oracle installer インベントリに関する運用の理解と...

Oracle Installerインベントリに関する運用の理解と自動化

オラクル・ホワイト・ペーパー 2005年


概要 ...................................................................................................................... 3 はじめに .............................................................................................................. 3 OUIインベントリの構造 .................................................................................. 4 中央インベントリ・ポインタ ..................................................................... 4 中央インベントリ......................................................................................... 5 ローカル・インベントリ ............................................................................. 6

ゴールド・イメージ ORACLE_HOMEのクローニング ............................... 6 ORACLE_HOMEのインベントリへのアタッチ ............................................ 8 インベントリ・メンテナンス操作................................................................... 9 インベントリ破損の診断とリカバリ ......................................................... 9 CRSおよび RACの場合の特別な OUI操作 ............................................. 9 クラスタ内のノードの検出 ....................................................................... 10 インストール後妥当性チェック ............................................................... 11 ORACLE_HOMEのインベントリにおけるノード一覧の更新............. 11 CRSインストール後のインベントリ問題のトラブルシューティング12

ワンオフ・パッチ適用とインベントリ・インタラクト ............................. 13 OPatch 10.1 RAC検出................................................................................. 13 パッチ適用を正しく実行する必要条件 ................................................... 13 システムの必要条件 ............................................................................. 13 OUIの必要条件 ..................................................................................... 14 RACの必要条件（RACのみに適用可能） ....................................... 15

結論 .................................................................................................................... 16

Oracle Installer インベントリに関する運用の理解と自動化

2

Oracle Corporation 発行「Understanding and Automating Operations Around the Oracle Installer Inventory」の翻訳版です。


概要

DBAが Oracleソフトウェアをインストールしてパッチする適用方法は、年月とと

もに大きく変化してきました。従来の GUIによるインストール方法は、クローニ

ングのようなより高速でスケーラブルな方法に変わりました。一方、パッチ適用

は、シンプルなビット・パッチ適用からさらに複雑な形式へ進化しています。こ

のような操作の後には、必ず適切なインベントリ・エントリが続き、ソフトウェ

アのライフサイクル全体にわたる管理ができます。

ライフサイクル全体の管理におけるインベントリの重要性が高いため、インベン

トリの精度を維持した保守もさらに重要となっています。このドキュメントでは、

インベントリでのクローニングやパッチ適用などの操作を積極的に取り入れる方

法を説明して一般的なプラクティスに統合するスクリプト化したアプローチを明

らかにします。

はじめに

Oracle 9.2以降、Oracleソフトウェアのインストールを追跡するために、XMLベー

スの Oracle Universal Installerインベントリ（以後、OUIインベントリと表記）が

導入されました。通常の Oracleインストールは、このインベントリを読み込み更

新します。このドキュメントでは、インベントリの構造について説明します。ま

た、通常のインストールの域を超えて、すべての重要なインベントリとインタラ

クトするクローニングやパッチ適用などの操作も説明します。範囲については、

OUI 10.1に限定しますが、以前のバージョンも参照します。


3


OUI インベントリの構造

OUIインベントリの構造は、中央インベントリ・ポインタ、中央インベントリお

よびローカル・インベントリからなる階層です。

中央インベントリ・ポインタ

インベントリは、ホスト上の各 ORACLE_HOMEに関するソフトウェア関連情報

のサテライトです。

各環境には、ORACLE_HOMEが登録された関連中央インベントリと、コンポーネ

ントおよび適用済み暫定パッチの一覧を持つ ORACLE_HOME内のローカル・イ

ンベントリがあります。中央インベントリは、Inventory Pointer Locationファイル

と呼ばれるファイルのコンテンツが指定したディレクトリに置かれます。この

ファイルは、通常、Solarisでは/var/opt/oracle/oraInst.locとして、Linuxでは

/etc/oraInst.locとして存在しますが、インストール時に-invPtrLoc引数を使用した

指定も可能です。Windowsでは、ポインタはレジストリ・キー

＼＼＼＼HKEY_LOCAL_MACHINE＼＼Software＼＼Oracle＼＼inst_locの値が指

定した位置にあります。

