妈的,这次事情经过很简单但是过程还是比较曲折,想起这次误操作导致数据库停机1个多小时然后还要被领导骂个狗血淋头就很蛋疼,本来是一次简单的在服务器上逻辑卷扩容,但是我在写命令的时候从自己的笔记里面复制出来一个收缩的命令。
本来这是扩容 lvextend -L +50G /dev/VolGroup/lv_root
我复制成了lvreduce -L -51G /dev/VolGroup/lv_home
这两个命令一起我又没仔细看。。而且使用格式也差不多,所以敲下去在刷新之后整个LV就掉了,我当时刚敲下去就感觉不对因为马上就卡了,根据我原来扩容的经验应该几秒就好然后就能在逻辑卷中看见增加的空间。这个逻辑卷上大概有240G左右的数据包括Oracle软件,运行之后直接整个逻辑卷就卸载了,而且死活挂不上去。。当时我还不知道是什么原因,仔细看了下命令才知道。。整个人都要崩溃了,但我突然又想起这个库是做了DG的所以还是能抢救,我赶紧切到备库,切完之后通知业务,但是业务又不想改连接,叫我把原主库恢复出来,只有试试。。我仔细想想我是做的收缩没做其他东西如果把LV扩成原来的大小应该能恢复出来,试了下果然就成功了,赶紧通知各位大哥。。虽然数据库能用了但是现在的问题是有两个主库,并且两个主库都有同时打开的时候也就是说SCN已经不一致了,这个问题百度了一下网上说只能重建备库,不过我还是自己摸索出了一个方式快速把备库搭建起来。
首先,因为使用的ADG所以基本上不存在数据丢失的情况,所以用下面的命令停止备库的standby日志应用
SQL> alter database recover managed standby database cancel;
完成备库standby日志应用
SQL> alter database recover mana