ADG LabExercise Linux

Oracle Active Data Guard
Oracle Database 11g Active Data Guard

Hands on Workshop
Setup
Date: January 2012
Author
Ashish Sohane
Principal Technical Consultant | Database Technologies
ashish.sohane@oracle.com | 18006330930 - 87665
Table of Contents
Introduction ............................................................................................ 3
Oracle Active Data Guard Benefits .......................................................... 4
Overview of the Exercises ....................................................................... 5
Workshop Setup and Configuration ........................................................ 6
Prerequisites ........................................................................................... 7
Preparing the Primary Database for Standby Database Creation ........... 8
Creating the Physical Standby Database ............................................... 12
Verify that the Physical Standby Database is Performing Correctly ...... 21
This handbook is your guide to the capabilities of Active Data Guard

in Oracle Database 11g Release 2.
Introduction
Oracle Data Guard ensures high availability, data protection, and disaster
recovery for enterprise data. Data Guard provides a comprehensive set of services
that create, maintain, manage, and monitor one or more standby databases to
enable production Oracle databases to survive disasters and data corruptions. These
standbys databases are maintained as transaction consistent copies of the
production database. If the production database becomes unavailable because of a
planned or an unplanned outage, Data Guard can switch any standby database to the
production role, minimizing the downtime associated with the outage. Data Guard
can be used with traditional backup, restoration, and cluster techniques to provide a
high level of data protection and data availability.
With Oracle Database 11g Active Data Guard, administrators can improve
production database performance by offloading resource-intensive backup and
query/reporting operations to Physical standby databases A Data Guard
configuration consists of one production database and one or more standby
databases. The databases in a Data Guard configuration are connected by Oracle Net
and may be dispersed geographically. There are no restrictions on where the
databases are located, provided they can communicate with each other. For
example, you can have a standby database on the same system as the production
database, along with two standby databases on other systems at remote locations.
A standby database can be:
Physical standby database

Provides a physically identical copy of the primary database, with on disk
database structures that are identical to the primary database on a block-for-block
basis. A physical standby database is kept synchronized with the primary database,
through Redo Apply, which recovers the redo data, received from the primary
database and applies the redo to the physical standby database.
Logical standby database

Contains the same logical information as the production database, although
the physical organization and structure of the data can be different. The logical
standby database is kept synchronized with the primary database using SQL Apply,
which transforms the data in the redo received from the primary database into SQL
statements and then executes the SQL statements on the standby database. Some
restrictions apply.
Active Data Guard standby database

A Physical standby database that is open to read access with up-to-date data
from the Primary database. Ancillary writes are also possible but the writes must be
redirected to a read write database using database links.
Snapshot Standby database

A fully read write standby database that is created by converting a physical
standby database into a Read write snapshot standby database. Receives and
archives redo data from the primary database. A snapshot standby database does
not apply the redo data that it receives. The redo data is not applied until the
snapshot standby is converted back into a physical standby database, after first
discarding any local updates made to the snapshot standby database.
Oracle Active Data Guard Benefits

Increase performance of production database: Offload unpredictable workloads.
 Simplify operations: Eliminate traditional replication management complexity.

 Eliminate compromise: Reporting replica is up-to-date and online at all times.
 Reduce cost: Provides disaster protection and high availability and can serve as a
QA system.
 Reduce backup time: Complete incremental backups on the standby up to 20x
faster.
 Automatic Block Media Recovery: Repair corrupted blocks without returning an
error to the application.
High Level Overview of Active Data Guard

Overview of the Exercises
The exercises are set up to walk you through Oracle Database 11g Active Data
Guard using SQL*Plus and the Broker working with a Physical standby (Redo Apply)
database using Active Data Guard to read your data as redo is being applied while
maintaining data protection. The exercises are designed from the top down so that
each step builds upon the previous exercise. It is essential that you follow the
exercises in order.
The following is an outline of the exercises that you will perform in Oracle
Database 11g.
 Workshop Sample Schema Creation and Data Insertion at Primary Database

 Preparing the Primary Database for Standby Database Creation
 Creating the Physical Standby Database
 Use the DUPLICATE FROM ACTIVE DATABASE RMAN command
 Enable Maximum Performance standby mode
 Verify that data is getting to the Physical standby
 Examine views to monitor Primary and Physical Standby Databases using