実際には複数の中央インベントリを使用するため、通常アプリケーション・サー

ビス・プロバイダ（ASP）でのホストされた環境では、単一マシン上に複数の中

央インベントリ・ポインタが存在します。ホストされたモデルでは、各ホストが

異なる組織に対してアプリケーションを持ちます。「適切にパブリッシュ」され

た中央インベントリで発生する明白なセキュリティ問題以外にも、これらの各組

織は異なる運用プラクティスを持つ場合があります。さらに、パッチ適用やアッ

プグレードなどのライフサイクル操作のため、中央インベントリに対する排他的

アクセスが必要なこともあります。

ただし、管理を容易にするために単一のデフォルト中央インベントリの使用をお

薦めします。CRSや RACの一部の製品では、Metalinkノート 263151.1に記載さ

れているように、これが必須要件です。

図 1: Oracleソフトウェア・コンポーネント検索のためのパス・ダイアグラム


4


中央インベントリ

中央インベントリには、ホストにインストールされた ORACLE_HOMESのセット

の一覧が表示されます。各中央インベントリは、一覧の入った inventory.xmlと呼

ばれるファイルで構成されます。以下に、RDBMS 9i、RDBMS 10gおよび Enterprise

Manager Grid Controlがインストールされたホスト用の inventory.xmlファイルから

の引用を示します。

<?xml version="1.0" standalone="yes" ?>





<INVENTORY>

<VERSION_INFO>

<SAVED_WITH>10.1.0.2.0</SAVED_WITH>

<MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>

</VERSION_INFO>

<HOME_LIST>

<HOMENAME="DB NINE" LOC=" /private/oracle_homes/9iR2"

TYPE="O" IDX="1"/>

<HOME NAME="EM_HOME" LOC="/private/oracle_homes/EM"

TYPE="O" IDX="2"/>

<HOME NAME="TEN_HOME" LOC="/private/oracle_homes/10g"

TYPE="O" IDX="3"/>

</HOME LIST>

</INVENTORY>

各「インストール・セット」には、他の「インストール・セット」には知られて

いない独自の中央インベントリ・ポインタ・ファイルがあります。パッチ適用、

アップグレードおよびインストールなどの操作では、コマンドライン引数

invPtrLocにより、デフォルト以外の中央インベントリ・ポインタ位置をサポート

します。Oracle Database 10g以降では、中央インベントリ・ポインタ位置ファイル

のコピーが ORACLE_HOME内に保持されます。前述のファイルは、インストー

ル、アップグレード・パッチ適用および Enterprise Managerコレクションに影響を

及ぼす可能性があるため、いずれも削除しないことを強くお薦めします。

インベントリにおけるすべての読取りおよび書込み操作は、Oracle Universal

Installerコンポーネントにより実行されます。現在、中央インベントリ上の操作は、

ロッキング・メカニズムによりシリアル化されています。これは、同じ中央イン

ベントリを共有する他の ORACLE_HOMEでは、ORACLE_HOMEでインストール、

アップグレードあるいはパッチ適用などの操作がブロックされることを意味しま

す。ただしパッチ適用の場合、このようなロック期間が非常に短いため、他の

ORACLE_HOMEでのパッチ適用操作は、インベントリへのアクセスをシンプルな

待機および再試行メカニズムで試行します。10g R1では、パッチ適用プロセスは

30秒ごとに起動してインベントリ・ロックの取得を試行します。これは 10回ま

で試行されます。待機および再試行メカニズムにより、同じ中央インベントリを

使用する複数の ORACLE_HOMEで同時にパッチ適用されます。再試行と待機の

インターバルは、opatchコマンドラインから指定できます。


5

ローカル・インベントリ

ローカル・インベントリは、各 ORACLE_HOMEの'inventory'サブディレクトリ内

にあります。このインベントリには、ORACLE_HOMEにインストールされたパッ

チセットや暫定パッチだけでなく、すべてのコンポーネントを含む comps.xmlと

呼ばれるファイルがあります。また、異なる Javaベースの Oracleツールおよびコ

ンポーネントが必要とする Java Runtime Environment（JRE）など、Oracle以外の

