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.