SQL*Plus
As you go through these exercises you will find the commands that must be
done for each step at each line beginning with the word TASK. Each TASK line in the
book lists the commands (SQL*Plus, DGMGRL or Linux) that are to be executed in
one of the windows, depending on the type of command. Any DGMGRL commands
are to be executed in your DGMGRL terminal window, SQL commands in your
SQL*Plus terminal window, etc.
NOTE: For the convenience of less typing and fewer errors, these commands can be
copied from this book / download Scripts from Email attachment and pasted into
your Server Windows.
Please read the “Setup and Configuration” section carefully before attempting the
exercises.
Workshop Setup and Configuration
You will use any Linux system you have for the user interface to the Lab
system. Your Lab system will be made of One Host / Server with 2 instances (Primary
and Stand By).
Installation Setup
Software and Databases
The following are required:
 Oracle Database 11g (Version 11g Release 2)

 Install Primary database instance and name ORACLE_SID as ‘orcl’
 Later we will create Physical Standby database and will keep ORACLE_SID as
‘standby1’
Accounts and Passwords
All Database ‘SYS’ and ‘SYSTEM’ accounts have the password ‘oracle’
Prerequisites
Before starting this tutorial, you should:
1. Download and Install Oracle Database 11g. (Keep Oracle_SID = ‘orcl’).

2. Create a directory named wkdir. Download and unzip physstdby.zip into the wkdir
directory.
Execute following Scripts on Primary Instance
@database.sql;
@seed_database.sql;
@source_count.sql;
@trans_generator_east.sql;
Preparing the Primary Database for Standby Database Creation
In this practice, you verify that the primary database is configured correctly to support
a physical standby database.
You only need to perform these preparatory tasks once. After you complete these
steps, the database is prepared to serve as the primary database for one or more
standby databases. You should perform the following steps:
1. Determine if FORCE LOGGING is enabled. If it is not enabled, enable FORCE LOGGING

mode. This statement may take some time to complete, because it waits for all unlogged
direct write I/O to finish. Use SQL*Plus to execute the following commands:
SELECT force_logging FROM v$database;
ALTER DATABASE FORCE LOGGING;
2. Configure redo transport authentication.
Data Guard uses Oracle Net sessions to transport redo data and control messages
between the members of a Data Guard configuration. These redo transport sessions are
authenticated using either the Secure Sockets Layer (SSL) protocol or a remote login
password file. In this OBE, we will be using a remote login password file which will be
created in a subsequent step.
3. Configure the primary database to receive redo data, by adding the standby logfiles to the
primary. You can use the cr_sby_redologs.sql script, after validating the directory paths
reflect your environment.
It is highly recommended that you have one more standby redo log group than you have
online redo log groups as the primary database. The files must be the same size or larger
than the primary database’s online redo logs.
4. Set primary database initialization parameters
On the primary database, you define initialization parameters that control redo transport
services while the database is in the primary role. These include:
DB_NAME Specifies the database name. Must be orcl.
Specify a unique name for each database. Does not change even
DB_UNIQUE_NAME
if DG roles change. Must be orcl.
Specifies the local path name for the control files on the primary
CONTROL_FILES
database.
Uses the DG_CONFIG attribute to list the DB_UNIQUE_NAME of

LOG_ARCHIVE_CONFIG
the primary and standby databases.
Defaults to archive destination for the local archived redo log

LOG_ARCHIVE_DEST_1
files.
Valid only for the primary role, this destination transmits redo
LOG_ARCHIVE_DEST_2
data to the remote physical standby destination standby1.
Must be EXCLUSIVE or SHARED if a remote login password file is

REMOTE_LOGIN_PASSWORDFILE
used (default = EXCLUSIVE)
LOG_ARCHIVE_DEST_STATE_n Must be ENABLE (default)
Verify your settings for DB_NAME and DB_UNIQUE_NAME.
Use the set_log_params.sql script to set the LOG_ARCHIVE_CONFIG and

LOG_ARCHIVE_DEST_2 parameters.
5. Issue the following statements to determine your database's archival state, and then put
the primary database in ARCHIVELOG mode to enable automatic archiving.
Creating the Physical Standby Database
In this practice, you configure the network environment and create a physical
standby database.
A Create an Oracle Net service name for your physical standby database.
B. Configure an entry for your standby database in the listener.ora file.
C. Creating the standby database.

