物理写的判断 & 介质恢复 & 实例恢复 & 增量检查点

物理写的检测:

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

 physical writes 119             //我一共写了多少块

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

104 DBWR checkpoint buffers written 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 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 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)写入到控制文件



物理写的判断 & 介质恢复 & 实例恢复 & 增量检查点,布布扣,bubuko.com

物理写的判断 & 介质恢复 & 实例恢复 & 增量检查点

时间: 2024-10-13 09:23:03

物理写的判断 & 介质恢复 & 实例恢复 & 增量检查点的相关文章

Oracle 实例恢复

-======================= -- Oracle 实例恢复 --======================= 一.Oracle实例失败 Oracle实例失败多为实例非一致性关闭所致,通常称为崩溃(crash).实例失败的结果等同于shutdown abort. 实例失败的原因 电源负载故障 硬件故障 后台进程失败 异常关闭数据库 实例失败后的状况 数据库可能丢失已提交的事务以及存储了未提交的事务,导致数据库出现不一致的情况 解决方案 使用startup 重新启动实例.实例实

oracle介质恢复和实例恢复的异同

1.概念 ? ? REDO LOG是Oracle为确保已经提交的事务不会丢失而建立的一个机制.实际上REDO LOG的存在是为两种场景准备的: 实例恢复(INSTANCE RECOVERY): 介质恢复(MEDIA RECOVERY). ? ? 实例恢复的目的是在数据库发生故障时,确保BUFFER CACHE中的数据不会丢失,不会造成数据库的不一致: 介质恢复的目的是当数据文件发生故障时,能够恢复数据. 虽然这两种恢复使用的机制类似的,但是这两种恢复也有着十分本质的不同,这一点也是很多DBA经常

关于oracle实例恢复的前滚和回滚的理解

关于oracle实例恢复的一些理解,一直都有误区,今天通过查看相关资料和与同学探讨,发觉了自己的错误,探讨结果如下: 实例恢复:当数据库非正常关闭的时候(断电或者shu  abort等等非一致性关闭),当你从新启动数据库的时候,数据库相关进程自动进行实例恢复,无须人工干预. 什么时候需要实例恢复 在shutdown normal or shutdown immediate下,也就是所谓的clean shutdown,checkpoint也会自动触发,并且把SCN纪录写回. 当发生checkpoi

【Android】11.2 通过重写对应的方法保存和恢复实例的状态

分类:C#.Android.VS2015: 创建日期:2016-02-21 一.简介 通过重写(也叫回调)对应的方法来管理Activity的生命周期,比如用户旋转屏幕时应用程序要能自动保存和恢复实例的状态,这对于开发一个健壮而又灵活的应用程序而言至关重要. 1.本节要点 一旦真正理解了Activity的生命周期,就可以轻松自如地通过C#代码去控制它了.这一节我们主要学习如何用Boundle存储简单类型的数据(比如int.double.string.bool.--等). 当一个Activity停止

SQL Server的实例恢复解析

同Oracle一样,SQL Server在非一致性关闭的时候也会进行实例恢复(Instance Recovery),本文根据stack overflow的文章介绍一些SQL Server实例恢复的知识. 原文链接:https://stackoverflow.com/questions/41932735/sql-server-instance-recovery 关于Oracle的实例恢复参考之前的博文:http://www.cnblogs.com/leohahah/p/6973600.html 首

Oracle实例恢复阶段以及flashback简介

实例恢复阶段: 1.数据文件不同步 2.前滚(重做redo) 3.文件中的提交和未提交数据 4.打开数据库 5.回退(还原undo) 6.文件中的提交数据 优化实例恢复:(加快脏数据的写) 使用 MTTR fast_start_mttr_target (建议不要设置/增加系统负担) db_writer_pricesses(DBWn的进程) flashback; 位置由 DB_RECOVERY_FILE_DEST 参数指定 大小由 DB_RECOVERY_FILE_DEST_SIZE 参数指定 足

ORA-00265: 要求实例恢复, 无法设置 ARCHIVELOG 模式解决办法

解决了这个问题,方法如下: 从 Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options 断开 C:\Documents and Settings\yc>sqlplus sys/abcd as sysdba SQL*Plus: Release 10.2.0.1.0 - Production on 星期一 12月

Oracle数据块损坏的恢复实例

测试环境:11.2.0.4 1.构建数据块损坏的测试环境 2.有备份:常规恢复坏块 3.无备份:跳过坏块 1.构建数据块损坏的测试环境 1.1 创建测试表 --Create Table t_test conn jingyu/jingyu drop table t_test purge; create table t_test (id number, name char(2000)); --Insert data insert into t_test values(1, 'alfred 1');

实例恢复与Oracle的SCN

简单理解oracle的SCN就是自己的时间功能,好比linux系统自己的时间一样,oracle它也有自己的一套时间. 在你干净的关闭数据库时shutdown immediate或者使用alter system checkpoint都会把SCN的值写入4个位置,其中有3个位于controlfile内,还有1个位于datafile header内 controlfile里面的三个SCN分别是:1.system checkpoint SCN  2.datafile checkpoint SCN  3.