Databases Reference
In-Depth Information
If you find yourself in a storage cell rescue procedure situation, we recommend engaging Oracle Support
and working with Support not only to ensure that the steps you take are supported, but to guide you through the
potentially daunting rescue procedure. The rescue procedure itself is relatively straightforward and robust, but care
must me taken to ensure that your recovery experience is positive. Following is a list of recommendations to ensure
you will be able to confidently navigate through a cell rescue using your CELLBOOT USB image:
•
Periodically mount your CELLBOOT USB drive and confirm its contents, per Recipe 8-2. If
your server is experiencing issues backing up the boot image and system volumes to your
CELLBOOT USB drive, you will likely become aware of this during reboots or patching, but it
helps to know that your CELLBOOT USB drive contains the data it should.
•
Make it a practice to create an additional cell boot image on an external USB drive, as
discussed in Recipe 8-3. The storage cell rescue procedure will clearly not work as planned if
your internal CELLBOOT USB drive is damaged.
•
When performing your cell rescue procedure, read the prompts carefully and understand
your data loss risk. The storage cell rescue procedure will not destroy the contents of the data
disks or data partitions on the system area disks unless you explicitly tell it to do so during
the rescue.
•
Configure your ASM storage with normal or high redundancy and create your ASM disk
groups with grid disks spanning storage cell disks. In other words, follow Exadata best
practices; not doing so could lead to data loss during a system volume rescue and mandate
restore and recovery of your data from tape or external RMAN backups.
•
Document your cell and grid disk configuration to reduce errors when rebuilding your
grid disks.
•
Document any custom cell attributes, including SNMP configuration, SMTP details, alert, and
threshold information.
•
Use the ILOM console to perform your storage cell rescue procedure.
8-10. Recovering from a Failed Storage Server Patch
Problem
You have experienced a failure applying a storage server patch and wish to recover its state to an operable status.
Solution
To recover from a failed storage server patch, the Exadata DMA should simply rely on Exadata's patching process and
validation utilities to perform the rollback and recovery. It is very rare that the Exadata DMA will need to perform
any specific steps as part of a failed patch application and, if required, it is generally best to contact Oracle Support to
guide you through the process.
■
Note
to learn more about the exadata storage cell patching process, please refer to recipes 11-2 and 11-3.
Search WWH ::
Custom Search