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

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

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

1. 更新ユーティリティを駆動するユーザーに対してSSH等価を設定します。
2. Exachkの最新バージョンをダウンロードして実行します。未解決の問題がある場合は、確認して対処します。My Oracle Supportノート1070954.1を参照してください。
3. リリース固有のMy Oracle Supportノートで既知の問題および回避策を確認します。
4. 更新またはロールバックの方式に対して前提条件をチェックします。

   ローリング更新を実行するための前提条件:

   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修復タイマーがデフォルト値よりも低い場合には、修復タイマーを更新期間のデフォルト値に設定してください。すべてのストレージ・サーバーの更新が正常に完了した後で、現在値に戻してもかまいません。

   非ローリング更新を実行するための前提条件:

   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の状態を確認する必要があります。

5. システムが次の条件を満たしているかどうかをチェックします。
   • Oracle Exadata Database MachineハードウェアがSunのサーバーを使用している。
   • インストール済のOracle Exadataソフトウェア・リリースがリリース11.2.2.2.0よりも前のものである。
   • インストール済のLinux ofaパッケージが1.5.1-4.0.28よりも前のものである。

   システムが前の条件をすべて満たしている場合に、Exadataストレージ・サーバーでOracle Linuxを実行していると、ファイル・システムが破損し、その結果、再起動後にルート・ファイル・システムが読取り専用としてマウントされることがあります。ストレージ・サーバーおよびデータベース・サーバーを更新する前に、My Oracle Supportノート1589868.1の指示に従ってください。

6. 更新を解凍します。patch_release.date_codeディレクトリに抽出されます。このパッチ・ディレクトリに移動します。

7. ターゲット・リリースのMy Oracle Supportノートに添付されているpatchmgrプラグインをダウンロードし、My Oracle Supportノートの記載に従ってインストールします。実際に更新の適用を開始する直前に、リリース・ノートに記載されているMy Oracle Supportノート、問題および回避策を確認することをお薦めします。
8. -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
   

9. 前提条件チェックを実行します。

   Exadataデータベース・サーバーからrootユーザーとしてローリング更新の前提条件チェックを実行している例:

   [root@dm01 ]# ./patchmgr -cells ~/cell_group -patch_check_prereq -rolling -smtp_from "[e-mail]"  
   -smtp_to [e-mail]
   

   Exadata以外のデータベース・サーバーからroot以外のユーザーとして非ローリング更新の前提条件チェックを実行している例:

   [oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto -patch_check_prereq -smtp_from "[e-mail]"
   -smtp_to "[e-mail]"