windows 2000 advance server +oracle 9i系统崩溃后的数据恢复案例
     这是我亲身经历的一次过程，我想将它记录下来跟大家分享一下，也许对初学者有用。
2006-10-30-1 我的一台业务系统服务突然蓝屏，惨了，系统出现问题，采用修复系统，找到系统安装盘。
开始修复………………………………
结果无法修复，只好叫业务系统开发人员赶紧发通知，业务停止一天，缓和一下时间，想好对策进行数据恢复。
第一考虑的是我的备份是在凌晨3点开始，恰好不好采，备份系统也在这台业务系统上安装，所以昨天晚上的数据是没有备份的，而该业务系统又是前期开发商安装在系统分区，真是祸害一连串啊！想想捏了一把冷汗！！
最后，赌一把，重新安装系统，将系统安装到另一个分区，将数据文件拷贝出来，然后，再进行正常系统安装规划。等待的时间是那么的漫长……………………终于将原有的oracle数据文件拷贝出来。然后，再次格式化安装系统。重新构建oracle数据库，将数据文件恢复到初始状态，担心的是文件不知是否损坏。最后将数据文件恢复成功，查看一下后台数据，哟！昨天的数据还在，心里压着的石头放下了。如下是我的恢复过程，欢迎大家指教！
  
   首先要能保证你的数据库是正常情况下执行关闭才能进行以下操作.
否则，可能恢复不成功，即使恢复了也有部分数据丢失可能性。
恢复数据整个过程：
一.首先，将原有的数据库正常关闭（停止oracle后台所有服务）。
二.拷贝oracle数据安装整个目录（比如，初始安装指定目录在D盘路径D:\Oracle）
先将该目录拷贝到一个安全的地方。然后，安装好操作系统和恢复前相同版本oracle
注:所安装的机器名,iP地址和oracle目录路径，oracle用户和密码（特别是system用户）
等初始崩溃前系统一样.

二.安装oracle数据库（版本，实例名跟先前崩溃系统一样命名）
注:有个默认实例名instance修改为你所有的原来一样.
包括:一个完整的数据库文件集包括：
数据库启动参数文件，控制文件，数据文件，日志文件。
要和原来路经一样才行.
三.恢复数据库
  当操作系统和oracle数据库都安装好，计算机名，ip，目录，路径，oracle系统用户，
密码都设置成先前崩溃系统一样。
  步骤：
   1.停止所有oracle服务
   2.将新安装的数据库目录重新命名《oracle命名为oracle-source》
   （防止恢复不成功，然后将ORACLE安装目录更改成初始状态，避免重新安装ORACLE）
   3.将先前备份的oracle目录拷贝到当前安装盘符比如:D：\
   4.启动oracle相关服务 测试一下ok！！！大功告成！
如果启动数据库密码文件出错，可以用如下方法进行密码文件重建，方法如下：
利用orapwd 命令：
其用法如下：orapwd file=   password=  enfries=
说明：
-----file－name of password file(口令文件的命名方式为：orapwSID)(必须)
-----password－password for SYSand INTERNAL(必须)
-----enfries－maximum number of distinct DBA and OPERS(可选)
-----There are no spaces around the eaual to(=) charactor
Example：orapwd file=orapwora816 password=manager
重新创建好口令文件之后ORACLE就可以正常启动了。

这样真的行啊，偶倒没试过，上次正好有这样的机会
偶也是这样的想法，可是没有真正的去做
倒是把备份出来的DMP文件恢复回去算鸟事

前提是数据文件没有破坏，正常关闭的情况下。肯定能修复的！

好厉害,数据库迁移也可以用这个办法了哦 .难度啊

如果系统突然崩溃，数据库是不关闭状态下的。一般这样的情况比较多，所以这个情况是最理想的状态。

不错,对我有用的,谢谢

ding

确实这样的，我的是oracle8.16数据库也是这样克隆到另外的一台服务器上的

只要数据文件还在，就基本上没有多大的问题

我也碰到这样的问题，但是我只剩数据库文件，因为在盘柜里，数据库应用文件跟系统一起走了，我重新装了数据库，也建了相同的库文件，地址也一样，然后把盘柜里的覆盖上去，监听就起不来了

fdf

控制文件的损坏，回滚段的损坏，system01.dbf文件的破坏和丢失，都会使oracle数据库处于nomount,mount状态，不会处于open状态，面对以上问题，飞客数据恢复中心有专门的 oracle数据库恢复和修复专家，能对以上常见的数据库故障进行恢复和修复，即使是在system01.dbf文件遭到破坏的情况下，数据文件丢失，都可以让你的数据库重新回到open的状态下。
联系方式详见：http://www.fix.com.cn
飞客oracle数据库恢复和修复中心

