Data guard logical_r3.1

Oracle10g Data Guard
Overview / Logical Standby
Bill Sutton
SAIC
suttonbi@saic.com

Objectives
• Explain the benefits of Data Guard and why we
might use it
• Describe the basic components of Oracle Data
Guard
• Understand the difference between Physical and
Logical Standby databases
• Gain detailed insight into Logical Standby
databases:
– Things-you-need-to-be-aware-of
– Creation
– Maintenance
– Tuning

Benefits of Oracle Data Guard
• Configure the system to meet business protection
and recovery requirements
• Continuous service through a disaster or crippling
data failure
• Complete data protection against corruptions and
data loss
• Reduce overhead on primary systems by
offloading:
– adhoc queries
– reporting
– backups
• Centralized management (Data Guard Broker, Data
Guard Manager via Enterprise Manager)

Data Loss Causes…
* Protect Data 2006
Natural Disasters 3%
Software Corruption 14%
Human Error 32%
Hardware & System Error 44%
Computer Viruses 7%

What is Data Guard?
Primary
Database
Standby
Database
Database Database
Copy
OracleNet
Oracle® Data Guard Concepts and Administration 10g Release 2 (10.2)
“Ch. 1 Introduction to Oracle Data Guard “
Redo

Support/Compliment High Availability…
System
Failure
Data Failure
and Disaster
Human
Error
Failover
Failover
Standby Lag/Failover
System
Maintenance
Data
Maintenance
Switchover
Concurrent Update of Standby
Unplanned
Downtime
Planned
Downtime
Oracle
Upgrade
Backout Support (Failover)

Standby Databases
There are two types of standby databases:
1. Physical standby database
2. Logical standby database

Data Guard Services
There are three types of services provided
between the Primary and Standby databases:
1. Redo Transport: (2 types: Archival or Real-Time)
• Controls the transfer of redo data from the primary
database to the standby database.
1. Log Apply: (2 types: Redo Apply or SQL Apply)
• Applies redo data on the standby database to maintain
synchronization with the primary database.
1. Role Transitions: (2 types: Switchover or Failover)
• Change the role of a database:
SWITCHOVER: standby to primary + primary to standby
FAILOVER: standby to primary

Data Protection Modes
There are three types of Data Protection
Modes:
1. Maximum Protection
2. Maximum Availability (hybrid)
3. Maximum Performance
REMEMBER: 2323... There will be a test sooner or later…

2323 Test…
2, Types of standby databases:
– Physical and Logical
3, Types of services:
– Redo Transport
– Log Apply
– Role Transitions
2, Types of features for each service:
– Redo Transport (Archival, Real-Time)
– Log Apply (Redo Apply, SQL Apply)
– Role Transitions (Switchover, Failover)
3, Types of Protection Modes
– Maximum Protection
– Maximum Availability
– Maximum Performance

Physical Standby Database
Physical standby database:
• Identical to the primary database on a block-for-
block, byte-for-byte, bit-for-bit basis
• Redo Transport : Archival or Real-Time
• Log Apply : Redo Apply only
• Role transition : Switchover or Failover
• Maintained in a managed recovery mode (MOUNT)
• Can be opened as READ ONLY
• Can be opened as READ/WRITE
* Must use FLASHBACK DATABASE to return to time
prior to READ/WRITE in order to resume managed
recovery mode OR restore from backup made prior to
activation.

Logical Standby Database
Logical standby database:
• NOT physically identical to primary but instead
data identical, or data subset.
• Redo Transport : Archival or Real-Time
• Log Apply : SQL Apply only
• Role transition : Switchover or Failover (atypical)
• Maintained in an non-recovery mode (OPEN)
• Replicated primary data is READ ONLY
• Non-Primary data is READ WRITE
• Contains some, or all, of the primary schema
definition
• Some data types, storage types, PL/SQL supplied
packages, structures, and DDL are not supported

Data Guard Services
Redo Transport
Redo transport services perform the following
tasks:
• Transmits redo data from the primary to one
or more standbys (9 max*) using ARCH or
LGWR (LNSn)
• Enforces the database protection mode
• Automatically detects missing or corrupted
archived redo log files on the standby and
retrieves replacement archived redo log files
from the primary, or another standby database
i.e.: “GAP” RESOLUTION
• Archival or Real-Time

Data Guard Services
No Standby – No REDO Transport
Primary
Database
Transactions
LGWR
Online
Redo Log Files
ARC0
Archived
Redo Log Files

