Instructions for Oracle Data Guard Failover __oracle

The failover of Oracle Data Guard was described in both previous articles, but there was no systematic explanation, so in this paper, DG's failover is described in a systematic note.

The processing of failover redo under physical data Guard

http://www.cndba.cn/Dave/article/883

Oracle Data Guard Linux Platform Physical Standby Build example

http://www.cndba.cn/Dave/article/893

Failover is a failed switch. In this case switching to the redo processing, it is very important. If handled well, there will be no data loss. Otherwise, there will be data loss.

In Oracle 11g, the Data Guard switch has a new feature: Flush redo.

Flush can transfer redo from the main library to the standby library. As long as the main library boots to the Mount state, flush can send archived and current online redo that are not sent to the repository.

Flush Syntax:

sql> ALTER SYSTEM FLUSH REDO to Target_db_name;

The target_db_name here is our db_unique_name name in the main library. Which is the Tnsnames.ora file configuration. Flush will upload the unsent redo from the main library to the repository and wait for redo to return to success after the standby library. So as long as flush success, then failover no main sentence is lost.

If our primary has not been able to boot to mount state, then we can only follow the previous method. That's how Oracle 10g operates.

A. Normal failover

1.1 Check Gap

Sql> Select thread#, low_sequence#, high_sequence# from V$archive_gap;

If so, copy the corresponding archive to the repository and register it

Sql>alter Database Register physical logfile ' FILESPEC1 ';

Note: If gap exists, it is not resolved. Then it is not normal to carry out a failover. Only a mandatory failover can be performed. There will be data loss in this case.

Sql> ALTER DATABASE activate physical standby database;

1.2 To solve the gap problem, to switch

1.2.1 Cancel Apply

sql> Recover managed standby database cancel;

1.2.2 End Apply

(1) in Oracle 10GR2 or later versions: if there is an alternate library log file on the standby library

sql> ALTER DATABASE recover managed standby database finish; --[force|wait|nowait]

When executing this command, if the network between the primary and standby is interrupted. Then the RFS process of the standby waits for the network to connect until the TCP times out. So in this case, we need to add the FOCE keyword.

(2) prior to Oracle 10GR2: no repository log files

sql> ALTER DATABASE recover managed standby database finish skip standby logfile;

Note: If this command is executed, the recover standby database cannot be performed;

1.2.3 to switch the repository to the main library

Sql> ALTER DATABASE commit to switchover to primary;

sql> shutdown immediate;

Sql> Startup

Two. Forcibly switch (activate)

2.1 Conditions of Use

When we switch normally, we need to use forced activation of the standby library when we are prompted for media recovery. Such as:

Sql> ALTER DATABASE COMMIT to switchover to PRIMARY;

ALTER DATABASE COMMIT to switchover to PRIMARY

*

ERROR at line 1:

Ora-16139:media Recovery Required

2.2 The problem of redo under forced activation

The point to note here is that after we commit to the main library and then shutdown abort, the online redo of the main library is automatically written to the last archive of the repository (size changes). We need to re-register the last archive of the standby when we recover.

Sql>alter Database Register physical logfile ' FILESPEC1 ';

If you say, the main library OS is the entire outage. At this time, online redo is not sent to the standby. So we need to manually copy all online redo from the main library to the repository. Then proceed to recover.

The steps are as follows:

sql> ALTER DATABASE recover managed standby database cancel;

Database altered.

sql> recover standby database until cancel;

Ora-00279:change 509016 generated at 11/05/2010 11:40:27 for thread 1

Ora-00289:suggestion:/u01/archive/1_17_734225750.dbf

Ora-00280:change 509016 for thread 1 was in sequence #17

--By default, you will be prompted to archive 17, and in fact this sequence of 17 of the archive has not yet been generated, we ignore it and use the redo log we just came over to recover.

Specify log: {<ret>=suggested | AUTO | CANCEL}

/u01/app/oracle/oradata/orcl/redo01.log--Note that I wrote this position manually.

Log applied.

Media recovery complete.

It's done here once. There are actually three redo, and if you are unsure which redo to use, you can only try one.

When we use the Recover standby database until cancel, we can only use the force-activation standby, and if normal mode is used, we are prompted to:

Ora-16139:media Recovery Required

2.3 Force to activate a standby:

sql> ALTER DATABASE recover managed standby database cancel;
sql> recover standby database until cancel;

Sql>alter database activate standby database;
Sql>shutdown immediate;

Sql>startup

Three. Switchover

3.1 Main Library operations:

(1) View status:

Sql>select switchover_status from V$database;

(2) switching

Sql> ALTER DATABASE commit to switchover to physical standby with session shutdown;

sql> shutdown immediate;

Sql> startup;

Sql> ALTER DATABASE mount standby database;

sql> Recover managed standby database disconnect;

3.2 Backup operation:

Sql> ALTER DATABASE commit to switchover to primary with the session shutdown;

sql> shutdown Immediate

Sql> Startup