| Oracle® OPatchユーザーズ・ガイド 13c リリース2 E49737-08 |
|
 前 |
 次 |
この章では、使用中に発生する可能性のある一般的なOPatchAutoの問題について説明します。
この章の内容は次のとおりです。
OPatchAutoは、パッチ適用プロセスを十分に自動化するために、様々なツール/ユーティリティにアクセスし、様々なパッチ適用フェーズを実行します。主なツール/ユーティリティは次の4つです。
OPatch - 製品(Fusion Middlewareなど)ホームにパッチを適用します。
rootcrs - パッチを適用可能にするためのファイルのロック解除およびGIスタックの起動と停止を行うことにより、GIホーム・アクセスを制御します。
patchgen - パッチ・レベルを記録します。
datapatch - データベース・インスタンスにSQL変更を適用します。
これらのツール/ユーティリティはパッチ適用プロセス中にアクセスされます。このため、OPatchAutoのトラブルシューティングには、個別のツールに関する問題の診断が含まれています。
OPatchAutoを使用する際には、解決策を続行する方法が明確ではない問題が発生する場合があります。次のユースケースでは、このような問題が発生する可能性のある一般的なパッチ適用シナリオおよび問題を解決するために使用できる一般的な手順を示します。
rootcrs.plスクリプトは、クラスタ上にGrid Infrastructureスタックを構成するために必要な処理を実行します。OPatchAutoセッション時には、rootcrs.plスクリプトが原因のエラーが発生する場合があります。
OPatchAutoが発行するコマンド: $GRID_HOME/crs/rootcrs.pl -prepatch
rootcrs.plが失敗した場合、次の例に示すように、エラー・コードとそれに関連するメッセージが生成されます。
CRS-1159: The cluster cannot be set to rolling patch mode because Grid Infrastructure is not active on at least one remote node.
メッセージが明確ではない場合に追加のヘルプを取得するには、OERRユーティリティを実行して、原因と推奨アクションに関する情報を取得します。
OERRの実行
特定のエラー・コードに対してOERRを実行すると、該当するエラー・コードの原因とアクションの両方が生成されます。
例10-1 CRSエラー
$GRID_HOME/bin/oerr crs 1159 Cause: The cluster could not be set to rolling patch mode because Grid Infrastructure was not active on any of the remote nodes. Action: Start Grid Infrastructure on at least one remote node and retry the 'crsctl start rollingpatch' command, or retry patching using the non-rolling option.
例10-2 CLSRSCエラー
CLSRSC-400: A system reboot is required to continue installing. oerr clsrsc 400 Cause: The installation of new drivers requires a node reboot to continue the install. Action: Reboot the node and rerun the install or patch configuration step.
次の表に、パッチ適用セッション時に発生する可能性のある一般的なエラー・コードを示します。包括的なリストについては、Oracle® Databaseエラー・メッセージのマニュアルを参照してください。
表10-1 CRSエラー・コード
| エラー・コード | コンソール・メッセージ |
|---|---|
1153 |
Grid Infrastructureをローリング・パッチ・モードに設定中にエラーが発生しました。 |
1154 |
Oracle ASMをローリング・パッチ・モードに設定中にエラーが発生しました。 |
1156 |
クラスタがアップグレードの途中であるため、ローリング・パッチ・モードの変更を拒否しています。 |
1157 |
クラスタが強制的にアップグレードされたため、ローリング・パッチ・モードの変更を拒否しています。 |
1158 |
クラスタをローリング・パッチ・モードに設定中にエラーが発生しました。 |
1159 |
Grid Infrastructureは少なくとも1つのリモート・ノードでアクティブではないため、クラスタはローリング・パッチ・モードに設定されません。 |
1162 |
パッチ・レベルがクラスタのすべてのノード間で一致していないため、ローリング・パッチ・モードの変更を拒否しています。ノード<patch_list>の所定のパッチ・レベルがパッチ・レベル<patch_level> (ノード<node_list>で見つかった)と同じではありません。 |
1163 |
Grid Infrastructureのローリング・パッチ・モードをリセット中にエラーが発生しました。 |
1164 |
Oracle ASMのローリング・パッチ・モードをリセット中にエラーが発生しました。 |
1166 |
Oracle ASMが<current_state>状態にあるため、ローリング・パッチ・モードの変更を拒否しています。 |
1168 |
クラスタのローリング・パッチ・モードをリセット中にエラーが発生しました。 |
1171 |
パッチ・レベルがクラスタのすべてのノード間で一致していないため、ローリング・パッチ・モードの変更を拒否しています。ノード<node_list>のパッチ・レベルがパッチ・レベル<patch_level> (ノード<node_list>で見つかった)と同じではありません。 |
1181 |
Grid Infrastructureのリリース・パッチ・レベルを取得中にエラーが発生しました。 |
1183 |
Grid Infrastructureのリリース・パッチ・レベルは<patch_level>で、パッチ<patch_list>の不完全なリストがローカル・ノード上で適用されています。 |
1191 |
Grid Infrastructureのソフトウェア・パッチ・レベルを取得中にエラーが発生しました。 |
問題1: ロール不可能なパッチがローリング・モードで適用されている
2ノード(ノード1およびノード2)構成において、ロール不可能なパッチをローリング・モードで適用しようとしています。
注意:
デフォルトでは、OPatchAutoはローリング・モードでパッチを適用します。
パッチをローリング・モードで適用しているため、すべてのデータベースおよびスタックは停止していません。OPatchAutoを実行すると、予定どおりにスタック・インベントリを出力し、バイナリを更新します。
症状
rootcrs.pl -postpatch (Oracleパッチ適用ツール(OPatch)の起動後に必要な手順を実行)を実行すると、複数のノードのASMインスタンスのパッチ・レベルが異なることが原因で失敗します。この状況では、OPatchAuto (OPatchを実行)は、ゼロ以外の終了コードで失敗します。ただし、パッチはGIホームに残されたままです。スタックは起動できません。
推奨アクション
重要なのは、この状況ではパッチはすでにノード1に適用されているため、ロールバックする必要はないということです。通常、スタックの起動を試みるのは、最後に実行するステップです。スタックの起動に失敗した場合でも、パッチはノードに正常に適用されています。
パッチはロール不可能であるため、スタックに関する問題を解決するには、次の手順を実行します。
すべてのノードのスタックを停止します。
パッチREADMEに記載されている手動の手順に従って、残りのノードにパッチを適用します。
すべてのノードのスタックを再起動します。
問題2: OPatchAutoがGIホームへのパッチ適用に失敗する
サブパッチ(P1およびP2)を含む1つのシステム・パッチがあります。OPatchAuto applyを実行すると、最初にRACホームにパッチを適用します。このシナリオでは、P1は時刻t1にRACに適用され、P2は時刻t2にRACに適用されます。OPatchAutoは、時刻t3にサブパッチP2をGIホームに適用しようと試みますが、失敗します。
症状
OPatchAutoは、ゼロ以外の終了コードで失敗します。エラー・メッセージは、GIホームでサブパッチP2を適用した際に失敗したことを示しています。エラー・メッセージには、ログ・ファイルの場所も記載されています。現在、RACホームにはP1およびP2が含まれていますが、GIホームではP2が欠落しています。
推奨アクション
欠落したパッチをGIホームに適用する必要があります。システム・パッチはすでにRACホームに正常に適用されているため、パッチをロールバックする必要はありません。
ログ・ファイルから、GIホームでのパッチ適用が失敗した原因を判別します。
GIホームでのパッチ適用が失敗したことに関する問題を修正します。
GIホームでのパッチ適用が失敗した場合、考えられる原因が3つあります。
patchgen -- この状況では、patchgenユースケースで指定した推奨アクションを参照してください。「Patchgen」を参照してください。
GIホームに手動でパッチを適用する必要があります。手順は、パッチのREADMEを参照してください。
opatch -callコマンドが失敗しました。この状況では、OPatch実行時にエラーが発生しています。たとえば、OPatchが必要なファイルをコピーできていません。
rootcrs.pl -prepatch (OPatchを起動する前に、必要な手順を実行)が失敗しました。
失敗の原因に関係なく、問題を解決してパッチを手動でGIホームに適用する必要があります。
GIホームでopatchauto resumeを再実行します。OPatchAutoによって、パッチ適用が失敗した時点から再開されます。
問題点
システム・パッチを適用すると、patchgenで発生したエラー状態の結果としてOPatchAutoが失敗します。
症状
OPatchAutoが失敗した際には、patchgenで発生した問題が原因でパッチの適用に失敗したことを示すSTDOUTエラー・メッセージが表示されます。
推奨アクション
エラー・メッセージがpatchgenエラーの結果として表示されたものであるかどうかを判別します。メッセージ出力でキーワード「patchgen」を検索することにより、エラーの原因がpatchgenであるかどうかを判別できます。次に、patchgenによって生成されたエラー・メッセージの例を示します。キーワード「patchgen」とそれに関連するエラー・コードは太字で示されています。
patchgenエラー・コードに応じて、oerrコマンドを実行し、patchgenで発生した特定の問題の原因とその問題を解決するための推奨アクションを取得します。推奨アクションを実装します。「OERRの実行」を参照してください。
patchgenエラーが発生すると、パッチを維持するかまたはロールバックするかを尋ねられます。デフォルトでは、patchgenはパッチをロールバックします。パッチをロールバックするどうかにより、次のステップでの対策が決定されます。
パッチがロールバックされなかった場合は、patchgenを再度実行します。
エラーが発生した場合でも、パッチ自体はロールバックされていないため、GI/RACホームに残されたままです。
パッチがロールバックされた場合、OPatchAutoはシステム・パッチをRACホームに適用しますが、サブパッチはすべてがGIホームに適用されるわけではありません。この時点で、システム・パッチの一部のみをGIホームに適用する必要があります。
OPatchは、lsinventoryを介して適用されなかったパッチを通知します。特定のサブパッチを適用するには、次の手順に従って手動でパッチを適用する必要があります。
1. スタックを停止します。
2. GIホームでopatch apply (OPatchAutoではない)を実行します。
手動によるパッチ適用の明示的な手順は、パッチのREADMEを参照してください。
例10-3 Patchgenエラー出力
$export ORACLE_HOME=/scratch/GI12/product/12.1.0/crs $/scratch/GI12/product/12.1.0/crs/bin/patchgen commit -pi 13852018 loading the appropriate library for linux java.lang.UnsatisfiedLinkError: /scratch/GI12/product/12.1.0/crs/lib/libpatchgensh12.so (libasmclntsh12.so: cannot open shared object file: No such file or directory)
次の表に、生成される可能性があるpatchgenエラー・コードを示します。
表10-2 Patchgenエラー・コード
| エラー・コード | 原因 | デバッグ情報 |
|---|---|---|
2 |
内部エラー |
一般的な失敗エラー・コード。 |
3 |
内部エラー |
MS Windows: リソース・ファイルの読取りエラー。 |
4 |
内部エラー |
MS Windows: リソース・ファイルの書込みエラー。 |
5 |
内部エラー |
Unix: パッチ・リポジトリを開くのに失敗しました。 |
6 |
内部エラー |
Unix: フルパスlibasmclntshの正規化に失敗しました。 |
7 |
内部エラー |
Unix: パッチ・リポジトリへの書込みに失敗しました。 |
18 |
内部エラー |
PGAの初期化に失敗しました。 |
19 |
内部エラー |
パッチ・イテレータの初期化に失敗しました。 |
40 |
構文エラー。適切なメッセージが表示されます。 |
patchgenの引数がありません。 例: |
41 |
構文エラー。適切なメッセージが表示されます。 |
引数がありません 例: |
42 |
構文エラー。適切なメッセージが表示されます。 |
-pi patchidsが数字ではありません。 例: |
43 |
構文エラー。適切なメッセージが表示されます。 |
-rb patchidsが数字ではありません。 例: |
44 |
構文エラー。適切なメッセージが表示されます。 |
引数
例: |
45 |
構文エラー。適切なメッセージが表示されます。 |
Patchgenが無効な引数を指定して起動されました。 例: |
46 |
libpatchgensh12.soのロードに失敗しました。 |
問題点
OPatchAutoを実行して、4つの製品(Fusion Middlewareなど)ホームを修正しようとしています。このパッチには、データベースを更新するためのビットおよびSQLの両方が含まれています。OPatchAutoを実行すると、次の2つのアクションが実行されます。
GI/RACホームへのビットの適用
SQLの実行(datapatchコマンドを使用)
通常は、GI/RACホームごとにOPatchAutoを実行します。実行するたびに、OPatchAutoはdatapatchを呼び出してパッチSQLを実行します。datapatchは、最初のn-1ノードでは何も実行しません(no-op)。最後(n番目)のノードで、datapatchはパッチSQLの実行を試みます。
datapatchが失敗した場合は、エラー・メッセージが表示されます。エラーの原因がdatapatchであるかどうかを確認するには、OPatchAutoデバッグ・ログを表示します。
症状
SQLPatch/datapatchが失敗したことを示す警告メッセージが表示されます。datapatchが最後のノードへのSQLの適用に失敗した際に、警告メッセージが生成されました。
推奨アクション
通常、警告メッセージは無視でき、最後のノードで手動でdatapatchを実行します。datapatchはデータベースへの接続を確立し、問合せ可能なインベントリ(http://docs.oracle.com/cd/E16655_01/appdev.121/e17602/d_qopatch.htm)を使用して、Oracleホームのバッチ・インベントリに関する情報を取得します。Oracle Databaseへの接続の確立に関する問題は、Oracleエラー・コードによる説明と適切な処置が示されているORA-nnnnnエラーになる可能性があります(http://docs.oracle.com/cd/B28359_01/server.111/b28278/toc.htm)。さらに、問合せ可能なインベントリには、いくつかの予想されるORA-nnnnnがあります。このようなエラーのリストは、http://docs.oracle.com/cd/E16655_01/appdev.121/e17602/d_qopatch.htm#CEGIFCHHで参照することができます。他の問題については、Oracleサポートに連絡してください。
ロール可能なパッチとロール不可能なパッチ: パッチは、ローリング・モードまたは非ローリング・モードのいずれかで適用するように設計されています。パッチがロール可能であるかまたはロール不可能であるかに応じて、対策を決定します。
パッチがロール可能である場合、SQLスクリプトに関してパッチに依存性はありません。データベースを問題なく起動できます。ロール可能なパッチは、ローリング・モードと非ローリング・モードの両方で適用できます。
ただし、パッチがロール不可能である場合は、最初にパッチをロールバックする必要があります。OPatchAutoは、ロール不可能なパッチをローリング・モードでは適用できないようにします。
順序
OPatchAutoが、datapatch/sqlpatchについての警告とともに成功します。
ロール可能なパッチの場合:
ノード1からノード(n-1)までのdatapatchエラーは無視します。
最後のノード(ノードn)で、datapatchを再度実行します。このコマンドはログ・ファイルから切り取って貼り付けることができます。
最後のノードでまだdatapatchエラーが発生する場合は、Oracleサポートに連絡するか、またはサービス・リクエストを開きます。
ロール不可能なパッチの場合:
すべてのノードですべてのデータベースとスタックを手動で停止します。
それぞれのノードでopatchauto applyを実行します。
スタックとデータベースを起動します。datapatchが接続してSQLを適用するために、データベースを起動する必要があります。
最後のノードで、datapatchを手動で実行します。datapatchを実行しないと、パッチのSQLが適用されず、不具合修正の効果がありません。さらに、SQLを実装するための変更内容によっては、システムの動作が不正確になる場合があります。
まだdatapatchが失敗する場合は、パッチをロールバックする必要があります。Oracleサポートに連絡して支援を要請するか、またはサービス・リクエストを開きます。
OPatchAutoは、OPatchAutoの操作とパッチの適用にかかわる問題を診断するための複数の機会を提供します。
関連項目: 詳細は、「OPatchAutoのトラブルシューティング」を参照してください。
OPatchAutoとパッチ適用プロセスにかかわる操作上の問題を診断する際に役立つ情報を提供する複数のログ・ファイルがあります。必要な診断情報(パッチとシステム構成の詳細など)がログ・ファイルに含まれるようにするには、OPatchAutoをデバッグ・モードで実行します。
次の手順では、一般的なトラブルシューティング・プロセスの詳細を示します。
ログ・ファイルを調べます。
ローカル・ノードのログ・ファイル
ログ・ファイルは、OPatchAutoを実行したORACLE_HOMEにあります。
場所: <ORACLE_HOME>/cfgtoollogs/opatchauto
リモート・ノードのログ・ファイル
ログ・ファイルは、リモート・ノードの<ORACLE_HOME>にあります。
場所: <リモート・ノードのORACLE_HOME>/cfgtoollogs/opatchauto
リモート・ノードの<ORACLE_HOME>の情報は、ローカル・ノードのメイン・ログ・ファイルにあります。
ローカル・コンソールとメイン・ログ・ファイルにもリモート・ノードに関するログ情報が含まれています。コンソールからは、ローカルとリモートの両方のノードに関する特定のログ・ファイル情報を利用できます。ただし、詳細なログ情報を表示するには、ローカルとリモートのログ・ファイルを直接確認する必要があります。
障害が発生している場合、その問題を詳細に把握するために推奨される手順。
障害が発生した場合は、ログを確認して、パッチ適用オーケストレーションが失敗した理由を調べます。問題の解決後に、パッチ適用オーケストレーションを再開できます。
リモート・ノードでパッチがステージングされている場所を調べます。
パッチは、リモート・ノードの次の場所に一時的にコピーされます。
<ORACLE_HOME>/OPatch/auto/dbtmp/<patch_id>/
OPatchAutoは、システム構成ログを生成します。その場所がコンソールに表示されます。
次に例を示します。
<ORACLE_HOME>/cfgtoollogs/opatchautodb/systemconfig*<timestamp>.log
このログには、ブートストラップ、GI/SIHAの識別、ローカル・ノード上のユーザー資格証明チェックなど、パッチ実行アクティビティの開始前のOPatchAutoフローの詳細がすべて含まれています。
OPatchAutoは、SRVCTL、ROOTCRSのようなグリッド・ユーティリティ、OPatchなどの他のコンポーネントと相互作用してパッチを適用します。障害は、これらのコンポーネントで発生することもあります。問題が発生している場所を特定するために、コンポーネントごとに次の基本チェックを実行できます。
SRVCTL: 情報の取得やデータベース・ホームの状態の変更のために提供されているユーティリティです。これは、OPatchAutoがいくつかの操作(ホームの停止、ホームの開始、ホームのステータス、インスタンスの再配置など)を実行するために使用します。opatchautoが、どの操作を実行しようとしているかは、opatchautoのログで調べることができます。現在、この領域でなんらかの失敗がある場合は、直接srvctlを使用してデータベース・ホームのステータスを確認できます。
opatchautoがデバッグ・モードで実行されていると、srvctlの失敗したコマンドのログが次の場所で利用可能になります。このログは、失敗の理由を見つけるために分析できます。失敗の理由がシステム構成に関連している場合は、opatchautoを使用する前に修正する必要があります。
/tmp/liveoutput_hostname.trc
Grid/SIHAホーム・ユーティリティ: OPatchAutoは、パッチ適用の前後にGI/SIHAホームを停止および開始するためにrootcrs.pl/roothas.plを使用します。このユーティリティは、システム構成またはパッチによっては一部のシナリオで失敗します。このユーティリティによって生成されるログは、次の場所にあります。
<GIHome>/cfgtoollogs/crsconfig/crspatch*<timestamp>.log (GIバージョン< 12.2)
<OracleBase>/crsdata/<host>/crsconfig/crspatch*<timestamp>.log (GIバージョン>= 12.2)
<OracleBase>/diag/ (GIバージョン>= 12.2)
このログを開いて失敗の理由を確認できます。その理由について詳しく知らない場合は、インターネット経由で考えられる原因や修正方法を検索できます。それでも問題が解決できない場合は、開発チームに詳細な調査を依頼してください。問題について最初に実行した分析の詳細とともに、すべてのログ・ファイルを必ず添付してください。これは、事前通知することで開発チームの時間の節約になります。
OPatchCore: OPatchAutoは適用/ロールバックのためにopatchのコアAPIを使用します。これらのAPIの実行に関するログは次の場所にあります。
<ORACLE_HOME>/cfgtoollogs/opatchauto/opatchauto_<timestamp>_binary.log
<ORACLE_HOME>/cfgtoollogs/opatchauto/core/opatch/opatch<timestamp>.log
パッチの適用が正しく実行されたかどうかを確認できます。
パッチ適用の手順がローカルとリモートのどちらか(あるいは両方)のノードで実行されたことを検証します。
パッチの適用がローカル・ノード上で実行された場合、コンソールからホスト情報を利用できません。
パッチの適用がリモート・ノード上で実行された場合、コンソールからホスト情報を利用できます。
パッチがローリング・モードで実行されたことを検証します。
パッチがローリング・モードで適用されたことをコンソールから直接検証できます。ローリング・モードでパッチが適用されるときには、次の順序のフェーズが発生します。
初期化フェーズのみ: ローカルとリモートの両方のノードで完了されます。
停止
オフライン
起動
オンライン
ファイナライズ
これらすべてのフェーズは、ローカル・ノード上でエンドツーエンドに実行されてからリモート・ノードに進みます。
複数ノード環境では、これらすべてのフェーズが特定のノードでエンドツーエンドに実行されてから、その次のノードに進みます。
パッチが非ローリング・モードで実行されたことを検証します。
パッチが非ローリング・モードで適用されたことをコンソールから直接検証できます。非ローリング・モードでパッチが適用されるときには、次の順序のフェーズが発生します。
初期化フェーズのみ: ローカルとリモートの両方のノードで完了されます。
停止
オフライン
起動
オンライン
ファイナライズ
Oracle Databaseリリース11.2の場合、各フェーズがすべてのノードで並行して実行されます。
Oracle Databaseリリース12.0以降の場合、すべてのフェーズが最初にローカル・ノード上でエンドツーエンドに完了されます。その後で、各フェーズがn-2個のノードで並行して実行されます(nは、クラスタ内のノード数になります)。n番目のノードでは、すべてのフェーズがエンドツーエンドに完了されます。
パッチが適用またはロールバックされたことを検証します。
GRIDホームとRACホームの両方は、パッチの適用/ロールバックの前後で同じ状態になっている必要があります。
GRIDホームとRACホームの現在のステータスを確認するには、次のコマンドを実行します。
crsctl check status crs
srvctl status database -d <database>
"opatch lsinv"コマンドを使用すると、ユーザーはシステムで使用可能なパッチを確認できます。
問題: OPatchAutoを使用して12.1.0.2.0 GI/RACにOCT/JAN PSUでパッチを適用したとき、または12.1.0.2 PSUの複数回の適用/ロールバックの後で、rootcrs postpatch時にohasdの障害が発生します。
解決策: <crs_home>/./crs/sbs/crswrap.sh.sbsで次の変更を実行します。
この問題を解決するには、ohasdスクリプトで2つの行を変更します。
UID=`/usr/xpg4/bin/id -u` # Check for root privilege if [ $UID -eq 0 ];
ローカル変数としてUIDを使用するかわりに、別のもの(たとえばUID1)を使用してください。これにより、次の問題を防止できます。
bash-3.2# ./ohasd restart
./ohasd: line 279: UID: readonly variable
次のパッチ適用シナリオは、パッチ適用中に発生する可能性のある既知の問題の例です。
次の問題は、rootcrs.plの実行に関連しています。
問題点
-norestartオプションが指定されていると、rootcrs.pl -postpatchでopatchauto rollbackが失敗します。
症状
10月のPSUパッチのロールバック時に、-norestartモードでのOPatchAutoの実行がrootcrs.pl -postpatchステップで失敗します。
例10-4 コンソール出力
Starting CRS ... Failed Command "/usr/bin/perl /scratch/GI12/app/12.1.0/grid/crs/install/rootcrs.pl -postpatch -norestart" execution failed: Died at /scratch/GI12/app/12.1.0/grid/crs/install/crspatch.pm line 851.
推奨アクション:
前提条件である個別パッチが必須です。
問題点
リーフ・ノードのスタックが稼働していない場合、フレックス・クラスタのリーフ・ノードのopatchautoが失敗します。
症状
スタックがクラスタで稼働していない場合、フレックス・クラスタのリーフ・ノードでのOPatchAutoの実行が失敗します。これは、ローリング・モードおよび非ローリング・モードの両方のパッチ適用で発生します。次の例で示されるコンソール・メッセージとともにrootcrs.pl -prepatchが失敗します。
例10-5 コンソール出力
Using configuration parameter file: crs/install/crsconfig_params 2013/09/27 06:00:01 CLSRSC-455: Failed attempt to initiate patch on a Leaf node
推奨アクション:
パッチ適用の前に、リーフ・ノードのスタックを起動します。
次の問題は、datapatchの実行に関連しています。
問題点
opatchauto rollbackの実行中、最初のノードそのものでSQLの変更がロールバックされます。
症状
SQLの変更は最初のノードからロールバックされます。
例10-6 ログ・ファイル出力
Output from the command: 2013-10-07_05-16-28 : SQL Patching tool version 12.1.0.1.0 on Mon Oct 7 05:15:31 2013 Copyright (c) 2012, Oracle. All rights reserved. . Connecting to database...OK Determining current state...done The following patches will be rolled back: 17027533
推奨アクション
パッチがすべてのノードからロールバックされる場合は、メッセージを無視します。回避策はありません。
次の問題は、OPatchの実行に関連しています。
opatch napplyの失敗問題点
アクティブ・ファイルが原因で、CRSホームでのopatch napplyステップ時にOPatchAutoが失敗します。
症状
Gridホームのパッチ適用時にOpatchautoが失敗します。
例10-7 ログ・メッセージ
[Sep 19, 2013 6:52:14 PM] Following executables are active :
/u01/app/12.1.0/grid/lib/libclntsh.so.12.1
[Sep 19, 2013 6:52:14 PM] Prerequisite check
"CheckActiveFilesAndExecutables" failed.
推奨アクション
少し時間を置いてから、opatchauto resumeを実行します。
問題: OPatchAutoがDB PSUのロールバックに失敗します。
症状: ロールバックで次のエラーが発生します: [Apr 4, 2017 2:30:09 PM] [SEVERE] OUI-67073:UtilSession failed: Following patch(es) are inactive and cannot be rolled back.
April 2017 DB PSUと、すべてのオーバーレイに必須のパッチを適用します
July 2017 DB PSUを適用します
手順: July 2017 DB PSUをロールバックする
事前条件: 非アクティブのパッチはロールバックできないためOPatchエラーが発生する
解決策: これはDB Oct PSUのOPatch 12.2.0.1.10で修正されています。opatchをアップグレードしてコマンドを再実行してください。
次の問題は、OPatchAutoの実行に関連しています。
次の問題は、OPatchAutoバージョン12.1.0.1.5のみに関連しています。
問題: OPatchAutoでは、ソフトウェアのみのホームはサポートされません。
症状: config.shが次のエラー・メッセージで失敗します。
kfod.bin: cannot execute: No such file or directory
推奨アクション: パッチREADMEの指示に従って、パッチを手動で適用します。
問題: OPatchAutoが共有ホームを見つけられないためエラーが発生します。これは共有ホームと非共有ホームのどちらでも発生することがあります。
症状: OPatchAutoによって次のエラーが生成されます。
System Configuration Collection failed: oracle.osysmodel.driver.crs.productdriver.ProductDriverException: Unable to determine if "ORACLE HOME" is a shared oracle home.
推奨アクション: OracleホームでROOTとして次のコマンド(以下の例)を実行して、根底にある問題を判別します。コマンドは、opatchautoが実行されたのと同じ場所で実行してください。
RACホームの場合:
su <RAC OWNER> -c "$GRID_HOME/bin/cluvfy comp ssa -t software -s
$DB_HOME -n $NODELIST -display_status"
GRIDホームの場合:
su <GRID OWNER> -c "$GRID_HOME/bin/cluvfy comp ssa -t software -s
$GRID_HOME/crs/install -n $NODELIST -display_status"
例:
su <GRID OWNER> -c "$GRID_HOME/bin/cluvfy comp ssa -t software -s
$GRID_HOME/crs/install -n node1,node2,node3 -display_status"
根底にある問題が解決してから、opatchautoを再び実行します。
問題: OPatchAutoがRAC Oneデータベースのステータスを検出できません。このため、データベースにSQLの変更を適用できません。
症状: OPatchAutoによってコンソールに次のメッセージが表示されます。
[WARNING] The local database instance 'INST' from 'RAC_HOME' is not running. SQL changes, if any, will not be applied.
推奨アクション: RAC Oneデータベースに対してdatapatchコマンドを手動で実行します。正確なコマンドはopatchautoログ・ファイルに表示されます。
問題: OPatchAutoを-norestartモードで実行した場合にも、メッセージ「Starting CRS ... Successful」が表示されます。
症状: OPatchAutoによってコンソールにこのメッセージが表示されます。
Starting CRS ... Successful
推奨アクション: メッセージを無視します。OPatchAutoによって必要な処理が実行されます。実際にはCRSは起動されません。
問題: 既存のパッチのサブセットである個別パッチがシステム・パッチに含まれる場合、OPatchAutoはそのシステム・パッチを適用できません。
症状: コマンドopatch prereq CheckConflictAgainstOHが失敗したと報告されます。
推奨アクション: ホームでスーパーセット・パッチをロールバックし、システム・パッチを適用してから、スーパーセット・パッチを再び適用します。
問題点
opatchauto applyまたはopatchauto rollbackの実行によって、datapatchがすべてのノードで実行されます。
症状
パッチを適用する最初のノードで、RACデータベースがそのノードで構成されている場合、例10-8に示すメッセージが表示されます。
例10-8 コンソール出力
SQL changes, if any, are applied successfully on the following database(s):
推奨アクション
このメッセージは無視してかまいません。datapatchステップによって行われるSQLの変更の詳細は、OPatchAutoデバッグ・ログから取得できます。datapatchが、以前のパッチ適用セッションで保留になったSQL変更を適用していた可能性もあります。
問題点
opatchauto resume -rebootでdatapatchステップが実行されません。
症状
opatchauto resume -rebootコマンドで、datapatchステップが実行されません。
推奨アクション
datapatchステップは、いずれのノードからも手動で実行できます。保留中のすべての変更も、次のOPatchAutoセッションのdatapatchコマンドによって実行されます。
環境変数ORACLE_HOMEおよびORACLE_SIDを設定し、次のコマンドを実行します。
$ORACLE_HOME/OPatch/datapatch
問題点
opatchautoコマンドが、コンソールにエラー・メッセージやスタック・トレースも出力せずに失敗します。
症状
コンソールおよびログ・ファイルには次のメッセージが表示されます。
例10-9 コンソール出力
Starting CRS ... Failed
例10-10 ログ・メッセージ
Failed to run this command : /usr/bin/perl $GRID_HOME/crs/install/rootcrs.pl -postpatch Executing command: $RAC_HOME/bin/srvctl start home …
推奨アクション
次の場所にあるcrspatchログ・ファイルを参照し、タイムスタンプがOPatchAutoの実行時間を指していることを確認します。
$GRID_HOME/cfgtoollogs/crsconfig/crspatch_<hostname>_<timestamp>.log
このファイルに「CLSRSC-400: インストールを続行するにはシステムの再起動が必要です。」というメッセージが含まれる場合は、次の手順に従います。
マシンを再起動します。
次のコマンドを実行します。
opatchauto resume -reboot
