Tag Archives: Data Guard

Start DG Database Automatically

In order to start a DG database automatically you can use DGMGRL. You must have parameter dg_broker_start=true,
You can set it to true using:
SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE SCOPE=BOTH;

When database is started from DGMGRL, it starts the database in mode according to database_role.

For Primary, it will start database in open read write stage.
For Physical Standby, it will start database in mount stage and also start the managed recovery.
For Logical Standby, it will start database in open stage and also start the SQL apply.

Steps for Windows:
1- Set ORA_SID_AUTOSTART to false in windows registry.

2- Create a batch job on the both primary and standby database:
start1.bat
=========
set ORACLE_SID=
dgmgrl / “startup”

start2.bat
======
set ORACLE_SID=
dgmgrl sys/ “startup”

++ Use either of 2 (start1.bat or start2.bat), only difference in these is OS and database authentication.

3- Now schedule this bat file to execute automatically at the system reboot to start the database automatically

Continue reading Start DG Database Automatically

Managing a Physical Standby Database

Below steps are related to day-to-day operations of the Oracle Data Guard environment. These operations include starting the standby database, enabling managed recovery, opening the standby in read-only, as well as general maintenance tasks.

Starting a Physical Standby
Before Oracle 10g

SQL> startup nomount;
SQL> alter database mount standby database;

Starting with Oracle 10g, the start-up task can be done in single step

SQL> startup mount;

During startup, Oracle will read the controlfile when mounting the database to make the determination to mount the database as astandby database or as a primary database.

Starting  Managed Recovery:

Once the standby database has been started, it will begin receiving redo data from the primary database. This redo data will stack up in the form of archivelogs until we instruct the standby database to begin applying the redo data to the standby database. For a physical standby, the redo application is performed via the MRP.

SQL> alter database recovery managed standby database;

This above command will appear to hang because MRP is part of the session that it was started in. If we cancel out of this session, the MRP will also exit. To avoid this we need to run the MRP in the background as below

SQL> alter database recover managed standby database disconnect;

If the physical standby has standby redo logs configured, it is possible to have the MRP begin applying changes as soon as they arrive to the standby instead of waiting for the standby redo log to be archived. This functionality was introduced in 10g and is called Real-Time Apply. Real-Time Apply can shorten the role transition time by minimizing the redo that needs to be applied

To start Real-Time Apply, you initiate MRP by issuing the following command:

SQL> alter database recover managed standby database using current logfile disconnect;

Stopping Managed Recovery:

We could simply perform a normal shutdown on the database, or we could cancel managed recovery,
leaving the standby database up and running. To cancel managed recovery, issue the following:

SQL> alter database recover managed standby database cancel;

Starting and Stopping Active Data Guard:

The actual process of enabling Active Data Guard is simple: Open the physical standby database in read-only mode and start Redo Apply. A physical standby database instance cannot be opened if Redo Apply is active on a mounted instance of that database. The Data Guard physical standby should be in
one of two states prior to enabling Active Data Guard:

1. The standby database is mounted and Redo Apply is running.

2. The standby database has been shut down cleanly and Redo Apply was stopped.

In the first scenario, proceed as follows using SQL*Plus

1. Stop Redo Apply:

SQL> RECOVER MANAGED STANDBY DATABASE CANCEL;

2. Open the database read-only:

SQL> ALTER DATABASE OPEN READ ONLY;

3. Restart Redo Apply:

SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT USING CURRENT LOGFILE;

In the second scenario, where the physical standby and Redo Apply are already shut down,
proceed as follow using SQL*Plus alone,

1. Start the physical standby in read-only mode.

SQL> STARTUP

2. Start Redo Apply.

SQL> SELECT open_mode FROM V$DATABASE;

OPEN_MODE
——————–
READ ONLY

SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT USING CURRENT LOGFILE;

SQL> select open_mode from v$database;

OPEN_MODE
——————–
READ ONLY WITH APPLY

Open Physical Standby For Read Write Testing and Flashback

Hi all, today I will show the process to Open a Dataguard database in Read Write mode, after that we will revert back using FlashBack Technologies.

Step 1 – In Standby database

A ) Set up a flash recovery area.

If Flash Recovery Area ( FRA ) is not configured in the standby then enable it and make sure to give enough space for to FRA

SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=5G; 
SQL> ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='/u01/oracle/flashback';

B ) Cancel Redo Apply and create a guaranteed restore point.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;  
SQL> CREATE RESTORE POINT Standby_flashback_testing GUARANTEE FLASHBACK DATABASE;

To Confirm the details of restore point and its SCN and time stamp run

SQL> select NAME,SCN,TIME from v$restore_point; 

NAME                          SCN            TIME 
---------------------------  -------------   ----------
STANDBY_FLASHBACK_TESTING    22607810        12-APR-18

Continue reading Open Physical Standby For Read Write Testing and Flashback