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

事情概况

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


沦入事故

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

1
2
3
4
5
6
7
8
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。



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

转载:http://2874575.blog.51cto.com/2864575/1360166