Oracle Data Guard fail over using Broker

-

 This topic  demonstrates how to  fail over on Oracle 11g data guard environment.


The below scenario is tested in 11.2.0.4 version. The following database is used for fail over testing.

Data Guard
Database
Primary
devdb12
Standby
devdb12_dg

The manual fail over is tested from primary(devdb12) to standby(devdb12_dg). 

Things to check prior to fail over :

Make sure, application is down and no application connection on the database.

Verify the data guard replication  and see standby is close to primary. we need to ensure that, all the archive logs are shipped to standby and applied successfully. If not, then there will be data loss after fail over.

If we  have multiple standby, then it is better to choose the standby which has highest log sequence# to  minimize the data loss.

Generally Fail over can be done for the following circumstances
  • Primary  is crashed
  • Primary is not performing well
  • Primary database is in mount mode and not able to open the database  
Prerequisite : The data guard broker should be configured on the database.  Click  here to review the broker configuration steps in case you need.


>dgmgrl
DGMGRL for Linux: Version 11.2.0.3.0 - 64bit Production

Copyright (c) 2000, 2009, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
DGMGRL> connect /
Connected.
DGMGRL> show configuration;

Configuration - devdb12_dg_broker

 Protection Mode: MaxPerformance
  Databases:
    chfsdb43    - Primary database
      Error: ORA-16810: multiple errors or warnings detected for the database

    devdb12_dg - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
ERROR

DGMGRL> failover to devdb12_dg;
Performing failover NOW, please wait...
Error: ORA-16798: unable to complete recovery during failover

Failed.
Unable to failover
DGMGRL> failover to devdb12_dg immediate;
Performing failover NOW, please wait...
Failover succeeded, new primary is "devdb12_dg"
DGMGRL> exit



After fail over, we need to rebuild the standby or flash back to prior stage and apply the archive log files.

Comments

Post a Comment

Popular posts from this blog

Step by Step: How to troubleshoot a slow running query in Oracle

-
This is a day to day task of a DBA. Someone from application team comes to our desk and simply says a query is running slow. We may question him on many things but ultimately a DBA has to tune the query at the end. This is also very popular and known question for the DBA's who are attending interviews. This question is simply asked again and again. I have also been asked this question multiple times. After a pause, interviewer simply asks...so suppose a user comes and reports that his query is running slow, what will be your approach to tune this. There is no absolute or concrete answer to this question because there might be multiple way to tune a slow running query. Everyone can have a different approach. So here is my approach: Very first thing we have to find which type of query is running slow. Whether it is SELECT query of DML statements(insert, update, delete and merge). So first we will see how to tune a SELECT query Step 1 – Find the SQL_ID of the
Read more

Register Archive log file manually in standby Database

-
  Some time, the archive logs are not shipping to standby location due to network issue.  There may be  several  archive logs are waiting in standby location for one archive log file. For instance, Archive log sequence # 100 is not shipped to standby location. But other archive logs(sequence#101 to sequence#200) were shipped to standby and it is waiting to ship the sequence# 100.  In this scenario, DBA can copy the archive log file and register manually. Once manually registered, the sequence#101 to sequence#200 will apply automatically on standby database. Step 1 Let us assume, the archive log file devdb12_1_283_801988635.arc is not shipped to standby due to some reason. Copy the archive log file devdb12_1_283_801988635.arc manually from primary to standby archive destination location. Step  2 Run the below command in standby database. ALTER DATABASE REGISTER LOGFILE '/dbArch/oradata/devdb12/ devdb12_1_283_801988635.arc';   Step  3 Verify the standby database and see if the co
Read more

How to check UNDO tablespace usage and who is using more undo

-
Query To check UNDO tablespace usage: ================================ set linesize 152 col tablespace_name for a20 col status for a10 select tablespace_name,status,count(extent_id) "Extent Count", sum(blocks) "Total Blocks",sum(bytes)/(1024*1024*1024) spaceInGB from   dba_undo_extents group by  tablespace_name, status having tablespace_name=upper('&TSNAME') order by tablespace_name; Query To check who is using more UNDO space: ===================================== SET termout ON SET heading ON SET PAGESIZE   6000 SET LINESIZE   200 COLUMN pgm_notes    FORMAT a80        HEADING 'Notes' COLUMN rbs          FORMAT a16         HEADING 'RBS'             JUST center COLUMN oracle_user  FORMAT a12        HEADING 'Oracle|Username' COLUMN sid_serial   FORMAT a12        HEADING 'SID,Serial' COLUMN unix_pid     FORMAT a6         HEADING 'O/S|PID' COLUMN Client_User  FORMAT a14        HEADING 'Cl
Read more