Business continuity (Disaster Recovery) has become a key aspect of every business for a long time now. Oracle data guard is one of the best solutions for business critical applications running on Oracle databases. From its inception, a lot has been enhanced in standby database functionality to meet the market demand.
This blog post is dedicated and focused on some key enhancements introduced in 19c Data Guard. Below are my hand-picked list of new features, which really got my attention:
Fast-Start-Failover (FSFO) in Observer-only Mode
Configuring FSFO was really a big debate for quite sometime in Oracle community. Some may recommend and some are not in favor of enabling FSFO. Personally, I was not in favor of this feature. Though the decision is lot depends on various factors.
FSFO can be configured in observe-only mode wit 19c (validate without real action), which allow DBAs to test an automatic failover configuration without actually causing any damage to the databases in production environment. When FSFO is configured in observer-only mode, no actual changes are made to the DG Broker settings, also doesn't require any application changes. And, when the conditions for FSFO are met, the DG Broker adds the messages to the observer log indicating that FSFO would have been initiated. This makes it easer to justify using FSFO to reduce the recovery time for real failover.
To enable FSFO in observer mode, use the below syntax:
DGMGRL> ENABLE FAST_START FAILOVER OBSERVER ONLY;
Automatic Flashback Standby
Prior to Oracle 19c, when flashback database or point-in-time operations are performed on a primary database, the underlying standby database needs to be put into same point-in-time as its primary database with a manual procedure (for example, FLASHBACK STANDBY DATABASE TO SCN resetlogs_change# - 2;). This functionality is automated in 19c. This new feature enables the standby database to be flashed back automatically whenever flashback database operation is triggered on the primary database. By automating this process, it drastically reduces the time & efforts and improves RTO.
So, when a primary database has any flashback database or point-in-time recovery operations, the standby automatically follow the primary database, and the MRP on standby database perform the following actions:
Automatic flashback standby operation takes place when the database is opened in MOUNT state. If the standby database is open in READ ONLY mode, the error messages are recorded in the alert log and whenever standby database is restarted, the recovery process (MRP) automatically executes the flashback operation.
DML Operations on Active Data Guard
Performing DML operations on Active Data Guard was something long awaited. I remember, there are some application that needs to long an entry into the database whenever they connected to the database. This was causing many applications no to use with Data Guard, specially for testing.
So, it's here finally with Oracle 19c. Though Oracle doesn't recommend heavy DML operations on active standby database pridicting the performance impact on the primary database. But, it's good for applications that mostly read-applications with occasional DML executions.
To configure DML operations, set ADG_REDIRECT_DML init parameter to TRUE or execute the following SQL statement:
SQL> ALTER SESSION ENABLE ADG_REDIRECT_DML;
Subsequently, perform the DML operations:
SQL> INSERT INTO table VALUES (.......);
** The settings can be database or session level.
DML operations on active standby database are transparently redirected to the primary database upon setting the above configuration, including DML operations that are part of PL/SQL blocks. However, the active data guard session waits until the corresponding changes (DML) are shipped to and applied to the ADG standby database, while maintaining the read-consistency.
To redirect PL/SQL operation from active standby data guard database to primary database, configure the following:
SQL> ALTER SESSION ENABLE ADG_REDIRECT_PLSQL;
Subsequently, perform the PL/SQL operations :
SQL> CREATE OR REPLACE PROCEDURE ....;
Image source (https://blogs.oracle.com/oracle-database/oracle-database-19c-now-available-on-oracle-exadata)
Automatic outage resolution with Data Guard
One of the common scenarios of delayed redo transport and gap resolution on data guard is due to network hangs, disconnects, and disk I/O issue. With 19c, new DATA_GUARD_MAX_IO_TIME and DATA_GUARD_MAX_LONGIO_TIME parameters, DBA can tune the amount of wait time for those detection based on the user network and Disk I/O behavior. Data Guard has an internal mechanism to detect these hung processes and terminate them allowing the normal outage resolution to occur.
Here is the list of new parameters for Data guard:
Stay tuned for more 19c new features.
This blog post is dedicated and focused on some key enhancements introduced in 19c Data Guard. Below are my hand-picked list of new features, which really got my attention:
Fast-Start-Failover (FSFO) in Observer-only Mode
Configuring FSFO was really a big debate for quite sometime in Oracle community. Some may recommend and some are not in favor of enabling FSFO. Personally, I was not in favor of this feature. Though the decision is lot depends on various factors.
FSFO can be configured in observe-only mode wit 19c (validate without real action), which allow DBAs to test an automatic failover configuration without actually causing any damage to the databases in production environment. When FSFO is configured in observer-only mode, no actual changes are made to the DG Broker settings, also doesn't require any application changes. And, when the conditions for FSFO are met, the DG Broker adds the messages to the observer log indicating that FSFO would have been initiated. This makes it easer to justify using FSFO to reduce the recovery time for real failover.
To enable FSFO in observer mode, use the below syntax:
DGMGRL> ENABLE FAST_START FAILOVER OBSERVER ONLY;
Automatic Flashback Standby
Prior to Oracle 19c, when flashback database or point-in-time operations are performed on a primary database, the underlying standby database needs to be put into same point-in-time as its primary database with a manual procedure (for example, FLASHBACK STANDBY DATABASE TO SCN resetlogs_change# - 2;). This functionality is automated in 19c. This new feature enables the standby database to be flashed back automatically whenever flashback database operation is triggered on the primary database. By automating this process, it drastically reduces the time & efforts and improves RTO.
So, when a primary database has any flashback database or point-in-time recovery operations, the standby automatically follow the primary database, and the MRP on standby database perform the following actions:
- detect the new incarnation
- flashback the standby to the exam time as its primary
- restart the standby recovery and move the standby to the new branch of redo
** Note : Flashback operation success is subject to flashback data availability
Automatic flashback standby operation takes place when the database is opened in MOUNT state. If the standby database is open in READ ONLY mode, the error messages are recorded in the alert log and whenever standby database is restarted, the recovery process (MRP) automatically executes the flashback operation.
DML Operations on Active Data Guard
Performing DML operations on Active Data Guard was something long awaited. I remember, there are some application that needs to long an entry into the database whenever they connected to the database. This was causing many applications no to use with Data Guard, specially for testing.
So, it's here finally with Oracle 19c. Though Oracle doesn't recommend heavy DML operations on active standby database pridicting the performance impact on the primary database. But, it's good for applications that mostly read-applications with occasional DML executions.
To configure DML operations, set ADG_REDIRECT_DML init parameter to TRUE or execute the following SQL statement:
SQL> ALTER SESSION ENABLE ADG_REDIRECT_DML;
Subsequently, perform the DML operations:
SQL> INSERT INTO table VALUES (.......);
** The settings can be database or session level.
DML operations on active standby database are transparently redirected to the primary database upon setting the above configuration, including DML operations that are part of PL/SQL blocks. However, the active data guard session waits until the corresponding changes (DML) are shipped to and applied to the ADG standby database, while maintaining the read-consistency.
To redirect PL/SQL operation from active standby data guard database to primary database, configure the following:
SQL> ALTER SESSION ENABLE ADG_REDIRECT_PLSQL;
Subsequently, perform the PL/SQL operations :
SQL> CREATE OR REPLACE PROCEDURE ....;
Automatic outage resolution with Data Guard
One of the common scenarios of delayed redo transport and gap resolution on data guard is due to network hangs, disconnects, and disk I/O issue. With 19c, new DATA_GUARD_MAX_IO_TIME and DATA_GUARD_MAX_LONGIO_TIME parameters, DBA can tune the amount of wait time for those detection based on the user network and Disk I/O behavior. Data Guard has an internal mechanism to detect these hung processes and terminate them allowing the normal outage resolution to occur.
Here is the list of new parameters for Data guard:
Stay tuned for more 19c new features.
No comments:
Post a Comment