出了件大事，我们一直负责维护的现事上班开小差，一开就一星期，结果刚好碰到带库罢工，整整一星期的数据没备份，真的不敢想象这件事让公司知道会不会把那同事生XXX了，一年200多万一个月约20万的代维费哪，幸好客户的数据系统没出什么事，否则-----不想象了，太可怕了。
客户备份系统的策略是：每天做归档保留一星期，每周做全备保留4星期，磁带异地保存一个周，下周循环，每月1号做全备永久保留，磁带异地保存一个月，下月循环。
当时的状态是11月28日是周日，刚好做了周全备；30日是周二客户取磁带的日子，约18点左右取走，接着带库罢工。结果是：11月30日18：00之后到12月6日之前的所有归档备份失败，12月1日的月备份失败，12月5日的周备份失败。
客户当时的要求是12月1日的数据库状态必须恢复，否则将会向公司提升这件事。吓得项目经理赶快找公司的DBA帮忙，但问题来了。首先是客户的数据库目前正常，肯定不能恢复回原数据库，但客户的平台是HPUNIX没有别的机器可用。其次按照归档的保留时间到12月6日的时候11月28日到29日的归档已经过期可能已经被12月6日的归档OVERWRITE掉了。最后检查时发现除一个最重要的实例有保留归档外，别的数据库的归档都被删除了。
针对上面的第一个问题，想起当初做数据库的恢复测试（项目验收时）的方法是把数据库恢复到小机双机系统的别一个STANDBY节点，跟客户沟通，同意此方法。针对上面后两个问题，发现理论上把数据库恢复到11月28日的备份再应用归档把数据库恢复到12月1日的不太可行，因为只有一个库有归档了。和客户沟通后应用归档恢复的方法也要做一下测试才知道是否生效，最后的指导思想是先做测试在测试的过程中找办法。好吧，我也只得这样，先做有归档的恢复。
恢复过程：
在目标机器创建与源数据库一致的环境，启动数据库为NOMOUNT状态，从磁带恢复控制文件，利用控制文件MOUNT上数据库，从磁带恢复数据库文件，再从磁带RECOVERY数据库，最后使用RESETLOGS打开数据库。
测试一：这个测试实例的数据库文件的恢复时间是到11月28日的23：59，但RECOVERY的时间是18：00.测试结果：成功。
测试二：将数据库关闭并启动到MOUNT状态利用DP软件将数据库直接恢复到12月1日18：00.测试结果失败。
测试三：将数据库关闭并删除所有数据文件，重新恢复数据文件到11月28日的状态，将11月28日之后的归档拷贝到目标库的相同路径，再利用DP将数据库恢复到12月1日。测试结果：成功。
分析：第三次测试的时候发现DP恢复数据时直接 从磁带导出数据，但读取的文件是12月6日、12月9日两个全备。感觉比较奇怪，12月6日、12月9日两个是全备份，备份的时间点比较晚，虽然全备的脚本里有归档的备份，但经过了一个星期所有在线日志都已经被OVERWRITE了吧，有点奇怪。
既然如此就用同样的方法尝试一下别的实例的恢复，测试结果也是成功。太爽了，虽然不能确定是不是在线日志有归档的原因，但总算是有个交代了。WOWOWOWOWO--------
阅读(1984) | 评论(0) | 转发(0) |
