【Oracle】-【COMMIT對索引的影響】-從trace看COMMIT對索引的影響
之前看過老楊http://yangtingkun.itpub.net/post/468/231000的一篇文章,講述了INSERT操作對全文索引無操作,但DELETE時為了防止刪除的資料仍能通過索引的ROWID訪問產生的錯誤,此時會進行索引的刪除操作,因此大批量的DELETE-COMMIT就會耗時,甚至導致資料庫掛起。
最近因為工作上的需求,有個任務涉及到資料遷移,因此一直關注COMMIT耗時的問題,就想按照老楊的方法,看看對於普通索引,上述所說的COMMIT是否有影響。
測試環境:Oracle 10.2.0.4+Linux x86_64
用例1:INSERT後COMMIT操作。
SQL> create table t as select * from dba_objects;
Table created.
SQL> create index t_idx on t(object_id);
Index created.
SQL> insert into t(object_id) values(1);
1 row created.
SQL> alter session set sql_trace=true;
Session altered.
SQL> commit;
Commit complete.
SQL> alter session set sql_trace=false;
Session altered.
用例2:DELETE後COMMIT操作。
重登陸
SQL> delete from t where object_id=1;
1 row deleted.
SQL> alter session set sql_trace=true;
Session altered.
SQL> commit;
Commit complete.
SQL> alter session set sql_trace=false;
Session altered.
這裡重登陸再trace是為了防止重用會話快取的遊標,從而使結果更清晰。
用例1的trace檔案:
*** 2013-07-31 08:56:57.328
*** ACTION NAME:() 2013-07-31 08:56:57.328
*** MODULE NAME:(sqlplus@vm-vmw4131-t (TNS V1-V3)) 2013-07-31 08:56:57.328
*** SERVICE NAME:(SYS$USERS) 2013-07-31 08:56:57.328
*** SESSION ID:(508.20733) 2013-07-31 08:56:57.327
=====================
PARSING IN CURSOR #1 len=6 dep=0 uid=0 ct=44 lid=0 tim=1343000212234337 hv=3480936638 ad='0'
commit
END OF STMT
PARSE #1:c=0,e=54,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1343000212234330
XCTEND rlbk=0, rd_only=0
EXEC #1:c=0,e=374,p=0,cr=0,cu=1,mis=0,r=0,dep=0,og=0,tim=1343000212235249
=====================
PARSING IN CURSOR #2 len=33 dep=0 uid=0 ct=42 lid=0 tim=1343000219675725 hv=525901419 ad='0'
alter session set sql_trace=false
END OF STMT
PARSE #2:c=0,e=47,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1343000219675717
EXEC #2:c=0,e=28,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1343000219675914
用例2的trace檔案:
*** 2013-07-31 08:57:43.829
*** ACTION NAME:() 2013-07-31 08:57:43.828
*** MODULE NAME:(sqlplus@vm-vmw4131-t (TNS V1-V3)) 2013-07-31 08:57:43.828
*** SERVICE NAME:(SYS$USERS) 2013-07-31 08:57:43.828
*** SESSION ID:(508.20743) 2013-07-31 08:57:43.828
=====================
PARSING IN CURSOR #3 len=6 dep=0 uid=0 ct=44 lid=0 tim=1343000257645312 hv=3480936638 ad='0'
commit
END OF STMT
PARSE #3:c=0,e=130,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1343000257645304
XCTEND rlbk=0, rd_only=0
EXEC #3:c=0,e=424,p=0,cr=0,cu=1,mis=0,r=0,dep=0,og=0,tim=1343000257646177
=====================
PARSING IN CURSOR #1 len=33 dep=0 uid=0 ct=42 lid=0 tim=1343000265207698 hv=525901419 ad='0'
alter session set sql_trace=false
END OF STMT
PARSE #1:c=0,e=50,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1343000265207690
EXEC #1:c=0,e=31,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1343000265207917
由此可見,兩種操作後的trace顯示僅僅包含COMMIT操作,並沒有類似文章中提到的對全文索引那樣的維護操作。換句話說,我理解COMMIT操作自身除觸發LGWR外,沒有其它的耗時。如果COMMIT的時間長,一方面可能是LGWR的問題,另一方面可能是COMMIT之前的操作問題,需要具體問題具體分析。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7192724/viewspace-767511/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- oracle點陣圖索引對DML操作的影響Oracle索引
- 16、MySQL Case-索引key對select count(*)的影響MySql索引
- 資料庫聚簇索引——not null條件對唯一鍵索引成為聚簇索引的影響資料庫索引Null
- 修改系統時間對oracle的影響Oracle
- MySQL:Innodb:innodb_flush_log_at_trx_commit引數影響的位置MySqlMIT
- 修改主機時區對Oracle的影響分析Oracle
- oracle全文索引之commit與DML操作Oracle索引MIT
- 表資料量影響MySQL索引選擇MySql索引
- 新特性:/dev/shm對Oracle 11g的影響devOracle
- 磁碟排序對Oracle資料庫效能的影響PT排序Oracle資料庫
- 【Dataguard】Oracle多租戶環境對Dataguard的影響Oracle
- unusable index對DML/QUERY的影響Index
- Nologging對恢復的影響(二)
- 語言對思維的影響
- Nologging對恢復的影響(一)
- 網線的分類與對網速的影響 網線對網速影響大嗎?
- 浮動的盒子對img的影響
- Oracle 11g 測試停庫對job的影響Oracle
- 來電對播放音樂的影響
- python:super()對多繼承的影響Python繼承
- DB2 HADR對效能的影響DB2
- INDEX建立方式對SQL的影響IndexSQL
- 關於OPcache對Swoole影響的理解opcache
- Postgresql MVCC架構對從庫長查詢的影響SQLMVC架構
- 終端環境對go程式的影響?Go
- margin為負值對佈局的影響
- Sailthru:Facebook醜聞對人們的影響AI
- 網路延遲對事務的影響
- JVM 引數調整對 sortx 的影響JVM
- Mavrck:COVID-19對創作者的影響VR
- cluster factor對執行計劃的影響
- 淺談疫情對消費金融的影響
- 虛擬記憶體對 OI 的影響記憶體
- VideaHealth:人工智慧對牙科的真正影響Idea人工智慧
- windows server許可權對tomcat的影響WindowsServerTomcat
- namespace對axis解析xml請求的影響namespaceXML
- 是什麼影響了資料庫索引選型?資料庫索引
- MySQL alter 新增列對dml影響MySql
- 海外伺服器對SEO影響?伺服器