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 is done 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 redo logs after specific time period. Time period can be days (d) or hours(h) | 3d |
DELETE_OBSOLETE_RLOGS_SIZE_MB | Delete redo logs are total size of all plogs exceeds size in MB | 1024 |
DELETE_OBSOLETE_RLOGS_GZIP | Compress the redo logs 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".
The management is done on every log switch. The redo logs are located in a directory called mine_stage.
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
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 wil 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.