A. Create an Oracle Net service name for your physical standby database.
1Your Data Guard configuration will use Oracle Net service names to reference
.different databases. Add a service name for your physical standby database. This
can be achieved by appending the entry provided in tns_entry.txt to your existing
$ORACLE_HOME/network/admin/tnsnames.ora file as shown below.
Note: If you are familiar with Oracle Net services use the netmgr utility to configure
the new service entry.
Note: It is likely that you already have a service name defined for you primary
database as illustrated above. If not, be sure to add a service name entry for that
database as well.
B. Configure an entry for your standby database in the listener.ora file.
1. In the following section you will use RMAN to create your standby database. To
achieve this you will need to add a database service entry to your listener.ora file.
This can be achieved by appending the entry provided in sid_entry.txt to your
existing $ORACLE_HOME/network/admin/listener.ora file as shown below.
Note: If you are familiar with Oracle Net services use the netmgr utility to configure
the new service entry.
C. Creating the standby database.
1. Stop and re-start the Oracle network listener using the lsnrctl stop and lsnrctl start
commands.
2. Change directory to $ORACLE_HOME/dbs and copy the remote login password file
(orapworcl) from the primary database system to the $ORACLE_HOME/dbs
directory on the standby database system, renaming it to orapwstandby1.
Note: The password file must be re-copied each time the SYSDBA or SYSOPER
privilege is granted or revoked and whenever the login password of a user with
these privileges is changed. You may need FTP, or some other remote file transfer
mechanism, if you are using different servers.
3. In the $ORACLE_HOME/dbs directory of the standby system, create an initialization

parameter file named initstandby1.ora containing a single parameter:
DB_NAME=<physical standby SID> (i.e. standby1)
4. On the standby system, change to the /u01/app/oracle/admin directory. Create a

directory with a name that matches your physical standby SID (i.e. standby1).
Change to the newly created directory (i.e. standby1) and create an adump
directory.
5. On the standby system, create a directory with a name that matches your physical
standby SID (i.e. standby1) in $ORACLE_BASE/oradata for the data files.
Note: Depending on how you configured your existing primary database you may
need to also create a similar directory in your fast recovery area (i.e.
$ORACLE_BASE/flash_recovery_area)
6. On the standby system, set the ORACLE_SID environment variable to your physical
standby SID (i.e. standby1) and start the instance in NOMOUNT mode with the text
initialization parameter file created earlier.
7. On the primary system, ensure the ORACLE_SID environment variable is set to your
primary database SID (i.e. orcl). Verify that your current directory contains the
cr_phys_sby1.txt RMAN script.
8. On the primary system, invoke RMAN and connect as SYSDBA to the target
database. Connect as SYSDBA to the auxiliary database. Enter <your password> for
SYS.
9. Execute the cr_phys_sby1.txt script from RMAN on the primary system. When this
script finishes you will have a new standby database that was created over the
network without any interim storage.
(To view below image – right click and Save as (*.gif) and open in Paint brush.)
and
10 Perform a log switch on the primary database and redo will start being sent to the
. standby.
11 On the standby system, ensure the ORACLE_SID environment variable is set to your
. physical standby SID (i.e. standby1) and start the managed recovery process.
Verify that the Physical Standby Database is performing correctly
Once you create the physical standby database and set up redo transport
services, you may want to verify database modifications are being successfully
transmitted from the primary database to the standby database. To see that redo
data is being received on the standby database, you should first identify the existing
archived redo log files on the standby database, force a log switch and archive a few
online redo log files on the primary database, and then check the standby database
again. The following steps show how to perform these tasks.
1. On the standby database, identify the existing archived redo log files by querying the
V$ARCHIVED_LOG view.
You can use the query_archived_log.sql file.
Note: Depending on your machine performance, you may see that both archived
redo logs have been applied at the time that you query the view.
2. On the primary database, issue a number of ALTER SYSTEM SWITCH LOGFILE

statements to archive a number of redo log files.
3. On the standby instance, re-query the V$ARCHIVED_LOG view to verify the redo
data was received and applied on the standby database.
At the completion of this step, the physical standby database is running and
provides the maximum performance level of data protection.
Exercise 5: Physical Standby – Data Guard Limitations
With Data Guard, Physical Standby can run either in Managed Recovery Mode
or Read Only Mode. To demonstrate this, open a new Terminal / Command
Window and set ORACLE_SID=standby1 (We will use this terminal as our Standby
Instance)
C:\> set ORACLE_SID = standby1

C:\> echo %ORACLE_SID%
C:> sqlplus / as sysdba
23
Enter Password: ******
Step 1: select * from v$instance; (Let’s make sure we are at Standby Instance)
Step 2: SHUTDOWN IMMEDIATE;
Step 3: STARTUP MOUNT;
Step 4: ALTER DATABASE OPEN READ ONLY;
Step 5: SELECT * FROM BRANCH;
(You will be able to Query the data as the Physical Standby is running in Read
Only Mode)
To resume managed recovery, do the following on Standby Instance
Step 1: SHUTDOWN IMMEDIATE;

Step 2: STARTUP MOUNT;
Step 3: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM
SESSION;
Step 4: SELECT * FROM BRANCH;
(This time you will not be able to Query the data as the Physical Standby is
running in Managed Recovery Mode)
Exercise 6: Enabling Active Data Guard
Enabling a Physical standby database for Active Data Guard is so simple

that you may be disappointed that this exercise is so short and so easy. But that is
the point, Active Data Guard is easy. To be able to read from your Physical standby
database all you have to do is stop Redo Apply, open the Physical standby database
Read Only and restarts Redo Apply. If you were not using the Broker the steps
would be as follows on your Physical standby database.
Active Data Guard - Read Only + Managed Recovery, do the following on

Standby Instance
Step 1: alter database recover managed standby database cancel;

Step 2: ALTER DATABASE OPEN READ ONLY;
24
Step 3: alter database recover managed standby database using current logfile
disconnect;
Exercise 7: Reading from an Active Data Guard Standby Database
To show that you can read the data on the Physical Standby database as it
is being applied, you can add some information to a table in the Primary database
and read that data from the Physical Standby database.
To begin, log into the Physical standby standby1 and read the branch table.
Now, we have Standby Database open in Read Only and Managed Recovery
Mode, let’s insert data at Primary Database.
Step 1: On a StandBy Instance

 Sql> select * from branch;
Step 2: On a Primary Instance

 Sql> insert into branch values (65000, 75000);
 Sql> commit;
 Sql> alter system switch logfile;
 Sql> alter system switch logfile;
Step 3: On a StandBy Instance

 Sql> select * from branch;
(You will be able to Query the data as the Physical Standby is running in Read Only
+ Managed Recovery Mode). You have now used Active Data Guard to read up-
to-date data from your Physical standby database.
To view log setup
SQL> show parameter log_archive; -
25
Exercise 8: Enterprise Manager – High Availability Console
Let’s move to Enterprise Manager and add Standby1 instance to EM.

https://localhost:1158/em
Exercise 9: Writing Data with an Active Data Guard Standby
When connected to an Active Data Guard standby database, read-only

applications can perform:
 Selects
 Alter session / system
 Set role
 Lock table
 Call stored procedures
 DBlinks to write to remote databases
 Stored procedures to call remote procedures via DBlinks
 SET TRANSACTION READ ONLY for transaction level read consistency
 Complex queries e.g. grouping set queries and with clause queries
If an application has the capability of directing read operations to the Active Data
Guard service running on the Physical standby database and write operations to the
Primary database then all you need to do is define the services to start on the correct
database and the application will automatically offload the read workload to the
Physical standby database.
However, as of Oracle Database 11g Release 1 with Active Data Guard, write
operations can be performed on a Physical Standby that is opened read only, through
the use of Database Links. The links are created on the Primary database and are
applied to the Physical Standby through Redo Apply. They can point back to the Primary
or to another database where the application has read write access. In this manner a
primarily read application that has a need to make a few writes can make those writes
26
on the standby and they will be automatically redirected to the read write database. If
the applications require access to the data that is updated on the Active Data Guard
standby then your database link must point to the Primary database so that the data is
available to all users.
To begin with log into the Primary instance (orcl) as SYS ( AS SYSDBA) again and
create a database link that uses ‘ORCL’ (use UPPER CASE ‘ORCL’) as the connect string.
The redo generated by this DDL will be sent to the physical standby where Redo Apply
will apply the redo making the database link available to the application running on the
physical standby.
Execute following @ Primary Instance (orcl) Terminal
SQL> show user

USER is "SYS"
SQL> create public database link write_ADG connect to HR identified by oracle

using 'ORCL';
Database link created.
It may require unlocking / identification of HR user – if ask please unlock the

account and reset the password to ‘oracle’
SQL> Alter user HR identified by oracle;
SQL> Alter user HR account unlock;
SQL> create table hr.branch as select * from branch;

Table created.
SQL> alter system switch logfile;

System altered.

System altered.
SQL> select count(*) from hr.branch; (Actual count may differ at your Instance – please ignore)
COUNT(*)- 52
27
Execute following @ Standby Instance (standby1) Terminal
SQL> select count(*) from hr.branch;

COUNT(*)
----------
52
This time we will insert a new row into the HR.BRANCH table using the database
link while connected to the Physical standby. The actual DML will be redirected to the
Primary database and once the COMMIT is executed redo will be generated and sent to
the Physical standby. Redo Apply will apply the redo making the new data available to
the application.
SQL> insert into hr.branch@write_ADG values (6666,7777);

1 row created.
SQL> commit;
Commit complete.
COUNT(*)
----------
52
COUNT(*)
----------
52

COUNT(*)
----------
53
Switch back to Primary Instance Terminal and again query Branch Table:

COUNT(*) - 53
28
How fast the data appears in the Physical standby depends on the workload on
your Primary database, how fast the redo can be sent to the Physical standby and how
well Redo Apply is performing. You can tune these factors by following the MAA papers
for tuning Redo Transport and Apply.
Exercise 10: Use Data Pump to extract data from an Active Data Guard standby
database.
Since a physical standby is a byte for byte copy of your production database, all
the data that you might want to distribute en-masse to another database is available
there. The question is, How to get it out? Most extract utilities requiring writing to the
database, something you cannot do on a read-only Data Guard standby database.
With the arrival of Active Data Guard though, things have changed. Since Active Data
Guard allows you to read and write over database links it is now possible to use Oracle
Data Pump and the network option to extract data from a physical standby that is in
Active Data Guard mode.
Oracle Data Pump enables high-speed movement of data and metadata from one
database to another. This technology is the basis for the following Oracle Database data
movement utilities:
 Data Pump Export (Export) - Export is a utility for unloading data and metadata
into a set of operating system files called a dump file set. The dump file set is
made up of one or more binary files that contain table data, database object
metadata, and control information.
 Data Pump Import (Import) - Import is a utility for loading an export dump file set
into a database. You can also use Import to load a destination database directly
from a source database with no intervening files, which allows export and import
operations to run concurrently, minimizing total elapsed time.
Being able to extract data from an Active Data Guard standby allows you to
offload the Data Pump processing to the standby database. This enables the ability to
not only extract and move data to other databases; it also allows you to repair the
29
Primary database selectively without necessarily affecting the entire database. An

example of this would be as follows:
 Your Primary database has multiple applications that run in different schemas.
 At some point, due to user error, one application‘s schema is damaged.
o A batch job runs twice by mistake, etc.
 During the 2nd batch job run, the other applications continue on and are taking
new transactions.
When the error is discovered you could use flashback database and return the
Primary database to the point just prior to the 2nd batch job run and open reset logs.
But this will cause an entire application suite outage and also return all the other
schemas to the same point in time losing all of their good data that was generated
during the 2nd batch job run.
You could just perform the same flashback on the Primary, extract a good copy of
the schema and then reverse the flashback and replace the damaged schema. You
would not lose any data from the other applications but this would require that all the
applications are down during the entire process.
Instead, you can flashback the Active Data Guard standby to the appropriate point
in time and extract a good copy of the schema using Oracle Data Pump and repair the
Primary database by replacing the damaged schema with this good copy of the data. All
the while the other applications which do not have a problem keep running and do not
lose any data and your application outage is limited only to the schema that was
damaged.
This exercise will take you through the steps of extracting the ‘HR’ schema from
your Active Data Guard standby and using the data to replace the ‘HR’ schema in the
Primary database.
SQL> create or replace directory dir_DBBackup as 'C:\DataPump_Backup';

Directory created.
Go back to C:\ and check if the directory is created or not – if not please manually
create a New Folder and rename to DataPump_Backup.
30
SQL> grant read, write on directory dir_DBBackup to public;

Grant succeeded.

