043-3 不完全恢复 REDO损坏恢复

最新推荐文章于 2022-09-09 17:40:45 发布
最新推荐文章于 2022-09-09 17:40:45 发布
阅读量103 收藏
点赞数

--**************
模拟表误删的恢复
--**************
RMAN> delete backup;
RMAN> backup database;  --全库备份

Select * From V$LOG;          --GROUP# 3 CURRENT
Alter System Switch Logfile;  --产生6次归档日志

Select current_scn From v$database;  --当前SCN 656943
Drop Table  T_SCN;                   --误删除的表
--删除之后，还执行创建表，插入数据等操作
Create Table t3(Id Int) Tablespace users;
Insert Into t3 Values(1);

Alter System Switch Logfile;  --产生归档日志

--*************************************************
不完全恢复 恢复到过去一个SCN 该SCN后的数据会丢失
--*************************************************
RMAN> shutdown Immediate
RMAN> startup Mount
RMAN> restore database;
SQL> select file#,checkpoint_change# from v$datafile;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1             657220
         2             657220
         3             657220
         4             657220
         5             657220
         6             657220
         7             657220

已选择7行。

SQL> select file#,checkpoint_change# from v$datafile_header;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1             654699
         2             654699
         3             654699
         4             654699
         5             654699
         6             654699
         7             654699

SQL> recover database until change 656943;
ORA-00279: 更改 654699 (在 02/11/2014 14:15:40 生成) 对于线程 1 是必需的
ORA-00289: 建议: C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_42_%U_.ARC
ORA-00280: 更改 654699 (用于线程 1) 在序列 #42 中

指定日志: {=suggested | filename | AUTO | CANCEL}
Auto

Select Sequence#,first_change#,next_change# From v$archived_log;  -- scn 656943 在sequence# 48中

SQL> select file#,checkpoint_change# from v$datafile_header;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1             656949
         2             656949
         3             656949
         4             656949
         5             656949
         6             656949
         7             656949
SQL> alter database open resetlogs;  --打开不完全恢复后的数据库

数据库已更改。

SQL> select * from t_scn;            --表T_SCN恢复

        ID        SCN
---------- ----------
         1     608386
         1     609310
         2     609320
         3     610263
         4     611165
         5     611210
         6     611345

已选择7行。

SQL> select * from t3;               --T3没有恢复
select * from t3
              *
第 1 行出现错误:
ORA-00942: 表或视图不存在
--*******************************T3表无法恢复，只适合为了找回T_SCN表，另搭建一套环境恢复
--*****************************
被迫的不完全恢复 如REDO日志文件current状态的损坏
--*****************************
Select * From t_scn

Alter System Switch Logfile;  --产生2次归档日志

Insert Into t_scn Values(11,11);

Alter System Switch Logfile;  --产生2次归档日志

Select * From v$log           --group# = 2,seq=5 current
Insert Into t_scn Values(100,100);

--****模拟日志损坏
SQL> shutdown immediate
删除group# = 2 第二组日志 REDO02.Log
SQL> startup
ORACLE 例程已经启动。

Total System Global Area  272629760 bytes
Fixed Size                  1248476 bytes
Variable Size              79692580 bytes
Database Buffers          184549376 bytes
Redo Buffers                7139328 bytes
数据库装载完毕。
ORA-00313: 无法打开日志组 2 (用于线程 1) 的成员
ORA-00312: 联机日志 2 线程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TESTDB\REDO02.LOG'
--**此时可以强制打开，但是可能会造成数据不一直，oracle建议此时进行不完全恢复

