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 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".
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
...
| No Format | ||
|---|---|---|
| ||
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
...