コンポーネントに関する詳細情報もあります。OUI 2.1以降では、インベントリ内

の情報は Extensible Markup Language（XML）フォーマットで格納されます。XML

フォーマットにより、インベントリに関連する問題をより容易に診断できます。

セキュアな情報は、インベントリに直接格納されません。このため、一部の製品

ではアンインストール時にパスワードなどの必要情報が求められます。パッチ適

用中、これらのコンポーネントは APIを通じてパッチ・エンジンにより呼び出さ

れ、適切な互換性および競合チェックが実行され、パッチが正しく適用されると、

最後にインベントリが暫定パッチ情報で更新されます。

以下の項では、次の点について説明します。

1. インベントリとインタラクトする各種 OUI操作（通常のインストールで

の操作以外）

2. インベントリをリカバリする様々な方法

3. OUIを介したインベントリとインタラクトするワンオフ・パッチ適用操

作

注意: 10g OUI以前、OUIと JREは ORACLE-HOME以外のコンポーネントに

使用され、製品の ORACLE_HOMEの外部にあるそれぞれの独立した位置に

置かれていました。10g OUI以前の環境での JREと OUIの位置は、OUIを呼

び出し"Installed Products"をクリックして調べます。これらの位置は、中央イ

ンベントリに登録されています。

10gでの JREと OUIは、製品の ORACLE_HOMEに移され、ORACLE_HOME

を自己完結型にして、クローニングなどの操作をサポートします。

ゴールド・イメージ ORACLE_HOME のクローニング

ソフトウェアを多数のホストに配置する一般的方法は、「ゴールド・イメージ」

を使用した配置です。ゴールド・イメージとは、ビットが「tarballされた」、つ

まり圧縮されたイメージのことです。10g R1での操作は、ソフトウェアのライフ

サイクル管理全体がインベントリで中央化されているため、必ずこのインベント

リを認識する方法で行われます。これが、Oracleが OUIユーティリティを強化し、

tarballクローニングの場合にインベントリ変更を行う理由です。

ORACLE_HOMEクローニング操作は、次の手順となります。

ソース・ホストにおいて、好みの方法で ORACLE_HOMEのバックアップを取り

ます。zip、tar、cpioなど、任意の方法が使用できます。


6


1. バックアップ・アーカイブを宛先に転送します。宛先 ORACLE_HOME

が同じホスト上にある場合、コピー操作のように簡単です。

2. ターゲット・ホスト上のソフトウェアを、ORACLE_HOMEとなるディレ

クトリにリストアします。

3. 操作全体をバッチ対応にするためには、サイレント・モードを使用しま

す。利点を最大限に活用するため、サイレント・モードでクローニング

を実行して、この操作を他の配置操作と一緒にスクリプト化します。

クローン・モードで Oracle Universal Installerを実行する構文を次に示します。

RunInstaller -clone -silent

ORACLE_HOME="/u01/oracle/product/10.1.0/10gl"

ORACLE_HOME NAME="db_10gl"

中央インベントリ・ポインタの位置として、デフォルト以外の位置仕様も使用で

きます。ゴールド・イメージのクローニングは、

多数のホストにイメージを配置する方法

の 1 つです。OUI クローニング操作は数

分で完了します。 runInstaller -clone -silent -invPtrLoc /home/oracle/oraInst.loc

ORACLE_HOME="/home/oracle/product/10.1.0/db-10gl"

ORACLE_HOME_NAME="db-10gl"

OUIプロセスは、クローン・モードで実行した場合、次の主要フェーズで構成さ

れます。

1. クローニング操作は、通常のインストールと同じ必要条件と妥当性の

チェックを実行します。たとえば、ORACLE_HOMEがインベントリに既

存する場合、操作はエラーとなります。ただし、OUIをスキップ可能で

製品コンポーネント固有の必要条件が、"-ignoreSysPrereqs"フラグと

"-ignorePreReq"フラグを個々に使用してチェックします。決して推奨でき

る方法ではありませんが、必要条件をスキップすると、すでに妥当性

チェック済みのホストでの配置に便利となります。

