oracle利用redo恢复
oracle媒介恢复（Media Recovery）
官方资料
https://docs.oracle.com/database/121/ADMQS/GUID-CBC5870F-2C9A-4F67-B5E9-D65049AD1E8E.htm#ADMQS09112
翻译如下：
如果还原存档的重做日志文件和数据文件，则必须先执行介质恢复，然后才能打开数据库。归档重做日志文件中未反映在数据文件中的任何数据库事务都将应用于数据文件，从而在打开数据库之前将它们置于事务一致状态。
介质恢复需要控制文件，数据文件（通常从备份恢复）以及包含自备份数据文件以来的更改的联机和归档重做日志文件。介质恢复通常用于从介质故障中恢复，例如丢失文件或磁盘，或用户错误，例如删除表的内容。
媒体恢复可以是完全恢复或时间点恢复。完全恢复可以应用于单个数据文件，表空间或整个数据库。时间点恢复适用于整个数据库（有时也适用于单个表空间，具有Oracle Recover Manager（RMAN）的自动化帮助）。
在完全恢复中，您可以还原备份数据文件，并将存档和联机重做日志文件中的所有更改应用于数据文件。数据库在发生故障时返回其状态，可以在不丢失数据的情况下打开。
在时间点恢复中，您将数据库返回到过去用户选择的时间的内容。您可以还原在目标时间之前创建的数据文件的备份以及从备份创建到目标时间的一整套归档重做日志文件。恢复将备份时间和目标时间之间的更改应用于数据文件。目标时间之后的所有更改都将被丢弃。
RMAN使您可以执行数据库的完整和时间点恢复。但是，本文档重点介绍完全恢复。
“执行用户定向恢复”
有关时间点恢复的更多详细信息，请参见“Oracle数据库备份和恢复用户指南”
案例分析实践
例1：数据库正常关闭后redo丢失
oracle在正常关闭过程中会将buffer cache中的脏块都写入数据文件，同时执行全面检查点，保证数据库一致性，所以关闭丢失redo日志，可以以resetlogs打开数据库不丢失数据。实际上reodo不丢失的话，oracle默认以noresetlogs打开数据库。
正常关闭数据库会同步校验各文件，使得重新启动的时候文件时间点一致并且不用进行崩溃恢复（Crash Recovery）
- 正常关闭数据库
- SQL> shutdown immediate
- Database closed.
- Database dismounted.
- ORACLE instance shut down.
- SQL> shutdown immediate
- 删除redo日志
- -rw-r----- 1 oracle oinstall 9748480 Jul 10 14:55 control01.ctl
- -rw-r----- 1 oracle oinstall 52429312 Jul 10 04:00 redo01.log
- -rw-r----- 1 oracle oinstall 52429312 Jul 10 11:00 redo02.log
- -rw-r----- 1 oracle oinstall 52429312 Jul 10 14:55 redo03.log
- -rw-r----- 1 oracle oinstall 660611072 Jul 10 14:55 sysaux01.dbf
- -rw-r----- 1 oracle oinstall 786440192 Jul 10 14:55 system01.dbf
- -rw-r----- 1 oracle oinstall 30416896 Jul 10 14:45 temp01.dbf
- -rw-r----- 1 oracle oinstall 94380032 Jul 10 14:55 undotbs01.dbf
- -rw-r----- 1 oracle oinstall 5251072 Jul 10 14:55 users01.dbf
- [oracle@zml-rhel6 orcl63]$ rm -f redo0*
- [oracle@zml-rhel6 orcl63]$ ll
- total 1523900
- -rw-r----- 1 oracle oinstall 9748480 Jul 10 14:55 control01.ctl
- -rw-r----- 1 oracle oinstall 660611072 Jul 10 14:55 sysaux01.dbf
- -rw-r----- 1 oracle oinstall 786440192 Jul 10 14:55 system01.dbf
- -rw-r----- 1 oracle oinstall 30416896 Jul 10 14:45 temp01.dbf
- -rw-r----- 1 oracle oinstall 94380032 Jul 10 14:55 undotbs01.dbf
- -rw-r----- 1 oracle oinstall 5251072 Jul 10 14:55 users01.dbf
- -rw-r----- 1 oracle oinstall 9748480 Jul 10 14:55 control01.ctl
- 启动数据库至MOUNT
- SQL> startup mount
- ORACLE instance started.
- Total System Global Area 4993982464 bytes
- Fixed Size 2261808 bytes
- Variable Size 1040190672 bytes
- Database Buffers 3942645760 bytes
- Redo Buffers 8884224 bytes
- Database mounted.
- SQL> startup mount
- 执行不完全恢复
- SQL> recover database until cancel;
- Media recovery complete.
- SQL> recover database until cancel;
- resetlogs打开数据库
- SQL> alter database open resetlogs;
- Database altered.
启动成功。resetlogs的解释参见：oracle的resetlogs机制浅析
linux系统中因为文件句柄的原因，即便在oracle open状态下删除redo日志，依然可以正常运行，同时也能正常关闭。如下例子说明：
open状态删除redo
- -rw-r----- 1 oracle oinstall 9748480 Jul 10 15:05 control01.ctl
- -rw-r----- 1 oracle oinstall 52429312 Jul 10 15:05 redo01.log
- -rw-r----- 1 oracle oinstall 52429312 Jul 10 15:02 redo02.log
- -rw-r----- 1 oracle oinstall 52429312 Jul 10 15:02 redo03.log
- -rw-r----- 1 oracle oinstall 660611072 Jul 10 15:02 sysaux01.dbf
- -rw-r----- 1 oracle oinstall 786440192 Jul 10 15:02 system01.dbf
- -rw-r----- 1 oracle oinstall 30416896 Jul 10 14:45 temp01.dbf
- -rw-r----- 1 oracle oinstall 94380032 Jul 10 15:02 undotbs01.dbf
- -rw-r----- 1 oracle oinstall 5251072 Jul 10 15:02 users01.dbf
- [oracle@zml-rhel6 orcl63]$ rm -f redo0*
- -rw-r----- 1 oracle oinstall 9748480 Jul 10 15:05 control01.ctl
- 查看占用redo文件的进程
- [oracle@zml-rhel6 orcl63]$ lsof|grep redo
- lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /root/.gvfs
- Output information may be incomplete.
- oracle 27082 oracle 258u REG 8,3 52429312 6684835 /u01/app/oracle/oradata/orcl63/redo01.log (deleted)
- oracle 27082 oracle 259u REG 8,3 52429312 6684838 /u01/app/oracle/oradata/orcl63/redo02.log (deleted)
- oracle 27082 oracle 260u REG 8,3 52429312 6684839 /u01/app/oracle/oradata/orcl63/redo03.log (deleted)
- [oracle@zml-rhel6 orcl63]$ ps -ef|grep 27082
- oracle 27082 1 0 14:59 ? 00:00:00 ora_lgwr_orcl63
- oracle 28808 23232 0 15:08 pts/2 00:00:00 grep 27082
可以看到redo log文件被系统标记为deleted，但是没有真正的删除，该文件正在被进程lgwr占用。linux的文件句柄会在应用程序关闭后才会释放文件，所以此期间即便删除了也可以正常关闭数据库。此后再以resetlogs启动便可。
- [oracle@zml-rhel6 orcl63]$ lsof|grep redo
例2：数据库异常关闭（kill or shutdown abort）的恢复
数据库异常关闭kill或shutdown abort，这个时候文件状态可能不一致。若检查点信息一致，则做崩溃恢复。若检查点信息不一致（正好在更新文件头）则需要做介质恢复。
以下演示redo不丢失和丢失的情况
一、redo不丢失
- shutdown abort关闭数据库
- SQL> shutdown abort
- ORACLE instance shut down.
- SQL> shutdown abort
- 启动到MOUNT
- SQL> startup mount
- ORACLE instance started.
- Total System Global Area 4993982464 bytes
- Fixed Size 2261808 bytes
- Variable Size 1040190672 bytes
- Database Buffers 3942645760 bytes
- Redo Buffers 8884224 bytes
- Database mounted.
- SQL> startup mount
- 查询控制文件中记录的数据文件的检查点信息以及END SCN信息
- SQL> select file#,checkpoint_change#,last_change# from v$datafile;
- FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
- ---------- ------------------ ------------
- 1 1602035
- 2 1602035
- 3 1602035
- 4 1602035
可以看到END SCN为NULL，说明数据库上次是异常关闭。
数据库正常运行过程中，该END SCN号始终为NULL。而当数据库正常关闭时，会进行完全检查点，并将检查点SCN号更新该字段。而崩溃时，Oracle还来不及更新该字段，则该字段仍然为NULL。当SMON进程发现该字段为空时，就知道实例在上次没有正常关闭，于是由SMON进程就开始进行实例恢复了。
- 打开数据库
- SQL> alter database open;
- Database altered.
查看此过程的告警日志：
（从告警日志红色标注内容可知，打开过程中，数据库进行了crash recovery，应用redo日志进行前滚和回滚操作）- Wed Jul 11 16:16:49 2018
- alter database open
- Beginning crash recovery of 1 threads
- parallel recovery started with 15 processes
- Started redo scan
- Completed redo scan
- read 175 KB redo, 97 data blocks need recovery
- Started redo application at
- Thread 1: logseq 9, block 782
- Recovery of Online Redo Log: Thread 1 Group 3 Seq 9 Reading mem 0
- Mem# 0: /u01/app/oracle/oradata/orcl63/redo03.log
- Completed redo application of 0.13MB
- Completed crash recovery at
- Thread 1: logseq 9, block 1133, scn 1622464
- 97 data blocks read, 97 data blocks written, 175 redo k-bytes read
- Wed Jul 11 16:16:49 2018
- Thread 1 advanced to log sequence 10 (thread open)
- Thread 1 opened at log sequence 10
- Current log# 1 seq# 10 mem# 0: /u01/app/oracle/oradata/orcl63/redo01.log
- Successful open of redo thread 1
- MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
- Wed Jul 11 16:16:49 2018
- SMON: enabling cache recovery
- [] Successfully onlined Undo Tablespace 2.
- Undo initialization finished serial:0 start:2869436558 end:2869436588 diff:30 (0 seconds)
- Verifying file header compatibility for 11g tablespace encryption..
- Verifying 11g file header compatibility for tablespace encryption completed
- SMON: enabling tx recovery
- Database Characterset is ZHS16GBK
- No Resource Manager plan active
- replication_dependency_tracking turned off (no async multimaster replication found)
- Starting background process QMNC
- Wed Jul 11 16:16:50 2018
- QMNC started with pid=36, OS id=16458
- Completed: alter database open
- Wed Jul 11 16:16:50 2018
- db_recovery_file_dest_size of 41820 MB is 0.00% used. This is a
- user-specified limit on the amount of space that will be used by this
- database for recovery-related files, and does not reflect the amount of
- space available in the underlying filesystem or ASM diskgroup.
- Wed Jul 11 16:16:50 2018
- Starting background process CJQ0
- Wed Jul 11 16:16:50 2018
- CJQ0 started with pid=38, OS id=16472
- ---------------------------------------------------------------------------------------------------------
关于应用redo日志进行前滚和回滚的说明如下：
二、redo丢失（数据库处于归档模式下，归档不丢失）
(归档没有用，数据库异常关闭，数据库未进行完全检查点，需要redo进行crash recovery，而异常关闭时，归档进行可能都没有来得及将redo日志刷到归档日志中。这种情况只能通过不完全恢复后，修改参数文件允许resetlogs启动，强制以resetlogs，即不一致启动，但是可能导致ora-00600。如果有ora-00600则要重装数据库了。)
- 归档模式下shutdown immediate关闭数据库
- SQL> archive log list
- Database log mode Archive Mode
- Automatic archival Enabled
- Archive destination USE_DB_RECOVERY_FILE_DEST
- Oldest online log sequence 8
- Next log sequence to archive 10
- Current log sequence 10
- SQL> shutdown abort
- ORACLE instance shut down.
- SQL> archive log list
- 删除redo日志
- [oracle@zml-rhel6 orcl63]$ ls -rlt
- total 1698848
- -rw-r----- 1 oracle oinstall 52429312 Jul 11 16:59 redo03.log
- -rw-r----- 1 oracle oinstall 52429312 Jul 11 16:59 redo02.log
- -rw-r----- 1 oracle oinstall 94380032 Jul 11 16:59 undotbs01.dbf
- -rw-r----- 1 oracle oinstall 786440192 Jul 11 16:59 system01.dbf
- -rw-r----- 1 oracle oinstall 681582592 Jul 11 16:59 sysaux01.dbf
- -rw-r----- 1 oracle oinstall 5251072 Jul 11 16:59 users01.dbf
- -rw-r----- 1 oracle oinstall 30416896 Jul 11 16:59 temp01.dbf
- -rw-r----- 1 oracle oinstall 52429312 Jul 11 17:00 redo01.log
- -rw-r----- 1 oracle oinstall 9748480 Jul 11 17:00 control01.ctl
- [oracle@zml-rhel6 orcl63]$ rm -f redo0*
- [oracle@zml-rhel6 orcl63]$ ls -rlt
- 启动到mount
- SQL> startup mount
- ORACLE instance started.
- Total System Global Area 4993982464 bytes
- Fixed Size 2261808 bytes
- Variable Size 1040190672 bytes
- Database Buffers 3942645760 bytes
- Redo Buffers 8884224 bytes
- Database mounted.
- SQL> startup mount
- 查询控制文件中记录的数据文件的检查点信息以及END SCN信息
- SQL> select file#,checkpoint_change#,last_change# from v$datafile;
- FILE# CHECKPOINT_CHANGE# LAST_CHANGE#
- ---------- ------------------ ------------
- 1 1627660
- 2 1627660
- 3 1627660
- 4 1627660
LAST_CHANGE#为NULL，异常关闭
- 打开数据库
参考资料
https://blog.csdn.net/liaocongyuan1314/article/details/50847529
总结：只有current和active状态的redo日志丢失或损坏，且数据库异常关闭，如kill或者abort，才会丢失数据！其他都可以进行恢复。
oracle利用redo恢复的更多相关文章
- ORACLE 利用SCN恢复误delete的表
--kg是误删除的表 SQL> select count(*) from kg; COUNT(*) ---------- 820861 SQL> delete from kg; ...
- 【转】ORACLE的REDO与UNDO
一.什么是redo?redo:oracle在在线或者归档重做日志文件中的记录的信息,外以出现失败时可以利用这些数据来"重放"事务.每个oracle数据都至少有二个在线重做日志组,每 ...
- oracle 利用flashback将备库激活为read wirte(10g 及上)
oracle 利用flashback将备库激活为read wirte(10g 及上) 环境: OS: CENTOS 6.5 X64 DB: ORACLE 10.2.0.5 主库操作: SQL> ...
- 利用RMAN恢复整个数据库
利用RMAN恢复整个数据库案例一 适合场合:恢复的目录一致,同时备份的过程中有归档日志 恢复的数据库目录和down机的数据库一致,还有一个就是RMAN备份的时候已经备份了归档日志. 备份脚本: run ...
- rman恢复方案和oracle异机恢复
这篇文章主要介绍了rman恢复方案和oracle异机恢复,需要的朋友可以参考下 注:①恢复的前提是已经做好备份②完全恢复数据库是数据库遇到故障,在恢复时候没有丢失任何已经提交事物数据的恢复不完全恢复数 ...
- oracle 11g 数据库恢复技术 ---01 重做日志
一 redo log Oracle数据库中的三大核心文件分别是数据文件(data file).重做日志(redo log)和控制文件(control file).数据文件保证了数据库的持久性,是保存修 ...
- Oracle的实例恢复解析
在数据库服务器异常断电重启后,数据库会进行实例恢复,那么实例恢复的过程中Oracle做了什么操作呢?参考官网在这里做一下解释,菜鸟水平有限,欢迎勘正. 首先说下实例恢复的定义: Instance re ...
- 删除Oracle Online Redo 测试
删除Oracle Online Redo 测试 SQL> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES BLOCKS ...
- 11g RAC 如何备份OCR，利用备份恢复OCR，ocrdump
OCR备份 OCR的备份有2种方式,自动备份和手工备份. 自动备份策略: Oracle Clusterware 每隔4小时,CRSD 进程会自动对OCR 进行一次备份,在任意时刻,oracle 总会保 ...
随机推荐
- ubuntu 16.04 LTS - 谷歌拼音输入法
https://blog.csdn.net/chengyq116/article/details/78638249 1. installation1.1 汉语语言包 sudo apt-get inst ...
- 怎么在Vue的某个组件中根据组件tag标签名获取到对应的VueComponent实例呢
1.以前玩omi框架的时候,有Omi.get方法来获取实例, ...好久没玩了,忘了.反正很喜欢该方法.2.如今想在vue里面怎么能够快速获取到对应组件标签名的的实例呢?3.文档也看过,似乎脑海中没啥 ...
- go笔记-pprof使用
go tool pprof http://localhost:6060/debug/pprof/profile go tool pprof http://localhost:6060/debug/pp ...
- Asp.Net Core使用NLog+Mysql的几个小问题
项目中使用NLog记录日志,很好用,之前一直放在文本文件中,准备放到db中,方便查询. 项目使用了Mysql,所以日志也放到Mysql上,安装NLog不用说,接着你需要安装Mysql.Data安装包: ...
- 源码编译安装php7
现在新启的项目都是采用php7了,无奈很多Linux发行版中还是php5 第三方php7源在自己本机上用用到无所谓,放到正式环境上还是有点不放心 其实编译安装也就几分钟,麻烦的是各种依赖 先删除老版本 ...
- python之旅九【第九篇】socket
什么是socket 建立网络通信连接至少要一对端口号(socket).socket本质是编程接口(API),对TCP/IP的封装,TCP/IP也要提供可供程序员做网络开发所用的接口,这就是Socket ...
- Codeforces #381(div2)
A.题目:http://codeforces.com/contest/740/problem/A 题意:现有n本书,买一本书需要花a元,两本书b元,三本书c元,问买够书是4的倍数所需要的最小花费 思路 ...
- nginx 返回数据被截断
nignx 代理 buffer proxy_buffers 16 512k; proxy_buffer_size 512k; fastcgi buffer fastcgi_buffers 4 64 ...
- Access-Control-Allow-Origin跨域请求处理
今天在看新项目的时候,发现很多的 Controller 中都有一个 response.setHeader("Access-Control-Allow-Origin"," ...
- Java入门：基础算法之二进制转换为十进制
Java有两种方法可以将二进制数转换为十进制数: 1)使用Integer类的Integer.parseInt()方法. 2)自己编写转换逻辑. 方法1:使用Integer.parseInt()实现二进 ...