Site icon Database Tutorials

Failover From Broker

In order to make Failover from the broker, we need to set the Listener and TNS settings correctly.

Listener and TNS files of a SINGLE NODE Data Guard Environment whose broker configuration is as follows.

LISTENER.ORA

[Primary]

[PrimaryFS]

[Physical]

[Logical]

[PhysicalFS]

 TNSNAMES.ORA

The TNSNAMES.ORA file is the same in all instances.

After this information, Failover tests can be started.

1. We check if there is a problem by querying the broker configuration.

2. We question whether the Physical Standby Databases are ready for Failover.

3. It is checked whether the Primary Database is ready for Failover.

4. The failover process is started.

The reason for getting this error is that the broker is not logged in with the correct user. Since the failover process is triggered from Physical Standby, it must be connected to the Broker with Physical Standby.

5. Connect to Physical Standby Database from the broker.

6. The failover process is triggered.

7. We check if there is an error by querying the broker configuration.

The reason for the Warning in the Primary Database is that the Reinstate operations in the Physical Standby and Logical Standby have not been completed yet.

The reason for the Warning in Physical Standby is that the automatically starting Reinstate has not been completed yet. This can be seen when checked from Observer. If Fast-start Failover was DISABLE, Reinstate operation of the Original Primary Database would be done manually.

The reason for the Warning in Logical Standby is the requirement of Reinstate.

8. When the reinstate operation in the Observer is completed, the Broker configuration is queried again.

9. Reinstate operation for Logical Standby is triggered manually.

[Primary-DGMGRL] 10. The broker configuration is queried again.
11. We do the checks.

a. The statuses of the databases are queried.

b. Open modes, roles and protection modes of databases are queried.

c. Recovery modes of Standby Databases are queried.

12. Tests are entered.

a. Existing archive log sequence numbers are queried.

b. The archive sequence numbers are checked by performing the Log Switch operation.

The reason why the archive sequence number does not increase despite the Log Switch is the use of the wrong where condition. Since the databases eat RESETLOGS, the most recent RESETLOGS_TIME is written in the where condition.

c. The nls_data_format of the session is changed so that RESETLOGS_TIME can be seen in date and time format.

d. This date is written in the where condition and the archive sequence numbers are checked again.

The reason why there is no data in Physical Far SYNC is that this instance is not actively used after the specified RESETLOGS_TIME.

Logs are sent to Standby Databases via Primary Far SYNC instance.

e. It is checked whether the archive sequence number has increased by performing the Log Switch operation.

f. Finally, a table belonging to the TEST user is created and it is checked whether it also occurs in Standby databases.

i. We are querying the existing tables.

ii. We create a new table.

 

Exit mobile version