RMAN> Restore Database;
RMAN> recover database;
/*
archive log thread 1 sequence 42 is already on disk as file C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_42_9HMP2ZWS_.AR
archive log thread 1 sequence 43 is already on disk as file C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_43_9HMP31F5_.AR
archive log thread 1 sequence 44 is already on disk as file C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_44_9HMP36WS_.AR
archive log thread 1 sequence 45 is already on disk as file C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_45_9HMP3CLK_.AR
archive log thread 1 sequence 46 is already on disk as file C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_46_9HMP3DTV_.AR
archive log thread 1 sequence 47 is already on disk as file C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_47_9HMP3RGN_.AR
archive log thread 1 sequence 48 is already on disk as file C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_48_9HMPBTZ7_.AR
archive log thread 1 sequence 1 is already on disk as file C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_1_9HMS50D6_.ARC
archive log thread 1 sequence 2 is already on disk as file C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_2_9HMS513F_.ARC
archive log thread 1 sequence 3 is already on disk as file C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_3_9HMS7XNJ_.ARC
archive log thread 1 sequence 4 is already on disk as file C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_4_9HMS7YDP_.ARC
archive log filename=C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_42_9HMP2ZWS_.ARC thread=1 sequence=42
archive log filename=C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_43_9HMP31F5_.ARC thread=1 sequence=43
archive log filename=C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_44_9HMP36WS_.ARC thread=1 sequence=44
archive log filename=C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_45_9HMP3CLK_.ARC thread=1 sequence=45
archive log filename=C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_46_9HMP3DTV_.ARC thread=1 sequence=46
archive log filename=C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_47_9HMP3RGN_.ARC thread=1 sequence=47
archive log filename=C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_48_9HMPBTZ7_.ARC thread=1 sequence=48
archive log filename=C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_1_9HMS50D6_.ARC thread=1 sequence=1
archive log filename=C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2014_02_11\O1_MF_1_2_9HMS513F_.ARC thread=1 sequence=2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/11/2014 17:27:21
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\TESTDB\ARCHIVELOG\2
ORA-00283: recovery session canceled due to errors
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TESTDB\REDO02.LOG'
ORA-27041: unable to open file
*/

SQL> select file#,checkpoint_change# from v$datafile;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1             658211
         2             658211
         3             658211
         4             658211
         5             658211
         6             658211
         7             658211

已选择7行。

SQL> select file#,checkpoint_change# from v$datafile_header;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1             658093
         2             658093
         3             658093
         4             658093
         5             658093
         6             658093
         7             658093                               --Select Sequence#,first_change#,next_change# From V$ARCHIVED_LOG   --最大的NEXT_CHANGE# = 658093

已选择7行。

--**SCN = 658093 后面的日志丢失，此时无法打开数据库，使用resetlogs尝试
SQL> alter database open resetlogs;
alter database open resetlogs
*
第 1 行出现错误:
ORA-01139: RESETLOGS 选项仅在不完全数据库恢复后有效    --***必须在recover database时候使用until，
--如recover database until change 658093;或者使用until cancel

RMAN> restore database;
recover database Until Cancel     --部分恢复，直到输入cancel   在SQL中进行恢复
Auto
Cancel
SQL> alter database open Resetlogs;
数据库已更改。
--****启动数据库成功
Select * From t_scn          --11 11恢复成功 100 100丢失

--**************************
不完全恢复 模拟INACTIVE的日志损坏
--**************************
Shutdown Immediate
Select * From v$log   --group# 1 current   删除第三组日志
startup
/*
SQL> startup
ORACLE 例程已经启动。

Total System Global Area  272629760 bytes
Fixed Size                  1248476 bytes
Variable Size              79692580 bytes
Database Buffers          184549376 bytes
Redo Buffers                7139328 bytes
数据库装载完毕。
ORA-00313: 无法打开日志组 3 (用于线程 1) 的成员
ORA-00312: 联机日志 3 线程 1:
'C:\ORACLE\PRODUCT\10.2.0\ORADATA\TESTDB\REDO03.LOG'
*/
SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------------
         1          1          5   52428800          1 NO  CURRENT                 658618 11-2月 -14
         3          1          3   52428800          1 YES INACTIVE                658613 11-2月 -14
         2          1          4   52428800          1 YES INACTIVE                658615 11-2月 -14

SQL> alter database drop logfile group 3;            --将第三组日志从控制文件中删除
SQL> alter database open;

数据库已更改。

SQL> select * from v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- --------------
         1          1          5   52428800          1 YES INACTIVE                658618 11-2月 -14
         2          1          6   52428800          1 NO  CURRENT                 658909 11-2月 -14

Alter Database Add Logfile Group 3 'C:\oracle\product\10.2.0\oradata\testDB\REDO03.LOG' Size 50M;    --重新创建REDO日志，REDO日志大小最好相同，方便维护

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15810196/viewspace-1146677/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/15810196/viewspace-1146677/

