打开APP
userphoto
未登录

开通VIP,畅享免费电子书等14项超值服

开通VIP
After Test

Maybe we want to test Failover, although the Primary is working fine. After the failover succeeded, we have an OLD Primary then and a NEW Primary. There is a well documented way to convert the OLD Primary into a Standby. This procedure is called Reinstate. This posting shows how to make the NEW Primary a Standby again. The OLD Primary will keep on running as Primary – with all productive users connected there still. A special case why we may want to do that is because we tested Failover to a Snapshot Standby that has no network connection to the Primary.

The initial configuration:

DGMGRL> show configurationConfiguration - myconf  Protection Mode: MaxPerformance  Databases:    prima - Primary database    physt - Physical standby databaseFast-Start Failover: DISABLEDConfiguration Status:SUCCESS

The version is still 11.2.0.1 like in the previous posting. I will now failover to physt while prima keeps running. Attention: If there is a productive service started on the NEW Primary, make sure to stop it. Else new productive connections will access the NEW Primary! We will deliberately cause a Split Brain situation here with two Primary Databases. This may cause problems in a productive environment and is not recommended.

DGMGRL> failover to physt;Performing failover NOW, please wait...Error: ORA-16600: not connected to target standby database for failoverFailed.Unable to failoverDGMGRL> exit[oracle@uhesse ~]$ dgmgrl sys/oracle@phystDGMGRL for Linux: Version 11.2.0.1.0 - 64bit ProductionCopyright (c) 2000, 2009, Oracle. All rights reserved.Welcome to DGMGRL, type "help" for information.Connected.DGMGRL> failover to physt;Performing failover NOW, please wait...Failover succeeded, new primary is "physt"

The error above shows that we cannot failover, connected to the (still working) Primary but must connect to the Standby first. Now there are two Primary Databases:

[oracle@uhesse ~]$ sqlplus sys/oracle@physt as sysdbaSQL*Plus: Release 11.2.0.1.0 Production on Mon Jan 16 10:25:51 2012Copyright (c) 1982, 2009, Oracle.  All rights reserved.Connected to:Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing optionsSQL> select database_role from v$database;DATABASE_ROLE----------------PRIMARYSQL> connect sys/oracle@prima as sysdbaConnected.SQL> select database_role from v$database;DATABASE_ROLE----------------PRIMARY

I want to make the NEW Primary a Standby again. Similar to a Reinstate, that needs Flashback Logs. My two Databases generate Flashback Logs, so that requirement is met.

SQL> connect sys/oracle@physt as sysdbaConnected.SQL> shutdown immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL> startup mountORACLE instance started.Total System Global Area  313159680 bytesFixed Size            2212936 bytesVariable Size          264244152 bytesDatabase Buffers       41943040 bytesRedo Buffers            4759552 bytesDatabase mounted.SQL> flashback database to before resetlogs;Flashback complete.SQL> alter database convert to physical standby;Database altered.

This modified the controlfile and puts the Instance in NOMOUNT. We need to restart into MOUNT:

SQL> shutdown immediateORA-01507: database not mountedORACLE instance shut down.SQL> startup mountORACLE instance started.Total System Global Area  313159680 bytesFixed Size            2212936 bytesVariable Size          264244152 bytesDatabase Buffers       41943040 bytesRedo Buffers            4759552 bytesDatabase mounted.SQL> recover managed standby database using current logfile disconnect;Media recovery complete.SQL> select status,sequence# from v$managed_standby where process='MRP0';STATUS          SEQUENCE#------------ ----------WAIT_FOR_LOG         12

We want to see here APPLYING LOG – the redo is not yet transmitted from the OLD Primary.

SQL> connect sys/oracle@prima as sysdbaConnected.SQL> select sequence# from v$log where status='CURRENT'; SEQUENCE#----------    13SQL> alter system set log_archive_dest_2='service=physt db_unique_name=physt';System altered.SQL> alter system set log_archive_dest_state_2=enable;System altered.SQL> alter system switch logfile;System altered.SQL> connect sys/oracle@physt as sysdbaConnected.SQL> select status,sequence# from v$managed_standby where process='MRP0';STATUS          SEQUENCE#------------ ----------APPLYING_LOG         15

Everything is fine now on the Database Layer: OLD Primary is still Primary, NEW Primary is again Standby, applying Redo from the OLD Primary. Only the Data Guard Broker is confused now – we need to create a new configuration:

[oracle@uhesse ~]$ dgmgrl sys/oracle@primaDGMGRL for Linux: Version 11.2.0.1.0 - 64bit ProductionCopyright (c) 2000, 2009, Oracle. All rights reserved.Welcome to DGMGRL, type "help" for information.Connected.DGMGRL> show configuration;ORA-16795: the standby database needs to be re-createdConfiguration details cannot be determined by DGMGRL[oracle@uhesse ~]$ sqlplus sys/oracle@physt as sysdbaSQL*Plus: Release 11.2.0.1.0 Production on Mon Jan 16 10:46:13 2012Copyright (c) 1982, 2009, Oracle.  All rights reserved.Connected to:Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing optionsSQL> alter system set dg_broker_start=false;System altered.SQL> connect sys/oracle@prima as sysdbaConnected.SQL> alter system set dg_broker_start=false;System altered.SQL> exitDisconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing options[oracle@uhesse ~]$ rm $ORACLE_HOME/dbs/dr*

The above deleted the Broker Config Files. Now we create a new Broker Configuration:

[oracle@uhesse ~]$ sqlplus sys/oracle@physt as sysdbaSQL*Plus: Release 11.2.0.1.0 Production on Mon Jan 16 10:48:22 2012Copyright (c) 1982, 2009, Oracle.  All rights reserved.Connected to:Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit ProductionWith the Partitioning, OLAP, Data Mining and Real Application Testing optionsSQL> alter system set dg_broker_start=true;System altered.SQL> connect sys/oracle@prima as sysdbaConnected.SQL> alter system set dg_broker_start=true;System altered.[oracle@uhesse ~]$ dgmgrl sys/oracle@primaDGMGRL for Linux: Version 11.2.0.1.0 - 64bit ProductionCopyright (c) 2000, 2009, Oracle. All rights reserved.Welcome to DGMGRL, type "help" for information.Connected.DGMGRL> create configuration mycon as primary database is prima connect identifier is prima;Configuration "mycon" created with primary database "prima"DGMGRL> add database physt as connect identifier is physt maintained as physical;Database "physt" addedDGMGRL> enable configuration;Enabled.DGMGRL> show configuration;Configuration - mycon  Protection Mode: MaxPerformance  Databases:    prima - Primary database    physt - Physical standby databaseFast-Start Failover: DISABLEDConfiguration Status:SUCCESS

That was it :-)

Like this:

Like Loading...

Related

本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请点击举报
打开APP,阅读全文并永久保存 查看更多类似文章
猜你喜欢
类似文章
使用transport tablespace将表和数据从一个用户下快速迁移到另一个用户
1.oracle登陆
打开关闭ORACLE
11g Dataguard中的snapshot standby特性(r8笔记第49天)
ora-01031:insufficient privileges解决方法总结 - inf...
oracle中注释都是问号?中文显示不出来问题
更多类似文章 >>
生活服务
热点新闻
分享 收藏 导长图 关注 下载文章
绑定账号成功
后续可登录账号畅享VIP特权!
如果VIP功能使用有故障,
可点击这里联系客服!

联系客服