Nabil Nawaz Oracle Oracle 12c Data Guard Deep Dive Presentation

CSC Proprietary and Confidential
Oracle Dataguard Deep Dive
Nabil Nawaz
Dallas OUG Sept 22, 2016

CSC Proprietary and Confidential 2December 4, 2016
Nabil Nawaz
o Oracle Certified Professional – OCP and Exadata Certified Implementation Specialist
o Oracle Architect/DBA for 19 years, working with Oracle since version 7
o Lead Engineered Systems Solutions Architect at Computer Science Corporation
o Contributing Author for recent Book Oracle Exadata Expert’s Handbook
o Experience covers Performance tuning, Architecture, and Implementation of High Available systems with
Virtualization, Exadata, Supercluster, RAC, Dataguard and on both OLTP and Data warehouse
environments.
o Please follow me on my Blog http://nnawaz.blogspot.com/ and on Twitter! @Nabil_Nawaz

Oracle Exadata Expert’s Handbook

What is Dataguard?
• Feature was named Standby database back in Oracle 7.3
• Renamed as Oracle Dataguard in Oracle version 9i
• Dataguard has been improved in every release to current release in 12c
• Oracle Data Guard is a solution for the following:
– Database High Availability (HA)
– Disaster Recovery (DR) for enterprise data.
– Data Protection
– Real-time Data Replication

Dataguard Benefits
• No extra cost Included with Oracle Database Enterprise edition license
• Can have up to 30 standby databases from single primary database.
• Offload Database backups
• Offload Reporting point-in-time or real-time with Active Dataguard extra licensing cost
• Database cloning from standby database
• Near real time copy of database in sync

Dataguard Concepts
•Primary Database
•Standby database
–Physical Standby database
–Logical Standby database

Dataguard Configuration

Dataguard Protection modes
• Maximum Performance –
– Default Mode
– Provides the highest level of data protection without affecting the performance of primary
– Once transactions commit ,redo sent asynchronously to standby
– Minimal impact on primary database performance.
• Maximum Availability –
– Highest data protection without compromising availability of primary
– If the primary does not receive acknowledgement from at least one synchronized standby, then it operates
as if it were in maximum performance mode to preserve primary database availability until it is again able
to write its redo stream to a synchronized standby database.

Dataguard Protection modes
• Maximum Protection –
– Shuts the primary database down if it cannot contact the standby
– Prioritizes data protection over primary database availability
– Oracle recommends that a minimum of two standby databases be used to protect a primary database that
runs in maximum protection mode to prevent a single standby database failure from causing the primary
database to shut down.

Required Redo Transmission attributes for Data Protection Modes

Dataguard Real-Time Redo Apply
• With the real-time apply feature redo can be applied on the standby as it is received.
• Results in the following:
– Faster synchronization on Standby
– Faster Switchover
– Faster Failover
– Enables real-time reporting
• Requires standby redo logs on standby also required on Primary in case of switchover/failover.
• Enable Real-time apply with command:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;
• As of Oracle Database 12c Release 1 (12.1), the USING CURRENT LOGFILE clause is deprecated
and no longer necessary to start real-time apply.

Redo Apply with Real-time Apply

Cases Where Redo not written to Standby Redo Logs
• Redo received by a standby database is written directly to an archived redo log file.
–if a standby redo log group is not available
–if the redo was sent to resolve a redo gap.
• When this occurs, redo is written to the location specified by the LOCATION attribute
of one LOG_ARCHIVE_DEST_n parameter and then applied from the archive redo
logs.

Dataguard Different Platforms
• In general the platform and database software & patch level for both and the primary and standby
locations should be identical
• Oracle does support Heterogeneous platform Dataguard platform configurations Documented in
Oracle Support note:
Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard
Configuration (Doc ID 413484.1)
• Common heterogeneous platforms for Dataguard
– HP-UX (64-bit) Big
– AIX-Based Systems (64-bit) Big
– Microsoft Windows x86 64-bit Little
– Linux x86 64-bit Little

Cascading Standby
• A cascaded standby database receives primary database redo indirectly from a standby database
rather than directly from a primary database.
• Only physical standby databases can cascade redo!
Redo Redo

Switchover
• Allows the primary database to switch roles with one of its standby databases.
– There is no data loss during a switchover.
– After a switchover, each database continues to participate in the Oracle Data Guard configuration with its
new role.
• Use case to reduce primary database downtime during planned outages, such as OS or HW
upgrades, or rolling upgrades of the Oracle database software and patch sets
• A switchover takes place in two phases.
– In the first phase, the existing primary database undergoes a transition to a standby role.
– In the second phase, a standby database undergoes a transition to the primary role.