Data Guard Services
Redo Transport (Archival)
Primary
Database
Transactions
LGWR
Online
Redo Log Files
ARC0
Archived
Redo Log Files
Physical
Standby
Database
ARC0
Archived
Redo Log Files
MSRP
ARC1
RFSArchival
Transport
Redo
Apply

Data Guard Services
Redo Transport (Real-Time)
Primary
Database
Transactions
LGWR
Online
Redo Log Files
ARC0
Archived
Redo Log Files
Logical
Standby
Database
LGWR
Standby
Redo Log Files
(Required)
ARC0
Archived
Redo Log Files
LSPLSN0 RFS
SQL
ApplyReal-Time
Transport

Data Guard Services
Redo Transport Configuration
Redo transport is configured via parameters:
LOG_ARCHIVE_DEST_n (n = { 1..10 })
• One destination must be LOCAL and must be MANDATORY.
This destination, usually n = 1, is always archived first when
using ARCH for redo transport
• Destination n = 10 is the default FLASHBACK RECOVERY
area.
LOG_ARCHIVE_DEST_STATE_n
• Allows one to ENABLE, DEFER, or RESET a specific
destination
STANDBY_ARCHIVE_DEST (standby only)
• If no LOG_ARCHIVE_DEST_n locations specified then
provides default location for archived redo logs

Data Guard Services
Redo Transport Configuration
LOG_ARCHIVE_DEST_[1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10] =
{ null_string | { LOCATION=path_name | SERVICE=service_name }
[ { MANDATORY | OPTIONAL } ]
[ REOPEN[=seconds] ]
[ DELAY[=minutes] ]
[ NOREGISTER ]
[ TEMPLATE=template ]
[ ALTERNATE=LOG_ARCHIVE_DEST_n ]
[ DEPENDENCY=LOG_ARCHIVE_DEST_n ]
[ MAX_FAILURE=count ]
[ ARCH | LGWR ]
[ SYNC | ASYNC ]
[ AFFIRM | NOAFFIRM ]
[ NET_TIMEOUT=seconds ]
[ VALID_FOR=(redo_log_type,database_role) ]
[ DB_UNIQUE_NAME ]
[ VERIFY ] } Parameter Defs

Data Guard Services
Log Apply (Redo Apply)
For physical standby databases, Data Guard uses Redo Apply
technology, which applies redo data on the standby database
using standard recovery techniques of an Oracle database.
I.e. Block-for-block, byte-for-byte, bit-for-bit identical to primary.

Data Guard Services
Log Apply (SQL Apply)
For logical standby databases, Data Guard uses SQL Apply
technology, which transforms the received redo data into SQL
statements and then executes the generated SQL statements on
the logical standby database.
I.e. Use Log Mining to extract the redo, transform the redo into SQL
statements, then execute the SQL statements against the logical
standby.

SQL Apply EnginePrimary
Redo
Reader Preparer
LCR
LCR
LCR
LCR
Builder
AnalyzerCoordinator
Standby
Database
Applier
Redo
Records
Log
Mining
LCRs
Shared
Pool Logical Change
Records not Grouped
into Transactions
Apply
Processing Transactions
To be Applied
Transactions
Sorted in
Dependency Order
Transaction
Groups

SQL Apply Engine Steps
1. Primary ARCH or LGWR (LNS0) sends redo to standby RFS
2. READER mines redo (LogMiner), then sends redo to
PREPARER
3. PREPARER transforms redo into Logical Change Records
(LCRs), then stores LCRs in the LCR CACHE of the
SHARED_POOL
4. BUILDER retrieves LCRs, groups them into Transaction
Groups, then sends Transaction Groups to ANALYZER
5. ANALYZER sorts Transactions (by SCN), then sends sorted
Transaction Groups to COORDINATOR
6. COORDINATOR assigns sorted Transaction Groups to one or
more APPLIERS
7. APPLIERS execute transactions against Logical Standby

SQL Apply
Considerations
• SHARED_POOL_SIZE will need to increase to
accommodate the Logical Change Records (LCRs)
• PREPARER and/or APPLIER processes may be over-
worked (… add more)
• Transaction sizes (Oracle determines...)
– Small : Applies LCRs once COMMIT is read
– Large : Breaks transaction into transaction chunks and
applies immediately, before COMMIT is read.
WHY?
• Pageouts : Not enough memory in LCR Cache of the
SHARED POOL
• Restarts : Can require the SQL Apply process to
“re-mine” the redo for any transactions not
committed and time of standby shutdown.
WHY?

