Patches are a necessary evil whenever you’re developing software. Since zztat is shipped as a 100% SQL & PL/SQL software, we have the luxury of providing far better usability to patch zztat compared to some other software.
The zztat framework now comes with a full patching mechanism. And it’s pretty powerful!
Let’s assume that you have a zztat repository, and 20-some target databases which are monitored and reporting in to that repository. What if you need to apply a zztat patch?
Well, you’ll be glad to know that all you gotta do, is load the patch into the repository. The framework can then automatically distribute the patch to all the target databases, and apply it there automatically!
The mechanisms used for patching make full use of the core framework components, which enables us to:
- Deliver patch sets (a.k.a. bundle patches)
- Deliver one-off patches or hot-fixes
… and allow you to apply them with a single command. On the entire environment.
The patching component is smart enough to understand:
- Online vs Offline Patches
Some patches will require the framework to be stopped to apply the patch, and restarted thereafter. This will happen automatically.
Some patches may require other patches to install correctly. An example would be a hot-fix produced for a patch-set. We want to take as much of the simple tasks off your hands, so if we need to apply a prerequisite patch and it is available, we’ll apply it automatically. The same goes for patches required to be rolled back before a new patch can be applied.
Patches may render previous patches obsolete. This can happen when a new patch is released which combines two or more previous patches, or when a patch-set includes hot-fixes previously released. The patching component can handle that, too.
- Automated vs Manual Patching
If, for some reason or another you wish to apply the patch manually on a few select databases instead of all of them, there is also a manual mode which gives you full control over the patching process.
The repository of course contains all the information about which patch is ready to apply, applied or rolled back on which target database. And, naturally you will also be controlling all of these things from one single place: the repository database.
So how does it all work?
Say you have a patch that you need to apply to your zztat environment. You’d have to do the following:
- Download the patch onto the zztat repository server and extract the archive
- Start the patch install script
What the framework then will do is the following:
- Locate the patch inventory XML file which contains all the details the patching process needs to do (as well as the rollback steps).
- Load the patch data files into the zztat repository database.
- Patch the repository database.
- Create tasks for the target databases to pick up , and to tell them to download the patch from the repository.
- Once a target database has completed the download, it will inform the repository.
- The repository will create a new task for the patch to be applied.
- The target database will then apply the patch and once complete, inform the repository.
- Once all targets have checked in to the repository, the patch is marked as fully applied.
- If, at a later time a database comes out of blackout or is restarted and zztat finds an automatic patch install has been done in the meantime, it will automatically pick it up and apply the patch as well.
This is yet another awesome feature that lets zztat stand out against existing monitoring software. And there will be more to come!
In closing, we’d like to hear from you guys what you’d think:
Should zztat automatically download (but not apply) available patches from zztat’s servers? Would you want that feature?
Let us know your opinion in the comments!
Have a great day!