update操作會產生幾條mlog$日誌?
我們知道,在快速重新整理物化檢視中,源表必須建立物化檢視日誌來記錄源表資料的變化,從而使得物化檢視能夠快速重新整理。
今天以前一位同事提出這樣一個問題:做一個update操作會產生兩個mlog$日誌。這與我印象中產生一條記錄不同。
下面重現這個過程:
首先建立測試資料表:
SQL> create table k(id int primary key,name varchar2(10));
Table created
SQL> create materialized view log on k;
Materialized view log created
SQL> insert into k values(1,'suk');
1 row inserted
SQL> commit;
Commit complete
SQL> create materialized view mv_t as select * from k;
Materialized view created
SQL> select * from mlog$_k;
ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$
---------- ----------- --------- --------- ----------------------
SQL> select * from mv_t;
ID NAME
--------------------------------------- ----------
1 suk
--執行一個更新操作
SQL> update k set name='new' where id=1;
1 row updated
SQL> select * from mlog$_k;
ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$
---------- ----------- --------- --------- ---------------------
1 4000-1-1 U U 04
--產生一條mlog記錄,DML型別為U
SQL> rollback;
Rollback complete
SQL> select * from mlog$_k;
ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$
---------- ----------- --------- --------- ---------------------
--再更新一條記錄,不過這次更新內容包含主鍵
SQL> update k set name='new',id=2 where id=1;
1 row updated
SQL> select * from mlog$_k;
ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$
---------- ----------- --------- --------- --------------------
1 4000-1-1 D O 00
2 4000-1-1 I N FF
--可以看出,更新列包含主鍵的話會產生2條mlog記錄。在這種情況下,一個update操作實際上是由一個DELETE操作和一個INSERT操作組成的。
--其實oracle這樣做有它的道理,如果MV是基於主鍵重新整理的,如果主鍵被update了,如果它不記錄下來原來主鍵ID的話,MV段就不知道那條記錄被update了
--那麼是不是更新內容包含主鍵的話都會產生2條mlog記錄呢?再看看下面的測試:
SQL> rollback;
Rollback complete
SQL> select * from mlog$_k;
ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$
---------- ----------- --------- --------- --------------------
--更新主鍵,但是鍵值與之前一樣
SQL> update k set name='new',id=1 where id=1;
1 row updated
SQL> select * from mlog$_k;
ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$
---------- ----------- --------- --------- ---------------------
1 4000-1-1 U U 04
--可以看到,oracle還是比較聰明的,已經把這種更新情況考慮進去了
--這種方式下,它實際上與更新非主鍵產生操作的mlog是一樣的
總結:
1、更新列都是非主鍵時
每更新一條記錄,在MLOG$會產生一個型別為U的記錄。
2、更新列包含主鍵時
如果鍵值變化,每更新一條記錄,在MLOG$會產生兩條記錄:D和I。
如果鍵值不發生變化,每更新一條記錄,在MLOG$會產生一個型別為U的記錄。
今天以前一位同事提出這樣一個問題:做一個update操作會產生兩個mlog$日誌。這與我印象中產生一條記錄不同。
下面重現這個過程:
首先建立測試資料表:
SQL> create table k(id int primary key,name varchar2(10));
Table created
SQL> create materialized view log on k;
Materialized view log created
SQL> insert into k values(1,'suk');
1 row inserted
SQL> commit;
Commit complete
SQL> create materialized view mv_t as select * from k;
Materialized view created
SQL> select * from mlog$_k;
ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$
---------- ----------- --------- --------- ----------------------
SQL> select * from mv_t;
ID NAME
--------------------------------------- ----------
1 suk
--執行一個更新操作
SQL> update k set name='new' where id=1;
1 row updated
SQL> select * from mlog$_k;
ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$
---------- ----------- --------- --------- ---------------------
1 4000-1-1 U U 04
--產生一條mlog記錄,DML型別為U
SQL> rollback;
Rollback complete
SQL> select * from mlog$_k;
ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$
---------- ----------- --------- --------- ---------------------
--再更新一條記錄,不過這次更新內容包含主鍵
SQL> update k set name='new',id=2 where id=1;
1 row updated
SQL> select * from mlog$_k;
ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$
---------- ----------- --------- --------- --------------------
1 4000-1-1 D O 00
2 4000-1-1 I N FF
--可以看出,更新列包含主鍵的話會產生2條mlog記錄。在這種情況下,一個update操作實際上是由一個DELETE操作和一個INSERT操作組成的。
--其實oracle這樣做有它的道理,如果MV是基於主鍵重新整理的,如果主鍵被update了,如果它不記錄下來原來主鍵ID的話,MV段就不知道那條記錄被update了
--那麼是不是更新內容包含主鍵的話都會產生2條mlog記錄呢?再看看下面的測試:
SQL> rollback;
Rollback complete
SQL> select * from mlog$_k;
ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$
---------- ----------- --------- --------- --------------------
--更新主鍵,但是鍵值與之前一樣
SQL> update k set name='new',id=1 where id=1;
1 row updated
SQL> select * from mlog$_k;
ID SNAPTIME$$ DMLTYPE$$ OLD_NEW$$ CHANGE_VECTOR$$
---------- ----------- --------- --------- ---------------------
1 4000-1-1 U U 04
--可以看到,oracle還是比較聰明的,已經把這種更新情況考慮進去了
--這種方式下,它實際上與更新非主鍵產生操作的mlog是一樣的
總結:
1、更新列都是非主鍵時
每更新一條記錄,在MLOG$會產生一個型別為U的記錄。
2、更新列包含主鍵時
如果鍵值變化,每更新一條記錄,在MLOG$會產生兩條記錄:D和I。
如果鍵值不發生變化,每更新一條記錄,在MLOG$會產生一個型別為U的記錄。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/231499/viewspace-63797/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 關於delete還是update會產生更多日誌的問題delete
- 減少oracle日誌的產生Oracle
- 【體系結構】dump檢視update操作redo日誌
- 物化檢視comlete重新整理會產生大量的日誌
- 減少日誌產生量小結
- 每天產生REDO歸檔日誌量
- oracle 日誌產生大小的計算Oracle
- 非IMU模式下一條update語句產生REDO RECORD條數的探究模式
- Oracle產生redo日誌量大小統計Oracle
- 啟用生產工單標準日誌
- 測試DML 時產生歸檔日誌和閃回日誌的比
- 【oracle】關於日誌產生量的計算Oracle
- 【LISTENER】禁止產生監聽器日誌的方法
- 生產資料update沒加where條件(從執行到恢復)
- 解決生產日誌重複列印的問題
- Oracle資料庫減少redo日誌產生方式Oracle資料庫
- MySQL案例之——生產slave庫無法應用日誌MySql應用日誌
- oracle redo日誌產生量測試及比較1Oracle Redo
- 2.4慢操作日誌
- Filebeat 收集K8S 日誌,生產環境實踐K8S
- 聊一聊如何截獲 C# 程式產生的日誌C#
- oracle檢視昨天產生歸檔日誌檔案總量Oracle
- 物化檢視日誌對UPDATE的影響
- 有條件分析oracle日誌Oracle
- 11G Oracle 關閉監聽XML日誌產生的方法OracleXML
- trace_enabled 是否產生trace日誌--按情況來關閉
- 11G flashback data archive 導致產生大量歸檔日誌Hive
- update/select也可能產生buffer busy waits。AI
- 日誌分析常規操作
- secureCRT記錄操作日誌Securecrt
- 重做日誌基礎操作
- oracle日誌操作記錄Oracle
- dml操作重做日誌分析
- spring-boot-route(十六)使用logback生產日誌檔案Springboot
- oracle redo日誌產生量測試及比較2_insertOracle Redo
- goldengate 目的端同步無主鍵無索引表時的rpt日誌(做update操作)Go索引
- Linux系統日誌分為哪幾種?日誌檔案包括幾列內容?Linux
- webpack watch模式產生*.hot-update.json檔案Web模式JSON