gc current block pin time gc current block flush time 疑惑
非常簡單的記錄,沒有可讀性,留作一個疑惑。
第一個節點更新資料塊
第二個節點更新同樣的資料塊
由於是更新操作,因此需要塊的current block
第二個節點像第一個節點要求current block,再傳送前,第一個節點需要pin住此塊,把log buffer內的內容寫磁碟。
統計量裡的gc current block pin time gc current block flush time分別對應了此種情況。但是我模擬的情況,發現並沒有發生統計量的增加。
節點1:
test@ILSP>select
2 statistic#,
3 name,
4 value
5 from
6 v$sysstat where statistic# in (215,216);
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 68
216 gc current block flush time 7019
test@ILSP> update t_one set v1='10' where n1=265 and rownum=1;
1 row updated.
test@ILSP>
test@ILSP>select
2 statistic#,
3 name,
4 value
5 from
6 v$sysstat where statistic# in (215,216);
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 68
216 gc current block flush time 7019
節點2:
test@ILSP>select
2 statistic#,
3 name,
4 value
5 from
6 v$sysstat where statistic# in (215,216);
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 67
216 gc current block flush time 6906
test@ILSP> update t_one set v1='10' where n1=266 and rownum=1;
1 row updated.
test@ILSP>
test@ILSP>select
2 statistic#,
3 name,
4 value
5 from
6 v$sysstat where statistic# in (215,216);
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 67
216 gc current block flush time 6906
但是,另一個場景卻發生了:
test@ILSP>begin
2 for i in 1 ..100000 loop
3 UPDATE wxh_tbd SET object_name=20 where rowid='AAAVaMAAEAAABDjAAA';
4 commit write immediate wait;
5 end loop;
6 end;
7 /
test@ILSP>begin
2 for i in 1 ..10000 loop
3 UPDATE wxh_tbd SET object_name=20 where rowid='AAAVaMAAEAAABDjAAB';
4 commit write immediate wait;
5 end loop;
6 end;
7 /
sys@ILSP>select
2 statistic#,
3 name,
4 value
5 from
6 v$sysstat where statistic# in (215,216);
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 72
216 gc current block flush time 7502
2 rows selected.
sys@ILSP>/
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 73
216 gc current block flush time 7545
2 rows selected.
sys@ILSP>/
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 73
216 gc current block flush time 7570
2 rows selected.
sys@ILSP>/
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 74
216 gc current block flush time 7591
我的版本是11.2.0.3,我的猜想,可能是ORACLE做了最佳化,再傳送current block前檢查下對應的日誌有沒有寫磁碟,如果已經寫磁碟了,就不需要再去做pin和flush的操作了。
第一個節點更新資料塊
第二個節點更新同樣的資料塊
由於是更新操作,因此需要塊的current block
第二個節點像第一個節點要求current block,再傳送前,第一個節點需要pin住此塊,把log buffer內的內容寫磁碟。
統計量裡的gc current block pin time gc current block flush time分別對應了此種情況。但是我模擬的情況,發現並沒有發生統計量的增加。
節點1:
test@ILSP>select
2 statistic#,
3 name,
4 value
5 from
6 v$sysstat where statistic# in (215,216);
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 68
216 gc current block flush time 7019
test@ILSP> update t_one set v1='10' where n1=265 and rownum=1;
1 row updated.
test@ILSP>
test@ILSP>select
2 statistic#,
3 name,
4 value
5 from
6 v$sysstat where statistic# in (215,216);
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 68
216 gc current block flush time 7019
節點2:
test@ILSP>select
2 statistic#,
3 name,
4 value
5 from
6 v$sysstat where statistic# in (215,216);
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 67
216 gc current block flush time 6906
test@ILSP> update t_one set v1='10' where n1=266 and rownum=1;
1 row updated.
test@ILSP>
test@ILSP>select
2 statistic#,
3 name,
4 value
5 from
6 v$sysstat where statistic# in (215,216);
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 67
216 gc current block flush time 6906
但是,另一個場景卻發生了:
test@ILSP>begin
2 for i in 1 ..100000 loop
3 UPDATE wxh_tbd SET object_name=20 where rowid='AAAVaMAAEAAABDjAAA';
4 commit write immediate wait;
5 end loop;
6 end;
7 /
test@ILSP>begin
2 for i in 1 ..10000 loop
3 UPDATE wxh_tbd SET object_name=20 where rowid='AAAVaMAAEAAABDjAAB';
4 commit write immediate wait;
5 end loop;
6 end;
7 /
sys@ILSP>select
2 statistic#,
3 name,
4 value
5 from
6 v$sysstat where statistic# in (215,216);
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 72
216 gc current block flush time 7502
2 rows selected.
sys@ILSP>/
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 73
216 gc current block flush time 7545
2 rows selected.
sys@ILSP>/
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 73
216 gc current block flush time 7570
2 rows selected.
sys@ILSP>/
STATISTIC# NAME VALUE
---------- ---------------------------------------------------------------- ----------
215 gc current block pin time 74
216 gc current block flush time 7591
我的版本是11.2.0.3,我的猜想,可能是ORACLE做了最佳化,再傳送current block前檢查下對應的日誌有沒有寫磁碟,如果已經寫磁碟了,就不需要再去做pin和flush的操作了。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22034023/viewspace-1427402/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- gc current/cr block busy等待事件GCBloC事件
- gc current block busy和LMS優先順序GCBloC
- mysql CURRENT_TIMESTAMP 和ON UPDATE CURRENT_TIMESTAMPMySql
- 解決gc current request等待事件GC事件
- gc current request等待時間處理GC
- 【等待事件】global cache cr request/gc current request事件GC
- gc current request 引起長期鎖表的故障GC
- MySQL中的CURRENT_TIMESTAMPMySql
- ORA-13639: The CURRENT operation was interrupted because it timed OUT
- Monitor RDBMS Session UGA and PGA Current And Maximum Usage Over TimeSession
- 教你如何使用MySQL中CURRENT_TIMESTAMP時間戳MySql時間戳
- Job: TO_CHAR(CURRENT_TIMESTAMP, 'HH24MISSFF') errorError
- gc cr request 'gcs log flush sync'GC
- 如何診斷RAC系統中的'gc cr multi block request'?GCBloC
- ORA-600 [2662] Block SCN is ahead of Current SCN 處理方法 說明BloC
- oracle 中關於當前的sysdate,sysstimestap,current_date,curent_timestamp 區別Oracle
- 分析解決11gR2 雙節點RAC環境下的gc cr block busy/gc buffer busy acquire等待GCBloCUI
- RuntimeError: An attempt has been made to start a new process before the current process hasError
- gc current request等待事件,介紹p1,p2,p3轉換方法GC事件
- PostgreSQL DBA(111) - pgAdmin(Don't do this:Don't use CURRENT_TIME)SQL
- iOS | 用於解決迴圈引用的block timeriOSBloC
- makes the current sessionSession
- 記一次線上問題 → 對 MySQL 的 ON UPDATE CURRENT_TIMESTAMP 的片面認知MySql
- iOS常見面試題(block,runtime,runloop,類結構)附參考答案iOS面試題BloCOOP
- 從CLR GC到CoreCLR GCGC
- [pl sql] where current ofSQL
- GCGC
- GC Agent Startup Fails on AIX due to Invalid Timezone Setting at OS_825933.1GCAI
- 一個疑惑 ,gc cr grant 2-way ,簡單記錄GC
- Full GC (Metadata GC Threshold)GC
- GC.MaxGeneration屬性【GC示例】GC
- Minor GC、Major GC以及Full GC的介紹及對比GC
- RAC 環境中 gc block lost 和私網通訊效能問題的診斷 (文件 ID 1674865.1)GCBloC
- Block學習①--block的本質BloC
- 遊標current of cur特性
- UIButton、UIGestureRecongnizer、UITapGestureRecongnizer、NSTimer、UISwitch事件以block的方式回撥...UI事件BloC
- 【MOS】RAC 環境中 gc block lost 和私網通訊效能問題的診斷 (文件 ID 1674865.1)GCBloC
- AUTHID DEFINER\authid current_user與alter session set current_schemaSession