The advantage of having scripts to execute the switch to new files online cannot be overstated. Manually typing the commands and queries to stop, rename and restart processes accessing the files really opens the process up to errors.
These files are generally accessed via database server processes, either TS/MP Pathway managed or the occasional individual generating reports with data from the files. This gave us the ability to 'interrupt' file activity with a relatively small impact.
The high level steps of the script involved, stopping database servers, stopping any ad hoc processes, renaming the current primary file to old primary file, renaming the new primary to the online primary file. Decision to leave the new alternate key file with its created name was so that fewer steps would be involved and since the alternate keys map from the file system it would not be a problem going forward. If needed the ALTER of the alternate key file could be performed later at a planned downtime.
Keep in mind the intent here was to minimize impact to database access, add new alternate key functionality for application use and avoid a planned lengthy system downtime to load and switch to new primary and alternate key files.
The switch process for each set of database files took approximately 5-10 seconds using the script. At this point the new primary file with associated alternate keys was swapped in and the database server recovered. Similar but not exactly like a Base24 log rollover.
The current GoldenGate configuration also facilitated the swap on the Target site as it executed file renames with the GETFILEOPS parameter enabled on the Target. Essentially keeping us in sync across source system and target.
After all files were switched and the database functions were recovered, it was necessary to stop and delete the temporary Extractor and Replicator processes that had been configured to load the new files, they were no longer needed.
Then, a Veridata compare configured to evaluate the new files indicated the New Source and New Target were in Sync, except for one missing 107 records. To recover from this, the Extractor was repositioned on the Extract Trail to a point just a few minutes prior to the swap and restarted with HANDLECOLLISIONS ON. The records were applied and the file was checked again and found to be in sync across Source System and Target System.
Considering time required, the Initial file loads were performed 2 weeks prior to the switch. This enabled appropriate notification, change management and design of switch scripting. The loads were all performed online, during normal working hours and validated without impact to the user community. The file switches were performed without perceived impact from the user community, during normal business hours and using automated scripts in a few seconds.
"Your actual mileage may vary...."
Typically in past operations like these, it required a system downtime, use of FUP to CREATE, LOAD and LOADALTFILE during the outage. Considering the size and number of alternate keys to be added to theses database files the entire process would have had to be either an extremely lengthy downtime or several downtimes to perform.
By using GoldenGate to Load and synchronize the files, the majority of the effort could be focused on distilling the switch scripts to the smallest possible window and time dedicated to validating file integrity before and after the switch.
Again, your conditions and environment may vary, but reducing impact, eliminating a downtime and providing 100% record integrity before and after made GoldenGate an excellent choice for performing an online alteration to these database files.
If you'd like to know more, have questions, comments or I haven't covered something here, drop me a note.
Now I'm off to find another topic of NonStop interest.
-K
No comments:
Post a Comment