数据库就是结构化的数据仓库。人们时刻都在和数据打交道，如：存储在个人掌上电脑（ PDA ）中的数据、家庭预算电子数据表，企业的财务、仓库数据，银行、电信数据等等。对于少量、简单的数据，如果它们与其它数据之间的关联较少或没有关联的情况下，他们可以简单的存放在文件中。当然如果所有的数据结构都很简单，那么数据库管理系统就没什么用了。但是企业数据都是相关联的。如：职员表链接到名称和地址的记录，订单记录需要与库存信息相对应，海运记录需要与信用额度相对应，等等。通常来说，不可能使用普通的记录文件来管理大量的、复杂的系列数据，如：银行的客户数据，或者生产厂商的的生产控制数据。普通记录文件没有系统结构来系统的反映数据间的复杂关系，它也不能强制定义个别数据对象。 数据库管理系统 数据库管理系统 (DBMSs) ，或者数据库管理器已经发展了近二十年，来解决上面提到的这些需求。数据库管理器是近似于文件系统的软件系统，通过它应用程序和用户可以取得所需的数据。然而，它们又不像文件系统，它们定义了所管理的数据之间的结构和约束关系。并且，数据库管理器提供了一些基本的数据管理功能：
                                 管理数据库日志
      对于容灾而言，数据库备份应当存贮在远离数据库的地方。为了达到最优容灾状态，在灾难发生后能够容易地获取数据库日志也是非常必要的。数据库归档日志通常保存在备份储存的地点。数据库管理员必须在数据库实时恢复和资源占用量两者之间找到平衡，从而决定进行数据库日志归档的频率。过多地进行归档可以降低数据损失的潜在危险，但是浪费了更多的进程和 I/O 资源，很有可能增加了处理的响应时间。过少地进行归档可以降低资源的平均占用量，但是延长了两次归档的间隔时间，很有可能导致不能做到精确的实时恢复。 如果一个数据库和它的联机日志被损坏了，那么即使马上进行了严密的数据库备份和日志归档，数据也极有可能丢失。因此，一个完整的数据库融灾策略的一个重要部分就是对联机的数据库日志进行复制，这样在进行修复处理时就可以及时利用这些复制的内容准确无误地修复数据库。联机数据库日志可以通过有限的距离进行镜像。如果距离过长，数据库管理员可以通过多路转接技术或者通过企业网络同时进行本地和远处的日志拷贝。多路转接技术通常比镜像和低水平复制（如数据卷）的速度要慢一些，因此如果可以的话要尽量选择后一种方式。 最高级别的数据库实时恢复是在每次事务提交的之前同步进行数据库日志的传输和归档。换句话说，必须要在日志已经被转移到另外地点后，才进行事务的提交。显而易见，这种选择执行起来的代价是非常昂贵的，因而在实践中较少采用。
  被动式的数据库恢复
      在没有备份的情况下，一旦出现数据灾难，那么就只能通过修复关键数据库文件，再尝试修复文件结构，以这样的方式来恢复数据库。由于此时涉及到对硬件结构、文件系统、数据库结构的深入分析，因此要求服务商有极强的综合技术能力。
      

   飞客最擅长 Oracle 和 SQL Server 数据库的恢复，主要包括以下数据库修复技术：
     ORACLE 恢复修复
  1 undo 、 system 表空间损坏的恢复。
  2 误 delete 数据的恢复、误删除表空间 drop 、 truncate 表的恢复。
  3 各种 ora- 错误的修复。
  4 DMP 文件不能导入数据库以及 LOB 数据恢复等情况。
  5 oracle 数据库中数据文件出现坏块情况下的恢复。
  6 oracle 数据库无数据文件但有有日志的情况下的恢复。
  7 能够在系统表和表空间文件丢失，变成 0 字节下完整的恢复数据。
  9 只要没有覆盖表空间文件，我都有信心恢复数据。无论你是什么系统（ Windows 、 UNIX 等），无论什么存储设备（硬盘、磁盘阵列）
      SQL Server 修复
        1. 如完全丢失数据库文件，用一般数据恢复方式不能恢复
        2. 表被删除，甚至被重写，表行被删除。
        3. 索引错误，或者 IAM 断裂。
        4. 数据库大面损坏，可以指定任意表或者字段提取数据。
        5. 系统表损坏甚至完全损坏。可以提取指定数据。

公司网站：http://www.fix.com.cn

学习,以备不时之需要