13518219792
物理写的检测：
为六枝等地区用户提供了全套网页设计制作服务，及六枝网站建设行业解决方案。主营业务为成都网站设计、成都网站制作、六枝网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
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状态，然后查询
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)写入到控制文件
