连错库误删100多张表

    炎炎厦日, 容易让人头脑发晕, 做错事情. 某地某位开发人员连错了数据库, 本来要连到测试库进行表重建的, 连到了产品库, 过了几分钟后, 猛然惊醒, 已发现删除了一百来张表, 业务立马被中止, 一堆人被拖到惊惶失措中.

    在事件发生后, 立马联系本站, 决定用AUL去恢复数据, 事发情景如下:

1, 事发后立马停止数据库.
2, 数据库在归档方式下, 删表归档文件还在.
3, 开发人员可以提供准确的重建表的语句.
4, 数据文件有十多GB, 有五万个存放在LOB中的图片.

    了解上述情况后, 立马让客户准备远程连接环境, 先是拷贝AIX上的数据文件到Windows上, 由AUL进行跨平台恢复; 然后是将Windows机器挂到Internet上, 由我进行远程操作; 约好晚上八点半开始, 经过三个小时的紧张恢复, 数据全部搞定. 步骤如下:

1, 从归档日志中找到删除的表的信息.
2, 扫描所有的数据文件, 生成Extent Map.
3, 在新的库中建立空表, 以便借用表结构.
4, 进行大部份表的数据恢复.
5, 再次扫描所有文件, 查找LOB索引段头块.
6, 恢复带LOB的少量表.

    能这么顺利完成任务, 也超出我自已的意料之外, 最主要的是删除表时的归档文件还在, 以及能提供准确的重建表的SQL语句, 以及AUL多年恢复Drop类操作的经验基础上的良好设计.

留言 (9)

一下子删除那么多表,真是汗~

小白有着落了:)

没有RMAN备份,做到时间点的恢复?

因为客户确认在发现删错表后,马上停止了数据库,因此从文件中直接恢复出来的数据都是准确的。

为什么不用tspitr或dbpitr,归档默认,有归档再,难道没有任何备份?哈哈

一是没有全备,二是归档日志也断号了。

请客吃饭吧,我的肠胃已经养好了。顺便买个爱死小白拍荷花,再弄个5D吧。

生产环境,没有standby?

生意啊

发表留言:

« Previous | Main | Next »

英语900句 | English 900

  • I haven't heard from him for a long time.
  • 我很久没有收到他的信了.
  • Send a postcard to me when you arrive in Shanghai.
  • 你到上海以后给我发张明信片.
  • I put some photographs in the envelope.
  • 我在信里夹了几张照片.
  • He hasn't answered my letter yet.
  • 他还没有给我回信.
  • My mother mailed me a parcel.
  • 我妈给我寄了一个包裹.