D17316GC21 Les09 9

Copyright 2006, Oracle. All rights reserved.
Performing Switchover and 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
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 9 - 2
Objectives
After completing this lesson, you should be able to do the
following:
Explain the database roles
Perform a switchover
Perform a failover
Use Flashback Database after a 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
Types of Roles in an
Oracle Data Guard Configuration
There are two types of roles in an Oracle Data Guard
configuration:
User role: identifies the group and determines the
privileges assigned to a user.
Database role: identifies what role (primary or standby)
the database plays in a Data Guard configuration.
SQL> SELECT database_role FROM v$database;
DATABASE_ROLE
----------------
LOGICAL STANDBY
Types of Roles in an Oracle Data Guard Configuration
User roles are named groups of related privileges that you grant to users or other user roles. User
roles are designed to ease the administration of the end-user system and schema object
privileges.
Database roles identify what part the database is playing in the Data Guard configuration. A
database can be in one of two roles:
Primary
Standby
A database that is in the standby role is one of the following types:
Physical standby
Logical standby
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 Management Services
A database operates in one of two mutually exclusive
roles in a Data Guard configuration:
Primary role: The database is operating in the primary
role, and redo transport services are shipping redo to the
standby databases.
Standby role: The database is operating in the standby
role, and log apply services are applying the archived
redo logs to the standby database.
With role management services, you can change these
roles dynamically.
Role Management Services
You can use role management services to change the primary and standby roles dynamically as a
planned transition called a switchover operation, or as a result of a database failure through a
failover operation.
For example, you might perform a switchover operation to transition the primary database to the
standby role and transition a standby database to the primary role to perform routine
maintenance tasks.
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: Switchover and Failover
Not automatically invoked
Switchover
Planned role reversal
Used for OS or hardware maintenance
Failover
Unplanned role reversal
Used in an emergency
Minimal or no data loss depending on the
data-protection mode
Fast-start failover can be enabled for automatic failover
Role Transitions: Switchover and Failover
Switchover and failover operations are not invoked automatically. You must initiate switchover
or failover operations by using a SQL statement or by using the Data Guard GUI or Data Guard
broker command-line interface (CLI).
Switchover
You can use the switchover feature to switch the role of the primary database to one of the
available standby databases. The chosen standby database becomes the primary database, and
the original primary database then becomes a standby database. There is no need to
re-create any of the databases in the switchover operation. There is no data divergence between
the original and the new primary database after the successful completion of the database
switchover.
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: Switchover and Failover (continued)
Failover
You invoke a failover operation when a catastrophic failure occurs on the primary database, and
there is no possibility of recovering the primary database in a timely manner. During a failover
operation, the incapacitated primary database is removed from the Data Guard environment and
a standby database assumes the primary database role. You invoke the failover operation on the
standby database that you want to fail over to the primary role.
Note: You can enable fast-start failover to fail over automatically when the primary database
becomes unavailable. When fast-start failover is enabled, the broker determines if a failover is
necessary and initiates the failover to the specified target standby database automatically, with
no need for DBA intervention and with no loss of data. Fast-start failover is discussed in detail
in the lesson titled Enabling Fast-Start 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
Choosing the Best Role Transition Operation
Are you performing a planned role
transition so that you can perform
hardware or software maintenance
on the system that currently hosts
the primary database?
Switch over to
best available
standby
database.
Yes
Can you run crash recovery to
repair the primary database in
a timely manner?
Yes
Repair
primary
database.
No
No
Fail over to best
available standby
database.
Choosing the Best Role Transition Operation
The goal of a role transition (switchover or failover) is to bring the new primary database online
as quickly as possible with no data loss or with the least possible data loss. The decision tree
shown in the slide can help you choose the role transition operation that best minimizes
downtime and the risk of data loss. In general, you should always consider performing crash
recovery to repair the primary database or performing a switchover before you consider
performing a failover.
Repairing the primary database may be faster than transitioning a standby database to the
primary role, even when you are using a no-data-loss environment. If you can repair the primary
database, you also do not have to reconfigure client applications to connect to a new database.
However, if the repair operation results in any data loss, you may need to re-create all other
standby databases in the configuration from a backup of the repaired primary database.
In general, the best standby database to transition to is a physical standby database that has the
most redo applied to it.
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
Switchover
Transitions the roles of the primary and standby
databases
No resetting of the online redo logs of the new primary
database
No data loss
Switchover
A switchover operation transitions the primary database to the standby role and transitions the
standby database to the primary role, without resetting the online redo logs of the new primary
database.
If the switchover operation involves a physical standby database, both the primary database and
the physical standby database switching over to the primary role will be shut down and restarted.
However, there is no need to shut down and restart any other standby databases that are not
participants in the switchover operation. If the switchover operation involves a logical standby
database, there is no need to shut down and restart either the primary database or any of the
standby databases. Logical standby databases do not need to be shut down and restarted.
Note: All extra RAC instances will be shut down and restarted.
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
Switchover: Before
Standby
database
Read/write
transactions
Primary
database
San Francisco
Boston
Oracle Net
Application
Application
Read-only
reports
Switchover: Before
For example, assume that the primary database is located in San Francisco and the physical
standby database is located in Boston. Switchovers are initiated only on the primary database.
They cannot be initiated from the standby 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
Switchover: After
Standby
database
Read/write
transactions
Primary
database
Application
Application
Read-only
reports
San Francisco
Boston
Oracle Net
Switchover: After
After the switchover completes, each database has the role opposite to the one that it had before
the switchover. In our example, Boston is now the primary database and San Francisco is the
standby database.
Data Guard does not automatically switch over sessions from one database to the other, so active
sessions for each system need to reconnect.
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
Standby Redo Logs and Switchovers
Standby redo logs should be configured on the primary
database to ease switchovers.
Redo
shipment
RFS
Standby
redo
logs
Online redo
logs
Primary
database
Standby
database
Standby
redo
logs
Standby Redo Logs and Switchovers
Standby redo log configuration should be identical on the primary database and on any physical
standby databases. Even though the standby redo logs are not used when the database is in the
primary role, configuring the standby redo logs on the primary database is recommended in
preparation for an eventual switchover operation.
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
Preparing for a Switchover
Verify the following in preparation for the switchover
operation: network connectivity between the primary and
standby locations.
Preparing for a Switchover
Each location in the Data Guard configuration should have connectivity through Oracle Net to
the primary database and to all associated standby databases.
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
Performing a Switchover by Using
Enterprise Manager
Select the database and
click Switchover.
Performing a Switchover with Enterprise Manager
The following tasks are performed when Enterprise Manager is used for the switchover:
a. A check is made to ensure that the primary database and standby database are not currently
in an error status condition and that broker management of the primary database is enabled
and online.
b. Any active sessions connected to the primary database are automatically closed during the
switchover.
c. The primary database is first changed to the standby role, and then the standby database is
changed to the primary role.
d. If the switchover target is a physical standby database, the target and primary databases are
each restarted.
To initiate a switchover by using Enterprise Manager:
1. On the Data Guard page, select the standby database that you want to become the primary
database.
2. Click Switchover.
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
Enterprise Manager
Click Yes to confirm.
Performing a Switchover with Enterprise Manager (continued)
3. The Data Guard Switchover Confirmation page appears.
4. You can view active sessions by clicking the Browse Primary Database Sessions link.
5. Click Yes to continue with the switchover, or click No to cancel.
You cannot cancel the switchover operation after it has begun.
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
Enterprise Manager
Performing a Switchover with Enterprise Manager (continued)
The Data Guard Switchover processing page displays the progress of the switchover operation as
it performs the following steps:
Switch roles between the primary and standby databases. If the switchover target is a
physical standby database, it is restarted along with the primary database.
Wait for the Data Guard broker to complete the initialization tasks required to switch the
database roles.
You can view the database alert log of the primary and standby databases by clicking the
respective View alert log links. A new browser window opens with the content of the alert log.
After the switchover operation is complete, you are returned to the Data Guard page.
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
Performing a Switchover
to a Physical Standby by Using SQL
Perform these steps only if you are not using the Data
Guard broker.
On the original primary database:
1. Verify that it is possible to perform a switchover
operation.
2. Initiate the switchover operation on the primary
database:
3. Shut down and restart the instance.
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO
2 PHYSICAL STANDBY;
Performing a Switchover to a Physical Standby by Using SQL
You can perform a switchover using SQL, as described in the following steps. You should not
execute these steps when managing your configuration with the Data Guard broker. Consider
using the Data Guard broker to automate and simplify the switchover procedure.
Execute steps 1 through 3 on the original primary database:
1. Query the SWITCHOVER_STATUS column of the V$DATABASE view on the primary
database to verify that it is possible to perform a switchover operation.
A TO STANDBY value in the SWITCHOVER_STATUS column indicates that it is possible
to switch the primary database to the standby role.
2. To transition the primary database to a physical standby database role, execute the
following SQL statement:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO
2 PHYSICAL STANDBY WITH SESSION SHUTDOWN WAIT;
The WAIT option specifies that control is not returned to you until the statement completes.
3. Shut down the instance and restart the database in MOUNT mode:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
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
to a Physical Standby by Using SQL
On the original physical standby database:
1. Verify the switchover status in the V$DATABASE view.
2. Switch the physical standby database role to the
primary role.
3. If the standby database was opened read-only, shut
down and restart the new primary database. If it was
not opened read-only, open the database.
4. Begin archiving logs to the physical standby database.
Performing a Switchover to a Physical Standby by Using SQL (continued)
Execute steps 4 through 7 on the original standby database:
4. After you switch the primary database to the standby role and the switchover notification
has been received by the standby database, you should verify that the switchover
notification has been processed by the standby database by querying the
SWITCHOVER_STATUS column of the V$DATABASE fixed view on the standby database.
You should see a value of TO_PRIMARY.
5. Execute the following SQL statement on the physical standby database that you want to
switch to the primary role: ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
6. If the standby database was opened read-only, shut down and restart the new primary
database.
SQL> STARTUP;
If it was not opened read-only, open the database with the ALTER DATABASE OPEN
command.
The selected physical standby database is now transitioned to the primary database role.
There is no need to shut down and restart any other standby databases that were online at
the time of the switchover operation.
7. Issue the following statement on the new primary database to start redo transport:
SQL> ALTER SYSTEM SWITCH LOGFILE;
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
to a Logical Standby by Using SQL
1. Verify that it is possible to perform a switchover.
2. Prepare the primary database for the switchover:
SQL> ALTER DATABASE PREPARE TO SWITCHOVER
2 TO LOGICAL STANDBY;
Performing a Switchover to a Logical Standby by Using SQL
When you perform a switchover that changes roles between a primary database and a logical
standby database, you must always initiate the switchover on the primary database and complete
it on the logical standby database.
Perform steps 1 and 2 on the original primary database:
1. Query the SWITCHOVER_STATUS column of the V$DATABASE view on the primary
database to verify that it is possible to perform a switchover operation.
A TO STANDBY or SESSIONS ACTIVE value in the SWITCHOVER_STATUS column
indicates that it is possible to switch the primary database to the standby role.
2. Issue the following SQL statement to prepare the current primary database for a logical
standby database role:
This statement notifies the current primary database that it will soon switch to the logical
standby role and begin receiving redo data from a new 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
On the original logical standby database:
3. Prepare the logical standby database for switchover:
2 TO PRIMARY;
Performing a Switchover to a Logical Standby by Using SQL (continued)
Perform step 3 on the logical standby database:
3. Issue the following statement to build a LogMiner dictionary on the logical standby
database that is the target of the switchover:
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
This statement also starts redo transport services on the logical standby database to begin
transmitting its redo data to the current primary database and to other standby databases in the
Data Guard configuration. The sites receiving redo data from this logical standby database
accept the redo data, but they do not apply it.
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
4. Verify the switchover status in V$DATABASE.
5. Switch the primary database to the logical standby
database role:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER
Perform steps 4 and 5 on the original primary database:
4. Verify that the LogMiner dictionary was received by the primary database by querying the
SWITCHOVER_STATUS column of V$DATABASE on the primary database. When the
query returns TO LOGICAL STANDBY in the SWITCHOVER_STATUS column, proceed
with step 5.
5. Issue the following SQL statement to transition the primary database to a logical standby
database role:
This statement waits for all current transactions on the primary database to end and prevents
any new users from starting new transactions. It also puts a marker in the redo data to
provide a synchronization point for logical standby database operations.
Executing this statement also prevents users from making any changes to the data being
maintained in the logical standby database. To ensure faster execution, ensure that the
primary database is in a quiet state with no update activity before issuing the switchover
statement. You can query V$TRANSACTIONS for the status of any current in-progress
transactions that could delay execution of this statement.
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
2 TO PRIMARY;
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
On the new primary database (original logical standby
database):
6. Verify the switchover status in V$DATABASE.
7. Switch the logical standby database to the primary
database role.
8. Ensure that all standby databases begin receiving redo
data.
Perform steps 6, 7, and 8 on the new primary database (original logical standby database):
6. Verify that the switchover notification was processed by the target standby database by
querying the SWITCHOVER_STATUS column of the V$DATABASE fixed view on the
target standby database. The SWITCHOVER_STATUS value is updated to show progress
during the switchover. When the status is TO PRIMARY, proceed with step 7.
7. Issue the following SQL statement to switch the logical standby database to the primary
role:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
8. Issue the following statement to perform a log switch and to ensure that all logical standby
databases begin receiving redo data from the new primary database:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
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
On the new logical standby database:
9. Start SQL Apply.
SQL> ALTER DATABASE
2 START LOGICAL STANDBY APPLY;
Perform step 9 on the new logical standby database:
9. Issue the following statement to start SQL Apply:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
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
Considerations When Performing a Switchover to
a Logical Standby Database
Switchover operation does not cause a shutdown of
the primary.
There is no need to terminate user sessions, but
termination is recommended.
Logical standby database may not have all data.
Considerations When Performing a Switchover to a Logical Standby Database
Consider the following when performing a switchover to a logical standby database:
Unlike a switchover to a physical standby database, a switchover to a logical standby
database does not require a shutdown of the primary database.
If you are switching over to a logical standby database, you do not need to terminate
applications that are connected to the current primary database or to the logical standby
database, because neither database is shut down during the switchover operation. However,
because sessions on the old primary database may fail after the switchover operation
completes and the database guard is turned on, you should terminate such open sessions
now. The database guard prevents users from making changes in the logical standby
database.
If you switch over to a logical standby database, there may be a loss of data if the logical
standby database contains only a subset of the data that is present in 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
Situations That Prevent a Switchover
You cannot perform a switchover in the following
situations:
Archived redo log files are unavailable.
Point-in-time recovery is required.
Production database is not open and cannot be
opened.
Situations That Prevent a Switchover
The following situations prevent the execution of a switchover operation:
Archived redo log files are unavailable: If there is a gap in the archived redo log files on
the standby database, you are not able to switch over to that standby database.
Point-in-time recovery is required: When you perform a switchover to a standby
database, you always switch over to the current state of the primary database. You cannot
switch over to a time in the past.
Production database is not open and cannot be opened: A switchover is initiated on the
primary database while it is in the open state. If you cannot open the primary database, a
switchover is not possible.
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
Failover
Standby
database becomes
primary database.
Read/write
transactions
Online redo
logs
Local
archiving
San Francisco
Boston
Archived redo
logs
Application
Online Redo
Logs
Local
Archiving
Archived redo
logs
Primary
database
Failover
You invoke a failover operation when a catastrophic failure occurs on the primary database and
there is no possibility of recovering the primary database in a timely manner. During a failover
operation, the primary database is removed from the Data Guard environment and a standby
database assumes the primary database role. Failing over to a standby database is a permanent
operation. You cannot undo the failover and return the database to its former role as a standby
database. Because of this, you should invoke a failover operation only in an emergency.
It is not always necessary to fail over to the standby database. In some cases, recovery of the
primary database may be faster. Most failures can be resolved at a primary database within a
reasonable amount of time.
In a failover operation:
The original primary database is presumed to be lost. You must re-create (or flash back) the
original primary database as a new standby database, if desired.
Standby databases that are online at the time of the failover operation, but are not involved
in the role transition, do not need to be shut down and restarted.
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
Failover Considerations
Old primary database is no longer part of the
configuration.
Data loss is possible.
Failover should be used only in an emergency.
Special-case failover: activation of a standby
Failover Considerations
During a failover operation, a standby database transitions to the primary role and the old
primary database is rendered unable to participate in the configuration. Depending on the
protection mode under which the old primary database was operating before the failover, there
may be some or no data loss during a failover. A failover is typically used only when a primary
database becomes incapacitated and there is no possibility of performing a switchover or
successfully repairing the primary database within a reasonable amount of time. The specific
actions that are performed during a failover vary depending on whether a logical or physical
standby database is involved in the failover operation, the state of the configuration at the time
of the failover, and the specific SQL commands that are used to initiate the failover.
There is also a special-case failover in which the standby database is activated. This should be
avoided unless absolutely necessary because it causes all other databases in the configuration to
become permanently disabled.
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
Performing a Failover by Using
Enterprise Manager
Select the database and
click Failover.
Performing a Failover with Enterprise Manager
You should perform a failover only in the event of a software or system failure that results in the
loss of the primary database. The failed primary database is disabled by the broker and must be
re-created. The standby database then assumes the primary database role.
To initiate a failover by using Enterprise Manager:
1. On the Data Guard page, select the standby database that you want to become the primary
database.
2. Click 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
Enterprise Manager
Performing a Failover with Enterprise Manager (continued)
3. Confirm that you want to proceed with the failover operation by clicking Yes.
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
Enterprise Manager
Select the failover type and
click Yes.
4. On the Data Guard Failover Confirmation page, you must specify the type of failover that
you want to perform:
- Complete: All available redo is applied on the standby database. Oracle Corporation
recommends that you specify this type of failover.
- Immediate: No additional data is applied on the standby database resulting in a data
loss failover and should be used only when a Complete failover is not possible.
5. Select the failover option, and then click Yes to confirm the failover operation.
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
Enterprise Manager
After you click Yes, the Failover Processing page shows you the progress of the failover
operation.
You cannot cancel this operation after it begins.
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
Performing a Failover
to a Physical Standby Database
The physical standby
database needs to be
reinstated.
Performing a Failover to a Physical Standby Database
During the failover operation, the selected standby database transitions into the primary role. If
the failover target is a physical standby database, it is restarted. If you are failing over to a
logical standby database, it is not restarted. When the operation is completed, the Data Guard
Overview page reflects the updated configuration.
After a complete or immediate failover, the primary database and some standby databases may
need to be reinstated or re-created.
To reinstate the database, click the Database must be reinstated link. Click Reinstate on the
General Properties page. Enterprise Manager reinstates the database as a standby database to the
new primary database.
Note: Flashback Database must have been enabled on the database prior to the failover and there
must be sufficient flashback logs on that database for the reinstatement to succeed. In addition,
the database to be reinstated and the new primary database must have network connectivity.
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
Performing a Failover
to a Logical Standby Database
The logical standby database
is now the primary database.
The physical standby
database is disabled.
Performing a Failover to a Logical Standby Database
When you perform a failover to a logical standby database, any physical standby databases in
the configuration are permanently disabled after the failover and are no longer usable. These
databases must be re-created from the new 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
Performing a Failover to a
Physical Standby Database by Using SQL
1. Identify and resolve any gaps in the archived redo log
files.
2. Repeat step 1 until all gaps are resolved.
3. Copy any other missing archived redo log files.
4. Initiate the failover operation on the target standby
database.
5. Convert the physical standby database to the primary
role.
6. Complete the transition of the standby database to the
primary database role.
7. (Optional) Back up the new primary database.
8. (Optional) Restore the failed primary database.
Performing a Failover to a Physical Standby Database by Using SQL
Perform the following steps to fail over to a physical standby database by using SQL.
Note: If the target standby database was operating in maximum protection mode, no gaps in the
archived redo log files should exist, and you can proceed directly to step 4. Otherwise, begin
with step 1 to determine if any manual gap resolution steps must be performed.
1. To determine if there are gaps in the archived redo log files on the target standby database,
query the V$ARCHIVE_GAP view. This view contains the sequence numbers of the
archived redo log files that are known to be missing for each thread. The data returned
reflects the highest gap only.
SQL> SELECT thread#, low_sequence#, high_sequence#
2 FROM v$archive_gap;
If possible, copy all of the identified missing archived redo log files to the target standby
database from the primary database and register them. Execute the following command to
register the redo log files:
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
Perform this step for each thread.
2. Repeat step 1 until all gaps are resolved. The query that is executed in step 1 displays
information for the highest gap only. Repeat step 1 until the query returns no rows.
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
Performing a Failover to a Physical Standby Database by Using SQL (continued)
3. To determine if there are any other missing archived redo log files, query the
V$ARCHIVED_LOG view on the target standby database to obtain the highest sequence
number for each thread.
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#)
2 OVER (PARTITION BY thread#) AS LAST
3 FROM V$ARCHIVED_LOG;
Copy to the target standby database any available primary database archived redo log files
that contain sequence numbers higher than the highest sequence number that is available on
the target standby database. Then register those redo log files by issuing the following SQL
statement:
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
Perform this step for each thread.
After registering all available archived redo log files, query the V$ARCHIVE_GAP view (as
described in step 1) to verify that no additional gaps were introduced in step 3.
4. Execute the following SQL statement to initiate the failover:
SQL> ALTER DATABASE RECOVER
2 MANAGED STANDBY DATABASE FINISH FORCE;
5. Transition the physical standby database to the primary database role by issuing the
following SQL statement:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
After issuing this SQL statement, you can no longer use this database as a standby database.
Any subsequent redo that is received from the original primary database cannot be applied.
During the failover process, the standby redo log files are automatically archived and
recovered on all other standby databases that are derived from the original primary database
if the standby destinations are correctly defined on the new primary database.
Perform step 6 on the new primary database.
6. If the physical standby database has not been opened in read-only mode since the last time
it was started, open the new primary database as follows and proceed to step 7:
SQL> ALTER DATABASE OPEN;
If the physical database has been opened in read-only mode since the last time it was
started, shut down the target standby database (new primary database) and restart it as
follows:
SQL> STARTUP;
7. Perform an open backup of the database after opening the database. Although performing a
backup immediately is not required, it is recommended because you cannot recover changes
that are made after the failover without a complete backup copy of the 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
Performing a Failover to a Physical Standby Database by Using SQL (continued)
8. After a failover, the original primary database no longer participates in the configuration.
After performing a failover, you may be able to optionally restore the failed primary
database as a new standby database using either of the following methods:
- Use Flashback Database to restore the failed primary database to a point in time before
the failover occurred, and then convert it into a standby database.
- Re-create the failed database and add it to the configuration as a new standby database.
To reuse the old primary database in the new configuration, you must re-create it as a
standby database using a backup copy of the new primary database.
After the failed primary database is restored and is operating in the standby role,
you can optionally perform a switchover to transition the databases to their original
(pre-failure) roles.
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
Logical Standby Database by Using SQL
1. Copy missing redo logs to the logical standby
database.
2. Register the missing redo logs:
3. If it exists, register the partially filled archive log file.
4. Ensure that all redo log files have been applied to the
new primary database.
SQL> ALTER DATABASE REGISTER LOGICAL
2 LOGFILE 'filespec';
SQL> SELECT APPLIED_SCN, LATEST_SCN
2 FROM V$LOGSTDBY_PROGRESS;
Performing a Failover to a Logical Standby Database by Using SQL
To perform failover for logical standby databases using SQL:
1. If redo logs exist on the primary database that have not yet been applied on the logical
standby database, manually copy the redo logs to that standby database.
2. You must register the redo log files that you manually copied from the original primary
database. Issue the following SQL statement for each missing redo log file on the logical
standby:
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE 'filespec';
3. On the logical standby database, check if there is a partially written archived log file. If it
exists, this file has a sequence number that is one greater than the last registered archived
log file. If it exists, register the partially filled archived log file.
4. On the new primary database, ensure that the remaining redo logs have been applied by
checking the V$LOGSTDBY_PROGRESS view. When the values in the APPLIED_SCN
and LATEST_SCN columns are equal, all available redo has been applied. The logical
standby database now contains as much data as possible from the primary database. Issue
the following query:
SQL> SELECT APPLIED_SCN, LATEST_SCN
2 FROM V$LOGSTDBY_PROGRESS;
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
Logical Standby Database by Using SQL
5. Activate the new primary database:
6. Enable archiving of redo logs.
7. Begin SQL Apply operations on all logical standby
databases:
SQL> ALTER DATABASE ACTIVATE
2 LOGICAL STANDBY DATABASE
3 FINISH APPLY;
SQL> ALTER DATABASE START LOGICAL STANDBY
2 APPLY NEW PRIMARY dblink;
Performing a Failover to a Logical Standby Database by Using SQL (continued)
5. To stop the RFS process, apply remaining redo, stop SQL Apply, and activate the database
in the primary database role, issue the following statements on the logical standby database
that you are transitioning to the new primary role:
SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE
2 FINISH APPLY;
6. Enable archiving of redo logs to all remote logical standby destinations, as in the following
example:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE
In general, when the database operates in the primary role, you must enable archiving of
redo logs to remote destinations. When the database operates in the standby role, you must
disable archiving of redo logs to remote destinations.
7. Issue the following command to begin SQL Apply operations on all logical standby
databases in the configuration:
SQL> ALTER DATABASE START LOGICAL STANDBY
2 APPLY NEW PRIMARY dblink;
Note: Any logical standby databases that are more current (have applied more redo operations)
than the standby database to which the primary database has failed over to must be re-created
from a backup of the new primary database and added back to the configuration.
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 Standby Database
When you are unable to fail over, you can activate a
standby database by issuing one of the following
commands (depending on the role of the database):
2 LOGICAL STANDBY DATABASE;
2 PHYSICAL STANDBY DATABASE;
Activating a Standby Database
You can use the ALTER DATABASE ACTIVATE STANDBY DATABASE command to force the
standby database into the primary role. Specify the appropriate option, PHYSICAL or
LOGICAL, for the type of database that you are activating. You can issue this command in a
situation in which you cannot perform a failover operation.
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
Restoring Databases After a Role Transition
Additional steps may be needed to restore your disaster-
recovery solution after a role transition:
Databases may be disabled, but are not removed from
the broker configuration.
Reenable broker management of the databases:
Reinstate databases using the REINSTATE DATABASE
command or through Enterprise Manager.
Re-create databases from a copy of the primary database
and reenable the database.
Restoring Databases After a Role Transition
If a database can be reinstated, it has the following status after a complete failover: ORA-16661:
the standby database needs to be reinstated. The Database must be reinstated message is
displayed in the Status column in Enterprise Manager. Reinstate the database using the
DGMGRL REINSTATE DATABASE command or the reinstate option in Enterprise Manager.
A database that must be re-created from a copy of the new primary database, has the following
status: ORA-16795: the broker detects that database re-creation is required. Re-create the
standby database from a copy of the primary database and then reenable it.
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 Through Standby Database
Role Transitions
Use Flashback Database to flash back a database to a
point in time before a switchover or failover.
Primary and standby databases retain their current
roles when you flash back through physical standby
switchovers or failovers.
Database roles will be flashed back when you flash
back through logical standby switchovers or failovers.
Flashback database can be used to undo a physical
database activation.
Flashback Through Standby Database Role Transitions
You can use Flashback Database to revert a database to a point in time before a physical standby
database switchover or failover. The database role does not change when flashing back through a
physical standby switchover, failover, or activation.
In a logical standby database, the FLASHBACK DATABASE command reverts the database to a
system change number (SCN) or timestamp before a switchover or failover. For a logical
standby database, the database reverts to its original role at the time of the flashback SCN or
flashback time.
You can also use Flashback Database to undo a physical standby activation, making a physical
standby database more useful. Previously, you could open standby databases as read-only only.
Read-only mode is usually not adequate for running report tools because these tools typically
also change the database. In Oracle Database 10g Release 2, a physical standby database can be
temporarily activated to run reports and tests. After noting or saving the results, you can flash
back your database to revert to a standby 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 Failover
Failover
New standby database
Redo
Redo
New primary database
Flashback
Primary
database
Standby
database
Using Flashback Database After Failover
You invoke a failover operation when a catastrophic failure occurs on the primary database and
there is no possibility of recovering the primary database in a timely manner. After a failover
operation, the old standby database becomes the new primary database, and the old primary
database is placed in the needs reinstatement state.
You can use the Flashback Database feature to convert the old primary database into a new
standby database without re-creating the database. You can flash back the old primary database
so that it contains only those changes that are already applied to the old standby database. This
enables you to convert the old primary database into a new standby database without restoring
the old primary database.
Note: You must have the Flashback Database feature enabled on the old 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
Using Flashback Database After Failover (continued)
Physical Standby Configuration
In a physical standby configuration, use the following procedure to avoid reinstantiating the old
primary database after a failover:
1. On the new primary database, issue the following query to determine the system change
number (SCN) at which the old standby database became the new primary database:
SELECT standby_became_primary_scn FROM v$database;
2. After the old primary database site is available, mount the old primary database.
STARTUP MOUNT;
3. Flash back the old primary database to the standby became primary SCN that you
determined in step 1:
FLASHBACK DATABASE TO SCN <SCN>;
4. On the old primary database, issue the following command to convert the control file to a
standby control file:
ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
5. Shut down the old primary instance.
SHUTDOWN IMMEDIATE;
6. Mount the old primary database. The old primary database is now your new standby
database.
STARTUP MOUNT;
7. On the new primary database, enable redo transport to the old primary database (new
standby database). Check the status of the archive destinations and enable any that are not
enabled.
SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE,
DESTINATION, ERROR, SRL FROM V$ARCHIVE_DEST_STATUS;
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;
Then, archive a new log to the new standby by issuing the following command:
ALTER SYSTEM ARCHIVE LOG CURRENT;
8. On the new standby database, start managed standby recovery. The role reversal is now
complete:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
If you are using real-time apply:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE DISCONNECT;
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 Failover (continued)
Logical Standby Configuration
In a logical standby configuration, use the following procedure to avoid reinstantiating the old
primary database after a failover:
1. On the new primary database, issue the following query to determine the SCN to which you
want to flash back the failed primary database:
SELECT applied_scn AS flashback_scn
FROM v$logstdby_progress;
2. On the new primary database, issue the following query to determine if you need to copy
any redo log files to the failed primary database so that Flashback Database reaches a
consistent state:
SELECT NAME FROM DBA_LOGSDTBY_LOG
WHERE NEXT_CHANGE# >
(SELECT VALUE FROM DBA_LOGSTDBY_PARAMETERS
WHERE NAME = 'STANDBY_BECAME_PRIMARY_SCN')
AND FIRST_CHANGE <= (FLASHBACK_SCN from step 1);
3. Shutdown (if required) and mount the failed primary database.
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
4. Flash back the old primary database to the standby became primary SCN that you
determined in step 1:
FLASHBACK DATABASE TO SCN <SCN>;
5. Enable the Data Guard guard to prevent the job queue from executing:
ALTER DATABASE GUARD ALL;
6. Open the database with the RESETLOGS option:
ALTER DATABASE OPEN RESETLOGS;
7. Create a database link to the new primary database:
CREATE PUBLIC DATABASE LINK mylink
CONNECT TO system IDENTIFIED BY password
USING 'service_name_of_new_primary_database';
8. Start SQL Apply:
ALTER DATABASE START LOGICAL STANDBY
APPLY NEW PRIMARY mylink;
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:
Use the Data Guard GUI to perform switchover and
failover operations
Use SQL commands to perform switchover and failover
operations
Use Flashback Database after a 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
Practice 9: Overview
This practice covers the following topics:
Performing a switchover
Performing a 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
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

D17316GC21 Les09 9

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

D17316GC21 Les09 9

Caricato da

Copyright:

Formati disponibili

Copyright 2006, Oracle. All rights reserved.

Performing Switchover and Failover

Potrebbero piacerti anche