2. OUIは、新しい ORACLE_HOMEディレクトリ・パスにより、いくつか

のファイルをセットアップします。

3. Unixでの OUIは、通常の設定が必要ではないインストールの場合と同様、

実行ファイルを再リンクします。

4. OUIは、インベントリ・ポインタ oraInst.locファイルが指定した位置に中

央インベントリをセットアップします。中央インベントリが既存する場

合は、単に新しい ORACLE_HOMEを中央インベントリに登録します。

5. Windowsでの OUIはレジストリもセットアップし、プログラム・グルー

プをセットアップします。

スクリプトからクローニング操作を実行し、dbcaや netcaなどの構成ツールでそ

れを追跡できます。なお、これらのツールはサイレント・モードで実行できます。

クローニング操作は、root.shを実行しません。root.shは、フレッシュ・インストー

ル中と同様にスーパーユーザーとして手動での実行が必要となります。これは、

Unixの場合にのみ適用されます。


7


現在のところ、OUIを使用したクローニング操作は、CRSと RAC 10.1

ORACLE_HOMEをサポートしません。

ORACLE_HOME のインベントリへのアタッチ

単に中央インベントリのセットアップだけ、または物理的に存在する

ORACLE_HOMEを中央インベントリに登録したいときもあります。そのために、

OUIにはORACLE_HOMEを簡単にアタッチするオプションが用意されています。

1. 物理パスがソースと同じでライブラリ互換である ORACLE_HOMEに配

置されたゴールド・イメージを登録することで、再リンク操作が必要あ

りません。（注意: 再リンク操作は、既存の実行ファイルを"pre root.sh"

権限で上書きするため、その場合は root.shの実行が必要となります。し

たがって、root.shをターゲットで実行したくない場合は、単に

ORACLE_HOMEを登録して再リンク操作のスキップをお薦めします。）

ORACLE_HOME のアタッチは、ソース

環境とターゲット環境が同一の場合に意

味があります。これは、クローニングよ

りはるかに高速です。

2. Windowsでのクローニングは再リンク以上のことを行うため、'attachhome'

操作の代わりに OUIベースのクローニングが必要となります。

3. 何らかの理由で中央インベントリが失われた場合、中央インベントリを

再作成して ORACLE_HOMEを登録します。

ORACLE_HOMEをアタッチする構文を次に示します。

/home/oracle/product/10.1.0/db10g/bin/runInstaller -silent -

attachHome ORACLE_HOME="/home/oracle/product/10.1.0/db10g"

ORACLE_HOME_NAME="OraDBHome"

この場合も、他の runInstallerオプションと組み合せて使用できます。

/home/oracle/product/10.1.0/db10g/bin/runInstaller -silent -

attachHome -invPtrLoc /home/oracle/oraInst.loc

ORACLE_HOME="/home/oracle/product/10.1.0/db10g"

ORACLE_HOME_NAME="OraDBHome"

10.1.0.3以前の OUIは、attachhome操作中に中央インベントリを再作成しません。

中央インベントリが既存する場合は、単に ORACLE_HOMEをアタッチします（中

央インベントリは同じプラットフォームを持つ他のマシンからコピーできます）。

10.1.0.3以降では、中央インベントリがまだ存在しない場合、OUIは、oraInst.loc

ファイルにより指定された位置に中央インベントリを作成します。

ORACLE_HOMEをクローニングまたはアタッチした後、<central inventory>/logs

ディレクトリにあるログの表示により、成功または失敗が調べられます。また、

ORACLE_HOMEが実際に登録済みの場合は、<central

inventory>/ContentsXML/inventory.xmlファイルのもとにある inventory.xmlファイ

ルを表示して確認できます。


8


インベントリ・メンテナンス操作

インベントリの重要性を理解したところで RAC環境と非 RAC環境とにおける

バックアップ、リカバリ、健全性テストなどのインベントリ・メンテナンス操作

について説明します。

インベントリ破損の診断とリカバリ

'opatch lsinventory -detail'の実行時に、またはユーザーが"Installed Products"をクリッ

クした時に ORACLE_HOMEが表示されない場合、ORACLE_HOMEが中央インベ

