Wednesday, October 5, 2011

DataGuard Broker And its Benefits

The Oracle Data Guard broker  is a distributed  management  framework that automates and centralizes  the creation, maintenance, and   monitoring  of  Data Guard configurations. The  following  describes  some of the operations the broker automates and simplifies 


I.) Adding  additional  new  or  existing (physical, snapshot, logical, RAC or non-RAC)  standby databases to  an existing Data Guard configuration, for a total of one primary database, and from 1 to 30 standby databases(in Oracle 11g) in the same configuration.


II.) Managing  an entire Data Guard configuration, including  all databases, redo transport services, and log apply services, through a client connection to any database in the configuration.


III.) Managing the protection mode for the broker configuration.

IV.) Invoking switchover or failover with a single command to initiate and control complex role changes across all databases in the configuration.


V.) Configuring failover to occur automatically upon loss of the primary database, increasing availability without manual intervention.


VI.) Monitoring the status of the entire configuration, capturing diagnostic information, reporting statistics such as the redo apply rate and the redo generation rate, and detecting problems quickly with centralized monitoring, testing, and performance tools.


Oracle Data Guard Broker Diagram :  The below diagram will help us to understand Data Guard Broker.






We can perform all management operations locally or remotely through the broker's easy-to-use interfaces: the Data Guard management pages in Oracle Enterprise Manager, which is the broker's graphical user interface (GUI), and the Data Guard command-line interface called DGMGRL.


Benefits of  Data Guard Broker : 
The broker's interfaces improve usability and centralize management and monitoring of the Data Guard configuration.The following benefits are : 


1.) Disaster protection :  By  automating  many of the manual tasks required to configure and monitor  a Data  Guard configuration, the broker enhances  the  high  availability,  data  protection, and  disaster protection capabilities that are inherent in Oracle Data Guard. Access is possible through a client to any system  in the  Data Guard  configuration, eliminating  any  single  point  o  failure. If  the  primary  database fails, the  broker automates  the  process  for  any  one of the standby databases to replace the primary database  and  take  over  production  processing. The  database  availability  that  Data Guard provides makes it easier to protect our data.

2.) Higher availability and scalability :  While  Oracle  Data Guard broker  enhances  disaster  protection by  maintaining  transitionally  consistent  copies  of  the  primary database,  Data Guard,  configured  with Oracle  high  availability solutions such as Oracle Real Application Clusters (RAC) databases.


3.) Automated creation of a Data Guard configuration :  The broker  helps us  to  logically  define  and create  a Data  Guard  configuration  consisting  of  a  primary  database  and  (physical  or  logical, snapshot, R AC or non-RAC)  standby  databases.  The  broker  automatically  communicates  between  the databases  in  a Data Guard configuration using Oracle Net Services. The databases can be local or remote, connected by a LAN or geographically dispersed over a WAN.


4.) Easy configuration of additional standby databases :  After  we  create  a  Data Guard  configuration consisting  of  a  primary  and  a  standby  database,  we can  add  up  to  eight  new  or  existing,  physical, snapshot, or logical standby databases to each Data Guard configuration. Oracle Enterprise Manager provides an Add Standby Database wizard to guide us through the process of adding more databases. 

5.) Simplified, centralized, and extended management : We can issue commands to manage many aspects of the broker configuration. These include:

I.> Simplify the management of all components of the configuration, including the primary and standby databases, redo transport services, and log apply services.


II.>  Coordinate  database  state transitions  and  update  database  properties  dynamically  with  the broker recording the changes in a broker  configuration  file  that  includes  profiles  of  all  the  databases  in  the configuration. The broker  propagates  the  changes  to  all  databases  in  the configuration and their server parameter files.


6.) Simplified switchover and failover operations : The  broker  simplifies  switchovers  and  failovers  by allowing  us  to  invoke  them  using  a  single  key  click  in  Oracle  Enterprise  Manager  or  a  single command  at  the  DGMGRL  command-line interface. Fast-start  failover  can  be configured  to occur  with no data loss or with a configurable amount of data loss.


7.) Built-in monitoring and alert and control mechanisms :  The  broker  provides  built-in  validation that  monitors  the  health  of  all  of  the  databases  in  the configuration. From  any  system  in  the configuration connected to  any   database, we  can capture  diagnostic  information  and detect obvious and subtle  problems  quickly  with  centralized  monitoring,  testing,  and  performance  tools. 

8.) Transparent to application :  Use  of  the broker  is  possible  for  any  database  because  the  broker works  transparently  with  applications;  no  application  code  changes  are  required  to  accommodate a configuration that we manage with the broker.


Relationship of Objects Managed by the Data Guard Broker :












Reference : http://download.oracle.com/docs/cd/B13789_01/server.101/b10822/concepts.htm




Enjoy      :-) 



Tuesday, October 4, 2011

ORA-16789: Standby Redo Logs Not Configured


This is very common error which occur during the switchover the standby database in Dataguard Broker. In my case when i switchover to standby the error occur as below : 

C:\>dgmgrl
DGMGRL for 32-bit Windows: Version 11.2.0.1.0 - Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.

DGMGRL> connect sys/xxxx@noida
Connected.

DGMGRL>  switchover to 'red';
Performing switchover NOW, please wait...
Error: ORA-16789: standby redo logs not configured
Failed.
Unable to switchover, primary database is still "noida"

This error generally occur because the Standby redo logs were not configured for the database.

Therefore,Standby redo logs are required when the redo transport mode is set to SYNC or ASYNC . Hence to solve this we have add standby redolog files on primary database . Below the command to this issue. 

On Primary Database: 

SQL> ALTER DATABASE add standby  LOGFILE GROUP 6  'C:\APP\NEERAJS\ORADATA\NOIDA\REDO06.LOG' size 50m ;
Database altered.

Now it's is not giving any further error .


Enjoy         :-) 

How to Drop/Rename Standby Redolog file in Oracle 11g

While performing the dataguard Broker, we need to drop the standby database while switchover the standby . As it seems an easy task but it is bit tricky . Below are the steps to drop the redolog file from standby database :

On Standby Database : 
SQL> select member,type from v$logfile;
MEMBER                                                                     TYPE                      
----------------------------------                                         -----------
D:\APP\STANDBY\ORADATA\REDO03.LOG      ONLINE
D:\APP\STANDBY\ORADATA\REDO02.LOG      ONLINE
D:\APP\STANDBY\ORADATA\REDO01.LOG      ONLINE
D:\APP\STANDBY\ORADATA\REDO04.LOG      STANDBY    
D:\APP\STANDBY\ORADATA\REDO05.LOG      STANDBY

Here,we have to drop the two standby redolog file .

SQL> alter database drop standby logfile group 4;
alter database drop standby logfile group 4
*
ERROR at line 1:
ORA-01156: recovery or flashback in progress may need access to files

Now to solve this issue we have cancel the managed recovery session and set  "standby_file_management"  to manual and drop the standby redolog file  as 

SQL> alter database recover managed standby database cancel ;
Database altered.

SQL> alter system set standby_file_management='MANUAL' ;
System altered.

SQL>alter database drop standby logfile group 4;
Database altered.

SQL>alter database drop standby logfile group 5;
Database altered.

If the status of standby redolog show the "clearing_current" then we cannot drop "clearing_current" status logs,and for that we have to sync with Primary and clear the log first before dropping as
SQL> alter database clear logfile group n;

Once the standby redologs are dropped then again back to recover the standby.

SQL>alter system set standby_file_management='AUTO' ;
System altered.

SQL> alter database recover managed standby database disconnect from session ;
Database altered.

More detail click here


Enjoy    :-)