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;

Data Guard Startup & Shutdown Steps

Oracle Data Guard Startup & Shutdown Steps

Follow the correct steps to start up and shut down Oracle Data Guard environments.

In this article we will look at Oracle Data Guard startup and shutdown sequence. You must follow proper shutdown order to perform a graceful shutdown.

Data Guard Shutdown Sequence

Stop log apply service or MRP and shutdown the standby

on Standby

=========

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> SHUT IMMEDIATE;

Stop log shipping from primary and shutdown primary database

on primary

========

SQL> ALTER SYSTEM SET log_archive_dest_state_2='DEFER';

SQL> SHUT IMMEDIATE;

Data Guard Startup Sequence

Startup primary database and enable log shipping

on primary

========

SQL> STARTUP;

SQL> ALTER SYSTEM SET log_archive_dest_state_2='ENABLE';

Startup standby and enable log apply service or MRP

on standby

=========

SQL> startup nomount;

SQL> alter database mount standby database;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

DBCA silent mode 12C

 

Create Database using DBCA silent mode

on primary

==========

dbca -silent -createDatabase -templateName General_Purpose.dbc -gdbName test -sid test -createAsContainerDatabase false -emConfiguration NONE -datafileDestination /u01/data/db_files  -storageType FS -characterSet AL32UTF8 -totalMemory 1500 -recoveryAreaDestination /u01/app/oracle/FRA

Enter SYS user password:  EnterCDB#123

Enter SYSTEM user password:  EnterCDB#123

keep both same

Verify

[oracle@prm ~]$ cat /etc/oratab | grep -i test

ps -ef | grep pmon

sqlplus / as sysdba

SQL> select name,open_mode,cdb from v$database;

NAME      OPEN_MODE            CDB
--------- -------------------- ---
test   READ WRITE           NO <------ NON-CDB

SQL> show con_name

CON_NAME
------------------------------
test
SQL> archive log list