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
No comments:
Post a Comment