ントリから消失しているか、中央インベントリ自体が消失または破損している可

能性があります。

インベントリは、ライフサイクル管理に

重要です。したがって、リカバリ方針を

知り、理解することが重要となります。

ユーザーが'opatch lsinventory-detail'を実行したときに ORACLE_HOMEがリストさ

れ、およびユーザーが"Installed Products"をクリックしたときに ORACLE_HOME

が表示されても、さらにドリルダウンによりORACLE_HOME内の製品とコンポー

ネントがリストしない場合は、ORACLE_HOME内のインベントリ（ローカル・イ

ンベントリと呼ばれる）の消失または破損が考えられます。

何らかの理由で中央インベントリが破損または消失した場合、バックアップがあ

れば中央インベントリを簡単にリストアできます。または、複数の

ORACLE_HOMEで OUI attachome操作を繰り返すことにより、中央インベントリ

全体をリストアできます。

ローカル・インベントリが破損している場合は、バックアップがあれば

ORACLE_HOME/inventoryを簡単にリストアできます。バックアップが存在しな

い場合は、同じプラットフォームを持つ別のノードでソフトウェアをインストー

ルし、暫定修正情報を含む同じパッチレベルのインストールが必要となります。

その後、「パッチ適用済み」の ORACLE_HOMEから影響する ORACLE_HOME

の位置にインベントリ・ディレクトリを簡単にコピーできます。

アップグレードやパッチ適用操作の前には、ORACLE_HOMEのバックアップを強

くお薦めします。ORACLE_HOMEのインストール時またはアンインストール時に

も、中央インベントリをバックアップしてください。バージョン 1.0.0.0.51以降で

は、opatchはパッチ適用の前にローカル・インベントリ内の comps.xmlファイル

をバックアップします。

データベース・バージョン 9.2を使用している場合、OUIの以前のバージョン

（2.2.0.12.0）ではバグからのインベントリ破損が報告されていました。これを回避

または修正する推奨方法は、Metalink Note 229773.1に記載されています。

CRS および RAC の場合の特別な OUI 操作

10g CRSクラスタでの中央インベントリは、ORACLE_HOMEだけでなく

ORACLE_HOMEが拡張するノードの一覧も格納しているため、さらに重要となり

ます。これがCRS-RAC環境におけるOUIに次の必要条件が課せられる理由です。

すべてのノードのインベントリは一貫性のある状態が要求されます。すなわち、

ノードがクリーンであるか（Oracleソフトウェアがない）、またはインベントリ

が既存する Oracleソフトウェアの反映が必要なことを意味します。


9


クリーンなマシンとは、次を意味します。

Linuxでは、/etc/oralnst.loc and $HOME/oraInventoryが存在しないこと。

Windowsでは、レジストリ・キー

My Computer＼HKEY_LOCAL_MACHINE＼Software＼Oracle＼inst_loc

およびディレクトリ"c:＼program files＼oracle＼inventory"が存在しないこと。

ノードがクリーンでない場合、インストール済み製品の一覧を含む有効なインベ

ントリを持つ必要があります。この確認には、そのノードで OUIを起動して

"Installed Products"をクリックするか、製品 ORACLE_HOMEのいずれから'opatch

lsinventory'を実行します（opatchは 10.10.2以降の製品に含まれています）。イン

ベントリ・ダイアログ画面には、すべての ORACLE_HOME、製品、コンポーネン

トおよびその ORACLE_HOMEがインストールされたノードの一覧が表示されま

す。

CRS-RAC 環境におけるインベントリに

は ORACLE_HOME と関連したノードの

一覧も含みます。アップグレードやパッ

チ適用の際、インベントリはノードの一

覧が正しく移入済みなことが重要です。

RAC環境では、CRSインストール後の妥当性チェックが済んでいます。

CRSと RACは、10g R1で同じ中央インベントリを共有する点に注意してくださ

い。これは、Metalink Note 263151.1で説明しています。

クラスタ内のノードの検出

ノードの一覧でインベントリを更新する前に、インストーラはノードの一覧を探

し出す必要があります。そのためには、製品の oraparm.iniファイルに指定された

