Oracle 中临时数据的性能注意事项

Question

我正在评估各种选项，以针对 Oracle 中的单个临时数据集运行一组高性能查询。在 T-SQL 中，我可能会使用内存中的临时表，但 Oracle 没有与此功能完全相同的功能。

我目前看到以下选项：

1。全局临时表

CREATE GLOBAL TEMPORARY TABLE test_temp_t (
  n NUMBER(10), 
  s VARCHAR2(10)
) ON COMMIT DELETE ROWS; -- Other configurations are possible, too

DECLARE
  t test_t;
  n NUMBER(10);
BEGIN

  -- Replace this with the actual temporary data set generation
  INSERT INTO test_temp_t
  SELECT MOD(level, 10), '' || MOD(level, 12)
  FROM dual
  CONNECT BY level < 1000000;

  -- Replace this example query with more interesting statistics
  SELECT COUNT(DISTINCT t.n)
  INTO n 
  FROM test_temp_t t;

  DBMS_OUTPUT.PUT_LINE(n);
END;

计划：

----------------------------------------------------
| Id  | Operation            | A-Rows |   A-Time   |
----------------------------------------------------
|   0 | SELECT STATEMENT     |      1 |00:00:00.27 |
|   1 |  SORT AGGREGATE      |      1 |00:00:00.27 |
|   2 |   VIEW               |     10 |00:00:00.27 |
|   3 |    HASH GROUP BY     |     10 |00:00:00.27 |
|   4 |     TABLE ACCESS FULL|    999K|00:00:00.11 |
----------------------------------------------------

2。 PL/SQL 表类型变量的取消嵌套

CREATE TYPE test_o AS OBJECT (n NUMBER(10), s VARCHAR2(10));
CREATE TYPE test_t AS TABLE OF test_o;

DECLARE
  t test_t;
  n NUMBER(10);
BEGIN

  -- Replace this with the actual temporary data set generation
  SELECT test_o(MOD(level, 10), '' || MOD(level, 12))
  BULK COLLECT INTO t
  FROM dual
  CONNECT BY level < 1000000;

  -- Replace this example query with more interesting statistics
  SELECT COUNT(DISTINCT n)
  INTO n 
  FROM TABLE(t) t;

  DBMS_OUTPUT.PUT_LINE(n);
END;

计划：

------------------------------------------------------------------
| Id  | Operation                          | A-Rows |   A-Time   |
------------------------------------------------------------------
|   0 | SELECT STATEMENT                   |      1 |00:00:00.68 |
|   1 |  SORT GROUP BY                     |      1 |00:00:00.68 |
|   2 |   COLLECTION ITERATOR PICKLER FETCH|    999K|00:00:00.22 |
------------------------------------------------------------------

3。物化视图

我将它们排除在这个用例之外，因为有问题的临时数据集相当复杂，而且对更新物化视图的影响太大。

真实数据注意事项

以上是我正在尝试做的示例。真实数据集涉及：

• 临时数据是从大约 15 个连接的表中非规范化的。
• 它的生产速度约为 2-20x / 秒。
• 每个临时数据集的实际行数约为 10-200（没有上例中那么大）。
• 系统的每个用户都有自己的临时数据集（总共 100 万用户，10k 并发用户）。
• 建立数据集后，应针对它运行大约 10-50 个分析查询。
• 这些分析必须在线运行，即不能推迟到批处理作业。

问题

根据我的直觉，临时表查询“应该”比较慢，因为它（可能）涉及 I/O 和磁盘访问，而 PL/SQL 集合查询仅仅是内存中的解决方案.但在我的简单基准测试中，情况并非如此，因为临时表查询比 PL/SQL 集合查询高出 3 倍。为什么会这样？是否发生了一些 PL/SQL SQL 上下文切换？

对于定义明确的临时数据集，我是否还有其他选项可以快速（但广泛）“内存中”数据分析？是否有任何重要的公开基准比较各种选项？

Answer 1

由于缓存和异步 I/O，临时表实际上与内存表相同，并且临时表解决方案不需要任何在 SQL 和 PL/SQL 之间转换的开销。

确认结果

将两个版本与 RunStats 进行比较，临时表版本看起来要差得多。 Run1 中临时表版本的所有垃圾，Run2 中的 PL/SQL 版本只有一点额外内存。起初，PL/SQL 似乎应该是明显的赢家。