SQL Apply
Considerations
Primary DML Statements:
• Batch updates are performed one row at a time
• Direct path inserts are performed in a conventional
manner
• Parallel DML is not executed in parallel
Primary DDL Statements:
• Parallel DDL is not executed in parallel
• CREATE TABLE AS SELECT is performed as:
– CREATE TABLE …
– INSERT, INSERT, INSERT, etc…
What does this imply?

Role Transitions
Switchover and Failover
• Not automatically invoked (but can be…)
• Switchover
– Planned role reversal
– Used for OS or hardware maintenance
• Failover
– Unplanned role reversal
– Use in an emergency
– Minimal or zero data loss depending on choice of
data protection mode

Maximum Protection
• Ensures that no data loss will occur if the primary
database fails.
• Redo needed to recover each transaction must be
written to both the local online redo log and to the
standby redo log on at least one standby database
before the transaction commits.
• If a fault prevents the primary database from
writing its redo stream to the standby redo log of
at least one transactionally-consistent standby
database, the primary database shuts down.

Maximum Availability
• Highest level of data protection possible without
compromising availability of the primary database.
• Transactions will not commit until the redo needed
to recover them is written to the local online redo
log and to the standby redo log of at least one
transactionally-consistent standby database.
• If a fault prevents the writing of the redo stream to
a remote standby redo log, the protection mode
downgrades to maximum performance, thus
preventing the shutdown of the primary database.
• Once fault is corrected, and all gaps in redo log
files are resolved, the mode upgrades back to
maximum availability.
• No data loss is guaranteed unless a second fault
occurs prior to the correction of the first fault.

Maximum Performance
• Default. Provides highest level of data protection
possible without affecting the performance of the
primary database.
• Transactions may commit as soon as the redo
data needed to recover them transaction is written
to the primary’s online redo log.
• Redo data stream written asynchronously to at
least one standby database.
• If sufficient bandwidth exists, provides a level of
data protection that approaches that of maximum
availability mode with minimal impact on primary
database performance.

Setting the Protection Mode
To set up redo transport services and specify a level of data
protection for the Data Guard configuration, perform the following
steps.
Step 1: Configure the LOG_ARCHIVE_DEST_n parameters on the
primary database.
Maximum
Protection
Maximum
Availability
Maximum
Performance
Redo archival process LGWR LGWR LGWR or ARCH
Network Transmission
Mode
SYNC SYNC SYNC or ASYNC (LGWR)
SYNC (ARCH)
Disk Write Option AFFIRM AFFIRM AFFIRM or NOAFFIRM
Standby Redo Log
Required?
Yes Yes No but recommended

Setting the Protection Mode
Step 1: Bounce the primary database:
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
* If RAC, shutdown all instances, restart/mount one instance.
Step 2: Set the mode:
SQL> ALTER DATABASE SET STANDBY DATABASE TO PROTECTION MODE;
Step 3: Open the Primary Database:
SQL> ALTER DATABASE OPEN;
Step 4: Confirm LOG_ARCHIVE_DEST_n parameter(s) on Standby
Database:
SQL> SHOW PARAMETER log_archive_dest_
Step 5: Confirm configuration:
SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;

Briefs…

Cascaded Destinations
A primary database can directly support up to nine
standby databases in any combination of physical
and/or logical configurations.
A standby database can directly support up to nine
standby databases in any combination of physical
and/or logical configurations.
Indirectly, there is no technical limit.

Standbys from Standbys from Standbys….
Primary
Physical
Standby
Logical
Standby
Physical
Standby
Logical
Standby
Logical
Standby

Data Guard Broker
CLI Management Client
Primary
Database
Data
Guard
Broker
Data
Guard
Broker
Standby
Database

Data Guard Manager
CLI Management Client
Data Guard Manager
(GUI)
Repository
Primary
Database
Data
Guard
Broker
Oracle
Management
Server
Data
Guard
Broker
Intelligent
Agent
Standby
Database
Intelligent
Agent

Oracle Data Guard and Real
Application Clusters
Oracle Data Guard and Real Application Clusters are
complementary and can be used together
• Real Application Clusters provides high
availability
• Oracle Data Guard provides disaster protection
and prevents data loss
• RAC to Data Guard can be All:1 or All:M
• All RAC instances must stream their redo to the
standby database, The standby database will
apply the redo in proper order based on SCN.

Logical Standby

Logical Standby
Benefits
• Provides disaster recovery, high availability, and
data protection
• Can be altered to have a different structure from
the Primary
• Is maintained while in an OPEN state
• Allows for offloading of reports and adhoc queries
• Easy to implement

