Dbvisit Replicate offers automatic house keeping (housekeeping) on the following files:
Dbvisit Replicate
...
PLOG files
The management of plog PLOG files on source and target systems are done according to the following settings:
| Default | ||
|---|---|---|
| DELETE_OBSOLETE_PLOGS_AGE | Delete plogs PLOGs after specific time period. Time period can be days (d) or hours(h) | 3d |
| DELETE_OBSOLETE_PLOGS_SIZE_MB | Delete plogs PLOGs are total size of all plogs PLOGs exceeds size in MB | 1024 |
| DELETE_OBSOLETE_PLOGS_GZIP | Compress the plogs PLOGs as soon as they are not needed by Dbvisit Replicate anymore | Yes |
The management of the plogs PLOGs can be found in the MineMINE/Apply APPLY log files by searching for "plog maintenance with settings".
| Note |
|---|
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:
| No Format |
|---|
First plog needed (and thus not eligible for deletion): |
If Apply is restarted, it will start processing from this plog.
| Note |
|---|
The last obsolete plog information is only updated on every PLOG switch. |
Dbvisit Replicate redo files
If the Fetcher FETCHER process is used, then redo logs are transferred from the source database server to the server where the Mine 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 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 FETCHER after total size of all plogs PLOGs exceeds size in MB. | 1024 |
| DELETE_OBSOLETE_RLOGS_GZIP | Compress the redo logs transferred from Fetcher 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 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
...
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
LIST OBSOLETE REDOREDO
[THREAD thread]The oldest archive log that MINE will ever need is "last obsolete sequence" + 1
The oldest archive log that APPLY wil 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:
| Section |
|---|
| Column | ||
|---|---|---|
| ||
|
| width | 95 |
|---|
| bgColor | CCC |
|---|
start-console.sh --silent engine mine send engine status
| grep Sequencestart-console.sh --silent engine apply send engine status
| grep Sequence
The Mine MINE process returns the plog PLOG sequence and the redo sequence. If RAC is not used, then this number will be the same.
...
| Align | ||||
|---|---|---|---|---|
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:
|