物化試圖日誌過大
發現一張物化試圖日誌表達到了2G。...
[@more@]1. 遠端試圖使用的rowid重新整理,可我的日誌用的是主鍵建立的,所以fast重新整理失敗,結果使用了完全重新整理,導致日誌表一直增加。
順便看了下物化檢視重新整理的順序。
更新的順序是先刪除後更新,最後插入。
首先查詢出需要刪除的資料:
SELECT /*+ remote_mapped(MASPROD104.CIMC.COM) */
DISTINCT M_ROW$$
FROM (SELECT M_ROW$$
FROM "MAS9I"."MLOG$_ACTION_TEST1"@MASPROD104.CIMC.COM MLOG$
WHERE "SNAPTIME$$" > :1
AND ("DMLTYPE$$" != 'I')) LOG$
WHERE (M_ROW$$) NOT IN
(SELECT ROWID
FROM "MAS_TAB$"
WHERE MAS_TAB$.ROWID = LOG$.M_ROW$$);
DELETE FROM "MAS9I"."MV_ACTION_TEST1" SNAP$ WHERE M_ROW$$ = :1;
然後查出需要update和insert的資料
SELECT /*+ remote_mapped(MASPROD104.CIMC.COM) */
CURRENT$."R_ID",
CURRENT$."OWNER",
CURRENT$."OBJECT_NAME",
CURRENT$."SUBOBJECT_NAME",
CURRENT$."OBJECT_ID",
CURRENT$."DATA_OBJECT_ID",
CURRENT$."OBJECT_TYPE",
CURRENT$."CREATED",
CURRENT$."LAST_DDL_TIME",
CURRENT$."TIMESTAMP",
CURRENT$."STATUS",
CURRENT$."TEMPORARY",
CURRENT$."GENERATED",
CURRENT$."SECONDARY",
ROWIDTOCHAR(CURRENT$.ROWID) M_ROW$$
FROM (SELECT "A".ROWID "R_ID",
"A"."OWNER" "OWNER",
"A"."OBJECT_NAME" "OBJECT_NAME",
"A"."SUBOBJECT_NAME" "SUBOBJECT_NAME",
"A"."OBJECT_ID" "OBJECT_ID",
"A"."DATA_OBJECT_ID" "DATA_OBJECT_ID",
"A"."OBJECT_TYPE" "OBJECT_TYPE",
"A"."CREATED" "CREATED",
"A"."LAST_DDL_TIME" "LAST_DDL_TIME",
"A"."TIMESTAMP" "TIMESTAMP",
"A"."STATUS" "STATUS",
"A"."TEMPORARY" "TEMPORARY",
"A"."GENERATED" "GENERATED",
"A"."SECONDARY" "SECONDARY"
FROM "A") CURRENT$,
(SELECT DISTINCT M_ROW$$
FROM "MAS9I"."MLOG$_ACTION_TEST1"@MASPROD104.CIMC.COM MLOG$
WHERE "SNAPTIME$$" > :1
AND ("DMLTYPE$$" != 'D')) LOG$
WHERE CURRENT$.ROWID = LOG$.M_ROW$$;
UPDATE "MAS9I"."MV_ACTION_TEST1"
SET "R_ID" = :1,
"OWNER" = :2,
"OBJECT_NAME" = :3,
"SUBOBJECT_NAME" = :4,
"OBJECT_ID" = :5,
"DATA_OBJECT_ID" = :6,
"OBJECT_TYPE" = :7,
"CREATED" = :8,
"LAST_DDL_TIME" = :9,
"TIMESTAMP" = :10,
"STATUS" = :11,
"TEMPORARY" = :12,
"GENERATED" = :13,
"SECONDARY" = :14
WHERE M_ROW$$ = :15
select * from sys.snap_reftime$;
INSERT INTO "MAS9I"."MV_ACTION_TEST1" ("R_ID","OWNER","OBJECT_NAME","SUBOBJECT_NAME","OBJECT_ID","DATA_OBJECT_ID","OBJECT_TYPE","CREATED","LAST_DDL_TIME","TIMESTAMP","STATUS","TEMPORARY","GENERATED","SECONDARY","M_ROW$$") VALUES (:1,:2,:3,:4,:5,:6,:7,:8,:9,:10,:11,:12,:13,:14,:15)
UPDATE sys.snap$ SET status = :1, rscn = :2, refhnt = :3, flag = :4 WHERE vname = :5 AND sowner = :6 AND instsite = :7
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/133835/viewspace-1005195/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 物化檢視的快速重新整理測試與物化檢視日誌
- 【物化檢視】根據物化檢視日誌快速重新整理物化檢視的過程
- 【物化檢視】幾種物化檢視日誌分析
- 物化檢視日誌的維護
- oracle物化檢視日誌系列(一)Oracle
- oracle物化檢視日誌系列(二)Oracle
- oracle物化檢視日誌系列(三)Oracle
- 日誌檔案過大清理
- 多個物化檢視導致物化日誌無法及時更新
- 物化檢視日誌表被DROP後建立物化檢視報錯
- 物化檢視日誌與增量重新整理
- 物化檢視日誌對UPDATE的影響
- Oracle如何根據物化檢視日誌快速重新整理物化檢視Oracle
- 資料庫日誌減肥。自己試過可以資料庫
- 物化檢視匯出匯入可能導致物化檢視日誌的失效
- ORACLE 告警日誌alert過大的處理Oracle
- 物化檢視重新整理並非完全根據物化檢視日誌記錄
- SQL Server事務日誌過大的處理SQLServer
- 10G物化檢視PCT快速重新整理不再需要物化檢視日誌(三)
- 10G物化檢視PCT快速重新整理不再需要物化檢視日誌(二)
- 10G物化檢視PCT快速重新整理不再需要物化檢視日誌(一)
- 物化檢視日誌無法正常清除的解決方法
- 物化檢視日誌的重建 與 ORA-12034
- oracle監聽器日誌過大-處理辦法Oracle
- Oracle監聽日誌過大導致的問題Oracle
- 用exp、imp遷移包含物化檢視日誌的資料
- SYS使用者的表無法建立物化檢視日誌
- 物化檢視日誌(materialized view log)引起大量Dfs Lock Handle等待ZedView
- Oracle11gr2物化檢視日誌新增PURGE語句Oracle
- ELK太重?試試KFC日誌採集
- sqlserver 事務日誌過大 收縮方法解決方案SQLServer
- MongoDB日誌檔案過大的解決方法(不停機)MongoDB
- oracle 中 alert 報警日誌過大的處理方法Oracle
- 物化檢視comlete重新整理會產生大量的日誌
- 建立測試物理Standby日誌
- apache日誌匯入oracle(日誌經過python處理)ApacheOraclePython
- 大資料開發過程中Kafka日誌結構解析大資料Kafka
- mysql 關於大資料量日誌表的優化過程MySql大資料優化