バッチを使用したOracle Grid InfrastructureおよびOracle Databaseへのパッチ適用

バッチを使用すると、パッチ適用プロセス中のサービスの可用性が最大化されます。Oracle Grid Infrastructure 12cリリース2 (12.2.x)以降のソフトウェア・ホームにパッチを適用するときに、コマンドラインでバッチを定義することも、クラスタで実行されているデータベース・サービスの分析に基づいてFleet Patching and Provisioningでバッチのリストを生成することもできます。

バッチを定義するには、いくつかの方法があります。

ユーザー定義のバッチ

このパッチ適用の方法を使用する場合、初めてrhpctl move gihomeコマンドを実行するときに、ソース・ホーム、宛先ホーム、バッチおよび必要に応じてその他のオプションを指定する必要があります。コマンドは、最初のノードの再起動後に終了します。

定義したバッチを使用してOracle Grid Infrastructureにパッチを適用するには:

次の例のように、コマンドラインでバッチのリストを定義して、パッチ適用プロセスを開始します。
```
$ rhpctl move gihome -sourcewc wc1 -destwc wc2 -batches "(n1),(n2,n3),(n4)"
```
前述のコマンド例では、移動操作を開始し、最初のバッチでOracle Grid Infrastructureスタックが再起動したときに終了し、成功をレポートします。Oracle Grid Infrastructureは、-batchesパラメータで指定した順序でバッチを再起動します。

バッチにクラスタ内のすべてのノードが含まれていない場合は、Oracle FPPによって、バッチのリストの末尾に、含まれていないノードが新規バッチ・グループとして自動的に追加されます。たとえば、クラスタにn1、n2、n3、n4という4つのノードがあり、2つのバッチを"(n1),(n2)"として作成した場合、Oracle FPPによって自動的に末尾に3つ目のバッチ・グループが"(n1),(n2),(n3,n4)"として追加されます。

コマンド例では、ノードn1は最初のバッチを形成し、ノードn2およびn3は2つ目のバッチを形成し、ノードn4は最後のバッチを形成しています。コマンドでは、ソースの作業用コピーがwc1として、パッチが適用された(宛先)作業用コピーがwc2として定義されています。

ノート:

パッチ適用処理中に、シングルトン・サービスがバッチ間で再配置され、非シングルトン・サービスが引き続き部分的に使用できるように、バッチを指定できます。
次のように、rhpctl move gihomeコマンドを再度実行して、次のバッチを処理する必要があります。
```
$ rhpctl move gihome -destwc wc2 -continue
```
前述のコマンド例では、2つ目のバッチ(ノードn2およびn3)のOracle Grid Infrastructureスタックを再起動します。コマンドは、2つ目のバッチが正常にパッチ適用されたことをレポートして、終了します。
ノードの最後のバッチが処理されるまで、前述のステップを繰り返します。最後のバッチが処理された後で-continueパラメータを含むコマンドを実行しようとすると、コマンドでエラーが返されます。

前述の一連の手順のいずれかでrhpctl move gihomeコマンドが失敗した場合は、失敗の原因を特定し、修正した後、-continueオプションを指定してコマンドを再度実行し、失敗したバッチへのパッチ適用を試行します。失敗したバッチをスキップして次のバッチに進む場合は、-continueと-skip のパラメータを使用します。最後のバッチをスキップしようとすると、移動操作が終了します。

また、-revertパラメータを使用してコマンドを再発行することで、行われた変更を元に戻し、構成を初期状態に戻すことができます。