CRSまたはベンダー・クラスタウェアのいずれかまたは両方を利用します。製品

インストール CDの oraparm.iniには、次に示す行のいずれかまたは両方がありま

す。

CLUSTERWARE={"oracle.crs","10.1.0.2.0"}

VENDORCLUSTERWARE=TRUE

CRSクラスタウェアの場合、インストーラは CRS ORACLE_HOMEから"olsnodes"

実行ファイルを呼び出して、ノードの一覧を探します。ベンダー・クラスタウェ

アの場合は、OUI自体にパッケージされた"lsnodes"実行ファイルを実行します。

両方が指定されている場合、インストーラは CRS、ベンダー・クラスタウェアの

順に使用してノードの一覧を探します。

既存の ORACLE_HOME上にインストールした場合（たとえば、Companion CD

install for 10.1）、インストーラ・セッションは中央インベントリ自体からノード

の一覧を検出します。ノード一覧が検出されない場合、「CRSインストール後の

インベントリ問題のトラブルシューティング」の項で説明したように、インベン

トリのコンテンツを調べる必要があります。

クラスタ検出に関する上記のアルゴリズムは 10.1で有効であり、今後のリリース

では変更の可能性があるため十分に注意してください。


10


インストール後妥当性チェック

各ノードにおいては、OH/Opatchへ移動して'opatch lsinventory -detail'を実行するか、

単に OUIを実行して"Installed Products"をクリックします。ORACLE_HOME内に

インストールされたコンポーネントの一覧と、その ORACLE_HOMEのローカル・

ノードおよびリモート・ノードの一覧も表示されます。この情報を妥当性チェッ

クします。また、インストール・ログと inventory.xmlを調べることも可能です。

チェックに失敗した場合の手順については、トラブルシューティングの項も参照

してください。この情報を妥当性チェックするもう 1つの方法は、新しくインス

トールされた ORACLE_HOME内部で OUIを起動して"Installed Products"をクリッ

クします。

ORACLE_HOME のインベントリにおけるノード一覧の更新

10gクラスタ環境では、OUIの'updateNodelist'フラグを使用して、ORACLE_HOME

に対応するノード一覧が更新できます。ノード一覧が正しい場合、そのノードで

のインストーラ操作により、一覧にあるノードにビットが伝播されます。

ノードでは、次のように updateNodeListを実行します。

OH/oui/bin/<runInstaller or setup.exe> -updateNodeList

ORACLE_HOME=<oracle home location> CLUSTER_NODES=<comma

separated nodelist e.g. node1, node2, node3> -noClusterEnabled


11


CRS インストール後のインベントリ問題のトラブルシューティング


12


ワンオフ・パッチ適用とインベントリ・インタラクト

パッチ適用ツール（opatch）によるワンオフ・パッチ適用は、ORACLE_HOMEお

よびクラスタのノードの存在を検出する場合と同様のメカニズムです。そのため

に、opatchは OUI Java APIを介して中央インベントリ（デフォルト中央インベン

トリまたは invPtrLocにより指定された位置）とインタラクトします。つまり、イ

ンベントリの直接な読取りではなく、Javaランタイム環境を呼び出して、インベ

ントリを読み取る OUI APIをコールします。-silentフラグを使用して、サイレン

ト・モードで opatchを呼び出せます。

ここでは次のことが重要になります。暫定パッチ適用の場合、必要条件は必ず

守ってください。環境がすべての必要条

件を満たせば、パッチ適用の自動化が非

常に簡単になり、失敗に悩むことはあり

ません。

• opatchは、対応する Oracle Universal Installerライブラリをどのように見つ

けるか?

• opatchは、RAC環境でノードをどのように見つけるか?

• opatchは、Javaの存在をどのように検出するか?

OPatch 10.1 RAC 検出

経験則として、opatchは次の 2つの場合にシングル・インスタンスを仮定します。

何らかのエラーが発生した場合、opatchを"Not RAC"モードに設定してください。

-localを使用する場合、不必要な RAC検出を行わない"Not RAC"モードに設定して

ください。

