我的增量物化视图刷新开始变得越来越慢。每天都有数百万条新记录。所以mv日志表上有很多删除。经过调查,我发现一个特定的 sql 花费了大量时间,这可能会导致根本原因。以下是作为 mv 刷新的一部分运行的 SQL 之一:
SQL> select dmltype$$, max(snaptime$$) from "S"."MLOG$_TABLE_202210" group by dmltype$$;
no rows selected
Elapsed: 00:00:12.68
Statistics
----------------------------------------------------------
7 recursive calls
0 db block gets
678822 consistent gets
678789 physical reads
0 redo size
438 bytes sent via SQL*Net to client
41 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
正如您所看到的,对这个空 mv 日志表的计数花费了 12 秒!(我们有很多这样的)。原因是物理读取量较高。统计数据的目的是锁定的(就预言机推荐而言)
SQL> select NUM_ROWS,BLOCKS,EMPTY_BLOCKS,AVG_SPACE_FREELIST_BLOCKS,LAST_ANALYZED,STATTYPE_LOCKED,STALE_STATS
from dba_tab_statistics
where table_name='MLOG$_TABLE_202210';
NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE_FREELIST_BLOCKS LAST_ANAL STATT STALE_S
---------- ---------- ------------ ------------------------- --------- ----- -------
0 0 0 0 14-NOV-22 ALL YES
SQL> SELECT EXTENTS, blocks, bytes
FROM dba_segments
WHERE SEGMENT_NAME = 'MLOG$_TABLE_202210';
EXTENTS BLOCKS BYTES
---------- ---------- ----------
18 384 3145728
因此,如果表不在 SGA 中,它会遍历所有由于多次删除而导致 HWM 较高的块。因为这都是 mv 刷新 - 如果我运行 truncate 它会破坏 MV。
我将不胜感激一些其他建议。
我最终做的是
enable row movement
+shrink space compact
+move
- 将其减少到 0.01 秒。