Type  Name                              Run1 (temp) Run2 (PLSQL)         Diff
----- -------------------------------- ------------ ------------ ------------
...
STAT  physical read bytes                    81,920            0      -81,920
STAT  physical read total bytes              81,920            0      -81,920
LATCH cache buffers chains                  104,663          462     -104,201
STAT  session uga memory                    445,488      681,016      235,528
STAT  KTFB alloc space (block)            2,097,152            0   -2,097,152
STAT  undo change vector size             2,350,188            0   -2,350,188
STAT  redo size                           2,804,516            0   -2,804,516
STAT  temp space allocated (bytes)       12,582,912            0  -12,582,912
STAT  table scan rows gotten             15,499,845            0  -15,499,845
STAT  session pga memory                    196,608   19,857,408   19,660,800
STAT  logical read bytes from cache     299,958,272            0 -299,958,272

但归根结底，只有挂钟时间很重要。使用临时表时，加载和查询步骤都运行得更快。

可以通过将BULK COLLECT 替换为cast(collect(test_o(MOD(a, 10), '' || MOD(a, 12))) as test_t) INTO t 来改进PL/SQL 版本。但它仍然比临时表版本慢很多。

优化读取

从小型临时表中读取仅使用内存中的缓冲区缓存。只运行查询部分多次，观察consistent gets from cache（内存）如何增加，而physical reads cache（磁盘）保持不变。

select name, value
from v$sysstat
where name in ('db block gets from cache', 'consistent gets from cache', 
'physical reads cache');

优化写入

理想情况下不会有物理 I/O，尤其是因为临时表是 ON COMMIT DELETE ROWS。而且听起来Oracle的下一个版本可能会引入这样的机制。但在这种情况下，这并不重要，磁盘 I/O 似乎并没有减慢速度。

多次运行加载步骤，然后运行select * from v$active_session_history order by sample_time desc;。大多数 I/O 是BACKGROUND，这意味着没有任何东西在等待它。我假设临时表内部逻辑只是常规 DML 机制的副本。一般来说，如果新表数据已提交，可能需要写入磁盘。 Oracle 可能会开始处理它，例如将数据从日志缓冲区移动到磁盘，但在有实际的COMMIT 之前不会急于求成。

PL/SQL 时间都去哪儿了？

我不知道。 SQL 和 PL/SQL 引擎之间是否存在多个上下文切换或单个转换？据我所知，没有可用的指标显示在 SQL 和 PL/SQL 之间切换所花费的时间。

我们可能永远不知道为什么 PL/SQL 代码会更慢。我不太担心。一般的答案是，绝大多数数据库工作无论如何都必须在 SQL 中完成。如果 Oracle 花费更多时间优化其数据库核心 SQL，而不是附加语言 PL/SQL，那将是很有意义的。

补充说明

对于性能测试，将connect by 逻辑删除到单独的步骤中会很有帮助。该 SQL 是加载数据的绝妙技巧，但它可能非常缓慢且占用大量资源。使用该技巧加载样本表一次，然后从该表中插入更为现实。

我尝试使用新的 Oracle 12c 特性、临时撤消和新的 18c 特性、私有临时表。两者都没有提高常规临时表的性能。

我不会打赌，但我可以看到结果会随着数据变大而完全改变的方式。日志缓冲区和缓冲区缓存只能变得如此之大。最终，后台 I/O 可能会累加并压倒一些进程，将 BACKGROUND 等待变成 FOREGROUND 等待。另一方面，PL/SQL 解决方案只有这么多的 PGA 内存，然后事情就崩溃了。

最后，这部分证实了我对“内存数据库”的怀疑。缓存并不是什么新鲜事，数据库已经做了几十年了。

Answer 2

GTT 比 PLSQL 集合更快的原因可能是从双重（或您的真实表）中选择的上下文切换以及表很小，几乎可以肯定在缓冲区缓存中（无 I/O）的事实

因为您的表很小，我会使用带有 CACHE 选项的 GTT，以增加数据在 SGA 中的机会。

（但是这种类型的选项应该小心使用，因为它看起来不像。 请阅读Ask Tom about alter table cache和ask Tom about pools)

Answer 3

如果你像这样比较解决方案，结果是什么：

DECLARE
  t test_t;
  n NUMBER(10);
StartTime TIMESTAMP(9);  
BEGIN

StartTime := LOCALTIMESTAMP;  
  -- Replace this with the actual temporary data set generation
  SELECT test_o(MOD(level, 10), '' || MOD(level, 12))
  BULK COLLECT INTO t
  FROM dual
  CONNECT BY level < 1000000;
DBMS_OUTPUT.PUT_LINE ( EXTRACT(SECOND FROM (LOCALTIMESTAMP - StartTime) ) ||' sec.');

StartTime := LOCALTIMESTAMP;  
  -- Replace this example query with more interesting statistics
  SELECT COUNT(DISTINCT n)
  INTO n 
  FROM TABLE(t) t;
DBMS_OUTPUT.PUT_LINE ( EXTRACT(SECOND FROM (LOCALTIMESTAMP - StartTime) ) ||' sec.');

END;

这些数字可能更适合比较。