Foreword:
This article mainly introduces how to recover the ogg process (classic mode) running in the main database and standby database when the Oracle database physical ADG primary and backup switches (switchover, failover).
Test recovery scenario:
1 A switchover occurs between the active and standby devices, and the main database is the ogg source.
2 A switchover occurs between the active and standby databases, and the standby database is the ogg source.
3 A failover switch occurs between the active and standby devices, and the main database is the ogg source.
4 A failover switch occurs between the primary and secondary databases, and the secondary database is the ogg source.
5 A switchover occurs between the active and standby devices, and the main database is the ogg target.
6 A failover switch occurs between the active and standby devices, and the main database is the ogg target.
Test environment:
OGG Software:19.1.0.0.4
Source:
extract :ext_text
pump :pum_test
Target:
replicat:rep_test
Recovery scenario:
1 A switchover occurs between the active and standby devices The main database is the ogg source
After the active/standby switchover occurs, the extract process on the ogg source end of the main library will abend, and an error 01028 will occur.
Recovery method 1: The new standby database directly after the active/standby switch, that is, the original environment is directly synchronized by extracting DG. After the switchover switch, the logs of the active and standby are continuous, so just configure the DG extraction mode in the parameter file. Can
--Add extraction ADG log mode in extract ext_test TRANLOGOPTIONSMINEFROMACTIVEDG --If you use DBLOGREADER mode to access, it cannot be used in ADG mode and needs to be deleted. Access the asm instance by configuring asmuser. --Testing that you can access the asm instance under the grid user sqlplus sys/[email protected]:1521/ + ASM as sysasm --Configuration added to extract tranlogoptions asmuser [email protected]/ + ASM,asmpassword oracle --DDLOPTIONS ADDTRANDATA cannot be used and needs to be deleted --Start process GGSCI> start EXT_TEST --At this time, an error will normally appear when encountering ADG role conversion, prompting Alter Extract to SCN 1,098,590 and restart Extract. ERROR OGG-02803 Encountered a Data Guard role transition. Alter Extract to SCN 1,098,590 and restart Extract, or recreate Extract with the correct number of threads at SCN 1,098,590. --Modify the capture scn of extract to the scn displayed in the error report GGSCI> ALTER EXTRACT ext_test scn 1098590; --Restart the extract process to return to normal, no operation is required on the target side GGSCI> stats EXTRACT
Reference configuration file for DG mode
The scn in the OGG-02803 error is the scn when the standby database becomes the primary database. You can view SwitchOver after complete recovery through change 1098590 through the alert log, or obtain it through the column STANDBY_BECAME_PRIMARY_SCN in the v$database view.
Recovery method two: Extract from the new main library after the active/standby switchover, that is, configure a new extraction process in the main library of the new environment on the target side.
--Close all processes GGSCI> info all ? Program Status Group Lag at Chkpt Time Since Chkpt ? MANAGER STOPPED EXTRACT ABENDED EXT_TEST 00:00:00 00:05:30 EXTRACT STOPPED PUM_TEST 00:00:00 00:00:09 --Package and copy the installation directory to the target tar -cvf ogg.tar ogg/ scp -rp ogg.tar [email protected]:/u01/ --Extract it to the same path on the target side tar xvf ogg.tar --If the database installation directories and instance name configurations on both sides are different, modify the configuration ORACLE_HOME, ORACLE_SID in the configuration file. --Start process GGSCI> start mgr GGSCI> start pum_test GGSCI> start EXT_TEST --At this time, an error will normally occur when encountering the ADG role transformation. 2023-10-29 17:03:31 ERROR OGG-02803 Encountered a Data Guard role transition. Alter Extract to SCN 1,220,815 and restart Extract, or recreate Extract with the correct number of threads at SCN 1,220,815. --Modify the capture scn of extract GGSCI> ALTER EXTRACT ext_test scn 1220815 --start up GGSCI> START EXTRACT EXT_TEST --If the installation directory of OGG is different, that is, the storage path of dirdat changes, you need to modify the exttrail file path of extract and pump. --extract process --Modify the exttrail path configuration in the configuration file --Modify the exttrail file path of the extract process GGSCI> delete EXTTRAIL /u01/ogg/dirdat/eo GGSCI> ADD EXTTRAIL /ogg/ogg/dirdat/eo, EXTRACT EXT_TEST --pump process retains the currently read exttrail position GGSCI> info pum_test,detail --Recreate the delivery process pump and assign a new path GGSCI> delete PUM_TEST GGSCI> add extract PUM_TEST, exttrailsource /ogg/ogg/dirdat/eo GGSCI> add rmttrail /u01/ogg/dirdat/ro,extract PUM_TEST,MEGABYTES 1000 --If exttrail does not retain all exttrail logs, that is, it does not start from 0, then you need to specify the read sequence alter PUM_TEST,EXTSEQNO 10 --Restart the process
If the process is abnormal due to different log threads, it can be rebuilt through drop + add.
GGSCI> DROP EXTRACT ext_test GGSCI> ADD EXTRACT ext_test THREADS t BEGIN SCN s GGSCI> START EXTRACT ext_test
If the following error occurs during startup, please check the configuration of the ogg method asm instance.
OGG-02829 Not able to establish initial position for SCN 0.1268918 (1268918)
Getting attributes for ASM file + FRA/dgocs/archivelog/2023_10_29/thread_1_seq_51.286.1151515025,
SQL <BEGIN dbms_diskgroup.getfileattr(' + FRA/dgocs/archivelog/2023_10_29/thread_1_seq_51.286.1151515025', :filetype, :filesize, :lblksize); END;>: (15056)
ORA-15056: additional error message
ORA-15173: entry 'dgocs' does not exist in directory '/'
ORA-06512: at "SYS.X$DBMS_DISKGROUP", line 322
2 A switchover occurs between the primary and secondary databases, and the secondary database is the ogg source
A switchover occurs between the active and standby servers, and an error ERROR OGG-02803 Encountered a Data Guard role transition. Alter Extract to SCN 1,125,395 and restart Extract, or recreate Extract with the correct number of threads at SCN 1,125,395.
Recovery method 1: The new main database directly after the master/backup switch, that is, the original environment is directly synchronized by extracting the master database. After the switchover switch, the logs of the master and slave are continuous, so as long as the extraction of the master database is configured in the parameter file mode
--Delete adg configuration mode ATRANLOGOPTIONSMINEFROMACTIVEDG --Add parameter configuration of main library mode --Modify the capture scn of extract to the scn of OGG-02803 error GGSCI> ALTER EXTRACT ext_test scn 1125395 --Restart GGSCI> START EXTRACT ext1
Reference configuration file for extract
Recovery method two: Extract from the new standby database after the active/standby switchover, that is, configure a new extraction process in the new environment standby database at the target end.
--Close all processes GGSCI> info all ? Program Status Group Lag at Chkpt Time Since Chkpt ? MANAGER STOPPED EXTRACT ABENDED EXT_TEST 00:00:00 00:05:30 EXTRACT STOPPED PUM_TEST 00:00:00 00:00:09 --Package and copy the installation directory to the target tar -cvf ogg.tar ogg/ scp -rp ogg.tar [email protected]:/u01/ --Extract it to the same path on the target side tar xvf ogg.tar --If the database installation directories and instance name configurations on both sides are different, modify the configuration ORACLE_HOME, ORACLE_SID in the configuration file. --Start process GGSCI> start mgr GGSCI> start pum_test GGSCI> start EXT_TEST --At this time, an error will normally occur when encountering the ADG role transformation. 2023-10-29 17:03:31 ERROR OGG-02803 Encountered a Data Guard role transition. Alter Extract to SCN 1,220,815 and restart Extract, or recreate Extract with the correct number of threads at SCN 1,220,815. --Modify the capture scn of extract GGSCI> ALTER EXTRACT ext_test scn 1220815 --start up GGSCI> START EXTRACT EXT_TEST --If the installation directory of OGG is different, that is, the storage path of dirdat changes, you need to modify the exttrail file path of extract and pump. --extract process --Modify the exttrail path configuration in the configuration file --Modify the exttrail file path of the extract process GGSCI> delete EXTTRAIL /u01/ogg/dirdat/eo GGSCI> ADD EXTTRAIL /ogg/ogg/dirdat/eo, EXTRACT EXT_TEST --pump process retains the currently read exttrail position GGSCI> info pum_test,detail --Recreate the delivery process pump and assign a new path GGSCI> delete PUM_TEST GGSCI> add extract PUM_TEST, exttrailsource /ogg/ogg/dirdat/eo GGSCI> add rmttrail /u01/ogg/dirdat/ro,extract PUM_TEST,MEGABYTES 1000 --If exttrail does not retain all exttrail logs, that is, it does not start from 0, then you need to specify the read sequence GGSCI> alter PUM_TEST,EXTSEQNO 10 --Restart the process
3 A failover switch occurs between the primary and secondary databases, and the primary database is the ogg source
When a failover switch occurs between the primary and secondary databases, it is usually because the primary database has suffered extreme damage, such as storage damage or server damage, causing the primary database to be unable to start normally. At this time, ogg can only be extracted from the primary database after the failover.
Recovery method 1: If the ogg software of the main library is still retained, you can directly copy the ogg software of the main library to the main library after failover.
--Package and copy the installation directory to the target tar -cvf ogg.tar ogg/ scp -rp ogg.tar [email protected]:/u01/ --Extract it to the same path on the target side tar xvf ogg.tar --View the scn when the standby database becomes the primary database, STANDBY_BECAME_PRIMARY_SCN SQL> select STANDBY_BECAME_PRIMARY_SCN from v$database; ? STANDBY_BECAME_PRIMARY_SCN -------------------------- 1400705 ? --Modify the scn of the process to STANDBY_BECAME_PRIMARY_SCN GGSCI> alter extract EXT_TEST scn 1400705 --If the database installation directories and instance name configurations on both sides are different, modify the configuration ORACLE_HOME, ORACLE_SID in the configuration file. --Start process GGSCI> start mgr GGSCI> start pum_test GGSCI> start EXT_TEST
Recovery method two: install a new ogg directory and rebuild the extract and pump processes
--Install ogg software --Configuration files for mgr, extract, and pump --Re-add extract GGSCI> add extract EXT_TEST tranlog,begin now,threads 2 GGSCI> add exttrail /u01/ogg/dirdat/eo,extract EXT_TEST,megabytes 1000 --scn is STANDBY_BECAME_PRIMARY_SCN GGSCI> alter extract EXT_TEST scn 1400705 --Re-add pump GGSCI> add extract PUM_TEST, exttrailsource /u01/ogg/dirdat/eo GGSCI> add rmttrail /u01/ogg/dirdat/ro,extract PUM_TEST,MEGABYTES 1000 --Start the extract and pump processes --replicat does not need to be rebuilt, the rmtrail queue file will be automatically generated
4 A failover switch occurs between the primary and secondary databases, and the secondary database is the ogg source
Recovery method: It can only be extracted on the new main database, so change the DG extraction mode of ogg configuration to the configuration extracted on the main database.
--Delete adg configuration mode
ATRANLOGOPTIONSMINEFROMACTIVEDG
--Add parameter configuration of main library mode
--View the switched scn
SQL>select STANDBY_BECAME_PRIMARY_SCN
2 from v$database
?
STANDBY_BECAME_PRIMARY_SCN
--------------------------
1475226
--Modify the capture scn of extract
GGSCI> ALTER EXTRACT ext_test scn 1475226
--start up
GGSCI> START EXTRACT ext1
5 A switchover occurs between the primary and secondary databases, and the primary database is the ogg target
A switchover occurs between the active and standby devices, and the replica process will report an error OGG-01004 Aborted grouped transaction on TEST.T_20200308, Database error 16000 (OCI Error ORA-16000: database open for read-only access (status = 16000),
Since the target application process of ogg needs to write data, it cannot run on the physical DG.
Recovery method: copy ogg to the new main library for application
--Before copying the directory, remember to stop the pump process on the source side and ensure that the trial log on the application side is not written again before copying. --Package and copy the installation directory to the target tar -cvf ogg.tar ogg/ scp -rp ogg.tar [email protected]:/u01/ --Extract it to the same path on the target side tar xvf ogg.tar --If the directory copied to the new path is inconsistent --To modify the trial path of the application process --First record the trail rba of the replicate process GGSCI> info rep_test,detail --Modify the replicate trial again GGSCI> alter replicat rep_test,exttrail /ogg/ogg/dirdat/ro GGSCI> alter replicat rep_test EXTSEQNO 0, EXTRBA 1713507 --Modify the target IP of the source pump process to the new environment IP GGSCI> rmthost 172.20.10.100, mgrport 7810 --If the directory of the new environment is inconsistent, modify the configuration file GGSCI> rmttrail /ogg/ogg/dirdat/ro --Re-add rmttrail GGSCI> delete RMTTRAIL /u01/ogg/dirdat/ro, EXTRACT PUM_TEST GGSCI> ADD RMTTRAIL /ogg/ogg/dirdat/ro, EXTRACT PUM_TEST --Start the replicate process GGSCI> stat rep_test
6 A failover switch occurs between the primary and secondary databases, and the primary database is the ogg target
When a failover switch occurs between the primary and secondary databases, it is usually because the primary database has suffered extreme damage, such as storage damage or server damage, causing the primary database to be unable to start normally. At this time, ogg can only be applied on the primary database after the failover.
Recovery method 1: Copy ogg to the new main library for application
--Before copying the directory, remember to stop the pump process on the source side and ensure that the trial log on the application side is not written again before copying. --Package and copy the installation directory to the target tar -cvf ogg.tar ogg/ scp -rp ogg.tar [email protected]:/u01/ --Extract it to the same path on the target side tar xvf ogg.tar --If the directory copied to the new path is inconsistent --To modify the trial path of the application process --First record the trail rba of the replicate process GGSCI> info rep_test,detail --Modify the replicate trial again GGSCI> alter replicat rep_test,exttrail /ogg/ogg/dirdat/ro GGSCI> alter replicat rep_test EXTSEQNO 0, EXTRBA 1713507 --Modify the target IP of the source pump process to the new environment IP GGSCI> rmthost 172.20.10.100, mgrport 7810 --If the directory of the new environment is inconsistent, modify the configuration file GGSCI> rmttrail /ogg/ogg/dirdat/ro --Re-add rmttrail GGSCI> delete RMTTRAIL /u01/ogg/dirdat/ro, EXTRACT PUM_TEST GGSCI> ADD RMTTRAIL /ogg/ogg/dirdat/ro, EXTRACT PUM_TEST --Start the replicate process GGSCI>stat rep_test
Recovery method two: Install a new OGG software and reconfigure the replicate process
--Install ogg software --Configure mgr, replicate configuration files --Add replicate again GGSCI> dblogin userid ogg,password "go_20230_W506" GGSCI> delete checkpointtable ogg.rep_chkpt GGSCI> add checkpointtable ogg.rep_chkpt GGSCI> add replicat rep_test,exttrail ./dirdat/ro,checkpointtable ogg.rep_chkpt GGSCI> alter replicat rep_test, EXTSEQNO 0, EXTRBA 0 ? --Modify the target IP of the source pump process to the new environment IP GGSCI> rmthost 172.20.10.100, mgrport 7810 --If the directory of the new environment is inconsistent, modify the configuration file GGSCI> rmttrail /u01/ogg/dirdat/ro --Re-add rmttrail GGSCI> delete RMTTRAIL /ogg/ogg/dirdat/ro, EXTRACT PUM_TEST GGSCI> ADD RMTTRAIL /u01/ogg/dirdat/ro, EXTRACT PUM_TEST --Modify the source pump process to read the exttrail location. The logs read must be before the switch, so that the data will not be lost. GGSCI> ALTER EXTRACT pum_test, EXTSEQNO 0, EXTRBA 0 --Replicat process adds data conflict checking parameters to ensure that the table has a primary key or unique key HANDLECOLLISIONS --Start the replicate process GGSCI>stat rep_test
The knowledge points of the article match the official knowledge files, and you can further learn relevant knowledge. Cloud native entry-level skills treeHomepageOverview 17045 people are learning the system