House Keeping

Dbvisit Replicate offers automatic house keeping (housekeeping) on the following files:

Dbvisit Replicate PLOG files

The management of PLOG files on source and target systems are done according to the following settings:

		Default
DELETE_OBSOLETE_PLOGS_AGE	Delete PLOGs after specific time period. Time period can be days (d) or hours(h)	3d
DELETE_OBSOLETE_PLOGS_SIZE_MB	Delete PLOGs are total size of all PLOGs exceeds size in MB	1024
DELETE_OBSOLETE_PLOGS_GZIP	Compress the PLOGs as soon as they are not needed by Dbvisit Replicate anymore	Yes

The management of the PLOGs can be found in the MINE/APPLY log files by searching for "plog maintenance with settings".

The management of plogs is only done on every PLOG switch.

Last obsolete plog on Apply

The last plog (last obsolete plog) needed on apply can be found by searching in the Apply log for the following string:

First plog needed (and thus not eligible for deletion):

If Apply is restarted, it will start processing from this plog.

The last obsolete plog information is only updated on every PLOG switch.

Dbvisit Replicate redo files

If the FETCHER process is used, then redo logs are transferred from the source database server to the server where the MINE process running. The management of these redo logs are done according to the following settings:

		Default
DELETE_OBSOLETE_RLOGS_AGE	Delete the redo logs transferred from FETCHER after specific time period. Time period can be days (d) or hours(h).	3d
DELETE_OBSOLETE_RLOGS_SIZE_MB	Delete the redo logs transferred from FETCHER after total size of all PLOGs exceeds size in MB.	1024
DELETE_OBSOLETE_RLOGS_GZIP	Compress the redo logs transferred from FETCHER as soon as they are not needed by Dbvisit Replicate anymore.	Yes

The management of the redo logs can be found in the MINE log files by searching for "rlog maintenance with settings". If there are long running transactions, then the oldest redo logs belonging to the start of the transactions will be kept. Use the command dbvrep> LIST OBSOLETE REDO to identify the oldest redo log required. This is very important, if MINE is shutdown, when MINE restarts it will start at the redo specified.

The management is done on every log switch. The redo logs are located in a directory called mine_stage.

** Note if the result of performing dbvrep> list obsolete redo goes back more than 24 hours you may wish to check long running transactions or uncommitted transactions with idle sessions using http://support.dbvisit.com/hc/en-us/articles/215913398-Oldest-redo-log-sequence-required-by-MINE

Dbvisit Replicate log files

. These are set managed to keep one backup file and a size limit of 100MB. This is configurable through the parameters:
- LOG_FILE_SIZE
- LOG_FILE_COUNT
- LOG_FILE_DATE_ROTATE

Manual house keeping is required on the following files:

Dbvisit Replicate trace files
Dbvisit Replicate Cache files (see below)

Obsolete archive redo log files

To obtain a list of obsolete archived redo log files that are not needed by Dbvisit Replicate anymore and therefore maybe deleted (by RMAN), run the following command in Dbvisit Replicate command console:

LIST OBSOLETE REDO [THREAD thread]

The oldest archive log that MINE will ever need is "last obsolete sequence" + 1

The oldest archive log that APPLY will ever need is the sequence # that APPLY is working on

Scripting the output of the "list status" command

To automate the management of Dbvisit Replicate further, the output of the list status command can be scripted.

The commands are:

start-console.sh --silent engine mine send engine status  | grep Sequence
start-console.sh --silent engine apply send engine status  | grep Sequence

The MINE process returns the PLOG sequence and the redo sequence. If RAC is not used, then this number will be the same.

Dbvisit Replicate Cache files

The Dbvisit Replicate executable (dbvrep) is a self contained executable and contains all the necessary required libraries for it to function. These libraries are extracted out of the executable and into the default temporary directory of the system at startup of dbvrep. Dbvisit Replicate will reuse these cache files the next time that it is started. This maybe noticeable in the startup time of dbvrep. If the cache already exists, the startup time is faster.

It maybe possible that there are several cache directories. This can happen if a new version of Dbvisit Replicate is installed. The old cache directories can be removed, however when dbvrep is running, it is difficult to determine which is the current cache and which is the old cache. If the cache needs to be removed, then is preferable to shutdown dbvrep and then remove all cache files and then to restart dbvrep.

The cache files are in the OS default temp directory under a directory called par-username.

Example to remove the Dbvisit Replicate cache:

rm -rf /tmp/par-oracle

Ensure Dbvisit Replicate is stopped before the cache is removed
Configurations settings are NOT stored in the cache
Data being replicated is NOT stored in the cache