Other Considerations For Oracle Data Guard

Copyright 2006, Oracle. All rights reserved.
Other Considerations for

Oracle Data Guard
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS
COMPUTER IS STRICTLY PROHIBITED
Oracle Database 10g: Data Guard Administration 12 - 2
Objectives
After completing this lesson, you should be able to do the
following:
Back up the primary database with a physical standby
database
Back up a logical standby database
Use Flashback Database features in a Data Guard
configuration
Encrypt redo information
Configure cascaded redo log destinations
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Offloading Backups to a Physical Standby
Backups of data files and archived redo logs are fully
interchangeable.
Control file backups are not interchangeable.
Primary and standby databases must use the same
recovery catalog.
It is not necessary to register the standby database.
Offloading Backups to a Physical Standby
Recovery Manager (RMAN) can back up the standby database and its associated archived redo logs.
Standby backups of data files and archived redo logs are fully interchangeable with primary database
backups. In other words, you can execute the RESTORE command to restore a backup of a standby
data file to the primary database, and you can restore a backup of a primary data file to the standby
database. The standby control file and primary control file, however, are not interchangeable.
Both the primary database and standby database must use the same recovery catalog. Note that you
do not need to register the standby database in the catalog if the primary is already registered; simply
connect to the standby database and execute the BACKUP command.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Using RMAN to Back Up
a Physical Standby Database
1. Invoke RMAN.
2. Allocate channels if needed.
3. Issue the BACKUP command.
4. Use the LIST command to verify the backup.
Using RMAN to Back Up a Physical Standby Database
Use the RMAN BACKUP command to back up the standby database. Performing a backup on the
standby database is exactly the same as a backup of the primary database, except that the backup
takes place on the standby site.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Restrictions and Usage Notes
The database you are backing up must be a physical
standby database.
You must be connected to the recovery catalog when
backing up.
You cannot back up the standby control file.
You must connect to the physical standby database
with the TARGET keyword.
Restrictions and Usage Notes
If physical standby database backups are to be usable for restore jobs at the primary site, you must be
connected to the recovery catalog when backing up the standby database or must resynchronize the
physical standby database shortly after the backup. This step is necessary because there is no way for
the primary database to know about the standby backups unless the backup records are stored in the
recovery catalog.
You cannot back up the standby control file. Also, you cannot make an image copy or
non-RMAN backup of the standby control file and then use it to restore the primary database.
When you back up the standby database, you must connect to the standby database with the TARGET
keyword (not the AUXILIARY keyword). Essentially, the standby database is substituting for the
primary database during the backup.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Backup and Recovery of a
Logical Standby Database
Backup considerations:
Use the same backup method that you use for your
primary database.
Files are not interchangeable with the primary database.
Recovery considerations:
Can recover like any other database for loss of individual
files
Need to re-create if you lose entire database
Must use a binary copy of control file for control-file
recovery
Backup and Recovery of a Logical Standby Database
You can back up your logical standby database by using the same method that you use for your
primary database. The backup files are not interchangeable with the primary database. Remember
that this is a different database.
You can use the same recovery techniques as with any other database for loss of data files or online
log files. You must use the backups of the logical (not the primary) database. If the entire logical
standby database is lost, you must re-create the logical standby.
If you lose all copies of your control file, you must use a binary copy of the control file when
performing the recovery. Using a trace file or the CREATE CONTROLFILE command for control
file recovery does not create a logical standby control file. You can make a binary copy of the control
file by doing either of the following:
Shut down the logical standby and copy the control file to a backup.
Issue the following command while the logical standby database is open:
ALTER DATABASE BACKUP CONTROLFILE TO '<filename>';
This command creates a binary copy of the control file with the name that you supply.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Flashback Across Database Changes
Flashback Database restores the database to a point-in-
time before the following global database changes:
Database RESETLOGS operation
Database switchover or failover to a physical or logical
standby database
Physical standby database activation
Flashback Across Database Changes
In Oracle Database 10g Release 2, you can use flashback database functionality to flash back through
the global database changes described above. To flash back through any of these database state
changes, Flashback Database must be previously enabled. Enabling Flashback Database for your
database remains unchanged from the previous release.
Previously, when any of these global database changes were made, the flashback logs were
discarded. Oracle Database 10g Release 2 maintains the flashback logs through the above global
database changes, thereby extending the functionality of the Flashback Database command.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Using Flashback Database and
Real-Time Apply
RFS
Standby
redo log
MRP
ARC0
Archived
redo logs
Primary
database
Standby
database
Using Flashback Database and Real-Time Apply
You can reduce failover time by using the Oracle Data Guard real-time apply feature. You can
protect a physical standby database from logical data corruption or user error by using Flashback
Database.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Using Flashback Database After RESETLOGS
Redo
Redo
Flashback
Primary
database
Standby
database
RESETLOGS
after
point-in-time
recovery
Primary database Standby database
Using Flashback Database After RESETLOGS
Physical Standby Configuration
For a physical standby database, it is possible that the Redo Apply service might not halt when it
encounters the OPEN RESETLOGS command in the redo information. If the physical standby
databases SCN is far enough behind the primary databases SCN, then the Redo Apply service will
be able to interpret the OPEN RESETLOGS command without stopping.
Use the following procedure to avoid re-creating a standby database after you have performed an
OPEN RESETLOGS on the primary database and the managed recovery process has halted on the
physical standby database:
1. On the primary database, determine an SCN that is at least two SCNs prior to the SCN when the
OPEN RESETLOGS command was issued. This is necessary to enable the standby to recover
properly through the OPEN RESETLOGS. Use the following query to find the before
RESETLOGS SCN:
SELECT TO_CHAR(resetlogs_change# - 2) FROM v$database;
2. On the standby database, obtain the current SCN by using the following query:
SELECT TO_CHAR(current_scn) FROM v$database;
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Using Flashback Database After RESETLOGS (continued)
3. Flash back the standby database to the before RESETLOGS SCN that you queried in
step 1:
FLASHBACK STANDBY DATABASE TO SCN <before RESETLOGS SCN>;
4. Restart managed recovery on the standby database. The standby database should now be ready
to receive and apply logs from the primary database:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
Logical Standby Configuration
For a logical standby database, it is possible that the SQL Apply service might not halt when it
encounters the OPEN RESETLOGS command in the redo information. If the logical standby
databases SCN is far enough behind the primary databases SCN, then the SQL Apply service will
be able to interpret the OPEN RESETLOGS command without stopping.
Use the following procedure to avoid re-creating a standby database after you have performed an
OPEN RESETLOGS on the primary database and the SQL Apply process has halted on the logical
standby database:
1. On the primary database, determine an SCN that is at least two SCNs prior to the SCN when the
OPEN RESETLOGS command was issued. This is necessary to enable the standby to recover
properly through the OPEN RESETLOGS. Use the following query to find the before
RESETLOGS SCN:
SELECT TO_CHAR(resetlogs_change# - 2) FROM v$database;
2. On the standby database, obtain the current SCN with the following query:
SELECT TO_CHAR(current_scn) FROM v$database;
3. Flash back the standby database to the before RESETLOGS SCN that you queried in
step 1:
FLASHBACK STANDBY DATABASE TO SCN <before RESETLOGS SCN>;
4. Restart SQL Apply on the standby database. The standby database should now be ready to
receive and apply logs from the primary database:
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Enabling Redo Encryption
Primary
database
Standby
database
Redo
information
encrypted
Enabling Redo Encryption
You can optionally enable encryption of the redo data by using the following procedure:
1. Install the Oracle Advanced Security option at both the primary and standby databases.
2. Configure the appropriate SQLNET.ORA parameters to enable Oracle Net to encrypt the redo
traffic shipped to the standby. An outline of the tasks to configure encryption on the client and
on the server using Oracle Net Manager is as follows:
a. Navigate to the Oracle Advanced Security profile.
b. Choose the Encryption tab.
c. Select CLIENT or SERVER from the list.
d. From the Encryption Type list, select one of the following: REQUESTED, REQUIRED,
ACCEPTED, or REJECTED.
e. (Optional) In the Encryption Seed field, enter between 10 and 70 random characters; the
encryption seed for the client should not be the same as that for the server.
f. Choose File > Save Network Configuration. The SQLNET.ORA file is updated.
g. Repeat this procedure to configure encryption on the other system.
Refer to the Oracle Database Advanced Security Administrators Guide for detailed information.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Activating a Physical Standby Database for
Reporting
Physical
standby
database
Flashback
Redo
apply
Redo
stream
Redo
transport
Guaranteed
restore
point
Primary
database
Activate
for
reporting
Activating a Physical Standby Database for Reporting
In Oracle Database 10g Release 2, using a combination of the capabilities of Data Guard, guaranteed
restore points, and the Flashback Database features, a physical standby database can be temporarily
activated in read/write mode for running reports and flashed back to revert it to a physical standby
database. When the physical standby database is flashed back, Data Guard automatically
synchronizes it with the primary database. You do not need to re-create the physical standby database
from a backup copy of the primary database.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Reporting
1. On the physical standby database, perform the
following steps:
a. Specify initialization parameters to define the flash
recovery area if not already configured.
b. Cancel Redo Apply.
c. Create a guaranteed restore point.
2. On the primary database, perform the following steps
to ensure that the physical standby database can be
reverted to the restore point:
a. Archive the current log.
b. Defer the log archive destination for the physical standby
database.
Activating a Physical Standby Database for Reporting (continued)
The steps to activate a physical standby database for reporting are outlined on this page and the next.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Reporting
3. Activate the physical standby database and set
protection mode to maximum performance.
4. Perform reporting or testing on the activated database.
5. Revert the activated database to a physical standby
database:
a. Flash back to the restore point.
b. Convert it back into a physical standby database.
6. On the primary database, reenable archiving to the
physical standby database destination.
7. Allow Data Guard to automatically resynchronize the
physical standby database or use RMAN incremental
backups from the primary database to resynchronize
the physical standby database.
Activating a Physical Standby Database for Reporting (continued)
When you activate a physical standby database temporarily as read/write, it does not receive logs
from the primary database to provide disaster protection. In this case, you should use multiple
standby databases to ensure full disaster protection while a standby is activated temporarily. Also,
you should note that any results stored in the database by a reporting tool are lost when the standby
database is flashed back. Any results that should be saved must be copied from the database before
flashing it back.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Cascaded Redo Log Destinations
Primary
database
Standby
database
Standby
database
Redo
Redo
Cascading Redo Log Destinations
To reduce the load on your primary system, you can implement cascaded redo log destinations,
whereby a standby database receives its redo data from another standby database instead of directly
from the primary database. You can configure a physical standby database to retransmit the incoming
redo data that it receives from the primary database to other remote destinations in the same manner
as the primary database.
Note: You must use SQL commands when managing a cascaded redo log destination configuration
because Data Guard broker does not support this feature.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Configuring Cascaded Redo Log Destinations:
Physical Standby
On the primary database, use the LGWR transport.
On the receiving standby database:
Configure standby redo logs.
Configure LOG_ARCHIVE_DEST_n to send redo to the next
standby.
Physical
standby
Primary
database
Physical or
logical standby
Configuring Cascaded Redo Log Destinations: Physical Standby
To enable a physical standby database to send the incoming redo data to another set of destinations,
you must do the following:
Define the LOG_ARCHIVE_DEST_n initialization parameter on the primary database to set up
a physical standby database as the starting point for a cascade to use the LGWR transport method.
Use either the SYNC or the ASYNC network protocol, depending on your requirements.
On the receiving physical standby database, define sufficient standby redo log files and ensure
that archiving is enabled.
Define the LOG_ARCHIVE_DEST_n initialization parameter on the physical standby database
that will define the end points of the cascade.
Remember that, as part of the original setup of the physical standby database, you should have
defined a local archive destination to be used for local archiving when the physical standby database
transitions to the primary role.
For example, you might define the LOG_ARCHIVE_DEST_1 initialization parameter to be the
'LOCATION=/physical1/arch' location. When the physical standby database switches roles,
any archived redo log files are put into that directory with the same format that you defined with the
LOG_ARCHIVE_FORMAT initialization parameter.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Configuring Cascaded Redo Log Destinations: Physical Standby (continued)
This local archiving destination can be the same as the one that is defined in the parameter
STANDBY_ARCHIVE_DEST, but this is not required.
A side effect of this configuration is that the archiver process on the standby database now tries to
send the redo data not only to the cascading end points, but also to the other standby databases and
the primary database if they are defined and enabled. The shipping of redo back to the primary or
another standby is not a problem, because the receiving database will reject it. If the destination is
another standby database and it has not received the log file successfully, then the shipping of redo
acts as an active gap resolution. You can avoid the shipping of redo to the primary and other standbys
by setting the state to DEFER for any destinations not involved in the cascade. However, you must
remember to enable them again if you do a switchover or failover operation.
If you want to have one initialization parameter file handle both the cascaded redo log destinations
and the original primary and standby destinations, define the destinations for the primary database
and other standby databases as well as for the cascading standby databases. However, the total
remote destinations still cannot exceed 10, including the local archiving destination.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Role Transitions with
Cascaded Redo Log Destinations
Standby databases that receive redo data from a
physical standby database:
No change: Switchover and failover are exactly the same.
May take longer
Standby databases that receive redo data from a logical
standby database cannot participate in a switchover
involving the primary database.
Role Transitions with Cascaded Redo Log Destinations
The process to perform a switchover or failover is exactly the same in a cascaded redo log
destinations configuration, because all physical standby databases that receive retransmitted primary
database redo data are identical and valid for role transitions. The only difference is that additional
time may be required for the end-of-redo data to cascade to the standby database.
Any standby database that receives redo data that is cascaded from a logical standby database cannot
participate in a switchover involving the primary database. (Only logical standby databases that
receive redo data directly from the primary database can participate in switchovers.) If you fail over
to a database that receives redo data generated by a logical standby database, then the only other
logical standby databases that receive redo data cascaded from the same logical standby database are
able to continue to participate in the Data Guard configuration after the failover.
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
Summary
In this lesson, you should have learned how to:
Back up the primary database with a physical standby
database
Back up a logical standby database
Use Flashback Database features in a Data Guard
configuration
Encrypt redo information
Configure cascaded redo log destinations
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y
O
r
a
c
l
e

U
n
i
v
e
r
s
i
t
y

a
n
d

S
Q
L

S
T
A
R

I
N
T
E
R
N
A
T
I
O
N
A
L

L
I
M
I
T
E
D

u
s
e

o
n
l
y

Other Considerations For Oracle Data Guard

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Other Considerations For Oracle Data Guard

Enviado por

Direitos autorais:

Formatos disponíveis

Copyright 2006, Oracle. All rights reserved.

Other Considerations for

Você também pode gostar