Considerations
• Data types
• Storage types
• PL/SQL Supplied Packages
• Unsupported Tables, Sequences, and Views
• DDL Support
• SKIP Handlers
• Tuning

Data Type Considerations
Not all Data Types are supported:
• BFILE
• Collections (including VARRAYS and nested
tables)
• Encrypted columns
• Multimedia data types (including Spatial, Image,
and Context)
• ROWID, UROWID
• User-defined types
• XML Type

Storage Type Considerations
Not all Storage Types are supported:
• Segment compression

PL/SQL Supplied Packages Considerations
Typically, any supplied Oracle PL/SQL that modifies system
metadata is not supported
e.g.:
– DBMS_JAVA, DBMS_REGISTRY, DBMS_ALERT
– DBMS_SPACE_ADMIN, DBMS_REFRESH
– DBMS_REDEFINITION, DBMS_SCHEDULER,DBMS_AQ.
DBMS_JOB is supported as follows
• Job execution is suspended on the logical standby
• Jobs cannot be scheduled on the logical standby
database
• Jobs submitted on the primary are replicated in the
logical standby
• In the event of a switchover or failover, jobs scheduled
on the primary database will begin running on the new
primary

Unsupported Tables, Sequences, and Views
Identify unsupported structures:
SQL> SELECT DISTINCT OWNER,TABLE_NAME
2> FROM DBA_LOGSTDBY_UNSUPPORTED
3> ORDER BY OWNER,TABLE_NAME;
OWNER TABLE_NAME
----------- --------------------------
HR COUNTRIES
OE ORDERS
OE CUSTOMERS
OE WAREHOUSES

Identify unsupported columns:
SQL> SELECT COLUMN_NAME,DATA_TYPE
2> FROM DBA_LOGSTDBY_UNSUPPORTED
2> WHERE OWNER='OE' AND TABLE_NAME = 'CUSTOMERS';
COLUMN_NAME DATA_TYPE
------------------------------- -------------------
CUST_ADDRESS CUST_ADDRESS_TYP
PHONE_NUMBERS PHONE_LIST_TYP
CUST_GEO_LOCATION SDO_GEOMETRY

So what we do when we have structures that are
unsupported?
• Redefine the structure
• Leverage other means to move the data across
– Export/Import
– DataPump
– Database links
– SQL*Loader
– Program
• Don’t move the data…

SQL Apply : Skipped SQL Statements
Not all SQL Statements are supported by SQL Apply:
• ALTER DATABASE
• ALTER SESSION, ALTER SYSTEM
• CREATE CONTROL FILE
• CREATE DATABASE
• CREATE/DROP DATABASE LINK
• CREATE PFILE FROM SPFILE
• CREATE/DROP/ALTER MATERIALIZED VIEW
• CREATE/DROP/ALTER MATERIALIZED VIEW LOG
• CREATE SCHEMA AUTHORIZATION
• CREATE SPFILE FROM PFILE
• EXPLAIN
• LOCK TABLE
• SET CONSTRAINTS, SET ROLE, SET TRANSACTION

Handling Materialized Views
For primary MViews created before creation of logical
standby:
• ON-COMMITs are maintained as normal
• ON-DEMANDs must be manually refreshed
For primary MViews created after creation of logical
standby:
• Recreate logical standby
• Create MView manually
For standby MViews:
• Create MView manually

SKIP Handlers
• Allow programmatic control over replicated tables
• Prevent changes to a specific schema
• Prevent changes to a specific schema object
• Replace SQL Apply supported DDL statements
• Created via DBMS_LOGSTDBY.SKIP

SKIP Handlers
In my logical environment, I renamed all
filenames/folders from “wimp” to “wimr”, so my DDL
syntax must be changed to reflect such:
e.g:
PRIMARY:
SQL> create tablespace users datafile
'/db01/ORACLE/data/wimp/wimp_users_ts01.dbf‘ size 16m;
needs to become:
STANDBY:
'/db01/ORACLE/data/wimr/wimr_users_ts01.dbf‘ size 16m;

DBMS_LOGSTDBY.SKIP
DBMS_LOGSTDBY.SKIP
(stmt IN VARCHAR2,
schema_name IN VARCHAR2 DEFAULT NULL,
object_name IN VARCHAR2 DEFAULT NULL,
proc_name IN VARCHAR2 DEFAULT NULL,
use_like IN BOOLEAN DEFAULT TRUE,
esc IN CHAR1 DEFAULT NULL);
The DBMS_LOGSTDBY.SKIP is used to define rules
that will be used by SQL Apply to skip the application
of certain changes to the logical standby database
* Do NOT confuse with SQL Apply Skipped SQL statements