前述の手順のいずれかで-continueパラメータではなく-abortパラメータを使用して、パッチ適用プロセスを終了し、クラスタを現在の状態のままにすることができます。
ノート:
- 1つの優先インスタンスによる管理者管理サービスおよび使用可能なインスタンスがない管理者管理サービスは再配置できず、インスタンスの再起動中にオフラインになります。
- 移動操作が進行中の場合は、同じソース・ホームからの別の移動操作または同じ宛先ホームへの別の移動操作は開始できません。
- 移動操作が終了した後で、移動の前に実行されていたものとは異なるノードでサービスが実行されている場合があり、必要に応じてこれらを元のインスタンスに手動で配置しなおす必要があります。
- -abortパラメータを使用してパッチ適用操作を終了する場合、フリート・パッチ適用およびプロビジョニングでは、クリーン・アップは行われず、またパッチ適用ステップは元に戻されません。すべてのノードにパッチが適用されていないため、クラスタ、データベース、あるいはその両方が一貫性のない状態である可能性があります。
- 起動依存性に応じて、移動の開始前にオフラインだったサービスが移動中にオンラインになる場合があります。

フリート・パッチ適用およびプロビジョニング定義のバッチ

ノードのバッチの定義とパッチ適用にフリート・パッチ適用およびプロビジョニングを使用することは、次のコマンド例、つまり、ソースの作業用コピーがwc1で宛先の作業用コピーがwc2となっている例で示すように、実行する必要があるコマンドが1つのみであることを意味します。

$ rhpctl move gihome -sourcewc wc1 -destwc wc2 -smartmove -saf 50 [-eval]

移動操作が完了前のある時点で失敗した場合は、次のように、コマンドを再度実行することで操作を再実行するか、部分的に完了した操作を元に戻すことができます。

$ rhpctl move gihome -destwc destination_workingcopy_name -revert [authentication_option]

管理対象外のホームを指定して-revertパラメータを使用できます。

前述の例で使用されているパラメータは、次のとおりです。

-smartmove: このパラメータにより、Oracle Grid Infrastructureを起動する前にシングルトン・リソースが再配置されるように、非結合のノードのセット上のOracle Grid Infrastructureスタックが再起動されます。

-smartmoveパラメータ:
- サービスとそれらが実行されているノードのマップを作成します。
- ノードのバッチを作成します。次の場合は、ノードをバッチにマージできます:
  - このノードで実行されている非シングルトン・サービスの可用性が、指定したサービスの可用性ファクタ(またはデフォルトの50%)を下回っていない。
  - このノードでシングルトン・サービスが実行されていて、バッチにサービスの再配置先ノードが含まれていない。
- バッチごとにOracle Grid Infrastructureスタックを再起動します。
サービスの可用性ファクタ(-saf Z+): データベース・サービスを実行する必要があるデータベース・インスタンスの最小数を示す正数を割合として指定できます。たとえば:
- 2つのインスタンスで実行されるサービスに対して-saf 50を指定した場合は、一度に1つのインスタンスのみをオフラインにすることができます。
- 3つのインスタンスで実行されるサービスに対して-saf 50を指定した場合は、一度に1つのインスタンスのみをオフラインにすることができます。
- 2つのインスタンスで実行されるサービスに対して-saf 75を指定した場合、宛先は対応できないため、エラーが発生します。
- サービスの可用性ファクタは、2つ以上のインスタンスで実行されるサービスに適用できます。そのため、サービスの可用性ファクタは非ローリング移動を示す0%にすることはできますが、100%にすることはできません。デフォルトは50%です。
- シングルトン・サービスに対してサービスの可用性ファクタを指定した場合、そのようなサービスの可用性は100%であるためパラメータが無視されて、サービスが再配置されます。
-eval: オプションでこのパラメータを使用して、自動生成されたバッチを表示できます。また、このパラメータでは、実際にソフトウェアにパッチを適用することなく、移動操作の順序が表示されます。

バッチを使用したOracle Databaseへのパッチ適用

データベースへのパッチの適用中に、フリート・パッチ適用およびプロビジョニングによって、ノードのバッチを順次処理し、各バッチの多数のノードをパラレルで再起動できます。この方法により、パッチ適用プロセス中のサービスの可用性が最大化されます。コマンドラインでバッチを定義することも、クラスタで実行されているデータベース・サービスの分析に基づいてフリート・パッチ適用およびプロビジョニングでバッチのリストを生成することもできます。