所有控制文件损坏的恢复--resetlogs方式

        此方式和 所有控制文件损坏的恢复--noresetlogs方式恢复时的前五个步骤是一样的。

1)先备份控制文件            
SQL> alter database backup controlfile to 'f:\lib\control.ctl' reuse;
数据库已更改。
2)生成跟踪文件。

SQL> alter database backup controlfile to trace;
数据库已更改。
SQL> @f:\sql\gettrace.sql---一个脚本,稍后会给出。
TRACE_FILE__NAME                                                               
--------------------------------------------------------------------------------
f:\app\yang\diag\rdbms\oracl\oracl\trace/oracl_ora_2572.trc       

3)关闭数据库,模拟控制文件全部损坏。

SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。

4)启动数据库。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area  535662592 bytes                                      
Fixed Size                  1334380 bytes                                      
Variable Size             134218644 bytes                                      
Database Buffers          394264576 bytes                                      
Redo Buffers                5844992 bytes                                      
ORA-00205: ORA-00205 error in identifying controlfile, check alert log for more info

alert 文件显示:

ALTER DATABASE   MOUNT
ORA-00210: cannot open the specified control file
ORA-00202: control file: 'F:\APP\YANG\ORADATA\ORACL\CONTROL03.CTL'
ORA-27041: unable to open file
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
ORA-00210: cannot open the specified control file
ORA-00202: control file: 'F:\APP\YANG\ORADATA\ORACL\CONTROL02.CTL'
ORA-27041: unable to open file
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
ORA-00210: cannot open the specified control file
ORA-00202: control file: 'F:\APP\YANG\ORADATA\ORACL\CONTROL01.CTL'
ORA-27041: unable to open file
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

5)启动到nomount状态。
SQL> startup nomount

6)执行创建控制文件的脚本
SQL> @f:\createctlreset.sql

控制文件已创建。

7)恢复数据库
SQL> recover database;
ORA-00283: 恢复会话因错误而取消
ORA-01610: 使用 BACKUP CONTROLFILE 选项的恢复必须已完成

SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 3230396 (在 05/28/2010 20:15:05 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\18_1_719709206.LOG
ORA-00280: 更改 3230396 (用于线程 1) 在序列 #18 中

指定日志: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: 无法打开归档日志 'F:\APP\YANG\ARCHIVE2\18_1_719709206.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

ORA-00308: 无法打开归档日志 'F:\APP\YANG\ARCHIVE2\18_1_719709206.LOG'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'F:\APP\YANG\ORADATA\ORACL\SYSTEM01.DBF'

SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 3230396 (在 05/28/2010 20:15:05 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\18_1_719709206.LOG
ORA-00280: 更改 3230396 (用于线程 1) 在序列 #18 中

指定日志: {=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'F:\APP\YANG\ORADATA\ORACL\SYSTEM01.DBF'
ORA-01112: 未启动介质恢复

SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 3230396 (在 05/28/2010 20:15:05 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\18_1_719709206.LOG
ORA-00280: 更改 3230396 (用于线程 1) 在序列 #18 中

指定日志: {=suggested | filename | AUTO | CANCEL}
f:\app\yang\oradata\oracl\redo01.log
ORA-00310: 归档日志包含序列 16; 要求序列 18
ORA-00334: 归档日志: 'F:\APP\YANG\ORADATA\ORACL\REDO01.LOG'

ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'F:\APP\YANG\ORADATA\ORACL\SYSTEM01.DBF'

SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 3230396 (在 05/28/2010 20:15:05 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\18_1_719709206.LOG
ORA-00280: 更改 3230396 (用于线程 1) 在序列 #18 中

指定日志: {=suggested | filename | AUTO | CANCEL}
f:\app\yang\oradate\oracl\redo02.log
ORA-00308: 无法打开归档日志 'f:\app\yang\oradate\oracl\redo02.log'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 3) 系统找不到指定的路径。

指定日志: {=suggested | filename | AUTO | CANCEL}
f:\app\yang\oradata\oracl\redo02.log
ORA-00310: 归档日志包含序列 17; 要求序列 18
ORA-00334: 归档日志: 'F:\APP\YANG\ORADATA\ORACL\REDO02.LOG'

ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'F:\APP\YANG\ORADATA\ORACL\SYSTEM01.DBF'

SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 3230396 (在 05/28/2010 20:15:05 生成) 对于线程 1 是必需的
ORA-00289: 建议: F:\APP\YANG\ARCHIVE2\18_1_719709206.LOG
ORA-00280: 更改 3230396 (用于线程 1) 在序列 #18 中

指定日志: {=suggested | filename | AUTO | CANCEL}
f:\app\yang\oradata\oracl\redo03.log
已应用的日志。
完成介质恢复。

SQL> select status from v$instance;

STATUS                                                                         
------------                                                                   
MOUNTED                                                                        

SQL> select current_scn from v$database;

CURRENT_SCN                                                                    
-----------                                                                    
          0                                                                    

SQL> alter database open;
alter database open
*
第 1 行出现错误:
ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项
SQL> alter database open resetlogs;
数据库已更改。
SQL> select current_scn from v$database;
CURRENT_SCN                                                                    
-----------                                                                    
    3231396                                                                    
SQL> select dbms_flashback.get_system_change_number from dual;

GET_SYSTEM_CHANGE_NUMBER                                                       
------------------------                                                       
                 3231397                                                       

 

附:

通过查询跟踪文件的脚本可以查询到相关的详细信息
SQL> SELECT a.VALUE||b.symbol||c.instance_name||'_ora_'||d.spid||'.trc' TRACE_FILE_NAME
  2  FROM (SELECT VALUE FROM v$parameter WHERE NAME='user_dump_dest') a,
  3       (SELECT SUBSTR(VALUE,-6,1) symbol FROM v$parameter WHERE NAME='user_dump_dest') b,
  4       (SELECT instance_name FROM v$instance) c,
  5       (SELECT spid FROM v$session s,v$process p,v$mystat m
  6        WHERE s.paddr=p.addr AND s.SID=m.SID AND m.statistic#=0) d
  7  /

createctlreset.sql脚本:

CREATE CONTROLFILE REUSE DATABASE "ORACL" RESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 292
LOGFILE
  GROUP 1 'F:\APP\YANG\ORADATA\ORACL\REDO01.LOG'  SIZE 50M,
  GROUP 2 'F:\APP\YANG\ORADATA\ORACL\REDO02.LOG'  SIZE 50M,
  GROUP 3 'F:\APP\YANG\ORADATA\ORACL\REDO03.LOG'  SIZE 50M
-- STANDBY LOGFILE
DATAFILE
  'F:\APP\YANG\ORADATA\ORACL\SYSTEM01.DBF',
  'F:\APP\YANG\ORADATA\ORACL\SYSAUX01.DBF',
  'F:\APP\YANG\ORADATA\ORACL\UNDOTBS01.DBF',
  'F:\APP\YANG\ORADATA\ORACL\USERS01.DBF',
  'F:\APP\YANG\ORADATA\ORACL\EXAMPLE01.DBF',
  'F:\APP\YANG\ORADATA\ORACL\TEST.DBF'
CHARACTER SET ZHS16GBK
;

小结:

要弄清楚resetlogs与noresetlogs的区别
norestlogs,控制文件的scn是来自当前日志的high scn,而resetlogs控制文件的scn是来自数据文件。
所有online redolog没有丢失,以noresetlogs选项打开数据库的情况下使用的。第二段则是在丢失了online redolog需要resetlogs的情况下使用。

时间: 2024-09-11 15:15:43

所有控制文件损坏的恢复--resetlogs方式的相关文章

所有控制文件损坏的恢复--noresetlogs方式

       所有控制文件损坏,或者人为的删除了所有的控制文件,通过控制文件的复制已经不能解决问题,这个时候需要重新建立控制文件.同时注意,alter database backup control file to trace可以产生一个控制文件的文本备份. 1)先备份控制文件             SQL> alter database backup controlfile to 'f:\lib\control.ctl' reuse;数据库已更改.2)生成跟踪文件. SQL> alter

单个控制文件损坏的恢复

        损坏单个控制文件是比较容易恢复的,因为数据库系统,控制文件都不是一个,而且所有的控制文件都互为镜像,只要拷贝一个好的控制文件替换坏的控制文件就可以.实验如下: 1) 查看系统的控制文件 SQL> select name from v$controlfile;NAME                                                                            ---------------------------------

oracle控制文件损坏的恢复过程记录

曾经做过一些测试,在启动或关闭数据库的情况下删除了控制文件,由于这个数据库只是我自己使用的测试数据库,当时也没有在意去恢复. 今天想启动这个数据库的时候就碰到了问题: [oracle@bjtest ~]$ sqlplus "/ as sysdba" SQL*Plus: Release9.2.0.4.0 - Production on星期三6月3 01:47:42 2009 Copyright (c) 1982, 2002, Oracle Corporation.  All rights

数据库文件损坏的恢复方法

  说明如下:SQL Server 2000文件损坏的恢复 1.建一个测试数据库test(数据库类型为完全). 2.建一个表,插入点记录. create table a(c1 varchar(2)) go insert into a values('aa') go insert into a values('bb') go 3.作完全备份,到文件test_1.bak. 4.在作一点修改. insert into a values('cc') go create table b(c1 int) g

oracle中exp dmp文件损坏怎么恢复

创建exp dmp文件并使用dd破坏  代码如下 复制代码 SQL> create table t_xifenfei as select * from dba_objects; Table created. SQL> select count(*) from t_xifenfei;   COUNT(*) ----------      90915 [oracle@localhost ~]$ exp chf/xifenfei@pdb1 file=/tmp/t_xifenfei.dmp table

Oracle控制文件损坏

现象是系统无法登录,任何用户都不行,怀疑数据库有问题,进入服务器,运行sqlplus username/password,无法进入数据库,提示输入用户名. 重启数据库,报控制文件control01.ctl有错,由于Oracle控制文件都是镜像的,因此先试着拷贝control03.ctl 覆盖control01.ctl,提示无法覆盖. 输入命令:sqlplus / as sysdba进入数据库,用命令shutdown immediate关闭数据库,然后将control01.ctl 重命名为cont

Oracle数据库数据文件损坏如何恢复

数据文件有时候因为某种原因会导致损坏而导致无法启动数据库,那如何恢复呢? 下面是一次模拟实验,如下 1. 首先创建一个表空间TEST,在创建一个表test在表空间test上 SQL> create tablespace test datafile '/u01/app/oracle/oradata/lhz/test01.dbf' size 10M; SQL>  create table test as  select * from dba_objects; Table created SQL&g

Oracle损坏控制文件的恢复方法

一: 损坏单个控制文件 损坏单个控制文件是比较容易恢复的,因为一般的数据库系统,控制文件都不是一个,而且所有的控制文件都互为镜相,只要拷贝一个好的控制文件替换坏的控制文件就可以了. 1.控制文件损坏,最典型的就是启动数据库出错,不能mount数据库 SQL>startup ORA-00205: error in identifying controlfile, check alert log for more info 查看报警日志文件,有如下信息 alter database  mount M

重建控制文件时resetlogs与noresetlogs的使用情况

重建控制文件时resetlogs与noresetlogs的使用情况 控制文件中记录着数据库的数据文件,日志文件,备份数据等信息,更为重要的,控制文件中还记录了数据库的检查点 和scn信息,这些信息在数据恢复的过程中将起到关键性作用. 一个正常运行的数据库,通常控制文件都存在多份镜像,这些镜像的内容是完全相同的,oracle缺省就创建多份控制 文件更说明了控制文件的重要: SQL> select name from v$controlfile; NAME ---------------------