ODABR (just like purgelog) is probably familiar to anyone who works with Oracle Database Appliances (ODA) or applies patches to them regularly. Until recently, the odabr tool was downloaded via this link from Oracle Support and installed as a RPM.
Newer versions had to be manually copied to the ODA, and the RPM had to be updated accordingly on the ODA.
The ODABR tool then allowed users to manually create backups of the system areas and provided the option to restore them or use the backup to reset the system areas.
Presumably, almost everyone used the tool this way before applying the patch: they created a backup as a snapshot using ODABR, and then manually deleted that snapshot using ODABR after applying the patch.
If an error occurred on the ODA during patching, one was able to restore the backup using 'odabr restore --snap' and rebooting the ODA - which restored the system area (in very rare cases where booting was no longer possible, on had to switch to the rescue disk, but that has never happened to me personally) and one had a working ODA again.
Starting with Release 19.30, the odabr backup and restore utility is now an integrated part of the ODA installation itself and is installed automatically.
As one can see this from the log, the system checks whether odabr is already installed on the ODA and, if so, which version is installed.
Since ODABR is now always available on the server, Oracle has also updated the syntax and checks for odacli accordingly.
Starting with version 19.30, when one generates the prepatch report or perform the upgrade for the server components, there is now a new switch which can be used: “-rf” or “--rollback-onfailure.” This switch ensures that the ODABR utility is automatically checked and used during a patch.
So there are now two different approaches:
The "classical" way:
1. Create an ODABR snapshot manually
2. Precheck and patch the server components
3. Delete the ODABR snapshot manually
The new approach (example with version 19.32.0.2.0) is:
1. odacli create-prepatchreport -sc -v 19.32.0.2.0 -rf
2. odacli update-servercomponents -v 19.32.0.2.0 -rf
Let's have a look behind the curtain of the jobs and check the job output.
When generating the prepatch report, the prepatch check may fail while verifying the rollback behavior.
Why did this happen? The image below (details for the Pre-Checks) shows that one has already created the odabr snapshot here (presumably out of habit or as a safety precaution). This causes the check to fail. When running the command with the “-rf” switch, no snapshot should be present.
The manually created snapshot needs to be deleted. Afterwards, the Pre-Checks all succeed.
If the "-rf" switch was used during the prepatch check, it must also be used when updating the server components! If one misses that, the patching is done without a valid ODABR backup!
Using "-rf", a separate snapshot is created right at the start of the update.
The patching procedure is checking the validity of the snap, which can be found at the log:
After the upgrade has been completed successful, the backup snapshot is deleted automatically and the server reboots a minute later.
This would mean - in theory - a scenario is possible in which an error is only detected AFTER the reboot. However, since the snapshot has already been deleted, a restore would no longer be possible at this stage. With the traditional, manual approach, you can decide for yourself when the snapshot is deleted. Typically, this always happens only after the reboot - nobody deletes a snapshot while the backup job is running (but one could forget to delete the snapshot).
This raises the question of the usefulness of the new switch—who trusts the update mechanism and uses the "-rf" switch, and who is more type "safety first" and sticks with the traditional use of ODABR? Both approaches benefit from the tool's automatic installation. Both approaches are possible, but one should never try to mix them. Use the approach you like and stick on it. If you use "-rf" only on the prepatchreport but don't specify it for the upgrade, you don't have an odabr snapshot!
