oracle 8i恢复

地点：南京某政府机关
数据库版本：oracle 8.1.7企业版本
操作系统：Windows
时间：2008-11-18

场景描述：接到电话，说因为因为数据迁移的需要，需要从A市将数据迁移到省级中心。但是因为A市数据库做的是双机热备，他们是从镜像磁盘上拷贝的文件。

 

    时间紧急,我立即去了现场，就这么一堆文件，其余什么都没有，晕啊，到了现场知道数据库的版本是oracle 817，先搞个817版本，身边没有啊，现在一般至少也用九了，谁还用这么老的版本，还好我可是收集了从oracle8-11的windows,linux下的安装文件，这次终于有用了，拿出来搞一把吧。
    说真的8i还是第一次恢复，接触的比较多的还是9,10。
    我还是按照常规的思维去解决吧。
    还好，在备份的时候警告日志文件提供给我了，这给我带了很大的方便，不用自己去猜测了，呵呵。
    首先是安装oracle817 for windows吧。安装非常的顺利。
    windows下先建立一个实例吧。oradim -new -sid XXX。再次建立后我就尝试连接进去。
    set oracle_sid后sqlplus " / as sysdba"总是报权限不足。我就查看了下sqlnet.ora文件，呵呵，默认是没这个文件，难道需要自己创建一个？于是我就自己建了一个加入SQLNET.AUTHENTICATION_SERVICES=(NTS)，这就是操作系统认证呀，这下应该是可以了吧。果真直接可以连接进去了。
    连进去后，启动数据库呀。那么我就需要构造参数文件了啊，参数文件当然是有模板的，主要是指定控制文件、后台的一些dump文件的路径，这要设置正确。然后我就开始nomount数据库了。
    startup nomount使用pfile指定参数文件，nomount成功，直接改变数据库到mount状态。这个时候我想，open时候肯定报错的。因为好多文件的路径，和原来操作系统的肯定是不一致的。那么我怎么得到原来数据库中文件的相关路径呢？其实仔细想想很简单啊，数据库的所有信息都记录在控制文件中，而数据库在mount阶段，控制文件已经加载，也就是可以读出控制文件中相关信息了，那么还怕找不出相关文件位置。

    既然如此，首要任务就是读取控制文件信息，记得在9i中是可以对控制文件做trace的，trace后控制文件的创建脚本就在相关的udump目录中。因此我执行了alter database backup controlfile to trace。果真在udump目录中，发现了控制文件的创建脚本，其中就包含了每个日志文件、数据文件相应的路径。在8i中好像alter database backup controlfile to trace as ''不可以。

    路径是找到了，可是目前的日志文件、数据文件与控制文件的信息不一致，如果控制文件不一致，这些文件是无法加载到oracle的。控制文件其实就是一个服务人员，记得以前有人做过一个形象的比喻，控制文件就是播放器，而数据文件就是一部电影，我们只有通过播放器才能看到电影，而同时播放器需要能够识别电影，那就需要播放器有相应的解析器。
    因此我现在就想控制文件应该能够正确的解析出数据文件，那么控制文件中的数据文件的路径必须和实际路径相符。要达到这个目的，就需要更改控制文件。
    alter database rename file 'E:\ORACLE\ORADATA\ORA8I\TOOLS01.DBF' to 'E:\oracle\oradata\TOOLS01.DBF';
    alter database rename file 'E:\ORACLE\ORADATA\ORA8I\REDO01.LOG' to 'E:\oracle\oradata\REDO01.log';
    ……

    而控制文件是在参数文件中指定的，密码文件在固定的路径中，参数文件我们可以在数据库启动时指定相应的路径。
    将全部的控制文件、日志文件的路径修改后，那么控制文件中的信息就和实际相符了。打开数据库吧。激动人心的时刻到来了。在执行打开数据库前，我就在猜想：如果open成功，那是最顺利的，备份时数据库就是一致的，否则可能需要不完全恢复，或者应用日志了。如果失败的话，因为我看到了许多归档日志，可能需要应用归档日志吧。或者部分不重要的文件有问题，比如tools表空间，还是非当前无活动事务的日志出了问题。这些都很好解决的。不过这个时候，挑战还是小点的好。
    alter database open;
    数据库直接打开了，这时一颗心也算是平静下来了。工作算是告以结束。

    紧急下来，帮忙配置了监听，重置了部分数据库用户密码。解决了乱码问题。数据库存储中文竟然使用us7ascii字符集，晕啊。后来他们倒数据时，发现了oracle 9i的exp无法导出oracle 8数据库的数据。

    总之：本次的数据恢复，一切都很顺利。哈哈。按照正常的思维进展就ok了。