In my setup, I have three databases:
- A primary database (hdal)
- A physical standby database (hdal_stb) which serves as a "cascading" database
- A terminal standby database (hdal_tstb) which receives redo from the cascading standby database
dgmgrl / as sysdba Connected to "hdal_stb" Connected as SYSDBA. DGMGRL> show configuration; Configuration - DGConfig1 Protection Mode: MaxPerformance Members: hdal - Primary database hdal_stb - Physical standby database hdal_tstb - Physical standby database (receiving current redo)
DGMGRL> edit database 'hdal_stb' set property ApplyParallel=4;
In the database's alert log, we can se that Oracle is cancelling the ongoing recovery process:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL 2020-08-10T09:26:24.249847+02:00 MRP0: Background Media Recovery cancelled with status 16037 Managed Standby Recovery not using Real Time Apply Recovery interrupted! Recovered data files to a consistent state at change 27754456 2020-08-10T09:26:24.510262+02:00 ORA-16037: user requested cancel of managed recovery operation 2020-08-10T09:26:24.617519+02:00 MRP0: Background Media Recovery process shutdown (hdal) 2020-08-10T09:26:25.250904+02:00 Managed Standby Recovery Canceled (hdal)And then starting it again:
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT PARALLEL 4 NODELAY 2020-08-10T09:26:25.284547+02:00 Attempt to start background Managed Standby Recovery process (hdal) Starting background process MRP0 2020-08-10T09:26:25.306150+02:00 MRP0 started with pid=77, OS id=115854 2020-08-10T09:26:25.311038+02:00 MRP0: Background Managed Standby Recovery process started (hdal) 2020-08-10T09:26:30.339894+02:00 Started logmerger process 2020-08-10T09:26:30.378497+02:00 Managed Standby Recovery starting Real Time Apply 2020-08-10T09:26:30.515607+02:00 Parallel Media Recovery started with 4 slaves 2020-08-10T09:26:30.741846+02:00 Media Recovery Waiting for thread 1 sequence 8299 (in transit)Verify the new setting by looking at the properties (output truncated for brevity):
DGMGRL> show database verbose hdal_stb Database - hdal_stb Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds (computed 1 second ago) Apply Lag: 0 seconds (computed 1 second ago) Average Apply Rate: 0 Byte/s Active Apply Rate: 0 Byte/s Maximum Apply Rate: 0 Byte/s Real Time Query: OFF Instance(s): hdal Properties: DGConnectIdentifier = 'hdal_stb' LogXptMode = 'ASYNC' ApplyParallel = '4'The change will be propagated to the other members of the data guard configuration. The data guard broker logfile, located in $ORACLE_BASE/diag/rdbms/$UNIQUE_NAME/$ORACLE_SID/trace, shows:
08/10/2020 09:26:24 Forwarding EDIT_RES_PROP operation to member hdal for processing 08/10/2020 09:26:31 Updated broker configuration file available, loading from "$ORACLE_HOME/dbs/dr2hdal_stb.dat" 08/10/2020 09:42:35 Forwarding MON_PROPERTY operation to member hdal_tstb for processingThe cascading database hdal_tstb simply confirms that the broker configuration has been updated:
08/10/2020 09:26:31 Updated broker configuration file available, loading from "$ORACLE_HOME/dbs/dr2hdal_tstb.dat"The primary database is also verifying the change, although a bit more detailed:
08/10/2020 09:26:24 EDIT DATABASE hdal_stb SET PROPERTY applyparallel = 4 08/10/2020 09:26:31 EDIT INSTANCE hdal ON DATABASE hdal_stb SET PROPERTY applyparallel = 4 completed successfullyDocumentation for dgmgrl version 19c can be found here