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

使用BMR功能快速修复数据坏块Oracle提供了许多方法检测和修补数据库中的数据坏块，而BMR就是其中之一，其它方法还包括Analyze语句、dbv命令以及DBMS_REPAIR等。

DBMS_REPAIR包仅仅对transaction层和data层的坏块（即逻辑损坏的块）起作用，对物理上损坏的块，在它被读到缓冲区中时就已被标识出来了，而DBMS_REPAIR会忽略所有被标识为坏了的块。

要快速修复物理损坏的数据块，可以通过BMR功能来完成。

块介质恢复的最大好处在于可以降低平均恢复时间(MTTR) ，因为介质恢复的最小可恢复单位从数据文件缩小到块。

如果已知数据库中只有少量的块需要介质恢复，则最有效的方式是有选择地进行还原，只恢复需要恢复的块。

而且该技术提高了介质恢复期间的数据可用性，因为在数据恢复期间，数据文件可以保持联机状态，只有正在恢复的数据块是不可访问的。

使用BMR之前，需要对保护的数据进行备份。

在执行BMR时，只需要简单地执行blockrecover 命令就可以了，例如编号为4的数据文件的数据块385发生了损坏，修复时可以如下：RMAN> BLOCKRECOVER DATAFILE 4 BLOCK 385;下面通过一个实例来讨论BMR的使用。

一、建立测试环境首先建立一个测试用的表T1，T1的结构如下：SQL> desc t1Name Null? Type--------------------------------------------------- -------- ---------------------COL1 NUMBERCOL2 CHAR(1000)将COL2的数据类型设置为CHAR(1000)只是为了让每个行记录占用的空间更多，这样我们可以使用较少的记录填充多个数据块。

为该测试表填入一部分测试数据：SQL>insert into t1 select rownum,rownum from dual connect by rownum<=20;上述语句使用了层次查询语句。

损坏数据文件的恢复方法一：非归档模式下丢失或者损坏数据文件A：OS备份恢复方案在非归档模式下损坏或者丢失数据文件，如果有相应的备份，在一定程度上是可以恢复的，但是如果oracle过多的读写操作记录信息而导致redo重写的时候，恢复就会停滞，非归档下系统能自动恢复的仅仅限于redo中存在的记录。

