Oracle数据库恢复
Oracle作为世界上稳定的数据库得到大型企业以及金融机构的青睐，Oracle经常应用在linux系统，unix系统和aix小型机等环境下。
Oracle由控制文件、数据库文件和临时文件组成。
控制文件在Oracle数据库中扮演着很重要的角色，控制文件包括了很多重要的信息，比如数据库的数据文件、重做日志文件、数据库的名称、数据库创建信息、表空间信息、数据文件的状态、日志文件信息、备份信息、检查点信息等，断电或者硬盘坏道导致没有控制文件或者控制文件损坏了，运行着的实例立即崩溃，关闭着Oracle的死活打不开，可以说，控制文件一旦损坏，数据库必然down了。
数据文件是用来存储实际数据的，数据文件是存储数据的物理概念，是数据库文件的核心所在。在Oracle中有个概念叫做表空间，一个表空间至少包含一个数据文件，创建数据库对象的时候指定的是使用的表空间，一个表空间(比如一张大表)可以跨越多个数据文件。
临时文件是临时表空间对应的数据文件，这个文件不是一用完就删除，而是指这个文件存储的对象是属于临时存在的对象。临时文件主要用于大量的排序的时候，如果不能在内存中进行排序，那么就会将数据转移到临时文件中作为中转。
有时候控制文件虽然完好，但数据库文件却出现了问题，比如库文件恰好在坏道上，或者磁盘阵列故障，导致数据库文件损坏。或者说控制文件也坏了，无论数据库文件是否完好，这个时候，数据库会报各种各样的错误代码，都是ORA-××××。
Oracle一般出现故障的原因是突然断电、硬盘坏道、磁盘阵列中硬盘掉线。具体有以下的表现形式
1、 非归档模式的数据库，丢失数据文件
丢失某个数据库文件，造成了数据库无法启动，同时数据库处于非归档模式，也没有冷备份，启动时的错误信息如下：
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:ORACLEORADATATESTUSERS01.DBF'
2、控制文件损坏
控制文件发生了损坏，数据库已经无法启动，报错信息如下：
ORA-00202: controlfile: 'D:Oracleoradatachencontrol01.ctl'
ORA-27041: unable to open file
OSD-04002: unable to open file
这种控制文件损坏不外乎两种情况，其一是控制文件有镜像，且镜像控制文件没有被损坏，其二是控制文件无镜像，或者镜像的所有控制文件都损坏了。
3、UNDO数据文件损坏，数据库无法启动
Undo数据文件发生了丢失或损坏，数据库启动报错:
ORA-01157: cannot identify/lock data file 2 - see DBWR trace file
ORA-01110: data file 2: '/oracle10/oradata/ora10g/undotbs01.dbf'
4、临时表空间的数据文件损坏
临时表空间的数据文件发生损坏，系统出现故障
5、current或active的redo log损坏
误删除了redo log，或者redo log被损坏，数据库不能打开:
ORA-00313: open failed for members of log group 2 of thread 1
ORA-00312: online log 2 thread 1: '/oracle10/oradata/ora10g/redo02.log'
6、非current和active的redo log损坏
误删除了redo log，或者redo log被损坏，数据库能mount,不能open:
ORA-00313: open failed for members of log group 3 of thread 1
ORA-00312: online log 3 thread 1: '/oracle10/oradata/ora10g/redo03.log'
7、归档模式数据库丢失某数据文件，无备份,但有该数据文件创建以来的归档日志。
归档模式的数据库，丢失了某个数据库文件，造成了数据库无法启动，同时没有数据库的全备份，但有该数据文件创建以来的归档日志，数据库无法启动：
ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
ORA-01110: data file 3: 'D:ORACLEORADATATESTUSERS01.DBF
解决方案
不管是控制文件还是数据库文件出错，只要保留好Oracle system文件夹不被破坏, 我们都有挽救的办法，如果里面包含有控制文件和数据库文件，补天时代都有良好的解决方案：把数据库文件修复生成DMP文件。然后再建立一个同样的oracle数据库环境，把DMP文件导入即可恢复。
Oracle 的恢复门槛在于：数据库的"目录结构"本身也存放在数据库里（数据字典），一旦系统表空间或控制文件损坏，普通工具连表名都读不出来，更谈不上导出数据。
技术难点：数据字典 + 日志顺序
Oracle 由数据文件（按块存放，块大小建库时确定）、重做日志、回滚数据、控制文件组成，靠 SCN（系统改变号）串起一致的时间线。控制文件丢失后必须重建或绕过；重做日志链断裂，最新的事务就无法前滚；如果数据放在自动存储管理（ASM）上，连文件系统都没有，要按分配单元直接解析。集群环境还涉及多节点的日志归并。
我们实际怎么做
- 物理层只读镜像：数据文件、日志、控制文件所在的盘全部镜像；ASM 环境按分配单元整体镜像。
- 块级与段级解析：读取数据块的块头信息，解析段的区映射，找出每张表的数据分布在哪些块上；同时解析数据字典，还原表、列、索引的定义。系统表空间损坏时，用引导记录重建最小可用的数据字典。
- 重建控制文件或绕过控制文件：控制文件可用就重建；不可用时直接从数据文件解析数据对象，继续取数。
- 日志前滚 + 回滚未提交事务：按 SCN 顺序应用重做记录，把数据推到一致点，并回滚未提交的变更，避免出现"半笔业务"。
- ASM 场景按分配单元重建映射，再还原出数据文件。
- 导出验证：数据导出为可导入的形式（数据泵/脚本/表格），客户核对行数与业务查询后交付。
这些操作千万别做
- 在故障库上执行启动恢复、挂载或重建控制文件的写入类操作——原库应当是"证据"，只读不动。
- 把重做日志或归档日志随手丢掉：它们决定你能拿回多少最新数据。
- 在没有还原点的情况下执行全库恢复；或把 ASM 盘当成普通分区去挂载。
Oracle 单库、ASM、集群环境我们均可处理；先免费检测评估可恢复性，不成功不收费。完整服务流程见 数据恢复服务流程。