物理寫的判斷 & 介質恢複 & 執行個體恢複 & 增量檢查點

標籤：physical   written   where   檢測   

物理寫的檢測：

select  * from v$sysstat where lower(name) like ‘physical writes%‘;

 physical writes 8 9 119             //我一共寫了多少塊

 

select * from v$sysstat where upper(name) like ‘DBW%‘;

 104 DBWR checkpoint buffers written 8 173 12  //通過檢查點寫了多少塊。

那你就可以用  buffer writer / physical writers      基本在百分之六，七十  算正常。

測試：

[email protected]_connect_identifier>[email protected]_connect_identifier>select * from v$sysstat where upper(name) like ‘DBWR%‘;STATISTIC# NAME CLASS VALUE STAT_ID---------- ---------------------------------------------------------------- ---------- ---------- ----------       104 DBWR checkpoint buffers written 8 259 1208600358       105 DBWR thread checkpoint buffers written 8 0 3905787588       106 DBWR tablespace checkpoint buffers written 8 0 2649259263       107 DBWR parallel query checkpoint buffers written 8 0 1768645316       108 DBWR object drop buffers written 8 0 658143835       109 DBWR transaction table writes 8 19 2146120386       110 DBWR undo block writes 8 73 111270822       111 DBWR revisited being-written buffer 8 0 2773697723       112 DBWR lru scans 8 0 2139101792

     

  113 DBWR checkpoints 8 0 1732023165       114 DBWR fusion writes 40 0 2313150541已選擇11行。[email protected]_connect_identifier>select * from v$sysstat where lower(name) like ‘physical writ%‘;STATISTIC# NAME CLASS VALUE STAT_ID---------- ---------------------------------------------------------------- ---------- ---------- ----------        48 physical write total IO requests 8 1301 1315894329        49 physical write total multi block requests 8 5 3540174003        50 physical write total bytes 8 16102400 2495644835        83 physical writes 8 272 1190468109        84 physical writes direct 8 13 2699895516        85 physical writes from cache 8 259 163083034        86 physical write IO requests 8 187 2904164198        89 physical writes direct temporary tablespace 8 9 996415569        90 physical write bytes 8 2228224 3131337131       102 physical writes non checkpoint 8 246 2602029796       156 physical writes direct (lob) 8 4 3308932835已選擇11行。

[email protected]_connect_identifier>select 259/272 from dual;   259/272----------.952205882

那什麼時候Oracle會做執行個體恢複呢？

其實Oracle是有一個標誌位的當他為1 時開啟就執行個體恢複，當他為0 時，那就不恢複嘍：

主要在 v$DATAFILE 中 有一個參數   last_time  和last_change#.  

 

你可以先將資料庫mount狀態，然後查詢    

select  last_time, last_change# from v$DATAFILE;

就可以觀察出來。出現結果了就是正常關閉，如果沒有結果那就是異常關閉。

判斷檔案是否需要介質恢複：

v$datafile;   來自控制檔案

v$datafile_header 來自資料檔案頭。

col name for a40select name,CHECKPOINT_CHANGE#, CHECKPOINT_TIME FROM V$DATAFILE;SELECT CHECKPOINT_CHANGE# FROM V$DATAFILE_HEADER;

如果出現那個檔案檢查點不一樣，那就需要介質恢複。

測試：

先熱備一下一個檔案：

rman target /backup datafile ‘/u01/app/oracle/oradata/test/test_01‘  format  ‘/tmp/test_01%U.bak‘;

更改時間格式：

alter  session set nls_date_format=‘yyyy-mm-dd hh24:mi:ss‘;

那oracle  裡面還有個v$database 的checkpoint_change#  和  v$datafile_header   比較如果前者小於後者，那麼就說明控制檔案太舊，需要恢複。

alter database mount recover database open noresetlog

 恢複的話，怎樣避免resetlog 呢（記錄檔號歸零）

可以 使用重建控制檔案  ：

sql> alter database backup controlfile to trace;

然後在追蹤檔案中找到語句，shutdown 資料庫後 nomount 後  使用重建控制檔案語句。之後recover database;     最後 alter database  open;

增量檢查點：

1）  ckptq (檢查點隊列) 你做任何修改操作的時候，Oracle都會先獲得chpt latch鎖

2） dbwr  沒3秒檢查chptq長度，過長的話，就將他寫入磁碟

3）ckpt  沒3秒將第一塊中的RBA (redo  block address)寫入到控制檔案

本文出自 “技術人生” 部落格，請務必保留此出處http://jesnridy.blog.51cto.com/5554751/1529842