Switchover Steps
• Step 1 Verify that the target standby database is ready for switchover, issue on primary database
Boston.
SQL> ALTER DATABASE SWITCHOVER TO CHICAGO VERIFY;
• Step 2 Initiate the switchover on the primary database Boston.
SQL> ALTER DATABASE SWITCHOVER TO CHICAGO;
• Step 3 Open the new primary database Chicago.
SQL> ALTER DATABASE OPEN;
• Step 4 Mount the new physical standby database Boston.
SQL> STARTUP MOUNT;
• Step 5 Start Redo Apply on the new physical standby database Boston.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Failover
• Changes a standby database to a primary role in response to a primary database
failure.
• If the primary database was not operating in either maximum protection mode or
maximum availability mode before the failure, some data loss may occur.

Failover Steps
• Step 1 Flush any unsent redo from the primary database to the target Standby database.
SQL> ALTER SYSTEM FLUSH REDO TO DB_UNIQUE_NAME;
• Step 2 Verify that the standby database has the most recently archived redo log file for each primary
database redo thread.
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) - > OVER (PARTITION BY thread#) AS LAST from
V$ARCHIVED_LOG;
• Step 3 Identify and resolve any archived redo log gaps. Repeat until all gaps resolved.
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
• Step 4 Stop Redo Apply on Standby.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
• Step 5 Failover physical standby database to the Primary role.
SQL> ALTER DATABASE FAILOVER TO DB_UNIQUE_NAME;
• Step 6 If an error occurs, try to resolve the cause of the error and then reissue the statement.

Failover Steps(Continued)
• Step 7 Backup the new primary database
• Step 8 Restart Redo Apply, if necessary on any additional Standbys.
• Step 9 Optional – Rebuild Standby and perform switchover if both Primary and Standby are in
sync.
• Optional can also activate Standby into Primary(Data-loss could occur)
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;

Dataguard Broker
• The Broker is a management framework for Dataguard
• Create and enable Oracle Data Guard configurations
• Manage an entire Oracle Data Guard configuration from any target in the configuration
• Monitor Oracle Data Guard configurations that contain Oracle RAC primary or standby databases
• Simple switchovers and failovers
– Single key click in Oracle Enterprise Manager Cloud Control
– Single command in the DGMGRL command-line interface.
• Enable Oracle Data Guard fast-start failover to fail over automatically when the primary database
becomes unavailable.

Dataguard Broker Create Configuration - Primary
• Step 1 Invoke DGMGRL from Database Oracle home
DGMGRL>
• Step 2 Connect to the primary and clear any remote redo transport destinations on the primary
database that do not have the NOREGISTER attribute
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_n=" " SQL*Plus command.
NOTE: If this is not done then you will encounter the error ORA-16698: LOG_ARCHIVE_DEST_n parameter set for object to be added
• Step 3 Create the broker configuration from the primary.
DGMGRL> CREATE CONFIGURATION 'DRSolution' AS PRIMARY DATABASE IS 'DALLAS' CONNECT IDENTIFIER IS
Dallas.oracle.com;
• Step 4 Show the current configuration.
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxPerformance
Databases: DALLAS - Primary database
Fast-Start Failover: DISABLED
Configuration Status: DISABLED

Dataguard Broker Add Standby to Configuration
• Step 5 Invoke DGMGRL from Database Oracle home
– To add a standby database to the DRSolution configuration, use the ADD DATABASE command.
– The following command defines New York as a standby database, which is the standby database associated
with the primary database called Dallas:
DGMGRL> ADD DATABASE 'NEWYORK' AS CONNECT IDENTIFIER IS NewYork.oracle.com;
• Step 6 Verify the Primary and Standby database configuration
DGMGRL> SHOW CONFIGURATION;
Configuration - DRSolution
Protection Mode: MaxPerformance
Databases:
DALLAS - Primary database
NEWYORK - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status: DISABLED
DGMGRL>

Dataguard Broker Setting Properties
• After you create the configuration with DGMGRL, you can set database properties at any time.
DGMGRL> EDIT DATABASE 'DALLAS' SET PROPERTY 'LogArchiveFormat'='log_%t_%s_%r_%d.arc';
Property "LogArchiveFormat" updated.
DGMGRL> EDIT DATABASE 'Dallas' SET PROPERTY 'StandbyArchiveLocation'='USE_DB_RECOVERY_FILE_DEST';
Property "StandbyArchiveLocation" updated.

Broker Validate,Switchover/Failover
• VALIDATE DATABASE
– Performs a comprehensive set of database checks prior to a role change.
– The checks use information available in various Oracle Data Guard views as well
DGMGRL> SWITCHOVER TO 'NEWYORK';
Performing switchover NOW, please wait...
Operation requires a connection to instance ”NEWYORK" on database ”NEWYORK"
Connecting to instance ”NEWYORK"...
Connected as SYSDBA.
New primary database ”NEWYORK" is opening...
Operation requires startup of instance ”DALLAS" on database ”DALLAS"
Starting instance ”DALLAS"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is ”NEWYORK"
DGMGRL> FAILOVER TO 'NEWYORK';
Performing failover NOW, please wait...
Failover succeeded, new primary is ”NEWYORK"

Dataguard Broker Cloud Control
• OEM Cloud Control provides a wizard that automates the complex tasks involved in
creating a broker configuration, including:
–Add Standby Database wizard to guide you through the process
–Adding an existing standby database, or a new standby database.
–Configuring the standby control file, server parameter file, and datafiles
–Creating standby redo log files

Dataguard Standby-First Patch Apply
• Purpose for applying and validating Oracle patches and patch bundles on standby database before
applying to the primary.
• Use Case example –
– Apply a database home patch first to a physical standby database.
• The standby is used to run read-only workload, or read-write workload if it is a snapshot standby, for testing and evaluation of
the patch.
• After passing evaluation, the patch is then installed on the primary system with greater assurance of the effectiveness and
stability of the database home patch.

Dataguard Standby-First Patch Apply
• The following types of patches are candidates to be Data Guard Standby-First certified should be
11.2.0.1 or later:
– Database home interim patches(One-off patch)
– Exadata bundle patches (for example, monthly and quarterly database patches for Exadata)
– Database patch set updates (PSU)
– Will be documented in the README for the patch set
• Oracle patch sets and major release upgrades do not qualify for Data Guard Standby-First Patch
Apply.
• For example, upgrades from 11.2.0.2 to 11.2.0.3 or 11.2 to 12.1 do not qualify.

Upgrading Primary with Physical Standby Database in Place
• Install the new release of the 12c Oracle Database binaries into a new Oracle home on the physical
standby database and primary database systems.
• Shut down the primary and physical standby database(s).
• Stop all listeners, agents, and other processes running in the Oracle home that are to be upgraded.
• In the new Oracle home, restart all listeners, agents, and other processes that were stopped.
• Mount and start redo apply on the physical standby database(s) on the new Oracle home (upgraded
version).
• Upgrade the primary database.
• Note that the physical standby database(s) will be upgraded when the redo generated by the primary
database as it is upgraded is applied.

Active Dataguard
• If a license for Active Data Guard option has been purchased, Redo Apply can be active while the
physical standby database is open.
• Reporting can be done on the Standby database. This capability is known as the real-time query
feature.
• The COMPATIBLE database initialization parameter must be set to 11.0 or higher to use the real-time
query feature of the Oracle Active Data Guard option.

Active Dataguard
• Enable Active Dataguard mode/Real-time Query on Standby
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE OPEN; -- Put in Read Only mode
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; -- Enable Recovery
SQL> SELECT open_mode FROM V$DATABASE;
OPEN_MODE
--------------------
READ ONLY WITH APPLY

Snapshot Standby
• A snapshot standby database is a fully updatable standby database.
• A snapshot standby database receives and archives redo, but does not apply redo data from a
primary database.
• Redo data received from the primary database is applied when a snapshot standby database is
converted back into a physical standby database, after discarding all local updates to the snapshot
standby database.
• Guaranteed Restore Points(GRP) are used to flashback the Snapshot Standby.
• Ideal for testing for Development, Test, QA systems.

Simple Snapshot Standby Creation!

Dataguard in the Oracle Cloud

Prerequisites for Hybrid Dataguard in the Oracle
Cloud

New in 12.2 In-Memory runs on Active Dataguard Standby

RAC and Dataguard
• An Oracle Data Guard configuration can consist of any combination of single-instance and RAC
databases.

RAC and Dataguard

Dataguard Configuration Considerations for RAC
• On a Standby RAC database ensure that both the Standby redo logs and Standby redo log archival
are both sent to a shared location such as ASM or a clustered filesystem.
• On a Primary RAC database Use the same LOG_ARCHIVE_DEST_n parameter on each instance to
send the redo to the Standby database.
• The thread parameters %t or %T(instance thread numbers) are mandatory for Oracle RAC to uniquely
identify the archived redo log files with the LOG_ARCHIVE_FORMAT parameter.
LOG_ARCHIVE_FORMAT = log%d_%t_%s_%r.arc

Dataguard RAC Add Services
• Add database resources in OCR
$ srvctl add database -d standby -o $ORACLE_HOME -role physical_standby -s mount -diskgroup DATA,FRA
$ srvctl add instance -d standby -i stdby1 -n stdnode1
$ srvctl add instance -d standby -i stdby2 -n stdnode2

Creating a Physical Standby Database - Prepare Primary
• Place the primary database in FORCE LOGGING mode. You can do this after database creation
using the following SQL statement:
SQL> ALTER DATABASE FORCE LOGGING;
• Ensure Archive logging is on.
• Copy the password file from the primary to standby database(s) – also rename with standby name.
• Add Standby Redo Logs (SRLs) on primary, needed for conversion to standby role.
• Add same size SRLs and one additional group per Oracle recommendation.
SQL> ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog1.rdo') SIZE 500M;

Creating a Physical Standby Database – TNS Entries
CHICAGO =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = HOST_PRIMARY)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = chicago)
)
)
BOSTON =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = HOST_STANDBY)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = boston)
)
)

