Thinking Out Loud

February 3, 2018

PURGEOLDEXTRACTS Not Purging Trail Files Part2

Filed under: 12c,GoldenGate — mdinh @ 4:55 pm
If you read the post PURGEOLDEXTRACTS Not Purging Trail Files, you will find the solution is to replace syntax from mgr.prm as shown below:
Replace PURGEOLDEXTRACTS ./dirdat/*, USECHECKPOINTS, MINKEEPDAYS 1
With    PURGEOLDEXTRACTS /ggs/dirdat/*, USECHECKPOINTS, MINKEEPDAYS 2 

I found the solution by luck vs correct analysis; hence, the adage “Better to be lucky than good.”

Recently, the same issue occurred again for another environment and the solution was just the opposite.

PURGEOLDEXTRACTS dirdat/*, USECHECKPOINTS, MINKEEPHOURS 24, FREQUENCYMINUTES 30
-- PURGEOLDEXTRACTS /DBFS/ggs/dirdat/*, USECHECKPOINTS, MINKEEPHOURS 24, FREQUENCYMINUTES 30

Why is that!

No convention and inconsistency.

Here are the details.

--- How is manager configured?
GGSCI> send manager GETPURGEOLDEXTRACTS

Sending GETPURGEOLDEXTRACTS request to MANAGER ...

--- Manager is configured with trail pointing to /DBFS
PurgeOldExtracts Rules
Fileset                              MinHours MaxHours MinFiles MaxFiles UseCP
/DBFS/ggs/dirdat/*                   24       0        1        0        Y
OK	
--- Extract trail showing from $GG_HOME/dirdat
Extract Trails
Filename                        Oldest_Chkpt_Seqno  IsTable  IsVamTwoPhaseCommit
/u01/app/gg/12.2.0/dirdat/aa    16285

--- How was the extract created?
GGSCI> send e* status

Sending STATUS request to EXTRACT E_HAWK ...


EXTRACT E_HAWK (PID 40932)
  Current status: Recovery complete: At EOF

  Current read position:
  Sequence #: 16285
  RBA: 27233729
  Timestamp: 2018-01-25 21:01:35.000450
  Extract Trail: dirdat/aa --- This is how the trail is defined when extract was created

GGSCI> info e*

EXTRACT    E_HAWK    Last Started 2018-01-25 21:22   Status RUNNING
Checkpoint Lag       00:00:00 (updated 00:00:00 ago)
Process ID           40932
Log Read Checkpoint  File dirdat/aa000016286
                     2018-02-01 14:42:29.000124  RBA 29233729
GGSCI> exit

--- From $GG_HOME, dirdat is using symbolic link to /DBFS
$ ls -ld dir*
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirchk -> /DBFS/ggs/dirchk
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dircrd -> /DBFS/ggs/dircrd
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirdat -> /DBFS/ggs/dirdat
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirdef -> /DBFS/ggs/dirdef
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirdmp -> /DBFS/ggs/dirdmp
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirout -> /DBFS/ggs/dirout
drwxr-xr-x 2 ggsuser oinstall 4096 Jan 26 13:49 dirpcs
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirprm -> /DBFS/ggs/dirprm
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirrpt -> /DBFS/ggs/dirrpt
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirsql -> /DBFS/ggs/dirsql
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirtmp -> /DBFS/ggs/dirtmp
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirwlt -> /DBFS/ggs/dirwlt
lrwxrwxrwx 1 ggsuser oinstall   23 Mar 18  2017 dirwww -> /DBFS/ggs/dirwww

In conclusion, PURGEOLDEXTRACTS location should be defined the same as the extract.

Isn’t that intuitive?

Oracle should make this a MOS Doc ;=)

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Blog at WordPress.com.

%d bloggers like this: