DG 主库fial over，强制激活备库解决案例

   14年1月份的时候，因硬件环境的变更，需要把库从原来的存储平台移到新的存储平台。也就是把数据库的底层存储介质更换一下。下面主要记录一下事故的发生及应对措施。

事情概况

   win平台，11R2，64位，单实例，DG物理备库。主库与备库均只有redo 和业务数据文件存储介质为fusion io卡，其它数据文件、控制文件等是存放在非fusion io卡介质上的。现需要将存储介质fusion io 卡更换为virident 卡。2种卡都是直接插在pci插槽上的，且两卡本身是由同一生产厂家生产过了。最主要是有人反应之前测试用时直接用文件拷贝方式来进行移库的。鉴于2种卡的拷贝速度很快，于是采用了直接数据文件卡对卡拷贝方式来进行换卡操作，然后将盘符改成原来一模一样的，卡的拷贝速度很快，忘了是几百M每秒，而且只拷贝存放在fusion io 卡上的数据文件到virident卡上，其它的数据文件及控制文件等 东西不需要移动。

沦入事故

   于是乎，先将各服务都关掉，主备库都shutdown。开始针对主库采取文件卡到卡的对拷。很快拷贝完了，盘符也改好了。于是启动主库，启动时报错如下：

Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\branch_p\branch\trace\branch_lgwr_2196.trc:
ORA-00313: ??????? 3 (???? 1) ???
ORA-00312: ???? 3 ?? 1: 'J:\REDO\BRANCH\REDO03.LOG'
ORA-01382: ?? 1 ???????? J:\REDO\BRANCH\REDO03.LOG????????? (4096) ???????? (512)
Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\branch_p\branch\trace\branch_lgwr_2196.trc:
ORA-00313: ??????? 3 (???? 1) ???
ORA-00312: ???? 3 ?? 1: 'J:\REDO\BRANCH\REDO03.LOG'
ORA-01382: ?? 1 ???????? J:\REDO\BRANCH\REDO03.LOG????????? (4096) ???????? (512)

虽然有乱码，但是从报错错误代码可以看出是无法打开日志组。经查发当无法打开的日志组为current。从ora-01382可知，是因为日志文件的block size比virident卡的磁盘扇区大小要大。所以日志组无法打开。

开始没注意到ora-01382这个错误，心想先想办法把库给拉起来，于是使用命令alter database clear unarchived logfile group 3;

       可是报错依旧如上。后来找到解决ORA-01382这个错误了，用 alter system set "_disk_sector_size_override"=true;   更改参数解决启动报错无法打开日志的问题，然后继续启动数据库，结果能正常启动，但是库依旧执行前面的clear log操作，这一clear了就会使得数据有丢失，于是就赶紧cancel。然后把拷贝到virident卡上面的数据全部清空，准备重新将fusion io卡上的数据拷贝过来。然后在库startup mount后设置隐含参数 _disk_sector_size_override值再open库。

        已经将virident卡上的数据清掉了，再次将原数据文件拷贝过来了，正拷贝过程中想到，这时的控制文件已经在之前clear log时SCN发生了变化。fusion io卡上的数据文件头scn已经与此时控制文件的scn不一致了，数据库是无法打开了。之前clear log期间发生的日志切换（也就是生成的archivelog ）也都清了，这样归档日志文件也不连续了。备库与主库之前的日志出现gap了。

事故解决

       现在有2种解决方法。在拷贝文件之前做了一个rman备份，此备份是在停掉业务时，准备换卡前做的备份，所以用它数据绝不会挂失，我们可以用rman备份文件来做恢复。另一种方法是换卡前已确保发生了业务的数据全部传入备库，所以可以把备库拉起来当主库用。此时的DG环境是主库fail over了，备库东西都完好。

       定下一步的解决方案。

    鉴于rman备份文件恢复起来速度过慢。而我们距离正常业务开展时间少于3个小时。然后决定采取将备库拉起来当主库用这种方法。但是备库一样要把fusion io卡上的数据移到virident卡上，还是采取文件对拷方式。省时。

       这次在拷贝前（库已停）静态备份所有的数据文件，以防再次发生在主库上面的错误。备份完后，将fusion io卡上的数据物理拷贝到virident卡上，并把盘符互换，接下来库startup mount ， alter system set "_disk_sector_size_override"=true; 再open read only。可以正常打开。好了，存储介质更换成功了。下一步是要把备库激活当主库用，是强制激活备库，关库启动到mount，使用命令alter database activate standby database; 打开了备库，再次重启一下备库。连上业务系统，能正常使用。于是再关机，拔下fusion io 止。到了正常业务操作时间，此库已经可以当生产库来用了。原来的主库就废掉，重新建一个physical standby。

总结：不管做什么先备份。备份好后再做事。做事前提前演练操作，冷静处理问题。