Creating a Physical Standby Database – Primary Listener
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = chicago)
(ORACLE_HOME = /u01/app/oracle/product/12.1.0.2/dbhome)
(SID_NAME = chicago)
)
(SID_DESC =
(GLOBAL_DBNAME = chicago_dgmgrl)
(SID_NAME = chicago)
)
)
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = HOST_PRIMARY)(PORT = 1521))
)

Creating a Physical Standby Database – Standby Listener
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = boston)
(SID_NAME = boston)
)
(SID_DESC =
(GLOBAL_DBNAME = boston_dgmgrl)
(SID_NAME = boston)
)
)
LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = HOST_STANDBY)(PORT = 1521))
)

Creating a Physical Standby Database – Broker parameter
To enable broker automatic restart instances during the course of the switchover, a static service is
required. This can be supplied by explicitly setting the Broker Instance Property StaticConnectIdentifier.
DGMGRL> edit database chicago set property staticConnectidentifier='chicago';
DGMGRL> edit database boston set property staticConnectidentifier='boston';
If above property is not set, then make change in listener.ora
"<db_unique_name>_DGMGRL.<db_domain>" is statically registered with the listener of each instance.

Creating a Physical Standby Database - Prepare Primary
• Set the Primary Database Initialization Parameters.
DB_NAME=chicago
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/chicago/control1.ctl', '/arch2/chicago/control2.ctl’
LOG_ARCHIVE_DEST_1= 'LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2= 'SERVICE=boston ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
• Standby Role Initialization Parameters
FAL_SERVER=boston
DB_FILE_NAME_CONVERT='/boston/','/chicago/'
LOG_FILE_NAME_CONVERT='/boston/','/chicago/'
STANDBY_FILE_MANAGEMENT=AUTO