System altered.
This creates the directory metadata in the Primary database and the same thing
happens on the standby database through the redo. Since the directory
‘C:\DataPump_Backup’ also exists at the standby (the two databases are on the same
system but ‘C:\DataPump_Backup’ would also exist on a remote system as well if it
exists on the Primary system) the directory will point to a real location. But this still does
not allow you to export directly from the Active Data Guard standby.
Check on a Standby Instance
SQL> select * from dba_directories;
Now Execute:
SQL> host expdp system/oracle@standby1 directory=dir_DBBackup
dumpfile=system_sby.dmp
As you can see from the previous exercise, even though the directory metadata
and the system directory exist at the standby, you cannot export directly from a read-
only database because Oracle Data Pump needs to write to its master table. To extract
data from the standby you must run Data Pump from a read-write database using the
NETWORK_LINK qualifier in the export or import command.
31
The read-write database can be the Primary database or some other target
database for the data you are going to extract. If you are only creating export dump files
then the read-write database could also be a small ‘stub’ database that resides on the
same system as the Active Data Guard standby database. In this exercise you will be
using the Primary database as the read-write database for Data Pump’s information.
The first exercise is to extract the ‘HR’ schema from the Active Data Guard
standby and put it in a dump file in the 'C:\DataPump_Backup' directory. To do this you
first have to create a database link that will be used by Oracle Data Pump to connect
from the read-write database (the Primary ORCL) to the read-only database (the Active
Data Guard standby standby1). This will be used to connect to the standby and extract
the required data.
On Primary Instance
SQL> create public database link adg_sby using 'STANDBY1';

Database link created.
SQL> grant read,write on directory dir_DBBackup to hr;

Grant Succeeded.
Now you can begin to extract data from the standby into dump files that will be
placed in the ‘C:\DataPump_Backup’ directory.
Sql> host expdp system/oracle@ORCL directory=dir_DBBackup dumpfile=hr.dmp

network_link=adg_sby schemas=HR
The dump file ‘C:\DataPump_Backup\hr.dmp’ can now be imported into any read
write database and a record of the export is contained in the export log file
‘C:\DataPump_Backup\export.log’.
As an example you will drop the ‘HR’ schema in the Primary database, which will
cause it to also be removed from the standby database, and then using the dump file
you just created, recreate the ‘HR’ schema in the Primary database by importing it.
SQL> connect sys/oracle@ORCL as sysdba

Connected.
32
SQL> drop user HR cascade;

User dropped.
This drops the entire schema related to the user ‘HR’ and, since we are running in
Real-Time Apply mode at the standby, the HR schema has also been removed. Now we
can use import to replace the ‘HR’ user.
C:\> host impdp system/oracle@ORCL directory=dir_DBBackup dumpfile=hr.dmp

schemas=HR
You can verify that the data has been returned by connecting to both the Standby
and the Primary databases as the ‘HR’ user again and examine the ‘EMPLOYEES’ table.
@ Standby1
SQL> connect hr/oracle
Connected.
SQL> select count(*) from employees;

COUNT(*)
----------
107
@ Primary
SQL> connect hr/welcome1@SFO
Connected.
SQL> select count(*) from employees;

COUNT(*)
----------
107
Exercise 11: Perform a Switchover
Once the standby database is setup using Data Guard and works properly, you
may want to test switchover, or perform switchover to reduce primary database
downtime during OS upgrades or hardware upgrades.
33
A switchover allows the primary database to switch roles with its standby
database. There is no data loss during a switchover. You can switch back to the original
Primary database later by performing another switchover.
In case of primary database failure, you will need to perform failover to transition
the standby database to the primary role. After a failover, the original primary database
can no longer participate in the Data Guard configuration. So if the original Primary
database is still accessible, you should always consider a switchover first.
This exercise only talks about switchover involving physical standby database. In
this example, the original primary instance is called ORCL and the original standby
database is called STANDBY1
Before Switchover: Oracle always recommends
1. Test the Switchover first on your testing systems before working on Production.
2. Verify the primary database instance is open and the standby database instance is
mounted.
3. Verify there are no active users connected to the databases.
4. Make sure the last redo data transmitted from the Primary database was applied
on the standby database.
Issue the following commands on Primary database and Standby database to find out:
SQL>select sequence#, applied from v$archived_log;

Perform SWITCH LOGFILE if necessary. In order to apply redo data to the standby
database as soon as it is received, use Real-time apply.
Switchover Steps
Step 1 : Verify whether it is possible to perform a switchover
On the current primary database, query the "switchover_status" column of the

V$DATABASE fixed view on the primary database to verify it is possible to perform
switchover.
34
SQL> select switchover_status from v$database ;

SWITCHOVER_STATUS
--------------------
TO STANDBY
The TO STANDBY value in the "switchover_status" column indicates that it is

possible to switch the primary database to the standby role. If the TO STANDBY value is
not displayed, then verify the configuration is functioning correctly . (for example, verify
all "log_archive_dest_n" parameter values are specified correctly).
Step 2 : Check that there is no active users connected to the databases.
SQL> select distinct osuser,username from v$session;
Step 3 : Switch the current online redo log file on primary database and verify that it
has been applied
SQL>alter system switch logfile ;