opatchは、クラスタを検出すると OUIを介してインベントリを問い合わせ、ロー

カル・ノード名とノードリストを調べます。ノードリストが不完全と思われる場

合は、第 7項に記載した APIを使用してノードリストの更新が必要となります。

opatchが RACまたは RACの 1つ以上のノードを自動的に検出しない場合、イン

ベントリのコンテンツを調べる必要があります。インベントリのコンテンツが完

全なことの確認には、第 8項のデバッグ・フローを参照してください。

パッチ適用を正しく実行する必要条件

暫定パッチの正しいインストールには、次の条件を満たす必要があります。

1. システム必要条件

2. RAC必要条件（RACの場合）

メタリンクから最新の OPatchをダウンロードし、適用前のドライ実行を強く

お薦めします。最新の opatchは、プレースホルダ・パッチ 2617419から入手

できます。

システムの必要条件

1. Perlが Oracle Homeにインストールされていること、または PARHで使用可

能なことが必要です。次の位置に実行可能な'perl'（Unix）または'perl.exe'（Win）

が必要です。


13


Unixの場合: ORACLE_HOME/perl/binまたは

ORACLE_HOME/Apache/perl/binまたは環境変数 PATHの中

（PATHにある場合は'which perl'が示す）

Windowsの場合:

ORACLE_HOME＼perl＼5.6.1＼bin＼MSWin32-x86 (Win)または

ORACLE_HOME＼Apache＼perl＼5.00503＼bin＼MSWin32-x86 (Win)または

ORACLE_HOME＼Apache＼perl＼5.00503＼bin＼MSWin32-IA64 (Win)

opatchについて証明済みの Perlバージョンは Perl 5.6以降です。

AIX 5.1 Per1 5.6および 5.8でのみ機能し、5.6.1の場合はバグ 2825106のため

に機能しません。最新 opatch Perl証明書についてはメタリンクを参照してく

ださい。

2. "fuser"は、/sbin, /usr/sbinに存在するか、または PATHで使用可能なことが必

要です。

Unixの場合: 実行ファイル'fuser'は、/sbin, /usr/sbinにあるか、または PATHで

使用可能なことが必要です。（PATHにある場合、'which fuser'で表示される）

Windowsの場合: 不要

3. "ar"は、PATHで使用可能なことが必要です。

Unixの場合: 実行ファイル"ar"は、PATHで使用可能なことが必要です（'which

ar'で表示される）

Windowsの場合: 不要

4. -jdkオプションを使用する場合を除き、"jar"が ORACLE_HOMEまたは PATH

で使用可能なことが必要です。

Unixの場合: 実行ファイル'jar'が ORACLE_HOME/jdk/binに存在するか、また

は PATHで使用可能なことが必要です。（'which jar'で表示される）

Windowsの場合: 実行ファイル'jar'が ORACLE_HOME/jdk/binに存在するか、

PATHで使用可能なことが必要です。

OUI の必要条件

パッチ適用に関連して、OUIに 2種類の必要条件があります。それは、OUIライ

ブラリと Javaライブラリです。

10g R1以降、Oracle Universal Installer（OUI）および Java Runtime Environment（JRE）

は各 ORACLE_HOMEの中に内蔵されています。したがって、opatchは、それが

呼び出されたORACLE_HOMEからのOUIライブラリと JREに対して機能します。

OUIライブラリの場合、opatchは、ファイル'OraInstaller.jar'、'share.jar'、'srvm.jar'、

'xmlparserv2.jar'のすべてを<OUI_Location>/jlibまたは<OUI_Location/libで探します。

<OUI_Location>は、ORACLE_HOME/ouiまたは<Central_Inventory>/../ouiです。

一部のプラットフォームでは、ネイティブな oraInstaller.dll（Windows）、

liboraInsaller.sl（HP Itanium以外の HP）または liboraInstaller.so（HP Itaniumを含む

その他）を探します。


14


注意: 10g以前の環境では、opatchは中央インベントリを調べて OUIおよび

JREの位置を探します。

opatchは、中央インベントリ内の comps.xmlを使用して、JREのインストー