Creating a Physical Standby Database – Prepare Standby
• Create/Update the pfile for the Standby Database.
SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;
DB_NAME=chicago
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'
CONTROL_FILES='/arch1/boston/control1.ctl', '/arch2/boston/control2.ctl'
LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc
LOG_ARCHIVE_DEST_1= 'LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2= 'SERVICE=chicago ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago' REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
STANDBY_FILE_MANAGEMENT=AUTO
FAL_SERVER=chicago
db_create_file_dest=/boston
db_create_online_log_dest_1=/boston

Creating a Physical Standby Database – RMAN Duplicate
• Use RMAN Duplicate to create the Standby database from:
–Source RMAN Backup from Primary Database
–From online “Active database”

Creating a Physical Standby Database – Backup Primary
Run backup of RMAN of the whole Primary Database and Archive redo logs:
run {
ALLOCATE CHANNEL disk1 DEVICE TYPE DISK ;
SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; # switches logs and archives all logs
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/backup/standby_controlfile.ctl';
BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 0 DATABASE filesperset 3 FORMAT '/backup/%d-%t-%s_FULL';
BACKUP AS COMPRESSED BACKUPSET archivelog all delete input filesperset 5 FORMAT ‘/backup/%d-%t-%s_ARCH';
}

Create Physical Standby Database RMAN Duplicate from Backup
• Startup the standby database instance in nomount mode.
• Issue duplicate command, no connection to target needed.
$ nohup rman auxiliary / cmdfile=dup.rcv log=stdby_dup.log &
run {
ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK ;
duplicate target database for standby backup location='/backup';
}
• Standby controlfile will be restored automatically from the backup of it taken.
• All Datafiles will be restored for Standby database
• Standby database will be mounted

