What is real-time apply?
Real-Time Apply configuration is a feature of Oracle Data Guard. By enabling real-time apply configuration, you can apply redo data on the go to the standby database without waiting for the redo logs to be archived and then applied to the standby database. This means:
Faster synchronization between primary and standby.
Reduced data loss in case the primary database fails.
For more information, see the Oracle documentation Apply Services.
How to check if real-time apply is enabled?
You can check whether real-time apply is enabled on the standby database by running one of the following queries on SQLPLUS or RMAN prompt:
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';
The status APPLYING_LOG indicates that real-time apply is enabled.SELECT DEST_ID,DEST_NAME,STATUS,TYPE,SRL,RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=1;
IfRECOVERY_MODEvalue is MANAGED REAL TIME APPLY, it indicates that real-time apply is enabled.
Prerequisites for using real-time apply configuration
Make sure you have the following prerequisites in place for enabling real-time apply on standby databases.
All archive logs till the lowest SCN of the database files should be available.
Run the following command to get the minimum Header SCN:
Select MIN(CHECKPOINT_CHANGE#) AS SCN FROM V$DATAFILE_HEADER;Run the following command to get the corresponding log:
SELECT SEQUENCE#, NAME, DELETED, STATUS FROM V$ARCHIVED_LOG WHERE FIRST_CHANGE# <= 3625999 AND NEXT_CHANGE# > 3625999;The user must have
sysbackuppermission for the primary database.If you are using Oracle authentication, the credentials must be the same for the primary and standby database.
If you don’t want to use Oracle Auth or Wallet Auth from the Console, you can provide a key value pair for the primary database name and corresponding connection string in the /etc/Druva/EnterpriseWorkloads/oracle/OraclePlugin.yml file.
For example, if the primary database name is prim, this is how the entry in the OraclePlugin.yml file will look like:primary_connect_string_map:prim: “user/pass@prim as sysbackup”prim2: “user/pass@prim2 as sysbackup”If using wallet creds as connection string, the value will look like this:
primary_connect_string_map:prim: “/@prim as sysbackup”prim2: “/@prim2 as sysbackup”Restart the Agent service:
service Druva-EnterpriseWorkloads restart
If you’re using Wallet or OS authentication, make sure :
Wallet must be configured for the primary database
The TNS Alias must be the same as the primary database name. For example, if the primary database name is prim, there must be an entry in tnsnames.ora with the same name.
Listeners on the primary and standby databases are up and running. You can verify the listener status using the following command on primay and standby:
$ lsnrctl statusVerify if the TNS Alias is being resolved from the standby server:
$ tnsping prim #primary database nameVerify connection to the primary database from the standby database host using the following command:
sqlplus <connectionString>
For example:
sqlplus /@prim as sysbackup (Wallet Auth)
sqlplus user/pass@prim as sysbackup (Oracle Auth)
sqlplus /@prim as sysdba (OS Auth)
For more information on configuring Wallet, see Steps to configure wallet.
Key Considerations for Backups
If the SCN does not change after the previous backup, the FULL backup will fail. You may update SCN manually by restarting the Managed Recovery Process (MRP). For more information, see Process to update SCN manually.
FULL will succeed only when there is a change in the datafile header SCN since the last backup.
Log backup will continue, provided the last FULL backup was successful.
If the last FULL backup fails, the scheduled log backups will not be triggered.
If the backup policy specifies deleting archivelogs from the Oracle server after a successful backup, these logs will be deleted only after every successful FULL backup. This ensures the FULL backup contains all the logs down to the lowest datafile header SCN.
Process to update SCN manually
Check the current datafile header SCN by running the following command:
Select MIN(CHECKPOINT_CHANGE#) AS SCN FROM V$DATAFILE_HEADER;Stop and start MRP:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; #stopALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;#startCheck the MRP restart status:
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';Check the SCN progress after MRP process restart:
SELECT MIN(CHECKPOINT_CHANGE#) AS SCN FROM V$DATAFILE_HEADER;