ルされた位置の取得に COMP NAME= "oracle.swd jre" VEA= "1.3.*" ... を探

し、OUIの位置の取得に COMP NAME= "oracle.swd.oui" ...を探します。

opatchが中央インベントリから Javaの位置を見つけられない場合、ユーザーが-jre

または-jdkにより Javaの位置を指定していなければ、特定なオペレーティング・

システムについて「既知」のパス内で"Java"実行ファイルを探します。-Javaまた

は jdkのいずれか一方（両方ではない）の指定を強くお薦めします。

RAC の必要条件（RAC のみに適用可能）

RACがある場合は前述のとおり、まず RACの必要条件チェック方法に従ってく

ださい。

その後、'opatch lsinventory -detail'を実行します。次に示す出力が得られます。

…

XML

10.1.0.2.0

XSQL Servlet Patch

10.1.0.3.0

XSQL Servlet

10.1.0.2.0

There are 258 components installed.

Installed Patch List:

=====================

1) Patch 1222222 applied on Wed Oct 20 16:46:48 PDT

2004

[ Base Bug(s): 2222222 ]

----------------------------

Mufti-Nodes RAC System

Node List:

linuxrac1 ← RAC detected linuxrac2

Local Node: linuxrac1

----------------------------

ここで示すように、OPatchは検出されたノードの一覧を出力します。前述のよう

に linuxrac1と linuxrac2という 2つのノードで構成されたRACで、linuxrac1をパッ

チ適用ノード（OPatchを呼び出すノード）として選択した場合は、linuxrac1から

次のコマンドを呼び出してリモート実行必要条件を満たしていることを確認しま

す。

1. rsh linuxrac-2 ls /tmp

出力は linuxrac2の/tmpにあるファイルの一覧です。


15


2. rsh linuxrac2 make

出力は次のようになります。

make: *** No targets specified and no makefile found.

Stop.

出力が次の場合もあります。

make: Command not found.

これは、OPatchがリモート・ノードで'make'を見つけられなかったことを

意味するため、この問題の訂正が必要となります。環境変数の設定だけで、RSH の代わりに

SSH で opatch が使用できます。

リモート・シェル（rsh）の代わりにセキュア・シェル（ssh）を使用する場合、

OPatchの呼出し前に上の'rsh'を'ssh'に置き換え、'setenv OPATCH_REMOTE_SHELL

ssh'とします。これで、OPatchに対するファイルの伝播とリモート再リンクに、'rsh'

の代わりに'ssh'の使用を指示します。

結論

インベントリは、ライフサイクル管理を容易にするために導入されました。今日

では、インストールのみならず、Enterprise Managerからの整合性追跡など、その

後の操作にも大きな役割を担っています。そのため、10gではクローニングのよ

うないくつかの機能を導入し、様々な配置操作の使用をサポートしています。こ

のドキュメントでは、インベントリの重要性と、それに関連する様々な操作を中

心に説明しています。このドキュメントを利用すれば、配置方針を計画でき、配

置後の操作についても参照できます。


16


Oracle Installer インベントリに関する運用の理解と自動化 2005 年著書: Sudip Datta and Debashis Saha Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問合せ窓口: 電話: +1.650.506.7000 ファックス: +1.650.506.7200 www.oracle.com Copyright © 2005, Oracle. All rights reserved. この文書はあくまで参考資料であり、掲載されている情報は予告なしに変更されることがあります。オラクル社は、本ドキュメントの無謬性を保証しません。また、本ドキュメントは、法律で明示的または暗黙的に記載

されているかどうかに関係なく、商品性または特定の目的に対する適合性に関する暗黙の保証や条件を含む一切の保証

または条件に制約されません。オラクル社は、本書の内容に関していかなる保証もいたしません。また、本書により、

契約上の直接的および間接的義務も発生しません。本書は、事前の書面による承諾を得ることなく、電子的または物理

的に、いかなる形式や方法によっても再生または伝送することはできません。 Oracle は、Oracle Corporation の登録商標です。その他の名称は、それぞれの所有者の商標です。

oracle installer インベントリに関する 運用の理解と...

Documents

oracle installer インベントリに関する運用の理解と...