商务网站开发意义,西宁企业网站建设公司,个人简单app的开发流程,360云盘做服务器建设网站今天碰到一个有些奇怪的问题#xff0c;但是奇怪的现象背后都是有本质的因果。下午在做一个环境的检查时#xff0c;发现备库是在mount阶段#xff0c;这可是一个11gR2的库#xff0c;没有ADG实在是太浪费了#xff0c;对于这种情况感觉太不应该了。所以尝试启动至open阶段…今天碰到一个有些奇怪的问题但是奇怪的现象背后都是有本质的因果。下午在做一个环境的检查时发现备库是在mount阶段这可是一个11gR2的库没有ADG实在是太浪费了对于这种情况感觉太不应该了。所以尝试启动至open阶段发现状态一直是read only,在ADG中应该是READ ONLY WITH APPLY才对啊。使用dg broker设置为READ-ONLY,备库的数据库日志如下Standby Database: stestdb3, Enabled Physical Standby (0x02010000)08/14/2014 16:03:28version check on database stestdb3 detected stale metadata,requesting update from primary databaseCreating process RSM012/29/2015 16:28:11Command EDIT DATABASE stestdb3 SET STATE READ-ONLY completedRead-Only state no longer supported12/29/2015 16:29:10似乎也看不出来什么端倪。使用dg broker查看一下。发现报了下面的错误。DGMGRL show configuration;Configuration - testdbProtection Mode: MaxPerformanceDatabases:testdbbak93 - Primary databasestestdb3 - Physical standby databaseError: ORA-16766: Redo Apply is stoppedFast-Start Failover: DISABLEDConfiguration Status:ERROR查看dg broker的日志如下Data Guard Broker initializing...Data Guard Broker initialization completeTue Dec 29 16:47:15 2015SMON: enabling cache recoveryNo Resource Manager plan activePhysical standby database opened for read only access.Completed: alter database openTue Dec 29 16:47:16 2015idle dispatcher D000 terminated, pid (18, 1)Tue Dec 29 16:51:40 2015Primary database is in MAXIMUM PERFORMANCE modeRFS[3]: Assigned to RFS process 3596RFS[3]: Selected log 7 for thread 1 sequence 72606 dbid -1549369665 branch 746558785Tue Dec 29 16:51:41 2015RFS[4]: Assigned to RFS process 3590RFS[4]: Selected log 8 for thread 1 sequence 72605 dbid -1549369665 branch 746558785Tue Dec 29 16:51:42 2015Archived Log entry 69432 added for thread 1 sequence 72605 ID 0xa829ec3b dest 2:从上面的情况可以很明显看到确实MRP没有开始工作只有RFS在接收归档。然后使用dg broker把备库设置为ONLINE状态再次查看dg broker的检查发现检查就没有问题了。DGMGRL show configuration;Configuration - testdbProtection Mode: MaxPerformanceDatabases:testdbbak93 - Primary databasestestdb3 - Physical standby databaseFast-Start Failover: DISABLEDConfiguration Status:SUCCESS总体感觉这不是一个11g的库。然后再次尝试手工启动到open阶段然后可以看到备库还是READ ONLY,重启之后问题依然存在。对于这个问题最好的方式也还是查看日志这个备库是一年前重启的了庆幸的是数据库日志依然存在。从当时的启动情况来看也没有其它的错误。但是我注意到了compatible这个参数因为在11g的库中还是比较显眼的。所以这个参数引起了我的好奇。结果带着疑问在MOS一查果然有几篇相关的文章看来又碰上一个遗留问题而且有一个相关的BUG描述。ACTIVE DATAGUARD (ADG) NOT POSSIBLE WITH COMPATIBLE 11.1.0.0.0 (Doc ID 1363396.1)BUG:13032521 - ADG PHYSICAL STANDBY GOES TO MOUNT STATE INSTEAD OF READ ONLY WITH APPLY问题基本定位后主备库中查看这个参数都是10.2.0.5.0SQL show parameter compaNAME TYPE VALUE------------------------------------ ----------- ------------------------------compatible string 10.2.0.5.0那么按照bug描述的WA是设置备库的compatible为11.1.0.7以上这个参数的修改需要重启实例所以还是比较影响的主库目前是没法重启了。SQL alter system set compatible11.2.0.3.0;alter system set compatible11.2.0.3.0*ERROR at line 1:ORA-02095: specified initialization parameter cannot be modified现在备库设置一番先看看行不行。SQL alter system set compatible11.2.0.3.0 scopespfile;System altered.重启时可以看到备库的数据库日志有下面这么一段输出。Tue Dec 29 17:25:26 2015Spfile /U01/app/Oracle/product/11.2.3/db_1/dbs/spfiletestdb.ora is in old pre-11 format and compatible 11.0.0; converting to new H.A.R.D. compliant format.Completed: alter database mount但是再次设置为ONLINE查看数据库状态依旧是MOUNTSQL select open_mode from v$database;OPEN_MODE--------------------READ ONLY看来备库修改还不行主库也得修改一致。不过查看数据库日志可以看到下面的这么一段内容发现MRP启动失败。ALTER DATABASE RECOVER MANAGED STANDBY DATABASE THROUGH ALL SWITCHOVER DISCONNECT USING CURRENT LOGFILEAttempt to start background Managed Standby Recovery process (testdb)Tue Dec 29 17:57:03 2015MRP0 started with pid29, OS id17740MRP0: Background Managed Standby Recovery process started (testdb)started logmerger processTue Dec 29 17:57:08 2015Managed Standby Recovery starting Real Time ApplyParallel Media Recovery started with 16 slavesWaiting for all non-current ORLs to be archived...All non-current ORLs have been archived.Media Recovery Log /U01/app/oracle/fra/StestDB3/archivelog/2015_12_29/o1_mf_1_72606_c84n0xml_.arcCompleted: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE THROUGH ALL SWITCHOVER DISCONNECT USING CURRENT LOGFILEErrors with log /U01/app/oracle/fra/StestDB3/archivelog/2015_12_29/o1_mf_1_72606_c84n0xml_.arcMRP0: Background Media Recovery terminated with error 38800Errors in file /U01/app/oracle/diag/rdbms/stestdb3/testdb/trace/testdb_pr00_17745.trc:ORA-38800: Cannot start Redo Apply on the open physical standby databaseManaged Standby Recovery not using Real Time ApplyRecovery interrupted!MRP0: Background Media Recovery process shutdown (testdb)看来这个参数变化影响确实不小备库先恢复正常状态再说等协调主库重启再处理了所以开始恢复参数原有的设置。把compatible设置为10.2.0.5.0?但是重启的时候就开始报错了。SQL alter database mount;alter database mount*ERROR at line 1:ORA-00201: control file version 11.2.0.3.0 incompatible with ORACLE version10.2.0.5.0ORA-00202: control file: /U01/app/oracle/oradata/testdb/control01.ctl这个问题看似还有余地在主库生成备库控制文件传输过去mount就没有问题了主库SQL alter database create standby controlfile as /tmp/std1.ctl;Database altered.?备库SQL alter database mount standby database;Database altered.但是这个时候查看备库的数据库日志发现问题貌似变麻烦了。文件头部已经修改已经不同步了。ALTER DATABASE RECOVER managed standby database disconnect from sessionAttempt to start background Managed Standby Recovery process (testdb)Tue Dec 29 18:28:13 2015MRP0 started with pid30, OS id24283MRP0: Background Managed Standby Recovery process started (testdb)started logmerger processTue Dec 29 18:28:18 2015Managed Standby Recovery not using Real Time ApplyRead of datafile /U01/app/oracle/oradata/testdb/system01.dbf (fno 1) header failed with ORA-01130Rereading datafile 1 header failed with ORA-01130MRP0: Background Media Recovery terminated with error 1110Errors in file /U01/app/oracle/diag/rdbms/stestdb3/testdb/trace/testdb_pr00_24288.trc:ORA-01110: data file 1: /U01/app/oracle/oradata/testdb/system01.dbfORA-01122: database file 1 failed verification checkORA-01110: data file 1: /U01/app/oracle/oradata/testdb/system01.dbfORA-01130: database file version 11.2.0.3.0 incompatible with ORACLE version 10.2.0.5.0Slave exiting with ORA-1110 exceptionErrors in file /U01/app/oracle/diag/rdbms/stestdb3/testdb/trace/testdb_pr00_24288.trc:ORA-01110: data file 1: /U01/app/oracle/oradata/testdb/system01.dbfORA-01122: database file 1 failed verification checkORA-01110: data file 1: /U01/app/oracle/oradata/testdb/system01.dbfORA-01130: database file version 11.2.0.3.0 incompatible with ORACLE version 10.2.0.5.0Recovery Slave PR00 previously exited with exception 1110MRP0: Background Media Recovery process shutdown (testdb)Completed: ALTER DATABASE RECOVER managed standby database disconnect from session对应的trace文件如下*** 2015-12-29 18:28:18.495 4320 krsh.cManaged Standby Recovery not using Real Time ApplyRead of datafile /U01/app/oracle/oradata/testdb/system01.dbf (fno 1) header failed with ORA-01130Rereading datafile 1 header failed with ORA-01130V10 STYLE FILE HEADER:Compatibility Vsn 1866472960xb200300Db ID27455976310xa3a67ebf, Db NametestDBActivation ID00x0Control Seq10x1, File size1472000x23f00File Number1, Blksiz8192, File Type3 DATATablespace #0 - SYSTEM rel_fn:1对于这种情况其实恢复备库11g的控制文件重启主库 应该就可以解决了但是重启主库还需要协调时间找维护窗口所以不是一蹴而就的事情那么这个期间容灾是重中之重一旦主库出了问题影响还是不小所以最后的无奈之举就是重建备库。当然搭建备库还是可以采用11g的active方式。rman target sysxxxxx auxiliary sysxxxx nocatalogRMAN duplicate target database for standby from active database nofilenamecheck;?然后就没有然后了就是备库搭建成功了看着白忙活一场心中像打翻了五味瓶。
