Which two statements are true about troubleshooting failed patching activities?
A.
Dependency issues found during yum updates require rolling back to a previous release before
retrying.
B.
Bundle patches applied using opatch auto cannot roll back only the database or the grid
infrastructure home.
C.
Failed OS patches on database servers can be rolled back.
D.
Failed storage cell patches are rolled back to the previous release automatically.
E.
Database server OS updates can be rolled back using opatch auto -rollback.
F.
Dependency issues found during yum updates should be ignored using the force option.
Explanation:
* Oracle has shifted the strategy to patching the exadata in 11.2.3.2.0 onwards to
using Yum as the method of patching.
* Database servers are patched using yum; there is a yum channel for each Exadata image
version. Recently, this functionality replaced the “minimal pack.”
* In the README for each storage server patch, Oracle provides detailed rollback instructions that
are to be followed in the event of a patch failure.
A D
Hi Ranjit,
Do you have any documentation showing this “auto rollback” feature when applying patch on storage server?
Regards,
http://docs.oracle.com/cd/E50790_01/doc/doc.121/e50471/cellmaint.htm#SAGUG21022
Automatic patch rollback occurs if one or more validation checks fail after patch application.
A,D
A,D because; Opatch auto for grid not OS..
A,E
C,D
A.Dependency issues found during yum updates require rolling back to a previous release before retrying.
D.Failed storage cell patches are rolled back to the previous release automatically.
I hope it’s clear now.
According the following documents
answers : CD
http://docs.oracle.com/cd/E50790_01/doc/doc.121/e50471/cellmaint.htm#SAGUG21022
http://docs.oracle.com/cd/E50790_01/doc/doc.121/e51951/db_server.htm#DBMMN22211
C:
When the dbnodeupdate.sh utility performs a rollback, the inactive system disk partition becomes active, and the active system disk partition becomes inactive. Rolling back to the previous release by activating the inactive system partition does not roll back the firmware. The Oracle Exadata Storage Server Software releases support later firmware releases.
The ability to roll back database server updates require a backup to be made prior to updating the database servers. The dbnodeupdate.sh utility creates a backup on the inactive system disk partition when the following conditions are met:
The system uses LVM.
The size of the inactive partition is equal to the active partition. If only LVDbSys1 partition exists, then there must be as much free space in the volume group as the inactive partition to be created.
If both system disk partitions, LVDbSys1 and LVDbSys2, exist, then the volume group must have at least 1 GB free space for the temporary snapshot created during the backup.
If the preceding conditions are not met, then the dbnodeupdate.sh utility reports this, and disables the automatic backup for the process. If you proceed with the update, then you will not be able to roll back the update.
D:
roollack is automatically in cell nodes if one or mmore validations fail
C, D
C – Database server patches can be rolled back executing the following commands:
Step 1 #./dbnodeupdate.sh -r
Step 2 #./dbnodeupdate.sh -c
D – Documented – rollback is automatic
C,D
Automatic patch rollback occurs if one or more validation checks fail after patch application. Refer to the documentation for the specific patch.
https://docs.oracle.com/cd/E80920_01/SAGUG/exadata-storage-server-maintaining.htm#SAGUG20902