|
|
 Copyright © 2007, Oracle. All rights reserved. |
|
管理エージェント・リリース・ノート
10gリリース3（10.2.0.3.0） for HP-UX Itanium
部品番号: E05385-01
原典情報: E10089-01 Oracle Enterprise Manager Management Agent Release Notes, 10g Release 3 (10.2.0.3.0) for HP-UX Itanium
2007年5月
Oracle Enterprise Manager Grid Control（Grid Control）は、企業内の様々なバージョンのOracle製品や、一部のサード・パーティ製品を管理するための、集中型の統合フレームワークを提供する管理ソリューションです。Grid Controlでは、ソフトウェアのインストール、パッチ適用、アップグレード、ワークロード・バランシング、セキュリティなど、企業グリッドに必要な日々のメンテナンスを自動化できます。
このリリース・ノートは、10.2.0.3.0 Grid Controlパッチ・セットにバンドルされているドキュメントの1つです。このドキュメントでは、このパッチ・セットに関する情報を提供し、以前のリリース（10.2.x.x.xのインストール）のGrid Controlまたは管理エージェント（もしくはその両方）にパッチを適用して10.2.0.3.0リリースにアップグレードするために役立つ手順を説明します。
|
注意: このリリース・ノートは、Oracle管理サービス、管理エージェントとそのリポジトリについて記述した一般的なドキュメントです。今回のリリースは管理エージェントにのみ適用されます。このドキュメント内の管理エージェントに関連する項のみ参照してください。 |
|
注意: このドキュメントは、Grid Controlまたは管理エージェント（もしくはその両方）の以前のリリース、つまり10.2.x.x.xインストールにパッチを適用して10.2.0.3.0リリースにアップグレードする場合のみを対象にしています。以前のリリースがインストールされていない場合に10.2.0.3.0環境を入手するには、まず10.2.0.1.0または10.2.0.2.0のリリースをインストールして、その後このパッチ・セットを使用して10.2.0.3.0にアップグレードしてください。10.2.0.1.0または10.2.0.2.0のGrid Controlのインストールの詳細は、次のURLのインストレーション・ガイドを参照してください。 |
このリリース・ノートは、次の項目で構成されています。
このリリースの管理エージェント・パッチ・セットに関連するドキュメントは2つあります。
Oracle Enterprise Manager管理エージェント・リリース・ノート, 10gリリース3（10.2.0.3.0）（このドキュメント）
このドキュメントの内容は次のとおりです。
このパッチ・セットに含まれている新しいコンポーネントのリスト
パッチ・セットのインストールまたはアンインストールの方法に関する情報
このリリースのGrid Controlパッチ・セットに関連する既知の問題のリスト
『Oracle Enterprise Manager Grid Control List of Bugs Fixed, 10g Release 3 (10.2.0.3.0)』
このドキュメントでは、このリリースで修正された、Grid Controlに関連するすべての一般的な不具合のリストを示します。
これらのドキュメントは、どちらも10.2.0.3.0パッチ・セットに含まれています。なお、次のURLのOracleMetaLinkで、統合されたドキュメント（ドキュメントID 418170.1）を検索することもできます。
ドキュメント418170.1の検索手順:
OracleMetaLinkページの最上部にある「Advanced」をクリックします。
「Document ID」フィールドに418170.1と入力し、「Submit」をクリックします。
このドキュメントは、次のURLにあるOracle Technology Network（OTN）のWebサイトでも検索できます。
10.2.0.3.0パッチ・セットには、次の新しいコンポーネントがバンドルされています。
Oracle Content Databaseプラグイン
Oracle Content Databaseプラグインは、Oracle Content Databaseリリース10.1.3.2.0を、Grid Controlリリース10.2.0.3.0の管理エージェント、管理サービスおよびリポジトリと統合する機能を提供します。たとえば、Content DBの実行時パフォーマンスやリポジトリ統計をGrid Controlで監視できるよう、ターゲット・タイプのメタデータとデフォルトのコレクションが定義されています。
Oracle Application Management Pack for Siebel
Oracle Application Management Pack for Siebelは、Siebel CRMアプリケーションの構成、パフォーマンス、可用性およびサービス・レベルを管理するための包括的ソリューションです。サーバーおよびコンポーネントの状態の監視、アプリケーション・レスポンス時間の測定、構成変更の追跡、およびパフォーマンスや実行に関する問題の診断に使用できます。
コネクタ（MOMおよびRemedy）
Microsoft Operations Management Connectorを使用すると、Microsoft Operations Manager（MOM）からのアラートをOracle Enterprise Managerで取得できます。取得したアラートは、Enterprise Managerリポジトリに格納され、Enterprise Managerコンソールに表示されます。
Remedy Connectorを使用すると、Remedy Trouble Ticket SystemとEnterprise Managerを統合できます。このコネクタは、Enterprise Managerの通知システムから取得されたアラートに基づいて、トラブル・チケットを作成します。
Oracle Configuration Manager
Oracle Configuration Manager（OCM）は、顧客の構成情報を収集および提供し、それらをOracleリポジトリに格納して、メンテナンスやその他の関連タスクを行えるように設計されています。この機能は、リリース10.2.0.2.0以降のGrid Controlから導入されたものです。
Linux Management Pack
Linux Management Packは、Oracle Unbreakable Linuxサポート・プログラムの一部としてのみ使用可能で、サーバーのプロビジョニング、パッチ適用、監視および管理など、Linuxサーバーのライフサイクル全体を管理するための、費用効率の高い統合されたソリューションを提供します。
Linux Server Administration
今回のリリースから、Enterprise ManagerではRedHat（RHEL4）およびSuSE Linux（sles9）用のLinux管理機能がサポートされます。これにより、システム・サービス構成やネットワーク設定など、エラーが発生しやすく時間のかかるサーバー設定タスクが大幅に簡略化されます。
この項では、インストール前に実行する作業について説明します。
このパッチ・セットを使用してアップグレードを行う前に、アップグレードするORACLE_HOMEのバックアップをとることをお薦めします。管理リポジトリの場合は、リポジトリ・データベースをバックアップすることをお薦めします。これは、パッチ・セットを適用すると、リポジトリに対してロールバック不可能な変更が行われるためです。また、Oracle Inventoryディレクトリもパッチ・セット適用前の状態でバックアップしてください。
10.2.0.3.0の製品前提条件（必要なオペレーティング・システムのパッチ、パッケージなど）は、10.2.0.1.0/10.2.0.2.0と同じであるため、すでに満たされています。
Grid Control環境を、10.1.0.4または10.1.0.5データベースの「新規データベースを使用したEnterprise Manager」オプションまたは「既存のデータベースを使用したEnterprise Manager」オプションを使用してインストールした場合は、10.2.0.3にアップグレードする前に、データベース・ホームでOracle Bug#4329444のパッチを適用してください。
ご使用の環境にパッチ5191377が適用されている場合は、10.2.0.3にアップグレードする前に、次の手順を行ってください。
個別パッチ5191377をロールバックします。
現行ディレクトリを、パッチがあるディレクトリに設定します。
% cd 5191377
次のコマンドを実行します。
% opatch rollback -id 5191377
リポジトリ所有者としてログインし、SQLプロンプトに対して次のコマンドを実行します。
SQL>drop index mgmt_current_violation_idx_05
インストール前の作業は、考えられるアップグレードのタイプによって次のように大まかに分類できます。
Oracle管理サービス（OMS）が複数ある場合は、一括でアップグレードする以外に、1つずつアップグレードする方法もあります。その場合、パッチ・セットを使用して1つ目のOMSをアップグレードする際には、関連付けられているリポジトリもアップグレードされることに注意してください。
1つ目のOMSをアップグレードする前には、次の手順を行います。
リポジトリ・データベースおよびリスナー・インスタンスは、実行中のままにします。
Grid Control環境を、10.1.0.4または10.1.0.5データベースの「新規データベースを使用したEnterprise Manager」オプションまたは「既存のデータベースを使用したEnterprise Manager」オプションを使用してインストールした場合は、10.2.0.3にアップグレードする前に、データベース・ホームでOracle Bug#4329444のパッチを適用してください。
ご使用の環境にパッチ5191377が適用されている場合は、10.2.0.3にアップグレードする前に、次の手順を行ってください。
個別パッチ5191377をロールバックします。
a.現行ディレクトリを、パッチがあるディレクトリに設定します。
% cd 5191377
b.次のコマンドを実行します。
% opatch rollback -id 5191377
リポジトリ所有者としてログインし、SQLプロンプトに対して次のコマンドを実行します。
SQL>drop index mgmt_current_violation_idx_05
それぞれのホストの各ORACLE_HOMEから次のコマンドを使用して、リポジトリに関連付けられているすべてのOMSインスタンスを停止します。
$ORACLE_HOME/opmn/bin/opmnctl stopall
|
注意: 1つ目のOMSのみをアップグレードするの場合でも、すべてのOMSインスタンスを停止する必要があります。これは、1つ目のOMSをアップグレードするとリポジトリもアップグレードされますが、他のOMSインスタンスもこの同じリポジトリに接続しているので、それらのインスタンスも停止する必要があるためです。 また、管理エージェントの停止は必須ではありませんが、停止しない場合はエージェント関連のログ・ファイルの数が増える可能性があります。ただし、これは無害なので無視してかまいません。 |
すべてのOMSを停止したら、/usr/sbin/slibcleanをルートとして実行します。runInstallerを実行する前に、OBJECT_MODE環境変数が設定解除されていることを確認してください。OBJECT_MODEを設定解除するには、unset OBJECT_MODEを実行します。
10.2.0.3.0パッチ・セットを適用します。これには、runInstaller（Microsoft Windowsの場合はsetup.exe）を実行して対話形式で行う方法と、レスポンス・ファイルを使用してサイレントに行う方法があります。
1つ目のOMSとリポジトリを10.2.0.3.0にアップグレードした後にその他のOMSインスタンスをアップグレードする場合、事前に行う手順は1つのみです。その手順は、他のOMSインスタンス（最初にアップグレードしたOMSを含む）が停止していることを確認することです。
Oracle Universal Installer（OUI）を使用して手動でパッチ・セットを適用する場合、インストール前に実行する手順は管理エージェントを停止することのみです。OUIでは、実行中の管理エージェント・プロセスがないどうかの検証が行われます。実行中の管理エージェント・プロセスがある場合、インストーラは管理エージェントの停止を要求し、停止されたらファイルのコピーおよび後続の再リンク操作に進みます。
パッチ・ウィザードを使用してパッチ・セットを適用する場合は、管理エージェントが稼働中である必要があります。
|
注意: 10.2.0.1では、OMSのインストールによってOMSのみでなく管理エージェントも自動的にインストールされます。ただし、そのOMSをパッチ・セットを使用して10.2.0.3.0にアップグレードする際には、関連付けられている管理エージェントは、いずれもアップグレードされません。管理エージェントをアップグレードするには、管理エージェント・ホームごとにパッチ・セットを手動で適用する必要があります。これは、それぞれのホームが別個のOracleホームであるためです。 |
この項では、インストール手順を説明します。
10.2.0.3.0にアップグレードするには、10.2.0.3.0パッチ・セットを手動でダウンロードし抽出する必要があります。
パッチ・セットのダウンロードおよび抽出の手順:
p3731593_102030_<platform name>.zipパッチ・セット（インストール・アーカイブ）を任意のディレクトリにダウンロードします。これは、Oracleホーム・ディレクトリでもそれ以外のディレクトリでもかまいません。
次のコマンドを入力して、インストール・ファイルを解凍し、抽出します。
$ unzip p3731593_102030_<platform name>.zip
3731593ディレクトリにファイルが抽出されます。
|
重要: このパッチ・セットは、OMS、リポジトリおよび管理エージェントへのパッチ適用にも使用できます。手順は、この後の各項で説明します。 |
ORACLE_HOMEが、アップグレードしようとしているOMSのORACLE_HOMEに設定されていることを確認します。3731593/Disk1サブディレクトリに移動してrunInstaller（Microsoft Windowsの場合はsetup.exe）を実行します。
|
注意: パッチ・セットには、古いコンポーネント（Oracle Configuration Manager（OCM））に加えて、Siebelやコネクタなどの新しいコンポーネントが含まれています。これらのコンポーネントをインストールして正常に機能させるには、パッチ・セットを管理エージェントのみでなくOMSにも適用して、OMSおよび管理エージェントに関連するビットが適宜インストールされるようにする必要があります。パッチ・セットは、対象のORACLE_HOMEがOMSか管理エージェントかを判別し、OMSまたはエージェントのビットを適宜インストールします。 |
|
重要: Grid Control環境を、10.1.0.4または10.1.0.5データベースの「新規データベースを使用したEnterprise Manager」オプションまたは「既存のデータベースを使用したEnterprise Manager」オプションを使用してインストールした場合は、10.2.0.3にアップグレードする前に、データベース・ホームでOracle Bug#4329444のパッチを適用してください。ご使用の環境にパッチ5191377が適用されている場合は、10.2.0.3にアップグレードする前に、次の手順を行ってください。
|
ORACLE_HOMEが環境内に設定されているか、またはコマンドライン引数として渡されていれば、OUIはそのORACLE_HOMEを自動的に選択し、次の3つのフェーズに順に移行します。
このフェーズでは、OUIは構成ファイルからリポジトリ接続の詳細を取得し、リポジトリ・データベースのSYSパスワードを要求します。その後、リポジトリへの既存の接続があるかどうかを検証します。このとき、OUIはオペレーティング・システム・プロセスをチェックするのではなく、Enterprise Managerリポジトリ内の特定のエントリを検索します。そのため、OMSを停止した後は、セッション・エントリが消去されるまで数分間待機してください。
Oracle Configuration Managerのインストール
このステップでは、インストーラは既存のORACLE_HOMEの場所にOracle Configuration Manager（OCM）をインストールするための情報を収集します。OCMの構成は、ライセンス契約が受け入れられた場合にのみ行われます。
「OCMの構成」ページでOCMを構成する際には、カスタマ・サービスID（CSI）、OracleMetaLinkアカウントのユーザー名およびライセンス発行国を入力します。プロキシ設定を構成する場合は、この構成ページの「接続設定」をクリックして、プロキシ設定を指定します。
|
注意: OCMは、ライセンス契約を拒否した場合でもインストールされますが、構成はされません。その際、必要なディレクトリが作成され、ファイルはインスタンス化されます。構成は、後で管理者がsetupCCR（$ORACLE_HOME/ccr/bin/setupCCR）を起動して行う必要があります。setupCCRを対話形式で起動した場合は、必要なパラメータ値が要求されます。なお、ライセンス契約は受け入れた上で、Oracle Configuration Managerの有効化はしないということもできます。ライセンス契約を受け入れた後でOracle Configuration Managerを無効化するには、「Oracle Configuration Managerの有効化」オプションを選択解除します。
|
管理エージェントのインストールにエージェント・ダウンロードを使用した場合は、OCMを手動で構成する必要があります。OCMを構成するには、次の手順を行います。
CSI、OracleMetaLink ID、およびサービス契約を購入した国を確認します。
状況に応じて、次のコマンドのいずれかを実行します。
プロキシ・サーバーを使用して構成する場合:
$ORACLE_HOME/ccr/bin/setupCCR -p <proxy server>
プロキシ・サーバーを使用せずに構成する場合:
$ORACLE_HOME/ccr/bin/setupCCR
setupCCRの使用方法の詳細を表示するには、setupCCR -helpコマンドを使用します。
Oracle Configuration Managerのライセンス契約が表示されます。ライセンス契約を受け入れる場合はYを入力します。
CSI、OracleMetaLink IDおよび国コードが要求されたら、それらの情報を入力します。
OCMがインストールされて構成されます。
セットアップが完了すると、OCMによってORACLE_HOMEの構成情報が収集され、Oracleにアップロードされて、サイトのサポート期間中使用されます。
OCMのステータスをチェックするには、次のコマンドを実行します。
$ORACLE_HOME/ccr/bin/emCCR status
このフェーズでは、インストーラは次の処理を行います。
リポジトリの更新: リポジトリがすでに10.2.0.3.0リリースにアップグレードされており、現在アップグレード中のOMSが2つ目以降のOMSである場合は、構成フェーズでのリポジトリの更新は行われません。
Enterprise Managerアプリケーションの再デプロイ: このステップでは、OC4Jアプリケーションが再デプロイされます。
プロビジョニング・アプリケーションのデプロイ: このステップでは、アプリケーションのデプロイに使用できる様々なプロビジョニング・アプリケーション・ステップが構成されます。ここでは、プロビジョニング・アーカイブ・ファイルもEnterprise Managerリポジトリに合わせて更新されます。通常、プロビジョニング・アーカイブ・ファイルは、アプリケーションで使用される新しいプロシージャ、新しいディレクティブおよび新しいコンポーネントで構成されます。
ソフトウェア・ライブラリが設定されていない場合は、プロビジョニング構成が正常に行われなかったことを示すメッセージが表示されます。その場合は、アップグレード後、ソフトウェア・ライブラリを設定した後に手動でツールを実行する必要があります。ソフトウェア・ライブラリの作成には、すべてのOMSインスタンスからの読取りおよび書込みが可能な任意のマウント済ファイル・システムを使用できます。
このエラーを修正するには、次の手順を行います。
Enterprise Manager Grid ControlにSYSMANとしてログインします。
「デプロイ」、「プロビジョニング」、「管理」の順に移動します。
「ソフトウェア・ライブラリ構成」セクションに移動して「追加」をクリックします。
対象コンポーネント用のRAWデータの格納先として、有効なディレクトリ・パスを指定します。
OMSをホストするマシンにログインして次の処理を行います。
環境変数をOMSのORACLE_HOMEに設定します。
次のコマンドを実行します。
<ORACLE_HOME>/bin/PARDeploy -action -force deploy -parDir <OMSHome>/sysman/prov/paf
Oracle管理サービスの開始: このステップでは、OMSが開始されます。
Oracle Configuration Managerの構成: ライセンス契約を受け入れた場合、このステップでOCMの構成が行われます。その際、必要なディレクトリが作成され、ファイルはインスタンス化されます。構成中に問題が発生した場合、構成は実行されません。後で構成する場合は、構成する際にsetupCCR（$ORACLE_HOME/ccr/bin/setupCCR）を起動してください。
管理エージェントのアップグレード方法は2つあります。1回に1つのホストをアップグレードする方法と、同時に複数のホストをアップグレードする方法です。
|
重要: パッチ・セットには、古いコンポーネント（Oracle Configuration Manager（OCM））に加えて、Siebelやコネクタなどの新しいコンポーネントが含まれています。これらのコンポーネントをインストールして正常に機能させるには、パッチ・セットを管理エージェントのみでなくOMSにも適用して、OMSおよびエージェントに関連するビットが適宜インストールされるようにする必要があります。パッチ・セットは、対象のORACLE_HOMEがOMSか管理エージェントかを判別し、OMSまたはエージェントのビットを適宜インストールします。 |
OUIを使用して1回に1つのホストで管理エージェントをアップグレードするには、次の手順に従います。
管理エージェントが実行されている特定のホストにログインします。
管理エージェントを停止します。
ORACLE_HOMEが、パッチ適用対象のORACLE_HOMEに設定されていることを確認します。
パッチ・セット・メディアのディスク1のサブディレクトリから、実行可能ファイルrunInstaller（Microsoft Windowsの場合はsetup.exe）を実行します。
ORACLE_HOMEが環境内に設定されているか、またはコマンドライン引数として渡されていれば、OUIはORACLE_HOMEを自動的に選択します。
その後、OUIは管理エージェントがORACLE_HOMEから稼働しているかどうかを検証します。管理エージェントが稼働中の場合、インストーラは管理エージェントの停止を要求し、停止されたらファイルのコピーおよび後続の再リンク操作に進みます。インストールが完了すると、パッチ・セットが管理エージェントを自動的に再起動します。
同時に複数のホストで管理エージェントをアップグレードするには、次に示す2つの方法のどちらかを使用します。
方法1: 多数のノードに完全なパッチ・セットを配布する
方法2: パッチ・セットをステージングして多数のノードにスクリプトを配布する
多数の管理エージェントへのパッチ適用には、これらのどちらかの方法を選択できます。方法1は、パッチ・バイナリのセット全体がすべてのターゲットに転送されるプッシュの技術に基づきます。方法2は、1つのスクリプトのみがターゲットに転送された後、HTTPを介してパッチがインストールされるプルの技術に基づきます。方法2ではパッチ・バイナリのセット全体を転送する必要がないため、ターゲットが多数ある場合はこちらの方法をお薦めします。一方、方法1はターゲットの数が限られている場合に適しています。方法2を使用する場合は、実行可能ファイルwgetがターゲット・マシンにインストールされていて、かつPATH環境変数内に存在する必要があります。
方法1: 多数のノードに完全なパッチ・セットを配布する
Enterprise Manager Grid ControlにSYSMAN資格証明を使用してログインします。「ターゲット」をクリックしてホストが実行中かどうかをチェックします。
Grid Controlコンソールの右上隅にある「設定」をクリックします。左のパネルで「パッチ適用設定」を選択します。OracleMetalinkの資格証明を入力して「適用」をクリックします。
「ジョブ」タブに移動します。タイプRefreshFromMetalinkのジョブを作成して実行します。
「デプロイ」、「Oracleソフトウェアのパッチ」の順にクリックします。パッチ番号3822442を指定し、正しいプラットフォームと10.2.0.3.0リリースを選択します。
パッチを適用するターゲットを複数選択します。ターゲットを選択したら、ターゲット・エージェントのホームにOCMがインストールされるよう、「デフォルトのパッチ適用スクリプトの使用」オプションまたは「カスタム・スクリプトの指定」オプションを選択します。
ターゲットがMicrosoft Windowsのマシンの場合は、前処理スクリプト・オプションで次のように指定します。
%emd_root%\EMStagedPatches\3822442\3822442\ecm_3822442.bat
この方法によって、選択した数のターゲットにパッチがコピーされ、パッチを適用するスクリプトが実行されます。スクリプトでは、ブラックアウトの作成、パッチ・セット適用前の管理エージェントの停止、パッチ・セットの適用、パッチ・セット適用後のブラックアウトの消去、および管理エージェントの再起動が実行されます。ネットワークに負荷をかけすぎないよう、選択するノードは妥当な数にとどめることをお薦めします。
|
重要: パッチ・セットには、古いコンポーネント（OCM）に加えて、Siebelやコネクタなどの新しいコンポーネントが含まれています。これらのコンポーネントをインストールして正常に機能させるには、パッチ・セットを管理エージェントのみでなくOMSにも適用して、OMSおよびエージェントに関連するビットが適宜インストールされるようにする必要があります。 |
方法2: パッチ・セットをステージングして多数のノードにスクリプトを配布する
|
注意: Microsoft Windowsのターゲット・マシンの場合、この方法でパッチを適用するにはPATH環境変数にwget.exeが存在する必要があります。ターゲット・マシンのPATHにwget.exeがない場合は、wget.exeをPATHに追加し、次のコマンドを実行して管理エージェントを再バウンスしてください。
|
OMSホストで次の手順を行います。
次の場所に移動します。
cd <OMS ORACLE_HOME>/sysman/agent_download/
ディレクトリを作成します。
mkdir -p patchset/10.2.0.3.0/<platform name>
DVDからコピーするか、Metalinkパッチ3731593の内容を抽出して、パッチ・セットをステージングします。
DVDまたはMetalinkパッチから空の一時ディレクトリへp3731593_102030_<platform name>.zipをコピーします。
ZIPファイルの内容を同じ一時ディレクトリに抽出します。
3731593/Disk1ディレクトリに移動し、ディレクトリの内容を手順2で新規作成したディレクトリにコピーします。
移動するには、次のコマンドを使用します。
cd 3731593/Disk1
手順2で新規作成したディレクトリに内容をコピーするには、次のコマンドを使用します。
cp -r * <ORACLE_HOME>/sysman/agent_download/patchset/10.2.0.3.0/<platform name>
ここで、ORACLE_HOMEはOMS ORACLE_HOMEを指し、platform nameは次のいずれかを指します。
表1 プラットフォーム名の説明
| プラットフォーム名 | 説明 |
|---|---|
| linux | Linux |
| x86_64 | Linux X86_64 |
| ppc64 | Linux on power PC |
| linux390 | z/Linux |
| ia64linux | IA64 Linux |
| solaris | Solaris 64 bit |
| solarisx86 | Solaris-x86 |
| hpux | HP-UX |
| decunix | HP Tru64 UNIX |
| hpunix | HP 64 bit |
| hpi | HPUX-Itanium |
| aix | AIX5L |
| macosx | MACOSX |
| vms | VMS |
上に示した操作により、パッチ・セットの内容がOMSホストにステージングされます。
その後、次の手順を行います。
（a）Enterprise Manager Grid Controlにログインして「ジョブ」タブに移動し、パッチ・ジョブを選択します。
（b）パッチ番号3731596を指定して、正しいプラットフォームおよびターゲットのリリースを選択します。
（c）パッチを適用するターゲットを複数選択します。ターゲットを選択したら、「カスタム・スクリプトの指定」オプションを選択して、OCMがターゲット・エージェントのホームにインストールされるようにします。
（d）ターゲットがMicrosoft Windowsのマシンの場合は、前処理スクリプト・オプションで次のように指定します。
%emd_root%\EMStagedPatches\3731596\3731596\ecm_3731596.bat
この方法では、選択した数のノードにスクリプトがコピーされ、スクリプトが実行されて前述のステージング場所からパッチ・セットが適用されます。ネットワークに負荷をかけすぎないよう、選択するノードは妥当な数にとどめることをお薦めします。
|
重要: パッチ・セットには、古いコンポーネント（OCM）に加えて、Siebelやコネクタなどの新しいコンポーネントが含まれています。これらのコンポーネントをインストールして正常に機能させるには、パッチ・セットを管理エージェントのみでなくOMSにも適用して、OMSおよびエージェントに関連するビットが適宜インストールされるようにする必要があります。 |
クラスタのノードを選択して管理エージェントにパッチを適用できます。これを行うには、次の2つの方法のどちらかを使用します。
方法1: 多数のノードに完全なパッチ・セットを配布する
方法2: パッチ・セットをステージングして多数のノードにスクリプトを配布する
多数の管理エージェントへのパッチ適用には、これらのどちらかの方法を選択できます。方法1は、パッチ・バイナリのセット全体がすべてのターゲットに転送されるプッシュの技術に基づきます。方法2は、1つのスクリプトのみがターゲットに転送された後、HTTPを介してパッチがインストールされるプルの技術に基づきます。方法2ではパッチ・バイナリのセット全体を転送する必要がないため、ターゲットが多数ある場合はこちらの方法をお薦めします。一方、方法1はターゲットの数が限られている場合に適しています。方法2を使用する場合は、実行可能ファイルwgetがターゲット・マシンにインストールされていて、かつPATH環境変数内に存在する必要があります。
方法1: 多数のノードに完全なパッチ・セットを配布する
Enterprise Manager Grid Controlにログインします。「ジョブ」タブに移動してパッチ・ジョブを選択します。
パッチ番号3822442を指定し、正しいプラットフォームと10.2.0.3.0リリースを選択します。
パッチを適用するすべてのクラスタ・ノードを選択できます。ターゲットを選択したら、「カスタム・スクリプトの指定」オプションを選択して、OCMがターゲット・エージェントのホームにインストールされるようにします。
ターゲットがMicrosoft Windowsのマシンの場合は、前処理スクリプト・オプションで次のように指定します。
%emd_root%\EMStagedPatches\3822442\3822442\ecm_3822442.bat
この方法によって、選択したクラスタ・ノードにパッチがコピーされ、パッチを適用するスクリプトが実行されます。このスクリプトによって、ブラックアウトの作成、パッチ・セット適用前の管理エージェントの停止、パッチ・セット適用後のブラックアウトの消去、そして管理エージェントの起動が行われます。クラスタが非常に大きい場合は、ネットワークに負荷をかけすぎないよう、選択するノードは妥当な数にとどめることをお薦めします。
方法2: パッチ・セットをステージングして多数のノードにスクリプトを配布する
|
注意: Microsoft Windowsのターゲット・マシンの場合、この方法でパッチを適用するにはPATH環境変数にwget.exeが存在する必要があります。ターゲット・マシンのPATHにwget.exeがない場合は、wget.exeをPATHに追加し、次のコマンドを実行して管理エージェントを再バウンスしてください。
|
OMSホストで次の手順を行います。
次の場所に移動します。
cd <OMS ORACLE_HOME>/sysman/agent_download/
ディレクトリを作成します。
mkdir -p patchset/10.2.0.3.0/<platform name>
DVDからコピーするか、Metalinkパッチ3731593の内容を抽出して、パッチ・セットをステージングできます。
DVDまたはMetalinkパッチから空の一時ディレクトリへp3731593_102030_<platform name>.zipをコピーします。
ZIPファイルの内容を同じ一時ディレクトリに抽出します。
3731593/Disk1ディレクトリに移動し、ディレクトリの内容を手順2で新規作成したディレクトリにコピーします。
移動するには、次のコマンドを使用します。
cd 3731593/Disk1
手順2で新規作成したディレクトリに内容をコピーするには、次のコマンドを使用します。
cp -r * <ORACLE_HOME>/sysman/agent_download/patchset/10.2.0.3.0/<platform name>
ここで、ORACLE_HOMEはOMS ORACLE_HOMEを指し、platform nameは次のいずれかを指します。
表2 プラットフォーム名の説明
| プラットフォーム名 | 説明 |
|---|---|
| linux | Linux |
| x86_64 | Linux X86_64 |
| ppc64 | Linux on power PC |
| linux390 | z/Linux |
| ia64linux | IA64 Linux |
| solaris | Solaris 64 bit |
| solarisx86 | Solaris-x86 |
| hpux | HP-UX |
| decunix | HP Tru64 UNIX |
| hpunix | HP 64 bit |
| hpi | HPUX-Itanium |
| aix | AIX5L |
| macosx | MACOSX |
| vms | VMS |
上に示した操作により、パッチ・セットの内容がOMSホストにステージングされます。
その後、次の手順を行います。
（a）Enterprise Manager Grid Controlにログインして「ジョブ」タブに移動し、パッチ・ジョブを選択します。
（b）パッチ番号3731596を指定して、正しいプラットフォームおよびターゲットのリリースを選択します。
（c）パッチを適用するターゲットを複数選択します。ターゲットを選択したら、「カスタム・スクリプトの指定」オプションを選択して、OCMがターゲット・エージェントのホームにインストールされるようにします。
（d）ターゲットがMicrosoft Windowsのマシンの場合は、前処理スクリプト・オプションで次のように指定します。
%emd_root%\EMStagedPatches\3731596\3731596\ecm_3731596.bat
この方法では、選択したクラスタ・ノードにパッチがコピーされ、スクリプトが実行されて前述のステージング場所からパッチ・セットが適用されます。ネットワークに負荷をかけすぎないよう、選択するノードは妥当な数にとどめることをお薦めします。
この項では、インストール後に実行する作業について説明します。
OMSインスタンスを個別にアップグレードすることを選択した場合、つまり1つ目のOMSとリポジトリをアップグレードした場合は、アップグレードの完了後に、停止したすべての管理エージェントを再起動してください。OMSはアップグレードの完了後に自動的に再起動しますが、管理エージェントは手動で再起動する必要があります。1つ目のOMSとリポジトリのアップグレードに関する詳細は、「1つ目のOracle管理サービスとリポジトリのアップグレード」を参照してください。
この項では、Solarisエージェント・ホストで実行する必要があるインストール後の作業について説明します。
対象のEnterprise Manager配置内にSolaris 10.2.0.1.0管理エージェントが一度も配置されていない場合は、この項を無視してください。次に示す手順は、すべてのSolaris 10.2.0.1管理エージェントを10.2.0.2以降のリリースにアップグレードした後で、1回行えば十分です。確信がない場合は、この項で説明する処理を複数回繰り返してもかまいません。
Enterprise Managerリポジトリ内で、Host 3.0メタデータを使用するSolarisエージェントを識別します。該当するエージェントがあれば、それらを10.2.0.2.0以降のリリースにアップグレードします。
Solaris 3.0メタデータがEnterprise Managerリポジトリにあるかどうかをチェックするには、lfm_check_solaris_3_0_metadataを実行します。
% sqlplus sysman/<sysman_passwd> @lfm_check_solaris_3_0_metadata
この手順で0が戻された場合は、この項を無視してかまいません。
アップグレードが必要なホストを識別するには、Enterprise Managerリポジトリに対してlist_lfm_solaris_3_0_metadata_hosts.sqlを実行します。
% sqlplus sysman/<sysman_passwd> @list_lfm_solaris_3_0_metadata_hosts
この手順で空のリストが戻された場合は、Solarisエージェント・ホストは存在しません。この項を無視してください。
OracleMetalink Webサイトから、Solaris 10.2.0.2.0またはそれ以降のリリースのパッチ・セットをダウンロードします。その後、前の手順で識別されたSolarisエージェントにこのパッチを適用します。
まず管理エージェントの所有者アカウントを使用してSolarisホストにログオンします。次に、emctlアップロード・コマンドを使用して保留中のデータをアップロードします。その後、emctl stop agentを使用して管理エージェントを停止します。停止したら、パッチ・セットの10.2.0.2管理エージェント部分を適用します。その後、emctl start agentを使用して管理エージェントを起動します。
1時間後にもう一度list_lfm_solaris_3_0_metadata_hosts.sqlを実行して、パッチの適用が必要なエージェントが他にないか確認します。
「監視テンプレート」から、汎用ログ・ファイル監視に固有のカスタマイズを削除します。汎用ログ・ファイル監視機能の詳細は、汎用ログ・ファイル監視基準の構成に関するオンライン・ヘルプを参照してください。
list_lfm_templates.sqlを実行して、カスタマイズされているテンプレートを識別します。
% sqlplus sysman/<sysman_passwd> @list_lfm_templates
この手順で空のリストが戻された場合は、手順3に進んでください。
手順2（a）でリストされた各通知ルールに対して、次の手順を実行します。
テンプレートを編集するために、適切な権限を使用してEnterprise Managerコンソールにログオンします。
「設定」をクリックして、左ペインにある「監視テンプレート」をクリックします。
名前を基準にテンプレートを検索し、ラジオ・ボタンを選択してテンプレートを選択します。
汎用ログ・ファイル監視に関連するカスタマイズを削除するには、テンプレートを削除または更新します。
テンプレートを削除する場合は、まず「表示」をクリックし、後で使用できるよう、テンプレートの設定を記録します。記録したら、「OK」をクリックして「監視テンプレート」ページに戻ります。戻ったら、テンプレートを選択して「削除」をクリックします。その後、「テンプレート削除の確認」ページで「はい」をクリックします。
テンプレートを更新する場合は、まず「編集」、「メトリックしきい値」タブの順にクリックします。次に、「ログ・ファイル・パターン一致行数」の横にある編集アイコンをクリックして、後で参照できるよう、「監視対象オブジェクト」表にある設定を記録します。記録したら、「続行」（ページ・レベル）をクリックして「メトリックしきい値」タブに戻ります。戻ったら、「ログ・ファイル・パターン一致行数」を選択し、「テンプレートからのメトリックの削除」をクリックして削除します。その後、「OK」（ページ・レベル）をクリックして変更をコミットします。
手順2（a）を実行して、カスタマイズされたテンプレートが他にもないか確認します。
「通知ルール」から、汎用ログ・ファイル監視に関連するフィルタを削除します。これを行うには、次の手順を行います。
list_lfm_notif_rules.sqlを実行して、カスタマイズされているルールを識別します。
% sqlplus sysman/<sysman_passwd> @list_lfm_notif_rules
この手順で空のリストが戻された場合は、手順4に進んでください。
手順3（a）でリストされた各ルールに対して、次の手順を実行します。
通知ルールを編集できる資格証明または権限を使用して、Grid Controlコンソールにログオンします。
「プリファレンス」をクリックし、左ペインの「通知」の下にある「ルール」をクリックします。次に、ラジオ・ボタンを選択してルールを選択します。その後、選択したルールを削除または更新します。ここでいう更新とは、「ログ・ファイル・パターン一致行数」メトリックを削除するか、または「ログ・ファイル・パターン一致行数」メトリックを更新してすべてのオブジェクトに通知することを指します。
通知ルールを削除する場合は、まず「表示」をクリックし、後で参照できるよう、現在の設定を記録します。記録したら、ブレッドクラム・リストの「通知ルール」をクリックして前のページに戻ります。その後、「削除」をクリックし、確認ページで「はい」をクリックします。
「ログ・ファイル・パターン一致行数」メトリックを削除することによってルールを更新する場合は、まず、「編集」、「メトリック」タブの順にクリックします。次に、「ログ・ファイル・パターン一致行数」メトリックの行を選択し、現在の設定を記録します。記録したら、表レベルの「削除」をクリックします。その後、「OK」（ページ・レベル）をクリックして変更をコミットします。
「ログ・ファイル・パターン一致行数」メトリックを更新してすべてのオブジェクトに通知する場合は、まず、「編集」、「メトリック」タブの順にクリックします。次に、「ログ・ファイル・パターン一致行数」メトリックの横にある編集アイコンをクリックします。現在の設定が表示されたら、設定内容を記録しておきます。記録したら、「すべてのオブジェクト」のラジオ・ボタンを選択し、「続行」（ページ・レベル）をクリックして「メトリック」ページに戻ります。その後、「OK」（ページ・レベル）をクリックして変更をコミットします。
手順3（a）を実行します。
「ログ・ファイル・パターン一致行数」ホスト・メトリックのメトリックしきい値を設定することによって構成された、汎用ログ・ファイル監視関連のカスタム構成を削除します。
list_lfm_threshold_hosts.sqlを実行してカスタム構成を使用しているホストを識別します。
% sqlplus sysman/<sysman_passwd> @list_lfm_threshold_hosts
この手順で空のリストが戻された場合は、手順5に進んでください。
手順4（a）でリストされた各ホストに対して、次の手順を実行します。
ホストしきい値を編集できる資格証明または権限を使用して、Grid Controlコンソールにログオンします。
対象のホストのホームページに移動して、「メトリックとポリシー設定」をクリックします。
「ログ・ファイル・パターン一致行数」メトリックと同じ行にある編集アイコンをクリックします。
「監視対象オブジェクト」表にある設定を、後で参照できるよう記録します。
「監視対象オブジェクト」表から「その他すべて」以外のすべての行を削除します。
「続行」（ページ・レベル）をクリックして「メトリックしきい値」タブに戻り、「OK」（ページ・レベル）をクリックして変更をコミットします。
手順4（a）を実行します。
Solaris 3.0メタデータ・ベースのホストから「ログ・ファイル・パターン一致行数」の重大度を消去およびパージします。
list_lfm_severity_solaris_hosts.sqlを実行してホストを識別します。
% sqlplus sysman/<sysman_passwd> @list_lfm_severity_solaris_hosts
この手順で空のリストが戻された場合は、手順6に進んでください。
手順5（a）でリストされた各ホストに対して、次の手順を実行します。
ホストしきい値を編集できる資格証明または権限を使用して、Grid Controlコンソールにログオンします。
対象のホストのホームページに移動して、「ログ・ファイル・アラート」をクリックします。
「すべてのオープン・アラートを消去」をクリックします。
消去されたアラートをパージするには、「消去されたアラートの表示」、「すべてのアラートをパージ」の順にクリックします。この手順はオプションです。
手順5（a）を実行します。
すべてのOMSノードでGrid Controlコンソールを停止します。
Enterprise Managerリポジトリに対してlfm_fix_host_metadata.sqlを実行します。
% sqlplus sysman/<sysman_passwd> @lfm_fix_host_metadata
終了コマンドを入力してsqlplusセッションを終了します。
すべてのOMSノードでGrid Controlコンソールを起動します。
パッチが適切に適用されていることを検証します。そのためには、次の手順を行います。
Grid Controlコンソールにログオンします。
UNIXホスト（Solaris、Linuxなど）のホームページに移動して「メトリックとポリシー設定」をクリックします。
「ログ・ファイル・パターン一致行数」の横にある編集アイコンをクリックして、「監視対象オブジェクト」表に表示されている列が次のとおりであることを検証します。「選択」、「ログ・ファイル名」、「Perlでのパターンの一致」、「Perlでのパターンの無視」、「比較演算子」、「警告のしきい値」、「クリティカルのしきい値」、「修正処理」。
ここまでの手順で削除したすべてのカスタム設定を再作成します。
|
注意: 今後は、Solaris 10.2.0.1.0管理エージェントを配置しないでください。かわりに、Solaris管理エージェントの10.2.0.2.0以降のリリースを配置してください。 |
パッチ・セットをアンインストールするためのメカニズムは提供されていません。パッチ・セットをアンインストールできるようにする場合は、パッチ・セットを適用する前に、ソフトウェアのインストールをバックアップしておくことをお薦めします。パッチ・セットをアンインストールする必要がある場合は、優先順に示した次の手順のいずれかを使用します。
バックアップされたORACLE_HOMEディレクトリをリストアする。
ベースライン・リリースおよび以前適用されたすべてのパッチ・セット（このパッチ・セットを除く）を再インストールする。
バックアップされたリポジトリ・データベースをリストアする。
バックアップされたOracleインベントリをリストアする。
どの方法でパッチ・セットをアンインストールする場合でも、発生する問題が解決されているかどうかを検証するために、オラクル社カスタマ・サポート・センターに連絡してください。
この項では、このリリースに関する既知の問題をリストします。
この項では、インストールおよびアップグレードの問題について説明します。
この項では、すべてのインストールおよびアップグレードの一般的な問題について説明します。
10.2.0.3パッチ・セットを適用してリポジトリをアップグレードする際に、アップグレードに失敗することがあります。
Grid Control環境を、10.1.0.4または10.1.0.5データベースの「新規データベースを使用したEnterprise Manager」オプションまたは「既存のデータベースを使用したEnterprise Manager」オプションを使用してインストールした場合は、10.2.0.3にアップグレードする前に、データベース・ホームでOracle Bug#4329444のパッチを適用してください。
（Oracle Bug#5648438、5665837）
ご使用の環境にパッチ5191377が適用されている場合は、10.2.0.3にアップグレードする前に、次の手順を行ってください。
個別パッチ5191377をロールバックします。
現行ディレクトリを、パッチがあるディレクトリに設定します。
% cd 5191377
次のコマンドを実行します。
% opatch rollback -id 5191377
リポジトリ所有者としてログインし、SQLプロンプトに対して次のコマンドを実行します。
SQL>drop index mgmt_current_violation_idx_05
（Oracle Bug#5758101）
キーが存在しないリポジトリに対してして追加のOMSのインストールを実行する場合、次のメッセージが表示されます。
「現在のManagement Serviceを保護するemkeyが、指定したリポジトリに存在しません。このインストールを続行する前に、最初のOracle Management Serviceインストールから"emctl prepare repository -new_oms_install"を実行してください。」
このメッセージで示されている、実行する必要があるコマンドは正しくありません。そのため、かわりに次の手順を行ってください。
データベースを再バウンスします。
emkey.oraを/OH/sysman/config/にコピーします。
./emctl config emkey -emkeyfile /OH/sysman/config/emkey.oraを実行します。
（Oracle Bug#5658897）
10.2.0.3.0 OMSのリポジトリを使用して追加の10.2.0.1.0 OMSのインストールを実行できません。
リポジトリがすでに10.2.0.3.0にアップグレードされている場合、次の回避策により追加のOMSをインストールできます。次の手順を実行します。
次のSQL文を使用して、リポジトリのリリースを10.2.0.3.0から10.2.0.1.0に変換します。
UPDATE sysman.mgmt_versions SET version = '10.2.0.1.0' where component_name='CORE'; commit;
データベース構成の指定画面のリポジトリの資格証明を指定して、「次」をクリックします。
次のSQL文を使用して、リポジトリのリリースを10.2.0.3.0に更新します。
UPDATE sysman.mgmt_versions SET version = '10.2.0.2.0' where component_name='CORE'; commit;
インストールを続行します。
（Oracle Bug#4910745）
この項では、エージェントの配置アプリケーションに関連する問題について説明します。
管理エージェントの配置の詳細は、次のURLから入手できる「Management Agent 10g R2の配置におけるベスト・プラクティス」ドキュメントを参照してください。
http://www.oracle.com/technology/products/oem/pdf/10gr2_agent_deploy_bp.pdf
ローカル・ホストのSCRATCH_PATHで指定されたディレクトリは、書込み可能であることが必要です。書込み不可の場合はアプリケーション・エラーが表示されます。（デフォルトではC:\tmpに設定されています。）
リモート・ホストのagentpush.propertiesファイルのnttempdirで指定されたディレクトリは、<username>_agentOHQuery.shのコピーに使用されるため、権限が必要です（クラスタの場合はNFSのインストール）。権限がない場合はアプリケーション・エラーが表示されます。（デフォルトではC:\tmpに設定されています。）
（Oracle Bug#5665925）
一部のマシンで既存のSSHが設定されており、新しい設定を手動で行うためにsshConnectivity.shを使用する場合は、古い設定をリストアするために、次の手順を手動で行う必要があります。
mv $HOME/.ssh/identity.pub.ri.bak $HOME/.ssh/identity.pub
mv $HOME/.ssh/identity.ri.bak $HOME/.ssh/identity
mv $HOME/.ssh/known_hosts.ri.bak $HOME/.ssh/known_hosts
mv $HOME/.ssh/config.ri.bak $HOME/.ssh/config
chmod 644 $HOME/.ssh/identity.pub
chmod 600 $HOME/.ssh/identity
chmod 644 $HOME/.ssh/known_hosts
chmod 644 $HOME/.ssh/config
詳細は、次のURLから入手できる『Management Agent 10g R2の配置におけるベスト・プラクティス』ドキュメントを参照してください。
http://www.oracle.com/technology/products/oem/pdf/10gr2_agent_deploy_bp.pdf
（Oracle Bug#5484944）
OMSでパッチ・セットを適用し、管理エージェントをエージェント・ダウンロード・キットから対話形式でインストールした場合、構成マネージャ登録ページで「登録のテスト登録」をクリックする前に「接続設定」をクリックすると、次のエラーが表示されてインストールを続行できなくなります。
Unable to locate Oracle Configuration Manager Trusted Keystore /scratch/DUMMY/.dummy/ccr/admin/security/certca( No such file or directory
（Oracle Bug#5591205）
この項では、OMSおよび管理エージェントに関連する問題について説明します。
『Oracle Enterprise Managerアドバンスト構成』の説明に従ってGrid Controlコンソールと管理サービスの間のサーバー・ロード・バランサを構成する際に、管理サービスによってクライアント・ブラウザがサーバー・ロード・バランサを省略して管理サービスのホストにリダイレクトされます。
たとえば、3つのOracle管理サービス（たとえばomshost1.example.com、omshost2.example.com、omshost3.example.com）と1つのサーバー・ロード・バランサ（slbhost.example.com）を含むGrid Control配置では、クライアント・ブラウザがhttp(s)://slbhost.example.com[:port]/emをリクエストすると、http(s)://omshost[1,2,3][:port]/emにリダイレクトされます。
URLのリダイレクト時にブラウザがロード・バランサを省略するのを回避するには、$ORACLE_HOME/sysman/config/httpd_em.confにあるOracle HTTP Serverの構成ファイルで定義されている*|ServerName|*ディレクティブを編集して、サーバー・ロード・バランサ・ホストの名前と一致させます。上の例の場合、ディレクティブは次のようになります。
ServerName slbhost.example.com
この回避策は、『Oracle Enterprise Managerアドバンスト構成』のGrid Controlコンソールに対してサーバー・ロード・バランサを使用する際のOracle HTTP Serverの構成に関する項で定義されている構成を行った上で実行する必要があります。
また、複数のOMSを設定する場合は、すべての管理サービスでこの回避策を実行する必要があります。
（Oracle Bug#5692755）
管理エージェントではメモリー・リークがあり、iASターゲットの監視中、一般的に大量のHTTPリクエストが管理エージェントに送信される際に増幅します。このリークは管理エージェントによって使用されるxdkコードにあり、Oracle Bug#5573534によって追跡されます。
この問題を解決するには、Oracle Bug#5573534の個別パッチを適用します。
（Oracle Bug#5575154、5573534）
2007年から始まる2005年エネルギ政策法により、サマータイムが1か月延長されたため、サマータイムを導入するアメリカ合衆国の州のスケジュールでは、次のルールが使用されます。
開始: 3月の第2日曜日
終了: 11月の第1日曜日
時間: ローカル時間の午前2時
新しいルールはJDK1.5.0_06に組み込まれています。詳細は、次のサイトで検索できます。
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6317178
パッチを適用してこの変更を反映させることをお薦めします。これを行わない場合、Grid Control（特にジョブ・システム）で予期しない動作が発生する可能性があります。たとえば、ジョブが予想より1時間遅くスケジュールされる場合があります。
詳細は、OracleMetalinkサイトのMetalink Note:359145.1（タイトルは「Impact of 2007 USA daylight savings changes on the Oracle database」）を参照してください。
（Oracle Bug#5351247）
OMSが保護およびロックされている場合は、管理エージェントの保護を解除できません。
（Oracle Bug#5531324）
次に関して翻訳されているオンライン・ヘルプはありません。
ターゲット・メトリック: Oracle Content DBのメトリック、Voicemail & Faxの記録サービス、JBossアプリケーション・サーバーのメトリック、Oracle BPEL Process Managerのメトリック、IBM WebSphere MQ Queue Managerのメトリック、Identity Managerサーバー・ターゲットのメトリック、Identity Managerリポジトリ・ターゲットのメトリック、Access Manager - Identityサーバーのメトリック、Access Manager - Accessサーバーのメトリック、Siebelサーバー・ターゲットのメトリック、Siebelコンポーネントのメトリック、Siebel GatewayターゲットのメトリックおよびSiebelコンポーネント・グループ・ターゲットのメトリック。
Application Server管理: Oracle BPEL Process Managerの管理、IBM WebSphere MQ Queue Managerの管理、Identity Federationサーバーの管理、JBoss Application Serverの管理、Identity Managerの管理、Access Manager - AccessサーバーとIdentityサーバーの管理、JBoss Partitionの管理およびIBM WebSphere MQ Clusterの管理。
ターゲット・ポリシー: Oracle Databaseのセキュアな構成、Oracle Real Application Clusterデータベースのセキュアな構成およびOracleリスナーのセキュアな構成。
管理操作: データ交換の管理、管理コネクタの管理、ポリシー・グループの管理およびSiebelターゲットの管理。
（Oracle Bug#5715773）
10.2.0.1製品から10.2.0.2パッチ・セット・リリースへのリポジトリのアップグレードは、SYSMANユーザーが即時使用可能なレポートを基に新しいレポートを作成した場合、つまり、類似作成機能を使用して即時使用可能なレポートと同じ名前でレポートを作成した場合に失敗します。この失敗は、10.2.0.2リリースに即時使用可能なレポートの新規コピーが含まれている場合のみ発生します。
この問題を解決するには、Enterprise Managerのスーパー管理者として新規作成レポートの名前を企業全体で一意の名前に変更するか、そのレポートを削除します。レポートの名前変更または削除を実行したら、アップグレード処理を再実行します。
（Oracle Bug#5225689）
シードを使用して10.2.0.3リリースにアップグレードした後、ローダー・エラーが表示されます。これは、ORA-01801エラーによってファイルを処理できないローダーに対応するOracle Bug#4482253によるものです。この問題はOracle Bug#3944226が原因で発生します。
この問題を解決するには、リポジトリ・データベースを再起動してみます。まだ問題が解決されない場合は、オラクル社カスタマ・サポート・センターに連絡してOracle Bug#3944226のパッチを入手してください。
（Oracle Bug#5614815）
この項では、パッチの管理に関連する問題について説明します。
CRSホームはルートに所有されています。ルート以外のユーザーがCRS pre-req DPを実行中で、ORACLE_HOMEの下にあるパッチ・ステージング・フォルダを指定した場合、権限に関連する問題が発生します。
この問題を解決するには、CRSホーム外のフォルダ（たとえば/tmp）に権限を付与して、パッチ適用ユーザーがパッチをステージングできるようにします。
（Oracle Bug#5686511）
Optachアップグレード・ステップが有効なすべてのデプロイメント・プロシージャのパッチ適用では、パッチが適用されるホームの正しいリリースのOptachパッチがソフトウェア・ライブラリにあることが必要です。Optachパッチをソフトウェア・ライブラリに手動でアップロードするか、Optachパッチ・ジョブを正常に実行する必要があります。このジョブは1回のみ実行する必要があります。このジョブを実行するには、ダンプ・ディレクトリを指定する必要があります。このディレクトリは「オフライン・パッチ適用の設定」ページで指定できます。このページを表示するには、「設定」を選択してから「パッチ適用設定」を選択します。
（Oracle Bug#5701915）
10.2.0.1 CRSでのパッチ・セットの適用時に、ユーザーがターゲットの資格証明で指定されており、CRSのターゲットまたはノードでのsudo権限を持たない場合は、「Oracleクラスタウェアへのパッチ適用」CRSデプロイメント・プロシージャをカスタマイズしてsudoステップをPAMステップとして実行し、さらにPAMコマンド・スクリプトを指定するのが理想的です。ただし、umask値を0022に設定するためにPAMコマンド・スクリプトを更新していない場合は、ループで次のエラーが表示され、デプロイメント・プロシージャの実行は「ルート・スクリプトの実行」ステップで停止します。
Startup will be queued to init within 90 seconds. /scratch/aime/CRS/crs/bin/crsctl.bin: error while loading shared libraries: libclntsh.so.10.1: cannot open shared object file: No such file or directory
この問題を解決するには、umask値を0022に設定するために、使用するPAMコマンド・スクリプトが更新されていることを確認してください。
（Oracle Bug#5691165）
CRSのパッチ適用デプロイメント・プロシージャは、Microsoft Windowsのターゲットではサポートされていません。
（Oracle Bug#5683930）
ホームの所有権の問題によりパッチ適用がOpatchのアップグレード・ステップで失敗した場合は、次の更新を使用してデプロイメント・プロシージャを実行します。
「opatchのアップグレード」ステップを無効にしてCRSホームのopatchのバージョンがパッチ適用要件を満たしていることを検証します。
パッチを適用するユーザーが書込み権限を持つ、CRSホームの外のディレクトリにパッチをステージングします。
（Oracle Bug#5704923）
パッチの適用にデプロイメント・プロシージャを使用した場合、RDBMSおよびASMの10.2.0.2.0および10.2.0.3.0のパッチ・セットの適用に失敗することがあります。この問題は、Microsoft Windowsのターゲットのみに関連します。デプロイメント・プロシージャは、この問題により「パッチの適用」ステップで失敗することがあります。
回避策として、「パッチの適用」ディレクティブを次のように変更します。
L1045: $runInst_loc_win = File::Spec -> catfile($runInst_loc_win, "oui.exe");
（Oracle Bug#5759231）
Microsoft Windowsでは、ASデプロイメント・プロシージャを使用してパッチを適用する際に、「Application Serverの停止」ステップでプロシージャが失敗します。これは、スクリプトでperlモジュールConfigが使用されていないためです。
この問題を解決するには、次の2つのディレクティブのスクリプトを変更して、スクリプトの最初の行にモジュールConfigをUse Configとして含めます。
Directive: Oracle Directives/Common/AS/All/Generic/PA_Startup_AS Name of script: pa_startup_as.pl Directive: Oracle Directives/Common/AS/All/Generic/PA_Shutdown_AS Name of the script: pa_shutdown_as.pl
（Oracle Bug#5757192）
この項では、クライアント側の監視の問題について説明します。
次のメッセージが表示されることがあります。
Formsトランザクションのビーコンからのデータがありません。
このメッセージが表示された場合は、次のことを試してください。
そのビーコンからのFormsトランザクションを検証します。
トランザクションが停止中の場合は、ビーコンの配置先の管理エージェントがWeb Cacheターゲットを監視しているかどうかをチェックします。
管理エージェントがWeb Cacheターゲットを監視している場合、Oracle Bug#5700255により、管理エージェントがFormsトランザクションを実行できないことを示します。
この問題を解決するには、異なる管理エージェントにFormsトランザクションを配置します。
（Oracle Bug#5700255）
Grid Controlで「ターゲット」、「すべてのターゲット」の順に選択し、ターゲットのリストから「管理サービスとリポジトリ」を選択すると、選択した管理サービスおよびリポジトリの「概要」ページが表示されます。このページで「エラー」タブを選択すると、次のエラーが表示されます。
Beacon Availability Computation n/a Nov 13, 2006 5:07:04 PM Error EXEC_AVAIL_JOB failed. Error: ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS2'
Grid Controlを既存のデータベースにインストールした場合、UNDO表領域は作成されません。この問題を解決するには、データベースにUNDO表領域がすでに存在しており、その領域が200MB以上あることを確認してください。
（Oracle Bug#5659103）
OMSの10.1.0.x、10.2.0.1または10.2.0.2の古いリリースからビーコンを10.2.0.3管理エージェントに追加するなどの特定のビーコン操作を行うと失敗します。操作が失敗すると、次のエラー・メッセージが表示されます。
Error: oracle.sysman.emSDK.emd.comm.CommException: SAXParseException in parsing Response :: Key columns cannot be transient or computed
これらの操作を正常に行うには、最初にOMSを10.2.0.3にアップグレードする必要があります。この目的のためだけにOMSをアップグレードしたくない場合は、Oracle Bug#5729053の個別パッチをダウンロードして、管理エージェントに適用できます。
（Oracle Bug#5729053）
OMSを（emoms.propertiesファイルで宣言した以外の）リモート・リポジトリで設定した場合、テスト・メタデータが正しく移入されないという問題が発生します。この問題の詳細は次のとおりです。
すべてのテスト・タイプでサービスを作成できません。
サービスの作成または編集のページに、テストが一切表示されません。
回避策は、次のコマンドを実行することです。
$ORACLE_HOME/jdk/jre/bin/java -classpath
$ORACLE_HOME/jdbc/lib/ojdbc14.jar:$ORACLE_HOME/sysman/jlib/emCORE.jar:$ORACLE_HOME/sysman/jlib/log4j-core.jar:$ORACLE_HOME/lib/servlet.jar:$ORACLE_HOME/jdbc/lib/orai18n.jar:$ORACLE_HOME/sysman/jlib/emagentSDK.jar
oracle.sysman.eml.gensvc.test.data.SeedMetadata "<<repository connect string>>" <<db_sysman_username>> <<db_sysman_password>> "$ORACLE_HOME"
Microsoft Windowsを使用している場合、変数は$VAR_NAMEではなく%VAR_NAME%になります。つまり、$ORACLE_HOMEは%ORACLE_HOME%になります。
（Oracle Bug#5584394）
テストベースのFormsアプリケーション・ターゲットを作成する場合、作成するターゲットのFormsトランザクションを記録する必要があります。トランザクションの監視を有効にするためにFormsサーバーがあらかじめ構成されていない場合は、記録に失敗します。ただし、「Formsトランザクション監視を有効にします」ページへのリンクは、すでに作成済のFormsアプリケーション・ターゲットのコンテキストのみで使用できます。
Formsアプリケーション・ターゲットをシステムベースとして作成してから「Formsトランザクション監視を有効にします」ページでFormsサーバーを構成し、Formsアプリケーション・ターゲットをテストベースに変更した後でトランザクションを記録する必要があります。
（Oracle Bug#5696760）
この項では、エンタープライズ統合の問題について説明します。
データ交換ハブを削除した後、そのハブに関連付けられている基礎となるセッションは削除されますが、アウトバウンド・データ交換セッションに関連付けられている基礎となるジョブは削除されません。この問題は、アウトバウンド・データ交換セッションのみで発生し、インバウンドのセッションでは発生しません。ジョブは、削除されないだけでなく、引き続きスケジュールされて実行されます。
この問題を解決するには、ハブを削除する前にこれらのセッションがある場合は削除します。もしくは、「ジョブ」ページに移動して、アウトバウンド・セッションに対応するすべてのジョブを削除します。
（Oracle Bug#5664615）
この項では、データベース管理の問題について説明します。
db2gcの実行中に、ターミナル・セッション・ウィンドウに次のエラーが表示される場合があります。
Invalid UTF8 encoding. : Start of root element expected
このエラーが発生するのは、ターミナル・セッション・ウィンドウのキャラクタ・セット・エンコーディングの設定がUTF8ベースではなく、現行ターゲットの表示名を変更してマルチバイト文字やネイティブ言語ベースの文字を含む名前に変更することを選択した場合のみです。
この問題を解決するには、次の処理を行います。
緊急の要求でない場合は、ターゲットの表示名を変更しません。
ターミナル・セッション・ウィンドウのキャラクタ・セット・エンコーディングの設定がUTF8ベースであることを確認します。設定が異なる場合は、UTF8に設定して再実行します。
（Oracle Bug#5724384）
db2gcユーティリティでは、RACデータベース・ターゲットのGrid Controlにメトリックのカスタマイズが移行されません。ターゲットの移行後に「すべてのメトリック」ページを表示して、必要に応じてメトリックしきい値または収集頻度（もしくはその両方）をカスタマイズしてください。
（Oracle Bug#5709028）
RACデータベースの「インスタンスの追加」操作の実行中にエラーが発生する場合があります。この問題を回避するには、ソース・ノードのinit.oraファイルに+ASM2.instance_number=2を追加し、srvctl stop asm -n destination_node_nameでASMインスタンスを停止し、srvctl start asm -n destination_node_nameで再起動します。これで、srvctl stop instance -d RAC_DB_NAME -i Destination_INSTANCE_NAMEでinstance2を正常に起動できます。
（Oracle Bug#5260570）
この項では、Application Serverの管理の問題について説明します。
リリース10.1.3のOracle HTTP Serverの「mod_oc4jメトリック」ページで正確な値を表示するには、Oracle Application Server 10.1.3.0インストールにパッチ5161311とパッチ5088239（OracleMetalinkのサイトで入手可能）を適用する必要があります。詳細は、パッチのREADMEを参照してください。
（Oracle Bug#5042008）
Grid Controlは、Oracle Application Serverリリース9.0.4の一部のインストールの検出に失敗します。これは、検出時に発生する内部エラーによるもので、Application ServerインスタンスにOracle Process Connectコンポーネントが含まれている場合に発生する傾向があります。ただし、エラー・メッセージは表示されません。
（Oracle Bug#5735044）
OMSが10.2.0.3にアップグレードされ、管理エージェントが10.2.0.2以前のリリースのままの場合は、BPEL Process Managerターゲット、つまりBPEL Process Managerリリース10.1.3.1のステータスは、常に「停止中」と表示されます。また、「プロセス」ページにプロセスがリストされません。
この問題を解決してプロセスを「プロセス」ページに表示するには、管理エージェントを10.2.0.3にアップグレードします。
正しいステータスを表示するには、次のいずれかを行います。
管理エージェントを10.2.0.3にアップグレードする。
管理エージェントに個別パッチ5708626を適用する。
一時的な解決策として、次の手順を実行する。
次のファイルを開きます。
${OH}/sysman/admin/metadata/oracle_integrationbpm.xml（エージェントOH）
「レスポンス」メトリックに移動して、実行記述子の次の行を探します。
<Filter COLUMN_NAME="opmn_process_type" OPERATOR="CONTAINS">OC4J_BPEL</Filter>
この行のOC4J_BPELを、BPELが実行されているOC4Jインスタンスの名前に置き換えます。たとえば、OC4Jインスタンスの名前がhomeの場合、変更後の行は次のようになります。
<Filter COLUMN_NAME="opmn_process_type" OPERATOR="CONTAINS">home</Filter>
ファイルを保存して${OH}/bin（エージェントOH）に移動し、次のコマンドを実行します。
emctl reload agent
（Oracle Bug#5708626、5704583）
Grid Controlのadminユーザーとして10.1.3.1 OC4Jを構成する際に、「OC4Jデータ収集の管理」ページの「ロギング有効化」をクリックしてエンドツーエンド・トレース機能を有効にすると、Application Server Controlにリダイレクトされます。
理想的な動作は、Application Server Controlにログインした後にOC4Jトレースのプロパティ構成ページにリダイレクトされることです。これに反して、Application Server Controlの「トポロジ」ページにリダイレクトされます。このページでは、適切なページへ移動するために手動でドリルダウンする必要があります。この問題は、アプリケーション・サーバー10.1.3.1リリースで発生します。
この問題を回避するには、Application Server Controlにログインした後「トポロジ」ページで適切なOC4Jインスタンスを選択して「管理」タブをクリックし、「サーバーのプロパティの編集」をクリックしてからページの最下部までスクロールして「トレースのプロパティ」をクリックします。
（Oracle Bug#5439369）
Grid Controlを使用してWeb層を再起動するためにデプロイメント・プロシージャを実行すると、Web層が再起動されたというメッセージが表示されて正常に終了しても、実際にはWeb層が再起動されていない場合があります。
この問題を解決するには、デプロイメント・プロシージャを実行する前に、ディレクティブmanuallymanagedclusterconfig.plを変更する必要があります。
ディレクティブmanuallymanagedclusterconfig.plを変更するには、次の手順を行います。
Grid Controlコンソールで「デプロイ」をクリックして「デプロイ」ページに移動します。
「デプロイ」ページで「プロビジョニング」をクリックして「ディレクティブ」タブを選択します。
表から「ディレクティブ」、「Oracleディレクティブ」、「myJ2EECompany プロビジョニング」の順に選択します。次に、「10.1.2.0.2」、「手動管理対象クラスタの構成」の順に選択します。
さらに、「編集」をクリックしてディレクティブの編集ページに移動します。
ディレクティブの編集ページで「ファイルのアップロード」タブをクリックします。
現在関連付けられているファイルmanuallymanagedclusterconfig.plをクリックしてコンテンツを表示します。
このファイルの内容をエディタ（メモ帳やワードパッドなど）にコピーします。
次の変更を行います。
関数parseCommandLineParams()の行番号135を、$hmpParams{"INSTALL_BASE"} = "true";から$hmpParams{"INSTALL_BASE"} = $ARGV[ $i + 1 ];に変更します。
同じく行番号140を、$hmpParams{"VIRTUAL_HOST"} = "true";から$hmpParams{"VIRTUAL_HOST"} = $ARGV[ $i + 1 ];に変更します。
変更したファイルをローカル・マシンにmanuallymangedclusterconfig.plとして保存します。
Grid Controlコンソールのディレクティブの編集ページの「ファイルのアップロード」タブには、現在関連付けられているファイルが表示されます。このページで「ローカル・マシンからアップロード」を選択します。
「参照」を選択して、手順9で保存したファイルmanuallymangedclusterconfig.plをアップロードします。
「終了」を選択します。
（Oracle Bug#5684224）
この項では、IDの管理の問題について説明します。
Identity Federationシステムの「インフラストラクチャ・パフォーマンス」タブにアクセスして「データの表示」メニューから「実行時間: 手動リフレッシュ」を選択すると、グラフは表示されますがデータが表示されません。
（Oracle Bug#5700277）
検出されたOracle Identity Managerのターゲットを既存のIdentity Managerシステムに関連付ける際に、内部例外が検出されます。そのため、Oracle Identity Managerコンポーネントの検出が完了せずに失敗します。
この問題を解決するには、Oracle Identity Managerコンポーネントを新しいIdentity Managerシステムに関連付けて検出します。その後、Grid Controlコンソールの「システム」タブから、検出したコンポーネントを既存のシステムに追加できます。
（Oracle Bug#5751839）
この項では、Siebelアプリケーションの管理の問題について説明します。
ビーコンの強化機能は、Microsoft Internet Explorer 7ブラウザではサポートされていません。これは、現在Siebelが、高レベル双方向性アプリケーションをMicrosoft Internet Explorer 7ブラウザ上ではサポートしていないためです。
提供されているサポートの詳細は、次のサイトを参照してください。
http://supportweb.siebel.com/support/private/content/knowledgedocs/enu/SOD/IE7-SOD.pdf
Windows XP P2上のMicrosoft Internet Explorer 7に対する今後のサポートに関する項を参照してください。このドキュメントの説明では、Microsoft Internet Exxplorer 7での高レベル双方向性アプリケーションのサポートはCYQ207の早い段階で提供されます。
（Oracle Bug#5724954）
管理エージェントはリモート再生機能を実行します。そのために、ブラウザを起動して記録されたスクリプトを再実行します。管理エージェントは、システム・アカウントの資格証明を使用して、Windowsサービスとして稼働します。システム・アカウントに適切な権限がない場合は、この機能が許可されません。
この問題は、Microsoft Windows 2003サーバーのビーコンで発生します。そのため、これらのホストでは、アプリケーションのステータスが常に「停止中」になり、収集されたメトリックには値がありません。この問題は、Windows 2000およびMicrosoft Windows XPのホストでは発生しません。
（Oracle Bug#5676927）
Grid Control 10.2.0.3.0リリースでは、Siebelサーバー内で有効なSiebelコンポーネントとコンポーネント・グループの合計数が71以上の場合は、サーバーの監視のサポートは提供されません。
（Oracle Bug#5724329）
Siebelサーバーのインストールが複数ある場合は、サーバーがインストールされているSiebelのホーム・ディレクトリがマシンごとに異なると、Siebelサーバーのコンポーネントの起動中および停止中に問題が発生する可能性があります。
Siebelサーバーのインストール・ディレクトリは、すべてのマシンで同じにしてください。それ以外の回避策としては、サーバー・マネージャ・ユーティリティから起動および停止の操作を実行します。
サーバー・マネージャ・ユーティリティの使用に関する詳細は、次のURLのドキュメントを参照してください。
（Oracle Bug#5747767）
Siebelターゲット、つまりSiebelサーバー、Siebel GatewayサーバーおよびSiebelコンポーネントの「構成の表示」ページのナビゲーションは動作しません。
この問題を解決するには、ナビゲーション・メニューから「すべて表示」オプションを使用します。
（Oracle Bug#5702824）
手動で追加したサービスは、サービス・ダッシュボードに反映されません。この問題を解決するには、次の処理を行います。
「レポート」をクリックします。
それぞれのサービス・ダッシュボードを選択して「編集」をクリックします。
「要素」、「パラメータを設定」リンクの順にクリックします。
新たに追加したサービスを追加して「続行」をクリックします。
「OK」をクリックします。
（Oracle Bug#5718696）
Grid Controlは、同じ名前を持つ2つのSiebel Enterpriseを処理できません。
（Oracle Bug#5654804）
この項では、ホストの管理の問題について説明します。
10.2.0.3のパッチをOMSに適用すると、Grid Controlによって、ターゲット・ホストのメモリー使用率が99%と報告される場合があります。
この問題を解決するには、「デプロイ」を選択して、そのページの「ホスト構成のリフレッシュ」をクリックします。「使用可能なホスト」から関連するホストを選択して「ホストのリフレッシュ」をクリックします。
（Oracle Bug#5141414）
Microsoft Windowsのホスト・ターゲットに対して「管理」タブが表示されますが、この機能はRedHat（RHEL4）およびSuse Linux（sles9）のホストに対してのみサポートされています。この問題への対応は次のパッチ・セットで行われます。
（Oracle Bug#5689719）
RHEL4またはsles9で完全エージェント・インストールまたはパッチ・エージェント・インストールを行った場合、SuseのYaSTパッチがすでにインストールされていても、必要なコンポーネントとパッチをインストールするように要求するUIが表示されます。
この問題を解決するには、次の処理を行います。
RHEL4またはsles9での完全エージェント・インストール
次のコマンドを実行してエージェントをバウンスします。
emctl stop agent
emctl start agent
RHEL4またはsles9でのパッチ・エージェント・インストール
次のコマンドを実行してエージェントをバウンスします。
emctl stop agent
emctl start agent
$ORACLE_HOME/sysman/admin/scriptsの権限を次のように変更します。
chmod 755 EM*.ycp
chmod 755 DiscoverYast2.pl
chmod 755 RunYast.sh
（Oracle Bug#5718456）
この項では、サード・パーティのアプリケーション・サーバーの監視の問題について説明します。
BEA WebLogicで管理されるサーバー・ターゲットの監視中に、メトリック収集エラーが発生する場合があります。その際には、次のようなエラー・メッセージが表示されます。
weblogic.rmi.extensions.RemoteRuntimeException: Unexpected Exception - with nested exception
このエラーは、1つの管理エージェントを使用して、JMXの特定のリリースと互換性のある1つのアプリケーション・サーバー・ターゲット、およびJMXの別のリリースと互換性のあるもう1つのアプリケーション・サーバー・ターゲットを監視している場合に発生します。たとえば、BEA WebLogicリリース8.1およびBEA WebLogicリリース9を同じ管理エージェントで監視すると、このエラーが表示されます。
この問題を解決するには、これらのターゲットを同じ管理エージェントで監視しないでください。1つのターゲットを1つの管理エージェントで監視し、別のターゲットを別の管理エージェントで監視してください。
（Oracle Bug#5458460）
IBM WebSphere Application Server、IBM WebSphere Application Server CellまたはBEA WebLogic Server Domainを検出した後は、管理エージェントを再起動してください。この再起動は、サード・パーティのアプリケーション・サーバーを初めて検出したときだけ要求されます。
（Oracle Bug#4451228）
英語版以外のMicrosoft Windowsまたはiso88591かUTF8以外のOSロケールのキャラクタ・セットを使用するLinuxにIBM MQシリーズがインストールされている場合は、Grid ControlからのMQターゲットの検出に失敗します。
この問題を解決するには、英語版のMicrosoft Windows、またはキャラクタセットiso88591かutf8を使用するOSロケールに、IBM MQシリーズをインストールします。たとえばen_US.iso88591およびzh_CN.utf8です。
（Oracle Bug#5722258）
オラクル社は、障害のあるお客様にもオラクル社の製品、サービスおよびサポート・ドキュメントを簡単にご利用いただけることを目標としています。オラクル社のドキュメントには、ユーザーが障害支援技術を使用して情報を利用できる機能が組み込まれています。HTML形式のドキュメントで用意されており、障害のあるお客様が簡単にアクセスできるようにマークアップされています。標準規格は改善されつつあります。オラクル社はドキュメントをすべてのお客様がご利用できるように、市場をリードする他の技術ベンダーと積極的に連携して技術的な問題に対応しています。オラクル社のアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/accessibility/を参照してください。
ドキュメント内のサンプル・コードのアクセシビリティについて
スクリーン・リーダーは、ドキュメント内のサンプル・コードを正確に読めない場合があります。コード表記規則では閉じ括弧だけを行に記述する必要があります。しかしJAWSは括弧だけの行を読まない場合があります。
外部Webサイトのドキュメントのアクセシビリティについて
このドキュメントにはオラクル社およびその関連会社が所有または管理しないWebサイトへのリンクが含まれている場合があります。オラクル社およびその関連会社は、それらのWebサイトのアクセシビリティに関しての評価や言及は行っておりません。
Oracleサポート・サービスへのTTYアクセス
アメリカ国内では、Oracleサポート・サービスへ24時間年中無休でテキスト電話（TTY）アクセスが提供されています。TTYサポートについては、 (800)446-2398にお電話ください。
次の各項に、各サービスに接続するためのURLを記載します。
オラクル製品サポートの購入方法、およびOracleサポート・サービスへの連絡方法の詳細は、次のURLを参照してください。
http://www.oracle.co.jp/support/
製品のマニュアルは、次のURLにあります。
http://otn.oracle.co.jp/document/
研修に関する情報とスケジュールは、次のURLで入手できます。
http://www.oracle.co.jp/education/
オラクル製品やサービスに関するその他の情報については、次のURLから参照してください。
http://www.oracle.co.jphttp://otn.oracle.co.jp
|
注意: ドキュメント内に記載されているURLや参照ドキュメントには、Oracle Corporationが提供する英語の情報も含まれています。日本語版の情報については、前述のURLを参照してください。 |
Oracle Enterprise Manager管理エージェント・リリース・ノート, 10gリリース3（10.2.0.3.0） for HP-UX Itanium
部品番号: E05385-01
原本名: Oracle Enterprise Manager Management Agent Release Notes, 10g Release 3 (10.2.0.3.0) for HP-UX Itanium
原本部品番号: E10089-01
Copyright © 2007, Oracle.All rights reserved.
制限付権利の説明
このプログラム（ソフトウェアおよびドキュメントを含む）には、オラクル社およびその関連会社に所有権のある情報が含まれています。このプログラムの使用または開示は、オラクル社およびその関連会社との契約に記された制約条件に従うものとします。著作権、特許権およびその他の知的財産権と工業所有権に関する法律により保護されています。
独立して作成された他のソフトウェアとの互換性を得るために必要な場合、もしくは法律によって規定される場合を除き、このプログラムのリバース・エンジニアリング、逆アセンブル、逆コンパイル等は禁止されています。
このドキュメントの情報は、予告なしに変更される場合があります。オラクル社およびその関連会社は、このドキュメントに誤りが無いことの保証は致し兼ねます。これらのプログラムのライセンス契約で許諾されている場合を除き、プログラムを形式、手段（電子的または機械的）、目的に関係なく、複製または転用することはできません。
このプログラムが米国政府機関、もしくは米国政府機関に代わってこのプログラムをライセンスまたは使用する者に提供される場合は、次の注意が適用されます。
U.S. GOVERNMENT RIGHTS
Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the Programs, including documentation and technical data, shall be subject to the licensing restrictions set forth in the applicable Oracle license agreement, and, to the extent applicable, the additional rights set forth in FAR 52.227-19, Commercial Computer Software--Restricted Rights (June 1987). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
このプログラムは、核、航空産業、大量輸送、医療あるいはその他の危険が伴うアプリケーションへの用途を目的としておりません。このプログラムをかかる目的で使用する際、上述のアプリケーションを安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。万一かかるプログラムの使用に起因して損害が発生いたしましても、オラクル社およびその関連会社は一切責任を負いかねます。
Oracle、JD Edwards、PeopleSoft、Siebelは米国Oracle Corporationおよびその子会社、関連会社の登録商標です。その他の名称は、他社の商標の可能性があります。
このプログラムは、第三者のWebサイトへリンクし、第三者のコンテンツ、製品、サービスへアクセスすることがあります。オラクル社およびその関連会社は第三者のWebサイトで提供されるコンテンツについては、一切の責任を負いかねます。当該コンテンツの利用は、お客様の責任になります。第三者の製品またはサービスを購入する場合は、第三者と直接の取引となります。オラクル社およびその関連会社は、第三者の製品およびサービスの品質、契約の履行（製品またはサービスの提供、保証義務を含む）に関しては責任を負いかねます。また、第三者との取引により損失や損害が発生いたしましても、オラクル社およびその関連会社は一切の責任を負いかねます。