ctxylong2013
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Oracle备份恢复-redo文件损坏的各种场景恢复专题.docx
07-03
Oracle备份恢复-redo文件损坏的各种场景恢复专题：redo文件损坏涉及到多种多样场景，具体场景可以分四大部分： 1、按照redo的状态可以分为current、active和inactive； 2、按照数据库归档模式可以分为归档和非归档；...
数据库强制open后业务用户ora-00600[2662]错误解决
还不算晕的专栏
01-27 353
用户做异机RMAN恢复，recover时因归档不够，报ORA-01547,如下： ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1:...
oracle 06502 解决,【故障解决】ORA-06502错误解决
weixin_33267830的博客
04-12 5653
【故障解决】ORA-06502: PL/SQL: numeric or value error: character string buffer too small一.1BLOG文档结构图 一.2前言部分一.2.1导读和注意事项各位技术爱好者，看完本文后，你可以掌握如下的技能，也可以学到一些其它你所不知道的知识，~O(∩_∩)O~：① EXPDP和IMPDP基于scn的导出② ora-06502的...
使用redo.log完全恢复数据库
谭博文DBA的天空——专栏
02-02 3956
场景：之前该数据库进行过一次完全恢复，应有是有如下提示的，然后又使用了resetlogs打开过数据库，但未做日志切换（alter system checkpoint/alter system switch logfile）. 导致关库的时候提示：ORA-00338/ORA-00312 RMAN> recover database; 启动 recover 于 01-2月 -16 使用
一次current redo 损坏的解决过程， 没有利用备份，只能不完全恢复。
cudang7414的博客
03-19 140
Microsoft Windows 2000 [Version 5.00.2195](C) 版权所有 1985-2000 Microsoft Corp.C:Documents and SettingsAdministrator&...
异机rman数据不完全恢复
weixin_34342578的博客
06-13 315
源库：Red Hat Enterprise Linux Server release 5.5 (Tikanga) 64bit + ORACLE V11.2.0.4.0 + DG + RAC 目标库：Red Hat Enterprise Linux Server release 5.8 (Catthage) 64bit + ORACLE V11.2.0.4.0 1、在目标库，安装好相同版本...
ORACLE RMAN备份恢复指南
07-26
包含RMAN全量、增量、备份、恢复以及数据丢失、控制文件丢失、参数文件丢失、密码文件丢失、redo文件丢失、表空间损坏相关操作。
RMAN测试演练即讲解
12-28
6、 模拟redolog file恢复（其实下面操作在sqlplus里面，不在rman执行） （1） shutdown immediate; （2） startup mount; （3） recover database until cancel; （4） alter database resetlog;
oracle_10g的闪回设置
07-20
startup 时报错误信息 ORA-16038: 日志 2 序列号 225 无法归档 ORA-19809: 超出了恢复文件数的限制 ORA-00312: 联机日志 2 线程 1: 'O:\ORACLE\ORADATA\ORACLE10\REDO02.LOG' 分析为日志损坏
深入解析OracleDBA入门进阶与诊断案例 3/4
03-10
　8.19　诊断案例之二：回滚段损坏的恢复　 第9章　等待事件　 　9.1　等待事件的源起　 　9.2　从等待发现瓶颈　 　9.3　Oracle 10g的增强　 　9.4　顶级等待事件　 　9.5　重要等待事件　 第10章　性能诊断与SQL...
重建redo-oracle数据库恢复
porly的专栏
08-26 1310
原文地址：http://www.itpub.net/viewthread.php?tid=175996   损坏非当前联机日志 大家都清楚，联机日志分为当前联机日志和非当前联机日志，非当前联机日志的损坏是比较简单的，一般通过clear命令就可以解决问题。 1、启动数据库，遇到ORA-00312 or ORA-00313错误，如 ORA-00313: open failed for mem
Redo 损坏彻底解决
人生三十重学艺
05-30 3416
Redo 损坏彻底解决 [转]几天在看隐含参数，为了验证一下，便加了一大堆进行，结果。。。。居然导致Redo损坏：ORA-16038: log 3 sequence# 72 cannot be archivedORA-00354: corrupt redo log block headerORA-00312: online log 3 thread 1: D:/ORACLE/ORADATA/
oracle数据库异常关闭之后恢复
liujinzs的博客
12-24 940
oracle服务器重启之后无法启动，startup时报 [code="java"] ORA-03113: 通信通道的文件结尾 shutdown 时报：ORA-27101: shared memory realm does not exist[/code] 解决办法参见博文：[url]http://soulful.blog.51cto.com/468033/389570/[/url] 登陆...
备份与恢复（Redo log 恢复篇）
cqrw65623的博客
07-18 877
备份与恢复（Redo log 恢复篇） 环境：oracle 版本10.2.0.1 无归档模式下 系统：contes5.6 总结： ...
Oracle current redo.log出现坏块后的不完全恢复案例一则
weixin_30762087的博客
09-22 242
1异常出现 8月30日下午2时左右，接同事电话，说数据库异常宕机了，现在启动不了。 2初步分析 　　我让现场把alert.log发过来，先看看是什么问题。 关于ORA-00353和ORA-00334,先查一查是什么错误： 　　根据上述信息可知，30日10点39分，在进行crash recovery时，REDO03.LOG文件的block＝375...
同时丢失参数文件、控制文件及redo log file的不完全恢复（有数据文件的热备和归档）
长期深耕于云计算、大数据、数据库领域！
06-14 3502
同时丢失参数文件、控制文件及redo log file的不完全恢复（有数据文件的热备和归档）
ORA-01033问题：定位redo日志进行不完全恢复启库实战案例
狗剩儿的记忆博客
09-09 400
再以上截图中，有个信息特别重要：就是ORA-00280中 change xxxxxx 和 sequence #815,这类型的故障,一般是由于缺少日志(比如数据库非归档模式,或者归档日志丢失),导致某些文件无法正常online。完成以上操作后，我们就可以进行open数据库，但是这里要注意的是我们在不完全恢复后，日志序列号中断，重新open数据库的话就需要重置日志序列。recover database的原理是数据库使用控制文件的scn作为恢复的终点，将数据文件block恢复到控制文件所记录的scn为止。
不完全恢复-redo损坏
hugh 's Oracle 10g blog
11-04 933
--不完全恢复-redo损坏 --逻辑备份 1. exp/imp 2. expdp/impdp 3. sqlldr 恢复 1. 完全恢复 --能恢复到失败那一刻 2. 不完全恢复 --主动，被动的，不能恢复到终点 --=== 恢复的起点 select file#,checkpoint_change# from v$datafile_header 1578538 恢复的终点 select
基于go开发的waf，包括网关和WAF两部分；.zip
最新发布
05-23
Go语言（也称为Golang）是由Google开发的一种静态强类型、编译型的编程语言。它旨在成为一门简单、高效、安全和并发的编程语言，特别适用于构建高性能的服务器和分布式系统。以下是Go语言的一些主要特点和优势： 简洁性：Go语言的语法简单直观，易于学习和使用。它避免了复杂的语法特性，如继承、重载等，转而采用组合和接口来实现代码的复用和扩展。 高性能：Go语言具有出色的性能，可以媲美C和C++。它使用静态类型系统和编译型语言的优势，能够生成高效的机器码。 并发性：Go语言内置了对并发的支持，通过轻量级的goroutine和channel机制，可以轻松实现并发编程。这使得Go语言在构建高性能的服务器和分布式系统时具有天然的优势。 安全性：Go语言具有强大的类型系统和内存管理机制，能够减少运行时错误和内存泄漏等问题。它还支持编译时检查，可以在编译阶段就发现潜在的问题。 标准库：Go语言的标准库非常丰富，包含了大量的实用功能和工具，如网络编程、文件操作、加密解密等。这使得开发者可以更加专注于业务逻辑的实现，而无需花费太多时间在底层功能的实现上。 跨平台：Go语言支持多种操作系统和平台，包括Windows、Linux、macOS等。它使用统一的构建系统（如Go Modules），可以轻松地跨平台编译和运行代码。 开源和社区支持：Go语言是开源的，具有庞大的社区支持和丰富的资源。开发者可以通过社区获取帮助、分享经验和学习资料。 总之，Go语言是一种简单、高效、安全、并发的编程语言，特别适用于构建高性能的服务器和分布式系统。如果你正在寻找一种易于学习和使用的编程语言，并且需要处理大量的并发请求和数据，那么Go语言可能是一个不错的选择。
Innobackex 中的--apply-log --redo-only的使用区别
07-17
--apply-log 和 --redo-only 是 Innobackex 工具中用于恢复 InnoDB 数据库备份的选项。 --apply-log 选项用于应用日志文件到备份数据中，以确保数据的一致性。它会将备份数据与 InnoDB 存储引擎的日志文件进行合并...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值