System altered.
Step 4 : On the primary database initiate the switchover
SQL> alter database commit to switchover to physical standby;

Database altered.
Now, the primary database is converted into standby database. The controlfile is
backed up to the current SQL session trace file before the switchover. This makes it
possible to reconstruct a current control file, if necessary.
35
If we try to perform a switchover when other instances are running then we will
get ORA-01105 as follows :
SQL>alter database commit to switchover to standby ;

ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY
*
ORA-01105: mount is incompatible with mounts by other instances
In order to perform a switchover, run below command on the primary database.
SQL>alter database commit to switchover to physical standby with session shutdown;
The above statement first terminates all active sessions by closing the primary
database. Then any non-archived redo log files are transmitted and applied to standby
database. Apart from that an end-of-redo marker is added to the header of the last log
file that was archived. A backup of current control file is created and the current control
file is converted into a standby control file.
Step 5: Switch the target physical standby (standby1) database role to the primary role
We can switch a physical standby database from the standby role to the primary
role when the standby database instance is either mounted in Redo Apply mode or open
for read-only access. It must be in one of these modes so that the primary database
switchover request can be coordinated. After the standby database is in an appropriate
mode, issue the following sql statement on the physical standby database that we want
to change to the primary role:
Execute following on old Standby DB (standby1)
SQL>alter database commit to switchover to primary ;

Database altered.
Step 6 : Shut down and restart the old primary instance(ORCL).
36
SQL>shutdown immediate;
SQL> startup mount;
Step 7 : Shut down and restart the old standby instance(standby1).
SQL>shutdown immediate;
SQL> startup;
Step 8 : Verify the switchover status in the v$database view.
After we change the primary database to the physical standby role and the
switchover notification is received by the standby databases in the configuration, we
should verify if the switchover notification was processed by the target standby
database by querying the "switchover_status" column of thev$database fixed view on
the target standby database.
Step 9: Check the new primary database(Standby1) and switch logfile :
SQL> select open_mode from v$database;

OPEN_MODE
---------------
READ WRITE
Note : it's a good idea to perform a log switch on the primary .

System altered.
Step 10 : Open new standby database(ORCL) in read-only
SQL> alter database open read only;

Database altered
SQL> select name,open_mode ,db_unique_name,switchover_status from v$database;
37
NAME OPEN_MODE DB_UNIQUE_NAME SWITCHOVER_STATUS

------ ------------- ------------------ -----------------------
NOIDA READ ONLY orcl RECOVERY NEEDED
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL> select name,open_mode from v$database;

NAME OPEN_MODE
--------- ---------------------------------
NOIDA READ ONLY WITH APPLY
The switchover_status column of v$database can have the following values:
Not Allowed : Either this is a standby database and the primary database has not been
switched first, or this is a primary database and there are no standby databases.
Session Active : Indicates that there are active SQL sessions attached to the primary or
standby database that need to be disconnected before the switchover operation is
permitted.
Switchover Pending : This is a standby database and the primary database switchover
request has been received but not processed.
Switchover Latent : The switchover was in pending mode, but did not complete and
went back to the primary database.
To Primary : This is a standby database, with no active sessions, that is allowed to
switch over to a primary database.
To Standby : This is a primary database, with no active sessions, that is allowed to
switch over to a standby database.
Recovery Needed : This is a standby database that has not received the switchover
request.
Exercise 12: Leveraging the power of the Snapshot Standby Database
Snapshot Standby
Introduced in 11g, snapshot standby allows the standby database to be opened in

read-write mode. When switched back into standby mode, all changes made whilst in
38
read-write mode are lost. This is achieved using flashback database, but the standby
database does not need to have flashback database explicitly enabled to take advantage
of this feature, thought it works just the same if it is.
Convert the standby to a snapshot standby. The following example queries the
V$DATABASE view to show that flashback database is not enabled prior to the
conversion operation.
SQL> SELECT flashback_on FROM v$database;
FLASHBACK_ON
------------------
NO
SQL> ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;

SQL> ALTER DATABASE OPEN;
FLASHBACK_ON
------------------
RESTORE POINT ONLY
SQL>
You can now do treat the standby like any read-write database.
To convert it back to the physical standby, losing all the changes made since the conversion to
snapshot standby, issue the following commands.
SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP NOMOUNT;
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

