8.5.10 前提条件チェックの実行

実際の更新を行う前に、常に、前提条件チェックを実行する必要があります。前提条件チェックでは停止時間は必要なく、次のような重要な検証を実行します:

  • Exadataリリースの検証

  • ユーザー入力の検証

  • インストール・メディア(ISOかHTTPのいずれかのYUMリポジトリ)の検証

  • ディスク領域およびスナップショットの検証

  • 更新を正常に終了するために重要なYUM設定の検証

  • 既知の問題とベスト・プラクティスに基づくチェック

更新ユーティリティによって実行される最も重要な検証は、YUM依存性チェックです。YUM依存性チェックは、実際のYUM更新は行わず、依存性の検証を行うYUM更新テスト実行コマンド(11.2.3.3.0で導入)です。これは、更新を続行できるかどうかを判断する最終テストです。正常に更新できない場合、その原因がカスタマイズであることがよくあります。たとえば、RPMを追加でインストールしたことによって、YUMリポジトリにない依存パッケージが必要になることがあります。この場合、競合を解決するための是正処置を実行する必要があります。

YUM依存性チェック(テスト実行)は、MinimumおよびExact依存性に対して検証されます。これらの依存性は非機能Exadata RPMによって成立し、管理者がシステムをカスタマイズするときに、元のExadataリリースとまったく同じ(かそれに近い)状態を維持するために役立ちます。更新ユーティリティでは、次のようにexadata-*-computenode-exactおよびexadata-*-computenode-minimum RPMを使用します:

  • exadata-*-computenode-exact RPMでは、更新中にOracle Exadataブランド・パッケージの特定のリリースのみが許可されるようにします(リリース=x)

  • exadata-*-computenode-minimum RPMでは、更新中にOracle Exadataブランド・パッケージの特定のリリース以降のリリースが許可されるようにします(リリース>=x)

関連するRPMは、システム構成によって異なります。exadata-*-computenode-exact RPMで使用可能な名前を次に示します:

  • exadata-ib-computenode-exact: InfiniBandネットワーク・ファブリックを使用するベアメタル・システム。

  • exadata-sun-computenode-exact: RoCEネットワーク・ファブリックを使用するベアメタル・システムまたはKVMホスト。

  • exadata-sun-kvm-computenode-exact: Oracle Linux KVM上の仮想マシン(VM)ゲスト。

  • exadata-sun-ovs-computenode-exact: Oracle VM Server (OVS)管理ドメイン(Dom0)。

  • exadata-sun-vm-computenode-exact: Oracle VM Server (OVS)ユーザー・ドメイン(DomU)。

exadata-*-computenode-exact RPMを使用すると、すべてのOracle Exadataパッケージがフレッシュ・インストールの場合とまったく同じであるため、システムは新しくイメージ化されたかのように維持されます。exadata-*-computenode-minimum RPMにより、Minimum依存性が設定され、必要なすべてのパッケージのインストールが強制されるが、パッケージをそれより後のバージョンにすることも許容されます。フレッシュ・インストールは常に、両方のRPMを使用して開始されます。カスタマイズまたは更新を可能にするには、exadata-*-computenode-exact RPMを削除する必要があります。ただし、exadata-*-computenode-minimum RPMは削除しないでください。

デフォルトでは、後のExadataリリースに更新するときに、更新ユーティリティはExact依存性を一致させようとします。Exact依存性が競合して成立しない場合、ユーティリティはフォールバックし、Minimum依存性を成立させるために、exadata-*-computenode-minimum RPMの適用を試みます。このような場合、exadata-*-computenode-exact RPMはインストールされていません。

Exact依存性の欠如または未更新は許容され、問題にはなりません。システムをExact依存性に従って更新する必要がある場合、すべての競合を解決する必要があります。ログ・ファイルを調べて、競合するパッケージを確認し、それらを慎重に削除してから、前提条件チェック・モードで更新ユーティリティを再実行します。

前提条件チェックが失敗した場合は、更新ユーティリティのログ・ファイルで詳細を確認し、失敗した依存性を判断できます。Exact依存性とMinimum依存性の両方が一致しないときには、更新は続行できません。

このような場合は、ログ・ファイルを調べて、依存性が失敗した原因を特定します。失敗した依存性を取り除いた後、更新ユーティリティを再実行して、少なくともMinimum依存性が成立することを確認します。

前提条件チェック中または更新の開始前に依存性エラーが発生した場合は、ログ・ファイル(dbnodeupdate.log )を調べ、問題を解決します。状況によっては、依存性の問題や競合の原因となるRPMパッケージを、アンインストール、インストールまたは更新する必要があります。ログ・ファイルには、失敗した依存性が記載されています。

更新後、アンインストールしたカスタムRPMパッケージが引き続き必要となり、かつ、更新したシステムと互換性がある場合は、そのパッケージを再インストールできます。

その他のオプションは、更新ユーティリティに組込みのヘルプを参照してください。

前提条件チェックの例

次のコマンドは、ISOリポジトリを使用した前提条件チェックの例を示しています。このコマンドは、rootとして実行します。

[root@pmserver ]# ./patchmgr --dbnodes dbs_group --precheck --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109

  • --dbnodesには、更新するデータベース・ノードのリストを指定します。

  • --precheckには、前提条件チェック・アクションを指定します。

  • --repoには、更新リポジトリを含む圧縮ISOファイルの場所を指定します。圧縮されたISOファイルを指定する場合は、更新ユーティリティを実行しているノードでファイル・パスにアクセスできる必要があります。または、YUMリポジトリへのURLを指定することもできます。

  • --target_versionには、データベース・サーバーの更新先のターゲット・リリースを指定します。

関連トピック

親トピック: Oracle Exadata Database Serverの更新