Exadataストレージ・サーバーを更新するための準備

8.6.5 Exadataストレージ・サーバーを更新するための準備

Exadataストレージ・サーバーを更新する前に、次の準備ステップを実行します。

更新(およびロールバック)アクションは、ローリング方式または非ローリング方式で実行できます。また、前提条件チェックもローリング方式または非ローリング方式で実行できます。デフォルトは非ローリング方式です。

更新ユーティリティを駆動するユーザーに対してSSH等価を設定します。
Exachkの最新バージョンをダウンロードして実行します。未解決の問題がある場合は、確認して対処します。My Oracle Supportノート1070954.1を参照してください。
リリース固有のMy Oracle Supportノートで既知の問題および回避策を確認します。
更新またはロールバックの方式に対して前提条件をチェックします。
1. ローリング更新を実行するための前提条件:
  1. My Oracle Supportノート888828.1の記載に従って、Grid InfrastructureホームおよびDatabaseホームのソフトウェア・バージョンとパッチ・レベルがExadataストレージ・サーバー・ローリング・セル更新の最小要件を満たしていることを検証します。
  2. それぞれのOracle ASMディスク・グループについて、failgroup_repair_timeまたはdisk_repair_timeを検証します。
    ローリング方式で更新を適用する場合、更新ユーティリティは一度に1つのサーバーを更新します。まず、すべてのグリッド・ディスクおよびASMディスクをオフラインにし、次に、サーバーに更新を適用し、その後、すべてのASMディスクおよびグリッド・ディスクをオンラインに戻します。Oracle ASM修復タイムアウト属性disk_repair_timeおよびfailgroup_repair_timeは、1つのストレージ・サーバー更新を完了できる十分な大きさの値に設定する必要があります。それぞれのデフォルト値である3.6hおよび24hが推奨値です。ローリング中に、compatible.asmが12.1.0.2.0以上のストレージ・サーバー更新ディスク・グループはfailgroup_repair_timeの値を使用し、compatible.asmが12.1.0.2.0未満のディスク・グループはdisk_repair_timeの値を使用することに注意してください。
    
    ASM修復タイムアウト属性がデフォルト以上の値に設定されていることを検証してください。Oracle ASMインスタンスのすべてのマウント済ディスク・グループについて修復時間属性をチェックするには、次のコマンドを使用します。
```
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
```
    ディスク・グループのOracle ASM修復タイマーがデフォルト値よりも低い場合には、修復タイマーを更新期間のデフォルト値に設定してください。すべてのストレージ・サーバーの更新が正常に完了した後で、現在値に戻してもかまいません。
2. 非ローリング更新を実行するための前提条件:
  1. 次のコマンドを使用して、各Exadataデータベース・サーバー上のOracleコンポーネントをシャットダウンして停止します。Grid_homeはOracle Grid Infrastructureソフトウェアがインストールされているディレクトリです。
```
[root@dm01 ]# dcli -g dbs_group -l root "Grid_home/bin/crsctl stop crs"
```
    前述のコマンドを使用してもOracle Clusterwareが停止しなかった場合は、次のコマンドを使用して各サーバーで強制的に停止します:
```
[root@dm01 ]# crsctl stop crs -f
```
  2. 次のコマンドを使用して、Oracle Clusterwareステータスを確認します。Grid_homeはOracle Grid Infrastructureソフトウェアがインストールされているディレクトリです。
```
[root@dm01 ]# dcli -g dbs_group -l root "Grid_home/bin/crsctl check crs"
```
    すべてのOracle Clusterwareコンポーネントがオフラインである必要があります。Oracle VMを実行している構成で非ローリング更新を実行している場合には、すべてのVMクラスタでOracle Clusterwareの状態を確認する必要があります。
  3. Exascaleを使用するシステムでは、Oracle Exadata Database Machineコマンドライン・インタフェース(DBMCLI)ユーティリティを使用して、各データベース・サーバーでExascaleダイレクト・ボリューム(EDV)サービスおよびExascaleノード・プロキシ(ESNP)サービスを停止します。
    
    すべてのデータベース・サーバー(ベアメタル、KVMホストまたはゲスト)で次のコマンドを実行します:
```
dbmcli> alter dbserver shutdown services edv
dbmcli> alter dbserver shutdown services esnp
```
  4. Exascaleを使用するシステムでは、Exascaleコマンドライン・インタフェース(ESCLI)を使用してExascaleクラスタ・サービスを停止します。
    
    次に例を示します:
```
$ escli --wallet admin-wallet-location --ctrl ERS-server-IP:8080 chcluster -–shutdown
```
    ノート:
    
    Exascaleクラスタ・サービスを停止するには、必ずESCLIをExascaleクラスタ管理者として実行するか、Exascale adminユーザーを使用します。また、ESCLIをオンラインのExascale制御サービス(ERS)バックエンド・サーバー・プロセスに直接接続する必要もあります。詳細は、「Exascaleクラスタの停止」を参照してください。
更新を解凍します。patch_release.date_codeディレクトリに抽出されます。このパッチ・ディレクトリに移動します。
ターゲット・リリースのMy Oracle Supportノートに添付されているpatchmgrプラグインをダウンロードし、My Oracle Supportノートの記載に従ってインストールします。実際に更新の適用を開始する直前に、リリース・ノートに記載されているMy Oracle Supportノート、問題および回避策を確認することをお薦めします。
-cleanupフラグを使用して、以前の更新ユーティリティ実行をクリーン・アップします。
ノート:

初めてストレージ・サーバーを更新するときには、クリーン・アップを実行する前に、-reset_forceフラグを使用する必要があります。

rootユーザーとして-reset_forceを使用する例:
```
[root@dm01 ]# ./patchmgr -cells ~/cell_group –reset_force
```
root以外のユーザーとして-reset_forceを使用する例:
```
[oracle@nonExadataHost ]# ./patchmgr -cells ~/cell_group -log_dir auto –reset_force
```
rootユーザーとして-cleanupを使用する例:
```
[root@dm01 ]# ./patchmgr -cells ~/cell_group -cleanup
```
root以外のユーザーとして-cleanupを使用する例:
```
[oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto –cleanup
```
前提条件チェックを実行します。
Exadataデータベース・サーバーからrootユーザーとしてローリング更新の前提条件チェックを実行している例:
```
[root@dm01 ]# ./patchmgr -cells ~/cell_group -patch_check_prereq -rolling -smtp_from "sender@example.com"  
-smtp_to receiver@example.com
```
Exadata以外のデータベース・サーバーからroot以外のユーザーとして非ローリング更新の前提条件チェックを実行している例:
```
[oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto -patch_check_prereq -smtp_from "sender@example.com"
-smtp_to "receiver@example.com"
```