D17316GC21 Les07 7

Copyright 2006, Oracle. All rights reserved.
Creating a Logical Standby Database by

Using Enterprise Manager
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 7 - 2
Objectives
After completing this lesson, you should be able to do the
following:
Explain the advantages of SQL Apply
Explain when to use a logical standby database
Create a logical standby database by using Enterprise
Manager
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
Benefits of Implementing a
Logical Standby Database
Provides an efficient use of system resources:
Open, independent, and active production database
Additional indexes and materialized views can be created
for improved query performance.
Reduces workload on the primary database by
offloading the following workloads to a logical standby
database
Reporting
Summations
Queries
Benefits of Implementing a Logical Standby Database
A logical standby database provides disaster recovery, high availability, and data protection
benefits that are similar to those of a physical standby database. It also provides the following
specialized benefits:
Efficient utilization of system resources: A logical standby database is an open,
independent, and active production database. It can host multiple database schemas, and
users can perform normal data manipulation operations on tables in schemas that are not
updated from the primary database. It remains open while the tables are updated from the
primary database, and those tables are simultaneously available for read-access. Because
the data can be presented with a different physical layout, additional indexes and
materialized views can be created to improve your reporting and query requirements and to
suit your specific business requirements.
Reduction in primary database workload: The logical standby tables that are updated
from the primary database can be used for other tasks (such as reporting, summations, and
queries), thereby reducing the primary database workload.
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
Benefits of Implementing a
Provides data protection:
Primary database corruptions not propagated
Provides disaster recovery capabilities:
Switchover and failover
Minimizes downtime for planned and unplanned outages
Benefits of Implementing a Logical Standby Database (continued)
Data protection: A logical standby database provides a safeguard against data corruptions
and user errors. Primary-side physical corruptions do not propagate through the redo data
that are transported to the logical standby database. Similarly, user errors that may cause the
primary database to be permanently damaged can be resolved before application on the
logical standby through delay features.
Disaster recovery: A logical standby database provides a robust and efficient disaster-
recovery solution. Easy-to-manage switchover and failover capabilities allow easy role
reversals between primary and logical standby databases, minimizing the downtime of the
primary database for planned and unplanned outages.
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
Securing Your Logical Standby Database
Configure the database guard to control user access to
tables.
ALTER DATABASE GUARD command keywords:
ALL: prevents users from making changes to any data in
the database.
STANDBY: prevents users from making changes to any
data maintained by Data Guard SQL Apply.
NONE: normal security
Query GUARD_STATUS column in V$DATABASE.
Database guard level is set to ALL by broker
automatically on the logical standby database.
Database guard level applies to all users except SYS.
Securing Your Logical Standby Database
You can control user access to tables in a logical standby database by using the ALTER
DATABASE GUARD command to configure the database guard.
By default, it is not possible for a nonprivileged user to modify data on a Data Guard SQL Apply
database. This is because the database guard is automatically set to ALL. With this level of
security, only the SYS user can modify data.
When you set the security level to STANDBY, users are able to modify data that is not
maintained by the logical apply engine. A security level of NONE permits any user to access the
standby database as long as they have the correct privileges.
When creating a logical standby database manually with SQL commands, you must issue the
ALTER DATABASE GUARD ALL command before opening the database. Failure to do so will
allow jobs that are submitted through DBMS_JOB.SUBMIT to be scheduled and to potentially
modify tables in the logical 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
Preparing to Create a
Perform the following steps on the primary database
before creating a logical standby database:
1. Check for unsupported data types.
2. Be aware of unsupported DDL commands.
3. Ensure row uniqueness.
4. Verify that the primary database is configured for
ARCHIVELOG mode.
5. Enable supplemental logging.
Preparing to Create a Logical Standby Database
When creating a logical standby database, you must take several actions before you begin. The
following pages discuss these steps in detail.
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
Unsupported Objects
Log apply services automatically exclude unsupported
objects when applying redo data to the logical standby
database.
Unsupported objects:
Tables and sequences in the SYS schema
Tables using table compression
Tables used to support materialized views
Global temporary tables
Tables with unsupported data types (see list on next
page)
Unsupported Objects
If the primary database contains unsupported tables, log apply services automatically exclude
these tables when applying redo data to the logical 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
Unsupported Data Types
Log apply services automatically exclude tables with
unsupported data types when applying redo data to the
logical standby database.
Unsupported data types:
BFILE, ROWID, and UROWID
User-defined types
Object types REFs
Varrays
Nested tables
XMLtype
Ensure that your logical standby database can support the data types of the database objects that
are defined in your primary database.
Refer to Oracle Data Guard Concepts and Administration for additional information about
unsupported data types and objects.
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
Checking for Tables with
Query DBA_LOGSTDBY_UNSUPPORTED on the primary
database for tables with unsupported data types:
SQL> desc DBA_LOGSTDBY_UNSUPPORTED
Name Null? Type
-------------- -------- -------------
OWNER NOT NULL VARCHAR2(30)
TABLE_NAME NOT NULL VARCHAR2(30)
COLUMN_NAME NOT NULL VARCHAR2(30)
DATA_TYPE VARCHAR2(106)
Checking for Tables with Unsupported Data Types
You can query the DBA_LOGSTDBY_UNSUPPORTED data dictionary view to see all of the
tables that contain data types that are not supported by logical standby databases. These tables
are not maintained (do not have DML applied) in the logical standby database. Any changes
made to unsupported data types, tables, sequences, or views on the primary database are neither
propagated to the logical standby database, nor is an error message returned.
It is a good idea to query this view on the primary database to ensure that those tables necessary
for critical applications are not in this list before you create the logical standby database.
If the primary database includes unsupported tables that are critical, consider using a physical
standby database instead.
Note: This view does not show any tables from the SYS schema because changes to the SYS
schema object are not applied to the logical standby database. In addition, this view does not
show tables with table compression.
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
Unsupported DDL Commands
EXPLAIN
LOCK TABLE
SET CONSTRAINTS
SET ROLE
SET TRANSACTION
ALTER DATABASE
ALTER SESSION
ALTER MATERIALIZED VIEW
ALTER MATERIALIZED VIEW LOG
ALTER SYSTEM
CREATE CONTROL FILE
CREATE DATABASE
CREATE DATABASE LINK
CREATE PFILE FROM SPFILE
CREATE SCHEMA AUTHORIZATION
CREATE MATERIALIZED VIEW
CREATE MATERIALIZED VIEW LOG
CREATE SPFILE FROM PFILE
DROP DATABASE LINK
DROP MATERIALIZED VIEW
DROP MATERIALIZED VIEW LOG
Unsupported DDL Commands
Not all data definition language (DDL) commands that are executed on the primary database are
applied to the logical standby database. If you execute any of these commands (shown in the
slide) on the primary database, they are not executed on any logical standby database in your
configuration. You must execute them on the logical standby database to maintain consistency
between the primary database and the logical 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
Ensuring Unique Row Identifiers
Query DBA_LOGSTDBY_NOT_UNIQUE on the primary
database to find tables without a unique identifier:
BAD_COLUMN values:
Y: Data type is unbounded.
N: Table contains enough column information.
Add a primary key or unique index to ensure that SQL
Apply can efficiently apply data updates
SQL> desc DBA_LOGSTDBY_NOT_UNIQUE
Name Null? Type
-------------- -------- ------------
OWNER NOT NULL VARCHAR2(30)
TABLE_NAME NOT NULL VARCHAR2(30)
BAD_COLUMN VARCHAR2(1)
Ensuring Unique Row Identifiers
Because the row IDs on a logical standby database might not be the same as the row IDs on the
primary database, a different mechanism must be used to match the updated row on the primary
database to its corresponding row on the logical standby database. Primary keys and unique
indexes can be used to match the corresponding rows. It is recommended that you add a primary
key or a unique index to tables on the primary database (whenever appropriate and possible) to
ensure that SQL Apply can efficiently apply data updates to the logical standby database.
You can query the DBA_LOGSTDBY_NOT_UNIQUE view to identify tables in the primary
database that do not have a primary key or unique index with NOT NULL columns. Issue the
following query to display a list of tables that SQL Apply might not be able to uniquely identify:
SQL> SELECT OWNER, TABLE_NAME,BAD_COLUMN
2 FROM DBA_LOGSTDBY_NOT_UNIQUE
3 WHERE TABLE_NAME NOT IN
4 (SELECT TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED);
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
Ensuring Unique Row Identifiers (continued)
The key column in this view is BAD_COLUMN. If this view returns a row for a given table, you
may want to consider adding a primary or unique key constraint on the table.
A value of Y indicates that the table does not have a primary or unique constraint and that the
column is defined using an unbounded data type, such as CLOB. If two rows in the table match
except for values in their LOB column, then the table cannot be maintained properly and SQL
Apply stops.
A value of N indicates that the table does not have a primary or unique constraint but that it
contains enough column information to maintain the table in the logical standby database.
However, the redo transport services and log apply services run more efficiently if you add a
primary key. You should consider adding a disabled RELY constraint to these tables (as
described on the next 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
Adding a Disabled Primary Key
RELY Constraint
You can add a disabled RELY constraint to uniquely
identify rows:
SQL> ALTER TABLE hr.employees
2 ADD PRIMARY KEY (employee_id, last_name)
3 RELY DISABLE;
Adding a Disabled Primary Key RELY Constraint
If your application ensures that the rows in a table are unique, you can create a disabled primary
key RELY constraint on the table without incurring the overhead of maintaining a primary key
on the primary database.
The RELY constraint tells the system to log the named columns (in this example,
employee_id and last_name) to identify rows in this table. Be careful to select columns
for the disabled RELY constraint that uniquely identify the row. If the columns selected for the
RELY constraint do not uniquely identify the row, SQL Apply does not apply redo information
to the logical standby database. Supplemental logging must be set to MINIMAL or FULL as
described on the next page.
Note: For this example, assume that the HR.EMPLOYEES table does not have a primary key.
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
Supplemental Logging
Adds supplemental data to the log stream
Three levels of database supplemental logging:
Full: enables database-wide, before-image logging of
primary keys or unique indexes for all updates.
Minimal: Minimal amount of information needed for
LogMiner to identify, group, and merge the redo
operations that are associated with DML changes.
None: No additional redo information added to the redo
stream.
SQL Apply requires full supplemental logging.
Supplemental Logging
Supplemental logging must be enabled on the primary database to support a logical standby
database. Because an Oracle Database logs only the columns that were modified, this is not
always sufficient to uniquely identify the row that changed, and additional information must be
put into the stream of redo data. The supplemental information that is added to the redo data
helps SQL Apply correctly identify and maintain tables in the logical standby database.
The supplemental_db_logging clauses of the ALTER DATABASE command instructs
the Oracle Database server to add or stop adding supplemental data to the log stream.
Full supplemental logging (or identification key logging) enables database-wide, before-image
logging of primary keys or unique indexes (in the absence of primary keys) for all updates. With
this type of logging, an application can identify updated rows logically rather than resorting to
row IDs. This type of logging is required by SQL Apply.
On the primary database, issue the following statement to add primary key and unique index
information to the archived redo log file:
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
2 (PRIMARY KEY, UNIQUE INDEX) COLUMNS;
Note: The default for supplemental logging is None.
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 Supplemental Logging
Data Guard broker automatically enables supplemental
logging.
Manually enable full supplemental logging before you
create your logical standby:
Verify that the following columns in V$DATABASE
contain a YES value:
SUPPLEMENTAL_LOG_DATA_MIN
SUPPLEMENTAL_LOG_DATA_PK
SUPPLEMENTAL_LOG_DATA_UI
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
2 (PRIMARY KEY, UNIQUE INDEX) COLUMNS;
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
Enabling Supplemental Logging
You must enable full supplemental logging before you create the logical standby database. The
reason is that the logical standby database cannot use archived redo logs that contain both
supplemental log data and nonsupplemental log data.
Note: Enterprise Manager automatically enables supplemental logging when you create the
logical standby database.
The following columns in the V$DATABASE view have a YES value after supplemental logging
has been enabled. YES represents the following for the respective columns:
SUPPLEMENTAL_LOG_DATA_MIN: LogMiner has sufficient information to support
chained rows and various storage arrangements.
SUPPLEMENTAL_LOG_DATA_PK: All columns of the primary key are placed in the redo
log whenever there is an update.
SUPPLEMENTAL_LOG_DATA_UI: If any unique key columns are modified, all other
columns belonging to the unique key are also logged.
Note: If you enable full supplemental logging on your primary database and you have already
created physical standby databases, then you must enable supplemental logging on each physical
standby database to ensure that future switchovers work correctly.
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
Verifying Values of
Initialization Parameters
Verify the values for the following initialization parameters
on the primary database :
PARALLEL_MAX_SERVERS:
Set to 5 or greater.
Recommended value is 9.
LOG_PARALLELISM: Set to 1 (default).
SHARED_POOL_SIZE: Set to 160 MB or greater.
Verifying Values of Initialization Parameters
Verify the values of the following initialization parameters on the primary database before
creating the logical standby database (where the parameters will also be applicable):
PARALLEL_MAX_SERVERS: Value must be set to 5 or greater. The recommended value is
9. The SQL Apply Service on the logical standby site uses several parallel processes when
applying the SQL to the logical database.
LOG_PARALLELISM: Value must be set to 1. This is the default value. If this value is
changed, LogMiner on the logical standby site cannot read the redo logs.
SHARED_POOL_SIZE: Value should be 160 MB or greater. This is a recommendation.
Your configuration may operate with a lower value, but in a production environment a
lower value may cause performance degradation.
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
Creating a Logical Standby Database
with Enterprise Manager
Click Add Standby Database.
Creating a Logical Standby Database with Enterprise Manager
The following series of slides shows you how to add a logical standby database to an existing
configuration.
First, click Add Standby Database to invoke the Add Standby Database Wizard.
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 the Add Standby Database Wizard
Select Create a new logical
standby database.
Using the Add Standby Database Wizard
Select Create a new logical standby database on the Add Standby Database page, and then
click Continue.
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
Step 1: Specifying the Backup Type
Step 1: Specifying the Backup Type
On the Backup Type page of the wizard, select one of the two backup operations to use to create
the standby database (as you did when creating a physical standby database).
When you create a logical standby database, the wizard also identifies tables that cannot be
supported in your logical standby database and displays a list on the Backup Type page.
Click Next to continue.
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
Step 2: Specifying the Backup Options
Step 2: Specifying the Backup Options
On the Backup Options page, specify the parameters that are required to perform a new backup
of the primary database or to access an existing backup.
See the lesson titled Creating a Configuration with Enterprise Manager for additional
information about the parameters on the Backup Options 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
Step 3: Selecting the Database Location Instance
Name
Step 3: Selecting the Database Location Instance Name
On the Database Location page, specify the parameters that are required to create the standby
database and select the Oracle home in which to create the standby database. The standby
database can be created in any Oracle home that has been discovered by Oracle Enterprise
Manager. Only Oracle homes on hosts that match the architecture and version of the primary
host are shown.
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
Step 4: Specifying the Standby Database
File Locations Access Method
Step 4: Specifying the Standby Database File Locations Access Method
On the File Locations page, specify the location for the standby database files and customize
other selections based on whether the standby database is being created on a different host than
the primary database.
Note: The Standby Host Backup File Access section appears only when the standby database is
being created on a host other than the primary database. In this case, you must choose a method
to make the primary backup files accessible to the standby host.
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
Step 4: Specifying the Standby Database
File Locations File Locations
Step 4: Specifying the Standby Database File Location File Locations
When the primary and standby databases are on the same host, all standby database files are put
in an Optimal Flexible Architecture (OFA) directory structure by default.
When the primary and standby databases are on different hosts, you can use the Standby
Database File Locations section to put all the standby database files in an OFA directory
structure, or to keep file names and locations the same as the primary database.
You can optionally change the locations of individual standby database files by clicking
Customize, which displays the File Locations Customize page.
Data Guard automatically adds configuration information for the new standby database to the
listener.ora and tnsnames.ora files in the directory that is specified in the Network
Configuration File Location section. The default location is the network administration directory
of the standby database Oracle home.
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
Step 5: Specifying Standby Database
Configuration Parameters
Step 5: Specifying Standby Database Configuration Parameters
On the Standby Configuration page, you can specify configuration parameters for the standby
database. The configuration parameters include the instance name, service provider name, target
name, and standby archive location. The default values are based on corresponding primary
database settings.
When you create a new logical standby database, the following parameters must be configured:
Database Name: This field appears only when you are creating a new logical standby
database. (Physical standby databases use the same database name as the primary.)
A default database name is provided; you can specify any name that conforms to Oracle
naming conventions.
Database Unique Name: Specify a value for the DB_UNIQUE_NAME parameter.
This name must be unique in the Data Guard configuration.
Target Name: Specify a name for Enterprise Manager to use for the new standby database.
This name appears in the list of database targets maintained by Enterprise Manager. It is
recommended that this name be the same as the database unique name.
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
Step 6: Reviewing the
Configuration Information
Step 6: Reviewing the Configuration Information
The Review page of the wizard displays a summary of your selections and lists the parameters to
be used to create the new standby database.
The new standby database is created in the background by an Oracle Enterprise Manager job.
The name of the job that is submitted is provided at the top of the page.
When you click Finish, the Processing page appears. This page tracks each step through the
submission of the standby creation job. After the job submission is complete, you see the Data
Guard Overview page, where you can monitor the progress of the standby creation job.
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 Database Creation Processing
Standby Database Creation Processing
You can view the progress of the Add Standby Database process on the Processing page. When
the process completes, Enterprise Manager displays the Data Guard Overview 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
Automatic Deletion of Redo Log
Files by SQL Apply
Logical
standby
database
Redo
logs from
primary
database
Transform redo
information into
SQL
Delete redo log files
SQL
Apply
Automatic Deletion of Redo Log Files by SQL Apply
In Oracle Database 10g Release 2, archived redo logs on the logical standby database are
automatically deleted by SQL Apply after they have been applied. This feature reduces the
amount of space consumed on the logical standby database and eliminates the manual step of
deleting the archived redo log files.
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 and Disabling the Auto-Delete Feature
Enabling the auto-delete feature:
Disabling the auto-delete feature:
EXECUTE dbms_logstdby.apply_set
('LOG_AUTO_DELETE','TRUE');
EXECUTE dbms_logstdby.apply_set
('LOG_AUTO_DELETE','FALSE');
Enabling and Disabling the Auto-Delete Feature
You can enable the auto-delete feature for archived redo logs with the
DBMS_LOGSTDBY.APPLY_SET procedure as shown. By default, the auto-delete feature is
enabled in Oracle Database 10g Release 2.
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:
Explain the advantages of a logical standby database
Decide when to use a logical standby database
Create a logical standby by using Enterprise Manager
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 7: Overview
This practice covers the following topics:
Creating a logical standby database using the
Add Standby Database Wizard
Verifying 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

D17316GC21 Les07 7

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 Les07 7

Caricato da

Copyright:

Formati disponibili

Copyright 2006, Oracle. All rights reserved.

Creating a Logical Standby Database by

Potrebbero piacerti anche