In a scenario where a change is to be made to a Replication enabled Source database and there is concern that the change may not be successful, for example:
- Running a maintenance update with the no integrity (i) flag.
- Schema changes
Replicated Source and Target databases can be reverted by creating a baseline as follows:
0. Ensure that there are enough AI files to hold the transactions involved in the project.
1. Shutdown the target database.
2. Shutdown the source database.
3. Create a baseline by using an Operating System copy or backup program to backup the entire source database (all files: .db, .d<n>, .b<n>, .a<n>, etc.) and the associated <sourcedb>.repl.recovery file to a backup location.
Do not modify or use these backup files unless it is necessary to undo all future changes to the source.
4. At this point the source database can be served no integrity (-i) for example or whatever else the project involves. If running with no-integrity pay special attention to the considerations discussed in Article
000035932.
- It's advisable at this point to terminate the replication server (dsrutil source -C terminate server) since the target is offline and must remain offline for the baseline to be relied upon.
- Changes (transaction notes) to the source database will be written to the AI files. If the AI files become full then the database will shutdown (unless -aistall is used in which case the database will stall) because with replication active but the target database(s) offline no AI files can be emptied. All full AI files will remain in a LOCKED state when switched. If using AIMGT, ensure that the interval (-aiarcinterval) is extended so that ai files are switched when filled or if variable AI files, say every half hour.
5. If changes made to the source database files need to be completely undone without ever applying the changes to the target database(s) then delete the current source files and restore all the associated Operating System copies or backup files of the source and <source>.repl.recovery file, taken in Step 3.
6. If the changes succeeded, then start the target database. Refer to Article
000037491 which should be considered as a technique to speed up the source | target synchronisation.
Ensure that the above procedure is verified in your environment and documented beforehand.
