Rebuild Primary After Failover

 Post failover, there are two methods of rebuilding your failed primary

• Method 1:Rebuild from scratch RMAN duplicate

• Method 2: Flashback database only if Flashback was enabled

• 
  

In our earlier activity, we have performed Failover. Current state of your servers should be

because we have performed Failover.

action:

Let’s crash primary (test): In order to simulate failure, we will shut down the primary server test. As root user, shutdown the server without shutting down DB.

On new primary

newpr>Select to_char(standby_became_primary_scn) from v$database;

This is sin when standby became primary

On crush primary server  

connect and restart it and now server is up and running . So you admin told you that they have rebuild the server and you can connect to the server

1st step: 

Su - oracle

Start listener

Lsnrctl start listener

Sqlplus / as sysdba

Do not hist startup command here because check what is the role this server is ready to take after crush?

Answer : standby so crush primary is taking standby role now so do not hist status so standby should be in mount mode

And you should think the crush primary is still primary no it is taking standby role now

Take it to mount mode

stbSQL>startup mount;

Flashback the database back to the exact SCN where the standby was converted to primary

So on new primary what ever redo is generated we want that redo to flow back and to be applied onto the new standby that we are building now so with this we make it consistent with exact SCN number when standby became primary

prmSQL> flashback database to SCN 18151989;

Now we are telling data Guard configuration from now onward this server is going to act as standby 

So that’s why we need to convert this database to standby

prmSQL> alter database convert to physical standby;

prmSQL>Shut immediate;

SQL> exit

prm$Sqlplus / as sysdba

prmSQL>Startup mount;

Now start the MRP process to apply redo on new physical standby

prmSQL> alter database recover managed standby database disconnect;

At this stage check the sync of data Guard 

On new primary switch log

stbSQL> alter system switch log file;

/

/

On new physical standby check sync log

prmSQL> select process, status ,sequence# from v$managed_standby;

So with this we confirm our data Guard configuration is sync

Check client connectivity=================

To revert back to our original configuration simply do normal switchover action:

Perform Manual Switchover on Physical Standby

-----------------------------------------------------------

Connect to test database via client and keep querying below

sqlplus sys/sys@test as sysdba

 

select name, open_mode, db_unique_name, database_role from v$database;

 

NAME      OPEN_MODE      DB_UNIQUE_NAME         DATABASE_ROLE

--------- -------------- ---------------------- --------------

test    READ WRITE     test                 PRIMARY

Check primary and standby for any gaps

On primary:

===========

select STATUS, GAP_STATUS from V$ARCHIVE_DEST_STATUS where DEST_ID = 2;

 

On standby:

===========

select NAME, VALUE, DATUM_TIME from V$DATAGUARD_STATS;

We will first convert primary to standby and later standby to primary

On primary:

===========

select SWITCHOVER_STATUS from V$DATABASE;

You must see TO STANDBY or SESSIONS ACTIVE

SQL>alter database commit to switchover to physical standby with session shutdown;

 

SQL>startup mount;

At this stage, there is no primary to accept queries from client. Run below query on client putty terminal. The query will hang and wait until standby is converted to primary.

select name, open_mode, db_unique_name, database_role from v$database;

Convert standby to primary: Our primary is already converted to standby. Now it’s time to convert original standby into primary

select SWITCHOVER_STATUS from V$DATABASE;

 

SQL>alter database commit to switchover to primary with session shutdown;

 

SQL> alter database open;

At this stage, the client query would execute successfully!

On new standby – Initially your primary database: Start MRP

SQL>alter database recover managed standby database disconnect;