Create Physical Standby Database RMAN Duplicate from Active DB
• Duplicate from active database changes in 12c
• USING BACKUPSET
• USING COMPRESSED BACKUPSET
• SECTION SIZE clause
• Example duplicate from active database
RMAN> run {
allocate channel c1 device type disk;
allocate auxiliary channel a1 device type disk;
allocate auxiliary channel a2 device type disk;
duplicate database for standby from active database using backupset nofilenamecheck;
}

Standby Database Setup Tips
• Ensure that you understand the expected transfer rate for the redo to the standby.
–Check the AWR Report under load profile “Redo Size” check the column “Per Second”
–How To Calculate The Required Network Bandwidth Transfer Of Redo In Data Guard Environments
(Doc ID 736755.1)
• The value of the LOG_ARCHIVE_MAX_PROCESSES initialization parameter must be at least one
greater than the total number of all remote destinations.
• The COMPRESSION attribute is used to specify that redo data is sent in compressed form.
• Set archive_lag_target to at least 30 minutes for critical SLAs.
• You can enable block change tracking on a physical standby database (Active DG license required)

Standby Delay
• Enable delay on Standby database from Primary
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=stdby_srvc DELAY=60';
• Enable delay on Standby database
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DELAY 60;
• Return to NoDelay
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

Standby Database way out of Sync!
Problem
• Standby database has a huge gap it is hours or days behind and you don’t have all archive redo logs to
apply to the standby database.
Solution
• Get the current SCN of the Standby database.
• Run RMAN BACKUP INCREMENTAL FROM (Current SCN from Standby) on the Primary database.
• Recover Standby from incremental backup from Primary.

Check Archive Log Gaps
V$ARCHIVED_LOG
• APPLIED Column Indicates whether an archived redo log file has been applied to the corresponding
physical standby database.
V$ARCHIVE_GAP
SQL> select * from v$archive_gap;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE# CON_ID
---------- ------------- -------------- ----------
1 146 149 1
• We can check the GAP status from the Dataguard Broker.
DGMGRL> show configuration

12c Move Datafiles
• You can move the location of an online data file from one physical file to another physical file while the
database is actively accessing the file.
• In releases prior to Oracle Database 12c Release 1 (12.1), you could only move the location of an online
data file if the database was down or not open, or by first taking the file offline.
• You can perform an online move data file operation independently on the primary and on the standby
• The standby is not affected when a data file is moved on the primary, and vice versa.
• On a primary database, the online move data file operation cannot be executed on a file that belongs to a
pluggable database (PDB) that has been closed on all instances of the primary database.
SQL> ALTER DATABASE MOVE DATAFILE;

12c Far Sync
• Far sync instance is a remote Data Guard destination that accepts redo from the primary then ships that
redo to other members of the Oracle Data Guard configuration.
• Provides the ability to failover to a terminal destination with zero data loss
• Offload the primary database of other types of overhead (for example, redo transport)
• Composed of SPFILE, Password file, Control file, SRL, Archive Redo logs
–No Datafiles
–Database not open
–Need enough storage for largest archive log Gap expected

12c Real-time Cascade
• Primary database redo can now be cascaded in real time as it is being written to the SRL at a physical
standby or a far sync instance.
• This feature is known as real-time cascading and it requires a license for the Oracle Active Data Guard
option.
• Real-time cascading is supported on all destinations up to 30(far sync or standby)

12c Fast Sync
• Maximum Availability mode now allows the LOG_ARCHIVE_DEST_n attributes SYNC and NOAFFIRM to
be used together.
• SYNC/AFFIRM - Primary waits for acknowledgment that the redo has been transmitted synchronously to
the physical standby and written to disk.
• SYNC/AFFIRM transport provides a protection benefit at the expense of a performance impact caused by
time required to complete the I/O to the standby redo log.
• Fast Sync or SYNC/NOAFFIRM, the primary performs write operations and waits only for
acknowledgement that the data has been received on the standby, not that it has been written to disk.
• The SYNC/NOAFFIRM transport can provide a performance benefit at the expense of potential exposure
to data loss

Fast Sync VS Sync/Afrrim

SYSDG Role
• For better separation of duty, Oracle Database now provides an Oracle Data Guard-specific
administration privilege, SYSDG.
• Can administer duties for Oracle Data Guard.
• The SYSDBA privilege continues to work as in previous releases.

Thank you!

Nabil Nawaz Oracle Oracle 12c Data Guard Deep Dive Presentation

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Nabil Nawaz Oracle Oracle 12c Data Guard Deep Dive Presentation

Similaire à Nabil Nawaz Oracle Oracle 12c Data Guard Deep Dive Presentation (20)

Dernier

Dernier (20)

Nabil Nawaz Oracle Oracle 12c Data Guard Deep Dive Presentation