SKIP Handlers
Intercept and modify DDL:
1. Create your procedure to be executed by DBMS_LOGSTDBY.SKIP. Here,
SYS.HANDLE_TBS_DDL will be called by DBMS_LOGSTDBY.SKIP for every DDL
statement that contains the command ‘TABLESPACE’
SQL> CREATE OR REPLACE PROCEDURE SYS.HANDLE_TBS_DDL (
OLD_STMT IN VARCHAR2,
STMT_TYP IN VARCHAR2,
SCHEMA IN VARCHAR2,
NAME IN VARCHAR2,
XIDUSN IN NUMBER,
XIDSLT IN NUMBER,
XIDSQN IN NUMBER,
ACTION OUT NUMBER,
NEW_STMT OUT VARCHAR2
) AS
BEGIN
NEW_STMT = REPLACE(OLD_STMT, 'wimp', ‘wimr');
ACTION := DBMS_LOGSTDBY.SKIP_ACTION_REPLACE;
EXCEPTION
WHEN OTHERS THEN
ACTION := DBMS_LOGSTDBY.SKIP_ACTION_ERROR;
NEW_STMT := NULL;
END HANDLE_TBS_DDL;

SKIP Handlers
Intercept and modify DDL:
2. Stop SQL Apply:
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
3. Register the skip procedure with SQL Apply:
SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'TABLESPACE', -
proc_name => 'sys.handle_tbs_ddl');
4. Start SQL Apply:
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

SKIP Handlers
All DDL using keyword TABLESPACE will now replace all
occurrences of 'wimp' with 'wimr‘ before it executes on
the logical:
e.g.:
PRIMARY:
'/db01/ORACLE/data/wimp/wimp_users_ts01.dbf‘ size 16m;
becomes
STANDBY:
'/db01/ORACLE/data/wimr/wimr_users_ts01.dbf‘ size 16m;
This is necessary because the DR server supports
both a physical and logical standby database,
maintained from a single primary, and the physical will
retains ‘wimp’ folder/file names, whereas the logical
will use ‘wimr’.

SKIP Handlers
Prevent a change to a specific schema object:
a. Stop SQL Apply:
b. Register the SKIP rules:
SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'DML', -
schema_name => 'HR', object_name => 'EMPLOYEES', -
proc_name => null);
SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'SCHEMA_DDL', -
schema_name => 'HR', object_name => 'EMPLOYEES', -
proc_name => null);
c. Start SQL Apply:
If I replace 'EMPLOYEES‘ with '*‘, what does this
imply?

Creating
• Identify/resolve all unsupported operations
• Ensure primary table rows can be uniquely
identified
• Determine need for SKIP Handlers
• Create a physical standby database
• Stop Redo Apply on the physical standby
• Inject primary metadata into the redo stream
• Initiate conversion of physical standby to logical
standby
• Confirm

Creating
• Place the primary metadata into the redo stream
SQL> exec DBMS_LOGSTDBY.BUILD
• Convert physical standby to logical standby
• Create a new passwordfile for the logical standby
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY wimr;
C: orapwd file=%ORACLE_HOME%databasepwdwimr.ora password=xxxxx
• Open, verify, and use the logical standby
SQL> SHUTDOWN IMMEDITE
SQL> STARTUP MOUNT
SQL> ALTER DATABASE OPEN RESETLOGS;

Tuning
• Primary Key RELY Constraint
• Cost-Based Optimizer
• APPLIER / PREPARER Processes
• LCR Cache
• Transaction Apply Order

Tuning a Logical Standby Database
Primary Key RELY Constraint
For primary tables with no primary key nor unique
index, SQL Apply will perform a full-table scan for
every update and delete. Adding a Primary Key RELY
constraint and index will eliminate the full-table scan:
• Table must have unique rows
SQL> ALTER TABLE HR.TEST_EMPLOYEES
2> ADD PRIMARY KEY (EMPNO) RELY DISABLE;
SQL> CREATE UNIQUE INDEX UI_TEST_EMP
2> ON HR.TEST_EMPLOYEES (EMPNO);

Cost-Based Optimizer
Even though the Logical standby is data-equivalent to
the primary, the DML / DDL operations are executed
through different execution paths.
It is critical that optimizer statistics are collected on an
as-needed basis the same as one would for a primary
database.