可以成功恢复案例：SQL> startupORACLE instance started.Total System Global Area 235999352 bytesFixed Size 450680 bytesVariable Size 201326592 bytesDatabase Buffers 33554432 bytesRedo Buffers 667648 bytesDatabase mounted.Database openedSQL> create table test(a int);Table created.SQL> insert into test values(1);1 row created.SQL> /1 row created.SQL> /1 row created.SQL> /1 row created.SQL> commit;Commit complete.SQL> exit;[oracle@www oradata]$ cd cicro/[oracle@www cicro]$ lscontrol01.ctl cwmlite01.dbf indx01.dbf redo02.log temp01.dbfusers01.dbf control02.ctl drsys01.dbf odm01.dbf redo03.logtools01.dbf xdb01.dbf control03.ctl example01.dbf redo01.log system01.dbf undotbs01.dbf[oracle@www cicro]$ pwd/opt/oracle/oradata/cicro[oracle@www cicro]$ sqlplus "/as sysdba"SQL> shutdown immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL>exit;[oracle@www cicro]$ cp ./*.dbf ../[oracle@www cicro]$ sqlplus "/as sysdba"SQL*Plus: Release 9.2.0.1.0 - Production on Tue Jul 25 19:44:31 2006 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Connected to:Oracle9i Release 9.2.0.1.0 - ProductionJServer Release 9.2.0.1.0 – ProductionConnected to an idle instance.SQL> startupORACLE instance started.Total System Global Area 235999352 bytesFixed Size 450680 bytesVariable Size 201326592 bytesDatabase Buffers 33554432 bytesRedo Buffers 667648 bytesDatabase mounted.Database opened.SQL> insert into test values(3333);1 row created.SQL> /1 row created.SQL> /1 row created.SQL> /1 row created.SQL> commit;Commit complete.SQL> select * from test;A----------1113333333333338 rows selected.SQL> shutdown immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL>exit;[oracle@www cicro]$ rm –rf ./*.dbf[oracle@www cicro]$ sqlplus "/as sysdba"Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.Connected to an idle instance.SQL> startupORACLE instance started.Total System Global Area 235999352 bytesFixed Size 450680 bytes技术社区Variable Size 201326592 bytesDatabase Buffers 33554432 bytesRedo Buffers 667648 bytesDatabase mounted.ORA-01157: cannot identify/lock data file 1 - see DBWR trace fileORA-01110: data file 1: '/opt/oracle/oradata/cicro/system01.dbf'SQL> quit[oracle@www cicro]$ mv ../*.dbf .[oracle@www cicro]$ lscontrol01.ctl cwmlite01.dbf indx01.dbf redo02.log temp01.dbf users01.dbf control02.ctl drsys01.dbf odm01.dbf redo03.log tools01.dbf xdb01.dbf control03.ctl example01.dbf redo01.log system01.dbf undotbs01.dbf[oracle@www cicro]$ sqlplus "/as sysdba"SQL*Plus: Release 9.2.0.1.0 - Production on Tue Jul 25 17:56:06 2006Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.Connected to:Oracle9i Release 9.2.0.1.0 - ProductionJServer Release 9.2.0.1.0 - ProductionSQL> recover database;Media recovery complete.SQL> alter database open;Database altered.SQL> select * from test;A----------111333333333333333333338 rows selected.至此，恢复成功！不完全恢复的案例基本操作与上面相同，还是首先建立一张表，然后插入数据：1：建表，写入数据,然后关闭数据库SQL> create table gaojf1 as select * from all_objects;T able created.SQL> insert into gaojf1 select * from gaojf1;29614 rows created.SQL> /59228 rows created. (即为现在此表数据有118456列)SQL>commit;SQL>shutdown immediate2：备份所有的数据文件3：启动数据库继续插入数据[oracle@www cicro]$ sqlplus "/as sysdba"SQL*Plus: Release 9.2.0.1.0 - Production on Tue Jul 25 18:07:19 2006 Copyright (c) 1982, 2002, Oracle Corporation.Connected to:Oracle9i Release 9.2.0.1.0 - ProductionJServer Release 9.2.0.1.0 - ProductionSQL> insert into gaojf1 select * from gaojf1;118456 rows created.SQL> /236912 rows created.SQL> /473824 rows created.SQL> /947648 rows created.SQL> commit;Commit complete.SQL> select count(*) from gaojf1;COUNT(*)----------1895296SQL> /1895296 rows created.SQL> /技术社区3790592 rows created.（如果能够完全恢复，此表应该有3790592*2列）SQL> commit;Commit complete.期间，查看日志信息如下：Wed Jul 26 13:02:54 2006Thread 1 opened at log sequence 1Current log# 3 seq# 1 mem# 0: /opt/oracle/oradata/cicro/redo03.log Successful open of redo thread 1.Wed Jul 26 13:03:56 2006Thread 1 advanced to log sequence 2Current log# 1 seq# 2 mem# 0: /opt/oracle/oradata/cicro/redo01.logWed Jul 26 13:05:41 2006Thread 1 advanced to log sequence 3Current log# 2 seq# 3 mem# 0: /opt/oracle/oradata/cicro/redo02.logWed Jul 26 13:09:04 2006Thread 1 advanced to log sequence 4Current log# 3 seq# 4 mem# 0: /opt/oracle/oradata/cicro/redo03.logWed Jul 26 13:09:29 2006Thread 1 advanced to log sequence 5Current log# 1 seq# 5 mem# 0: /opt/oracle/oradata/cicro/redo01.log 可以看到，redo文件在不断的循环重写，当一个redo写完后继续写第二个redo，然后是第三个，当第三个写完后继续回来重写第一个，依此类推。

现场情况：1、数据库没有作归档，2、数据都存放在system表空间3、没有备份状况：操作系统由于磁盘原因出现宕机，用户强行按电源关闭系统，数据库无法启动。

处理：Sql代码1.SQL> recover database;2.ORA-00283: recovery session canceled due to errors3.ORA-12801: error signaled in parallel query server P0024.ORA-10562: Error occurred while applying redo to data block (file# 1, block#4568)5.ORA-10564: tablespace SYSTEM6.ORA-01110: data file 1: '/opt/oracle/oradata/orcl/system01.dbf'7.ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 5768.ORA-00600: internal error code, arguments: [6101]9.检查日志信息如下：Oracle代码1.Mon Nov 1915:38:5020072.ALTER DATABASE RECOVER database3.Mon Nov 1915:38:5020074.Media Recovery Start5. parallel recovery started with 3 processes6.Mon Nov 1915:38:5020077.Recovery of Online Redo Log: Thread 1 Group 3 Seq 16 Reading mem 08. Mem# 0 errs 0: /opt/oracle/oradata/orcl/redo03.log9.Mon Nov 1915:38:50200710.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p002_7917.trc:11.ORA-00600: internal error code, arguments: [6101], [0], [17], [0], [], [], [], []12.Mon Nov 1915:38:50200713.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p000_7913.trc:14.ORA-00600: internal error code, arguments: [3020], [2], [882],[8389490], [], [], [], []15.ORA-10567: Redo is inconsistent with data block (file# 2, block# 882)16.ORA-10564: tablespace UNDOTBS117.ORA-01110: data file 2: '/opt/oracle/oradata/orcl/undotbs01.dbf'18.ORA-10560: block type 'KTU UNDO BLOCK'19.Mon Nov 1915:38:51200720.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p000_7913.trc:21.ORA-00600: internal error code, arguments: [3020], [2], [882],[8389490], [], [], [], []22.ORA-10567: Redo is inconsistent with data block (file# 2, block# 882)23.ORA-10564: tablespace UNDOTBS124.ORA-01110: data file 2: '/opt/oracle/oradata/orcl/undotbs01.dbf'25.ORA-10560: block type 'KTU UNDO BLOCK'26.Mon Nov 1915:38:51200727.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p002_7917.trc:28.ORA-10562: Error occurred while applying redo to data block (file# 1, block# 4568)29.ORA-10564: tablespace SYSTEM30.ORA-01110: data file 1: '/opt/oracle/oradata/orcl/system01.dbf'31.ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 57632.ORA-00600: internal error code, arguments: [6101], [0], [17], [0], [], [], [], []33.Mon Nov 1915:38:54200734.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p001_7915.trc:35.ORA-00600: internal error code, arguments: [kddummy_blkchk], [1], [1658], [6101], [], [], [], []36.Mon Nov 1915:38:54200737.Errors in file /opt/oracle/admin/orcl/bdump/orcl_p001_7915.trc:38.ORA-10562: Error occurred while applying redo to data block (file# 1, block# 1658)39.ORA-10564: tablespace SYSTEM40.ORA-01110: data file 1: '/opt/oracle/oradata/orcl/system01.dbf'41.ORA-10561: block type 'TRANSACTION MANAGED DATA BLOCK', data object# 23742.ORA-00607: Internal error occurred while making a change to a data block43.ORA-00600: internal error code, arguments: [kddummy_blkchk], [1], [1658], [6101], [], [], [], []44.Mon Nov 1915:38:54200745.Media Recovery failed with error 1280146.ORA-283 signalled during: ALTER DATABASE RECOVER database ...从上面信息中抓取了一个信息：Oracle代码1.ORA-10562: Error occurred while applying redo to data block (file# 1, block# 1658)针对这个错误解决如下：Oracle代码1.ORA-10562: Error occurred while applying redo to data block (file# string, block# string)2.Cause: See other errors on error stack.3.Action: Investigate why the error occurred and how important isthe data block. Media and standby database recovery usually ca n continue if user allows recovery to corrupt this data block。

oracle 故障恢复案例Oracle故障恢复案例1. 数据库实例崩溃恢复某公司的Oracle数据库实例突然崩溃，导致所有业务无法正常运行。

经过专业技术人员的分析，发现是由于服务器硬件故障导致的。

为了恢复数据库，技术人员采取了备份恢复的方式，通过使用备份数据文件和重做日志文件，成功将数据库实例恢复到崩溃前的状态。

2. 数据文件损坏的恢复某公司的数据库中的一个数据文件损坏，导致部分数据无法正常访问。

为了解决这个问题，技术人员首先通过文件系统级别的工具检查数据文件的完整性，并确定了损坏的范围。

然后，他们使用备份数据文件和重做日志文件进行恢复，成功修复了损坏的数据文件，并使数据库恢复正常。

3. 表空间故障的恢复某公司的数据库中的一个表空间突然出现故障，导致表空间中的所有表无法访问。

为了解决这个问题，技术人员首先通过Oracle的故障自诊断工具诊断表空间故障的原因，并确定了故障的范围。

然后，他们使用备份的表空间文件和重做日志文件进行恢复，成功修复了故障的表空间，并使其正常运行。

4. 数据库日志文件损坏的恢复某公司的数据库日志文件突然损坏，导致数据库无法正常启动。

为了恢复数据库，技术人员首先检查了日志文件的完整性，并确定了损坏的范围。

然后，他们使用备份的日志文件进行恢复，成功修复了损坏的日志文件，并使数据库恢复正常。

5. 控制文件丢失的恢复某公司的数据库控制文件丢失，导致数据库无法正常启动。

为了解决这个问题，技术人员首先通过文件系统级别的工具检查控制文件的完整性，并确定了丢失的范围。

然后，他们使用备份的控制文件进行恢复，成功恢复了丢失的控制文件，并使数据库正常启动。

6. 数据库块损坏的恢复某公司的数据库中的一个数据块突然损坏，导致数据库无法正常读取该块的数据。

为了解决这个问题，技术人员首先通过Oracle的故障自诊断工具诊断数据块故障的原因，并确定了损坏的范围。

然后，他们使用备份的数据块进行恢复，成功修复了损坏的数据块，并使数据库恢复正常。

一般情况下数据库的DBA都会对controlfile 进行多路复用，这样可以保证控制文件的安全性，对于数据库而言只要数据文件和redolog、archivelog不丢，数据都是可以恢复的，只是controlfile丢失，会比较麻烦。

环境：control01.ctl、control02.ctl、control03.ctl1、3个controlfile中的一个或者两个丢失，关闭数据库后，从没有没丢失的那个controlfile进行拷贝。

2、3个控制文件全丢失，可以进行重构控制文件，一般情况下我们会对控制文件进行二进制文件备份（alter database backup controlfile to trace as '*****' 备份成二进制文件）(alter database backup controlfile to '***' 是直接备份控制文件 )以下是备份出来的二进制文件的内容：有两种情况，1、完全恢复的时候用（红色）2、不完全恢复的时候用（紫红）-- The following are current System-scope REDO Log Archival related-- parameters and can be included in the database initialization file.-- LOG_ARCHIVE_DEST=''-- LOG_ARCHIVE_DUPLEX_DEST=''-- LOG_ARCHIVE_FORMAT=%t_%s_%r.dbf-- DB_UNIQUE_NAME="orcl"-- LOG_ARCHIVE_CONFIG='SEND, RECEIVE, NODG_CONFIG'-- LOG_ARCHIVE_MAX_PROCESSES=2-- STANDBY_FILE_MANAGEMENT=MANUAL-- STANDBY_ARCHIVE_DEST=?/dbs/arch-- FAL_CLIENT=''-- FAL_SERVER=''-- LOG_ARCHIVE_DEST_1='LOCATION=/u01/app/oracle/oradata/orcl/arch'-- LOG_ARCHIVE_DEST_1='OPTIONAL REOPEN=300 NODELAY'-- LOG_ARCHIVE_DEST_1='ARCH NOAFFIRM NOEXPEDITE NOVERIFY SYNC'-- LOG_ARCHIVE_DEST_1='REGISTER NOALTERNATE NODEPENDENCY'-- LOG_ARCHIVE_DEST_1='NOMAX_FAILURE NOQUOTA_SIZE NOQUOTA_USED NODB_UNIQUE_NAME'-- LOG_ARCHIVE_DEST_1='VALID_FOR=(PRIMARY_ROLE,ONLINE_LOGFILES)'-- LOG_ARCHIVE_DEST_STATE_1=ENABLE-- Below are two sets of SQL statements, each of which creates a new-- control file and uses it to open the database. The first set opens-- the database with the NORESETLOGS option and should be used only if-- the current versions of all online logs are available. The second -- set opens the database with the RESETLOGS option and should be used -- if online logs are unavailable.-- The appropriate set of statements can be copied from the trace into -- a script file, edited as necessary, and executed when there is a-- need to re-create the control file.-- Set #1. NORESETLOGS case-- The following commands will create a new control file and use it-- to open the database.-- Data used by Recovery Manager will be lost.-- Additional logs may be required for media recovery of offline-- Use this only if the current versions of all online logs are-- available.-- After mounting the created controlfile, the following SQL-- statement will place the database in the appropriate-- protection mode:-- ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE STARTUP NOMOUNTCREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS ARCHIVELOGMAXLOGFILES 16MAXLOGMEMBERS 3MAXDATAFILES 100MAXINSTANCES 8MAXLOGHISTORY 292LOGFILEGROUP 1 '/u01/app/oracle/oradata/orcl/redo01.log' SIZE 50M,GROUP 2 '/u01/app/oracle/oradata/orcl/redo02.log' SIZE 50M,GROUP 3 '/u01/app/oracle/oradata/orcl/redo03.log' SIZE 50M-- STANDBY LOGFILEDATAFILE'/u01/app/oracle/oradata/orcl/system01.dbf','/u01/app/oracle/oradata/orcl/undotbs01.dbf','/u01/app/oracle/oradata/orcl/sysaux01.dbf','/u01/app/oracle/oradata/orcl/users01.dbf','/u01/app/oracle/oradata/orcl/example01.dbf','/u01/app/oracle/oradata/orcl/app1_01.dbf','/u01/app/oracle/oradata/orcl/app02_01.dbf'CHARACTER SET AL32UTF8-- Commands to re-create incarnation table-- Below log names MUST be changed to existing filenames on-- disk. Any one log file from each branch can be used to-- re-create incarnation records.-- Recovery is required if any of the datafiles are restored backups,-- or if the last shutdown was not normal or immediate.RECOVER DATABASE-- All logs need archiving and a log switch is needed.ALTER SYSTEM ARCHIVE LOG ALL;-- Database can now be opened normally.ALTER DATABASE OPEN;-- Commands to add tempfiles to temporary tablespaces.-- Online tempfiles have complete space information.-- Other tempfiles may require adjustment.ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/orcl/temp01.dbf'-- End of tempfile additions.-- Set #2. RESETLOGS case-- The following commands will create a new control file and use it-- to open the database.-- Data used by Recovery Manager will be lost.-- The contents of online logs will be lost and all backups will-- be invalidated. Use this only if online logs are damaged.-- After mounting the created controlfile, the following SQL-- statement will place the database in the appropriate-- protection mode:-- ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCESTARTUP NOMOUNTCREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS ARCHIVELOGMAXLOGFILES 16MAXLOGMEMBERS 3MAXDATAFILES 100MAXINSTANCES 8MAXLOGHISTORY 292LOGFILEGROUP 1 '/u01/app/oracle/oradata/orcl/redo01.log' SIZE 50M,GROUP 2 '/u01/app/oracle/oradata/orcl/redo02.log' SIZE 50M,GROUP 3 '/u01/app/oracle/oradata/orcl/redo03.log' SIZE 50M-- STANDBY LOGFILEDATAFILE'/u01/app/oracle/oradata/orcl/system01.dbf','/u01/app/oracle/oradata/orcl/undotbs01.dbf','/u01/app/oracle/oradata/orcl/sysaux01.dbf','/u01/app/oracle/oradata/orcl/users01.dbf','/u01/app/oracle/oradata/orcl/example01.dbf','/u01/app/oracle/oradata/orcl/app1_01.dbf','/u01/app/oracle/oradata/orcl/app02_01.dbf'CHARACTER SET AL32UTF8-- Commands to re-create incarnation table-- Below log names MUST be changed to existing filenames on-- disk. Any one log file from each branch can be used to-- re-create incarnation records.-- Recovery is required if any of the datafiles are restored backups,-- or if the last shutdown was not normal or immediate.RECOVER DATABASE USING BACKUP CONTROLFILE-- Database can now be opened zeroing the online logs.ALTER DATABASE OPEN RESETLOGS;-- Commands to add tempfiles to temporary tablespaces.-- Online tempfiles have complete space information.-- Other tempfiles may require adjustment.ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/app/oracle/oradata/orcl/temp01.dbf'-- End of tempfile additions.执行以上脚本对controlfile进行重构时，是在数据库未启动的时候进行。

时间：2010.1.6 来源：网络编辑：联动北方技术论坛在Oracle数据库中，控制文件是非常重要的。

它用于记录和维护数据库。

当恢复数据库时，服务器进程和后台进程需要从控制文件中读取各种备份相关的信息。

如果控制文件损坏，则会导致这些备份信息的丢失。

尽管使用多元化控制文件可以防止控制文件损坏，但因为控制文件的重要性，应该定期备份控制文件。

当数据库配置发生改变时，一定要备份控制文件。

涉及到数据库配置改变的命令：1.alter database [add|drop] logfile2.3.alter database [add|drop] logfile member4.5.alter database [add|drop] logfile group6.7.alter database [noarchivelog|archivelog]8.9.alter database rename file10.11.create tablespace12.13.alter tablespace [add|rename] datafile14.15.alter tablespace [read write|read only]16.17.drop tablespace控制文件的备份，三种方式1)使用OS命令进行拷贝1)open状态下，使用alter database命令生成控制文件副本2)open状态下，使用alter database backup controlfile to trace命令将控制文件备份到跟踪文件控制文件的恢复,两种方式1)mount状态下，使用RECOVER DATABASE USING BACKUP CONTROLFILE2)mount状态下，生成跟踪文件并进行恢复2--2示例：1.[oracle@localhost ~]$ rlsqlplus / as sysdba2.3.SQL*Plus: Release 10.2.0.1.0 - Production on 星期一 8月 1 21:40:03 20114.5.Copyright (c) 1982, 2005, Oracle. All rights reserved.6.7.Connected to an idle instance.8.9.SQL> startup10.11.ORACLE instance started.12.13.Total System Global Area 528482304 bytes14.15.Fixed Size 1220360 bytes16.17.Variable Size 176161016 bytes18.19.Database Buffers 343932928 bytes20.21.Redo Buffers 7168000 bytes22.23.Database mounted.24.25.Database opened.--open状态下生成控制文件副本1.SQL> alter database backup controlfile to2.3. 2 '/oracle/10g/oracle/bakup/database/oralife.ctl';4.5.alter database backup controlfile to6.7.*8.9.ERROR at line 1:10.11.ORA-01580: error creating control backup file12.13./oracle/10g/oracle/bakup/database/oralife.ctl14.15.ORA-27038: created file already exists16.17.Additional information: 118.19.SQL> alter database backup controlfile to20.21. 2 '/oracle/10g/oracle/bakup/database/oralife.ctl' reuse; --reuse用于覆盖原有控制文件副本23.Database altered.--手动删除所有控制文件模拟文件丢失1.SQL> ho rm /oracle/10g/oracle/product/10.2.0/oradata/oralife/*.ctl;--使用evan登录，并添加数据1.SQL> conn evan/evan2.3.Connected.4.5.SQL> select * from t_evan;6.7.TEXT8.9.--------------------------------------------------------------------------------10.11.oracle12.13.java14.15.spring16.17.hibernate18.19.hibernate20.21.SQL> insert into t_evan values('added');22.23. 1 row created.24.25.SQL> commit;26.mit complete.28.29.SQL> conn / as sysdba30.31.Connected.32.33.SQL> shutdown immediate34.35.ORA-00210: cannot open the specified control file36.37.ORA-00202: control file: '/oracle/10g/oracle/product/10.2.0/oradata/oralife/control01.ctl'39.ORA-27041: unable to open file40.41.Linux Error: 2: No such file or directory42.43.Additional information: 344.45.SQL> shutdown abort46.47.ORACLE instance shut down.--alter_oralife.log出现这样的信息：1.Mon Aug 1 23:13:51 20112.3.ORA-00202: control file: '/oracle/10g/oracle/product/10.2.0/oradata/oralife/control01.ctl'4.5.ORA-27037: unable to obtain file status6.7.Linux Error: 2: No such file or directory8.9.Additional information: 3--拷贝控制文件到目标路径1.SQL>ho cp /oracle/10g/oracle/bakup/database/oralife.ctl /oracle/10g/oracle/product/10.2.0/oradata/oralife/control01.ctl2.3.SQL> alter system set control_files='/oracle/10g/oracle/product/10.2.0/oradata/oralife/control01.ctl'scope = spfile; --修改control_files参数，指定可用的控制文件4.5.System altered.6.7.SQL> startup force mount8.9.ORACLE instance started.10.11.Total System Global Area 528482304 bytes12.13.Fixed Size 1220360 bytes14.15.Variable Size 138412280 bytes16.17.Database Buffers 381681664 bytes18.19.Redo Buffers 7168000 bytes20.21.Database mounted.--生成trace文件1.SQL> alter database backup controlfile to trace noresetlogs;2.3.Database altered.4.5.SELECT c.VALUE || '/' || d.instance_name || '_ora_' || a.spid || '.trc' TRACE6.7.FROM v$process a, v$session b, v$parameter c, v$instance d8.9.WHERE a.addr = b.paddr10.11.AND b.audsid = USERENV ('sessionid')12.13.AND = 'user_dump_dest';14.15.TRACE16.17.--------------------------------------------------------------------------------18.19./oracle/10g/oracle/product/10.2.0/db_1/admin/oralife/udump/oralife_ora_4558.trc20.21.SQL> shutdown immediate22.23.ORA-01109: database not open24.25.Database dismounted.26.27.ORACLE instance shut down.--打开trace文件，去掉注释，在shutdown状态下执行脚本，创建控制文件--用evan登录验证数据1.SQL> conn evan/evan2.3.Connected.4.5.SQL> select * from t_evan;6.7.TEXT8.9.--------------------------------------------------------------------------------10.11.oracle12.13.java14.15.spring16.17.hibernate18.19.hibernate20.21.added22.23. 6 rows selected.可见数据没有丢失。

一般情况下是利用控制文件的副本，我们创建数据库的时候不是一般都建立3个控制文件吗，这是用于进行冗余保护的，如果只有一个控制文件是好的，那么我们只需要将已损坏的控制文件删除，然后将好的这个控制文件复制到已损坏的控制文件的目录下，重命名成已损坏的控制文件即可（注意一下复制的位置，如果目标文件夹所在的磁盘已经损坏的情况下，我们就得把控制文件复制到好的磁盘上，并且还要修改control_files参数重新定位控制文件的位置）。

还有一种情况就是所有控制文件都损坏了，那么就得利用控制文件的备份进行恢复。

所以，我们在数据库创建好后第一件事就是对控制文件进行备份，在数据库物理结构变化之后也得备份控制文件。

使用命令ALTER DATABASE BACKUP CONTROLFILE TO TRACE，会有一个转储文件会放在user_dump_dest参数定义的目录中，里面有重建控制文件的脚步，按照转储文件里面写的做就可以了。

一、损坏单个控制文件损坏单个控制文件是比较容易恢复的，因为一般的数据库系统，控制文件都不是一个，而且所有的控制文件都互为镜相，只要拷贝一个好的控制文件替换坏的控制文件就可以了。

1、控制文件损坏，最典型的就是启动数据库出错，不能mount数据库SQL>startupORA-00205: error in identifying controlfile, check alert log for more info查看报警日志文件，有如下信息alter database mountMon May 26 11:59:52 2003ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl'ORA-27041: unable to open fileOSD-04002: unable to open fileO/S-Error: (OS 2) 系统找不到指定的文件。

一、损坏单个控制文件损坏单个控制文件是比较容易恢复的，因为一般的数据库系统，控制文件都不是一个，而且所有的控制文件都互为镜相，只要拷贝一个好的控制文件替换坏的控制文件就可以了。

1、控制文件损坏，最典型的就是启动数据库出错，不能mount数据库SQL>startupORA-00205: error in identifying controlfile, check alert logfor more info查看报警日志文件，有如下信息alter database mountMon May 26 11:59:52 2003ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl' ORA-27041: unable to open fileOSD-04002: unable to open fileO/S-Error: (OS 2) 系统找不到指定的文件。

2、停止数据库SQL>shutdown immediate3、拷贝一个好的控制文件替换坏的控制文件或修改init.ora中的控制文件参数，取消这个坏的控制文件。

4、重新启动数据SQL>startup说明：1、损失单个控制文件是比较简单的，因为数据库中所有的控制文件都是镜相的，只需要简单的拷贝一个好的就可以了2、建议镜相控制文件在不同的磁盘上3、建议多做控制文件的备份，长期保留一份由alter databasebackup control file to trace产生的控制文件的文本备份二、损坏全部控制文件损坏多个控制文件，或者人为的删除了所有的控制文件，通过控制文件的复制已经不能解决问题，这个时候需要重新建立控制文件。

同时注意，alter database backup control file to trace可以产生一个控制文件的文本备份。

以下是详细重新创建控制文件的步骤1、关闭数据库SQL>shutdown immediate;2、删除所有控制文件，模拟控制文件的丢失3、启动数据库，出现错误，并不能启动到mount下SQL>startupORA-00205: error in identifying controlfile, check alert logfor more info查看报警日志文件，有如下信息alter database mountMon May 26 11:53:15 2003ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl' ORA-27041: unable to open fileOSD-04002: unable to open fileO/S-Error: (OS 2) 系统找不到指定的文件。