Goldengate Log Rotation
14/04/2015 1 Comment
Golden Gate 12 has some excellent commands to keep your log files in check, plus one glaring omission (scheduled for a future enhancement)
Each extract, datapump and replicat will be writing to report (.rpt) and discard (.dsc) files in the dirrpt directory (if you aren’t specifying a discard file, you should. They are very useful for troubleshooting)
If your system is up for a long time, these files are going to get large. Oracle has realised this and provides some lovely in-built log rotation commands. To keep my parameter (.prm) files nice and neat and consistent, I use include files, and this is a perfect case for a standard include.
report.prm: -- Standard include commands for ALL extracts and replicats to ensure they are aligned -- Write the days stats out to the file at the end of every day. -- Roll the file over every week -- Report just how much throughput we have every 15 minutes -- History: 14.04.2015 N Chandler -- place the command include/dirprm/report.prm in your parameter files STATOPTIONS REPORTDETAIL, RESETREPORTSTATS REPORT AT 23:59 REPORTROLLOVER AT 00:01 ON MONDAY REPORTCOUNT EVERY 15 MINUTES, RATE -- or if you would rather by volume... --REPORTCOUNT EVERY 10000000 RECORDS, RATE
I think it’s worth pointing out here what the 2 bracketed throughput numbers output by the REPORTCOUNT commands mean, as you’ll struggle to find it in the documentation
Rate = number of records processed per second since startup divided by the total time since startup of the extract/replicat Delta = number of records processed per second since last report divided by time since last report (in this case, 15 minutes)
There is 1 notable growing file which you cannot rotate using Goldengate commands: ggserr.log
This is a significant oversight by Oracle and will be rectified in a future release, but as of 12.1 you have to manually sort this out. You have 2 main options to do this:
1. Stop the manager, rename the file, restart the manager
2. Copy the file to a new file and then empty the in-place file by catting /dev/null into it. (I’m sure there’s a Windows equivalent of this, but I mainly work on Unix)
* DO NOT simply delete the file while the manager is running.
All future error output will drop into a “black hole” until the manager is restarted. Option 2 tends to be preferably, so here’s part of a bash script I use to perform this action
#!/bin/bash # rotate_ggserr_log.sh - copies the logfile to one side with a date suffix and blows away the current file # but leaves it in place to we can continue to write to it with the manager. # Neil Chandler 14.04.2015 created # today=`date +%Y%m%d` -- Check to see if we have already rolled-over today if [ -e /u99/gg/bin/ggserr.log.${today} ] then echo "File /u99/gg/bin/ggserr.log.${today} exist already. Stopping." else # copy the log file preserving attributes /bin/cp -pnv /u99/gg/bin/ggserr.log /u99/gg/bin/ggserr.log.${today} # See if there is a difference - did you copy it successfully? diff /u99/gg/bin/ggserr.log /u99/gg/bin/ggserr.log.${today} RC=$? # If there is no difference, wipe the ggserr.log file out # otherwise stop! if [ ${RC} -eq 0 ] then echo "clear the file /u99/gg/bin/ggserr.log" cat /dev/null > /u99/gg/bin/ggserr.log exit ${RC} else echo "Error - cannot clear file /u99/gg/bin/ggserr.log as it's not the same as the copied version. Stopping." exit ${RC} fi fi