APPLIER Processes
1. Determine if all APPLIER processes are busy:
SQL> SELECT COUNT(*) AS IDLE_APPLIER
FROM V$LOGSTDBY_PROCESS
WHERE TYPE = 'APPLIER' and status_code = 16166;
IDLE_APPLIER
-------------------------
0

APPLIER Processes
2. Ensure there is enough work available:
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME LIKE 'TRANSACTIONS%';
NAME VALUE
--------------------- -------
transactions ready 27896
transactions applied 25671
If transactions ready – transactions applied
> 2 * APPLIER Processes
Then
add more APPLIER processes

APPLIER Processes
3. Add APPLIER Processes:
a. Stop SQL Apply:
b. Set the number of APPLY_SERVERS to 20:
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS', 20);
c. Start SQL Apply:

PREPARER Processes
1. It is RARE to have to increase PREPARERs
2. Confirm all PREPARER processes are busy:
SQL> SELECT COUNT(*) AS IDLE_PREPARER
WHERE TYPE = 'PREPARER' and status_code = 16166;
IDLE_PREPARER
-------------
0

PREPARER Processes
3. Ensure the slowdown is not due to a lack of
APPLIER processes:
WHERE NAME LIKE 'TRANSACTIONS%';
NAME VALUE
--------------------- -------
transactions ready 27896
transactions applied 27892
SQL> SELECT COUNT(*) AS APPLIER_COUNT
FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER';
APPLIER_COUNT
-------------
20
Run these commands several times to be certain the
results are consistent.

PREPARER Processes
4. Be certain there are idle APPLIER processes:
SQL> SELECT COUNT(*) AS IDLE_APPLIER
WHERE TYPE = 'APPLIER' and status_code = 16166;
IDLE_APPLIER
-------------------------
1

APPLIER Processes
5. Add PREPARER Processes:
a. Stop SQL Apply:
b. Set the number of PREPARE_SERVERS to 4:
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS',4);
c. Start SQL Apply:

LCR Cache
Pageout activity should not consume more than 5% of
total uptime.

LCR Cache
1. Query pageout activity every 5 minutes during the
busiest hour of the day:
WHERE NAME LIKE '%PAGE%' OR
NAME LIKE '%UPTIME%' OR NAME LIKE '%idle%';
NAME VALUE
-------------------------- ---------------
coordinator uptime in secs 894856 (C)
bytes paged out 20000
seconds spent in pageout 2 (P)
system idle time in secs 1000 (I)
NAME VALUE
-------------------------- ---------------
coordinator uptime in secs 895156 (C)
bytes paged out 20000
seconds spent in pageout 100 (P)
system idle time in secs 1000 (I)
RUN 1
RUN 2

LCR Cache
Change in coordinator uptime (C)= (895156 – 894856) = 300 secs
Amount of additional idle time (I)= (1000 – 1000) = 0
Change in time spent in pageout (P) = (100 – 2) = 98 secs
Pageout time in comparison to uptime = P/(C-I) = 98/300 ~ 32.67%
2. Subtract latest RUN from previous RUN:
3. Increase LCR Cache:
a. Stop SQL Apply:
b. Increase LCR Cache (kbytes):
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 1024);
c. Start SQL Apply:

Transaction Apply Order
On occasion, there may arise a need to apply
transactions in an order different than that in which
they were committed, such as after a period of
prolonged outage.
Doing so will:
• Eliminate the need to order non-dependent
transactions
• Speed up the apply process
• CAUTION: reporting can/will be different from
primary during this time

a. Stop SQL Apply:
b. Allow transactions to be applied out-of-order:
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET -
('PRESERVE_COMMIT_ORDER', 'FALSE');
c. Start SQL Apply:

a. Stop SQL Apply:
b. Reset transaction apply order:
SQL> EXECUTE DBMS_LOGSTDBY.APPLY_UNSET -
('PRESERVE_COMMIT_ORDER');
c. Start SQL Apply:
Once the standby is caught up with the primary,
enforce commit order.

Summary
In this lesson you should have learned:
• Benefits of Data Guard and why we might use it
• Basic components of Oracle Data Guard
• Difference between Physical and Logical Standby
databases
• Detailed insight into Logical Standby databases:
– Things-you-need-to-be-aware-of
– Creation
– Maintenance
– Tuning

Data guard logical_r3.1

Recommended

More Related Content

What's hot (20)

Similar to Data guard logical_r3.1 (20)

Recently uploaded (20)

Data guard logical_r3.1