如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]
目的
——-
本文旨在介绍磁盘出现故障后的一些常见恢复技术
范围 & 应用
——————-
所有参与恢复Oracle数据库的Oracle support分析师，DBA和顾问
由于磁盘故障的丢失
————————
磁盘故障会使哪些丢失：
- A) 控制文件
- B) 重做日志文件
- C) 归档日志文件
- D) 数据文件
- E) 参数文件或SPFILE
- F) Oracle 软件安装
检测磁盘故障
———————–
1) 运行复制工具，如unix上”dd”
2) 如果使用RAID 机制，如RAID 5, parity信息可能掩盖磁盘故障，将需要更有力的检查
3) 与往常一样，检查操作系统日志文件
4) 另一个明显的情况是当OS无法查看或mount磁盘。
5) 在Oracle端，如果受影响的文件是一个数据文件，运行dbv
6) 检测磁盘故障的最佳方法是运行Hardware 诊断工具和OS特定磁盘工具。
下一步Next Action
————
当识别出故障类型时，下一步是纠正它们。
选项有：
(1) 使用新的磁盘替换损坏的磁盘，并使用相同名称mount 它们（如 /oracle或 D:\）
(2) 使用新的磁盘替换损坏的磁盘，并使用不同名称mount 它们 (如 /oracle1 作为新的mount point）
(3) 决定使用被不同名称mount的另一个现有磁盘（如 /oracle2）
最常见方法为 (1) 和 (3)。
Oracle Recovery
—————
一旦磁盘问题被分类，则下一步是在Oracle级别执行恢复。这取决于丢失的文件类型（参见”Loss due to Disk Failure” 部分）以及在”下一步Next Action”部分提到的磁盘恢复类型。
(A) 控制文件
——————
通常，我们有控制文件multiplexing且它们预计在不同的磁盘。
如果一个或多个控制文件丢失，mount会失败显示如下：
SQL> startup
Oracle Instance started
….
ORA-00205: error in identifying controlfile, check alert log for more info
你可以验证控制文件副本，使用：
SQL> select * from v$controlfile;
**如果至少一个控制文件的副本未受磁盘故障影响，
当数据库被干净关闭时：
(a) 将控制文件好的副本复制到丢失位置
(b) 启动数据库
另一个选择，删除在init参数control_files中指定的丢失控制文件位置，并启动数据库。
**如果控制文件的所有副本由于磁盘故障丢失，则：
查看控制文件备份。通常使用以下命令之一创建备份控制文件：
(a) SQL> alter database backup controlfile to ‘/backup/control.ctl’;
— 这会创建当前控制文件的二进制备份 —
–>如果创建了上述二进制格式的备份，使用OS复制工具将文件还原到丢失控制文件的位置。
–> SQL> startup mount;
–> SQL> recover database using backup controlfile;
–> SQL> alter database open;
(b) SQL> alter database backup controlfile to trace;
— 这会创建一个包含create controlfile 脚本的可读跟踪文件 —
–> 编辑创建的跟踪文件（检查位置的user_dump_dest ）并单独保留SQL 命令。将其保存到一个文件，如cr_ctrl.sql
–> 运行脚本
SQL> @cr_ctrl
这会创建控制文件，恢复数据库并打开数据库。
** 如果没有可用的控制文件副本或备份，则使用数据文件和重做日志文件信息创建一个controlfile creation脚本。确保文件如FILE$中一样以正确的顺序列示。
之后的步骤与cr_ctrl.sql脚本之后的步骤类似。
注意相关SQL维护操作的所有控制文件在数据库nomount状态完成
(B) 重做日志
———
通常情况下，我们不会有联机重做日志的备份。但非活跃日志文件更改可能已经在数据文件上被checkpoint且甚至归档日志可用。
SQL> startup mount
Oracle Instance Started
Database mounted
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: ‘/ORACLE/ORADATA/H817/REDO01.LOG’
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) The system cannot find the file specified.
** 验证丢失的重做文件是否为Current。
SQL> select * from v$log;
SQL> select * from v$logfile;
–> 如果丢失的重做日志是非活跃日志文件，你可以清理日志文件：
SQL> alter database clear logfile ‘/ORACLE/ORADATA/H817/REDO01.LOG’;
另一个选择，如果你有至少两个其他日志文件，你可以drop日志文件：
SQL> alter database drop logfile group 1;
–> 如果日志文件是Current日志文件，则执行以下：
SQL> recover database until cancel;
当提示时输入cancel Type Cancel when prompted
SQL>alter database open resetlogs;
‘recover database until cancel’ 命令会失败显示以下错误：
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/ORADATA/H817/SYSTEM01.DBF’
在这种情况下，还原数据库文件的旧备份并应用归档日志来执行不完全恢复。
–> 还原旧备份
SQL> startup mount
SQL> recover database until cancel using backup controlfile;
SQL> alter database open resetlogs;
如果数据库在noarchivelog模式且如果发生ORA-1547，ORA-1194 和ORA-1110错误，然后你会从旧备份中还原并启动数据库。
注意所有重做日志维护操作在数据库mount状态中完成
(C) 归档日志
—————–
如果仅丢失之前的归档日志文件，那就不需要担心。
** 使用确保不需要丢失的归档日志的热或冷备份来备份当前数据库文件
(D) 数据文件
————–
这显然是最大的丢失。
(1) 如果只有一些部分损坏，则当访问这些块时，你会得到ora-1578。
–> 通过查询dba_extents ，识别损坏块的对象名和类型
–> 基于对象类型，执行正确恢复
–> 查看metalink Note:28814.1 来解决该错误
(2) 如果整个磁盘丢失，则可能需要恢复一个或多个数据文件。
SQL> startup
ORACLE instance started.
…
Database mounted.
ORA-01157: cannot identify/lock data file 3 – see DBWR trace file
ORA-01110: data file 3: ‘/ORACLE/ORADATA/H817/USERS01.DBF’
其他可能的错误有ORA-00376和ORA-1113
识别数据文件的视图和查询会是：
SQL> select file#,name,status from v$datafile;
SQL> select file#,online,error from v$recover_file;
** 如果restoring to a replaced disk mount同一名称，则：
(1) 使用OS copy/restore 命令从之前的备份中还原受影响的数据文件
(2) 基于受影响的数据文件类型，即SYSTEM，ROLLBACK 或UNDO，TEMP ，DATA 或INDEX执行恢复。
(3) 基于丢失和数据库状态，恢复命令可以是 ‘recover database’，’recover tablespace’或 ‘recover datafile’
** 如果还原到另一个mount point，则：
(1) 从之前的备份中将文件还原到新的位置
(2) SQL> STARTUP MOUNT
(3) SQL> alter database rename file ‘/old path_name’ to ‘new path_name’;
— 对受影响的所有数据文件进行重命名。–
(4) 基于受影响的数据文件类型，即SYSTEM，ROLLBACK 或UNDO，TEMP ，DATA 或INDEX执行恢复。
(5) 基于丢失和数据库状态，恢复命令可以是 ‘recover database’，’recover tablespace’或 ‘recover datafile’
基于丢失的数据文件和Oracle错误，恢复的详细步骤在本文结尾引用的文章中。
NOARCHIVELOG DATABASE
=====================
当涉及归档日志的情况下，(A)，(B)和(D) 的丢失就有所不同。
我们将在这里讨论数据文件丢失方案：
(a) 如果丢失的数据文件是一个SYSTEM 数据文件，从之前的备份中还原完全数据库并启动数据库。
(b) 如果丢失的数据文件是有活跃事务的回滚相关的数据文件，从之前的备份中还原数据库并启动数据库。
(c) 如果数据文件包含没有活跃回滚段的回滚，你可以脱机数据文件（在注释rollback_segments 参数，假定它们是private 回滚段）并打开数据库。
(d) 如果数据文件是临时的，脱机数据文件并打开数据库。
Drop表空间并重建表空间。
(e) 如果数据文件是DATA 或INDEX，
**脱机表空间并启动数据库。
**如果你有一个之前的备份，将其还原到另一个位置。
**然后导出受影响对象中的对象（使用用户或表级别导出）。
**在原始数据库中创建表空间。
**导入以上导出的对象。
如果数据库是8i或以上，你也可以示意Transportable 表空间功能。
(E) 参数文件
—————
这不是主要的损失且可以简单被还原。选项有：
(1) 如果有备份，还原文件
(2) 如果没有备份，复制相同文件机票创建一个示例文件或创建一个新文件并添加所需的参数。确保参数db_name，control_files，db_block_size，compatible 被正确设置
(3) 如果spfile丢失，如果init参数文件可用，你可以根据它再创建一个
(F) Oracle Software Installation
—————————-
有两个方法从这种情况中恢复：
(1) 如果有一个Oracle home和Oracle Inventory的备份，将它们还原到各自的目录。注意如果你更改了Oracle Home，目录不会注意到 thid new path且你会无法应用补丁集。并还原到系统OS用户和组。
(2) 执行新安装，使其在同一补丁集级别
PRACTICAL SCENARIO实用情景
==================
在大多数情况下，当一个磁盘丢失，多于一个类型的文件会丢失。
这个情况下的恢复会是：
(1) 这些数据丢失恢复情况的组合
(2) 从最近的备份还原整个数据库并应用归档日志执行恢复。这是强烈建议的方法但可能相当耗时。
参考
NOTE:184327.1 – ORA-1157 Troubleshooting
NOTE:198640.1 – How to Recover from a Lost or Deleted Datafile with Different Scenarios
NOTE:183327.1 – Common Causes and Solutions on ORA-376 Error Found in Backup & Recovery
NOTE:183367.1 – Common Causes and Solutions on ORA-1113 Error Found in Backup & Recovery
NOTE:117481.1 – How to Recover from Loss Of Online Redo Log And ORA-312 And ORA-313
Leave a Reply