物理寫的檢測：

為六枝等地區(qū)用戶提供了全套網頁設計制作服務，及六枝網站建設行業(yè)解決方案。主營業(yè)務為成都網站設計、成都網站制作、六枝網站設計，以傳統方式定制建設網站，并提供域名空間備案等一條龍服務，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

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      基本在百分之六，七十  算正常。

測試：

SYS@_connect_identifier>
SYS@_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行。
SYS@_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行。

SYS@_connect_identifier>select 259/272 from dual;
   259/272
----------
.952205882

那什么時候Oracle會做實例恢復呢？

其實Oracle是有一個標志位的當他為1 時打開就實例恢復，當他為0 時，那就不恢復嘍：

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

你可以先將數據庫mount狀態(tài)，然后查詢    

select  last_time, last_change# from v$DATAFILE;

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

判斷文件是否需要介質恢復：

v$datafile;   來自控制文件

v$datafile_header 來自數據文件頭。

col name for a40
select 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 hh34: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)寫入到控制文件