source
Golden Gate Extract Abended with ERROR OGG-01028
APRIL 13, 2015 LEAVE A COMMENT
In our production environment today I received an alert as below
Alert: EM Event: Critical:test.com – EXTRACT E_PRD’s Time Since Last Checkpoint is currently 1396 seconds.
I fixed this issue as below.
Step 1: Invoke GGSCI
Go to the folder were ggate is installed on the server and invoke ggsci (or set path environment variable accordingly and run ggsci from anywhere)
D:\ggate>ggsci
Oracle GoldenGate Command Interpreter for Oracle
Version 11.2.1.0.13 17435036 OGGCORE_11.2.1.0.0OGGBP_PLATFORMS_131002.1206
Windows x64 (optimized), Oracle 11g on Oct 3 2013 11:17:46
Copyright (C) 1995, 2013, Oracle and/or its affiliates. All rights reserved.
Step 2: Check status of extract
Use info all command or info to view the status of the extract
GGSCI (GPDB04) 1>
GGSCI (GPDB04) 41> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
JAGENT RUNNING
EXTRACT ABENDED E_PRD 03:46:35 00:03:57
EXTRACT RUNNING P_PRD 00:00:00 00:00:06
Step 3: Check error log file
The error log file is in the place where golden gate is installed and generally called ggserr.log
2015-04-10 02:15:56 INFO OGG-00987 Oracle GoldenGate Command Interpreter for Oracle: GGSCI command (sthangavelu-c): info all.
2015-04-10 02:17:11 ERROR OGG-01028 Oracle GoldenGate Capture for Oracle, E_PRD.prm: Could not find archived log for sequence 167886 thread 1 under default destinations SQL
2015-04-10 02:17:16 ERROR OGG-01668 Oracle GoldenGate Capture for Oracle, E_PRD.prm: PROCESS ABENDING.
The extract is complaining that it can’t find a sequence number. This happens generally when an archive log backup removes all archive logs before they are used by the GG extract process. The archive log backup doesn’t normally wait for the golden gate to catchup as it is a totally an independent process.
Step 4: Restore missing sequence
Restore the missing sequences from backup as below
RMAN> restore archivelog from sequence 167886 until sequence 167888;
Starting restore at 10-APR-15
using channel ORA_DISK_1
archived log for thread 1 with sequence 167950 is already on disk as file G:\FLASHRECOVERYAREA\MNPROD7\MNPROD7\ARCHIVELOG\2015_04_10\O1_MF_1_167950_BLGP6SKG_.A
archived log for thread 1 with sequence 167951 is already on disk as file G:\FLASHRECOVERYAREA\MNPROD7\MNPROD7\ARCHIVELOG\2015_04_10\O1_MF_1_167951_BLGQJPJZ_.A
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=167886
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=167887
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=167888
channel ORA_DISK_1: restoring archived log
channel ORA_DISK_1: reading from backup piece G:\FLASHRECOVERYAREA\MNPROD7\MNPROD7\OFQ408C2_1_1
channel ORA_DISK_1: piece handle=G:\FLASHRECOVERYAREA\MNPROD7\MNPROD7\OFQ408C2_1_1 tag=TAG20150410T010021
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:55
Finished restore at 10-APR-15
Step 4: Restart extract
After restore, restart the extract
GGSCI (GPDB04) 42> start e_prd
Sending START request to MANAGER …
EXTRACT E_PRD starting
GGSCI (GPDB04) 58> info e_prd
EXTRACT E_PRD Last Started 2015-04-10 02:19 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:01 ago)
Log Read Checkpoint Oracle Redo Logs
2015-04-10 02:26:52 Seqno 167952, RBA 21403648
SCN 0.1389927798 (1389927798)
Step 5: Check whether the extract has caught up
Depending on how long the extract was down, it can take a while to catch up.
GGSCI (GPDB04) 59> info all
Program Status Group Lag at Chkpt Time Since Chkpt
MANAGER RUNNING
JAGENT RUNNING
EXTRACT RUNNING E_PRD 00:00:00 00:00:01
EXTRACT RUNNING P_PRD 00:00:00 00:00:09
EXTRACT RUNNING P_PRDT 00:00:00 00:00:04
No comments:
Post a Comment