DG unresolvable gap gap sequence备库恢复
案例
环境：2节点RAC asm + 单实例DG备库 ，备库用的是文件系统来存放数据文件，未用ASM；RAC一节点上部署有ogg。
在主库上通过在线重定义对表做分区，创建分区表空间时备库上创建数据文件失败，
导致日志传到备库无法应用，备库停止日志应用。
rman备份清理归档的脚本无法及时清理归档导到主库、备库归档磁盘空间均出现满的现象，ogg进程不工作，进程正常，只是time since chkpt 持续升高。
清理了归档后，备库可以接收日志但不应用。查看DG switchover_status 为unresolvable gap 。下面进行备库的恢复。
备库中的alert日志信息如下：
ManagedStandbyRecoverystartingRealTimeApplyTueApr0708:39:572015Errorsinfile/u01/app/oracle/diag/rdbms/centerdg/center/trace/center_dbw0_4645.trc:ORA-01186:file63failedverificationtestsORA-01157:cannotidentify/lockdatafile63-seeDBWRtracefileORA-01111:namefordatafile63isunknown-renametocorrectfileORA-01110:datafile63:'/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00063'File63notverifiedduetoerrorORA-01157Errorsinfile/u01/app/oracle/diag/rdbms/centerdg/center/trace/center_dbw0_4645.trc:ORA-01186:file201failedverificationtestsORA-01157:cannotidentify/lockdatafile201-seeDBWRtracefileORA-01110:datafile201:'+DATA'File201notverifiedduetoerrorORA-01157MRP0:BackgroundMediaRecoveryterminatedwitherror1111Errorsinfile/u01/app/oracle/diag/rdbms/centerdg/center/trace/center_pr00_5770.trc:ORA-01111:namefordatafile63isunknown-renametocorrectfileORA-01110:datafile63:'/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00063'ORA-01157:cannotidentify/lockdatafile63-seeDBWRtracefileORA-01111:namefordatafile63isunknown-renametocorrectfileORA-01110:datafile63:'/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00063'ManagedStandbyRecoverynotusingRealTimeApplySlaveexitingwithORA-1111exception
处理思路：
1.停ogg
2.置分区表空间cdtbs_par2-10 ,idxtbs_2-10 readonly [表空间来源于下面的查询create_change#>备库当前SCN号，其中备库的cdtbs_par1也没有，但未查出来].
3.拷贝分区表空间对应的数据文件。
4.增备，做恢复。
具体操作：
1.置表空间为read only:
--在此之前先查出备库scn号。
selectcurrent_scnfromv$database;10329528031425
--主库上查询
select'altertablespace'||b.name||'readonly;'fromv$datafilea,v$tablespacebwherea.CREATION_CHANGE#>=10329528031425anda.TS#=b.TS#;altertablespaceCDTBS_PAR2readonly;altertablespaceCDTBS_PAR3readonly;altertablespaceCDTBS_PAR4readonly;altertablespaceCDTBS_PAR5readonly;altertablespaceCDTBS_PAR6readonly;altertablespaceCDTBS_PAR7readonly;altertablespaceCDTBS_PAR8readonly;altertablespaceCDTBS_PAR9readonly;altertablespaceCDTBS_PAR10readonly;altertablespaceIDXTBS_2readonly;altertablespaceIDXTBS_3readonly;altertablespaceIDXTBS_4readonly;altertablespaceIDXTBS_5readonly;altertablespaceIDXTBS_6readonly;altertablespaceIDXTBS_7readonly;altertablespaceIDXTBS_8readonly;altertablespaceIDXTBS_9readonly;altertablespaceIDXTBS_10readonly;
--因为发现备库上是没有cdtbs_par1表空间对应的数据文件，处理方法如上，先read only后静态拷贝到备库。
alter tablespace CDTBS_PAR1 read only;
2.拷贝文件到备库上。
先从ASM上拷贝到本地文件系统上：
cpCDTBS_PAR1.345.875609233/home/gridcpCDTBS_PAR2.346.875609279/home/grid/archcpCDTBS_PAR3.347.875609293/home/grid/archcpCDTBS_PAR4.348.875609307/home/grid/archcpCDTBS_PAR5.349.875609319/home/grid/archcpCDTBS_PAR6.350.875609333/home/grid/archcpCDTBS_PAR7.351.875609345/home/grid/archcpCDTBS_PAR8.352.875609359/home/grid/archcpCDTBS_PAR9.353.875609371/home/grid/archcpCDTBS_PAR10.354.875609385/home/grid/archcpIDXTBS_10.363.875609811/home/grid/archcpIDXTBS_2.355.875609535/home/grid/archcpIDXTBS_3.356.875609679/home/grid/archcpIDXTBS_4.357.875609687/home/grid/archcpIDXTBS_5.358.875609693/home/grid/archcpIDXTBS_6.359.875609699/home/grid/archcpIDXTBS_7.360.875609707/home/grid/archcpIDXTBS_8.361.875609713/home/grid/archcpIDXTBS_9.362.875609719/home/grid/arch
grid用户直接scp 拷贝,例句：
scpCDTBS_PAR10.354.875609385oracle@host:/datadg/center/datafilescpCDTBS_PAR[3,4,5,6]*oracle@host:/datadg/center/datafile
--多个同时拷贝，批考例句：
scpIDXTBS_[2,3,4]*oracle@host:/datadg/center/datafilescpIDXTBS_[5,6,7,8,9]*oracle@host:/datadg/center/datafile
PS:拷贝后发现文件权限是对的，但是在备库上文件名全部转换成了小写，为了避免linux系统文件名大小写敏感，将文件名重命名为小写，但未验证大写的文件名是否有影响。
3.主库基于备库的SCN号做增备备份
--分配多通道加快速度，恢复时未用多通道耗时较长。
主库上做增备：
rmantarget/run{allocatechannelc1typedisk;allocatechannelc2typedisk;allocatechannelc3typedisk;allocatechannelc4typedisk;BACKUPINCREMENTALFROMSCN10329528031425DATABASEFORMAT'/home/oracle/upstd_%U_%p'tag'upstd';releasechannelc1;releasechannelc2;releasechannelc3;releasechannelc4;}backupcurrentcontrolfileforstandbyformat'/home/oracle/upstdctl_%U';
4.备库上操作，清理有问题的数据文件：
altersystemsetstandby_file_management=manual;alterdatabasecreatedatafile'/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00063'as'/datadg/center/datafile/cdtbs_par1.345.875609233';alterdatabasedatafile'/datadg/center/datafile/cdtbs_par1.345.875609233'offlinedrop;--alterdatabasedatafile'/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00063'offlinedrop;用此句应该等效上面2句，未验证。--然后静态readonly将对应的数据文件拷贝过来altersystemsetstandby_file_management=auto;
5.备库上恢复
rmantarget/catalogstartwith'/home/oracle/dgbak';recoverdatabasenoredo;shutdownimmediate;STARTUPNOMOUNT;RESTORESTANDBYCONTROLFILEFROM'/home/oracle/dgbak/upstdctl_9uq3rv22_1_1';alterdatabasemount;RMAN>alterdatabaseopen;RMAN-00571:===========================================================RMAN-00569:===============ERRORMESSAGESTACKFOLLOWS===============RMAN-00571:===========================================================RMAN-03002:failureofalterdbcommandat04/08/201516:32:47ORA-10458:standbydatabaserequiresrecoveryORA-01194:file1needsmorerecoverytobeconsistentORA-01110:datafile1:'/datadg/center/datafile/system.260.797342827'
继续备库上操作：
SQL>setnum50SQL>selectcurrent_scnfromv$database;此处先应用日志SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEDISCONNECTFROMSESSION;SQL>selectfile#,status,namefromv$datafile;SQL>select*fromv$dataguard_status;ARC4:Beginningtoarchivethread1sequence171370(10331448528074-10331448899608)SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEcancel;SQL>alterdatabaseopenreadonly;SQL>ALTERDATABASERECOVERMANAGEDSTANDBYDATABASEusingcurrentlogfileDISCONNECTFROMSESSION;
附加后续DG相关信息
备库应用日志及打开到read only状态时alert中的一些信息：
备库上一些操作alert日志中的提示信息，虽然显示的是报错，但其实可以不用管，只是一个信息提示。
mount状态 取消日志应用报错ORA 16037：
ALTERDATABASERECOVERMANAGEDSTANDBYDATABASECANCELMRP0:BackgroundMediaRecoverycancelledwithstatus16037Errorsinfile/u01/app/oracle/diag/rdbms/centerdg/center/trace/center_pr00_6282.trc:ORA-16037:userrequestedcancelofmanagedrecoveryoperationThuApr0908:32:092015Recoveryinterrupted!Recovereddatafilestoaconsistentstateatchange10331906716894ThuApr0908:32:102015MRP0:BackgroundMediaRecoveryprocessshutdown(center)ThuApr0908:32:102015ManagedStandbyRecoveryCanceled(center)Completed:ALTERDATABASERECOVERMANAGEDSTANDBYDATABASECANCELThuApr0908:32:382015
将备库打开提示临时表空间数据文件无法锁定，可忽略，临时表空间会自动处理：
DataGuardBrokerinitializing...DataGuardBrokerinitializationcompleteThuApr0908:32:412015SMON:enablingcacherecoveryDictionarycheckbeginningThuApr0908:32:462015RFS[6]:Selectedlog26forthread2sequence189031dbid-68775212branch797342936ThuApr0908:32:532015Errorsinfile/u01/app/oracle/diag/rdbms/centerdg/center/trace/center_dbw0_4855.trc:ORA-01157:cannotidentify/lockdatafile201-seeDBWRtracefileORA-01110:datafile201:'+DATA/center/tempfile/temp.264.797342939'ORA-17503:ksfdopn:2Failedtoopenfile+DATA/center/tempfile/temp.264.797342939ORA-15001:diskgroup"DATA"doesnotexistorisnotmountedORA-15077:couldnotlocateASMinstanceservingarequireddiskgroupORA-29701:unabletoconnecttoClusterSynchronizationServiceErrorsinfile/u01/app/oracle/diag/rdbms/centerdg/center/trace/center_dbw0_4855.trc:ORA-01186:file201failedverificationtestsORA-01157:cannotidentify/lockdatafile201-seeDBWRtracefileORA-01110:datafile201:'+DATA/center/tempfile/temp.264.797342939'File201notverifiedduetoerrorORA-01157ThuApr0908:32:532015DictionarycheckcompleteCannotre-createtempfile+DATA/center/tempfile/temp.264.797342939,thesamenamefileexistsErrorsinfile/u01/app/oracle/diag/rdbms/centerdg/center/trace/center_dbw0_4855.trc:ORA-01157:cannotidentify/lockdatafile201-seeDBWRtracefileORA-01110:datafile201:'+DATA/center/tempfile/temp.264.797342939'ORA-17503:ksfdopn:2Failedtoopenfile+DATA/center/tempfile/temp.264.797342939ORA-15001:diskgroup"DATA"doesnotexistorisnotmountedORA-15077:couldnotlocateASMinstanceservingarequireddiskgroupORA-29701:unabletoconnecttoClusterSynchronizationServiceDatabaseCharactersetisZHS16GBKNoResourceManagerplanactivereplication_dependency_trackingturnedoff(noasyncmultimasterreplicationfound)ThuApr0908:32:552015ArchivedLogentry485addedforthread2sequence189030ID0xfd3d5b54dest1:Physicalstandbydatabaseopenedforreadonlyaccess.Completed:alterdatabaseopenreadonly
到此备库已恢复成功。
在此附上惜纷飞的基于Data Guard出现gap sequence修复的案例，只是其中无创建数据文件。
http://www.xifenfei.com/1176.html
声明：本站所有文章资源内容，如无特殊说明或标注，均为采集网络资源。如若本站内容侵犯了原著者的合法权益，可联系本站删除。
