Oracle資料泵expdp遭遇Streams AQ: Enqueue Blocked On Low Memory等待事件
Oracle資料泵expdp遭遇Streams AQ: Enqueue Blocked On Low Memory等待事件
版本:11.2.0.4.0
PSU+OJVM:11.2.0.4.201020
對資料庫使用expdp做全庫匯出時,發現異常的慢。
每張小表的匯出都要隔個幾秒才會繼續匯出下一張表。
檢視資料泵會話的等待事件資訊如下:
10:00:51 SYS@test(586)> / SID SERIAL# EVENT SADDR PROGRAM USERNAME STATUS SQL_ID SQL_FULLTEXT---------- ---------- ------------------------------------------ ---------------- --------------------- ---------- --------- ---------------- ------------------------------------------------------- 526 56831 Streams AQ: enqueue blocked on low memory 00000000F6804560 oracle@testdb (DM00) SYS ACTIVE 87nt40c5wj7y5 BEGINsys.kupc$que_int.put_status(:1, :2, :3); END; 583 19087 Streams AQ: enqueue blocked on low memory 00000000F6756380 oracle@testdb (DW00) SYS ACTIVE 8rgw5q94paqsg BEGIN sys.kupc$que_int.send(:1, :2, :3); END; Elapsed: 00:00:00.00
檢視當前steam pool的值,發現並不小。
14:50:09 SYS@test(1091)> select COMPONENT,CURRENT_SIZE/1024/1024 CURRENT_SIZE_MB from V$SGA_DYNAMIC_COMPONENTS where COMPONENT='streams pool'; COMPONENT CURRENT_SIZE_MB -------------------------------------------------- --------------- streams pool 128 Elapsed: 00:00:00.01
搜尋mos,根據由於頻繁等待 ”Streams AQ: Enqueue Blocked On Low Memory" 而導致Datapump Expdp或Impdp變慢 (文件 ID 2469587.1),
症狀
Datapump匯出和匯入(expdp和impdp)可能會遇到突然嚴重的效能問題,因為DW和DM程序經常等待 "StreamsAQ: enqueue blocked on low memory"。
以下是expdp logtime = all命令的示例症狀。(logtime 引數在 12.1 及以上版本可用)
匯出空分割槽表需要0-3秒才能匯出每個分割槽,而正常時通常需要不到一秒的時間。
11-APR-18 18:02:26.726: Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER
11-APR-18 18:02:37.672: . . exported "<SCHEMA_NAME>"."<TABLE_NAME>":"<PART_NAME1>" 0 KB 0 rows
11-APR-18 18:02:40.677: . . exported "<SCHEMA_NAME>"."<TABLE_NAME>":"<PART_NAME2>" 0 KB 0 rows
11-APR-18 18:02:42.686: . . exported "<SCHEMA_NAME>"."<TABLE_NAME>":"<PART_NAME3>" 0 KB 0 rows
11-APR-18 18:02:45.699: . . exported "<SCHEMA_NAME>"."<TABLE_NAME>":"<PART_NAME4>" 0 KB 0 rows
11-APR-18 18:02:48.702: . . exported "<SCHEMA_NAME>"."<TABLE_NAME>":"<PART_NAME5>" 0 KB 0 rows
11-APR-18 18:02:50.712: . . exported "<SCHEMA_NAME>"."<TABLE_NAME>":"<PART_NAME6>" 0 KB 0 rows
11-APR-18 18:02:53.724: . . exported "<SCHEMA_NAME>"."<TABLE_NAME>":"<PART_NAME7>" 0 KB 0 rows更改
在Auto SGA環境(設定了sga_target或memory_target)下,當 buffer cache負載較高並且 streams pool 中的記憶體正被移動到 buffer cache 時,可能會發生此問題。
如果遇到類似的效能問題時,請檢查以下查詢是否一直返回“1”。該值表示 streams pool 處於收縮階段。當 streams pool 完成收縮時,該值應返回“0”,但如果它一直返回“1”,則您可能遇到此問題。
SQL> select shrink_phase_knlasg from X$KNLASG;
SHRINK_PHASE_KNLASG
-------------------
1原因
即使 streams pool 已經結束收縮,該標誌也沒有被修改,這導致各種 stream pool 操作(例如資料泵的內部操作)等待 "StreamsAQ: enqueue blocked on low memory"。
該問題是由於Bug 27634991引起的,在版本19.1及更高版本中修復了該問題。
解決方案
如果由於“StreamsAQ: enqueue blocked on low memory”等待事件導致expdp / impdp命令出現嚴重效能問題,並且X$KNLASG.SHRINK_PHASE_KNLASG 列保持返回1並持續幾分鐘,則從sqlplus執行以下命令強制streams pool縮小完成。
connect / as sysdba
alter system set events 'immediate trace name mman_create_def_request level 6';
可以應用Patch 27634991以防止發生此問題。
根據mos,檢視我自己的環境:
14:52:16 SYS@test(1091)> select shrink_phase_knlasg from X$KNLASG; SHRINK_PHASE_KNLASG ------------------- 1 Elapsed: 00:00:00.01
根據建議執行"alter system set events 'immediate trace name mman_create_def_request level 6';"後,expdp的日誌刷刷比原來快了不少。