18c :Automatic Correction of Non-logged Blocks at a Data Guard Standby Database

1) We all aware of, when a table has attribute set with nologging option , those redo      will be missed (although redo information there, the data will be missed) and        standby will not apply those changes, and this will problematic when you do a switchover or failover unless you use force logging mode.

2) To address this in 18c, we have three different logging modes to ensure nologged blocks are also captured and send to standby depends on requirement of performance and availability perspective.

3) Of course, we can use FORCE LOGGING at primary database to ensure all modifications are captured, however this has an performance impact where in which you are doing a bulk load and this has to be captured in redo logs may slow down your load process.

To overcome this, we have two new Logging modes available at primary database

Automatic Correction of Non-logged Blocks at a Data Guard Standby Database

Database nologging functionality has been extended to provide better support for use in an Oracle Active Data Guard environment without significantly increasing the amount of redo generated. 

There are two new nologging modes:

1) Standby Nologging for Data Availability

ALTER DATABASE SET STANDBY NOLOGGING FOR DATA AVAILABILITY;

This  mode causes the load operation to send the loaded data to each standby through its own connection to the standby. 

Means the data availability is critical so it has to delay the commit on primary side to ensure all non logged blocks also shipped and applied by MRP

This mode causes the load operation to send the loaded data to each standby through its own respective connection. 

The commit is delayed until all the standbys have applied the data as part of running managed recovery in an Active Data Guard environment

▪ Standby Nologging for Data Availability 

 dedicated connection to all standbys 

 commit delayed until changes are applied on all standbys

2) Standby Nologging for Load Performance

ALTER DATABASE SET STANDBY NOLOGGING FOR LOAD PERFORMANCE;

This mode  is similar to the above one except that the loading process can stop sending the data to the standbys if the network cannot keep up with the speed at which data is being loaded to the primary. 

Standby may miss the data but eventually it fetches the non logged blocks during recover process by MRP process.

With this mode loading process can stop sending the data to the standbys if the network cannot keep up with the speed at which data is being loaded to the primary. 

In this mode it is possible that the standbys may have missing data, but each standby automatically fetches the data from the primary as a normal part of running managed recovery in an Active Data Guard environment.

▪ Standby Nologging for Load Performance 

 all nologging data is directly sent to standby databases 

 if not possible due to network bottlenecks, nologging data transport will be stopped. 

Same situation as on primary for nologging operations.

 Datafile changes will be applied to Standby during normal managed recovery apply.

Commands to Enable an Appropriate Logging Mode

 
 FORCE LOGGING
 ALTER DATABASE FORCE LOGGING;

 STANDBY NOLOGGING FOR DATA AVAILABILITY
 ALTER DATABASE SET STANDBY NOLOGGING FOR DATA AVAILABILITY; 

 STANDBY NOLOGGING FOR LOAD PERFORMANCE
 ALTER DATABASE SET STANDBY NOLOGGING FOR LOAD PERFORMANCE;

Recovery Steps for Physical Standby Databases with conventional nonlogged operations

 
 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 
 RMAN> RECOVER DATABASE NONLOGGED BLOCK;

If the presence of unrecoverable blocks is only found after a switchover, then you can use these same two steps, but the primary database must be just mounted ( not open) and, RMAN must be connected to the primary.