У нас есть обновление Mview (полное обновление), которое выполняется в DB1, и оно отправляет инструкцию SELECT по dblink в DB2. Первоначально, когда он запускается через привилегированного пользователя, он застревает на несколько часов. Когда мы исследовали это, он показывает ожидания из-за "Физического чтения ячейки одного блока". Однако, когда мы завершаем обновление из DB1 / DB2 и перезапускаем, оно быстро завершается (от 2 до 10 минут) и выдает событие ожидания (событие ожидания чтения многоблочного ЦП или ячейки БД). Это происходит почти каждый день для нас.
Мы сравнили план выполнения с тем временем, когда он выполнялся в DB2, мы не видим особых изменений ни в plan_hash_value и SQL_ID, ни в плане выполнения. Кто-нибудь знает / или скажите мне, что еще мне здесь не хватает, а также какие-либо идеи, как можно решить эту проблему.
1st run
=======
SNAP_ID NODE BEGIN_INTERVAL_TIME SQL_ID PLAN_HASH_VALUE EXECS AVG_ETIME AVG_LIO AVG_PIO
---------- ------ ------------------------------ ------------- --------------- ------------ ------------ -------------- --------------
77142 3 01-OCT-19 07.15.05.867 AM fybjvvtk09u2j 0 912.735 1,090,393.0 440,686.0
77143 3 01-OCT-19 07.30.00.413 AM fybjvvtk09u2j 0 842.735 989,493.0 467,590.0
kill and re-run
===============
SNAP_ID NODE BEGIN_INTERVAL_TIME SQL_ID PLAN_HASH_VALUE EXECS AVG_ETIME AVG_LIO AVG_PIO
---------- ------ ------------------------------ ------------- --------------- ------------ ------------ -------------- --------------
77144 4 01-OCT-19 07.45.01.936 AM fybjvvtk09u2j 1 98.649 14,272,525.0 14,591,211.0
План выполнения 1-й запуск: -
Plan hash value: 3547885274
----------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | | 447K(100)| | | |
| 1 | HASH GROUP BY | | 27M| 1414M| 2004M| 447K (2)| 00:00:18 | | |
|* 2 | HASH JOIN | | 27M| 1414M| 281M| 180K (4)| 00:00:08 | | |
| 3 | TABLE ACCESS STORAGE FULL | AUDIT_LOG | 11M| 146M| | 8504 (4)| 00:00:01 | | |
| 4 | PARTITION HASH ALL | | 30M| 1200M| | 165K (4)| 00:00:07 | 1 | 256 |
|* 5 | TABLE ACCESS STORAGE FULL | DISA_DAILY_HHT_PUB | 30M| 1200M| | 165K (4)| 00:00:07 | 1 | 256 |
| 6 | SORT AGGREGATE | | 1 | 6 | | | | | |
| 7 | INDEX FULL SCAN (MIN/MAX)| DISA_DAILY_HHT_PUB_IDX2 | 1 | 6 | | 4 (0)| 00:00:01 | | |
----------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("P"."AUDIT_LOG_ID"="AL"."AUDIT_LOG_ID")
5 - storage("P"."AUDIT_LOG_ID"=)
filter("P"."AUDIT_LOG_ID"=)
Execution plan on kill and re-run :-
code
Plan hash value: 3547885274
----------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | | 437K(100)| | | |
| 1 | HASH GROUP BY | | 26M| 1360M| 1928M| 437K (2)| 00:00:18 | | |
|* 2 | HASH JOIN | | 26M| 1360M| 281M| 179K (4)| 00:00:08 | | |
| 3 | TABLE ACCESS STORAGE FULL | AUDIT_LOG | 11M| 146M| | 8504 (4)| 00:00:01 | | |
| 4 | PARTITION HASH ALL | | 29M| 1171M| | 165K (4)| 00:00:07 | 1 | 256 |
|* 5 | TABLE ACCESS STORAGE FULL | DISA_DAILY_HHT_PUB | 29M| 1171M| | 165K (4)| 00:00:07 | 1 | 256 |
| 6 | SORT AGGREGATE | | 1 | 6 | | | | | |
| 7 | INDEX FULL SCAN (MIN/MAX)| DISA_DAILY_HHT_PUB_IDX2 | 1 | 6 | | 4 (0)| 00:00:01 | | |
----------------------------------------------------------------------------------------------------------------------------------