Académique Documents
Professionnel Documents
Culture Documents
The following article describes the new features and enhancements that were added in Oracle Data
Guard 12c Release 1.
a. Introduction:
Prior to Oracle 12c, cascading standby database is a standby database that receives its redo logs from
another standby database, not from the original primary database. The standby database, which serves
the cascading standby database, is created from the primary database using RMAN (active) duplication
method or restored from a backup of the primary.
The following image shows a primary database sending redo data over Oracle network to a physical
standby database and a logical standby database. The physical standby database retransmits the redo
data to another physical standby database (Cascading standby 1).The logical standby database
generates the redo data into SQL statements, which are then transmitted to another physical standby
database (Cascading standby 2).
Page 1
The Physical and logical serving the cascading databases are databases with standby control files, server
parameter files, data files etc
Oracle database 12cR1 comes with a new standby role called Far Sync Standby. The new Standby
works as a coordinator between the primary and all its standby databases. Far Sync Standby is a
cascading Standby Database which acts as an archive logs repository.
Far sync standby can only has a server parameter file, standby control file, standby redo logs and archive
logs received from primary database. Far sync standby cannot be opened for access, cannot run redo
apply, cannot function in the primary role or be converted to any type of standby database and doesnt
have any data file.
Far sync standby can have very limited server resources as it is acting only for archive logs repository for
other standby databases.
As of Oracle Database 12c Release 1, creating a far sync instance close to the primary has the benefit
having a local synchronous redo which guarantee Zero Data loss when standby databases are far away.
Performance gain for redo transport compression and for servicing asynchronous multiple destinations.
Switchover & Failover to standby is transparent.
Far sync standby can operate in maximum protection, maximum availability or maximum performance
mode.
Wissem El Khlifi www.oracle-class.com 12 July 2013
Page 2
The following image shows a primary database sending redo data over Oracle network to a far sync
standby. The far sync standby retransmits the redo data to the other physical standby databases.
Prerequisites
-
Page 3
Environment Information
In the following example, we have one primary database, one far sync standby and two physical standby
databases.
ROLE
Primary
Far Sync Standby
Standby database
Standby database
DB_UNIQUE_NAME
livedb
livefs
livestby1
livestby2
Page 4
)
)
livefs =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = livefs.domain.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = livefs)
)
)
log_archive_dest_1 = location=USE_DB_RECOVERY_FILE_DEST
log_archive_dest_2 ='SERVICE=livefs SYNC COMPRESSION=ENABLE
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=livefs' (Note we enable
compression)
LOG_ARCHIVE_DEST_STATE_2=ENABLE
log_archive_config= dg_config=(livedb,livefs,livestby1,livestby2)
log_archive_max_processes = 8
Edit the pfile created in the previous step and change the following parameters
*.control_files=/home/oracle/wissem/far_stby_ctl.ctl
*.db_unique_name=livefs
log_archive_config= dg_config=(livedb,livefs,livestby1,livestby2)
*.fal_server=livedb
log_archive_dest_1 = location=USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
Page 5
DB_UNIQUE_NAME=livefs
log_archive_dest_2= SERVICE=livestby1 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
DB_UNIQUE_NAME=livestby1'
log_archive_dest_3= SERVICE=livestby2 VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
DB_UNIQUE_NAME=livestby2'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE
log_archive_max_processes = 8
Create TNS-Alias to resolve primary database and the two physical standby databases on the far sync
standby. Copy the same information on the livestby1 and livestby2 databases.
livedb =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = livedb.domain.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = livedb)
)
)
livefs =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = livefs.domain.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = livefs)
)
Page 6
)
Livestby1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = Livestby1.domain.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = Livestby1)
)
)
Livestby2=
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = Livestby2.domain.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = Livestby2)
)
)
Query v$database:
Wissem El Khlifi www.oracle-class.com 12 July 2013
Page 7
Check the archive logs are received on the far sync standby, you can query the v$archive_dest_Status
Copy the pfile of primary database to the physical standby and change the following values:
For Livestby1 physical standby database:
*.db_unique_name=livestby1
log_archive_config= dg_config=(livedb,livefs,livestby1,livestby2)
*.fal_server=livefs <= the far sync standby name.
log_archive_dest_1 = location=USE_DB_RECOVERY_FILE_DEST
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=livestby1
log_archive_dest_2= SERVICE=livefs VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
DB_UNIQUE_NAME=livefs'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
log_archive_max_processes = 8
*.db_unique_name=livestby2
log_archive_config= dg_config=(livedb,livefs,livestby1,livestby2)
Page 8
The Steps to create the physical Standby database, we can directly start the RMAN Duplicate from the
Standby Site. This method will leave the physical standby in mount mode.
$ export ORACLE_SID = livestby1
SQL> startup nomount pfile =pfile_location
RMAN> connect target sys/<Password>@livedb
RMAN> connect auxiliary /
RMAN> duplicate target database for standby from active database nofilenamecheck;
Page 9
order by timestamp;
c. Questions
Now, I leave the following questions:
1- What impacts on the data guard environment if the far sync standby is down?
2- Is it possible to make more servers running as far sync standby?
3- Using far sync standby option requires an extra cost?
b. Prerequisites
Page 10
Environment Information
In the following example, we have one primary database, one far sync standby and two physical standby
databases.
ROLE
Primary
First Cascading Standby (can be Far Sync Standby)
Terminal Standby database
Terminal Standby database
DB_UNIQUE_NAME
livedb
livefs
livestby1
livestby2
In the first setup, The Log Transport Method should be SYNC and Standby redo logs must be
configured on the cascading Standby Database, like shown in the previous chapter.
DG_CONFIG of log_archive_config parameter must have all the unique database names of
involved databases (Primary, first cascading database, terminal cascading databases).
log_archive_config= dg_config=(livedb,livefs,livestby1,livestby2)
log_archive_dest_n on the cascading Standby Database must have the attribute:
valid_for=(STANDBY_LOGFILES,STANDBY_ROLE)
FAL_SERVER on the first cascading Standby Database should be set to the Primary or any other
Standby Database served by the Primary Database directly.
FAL_SERVER on the terminal Standby Database should be set to the cascading Standby Database
or the Primary Database.
Specify the Log Transport Method ASYNC which enables Real-Time Cascading. SYNC log
transport method enables the Non Real time cascading.
Page 11
synchronized with the old primary by applying the changes that were generated at the old primary
database during the upgrade process. Rolling upgrade guarantee a high availability of the environment
during an upgrade process.
In the following example we will use DBMS_ROLLING to perform rolling upgrade.
Environment Information
In the following example, we have one primary database and two physical standby databases.
ROLE
Primary
Standby database
Standby database
DB_UNIQUE_NAME
livedb
livestby1
livestby2
GROUP
TG
TG
LG
Upgrade the LG standby and restart it in open write mode using the higher Oracle Database
software version.
Switchover to the LG:
SQL> EXECUTE DBMS_ROLLING.SWITCHOVER;
Mount the former primary livedb using the higher Oracle Database version.
Mount the physical standbys of the former primary livestby1 using the higher Oracle Database
version.
Finish the rolling upgrade:
Page 12
4- SYSDG Privilege
User granted the SYSDG privilege can execute all data guard Operations in SQL*Plus or using all the Data
Guard Broker commands via DGMGRL.
The following is a list of commands a user granted the SYSDG privilege can run
STARTUP
SHUTDOWN
ALTER DATABASE
ALTER SESSION
ALTER SYSTEM
CREATE RESTORE POINT (including GUARANTEED Restore Points)
CREATE SESSION
DROP RESTORE POINT (including GUARANTEED Restore Points)
FLASHBACK DATABASE
SELECT ANY DICTIONARY (DBA_ Views)
SELECT
o X$ Tables
o V$ and GV$ Views
o APPQOSSYS.WLM_CLASSIFIER_PLAN
DELETE
o APPQOSSYS.WLM_CLASSIFIER_PLAN
EXECUTE
o SYS.DBMS_DRS
Page 13
7- References:
http://docs.oracle.com/cd/E16655_01/server.121/e17640/create_fs.htm#CJAGJBBG
http://docs.oracle.com/cd/E16655_01/server.121/e17601/overview.htm#HAOVW111
http://docs.oracle.com/cd/E16655_01/server.121/e17640/dbms_rolling_upgrades.htm
http://allthingsoracle.com/data-guard-physical-standby-database-best-practices-part-i/
http://allthingsoracle.com/data-guard-physical-standby-database-best-practices-part-ii/
Page 14