Dbvisit Replicate offers automatic house keeping (housekeeping) on the following files:
...
The management of the PLOGs can be found in the MINE/APPLY log files by searching for "plog maintenance with settings".
| Note |
|---|
The management of plogs is only updated 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 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:
...
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
...