Preparing Exadata Storage Servers for Update

8.6.5 Preparing Exadata Storage Servers for Update

Perform these preparation steps before updating the Exadata storage servers.

You can perform the update (and rollback) action in a rolling or non-rolling method. You can also perform a prerequisite check in a rolling or non-rolling method. The default is non-rolling.

Set up SSH equivalence for the user that is driving the update utility.
Download and run the latest version of Exachk. Review and address any open issues. See My Oracle Support note 1070954.1.
Review the release-specific My Oracle Support note for any known issues and workarounds.
Check prerequisites for your method of update or rollback.
1. Prerequisites for performing a rolling update:
  1. Verify that your Grid Infrastructure home and Database home software versions and patch levels meet the minimum required for Exadata storage server rolling cell update as documented in My Oracle Support note 888828.1
  2. Verify failgroup_repair_time or disk_repair_time for each Oracle ASM disk group.
    When applying the update in a rolling manner, the update utility updates one server at a time, first taking all grid disks and ASM disks offline, then applying the update to the server, then bringing all ASM disks and grid disks back online. The Oracle ASM repair timeout attributes, disk_repair_time and failgroup_repair_time, need to be set to a value large enough to allow a single storage server update to complete. The default values of 3.6h and 24h, respectively, are the recommended values. Note that during a rolling storage server update disk groups with compatible.asm >= 12.1.0.2.0 will use the value of failgroup_repair_time, and disk groups with compatible.asm < 12.1.0.2.0 will use the value of disk_repair_time.
    
    Verify ASM repair timeout attributes are set to default or higher values. Use the following command to check repair time attributes for all mounted disk groups in the Oracle ASM instance.
```
SQL> col attribute format a30
SQL> col value format a10
SQL> select dg.name as diskgroup, a.name as attribute, a.value
     from v$asm_diskgroup dg, v$asm_attribute a
     where dg.group_number=a.group_number
       and (a.name like '%repair_time' or a.name = 'compatible.asm');

DISKGROUP                      ATTRIBUTE                      VALUE
------------------------------ ------------------------------ ----------
DATA                           disk_repair_time               3.6h
DATA                           failgroup_repair_time          24.0h
DATA                           compatible.asm                 12.1.0.2.0
RECO                           disk_repair_time               3.6h
RECO                           failgroup_repair_time          24.0h
RECO                           compatible.asm                 12.1.0.2.0
```
    If the Oracle ASM repair timer for any disk group is lower than the default value, then set the repair timer to the default value for the duration of the update. You may set it back to its current value after the update successfully finishes for all storage servers.
2. Prerequisites for performing a non-rolling update:
  1. Shut down and stop the Oracle components on each Exadata database server using the following commands, where Grid_home is the directory where the Oracle Grid Infrastructure software is installed:
```
[root@dm01 ]# dcli -g dbs_group -l root "Grid_home/bin/crsctl stop crs"
```
    If Oracle Clusterware was not stopped using the preceding command, then use the following command to force it to stop on each server:
```
[root@dm01 ]# crsctl stop crs -f
```
  2. Use the following command to check Oracle Clusterware status, where Grid_home is the directory where the Oracle Grid Infrastructure software is installed:
```
[root@dm01 ]# dcli -g dbs_group -l root "Grid_home/bin/crsctl check crs"
```
    All Oracle Clusterware components must be offline. If you are performing a non-rolling update in a configuration running Oracle VM, then you must check the Oracle Clusterware state in all VM clusters.
  3. On systems using Exascale, use the Oracle Exadata Database Machine Command-Line Interface (DBMCLI) utility to shut down the Exascale Direct Volume (EDV) and Exascale Node Proxy (ESNP) services on each database server.
    
    Run the following commands on every database server (bare-metal, KVM host, or guest):
```
dbmcli> alter dbserver shutdown services edv
dbmcli> alter dbserver shutdown services esnp
```
  4. On systems using Exascale, use the Exascale command line interface (ESCLI) to shut down the Exascale cluster services.
    
    For example:
```
$ escli --wallet admin-wallet-location --ctrl ERS-server-IP:8080 chcluster -–shutdown
```
    Note:
    
    To shut down the Exascale cluster services, ensure that you run ESCLI as an Exascale cluster administrator or use the Exascale admin user. You must also connect ESCLI directly to an online Exascale control services (ERS) back-end server process. For more details, see Stop the Exascale Cluster.
Unzip the update. It will extract into the patch_release.date_code directory. Change to this patch directory.
Download any patchmgr plug-ins attached to the My Oracle Support note for your target release and install them as documented in the My Oracle Support note. Oracle recommends reviewing the My Oracle Support notes, issues, and workarounds listed in the release note just before starting to actually apply the update.
Clean up any previous update utility runs using the -cleanup flag.
Note:

The first time the storage servers are updated the -reset_force flag should be used before running cleanup.

Example using -reset_force as the root user:
```
[root@dm01 ]# ./patchmgr -cells ~/cell_group –reset_force
```
Example using -reset_force as a non-root user:
```
[oracle@nonExadataHost ]# ./patchmgr -cells ~/cell_group -log_dir auto –reset_force
```
Example using -cleanup as the root user:
```
[root@dm01 ]# ./patchmgr -cells ~/cell_group -cleanup
```
Example using -cleanup as a non-root user:
```
[oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto –cleanup
```

Run prerequisite check.

Example running prerequisite check for a rolling update as the root user from an Exadata database server:

[root@dm01 ]# ./patchmgr -cells ~/cell_group -patch_check_prereq -rolling -smtp_from "sender@example.com"  
-smtp_to receiver@example.com

Example running prerequisite check for a non-rolling update as a non-root user from a non-Exadata database server:

[oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto -patch_check_prereq -smtp_from "sender@example.com"
-smtp_to "receiver@example.com"