FLASHBACK_ON
39
------------------
NO
SQL>
The standby is once again in managed recovery and archive log shipping is resumed. Notice that
flashback database is still not enabled.
40
Resources
The following documentation is available for Data Guard
Oracle® Data Guard Concepts and Administration 11g Release 1 (11.1)

http://download.oracle.com/docs/cd/B28359_01/server.111/b28294/toc.htm
Oracle® Data Guard Broker 11g Release 1 (11.1)

http://download.oracle.com/docs/cd/B28359_01/server.111/b28295/toc.htm
Oracle® Data Guard Concepts and Administration 11g Release 2 (11.2)

http://download.oracle.com/docs/cd/E11882_01/server.112/e10700/toc.htm
Oracle® Data Guard Broker 11g Release 2 (11.2)

http://download.oracle.com/docs/cd/E11882_01/server.112/e10702/toc.htm
The Maximum Availability Architecture Best Practices papers are on Oracle OTN.
Best Practices for High Availability -- Maximum Availability Architecture (MAA)
http://www.oracle.com/technetwork/database/features/availability/maa-096107.html
41

ADG LabExercise Linux

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ADG LabExercise Linux

Uploaded by

Copyright:

Available Formats

Oracle Active Data Guard

Oracle Database 11g Active Data Guard

Date: January 2012

Oracle Active Data Guard Benefits .......................................................... 4

Overview of the Exercises ....................................................................... 5

Workshop Setup and Configuration ........................................................ 6

Preparing the Primary Database for Standby Database Creation ........... 8

Creating the Physical Standby Database ............................................... 12

Verify that the Physical Standby Database is Performing Correctly ...... 21

This handbook is your guide to the capabilities of Active Data Guard

A standby database can be:

Physical standby database

Logical standby database

Active Data Guard standby database

Snapshot Standby database

Oracle Active Data Guard Benefits

 Simplify operations: Eliminate traditional replication management complexity.

High Level Overview of Active Data Guard

Overview of the Exercises

 Workshop Sample Schema Creation and Data Insertion at Primary Database

Workshop Setup and Configuration

Software and Databases

The following are required:

 Oracle Database 11g (Version 11g Release 2)

Accounts and Passwords

Before starting this tutorial, you should:

1. Download and Install Oracle Database 11g. (Keep Oracle_SID = ‘orcl’).

Execute following Scripts on Primary Instance

Preparing the Primary Database for Standby Database Creation

1. Determine if FORCE LOGGING is enabled. If it is not enabled, enable FORCE LOGGING

SELECT force_logging FROM v$database;

ALTER DATABASE FORCE LOGGING;

2. Configure redo transport authentication.

4. Set primary database initialization parameters

DB_NAME Specifies the database name. Must be orcl.

Uses the DG_CONFIG attribute to list the DB_UNIQUE_NAME of

Defaults to archive destination for the local archived redo log

Must be EXCLUSIVE or SHARED if a remote login password file is

LOG_ARCHIVE_DEST_STATE_n Must be ENABLE (default)

Verify your settings for DB_NAME and DB_UNIQUE_NAME.

Use the set_log_params.sql script to set the LOG_ARCHIVE_CONFIG and

Creating the Physical Standby Database

B. Configure an entry for your standby database in the listener.ora file.

C. Creating the standby database.

B. Configure an entry for your standby database in the listener.ora file.

C. Creating the standby database.

3. In the $ORACLE_HOME/dbs directory of the standby system, create an initialization

4. On the standby system, change to the /u01/app/oracle/admin directory. Create a

standby SID (i.e. standby1) in $ORACLE_BASE/oradata for the data files.

Verify that the Physical Standby Database is performing correctly

You can use the query_archived_log.sql file.

2. On the primary database, issue a number of ALTER SYSTEM SWITCH LOGFILE

C:\> set ORACLE_SID = standby1

Enter Password: ******

To resume managed recovery, do the following on Standby Instance

Step 1: SHUTDOWN IMMEDIATE;

Exercise 6: Enabling Active Data Guard

Enabling a Physical standby database for Active Data Guard is so simple

Active Data Guard - Read Only + Managed Recovery, do the following on

Step 1: alter database recover managed standby database cancel;

Exercise 7: Reading from an Active Data Guard Standby Database

Step 1: On a StandBy Instance

Step 2: On a Primary Instance

Step 3: On a StandBy Instance