首页 » ORACLE 9i-23ai » Oracle Dataguard在standby failover后如何加回原primary？

Oracle Dataguard在standby failover后如何加回原primary？

  • 2020/11/16
  • ORACLE 9i-23ai
  • 120 views
  • Oracle Dataguard在standby failover后如何加回原primary？已关闭评论

今天谈起一种场景，如果oracle dataguard环境中，primary db长时间不可用或出现永久性故障，那么我们必须考虑failover到备用数据库以使其成为新的主数据库。之后，我们还要重建旧的主库，使其成为新的备库。关于备库在failover激活后，再次回到备库，Gavin Soorma在他的blog上有详细的测试记录。

同事说db2 可以实现上面的情况，而不用重建standby，postgresql听说pg_rewind，faildover后如果WAL没覆盖，可以快速重构原主库，那oracle dataguard是否如果redo 归档日志都存在，是否也可以在备库failover后，原primary库在修好后重新以standby身份加回Dataguard，而不用重新搭建呢？

最好操作前的一个rman全库备份，如果在failover失败时提供帮助。 以下操作有一个前提是原primary开启flashback database.

Step 1  Flush any unsent redo from the primary database to the target standby database.
  • If the primary database can be mounted
  1. Ensure that Redo Apply is active at the target standby database.
  2. Issue the following SQL statement at the primary database
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;

--For target_db_name, specify the DB_UNIQUE_NAME of the standby database
  •  If the primary database cannot be mounted
  1. Query the V$ARCHIVED_LOG view on the target standby database to obtain the highest log sequence number for each redo thread. If possible, copy the most recently archived redo log file for each primary database redo thread to the standby database if it does not exist there, and register it. This must be done for each redo thread.
  2. Identify and resolve any archived redo log gaps. If possible, copy any missing archived redo log files to the target standby database from the primary database and register them at the target standby database. This must be done for each redo thread.
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#)OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
Step 2   Run the below steps on the standby server
  • a) alter database recover managed standby database cancel; (Must return “Database altered” message quickly.)
  • b) alter database recover managed standby database finish; (Must return “Database altered” message quickly.)

If the error condition cannot be resolved, a failover can still be performed (with some data loss) by issuing the following SQL statement on the target standby database

  • c) alter database activate standby database; (Must return “Database altered” message quickly.)

At this stage, the database role must be turned as PRIMARY

  • d) shutdown immediate;
  • e) startup;
  • f) select to_char(standby_became_primary_scn) from v$database;  (NOTE THIS SCN value)
Now, it is strongly recommended to take a full database backup.
Rebuild OLD primary database
Step 3  Run the below steps on the old primary server (which had a permanent problem that made you to do the failover in the first place).
  • 1) shutdown immediate; (If it is already in running status)
  • 2) startup mount;
  • 3) flashback database to SCN nnnnn (Replace nnnnn with the actual SCN value noted in #f above)
  • 4)  alter database convert to physical standby;
  • 5) alter database recover managed standby database disconnect from session;
(This will start the managed recovery process – MRP0 in the background)
  • 6) select database_role from v$database; (Must show PHYSICAL STANDBY)
  • 7) select switchover_status from v$database;
It can show either “SWITCHOVER PENDING” or “NOT ALLOWED”. Both are valid values.
打赏

,

对不起，这篇文章暂时关闭评论。

上一篇：

下一篇：