Oracle® Fusion Middleware

Oracle Fusion Middlewareの管理

12c (12.2.1)

E69938-01(原本部品番号:E56161-02)

2015年12月

Oracle Fusion Middlewareの起動と停止、コンポーネントの構成と監視、環境のバックアップとリカバリ、およびテスト環境から本番環境への移行方法を含む、Oracle Fusion Middlewareの管理方法について説明する管理者向けのドキュメントです。

Oracle Fusion Middleware Oracle Fusion Middlewareの管理, 12c (12.2.1)

E69938-01

Copyright © 2009, 2015, Oracle and/or its affiliates.All rights reserved.

原本著者:  Helen Grembowicz

原本協力著者:  Vinaye Misra

協力者: Mike Blevins、Nick Fry、Greg Cook、Harry Hsu、Christine Jacobs、Srini Indla、Pavana Jain、Rama Kalava、Gopal Kirsur、Kenneth Ma、Dan MacKinnon、Manoj Nayak、Mark Nelson、Praveen Sampath、Sunita Sharma

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXはThe Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このガイドの最新情報

- リリース12cの新機能と変更された機能 12.2.1

- リリース12c (12.1.3)の新機能と変更された機能

- リリース12c (12.1.2)の新機能と変更された機能

第I部 Oracle Fusion Middlewareの理解

1 Oracle Fusion Middlewareの概要

- 1.1 Oracle Fusion Middlewareとは

- 1.2 Oracle Fusion Middlewareコンポーネント

第II部 基本的な管理

2 Oracle Fusion Middlewareの管理のスタート・ガイド

- 2.1 Oracle Fusion Middlewareの管理ツールの概要

- 2.2 Oracle Enterprise Manager Fusion Middleware Controlの使用のスタート・ガイド

- 2.2.1 Fusion Middleware Controlの表示

- 2.2.2 Fusion Middleware Controlヘルプの使用

- 2.2.3 Fusion Middleware Controlでのナビゲート

- 2.2.4 Fusion Middleware Controlのユーザーおよびロールの理解

- 2.2.5 WebLogic Serverの構成のロック

- 2.2.6 WebLogicドメインの表示と管理

- 2.2.7 Javaコンポーネントの表示と管理

- 2.2.8 システム・コンポーネントの表示と管理

- 2.3 Oracle WebLogic Server管理コンソールの使用のスタート・ガイド

- 2.4 WebLogic Scripting Tool (WLST)の使用のスタート・ガイド

- 2.4.1 JavaコンポーネントおよびOracle Fusion MiddlewareサービスとともにWLSTを使用する方法

- 2.4.2システム・コンポーネントでのWLSTコマンドの使用

- 2.5 Fusion Middleware Control MBeanブラウザの使用のスタート・ガイド

- 2.5.1 MBeanの理解

- 2.5.2 システムMBeanブラウザの使用

- 2.5.3 選択したアプリケーションのMBeanの使用

- 2.6 管理ユーザーのパスワードの変更

- 2.6.1 コマンド行を使用した管理ユーザーのパスワードの変更

- 2.6.2 Oracle Fusion Middlewareを使用した管理ユーザーのパスワードの変更

- 2.7 ノード・マネージャの構成

- 2.7.1 ノード・マネージャでの管理対象サーバーの起動の構成

- 2.7.2 OPSSキーストア・サービスを使用するためのノード・マネージャの構成

- 2.8 Oracle Fusion Middlewareの構成および管理の基本的なタスク

3 連携するコンポーネントのワイヤリング

- 3.1 サービス表の理解

- 3.2 サービス表の表示

- 3.3 コンポーネントのワイヤリング

- 3.3.1 Oracle HTTP Serverから管理サーバーへのワイヤリング

- 3.3.1.1 管理サーバーにOracle HTTP Serverをワイヤリングする理由

- 3.3.1.2 管理サーバーへのOracle HTTP Serverの接続

- 3.3.2 Oracle HTTP Serverを介してアプリケーションをOracle WebLogic Serverにルーティングする

4 Oracle Fusion Middlewareの起動と停止

- 4.1 起動および停止手順の概要

- 4.2 管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止

- 4.2.1 管理サーバーの起動と停止

- 4.2.2 ノード・マネージャの起動と停止

- 4.2.3 管理対象サーバーの起動と停止

- 4.2.3.1 Fusion Middleware Controlを使用した管理対象サーバーの起動と停止

- 4.2.3.2 スクリプトを使用した管理対象サーバーの起動と停止

- 4.2.4 資格証明を入力しないサーバーの起動の有効化

- 4.2.5 WindowsサービスとしてのOracle WebLogic Serverの設定

- 4.3 コンポーネントの起動と停止

- 4.3.1 Fusion Middleware Controlを使用したコンポーネントの起動と停止

- 4.3.2 コマンド行を使用したコンポーネントの起動と停止

- 4.3.2.1 Javaコンポーネントの起動と停止

- 4.3.2.2 システム・コンポーネントの起動と停止

- 4.4 Fusion Middleware Controlの起動と停止

- 4.5 アプリケーションの起動と停止

- 4.5.1 Fusion Middleware Controlを使用したJava EEアプリケーションの起動と停止

- 4.5.2 WLSTを使用したJava EEアプリケーションの起動と停止

- 4.6 Oracle Fusion Middleware環境の起動と停止

- 4.6.1 Oracle Fusion Middleware環境の起動

- 4.6.2 Oracle Fusion Middleware環境の停止

- 4.7 起動と停止: 特殊なトピック

- 4.7.1 高可用性環境での起動と停止

- 4.7.2 Oracle Databaseの強制停止

5 ポートの管理

- 5.1 ポートの管理について

- 5.2 ポート番号の表示

- 5.2.1 コマンド行を使用したポート番号の表示

- 5.2.2 Fusion Middleware Controlを使用したポート番号の表示

- 5.3 Oracle Fusion Middlewareで使用するポート番号の変更

- 5.3.1 Oracle WebLogic Serverリスニング・ポートの変更

- 5.3.1.1 Fusion Middleware Controlを使用したOracle WebLogic Serverリスニング・ポートの変更

- 5.3.1.2 WLSTを使用したOracle WebLogic Serverリスニング・ポートの変更

- 5.3.2 ノード・マネージャのリスニング・ポートの変更

- 5.3.2.1 WLSTを使用したノード・マネージャのリスニング・ポートの変更

- 5.3.2.2 Fusion Middleware Controlを使用したノード・マネージャのリスニング・ポートの変更

- 5.3.3 Oracle HTTP Serverリスニング・ポートの変更

- 5.3.3.1 1024未満に設定されたポート使用時のOracle HTTP Serverのroot実行の有効化(UNIXのみ)

- 5.3.3.2 WebLogic ServerドメインでのOracle HTTP Serverの非SSLリスニング・ポートの変更

- 5.3.3.3 WebLogic ServerドメインでのOracle HTTP ServerのSSLリスニング・ポートの変更

- 5.3.3.4 スタンドアロン・ドメインでのOracle HTTP Serverリスニング・ポートの変更

- 5.3.4 Oracle Database Netリスナー・ポートの変更

- 5.3.4.1 IPCリスナーのKEY値の変更

第III部 セキュアな通信

6 Oracle Fusion MiddlewareでのSSLの構成

- 6.1 SSLのしくみ

- 6.1.1 SSLの機能

- 6.1.2 秘密鍵と公開鍵の暗号化について

- 6.1.3 キーストアおよびウォレット

- 6.1.4 SSLセッションのしくみ

- 6.2 Oracle Fusion MiddlewareにおけるSSLについて

- 6.2.1 Oracle Fusion MiddlewareアーキテクチャにおけるSSL

- 6.2.2 キーストアおよびOracleウォレット

- 6.2.3 Oracle Fusion MiddlewareでのTLSプロトコルのサポート

- 6.2.4 Oracle Fusion Middlewareでの認証モード

- 6.2.5 SSL構成用ツール

- 6.3 構成ツールでのSSLの構成

- 6.3.1 Oracle Enterprise Manager Fusion Middleware Control

- 6.3.2 Oracle WebLogic Server管理コンソール

- 6.3.3 WLSTコマンド行ツール

- 6.4 Web層でのSSLの構成

- 6.4.1 ロード・バランサの構成

- 6.4.2 Oracle HTTP Server仮想ホストでのSSLの有効化

- 6.4.2.1 Fusion Middleware Controlを使用したOracle HTTP Server仮想ホストへのインバウンド・リクエストでのSSLの有効化

- 6.4.2.2 WLSTを使用したOracle HTTP Server仮想ホストへのインバウンド・リクエストでのSSLの有効化

- 6.4.2.3 Oracle HTTP Serverからのアウトバウンド・リクエストでのSSLの有効化

- 6.4.2.3.1 一方向SSLの有効化

- 6.4.2.3.2 双方向SSLの有効化

- 6.5 中間層でのSSLの構成

- 6.5.1 Oracle WebLogic ServerでのSSLの構成

- 6.5.1.1 Oracle WebLogic ServerへのインバウンドSSLの構成

- 6.5.1.2 Oracle WebLogic ServerからのアウトバウンドSSLの構成

- 6.5.1.2.1 Oracle Platform Security ServicesからLDAPへのアウトバウンドSSLの構成

- 6.5.1.2.2 Oracle Platform Security ServicesからOracle DatabaseへのアウトバウンドSSLの構成

- 6.5.1.2.3 LDAPオーセンティケータからLDAPへのアウトバウンドSSLの構成

- 6.5.1.2.4 データベースへのアウトバウンドSSLの構成

- 6.5.2 アプリケーションのクライアント側のSSL

- 6.6 データ層でのSSLの構成

- 6.6.1 データベースでのSSLの構成

- 6.6.1.1 Oracle DatabaseでのSSLの有効化

- 6.6.1.2 データ・ソースでのSSLの有効化

- 6.7 高度なSSLの使用事例

- 6.7.1 ハードウェア・セキュリティ・モジュールとアクセラレータ

- 6.7.2 CRLとSSLとの統合

- 6.7.2.1 コンポーネントのCRL検証の構成

- 6.7.2.2 ファイル・システムでのCRLの管理

- 6.7.2.3 CRL検証が構成されたコンポーネントのテスト

- 6.7.3 Oracle Fusion MiddlewareのFIPS 140-2の設定

- 6.8 SSLのベスト・プラクティス

- 6.8.1 管理者のベスト・プラクティス

- 6.8.2 アプリケーション開発者のベスト・プラクティス

- 6.9 SSL関連のWLSTリファレンス

7 キーストア、ウォレットおよび証明書の管理

- 7.1 Oracle Fusion Middlewareでの鍵および証明書の保存

- 7.1.1 キーストアのタイプ

- 7.1.1.1 Oracleウォレットについて

- 7.1.1.2 JKSキーストアについて

- 7.1.1.3 キーストア・サービス(KSS)キーストアについて

- 7.1.2 キーストア管理ツール

- 7.2 キーストアおよびウォレット用コマンド行インタフェース

- 7.2.1 コマンド行インタフェースの起動方法

- 7.3 キーストア管理

- 7.4 ウォレットの管理

- 7.4.1 ウォレットおよび証明書について

- 7.4.1.1 パスワードで保護されたウォレットと自動ログイン・ウォレットについて

- 7.4.1.2 自己署名付きウォレットとサード・パーティのウォレットについて

- 7.4.1.3 インスタンス間でのウォレットの共有

- 7.4.1.4 ウォレットの命名規則

- 7.4.1.5 JDK7でのウォレットの要件

- 7.4.2 Fusion Middleware Controlのウォレット管理ページへのアクセス

- 7.4.3 ウォレットのライフサイクルの管理

- 7.4.4 一般的なウォレットの操作

- 7.4.4.1 ウォレットの作成

- 7.4.4.1.1 Fusion Middleware Controlを使用したウォレットの作成

- 7.4.4.1.2 WLSTを使用したウォレットの作成

- 7.4.4.2 自己署名付きウォレットの作成

- 7.4.4.2.1 Fusion Middleware Controlを使用した自己署名付きウォレットの作成

- 7.4.4.2.2 WLSTを使用した自己署名付きウォレットの作成

- 7.4.4.3 自己署名付きウォレットのサード・パーティのウォレットへの変更

- 7.4.4.4 ウォレットのエクスポート

- 7.4.4.4.1 Fusion Middleware Controlを使用したウォレットのエクスポート

- 7.4.4.4.2 WLSTを使用したウォレットのエクスポート

- 7.4.4.5 ウォレットのインポート

- 7.4.4.5.1 Fusion Middleware Controlを使用したウォレットのインポート

- 7.4.4.5.2 WLSTを使用したウォレットのインポート

- 7.4.4.6 ウォレットの削除

- 7.4.4.6.1 Fusion Middleware Controlを使用したウォレットの削除

- 7.4.4.6.2 WLSTを使用したウォレットの削除

- 7.4.5 証明書のライフサイクルの管理

- 7.4.6 Fusion Middleware Controlのウォレットの証明書管理ページへのアクセス

- 7.4.7 一般的な証明書の操作

- 7.4.7.1 証明書リクエストの追加

- 7.4.7.1.1 Fusion Middleware Controlを使用した証明書リクエストの追加

- 7.4.7.1.2 WLSTを使用した証明書リクエストの追加

- 7.4.7.2 証明書、証明書リクエストまたは信頼できる証明書のエクスポート

- 7.4.7.2.1 Fusion Middleware Controlを使用した証明書、証明書リクエストまたは信頼できる証明書のエクスポート

- 7.4.7.2.2 WLSTを使用した証明書、証明書リクエストまたは信頼できる証明書のエクスポート

- 7.4.7.3 証明書または信頼できる証明書のインポート

- 7.4.7.3.1 Fusion Middleware Controlを使用した証明書または信頼できる証明書のインポート

- 7.4.7.3.2 WLSTを使用した証明書または信頼できる証明書のインポート

- 7.4.7.4 証明書リクエスト、証明書または信頼できる証明書の削除

- 7.4.7.4.1 Fusion Middleware Controlを使用した証明書リクエスト、証明書または信頼できる証明書の削除

- 7.4.7.4.2 WLSTを使用した証明書リクエスト、証明書または信頼できる証明書の削除

- 7.4.7.5 自己署名付き証明書のサード・パーティ証明書への変換

- 7.4.7.5.1 Fusion Middleware Controlを使用したサード・パーティ証明書への自己署名証明書の変換

- 7.4.7.5.2 WLSTを使用したサード・パーティ証明書への自己署名証明書の変換

- 7.4.8 ウォレットおよび証明書の保守

- 7.4.8.1 ウォレットの場所

- 7.4.8.2 ホスト名変更のウォレットへの影響

- 7.4.8.2.1 本番ウォレットに対する新しい証明書のリクエスト

- 7.4.8.2.2 自己署名付きウォレットに対する新しい証明書のリクエスト

- 7.4.8.3 自己署名付きウォレットのサード・パーティのウォレットへの変更

- 7.4.8.4 ウォレット内の期限が切れそうな証明書の置換え

8 Oracle Fusion MiddlewareでのFIPS 140のサポート

- 8.1 FIPS標準について

- 8.2 Oracle Fusion Middlewareリリース12c (12.2.1)でのFIPS 140-2について

- 8.2.1 FIPS 140-2検証済ライブラリについて

- 8.2.2 プロバイダおよびアルゴリズムの選択について

- 8.3 FIPS 140によりサポートされているコンポーネント

- 8.4 業務系FIPS 140-2環境の一般的なシナリオ

- 8.5 FIPS 140問題のトラブルシューティング

- 8.5.1 スタンドアロンWebLogic ServerにおけるFIPS 140のトラブルシューティング

- 8.5.2 Oracle Platform Security ServicesにおけるFIPS 140のトラブルシューティング

- 8.5.3 Oracle Web Services ManagerにおけるFIPS 140のトラブルシューティング

- 8.5.4 データベースおよびJDBCドライバにおけるFIPS 140のトラブルシューティング

第IV部 アプリケーションのデプロイ

9 デプロイ・プロセスの理解

- 9.1 デプロイヤとは

- 9.2 アプリケーション設計から本番デプロイへの一般的な移行手順

- 9.2.1 アプリケーションの設計および開発

- 9.2.2 管理対象サーバーへのアプリケーションのデプロイ

- 9.2.3 他の環境へのアプリケーションの移行の自動化

- 9.3 一般的な問題の診断

10 アプリケーションのデプロイ

- 10.1 アプリケーションのデプロイの概要

- 10.1.1 デプロイ可能なアプリケーションのタイプ

- 10.1.2 デプロイ、再デプロイおよびアンデプロイの理解

- 10.2 データ・ソースの理解と管理

- 10.2.1 データ・ソースの理解

- 10.2.2 JDBCデータ・ソースの作成と管理

- 10.2.2.1 Fusion Middleware Controlを使用したJDBCデータ・ソースの作成

- 10.2.2.2 Fusion Middleware Controlを使用したJDBCデータ・ソースの編集

- 10.2.2.3 Fusion Middleware Controlを使用したJDBCデータ・ソースのモニタリング

- 10.2.2.4 Fusion Middleware Controlを使用したJDBCデータ・ソースの管理

- 10.2.2.5 Fusion Middleware Controlを使用したGridLinkデータ・ソースの作成

- 10.3 Java EEアプリケーションのデプロイ、アンデプロイおよび再デプロイ

- 10.3.1 Java EEアプリケーションのデプロイ

- 10.3.1.1 Fusion Middleware Controlを使用したJava EEアプリケーションのデプロイ

- 10.3.1.2 WLSTを使用したJava EEアプリケーションのデプロイ

- 10.3.2 Java EEアプリケーションのアンデプロイ

- 10.3.2.1 Fusion Middleware Controlを使用したJava EEアプリケーションのアンデプロイ

- 10.3.2.2 WLSTを使用したJava EEアプリケーションのアンデプロイ

- 10.3.3 Java EEアプリケーションの再デプロイ

- 10.3.3.1 Fusion Middleware Controlを使用したJava EEアプリケーションの再デプロイ

- 10.3.3.2 WLSTを使用したJava EEアプリケーションの再デプロイ

- 10.4 Oracle ADFアプリケーションのデプロイ、アンデプロイおよび再デプロイ

- 10.4.1 Oracle ADFアプリケーションのデプロイ

- 10.4.1.1 Fusion Middleware Controlを使用したADFアプリケーションのデプロイ

- 10.4.1.2 WLSTを使用したADFアプリケーションのデプロイ

- 10.4.1.3 管理コンソールを使用したADFアプリケーションのデプロイ

- 10.4.2 Oracle ADFアプリケーションのアンデプロイ

- 10.4.3 Oracle ADFアプリケーションの再デプロイ

- 10.5 SOAコンポジット・アプリケーションのデプロイ、アンデプロイおよび再デプロイ

- 10.5.1 SOAコンポジット・アプリケーションのデプロイ

- 10.5.2 SOAコンポジット・アプリケーションのアンデプロイ

- 10.5.3 SOAコンポジット・アプリケーションの再デプロイ

- 10.6 WebCenter Portalアプリケーションのデプロイ、アンデプロイおよび再デプロイ

- 10.6.1 WebCenter Portalアプリケーションのデプロイ

- 10.6.2 WebCenter Portalアプリケーションのアンデプロイ

- 10.6.3 WebCenter Portalアプリケーションの再デプロイ

- 10.7 デプロイメント・プランの管理

- 10.8 Fusion Middleware Controlでの一般的なデプロイ・タスクについて

- 10.9 デプロイされたアプリケーションでのMDS構成属性の変更

- 10.9.1 Fusion Middleware Controlを使用したMDS構成属性の変更

- 10.9.2 WLSTを使用したMDS構成の変更

- 10.9.3 アプリケーションの元のMDS構成のリストア

第V部 Oracle Fusion Middlewareのモニタリング

11 Oracle Fusion Middlewareのモニタリング

- 11.1 Oracle Fusion Middlewareのステータスのモニタリング

- 11.1.1 Oracle WebLogic Serverドメインのモニタリング

- 11.1.2 Oracle WebLogic Serverの管理サーバーや管理対象サーバーのモニタリング

- 11.1.3 クラスタのモニタリング

- 11.1.4 Javaコンポーネントのモニタリング

- 11.1.5 システム・コンポーネントのモニタリング

- 11.1.6 Java EEアプリケーションのモニタリング

- 11.1.7 ADFアプリケーションのモニタリング

- 11.1.8 SOAインフラストラクチャおよびSOAコンポジット・アプリケーションの監視

- 11.1.9 Oracle WebCenter Portalアプリケーションの監視

- 11.1.10 クラスタにデプロイされたアプリケーションのモニタリング

- 11.1.11 コマンド行を使用したコンポーネントのステータスのモニター

- 11.2 Oracle Fusion Middlewareのパフォーマンスの表示

12 ログ・ファイルと診断データの管理

- 12.1 Oracle Fusion Middlewareのロギングの概要

- 12.1.1 Oracle Fusion Middleware HTTPアクセス・ロギングの理解

- 12.1.2 Oracle Fusion Middleware診断ロギングの理解

- 12.2 ODLメッセージおよびODLログ・ファイルの理解

- 12.3 ログ・ファイルの表示と検索

- 12.3.1 ログ・ファイルおよびそのメッセージの表示

- 12.3.1.1 Fusion Middleware Controlを使用したログ・ファイルおよびそのメッセージの表示

- 12.3.1.2 WLSTを使用したログ・ファイルおよびそのメッセージの表示

- 12.3.2 ログ・ファイルの検索

- 12.3.2.1 Fusion Middleware Controlを使用したログ・ファイルの検索

- 12.3.2.1.1 ログ・ファイルの検索: 基本検索

- 12.3.2.1.2 ログ・ファイルの検索: 拡張検索

- 12.3.2.2 WLSTを使用したログ・ファイルの検索

- 12.3.3 ログ・ファイルのダウンロード

- 12.3.3.1 Fusion Middleware Controlを使用したログ・ファイルのダウンロード

- 12.3.3.2 Fusion Middleware Controlを使用した特定のコンポーネントのログ・ファイルのダウンロード

- 12.3.3.3 Fusion Middleware Controlを使用した特定のタイプのメッセージのダウンロード

- 12.3.3.4 WLSTを使用したログ・ファイルのダウンロード

- 12.4 ログ・ファイルの設定の構成

- 12.4.1 ログ・ファイルの場所の変更

- 12.4.1.1 Fusion Middleware Controlを使用したログ・ファイルの場所の変更

- 12.4.1.2 WLSTを使用したログ・ファイルの場所の変更

- 12.4.2 ログ・ファイルのローテーションの構成

- 12.4.2.1 Fusion Middleware Controlを使用したログ・ファイル・ローテーションの指定

- 12.4.2.2 WLSTを使用したログ・ファイル・ローテーションの指定

- 12.4.3 ログ・ファイルに書き込まれる情報レベルの設定

- 12.4.3.1 Fusion Middleware Controlを使用したログ・ファイルのメッセージ・レベルの構成

- 12.4.3.2 Fusion Middleware Controlを使用したロガーのメッセージ・レベルの構成

- 12.4.3.3 WLSTを使用したメッセージ・レベルの構成

- 12.4.4 ログ・ファイル形式の指定

- 12.4.4.1 Fusion Middleware Controlを使用したログ・ファイル形式の指定

- 12.4.4.2 WLSTを使用したログ・ファイル形式の指定

- 12.4.5 ログ・ファイルのロケールの指定

- 12.4.5.1 WLSTを使用したログ・ファイルのエンコーディングの指定

- 12.4.5.2 logging.xmlでのログ・ファイルのエンコーディングの指定

- 12.5 ログ・ファイルおよびコンポーネント間のメッセージの関連付けの理解

- 12.5.1 メッセージの関連付けでのECIDおよびRIDの理解

- 12.5.2 メッセージおよびコンポーネント間のメッセージの関連付け

- 12.6 トレースの構成

- 12.6.1 QuickTraceの構成と使用

- 12.6.1.1 QuickTraceの理解

- 12.6.1.2 QuickTraceの構成

- 12.6.1.2.1 Fusion Middleware Controlを使用したQuickTraceの構成

- 12.6.1.2.2 WLSTを使用したQuickTraceの構成

- 12.6.1.3 ファイルへのトレース・メッセージの書込み

- 12.6.1.3.1 Fusion Middleware Controlを使用したトレース・メッセージのファイルへの書き込み

- 12.6.1.3.2 WLSTを使用したトレース・メッセージのファイルへの書き込み

- 12.6.1.4 WLSTを使用したQuickTraceの無効化

- 12.6.2 選択的トレースの構成と使用

- 12.6.2.1 選択的トレースの理解

- 12.6.2.2 選択的トレースの構成

- 12.6.2.2.1 Fusion Middleware Controlを使用した選択的トレースの構成

- 12.6.2.2.2 WLSTを使用した選択的トレースの構成

- 12.6.2.3 選択的トレースの表示

- 12.6.2.3.1 Fusion Middleware Controlを使用した選択的トレースの表示

- 12.6.2.3.2 WLSTを使用した選択的トレースの表示

- 12.6.2.4 選択的トレースの無効化

- 12.6.2.4.1 Fusion Middleware Controlを使用した選択的トレースの無効化

- 12.6.2.4.2 WLSTを使用した選択的トレースの無効化

13 問題の診断

- 13.1 診断フレームワークの理解

- 13.1.1 インシデントと問題について

- 13.1.1.1 インシデントのフラッド制御

- 13.1.2 診断フレームワークのコンポーネント

- 13.1.2.1 自動診断リポジトリ

- 13.1.2.2 診断ダンプ

- 13.1.2.3 管理MBean

- 13.1.2.4 診断フレームワーク用WLSTコマンド

- 13.1.2.5 ADRCIコマンド行ユーティリティ

- 13.2 診断フレームワークの動作

- 13.3 診断フレームワークの構成

- 13.3.1 診断フレームワークの設定の構成

- 13.3.2 カスタム診断ルールの構成

- 13.3.3 問題抑制の構成

- 13.3.4 問題キー・フィルタの取得

- 13.3.5 診断フレームワーク用のWLDFポリシーおよびアクションの構成

- 13.4 問題の調査、報告および解決

- 13.4.1 ロードマップ—問題の調査、報告および解決

- 13.4.2 問題およびインシデントの確認

- 13.4.2.1 問題の確認

- 13.4.2.2 インシデントの確認

- 13.4.2.3 インシデントの問合せ

- 13.4.3 特定の問題キーの分析

- 13.4.4 診断ダンプの処理

- 13.4.4.1 診断ダンプの一覧表示

- 13.4.4.2 診断ダンプの説明の表示

- 13.4.4.3 ダンプの実行

- 13.4.5 診断ダンプ・サンプリングの構成と使用

- 13.4.5.1 診断ダンプ・サンプリングの理解

- 13.4.5.2 ダンプ・サンプリングの構成

- 13.4.5.2.1 デフォルト・サンプルのアクティブ化

- 13.4.5.2.2 ダンプ・サンプリングの作成

- 13.4.5.2.3 ダンプ・サンプリング設定の変更

- 13.4.5.2.4 ダンプ・サンプリングの削除

- 13.4.5.2.5 すべてのダンプ・サンプリングの有効化または無効化

- 13.4.5.3 ダンプ・サンプリングのリスト

- 13.4.5.4 ダンプ・サンプリング出力の取得

- 13.4.5.4.1 executeDumpコマンドを使用したダンプ・サンプルの取得

- 13.4.5.4.2 getSamplingArchivesコマンドを使用したダンプ・サンプルの取得

- 13.4.6 インシデントの管理

- 13.4.6.1 インシデントの手動作成

- 13.4.6.2 集計インシデントの作成

- 13.4.6.3 インシデントのパッケージ化

- 13.4.6.4 インシデントのパージ

- 13.4.7 RDAレポートの生成

- 13.5 ヘルス・テスト・フレームワークの管理および実行

- 13.5.1 ヘルス・テスト・フレームワークの理解

- 13.5.2 ヘルス・テスト・フレームワークのファイル・リポジトリの理解

- 13.5.3 ヘルス・テスト・フレームワークのコマンド行の使用方法

- 13.5.3.1 dfwhealthtestadminctl.shコマンド行

- 13.5.3.1.1 help

- 13.5.3.1.2 register

- 13.5.3.1.3 index

- 13.5.3.2 dfwhealthtestctl.shコマンド行

- 13.5.3.2.1 desctest

- 13.5.3.2.2 help

- 13.5.3.2.3 listrun

- 13.5.3.2.4 listtest

- 13.5.3.2.5 report

- 13.5.3.2.6 run

- 13.5.3.2.7 status

- 13.5.4 ヘルス・テスト・フレームワークの管理

- 13.5.4.1 リポジトリの作成およびヘルス・テスト・フレームワーク・テストの登録

- 13.5.4.2 ヘルス・テスト・フレームワークの索引の再構築

- 13.5.5 ヘルス・テスト・フレームワークの診断テストの実行

- 13.5.6 ヘルス・テスト・フレームワークの診断テストの検索

- 13.5.7 ヘルス・テスト・フレームワーク・テストの説明の取得

- 13.5.8 ヘルス・テスト・フレームワークのテスト・ランのリスト

- 13.5.9 ヘルス・テスト・フレームワークのレポートの生成

第VI部 高度な管理

14 メタデータ・リポジトリの管理

- 14.1 メタデータ・リポジトリの理解

- 14.2 データベース・ベース・メタデータ・リポジトリの作成

- 14.3 MDSリポジトリの管理

- 14.3.1 MDSリポジトリの理解

- 14.3.1.1 MDSでサポートされるデータベース

- 14.3.1.2 MDS操作の理解

- 14.3.2 データベース・ベースのMDSリポジトリの登録および登録解除

- 14.3.2.1 データベース・ベースのMDSリポジトリの登録

- 14.3.2.1.1 Fusion Middleware Controlを使用したデータベース・ベースのMDSリポジトリの登録

- 14.3.2.1.2 WLSTを使用したデータベース・ベースのMDSリポジトリの登録

- 14.3.2.2 MDSリポジトリをターゲットとする追加サーバーの設定

- 14.3.2.3 メタデータ・リポジトリをターゲットとするサーバーの削除

- 14.3.2.4 データベース・ベースのMDSリポジトリの登録解除

- 14.3.2.4.1 Fusion Middleware Controlを使用したデータベース・ベースのMDSリポジトリの登録解除

- 14.3.2.4.2 WLSTを使用したデータベース・ベースのMDSリポジトリの登録解除

- 14.3.3 ファイルベースのMDSリポジトリの登録および登録解除

- 14.3.3.1 ファイルベースのMDSリポジトリの作成および登録

- 14.3.3.2 ファイルベースのMDSリポジトリの登録解除

- 14.3.4 システム・データ・ソースの変更

- 14.3.5 システムMBeanを使用したMDSリポジトリの管理

- 14.3.6 MDSリポジトリに関する情報の表示

- 14.3.6.1 Fusion Middleware Controlを使用したMDSリポジトリに関する情報の表示

- 14.3.6.2 システムMBeanを使用したMDSリポジトリに関する情報の表示

- 14.3.7 アプリケーションでの別のMDSリポジトリまたはパーティションの使用の構成

- 14.3.7.1 パーティションのクローニング

- 14.3.7.2 新しいパーティションの作成とアプリケーションの再関連付け

- 14.3.8 ソース・システムからターゲット・システムへのメタデータの移動

- 14.3.8.1 Fusion Middleware Controlを使用したメタデータの転送

- 14.3.8.2 WLSTを使用したメタデータの転送

- 14.3.9 ファイルベース・リポジトリからデータベース・ベース・リポジトリへの移動

- 14.3.10 リポジトリからのメタデータ・パーティションの削除

- 14.3.10.1 Fusion Middleware Controlによるメタデータ・パーティションの削除

- 14.3.10.2 WLSTによるメタデータ・パーティションの削除

- 14.3.11 メタデータ・バージョン履歴のパージ

- 14.3.11.1 Fusion Middleware Controlによるメタデータ・バージョン履歴のパージ

- 14.3.11.2 WLSTによるメタデータ・バージョン履歴のパージ

- 14.3.11.3 自動パージの有効化

- 14.3.12 MDSリポジトリでのメタデータ・ラベルの管理

- 14.3.12.1 メタデータ・ラベルの理解

- 14.3.12.2 メタデータ・ラベルの作成

- 14.3.12.3 メタデータ・ラベルの一覧表示

- 14.3.12.4 メタデータ・ラベルの昇格

- 14.3.12.5 メタデータ・ラベルのパージ

- 14.3.12.5.1 Fusion Middleware Controlを使用したメタデータ・ラベルのパージ

- 14.3.12.5.2 WLSTを使用したメタデータ・ラベルのパージ

- 14.3.12.6 メタデータ・ラベルの削除

- 14.4 メタデータ・リポジトリ・スキーマの管理

- 14.4.1 メタデータ・リポジトリ・スキーマ・パスワードの変更

- 14.4.1.1 ほとんどのコンポーネントのスキーマ・パスワードの変更

- 14.4.1.2 Oracle Platform Security Servicesのスキーマ・パスワードの変更

- 14.4.2 メタデータ・リポジトリの文字セットの変更

- 14.5 データのパージ

- 14.5.1 Oracle Infrastructure Webサービスのデータのパージ

15 ネットワーク構成の変更

- 15.1 Oracle Fusion Middlewareのネットワーク構成の変更

- 15.1.1 管理サーバーのネットワーク構成の変更

- 15.1.2 管理対象サーバーのネットワーク構成の変更

- 15.1.3 Oracle HTTP Serverのネットワーク構成の変更

- 15.2 データベースのネットワーク構成の変更

- 15.3 ネットワーク接続のオン/オフの切替え

- 15.3.1 ネットワーク接続のオフからオンへの変更(静的IPアドレス)

- 15.3.2 ネットワーク接続のオフからオンへの変更(DHCP)

- 15.3.3 ネットワーク接続のオンからオフへの変更(静的IPアドレス)

- 15.4 静的IPアドレスとDHCPの切替え

- 15.4.1 静的IPアドレスからDHCPへの切替え

- 15.4.2 DHCPから静的IPアドレスへの切替え

- 15.5 IPv6の使用

- 15.5.1 Oracle HTTP ServerでIPv6を使用する場合の構成

- 15.5.2 Oracle SOA SuiteおよびFusion Middleware Controlでのデュアル・スタックの使用

第VII部 高度な管理: バックアップとリカバリ

16 バックアップとリカバリの概要

- 16.1 Oracle Fusion Middlewareのバックアップとリカバリの理解

- 16.1.1 管理サーバーで発生した障害の影響

- 16.1.2管理対象サーバーの独立(MSI)モード

- 16.1.3 管理対象サーバーでの構成の変更

- 16.2 Oracle Fusion Middlewareのディレクトリ構造

- 16.3 バックアップおよびリカバリで使用するツール

- 16.4 Oracle Fusion Middlewareコンポーネントのバックアップおよびリカバリに関する推奨事項

- 16.4.1 Oracle WebLogic Server JMSのバックアップとリカバリの推奨事項

- 16.4.2 Oracle BPEL Process Managerのバックアップおよびリカバリに関する推奨事項

- 16.5 前提と制限

17 環境のバックアップ

- 17.1 バックアップ計画の概要

- 17.1.1 バックアップのタイプ

- 17.1.2 バックアップ・アーティファクト

- 17.1.3 推奨されるバックアップ戦略

- 17.2 データのバックアップに関する制限事項

- 17.3 バックアップの実行

- 17.3.1 全体オフライン・バックアップの実行

- 17.3.2 ランタイム・アーティファクトのオンライン・バックアップの実行

- 17.3.3 Windowsレジストリ・エントリのバックアップ

- 17.4 Oracle Fusion Middleware構成の記録の作成

18 環境のリカバリ

- 18.1 リカバリ戦略の概要

- 18.1.1 リカバリのタイプ

- 18.1.2 推奨されるリカバリ戦略

- 18.2 データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

- 18.2.1 Oracleホームのリカバリ

- 18.2.2 Oracle WebLogic Serverドメインのリカバリ

- 18.2.2.1 サーバー全体の移行を使用したOracle WebLogic Serverのリカバリ

- 18.2.3 スタンドアロン・ドメインのリカバリ

- 18.2.4 管理サーバー構成のリカバリ

- 18.2.5 管理対象サーバーのリカバリ

- 18.2.6 コンポーネントのリカバリ

- 18.2.6.1 Oracle Platform Security Servicesのリカバリ

- 18.2.6.2 Oracle B2Bのリカバリ

- 18.2.6.3 Oracle WebCenter Portal分析のリカバリ

- 18.2.6.4 Oracle WebCenter Contentのリカバリ

- 18.2.6.5 Oracle BI Enterprise Editionのリカバリ

- 18.2.6.5.1 LDAPデータベースとRPDの調整

- 18.2.6.5.2 LDAPデータベースとOracle BI Presentation Catalogの調整

- 18.2.7 クラスタのリカバリ

- 18.2.8 アプリケーションのリカバリ

- 18.2.8.1 アプリケーション・アーティファクトのリカバリ

- 18.2.8.2 Java EEアプリケーションのリカバリ

- 18.2.9 データベースのリカバリ

- 18.3 ホスト破損後のリカバリ

- 18.3.1 Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ

- 18.3.2スタンドアロン・ドメイン・ホストの破損後のリカバリ

- 18.3.2.1 同じホストへのスタンドアロン・ドメインのリカバリ

- 18.3.2.2 別のホストへのスタンドアロン・ドメインのリカバリ

- 18.3.3 管理サーバー・ホストの破損後のリカバリ

- 18.3.3.1 同じホストへの管理サーバーのリカバリ

- 18.3.3.2 別のホストへの管理サーバーのリカバリ

- 18.3.4 管理対象サーバー・ホストの破損後のリカバリ

- 18.3.4.1 同じホストへの管理対象サーバーのリカバリ

- 18.3.4.2 別のホストへの管理対象サーバーのリカバリ

- 18.3.5 コンポーネント・ホスト破損後のリカバリ

- 18.3.5.1 同じホストまたは別のホストへのJavaコンポーネントのリカバリ

- 18.3.5.2 別のホストへのJavaコンポーネントのリカバリ

- 18.3.5.3 同じホストまたは別のホストへのシステム・コンポーネントのリカバリ

- 18.3.5.4 ホスト破損後のOracle SOA Suiteのリカバリ

- 18.3.5.5 別のホストへのWeb層コンポーネントのリカバリ

- 18.3.5.5.1 スタンドアロン・ドメインのOracle HTTP Serverを別のホストにリカバリする

- 18.3.5.5.2 WebLogic ServerドメインのOracle HTTP Serverを別のホストにリカバリする

- 18.3.5.6 別のホストへのOracle Forms Servicesのリカバリ

- 18.3.5.7 別のホストへのOracle Reportsのリカバリ

- 18.3.5.8 別のホストへのOracle BI Enterprise Editionのリカバリ

- 18.3.5.8.1 非クラスタ化環境での別のホストへのOracle BI EEのリカバリ

- 18.3.5.8.2 クラスタ化環境での別のホストへのOracle BI EEのリカバリ

- 18.3.5.8.3 Oracle BI EEレジストリ・エントリのインポート

- 18.3.5.9 別のホストへのOracle Business Intelligence Publisherのリカバリ

- 18.3.5.10 別のホストへのOracle Data Integratorのリカバリ

- 18.3.5.10.1 Oracle Data Integratorリポジトリのリカバリ

- 18.3.5.10.2 別のホストへのOracle Data Integratorエージェントのリカバリ

- 18.3.5.11 別のホストへのOracle WebCenter Contentのリカバリ

- 18.3.6 ホストの破損後にエンティティをリカバリするための追加の操作

- 18.3.6.1 別のホストへのFusion Middleware Controlのリカバリ

- 18.3.6.2 mod_wl_ohs.confファイルの変更

- 18.3.6.3 特定のコンポーネントの新しいマシンの作成

- 18.3.6.4 Oracleインベントリの更新

- 18.3.6.5 Windowsレジストリのリカバリ

- 18.3.7 データベース・ホストの破損後のリカバリ

第VIII部 高度な管理: 環境の拡張

19 環境のスケール・アップ

- 19.1 環境のスケール・アップの概要

- 19.2 ドメインの拡張による追加コンポーネントのサポート

- 19.3 ドメインへの管理対象サーバーの追加

- 19.3.1 管理対象サーバーまたはクラスタへのOracle JRFテンプレートの適用

- 19.4 クラスタの作成

- 19.5 スタンドアロン・ドメインおよびシステム・コンポーネントの作成

- 19.6 WebLogic Serverドメインでのシステム・コンポーネント・インスタンスの作成

- 19.7 Oracleホームおよびドメインのコピー

20 テスト環境から本番環境への移行

- 20.1 Oracle Fusion Middlewareコンポーネントの移行の概要

- 20.2 環境の移行の計画

- 20.2.1 移行スクリプトの概要

- 20.2.2 ソース環境の確認

- 20.2.3 移行スクリプトがキーストアを処理する方法の理解

- 20.2.4 ターゲット環境の準備

- 20.2.5 ソースからターゲットへの移行に関する制限事項

- 20.2.6 ソース環境からターゲット環境への移行手順の概要

- 20.3 ターゲット環境への移行の一般的な手順

- 20.3.1 ターゲット環境でのデータベースのインストール

- 20.3.2 スクリプトを使用したOracleホームおよびバイナリ・ファイルの移行

- 20.3.3 ストレージ・レベルのクローニング・ツールを使用したOracleホームおよびバイナリ・ファイルの移行

- 20.3.4 WebLogic Serverドメインの構成の移行

- 20.3.5 スタンドアロン・ドメインの構成の移行

- 20.3.6 ノード・マネージャの構成の移行

- 20.3.7 ユーザーおよびグループの構成

- 20.3.8 SSL専用の環境での追加考慮事項

- 20.3.9 管理対象サーバーおよびコンポーネントの起動

- 20.4 特定のコンポーネントに対する追加の手順または情報

- 20.4.1 Oracle Data Integrator移行のための追加手順

- 20.4.2 Oracle B2B移行のための追加手順

- 20.4.3 Oracle Business Process Management移行のための追加手順

- 20.4.4 Oracle Forms Services移行のための追加手順

- 20.4.5 Oracle Traffic Director移行のための追加手順

- 20.4.6 Oracle WebCenter Portal移行のための追加手順

- 20.4.6.1 Oracle WebCenter Portalデータのターゲット環境への移行(オプション)

- 20.4.6.2 スペースに関連するOracle WebCenter Contentのドキュメントおよびフォルダの移行(オプション)

- 20.4.6.3 ターゲット環境へのディスカッション・サーバーのデータの移行(オプション)

- 20.4.7 Oracle WebCenter Contentの移行の追加情報および手順

- 20.4.8 Oracle WebCenter Sites移行のための追加手順

- 20.5 アーティファクトの漸進的な移行

- 20.6 分散トポロジの移行

- 20.6.1 複数ホスト環境での考慮事項

- 20.6.2 Oracle RAC環境への移行またはOracle RAC環境からの移行に関する考慮事項

- 20.7 テストから本番への移行におけるエラーのリカバリ

第IX部 付録

A 移行スクリプトおよび移動計画

- A.1 移行スクリプトの理解

- A.1.1 Javaオプションの指定

- A.1.2 移行スクリプトの構文

- A.1.2.1 copyBinaryスクリプト

- A.1.2.2 pasteBinaryスクリプト

- A.1.2.3 Oracle WebLogic Serverドメイン用copyConfigスクリプト

- A.1.2.4 スタンドアロン・ドメイン用copyConfigスクリプト

- A.1.2.5 ノード・マネージャ用のcopyConfigスクリプト

- A.1.2.6 extractMovePlanスクリプト

- A.1.2.7 Oracle WebLogic Serverドメイン用pasteConfigスクリプト

- A.1.2.8 スタンドアロン・ドメイン用pasteConfigスクリプト

- A.1.2.9 ノード・マネージャ用のpasteConfigスクリプト

- A.1.2.10 obfuscatePasswordスクリプトとAPI

- A.2 移動計画の使用

- A.2.1 移動計画の変更

- A.2.2 configGroup要素の場所

- A.2.3 移動計画のプロパティ

B Oracle Fusion Middlewareコマンド行ツール

C コンポーネントのURL

D ポート番号

- D.1 コンポーネント別のポート番号

- D.2 ポート番号(番号順)

E Oracle Fusion Middlewareのアクセシビリティ・オプションの使用

- E.1 Java Access Bridgeのインストールおよび構成(Windowsのみ)

- E.2 Fusion Middleware Controlアクセシビリティ・モードの有効化

- E.2.1 HTMLページに対するアクセスのしやすさの強化

- E.2.2 Fusion Middleware Controlグラフのテキスト説明の表示

- E.3 Fusion Middleware Controlのキーボード・ナビゲーション

F リリース番号の確認

- F.1 リリース番号の書式

- F.2 ソフトウェア・インベントリおよびリリース番号の確認

- F.2.1 Oracle Fusion Middlewareインストールのリリース番号の確認

- F.2.2 Oracle WebLogic Serverのリリース番号の確認

- F.2.3 コンポーネント・リリース番号の確認

- F.2.4 メタデータ・リポジトリのリリース番号の確認

- F.2.5 スキーマのリリース番号の確認

G orapki

- G.1 証明書とCRLの管理にorapkiユーティリティを使用する方法

- G.1.1 orapkiの概要

- G.1.1.1 orapkiの構文

- G.1.1.2 orapkiの環境設定

- G.1.2 orapkiヘルプの表示

- G.1.3 テスト用の署名付き証明書の作成

- G.1.4 orapkiユーティリティを使用したOracleウォレットの管理

- G.1.4.1 orapkiを使用したOracleウォレットの作成と表示

- G.1.4.1.1 Oracleウォレットの作成

- G.1.4.1.2 自動ログインが有効なOracleウォレットの作成

- G.1.4.1.3 AES暗号化によるOracleウォレットの作成

- G.1.4.1.4 AES暗号化を使用するように既存のウォレットを変換

- G.1.4.1.5 Oracleウォレットの表示

- G.1.4.2 orapkiを使用した証明書と証明書リクエストのOracleウォレットへの追加

- G.1.4.2.1 証明書リクエストのOracleウォレットへの追加

- G.1.4.2.2 信頼できる証明書のOracleウォレットへの追加

- G.1.4.2.3 ルート証明書のOracleウォレットへの追加

- G.1.4.2.4 ユーザー証明書のOracleウォレットへの追加

- G.1.4.3 orapkiを使用した証明書と証明書リクエストのOracleウォレットからのエクスポート

- G.1.4.3.1 証明書のOracleウォレットからのエクスポート

- G.1.4.3.2 証明書リクエストのOracleウォレットからのエクスポート

- G.1.4.4 信頼フラグの作成と管理

- G.1.4.4.1 信頼フラグをサポートするウォレットの作成

- G.1.4.4.2 信頼フラグをサポートするようにウォレットを変換

- G.1.4.4.3 証明書の信頼フラグの追加と更新

- G.1.4.4.4 信頼フラグを含む証明書のウォレットへの追加

- G.1.4.5 PKCS#12ファイルのOracleウォレットへのインポート

- G.1.5 orapkiユーティリティを使用した証明書失効リスト(CRL)の管理

- G.1.5.1 証明書失効リストを使用した証明書の検証について

- G.1.5.1.1 使用するCRL

- G.1.5.1.2 CRLチェックのしくみ

- G.1.5.2 証明書失効リストの管理

- G.1.5.2.1 証明書検証用ハッシュ値によるCRLの名前変更

- G.1.6 orapkiユーティリティ・コマンドのサマリー

- G.1.6.1 orapki cert create

- G.1.6.1.1 用途

- G.1.6.1.2 構文

- G.1.6.2 orapki cert display

- G.1.6.2.1 用途

- G.1.6.3 orapki crl create

- G.1.6.3.1 用途

- G.1.6.3.2 構文

- G.1.6.4 orapki crl hash

- G.1.6.4.1 用途

- G.1.6.4.2 構文

- G.1.6.5 orapki crl revoke

- G.1.6.5.1 用途

- G.1.6.5.2 構文

- G.1.6.6 orapki crl status

- G.1.6.6.1 用途

- G.1.6.6.2 構文

- G.1.6.7 orapki crl verify

- G.1.6.7.1 用途

- G.1.6.7.2 構文

- G.1.6.8 orapki wallet add

- G.1.6.8.1 用途

- G.1.6.8.2 構文

- G.1.6.9 orapki wallet change_pwd

- G.1.6.9.1 用途

- G.1.6.9.2 構文

- G.1.6.10 orapki wallet create

- G.1.6.10.1 用途

- G.1.6.10.2 構文

- G.1.6.11 orapki wallet enable_trust_flags

- G.1.6.11.1 用途

- G.1.6.11.2 構文

- G.1.6.12 orapki wallet assign_trust_flags

- G.1.6.12.1 用途

- G.1.6.12.2 構文

- G.1.6.13 orapki wallet display

- G.1.6.13.1 用途

- G.1.6.13.2 構文

- G.1.6.14 orapki wallet export

- G.1.6.14.1 用途

- G.1.6.14.2 構文

- G.1.6.15 orapki wallet export_trust_chain

- G.1.6.15.1 用途

- G.1.6.15.2 構文

- G.1.6.16 orapki wallet import_pkcs12

- G.1.6.16.1 用途

- G.1.6.16.2 構文

H Oracle Fusion Middlewareのトラブルシューティング

- H.1 Oracle Fusion Middlewareの障害の診断

- H.2 一般的な障害と解決策

- H.2.1 データ・ソース接続の不足

- H.2.2 異なるバージョンのSpringの使用

- H.2.3 管理対象サーバー起動時のClassNotFoundエラー

- H.3 SSLのトラブルシューティング

- H.3.1 コンポーネントですべてのサポートされている暗号が有効になる場合がある

- H.3.2 特定のブラウザで必要なSSL証明書チェーン

- H.3.3 JDK7の証明書ではkeyUsage拡張機能が必要

- H.4 FIPS構成のトラブルシューティング

- H.5 追加情報

- H.5.1 Remote Diagnostic Agentの使用

図一覧

- 6-1 SSLハンドシェイク

- 6-2 Oracle Fusion MiddlewareにおけるSSL

- 8-1 FIPS 140プロバイダの選択

- 13-1 Oracle Fusion MiddlewareのADRディレクトリ構造

- 13-2 インシデント・ログ検出で生成されるインシデント作成

- 13-3 WLDFポリシーおよびアクションによって生成されるインシデント作成

- 13-4 問題調査のフロー

- 17-1 バックアップのタイプを判断するためのフロー・チャート

- 20-1 環境を移行するためのフローチャート

- F-1 Oracle Fusion Middlewareのリリース番号の例

表一覧

- 2-1 Fusion Middleware ControlとWebLogic Server管理コンソールの比較

- 2-2 Fusion Middleware Controlでのナビゲート

- 2-3 Fusion Middleware Controlでサポートされているロール

- 2-4 サポートされているロールの権限

- 2-5 システム・コンポーネント用WLSTコマンド

- 6-1 Oracle Fusion MiddlewareコンポーネントでのTLS v1.2のサポート

- 7-1 Oracle Fusion Middlewareのキーストアのタイプ

- 8-1 Oracle Fusion MiddlewareでFIPS 140-2がサポートされているコンポーネント

- 8-2 FIPS 140-2のシナリオ

- 9-1 Oracle JDeveloperの拡張機能

- 10-1 アプリケーションをデプロイするツール

- 10-2 デプロイされたアプリケーションでのMDS構成属性

- 12-1 ODL形式メッセージのフィールド

- 12-2 Oracle Fusion Middlewareコンポーネントのログ・ファイルの場所

- 12-3 診断メッセージのタイプとレベル

- 12-4 ODL、Oracle WebLogic ServerおよびJava間のログ・レベルのマッピング

- 13-1 診断フレームワークのDiagnosticConfig MBeanの属性

- 13-2 LogDetectionConditions要素の条件

- 13-3 defaultActions要素に対するオプションの引数

- 13-4 ruleCondition要素の属性

- 13-5 問題抑制フィルタのDiagnosticConfig MBeanの操作および属性

- 13-6 捕えられていない例外の問題キー

- 13-7 診断ダンプ操作

- 13-8 デフォルトの診断ダンプ・サンプリング構成

- 13-9 ヘルス・テスト・フレームワークのdfwhealthtestadminctl.shコマンド

- 13-10 ヘルス・テスト・フレームワークのdfwhealthtestctl.shコマンド

- 14-1 MDSの操作と必要なロール

- 14-2 データのパージに関する情報

- 16-1 バックアップとリカバリの推奨事項

- 18-1 特定のコンポーネントの追加のリカバリ手順

- 20-1 移行スクリプトのサポート

- 20-2 新しい環境への移行に追加の手順を必要とするコンポーネント

- A-1 移行スクリプト

- A-2 copyBinaryスクリプトのオプション

- A-3 pasteBinaryスクリプトのオプション

- A-4 Oracle WebLogic Serverドメイン用copyConfigスクリプトのオプション

- A-5 スタンドアロン・ドメイン用copyConfigスクリプトのオプション

- A-6 ノード・マネージャ用のcopyConfigスクリプトのオプション

- A-7 extractMovePlanスクリプトのオプション

- A-8 Oracle WebLogic Serverドメイン用pasteConfigスクリプトのオプション

- A-9 スタンドアロン・ドメイン用pasteConfigスクリプトのオプション

- A-10 ノード・マネージャ用のpasteConfigスクリプトのオプション

- A-11 コンポーネントの移動計画のプロパティ

- A-12 スタンドアロン・ドメインのノード・マネージャの移動計画のプロパティ

- A-13 Javaコンポーネントの移動計画の共通プロパティ

- A-14 Oracle ADF接続の移動計画のプロパティ

- A-15 Oracle Coherenceの移動計画のプロパティ

- A-16 Oracle Web Services Managerの移動計画のプロパティ

- A-17 Oracle HTTP Serverの移動計画のプロパティ

- A-18 Oracle SOA Suiteの移動計画のプロパティ

- A-19 Oracle Business Activity Monitoringの移動計画のプロパティ

- A-20 Oracle Service Busの移動計画のプロパティ

- A-21 Oracle User Messaging Serviceの移動計画のプロパティ

- A-22 Oracle B2BおよびOracle B2B for Healthcareの移動計画のプロパティ

- A-23 Oracle Enterprise Schedulerの移動計画のプロパティ

- A-24 Oracle Managed File Transferの移動計画のプロパティ

- A-25 Oracle Traffic Directorの移動計画のプロパティ

- A-26 WebCenter Content Server、RecordsおよびInbound Refineryの移動計画のプロパティ

- A-27 Oracle WebCenter Content: Imagingの移動計画のプロパティ

- A-28 Oracle WebCenter Captureの移動計画のプロパティ

- A-29 Oracle Data Integratorの移動計画のプロパティ

- B-1 Oracle Fusion Middlewareコマンド行ツール

- C-1 コンポーネントのURL

- D-1 ポート番号(コンポーネント順)

- D-2 ポート番号(番号順)

- E-1 共通タスクのキーボード・ナビゲーション

- G-1 Oracleウォレット証明書の信頼フラグ

はじめに

このガイドでは、Oracle Fusion Middlewareの起動と停止、ポートの変更、アプリケーションのデプロイ、Oracle Fusion Middlewareのバックアップとリカバリ、そしてソース環境(テスト環境など)からターゲット環境(本番環境など)への環境の移行など、Oracle Fusion Middlewareを管理する方法について説明します。

対象読者

このガイドは、Oracle Fusion Middlewareの管理者を対象としています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middleware 12c (12.2.1)ドキュメンテーション・セットの次のドキュメントを参照してください。

- Oracle Fusion Middlewareの理解

- Oracle Platform Security Servicesによるアプリケーションの保護

- 高可用性ガイド

- Oracle WebLogic Serverの理解

- パフォーマンスのチューニング

- Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理

- Oracle HTTP Server管理者ガイド

- Webサービスの管理

表記規則

本文では、次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するグラフィカル・ユーザー・インタフェース要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック

イタリックは、特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、パラグラフ内のコマンド、URL、例に記載されているコード、画面に表示されるテキスト、または入力するテキストを示します。

このガイドの最新情報

ここでは、このガイドで説明するOracle Fusion Middlewareの新しい管理機能と変更された管理機能について説明し、追加情報の参照先を示します。

リリース12cの新機能と変更された機能 12.2.1

次のトピックでは、Oracle Fusion Middlewareの新機能と変更された機能について、およびこのガイドに記載または参照されているその他の重要な変更について紹介し、詳細情報へのリンクを提供します。

- 以前のリリースでは、Oracle WebLogic Server、システム・コンポーネントまたはJavaコンポーネント(Oracle SOA Suiteなど)のどれに対してコマンドを使用しているかに応じて異なる場所からWLSTを呼び出していました。このリリースでは、次の場所からWLSTを呼び出します。

(UNIX) ORACLE_HOME/oracle_common/common/bin/wlst.sh
(Windows) ORACLE_HOME\oracle_common\common\bin\wlst.cmd

- 連絡先および識別子を含むOracle B2Bの新しい移動計画プロパティ。表A-22を参照してください。

- WLDF監視および通知はポリシーおよびアクションに名前が変更されました。第13.3.5項を参照してください。

- 別のFIPSコンプライアンス機能が追加されました。表8-1と表8-2を参照してください。

リリース12c (12.1.3)の新機能と変更された機能

次のトピックでは、Oracle Fusion Middlewareの新機能と変更された機能について、およびこのガイドに記載または参照されているその他の重要な変更について紹介し、詳細情報へのリンクを提供します。

- ノード・マネージャによるOPSSキーストア・サービスのサポート。ノード・マネージャの構成の詳細は、第2.7.2項を参照してください。

- OPSSキーストア・サービスの新しい環境への移行に関するサポートの向上。第20.2.3項を参照してください。また、キーストア・サービスに関連する移動計画のプロパティは、表A-13も参照してください。

- 次のコンポーネントを新しい環境に移行するためのサポート。

- Oracle User Messaging Service。移動計画のプロパティは、表A-21を参照してください。

- Oracle Managed File Transfer。移動計画のプロパティは、表A-24を参照してください。

- Oracle Enterprise Data Quality (Javaコンポーネント用の移動計画のプロパティを使用)。表A-13を参照してください。

移行スクリプトをサポートしているコンポーネントの詳細なリストは、表20-1を参照してください。

- Oracle B2Bの移動計画のプロパティの拡張。表A-22を参照してください。

- Oracleウォレット用のAES暗号化のサポート。第G.1.4.1.3項および第G.1.4.1.4項を参照してください。

- Oracleウォレットでの証明書の信頼フラグのサポート。第G.1.4.4項を参照してください。

- PKCS#12ファイルのOracleウォレットへのインポート機能。第G.1.4.5項を参照してください。

- Oracle Fusion MiddlewareでのFIPS 140のサポート。第8章を参照してください。

リリース12c (12.1.2)の新機能と変更された機能

次のトピックでは、Oracle Fusion Middlewareの新機能と変更された機能について、およびこのガイドに記載または参照されているその他の重要な変更について紹介し、詳細情報へのリンクを提供します。このマニュアルは、以前『Oracle Fusion Middleware管理者ガイド』と呼ばれていたマニュアルの新しいエディションです。

- Oracleホームが再定義され、Middlewareホームは使用しなくなりました。『Oracle Fusion Middlewareの理解』の12 cの新規用語および非推奨用語に関する項を参照してください。

- OPMNは、Oracle Fusion Middlewareでは使用されなくなりました。かわりに、システム・コンポーネントはWLST、ノード・マネージャおよびpackとunpackをはじめとするWebLogic Management Frameworkにより管理されます。『Oracle Fusion Middlewareの理解』のWebLogic Management Frameworkに関する項を参照してください。

- 「ドメインごと」ノード・マネージャのサポート。『Oracle Fusion Middlewareの理解』の「ノード・マネージャとは」を参照してください。

- Oracle Web CacheはOracle Fusion Middlewareの一部ではなくなりました。

- ソース環境からターゲット環境への移行での変更。

- Oracleホームが最適意義され、また、Middlewareホームが使用されなくなったため、スクリプトの一部のパラメータが変更されました。第A.1.2項を参照してください。

- スタンドアロン・ドメインの移行をサポート。第20.3.5項を参照してください。

- ストレージ・レベルのクローニング・ツールを使用したOracleホームおよびバイナリ・ファイルの移行をサポート。第20.3.3項を参照してください。

- Oracle Coherenceの移動計画。表A-15を参照してください。

- Oracle Web Services Managerの移動計画。表A-16を参照してください。

- OPSSキーストア・サービスが導入されました。第7.1.1.3項を参照してください。

- Oracle WebLogic ServerのSSL手順が更新されました。第6.5.1項を参照してください。

- Fusion Middleware Controlがクロス・コンポーネント・ワイヤリングをサポートするようになりました。第3.3項を参照してください。

- Oracle Fusion Middlewareにサービス表が導入されました。この表を使用すると、サービスに関するエンドポイント情報をサービス・プロバイダがパブリッシュでき、また、サービスのクライアントはこれらのサービスを問合せ、バインドできます。第3.1項を参照してください。

- スタンドアロン・ドメインのリカバリ手順を含み、バックアップとリカバリの手順が更新されました。第18章を参照してください。

- 診断インシデントの問合せに対するサポートが拡張されました。第13.4.2.3項を参照してください。

- 集計インシデントの作成がサポートされるようになりました。第13.4.6.2項を参照してください。

- アクセス・ログの拡張ログ・フォーマットがサポートされるようになりました。第12.1.1項を参照してください。

第I部

Oracle Fusion Middlewareの理解

この部では、Oracle Fusion Middlewareの概要、およびOracle Fusion Middlewareの管理と関連する概念について説明します。

第I部の内容は次のとおりです。

- 第1章「Oracle Fusion Middlewareの概要」

1 Oracle Fusion Middlewareの概要

Oracle Fusion Middlewareは、アプリケーション開発ツールや統合ソリューションから、ID管理、コラボレーションおよびビジネス・インテリジェンス・レポートに至るまでの幅広い製品群を含む包括的なファミリです。この章では、Oracle Fusion Middlewareの概要について説明します。

次の項目について説明します。

- Oracle Fusion Middlewareとは

- Oracle Fusion Middlewareコンポーネント

このマニュアルやその他のマニュアルに記載されている用語の定義については、「用語集」を参照してください。

1.1 Oracle Fusion Middlewareとは

Oracle Fusion Middlewareは、標準ベースのソフトウェア製品の集合であり、その範囲は、Java EEや開発者向けツールから、統合サービス、アイデンティティ管理、ビジネス・インテリジェンスおよびコラボレーションといったツールやサービスにまで及びます。Oracle Fusion Middlewareは、開発、デプロイおよび管理において完全なサポートを提供します。

Oracle Fusion Middlewareの概念の詳細は、『Oracle Fusion Middlewareの理解』を参照してください。

1.2 Oracle Fusion Middlewareコンポーネント

Oracle Fusion Middlewareには、次のようなコンポーネントが用意されています。

- Oracle WebLogic Serverは、エンタープライズ対応のJavaアプリケーション・サーバーです。堅牢、セキュア、高可用でスケーラブルな環境におけるミッション・クリティカルなアプリケーションのデプロイメントをサポートします。Oracle WebLogic Serverは、サービス指向アーキテクチャ(SOA)に基づいたアプリケーションを構築する上で理想的な基盤です。
詳細は、「Oracle WebLogic Serverの理解」.を参照してください。

- Oracle SOA Suiteは、コンポジット・アプリケーションの設計、デプロイおよび管理用のサービス指向アーキテクチャのサービス・インフラストラクチャ・コンポーネントの完全なセットです。Oracle SOA Suiteにより、サービスの作成と管理を行って、複合アプリケーションとビジネス・プロセスに編成できます。コンポジットにより、複数のテクノロジ・コンポーネントを1つのSOAコンポジット・アプリケーションに容易にアセンブルできます。
詳細は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理を参照してください。

- Oracle HTTP Serverは、Java EEアプリケーション用Webリスナー、またWeb上の静的および動的なページやアプリケーションをホスティングするフレームワークを提供します。Apache HTTP Serverの実績あるテクノロジに基づき、Oracle HTTP Serverには、ロード・バランシング、管理および構成を容易にする重要な拡張が含まれます。
詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。

- Oracle Web Services Managerは、アクセス制御(認証と認可)、信頼できるメッセージング、メッセージ送信の最適化メカニズム(MTOM)、WSアドレス、Webサービス管理など、Webサービスの各操作を管理するポリシーを集中的に定義および管理する方法を提供します。ポリシーは、複数のWebサービスに添付できるため、既存のWebサービスへの変更が不要になります。
詳細は、Webサービスの管理を参照してください。

- Oracle Platform Securityは、エンタープライズ製品開発チーム、システム・インテグレータおよび独立ソフトウェア・ベンダー(ISV)に、Java Standard Edition (Java SE)およびJava Enterprise Edition (Java EE)アプリケーションに対して、標準ベースでポータブルなエンタープライズ級統合セキュリティ・フレームワークを提供します。
Oracle Platform Securityは、セキュリティおよびID管理の実装の煩雑さから開発者を解放する、標準ベースのアプリケーション・プログラミング・インタフェース(API)形式の抽象化レイヤーを提供します。Oracle Platform Securityにより、開発者は暗号化鍵管理、ユーザー・リポジトリのインタフェース、またはその他のID管理インフラストラクチャの詳細を認識する必要はなくなります。Oracle Platform Securityを使用する場合、社内開発アプリケーション、サード・パーティのアプリケーションおよび統合されたアプリケーションは、エンタープライズ間で同じ均一セキュリティ、ID管理および監査サービスから恩恵を受けます。

詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

- Oracle Data Integratorには、複雑なデータ・ウェアハウスを構築、デプロイおよび管理するため、あるいはSOAまたはビジネス・インテリジェンス環境のデータ集中型アーキテクチャの一部として、完全に統一されたソリューションが用意されています。さらに、データ統合のあらゆる要素(データの移動、データの同期化、データ品質、データ管理、データ・サービス)を組み合せて、複雑なシステムにおいて情報の迅速さ、正確さおよび一貫性を保証します。
詳細は、『Oracle Data Integratorの管理』を参照してください。

- Oracle WebCenter Portalは、標準ベースの、サービス指向アーキテクチャの上に構築された、統合された一連のコンポーネントであり、ソーシャル・アプリケーション、エンタープライズ・ポータル、コラボレイティブ・コミュニティおよびコンポジット・アプリケーションを作成できます。Oracle WebCenter Portalは、機能豊富なインターネット・アプリケーション、統合されたマルチチャネルのポータル・フレームワークの柔軟性と力、およびコンテンツ、コラボレーション、プレゼンスおよびソーシャル・ネットワーキング機能を実現する一連のツールとサービスを開発するために、動的なユーザー・インタフェース・テクノロジを結合します。これらのコンポーネントを基に、Oracle WebCenter Portalは、個人およびグループがより効果的に作業およびコラボレーションできる構成可能な作業環境とともに、WebCenter Portalと呼ばれる、すぐに利用できる、エンタープライズ対応のカスタマイズ可能なアプリケーションも提供します。
詳細は、『Oracle WebCenter Portalの管理』を参照してください。

- Oracle WebCenter Contentは、コンテンツの管理のために設計されたアプリケーションの統合スイートです。Oracle WebCenter Contentには、コンテンツ・リポジトリの管理に使用されるOracle WebCenter Content Serverが含まれます。Oracle WebCenter Contentを使用すると、企業は企業全体においてあらゆる種類のコンテンツを統合、管理および活用できます。マーケティング、ブランド管理、Webプレゼンス、販売、人事およびエンジニアリングなどの企業のすべての業務分野で、同じツールを共有して共通のリポジトリ内の同じ情報に容易にアクセスできます。
詳細は、『Oracle WebCenter Contentの理解』を参照してください。

- Oracle Business Intelligenceは、ビジネス・インテリジェンス要件に対応する完全な統合ソリューションです。Oracle Business Intelligenceには、Oracle BI Enterprise Edition、Oracle Business Intelligence PublisherおよびOracle Real-Time Decisionsがあります。
詳細は、『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。

第II部

基本管理

この部では、Oracle Fusion Middlewareの基本的な管理タスクについて説明します。

第II部は、次の章で構成されています。

- 第2章「Oracle Fusion Middlewareの管理のスタート・ガイド」

- 第3章「連携するコンポーネントのワイヤリング」

- 第4章「Oracle Fusion Middlewareの起動と停止」

- 第5章「ポートの管理」

2 Oracle Fusion Middlewareの管理のスタート・ガイド

Oracle Fusion Middlewareをインストールする場合、実行可能ファイル、jarファイル、ライブラリなどのバイナリ・ファイルをインストールします。次に、構成ツールを使用してソフトウェアを構成します。この章では、Oracle Fusion Middlewareの管理を開始する際に、使用するツールなどの必要な情報について説明します。

この章の内容は次のとおりです。

- Oracle Fusion Middlewareの管理ツールの概要

- Oracle Enterprise Manager Fusion Middleware Controlの使用のスタート・ガイド

- Oracle WebLogic Server管理コンソールのスタート・ガイド

- Oracle WebLogic Scripting Tool (WLST)の使用のスタート・ガイド

- Fusion Middleware Control MBeanブラウザの使用のスタート・ガイド

- 管理ユーザーのパスワードの変更

- ノード・マネージャの構成

- Oracle Fusion Middlewareの構成および管理の基本的なタスク

2.1 Oracle Fusion Middlewareの管理ツールの概要

Oracle Fusion Middlewareをインストールして構成すると、グラフィカル・ユーザー・インタフェースまたはコマンド行ツールを使用して、環境を管理できるようになります。

Oracle Fusion Middlewareインストールを管理するために、次の主要なツールが用意されています。

- Oracle Enterprise Manager Fusion Middleware Control。第2.2項を参照してください。

- Oracle WebLogic Server管理コンソール。第2.3項を参照してください。

- Oracle Fusion Middlewareのコマンド行ツール。第2.4項を参照してください。

- Fusion Middleware Control MBeanブラウザ。第2.5項を参照してください。

特にファイルの編集を必要とする手順がないかぎり、すべての管理タスクを実行する際には、構成ファイルを直接編集するより、これらのツールを使用してください。ファイルを編集すると、設定に不整合が生じて問題が発生する場合があります。

Fusion Middleware ControlもOracle WebLogic Server管理コンソールもグラフィカル・ユーザー・インタフェースであり、これらを使用してOracle Fusion Middleware環境をモニターおよび管理できます。Fusion Middleware Controlおよび管理コンソールは、ほとんどのFusion Middlewareコンポーネントのインストール時にインストールできます。

次の点に注意してください。

- スタンドアロンのOracle WebLogic Serverをインストールする場合は、Fusion Middleware Controlはインストールされません。管理コンソールのみがインストールされます。

- Oracle JDeveloperをインストールする場合は、Fusion Middleware Controlも管理コンソールもインストールされません。これらは、Oracle Fusion Middleware Application Developerのインストール時にインストールできます。

一部のタスクではどちらのツールを使用しても実行できますが、いずれか一方のツールしか使用できないタスクもあります。表2-1は、一般的なタスクのいくつかと推奨ツールを示しています。

表2-1 Fusion Middleware ControlとWebLogic Server管理コンソールの比較

タスク

使用するツール

Oracle WebLogic Serverの管理

使用:

追加管理対象サーバーの作成

Fusion Middleware Control

管理対象サーバーのクローニング

WebLogic Server管理コンソール

管理対象サーバーのクラスタ化

Fusion Middleware Control

Oracle WebLogic Serverの起動と停止

Fusion Middleware ControlまたはWebLogic Server管理コンソール

ユーザーおよびグループの追加

Fusion Middleware ControlまたはWebLogic Server管理コンソール(デフォルトの組込みのLDAPを使用する場合)。別のLDAPサーバーを使用する場合はそのLDAPサーバーのツールを使用します

データ・ソースの管理

使用:

データ・ソースの作成

Fusion Middleware ControlまたはWebLogic Server管理コンソール

接続プールの作成

Fusion Middleware ControlまたはWebLogic Server管理コンソール

JMSリソースの管理

使用:

JMSキューの作成

WebLogic Server管理コンソール

アドバンスト・キューイングの構成

WebLogic Server管理コンソール

SOA環境の管理

使用:

SOAコンポジット・アプリケーションのデプロイ

Fusion Middleware Control

SOAコンポジット・アプリケーションのモニター

Fusion Middleware Control

Oracle BPEL Process ManagerのMBeanプロパティの変更

Fusion Middleware Control

Oracle BPEL Process Managerアプリケーションなどのデバッグ・アプリケーション

Fusion Middleware Control

ADFアプリケーション

使用:

ADFアプリケーションのデプロイ

Fusion Middleware Control

Java EEアプリケーション

使用:

Java EEアプリケーションのデプロイ

WebLogic Server管理コンソールまたはFusion Middleware Control

Oracle WebCenter Portalの管理

使用:

Oracle WebCenter Portalの管理

Fusion Middleware Control

Oracle WebCenter Portalアプリケーションのデプロイ

Fusion Middleware Control

Oracle WebCenter Contentの管理

使用:

Oracle WebCenter Contentの管理

Fusion Middleware Control

Oracle WebCenter Contentアプリケーションのデプロイ

Fusion Middleware Control

Oracle WebCenter Sitesの管理

使用:

Oracle WebCenter Sitesの管理

Fusion Middleware Control

Oracle WebCenter Sitesアプリケーションのデプロイ

Fusion Middleware Control

セキュリティ

使用:

監査の構成および管理

Fusion Middleware Control

SSLの構成

WebLogic Server管理コンソール(Oracle WebLogic Server)

Fusion Middleware Control。第6章を参照してください。

パスワードの変更

WebLogic Server管理コンソール

コンポーネントの管理

使用:

ログ・ファイルの表示および管理

Fusion Middleware Control(ほとんどのログ・ファイル)

次のログに対しては、WebLogic Server管理コンソール

DOMAIN_HOME/servers/server_name/logs/access.log
DOMAIN_HOME/servers/server_name/data/ldap/log/EmbeddedLDAP.log
DOMAIN_HOME/servers/server_name/data/ldap/log/EmbeddedLDAPAccess.log

ポートの変更

WebLogic Server管理コンソール(Oracle WebLogic ServerおよびJavaコンポーネント)

一部のシステム・コンポーネントに対しては、Fusion Middleware Control。各コンポーネントの管理ガイドを参照してください。

Oracle HTTP Serverの管理

Fusion Middleware Control

コンポーネントの起動と停止

Fusion Middleware Control

アプリケーションの起動と停止

Fusion Middleware Control

2.2 Oracle Enterprise Manager Fusion Middleware Controlの使用のスタート・ガイド

Fusion Middleware Controlは、ドメインのモニターおよび管理に使用できるWebブラウザベースのグラフィカル・ユーザー・インタフェースです。管理サーバーを持つ1つのOracle WebLogic Serverドメイン、1つ以上の管理対象サーバー、クラスタ、ドメインにインストールされ、構成および実行されている複数のOracleミドルウェア・コンポーネント、およびデプロイするアプリケーションを管理できます。

Fusion Middleware Controlでは、ドメイン、サーバー、コンポーネントおよびアプリケーションについて、幅広いパフォーマンス・データと管理機能がWebベースの個別のホームページにまとめられています。Fusion Middleware Controlホーム・ページを使用すると、最も重要なモニタリング・データと最もよく使用される管理機能のすべてに、Webブラウザから容易にアクセスできます。

この項で説明する項目は、次のとおりです。

- Fusion Middleware Controlの表示

- Fusion Middleware Controlヘルプの使用

- Fusion Middleware Controlでのナビゲート

- Fusion Middleware Controlのユーザーおよびロールの理解

- WebLogic Server構成のロック

- WebLogicドメインの表示と管理

- Javaコンポーネントの表示と管理

- システム・コンポーネントの表示と管理

2.2.1 Fusion Middleware Controlの表示

Fusion Middleware Controlを表示するには、Fusion Middleware ControlのURLを入力します。このURLには、インストール時に割り当てられたホスト名と管理ポート番号が含まれます。このURLの形式は次のとおりです。

http://hostname.domain:port/em

ポート番号は管理サーバーのポート番号です。デフォルトのポート番号は、7001です。ポート番号は、次のファイルにリストされています。

DOMAIN_HOME/config/config.xml

Web層など、一部のインストール・タイプでは、最後のインストール画面で「保存」をクリックしてインストール情報を保存した場合、Fusion Middleware ControlのURLが、ディスクに書き込まれたファイル(デフォルトではホーム・ディレクトリにあります)に含まれています。その他のインストール・タイプの場合、構成が完了すると構成ウィザードの「ドメインの作成」画面に情報が表示されます。

Fusion Middleware Controlを表示する手順は次のとおりです。

1. WebブラウザにURLを入力します。次に例を示します。

http://host1.example.com:7001/em

2. Oracle Fusion Middleware管理者のユーザー名とパスワードを入力して、「ログイン」をクリックします。

2.2.2 Fusion Middleware Controlヘルプの使用

Fusion Middleware Controlを使用している際にはいつでも、このページの上部にある「ユーザー名」メニューから「ヘルプ」を選択することにより、詳細な情報を取得できます。「ヘルプ」メニューから、次の項目を選択できます。

- 「目次」ヘルプの目次を一覧表示します。

- 「このページのヘルプ」現在のページのコンテキスト依存のヘルプを表示します。

- 「使用方法」ドキュメント内のチュートリアル情報にリンクします。

- 「ドキュメント・ライブラリ」Oracle Technology Networkのライブラリにリンクします。

- 「ユーザー・フォーラム」Oracle Technology Networkのディスカッション・フォーラムにリンクします。

- 「Oracle Technology Network」Oracle Technology Networkにリンクします。

2.2.3 Fusion Middleware Controlでのナビゲート

Fusion Middleware Controlにログインすると、次の図に示すように、サーバー、クラスタおよびデプロイメントを示すボックスが右側に表示され、ドメインのホーム・ページが左側に表示されます。

ターゲット・ナビゲーション・ペインを表示するには、左上隅にある「ターゲット・ナビゲーション」アイコンをクリックします。Fusion Middleware Controlの左側にはターゲット・ナビゲーション・ペインが、右側にはコンテンツ・ペインが表示されます。

ターゲット・ナビゲーション・ペインでツリーを開き、Oracle WebLogic Serverドメイン、Oracle WebLogic Server管理対象サーバー、コンポーネント、アプリケーションまたはメタデータ・リポジトリを選択できます。

次の図は、右クリックのコンテキスト・メニューが表示されたターゲット・ナビゲーション・ペインを示しています。

管理対象サーバー、コンポーネントなどのターゲットを選択する場合、ターゲットのホーム・ページはコンテンツ・ペインに表示されます。また、そのターゲットのメニューは、コンテキスト・ペインのページ上部に表示されます。たとえば、「管理対象サーバー」を選択した場合、「WebLogic Server」メニューが表示されます。ナビゲーション・ペインのターゲットで右クリックすることにより、ターゲットのメニューを表示することも可能です。

次の図は、ターゲット・ナビゲーション・ペインと管理対象サーバーのホーム・ページを示しています。管理対象サーバーが選択されているので、コンテキスト・ペインにリストされる動的ターゲット・メニューは「WebLogic Server」メニューになります。

前述の図のコールアウト・テキストの説明は次のとおりです。

- 動的ターゲット・メニュー: 現在選択されているターゲットで実行可能な操作のリストが表示されます。表示されるメニューは、選択するターゲットによって異なります。特定のターゲットのメニューには、右クリック・ターゲット・メニューと同様の操作が含まれます。

- 「チェンジ・センター」には行われた変更が表示され、構成のロックと編集、構成のリリース、変更のアクティブ化、すべての変更の取消し、設定の変更が可能です。また、セッション記録の開始と停止、および記録の表示も可能でます。

- 「WebLogicドメイン」メニューには、ドメインで実行できる操作のリストが表示されます。「WebLogicドメイン」メニューはいつでも使用できます。

- ターゲット名: 現在選択されているターゲットの名前が表示されます。

- ターゲット情報: ターゲットに関する詳細が示されます。たとえば、ドメインの場合、ターゲット名、バージョン、およびドメイン・ホームが表示されます。

- 「ターゲット・ナビゲーション」アイコンが展開し、ドメイン内のすべてのターゲットをナビゲーション・ツリーで一覧表示されます。

- コンテキスト・ペイン: ターゲットの名前、現行ユーザーの名前、ホスト名、最終ページ・リフレッシュ時間、および「リフレッシュ」アイコンが表示されます。

- コンテンツ・ペインには、ターゲットの現在のページが表示されます。最初にターゲットを選択する場合、そのターゲットのホーム・ページが表示されます。

- 「ユーザー名」メニューには、「ヘルプ」、「アクセシビリティ」、Fusion Middleware Controlに関する情報およびログアウトへのリンクが表示されます。

- リフレッシュ: ページがリフレッシュされているときに表示されます。これをクリックすると、新しいデータでページがリフレッシュされます。(ブラウザ・ウィンドウをリフレッシュするとページ自体はリフレッシュされますが、新しいデータは取得されません。)

- ターゲット・ナビゲーション・ペインからアクセスする右クリック・ターゲット・メニューを使用すると、現在選択されているターゲットで実行可能な操作のリストが表示されます。このメニューは、ターゲット・ナビゲーション・ペインでターゲットの名前を右クリックすると表示されます。この図は、WebLogic Serverを選択してそのホーム・ページを表示した後の時点を示すものですが、ユーザーがメタデータ・リポジトリを右クリックしたので、右クリック・ターゲット・メニューには、メタデータ・リポジトリの操作が表示されています。
特定のターゲットのメニューには、動的ターゲット・メニューと同様の操作が含まれます。

- 「ビュー」を使用すると、ナビゲーション・ツリーを展開または縮小できます。

また、管理サーバーや管理対象サーバーなどのターゲットのホーム・ページから、WebLogic Server管理コンソールにアクセスできます。

表2-2では、Fusion Middleware Controlでの一般的なナビゲーション操作のいくつかを説明します。

表2-2 Fusion Middleware Controlでのナビゲート

目的:

操作方法

ドメイン内のすべてのターゲットを表示する

「ビュー」メニューから「すべてを開く」を選択します。

ドメインで操作する

Fusion Middleware Controlの左上にあり、常に使用できる「WebLogicドメイン」メニューを選択します。

ターゲットで操作する

ターゲット・ナビゲーション・ペインで、ターゲットを右クリックします。「ターゲット」メニューが表示されます。

または、ターゲットを選択してコンテキスト・ペインの動的ターゲット・メニューを使用できます。

ターゲットのホーム・ページに戻る

コンテキスト・ペインの左上隅のターゲット名をクリックします。

新しいデータでページをリフレッシュする

コンテキスト・ペインの右上の「リフレッシュ」アイコンをクリックします。

前のページに戻る

コンテキスト・ペインの下に表示されるブレッドクラムをクリックします。ターゲットでドリルダウンするとブレッドクラムが表示されます。たとえば、「WebLogic Server」メニューから「ログ」→「ログ・メッセージの表示」を選択します。ログ・ファイルを選択して、「ログ・ファイルの表示」をクリックします。ブレッドクラムは次のように表示されます。

ログ・メッセージ→ログ・ファイル→>ログ・ファイルの表示: logfile_name

ターゲットが稼働中のホストを表示する

ターゲット・ナビゲーション・ペインでターゲットを選択し、ターゲットのコンテキスト・ペインにホスト名を表示します。「ターゲット情報」アイコンをクリックして、ホスト名を表示することもできます。

サーバー・ログ・ファイルを表示する

ターゲット・ナビゲーション・ペインで、サーバー名を右クリックします。「ログ」→「ログ・メッセージの表示」を選択して、ログ・メッセージのサマリーの確認およびログ・ファイルの検索を実行します。

2.2.4 Fusion Middleware Controlのユーザーおよびロールの理解

Fusion Middleware Controlにアクセスしてタスクを実行するには、適切なロールが必要です。Fusion Middleware Controlでは、Oracle WebLogic Serverセキュリティ・レルムとそのレルムで定義されたロールを使用します。ユーザーにそれらのロールのいずれかが付与されていないと、そのユーザーはFusion Middleware Controlにアクセスできません。

表2-3で説明されているように、各ロールではユーザーに付与されているアクセスのタイプが定義されます。

表2-3 Fusion Middleware Controlでサポートされているロール

ロール

許可されているアクション

管理者

すべてのアクセス。管理者には、インスタンスの作成と削除、構成の変更を含む、完全な権限が付与されています。

デプロイヤ

アプリケーションのデプロイ、アンデプロイおよび再デプロイ、アプリケーションの構成の変更、アプリケーションの起動と停止、JDBCおよびJMSリソースの作成と削除、JDBCおよびJMSリソースの変更、モニター・ロールのすべての権限。

オペレータ

サーバーおよびアプリケーションの起動と停止、モニター・ロールのすべての権限。

モニター

構成、サーバーおよびアプリケーションのステータス、メトリック、ログ・ファイルおよびログ・メッセージの表示。

表2-4は、Fusion Middleware Controlでサポートされている各ロールの権限をまとめたものです。

表2-4 サポートされているロールの権限

権限

管理者

デプロイヤ

オペレータ

モニター

セッション操作の編集(セッションの起動または解放、変更のアクティブ化または元に戻す)

はい

はい

いいえ

いいえ

サーバー、クラスタ、テンプレートまたはマシン

ライフサイクル操作(作成、削除)

はい

いいえ

いいえ

いいえ

構成の変更

はい

いいえ

いいえ

いいえ

操作の制御(起動、停止、再開)

はい

いいえ

はい

いいえ

構成の表示

はい

はい

はい

はい

アプリケーション・デプロイメント

ライフサイクル操作(デプロイ、アンデプロイ、再デプロイ)

はい

はい

いいえ

いいえ

構成の変更

はい

はい

いいえ

いいえ

操作の制御(起動、停止)

はい

はい

はい

いいえ

JDBCおよびJMSリソース

ライフサイクル操作(作成、削除)

はい

はい

いいえ

いいえ

構成の変更

はい

はい

いいえ

いいえ

操作の制御(起動、停止)

はい

いいえ

いいえ

いいえ

構成の表示

はい

はい

はい

はい

クラス、Coherenceクラスタの起動と停止

ライフサイクル操作(作成、削除)

はい

いいえ

いいえ

いいえ

構成の変更

はい

はい

いいえ

いいえ

構成の表示

はい

はい

はい

はい

表2-4の情報は、WebLogicリソースおよびMBean用のデフォルトの即時利用可能なセキュリティ・ポリシーを基にしています。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのロールおよびポリシーを使用したリソースの保護に関する項で説明されているように、デフォルトのセキュリティ・ポリシーは管理コンソールで管理できます。

詳細は、ロールおよびポリシーによるOracle WebLogic Serverリソースの保護のWebLogicリソースのセキュリティの理解に関する項を参照してください。

2.2.5 WebLogic Serverの構成のロック

構成の変更を行う前に、編集セッション中に他のアカウントで変更が行われずに構成を変更できるように、ドメイン構成をロックします。Fusion Middleware Controlからドメイン構成を参照する手順は次のとおりです。

1. Fusion Middleware Controlの上部にあるチェンジ・センターを探します。

2. 「変更」メニューから、「ロックと編集」を選択し、ドメインの編集可能な構成階層をロックします。

管理コンソールを使用して構成を変更したら、適切なページで「保存」(場合によっては「終了」)をクリックします。この変更は即座には反映されません。この変更は、チェンジ・センターで「変更のアクティブ化」をクリックすると反映されます。その時点で、構成の変更はドメイン内の各サーバーに配信されます。変更が各サーバーに受け入れられると、変更が反映されます。いずれかのサーバーで変更が受け入れられない場合、ドメイン内のすべてのサーバーからすべての変更がロールバックされます。変更は保留状態になるので、保留中の変更を編集して問題を解決するか、前の構成に戻すことができます。

次のようにWLSTコマンドstartEditを使用して構成をロックすることもできます。

startEdit()

startEditコマンドおよびロックを解除するstopEditコマンドの詳細は、『WebLogic Server WLSTコマンド・リファレンス』のstartEditおよびstopEditに関する項を参照してください。

2.2.6 WebLogicドメインの表示と管理

Fusion Middleware Controlにログインすると、最初に表示されるページはドメイン・ホーム・ページです。また、「WebLogicドメイン」メニューで「ホーム」を選択すれば、このページをいつでも表示できます。

次の図はドメイン・ホーム・ページを示しています。

「WebLogicドメイン」メニューはページの上部に表示されます。このメニューからドメインをモニターし、構成できます。

「WebLogicドメイン」メニューは、別のエンティティを選択した場合でも常に表示されています。

2.2.7 Javaコンポーネントの表示と管理

ターゲット・ナビゲーション・ペインからドリルダウンしてドメイン内のJavaコンポーネントを表示および管理できます。

たとえば、Oracle SOA Suiteを表示および管理する場合、次の手順を実行します。

1. ターゲット・ナビゲーション・ペインを展開し、「SOA」を展開します。

2. SOA soa_infraインスタンスを選択します。
SOAインスタンスのホーム・ページは、次の図のように表示されます。

3. 「SOAインフラストラクチャ」メニューから、Oracle SOA Suiteの開始、停止およびモニタリング、SOAコンポジット・アプリケーションのデプロイなどの多くの管理タスクを実行できます。

コンポーネントのモニタリングの詳細は、第11.1.5項を参照してください。

2.2.8 システム・コンポーネントの表示と管理

システム・コンポーネントを表示して管理することもできます。たとえば、Oracle HTTP Serverを表示および管理する手順は、次のとおりです。

1. ナビゲーション・ペインで、「HTTP_Server」を展開します。

2. ohs1などのOracle HTTP Serverインスタンスを選択します。
Oracle HTTP Serverのohs1のホーム・ページは、次の図のように表示されます。

3. 「HTTP Server」メニューから、Oracle HTTP Serverの開始、停止、モニタリングなどの多くの管理タスクを実行できます。

コンポーネントのモニタリングの詳細は、第11.1.5項を参照してください。

2.3 Oracle WebLogic Server管理コンソールの使用のスタート・ガイド

Oracle WebLogic Server管理コンソールは、Oracle WebLogic Serverドメインの管理に使用する、Webブラウザ・ベースのグラフィカル・ユーザー・インタフェースです。これは、管理サーバーへのネットワーク・アクセスでサポートされるWebブラウザからアクセスできます。

管理コンソールでは、次の操作を行います。

- WebLogic Serverインスタンスを構成、起動および停止します。

- WebLogic Serverクラスタを構成します。

- データベース接続(JDBC)やメッセージング(JMS)などの、WebLogic Serverサービスを構成します。

- ユーザー、グループおよびロールの作成、管理などの、セキュリティ・パラメータを構成します。

- Java EEアプリケーションの構成とデプロイを行います。

- サーバーおよびアプリケーションのパフォーマンスをモニターします。

- サーバーおよびドメインのログ・ファイルを表示します。

- アプリケーション・デプロイメント記述子を表示します。

- 選択したランタイム・アプリケーション・デプロイメント記述子の各要素を編集します。

管理コンソールを表示する手順は次のとおりです。

1. ブラウザに次のURLを入力します。

http://hostname:port_number/console

ポート番号は管理サーバーのポート番号です。デフォルトのポート番号は、7001です。

ログイン・ページが表示されます。

2. インストール時に指定したユーザー名とパスワード、作成した別の管理ユーザーのユーザー名とパスワードを使用してログインします。
Oracle WebLogic Server管理コンソールは、次の図のように表示されます。

また、Fusion Middleware Controlで、「WebLogic Server」メニューから、管理コンソールにアクセスすることもできます。

2.4 WebLogic Scripting Tool (WLST)の使用のスタート・ガイド

Oracle WebLogic Scripting Tool (WLST)は、Oracle WebLogic Serverドメインの作成、管理およびモニターに使用するコマンド行スクリプト環境です。これは、Javaのスクリプト・インタプリタであるJythonがベースとなっています。ローカル変数、条件変数、フロー制御文などのJythonの標準機能のサポートの他に、WLSTには、WebLogic Serverに固有のスクリプト関数(コマンド)セットが用意されています。Jythonの言語構文に従うことで、必要に応じてWebLogicのスクリプト言語を拡張できます。

次の各トピックでは、WLSTを使用したOracle Fusion Middlewareコンポーネントの管理について説明します。

- JavaコンポーネントおよびOracle Fusion MiddlewareサービスとともにWLSTを使用する方法

- システム・コンポーネントでのWLSTコマンドの使用

2.4.1 JavaコンポーネントおよびOracle Fusion MiddlewareサービスとともにWLSTを使用する方法

Oracle SOA Suite、Oracle Platform Security Services (OPSS)、Oracle Fusion Middleware監査フレームワーク、MDSなどのJavaコンポーネント、およびSSL、ロギングおよび診断フレームワークなどのサービスとともにWLSTTコマンドを使用できます。

WLSTコマンドは、次のように使用できます。

- コマンド行で対話的に実行する

- スクリプト・モードでファイルに指定する

- Javaコードに組み込む

このスクリプトは、次の場所にあります。

(UNIX) ORACLE_HOME/oracle_common/common/bin/wlst.sh
(Windows) ORACLE_HOME\oracle_common\common\bin\wlst.cmd

たとえば、WLSTを対話的に起動してWebLogic Serverに接続するには、次のコマンドを使用します。

ORACLE_HOME/oracle_common/common/bin/wlst.sh
connect('username', 'password', 'localhost:7001')

WLSTコマンドや変数の詳細を表示するには、ヘルプ・コマンドを入力します。たとえば、オンライン・コマンドのカテゴリ一覧を表示するには、次のように入力します。

wls:/base_domain/serverConfig>  help('online')
help('activate')            Activate the changes.
help('addListener')         Add a JMX listener to the specified MBean.
help('adminHome')           Administration MBeanHome.
help('cancelEdit')          Cancel an edit session.
help('cd')                  Navigate the hierarchy of beans.
help('cmo')                 Current Management Object.
.
.
.

ステータスをモニターするには、次の形式でWLSTのstateコマンドを使用します。

state(name, type)

たとえば、管理対象サーバーwls_server1のステータスを取得するには、次のコマンドを使用します。

wls:/WLS_domain/serverConfig> state('wls_server1', 'Server')
Current state of 'wls_server1' : RUNNING

WLSTの使用の詳細は、『WebLogic Server WLSTコマンド・リファレンス』を参照してください。

2.4.2システム・コンポーネントでのWLSTコマンドの使用

システム・コンポーネントではWLSTコマンドを使用できます。次のコンポーネントはシステム・コンポーネントです。

- Oracle HTTP Server

システム・コンポーネントには表2-5にリストしたWLSTコマンドのみ使用できます。コマンドをオンライン・モードで呼び出せるか、オフライン・モードで呼び出せるかの詳細は、『WebLogic Server WLSTコマンド・リファレンス』を参照してください。

表2-5 システム・コンポーネント用WLSTコマンド

WLSTコマンド

説明

詳細は、次を参照してください:

create

デフォルト値でシステム・コンポーネントのインスタンスを作成します

『WebLogic Server WLSTコマンド・リファレンス』のcreateコマンドに関する項

displayLogs

ログ・ファイルのメッセージを表示します

『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』および第12.3.1.2項のdisplayLogsコマンド

displayMetricTableNames

DMSメトリック表の名前を表示します

インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のdisplayMetricTableNamesコマンドに関する項

displayMetricTables

DMSメトリック表の内容を表示します

インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のdisplayMetricTablesコマンドに関する項

dumpMetrics

使用可能なDMSメトリックを表示します

インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のdumpMetricsコマンドに関する項

listLogs

ログ・ファイルをリストします

『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』および第12.3.1.2項のlistLogsコマンド

nmKill

インスタンスを停止します

『WebLogic Server WLSTコマンド・リファレンス』および第4.3.2.2項のnmkillコマンド

nmServerStatus

インスタンスでのステータスを返します

『WebLogic Server WLSTコマンド・リファレンス』のnmServerStatusコマンドに関する項

nmStart

インスタンスを起動します

『WebLogic Server WLSTコマンド・リファレンス』および第4.3.2.2項のnmStartコマンド

shutdown

システム・コンポーネント・インスタンスを停止します

『WebLogic Server WLSTコマンド・リファレンス』および第4.3.2.2項のshutdownコマンド

start

システム・コンポーネント・インスタンスを起動します。

『WebLogic Server WLSTコマンド・リファレンス』および第4.3.2.2項のstartコマンド

state

システム・コンポーネント・インスタンスの状態を返します

『WebLogic Server WLSTコマンド・リファレンス』および第2.4項のstateコマンド

resync

ドメイン内の特定のシステム・コンポーネント・インスタンスの構成を再同期化します。

『WebLogic Server WLSTコマンド・リファレンス』のresyncコマンドに関する項

resyncAll

ドメイン内のすべてのシステム・コンポーネント・インスタンスの構成を再同期化します。

『WebLogic Server WLSTコマンド・リファレンス』のresyncAllコマンドに関する項

showComponentChanges

指定したシステム・コンポーネント・インスタンス、またはドメイン内のすべてのシステム・コンポーネント・インスタンスに対して行われた変更を表示します。

『WebLogic Server WLSTコマンド・リファレンス』のshowComponentChangesコマンドに関する項

pullComponentChanges

システム・コンポーネント・インスタンスの構成に対して行われた変更を現在の編集セッションにプルします。

『WebLogic Server WLSTコマンド・リファレンス』のpullComponentChangesコマンドに関する項

これらのコマンドを使用するには、Oracle共通ホームからWLSTスクリプトを呼び出す必要があります。このスクリプトは、次の場所にあります。

(UNIX) ORACLE_HOME/oracle_common/common/bin/wlst.sh
(Windows) ORACLE_HOME\oracle_common\common\bin\wlst.cmd

システム・コンポーネントのステータスをモニターするには、次の形式でWLSTのstateコマンドを使用します。

state(component_ame, SystemComponent)

オンライン・モードでは、より多くの機能を提供するMBean操作を呼び出すために、cmo変数を使用できます。cmo変数の詳細は、『WebLogic Scripting Toolの理解』の現在の管理オブジェクトの変更に関する項を参照してください。

2.5 Fusion Middleware Control MBeanブラウザの使用のスタート・ガイド

マネージドBean (MBean)とは、分散環境内のJMXで管理されるリソースを表すJavaオブジェクトです。MBeanには、アプリケーション、サービス、コンポーネント、デバイスなどがあります。

次の各トピックでは、MBeanとMBeanの表示方法や構成方法について説明します。

- MBeanの理解

- システムMBeanブラウザの使用

- 選択したアプリケーションのMBeanの使用

2.5.1 MBeanの理解

MBeanは、Java EE環境のアプリケーションの管理に使用する標準インタフェースを作成するための一連の仕様、すなわちJava Management Extension (JMX)の一部である、Java EE管理仕様(JSR-77)で定義されています。JSR-77の詳細は、次を参照してください。

http://www.oracle.com/technetwork/java/javaee/overview-137048.html

MBeanを作成してアプリケーションとともにOracle WebLogic Serverにデプロイすると、アプリケーションまたはアプリケーションのコンポーネントを、Fusion Middleware Controlを使用して管理およびモニターできるようになります。

Fusion Middleware Controlには、Oracle WebLogic Serverまたは選択したアプリケーションのMBeanを参照できる、一連のMBeanブラウザが用意されています。MBeanブラウザでは、特定のモニタリング・タスクや構成タスクも実行できます。

MBeanは、構成MBean、ランタイムMBean、およびアプリケーション定義MBeanの3つのグループに編成されます。

MBeansの詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeansの理解に関する項を参照してください。

2.5.2 システムMBeanブラウザの使用

Oracle WebLogic Serverドメイン、管理サーバー、管理対象サーバーやアプリケーションなど多くのエンティティのためにシステムMbeanブラウザを表示できます。MBeanナビゲーション・ツリーで、MBeanの検索、MBeanのリストのフィルタ、およびMBeanのリストのリフレッシュを実行できます。

特定のOracle WebLogic Server管理対象サーバーに固有のシステムMBeanブラウザを表示して、MBeansを構成および使用する手順は次のとおりです。

1. ターゲット・ナビゲーション・ペインからドメインを展開します。

2. ドメインのホーム・ページから、管理対象サーバーを選択します。

3. 「WebLogicサーバー」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

4. MBeanナビゲーション・ツリーでノードを開いて、アクセスするMBeanにドリルダウンします。MBeanインスタンスを選択します。
MBeanの場所がわからない場合、そのMBeanを検索できます。

1. MBeanナビゲーション・ツリーの上部にある「検索」アイコンをクリックします。

2. 検索するには、「MBean名」を選択します。
「属性」、「操作」、または「JMX構文」も選択できます。

3. MBeanの名前を入力し、検索アイコンをクリックします。

5. MBeanの属性を表示するには、「属性」タブを選択します。一部の属性では値を変更できます。そのためには、値を「値」列に入力します。

6. 使用可能な操作を表示するには、「操作」タブを選択します。操作を実行するには、操作をクリックします。「操作」ページが表示されます。適切な値を入力し、「起動」をクリックします。

詳細は、Fusion Middleware Controlのオンライン・ヘルプを参照してください。

2.5.3 選択したアプリケーションのMBeanの使用

第2.5.2項で説明されている手順を実行し、アプリケーションに関してドリルダウンすると、特定のアプリケーションのMBeanを表示、構成および使用できます。また、次の手順を使用してもアプリケーションのMBeanにナビゲートできます。

1. ターゲット・ナビゲーション・ペインから、「アプリケーション・デプロイメント」を展開します。

2. アプリケーションを選択します。

3. 「アプリケーションのデプロイ」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページに、アプリケーションのMBean情報が表示されます。

4. MBeanの属性を表示するには、「属性」タブを選択します。一部の属性では値を変更できます。そのためには、値を「値」列に入力します。

5. 使用可能な操作を表示するには、「操作」タブを選択します。操作を実行するには、操作をクリックします。「操作」ページが表示されます。適切な値を入力し、「起動」をクリックします。

2.6 管理ユーザーのパスワードの変更

Oracle Fusion Middlewareのインストール時に、管理アカウントのパスワードを指定する必要があります。このアカウントは、Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールへの初回ログイン時に使用できます。追加の管理アカウントを作成するには、WLSTコマンド行またはOracle WebLogic Server管理コンソールを使用します。

次のトピックの説明に従って、コマンド行またはOracle WebLogic Server管理コンソールを使用して、管理ユーザーのパスワードを変更できます。

- コマンド行を使用した管理ユーザーのパスワードの変更

- Oracle Fusion Middlewareを使用した管理ユーザー・パスワードの変更

ユーザー、ロールおよびパスワード変更の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のユーザーおよびロールの理解に関する項を参照してください。

2.6.1 コマンド行を使用した管理ユーザーのパスワードの変更

コマンド行を使用して管理ユーザーのパスワードまたはその他のユーザーのパスワードを変更するには、UserPasswordEditorMBean.changeUserPasswordメソッドを呼び出します。このメソッドはセキュリティ・レルムのAuthenticationProvider MBeanで拡張されます。

詳細は、Oracle WebLogic ServerのMBeanリファレンスのchangeUserPasswordメソッドに関する項を参照してください。

2.6.2 Oracle Fusion Middlewareを使用した管理ユーザーのパスワードの変更

Oracle Fusion Middlewareを使用して管理ユーザーのパスワードを変更する手順は、次のとおりです。

1. 「WebLogicドメイン」メニューで、「セキュリティ」→「ユーザーとグループ」を選択します。
「セキュリティ・レルムのサマリー」ページが表示されます。

2. 「ユーザーの選択」を選択します。
ユーザーの設定ページが表示されます。

3. 「パスワード」タブを選択します。

4. 新しいパスワードを入力した後、確認のために再度それを入力します。

5. 「保存」をクリックします。

2.7 ノード・マネージャの構成

ノード・マネージャでは、管理コンソールやFusion Middleware Controlを使用して、管理対象サーバーに対し、起動や停止などの一般的な操作を実行できます。

この項の内容は次のとおりです。

- 管理対象サーバーを起動するためのノード・マネージャの構成

- OPSSキーストア・サービスを使用するためのノード・マネージャの構成

2.7.1 管理対象サーバーを起動するためのノード・マネージャの構成

管理対象サーバーにOracle JRF、Oracle SOA Suiteなどの別のOracle Fusion Middleware製品が含まれている場合は、正しいクラスパスおよびパラメータを設定するように管理対象サーバー環境を構成する必要があります。デフォルトで、ノード・マネージャはOracle Fusion Middlewareのインストール時に構成されます。

ただし、自動構成を選択しない場合は、この環境情報をstartWebLogicおよびsetDomainEnvなど、次のディレクトリにある起動スクリプトを介して指定する必要があります。

DOMAIN_HOME/bin

管理対象サーバーがノード・マネージャによって起動される場合、(Oracle WebLogic Server管理コンソールまたはFusion Middleware Controlによりサーバーが起動される場合と同様に)ノード・マネージャにこれらの起動スクリプトを使用するよう指示する必要があります。これにより、サーバー環境は正しく構成されます。具体的には、ノード・マネージャはStartScriptEnabled=trueというプロパティで起動される必要があります。

このプロパティが有効な状態でノード・マネージャが起動されるようにする方法はいくつかあります。Oracle Fusion Middlewareには、次のスクリプトが用意されています。これは、nodemanager.propertiesプロパティ・ファイルにStartScriptEnabled=trueプロパティを追加するためのものです。

(UNIX) ORACLE_HOME/oracle_common/common/bin/setNMProps.sh.
(Windows) ORACLE_HOME\oracle_common\common\bin\setNMProps.cmd

たとえば、Linuxでは、次のコマンドを使用して、setNMPropsスクリプトを実行し、ノード・マネージャを起動します。

ORACLE_HOME/oracle_common/common/bin/setNMProps.sh
DOMAIN_HOME/bin/startNodeManager.sh

ノード・マネージャを起動すると、nodemanager.propertiesファイルのStartScriptEnabled=trueプロパティが読み取られ、その後で管理対象サーバーを起動するときに起動スクリプトが使用されます。setNMPropsスクリプトを実行する必要があるのは1回だけであることに注意してください。

また、StartScriptEnableプロパティがtrueに設定されていると、ノード・マネージャによりstartWebLogicスクリプトを読み取り、続いてsetDomainEnvスクリプトを読み取ります。その結果、setDomainEnvスクリプトを編集することでチューニング変更を行う必要があります。ノード・マネージャによりサーバーが起動されると、コマンド行や管理コンソールを使用して行われた変更は実装されません。たとえば、管理コンソールを使用してサーバー起動引数を変更すると、これらの変更はconfig.xmlに書き込まれますが、ノード・マネージャではこれらの設定は無視され、これらをsetDomainEnvで使用します。

ノード・マネージャの構成および起動の他の方法については、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの使用に関する項を参照してください。

2.7.2 OPSSキーストア・サービスを使用するためのノード・マネージャの構成

Oracle JRFを含むドメインを作成し、「ドメイン当たり」でノード・マネージャを構成した場合、Oracle Platform Security Servicesキーストア・サービスを使用するようにノード・マネージャを構成できます。次の手順を実行します。

1. 『 Oracle Platform Security Servicesによるアプリケーションの保護』のキーストア・サービスによるキーストアの管理に関する項の説明に従ってキーストア・サービスを構成します。

2. 次のファイルを編集してノード・マネージャを構成します。

DOMAIN_HOME/nodemanager/nodemanager.properties

ファイル内で、次のプロパティを指定します。

KeyStores=CustomIdentityAndDemoTrust
CustomIdentityKeyStoreType=KSS
CustomIdentityKeyStoreFileName=kss://system/keystore_name
CustomIdentityKeyStorePassPhrase= keystore_passphrase
CustomIdentityAlias= key store alias
CustomIdentityPrivateKeyPassPhrase= keystore_private_key_passphrase

Oracle Platform Security Servicesのキーストア・サービスは、「ホスト当たり」のノード・マネージャではサポートされていません。ただし、特定の状況では、「ホスト当たり」ノード・マネージャがキーストア・サービスをロードしようとすることがあります。これを避けるには、次のファイルでUseKSSForDemo=falseを指定する必要があります。

ORACLE_HOME/oracle_common/common/nodemanager/nodemanager.properties

注意:
Oracle Platform Security Servicesは、startNodeManagerスクリプトに次の引数を追加して、JKSベースのキーストアのかわりにキーストア・サービスを使用するように設定します。

-Doracle.security.jps.config=DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml
-Dcommon.components.home=MW_HOME/oracle_common
-Dopss.version=12.1.3

startWebLogicスクリプトを使用せずに(StartScriptEnabled=false)、WebLogic Serverを起動するようノード・マネージャを構成する場合は、WLSTや管理コンソールなどの管理ツールを使用して、サーバーのServerStartMBean Argumentsフィールドにこれらの引数を追加する必要があります。

また、CLASSPATH定義に、次の項目を追加する必要があります。

MW_HOME/oracle_common/modules/oracle.jps_12.1.3/jps-manifest.jar.

2.8 Oracle Fusion Middlewareの構成および管理の基本的なタスク

次に、ソフトウェアをインストールした後に基本的なOracle Fusion Middleware環境を構成および管理するために必要な手順のサマリーを示します。

1. Oracle WebLogic Server、およびOracle SOA Suite、Oracle HTTP Serverなどのコンポーネントを構成します。『Oracle Fusion Middlewareのインストールのプランニング』を参照してください。

2. ノード・マネージャを構成します。第2.7項を参照してください。

3. SSLを構成します。第6章を参照してください。

4. MDSリポジトリなどのメタデータ・リポジトリを作成および管理します。第14.2項を参照してください。

5. アプリケーションをデプロイします。第10章を参照してください。

6. ロード・バランシングを構成します。様々なコンポーネントまたはアプリケーション間のロード・バランシングを構成できます。『高可用性ガイド』を参照してください。

7. 環境をバックアップします。第16章を参照してください。

8. 環境をモニターし、ログ・ファイルを管理します。第11章および第12章を参照してください。

9. 環境を拡張します。第19章を参照してください。

このガイドでは、Oracle Fusion Middleware環境に応じて、実行する必要がある場合があるその他のタスクについても説明します。

注意:
このマニュアルの手順の大部分は、ユーザーが標準的なインストール・トポロジ(1つの管理サーバーを含む1つのドメインと2つの管理対象サーバーが含まれているクラスタで構成)を使用すると想定しています。
標準的なトポロジの詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のOracle Fusion Middlewareインフラストラクチャの標準的なインストール・トポロジの理解に関する項を参照してください。

3 連携するコンポーネントのワイヤリング

この章ではサービス表について説明し、また、特定のOracle Fusion Middlewareコンポーネントを一緒にワイヤリングする方法について説明します。

内容は次のとおりです。

- サービス表の理解

- サービス表の表示

- コンポーネントのワイヤリング

3.1 サービス表の理解

サービス表を使用すると、サービスに関するエンドポイント情報をサービス・プロバイダがパブリッシュでき、サービスのクライアントはこれらのサービスを問合せしてバインドできます。サービス表はデータベース・スキーマの単一の表です。パブリッシュされる各エンドポイントに対して1行あります。サービス表スキーマは、最初にリポジトリ作成ユーティリティにより作成されます。

サービス表スキーマの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

ローカルのサービス表はドメインと関連付けられます。これには、そのドメインにより提供されるエンドポイントが含まれています。ローカル・サービス表の場合、データソース名はLocalSvcTblDataSourceです。

たとえば、サービス表にはデフォルトでOracle Web Services ManagerおよびFusion Middleware Controlのエンドポイント情報が含まれています。

3.2 サービス表の表示

Fusion Middleware Controlを使用してサービス表を表示できます。

1. 「WebLogicドメイン」メニューから「クロス・コンポーネント・ワイヤリング」、「サービス表」を選択します。
「サービス表」ページが表示されます。

2. いずれかのボタンを押してエンドポイントのプロパティを表示、編集または削除できます。

3.3 コンポーネントのワイヤリング

Oracle Fusion Middlewareをインストールし、構成するときに、ほとんどのクロス・コンポーネント・ワイヤリングは自動的に実行されます。ただし、別のコンポーネントに接続したい場合や、現在のワイヤリングを変更したい場合もあります。次に例を示します。

- Oracle HTTP Serverを管理サーバーに接続する。こうすると、Oracle HTTP ServerはFusion Middleware Controlに、そして管理コンソールに接続されます。第3.3.1項を参照してください。

- Oracle HTTP ServerをOracle WebLogic Serverクラスタまたはサーバーに接続する。こうすると、アプリケーションはOracle HTTP Serverを介してクラスタやサーバーにルーティングされます。第3.3.2項を参照してください。

- Oracle Web Services Managerエージェントをポリシー・マネージャに接続する。『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のポリシー・マネージャの自動検出でのクロス・コンポーネント・ワイヤリングの使用に関する項を参照してください。

3.3.1 Oracle HTTP Serverから管理サーバーへのワイヤリング

次の各トピックで説明するように、Oracle HTTP Serverを介してFusion Middleware Controlおよび管理コンソールにアクセスできるようにするために、Oracle HTTP Serverを管理サーバーに接続できます。

- 管理サーバーにOracle HTTP Serverをワイヤリングする理由

- 管理サーバーへのOracle HTTP Serverの接続

3.3.1.1 管理サーバーにOracle HTTP Serverをワイヤリングする理由

デフォルトでは、Fusion Middleware ControlおよびWebLogic Server管理コンソールにアクセスするには、管理サーバーおよびデフォルトの管理ポート(7001)に直接アクセスします。次に例を示します。

http://hostname:7001/em

ただし、多くの場合、DMZの一部としてインターネットに公開されるのは、Web層のOracle HTTP Serverインスタンスのみであり、アプリケーション層(管理サーバーが存在する層)は、別のファイアウォールによって保護されています。この場合、管理コンソールへのすべてのリクエストを管理サーバーにルーティングするように、Web層のOracle HTTP Serverインスタンスを構成できます。こうすることにより、管理者は、Oracle HTTP Serverインスタンスにアクセスするのに使用される標準のフロントエンドURLを使用して、ファイアウォールの外側から管理コンソールにアクセスできるようになります。この方法でWebサーバーを構成すると、アプリケーションをデプロイするための準備として、現在のドメインの構成を検証する方法としても機能できます。アプリケーションをアプリケーション層にデプロイすると、同様の方法でOracle HTTP Serverを構成できるようになるため、アプリケーション・ユーザーは、フロントエンドHTTP ServerインスタンスURLを介してアプリケーションにアクセスできます。

Oracle HTTP ServerをWeb層の一部として構成する方法の詳細な例は、『高可用性ガイド』の高可用性を実現するためのOracle HTTP Serverの構成に関する項を参照してください。

3.3.1.2 管理サーバーへのOracle HTTP Serverの接続

Oracle HTTP Serverを管理サーバーに接続する手順は、次のとおりです。

1. ナビゲーション・ペインで、「HTTP_Server」を展開します。

2. Oracle HTTP Serverインスタンス(ohs1など)を選択します。
「Oracle HTTP Server」ページが表示されます。

3. Oracle HTTP Serverのメニューから「管理」を選択し、「mod_wl_ohs構成」を選択します。
次の図に示すように、「mod_wl_ohs構成」ページが表示されます。

4. 管理サーバーに接続するには、クラスタまたはホストを選択できます。「WebLogic Serverホストおよびポート詳細の指定」を選択する場合、次の詳細を指定します。

- 「WebLogicホスト」に、管理サーバーのホスト名を入力します。

- 「WebLogicポート」に、管理サーバーのサーバー・ポートを入力します。

または、検索アイコンをクリックできます。次に管理サーバーを選択し、「OK」をクリックします。各フィールドには自動的に入力されます。

続いて、次の情報を入力します。

- 「エラー・ページ」で、サーバーがリクエストを転送できない場合に表示するページのURLを入力します。

- 「WebLogic一時ディレクトリ」で、Oracle WebLogic Serverの一時ディレクトリの絶対パスを入力します。

- 「パスまたはMIMEタイプの除外」で、プロキシの対象から除外するパスまたはMIMEタイプを入力します。

5. 「ロケーション」のセクションで、「自動入力」をクリックします。
WebLogic Serverの有効なエンドポイント位置がすべて表示されます。

6. 表から「/em」を選択します。

7. 管理コンソールを追加する手順は、次のとおりです。

1. 「行の追加」をクリックします。

2. 場所として「/console」と入力します。

3. 「WebLogicホスト」に、管理サーバーのホスト名を入力します。

4. 「ポート」に、管理サーバーのポート番号を入力します。

8. 「適用」をクリックします。

9. Oracle HTTP Serverインスタンスをシャットダウンし、再起動します。

3.3.2 Oracle HTTP Serverを介してアプリケーションをOracle WebLogic Serverにルーティングする

リクエストがOracle HTTP Serverを介してOracle WebLogic Serverにルーティングされるように、Oracle HTTP Serverを接続する手順は、次のとおりです。

1. ナビゲーション・ペインからドメインを展開し、次に「HTTP Server」を展開します。

2. Oracle HTTP Serverインスタンス(ohs1など)を選択します。
「Oracle HTTP Server」ページが表示されます。

3. Oracle HTTP Serverのメニューから「管理」を選択し、「mod_wl_ohs構成」を選択します。
「mod_wl_ohs構成」ページが表示されます。

4. リクエストがクラスタにルーティングされるようにするには、「WebLogicクラスタ」にクラスタ・アドレスを入力します。または、検索アイコンをクリックしてクラスタを選択できます。各フィールドには自動的に入力されます。
単一のWebLogicサーバーにリクエストがルーティングされるようにする手順は、次のとおりです。

- 「WebLogicホスト」にサーバー名を入力します。

- 「WebLogicポート」にサーバー・ポートを入力します。

または、「WebLogicホスト」の横にある検索アイコンをクリックできます。次に、リストからサーバーを選択し、「OK」をクリックします。各フィールドには自動的に入力されます。

WebLogicクラスタと、WebLogicホストおよびポートの両方に値を入力した場合は注意してください。WebLogicクラスタが使用されます。

5. 次の情報を入力します。

- 「エラー・ページ」で、サーバーがリクエストを転送できない場合に表示するページのURLを入力します。

- 「WebLogic一時ディレクトリ」で、Oracle WebLogic Serverの一時ディレクトリの絶対パスを入力します。

- 「パスまたはMIMEタイプの除外」で、プロキシの対象から除外するパスまたはMIMEタイプを入力します。

6. 「ロケーション」のセクションで、「自動入力」をクリックします。
WebLogic Serverの有効なエンドポイント位置がすべて表示されます。

7. 表からアプリケーションを選択します。

8. 「適用」をクリックします。

9. Oracle HTTP Serverインスタンスをシャットダウンし、再起動します。

4 Oracle Fusion Middlewareの起動と停止

この章では、Oracle Fusion Middlewareの起動と停止の手順(管理サーバー、管理対象サーバーおよびコンポーネントを含む)について説明します。

内容は次のとおりです。

- 起動および停止手順の概要

- 管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止

- コンポーネントの起動と停止

- Fusion Middleware Controlの起動と停止

- アプリケーションの起動と停止

- Oracle Fusion Middleware環境の起動と停止

- 起動と停止: 特殊なトピック

4.1 起動および停止手順の概要

Oracle Fusion Middlewareは、使用者の要件に応じて、様々な方法で起動および停止できる柔軟性のある製品です。多くの場合、Fusion Middleware Control、Oracle WebLogic Server管理コンソールまたはWLSTコマンドを使用して、Oracle Fusion Middlewareコンポーネントを起動または停止できます。

これらのツールは完全に互換性があり、ほとんどの場合、相互に使用できます。たとえば、WLSTを使用してJ2EEコンポーネントを起動し、Fusion Middleware Controlを使用して停止できます。

4.2 管理サーバー、管理対象サーバーおよびノード・マネージャの起動と停止

Oracle WebLogic Server管理サーバーは、WLSTコマンド行を使用して起動できます。管理対象サーバーは、スクリプト、WLSTコマンド行、WebLogic Server管理コンソールまたはFusion Middleware Controlを使用して起動または停止できます。次の項では、WLSTコマンド行、Fusion Middleware Control、またはその両方を使用してWebLogic Serverを起動および停止する方法について説明します。

- 管理サーバーの起動と停止

- ノード・マネージャの起動と停止

- 管理対象サーバーの起動と停止

- 資格証明を入力しないサーバーの起動の有効化

- WindowsサービスとしてのOracle WebLogic Serverの設定

4.2.1 管理サーバーの起動と停止

Oracle WebLogic Server管理サーバーは、WLSTコマンド行またはスクリプトを使用して起動および停止できます。管理サーバーを起動または停止する場合、管理サーバーで稼働しているWebLogic Server管理コンソールやFusion Middleware Controlなどのプロセスも起動または停止します。

たとえば、管理サーバーを起動するには、次のスクリプトを使用します。

DOMAIN_HOME/bin/startWebLogic.sh

管理サーバーを停止するには、次のスクリプトを使用します。

DOMAIN_HOME/bin/stopWebLogic.sh
username password [admin_url]

4.2.2 ノード・マネージャの起動と停止

デフォルトで、ノード・マネージャはOracle Fusion Middlewareの構成時に構成されます。ノード・マネージャが構成されていない場合は、ノード・マネージャのプロパティStartScriptEnabledをTrueに変更することが非常に重要です。このプロパティがFalseに設定されていると、Oracle Fusion Middlewareコンポーネントが使用するために構成された管理対象サーバーを起動するときに、エラーや障害が発生します。詳細は、第2.7.1項を参照してください。

ノード・マネージャは、WLSTコマンド行またはスクリプトを使用して起動できます。

たとえば、ノード・マネージャを起動するには、次のスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd

ノード・マネージャを停止するには、ノード・マネージャが実行されているコマンド・シェルを終了します。

または、nodemanager.properties属性QuitEnabledをtrueに設定後に(デフォルトはfalse)、WLSTを使用してノード・マネージャに接続し、停止できます。詳細は、『WebLogic Server WLSTコマンド・リファレンス』のstopNodeManagerに関する項を参照してください。

4.2.3 管理対象サーバーの起動と停止

次の各項で説明するように、Fusion Middleware ControlまたはWLSTコマンドおよびスクリプトを使用して、管理対象サーバーを起動および停止できます。

- Fusion Middleware Controlを使用した管理対象サーバーの起動と停止

- スクリプトを使用した管理対象サーバーの起動と停止

4.2.3.1 Fusion Middleware Controlを使用した管理対象サーバーの起動と停止

Fusion Middleware ControlおよびOracle WebLogic Server管理コンソールでは、ノード・マネージャを使用して管理対象サーバーを起動します。Oracle WebLogic Server以外のOracle Fusion Middleware製品が含まれない管理対象サーバーを起動する場合、この項の手順を使用してサーバーを起動できます。

ただし、Oracle JRF、Oracle SOA Suiteなどの他のOracle Fusion Middleware製品が管理対象サーバーに含まれている場合は、第2.7.1項の説明に従って、最初にノード・マネージャを構成する必要があります。

Fusion Middleware Controlを使用してWebLogic Server管理対象サーバーを起動および停止するには:

1. ナビゲーション・ペインからドメインを展開します。

2. 管理対象サーバーを選択します。

3. 「WebLogic Server」メニューから、「コントロール」を選択してから、「起動」または「停止」を選択します。

また、サーバーを右クリックして、「コントロール」を選択してから、「起動」または「停止」も選択できます。

4.2.3.2 スクリプトを使用した管理対象サーバーの起動と停止

スクリプトまたはWLSTを使用して、WebLogic Server管理対象サーバーを起動および停止できます。

たとえば、WebLogic Server管理対象サーバーを起動するには、次のスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/startManagedWebLogic.sh
managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\startManagedWebLogic.cmd
managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

WebLogic Server管理対象サーバーを停止するには、次のスクリプトを使用します。

(UNIX) DOMAIN_HOME/bin/stopManagedWebLogic.sh
managed_server_name admin_url
(Windows) DOMAIN_HOME\bin\stopManagedWebLogic.cmd
managed_server_name admin_url

プロンプトが表示されたらユーザー名とパスワードを入力します。

WLSTを使用した管理対象サーバーの起動と停止の詳細は、『WebLogic Scripting Toolの理解』のサーバー・ライフサイクルの管理に関する項を参照してください。

4.2.4 資格証明を入力しないサーバーの起動の有効化

管理者のユーザー名とパスワードの入力を求められることなく、管理サーバーおよび管理対象サーバーを起動できます。

1. 管理サーバーの場合、boot.propertiesファイルを作成します。

1. 次のディレクトリを作成します。

DOMAIN_HOME/servers/AdminServer/security

2. テキスト・エディタを使用して、前の手順で作成したセキュリティ・ディレクトリにboot.propertiesというファイルを作成し、そのファイルに次の行を入力します。

username=adminuser
password=password

2. 各管理対象サーバーの場合は、次のとおりです。

1. 次のディレクトリを作成します。

DOMAIN_HOME/servers/server_name/security

2. 管理サーバー用に作成したboot.propertiesファイルを前の手順で作成したセキュリティ・ディレクトリにコピーします。

3. 第4.2.1項および第4.2.3項の説明に従って、管理サーバーおよび管理対象サーバーを再起動します。

注意:
管理サーバーまたは管理対象サーバーの起動時には、このファイルのユーザー名とパスワードのエントリは暗号化されています。
セキュリティ上の理由から、ファイルのエントリが暗号化されていない状態の時間は最小限に抑えてください。ファイルの編集後は、速やかにサーバーを起動してエントリを暗号化します。

詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』の起動IDファイルに関する項を参照してください。

4.2.5 WindowsサービスとしてのOracle WebLogic Serverの設定

Windowsホスト・コンピュータの起動時にWebLogic Serverインスタンスを自動的に起動する場合、サーバーをWindowsサービスとして設定できます。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のWindowsサービスとしてのWebLogic Serverインスタンスの設定に関する項を参照してください。

ただし、その章ではスタンドアロンOracle WebLogic Serverインストールのプロセスについて説明しています。Oracle WebLogic ServerがOracle Fusion Middleware環境の一部の場合、環境を設定してORACLE_COMMONへの参照を含める必要があります。これを行うために作成するスクリプトは、管理対象サーバーをWindowsサービスとして設定するためのスクリプト例で説明されているスクリプトとは多少異なります。次に、正しいスクリプトを示します。

echo off
SETLOCAL
set DOMAIN_NAME=myWLSdomain
set USERDOMAIN_HOME=d:\Oracle\config\domains\myWLSdomain
set SERVER_NAME=myWLSserver
set PRODUCTION_MODE=true
set
JAVA_OPTIONS=-Dweblogic.Stdout="d:\Oracle\config\domains\myWLSdomain\
stdout.txt" -Dweblogic.Stderr="d:\Oracle\config\domains\myWLSdomain\stderr.txt"
set ADMIN_URL=http://adminserver:7501
set MEM_ARGS=-Xms40m -Xmx250m
call %USERDOMAIN_HOME%\bin\setDomainEnv.cmd
call "d:\Oracle_home\wlserver\server\bin\installSvc.cmd"
ENDLOCAL

4.3 コンポーネントの起動と停止

コンポーネントを起動および停止するには、そのコンポーネントに応じて、コマンド行、WebLogic Server管理コンソール、またはFusion Middleware Controlを使用します。次の各項では、Fusion Middleware Controlおよびコマンド行を使用してコンポーネントを起動および停止する方法について説明します。

- Fusion Middleware Controlを使用したコンポーネントの起動と停止

- コマンド行を使用したコンポーネントの起動と停止

4.3.1 Fusion Middleware Controlを使用したコンポーネントの起動と停止

コンポーネントを起動または停止するには:

1. ナビゲーション・ペインからコンポーネントにナビゲートします。

2. OHSなどのコンポーネントを選択します。

3. 動的ターゲット・メニューから、「コントロール」を選択してから、「起動」または「停止」を選択します。

4.3.2 コマンド行を使用したコンポーネントの起動と停止

コンポーネントがJavaコンポーネントの場合、WLSTコマンドを使用してコンポーネントを起動および停止できます。コンポーネントがシステム・コンポーネントの場合は、スクリプトを使用してWLSTコマンドを呼び出し、コンポーネントを起動および停止できます(次の各トピックを参照)。

- Javaコンポーネントの起動と停止

- システム・コンポーネントの起動と停止

4.3.2.1 Javaコンポーネントの起動と停止

Javaコンポーネントを起動および停止するには、WLSTのstartApplicationおよびstopApplicationコマンドを使用します。

startApplication(appName, [options])
stopApplication(appName, [options])

たとえば、Oracle Web Services Managerポリシー・マネージャを起動するには、次のコマンドを使用します。

startApplication("wsm-pm")

4.3.2.2 システム・コンポーネントの起動と停止

コンポーネントがシステム・コンポーネントの場合、コンポーネントを起動および停止するには、スクリプトを使用してWLSTコマンドを呼び出すか、またはWLSTコマンドを使用できます。

- システム・コンポーネントを起動および停止するには、startComponentスクリプトおよびstopComponentスクリプトを使用します。この方法は、スタンドアロン・ドメインまたはWebLogic ServerドメインにあるOracle HTTP Serverなどのシステム・コンポーネントに使用できます。これらのコンポーネントは、管理サーバーが含まれているホストから起動する必要があります。
これらのスクリプトは次の場所にあります。

(UNIX) DOMAIN_HOME/bin
(Windows) DOMAIN_HOME\bin

これらのスクリプトを使用してコンポーネントを起動または停止するには、次の構文を使用します。

./startComponent.sh component_name [storeUserConfig] [showErrorStack]
./stopComponent.sh component_name [storeUserConfig] [showErrorStack]

この構文では、次の変数が使用されています。

- component_name: コンポーネント・インスタンスの名前(ohs1など)。

- storeUserConfig: 指定した場合、ユーザー名とパスワードを求めるプロンプトが表示されます。その後に、ユーザー構成をプロパティ・ファイルに格納するかどうかを問うプロンプトが表示されます。ここでyを指定すると、ユーザー構成ファイルおよび関連付けられたキー・ファイルが作成されます。ユーザー構成ファイルには暗号化されたユーザー名とパスワードが含まれています。キー・ファイルには、ユーザー名とパスワードの暗号化と復号化に使用される秘密鍵が含まれています。プロパティ・ファイルの名前および場所を次に示します。

user_home/.wlst/nm-key-domain_name.props
user_home/.wlst/nm-cfg-domain_name.props

プロパティ・ファイルに情報を格納すると、それ以降にスクリプトを実行してもユーザー名とパスワードを求めるプロンプトは表示されません。

- showErrorStack: より詳細なエラー情報(エラー・スタック内のすべてのエラー・メッセージを含む)が表示されます。エラーの原因を特定する必要がある場合は、このオプションを指定します。

たとえば、ohs1というOracle HTTP Serverインスタンスを起動するには、次のスクリプトを実行します。

./startComponent.sh ohs1

これらのスクリプトを使用して、リモートでシステム・コンポーネントを起動、停止することもできます。その場合、スクリプトはコンポーネントの場所を判別するために構成を読み取ります。

- WLSTコマンドを使用してシステムを起動するには、次のいずれかのメソッドを使用できます。

- nmstartコマンド。この方法は、スタンドアロン・ドメインまたはWebLogic ServerドメインのOracle HTTP Serverに使用できます。
たとえば、Oracle HTTP ServerコンポーネントOHS1を起動するには、次のWLSTコマンドを使用します。

nmConnect(domainName='domain_name', username='username', password='password')
nmstart(serverName='OHS1', serverType='OHS')

- WLSTのstartコマンド。このメソッドは、スタンドアロン・ドメインのOracle HTTP Serverに使用できます。
たとえば、Oracle HTTP ServerコンポーネントOHS1を起動するには、次のWLSTコマンドを使用します。

connect('username','password','hostname:port')
start('OHS1')

- WLSTコマンドを使用してシステム・コンポーネントを停止するには、WLSTのnmkillコマンドを使用します。
たとえば、Oracle HTTP ServerコンポーネントOHS1を停止するには、次のWLSTコマンドを使用します。

nmKill(serverName='ohs1', serverType='OHS')

どちらのメソッドを使用するか決定するには、次の点に留意してください。

- WLSTスクリプトを使用している場合は、WLSTコマンドを使用します。

- システム・コンポーネントを対話型で迅速に起動、停止するには、スクリプトを使用します。

- システム・コンポーネントをリモートで起動、停止するには、スクリプトを使用します。

4.4 Fusion Middleware Controlの起動と停止

Fusion Middleware Controlがドメインに対して構成されている場合は、第4.2.1項で説明されているとおり、Oracle WebLogic Server管理サーバーを起動または停止すると、Fusion Middleware Controlが自動的に起動または停止されます。

4.5 アプリケーションの起動と停止

アプリケーションは、Fusion Middleware Control、WebLogic Server管理コンソール、またはWLSTコマンド行を使用して起動および停止できます。次の各項では、Fusion Middleware Controlおよびコマンド行を使用してアプリケーションを起動および停止する方法について説明します。

- Fusion Middleware Controlを使用したJava EEアプリケーションの起動と停止

- WLSTを使用したJava EEアプリケーションの起動と停止

4.5.1 Fusion Middleware Controlを使用したJava EEアプリケーションの起動と停止

Fusion Middleware Controlを使用してJava EEアプリケーションを起動および停止するには:

1. ナビゲーション・ペインで、「アプリケーションのデプロイ」を開きます。

2. アプリケーションを選択します。

3. 「アプリケーションのデプロイ」メニューから、「コントロール」を選択してから、「起動」または「停止」を選択します。

Oracle SOA SuiteまたはOracle WebCenter PortalなどのOracle Fusion Middlewareの起動と停止の詳細は、そのコンポーネントの管理ガイドを参照してください。

4.5.2 WLSTを使用したJava EEアプリケーションの起動と停止

WLSTコマンド行を使用してJava EEアプリケーションを起動および停止するには、次のコマンドを使用します。

startApplication(appName, [options])
stopApplication(appName, [options])

アプリケーションは、ドメイン内で完全に構成されて使用可能である必要があります。startApplicationコマンドは、WLSTProgressオブジェクトを返します。このオブジェクトにアクセスすると、コマンドのステータスを確認できます。エラーが発生した場合、コマンドはWLSTExceptionを返します。WLSTProgressオブジェクトの詳細は、『WebLogic Scripting Toolの理解』のWLSTProgressオブジェクトに関する項を参照してください。

4.6 Oracle Fusion Middleware環境の起動と停止

この項では、Oracle Fusion Middleware環境を起動および停止する手順について説明します。環境は、Oracle WebLogic Serverドメイン、管理サーバー、複数の管理対象サーバー、Javaコンポーネント、アイデンティティ管理コンポーネントなどのシステム・コンポーネント、およびメタデータのリポジトリに使用されるデータベースで構成できます。これらのコンポーネントは相互に依存する場合があります。したがって、特定の順序で起動および停止することが重要です。

4.6.1 Oracle Fusion Middleware環境の起動

Oracle Fusion Middleware環境を起動する手順は次のとおりです。

1. メタデータ・スキーマをホストしているデータベースを起動します。次の手順は、データベースを起動する方法の一例を示しています。

1. データベースの場所にナビゲートします。たとえば、データベースがOracle Fusion Middleware以外の別のホストにある場合があります。

2. ORACLE_HOME環境変数をデータベースのOracleホームに設定します。

3. ORACLE_SID環境変数をデータベースのSID(デフォルトはorcl)に設定します。

4. Netリスナーを起動します。

ORACLE_HOME/bin/lsnrctl start

5. データベース・インスタンスを起動します。

ORACLE_HOME/bin/sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> startup
SQL> quit

Oracle Databaseの起動方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

2. 第4.2.1項の説明に従って、管理サーバーを起動します。

3. 第4.2.2項の説明に従って、ノード・マネージャを起動します。

4. 環境を構成しているOracle Internet DirectoryなどのOracle Identity Managementコンポーネントがあれば、それをすべて起動します。

5. 第4.2.3.2項の説明に従って、管理対象サーバーを起動します。
注意: 通常は、管理対象サーバーの起動により、それにデプロイされているアプリケーションが開始されます。したがって、管理対象サーバーの起動後にアプリケーションを手動で開始する必要はありません。

6. Oracle HTTP Serverなどの、その他のシステム・コンポーネントをすべて起動します。

(UNIX) DOMAIN_HOME/bin/startComponent.sh component_name
(Windows) DOMAIN_HOME\bin\startComponent.cmd component_name

4.6.2 Oracle Fusion Middleware環境の停止

Oracle Fusion Middleware環境を停止する手順は次のとおりです。

1. Oracle HTTP Serverなどのシステム・コンポーネントを停止します。これらは、任意の順序で停止できます。

(UNIX) DOMAIN_HOME/bin/stopComponent.sh component_name
(Windows) DOMAIN_HOME\bin\stopComponent.cmd component_name

2. 第4.2項の説明に従って、管理対象サーバーを停止します。サーバーにデプロイされているすべてのアプリケーションも停止されます。

3. 環境を構成しているOracle Internet Directoryなどの11g Oracle Identity Managementコンポーネントがあれば、それをすべて停止します。

4. 第4.2.1項の説明に従って管理サーバーを停止します。

5. 第4.2.2項の説明に従って、ノード・マネージャを停止します。

6. メタデータ・スキーマをホストしているデータベースを起動します。次の手順は、データベースを停止する方法の一例を示しています。

1. データベースの場所にナビゲートします。たとえば、データベースがOracle Fusion Middleware以外の別のホストにある場合があります。

2. ORACLE_HOME環境変数をデータベースのOracleホームに設定します。

3. ORACLE_SID環境変数をデータベースのSID(デフォルトはorcl)に設定します。

4. データベース・インスタンスを停止します。

ORACLE_HOME/bin/sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> shutdown
SQL> quit

5. Netリスナーを停止します。

ORACLE_HOME/bin/lsnrctl stop

Oracle Databaseの停止方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

4.7 起動と停止: 特殊なトピック

この項では、Oracle Fusion Middlewareの起動および停止に関する特殊なトピックについて説明します。この項の項目は次のとおりです。

- 高可用性環境での起動と停止

- Oracle Databaseの強制停止

4.7.1 高可用性環境での起動と停止

次に示す高可用性環境では、起動および停止について特別な検討と手順が必要です。

- アクティブ-アクティブ・ソリューション

- アクティブ-パッシブ・ソリューション

高可用性環境での起動と停止の詳細は、『高可用性ガイド』を参照してください。

4.7.2 Oracle Databaseの強制停止

Oracle Databaseインスタンスの停止に時間がかかる場合、次のコマンドを使用してただちに強制停止できます。

ORACLE_HOME/bin/sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> SHUTDOWN IMMEDIATE;

データベースの即時停止は、次の条件で処理されます。

- 文が発行されると、新しい接続は許可されず、新しいトランザクションは開始できません。

- すべての未コミットのトランザクションは、ロールバックされます。(長くかかる未コミットのトランザクションが存在する場合、この停止方法ではその名前に反して即座に終了しない場合があります。)

- 現在データベースに接続しているユーザーが切断するのを待つことはありません。アクティブなトランザクションは暗黙的にロールバックして、接続しているすべてのユーザーを切断します。

次にデータベースを起動するときに、インスタンス・リカバリ手順は必要ありません。

Oracle Databaseの停止の詳細は、Oracle Databaseドキュメント・ライブラリの『Oracle Database管理者ガイド』を参照してください。

5 ポートの管理

この章では、Oracle WebLogic ServerまたはOracle HTTP Serverによって使用されるポート番号などの、Oracle Fusion Middlewareポート番号の確認および変更方法について説明します。

内容は次のとおりです。

- ポートの管理について

- ポート番号の表示

- Oracle Fusion Middlewareで使用するポート番号の変更

5.1 ポートの管理について

Oracle Fusion Middlewareの多くのコンポーネントやサービスはポートを使用します。ほとんどのポート番号はドメインの作成時に割り当てられます。それらのサービスで使用されるポート番号を認識し、同じポート番号をホスト上の2つのサービスで使用されないようにすることは、管理者として重要です。

一部のポートは、ドメインの作成時にポート番号割当てを指定できます。

ポート番号のリストは、付録Dを参照してください。インストール時のポートの割当てを無効にする方法の詳細は、インストレーション・ガイドを参照してください。

5.2 ポート番号の表示

次の項で説明されているように、コマンド行またはFusion Middleware Controlを使用して、現在使用中のポート番号を表示できます。

- コマンド行を使用したポート番号の表示

- Fusion Middleware Controlを使用したポート番号の表示

5.2.1 コマンド行を使用したポート番号の表示

Oracle WebLogic Serverのポート番号を表示するには、属性を指定してWLSTのgetコマンドを使用します。たとえば、管理ポートを取得するには、次のコマンドを使用します。

wls:/WLS_domain/serverConfig> get('AdministrationPort')
9002

5.2.2 Fusion Middleware Controlを使用したポート番号の表示

Fusion Middleware Controlを使用して、ドメイン、管理サーバー、管理対象サーバー、またはOracle HTTP Serverなどのコンポーネントのポート番号を表示できます。

たとえば、ドメインのポートを表示するには、次の手順を実行します。

1. 「WebLogicドメイン」メニューで「モニタリング」、「ポートの使用状況」を選択します。
次の図に示すように、「ポートの使用状況」ページが表示されます。

オプションで、「表示」から管理対象サーバーを選択することで、表示するポートをフィルタできます。

「ポートの使用状況の詳細」表に、使用されているポート、IPアドレス、コンポーネント、チャネルおよびプロトコルが表示されます。

ターゲットに移動し、ターゲットのメニューから「ポートの使用状況」を選択することで、管理サーバー、管理対象サーバーおよびOracle HTTP Serverなどのコンポーネントについて同様のページを表示できます。

5.3 Oracle Fusion Middlewareで使用するポート番号の変更

Fusion Middleware Control、Oracle WebLogic Server管理コンソールまたはコマンド行を使用して、一部のOracle Fusion Middlewareコンポーネントのポート番号を変更できます。

注意:
ポート番号は、未使用であるポートの任意のポート番号に変更できます。コンポーネントに割り当てられているポート範囲内のポート番号を使用する必要はありません。割当て済のポート範囲の詳細は、付録Dを参照してください。

この項の内容は次のとおりです。

- Oracle WebLogic Serverリスニング・ポートの変更

- ノード・マネージャのリスニング・ポートの変更

- Oracle HTTP Serverリスニング・ポートの変更

- Oracle Database Netリスナー・ポートの変更

その他のポートの変更の詳細は、次を参照してください。

- ノード・マネージャ・ポートの変更の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャ構成に関する項

5.3.1 Oracle WebLogic Serverリスニング・ポートの変更

次の各項目で説明するように、Oracle WebLogic Server管理コンソールまたはWLSTを使用して、管理サーバーまたは管理対象サーバーの非SSL (HTTP)リスニング・ポートおよびSSL (HTTPS)リスニング・ポートを変更できます。

- Fusion Middleware Controlを使用したOracle WebLogic Serverリスニング・ポートの変更

- WLSTを使用したOracle WebLogic Serverリスニング・ポートの変更

Oracle WebLogic Serverポートの変更の詳細は、『Oracle WebLogic Serverサーバー環境の管理』を参照してください。

5.3.1.1 Fusion Middleware Controlを使用したOracle WebLogic Serverリスニング・ポートの変更

Fusion Middleware Controlを使用して、管理サーバーまたは管理対象サーバーの非SSL (HTTP)リスニング・ポートおよびSSL (HTTPS)リスニング・ポートを変更するには、次の手順を実行します。

1. ターゲット・ナビゲーション・ペインで、サーバーを選択します。

2. 「WebLogic Server」メニューで、「管理」→「一般設定」を選択します。

3. 「構成」タブを選択します。「一般設定」タブで、「リスニング・ポート」または「SSLリスニング・ポート」の数値を変更します。

4. サーバーが稼働中であれば、サーバーを再起動します。

5. 別のコンポーネントがOracle WebLogic Serverリスニング・ポートに依存している場合、これらのコンポーネントを再構成する必要があります。

5.3.1.2 WLSTを使用したOracle WebLogic Serverリスニング・ポートの変更

WLSTコマンド行を使用して、管理サーバーまたは管理対象サーバーの非SSL (HTTP)リスニング・ポートおよびSSL (HTTPS)リスニング・ポートを変更するには、次の手順を実行します。コマンドはオフライン・モードで(サーバーに接続せずに)実行する必要があります。

たとえば、管理サーバーのHTTPリスニング・ポートをポート8001に変更するには、次のWLSTコマンドを使用します。

readDomain("oracle/config/domains/domain_name")
cd("servers/AdminServer")
cmo.setListenPort(8001)
updateDomain()

5.3.2 ノード・マネージャのリスニング・ポートの変更

ノード・マネージャのリスニング・ポートは、以降の項で説明しているように、Oracle WebLogic Server管理コンソールやWLSTを使用して変更できます。

- WLSTを使用したノード・マネージャのリスニング・ポートの変更

- Fusion Middleware Controlを使用したノード・マネージャのリスニング・ポートの変更

5.3.2.1 WLSTを使用したノード・マネージャのリスニング・ポートの変更

WLSTを使用してノード・マネージャのリスニング・ポートを変更するには:

readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenPort',new_port_number)
updateDomain()

5.3.2.2 Fusion Middleware Controlを使用したノード・マネージャのリスニング・ポートの変更

Fusion Middleware Controlを使用してノード・マネージャのリスニング・ポートを変更するには、新しいポートを指し示すようマシンの構成を変更します。

1. ノード・マネージャのプロパティ・ファイルを編集して、リスニング・ポート・プロパティを変更します。ドメインベースのノード・マネージャの場合、ファイルは次の場所にあります。

DOMAIN_HOME/nodemanager/nodemanager.properties

2. 「WebLogicドメイン」メニューから「環境」→「マシン」を選択します。

3. 「マシン」ページで、マシンを選択します。

4. 「構成」タブを選択します。

5. 「ノード・マネージャ」タブを選択します。

6. 「リスニング・ポート」を新しいポート番号に変更します。

7. 「保存」をクリックします。

5.3.3 Oracle HTTP Serverリスニング・ポートの変更

Oracle HTTP Serverリスニング・ポート(非SSLまたはSSL)を変更する場合、通常、設定する必要がある依存関係が存在します。

次の各項では、Oracle HTTP ServerのHTTPまたはHTTPSリスニング・ポートを変更する方法について説明します。

- 1024未満に設定されたポート使用時のOracle HTTP Serverのroot実行の有効化(UNIXのみ)

- WebLogic ServerドメインでのOracle HTTP Serverの非SSLリスニング・ポートの変更

- WebLogic ServerドメインでのOracle HTTP ServerのSSLリスニング・ポートの変更

- スタンドアロン・ドメインでのOracle HTTP Serverリスニング・ポートの変更

5.3.3.1 1024未満に設定されたポート使用時のOracle HTTP Serverのroot実行の有効化(UNIXのみ)

デフォルトでは、Oracle HTTP Serverは非rootユーザー(Oracle Fusion Middlewareをインストールしたユーザー)として実行されます。UNIXシステムでは、Oracle HTTP Serverのリスニング・ポート番号を1024未満の値に変更する場合は、rootとして実行するようにOracle HTTP Serverを有効にする必要があります。

rootとして実行するようにリスニング・ポートを有効にする方法の詳細は、『Oracle HTTP Server管理者ガイド』の権限ポートでのOracle HTTP Serverインスタンスの起動(UNIXの場合のみ)に関する項を参照してください。

5.3.3.2 WebLogic ServerドメインでのOracle HTTP Serverの非SSLリスニング・ポートの変更

Oracle HTTP Serverの非SSL (HTTP)リスニング・ポートを変更するには、次の手順を実行します。UNIXシステムでリスニング・ポートを1024未満の番号に変更する場合は、最初に第5.3.3.1項の手順を実行する必要があります。

Fusion Middleware Controlを使用してOracle HTTP Serverリスニング・ポートを変更するには:

1. ナビゲーション・ペインで、「HTTP_Server」を展開します。次に、Oracle HTTP Serverインスタンスを選択します。

2. 「Oracle HTTP Server」メニューで、「管理」→「ポート構成」を選択します。

3. HTTPプロトコルを使用するリスニング・ポートを選択して、「編集」をクリックします。

4. ポート番号を変更して、「OK」をクリックします。

5. Oracle HTTP Serverを再起動します。(「Oracle HTTP Server」メニューで、「コントロール」→「再起動」を選択します。)

5.3.3.3 WebLogic ServerドメインでのOracle HTTP ServerのSSLリスニング・ポートの変更

Oracle HTTP ServerのSSL (HTTPS)リスニング・ポートを変更するには、次の手順を実行します。UNIXシステムでリスニング・ポートを1024未満の番号に変更する場合は、第5.3.3.1項の手順を実行する必要があります。

Fusion Middleware Controlを使用してOracle HTTP Server SSLリスニング・ポートを変更するには:

1. ナビゲーション・ペインで、「HTTP_Server」を展開します。次に、Oracle HTTP Serverインスタンスを選択します。

2. 「Oracle HTTP Server」メニューで、「管理」→「ポート構成」を選択します。

3. HTTPSプロトコルを使用するリスニング・ポートを選択して、「編集」をクリックします。

4. ポート番号を変更して、「OK」をクリックします。

5. Oracle HTTP Serverを再起動します。(「Oracle HTTP Server」メニューで、「コントロール」→「再起動」を選択します。)

5.3.3.4 スタンドアロン・ドメインでのOracle HTTP Serverリスニング・ポートの変更

スタンドアロン・ドメインにおいてOracle HTTP Serverの非SSLおよびSSLリスニング・ポートを変更するには、次のファイルを変更します。

DOMAIN_HOME/config/fmwconfig/components/OHS/component_name/httpd.conf
DOMAIN_HOME/config/fmwconfig/components/OHS/component_name/admin.conf
DOMAIN_HOME/config/fmwconfig/components/OHS/component_name/ssl.conf

5.3.4 Oracle Database Netリスナー・ポートの変更

環境にメタデータ・リポジトリとして機能するOracle Databaseが含まれるときに、そのデータベースのリスナー・ポート番号を変更する場合は、この項で説明する手順を実行します。

最初に、リスナー・ポート番号の変更が必要かどうかを判断します。ホスト上に同じポートを使用する別のデータベースがある場合でも、両方のデータベースで同じポートを使用できます。

複数のOracle Database 10g、Oracle Database 11g、Oracle Database 12cデータベースで、同じOracle Netリスナー・ポートを共有できます。メタデータ・リポジトリとしてOracle Databaseを使用しているホストに別のOracle Database 10g、Oracle Database 11g、Oracle Database 12cデータベースが含まれる場合、それらはすべてポート1521を使用できます。リスナー・ポート番号を変更する必要はありません。

注意:
ホスト上で同じキー値を使用する2つのリスナーを実行する場合は、第5.3.4.1項「IPCリスナーのKEY値の変更」を参照してください。

データベース・リスナー・ポートを変更するには:

1. メタデータ・リポジトリを使用するすべてのコンポーネントを停止します。手順は、第4章を参照してください。

2. メタデータ・リポジトリ・ホストで、メタデータ・リポジトリのOracle Netリスナー・ポートを変更します。

1. ORACLE_HOMEおよびORACLE_SID環境変数が設定されていることを確認します。

2. メタデータ・リポジトリ・リスナーを停止します。

lsnrctl stop

3. 次の場所にあるlistener.oraファイルを編集します。

(UNIX) ORACLE_HOME/network/admin/listener.ora
(Windows) ORACLE_HOME\network\admin\listener.ora

LISTENERエントリの下にあるPORTの値を更新します。ファイルを保存します。

4. tnsnames.oraファイルを編集します。デフォルトの場所は次のとおりです。

(UNIX) ORACLE_HOME/network/admin/tnsnames.ora
(Windows) ORACLE_HOME\network\admin\tnsnames.ora

ファイルに次の変更を加えます。

- MDSリポジトリに適用する各エントリでPORT値を更新します。

- 次のようなエントリを追加します。

newnetport =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = tcp) (HOST = hostname) (PORT = port)))

この例で、hostnameは完全修飾のホスト名、portは新しいポート番号です。

5. メタデータ・リポジトリ・リスナーを起動します。

lsnrctl start

6. SQL*Plusを使用して、SYSDBA権限を持つSYSTEMユーザーとしてメタデータ・リポジトリにログインし、次のコマンドを実行します。

SQL> ALTER SYSTEM SET local_listener='newnetport' scope=spfile;

7. SQL*Plusを使用して、メタデータ・リポジトリを再起動します。

SQL> SHUTDOWN
SQL> STARTUP

(UNIX) DOMAIN_HOME/bin/startComponent.sh OID1
(Windows) DOMAIN_HOME\bin\startComponent.cmd OID1

3. メタデータ・リポジトリに新しいポート番号を使用するようにシステム・データ・ソースを変更します。これを行うには、Fusion Middleware Controlを使用できます。

1. チェンジ・センターで、「ロックして編集」をクリックします。

2. ナビゲーション・ペインで、ドメインを展開します。
「WebLogicドメイン」ページが表示されます。

3. 「WebLogicドメイン」メニューから「JDBCデータ・ソース」を選択します。
「JDBCデータ・ソースのサマリー」ページが表示されます。

4. 変更するデータ・ソースを選択します。
「JDBCデータ・ソース」ページが表示されます。

5. 「接続プール」タブを選択します。

6. データベース・ポートを変更するには、「データベースURL」フィールドを変更します。次に例を示します。

jdbc:oracle:thin:@hostname.domainname.com:1522/orcl

7. 「保存」をクリックします。

8. このデータ・ソースを使用するサーバーを再起動します。(「ターゲット」タブをクリックし、このデータ・ソースを使用するサーバーを表示します。)

5.3.4.1 IPCリスナーのKEY値の変更

2つのリスナーのIPCプロトコル・アドレスに同じKEY値の使用が構成されている場合は、それらを同時に実行できません。デフォルトでは、メタデータ・リポジトリ・リスナーのIPC KEY値はEXTPROCに設定されます。したがって、EXTPROCキーを使用するIPCリスナーが他にもある場合は、EXTPROC1などの別のキー値を使用するようにメタデータ・リポジトリ・リスナーを構成する必要があります。

IPCリスナーのKEY値を変更する手順は次のとおりです。

1. リスナーを停止します(ORACLE_HOME環境変数が最初に設定されていることを確認します)。

lsnrctl stop

2. listener.oraおよびtnsnames.oraファイルを編集します。各ファイルで、次の行を探します。

(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))

この行を次のように変更します。

(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))

3. リスナーを再起動します。

lsnrctl start

第III部

セキュアな通信

この部では、Oracle Fusion Middlewareコンポーネント間の通信を保護する方法について説明します。Secure Sockets Layer (SSL)、キーストア、ウォレット、証明書、FIPSサポートなどのテクノロジについて説明します。

第III部は、次の章で構成されています。

- 第6章「Oracle Fusion MiddlewareでのSSLの構成」

- 第7章「キーストア、ウォレットおよび証明書の管理」

- 第8章「Oracle Fusion MiddlewareでのFIPS 140のサポート」

6 Oracle Fusion MiddlewareでのSSLの構成

この章では、Secure Sockets Layer (SSL)を使用して、Web層、中間層およびデータ層においてOracle Fusion Middlewareコンポーネント間の通信を保護するための手順について説明します。また、基本的なトポロジよりさらに高度なシナリオおよびベスト・プラクティスについても説明します。

注意:
このドキュメントでは、トランスポート・レイヤー・セキュリティ(TLS)を含むセキュアなトランスポート・メカニズムを表すために、SSLという用語が一般的に使用されています。
SSL/TLSハンドシェイク時にクライアントが使用できる暗号スイートの詳細は、コンポーネント固有のドキュメントを参照してください。

この章の内容は次のとおりです。

- SSLのしくみ

- Oracle Fusion MiddlewareにおけるSSLについて

- 構成ツールでのSSLの構成

- Web層でのSSLの構成

- 中間層でのSSLの構成

- データ層でのSSLの構成

- 高度なSSLの使用事例

- SSLのベスト・プラクティス

- SSL関連のWLSTリファレンス

注意:
Oracle WebLogic Server内でSSL接続を構成する場合、ここでの手順を実行するかわりに、この章で紹介しているコンポーネントの関連ドキュメントを参照してください。

6.1 SSLのしくみ

この項では、基本的なSSLの概念について説明します。内容は次のとおりです。

- SSLの機能

- 秘密鍵と公開鍵の暗号化について

- キーストアおよびウォレット

- SSLセッションのしくみ

6.1.1 SSLの機能

SSLは、メッセージの暗号化、整合性および認証を提供することで、通信を保護します。SSL標準により、関係するコンポーネント(ブラウザやHTTPサーバーなど)は、どの暗号化、認証および整合性メカニズムを使用するかのネゴシエーションができます。

- 暗号化を行うと、正当な受信者のみがメッセージを読むことができ機密が保持されます。SSLでは、様々な暗号化アルゴリズムを使用してメッセージを暗号化できます。各SSLセッションの開始時に行われるSSLハンドシェイク中、クライアントとサーバーは、どのアルゴリズムを使用するかのネゴシエーションを行います。SSLがサポートしている暗号化アルゴリズムには、AES、RC4、3DESなどがあります。

- 整合性により、クライアントが送信したメッセージが改ざんされずに正当なサーバーに届きます。メッセージの整合性を確保するために、クライアントはハッシュ機能を使用してメッセージをダイジェストにハッシュし、このメッセージ・ダイジェストをサーバーに送信します。サーバーは、さらにこのメッセージをダイジェストにハッシュし、これらのダイジェストを比較します。SSLでは、2つの異なるメッセージから同じダイジェストをコンピュータで生成するのが不可能なハッシュ機能を使用しているため、サーバーでは2つのダイジェストが一致しない場合には、何者かによりメッセージが改ざんされたとみなすことができます。SSLがサポートしているハッシュ機能の1つに、SHA2があります。

- 認証を使用すると、サーバーとクライアントは互いに相手の身元を確認できます。クライアントがSSLセッションを開始すると、サーバーは通常、サーバー自身の証明書をクライアントに送信します。証明書とは、VeriSignなどの信頼できる認証局によって発行されるデジタルIDです。第7章「キーストア、ウォレットおよび証明書の管理」では、証明書について詳細に説明しています。
クライアントは、サーバー証明書内の証明連鎖を検証することで、サーバーが本物であることを確認します。サーバー証明書は、サーバー証明書に署名した認証局(CA)により保証されています。

また、サーバーがクライアントの識別を認証する必要がある場合には、サーバーがクライアントに証明書の所持を要求することもできます。

6.1.2 秘密鍵と公開鍵の暗号化について

メッセージの整合性、認証および暗号化を提供するために、SSLでは秘密鍵と公開鍵の両方の暗号化を使用します。

秘密鍵の暗号化

対称鍵の暗号化では、通信を保護する目的で2者以上が共有する1つの秘密鍵が必要です。この鍵は、当事者間で送信された安全なメッセージを暗号化および復号化するために使用します。これを行うには、安全な方法で各当事者に鍵を事前に配布しておく必要があります。この方法における問題点は、鍵を安全に転送し、格納することが困難なことです。

SSLでは、各当事者は互いに認識している乱数を使用して秘密鍵を個別に計算します。次に、その秘密鍵を使用して暗号化したメッセージを送信します。

公開鍵の暗号化

公開鍵の暗号化による公開鍵/秘密鍵のペアおよび鍵配布のための安全な方法を採用することで、この問題は解決します。対応する秘密鍵の所有者のみが復号化できるメッセージは、自由に使用できる公開鍵によって暗号化できます。秘密鍵は、その他のセキュリティ資格証明とともに、Oracleウォレットなどの暗号化されたコンテナに安全に格納されます。

公開鍵アルゴリズムでは、メッセージの秘密が保証されます。しかし通信者間の識別が検証されないため、安全な通信は必ずしも保証されません。安全な通信を確立するには、メッセージの暗号化に使用される公開鍵が相手の受信者に実際に属していることを確認することが重要です。そうしないと、第三者が通信を傍受し、公開鍵のリクエストに割り込み、正当な鍵を独自の公開鍵に置き換えることが可能になります(介在者攻撃)。

そうした攻撃を避けるには、認証と呼ばれるプロセスにより、公開鍵の所有者を検証することが必要です。その際に、通信の両当事者により信頼された、認証局(CA)と呼ばれる第三者機関が、この認証プロセスを実行できます。

CAは、エンティティの名前、公開鍵および他のセキュリティ資格証明を含む公開鍵証明書を発行します。通常、このような資格証明には、CA名、CAの署名および証明書の有効日(開始日、終了日)が含まれています。

CAでは独自の秘密鍵を使用してメッセージを暗号化します。一方、そのメッセージの復号化には公開鍵が使用されるため、メッセージがCAによって暗号化されたものであるかどうかが確認されます。CA公開鍵は広く一般に知られているため、アクセスするたびに認証する必要はありません。このようなCA公開鍵はウォレットに格納されます。

6.1.3 キーストアおよびウォレット

Oracle Fusion Middlewareでは、Oracle HTTP Serverなどのコンポーネントにおいて、記憶域メカニズムとしてOracleウォレットが使用されます。Oracleウォレットは、証明書、信頼できる証明書、証明書リクエスト、秘密鍵などの資格証明を格納するコンテナです。Oracle Internet DirectoryなどのLDAPディレクトリやファイル・システムにOracleウォレットを格納できます。Oracleウォレットは、パスワードで保護することも自動ログインにもできます。

Oracle HTTP ServerではOracleウォレットが使用されます。Oracle HTTP ServerでのSSLの構成では、Oracleウォレットを設定および使用する必要があります。

注意:
Oracle Fusion Middleware 12c (12.1.3)の時点では、キーストア・サービスで使用できる中央記憶域および統合管理を利用して、該当するサービスのエクスポート、インポートおよび同期化機能により、ウォレットとその内容を管理できます。importKeyStore、exportKeyStoreおよびsyncKeyStoreコマンドの詳細は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

他のコンポーネントはJKSキーストアまたはKSSキーストアを使用して鍵と証明書を保管するので、これらのコンポーネントのSSLの構成では、適切なキーストアを使用して設定する必要があります。

キーストアおよびウォレットの構成の詳細は、次を参照してください。

- Oracle Fusion Middlewareでのキーストアおよびウォレットの詳細は、第6.2項「Oracle Fusion MiddlewareにおけるSSLについて」を参照してください。

- それらの用語および管理作業の詳細は、第7章「キーストア、ウォレットおよび証明書の管理」を参照してください。

6.1.4 SSLセッションのしくみ

SSLプロトコルには、ハンドシェイク・フェーズとデータ転送フェーズという2つのフェーズがあります。ハンドシェイク・フェーズでは、サーバーおよびオプションでクライアントを認証し、データ転送フェーズで転送されるデータを保護するための暗号化鍵を設定します。

クライアントがサーバーへのSSL接続を要求すると、クライアントとサーバーはまずハンドシェイク・フェーズでメッセージを交換します。(一般的なシナリオとしては、http://ではなくhttps://プロトコルを使用して、サーバーからページを要求するブラウザがあります。HTTPSプロトコルは、HTTPでSSLを使用することを示します。)

図6-1に、Webサーバーとブラウザ間の一般的なSSL接続用ハンドシェイク・メッセージを示します。この図では次の手順を示しています。

1. クライアントは、サーバーにハロー・メッセージを送信します。
メッセージには、クライアントがサポートしているアルゴリズムの一覧および鍵を生成するための乱数が含まれています。

2. サーバーは、クライアントにハロー・メッセージを送信してレスポンスを返します。このメッセージには、次の内容が含まれています。

- 使用するアルゴリズム。これは、クライアントが送信した一覧から、サーバーによって選択されます。

- 鍵の生成に使用する乱数。

3. サーバーは、クライアントに証明書を送信します。

4. クライアントは、サーバーの証明書の妥当性、発行者CAおよびオプションでサーバーのホスト名がサブジェクトDNと一致するかどうかをチェックして、サーバーを認証します。クライアントはセッション・キャッシュのセッションIDを送信します。

5. クライアントが乱数(プリマスタ・シークレット)を生成し、サーバーの公開鍵を使用して暗号化し、サーバーに送信します。

6. サーバーは、秘密鍵を使用してメッセージを復号化し、プリマスタ・シークレットを取得します。

7. クライアントとサーバーは、SSLセッションで使用される鍵を個別に計算します。
これらの鍵は、互いに認識しているプリマスタ・シークレットと乱数に基づいて計算されるため、それぞれの相手には送信されません。鍵には次の内容が含まれています。

- クライアントがサーバーへの送信前にデータを暗号化するために使用する暗号化鍵

- サーバーがクライアントへの送信前にデータを暗号化するために使用する暗号化鍵

- クライアントがデータのメッセージ・ダイジェストを作成するために使用する鍵

- サーバーがデータのメッセージ・ダイジェストを作成するために使用する鍵

暗号化鍵は、対称的です。つまり、データの暗号化と復号化には同じ鍵が使用されます。

8. クライアントとサーバーは、相互にFinishedメッセージを送信します。これらは前の手順で生成した鍵を使用して送信される最初のメッセージ(最初の安全なメッセージ)です。
Finishedメッセージには、各当事者が送信した以前のハンドシェイク・メッセージがすべて含まれています。各当事者は、受信した以前のメッセージが、Finishedメッセージに含まれているメッセージに一致するかどうかを確認します。これは、ハンドシェイク・メッセージが改ざんされていないことを確認するためです。

9. クライアントとサーバーは、暗号化鍵とハッシュ鍵およびアルゴリズムを使用してデータを転送します。

図6-1 SSLハンドシェイク

6.2 Oracle Fusion MiddlewareにおけるSSLについて

この項では、Oracle Fusion MiddlewareにおけるSSLについて説明します。内容は次のとおりです。

- Oracle Fusion MiddlewareアーキテクチャにおけるSSL

- キーストアおよびOracleウォレット

- Oracle Fusion MiddlewareでのTLSプロトコルのサポート

- Oracle Fusion Middlewareでの認証モード

- SSL構成用ツール

6.2.1 Oracle Fusion MiddlewareアーキテクチャにおけるSSL

図6-2 Oracle Fusion MiddlewareにおけるSSL

注意:

- 図6-2の「Oracle Enterprise Manager」は、Fusion Middleware Controlのユーザー・インタフェースを指します。

- その他の管理ツールは、特定のタスクで使用できます。

図6-2で示されるOracle Fusion Middlewareアーキテクチャにおいて、丸はSSLを有効にできるエンドポイントを表します。それぞれのエンドポイントの構成の詳細は、次の項目を参照してください。

1. 第6.4.2.1項「Fusion Middleware Controlを使用したOracle HTTP Server仮想ホストへのインバウンド・リクエストでのSSLの有効化」および第6.4.2.2項「WLSTを使用したOracle HTTP Server仮想ホストへのインバウンド・リクエストでのSSLの有効化」

2. 第6.4.2.3項「Oracle HTTP Serverからのアウトバウンド・リクエストでのSSLの有効化」

3. 第6.5.1.1項「Oracle WebLogic ServerへのインバウンドSSLの構成」

4. LDAPサーバーへのアウトバウンド接続は、Oracle Platform Security ServicesまたはOracle WebLogic Serverから発生します。

1. 第6.5.1.2.1項「Oracle Platform Security ServicesからLDAPへのアウトバウンドSSLの構成」

2. 第6.5.1.2.3項「LDAPオーセンティケータからLDAPへのアウトバウンドSSLの構成」

5. 第6.6.1.2項「データソースでのSSLの有効化」

6. 第6.6.1.1項「Oracle DatabaseでのSSLの有効化」

7. 第6.5.2項「アプリケーションのクライアント側のSSL」

8. 第6.5.1.2項「Oracle WebLogic ServerからのアウトバウンドSSLの構成」

9. 第6.6.1.1項「Oracle DatabaseでのSSLの有効化」

キーストアおよびウォレット

キーストアおよびウォレットはSSL構成の中心となり、これらを使用して証明書および鍵を保存します。

詳細は、第6.2.2項「キーストアおよびOracleウォレット」を参照してください。

6.2.2 キーストアおよびOracleウォレット

Oracle Fusion Middleware 12c (12.2.1)では、鍵と証明書のために様々なタイプのキーストアをサポートしています。

- JKSベースのキーストアとトラストストア
Oracle WebLogic Serverは、アップグレードした環境でJKSキーストアを使用します。

JDKのkeytoolユーティリティでJKSキーストアおよび証明書を管理します。

- Oracleウォレット
Oracle HTTP Serverなどのシステム・コンポーネントではOracleウォレットを使用します。

システム・コンポーネントのウォレットとその証明書を管理するには、Fusion Middleware Controlまたはコマンド行WLSTとorapkiインタフェースを使用します。Fusion Middleware ControlまたはWLSTのいずれかを使用して、これらのコンポーネントのリスナーでSSLを有効化できます。

- OPSSキーストア・サービス(KSS)のキーストアおよびトラストストア
キーストア・サービスでは、鍵と証明書を管理するために、かわりのメカニズムが用意されています。12c (12.2.1)を新しくインストールした場合、Oracle WebLogic Serverは最初からKSSキーストアを使用します。

KSSキーストアおよびその証明書を管理するには、Fusion Middleware ControlまたはWLSTを使用します。WebLogicサーバーのリスナーでSSLを有効化するには、WebLogicコンソールを使用します。

これらのストアのタイプ、およびどのストアのタイプをいつ使用するかについては、第6.1.3項「キーストアおよびウォレット」を参照してください。

関連項目:
キーストアの管理は、第7.1項「Oracle Fusion Middlewareにおける鍵と証明書の格納」を参照してください。

JDK7ではkeyCertSignを持つkeyUsageが必要

JDK7では、SSL構成で使用する自己署名付きCA証明書に、keyCertSignがアサートされたkeyUsage拡張機能が存在している必要があります。詳細は、第H.3.3項を参照してください。

6.2.3 Oracle Fusion MiddlewareでのTLSプロトコルのサポート

Oracle Fusion Middlewareは、TLS v1.2暗号ライブラリをサポートしています。ただし、ライブラリはデフォルトでは有効でない可能性があるため、コンポーネント内でこのプロトコルを構成する必要があります。表は、関連する手順へのリンクを示しています。

表6-1 Oracle Fusion MiddlewareコンポーネントでのTLS v1.2のサポート

コンポーネント/機能

TLSのドキュメント

Oracle HTTP Server

『Oracle HTTP Server管理者ガイド』のSSLProtocolに関する項

Oracle WebLogic Server

『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のSSLプロトコルのバージョンの指定に関する項

Oracle Traffic Director

『Oracle Traffic Directorの管理』のセキュリティの管理に関する項

『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』のSSL管理に関する項

6.2.4 Oracle Fusion Middlewareでの認証モード

サポートされている認証モードは、次のとおりです。

- 認証なしモードでは、サーバーもクライアントも認証は不要です。
このモードは、匿名SSL/認証なし/Diffie-Hellmanなどと呼ばれています。このモードはセキュアではないと見なされます。

- サーバー認証モードでは、クライアントに対してサーバー自身の認証が行われます。
このモードは、一方向SSL/サーバー認証とも呼ばれています。

- 相互認証モードでは、サーバーに対してクライアント自身の認証が行われ、クライアントに対してサーバー自身の認証が行われます。
このモードは、双方向SSL/クライアント認証とも呼ばれています。

- オプションのクライアント認証モードでは、クライアントに対してサーバー自身の認証が行われますが、サーバーに対してはクライアント自身の認証を行うことも行わないこともできます。クライアント自身の認証を行わなくても、SSLセッションは機能します。

6.2.5 SSL構成用ツール

Oracle Fusion Middlewareでは、一般的なツールと拡張ツールの2種類の構成ツールを使用します。

一般的なツール

- Fusion Middleware Control

- WLSTコマンド行インタフェース

- Oracle WebLogic Server管理コンソール

- keytoolコマンドライン・ツール

これらのツールを使用して、Oracle Fusion Middlewareの任意のリスナーまたはコンポーネントでSSLを構成したり、Oracle WalletやJKSキーストアを管理できます。

このリストの最初の3つのツールは、コンポーネントがアプリケーション・サーバー・ドメインに関連付けられている場合(コンポーネントがスタンドアロン・インストールではない場合)に使用できます。

拡張ツール

orapkiコマンド行ツールは、特定のスタンドアロン・インストールでウォレットを管理するために必要です。

関連項目:
キーストアの管理は、第7.1項「Oracle Fusion Middlewareにおける鍵と証明書の格納」を参照してください。

6.3 構成ツールでのSSLの構成

Oracle Fusion Middleware構成ではいくつかのツールを使用できます。この項では、これらのツールでSSLを構成して、それをSSLが有効なOracle WebLogic Serverに接続できるようにする方法について説明します。

関連項目:
Oracle WebLogic ServerでのインバウンドSSLの有効化の詳細は、第6.5.1.1項を参照してください。

すべての構成ツールの一覧は、第6.2.5項「SSL構成用ツール」を参照してください。

この項の項目は次のとおりです。

- Oracle Enterprise Manager Fusion Middleware Control

- Oracle WebLogic Server管理コンソール

- WLSTコマンド行ツール

6.3.1 Oracle Enterprise Manager Fusion Middleware Control

次の手順に従います。

- Fusion Middleware ControlがデプロイされているOracle WebLogic ServerインスタンスでSSLポートが有効なことを確認し、(Fusion Middleware Controlを起動する)ブラウザがサーバー証明書を信頼していることを確認します。
詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』を参照してください。

- ここで、「https://host:port」形式でSSLベースのURLを使用してFusion Middleware Controlを起動します。

6.3.2 Oracle WebLogic Server管理コンソール

Oracle WebLogic ServerインスタンスでSSLポートが有効なことを確認します。ここで、URLにSSLポートを指定して管理コンソールを起動します。証明書が信頼できないという警告が表示される場合がありますが、この証明書を受け入れて続行します。

詳細は、『Fusion Middleware ControlによるOracle WebLogic Serverの管理』を参照してください。

6.3.3 WLSTコマンド行ツール

WLSTでのSSLの構成の詳細は、次の手順を実行します。

1. WLSTシェルを起動します。

2. WLSTコマンドを実行します。

help('connect')

ヘルプ・テキストの説明にある手順に従って、SSLモードでWLSTシェルを設定します。

関連項目:
WLSTの使用の詳細は、第6.9項を参照してください。

6.4 Web層でのSSLの構成

この項では、Web層に存在するOracle HTTP Server用のSSLについて説明しますが、各項目は次のとおりです。

- ロード・バランサの構成

- Oracle HTTP Server仮想ホストでのSSLの有効化

注意:

- この項の内容は、Oracle WebLogic Serverドメインに関連したWeb層に適用されます。

- これらの項目の表示順は、SSLが有効化される順序ではありません(この順序はトポロジによって異なります)。これらの項目は、フロントエンドのコンポーネントから開始するように配置されています。

この章は、すべてのOracle HTTP Server構成オプションについて説明しているわけではありません。追加のシナリオについては、『Oracle HTTP Serverのインストールと構成』を参照してください。

6.4.1 ロード・バランサの構成

ロード・バランシング・デバイスに固有の手順を使用して、Oracle Fusion Middleware環境のロード・バランサを構成します。

6.4.2 Oracle HTTP Server仮想ホストでのSSLの有効化

この項では、Oracle WebLogic Server環境で動作しているOracle HTTP Server仮想ホストのSSL構成の管理方法について説明します。

注意:
スタンドアロン・モードのOracle HTTP Serverの詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。

インバウンド・トラフィックの場合は、次を参照してください。

- 第6.4.2.1項 (Fusion Middleware Controlを使用)

- 第6.4.2.2項(WLSTを使用)

アウトバウンド・トラフィックの場合は、次を参照してください。

- 第6.4.2.3項(Fusion Middleware ControlまたはWLSTを使用)

6.4.2.1 Fusion Middleware Controlを使用したOracle HTTP Server仮想ホストへのインバウンド・リクエストでのSSLの有効化

次の手順を実行して、Oracle HTTP Server仮想ホストへのインバウンド・トラフィックでSSLを有効にすることができます。

1. 左側のナビゲーション・ペインでOracle HTTP Serverインスタンスを選択します。

2. 必要に応じて、「Oracle HTTP Server」→「セキュリティ」→「ウォレット」にナビゲートします。
ウォレットの作成とメンテナンスは、第7章「キーストア、ウォレットおよび証明書の管理」を参照してください。

3. 「HTTP Server」→「管理」→「仮想ホスト」にナビゲートします。
このページには、現在構成されているホスト、およびそれらがhttpまたはhttpsに構成されているかが表示されます。

4. 更新する仮想ホストを選択して、「構成」→「SSL構成」をクリックします。(注意: 新規仮想ホストを作成する場合は、『Oracle HTTP Server管理者ガイド』を参照してください。)

「SSL構成」ページが表示されます。

5. 「SSLの有効化」の選択を解除すると、httpsポートをhttpポートに変換できます。
現在httpを使用している仮想ホストでSSLを構成するには:

- 「SSLの有効化」ボックスを選択します。

- ドロップダウン・リストからウォレットを選択します。

- 「サーバーSSLプロパティ」から、SSL認証タイプ、使用する暗号スイートおよびSSLプロトコル・バージョンを選択します。

注意:
ほとんどの状況ではデフォルト値が最適です。

注意:

- ここでは、Fusion Middleware Controlに証明書があることを想定しています。証明書がorapkiで作成された場合は、最初に証明書をインポートします(第7.4.4.5.1項を参照)。

- 選択した認証タイプにより使用可能な暗号スイートが決まり、選択した暗号スイートにより使用可能なプロトコル・バージョンが決まります。暗号およびプロトコルのバージョンの詳細は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のSSL用のプロパティ・ファイルに関する項を参照してください。

6. 「OK」をクリックして変更内容を適用します。

7. Windowsプラットフォームの場合にのみ、Windowsエクスプローラを開いて、cwallet.ssoファイルの場所に移動します。「プロパティ」→「セキュリティ」で、「グループ名またはユーザー名」にSYSTEMを追加します。

8. 「Oracle HTTP Server」→「コントロール」→「再起動」にナビゲートして、Oracle HTTP Serverインスタンスを再起動します。

9. ブラウザ・セッションを開き、SSLを有効にしたポート番号に接続します。

6.4.2.2 WLSTを使用したOracle HTTP Server仮想ホストへのインバウンド・リクエストでのSSLの有効化

第7.2.1項の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。

次の手順に従います。

1. 次のコマンドを実行して、このOracle HTTP Serverインスタンスの仮想ホストを確認します。

listListeners('OHS_instance','OHS_instance' )

このコマンドは、このインスタンスのすべての仮想ホストをリストします。SSLを構成する必要がある仮想ホストを1つ選択します。たとえば、「vhost1」を選択できます。このコマンドの詳細は、『WebLogic Server WLSTコマンド・リファレンス』を参照してください。

2. SSLプロパティで仮想ホストを構成します。

configureSSL('OHS_instance',
'OHS_instance',
'ohs',
'vhost1')

注意:

- configureSSLでは、すべてのSSL属性に対してデフォルト値を使用します(詳細は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のパラメータのデフォルト値に関する項を参照)。

- パラメータとしてプロパティ・ファイルをconfigureSSLに指定することもできます。プロパティ・ファイルの使用方法の例と詳細は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のプロパティ・ファイルのパラメータに関する項およびconfigureSSLに関する項を参照してください。このコマンドの詳細は、同じドキュメントのconfigureSSLに関する説明を参照してください。

3. Windowsプラットフォームの場合にのみ、Windowsエクスプローラを開いて、cwallet.ssoファイルの場所に移動します。「プロパティ」→「セキュリティ」で、「グループ名またはユーザー名」にSYSTEMを追加します。

6.4.2.3 Oracle HTTP Serverからのアウトバウンド・リクエストでのSSLの有効化

mod_wl_ohsを構成してOracle HTTP Serverからのアウトバウンド・リクエストでのSSLを有効化します。

6.4.2.3.1 一方向SSLの有効化

手順は次のとおりです。

1. 証明書を含むOracle WebLogic Serverのカスタム・キーストアを生成します(第6.5.1項を参照してください)。

2. Oracle WebLogic Serverで使用される信頼できるCA証明書を、Oracle HTTP Serverウォレットに信頼できる証明書としてインポートします。このタスクには、WLSTやFusion Middleware Controlなどの使用可能なユーティリティを使用できます。(注意: ここで説明するウォレットは、Oracle HTTP Serverリスニング・ポートがSSL用に使用するウォレットです。Oracle WebLogic Server証明書に署名した信頼性できる(ルート)CA証明書は、このウォレットに格納されている必要があります。信頼性できる証明書のインポートの詳細は、第7.4.7.3.1項を参照してください。)

3. Oracle WebLogic Serverインスタンスを停止し、Oracle HTTP Server構成ファイル(DOMAIN_HOME/config/fmwconfig/components/OHS/instance_name/ssl.conf)を編集して、mod_weblogicの下のSSL構成に次の行を追加します。

WlSSLWallet  "$(DOMAIN_HOME}/config/fmwconfig/components/COMPONENT_TYPE/COMPONENT_NAME/keystores/default"

このdefaultは、ステップ2のOracle HTTP Serverウォレットの名前です。

次にその構成の例を示します。

<IfModule mod_weblogic.c>
WebLogicHost myweblogic.server.com
WebLogicPort 7002
MatchExpression *.jsp
SecureProxy On
WlSSLWallet "$(DOMAIN_HOME}/config/fmwconfig/components/OHS/ohs1/keystores/default"
</IfModule>

ファイルを保存して終了します。

4. Windowsプラットフォームの場合にのみ、Windowsエクスプローラを開いて、cwallet.ssoファイルの場所に移動します。「プロパティ」→「セキュリティ」で、「グループ名またはユーザー名」にSYSTEMを追加します。

5. Oracle HTTP Serverを再起動して変更を有効にします。詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。

6. ステップ1で生成されたカスタム・キーストアを使用するようにOracle WebLogic Serverインスタンスが構成され、別名が証明書の生成に使用される別名値を指していることを確認します。Oracle WebLogic Serverインスタンスを再起動します。詳細は、6.5.1.1項を参照してください。

6.4.2.3.2 双方向SSLの有効化

mod_wl_ohsでは、双方向SSL通信もサポートします。双方向SSLを構成する手順は次のとおりです。

1. 前の一方向SSLのステップ1から4を実行します。

2. Oracle WebLogic Serverのトラストストアtrust.jksを生成します。
(前の手順のステップ1で)一方向SSL用に作成されたキーストアは、信頼できる証明書を保存するために使用できますが、この手順で個別のトラストストアを作成することをお薦めします。

3. Oracle HTTP Serverウォレットからユーザー証明書をエクスポートして、それをステップ2で作成したトラストストアにインポートします。
エクスポートには、WLSTやFusion Middleware Controlなどの使用可能なユーティリティを使用できます。インポートにはkeytoolユーティリティを使用できます。詳細は、7.4.5項を参照してください。

4. Oracle WebLogic Server管理コンソールから、構成するサーバーの「キーストア」タブを選択します。

5. ステップ2で作成したトラストストアのtrust.jksファイルの場所によりカスタム・トラストストアを設定します(完全な名前を使用します)。

6. キーストア・タイプをJKSに設定し、キーストアの作成に使用されるパスフレーズを設定します。

7. 「SSL」タブで、「信頼性のある認証局」が「カスタム信頼キーストアから」に設定されていることを確認します。

8. Oracle WebLogic Serverが双方向SSL用に構成されていることを確認します。詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のSSLの構成に関する項を参照してください。

6.5 中間層でのSSLの構成

中間層では、次のようにSSLを使用します。

- アプリケーション・サーバーでのSSLの有効化

- アプリケーション・サーバー上で稼働するコンポーネントおよびアプリケーションでのSSLの有効化

この項では、中間層でのSSLの構成について説明します。この項の項目は次のとおりです。

- Oracle WebLogic ServerでのSSLの構成

- アプリケーションのクライアント側のSSL

6.5.1 Oracle WebLogic ServerでのSSLの構成

この項では、アプリケーション・サーバーの構成について説明します。

6.5.1.1 Oracle WebLogic ServerへのインバウンドSSLの構成

SSLを実装してOracle WebLogic Serverを保護する方法の詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』の次のトピックを参照してください。

- 「Oracle OPSSキーストア・サービスの構成」

- 「WebLogic ServerでのSSLの構成の概要」

6.5.1.2 Oracle WebLogic ServerからのアウトバウンドSSLの構成

この項では、Oracle WebLogic Serverからのアウトバウンド接続でSSLを有効にする方法について説明します。

- Oracle Platform Security ServicesからLDAPへのアウトバウンドSSLの構成

- Oracle Platform Security ServicesからOracle DatabaseへのアウトバウンドSSLの構成

- LDAPオーセンティケータからLDAPへのアウトバウンドSSLの構成

- データベースへのアウトバウンドSSLの構成

6.5.1.2.1 Oracle Platform Security ServicesからLDAPへのアウトバウンドSSLの構成

この項では、LDAPディレクトリへのポリシー・ストア接続および資格証明ストア接続用にSSLを構成する方法について説明します(サーバー側とクライアント側が必要)。匿名SSLおよび一方向SSLがサポートされています。

この項で参照されるjps-config.xmlの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

匿名SSL(サーバー側)

匿名認証モードでLDAPサーバーを起動します。

このタスクの詳細は、LDAPサーバーのドキュメントを参照してください。

匿名SSL(クライアント側)

jps-config.xmlファイルでは、プロトコルをldapsに設定し、プロパティldap.urlに適切なポートを指定する必要があります。この情報は、ポリシー・ストア、資格証明ストア、キーストア、およびldap.urlを使用するその他のサービスに対して更新する必要があります。

一方向SSL(クライアント側)

クライアント側の構成が次のようになっている必要があります。

1. LDAPの証明書を信頼するには、使用するトラスト・ストアを検索する場所をJVMが認識している必要があります。これを行うには、次のように設定します。

-Djavax.net.ssl.trustStore=path_to_jks_file

このプロパティは、JavaSEプログラム、またはJavaEE環境のサーバー起動プロパティに追加されます。

2. jps-config.xmlファイルでは、プロトコルをldapsに設定し、プロパティldap.urlに適切なポートを指定する必要があります。この情報は、ポリシー・ストア、資格証明ストア、キーストア、およびldap.urlを使用するその他のサービスに対して更新する必要があります。

3. keytoolを使用して、LDAPサーバーの証明書をステップ1で指定したトラスト・ストアにインポートします。

6.5.1.2.2 Oracle Platform Security ServicesからOracle DatabaseへのアウトバウンドSSLの構成

一方向または双方向のSSL接続をデータベース・ベースのOPSSセキュリティ・ストアに設定できます。

データベースのサーバーおよびクライアントの構成の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

6.5.1.2.3 LDAPオーセンティケータからLDAPへのアウトバウンドSSLの構成

LDAPディレクトリへのアウトバウンドSSLの詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のWebLogic ServerでのSSL証明書の検証方法に関する項を参照してください。

6.5.1.2.4 データベースへのアウトバウンドSSLの構成

データベース・リスナー用のSSLの構成の詳細は、Oracle Advanced Security管理者ガイドのSSL認証の構成に関する項(http://docs.oracle.com/cd/E11882_01/network.112/e10746/asossl.htm)を参照してください。

6.5.2 アプリケーションのクライアント側のSSL

SSLを有効にしたアプリケーションの作成方法の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のJavaクライアントでのSSL認証の使用に関する項を参照してください。

ベスト・プラクティスは、第6.8.2項「アプリケーション開発者のベスト・プラクティス」を参照してください。

6.6 データ層でのSSLの構成

この項では、次の項目について説明します。

- データベースでのSSLの構成

6.6.1 データベースでのSSLの構成

この項の項目は次のとおりです。

- Oracle DatabaseでのSSLの有効化

- データ・ソースでのSSLの有効化

6.6.1.1 Oracle DatabaseでのSSLの有効化

次の手順を実行して、OracleデータベースでSSLを有効にします。

1. ルートCAとDBの証明書を作成します。次に例を示します。

注意:
本番で使用する場合、自己署名証明書はお薦めしません。本番ウォレットの取得の詳細は、第7.4.8.3項「自己署名付きウォレットのサード・パーティのウォレットへの変更」を参照してください。

mkdir root
mkdir server

# Create root wallet, add self-signed certificate and export
orapki wallet create -wallet ./root -pwd password
orapki wallet add -wallet ./root -dn CN=root_test,C=US -keysize 2048 -self_signed -validity 3650 -pwd password
orapki wallet display -wallet ./root -pwd password
orapki wallet export -wallet ./root -dn CN=root_test,C=US -cert ./root/b64certificate.txt -pwd password

#Create server wallet, add self-signed certificate and export
orapki wallet create -wallet ./server -pwd password
orapki wallet add -wallet ./server -dn CN=server_test,C=US -keysize 2048 -pwd password
orapki wallet display -wallet ./server -pwd password
orapki wallet export -wallet ./server -dn CN=server_test,C=US -request ./server/creq.txt -pwd password

# Import trusted certificates
orapki cert create -wallet ./root -request ./server/creq.txt -cert ./server/cert.txt -validity 3650 -pwd password
orapki cert display -cert ./server/cert.txt -complete
orapki wallet add -wallet ./server -trusted_cert -cert ./root/b64certificate.txt -pwd password
orapki wallet add -wallet ./server -user_cert -cert ./server/cert.txt -pwd password
orapki wallet create -wallet ./server -auto_login -pwd password}}

2. データベースのlistener.ora、sqlnet.oraおよびtnsnames.oraを更新します。

1. 次の例は、デフォルトのlistener.oraを示します。

SID_LIST_LISTENER =
(SID_LIST =(SID_DESC =(SID_NAME = PLSExtProc)(ORACLE_HOME = /path_to_O_H)(PROGRAM = extproc)))
LISTENER =(DESCRIPTION_LIST =(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
(ADDRESS = (PROTOCOL = TCP)(HOST = mynode.mycorp.com)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCPS)(HOST = mynode.mycorp.com)(PORT = 2490))
))

WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/wallet_location)))

SSL_CLIENT_AUTHENTICATION=FALSE}}

次に、更新されたlistener.oraファイルを示します。このシナリオではクライアント認証なしに指定しています。

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = dbname)
(ORACLE_HOME = /path_to_O_H)
(SID_NAME = sid)
)
)

SSL_CLIENT_AUTHENTICATION = FALSE

WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /wallet_path)
)
)

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mynode.mycorp.com)(PORT = 1521))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCPS)(HOST = mycorp.com)(PORT = 2490))
)
)

SSLポートが追加されています。

2. 同様に、変更されたsqlnet.oraファイルは次のようになります。

NAMES.DIRECTORY_PATH= (TNSNAMES, EZCONNECT)
SQLNET.AUTHENTICATION_SERVICES=(BEQ,TCPS,NTS)
WALLET_LOCATION=(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/directory)))
SSL_CLIENT_AUTHENTICATION=FALSE

3. 変更されたtnsnames.oraファイルは次のようになります。

OID =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mynode.mycorp.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = mynode.mycorp.com)
)
)

SSL =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCPS)(HOST = mynode.mycorp.com)(PORT = 2490))
)
(CONNECT_DATA =
(SERVICE_NAME = mynode.mycorp.com)
or
(SID = mynode.mycorp.com)
)
(SECURITY=(SSL_SERVER_CERT_DN=\"CN=server_test,C=US\"))
)

3. 新しい接続文字列を使用してデータベースへの接続をテストします。次に例を示します。

$ tnsping ssl
$ sqlplus username/password@ssl

関連項目:
『Oracle Database Advanced Security管理者ガイド』のSecure Sockets Layer認証の構成に関する項を参照してください。

6.6.1.2 データ・ソースでのSSLの有効化

次の手順を実行して、SSLを使用するようにOracle WebLogic Server上のデータ・ソースを構成します。

1. トラストストアを作成して、(データベースでSSLを有効にしたときに作成した)ルート証明書を、信頼できる証明書としてトラストストアに追加します。

2. Oracle WebLogic Server管理コンソールで、使用しているデータ・ソースの「接続プール」タブにナビゲートします。

注意:
Oracle WebCenter Portalデータ・ソースなどの既存ソースや新しいデータ・ソースをデータ・ソースにできます。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの作成に関する項を参照してください。

「JDBCプロパティ」テキスト・ボックスで指定する必要があるプロパティは、構成する認証のタイプにより異なります。

- クライアント認証(双方向認証)が必要な場合:

javax.net.ssl.keyStore=..(password of the keystore)
javax.net.ssl.keyStoreType=JKS
javax.net.ssl.keyStorePassword=...(password of the keystore)
javax.net.ssl.trustStore=...(the truststore location on the disk)
javax.net.ssl.trustStoreType=JKS
javax.net.ssl.trustStorePassword=...(password of the truststore)

- クライアント認証が不要な場合:

javax.net.ssl.trustStore=...(the truststore location on the disk)
javax.net.ssl.trustStoreType=JKS
javax.net.ssl.trustStorePassword=...(password of the truststore)

3. 「URL」テキスト・ボックスにJDBC接続文字列を入力します。プロトコルがTCPSで、SSL_SERVER_CERT_DNにデータベース証明書の完全なDNが含まれていることを確認します。
tnsnames.oraが「SERVICE_NAME」を使用する場合は、次の構文を使用します。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCPS)(HOST=host-name)(PORT=port-number)))(CONNECT_DATA=(SERVICE_NAME=service))(SECURITY=(SSL_SERVER_CERT_DN="CN=server_test,C=US")))

tnsnames.oraが「SID」を使用する場合は、次の構文を使用します。

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCPS)(HOST=host-name)(PORT=port-number)))(CONNECT_DATA=(SID=service))(SECURITY=(SSL_SERVER_CERT_DN="CN=server_test,C=US")))

4. 接続をテストおよび検証します。この時点で、データ・ソースはSSLを使用するように構成されています。

6.7 高度なSSLの使用事例

この項では、前述の基本的なトポロジを超えた高度なSSL構成のシナリオを処理する方法について説明します。

- ハードウェア・セキュリティ・モジュールとアクセラレータ

- CRLとSSLとの統合

- Oracle Fusion MiddlewareのFIPS 140-2の設定

この項で使用されているコマンドの詳細および例は、第6.9項を参照してください。

6.7.1 ハードウェア・セキュリティ・モジュールとアクセラレータ

ハードウェア・セキュリティ・モジュール(HSM)は、コンピュータに組み込むことができる物理的なプラグイン・カードまたは外部セキュリティ・デバイスで、セキュアなストレージ環境を提供し機密コンテンツを扱うことができます。

注意:
この項の内容は、HSMをサポートしているシステム・コンポーネントであるOracle HTTP Serverにのみ適用されます。

Oracle Fusion Middlewareでは、PKCS#11規格に準拠したHSMデバイスをサポートし、秘密鍵を使用したセキュアなストレージ環境を提供します。

次の手順を実行し、PKCS#11ウォレットを使用してコンポーネントでSSLを実装します。

1. コンポーネントが稼働しているマシンにHSMライブラリをインストールします。これは、1回かぎりのタスクでデバイスに依存します。

2. 次に、orapkiコマンド行ツールを使用してウォレットを作成します。次の点に注意してください。

1. ウォレット・タイプとしてPKCS11を選択します。

2. デバイスとの通信に使用されるデバイス固有のPKCS#11ライブラリを指定します。このライブラリは、HSMソフトウェアの一部です。
Linuxでは、ライブラリは次の場所にあります。

For LunaSA (Safenet):  /usr/lunasa/lib/libCryptoki2.so
For nCipher:  /opt/nfast/toolkits/pkcs11/libcknfast.so

Windowsでは、ライブラリは次の場所にあります。

For LunaSA (Safenet): C:\Program Files\LunaSA\cryptoki.dll

3. ここで、第三者の証明書を取得するための標準的な手順を実行します。証明書リクエストを作成し、認証局(CA)で承認されたリクエストを取得して、そのCAで署名された証明書をインストールします。
設定したウォレットは、他のウォレットと同様に使用されます。

4. orapkiユーティリティでウォレットを確認します。次のコマンド構文を使用します。

orapki wallet p11_verify [-wallet [wallet]] [-pwd password]

関連項目:
orapkiの詳細は、付録G「orapki」を参照してください。

5. configureSSL WLSTコマンドを使用して、コンポーネントのリスナーでSSLを構成します。このコマンドは入力にプロパティ・ファイルを指定します。プロパティ・ファイルでは、コンポーネントが稼働しているマシンのPKCS#11ウォレット・ディレクトリのフルパスを指定する必要があります。(注意: PKCS#11ウォレットをインスタンス・ホーム・ディレクトリに保存しないでください。Fusion Middleware ControlまたはWLSTを介して作成および管理されるウォレットのみがインスタンス・ホームに存在する必要があります。)
サンプルのプロパティ・ファイルは、次のようになります。

SSLEnabled=true
AuthenticationType=Server
PKCS11Wallet=/tmp/lunasa/wallet

注意:
WLSTコマンドのconfigureSSLを使用して、PKCS11ウォレットを構成する必要があります。Fusion Middleware Controlまたはその他のツールを使用してこのタスクを実行することはできません。

6.7.2 CRLとSSLとの統合

注意:

- この項の内容は、Oracle WebLogic Server環境におけるOracle HTTP Serverにのみ適用されます。スタンドアロン・コンポーネントのSSL構成の詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。

- CRL検証はWLSTを使用して管理します。このタスクはFusion Middleware Controlを使用して実行することができません。

SSLを使用するコンポーネントは、オプションで証明書失効リスト(CRL)を使用した証明書の検証を有効にできます。これによりそのコンポーネントでは、SSLハンドシェイクでピア証明書を検証して、認証局(CA)で発行された失効済証明書のリストにそれがないか確認できます。

この項では、CRLベースの検証を使用するようにコンポーネントを構成する方法、およびファイル・システム上にCRLを作成および設定する方法を説明します。

6.7.2.1 コンポーネントのCRL検証の構成

configureSSL WLSTコマンドを使用して、コンポーネントのリスナーでSSLを構成します。このコマンドは入力にプロパティ・ファイルを指定します。

プロパティ・ファイルは、次のように設定する必要があります。

1. 「CertValidation」属性はurlに設定する必要があります。

2. 「CertValidationPath」属性は、「file://file_path」または「dir://directory_path」という形式にする必要があります。

- 証明書の検証に単一のCRLファイルを使用している場合、最初の形式を使用します。このCRLファイルは、すべてのCRLファイルを結合する必要があります。

- 複数のCRLファイルがハッシュ形式で格納されているディレクトリ・パスを指定する場合、2番目の形式を使用します。
ハッシュ形式でCRLを作成する方法の詳細は、第6.7.2.2項「ファイル・システムでのCRLの管理」を参照してください。

次の例では、プロパティ・ファイルは単一のCRLファイルを指定します。

SSLEnabled=true
AuthenticationType=Server
CertValidation=crl
KeyStore=ohs1
CertValidationPath=file:///tmp/file.crl

次の例では、プロパティ・ファイルは複数のCRLファイルへのディレクトリ・パスを指定しています。

SSLEnabled=true
AuthenticationType=Server
KeyStore=ohs1
CertValidation=crl
CertValidationPath=dir:///tmp

6.7.2.2 ファイル・システムでのCRLの管理

注意:
LDAPベースのCRLまたはCRL配布ポイントはサポートされません。

orapkiコマンド行ツールを使用して、ファイル・システム上でCRLを管理します。このトピックの詳細は、第G.1.5項「orapkiユーティリティを使用した証明書失効リスト(CRL)の管理」を参照してください。

ハッシュ形式へのCRLの名前変更

CRL格納場所を指定する場合は、CRLの名前を変更する必要があります。これにより、実行時に効率的にCRLをロードできます。この操作では、実際のCRLファイルへのシンボリック・リンクを作成します。Windowsでは、新しい名前を付けたファイルにCRLをコピーします。

CRLの名前を変更するには:

orapki crl hash
[-crl [url|filename]] [-wallet wallet] [-symlink directory]
[-copy directory] [-summary] [-pwd password]

次に例を示します。

orapki crl hash -crl nzcrl.txt -symlink wltdir -pwd password

CRLファイル名を実行時に指定すると、複数のCRLをそのファイルに結合できます。この例で作成されるCRLはBase64形式なので、テキスト・エディタを使用してCRLを結合できます。

CRLの作成

注意:
CRLの作成および証明書の失効はテスト目的で行い、必ず自己署名証明書とともに使用します。本番で使用する場合、本番の証明書を有名なCAから取得して、CRLをそれらの認証局から取得します。

CRLを作成するには:

orapki crl create
[-crl [url|filename]] [-wallet [cawallet]] [-nextupdate [days]] [-pwd password]

次に例を示します。

orapki crl create
-crl nzcrl.crl -wallet rootwlt -nextupdate 3650 -pwd password

証明書の失効

証明書が失効すると、証明書のシリアル番号がCRLに追加されます。

証明書を失効させるには:

orapki crl revoke
[-crl [url|filename]] [-wallet [cawallet]] [-cert   [revokecert]] [-pwd password]

次に例を示します。

orapki crl revoke
-crl nzcrl.txt -wallet rootwlt -cert cert.txt -pwd password

6.7.2.3 CRL検証が構成されたコンポーネントのテスト

コンポーネントでCRL検証が正しく構成されていることをテストするには、次の手順を実行します。

1. コンポーネントで使用される証明書をウォレットに設定します。

2. この証明書を含むCRLを失効済証明書リストの中に生成します。第6.7.2.2項「ファイル・システムでのCRLの管理」で説明されている手順を実行します。

3. このCRLを使用するようにコンポーネントを構成します。第6.7.2.1項「コンポーネントのCRL検証の構成」で説明されている手順を実行します。

4. この失効済証明書を使用すると、SSLハンドシェイクは失敗します。

6.7.3 Oracle Fusion MiddlewareのFIPS 140-2の設定

Oracle Fusion MiddlewareでのFIPS 140のサポートの詳細は、第8章を参照してください。

6.8 SSLのベスト・プラクティス

この項では、Oracle Fusion Middlewareコンポーネント管理者およびアプリケーション開発者のいくつかのベスト・プラクティスの概要を説明します。内容は次のとおりです。

- 管理者のベスト・プラクティス

- アプリケーション開発者のベスト・プラクティス

6.8.1 管理者のベスト・プラクティス

システム管理者のベスト・プラクティスには、次のようなものがあります。

- 自己署名付きウォレットはテスト環境でのみ使用します。本番環境に移行する前にウォレットにCAで署名された証明書を取得する必要があります。詳細は、第7章「キーストア、ウォレットおよび証明書の管理」を参照してください。

- (少なくともWeb層の)コンポーネントでは、DNとしてシステム・ホスト名あるいは仮想ホストまたはサイト名を持つ証明書を使用することをお薦めします。そうすることにより、混乱させる警告メッセージが表示されることなく、ブラウザはSSLモードで接続できます。

- SSLで使用される証明書では、最小キー・サイズの1024ビットを使用することをお薦めします。キー・サイズを大きくすると、セキュリティは高くなりますが、パフォーマンスが低下します。セキュリティおよびパフォーマンス要件に応じて、適切なキー・サイズ値を選択します。

- SSLハンドシェイクが失敗する主な原因の1つに信頼性が欠落していることがあります。SSLハンドシェイクを開始する前に、(サーバーCA証明書をクライアント・キーストアにインポートして)クライアントがサーバーを信頼していることを確認してください。クライアント認証も必要な場合は、その逆も確認する必要があります。

6.8.2 アプリケーション開発者のベスト・プラクティス

次のプラクティスをお薦めします。

- Javaキーストア(JKS)を使用してJava EEアプリケーションの証明書を保存します。

- キーストア・パス、トラストストア・パス、構成ファイルの認証タイプなどのSSL構成パラメータは、アプリケーション・コードのそれぞれの値に埋め込まず、外部に配置します。そうすることで、アプリケーション自体を変更せずに柔軟にSSL構成を変更できます。

6.9 SSL関連のWLSTリファレンス

Oracleウォレットを管理し、Oracle Fusion Middlewareコンポーネント用のSSLを構成するために、WLSTコマンドが使用できます。

これらのWLSTコマンドの詳細は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』の次の章を参照してください。

- 「SSL構成WLSTコマンド」

- 「ウォレット構成WLSTコマンド」

関連項目:
WLSTシェルを起動してSSL関連コマンドを実行する方法の詳細は、第7.2項「キーストアおよびウォレット用コマンド行インタフェース」を参照してください。その他の場所からはWLSTインタフェースを起動しないでください。

注意:
SSL構成用のすべてのWLSTコマンドは、オンライン・モードで実行する必要があります。

注意:
WLSTを使用する場合、証明書はPEMフォーマットのみでインポートできます。

7 キーストア、ウォレットおよび証明書の管理

この章では、Oracle Fusion Middlewareのセキュリティ機能を使用してキーストア、鍵および証明書を管理する方法について説明します。これらのアーティファクトは、Oracle Fusion MiddlewareコンポーネントのSSLおよび関連タスクを構成するために使用されます。

この章では、次の内容を説明します。

- Oracle Fusion Middlewareでの鍵および証明書の保存

- キーストアおよびウォレット用コマンド行インタフェース

- キーストア管理

- ウォレットの管理

7.1 Oracle Fusion Middlewareでの鍵および証明書の保存

鍵と証明書はデータのデジタル署名および検証に使用され、ネットワーク接続において認証、整合性およびプライバシを実現できます。

秘密鍵、デジタル証明書および信頼できるCA証明書は、キーストアに格納されます。この項では、Oracle Fusion Middlewareで使用可能なキーストアについて説明します。この項の項目は次のとおりです。

- キーストアのタイプ

- キーストア管理ツール

7.1.1 キーストアのタイプ

Oracle Fusion Middlewareでは、鍵と証明書用に様々なタイプのキーストアが用意されています(表7-1を参照)。

表7-1 Oracle Fusion Middlewareのキーストアのタイプ

キーストア・タイプ

説明

保護メカニズム

Oracleウォレット

Oracleウォレット

パスワードまたは自動ログイン

JKS

Javaキーストア

パスワード

KSS

OPSSキーストア・サービス

パスワードまたはポリシー

7.1.1.1 Oracleウォレットについて

Oracleウォレットは、証明書、信頼できる証明書、証明書リクエスト、秘密鍵などの資格証明を格納するコンテナです。Oracle Internet DirectoryなどのLDAPディレクトリやファイル・システムにOracleウォレットを格納できます。Oracleウォレットは、パスワードで保護することも自動ログインにもできます。

ウォレットを作成すると、次のことができます。

- ウォレットに自己署名付き証明書を自動移入できます。このようなウォレットはテスト・ウォレットと呼ばれ、通常、開発またはテスト・フェーズで使用されます。

- 認証局(CA)から署名された証明書を返送してもらえるように、証明書リクエストを生成することができます。CAが証明書を返送すると、その証明書はウォレットにインポートされます。このようなウォレットは、サード・パーティのウォレットと呼ばれます。

テスト・ウォレットまたはサード・パーティのウォレットはパスワードで保護することも、パスワードが不要なように構成することもできます。後者は、自動ログイン・ウォレットと呼ばれています。

OracleウォレットはOracle HTTP Serverで使用されます。Oracle Fusion Middleware 12c (12.1.3)の時点では、キーストア・サービスで使用できる中央記憶域および統合管理を利用して、該当するサービスのエクスポート、インポートおよび同期化機能により、ウォレットとその内容を管理できます。

関連項目:

- キーストア・サービスの詳細は、第7.1.1.3項を参照してください。

- importKeyStore、exportKeyStoreおよびsyncKeyStoreコマンドの詳細は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

7.1.1.2 JKSキーストアについて

JKSキーストアは、JavaキーストアのデフォルトのJDK実装です。Java EEアプリケーションはJKSベースのキーストアおよびトラストストアを使用できます。

7.1.1.3 キーストア・サービス(KSS)キーストアについて

OPSSキーストア・サービスでは、SSL、メッセージ・セキュリティ、暗号化および関連タスク用のキーおよび証明書を管理できます。

キーストア・サービスは、キーストアとトラストストア、期限切れ証明書およびその他の重要な資料に対するポリシー・ベースの保護および集中管理を含む、いくつかの利点を提供します。

Oracle Fusion Middleware 12c (12.2.1)、Oracle WebLogic Serverの場合

- 最初からキーストア・サービスを使用します。

- アップグレードした環境ではデフォルトでJKSを使用します。

7.1.2 キーストア管理ツール

Oracle Fusion Middlewareでは、次のようなキーストア操作のオプションが用意されています。

- WLST: JKSキーストアおよびOracleウォレット用のコマンド行インタフェース

- orapki: ウォレット用のコマンド行ツール

- Fusion Middleware Control: グラフィカル・ユーザー・インタフェース

DERでエンコードされた証明書のインポートについて

DERでエンコードされた証明書または信頼できる証明書をOracleウォレットにインポートするときには、Fusion Middleware ControlもWLSTコマンド行ツールも使用できません。かわりに、orapkiコマンド行ツールを使用してください。

WLSTでもFusion Middleware Controlでも作成されていないキーストアの使用

Oracleウォレットがorapkiなどのツールを使用して作成された場合、使用前にインポートする必要があります。特にOracle HTTP Serverでは、ウォレットがorapkiを使用して作成された場合、これをFusion Middleware Controlで表示または管理するには、最初にFusion Middleware ControlまたはWLST importWalletコマンドを使用してインポートする必要があります。詳細は、第7.4.4.5.1項および第7.4.4.5.2項を参照してください。

ファイル・システムへのキーストアのコピーはサポートされない

ファイル・システム上の任意のディレクトリにキーストアを直接作成、名前変更、またはコピーすることはサポートされていません。使用する既存のキーストアまたはウォレットを、Fusion Middleware ControlまたはWLSTユーティリティを使用してインポートする必要があります。

スタンドアロン環境でのウォレットの管理

スタンドアロンOHSインストールなどのスタンドアロン環境では、データベースによるキーストア管理機能が用意されています。

詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。

自己署名付き証明書に関するJDK7の要件

JDK7では、SSL構成で使用する自己署名付きCA証明書にkeyUsage拡張機能が必要です。詳細は、第H.3.3項を参照してください。

追加情報

これらのツールの詳細は、次の各項を参照してください。

- キーストアおよびウォレット用コマンド行インタフェース

- ウォレットの管理

- 付録G「orapki」

7.2 キーストアおよびウォレット用コマンド行インタフェース

Oracle Fusion Middlewareでは、キーストアおよびOracleウォレットを作成および管理したり、そこに格納されたオブジェクトを操作するWLSTスクリプトのセットが用意されています。

ここでは、次の項目について説明します。

- コマンド行インタフェースの起動方法

7.2.1 コマンド行インタフェースの起動方法

SSL用のWLSTコマンドを実行する場合は、Oracle共通ホームからWLSTスクリプトを起動する必要があります。(詳細は、第7.2.1項を参照してください。)

これにより、WLSTシェルが起動します。ユーザー名、パスワードおよび接続URLを指定して、実行中のOracle WebLogic Serverインスタンスに接続します。接続すると、次の項で説明するようにSSL関連のWLSTコマンドを実行できるようになります。

注意:
SSL関連のすべてのWLSTコマンドでは、前述の場所でのみスクリプトを起動する必要があります。

次に基本的な実行シーケンスを示します。

./wlst.sh
connect('weblogic','weblogic1') --- To connect to WebLogic Admin Server
editCustom()
startEdit()
wlstCommand('param1', 'param2', 'param3', 'param4')
save()
activate()

ここで、wlstCommandは、実際のWLSTコマンドです。たとえば、OHSウォレットを作成するには:

connect('weblogic','weblogic1') --- For connecting to WLS Admin Server
editCustom()
startEdit()
createWallet('ohs1', 'ohs1', 'ohs', 'testwallet')
save()
activate()

このコマンドでは、最初の2つのパラメータはともにコンポーネント・インスタンス名を参照し(それぞれのパラメータがOracleインスタンスおよびコンポーネント・インスタンスを参照する以前のリリースとは異なり、このリリースでは両方のパラメータがコンポーネント・インスタンスを参照します)、3番目のパラメータはコンポーネントで、4番目のパラメータはウォレット名です。

次にcreateWalletの出力例を示します。

wls:/base_domain/serverConfig> editCustom()
Location changed to edit custom tree. This is a writable tree with No root.
For more help, use help('editCustom')

wls:/base_domain/editCustom> startEdit()
Starting an edit session ...
Started edit session, please be sure to save and activate your
changes once you are done.
wls:/base_domain/editCustom> createWallet('ohs1','ohs1','ohs','testwallet','Welcome1')
Wallet created
wls:/base_domain/editCustom> save()
Saving all your changes ...
Saved all your changes successfully.
wls:/base_domain/editCustom> activate()
Activating all your changes, this may take a while ...
The edit lock associated with this edit session is released
once the activation is completed.
Activation completed

7.3 キーストア管理

キーストア・サービス(KSS)のキーストア管理の詳細は、『 Oracle Platform Security Servicesによるアプリケーションの保護』のキーストア・サービスによるキーストアの管理に関する項を参照してください。

7.4 ウォレットの管理

Oracleウォレットには、様々なアプリケーション用の証明書を作成、保持および削除できる全種類の管理機能が用意されています。

この項の内容は次のとおりです。

- ウォレットおよび証明書について

- Fusion Middleware Controlのウォレット管理ページへのアクセス

- ウォレットのライフサイクルの管理

- 一般的なウォレットの操作

- 証明書のライフサイクルの管理

- Fusion Middleware Controlのウォレットの証明書管理ページへのアクセス

- 一般的な証明書の操作

- ウォレットおよび証明書の保守

この説明では、コンポーネントがWebLogicドメインにインストールされていることを前提としています。スタンドアロン・コンテキスト(たとえば、スタンドアロンOracle HTTP Server)でのウォレット構成は、付録Gを参照してください。

7.4.1 ウォレットおよび証明書について

この項の内容は次のとおりです。

- パスワードで保護されたウォレットと自動ログイン・ウォレットについて

- 自己署名付きウォレットとサード・パーティのウォレットについて

- インスタンス間でのウォレットの共有

- ウォレットの命名規則

7.4.1.1 パスワードで保護されたウォレットと自動ログイン・ウォレットについて

作成できるウォレットは次の2種類です。

- 自動ログイン・ウォレット
これは、PKCS#12ウォレットの不明瞭化された形式です。実行時にパスワードを入力せずに、サービスおよびアプリケーションにPKIベースでアクセスできます。ウォレットへの追加、変更、削除の際にも、パスワードは不要です。ファイル・システム権限では、ウォレットの自動ログインに必要なセキュリティが提供されます。

注意:
以前のリリースでは、パスワード付きのウォレットを作成してから自動ログインを有効にして不明瞭化されたウォレットを作成できました。12c (12.2.1)では、自動ログイン・ウォレットはパスワードなしで作成されます。そのようなウォレットを使用する場合、パスワードを指定する必要はありません。
パスワードのない自動ログインのウォレットを使用している場合、ldapbindコマンドで空値のパスワード("")を指定します。

古いタイプのウォレット(リリース10gのウォレットなど)は、引き続き以前と同様に機能します。

- パスワードで保護されたウォレット
名前のとおり、このタイプのウォレットはパスワードで保護されます。ウォレットのコンテンツに対する追加、変更または削除には、パスワードが必要です。

パスワードで保護されたウォレットが作成されるたびに、自動ログイン・ウォレットが自動的に生成されます。ただし、この自動ログイン・ウォレットは、前の項目で説明した、ユーザーが作成した自動ログイン・ウォレットとは異なります。ユーザーが作成したウォレットは構成時にパスワードなしで更新することができますが、自動的に生成される自動ログイン・ウォレットはユーザーが直接更新できない読取り専用のウォレットです。ウォレットは、自動ログイン・ウォレットを再度生成するときに、パスワードで保護されたファイルを使用して(パスワードを入力して)変更する必要があります。

このシステム生成の自動ログイン・ウォレットの目的は、実行時にパスワードなしでサービスおよびアプリケーションにPKIベースのアクセスを提供することですが、構成時にはパスワードが必要です。

7.4.1.2 自己署名付きウォレットとサード・パーティのウォレットについて

自己署名付きウォレットには、発行者がサブジェクトと同じである証明書が格納されます。これらの証明書は、一般的には信頼性がさほど優先されないイントラネット環境内で作成されます。自己署名付きウォレットの発行者はそれぞれ一意であるため、複数のコンポーネントおよびウォレットを含む環境では信頼性管理タスクはn倍に増加します。

Fusion Middleware Controlを使用して作成した場合、自己署名付きウォレットは5年間有効です。

サード・パーティのウォレットには、既知の認証局(CA)によって発行された証明書が含まれています。機能およびセキュリティは自己署名付きウォレットと同じですが、サード・パーティの証明書は、発行者がよく知られており、多くのクライアントから信頼されているので、信頼性が向上します。

自己署名付きウォレットとサード・パーティのウォレットの違い

機能およびセキュリティの観点からは、自己署名証明書はサード・パーティで発行された証明書と同等です。唯一の異なる点は、自己署名証明書は信頼性がないことです。

7.4.1.3 インスタンス間でのウォレットの共有

ウォレットはそれぞれ一意のアイデンティティを示すため、コンポーネント・インスタンス間ではウォレットを共有しないことをお薦めします。

ただし、コンポーネント・インスタンスのクラスタを含む環境は例外です。この場合はウォレットを共有してかまいません。

ウォレットを簡単に共有するための管理ツールまたはインタフェースは用意されていません。ただし、あるインスタンスからウォレットをエクスポートして別のインスタンスにインポートすることはできます。ウォレットのエクスポートおよびインポートの詳細は、第7.4.4項を参照してください。

7.4.1.4 ウォレットの命名規則

Oracleウォレットの場合は、次の命名規則に従います。

- 256文字を超える名前は使用しないでください。

- ウォレット名には、次のいずれの文字も使用しないでください。

| ; , ! @ # $ ( ) < > / \ " ' ` ~ { } [ ] = + & ^ space tab

注意:
オペレーティング・システムでこれらの文字をサポートしていても、このルールは守ってください。

- ウォレット名には、ASCII以外の文字は使用しないでください。

- また、ディレクトリ名およびファイル名に関するオペレーティング・システム固有のルールにも従ってください。

LDAPディレクトリでのデータの処理方法により、ウォレット名では大文字と小文字が区別されません。

そのため、ウォレット名は大文字/小文字を区別せずに使用することをお薦めします(可能であれば、すべて小文字を使用します)。たとえば、UPPERという名前のウォレットを作成した場合、upperという名前のウォレットを別に作成しないでください。作成すると、ウォレットの管理作業時に混乱を引き起こす可能性があります。

7.4.1.5 JDK7でのウォレットの要件

JDK7では、SSL構成で使用する自己署名付きCA証明書にkeyUsage拡張機能が必要です。詳細は、第H.3.3項を参照してください。

7.4.2 Fusion Middleware Controlのウォレット管理ページへのアクセス

Oracleウォレットは、使用先のコンポーネントに関連付けられます。コンポーネント・インスタンスを探す手順は次のとおりです。

1. 管理者の資格証明を使用してFusion Middleware Controlにログインします。

2. 目的のドメインを選択します。

注意:
「設定」を使用すると、作業対象の特定のOracle WebLogic Serverドメインを見つけることができます。

3. ナビゲーション・ペインで、ウォレットを使用するインスタンス(OHSインスタンスなど)を探します。インスタンスをクリックします。
ページの左上の「ファーム」ドロップダウンの横にコンポーネント・タイプが表示されます。

4. コンポーネント・タイプのドロップダウンから選択します(Oracle HTTP Serverなど)。
コンポーネントが起動していない場合、右クリックして「コンポーネント」メニューを開き、「コントロール」→「起動」を押して、コンポーネントを起動します。

5. 「セキュリティ」→「ウォレット」にナビゲートします。

6. 「ウォレット」ページが表示されます。

「ウォレット」ページで、次の処理を実行できます。

- ウォレットの作成

- ウォレットの削除

- ウォレットのインポート

- ウォレットのエクスポート

7.4.3 ウォレットのライフサイクルの管理

Oracleウォレットの一般的なライフサイクル・イベントは、次のとおりです。

- ウォレットが作成されます。ウォレットは直接作成するか、ファイル・システムからウォレット・ファイルをインポートすることによって作成できます。

- 使用可能なウォレットのリストが表示され、特定のウォレットが選択されて更新されます。

- ウォレットが更新または削除されます。パスワードで保護されたウォレットの更新操作では、ウォレット・パスワードを入力する必要があります。

- パスワードで保護されたウォレットでは、ウォレット・パスワードは変更できます。

- ウォレットは削除できます。

- ウォレットはエクスポートおよびインポートできます。

注意:
Oracle Fusion Middleware 12c (12.1.3)の時点では、キーストア・サービスで使用できる中央記憶域および統合コンソールを利用して、該当するサービスのエクスポート、インポートおよび同期化機能により、ウォレットとその内容を管理できます。importKeyStore、exportKeyStoreおよびsyncKeyStoreコマンドの詳細は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

7.4.4 一般的なウォレットの操作

この項では、次のような様々なウォレット管理機能を実行するために必要な手順について説明します。

- ウォレットの作成

- 自己署名付きウォレットの作成

- 自己署名付きウォレットのサード・パーティのウォレットへの変更

- ウォレットのエクスポート

- ウォレットのインポート

- ウォレットの削除

7.4.4.1 ウォレットの作成

この項では、Oracleウォレットの作成方法について説明します。

- Fusion Middleware Controlを使用したウォレットの作成

- WLSTを使用したウォレットの作成

7.4.4.1.1 Fusion Middleware Controlを使用したウォレットの作成

次の手順を実行して、ウォレットを作成します。

1. コンポーネント・インスタンスの「ウォレット」ページにナビゲートします。第7.4.2項「Fusion Middleware Controlのウォレット管理ページへのアクセス」を参照してください。

2. 「作成」をクリックします。

3. 「ウォレットの作成」ページが表示されます。

4. ウォレットの名前を入力します。

5. ウォレットを自動ログイン・ウォレットにするかどうかによって、「自動ログイン」ボックスを選択または選択解除します。デフォルトでは、自動ログイン・ウォレットになります。
詳細は、第7.4.1.1項「パスワードで保護されたウォレットと自動ログイン・ウォレットについて」を参照してください。

注意:
Oracle Internet Directory用に構成されたウォレットは、自動ログインが有効になっている必要があります。

6. 「発行」をクリックします。

7. この時点で、証明書リクエスト(CR)を追加するかどうかを選択する必要があります。ここで追加しなくとも、CRは後でいつでも追加できます。詳細は、第7.4.7.1.1項「Fusion Middleware Controlを使用した証明書リクエストの追加」を参照してください。
この例では、CRを追加します。

注意:
ここに入力する共通名は、クライアントが接続するOracle HTTP Serverのホスト名と一致する必要があります。これにより、第7.4.8.2項で説明されている問題を回避できます。

8. 「終了」をクリックします。

9. CRには、次の2つのオプションがあります。

- Base64でエンコードされた証明書リクエストを、テキスト・ボックスからコピーしてファイルに貼り付けます。

- 「証明書リクエストのエクスポート」ボタンを使用して、ファイルに直接エクスポートします。

10. ウォレットの作成を確認するメッセージが表示されます。

7.4.4.1.2 WLSTを使用したウォレットの作成

第7.2.1項の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。

コンポーネント・インスタンスをohs1とした場合は、次のコマンドを使用してウォレットを作成します。

createWallet('ohs1', 'ohs1', 'ohs', 'ohs2', 'password')

ohs2はこのウォレットの名前で、passwordはこのウォレットのパスワードです。自動ログイン・ウォレットを作成する必要がある場合、パスワードは''と指定する必要があります(引用符の間にテキストは入れません)。

関連項目:
『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のcreateWalletに関する項。

7.4.4.2 自己署名付きウォレットの作成

この項では、自己署名付きウォレットの作成方法について説明します。

- Fusion Middleware Controlを使用した自己署名付きウォレットの作成

- WLSTを使用した自己署名付きウォレットの作成

7.4.4.2.1 Fusion Middleware Controlを使用した自己署名付きウォレットの作成

次の手順を実行して、自己署名付きウォレットを作成します。

関連項目:
第7.4.1.2項「自己署名付きウォレットとサード・パーティのウォレットについて」

1. コンポーネント・インスタンスの「ウォレット」ページにナビゲートします。第7.4.2項「Fusion Middleware Controlのウォレット管理ページへのアクセス」を参照してください。

2. 「自己署名付きウォレットの作成」をクリックします。

3. 「自己署名付きウォレットの作成」ページで、次のデータを入力してウォレットを作成します。次のものが含まれます。

- ウォレット名

- 自動ログイン・ウォレットかどうか

関連項目:
第7.4.1.1項「パスワードで保護されたウォレットと自動ログイン・ウォレットについて」。

- DN情報

- キー・サイズ

4. 「発行」をクリックします。

5. 確認メッセージが表示され、新しいウォレットがウォレットのリストに表示されます。

注意:
Oracle Internet Directory用に構成されたウォレットは、自動ログインが有効になっている必要があります。

7.4.4.2.2 WLSTを使用した自己署名付きウォレットの作成

第7.2.1項の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。

コンポーネント・インスタンスをohs1とした場合は、次のコマンドを使用して自己署名付きウォレットを作成します。

createWallet('ohs1', 'ohs1', 'ohs', 'ohs2', 'password')
addSelfSignedCertificate('ohs1', 'ohs1', 'ohs', 'ohs2', 'password', 'subject_dn', 'key_size')

ohs2はウォレット名、subject_dnは自己署名証明書の識別名、key_sizeはキー・サイズ(ビット単位)、passwordはこのウォレットのパスワードです。自動ログイン・ウォレットを作成する必要がある場合、パスワードは''と指定する必要があります(引用符の間にテキストは入れません)。

関連項目:

- 『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のcreateWalletに関する項。

- 『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のaddSelfSignedCertificateに関する項。

注意:
Oracle Internet Directory用に構成されたウォレットは、自動ログインが有効になっている必要があります。

7.4.4.3 自己署名付きウォレットのサード・パーティのウォレットへの変更

自己署名付きウォレットをサード・パーティのウォレットに変換する手順は、第7.4.8.3項「自己署名付きウォレットのサード・パーティのウォレットへの変更」を参照してください。

7.4.4.4 ウォレットのエクスポート

この項では、ウォレットのエクスポート方法について説明します。

- Fusion Middleware Controlを使用したウォレットのエクスポート

- WLSTを使用したウォレットのエクスポート

7.4.4.4.1 Fusion Middleware Controlを使用したウォレットのエクスポート

次の手順を実行して、ウォレットをエクスポートします。

1. コンポーネント・インスタンスの「ウォレット」ページにナビゲートします。第7.4.2項「Fusion Middleware Controlのウォレット管理ページへのアクセス」を参照してください。

2. 目的のウォレットに対応する行を選択します。

注意:
ウォレットの名前自体をクリックしないでください。名前をクリックすると、証明書管理操作用のウォレットが開きます。

3. 「エクスポート」をクリックします。

4. 「ウォレットのエクスポート」ページが表示されます。

5. ファイル名とウォレットのエクスポート先を入力します。

6. 「OK」をクリックします。

7.4.4.4.2 WLSTを使用したウォレットのエクスポート

第7.2.1項の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。

コンポーネント・インスタンスをohs1とした場合は、次のコマンドを使用してウォレットをエクスポートします。

exportWallet('ohs1', 'ohs1', 'ohs', 'selfsigned', 'password', '/tmp')

passwordはこのウォレットのパスワードです(自動ログイン・ウォレットの場合、パスワードは''と指定する必要があります)。

自動ログイン・ウォレットの場合、このコマンドにより、ウォレットはディレクトリ/tmpの下のcwallet.ssoという名前のファイルにエクスポートされます。パスワードで保護されたウォレットの場合、/tmpの下にewallet.p12とcwallet.ssoという2つのファイルが作成されます。

関連項目:
『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportWalletに関する項。

7.4.4.5 ウォレットのインポート

この項では、ウォレットのインポート方法について説明します。

- Fusion Middleware Controlを使用したウォレットのインポート

- WLSTを使用したウォレットのインポート

7.4.4.5.1 Fusion Middleware Controlを使用したウォレットのインポート

次の手順を実行して、ウォレットをインポートします。

1. コンポーネント・インスタンスの「ウォレット」ページにナビゲートします。第7.4.2項「Fusion Middleware Controlのウォレット管理ページへのアクセス」を参照してください。

2. 「インポート」をクリックします。

3. 「ウォレットのインポート」ページが表示されます。

4. これが自動ログイン・ウォレットの場合は、ボックスを選択してウォレット名を入力します。パスワードは不要です。

5. これが自動ログイン・ウォレットでない場合は、自動ログイン・ボックスを選択解除します。ウォレット名とパスワードを指定します。

6. 「OK」をクリックします。ウォレットがリポジトリにインポートされます。

7.4.4.5.2 WLSTを使用したウォレットのインポート

第7.2.1項の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。

コンポーネント・インスタンスをohs1とした場合は、次のコマンドを使用してウォレットをインポートします。

importWallet('ohs1', 'ohs1', 'ohs', 'ohs5', 'password', '/tmp/ewallet.p12')

ここで、ohs5はウォレット名、passwordはインポートされるウォレットのパスワードで、/tmp/ewallet.p12にはウォレット・ファイルが含まれています(ewallet.p12とcwallet.ssoという2つのウォレット・ファイルがある場合は、ewallet.p12を指します)。cwallet.ssoを指すのは、自動ログイン・ウォレットの場合のみです。またこの場合、パスワードは''と指定する必要があります。

関連項目:
『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のimportWalletに関する項。

7.4.4.6 ウォレットの削除

この項では、ウォレットの削除方法について説明します。

- Fusion Middleware Controlを使用したウォレットの削除

- WLSTを使用したウォレットの削除

7.4.4.6.1 Fusion Middleware Controlを使用したウォレットの削除

次の手順を実行して、ウォレットを削除します。

1. コンポーネント・インスタンスの「ウォレット」ページにナビゲートします。第7.4.2項「Fusion Middleware Controlのウォレット管理ページへのアクセス」を参照してください。

2. 目的のウォレットに対応する行を選択します。

3. 「削除」をクリックします。

4. このウォレットは削除され、ウォレットのリストに表示されなくなります。

7.4.4.6.2 WLSTを使用したウォレットの削除

第7.2.1項の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。

コンポーネント・インスタンスをohs1とした場合は、次のコマンドを使用してウォレットを削除します。

deleteWallet('ohs1', 'ohs1', 'ohs', 'selfsigned')

関連項目:
『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のdeleteWalletに関する項。

7.4.5 証明書のライフサイクルの管理

完全な証明書のライフサイクルは、ウォレットの作成から始まり、次のような処理が含まれます。

1. 空のウォレット(証明書リクエストが格納されていないウォレット)を作成します。

2. 証明書リクエストをウォレットに追加します。

3. 証明書リクエストをエクスポートします。

4. 証明書リクエストを使用して、対応する証明書を取得します。

5. 信頼できる証明書をインポートします。

6. 証明書をインポートします。

これらの手順は、サード・パーティの信頼できる証明書を含むウォレットの生成に必要です。このタスクの詳細は、第7.4.7.5.1項「Fusion Middleware Controlを使用したサード・パーティ証明書への自己署名証明書の変換」を参照してください。

関連項目:
第7.4.6項「Fusion Middleware Controlのウォレットの証明書管理ページへのアクセス」

7.4.6 Fusion Middleware Controlのウォレットの証明書管理ページへのアクセス

Oracleウォレットは、使用先のコンポーネントに関連付けられます。

コンポーネント・インスタンスを探す手順は次のとおりです。

1. 管理者の資格証明を使用してFusion Middleware Controlにログインします。

2. 目的のドメインを選択します。

注意:
「設定」を使用して、利用する特定のOracle WebLogic Serverドメインを見つけることができます。

3. ナビゲーション・ペインを使用して、ウォレットを使用するインスタンス(Oracle HTTP Serverインスタンスなど)を探します。注意: 後続の手順が機能するように、Oracle HTTP Serverが実行中である必要があります。

コンポーネント・インスタンスを見つけた後、Fusion Middleware Controlのウォレットの証明書管理ページにアクセスするには、次の2つの方法があります。

- 「ウォレット」ページに移動し、目的のウォレットの行を選択して、「管理」をクリックします。

- 「ウォレット」ページに移動し、目的のウォレットを見つけて、ウォレット名をクリックします。

証明書管理ページでは、次の処理を実行できます。

- 証明書リクエストの追加

- 証明書リクエスト、証明書または信頼できる証明書のエクスポート

- 証明書または信頼できる証明書のインポート

- 証明書リクエスト、証明書または信頼できる証明書の削除

7.4.7 一般的な証明書の操作

この項では、次のような一般的な証明書の操作について説明します。

- 証明書リクエストの追加

- 証明書、証明書リクエストまたは信頼できる証明書のエクスポート

- 証明書または信頼できる証明書のインポート

- 証明書リクエスト、証明書または信頼できる証明書の削除

- 自己署名付き証明書のサード・パーティ証明書への変換

7.4.7.1 証明書リクエストの追加

この項では、証明書リクエストのウォレットへの追加方法について説明します。

- Fusion Middleware Controlを使用した証明書リクエストの追加

- WLSTを使用した証明書リクエストの追加

7.4.7.1.1 Fusion Middleware Controlを使用した証明書リクエストの追加

ウォレットを作成するときに証明書リクエストを追加できますが、そのときに追加していない場合は、次の手順を使用して追加できます。

1. 証明書管理ページにナビゲートします。第7.4.6項「Fusion Middleware Controlのウォレットの証明書管理ページへのアクセス」を参照してください。

2. 「証明書リクエストの追加」をクリックします。

3. CRのDN値を入力するダイアログ・ボックスが表示されます。

アスタリスク(*)のマークが付いたフィールドは必須です。注意: 共通名は、クライアントがコンポーネントへのアクセスに使用するホスト名である必要があります。

4. 「OK」をクリックします。

5. 新しいCRが生成されて、ダイアログ・ボックスが開き、テキスト・ボックスにそのCRが表示されます。次のいずれかを実行できます。

- Base64でエンコードされた証明書リクエストをコピーしてファイルに貼り付けます。

- 「証明書リクエストのエクスポート」ボタンを使用して、ファイルに直接エクスポートします。

7.4.7.1.2 WLSTを使用した証明書リクエストの追加

第7.2.1項の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。

コンポーネント・インスタンスをohs1とした場合は、次のコマンドを使用してウォレットに証明書リクエストを追加します。

addCertificateRequest('ohs1', 'ohs1', 'ohs', 'selfsigned', 'password', 'subject_dn', 'key_size')

passwordはこのウォレットのパスワード、subject_dnは証明書リクエストを生成する際に使用される識別名、key_sizeはキー・サイズ(ビット単位)です。

関連項目:
『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のaddCertificateRequestに関する項。

7.4.7.2 証明書、証明書リクエストまたは信頼できる証明書のエクスポート

この項では、証明書、証明書リクエストまたは信頼できる証明書のエクスポート方法について説明します。

- Fusion Middleware Controlを使用した証明書、証明書リクエストまたは信頼できる証明書のエクスポート

- WLSTを使用した証明書、証明書リクエストまたは信頼できる証明書のエクスポート

7.4.7.2.1 Fusion Middleware Controlを使用した証明書、証明書リクエストまたは信頼できる証明書のエクスポート

次の手順を実行して、証明書、証明書リクエスト(CR)または信頼できる証明書をエクスポートします。

1. 証明書管理ページにナビゲートします。第7.4.6項「Fusion Middleware Controlのウォレットの証明書管理ページへのアクセス」を参照してください。

2. 証明書、CRまたは信頼できる証明書を選択して、「エクスポート」をクリックします。

3. ダイアログ・ボックスが開き、証明書、CRまたは信頼できる証明書がテキスト・ボックスに表示されます。次のいずれかを実行できます。

- Base64でエンコードされた証明書をコピーしてファイルに貼り付けます。

- 「証明書のエクスポート」または「信頼できる証明書のエクスポート」ボタンを使用して、ファイルに直接エクスポートします。

7.4.7.2.2 WLSTを使用した証明書、証明書リクエストまたは信頼できる証明書のエクスポート

第7.2.1項の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。

コンポーネント・インスタンスをohs1とした場合は、次のコマンドを使用して証明書リクエストをエクスポートします。

exportWalletObject('ohs1', 'ohs1', 'ohs', 'selfsigned', 'password', 'CertificateRequest', '/tmp', 'subject_dn')

passwordはこのウォレットのパスワード、/tmpはBASE64形式で証明書リクエストがエクスポートされるファイルbase64.txtを含むディレクトリのパス、subject_dnはエクスポートされる証明書リクエストの識別名です。

証明書または信頼できる証明書をエクスポートするには、前述のコマンドの中のCertificateRequestをCertificateまたはTrustedCertificateに置き換えます。

関連項目:
『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportWalletObjectに関する項。

7.4.7.3 証明書または信頼できる証明書のインポート

この項では、証明書または信頼できる証明書のインポート方法について説明します。

- Fusion Middleware Controlを使用した証明書または信頼できる証明書のインポート

- WLSTを使用した証明書または信頼できる証明書のインポート

7.4.7.3.1 Fusion Middleware Controlを使用した証明書または信頼できる証明書のインポート

注意:
DERでエンコードされた証明書または信頼できる証明書をOracleウォレットにインポートするには、Fusion Middleware Controlは使用できません。かわりに、orapkiコマンド行ツールを使用してください。

次の手順を実行して、証明書または信頼できる証明書をインポートします。

1. 証明書管理ページにナビゲートします。第7.4.6項「Fusion Middleware Controlのウォレットの証明書管理ページへのアクセス」を参照してください。

2. 「インポート」をクリックします。

3. 「証明書のインポート」ダイアログで、証明書または信頼できる証明書のいずれかを選択できます。

4. インポートには、次の2つの方法があります。

- Base64でエンコードされた証明書または信頼できる証明書をテキスト・ボックスに貼り付けます。

- ファイル・セレクタを使用してファイル・システムを参照し、Base64でエンコードされた証明書または信頼できる証明書を含むファイルを見つけます。

5. 「OK」をクリックします。

7.4.7.3.2 WLSTを使用した証明書または信頼できる証明書のインポート

注意:
DERでエンコードされた証明書または信頼できる証明書をOracleウォレットにインポートするには、WLSTコマンド行ツールは使用できません。かわりに、orapkiコマンド行ツールを使用してください。

第7.2.1項の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。

コンポーネント・インスタンスをohs1とした場合は、次のコマンドを使用してウォレットに証明書をインポートします。

importWalletObject('ohs1', 'ohs1', 'ohs', 'selfsigned', 'password', 'Certificate', '/tmp/cert.txt')

passwordはこのウォレットのパスワードで、/tmp/cert.txtはBASE64でエンコードされた証明書を含むファイルです。

信頼できる証明書をインポートするには、前述のコマンドの中のCertificateをTrustedCertificateに置き換えます。

関連項目:
『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のimportWalletObjectに関する項。

7.4.7.4 証明書リクエスト、証明書または信頼できる証明書の削除

この項では、証明書リクエスト、証明書または信頼できる証明書の削除方法について説明します。

- Fusion Middleware Controlを使用した証明書リクエスト、証明書または信頼できる証明書の削除

- WLSTを使用した証明書リクエスト、証明書または信頼できる証明書の削除

7.4.7.4.1 Fusion Middleware Controlを使用した証明書リクエスト、証明書または信頼できる証明書の削除

次の手順を実行して、CR、証明書または信頼できる証明書を削除します。

1. 証明書管理ページにナビゲートします。第7.4.6項「Fusion Middleware Controlのウォレットの証明書管理ページへのアクセス」を参照してください。

2. 証明書リクエスト、証明書または信頼できる証明書を含む行を選択します。

3. 「削除」をクリックします。

4. 確認を求めるダイアログ・ボックスが表示されます。

5. 「はい」をクリックします。

6. そのオブジェクトは「証明書の管理」リストに表示されなくなります。

7.4.7.4.2 WLSTを使用した証明書リクエスト、証明書または信頼できる証明書の削除

第7.2.1項の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。

コンポーネント・インスタンスをohs1とした場合は、次のコマンドを使用して証明書を削除します。

removeWalletObject('ohs1', 'ohs1', 'ohs', 'selfsigned', 'password', 'Certificate', 'subject_dn')

passwordはこのウォレットのパスワードで、subject_dnは削除する証明書の識別名です。

証明書リクエストまたは信頼できる証明書を削除するには、前述のコマンドの中のCertificateをCertificateRequestまたはTrustedCertificateに置き換えます。

関連項目:
『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のremoveWalletObjectに関する項。

7.4.7.5 自己署名付き証明書のサード・パーティ証明書への変換

この項では、自己署名付き証明書のサード・パーティ証明書への変換方法について説明します。

- Fusion Middleware Controlを使用したサード・パーティ証明書への自己署名証明書の変換

- WLSTを使用したサード・パーティ証明書への自己署名証明書の変換

7.4.7.5.1 Fusion Middleware Controlを使用したサード・パーティ証明書への自己署名証明書の変換

ウォレットに存在する自己署名証明書は、認証局(CA)で署名されたサード・パーティ証明書に変換できます。次の手順を実行して、このタスクを実行します。

注意:
この手順はOracle Internet Directoryで使用するものですが、Oracle HTTP Serverで使用するウォレットの生成にも同様の手順を適用できます。

1. ナビゲーション・ペインからコンポーネント・インスタンスを見つけます。

2. 「component_name」→「セキュリティ」→「ウォレット」にナビゲートします。

3. ウォレットのリストから自己署名証明書が格納されているウォレットを選択します。

4. 「証明書の管理」ページが表示されます。ウォレット内の証明書の一覧が含まれます。

5. 変換対象の自己署名証明書用に新しい証明書リクエストを生成する必要があります。自己署名証明書を選択して、「証明書リクエストの追加」をクリックします。ダイアログ・ボックスが表示されます。

注意:
ここに入力する共通名は、クライアントが接続するサーバーのホスト名と一致する必要があります。これにより、第7.4.8.2項で説明されている問題を回避できます。

6. 証明書リクエスト(CR)の詳細を入力して、「OK」をクリックします。
CRが生成されます。次のいずれかを実行できます。

- Base64でエンコードされた証明書リクエストをコピーしてファイルに貼り付けます。

- 「証明書リクエストのエクスポート」ボタンを使用して、ファイルに直接エクスポートします。

7. 証明書リクエスト・ファイルを認証局に送信して、証明書を生成します。これは、証明書取得のローカル・ポリシーに従って実行できるオフラインの手順です。

8. CAは証明書リクエストに署名して、証明書を生成します。CAは、次のいずれかを返送します。

- 1個のファイル。新しく生成された証明書と独自のCA証明書の両方がpkcs7形式で含まれます。

- 1つのファイルには新しく生成された証明書、その他のファイルには独自のCA証明書(チェーンがある場合は複数のCA証明書)が含まれている複数のファイル。

9. 「インポート」を使用して、これらのファイルをウォレットにインポートします。

- CAから1個のファイルを受信した場合は、置き換える自己署名証明書の別名(ステップ3を参照)と一致する別名を使用して、信頼できる証明書としてインポートします。

- 2つ以上のファイルを受信した場合は、次の手順を実行します。

- CA証明書または証明書チェーンが含まれているファイルを、信頼できる証明書としてインポートします(ウォレット内で一意の別名を使用)。

- 証明書ファイルを証明書としてインポートします(置き換える自己署名証明書の別名と一致する別名を使用)。

注意:
順序は重要です。信頼できる証明書、証明書の順にインポートする必要があります。
正しい信頼できるCA証明書、または信頼できる証明書の正しいチェーンを識別する方法の詳細は、My Oracle Supportナレッジ・ベースのドキュメントID 1368940.1 (https://support.oracle.com/epmos/faces/DocumentDisplay?id=1368940.1">>https://support.oracle.com/epmos/faces/DocumentDisplay?id=1368940.1)を参照してください

CAから1個のファイルが返され、これを信頼できる証明書としてインポートします。

10. インポート後に、CAが発行した証明書で自己署名証明書が置き換えられます。

7.4.7.5.2 WLSTを使用したサード・パーティ証明書への自己署名証明書の変換

関連項目:
第6.9項

第7.2.1項の説明に従い、プロトコルを使用してこれらのWLSTコマンドを実行します。

次の手順を実行し、WLSTを使用して自己署名証明書をサード・パーティ証明書に変換します。

1. 証明書リクエストを追加します。例:

addCertificateRequest('inst1', 'ohs1', 'ohs', 'selfsigned', 'password', 'subject_dn', 'key_size')

2. 証明書リクエストをエクスポートします。

exportWalletObject('inst1', 'ohs1', 'ohs', 'selfsigned', 'password', 'CertificateRequest', '/tmp', 'subject_dn')

3. 証明書リクエスト/tmp/base64.txtを認証局に送信します。CAは、新しく生成された証明書とその独自の証明書を、PKCS#7形式の1つのファイル、または1つのファイルには新しく生成された証明書、その他のファイルには独自のCA証明書(チェーンがある場合は複数のCA証明書)が含まれている複数のファイルとして返します。

4. CAから単一のファイルを受信した場合は、次のコマンドを実行します。

importWalletObject('inst1', 'ohs1', 'ohs', 'selfsigned', 'password', 'TrustedChain', '/tmp/cert.txt')

passwordはこのウォレットのパスワード、/tmp/cert.txtはCAから返され、BASE64でエンコードされたPKCS#7を含むファイルです。

CAから2つ以上のファイルを受信した場合は、信頼できる証明書としてCA証明書または証明書チェーンが含まれているファイルを最初にインポートし、次に新しく生成された証明書をインポートします。たとえば、次に2つのファイルが返される例を示します。

importWalletObject('inst1', 'ohs1', 'ohs', 'selfsigned', 'password', 'TrustedCertificate', '/tmp/cacert.txt')

importWalletObject('inst1', 'ohs1', 'ohs', 'selfsigned', 'password', 'Certificate', '/tmp/cert.txt')

passwordはこのウォレットのパスワード、/tmp/cert.txtはCAから返され、BASE64でエンコードされた証明書を含むファイル、/tmp/cacert.txtはBASE64でエンコードされたCA証明書を含むファイルです。

正しい信頼できるCA証明書、または信頼できる証明書の正しいチェーンを識別する方法の詳細は、My Oracle Supportナレッジ・ベースのドキュメントID 1368940.1 (https://support.oracle.com/epmos/faces/DocumentDisplay?id=1368940.1">>https://support.oracle.com/epmos/faces/DocumentDisplay?id=1368940.1)を参照してください

関連項目:
『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』の次のリファレンス項目。

- 「addCertificateRequest」

- 「exportWalletObject」

- importWalletObjectに関する説明

7.4.8 ウォレットおよび証明書の保守

この項は次の管理に関する項目で構成されています。

- ウォレットの場所

- ホスト名変更のウォレットへの影響

- 自己署名付きウォレットのサード・パーティのウォレットへの変更

- ウォレット内の期限が切れそうな証明書の置換え

7.4.8.1 ウォレットの場所

この項ではウォレットの場所およびメンテナンスの詳細について説明します。

Oracle HTTP Serverウォレットのルート・ディレクトリ

Oracle HTTP Serverウォレットのルート・ディレクトリは、次のとおりです。

$DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_instance_name/keystores

このルート・ディレクトリには、ウォレットの名前がついたサブディレクトリが入ります。それぞれのサブディレクトリには実際のウォレット・ファイルが格納されます。

たとえば、ohs_instance1にohs1とohs2という2つのウォレットがあるとします。ohs1はパスワードで保護されたウォレット、ohs2は自動ログインのみのウォレットです。サンプルの構造は、次のようになります。

$DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_instance1
/keystores/ohs1/cwallet.sso

$DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_instance1
/keystores/ohs1/ewallet.p12

$DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_instance1
/keystores/ohs2/cwallet.sso

7.4.8.2 ホスト名変更のウォレットへの影響

一般的には、ウォレットのDNはウォレットが使用されるサーバーのホスト名に基づいています。

たとえば、ウォレットがOracle HTTP Serverのmy.example.comで作成されている場合、このOracle HTTP Serverウォレットの証明書のDNは「CN=my.example.com,O=organization name」のようになります。

ほとんどのクライアントはSSLハンドシェイク時にホスト名を検証するため、この同期は必須です。

ホスト名の検証を実行するクライアントには、WebブラウザやOracle HTTPClientなどがあります。サーバーのホスト名が証明書のDNと一致しない場合、次のように処理されます。

- 明確な警告が表示されます(ブラウザ・クライアントの場合)。

- SSLハンドシェイクが失敗する場合があります(その他のクライアントの場合)。

クライアントからリクエストを受信しているサーバー上にウォレットがある場合、このサーバーのホスト名が変更されるたびに、ウォレット内の証明書も更新する必要があります。

これは、新しいDN(新しいホスト名に基づく)で新しい証明書をリクエストすることで実行できます。

7.4.8.2.1 本番ウォレットに対する新しい証明書のリクエスト

本番ウォレットにインポートするための新しい証明書をリクエストできます。

手順は次のとおりです。

1. 新しいDN(新しいホスト名に基づく)で新しいリクエストを生成します。

2. このリクエストを認証局(CA)に送信します。

3. CAから新しい証明書が返送されます。

4. ウォレットから古い証明書および証明書リクエストを削除します。

5. 新しい証明書をインポートします。

これらの操作の詳細は、第7.4.4項を参照してください。

7.4.8.2.2 自己署名付きウォレットに対する新しい証明書のリクエスト

自己署名ウォレットに新しい証明書を追加するには、証明書の新しいウォレットを作成する必要があります。

手順は次のとおりです。

1. 既存のウォレットを削除します。

2. 新しいDN(新しいホスト名に基づく)を使用して自己署名証明書を含む新しいウォレットを作成します。

これらの操作の詳細は、第7.4.4項を参照してください。

本番ウォレットの場合も自己署名付きウォレットの場合も、新しい証明書がウォレットで使用可能になったら、その証明書を信頼する必要があるすべてのコンポーネントのウォレットに確実にインポートする必要があります。たとえば、Oracle WebLogic ServerでSSLが有効な場合、ホスト名の変更によってOracle WebLogic Serverの証明書が変更されたら、新しい証明書をOracle HTTP Serverウォレットにインポートして、新しいピアを信頼できるようにする必要があります。

7.4.8.3 自己署名付きウォレットのサード・パーティのウォレットへの変更

自己署名付きウォレットをサード・パーティのウォレットに変換できます。サード・パーティのウォレットには、信頼できる認証局(CA)が署名した証明書が含まれます。

「CN=my.example.com,O=example」というDNの証明書が格納された、MYWalletという自己署名付きウォレットがあるとすると、次の手順を実行して、これをサード・パーティのウォレットに変換します。

1. ウォレットからユーザー証明書「CN=my.example.com,O=example」を削除します。

2. ウォレットから信頼できる証明書「CN=my.example.com,O=example」を削除します(これは、ユーザー証明書と同じDNですが、別のエンティティです)。

3. ウォレットから証明書リクエスト「CN=my.example.com,O=example」をエクスポートして、ファイルに保存します。

4. この証明書リクエスト・ファイルをVeriSignなどのサード・パーティの認証局(CA)に送信します。

5. CAは、次のいずれかを返送します。

- ユーザー証明書ファイルと独自の証明書ファイル

- ユーザー証明書と独自の証明書で構成された証明連鎖を含む単一のファイル

6. これらのファイルをウォレットにインポートします。

これらの操作の詳細は、第7.4.4項を参照してください。

7.4.8.4 ウォレット内の期限が切れそうな証明書の置換え

期限が切れそうな証明書は、実際に期限が切れる前に置き換えて、アプリケーションの停止時間を回避または短縮する必要があります。

期限が切れそうな証明書を置き換える手順は次のとおりです。

1. ウォレットから証明書リクエストをエクスポートします(これは、現在期限が切れそうな証明書の発行時と同じリクエストです)。

2. 証明書発行のために、この証明書リクエストをサード・パーティの認証局(CA)に送信します。新しい証明書の発効日は、現在の証明書の失効日より早くしてください。停止時間を短縮するために、このような重複期間を設けることをお薦めします。

注意:
サード・パーティのCAがすでにリポジトリの証明書リクエストを保守している場合、ステップ1と2は不要です。その場合は、単純にその証明書リクエストの新しい証明書の発行をCAにリクエストします。

3. ウォレットから既存の証明書(期限が切れそうな証明書)を削除します。

4. 新しく発行された証明書をウォレットにインポートします。
停止時間を短縮するために、新しい証明書が有効になり古い証明書が失効していない重複期間に、前の証明書を削除して新しい証明書をインポートします。

5. 新しい証明書が元の証明書の発行元以外のCAで発行された場合は、新しく発行された証明書をインポートする前に、新しいCAの信頼できる証明書をインポートする必要があります。

これらの操作の詳細は、第7.4.4項を参照してください。

8 Oracle Fusion MiddlewareでのFIPS 140のサポート

この章では、Oracle Fusion MiddlewareでのFIPS 140のサポートについて説明します。

この章の内容は次のとおりです。

- FIPS標準について

- Oracle Fusion Middlewareリリース12c (12.2.1)でのFIPS 140-2について

- FIPS 140によりサポートされているコンポーネント

- 業務系FIPS 140-2環境の一般的なシナリオ

- FIPS 140問題のトラブルシューティング

8.1 FIPS標準について

FIPS (Federal Information Processing Standards)は、米国商務省の標準技術局(National Institute of Standards and Technology: NIST)によって発行されている一連の標準で、コンピュータ・システムおよびネットワークのセキュリティを評価するのに使用されます。

FIPS標準の1つであるFIPS 140-2は、機密情報を保護するために暗号化モジュールが満たしている必要があるセキュリティ要件を規定しています。この標準では、暗号化モジュールを使用する可能性のある幅広いアプリケーションおよび環境に対応するために、質的に拡張された4段階のセキュリティレベルが指定されています。

注意:
この章では以降、用語「FIPS 140」はFIPS 140-2標準のことを意味しています。

8.2 Oracle Fusion Middlewareリリース12c (12.2.1)でのFIPS 140-2について

Oracle Fusion Middlewareリリース12c (12.2.1)では、FIPS 140-2対応の暗号化ライブラリを使用できます。

FIPS 140モードで動作する機能は、汎用的で製品スイート全体にわたる要求ではありません。それよりはむしろ、関連するOracle Fusion Middleware 12c (12.2.1)製品コンポーネントによってサポートされているシナリオおよびトランザクションの定義済セットに固有のものです。また、認証、許可、機密保護、整合性など、セキュリティの影響を受けるタスクをサポートまたは実行するために検証済の暗号化が使用される箇所に適用されます。

セキュリティの影響を受けない他のタスクで暗号化サービスを使用する場合は、FIPS 140コンプライアンスに従う必要はありません。Oracle Fusion Middleware 12c (12.2.1)では、セキュリティの影響を受けるシナリオでFIPS 140モードを有効化できると同時に、このモードで動作する必要がない製品機能にも対応して共存することが可能です。

8.2.1 FIPS 140-2検証済ライブラリについて

FIPS 140動作をサポートするために、Oracle Fusion Middleware 12c (12.2.1)には、RSA, The Security Division of EMC (RSA)のFIPS 140検証済RSAライブラリが組み込まれています。FIPS 140の下で承認されていないアルゴリズムは、RSAライブラリでは無効化されています。

このライブラリは、RSAバージョン6.1 BSAFEおよびJCEソフトウェアを基本にしており、次のモジュールが含まれています。

- Crypto-J V6.1.1

- SSL-J V6.1.2

- Cert-J V6.1.1

注意:
これらは、発行時点におけるFIPS 140認証済ライブラリおよびモジュール・バージョンです。ただし、動作保証時から製品の実際の出荷時までの間にベンダーによりパッチが発行されている場合があるため、インストール時に実際に有効なバージョンは、ここで示されているバージョンとは多少異なることがあります。この場合、実際のバージョンは、動作保証されたバージョンのドット・リリースになります。
バージョン番号は単なる参考情報であり、アルゴリズムの動作保証とセキュリティ強度について別個検証を行う必要があります。

FIPS 140標準およびアルゴリズムのバックグラウンドの詳細は、FIPS 140-2ドキュメントを参照してください。

http://csrc.nist.gov/publications/PubsFIPS.html

8.2.2 プロバイダおよびアルゴリズムの選択について

FIPS 140は、JavaプラットフォームのJava暗号化アーキテクチャ(JCA)のコンテキストに従ってOracle Fusion Middlewareに実装されます。セキュリティの影響を受けるタスク用のFIPS 140検証済アルゴリズムと、その他のタスク用のアルゴリズムを共存させるために、FIPS 140検証済RSAライブラリでサポートされていない機能、およびFIPS 140検証済RSAライブラリでは無効化されている特定の非準拠暗号化機能(MD5など)にも対応するように、追加の暗号化プロバイダ・サービスを構成します。

基本的なフローは次のとおりです。

- アプリケーション(たとえば、外部Webクライアント、Oracle HTTP Serverなど)が、WebLogic Serverなどのサーバーに対してサービスまたは接続をリクエストします。このリクエストには通常、転送されるデータ・パケットなどの「ペイロード」が含まれています。

- JCAがこのリクエストを評価し、FIPS 140コンプライアンスが必要であるかどうかを判別します。

- このリクエストはJCAの「プロバイダ」フレームワークにルーティングされますが、ここには、デジタル署名、メッセージ・ダイジェスト(ハッシュ)、証明書、証明書検証、暗号化およびその他の暗号化サービス用の一連の(FIPS 140準拠および非準拠の)プロバイダが含まれています。

- このプロバイダは優先順位に従って検索され、正しいアルゴリズムを提供している最初のプロバイダの実装が返されます。セキュリティの影響を受ける状況の場合、暗号化操作を実行するのに使用されるのはFIPS 140準拠のアルゴリズムのみです。

図8-1に、このフローを示します。

図8-1 FIPS 140プロバイダの選択

- 左側の最初のリクエストは、セキュリティの影響を受けるシナリオで実行されます。JCAは、RSA暗号化ライブラリのSHA-256プロバイダを使用してこのリクエストを処理し、FIPS 140ペイロードを配信します。

- 右側の2番目のリクエストは、セキュリティの影響を受けないシナリオで実行されます。JCAは、非暗号化ライブラリのMD5プロバイダを使用して、非FIPS 140ペイロードが含まれたこのリクエストを処理します。

このように、FIPS 140に準拠することを目的としたHTTPS/TLSインバウンドおよびアウトバウンド通信などの、セキュリティの影響を受けるシナリオでは、FIPS 140検証済RSAライブラリで使用可能な暗号化機能のみを使用して、HTTPS/TLSネットワーク・ペイロードを暗号化して署名します。

8.3 FIPS 140によりサポートされているコンポーネント

Oracle Fusion MiddlewareでFIPS 140を取り扱う場合は、特定の機能がFIPS 140モードで動作できるようなミドルウェア・スタックの様々なレイヤーにある個別のコンポーネントに注意してください。スタック内のいずれかのコンポーネントが非FIPS 140モードで動作している場合、トランザクションがFIPS 140に準拠していない可能性があります。このため、関連コンポーネントがすべてFIPS 140モードで動作していることを確認することが重要になります。

表8-1に、FIPS 140を有効化できるコンポーネントを一覧表示し、その詳細について説明します。

- コンポーネントが存在するOracle Fusion Middlewareレイヤー

- コンポーネント名

- FIPS 140対応が可能なシナリオ

- 詳細の製品ドキュメントに対する相互参照(FIPS 140を有効化または無効化する方法、その他の関連する構成の詳細、FIPS 140検証済暗号化を使用できる製品機能を含む)

注意:
一覧表示されている各コンポーネントのすべての機能がFIPS 140に準拠しているとはかぎりません。FIPS 140をサポートしているのは指定された機能のみです。

表8-1 Oracle Fusion MiddlewareでFIPS 140-2がサポートされているコンポーネント

コンポーネント・レイヤー

コンポーネント

機能

詳細

Fusion Middlewareコア

Oracle HTTP Server

- TLSインバウンド(HTTPS)

- OHS SSLプロキシ(mod_proxy、mod_ossl)を使用したOHSから任意のWebサーバー、プロキシ・サーバーまたはアプリケーション・サーバーへのTLSアウトバウンド

注意: OHSからWLSへのアウトバウンド接続の場合、FIPSをWebLogic (インバウンド接続用)で有効にし、OHSとWLS間のFIPS通信を有効にする必要があります。

『Oracle HTTP Server管理者ガイド』の次のトピック:

- mod_osslの「SSLFIPS」ディレクティブ

- 「アプリケーション・セキュリティの管理」

Oracle WebLogic Server

- TLSインバウンド: HTTPS、T3S、JMX/T3S、JMS

- TLSアウトバウンド: HTTPS、T3S、JMX/T3S、JMS、JDBC (Oracle RDBMS)

- データベース接続(データ・ソースを介した)

『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のFIPSモードの有効化に関する項

『Oracle WebLogic Server WebLogic Webサービスの保護』のSHA-256セキュア・ハッシュ・アルゴリズムの使用に関する項

『Oracle WebLogic Server JDBCデータ・ソースの管理』の暗号化済接続プロパティの使用に関する項

Oracle Platform Security Services

- キーストア・サービス

- 資格証明ストア・サービス

『Oracle Platform Security Servicesによるアプリケーションの保護』のOPSSでのFIPSのサポートに関する項

Oracle Web Services Manager

- メッセージ保護

- トークン署名

『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のサポートされているアルゴリズム・スイートに関する項

Oracle SOA Suite

- ファイル/FTP用のJCAアダプタ

- データベース用のJCAアダプタ

- JMS用のJCAアダプタ

- Service Bus

『Oracle Service Busでのサービスの開発』のSFTPトランスポートのFIPS準拠に関する項

『テクノロジ・アダプタの理解』のOracleファイルおよびFTPアダプタのFIPS準拠の有効化に関する項

Oracle Traffic Director

NZ統合

- 『Oracle Traffic Director WebLogic Scripting Toolコマンド・リファレンス』

- 『Oracle Traffic Directorの管理』

データベース

Oracle Database

- FIPS 140-2モードでのデータベース

『Oracle Databaseセキュリティ・ガイド』のOracle DatabaseのFIPS 140-2設定に関する項

注意:
データベースは参照用です。サポートされているバージョンおよびその他の詳細は、動作保証マトリックスを参照してください。

8.4 業務系FIPS 140-2環境の一般的なシナリオ

表8-1では、FIPS 140-2機能を備えたOracle Fusion Middlewareのコンポーネントを一覧表示しています。表8-2に、コンポーネント・シナリオごとの一般的なプロトコルを一覧表示します。

注意:
これらは代表的なシナリオであり、この表は使用可能なすべてのシナリオの包括的なリストを提供することが目的ではありません。

表8-2 FIPS 140-2のシナリオ

機能または接続

通信プロトコル

署名アルゴリズムおよびプロトコルの詳細

外部WebクライアントまたはアプリケーションからOracle HTTP Serverへのインバウンド接続

- HTTPS (OHSへのクライアント・アクセス)

- SOAP-TLS (サーバー間の通信)

HTTPSサーバー(TLS、相互認証、SHA-256 X.509証明書を備えたRSA-2048、AES-256バルク・データ暗号化)

Oracle HTTP ServerからOracle WebLogic Serverへのアウトバウンド接続

- OHS内の外部SSL Terminationを備えた端末間SSL用のHTTPS (OHSとWLS内のHTTP Servlet間)

HTTPSクライアント(TLS、相互認証、SHA-256 X.509証明書を備えたRSA-2048、AES-256バルク・データ暗号化)

外部WebクライアントまたはアプリケーションからOracle WebLogic Serverへのインバウンド接続

- HTTPS (HTTP Servletへのクライアント・アクセス)

- SOAP-TLS (サーバー間の通信)

HTTPSサーバー(TLS、相互認証、SHA-256 X.509証明書を備えたRSA-2048、AES-256バルク・データ暗号化)

Oracle WebLogic Serverから外部Webサーバー、プロキシ・サーバーまたはアプリケーション・サーバーへのアウトバウンド接続

- HTTPS (WLSと外部HTTPSサーバー間)

- SOAP-TLS (サーバー間の通信)

HTTPSクライアント(TLS、相互認証、SHA-256 X.509証明書を備えたRSA-2048、AES-256バルク・データ暗号化)

Oracle WebLogic ServerからOracle Database 11gR2へのアウトバウンド接続

- DB-TLS-jdbc (WebLogicとデータベース間の通信)

JDBC (TLS、相互認証、SHA-256 X.509証明書を備えたRSA-2048、AES-256バルク・データ暗号化)

Oracle Web Services Managerを使用したSOAPメッセージ用のXMLメッセージ保護(XML署名)

- SOAP-MsgSec

XML署名(Basic256Sha256、Basic256Sha256Rsa15)、全文、SwA添付を含む

Oracle Web Services Managerを使用したSOAPメッセージ用のXMLメッセージ保護(XML暗号化)

- SOAP-MsgSec

XML署名(Basic256Sha256、Basic256Sha256Rsa15)、全文、SwA添付を含む

Oracle WebLogic ServerへのインバウンドJMS接続

- 通信中のJMSトラフィックはセキュア

JMS/TLS

Oracle WebLogic ServerからのアウトバウンドJMS接続

- 通信中のJMSトラフィックはセキュア

JMS/TLS

デプロイ済コンポーネントからのセキュアなJNDI参照

- JDNI-EJB

T3S

サーバーへのセキュアな管理者アクセス

- WLSサーバーへ通信中のWLSTトラフィックはセキュア

T3S

キーストアおよび証明書の生成

- 暗号化

- 鍵の交換

RSA 2048、AES 256、SHA-2

ハッシング・アルゴリズム、パスワードベースの暗号化

- ハッシング

- 暗号化

SHA-2

SOAサービスベースのコンポーネント用のOracle Service Bus

サービス・タイプ用のSFTPトランスポート:

- メッセージング

- 任意のXML

公開鍵アルゴリズム(diffie-hellman-group14-sha1)

キー交換アルゴリズム(ssh-rsa)

Managed File Transfer (MFT)

- 鍵の交換

- 暗号

- メッセージ認証

ファイル・トランスポート:

- SFTP

- FTP-SSL

- PGP

- JCAトランスポート

一般的なアルゴリズム

- DHG14

- AES128CBC、TripleDESCBC

- HMACSHA1

- RSA、DSA

- diffie-hellman-group14-sha1

JCAアダプタ

ファイル転送プロトコル

- diffie-hellman-group14-sha1

- ssh-rsa

注意:
特に指示のないかぎり、すべてのコンポーネント・サーバーはリリース12c (12.2.1)です。

8.5 FIPS 140問題のトラブルシューティング

この項では、FIPS 140構成で発生した問題をトラブルシューティングする方法について説明します。内容は次のとおりです。

- スタンドアロンWebLogic ServerにおけるFIPS 140のトラブルシューティング

- Oracle Platform Security ServicesにおけるFIPS 140のトラブルシューティング

- Oracle Web Services ManagerにおけるFIPS 140のトラブルシューティング

- データベースおよびJDBCドライバにおけるFIPS 140のトラブルシューティング

8.5.1 スタンドアロンWebLogic ServerにおけるFIPS 140のトラブルシューティング

スタンドアロンOracle WebLogic ServerでFIPS 140モードをトラブルシューティングするには、次の手順を実行します。

WebLogic Serverの構成時

1. jcmFIPS.jarおよびsslj.jarの先頭にサーバーのCLASSPATHが付加されていることを確認します。

2. *AES_256*暗号スイートを明示的に検証するために、JAVA_HOME/jre/lib/securityディレクトリにあるlocal_policy.jarおよびUS_export_policy.jarを、セキュリティ強度制限のない対応するファイルで更新します。

3. リストの上部にsecurity.provider.1=com.rsa.jsafe.provider.JsafeJCEおよびsecurity.provider.2=com.rsa.jsse.JsseProviderを追加して、JAVA_HOME/jre/lib/security/java.securityを変更します。

データ・ソースの構成時

DataSourceプロパティoracle.net.ssl_versionの値が1.0に設定されていることを確認します。

注意: oracle.net.ssl_versionは、オプションのOracle WebLogic Server DataSource構成プロパティです。値1.0は、TLS v1.0プロトコルを介して接続されていることを示します。

8.5.2 Oracle Platform Security ServicesにおけるFIPS 140のトラブルシューティング

この項では、Oracle Platform Security Services (OPSS)におけるいくつかのトラブルシューティングのヒントについて説明します。

WebLogicドメインの作成時

FIPS 140モードでのドメインの作成時に、wlsconfig_xxxxx.logに次の例外が表示される場合があります。

"CFGFWK-60455: The password
must be at least 8 alphanumeric characters with at least one number or
special character."

"Caused by: java.lang.NoSuchMethodError:
com.rsa.jsafe.JSAFE_SecretKey.generateInit([ILjava/security/SecureRandom;)"

この例外は、cryptoJ 5 jarを使用している場合に発生することがあります。このエラーを回避するために、cryptoJ 6 jarを備えたOracle WebLogic Serverがインストールされていることを確認してください。

ドメイン・キーストアからのエクスポート時

FIPS 140対応のドメインでJKSおよびJCEKSタイプのキーストアを使用している場合は、次のエラーが表示されます。

Command FAILED, Reason:
oracle.security.jps.service.keystore.KeyStoreServiceException: Failed to export the keystore

この場合は、java.securityファイルで次のプロバイダが構成されていることを確認してください。

sun.security.provider.Sun
com.sun.crypto.provider.SunJCE

8.5.3 Oracle Web Services ManagerにおけるFIPS 140のトラブルシューティング

この項では、Oracle Web Services Managerで発生する問題に関するヒントについて説明します。

メッセージ保護ポリシー実行時

Oracle Web Services Managerでメッセージ保護ポリシー実行時にこのエラーが表示される場合があります。

Caused by: java.lang.SecurityException: Algorithm not allowable in FIPS140 mode: MD5
at com.rsa.cryptoj.o.cc.b(Unknown Source)
at com.rsa.cryptoj.o.cc.f(Unknown Source)

この場合は、メッセージ保護実行時に使用されている証明書が、SHA1WithRSAやSHA256WithRSAなどのFIPS 140に準拠したアルゴリズムを使用して生成されていることを確認してください。

メッセージ保護ポリシー実行時に、JKSキーストアに対してこのエラーが表示される場合があります。

oracle.fabric.common.PolicyEnforcementException: WSM-00143 : Failure creating Java Keystore instance for type JKS.

この場合は、JDKでsun.security.provider.Sunが構成されていることを確認してください。

8.5.4 データベースおよびJDBCドライバにおけるFIPS 140のトラブルシューティング

データベースに関連するデータ・ソースの問題を含む、データベースおよびJDBCドライバのセキュリティ構成の詳細は、Oracle Technology Networkで入手可能なホワイト・ペーパーのOracle JDBCシン・ドライバでのSSLに関する説明を参照してください。

http://www.oracle.com/technetwork/middleware/id-mgmt/documentation/index.html

第IV部

アプリケーションのデプロイ

この部では、デプロイ・プロセス、Oracle Fusion Middlewareにアプリケーションをデプロイする方法について説明します。

第IV部は、次の章で構成されています。

- 第9章「デプロイ・プロセスの理解」

- 第10章「アプリケーションのデプロイ」

9 デプロイ・プロセスの理解

Oracle Fusion Middlewareアプリケーション(Java EEアプリケーションなど)をデプロイする前に、デプロイ・プロセス(アプリケーションの設計および開発、これらのアプリケーションの管理対象サーバーへのデプロイなど)を理解する必要があります。

この章の内容は次のとおりです。

- デプロイヤとは

- アプリケーション設計から本番デプロイへの一般的な移行手順

- 一般的な問題の診断

9.1 デプロイヤとは

デプロイヤ・ロールのユーザーは、Java EEアプリケーションやADFアプリケーションなどのアプリケーションを、WebLogic Serverのインスタンスまたはクラスタにデプロイする作業を担当します。

デプロイヤとして作業するユーザーには、Oracle WebLogic Serverのデプロイヤ・セキュリティ・ロールを付与する必要があります。デプロイヤ・セキュリティ・ロールが付与されていると、デプロイ操作の他に、サーバー構成の表示や起動クラスと停止クラスの変更などが可能になります。このロールをユーザーに付与するには、Oracle WebLogic Server管理コンソールを使用します。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの、セキュリティ・ロールの管理に関する項を参照してください。

9.2 アプリケーション設計から本番デプロイへの一般的な移行手順

この項では、アプリケーションの設計および開発から本番環境へのデプロイに移行する際の一般的な手順について説明します。次の項目が含まれます。

- アプリケーションの設計および開発

- 管理対象サーバーへのアプリケーションのデプロイ

- 他の環境へのアプリケーションの移行の自動化

9.2.1 アプリケーションの設計および開発

多くの場合、開発者はアプリケーションの作成にOracle JDeveloperを使用します。Oracle JDeveloperは、Java、XML、Webサービス、ポートレット、SQLの最新業界標準を使用してサービス指向アプリケーションを構築するための統合開発環境(IDE)です。JDeveloperは、アプリケーションのモデリング、コーディング、デバッグ、テスト、プロファイル、チューニング、デプロイの各機能が統合されており、ソフトウェア開発のライフサイクル全体をサポートしています。

この環境では、統合型のOracle WebLogic Serverを使用します。これは、アプリケーションのテストを目的として、Oracle JDeveloperとともにパッケージ化されています。

アプリケーションのデプロイの詳細は、次を参照してください。

- Oracle WebLogic Serverアプリケーションの開発

- Oracle Application Development FrameworkによるFusion Webアプリケーションの開発

- Oracle SOA SuiteでのSOAアプリケーションの開発

- Oracle JDeveloperによる、WebCenter Portalアセットおよびカスタム・コンポーネントの開発

9.2.2 管理対象サーバーへのアプリケーションのデプロイ

統合型のOracle WebLogic Serverで設計とテストの済んだアプリケーションは、管理対象サーバー・インスタンスにデプロイできます。たとえば、本番環境にOracle WebLogic Serverをインストールして、管理対象サーバーを含めたドメインを構成し、その管理対象サーバーにアプリケーションをデプロイするとします。

次の各ドキュメントでは、様々なタイプのアプリケーションのデプロイについて具体的な情報が記述されています。

- Java EEアプリケーションの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照

- Oracle ADFの詳細は、『Oracle ADFアプリケーションの管理』を参照してください。

- Oracle SOA Suiteの詳細は、『Oracle SOA SuiteによるSOAアプリケーションの開発』を参照してください。

- Oracle WebCenter Portalの詳細は、『Oracle WebCenter Portalの管理』を参照してください

この項では、統合型のOracle WebLogic Serverからデプロイ環境とは別の環境にアプリケーションを移行する場合に必要な、主な手順の概要について説明します。一般的な手順は次のとおりです。

1. アプリケーションをパッケージ化します。

- Java EEアプリケーションでは、アプリケーションをEARファイルにパッケージ化します。『Oracle WebLogic Serverへのアプリケーションのデプロイ』のアプリケーションとモジュールのデプロイのための準備に関する項を参照してください。

- Oracle ADFでは、アプリケーションをEARファイルにパッケージ化します。詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のEARファイルおよびパッケージ化に関する必知事項を参照してください。

- Oracle SOA Suiteでは、アプリケーションをJARまたはZIPファイルにパッケージ化します。詳細は、『Oracle SOA SuiteによるSOAアプリケーションの開発』のパッケージ化の影響の理解に関する項を参照してください。

- Oracle WebCenter Portalでは、アプリケーションをEARファイルにパッケージ化します。Oracle JDeveloperでのWebCenter Portalアセットおよびカスタム・コンポーネントの開発のWebCenter Portalアプリケーションのパッケージ化に関する項を参照してください

2. 環境を設定します。次のものが含まれます。

- ドメイン、およびその正しいドメイン・テンプレートで構成された管理対象サーバーのインストールおよび構成。たとえば、Oracle SOA Suiteアプリケーションをデプロイする場合、管理対象サーバーではOracle SOA Suiteドメイン・テンプレートを使用する必要があります。構成ウィザードを使用してドメインを作成すると、適切なドメイン・テンプレートが適用されます。また、第19.2項で説明するように、ドメインを拡張して別のドメイン・テンプレートを使用することもできます。
具体的なコンポーネントのインストールおよび構成の詳細は、次を参照してください。

- Oracle ADF: 『Oracle ADFアプリケーションの管理』のWebLogicインストールにADFランタイムをインストールする方法に関する項

- Oracle SOA Suite: 『Oracle SOA SuiteおよびOracle Business Process Managementのインストールと構成』のOracle SOA SuiteおよびOracle Business Process Management Suiteのインストールに関する項、Oracle SOA Suiteドメインの構成に関する項およびOracle Business Process Managementドメインの構成に関する項

- Oracle WebCenter Portal: 『Oracle WebCenter Portalのインストールと構成』のOracle WebCenter Portalのインストールに関する項およびOracle WebCenter Portalの構成に関する項

- 必要なすべてのスキーマの既存のデータベースでの作成。『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

- Oracle WebLogic ServerドメインへのMDSリポジトリの登録(アプリケーションでMDSリポジトリを使用する場合)。たとえば、Oracle SOA SuiteアプリケーションにはMDSが必要です。一部のADFアプリケーションでは、MDSを使用してカスタマイズを行います。MDSリポジトリの登録の詳細は、第14.3.2.1.1項を参照してください。

3. アプリケーションでデータベースを使用する場合は、JDBCデータ・ソースを設定します。

JDBCデータ・ソースの設定の詳細は、次を参照してください。

- ピュアJava EEアプリケーション: 『Oracle WebLogic Server JDBCデータ・ソースの管理』

- Oracle ADF: 『Oracle ADFアプリケーションの管理』のOracle WebLogic ServerのJDBCデータ・ソースを作成する方法に関する項

- Oracle SOA Suite: 『Oracle SOA SuiteによるSOAアプリケーションの開発』のデータ・ソースおよびキューを作成する方法に関する項

- Oracle WebCenter Portal: 『Oracle WebCenter Portalの管理』のデータ・ソースの選択に関する項

4. Oracle SOA Suiteの場合、接続ファクトリおよび接続プールを作成します。詳細は、『Oracle SOA SuiteによるSOAアプリケーションの開発』の接続ファクトリおよび接続プールを作成する方法に関する項を参照してください。

5. ターゲットとなる管理対象サーバーへの接続を作成します。

Oracle JDeveloperから、JDeveloperの外部にある管理対象サーバー・インスタンスにアプリケーションをデプロイできます。そのためには、まずアプリケーションのデプロイ先となるサーバー・インスタンスへの接続を作成する必要があります。

詳細は、次を参照してください:

- Oracle ADF: 『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のターゲット・アプリケーション・サーバーへの接続を作成する方法に関する項

- Oracle SOA Suite: 『Oracle SOA SuiteによるSOAアプリケーションの開発』のアプリケーション・サーバー接続を作成する方法に関する項

- Oracle WebCenter Portal: Oracle JDeveloperでのWebCenter Portalアセットおよびカスタム・コンポーネントの開発のWebLogic管理対象サーバー接続の作成に関する項

6. Oracle SOA Suiteの場合、SOAコンポジット・アプリケーションが他のコンポジットとメタデータを共有している場合、SOA-MDS接続を作成します。『Oracle SOA SuiteでのSOAアプリケーションの開発』のSOA-MDS接続の作成に関する項を参照してください。

7. JDBC接続文字列や各種サーバーのホスト名など、環境に固有の値の情報を含む構成プランまたはデプロイメント・プランを作成します。詳細は、次を参照してください:

- ピュアJava EEアプリケーション: 『Oracle WebLogic Serverへのアプリケーションのデプロイ』のアプリケーションを構成するための新規デプロイメント・プランの作成に関する項

- Oracle SOA Suite: 『Oracle SOA SuiteでのSOAアプリケーションの開発』の構成プランの概要に関する項

8. 資格証明、アイデンティティ、ポリシーなどのアプリケーション・セキュリティを移行します。詳細は、次を参照してください:

- ピュアJava EEアプリケーション: 『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のセキュリティ・データの移行に関する項

- Oracle ADF: 『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のデプロイメントのためのセキュア・アプリケーションの準備に関する項

- Oracle SOA Suite: 『Oracle SOA SuiteでのSOAアプリケーションの開発』のセキュリティの有効化に関する項

- Oracle WebCenter Portal: 『Oracle WebCenter Portalの管理』のWebCenter Portalアプリケーション・セキュリティの管理に関する項

9. デプロイメント・プロファイルを作成します。デプロイメント・プロファイルは、カスタムADF、WebCenter Portal、SOAの各アプリケーションおよび関連付けられたファイルをパッケージ化またはアーカイブして、Oracle WebLogic Server管理対象サーバー・インスタンスにアプリケーションをデプロイできるようにします。デプロイ・プロファイルは、プロジェクト・レベルおよびアプリケーション・レベルで作成されます。
詳細は、次を参照してください:

- Oracle ADF: 『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のデプロイメント・プロファイルの作成方法に関する項

- Oracle SOA Suite: 『Oracle SOA SuiteでのSOAアプリケーションの開発』のプロジェクト・デプロイメント・プロファイルの作成(オプション)に関する項

- Oracle WebCenter Portal: Oracle JDeveloperでのWebCenter Portalアセットおよびカスタム・コンポーネントの開発のデプロイメント・プロファイルの作成に関する項

10. Oracle SOA Suiteに対して、Oracle JDeveloperの拡張機能を移行します。表9-1に、拡張機能とそれを説明しているドキュメントを示します。

表9-1 Oracle JDeveloperの拡張機能

コンポーネント

拡張機能

関連項目:

Oracle SOA Suite

SOAの拡張機能

『Oracle JDeveloperのインストール』のOracle JDeveloper拡張機能の有効化に関する項を参照してください。

Oracle WebCenter Portal

WebCenter Portalの拡張機能

Oracle JDeveloperでのWebCenter Portalアセットおよびカスタム・コンポーネントの開発のWebLogic管理対象サーバー・インスタンスの作成とプロビジョニングに関する項

11. アプリケーションを管理対象サーバーにデプロイします。
詳細は、次を参照してください:

- ピュアJava EEアプリケーション: 『Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメント用アプリケーションの新しい環境へのエクスポートに関する項

- Oracle ADF: 『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のアプリケーションのデプロイに関する項

- Oracle SOA Suite: 『Oracle SOA SuiteによるSOAアプリケーションの開発』のSOAコンポジット・アプリケーションのデプロイに関する項

- Oracle WebCenter Portal: 『Oracle WebCenter Portalの管理』のWebLogic管理対象サーバーに対するアプリケーションのデプロイに関する項

9.2.3 他の環境へのアプリケーションの移行の自動化

アプリケーションの移行は、WLSTスクリプトまたはantスクリプトを使用して自動化できます。これにより、複数の環境または管理対象サーバーへのアプリケーションのデプロイ、および更新されたバージョンのアプリケーションのデプロイが容易になります。

スクリプトの使用によってアプリケーションを他の環境に移行する操作の詳細は、次を参照してください。

- ピュアJava EEアプリケーション:『WebLogic Scripting Toolの理解』のWebLogic Scripting Toolの使用に関する項

- Oracle ADF: 『Oracle ADFアプリケーションの管理』のスクリプトおよびAntを使用したデプロイに関する項

- Oracle SOA Suite: 『Oracle SOA SuiteでのSOAアプリケーションの開発』の次の各項

- 「スクリプトを使用したSOAコンポジット・アプリケーション」

- 「antスクリプトを使用したSOAコンポジット・アプリケーションの管理」

- Oracle WebCenter Portal: Oracle JDeveloperでのWebCenter Portalアセットおよびカスタム・コンポーネントの開発のWebLogic管理対象サーバー・インスタンスの作成とプロビジョニングに関する項

9.3 一般的な問題の診断

次に、アプリケーションを管理対象サーバーにデプロイする際に直面する可能性のある一般的な問題についていくつか説明します。

- 接続情報。ターゲットとなる管理対象サーバーへの接続を正しく構成していることを確認します。第9.2.2項のステップ4、5および6を参照してください。

- Oracle JDeveloperの拡張機能。Oracle JDeveloperの任意の拡張機能を移行していることを確認します。表9-1を参照してください。

- データ・ソース。JDBCデータ・ソースを正しく構成していることを確認します。第9.2.2項のステップ3を参照してください。

- セキュリティ構成。資格証明、アイデンティティ、ポリシーなどのアプリケーション・セキュリティを移行していることを確認します。第9.2.2項のステップ8を参照してください。

また、SOAアプリケーションのトラブルシューティングの詳細は、『Oracle SOA SuiteによるSOAアプリケーションの開発』の一般的なデプロイ・エラーのトラブルシューティングに関する項を参照してください。

10 アプリケーションのデプロイ

デプロイとは、アプリケーションのファイルをアーカイブ・ファイルとしてパッケージ化し、ターゲットのアプリケーション・サーバーに転送するプロセスです。この章では、Oracle Fusion Middlewareにアプリケーションをデプロイ、再デプロイおよびアンデプロイする方法について説明します。

内容は次のとおりです。

- アプリケーションのデプロイの概要

- データ・ソースの理解と管理

- Java EEアプリケーションのデプロイ、アンデプロイおよび再デプロイ

- Oracle ADFアプリケーションのデプロイ、アンデプロイおよび再デプロイ

- SOAコンポジット・アプリケーションのデプロイ、アンデプロイおよび再デプロイ

- WebCenter Portalアプリケーションのデプロイ、アンデプロイおよび再デプロイ

- デプロイメント・プランの管理

- Fusion Middleware Controlでの一般的なデプロイ・タスクについて

- デプロイされたアプリケーションでのMDS構成属性の変更

10.1 アプリケーションのデプロイの概要

Oracle WebLogic Serverには、Java EEに準拠したインフラストラクチャが用意されており、Java EEに準拠したアプリケーションやモジュールのデプロイ、アンデプロイおよび再デプロイが可能です。

次の項目について説明します。

- デプロイ可能なアプリケーションのタイプ

- デプロイ、再デプロイおよびアンデプロイの理解

10.1.1 デプロイ可能なアプリケーションのタイプ

Oracle WebLogic Serverにデプロイできるコンポーネントは次のとおりです。

- Enterprise Archive (EAR)ファイルとしてパッケージ化された完全なJava EEアプリケーション。

- Webサービス、Enterprise JavaBeans (EJB)、アプリケーション・クライアント(CAR)またはリソース・アダプタ(RAR)を含む、Java Archive (JAR)ファイルとしてパッケージ化されたスタンドアロン・モジュール。

- ADFアプリケーション。Oracle Application Development Framework (Oracle ADF)は、Java Platform, Enterprise Edition (Java EE)標準やオープンソース・テクノロジに基づいて、サービス指向アプリケーションの実装を簡略化および高速化するエンドツーエンド・アプリケーション・フレームワークです。

- Oracle SOA Suiteコンポジット・アプリケーション。SOAコンポジット・アプリケーションは単一のデプロイ単位で、SOAアプリケーションの管理やライフサイクルを大幅に簡素化します。

- Oracle WebCenter Portalアプリケーション。WebCenter Portalアプリケーションが従来のJava EEアプリケーションと異なる点は、アプリケーションのページ、これらのページに含まれるポートレット、ドキュメント・ライブラリなどのランタイム・カスタマイズをサポートすることです。

メタデータ・アーカイブ(MAR)とは、アプリケーションレベルのデプロイ・プロファイルなどの、アプリケーションについて選択したメタデータを圧縮したアーカイブです。MARは、メタデータ・コンテンツをメタデータ・サービス(MDS)リポジトリにデプロイする際に使用します。次のアプリケーションのタイプでは、MDSリポジトリにデプロイされるコンテンツ(ADFアプリケーション、SOAコンポジット・アプリケーション、Oracle WebCenter Portalアプリケーション)のコンテナとしてMARを使用します。

注意:
アプリケーションレベルのデータ・ソースで間接パスワードを使用している場合、Fusion Middleware Controlを使用してアプリケーションをデプロイすることはできません。Fusion Middleware Controlを使用してアプリケーションをデプロイできるように、アプリケーションの設定を変更する方法については、Oracle JDeveloperのヘルプにある、Oracle WebLogic Serverで実行されているEARファイルにアプリケーションをデプロイする方法に関する項を参照してください。

アプリケーションのデプロイ、アンデプロイ、および再デプロイには、Fusion Middleware Control、Oracle WebLogic Server管理コンソール、Oracle JDeveloper、またはコマンド行を使用できます。使用する方法は、アプリケーションのタイプによって異なります(表10-1を参照)。

表10-1 アプリケーションをデプロイするツール

アプリケーションのタイプ

使用するツール

ピュアJava EEアプリケーション

Oracle WebLogic Server管理コンソール

Fusion Middleware Control: デプロイメント・ウィザード

Oracle JDeveloper

WLSTコマンド行

ADFアプリケーション

Fusion Middleware Control: デプロイメント・ウィザード

Oracle JDeveloper

WLSTコマンド行

SOAコンポジット・アプリケーション

Fusion Middleware Control: 「SOAコンポジット・デプロイ」ウィザード

Oracle JDeveloper

WLSTコマンド行

WebCenter Portalアプリケーション

Fusion Middleware Control: デプロイメント・ウィザード

Oracle JDeveloper

WLSTコマンド行

アプリケーションでMDSリポジトリを使用している場合、アプリケーションをデプロイする前にリポジトリをOracle WebLogic Serverドメインに登録する必要があります。組織で独自に開発したカスタムJava EEアプリケーション、Oracle B2BやOracle Web Services Managerなどの一部のOracle Fusion Middlewareコンポーネント・アプリケーションなどは、MDSリポジトリを使用します。MDSリポジトリおよびリポジトリの登録の詳細は、第14.3項を参照してください。

注意:
アプリケーションにアプリケーションレベルの資格証明ストアが含まれており、アプリケーションをテスト環境から本番環境に移行する場合は、『Oracle Platform Security Servicesによるアプリケーションの保護』のドメイン・ポリシー・ストアの再関連付けに関する項で説明されているように、資格証明ストアを再度関連付けする必要があります。

10.1.2 デプロイ、再デプロイおよびアンデプロイの理解

アプリケーションをデプロイする場合は、アプリケーション・サーバーに初めてデプロイします。

アプリケーションを再デプロイする場合は、次を実行できます。

- 新しいバージョンのアプリケーションの再デプロイ。以前のバージョンも引き続き使用できますが、状態は「リタイア」に設定されます。
これは、本番の再デプロイ戦略と呼ばれています。Oracle WebLogic Serverでは、クライアントの接続が自動的に管理され、新しいクライアント・リクエストのみが新しいバージョンに転送されるようになります。再デプロイ時にアプリケーションに接続していたクライアントは、その処理が完了するまで古いバージョンのアプリケーションを使用し続けます。その処理が完了した時点でOracle WebLogic Serverは自動的に古いアプリケーションをリタイアさせます。

- 同じバージョンのアプリケーションの再デプロイまたはバージョンが割り当てられていないアプリケーションの再デプロイ。選択したアプリケーションのバージョンは新しいデプロイに置き換えられます。

- 以前のバージョンのアプリケーションの再デプロイ。リタイアした古い方のバージョンは「アクティブ」に設定され、新しい方のバージョンは「リタイア」に設定されます。

アプリケーションをアンデプロイする場合、Oracle WebLogic Serverはアプリケーションを停止して、ステージング済のファイルをターゲット・サーバーから削除します。デプロイに使用された元のソース・ファイルは削除しません。

10.2 データ・ソースの理解と管理

次の各項では、データ・ソースとそれらの管理方法について説明します。

- データ・ソースの理解

- JDBCデータ・ソースの作成と管理

10.2.1 データ・ソースの理解

データ・ソースは、リレーショナル・データベースへの接続を取得するためにアプリケーション・コンポーネントで使用するJavaオブジェクトです。URLやユーザー名とパスワードなどの特定の接続情報は、データ・ソース・オブジェクトでプロパティとして設定されるため、アプリケーション・コードで明示的に定義する必要はありません。この抽象化により、アプリケーションが特定のバックエンド・データベースに関連付けらなくなるため、アプリケーションをポータブルな方法で構築できます。データベースを変更しても、アプリケーション・コードに影響はありません。

アプリケーションは、Java Naming and Directory Interface (JNDI) APIを使用してデータ・ソース・オブジェクトにアクセスします。アプリケーションは、データ・ソース・オブジェクトにバインドされたJNDI名を使用します。JNDI名は論理名であるため、すべてのデータ・ソース・オブジェクトにマップできます。データ・ソース・プロパティと同様に、データ・ソース・オブジェクトを変更してもアプリケーション・コードを変更する必要がないため、JNDIを使用すると抽象レベルが上がります。結果として、データベースへのアクセスの詳細が、アプリケーションに対して透過的になります。

データ・ソースの詳細は、『 Oracle WebLogic Server JDBCデータ・ソースの管理』を参照してください。

Oracle SOA Suiteなど、特定のOracle Fusion Middlewareコンポーネントを構成する場合は、Oracle WebLogic Server構成ウィザードを使用して、データ・ソースの接続情報を指定します。コンポーネントでMDSリポジトリを使用している場合、構成ウィザードではデータ・ソース名の先頭にmds-を付加して、そのデータ・ソースがMDSリポジトリで使用されるシステム・データ・ソースであることを示します。

構成ウィザードを使用してデータ・ソースを指定する方法の詳細は、構成ウィザードによるWebLogicドメインの作成を参照してください。

Oracle Real Application Clusters (Oracle RAC)またはOracle Fusion Middlewareのコールド・フェイルオーバー・クラスタを使用している場合、次のデータ・ソース・タイプのいずれかを構成する必要があります。

- マルチ・データ・ソース
マルチ・データ・ソースを使用するには、Oracle WebLogic Server管理コンソールを使用する必要があります。複数のデータ・ソースを作成し、それに既存のMDSデータ・ソースを追加した場合、追加したデータ・ソースは有効なMDSリポジトリとみなされなくなるので注意してください。リポジトリは、Fusion Middleware ControlにもOracle WebLogic Server管理コンソールにも表示されません。たとえば、MDSリポジトリはFusion Middleware Controlのナビゲーション・ペインには一覧表示されず、アプリケーションをデプロイするときにターゲットのメタデータ・リポジトリの選択肢として表示されません。

- GridLinkデータ・ソース
GridLinkデータ・ソースを使用するために、第10.2.2.5項の説明に従って、Oracle WebLogic Server管理コンソールまたはFusion Middleware Controlを使用できます。

マルチ・データ・ソースおよびGridLinkデータ・ソースの構成に関する詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』を参照してください。

10.2.2 JDBCデータ・ソースの作成と管理

JDBCデータ・ソースの作成と管理には、次の管理ツールを使用できます。

- Oracle WebLogic Server管理コンソール

- WebLogic Scripting Tool (WLST)

- Fusion Middleware Control

MDSデータ・ソースを手動で作成するには、Fusion Middleware ControlまたはWLSTを使用して、データ・ソースの正しい属性を設定する必要があります。MDSデータ・ソースは、Fusion Middleware Controlではナビゲーション・ペインに表示され、管理コンソールではドメイン構造に表示されます。アプリケーションでMDSリポジトリを使用している場合、アプリケーションをデプロイする前にリポジトリをOracle WebLogic Serverドメインに登録する必要があります。MDSリポジトリおよびリポジトリの登録の詳細は、第14.3項を参照してください。

注意:
データ・ソースを作成する場合、リポジトリ作成ユーティリティ(RCU)で作成されたMDSスキーマを使用する必要があります。それ以外のスキーマは使用しないでください。

お薦めはできませんが、Oracle WebLogic Server管理コンソールを使用して、MDSデータ・ソースを作成することもできます。その場合は、次の点に注意してください。

- MDSリポジトリでの使用を目的とする場合、データ・ソース名に接頭辞としてmds-を付ける必要があります。

- データ・ソースの対象は、管理サーバー、およびデータ・ソースが必要なアプリケーションをデプロイするすべての管理対象サーバーとする必要があります。

- グローバル・トランザクションをオフにする必要があります。

Oracle WebLogic Server管理コンソールまたはWLSTを使用してデータ・ソースを作成および管理する方法の詳細、および複数のデータ・ソースの構成の詳細は、『 Oracle WebLogic Server JDBCデータ・ソースの管理』を参照してください。

次の各項では、Fusion Middleware Controlを使用してJDBCデータ・ソースを作成および管理する方法について説明します。

- Fusion Middleware Controlを使用したJDBCデータ・ソースの作成

- Fusion Middleware Controlを使用したJDBCデータ・ソースの編集

- Fusion Middleware Controlを使用したJDBCデータ・ソースのモニタリング

- Fusion Middleware Controlを使用したJDBCデータ・ソースの管理

- Fusion Middleware Controlを使用したGridLinkデータ・ソースの作成

10.2.2.1 Fusion Middleware Controlを使用したJDBCデータ・ソースの作成

Fusion Middleware Controlを使用してJDBCデータ・ソースを作成する手順は次のとおりです。

1. 「WebLogicドメイン」メニューで「JDBCデータ・ソース」を選択します。
次の図のように「JDBCデータ・ソース」ページが表示されます。

2. 「作成」から、「汎用データ・ソース」を選択します。

3. ウィザードの指示に従って、データ・ソースのプロパティを設定し、ドメイン内の1つ以上の管理対象サーバーのデータ・ソースを対象に指定します。
個々のフィールドおよびプロパティに関するヘルプを表示するには、マウスを使用してフィールドをフォーカスします。Fusion Middleware Controlでは、フィールドの定義がポップアップで表示されます。

Fusion Middleware Controlで定義するデータ・ソース・プロパティは、Oracle WebLogic Server管理コンソールでデータ・ソースを作成するときに定義するデータ・ソース・プロパティと似ています。このため、データ・ソース・プロパティの詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの作成に関する項を参照することもできます。

10.2.2.2 Fusion Middleware Controlを使用したJDBCデータ・ソースの編集

Fusion Middleware Controlを使用して既存のJDBCデータ・ソースを編集する手順は次のとおりです。

1. 「WebLogicドメイン」メニューで「JDBCデータ・ソース」を選択します。
「JDBCデータ・ソース」ページが表示されます。

2. 編集するデータ・ソースをクリックします。
その特定のJDBCデータ・ソースのページが表示されます。

3. このページのタブを使用して、選択したデータ・ソースのプロパティを変更します。
個々のフィールドおよびプロパティに関するヘルプを表示するには、マウスを使用してフィールドをフォーカスします。Fusion Middleware Controlでは、フィールドの定義がポップアップで表示されます。

Fusion Middleware Controlで編集するデータ・ソース・プロパティは、Oracle WebLogic Server管理コンソールでデータ・ソースを編集するときに編集するデータ・ソース・プロパティと似ています。このため、データ・ソース・プロパティの詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCデータ・ソースの作成に関する項を参照することもできます。

10.2.2.3 Fusion Middleware Controlを使用したJDBCデータ・ソースのモニタリング

Fusion Middleware Controlを使用してJDBCデータ・ソースをモニターする手順は次のとおりです。

1. 「WebLogicドメイン」メニューで「JDBCデータ・ソース」を選択します。
「JDBCデータ・ソース」ページが表示されます。

2. モニターするデータ・ソースを選択します。

3. 「モニタリング」タブを選択し、JDBCデータ・ソースの統計を表示します。
このページには、選択したデータ・ソースの現在のインスタンスが表示されます。

このページに表示されるのは、実行中の管理対象サーバーを対象にしたデータ・ソースのみです。モニタリング・ページに特定のデータ・ソースが表示されていない場合は、データ・ソースを編集して、実行中の管理対象サーバーを対象にするようにします。

4. データ・ソースのインスタンスごとに、パフォーマンス・メトリックを確認します。

10.2.2.4 Fusion Middleware Controlを使用したJDBCデータ・ソースの管理

Fusion Middleware Controlを使用して、JDBCデータ・ソースの文キャッシュを開始、停止、中断、再開またはクリアするには:

1. 「WebLogicドメイン」メニューで「JDBCデータ・ソース」を選択します。
「JDBCデータ・ソース」ページが表示されます。

2. 制御するデータ・ソースを選択します

3. 「Control」タブを選択します。
このページに表示されるのは、実行中の管理対象サーバーを対象にしたデータ・ソースのみです。管理ページに特定のデータ・ソースが表示されていない場合は、データ・ソースを編集して、実行中の管理対象サーバーを対象にするようにします。

4. インスタンスを選択し、「開始」、「停止」、「再開」、「中断」、「縮小」、「リセット」または「文キャッシュのクリア」をクリックして、選択したJDBCデータ・ソースの状態を制御または変更します。
このページで選択するコマンドは、Oracle WebLogic Server管理コンソールでデータ・ソースを管理するときに使用可能なコマンドと似ています。JDBCデータ・ソース制御オプションの詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のWebLogic JDBCリソースの管理に関する項を参照してください。

10.2.2.5 Fusion Middleware Controlを使用したGridLinkデータ・ソースの作成

単一のGridLinkデータ・ソースは、Oracle RACクラスタにターゲット指定されたOracle WebLogic ServerとOracle Databaseサービス間の接続を提供します。GridLinkデータ・ソースの詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のGridLinkデータ・ソースの作成に関する項を参照してください。

Fusion Middleware Controlを使用してGrid Linkデータ・ソースを作成する手順は次のとおりです。

1. 「WebLogicドメイン」メニューで「JDBCデータ・ソース」を選択します。
「JDBCデータ・ソース」ページが表示されます。

2. 「作成」から、「GridLinkデータ・ソース」を選択します。

3. ウィザードの指示に従って、データ・ソースのプロパティを設定し、ドメイン内の1つ以上の管理対象サーバーのデータ・ソースを対象に指定します。
個々のフィールドおよびプロパティに関するヘルプを表示するには、マウスを使用してフィールドをフォーカスします。Fusion Middleware Controlでは、フィールドの定義がポップアップで表示されます。

Fusion Middleware Controlで定義するデータ・ソース・プロパティは、Oracle WebLogic Server管理コンソールでデータ・ソースを作成するときに定義するデータ・ソース・プロパティと似ています。このため、データ・ソース・プロパティの詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のGridLinkデータ・ソースの作成に関する項を参照することもできます。

10.3 Java EEアプリケーションのデプロイ、アンデプロイおよび再デプロイ

Java EEアプリケーションのデプロイ、アンデプロイおよび再デプロイには、Fusion Middleware Control、Oracle WebLogic Server管理コンソール、Oracle JDeveloperまたはコマンド行を使用できます。次の各項では、Fusion Middleware Controlおよびコマンド行を使用して、これらの作業を行う手順を説明します。

- Java EEアプリケーションのデプロイ

- Java EEアプリケーションのアンデプロイ

- Java EEアプリケーションの再デプロイ

Oracle WebLogic Server管理コンソールおよびWLSTコマンド行を使用してデプロイする方法の詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

10.3.1 Java EEアプリケーションのデプロイ

管理対象サーバー・インスタンスまたはクラスタに対して、アプリケーションをデプロイできます。この項では、管理対象サーバーにアプリケーションをデプロイする方法について説明します。次の項目が含まれます。

- Fusion Middleware Controlを使用したJava EEアプリケーションのデプロイ

- WLSTを使用したJava EEアプリケーションのデプロイ

10.3.1.1 Fusion Middleware Controlを使用したJava EEアプリケーションのデプロイ

Fusion Middleware Controlを使用してJava EEアプリケーションを管理対象サーバーにデプロイする手順は次のとおりです。

1. ナビゲーション・ペインからドメインを展開します。

2. アプリケーションをデプロイするサーバーを選択します。
サーバーのホーム・ページが表示されます。

3. 「WebLogic Server」メニューで、「デプロイメント」」を選択します。
「デプロイ」ページが表示されます。

4. 「デプロイメント」メニューから「デプロイ」を選択し、Java EEアプリケーション・アシスタントのデプロイを開きます。
次の図に示すように、「アーカイブの選択」ページが表示されます。

5. 「アーカイブまたは展開済ディレクトリ」セクションで、次のいずれかを選択します。

- アーカイブはこのブラウザが稼働しているマシンに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

- アーカイブまたは展開済ディレクトリはEnterprise Managerが稼働しているサーバーに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

6. 「デプロイ・プラン」セクションで、次のいずれかを選択できます。

- デプロイ構成が行われるとき、新規デプロイメント・プランを作成します。

- デプロイメント・プランはこのWebブラウザが稼働しているマシンに存在します。このオプションを選択した場合は、デプロイ・プランへのパスを入力します。

- デプロイメント・プランはEnterprise Managerが稼働しているサーバーに存在します。このオプションを選択した場合は、デプロイ・プランへのパスを入力します。

7. 「デプロイメント・タイプ」セクションで、次のいずれかを選択できます。

- このアーカイブまたは展開済ディレクトリをアプリケーションとしてデプロイします

- このアーカイブまたは展開済ディレクトリをライブラリとしてデプロイします

8. 「次へ」をクリックします。
「ターゲットの選択」ページが表示されます。

9. アプリケーションのデプロイ先を選択します。管理サーバー、管理対象サーバーおよびクラスタが一覧表示されます。クラスタ、クラスタ内の1つ以上の管理対象サーバー、またはクラスタに属していない管理対象サーバーを選択できます。管理サーバーもターゲットのリストに表示されていますが、管理サーバーにはアプリケーションをデプロイしないでください。管理サーバーは、Oracle WebLogic Server管理コンソールなど、管理アプリケーションのみを対象としています。

10. 「次へ」をクリックします。
「アプリケーション属性」ページが表示されます。

11. 「アプリケーション属性」セクションの「アプリケーション名」に、アプリケーション名を入力します。

12. 「Webモジュールのコンテキスト・ルート」セクションでは、Webモジュールのコンテキスト・ルートがapplication.xmlで構成されていない場合に、アプリケーションのコンテキスト・ルートを指定できます。コンテキスト・ルートは、WebモジュールのURIです。Webモジュール、またはWebサービスを含むEJBモジュールごとに、コンテキスト・ルートを指定できます。

13. 「配布」セクションで、次のいずれかを選択します。

- アプリケーションをインストールして起動(すべてのリクエストを処理)

- アプリケーションをインストールして管理モードで起動(管理リクエストのみを処理)

- インストールのみ。起動しない

14. 「その他のオプション」を展開すると、「アプリケーション・ソースのアクセス可能性」に対して次の選択肢が表示されます。

- デプロイメントのターゲットに定義されるデフォルトを使用。推奨選択です。

- このアプリケーションをすべてのターゲットにコピーします。デプロイ時には、アプリケーションのターゲットである管理サーバーにこれらのファイルが自動的にコピーされます。

- デプロイされるソースの場所からアプリケーションにアクセスできるようにします。すべてのターゲットからこの場所にアクセスできる必要があります。

15. 「その他のオプション」では、「デプロイ・プラン・ソースのアクセス可能性」に次のいずれかを選択することもできます。

- アプリケーションと同じアクセス可能性を使用します。

- デプロイ・プランをすべてのターゲットにコピーします。デプロイ時には、アプリケーションのターゲットである管理サーバーにこれらのファイルが自動的にコピーされます。

- デプロイされるソースの場所からデプロイ・プランにアクセスできるようにします。すべてのターゲットからこの場所にアクセスできる必要があります。

16. 「次へ」をクリックします。
デプロイ・ウィザードの「デプロイ設定」ページが表示されます。

17. このページでは、アプリケーションをデプロイする前の一般的なタスクを実行できます。また、デプロイメント・プランの編集またはディスクへの保存もできます。
これらのタスクの詳細は、第10.8項を参照してください。

アプリケーションのタイプに応じて、「デプロイ・タスク」セクションで次の操作ができます。

- Webモジュールの構成: 「Webモジュールの構成」行で、「タスクに移動」をクリックします。「Webモジュールの構成」ページが表示されます。「一般プロパティの構成」をクリックして、Webモジュールの一般構成を表示および編集するか、または「リソース参照のマップ」をクリックして、リソース参照をマップします。
たとえば、セッション無効化間隔、またはセッションCookieの最大保持時間を変更できます。

- EJBモジュールの構成: 「EJBモジュールの構成」行で、「タスクに移動」をクリックして、EJBデプロイメント記述子の標準的なプロパティを設定します。EJBモジュールの構成ページが表示されます。EJBプロパティの構成をクリックして、EJBの一般構成を表示および編集するか、または「リソース参照のマップ」をクリックして、リソース参照をマップします。
たとえば、空きプール内のBeanの最大数、またはネットワーク・アクセス・ポイントを構成できます。

- アプリケーション・セキュリティの構成: 「アプリケーション・セキュリティの構成」行で、「タスクに移動」をクリックします。第10.8項で説明しているように、使用しているセキュリティのタイプに応じて、様々なページが表示されます。

- 永続性の構成: 「永続性の構成」行で、「タスクに移動」をクリックして、Java Persistent API (JPA)の永続性単位を構成します。

18. 「デプロイメント・プラン」を開きます。
デプロイメント・プランを選択した場合、編集と保存ができます。デプロイメント・プランを編集してディスクリプタの値を変更した場合、その変更内容がデプロイメント・プランに保存されます。また、デプロイメント・プランには、次の構成も保存されます。

- アプリケーション属性

- Webモジュール構成

- EJB構成

MDSに関連するアプリケーション属性は、ファイルadf-config.xmlに格納されます。アプリケーション・セキュリティ属性は、weblogic-application.xmlに格納されます。

Fusion Middleware Controlでは、該当するファイルが更新され、.earファイルが再パッケージ化されます。

19. 「デプロイ」をクリックします。
Fusion Middleware Controlに処理中のメッセージが表示されます。

20. デプロイが完了したら、「閉じる」をクリックします。

アプリケーションを複数のサーバーに同時にデプロイするには、ドメインにナビゲートします。次に、「WebLogicドメイン」メニューから「アプリケーション・デプロイメント」→「デプロイ」を選択します。デプロイメント・ウィザードにサーバーを選択できるページが表示されます。

アプリケーションをクラスタにデプロイするには、クラスタを選択します。次に「クラスタ」メニューから、「アプリケーション・デプロイメント」→「デプロイ」を選択します。

10.3.1.2 WLSTを使用したJava EEアプリケーションのデプロイ

WLSTコマンド行を使用して、アプリケーションをデプロイできます。WLSTが管理サーバーに接続されている際にJava EEアプリケーションをデプロイするには、WLSTコマンドdeployを次の形式で使用します。

deploy(app_name, path [,targets] [,stageMode] [,planPath] [,options])

deployコマンドは、管理サーバーをホストするコンピュータ上で起動する必要があります。

たとえば、アプリケーションmainWebAppをデプロイするには、次のように指定します。

deploy("myApp","/scratch/applications/wlserveR/samples/server/examples/build/mainWebApp")

次の例に示すように、weblogic.deployerを使用してアプリケーションをデプロイすることもできます。

java weblogic.Deployer -adminurl http://localhost:7001
-user username -password password -deploy
-name myApp c:\localfiles\mainWebApp
-plan c:\localfiles\productionEnvPlan.xml

詳細は、次を参照してください:

- WLSTを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメント・ツールに関する項を参照

- WebLogic Server WLSTコマンド・リファレンス

10.3.2 Java EEアプリケーションのアンデプロイ

アプリケーションまたは特定のバージョンのアプリケーションは、管理対象サーバーのインスタンスまたはクラスタからアンデプロイできます。この項では、管理対象サーバーからアプリケーションをアンデプロイする方法について説明します。アプリケーションが複数のサーバーにデプロイされている場合、Fusion Middleware Controlを使用してアプリケーションをアンデプロイすると、そのアプリケーションはすべてのサーバーからアンデプロイされます。

この項には、次の項目が含まれます。

- Fusion Middleware Controlを使用したJava EEアプリケーションのアンデプロイ

- WLSTを使用したJava EEアプリケーションのアンデプロイ

10.3.2.1 Fusion Middleware Controlを使用したJava EEアプリケーションのアンデプロイ

Fusion Middleware Controlを使用して管理対象サーバーからJava EEアプリケーションをアンデプロイする手順は次のとおりです。

1. ナビゲーション・ペインで、「アプリケーションのデプロイ」を開きます。

2. アンデプロイするアプリケーションを選択します。
アプリケーションのホーム・ページが表示されます。

3. 「デプロイメント」メニューから「アンデプロイ」を選択します。

4. アプリケーションを選択します。

5. 「確認」ページで「アンデプロイ」をクリックします。
処理中のメッセージが表示されます。

6. 操作が完了したら、「閉じる」をクリックします。

また、ドメイン、管理対象サーバーまたはクラスタにナビゲートすることもできます。ターゲット・メニューから「アプリケーションのデプロイ」→「アンデプロイ」を選択します。「アプリケーションの選択」ページで、アンデプロイするアプリケーションを選択します。

10.3.2.2 WLSTを使用したJava EEアプリケーションのアンデプロイ

WLSTコマンド行を使用して、アプリケーションをアンデプロイできます。WLSTが管理サーバーに接続されている際にJava EEアプリケーションをアンデプロイするには、WLSTコマンドundeployを次の形式で使用します。

undeploy(app_name, path [,targets] [,options])

undeployコマンドは、管理サーバーをホストするコンピュータ上で起動する必要があります。

たとえば、すべてのターゲット・サーバーからアプリケーションbusinessAppをアンデプロイし、WLSTでプロセスが完了するまで60,000ミリ秒待機するように指定するには、次のように指定します。

wls:/mydomain/serverConfig> undeploy('businessApp', timeout=60000)

10.3.3 Java EEアプリケーションの再デプロイ

更新した新しいバージョンのアプリケーション、同じバージョンのアプリケーション、またはバージョンのないアプリケーションを再デプロイすることができます。アプリケーションは、クラスタまたは管理対象サーバーに再デプロイできます。

次の各項では、アプリケーションを管理対象サーバーに再デプロイする方法について説明します。

- Fusion Middleware Controlを使用したJava EEアプリケーションの再デプロイ

- WLSTを使用したJava EEアプリケーションの再デプロイ

バージョンのないアプリケーションまたは同じバージョンのアプリケーションを再デプロイする場合は、次のことに注意してください。

- 再デプロイするアーカイブのファイル名およびパスは、アプリケーションを最初にデプロイした際に使用したファイル名およびパスと同じにする必要があります。
たとえば、元のアプリケーションのファイル名およびパスが/dua0/staging/myApp.earの場合、更新されたアプリケーションは/dua0/staging/myApp.earである必要があります。

- 最初にOracle WebLogic Server管理コンソールやWLST、またはFusion Middleware Control以外の他の管理ツールを使用してアプリケーションをデプロイした場合、Fusion Middleware Controlを使用してそのアプリケーションを再デプロイすることはできません。

10.3.3.1 Fusion Middleware Controlを使用したJava EEアプリケーションの再デプロイ

Fusion Middleware Controlを使用してJava EEアプリケーションを管理対象サーバーに再デプロイする手順は次のとおりです。

1. ナビゲーション・ペインで、「アプリケーションのデプロイ」を開きます。

2. 再デプロイするアプリケーションを選択します。
アプリケーションのホーム・ページが表示されます。

3. 「ドメイン・アプリケーション・デプロイメント」メニューから、「デプロイメント」を選択します。

4. 「デプロイメント」メニューから「再デプロイ」を選択し、「Java EEアプリケーションの再デプロイ」を開きます。
「アプリケーションの選択」ページが表示されます。

5. 「次へ」をクリックします。

6. 「アーカイブまたは展開済ディレクトリ」セクションで、次のいずれかを選択します。

- 管理サーバー上にあるアプリケーションの既存のソースの場所で、アーカイブまたは展開済ディレクトリを使用します。

- アーカイブはこのブラウザが稼働しているマシンに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

- アーカイブまたは展開済ディレクトリはEnterprise Managerが稼働しているサーバーに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

7. 「デプロイ・プラン」セクションで、次のいずれかを選択できます。

- デプロイ構成が行われるとき、新規デプロイメント・プランを作成します。

- このアプリケーションの現在のデプロイ・プランを使用します。

- デプロイメント・プランはこのWebブラウザが稼働しているマシンに存在します。プランへのパスを入力するか、「参照」をクリックしてプラン・ファイルを検索します。

- デプロイメント・プランはEnterprise Managerが稼働しているサーバーに存在します。プランへのパスを入力するか、「参照」をクリックしてプラン・ファイルを検索します。

8. 「次へ」をクリックします。
「アプリケーション属性」ページが表示されます。

9. 「次へ」をクリックします。
デプロイ・ウィザードの「デプロイ設定」ページが表示されます。

10. このページでは、アプリケーションをデプロイする前の一般的なタスクを実行できます。また、デプロイメント・プランの編集またはディスクへの保存もできます。アプリケーションのタイプに応じて、「デプロイ・タスク」セクションで次の操作ができます。

- Webモジュールの構成

- アプリケーション・セキュリティの構成

- EJBモジュールの構成

- 永続性の構成

これらのタスクの詳細は、第10.8項を参照してください。

11. 「デプロイメント・プラン」を開きます。
デプロイメント・プランを選択した場合、編集と保存ができます。デプロイメント・プランを編集してディスクリプタの値を変更した場合、その変更内容がデプロイメント・プランに保存されます。また、デプロイメント・プランには、次の構成も保存されます。

- アプリケーション属性

- Webモジュール構成

- EJB構成

MDSに関連するアプリケーション属性は、ファイルadf-config.xmlに格納されます。アプリケーション・セキュリティ属性は、weblogic-application.xmlに格納されます。

Fusion Middleware Controlでは、該当するファイルが更新され、.earファイルが再パッケージ化されます。

12. 「再デプロイ」をクリックします。
処理中のメッセージが表示されます。

13. 操作が完了したら、「閉じる」をクリックします。

アプリケーションをクラスタに再デプロイするには、クラスタを選択します。次にターゲットのメニューから、「アプリケーション・デプロイメント」→「再デプロイ」を選択します。

10.3.3.2 WLSTを使用したJava EEアプリケーションの再デプロイ

WLSTコマンド行を使用して、アプリケーションを再デプロイできます。WLSTが管理サーバーに接続されている際にJava EEアプリケーションを再デプロイするには、WLSTコマンドredeployを次の形式で使用します。

redeploy(app_name [,planpath] [,options])

redeployコマンドは、管理サーバーをホストするコンピュータ上で起動する必要があります。

たとえば、アプリケーションbusinessAppをすべてのターゲット・サーバーに再デプロイするには、次のように指定します。

redeploy('businessApp')

10.4 Oracle ADFアプリケーションのデプロイ、アンデプロイおよび再デプロイ

Oracle ADFは、Java Platform, Enterprise Edition (Java EE)標準やオープンソース・テクノロジに基づいて、サービス指向アプリケーションの実装を簡略化および高速化するエンドツーエンド・アプリケーション・フレームワークです。

Oracle ADFアプリケーションのデプロイ、アンデプロイおよび再デプロイには、Fusion Middleware Control、Oracle WebLogic Server管理コンソール、Oracle JDeveloperまたはコマンド行を使用できます。次の各項では、Fusion Middleware Control、管理コンソールおよびコマンド行を使用して、これらの作業を行う手順を説明します。

- Oracle ADFアプリケーションのデプロイ

- Oracle ADFアプリケーションのアンデプロイ

- Oracle ADFアプリケーションの再デプロイ

ADFアプリケーションの開発およびOracle JDeveloperを使用したデプロイの詳細は、Oracle Application Development FrameworkによるFusion Webアプリケーションの開発を参照してください。

10.4.1 Oracle ADFアプリケーションのデプロイ

WebLogic Serverの管理対象サーバー・インスタンスまたはクラスタへ、アプリケーションをデプロイできます。この項では、管理対象サーバーにアプリケーションをデプロイする方法について説明します。また、ADFアプリケーションを含む.earファイルを作成しているものとします。

このセクションの内容は次のとおりです。

- Fusion Middleware Controlを使用したADFアプリケーションのデプロイ

- WLSTを使用したADFアプリケーションのデプロイ

- 管理コンソールを使用したADFアプリケーションのデプロイ

10.4.1.1 Fusion Middleware Controlを使用したADFアプリケーションのデプロイ

Fusion Middleware Controlを使用してOracle ADFアプリケーションをデプロイする手順は次のとおりです。

1. ナビゲーション・ペインからドメインを展開します。

2. アプリケーションをデプロイするサーバーを選択します。
サーバーのホーム・ページが表示されます。

3. 「WebLogic Server」メニューで、「デプロイメント」」を選択します。
「デプロイ」ページが表示されます。

4. 「デプロイメント」メニューから「デプロイ」を選択し、Java EEアプリケーション・アシスタントのデプロイを開きます。
「アーカイブの選択」ページが表示されます。

5. 「アーカイブまたは展開済ディレクトリ」セクションで、次のいずれかを選択します。

- アーカイブはこのブラウザが稼働しているマシンに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

- アーカイブまたは展開済ディレクトリはEnterprise Managerが稼働しているサーバーに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

6. 「デプロイ・プラン」セクションで、次のいずれかを選択できます。

- デプロイ構成が行われるとき、新規デプロイメント・プランを作成します。

- デプロイメント・プランはこのWebブラウザが稼働しているマシンに存在します。プランへのパスを入力します。

- デプロイメント・プランはEnterprise Managerが稼働しているサーバーに存在します。プランへのパスを入力します。

7. 「デプロイメント・タイプ」セクションで、次のいずれかを選択できます。

- このアーカイブまたは展開済ディレクトリをアプリケーションとしてデプロイします

- このアーカイブまたは展開済ディレクトリをライブラリとしてデプロイします

8. 「次へ」をクリックします。
「ターゲットの選択」ページが表示されます。

9. アプリケーションのデプロイ先を選択します。管理サーバー、管理対象サーバーおよびクラスタが一覧表示されます。クラスタ、クラスタ内の1つ以上の管理対象サーバー、またはクラスタに属していない管理対象サーバーを選択できます。管理サーバーもターゲットのリストに表示されていますが、管理サーバーにはアプリケーションをデプロイしないでください。管理サーバーは、Oracle WebLogic Server管理コンソールなど、管理アプリケーションのみを対象としています。

10. 「次へ」をクリックします。
次の図のように「アプリケーション属性」ページが表示されます。

11. 「アプリケーション属性」セクションの「アプリケーション名」に、アプリケーション名を入力します。

12. 「Webモジュールのコンテキスト・ルート」セクションでは、Webモジュールのコンテキスト・ルートがapplication.xmlで構成されていない場合に、アプリケーションのコンテキスト・ルートを指定できます。コンテキスト・ルートは、WebモジュールのURIです。Webモジュール、またはWebサービスを含むEJBモジュールごとに、コンテキスト・ルートを指定できます。

13. 「ターゲット・メタデータ・リポジトリ」セクションで、このアプリケーションのリポジトリおよびパーティションを選択できます。パーティション名がadf-config.xmlファイルで指定されていない場合には、デフォルトのパーティション名としてアプリケーション名にバージョンを付加したものが使用されます。これにより、使用されるパーティションはドメイン内で一意になり、異なるアプリケーションのメタデータが同じリポジトリ・パーティションに誤ってインポートされて相互に上書きされることはなくなります。通常は、アプリケーションのメタデータは、それぞれ専用のパーティションにデプロイされます。

- リポジトリを変更するには、「リポジトリ名」の横にあるアイコンをクリックします。「メタデータ・リポジトリ」ダイアログ・ボックスでリポジトリを選択し、「OK」をクリックします。

- パーティションを変更するには、「パーティション名」にパーティション名を入力します。アプリケーションごとに新しいパーティションを作成することをお薦めします。存在していないパーティションの名前を入力した場合は、そのパーティションが作成されます。

.earファイル内のadf-config.xmlファイルは、新しい情報で更新されます。

アプリケーションで指定したパーティションまたはリポジトリがドメイン内で有効でない場合は、Fusion Middleware Controlによってメッセージが表示されます。

14. MDS共有リポジトリのMDS構成がアプリケーションのadf-config.xmlファイル・アーカイブに含まれている場合には、「共有メタデータ・リポジトリ」セクションが表示されます。このセクションで、このアプリケーションのリポジトリおよびパーティションを選択できます。アプリケーションで指定したパーティションまたはリポジトリがドメイン内で有効でない場合は、Fusion Middleware Controlによってメッセージが表示されます。
リポジトリまたはパーティションを変更した場合、.earファイル内のadf-config.xmlファイルは、新しい情報で更新されます。

15. 「配布」セクションで、次のいずれかを選択します。

- アプリケーションをインストールして起動(すべてのリクエストを処理)

- 管理モードでのアプリケーションのインストールと起動(管理リクエストのみ処理)

- インストールのみ。起動しない。

16. 「その他のオプション」を展開できます。これらのオプションについては、第10.3.1項の14を参照してください。

17. 「次へ」をクリックします。
デプロイ・ウィザードの「デプロイ設定」ページが表示されます。

18. このページでは、アプリケーションをデプロイする前の一般的なタスクを実行できます。また、デプロイメント・プランの編集またはディスクへの保存もできます。アプリケーションのタイプに応じて、「デプロイ・タスク」セクションで次の操作ができます。

- Webモジュールの構成: 「Webモジュールの構成」行で、「タスクに移動」をクリックします。「Webモジュールの構成」ページが表示されます。「一般プロパティの構成」をクリックして、Webモジュールの一般構成を表示および編集するか、または「リソース参照のマップ」をクリックして、リソース参照をマップします。
たとえば、セッション無効化間隔、またはセッションCookieの最大保持時間を変更できます。

- EJBモジュールの構成: 「EJBモジュールの構成」行で、「タスクに移動」をクリックして、EJBデプロイメント記述子の標準的なプロパティを設定します。EJBモジュールの構成ページが表示されます。EJBプロパティの構成をクリックして、EJBの一般構成を表示および編集するか、または「リソース参照のマップ」をクリックして、リソース参照をマップします。
たとえば、空きプール内のBeanの最大数、またはネットワーク・アクセス・ポイントを構成できます。

- アプリケーション・セキュリティの構成: 「アプリケーション・セキュリティの構成」行で、「タスクに移動」をクリックします。第10.8項で説明しているように、使用しているセキュリティのタイプに応じて、様々なページが表示されます。

- 永続性の構成: 「永続性の構成」行で、「タスクに移動」をクリックして、Java Persistent API (JPA)の永続性単位を構成します。

- ADF接続の構成: ADF接続を変更するには、「ADF接続の構成」行で「タスクに移動」をクリックします。「ADF接続の構成」ページが開き、現在の接続情報が表示されます。接続タイプを変更するには、目的の行の「編集」アイコンをクリックします。たとえば、外部アプリケーションの接続情報を変更できます。ADF接続の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。

これらのオプションの詳細は、第10.8項を参照してください。

19. 「デプロイメント・プラン」を開きます。
デプロイメント・プランを選択した場合、編集と保存ができます。

20. 「デプロイ」をクリックします。
Fusion Middleware Controlに処理中のメッセージが表示されます。

21. デプロイが完了したら、「閉じる」をクリックします。

10.4.1.2 WLSTを使用したADFアプリケーションのデプロイ

WLSTコマンド行を使用してADFアプリケーションをデプロイする手順は次のとおりです。

1. アプリケーションでMDSリポジトリを使用している場合、アプリケーションをデプロイする前にアプリケーション・アーカイブ(.ear)ファイルを構成する必要があります。デプロイ・ターゲット・リポジトリまたは任意の共有メタデータ・リポジトリのリポジトリ情報は、WLSTのgetMDSArchiveConfigコマンドを使用して指定する必要があります。アプリケーションをデプロイする前に、指定されたリポジトリをドメインに登録しておく必要があります。次の例では、このコマンドを使用してMDSArchiveConfigを取得し、setAppMetadataRepositoryメソッドをコールしてデプロイ・ターゲット・リポジトリを設定する方法を示します。そうしないと、アプリケーションが起動しません。

wls:/offline> archive = getMDSArchiveConfig(fromLocation='/tmp/App1.ear')
wls:/offline> archive.setAppMetadataRepository(repository='AppRepos1',
partition='partition1', type='DB', jndi='mds-jndi1')

この操作では、アーカイブ・ファイル内のadf-config.xmlファイルのMDS構成部分に変更が配置されます。

2. 次のコマンドを使用して、変更を元の.earファイルに保存します。

wls:/offline> archive.save()

3. アプリケーションをデプロイします。
WLSTが管理サーバーに接続されている際にアプリケーションをデプロイするには、WLSTコマンドdeployを次の形式で使用します。

deploy(app_name, path [,targets] [,stageMode] [,planPath] [,options])

deployコマンドは、管理サーバーをホストするコンピュータ上で起動する必要があります。

たとえば、アプリケーションmyAppをデプロイするには、次のように指定します。

deploy("myApp","/scratch/applications/myApp", targets='myserver', timeout=120000))

詳細は、次を参照してください:

- WLSTを使用したアプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のデプロイメント・ツールに関する項を参照

- WebLogic Server WLSTコマンド・リファレンス

10.4.1.3 管理コンソールを使用したADFアプリケーションのデプロイ

Oracle WebLogic Server管理コンソールを使用してアプリケーションをデプロイする手順は次のとおりです。

1. まだ行っていない場合は、管理コンソールのチェンジ・センターで「ロックして編集」をクリックします。

2. 管理コンソールの左ペインで、「デプロイメント」を選択します。

3. 右ペインで、「インストール」をクリックします。

10.4.2 Oracle ADFアプリケーションのアンデプロイ

Fusion Middleware Controlを使用してOracle ADFアプリケーションをアンデプロイする手順は次のとおりです。

1. ナビゲーション・ペインで、「アプリケーションのデプロイ」を開きます。

2. アンデプロイするアプリケーションを選択します。
アプリケーションのホーム・ページが表示されます。

3. 「ドメイン・アプリケーション・デプロイメント」メニューから、「デプロイメント」を選択します。

4. 「デプロイメント」メニューから「アンデプロイ」を選択します。

5. 「確認」ページで「アンデプロイ」をクリックします。
処理中のメッセージが表示されます。

6. 操作が完了したら、「閉じる」をクリックします。

また、ドメイン、管理対象サーバーまたはクラスタにナビゲートすることもできます。ターゲット・メニューから「アプリケーションのデプロイ」→「アンデプロイ」を選択します。「アプリケーションの選択」ページで、アンデプロイするアプリケーションを選択します。

アプリケーションをアンデプロイしても、MDSパーティションに格納されているドキュメントは削除されません。

10.4.3 Oracle ADFアプリケーションの再デプロイ

アプリケーションを再デプロイする際に、アプリケーションにメタデータ・アーカイブ(MAR)が含まれていると、MARの内容は、MARが変更されている場合にのみ、アプリケーションのメタデータ・リポジトリにインポートされます。MARがアプリケーションの前回のデプロイから変更されていない場合は無視されます。

バージョンのないアプリケーションまたは同じバージョンのアプリケーションを再デプロイする場合は、次のことに注意してください。

- 再デプロイするアーカイブのファイル名およびパスは、アプリケーションを最初にデプロイした際に使用したファイル名およびパスと同じにする必要があります。
たとえば、元のアプリケーションのファイル名およびパスが/dua0/staging/myApp.earの場合、更新されたアプリケーションは/dua0/staging/myApp.earである必要があります。

- 最初にOracle WebLogic Server管理コンソールやWLST、またはFusion Middleware Control以外の他の管理ツールを使用してアプリケーションをデプロイした場合、Fusion Middleware Controlを使用してそのアプリケーションを再デプロイすることはできません。

Fusion Middleware Controlを使用してOracle ADFアプリケーションを再デプロイする手順は次のとおりです。

1. ナビゲーション・ペインで、「アプリケーションのデプロイ」を開きます。

2. 再デプロイするアプリケーションを選択します。
アプリケーションのホーム・ページが表示されます。

3. 「ドメイン・アプリケーション・デプロイメント」メニューから、「デプロイメント」を選択します。

4. 「デプロイメント」メニューから「再デプロイ」を選択します。

5. 「次へ」をクリックします。
「アーカイブの選択」ページが表示されます。

6. 「アーカイブまたは展開済ディレクトリ」セクションで、次のいずれかを選択します。

- 管理サーバー上にあるアプリケーションの既存のソースの場所で、アーカイブまたは展開済ディレクトリを使用します。

- アーカイブはこのブラウザが稼働しているマシンに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

- アーカイブまたは展開済ディレクトリはEnterprise Managerが稼働しているサーバーに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

7. 「デプロイ・プラン」セクションで、次のいずれかを選択できます。

- デプロイ構成が行われるとき、新規デプロイメント・プランを作成します。

- デプロイメント・プランはこのWebブラウザが稼働しているマシンに存在します。プランへのパスを入力します。

- デプロイメント・プランはEnterprise Managerが稼働しているサーバーに存在します。プランへのパスを入力します。

8. 「次へ」をクリックします。
「アプリケーション属性」ページが表示されます。

9. 「アプリケーション属性」セクションの「アプリケーション名」に、アプリケーション名を入力します。

10. 「Webモジュールのコンテキスト・ルート」セクションでは、Webモジュールのコンテキスト・ルートがapplication.xmlで構成されていない場合に、アプリケーションのコンテキスト・ルートを指定できます。コンテキスト・ルートは、WebモジュールのURIです。Webモジュール、またはWebサービスを含むEJBモジュールごとに、コンテキスト・ルートを指定できます。

11. 「ターゲット・メタデータ・リポジトリ」セクションが表示されます。このセクションで、このアプリケーションのリポジトリおよびパーティションを選択できます。

- リポジトリを変更するには、「リポジトリ名」の横にあるアイコンをクリックします。「メタデータ・リポジトリ」ダイアログ・ボックスでリポジトリを選択し、「OK」をクリックします。

- パーティションを変更するには、「パーティション名」にパーティション名を入力します。アプリケーションごとに新しいパーティションを作成することをお薦めします。存在していないパーティションの名前を入力した場合は、そのパーティションが作成されます。

12. MDS共有リポジトリのMDS構成がアプリケーションのadf-config.xmlファイル・アーカイブに含まれている場合には、「共有メタデータ・リポジトリ」セクションが表示されます。このセクションで、このアプリケーションのリポジトリおよびパーティションを選択できます。

13. 「次へ」をクリックします。
「デプロイ設定」ページが表示されます。

14. このページでは、アプリケーションをデプロイする前の一般的なタスクを実行できます。また、デプロイメント・プランの編集またはディスクへの保存もできます。「デプロイ・タスク」セクションで次の操作ができます。

- Webモジュールの構成

- アプリケーション・セキュリティの構成

- 永続性の構成

これらのオプションの詳細は、第10.8項を参照してください。

15. 「デプロイメント・プラン」を開きます。
デプロイメント・プランを選択した場合、編集と保存ができます。

16. 「デプロイ」をクリックします。
Fusion Middleware Controlに処理中のメッセージが表示されます。

17. デプロイが完了したら、「閉じる」をクリックします。

18. 確認ページで、「再デプロイ」をクリックします。

10.5 SOAコンポジット・アプリケーションのデプロイ、アンデプロイおよび再デプロイ

SOAコンポジット・アプリケーションは、次のコンポーネントで構成されます。

- ルーティングを処理するOracle Mediator、全体を統括するBPELプロセス、ワークフローを承認する人間のタスク、ビジネスの意思決定を設計するビジネス・ルール、イベント・ストリームを問い合せる複合イベント処理などのサービス・コンポーネント

- 外部のサービス、アプリケーションおよびテクノロジに対してSOAコンポジット・アプリケーションを接続するバインディング・コンポーネント(サービスと参照)

これらのコンポーネントを集合させたものがSOAコンポジット・アプリケーションです。このアプリケーションは単一のデプロイ単位で、SOAアプリケーションの管理やライフサイクルを大幅に簡素化します。

SOAアプリケーションのデプロイ、アンデプロイおよび再デプロイには、Fusion Middleware Control、Oracle JDeveloperまたはコマンド行を使用できます。次の各項では、Fusion Middleware Controlを使用して、これらの作業を行う手順を説明します。

- SOAコンポジット・アプリケーションのデプロイ

- SOAコンポジット・アプリケーションのアンデプロイ

- SOAコンポジット・アプリケーションの再デプロイ

詳細は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理を参照してください。

10.5.1 SOAコンポジット・アプリケーションのデプロイ

SOAコンポジット・アプリケーションをデプロイする場合、デプロイによってSOAインフラストラクチャのコンポジット・アプリケーションが抽出されてアクティブ化されます。

SOAコンポジット・アプリケーションは、Fusion Middleware Controlから「SOAコンポジットのデプロイ」ウィザードを使用してデプロイできます。

1. ナビゲーション・ペインで、「SOA」を展開してから、「soa-infra」を選択します。
SOAインフラストラクチャのホーム・ページが表示されます。

2. 「SOAインフラストラクチャ」メニューから、「SOAデプロイ」→「デプロイ」を選択します。
次の図のように、デプロイメント・ウィザードの「アーカイブの選択」ページが表示されます。

3. 「アーカイブまたは展開済ディレクトリ」セクションで、次のいずれかを選択します。

- アーカイブはこのブラウザが稼働しているマシンに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

- アーカイブまたは展開済ディレクトリはEnterprise Managerが稼働しているサーバーに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。
デプロイするSOAコンポジット・アプリケーションのアーカイブを指定できます。アーカイブには、デプロイするアプリケーションのプロジェクト・ファイルが含まれています(単一アーカイブ用のHelloWorld_rev1.0.jarや複数アーカイブ用のOrderBooking_rev1.0.zipなど)。

4. 「構成プラン」セクションで、アーカイブに含める構成プランを指定します(オプション)。構成プランには、異なる環境で使用するURLとプロパティ値を定義できます。構成プランは、プロセスのデプロイメント時に、プロジェクトを別のターゲット環境に適合させるために置換する必要のある値に関するSOAプロジェクトを検索する際に使用されます。

5. 「次へ」をクリックします。
「ターゲットの選択」ページが表示されます。

6. SOAパーティション・セクションで、このSOAコンポジット・アプリケーションをデプロイする先のパーティションを選択します。パーティションを使用すると、SOAコンポジット・アプリケーションを異なるセクションに論理的にグループ化できます。使用可能なパーティションが1つのみである場合も、そのパーティションを明示的に選択する必要があります。デプロイした後は、コンポジットを別のパーティションに転送できなくなります。

7. 「次へ」をクリックします。
確認ページが表示されます。

8. 選択内容を確認します。

9. SOAコンポジット・アプリケーションをデフォルト・リビジョンとしてデプロイするかどうかを選択します。デフォルト・リビジョンは、新しいリクエストを受信する際にインスタンス化されます。

10. 「デプロイ」をクリックします。
処理中のメッセージが表示されます。

11. デプロイが完了したら、「確認」ボックスを閉じます。

SOAコンポジット・アプリケーションのデプロイに関する詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のアプリケーションのデプロイに関する項を参照してください。

10.5.2 SOAコンポジット・アプリケーションのアンデプロイ

SOAコンポジット・アプリケーションは、Fusion Middleware Controlから「SOAコンポジットのアンデプロイ」ウィザードを使用してアンデプロイできます。

1. ナビゲーション・ペインで、「SOA」を展開してから、「soa-infra」を選択します。
SOAインフラストラクチャのホーム・ページが表示されます。

2. 「SOAインフラストラクチャ」メニューから、「SOAデプロイ」→「アンデプロイ」を選択します。

3. アンデプロイするコンポジットを選択して、「次へ」をクリックします。

4. 選択内容を確認します。問題ない場合、「アンデプロイ」をクリックします。
処理中のメッセージが表示されます。

5. アンデプロイが完了したら、「確認」ウィンドウを閉じます。

SOAコンポジット・アプリケーションのアンデプロイに関する詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のアプリケーションのアンデプロイに関する項を参照してください。

10.5.3 SOAコンポジット・アプリケーションの再デプロイ

SOAコンポジット・アプリケーションは、Fusion Middleware Controlから「SOAコンポジットの再デプロイ」ウィザードを使用して再デプロイできます。

1. ナビゲーション・ペインで、「SOA」を展開してから、「soa-infra」を選択します。
SOAインフラストラクチャのホーム・ページが表示されます。

2. 「SOAインフラストラクチャ」メニューから、「SOAデプロイ」→「再デプロイ」を選択します。
「コンポジットの選択」ページが表示されます。

3. 再デプロイするコンポジットを選択します。

4. 「次へ」をクリックします。
「アーカイブの選択」ページが表示されます。

5. 「アーカイブまたは展開済ディレクトリ」セクションで、再デプロイするSOAコンポジット・アプリケーション・リビジョンの場所を選択します。

6. 「構成プラン」セクションで、アーカイブに含める構成プランを指定します(オプション)。

7. 「次へ」をクリックします。
確認ページが表示されます。

8. SOAコンポジット・アプリケーションをデフォルト・リビジョンとして再デプロイするかどうかを選択します。

9. 「再デプロイ」をクリックします。
処理中のメッセージが表示されます。

10. 再デプロイが完了したら、「閉じる」をクリックします。

SOAコンポジット・アプリケーションの再デプロイに関する詳細は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のアプリケーションの再デプロイに関する項を参照してください。

10.6 WebCenter Portalアプリケーションのデプロイ、アンデプロイおよび再デプロイ

Oracle WebCenter Portalアプリケーションが従来のJava EEアプリケーションと異なる点は、アプリケーションのページ、これらのページに含まれるポートレット、ドキュメント・ライブラリなどのランタイム・カスタマイズをサポートすることです。カスタマイズは次のように保存されます。

- WebCenter Portalアプリケーションのカスタマイズは、データベースにインストールされたOracle Metadata Services (MDS)に保存されます。

- ポートレット・プロデューサのカスタマイズ(プリファレンス)は、通常はデータベース・プリファレンス・ストアに保存されます。

WebCenter Portalアプリケーションのデプロイ、アンデプロイまたは再デプロイには、Fusion Middleware Control、Oracle JDeveloperまたはコマンド行を使用できます。次の各項では、Fusion Middleware Controlを使用して、これらの作業を行う手順を説明します。

- WebCenter Portalアプリケーションのデプロイ

- WebCenter Portalアプリケーションのアンデプロイ

- WebCenter Portalアプリケーションの再デプロイ

関連項目:
Oracle WebCenter Portalの管理

10.6.1 WebCenter Portalアプリケーションのデプロイ

アプリケーションをJDeveloperの外部にある管理対象サーバーにデプロイするには、まずアプリケーションのデプロイメント・プランを作成する必要があります。Oracle JDeveloperで、プロジェクトレベルのデプロイメント・プロファイルを作成してから、アプリケーションレベルのデプロイメント・プロファイルを作成します。プロジェクトレベルのデプロイメント・プロファイルは、Web Application Archive (WAR)ファイルとしてパッケージ化されます。アプリケーションレベルのデプロイメント・プロファイルは、Metadata Archive (MAR)としてパッケージ化されます。1つのMARに、複数のプロジェクトのメタデータ・コンテンツを格納できます。MARファイルは、メタデータ・コンテンツをMDSリポジトリにデプロイする際に使用します。Oracle JDeveloperによるデプロイメント・プランの作成の詳細は、Oracle JDeveloperでのWebCenter Portalアセットおよびカスタム・コンポーネントの開発を参照してください。

Oracle WebCenter Portalアプリケーションのデプロイの詳細は、『Oracle WebCenter Portalの管理』のWebCenter Portalフレームワーク・アプリケーションのデプロイに関する項を参照してください。

Fusion Middleware Controlを使用してOracle WebCenter Portalアプリケーションを管理対象サーバーにデプロイする手順は次のとおりです。

1. ナビゲーション・ペインからドメインを展開します。

2. アプリケーションをデプロイするドメインを選択します。
サーバーのホーム・ページが表示されます。

3. 「WebLogicドメイン」メニューから、「セキュリティ」→「デプロイ」を選択します。

4. 「デプロイメント」メニューから「デプロイ」を選択し、Java EEアプリケーション・アシスタントのデプロイを開きます。
デプロイ・ウィザードの「アーカイブの選択」ページが表示されます。

5. 「アーカイブまたは展開済ディレクトリ」セクションで、次のいずれかを選択します。

- アーカイブはこのブラウザが稼働しているマシンに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

- アーカイブまたは展開済ディレクトリはEnterprise Managerが稼働しているサーバーに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

6. 「デプロイ・プラン」セクションで、次のいずれかを選択できます。

- デプロイ構成が行われるとき、新規デプロイメント・プランを作成します。

- デプロイメント・プランはこのWebブラウザが稼働しているマシンに存在します。プランへのパスを入力します。

- デプロイメント・プランはEnterprise Managerが稼働しているサーバーに存在します。プランへのパスを入力します。

7. 「次へ」をクリックします。
「ターゲットの選択」ページが表示されます。

8. アプリケーションのデプロイ先を選択します。
クラスタ、クラスタ内の1つ以上の管理対象サーバー、またはクラスタに属していない管理対象サーバーを選択できます。

9. 「次へ」をクリックします。
「アプリケーション属性」ページが表示されます。

10. 「アプリケーション属性」セクションの「アプリケーション名」に、アプリケーション名を入力します。

11. 「Webモジュールのコンテキスト・ルート」セクションで、アプリケーションのコンテキスト・ルートをapplication.xmlで指定済でない場合は指定します。コンテキスト・ルートは、WebモジュールのURIです。Webモジュール、またはWebサービスを含むEJBモジュールごとに、コンテキスト・ルートを指定できます。

12. 「ターゲット・メタデータ・リポジトリ」セクションで、このアプリケーションのリポジトリおよびパーティションを選択できます。アプリケーションで指定したパーティションまたはリポジトリがドメイン内で有効でない場合は、Fusion Middleware Controlによってメッセージが表示されます。

- リポジトリを変更するには、「リポジトリ名」の横にあるアイコンをクリックします。「メタデータ・リポジトリ」ダイアログ・ボックスでリポジトリを選択し、「OK」をクリックします。

- パーティションを変更するには、「パーティション名」にパーティション名を入力します。アプリケーションごとに新しいパーティションを作成することをお薦めします。存在していないパーティションの名前を入力した場合は、そのパーティションが作成されます。
各アプリケーションには、リポジトリ内で一意のパーティションを指定する必要があります。

13. 「次へ」をクリックします。
デプロイ・ウィザードの「デプロイ設定」ページが表示されます。

14. このページでは、アプリケーションをデプロイする前の一般的なタスクを実行できます。また、デプロイメント・プランの編集またはディスクへの保存もできます。アプリケーションのタイプに応じて、「デプロイ・タスク」セクションで次の操作ができます。

- Webモジュールの構成: 「Webモジュールの構成」行で、「タスクに移動」をクリックします。「Webモジュールの構成」ページが表示されます。「一般プロパティの構成」をクリックして、Webモジュールの一般構成を表示および編集するか、または「リソース参照のマップ」をクリックして、リソース参照をマップします。
たとえば、セッション無効化間隔、またはセッションCookieの最大保持時間を変更できます。

- EJBモジュールの構成: 「EJBモジュールの構成」行で、「タスクに移動」をクリックして、EJBデプロイメント記述子の標準的なプロパティを設定します。EJBモジュールの構成ページが表示されます。EJBプロパティの構成をクリックして、EJBの一般構成を表示および編集するか、または「リソース参照のマップ」をクリックして、リソース参照をマップします。
たとえば、空きプール内のBeanの最大数、またはネットワーク・アクセス・ポイントを構成できます。

- アプリケーション・セキュリティの構成: 「アプリケーション・セキュリティの構成」行で、「タスクに移動」をクリックします。第10.8項で説明しているように、使用しているセキュリティのタイプに応じて、様々なページが表示されます。

- 永続性の構成: 「永続性の構成」行で、「タスクに移動」をクリックして、Java Persistent API (JPA)の永続性単位を構成します。

- ADF接続の構成: ADF接続を変更するには、「ADF接続の構成」行で「タスクに移動」をクリックします。「ADF接続の構成」ページが開き、現在の接続情報が表示されます。接続タイプを変更するには、目的の行の「編集」アイコンをクリックします。

これらのオプションの詳細は、第10.8項を参照してください。

15. 「デプロイメント・プラン」を開きます。
デプロイメント・プランを選択した場合、編集と保存ができます。

16. 「デプロイ」をクリックします。
Fusion Middleware Controlに処理中のメッセージが表示されます。

17. デプロイが完了したら、「閉じる」をクリックします。

10.6.2 WebCenter Portalアプリケーションのアンデプロイ

WebCenter Portalアプリケーションをアンデプロイする手順は次のとおりです。

1. ナビゲーション・ペインで、「アプリケーションのデプロイ」を開き、アンデプロイするアプリケーションを選択します。
アプリケーションのホーム・ページが表示されます。

2. 「デプロイメント」メニューから「アンデプロイ」を選択し、Java EEアプリケーション・アシスタントのデプロイを開きます。
確認ページが表示されます。

3. 「アンデプロイ」をクリックします。
処理中のメッセージが表示されます。

4. 操作が完了したら、「閉じる」をクリックします。

また、ドメイン、管理対象サーバーまたはクラスタにナビゲートすることもできます。ターゲット・メニューから「アプリケーションのデプロイ」→「アンデプロイ」を選択します。「アプリケーションの選択」ページで、アンデプロイするアプリケーションを選択します。

10.6.3 WebCenter Portalアプリケーションの再デプロイ

WebCenter Portalアプリケーションを再デプロイする手順は次のとおりです。

1. ナビゲーション・ペインからドメインを展開します。

2. アプリケーションを再デプロイするサーバーを選択します。
サーバーのホーム・ページが表示されます。

3. 「WebLogic Server」メニューで、「デプロイメント」」を選択します。
「デプロイ」ページが表示されます。再デプロイできるのは、バージョニング済のアプリケーションのみです。バージョニングされていないアプリケーションの場合は、アンデプロイしてから再デプロイする必要があります。

4. 再デプロイするアプリケーションを選択します。

5. 「デプロイメント」メニューから「再デプロイ」を選択し、Java EEアプリケーション・アシスタントのデプロイを開きます。

6. 「次へ」をクリックします。
「アプリケーションの再デプロイ」ページが表示されます。

7. 「次へ」をクリックします。
「アーカイブの選択」ページが表示されます。

8. 「アーカイブまたは展開済ディレクトリ」セクションで、次のいずれかを選択します。

- アーカイブはこのブラウザが稼働しているマシンに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

- アーカイブまたは展開済ディレクトリはEnterprise Managerが稼働しているサーバーに存在します。アーカイブの場所を入力するか、「参照」をクリックしてアーカイブ・ファイルを検索します。

9. 「デプロイ・プラン」セクションで、次のいずれかを選択できます。

- デプロイ構成が行われるとき、新規デプロイメント・プランを作成します。

- このアプリケーションの現在のデプロイ・プランを使用します。

- デプロイメント・プランはこのWebブラウザが稼働しているマシンに存在します。プランへのパスを入力します。

- デプロイメント・プランはEnterprise Managerが稼働しているサーバーに存在します。プランへのパスを入力します。

10. 「次へ」をクリックします。
「アプリケーション属性」ページが表示されます。

11. 「アプリケーション属性」セクションの「アプリケーション名」に、アプリケーション名を入力します。

12. 「Webモジュールのコンテキスト・ルート」セクションで、アプリケーションのコンテキスト・ルートをapplication.xmlで指定済でない場合は指定します。コンテキスト・ルートは、WebモジュールのURIです。Webモジュール、またはWebサービスを含むEJBモジュールごとに、コンテキスト・ルートを指定できます。

13. 「ターゲット・メタデータ・リポジトリ」セクションで「MDSリポジトリ」を選択し、「パーティション名」にパーティション名を入力します。アプリケーションを最初にデプロイしたときに使用したものと同じリポジトリ接続およびパーティション名を使用してください。そうしなければ、すべてのカスタマイズが失われます。

14. 「次へ」をクリックします。
「デプロイ設定」ページが表示されます。

15. このページでは、アプリケーションをデプロイする前の一般的なタスクを実行できます。また、デプロイメント・プランの編集またはディスクへの保存もできます。「デプロイ・タスク」セクションで次の操作ができます。

- Webモジュールの構成

- アプリケーション・セキュリティの構成

- 永続性の構成

これらのオプションの詳細は、第10.8項を参照してください。

16. 「デプロイメント・プラン」を開きます。
デプロイメント・プランを選択した場合、編集と保存ができます。

17. 「再デプロイ」をクリックします。
Fusion Middleware Controlに処理中のメッセージが表示されます。

18. デプロイが完了したら、「閉じる」をクリックします。

10.7 デプロイメント・プランの管理

デプロイ・プランは、アーカイブをOracle WebLogic Serverにデプロイするために必要な構成データのすべてをクライアント側でまとめたものです。デプロイ・プランにより、構成設定の保存済セットを使用して、アプリケーションを容易にデプロイまたは再デプロイできます。

第10.3.1項で説明されているように、デプロイ時に既存のデプロイメント・プランをアプリケーションに適用しない場合、デフォルトでは新しいデプロイメント・プランが作成されます。作成されたデプロイメント・プランはファイルとして保存し、そのアプリケーションの再デプロイや他のアプリケーションのデプロイに再利用できます。

ただし、アプリケーションのデプロイ後にその構成を変更する場合(たとえば、アプリケーションのMDS構成を変更する場合)、保存した既存のデプロイメント・プランは、デプロイされたアプリケーションの構成設定を表さなくなります。

そのような場合、デプロイされたアプリケーションの構成をより綿密に表す新しいデプロイメント・プランをフェッチできます。

現在デプロイされているアプリケーションのデプロイ・プランをフェッチする手順は次のとおりです。

1. 「WebLogicドメイン」メニューから、「デプロイメント」を選択します。

2. 現在デプロイされているアプリケーションのリストからアプリケーションを選択します。

3. 「デプロイメント」メニューから「デプロイ・プランのフェッチ」を選択します。
「デプロイメント・プランのフェッチ」ページが表示されます。

4. デプロイメント・プランの保存先を選択して、「フェッチ」をクリックします。
デプロイ・プランは、Webブラウザが実行されているコンピュータまたはFusion Middleware Controlが実行されているコンピュータに保存できます。

5. 表示されたダイアログ・ボックスで、デプロイメント・プランが保存されたディレクトリの場所を指定します。
これで、このデプロイメント・プランを使用し、現在アプリケーションで使用中の構成で、後でアプリケーションをデプロイまたは再デプロイできるようになりました。

また、アプリケーション・デプロイメント・ウィザードの「デプロイ設定」ページでデプロイメント・プランを編集することもできます。

10.8 Fusion Middleware Controlでの一般的なデプロイ・タスクについて

Fusion Middleware Controlを使用してアプリケーションをデプロイする場合、アプリケーションをデプロイする前に、デプロイメント・ウィザードの「デプロイ設定」ページを使用して、具体的なデプロイ構成タスクを実行できます。

デプロイするアプリケーションのタイプに応じて「デプロイ設定」ページに表示できるデプロイ・タスクについて、次に説明します。

Webモジュールの構成

このデプロイ・タスクは、Webモジュールを含むアプリケーションをデプロイする場合に使用できます。これは、ほとんどの場合、アプリケーションにWebアプリケーション・デプロイメント記述子(web.xmlまたはweblogic.xml)が含まれることを意味します。ただし、Webモジュールは、アプリケーションのJavaコードのアノテーションで識別することもできます。

このデプロイ・タスクを使用して、Webアプリケーション・デプロイメント記述子の標準的なプロパティを設定できます。このプロパティには、次のようなものがあります。

- セッション検証間隔

- セッションCookieの最大保持時間

EJBの構成

このデプロイ・タスクは、EJBモジュールを含むアプリケーションで使用できます。これは、ほとんどの場合、アプリケーションにEJBデプロイメント記述子(ejb-jar.xmlまたはweblogic-ejb-jar.xml)が含まれることを意味します。ただし、EJBモジュールは、アプリケーションのJavaコードのアノテーションで識別することもできます。

このデプロイ・タスクを使用して、EJBデプロイメント記述子の標準的なプロパティを設定できます。このプロパティには、次のようなものがあります。

- 空きプール内のBeanの最大数

- EJBネットワーク・アクセス・ポイント

アプリケーション・セキュリティの構成

このデプロイ・タスクは、すべてのアプリケーション・タイプで使用できます。ただし、このタスクを選択したときに使用できるオプションは、アプリケーションに次のファイルがあるかどうかによって異なります。

- jazn-data.xml
アプリケーションにjazn-data.xmlファイルが存在する場合は、次の操作ができます。

- ポリシー移行の追加、上書きまたは無視。

- 初めてアプリケーションをデプロイする場合は、「追加」を選択します。

- アプリケーションが以前にデプロイされており、アプリケーション認可ポリシーが存在する場合は、「追加」または「無視」を選択して、アプリケーション認可ポリシーを保持します。

- 前のポリシーを上書きするには、「上書き」を選択します。

- アプリケーション・ストライプIDの指定(ストライプIDが、移行オプションで定義されているストライプIDと一致しない場合)。

- アプリケーションをアンデプロイするときにポリシーを削除するように指定。

- cwallet.sso
アプリケーションにcwallet.ssoファイルが存在する場合は、追加のアプリケーション資格証明移行オプションを設定できます。

アプリケーションに両方のファイルが含まれている場合、このページには両方のセクションが表示されます。

「アプリケーション・セキュリティの構成」デプロイ・タスクを選択するときに使用可能な設定に関する詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のFusion Middleware Controlを使用したJava EEとOracle ADFのアプリケーションのデプロイに関する項を参照してください。

アプリケーションにどちらのファイルも存在しない場合は、このタスクを使用して、アプリケーションをデプロイするときのユーザー・ロールおよびポリシーの定義方法を決定できます。たとえば、デプロイメント記述子で定義されたロールおよびポリシーのみを使用することも、サーバーで定義されたロールおよびポリシーのみを使用することもできます。「アプリケーション・セキュリティの構成」ページには、次のオプションが表示されます。

- デプロイメント記述子のみ: デプロイメント記述子で定義されているロールおよびポリシーのみを使用します。

- カスタム・ロール: 管理コンソールで定義されているロールを使用し、デプロイメント記述子で定義されているポリシーを使用します。

- カスタム・ロールおよびポリシー: 管理コンソールで定義されているロールおよびポリシーのみを使用します。

- 拡張: レルムの構成ページで構成したカスタム・モデルを使用します。

永続性の構成

このデプロイ・タスクは、1つ以上のpersistence.xmlファイルを含むアプリケーションで使用できます。このタスクを使用して、アプリケーションのJava Persistent API (JPA)の永続性単位を構成できます。

それぞれの永続性単位の詳細を表示して、それぞれの永続性単位のJava Transaction API (JTA)データ・ソースまたは非JTAデータ・ソースを定義することができます。

永続性単位にデータ・ソースを構成すると、Oracle TopLinkを使用するアプリケーションで便利な場合があります。詳細は、『Oracle TopLinkソリューション・ガイド』を参照してください。

Java EEアプリケーションでの永続性単位およびpersistence.xmlファイルの使用方法の詳細は、次のWebサイトにあるJava EE 5チュートリアルの、永続性単位の定義に関する項を参照してください。

http://download.oracle.com/javaee/5/tutorial/doc/bnbqw.html#bnbrj

ADF接続の構成

このデプロイ・タスクは、ADF接続を使用するアプリケーションで使用できます。外部アプリケーションの接続情報を変更できます。ADF接続の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。

10.9 デプロイされたアプリケーションでのMDS構成属性の変更

アプリケーションでMDSリポジトリを使用している場合、アプリケーションをデプロイした後に構成属性を変更できます。属性を表示または変更するには、システムMBeanブラウザまたはWLSTを使用できます。

注意:
この構成の変更は、カスタマイズとしてMDSに保持されます。これらがカスタマイズとして保持される理由は次のとおりです。

- この構成の変更は、アプリケーション・デプロイメント全体で保持されます。たとえば、アプリケーションのExternalChangeDetectionInterval構成属性の値がOracle JDeveloper全体で40秒に設定されているとします。ExternalChangeDetectionInterval構成属性を50秒に変更し、このアプリケーションを再デプロイすると、この属性の値は50秒のままになります。

- クラスタでは、デプロイされたアプリケーションのすべてのインスタンスが同じMDSリポジトリ・パーティションを指すため、このアプリケーションのすべてのインスタンスは同じ値を使用します。構成属性が1つのアプリケーション・インスタンスに対して変更されると、クラスタ内でそのアプリケーションのすべてのインスタンスが変更された値を使用します。

次の各項では、MDS構成属性を変更する方法について説明します。

- Fusion Middleware Controlを使用したMDS構成属性の変更

- WLSTを使用したMDS構成の変更

- アプリケーションの元のMDS構成のリストア

10.9.1 Fusion Middleware Controlを使用したMDS構成属性の変更

アプリケーションのMDS構成属性を変更するには、次の手順を実行します。

1. 「アプリケーションのデプロイ」を展開して、アプリケーションのホーム・ページに移動します。そこで、アプリケーションを選択します。
アプリケーションのホーム・ページが表示されます。

2. 「アプリケーションのデプロイ」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

3. 「アプリケーション定義のMBean」→「oracle.adf.share.config」→「サーバー: 名前」→「アプリケーション: 名前」→「ADFConfig」→「ADFConfig」→「ADFConfig」を開きます。

4. 「MDSAppConfig」を選択します。
次の図のように「アプリケーション定義のMBean」ページが表示されます。

5. 属性の説明および値を表示できます。
表10-2では、MDS固有の構成属性について説明します。ConfigMBeanなど、他の属性もブラウザに表示されますが、それらはすべてのMBeanの汎用属性です。

表10-2 デプロイされたアプリケーションでのMDS構成属性

属性

説明

AppMetadataRepositoryInfo

読取り専用。アプリケーションがデプロイされているメタデータ・リポジトリ・パーティションについての説明です。

AutoPurgeTimeToLive

秒単位で指定された特定の時間間隔より古いメタデータ・ドキュメントのバージョンを自動的にパージします。この時間間隔より古い、ラベルのないバージョンはいずれも、このアプリケーションから後続の更新が行われるたびに自動的にパージされます。値が設定されていない場合、バージョンは自動的にパージされません。

ConfigMBean

trueの場合、このMBeanが構成MBeanであることを示します。

DeployTargetRepository

アプリケーション用に構成されたターゲット・リポジトリの名前。

eventProvider

trueの場合、このMBeanがJSR-77によって定義されているイベント・プロバイダであることを示します。

eventTypes

このMBeanによって送信されるすべてのイベントのタイプ。

ExternalChangeDetection

いずれかのメタデータの変更が他のクラスタ・ノードで実行されているか、または別のアプリケーションで実行されているかを判断するために、MDSリポジトリをポーリングするように指定します。変更が検出されると、リポジトリを共有するアプリケーションに通知が送信されます。

複数のアプリケーションで、共有リポジトリにデプロイされるメタデータを共有できます。あるアプリケーションでこの共有メタデータに対して変更を行うと、他のアプリケーションでその変更を検出できます。そのためには、すべてのアプリケーションで、アプリケーション構成の一環として共有リポジトリを構成する必要があります。

MDSリポジトリが同じJVMの複数のアプリケーションで使用されている場合、いずれかのアプリケーションでExternalChangeDetectionがtrueに設定されていると、MDSは変更がないかポーリングします。

このアプリケーション・メタデータを更新することがない場合、または単一のサーバー上でこのアプリケーションでのみ使用される場合、この属性はfalseに設定します。

この属性は、データベース・ベースのリポジトリにのみ適用されます。デフォルトはtrueです。

ExternalChangeDetectionInterval

外部メタデータの変更があるかどうかを判断するために、MDSリポジトリのポーリングを行う最大時間間隔(秒)。この属性は、ExternalChangeDetectionが有効な場合にのみ有効です。

MDSリポジトリが同じJVMの複数のアプリケーションで共有され、使用されている場合、MDSは各アプリケーションでこの属性に指定されている値のうち、最低のものを使用します。そのため、あるアプリケーションでこのパラメータの値を変更しても、変更の影響が発生するのは、新しい値が他のアプリケーションで指定されたいずれの値より小さい場合のみです。

デフォルトは30秒です。

MaximumCacheSize

最大メタデータ・キャッシュ・サイズ制限(KB)。値が0の場合、キャッシュは無効です。値が指定されていない場合、キャッシュは無制限になります。その場合、キャッシュ・データは無制限に格納されます。

objectName

このMBeanによって送信されるすべてのイベントのタイプ。

ReadOnly

trueの場合、このMBeanが読取り専用MBeanであることを示します。

ReadOnlyMode

アプリケーションを読取り専用モードに変更します。これによって、構成やアプリケーションのメタデータなど、アプリケーションのリポジトリ・パーティションを更新できないようにします。

RemoteNotifications

適用可能なメタデータ変更に対する配布リモート通知を有効にします。このパラメータは、ExternalChangeDetectionが有効な場合のみ有効です。

RestartNeeded

適用可能なメタデータ変更に対する配布リモート通知を有効にします。このパラメータは、ExternalChangeDetectionが有効な場合のみ有効です。

RetryConnection

接続に失敗した後、アプリケーションがメタデータ・リポジトリへの接続を再試行できるようにします。

SharedMetadataRepositoryInfo

読取り専用。アプリケーションで使用されるMDSリポジトリ・パーティションを指定します。1つのアプリケーションで、複数の共有メタデータ・リポジトリを使用できます。

stateManageable

trueの場合、このMBeanがJSR-77によって定義されている状態管理機能を提供することを示します。

statisticsProvider

trueの場合、このMBeanがJSR-77によって定義されている静的プロバイダであることを示します。

SystemMBean

trueの場合、このMBeanがシステムMBeanであることを示します。

Visible

trueの場合、このMBeanが現在のユーザーに見えることを示します。

6. 属性を表示または変更するには、属性を選択します。
属性ページが表示されます。

7. 属性が読取り専用でない場合は、値を変更できます。たとえば、AutoPurgeTimeToLiveでは、「値」に新しい値を入力して間隔を変更できます。

8. 「適用」をクリックします。

9. 「ADFConfig」(MDSAppConfigの親)にナビゲートして選択します。

10. 「操作」タブで、「保存」をクリックします。

11. 「起動」をクリックします。

10.9.2 WLSTを使用したMDS構成の変更

WLSTを使用して、アプリケーションのMDS構成を変更できます。次の例は、ReadOnlyMode属性を読み込んで設定するWLSTスクリプトを示しています。

"""
Getting ReadOnlyMode Attribute from MBean
"""
connect('username','password','hostname:port')
application = 'application_name'
attribute = 'ReadOnlyMode'
beanName = 'oracle.adf.share.config:ApplicationName='+ application +',name=MDSAppConfig,type=ADFConfig,Application='+ application +',ADFConfig=ADFConfig,*'

beanObjectName = ObjectName(beanName)
beans = mbs.queryMBeans(beanObjectName, None)
bean = beans.iterator().next().getObjectName()
custom()
value = mbs.getAttribute(bean, attribute)
print value

"""
Setting ReadOnlyMode Attribute from MBean
"""
attr = Attribute(attribute, Boolean(0))
mbs.setAttribute(bean,attr)
value = mbs.getAttribute(bean, attribute)
print value

"""
Saving the Changes. This is required to persist the changes.
"""

adfConfigName = 'oracle.adf.share.config:ApplicationName='+ application + ',name=ADFConfig,type=ADFConfig,Application='+ application + ',*'
adfConfigObjectName = ObjectName(adfConfigName)
adfConfigMBeans = mbs.queryMBeans(adfConfigObjectName, None)
adfConfigMBean = adfConfigMBeans.iterator().next().getObjectName()
mbs.invoke(adfConfigMBean, 'save', None, None)

10.9.3 アプリケーションの元のMDS構成のリストア

アプリケーションの元のMDS構成をリストアするには:

1. 「アプリケーションのデプロイ」を展開して、アプリケーションのホーム・ページに移動します。そこで、アプリケーションを選択します。
アプリケーションのホーム・ページが表示されます。

2. 「アプリケーションのデプロイ」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

3. 「アプリケーション定義のMBean」→「oracle.adf.share.config」→「サーバー: 名前」→「アプリケーション: 名前」→「ADFConfig」→「ADFConfig」を開きます。

4. 「操作」タブを選択します。

5. RestoreToOriginalConfigurationを選択します。
操作: restoreToOriginalConfigurationページが表示されます。

6. 「起動」をクリックします。
この操作は注意して行ってください。これにより、元のadf-config.xmlファイルに行われたすべての変更が破棄されます。adf-config.xmlはベース・ドキュメントにリストアされます。

第V部

Oracle Fusion Middlewareのモニタリング

この部では、エラー原因と修正アクションに関する情報の検索方法、システム・アクティビティのモニタリングに役立つログ・ファイルの表示と管理の方法、問題の診断方法、およびOracle Fusion Middlewareのモニター方法について説明します。

第V部は、次の章で構成されています。

- 第11章「Oracle Fusion Middlewareのモニタリング」

- 第12章「ログ・ファイルと診断データの管理」

- 第13章「問題の診断」

11 Oracle Fusion Middlewareのモニタリング

この章では、Fusion Middleware Control、Oracle WebLogic Server管理コンソールおよびコマンド行を使用したOracle Fusion Middlewareのモニター方法について説明します。

次の各項について説明します。

- Oracle Fusion Middlewareのステータスの監視

- Oracle Fusion Middlewareのパフォーマンスの表示

11.1 Oracle Fusion Middlewareのステータスのモニタリング

Oracle Fusion Middleware環境のヘルス状態のモニタリング、およびパフォーマンスが最適であることの確認は、管理者の重要な作業です。

Oracle Fusion Middlewareでは、次の方法で環境のステータスをモニタリングできます。

Oracle Fusion Middlewareでは、次の方法で環境のステータスをモニタリングできます。

- Fusion Middleware Control: Oracle WebLogic Serverドメイン、クラスタ、サーバー、Javaコンポーネント、システム・コンポーネントおよびアプリケーションのステータスをモニターできます。Oracle HTTP Serverインスタンスのホーム・ページなどのエンティティのホーム・ページにナビゲートします。

- Oracle WebLogic Server管理コンソール: Oracle WebLogic Serverドメイン、クラスタ、サーバー、Javaコンポーネント、およびアプリケーションのステータスをモニターできます。管理コンソールからエンティティのページにナビゲートします。コンソールを使用したモニタリングの詳細は、『Oracle WebLogic Serverの理解』の管理コンソールの概要に関する項を参照してください。

- コマンド行: WLSTのstateコマンドを使用して、環境のステータスをモニターできます。

この章のほとんどのモニタリング・タスクでは、Fusion Middleware Controlまたはコマンド行を使用してモニターする方法を説明します。

次の各項で、詳細を説明します。

- Oracle WebLogic Serverドメインのモニタリング

- Oracle WebLogic Serverの管理サーバーや管理対象サーバーのモニタリング

- クラスタのモニタリング

- Javaコンポーネントのモニタリング

- システム・コンポーネントのモニタリング

- Java EEアプリケーションのモニタリング

- ADFアプリケーションのモニタリング

- SOAインフラストラクチャおよびSOAコンポジット・アプリケーションの監視

- Oracle WebCenter Portalアプリケーションの監視

- クラスタにデプロイされたアプリケーションのモニタリング

- コマンド行を使用したコンポーネントのステータスのモニター

11.1.1 Oracle WebLogic Serverドメインのモニタリング

また、Fusion Middleware Controlのドメインのホーム・ページでも、サーバー、クラスタ、ドメイン内のデプロイなどのドメインのステータスを表示できます。

1. 「WebLogicドメイン」メニューから、「ホーム」を選択します。
次の図のようにドメインのホーム・ページが表示されます。

このページには次の内容が表示されます。

- 管理サーバーおよび管理サーバーが置かれているホストの名前。

- ドメイン内のサーバーに関する情報がリストされた表。表には、「名前」、「ステータス」、「サーバー・タイプ」、「ホスト」、「クラスタ」、「リスニング・ポート」、「CPU使用率」および「ヒープ使用量」の各列が含まれます。

2. ドメインに関する特定の監視の詳細は、WebLogicドメインのメニューで、「モニタリング」を選択し、パフォーマンス・サマリー、ヘルスまたはデプロイメントなどの他のサブカテゴリを選択します。

Oracle WebLogic Server管理コンソールを使用したOracle WebLogic Serverドメインのモニタリングの詳細は、『Oracle WebLogic Serverの理解』の管理コンソールの概要に関する項を参照してください。管理コンソールは、ドメインのヘルスとパフォーマンスの詳細を提供します。

11.1.2 Oracle WebLogic Serverの管理サーバーや管理対象サーバーのモニタリング

Fusion Middleware Controlで、WebLogic Serverの管理サーバーや管理対象サーバーのステータスを表示できます。

1. ナビゲーション・ペインからドメインを展開します。

2. サーバーを選択します。
サーバーのホーム・ページが表示されます。

次の図は、管理対象サーバーのホーム・ページを示しています。

このページには次の内容が表示されます。

- サーバーのステータス、サーバーで実行されているサーブレット、JSPおよびEJBに関する情報を含む、サーバーの一般的なサマリー

- レスポンスと負荷

3. サーバーに関する特定の監視の詳細は、「WebLogic Server」メニューで、「モニタリング」を選択し、パフォーマンス・サマリー、ヘルスまたはデプロイメントなどの他のサブカテゴリを選択します。

Oracle WebLogic Server管理コンソールを使用したサーバーのモニタリングの詳細は、『Oracle WebLogic Serverの理解』の管理コンソールの概要に関する項を参照してください。管理コンソールは、サーバーのヘルスとパフォーマンスの詳細を提供します。

11.1.3 クラスタのモニタリング

Fusion Middleware Controlを使用して、クラスタ内のサーバーやデプロイメントを含めて、クラスタのステータスを表示できます。

1. ナビゲーション・ペインからドメインを展開します。

2. クラスタを選択します。
次の図のようにクラスタ・ページが表示されます。

このページには、クラスタ・メッセージング・モード、レスポンスおよび負荷を含むクラスタに関する一般情報、サーブレットおよびJSPに関する情報が表示されます。

3. クラスタ内のサーブレットのステータスのサマリーを表示するには、WebLogic Clusterのメニューで、「モニタリング」→「サマリー」の順に選択します。

4. クラスタに関する特定の監視の詳細は、WebLogicクラスタのメニューで、「モニタリング」を選択し、パフォーマンス・サマリー、ヘルスまたはデプロイメントなどの他のサブカテゴリを選択します。

11.1.4 Javaコンポーネントのモニタリング

Fusion Middleware Controlのコンポーネントのホーム・ページでは、コンポーネントが起動されているかどうかといったJavaコンポーネントのステータスを表示できます。

Oracle Enterprise SchedulerなどのJavaコンポーネントをモニターするには、次の手順を実行します。

1. ナビゲーション・ペインで、WebCenterなどのコンポーネント・タイプを展開してから、「コンテンツ」→取得の順に選択します。

2. コンポーネントを選択します。たとえば、captureを選択します。
次の図のように、コンポーネントのホーム・ページが表示されます。

このページには、状態や主要なメトリックを含むコンポーネントに関する一般情報が表示されます。

3. コンポーネントに関する特定の監視の詳細は、コンポーネントのメニューで、「モニタリング」を選択し、パフォーマンス・サマリーを選択します。

11.1.5 システム・コンポーネントのモニタリング

Oracle HTTP Serverなどのシステム・コンポーネントをモニターするには:

1. ナビゲーション・ペインで、コンポーネントのタイプ(「HTTP_Server」など)を展開します。

2. ohs1などのコンポーネントを選択します。
次の図のように、コンポーネントのホーム・ページが表示されます。

このページには次の内容が表示されます。

- 名前や状態などのコンポーネントに関する基本情報が含まれる「一般」セクション

- 1秒当たりのリクエスト数とリクエスト処理時間が表示されたレスポンスと負荷のセクション

- CPU使用率およびメモリー使用量

11.1.6 Java EEアプリケーションのモニタリング

Fusion Middleware Controlを使用してJava EEアプリケーションをモニターする手順は次のとおりです。

1. ナビゲーション・ペインで、「アプリケーションのデプロイ」を開き、モニター対象のアプリケーションを選択します。
アプリケーションのホーム・ページが表示されます。

2. このページで、アプリケーションのステータスのサマリー、アプリケーションのエントリ・ポイント、アプリケーションに関連付けられているWebサービスおよびモジュール、レスポンスと負荷を確認できます。
次の図はアプリケーションのホーム・ページを示しています。

このページには、状態を含むアプリケーションのサマリーが表示されます。

11.1.7 ADFアプリケーションのモニタリング

ADFアプリケーションをモニターする手順は次のとおりです。

1. ナビゲーション・ペインで、「アプリケーションのデプロイ」を開き、モニター対象のアプリケーションを選択します。
アプリケーションのホーム・ページが表示されます。

次の図は、アプリケーションのホーム・ページの一部を示しています。

- アプリケーションの状態、デプロイされている管理対象サーバーや、アクティブ・セッション、アクティブ・リクエスト、リクエストの処理時間の情報などのアプリケーションのサマリー

- アプリケーションがデプロイされるサーバーをリスト表示する「デプロイメント」

- モジュールとそれぞれのモジュール・タイプの一覧

- データ・ソースのリスト

2. 環境のヘルスを表示するには、「アプリケーションのデプロイ」メニューから「モニタリング」を選択し、次に「環境モニタリング」を選択します。「環境モニタリング」ページが表示されます。
「ヘルス」、「問合せキャッシング」、「ワークロード」および「Coherence」の各タブがあります。

11.1.8 SOAインフラストラクチャおよびSOAコンポジット・アプリケーションの監視

SOAインフラストラクチャおよびSOAコンポジット・アプリケーションを監視するには、次を参照してください。

- 『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAインフラストラクチャまたは個々のパーティションの全体的なステータスの監視に関する項

- 『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAコンポジット・アプリケーションの監視に関する項

11.1.9 Oracle WebCenter Portalアプリケーションの監視

Oracle WebCenter Portalアプリケーションを監視するには、『Oracle WebCenter Portalの管理』のOracle WebCenter Portalサービスの監視に関する項を参照してください。

11.1.10 クラスタにデプロイされたアプリケーションのモニタリング

アプリケーションをクラスタにデプロイする場合、Oracle Fusion Middlewareでは、アプリケーションがクラスタ内の各管理対象サーバーに自動的にデプロイされます。そのため、各サーバーにはアプリケーションのインスタンスがあります。

個々のサーバーのアプリケーションのパフォーマンスをモニターしたり、クラスタ内のすべてのサーバーにわたってアプリケーションの全体的なパフォーマンスをモニターすることが必要になる場合があります。

たとえば、通常は、アプリケーションの全体的なパフォーマンスを管理して、ユーザーがどのインスタンスにアクセスしているかに関係なく、アプリケーションのすべてのユーザーに影響するパフォーマンスの問題が発生していないかどうかを確認します。パフォーマンスの問題に気付いたら、アプリケーションの具体的なインスタンスを掘り下げて、その問題の影響を受けているのが、クラスタ内のアプリケーション・インスタンスの1つなのかすべてなのかを確認します。

Fusion Middleware Controlでは、その両方のシナリオに対してモニタリング・ページが用意されています。

1. ナビゲーション・ペインで、「アプリケーションのデプロイ」を開きます。
Fusion Middleware Controlでは、現在のドメインにデプロイされているアプリケーションが一覧表示されます。

2. アプリケーションがクラスタにデプロイされた場合は、ナビゲーション・ペインでアプリケーションを展開します。Fusion Middleware Controlは、アプリケーションがクラスタ・アプリケーションにデプロイされたことを表示し、それがクラスタ上の複数のアプリケーション・インスタンスを表していることを示します。

3. クラスタ・アプリケーションをクリックしてクラスタ上のアプリケーションの全体的なパフォーマンスをモニターするか、またはアプリケーション・デプロイ・インスタンスのいずれかをクリックして1つのサーバー上のアプリケーションのパフォーマンスをモニターします。

11.1.11 コマンド行を使用したコンポーネントのステータスのモニター

WLSTコマンド行を使用してコンポーネントのステータスをモニターする手順は次のとおりです。

- Javaコンポーネントの場合は、次の形式でWLSTのstateコマンドを使用します。

state(name, type)

たとえば、管理対象サーバーserver1のステータスを確認する場合は、次のコマンドを使用します。

wls:/mydomain/serverConfig> state('server1','Server')
Current state of "server1": SUSPENDED

- システム・コンポーネントのステータスをモニターするには、次の形式でWLSTのstateコマンドを使用します。
Oracle Fusion Middlewareでは、次の方法で環境のステータスをモニタリングできます。

システム・コンポーネントのステータスをモニターするには、次の形式でWLSTのstateコマンドを使用します。

state('component_name')]

たとえば、ohs1ステータスを表示するには、次のコマンドを使用します。

state('ohs1')]

11.2 Oracle Fusion Middlewareのパフォーマンスの表示

アプリケーションの実行速度の低下やハングなどの問題が発生した場合は、特定のターゲットのパフォーマンス・メトリックなど、パフォーマンスの詳細情報を表示して、問題の詳細を調べることができます。

Oracle Fusion Middlewareは、ランタイム・パフォーマンスを継続的に自動測定します。パフォーマンス・メトリックは自動的に有効化されるため、メトリックの収集のためにオプションを設定したり、追加の構成を実行する必要はありません。

Fusion Middleware Controlでは、リアルタイムのデータが表示されます。履歴データの表示が必要な場合は、Oracle Enterprise Manager Grid Controlの使用を検討してください。

たとえば、Oracle WebLogic Serverの管理対象サーバーのパフォーマンスを表示する手順は次のとおりです。

1. ナビゲーション・ペインからドメインを展開します。

2. モニターするサーバーを選択します。
管理対象サーバーのホーム・ページが表示されます。

3. 「WebLogic Server」メニューから、「モニタリング」、「パフォーマンス・サマリー」と選択します。
「パフォーマンス・サマリー」ページが表示されます。Oracle WebLogic Serverにデプロイされているアプリケーションのパフォーマンス・メトリックと、レスポンス時間およびリクエスト処理時間に関する情報が表示されます。

4. 追加メトリックを表示するには、「メトリック・パレットの表示」をクリックして、メトリック・カテゴリを開きます。
次の図は、メトリック・パレットが表示された「パフォーマンス・サマリー」ページの一部を示しています。別のメトリックを表示するには、左側のペインで下にスクロールします。

5. メトリックを選択して、パフォーマンス・サマリーに追加します。

6. 「比較」→他のOracle WebLogic Serverを選択すると、サーバー間で比較できます。別のターゲットをオーバーレイするには、「オーバーレイ」をクリックして、そのターゲットを選択します。このターゲットはチャートに追加され、複数のターゲットのパフォーマンスを一度に表示して比較できるようになります。

7. チャートごとに表示される時間フレームをカスタマイズするには、次の処理を実行します。

- 「スライダ」をクリックして、スライダ・ツールを表示します。これを使用すると、チャートに表示される時間を伸縮できます。たとえば、表示範囲を直前の15分から10分に変更する場合、左側のスライダ・コントロールを、直前の10分間が表示されるようになるまで右にスライドさせます。

- カレンダと時計アイコンを選択します。次に、「開始時間」と「終了時間」を入力します。このような時間に関して利用可能なデータがない場合、確認メッセージが表示され、このデータが利用可能な期間へと時系列が自動的に調整されることが説明されます。

Oracle HTTP ServerやOracle SOA Suiteなどのコンポーネントのパフォーマンスも表示できます。目的のコンポーネントにナビゲートして「モニタリング」を選択し、動的ターゲット・メニューから「パフォーマンス・サマリー」を選択します。

12 ログ・ファイルと診断データの管理

Oracle Fusion Middlewareコンポーネントは、起動および停止情報、エラー、警告メッセージ、HTTPリクエスト時のアクセス情報など、すべての種類のイベントを記録するメッセージが格納されたログ・ファイルを生成します。この章では、エラー原因と修正アクションに関する情報の検索方法、システム・アクティビティのモニタリングおよび問題の診断に役立つログ・ファイルの表示と管理の方法について説明します。

内容は次のとおりです。

- Oracle Fusion Middlewareのロギングの概要

- ODLメッセージとODLログ・ファイルの理解

- ログ・ファイルの表示と検索

- ログ・ファイルの設定の構成

- ログ・ファイルおよびコンポーネント間のメッセージの関連付けの理解

- トレースの構成

12.1 Oracle Fusion Middlewareのロギングの概要

次の各項目ではHTTPアクセス・ロギングおよび診断ロギングについて説明します。

- Oracle Fusion Middleware HTTPアクセス・ロギングの理解

- Oracle Fusion Middleware診断ロギングの理解

12.1.1 Oracle Fusion Middleware HTTPアクセス・ロギングの理解

デフォルトで、Oracle WebLogic ServerはHTTPアクセス・ログについて共通のログ・フォーマットを使用するように構成されます。Oracle WebLogic Serverは、World Wide Web Consortium (W3C)のドラフト仕様で定義された新たな標準である、拡張ログ・フォーマットもサポートしています。

Oracle WebLogic ServerをOracle JRFとともにインストールした場合、HTTPアクセス・ログにはデフォルトでこの拡張ログ・フォーマットが使用されます。拡張ログ・フォーマットを使用すると、各HTTP通信について記録される情報のタイプと順序を指定できます。

Oracle Fusion Middlewareでは次のフィールド識別子がサポートされています。

- date: トランザクションが完了した日付。このフィールドの形式はYYYY-MM-DDです。すべての日付はGMTで指定します。

- time: トランザクションが完了した時刻。このフィールドの形式はHH:MM、HH:MM:SSまたはHH:MM:SS.Sが可能です(HHは24時間表示の時、MMは分、SSは秒)。すべての時刻はGMTで指定します。

- cs-method: リクエスト・メソッド(GETやPOSTなど)。このフィールドにはW3C仕様で定義された入力値<name>が入ります。

- cs-url: リクエストされたURIの絶対パス。このフィールドにはW3C仕様で定義された入力値<uri>が入ります。

- ctx-ecid: 実行コンテキストID (ECID)。ECIDは、特定のリクエストの実行に関連付けられたグローバルに一意の識別子です。

- ctx-rid: 関係ID (RID)。RIDは、1つのリクエストにおいて、特定のプロセス上の特定スレッドで実行された作業と、同じプロセス上の別スレッドおよび別プロセス上で実行された作業を区別します。

- sc-status: レスポンスのステータス・コード。たとえば(404)は「ファイルが見つかりません」というステータスを示します。このフィールドにはW3C仕様で定義された入力値<integer>が入ります。

拡張ログ・フォーマットの詳細は、次の場所を参照してください。

http://www.w3.org/TR/WD-logfile.html

12.1.2 Oracle Fusion Middleware診断ロギングの理解

大部分のOracle Fusion Middlewareコンポーネントでは、Oracle Diagnostic Logging (ODL)形式で診断ログ・ファイルが作成されます。ログ・ファイルの名前とログ・ファイルの内容の形式は、Oracle標準に準拠します。デフォルトでは、診断メッセージはテキスト形式で書き込まれます。

ODLには次の利点があります。

- 保存される診断情報の合計サイズを制限します。保存される情報のレベルを設定したり、ログ・ファイルおよびログ・ファイル・ディレクトリの最大サイズを指定できます。

- 指定サイズに達すると、古いセグメント・ファイルが削除され、新しいセグメント・ファイルが時系列で保存されます。

- コンポーネントがアクティブな状態で古い診断ログ・ファイルを削除でき、停止する必要がありません。

ログ・ファイルは、Fusion Middleware ControlまたはWLST displayLogsコマンドを使用して表示できます。また、ログ・ファイルをローカル・クライアントにダウンロードして、他のツール(テキスト・エディタおよびその他のファイル表示ユーティリティ)を使用して表示することもできます。

注意:
Oracle WebLogic Serverは、ODL形式を使用しません。Oracle WebLogic Serverのログ・フォーマットについては、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』を参照してください。

12.2 ODLメッセージおよびODLログ・ファイルの理解

ODLを使用すると、診断メッセージがログ・ファイルに書き込まれ、メッセージのそれぞれに、時間、コンポーネントID、ユーザーなどの情報が組み込まれます。

次の例は、Oracle HTTP ServerからのODL形式のエラー・メッセージを示しています。

[2015-03-13T12:31:29.0584-07:00] [OHS] [NOTIFICATION:16] [OHS-9999]
[mod_weblogic.c] [host_id: example] [host_addr: nn.nnn.nn.nn] [pid: 12789]
[tid: 46919953675776] [user: username VirtualHost: main
WebLogic Server Plugin version 12.1.2 <WLSPLUGINS_MAIN_LINUX.X64_130502.1731>

このメッセージでは、フィールドが次の属性にマップされています。これらについては表12-1で説明します。

- タイムスタンプ、開始: 2015-03-13T12:31:29.0584-07:00

- 組織ID: OHS

- メッセージ・タイプ: NOTIFICATION:16

- コンポーネントID: mod_weblogic.c

- ホストID: host_id: example

- ホスト・アドレス: host_addr: nn.nnn.nn.nn

- プロセスID: pid: 12789

- スレッドID: tid: 46919953675776

- ユーザーID: userId: username

- 仮想ホスト: VirtualHost: main

- メッセージ・テキスト: "WebLogic Server Plugin version 12.1.2 <WLSPLUGINS_MAIN_LINUX.X64_130502.1731>"

デフォルトでは、情報はログ・ファイルにODLテキスト形式で書き込まれます。この形式は、第12.4.4項で説明するように、ODL XML形式に変更できます。

表12-1で、ODLメッセージの内容を説明します。コンポーネントによっては、生成された診断メッセージにオプションの属性が存在しない場合があります。

表12-1 ODL形式メッセージのフィールド

属性名

説明

必須

タイムスタンプ、開始(TIME)

メッセージが生成された日時。ローカル・タイムゾーンが反映されます。

はい

タイムスタンプ、正規化済(time_norm)

ホスト間のクロックのずれの調整用に標準化されたタイムスタンプ。診断メッセージが別のホスト上のリポジトリにコピーされる場合に使用します。

いいえ

組織ID (org_id)

作成元のコンポーネントの組織ID。

いいえ

INSTANCE_ID
(INST_ID)

メッセージを生成したコンポーネントが属するインスタンスの名前。

いいえ

COMPONENT ID (COMP_ID)

メッセージを生成したコンポーネントのID。

はい

MESSAGE_ID (MSG_ID)

コンポーネント内でメッセージを一意に識別するID。IDは、コンポーネントを示す接頭辞、およびそれに続くダッシュと5桁の数値で構成されます。次に例を示します。

OHS-51009

はい

MESSAGE_TYPE
(MSG_TYPE)

メッセージのタイプ。使用可能な値は、INCIDENT_ERROR、ERROR、WARNING、NOTIFICATION、TRACEおよびUNKNOWNです。メッセージ・タイプの詳細は、表12-3を参照してください。

はい

MESSAGE_LEVEL (MSG_LEVEL)

メッセージ・レベル。メッセージ・タイプを限定する整数値で示されます。使用可能な値は1(最高重大度)から32(最低重大度)です。メッセージ・レベルの詳細は、表12-3を参照してください。

はい

HOST_ID (HOST_ID)

メッセージを生成したホストの名前。

いいえ

HOST_NW_ADDR (HOST_ADDR)

メッセージを生成したホストのネットワーク・アドレス。

いいえ

MODULE_ID (MODULE)

メッセージを生成したモジュールのID。コンポーネントが単独のモジュールの場合は、この属性にコンポーネントIDが表示されます。

はい

PROCESS_ID (PID)

メッセージに関連付けられたプロセスまたは実行単位のプロセスID。

いいえ

THREAD_ID (TID)

メッセージを生成したスレッドのID。

いいえ

USER_ID (USER)

メッセージを生成した実行コンテキストを所有するユーザーの名前。

いいえ

ECID

実行コンテキストID (ECID)。生成コンポーネントが関与する特定のリクエストの実行のグローバル一意識別子。ECIDは、別のコンポーネントで発生したエラー・メッセージの関連付けに使用できます。ECIDの詳細は、第12.5項を参照してください。

はい

RID

関係ID (RID)。1つのリクエストにおいて、特定のプロセス上の特定スレッドで実行された作業と、同じプロセスの別のスレッドおよび別プロセス上で実行された作業を区別します。RIDの詳細は、第12.5項を参照してください。

いいえ

SUPPL_ATTRS

イベントに関するコンポーネント固有の属性を格納する名前/値のペアが記載された追加リスト。

Oracle Fusion Middlewareでは、サプリメンタル属性DSID(診断セッションID)が提供されています。DSIDはユーザー・セッションのIDであり、一連のログ・メッセージ、インシデントおよびその他の診断データをユーザー・セッションにマップするために使用されます。たとえば、ユーザー・セッションで生成された特定のインシデントの前に同じセッション内で別のインシデントが生成されていたかどうか、またそれらが後に続いたインシデントの原因であったかどうかを確認できます。

いいえ

MESSAGE TEXT (TEXT)

メッセージのテキスト。

はい

メッセージ引数(arg)

メッセージ・テキストにバインドされた引数のリスト。

いいえ

追加詳細

イベントの追加情報で、メッセージ・テキストより詳細な情報が含まれます。

いいえ

ログ・ファイルの場所は、コンポーネントのタイプによって異なります。

- ほとんどのJavaコンポーネントのログ・ファイルは、次の場所にあります。

(UNIX) DOMAIN_HOME/servers/server_name/logs
(Windows) DOMAIN_HOME\servers\server_name\logs

ログ・ファイルのデフォルト名は、server-name-diagnostic.logです。

- システム・コンポーネントのログ・ファイルは、デフォルトでは次の場所にあります。

(UNIX) DOMAIN_HOME/servers/component_name/logs
(Windows) DOMAIN_HOME\servers\component_name\logs

表12-2に、Oracle Fusion Middlewareのコンポーネントのログ・ファイルの場所を示します。

表12-2 Oracle Fusion Middlewareコンポーネントのログ・ファイルの場所

コンポーネント

ログ・ファイルの場所

Fusion Middleware Control

DOMAIN_HOME/sysman/log/emoms.log
DOMAIN_HOME/sysman/log/emoms.trc

Oracle Application Development Framework

DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log

Oracle BI Enterprise Edition。

DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log
DOMAIN_HOME/servers/instance_key/logs/server-name-diagnostic.log

Oracle Enterprise Scheduler

DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log

Oracle Event Processing

DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log

Oracle Forms Services

DOMAIN_HOME/servers/server_name/logs/application_name.log

Oracle HTTP Server

DOMAIN_HOME/servers/component_name/logs/*.log

Oracle Managed File Transfer

DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log

Oracle Platform Security Services

DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log

Oracle Service Bus

DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log

Oracle TopLink

DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log

Oracle Web Services Manager

DOMAIN_HOME/servers/server_name/logs/owsm/msglogging
DOMAIN_HOME/servers/server_name/logs/owsm-diagnostic.log

Oracle WebLogic Server

DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log

Oracle WebCenter Content

DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log

Oracle WebCenter Portal Services

DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log

Oracle WebCenter Sites

DOMAIN_HOME/servers/server_name/logs/server-name-diagnostic.log
DOMAIN_HOME/servers/server_name/logs/sites_server-name.log000n
DOMAIN_HOME/servers/server_name/logs/cas_server-name.log000n

リポジトリ作成ユーティリティ

デフォルトでは、RCU_LOG_LOCATIONで指定されたファイルに書き込みます。指定されていない場合は、次の場所に書き込もうとします。

1. ORACLE_HOME/rcu/log/timestamp

2. /tmp/logdir.timestamp

12.3 ログ・ファイルの表示と検索

Oracle Fusion Middlewareコンポーネントをまたがって、ログ・ファイルの表示、リスト表示、および検索ができます。Fusion Middleware Controlを使用してログ・ファイルの表示や検索を行い、ログ・ファイルをローカル・クライアントにダウンロードし、別のツールを使用して表示することができます。また、WLSTコマンド行ツールを使用してログ・ファイルをリスト表示、表示および検索することもできます。

この項の項目は次のとおりです。

- ログ・ファイルおよびそのメッセージの表示

- ログ・ファイルの検索

- ログ・ファイルのダウンロード

WLSTコマンドを使用してログ・ファイルを表示する場合は、次の点に注意してください。

- ログ表示コマンドは、Weblogic Serverに接続していても接続していなくても機能します。接続していない場合は、oracleInstanceパラメータでパスを指定して、そのパスをドメイン・ホームに渡す必要があります。

- WLSTロギング・コマンドは、多くの場合、domainRuntimeツリーで実行する必要があります。たとえば、domainRuntimeツリーに接続して実行する場合は、次のWLSTコマンドを使用します。

connect('username', 'password', 'localhost:port_number')
domainRuntime()

コマンドの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のロギングのカスタムWLSTコマンドに関する項を参照してください。

12.3.1 ログ・ファイルおよびそのメッセージの表示

次の各項で説明するように、Fusion Middleware ControlまたはWLSTコマンドを使用して、ログ・ファイルを表示できます。

- Fusion Middleware Controlを使用したログ・ファイルおよびそのメッセージの表示

- WLSTを使用したログ・ファイルおよびそのメッセージの表示

12.3.1.1 Fusion Middleware Controlを使用したログ・ファイルおよびそのメッセージの表示

特定のドメイン、Oracle WebLogic Server、コンポーネントまたはアプリケーションのすべてのエンティティのメッセージを表示できます。

たとえば、管理対象サーバーのログ・ファイルおよびメッセージを表示する手順は次のとおりです。

1. ナビゲーション・ペインからドメインを展開します。管理対象サーバーの名前を右クリックし、「ログ」→「ログ・メッセージの表示」を選択します。
「ログ・メッセージ」ページが表示されます。

2. 「ターゲット・ログ・ファイル」をクリックします。
「ログ・ファイル」ページが表示されます。このページには、次の図に示すように管理対象サーバーに関連するログ・ファイルのリストが表示されます。

3. ファイルを選択して、「ログ・ファイルの表示」をクリックします。
「ログ・ファイルの表示」ページが表示されます。このページに、メッセージのリストが表示されます。

4. メッセージの詳細を表示するには、該当するメッセージを選択します。
次の図のように、リストの下のペインに詳細が表示されます。

デフォルトでは、メッセージは時間を基準として昇順でソートされます。メッセージは、列名をクリックすることにより、メッセージ・タイプなどの任意の列を基準としてソートできます。

12.3.1.2 WLSTを使用したログ・ファイルおよびそのメッセージの表示

WLSTのlistLogsコマンドを使用して、Oracle WebLogic Serverドメイン、サーバーまたはコンポーネントのログ・ファイルをリスト表示できます。

このコマンドは、接続中も切断中も使用できます。接続時のデフォルトのターゲットは、Oracle WebLogic Serverドメインです。

ログ・ファイルをリスト表示するには、第12.3項の説明に従って、まずdomainRuntimeコマンドを使用します。次に、ログ・ファイルのリスト表示方法および表示方法について説明します。

- Oracle WebLogic Server wls_server_1のすべてのログ・ファイルをリスト表示するには、次のコマンドを使用します。

listLogs(target='wls_server_1')
file://hostname/scratch/oracle1/Oracle/domains/base_domain/servers/wls_server_1/logs/wls_server_1.log
2015-03-21 06:55:37                  500.1K wls_server_1.log00026
2015-03-21 07:49:08                  500.1K wls_server_1.log00027
2015-03-21 08:46:29                  500.4K wls_server_1.log00028
2015-03-21 09:45:29                  500.4K wls_server_1.log00029
2015-03-21 10:43:00                  500.3K wls_server_1.log00030
2015-03-21 11:39:56                  500.3K wls_server_1.log00031
2015-03-21 12:38:56                  500.4K wls_server_1.log00032
2015-03-21 13:18:06                  358.1K wls_server_1.log

file://hostname/scratch/oracle1/Oracle/domains/base_domain/servers/wls_server_1/logs/wls_server_1.out
2015-03-13 11:00:05                      4M wls_server_1.out00001
2015-03-21 13:18:06                   12.1M wls_server_1.out
...

- システム・コンポーネントのログをリスト表示するには、次のいずれかの形式を使用します。

listLogs(target='component_name')
listLogs(target='sc:component_name')

たとえば、Oracle HTTP Server ohs1のログをリスト表示するには、次のコマンドを使用します。

listLogs(target='ohs1')

- 未接続時にログをリスト表示するには、oracleInstanceパラメータを指定し、それをドメインのパスに渡す必要があります。たとえば、Managed Server wls_server_1のログ・ファイルをリスト表示するには、次のコマンドを実行します。

listLogs(oracleInstance='/scratch/Oracle/config/domains/WLS_domain',
target='wls_server_1')

- ログ・ファイルの診断メッセージを表示するには、WLST displayLogsコマンドを使用します。このコマンドは、接続時も切断時も機能します。
たとえば、Oracle WebLogic Serverドメインで直前の10分以内にログ・ファイルに生成されたメッセージを表示するには、次のコマンドを使用します。

displayLogs(last=10)

[2015-03-21T13:30:11.892-07:00] [wls_server_1] [WARNING] [WSM-09004]
[oracle.wsm.resources.common] [host: hostname [nwaddr: 10.240.82.231]
[tid: [ACTIVE].ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: OracleSystemUser]
[ecid: 66217af9-247f-4344-94a9-14f90e75a586-00070b85,0] [APP: wsm-pm] [TARGET: /base_domain/wls_server_1/wsm-pm]
[LOG_FILE: /scratch/oracle1/Oracle/domains/base_domain/servers/wls_server_1/logs/wls_server_1-diagnostic.log]
Component auditing cannot be initialized.
[2015-03-21T13:30:11.895-07:00] [wls_server_1] [NOTIFICATION] [BEA-010227]
[EJB] [host: hostname] [nwaddr: 10.240.82.231] [tid: [ACTIVE].ExecuteThread:
'5' for queue: 'weblogic.kernel.Default (self-tuning)']
[userId: OracleSystemUser]
[ecid: 66217af9-247f-4344-94a9-14f90e75a586-00070b85,0] [TXN_ID: BEA1-7438ECB7CDFCAF163A9A]
[TARGET: /base_domain/wls_server_1]
[LOG_FILE: /scratch/oracle1/Oracle/domains/base_domain/servers/wls_server_1/logs/wls_server_1.log]
EJB exception occurred during invocation from home or business:
weblogic.ejb.container.internal.StatelessEJBHomeImpl@314c2224 generated
exception: java.lang.reflect.UndeclaredThrowableException

このコマンドでは、時間を基準に昇順でソートされたメッセージが返されます。

- システム・コンポーネントのログを表示するには、次のいずれかの形式を使用します。

listLogs(target='component_name')
listLogs(target='sc:component_name')

たとえば、Oracle HTTP Server ohs_1のログを表示するには、次のコマンドを使用します。

displayLogs(target='sc:ohs_1')

メッセージは、第12.3.2項で説明されているように、特定の基準を指定して検索し、出力をソートできます。

listLogsおよびdisplayLogsコマンドの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のロギングのカスタムWLSTに関する項を参照してください。

12.3.2 ログ・ファイルの検索

次の各項で説明するように、Fusion Middleware ControlまたはWLSTコマンドを使用すると、時間、メッセージのタイプおよび特定のログ・ファイル属性を基準にして診断メッセージを検索できます。

- Fusion Middleware Controlを使用したログ・ファイルの検索

- WLSTを使用したログ・ファイルの検索

12.3.2.1 Fusion Middleware Controlを使用したログ・ファイルの検索

Fusion Middleware Controlの「ログ・メッセージ」ページでは、標準および追加のODL属性を使用して診断メッセージを検索できます。デフォルトで、このページには、直前1時間にログに記録された問題のサマリーが表示されます。

検索基準は、適合度の高いメッセージが特定されるように変更できます。検索結果を別のモードで表示すると、大量のデータを簡単にナビゲーションできます。

次の各項では、ログ・ファイルの検索方法を説明します。

- ログ・ファイルの検索: 基本検索

- ログ・ファイルの検索: 拡張検索

12.3.2.1.1 ログ・ファイルの検索: 基本検索

この項では、ログ・メッセージの基本検索の方法について説明します。

特定のドメイン、Oracle WebLogic Server、コンポーネントまたはアプリケーションのすべてのエンティティのすべてのメッセージを検索できます。

たとえば、特定のドメインのメッセージを検索する手順は次のとおりです。

1. 「WebLogicドメイン」メニューで、「ログ」→「ログ・メッセージの表示」を選択します。
特定のコンポーネントまたはアプリケーションのメッセージを検索するには、目的のコンポーネントまたはアプリケーションを選択します。そのターゲットのメニューで、「ログ」→「ログ・メッセージの表示」を選択します。

「ログ・メッセージ」ページに、「検索」セクションおよび過去10分間のメッセージのサマリーを示す表が表示されます。

2. 「検索」アイコンをクリックします。「日付範囲」セクションでは、次のいずれかを選択できます。

- 最新: このオプションを選択した場合は、3時間などの時間を選択します。デフォルトは10分です。

- 時間間隔: このオプションを選択した場合は、「開始日」のカレンダ・アイコンを選択します。日付および時刻を選択します。次に、「終了日」のカレンダ・アイコンを選択します。日付および時刻を選択します。

3. 「メッセージ・タイプ」セクションで、1つ以上のメッセージ・タイプを選択します。タイプについては、表12-3を参照してください。

4. 第12.3.2.1.2項の説明に従って、詳細な検索条件を指定できます。

5. 「検索」をクリックします。

6. 適合性の高いメッセージを特定しやすくするため、表内の「表示」で次のモードのいずれかを選択します。

- メッセージ: 一致するメッセージを表示します。
特定のメッセージの詳細を表示するには、該当するメッセージをクリックします。メッセージの表の下に詳細が表示されます。

関連するメッセージを表示するには、メッセージを選択して「関連メッセージの表示」をクリックし、「時間ごと」または「ECID(実行コンテキストID)ごと」を選択します。

12.3.2.1.2 ログ・ファイルの検索: 拡張検索

検索基準は、「検索」アイコンをクリックし、次の追加コントロールを使用することにより、絞り込むことができます。

- メッセージ: 「次を含む」などの演算子を選択し、比較する値を入力します。

- フィールドの追加: クリックすると、ホストなどの追加の基準を指定して、検索範囲を特定のホストに絞り込むことができます。次に、「追加」をクリックします。
追加したフィールドのそれぞれに、「次を含む」などの演算子を選択し、比較する値を入力します。

12.3.2.2 WLSTを使用したログ・ファイルの検索

WLST displayLogsコマンドを使用してログ・ファイルを検索できます。時間、コンポーネントID、メッセージ・タイプ、ECIDなどの基準を指定して検索範囲を絞り込むことができます。次に例を示します。

- Oracle HTTP Server ohs1などのシステム・コンポーネントで直前の5分以内に生成されたエラー・メッセージを検索するには、次のコマンドを使用します。

displayLogs(target='sc:ohs1', last=5)

- 管理対象サーバーwls_server_1で直前の10分以内に生成されたエラー・メッセージを検索するには、次のコマンドを使用します。

displayLogs(oracleInstance='/scratch/Oracle/config/domains/WLS_domain', target='wls_server_1', last=10)

queryパラメータを使用してコンポーネントID、メッセージ・タイプ、ECIDなどの基準を指定して、検索範囲を絞り込むことができます。query句では、表12-1にある任意の属性を使用して問合せ式を指定できます。次のような基準を使用できます。

- メッセージのタイプ。たとえば、管理対象サーバーwls_server_1のERRORおよびINCIDENT_ERRORのメッセージを検索するには、次のコマンドを使用します。

displayLogs(oracleInstance='/scratch/Oracle/config/domains/wls_domain',
target='wls_server_1',
query='MSG_TYPE eq ERROR or MSG_TYPE eq INCIDENT_ERROR')

- 特定のECID。たとえば、管理対象サーバーwls_server_1の特定のECID (0000I3K7DCnAhKB5JZ4Eyf19wAgN000001,0')のエラー・メッセージを検索するには、次のコマンドを使用します。

displayLogs(oracleInstance='/scratch/Oracle/config/domains/wls_domain',
target='wls_server_1',
query='ecid eq 0000I3K7DCnAhKB5JZ4Eyf19wAgN000001,0')

- コンポーネント・タイプ。たとえば、Oracle HTTP Serverインスタンスのメッセージを検索するには、次の問合せを使用します。

displayLogs(query='COMPONENT_ID eq ohs')

- 時間範囲。特定の時間範囲内に発生したエラー・メッセージを検索するには、次の形式で属性TSTZ_ORIGINATINGを、fromとtoの両演算子とともに指定します。

displayLogs(query='TSTZ_ORIGINATING from start_time and
TSTZ_ORIGINATING to end_time')

日付は次のISO 8601時間形式で指定します。

YYYY-MM-DDThh:mm:ss-hh:mm_offset_from_UTC

次に例を示します。

2015-03-30T12:00:00:0000-08:00

たとえば、2015年3月17日の午前8時から11時の間のエラー・メッセージを表示するには、次のコマンドを使用します。

displayLogs(query='TSTZ_ORIGINATING from 2015-03-17T08:00:00-07:00
and TSTZ_ORIGINATING to 2015-03-17T11:00:00-07:00')

- グループ・メッセージ。特定の属性でグループ化したメッセージの件数を表示するには、WLSTコマンドdisplayLogsで、groupByパラメータを使用します。たとえば、コンポーネント別にWARNINGメッセージの件数を表示する場合は、次のコマンドを使用します。

displayLogs(groupBy=['COMPONENT_ID'], query='MSG_TYPE eq WARNING')

- メッセージをサプリメンタル属性別にグループ化します。DMSイベント・トレース・コマンドを使用する場合は、宛先を作成して特定のサプリメンタル属性別にメッセージを問い合せてグループ化できます。この場合は、addDMSEventDestinationコマンドを使用して、プロパティがwriteDataAsMessageAttributesである宛先を作成します。(詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のaddDMSEventDestinationに関する項を参照してください。)
これで、ログ・メッセージを問い合せることができるようになります。たとえば、CompletingPartyにより問い合せるには、次のようにします。

displayLogs(log="DOMAIN_HOME/servers/AdminServer/logs/DMSEventTraceLoggerDestination-event.log",
groupBy=["SUPPL_ATTR.dms.NounType",
"SUPPL_ATTR.dms.NounPath",
"SUPPL_ATTR.org.service.CompletingParty"])

このコマンドにより、次の情報が返されます。

------------------------+------------------+-----------------------------+------
dms.NounType           | dms.NounPath     |org.service.CompletingParty|COUNT
-----------------------+--------------------------+-------------------+------
CallCenter_Agent       |/callAgent/Freya          | null              |    25
CallCenter_Agent       |/callAgent/Johann         | null              |    20
CallCenter_Agent       |/callAgent/Rhys           | null              |    25
CallCenter_City        |/callCenter/fr/Pau        | null              |     2
CallCenter_City        |/callCenter/fr/Vichy      | null              |     2
CallCenter_City        |/callCenter/uk/Watford    | null              |     2
CallCenter_Country     |/callCenter/de            | null              |     6
CallCenter_Country     |/callCenter/fr            | null              |     6
CallCenter_Country     |/callCenter/uk            | null              |     6
CallCenter_IncomingCall|/callCenter/fr/Pau/inCalls| agent             |    10
CallCenter_IncomingCall|/callCenter/fr/Pau/inCalls| caller            |    40

12.3.3 ログ・ファイルのダウンロード

次の各項で説明するように、Fusion Middleware ControlまたはWLSTコマンドを使用して、メッセージをダウンロードできます。

- Fusion Middleware Controlを使用したログ・ファイルのダウンロード

- Fusion Middleware Controlを使用した特定のコンポーネントのログ・ファイルのダウンロード

- Fusion Middleware Controlを使用した特定のタイプのメッセージのダウンロード

- WLSTを使用したログ・ファイルのダウンロード

12.3.3.1 Fusion Middleware Controlを使用したログ・ファイルのダウンロード

ログ・メッセージをファイルにダウンロードできます。検索で一致したメッセージまたは特定のログ・ファイル内のメッセージをダウンロードできます。

Fusion Middleware Controlを使用して、検索で一致したメッセージをダウンロードする手順は次のとおりです。

1. ナビゲーション・ペインからドメインを開き、ドメインをクリックするなどしてターゲットを選択します。

2. 「WebLogicドメイン」メニューなどの動的ターゲット・メニューから、「ログ」→「ログ・メッセージの表示」を選択します。
「ログ・メッセージ」ページが表示されます。

3. 第12.3.2.1項の説明に従って、特定のタイプのメッセージを検索します。

4. 「メッセージをファイルにエクスポート」をクリックしてファイル・タイプを選択し、次のいずれかを選択します。

- Oracle診断ログ・テキスト(.txt)として

- Oracle診断ログXML (.xml)として

- カンマ区切りリスト(.csv)として

「オープン中」ダイアログ・ボックスが表示されます。

5. 次を使用してオープンまたはディスクに保存を選択します。「OK」をクリックします。

12.3.3.2 Fusion Middleware Controlを使用した特定のコンポーネントのログ・ファイルのダウンロード

Fusion Middleware Controlを使用して、特定のコンポーネントのログ・ファイルをダウンロードする手順は次のとおりです。

1. システム・コンポーネントの場合は、ナビゲーション・ペインからインストール・タイプ(「HTTP Server」など)を展開し、コンポーネントを選択します。Javaコンポーネントの場合は、ナビゲーション・ペインからコンポーネント・タイプを展開した後、コンポーネントを選択します。

2. 動的ターゲット・メニューで、「ログ」→「ログ・メッセージの表示」を選択します。
「ログ・メッセージ」ページが表示されます。

3. 「ターゲット・ログ・ファイル」をクリックします。
「ログ・ファイル」ページが表示されます。このページに、コンポーネントまたはアプリケーションに関連するログ・ファイルのリストが表示されます。

4. ログ・ファイルを選択して、「ダウンロード」をクリックします。

5. 「オープン中」ダイアログ・ボックスが表示されます。

6. 次を使用してオープンまたはディスクに保存を選択します。「OK」をクリックします。

12.3.3.3 Fusion Middleware Controlを使用した特定のタイプのメッセージのダウンロード

特定のタイプのメッセージ、または特定のメッセージIDのメッセージをファイルにエクスポートする手順は次のとおりです。

1. ナビゲーション・ペインでドメインを展開し、ターゲットを選択します。

2. 動的ターゲット・メニューで、「ログ」→「ログ・メッセージの表示」を選択します。
「ログ・メッセージ」ページが表示されます。

3. 第12.3.2.1項の説明に従って、特定のタイプのメッセージを検索します。

4. 「表示」で「メッセージ・タイプ別グループ」または「メッセージID別グループ」を選択します。

5. メッセージをファイルにダウンロードするには、「メッセージ・タイプ別グループ」を選択した場合、列のいずれか(「エラー」列など)で、メッセージ数をリスト表示するリンクを選択します。「メッセージID別グループ」を選択した場合、「発生」列のリンクのいずれかを選択します。
「メッセージ、タイプ別」ページまたはメッセージID別のメッセージが表示されます。

6. 「メッセージをファイルにエクスポート」をクリックしてファイル・タイプを選択し、次のいずれかを選択します。

- Oracle診断ログ・テキスト(.txt)として

- Oracle診断ログXML (.xml)として

- カンマ区切りリスト(.csv)として

「オープン中」ダイアログ・ボックスが表示されます。

7. 次を使用してオープンまたはディスクに保存を選択します。「OK」をクリックします。

12.3.3.4 WLSTを使用したログ・ファイルのダウンロード

WLST displayLogsコマンドを使用し、出力をファイルにリダイレクトすることによって、ログ・ファイルをダウンロードできます。次に例を示します。

displayLogs(type=['ERROR','INCIDENT_ERROR'], exportFile='/scratch/tmp/download_log.txt')

メッセージは、指定されたディレクトリのファイルdownload_log.txtに書き込まれます。デフォルトでは、標準出力に書き込まれます。

12.4 ログ・ファイルの設定の構成

Fusion Middleware ControlまたはWLSTを使用して、管理対象サーバーおよびJavaコンポーネントのログ設定を変更できます。

注意:
第2.4.2項に記載されている多くのシステム・コンポーネントについては、Fusion Middleware Controlを使用してログ・ファイルの設定を構成できません。システム・コンポーネントのログ・ファイルに対するオプションの構成方法の詳細は、対象のコンポーネントの管理者ガイドを参照してください。

Javaコンポーネントの場合、次の各項で説明するように、ログ・ファイルの名前と場所、ログ・ファイルのサイズ、ログ・ファイルに書き込まれる情報レベル、形式、ロケール・エンコーディングを構成できます。

- ログ・ファイルの場所の変更

- ログ・ファイル・ローテーションの構成

- ログ・ファイルに書き込まれる情報レベルの設定

- ログ・ファイル形式の指定

- ログ・ファイルのロケールの指定

WLSTコマンドを使用してログ設定を構成する場合は、次の点に注意してください。

- setLogLevelなどの構成コマンドは、接続モードでのみ機能します。このため、コマンドを起動する際は、あらかじめ実行中のWebLogic Serverインスタンスに接続しておく必要があります。
構成コマンドは、WebLogic Server内で稼働するJavaコンポーネントではサポートされますが、Oracle WebLogic Serverではサポートされません。構成コマンドは、システム・コンポーネントではサポートされません。

- WLSTロギング・コマンドは、多くの場合、domainRuntimeツリーで実行する必要があります。たとえば、domainRuntimeツリーに接続して実行する場合は、次のコマンドを使用します。

connect('username', 'password', 'localhost:port_number')
domainRuntime()

- listLoggers、getLogLevelおよびsetLogLevelの各コマンドは、configおよびruntimeモードで機能します。configモードの場合、コマンドは構成ファイルで定義されたロガーに作用します。runtimeモードの場合、コマンドはサーバーJVMで定義されたロガーと直接連動します。デフォルトの場合、setLogLevelコマンドで、ランタイム・ロガーのレベルが設定され、構成ファイルのロガー定義が更新されます。デフォルトの場合、listLoggersおよびgetLogLevelコマンドではランタイム・ロガーが返されます。
コマンドの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のロギングのカスタムWLSTコマンドに関する項を参照してください。

12.4.1 ログ・ファイルの場所の変更

次の各項で説明するように、Fusion Middleware ControlまたはWLSTコマンドを使用して、ログ・ファイルの名前および場所を変更できます。

- Fusion Middleware Controlを使用したログ・ファイルの場所の変更

- WLSTを使用したログ・ファイルの場所の変更

12.4.1.1 Fusion Middleware Controlを使用したログ・ファイルの場所の変更

Fusion Middleware Controlを使用してコンポーネント・ログ・ファイルの名前および場所を変更するには:

1. ナビゲーション・ペインからコンポーネントを選択します。

2. 動的ターゲット・メニューで、「ログ」→「ログ構成」を選択します。
「ログ構成」ページが表示されます。

いくつかのコンポーネントでは、ナビゲーションが異なる場合があります。たとえば、Oracle HTTP Serverでは、「管理」→「ログ構成」を選択します。

3. 「ログ・ファイル」タブを選択します。

4. 表内で、ログ・ハンドラを選択して「編集」をクリックします。
次の図のように「ログ・ファイルの編集」ダイアログ・ボックスが表示されます。

5. 「ログ・パス」に新しいパスを入力します。

6. 「OK」をクリックします。

7. 確認ウィンドウで、「閉じる」をクリックします。

Oracle HTTP Serverログ・ファイルの場所を変更すると、access_logとohsn.logのファイルの場所は変更されますが、console~OHS~1.logの場所は変更されません。

12.4.1.2 WLSTを使用したログ・ファイルの場所の変更

WLSTを使用してログ・ファイルの場所を変更するには、 configureLogHandlerコマンドを使用します。たとえば、odl-handlerという名前のロガーのパスを変更するには、次のコマンドを使用します。

configureLogHandler(name='odl-handler', path='/scratch/Oracle/logs')

12.4.2 ログ・ファイルのローテーションの構成

bug 8520773: xmlに変更するには、log.xmlという名前を付ける必要があります。EMでは、ファイル名を指定しないとlog.xmlが作成されます。

ODLログは、現在のODLログ・ファイルと、古いメッセージが格納された0個以上のODLアーカイブ(セグメント・ファイル)を含むログ・ファイルのセットです。ログ・ファイルが拡大すると、新しい情報がログ・ファイルserver_name-diagnostic.logの最後に追加されます。ログ・ファイルがローテーション・ポイントに達すると、名前が変更されて、新しいログ・ファイルserver_name-diagnostic.logが作成されます。ローテーション・ポイントを指定するには、最大ODLセグメント・サイズまたはローテーション時間およびローテーション頻度を指定します。

ODLログ・ファイルserver_name-diagnostic.logがローテーション・ポイントに達すると、セグメント・ファイルが作成されます。このため、ファイル名server_name-diagnostic.logがserver_name-diagnostic-n.logに変更され(nは整数)、コンポーネントで新たな診断メッセージが生成されると、server_name-diagnostic.logファイルが新たに作成されます。

ODLログのサイズは、次の指定によって制限できます。

- ロギング・ディレクトリの最大サイズ。ディレクトリ内の全ファイルの合計サイズが最大値に達すると、合計サイズが指定された制限を超えないように一番古いアーカイブが削除されます。
デフォルトでは、10MBに達するとログ・ファイルはローテーションされます。特定のコンポーネントの全ログ・ファイルの最大サイズは100MBです。

- ログ・ファイルの最大サイズ。特定の時点または頻度に達したときに新しいログ・ファイルが作成されるように指定します。

注意:
ログ・ファイルのローテーションを変更すると、構成が動的にリロードされます。構成のリロードには1から2秒かかります。

次の各項目で、ローテーションを変更する方法を説明します。

- Fusion Middleware Controlを使用したログ・ファイル・ローテーションの指定

- WLSTを使用したログ・ファイル・ローテーションの指定

12.4.2.1 Fusion Middleware Controlを使用したログ・ファイル・ローテーションの指定

Fusion Middleware Controlを使用してログ・ファイルのローテーションを構成する手順は次のとおりです。

1. ナビゲーション・ペインからコンポーネントを選択します。

2. 動的ターゲット・メニューで、「ログ」→「ログ構成」を選択します。
「ログ構成」ページが表示されます。

いくつかのコンポーネントでは、ナビゲーションが異なる場合があります。たとえば、Oracle HTTP Serverでは、「管理」→「ログ構成」を選択します。

3. 「ログ・ファイル」タブを選択します。

4. 表内で、ロガーを選択して「編集」をクリックします。
「ログ・ファイルの編集」ダイアログ・ボックスが表示されます。

5. 「ローテーション・ポリシー」セクションで、次のいずれかを選択します。

- サイズ・ベース: これを選択した場合は、次を入力します。

- 「最大ログ・ファイル・サイズ」に、MB単位でサイズを入力します(例: 15)。

- 「すべてのログ・ファイルの最大サイズ」に、MB単位でサイズを入力します(例: 150)。

- 時間ベース: これを選択した場合は、次を入力します。

- 「開始時間」では、「カレンダ」をクリックし、ローテーションを開始する「日付と時間」を選択します。たとえば、September 8, 2010 6:00 AMを選択します。

- 「頻度」では、「分」を選択して何分かを入力できます。また、「時間」「日次」または「週」を選択することもできます。

- 「保存期間」では、ログ・ファイルの保存期間を指定できます。「分」を選択して何分かを入力できます。また、「日」「週」、「月」または「年」を選択することもできます。
指定する期間が短いと、使用ディスク領域が少なくなりますが、古い情報を取得できなくなります。

6. 「OK」をクリックします。

7. 確認ウィンドウで、「閉じる」をクリックします。

12.4.2.2 WLSTを使用したログ・ファイル・ローテーションの指定

WLSTを使用してログ・ファイル・ローテーションを指定するには、configureLogHandlerコマンドを使用します。サイズベース、または時間ベースのローテーションを指定できます。

たとえば、ログ・ファイルのローテーションを毎日実行し、1週間保存する場合は、次のコマンドを使用します。

configureLogHandler(name='odl-handler', rotationFrequency='daily',
retentionPeriod='week')

ログ・ファイルのサイズが5 MBを超えないこと、およびこのサイズに達するとローテーションすることを指定するには、次のコマンドを使用します。

configureLogHandler(name='odl-handler', maxFileSize='5M')

12.4.3 ログ・ファイルに書き込まれる情報レベルの設定

メッセージのタイプおよびレベルを指定して、ログ・ファイルに書き込まれる情報の量とタイプを構成できます。各メッセージ・タイプで、メッセージ・レベルに使用可能な値は1(最低重大度)から32(最高重大度)です。コンポーネントによっては、各メッセージ・タイプ別にサポートされるレベルが一部に限定されています。詳細は、ご使用のコンポーネント用の管理ガイドを参照してください。一般的には、指定が必要なのはタイプのみで、レベルの指定は必要ありません。

タイプを指定すると、Oracle Fusion Middlewareではそのタイプのすべてのメッセージと、指定したタイプ以上の重大度のメッセージが返されます。たとえば、メッセージ・タイプをWARNINGに設定した場合、Oracle Fusion MiddlewareからINCIDENT_ERRORおよびERRORのタイプのメッセージも返されます。

表12-3は、メッセージ・タイプと各タイプで最も一般的なレベルを説明しています。

表12-3 診断メッセージのタイプとレベル

メッセージ・タイプ

レベル

説明

INCIDENT_ERROR

1

製品のbugが原因の可能性があり、Oracleサポートに報告する必要がある重大な問題。

この例としては、回復不能なエラーや重大な問題があります。

ERROR

1

管理者がただちに対処する必要があり、製品のbug以外が原因の重大な問題。

この例としては、Oracle Fusion Middlewareがログ・ファイルを処理できないものの、ドキュメントに対する権限の調整によって問題の修正が可能な場合などがあります。

WARNING

1

管理者による確認を要する、潜在的な問題。

この例としては、パラメータ値が無効な場合や指定したファイルが存在しない場合などがあります。

NOTIFICATION

1

プライマリ・サブコンポーネントや機能のアクティブ化や非アクティブ化などの主要なライフサイクル・イベント。

これはNOTIFICATIONのデフォルト・レベルです。

NOTIFICATION

16

通常のイベントをレポートする粒度の詳細なレベル。

TRACE

1

パブリックAPIエントリや終了ポイントなど、管理者に重要なイベントに関するトレースまたはデバッグ情報。

TRACE

16

詳細なトレースまたはデバッグ情報で、Oracleサポートによる特定のサブシステムの問題診断に有益なもの。

TRACE

32

非常に詳細なトレースまたはデバッグ情報で、Oracleサポートによる特定のサブシステムの問題診断に有益なもの。

デフォルトは、NOTIFICATION、レベル1です。

レベル1のINCIDENT_ERROR、ERROR、WARNINGおよびNOTIFICATIONは、パフォーマンスに影響しません。その他のタイプおよびレベルについては、次の点に注意してください。

- NOTIFICATION、レベル16: パフォーマンスに対する影響は最小。

- TRACE、レベル1: パフォーマンスに対する影響は小。このレベルは、ときどき本番環境で有効化して、問題のデバッグに利用できます。

- TRACE、レベル16: パフォーマンスに対する影響は大。このレベルは、問題のデバッグなどの特殊な状況を除いて本番環境では有効にしないでください。

- TRACE、レベル32: パフォーマンスに対する影響は特大。このレベルは、本番環境で有効にしないでください。これは、テストまたは開発環境における製品のデバッグでの使用を目的としています。

表12-4は、ODL形式、Oracle WebLogic ServerおよびJava間のログ・レベルのマッピングを示しています。

表12-4 ODL、Oracle WebLogic ServerおよびJava間のログ・レベルのマッピング

ODL

WebLogic Server

Java

OFF

OFF

2147483647 - OFF

INCIDENT_ERROR:1

(EMERGENCY)

1100

INCIDENT_ERROR:4

EMERGENCY

1090

INCIDENT_ERROR:14

ALERT

1060

INCIDENT_ERROR:24

CRITICAL

1030

ERROR:1

(ERROR)

1000 - SEVERE

ERROR:7

ERROR

980

WARNING:1

WARNING

900 - WARNING

WARNING:7

NOTICE

880

NOTIFICATION:1

INFO

800 - INFO

NOTIFICATION:16

(DEBUG)

700 - CONFIG

TRACE:1

(DEBUG)

500 - FINE

TRACE:1

DEBUG

495

TRACE:16

(TRACE)

400 - FINER

TRACE:32

(TRACE)

300 - FINEST

TRACE:32

TRACE

295

次の各項で説明するように、Fusion Middleware ControlまたはWLSTコマンドを使用して、特定のログ・ファイルまたはロガーについてログ・ファイルに書き込まれたメッセージ・レベルを構成できます。

- Fusion Middleware Controlを使用したログ・ファイルのメッセージ・レベルの構成

- Fusion Middleware Controlを使用したロガーのメッセージ・レベルの構成

- WLSTを使用したメッセージ・レベルの構成

12.4.3.1 Fusion Middleware Controlを使用したログ・ファイルのメッセージ・レベルの構成

コンポーネント・ログ・ファイルのメッセージ・レベルを設定する手順は次のとおりです。

1. ナビゲーション・ペインからコンポーネントを選択します。

2. 動的ターゲット・メニューで、「ログ」→「ログ構成」を選択します。
「ログ構成」ページが表示されます。

いくつかのコンポーネントでは、ナビゲーションが異なる場合があります。たとえば、Oracle HTTP Serverでは、「管理」→「ログ構成」を選択します。

3. 「ログ・ファイル」タブを選択します。

4. 表内で、ログ・ファイルを選択して「編集」をクリックします。
次の図のように「ログ・ファイルの編集」ダイアログ・ボックスが表示されます。

5. 「ログ・レベル」でロギング・レベルを選択します。たとえば、「WARNING:1 (WARNING)」を選択します。

6. 「OK」をクリックします。

7. 確認ウィンドウで、「閉じる」をクリックします。

12.4.3.2 Fusion Middleware Controlを使用したロガーのメッセージ・レベルの構成

特定のコンポーネントの1つ以上のロガーにメッセージ・レベルを設定する手順は次のとおりです。

1. ナビゲーション・ペインからコンポーネントを選択します。

2. 動的ターゲット・メニューで、「ログ」→「ログ構成」を選択します。
「ログ構成」ページが表示されます。

いくつかのコンポーネントでは、ナビゲーションが異なる場合があります。たとえば、Oracle HTTP Serverでは、「管理」→「ログ構成」を選択します。

3. 「ログ・レベル」タブを選択します。

4. 「表示」で「ランタイム・ロガー」または「永続ログ・レベル状態のロガー」を選択します。
ランタイム・ロガーとは、現在アクティブなロガーです。永続ロガーとは、構成ファイルに保存されたロガーで、このロガーのログ・レベルはコンポーネントを再起動しても持続されます。ランタイム・ロガーは永続ロガーでもある場合がありますが、すべてのランタイム・ロガーが永続ロガーであるとはかぎりません。

5. 表内で、すべてのロガーに同一のレベルを指定するには、トップレベル・ロガーにこのロギング・レベルを選択します。次に、ロギング・レベルを親から継承しないことを指定する子ロガーに、「親から継承」を指定します。多くの場合は、これで十分です。
ただし、特定のロガーのレベルを指定する必要がある場合は、ロガーを開き、変更するロガーにロギング・レベルを選択します。たとえば、ロガーoracle.wsm.management.loggingに、「WARNING:1 (WARNING)」を選択します。

6. 「適用」をクリックします。

12.4.3.3 WLSTを使用したメッセージ・レベルの構成

WLSTを使用してメッセージ・レベルを設定するには、setLoglevelコマンドを使用します。現在のメッセージ・レベルを確認するには、getLogLevelコマンドを使用します。構成コマンドを使用する際は、あらかじめWebLogic Serverに接続しておく必要があります。

Oracle WebLogic Serverのロガーのログ・レベルを表示できます。たとえば、Oracle WebLogic Server wls_server_1のログ・レベルを表示する場合は、次のコマンドを使用します。

getLogLevel(logger='oracle',  target='wls_server_1')

NOTIFICATION:1

特定のロガーのログ・レベルを設定できます。次の例では、ロガーoracle.wsm.msg.loggingのメッセージ・タイプをWARNINGに設定しています。

setLogLevel(target='wls_server_1', logger='oracle.wsm.msg.logging', level='WARNING')

Oracle WebLogic Server wls_server_1のロガーのリストを表示するには、listLoggersコマンドを使用します。

listLoggers(target='wls_server_1')
.
.
.
oracle.wsm.msg.logging                                  | NOTIFICATION:1
oracle.wsm.nobehavior.model.NoBehaviorAssertion         | <Inherited>
oracle.wsm.policy.advertisement.AdvertisementContext    | <Inherited>
oracle.wsm.policy.model.impl.AndCompositeAssertion      | <Inherited>
.
.
.

また、パターン・パラメータと正規表現を使用して、ロガー名をフィルタ処理することもできます。たとえば、Oracle WebLogic Server wls_server_1内で名前がoracleで始まるすべてのロガーを取得するには、次のコマンドを使用します。

listLoggers(target='wls_server_1', pattern='oracle.*')

-------------------------------------------------------------------------------
Logger                                                  | Level
-------------------------------------------------------------------------------
oracle                                                    NOTIFICATION:1
oracle.adf                                               <Inherited>
oracle.adf.controller                                     <Inherited>
oracle.adf.desktopintegration                             <Inherited>
oracle.adf.faces                                          <Inherited>

12.4.4 ログ・ファイル形式の指定

デフォルトでは、情報はログ・ファイルにODLテキスト形式で書き込まれます。この形式は、次の各項で説明するように、Fusion Middleware ControlまたはWLSTコマンドを使用してODL XML形式に変更できます。

- Fusion Middleware Controlを使用したログ・ファイル形式の指定

- WLSTを使用したログ・ファイル形式の指定

12.4.4.1 Fusion Middleware Controlを使用したログ・ファイル形式の指定

Fusion Middleware Controlを使用して形式を変更する手順は次のとおりです。

1. ナビゲーション・ペインからコンポーネントを選択します。

2. 動的ターゲット・メニューで、「ログ」→「ログ構成」を選択します。
「ログ構成」ページが表示されます。

いくつかのコンポーネントでは、ナビゲーションが異なる場合があります。たとえば、Oracle HTTP Serverでは、「管理」→「ログ構成」を選択します。

3. 「ログ・ファイル」タブを選択します。

4. 表内で、ログ・ファイルを選択して「編集」をクリックします。
「ログ・ファイルの編集」ダイアログ・ボックスが表示されます。

5. 「ログ・ファイル形式」で、「Oracle Diagnostics Logging - テキスト」または「Oracle Diagnostics Logging - XML」を選択します。

6. 「OK」をクリックします。

7. 確認ウィンドウで、「閉じる」をクリックします。

12.4.4.2 WLSTを使用したログ・ファイル形式の指定

WLSTを使用してログ・ファイル形式を指定するには、configureLogHandlerコマンドを使用します(formatパラメータを使用し、ODL-TextまたはODL-XMLを指定します)。デフォルトはODL-Textです。

たとえば、ODL-XML形式を指定するには、次のコマンドを使用します。

configureLogHandler(name='odl-handler', format='ODL-XML')

12.4.5 ログ・ファイルのロケールの指定

ログ・ファイルで使用される言語形式およびデータ形式は、サーバーJava仮想マシン(JVM)のデフォルトのロケールで決定されます。これを変更するには、Windowsの場合は「コントロール パネル」の「言語と地域のオプション」を使用し、UNIXプラットフォームの場合は環境変数のLANGおよびLC_ALLを使用します。

ログ・ファイルの文字エンコーディングは、サーバーJVMのデフォルトの文字エンコーディングまたはオプションの構成設定によって決定されます。ユーザーが使用するすべての言語をサポートするエンコーディングを選択する必要があります。選択しないと、ログ・ファイルが破損する可能性があります。デフォルトでは、ログはサーバーJVMのデフォルトのキャラクタ・エンコーディングを使用します。エンコーディングを変更する場合、別のエンコーディングで追加された新しいログによって破損しないように、古いログを削除するか、またはその名前を変更します。

どのような言語でもサポートできるようにするには、Unicode UTF-8エンコーディングを使用することをお薦めします。UNIXオペレーティング・システムでは、環境変数LANGおよびLC_AllをUTF-8文字セットのロケールに設定すると、UTF-8ロギングが可能になります(たとえば、UTF-8エンコーディングのUSロケールは、en_US.UTF-8)。

次の各項で説明するように、ログ・ファイルのロケールを指定するには、WLSTコマンドを使用するか、またはファイルを編集します。

- WLSTを使用したログ・ファイルのエンコーディングの指定

- logging.xmlでのログ・ファイルのエンコーディングの指定

12.4.5.1 WLSTを使用したログ・ファイルのエンコーディングの指定

WLSTを使用してログ・ファイルのエンコーディングを指定するには、configureLogHandlerコマンドを使用します。エンコーディング・パラメータを使用して、文字セットのエンコーディングを指定できます。

たとえば、UTF-8を指定するには、次のコマンドを使用します。

configureLogHandler(name="odl-handler", encoding="UTF-8")

12.4.5.2 logging.xmlでのログ・ファイルのエンコーディングの指定

logging.xmlファイルでログ・ファイルのエンコーディングを指定するには、オプションのエンコーディング・プロパティを使用して、文字セットのエンコーディングを指定します。

logging.xmlファイルは、次のディレクトリにあります。

DOMAIN_HOME/config/fmwconfig/servers/server_name/

たとえば、UTF-8を指定するには、log_handler要素に次のエンコーディング・プロパティを追加します。

<property name='encoding' value='UTF-8'/>

12.5 ログ・ファイルおよびコンポーネント間のメッセージの関連付けの理解

Oracle Fusion Middlewareコンポーネントは、診断メッセージにメッセージ相関情報を提供します。メッセージ相関情報は、診断メッセージを表示したユーザーがコンポーネント間のメッセージの関係を判定する際に役立ちます。この項では、次の項目について説明します。

- メッセージの関連付けでのECIDおよびRIDの理解

- メッセージおよびコンポーネント間のメッセージの関連付け

12.5.1 メッセージの関連付けでのECIDおよびRIDの理解

診断メッセージのそれぞれに、実行コンテキストID (ECID)と関係ID (RID)が組み込まれています。

- ECIDは、特定リクエストの実行に関連付けられたグローバル一意識別子です。ECIDは、リクエストを最初に処理したときに生成されます。

- RIDは、1つのリクエストにおいて、特定のプロセス上の特定スレッドで実行された作業と、同じプロセス上の別スレッドおよび別プロセス上で実行された作業を区別します。

ECIDとRIDを利用すると、ログ・ファイル・エントリを使用して、特定のアプリケーションとOracle Fusion Middlewareコンポーネント間のメッセージを関連付けることができます。メッセージ相関情報を使用して関連メッセージを検索すると、複数のメッセージを調べることができ、最初に問題が発生したコンポーネントを特定できます(この方法は、最初に障害が発生したコンポーネントの切分けと呼ばれます)。メッセージ相関データを使用すると、コンポーネント全体における診断メッセージのパスが明確になり、エラーや関連する動作を把握できます。

ECIDおよびRIDを使用して、Oracle Fusion Middleware内を移動するリクエストをトラッキングできます。

次に、ECIDの例を示します。

0000I3K7DCnAhKB5JZ4Eyf19wAgN000001,0

RIDはコロン(:)で区切られた1つ以上の数字で示されます。特定のリクエストに対して最初に作成されるRIDは0です。ECIDが関連付けられているスレッドから別のスレッドまたはプロセスに作業が渡されるたびに、作成者との関係をエンコードする新たなRIDが生成されます。つまり、新しい世代が生成されます。世代が推移するたびに、コロンと数値が追加されます。たとえば、リクエストの作成者の3番目の子の7番目の子は、次のように示されます。

0:3:7

12.5.2 メッセージおよびコンポーネント間のメッセージの関連付け

WLSTのdisplayLogsコマンドを使用して、同一のECIDのメッセージをすべて表示できます。次の例は、ドメインでECIDを検索します。

displayLogs(ecid='0000Hl9TwKUCslT6uBi8UH18lkWX000002')

ターゲット・オプションで指定することにより、WebLogic Serverインスタンスやシステム・コンポーネントでECIDを検索することも可能です。

Fusion Middleware Controlの「ログ・メッセージ」ページで特定のECIDを持つメッセージを検索できます。

1. 「WebLogicドメイン」メニューで、「ログ」→「ログ・メッセージの表示」を選択します。
特定のコンポーネントまたはアプリケーションのメッセージを検索する際は、該当するコンポーネントまたはアプリケーションを選択し、そのターゲットのメニューから「ログ」→「ログ・メッセージの表示」を選択します。

2. 第12.3.2.1.2項の説明に従って、検索条件を指定します。

3. 「検索」をクリックします。

4. メッセージを選択して「関連メッセージの表示」をクリックし、「ECID(実行コンテキストID)ごと」を選択します。
次の図のように、ECIDが同じメッセージが表示されます。

5. 最も古いメッセージまでECIDをトレースします。(場合によってはそのECIDを持つ最初のメッセージが表示されるまで範囲を拡大する必要があります。)

12.6 トレースの構成

場合によっては、問題を解決するために、通常のログに記録されるよりも多くの情報が必要になることがあります。これを実現する方法の一つは、1つまたは複数のコンポーネントで記録されるログのメッセージ・レベルを上げることです。たとえば、第12.4.3項で説明されているように、ロギング・レベルをTRACE:1やTRACE:32に設定できます。これにより、より詳細なメッセージがログ・ファイルに書き込まれるようになります。これをトレースと呼びます。

ただし、多くの場合、これによってログ・ファイルに大量のログ・メッセージが書き込まれるようになります。Oracle Fusion Middlewareでは、トレース対象のメッセージを細かく調整するために次のメカニズムを使用できます。

- QuickTrace。メモリーに対してきめ細かなロギングを行います。

- 選択的トレース。リクエスト内の特定のユーザーまたは他のプロパティについて、きめ細かなロギングを行います。

次の各項では、これらのメカニズムの使用方法について説明します。

- QuickTraceの構成と使用

- 選択的トレースの構成と使用

12.6.1 QuickTraceの構成と使用

QuickTraceでは、メモリーに対するきめ細かなロギングが行われます。次の各トピックでは、QuickTraceおよびその有効化と使用方法について説明します。

- QuickTraceの理解

- QuickTraceの構成

- ファイルへのトレース・メッセージの書込み

- WLSTを使用したQuickTraceの無効化

12.6.1.1 QuickTraceの理解

QuickTraceを使用すると、特定のロガーのメッセージをトレースして、そのメッセージをメモリーに格納できます。QuickTraceではメッセージがメモリーに記録されるため、フォーマット設定、文字列操作および入出力操作に伴うコストが回避されます。そのため、パフォーマンスのオーバーヘッドを気にすることなく、特定のロガーに対して詳細レベルでのアプリケーション・ロギングを有効化できます。

デフォルトでは、QuickTraceは1つの共通バッファにメッセージを書き込みます。一方で、特定のユーザーのメッセージが個別のバッファに書き込まれるように指定できます。

メモリーに格納されたメッセージは、Fusion Middleware ControlでQuickTraceダンプを起動する(第12.6.1.3.1項を参照)か、WLSTを使用する(第12.6.1.3.2項を参照)ことによってファイルに保存できます。

QuickTraceを有効にするには、QuickTraceハンドラを作成してロガーに関連付けます。ハンドラには、バッファ・サイズなどの属性を指定できます。続いて、ロガーがメモリーに書き込む情報の量およびタイプのレベルを設定します。

12.6.1.2 QuickTraceの構成

次の各トピックで説明するように、Fusion Middleware ControlまたはWLSTを使用して、QuickTraceを構成および使用できます。

- Fusion Middleware Controlを使用したQuickTraceの構成

- WLSTを使用したQuickTraceの構成

12.6.1.2.1 Fusion Middleware Controlを使用したQuickTraceの構成

Fusion Middleware Controlを使用してQuickTraceを構成する手順は次のとおりです。

1. ナビゲーション・ペインからドメインを展開します。管理対象サーバー名を右クリックして、「ログ」→「ログ構成」を選択します。
「ログ構成」ページが表示されます。

2. 「QuickTrace」タブを選択します。

3. 「作成」をクリックします。
次の図に示すように、「QuickTraceハンドラの作成」ダイアログ・ボックスが表示されます。

4. 「名前」に、ハンドラの名前を入力します。

5. 「バッファ・サイズ」に、ログ・メッセージをメモリーに格納するためのバッファ・サイズ(バイト)を入力します。デフォルトは5242880です。

6. 「最大フィールド長」に、メッセージの各フィールドの長さ(バイト)を入力します。フィールドには、メッセージ・テキスト、サプリメンタル属性およびスレッド名を含めることができます。デフォルトは240です。
各メッセージのフィールドが長すぎると、バッファ内に格納できるログ・レコードの量が少なくなります。

7. 「ハンドラ・レベル」で、ハンドラのログ・レベルを選択します。レベルについては、第12.4.3項を参照してください。

8. 「関連付けるロガー」で、このQuickTraceハンドラに関連付けるロガーを選択します。これらのハンドラに指定されたレベルのメッセージはすべて、メモリーに書き込まれます。
様々なロガーが他のハンドラに関連付けられています。たとえば、oracle.adfロガーは、ハンドラodl-handler、wls-domainおよびconsole-handlerに関連付けられています。ロガーのレベルを設定すると、これらのハンドラはロガー(oracle.adfなど)に対して同一のレベル(TRACE:1など)を使用します。そのため、ログ・ファイルに大量の情報が書き込まれ、リソースが消費されます。リソースの消費を回避するには、ハンドラのレベルを低いレベル(WARNINGやINFORMATIONなど)に設定します。

9. ユーザー・バッファを有効にする場合は、「ユーザー・バッファを有効化しますか。」を選択します。これを有効にすると、ハンドラは、指定された各ユーザーに対して個別のバッファを保持します。
続いて、「予備バッファのユーザー名」に、カンマ区切りのユーザー名を入力します。

10. 残りのオプションについては、デフォルト値を受け入れます。オプションの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のConfigureLogHandlerに関する項を参照してください。

11. 「OK」をクリックします。

12. 構成処理が完了したら、「OK」をクリックします。

これで、指定したロガーの指定したレベルのメッセージが、メモリーに書き込まれるようになりました。

12.6.1.2.2 WLSTを使用したQuickTraceの構成

WLSTを使用してQuickTraceを構成するには、configureLogHandlerコマンドを使用して、ロガーをQuickTraceハンドラに関連付けます。

たとえば、oracle.adfロガーをQuickTraceハンドラに関連付けて、TRACE:1のメッセージをすべてメモリーに書き込む手順は次のとおりです。

1. configureLogHandlerコマンドを使用して、ロガーをQuickTraceハンドラに関連付けます。

configureLogHandler(name="quicktrace-handler", addToLogger="oracle.adf")

Handler Name: quicktrace-handler
type:   oracle.core.ojdl.logging.QuickTraceHandlerFactory
encoding:       UTF-8
maxFieldLength: 240
mode:   objRef
useThreadName:  false
useSourceClassandMethod:        false
useLoggingContext:      false
bufferSize:     5242880

ハンドラのメッセージが共通バッファに書き込まれます。

QuickTraceハンドラに追加のプロパティを設定できます。たとえば、user1およびuser2のユーザー・バッファを有効にするには次のようにします。

configureLogHandler(name="quicktrace-handler", addToLogger="oracle.adf.faces",
propertyName="enableUserBuffer", propertyValue="true",
propertyName="enableUserBuffer", propertyValue="user1, user2")
...
Handler Name: quicktrace-handler
type:   oracle.core.ojdl.logging.QuickTraceHandlerFactory
useLoggingContext:      false
bufferSize:     5242880
.
.
.
reserveBufferUserID:    user1, user2
enableUserBuffer:       true

user1およびuser2のメッセージは別々のバッファに書き込まれます。また、他のユーザーに関連するメッセージは共通バッファに書き込まれます。

ハンドラの設定を確認するには、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のlistLogHandlersに関する項の説明に従って、listLogHandlersコマンドを使用します。

2. setLogLevelコマンドを使用して、ロガーのレベルを設定します。

setLogLevel(logger='oracle.adf', level='TRACE:1')

ロガーの設定を確認するには、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のlistLoggersに関する項の説明に従って、listLoggersコマンドを使用します。

3. 様々なロガーが他のハンドラに関連付けられています。たとえば、oracle.adfロガーは、ハンドラodl-handler、wls-domainおよびconsole-handlerに関連付けられています。ロガーのレベルを設定すると、これらのハンドラはロガーoracle.adfに対して同一のレベル(TRACE:1)を使用します。そのため、ログ・ファイルに大量の情報が書き込まれ、リソースが消費されます。リソースの消費を回避するには、ハンドラのレベルを低いレベル(WARNINGやINFORMATIONなど)に設定します。
次の例では、3つのハンドラのレベルをWARNING:1に設定します。

configureLogHandler(name="odl-handler", level="WARNING:1")
configureLogHandler(name="wls-domain", level="WARNING:1")
configureLogHandler(name="console-handler", level="WARNING:1")

QuickTraceハンドラのレベルは、ALL(デフォルト)のままにしておいてください。

詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のconfigureLogHandlerに関する項を参照してください。

このハンドラのレベルを確認するには、第12.4.3.3項の説明に従ってgetLogLevelコマンドを使用します。

12.6.1.3 ファイルへのトレース・メッセージの書込み

次の各トピックで説明するように、Fusion Middleware ControlまたはWLSTを使用して、トレース・メッセージをファイルに書き込めます。

- Fusion Middleware Controlを使用したトレース・メッセージのファイルへの書き込み

- WLSTを使用したトレース・メッセージのファイルへの書き込み

12.6.1.3.1 Fusion Middleware Controlを使用したトレース・メッセージのファイルへの書き込み

Fusion Middleware ControlでQuickTraceダンプを起動して、メモリーに格納されたメッセージをファイルに保存できます。

1. 「ログ構成」ページの「QuickTrace」タブで、ハンドラを選択し、「QuickTraceダンプの起動」をクリックします。
「QuickTraceダンプの起動」ダイアログ・ボックスが表示されます。

2. QuickTraceハンドラの構成時にユーザー・バッファを指定した場合は、「バッファ名」でユーザーを選択するか、指定しなかったユーザーに対して「共通バッファ」を選択します。いずれのユーザー・バッファも選択しなかった場合には、「共通バッファ」のみを選択できます。

3. 「OK」をクリックします。
処理が完了すると、「ログ・メッセージの表示」ページが表示されます。

4. 第12.3.2項の説明に従って、メッセージを検索できます。また、第12.5項の説明に従って、メッセージを関連付けることができます。
さらに、第12.3.3.1項.の説明に従って、メッセージをファイルにダウンロードすることもできます。

12.6.1.3.2 WLSTを使用したトレース・メッセージのファイルへの書き込み

メッセージをファイルに保存するには、executeDumpコマンドを使用します。

次に例を示します。

executeDump(name="odl.quicktrace", outputFile="/scratch/oracle1/qt1.dmp")

コマンドにより、指定したファイルにダンプが書き込まれます。

executeDumpコマンドの詳細は、第13.4.4.3項.を参照してください。

また、インシデントが(自動または手動で)作成されると、インシデント・ディレクトリのダンプ・ファイルにQuickTraceメッセージが書き込まれます。ユーザー・バッファを有効にしている場合、各ユーザーは1つのファイルを使用します。また、共通バッファでも1つのファイルを使用します。

ファイル名のフォーマットは次のとおりです。

odl_quicktraceN_iincident_number.username.dmp

次に例を示します。

odl_quicktrace6_i1.weblogic.dmp

インシデントの作成については、第13.4.6.1項を参照してください。

12.6.1.4 WLSTを使用したQuickTraceの無効化

QuickTraceを無効化するには、WLSTのconfigureLogHandlerコマンドを使用して、levelにOFFを指定します:

configureLogHandler(name="quicktrace-handler", level="OFF")

Handler Name: quicktrace-handler
type:   oracle.core.ojdl.logging.QuickraceHandlerFactory
.
.
.
reserveBufferUserID:    user1, user2
enableUserBuffer:       true

QuickTraceハンドラの関連付けから特定のロガーを削除するには、configureLogHandlerコマンドを使用してremoveFromLoggerパラメータを指定します。

configureLogHandler(name="quicktrace-handler", removeFromLogger="oracle.adf.faces")

Handler Name: quicktrace-handler
type:   oracle.core.ojdl.logging.QuickraceHandlerFactory
reserveBufferUserID:    user1, user2
enableUserBuffer:       true

詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のconfigureLogHandlerに関する項を参照してください。

12.6.2 選択的トレースの構成と使用

選択的トレースは、リクエスト内の指定したユーザーまたは他の属性について、きめ細かなロギングを行います。

次の各トピックでは、選択的トレースと、Fusion Middleware ControlまたはWLSTを使用した選択的トレースの管理方法について説明します。

- 選択的トレースの理解

- 選択的トレースの構成

- 選択的トレースの表示

- 選択的トレースの無効化

12.6.2.1 選択的トレースの理解

選択的トレースは、リクエスト内の指定したユーザーまたは他の属性について、きめ細かなロギングを行います。

たとえば、セキュリティ権限が原因で、あるユーザーが一部の機能を実行できない場合に、どの操作に問題があるのか、あるいはどの操作の権限が不足しているのか、わからないことがあります。

このような場合、システム全体を通じてトレースを有効にすることもできますが、そうすることで問題のあるユーザーのみならず、システム内のすべてのユーザーに対してログ・メッセージが大量に生成されることになります。選択的トレースを使用すると、問題のあるユーザーのみに対してトレースを有効化できます。また、機能を再試行するかどうか、そのユーザーに尋ねることができます。そして、そのユーザーが行った特定のリクエストに該当するトレース・メッセージを調べることができます。

ロガーを指定して、ログに記録されるメッセージの範囲を絞り込むこともできます。

12.6.2.2 選択的トレースの構成

次の各トピックで説明するように、Fusion Middleware ControlまたはWLSTを使用して、選択的トレースを構成できます。

- Fusion Middleware Controlを使用した選択的トレースの構成

- WLSTを使用した選択的トレースの構成

12.6.2.2.1 Fusion Middleware Controlを使用した選択的トレースの構成

Fusion Middleware Controlを使用して選択的トレースを構成する手順は次のとおりです。

1. ナビゲーション・ペインからドメイン名を右クリックして、「ログ」、「選択的トレース」の順に選択します。
次の図に示すように、「選択的トレース」ページが表示されます。

2. 「アプリケーション名」で、アプリケーションを選択します。

3. さらにフィールドを追加するには、「フィールドの追加」をクリックし、いずれかのオプション(「クライアント・ホスト」や「ユーザー名」など)を選択します。

4. 「レベル」で、ロギング・レベルを選択します。表12-3にロギング・レベルを示します。

5. 「説明」に、説明を入力します。

6. 「期間」に、選択的トレースの実行時間を分単位で入力します。
指定した時間を過ぎると、選択的トレースは無効化されます。

7. 「トレースID」で、「一意の新規トレースIDの生成」または「カスタム・トレースIDの使用」のいずれかを選択します。「カスタム・トレースIDの使用」を選択する場合は、任意の選択IDを入力しますが、それが一意のIDであることを確認してください。Fusion Middleware Controlは、IDの一意性を検証しません。

8. 「ODL」セクションで、「有効化」を選択します。

9. 「DMS」セクションで、「有効化」を選択します。

10. デフォルトでは、「ロガー」セクションで、すべてのロガーが選択されています。
トレースする特定のロガーを選択できます。特定のロガーを検索するには、表の上部にあるフィールドに文字列を入力して、[Return]キーを押します。たとえば、「oracle.security」で始まるロガーをすべて検索するには、「oracle.security」と入力します。

続いて、表の「すべてのサーバーで有効化しますか。」列でロガーを選択します。

ロガーを選択すると、それらのロガーは、現在アクティブなすべてのトレースに適用されます。また、ロガーを無効にした場合でも、すべてのロガーで一般的なロギング・レベル(Notificationなど)が使用されているため、メッセージが表示される場合があります。これらのメッセージは、引き続き書き込まれます。

11. 「トレースを開始」をクリックします。

これで、トレースが開始されました。第12.6.2.3.1項の説明に従って、アクティブなトレースと以前のトレースを表示できます。

12.6.2.2.2 WLSTを使用した選択的トレースの構成

WLSTのconfigureTracingLoggersコマンドとstartTracingコマンドを使用して、選択的トレースのロガーを構成し、トレースを開始できます。

最も簡単に行うには、startTracingコマンドを使用してトレースを構成および開始します。これを行うと、選択的トレースが有効化されているすべてのロガーが選択的トレースに含まれます。

たとえば、user1は特定の操作を実行しようとするとエラーを受け取ります。user1に関連するメッセージのトレースを開始して、ロギング・レベルをFINEに設定するには、次のコマンドを使用します。

startTracing(user="user1",level="FINE")
Started tracing with ID: 885649f7-8efd-4a7a-9898-accbfc0bbba3

startTracingコマンドには、特定のロガーを含めるまたは除外するためのオプションはありません。そのような場合には、configureTracingLoggersコマンドを使用します。このコマンドを使用すると、特定のロガーと特定のOracle WebLogic Serverインスタンスのみを含むように選択的トレースを構成できます。指定するオプションは、現在アクティブなすべてのトレースに適用されます。

たとえば、セキュリティ関連のロガーのみを含むように選択的トレースを構成する手順は次のとおりです。

1. 次の例に示すように、トレースに関するすべてのロガーが無効化されるように指定します。

configureTracingLoggers(action="disable")
Configured 1244 loggers

2. 正規表現でパターン・オプションを指定して、セキュリティ関連のロガーを有効化します。

configureTracingLoggers(pattern='oracle.security.*', action="enable")
Configured 62 loggers

選択的トレースをサポートするロガーのリストを表示するには、次の例に示すように、WLSTのlistTracingLoggersコマンドを使用します。

listTracingLoggers(pattern="oracle.security.*")
------------------------------------------------------------------+--------
Logger                                                            | Status
------------------------------------------------------------------+--------
oracle.security                                                   | enabled
oracle.security.audit.logger                                      | enabled
oracle.security.jps.az.common.util.JpsLock                        | enabled
.
.
.

3. startTracingコマンドを使用して、ユーザーとレベルを指定します。次に例を示します。

startTracing(user="user1",level="FINE")
Started tracing with ID: a9580e65-13c4-420b-977e-5ba7dd88ca7f

完全な構文については、『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』の次のコマンドに関する説明を参照してください。

- 「configureTracingLoggers」

- 「startTracing」

- 「listTracingLoggers」

12.6.2.3 選択的トレースの表示

次の各トピックで説明するように、Fusion Middleware ControlまたはWLSTを使用して、選択的トレースを表示できます。

- Fusion Middleware Controlを使用した選択的トレースの表示

- WLSTを使用した選択的トレースの表示

12.6.2.3.1 Fusion Middleware Controlを使用した選択的トレースの表示

現在アクティブな選択的トレースおよび選択的トレースの履歴を表示できます。

選択的トレースを表示する手順は次のとおりです。

1. 「選択的トレース」ページで、「アクティブなトレースとトレース履歴」タブを選択します。
次の図に示すように、アクティブなトレースの表とトレース履歴の表がタブに表示されます。

2. トレースを表示するには、該当する表からトレースを選択します。
「ログ・メッセージ」ページが表示され、選択的トレースで収集されたメッセージが表示されます。第12.3.2項の説明に従って、メッセージを検索できます。また、第12.5項の説明に従って、メッセージを関連付けることができます。

さらに、第12.3.3.1項.の説明に従って、メッセージをファイルにダウンロードすることもできます。

12.6.2.3.2 WLSTを使用した選択的トレースの表示

トレースを開始した後で、次の例に示すように、listActiveTracesコマンドを使用してアクティブなトレースを表示できます。

listActiveTraces()
-------------------------------------+----------+-----------+------+-----------+-----------
Trace ID                             |Attr. Name|Attr. Value| Level| Exp. Time |Description
-------------------------------------+----------+-----------+------+-----------+-----------
b73b351c-9a9b-47df-b05a-356a336d5780 | USER_ID  | user1     | FINE | 5/22/13 11:17 AM |
a9580e65-13c4-420b-977e-5ba7dd88ca7f |USER_ID   |user1      | FINE | 5/22/13 11:19 AM |

トレースの内容を表示するには、displayLogsコマンドを使用してトレースIDを渡します。停止されたトレースを表示することもできます。次に例を示します。

displayLogs("a9580e65-13c4-420b-977e-5ba7dd88ca7f")

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のlistActiveTracesに関する項を参照してください。

12.6.2.4 選択的トレースの無効化

次の各項で説明するように、WLSTを使用して、選択的トレースの構成、トレースの表示および選択的トレースの無効化を行うことができます。

- Fusion Middleware Controlを使用した選択的トレースの無効化

- WLSTを使用した選択的トレースの無効化

12.6.2.4.1 Fusion Middleware Controlを使用した選択的トレースの無効化

Fusion Middleware Controlを使用して選択的トレースを無効化する手順は次のとおりです。

1. ナビゲーション・ペインからドメイン名を右クリックして、「ログ」、「選択的トレース」の順に選択します。

2. 「アクティブなトレースとトレース履歴」タブを選択します。

3. 「アクティブなトレース」表で、トレースを選択して「無効化」をクリックします。

12.6.2.4.2 WLSTを使用した選択的トレースの無効化

システムで過度のロギングが行われないようにするには、必要な情報を取得した後で選択的トレースを無効化します。選択的トレースを無効化するには、WLSTのstopTracingコマンドを使用して、トレースIDまたはユーザーを渡します。次に例を示します。

stopTracing(traceId="885649f7-8efd-4a7a-9898-accbfc0bbba3")
Stopped 1 traces

stopAllオプションを使用して、すべてのトレースを無効化することもできます。次に例を示します。

stopTracing(stopAll=1)

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のstopTracingに関する項を参照してください。

13 問題の診断

この章では、問題を解決したり、解決のためにOracleサポートに送信したりできるように、Oracle Fusion Middleware診断フレームワークを使用して問題に関する情報の収集および管理をする方法について説明します。

この章の構成は、次のとおりです。

- 診断フレームワークの理解

- 診断フレームワークの動作

- 診断フレームワークの構成

- 問題の調査、報告および解決

- ヘルス・テスト・フレームワークの管理および実行

13.1 診断フレームワークの理解

Oracle Fusion Middlewareには、問題の検出、診断および解決を支援する診断フレームワークが含まれています。特に対象としている問題は、コードのbug、メタデータの破損、顧客データの破損、スレッドのデッドロック、一貫性のない状態に起因する障害などのクリティカル・エラーです。

クリティカル・エラーが発生すると、そのエラーにはインシデント番号が割り当てられ、エラーの診断ログ(ログ・ファイルなど)が即座に取得され、その番号でタグ付けされます。データは、自動診断リポジトリ(ADR)に格納されます。ADRでは、後でデータをインシデント番号によって取得し、分析することができます。

診断フレームワークの目標は、次のとおりです。

- 初期障害の診断

- 問題が検出された後の損害および中断の抑制

- 問題の診断時間の短縮

- 問題の解決時間の短縮

- 顧客とOracleサポートのやり取りの簡略化

診断フレームワークに組み込まれているテクノロジは次のとおりです。

- 初期障害時の診断データの自動取得: クリティカルなエラーの場合、初期障害の段階でエラー情報を取得できると、問題が早期に解決され停止時間が短縮される可能性が大幅に増加します。診断フレームワークでは、スレッド・ダンプ、DMSメトリック・ダンプ、WebLogic診断フレームワーク(WLDF)のサーバー・イメージ・ダンプなどの診断情報を自動的に収集します。このような診断データは、飛行機のフライト・レコーダ「ブラック・ボックス」で収集されるデータに似ています。問題が検出されると、アラートが生成されて、障害診断インフラストラクチャがアクティブになり、診断データが取得されて格納されます。データはファイルベース・リポジトリに格納され、コマンド行ユーティリティでアクセスできます。

- 標準化されたログ形式: (ODLログ・ファイル形式を使用して)Oracle Fusion Middlewareのすべてのコンポーネントにわたってログ形式が標準化されていると、管理者およびOracleサポートのスタッフが、問題を分析するためのツールの単一セットを使用できます。問題の診断はさらに容易となり、停止時間は短縮されます。

- 診断ルール: それぞれのコンポーネントでは、特定のログ・メッセージによりインシデントを作成するかどうか、およびどのダンプを実行するかを評価する際に使用する診断ルールを定義します。診断ルールでは、個々のダンプの作成を同期で行うか非同期で行うかということも示します。
また、ドメイン、サーバーあるいはドメインまたはサーバー内のアプリケーションに適用されるカスタム・ルールを定義できます。

- インシデント検出ログ・フィルタ: インシデント検出ログ・フィルタには、java.util.loggingフィルタが実装されています。これにより、それぞれのログ・メッセージを検証し、コンポーネントおよびアプリケーションの診断ルールに基づいて、インシデントを作成するかどうかを判断します。

- インシデント・パッケージ化サービス(IPS)およびインシデント・パッケージ: IPSを使用すると、対応するインシデントのあるクリティカル・エラーに関する診断データ(ログ・ファイル、ダンプ、レポートなど)を自動的かつ容易に収集し、それらのデータをzipファイルにパッケージ化してOracleサポートに転送できます。診断フレームワークで検出されたクリティカル・エラーに関連する診断データはすべて、インシデントとして取得され、ADRに格納されます。インシデント・パッケージ化サービスでは、必要なファイルを自動的に特定してzipファイルに追加します。
zipファイルを作成する前に、IPSはまず、インシデント・パッケージという中間論理構造に診断データを収集します。パッケージは自動診断リポジトリに格納されます。必要に応じて、この中間論理構造にアクセスして、その内容を表示および修正したり、詳細な診断データをいつでも追加または削除できます。さらに、準備ができたらパッケージからzipファイルを作成し、Oracleサポートにアップロードできます。

- WebLogic診断フレームワーク(WLDF)との統合: Oracle Fusion Middleware診断フレームワークでは、クリティカル・エラー検出時にWebLogic Serverのイメージを取得するなど、WebLogic診断フレームワーク(WLDF)の一部の機能を統合しています。WLDFは、モニタリングと診断を行うフレームワークであり、WebLogic Serverプロセス内で稼働してサーバーの標準的なライフサイクルの一部となる一連のサービスを定義および実装します。WLDFを使用して、稼働中のサーバー、およびコンテナ内にデプロイされたアプリケーションで生成された診断データを作成、収集、分析、アーカイブし、そのデータにアクセスできます。このデータにより、サーバーおよびアプリケーションの実行時のパフォーマンスに関する指標が提供され、障害発生時に失敗を隔離して診断することができます。
Oracle Fusion Middleware診断フレームワークは、次のようなWLDFのコンポーネントと統合しています。

- WLDFポリシーおよびアクション。指定された条件の特定のログおよびメトリックを監視し、条件が満たされると通知を送信します。通知には、JMX通知や診断イメージを作成する通知など、いくつかの種類があります。Oracle Fusion Middleware診断フレームワークは、WLDFポリシーおよびアクション・コンポーネントと統合してインシデントを作成します。

- 診断イメージ・キャプチャ。問題の診断に使用される、サーバーの主要な状態の最も一般的なソースを収集します。これは、その状態を単一のアーティファクト、診断イメージにパッケージ化します。Oracle Fusion Middleware診断フレームワークにより、アーティファクトはADRに書き込まれます。

WLDFの詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。

13.1.1 インシデントと問題について

クリティカル・エラーを円滑に診断および解決するために、診断フレームワークには、問題とインシデントという、Oracle Fusion Middlewareの2つの概念が導入されています。

問題とは、クリティカル・エラーです。クリティカル・エラーは、内部エラーなどのサーバー・エラーとして発生します。問題はADRで追跡されます。各問題には、問題を説明する文字列である問題キーがあります。これには、エラー・コード(XXX-nnnnnという形式)と、場合によってはエラー固有の他の値が含まれます。

インシデントとは、問題の1回の発生です。問題(クリティカル・エラー)が複数回発生すると、インシデントはそれぞれの発生分に対して作成されます。インシデントにはタイムスタンプが付与され、ADRで追跡されます。それぞれのインシデントは数字のインシデントIDで識別されます。このインシデントIDは、ADRホーム内で一意です。インシデントが発生すると、診断フレームワークでは次の処理を実行します。

- インシデントに関する初期障害診断データをダンプ・ファイルの形式(インシデント・ダンプ)で収集します。

- そのインシデント用に作成されたADRサブディレクトリにインシデント・ダンプを格納します。

- インシデント・ダンプをインシデントとともにADRに登録します。

13.1.1.1 インシデントのフラッド制御

問題によって、短期間の間に数十、場合によっては数百ものインシデントが生成されることも考えられます。その場合、生成される診断データが多すぎて、ADRの領域が大量に消費され、問題の診断および解決に手間がかかることにもなります。そのため、診断フレームワークでは、特定のしきい値に達したときにインシデントの生成に対してフラッド制御を適用します。フラッド制御インシデントは、ADRに記録されないインシデントです。かわりに、診断フレームワークによって、WARNINGレベルのメッセージがログ・ファイルに書き込まれ、oracle.dfw.incident.Incidentオブジェクトが返されます。フラッド制御インシデントは、診断データによりシステムに過大な負荷をかけることなく、クリティカル・エラーが継続的に発生していることを知らせる手段となります。

デフォルトでは、問題キーが同じインシデントが60分以内に6件以上発生すると、それ以降、問題キーが同じインシデントはフラッド制御されます。この値はMBeanを使用して変更できます(第13.3項を参照)。

13.1.2 診断フレームワークのコンポーネント

次の各項目で、診断フレームワークの主要コンポーネントについて説明します。

- 自動診断リポジトリ

- 診断ダンプ

- 管理MBean

- 診断フレームワーク用WLSTコマンド

- ADRCIコマンド行ユーティリティ

注意:
診断フレームワーク、特に自動診断リポジトリを使用するには、管理対象サーバーにOracle JRFが適用されている必要があります。Oracle JRFが適用されていれば、各管理対象サーバーに対して次のディレクトリが存在します。

DOMAIN_HOME/SERVERS/server_name/adr

ディレクトリが存在しない場合は、次のいずれかの手順を実行します。

- 第19.3.1項の説明に従って、Oracle JRFを適用します。

- Oracle JRFが適用されている場合は、第2.7.1項で説明しているように、ノード・マネージャのプロパティstartScriptEnabledがtrueに設定されていることを確認して、サーバーを再起動します。

13.1.2.1 自動診断リポジトリ

自動診断リポジトリ(ADR)は、追跡データやダンプなどのOracle Fusion Middleware診断データ用のファイルベースの階層リポジトリです。Oracle Fusion Middlewareのコンポーネントでは、インシデント・データはすべてADRに格納されます。それぞれのOracle WebLogic Serverでは、ADR内の自身のホーム・ディレクトリのサブディレクトリに診断データが格納されます。たとえば、それぞれの管理対象サーバーおよび管理サーバーにはADRホーム・ディレクトリがあります。

ADRのルート・ディレクトリは、ADRベースと呼ばれています。デフォルトでは、ADRベースは次のディレクトリにあります。

DOMAIN_HOME/servers/server_name/adr

ADRベースの中に、複数のADRホームがある場合があります。それぞれのADRホームは、Oracle WebLogic Serverの特定のインスタンスに対し、すべてのインシデント・データのルート・ディレクトリになります。次のパスは、ADRホームの場所を示します。

ADR_BASE/diag/ofm/domain_name/server_name

図13-1は、Oracle WebLogic ServerインスタンスのADRホームのディレクトリ階層を示しています。

図13-1 Oracle Fusion MiddlewareのADRディレクトリ構造

ADRホームのサブディレクトリには、次の情報が含まれています。

- alert: XML形式のアラート・ログ。

- incident: 複数のサブディレクトリを格納できるディレクトリ。それぞれのサブディレクトリには、当該のインシデントの名前が付けられます。サブディレクトリの名前はincdir_nで、このnはインシデントの番号を表しています。それぞれのサブディレクトリには、そのインシデントのみに関する情報および診断ダンプが格納されます。

- (others): ADRホームのその他のサブディレクトリ。インシデント・パッケージなどの情報が格納されます。

注意:
ADRでは、インシデントをパッケージ化する際に、製品IDとしてドメイン名を使用し、インスタンスIDとしてサーバー名を使用します。ただし、いずれかの名前が30文字を超える場合は、ADRは名前の一部を切り捨てます。また、ドル記号($)と空白文字はアンダースコアに置き換えられます。

13.1.2.2 診断ダンプ

診断ダンプは、特定の診断情報を取得およびダンプします。この処理は、インシデントが作成された時点では自動で、管理者が要求した時点では手動で行われます。インシデント作成の一環として実行される場合、ダンプは一連のインシデント診断データに含まれます。診断ダンプには、JVMスレッド・ダンプ、JVMクラス・ヒストグラム・ダンプ、DMSメトリック・ダンプなどがあります。診断ダンプのリストについては、表13-7を参照してください。

13.1.2.3 管理MBean

診断フレームワークには、診断フレームワークの構成に使用できるMBeanが用意されています。たとえば、フラッド制御を有効化または無効化したり、指定された期間内に問題キーが同じインシデントが何回発生できるかを構成できます。管理MBeanを使用して診断フレームワークを構成する方法の詳細は、第13.3項を参照してください。

また、MBeanを使用すると、インシデントの問合せおよび作成を行ったり、使用可能な診断ダンプ・タイプのリストを検索したり、個々の診断ダンプを実行することができます。

13.1.2.4 診断フレームワーク用WLSTコマンド

診断フレームワークには、問題およびインシデントに関する情報の表示、インシデントの作成、特定のダンプの実行および一連の診断ダンプ・タイプの問合せに使用できるWLSTコマンドが用意されています。詳細は、次を参照してください:

- 問題の確認

- インシデントの確認

- 診断ダンプの一覧表示

- 診断ダンプの説明の表示

- ダンプの実行

- インシデントの手動作成

- 『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』の診断フレームワークのカスタムWLSTコマンドに関する項

13.1.2.5 ADRCIコマンド行ユーティリティ

ADRコマンド・インタプリタ(ADRCI)は、問題を調査し、初期障害診断データをパッケージ化してOracleサポートにアップロードするという処理を、コマンド行環境ですべて実行できるユーティリティです。またADRCIを使用して、ADR内のダンプ・ファイルの名前を表示したり、コンテンツ・フィルタを指定して(または未指定で)XMLタグが取り除かれた状態でアラート・ログを表示することもできます。

ADRCIは次のディレクトリにインストールされています。

(UNIX) ORACLE_HOME/oracle_common/adr
(Windows) ORACLE_HOME\oracle_common\adr

ADRCIコマンド行ユーティリティの使用の詳細は、次の各項を参照してください。

- インシデントのパッケージ化に関しては第13.4.6.3項

- インシデントのパージに関しては第13.4.6.4項

関連項目:

- 『Oracle Databaseユーティリティ』の「ADRCI: ADRコマンド・インタプリタ」

- 『Oracle Database管理者ガイド』の「診断データの管理」

13.2 診断フレームワークの動作

診断フレームワークは、それぞれのサーバーでアクティブであり、構成された事前定義のルールに基づいてエラーを自動的に検出します。Oracle Fusion Middlewareのコンポーネントおよびアプリケーションは、常に監視対象となるため、自動的に診断フレームワークの恩恵を受けることになります。

インシデントは、次の2つの方法で自動的に検出されます。

- インシデント検出ログ・フィルタ。クリティカル・エラーを検出するように自動的に構成されます。

- WLDFポリシーおよびアクション・コンポーネント。診断フレームワークでは、事前定義された通知タイプをリスニングし、そのような通知を受信したときにインシデントを作成します。
WLDFポリシーおよびアクションの構成の詳細は、第13.3.5項を参照してください。

- プログラムによるインシデント作成。一部のコンポーネントでは、インシデントを直接作成します。

図13-2は、インシデント・ログ検出でインシデントが検出された際の情報のやり取りを示しています。ここでは、インシデント・ログ検出でインシデントが検出されたときの、インシデント・ログ検出、WLDF診断イメージMBean、ADR、およびコンポーネントまたはアプリケーションのダンプの間のやり取りを示しています。

図13-2 インシデント・ログ検出で生成されるインシデント作成

図13-2で示されている手順は、次のとおりです。

1. インシデント検出ログ・フィルタは、コンポーネントおよびアプリケーションの診断ルールで初期化されます。

2. アプリケーションまたはコンポーネントは、java.util.logging APIを使用して、メッセージをログに記録します。

3. ODLログ・ハンドラは、メッセージをインシデント検出ログ・フィルタに渡します。

4. インシデント・ログ検出フィルタは、ログ・メッセージを検証し、コンポーネントの診断ルールに基づいて、インシデントを作成するかどうかを判断します。診断ルールによりインシデントを作成する必要があると示された場合、ADRにインシデントが作成されます。

5. ODLログ・ハンドラは、ログ・メッセージをログ・ファイルに書き込み、制御をアプリケーションに戻します。
インシデントが作成されると、次のようなメッセージがログ・ファイルに書き込まれます。

[2015-03-28T11:05:34.603-07:00] [wls_server_1] [NOTIFICATION] [DFW-40101] [oracle.dfw.incident] [tid: [ACTIVE].ExecuteThread: '4' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: weblogic] [ecid: 66217af9-247f-4344-94a9-14f90e75a586-000e093f,0] An incident has been signalled with the incident facts: [problemKey=MDS-50500 [MANUAL] incidentSource=MANUAL incidentTime=Fri March 28 11:05:34 PDT 2015 errorMessage=MDS-50500 executionContextId=null]

6. 診断フレームワークは、コンポーネントの診断ルールで示される診断ダンプを実行します。

7. 診断フレームワークは、ADRの中の、インシデント用に作成されたディレクトリにダンプを書き込みます。

8. 診断フレームワークは、ADRに診断イメージを作成することを要求するWLDF診断イメージMBeanを呼び出します。

9. WLDFは、ADRに診断イメージを書き込みます。

図13-3は、WLDFポリシーおよびアクション・システムでインシデントが検出された際の情報のやり取りを示しています。ここでは、インシデント通知リスナー、WLDFポリシーおよびアクション・システム、WLDF診断イメージMBeanの間の情報のやり取りを示しています。

図13-3 WLDFポリシーおよびアクションによって生成されるインシデント作成

図13-3で示されている手順は、次のとおりです。

1. インシデント通知リスナーは、コンポーネントおよびアプリケーションの診断ルールで初期化されます。

2. Oracle Fusion Middleware診断フレームワークは、WLDFにJMX通知リスナーを登録します。リスナーは、WLDFポリシーおよびアクション・システムからのイベントをリスニングします。ここで処理される通知は、oracle.dfw.wldfnotificationタイプのみです。

3. システム内のなんらかが原因となって、構成されたWLDFポリシーがトリガーされ、インシデント通知リスナーに通知が送信されます。通知には、ポリシーをトリガーする原因となったデータについて記述したイベント情報が含まれます。

4. 診断フレームワークにより、ADRにインシデントが作成されます。

5. 診断フレームワークは、診断ルールで示される診断ダンプを実行します。

6. 診断フレームワークは、ADRの中の、インシデント用に作成されたディレクトリにダンプを書き込みます。

7. 診断フレームワークは、ADRに診断イメージを作成することを要求するWLDF診断イメージMBeanを呼び出します。

8. WLDFは、ADRに診断イメージを書き込みます。

13.3 診断フレームワークの構成

診断フレームワークの一部の設定を構成できます。また、WLDFポリシーおよびアクションを構成してインシデントを作成することもできます。次の各項目で、診断フレームワークを構成する方法を説明します。

- 診断フレームワークの設定の構成

- カスタム診断ルールの構成

- 問題抑制の構成

- 問題キー・フィルタの取得

- 診断フレームワーク用のWLDFポリシーおよびアクションの構成

13.3.1 診断フレームワークの設定の構成

次の設定を構成できます。

- ログ・ファイルを使用したインシデントの検出の有効化または無効化

- フラッド制御およびフラッド制御のパラメータ設定の有効化または無効化

これらの設定を構成するには、診断フレームワークMBean DiagnosticConfigを使用します。次に、MBeanのObjectNameを示します。

oracle.dfw:type=oracle.dfw.jmx.DiagnosticsConfigMBean,name=DiagnosticsConfig

表13-1は、DiagnosticConfig MBeanの属性と各パラメータの説明を示しています。

表13-1 診断フレームワークのDiagnosticConfig MBeanの属性

属性

説明

DumpSamplingIdleWhenHealthy

システムが健全な場合にダンプ・サンプリングを有効にするかどうかを決定します。デフォルトで、これはtrueに設定されています(インシデントが発生するまで、ダンプ・サンプリングは有効ではありません)。

DumpSamplingMinimumHealthyPeriod

インシデントが発生した後、ダンプ・サンプリングが有効になるまでの時間(秒数)。デフォルトは259200秒(72時間)です。

floodControlEnabled

フラッド制御を有効化または無効化します。有効化する場合はtrue、無効化する場合はfalseと指定します。デフォルトはtrueです。

フラッド制御は、手動で作成されたインシデントには適用されません。

floodControlIncidentCount

フラッド制御で制御されるまでに、floodControlIncidentTimeoutPeriodで指定された期間内に作成できる、問題キーが同じインシデントの数を設定します。デフォルトは5です。

フラッド制御が有効になっていて、同じ問題キーのインシデントの数がこのカウントを超えると、インシデントが作成されなくなります。ただし、診断フレームワークは、WARNINGレベルのメッセージをログ・ファイルに書き込みます。

floodControlIncidentTimeoutPeriod

フラッド制御で制御されるまでに、floodControlIncidentCountで指定された数の、問題キーが同じインシデントを作成できる期間を設定します。デフォルトは60分です。

incidentCreationEnabled

インシデント作成を有効化または無効化します。有効化する場合はtrue、無効化する場合はfalseと指定します。デフォルトはtrueです。

logDetectionEnabled

ログ・ファイルを使用したインシデントの検出を有効化または無効化します。有効化する場合はtrue、無効化する場合はfalseと指定します。デフォルトはtrueです。

maxTotalIncidentSize

すべてのインシデントに割り当てられる最大合計サイズを設定します。この制限に達すると、すべてのインシデントで使用される領域がこのパラメータで指定される量より小さくなるまで、最も古いインシデントから順にパージされます。

デフォルトは500MBです。インシデントの作成時にこの制限を超えた場合は、インシデントの作成が完了したときに、最も古いインシデントからパージされていきます。

reservedMemoryKB

OutOfMemoryErrorが検出されたときに解放される予約済メモリーの量。

診断フレームワークの起動時に、プライベートで使用されるメモリーが512 KB割り当てられます。診断フレームワークにより、サーバーにOutOfMemoryErrorが発生したことが検出されると、そのメモリーのブロックを解放して、インシデントの作成に進みます。

デフォルトは512KBです。

uncaughtExceptionDetectionEnabled

Javaベースの捕えられていない例外ハンドラを有効にします。これが有効のときに捕えられていない例外が検出されると、インシデントが作成されます。有効化する場合はtrue、無効化する場合はfalseと指定します。

デフォルトはtrueです。

useExternalCommands

スレッド・ダンプの実行に外部JVMコマンドを使用するかどうかを示します。有効化する場合はtrue、無効化する場合はfalseと指定します。デフォルトはtrueです。

次の例は、Fusion Middleware ControlシステムMBeanブラウザを使用してこれらの設定を構成する方法を示しています。

1. 「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

2. アプリケーション定義のBean→「oracle.dfw」→「Domain.domain_name」→「dfw.jmx.DiagnosticsConfigMBean」を開きます。

3. DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。

4. 「アプリケーション定義のMBean」ペインで「MBean情報の表示」を開くと、サーバー名が表示されます。
次に、「システムMBeanブラウザ」ページを示します。

5. 表13-1に一覧表示されている属性の値を変更するには、「値」フィールドで値を入力または選択します。

6. 「適用」をクリックします。

13.3.2 カスタム診断ルールの構成

ドメイン、サーバーあるいはドメインまたはサーバー内のアプリケーションに適用されるカスタム診断ルールを構成できます。

カスタム診断ルールは、特定の形式の.xmlファイル(この項の後半の例を参照)を作成することにより作成します。ファイルは次のいずれかの場所に保存する必要があります。

- ドメイン全体に適用されるルールの場合

DOMAIN_HOME/config/fmwconfig/dfw

- 特定のサーバーに適用されるルールの場合

DOMAIN_HOME/config/fmwconfig/servers/server_name/dfw

ファイル名には次の形式を使用する必要があります。

name.xml
appname#name.xml

この形式では、appnameは、ルールが適用されるアプリケーションの名前です。appnameは、デプロイされたアプリケーションの正確な名前である必要があります。nameは、指定するルールの名前です。appnameを指定しないと、ルールはサーバー全体に適用されます。たとえば、次のルールはmyAppアプリケーションに適用されます。

myApp#custom_rule.xml

カスタム診断ルール・ファイルには、ルールを定義するために次のような要素を含めることができます。

- ログ検出条件(オプション)
ルールが登録されているサーバーまたは指定されたアプリケーションに適用される診断ログ内でチェックする条件のセットを、logDetectionConditions要素内に定義できます。条件に一致するログ・メッセージが検出されると、インシデントが作成され、問題の特定に役立つ診断情報が取得されます。デフォルトでは、すべてのINCIDENT_ERRORメッセージが検出され、それらに対してインシデントが作成されます。また、特定のコンポーネントに対して、特定のメッセージを検出するルールを構成することもできます。

次の例は、4つのログ検出条件を定義するカスタム診断ルール・ファイルの一部を示しています。1つ以上の条件がtrueの場合、インシデントが作成されます。

<?xml version="1.0" encoding="UTF-8"?>
<diagnosticRules xmlns="http://www.oracle.com/DFW/DiagnosticsFrameworkRules" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance">
<logDetectionConditions>
<condition messageSeverity="INCIDENT_ERROR"/>
<condition messageSeverity="ERROR" component="jrfServer_admin"/>
<condition messageSeverity="ERROR" module="test.servletA"/>
<condition messageId="FMW-40300"/>
</logDetectionConditions>

使用できる条件の説明は、表13-2を参照してください。

- 処理ルール
インシデントの作成にサーバー・ルールまたはアプリケーション・ルールが関わっている場合に評価される処理ルールを定義できます。たとえば、インシデントの作成にMyAppアプリケーションが関わっている場合、MyAppアプリケーションに関連付けられたすべてのルールが評価されます。どの場合にも、アプリケーションにかかわらず、サーバー全体に対するルールは常に評価されます。

処理ルールは次の2つの部分から構成されます。

- デフォルト・アクション(オプション)。指定されている場合は、インシデントの作成中に常に実行されます。アクションとは、実行する診断ダンプとオプションの引数のリストです。
次に、デフォルト・アクション・セットの例を示します。

<defaultActions>
<dumpAction name="odl.logs">
<argument name="timestamp" value="INCIDENT_TIME" valueType="fact"/>
</dumpAction>
<dumpAction name="dms.metrics"/>
</defaultActions>

使用できるオプションの引数の説明は、表13-3を参照してください。

- 条件ベースのアクション。これは、条件がtrueと評価された場合にのみ実行されます。各<rule>要素は、名前属性および子<ruleCondition>要素と子<ruleActions>要素から構成されます。<ruleActions>要素には、1つ以上のdumpAction要素が含まれます。<ruleCondition>要素属性のリストは、表13-4を参照してください。
1つの<rule>要素内に複数の<condition>要素が指定されている場合、すべての条件がtrueに評価される場合にのみdumpActionが実行されます。

次に、条件ベースのアクション・ルールの例を示します。MESSAGE_IDがDFW-99997の場合、条件がtrueと評価され、jvm.classhistogramダンプが実行されます。

<processingRules>
<rule name="OOME">
<ruleCondition>
<condition name="MESSAGE_ID" value="DFW-99997"/>
</ruleCondition>
<ruleActions>
<dumpAction name="jvm.classhistogram"/>
</ruleActions>
</rule>
</processingRules>

表13-2に、ログ検出条件を作成するために使用できる属性を示します。

表13-2 LogDetectionConditions要素の条件

条件

説明

messageSeverity

メッセージが記録されたログ・レベル。(これはODLログ・ファイルでのMESSAGE_LEVELフィールドです。)例: INCIDENT_ERROR、ERROR

messageId

メッセージのID。(これはODLログ・ファイルでのMESSAGE_IDフィールドです。)例: DFW-99997

component

コンポーネント名。(これはODLログ・ファイルでのCOMPONENT_IDフィールドです。)たとえば、oracle.mdsのように指定します。

module

メッセージを生成したモジュールの名前。(これはODLログ・ファイルでのMODULE_IDフィールドです。)

ODLログ・ファイル・フィールドの説明は、表12-1を参照してください。

表13-3に、<defaultActions>要素に対して使用できるオプションの引数を示します。

表13-3 defaultActions要素に対するオプションの引数

引数

説明

name

引数の名前。

value

引数の値。

type

引数のタイプ。有効な値は、次のとおりです。

- literal: このタイプを指定した場合は、引数のリテラル値が使用されます。これはデフォルトです。

- fact: このタイプを指定した場合は、値はINCIDENT_TIMEまたはECIDである必要があります。

- context: このタイプを指定した場合は、値はDMS実行コンテキストでの値の名前である必要があります。DMS実行コンテキストの詳細は、『パフォーマンスのチューニング』のDMS実行コンテキストに関する項を参照してください。

表13-4に、<ruleCondition>要素属性を示します。

表13-4 ruleCondition要素の属性

要素

説明

name

属性の名前を指定します。有効な値はvalueTypeに依存します。

- valueTypeがfactの場合は、有効な値はCOMPONENT_ID、MODULE_IDまたはMESSAGE_IDです。

- valueTypeがcontextの場合は、値はDMS実行コンテキストでの値の名前である必要があります。DMS実行コンテキストの詳細は、『パフォーマンスのチューニング』のDMS実行コンテキストに関する項を参照してください。

operator

演算子。有効な値は、EQ、EQNoCase、NE、Contains、StartsWith、EndsWith、LT、GT、LE、GEです。デフォルトはEQです。

値では大/小文字が区別されます。

value

比較するリテラル値。

datatype

データ型。有効な値はStringまたはIntegerです。デフォルトはStringです。

値では大/小文字が区別されます。

valueType

引数のタイプ。

- fact

- context

カスタム診断ルールを作成してロードする手順は次のとおりです。

1. カスタム・ルールを含むファイルを作成します。
サンプル・カスタム・ルール・ファイルを次に示します。

<?xml version="1.0" encoding="UTF-8"?>
<diagnosticRules xmlns="http://www.oracle.com/DFW/DiagnosticsFrameworkRules" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance">

<logDetectionConditions>
<condition messageSeverity="INCIDENT_ERROR"/>
// detect all message logged at level INCIDENT_ERROR
<condition messageSeverity="ERROR" component="jrfServer_admin"/>
// detect all "jrfServer_admin" component messages logged at level ERROR
<condition messageSeverity="ERROR" module="test.servletA"/>
// detect all "test.servlet" module messages logged at level ERROR
<condition messageId="FMW-40300"/>
// detect message "FMW-40300"
</logDetectionConditions>

<defaultActions>
<dumpAction name="odl.logs">
<argument name="timestamp" value="INCIDENT_TIME" valueType="fact"/>
</dumpAction>
<dumpAction name="dms.metrics"/>
</defaultActions>

<processingRules>
<rule name="OOME">
<ruleCondition>
<condition name="MESSAGE_ID" value="DFW-99997"/>
</ruleCondition>
<ruleActions>
<dumpAction name="jvm.classhistogram"/>
</ruleActions>
</rule>
</processingRules>

</diagnosticRules>

2. 拡張子.xmlを含む名前を付けて、ファイルを保存します。ルールがアプリケーションに適用される場合は、ファイル名の前にapp_name#を付けます。ファイルを次のいずれかの場所に保存します。

DOMAIN_HOME/config/fmwconfig/dfw
DOMAIN_HOME/config/fmwconfig/servers/server_name/dfw

3. WLSTコマンドreloadCustomRulesを使用して、ルールをロードします。次の例は、myAppアプリケーションに適用されるcustomrules.xmlルールをロードします。

reloadCustomRules(name='myApp#customrules.xml')

ドメイン内のすべてのルール、または特定のサーバーに関連するすべてのルールを再ロードできます。次の例は、wls_server1サーバーに対するすべてのルールを再ロードします。

reloadCustomRules(server='wls_server1')

reloadCustomRulesコマンドの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のreloadCustomRulesに関する項を参照してください。

13.3.3 問題抑制の構成

一定の状況では、特定の問題キーに基づいてインシデントの作成を抑制する必要がある場合があります。たとえば、開発環境で、サーブレットを開発しているときに、コードを調整すると捕えられていない例外が多数生成されることがあります。これにより、不要なインシデントが作成されます。

診断フレームワークによって、フィルタ条件と一致する問題でインシデントが作成されないように問題抑制フィルタを構成できます。

問題抑制フィルタを構成する場合は、マッチするパターンを表す正規表現を使用します。java.util.regexクラスを使用して、正規表現とのマッチが行われます。次に例を示します。

- 次の正規表現では、インシデントがMDS-5000で始まる問題キーとマッチされます。

MDS-5000.*

- 次の正規表現は、テキストOutOfMemoryを含む問題とマッチします。正規表現では大/小文字が区別されるため、テキストoutofmemoryを含む問題とはマッチしません。

.*OutOfMemory.*

DiagnosticConfig MBeanを使用すると、フィルタを追加および削除したり、フィルタ・リストまたは1つのフィルタの詳細を取得できます。

表13-5は、構成中の問題抑制フィルタの操作および属性とそれぞれの説明を示しています。

表13-5 問題抑制フィルタのDiagnosticConfig MBeanの操作および属性

操作および属性

説明

操作:

addProblemKeyFilter(filter_pattern)

新しい問題抑制フィルタを追加します。マッチするパターンを表す正規表現に渡します。次に例を示します。

addProblemKeyFilter(".*OutOfMemory.*)

属性:

getProblemKeyFilters()

構成済の問題抑制フィルタのリストを返します。次に例を示します。

getProblemKeyFilters()

操作:

getProblemKeyFilter(filterID)

特定IDに関連するフィルタ・パターンを返します。次に例を示します。

getProblemKeyFilter(id)

IDを検索するには、getProblemKeyFilters()操作を使用します。

操作:

removeProblemKeyFilter(filterID)

任意のフィルタIDに関連するフィルタ・パターンを削除します。次に例を示します。

removeProblemKeyFilter(id)

問題抑制フィルタを構成する手順は次のとおりです。

1. 「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

2. アプリケーション定義のBean→「oracle.dfw」→「domain.domain_name」→「dfw.jmx.DiagnosticsConfigMBean」を開きます。

3. DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。

4. 「アプリケーション定義のMBean」ペインで、「操作」タブを選択します。

5. addProblemKeyFilterをクリックします。操作: addProblemKeyFilterページが、次の図のように表示されます。

6. 「値」に、マッチするパターンを表す正規表現を入力します。たとえば、開発環境では、java.lang.IllegalStateExceptionというJava例外が報告されたときにインシデントが作成されないようにフィルタを追加する必要がある場合があります。この場合、次のように入力します。

".*[java.lang.IllegalStateException].*"

7. 「起動」をクリックします。

8. 「戻る」をクリックし、「アプリケーション定義のMBean」ページに戻ります。

removeProblemKeyFilter操作を使用すると、フィルタを削除できます。

13.3.4 問題キー・フィルタの取得

getProblemKeyFilter操作にフィルタIDを渡すと、特定のフィルタを取得できます。

また、次のようにgetProblemKeyFilters属性を使用すると、フィルタのリストを取得できます。

1. 「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

2. アプリケーション定義のBean→「oracle.dfw」→「domain.domain_name」→「dfw.jmx.DiagnosticsConfigMBean」を開きます。

3. DiagnosticConfigエントリのいずれかを選択します。DiagnosticConfigエントリは、各サーバーに1つずつあります。

4. 「アプリケーション定義のMBean」ペインで、「属性」タブを選択します。

5. ProblemKeyFiltersをクリックします。
問題抑制フィルタのリストが表示されます。

13.3.5 診断フレームワーク用のWLDFポリシーおよびアクションの構成

Oracle Fusion Middlewareでは、一連のポリシーおよびアクションのルール(以前は監視および通知のルールと呼ばれていました)が含まれているWLDF診断モジュールを構成します。そのルールは、特定の一連のクリティカル・エラーを検出し、それらのエラーが発生するたびにインシデントを作成するためのものです。このモジュールはモジュールFMWDFWと呼ばれ、次の一連のポリシー条件が含まれます。

名前

説明

Deadlock

複数のJavaスレッドで、Java Monitorオブジェクトを使用する際に循環ロック・チェーンがあります。

StuckThread

Oracle WebLogic ServerのExecuteThread。Oracle WebLogic ServerのStuckThreadMaxTimeパラメータで指定された時間より多くの期間、ブロックされているかビジー状態です。

UncheckedException

このカテゴリには、未チェックの例外、実行時の例外、およびNullPointerException、StackOverflowError、OutOfMemoryErrorなどのOracle WebLogic ServerのExecuteThreadで捕捉されたエラーがすべて含まれます。

診断モジュールには、oracle.dfw.wldfnotificationタイプの、構成されたWLDF JMX通知FMWDFW-notificationも含まれます。このWLDF JMX通知は、インシデントを作成するために、独自のWLDFポリシー条件で再利用することもできます。

1. 第2.3項の説明に従って、管理コンソールを表示します。

2. 左ペインで、「診断」を開き、「診断モジュール」を選択します。
「診断モジュールのサマリー」ページが表示されます。

3. 「Module-FMWDFW」をクリックします。
「Module-FMWDFWの設定」ページが表示されます。

4. 「構成」タブ、「ポリシーとアクション」タブの順に選択します。次の図は、「ポリシー」セクションを示しています。

5. 「ポリシー」タブを選択し、「新規」をクリックします。
「ポリシーの作成」ページが表示されます。

6. 「ポリシー名」にポリシーの名前を入力します。
任意の名前を入力できます。または、次の形式を使用し、診断フレームワークでカスタム・メッセージIDが使用されるようにすることができます。

message-id#[application_name]#any_text

メッセージIDは、1から6文字の接頭辞と1から6桁の数字で構成されます。アプリケーション名はオプションです。次に例を示します。

WLS-40500#My_Policy_Name

次の例では、アプリケーション名testappを使用します。

WLS-40501#testapp#My_Policy_Name

診断フレームワークでは、インシデント問題キーの構成時にメッセージIDをインシデント・メッセージIDとして使用します。

7. 「ポリシー・タイプ」で、「サーバー・ログ」や「スマート・ルール」などのタイプを選択します。これは、「クラスタ平均スループット(下限)」などの事前構成済ルールです。

8. 「次へ」をクリックします。

9. 次のページは、ポリシーのタイプによって異なります。

- 「スマート・ルール」:

1. ルールを選択して「次へ」をクリックします。

2. パラメータ値を入力して「次へ」をクリックします。

3. 「繰返し」で、指定した時間内に実行する回数を選択します。たとえば、4分ごとに繰り返すようにし、「次へ」をクリックします。

4. 「頻度」で、「N分ごと」などの頻度を選択し、「次へ」をクリックします。

- 「カレンダ・ベース」で、頻度を選択し、「次へ」をクリックします。

- 「収集対象メトリック」:

1. ポリシーのルールを作成するための式を追加します。

2. パラメータ値を入力して「次へ」をクリックします。

3. 「頻度」で、「N分ごと」などの頻度を選択し、「次へ」をクリックします。

4. 「繰返し」で、指定した時間内に実行する回数を選択します。たとえば、4分ごとに繰り返すようにし、「次へ」をクリックします。

- 「サーバー・ログ」で、ポリシーのルールを作成するための式を追加します。たとえば、式(SEVERITY = 'Error') AND (MSGID = 'BEA-000337')を作成します。次に、「次へ」をクリックします。

- 「ドメイン・ログ」で、ポリシーのルールを作成するための式を追加します。次に、「次へ」をクリックします。

- 「イベント・データ」で、ポリシーのルールを作成するための式を追加します。次に、「次へ」をクリックします。

10. アラーム・タイプを選択して、「次へ」をクリックします。

11. 「通知」で、FMWDFW-notificationを選択し、これを「選択済み」ボックスに移動します。

12. 「終了」をクリックします。

ポリシーの作成の詳細は、『Oracle WebLogic Server Administration Consoleオンラインヘルプ』の診断モジュール: 診断ポリシーの作成に関する項を参照してください。

13.4 問題の調査、報告および解決

この項では、WLSTコマンドおよびADRCIコマンドとRemote Diagnostic Agent (RDA)を使用して、問題(クリティカル・エラー)を調査および報告し、場合によっては問題を解決する方法について説明します。初めに、実行する必要がある典型的な一連の作業をまとめたロードマップを示します。次の項目について説明します。

- ロードマップ—問題の調査、報告および解決

- 問題およびインシデントの確認

- 特定の問題キーの分析

- 診断ダンプの処理

- 診断ダンプ・サンプリングの構成と使用

- インシデントの管理

- RDAレポートの生成

13.4.1 ロードマップ—問題の調査、報告および解決

一般的に、問題の調査、報告および解決は、クリティカル・エラーの発生から始まります。この項では、そのワークフローの概要について説明します。

図13-4は、問題を調査、報告および解決するためのタスクを示しています。

図13-4 問題調査のフロー

次に、図13-4に示しているワークフローについて説明します。

1. システム、コンポーネントまたはアプリケーションが想定どおりに機能していないことがわかります。たとえば、パフォーマンスに問題があることがわかったり、アクセスしようとしているアプリケーションでエラーが報告されているとユーザーから報告があった場合などです。

2. 観察された症状に関連する可能性のある問題およびインシデントが作成されているかどうかを確認します。

1. 一連の問題を確認するには、第13.4.2.1項の説明に従って、WLSTのlistProblemsコマンドを使用します。

2. 問題が作成されている場合、第13.4.2.2項の説明に従って、listIncidentsコマンドを使用して、特定の問題に関連するインシデントを一覧表示します。

3. インシデントが作成されていない場合は、ステップ4に進みます。インシデントが作成されている場合は、ステップ5に進みます。

4. 問題に関連しているインシデントを確認できない場合は、createIncidentコマンドを使用してインシデントを手動で作成し、問題の診断情報を取得することができます。

ソフトウェアの障害やパフォーマンスの問題などに直面して詳細な診断データを収集する必要がある場合は、インシデントを作成することを検討してください。ログ・ファイルとその中のメッセージを表示できます。直面している問題に関連すると思われるメッセージがあったら、createIncidentコマンドでそのメッセージIDを使用できます。

インシデントの作成の詳細は、第13.4.6.1項を参照してください。

5. 特定のインシデントの詳細を確認するには、第13.4.2.2項の説明に従って、showIncidentコマンドを使用します。このコマンドを実行すると、関連するメッセージID、インシデントの時刻、ECID、インシデントで生成されたファイルなど、インシデントに関する情報が一覧表示されます。

6. 第13.4.2.2項の説明に従って、getIncidentFileコマンドを使用して、インシデントのファイルの内容を表示します。その内容には、問題の原因を導き出し、その解決に役立つ情報が含まれる可能性があります。

7. インシデントのファイルの内容が問題の解決に役立たなかった場合、追加のダンプを実行して詳細な診断情報を確認できます。たとえば、パフォーマンスの問題に直面した場合は、dms.metricsダンプを実行します。使用可能なダンプおよびその実行方法の詳細は、第13.4.4項を参照してください。

8. それでも問題が解決できない場合は、RDAレポートとともにインシデントをパッケージ化して、Oracleサポートにお送りください。インシデントのパッケージ化およびRDAレポートの生成の詳細は、第13.4.6.3項および第13.4.7項を参照してください。

13.4.2 問題およびインシデントの確認

次の各項で説明するように、WLSTコマンド行ユーティリティを使用して、一連の問題、インシデントのリスト、および特定のインシデントの詳細を確認できます。

- 問題の確認

- インシデントの確認

- インシデントの問合せ

13.4.2.1 問題の確認

一連の問題を確認するには、次の形式でWLSTのlistProblemsコマンドを実行します。

listProblems([adrHome] [,server])

listProblemsコマンドを実行すると、ADRホームの問題が一覧表示されます。それぞれの問題では、IDが一意です。

listProblems()
Problem Id      Problem Key
1       BEA-101020 [HTTP]

13.4.2.2 インシデントの確認

次の形式でWLSTのlistIncidentsコマンドを実行して、すべての使用可能なインシデントまたは特定の問題に関連するインシデントをリストできます。

listIncidents([id], [ADRHome])

たとえば、すべてのインシデントのリストを表示するには、次のコマンドを使用します。

listIncidents()
Incident Id     Incident Time                   Problem Key
2       Fri Mar 28 11:05:59 PDT 2015    MDS-50500 [MANUAL]
1       Fri Mar 28 11:02:22 PDT 2015    MDS-50500 [MANUAL]

特定の問題に関連するインシデントを確認するには、次のコマンドを使用します。

listIncidents(id='1')
Incident Id     Incident Time                   Problem Key
2       Fri Mar 28 11:05:59 PDT 2015    MDS-50500 [MANUAL]
1       Fri Mar 28 11:02:22 PDT 2015    MDS-50500 [MANUAL]

特定のインシデントの詳細を確認するには、次の形式でWLSTのshowIncidentコマンドを使用します。

showIncident(id, [adrHome] [,server])

たとえば、インシデント1の詳細を確認するには、次のコマンドを使用します。

showIncident(id='1')
Incident Id: 1
Problem Id: 1
Problem Key: MDS-50500 [MANUAL]
Incident Time:Fri Mar 28 11:02:22 PDT 2015
Error Message Id: MDS-50500
Execution Context:
Flood Controlled: false
Dump Files :
readme.txt
jvm_threads10_i1.txt
dms_metrics11_i1.txt
dfw_samplingArchive13_i1.JVMThreadDump.txt
dfw_samplingArchive13_i1.readme.txt
odl_logs14_i1.txt

インシデントのファイルの内容を確認するには、次の形式でWLSTのgetIncidentFileコマンドを使用します。

getIncidentFile(id, name [,outputFile] [,adrHome] [,server])

たとえば、ファイルodl_logs4_i1.dmpの内容を確認するには、次のコマンドを使用します。

getIncidentFile(id='1', name='odl_logs14_i1.txt',outputFile='/tmp/odl_logs4_i1_dmp.output')

このコマンドは、出力をファイルodl_logs4_i1_dmp.outputに書き込みます。

13.4.2.3 インシデントの問合せ

listIncidentsコマンドでは特定の問題IDまたは特定のサーバーに関連するインシデントが表示されますが、リストをそれ以上絞り込むことはできません。WLSTのqueryIncidentsコマンドは、ドメイン内の1つ以上のサーバー、またはすべてのサーバーに渡って、特定の属性の値を問い合せることができます。たとえば、インシデント作成時やECIDで問い合されます。

式にはインシデント属性、演算子、および文字列が次の形式で含まれます。

attribute operator "string"

問合せ式をブール演算子ANDまたはORで連結し、カッコ()でグループ化できます。

次のインシデント属性がサポートされています。

- TIMESTAMP: インシデントの作成時刻。fromおよびto演算子を使用して、時間の範囲を指定できます。日付の形式はYYYY-MM-DD HH:MMです。

- ECID: 実行コンテキストID

- PROBLEM_KEY: 問題キー

- MSG_FACILITY: エラー・メッセージ機能(ORAやOHSなど)。

- MSG_NUMBER: メッセージID (600など)。

カスタム・インシデント属性もサポートされています。たとえば、TRACEID、APP、URIおよびDSIDがサポートされています。さらに、インシデントのreadme.txtファイルに示されるコンテキスト値がサポートされています。たとえば、DFW_APP_NAMEおよびDFW_USER_NAMEがサポートされています。

次の演算子がサポートされています。

- equals

- notEqual

- startsWith

- endsWith

- contains

- isNull

- notNull

たとえば、ドメイン内のすべてのサーバーのすべてのインシデントに対して、ECID f19wAgN000001を問い合せることができます。

queryIncidents(query="ECID equals f19wAgN000001")

次の例では、2015年3月1日と2015年3月15日の間に発生したすべてのインシデントに対して、サーバーwls_server_1を問い合せています。

queryIncidents(query="TIMESTAMP from '2015-03-01 00:00'AND TIMESTAMP to '2015-03-15 00:00'",
servers=["wls_server_1"])

このコマンドの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のqueryIncidentsに関する項を参照してください。

13.4.3特定の問題キーの分析

診断フレームワークは、未処理の例外について明確に定義された一連の問題キーを提供します。これらの例外は、既存のWLDFポリシーのUncheckedException、または診断フレームワークのjava.lang.Thread.UncaughtExceptionHandlerハンドラのいずれかによって検出されます。これまで、診断フレームワークは、同一タイプの問題に様々な形式で問題キーを生成していました。表13-6は、これらの問題キーとそれらを使用して問題を調査する方法について説明しています。

表13-6 捕えられていない例外の問題キー

例外

問題キー

説明

java.lang.OutOfMemoryError

DFW-99997 [java.lang.OutOfMemoryError]

すべてのjava.lang.OUtOfMemoryErrorインシデントで使用されます。このタイプの各インシデントによって、jvm.classhistogramダンプが実行されます。ダンプは、ロードされたクラスのインスタンスと関連オブジェクトの数に関する統計を取得します。

このダンプの内容を確認し、JVMメモリーに何がロードされたかを理解するための効率的な手がかりとなる情報を見つけてください。また、dms.metricsダンプは、全体的なJVMメモリーに関する統計を記録します。

java.sql.SQLException

DFW-99996 [ora-code|java.sql.SQLException]][package.class.method][app-name]

サブクラスを含むjava.sql.SQLExceptionタイプのすべての例外に使用されます。診断フレームワークは、例外エラー・メッセージからOracleエラー・コードの抽出を試み、成功した場合はそのコードを問題キーに使用します。失敗した場合は、例外名を使用します。

例外に関連するテキストを確認し、データベースで実行されなかった操作などの詳細を取得します。さらに、SQLエラー・コードの詳細で追加情報を確認できます。

その他すべて

DFW-99998 [exception-name][package.class.name][app-name]

固有の方法では処理されないその他すべての例外タイプ(java.lang.NullPointerException、java.io.IOException、java.lang.StringIndexOutOfBoundsExceptionなど)で使用されます。

例外に関連付けられたテキストを確認し、障害の理由などの詳細を取得します。問題キーのソース行で障害の場所が示されている可能性があります。

13.4.4 診断ダンプの処理

問題が疑われる場合、組込みの診断ダンプを利用して、問題の診断に役立つ詳細な診断結果を報告できます。診断ダンプは、診断データを出力および記録する手段を提供します。診断データは、Oracle Fusion Middlewareのコンポーネント、アプリケーションおよびインフラストラクチャに関する問題を診断する際に有益な情報になります。これらのダンプからの出力は、Oracle Fusion Middlewareに関する問題を診断するために、顧客およびOracleサポートが使用することを想定しています。

診断ダンプは、次のように実行します。

- 手動。次の各項で説明するように、WLSTコマンドを使用します。
たとえば、Java EEアプリケーションがハングしてデッドロックが疑われる場合には、jvm.threadsダンプを使用して一連のスレッドを取得できます。

- 自動。診断フレームワークがクリティカル・エラーを検出してインシデントを作成した場合、または管理者がインシデントを作成した場合。

13.4.4.1 診断ダンプの一覧表示

管理対象サーバーで使用可能な診断ダンプのリストを検索するには、次の形式でWLSTのlistDumpsコマンドを実行します。

listDumps([appName] [,server])

たとえば、wls_server1で使用可能なダンプを一覧表示するには、次のコマンドを使用します。

listDumps(server='wls_server1')
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)
dfw.samplingArchive
dms.configuration
dms.ecidctx
dms.metrics
http.requests
jvm.classhistogram
jvm.threads
mds.MDSInstancesDump
odl.activeLogConfig
odl.logs
odl.quicktrace
opss.diagTest
opss.identityStoreUserRoleApiConfig
opss.securityContext
wls.image

Use the command describeDump(name=<dumpName>) for help on a specific dump.

表13-7は、Oracle Fusion Middlewareで定義される診断ダンプ操作とその説明を記載したものです。

表13-7 診断ダンプ操作

ダンプ操作

説明

dms.ecidctx

特定の実行コンテキストID (ECID)が指定されている場合は、それに関連付けられたデータ。そうでない場合は、使用可能なすべてのECIDに関連付けられたデータ。

dms.metrics

ダイナミック・モニタリング・サービス(DMS)メトリック。これらのメトリックについては、『パフォーマンスのチューニング』のダイナミック・モニタリング・サービス(DMS)に関する項を参照してください。

http.requests

現在アクティブなHTTPリクエストのサマリー。

jvm.classhistogram

JVMクラス・ヒストグラム。その出力内容は、JVMベンダーによって異なります。

jvm.flightRecording

アクティブなJRockitフライト・レコーダの記録。

jvm.threads

JVMで実行中のスレッド、および完全なスレッド・ダンプを実行中のスレッドに関する統計サマリー。

mds.MDSInstancesDump

現在のJVMの各MDSインスタンスに関する情報。

odl.activeLogConfig

アクティブなJavaロギング構成。

odl.logs

ECIDまたは時間範囲で関連付けられる診断ログの内容。

odl.quicktrace

クイック・トレース・メッセージ

wls.image

WLDFサーバー・イメージ・ダンプ。

また、Oracle SOA Suiteでは、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のSOAコンポジット・アプリケーションを使用した問題の診断に関する項の説明に従って、診断ダンプが提供されます。

13.4.4.2 診断ダンプの説明の表示

WLSTのdescribeDumpコマンドを使用して、ダンプを実行する際の構文など、特定のダンプの説明を表示できます。目的のダンプの名前を指定します。たとえば、dms.metricsダンプの説明を表示するには、次のコマンドを使用します。

describeDump(name='dms.metrics')
Name: dms.metrics
Description: Dumps DMS (Dynamic Monitoring Service) metrics.
Run Mode: asynchronous
Mandatory Arguments:
Optional Arguments:
Name        Type     Description
dump        STRING   How much to dump
servers     STRING   Server names
names       STRING   Name of DMS noun or metric
format      STRING   Format of the dump output; raw or xml
nountypes   STRING   Type of DMS noun

13.4.4.3 ダンプの実行

問題を検出して追加の診断データを収集する場合、指定したダンプに対してexecuteDumpコマンドを起動します。それぞれのダンプには、必須またはオプション、あるいはその両方の引数があります。特定のダンプの引数やその指定方法を確認するには、第13.4.4.2項の説明に従って、describeDumpコマンドを使用します。

次の例では、名前がdms.metricsでインシデントIDが1のダンプを実行し、それをファイルdumpout.txtに書き込んでいます。

executeDump(name='dms.metrics', outputFile='/tmp/dumpout.txt', id='1')
Dump file dms_metrics1_i1.dmp added to incident 1

このコマンドは、ダンプ出力をインシデント1に関する情報に書き込みます。インシデント1に対してshowIncidentコマンドを実行すると、出力結果にはdms_metrics1_i1.dmpが含まれます。

13.4.5 診断ダンプ・サンプリングの構成と使用

診断ダンプ・サンプリングは、指定された間隔で診断ダンプの出力を取得します。定期的な間隔でサンプルを取得する診断ダンプ・サンプリングにより、低速なWebリクエストなどの問題や、これらのリクエストのどこで処理が実行されているなどを特定できます。

この項の内容は次のとおりです。

- 診断ダンプ・サンプリングの理解

- ダンプ・サンプリングの構成

- ダンプ・サンプリングのリスト

- ダンプ・サンプリング出力の取得

13.4.5.1 診断ダンプ・サンプリングの理解

すべての診断ダンプ・サンプリングは、指定した間隔で、バックグラウンドで実行されます。デフォルトでは、jvm.threadsおよびjvm.classhistogramダンプがサンプリング用に構成されています。ただし、インシデントが生成されるまでこれらはアクティブではありません。インシデントが生成されると、デフォルトで72時間、アクティブになります。

デフォルト・ダンプ・サンプリングに対する設定を変更し、また表13-7に示したダンプ操作およびアプリケーション固有のダンプに対して新しいサンプリング定義を作成できます。サンプリング間隔やサーバーなどについて異なる設定を指定して、同じ診断ダンプに対して複数のサンプリング定義を構成できます。

各診断ダンプ・サンプリングに対して、診断フレームワークにより、指定された数のサンプルが保存されます。上限に達すると、最も古いサンプルからパージされます。サーバーの停止時にはすべてのサンプルがパージされます。

表13-8に、デフォルトで構成されているダンプ・サンプリングの設定を示します。

表13-8 デフォルトの診断ダンプ・サンプリング構成

ダンプ名

サンプリング間隔

保存される最大サンプル数

jvm.threads

60秒

10

jvm.classhistogram

30分

5

診断フレームワークにより、インシデントが作成されるたびに(エラー検出またはインシデントの手動作成により)、ダンプ・サンプルの取得がトリガーされます。また、ダンプ・サンプルの内容を取得することもできます(第13.4.5.4項を参照)。

ダンプ・サンプル・アーカイブは、テキストまたはzipファイルとして取得できます。

- テキスト: デフォルトでは、診断ダンプ・サンプルはテキスト形式で1つのアーカイブ・ファイルに連結されます。アーカイブ・ファイル内では、各サンプルはASCIIヘッダーとフッターによりラップされます。ヘッダーには、サンプルを生成した診断ダンプのタイムスタンプと名前が含まれます。ヘッダーとフッターの両方に、アーカイブ内のサンプルの数と、その特定のサンプルの番号が含まれます。次に例を示します。

$$$=== BEGIN OF Diagnostic Dump - jvm.classhistogram (Archive #0 1_of_2) ===$$$
Fri Sep 07 07:00:00 PDT 2013

<text of dump sampling>

$$$=== END OF Diagnostic Dump - jvm.classhistogram (Archive #0 1_of_2) ===$$$

- Zip: 連結ファイルのかわりにzipファイルを返すように、診断ダンプ・サンプリングを構成できます。zipファイルには、使用可能なすべてのダンプ・サンプル・ファイルが含まれます。この形式では、出力が連結に適していないバイナリ形式である診断ダンプや、テキスト形式で出力を生成するダンプがサポートされます。またこの形式では、サンプルを含むアーカイブのサイズも縮小できます。
次の例は、zipファイルの内容を示しています。

unzip -l jvm_dump.zip
Archive:  jvm_dump.zip
Length     Date   Time    Name
--------    ----   ----    ----
508780  08-21-13 07:25   dfw_samplingArchive1065570966467923683.JVMThreadDump.dmp
840  08-21-13 07:25   dfw_samplingArchive7749640004639161119.readme.txt
--------                   -------
509620                   2 files

ダンプ・サンプルの取得時には、テキストまたはzipファイルに加え、診断フレームワークによりREADMEファイルが生成されます。READMEファイルには、アーカイブ内の各ダンプ・サンプルの行番号(テキスト形式の場合)または個々のファイル名(zip形式の場合)のリストが含まれます。また、各サンプルのタイムスタンプおよびアーカイブに対する索引も含まれます。

ダンプ・サンプル・ファイルには次の形式で名前が付けられます。

dfw_dumpArchivennn.Sampling_Name.{txt]|zip}

ここで、nnnは、診断フレームワークにより割り当てられる一意の番号です。

たとえば、次はJVMThreadDumpに対するダンプ・サンプル・ファイルの例です。

dfw_dumpArchive17394218037.JVMThreadDump.txt

READMEファイルには次の形式で名前が付けられます。

dfw_dumpArchivennn.readme.txt

ここで、nnnは、診断フレームワークにより割り当てられる一意の番号です。

すべてのサンプリングは、頻度に対応する、次の間隔で開始するようにスケジュールされます。たとえば、サンプリングが午後12:05:13に構成され、頻度が5秒の場合、サンプルは午後12:05:15に収集されます。これにより、同じ頻度の一連のサンプリングが同時に実行されるようになります。また、システム・クロックが同期化されていれば、異なるマシン上でもすべてのサンプルが同時に取得されます。

注意:
WLSTダンプ・サンプリング・コマンドを実行するには、管理サーバーに接続している必要があります。

13.4.5.2 ダンプ・サンプリングの構成

次の各項で説明しているように、追加のダンプ・サンプリングを作成し、既存のダンプ・サンプリングを更新し、ダンプ・サンプリングを削除し、ダンプ・サンプリングを有効化または無効化できます。

- デフォルト・サンプルのアクティブ化

- ダンプ・サンプリングの作成

- ダンプ・サンプリング設定の変更

- ダンプ・サンプリングの削除

- すべてのダンプ・サンプリングの有効化または無効化

13.4.5.2.1 デフォルト・サンプルのアクティブ化

デフォルトでは、jvm.threadsおよびjvm.classhistogramダンプは、インシデントが発生するまでアクティブではありません。インシデントが発生すると、デフォルトで72時間、アクティブになります。

MBean DumpSamplingIdleWhenHealthyをfalseに設定することにより、インシデントが発生しなくてもダンプがアクティブになるように、動作を変更できます。

システムのヘルスを判定するために費やす時間を変更するには、DumpSamplingMinimumHealthyPeriod MBeanの値を変更します。

診断フレームワークMBeanの値の変更の詳細は、第13.3.1項を参照してください。

13.4.5.2.2 ダンプ・サンプリングの作成

表13-7に示したダンプおよびアプリケーション固有のダンプに対して、ダンプ・サンプリングを作成できます。ダンプ・サンプリングを作成するには、WLSTコマンドaddDumpSampleを使用します。addDumpSampleコマンドでは、次の構文を使用します。

addDumpSample(sampleName="sample_name", diagnosticDumpName="dump_name",
[appName="application_name",] samplingInterval=num_seconds,
rotationCount=num_samples, [dumpedImplicitly={true|false},]
[toAppend={true|false},] [args={"arg_name" : "value"},]
[server="server_name"])

たとえば、wls_server1サーバーに対して、http.requestsダンプに対するダンプ・サンプリングを作成し、サンプリング間隔を300秒、繰返し回数を10サンプルに設定するには、次のように指定します。

addDumpSample(sampleName="HTTPSampling", diagnosticDumpName="http.requests", samplingInterval=300, rotationCount=10, server="wls_server1")

HTTPSampling is added

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のaddDumpSampleに関する項を参照してください。

13.4.5.2.3 ダンプ・サンプリング設定の変更

WLSTコマンドupdateDumpSampleを使用することにより、既存のダンプ・サンプリングの設定を変更できます。updateDumpSampleコマンドでは、次の構文を使用します。

updateDumpSample(sampleName="sample_name",
[        appName="application_name",] samplingInterval=num_seconds,
rotationCount=num_samplings, [dumpedImplicitly={true|false},]
[        toAppend={true|false},] [args={"arg_name" : "value"},]
[        server="server_name"])

たとえば、サンプリング間隔を200に、繰返し回数を5に変更して、ダンプ・サンプリングHTTPSamplingを変更するには、次のように指定します。

updateDumpSample(sampleName="HTTPSampling", samplingInterval=200,
rotationCount=5, server="wls_server1")

HTTPSampling is updated

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のupdateDumpSampleに関する項を参照してください。

13.4.5.2.4 ダンプ・サンプリングの削除

WLSTコマンドremoveDumpSampleを使用することにより、既存のダンプ・サンプリングを削除できます。removeDumpSampleコマンドでは、次の構文を使用します。

removeDumpSample(sampleName="sample_name", [server="server_name"])

たとえば、ダンプ・サンプリングHTTPSamplingを削除するには、次のように指定します。

removeDumpSample(sampleName="HTTPSampling", server="wls_server1")

Removed HTTPSampling

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のremoveDumpSampleに関する項を参照してください。

13.4.5.2.5 すべてのダンプ・サンプリングの有効化または無効化

WLSTコマンドenableDumpSamplingを使用することにより、すべてのダンプ・サンプリングを有効化または無効化できます。このコマンドは、構成済のすべてのダンプ・サンプリングに影響します。enableDumpSamplingコマンドでは、次の構文を使用します。

enableDumpSampling(enable={true|false}, [server="server_name"])

serverパラメータは、管理サーバーに接続している場合にのみ有効です。serverパラメータを指定しないと、管理サーバーに対してダンプ・サンプリングが無効化されます。

たとえば、管理サーバーに対してダンプ・サンプリングを無効化するには、次のように指定します。

enableDumpSampling(enable=false)

Dump sampling disabled

ダンプ・サンプリングが有効化されているのかどうかを確認するには、WLSTコマンドisDumpSamplingEnabledを使用します。isDumpSamplingEnabledコマンドでは、次の構文を使用します。

isDumpSamplingEnabled([server="server_name"])

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のenableDumpSamplingおよびisDumpSamplingEnabledに関する項を参照してください。

13.4.5.3 ダンプ・サンプリングのリスト

WLSTコマンドlistDumpSamplesを使用することにより、ダンプ・サンプリングをリストできます。すべてのダンプ・サンプリング、指定したダンプ・サンプリングまたは特定のサーバーに関連付けられているすべてのダンプ・サンプリングをリストできます。listDumpSamplesコマンドでは、次の構文を使用します。

listDumpSample([sampleName="sample_name",] [server="server_name"])

たとえば、wls_server1サーバーに関連付けられているすべてのダンプ・サンプリングをリストするには、次のように指定します。

listDumpSamples(server="wls_server1")
Name              : JVMThreadDump
Dump Name         : jvm.threads
Application Name  :
Sampling Interval : 30
Rotation Count    : 20
Dump Implicitly   : true
Append Samples    : true
Dump Arguments    : context=true, timing=true, progressive=true, depth=20, threshold=30000

Name              : JavaClassHistogram
Dump Name         : jvm.classhistogram
Application Name  :
Sampling Interval : 1800
Rotation Count    : 5
Dump Implicitly   : false
Append Samples    : true
Dump Arguments    :

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のlistDumpSampleに関する項を参照してください。

13.4.5.4 ダンプ・サンプリング出力の取得

ダンプ・サンプルの出力を取得するには、次の各項で説明するように、WLSTコマンドexecuteDumpまたはgetSamplingArchivesを使用します。

- executeDumpコマンドを使用したダンプ・サンプルの取得

- getSamplingArchivesコマンドを使用したダンプ・サンプルの取得

13.4.5.4.1 executeDumpコマンドを使用したダンプ・サンプルの取得

WLSTコマンドexecuteDumpを使用し、dfw.samplingArchiveダンプを指定することにより、ダンプ・サンプルを取得できます。このコマンドは、すべてのデフォルト・サンプル・アーカイブ、および一時的な場所にあり、dumpImplicitly=trueパラメータが指定されているダンプ・サンプルを収集し、1つのファイルに連結します。このコマンドは、ダンプ・サンプルの詳細を含むREADMEファイルも返します。

executeDumpコマンドでは、次の構文を使用します。

executeDump(name="dfw.samplingArchive",outputFile="filename"

outputFileパラメータに対しては、テキスト・ファイルまたはzipファイルを指定できます。zipファイルを指定する場合は、引数zipOutput=trueを使用する必要があります。

dumpImplicitly=falseパラメータが構成されているダンプ・サンプリングについては、その内容を収集するには、オプションのdfw.samplingArchive引数sampleNameを指定する必要があります。次に例を示します。

executeDump(name='dfw.samplingArchive', args={'sampleName' : 'JavaClassHistogram'})

詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のexecuteDumpに関する項を参照してください。

13.4.5.4.2 getSamplingArchivesコマンドを使用したダンプ・サンプルの取得

WLSTコマンドgetSamplingArchivesを使用することにより、ダンプ・サンプリングを取得できます。このコマンドはすべてのダンプ・サンプルを、個々のダンプ・サンプル・ファイルとREADMEファイルを含むzipファイルに収集します。この方法は、バイナリ形式のダンプを扱う場合に特に有用です。

getSamplingArchivesコマンドでは、次の構文を使用します。

getSamplingArchives([sampleName="sample_name"] [,outputFile="filename" [,server="server_name"])

たとえば、サンプリングJavaClassHistogramに対するダンプ・サンプルを取得するには、次のコマンドを使用します。

getSamplingArchives(sampleName="JavaClassHistogram", outputFile="/tmp/sampling.zip")

次の例は、zipファイルの内容を示しています。

unzip -l /tmp/sampling.zip
Archive:  /tmp/sampling.zip
Length     Date   Time    Name
--------    ----   ----    ----
6241768  04-27-13 11:19   dfw_samplingArchive8680976839106379444.JavaClassHistogram.dmp
552  04-27-13 11:19   dfw_samplingArchive7861027727509995202.readme.txt
--------                   -------
6242320                   2 files

完全な構文については、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のgetSamplingArchivesに関する項を参照してください。

13.4.6 インシデントの管理

診断フレームワークでは、自動で作成されるか手動で作成されるかに関係なく、インシデントが格納されます。Oracle Fusion Middlewareには、インシデントのレポートの処理に役立ち、それらのインシデントをパッケージ化してOracleサポートに送信するツールが用意されています。各項目で説明する内容は次のとおりです。

- インシデントの手動作成

- 集計インシデントの作成

- インシデントのパッケージ化

- インシデントのパージ

13.4.6.1 インシデントの手動作成

システムで生成された問題(内部で生成されたクリティカル・エラー)は、自動診断リポジトリ(ADR)に自動的に追加されます。それらの問題に関する追加の診断データを収集し、それをOracleサポートにアップロードできます。また場合によっては、問題を解決することもできます。これらはすべて、第13.4項で説明されているワークフローに記載されています。

ソフトウェアの障害やパフォーマンスの問題などに直面して詳細な診断データを収集する必要があるものの、診断フレームワークでインシデントが自動的に作成されていない場合は、インシデントを手動で作成することを検討してください。

インシデントを手動で作成するには、WLSTコマンドのcreateIncidentを使用します。インシデントは、時間、メッセージID、影響領域またはECIDを基準に指定できます。ここで、インシデントの内容を調べたり、Oracleサポートに送信してさらなる分析を依頼することができます。

たとえば、メッセージIDに基づいてインシデントを手動で作成する手順は、次のとおりです。

1. 第12.3.2項の説明に従って、ログ・ファイルを検索します。直面している問題に関連すると疑われるメッセージがあったら、インシデントを作成するときにそのメッセージIDを使用できます。

2. 次のコマンドを使用してWLSTを起動し、管理対象サーバーに接続して、管理対象サーバー・インスタンスにナビゲートします。

java weblogic.WLST
connect('username', 'password', 'localhost:7001')
cd('servers/server_name')

3. 次の形式でcreateIncidentコマンドを使用して、インシデントを作成します。

createIncident([adrHome] [,incidentTime] [,messageId] [,ecid] [,appName]
[,description] [,server])

たとえば、メッセージIDがMDS-50500のエラーを基準としてインシデントを作成するには、次のコマンドを使用してメッセージIDを指定し、ユーザーおよびOracleサポートがインシデントを追跡しやすいように、インシデントの説明を入力します。

createIncident(messageId='MDS-50500', description='sample incident')
Incident Id: 1
Problem Id: 1
Problem Key: MDS-50500 [MANUAL]
Incident Time:Fri Mar 28 11:02:22 PDT 2015
Error Message Id: MDS-50500
Execution Context:null
Flood Controlled: false
Dump Files :
jvm_threads10_i1.txt
dms_metrics11_i1.txt
dfw_samplingArchive13_i1.JVMThreadDump.txt
dfw_samplingArchive13_i1.readme.txt
odl_logs14_i1.txt

サーバーを指定しないと、インシデントは接続されているサーバーから情報を収集します。サーバーを指定するには、次の例に示すようにserverオプションを使用します。

createIncident(messageId='MDS-50500', description='sample incident', server='wls_server1')
)

adrHomeオプションを指定しないと、インシデントは接続されているサーバーに作成されます。たとえば、管理サーバーに接続している場合、インシデントは管理サーバーのadrHomeに作成されます。

診断フレームワークはコマンドを評価して、適切な診断ダンプを起動します。インシデントおよび診断ダンプはADRに書き込まれます。それぞれの診断ダンプは、その出力結果をインシデントに書き込みます。

第13.4.2.2項で説明するように、インシデントに関する情報を表示できます。

第13.4.4項で説明するように、ダンプに情報を表示できます。

13.4.6.2 集計インシデントの作成

複数のインシデントがあり、それを1つのインシデントにまとめる場合は、WLSTのcreateAggregatedIncidentコマンドを使用できます。たとえば、選択的なトレースを使用した場合、トレース・データが含まれている結果のインシデントは複数のサーバーで生成される可能性があります。createAggregatedIncidentコマンドによって、指定する基準を満たす集計インシデントを生成できます。元のインシデントはそのままです。つまり、集計インシデントには問合せられたインシデントの複数のインシデント・ファイルのコピーが含まれています。

集計インシデントは管理サーバーのホストで作成されますが、これはドメイン内の1つ以上のサーバーまたはすべてのサーバーのインシデントを含むことができます。

インシデント属性、演算子、文字列が次の形式で含まれる式を使用して、問合せを作成できます。

attribute operator "string"

問合せ式をブール演算子ANDまたはORで連結し、カッコ()でグループ化できます。

サポートされている属性と演算子の詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のcreateAggregatedIncidentに関する項を参照してください。

各集計インシデントには、問合せから戻された各インシデントのzipファイルと、使用された問合せの詳細な説明テキストおよび各インシデントの詳細が含まれます。

たとえば、wls_server1サーバーでODL_TRACE_IDが123456を含むすべてのインシデントの集計インシデントを作成するには、次のコマンドを実行します。

createAggregatedIncident(query="ORDL_TRACE_ID equals 123456", servers="wls_server1")
Incident 55 created, containing the following incidents:
Server wls_server1
Incident Id    Problem Key                                     Incident Time
15                 TRACE [123456] [MANUAL]          Mon Apr 15 11:22:12 EDT 2015

ドメイン内のすべてのサーバー上で、ODL_TRACE_IDが123456を含むすべてのインシデントの集計インシデントを作成するには、次のコマンドを実行します。

createAggregatedIncident(query="ORDL_TRACE_ID equals 123456")
Incident 55 created, containing the following incidents:
Server wls_server1, wls_server2
Incident Id    Problem Key                                     Incident Time
15                 TRACE [123456] [MANUAL]          Mon Apr 15 11:22:12 EDT 2015

13.4.6.3 インシデントのパッケージ化

インシデントをパッケージ化して、その情報を容易にOracleサポートに送信できるようにするには、ADRコマンド・インタプリタ(ADRCI)を使用します。ADRCIユーティリティを使用すると、コマンド行環境で問題を調査および報告できます。ADRCIにより、インシデントおよび問題の情報をzipファイルにパッケージ化して、Oracleサポートに送信できます。

ADRCIコマンド行ユーティリティは次のディレクトリにあります。

(UNIX) ORACLE_HOME/oracle_common/adr
(Windows) ORACLE_HOME\oracle_common\adr

インシデントのパッケージ化は、次の3つのプロセスに分かれています。

1. 論理パッケージを作成します。
このパッケージは、ADRではメタデータとしてのみ存在するため、論理的なものと示されます。論理パッケージから物理パッケージを生成するまで、その中身はありません。論理パッケージにはパッケージ番号が割り当てられ、以降のコマンドではその番号でそのパッケージを参照します。

論理パッケージは、空のパッケージとして、あるいはインシデント番号、問題番号、問題キーまたは時間間隔を基準としたパッケージとして作成することができます。空のパッケージとしてパッケージを作成した場合は、ステップ2で診断情報を追加できます。

インシデントを基準にパッケージを作成すると、ダンプなど、そのインシデントの診断データが含まれることになります。問題番号または問題キーを基準にパッケージを作成すると、その問題番号または問題キーを参照するインシデントのパッケージ診断データが含まれることになります。時間間隔を基準にパッケージを作成すると、その時間間隔内に発生したインシデントの診断データが含まれることになります。

2. 診断情報をパッケージに追加します。
インシデント番号、問題番号、問題キーまたは時間間隔を基準として論理パッケージを作成した場合は、この手順は省略できます。追加のインシデントをパッケージに追加したり、ADR内の任意のファイルをパッケージに追加することができます。空のパッケージを作成した場合は、ADRCIコマンドを使用して、インシデントまたはファイルをパッケージに追加する必要があります。

3. 物理パッケージを生成します。
物理パッケージを生成するコマンドを発行すると、ADRCIでは必要な診断ファイルをすべて収集し、目的のディレクトリ内のzipファイルに追加します。完全なzipファイルまたは増分zipファイルを生成できます。増分ファイルには、同じ論理パッケージでzipファイルが前回作成されてから追加または変更された診断ファイルがすべて含まれます。増分ファイルは、完全ファイルを作成した後にのみ作成可能で、いくつでも作成できます。それぞれのzipファイルには、正しい順序で分析できるように、順序番号が割り当てられます。

zipファイルは、次の形式に従って名前が付けられます。

packageName_mode_sequence.zip

この形式の各項目について説明します。

- packageNameは、問題キーの一部にタイムスタンプが続きます。

- modeは、COM(完全)またはINC(増分)です。

- sequenceは整数です。

たとえば、インシデントをパッケージ化するには、次の手順を実行します。

1. 次の例に示すように、ORACLE_HOMEおよびLD_LIBRARY_PATH環境変数を設定します。

ORACLE_HOME=ORACLE_HOME/oracle_common
LD_LIBRARY_PATH=ORACLE_HOME/oracle_common/adr

2. ADRCIを起動します。次に例を示します。

ORACLE_HOME/oracle_common/adr/adrci

3. SET BASEコマンドを使用してADRベースを指定し、SET HOMEPATHコマンドを使用してインシデントを含むADRホームを指定します。HOMEPATHのパスは、ADRベースを基準に指定します。

SET BASE /scratch/oracle/config/domains/wls_domain/servers/wls_server1/adr
SET HOMEPATH diag/ofm/wls_domain/wls_server1

4. 論理パッケージを生成します。

IPS CREATE PACKAGE INCIDENT incident_number

たとえば、次のコマンドを実行すると、インシデント1を基準にパッケージが作成されます。

IPS CREATE PACKAGE INCIDENT 1
Created package 1 based on incident id 1, correlation level typical

ADRCIにより、論理パッケージに番号が割り当てられます。

5. オプションで、論理パッケージに診断情報を追加できます。次のタイプの情報を追加できます。

- 特定のインシデントのすべての診断情報。たとえば、次のコマンドを使用して、パッケージ化したインシデントに関連すると思われる別のインシデントを追加できます。

IPS ADD INCIDENT incident_number PACKAGE package_number

- ADR内にある、名前が付けられたファイル。たとえば、インシデントがアプリケーションに関連する場合、そのアプリケーションに対する.earファイルを追加できます。また、ユーザーがOracleサポートに通知するメモを記したreadmeファイルを追加することもできます。たとえば、パッケージにファイルを追加するには、次のコマンドを使用します。

IPS ADD FILE filespec PACKAGE package_number

6. 次のコマンドを使用して、物理パッケージを生成します。

IPS GENERATE PACKAGE package_number IN path

たとえば、番号1のパッケージを生成するには、次のコマンドを使用します。

IPS GENERATE PACKAGE 1 in /tmp
Generated package 1 in file /tmp/BEA337Web_20100223132315_COM_1.zip, mode complete

これにより、指定されたパスに完全な物理パッケージ(zipファイル)が生成されます。

詳細は、『Oracle Databaseユーティリティ』の「ADRCI: ADRコマンド・インタプリタ」を参照してください。

13.4.6.4 インシデントのパージ

デフォルトでは、すべてのインシデントの合計サイズが500 MBを超えると、インシデントはパージされます。この値は、第13.3.1項で説明されているように、maxTotalIncidentSize MBeanパラメータを使用して変更できます。

ADRCIコマンドを使用して、インシデントを手動でパージできます。パージは、IDまたはIDの範囲、インシデントの経過時間、またはインシデントのタイプを基準にして行えます。たとえば、経過時間が60分を超えたインシデントをパージするには、次のコマンドを使用します。

purge -age 60

『Oracle Databaseユーティリティ』の「ADRCI: ADRコマンド・インタプリタ」を参照してください。

13.4.7 RDAレポートの生成

コマンド行診断ツールのRemote Diagnostic Agent (RDA)を使用して、ご使用の環境の全体像を把握することができます。また、RDAでは、構成やセキュリティなど、様々な項目に関する推奨事項が提供されています。これは、ユーザーとOracleサポートの問題解決を支援します。

RDAは、エンジンにより実行される、Perlプログラミング言語で作成される一連のコマンド行診断スクリプトです。RDAはOracle環境に関する詳細情報の収集に使用され、収集されたデータは次に問題診断の支援に使用されます。また、その出力は全体的なシステム構成を確認するのに役立ちます。

RDAは、できるだけ控えめであるように設計されており、システムを変更することはありません。必要に応じて、セキュリティ・フィルタが提供されます。

RDAは次の領域の問題のトラブルシューティングに役立つ情報を収集します。

- インストールと構成

- パフォーマンス

- ORA-600エラー、ORA-7445エラー、ORA-3113エラーおよびORA-4031エラー

- アップグレード、移行およびリンク

- Oracle Database

- Oracle Fusion Middleware

RDAを実行するには、次のコマンドを実行します。

(UNIX) ORACLE_HOME/oracle_common/rda/rda.sh
(Windows) ORACLE_HOME\oracle_common\rda\rda.cmd

次に、出力の一部を示します。

./rda.sh
-------------------------------------------------------------------------------
S000INI: Initializes the Data Collection
-------------------------------------------------------------------------------
RDA uses the output file prefix to identify all files belonging to the same
data collection. The prefix must start with a letter and must contain only
alphanumeric characters.

Enter the prefix to be used for all the generated files
Hit 'Return' to accept the default (RDA)
>

Enter the directory used for all the files to be generated
Hit 'Return' to accept the default
(/scratch/oracle1/Oracle/Middleware/Oracle_Home/oracle_common/rda/output)
>

Do you want to keep report packages from previous runs (Y/N)?
Hit 'Return' to accept the default (N)
>

Enter the Oracle home to be used for data analysis
Hit 'Return' to accept the default
(/scratch/oracle1/Oracle/Middleware/Oracle_Home
)

RDAの詳細は、次の場所にあるreadmeファイルを参照してください。

(UNIX) ORACLE_HOME/oracle_common/rda/README_Unix.txt
(Windows) ORACLE_HOME\oracle_common\rda\README_Windows.txt

13.5 ヘルス・テスト・フレームワークの管理および実行

Oracle Fusion Middlewareでは、ヘルス・テスト・フレームワークが提供されています。これには、Oracle Fusion Middlewareおよびそのアプリケーションが正しく動作しているかどうかを判断し、問題があれば特定して解決するために、Oracle Fusion Middlewareおよびそのアプリケーションの特定の部分を動作させる診断テストが含まれます。

この項の内容は次のとおりです。

- ヘルス・テスト・フレームワークの理解

- ヘルス・テスト・フレームワークのファイル・リポジトリの理解

- ヘルス・テスト・フレームワークのコマンド行の使用方法

- ヘルス・テスト・フレームワークの管理

- ヘルス・テスト・フレームワークの診断テストの実行

- ヘルス・テスト・フレームワークの診断テストの検索

- ヘルス・テスト・フレームワーク・テストの説明の取得

- ヘルス・テスト・フレームワークのテスト・ランのリスト

- ヘルス・テスト・フレームワークのレポートの生成

13.5.1 ヘルス・テスト・フレームワークの理解

ヘルス・テスト・フレームワークでは、診断テストを実行し、結果を収集して、詳細な診断レポートを生成できます。診断テストは、Oracle Fusion Middlewareのインストールまたはパッチ適用時にインストールされます。

ヘルス・テスト・フレームワークを使用して、通常のシステム・ヘルスをチェックし、システムの問題をトラブルシューティングできます。ヘルス・テスト・フレームワークのコマンド行インタフェースを使用して診断テストを実行するように、Oracle Fusion Middleware環境を構成できます。

診断テストを特定のエラー・メッセージと関連付けることができます。Oracle Fusion Middlewareアプリケーションが特定のエラーを、インシデントの作成をトリガーするような方法で処理する場合、そのインシデントに対するエラー・メッセージに関連付けられている診断テストが自動的に実行されます。テスト結果はインシデントに関連付けられ、エラー・メッセージを受信したユーザーが誰であるかが記録されます。診断テストは、第13.5.2項で説明するように、ファイルベース・リポジトリに保存されます。

13.5.2 ヘルス・テスト・フレームワークのファイル・リポジトリの理解

ヘルス・テスト・フレームワークは、テストおよびテスト結果をファイルベースのリポジトリに保存します。リポジトリには次の2つのプライマリ・ストアがあります。

- TestDef: テスト定義、テスト・メタデータ、テスト・パラメータに関連するデータ、言語データファイルおよび索引ファイルが含まれます。

- TestRun: テスト・ランと実行、レポート・ファイルおよび索引ファイルに関連するデータが含まれます。

索引ファイルは、検索および問合せ速度を向上させるために使用されます。

リポジトリは、テストの登録または実行時に指定した場所にリポジトリが存在しない場合に作成されます。

リポジトリの場所は、構成プロパティ・ファイルdiagfsconfig.propertiesで指定できます。このファイルは次の場所にあります。

ORACLE_HOME/diagbase/dtf_filestore

デフォルトでは、ファイル・ストアは次の場所にあります。

ORACLE_HOME/diagbase/dtf_filestore/testdef
ORACLE_HOME/diagbase/dtf_filestore/testrun

13.5.3 ヘルス・テスト・フレームワークのコマンド行の使用方法

次の各項で説明するように、ヘルス・テスト・フレームワークには、管理コマンド用のdfwhealthtestadminctl.shと、実行コマンド用のdfwhealthtestctl.shという2つのコマンド行インタフェースがあります。

- dfwhealthtestadminctl.shコマンド行

- dfwhealthtestctl.shコマンド行

13.5.3.1 dfwhealthtestadminctl.shコマンド行

ヘルス・テスト・フレームワークには、ヘルス・テストを管理するためのdfwhealthtestadminctl.shコマンド行があります。これを使用して、テストを登録し、索引を再構築できます。

dfwhealthtestadmin.ctlコマンドを実行する前に、次の環境変数を設定する必要があります。

- ORACLE_HOME: Oracleホーム

- JAVA_HOME: Javaホーム

- dtf_fs_diagbase: リポジトリの場所

dfwhealthtestadminctl.shコマンド行は次の場所にあります。

ORACLE_HOME/oracle_common/common/bin

コマンド行インタフェースの構文は、次のとおりです。

/dfwhealthtestadminctl.sh command [options]

表13-9に、ヘルス・テスト・フレームワークの管理コマンドを示します。

表13-9 ヘルス・テスト・フレームワークのdfwhealthtestadminctl.shコマンド

コマンド

説明

help

コマンド行ヘルプを表示します。

register

1つ以上のヘルス・テスト・フレームワーク・テストをリポジトリに登録します。

index

既存のデータ・ファイルで索引を再構築します。

13.5.3.1.1 help

コマンドのヘルプを表示します。

構文は次のとおりです。

help command

次の表に、helpコマンドのパラメータを示します。

パラメータ

説明

command

コマンドの名前。

13.5.3.1.2 register

1つ以上のテストをリポジトリに登録します。

構文は次のとおりです。

register testfile=test_xml_files | dir=test_dirs
[validateonly={Y|N]]
testjar=jar_file_location

次の表に、registerコマンドのパラメータを示します。

パラメータ

説明

testfile

登録する1つ以上のXMLテスト・ファイル。ファイルへのパスを指定します。複数のファイルを指定する場合は、カンマ区切りリストを使用します。

dir

登録する1つ以上のディレクトリ。ディレクトリへのパスを指定します。複数のディレクトリを指定する場合は、カンマ区切りリストを使用します。このオプションは、同じディレクトリからの複数のテストを登録する場合に使用します。

validateonly

オプション。テストを検証するだけなのか、またはテストをリポジトリにアップロードするのかを指定するブール値。有効な値は、Y(テストの検証のみ)またはN(テストのアップロード)です。

testjar

テストjarファイルの場所。

13.5.3.1.3 index

リポジトリ内のデータ・ファイルを使用して、testdefまたはtestrunリポジトリに対する索引を再構築します。

構文は次のとおりです。

index [refresh={testdef|testrun}

次の表に、indexコマンドのパラメータを示します。

パラメータ

説明

refresh=testdef

testdefリポジトリの索引をリフレッシュします。

refresh=testrun

testrunリポジトリの索引をリフレッシュします。

13.5.3.2 dfwhealthtestctl.shコマンド行

ヘルス・テスト・フレームワークには、ヘルス・テストを実行するためのdfwhealthtestctl.shコマンド行があります。このコマンド行では、テストの実行、ランとテストのリスト、テストの説明の表示、テストのステータスの取得、およびテストまたはテスト・ランのレポートの取得を行えます。

dfwhealthtestctl.shコマンド行は次の場所にあります。

ORACLE_HOME/oracle_common/common/bin

コマンド行インタフェースの構文は、次のとおりです。

/dfwhealthtestctl.sh command [options]

表13-10に、ヘルス・テスト・フレームワークのdfwhealthtestctl.shコマンドを示します。

表13-10 ヘルス・テスト・フレームワークのdfwhealthtestctl.shコマンド

コマンド

説明

desctest

指定されたテストの詳細な説明を表示します。

listrun

テスト・ランをリストします。

listtest

1つ以上のテストの説明をリストします。

report

テスト・ランのレポートを抽出します。

run

1つ以上のテストを実行します。

status

テスト・ランまたは実行のステータスを取得します。

13.5.3.2.1 desctest

指定されたテストの詳細な説明を表示します。

構文は次のとおりです。

desctest {testid=testid | testname=testname}]
[showparam={Y|N}]

次の表に、desctestコマンドのパラメータを示します。

パラメータ

説明

testid

テストのID。IDを取得するには、listtestコマンドを使用します。このパラメータまたはtestnameパラメータのいずれかを指定する必要があります。

testname

テストの名前。このパラメータまたはtestidパラメータのいずれかを指定する必要があります。

showparam

オプション。テストのパラメータを取得するかどうかを指定するブール値。有効な値はYまたはNです。

13.5.3.2.2 help

コマンドのヘルプを表示します。

構文は次のとおりです。

help command

次の表に、helpコマンドのパラメータを示します。

パラメータ

説明

command

コマンドの名前。

13.5.3.2.3 listrun

テスト・ランに対するサマリー情報を取得します。ラン名、ラン・ステータス、開始時間またはテスト名に基づいて情報を取得できます。

構文は次のとおりです。

listrun { runname=runname | testname=testname | status=status | lasthours=hours }
[showexec={Y|N]]

次の表に、listrunコマンドのパラメータを示します。

パラメータ

説明

runname

結果を取得するランの名前。runnameを取得するには、パラメータを指定せずにlistrunコマンドを実行します。

testname

結果を取得するテストの名前。

ステータス

結果を取得するランのステータス。有効な値は、running、warningおよびsuccessです。

lasthours

結果を取得する時間数。

showexec

オプション。テストの実行を取得するかどうかを指定するブール値。有効な値はYまたはNです。

13.5.3.2.4 listtest

1つ以上のテストをリストします。ワイルドカードを使用してテストの名前を指定できます。

構文は次のとおりです。

listtest [testname=testname]
[productcode=productcode

次の表に、helpコマンドのパラメータを示します。

パラメータ

説明

testname

1つ以上のテストの名前のカンマ区切りリスト。ワイルドカードを使用してテストの名前に一致するパターンを指定できます。

productcode

製品の名前。ワイルドカードを使用して製品の名前に一致するパターンを指定できます。

13.5.3.2.5 report

特定のテスト・ランまたは実行に対するテスト・レポートを抽出します。

構文は次のとおりです。

report { runname=runname | runid=run_id | execid=execution_id }
[destdir=destination_directory}
[format=HTML | XML]
[translate={Y | N}

次の表に、reportコマンドのパラメータを示します。

パラメータ

説明

runname

ランの名前。名前を取得するには、listrunコマンドを使用します。このパラメータ、runidまたはexecidのいずれかを指定する必要があります。

runid

ランのID。IDを取得するには、listrunコマンドを使用します。このパラメータ、runnameまたはexecidのいずれかを指定する必要があります。

execid

ランの実行ID。IDを取得するには、listrunコマンドを使用します。このパラメータ、runnameまたはrunidのいずれかを指定する必要があります。

destdir

オプション。レポート・ファイルが書き込まれる宛先ディレクトリ。指定しないと、レポート・ファイルはjava.io.tmpdir/user.name/diagfwkディレクトリに抽出されます。ここで、java.io.tmpdirとuser.nameはJavaシステム・プロパティです。

format

生成されるレポートの形式。有効な値はHTMLおよびXMLです。

translate

レポートを翻訳するかどうかを指定するブール値。有効な値はYまたはNです。

13.5.3.2.6 run

指定されたテストを実行します。

run {test=testnames | productcode=codes }
[runname=name
[runoption=asynch]
[input:param1=value1 param2=value2 ...
[inputfile=filename]
[contextfile=context_file]
[moninterval=monitoring_interval]
[nthreads=number_of_threads]
[reportshowparam=show_param]

次の表に、runコマンドのパラメータを示します。

パラメータ

説明

test

1つ以上のテストの名前のカンマ区切りリスト。
単一のテスト名を指定する場合は、inputパラメータを使用して1つ以上の入力パラメータ名および値も指定できます。

このパラメータまたはproductcodeパラメータのいずれかを指定する必要があります。

productcode

実行するテストを含む1つ以上の製品に対するコード。複数の製品コードを指定するには、カンマ区切りリストを使用します。

runname

オプション。現在のランの名前。指定しないと、コマンドによりデフォルトのラン名が生成されます。

moninterval

ランのステータスがテスト・リポジトリにアップロードされる間隔(秒単位)。デフォルト値は30秒です。

nthreads

このラン内のテストを実行するために生成するパラレル・スレッドの数。デフォルト値は5です。このパラメータに対して値1を指定すると、テストはシリアルに実行されます。

runoption

オプション。テストを実行するためのオプション。有効な値はasynchであり、テストをバックグラウンドで非同期に実行します。

input

オプション。このパラメータを使用する場合は、1つ以上のパラメータ名/値ペアを指定します。次に例を示します。

domainhome=/scratch/oracle/domains/basedomain

このパラメータは、1つのテストだけを実行する場合にのみ使用できます。

inputfile

入力パラメータを含むファイルへのパス。各入力名/値ペアを、ファイル内の別々の行に指定します。各行の形式は次のとおりです。

input_param_name:input_param_value

contextfile

実行時に使用するユーザー・システム・プロパティを含むファイルへのパス。

reportshowparam

入力および出力パラメータの表示を設定します。デフォルトでは、すべてのパラメータは実行時には表示されません。パラメータを表示することを指定するには、inputまたはoutputを指定するか、両方をカンマで区切って指定します。次に例を示します。

reportshowparam=input,output

13.5.3.2.7 status

ラン名、ランIDまたは実行IDを指定して、テスト・ランのステータスを取得します。

構文は次のとおりです。

status { runname=runname | runid=run_id | execid=execution_id }
[printtree={Y|N}

次の表に、statusコマンドのパラメータを示します。

パラメータ

説明

runname

ランの名前。ラン名を取得するには、listrunコマンドを使用します。

runid

ランのID。IDを取得するには、listrunコマンドを使用します。

execid

ランの実行ID。IDを取得するには、listrunコマンドを使用します。

printtree

ネストされているすべての条件のステータスを出力するかどうかを指定します。有効な値はYまたはNです。

13.5.4 ヘルス・テスト・フレームワークの管理

次の各項で説明するように、テストを登録し、索引を再構築できます。

- リポジトリの作成およびヘルス・テスト・フレームワーク・テストの登録

- ヘルス・テスト・フレームワークの索引の再構築

13.5.4.1 リポジトリの作成およびヘルス・テスト・フレームワーク・テストの登録

リポジトリを作成するには、dfwhealthtestadminctl.sh registerコマンドを使用してテストを登録します。コマンドによりリポジトリが作成され、1つ以上のテストがリポジトリに登録されます。

リポジトリを作成してテストを登録する手順は次のとおりです。

1. リポジトリの場所を指定するようにdtf_fs_diagbase環境変数を設定します。次に例を示します。

setenv  dtf_fs_diagbase /scratch/Oracle/Middleware/diag

2. リポジトリを作成し、1つのテストをリポジトリに登録する次のコマンドを実行します。

dfwhealthtestadminctl.sh register testfile=/scratch/tests/sampleTest.xml
testjar=/scratch/tests/testjar

testfileまたはdirパラメータを使用することにより、一度に複数のテストを登録することもできます。

- testfileパラメータを使用して複数のテストを登録するには、カンマ区切りリストまたはワイルドカードを使用できます。
次の例は、カンマ区切りリストを使用して、2つのテストを登録します。

dfwhealthtestadminctl.sh register testfile=/scratch/tests/sampleTest.xml,
/scratch/moretests/sampleTest.xml
testjar=/scratch/tests/testjar

次の例は、ワイルドカードを使用して、複数のテストを登録します。

dfwhealthtestadminctl.sh register testfile=/scratch/tests/%Test.xml,
testjar=/scratch/tests/testjar

- dirパラメータを使用して複数のテストを登録するには、カンマ区切りリストで1つ以上のディレクトリを指定します。
次の例は、指定されたディレクトリ内のすべてのテストを登録します。

dfwhealthtestadminctl.sh register dir=/scratch/dtf_tests

13.5.4.2 ヘルス・テスト・フレームワークの索引の再構築

索引により、ヘルス・テスト・フレームワーク・リポジトリでの検索および問合せの速度が向上します。テスト定義に関連する索引は、testdefファイル・ストアに格納されています。テスト・ランおよび実行に関連する索引は、testrunファイル・ストアに格納されています。

状況によっては、索引のリフレッシュが必要になることがあります。この場合、testdefまたはtestrunファイル・ストアを指定して、dfwhealthtestadminctl.sh indexコマンドを実行します。次の例は、testdefファイル・ストアをリフレッシュします。

dfwhealthtestadminctl.sh index refresh=testdef

13.5.5 ヘルス・テスト・フレームワークの診断テストの実行

ヘルス・テスト・フレームワークの診断テストは、次の場所にあるdfwhealthtestctl.shコマンド行インタフェースを使用して実行します。

ORACLE_HOME/oracle_common/common/bin

テストを実行するには、第13.5.3.2.6項で説明している形式で、runコマンドを使用します。たとえば、SampleTestテストを実行するには、次のコマンドを使用します。

./dfwhealthtestctl.sh command
[testfile=SampleTest.xml]

一度に1つまたは複数のテストを実行できます。

- カンマ区切りリストでテスト名を指定して1つ以上のテストを実行する例

./dfwhealthtestctl.sh run test=oracle.dfw.healthtest.test.sample.SampleTest2
Processing "run" command ...

Executing run ID "1340125981427" with name "TestRun_1340125981427" ...
sampleTest2 sleep for a while....
sampleTest2 done

Run ID "1340125981427" with name "TestRun_1340125981427" started at 3/21/2015
10:13:01 AM and completed at 3/21/2015 10:13:04 AM. No diagnostic issues were detected.

- テスト名にワイルドカードを使用して1つ以上のテストを実行する例

./dfwhealthtestctl.sh run test=oracle.dfw.healthtest.test.sample.SampleTest*

- 特定の製品に関連付けられているすべてのテストを実行する例

./dfwhealthtestctl.sh run productcode=idm

1つのテストのみを実行する場合は、コマンド行または入力ファイルのいずれかで入力オプションを指定できます。

- コマンド行で入力オプションを指定するには、input:パラメータを使用します。

./dfwhealthtestctl.sh run test=oracle.dfw.healthtest.test.sample.SampleTest,oracle.dfw.healthtest.test.sample.SampleTest2
input:userid=11 input:roleid=22

- 入力ファイルで入力オプションを指定するには、ファイルを作成し、inputfileパラメータを使用して、コマンド行でそのファイルを指定します。入力ファイルの形式は次のとおりです。

input_parameter1:parameter_value1
input_parameter2:parameter_value2

次に例を示します。

userid:11
roleid:22

次に、コマンド行でファイルを指定します。

./dfwhealthtestctl.sh run test=oracle.dfw.healthtest.test.sample.SampleTest
inputfile=/tmp/inputfile

13.5.6 ヘルス・テスト・フレームワークの診断テストの検索

dfwhealthtestctl.sh listtestコマンドを使用することにより、テストまたはランを検索できます。オプションで、テストの名前または製品コードを指定できます。

- すべてのテストを検索するには、次のように指定します。

./dfwhealthtestctl.sh listtest

- SampleTestという名前のテストを検索するには、次のように指定します。

./dfwhealthtestctl.sh listtest testname=SampleTest

- ワイルドカードを使用して複数のテストを検索するには、次のように入力します。

./dfwhealthtestctl.sh listtest testname="S*"

- 特定の製品に関連するすべてのテストを検索するには、次のように入力します。

dfwhealthtestctl.sh listtest productcode=idm

13.5.7 ヘルス・テスト・フレームワーク・テストの説明の取得

dfwhealthtestctl.sh listtestコマンドを使用することにより、指定したテストの説明を取得できます。たとえば、SampleTestテストの説明とそのパラメータを取得するには、次のコマンドを使用します。

./dfwhealthtestctl.sh desctest testname="SampleTest" showparam=Y

13.5.8 ヘルス・テスト・フレームワークのテスト・ランのリスト

dfwhealthtestctl.sh listrunコマンドを使用することにより、テスト名、ラン名、ステータスまたは時間に基づいて、テスト・ランの結果を問い合せることができます。

- テスト名を指定してテスト・ランの結果を問い合せるには、次のように指定します。

./dfwhealthtestctl.sh listrun testname="SampleTest"

- ラン名を指定してテスト・ランの結果を問い合せるには、次のように指定します。

./dfwhealthtestctl.sh listrun runname="run_1"

- ステータスを指定してテスト・ランの結果を問い合せることができます。たとえば、ステータスがrunningであるすべてのテストの結果を取得するには、次のように指定します。

./dfwhealthtestctl.sh listrun status=r

- 過去2時間に開始されたテスト・ランの結果を問い合せるには、次のように指定します。

./dfwhealthtestctl.sh listrun lasthours=2

13.5.9 ヘルス・テスト・フレームワークのレポートの生成

dfwhealthtestctl.sh reportコマンドを使用することにより、ヘルス・テスト・フレームワークに対するテスト・ランのレポートを生成できます。HTMLまたはXMLレポートを生成できます。

ラン名、ランIDまたは実行IDを指定できます。

たとえば、ランIDが1330128064268のランに対するレポートをHTML形式で生成するには、次のように指定します。

dfwhealthtestctl.sh report runid=1330128064268 format=HTML

第VI部

拡張管理

この部では、Oracle Fusion Middlewareの再構成を伴う、メタデータ・リポジトリの管理、ネットワーク構成の変更などの高度な管理タスクについて説明します。

第VI部は、次の章で構成されています。

- 第14章「メタデータ・リポジトリの管理」

- 第15章「ネットワーク構成の変更」

14 メタデータ・リポジトリの管理

多くのOracle Fusion Middlewareコンポーネントでは、メタデータ・リポジトリを使用してアプリケーションのコンポーネントおよびメタデータの構成情報を保持しています。この章では、Oracle Fusion Middlewareで使用するメタデータ・リポジトリの管理について説明します。

内容は次のとおりです。

- メタデータ・リポジトリの理解

- データベース・ベース・メタデータ・リポジトリの作成

- MDSリポジトリの管理

- メタデータ・リポジトリ・スキーマの管理

- データのパージ

14.1 メタデータ・リポジトリの理解

メタデータ・リポジトリには、Oracle Application Development FrameworkなどのOracle Fusion Middlewareコンポーネントのメタデータが含まれています。また、Oracle Fusion Middlewareの構成に関するメタデータおよびアプリケーションのメタデータも格納できます。

Oracle Fusion Middlewareでは、複数のリポジトリ・タイプがサポートされています。リポジトリ・タイプは、特定のOracle Fusion Middlewareコンポーネント(Oracle Application Development Frameworkなど)に属する特定のスキーマまたはスキーマ・セットを表します。Oracle Fusion Middlewareでは、エディションベースの再定義(EBR)がサポートされており、エディションベースの再定義を使用すると、アプリケーションの使用中にそのデータベース・コンポーネントをアップグレードでき、停止時間を最小化あるいは排除することができます。リポジトリのスキーマは、EBR対応スキーマであることがあります。

特殊なタイプのリポジトリであるOracle Metadata Services (MDS)リポジトリには、特定タイプのデプロイ済アプリケーションのメタデータが格納されます。これには、ユーザーの組織で独自に開発されたカスタムのJava EEアプリケーションや、一部のOracle Fusion Middlewareコンポーネント・アプリケーションが含まれます。MDSリポジトリ・タイプに固有の関連情報については、第14.3項を参照してください。

MDSには、データベース・ベースおよびファイルベースのリポジトリを作成できます。本番環境では、データベース・ベース・リポジトリを使用します。一部のコンポーネントではスキーマがデータベースにインストールされている必要があるため、データベース・ベース・リポジトリを使用する必要があります。MDSでは、エディションベースの再定義(EBR)対応のスキーマがサポートされています。

注意:
メタデータ・リポジトリのデータベースがOracle Fusion Middlewareインストールで使用された後、データベース、サービス名またはSIDは変更できません。

14.2 データベース・ベース・メタデータ・リポジトリの作成

Oracle Fusion Middleware Repository作成ユーティリティ(RCU)を使用して、既存のデータベースにメタデータ・リポジトリを作成します。RCUを使用すると、MDSリポジトリや、特定コンポーネントのメタデータのリポジトリを作成できます。RCUはコンポーネントに必要なスキーマを作成します。スキーマのリストおよびその表領域とデータファイルについては、『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

RCUでは、コンポーネントのスキーマを削除することもできます。

サポートされているデータベースとサポートされているバージョンの詳細、およびMDSリポジトリでのこれらのデータベースの使用の詳細は、Oracle Fusion Middlewareのシステム要件と仕様のMDSスキーマ用にサポートされているデータベースに関する項を参照してください。

注意:
ネットワーク待機時間を短縮するには、すべてのメタデータ・リポジトリを同一サイトのデータベースにコンポーネントとして配置することをお薦めします。

MDSリポジトリの管理については、第14.3項を参照してください。

RCUを使用したデータベース・ベースのメタデータ・リポジトリの作成方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

14.3 MDSリポジトリの管理

Oracle Metadata Services (MDS)リポジトリには、特定タイプのデプロイ済アプリケーションのメタデータが格納されます。このデプロイ済アプリケーションには、ユーザーの組織で独自に開発されたカスタムのJava EEアプリケーションや、Oracle B2B、Oracle Web Services Managerなど、一部のOracle Fusion Middlewareコンポーネント・アプリケーションがあります。アプリケーションのメタデータを格納するMDSリポジトリにメタデータのコンテンツをデプロイする際には、選択したメタデータの圧縮アーカイブであるメタデータ・アーカイブ(MAR)が使用されます。

次の状況では、アプリケーションをMDSにデプロイして、デプロイ後のメタデータの管理を可能にする必要があります。

- MARの形式でパッケージ化され、シードされたメタデータがアプリケーションに組み込まれている場合

- 実行時にユーザーのパーソナライズを有効にする必要がある場合

- SOAコンポジットアプリケーション(SCA)がある場合

次の各項では、MDSリポジトリについて説明します。

- MDSリポジトリの理解

- データベース・ベースのMDSリポジトリの登録および登録解除

- ファイルベースのMDSリポジトリの登録および登録解除

- システム・データ・ソースの変更

- システムMBeanを使用したMDSリポジトリの管理

- MDSリポジトリに関する情報の表示

- アプリケーションでの別のMDSリポジトリまたはパーティションの使用の構成

- ソース・システムからターゲット・システムへのメタデータの移動

- ファイルベース・リポジトリからデータベース・ベース・リポジトリへの移動

- リポジトリからのメタデータ・パーティションの削除

- メタデータ・バージョン履歴のパージ

- MDSリポジトリでのメタデータ・ラベルの管理

関連項目:
Oracle Real Application Cluster (Oracle RAC)でMDSリポジトリを使用する方法の詳細は、『高可用性ガイド』を参照してください。

14.3.1 MDSリポジトリの理解

MDSフレームワークを使用すると、カスタマイズ可能なアプリケーションを作成できます。カスタマイズ済アプリケーションは、ベース・アプリケーション(ベース・ドキュメント)と、カスタマイズを含む1つ以上のレイヤーで構成されます。MDSは、カスタマイズをメタデータ・リポジトリに格納します。実行時にはこのカスタマイズを取得してベース・メタデータにマージし、カスタマイズ済アプリケーションを公開します。カスタマイズはベースから個別に保存されているので、カスタマイズは安全にアップグレードでき、ベースへの新しいパッチはカスタマイズを分割せずに適用できます。カスタマイズ済アプリケーションが起動されると、カスタマイズの内容がベース・アプリケーションに適用されます。

カスタマイズ可能なアプリケーションでは、複数のカスタマイズ・レイヤーを使用できます。カスタマイズ・レイヤーには、業種やサイトなどがあります。各レイヤーで複数のカスタマイズ・レイヤー値を使用できますが、実行時には、通常そのようなレイヤー値は各レイヤーから1つのみ適用されます。たとえば、カスタマイズ可能なアプリケーションの業種レイヤーには、医療や金融などの業種の値を格納できます。一方、デプロイ対象のカスタマイズ済アプリケーションで一度に使用されるのは、このレイヤー値のいずれか一つのみです。ベース・ドキュメントおよびカスタマイズ・レイヤーの詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のMDSを使用したアプリケーションのカスタマイズに関する項を参照してください。

MDSリポジトリはファイル・ベースまたはデータベース・ベースのいずれかです。本番環境では、データベース・ベース・リポジトリを使用します。1つのドメイン内に複数のMDSリポジトリを作成できます。

データベース・ベースのMDSリポジトリには、次の機能があり、これらはファイルベースのMDSリポジトリではサポートされません。

- 効率的な問合せ機能: データベース・ベースのMDSリポジトリは、セットベースの問合せ用に最適化されています。このため、データベース・リポジトリの検索などのパフォーマンスに優れています。
MDSリポジトリの問合せAPIには、問合せ操作を定義し、メタデータ・オブジェクトに対する条件を指定する構成メンバーがあります。これらの条件は、検索結果を特定の属性のタイプと値のセット、コンポーネント・タイプ、テキスト・コンテンツおよびメタデータ・パスに限定する一連の基準です。このAPIでは、複数の条件を組み合せ、ORおよびAND構成メンバーを使用することによって、動的な再帰的合成を実現できます。

- アトミックなトランザクション・セマンティック: データベース・ベースのMDSリポジトリは、データベース・トランザクション・セマンティックを使用し、トランザクションの失敗(インポートやデプロイの失敗など)をロールバックする機能があります。

- バージョニング: MDSリポジトリでは、ドキュメントのバージョンがデータベース・ベース・リポジトリで保持されます。バージョニングを使用すると、メタデータ・オブジェクトに対する変更は、メタデータ・リポジトリの既存データを単に上書きするのではなく、別のバージョンとして保存されます。バージョンのラベル付けだけではなくバージョン履歴の機能もあるため、特定時点におけるメタデータのセットを取得できます。

- メタデータの変更の分離: データベース・ベースのMDSリポジトリでは、実行環境でメタデータの変更を分離して、すべてのユーザーに渡す前に一部のユーザー・グループでテストできます。

- ポーリングに基づいた外部変更検出のサポート: あるアプリケーションで行った共有メタデータに対する変更を別のアプリケーションで検出できます。たとえば、クラスタ内の管理対象サーバーAおよびBにアプリケーションをデプロイし、管理対象サーバーAにデプロイされたアプリケーションのカスタマイズを変更した場合、そのデータはデータベース・ベース・リポジトリに書き込まれます。管理対象サーバーBにデプロイされたアプリケーションでは、更新されたカスタマイズが使用されます。これにより、高可用性がサポートされます(特に、アクティブ/アクティブ・シナリオの場合。)

- 更新のクラスタ化: データベース・ベースのMDSリポジトリでは、複数のホストからメタデータを更新できます。ファイルベースのMDSリポジトリでは、更新できるのは一度に1つのホストからのみです。

共有メタデータ・リポジトリを構成すると、複数のアプリケーションでメタデータを共有できます。メタデータを共有すると、アプリケーションの外部変更検出を構成することにより、あるアプリケーションがこのリポジトリのメタデータに対して行った変更を、共有リポジトリを使用している別のアプリケーションで確認できます。

MDSリポジトリでは、Oracle Fusion Middlewareコンポーネントなどのアプリケーションは、それぞれ専用のパーティションにデプロイされます。パーティションは、データベース・ベースかファイルベースかとは関係なく、物理MDSリポジトリ内で独立した論理リポジトリです。

アプリケーションをデプロイして、MDSリポジトリに関連付ける方法は、第10章を参照してください。

MDSリポジトリへのパッチ適用に関しては、次の点に注意してください。

- パッチを適用する前に、MDSリポジトリをドメインに登録する必要があります。そうしないと適用したパッチがロールバックできず、追加のパッチを適用できません。

- パッチの適用対象は次のとおりです。

- MDSのメタデータ

- MDSのjarファイル

- MDSの共有ライブラリ

- データベース・ベースのメタデータ・リポジトリ内のMDSスキーマ。パッチには、新たな列の追加や列のサイズの拡大など、付加的な変更が含まれる場合があります。このタイプのパッチは、ロールバックできません。

- データベース・ベースのメタデータ・リポジトリ内のMDSデータベースPL/SQL。パッチには、PL/SQLパッケージの変更や、新たなPL/SQLパッケージおよび手順が含まれる場合があります。

- 対応するMDS JARファイル・パッチを必要とする、データベース・ベースのメタデータ・リポジトリ内のMDSスキーマまたはPL/SQL

14.3.1.1 MDSでサポートされるデータベース

MDSリポジトリでは、Oracleデータベースだけではなく、SQL Server、DB2、MySQLなど、Oracle以外のデータベースもサポートされます。

サポートされているデータベースとサポートされているバージョンの詳細、およびMDSリポジトリでのこれらのデータベースの使用の詳細は、Oracle Fusion Middlewareのシステム要件と仕様のMDSスキーマ用にサポートされているデータベースに関する項を参照してください。

14.3.1.2 MDS操作の理解

Fusion Middleware ControlまたはWLSTコマンドを使用して、MDSリポジトリのほとんどの操作を実行できます。ただし、Fusion Middleware Controlのカスタム・ユーザー・インタフェースまたはWLSTコマンドが使用できない一部の操作では、システムMBeanを使用する必要があります。

次の各項では、システムMBeanのみがサポートされている場合を除き、Fusion Middleware ControlとWLSTコマンドを使用して、操作を実行する方法を説明します。システムMBeanのみがサポートされている場合、その項ではシステムMBeanを使用して操作を実行する方法を説明します。

パーティション、各パーティションにデプロイされたアプリケーションなど、リポジトリの詳細を表示できます。また、パーティションに対して、パージ、削除、メタデータのインポートやエクスポートなどの操作も実行できます。

後続の各項目で説明するMDS操作を使用する場合は次の点に注意してください。

- エクスポート操作では、MDSリポジトリ・パーティションからファイル・システムのディレクトリまたはアーカイブに、メタデータ・ドキュメントのバージョニング済のストライプ(最先端バージョンか、ラベルに基づくもの)がエクスポートされます。ディレクトリにエクスポートする場合、このディレクトリは、アプリケーションを実行しているホストからアクセス可能である必要があります。アーカイブにエクスポートする場合、このアーカイブは、コマンドを実行するシステム上に配置できます。
メタデータのバージョニングはファイルベース・リポジトリではサポートされないため、ファイルベース・リポジトリからは、最先端バージョン(唯一のバージョンでもあります)がエクスポートされます。

- インポート操作では、ファイル・システム・ディレクトリまたはアーカイブからMDSリポジトリ・パーティションにメタデータ・ドキュメントがインポートされます。ディレクトリにエクスポートした場合、このディレクトリは、アプリケーションを実行しているホストからアクセス可能である必要があります。アーカイブにエクスポートした場合、このアーカイブは、コマンドを実行するシステム上に配置できます。
ターゲット・リポジトリがデータベース・ベース・リポジトリの場合、メタデータ・ドキュメントは新しい最先端バージョンとしてインポートされます。ターゲット・リポジトリがファイルベース・リポジトリの場合、メタデータ・ドキュメントは上書きされます。

注意:

- カスタムWLST MDSコマンドの詳細は、『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のメタデータ・サービス(MDS)のカスタムWLSTコマンドに関する項を参照してください。

表14-1は、各操作に必要な論理ロールを示しています。ロールは、その操作の実行にWLSTコマンド、Fusion Middleware Control、およびMBeanのどれを使用する場合でも適用されます。

表14-1 MDSの操作と必要なロール

操作

論理ロール

キャッシュのクリア

アプリケーションのオペレータ・ロール

メタデータ・パーティションのクローニング

ドメインのAdminロール

メタデータ・ラベルの作成

アプリケーションのAdminロール

メタデータ・パーティションの作成

ドメインのAdminロール

メタデータの削除

アプリケーションのAdminロール

メタデータ・ラベルの削除

アプリケーションのAdminロール

メタデータ・パーティションの削除

ドメインのAdminロール

メタデータ・データベース・リポジトリの登録解除

ドメインのAdminロール

メタデータ・ファイル・リポジトリの登録解除

ドメインのAdminロール

サンドボックスの破棄

アプリケーションのAdminロール

メタデータのエクスポート

アプリケーションのMonitorロール

サンドボックス・メタデータのエクスポート

アプリケーションのMonitorロール

MARのインポート

アプリケーションのAdminロール

メタデータのインポート

アプリケーションのAdminロール

サンドボックス・メタデータのインポート

アプリケーションのAdminロール

メタデータ・ラベルの一覧表示

アプリケーションのMonitorロール

サンドボックスのリスト

アプリケーションのMonitorロール

メタデータ・ラベルの昇格

アプリケーションのAdminロール

メタデータのパージ

アプリケーションのAdminロール

メタデータ・ラベルのパージ

アプリケーションのAdminロール

メタデータ・データベース・リポジトリの登録

ドメインのAdminロール

メタデータ・ファイル・リポジトリの登録

ドメインのAdminロール

これらのロールをWebLogic Serverロールにマップする方法の詳細は『Oracle Platform Security Servicesによるアプリケーションの保護』の論理ロールのWebLogicロールへのマッピングに関する項を参照してください。

14.3.2 データベース・ベースのMDSリポジトリの登録および登録解除

次の各項では、データベース・ベースのMDSリポジトリを登録および登録解除する方法を説明します。

- Fusion Middleware Controlを使用したデータベース・ベースのMDSリポジトリの登録

- MDSリポジトリをターゲットとする追加サーバーの設定

- メタデータ・リポジトリをターゲットとするサーバーの削除

- データベース・ベースのMDSリポジトリの登録解除

注意:
次のWLSTコマンドまたは同等のMBeanをスクリプトで起動する場合は、次の点に気を付けてください。

- registerMetadataDBRepository

- deregisterMetadataDBRepository

今回のリリースおよびこれまでのリリースで、これらのコマンドやMBeanは次のような動作をします。

1. Oracle WebLogic Server編集セッションを開始します。

2. リポジトリを登録または登録解除します。

3. 変更をアクティブ化します。

ただし、編集セッションは明示的に開始できます。そうした場合、変更の自動アクティブ化は非推奨です。

14.3.2.1 データベース・ベースのMDSリポジトリの登録

アプリケーションをMDSリポジトリにデプロイする前に、Oracle WebLogic Serverドメインにリポジトリを登録する必要があります。次の各項で説明するように、Fusion Middleware ControlまたはWLSTを使用して、データベース・ベースのMDSリポジトリを登録できます。

- Fusion Middleware Controlを使用したデータベース・ベースのMDSリポジトリの登録

- WLSTを使用したデータベース・ベースのMDSリポジトリの登録

14.3.2.1.1 Fusion Middleware Controlを使用したデータベース・ベースのMDSリポジトリの登録

第14.2項の説明に従って、RCUを使用してデータベース・ベースのMDSリポジトリを作成します。

Fusion Middleware Controlを使用してデータベース・ベースのMDSリポジトリを登録する手順は次のとおりです。

1. 「WebLogicドメイン」メニューから「その他のサービス」、「メタデータ・リポジトリ」を選択します。
次の図のように、「メタデータ・リポジトリ」ページが表示されます。

2. 「データベース・ベース・リポジトリ」セクションで、「登録」をクリックします。
「データベース・ベースのメタデータ・リポジトリの登録」ページが表示されます。

3. 「データベース接続」セクションに、次の情報を入力します。

- 「データベース・タイプ」で、データベースのタイプを選択します。

- 「ホスト名」に、ホストの名前を入力します。

- 「ポート」に、データベースのポート番号を入力します(例: 1521)。

- 「サービス名」に、データベースのサービス名を入力します。データベースのデフォルトのサービス名は、グローバル・データベース名です。これはorclなどのデータベース名とドメイン名で構成されます。この例のサービス名はorcl.domain_name.comになります。

- 「ユーザー名」に、SYSなどの、SYSDBAロールが割り当てられたデータベース・ユーザー名を入力します。

- 「パスワード」に、このユーザーのパスワードを入力します。

- 「ロール」で、SYSDBAなどのデータベース・ロールを選択します。

4. 「問合せ」をクリックします。
次の図のように、データベース内にメタデータ・リポジトリがある表が表示されます。

5. リポジトリを選択して、ページの下部で次の情報を入力します。

- 「リポジトリ名」に名前を入力します。

- 「スキーマ・パスワード」に、スキーマ作成時に指定したパスワードを入力します。

6. 「OK」をクリックします。
リポジトリは、Oracle WebLogic Serverドメインに登録され、管理サーバーに対してターゲット設定されます。リポジトリのターゲット設定を他のサーバーにする方法は、第14.3.2.2項を参照してください。

また、mds-repository_nameという名前のシステム・データ・ソースが作成されます。このデータ・ソースに対するグローバル・トランザクション・サポートは無効になっています。

14.3.2.1.2 WLSTを使用したデータベース・ベースのMDSリポジトリの登録

コマンド行を使用してデータベース・ベースのMDSリポジトリを登録するには、WLSTのregisterMetadataDBRepositoryコマンドを使用します。たとえば、MDSリポジトリmds-repos1を登録するには、次のコマンドを使用します。

registerMetadataDBRepository(name='mds-repos1', dbVendor='ORACLE',
host='hostname', port='1521', dbName='ora11',
user='username', password='password', targetServers='server1')

14.3.2.2 MDSリポジトリをターゲットとする追加サーバーの設定

Fusion Middleware Controlを使用してMDSリポジトリを登録すると、リポジトリは管理サーバーに対してターゲット指定されます。リポジトリを追加サーバーにターゲット設定できます。

MDSリポジトリを追加のサーバーにターゲット設定するには:

1. ナビゲーション・ペインで「メタデータ・リポジトリ」を展開します。

2. リポジトリを選択します。
次の図のようにリポジトリのホーム・ページが表示されます。

3. 「ターゲット・サーバー」セクションで、「追加」をクリックします。
「リポジトリをターゲット設定します」ダイアログ・ボックスが表示されます。

4. サーバーまたはクラスタを選択して、「ターゲット」をクリックします。
クラスタを開いて、クラスタ内のサーバーを表示できます。ただし、クラスタを選択した場合、リポジトリはクラスタ内のすべてのサーバーにターゲット設定されます。

5. 操作が完了したら、「閉じる」をクリックします。
サーバーが「ターゲット・サーバー」セクションにリストされます。

14.3.2.3 メタデータ・リポジトリをターゲットとするサーバーの削除

リポジトリのターゲット設定からサーバーを削除するには:

1. ナビゲーション・ペインで「メタデータ・リポジトリ」を展開します。

2. リポジトリを選択します。
リポジトリのホーム・ページが表示されます。

3. 「ターゲット・サーバー」セクションで、ターゲット・サーバーを選択し、「削除」をクリックします。
「リポジトリをターゲット設定解除します」ダイアログ・ボックスが表示されます。

4. サーバーまたはクラスタを選択して、「ターゲット設定解除」をクリックします。
クラスタを開いて、クラスタ内のサーバーを表示できます。ただし、クラスタを選択した場合、リポジトリはクラスタ内のすべてのサーバーのターゲット設定から削除されます。

5. 操作が完了したら、「閉じる」をクリックします。

14.3.2.4 データベース・ベースのMDSリポジトリの登録解除

登録解除をしても、リポジトリに格納されているデータが失われることはありません。ただし、登録解除されたリポジトリを使用しているアプリケーションはすべて、リポジトリの登録解除後に機能しなくなります。リポジトリの登録解除前には、必ずそのリポジトリを使用しているアプリケーションがないことを確認してください。

次の各項で説明するように、Fusion Middleware ControlまたはWLSTを使用して、データベース・ベースのMDSリポジトリを登録解除できます。

- Fusion Middleware Controlを使用したデータベース・ベースのMDSリポジトリの登録解除

- WLSTを使用したデータベース・ベースのMDSリポジトリの登録解除

14.3.2.4.1 Fusion Middleware Controlを使用したデータベース・ベースのMDSリポジトリの登録解除

Fusion Middleware Controlを使用してMDSリポジトリの登録を解除する手順は次のとおりです。

1. 「WebLogicドメイン」メニューから「その他のサービス」、「メタデータ・リポジトリ」を選択します。
「メタデータ・リポジトリ」ページが表示されます。

また、メタデータ・リポジトリのホーム・ページの「メタデータ・リポジトリ」メニューから、「管理」→「登録/登録解除」を選択して、「メタデータ・リポジトリの登録」ページにナビゲートすることもできます。

2. 表からリポジトリを選択します。

3. 「登録解除」を選択します。

4. 「確認」ダイアログ・ボックスで、「はい」をクリックします。

14.3.2.4.2 WLSTを使用したデータベース・ベースのMDSリポジトリの登録解除

コマンド行を使用してデータベース・ベースのMDSリポジトリの登録を解除するには、WLSTのderegisterMetadataDBRepositoryコマンドを使用します。たとえば、MDSリポジトリmds-repos1を登録解除するには、次のコマンドを使用します。

deregisterMetadataDBRepository(name='mds-repos1')

14.3.3 ファイルベースのMDSリポジトリの登録および登録解除

次の各項目では、ファイルベース・メタデータ・リポジトリの作成、登録および登録解除の方法について説明します。

- ファイルベースのMDSリポジトリの作成および登録

- ファイルベースのMDSリポジトリの登録解除

注意:
スクリプトで次のMBeanを起動する場合は、次のことに気を付けてください。

- registerMetadataFileRepository

- deregisterMetadataFileRepository

今回のリリースおよびこれまでのリリースで、これらのMBeanは次のような動作をします。

1. Oracle WebLogic Server編集セッションを開始します。

2. リポジトリを登録または登録解除します。

3. 変更をアクティブ化します。

ただし、編集セッションは明示的に開始できます。そうした場合、変更の自動アクティブ化は非推奨です。

14.3.3.1 ファイルベースのMDSリポジトリの作成および登録

Fusion Middleware Controlを使用して、ファイルベースMDSリポジトリを作成し、Oracle WebLogic Serverドメインに登録できます。

Fusion Middleware Controlを使用して、ファイルベース・リポジトリを作成および登録する手順は次のとおりです。

1. 「WebLogicドメイン」メニューから「その他のサービス」、「メタデータ・リポジトリ」を選択します。
「メタデータ・リポジトリ」ページが表示されます。

2. 「ファイルベース・リポジトリ」セクションで、「登録」をクリックします。
「メタデータ・リポジトリの登録」ページが表示されます。

3. 次の情報を入力します。

- 「名前」に名前を入力します。たとえば、repos1と入力します。名前に接頭辞mds-が追加され、mds-repos1という名前のリポジトリが登録されます。mds-で始まる名前を入力した場合は、指定した名前のリポジトリが登録されます。

- 「ディレクトリ」で、ディレクトリを指定します。このリポジトリを使用するアプリケーションが実行される管理サーバーと管理対象サーバーには、このディレクトリに対する書込み権限が必要です。
次の点に注意してください。

- 絶対パスが指定されていない場合、ディレクトリはDOMAIN_HOMEディレクトリの下に作成されます。

- 指定したパスがファイル・システム上に存在する場合は、メタデータ・ファイル・リポジトリが登録されます。このパスの下にあるすべてのサブディレクトリは、このファイルベース・リポジトリのパーティションとして自動的にロードされます。

- 指定したパスが存在しない場合は、登録中にこの名前のディレクトリがファイル・システム上に作成されます。まだパーティションが作成されていないため、ロードされるサブディレクトリはありません。

- 指定したパスが無効またはなんらかの理由(権限が拒否されるなど)で作成できない場合は、エラーが表示され、登録は失敗します。

- 指定したパスがディレクトリではなくファイルとして存在する場合は、エラーは表示されず、登録は成功します。

4. 「OK」をクリックします。

リポジトリが作成および登録され、 「メタデータ・リポジトリ」ページに表示されます。

これでパーティションの作成と削除ができるようになりました。これらの変更は、ファイル・システム上のディレクトリに反映されます。

ファイルベース・リポジトリは、システムMBeanを使用して作成することもできます。システムMBeanブラウザの使用方法の詳細は、第14.3.5項を参照してください。

14.3.3.2 ファイルベースのMDSリポジトリの登録解除

Fusion Middleware Controlを使用して、ファイルベースMDSリポジトリの登録を解除できます。

Fusion Middleware Controlを使用してファイルベース・リポジトリの登録を解除する手順は次のとおりです。

1. 「WebLogicドメイン」メニューから「その他のサービス」、「メタデータ・リポジトリ」を選択します。
「メタデータ・リポジトリ」ページが表示されます。

2. 「ファイルベース・リポジトリ」セクションで、リポジトリを選択し「登録解除」をクリックします。

3. 「確認」ダイアログ・ボックスで「OK」をクリックします。
ファイルベース・リポジトリが有効の場合は、リポジトリ・リストから削除されます。そうでない場合は、エラーが表示されます。

ファイルベース・リポジトリは、システムMBeanを使用して登録解除することもできます。システムMBeanブラウザの使用方法の詳細は、第14.3.5項を参照してください。

14.3.4 システム・データ・ソースの変更

アプリケーションを新しいリポジトリに再関連付けするように、システム・データ・ソースを変更できます。データ・ソースを含むデータベースまたはスキーマを変更できます。これを行うために、Oracle WebLogic Server管理コンソールまたはFusion Middleware Controlを使用できます。Fusion Middleware Controlを使用するには、次の手順を実行します。

1. 「WebLogicドメイン」メニューで「JDBCデータ・ソース」を選択します。
「JDBCデータ・ソース」ページが表示されます。

2. 変更するデータ・ソースを選択します。
選択したデータ・ソースの「JDBCデータ・ソース」ページが表示されます。

3. 「接続プール」タブを選択します。

4. データベースを変更するには、「データベースURL」フィールドを変更します。次に例を示します。

jdbc:oracle:thin:@hostname.domainname.com:1522/orcl

5. 「パスワード」で、データベースのパスワードを入力します。

6. スキーマを変更するには、「プロパティ」セクションを変更し、「ユーザー」の値を変更します。

7. データベースがDB2データベースの場合、プロパティsendStreamAsBlobを値をtrueにして追加します。

8. 「適用」をクリックします。

9. このデータ・ソースを使用するサーバーを再起動します。

14.3.5 システムMBeanを使用したMDSリポジトリの管理

この章のほとんどの手順は、Fusion Middleware ControlまたはWLSTを使用してMDSリポジトリを管理する方法を説明していますが、システムMBeanも使用できます。

1. 「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

2. このページのナビゲーション・ペインで、「アプリケーション定義のMBean」→「oracle.mds.lcm」を開きます。ドメインを開いてから「MDSDomainRuntime」を開き、「MDSDomainRuntime」を選択します。

3. 「アプリケーション定義のMBean」ペインで、「操作」タブを選択します。

4. registerMetadataFileRepositoryなど「操作」の1つをクリックします。
「操作」ページが表示されます。

5. 「値」列で、操作の値を入力します。

6. 「起動」をクリックします。

14.3.6 MDSリポジトリに関する情報の表示

次の各項で説明するように、Fusion Middleware ControlまたはシステムMBeanを使用して、MDSリポジトリに関する情報を表示できます。

- Fusion Middleware Controlを使用したMDSリポジトリに関する情報の表示

- システムMBeanを使用したMDSリポジトリに関する情報の表示

14.3.6.1 Fusion Middleware Controlを使用したMDSリポジトリに関する情報の表示

Fusion Middleware Controlを使用してMDSリポジトリに関する情報を表示するには:

1. ナビゲーション・ペインで「メタデータ・リポジトリ」を展開します。

2. リポジトリを選択します。
次の図は、MDSリポジトリのホーム・ページを示しています。

3. どのアプリケーションがリポジトリを使用しているかを表示するには、「アプリケーション」列のアイコンをクリックします。「パーティションを使用するアプリケーション」ダイアログ・ボックスが、「デプロイ済アプリケーション」タブおよび「参照元アプリケーション」タブとともに表示されます。

- 「デプロイ済アプリケーション」タブに、メタデータがリポジトリ・パーティションにデプロイされたアプリケーションのリストが表示されます。

- 「参照元アプリケーション」タブに、リポジトリ・パーティションに格納されているメタデータを参照するアプリケーションのリストが表示されます。

このページでは、次の操作も実行できます。

- 第14.3.10.1項で説明するように、パーティションを削除します。

- 第14.3.12.6項で説明するように、ラベルを削除します。

- 第14.3.2.2項で説明するように、ターゲット・サーバーを追加または削除します。

14.3.6.2 システムMBeanを使用したMDSリポジトリに関する情報の表示

システムMBeanのlistPartitions、listRepositories、およびlistRepositoryDetailsの各操作を使用すると、リポジトリ内のパーティションの一覧、リポジトリの一覧、ドメインに登録されているリポジトリの詳細を取得できます。

1. 「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

2. このページのナビゲーション・ペインで、「アプリケーション定義のMBean」→「oracle.mds.lcm」を開きます。ドメインを開いてから「MDSDomainRuntime」を開き、「MDSDomainRuntime」を選択します。

3. 「アプリケーション定義のMBean」ペインで、「操作」タブを選択します。

4. listPartitions、listRepositories、listRepositoryDetailsなど「操作」の1つをクリックします。
「操作」ページが表示されます。

5. 「起動」をクリックします。
「戻り値」表に情報が表示されます。

アプリケーションのMDS構成属性を変更する方法の詳細は、第10.9項を参照してください。

14.3.7 アプリケーションでの別のMDSリポジトリまたはパーティションの使用の構成

アプリケーションはデプロイ時にMDSリポジトリに関連付けできます。その後、WLSTまたはFusion Middleware Controlを使用して、アプリケーションが関連付けられているMDSリポジトリまたはパーティションを変更できます。たとえば、特定のアプリケーションに使用する必要がある別のメタデータが、異なるリポジトリに格納されている場合などです。

アプリケーションを新しいMDSリポジトリまたはパーティションに関連付けるには、次のいずれかを実行します。

- 新しいリポジトリまたはパーティションを指定して、アプリケーションを再デプロイします。
新しいパーティションを作成するには、次のいずれかを実行します。

- パーティションを別のリポジトリにクローニングします。パーティションのクローニングは、タイプとバージョンが同じであるデータベースのデータベース・ベース・リポジトリでのみ有効です。パーティションをクローニングするときは、すべてのカスタマイズおよびラベルも含めて、メタデータのバージョン履歴を保持します。
パーティションのクローニング方法、およびクローニングしたパーティションを指定してアプリケーションを再デプロイする方法は、第14.3.7.1項で説明します。

- 新しいパーティションを作成し、次に現在のパーティションからメタデータをエクスポートして、新しいパーティションにこのメタデータをインポートします。
パーティションの作成方法、データのエクスポートおよびインポート方法、およびアプリケーションを再デプロイして新しいリポジトリまたはパーティションを指定する方法は、第14.3.7.2項で説明します。

- システム・データ・ソースを変更します。システム・データ・ソースを変更すると、そのデータ・ソースが格納されるデータベースまたはスキーマを変更できます。
システム・データ・ソースの変更方法は、第14.3.4項で説明します。

14.3.7.1 パーティションのクローニング

システムMBeanのcloneMetadataPartitionを使用すると、同じリポジトリまたは別のリポジトリにパーティションをクローニングできます。元のリポジトリもターゲット・リポジトリも、データベース・ベース・リポジトリを使用する必要があります。

パーティションをクローニングして、新しいリポジトリまたは同じリポジトリにアプリケーションを再デプロイするには:

1. システムMBeanのcloneMetadataPartition操作を使用して、パーティションをクローニングします。次の例では、partition1を元のリポジトリから新しいリポジトリにクローニングします。

1. Fusion Middleware Controlのナビゲーション・ペインから、アプリケーションがデプロイされている管理対象サーバーにナビゲートします。「WebLogicサーバー」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

2. 「システムMBeanブラウザ」のナビゲーション・ペインで、「アプリケーション定義のMBean」→「oracle.mds.lcm」を開きます。ドメインを開いてから「MDSDomainRuntime.」を開きます。「MDSDomainRuntime」を選択します。

3. 「アプリケーション定義のMBean」ペインで、「操作」タブを選択します。
次の図では、「システムMBeanブラウザ」に「アプリケーション定義のMBeans」ペインが表示されています。

4. 「cloneMetadataPartiton」を選択します。
「操作: cloneMetadataPartiton」ページが表示されます。

5. 「パラメータ」の表に次の値を入力します。

- 「fromRepository」に、メタデータ・ドキュメントのクローニング元のメタデータ・パーティションが格納されているメタデータ・リポジトリの名前を入力します。

- 「fromPartition」に、メタデータ・ドキュメントのクローニング元のパーティションの名前を入力します。

- 「toRepository」に、ソース・リポジトリ・パーティションのドキュメントのクローニング先とするメタデータ・リポジトリの名前を入力します。

- 「toPartition」に、ターゲット・パーティションとして使用するメタデータ・リポジトリ・パーティションの名前を入力します。この名前はリポジトリ内で一意にする必要があります。このパラメータに値を指定しない場合、ソース・パーティションの名前がターゲット・パーティションに使用されます。
「toRepository」の名前が元のリポジトリと同じ場合は、パーティション名を入力する必要があります。この名前はリポジトリ内で一意である必要があります。

6. 「起動」をクリックします。

7. ナビゲーション・ペインでリポジトリを選択して、パーティションが作成されていることを確認します。このパーティションは「メタデータ・リポジトリ」ホーム・ページの「パーティション」表に記載されています。

2. 第10.4.3項または第10.5.3項の説明に従って、アプリケーションのタイプに応じてアプリケーションを再デプロイします。この操作の際には、「アプリケーション属性」ページで新しいパーティションおよびリポジトリを指定します。

1. リポジトリを変更するには、「リポジトリ名」の横にあるアイコンをクリックします。「メタデータ・リポジトリ」ダイアログ・ボックスでリポジトリを選択し、「OK」をクリックします。

2. パーティションを変更するには、「パーティション名」にパーティション名を入力します。

14.3.7.2 新しいパーティションの作成とアプリケーションの再関連付け

アプリケーションを再デプロイして、新しいパーティションを指定することで、同じリポジトリまたは別のリポジトリに新しいパーティションを作成できます。続いて、WLSTを使用して、メタデータを新しいパーティションに転送します。

この手順を使用すると、タイプの異なる2つのリポジトリ間で(ファイルベースからデータベース・ベースへ、またはOracle Databaseから別のデータベースへ)メタデータを転送できます。

新しいパーティションを作成して、アプリケーションを再関連付けする手順は次のとおりです。

1. WLSTのexportMetadataコマンドを使用して、ソース・パーティションからファイル・システム上のディレクトリにメタデータをエクスポートします。

exportMetadata(application='sampleApp', server='server1',
toLocation='/tmp/myrepos/mypartition', docs='/**')

2. 第10.4.3項または第10.5.3項の説明に従って、アプリケーションのタイプに応じてアプリケーションを再デプロイします。この操作の際には、「アプリケーション属性」ページで新しいパーティションおよびリポジトリを指定します。

1. リポジトリを変更するには、「リポジトリ名」の横にあるアイコンをクリックします。「メタデータ・リポジトリ」ダイアログ・ボックスでリポジトリを選択し、「OK」をクリックします。

2. パーティションを変更するには、「パーティション名」にパーティション名を入力します。

3. WLSTのimportMetadataコマンドを使用して、ファイル・システムから新しいパーティションにメタデータをインポートします。

importMetadata(application='sampleApp', server='server1',
fromLocation='/tmp/myrepos/mypartiton', docs='/**')

4. また、第14.3.3.2項または第14.3.2.4項の説明に従って、元のリポジトリの登録を解除することもできます。

または、WLSTコマンドcreateMetadataPartitionを使用して、新しいパーティションを作成することもできます。パーティション名はリポジトリ内で一意にする必要があります。このパーティション・パラメータがない場合は、ソース・パーティションの名前がターゲット・パーティションに使用されます。次の例では、パーティションpartition1を作成します。

createMetadataPartition(repository='mds-repos1', partition='partition1')

14.3.8 ソース・システムからターゲット・システムへのメタデータの移動

MDSのメタデータは、別のドメインのパーティションに転送できます。例に示すように、テスト・システムから本番システムにアプリケーションを移行します。テスト・システムのドメインにデプロイされているテスト・アプリケーションと、本番システムのドメインにデプロイされている本番アプリケーションがあります。テスト・システムから本番システムにカスタマイズを転送します。これを実行するには、テスト・システムのパーティションから本番システムのパーティションにメタデータを転送します。

パーティション間でメタデータを転送するには、パーティションからメタデータをエクスポートして、別のパーティションにインポートします。次の各項で説明するように、メタデータの転送にはFusion Middleware ControlまたはWLSTを使用できます。

- Fusion Middleware Controlを使用したメタデータの転送

- WLSTを使用したメタデータの転送

14.3.8.1 Fusion Middleware Controlを使用したメタデータの転送

Fusion Middleware Controlを使用してメタデータを転送する手順は次のとおりです。

1. ナビゲーション・ペインで「アプリケーションのデプロイ」を展開し、アプリケーションを選択します。

2. 「アプリケーションのデプロイ」メニューで、「MDS構成」を選択します。
次の図のように「MDS構成」ページが表示されます。

3. 「エクスポート」セクションで、次のいずれかを選択します。

- 「このWebブラウザが稼働しているマシンにあるアーカイブにメタデータ・ドキュメントをエクスポートします。」
「エクスポート」をクリックします。

エクスポート操作では、zipファイルがエクスポートされます。オペレーティング・システムおよびブラウザに応じて、ファイルを保存するかまたはファイルを開くかを質問するダイアログ・ボックスが表示されます。

- 「このアプリケーションが稼働しているマシンにあるディレクトリまたはアーカイブにメタデータ・ドキュメントをエクスポートします。」
ディレクトリの場所またはメタデータをエクスポートできるアーカイブを入力します。

ドキュメントの転送先のターゲット・ディレクトリまたはアーカイブ・ファイル(.jar、.JAR、.zipまたは.ZIP)は、ソース・パーティションから選択されます。ディレクトリにエクスポートする場合、このディレクトリは、ローカル・ディレクトリまたはネットワーク・ディレクトリ、あるいはアプリケーションが物理的にデプロイされているファイルである必要があります。アーカイブにエクスポートする場合、このアーカイブをローカル・ディレクトリまたはネットワーク・ディレクトリ、あるいはアプリケーションが物理的にデプロイされるファイルにすることができます。または、コマンドを実行しているシステム上にすることもできます。

該当する場所がファイル・システム上に存在しない場合、.jar、.JAR、.zipまたは.ZIPで名前が終わるときにアーカイブ・ファイルが作成される場合を除いて、ディレクトリが作成されます。アーカイブ・ファイルがすでに存在する場合、exportMetadata操作によってファイルが上書きされます。

「エクスポート」をクリックします。次に「確認」ダイアログ・ボックスで、「閉じる」をクリックします。

「ベース・ドキュメントの除外」を選択すると、カスタマイズのみがエクスポートされ、ベース・ドキュメントはエクスポートされません。ベース・ドキュメントおよびカスタマイズについては、第14.3.1項を参照してください。

4. ターゲット・アプリケーションが別のシステムにある場合は、エクスポートされたメタデータをそのシステムにコピーします。

5. ターゲット・システムのナビゲーション・ペインで「アプリケーションのデプロイ」を開いてから、アプリケーションを選択します。

6. 「アプリケーションのデプロイ」メニューで、「MDS構成」を選択します。
「MDS構成」ページが表示されます。

7. 「インポート」セクションで、次のいずれかを選択します。

- 「このWebブラウザが稼働しているマシンにあるアーカイブからメタデータ・ドキュメントをインポートします。」

- 「このアプリケーションが稼働しているマシンにあるディレクトリまたはアーカイブからメタデータ・ドキュメントをインポートします。」

エクスポートされたメタデータが格納されているディレクトリまたはアーカイブの場所を入力します。ディレクトリを指定する場合は、パーティション名が付けられているサブディレクトリも含めます。このディレクトリまたはアーカイブは、ローカルまたはネットワークのディレクトリ、あるいはアプリケーションが物理的にデプロイされているファイルである必要があります。

8. 「インポート」をクリックします。

9. 「確認」ダイアログ・ボックスで「Close」をクリックします。

14.3.8.2 WLSTを使用したメタデータの転送

WLSTを使用してメタデータを転送する手順は次のとおりです。

1. exportMetadataコマンドを使用して、元のパーティションからメタデータをエクスポートします。

exportMetadata(application='sampleApp', server='server1',
toLocation='/tmp/myrepos/mypartition', docs='/**')

このコマンドでは、メタデータ・パーティションからファイル・システム・ディレクトリにメタデータ・ドキュメントのバージョニング済のストライプがエクスポートされます。adf-config.xmlのcust-config要素で宣言されたカスタマイズ・クラスのみがエクスポートされます。adf-config.xmlに宣言されたcust-config要素がない場合、すべてのカスタマイズ・クラスがエクスポートされます。

すべてのカスタマイズをエクスポートするには、オプションrestrictCustTo="%"を使用します。

2. 本番アプリケーションが別のシステムにある場合は、エクスポートされたメタデータをそのシステムにコピーします。

3. WLSTのimportMetadataコマンドを使用して、メタデータを別のパーティションにインポートします。

importMetadata(application='sampleApp', server='server1',
fromLocation='/tmp/myrepos/mypartiton', docs='/**')

fromLocationパラメータの値は、WLSTを実行しているシステムと同一システム上の場所にするか、またはマップ済のネットワーク・ドライブまたはディレクトリ・マウント上の場所にする必要があります。ネットワーク参照を直接使用することはできません(\\mymachine\repositories\など)。

adf-config.xmlのcust-config要素で宣言されたカスタマイズ・クラスのみがエクスポートされます。adf-config.xmlに宣言されたcust-config要素がない場合、すべてのカスタマイズ・クラスがエクスポートされます。

すべてのカスタマイズをインポートするには、オプションrestrictCustTo="%"を使用します。

14.3.9 ファイルベース・リポジトリからデータベース・ベース・リポジトリへの移動

ファイルベース・リポジトリをデータベース・ベース・リポジトリに移動できます。(データベース・ベース・リポジトリからファイルベース・リポジトリへの移動はできません。)

停止時間を最短にするため、ファイルベース・リポジトリからデータベース・ベース・リポジトリにアプリケーションのメタデータを移動するには、次の手順を使用します。

1. 第14.2項の説明に従い、RCUを使用して新しいリポジトリにスキーマを作成します。

2. ソース・パーティションと一致する名前を使用して、WLSTコマンドcreateMetadataPartitionで新しいパーティションを作成します。

createMetadataPartition(repository='mds-repos1', partition='partition1')

3. ソース・パーティションからファイル・システム上のディレクトリにメタデータをエクスポートします。

exportMetadata(application='sampleApp', server='server1',
toLocation='/tmp/myrepos/partition1', docs='/**')

4. ファイル・システムから新しいパーティションにメタデータをインポートします。

importMetadata(application='sampleApp', server='server1',
fromLocation='/tmp/myrepos/partition1', docs='/**')

5. 第10.4.3項または第10.5.3項の説明に従って、アプリケーションのタイプに応じてアプリケーションを再デプロイします。この操作の際には、「アプリケーション属性」ページで新しいパーティションおよびリポジトリを指定します。

1. リポジトリを変更するには、「リポジトリ名」の横にあるアイコンをクリックします。「メタデータ・リポジトリ」ダイアログ・ボックスでリポジトリを選択し、「OK」をクリックします。

2. パーティションを変更するには、「パーティション名」にパーティション名を入力します。

6. 第14.3.3.2項の説明に従って、ファイルベース・リポジトリの登録を解除します。

14.3.10 リポジトリからのメタデータ・パーティションの削除

アプリケーションのデプロイもアプリケーションによる参照も存在しないメタデータ・パーティションは削除できます。リポジトリからのメタデータ・パーティションの削除が必要な場合には、次の状況が考えられます。

- アプリケーションのアンデプロイ時。パーティション内のユーザー・カスタマイズなどのメタデータが引き続き必要な場合があるため、Oracle Fusion Middlewareではメタデータ・パーティションが残されます。メタデータが不要な場合は、パーティションを削除できます。

- メタデータを別のパーティションに転送し、新しいパーティションを使用するようにアプリケーションを構成した場合。

- パーティションをクローニングし、新しいパーティションを使用するようにアプリケーションを構成した場合。

パーティションを削除すると、そのパーティションに含まれるデータはすべて削除されます。

次の各項の説明に従って、WLSTまたはFusion Middleware Controlを使用し、メタデータのパーティションを削除できます。

- Fusion Middleware Controlによるメタデータ・パーティションの削除

- WLSTによるメタデータ・パーティションの削除

14.3.10.1 Fusion Middleware Controlによるメタデータ・パーティションの削除

Fusion Middleware Controlを使用してリポジトリ・パーティションからメタデータ・パーティションを削除する手順は次のとおりです。

1. ナビゲーション・ペインで「メタデータ・リポジトリ」を展開します。

2. リポジトリを選択します。
リポジトリのホーム・ページが表示されます。

3. 「リポジトリ・パーティション」セクションで、パーティションを選択し、「削除」を選択します。

4. 「確認」ダイアログ・ボックスで「OK」をクリックします。

14.3.10.2 WLSTによるメタデータ・パーティションの削除

メタデータ・パーティションをリポジトリから削除するには、WLSTコマンドdeleteMetadataPartitionを使用できます。たとえば、ファイルベース・リポジトリmds-repos1からメタデータ・パーティションを削除するには、次のコマンドを使用します。

deleteMetadataPartition(repository='mds-repos1', partition='partition1')

14.3.11 メタデータ・バージョン履歴のパージ

データベース・ベースのMDSリポジトリでは、メタデータ・バージョン履歴をパーティションからパージできます。(ファイルベースのMDSリポジトリではバージョン履歴が保持されません。)この操作では、ラベルのないドキュメントのバージョン履歴がアプリケーションのリポジトリ・パーティションからパージされます。最新バージョンはラベルがない場合もパージされません。

メタデータ・ラベルをパージするには、第14.3.12.5項の説明に従って、purgeMetadataLabelsコマンドを使用します。次に、メタデータ・バージョン履歴をパージできます。

データベースのスペース不足またはパフォーマンスの劣化が疑われる場合は、MDSリポジトリのメンテナンスの一環として、メタデータ・バージョン履歴を定期的にパージすることを検討してください。この操作はパフォーマンス集約型であるため、メンテナンス・ウィンドウ内またはシステム使用量の少ないときに実行するようにしてください。MDSは、反復ごとに300のドキュメントを消去し、変更をコミットして、消去可能なドキュメントの処理がすべて終了するまでこの操作を繰り返します。

特定のタイプのアプリケーションに固有の推奨事項については、個々のコンポーネントのドキュメントを参照してください。

次の項の説明にあるように、WLSTまたはFusion Middleware Controlを使用して、メタデータ・バージョン履歴をパージできます。

- Fusion Middleware Controlによるメタデータ・バージョン履歴のパージ

- WLSTによるメタデータ・バージョン履歴のパージ

- 自動パージの有効化

14.3.11.1 Fusion Middleware Controlによるメタデータ・バージョン履歴のパージ

Fusion Middleware Controlを使用してメタデータ・バージョン履歴をパージする手順は次のとおりです。

1. ナビゲーション・ペインで「アプリケーションのデプロイ」を展開し、アプリケーションを選択します。

2. 「アプリケーションのデプロイ」メニューで、「MDS構成」を選択します。
Oracle SOA Suiteの場合、ナビゲーション・ツリーで、「SOA」を開き、「soa-infra」を選択します。「SOAインフラストラクチャ」メニューから、「管理」→「MDS構成」を選択します。

「MDS構成」ページが表示されます。

3. 「パージ」セクションで、「次より古い過去のラベルのない全バージョンをパージ」フィールドに時間の数字を入力し、時間の単位を選択します。たとえば、「3」と入力し、「月」を選択します。

4. 「パージ」をクリックします。

5. 「確認」ダイアログ・ボックスで「Close」をクリックします。

14.3.11.2 WLSTによるメタデータ・バージョン履歴のパージ

WLSTを使用して、メタデータ・バージョン履歴をパージするには、purgeMetadataコマンドを使用します。olderThanパラメータで秒数を指定して、パージするドキュメントを指定します。次の例では、100秒以上経過しているすべてのドキュメントがパージされます。

purgeMetadata(application='sampleApp', server='server1', olderThan=100)

14.3.11.3 自動パージの有効化

MDSAppConfig MBeanを使用して、自動パージを有効化できます。

1. 「WebLogicドメイン」メニューから、「システムMBeanブラウザ」を選択します。
「システムMBeanブラウザ」ページが表示されます。

2. 「アプリケーション定義のMBean」→「oracle.adf.share.config」→「サーバー: 名前」→「アプリケーション: 名前」→「ADFConfig」→「ADFConfig」→「ADFConfig」を開きます。

3. 「MDSAppConfig」を選択します。
「アプリケーション定義のMBean」ページが表示されます。

4. AutoPurgeTimeToLiveに、値を秒単位で入力します。

5. 「ADFConfig」(MDSAppConfigの親)にナビゲートして選択します。

6. 「操作」タブで、「保存」をクリックします。

14.3.12 MDSリポジトリでのメタデータ・ラベルの管理

次の各項目で、MDSリポジトリ内のメタデータ・ラベルの管理方法について説明します。

- メタデータ・ラベルの理解

- メタデータ・ラベルの作成

- メタデータ・ラベルの一覧表示

- メタデータ・ラベルの昇格

- メタデータ・ラベルのパージ

- メタデータ・ラベルの削除

14.3.12.1 メタデータ・ラベルの理解

メタデータ・ラベルは、メタデータ・リポジトリ・パーティションから各オブジェクトの特定のバージョンを選択する手段です。概念的に、これは一連のドキュメント・バージョン(ドキュメントごとに1バージョン)で、様々なドキュメント・バージョンの水平のストライプを表します。このストライプは、ラベルが作成された時点におけるドキュメントの最先端バージョン(最新のバージョン)で構成されます。

ラベルを使用すると、ラベル作成時点におけるメタデータを表示できます。パーティションに含まれるアプリケーションのメタデータの論理バックアップとリカバリをサポートするWLSTコマンドを使用できます。

ラベルは、データベース・ベース・リポジトリでのみサポートされます。

ラベルに含まれるドキュメント・バージョンは、ラベルを明示的に削除しないかぎり、自動パージでは削除されません。このように、ラベルを作成することによって、ラベルの作成時点におけるメタデータのビューは、ラベルが削除されるまで使用可能です。

MARが含まれるアプリケーションがデプロイされると、接頭辞postDeployLabel_が付いたラベルが作成されます。たとえば、postDeployLabel_mdsappdb_mdsappdb.mar_2556916398です。

MARにパッチを適用するたびに、新しいデプロイメント・ラベルが作成されますが、以前のデプロイメント・ラベルは削除されません。同様に、MARが含まれるアプリケーションをアンデプロイすると、そのアプリケーションはアンデプロイされますが、ラベルはメタデータ・リポジトリ・パーティションに残ります。

デプロイメント・ラベルを削除する場合、アプリケーションを再起動するとMARは自動的に再デプロイされ、デプロイメント・ラベルも再作成されます。

14.3.12.2 メタデータ・ラベルの作成

MDSリポジトリのパーティション内で、オブジェクトの特定バージョンにラベルを作成するには、WLSTコマンドcreateMetadataLabelを使用します。たとえば、アプリケーションmy_mds_appにprod1という名前のラベルを作成するには、次のコマンドを使用します。

createMetadataLabel(application='my_mds_app', server='server1', name='prod1')
Executing operation: createMetadataLabel.

Created metadata label "prod1".

バージョンが複数あるアプリケーションの場合は、applicationVersionパラメータを使用してバージョンを指定する必要があります。

14.3.12.3 メタデータ・ラベルの一覧表示

特定のアプリケーションのメタデータ・ラベルを一覧表示できます。これを行うには、WLSTコマンドlistMetadataLabelを使用します。たとえば、アプリケーションmy_mds_appのラベルを一覧表示するには、次のコマンドを使用します。

listMetadataLabels(application='my_mds_app', server='server1')
Executing operation: listMetadataLabels.

Database Repository partition contains the following labels:
prod1
prod2
postDeployLabel_mdsappdb_mdsappdb.mar_2556916398

バージョンが複数あるアプリケーションの場合は、applicationVersionパラメータを使用してバージョンを指定する必要があります。

14.3.12.4 メタデータ・ラベルの昇格

メタデータ・ラベルが関連付けられたドキュメントを昇格して、最終バージョンにすることができます。つまり、最新への昇格が可能です。ラベルによって取得されたすべてのドキュメントを以前のバージョンにロールバックする場合にラベルを昇格します。

ラベルを最新に昇格するには、WLSTコマンドpromoteMetadataLabelを使用します。たとえば、ラベルprod1を昇格する場合は、次のコマンドを使用します。

promoteMetadataLabel(application='my_mds_app', server='server1', name='prod1')
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)

Executing operation: promoteMetadataLabel.

Promoted metadata label "prod1" to tip.

バージョンが複数あるアプリケーションの場合は、applicationVersionパラメータを使用してバージョンを指定する必要があります。

14.3.12.5 メタデータ・ラベルのパージ

指定した名前のパターンまたは経過時間と一致するメタデータ・ラベルをパージし、使用しなくなったラベルをパージできます。こうすることにより、データベースのサイズが減り、パフォーマンスが向上します。リポジトリからドキュメントやリビジョン履歴をパージする前に、使用しなくなったメタデータ・ドキュメントに関連付けられているラベルを削除する必要があります。

アンデプロイした古いアプリケーションのラベルを削除することが適切と思われる場合もありますが、これらのラベルは削除されていません。MARにパッチを適用するたびに、新しいラベルが作成されますが、以前のラベルは削除されません。

次の各項で説明するように、Fusion Middleware ControlまたはWLSTを使用して、メタデータ・ラベルをパージできます。

- Fusion Middleware Controlを使用したメタデータ・ラベルのパージ

- WLSTを使用したメタデータ・ラベルのパージ

14.3.12.5.1 Fusion Middleware Controlを使用したメタデータ・ラベルのパージ

Fusion Middleware Controlを使用してメタデータ・ラベルをパージする手順は次のとおりです。

1. ナビゲーション・ペインで「メタデータ・リポジトリ」を展開します。

2. リポジトリを選択します。
リポジトリのホーム・ページが表示されます。

3. 「パーティション」を選択し、「ラベルの管理」をクリックします。
次の図のように「ラベルの管理」ページが表示されます。

デフォルトでは、選択したパーティションで1年より長く経過し、デプロイされていないまたはサンドボックスに関連付けられていないすべてのメタデータ・ラベルが表にリストされます。

4. 特定のラベルまたは複数のラベルを検索する手順は次のとおりです。

- 「ラベル名」で演算子を選択し、フィルタ基準を入力します。文字には大/小文字区別があります。次のワイルドカードを使用できます。

- パーセント(%): 任意の数の文字に一致します。

- アンダースコア(_): 1文字に一致します。

- バックスラッシュ(\): ワイルドカードのエスケープ文字として使用します。

たとえば、文字列postDeployLabel%では、postDeployLabelで始まる任意のラベルが返されます。この結果、デプロイ済のMARに関連付けられたラベルが表示されます。

- 「期間」に2などの数値を入力します。(使用可能な演算子は「次より古い」のみです。)

- 「期間(単位)」で、「時間」、「日」、「週」、「月」、「年」などの単位を選択します。使用可能な演算子は「次と等しい」のみです。

5. 「検索」をクリックします。

6. デフォルトでは、サンドボックスに関連付けられているラベルおよびアプリケーションにデプロイ済のラベルは表示されません。これらのラベルを表示するには、「サンドボックス」または「デプロイメント」、あるいは両方を選択します。次の点に注意してください。

- サンドボックスに関連付けられたラベルは削除できません。

- 「デプロイメント」を選択すると、MARデプロイメントに関連付けられたラベルが表示されます。

7. ラベルを選択し、「選択項目の削除」をクリックします。

8. 「確認」ボックスで、「OK」をクリックします。

特定のデプロイ済アプリケーションで未使用のラベルをすべてパージするには、次の手順を実行します。

1. 「デプロイメント」を選択します。

2. 文字列postDeployLabel_application_name%を使用して、名前でフィルタ処理します。

3. 最新(使用中)以外をすべて選択して削除します。(現在使用中の最新のラベルは最初にリストされます。)

4. 「選択項目の削除」をクリックします。

14.3.12.5.2 WLSTを使用したメタデータ・ラベルのパージ

WLSTコマンドのpurgeMetadataLabelsを使用して、指定したパターンまたは経過時間と一致するメタデータ・ラベルをパージできます。このコマンドでは、指定した基準と一致するラベルがパージされますが、そのラベルによって指定されていたメタデータ・ドキュメントは削除されません。

たとえば、指定した名前のパターンと一致し30分よりも長く経過したメタデータ・ラベルすべてをパージするには、次のようにします。

purgeMetadataLabels(repository='mds-myRepos', partition='partition1',
namePattern='prod*', olderThanInMin='30')
Location changed to domainRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help(domainRuntime)

Executing operation: purgeMetadataLabels.

The following metadata labels were purged: repository=mds-soa,parititon=partition1,namePattern=prod*,olderThanInMin=30:

14.3.12.6 メタデータ・ラベルの削除

指定したメタデータ・ラベルを削除するには、WLSTコマンドdeleteMetadataLabelを使用します。たとえば、アプリケーションmy_mds_appのprod1という名前のラベルを削除するには、次のコマンドを使用します。

deleteMetadataLabel(application='my_mds_app', server='server1', name='prod1')

バージョンが複数あるアプリケーションの場合は、applicationVersionパラメータを使用してバージョンを指定する必要があります。

アプリケーションに関連付けられたラベルを検索するには、第14.3.12.3項の説明に従って、listMetadataLabelsコマンドを使用します。

14.4 メタデータ・リポジトリ・スキーマの管理

次の各項目で、メタデータ・リポジトリ・スキーマの管理方法について説明します。

- メタデータ・リポジトリ・スキーマ・パスワードの変更

- メタデータ・リポジトリの文字セットの変更

14.4.1 メタデータ・リポジトリ・スキーマ・パスワードの変更

スキーマのパスワードはデータベースに保存されています。パスワードは、一定期間が経過した後に期限切れになることに注意してください。たとえば、デフォルトでは、11gのOracle Databaseのパスワードが180日後に期限切れになります。

ほとんどのコンポーネントでは、データベースのパスワード変更のみを行う必要があります。ただし、Oracle Platform Security Servicesでは追加の手順が必要です。

この項には次のトピックが含まれます:

- ほとんどのコンポーネントのスキーマ・パスワードの変更

- Oracle Platform Security Servicesのスキーマ・パスワードの変更

14.4.1.1 ほとんどのコンポーネントのスキーマ・パスワードの変更

ほとんどのコンポーネントのスキーマ・パスワード変更では、データベースのパスワードを変更します。

たとえば、スキーマOFM_MDSのパスワードを変更する手順は次のとおりです。

1. SQL*Plusを使用して、データベースに接続します。SYSDBA権限のあるユーザーとして接続します。

2. 次のコマンドを発行します。

SQL> ALTER USER schema IDENTIFIED BY new_password;
COMMIT;

たとえば、OFM_MDSのパスワードをabc123に変更するには、次のコマンドを使用します。

SQL> ALTER USER OFM_MDS IDENTIFIED BY abc123;
COMMIT;

3. MDSリポジトリ・スキーマ・パスワードを変更する場合は、Oracle WebLogic Server管理コンソールを使用して、対応するMDSリポジトリ・データ・ソースのパスワードを変更する必要があります。

1. 「ドメイン構造」で、「サービス」→「データ・ソース」を選択します。

2. MDSリポジトリに関連するデータ・ソースをクリックします。

3. 「構成」タブをクリックして、「接続プール」タブをクリックします。

4. 「パスワード」に新しいパスワードを入力します。

5. 「保存」をクリックします。

6. このデータ・ソースを使用する管理対象サーバーを再起動します。

14.4.1.2 Oracle Platform Security Servicesのスキーマ・パスワードの変更

Oracle Platform Security Servicesのスキーマ・パスワードを変更する手順は次のとおりです。

1. SQL*Plusを使用して、データベースに接続します。SYSDBA権限のあるユーザーとして接続します。

2. 次のコマンドを発行します。

SQL> ALTER USER schema IDENTIFIED BY new_password;
COMMIT;

次の手順に進む前に、コミット・コマンドを必ず発行してください。

3. WLSTコマンドmodifyBootStrapCredentialを実行して、JPS構成ファイルを更新します。

1. 次のディレクトリからWLSTを起動します。

ORACLE_HOME/oracle_common/common/bin/wlst.sh

2. modifyBootStrapCredentialsコマンドで、JPS構成ファイルへのフル・パスを指定します。次に例を示します。

modifyBootStrapCredential(jpsConfigFile='/scratch/oracle//config/domains/soa_domain/config/fmwconfig/jps-config.xml',username='schema_username',password='password')

この時点で管理サーバーを起動できますが、ログ・ファイルには次の例外が表示されます。

####<Jun 30, 2014 2:15:09 PM CEST> <Error> <Deployer> <deployer> <AdminServer> <[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default
(self-tuning)'> <<WLS Kernel>> <>
<f9d07f66-36d0-462e-83fd-6ca40ac15a8a-00000004> <1402936508655> <BEA-149205>
<Failed to initialize the application "opss-data-source" due to error
weblogic.application.ModuleException:
weblogic.common.resourcepool.ResourceSystemException:
Could not connect to 'oracle.jdbc.OracleDriver'.

The returned message is: ORA-01017: invalid username/password; logon denied.

このエラーを回避するには、次の手順を実行します。

4. 第14.4.1.1項の手順3で説明するように、データ・ソースの構成を更新します。

14.4.2 メタデータ・リポジトリの文字セットの変更

Oracle Databaseに格納されるメタデータ・リポジトリの文字セットを変更する方法については、次のサイトにアクセスして、『Oracle Databaseグローバリゼーション・サポート・ガイド』を参照してください。

http://www.oracle.com/technetwork/database/enterprise-edition/documentation/index.html

新しいシステムのデプロイメントには、すべてUnicodeを使用することをお薦めします。システムをUnicodeでデプロイすることにより、操作性、互換性、拡張性の面で多くの利点が得られます。Oracle Databaseを使用すると、Unicodeの利点を利用しながら、高パフォーマンスのシステムをより迅速かつより容易にデプロイすることができます。現在、多言語データのサポートが必要ない場合やUnicodeをまったく必要としていない場合でも、これは新しいシステムにとって長期的には最善の選択となる可能性が高く、最終的に、時間と資金が節約されるとともに、長期にわたって競争上の優位性が確立されます。

SQL Serverデータベースにメタデータを格納する場合で、ロケールを考慮した文字セットが大/小文字を区別しない場合は、データベース・インスタンスの作成時に、大/小文字区別の照合順序を選択する必要があります。RCUを使用してSQL ServerにMDSスキーマを作成する場合は、Unicodeサポートがデフォルトになります。使用要件に応じて、このデフォルト設定はUnicode以外のスキーマを使用するように上書きできます。

14.5 データのパージ

Oracle Fusion Middlewareデータベース内のデータの量が非常に多くなった場合、データベースの保守が困難になり、パフォーマンスに影響を及ぼす可能性があります。場合によっては、Oracle Fusion Middlewareは、データを自動的にパージします。また、Oracle Fusion Middlewareがデータの増加を管理する方法(時間とともに蓄積し、パフォーマンスに影響を及ぼす可能性のあるデータをパージするスクリプトなど)を提供する場合もあります。

Oracle Fusion Middlewareのコンポーネントの多くは、データをパージするためにPL/SQL手順として書き込まれたスクリプトを提供します。このスクリプトは、次の場所にあります。

ORACLE_HOME/common/sql/component-name_purge_purgetype.sql

たとえば、Oracle Business Process Managementのログをパージするスクリプトは、次の場所にあります。

ORACLE_HOME/common/sql/bpm_purge_logs.sql

表14-2 にOracle Fusion Middlewareのコンポーネントのデータのパージに関する情報へのポインタを示します。

表14-2 データのパージに関する情報

コンポーネント

説明

Oracle Application Development Framework

『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の一時的な記憶域表のクリーンアップに関する項を参照してください。

Oracle Application Development Frameworkビジネス・コンポーネント

次のスクリプトを使用して、Oracle ADFビジネス・コンポーネントでユーザー・セッションの状態および一時的な永続コレクションの格納に使用されるデータベース内の行をパージします。

ORACLE_HOME/oracle_common/common/sql/adfbc_purge_statesnapshots.sql

PS_TXN表は、自動的にパージされます。

Oracle WebLogic Server: Oracle Infrastructure Webサービス

WS-RMがデータベース・ストアを使用している場合、次のスクリプトを使用してデータをパージします。

ORACLE_HOME/oracle_common/common/sql/ows_purge_wsrm_msgs.sql

Oracle WebLogic Server: JAXWS Webサービス

『Oracle WebLogic Server JAX-WS Webサービスの開発』のWebサービス永続性のクリーンアップに関する項の説明に従って、Webサービス永続ストアをクリーンアップします。

WebServicePersistenceMBeanのdefaultMaximumObjectLifetimeフィールドを使用して、オブジェクトの最大ライフタイムを設定します。『WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanの理解に関する項を参照してください。

Oracle WebLogic Server: ステートフルEJB

構成の必要はありません。データは自動的にパージされます。

Oracle WebLogic Server: JMS

『Oracle WebLogic Server JMSリソースの管理』の基本的なJMSシステム・リソースの構成およびJMSメッセージの管理に関する項を参照してください。

『Oracle WebLogic Serverのパフォーマンスのチューニング』の WebLogic JMSのチューニングに関する項も参照してください。

Oracle WebLogic Server: JDBCデータ・ソースまたはファイルベース・データ・ソースのセッション永続性

構成の必要はありません。データは自動的にパージされます。

MDSリポジトリ

データの自動パージおよび手動パージの詳細は、第14.3.11項を参照してください。

Oracle Web Services Manager

構成の必要はありません。データは自動的にパージされます。

特定の状況では、Oracle Schedulerを使用して、スクリプトの実行を自動化することを検討できます。たとえば、スケジュール済ジョブを設定して、完了インスタンスについて14日前までをパージすることができます。

特定の状況では、Oracle Schedulerを使用して、スクリプトの実行を自動化することを検討できます。たとえば、スケジュール済ジョブを設定して、Oracle SOA Suiteの完了インスタンスについて14日前までをパージすることができます。

Oracle Scheduler(エンタープライズ・ジョブ・スケジューラ)は、Oracle Databaseの一部です。Oracle Schedulerは、DBMS_SCHEDULER PL/SQLパッケージ内の手順および機能によって実装されます。Oracle Schedulerの詳細は、『Oracle Database管理者ガイド』のOracle Schedulerの概念およびジョブの作成、実行、および管理に関する項を参照してください。

14.5.1 Oracle Infrastructure Webサービスのデータのパージ

WS-RMがデータベース・ストアを使用している場合、次のスクリプトを使用してデータをパージします。

ORACLE_HOME/oracle_common/common/sql/ows_purge_wsrm_msgs.sql

15 ネットワーク構成の変更

この章では、Oracle Fusion Middlewareで使用するOracle Fusion MiddlewareのホストとOracleデータベースのホスト名、ドメイン名、IPアドレスなどのネットワーク構成を変更する手順について説明します。また、Oracle Fusion MiddlewareでIPv6プロトコルを使用する方法についても説明します。

内容は次のとおりです。

- Oracle Fusion Middlewareのネットワーク構成の変更

- データベースのネットワーク構成の変更

- ネットワーク接続のオン/オフの切替え

- 静的IPアドレスとDHCPの切替え

- IPv6の使用

15.1 Oracle Fusion Middlewareのネットワーク構成の変更

この項では、次のインストール・タイプが含まれるホストのホスト名、ドメイン名、IPアドレスまたはこれらの組合せを変更する方法について説明します。

- Oracle WebLogic ServerおよびJavaコンポーネント。Oracle WebLogic Serverのホスト名、ドメイン名またはIPアドレスを変更する場合は、Oracle WebLogic ServerにデプロイされているOracle SOA Suiteのコンポーネントなど、Javaコンポーネントに関する情報も自動的に変更されます。

- Oracle HTTP Serverホスト名またはIPアドレスを変更できます。

別のシステムへの環境の移行については、第20章を参照してください。

次の各項目では、ホスト名、ドメイン名、またはIPアドレスの変更方法を説明します。

- 管理サーバーのネットワーク構成の変更

- 管理対象サーバーのネットワーク構成の変更

- Oracle HTTP Serverのネットワーク構成の変更

15.1.1 管理サーバーのネットワーク構成の変更

WLSTコマンドを使用して、管理サーバーのネットワーク構成を変更できます。

1. 管理サーバーを停止します。

2. 管理サーバーの場合、次のWLSTコマンドをオフライン・モードで使用して、新しいホスト名でマシンを設定します。

wls:/offline> readDomain('DOMAIN_HOME')
wls:/offline/sampledomain> cd ('/Machine/newhostname')
wls:/offline/sampledomain> machine = cmo
wls:/offline/sampledomain> cd ('/Server/AdminServer')
wls:/offline/sampledomain> set('Machine', machine)
wls:/offline/sampledomain> updateDomain()
wls:/offline/sampledomain> exit()

3. 管理サーバーのリスニング・ポートを設定します。

wls:/offline/sampledomain> readDomain('DOMAIN_HOME')
wls:/offline/sampledomain> cd('/Server/AdminServer')
wls:/offline/sampledomain> cmo.setListenPort(8001)
wls:/offline/sampledomain> updateDomain()
wls:/offline/sampledomain> exit()

4. 管理サーバーを起動します。

15.1.2 管理対象サーバーのネットワーク構成の変更

Oracle WebLogic Server管理コンソールを使用して、管理対象サーバーのネットワーク構成を変更します。

管理対象サーバーのホスト名、ドメイン名またはIPアドレスを変更する手順は次のとおりです。

1. 第2.3項の説明に従って、管理コンソールを表示します。

2. チェンジ・センターで、「ロックして編集」をクリックします。

3. 1つ以上のWebLogic Serverをホストするコンピュータの論理的な表現であるマシンを作成し、新しいホストを指すように指定します。(「ホーム」ページで、「マシン」を選択します。続いて、「新規」をクリックします)。管理コンソール・ヘルプの指示に従います。
『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のホスト名検証の使用に関する項の説明に従って、ノード・マネージャにアクセスする管理サーバーのホスト名検証を無効にする必要があります。

4. 管理サーバーを再起動します。

5. 管理対象サーバーの構成を、新しいマシンを指すように変更します

1. コンソールの左ペインから、「環境」→「サーバー」を開いて、サーバーの名前を選択します。続いて、サーバーの名前を選択します。

2. 「構成」タブを選択して、「一般」タブを選択します。「マシン」フィールドで、サーバーの割当て先のマシンを選択します。

3. 「リスニング・アドレス」を新しいホストに変更します。
「保存」をクリックします。

6. 管理対象サーバーを起動します。Oracle WebLogic Server管理コンソール、WLST、または次のコマンドを使用できます。

DOMAIN_NAME/bin/startManagedWeblogic.sh managed_server_name
admin_url

管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。

15.1.3 Oracle HTTP Serverのネットワーク構成の変更

WebLogicドメインまたはスタンドアロン・ドメインでOracle HTTP Serverのネットワーク構成を変更する手順は、次のとおりです。

1. この手順を開始する前に、環境のバックアップを実行します。第17章を参照してください。

2. オペレーティング・システムで、ホスト名、ドメイン名、IPアドレス、またはこれらの組合せを更新します。ここでの手順を実行する方法の詳細は、該当するオペレーティング・システムのドキュメントを参照してください。

1. オペレーティング・システムの更新により、ホスト名、ドメイン名またはIPアドレスが適切に変更されることを確認します。

2. オペレーティング・システムで再起動が必要な場合は、ホストを再起動します。

3. ネットワークの別のホストから、このホストにpingが実行できることを確認します。必ず新しいホスト名を使用してpingを実行し、すべてが正しく解決されていることを確認してください。

3. 第4.2.2項の説明に従って、ノード・マネージャを停止します。

4. Oracle HTTP Serverを停止します。次に例を示します。

./stopComponent.sh ohs1

5. 次のディレクトリに変更します。

DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_component_name

6. 各構成ファイル(.confで終了するファイル)について、次を実行します。

- 古い正規ホスト名(oldhost.example.comなど)を検索し、新しい正規ホスト名(newhost.example.comなど)に置き換えます。

- 古いホストの短縮名(oldhostなど)を検索し、新しいホストの短縮名(newhostなど)に置き換えます。

- 古いIPアドレスを検索し、新しいIPアドレスに置き換えます。

7. ノード・マネージャを再起動します。

DOMAIN_HOME/bin/startNodeManager.sh

8. Oracle HTTP Serverを再起動します。

./startComponent.sh ohs1

15.2 データベースのネットワーク構成の変更

この項では、Oracle Fusion Middlewareコンポーネントのメタデータを格納するためのデータベースが含まれるホストのホスト名、ドメイン名、またはIPアドレスの変更方法について説明します。

1. 他のホスト上にあるものも含めて、データベースを使用するすべてのコンポーネントを停止します。第4章の説明に従って管理サーバー、管理対象サーバー、およびすべてのコンポーネントを停止します。

2. データベースを停止します。

1. ORACLE_HOMEおよびORACLE_SID環境変数を設定します。

2. リスナーとデータベースを停止します。

lsnrctl stop

sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> shutdown
SQL> quit

3. すべてのOracle Fusion Middlewareプロセスが停止したことを確認します。

4. ホストの再起動後にOracle Fusion Middlewareプロセスが自動的に起動しないように、/etc/init.dスクリプトなどの自動起動スクリプトを設定している場合はすべて無効にします。

3. ネットワーク構成を変更します。
ホスト名、ドメイン名、またはIPアドレスを変更する場合は、新しい名前またはIPアドレスでオペレーティング・システムを更新してホストを再起動し、そのホストがネットワーク上で正しく機能していることを確認します。ここでの手順を実行する方法の詳細は、該当するオペレーティング・システムのドキュメントを参照してください。

1. オペレーティング・システムの更新により、ホスト名、ドメイン名またはIPアドレスが適切に変更されることを確認します。

2. オペレーティング・システムで再起動が必要な場合は、ホストを再起動します。

3. ネットワークの別のホストから、このホストにpingが実行できることを確認します。必ず新しいホスト名、ドメイン名、またはIPアドレスを使用してpingを実行し、すべてが正しく解決されていることを確認してください。

4. ネットワーク構成への参照を変更します。
使用しているコンポーネントによっては、ホスト名、ドメイン名、またはIPアドレスが含まれるファイルを変更する必要があります。新しいホスト名、ドメイン名またはIPアドレスへの参照を変更する場合に、変更が必要になると考えられるファイルの一部を次に示します。

- tnsnames.ora。これは、次の場所にあります。

ORACLE_HOME/network/admin/tnsnames.ora

- listener.ora。これは、次の場所にあります。

(UNIX) ORACLE_HOME/network/admin/listener.ora
(Windows) ORACLE_HOME\network\admin\listener.ora

- Oracle HTTP Serverでは、httpd.confファイルを編集して次の変更を行います。

- 新しいホスト名またはIPアドレスおよびポートを使用して、リスニング・ディレクティブを更新します(本番環境のOracle HTTP Serverが別のポートを使用している場合)。

- ホスト名、IPアドレスまたはポート番号が定義されている場合、本番環境用の新しい値を使用してVirtualHostディレクティブを更新します。

- テスト環境で構成されており、トポロジ(ホスト名、IPアドレス、ポート番号)情報またはその他のマシン固有の情報を持つ、デフォルトでない他のディレクティブを更新します。

- Oracle HTTP Serverでは、dads.confファイルのPlsqlDatabaseConnectString

- Oracle HTTP Serverでは、mod_oradavを使用している場合、mod_oradav.confファイルのORACONNECTSNパラメータ

- Oracle HTTP Serverでmod_plsqlを使用する場合は、dads.confファイル内のPlsqlDatabaseConnectString属性。

- Oracle HTTP Serverでは、mod_wl_ohsを使用している場合、mod_wl_ohs.confファイルを更新します。
WebLogicHost、WebLogicPort、またはWebLogicClusterディレクティブでホスト名、IPアドレス、ポート番号を更新します。

- Oracle Forms Servicesでは、sqlnet.ora。

前述のリストは、すべてを網羅したものではありません。各コンポーネントで使用するファイルの詳細は、第20章を参照してください。その章では、データベースなどのコンポーネントをテスト・システムから本番システムに移動して、ホスト名の変更を反映する方法について説明しています。

5. データベースを起動する手順は次のとおりです。

1. データベースをインストールしたユーザーとしてホストにログインします。

2. ORACLE_HOMEおよびORACLE_SID環境変数を設定します。

3. UNIXシステムでは、LD_LIBRARY_PATH、LD_LIBRARY_PATH_64、LIB_PATHまたはSHLIB_PATHの各環境変数を適切な値に設定します。実際に設定が必要な環境変数および値は、UNIXオペレーティング・システムのタイプによって異なります。

4. データベースとリスナーを起動します。

sqlplus /nolog
SQL> connect SYS as SYSDBA
SQL> startup
SQL> quit

lsnrctl start

6. 第14.3.4項の説明に従って、データベースの新しいホスト名、ドメイン名、またはIPアドレスを使用するようにシステム・データ・ソースを変更します。

7. データベースを使用するコンポーネントを起動します。

1. 他のホスト上にあるものも含めて、データベースを使用するすべてのコンポーネントを起動します。第4章の説明に従って管理サーバー、管理対象サーバー、およびすべてのコンポーネントを起動します。

2. この手順の最初で、Oracle Fusion Middlewareを自動的に起動するプロセスを無効化していた場合は、有効化します。

15.3 ネットワーク接続のオン/オフの切替え

この項では、Oracle Fusion Middlewareホストのネットワーク接続のオン/オフを切り替える方法について説明します。前提および制限は次のとおりです。

- ホストには、Infrastructureを使用しないインスタンスが含まれている必要があります。または、中間層インスタンスおよびInfrastructureが同じホスト内にある必要があります。

- DHCPは、ループバック・モードで使用する必要があります。詳細は、Oracle Fusion Middlewareのシステム要件と仕様のドキュメントを参照してください。

- IPアドレスの変更のみがサポートされています。ホスト名は変更できません。

- DHCPモードでは、デフォルトのホスト名(localhost.localdomain)は使用しないでください。標準のホスト名を使用するようにホストを設定します。ループバックIPアドレスからそのホスト名に解決する必要があります。

- ループバック・アダプタはすべてのオフ状態のネットワークのインストール(DHCPまたは静的IP)で必要です。詳細は、『Oracle Fusion Middlewareのインストールのプランニング』を参照してください。

この項では、次の項目について説明します。

- ネットワーク接続のオフからオンへの変更(静的IPアドレス)

- ネットワーク接続のオフからオンへの変更(DHCP)

- ネットワーク接続のオンからオフへの変更(静的IPアドレス)

15.3.1 ネットワーク接続のオフからオンへの変更(静的IPアドレス)

この手順は、ネットワーク接続されていないホストに標準のホスト名(localhostではない)を使用してOracle Fusion Middlewareをインストールした後で、ネットワークに接続し、静的IPアドレスを使用する場合を想定しています。IPアドレスは、デフォルトのループバックIPまたは任意の標準的なIPアドレスです。

ネットワークに接続された状態に変更するには、ホストをネットワークに接続します。Oracle Fusion Middlewareの更新は必要ありません。

15.3.2 ネットワーク接続のオフからオンへの変更(DHCP)

この手順は、ネットワーク接続されていないホストに標準のホスト名(localhostではない)を使用してインストールした後で、ネットワークに接続し、DHCPを使用する場合を想定しています。ホストのIPアドレスは、任意の静的IPアドレスまたはループバックIPアドレスのいずれでもかまいません。また、このアドレスはホスト名に対して設定されている必要があります。

ネットワークに接続をオンにする手順は次のとおりです。

1. DHCPを使用してホストをネットワークに接続します。

2. ループバックIPアドレスに対してのみ、ホスト名を構成します。

15.3.3 ネットワーク接続のオンからオフへの変更(静的IPアドレス)

この手順は、ホストがネットワークに接続され、静的IPアドレスを使用している状態を、ネットワークに接続されていない状態に変更する場合に実行します。

1. /etc/hostsファイルを構成して、IPアドレスとホスト名がローカルで解決できるようにします。

2. ホストを、ネットワークから切断します。
ホスト名やIPアドレスを変更する必要はありません。

15.4 静的IPアドレスとDHCPの切替え

この項では、静的IPアドレスとDHCPを切り替える方法を説明します。前提および制限は次のとおりです。

- このホストには、アイデンティティ管理コンポーネントなどのすべてのOracle Fusion Middlewareコンポーネント、およびこれらのコンポーネントに関連付けられたデータベースが含まれている必要があります。つまり、Oracle Fusion Middleware環境全体が、このホスト上に存在している必要があります。

- DHCPは、ループバック・モードで使用する必要があります。詳細は、『Oracle Fusion Middlewareのインストールのプランニング』を参照してください。

- IPアドレスの変更のみがサポートされています。ホスト名は変更できません。

- DHCPモードでは、デフォルトのホスト名(localhost.localdomain)は使用しないでください。標準のホスト名を使用するようにホストを設定します。ループバックIPアドレスからそのホスト名に解決する必要があります。

この項では、次の項目について説明します。

- 静的IPアドレスからDHCPへの切替え

- DHCPから静的IPアドレスへの切替え

15.4.1 静的IPアドレスからDHCPへの切替え

ホストの設定を静的IPアドレスからDHCPに変更する手順は次のとおりです。

1. ホストをDHCPに変更する前に、ホスト名とループバックIPアドレスを関連付けてホストを構成します。

2. ホストをDHCPに変更します。Oracle Fusion Middlewareを更新する必要はありません。

15.4.2 DHCPから静的IPアドレスへの切替え

ホストの設定をDHCPから静的IPアドレスに変更する手順は次のとおりです。

1. ホストが静的IPアドレスを使用するように変更します。

2. Oracle Fusion Middlewareを更新する必要はありません。

15.5 IPv6の使用

Oracle Fusion Middlewareでは、インターネット・プロトコル・バージョン4 (IPv4)およびインターネット・プロトコル・バージョン6 (IPv6)がサポートされます。特にIPv6 (128ビット)では、IPv4 (32ビット)と比較してサポートされるアドレス空間が大きいため、Web上でアドレス指定可能なコンピュータの数が幾何級数的に増加しています。

IPv6のアドレスは、8つに区切られた4桁の16進数で表します。次に例を示します。

2001:0db8:85a3:08d3:1319:8a2e:0370:7334

Oracle Fusion MiddlewareコンポーネントによるIPv6サポートの詳細は、Oracle Fusion Middlewareのシステム要件と仕様を参照してください。

ほとんどのコンポーネントはIPv6をサポートしています。Oracle Fusion Middlewareの特定のコンポーネントのIPv6への構成の詳細は、次のトピックを参照してください。

- Oracle HTTP ServerでIPv6を使用する場合の構成

- Oracle SOA SuiteおよびFusion Middleware Controlでのデュアル・スタックの使用

15.5.1 Oracle HTTP ServerでIPv6を使用する場合の構成

IPv6を使用して通信を行うようにOracle HTTP Serverを構成するには、次のディレクトリにある構成ファイルを変更します。

(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_name
(Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\ohs_name

たとえば、IPv6を使用しているホスト上のOracle WebLogic Serverと、Oracle HTTP Serverが通信するように構成するには、mod_wl_ohsを構成します。次のディレクトリにある構成ファイルを編集します。

DOMAIN_HOME/config/fmwconfig/components/OHS/instances/ohs1

これらの構成ファイルで、次のいずれかのパラメータを使用して、解決可能なホスト名またはIPv6アドレスを指定します。

WebLogicHost hostname | [IPaddress]
WebCluster [IPaddress_1]:portnum1, [IPaddress_2]:portnum2, [IPaddress_3]:portnum3, ...

IPv6アドレスは大カッコで囲む必要があります。

エラーはすべてOracle HTTP Serverのログに記録されます。詳細情報を生成するには、mod_weblogicディレクティブにDebug AllおよびWLLogFileパスを設定します。Oracle HTTP Serverはモジュール固有のメッセージを記録します。

注意:
Oracle HTTP Serverの以前のバージョンでは、IPv6ノードが含まれる動的クラスタを使用する場合に制限がありました。たとえば、Oracle WebLogic Server用のOracle HTTP Serverプラグインでは、IPv6サポートが制限されていました。この制限により、プラグインのDSL(動的サーバー・リスト)機能がサポートされていませんでした。つまり、サーバー・リストの静的構成(DynamicServerList=OFF)のみがサポートされていました。これらの制限は解消されています。

15.5.2 Oracle SOA SuiteおよびFusion Middleware Controlでのデュアル・スタックの使用

Oracle SOA Suiteでは、デュアル・スタック構成がサポートされています。ただし、Fusion Middleware ControlをOracle SOA Suiteとともに使用する場合は、次のファイル内でプロトコルを指定する必要があります。そうしないと、Fusion Middleware Controlが正しく機能しないことがあります。

DSOMAIN_HOME/bin/startWebLogic.sh

ファイル内の${DOMAIN_HOME}/bin/setDomainEnv.sh行の後ろに、IPプロトコルを指定して次の行を追加します。

$DOMAIN_HOME/bin  JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.net.preferIPv4Stack=true"

第VII部

高度な管理: バックアップとリカバリ

バックアップとリカバリとは、ハードウェア障害およびデータの損失に備え、損失が発生した場合にデータを再構成するための様々な戦略および手順を意味します。この部では、Oracle Fusion Middlewareのバックアップおよびリカバリ方法について説明します。

次の章で構成されます。

- 第16章「バックアップとリカバリの概要」

- 第17章「環境のバックアップ」

- 第18章「環境のリカバリ」

16 バックアップとリカバリの概要

この章では、Oracle Fusion Middlewareのバックアップおよびリカバリの概要(Oracle Fusion Middlewareコンポーネントに関するバックアップおよびリカバリの推奨事項を含む)について説明します。

内容は次のとおりです。

- Oracle Fusion Middlewareのバックアップとリカバリの理解

- Oracle Fusion Middlewareのディレクトリ構造

- バックアップおよびリカバリで使用するツール

- Oracle Fusion Middlewareコンポーネントのバックアップおよびリカバリに関する推奨事項

- 前提と制限

16.1 Oracle Fusion Middlewareのバックアップとリカバリの理解

An Oracle Fusion Middleware環境は、様々なコンポーネントおよび構成で成り立ちます。通常のOracle Fusion Middleware環境は、Oracle SOA SuiteなどのJavaコンポーネントが含まれるOracle WebLogic Serverドメイン、およびIdentity Managementコンポーネントが含まれるWebLogic Serverドメインで構成されます。

Oracle Fusion Middleware環境内のインストールでは、構成情報、アプリケーションおよびデータの同期が保たれ、相互に依存します。たとえば、構成を変更すると、構成ファイル内の情報が更新されます。アプリケーションをデプロイすると、ドメインまたはクラスタ内のすべての管理対象サーバーへのデプロイが必要な場合があります。

したがって、バックアップおよびリカバリを実行するときは、Oracle Fusion Middleware全体の環境を考慮することが重要になります。Oracle Fusion Middleware環境全体を一度に、その後定期的にバックアップしてください。そうすれば、ファイルやデータなどが失われた場合でも、環境を一貫性のある状態にリストアできます。

次の各項目では、バックアップとリカバリを理解するために重要な概念について説明します。

- 管理サーバーで発生した障害の影響

- 管理対象サーバーの独立(MSI)モード

- 管理対象サーバーでの構成の変更

関連項目:
Oracle WebLogic Serverドメイン、管理サーバー、管理対象サーバーとクラスタ、およびノード・マネージャの概念の詳細は、『Oracle Fusion Middlewareコンセプトの理解』を参照してください。

16.1.1 管理サーバーで発生した障害の影響

管理サーバーで発生した障害が、ドメイン内の管理対象サーバーの操作に影響を与えることはありませんが、管理者がドメインの構成を変更できなくなります。管理サーバーのホスト・コンピュータ上のハードウェアまたはソフトウェアの障害が原因で管理サーバーに障害が発生した場合は、同じコンピュータ上のその他のサーバー・インスタンスが同様に影響を受けることがあります。

管理対象サーバー・インスタンス(クラスタ化されているものも、そうでないものも)が実行されている場合に、そのドメインの管理サーバーが使用できなくなっても、管理対象サーバーは継続して実行されます。周期的に、これらの管理対象サーバーは管理サーバーへの再接続を試みます。クラスタ化された管理対象サーバー・インスタンスでは、ドメイン構成でサポートされているロード・バランシングおよびフェイルオーバーの機能を引き続き使用できます。

管理対象サーバーを初めて起動する場合は、管理サーバーに接続して構成のコピーを取得する必要があります。これで、管理サーバーが実行されていない場合でも、管理対象サーバーを起動できます。この場合、管理対象サーバーでは、起動構成用にドメインの構成ファイルのローカル・コピーが使用され、周期的に管理サーバーとの接続が試行されます。管理サーバーに接続されると、管理対象サーバーの構成状態が管理サーバーの構成状態に同期されます。

16.1.2 管理対象サーバーの独立(MSI)モード

管理対象サーバーでは、ドメイン構成のローカル・コピーが保持されます。管理対象サーバーは、起動時に管理サーバーに接続し、管理対象サーバーが前回停止してからドメイン構成に変更が行われた場合は、その変更を取得します。管理対象サーバーが起動時に管理サーバーに接続できない場合は、ローカルにキャッシュされている構成情報を使用できます。これは、管理対象サーバーが前回停止した時点での構成です。管理サーバーに接続して構成の更新を確認できずに起動した管理対象サーバーは、管理対象サーバーの独立(MSI)モードで実行されます。デフォルトでは、MSIモードが有効になっています。ただし、初めて起動する場合は、管理サーバーが停止しているとキャッシュされた構成を使用できないため、管理対象サーバーはMSIモードでも起動できません。

16.1.3 管理対象サーバーでの構成の変更

構成の変更は、次の場合に管理対象サーバーで更新されます。

- 管理対象サーバーが再起動するたびに、管理サーバーから最新の構成が取得されます。これは、その管理対象サーバーが実行されているノードのノード・マネージャが停止している場合でも行われます。管理対象サーバーの再起動時に管理サーバーが使用できない場合、およびMSI(管理対象サーバーの独立)モードが管理対象サーバーで有効になっている場合は、管理対象サーバーは構成のローカル・コピーを読み取って起動し、管理サーバーが使用可能になったときに管理サーバーと同期します。デフォルトでは、MSIモードが有効になっています。

- 構成の変更、アプリケーションのデプロイまたは再デプロイ、トポロジの変更など、管理上の変更がアクティブ化されるたびに、管理サーバーから管理対象サーバーに最新の構成がプッシュされます。管理対象サーバーが実行されていない場合は、管理対象サーバーが起動したときに、管理サーバーから管理対象サーバーに最新バージョンの構成がプッシュされます。

16.2 Oracle Fusion Middlewareのディレクトリ構造

次に、Oracle Fusion Middleware Infrastructureをインストールした場合のOracle Fusion Middlewareのディレクトリ構造の簡易ビューを示します。

16.3 バックアップおよびリカバリで使用するツール

Oracle Fusion Middleware環境のバックアップまたはリカバリに使用できるものは、次のとおりです。

- copy、xcopy、tar、jarなどのファイル・コピー用ユーティリティ。ユーティリティでは、次のことを確認してください。

- シンボリック・リンクが保持されること

- 長いファイル名がサポートされること

- ファイルの権限、タイムスタンプおよび所有権が保持されること

ファイルをバックアップおよびリストアする場合は、それに適したツールを使用します。次に例を示します。

- Windowsでのオンライン・バックアップおよびリカバリには、copyまたはxcopyを使用し、オフライン・バックアップおよびリカバリには、copy、xcopyまたはjarを使用します。長いファイル名や拡張子には対応していないため、Winzipは使用しないでください。
一部のバージョンのWindowsでは、ファイル名が256文字を超えていると失敗します。この問題が発生しないようにするには、次のスイッチを指定したxcopyコマンドを使用できます。

xcopy /s/e  "C:\Temp\*.*"  "C:\copy"

構文と制限の詳細は、xcopyのヘルプを参照してください。

- LinuxおよびUNIXの場合はtarを使用します。

長期間バックアップを保持する場合は、たとえばOracle Secure Backupを使用して、テープにバックアップできます。

- Oracle Fusion Middlewareで使用されるデータベース・ベースのメタデータ・リポジトリとすべてのデータベースのバックアップまたはリカバリに使用するOracle Recovery Manager (RMAN)。RMANでは、全体バックアップまたは増分バックアップを実行できます。RMANを使用したデータベースのバックアップおよびリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

構成ファイルのバックアップ・コピーを作成するようにOracle WebLogic Serverを構成することもできます。これによって、構成の変更を元に戻す必要がある場合や、ほとんど可能性はなくとも構成ファイルが破損した場合のリカバリが簡単になります。管理サーバーの起動時に、構成ファイルを格納したconfig-booted.jarという名前の.jarファイルが保存されます。構成ファイルを変更した場合、変更前のファイルは、ドメイン・ディレクトリの下のconfigArchiveディレクトリに、config-1.jarなどの続き番号が付けられた.jarファイルとして保存されます。ただし、構成アーカイブは常に、管理サーバー・ホストのローカルとして保存されます。アーカイブは外部の場所にバックアップすることをお薦めします。

16.4 Oracle Fusion Middlewareコンポーネントのバックアップおよびリカバリに関する推奨事項

表16-1では、各Oracle Fusion Middlewareコンポーネントにおいて、バックアップおよびリカバリする必要がある項目について説明します。次の点に注意してください。

- コンポーネントに、表に示されているデータベースへの依存性が存在する場合は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』の説明に従い、RMANを使用してデータベースのバックアップおよびリカバリを実行します。

- バックアップの場合は、第17.3項の説明に従って、表に示されているエンティティをバックアップします。

- リカバリの場合は、失敗した項目に応じて、第18章の説明に従って、次の項目をリカバリする必要があります。

- ドメイン: 一部のコンポーネントでは、WebLogic Serverドメイン(第18.2.2項を参照)またはスタンドアロン・ドメイン(第18.2.3項を参照)のいずれか

- 管理サーバーの構成: 第18.2.4項を参照

- 管理対象サーバー: 第18.2.5項を参照

- クラスタ: 第18.2.7項を参照

- アプリケーション: 第18.2.8項を参照

- コンポーネントに関連するスキーマが含まれるデータベース。第18.2.9項を参照してください。

ホストの破損後には、次のリカバリが必要になることがあります。

- ドメイン: 一部のコンポーネントでは、WebLogic Serverドメイン(第18.3.1項を参照)またはスタンドアロン・ドメイン(第18.3.2項を参照)のいずれか

- 管理サーバー・ホスト: 第18.3.3項を参照

- 管理対象サーバー・ホスト: 第18.3.4項を参照

- コンポーネントに関連するスキーマが含まれるデータベース。第18.3.7項を参照してください。

表16-1では、Oracle Fusion Middlewareコンポーネントでのバックアップとリカバリの推奨事項について説明します。

表16-1 バックアップとリカバリの推奨事項

コンポーネント

データベースへの依存性

バックアップに関する推奨事項

リカバリに関する推奨事項

追加情報

Oracle B2B

MDSスキーマ

Oracle B2B構成ファイルに変更が行われた場合は、管理サーバー・ドメイン・ディレクトリ、Oracleホームおよび製品ホーム

管理対象サーバー

Xengine.tar.gzファイルの詳細は、第18.2.6.2項を参照してください。

Oracle BI EE

MDSスキーマおよびBIPLATFORMスキーマ

管理対象サーバーを含むOracleホーム、ドメイン・ホーム。

失敗したエンティティ

リカバリするには、第18.2.6.5項を参照してください。ホストの破損からリカバリするには、第18.3.5.8項を参照してください。

Oracle BPEL Process Manager

MDSスキーマおよびSOAINFRAスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

ドメイン・ホームおよび管理対象サーバー

データベースのバックアップおよびリカバリの詳細は、第16.4.2項を参照してください。

Oracle Business Activity Monitoring

MDSスキーマおよびSOAINFRAスキーマ

Oracleホーム、管理サーバー・ドメイン・ディレクトリ、管理対象サーバー・ディレクトリ。

障害の程度に応じて、管理対象サーバーとOracleホームのいずれかまたは両方

NA

Oracle Business Intelligence Publisher

BIPLATFORMスキーマ

Oracleホーム、ドメインおよびBI Publisherリポジトリ(データベースまたはファイルベースのいずれか)。

ドメイン・ホームおよび管理対象サーバー

ホストの破損からリカバリするには、第18.3.5.8項を参照してください。

バックアップ・アーティファクトが別の時点からリストアされると、ユーザー・アカウント、ユーザー・レポートおよび権限は、リストアされたバージョンに戻ります。すべてのアーティファクトを同じ時点からリストアします。

Oracle Business Process Management

MDSスキーマ

管理サーバー・ドメイン・ディレクトリおよびOracle BPEL Process Managerと同じデータ(第16.4.2項を参照)。

Oracle BPEL Process Managerと同じデータおよび管理対象サーバー

NA

Oracle Business Rules

MDSスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

soa-infraアプリケーションがデプロイされている管理対象サーバー

NA

Oracle Data Integrator

ODI_REPOスキーマ

Oracleホーム、Oracle Data Integratorがドメインにインストールされている場合はドメイン、およびスタンドアロン・エージェントがインストールされている各マシンのODI_Oracle_Home/oracledi/agentフォルダ

管理対象サーバーとOracleホームのいずれかまたは両方。

環境にOracle Data Integratorスタンドアロン・エージェントまたは開発者向けOracle Data Integratorが含まれている場合は、第18.2.1項の説明に従ってOracleホームをリストアします。

環境に管理対象サーバーにデプロイされたOracle Data Integratorが含まれている場合は、第18.2.5項の説明に従って管理対象サーバーをリストアします。

ホストの破損からリカバリするには、第18.3.5.10項を参照してください。

Oracle Data Service Integrator

MDSスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

管理サーバー・ドメイン

NA

Oracle Enterprise Scheduler

ESSスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

失敗したエンティティ

NA

Oracle Event Processing

MDSスキーマ(.cqlxファイルを1つのMARにパッケージ化して格納)

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

管理対象サーバー

NA

Oracle Forms Services

Oracle Forms Servicesアプリケーション用にユーザーが構成したデータベース。

Oracle Forms Servicesが存在する管理サーバーのドメイン、管理対象サーバーのディレクトリおよびドメイン・ディレクトリ。

Oracle Forms Servicesが存在するドメイン・ディレクトリ。

ホストの破損からリカバリするには、第18.3.5.6項を参照してください。

Oracle HTTP Server

なし

Oracleホームおよびドメイン(スタンドアロン・ドメインまたはOracle WebLogic Serverドメインのいずれか)。

管理サーバー・ドメイン・ディレクトリ

NA

Oracle Managed File Transfer

MFTスキーマおよびMDSスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

失敗したエンティティ

NA

Oracle Mediator

MDSスキーマおよびSOAINFRAスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

soa-infraアプリケーションがデプロイされている管理対象サーバー

NA

Oracle Platform Security Services

データベース・ベースのOracle Platform Securityリポジトリを使用する場合は、OPSSスキーマ。Oracle Internet Directoryベースのリポジトリを使用する場合は、Oracle Internet Directoryリポジトリ。

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ。

Oracle Platform SecurityでOracle Internet Directoryベースのリポジトリを使用する場合は、Oracle Internet Directoryをバックアップします。

第18.2.6.1項にリストされているファイル。

NA

Oracle Real-Time Decisions

分析モデルおよびRTDスキーマが含まれるデータベース

Oracleホーム、ドメイン・ホーム、および分析モデルが含まれるデータベース

管理対象サーバー

バックアップ・アーティファクトが別の時点からリストアされると、分析モデルで学習期間が失われますが、インテリジェント機能には影響しません。

Oracle Reports

ジョブ関連の情報が含まれるデータベース

Oracle Reportsが存在する管理サーバーのドメインおよび管理対象サーバーのディレクトリ

Oracle Reportsが存在する管理サーバーのドメインおよび管理対象サーバーのディレクトリ。

ホストの破損からリカバリするには、第18.3.5.7項を参照してください。

Oracle Service Bus

レポート機能が有効な場合、Oracle Service Busは、ユーザー指定のスキーマにWLI_QS_REPORT_DATAおよびWLI_QS_REPORT_ATTRIBUTEという2つの表を作成します。

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

管理対象サーバー

NA

Oracle SOA Suite

MDSスキーマおよびSOAINFRAスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

失敗したエンティティ

ホスト破損の詳細は、第18.3.5.4項を参照してください。

データベースのバックアップおよびリカバリの詳細は、第16.4.2項を参照してください。

Oracle User Messaging Service

UMSスキーマ

Oracleホームおよびドメイン(スタンドアロン・ドメインまたはOracle WebLogic Serverドメインのいずれか)。

ドメイン(スタンドアロン・ドメインまたはOracle WebLogic Serverドメインのいずれか)

第18.3.5.5.1項または第18.3.5.5.2項の説明に従って、構成変更を実行します。

Oracle Web Services Manager

データベース・ベースのMDSリポジトリを使用する場合は、MDSスキーマ。

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ。

Oracle WSMでファイルベースのMDSリポジトリが使用されている場合は、ファイル・コピー・メカニズムを使用してバックアップします。

管理対象サーバー

Oracle WSMでファイルベースのMDSリポジトリが使用されている場合は、バックアップからリストアします。

NA

Oracle WebCenter Capture

CAPTUREスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

失敗したエンティティ

NA

Oracle WebCenter Content

OCSスキーマ

ドメインおよびOracleホーム

ドメイン・ディレクトリにVaultディレクトリもWebLayoutディレクトリも配置されていない場合は、次のファイルで指定されているそれらのディレクトリをバックアップします。

DOMAIN_HOME/ucm/CONTEXT-ROOT/config/config.cfg

次のディレクトリもバックアップします。これは、共有ファイル・システムに配置されています。

DOMAIN_HOME/ucm/CONTEXT-ROOT/config

障害の重大度に応じて、ドメインと、VaultディレクトリおよびWebLayoutディレクトリが含まれる共有ファイル・システム。

リカバリするには、第18.2.6.4項を参照してください。ホストの破損からリカバリするには、第18.3.5.11項を参照してください。

Oracle WebCenter Content: Records

OCSスキーマ

Oracle WebCenter Contentに依存し、他のバックアップ・アーティファクトはありません

Oracle WebCenter Contentに依存し、他のリカバリ・アーティファクトはありません

NA

Oracle WebCenter Content: Inbound Refinery。

なし

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ。ユーザー・データがドメイン・ディレクトリ内にない場合は、データをバックアップします。

失敗したエンティティユーザー・データをリカバリする必要がある場合は、リカバリします。

NA

Oracle WebCenter Portal

MDSおよびWEBCENTERスキーマ

管理サーバー・ドメイン

管理サーバー・ドメイン

NA

Oracle WebCenter Portalの分析データ

ACTIVITIESスキーマおよびMDSスキーマ

Oracleホームおよびドメイン・ホーム

Oracleホームおよびドメイン・ホーム。

NA

Oracle WebCenter Portalのディスカッション・サーバー

DISCUSSIONSスキーマ

管理サーバー・ドメイン

管理サーバー・ドメイン

NA

Oracle WebCenter Portalのポートレット・プロデューサ

PORTLETスキーマ

管理サーバー・ドメイン

管理サーバー・ドメイン

NA

Oracle WebCenter Sites

WCSITESスキーマ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ。WebCenter Sitesの構成ファイルがOracleホーム・ディレクトリの外部に存在する場合、これらファイルもバックアップします。

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ。WebCenter Sitesの構成ファイルがOracleホーム・ディレクトリの外部に存在する場合、これらファイルもリストアします。

NA

Oracle WebLogic Server

デフォルトでは、いずれのデータベース・リポジトリにも依存しません。ただし、Oracle WebLogic Serverにデプロイされたアプリケーションでは、データ・ソースとしてデータベースが使用される場合があります。

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

失敗したエンティティ

サーバー全体の移行を使用する場合は、第18.2.2.1項を参照してください。

Oracle WebLogic Server JMS

JMSがデータベース・ベースの場合のみ

Oracleホームおよび管理サーバー・ドメイン・ディレクトリ

失敗したエンティティ

第16.4.1項を参照してください。

16.4.1 Oracle WebLogic Server JMSのバックアップとリカバリの推奨事項

ファイル・ベースのJMSを使用している場合は、ストレージのスナップショット技術を使用して一貫性のあるオンライン・バックアップを取ります。または、ファイル・システムのコピーを使用してオフライン・バックアップを実行することもできます。

JMS永続ストアがファイルベースの場合は、バックアップからリカバリします。JMS永続ストアがデータベース・ベースの場合は、必要に応じて、データベースを直近の時点にリカバリします。次の点に注意してください。

- JMSデータは常に、できるだけ最新に保つようにします。これを実現するには、データベース・ベースの永続性を確保する場合はOracle Databaseのポイント・イン・タイム・リカバリ機能を使用して直近の時間にリカバリするか、またはSAN/NASなど可用性の高いRAID対応ストレージ・デバイスを使用します。

- ファイル・ベースのJMSを使用している場合は、ストレージのスナップショットを使用してリカバリできます。

- どのような理由であれ、JMSデータを前の時点にリストアする必要がある場合、リストアによって影響が及ぶ可能性があります。システムの状態を前の時点にリストアすると、メッセージを複製する可能性だけでなく、メッセージを失う可能性もあります。この場合に失われたメッセージは、システムのリストア時点の前または後にエンキューされていた未処理のメッセージです。
重複メッセージを処理しないようにするには、リカバリの前に次の手順を実行して、永続ストアのリカバリ後にJMSキュー内のメッセージを排出する必要があります。

注意:
メッセージを排出および破棄する前に、保存の必要なデータがメッセージに含まれていないことを確認してください。リカバリしたメッセージには、処理済の重複メッセージの他に、重要なアプリケーション・データが含まれる未処理のメッセージが含まれている可能性があります。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 新しいメッセージが生成されたり宛先に挿入されたりしないように、また失効したメッセージを排出する前に宛先から消費されないようにするため、リカバリの前に、起動時の生成、挿入、消費の各操作を休止するようにJMSサーバーを構成します。これを行うには:

1. 「サービス」を開いてから「メッセージング」を開き、「JMSサーバー」をクリックします。

2. 「JMSサーバー」ページの「サマリー」で、メッセージを休止するように構成するJMSサーバーをクリックします。

3. 「構成: 全般」ページで「詳細」をクリックして、メッセージの休止オプションを定義します。「起動時に挿入を休止」、「起動時に生成を休止」および「起動時に消費を休止」を選択します。

4. 「保存」をクリックします。

リカバリ後に実行する手順は次のとおりです。

1. 永続ストアのリカバリ後に、管理対象サーバーを起動します。

2. 次の手順を実行して、失効したメッセージをJMS宛先から排出します。

1. 「サービス」を開いてから「メッセージング」を開き、「JMSモジュール」を開きます。

2. JMSモジュールを選択して、ターゲットを選択します。

3. 「モニタリング」を選択して、「メッセージの表示」を選択します。

3. 「すべて削除」をクリックします。

4. 次の手順を実行して、操作を再開します。

1. 「サービス」を開いてから「メッセージング」を開き、「JMSサーバー」を開きます。

2. 「JMSサーバー」ページの「サマリー」で、メッセージを休止するように構成するJMSサーバーをクリックします。

3. 「構成: 全般」ページで「詳細」をクリックします。「起動時に挿入を休止」、「起動時に生成を休止」および「起動時に消費を休止」を選択解除します。

4. 「保存」をクリックします。

永続ストアがJMS専用でない場合は、Oracle WebLogic Server JMSメッセージ管理ツールを使用します。このツールでは、操作のインポート、エクスポート、移動および削除を、管理コンソール、MBeanおよびWLSTから実行できます。

キューイングの他に、パブリッシュおよびサブスクライブも使用するアプリケーションの場合は、キューに加えてトピック・サブスクリプションを操作する必要があります。

16.4.2 Oracle BPEL Process Managerのバックアップおよびリカバリに関する推奨事項

グローバル・フォルト・ポリシー、ワークフローのコールバック・クラス、スーツケースの外部にある可能性のあるリソース・バンドルに対する変更など、構成に変更があった場合はその変更後にデータベースをバックアップします。また、データベースは、新しいコンポジットのデプロイまたはコンポジットの再デプロイの後にもバックアップします。

必要に応じて、データベースを直近の時点にリカバリします。ポイント・イン・タイム・リカバリを使用すると、最新のプロセス定義および進行中のインスタンスがリストアされます。ただし、これによってプロセスの手順が再実行される場合があります。できるかぎり、Oracle BPEL Process Managerの冪等プロセスを使用することをお薦めします。冪等以外のプロセスがシステムに含まれている場合は、それらをデハイドレーション・ストアからクリーンアップしてからOracle Fusion Middlewareを起動する必要があります。詳細は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理を参照してください。

インスタンスでは、プロセス定義とアーティファクトがすべてデータベースから取得されるため、データベースを最新の状態にリカバリした後で構成をリカバリする必要はありません。インスタンスは、引き続き正常に機能します。

再デプロイしたコンポジットの場合、データベースのリカバリによって、デハイドレーションされた進行中のプロセスとそれに対応する定義との整合性が確保されます。これは、デハイドレーションされたインスタンスも格納されているデータベース・リポジトリにプロセス定義が格納されているためです。

16.5 前提と制限

次の前提と制限は、このマニュアルに記載されているバックアップおよびリカバリ手順に適用されます。第17.2項に一覧表示されている制限も参照してください。

- バックアップおよびリカバリの操作は、製品をインストールするユーザーまたはOracle Fusion Middlewareがインストールされているディレクトリへのアクセス権限を持つユーザーのみが実行可能である必要があります。

- 1つの管理対象サーバーと管理サーバーが別々のホスト上で実行されていて、その管理対象サーバーがクラスタに属していない場合、管理対象サーバーでpackコマンドおよびunpackコマンドを使用して、適切な構成を取得する必要があります。
Cold Failover ClusterまたはDisaster Recoveryを使用している場合、詳細は、Disaster Recoveryガイドを参照してください。

17 環境のバックアップ

この章では、Oracle Fusion Middlewareの推奨されるバックアップ戦略およびその手順について説明します。

この章の内容は次のとおりです。

- バックアップ計画の概要

- データのバックアップに関する制限事項

- バックアップの実行

- Oracle Fusion Middleware構成の記録の作成

17.1 バックアップ計画の概要

バックアップ戦略によりデータを保護しておくと、後に実データの損失などの重大な障害からのリカバリが可能になります。次の各項目では、バックアップ戦略について説明します。

- バックアップのタイプ

- バックアップ・アーティファクト

- 推奨されるバックアップ戦略

17.1.1 バックアップのタイプ

Oracle Fusion Middleware環境は、オフラインまたはオンラインでバックアップできます。

- オフライン・バックアップとは、環境を停止してからファイルをバックアップする必要があることを意味します。オフライン・バックアップを行う場合は、管理サーバーとドメイン内のすべての管理対象サーバーを停止する必要があります。

- オンライン・バックアップとは、環境を停止せずにファイルをバックアップすることを意味します。バックアップの矛盾を防ぐために、バックアップが完了するまでは、いずれの構成も変更しないでください。WebLogic Serverドメインで変更が行われないようにするには、第2.2.5項で説明しているようにWebLogic Serverの構成をロックします。

Oracle Fusion Middleware環境全体をバックアップすることも、頻繁に変更されるファイルであるランタイム・アーティファクトをバックアップすることもできます。

全体バックアップを実行するには、静的ファイルおよび静的ディレクトリとともに、ランタイム・アーティファクトをバックアップする必要があります。これらについては、第17.1.2項で説明します。

17.1.2 バックアップ・アーティファクト

バックアップ・アーティファクトには、静的ファイルや静的ディレクトリ、およびランタイム・アーティファクトが含まれます。

静的ファイルや静的ディレクトリは、頻繁に変更されるものではありません。これらには、次のものがあります。

- Oracleホーム(ORACLE_HOME)。Oracleホームは、WebLogic ServerホームやOracle共通ホームなどの製品ホームで構成され、製品バイナリが含まれています。
また、推奨されてはいませんが、静的ファイルではないOracle WebLogic Serverドメインを格納したuser_projectsディレクトリが含まれる場合もあります。

- OraInventory

- LinuxおよびUNIXの場合はoraInst.locファイル。これは、次のディレクトリにあります。

(Linux and IBM AIX) /etc
(Other UNIX systems) /var/opt/oracle

- LinuxおよびUNIXの場合はoratabファイル。これは、次のディレクトリにあります。

/etc

- beahomelistファイル。これは、次の場所にあります。

(UNIX) user_home/bea/beahomelist
(Windows) C:\bea\beahomelist

- Windowsの場合は次のレジストリ・キー。

HKEY_LOCAL_MACHINE\Software\oracle

また、Oracle HTTP Serverなどのシステム・コンポーネント用に、次のWindowsレジストリ・キーをバックアップする必要があります。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

ランタイム・アーティファクトは頻繁に変更されるファイルです。これらのファイルは、全体バックアップの実行時、および定期的にバックアップします。ランタイム・アーティファクトには、次のものがあります。

- 管理サーバーおよび管理対象サーバーのドメイン・ディレクトリ。
ほとんどの場合、管理対象サーバーのディレクトリを個別にバックアップする必要はありません。管理サーバーのドメインには管理対象サーバーすべてに関する情報が格納されているためです。

- .earファイルや.warファイルなど、ドメインの外にあるアプリケーション・アーティファクト。
管理対象サーバーのディレクトリ構造のアプリケーション・アーティファクトは、管理対象サーバーの起動時に管理サーバーから取得できるため、バックアップする必要はありません。

- Oracle Fusion Middlewareが使用する、データベース・ベースのメタデータ・リポジトリ。

- JMSプロバイダやトランザクション・ログなどの永続ストア。

17.1.3 推奨されるバックアップ戦略

この項では、バックアップの実行に際し推奨される戦略について説明します。この戦略に従って、このマニュアルで説明するリカバリ手順を実行することができます。

- オフラインの全体バックアップの実行: これには、第17.1.2項で説明しているエンティティのバックアップも含まれます。オフラインの全体バックアップは、次の時点で実行します。

- Oracle Fusion Middlewareのインストール直後

- Oracle Fusion Middleware環境のパッチ適用またはアップグレードの直前

- オペレーティング・システムをアップグレードする直前

- Oracle Fusion Middlewareのアップグレードまたはパッチ適用直後

全体バックアップの実行の詳細は、第17.3.1項を参照してください。

- ランタイム・アーティファクトのオンライン・バックアップの実行: これには、第17.1.2項で説明しているランタイム・アーティファクトのバックアップも含まれます。ランタイム・アーティファクトをバックアップすることにより、構成とメタデータを最後にバックアップした時点の一貫性のある状態に環境をリストアすることができます。バックアップの矛盾を防ぐために、バックアップが完了するまでは、いずれの構成も変更しないでください。ランタイム・アーティファクトのオンライン・バックアップは、次の時点で実行します。

- 管理上の変更が行われた直後および定期的。ランタイム・アーティファクトのバックアップは夜間に行うことをお薦めします。

- コンポーネントに対して構成の変更を行う前。

- コンポーネントに対して構成の変更を行った後。

- 管理対象サーバーまたはクラスタにカスタムのJava EEアプリケーションをデプロイする前。

- サーバーやクラスタの作成など、デプロイメント・アーキテクチャに対して大きな変更が行われた後。

ランタイム・アーティファクトのバックアップの実行の詳細は、第17.3.2項を参照してください。

オンライン・バックアップを実行する場合、バックアップが完了するまでは、いずれの構成も変更しないでください。WebLogic Serverドメインで変更が行われないようにするには、第2.2.5項で説明しているようにWebLogic Serverの構成をロックします。

- アップグレードやパッチの適用、次のいずれかのファイルの変更など、大きな変更を行った後には、新たな全体バックアップを実行します。

DOMAIN_HOME/nodemanager/nodemanager.properties
ORACLE_HOME/wlserver/common/bin/wlsifconfig.sh
ORACLE_HOME/wlserver/common/bin/setPatchEnv.sh
ORACLE_HOME/wlserver/common/bin/commEnv.sh

全体バックアップの実行の詳細は、第17.3.1項を参照してください。

- データベースの全体バックアップまたは増分バックアップの実行: RMANを使用してデータベースをバックアップします。RMANの使用方法および推奨されるデータベースのバックアップ方法については、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

- Oracle Fusion Middleware環境の記録を作成します。第17.4項を参照してください。

- バックアップを作成したら、そのアーカイブ・ファイルに一意の名前を付けます。名前に日時を付加することを検討してください。たとえば、Oracleホームのバックアップを2014年6月5日に作成した場合は、そのバックアップに次の名前を付けます。

oracle_home_backup_06052014.tar

図17-1のフロー・チャートは、特定の状況に適したバックアップのタイプを判断する方法の概要を示しています。

図17-1 バックアップのタイプを判断するためのフロー・チャート

17.2 データのバックアップに関する制限事項

次の点に注意してください。

- LDAPバックアップ: 組込みのLDAPを使用する場合、LDAPデータのバックアップ中にセキュリティ・プロバイダの構成を更新しないでください。LDAPディレクトリ・ツリーのバックアップ中に変更があると(たとえば、管理者がユーザーを追加するなど)、ldapfilesサブディレクトリのバックアップにおいて一貫性が損なわれる場合があります。LDAPのバックアップ手順の詳細は、「WebLogic Server管理サーバーの起動と停止」を参照してください。

- Java Transaction API (JTA): JTAトランザクション・ログのバックアップおよびリストアはお薦めしません。

- Audit Framework:Oracle Fusion Middleware Audit Frameworkを、データベースにデータを書き込むように構成している場合は、バス・ストップ内のローカル・ファイルはバックアップしないでください(各コンポーネントから発生する監査対象イベントは、バス・ストップと呼ばれるリポジトリに格納されます。Oracle WebLogic Serverには、それぞれ独自のバス・ストップがあります。データはこのファイル内に永続的に置くか集中リポジトリにアップロードでき、集中リポジトリからは、レコードを表示したりレポート作成に使用したりできます。)
ローカル・ファイルをバックアップする場合、重複レコードがデータベースにアップロードされます。つまり、バス・ストップの作成時にデータベースにアップロードされ、その後ファイルをリストアしたときに再度アップロードされます。

バス・ストップのローカル・ファイルのデフォルトの場所は次のとおりです。

- Javaコンポーネントの場合:

DOMAIN_HOME/servers/server_name/logs/auditlogs/component_type

- Oracle HTTP Serverなどのシステム・コンポーネントの場合:

DOMAIN_HOME/auditlogs/component_type/component_name

Oracle Fusion Middleware Audit Frameworkおよびバス・ストップの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』の監査の構成および管理に関する項を参照してください。

- Oracle BI EEをバックアップする前に、Oracle BI Presentation Catalogをロックして、カタログとRPDの同期が確保されるようにする必要があります。次のスクリプトを実行します。

ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/coreapplication_obips1/catalogmanager/runcat.sh

以下のコマンドを使用します。

./runcat.sh -cmd maintenanceMode -on -online OBIPS_URL
-credentials credentials_properties_file

バックアップが完了したら、runcatコマンドを使用してメンテナンス・モードをオフにします。このコマンドの詳細は、次のようにヘルプを参照してください。

./runcat.sh -cmd maintenanceMode -help

17.3 バックアップの実行

次の各項の説明に従って、全体オフライン・バックアップまたはランタイム・アーティファクトのオンラインまたはオフライン・バックアップを実行できます。

- 全体オフライン・バックアップの実行

- ランタイム・アーティファクトのオンライン・バックアップの実行

- Windowsレジストリ・エントリのバックアップ

17.3.1 全体オフライン・バックアップの実行

全体オフライン・バックアップを行うには、Oracle Fusion Middlewareのファイルが含まれているディレクトリをコピーします。

第16.3項の説明に従って、アーカイブ用のツールを使用して、ソースOracleホームをアーカイブおよび圧縮します。

次の手順を実行します。

1. Oracleホームのすべてのプロセスをシャットダウンします。たとえば管理対象サーバー、管理サーバー、およびすべてのシステム・コンポーネントをシャットダウンします。

2. すべてのホストのOracleホーム(ORACLE_HOME)をバックアップします。次に例を示します。

(UNIX) tar -cf oracle_home_backup_06052014.tar ORACLE_HOME/*
(Windows) jar cMf oracle_home_backup_06052014.jar ORACLE_HOME\*

3. 管理サーバーのドメインは別にバックアップします。これにより、ドメインのJavaコンポーネントおよびすべてのシステム・コンポーネントがバックアップされます。
次に例を示します。

(UNIX) tar -cf domain_home_backup_06052014.tar DOMAIN_HOME/*
(Windows) jar cMf domain_home_backup_06052014.jar DOMAIN_HOME\*

ほとんどの場合、管理対象サーバーのディレクトリを個別にバックアップする必要はありません。管理サーバーのドメインには管理対象サーバーに関する情報が格納されているためです。管理対象サーバーの環境をカスタマイズしている場合は、管理対象サーバーのディレクトリをバックアップします。バックアップが必要なものの詳細は、第16.4項を参照してください。

4. 管理対象サーバーがドメイン内に見つからない場合は、管理対象サーバーのディレクトリをバックアップします。次に例を示します。

(UNIX) tar -cf mg1_home_backup_06052014.tar server_name/*
(Windows) jar cMf mgl_home_backup_06052014.jar server_name\*

5. アプリケーション・ホーム・ディレクトリをバックアップします。次に例を示します。

(UNIX) tar -cf app_home_backup_06052014.tar Applications_Home/domain_name/*
(Windows) jar cMf app_home_backup_06052014.jar Applications_Home\domain_name\*

6. OraInventoryディレクトリをバックアップします。次に例を示します。

tar -cf Inven_home_backup_06052014.tar /scratch/oracle/OraInventory

7. LinuxおよびUNIXの場合は、oraInst.locファイルをバックアップします。これは、次のディレクトリにあります。

(Linux and IBM AIX) /etc
(Other UNIX systems) /var/opt/oracle

8. LinuxおよびUNIXの場合は、oratabファイルをバックアップします。これは、次のディレクトリにあります。

/etc

9. Oracle Recovery Manager (RMAN)を使用して、データベース・リポジトリをバックアップします。詳細な手順は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

10. Windowsの場合は、第17.3.3項の説明に従って、Windowsレジストリ・エントリをエクスポートします。

11. 「構成の解放」をWebLogic Server管理コンソールでクリックして、WebLogic Server構成のロックを解除します。

12. Oracle Fusion Middleware環境の記録を作成します。第17.4項を参照してください。

17.3.2 ランタイム・アーティファクトのオンライン・バックアップの実行

ランタイム・アーティファクト(第17.1.2項を参照)のバックアップは、定期的に、また第17.1.3項で説明している時点で実行する必要があります。

ランタイム・アーティファクトをバックアップする手順は次のとおりです。

1. バックアップの矛盾を防ぐために、バックアップが完了するまでは、いずれの構成も変更しないでください。WebLogic Serverドメインで変更が行われないようにするには、第2.2.5項で説明しているようにWebLogic Serverの構成をロックします。

2. 管理サーバーのドメイン・ディレクトリをバックアップします。次に例を示します。

UNIX) tar -cf domain_home_backup_06052014.tar DOMAIN_HOME/*
(Windows) xcopy c:\DOMAIN_HOME e:\domain_home_backup_06052014 /s /e /i /h

Oracle ReportsおよびOracle Forms Servicesの場合は、管理サーバーのドメイン・ディレクトリ以外にも、管理対象サーバーのディレクトリをバックアップする必要があります。

3. アプリケーション・ホーム・ディレクトリをバックアップします。次に例を示します。

(UNIX) tar -cf app_home_backup_06052014.tar DOMAIN_HOME/*
(Windows) jar cMf app_home_backup_06052014.jar C:\oracle\applications\domain_name\*

4. Oracle Recovery Manager (RMAN)を使用して、データベース・リポジトリをバックアップします。詳細な手順は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

5. 「構成の解放」をWebLogic Server管理コンソールでクリックして、Oracle WebLogic Server構成のロックを解除します。

6. Oracle Fusion Middleware環境の記録を作成します。第17.4項を参照してください。

17.3.3 Windowsレジストリ・エントリのバックアップ

Windowsの場合、Oracle Fusion Middlewareに関連するWindowsレジストリ・キーをバックアップする必要があります。バックアップするキーは、インストールされているコンポーネントによって異なります。

キーをエクスポートするには、次のコマンドを使用します。

regedit /E  FileName Key

次のエントリをエクスポートします。

- すべてのコンポーネント向けに、次のレジストリ・キーをエクスポートします。

HKEY_LOCAL_MACHINE\Software\Oracle

- Oracle HTTP Serverなどのシステム・コンポーネントの場合は、次のレジストリ・キー内のOracleで始まる各ノードをエクスポートします。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services

次に例を示します。

regedit /E C:\oracleSMP.reg HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services

各キーには一意のファイル名を使用します。

- Oracle BI EEがインストールされている場合は、次のレジストリ・キーをエクスポートします。

HKEY_LOCAL_MACHINE\SOFTWARE\ODBC

例:

regedit /E C:\oracleregistry.reg HKEY_LOCAL_MACHINE\SOFTWARE\ODBC

キーのエクスポートにはレジストリ・エディタを使用することもできます。詳細は、レジストリ・エディタのヘルプを参照してください。

17.4 Oracle Fusion Middleware構成の記録の作成

Oracle Fusion Middleware環境のリストアおよびリカバリが必要な場合は、必要なすべての情報を入手し、対処することが重要です。これは、特にOracle Fusion Middleware環境全体(またはその一部)を新しいディスクまたはホストに再構成する必要があるような、ハードウェアの損失が発生した場合に当てはまります。

この項で説明されている情報を含む、Oracle Fusion Middleware環境の最新記録を維持管理する必要があります。この情報は、印刷物と電子形式の両方で保管してください。電子形式のデータは、Oracle Fusion Middleware環境とはまったく別のホストまたは電子メール・システム上に格納する必要があります。

Oracle Fusion Middlewareのハードウェアおよびソフトウェア構成の記録には、次のものが含まれます。

- 環境内のホストごとに次の情報が必要です。

- ホスト名

- 仮想ホスト名(存在する場合)

- ドメイン名

- IPアドレス

- ハードウェア・プラットフォーム

- オペレーティング・システムのリリース・レベルおよびパッチ情報

- Oracle Fusion Middlewareのインストールおよび構成に使用されるJDKのバージョンとそのパス

- 環境内のOracle Fusion Middlewareインストールごとに次の情報が必要です。

- インストール・タイプ(Oracle HTTP Serverなど)

- インストールが常駐するホスト

- Oracleホームを所有するオペレーティング・システム・ユーザーのユーザー名、ユーザーID番号、グループ名、グループID番号、環境プロファイルおよびシェル・タイプ(/etc/passwdおよび/etc/groupエントリ)

- Oracleホーム、Oracle共通ホーム、製品ホーム、Oracle WebLogic Serverドメイン・ホーム(Oracleホームのuser_projectsディレクトリに存在しない場合)のディレクトリ構造、マウント・ポイントおよびフルパス

- インストールで使用されるディスク領域の量

- インストールで使用されるポート番号

- Oracle Fusion Middlewareのインストールおよび構成に使用されるJDKのバージョンとそのパス

- コンポーネントのメタデータを格納しているデータベースに関して、次の情報が必要です。

- ホスト名

- データベースのバージョンとパッチ・レベル

- 基本言語

- 文字セット

- グローバル・データベース名

- SID

- リスニング・ポート

18 環境のリカバリ

この章では、Oracle Fusion Middlewareを様々なタイプの障害および停止(メディア障害またはホストの破損など)からリカバリするための推奨されるリカバリ戦略および手順について説明します。

この章の内容は次のとおりです。

- リカバリ戦略の概要

- データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

- ホストの破損後のリカバリ

18.1 リカバリ戦略の概要

リカバリ戦略により、実データの損失などの重大な障害からのリカバリが可能になります。損失のタイプにもよりますが、次のファイル・タイプのどのような組合せでもリカバリできます。

- Oracleソフトウェア・ファイル

- 構成ファイル

- Oracleシステム・ファイル

- Windowsレジストリ・キー

- アプリケーション・アーティファクト

Oracle Fusion Middleware環境のリカバリは、Oracle Fusion Middlewareがオフラインのときに実行できます。

次の各項目では、リカバリ戦略について説明します。

- リカバリのタイプ

- 推奨されるリカバリ戦略

18.1.1 リカバリのタイプ

Oracle Fusion Middleware環境は、部分的にまたは全体をリカバリできます。次のリカバリが可能です。

- Oracleホーム

- WebLogic Serverドメイン

- スタンドアロン・ドメイン

- 管理サーバー

- 管理対象サーバー

- Oracle SOA SuiteやOracle HTTP Serverなどのコンポーネント

- WebLogic Serverクラスタ

- デプロイ済アプリケーション

- データベース

18.1.2 推奨されるリカバリ戦略

この項では、ホストまたはディスクが再起動できず、永久に失われるような、実データの損失や破損、ホスト障害またはメディア障害などが関係する停止に対するリカバリ戦略の概要を示します。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。

注意:
この章に記載されている手順では、最後のバックアップ以降、管理上の変更は加えられていないことを前提としています。最後のバックアップ以降、管理上の変更が加えられている場合は、リカバリの完了後にそれらの変更を再適用する必要があります。

リカバリに関しては次の重要な点に注意してください。

- Oracle Fusion Middleware環境は、リカバリの実行中はオフラインにする必要があります。

- 必要なファイルを間違ってオーバーライドしないよう、バックアップからファイルをリストアする前に既存の重要なファイルおよびディレクトリの名前を変更してください。

- 1、2個のファイルのみが消失または破損しているように見える場合もありますが、1、2個のファイルのみをリストアするのではなく、ドメインなど要素全体のディレクトリ構造をリストアする必要があります。そうすることで、リカバリが成功する可能性が高くなります。

- ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合)。これは通常、データベースに障害が発生する直前の状態です。

- ファイルのリストア時に圧縮ファイルを解凍するには、第16.3項の説明に従って、それに適したツールを使用します。
使用しているツールが、ファイルの権限とタイムスタンプを保持することを確認してください。

環境をリカバリする場合は、正しい順序でエンティティをリカバリすることが重要です。

1. データベース(リカバリが必要な場合)。18.2.9項および18.3.7項を参照してください。

2. Oracleホーム(リカバリが必要な場合)。第18.2.1項を参照してください。

3. ドメイン全体(リカバリが必要な場合)。WebLogic Server管理対象ドメインのリカバリの詳細は、第18.2.2項および第18.3.1項を参照してください。スタンドアロン・ドメインのリカバリの詳細は、第18.2.3項を参照してください。

4. 管理サーバー(ドメインのリカバリが不要な場合)。18.2.4項および18.3.3項を参照してください。

5. 管理対象サーバー(管理対象サーバーが管理サーバードメイン・ディレクトリになく、リカバリが必要な場合)。18.2.5項および18.3.4項を参照してください。
Javaコンポーネントは、管理対象サーバーをリカバリする際にリカバリされます。システム・コンポーネントは、ドメインをリカバリする際にリカバリされます。一部の環境では、第18.2.6項および第18.3.5項で説明されている特定の手順を実行する必要があります。

6. コンポーネントによっては追加操作が必要なものがあります。それらは、表18-1で示した項で説明しています。

表18-1 特定のコンポーネントの追加のリカバリ手順

コンポーネント

データの損失、破損、メディア障害の場合

ホスト破損の場合

Oracle B2B

第18.2.6.2項

第18.2.6.2項

Oracle BI EE

第18.2.6.5項

同じホストにリカバリする場合は、追加手順は必要ありません。別のホストにリカバリする場合は、第18.3.5.8項を参照してください。

Oracle Business Intelligence Publisher

NA

同じホストにリカバリする場合は、追加手順は必要ありません。別のホストにリカバリする場合は、第18.3.5.9項を参照してください。

Oracle Data Integrator

NA

第18.3.5.10項

Oracle Forms Services

NA

同じホストにリカバリする場合は、追加手順は必要ありません。別のホストにリカバリする場合は、第18.3.5.6項を参照してください。

Oracle HTTP Server

NA

第18.3.5.5項

Oracle Platform Security Services

第18.2.6.1項

第18.2.6.1項

Oracle Reports

NA

第18.3.5.7項

Oracle SOA Suite

NA

同じホストにリカバリする場合は、追加手順は必要ありません。別のホストにリカバリする場合は、第18.3.5.4項を参照してください。

Oracle WebCenter Content

第18.2.6.4項

第18.3.5.11項

Oracle WebCenter Content: Records

Oracle WebCenter Contentをリカバリします。第18.2.6.4項を参照してください。

Oracle WebCenter Contentをリカバリします。第18.3.5.11項を参照してください。

Oracle WebCenter Portalの分析

第18.2.6.3項

第18.2.6.3項

Oracle WebLogic Server

Oracle WebLogic Serverでサーバー全体の移行を使用する場合は、第18.2.2.1項を参照してください。

Oracle WebLogic Serverでサーバー全体の移行を使用する場合は、第18.2.2.1項を参照してください。

7. アプリケーション(リカバリが必要な場合)。第18.2.8項を参照してください。

18.2 データの損失、破損、メディア障害またはアプリケーションの機能不全後のリカバリ

この項では、ディスクをリストアできないような、実データの損失や破損、またはメディア障害などが関係する停止に対するリカバリ戦略について説明します。適切に機能しなくなったアプリケーションに対するリカバリ戦略についても説明します。このタイプの障害では、Oracle Fusion Middleware環境を再起動し、通常の処理を続行する前に、ある種のデータ・リストアが必要です。次の項目が含まれます。

- Oracleホームのリカバリ

- Oracle WebLogic Serverドメインのリカバリ

- スタンドアロン・ドメインのリカバリ

- 管理サーバーの構成のリカバリ

- 管理対象サーバーのリカバリ

- コンポーネントのリカバリ

- クラスタのリカバリ

- アプリケーションのリカバリ

- データベースのリカバリ

注意:
エンティティは、元のエンティティと同じパスにのみリストアできます。そのパスは、同じホスト上であっても、異なるホスト上であってもかまいません。

18.2.1 Oracleホームのリカバリ

破損したりファイルが削除されたOracleホームをリカバリできます。

Oracleホームをリカバリする手順は、次のとおりです。

1. 関連するすべてのプロセスを停止します。つまり、管理サーバー、ノード・マネージャ、管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。たとえば、Linux上で管理サーバーを停止するには、次のように指定します。

DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]

2. Oracleホーム・ディレクトリの親ディレクトリにするディレクトリに変更します。元の環境と同じディレクトリ構造を使用します。

3. バックアップからOracleホーム・ディレクトリをリカバリします。次に例を示します。

(UNIX) tar -xf oracle_home_backup_06052014.tar
(Windows) jar xf oracle_home_backup_06052014.jar

4. 関連するプロセスをすべて起動します。つまり、管理サーバーや管理対象サーバーなど、Oracleホームで実行されているすべてのプロセスを開始します。たとえば、管理サーバーを起動します。

DOMAIN_HOME/bin/startWebLogic.sh

18.2.2 Oracle WebLogic Serverドメインのリカバリ

ファイル・システムから削除されたり破損した場合、またはドメインを含むホストが破損した場合、Oracle WebLogic Serverドメインをリカバリすることができます。

注意:
ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。

ファイル・システムから削除されたり破損したOracle WebLogic Serverドメインをリカバリする手順は次のとおりです。

1. 関連するプロセスが実行中である場合、そのプロセスをすべて停止します。つまり、管理サーバーや管理対象サーバーおよびシステム・コンポーネントなど、ドメインに関連するすべてのプロセスを停止します。たとえば、管理サーバーを停止します。

DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]

Oracle HTTP Serverなどのシステム・コンポーネントの停止の詳細は、第4.3.2項を参照してください。

2. ドメイン・ホーム・ディレクトリの親ディレクトリにするディレクトリに変更します。元の環境と同じディレクトリ構造を使用します。

3. バックアップからドメイン・ディレクトリをリカバリします。

(UNIX) tar -xf domain_backup_06052014.tar
(Windows) jar xf domain_backup_06052014.jar

4. 関連するプロセスをすべて起動します。つまり、管理サーバーや管理対象サーバーおよびシステム・コンポーネントなど、ドメインに関連するすべてのプロセスを開始します。たとえば、管理サーバーを起動します。

DOMAIN_HOME/bin/startWebLogic.sh

Oracle HTTP Serverなどのシステム・コンポーネントの開始の詳細は、第4.3.2項を参照してください。

5. 管理サーバーを起動できない場合は、第18.2.4項の説明に従って、管理サーバーをリカバリします。

6. 管理対象サーバーを起動できない場合は、第18.2.5項の説明に従って、管理対象サーバーをリカバリします。

18.2.2.1 サーバー全体の移行を使用したOracle WebLogic Serverのリカバリ

データベース・リース(たとえば、サーバー全体の移行)を使用して、Oracle WebLogic Serverをリカバリする場合は、リース表内の情報を破棄する必要があります。単にリース表を破棄して再作成する場合は、リース表作成スクリプトを実行します。(サーバー全体の移行の詳細は、『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。)

18.2.3 スタンドアロン・ドメインのリカバリ

ファイル・システムから削除されたり破損した場合、またはホストが破損して同じホストにリカバリする必要がある場合、Oracle HTTP Serverなどのシステム・コンポーネントが含まれているスタンドアロン・ドメインをリカバリできます。

スタンドアロン・ドメインをリカバリするには、次の手順に従います。

1. Oracle HTTP Serverなどのシステム・コンポーネントやノードマネージャが実行中の場合は、停止します。

2. 破損している場合は、Oracleホームをリカバリします。

(UNIX) tar xf oracle_home_backup_05_21_2013.tar
(Windows) jar xf oracle_home_backup_05_21_2013.jar

3. ドメイン・ホームをリカバリします。

(UNIX) tar xf domain_backup_05_21_2013.tar
(Windows) jar xf domain_backup_05_21_2013.jar

4. ノード・マネージャを起動します。

(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd

5. ドメインにある、Oracle HTTP Serverなどのシステム・コンポーネントを起動します。

(UNIX) Domain_Home/bin/startComponent.sh ohs1
(Windows) Domain_Home\bin\startComponent.cmd ohs1

18.2.4 管理サーバー構成のリカバリ

ファイルの削除またはファイル・システムの破損が原因で、管理サーバーの構成が失われた場合でも、問題の発生時に管理サーバーのコンソールがすでに起動しているときには、このコンソールは引き続き機能します。管理サーバーがユーザー名やパスワードのプロンプトを表示しないようにするには、第4.2.4項を参照してください。

注意:
ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。

管理サーバーの構成をリカバリする手順は次のとおりです。

1. 管理サーバー、管理対象サーバーおよびノード・マネージャが起動している場合はこれらも含めて、すべてのプロセスを停止します。たとえば、管理サーバーを停止するには、次のように指定します。

DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]

2. ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。

DOMAIN_HOME/config

3. 管理サーバーを起動します。次に例を示します。

DOMAIN_HOME/bin/startWebLogic.sh

4. 管理サーバーが正常に起動しており、アクセス可能であることを確認します。

構成が次回変更されるときに、管理サーバーの構成が、管理対象サーバーにプッシュされます。管理対象サーバーが再起動するたびに、管理サーバーから構成が取得されます。

18.2.5 管理対象サーバーのリカバリ

管理対象サーバーのファイルが削除されたり破損した場合、その構成ファイルを含めて、それらのファイルをリカバリできます。

このシナリオでは、管理対象サーバーが管理サーバーと同じホストに存在しておらず、適切に動作しない場合や起動できない場合を想定しています。この原因としては、構成の削除、構成の破損、構成を誤って変更したがその変更内容が不明であることなどが考えられます。

管理対象サーバーをリカバリするには、次の手順に従います。

1. 管理サーバーにアクセスできない場合は、第18.2.4項の説明に従って、管理サーバーをリカバリします。

2. 管理対象サーバーが稼働中である場合は、停止します。次に例を示します。

DOMAIN_HOME/bin/stopManagedWeblogic.sh managed_server_name admin_url
username password

3. 必要に応じて、Oracleホームをバックアップからリカバリします。次に例を示します。

tar -xf oracle_home_backup_06052014.tar

4. 第4.2.2項の説明に従って、ノード・マネージャを停止します。

5. 管理サーバーのホストでpackユーティリティを使用して、管理サーバーのドメイン・テンプレートjarファイルを作成します。次に例を示します。

pack.sh -domain=/scratch/oracle/config/domains/WLS_domain
-template=/scratch/temp.jar -template_name=test_install
-template_author=myname -log=/scratch/logs/my.log -managed=true

-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。

6. 管理対象サーバーのホストでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。次の例では、temp.jarはpackコマンドにより作成されたアーカイブです。

unpack.sh -template=/scratch/temp.jar
-domain=/scratch/oracle/config/domains/WLS_domain
-log=/scratch/logs/new.log -log_priority=info

注意:

- 次のディレクトリが存在している必要があります。存在しない場合、unpackコマンドが失敗します。

ORACLE_HOME/config/domains/

- unpackコマンドの-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。環境で必要な場合は、-overwrite_domainオプションを使用してください。

- -app_dir引数を使用して別の場所に渡さないかぎり、アプリケーションはデフォルトで次のディレクトリに格納されます。

ORACLE_HOME/user_projects/applications/Domain_Name

7. 管理対象サーバーを起動します。次に例を示します。

DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。

18.2.6 コンポーネントのリカバリ

コンポーネントのファイルが削除されたり破損した場合、またはコンポーネントの構成が変更されコミットされたためにコンポーネントが起動できないまたは適切に機能しない場合、コンポーネントをリカバリできます。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。

- Javaコンポーネントでは、第18.2.5項の説明に従って、管理対象サーバーをリカバリします。

- Oracle HTTP Serverなどのシステム・コンポーネントがスタンドアロン・ドメインにある場合は、第18.2.3項の説明に従って、ドメインをリカバリします。

- Oracle HTTP Serverなどのシステム・コンポーネントがOracle WebLogic Serverドメインにある場合は、第18.2.2項の説明に従って、ドメインをリカバリします。

次の項では、特定のコンポーネントに対して実行する必要がある追加の手順について説明します。

- Oracle Platform Security Servicesのリカバリ

- Oracle B2Bのリカバリ

- Oracle WebCenter Portal分析のリカバリ

- Oracle WebCenter Contentのリカバリ

- Oracle BI Enterprise Editionのリカバリ

18.2.6.1 Oracle Platform Security Servicesのリカバリ

Oracle Platform Security Servicesの場合は、次のファイルをリストアします。

DOMAIN_HOME/config/fmwconfig/jps-config.xml
DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml
DOMAIN_HOME/config/fmwconfig/cwallet.sso
DOMAIN_HOME/config/fmwconfig/bootstrap/cwallet.sso
DOMAIN_HOME/config/fmwconfig/keystores.xml
DOMAIN_HOME/config/config.xml
DOMAIN_HOME/config/fmwconfig/ids_config.xml
DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml (if present)
DOMAIN_HOME/config/fmwconfig/jps_mbeans.xml

18.2.6.2 Oracle B2Bのリカバリ

リカバリ後、ファイルXengine.tar.gzが解凍されていない場合は解凍します。次に例を示します。

cd B2B_ORACLE_HOME/soa/thirdparty/edifecs
tar xzvf XEngine.tar.gz

18.2.6.3 Oracle WebCenter Portal分析のリカバリ

Oracle WebCenter Portal分析をリカバリする手順は次のとおりです。

1. 第18.2.2項の説明に従って、ドメインをリストアします。

2. 第18.2.1項の説明に従って、Oracleホームをリストアします。

3. 必要に応じて、ACTIVITIESスキーマおよびMDSスキーマが含まれるデータベースをリストアします。

18.2.6.4 Oracle WebCenter Contentのリカバリ

Oracle WebCenter Contentをリカバリする手順は次のとおりです。

1. 必要に応じて、第18.3.7項の説明に従って、データベースをリストアします。

2. 第18.2.2項の説明に従って、ドメインをリストアします。

3. ドメイン・ディレクトリにVault、WebLayoutまたはSearchディレクトリが配置されていない場合は、必要に応じてそれらのディレクトリをリストアします。たとえば、Vaultディレクトリが/net/home/vault内の共有ドライブに配置されている場合は、バックアップからVaultディレクトリをリストアします。

cd /net/home/vault
tar -xf vault_backup_042012.tar

データベースと共有ファイル・システムは同時にリストアしてください。同時にリストアできない場合は、IDCAnalyseユーティリティを使用して、データベースと共有ファイル・システム間に不一致があるかどうかを特定できます。不一致がある場合は、IDCAnalyseを使用して、手動でリカバリを実行できます。

18.2.6.5 Oracle BI Enterprise Editionのリカバリ

クラスタ化環境でOracle BI EEをリカバリする手順は次のとおりです。

1. 第18.2.6.5.1項の説明に従って、LDAPデータベースとOracle BI EEリポジトリ(RPD)を調整します。

2. 第18.2.6.5.2項の説明に従って、LDAPデータベースとOracle BI Presentation Catalogを調整します。

18.2.6.5.1 LDAPデータベースとRPDの調整

LDAPデータベースは、Oracle BI EEリポジトリ(RPD)と調整する必要があります。

Oracle BI Enterprise Editionを使用して、同期を実行できます。常に自動同期を有効にすることも一時的に同期を実行することもできます。(NQSConfig.iniファイルの編集の詳細は、『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のNQSConfig.INIファイルの構成設定に関する項を参照してください。)

- 同期を有効にする手順は次のとおりです。

1. 次のファイルを編集します。

INSTANCE_HOME/config/OracleBIServerComponent/coreapplication_obis1/NQSConfig.INI

フラグFMW_UPDATE_ROLE_AND_USER_REF_GUIDSをyesに設定します。

2. サーバーを再起動します。LDAPデータベースの情報とRPDが同期化されます。

- 同期を無効にする手順は次のとおりです。

1. 同期を無効にするには、次のファイルを編集します。

INSTANCE_HOME/config/OracleBIServerComponent/coreapplication_obis1/NQSConfig.INI

フラグFMW_UPDATE_ROLE_AND_USER_REF_GUIDSをnoに設定します。

2. サーバーを再起動します。

Windows上のOracle BI管理ツールには、リポジトリの妥当性をチェックして不整合を修正できるConsistency Check Managerが用意されています。詳細は、『Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド』のリポジトリ・オブジェクトの一貫性のチェックに関する項を参照してください。

18.2.6.5.2 LDAPデータベースとOracle BI Presentation Catalogの調整

LDAPデータベースがOracle BI Presentation Catalogの背後にあるよりも以前の時点にLDAPデータベースをリストアする場合は、次のコマンドを使用してLDAPデータベースとOracle BI Presentation Catalogを調整します。

runcat.cmd -cmd forgetAccounts

runcatコマンドの詳細は、次のようにヘルプを参照してください。

./runcat.sh -cmd maintenanceMode -help

18.2.7 クラスタのリカバリ

次の状況では、クラスタをリカバリする必要があります。

- クラスタが誤って削除され、クラスタ・メンバーが誤って削除されている。

- JMS構成またはコンテナレベルのデータ・ソースなどのクラスタレベルの構成が誤って変更されコミットされている。コンポーネントまたはサーバーは起動できないか、または適切に動作せず、サーバー内で実行中のサービスは起動されていません。どの変更が問題の原因となっているかを確認できない場合は、以前のバージョンに戻します。

注意:
ドメイン・レベルのリカバリを実行すると、実行中のシステムに他の面で影響が出て、バックアップ後に行われた構成変更がすべて失われる場合があります。

構成の変更が少ない場合、最も簡単な方法は、構成の変更を再実行することです。この方法を実行できない場合は、次の手順に従って構成をリカバリします。

1. クラスタを停止します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。

shutdown('cluster_name', 'Cluster')

2. 管理サーバーや管理対象サーバーなど、すべてのプロセスを停止します。たとえば、管理サーバーを停止するには、次のように指定します。

DOMAIN_HOME/bin/stopWebLogic.sh username password [admin_url]

3. ドメイン・ホームのバックアップを一時的な場所にリカバリすることで、管理サーバーの構成をリカバリします。次に、configディレクトリを次の場所にリストアします。

DOMAIN_HOME/config

4. 管理サーバーを起動します。次に例を示します。

DOMAIN_HOME/bin/startWebLogic.sh

削除されたメンバーがすべてクラスタに戻ります。

5. 管理対象サーバーなど、すべてのプロセスを起動します。たとえば、Linux上で管理対象サーバーを起動するには、次のスクリプトを使用します。

DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

6. クラスタを起動します。Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。たとえば、WLSTを次のように使用します。

start('cluster_name', 'Cluster')

18.2.8 アプリケーションのリカバリ

次の各項目で、アプリケーションをリカバリする方法について説明します。

- アプリケーション・アーティファクトのリカバリ

- Java EEアプリケーションのリカバリ

アプリケーションのリカバリについては、次の点に注意してください。

- アプリケーションがステージングされている場合、管理サーバーは、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーションのビットをコピーします。

- デプロイメント・モードがステージングなしまたは外部ステージングの場合、追加のアプリケーション・アーティファクトが使用可能であることを確認してください。たとえば、アプリケーションがドメイン・ディレクトリの外部のディレクトリに存在する可能性があります。アプリケーション・ファイルを、バックアップからコピーするか共有ディスクを使用して、新しい管理サーバーで使用できるようにします。アプリケーション・ファイルは、新しいファイル・システム上でも、元の管理サーバーのファイル・システムの場合と相対的に同じ位置にある必要があります。
アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

18.2.8.1 アプリケーション・アーティファクトのリカバリ

.earファイルなどのアプリケーションのアーティファクトが損失または破損した場合、そのアプリケーションをリカバリできます。

アプリケーションをリカバリする手順は次のとおりです。

1. アプリケーションのデプロイ先の管理対象サーバーを起動します。次に例を示します。

DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

このコマンドを実行すると、構成が管理サーバーと同期されます。

管理対象サーバーが再起動するたびに、構成およびアプリケーション・アーティファクトが管理サーバーから取得されます。

18.2.8.2 Java EEアプリケーションのリカバリ

次の場合、Java EEアプリケーションをリカバリできます。

- Java EEアプリケーションが管理対象サーバーに再デプロイされ(管理対象サーバーがクラスタの一部であるかどうかは関係ない)、アプリケーションが機能しなくなった場合。

- デプロイ済アプリケーションがOracle WebLogic Serverからアンデプロイされた場合。

- コンポジット・アプリケーションの新規バージョンが管理対象サーバーまたはクラスタに再デプロイされました。このアプリケーションが機能しなくなったとします。

アプリケーションをリカバリする手順は次のとおりです。

1. 必要に応じて、アプリケーション・ファイルをバックアップからリカバリします。

2. バックアップから古いバージョンのアプリケーションを再デプロイします。
元のearファイルを単純にコピーすることはできません。元のearファイルをバックアップから管理対象サーバーのステージング・ディレクトリにコピーして管理対象サーバーを再起動しても、アプリケーションはリカバリされません。元のバージョンを再デプロイする必要があります。

18.2.9 データベースのリカバリ

MDSリポジトリなどのメタデータ・リポジトリが含まれるデータベースが破損している場合、RMANを使用してそのデータベースをリカバリできます。データベースは、完全リカバリまたは表領域リカバリのいずれかの必要な粒度でリカバリできます。

最善の結果を得るには、ポイント・イン・タイム・リカバリを使用して、データベースを最新の状態にリカバリします(データベースがアーカイブ・ログ・モードで構成されている場合。)これにより、確実に最新のデータがリカバリされます。次に例を示します。

rman> restore database;
rman> recover database;

各コンポーネントで使用されるスキーマについては、『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

詳細な手順は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

18.3 ホスト破損後のリカバリ

この項では、Oracle Fusion Middlewareの元の動作環境が損なわれた後、その環境をリカバリする方法について説明します。たとえば、システムの深刻な機能不全やメディアの損失が発生した場合などです。この項の項目は次のとおりです。

- Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ

- スタンドアロン・ドメイン・ホストの破損後のリカバリ

- 管理サーバー・ホストの破損後のリカバリ

- 管理対象サーバー・ホストの破損後のリカバリ

- コンポーネント・ホストの破損後のリカバリ

- ホストの破損後にエンティティをリカバリするための追加の操作

- データベース・ホストの破損後のリカバリ

注意:
ホストの破損からリカバリする場合、元のホストで使用していたものと同じパスを使用してファイルをリストアする必要があります。

18.3.1 Oracle WebLogic Serverドメイン・ホストの破損後のリカバリ

ホストの破損後に、Oracle WebLogic Serverドメインをリカバリするには、第18.2.2項の手順に従います。

18.3.2スタンドアロン・ドメイン・ホストの破損後のリカバリ

スタンドアロンドメインを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。

- 同じホストへのスタンドアロン・ドメインのリカバリ

- 別のホストへのスタンドアロン・ドメインのリカバリ

18.3.2.1 同じホストへのスタンドアロン・ドメインのリカバリ

オペレーティング・システムの再インストール後に、スタンドアロン・ドメインを同じホストにリカバリするには、第18.2.3項の手順に従います。

18.3.2.2 別のホストへのスタンドアロン・ドメインのリカバリ

このシナリオでは、スタンドアロン・ドメインを別のホストにリカバリします。

スタンドアロン・ドメインを別のホストにリカバリするには、次の手順に従います。

1. Oracleホームをリカバリします。

(UNIX) tar xf oracle_home_backup_05_21_2014.tar
(Windows) jar xf oracle_home_backup_05_21_2014.jar

2. ドメイン・ホームをリカバリします。

(UNIX) tar xf domain_backup_05_21_2014.tar
(Windows) jar xf domain_backup_05_21_2014.jar

3. スタンドアロン・ドメインでは、デフォルトで、ノード・マネージャはローカル・ホストでリスニングします。ただし、そうではない場合、次のWLSTコマンドを使用してListenAddressを更新できます。

readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
updateDomain()

4. ノード・マネージャを起動します。

(UNIX) DOMAIN_HOME/bin/startNodeManager.sh
(Windows) DOMAIN_HOME\bin\startNodeManager.cmd

5. システム・コンポーネントの構成ファイルをすべて、手動で更新します。
特定コンポーネントの場合の詳細は、第18.3.5項を参照してください。

6. ドメインにある、Oracle HTTP Serverなどのシステム・コンポーネントを起動します。次に例を示します。

(UNIX) Domain_Home/bin/startComponent.sh ohs1
(Windows) Domain_Home\bin\startComponent.cmd ohs1

7. 第18.3.6.4項の説明に従って、Oracle Inventoryを更新します。

8. Windowsの場合は、第18.3.6.5項の説明に従ってWindowsレジストリを更新します。

18.3.3 管理サーバー・ホストの破損後のリカバリ

管理サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。

- 同じホストへの管理サーバーのリカバリ

- 別のホストへの管理サーバーのリカバリ

18.3.3.1 同じホストへの管理サーバーのリカバリ

このシナリオでは、管理サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。たとえば、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されているとします。なんらかの理由により、ホストAで障害が発生したため、管理サーバーをリカバリする必要があります。

同じホストに管理サーバーをリカバリする手順は次のとおりです。

1. ファイル・システムをリカバリします。たとえば、第18.3.1項の説明に従って、この管理サーバーが含まれるドメインをリカバリします。

2. 管理サーバーを起動してみます。次に例を示します。

DOMAIN_HOME/bin/startWebLogic.sh

管理サーバーが起動する場合は、これ以上の手順は必要ありません。

3. 管理サーバーが起動しない場合は、ホストAで次の手順を実行します。

1. 関連するすべてのプロセスを停止します。つまり、管理対象サーバーなど、ドメインに関連するすべてのプロセスを停止します。

2. 必要に応じて、Oracleホームをリカバリします。

tar -xf oracle_home_backup_06052014.tar

3. ドメイン・ディレクトリがOracleホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。最初に、ドメイン・ホームの親にするディレクトリに変更してから、次を実行します。

tar -xf domain_backup_06052014.tar

4. 管理サーバーを起動します。次に例を示します。

DOMAIN_HOME/bin/startWebLogic.sh

5. ホストの管理用URLを指定して、管理対象サーバーを起動します。

DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

6. ノード・マネージャを起動します。

cd DOMAIN_HOME/bin
./startNodeManager.sh

18.3.3.2 別のホストへの管理サーバーのリカバリ

このシナリオでは、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんらかの理由により、ホストAで障害が発生したため、管理サーバーをホストCに移行する必要があります。

別のホストに管理サーバーをリカバリする手順は次のとおりです。

1. OracleホームをホストC (新規ホスト)にリカバリします。

tar -xf oracle_home_backup_06052014.tar

2. ドメイン・ディレクトリがOracleホーム内に見つからない場合は、ドメイン・ディレクトリバックアップからリカバリします。最初に、ドメイン・ホームの親にするディレクトリに変更してから、次を実行します。

tar -xf domain_backup_06052014.tar

3. 管理サーバーにリスニング・アドレスが指定されている場合は、第18.3.6.3項の説明に従って、新しいホスト名で新しいマシンを作成します。

4. 管理サーバーを起動します。次に例を示します。

DOMAIN_HOME/bin/startWebLogic.sh

5. WLSTを使用して管理サーバーに接続し、新しいホストで実行されているノード・マネージャを管理サーバーに登録します。

connect('username','password','t3://host:port')
nmEnroll('/scratch/oracle/config/domains/domain_name',
'DOMAIN_HOME/nodemanager')

Windowsの場合は、UNIXの場合と同様に、nmEnrollコマンドではバックスラッシュ(\)ではなくスラッシュ(/)を使用します。

6. ノード・マネージャのプロパティ・ファイルを編集して、リスニング・アドレス・プロパティを変更します。ドメインベースのノード・マネージャの場合、ファイルは次の場所にあります。

DOMAIN_HOME/nodemanager/nodemanager.properties

または、次のWLSTコマンドを使用してプロパティを変更できます。

readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',port_num)
updateDomain()

7. 元のホストでノード・マネージャが構成されていた場合は、ホストCでノード・マネージャを起動します。

cd DOMAIN_HOME/bin
./startNodeManager.sh

8. 管理対象サーバーを起動します。『Oracle WebLogic Serverサーバーの起動と停止の管理』の障害が発生した管理サーバーの再起動に関する項では、構成に応じた様々な再起動方法について説明されています。
オプションの1つとして、次のスクリプトの使用があります。このコマンドでは、新しいホストの管理用URLを指定します。

DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

9. 追加のアプリケーション・アーティファクトが使用可能であることを確認します。たとえば、デプロイメント・モードがステージングなしまたは外部ステージングの場合、アプリケーションはドメイン・ディレクトリの外部のディレクトリに存在する可能性があります。アプリケーション・ファイルを、バックアップからコピーするか共有ディスクを使用して、新しい管理サーバーで使用できるようにします。アプリケーション・ファイルは、新しいファイル・システム上でも、元の管理サーバーのファイル・システムの場合と相対的に同じ位置にある必要があります。
アプリケーションがステージングされている場合、管理サーバーは、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーションのビットをコピーします。

10. 第18.3.6.4項の説明に従って、Oracle Inventoryを更新します。

11. Windowsの場合は、第18.3.6.5項の説明に従って、Windowsレジストリをリカバリします。

12. 環境にOracle HTTP Serverが含まれる場合、第18.3.6.2項の説明に従って、mod_wl_ohs.confファイルを修正します。

これで、ホストCで実行されている管理コンソールを使用して、ホストBの管理対象サーバーを起動および停止できます。

Web層インストール用に管理サーバーをリカバリする場合、必要な追加操作の詳細は、第18.3.6項を参照してください。

18.3.4 管理対象サーバー・ホストの破損後のリカバリ

管理対象サーバーを含むホストが破損した場合、次の各項目で説明するように、同じホストまたは別のホストにリカバリできます。

- 同じホストへの管理対象サーバーのリカバリ

- 別のホストへの管理対象サーバーのリカバリ

18.3.4.1 同じホストへの管理対象サーバーのリカバリ

このシナリオでは、管理対象サーバーを、オペレーティング・システムの再インストール後に同じホストにリカバリするか、同じホスト名を持つ新しいホストにリカバリします。ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんかの理由により、ホストBで障害が発生したため、管理対象サーバーをホストBにリカバリする必要があります。

同じホストに管理対象サーバーをリカバリする手順は次のとおりです。

1. ホストBでノード・マネージャを起動します。

cd DOMAIN_HOME/bin
./startNodeManager.sh

2. 管理対象サーバーを起動します。次に例を示します。

DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

管理対象サーバーが起動した場合、管理対象サーバーは管理サーバーに接続し、構成の変更を更新します。これ以上の手順は必要ありません。

3. 管理対象サーバーが起動しない場合、またはファイル・システムが損失した場合は、次の手順を実行します。

1. 必要に応じて、OracleホームをバックアップからホストBにリカバリします。

tar -xf oracle_home_backup_06052014.tar

2. 第4.2.2項の説明に従って、ノード・マネージャを停止します。

3. 管理対象サーバーにOracle ReportsまたはOracle Forms Servicesが含まれており、管理対象サーバーのドメイン・ディレクトリがOracleホームの外部に存在する場合、Oracleホームに加えてドメインをリストアします。次に例を示します。

cd Domain_Home
tar -xf domain_home_backup_042012.tar

ステップeに進みます。

4. 管理対象サーバーにOracle Forms ServicesまたはOracle Reportsが含まれない場合、次の手順を実行します。

- packユーティリティを使用して、ホストAで実行されている管理サーバーのドメイン・テンプレートjarファイルを作成します。次に例を示します。

pack.sh -domain=/scratch/oracle/config/domains/domain_name
-template=/scratch/temp.jar -template_name=test_install
-template_author=myname -log=/scratch/logs/my.log -managed=true

-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。

- ホストBでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。

unpack.sh -template=/scratch/temp.jar
-domain=/scratch/oracle/config/domains/domain_name
-log=/scratch/logs/new.log -log_priority=info

5. 管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。

注意:

- ステージングなしおよび外部ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバー・ホスト・ディレクトリからアプリケーション・アーティファクトをコピーします。

- ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバーが、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーション・ビットをコピーします。

アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

6. 次のWLSTコマンドを使用して、ノード・マネージャのプロパティListenAddressを更新します。

readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
updateDomain()

7. ノード・マネージャが起動していない場合は、起動します。

cd DOMAIN_HOME/bin
./startNodeManager.sh

8. 管理対象サーバーを起動します。次に例を示します。

DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。

18.3.4.2 別のホストへの管理対象サーバーのリカバリ

このシナリオでは、ホストAで管理サーバーが実行されており、ホストBで管理対象サーバーが実行されています。なんらかの理由により、ホストBで障害が発生したため、管理対象サーバーをホストCにリカバリする必要があります。1台以上のWebLogic Serversをホストするコンピュータの論理表現である2台のマシン、ホストAのmachine_1およびホストBのmachine_2があります。

重要:
Oracleホームは元と同じ場所にリカバリしてください。

別のホストに管理対象サーバーをリカバリする手順は次のとおりです。

1. 管理対象サーバーのOracleホームをホストCにリカバリします。

tar -xf oracle_home_backup_06052014.tar

2. 新しいホストを指すように、トポロジを再構成します。

1. バックアップの矛盾を防ぐために、バックアップが完了するまでは、いずれの構成も変更しないでください。WebLogic Serverドメインで変更が行われないようにするには、第2.2.5項で説明しているようにWebLogic Serverの構成をロックします。

2. WebLogic Server管理コンソールで、machine_2の構成を、新しいホストを指すように変更します。
管理コンソールの左ペインから、「環境」を展開して「マシン」を選択します。machine_2を選択して、「構成」タブを選択します。次に、「ノード・マネージャ」を選択します。「リスニング・アドレス」をホストCのアドレスに変更します。「保存」をクリックします。

リスニング・アドレスをIPアドレスで定義する場合は、ノード・マネージャにアクセスする管理サーバーのホスト名検証を無効にする必要があります。詳細は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のホスト名検証の使用に関する項を参照してください。

3. 管理対象サーバーの構成を、新しいホストを指すように変更します。
コンソールの左ペインから、「環境」→「サーバー」を開いて、サーバーの名前を選択します。続いて、サーバーの名前を選択します。「構成」タブ、続いて「一般」タブを選択します。

マシンをmachine_2に変更します。

「リスニング・アドレス」を新しいホストに変更します。(リスニング・アドレスが空白に設定されている場合は、それを変更する必要はありません。)

「保存」をクリックしてから、「変更のアクティブ化」をクリックします。

4. 「構成の解放」をWebLogic Server管理コンソールでクリックして、Oracle WebLogic Server構成のロックを解除します。

3. 表18-1の説明に従って、必要な手順があればそれを実行します。

4. 第4.2.2項の説明に従って、ノード・マネージャを停止します。

5. 管理対象サーバーにOracle ReportsまたはOracle Forms Servicesが含まれており、管理対象サーバーのドメイン・ディレクトリがOracleホームの外部に存在する場合、Oracleホームに加えてドメインをリストアします。次に例を示します。

cd Domain_Home
tar -xf domain_home_backup_042012.tar

ステップ7に進みます。

6. ステップ5に示されているコンポーネントが管理対象サーバーに含まれていない場合は、次の手順に従います。

1. packユーティリティを使用して、ホストAで実行されている管理サーバーからドメイン・テンプレートjarファイルを作成します。次に例を示します。

pack.sh -domain=/scratch/oracle/config/domains/domain_name
-template=/scratch/temp.jar -template_name=test_install
-template_author=myname -log=/scratch/logs/my.log -managed=true

-managed=trueオプションを指定すると、管理対象サーバーのみがパックされます。ドメイン全体をパックする場合は、このオプションを省略します。

2. ホストCでunpackユーティリティを使用して、ドメイン・テンプレートjarファイルを解凍します。

unpack.sh -template=/scratch/temp.jar
-domain=/scratch/oracle/config/domains/domain_name
-log=/scratch/logs/new.log -log_priority=info

別のドメイン・ホームにリカバリする場合は、unpackコマンドで-app_dirスイッチを使用します。

7. 管理対象サーバー・ホストからアプリケーション・アーティファクトにアクセス可能であることを確認します。つまり、アプリケーション・アーティファクトが管理対象サーバーと同じサーバー上にない場合、それらは管理対象サーバーがアクセスできる場所に存在する必要があるということです。

注意:

- ステージングなしおよび外部ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバー・ホスト・ディレクトリからアプリケーション・アーティファクトをコピーします。

- ステージング・モードでデプロイされているアプリケーションの場合は、管理サーバーが、管理対象サーバー・ホストのステージング済ディレクトリにアプリケーション・ビットをコピーします。

アプリケーションのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

8. 次のWLSTコマンドを使用して、ListenAddressを更新します。

readDomain('Domain_Home')
cd('/')
cd('NMProperties')
set('ListenAddress','localhost')
set('ListenPort',9001)
updateDomain()

9. ホストCでノード・マネージャが起動していない場合は、起動します。

cd DOMAIN_HOME/bin
./startNodeManager.sh

10. 管理対象サーバーを起動します。次に例を示します。

DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

管理対象サーバーが管理サーバーに接続し、構成の変更を更新します。

11. 第18.3.6.4項の説明に従って、Oracle Inventoryを更新します。

12. Windowsの場合は、第18.3.6.5項の説明に従って、Windowsレジストリをリカバリします。

13. 環境にOracle HTTP Serverが含まれる場合、第18.3.6.2項の説明に従って、mod_wl_ohs.confファイルを修正します。

これで、ホストAで実行されている管理サーバーを使用して、ホストCの管理対象サーバーを起動および停止できます。

18.3.5 コンポーネント・ホスト破損後のリカバリ

コンポーネント(およびその管理対象サーバー(該当する場合))を含むホストが破損した場合、次の各項目で説明する手順を使用して、ほとんどのコンポーネントを同じホストまたは別のホストにリカバリできます。

- 同じホストまたは別のホストへのJavaコンポーネントのリカバリ

- 別のホストへのJavaコンポーネントのリカバリ

- 同じホストまたは別のホストへのシステム・コンポーネントのリカバリ

- ホスト破損後のOracle SOA Suiteのリカバリ

- 別のホストへのWeb層コンポーネントのリカバリ

- 別のホストへのOracle Forms Servicesのリカバリ

- 別のホストへのOracle Reportsのリカバリ

- 別のホストへのOracle BI Enterprise Editionのリカバリ

- 別のホストへのOracle Business Intelligence Publisherのリカバリ

- 別のホストへのOracle Data Integratorのリカバリ

- 別のホストへのOracle WebCenter Contentのリカバリ

コンポーネントによっては追加操作が必要なものがあります。それらは、表18-1で示した項で説明しています。

18.3.5.1 同じホストまたは別のホストへのJavaコンポーネントのリカバリ

Javaコンポーネントを同じホストにリカバリするには、次の手順に従います。

1. 第18.3.4.1項の説明に従って、管理対象サーバーをリカバリします。

2. 表18-1に示すように、コンポーネントに追加手順が必要な場合は、それらの手順を実行します。

18.3.5.2 別のホストへのJavaコンポーネントのリカバリ

別のホストにJavaコンポーネントをリカバリするには、次の手順を実行します。

1. 第18.3.4.2項の説明に従って、管理対象サーバーをリカバリします。

2. 表18-1に示すように、コンポーネントに追加手順が必要な場合は、それらの手順を実行します。

18.3.5.3 同じホストまたは別のホストへのシステム・コンポーネントのリカバリ

Oracle HTTP Serverなどのシステム・コンポーネントを同じホストまたは別のホストにリカバリするには、次の手順を実行します。

- Oracle HTTP Serverなどのシステム・コンポーネントがスタンドアロン・ドメインにある場合は、第18.3.2項の説明に従って、ドメインをリカバリします。

- Oracle HTTP Serverなどのシステム・コンポーネントがOracle WebLogic Serverドメインにある場合は、第18.3.1項の説明に従って、ドメインをリカバリします。

ただし、表18-1に示すように、一部のコンポーネントでは追加手順が必要です。

18.3.5.4 ホスト破損後のOracle SOA Suiteのリカバリ

同じホストにOracle SOA Suite管理対象サーバーをリカバリするには、第18.3.4.1項の説明に従って、管理対象サーバーをリカバリします。

ホストの破損後に別のホストにOracle SOA Suite管理対象サーバーをリカバリする手順は次のとおりです。

1. リカバリを実行する前に、新しいホスト名とポートを指すようにWSDLファイルを更新します。

2. 第18.3.4.2項の説明に従って、管理対象サーバーをリカバリします。

3. Oracle SOA Suite管理対象サーバーのリカバリ後に、次の操作を実行します。

- SOAインフラMBeanでホスト名を変更します。

1. Fusion Middleware Controlで、管理対象サーバーにナビゲートします。

2. 「WebLogicサーバー」メニューから、「システムMBeanブラウザ」を選択します。

3. 「アプリケーション定義のMBean」→「oracle.as.soainfra.config」→「サーバー: server_name」→「SoaInfraConfig」を開きます。「soa-infra」を選択します。

4. 「属性」タブで、「ServerURL」をクリックします。ServerURL属性に値が含まれている場合は、ホスト名を新しいホスト名に変更します。

5. 「適用」をクリックします。

- WSDLファイルが新しいホスト名に更新されたアプリケーションをすべて再デプロイします。

注意:
環境にロード・バランサが構成されておらず、Oracle SOA Suiteを別のホストにリカバリする必要がある場合、タスク・フローからのレスポンスおよび非同期レスポンスを保留している進行中のインスタンスはリカバリされません。ロード・バランサを使用して、別のホストにリカバリできるようにすることをお薦めします。

4. 環境にロード・バランサが構成されている場合は、次の追加手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. ドメイン構造で、「クラスタ」にナビゲートします。構成するクラスタを選択し、「構成」タブの下の「HTTP」タブに移動します。

3. 「フロントエンド・ホスト」に、新しいホスト名を入力します。

4. 「フロントエンドHTTPポート」および「フロントエンドHTTPSポート」(該当する場合)に、新しいポート番号を入力します。

5. 管理対象サーバーをそれぞれ再起動します。

18.3.5.5 別のホストへのWeb層コンポーネントのリカバリ

Web層はOracle HTTP Serverで構成されています。次の各項目では、別のホストにリカバリする方法について説明します。

- スタンドアロン・ドメインのOracle HTTP Serverを別のホストにリカバリする

- WebLogic ServerドメインのOracle HTTP Serverを別のホストにリカバリする

18.3.5.5.1 スタンドアロン・ドメインのOracle HTTP Serverを別のホストにリカバリする

スタンドアロン・ドメインのOracle HTTP Serverをリカバリするには、次の手順に従います。

1. 第18.3.2項の手順1から4を実行します。

2. 次のディレクトリの構成ファイルを更新します。

(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/instance_name
(Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\instance_name

たとえば、httpd.conf, admin.confおよびmod_wl_ohs.conf (必要な場合)のIPアドレスとホスト名を更新します。

3. 第18.3.2項の手順6から8を実行します。

18.3.5.5.2 WebLogic ServerドメインのOracle HTTP Serverを別のホストにリカバリする

WebLogic ServerドメインのOracle HTTP Serverを別のホストにリカバリするには、次の手順に従います。

1. 第18.3.1項の説明に従って、ドメインをリカバリします。

2. ホストBにあったOracle HTTP Serverインスタンスの構成を変更します。

1. Fusion Middleware Controlのナビゲーション・ペインで、「HTTP_Server」を展開します。

2. Oracle HTTP Serverインスタンス(ohs1など)を選択します。

3. Oracle HTTP Serverのメニューから「管理」を選択し、「ポート構成」を選択します。

4. 表の各ポートでポートを選択し、「編集」をクリックします。「IPアドレス」を変更します。
「任意」を選択した場合、変更を行う必要はありません。

5. 「OK」をクリックします。

3. Oracle HTTP Serverの各インスタンスについて、mod_wl_ohsワイヤリングを更新します。

1. Fusion Middleware Controlのナビゲーション・ペインで、「HTTP_Server」を展開します。

2. Oracle HTTP Serverインスタンス(ohs1など)を選択します。

3. Oracle HTTP Serverのメニューから「管理」を選択し、「mod_wl_ohs構成」を選択します。

4. 「ロケーション」のセクションで、「自動入力」をクリックします。
WebLogic Serverの有効なエンドポイント位置がすべて表示されます。

5. 「適用」をクリックします。

4. 障害が発生したマシン上ではないOracle HTTP Serverインスタンスに移動し、「起動」をクリックして、そうしたインスタンスをすべて再起動します。

5. ホストC上の各Oracle HTTP Serverインスタンスに移動し、「起動」をクリックして起動します。

18.3.5.6 別のホストへのOracle Forms Servicesのリカバリ

別のホストにOracle Forms Servicesをリカバリする手順は次のとおりです。

1. 第18.3.4.2項の説明に従って、管理対象サーバーをリカバリします。

2. 管理サーバーのホストで、次のファイルを編集します。

DOMAIN_HOME/opmn/topology.xml

Oracle Forms Servicesの<ias-component id>要素のプロパティを追加します。次の例は、変更後の要素を示しています。

</ias-component>
<ias-component id="forms" type="FormsComponent" >
<em-properties>
<property name="OracleHome" value="/path_to_oracle_home" />
<property name="instName" value="instance_name" />
<property name="EMTargetType" value="oracle_forms" />
<property name="version" value="12.2.1" />
</em-properties>
</ias-component>

3. ssoregスクリプトを実行します。これは次の場所にあります。

Identity_Management_ORACLE_HOME/sso/bin

次のコマンドを使用します。

ssoreg.sh -site_name newhost:http_listen_port
-mod_osso_url http://newhost:http_listen_port -config_mod_osso TRUE
-oracle_home_path $ORACLE_HOME -config_file any_new_file_path
-admin_info cn=orcladmin -virtualhost -remote_midtier

次に例を示します。

ssoreg.sh -site_name example.com:8090
-mod_osso_url http://example.com:8090 -config_mod_osso TRUE
-oracle_home_path $ORACLE_HOME -config_file /tmp/loh_osso.conf
-admin_info cn=orcladmin -virtualhost -remote_midtier

4. 前の手順のファイルを新しいホストにコピーします。

5. 新しいホストで、次のファイルのOssoConfigFileセクションを変更し、ステップ3のファイルのパスが含まれるようにします。

ORACLE_INSTANCE/config/OHS/ohs1/moduleconf/mod_osso.conf

例:

<IfModule mod_osso.c>
OssoIpCheck off
OssoSecureCookies off
OssoIdleTimeout off
OssoConfigFile /tmp/path_of_file_created

18.3.5.7 別のホストへのOracle Reportsのリカバリ

別のホストにOracle Reportsをリカバリする手順は次のとおりです。

1. 第18.3.4.2項の説明に従って、管理対象サーバーをリカバリします。

2. 次のファイルを編集して、以前のホスト名を新しいホスト名に置き換えます。

- nodemanager.properties。このファイルは次の場所にあります。

(UNIX) DOMAIN_HOME/nodemanager
(Windows) DOMAIN_HOME\nodemanager

- reports_ohs.conf。このファイルは次の場所にあります。

(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/instances/ohs_name/moduleconf
(Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\instances\ohs_name\moduleconf

- rwservlet.properties。このファイルは次の場所にあります。

(UNIX) DOMAIN_HOME/config/fmwconfig/servers/server_name/applications/reports_version/configuration
(Windows) DOMAIN_HOME\config\fmwconfig\servers\server_name\applications\reports_version\configuration

ファイル内で、<server>要素を変更して、新しいホスト名を使用します。

- mbeans.xml。このファイルは次の場所にあります。

(Unix) DOMAIN_HOME/servers/server_name/tmp/_WL_user/reports_version/random_string/META-INF
(Windows) DOMAIN_HOME\servers\server_name\tmp\_WL_user\reports_version\random_string\META-INF

18.3.5.8 別のホストへのOracle BI Enterprise Editionのリカバリ

Oracle BI EEを別のホストにリカバリできます。

次の各項目で、Oracle BI EEを同じ名前の別のホストに移動する方法について説明します。

- 非クラスタ化環境での別のホストへのOracle BI EEのリカバリ

- クラスタ化環境での別のホストへのOracle BI EEのリカバリ

18.3.5.8.1 非クラスタ化環境での別のホストへのOracle BI EEのリカバリ

Windowsでは、障害が発生したエンティティをリカバリした後、次の追加手順を実行します。

1. 次のファイルを実行して、MicrosoftのC++ライブラリをインストールします。

Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe

2. 第18.3.5.8.3項の説明に従って、新しいホストにエクスポートしたレジストリ・エントリをインポートします。

18.3.5.8.2 クラスタ化環境での別のホストへのOracle BI EEのリカバリ

このシナリオでは、ホストAとホストBの2つのホストにOracle BI EEクラスタがある場合を考えます。ホストAにはinstance1が含まれ、ホストBにはinstance2が含まれています。なんらかの理由(ホストのクラッシュなど)により、ホストAが置き換えられたため、ホストCにリカバリし、ホストCにinstance3が含まれるようにシステムをスケールアウトする必要があります。

障害が発生したエンティティをリカバリした後、次の追加手順を実行します。

1. Windowsでは、次のファイルを実行して、MicrosoftのC++ライブラリをインストールします。

Oracle_BI\bifoundation\install\vc80\vcredist_x86.exe

2. Windowsでは、第18.3.5.8.3項の説明に従って、新しいホストにエクスポートしたレジストリ・エントリをインポートします。

3. 障害が発生したノードに管理サーバーが含まれている場合、第18.3.3.2項のステップ1 - 4の説明に従ってリカバリします。

4. 『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のAPPHOST2上のBIシステムのスケールアウトに関する項の説明に従って、Oracle BI EEシステムをスケールアウトします。

次の点に注意してください。

- ドメイン・ホームおよびアプリケーション・ホームのディレクトリの指定を入力する場合、存在していないディレクトリまたは空のディレクトリの指定を入力します。

- ドメイン・ホーム・フィールドが空の場合は、ドメイン・ディレクトリを含むように次のファイルを更新します。

DOMAIN     _HOME/wlserver_10.3/common/nodemanager/nodemanager.domains

ノード・マネージャを起動する前に、次の手順を実行します。

1. ノード・マネージャが実行されている場合は、停止します。

2. ノード・マネージャを起動する前に、ORACLE_COMMON_HOME/common/binディレクトリにあるsetNMProps.shスクリプトを実行し、StartScriptEnabledプロパティをtrueに設定します。

cd ORACLE_COMMON_HOME/common/bin
./setNMProps.sh

3. ノード・マネージャを再起動し、次のコマンドを使用して動的登録を有効にします。

cd WL_HOME/server/bin
export JAVA_OPTIONS=-DDomainRegistrationEnabled=true
./startNodeManager.sh

注意:
管理サーバーを管理するノード・マネージャの起動時には、-DDomainRegistrationEnabled=trueを設定することが重要です。コンピュータ上に管理サーバーがなく、このコンピュータが管理サーバーのフェイルオーバー・ノードでない場合、ノード・マネージャは次のように起動できます。

./startNodeManager.sh

5. 『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のシステム・コンポーネントのスケールアウトに関する項の説明に従って、システム・コンポーネントをスケールアウトします。それらの構成を変更すると、Fusion Middleware Controlに、各インスタンスの再起動を求めるプロンプトが表示されます。インスタンスを再起動します。

ホストAのinstance1は使用できないので、BIサーバー、プレゼンテーション・サービス、およびJavaHostの数を0に変更する必要があります。それらの構成を変更すると、Fusion Middleware Controlに、各インスタンスの再起動を求めるプロンプトが表示されます。インスタンスを再起動します。

6. Fusion Middleware Controlを使用して、instance2をプライマリ・インスタンスに、instance3をセカンダリ・インスタンスにします。

1. instance 2をプライマリ・インスタンスにし、セカンダリ・インスタンスにはなにも指定しません。Fusion Middleware Controlのプロンプトに表示されたとおりにインスタンスをアクティブ化し、再起動します。

2. instance3をセカンダリ・インスタンスにします。Fusion Middleware Controlのプロンプトに表示されたとおりにインスタンスをアクティブ化し、再起動します。

詳細は、『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のシングルトン・システム・コンポーネントのセカンダリ・インスタンスの構成に関する項を参照してください。

7. 『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のbi_server2管理対象サーバーのリスニング・アドレスの設定に関する項の説明に従って、bi_servern管理対象サーバーのリスニング・アドレスを設定します。

8. 『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のbi_server2管理対象サーバーのホスト名検証の無効化に関する項の説明に従って、bi_servern管理対象サーバーのホスト名検証を無効にします。

9. 環境に応じて、『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のOracle Business Intelligenceの可用性のための追加構成の実行に関する項の説明に従って、追加構成を実行します。

10. Oracle HTTP Serverがインストールされている場合は、『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の管理コンソールのフロントエンドURLに関する項の説明に従って、Oracle BI SearchのURLが正しく設定されるようにOracle WebLogic ServerクラスタのフロントエンドHTTPホストおよびポートを設定します。

11. 『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』の管理対象サーバーのノード・マネージャの構成に関する項の説明に従って、管理対象サーバーのノード・マネージャを構成します。

12. Oracle BI EE管理対象サーバーおよびすべてのOPMNの管理対象コンポーネントを起動します。

環境に応じて、前の手順を実行した後に、追加手順を実行する必要がある場合があります。

- ホストにマスターBIサーバー、プライマリ・クラスタ・コントローラ、およびプライマリOracle BIスケジューラが含まれている環境で障害が発生したときに、新しいインスタンスをマスターBIサーバーにする必要がある場合、必要に応じて次の手順を実行します。インスタンス2を引き続きマスターBIサーバーにする場合は、この追加手順を実行する必要はありません。

- マスターBIサーバーが失われた場合、次の手順を実行します。

1. すべてのノードでOracle WebLogic ServerおよびOPMNプロセスを停止します。

2. 新しいマスターBIサーバーを指定するように次の構成ファイルを更新します。

DOAMIN_HOME/config/fmwconfig/biee-domain.xml

<AvailabilityOptions>セクションで、次のように編集します。

masterBIServerOracleInstanceId="instance_name"
masterBIServerComponentId="component_id"

また、次の設定も更新します。

<OracleInstance id="instance1" host="hostname"
instanceHome="path_to_instance_home" opmnLocalPort="9500" opmnRemotePort="number">
<SchedulerOptions dataSource="(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=hostname(PORT=number)))

3. 他のホストにファイルをコピーします。

4. 管理サーバーおよび管理対象サーバーを再起動します。

- プライマリ・クラスタ・コントローラまたはスケジューラが失われた場合、スタンバイ・クラスタ・コントローラまたはスケジューラにフェイルオーバーされます。これはプライマリ・クラスタ・コントローラになるように再構成するか、プライマリ・コンポーネントに障害が発生しているために有効にされているセカンダリのままにするかを決定する必要があります。詳細は、『Oracle Business Intelligenceエンタープライズ・デプロイメント・ガイド』のシングルトン・システム・コンポーネントのセカンダリ・インスタンスの構成に関する項を参照してください。

- 障害が発生したホストにBIサーバー、セカンダリ・クラスタ・コントローラ、およびセカンダリOracle BIスケジューラが含まれる場合、セカンダリ・クラスタ・コントローラまたはスケジューラとして新しいホストを指定します。

- 障害が発生したホストにBIサーバーおよびBIプレゼンテーション・サービスやBI Javaホストなどのシステム・コンポーネントが含まれる場合、追加手順は不要です。

- 障害が発生したホストに次の関連するコンポーネントが含まれる場合、それらをリカバリします。

- Oracle Business Intelligence Publisher: 第18.3.5.9項を参照

- Oracle Real-Time Decisions。

18.3.5.8.3 Oracle BI EEレジストリ・エントリのインポート

Windowsでは、Oracle BI EEレジストリ・エントリを新しいホストにインポートする必要があります。第17.3.3項には元のホストからそれらをエクスポートする方法が説明されています。

1. 元のホストからエクスポートされたすべてのファイルを新しいホストにコピーします。

2. 元のホストからコピーした各ファイルをダブルクリックします。入力を求められたら「はい」をクリックして、ファイルをレジストリにインポートします。

18.3.5.9 別のホストへのOracle Business Intelligence Publisherのリカバリ

障害が発生したエンティティをリカバリした後、次の追加手順を実行します。

1. Oracle BIプレゼンテーション・サービスに対するサーバー値を変更します。

1. http://hostname:port/xmlpserverでBI Publisherアプリケーションを開いてログインします。

2. 「管理」→「統合」→「Oracle BIプレゼンテーション・サービス」をクリックします。

3. 「サーバー」を新しいホスト名に変更します。

4. 「適用」をクリックします。

2. コールド・フェイルオーバー・クラスタ環境で動作するようにOracle BI Publisherを変換するには、BIスケジューラのJMS構成を変更する必要があります。

1. BI Publisherアプリケーションで、「管理」をクリックします。

2. システム管理セクションで、スケジューラ構成をクリックします。

3. 「Weblogic JNDI URL」を新しいホストURLに変更します。たとえば、t3://hostname:portと指定します。

4. 「適用」をクリックします。

3. コールド・フェイルオーバー・クラスタを使用している場合は、仮想IPアドレスをリスニングするように管理対象サーバーを構成します。『高可用性ガイド』のOracle WebLogic管理対象サーバーの変換に関する項を参照してください。次に、管理コンソールまたはWLSTコマンド行を使用して、管理対象サーバーを再起動します。

4. BI Publisherでは、BI Enterprise Editionのインスタンスを参照するデータ・ソースを変更するか、作成する必要があります(新規作成する場合は新しい仮想ホストを使用)。データ・ソースを変更する手順は次のとおりです。

1. BI Publisherアプリケーションで、次の手順を実行します。

2. 「データ・ソース」の下にある「JDBC接続」をクリックします。

3. このインスタンスのBI Enterprise Editionのデータ・ソースをすべて編集して、新しいホストに対する値を反映するようにします。

バックアップ・アーティファクトが別の時点からリストアされると、ユーザー・アカウント、ユーザー・レポートおよび権限は、リストアされたバージョンに戻ります。すべてのアーティファクトを同じ時点からリストアします。

18.3.5.10 別のホストへのOracle Data Integratorのリカバリ

Oracle Data Integratorをリカバリするには、障害に応じて、次の項目のうちの1つまたは両方の手順に従います。

- Oracle Data Integratorリポジトリのリカバリ

- 別のホストへのOracle Data Integratorエージェントのリカバリ

18.3.5.10.1 Oracle Data Integratorリポジトリのリカバリ

Oracle Data Integratorリポジトリを別のホストにリストアする必要がある場合は、次の手順を実行します。

1. 第18.3.7項の説明に従ってデータベースをリストアします。

2. ODI Studioを使用して、リストアされたOracle Data Integratorリポジトリに接続します。Oracle Data Integratorによる統合プロジェクトの開発のマスター・リポジトリへの接続に関する項の説明に従って、新しいデータベース・ホストへのマスター・リポジトリの新しい接続を作成します。

3. 作業リポジトリをそれぞれ編集します。「接続」をクリックして、作業リポジトリが含まれる新しいデータベース・ホストを指すJDBC URLが含まれるように接続情報を編集します。

4. Oracle WebLogic Server構成内のOracle Data Integrator JEEエージェント・リポジトリ構成の場合は、新しいデータベース・ホストの場所と一致するようデータ・ソースを編集します。

5. 次のWLSTオフライン・コマンドを使用して、Oracle Data Integratorスタンドアロン・エージェント・リポジトリ構成を更新します。

cd ORACLE_HOME/odi/common/bin
./wlst.sh
readDomain('DOMAIN_DIRECTORY')
cd('/JdbcSystemResource/OdiMasterRepository/JdbcResource/OdiMasterRepository/JDBCDriverParams/NO_NAME_0');
set('URL','NEW_JDBC_URL_TO_RECOVERED_DB');
updateDomain();
exit();

18.3.5.10.2 別のホストへのOracle Data Integratorエージェントのリカバリ

別のホストにOracle Data Integratorエージェントをリカバリする手順は次のとおりです。

1. 第18.3.4項の説明に従って管理対象サーバーをリストアすることによって、Oracle Data Integrator JEEエージェントをリストアします。

2. 第18.3.5項の説明に従って、Oracle Data Integratorスタンドアロン・システム・コンポーネントをリストアします。

3. ODI Studioを使用して、各物理エージェントの構成を編集し、更新したホスト名の値を指定して、ポートの値を変更した場合はポートの値も指定します。

4. 次のコマンドを使用して、Oracle Data Integratorスタンドアロン・エージェントのホストおよびポート構成を更新します。

cd ORACLE_HOME/odi/common/bin
./wlst.sh
readDomain('DOMAIN_HOME')
cd('ODI/ODI_STANDALONE_AGENT_NAME')
set("ServerListenAddress",'UPDATED_HOST_NAME');
set("ServerListenPort",'UPDATED_PORT');
updateDomain();
exit();

5. スタンドアロン・エージェント、およびOracle WebLogic ServerにデプロイされているOracle Data Integratorアプリケーションを再起動します。

18.3.5.11 別のホストへのOracle WebCenter Contentのリカバリ

別のホストにOracle WebCenter Contentをリカバリする手順は次のとおりです。

1. データベースを別のホストにリストアする必要がある場合は、第18.3.7項の説明に従って、データベースをリストアします。

2. 第18.3.3項の説明に従って、ドメインをリストアします。

3. ドメイン・ディレクトリにVault、WebLayoutまたはSearchディレクトリが配置されていない場合は、必要に応じてそれらのディレクトリをリストアします。たとえば、Vaultディレクトリが/net/home/vault内の共有ドライブに配置されている場合は、バックアップからVaultディレクトリをリストアします。

cd /net/home/vault
tar -xf vault_backup_042012.tar

4. 次のファイルを編集します。

DOMAIN_HOME/ucm_domain/ucm/cs/config/config.cfg

このファイルで、新しいホストを指定するようにHttpServerAddressの設定を変更します。例:

HttpServerAddress=hostname:port_number

データベースと共有ファイル・システムは同時にリストアしてください。同時にリストアできない場合は、IDCAnalyseユーティリティを使用して、データベースと共有ファイル・システム間に不一致があるかどうかを特定できます。不一致がある場合は、IDCAnalyseを使用して、手動でリカバリを実行できます。

18.3.6 ホストの破損後にエンティティをリカバリするための追加の操作

リカバリするエンティティによっては、ホストの破損後に追加操作の実行が必要な場合があります。各エンティティに関する項では、示される手順のうち1つ以上を実行する必要がある場合があります。そのような場合は、エンティティをリカバリする方法を説明している項に明記されています。

次の各項目で、実行することが必要な可能性のある操作について説明します。

- 別のホストへのFusion Middleware Controlのリカバリ

- mod_wl_ohs.confファイルの変更

- 特定のコンポーネントの新しいマシンの作成

- Oracleインベントリの更新

- Windowsレジストリのリカバリ

18.3.6.1 別のホストへのFusion Middleware Controlのリカバリ

Fusion Middleware Controlを別のホストにリカバリするには、システムMBeanブラウザを使用してプロパティを更新します。

1. Fusion Middleware ControlのWebLogicドメイン・メニューから、「システムMBeanブラウザ」を選択します。

2. 「システムMBeanブラウザ」ペインで「アプリケーション定義のMBean」、「emoms.props」、「サーバー: AdminServer」、「アプリケーション: em」、そして「プロパティ」と展開します。

3. 「emoms.properties」をクリックします。

4. 「属性」ペインで「操作」タブを選択し、「SetProperty」をクリックします。

5. 次のプロパティの値を新しいホスト名に変更します。

- oracle.sysman.emSDK.svlt.ConsoleServerHost

- oracle.sysman.emSDK.svlt.ConsoleServerName

たとえば、「キー」に「oracle.sysman.emSDK.svlt.ConsoleServerHost」と入力します。次に、値として「host.example.com:7001_Management_Service」と入力します。

6. 「起動」をクリックします。

18.3.6.2 mod_wl_ohs.confファイルの変更

管理サーバーまたは管理対象サーバーを別のホストにリカバリする場合、環境にOracle HTTP Serverが含まれていると、新しいホスト上で次のファイルを変更する必要があります。

(UNIX) DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_name/mod_wl_ohs.conf
(Windows) DOMAIN_HOME\config\fmwconfig\components\OHS\ohs_name\mod_wl_ohs.conf

WebLogic ServerドメインのOracle HTTP Serverの場合、このディレクトリは管理サーバーのドメイン・ホームであることに気を付けてください。スタンドアロン・ドメインのOracle HTTP Serverでは、このディレクトリはOracle HTTP Serverのドメイン・ホームです。

そのファイルで、ホスト名、ポート、およびクラスタのエントリのすべてのインスタンス(WebLogicHost、WebLogicPort、WebLogicClusterなどの要素)を変更します。次に例を示します。

<Location /console>
SetHandler weblogic-handler
WebLogicHost Admin_Host
WeblogicPort Admin_Port
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>
.
.
.
<Location /soa-infra>
SetHandler weblogic-handler
WebLogicCluster SOAHOST1VHN2:8001,*SOAHOST2VHN1*:*8001*
WLProxySSL ON
WLProxySSLPassThrough ON
</Location>

18.3.6.3 特定のコンポーネントの新しいマシンの作成

管理サーバーにリスニング・アドレスがある場合は、管理サーバーを起動する前に新しいホスト名の新規マシンを作成する必要があります。

次の手順を実行します。

1. 新しいホスト名で新しいマシンを作成します。次のWLSTコマンドをオフライン・モードで使用します。

readDomain('DOMAIN_HOME')
machine = create('newhostname', 'Machine')
cd('/Machine/newhostname')
nm = create('newhostname', 'NodeManager')
cd('/Machine/newhostname/NodeManager/newhostname')
set('ListenAddress', 'newhostname')
updateDomain()

2. 管理サーバーの場合、次のWLSTコマンドをオフライン・モードで使用して、新しいホスト名でマシンを設定します。

readDomain('DOMAIN_HOME')
cd ('/Machine/newhostname')
machine = cmo
cd ('/Server/AdminServer')
set('Machine', machine)
updateDomain()

3. WLSTを使用して、管理サーバーのリスニング・ポートを設定します。

readDomain('DOMAIN_HOME')
cd('/Server/AdminServer')
cmo.setListenPort(8001)
updateDomain()

4. 必要に応じて、WLSTを使用して管理サーバーのアドレス・リスニングを更新します。

readDomain('DOMAIN_HOME')
cd('/Server/AdminServer')
cmo.getListenAddress()
cmo.setListenAddress('newhostname')
updateDomain()
exit()

18.3.6.4 Oracleインベントリの更新

多くのコンポーネントで、別のホストにリカバリするときは、ホストの破損の場合と同様に、Oracleインベントリを更新する必要があります。そのためには、次のスクリプトを実行します。

(UNIX) ORACLE_HOME/oui/bin/attachHome.sh
(Windows) ORACLE_HOME\oui\bin\attachHome.cmd

18.3.6.5 Windowsレジストリのリカバリ

Windows上で別のホストにコンポーネントをリカバリするときは、ホストの破損の場合と同様に、Oracle Fusion Middlewareに関連するすべてのWindowsレジストリ・キーを新しいホストにインポートする必要があります。(レジストリ・キーは、第17.3.3項でエクスポートしたものです。)

次のレジストリ・キーをリカバリします。

HKEY_LOCAL_MACHINE\Software\Oracle

さらに、次のレジストリ・キー内のOracleで始まる各ノードをリカバリします。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Services

前にエクスポートしたキーをインポートするには、次のコマンドを使用します。

regedit  /I  FileName

例:

regedit /I C:\oracleregistry.reg

キーのインポートにはレジストリ・エディタを使用することもできます。詳細は、レジストリ・エディタのヘルプを参照してください。

18.3.7 データベース・ホストの破損後のリカバリ

データベースのリカバリの詳細は、第18.2.9項を参照してください。

第VIII部

高度な管理: 環境の拡張

この部では、Oracle Fusion Middleware環境を拡張する方法について説明します。

次の章で構成されます。

- 第19章「環境のスケール・アップ」

- 第20章「テスト環境から本番環境への移行」

19 環境のスケール・アップ

次の各項目では、管理対象サーバーの追加、他の製品の組込みによるドメインの拡張、管理対象サーバーのクラスタの作成、スタンドアロン・ドメインまたはシステム・コンポーネントの作成、既存のOracleホームまたはドメインのコピーによって環境を拡張する方法について説明します。

- 環境のスケール・アップの概要

- ドメインの拡張による追加コンポーネントのサポート

- ドメインへの管理対象サーバーの追加

- クラスタの作成

- スタンドアロン・ドメインおよびシステム・コンポーネントの作成

- WebLogic Serverドメインでのシステム・コンポーネント・インスタンスの作成

- Oracleホームおよびドメインのコピー

19.1 環境のスケール・アップの概要

スケーラビリティとはスループットを提供するシステムの能力で、使用可能なハードウェア・リソースに比例し、またこのリソースによってのみ制限されます。スケーラブルなシステムとは、リクエストが増加してもレスポンス時間およびスループットに悪影響をもたらすことなく処理できるシステムです。

1つの操作環境において計算力を増加することを、垂直スケーリングといいます。水平スケーリングとは、複数のシステムを連動させて共通の問題をパラレル処理することです。

Oracle Fusion Middlewareは、垂直および水平の両方のスケーリングを行います。

Oracle Fusion Middlewareでは、管理対象サーバーまたはコンポーネントを同一ホストに追加でき、垂直的なスケーラビリティも優れています。これは、スケール・アップと呼ばれます。

水平方向では、Oracle Fusion Middlewareには別のホスト・コンピュータへのフェイルオーバー機能が用意されています。これにより、あるコンピュータが停止しても、環境はデプロイ済アプリケーションのコンシューマに、サービス提供を続けることができます。これはスケールアウト、またはマシンのスケールアウトとも呼ばれます。スケールアウトの詳細は、『高可用性ガイド』のトポロジのスケールアウトに関する項を参照してください。

高可用性システムのデプロイによって、システムのダウン(使用不可の時間)を最小限に抑え、実行(使用可能な時間)を最大化できます。Oracle Fusion Middlewareは、ロード・バランシングや基本的なクラスタ化から、ハードウェアおよびソフトウェアの壊滅的な障害発生時にシステムの可用性を最大限にすることまで、非常に広範囲な高可用性ソリューションを提供するように設計されています。

高可用性ソリューションは、ローカルの高可用性と障害時リカバリの2つの基本的なカテゴリに分類できます。詳細は、次を参照してください:

- 高可用性の詳細は、『高可用性ガイド』を参照してください。

- ディザスタ・リカバリ・ガイド

19.2 ドメインの拡張による追加コンポーネントのサポート

Oracle WebLogic Serverドメインを作成する場合、特定のドメイン・テンプレートを使用します。そのテンプレートは、特定のコンポーネントや、Oracle WebLogic Serverなどのコンポーネント・グループをサポートしています。そのドメインにOracle HTTP Serverなどの他のコンポーネントを追加する場合、そのコンポーネントのドメイン・テンプレートを使用して追加の管理対象サーバーをドメインに作成することで、そのドメインを拡張します。

ドメインを拡張する際は、ドメインをオフラインにする必要があります。

ドメインを拡張するには、目的のコンポーネントがインストールされているOracleホームからOracle WebLogic Server構成ウィザードを使用します。そこで、拡張するドメインと追加するコンポーネントを選択します。詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のWebLogicドメインの構成に関する項を参照してください。

たとえば、最初にOracle Application Development Frameworkをサポートするように作成されたドメインを拡張し、Oracle HTTP Serverもサポートできるようにする手順は次のとおりです。

1. コンポーネントの必須スキーマを追加するには、『リポジトリ作成ユーティリティによるスキーマの作成』の説明に従ってRCUを使用します。

2. 『Oracle HTTP Serverのインストールと構成』の説明に従って、Oracle HTTP Serverをインストールします。

3. Oracleホームから、次のコマンドを使用して構成ウィザードを起動します。

(UNIX) ORACLE_HOME/oracle_common/common/bin/config.sh
(Windows) ORACLE_HOME\oracle_common\common\bin\config.cmd

構成ウィザードの「ようこそ」画面が表示されます。

4. 「既存ドメインの更新」を選択します。

5. 「ドメインの場所」でドメインの場所を指定します。

6. 「次へ」をクリックします。

7. 「製品テンプレートを使用してドメインを更新」を選択します。

8. Oracle HTTP Server (コロケート)を選択します。

9. 「次へ」をクリックします。

10. 「以下の追加製品をサポートするために、自動的にドメインを拡張する」を選択して、このドメインを拡張する元になるソースを選択します。たとえば、「Oracle HTTP Server」を選択します。

11. 「次へ」をクリックします。

12. RCUデータまたは「手動構成」のいずれかを選択します。「RCUデータ」を選択した場合、「RCU構成の取得」を選択すると、情報は自動的に移入されます。「手動構成」を選択した場合は、「次へ」をクリックします。
追加した新しいコンポーネントのスキーマを選択します。「コンポーネント・データソース」ページ内の値が正しくない場合、これらの値を変更します。

13. 「次へ」をクリックします。
「JDBCコンポーネント・スキーマ・テスト」画面が表示されます。

14. テストが成功したら、「次へ」をクリックします。
「拡張構成」画面が表示されます。

15. 「システム・コンポーネント」を選択します。

16. 「次へ」をクリックします。

17. 「追加」をクリックして、新しいOracle HTTP Serverインスタンスを作成します。

18. インスタンスの名前を入力し、コンポーネント・タイプとして「OHS」を選択します。

19. 「次へ」をクリックします。

20. 「OHSサーバー」ページの各フィールドは、事前に移入されています。

21. 「次へ」をクリックします。

22. 新しいマシンを作成しない場合は、「マシン」ページで「次へ」をクリックします。

23. システム・コンポーネントの割当ページでサーバーをダブルクリックし、これをマシンの下に移動します。

24. この画面に表示されている情報を確認して、正しければ「更新」をクリックします。

25. 操作が完了したら、「完了」をクリックします。

19.3 ドメインへの管理対象サーバーの追加

ドメインに管理対象サーバーを追加して、システムの容量を拡大できます。管理対象サーバーは、クラスタに追加することができます。

管理対象サーバーをクラスタに追加すると、管理対象サーバーは、そのクラスタが対象となっているアプリケーションおよびサービスを継承されます。管理対象サーバーをクラスタの一部として追加するのではない場合、管理対象サーバーは、テンプレートからアプリケーションとサービスを自動的には継承しません。

管理対象サーバーをドメインに追加するには、Fusion Middleware Control、Oracle WebLogic Server管理コンソールまたはWLSTを使用できます。

Fusion Middleware Controlを使用して、管理対象サーバーを追加する手順は次のとおりです。

1. 「WebLogicドメイン」メニューで「管理」、「コンポーネントの作成/削除」を選択します。
「コンポーネントの作成」ページが表示されます。

2. 「作成」をクリックし、「WebLogic Server」を選択します。
「WebLogic Serverの作成」ページが表示されます。

3. 「名前」に、サーバーの名前を入力します。
ドメイン内の各サーバーには、ドメイン内のすべての構成オブジェクトに対して一意の名前が必要です。ドメイン内では、各サーバー、コンピュータ、クラスタ、JDBC接続プール、仮想ホストおよびその他すべてのリソース・タイプに、一意の名前を付ける必要があり、ドメインと同じ名前を使用することはできません。

4. 「リスニング・ポート」に、サーバー・インスタンスへのアクセス元のポート番号を入力します。
1つのコンピュータで複数のサーバー・インスタンスを実行している場合は、各サーバーで固有のリスニング・ポートを使用する必要があります。

5. 「新規WebLogicマシンの作成」または「既存のWebLogicマシンの選択」のいずれかを選択します。「既存のWebLogicマシンの選択」を選択した場合は、表からマシンを選択します。

6. このサーバーをスタンドアロン・サーバーにするのか、それとも既存のクラスタのメンバーにするのかを指定します。

- このサーバーが既存のクラスタの一部である場合は、そのクラスタを選択します。

- このサーバーをスタンドアロン・サーバーにする場合は、クラスタを選択しません。

7. 「作成」をクリックします。

8. サーバーまたはクラスタにOracle JRFが適用されていない場合は、第19.3.1項の説明に従って、JRFを適用します。

19.3.1 管理対象サーバーまたはクラスタへのOracle JRFテンプレートの適用

Oracle JRF (Java Required Files)は、Oracle WebLogic Serverインストールに含まれておらず、Oracleビジネス・アプリケーションおよびアプリケーション・フレームワークに共通の機能を提供するコンポーネントで構成されています。

Oracle JRFには、共通の場所にデプロイされる、個別に開発されたいくつかのライブラリおよびアプリケーションが含まれています。Java Required Filesの一部と見なされるコンポーネントには、Oracle Application Development Framework共有ライブラリやODLロギング・ハンドラがあります。

特定の状況では、JRFテンプレートを管理対象サーバーまたはクラスタに適用する必要があります。JRFが構成されているドメイン内の管理対象サーバーにのみJRFを適用できます。つまり、ドメインを作成または拡張した場合は、構成ウィザードでOracle JRFを選択しておく必要があります。

JRFの適用については、次の点に注意してください。

- すでにJRFで構成されている既存のクラスタに管理対象サーバーを追加する場合は、その管理対象サーバーにJRFを適用する必要はありません。

- Fusion Middleware Controlを使用してサーバーを作成すると、JRFテンプレートが自動的に適用されます。

- 管理対象サーバーをドメインに追加する際、その管理対象サーバーにJRFサービスが必要だが、管理対象サービスがクラスタに属していない場合、その管理対象サーバーにJRFを適用する必要があります。

- クラスタを新規作成し、そのクラスタにJRFが必要な場合、クラスタにJRFを適用する必要があります。

- テンプレート拡張プロセスで製品テンプレートによって追加される管理対象サーバーにJRFを適用する必要はありません(ただし、構成ウィザードでJRFを選択する必要があります)。

- JRFの適用後は、サーバーまたはクラスタを再起動する必要があります。
ノード・マネージャを使用してサーバーまたはクラスタを起動する場合は(たとえば、ノード・マネージャを使用する管理コンソールを通して)、ノード・マネージャのプロパティstartScriptEnabledをtrueに設定する必要があります。詳細は、第2.7.1項を参照してください。

applyJRFコマンドの形式は次のとおりです。

applyJRF(target={server_name | cluster_name | *}, domainDir=domain_path,
[shouldUpdateDomain= {true | false}])

applyJRFコマンドは、オンラインまたはオフラインで使用できます。

- オンライン・モードでは、shouldUpdateDomainオプションを値true(デフォルト)で使用した場合、JRFの変更は暗黙的にアクティブになります。オンライン・モードでは、このオプションによって、オンラインWLST save()コマンドおよびactivate()コマンドがコールされます。

- オフライン・モードでは、管理サーバーおよび管理対象サーバーまたはクラスタを再起動する必要があります。(オフライン・モードでは、shouldUpdateDomainオプションを値trueで指定した場合、このオプションによってWLST updateDomain()コマンドがコールされます。)

たとえば、JRFで管理対象サーバーserver1を構成するには、次のコマンドを使用します。

applyJRF(target='server1', domainDir='DOMAIN_HOME')

ドメイン内のすべての管理対象サーバーをJRFで構成するには、targetオプションの値としてアスタリスク(*)を指定します。

クラスタをJRFで構成するには、次のコマンドを使用します。

applyJRF(target='cluster1', domainDir='DOMAIN_HOME')

追加情報は、次の場所を参照してください。

- 『インフラストラクチャ・コンポーネントのためのWLSTコマンド・リファレンス』のJava Required FilesのカスタムWLSTコマンドに関する項

- 第H.2.2項(JRFとともに提供されるものとは別のバージョンのSpringを使用する場合)

19.4 クラスタの作成

WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic Serverサーバー・インスタンスで構成されます。クライアントでは、1つのクラスタが、1つのWebLogic Serverインスタンスのように認識されます。1つのクラスタを構成するサーバー・インスタンスを同一のコンピュータで実行することも、複数のコンピュータに配置することもできます。既存のコンピュータ上のクラスタにサーバー・インスタンスを追加して、クラスタの容量を拡大したり、クラスタにコンピュータを追加して、追加のサーバー・インスタンスをホストしたりできます。クラスタ内の各サーバー・インスタンスでは、同一バージョンのWebLogic Serverを実行する必要があります。

WLST、Oracle WebLogic Server管理コンソールまたはFusion Middleware Controlを使用して、管理対象サーバーのクラスタを作成できます。この項では、Fusion Middleware Controlを使用してクラスタを作成する方法について説明します。

2つの管理対象サーバーwls_server1およびwls_server2のクラスタを作成するには、次の手順を実行します。

1. 「WebLogicドメイン」メニューで「管理」、「コンポーネントの作成/削除」を選択します。
「Fusion Middlewareコンポーネント」ページが表示されます。

2. 「作成」→「WebLogicクラスタ」を選択します。
「WebLogicクラスタの作成」ページが表示されます。

3. 「名前」に、クラスタの名前を入力します。

4. 「クラスタ・メッセージング・モード」セクションで、次のいずれかを選択します。

- ユニキャスト。「ユニキャスト・ブロードキャスト・チャネル」にチャネルを入力します。このチャネルは、クラスタ内でのメッセージの伝送に使用されます。

- マルチキャスト。マルチキャスト・ブロードキャスト・チャネルにチャネルを入力します。マルチキャスト・アドレスは、224.0.0.0から239.255.255.255の範囲内のIPアドレスです。「マルチキャスト・ポート」にポート番号を入力します。

注意:
入力するマルチキャスト・アドレスが使用されていないことを確認する必要があります。

5. 「サーバー」セクションで、クラスタに追加する1つ以上のサーバーを選択します。このシナリオでは、wls_server1およびwls_server2を選択します。

6. 「作成」をクリックします。

これで、wls_server1およびwls_server2の、2台のメンバーを持つクラスタができました。

クラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』を参照してください

19.5 スタンドアロン・ドメインおよびシステム・コンポーネントの作成

『Oracle HTTP Serverのインストールと構成』のスタンドアロン・ドメインでのOracle HTTP Serverの構成に関する項の説明に従い、構成ウィザードを使用して、Oracle HTTP Serverなどのシステム・コンポーネント用のスタンドアロン・ドメインを作成できます。

または、WLSTを使用して、たとえばOracle HTTP Serverなどのシステム・コンポーネントを含むスタンドアロン・ドメインを作成できます。

1. 次のディレクトリからWLSTを起動します。

cd ORACLE_HOME/oracle_common/common/bin

./wlst.sh

2. スタンドアロン・ドメイン・テンプレートを読み取ります。たとえば、Oracle HTTP Server用のスタンドアロン・ドメイン・テンプレートは、次のとおりです。

readTemplate('ORACLE_HOME/ohs/common/templates/wls/base_standalone.jar')
addTemplate('ORACLE_HOME/ohs/common/templates/wls/ohs_standalone_template_12.1.3.jar')

3. ノード・マネージャを構成します。

cd('/')
create(domainName, 'SecurityConfiguration')
cd('SecurityConfiguration/domain_name)
set('NodeManagerUsername', 'username')
set('NodeManagerPasswordEncrypted', 'password')
setOption('NodeManagerType', 'PerDomainNodeManager')

4. スタンドアロン・テンプレートには、デフォルトの構成値が含まれています。ただし、これらの値は変更できます。次に例を示します。

cd('/OHS/ohs1')
cmo.setAdminHost('127.0.0.1')
cmo.setAdminPort('7779')
cmo.setListenAddress('localhost')
cmo.setListenPort('7777')
cmo.setSSLListenPort('4443')

5. ドメインを作成します。この操作には多少時間がかかります。

writeDomain(domain_dir)
closeTemplate()

19.6 WebLogic Serverドメインでのシステム・コンポーネント・インスタンスの作成

『Oracle HTTP Serverのインストールと構成』のWebLogic ServerでのOracle HTTP Serverの構成に関する項の説明に従い、構成ウィザードを使用して、Oracle HTTP Serverなどのシステム・コンポーネント・インスタンスをWebLogic Serverドメインに作成できます。

または、次の方法に従って、たとえばOracle HTTP Serverなどのシステム・コンポーネント・インスタンスを作成できます。

- Fusion Middleware Controlを使用します。たとえば、Oracle HTTP Serverインスタンスを作成するには、『Oracle HTTP Server管理者ガイド』のFusion Middleware Controlを使用したインスタンスの作成に関する項を参照してください。

- Oracle HTTP Serverの場合は、『Oracle HTTP Server管理者ガイド』のWLSTを使用したインスタンスの作成に関する項の説明に従って、WLSTのcreateOHSInstanceコマンドを使用します。

- この項の説明に従って、WLSTコマンドを使用します。

この項では、WLSTコマンドを使用して、システム・コンポーネント・インスタンスを作成する方法について説明します。例として、Oracle HTTP Serverを使用し、Oracle JRFが含まれているWebLogic Serverドメインを作成しているものとします。

1. 次のディレクトリからWLSTを起動します。

cd ORACLE_HOME/oracle_common/common/bin

./wlst.sh

2. ドメイン・テンプレートを読み取り、そのテンプレートをシステム・コンポーネント用に追加します。次の例では、Oracle HTTP Serverテンプレートを示します。

readDomain('DOMAIN_HOME')
addTemplate('ORACLE_HOME/ohs/common/templates/wls/ohs_managed_template_12.1.3.jar')

3. システム・コンポーネント用のマシンをまだ作成していない場合は、次のようにして作成します。

cd('/')
create('ohs_machine', 'Machine')
cd('/Machines/ohs_machine')

create('ohs_machine', 'NodeManager')
cd('NodeManager/ohs_machine')

この場合、ノード・マネージャのポートはそのままにしておきます。

4. この例では、システム・コンポーネント・インスタンスOracle HTTP Serverを作成します。

cd('/')
create('myohs', 'SystemComponent')
cd('/SystemComponent/myohs')
cmo.setComponentType('OHS')
set('Machine', 'ohs_machine')

5. 作成したシステム・コンポーネント・インスタンスを構成します。設定するプロパティは、システム・コンポーネントのタイプごとに異なります。たとえば、Oracle HTTP Serverの場合は、次のようになります。

cd('/OHS/myohs')
cmo.setAdminHost('127.0.0.1')
cmo.setAdminPort('7779')
cmo.setListenPort('7777')
cmo.setSSLListenPort('4443')

6. ドメインを更新します。

updateDomain()
closeDomain()

19.7 Oracleホームおよびドメインのコピー

Oracleホームおよびドメインは、その構成を維持しながら、別の場所にコピーできます。これを行う場合、複数のOracle Fusion Middlewareコンポーネントもコピーされます。Oracle Fusion Middlewareのコピーは、次のような場合に有用です。

- 本番環境、テスト環境、または開発環境のコピーであるOracleホームを作成する場合。これにより、すべてのパッチが適用された状態で、新しいOracleホームまたはコンポーネントを1回の手順で作成できます。これは、個々のコンポーネントへのパッチの個別インストール、構成、および適用とは対照的です。

- パッチを適用したホームの「ゴールド」イメージを作成し、それを多数のホストに配置する場合。

Oracleホームおよびドメインのコピーで実行する手順の詳細は、第20章を参照してください。

20 テスト環境から本番環境への移行

この章では、Oracle Fusion Middlewareをテスト環境などのソース環境から本番環境などのターゲット環境に移行する方法について説明します。ソース環境内でアプリケーションの開発とテストを行い、最終的にはテスト・アプリケーション、また、必要に応じてテスト・データをターゲット環境にロール・アウトできます。このアプローチは、アップグレードのテストおよびロール・アウトにも使用できます。

この章の内容は次のとおりです。

- Oracle Fusion Middlewareコンポーネントの移行の概要

- 環境の移行の計画

- ターゲット環境への移行の一般的な手順

- 特定のコンポーネントに対する追加の手順または情報

- アーティファクトの漸進的な移行

- 分散トポロジの移行

- テストから本番への移行におけるエラーのリカバリ

注意:

- この章で説明されている手順は、Oracle Fusion Middleware 12c (12.2.1)およびそのリリースの一部であるコンポーネントを対象としてます。

- この章の手順の大部分は、ユーザーが標準的なインストール・トポロジ(1つの管理サーバーを含む1つのWebLogic Serverドメインと2つの管理対象サーバーまたはスタンドアロン・ドメインが含まれているクラスタで構成)を使用すると想定しています。
標準的なトポロジの詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のOracle Fusion Middlewareインフラストラクチャの標準的なインストール・トポロジの理解に関する項を参照してください。

20.1 Oracle Fusion Middlewareコンポーネントの移行の概要

Oracle Fusion Middlewareコンポーネントをソース環境からターゲット環境に移行できます。

Oracle Fusion Middlewareコンポーネントを移行しない場合、移行元の環境で行ったカスタマイズや構成変更は、移行先の環境にすべて再適用する必要がありますが、コンポーネントを移行することにより、このような作業が最小化されます。ソース環境では、Oracle Fusion Middlewareのインストール、構成、カスタマイズおよび検証を行うことができます。システムが安定し、必要に応じて機能するようになったら、ターゲット環境を作成しますが、このとき、ソース環境に取り込んだすべての変更内容を再実行するかわりに、コンポーネントとその構成のコピーをソース環境から移行することでターゲット環境を作成できます。

20.2 環境の移行の計画

この項では、環境を移行する前に知っておく必要がある重要な情報について説明します。内容は次のとおりです。

- Oracle Fusion Middlewareコンポーネントの移行の概要

- ソース環境の確認

- 移行スクリプトがキーストアを処理する方法の理解

- ターゲット環境の準備

- ソース環境からターゲット環境への移行に関する制限事項

- ソース環境からターゲット環境への移行手順の概要

20.2.1 移行スクリプトの概要

Oracle Fusion Middlewareには、環境の移行に使用できる一連のスクリプトが用意されています。

- copyBinary: ソースOracleホームのバイナリ・ファイルをコピーします。

- pasteBinary: コピーしたOracleホームをターゲットに適用します。

- copyConfig: 次のいずれにも使用できます。

- WebLogic Serverドメインの構成をコピーします(ドメイン内のすべてのJavaコンポーネントやシステム・コンポーネントを含む)

- スタンドアロン・ドメインの構成をコピーします(ドメイン内のすべてのシステム・コンポーネントを含む)

- ノード・マネージャの構成をコピーします。

- extractMovePlan: copyConfig操作で作成されたアーカイブ・ファイルから、移動計画を.xmlファイル(名前はmoveplan.xml)として抽出し、さらにその他のファイルも抽出します。

- pasteConfig: 次のいずれにも使用できます。

- コピーされたWebLogic Serverドメインの構成を適用します(ドメイン内のすべてのJavaコンポーネントやシステム・コンポーネントを含む)

- コピーされたスタンドアロン・ドメインの構成を適用します(ドメイン内のすべてのシステム・コンポーネントを含む)

- コピーされたノード・マネージャの構成を適用します。

こうしたスクリプトにより、ユーザーはOracleホーム・ドメイン、Oracle WebLogic Serverドメイン、さらにOracle HTTP ServerやOracle SOA Suiteなどの特定のOracle Fusion Middlewareコンポーネントの構成をコピーできます。

表20-1は、移行スクリプトをサポートしているOracle Fusion Middlewareコンポーネントを示しています。

表20-1 移行スクリプトのサポート

コンポーネント

サポートの有無

Oracle Application Development Framework

はい

Oracle B2B

はい

Oracle B2B for Healthcare

はい

Oracle Business Activity Monitoring

はい

Oracle Business Intelligence

いいえ

Oracle Business Process Management

はい

Oracle Coherence

はい

Oracle Data Integrator

はい

Oracle Enterprise Data Quality

はい

Oracle Enterprise Scheduler

はい

Oracle Forms Services

はい

Oracle HTTP Server

はい

Oracle HTTP Server WebGate

はい

Oracle Managed File Transfer

はい

Oracle Reports

いいえ

Oracle Platform Security Services

はい

Oracle Service Bus

はい

Oracle SOA Suite

はい

Oracle Traffic Director

はい

Oracle User Messaging Service

はい

Oracle Web Services Manager

はい

Oracle WebCenter Capture

はい

Oracle WebCenter Content

はい

Oracle WebCenter Portal

はい

Oracle WebCenter Sites

はい

Oracle WebLogic Server

はい

表A-11で説明しているように、多くのコンポーネントには特定の移動計画があります。

20.2.2 ソース環境の確認

この章の手順では、次の一部またはすべてが含まれる、Oracle Fusion Middlewareのインストールおよび構成がソース環境で行われていることを想定しています。

- Oracle SOA SuiteなどのOracle Fusion Middlewareコンポーネントで使用される1つ以上のデータベースをインストールしました。

- RCUを使用してソース環境で必要なスキーマを作成しました。『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

- Oracle Fusion Middleware製品をインストールし、構成しました。たとえば、Oracle WebLogic ServerとOracle Web Services Managerをインストールし、Oracleホームを作成し、Oracle WebLogic Serverドメインを構成しました。
ドメインを構成するときには、2つの方法のいずれかを選択できます。

- 開発モード: このモードでは、セキュリティの構成が比較的緩くなります。アプリケーションのデプロイには、ユーザー名とパスワードが必要です。

- 本番モード: このモードでは、セキュリティの構成が比較的厳格で、アプリケーションのデプロイおよび管理サーバーの起動にはユーザー名とパスワードが必要です。

- または、スタンドアロン・ドメインにシステム・コンポーネント(Oracle HTTP Serverなど)をインストールおよび構成しました。

- セキュリティ・ポリシーを構成しました。

- Oracle Platform Security Servicesの場合、セキュリティ・ポリシーおよび格納済の資格証明を資格証明ストア・フレームワーク(CSF)に作成しました。

- 1つ以上のアプリケーションまたはSOAコンポジット・アプリケーションをデプロイしました。これらのアプリケーションには、内部参照および外部参照が含まれる場合があります。

また、ソース環境については次の点に注意してください。

- WebLogic ServerドメインでcopyConfigスクリプトを実行する前に、管理サーバーと管理対象サーバーが実行されていることを確認してください。

- Windowsの場合、使用環境が、システム・コンポーネントが含まれるWebLogic Server domainドメインである場合、WebLogic ServerドメインでcopyConfigスクリプトを実行する前に、ノード・マネージャを停止する必要があります。管理サーバーおよび管理対象サーバーは稼働している必要がありますが、システム・コンポーネントは稼働していない必要があります
Windows以外のオペレーティング・システムの場合、WebLogic Serverドメインおよびスタンドアロン・ドメインについては、ソース環境でcopyConfigドメインを実行する場合、任意のシステム・コンポーネントを起動または停止できます。いずれの場合も、copyConfig操作は完了します。

- Oracle Web Services Managerの場合は、copyConfigスクリプトを実行する前に、Oracle Web Services Managerポリシー・マネージャ・アプリケーションのデプロイ先のサーバーが実行されている必要があります。

20.2.3 移行スクリプトがキーストアを処理する方法の理解

Oracle Fusion Middlewareでは、次の2つのタイプのキーストアがサポートされています。

- JKS: Javaキーストア

- KSS: Oracle Platform Security Servicesキーストア・サービス。キーストア・サービスは、Oracle JRFを含むドメインを作成した場合にのみ使用できます。

キーストア関連のプロパティは、次の状況である移動計画のすべてのサーバーに対して移入されます。

- 構成されているキーストアに関係なく、ソース・ドメインでSSLが有効化されている場合(管理サーバー・ポートまたは管理サーバーのSSLポートのいずれか)。

- ソース・ドメインで非SSLポートのみが有効化されており、管理サーバーのキーストアが次のタイプのいずれかである場合。

- CustomIdentityandCustomTrust

- CustomIdentityandJavaStandardTrust

- CustomIdentityandCommandLineTrust

- ソース・ドメインで非SSLポートのみが有効化されており、DemoIdentityAndDemoTrustキーストアが構成されている場合、キーストア関連のプロパティは移動計画に移入されません。

ソース環境が構成されている方法に関係なく、pasteConfigスクリプトを使用して構成をターゲットに移動する場合は、移動計画のプロパティを構成する方法について次の点に注意する必要があります。

- Oracle JRFで構成されているドメインの場合:

- すべてのサーバーは、同じキーストアを持っている必要があります。

- キーストア・タイプ(JKSまたはKSS)は、すべてのサーバーで同じにする必要があります。

- 移動計画を変更して、キーストア・タイプをJKSからKSS、またはKSSからJKSに変更できます。

- Oracle JRFで構成されていないドメインの場合:

- すべてのサーバーは、同じキーストアを持っている必要があります。

- JKSキーストアのみを使用できます。

- Oracle JRFで構成されているドメインおよびOracle JRFなしで構成されているドメインの両方に対して、キーストアをソースからターゲットに変更できます。ソースが非SSLのみでDemoIdentityAndDemoTrustである場合を除けば、たとえキーストアの値がソースにあるとしても、次のいずれかの値に変更できます。

- DemoIdentityAndDemoTrust

- CustomIdentityAndCustomTrust

- CustomIdentityAndJavaStandardTrust

- CustomIdentityAndCommandLineTrust

20.2.4 ターゲット環境の準備

この章の手順を使用するには、ターゲット環境が次の前提条件を満たしている必要があります。

- コピーするOracleホームおよびコンポーネントのバージョンと互換性のあるcloningclient.jarファイルおよび移行スクリプト(pasteBinaryなど)を使用する必要があります。この章の手順では、現行バージョンのcloningclient.jarファイルおよび移行スクリプトを使用することを前提としています。

- ターゲット環境は、ソース環境と同じオペレーティング・システム上にある必要があります。また、オペレーティング・システム・アーキテクチャは、両方の環境で同じでなければなりません。たとえば、両方の環境で32ビットのオペレーティング・システムまたは64ビットのオペレーティング・システムを実行している必要があります。

- スクリプトを実行するときに、対応するJavaホームを指定する必要があります。つまり、Oracleホームが64ビットの場合、64ビットのJavaホームを指定する必要があります。Oracleホームが32ビットの場合、32ビットのJavaホームを指定する必要があります。

- ホストには、JDK 1.8.0_x以降がインストールされている必要があります。

- ターゲット環境では、ソース環境のユーザーと同じスーパーユーザーまたは管理ユーザーが必要です。インストールの移行が完了したら、ターゲット環境でユーザーを変更できます。

- ターゲット環境のデータベースは、ソース環境のデータベースと同じタイプである必要があります。たとえば、ソース環境のデータベースがOracle Databaseである場合、ターゲット環境のデータベースもOracle Databaseである必要があります。ターゲット環境のデータベースは、ソース環境のデータベースと同じバージョンである必要があります。

- データベースが適切に調整されていない場合、copyConfig操作およびpasteConfig操作でパフォーマンスの問題が発生することがあります。このようなパフォーマンスの問題を回避するには、次の標準データベース・パフォーマンス調整ガイドラインに加えて、MDS表のインポート用に、データベースに十分なRAMが割り当てられていることを確認します。また、次のプロシージャを実行して、ターゲット・データベースに対する統計を実行します。

BEGIN
dbms_stats.gather_schema_stats(ownname => 'prefix_MDS',
METHOD_OPT => 'FOR ALL COLUMNS SIZE AUTO',
CASCADE => TRUE, ESTIMATE_PERCENT => NULL);
END;

このプロシージャでは、prefix_MDSは、インストールのMDSスキーマ名です。

- ソース環境がSSL専用の環境である場合、移行スクリプトを実行する前に、ソース環境内のキーストアおよび資格証明を必ず構成してください。

- Oracle Fusion MiddlewareがインストールされていないホストにOracleホームのアーカイブを適用する場合、次の点に注意してください。

- ソース・ホストの次の場所からpasteBinaryスクリプトをターゲット・ホストにコピーします。

(UNIX) ORACLE_HOME/oracle_common/bin/pasteBinary.sh
(Windows) ORACLE_HOME\oracle_common\bin\pasteBinary.cmd

Windowsの場合、pasteBinary.shはコピーしません。

- ソース・ホストの次のファイルをターゲット・ホストにコピーします。

(UNIX) ORACLE_HOME/oracle_common/jlib/cloningclient.jar
(Windows) ORACLE_HOME\oracle_common\jlib\cloningclient.jar

- ORACLE_HOME/oracle_common/bin以外の場所からpasteBinaryスクリプトを実行する場合は、pasteBinaryスクリプトとcloningclient.jarファイルが同一ディレクトリにある必要があります。
前のOracle Fusion MiddlewareインストールがないホストでpasteBinaryを実行する場合、pasteBinaryを実行する前にORACLE_HOME/oracle_common/binは存在していないため、pasteBinaryスクリプトとcloningclient.jarは同じディレクトリに存在する必要があります。

- ファイルに実行権限があることを確認してください。

- 移動計画で指定するポートはターゲット・マシン上で使用可能である必要があります。pasteConfigスクリプトは、指定されたポートが使用可能であるかどうかをチェックします。

- Windowsでは、ファイルMSVCR90.DLLがターゲット・ホストに存在する必要があります。そうでない場合、pasteConfigは失敗します。
このファイル(または、このファイルの様々なバージョン)は、次の下のディレクトリ・ツリーに置かれています。

(Windows 32 bit) C:\Windows\System32
(Windows 64 bit) C:\Windows\winsxs

- Windowsの場合、Oracle Traffic DirectorおよびOracle HTTP Serverを正常に移行するには、MS Visual C++バージョン12.0がインストールされている必要があります。

20.2.5 ソース環境からターゲット環境への移行に関する制限事項

次の制限事項に注意してください。

- ソース環境とターゲット環境は、同じエンコーディングを使用している必要があります。たとえば、ソース環境がja_JP.utf8ロケール・エンコーディングを使用しており、ターゲット環境がja_JPロケール・エンコーディングを使用している場合、ターゲットで一部のファイル名が正しく処理されない可能性があります。

- 移行スクリプトはWebSphereベースの環境をサポートしていません。

- コンポーネントの構成を移行すると、スクリプトによりソースのトポロジがレプリケートされます。たとえば、ソース・ドメインにホストAの管理対象サーバーserver_1とserver_2、およびホストBの管理対象サーバーserver_3とserver_4が含まれる場合、ターゲットにも同様の管理対象サーバーとホストの関係を指定する必要があります。(移動計画のそれぞれの管理対象サーバーに対してホストを指定します。)

- カスタム・アプリケーションで内部データ・ソースを使用する場合(たとえば、JDeveloperを使用してアプリケーションが作成され、内部データ・ソースとともにデプロイされている場合など)、pasteConfig操作では内部データ・ソースは移行されません。
この問題を解決するには、ドメインに外部データ・ソースを作成し、アプリケーションでそのデータ・ソースを使用するように変更して、アプリケーションを再度デプロイします。

- ソースOracleホームで、Oracleホームの外部にあるJDKを使用する場合、pasteBinary操作でも外部のJDKを使用する必要があります。

- ソースとターゲットで使用されているJDKが同じである必要があります。

- ソースとターゲットで使用されているJDKが同じである必要があります。たとえば、ソースでJava SEを使用する場合は、ターゲットでもJava SEを使用する必要があります。

- ソースおよびターゲットで使用されるベンダーは同じである必要があります。たとえば、ソースでOracle JDKを使用する場合は、ターゲットでもOracleのJDKを使用する必要があります。

- ソースおよびターゲットで使用されるJDKのメジャー・バージョンは、同じである必要があります。たとえば、ソースでバージョン1.8を使用する場合は、ターゲットでも1.8を使用する必要があります。

- 複数のドメインに対して同じ共有セキュリティ・ストアを使用することはできません。

- エンティティを移行する際に一時ディレクトリに十分な領域がない場合は、その旨を示すエラーが返されます。この問題が発生しないようにするには、第A.1.2項で説明しているように、T2P_JAVA_OPTIONS環境変数を使用して、一時ディレクトリとして別の場所を指定します。

- 環境を移行して、カスタムのインベントリの場所を使用(invPtrLocパラメータを使用)してpasteBinaryスクリプトを実行した場合、次のいずれかの引数を使用してrunInstallerを起動する必要があります。

-invPtrLoc custom_inventory_pointer_location

- Oracle Platform Security Servicesを移行していて、LDAP間でデータを移動している場合、ソースおよびターゲットのLDAPドメイン・コンポーネントの階層は同じである必要があります。同一でないと、Oracle Platform Security Servicesのデータ移行は失敗します。たとえば、ソースの階層がdc=us,dc=comとして構成されている場合、ターゲットのLDAPは同じドメイン・コンポーネントの階層を持っている必要があります。

- ドメインでOracle Service Busが構成されている場合、pasteConfig操作時に最初に管理サーバーを起動した際に、次のエラーが表示されることがあります。

Failed to initialize the application "Service Bus Framework Starter
Application" due to error java.lang.RuntimeException: OSB system user
authentication failed java.lang.RuntimeException: OSB system user authentication failed

このエラーは無視できます。

20.2.6 ソース環境からターゲット環境への移行手順の概要

この項では、インストールをソース環境からターゲット環境に移行する一般的な手順について説明します。表20-1に、この手順を示すフローチャートを表示します。

表20-1 環境を移行するためのフローチャート

一般的な手順は次のとおりです。

1. ソース環境をチェックします。第20.2.2項を参照してください。

2. ターゲット環境を準備します。第20.2.4項を参照してください。

3. 環境でデータベースを使用している場合は、新しいデータベースを作成します。第20.3.1項を参照してください。

4. Oracleホームにあるバイナリ・ファイルのコピーを、ソース環境からターゲット環境に移行します。

- copyBinaryおよびpasteBinaryスクリプトを使用します(第20.3.2項を参照)。

- ストレージ・レベルのクローニング・ツールを使用(環境でサポートされている場合)して、既存のディスク・ボリュームのコピーを作成し、それを別の場所に移動します。次に、pasteBinaryスクリプトを使用して、必要なインベントリ情報、ファイル権限および正しいORACLE_HOMEパスのための文字列置換を作成または更新することにより、ターゲットOracleホームを正しいOracleホームに変換します。第20.3.3項を参照してください。
この方法は、環境が1つのディスク・ボリュームにある場合に使用できます。

5. ドメインおよびコンポーネントの構成のコピーを移行します。ほとんどの場合、copyConfig、extractMovePlanおよびpasteConfigスクリプトを使用します。従う手順は、ご使用のトポロジによって異なります。

- Javaコンポーネントのみ、またはJavaコンポーネントとシステム・コンポーネントを含むWebLogic Serverドメインの構成を移行するには、第20.3.4項を参照してください。

- 複数のシステム・コンポーネントを含むスタンドアロン・ドメインの構成を移行するには、第20.3.5項を参照してください。

6. 第20.3.6項で説明するような特定の状況では、ノード・マネージャがソース環境で構成されている場合に、その構成のコピーを別途移行する必要があります。

7. 一部のコンポーネントで必要になる追加の手順を実行します。各コンポーネントに固有の情報については、第20.4項を参照してください。
その他のデータ(UMSユーザー・メッセージング・プリファレンスまたはOracle WebCenter Portalアプリケーションのデータ)を移行します。新しい環境に固有の情報(ホスト名、ポートなど)を変更します。各コンポーネントに固有の情報については、第20.4項を参照してください。

8. サーバーとコンポーネントを起動します。第20.3.9項を参照してください。

20.3 ターゲット環境への移行の一般的な手順

Oracle Fusion Middlewareコンポーネントの多くで、ソース環境からターゲット環境に移行する際に、共通の手順を使用します。ただし、すべてのコンポーネントがこれらの手順のすべてまたはそれらの一部を使用するわけではありません。また、一部コンポーネントでは追加の手順が必要な場合があります。特定のコンポーネントを移行する際に追加の手順が必要かどうか、表20-2でチェックする必要があります。

この項では、共通の手順について、次のとおり説明します。

- ターゲット環境でのデータベースのインストール

- スクリプトを使用したOracleホームおよびバイナリ・ファイルの移行

- ストレージ・レベルのクローニング・ツールを使用したOracleホームおよびバイナリ・ファイルの移行

- WebLogic Serverドメインの構成の移行

- スタンドアロン・ドメインの構成の移行

- ノード・マネージャの構成の移行

- ユーザーおよびグループの構成

- SSL専用の環境での追加考慮事項

- 管理対象サーバーおよびコンポーネントの起動

この項の手順では、標準的なインストール・トポロジが使用されていると仮定しています。このトポロジは、1つの管理サーバーを含む1つのWebLogic Serverドメインと、1つのホスト上の2つの管理対象サーバーまたはシステム・コンポーネントを含むスタンドアロン・ドメインが含まれているクラスタで構成されます。

複数のマシンにわたる分散トポロジの場合は、第20.6項を参照してください。

注意:
これらの手順および移動計画で使用するスクリプトでは、通常、パスワードを含むファイルを指定する必要があります。不明瞭化したパスワードを含むファイルを生成するには、第A.1.2.10項で説明されているobfuscatePasswordスクリプトを使用します。

20.3.1 ターゲット環境でのデータベースのインストール

Oracle Application Development Framework、Oracle SOA Suiteなどの一部のコンポーネントでは、メタデータを格納するためにデータベースを使用することがあります。

ターゲット環境のデータベースは、ソース環境のデータベースと同じタイプである必要があります。たとえば、ソース環境のデータベースがOracle Databaseである場合、ターゲット環境のデータベースもOracle Databaseである必要があります。ターゲット環境のデータベースは、ソース環境のデータベースと同じバージョンである必要があります。

新しいデータベースをインストールする手順は次のとおりです。

1. データベース・ソフトウェアをインストールして構成します。

2. RCUを使用してターゲット・データベースで必要なスキーマを作成します。『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

3. アプリケーションで使用するカスタム・スキーマを作成します。たとえば、アプリケーションがソース環境でカスタム・スキーマを使用する場合、ターゲット環境でそのスキーマを作成します。

20.3.2 スクリプトを使用したOracleホームおよびバイナリ・ファイルの移行

copyBinaryおよびpasteBinaryスクリプトを使用して、Oracleホームのコピーをターゲット環境に移行できます。

- copyBinaryスクリプトによって、ソースの準備が実行され、アーカイブが作成されます。また、Oracleホームのファイル権限も記録されます。
このアーカイブには、Oracle WebLogic ServerホームやOracle HTTP Serverホームなどの製品ホームを含む、Oracleホームが含まれています。

- pasteBinaryスクリプトによって、クローニング先で前提条件が満たされているかどうかが確認されます。アーカイブ・ファイルから複数のファイルが抽出され、OracleホームがOracleインベントリに登録されます。
次に、スクリプトによってファイル権限がリストアされ、必要に応じてリンクが再設定されます。

次の点に注意してください。

- copyBinaryおよびpasteBinaryスクリプトを実行しても、ソースOracleホームおよび製品ホーム(WebLogic Serverホームなど)の、ロード可能なモジュールやアプリケーション固有のライブラリなどのすべての依存関係が、ターゲット・ホームに継承されるわけではありません。スクリプトによって、Oracleホームおよびソースの製品ホーム全体がコピー先のOracleホームにコピーされるためです。ソースのWebLogic ServerまたはOracleホームの外部にあるファイルは、自動的にはコピーされません。そのため、ソースのWebLogic ServerまたはOracleホームの外部にあるファイルを参照するアプリケーションは、ターゲット・ホームで正しく機能しない場合があります。

- Oracleホームをコピーする場合は、Oracleホームの読取り専用部分のみがコピーされます。user_projectsディレクトリなどのユーザー構成ファイルは、アーカイブから除外されます。WebLogic Serverドメインはコピーされません。(copyConfigおよびpasteConfigスクリプトを使用して、ドメインをコピーします。)

- パスがシンボリック・リンクの場合、Oracleホームを移行することはできません。

関連項目:
この項で使用されるスクリプトの場所については、表A-1を参照してください。

Oracleホームを移行する手順は次のとおりです。

1. ソースでcopyBinaryスクリプトを実行します。これにより、OracleホームおよびWebLogic Serverホームなど、Oracleホームに含まれている製品ホームがコピーされます。

copyBinaryスクリプトの構文については、第A.1.2.1項を参照してください。

たとえば、/scratch/oracle/Oracle_home1にあるOracleホームをコピーするには、次のコマンドを使用します。

copyBinary.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/oh_copy.jar
-sourceOracleHomeLoc /scratch/oracle/Oracle_home1

2. Oracleホームを別のホストにコピーする場合は、アーカイブ・ファイルをそのシステムにコピーするか、または、ストレージ・レベルのクローニングを使用している場合は、ボリュームのスナップショット・コピーをターゲット・システムにコピーし、そのボリュームをマウントします。

3. pasteBinaryスクリプトとcloningclient.jarファイルをターゲット・システムにコピーし、実行権限があることを確認します。
cloningclient.jarファイルは次の場所にあります。

(UNIX) ORACLE_HOME/oracle_common/jlib/cloningclient.jar
(Windows) ORACLE_HOME\oracle_common\jlib\cloningclient.jar

pasteConfigなど他のスクリプトをコピーしないでください。これらのスクリプトは、ステップ5で説明しているように、ファイルの抽出時に生成されます。

4. LinuxとUNIXでは、インストールされているOracle製品がターゲット・システムにない場合、oraInst.locファイルを作成し、Oracleインベントリ(oraInventory)に対する書込みアクセス権が付与されているメンバーの所属グループとOracleインベントリの格納先を指定する必要があります。たとえば、oraInst.locファイルには次を含めることができます。

inst_group=dba
inventory_loc=/scratch/oracle1/oraInventory

そして、その場所がデフォルトの場所ではない場合、-invPtrLocオプションをpasteBinaryスクリプトに使用して、oraInst.locファイルの場所を指定します。(LinuxおよびAIXの場合、デフォルトの場所は/etc/oraInst.locで、その他のUNIXプラットフォームの場合は、/var/opt/oracle/oraInst.locです。)

5. クローニング先で、pasteBinaryスクリプトを使用して、アーカイブからファイルを抽出します。pasteBinaryスクリプトの構文については、第A.1.2.2項を参照してください。

注意:
Oracleホームの親ディレクトリが存在しない場合は、pasteBinaryスクリプトにより作成されます。
Oracleホーム(たとえば、Oracle_Home_prod)の実際のディレクトリは、存在してはいけないか、または既存の空のディレクトリにする必要があります。

たとえば、/scratch/oracle/ORACLE_HOME_prodディレクトリにアーカイブを適用するには、次のコマンドを使用します。

pasteBinary.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc  /tmp/oh_copy.jar
-targetOracleHomeLoc /scratch/oracle/ORACLE_HOME_prod
-targetOracleHomeName ORACLE_HOME_prod
-invPtrLoc /scratch/oracle/oraInventory

Oracleホームは/scratch/oracle/ORACLE_HOME_prodに抽出され、製品ホームはソースの製品ホームの名前と同じ名前でその下に抽出されます。

6. copyBinaryおよびpasteBinaryスクリプトでは、user_projectsディレクトリはコピーされません。これらのスクリプトでは、Oracleホームにある他のドメイン・ディレクトリがコピーされて貼り付けられます。ただし、これらのドメイン・ディレクトリは機能しません。(ドメイン・ディレクトリは、Oracleホームの下には作成しないことをお薦めします。)
pasteConfigスクリプトにより、ドメイン・ディレクトリがターゲット環境で再作成されるため、pasteConfigコマンドを実行する前に、ドメイン・ディレクトリをターゲットから削除してください(第20.3.4項を参照)。

7. ターゲットでは、ノード・マネージャがホストごとにOracleホームの下にある場合は、ノード・マネージャのディレクトリおよびその中のファイルを削除します。
この状態で、ノード・マネージャを第20.3.6に従って移行します。

20.3.3 ストレージ・レベルのクローニング・ツールを使用したOracleホームおよびバイナリ・ファイルの移行

copyBinaryスクリプトのかわりに、Oracle Solaris ZFSやNetApp Flex Cloningなどのストレージ・レベルのクローニング・ツールを使用して、既存のディスク・ボリュームのコピーを作成し、それを別の場所に移行できます。

この方法は、環境が1つのディスク・ボリュームにある場合に使用できます。

ストレージ・レベルのクローニング・ツールを使用してOracleホームおよびバイナリ・ファイルを移行する手順は、次のとおりです。

1. クローニング・ツールを使用して、ディスク・ボリュームをターゲット環境にレプリケートします。
詳細は、ご使用のディスク・ボリュームのドキュメントを参照してください。

2. ターゲットで、pasteBinaryスクリプトを-ohAlreadyClonedオプションを指定して使用します。このオプションを指定すると、必要なインベントリ情報、ファイル権限および正しいORACLE_HOMEパスのための文字列置換が、pasteBinaryスクリプトにより作成または更新されます。
pasteBinaryスクリプトの構文については、第A.1.2.2項を参照してください。

たとえば、/scratch/oracle/ORACLE_HOME_prodディレクトリにアーカイブを適用するには、次のコマンドを使用します。

pasteBinary.sh -javaHome /scratch/oracle/jdk1.8.0_40
-ohAlreadyCloned  true
-targetOracleHomeLoc /scratch/oracle/ORACLE_HOME_prod
-targetOracleHomeName ORACLE_HOME_prod

3. ターゲットでは、ノード・マネージャが「ホストごとに」Oracleホームの下にある場合は、ノード・マネージャのディレクトリおよびその中のファイルを削除します。
この状態で、ノード・マネージャを第20.3.6に従って移行します。

4. ストレージ・レベルのクローニング・ツールはユーザー・ディレクトリ全体をコピーするため、ドメイン・ディレクトリがソース環境で構成されていた場合は、バイナリ・ファイルだけではなく、ドメイン・ディレクトリもコピーされます。ただし、これらのドメイン・ディレクトリは正しく構成されていないので、機能しません。
pasteConfigコマンドにより、正しく構成されたドメイン・ディレクトリがターゲット環境で再作成されるので、このコマンドを実行する前に、ドメインディレクトリをターゲットから削除してください(第20.3.4項を参照)。

20.3.4 WebLogic Serverドメインの構成の移行

copyConfig、extractMovePlanまたはpasteConfigスクリプトを使用して、WebLogic Serverドメインの構成のコピーを移行できます。 domain configuration using the この手順により、ドメイン、管理サーバーと管理対象サーバーおよびドメイン内のすべてのコンポーネントの構成のコピーが移行されます。

コンポーネントの構成を移行すると、スクリプトによりソースのトポロジがレプリケートされます。たとえば、ソース・ドメインにホストAの管理対象サーバーserver_1とserver_2、およびホストBの管理対象サーバーserver_3とserver_4が含まれる場合、ターゲットにも同様の管理対象サーバーとホストの関係を指定する必要があります。(移動計画のそれぞれの管理対象サーバーに対してホストを指定します。)

ドメイン・ディレクトリは各マシンに対してローカルです。pasteConfigスクリプトは管理サーバー・ドメイン・ディレクトリでのみ実行されます。その後、管理対象サーバーのディレクトリが管理サーバーと異なる場合は、Oracle WebLogic Serverのpackおよびunpackコマンドを使用して、管理対象サーバーのドメイン・ディレクトリを再作成する必要があります。詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』を参照してください。

通常、ユーザーに固有のデータはターゲット環境とソース環境で同じではないため、この処理では、ユーザー固有のデータは移行されません。

関連項目:
この項で使用されるスクリプトの場所については、表A-1を参照してください。

注意:
IBM JDKを使用する場合、copyConfigおよびpasteConfigスクリプトのT2P_JAVA_OPTIONSパラメータを使用して最大永続生成領域(-XX:MaxPermSize=value)を設定します。

ドメイン構成のコピーを移行する手順は、次のとおりです。

1. ソースで、管理サーバーおよびすべての管理対象サーバーが起動されていることを確認します。

2. SSL専用の環境を持つOracle SOA Suiteの場合、『Oracle B2Bユーザーズ・ガイド』のSSL専用のドメインでのコマンド行ユーティリティの実行に関する項で説明されているように、SSLを有効にします。

3. Windowsの場合、使用環境が、システム・コンポーネントが含まれるWebLogic Server domainドメインである場合、WebLogic ServerドメインでcopyConfigスクリプトを実行する前に、ノード・マネージャを停止する必要があります。

4. ソースで、自動的にロックを取得するようにドメイン構成が設定されていないことを確認します。開発モードでドメインを構成した場合は、ロックの自動取得が有効になっています。本番モードでドメインを構成した場合は、デフォルトで無効になっています。次の手順を実行します。

1. 管理コンソールで「プリファレンス」をクリックします。

2. 「プリファレンス」タブで、「ロックを自動取得して変更をアクティブ化」の選択を解除します。

3. 「保存」をクリックします。

4. 「チェンジ・センター」で、該当する場合は「構成の解放」をクリックします。

5. ソースで次のスクリプトを実行して、domainAdminPasswordFileパラメータに必要な不明瞭化したパスワード・ファイルを生成します。

(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh
-javaHome path_to_java_home
(Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd
-javaHome path_to_java_home

スクリプトによって、パスワードおよびパスワード・ファイルが書き込まれるパス(ファイル名を含む)の入力を求めるプロンプトが表示されます。

6. ソースでcopyConfigスクリプトを実行して、ドメイン構成をコピーします。

copyConfigスクリプトは、次の場所にあります。

(UNIX) ORACLE_HOME/oracle_common/bin/copyConfig.sh
(Windows) ORACLE_HOME\oracle_common\bin\copyConfig.cmd

copyConfigスクリプトの構文については、第A.1.2.3項を参照してください。

たとえば、Oracleホーム/scratch/oracle/Oracle_home1のWLS_domain1という構成をコピーするには、次のコマンドを使用します。

copyConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/wls.jar
-sourceDomainLoc /scratch/oracle/domains/WLS_domain1
-sourceOracleHomeLoc /scratch/oracle/Oracle_home1
-domainHostName example.com
-domainPortNum 8001
-domainAdminUserName domain_admin_username
-domainAdminPasswordFile /scratch/admin/passwd.txt
-logDirLoc /tmp/logs

Oracle Service Busでは、copyConfigスクリプトの使用時に、キーosb.configuration.passphrase.fileおよびパスフレーズを含むファイルの絶対パスを指定するキー値とともに-additionalParamsオプションを渡す必要があります。次に例を示します。

-additionalParams osb.configuration.passphrase.file=/scratch/passwd/osb_passwd

このオプションを指定しないと、エクスポートされた構成はパスワードで保護されません。

7. ドメイン構成を別のホストにコピーする場合は、そのシステムにアーカイブ・ファイルをコピーします。

8. ソースでextractMovePlanスクリプトを使用して、アーカイブから移動計画を抽出します。
extractMovePlanスクリプトの構文については、第A.1.2.6項を参照してください。

次に例を示します。

extractMovePlan.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/wls.jar
-planDirLoc /tmp/Oracle/t2p_plans/wls

注意:
ソース環境に変更を加えていなくても、copyConfigスクリプトを使用するたびに、新しい移動計画を抽出する必要があります。pasteConfigスクリプトによって、移動計画とアーカイブが一致することが確認されます。一致しない場合は、スクリプトによりエラーが返されます。

9. ターゲット環境の値にあわせてプロパティを変更するために、移動計画を編集します。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。移行するコンポーネントのタイプごとのプロパティのリストについては、表A-11を参照してください。
Oracle WebCenter ContentサーバーまたはOracle WebCenter Content: Recordsの場合、移動計画で次のいずれかのオプションを指定します。

- copy: このオプションは、構成およびデータを含むソース・システム全体をターゲット・システムにコピーします。これはデフォルトのオプションですが、これに伴うテスト・データの移行がご使用の環境に適さない場合があるため、このオプションの使用はお薦めしません。

- init: このオプションは、ターゲット・システムの新しいContentサーバーまたはRecordsインスタンスを初期化します。これによって、データは移行されません。

表A-26の説明に従って、移動計画のMoveType configPropertyでcopyまたはinitオプションを指定します。その後、configGroupにリストされているプロパティを変更します。

これらのオプションの詳細は、第20.4.7項を参照してください。

10. extractMovePlanスクリプトによってデプロイメント・プランが生成された場合、次の場所にあるデプロイメント・プラン・ファイル内のOracleホームおよびドメイン・ホームの場所を更新します。

planDirLoc/deployment_plans

11. 編集済の移動計画を、extractMovePlanスクリプトで作成したすべてのフォルダとともに、ターゲットにコピーします。(これらのフォルダは、planDirLocパラメータで指定した場所に置かれています。)
pasteConfig操作時には、-movePlanLocオプションを使用して場所を指定します。

12. ターゲットで次のスクリプトを実行して、移動計画に必要な不明瞭化したパスワード・ファイルを生成します。パスワード・ファイルごとにスクリプトを実行します。

(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh  -javaHome path_to_java_home
(Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd -javaHome path_to_java_home

スクリプトによって、パスワードおよびパスワード・ファイルが書き込まれるパス(ファイル名を含む)の入力を求めるプロンプトが表示されます。

13. ターゲットで、pasteConfigスクリプトを使用してアーカイブからファイルを抽出します。

スクリプトの構文については、第A.1.2.7項を参照してください。

たとえば、アーカイブをOracleホーム/scratch/oracle/Oracle_home1に適用するには、次のコマンドを使用します。

pasteConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/wls.jar
-movePlanLoc /tmp/Oracle/t2p_plans/wls/moveplan.xml
-targetDomainLoc /scratch/oracle/config/domains/WLS_domain1
-targetOracleHomeLoc /scratch/oracle/Oracle_home1/
-domainAdminPasswordFile /scratch/pwd_dir/passwd.txt

14. 管理対象サーバーが管理サーバーと同じホスト上に置かれていない場合は、Oracle WebLogic Serverのpackおよびunpackコマンドを使用して、管理対象サーバーのドメイン・ディレクトリを再作成する必要があります。詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』を参照してください。

15. 第20.3.7項の説明に従って、ユーザーおよびグループを構成します。

この作業が完了した際に、第20.4項の説明に従って、一部のコンポーネントで追加手順の実行が必要な場合があります。

20.3.5 スタンドアロン・ドメインの構成の移行

複数のシステム・コンポーネントを含むスタンドアロン・ドメインの構成を移行できます。たとえば、Oracle HTTP Serverをスタンドアロン・ドメインにインストールしたとします。

関連項目:
この項で使用されるスクリプトの場所については、表A-1を参照してください。

システム・コンポーネントを含むスタンドアロン・ドメインの構成を移行するには、

1. ソースで、copyConfigスクリプトを実行して構成をコピーします。
copyConfigスクリプトの構文については、第A.1.2.4項を参照してください。

たとえば、Oracleホームの/scratch/oracle/Oracle_home1のOHS_domain1というドメインの構成をコピーするには、次のコマンドを使用します。

copyConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/stdalone_dom.jar
-sourceDomainLoc /scratch/oracle/domains/OHS_domain1
-sourceOracleHomeLoc /scratch/oracle/Oracle_home1/

このスクリプトを実行する前に、ノード・マネージャを停止する必要はありません。

2. 構成を別のホストにコピーする場合は、そのシステムにアーカイブ・ファイルをコピーします。

3. ソースでextractMovePlanスクリプトを使用して、copyConfigスクリプトにより作成したアーカイブから移動計画を抽出します。
extractMovePlanスクリプトの構文については、第A.1.2.6項を参照してください。

次に例を示します。

extractMovePlan.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/stdalone_dom.jar
-planDirLoc /tmp/Oracle/t2p_plans/

注意:
ソース環境に変更を加えていなくても、copyConfigスクリプトを使用するたびに、新しい移動計画を抽出する必要があります。pasteConfigスクリプトによって、移動計画とアーカイブが一致することが確認されます。一致しない場合は、スクリプトによりエラーが返されます。

4. ターゲット環境の値にあわせてプロパティを変更するために、移動計画を編集します。移行するコンポーネントのタイプごとのプロパティのリストについては、表A-11を参照してください。

5. extractMovePlanスクリプトによってデプロイメント・プランが生成された場合、次の場所にあるデプロイメント・プラン・ファイル内のOracleホームおよびドメイン・ホームの場所を更新します。

planDirLoc/deployment_plans

6. 編集済の移動計画を、extractMovePlanスクリプトで作成したすべてのフォルダとともに、ターゲットにコピーします。(これらのフォルダは、planDirLocパラメータで指定した場所に置かれています。)
pasteConfig操作時には、-movePlanLocオプションを使用して場所を指定します。

7. ターゲットで次のスクリプトを実行して、移動計画に必要な不明瞭化したパスワード・ファイルを生成します。パスワード・ファイルごとにスクリプトを実行します。

(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh  -javaHome path_to_java_home
(Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd -javaHome path_to_java_home

スクリプトによって、パスワードおよびパスワード・ファイルが書き込まれるパス(ファイル名を含む)の入力を求めるプロンプトが表示されます。

8. ターゲットで、pasteConfigスクリプトを使用してアーカイブからファイルを抽出します。
スクリプトの構文については、第A.1.2.7項を参照してください。

たとえば、アーカイブをOracleホーム/scratch/oracle/Oracle_home1に適用するには、次のコマンドを使用します。

pasteConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/stdalone_dom.jar
-targetDomainLoc /scratch/oracle/config/domains/dom_cl
-targetOracleHomeLoc /scratch/oracle/Oracle_home1
-movePlanLoc /tmp/Oracle/t2p_plans/move_plan.xml
-logDirLoc /tmp/log

20.3.6 ノード・マネージャの構成の移行

ノード・マネージャがソース環境で構成される場合は、次の条件でノード・マネージャを別途移行する必要があります。

- ノード・マネージャは「ホストごと」です。

- 複数ホストの環境で、ノード・マネージャは「ドメインごと」で構成はドメイン・ディレクトリ内にあるが、各ホストにはそのホストにだけ適用可能な、カスタマイズされたノード・マネージャ・プロパティがある。

ノード・マネージャがドメインごとの場合、ドメインを移行するためのスクリプトにより、ノード・マネージャも移行されます。

関連項目:
この項で使用されるスクリプトの場所については、表A-1を参照してください。

ノード・マネージャの構成を移行する手順は、次のとおりです。

1. ソースにおいて、ノード・マネージャが実行されていることを確認します。

2. ソースでcopyConfigスクリプトを実行して、ノード・マネージャ構成をコピーします。

スクリプトの構文については、第A.1.2.5項を参照してください。たとえば、次のコマンドを使用します。

copyConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/nm.jar
-sourceNMHomeLoc /scratch/oracle/Oracle_home1/wlserver/common/nodemanager
-logDirLoc /tmp/logs

3. ノード・マネージャを別のホストにコピーする場合は、そのシステムにアーカイブ・ファイルをコピーします。

4. ソースでextractMovePlanスクリプトを使用して、アーカイブから移動計画を抽出します。
extractMovePlanスクリプトの構文については、第A.1.2.6項を参照してください。

次に例を示します。

extractMovePlan.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/nm.jar
-planDirLoc /tmp/Oracle/t2p_plans/nm

5. ターゲット環境の値にあわせてプロパティを変更するために、移動計画を編集します。ノード・マネージャのプロパティのリストについては、表A-12と表A-13を参照してください。

6. 編集済の移動計画を、extractMovePlanスクリプトで作成したすべてのフォルダとともに、ターゲットにコピーします。(これらのフォルダは、planDirLocパラメータで指定した場所に置かれています。)
pasteConfig操作時には、-movePlanLocオプションを使用して場所を指定します。

7. ターゲットで次のスクリプトを実行して、移動計画に必要な不明瞭化したパスワード・ファイルを生成します。パスワード・ファイルごとにスクリプトを実行します。

(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh  -javaHome path_to_java_home
(Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd -javaHome path_to_java_home

スクリプトによって、パスワードおよびパスワード・ファイルが書き込まれるパス(ファイル名を含む)の入力を求めるプロンプトが表示されます。

8. ターゲットでは、pasteConfigスクリプトを使用してアーカイブからファイルを抽出します。
スクリプトの構文については、第A.1.2.9項を参照してください。

たとえば、次のコマンドを使用します。

pasteConfig -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/nm.jar
-targetNMHomeLoc /scratch/oracle/Oracle_home1/wlserver/common/nodemanager
-targetOracleHomeLoc /scratch/oracle/Oracle_home1
-movePlanLoc /tmp/Oracle/t2p_plans/nm/moveplan.xml

20.3.7 ユーザーおよびグループの構成

新しいターゲット環境でセキュリティを構成する必要があります。手順は、環境およびアプリケーションの構成によって異なります。

ターゲット環境のLDAPアイデンティティ・ストアでは、ソース環境と同じユーザーおよびグループを使用しない可能性や、すでにユーザーおよびグループが移入されている可能性があります。LDAPストアがOracle WebCenter Enterprise Captureの管理LDAPストアであり、ソース環境のユーザー、グループおよびパスワードをターゲット環境に移行する必要がある場合のみ、次の手順を実行します。

1. ldapsearchコマンドを使用して、ソース環境のLDAPアイデンティティ・ストアからユーザーおよびグループをエクスポートします。これにより、後でターゲット環境のLDAPアイデンティティ・ストアにインポートするldifファイルが作成されます。ldapsearchコマンドは、アイデンティティ管理コンポーネントのORACLE_HOME/binディレクトリにあります。次に例を示します。

ORACLE_HOME/bin/ldapsearch -h test_oid_host -p test_oid_port
-D "cn=orcladmin" -w "test_orcladmin_passwd" -b "cn=Users,dc=us"

2. 次の例で示すように、ldapaddmtコマンドを使用して、ソース環境からエクスポートしたldifファイルをターゲット環境にインポートします。(ORACLE_HOMEはアイデンティティ管理のOracleホームです。)

ORACLE_HOME/bin/ldapaddmt -h production_oid_host
-p production_oid_port -D "cn=orcladmin"
-w "production_orcladmin_passwd" -r -f ldif_filename

20.3.8 SSL専用の環境での追加考慮事項

SSL専用として構成されている環境を移行する場合、次の各事項に注意してください。

- Windowsでは、デモKSS証明書を持つSSL専用の環境の場合、管理対象サーバーを起動する前に次の環境変数を設定します。

set JAVA_OPTIONS=-Dweblogic.security.SSL.ignoreHostnameVerification=true

次に、次の項目に記載されている追加パラメータを使用して管理対象サーバーを起動します。

- デモKSS証明書を持つSSL専用の環境の場合、次の追加パラメータを渡して管理対象サーバーを起動します。

-Dweblogic.security.SSL.ignoreHostnameVerification=true)

次に例を示します。

StartManagedWebLogic.sh Managed_Server_name https://hostname:port_num
-Dweblogic.security.SSL.ignoreHostnameVerification=true

- カスタムJKS証明書を持つSSL専用の環境の場合、次のいずれかの手順を実行します。

- 管理対象サーバーを起動する前に、証明書をターゲットにインポートし、次のようなコマンドを使用します。

keytool -importcert -trustcacerts -alias hostalias -file
/scratch/oracle/keystores/hostalias_identity_exportcert.cer -keystore
/scratch/oracle/ORACLE_HOME/wlserver/server/lib/cacerts
-storepass changeit

- 管理対象サーバーを起動するときに信頼キーストアの場所を明示的に渡します。次に例を示します。

startManagedWebLogic.sh Managed_Server_name https://hostname:port_num
"-Dweblogic.security.SSL.trustedCAKeyStore=/scratch/Oracle/keystores/Hostname_trust.jks"

20.3.9 管理対象サーバーおよびコンポーネントの起動

移行手順が完了したら、管理サーバー、管理対象サーバー、ノード・マネージャおよびコンポーネントが停止されます。次の手順を実行します。

1. 第4.2.2項の説明に従って、ノード・マネージャを起動します。

2. 第4.2.1項の説明に従って管理サーバーを起動します。

3. 第4.2.3項の説明に従って、管理対象サーバーを起動します。

4. 第4.3項の説明に従って、各コンポーネントを起動します。

20.4 特定のコンポーネントに対する追加の手順または情報

表20-2に、特定のコンポーネントの移行を完了するために追加の手順が必要かどうか、または追加の情報を指定する必要があるかどうかを示します。

表20-2 新しい環境への移行に追加の手順を必要とするコンポーネント

コンポーネント

追加の手順

Oracle Application Development Framework

なし

Oracle B2B

第20.4.2項を参照してください

Oracle Business Activity Monitoring

なし

Oracle Business Process Management

第20.4.3項を参照

Oracle Coherence

なし

Oracle Data Integrator

第20.4.1項

Oracle Enterprise Data Quality

なし

Oracle Enterprise Scheduler

なし

Oracle Forms Services

第20.4.4項を参照してください。

Oracle HTTP Server

なし

Oracle Managed File Transfer

なし

Oracle Service Bus

第20.3.4項の手順6を参照

Oracle SOA Suite

なし

Oracle Traffic Director

第20.4.5項

Oracle User Messaging Service

なし

Oracle WebCenter Content

移動計画でのinitまたはcopyオプションの使用の詳細、およびSSL専用の環境の詳細は、第20.4.7項を参照してください。

Oracle WebCenter Portal

第20.4.6項を参照してください

Oracle WebCenter Sites

第20.4.8項を参照してください

Oracle Web Services Manager

なし

Oracle WebLogic Server

なし

20.4.1 Oracle Data Integrator移行のための追加手順

Oracle Data Integratorを移行する場合は、次の追加手順が必要です。

- RCUを使用して、ターゲット・データベースで必要なマスター・リポジトリおよび作業リポジトリのスキーマを作成します。『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。
ターゲット環境の作業リポジトリとマスター・リポジトリの両方が、それぞれ組織全体で一意のIDで作成されていることを確認します(これには、開発リポジトリとソース・リポジトリも含まれます)。さらに、ターゲットの作業リポジトリが、ソース・リポジトリと同じタイプで作成されていることを確認します(たとえば、ソースの作業リポジトリが開発リポジトリとして作成されている場合、ターゲットの作業リポジトリも開発リポジトリとして作成される必要があります)。

- Oracle Data IntegratorでRCUのカスタム変数の一部として作成されたODI作業リポジトリ名は、次の例に示すように、moveplan.xmlファイルの<configProperty id="WORKREP1">として反映されます。

...
<configProperty id="WORKREP1">
<configProperty>
<name>Url</name>
<value>jdbc:oracle:thin:@localhost:1521:ora1120</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
<configProperty>
<name>User</name>
<value>odi_work_11g</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
<configProperty>
@           <name>Password File</name>
<value>/tmp/all_pswd.txt</value>
<itemMetadata>
<dataType>STRING</dataType>
@              <password>true</password>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
</configProperty>
...

ここで重要なのは、moveplan.xmlでWORKREP1として反映されているデフォルトのODI作業リポジトリ名WORKREPは変更され、対応する名前の変更が本番環境で正確に反映されて、それに従うということです。

スキーマの作成の詳細は、『リポジトリ作成ユーティリティを使用したスキーマの作成』を参照してください。その他の情報は、RCUのオンライン・ヘルプに記載されています。

- 移行スクリプトを実行する前に、ODI Client (Studio)を使用してプロジェクトとモデルを作成します。

- copyConfigスクリプトを実行する場合は、次に注意してください。

- Agentの構成時には、構成ファイルをcopyConfigスクリプトに渡す必要があります。これを渡すには、引数odiCustomArgで-additionalParamsオプションを使用します。次に例を示します。

./copyConfig.sh -javaHome /private/Middleware/jrockit_160_26_D1.2.0-5
-archiveLocation /tmp/ar.jar
-sourceOracleHomeLoc /private/Middleware
-sourceDomainLoc /scratch/oracle/domains/base_domain
-domainHostName host1.example.com
-domainPortNum 7001
-domainAdminUserName weblogic
-domainAdminPasswordFile /tmp/wls_pswd.txt
-additionalParams odiCustomArg=/private/t2p/odiCustomArg.xml

ファイルodiCustomArg.xmlは構成ファイルです。サンプル・ファイルが次の場所にあります。

ORACLE_HOME/ODI_Oracle_Home/odi/plugin/t2p/odiCustomArg.xml

スクリプトに渡す構成ファイルには、すべてのOracle Data Integratorマスター・リポジトリの接続情報が含まれています。構成ファイルのサンプルを次に示します。

<?xml version="1.0" encoding="UTF-8" ?>
<config>
<masterRepositories>
<masterRepository>
<driver>oracle.jdbc.OracleDriver</driver>
<url>jdbc:oracle:thin:@localhost:1521:sid</url>
<schema>odi_master_12c</schema>
<schema_password_file>/tmp/all_pswd.txt</schema_password_file>
<supervisor>SUPERVISOR</supervisor>
<supervisor_password_file>/tmp/sup_pswd.txt</supervisor_password_file>
</masterRepository>
<masterRepository>
.....content for 2nd master repository
</masterRepository>
</masterRepositories>
</config>

次に構成ファイルのエントリを説明します。

- masterRepositories: ODIマスター・リポジトリのリストが含まれます。

- masterRepository: ODIマスター・リポジトリのセクション。

- driver: ODIマスター・リポジトリに接続するためのJDBCドライバ。

- url: ODIマスター・リポジトリに接続するためのJDBC URL。SIDまたはサービス名の使用に基づいて適切な構文を使用する必要があります。次のいずれかの形式を使用します。

<url>jdbc:oracle:thin:@hostname:port/servicename</url>
<url>jdbc:oracle:thin:@hostname:port:SID</url>

- schema: ODIマスター・リポジトリのスキーマ名。

- schema_password_file: スキーマのパスワードを含むファイルのパス。

- supervisor: ODIマスター・リポジトリのスーパーバイザ・ユーザー

- supervisor_password_file: スーパーバイザ・ユーザーのパスワードを含むファイルのパス。

- 移行スクリプトによって、移動計画で指定した情報に基づき、ターゲット環境の物理アーキテクチャが更新されます。ターゲット環境の物理アーキテクチャの次の項目を確認してから、次に進みます。

- 物理エージェント: ホスト、ポートおよびWebアプリケーション・コンテキスト(Java EEエージェント用)を、ターゲット環境の構成と一致するように変更します。

- データ・サーバー: データ・サーバーの接続に関する情報(JDBC、JNDI、データ・ソース名)を、ターゲット環境の構成と一致するように変更します。

- 物理スキーマ: データ・サーバー用に定義されたスキーマ(ファイル・フォルダの場所を含みます)は、ターゲット環境の構成と一致している必要があります。

- 移行の完了後に、ターゲット環境のJava EEエージェントを再起動します。これらのエージェントは、スケジュール済シナリオの処理を開始します。

20.4.2 Oracle B2B移行のための追加手順

移行スクリプトを実行すると、Oracle B2Bがターゲット環境に移行されます。ただし、次の追加の手順を実行する必要があります。

1. 『Oracle Platform Security Servicesによるアプリケーションの保護』のドメイン内のキーストア・サービス・アーティファクトの移行に関する項の説明に従って、キーストア・サービス証明書を移行し、B2Bインタフェースを使用してキーストア・パスワードを更新します。

2. 移行プロセスでは、アグリーメントがデプロイされ、チャネルが有効になります。移行プロセスが完了した後、およびOracle B2BおよびOracle B2B for Healthcareランタイムを起動する前に、各アグリーメントがデプロイされており、所定のリスニング・チャネルが有効であることを確認してください。

20.4.3 Oracle Business Process Management移行のための追加手順

Oracle Business Process Managementの組織単位およびダッシュボードを新しいターゲット環境に移行するには、次の手順を実行します。

- 組織単位を作成するには、『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・スタート・ガイド』のプロセス・ワークスペースでの組織単位の管理に関する項を参照してください。

- ダッシュボードを移行するには、ant-t2p-workspace.xml移行ツールを使用します。移行ツールは、コマンド行で実行できるantターゲットとして使用できます。これは、この作業で説明されているとおり、データの移行用の入力パラメータを指定して作成される構成ファイルをコールします。
このスクリプトでは、BPMUserApplicationData表内の、データ型がBAM_WIDGETであるダッシュボード・データがターゲット環境に移行されます。

ソース環境内とターゲット環境内のユーザーは同じではないため、移行ツールでは、ユーザー固有の構成は移行されないことに注意してください。

次のスクリプトを使用します。

ORACLE_HOME/soa/bin/ant-t2p-workspace.xml

コマンドの形式は次のとおりです。

ant -f ant-t2p-workspace.xml
-Dbea.home=BEA_HOME
-Dbpm.home=BPM_HOME
-Dbpm.t2p.migration.config=MIGRATION_CONFIG_FILE

次の手順を実行します。

1. PATH環境変数に、必要なJAVA_HOMEおよびANT_HOME環境変数が含まれており、それらがOracle SOA Suiteインストール内の場所を指していることを確認してください。

2. 暗号化キーoracle.bpm.services.client.keyを環境変数として設定します。次に例を示します。

oracle.bpm.services.client.key=1XXXX6XXXXX98XXX

暗号化キーは、antコマンドに引数として渡すことでも設定できます。指定しない場合、antタスクにより入力するようプロンプトが出されます。

3. ソース環境からダッシュボードをエクスポートします。

1. 構成ファイルを作成してダッシュボードをエクスポートします。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testToProductionMigrationConfiguration
xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config"
xmlns:ns2="http://xmlns.oracle.com/bpm/common"
override="true" skip="true">
<sourceEndPoint>
<serverEndPoint>
<serverURL>t3://host:port</serverURL>
<adminUserLogin>admin_username</adminUserLogin>
<adminUserPassword>admin_password</adminUserPassword>
<realm>jazn.com</realm>
</serverEndPoint>
</sourceEndPoint>
<targetEndPoint>
<fileEndPoint>
<migrationFile>/tmp/bpm_dashboard.xml</migrationFile>
</fileEndPoint>
</targetEndPoint>
<operation>EXPORT</operation>
<object>DASHBOARD</object>
<objectDetails>
<login>username</login>
<password>password</password>
<identityContext>jazn.com</identityContext>
<userApplicationData>
<ownerId>username/ownerId>
<option>CUSTOMLAYOUT</option>
</userApplicationData>
</objectDetails>
</testToProductionMigrationConfiguration>

構成ファイルでは、次の要素でソース環境用の値を指定する必要があります。

- serverURL: SOAサーバーのURL

- adminUserLogin: 管理者のユーザー名

- adminUserPassword: 管理ユーザーのパスワード

- migrationFile: エクスポート操作によって生成されたファイル

- objectDetails: ログインおよびパスワード要素

- userApplicationData: 所有者ID要素

2. 次のコマンドを使用して、ダッシュボードをエクスポートします。

ant -f ant-t2p-workspace.xml
-Dbea.home=WLS_HOME
-Dbpm.home=BPM_HOME
-Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE

4. ダッシュボードをインポートします。

1. 構成ファイルを作成してダッシュボードをインポートします。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<testToProductionMigrationConfiguration
xmlns="http://xmlns.oracle.com/bpm/t2p/migration/config"
xmlns:ns2="http://xmlns.oracle.com/bpm/common"
override="true" skip="true">
<sourceEndPoint>
<fileEndPoint>
<migrationFile>/tmp/bpm_dashboard.xml</migrationFile>
</fileEndPoint>
</sourceEndPoint>
<targetEndPoint>
<serverEndPoint>
<serverURL>t3://host:port</serverURL>
<adminUserLogin>admin_username</adminUserLogin>
<adminUserPassword>admin_password</adminUserPassword>
<realm>jazn.com</realm>
</serverEndPoint>
</targetEndPoint>
<operation>IMPORT</operation>
<object>DASHBOARD</object>
<objectDetails>
<login>username</login>
<password>password</password>
<identityContext>jazn.com</identityContext>
<userApplicationData>
<ownerId>username/ownerId>
<option>CUSTOMLAYOUT</option>
</userApplicationData>
</objectDetails>
</testToProductionMigrationConfiguration>

構成ファイルでは、次の要素をターゲット環境用の値で更新する必要があります。

- serverURL: SOAサーバーのURL

- adminUserLogin: 管理者のユーザー名

- adminUserPassword: 管理ユーザーのパスワード
パスワードは、ant-t2p-workspace.xmlツールを初めて実行する際に暗号化されます。

- migrationFile: エクスポート操作によって生成されたファイル

- objectDetails: ログインおよびパスワード要素
パスワードは、ant-t2p-workspace.xmlツールを初めて実行する際に暗号化されます。

- userApplicationData: 所有者ID要素

2. 次のコマンドを使用して、ダッシュボードをインポートします。

ant -f ant-t2p-workspace.xml
-Dbea.home=BEA_HOME
-Dbpm.home=BPM_HOME
-Dbpm.t2p.migration.config=Dashboard_MIGRATION_CONFIG_FILE

20.4.4 Oracle Forms Services移行のための追加手順

移行スクリプトを実行すると、Oracle Forms Servicesがターゲット環境に移行されます。ただし、次の追加の手順を実行する必要があります。

1. Oracle Forms Servicesに固有の移動計画プロパティはありません。ただし、次の場所にあるターゲット上のデプロイメント・プラン・ファイルでOracleホームの場所を更新する必要があります。

planDirLoc/deployment_plans

2. ネットワークを介して共有されていないFormsアプリケーション・ファイル(fmx、mmx、pllなど)がある場合、これらをターゲット環境にコピーします。

3. ソース環境とターゲット環境で共通アプリケーション・データベースが共有されていない場合、ターゲット環境のtnsnames.oraファイルにターゲット・データベースの接続情報を入力します。このファイルは、次のディレクトリにあります。

DOMAIN_HOME/config/fmwconfig

4. デモKSS証明書またはカスタムJKS証明書を持つSSL専用の構成が使用環境に含まれる場合、第20.3.8項で説明しているように、管理対象サーバーを起動する前に追加手順を実行する必要があります。

20.4.5 Oracle Traffic Director移行のための追加手順

Oracle Traffic Directorの構成を移行した後、ターゲット環境で証明書を再構成する必要があります。『Oracle Traffic Directorの管理』の証明書の管理に関する項を参照してください。

20.4.6 Oracle WebCenter Portal移行のための追加手順

移行スクリプトを実行すると、Oracle WebCenter Portalがターゲット環境に移行されます。ただし、次のトピックの追加の手順を実行する必要があります。

- Oracle WebCenter Portalデータのターゲット環境への移行(オプション)

- スペースに関連するOracle WebCenter Contentのドキュメントおよびフォルダの移行(オプション)

- ターゲット環境へのディスカッション・サーバーのデータの移行(オプション)

20.4.6.1 Oracle WebCenter Portalデータのターゲット環境への移行(オプション)

Oracle WebCenter Portalのデータ(イベント、リスト、リンク、タグ、ピープル・コネクションに関連するデータなど)をターゲット環境に移行する場合、次の手順に従います。

1. ORACLE_HOME/bin (UNIX)およびORACLE_HOME\bin (Windows)ディレクトリから次のコマンドを使用して、WebCenter Portalのデータをソース・データベースからエクスポートします(ORACLE_HOMEはOracle DatabaseのOracleホームです)。

sqlplus "sys/password as sysdba"
create or replace directory directory as 'path';
exit;

expdp "sys/password@connect_id as sysdba"
schemas=prefix_WEBCENTER directory=directory dumpfile=filename
logfile=expdp_prefix_WEBCENTER.log

2. ステップ1でエクスポートしたファイルを使用して、WebCenter Portalデータをターゲット・データベースにインポートします。次のコマンドを実行します(ORACLE_HOMEは、Oracle DatabaseのOracleホームです)。

ORACLE_HOME/bin/sqlplus "sys/password as sysdba"
create or replace directory directory as 'path';
exit;

ORACLE_HOME/bin/impdb "sys/password@connect_id as sysdba"
DIRECTORY=directory dumpfile=filename remap_schema=wcp_WEBCENTER:WEBCENTER
TABLE_EXISTS_ACTION=REPLACE

20.4.6.2 スペースに関連するOracle WebCenter Contentのドキュメントおよびフォルダの移行(オプション)

WebCenter Portalを介してOracle WebCenter Content内に格納されているデータを移行するには、第20.4.7項で説明しているように、コピー・オプションを使用してOracle WebCenter Contentを移行します。

20.4.6.3 ターゲット環境へのディスカッション・サーバーのデータの移行(オプション)

Oracle WebCenter Portalアプリケーションがディスカッション・サービスを使用している場合、ソース環境のディスカッション・サーバーのデータをターゲット環境に移行します。

1. ORACLE_HOME/bin (UNIX)およびORACLE_HOME\bin (Windows)のディレクトリからOracle Databaseエクスポート・ユーティリティを使用して、ディスカッション・サーバーのデータをエクスポートします(ORACLE_HOMEはOracle DatabaseのOracleホームです)。

expdp "sys/password@connect_id as sysdba"
OWNER=src_prefix_DISCUSSIONS DUMPFILE=dumpFileName.dmp STATISTICS=none
schemas=src_prefix_DISCUSSIONS directory=directory dumpfile=filename
schemas=src_prefix_DISCUSSIONS_CRAWLER directory=directory dumpfile=filename

2. ディスカッション・サーバー・データをインポートします。

1. ターゲット・ディスカッション・サーバーを停止します。

2. WebCenter Portalのディスカッション・サーバー・スキーマがインストールされているデータベースのORACLE_HOME/binディレクトリに移動し、sqlplusを使用してsysdbaとしてデータベースに接続します。

ORACLE_HOME/bin/sqlplus "sys/password@serviceid as sysdba"

3. ターゲット・ユーザーを削除して、新しいユーザーを作成します。

drop user trgt_prefix_DISCUSSIONS cascade;
create user trgt_prefix_DISCUSSIONS identified by password
default tablespace trgt_prefix_IAS_DISCUSSIONS temporary
tablespace name_IAS_TEMP;

4. ユーザーにconnectとresource権限を付与します。

grant connect,resource, create view to trgt_prefix_DISCUSSIONS;

5. SQLPlusを終了します。

exit;

6. ORACLE_HOME/bin (UNIX)およびORACLE_HOME\bin (Windows)のディレクトリからOracle Databaseインポート・ユーティリティを使用して、ディスカッション・サーバーのデータをインポートします(ORACLE_HOMEはOracle DatabaseのOracleホームです)。

impdp \"sys/password@serviceid as sysdba\"
remap_schema=src_prefix_DISCUSSIONS:trgt_prefix_DISCUSSIONS
remap_schema=src_prefix_DISCUSSIONS_CRAWLER:trgt_prefix_DISCUSSIONS_CRAWLER
remap_tablespace=source_tablespace:target_tablespace exclude=user
DUMPFILE=dumpFileName STATISTICS=none

20.4.7 Oracle WebCenter Contentの移行の追加情報および手順

移行スクリプトを実行すると、Oracle WebCenter Contentがターゲット環境に移行されます。Oracle WebCenter ContentサーバーまたはOracle WebCenter Content: Recordsの場合、コンポーネントを移行するには次の2つのオプションがあります。

- copy: このオプションは、構成およびデータを含むソース・システム全体をターゲット・システムにコピーします。これはデフォルトのオプションですが、これに伴うテスト・データの移行がご使用の環境に適さない場合があるため、このオプションの使用はお薦めしません。また、その手順では次のことも行われます。

- Oracle WebCenter Contentおよびそのコンポーネントの変更された設定などの構成のコピー

- BPEL資格証明のコピー

- Oracle WebCenter Captureの移行

- Oracle Web Services Managerポリシーの移行

- Oracle Application Extension Framework (AXF)を含む管理対象サーバーのリスニング・アドレスの設定

- 管理サーバーおよび管理対象サーバーの起動

- init: このオプションは、ターゲット・システムの新しいContentサーバーまたはRecordsインスタンスを初期化します。これによって、データは移行されません。ソース・ドメインと管理対象サーバーがターゲット・システムにコピーされます。
また、initオプションを使用すると、pasteConfigスクリプトにより、次の初期化プロパティがソース・システムからコピーされます。

IDC_Name
IDC_Id
InstanceMenuLabel
InstanceDescription
IntradocServerPort
IdcCommandServerHost
SocketHostAddressSecurityFilter
HttpServerAddress
HttpRelativeWebRoot
UseSSL
MailServer
SysAdminAddress
IsAutoNumber
AutoNumberPrefix
AdditionalRegisteredComponents
AdditionalEnabledComponents

表A-26の説明に従って、移動計画のMoveType configPropertyでcopyまたはinitオプションを指定します。その後、configGroupにリストされているプロパティを変更します。

カスタム証明書を使用する場合、カスタム証明書が生成され、それに応じて移動計画内でIDキーストアおよび信頼キーストアが更新されます。SSL専用の環境の場合、第20.3.8項の手順に従います。

ターゲット環境がデモ証明書を持つSSL専用の環境である場合、copyConfigスクリプトを実行した後に次の手順を実行します。

1. ContentサーバーのURLで使用される証明書をブラウザからエクスポートします。

2. すべてのサーバーが動作していることを確認します。

3. 次のコマンドを使用して、ローカルJDKのcacertsディレクトリに証明書をインポートします。

JDK_HOME/bin/keytool -import -keystore
JDK_HOME/jre/lib/security/cacerts -file cscert_file_location
/path-to-keystores/custom_keystores/hostname_identity_exportcert.cer

4. WebCenter ContentサーバーおよびWebUIサーバーを再起動します。

5. 第2.5.2項の説明に従って、Fusion Middleware Controlで、MBeanブラウザに移動します。

6. MBeanブラウザで、「アプリケーション定義のMBean」を開きます。次に、「oracle.adf.share.connections」→「サーバー:WCCcontentADF_server」→アプリケーション: Oracle WebCenter Content - Web UI→「ADFConnections」→「ADFConnections」→「WccConnection」の順に選択します。「WccAdfDefaultConnection」を選択します。

7. 次のフィールドを更新します。

- PropConnectionURL: たとえば、https://hostname.domainname:16201/cs/idcplg

- PropCredentialPassword

- PropProtocolHttpLibrary

- PropCredentialImpersonationAllowed。これをtrueに設定します。

8. 「適用」をクリックします。

9. 「アプリケーション定義のMBean」に移動し、展開します。次に、「oracle.adf.share.connections」→「サーバー:WCContentADF_server」→アプリケーション: Oracle WebCenter Content - Web UIの順に選択します。ADFConnectionsを選択します。

10. 「操作」タブを選択します。「保存」をクリックします。

11. 「起動」をクリックします。

12. WebUIサーバー(WCCADF_servername)を再起動します。

20.4.8 Oracle WebCenter Sites移行のための追加手順

移行スクリプトを実行すると、Oracle WebCenter Sitesがターゲット環境に移行されます。ただし、『Oracle WebCenter Sitesのインストールと構成』のテスト・モードから本番モードへの切替えに関する項で説明しているように、Oracle WebCenter Sitesを構成するための追加手順を実行する必要があります。

20.5 アーティファクトの漸進的な移行

移行のスクリプトは、新しいターゲット環境への移行を対象としています。既存の環境へのアーティファクトの移行はサポートしていません。

すでに新しいターゲットに環境を移行した場合、後になって、ソース環境で変更したアーティファクトをターゲット環境に移行したいことがあります。変更したアーティファクトの移行の詳細は、Oracle HTTP Serverなど、個々のコンポーネントのドキュメントを参照してください。

20.6 分散トポロジの移行

次の各項では、分散トポロジの場合の考慮事項について説明します。

- 複数ホスト環境での考慮事項

- Oracle RAC環境への移行またはOracle RAC環境からの移行に関する考慮事項

20.6.1 複数ホスト環境での考慮事項

ドメインが複数のホストに分散されている場合、移行を実行するためには追加の手順が必要です。

コンポーネントの構成を移行すると、スクリプトによりソースのトポロジがレプリケートされます。たとえば、ソース・ドメインにホストAの管理対象サーバーserver_1とserver_2、およびホストBの管理対象サーバーserver_3とserver_4が含まれる場合、ターゲットにも同様の管理対象サーバーとホストの関係を指定する必要があります。(移動計画のそれぞれの管理対象サーバーに対してホストを指定します。)

これらの手順は、管理サーバー・ホストで第20.3項の手順を実行済であることを前提としています。

1. 共有ディスクを使用していない場合は、pasteBinaryコマンドを使用して、リモート・ホスト(たとえばHost B)にOracleホームを作成します。第20.3.2項の手順1で作成した、同じアーカイブを使用します。
例:

pasteBinary.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc  /tmp/oh_copy.jar
-targetOracleHomeLoc /scratch/oracle/ORACLE_HOME_prod
-targetOracleHomeName ORACLE_HOME_prod

2. Oracle WebLogic Serverのpackとunpackコマンドを使用して、リモートの管理対象サーバーに対するドメイン・ディレクトリを再作成します。詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』を参照してください。

20.6.2 Oracle RAC環境への移行またはOracle RAC環境からの移行に関する考慮事項

Oracle Real Application Cluster (Oracle RAC)環境に、またはOracle Real Application Cluster (Oracle RAC)環境から環境を移行している場合は、次の点に注意してください。

- Oracle RAC環境ではないソース環境から、Oracle RACを使用するターゲット環境に移行している場合、移動計画には、汎用データ・ソースの1つのエントリ(mds-adfなど)があります。Oracle RACインスタンスの1つを指すように移動計画を更新し、ソース環境からターゲット環境への移行を完了します。
そして、『高可用性ガイド』(特にデータベースの考慮事項に関する説明)に従って、Oracle RAC用にターゲット環境を構成します。

- 移動計画にリストされていない場合でも、複数のデータ・ソースがターゲット環境に移行されます。

- Oracle RAC環境を使用するソース環境から、Oracle RACを使用しないターゲット環境に移行している場合、移動計画には、汎用データ・ソースの複数のエントリがあります。たとえば、4つのOracle RACインスタンスがある場合、mds-adf-rac1からmds-adf-rac4までの名前を持つ4つの汎用データ・ソースがあります。すべての汎用データ・ソースがターゲット環境のRAC以外の単一インスタンスを指すように、移動計画を更新します。

- Oracle RACを使用するソース環境から、Oracle RACを使用するターゲット環境に移行しているが、ターゲット環境にそれ以外のOracle RACインスタンスがある場合、移動計画には、汎用データ・ソースで複数のエントリがあります。たとえば、ソース環境に3つのOracle RACインスタンスがある場合、mds-adf-rac1からmds-adf-rac3までの名前を持つ3つの汎用データ・ソースがあります。ターゲット環境に、4つのOracle RACインスタンスがあります。汎用データ・ソースがターゲット環境の最初の3つのデータ・ソースを指すように、移動計画を更新します。

- Oracle RACを使用するソース環境から、Oracle RACを使用するターゲット環境に移行しているが、ターゲット環境にそれ以外のOracle RACインスタンスが少ない場合、移動計画には、汎用データ・ソースで複数のエントリがあります。たとえば、ソース環境に4つのOracle RACインスタンスがある場合、mds-adf-rac1からmds-adf-rac4までの名前を持つ4つの汎用データ・ソースがあります。ターゲット環境に、3つのOracle RACインスタンスがあります。最初の3つの汎用データ・ソースがターゲット環境の3つのデータ・ソースを指すように、移動計画を更新します。最後の汎用データ・ソースは、3つ目の汎用データ・ソースを指すようにします。(3つ目のOracle RACインスタンスにはmds-adf-rac3とmds-adf-rac4の両方が含まれます)。
第10.2.2.1項の説明に従って、データ・ソースを追加できます。

20.7 テストから本番への移行におけるエラーのリカバリ

pasteBinaryまたはpasteConfigスクリプトを実行して移動計画に不正な情報を入力すると、スクリプトはエラーを返します。場合によっては、貼付け操作が部分的に実行されていることもあります。リカバリするには、エラーを返したスクリプトに応じて、次の処理を実行します。

- Oracle HTTP ServerなどのWeb層コンポーネントが含まれる環境を移行する場合、copyBinaryスクリプトによって次のメッセージが返される場合があります。

Warning Message  :1
Nov 20, 2014 10:47:57 - WARNING - CLONE-20266   Unable to archive a file.
Nov 20, 2014 10:47:57 - CAUSE - CLONE-20266   The file
"/scratch/oracle/webtier6400/network/log/cgisock.9465" did not have
sufficient permission to access.
Nov 20, 2014 10:47:57 - ACTION - CLONE-20266   Correct the permission of
above file and run copyBinary again.

このメッセージは無視して問題ありません。

- Windowsで、Sun JDKを使用すると、copyBinary、pasteBinary、copyConfigまたはpasteConfigの操作が次のエラーで失敗する場合があります。

java.nio.channels.OverlappingFileLockException

この場合、T2P_JAVA_OPTIONSを使用して、システム・プロパティのsun.nio.ch.disableSystemWideOverlappingFileLockCheckを設定します。次に例を示します。

set T2P_JAVA_OPTIONS=
-Dsun.nio.ch.disableSystemWideOverlappingFileLockCheck=true

操作を再試行してください。

- pasteConfigスクリプトを再実行して、現在の環境にOracle Platform Security Servicesを含める場合は、次の環境変数を設定します。

setenv T2P_JAVA_OPTIONS="-Dopssdata.import=false"

この設定により、pasteConfigスクリプトがOPSSスキーマへのデータのインポートを試みないようにします。スキーマ内にデータがすでに存在する場合、pasteConfigスクリプトは失敗します。

- ターゲットで、Oracleホーム・ディレクトリの移行中にpasteBinaryスクリプトでエラーが返された場合の手順は、次のとおりです。

1. ターゲットOracleホームを削除します。

2. OracleインベントリにOracleホーム・エントリが存在する場合、それを削除します。

3. Windowsでは、Oracleホームのショートカットを削除します。

- copyConfigスクリプトでは、ディレクトリが変更されないように、すべてのサーバーが実行中であり、アイドルである必要があります。サーバーがアイドルではない場合、copyConfigスクリプトはクローニング操作が正常に完了したことを報告し、copyConfigエラー・ログ・ファイルが0バイトのままとなります。ただし、copyConfig標準ログ・ファイルには、packed_domain.jarへの書込みに関するエラーが含まれます。このエラーによって、pasteConfigプロセスが失敗します。
この問題を回避するには、少しの間待機して、copyConfig操作を再試行します。

- Javaコンポーネントの移行中に、pasteConfigスクリプトでエラーが返された場合は、次の手順を実行します。

1. ドメインに関連するすべてのプロセスを停止します。

2. 次のディレクトリを削除します。

ORACLE_HOME/user_projects/domains/domain_name
ORACLE_HOME/user_projects/applications/domain_name

3. スキーマを削除して、RCUを使用してそれらを再作成します。

また、Oracle Platform Securityの再割当てが失敗した場合、次の処理を実行します。

- ファイルベースのストアからLDAPストアに移行している場合は、移動計画の値で別の値を指定します。

- LDAPストアの場合は、ドメイン・ノードを削除します。

- データベースベース・ストアでは、スキーマを削除しRCUを使用してそれを再作成します。

- pasteConfigスクリプトを使用しているときにメモリー不足エラーが発生した場合は、次のいずれかの方法でこのエラーを回避できます。

- JVMヒープ・サイズを拡張します。最大ヒープ・サイズにオプション-Xmxを、初期ヒープ・サイズに-Xmsを使用します。次に例を示します。

CONFIG_JVM_ARGS="-Xms512m -Xmx1024m"

- 多くの場合、Oracle WebLogic Serverドメインのディレクトリ構造には、不要な大容量ファイル(大容量の古いログ・ファイルなど)が含まれています。これらのファイルを削除してから、copyConfigおよびpasteConfigスクリプトを再度実行します。

- Oracle SOA SuiteインストールでcopyConfigスクリプトを使用した際に次のエラーが表示された場合は、T2P_JAVA_OPTIONS環境変数を使用して、メッセージのサイズを大きくします。

weblogic.socket.MaxMessageSizeExceededException: Incoming message of size:
'10000080' bytes exceeds the configured maximum of: '10000000' bytes for
protocol: 't3'.

第A.1項の説明に従って、T2P_JAVA_OPTIONS環境変数を使用し、-Dweblogic.MaxMessageSize=20000000プロパティをcopyConfigとpasteConfigの両方のスクリプトに渡します。

- pasteConfig操作を使用する際に、Oracle B2Bインバウンド/アウトバウンド・ディスパッチャが構成されていると、次のエラーが表示される場合があります。

oracle.mds.exception.MDSRuntimeException: java.sql.SQLException: Data Source
mds-soa does not exist.
Data Source mds-soa does not exist.

この状況では、失敗後に管理対象サーバーのプロセスを強制終了し、手動で管理対象サーバーを再起動します。

- Oracle SOA Suite管理対象サーバーを起動しようとしてエラーが発生した場合は、pasteConfigスクリプトの実行後に管理コンソールを使用して、システム・パラメータを変更する必要があります。(これらのシステム・パラメータには、pasteConfigスクリプトによって一時的な値が設定されます。)

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ドメイン構造」ウィンドウで、「環境」を開きます。

3. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

4. サーバーを選択します。

5. 「サーバーの起動」タブを選択します。

6. 「引数」フィールドで、次のパラメータを入力します。

-Dtangosol.coherence.wkan=hostname
-Dtangosol.coherence.localhost=hostname
-Dtangosol.coherence.localport=localport_number
-Dtangosol.coherence.wka1.port=port_number_for_Coherence

7. 「保存」をクリックして、「変更のアクティブ化」をクリックします。

8. サーバーを起動します。

第IX部

付録

この部の内容は次のとおりです。

- 付録A「移行スクリプトおよび移動計画」

- 付録B「Oracle Fusion Middlewareのコマンド行ツール」

- 付録C「コンポーネントのURL」

- 付録D「ポート番号」

- 付録E「Oracle Fusion Middlewareのアクセシビリティ・オプションの使用」

- 付録F「リリース番号の確認」

- 付録G「orapki」

- 付録H「Oracle Fusion Middlewareのトラブルシューティング」

A 移行スクリプトおよび移動計画

Oracle Fusion Middlewareには、環境の移行に使用可能な一連のスクリプトが用意されています。たとえば、テスト環境を本番環境にレプリケートする場合などに使用できます。こうしたスクリプトにより、ユーザーはOracleホーム・ドメイン、Oracle WebLogic Serverドメインおよびスタンドアロン・ドメイン、さらにOracle HTTP ServerやOracle SOA Suiteなどの特定のOracle Fusion Middlewareコンポーネントの構成をコピーできます。この付録では、これらのエンティティの移行に使用可能なスクリプトについて説明します。環境を移行する際に編集する移動計画のプロパティも説明しています。

内容は次のとおりです。

- 第A.1項「移行スクリプトの理解」

- 第A.2項「移動計画の使用」

A.1 移行スクリプトの理解

移行スクリプトは、Oracleホームおよびドメインとそのコンポーネントの構成のバイナリ・ファイルを、ソース環境からコピーし、ターゲット環境に貼り付けます。

これらのスクリプトは、第20章で説明されている手順と合わせて使用します。

Oracle Fusion Middlewareでは、次のjarファイルを使用して、バイナリ・ファイルおよび構成ファイルの移行に必要なスクリプトを実行します。

(UNIX) ORACLE_HOME/oracle_common/jlib/cloningclient.jar
(Windows) ORACLE_HOME\oracle_common\jlib\cloningclient.jar

表A-1は、Oracleホームまたはドメインとそのコンポーネントの移行に使用するスクリプトを示しています。

表A-1 移行スクリプト

目的:

スクリプト

関連項目:

ソースOracleホームのバイナリ・ファイルをコピーする

(UNIX) ORACLE_HOME/oracle_common/bin/copyBinary.sh
(Windows) ORACLE_HOME\oracle_common\bin\copyBinary.cmd

第A.1.2.1項

コピーしたOracleホームをターゲットに適用する

(UNIX) ORACLE_HOME/oracle_common/bin/pasteBinary.sh
(Windows) ORACLE_HOME\oracle_common\bin\pasteBinary.cmd

第A.1.2.2項

WebLogic Serverドメインおよびコンポーネントの構成をコピーする

(UNIX) ORACLE_HOME/oracle_common/bin/copyConfig.sh
(Windows) ORACLE_HOME\oracle_common\bin\copyConfig.cmd

第A.1.2.3項

スタンドアロン・ドメインおよびコンポーネントの構成をコピーする

(UNIX) ORACLE_HOME/oracle_common/bin/copyConfig.sh
(Windows)  ORACLE_HOME\oracle_common\bin\copyConfig.cmd

第A.1.2.4項

ノード・マネージャの構成をコピーする

(UNIX)  ORACLE_HOME/oracle_common/bin/copyConfig.sh
(Windows)  ORACLE_HOME\oracle_common\bin\copyConfig.cmd

第A.1.2.5項

ドメインまたはコンポーネントから移動計画を抽出する

(UNIX)  ORACLE_HOME/oracle_common/bin/extractMovePlan.sh
(Windows)  ORACLE_HOME\oracle_common\bin\extractMovePlan.cmd

第A.1.2.6項

コピーされたWebLogic Serverドメインの構成およびコンポーネントの構成をターゲットに適用する

(UNIX)  ORACLE_HOME/oracle_common/bin/pasteConfig.sh
(Windows)  ORACLE_HOME\oracle_common\bin\pasteConfig.cmd

第A.1.2.7項

コピーされたスタンドアロン・ドメインおよびコンポーネントの構成をターゲットに適用する

(UNIX) ORACLE_HOME/oracle_common/bin/pasteConfig.sh
(Windows) ORACLE_HOME\oracle_common\bin\pasteConfig.cmd

第A.1.2.8項

コピーされたノード・マネージャの構成をターゲットに適用する

(UNIX) ORACLE_HOME/oracle_common/bin/pasteConfig.sh
(Windows) ORACLE_HOME\oracle_common\bin\pasteConfig.cmd

第A.1.2.9項

不明瞭化されたパスワードが含まれるファイルを生成する

(UNIX)ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh
(Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd

Oracle Fusion Middlewareでは、不明瞭化したパスワードを含むファイルを生成するためのAPIも用意されています。

第A.1.2.10項

これらのスクリプトのヘルプを参照するには、-helpオプションを使用します。次に例を示します。

./pasteConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40 -help

ヘルプには、UNIX版のパラメータ値が示されます。Windowsなど他のプラットフォームでは、そのプラットフォームのパラメータ値に変更してください。

注意:
IBM JDKを使用する場合、copyConfigおよびpasteConfigスクリプトのT2P_JAVA_OPTIONSパラメータを使用して最大永続生成領域(-XX:MaxPermSize=value)を設定します。

注意:

- 一時ディレクトリに対しては、スペースを含むパスを指定しないでください。

- Universal Uniform Naming Convention (UNC)パスは、Windowsではサポートされません。たとえば、次の例はサポートされていません。

\\host_name\oracle\java\win64\jdk8\jre\bin\java

この項の内容は次のとおりです。

- Javaオプションの指定

- 移行スクリプトの構文

A.1.1 Javaオプションの指定

追加のJavaオプションを指定するには、T2P_JAVA_OPTIONS環境変数を定義し、その変数定義にオプションを指定します。

次の例では、Java一時ディレクトリの値を設定しています。

- LinuxまたはUNIXの場合:

setenv T2P_JAVA_OPTIONS "-Djava.io.tmpdir=/home/t2p/temp"
export T2P_JAVA_OPTIONS

- Windowsの場合:

set T2P_JAVA_OPTIONS="-Djava.io.tmpdir=c:\home\t2p\temp"

Windowsの場合、tempディレクトリのパスに\xを含めることはできません。含めた場合、スクリプトは失敗します。

T2P_JAVA_OPTIONSを使用してログ・レベルを設定するには、次のいずれかを実行します。

- 構成ファイルを指定して、ログ・レベルを設定します。この場合、他のログ・ファイルおよび移行スクリプト・ログ・ファイルに対してもレベルを設定できます。次に例を示します。

setenv T2P_JAVA_OPTIONS -Dt2p.logging.config.file=log_config_file

たとえば、ログ構成ファイルには、次の内容を含めてすべてのログ出力のレベルをFINEに設定できますが、この場合org.hibernateのレベルはFINESTに設定されます。

#Root logger
.level = FINE
# Set the level of external loggers.
org.hibernate.level = FINEST

- 環境変数でログ・レベルを設定します。次に例を示します。

setenv T2P_JAVA_OPTIONS -Dt2p.logging.level=level

この場合、レベルはOFF、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST、ALLのいずれかに設定できます。

または、スクリプトの-debugオプションで、false (デフォルト)を指定するとログ・レベルはFINEに設定され、trueを指定するとログ・レベルはFINESTに設定されます。

優先順位は次のとおりです。

- 構成ファイルの環境変数による設定

setenv T2P_JAVA_OPTIONS -Dt2p.logging.config.file=log_config_file

- 環境変数によるログ・レベルの設定

setenv T2P_JAVA_OPTIONS -Dt2p.logging.level=level

- コマンド行で-debugオプションを指定

A.1.2 移行スクリプトの構文

次の各項では、移行スクリプトの構文について説明します。構文の後の表で、そのオプションについて説明します。

- copyBinaryスクリプト

- pasteBinaryスクリプト

- Oracle WebLogic Serverドメイン用copyConfigスクリプト

- スタンドアロン・ドメイン用copyConfigスクリプト

- ノード・マネージャ用のcopyConfigスクリプト

- extractMovePlanスクリプト

- Oracle WebLogic Serverドメイン用pasteConfigスクリプト

- スタンドアロン・ドメイン用pasteConfigスクリプト

- ノード・マネージャ用のpasteConfigスクリプト

- obfuscatePasswordスクリプトとAPI

注意:

- この章のこれ以降の表に示すように、ほとんどのオプションにはショートカット名があります。

- オプションの値に空白を入れることはできません。たとえば、Windowsでは、-archiveLocオプションの値として次のような文字列を渡すことはできません。

C:\tmp\Archive Files

ただし、JavaHomeオプションの値にはスペースを含めることができます。

- Windowsでは、UNIXコマンドをサポートするMKSまたは別のアプリケーションをコマンド・プロンプトで使用していない場合、または値にWindows固有のデリミタ(等号(=)、カンマ(,)など)が含まれている場合は、値全体を二重引用符(")で囲む必要があります。次に例を示します。

-additionalParams "search.encrypt.key=C:\T2P\encrypt.txt"

- javaHomeオプションで使用されるJavaのベンダーおよびバージョンは、次のファイル(ファイル名の前のピリオド(.)に注意してください)で定義されているJAVA_HOMEプロパティのベンダーおよびバージョンと一致する必要があります。

ORACLE_HOME/wlserver/.product.properties

A.1.2.1 copyBinaryスクリプト

WebLogic Serverホームを含めて、ソースOracleホームのバイナリ・ファイルをアーカイブ・ファイルにコピーすることにより、ソースOracleホームのアーカイブ・ファイルを作成します。

copyBinaryスクリプトは、次の場所にあります。

(UNIX) ORACLE_HOME/oracle_common/bin/copyBinary.sh
(Windows) ORACLE_HOME\oracle_common\bin\copyBinary.cmd

構文は次のとおりです。

copyBinary -javaHome path_of_jdk
-archiveLoc archive_location
-sourceOracleHomeLoc ORACLE_HOME_location
[-logDirLoc log_dir_path]
[-silent {true | false}]
[-ignoreDiskWarning {true | false}]
[-debug {true | false}]

次の例は、LinuxでOracleホームのアーカイブを作成する方法を示しています。

copyBinary.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/oh_copy.jar
-sourceOracleHomeLoc /scratch/oracle/Oracle_home1

注意:
スクリプトを実行するときに、対応するJavaホームを指定する必要があります。つまり、Oracleホームが64ビットの場合、64ビットのJavaホームを指定する必要があります。Oracleホームが32ビットの場合、32ビットのJavaホームを指定する必要があります。

表A-2は、copyBinaryスクリプトのオプションを説明しています。

表A-2 copyBinaryスクリプトのオプション

オプション

ショートカット

説明

必須/オプション

-javaHome

NA

Java Developer's Kitの絶対パス。

オペレーティング・システムが64ビットの場合にスクリプトによりそのことが検出され、コマンド行でスクリプトに-d64オプションが渡されます。

必須

-archiveLoc

-al

アーカイブの場所の絶対パス。このオプションは、copyBinaryスクリプトを使用して作成するアーカイブ・ファイルの場所の指定に使用します。

アーカイブの場所は存在している必要はありません。

アーカイブの場所がOracleホーム構造内に存在しないことを確認してください。

必須

-sourceOracleHomeLoc

-soh

アーカイブを作成するOracleホームの絶対パス。指定できるのはOracleホームだけです。

必須

-invPtrLoc

-ipl

このオプションは非推奨です。指定した場合は、無視されます。UNIXおよびLinuxでは、Oracleインベントリ・ポインタへの絶対パス。

無視される

-logDirLoc

-ldl

ディレクトリの絶対パス。このディレクトリは存在していても、存在していなくてもかまいません。このディレクトリ内に新しいログ・ファイルが作成されます。デフォルトは、システムの一時ディレクトリです。

オプション

-silent

NA

操作をサイレントで実行するかどうかを指定します。つまり、確認のためのプロンプトは表示されません(デフォルト)。

確認のためのプロンプトを表示するように指定するには、このオプションを値falseで指定します。続行するには、yesと入力します(大/小文字は区別されません)。「yes」以外を入力すると、スクリプトが異常終了します。

オプション

-ignoreDiskWarning

-idw

この操作で空き容量が不十分という警告を無視するかどうかを指定します。デフォルトは、falseです。

ターゲットがNFSでマウントされている場合、またはData ONTAPなどの異なるファイル・システムにある場合、このフラグを使用する必要がある場合があります。

オプション

-debug

NA

スクリプトのログ・レベルを設定して、デバッグ情報を提供します。デフォルトはfalseで、ログ・レベルはFINEに設定されます。trueに設定すると、ログ・レベルはFINESTに設定されます。

ログ・レベルの設定に関するその他のオプションは、第A.1.1項を参照してください。

A.1.2.2 pasteBinaryスクリプト

ソースのOracleホームのバイナリ・ファイルをターゲット環境に貼り付けることによって、アーカイブをターゲットの宛先に適用します。アーカイブは同一ホストに適用することも別のホストに適用することもできます。

ターゲット環境を準備するために必要となる手順の詳細は、このスクリプトを実行する前に、第20.2.4項を参照してください。

pasteBinaryスクリプトは、次の場所にあります。

(UNIX) ORACLE_HOME/oracle_common/bin/pasteBinary.sh
(Windows) ORACLE_HOME\oracle_common\bin\pasteBinary.cmd

構文は次のとおりです。

pasteBinary -javaHome path_of_jdk
-archiveLoc archive_location
-targetOracleHomeLoc target_Oracle_Home_location
[-targetOracleHomeName Oracle_home_name]
[-ouiParam key1=value], key2=value]
[-ohAlreadyCloned {true | false}]
[-executeSysPrereqs {true | false}]
[-invPtrLoc Oracle_InventoryLocation]
[-logDirLoc log_dir_path]
[-silent {true | false}]
[-ignoreDiskWarning {true | false}]
[-debug {true | false}]

次の例は、Linux上のディレクトリ//scratch/oracle/Oracle_home_prodにアーカイブを適用する方法を示しています。

pasteBinary.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc  /tmp/oh_copy.jar
-targetOracleHomeLoc /scratch/oracle/Oracle_home_prod
-targetOracleHomeName Oracle_home_prod

表A-3は、pasteBinaryスクリプトのオプションを説明しています。

表A-3 pasteBinaryスクリプトのオプション

オプション

ショートカット

説明

必須/オプション

-javaHome

NA

Java Developer's Kitの絶対パス。

オペレーティング・システムが64ビットの場合にスクリプトによりそのことが検出され、コマンド行でスクリプトに-d64オプションが渡されます。

必須

-archiveLoc

-al

アーカイブの場所の絶対パス。このオプションは、copyBinaryスクリプトを使用して作成するアーカイブ・ファイルの場所の指定に使用します。

既存の場所である必要があります。

このオプションは、-ohAlreadyClonedオプションとは相互に排他的です。

必須

-targetOracleHomeLoc

-toh

ターゲットのOracleホームの絶対パス。

Oracleホーム・ディレクトリがその場所に存在しないこと、また存在する場合は空のディレクトリであることを確認します。それ以外の場合、このスクリプトはエラー・メッセージを返します。

-targetOracleHomeLocを別のOracleホーム内に置くことはできません。

必須

-targetOracleHomeName

-tohn

Oracleホームの名前。この名前は、OracleホームをOracle Inventoryに登録するために使用します。名前に空白は使用できません。

オプション

-ouiParam

-op

このスクリプトの一部として実行されるOracle Universal Installerに渡される、追加の変数。これらの変数は「キー=値」のペアで渡す必要があります。複数の変数がある場合は、カンマで区切ります。

Windowsの場合、値ペア全体を二重引用符(")で囲みます。

オプション

-ohAlreadyCloned

-ohac

ストレージレベルのクローニング・ツールを使用して作成された既存のOracleホームを、スクリプトにより再構成することを指定するフラグ。このフラグがtrueに設定された場合、ターゲットのOracleホームが存在している必要があり、また、ターゲットOracleホームにOracleホーム・バイナリが含まれている必要があります。

有効な値はtrueおよびfalseです。デフォルトはfalseです。

このオプションは、-archiveLocオプションを使用するときには使用できません。

オプション

-executeSysPrereqs

-esp

pasteBinary操作でOracleホームの前提条件を確認するかどうかを指定します。デフォルトでは、前提条件が確認されます。前提条件を確認しないことを指定するには、このオプションを値falseで指定します。

オプション

-invPtrLoc

-ipl

UNIXおよびLinuxでは、Oracleインベントリ・ポインタへの絶対パス。このオプションは、インベントリの場所がデフォルトの場所ではない場合に使用します。これによって、操作は、Oracleインベントリ・ポインタ・ファイルで指定された中央OracleインベントリにOracleホームを登録できるようになります。

oraInst.locがデフォルトの場所にない場合は、このファイルを、ルート・ユーザーとしてデフォルトの場所に、あるいはルート・ユーザーまたは通常ユーザーとしてその他の任意の場所に作成する必要があります。次では、このファイルのコンテンツの例を示しています。

inventory_loc=/scratch/oraInventory
inst_group=dba

inventory_locとして指定されたディレクトリが存在しない場合は、操作により作成されます。

インベントリの場所への書込み権限が必要です。

AIXおよびLinuxでは、デフォルトの場所は/etc/oraInst.locです。他のUNIXプラットフォームでは、デフォルトの場所は/var/opt/oracle/oraInst.locです。

このパラメータはUNIXでのみサポートされます。Windowsでこのパラメータを指定した場合、このスクリプトはエラーを返します。

インベントリがデフォルトの場所にある場合は、オプション。それ以外の場合は、Linuxでは必須。

-logDirLoc

-ldl

ディレクトリの絶対パス。このディレクトリは存在していても、存在していなくてもかまいません。このディレクトリ内に新しいログ・ファイルが作成されます。デフォルトは、システムの一時ディレクトリです。

オプション

-silent

NA

操作をサイレントで実行するかどうかを指定します。つまり、確認のためのプロンプトは表示されません(デフォルト)。

確認のためのプロンプトを表示するように指定するには、このオプションを値falseで指定します。続行するには、yesと入力します(大/小文字は区別されません)。「yes」以外を入力すると、スクリプトが異常終了します。

オプション

-ignoreDiskWarning

-idw

この操作で空き容量が不十分という警告を無視するかどうかを指定します。デフォルトは、falseです。

ターゲットがNFSでマウントされている場合、またはData ONTAPなどの異なるファイル・システムにある場合、このフラグを使用する必要がある場合があります。

オプション

-debug

NA

スクリプトのログ・レベルを設定して、デバッグ情報を提供します。デフォルトはfalseで、ログ・レベルはFINEに設定されます。trueに設定すると、ログ・レベルはFINESTに設定されます。

ログ・レベルの設定に関するその他のオプションは、第A.1.1項を参照してください。

A.1.2.3 Oracle WebLogic Serverドメイン用copyConfigスクリプト

WebLogic Serverドメインの構成のスナップショットが含まれる構成アーカイブを作成します。WebLogic Serverドメインの元になるコンポーネントは、ファイル・システム、Oracle Metadata Service (MDS)、LDAP、データベースなどの様々なデータ・ストアに構成情報を保持します。

copyConfigスクリプトは、ソース環境のそれぞれのWebLogic Serverドメインで実行する必要があります。構成アーカイブは、それぞれのソース・ドメインに対して作成されます。

スクリプトを実行するときに、管理サーバーとドメイン内のすべての管理対象サーバーが起動している必要があります。

copyConfigスクリプトは、次の場所にあります。

(UNIX) ORACLE_HOME/oracle_common/bin/copyConfig.sh
(Windows) ORACLE_HOME\oracle_common\bin\copyConfig.cmd

構文は次のとおりです。

copyConfig  -javaHome path_of_jdk
-archiveLoc archive_location
-sourceDomainLoc domain_location
-sourceOracleHomeLoc Oracle_home_location
-domainHostName domain_host_name
-domainPortNum  domain_port_number
-domainAdminUserName domain_admin_username
-domainAdminPasswordFile domain_admin_password_file
[-mdsDataExport {true | false}]
[-opssDataExport {true | false}]
[-trustKeyStoreLoc custom_trust_keystore_path]
[-additionalParams property1=value1[, property2=value2]
[-logDirLoc log_dir_path]
[-silent {true | false}]
[-debug {true | false}]

次の例では、WebLogic Serverドメインの構成をコピーしています。

copyConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/a.jar
-sourceDomainLoc /scratch/oracle/config/domains/WLS_domain
-sourceOracleHomeLoc /scratch/oracle/Oracle_home1
-domainHostName myhost.example.com
-domainPortNum 7001
-domainAdminUserName weblogic
-domainAdminPasswordFile /home/oracle/password_file.txt

表A-4は、Oracle WebLogic Serverドメイン用のcopyConfigスクリプトのオプションを説明しています。

表A-4 Oracle WebLogic Serverドメイン用copyConfigスクリプトのオプション

オプション

ショートカット

説明

必須/オプション

-javaHome

NA

Java Developer's Kitの絶対パス。

オペレーティング・システムが64ビットの場合にスクリプトによりそのことが検出され、コマンド行でスクリプトに-d64オプションが渡されます。

必須

-archiveLoc

-al

アーカイブの場所の絶対パス。このオプションは、copyConfigスクリプトを使用して作成するアーカイブ・ファイルの場所の指定に使用します。

必須

-sourceDomainLoc

-sdl

Javaコンポーネントが含まれるソース・ドメインの絶対パス。

Windowsでは、バックスラッシュをパスの末尾に含めないでください。

必須

-sourceOracleHomeLoc

-soh

ソースOracleホームの絶対パス。

必須

-domainHostName

-dhn

ドメインが構成されているホストの名前。

必須

-domainPortNum

-dpn

ドメインの管理サーバーのポート番号。管理ポートを有効化する場合は、管理ポートを指定する必要があります。

必須

-domainAdminUserName

-dau

ドメインの管理ユーザーの名前。

必須

-domainAdminPasswordFile

-dap

ソース環境のドメインの管理ユーザーのパスワードが含まれるセキュア・ファイルの絶対パス。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

必須

-mdsDataExport

-mde

アプリケーションMDSメタデータをターゲットにインポートできるように、アーカイブにエクスポートするかどうかを指定します。デフォルトはtrueです。

アプリケーションMDSメタデータにエクスポートしない場合は、falseを指定します。

このオプションがtrueに設定されると、コンポーネントをターゲットにコピーするpasteConfigスクリプトは、それ以降アプリケーションMDSメタデータをターゲットにインポートします。

オプション

-opssDataExport

-ode

Oracle Platform Security Servicesデータをエクスポートするかどうかを指定します。デフォルトはtrueです。

このオプションがtrueに設定されると、コンポーネントをターゲットにコピーするそれ以降のpasteConfigスクリプトは、Oracle Platform Security Servicesデータをターゲットにインポートします。

注意: このオプションをtrueに設定した場合、pasteConfigスクリプトを実行する前に次の環境変数を設定する必要があります。

CONFIG_JVM_ARGS "-Xmx2048M -Xms2048M"

オプション

-trustKeyStoreLoc

-tkl

信頼キーストアの場所の絶対パス。domainPortNumがSSLポートであり、管理ポートとサーバーがCustomIdentityAndCustomTrustおよびCustomIdentityAndCommandLineTrustキーストアで構成されている場合は、このパラメータを使用します。

オプション

-logDirLoc

-ldl

ディレクトリの絶対パス。このディレクトリは存在していても、存在していなくてもかまいません。このディレクトリ内に新しいログ・ファイルが作成されます。デフォルトは、システムの一時ディレクトリです。

オプション

-additionalParams

-ap

追加パラメータと、スクリプトに渡されるその値。これらの変数は「キー=値」のペアで渡す必要があります。複数の変数がある場合は、カンマで区切ります。

Windowsの場合、値ペア全体を二重引用符(")で囲みます。

オプション

-silent

NA

操作をサイレントで実行するかどうかを指定します。つまり、確認のためのプロンプトは表示されません(デフォルト)。

確認のためのプロンプトを表示するように指定するには、このオプションを値falseで指定します。続行するには、yesと入力します(大/小文字は区別されません)。「yes」以外を入力すると、スクリプトが異常終了します。

オプション

-debug

NA

スクリプトのログ・レベルを設定して、デバッグ情報を提供します。デフォルトはfalseで、ログ・レベルはFINEに設定されます。trueに設定すると、ログ・レベルはFINESTに設定されます。

ログ・レベルの設定に関するその他のオプションは、第A.1.1項を参照してください。

オプション

A.1.2.4 スタンドアロン・ドメイン用copyConfigスクリプト

スタンドアロン・ドメインの構成のスナップショットが含まれる構成アーカイブを作成します。ドメインの元になるコンポーネントは、ファイル・システムやデータベースなどの様々なデータ・ストアに構成情報を保持します。

copyConfigスクリプトは、ソース環境のそれぞれのドメインで実行する必要があります。構成アーカイブは、それぞれのソース・ドメインに対して作成されます。

copyConfigスクリプトは、次の場所にあります。

(UNIX) ORACLE_HOME/oracle_common/bin/copyConfig.sh
(Windows) ORACLE_HOME\oracle_common\bin\copyConfig.cmd

構文は次のとおりです。

copyConfig  -javaHome path_of_jdk
-archiveLoc archive_location
-sourceDomainLoc domain_location
-sourceOracleHomeLoc Oracle_home_location
[-additionalParams property1=value1[, property2=value2]
[-logDirLoc log_dir_path]
[-silent {true | false}]
[-debug {true | false}]

次の例では、スタンドアロン・ドメインの構成をコピーしています。

copyConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/a.jar
-sourceDomainLoc /scratch/oracle/config/domains/base_domain
-sourceOracleHomeLoc /scratch/oracle/Oracle_home1/

表A-4は、スタンドアロン・ドメイン用のcopyConfigスクリプトのオプションを説明しています。

表A-5 スタンドアロン・ドメイン用copyConfigスクリプトのオプション

オプション

ショートカット

説明

必須/オプション

-javaHome

NA

Java Developer's Kitの絶対パス。

オペレーティング・システムが64ビットの場合にスクリプトによりそのことが検出され、コマンド行でスクリプトに-d64オプションが渡されます。

必須

-archiveLoc

-al

アーカイブの場所の絶対パス。このオプションは、copyConfigスクリプトを使用して作成するアーカイブ・ファイルの場所の指定に使用します。

必須

-sourceDomainLoc

-sdl

コンポーネントが含まれるソース・ドメインの絶対パス。

Windowsでは、バックスラッシュをパスの末尾に含めないでください。

必須

-sourceOracleHomeLoc

-soh

ソースOracleホームの絶対パス。

必須

-logDirLoc

-ldl

ディレクトリの絶対パス。このディレクトリは存在していても、存在していなくてもかまいません。このディレクトリ内に新しいログ・ファイルが作成されます。デフォルトは、システムの一時ディレクトリです。

オプション

-additionalParams

-ap

追加パラメータと、スクリプトに渡されるその値。これらの変数は「キー=値」のペアで渡す必要があります。複数の変数がある場合は、カンマで区切ります。

Windowsの場合、値ペア全体を二重引用符(")で囲みます。

オプション

-silent

NA

操作をサイレントで実行するかどうかを指定します。つまり、確認のためのプロンプトは表示されません(デフォルト)。

確認のためのプロンプトを表示するように指定するには、このオプションを値falseで指定します。続行するには、yesと入力します(大/小文字は区別されません)。「yes」以外を入力すると、スクリプトが異常終了します。

オプション

-debug

NA

スクリプトのログ・レベルを設定して、デバッグ情報を提供します。デフォルトはfalseで、ログ・レベルはFINEに設定されます。trueに設定すると、ログ・レベルはFINESTに設定されます。

ログ・レベルの設定に関するその他のオプションは、第A.1.1項を参照してください。

A.1.2.5 ノード・マネージャ用のcopyConfigスクリプト

ノード・マネージャの構成のスナップショットが含まれる構成アーカイブを作成します。

copyConfigスクリプトは、ソース環境のそれぞれのノード・マネージャでホストごとに実行する必要があります。構成アーカイブは、それぞれのソース・ノード・マネージャに対して作成されます。

注意:
ドメインごとのノード・マネージャの場合は、明示的に移動する必要はありません。ドメインの移動時に移動されます。

copyConfigスクリプトは、次の場所にあります。

(UNIX) ORACLE_HOME/oracle_common/bin/copyConfig.sh
(Windows) ORACLE_HOME\oracle_common\bin\copyConfig.cmd

構文は次のとおりです。

copyConfig  -javaHome path_of_jdk
-archiveLoc archive_location
-sourceNMHomeLoc source_Node_Manager_Home_location
[-logDirLoc log_dir_path]
[-silent {true | false}]
[-debug {true | false}]

次の例は、/scratch/oracle/Oracle_home1/wlserver/common/nodemanagerにあるソース・ノード・マネージャの構成のコピーを作成する方法を示しています。

copyConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/nm.jar
-sourceNMHomeLoc /scratch/oracle/Oracle_home1/wlserver/common/nodemanager

表A-6は、ノード・マネージャ用のcopyConfigスクリプトのオプションを説明しています。

表A-6 ノード・マネージャ用のcopyConfigスクリプトのオプション

オプション

ショートカット

説明

必須/オプション

-javaHome

NA

Java Developer's Kitの絶対パス。

オペレーティング・システムが64ビットの場合にスクリプトによりそのことが検出され、コマンド行でスクリプトに-d64オプションが渡されます。

必須

-archiveLoc

-al

アーカイブの場所の絶対パス。このオプションは、copyConfigスクリプトを使用して作成するアーカイブ・ファイルの場所の指定に使用します。

必須

-sourceNMHomeLoc

-snh

ソースのノード・マネージャ・ホームの絶対パス。

必須

-logDirLoc

-ldl

ディレクトリの絶対パス。このディレクトリは存在していても、存在していなくてもかまいません。このディレクトリ内に新しいログ・ファイルが作成されます。デフォルトは、システムの一時ディレクトリです。

オプション

-silent

NA

操作をサイレントで実行するかどうかを指定します。つまり、確認のためのプロンプトは表示されません(デフォルト)。

確認のためのプロンプトを表示するように指定するには、このオプションを値falseで指定します。続行するには、yesと入力します(大/小文字は区別されません)。「yes」以外を入力すると、スクリプトが異常終了します。

オプション

-debug

NA

スクリプトのログ・レベルを設定して、デバッグ情報を提供します。デフォルトはfalseで、ログ・レベルはFINEに設定されます。trueに設定すると、ログ・レベルはFINESTに設定されます。

ログ・レベルの設定に関するその他のオプションは、第A.1.1項を参照してください。

A.1.2.6 extractMovePlanスクリプト

構成情報をアーカイブから移動計画に抽出します。また、必要な構成計画もすべて抽出します。抽出した移動計画を編集して、ターゲット環境のプロパティを指定します。

extractMovePlanスクリプトは、次の場所にあります。

(UNIX) ORACLE_HOME/oracle_common/bin/extractMovePlan.sh
(Windows) ORACLE_HOME\oracle_common\bin\extractMovePlan.cmd

構文は次のとおりです。

extractMovePlan -javaHome path_of_jdk
-archiveLoc archive_location
-planDirLoc move_plan_directory
[-optimizationHints fusionApps,sameSchemaNameSinglePassword, rpdDataSource}
[-logDirLoc log_dir_path]
[-silent {true | false}]
[-debug {true | false}]

次の例では、アーカイブj2ee.jarから計画を抽出します。

extractMovePlan.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/j2ee.jar
-planDirLoc /scratch/oracle/t2p_plans

extractMovePlanスクリプトでは、移動計画を指定されたディレクトリに抽出します。移行するコンポーネントのタイプに応じて、extractMovePlanスクリプトは他の構成計画を抽出する場合もあります。たとえば、次のファイルを抽出します。

/scratch/oracle/t2p_plans/moveplan.xml
/scratch/oracle/t2p_plans/composites/configplan1.xml
/scratch/oracle/t2p_plans/composites/configplan2.xml
/scratch/oracle/t2p_plans/adapters/deploymentplan1.xml
/scratch/oracle/t2p_plans/adapters/deploymentplan2.xml

表A-7は、extractMovePlanスクリプトのオプションを説明しています。

表A-7 extractMovePlanスクリプトのオプション

オプション

ショートカット

説明

必須/オプション

-javaHome

NA

Java Developer's Kitの絶対パス。

オペレーティング・システムが64ビットの場合にスクリプトによりそのことが検出され、コマンド行でスクリプトに-d64オプションが渡されます。

必須

-archiveLoc

-al

アーカイブの場所の絶対パス。このオプションは、copyConfigスクリプトを使用して作成するアーカイブ・ファイルの場所の指定に使用します。

必須

-planDirLoc

-pdl

移動計画と必要な構成計画の抽出先ディレクトリの絶対パス。

このディレクトリは存在しないか、または、存在する場合は空である必要があります。

必須

-optimizationHints

-opth

ターゲット環境のトポロジに基づいて自動移入する構成値を指定します。これらの値は移動計画に含まれません。単一アーカイブ・ファイルまたは複数アーカイブ・ファイルのいずれの場合でも、このオプションを使用できます。環境に当てはまる場合は、ヒントを使用することをお薦めします。

このオプションは、次の引数をとります。

- fusionapps (fa)。-optimizationHintsオプションを使用する場合は、このヒントを指定する必要があります。

- sameSchemaNameSinglePassword (ssnsp)。特定のデータベースに関連付けられているすべてのスキーマに対して同じパスワードが使用されます。

- rpdDataSource (rpdds)。移動計画のRPD_CONFIGセクションで指定されている特定のデータベースに関連付けられているすべてのスキーマに対して同じパスワードが使用されます。
sameSchemaNameSinglePasswordフラグが指定されている場合、このフラグも自動的にtrueに設定されます。

オプション

-logDirLoc

-ldl

ディレクトリの絶対パス。このディレクトリは存在していても、存在していなくてもかまいません。このディレクトリ内に新しいログ・ファイルが作成されます。デフォルトは、システムの一時ディレクトリです。

オプション

-silent

NA

操作をサイレントで実行するかどうかを指定します。つまり、確認のためのプロンプトは表示されません(デフォルト)。

確認のためのプロンプトを表示するように指定するには、このオプションを値falseで指定します。続行するには、yesと入力します(大/小文字は区別されません)。「yes」以外を入力すると、スクリプトが異常終了します。

オプション

-debug

NA

スクリプトのログ・レベルを設定して、デバッグ情報を提供します。デフォルトはfalseで、ログ・レベルはFINEに設定されます。trueに設定すると、ログ・レベルはFINESTに設定されます。

ログ・レベルの設定に関するその他のオプションは、第A.1.1項を参照してください。

移動計画のプロパティおよび編集する必要があるプロパティの詳細は、第A.2項を参照してください。

A.1.2.7 Oracle WebLogic Serverドメイン用pasteConfigスクリプト

ソース環境からコピーされた構成をターゲット環境に適用します。スクリプトの入力には、ドメイン用のcopyConfigスクリプトで作成された構成アーカイブの場所と変更された移動計画の場所が含まれます。pasteConfigスクリプトでは、ターゲット環境のOracle WebLogic Serverドメインの構成情報を再作成します。また、ターゲット環境の移動計画のプロパティ値もマージします。

pasteConfigスクリプトは、次の場所にあります。

(UNIX) ORACLE_HOME/oracle_common/bin/pasteConfig.sh
(Windows) ORACLE_HOME\oracle_common\bin\pasteConfig.cmd

構文は次のとおりです。

pasteConfig  -javaHome path_of_jdk
-archiveLoc archive_location
-targetDomainLoc trgt_domain_path
-targetOracleHomeLoc trgt_Oracle_Home_path
-movePlanLoc move_plan_path
[-domainAdminUserName domain_admin_username
-domainAdminPasswordFile domain_admin_password_file
[-appDir WLS_application_directory]
[-logDirLoc log_dir_path]
[-silent {true | false}]
[-debug {true | false}]

次の例は、ドメインのアーカイブをOracleホームOracle_home1に適用する方法を示しています。:

pasteConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/java_ee_cl.jar
-targetDomainLoc /scratch/oracle/config/domains/dom_cl
-targetOracleHomeLoc /scratch/oracle/Oracle_home1
-movePlanLoc /scratch/oracle/java_ee/move_plan.xml
-domainAdminPasswordFile /scratch/pwd_dir/pass.txt
-logDirLoc /tmp/log

注意:
Oracle Fusion Middlewareインフラストラクチャ・インストールとしてのOracle JRFを含む環境を移行している場合は、移動計画の中で、ソースに使用されるデータベースとは異なるデータベースを、ターゲットに対して指定する必要があります。データベースのホスト、ポート、サービス名およびスキーマは同じであることができません。

表A-8は、Oracle WebLogic Serverドメイン用のpasteConfigスクリプトのオプションを説明しています。

表A-8 Oracle WebLogic Serverドメイン用pasteConfigスクリプトのオプション

オプション

ショートカット

説明

必須/オプション

-javaHome

NA

Java Developer's Kitの絶対パス。

オペレーティング・システムが64ビットの場合にスクリプトによりそのことが検出され、コマンド行でスクリプトに-d64オプションが渡されます。

必須

-archiveLoc

-al

アーカイブの場所の絶対パス。このオプションは、copyConfigスクリプトを使用して作成するアーカイブ・ファイルの場所の指定に使用します。

必須

-targetDomainLoc

-tdl

ターゲット・ドメインの絶対パス。このディレクトリは存在しないか、または、存在する場合は空である必要があります。

ドメイン・ディレクトリは、Oracleホームのディレクトリ構造の外部に配置できます。

必須

-targetOracleHomeLoc

-toh

ターゲットのOracleホームの絶対パス。ドメインの構成に使用されます。

必須

-movePlanLoc

-mpl

ソースから抽出された移動計画の更新バージョンの絶対パス。

必須

-domainAdminUserName

-dau

ターゲット・ドメインの管理ユーザーの名前。

ターゲットにソースと異なる管理ユーザーが必要な場合は、この引数を使用します。

オプション

-domainAdminPasswordFile

-dap

ターゲット環境のドメインの管理ユーザーのパスワードが含まれるセキュア・ファイルの絶対パス。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

パスワードはドメインの認証プロバイダに基づいています。たとえば、オーセンティケータには組込みLDAPや外部LDAPなどがあります。

必須

-appDir

-ad

ターゲットのOracle WebLogic Serverアプリケーション・ディレクトリの絶対パス。

オプション

-logDirLoc

-ldl

ディレクトリの絶対パス。このディレクトリは存在していても、存在していなくてもかまいません。このディレクトリ内に新しいログ・ファイルが作成されます。デフォルトは、システムの一時ディレクトリです。

オプション

-silent

NA

操作をサイレントで実行するかどうかを指定します。つまり、確認のためのプロンプトは表示されません(デフォルト)。

確認のためのプロンプトを表示するように指定するには、このオプションを値falseで指定します。続行するには、yesと入力します(大/小文字は区別されません)。「yes」以外を入力すると、スクリプトが異常終了します。

オプション

-debug

NA

スクリプトのログ・レベルを設定して、デバッグ情報を提供します。デフォルトはfalseで、ログ・レベルはFINEに設定されます。trueに設定すると、ログ・レベルはFINESTに設定されます。

ログ・レベルの設定に関するその他のオプションは、第A.1.1項を参照してください。

A.1.2.8 スタンドアロン・ドメイン用pasteConfigスクリプト

ソース環境からコピーされた構成をターゲット環境に適用します。スクリプトの入力には、ドメイン用のcopyConfigスクリプトで作成された構成アーカイブの場所と変更された移動計画の場所が含まれます。pasteConfigスクリプトは、スタンドアロン・ドメインの構成情報をターゲット環境に再作成します。また、ターゲット環境の移動計画のプロパティ値もマージします。

pasteConfigスクリプトは、次の場所にあります。

(UNIX) ORACLE_HOME/oracle_common/bin/pasteConfig.sh
(Windows) ORACLE_HOME\oracle_common\bin\pasteConfig.cmd

構文は次のとおりです。

pasteConfig  -javaHome path_of_jdk
-archiveLoc archive_location
-targetDomainLoc trgt_domain_path
-targetOracleHomeLoc trgt_Oracle_Home_path
-movePlanLoc move_plan_path
[-appDir WLS_application_directory]
[-logDirLoc log_dir_path]
[-silent {true | false}]
[-debug {true | false}]

次の例は、ドメインのアーカイブをOracleホームOracle_home1に適用する方法を示しています。:

pasteConfig.sh -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/java_ee_cl.jar
-targetDomainLoc /scratch/oracle/config/domains/dom_cl
-targetOracleHomeLoc /scratch/oracle/Oracle_home1
-movePlanLoc /scratch/oracle/java_ee/move_plan.xml
-logDirLoc /tmp/log

表A-8は、スタンドアロン・ドメイン用のpasteConfigスクリプトのオプションを説明しています。

表A-9 スタンドアロン・ドメイン用pasteConfigスクリプトのオプション

オプション

ショートカット

説明

必須/オプション

-javaHome

NA

Java Developer's Kitの絶対パス。

オペレーティング・システムが64ビットの場合にスクリプトによりそのことが検出され、コマンド行でスクリプトに-d64オプションが渡されます。

必須

-archiveLoc

-al

アーカイブの場所の絶対パス。このオプションは、copyConfigスクリプトを使用して作成するアーカイブ・ファイルの場所の指定に使用します。

必須

-targetDomainLoc

-tdl

ターゲット・ドメインの絶対パス。このディレクトリは存在しないか、または、存在する場合は空である必要があります。

ドメイン・ディレクトリは、Oracleホームのディレクトリ構造の外部に配置できます。

必須

-targetOracleHomeLoc

-toh

ターゲットのOracleホームの絶対パス。ドメインの構成に使用されます。

必須

-movePlanLoc

-mpl

ソースから抽出された移動計画の更新バージョンの絶対パス。

必須

-appDir

-ad

ターゲットのOracle WebLogic Serverアプリケーション・ディレクトリの絶対パス。

オプション

-logDirLoc

-ldl

ディレクトリの場所。このディレクトリは存在していても、存在していなくてもかまいません。このディレクトリ内に新しいログ・ファイルが作成されます。デフォルトは、システムの一時ディレクトリです。

オプション

-silent

NA

操作をサイレントで実行するかどうかを指定します。つまり、確認のためのプロンプトは表示されません(デフォルト)。

確認のためのプロンプトを表示するように指定するには、このオプションを値falseで指定します。続行するには、yesと入力します(大/小文字は区別されません)。「yes」以外を入力すると、スクリプトが異常終了します。

オプション

-debug

NA

スクリプトのログ・レベルを設定して、デバッグ情報を提供します。デフォルトはfalseで、ログ・レベルはFINEに設定されます。trueに設定すると、ログ・レベルはFINESTに設定されます。

ログ・レベルの設定に関するその他のオプションは、第A.1.1項を参照してください。

A.1.2.9 ノード・マネージャ用のpasteConfigスクリプト

ソース環境からコピーされたノード・マネージャの構成をターゲット環境に適用します。スクリプトの入力には、ノード・マネージャ用のcopyConfigスクリプトで作成された構成アーカイブの場所と変更された移動計画の場所が含まれます。pasteConfigスクリプトでは、ターゲット環境のノード・マネージャの構成情報を再作成します。また、ターゲット環境の移動計画のプロパティ値もマージします。

注意:
pasteConfigスクリプトを使用して(copyConfigスクリプトによる)ノード・マネージャのアーカイブ・コピーをターゲット環境に適用する前に、ノード・マネージャの管理対象となるすべてのドメインを移動する必要があります。また、管理サーバーが実行されている必要があります。

pasteConfigスクリプトは、ターゲット環境のそれぞれのノード・マネージャでホストごとに実行する必要があります。

構文は次のとおりです。

pasteConfig  -javaHome path_of_jdk
-archiveLoc archive_location
-targetNMHomeLoc trgt_Node_Manager_Home_path
-targetOracleHomeLoc trgt_Oracle_Home_path
-movePlanLoc move_plan_path
[-logDirLoc log_dir_path]
[-silent {true | false}]
[-debug {true | false}]

次の例は、/scratch/Oracle_home1/wlserver/common/nodemanagerにあるノード・マネージャ・ホームにノード・マネージャのコピーを適用する方法を示しています。

pasteConfig -javaHome /scratch/oracle/jdk1.8.0_40
-archiveLoc /tmp/nm.jar
-targetNMHomeLoc /scratch/oracle/Oracle_home1/wlserver/common/nodemanager
-targetOracleHomeLoc /scratch/oracle/Oracle_home1
-movePlanLoc /scratch/oracle/t2pplans/nm/moveplan.xml

表A-10は、ノード・マネージャ用のpasteConfigスクリプトのオプションを説明しています。

表A-10 ノード・マネージャ用のpasteConfigスクリプトのオプション

オプション

ショートカット

説明

必須/オプション

-javaHome

NA

Java Developer's Kitの絶対パス。

オペレーティング・システムが64ビットの場合にスクリプトによりそのことが検出され、コマンド行でスクリプトに-d64オプションが渡されます。

必須

-archiveLoc

-al

アーカイブの場所の絶対パス。このオプションは、copyConfigスクリプトを使用して作成するアーカイブ・ファイルの場所の指定に使用します。

必須

-targetNMHomeLoc

-tnh

ターゲットのノード・マネージャの絶対パス。

必須

-targetOracleHomeLoc

-toh

ノード・マネージャの構成に使用されるターゲットOracleホームの絶対パス。

必須

-movePlanLoc

-mpl

変更された移動計画のターゲット環境での絶対パス。

必須

-logDirLoc

-ldl

ディレクトリの絶対パス。このディレクトリは存在していても、存在していなくてもかまいません。このディレクトリ内に新しいログ・ファイルが作成されます。デフォルトは、システムの一時ディレクトリです。

オプション

-silent

NA

操作をサイレントで実行するかどうかを指定します。つまり、確認のためのプロンプトは表示されません(デフォルト)。

確認のためのプロンプトを表示するように指定するには、このオプションを値falseで指定します。続行するには、yesと入力します(大/小文字は区別されません)。「yes」以外を入力すると、スクリプトが異常終了します。

オプション

-debug

NA

スクリプトのログ・レベルを設定して、デバッグ情報を提供します。デフォルトはfalseで、ログ・レベルはFINEに設定されます。trueに設定すると、ログ・レベルはFINESTに設定されます。

ログ・レベルの設定に関するその他のオプションは、第A.1.1項を参照してください。

A.1.2.10 obfuscatePasswordスクリプトとAPI

不明瞭化されたパスワードが含まれるファイルを生成します。スクリプトおよび移動計画では、しばしばパスワードが含まれるファイルを指定する必要があります。

構文は次のとおりです。

(UNIX) ORACLE_HOME/oracle_common/bin/obfuscatePassword.sh
-javaHome path_to_java_home
(Windows) ORACLE_HOME\oracle_common\bin\obfuscatePassword.cmd
-javaHome path_to_java_home

スクリプトによって、パスワードおよびパスワード・ファイルが書き込まれるパス(ファイル名を含む)の入力を求めるプロンプトが表示されます。

または、APIを使用して、不明瞭化されたパスワード・ファイルを生成します。

1. 次のファイルをロードします。

ORACLE_HOME/oracle_common/jlib/obfuscatepassword.jar

2. 次のAPIを起動します。

oracle.as.t2p.framework.externalutils.ObfuscatePassword.createPasswordFile(String password, String filePath)

A.2 移動計画の使用

Oracle Fusion Middlewareコンポーネントを移行する際には、extractMovePlanスクリプトを実行して、移行するエンティティの移動計画を作成します。extractMovePlanスクリプトは、構成情報をアーカイブから移動計画に抽出します。また、必要な構成計画もすべて抽出します。アーカイブをターゲットに適用する前に、ターゲット環境の値を反映するように、移動計画を編集する必要があります。

この項の内容は次のとおりです。

- 移動計画の変更

- configGroup要素の場所

- 移動計画のプロパティ

A.2.1 移動計画の変更

READ_WRITEのスコープの移動計画プロパティを変更できます。READ_ONLYのスコープのプロパティは変更しないでください。

次の点に注意してください。

- 移動計画のセクションの追加、コメント化または削除はしないでください。

- 移動計画に変更を加えていなくても、アーカイブを作成するたびに、extractMovePlanスクリプトを使用して移動計画を生成する必要があります。別のアーカイブで作成された移動計画を使用すると、アーカイブは受け入れられず、pasteConfigスクリプトは失敗します。

- 移動計画のプロパティでIPアドレスが使用されている場合は、すべてのアドレスで同じ形式のIPプロトコルを使用する必要があります。たとえば、すべてのアドレスでIPv4形式を使用するか、またはIPv6形式を使用する必要があります。

- すべてのサーバーのリスニング・アドレスは、ソース・ファイル内でのサーバーの構成方法に関係なく、同じ形式を使用する必要があります。次のいずれかの形式を使用できますが、すべてのリスニング・アドレスで同じ形式を使用する必要があります。
実際のホスト名たとえば、hostname.domainnameなどです

IPv4アドレス

IPv6アドレス

localhost

All Local Addresses

Oracle Coherence構成を本番モードで適切に動作させるには、移動計画のすべてのリスニング・アドレスに対して、実際のホスト名またはIPアドレス(IPv6またはIPv4)を使用する必要があります。

A.2.2 configGroup要素の場所

ほとんどの移動計画には複数のconfigGroup要素が含まれます。特定のconfigGroup要素に関連付けられているプロパティについて、一覧表にconfigGroup要素ごとのプロパティがまとめています。たとえば、表A-13は、Javaコンポーネントの移動計画のプロパティの説明ですが、ここではSERVER_CONFIGやMACHINE_CONFIGなどの複数のconfigGroup要素が示されています。

次の例では、SERVER_CONFIGおよびMACHINE_CONFIG configGroup要素を使用したJavaコンポーネントの移動計画の一部を示しています。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<movePlan>
<movableComponent>
<componentType>J2EEDomain</componentType>
<moveDescriptor>
<StartupMode>PRODUCTION</StartupMode>
<configGroup>
<type>SERVER_CONFIG</type>
<configProperty id="Server1">
<configProperty>
<name>Server Name</name>
<value>AdminServer</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_ONLY</scope>
</itemMetadata>
</configProperty>
.
.
.
</configGroup>
<configGroup>
<type>MACHINE_CONFIG</type>
<configProperty id="Machine1">
<configProperty>
<name>Machine Name</name>
<value>LocalMachine</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
<configProperty>
<name>Node Manager Listen Address</name>
<value>example.com</value>
<itemMetadata>
<dataType>STRING</dataType>
<scope>READ_WRITE</scope>
</itemMetadata>
</configProperty>
.
.
.
</configGroup>

A.2.3 移動計画のプロパティ

この項の表で、Oracle Fusion Middlewareエンティティおよびコンポーネント用にカスタマイズできる移動計画のプロパティについて説明します。

注意:
多くの移動計画のプロパティでは、パスワードが含まれるファイルの場所を指定する必要があります。不明瞭化されたパスワードを使用する場合は、第A.1.2.10項の説明に従って、obfuscatePasswordスクリプトを使用できます。

編集するプロパティは、コンポーネントのタイプによって異なります。表A-11に各コンポーネントに応じたプロパティの一覧の場所を示します。

表A-11 コンポーネントの移動計画のプロパティ

コンポーネント

プロパティの一覧の場所:

スタンドアロン・ドメイン用ノード・マネージャ

表A-12

すべてのJavaコンポーネントとノード・マネージャ

表A-13

Oracle ADF接続

表A-14

Oracle B2BおよびOracle B2B for Healthcare

表A-22

Oracle Business Activity Monitoring

表A-19

Oracle Coherence

表A-15

Oracle Data Integrator

表A-29

Oracle Enterprise Scheduler

表A-23

Oracle HTTP Server

表A-17

Oracle Managed File Transfer

表A-24

Oracle Service Bus

表A-20

Oracle SOA Suite

表A-13、表A-14、表A-18

Oracle Traffic Director

表A-25

Oracle User Messaging Service

表A-13、表A-14、表A-21

Oracle Web Services Manager

表A-16

Oracle WebCenter Capture

表A-28

Oracle WebCenter Contentサーバー

表A-13、表A-14、表A-26

Oracle WebCenter Content: Imaging。

表A-13、表A-14、表A-27

Oracle WebCenter Content: Inbound Refinery。

表A-13、表A-14、表A-26

Oracle WebCenter Content: Records

表A-13、表A-14、表A-26

表A-12では、スタンドアロン・ドメイン用に構成されているホスト当たりのノード・マネージャで変更できる移動計画のプロパティについて説明します。(スタンドアロン・ドメインおよびWebLogic Serverドメイン用の追加のノード・マネージャ・プロパティを、表A-13に一覧表示しています。)ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

表A-12 スタンドアロン・ドメインのノード・マネージャの移動計画のプロパティ

プロパティ

説明

サンプル値

NODEMANAGER_PROPERTIES configGroupのプロパティ:

ノード・マネージャの構成

リスニング・アドレス

ノード・マネージャのリスニング・アドレス。

example.com

リスニング・ポート

ノード・マネージャのリスニング・ポート番号

5557

キーストア

ノード・マネージャのキーストア。有効な値は、次のとおりです。

- DemoIdentityAndDemoTrust

- CustomIdentityAndCustomTrust

- CustomIdentityAndJavaStandardTrust

DemoIdentityAndDemoTrust

カスタムIDキーストア・ファイル

カスタムIDキーストア・ファイルの場所の絶対パス

このプロパティは、ソース環境がSSLで構成されている場合にのみ、移動計画に存在します。

/scratch/oracle/Oracle_home1/wlserver/server/lib/example_identity.jks

カスタムIDキーストアのパスフレーズ・ファイル

カスタムIDキーストアのパスワードが含まれるセキュア・ファイルへの絶対パス。

ソース環境でDemoTrustを使用している場合、このプロパティは任意です。空白のままにしておくと、pasteConfigスクリプトにより警告メッセージが表示されて続行されます。ソース環境でCustomを使用している場合、このプロパティは必須です。

/scratch/oracle/i_passwd

カスタムID秘密鍵のエイリアス

IDキー・ストアの別名の値

このプロパティは、ソース環境がSSLで構成されている場合にのみ、移動計画に存在します。

mykey

カスタムID秘密鍵のパスフレーズ・ファイル

証明書の作成時に使用される秘密鍵が含まれるセキュア・ファイルへの絶対パス

このプロパティは、ソース環境がSSLで構成されている場合にのみ、移動計画に存在します。

/scratch/oracle/key_passwd

DOMAINS configGroupのプロパティ:

Oracle WebLogic Serverのドメイン構成

ドメイン名

ドメインの名前。

WLS_domain

ドメインの場所

ドメインの場所の絶対パス。

/scratch/oracle/config/domains/WLS_domain

AdminServerリスニング・アドレス

管理サーバーのリスニング・アドレス。

example.com

AdminServerリスニング・ポート

管理サーバーのリスニング・ポートの番号。

7001

AdminServerユーザー名

管理者のユーザー名

weblogic

AdminServerパスワード・ファイル

管理ユーザーのパスワードが含まれるセキュア・ファイルへの絶対パス。

/scratch/oracle/admin_passwd

ノード・マネージャのユーザー名

ノード・マネージャのユーザー名。このプロパティは必須です。

weblogic

ノード・マネージャのパスワード・ファイル

ノード・マネージャ・ユーザーのパスワードが含まれるセキュア・ファイルへの絶対パス。

このプロパティが存在する場合、これは必須です。

/scratch/oracle/nm_passwd

ノード・マネージャのログ・ファイル

ノード・マネージャのログ・ファイルの絶対位置。親ディレクトリが存在している必要があります。

/scratch/nodemanager.log

カスタム信頼キーストア・ファイル

カスタム信頼キーストアのパスワードが含まれるセキュア・ファイルへの絶対パス。

このプロパティは、configプロパティAdminServerリスニング・ポートがサーバーのSSLポートを表している場合にのみ、移動計画に存在します。

/scratch/oracle/trust_key_passwd

表A-13は、Javaコンポーネント用に変更できる移動計画のプロパティを説明しています。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

表A-13 Javaコンポーネントの移動計画の共通プロパティ

プロパティ

説明

サンプル値

起動モード

変更する必要はありません

SERVER_CONFIG configGroupのプロパティ:

Javaコンポーネントの共通プロパティ

キーストア

すべてのサーバーのキーストア。このプロパティは移動計画に一度だけ存在し、すべてのサーバーに対して関係があります。

値がDemoIdentityAndDemoTrustである場合、このconfigGroupの他のキーストア・プロパティは無視されます。

この場合、Oracle JRFで構成されていないドメインのキーストア・タイプの値はjksで、Oracle JRFで構成されているドメインの場合の値はkssです。

次のうちの1つ。

DemoIdentityAndDemoTrust
CustomIdentityAndCustomTrust
CustomIdentityAndJavaStandardTrust
CustomIdentityAndCommandLineTrust

キーストア・タイプ

すべてのサーバーのキーストア・タイプ。このプロパティは移動計画に一度だけ存在し、すべてのサーバーに対して関係があります。

JKS or KSS

管理ポート

管理サーバーのポート番号。

7001

リスニング・アドレス

WebLogic Serverのリスニング・アドレス。これはホスト名に設定するか、ホスト上のすべてのアドレスでリスニングするようにAll Local Addressesに設定します。

All Local Addresses

リスニング・ポート

リスニング・ポートの番号。

ポート番号を指定しない場合、または指定したポート番号が使用可能でない場合、エラーが返されます。

8001

SSLリスニング・ポート

SSLリスニング・ポートの番号。このプロパティは、SSLが有効な場合に移動計画に存在します。

7002

フロントエンド・ホスト

HTTPサーバーのホスト名。

このプロパティは、HTTPサーバーがサーバーに対するフロントエンドとして設定されている場合にのみ、移動計画に存在します。

example.com

フロントエンドHTTPポート

HTTPサーバー・ポートの番号。

このプロパティは、HTTPサーバーがサーバーに対するフロントエンドとして設定されている場合にのみ、移動計画に存在します。

10605

フロントエンドHTTPSポート

HTTPSサーバーのポート番号。

このプロパティは、HTTPSサーバーがサーバーに対するフロントエンドとして設定されている場合にのみ、移動計画に存在します。

10606

ログ・ファイルの場所

サーバー・ログ・ファイルの場所(デフォルトの場所にない場合)。

/scratch/servers/ms1/ms1.log

ユニキャスト・リスニング・アドレス

ユニキャスト・リスニング・アドレス。

このプロパティは、ユニキャストに対して構成されているサーバーごとに存在します。

10.240.98.232

ユニキャスト・リスニング・ポート

ユニキャスト・リスニング・ポート。

このプロパティは、ユニキャストに対して構成されているサーバーごとに存在します。

7036

デフォルトのファイル・ストア・ディレクトリ

サーバー上のデフォルトの永続ストアの構成を制御します。

ストアのデフォルトのデータは、ドメインのルート・ディレクトリのservernameサブディレクトリ内のdata\store\defaultディレクトリに保持されます。

ただし、デフォルトのストアに対して別の場所を指定できます。

注意: このプロパティは、ソース環境内で構成されてパスが絶対パスである場合にのみ、移動計画に移入されます。

このプロパティは、ユニキャストに対して構成されているサーバーごとに存在します。

DOMAIN_HOME/servername/data/store/default

キーストアのプロパティ

次のプロパティはサーバーごとに指定されます。

カスタムIDキーストア・ファイル

キーストア・タイプがJKSである場合は、カスタムIDキーストア・ファイルの場所の絶対パス。キーストア・タイプがKSSである場合は、URIパターン。

このプロパティは、キーストアがDemoIdentityAndDemoTrustでない場合は必須です。

JKS: /scratch/keystores/identity.jks
KSS: kss://appstripe/keystore

カスタムIDキーストアのパスフレーズ・ファイル

カスタムIDキーストアのパスワードが含まれるセキュア・ファイルへの絶対パス。

このプロパティは、キーストアがDemoIdentityAndDemoTrustでない場合は必須です。

/scratch/oracle/i_passwd.txt

カスタム信頼キーストア・ファイル

キーストア・タイプがJKSである場合は、カスタム信頼キーストア・ファイルの場所の絶対パス。キーストア・タイプがKSSである場合は、URIパターン。

このプロパティは、キーストアがCustomIdentityAndCustomTrustまたはCustomIdentityAndCommandLineTrustである場合は必須です。

JKS: /scratch/keystores/trust.jks
KSS: kss://appstripe/keystore

カスタム信頼キーストアのパスフレーズ・ファイル

カスタム信頼キーストアのパスワードが含まれるセキュア・ファイルへの絶対パス。

このプロパティは、キーストアがCustomIdentityAndCustomTrustである場合は必須です。

/scratch/oracle/key_passwd.txt

カスタムID秘密鍵のエイリアス

サーバーの秘密鍵を格納して取得するための文字列別名。

このプロパティは、キーストアがDemoIdentityAndDemoTrustでない場合は必須です。

Identity_key_alias

カスタムID秘密鍵のパスフレーズ・ファイル

カスタムID秘密鍵のパスワードが含まれるセキュア・ファイルへの絶対パス。

このプロパティは、キーストアがDemoIdentityAndDemoTrustでない場合は必須です。

/scratch/oracle/i_passwd.txt

IdentityKeystoreFileToBeImported

キーストア・サービスにインポートされるIDキーストア・ファイル(jksファイル)の絶対パス。

このプロパティは、キーストア・タイプがKSSで、キーストアがDemoIdentityAndDemoTrustでない場合は必須です。

/scratch/keystores/trust.jks

TrustKeystoreFileToBeImported

キーストア・サービスにインポートされる信頼キーストア・ファイルの絶対パス。

このプロパティは、キーストア・タイプがKSSで、キーストアがCustomIdentityAndCustomTrustである場合は必須です。

alias1_trust,alias2_trust

AliasesToBeImportedFromTrustKeystoreFile

信頼キーストア・ファイル(プロパティTrustKeystoreFileToBeImportedで指定)からキーストア・サービスにインポートされるエントリの別名のカンマ区切りリスト。

このプロパティは、キーストア・タイプがKSSで、キーストアがCustomIdentityAndCustomTrustである場合は必須です。

alias1_trust,alias2_trust

PasswordFilesForAliasesToBeImportedFromTrustKeystoreFile

信頼キーストア・ファイルからキーストア・サービスにインポートされる別名(プロパティAliasesToBeImportedFromTrustKeystoreFileで指定)を含むパスワード・ファイルのカンマ区切りリスト。

このプロパティは、キーストア・タイプがKSSで、キーストアがCustomIdentityAndCustomTrustである場合は必須です。

/scratch/pass/alias1_trust_pass.txt, /scratch/pass/alias2_trust_pass.txt

ネットワーク・チャネルのリスニング・アドレス

セッション・レプリケーションを使用する場合は、レプリケーション・チャネルのリスニング・アドレス。

example.host.com

ネットワーク・チャネルのリスニング・ポート

セッション・レプリケーションを使用する場合は、レプリケーション・チャネルのリスニング・ポート。

7005

ネットワーク・チャネルの外部リスニング・アドレス

セッション・レプリケーションを使用する場合は、レプリケーション・チャネルの外部リスニング・アドレス。

example.host.com

ネットワーク・チャネルの外部リスニング・ポート

セッション・レプリケーションを使用する場合は、レプリケーション・チャネルの外部リスニング・ポート。

7077

CLUSTER_CONFIG configGroupのプロパティ:

Oracle WebLogic Serverクラスタ構成プロパティ

メッセージング・モード

クラスタ・メッセージング・モード。有効な値は、unicastとmulticastです。

multicast

クラスタ・アドレス

クラスタ・アドレス。

localhost

ユニキャスト・チャネル

ユニキャスト・チャンネルの名前。

MyMulticastChannel

マルチキャスト・アドレス

マルチキャスト・アドレス。

239.192.0.0

マルチキャスト・ポート

マルチキャスト・アドレスのポート番号。

8899

フロントエンド・ホスト

クラスタのフロントエンド・ホストの名前またはIPアドレス。

example.com

フロントエンドHTTPポート

クラスタのフロントエンド・ホストのHTTPポート番号。

7008

フロントエンドHTTPSポート

クラスタのフロントエンド・ホストのHTTPSポート番号。

7009

MACHINE_CONFIG configGroupのプロパティ:

マシン構成プロパティ

マシン名

マシンの名前。

example.com

ノード・マネージャ名

ノード・マネージャの名前。この名前がマシン名プロパティとは異なる場合に、このプロパティは移動計画に表示されます。

example2.com

ノード・マネージャのリスニング・アドレス

ノード・マネージャが稼働するマシンのリスニング・アドレス。

example.com

ノード・マネージャ・リスニング・ポート

ノード・マネージャが稼働するマシンのリスニング・アドレスのポート番号。

5556

DEPLOYMENT_PLAN_CONFIG configGroupのプロパティ:

デプロイメント・プラン

デプロイメント・プラン

アプリケーションのデプロイ・プランが抽出される場所。この場所は、移動計画の場所を基準とした場所です。

deploy_plans/helloWorldEar_plan.xml

AUTHENTICATORS configGroupのプロパティ:

オーセンティケータ構成

ホスト名

LDAPサーバー・ホスト名。

example.com

ポート

LDAPサーバーのポート番号。

3060

プリンシパル

LDAPサーバーの管理ユーザー。

cn=orcladmin

パスワード・ファイル

LDAPユーザーのパスワードが含まれるセキュア・ファイルの絶対パス。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

/scratch/oracle/ldap_passwd.txt

ユーザー・ベースDN

ユーザー・ベース識別名(DN)。

cn=users,dc=us,dc=oracle,dc=com

ユーザー・オブジェクト・クラス

ユーザー・オブジェクト・クラス。

person

グループ・ベースDN

グループ・ベース識別名(DN)。

cn=groups,dc=us,dc=oracle,dc=com

GUID属性

グローバルな一意の識別子。

orclguid

DATASOURCE configGroupのプロパティ:

データ・ソースの構成

データベース名

データベースの名前。このデータベースがDB2またはSQLServerデータベースとは異なる場合に、このプロパティは移動計画に表示されます。

cert

ドライバ・クラス

データ・ソースのドライバ・クラス。『Oracle WebLogic Server JDBCデータ・ソースの管理』のWebLogic ServerでのJDBCドライバの使用に関する項を参照して、適切なクラスを選択してください。

oracle.jdbc.OracleDriver

Url

データ・ソースのデータベースのURL。これには、ホスト名、データベース・ポート番号およびSIDが含まれます。

この形式は次のとおりです。

jdbc:oracle:thin:@Db_host:Db_port:Db_SID

jdbc:oracle:thin:@host.example.com:1521:orcl

ユーザー

データ・ソースのスキーマ名。

OFM_MDS

パスワード・ファイル

データベース・スキーマのパスワードが含まれるセキュア・ファイルの絶対パス。データ・ソースの構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

/scratch/oracle/ds_passwd.txt

ONSノード・リスト

次の形式で指定される、Oracle Notification Service (ONS)ホストとポートのリスト。

ons_host1:port1,ons_host2:port2

myhost1:6100,myhost2:6101

ONSウォレット・ファイル

キーおよび証明書が含まれる資格証明ストア・ファイルの絶対パス。このプロパティは、SSLが有効になっている場合にのみ構成します。

/scratch/wallet

ONSウォレット・パスワード・ファイル

ウォレットのパスワードを含むファイルの絶対パス。

/scratch/ons_pass.txt

OPSS_SECURITY configGroupのプロパティ、LDAPのIDを持つconfigProperty内:

LDAPベース・ポリシーおよび資格証明ストアの構成。

ソースがファイルベース・ストアの場合、これらのプロパティの他に、LDAPベースおよびデータベース・ベースのポリシー、および資格認証ストア・プロパティも移動計画に表示されます。移動計画を構成する場合、ファイルベースからLDAPベースまたはデータベースベース・ストアに変更できます。

ソースがLDAPベースの場合、LDAPプロパティのみが移動計画に存在します。これを別のタイプに変更することはできませんが、LDAPエンドポイントを変更することはできます。

ソースがデータベース・ベースの場合、データベース・プロパティのみが移動計画に存在します。これを別のタイプに変更することはできませんが、データベースベースのエンドポイントを変更することはできます。

いずれかのタイプのストアのみを使用できます。いずれかを使用するには、移動計画の当該のセクションのコメントを外し、その他の箇所はコメントされるようにします。

パスワード・ファイル

LDAPサーバー管理ユーザーのパスワードが含まれるセキュア・ファイルの絶対パス。LDAPサーバーの構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

/scratch/oracle/ldap_passwd.txt

LDAPユーザー

LDAPサーバー管理ユーザー名。

cn=orcladmin

JPSルート

LDAPサーバー・コンテキスト・ルート。

cn=jpsRoot

ドメイン

ドメインの名前。

WLS_domain

LDAP Url

LDAP接続のURL。これには、LDAPストアのホスト名およびポート番号が含まれます。

ldap://example.com:3060

FILESTORE_CONFIG configGroupのプロパティ

JMSファイル・ストアの構成。

ディレクトリ

JMSファイル・ストアのディレクトリ。ディレクトリがソース環境でドメイン・ディレクトリの外部に存在するように構成されている場合、またはソース環境で明示的に構成されてパスが絶対パス(相対パスではなく)である場合、このプロパティは移動計画で公開されます。

/scratch/fmw/work0304/log/jms

OPSS_SECURITY configGroupのプロパティ、DBのIDを持つconfigProperty内:

データベース・ベースのポリシーおよび資格証明ストアの構成。

ソースがファイルベース・ストアの場合に、これらのプロパティが移動計画に表示されます。(LDAPベース・ストアは存在しないため、データベース・ベースからLDAPベース・ストアに移行することはできません。)移動計画を構成する場合、ファイルベースからLDAPベースまたはデータベースベース・ストアに変更できます。

いずれかのタイプのストアのみを使用できます。いずれかを使用するには、移動計画の当該のセクションのコメントを外し、その他の箇所はコメントされるようにします。

ソースがデータベース・ベースの場合、データベース・プロパティのみが移動計画に存在します。これを別のタイプに変更することはできませんが、データベースベースのエンドポイントを変更することはできます。

パスワード・ファイル

OPSSスキーマ所有者のパスワードが含まれるセキュア・ファイルの絶対パス。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

/scratch/oracle/ldap_passwd.txt

データソース名

データ・ソース名。この名前にはスラッシュ(/)を使用できません。

opssds

データソースのJNDI名

データ・ソースのJNDI名。

jdbc/opss

JPSルート

LDAPサーバー・コンテキスト・ルート。

cn=jpsRoot

ドメイン

ドメインの名前。

WLS_domain

ドライバ・クラス

データ・ソースのドライバ・クラス。『Oracle WebLogic Server JDBCデータ・ソースの管理』のJDBCドライバの選択に関する項を参照して、適切なクラスを選択してください。

oracle.jdbc.OracleDriver

Url

データ・ソースのデータベースのURL。これには、ホスト名、データベース・ポート番号およびSIDが含まれます。

この形式は次のとおりです。

jdbc:oracle:thin:@Db_host:Db_port:Db_SID

jdbc:oracle:thin:@host.example.com:1521:orcl

ユーザー

データ・ソースのOPSSスキーマ所有者の名前

DEV_OPSS

Prop接続URL

Content Serverに接続するためにWebbyによって使用されるURL。

idc://[IPv6_address:port}

RDBMS Security Store configGroupのプロパティ:

データベース・ベース・セキュリティ・ストアの構成。

URL

データ・ソースのデータベースのURL。これには、ホスト名、データベース・ポート番号およびSIDが含まれます。

この形式は次のとおりです。

jdbc:oracle:thin:@Db_host:Db_port:Db_SID

jdbc:oracle:thin:@host.example.com:1521:orcl

ドライバ・クラス

RDBMSセキュリティ・ストア接続のドライバ・クラス。『Oracle WebLogic Server JDBCデータ・ソースの管理』のWebLogic ServerでのJDBCドライバの使用に関する項を参照して、適切なクラスを選択してください。

oracle.jdbc.OracleDriver

ユーザー

スキーマ所有者の名前

admin

パスワード・ファイル

セキュリティ・ストア・スキーマ所有者のパスワードが含まれるセキュア・ファイルの絶対パス。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

/scratch/oracle/rbms_passwd.txt

ADAPTER configGroupのプロパティ:

リソース・アダプタ構成

デプロイメント・プラン

ターゲットへの移行時に使用されるデプロイ・プランへのパス。絶対パスを指定することも、移動計画の場所に対する相対パスを指定することもできます。

デプロイ・プランは、extractMovePlanスクリプトで抽出されます。

/scratch/adapters/adapters.xml

ノード・マネージャConfig ConfigGroupのプロパティ

管理サーバー・ホストのノード・マネージャのノード・マネージャ構成。

ノード・マネージャ・ホーム

ノード・マネージャの絶対パス。このプロパティは、ノード・マネージャ・タイプがManualNodeManagerSetupまたはCustomLocationNodeManagerのいずれかである場合に移入されます。

/scratch/oracle/domains/base_domain/nodemanager

ノード・マネージャのユーザー名

ノード・マネージャのユーザー名。

ノード・マネージャがドメイン当たりであるかカスタムの場所にある場合に、このプロパティは移動計画に表示されます。

ノード・マネージャが手動で構成されているときに値を指定しない場合、pasteConfigスクリプトによってログにエラーが記録されますが、処理は続行されます。

weblogic

ノード・マネージャのパスワード・ファイル

ノード・マネージャのパスワードが含まれているセキュア・ファイルの絶対パス。

Oracle WebLogic Serverドメインの場合、ノード・マネージャがドメイン当たりであるかカスタムの場所にあり、ユーザー名がソースと同じであるときに、パスワード・ファイルを指定しない場合、パスワードは管理パスワードにデフォルト設定されます。

Oracle WebLogic Serverドメインの場合、ノード・マネージャがドメイン当たりであるかカスタムの場所にあり、ユーザー名がソースと異なる場合、このプロパティは必須です。

スタンドアロン・ドメインの場合、ノード・マネージャがドメイン当たりであるかカスタムの場所にある場合、このプロパティは必須です。

ノード・マネージャが手動で構成されているときに値を指定しない場合、pasteConfigスクリプトによってログにエラーが記録されますが、処理は続行されます。

/scratch/oracle/nm_pass.txt

ノード・マネージャのログ・ファイル

ノード・マネージャがドメイン当たりであり、ログ・ファイルがデフォルトの場所にない場合は、ノード・マネージャのログ・ファイルの絶対位置。親ディレクトリが存在している必要があります。

/scratch/nodemanager.log

次のプロパティは、ノード・マネージャ・タイプがManualNodeManagerSetupではない場合に移入されますが、リスニング・アドレスとリスニング・ポートはMACHINE_CONFIG configGroupには移入されません。

リスニング・アドレス

ノード・マネージャのリスニング・アドレス。

example.com

リスニング・ポート

ノード・マネージャのリスニング・ポート番号

5557

次のプロパティは、nodemanager.propertiesのSecureListenerプロパティが存在してtrueではなく、ノード・マネージャ・タイプがManualNodeManagerSetupではない場合に移入されます。

キーストア

ノード・マネージャのキーストア。有効な値は、次のとおりです。

- DemoIdentityAndDemoTrust

- CustomIdentityAndCustomTrust

- CustomIdentityAndJavaStandardTrust

DemoIdentityAndDemoTrust

カスタムIDキーストア・ファイル

カスタムIDキーストア・ファイルの場所の絶対パス

このプロパティは、ソース環境がSSLで構成されている場合にのみ、移動計画に存在します。pasteConfig操作時に、キーストア・タイプがDemoIdentityAndDemoTrustである場合、このプロパティは無視されます。

/scratch/oracle/identity.jks

または、カスタムIDキーストア・タイプがKSSである場合は、次のようになります。

kss:appstripe/keystore

カスタムIDキーストアのパスフレーズ・ファイル

カスタムIDキーストアのパスワードが含まれるセキュア・ファイルへの絶対パス。

ソース環境でDemoTrustを使用している場合、このプロパティは任意です。空白のままにしておくと、pasteConfigスクリプトにより警告メッセージが表示されて続行されます。ソース環境でCustomを使用している場合、これらのパラメータは必須です。

pasteConfig操作時に、キーストア・タイプがDemoIdentityAndDemoTrustである場合、このプロパティは無視されます。

/scratch/oracle/i_passwd.txt

カスタムID秘密鍵のエイリアス

IDキー・ストアの別名の値

このプロパティは、ソース環境がSSLで構成されている場合にのみ、移動計画に存在します。pasteConfig操作時に、キーストア・タイプがDemoIdentityAndDemoTrustである場合、このプロパティは無視されます。

identity_key_alias

カスタムID秘密鍵のパスフレーズ・ファイル

証明書の作成時に使用される秘密鍵が含まれるセキュア・ファイルへの絶対パス

このプロパティは、ソース環境がSSLで構成されている場合にのみ、移動計画に存在します。pasteConfig操作時に、キーストア・タイプがDemoIdentityAndDemoTrustである場合、このプロパティは無視されます。

/scratch/oracle/key_passwd

次のプロパティは、ノード・マネージャ・タイプがManualNodeManagerSetupではなく、nodemanager.propertiesのCustomIdentityKeyStoreTypeプロパティが存在してKSSである場合、移動計画に移入されます。

JRFドメインでは、CustomIdentityKeyStoreTypeの可能な値はKSSのみで、ノード・マネージャ・タイプはPerDomainNodeManagerです。

IdentityKeystoreFileToBeImported

キーストア・サービスにインポートされるIDキーストア・ファイル(.jksファイル)の絶対パス。

このプロパティは、キーストア・タイプがKSSで、キーストアがDemoIdentityAndDemoTrustでない場合は必須です。

/scratch/keystores/trust.jks

表A-14は、Oracle ADF接続を使用している場合に変更できる移動計画のプロパティを説明しています。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。表はコンポーネントごとに分かれています。一部のコンポーネントについては、説明列にOBJECT_NAME_PROPERTYタイプが示されています。このタイプを検索して、関連するセクションを見つけることができます。

表A-14 Oracle ADF接続の移動計画のプロパティ

プロパティ

説明

サンプル値

Oracle ADF URL接続

OBJECT_NAME_PROPERTYタイプはURLConnProviderです。

ポート

URL接続に使用されるポート番号。

7000

URL

接続に使用されるURL。

example.com

Oracle ADFビジネス・コンポーネント・サービス接続

OBJECT_NAME_PROPERTYタイプはADFBCServiceConnectionです。

ServiceEndpointProvider

ビジネス・コンポーネント・サービス・エンドポイント・プロバイダ。

ADFBC

JndiFactoryInitial

JNDI初期ファクトリ・クラス。

com.sun.java.jndi.InitialFactory

JndiProviderUrl

JNDIプロバイダのURL。

t3://example.com:7101

JndiSecurityPrincipal

JNDIセキュリティ・プリンシパル名。

weblogic

WebServiceConnectionName

Webサービス接続名。

test

Oracle Enterprise Scheduler

OBJECT_NAME_PROPERTYタイプはEssConnectionです。

NotificationServiceURL

Oracle Enterprise Scheduler通知サービスURL。

http://localhost:8001

RequestFileDirectory

OES ConcurrentProcessor (CP)拡張のジョブに対するリクエスト・ログが作成されるディレクトリのパス。

/tmp/ess/requestFileDirectory

SAMLTokenPolicyURI

CP拡張で使用されるSAMLポリシーURI

oracle/wss11_saml_token_with_message_protection_service_policy

EssCallbackClientSecurityPolicyURI

Webサービスのコールバック時に、Oracle Enterprise SchedulerからWebサービスを起動する際にWS-Securityヘッダーで使用されるセキュリティ・ポリシー。

oracle/wss11_saml_token_with_message_protection_client_policy

Oracle Essbase

OBJECT_NAME_PROPERTYタイプはEssbaseConnProviderです。

ホスト

Oracle Essbaseサーバーのホスト名。

example.com

クラスタ

Oracle Essbaseサーバーがメンバーとなるクラスタの名前。

esbCluster

ポート

Oracle Essbaseサーバーのリスニング・ポート番号。

1423

ユーザー名

ユーザー名。

user3

Oracle Web Services

OBJECT_NAME_PROPERTYタイプはWebServiceConnectionです。

WsdlUrl

WSDLのURL。

http://example.com:port/MyWebService1?WSDL

Oracle Web Services

OBJECT_NAME_PROPERTYタイプはPortです。

AddressUrl

サービス・エンドポイントURL。

http://example.com:port/MyWebService1

ProxyHost

プロキシ・サーバーが稼働するホストの名前。

example.com

ProxyPort

プロキシ・サーバーがリスニングしているポート番号。

80

Oracle Web Center Content

OBJECT_NAME_PROPERTYタイプはOracle WebCenter Content - Web UIです

PropConnectionURL

Content Serverに接続するためにWebUIによって使用されるURL。

idc://IPv6_address:port

表A-15は、Oracle Coherence用に変更できる移動計画のプロパティを示します。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

表A-15 Oracle Coherenceの移動計画のプロパティ

プロパティ

説明

例

COHERENCE_SERVER_CONFIG configGroupのプロパティ

Oracle Coherenceサーバーの構成。

ユニキャスト・リスニング・アドレス

ユニキャスト・リスニング・アドレス。値がローカルホストかループバック・アドレスである場合、または値が空の場合、このプロパティは移動計画に表示されません。

10.240.98.232

ユニキャスト・リスニング・ポート

ユニキャスト・リスニング・ポート。

7036

COHERENCE_CLUSTER_CONFIG configGroupのプロパティ

Oracle Coherenceクラスタの構成。

カスタム・クラスタ構成ファイル

このクラスタを構成するために使用される外部のカスタム構成ファイル。

/scratch/external_custome_config.xml

マルチキャスト・リスニング・アドレス

マルチキャスト・リスニング・アドレス。このプロパティは、クラスタリング・モードがユニキャストではない場合に、移動計画に表示されます。

224.12.1.0

クラスタ・リスニング・ポート

クラスタ・リスニング・ポート。

12100

リスニング・アドレス

ウェル・ノウン・アドレス名構成プロパティのリスニング・アドレス。

SERVER_TEMPLATES_CONFIG configGroupのプロパティ

サーバー・テンプレートが構成されており、Coherenceクラスタ構成がサーバー・テンプレートでオーバーライドされている場合、これらのプロパティは公開されます。

ユニキャスト・リスニング・アドレス

ユニキャスト・リスニング・アドレス。値がローカルホストかループバック・アドレスである場合、または値が空の場合、このプロパティは移動計画に表示されません。

10.240.98.232

ユニキャスト・リスニング・ポート

ユニキャスト・リスニング・ポート。

7036

表A-16では、Oracle Web Services Manager用に変更できる移動計画のプロパティについて説明します。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。configProperty IDの値は編集しないでください。

表A-16 Oracle Web Services Managerの移動計画のプロパティ

プロパティ

説明

サンプル値

bootstrap.configmanager componentTypeのプロパティ

ブートストラップ・プロパティは、Oracle Web Services Managerエージェントにより、Oracle Web Services Manager Policy Managerに接続するために使用されます。

pm.url

ポリシー・マネージャのURL。ソース環境と同じポリシー・マネージャをターゲット環境で使用している場合は、このプロパティを変更する必要はありません。

t3://example.com:7003

keystore.path

キーストア・パス。これは、絶対パスであるか、またはDOMAIN_HOME/config/fmwconfigディレクトリに対する相対パスであることができます。

/scratch/oracle/domains/domain_name/config/fmwconfig/default-keystore.jks

truststore.path

トラストストアのパス。これは、絶対パスであるか、またはDOMAIN_HOME/config/fmwconfigディレクトリに対する相対パスであることができます。

/scratch/oracle/domains/domain_name/config/fmwconfig/default-keystore.jks

wsm.respository componentTypeのプロパティ

ポリシー・マネージャがドメインにインストールされている場合は、移動計画のOracle Web Services Managerリポジトリ構成。ただし、copyConfigスクリプトの-mdsDataExportパラメータをfalseに設定した場合、このコンポーネント・タイプは移動計画に存在しません。

wsm-pmがドメインにインストールされていない場合、このコンポーネントは表示されません。

configurations configGroupのプロパティ

ドメイン構成。アプリケーションまたはドメインがソース環境に登録されているか、または、ドメイン構成ドキュメントがソース環境で作成された場合に、このconfigGroupは移動計画に表示されます。

ドメインごとに1つのconfigGroupがあります。

domain

リポジトリで構成ドキュメントが作成されたコンテキストのドメイン名。特定のコンテキストでデフォルト構成に変更を行った場合に、このプロパティは移動計画に表示されます。

このプロパティを変更しない場合、構成プロパティはソース環境上と同じコンテキストを持ちます。

domain1

KerberosLoginModule:principal

使用するプリンシパルの名前。

HOST/localhost@example.com

KerberosLoginModule:key.tab

プリンシパルの秘密鍵を取得するためのキータブのパス。これは、絶対パスであるか、またはDOMAIN_HOME/config/fmwconfigディレクトリに対する相対パスであることができます。

./mylocation/krb5.keytab

ConfigManager:pm.url

ポリシー・アクセッサの場所を指定するURL。

t3://host.example.com:7003

ConfigManager:keystore.path

キーストアへのパス。これは、絶対パスであるか、またはDOMAIN_HOME/config/fmwconfigディレクトリに対する相対パスであることができます。

./mylocation/mykeystore.jks

ConfigManager:truststore.path

ドメイン構成ディレクトリに対するトラストストアの相対パス。これは、絶対パスであるか、またはDOMAIN_HOME/config/fmwconfigディレクトリに対する相対パスであることができます。

/mylocation/mykeystore.jks

KeystoreConfig:location

メッセージ保護に使用されるキーストアの場所。これは、絶対パスであるか、またはDOMAIN_HOME/config/fmwconfigディレクトリに対する相対パスであることができます。

mycustomlocation/key.tab

policysets configGroupのプロパティ

ポリシー・セットの構成。ポリシー・セットがソース環境で作成された場合に、このconfigGroupは移動計画に表示されます。

attach To

ポリシー・セットのスコープ。attachTo式のスコープがDOMAINまたはDOMAIN termの場合に、このプロパティは移動計画に表示されます。ただし、DOMAIN("*")の場合は例外が発生します。その場合、このプロパティは移動計画に表示されません。

domain1

ポリシーconfigGroupのプロパティ

ポリシーの構成。アサーションのあるポリシーがソース環境で変更された場合に、このconfigGroupが表示されます。ポリシーごとにconfigGroupsがあるため、複数存在する場合があります。このID属性は、configGroupが作成されるポリシー名です。

wsdl-uri

WSDLの実際のエンドポイントURI。

http://host:port/sts?wsdl

port-uri

STSポートの実際のエンドポイントURI。

http://host:port/sts-service

sts.auth.service.principal.name

サービスによって使用されるプリンシパルの名前。

HOST/localhost@EXAMPLE.COM

sts.auth.keytab.location

クライアントのキータブ・ファイルの場所。このプロパティは、セキュリティ・トークン・サービス(STS)がKerberosトークンで構成されている場合に表示されます。

mycustomlocation/key.tab

sts.auth.caller.principal.name

クライアントのプリンシパルの名前。

testuser

service.principal.name

サービスによって使用されるプリンシパルの名前。

HOST/localhost@EXAMPLE.COM

caller.principal.name

クライアントのプリンシパルの名前。

testuser

keytab.location

クライアントのキータブ・ファイルの場所。

mycustomlocation/key.tab

表A-17は、Oracle HTTP Server用に変更できる移動計画のプロパティを説明しています。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

Oracle HTTP Serverでは、移動計画に多数のconfigGroup要素があります。それぞれのconfigGroup要素は1つのOracle HTTP Server構成ファイルに関連付けられます。そのため、Listenなどの特定のプロパティのインスタンスは複数存在する場合があります。

表A-17 Oracle HTTP Serverの移動計画のプロパティ

プロパティ

説明

サンプル値

httpd.conf configGroupのプロパティ

全体の構成。これらのプロパティは、httpd.confファイルのプロパティに対応しています。

Listen

リスニング・アドレス。これには、ホスト名とポートを含めることも、ポートのみを含めることもできます。

orcl3.example.com:8888 or 8888

ServerName

Oracle HTTP Serverのサーバーの名前またはそのURL。ホストに登録されたDNS名がない場合、IPアドレスを使用します。

orcl1.example.com
http://host.example.com:2222

Allow

サーバーの領域にアクセスできるホストを制御します。有効な値は、from all、from full_or_partial_domain_name、from full_or_partial_IP_address、from network/netmask pair、from network/nnn CIDR specificationです。

from all

User

Oracle HTTP Server管理ユーザー。

admin_user

Group

ユーザーのグループ。

admin_group1

ServerAdmin

管理者の電子メール・アドレス。

Webmaster@example.com

DocumentRoot

Webサイトのメイン・コンテンツを格納するディレクトリ。

/scratch/oracle/base_domain/config/fmwconfig/components/OHS/instances/ohs_1/htdocs

SSLWallet

ウォレットがデフォルトの場所に存在しない場合のSSLウォレットの場所。

/scratch/oracle/base_domain/config/fmwconfig/components/OHS/ohs_1/keystores/mywallets

ssl.conf configGroupのプロパティ

SSLの構成。これらのプロパティは、ssl.confファイルのプロパティに対応しています。

Listen

SSLのリスニング・アドレス。これには、ホスト名とポートを含めることも、ポートのみを含めることもできます。

orcl3.example.com:4443 or 4443

VirtualHost

仮想ホストの名前。リストされたポート番号は、Listenプロパティにもリストされている必要があります。

*.4443

admin.conf configGroupのプロパティ

管理構成。これらのプロパティは、admin.confファイルのプロパティに対応しています。

Listen

リスニング・アドレス。これには、ホスト名とポートを含めることも、ポートのみを含めることもできます。

orcl3.example.com:8888 or 8888

VirtualHost

仮想ホストの名前。リストされたポート番号は、Listenプロパティにもリストされている必要があります。

orcl3.example.com:8888

Allow

サーバーの領域にアクセスできるホストを制御します。有効な値は、from all、from full_or_partial_domain_name、from full_or_partial_IP_address、from network/netmask pair、from network/nnn CIDR specificationです。

from all

mod_wl_ohs configGroupのプロパティ

mod_wl_ohsの構成。これらのプロパティは、mod_wl_ohs.confファイルのプロパティに対応しています。

WebLogicCluster

クラスタ内の管理対象サーバーのホスト名およびポートのカンマ区切りリスト。

host.example.com:8002,host.example.com:8003

MatchExpression

特定の構成において、既存のパラメータの値を変更するか、または新しいパラメータを追加できるパラメータ。

/integration/worklistapp WebLogicHost=host.example.com|WebLogicPort=23446

webgate.conf configGroupのプロパティ

Webgateの構成。これらのプロパティは、webgate.confファイルのプロパティに対応しています。

WebGateInstalldir

webgate.confファイルで指定されたWebGateインストール・ディレクトリの場所。

/scratch/oracle/oh_home/Oracle_OAMWebGate1/webgate/ohs

Alias

別名がデフォルトの場所に存在しない場合の別名の場所。二重引用符内の値を変更してください。

/icons/"/scratch/orcl/icons/"

ScriptAlias

スクリプトの別名がデフォルトの場所に存在しない場合のその場所。二重引用符内の値を変更してください。

/cgi-bin/"/scratch/oraclcgi-bin/"

primaryOAMServerHost

プライマリOracle Access Managerサーバー・ホスト。

初めてWebGateがプライマリ・サーバーと通信すると、セカンダリOracle Access Managerサーバー・ホストの構成は自動的に更新されます。

primary_oam_server_host.example.com

primaryOAMServerPort

Oracle Access Managerプライマリ・ホストのポート番号。

5575

dads.conf configGroupのプロパティ

PL/SQLデータベース・アクセス記述子の構成パラメータ。これらのプロパティは、dads.confファイルのプロパティに対応しています。

PlsqlDatabasePassword

PLSQLモジュールに固有の、パスワードが含まれるセキュア・ファイルの名前。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

/scratch/orcl/plsql_passwd.txt

PlsqlDatabaseConnectString

PLSQLモジュールに固有のデータベースのサービス名。

orcl.example.com:1521:orcl1

PlsqlNLSLanguage

PLSQLモジュールに固有のデータベース・アクセス記述子(DAD)のNLS_LANG変数。

America_America.UTF8

表A-18では、Oracle SOA Suite用に変更できる移動計画のプロパティについて説明します。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

表A-18 Oracle SOA Suiteの移動計画のプロパティ

プロパティ

説明

サンプル値

Composite configGroupのプロパティ:

SOAコンポジットの構成

Config Plan Location

ターゲットへの移行時にコンポジット・アプリケーションの再デプロイに使用される構成計画の場所。絶対パスを指定することも、移動計画の場所に対する相対パスを指定することもできます。

構成計画は、extractMovePlanスクリプトの実行時に抽出されます。

/scratch/app/config_plan.xml

表A-19では、Oracle Business Activity Monitoring用に変更できる移動計画のプロパティについて説明します。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

表A-19 Oracle Business Activity Monitoringの移動計画のプロパティ

プロパティ

説明

サンプル値

ApplicationURL

Oracle BAM WebアプリケーションおよびOracle BAM Serverに対するURL。

Oracle BAM WebアプリケーションおよびOracle BAM Serverが別々のホストにデプロイされていないかぎり、この値を更新する必要はありません。

http://DEFAULT:0000

DURABLE_SUBSCRIBER_NAME

EMSサンプル値に使用する永続サブスクライバ名。

myDURABLE_SUBSCRIBER_NAME

INITIAL_CONTEXT_FACTORY

EMSサンプル値に使用する初期コンテキスト・ファクトリ名。

weblogic.jndi.WLInitialContextFactory

JNDI_URL

EMSのJNDI URL。

t3://example.com:7001

JNDI_USERNAME

JNDIユーザー名。

myJMSUserName

JNDI_PASSWORD_FILE

パスワードが含まれるセキュア・ファイルの絶対パス。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

/scratch/pass/jndi_pass.txt

JMS_USERNAME

JMSユーザー名。

user1

JMS_PASSWORD_FILE

パスワードが含まれるセキュア・ファイルの絶対パス。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

/scratch/pass/jms_pass.txt

表A-20では、Oracle Service Bus用に変更できる移動計画のプロパティについて説明します。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

表A-20 Oracle Service Busの移動計画のプロパティ

プロパティ

説明

サンプル値

osb.configuration.passphrase.file

パスフレーズ・ファイルの絶対パス。ファイルはターゲット環境でアクセス可能である必要があります。

このプロパティは、-additionalParamsオプションを使用してcopyConfigスクリプトにosb.configuration.passphrase.fileを渡した場合に必要です。

パスフレーズは、ソース環境に対するものと同じである必要があります。

/scratch/passwd/osb_passwd.txt

表A-21では、Oracle User Messaging Service用に変更できる移動計画のプロパティについて説明します。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

表A-13のプロパティも編集できます。Oracle User Messaging Serviceを11gからアップグレードした場合は、データ・ソースのUserプロパティをprefix_ORASDPMからprefix_UMSに変更する必要があります。Oracle SOA SuiteおよびBusiness Process Managementのアップグレードのスキーマのアップグレード・タスクに関する項を参照してください。

表A-21 Oracle User Messaging Serviceの移動計画のプロパティ

プロパティ

説明

サンプル値

componentType UMSのプロパティ:

これらのプロパティは、すべてのドライバ・タイプに適用されます。

DefaultSenderAddress

送信者のデフォルトのアドレス。ドライバがサポートする特定のDeliveryTypeの送信者アドレスがUMSメッセージで指定されていない場合、ドライバがDefaultSenderAddressを送信者のアドレスとして使用することがあります。

SMS:1234

SenderAddresses

ドライバで処理するように構成されている送信者アドレスのリスト。SenderAdressesが指定されているドライバは、送信メッセージの送信者アドレスが一致する場合にのみ選択されます。SenderAdressesが指定されていないドライバは、メッセージの送信者アドレスに関係なく、すべての送信メッセージを処理できるとみなされます。リストは、カンマで区切られたUMSアドレスで構成されます。大/小文字の区別はありません。

EMAIL:alice@example.com,EMAIL:bob@example.com.

EmailDriver componentTypeのプロパティ:

これらのプロパティは、電子メール・ドライバに適用されます。

IncomingMailServer

受信メール・サーバーのホスト名。

usmdemo.example.com

IncomingMailServerPort

IMAP4サーバーのポート番号(143または993)、またはPOP3サーバーのポート番号(110または995)。

110

IncomingUserIDs

ドライバ・インスタンスがポーリングするメール・アカウントのユーザー名のリスト。各名前はカンマで区切られている必要があります(例: user1,user2)。

username.pop3@umsdemo.example.com

IncomingMailIDs

ユーザー名に対応する電子メール・アドレス。各電子メール・アドレスはカンマで区切られ、対応するユーザー名がユーザー名リストに表示されているとおりに、リスト内で同じ位置に配置されている必要があります。

username.pop3@umsdemo.example.com

IncomingUserPasswords

パスワードが含まれるセキュア・ファイルの絶対パス。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

ファイルには、ユーザー名に対応するパスワードのリストが含まれます。各パスワードはカンマで区切られ、対応するユーザー名がユーザー名リストに表示されているとおりに、リスト内で同じ位置に配置されている必要があります。

/scratch/oracle/ums_in_passwd.txt

OutgoingMailServer

SMTPサーバーの名前。

usmdemo.example.com

OutgoingMailServerPort

SMTPサーバーのポート番号。

25

OutgoingDefaultFromAddr

デフォルトの送信者アドレス(送信メッセージで指定されていない場合)。

username.pop3@umsdemo.example.com

OutgoingUsername

SMTP認証に使用されるユーザー名。

username.pop3@umsdemo.example.com

OutgoingPassword

SMTP認証に使用されるパスワードが含まれるセキュア・ファイルの絶対パス。SMTP認証がSMTPサーバーでサポートされている場合のみ必要です。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

このファイルにはパスワードのタイプ(「間接パスワード、新規のユーザーの作成」、「間接パスワード、既存のユーザーの使用」、「クリアテキスト・パスワードの使用」から選択)とパスワードが含まれています。

/scratch/oracle/ums_out_passwd.txt

ExtensionEndpoint configGroupのプロパティ:

これらのプロパティは、拡張ドライバに適用されます。

EndpointURL

リモート・エンドポイント・リスナーURL。

http://hostname:7001/integrationtest-war/extension

mappedDomain

受信者URIのドメイン部分がこの値と一致した場合に、メッセージの配信に使用される拡張エンドポイント。

test

SMPPDriver componentTypeのプロパティ:

これらのプロパティは、SMPPドライバに適用されます。

SmsAccountId

SMS-CのアカウントID。

myusername

SmsServerHost

SMS-Cサーバーの名前(またはIPアドレス)。

example_host

TransmitterSystemId

メッセージの送信に使用するアカウントID。

myusername

ReceiverSystemId

メッセージの受信に使用するアカウントID。

myusername

TransmitterSystemType

送信側システムのタイプ。

Logica

ReceiverSystemType

受信側システムのタイプ。

Logica

ServerTransmitterPort

送信側サーバーのTCPポート番号。

9001

ServerReceiverPort

受信側サーバーのTCPポート番号。

9001

TransmitterSystemPassword

送信側システムのパスワードが含まれるセキュア・ファイルの絶対パス。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

このファイルにはパスワードのタイプ(「間接パスワード、新規のユーザーの作成」、「間接パスワード、既存のユーザーの使用」、「クリアテキスト・パスワードの使用」から選択)とパスワードが含まれています。

/scratch/oracle/ums_trans_passwd.txt

ReceiverSystemPassword

受信側システムのパスワードが含まれるセキュア・ファイルの絶対パス。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

このファイルにはパスワードのタイプ(「間接パスワード、新規のユーザーの作成」、「間接パスワード、既存のユーザーの使用」、「クリアテキスト・パスワードの使用」から選択)とパスワードが含まれています。

/scratch/oracle/ums_rec_passwd.txt

XMPPDriver componentTypeのプロパティ:

これらのプロパティは、XMPPドライバに適用されます。

IMServerHost

Jabber/XMPPサーバーのホスト名。

example.domain.com

IMServerPort

対応するJabber/XMPPサーバー・ポート。デフォルト値は5222です。

5222

IMServerUsername

ログインで使用するJabber/XMPPユーザー名。ドメイン名がJabber/XMPPサーバー・ホスト名と異なる場合は、完全なJabber IDを入力することもできます。

myUserName@xmpp-domain

IMServerPassword

IMServerUsernameに対応するパスワードが含まれるセキュア・ファイルの絶対パス。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

このファイルにはパスワードのタイプ(「間接パスワード、新規のユーザーの作成」、「間接パスワード、既存のユーザーの使用」および「クリアテキスト・パスワードの使用」から選択)とパスワードが含まれています。

/scratch/oracle/ums_im_passwd.txt

TwitterDriver componentTypeのプロパティ

Twitterドライバのプロパティ。

認証モード

Twitterドライバで使用する認証モード。有効な値はOAuthまたはxAuthです。

OAuth

ユーザー名

Twitterユーザーのユーザー名。

MrSmith

パスワード

Twitterユーザーのパスワード。

password

ConsumerKey

Twitterユーザーの公開鍵。

Kr7px6KavOphOGLHQxa91W

ConsumerSecret

Twitterユーザーの秘密鍵。

ezDK6Ky9tIBxqMDIAPm752nFzIBdqgJF5Q4G9Bzotu

アクセス・トークン

登録済Twitterアプリケーションの公開鍵。

1091745185-SVKSxv7PFsBrFgSrywnqylWp3ANr8aS9QRMohnj

アクセス・トークン・シークレット

登録済Twitterアプリケーションの秘密鍵。

Q1PcWeDTVhaKH3DhJ9ilk1osXAtfXwXR257JEiqeYu

表A-22では、Oracle B2BおよびOracle B2B for Healthcare用に変更できる移動計画のプロパティについて説明します。ターゲット環境内で異なる値を持つホスト名、ポート番号およびリスニング・アドレスなどのプロパティをすべて編集します。連絡先および識別子を変更することもできます。

表A-22 Oracle B2BおよびOracle B2B for Healthcareの移動計画のプロパティ

プロパティ

説明

サンプル値

B2Bシステム・パラメータconfigGroupのプロパティ:

B2Bシステム・パラメータの構成。

コールアウト・ディレクトリ

コールアウト・ディレクトリの絶対パス。

/tmp/calloutDirectory

大きなペイロード・ディレクトリ

大きなペイロード・ディレクトリの絶対パス。

/tmp

SMTPホスト

AS1交換の取引パートナにネガティブMDNを送信するための、企業内のSMTPサーバーのホスト名。

host.example.com

Webサービス・ポリシー

Webサービスを保護するために使用するセキュリティ・ポリシーのURI。

oracle/wss_username_token_service_policy

SSL秘密鍵のパスワード

パスワードが含まれるセキュア・ファイルの絶対パス。パスワード・ファイルが指定されていない場合、ターゲット内で値は設定されません。

/tmp/passwordfile/sslpwd.txt

チャネルConfigGroupのプロパティ:

チャネルに関連するプロパティ。

暗号化の別名

暗号化キーの別名。これらのプロパティを使用する場合、キーストアの場所プロパティおよびキーストアのパスワード・プロパティが指定されていることを確認してください。

example

署名の別名

デジタル署名鍵の別名。

acne2Key

File.DeliveryChannel configGroupのプロパティ:

ファイル配信チャネルの構成。

file-param-folder

フォルダの絶対パス。

/tmp/file_deliv

File.ListeningChannel configGroupのプロパティ:

ファイル・リスニング・チャネルの構成。

file-param-folder

フォルダの絶対パス。

/tmp/file_listen

JMS configGroupのプロパティ:

JMSの構成。チャネルごとに独自のプロパティ値セットがあります。

jms-param-password

パスワードが含まれるセキュア・ファイルの絶対パス。パスワード・ファイルを用意しないと、値はターゲットで設定されません。ソース構成が維持されます。

/tmp/password/pass.txt

jms-param-is_topic

構成済の宛先トピックかどうかを指定するフラグ。有効な値はtrueおよびfalseです。

false

jms-param-queue_name

キューまたはトピックのJNDI名。

jms/b2b/B2B_IN_QUEUE

jms-param-DestinationProviderProperties

JMS接続先プロバイダのプロパティ。キー/値ペアのセパレータとしてセミコロン(;)を使用します。

java.naming.provider.url=t3://example.com:7001;
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;
java.naming.security.principal=weblogic;
java.naming.security.credentials=weblogic

1行で入力します。

jms-param-user

JMSユーザー名。

user1

FTP configGroupのプロパティ:

FTPの構成。チャネルごとに独自のプロパティ値セットがあります。

ftp-param-password

パスワードが含まれるセキュア・ファイルの絶対パス。パスワード・ファイルを用意しないと、値はターゲットで設定されません。ソース構成が維持されます。

/tmp/password/pass.txt

ftp-param-folder

フォルダの絶対パス。

/tmp/test1

ftp-param-host

FTPホスト名。

example

ftp-param-preserve_filename

ファイル名を保存するかどうかを指定するフラグ。有効な値はtrueおよびfalseです。

false

ftp-param-user

FTPユーザー名。

User

HTTP configGroupのプロパティ:

HTTPの構成。チャネルごとに独自のプロパティ値セットがあります。

http-param-password

パスワードが含まれるセキュア・ファイルの絶対パス。パスワード・ファイルを用意しないと、値はターゲットで設定されません。ソース構成が維持されます。

/tmp/password/pass.txt

http-param-use_proxy

プロキシ・サーバーを使用するかどうかを指定するフラグ。有効な値はtrueおよびfalseです。

false

http-param-additional_headers

追加のトランスポート・ヘッダー(Digest認証用のヘッダーなど)。

http-param-url

完全修飾されたHTTP URL。

http://example:8001/b2b/httpReceiver

as2-param-Receipt-Delivery-Option

完全修飾されたHTTP URL。

http://example:8001/b2b/httpReceiver

SFTPトランスポート・プロトコルのプロパティ:

SFTPの構成。

sftp-param-password

パスワードが含まれるセキュア・ファイルの絶対パス。パスワード・ファイルを用意しないと、値はターゲットで設定されません。ソース構成が維持されます。

/tmp/password/pass.txt

sftp-param-host

SFTPホスト名。

example

sftp-param-port

SFTPポート番号。

22

sftp-param-folder

フォルダの絶対パス。

/scratch/b2b/sftp

sftp-param-user

SFTPユーザー名。

user1

電子メール・トランスポート・プロトコルのプロパティ:

電子メールの構成。

email-param-password

パスワードが含まれるセキュア・ファイルの絶対パス。パスワード・ファイルを用意しないと、値はターゲットで設定されません。ソース構成が維持されます。

/tmp/password/pass.txt

email-param-host

電子メール・ホスト名。

example

email-param-user

電子メール・ユーザー名。

user1

email-param-email-id

メッセージ配信先の電子メール・アドレス(AQまたはJMSでのファイル・チャネルやキューのパスの指定と同じ)。

user1@exampleb2b.com

AQトランスポート・プロトコルのプロパティ:

AQの構成。

aq-param-password

パスワードが含まれるセキュア・ファイルの絶対パス。パスワード・ファイルを用意しないと、値はターゲットで設定されません。ソース構成が維持されます。

/tmp/password/pass.txt

aq-param-datasource

AQキューにアクセスするためのJDBCデータ・ソースのJNDI名。

jdbc/SOADataSource

aq-param-recipient

AQキューへのメッセージの配信時に使用する値。

testuser

aq-param-queue_name

AQキュー名。

IP_OUT_QUEUE

aq-param-consumer

メッセージを受信するクライアント。

b2buser

TCPトランスポート・プロトコルのプロパティ:

TCPの構成。

tcp-param-host

TCPホスト名。

example

tcp-param-port

TCPポート番号。

23456

tcp-param-PermanentConnectionType

キャッシュされた接続がすべてのメッセージの交換に使用されるかどうかを示すフラグ。有効な値はtrueおよびfalseです。

false

tcp-param-timeout

TCPタイムアウト(秒)。

300

B2B識別子ConfigGroupのプロパティ:

B2B識別子のプロパティ。移動計画には、1つ以上のB2B識別子を含めることができます。各識別子には、1つの取引パートナ、およびこの取引パートナに属する1つ以上の識別子を含めることができます。

『Oracle B2Bユーザーズ・ガイド』のOracle B2Bで定義されている識別子タイプに関する表を参照してください。

B2B_identifier

取引パートナのB2B識別子。

MyPartner

B2B連絡先情報ConfigGroupのプロパティ:

B2B連絡先情報のプロパティ。各取引パートナには1つ以上の連絡先があります。

連絡先名

連絡先の名前。

gcemail@email.com

B2Bキーストア詳細ConfigGroupのプロパティ:

B2Bキーストアに関連するプロパティ。

キーストアの場所

キーストアの絶対パス。

/scratch/b2b/keystore/keystore.jks

キーストア・パスワード

キーストアの認証に使用されるパスワードが含まれるセキュア・ファイルの絶対パス。構成を変更しない場合でも、パスワード・ファイルを用意する必要があります。

/tmp/oracle/pwd/ks_pwd.txt

表A-23では、Oracle Enterprise Scheduler用に変更できる移動計画のプロパティについて説明します。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。移動計画には、ソース環境で定義したプロパティも含めることができます。READ_WRITEプロパティを、ターゲット環境で有効な値で変更します。

表A-23 Oracle Enterprise Schedulerの移動計画のプロパティ

プロパティ

説明

サンプル値

ESS_CONFIG_XML configGroupのプロパティ:

Oracle Enterprise Schedulerの構成プロパティ

RequestFileDirectory

リクエストおよびログ出力のディレクトリ。

/tmp/ess/RequestFileDirectory

RequestFileDirectoryShared

リクエスト・ファイル・ディレクトリが共有されているかどうかを示すフラグ。有効な値はtrueまたはfalseです。デフォルトはfalseです。

false

ESS_ADF_DOMAIN_CONFIG configGroupのプロパティ:

Oracle Enterprise Schedulerのリクエスト出力および後処理を支援するためにadf-domain-config.xmlで構成されたプロパティ。

essappFilePersistenceMode

リクエスト実行の出力を格納するためのファイル永続性モード。

file

essappRequestFileDirectory

Oracle Enterprise Schedulerアプリケーションのリクエストおよびログ出力のディレクトリ。

/tmp/ess/MyRFD

essappCallbackClientSecurityPolicyURI

Webサービスのコールバック時、Oracle Enterprise SchedulerからWebサービスを起動する際にWS-Securityヘッダーで使用されるセキュリティ・ポリシーのURI。

oracle/wss11_saml_token_with_message_protection_client_policy

umsAppInternalHost

UMSサーバーのNotificationServiceURLホスト名。

example.domain.com

umsAppInternalPort

UMSサーバーのNotificationServiceURLポート。

10999

umsAppInternalProtocol

UMSサーバーのNotificationServiceURLプロトコル。

http

ucmAppInternalSamlTokenPolicyURI

SAMLポリシーのURI。

表A-24では、Oracle Managed File Transfer用に変更できる移動計画のプロパティについて説明します。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

表A-24 Oracle Managed File Transferの移動計画のプロパティ

プロパティ

説明

サンプル値

MFTシステム・プロパティconfigGroupのプロパティ:

システム・プロパティの構成

サーバーのプロパティ

サーバーのプロパティ

ペイロード・ストレージ・ディレクトリ

転送されるファイルが格納されるファイル・システムの場所のフルパス。

/scratch/oracle/mft/storage

コールアウト・ディレクトリ

カスタム・コールアウトが格納される場所。

/scratch/oracle/mft/callouts

外部アドレス

ロード・バランサの外部IPアドレスまたはホスト名。ロード・バランサが使用されていない場合は、ペイロード参照をカスタマに送信できる外部アドレスを参照できます。

host.example.com

内部アドレス

ロード・バランサの内部IPアドレスまたはホスト名。ロード・バランサが使用されていない場合は、ペイロード参照をカスタマに送信できる内部アドレスを参照できます。

host.example.com

キーストアのプロパティ

キーストアのプロパティ

デフォルトのキーストア・パスワード・ファイル

デフォルトのキーストアのパスワードが含まれているセキュア・ファイルの絶対パス。

/scratch/oracle/t2p/mft_db_pass.txt

デフォルトのキーストア秘密鍵パスワード・ファイル

デフォルトのキーストア秘密鍵のパスワードが含まれているセキュア・ファイルの絶対パス。

/scratch/oracle/t2p/mft_pvt_pass.txt

SSHキーストア秘密鍵パスワード・ファイル

SSHキーストア秘密鍵のパスワードが含まれているセキュア・ファイルの絶対パス。

/scratch/oracle/t2p/mft_ssh_pass.txt

PGPキーストア秘密鍵パスワード・ファイル

PGPキーストア秘密鍵のパスワードが含まれているセキュア・ファイルの絶対パス。

/scratch/oracle/t2p/mft_pgp_pass.txt

埋込みサーバーのプロパティ

埋込みFTPおよびsFTPサーバーのプロパティ。

埋込みサーバーのルート・ディレクトリ

埋込みFTPおよびsFTPサーバーのルート・ディレクトリの場所。

$DOMAIN_HOME/mft/ftp_root

ドメインのプロパティ

ドメインの構成プロパティ。

ドメイン別名

ドメインの別名。ソースまたはターゲットの構成時にドメインの詳細を参照するのに使用します。

B2B Remote

接続URL

ドメインに接続するためのURL。

t3://localhost:7001

ユーザー名

ドメインのユーザー名。

weblogic

Password File

ドメインのパスワードが含まれているセキュア・ファイルの絶対パス。

/scratch/oracle/t2p/mft_dom_pass.txt

タイプ

ドメインのタイプ: B2B、Healthcare、SOA、Service BusまたはODI。

B2B

表A-25では、Oracle Traffic Director用に変更できる移動計画のプロパティについて説明します。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

表A-25 Oracle Traffic Directorの移動計画のプロパティ

プロパティ

説明

サンプル値

http-listener configGroupのプロパティ:

HTTPリスナー構成

Ip

HTTPリスナーのIPアドレスまたはアスタリスク(*)

*

ポート

HTTPリスナーのポート番号

7001

ServerName

HTTPリスナーのサーバー名

構成計画は、extractMovePlanスクリプトの実行時に抽出されます。

hostname.example.com

tcp-listener configGroupのプロパティ:

TCPリスナー構成

Ip

TCPリスナーのIPアドレスまたはアスタリスク(*)

*

ポート

TCPリスナーのポート番号

7001

origin-server-pool configGroupのプロパティ:

オリジナル・サーバー・プール構成

origin-server-n

オリジナル・サーバーの場所。複数のサーバーを使用できます。

hostname.example.com:port

failover configGroupのプロパティ:

フェイルオーバー構成

virtual-ip

仮想IPアドレス。

ip_address

表A-26は、Oracle WebCenter Content Server、Oracle WebCenter Content: RecordsおよびOracle WebCenter Content: Inbound Refinery用に変更できる移動計画のプロパティを説明しています。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

適切なコンポーネント・タイプの下で各コンポーネントのプロパティを編集する必要があります。

表A-26 WebCenter Content Server、RecordsおよびInbound Refineryの移動計画のプロパティ

プロパティ

説明

サンプル値

componentTypeのプロパティ

componentTypeは、Content ServerまたはInbound Refineryです。

MoveType

構成およびデータを含むソース・システム・インスタンス全体をコピーするか、またはソース・システム構成に基づいて新しいコンテンツ・サーバー・インスタンスを作成するかどうかを示すフラグ。

有効な値はcopyおよびinitです。

このプロパティは、Inbound Refineryには適用できません。

copy

copy configGroupのプロパティ:

構成およびデータをコピーします。MoveTypeとしてcopyを使用する場合、これらのプロパティを使用します。

IntradocDir

Intradocディレクトリへのパス。ディレクトリ値は、ターゲット・システムのドメイン・ホーム・ディレクトリのパスに置き換えられる文字列{domainHome}で始まります。

/scratch/oracle/config/domains/domain_name/ucm/cs
or
{domainHome}/ucm/cs

WeblayoutDir

Weblayoutディレクトリへのパス。ディレクトリ値は、ターゲット・システムのドメイン・ホーム・ディレクトリのパスに置き換えられる文字列{domainHome}で始まります。

このプロパティは、WebLayoutDirがIntradocディレクトリ下のデフォルトの場所にある場合は、存在しないことがあります。

/scratch/oracle/config/domains/domain_name/ucm/cs/weblayout
or
{domainHome}/ucm/cs/weblayout

VaultDir

Vaultディレクトリへの絶対パス。ディレクトリ値は、ターゲット・システムのドメイン・ホーム・ディレクトリのパスに置き換えられる文字列{domainHome}で始まります。

このプロパティは、VaultDirがIntradocディレクトリ下のデフォルトの場所にある場合は、存在しないことがあります。

/scratch/oracle/config/domains/domain_name/ucm/cs/vault
or
{domainHome}/ucm/cs/vault

UserProfilesDir

ユーザー・プロファイル・ディレクトリへの絶対パス。ディレクトリ値は、ターゲット・システムのドメイン・ホーム・ディレクトリのパスに置き換えられる文字列{domainHome}で始まります。

このプロパティは、これがIntradocディレクトリ下のデフォルトの場所にある場合は、存在しないことがあります。

/scratch/oracle/config/domains/domain_name/ucm/cs/data/users/profiles
or
{domainHome}/ucm/cs/users/profiles

SocketHostAddressSecurityFilter

サーバー・ポートに直接アクセスできるホストを示すセキュリティ・フィルタ。縦棒(|)で区切って複数の値を指定できます。

ソースにIPv6が使用されている場合、IPv6を使用してこのプロパティを更新します。また、IPv6アドレスを使用してすべてのサーバーのリスニング・アドレスおよびPropConnectionURLを更新する必要があります。

127.0.0.1|0.0.0.0.0.0.0.1
or for IPv6:
*.*.*.*|IPv6_address

init configGroupのプロパティ:

ソースの構成で新しいインスタンスを作成します。MoveTypeとしてinitを使用する場合、これらのプロパティを使用します。

SocketHostAddressSecurityFilter

サーバー・ポートに直接アクセスできるホストを示すセキュリティ・フィルタ。縦棒(|)で区切って複数の値を指定できます。

127.0.0.1|0.0.0.0.0.0.0.1
or for IPv6:
*.*.*.*|IPv6_address

表A-27は、Oracle WebCenter Content: Imaging用に変更できる移動計画のプロパティを説明しています。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

表A-27 Oracle WebCenter Content: Imagingの移動計画のプロパティ

プロパティ

説明

サンプル値

AdminUser

シード・システム・セキュリティに対するpasteConfig操作中に使用される管理ユーザーID。空白のままの場合は、pasteConfigコマンド行で提供されるドメイン管理者ユーザーが使用されます。このプロパティは、Imaging管理ユーザーをドメイン管理者以外のユーザーにする必要がある場合に使用されます。

Admin2

MBean Settings configGroupのプロパティ:

MBeansの構成

InputAgentInputDirectories

入力ソースが作業を検索するディレクトリのカンマ区切りリスト。

IPM/InputAgent/Input

InputSampleDirectory

入力UIのサンプル・データを保持するディレクトリ。

IPM/InputAgent/Input/Sample

RenderGDFontPath

OITレンダリング・パッケージで使用されるTrueType (TTF)フォント・ファイル。

/usr/share/X11/fonts/TTF

UCM Connection configGroupのプロパティ:

WebCenter Contentの接続構成

repository.machine

リポジトリの場所。接続を「ローカルContent Serverの使用」に構成する場合は、値をlocalhostにする必要があります。

localhost

repository.port

ローカル・コンテンツ・サーバーの使用時に使用されるWebCenter Contentサーバー・ポート。ローカル・コンテンツ・サーバー接続を使用しない場合は、構成プロパティを削除します。

4444

repository.useSSL

WebCenter Contentシステムへの接続でSSLを使用するかどうかを指定するフラグ。有効な値はtrueまたはfalseです。

false

WORKFLOW Connection configGroupのプロパティ:

ワークフローの接続構成

bpel.front.address

Imaging SOA: 接続設定UIで使用されるHTTPフロントエンド・アドレス。

http://example.com:8001

表A-28は、Oracle WebCenter Capture用に変更できる移動計画のプロパティを説明しています。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

表A-28 Oracle WebCenter Captureの移動計画のプロパティ

プロパティ

説明

サンプル値

oracle.odc.importprocessor.email.connection_retries

電子メール・サーバーへの接続の試行が失敗した場合に、接続の再試行回数を決定します。指定しない場合、デフォルト値は0です(接続は再試行されません)。

0

oracle.odc.importprocessor.email.operation_timeout

電子メール・サーバーに接続した後、電子メール・サーバーに関連する他の機能すべてにこのタイムアウト(ミリ秒単位)が適用されます。

6000

oracle.odc.emailbroadcast.smtp_userid

capture SMTPサーバーのユーザーID

username

oracle.odc.emailbroadcast.smtp_message_from

captureから送信された電子メールすべてのFromフィールドに表示される名前。

username

oracle.odc.orphaned_import_token_check_interval

親なしのインポート・トークンをチェックする頻度(秒単位)。

60

oracle.odc.gd_font_path

Unixシステムの場合、Unixフォント・ディレクトリの場所を指定します。このパスは、PDFイメージ専用のエクスポート・ドライバが、PDFドキュメントのフォントをレンダリングするために使用します。

/usr/share/X11/fonts

oracle.odc.offlinejob_processing_delay

オフライン・ジョブがオンラインに戻って処理の準備が整ったかどうかを確認するまで待機する時間の長さ(秒単位)。

5

oracle.odc.max_processing_attempts

処理に失敗したバッチをエラー状態にするまでに行う再試行の回数。

5

oracle.odc.audit_ids

監査するイベントのアクションIDのカンマ区切りのリスト。有効なIDのリストは、Oracle WebCenter Enterprise Captureの管理のCaptureの監査に関する項を参照してください。

1001,1004,1005,1006,1011,1014,2001,2002,2003

oracle.odc.importprocessor.email.buffer_size

サーバーからフェッチされたメッセージのバッファ・サイズ。

262144

oracle.odc.systemid

組織内でCaptureシステムを特定するために使用される一意の識別子

Capture_01

oracle.odc.importprocessor.email.javamail_debug

trueに設定されているときにサーバーの.outログ・ファイルに格納されるJavaメールのデバッグ出力を有効にします。(指定しない場合、デフォルト値はfalseです。)

false

oracle.odc.poll_for_client_bundles

更新済クライアント・バンドルをチェックする頻度。秒単位で測定されます。

30

oracle.odc.days_to_retain_batches

キャッシュがクライアント・ワークステーションで保持される日数であるデフォルトのバッチ保存日数。バッチは、ロックされている場合は削除されません。この値より古いバッチは、クライアント・アプリケーションのロード時にパージされます。

3

oracle.odc.max_property_updates_t2p

T2P操作で変更できるカスタム・プロパティの最大数。

1

oracle.odc.import_token_expiration

インポート・プロセッサ・トークンが期限切れだとみなされるまでの分数。

5

oracle.odc.import_job_refresh_interval

処理を必要とするインポート・ジョブをチェックするために内部タイマーが起動する頻度(秒単位)であるインポート・ジョブ・リフレッシュ間隔。

60

oracle.odc.emailbroadcast.smtp_ssl

サーバーからブロードキャストされたメッセージのfrom電子メール・アドレスがSSLを使用しているかどうかを示します。

有効な値: 0 (false)または1 (true)です。

1

oracle.odc.emailbroadcast.smtp_start_tls

SMTPサーバーがTLSを起動するかどうかを示します。

有効な値: 0 (false)または1 (true)です。

1

oracle.odc.doc_conversion_max_paper_size_oit

ドキュメント変換プロセッサを使用してイメージを作成するときに使用する最大用紙サイズを表す文字列。カンマで区切られた有効な値は、次のとおりです: A1, A2, A3, A4, LETTER, LEGAL, LEDGER

LETTER

oracle.odc.importprocessor.email.connection_timeout

電子メール・サーバーへの接続を確立するまでCaptureが待機する時間(ミリ秒単位)。指定しない場合、デフォルト値は120000 (2分)です。

6000

oracle.odc.emailbroadcast.smtp_host

システム関連メッセージの送信に使用される電子メール・サーバーのホスト名。

test@example.com

oracle.odc.emailbroadcast.smtp_port

SMTPホストのポート番号。

80

oracle.odc.max_batch_search_rows

バッチの検索で返されるバッチの最大数を示すデフォルト値。

100

表A-29では、Oracle Data Integrator用に変更できる移動計画のプロパティについて説明します。ホスト名、ポート番号、リスニング・アドレスなどのすべてのプロパティを編集して、ターゲット環境で異なる値にします。

表A-29 Oracle Data Integratorの移動計画のプロパティ

プロパティ

説明

サンプル値

Master Repository configGroupのプロパティ:

マスター・リポジトリの構成

Url

マスター・リポジトリに接続するためのJDBC URL

jdbc:oracle:thin:@localhost:1522:orcl

Schema name

ターゲットODIリポジトリが作成されるターゲット・データベースにあるスキーマの名前。

odi_master_12c

Schema password file

スキーマのパスワードが含まれるセキュア・ファイルの絶対パス。

/scratch/oracle/odi_schema_passwd.txt

SUPERVISOR user

ODIユーザーSUPERVISOR名

SUPERVISOR

SUPERVISOR password file

ODIユーザーSUPERVISORのパスワードが含まれるセキュア・ファイルの絶対パス。

/scratch/oracle/odi_passwd.txt

Physical Data Servers configPropertyのプロパティ:

データ・サーバーの構成

Schema name

データベース・データ・サーバーのスキーマ名またはファイル・タイプ・データ・サーバーのディレクトリの場所。

FG_Dir_Schema

Work Schema

データベース・データ・サーバーの作業スキーマの名前またはファイル・タイプ・データ・サーバーのディレクトリの場所。

/tmp/FG_Dir_Schema

Url

データ・サーバーに接続するためのJDBC URL。

jdbc:oracle:thin:@localhost:1521/example.com

User

物理データ・サーバー接続用のユーザー名。

username

Password File

物理データ・サーバー接続用のユーザー・パスワードが含まれるセキュア・ファイルの絶対パス。

/scratch/oracle/rpd_ds_conn_passwd.txt

Agents configPropertyのプロパティ:

エージェントの構成

Host name

エージェントのホスト名。

localhost

Host port

エージェントのホスト・ポート番号。

12311

Work Repositories configPropertyのプロパティ:

作業リポジトリの構成

Url

作業リポジトリに接続するためのJDBC URL。

jdbc:oracle:thin:@localhost:1521/example.com

User

作業リポジトリに接続するためのユーザー名。

username

Password File

物理データ・サーバー接続用のユーザー・パスワードが含まれるセキュア・ファイルの絶対パス。

/scratch/oracle/odi_pds_passwd.txt

B Oracle Fusion Middlewareコマンド行ツール

この付録では、Oracle Fusion Middlewareで使用可能なコマンド行ツールについてまとめます。

表B-1 Oracle Fusion Middlewareコマンド行ツール

コマンド

パス

説明

adrci

UNIX: ORACLE_HOME/oracle_common/adr/adcri.sh

Windows: ORACLE_HOME\oracle_common\adr\adrci.bat

Oracleサポートへ送信するために、インシデントや問題の情報をZIPファイルにパッケージ化します。

config

UNIX: ORACLE_HOME/oracle_common/common/bin/config.sh
Windows:ORACLE_HOME\oracle_common\common\bin\config.cmd

構成ウィザードを起動して、ドメインの作成や構成、またはドメインの拡張を行います。

関連項目: 該当コンポーネントのインストレーション・ガイド

ua

UNIX: ORACLE_HOME/oracle_common/upgrade/bin /ua
Windows: ORACLE_HOME\oracle_common\upgrade\ua.bat

Oracle Fusion Middlewareのアップグレード・アシスタント。

『Oracle Fusion Middlewareのアップグレードのプランニング』を参照

orapki

UNIX: ORACLE_HOME/oracle_common/bin/orapki
Windows: ORACLE_HOME\oracle_common\bin\orapki.bat

ウォレットおよび証明書を管理します。付録Gを参照。

wlst

UNIX: ORACLE_HOME/oracle_common/common/bin/wlst.sh
Windows: ORACLE_HOME\oracle_common\common\bin\wlst.cmd

(WebLogic Scripting Tool) Oracle WebLogic Server、およびOracle WebLogic Serverドメイン内のコンポーネントを管理します。

第2.4項、『WebLogic Server WLSTコマンド・リファレンス』、および『インフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』を参照してください。

C コンポーネントのURL

この付録では、Oracle Fusion Middlewareの各コンポーネントへのアクセスに必要なURLを記載します。

表C-1に、インストール後にコンポーネントへアクセスするためのURLを示します。

表には、URLとともにデフォルト・ポートが示されています。環境によっては、コンポーネントで異なるポートが使用される場合があります。ポート番号を決定するには、Fusion Middleware Controlの「WebLogicドメイン」メニューで「ポートの使用状況」を選択します。

表C-1 コンポーネントのURL

コンポーネント

URL(およびデフォルトのポート番号)

Oracle B2B

http://host:8001/b2b

Oracle Business Activity Monitoring

http://host:9001/oracleBAM

Oracle Enterprise Manager Fusion Middleware Control

http://host:7001/em

Oracle HTTP Server

http://host:7777

Oracle Managed File Transfer

http://host:7001/mftconsole

Oracle Service Bus

http://host:7001/sbconsole

Oracle WebLogic Server管理コンソール

http://host:7001/console

D ポート番号

この付録では、Oracle Fusion Middlewareのポート番号について説明します。

内容は次のとおりです。

- コンポーネント別のポート番号

- ポート番号(番号別)

D.1 コンポーネント別のポート番号

この項では、ポートを使用する各Oracle Fusion Middlewareコンポーネントまたはサービスに関する次の情報について説明します。

- コンポーネントまたはサービス: コンポーネントおよびサービスの名前。

- デフォルトのポート番号: Oracle Fusion Middlewareがコンポーネントに割り当てる最初のポート番号。これは通常、割り当てられているポート範囲内の最小の数値です。このポートが使用されている場合、割り当てられているポート範囲内で次に使用可能なポート番号が割り当てられます。

- 割り当てられているポート範囲: Oracle Fusion Middlewareがポートを割り当てるときに使用する一連のポート番号。

Oracle WebLogic Serverサーバーのポート番号は、作成される各サーバーに対して順次割り当てられます。たとえば、最初の管理サーバーにポート7001が割り当てられた場合、2番目のサーバーには7002が割り当てられます。特定のコンポーネントのインストールおよび構成中に作成される管理対象サーバーは、特定のデフォルトのポート番号を持つ場合があります。

表D-1は、コンポーネントのデフォルトのポート番号およびポート番号範囲を、コンポーネントのアルファベット順で記載したものです。

表D-1 ポート番号(コンポーネント順)

コンポーネントまたはサービス

デフォルトのポート番号

割り当てられているポート範囲

Oracle Business Activity Monitoring

9001

9000-9080

Oracle Data Integrator

15000

15500

Oracle HTTP Serverの非SSLリスニング・ポート

7777または8888

7777-7877, 8888

Oracle HTTP ServerのSSLリスニング・ポート

4443

4443-4543

管理サーバーのOracle WebLogic Serverリスニング・ポート

7001

7001-9000

管理対象サーバーのOracle WebLogic Serverリスニング・ポート

7003

7003-9000

Oracle WebLogic Serverのノード・マネージャ・ポート

5556

5556

管理サーバーのOracle WebLogic Server SSLリスニング・ポート

7002

7002-9000

D.2 ポート番号(番号順)

表D-2は、Oracle Fusion Middlewareのポート番号およびコンポーネントを、ポート番号の昇順で記載したものです。

表D-2 ポート番号(番号順)

デフォルトのポート番号

コンポーネントまたはサービス

4443

Oracle HTTP Server (SSL)

5556

Oracle WebLogic Serverのノード・マネージャ・ポート

7001

管理サーバーのOracle WebLogic Serverリスニング・ポート

7002

管理サーバーのOracle WebLogic Server SSLリスニング・ポート

7003

管理対象サーバーのOracle WebLogic Serverリスニング・ポート

7777

Oracle HTTP Server(非SSL)

9001

Oracle Business Activity Monitoringの管理対象サーバー

15000

Oracle Data Integrator

E Oracle Fusion Middlewareのアクセシビリティ・オプションの使用

この付録では、Oracle Fusion Middlewareのアクセシビリティ・オプションの使用方法について説明します。

次の項目について説明します。

- Java Access Bridgeのインストールおよび構成(Windowsのみ)

- Fusion Middleware Controlアクセシビリティ・モードの有効化

- Fusion Middleware Controlのキーボード・ナビゲーション

E.1 Java Access Bridgeのインストールおよび構成(Windowsのみ)

Windowsコンピュータの場合、Java Access Bridgeをインストールおよび構成して第508条のアクセシビリティを使用できます。

1. Java Access Bridgeを次のURLからダウンロードします。

http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136191.html

2. Java Access Bridgeをインストールします。

3. access-bridge.jarファイルおよびjaccess-1_4.jarファイルをインストール場所からjre/lib/extディレクトリにコピーします。

4. WindowsAccessBridge.dllファイル、JavaAccessBridge.dllファイルおよびJAWTAccessBridge.dllファイルをインストール場所からjre/binディレクトリにコピーします。

5. accessibility.propertiesファイルをjre/libディレクトリにコピーします。

E.2 Fusion Middleware Controlアクセシビリティ・モードの有効化

次の各項では、Fusion Middleware Controlをアクセシビリティ・モードで実行する利点およびアクセシビリティ・モードを有効化する手順について説明します。

- HTMLページに対するアクセスのしやすさの強化

- Fusion Middleware Controlグラフのテキスト説明の表示

E.2.1 HTMLページに対するアクセスのしやすさの強化

Fusion Middleware Controlでは、スクリーン・リーダーのサポートを有効にすることができます。スクリーン・リーダーのサポートによりスクリーン・リーダーの動作が向上します。これは、アクセシビリティ固有の構成をHTMLに追加し、ページ上のナビゲーション要素の一部を変更することにより実現します。

Fusion Middleware Controlでスクリーン・リーダー・モードを有効化するには:

1. ページの右上にあるユーザー名を選択し、「アクセシビリティ」を選択します。
「アクセシビリティ・プリファレンス」ページが表示されます。

2. 次のいずれかのオプションを選択します。

- スクリーン・リーダーを使用する: アクセシビリティ固有の構成が追加されて、スクリーン・リーダーの動作が向上します。

- 高コントラスト設定を使用します: フォントで高コントラストを使用します。

- 大きいフォントを使用します: フォントが通常より大きくなります。

- ログイン時に「アクセシビリティ・プリファレンス」ダイアログを表示: ログイン時に「アクセシビリティ・プリファレンス」ページが表示されます。

3. 「適用」をクリックします。
「確認」ダイアログ・ボックスが表示されます。

4. 「OK」をクリックします。

5. ページ上部の「Enterprise Manager」をクリックすると、最後にアクセスしたページに戻ります。

スクリーン・リーダーのサポートを選択すると、Fusion Middleware Controlは、スクリーン・リーダーで読むことができるようにWebページをレンダリングします。たとえば、ナビゲーション・ツリーの各ノードに「選択」ボタンが含まれるようになります。

次の図は、スクリーン・リーダーのサポートを有効化した後のナビゲーション・ペインおよび管理サーバーのパフォーマンス・サマリーを示します。

E.2.2 Fusion Middleware Controlグラフのテキスト説明の表示

Fusion Middleware Control全体で、パフォーマンス・データの表示にはグラフが使用されます。ほとんどのユーザーにとって、これらのグラフは、トレンドを理解し、パフォーマンス・メトリックの最小値および最大値の特定に役立つ、データのグラフィック表示となります。

ただし、グラフでは、スクリーン・リーダーで読めるような方法で情報を表示することはできません。この問題を改善するために、各パフォーマンス・グラフの完全なテキスト表現を提供するようにFusion Middleware Controlを構成できます。スクリーン・リーダー・モードを有効にすると、Fusion Middleware Controlは、情報をグラフではなく表で表示します。

スクリーン・リーダー・モードを有効にせずに、データをグラフではなく表で表現するには、グラフの下の「表ビュー」をクリックします。

E.3 Fusion Middleware Controlのキーボード・ナビゲーション

この項では、Fusion Middleware Controlのキーボード・ナビゲーションについて説明します。

キーボード・ナビゲーションの多くは、スクリーン・リーダー・モードを使用していても使用していなくても同じです。

一般的に、次のキーを使用してナビゲートします。

- [Tab]キー: ページ内で次のコントロール(動的ターゲット・メニュー、ナビゲーション・ツリー、コンテンツ・ペイン、タブなど)に移動します。[Tab]キーを押すと、ページの左から右、上から下へと移動します。前のコントロールに移動するには、[Shift]+[Tab]キーを押します。

- 上矢印キーおよび下矢印キー: ナビゲーション・ツリー、メニューまたは表内で前の項目または次の項目に移動します。下矢印キーを押してメニューを開くこともできます。

- 左矢印キーおよび右矢印キー: ナビゲーション・ツリーまたはサブメニューで項目を閉じたり開いたりします。

- [Esc]キー: メニューを閉じます。

- [Space]キー: コントロールをアクティブ化します。たとえば、チェック・ボックスで[Space]キーを押すと、状態が切り替わります(ボックスの選択または選択解除)。リンクで[Space]キーを押すと、リンクのターゲットにナビゲートします。

- [Enter]キー: ボタンをアクティブ化します。

表E-1は、共通タスクの一部と、それに使用されるキーボード・ナビゲーションを示します。

表E-1 共通タスクのキーボード・ナビゲーション

タスク

ナビゲーション

次のコントロール(ナビゲーション・ツリー、メニューなど)に移動する

[Tab]

前のコントロール(ナビゲーション・ツリー、メニューなど)に移動する

[Shift]+[Tab]

ナビゲーション・ペインに移動する

[Tab]キー(ナビゲーション・ツリーに入力フォーカスが移動するまで)

ナビゲーション・ツリーを下に移動する

下矢印

ナビゲーション・ツリーを上に移動する

上矢印

フォルダを開く

右矢印

フォルダを閉じる

左矢印

メニューを開く

下矢印

メニュー内の次の項目に移動する

下矢印

メニュー内の前の項目に移動する

上矢印

メニュー項目を選択する

[Enter]

サブメニューを開く

右矢印

サブメニューを閉じる

左矢印

メニューの外に移動する

[Esc]

ボタンをアクティブ化する

[Enter]

コンテンツ・ペインのタブを開く

コンテンツ・ペインで[Tab]キーを押し、入力フォーカスを取得するタブで[Tab]キーを押してから、[Enter]キーを押してそのタブを選択する

項目(「ログ・メッセージ」画面におけるメッセージ・タイプなど)を選択する

[Space]

表内の行を選択する

表のヘッダーで[Tab]キーを押し、下矢印を押して行に移動する

表内のセルを選択する

表のヘッダーで[Tab]キーを押し、選択するセルに到達するまで[Tab]キーを押してから、[Enter]キーを押す

F リリース番号の確認

この付録では、Oracle Fusion Middlewareのリリース番号の確認方法について説明します。

この付録の内容は次のとおりです。

- リリース番号の書式

- ソフトウェア・インベントリおよびリリース番号の確認

F.1 リリース番号の書式

Oracleで使用されるリリース・レベルの命名体系を理解するには、図F-1に示したOracle Fusion Middlewareのリリース番号の例を確認してください。

図F-1 Oracle Fusion Middlewareのリリース番号の例

図F-1の各数字のラベルの意味は次のとおりです。

- 最初の2つの番号は、メジャー・リリース番号です。
これは最も一般的な識別子です。これは、Oracle Fusion Middlewareの主要な新規版(バージョン)を表すものであり、そのリリースに重要な新機能が含まれることを表します。

- 3つ目の番号は、マイナー・リリース番号です。

- 4つ目の番号は、パッチ・セット・リリースを表します。

- 5つ目の番号は、パッチ・セット更新リリースを表します。

F.2 ソフトウェア・インベントリおよびリリース番号の確認

次の各項で、Oracle Fusion Middlewareのリリース番号の取得方法を説明します。

- Oracle Fusion Middlewareインストールのリリース番号の確認

- コンポーネント・リリース番号の確認

- メタデータ・リポジトリのリリース番号の確認

F.2.1 Oracle Fusion Middlewareインストールのリリース番号の確認

すべてのOracle Fusion Middlewareインストールにはリリース番号があります。この番号は、パッチ・セット・リリースの適用時やインストールのアップグレード時に更新されます。

Oracle Fusion Middlewareインストールのリリース番号は、Opatchを使用して確認できます。次のコマンドを実行します。

(UNIX) ORACLE_HOME/OPatch/opatch lsinventory
(Windows) ORACLE_HOME\OPatch\opatch lsinventory

UNIXの場合の例:

./opatch lsinventory
Copyright (c) 2014, Oracle Corporation.  All rights reserved.

Oracle Home       : /scratch/oracle1/Oracle/Middleware/Oracle_Home
Central Inventory : /scratch/oracle1/oraInventory
from           : /scratch/oracle1/Oracle/Middleware/Oracle_Home/oraInst.loc
OPatch version    : 13.2.0.0.0
OUI version       : 13.2.0.0.0
Log file location : /scratch/oracle1/Oracle/Middleware/Oracle_Home/cfgtoollogs/opatch/opatch2014-05-29_13-23-02PM_1.log

OPatch detects the Middleware Home as "/scratch/oracle1/Oracle/Middleware/Oracle_Home"
May 29, 2014 1:23:33 PM oracle.sysman.oii.oiii.OiiiInstallAreaControl initAreaControl
INFO: Install area Control created with access level  0
Lsinventory Output file location : /scratch/oracle1/Oracle/Middleware/Oracle_Home/cfgtoollogs/opatch/lsinv/lsinventory2014-05-29_13-23-02PM.txt

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

There are no Interim patches installed in this Oracle Home.

F.2.2 Oracle WebLogic Serverのリリース番号の確認

Oracle WebLogic Serverのリリース番号は、次のコマンドを使用して確認できます。

(UNIX) cat $ORACLE_HOME/wlserver/.product.properties | grep WLS_PRODUCT_VERSION
(Windows) type %0RACLE_HOME%\wlserver\.product.properties | findstr WLS_PRODUCT_VERSION

UNIXの場合の例:

cat $ORACLE_HOME/wlserver/.product.properties | grep WLS_PRODUCT_VERSION
WLS_PRODUCT_VERSION=12.1.3.0.00

F.2.3 コンポーネント・リリース番号の確認

Oracle Fusion Middlewareのすべてのコンポーネントにはリリース番号があり、コンポーネントの多くはリリース番号を持つサービスを備えています。これらの番号は、パッチ・セット・リリースの適用時またはインストールのアップグレード時に更新される可能性があります。

コンポーネントとそのサービスのリリース番号は、次のコマンドを使用して確認できます。

- UNIXの場合:

cd ORACLE_HOME/inventory
ls -d Components*/*/*

- Windowsの場合:

cd ORACLE_HOME/inventory/Componentsn
dir /S /A:D

Oracle Fusion Middleware

F.2.4 メタデータ・リポジトリのリリース番号の確認

メタデータ・リポジトリにOracle Databaseインスタンスを使用している場合、データベースのリリース番号は、SQL*Plusを使用して次のように確認できます(どのようなユーザーとしてデータベースに接続していても、これらのコマンドは発行できます)。

SQL> COL PRODUCT FORMAT A40
SQL> COL VERSION FORMAT A15
SQL> COL STATUS FORMAT A15
SQL> SELECT * FROM PRODUCT_COMPONENT_VERSION;

PRODUCT                                    VERSION         STATUS
----------------------------------         --------------  ----------------
NLSRTL                                     11.2.0.4.0      Production
Oracle Database 11g Enterprise Edition     11.2.0.4.0      Production
PL/SQL                                     11.2.0.4.0      Production
TNS for Linux:                             11.2.0.4.0      Production

F.2.5 スキーマのリリース番号の確認

メタデータ・リポジトリにOracle Databaseインスタンスを使用している場合、スキーマのリリース番号は、SQL*Plusを使用して次のように確認できます。

SQL> COL COMP_ID FORMAT A20
SQL> COL COMP_NAME A40
SQL> COL VERSION FORMAT A20
SQL> SELECT COMP_ID, COMP_NAME, VERSION FROM SCHEMA_VERSION_REGISTRY;

COMP_ID             COMP_NAME                               VERSION
------------------------------------------------------------------------------
.
.
.
MDS                 Metadata Services                        12.1.3.0.0
OPSS                Oracle Platform Security Services        12.1.3.0.0
SOAINFRA            SOA Infrastructure Services              12.1.3.0.0
STB                 Service Table                            12.1.3.0.0
.
.
.

G orapki

この付録で、orapkiなど12cよりも前のツールから、12c (12.2.1)で提供されている証明書ツール、ウォレット管理ツールおよびSSL構成ツールへの移行方法について学習していきます。

orapkiユーティリティは、証明書失効リスト(CRL)の管理、Oracleウォレットの作成と管理、およびテスト用の署名付き証明書の作成のためのコマンド行ツールです。また、SSL構成ツールも提供されていました。

Oracle Fusion Middleware 12c (12.2.1)では、SSLを構成するために、コマンド行(orapkiユーティリティ)ユーザー・インタフェースとグラフィカル・ユーザー・インタフェースの両方が提供されています。Oracle WebLogic Scripting Tool (WLST)およびOracle Enterprise Manager Fusion Middleware Controlにより、ユーザーはKSSベースおよびJKSベースのキーストア、ウォレットおよび証明書を管理できます。

この付録の項は次のとおりです。

- 証明書とCRLの管理にorapkiユーティリティを使用する方法

関連項目:

- この付録で説明されているorapkiコマンドの追加の情報と例は、ドキュメントID 1629906.1 Fusion Middleware 12cにおけるORAPKIを使用したウォレットの作成方法(Oracle Technology Networkナレッジ・ベースにあります)を参照してください。

- この付録で説明されているWLSTコマンドの例は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

- Oracle Fusion Middlewareのキーストアとウォレット管理の詳細は、第6章を参照してください。

注意:
orapkiユーティリティは、Oracle共通ホームのバイナリ・ディレクトリ$ORACLE_HOME/oracle_common/binにあります。

G.1 証明書とCRLの管理にorapkiユーティリティを使用する方法

この項の項目は次のとおりです。

- orapkiの概要

- orapkiヘルプの表示

- テスト用の署名付き証明書の作成

- orapkiユーティリティを使用したOracleウォレットの管理

- orapkiユーティリティを使用した証明書失効リスト(CRL)の管理

- orapkiユーティリティ・コマンドのサマリー

G.1.1 orapkiの概要

orapkiユーティリティは、公開鍵インフラストラクチャ(PKI)要素(ウォレット、証明書失効リストなど)をコマンド行で管理できるようにするために提供されています。これにより、実行するタスクをスクリプトに組み込むことができます。これを使用して、PKIを保守するルーチン・タスクの多くを自動化できます。

このコマンド行ユーティリティを使用して、次のタスクを実行できます。

- テスト用の署名付き証明書の作成

- Oracleウォレットの管理

- Oracleウォレットの作成と表示

- 証明書リクエストの追加と削除

- 証明書の追加と削除

- 信頼できる証明書の追加と削除

- 証明書失効リスト(CRL)の管理

- 証明書検証用ハッシュ値によるCRLの名前変更

orapkiを使用すると、証明書をDERフォーマットとPEMフォーマットの両方でインポートできます。

G.1.1.1 orapkiの構文

orapkiコマンド行ユーティリティの基本的な構文を次に示します。

orapki module command -parameter value

このコマンドでは、moduleをwallet (Oracleウォレット)、crl(証明書失効リスト)またはcert (PKIデジタル証明書)にできます。使用可能なコマンドは、使用するmoduleによって異なります。たとえば、walletを使用している場合、addコマンドを使用して証明書またはキーをウォレットに追加できます。次の例では、/private/lhale/cert.txtにあるユーザー証明書が、ORACLE_HOME/wallet/ewallet.p12にあるウォレットに追加されます。

orapki wallet add -wallet ORACLE_HOME/wallet/ewallet.p12
-user_cert -cert /private/lhale/cert.txt

DN構文はプラットフォーム固有です。

多数のorapkiコマンドでは、DNの指定が必要です。UNIXでは、次の例のように、user_dnを一重引用符で囲む必要があります。

$ORACLE_HOME/oracle_common/bin/orapki wallet add
-wallet $ORACLE_HOME/wallet
-dn 'CN=server.in.oracle.com, OU=Support, O=Oracle, L=Jaipur, ST=Rajasthan, C=IN'
-keysize 1024

Windowsでは、次のように二重引用符で囲みます。

$ORACLE_HOME/oracle_common/bin/orapki wallet add
-wallet $ORACLE_HOME/wallet
-dn "CN=server.in.oracle.com, OU=Support, O=Oracle, L=Jaipur, ST=Rajasthan, C=IN"
-keysize 1024

G.1.1.2 orapkiの環境設定

Web層のインストール環境のコンテキストでorapkiを実行している場合は、ORACLE_HOMEを、製品のインストール場所を指すように設定します。

G.1.2 orapkiヘルプの表示

コマンド行で次のコマンドを入力することにより、特定のモードで使用可能なorapkiコマンドをすべて表示できます。

orapki mode help

たとえば、証明書失効リスト(CRL)を管理するために使用可能なコマンドをすべて表示するには、コマンド行に次のように入力します。

orapki crl help

注意:
-summary、-completeまたは-walletコマンド・オプションの使用は、常にオプションです。これらのコマンド・オプションが指定されていなくても、コマンドは実行されます。

G.1.3 テスト用の署名付き証明書の作成

このコマンド行ユーティリティは、テスト用の署名付き証明書を作成する便利で手軽な方法を提供します。次の構文を使用して、署名付き証明書を作成し、証明書を表示できます。

テスト用の署名付き証明書を作成するには:

orapki cert create [-wallet wallet_location] -request
certificate_request_location
-cert certificate_location -validity number_of_days [-summary]

このコマンドにより、証明書リクエストから署名付き証明書が作成されます。-walletパラメータは、証明書リクエストへの署名に使用されるユーザー証明書と秘密鍵を含むウォレットを指定します。-validityパラメータは、現在の日付から数えてこの証明書が有効である日数を指定します。証明書と証明書リクエストの指定は、このコマンドでは必須です。

証明書を表示するには:

orapki cert display -cert certificate_location [-summary | -complete]

このコマンドを使用すると、orapkiを使用して作成したテスト証明書を表示できます。-summaryまたは-completeのいずれかを選択できます。これによりコマンドが表示するデータの詳細さが決まります。-summaryを選択すると、証明書とその有効期限が表示されます。-completeを選択すると、シリアル番号、公開鍵などの追加の証明書情報が表示されます。

G.1.4 orapkiユーティリティを使用したOracleウォレットの管理

次の各項では、orapkiコマンド行ユーティリティを使用してOracleウォレットの作成および管理を行うために使用される構文について説明します。これらのorapkiユーティリティのwalletモジュール・コマンドをスクリプトで使用して、ウォレット作成プロセスを自動化できます。

- orapkiを使用したOracleウォレットの作成と表示

- orapkiを使用した証明書と証明書リクエストのOracleウォレットへの追加

- orapkiを使用した証明書と証明書リクエストのOracleウォレットからのエクスポート

注意:
-walletパラメータは、すべてのwalletモジュール・コマンドで必須です。

関連項目:
パスワードで保護されたウォレットまたは自動ログイン・ウォレットの作成方法の例は、ドキュメントID 1629906.1 Fusion Middleware 12cにおけるORAPKIを使用したウォレットの作成方法(Oracle Technology Networkナレッジ・ベースにあります)を参照してください。

- 信頼フラグの作成と管理

- PKCS#12ファイルのOracleウォレットへのインポート

G.1.4.1 orapkiを使用したOracleウォレットの作成と表示

この項の項目は次のとおりです。

- Oracleウォレットの作成

- 自動ログインが有効なOracleウォレットの作成

- AES暗号化によるOracleウォレットの作成

- AES暗号化を使用するように既存のウォレットを変換

- Oracleウォレットの表示

G.1.4.1.1 Oracleウォレットの作成

orapki wallet create -wallet wallet_location

このコマンドでは、ウォレット・パスワードを入力または再入力するよう求められます。-walletで指定された場所にウォレットが作成されます。

G.1.4.1.2 自動ログインが有効なOracleウォレットの作成

orapki wallet create -wallet wallet_location -auto_login

このコマンドを使用すると、自動ログインが有効なウォレットが作成されます。また、既存のウォレットで自動ログインを有効化する場合にも使用できます。wallet_locationにすでにウォレットが含まれている場合、そのウォレットの自動ログインが有効になります。自動ログイン機能を無効にするには、cwallet.ssoを削除します。

注意:
自動ログイン機能を有効にしたウォレットでは、addなど、ウォレットを変更する操作に対してのみパスワードの入力を求めるプロンプトが表示されます。

G.1.4.1.3 AES暗号化によるOracleウォレットの作成

orapki wallet create -wallet wallet -pwd pwd -compat_v12

このコマンドを使用すると、AES暗号化によりOracleウォレットが作成されます。

G.1.4.1.4 AES暗号化を使用するように既存のウォレットを変換

orapki wallet convert -wallet wallet -compat_v12 -pwd pwd

このコマンドを使用すると、Oracleウォレットの暗号化が3DESからAESに変換されます。

G.1.4.1.5 Oracleウォレットの表示

orapki wallet display -wallet wallet_location

このコマンドを使用すると、ウォレットに含まれている証明書リクエスト、ユーザー証明書および信頼できる証明書が表示されます。

G.1.4.2 orapkiを使用した証明書と証明書リクエストのOracleウォレットへの追加

この項の項目は次のとおりです。

- 証明書リクエストのOracleウォレットへの追加

- 信頼できる証明書のOracleウォレットへの追加

- ルート証明書のOracleウォレットへの追加

- ユーザー証明書のOracleウォレットへの追加

G.1.4.2.1 証明書リクエストのOracleウォレットへの追加

orapki wallet add -wallet wallet_location -dn user_dn -keysize 512|1024|2048|4096

このコマンドを使用すると、指定した識別名(user_dn)を持つユーザーのウォレットに証明書リクエストが追加されます。このリクエストでは、リクエストされた証明書のキー・サイズ(512、1024または2048ビット)も指定します。リクエストに署名するには、エクスポート・オプションを使用してそのリクエストをエクスポートします。第G.1.4.3項「orapkiを使用した証明書と証明書リクエストのOracleウォレットからのエクスポート」を参照してください。

次に例を示します。

Linux/Unix:
$ORACLE_HOME/oracle_common/bin/orapki wallet add
-wallet $ORACLE_HOME/wallet
-dn 'CN=server.in.test.com, OU=Support, O=Oracle, L=Jaipur, ST=Rajasthan, C=IN'
-keysize 1024

Windows:
$ORACLE_HOME/oracle_common/bin/orapki wallet add
-wallet $ORACLE_HOME/wallet
-dn "CN=server.in.test.com, OU=Support, O=Oracle, L=Jaipur, ST=Rajasthan, C=IN"
-keysize 1024

G.1.4.2.2 信頼できる証明書のOracleウォレットへの追加

orapki wallet add -wallet wallet_location -trusted_cert -cert
certificate_location

このコマンドを使用すると、指定した場所(-cert certificate_location)にある信頼できる証明書がウォレットに追加されます。ユーザー証明書を追加する前に、ユーザー証明書の証明書チェーンにあるすべての信頼できる証明書を追加する必要があります。そうしないと、ユーザー証明書を追加するコマンドは失敗します。

G.1.4.2.3 ルート証明書のOracleウォレットへの追加

orapki wallet add -wallet wallet_location -dn
certificate_dn -keysize 512|1024|2048 -self_signed -validity number_of_days

このコマンドを使用すると、新しい自己署名(ルート)証明書が作成され、ウォレットに追加されます。-validityパラメータ(必須)は、現在の日付から数えてこの証明書が有効である日数を指定します。このルート証明書のキー・サイズ(-keysize)は、512、1024、2048または4096ビットに指定できます。

DN構文の例は、第G.1.4.2.1項を参照してください。

G.1.4.2.4 ユーザー証明書のOracleウォレットへの追加

orapki wallet add -wallet wallet_location -user_cert -cert certificate_location

このコマンドを使用すると、-certパラメータで指定された場所にあるユーザー証明書が、wallet_locationにあるOracleウォレットに追加されます。ユーザー証明書をウォレットに追加する前に、証明書チェーンを構成するすべての信頼できる証明書を追加する必要があります。ユーザー証明書を追加する前に、すべての信頼できる証明書がウォレットに追加されていない場合、ユーザー証明書の追加は失敗します。

G.1.4.3 orapkiを使用した証明書と証明書リクエストのOracleウォレットからのエクスポート

この項の項目は次のとおりです。

- 証明書のOracleウォレットからのエクスポート

- 証明書リクエストのOracleウォレットからのエクスポート

G.1.4.3.1 証明書のOracleウォレットからのエクスポート

orapki wallet export -wallet wallet_location -dn
certificate_dn -cert certificate_filename

このコマンドを使用すると、サブジェクトの識別名(-dn)を持つ証明書が、ウォレットから-certで指定されたファイルにエクスポートされます。

DN構文の例は、第G.1.4.2.1項を参照してください。

G.1.4.3.2 証明書リクエストのOracleウォレットからのエクスポート

orapki wallet export -wallet wallet_location -dn
certificate_request_dn -request certificate_request_filename

このコマンドを使用すると、サブジェクトの識別名(-dn)を持つ証明書リクエストが、ウォレットから-requestで指定されたファイルにエクスポートされます。

DN構文の例は、第G.1.4.2.1項を参照してください。

G.1.4.4 信頼フラグの作成と管理

信頼フラグを使用すると、証明書に割り当てられた適切なロールによる、証明書チェーンの検証やパスの構築などの操作が簡単に実行できます。デフォルトでは、ウォレットで信頼フラグはサポートされていません。

orapkiユーティリティを使用して、Oracleウォレットにインストールされている証明書に信頼フラグを保持できます。また、信頼フラグをサポートするウォレットの作成と変換、適切なフラグの作成と各証明書での保持などを実行できます。

表G-1に、サポートされている信頼フラグを示します。

表G-1 Oracleウォレット証明書の信頼フラグ

NZ信頼フラグ値

説明およびベスト・プラクティス

NSSフラグ

SERVER_AUTH (信頼できるサーバーのCA証明書)

信頼できるCAのルート証明書と中間証明書に割り当てられます。CA証明書をクライアントCAロールまたはサーバーCAロールで機能できるようにするためのきめ細かな制御の役に立ちます。

CLIENT_AUTHフラグと共存できます。

サーバーの認証時に、クライアントの証明書ストア内のSERVER_AUTHフラグ付きのCA証明書がサーバー証明書チェーン内にある場合、認証は成功します。SERVER_AUTHフラグ付きのCA証明書が存在しない場合、認証は失敗します。

クライアント・ウォレットで、SERVER_AUTHフラグをサーバーのルートCA証明書を割り当てることをお薦めします。サーバー証明書チェーンの検証は、このSERVER_AUTHフラグ付きの証明書で停止します。サーバーのルートCA証明書をクライアント・ウォレットに追加しない場合は、サーバーの中間CA証明書に設定してください。

"C"

CLIENT_AUTH (信頼できるクライアントのCA証明書)

信頼できるCAのルート証明書と中間証明書に割り当てられます。

SERVER_AUTHフラグと共存できます。CA証明書をクライアントCAロールまたはサーバーCAロールで機能できるようにするためのきめ細かな制御の役に立ちます。

SSLサーバーがクライアント認証をリクエストする場合、サーバーは、証明書の受入れ元である信頼できるCA証明書のサブジェクト名のリストを送信します。このリストの作成には、ウォレット内のCLIENT_AUTHフラグ付きの信頼できる証明書が使用されます。

SSLクライアントの認証時に、サーバーのウォレット内のCLIENT_AUTHフラグ付きのCA証明書がクライアント証明書チェーン内にある場合、認証は成功します。CLIENT_AUTHフラグ付きのCA証明書が存在しない場合、認証は失敗します。

"T"

VALID_PEER

ピアを認証するためにピアのユーザー証明書に割り当てられます。通常は、秘密鍵を持ちません。

CLIENT_AUTH、SERVER_AUTHまたはUSER_CERTフラグと共存できません。

このフラグを自己署名サーバーまたはクライアント証明書に追加することをお薦めします。証明書チェーンの構築および検証は、VALID_PEERフラグ付きの証明書で停止します。

認証時に、認証を求めてSSLピアによって送信されたユーザーの証明書が、リライイング・パーティのVALID_PEERフラグ付きの証明書ストア内に存在する場合、この証明書が有効なピアのユーザー証明書であることを前提として、この証明書は証明書チェーンの検証なしにSSL接続を確立することが許可されます。

"P"

NULL。

フラグが指定されていない証明書に暗黙的に割り当てられます。

中間CA証明書とともに使用することをお薦めします。

""

明示的に実行できるフラグ割当ての他に、ウォレットで信頼フラグが使用できる場合に、証明書で自動的に実行される特定の割当てがあります。

- ルート・ウォレットにおいて(「ユーザー証明書」および「信頼できる証明書」セクションに同じ証明書のコピーを含む)、USER_CERTフラグが「ユーザー証明書」セクションにある証明書のみに追加されます。

- 信頼フラグをサポートできるようにウォレットが変換された場合、特定のルールにより、ウォレットに追加された信頼できる証明書への信頼フラグの割当てが制御されます(下記の「信頼できる証明書への信頼フラグの割当て」を参照)。

- 証明書がウォレットから削除されると、その証明書に関連付けられているフラグがすべて削除されます。同じ証明書を再インストールする場合は、再度フラグを追加する必要があります。

- 信頼フラグを含むウォレットを作成すると(-with_trust_flagsオプションを使用)、ウォレットに特定のデフォルトの証明書が移入されます。これらの証明書にはすべて、SERVER_AUTH/CLIENT_AUTHフラグが割り当てられます。

信頼できる証明書への信頼フラグの割当て

信頼フラグが有効なウォレットに信頼できる証明書を追加すると、信頼フラグは次のように処理されます。

- ルートCAにはSERVER_AUTHフラグが割り当てられます。

- 中間CA (ICA)にはNULLフラグが割り当てられます。

- 秘密鍵のないエンドエンティティ証明書には、VALID_PEERフラグが割り当てられます。

- 秘密鍵のない自己署名証明書には、VALID_PEERフラグが割り当てられます。

次の各項目では、orapkiで実行できる信頼フラグ操作について説明します。

- 信頼フラグをサポートするウォレットの作成

- 信頼フラグをサポートするようにウォレットを変換

- 証明書の信頼フラグの追加と更新

- 信頼フラグを含む証明書のウォレットへの追加

G.1.4.4.1 信頼フラグをサポートするウォレットの作成

ウォレットの作成時には、orapkiのオプションwith_trust_flagsを使用します。

orapki wallet create –wallet wallet_location
–pwd password –with_trust_flags

このコマンドを使用すると、信頼フラグをサポートするOracleウォレットが作成され、一方with_trust_flagsパラメータを指定せずに作成されたウォレットでは信頼フラグがサポートされませんが、サポートするように変換することはできます。

自動ログイン・ウォレットの作成などのその他のオプションも、信頼フラグをサポートするウォレットの作成時に指定できます。

信頼フラグ対応ウォレットに追加された信頼できる証明書への信頼フラグの割当てを制御するルールは、第G.1.4.4項「信頼フラグの作成と管理」(「信頼できる証明書への信頼フラグの割当て」を参照)で説明されており、これらのフラグは明示的にクリアできます。

G.1.4.4.2 信頼フラグをサポートするようにウォレットを変換

信頼フラグをサポートするように既存のウォレットを更新できます。

このコマンド構文を使用すると、信頼フラグをサポートするようにウォレットが変換されます。

orapki wallet enable_trust_flags –wallet wallet_location –pwd password

または、自動ログイン・ウォレットの場合:

orapki wallet enable_trust_flags –wallet wallet_location –auto_login_only

使用ルールは次のとおりです。

- これは自動ログイン・ウォレットであるため、パスワードは必要ありません。

- このコマンドを使用すると、ウォレットを元の状態(つまり、信頼フラグをサポートしない状態)には戻せません。

- ウォレット内に存在するユーザー証明書にはすべてUSER_CERTフラグが割り当てられます。

信頼できる証明書の信頼フラグは、次のように処理されます。

- ルートCAにはSERVER_AUTHフラグが割り当てられます。

- ICA (中間CA)にはNULLフラグが割り当てられます。

- 秘密鍵のないエンドエンティティ証明書には、VALID_PEERフラグが割り当てられます。

信頼できる証明書に関連付けられているフラグを変更して、任意の信頼フラグを割り当てることができます。

証明書の空のウォレットへの追加

前述したように、このコマンドを使用すると、ウォレットを元の状態(つまり、信頼フラグをサポートしない状態)には戻せません。

orapkiによってインストールされたデフォルトの証明書を含む、すべての証明書をウォレットから削除すると、ツールはウォレットが信頼フラグをサポートしているかどうかを判別することができなくなります。このため、お薦めする方法は、デフォルトでインストールされている証明書をウォレットから削除しないことであり、これらを削除する必要がある場合は、削除する前に必ず証明書をインストールして、ウォレット内に最低1つの証明書が残されている状態にしてください。

すべての証明書をウォレットから削除して、後で新しい証明書をインストールする場合、信頼フラグ・オプションを指定して新しい証明書をインストールすると、ウォレットは自動的に信頼フラグをサポートするようになります。信頼フラグ・オプションを指定せずに新しい証明書をインストールした場合、ウォレットは信頼フラグをサポートしません。

G.1.4.4.3 証明書の信頼フラグの追加と更新

orapkiのオプションtrust_flagsを使用すると、選択した証明書に必要なフラグが割り当てられます。

orapki wallet assign_trust_flags –wallet wallet_location
–pwd password –trust_flags ""|"flags"
–dn "value" [–serial_num "value"  –issuer "value"]

このコマンドを使用すると、dnによって指定された証明書の信頼フラグが追加、更新または削除されます。構文ルールは次のとおりです。

- ウォレットは信頼フラグをサポートしている必要があります。

- ウォレットは自動ログイン・ウォレットであるため、パスワードは必要ありません。

- 表G-1で定義されたフラグを指定します。

- 必須の証明書属性パラメータはサブジェクトDNのみであり、残りの2つのパラメータはオプションです。ただし、証明書を一意に識別するために、これらのパラメータを使用して詳細を十分に指定する必要があります。

- 照合する属性名では大文字と小文字は区別されませんが、属性値では区別されます。

- シリアル番号は、数値にする必要があります。

- 証明書に既存のフラグが割り当てられている場合は上書きされます。

- "," (カンマ)を使用して複数のフラグを割り当てることができます(例: –add "SERVER_AUTH,CLIENT_AUTH")。

- USER_CERTフラグは、ユーザー証明書に対して暗黙的に割り当てられているため、このコマンドでは指定できません(ユーザー証明書には必ずUSER_CERTフラグが存在します)。

- 信頼フラグを削除するには、–add ""を使用します。この場合、証明書にはNULLフラグが割り当てられます。

- 変更またはクリア・アクションにより、いずれかのユーザー証明書の証明書チェーンが無効になってしまう場合、このアクションは実行されません。

次に例を示します。

orapki wallet assign_trust_flags –wallet /usr/test
–trust_flags "SERVER_AUTH,CLIENT_AUTH"
–dn "cn=jack, ou=people, dc=example, dc=com"
–serial_num "1122" –issuer "sample"

G.1.4.4.4 信頼フラグを含む証明書のウォレットへの追加

ウォレットへの証明書の追加時には、orapkiのオプションtrust_flagsを使用します。

orapki wallet add –wallet wallet_location
–[trusted_cert|user_cert|self_signed]
–cert cert_location –pwd password –trust_flags "flag(s)"

このコマンドを使用すると、指定した信頼フラグを含む証明書がOracleウォレットに追加されます。構文ルールは次のとおりです。

- ウォレットは信頼フラグをサポートしている必要があります。

- ウォレットが自動ログイン・ウォレットである場合、パスワードは必要ありません。

- 自己署名付き証明書を生成する場合、cert_locationは必要ありません。

- 証明書のタイプがuser_certである場合、暗黙的にUSER_CERTフラグが追加されます。(ルート・ウォレットでは、「信頼できる証明書」セクションに自己署名付き証明書も存在していますが、この証明書にはUSER_CERTフラグは割り当てられません。)

- 表G-1で定義されたフラグを指定します。

- 信頼フラグが有効である場合、信頼できる証明書の完全な階層が存在している必要はありません(信頼フラグが指定されていないウォレットの場合とは異なり、ユーザー証明書の追加時に全チェーンが存在している必要があります)。階層内の信頼できる証明書のいずれかにSERVER_AUTH/CLIENT_AUTHフラグが割り当てられると、証明書チェーンの構築が停止します。

G.1.4.5 PKCS#12ファイルのOracleウォレットへのインポート

orapkiのオプションpkcs12fileを使用すると、PKCS#12ファイルをwall.etにインポートできます

orapki wallet import_pkcs12
–wallet wallet_location [-pwd wallet_password]
-pkcs12file pkcs12_file_location [-pkcs12pwd pkcs12_file_password]

このコマンドを使用すると、PKCS#12ファイルがOracleウォレットにインポートされます。コマンドでパスワードを指定しない場合、ユーティリティによってプロンプトが表示されます。

G.1.5 orapkiユーティリティを使用した証明書失効リスト(CRL)の管理

CRLは、orapkiを使用して管理する必要があります。このユーティリティは、CRL発行者名のハッシュ値を作成して、システム内でCRLの場所を特定します。orapkiを使用しないと、Oracleサーバーは、CRLを探してPKIデジタル証明書を検証することができません。次の各項では、CRLについて、CRLの使用方法、およびorapkiを使用してCRLを管理する方法について説明します。

- 第G.1.5.1項「証明書失効リストを使用した証明書の検証について」

- 第G.1.5.2項「証明書失効リストの管理」

関連項目:
orapkiでのCRLの管理の詳細は、Oracle Advanced Security管理者ガイドの証明書失効リストの管理に関する項を参照してください。
http://docs.oracle.com/cd/E11882_01/network.112/e10746/asossl.htm

G.1.5.1 証明書失効リストを使用した証明書の検証について

指定の証明書を指定のコンテキストで使用できるかどうかを判定するプロセスは、証明書の検証と呼ばれます。証明書の検証には、次の項目の判定が含まれます。

- 信頼できる認証局(CA)にデジタル署名された証明書があるかどうか。

- 証明書のデジタル署名が、証明書自体の別個に計算されたハッシュ値および証明書の署名者の(CAの)公開鍵に対応しているかどうか。

- 証明書が期限切れになっていないかどうか。

- 証明書が失効していないかどうか。

SSLネットワーク・レイヤーは、自動的に最初の3つの検証チェックを実行しますが、証明書が失効していないことを確認するには、証明書失効リスト(CRL)のチェックを構成する必要があります。CRLは、失効した証明書のリストを含む署名付きデータ構造体です。これは通常、元の証明書を発行したエンティティと同じエンティティによって発行され署名されます。

G.1.5.1.1 使用するCRL

使用するトラスト・ポイントすべてについてCRLが必要です。トラスト・ポイントは、一定の信頼レベルで資格を与えられたサード・パーティ・アイデンティティからの信頼できる証明書です。通常、信頼する認証局はトラスト・ポイントと呼ばれます。

G.1.5.1.2 CRLチェックのしくみ

証明書失効ステータスは、ファイル・システム・ディレクトリにあるCRL、または証明書のCRL配布ポイント(CRL DP)の拡張子で指定された場所からダウンロードしたCRLに対してチェックされます。CRLをローカル・ファイル・システムまたはディレクトリに格納する場合、CRLを定期的に更新する必要があります。CRL DPを使用する場合、CRLは、対応する証明書が最初に使用されるときにダウンロードされます。

サーバーは、次の場所で(ここに示されている順番で)CRLを検索します。システムは、証明書のCAのDNと一致するCRLを検出すると、検索を停止します。

1. ローカル・ファイル・システム
CRLファイルの場所と管理はコンポーネントに応じて異なります。Oracle WebLogic Serverの場合は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のCRLローカル・キャッシュの構成に関する項を参照してください。Oracle HTTP Serverの場合は、ドキュメントID 1665286.1 FMW 12cにおけるOracle HTTP ServerでのCRLチェックの構成方法(Oracle Technology Networkナレッジ・ベースにあります)を参照してください。

2. CRL DP
CAが、証明書が発行されたときのCRL DP X.509、バージョン3、証明書拡張子内の位置を指定すると、その証明書用の失効情報を含む適切なCRLがダウンロードされます。現在、Oracle Advanced Securityは、HTTPおよびLDAPを介したCRLのダウンロードをサポートしています。

注意:

- パフォーマンス上の理由から、ユーザー証明書のみがチェックされます。

- CRLをローカル・ファイル・システムではなくディレクトリに格納することをお薦めします。

G.1.5.2 証明書失効リストの管理

CRL管理の手順は、対象となるコンポーネントに応じて異なります。Oracle WebLogic Serverの場合は、『Oracle WebLogic Serverセキュリティの管理12c (12.2.1)』のCRLローカル・キャッシュの構成に関する項を参照してください。Oracle HTTP Serverの場合は、ドキュメントID 1665286.1 FMW 12cにおけるOracle HTTP ServerでのCRLチェックの構成方法(Oracle Technology Networkナレッジ・ベースにあります)を参照してください。

証明書失効ステータスのチェックを有効にするには、まず、使用するCAから受信したCRLがシステムで使用できるフォームである(ハッシュ値で名前変更されている)こと、またはシステムで使用できる場所にある(ディレクトリにアップロードされている)ことを確認してください。Oracle Advanced Securityには、次のタスクを実行するために使用できるコマンド行ユーティリティ、orapkiがあります。

- 証明書検証用ハッシュ値によるCRLの名前変更

注意:
CRLは、正常な検証を行うために、(期限切れになる前に)定期的に更新する必要があります。このタスクは、スクリプトでorapkiコマンドを使用して自動化できます。

関連項目:
LDAPコマンド行ツールおよびその構文については、Oracle Fusion Middleware Oracle Identity Managementリファレンスのコマンド行ツールの概要に関する項を参照してください。

G.1.5.2.1 証明書検証用ハッシュ値によるCRLの名前変更

システムは、証明書を検証するとき、証明書を作成したCAが発行するCRLを見つける必要があります。システムは、証明書の発行者名とCRLにある発行者名を照合して適切なCRLを検出します。

Oracle Net Managerの「証明書失効リスト・パス」フィールドにCRL格納場所を指定する(sqlnet.oraファイルのSSL_CRL_PATHパラメータを設定する)場合、orapkiユーティリティを使用して発行者名を表すハッシュ値を使用してCRLを名前変更します。ハッシュ値を作成すると、サーバーでCRLをロードできます。

UNIXシステムでは、orapkiによってCRLへのシンボリック・リンクが作成されます。Windowsシステムでは、CRLファイルのコピーが作成されます。どちらの場合も、orapkiによって作成されたシンボリック・リンクまたはコピーは、発行者名のハッシュ値を使用して名前が付けられます。その後、システムが証明書を検証するとき、同じハッシュ関数が使用されて、適切なCRLをロードできるようにリンク(またはコピー)の名前が計算されます。

ご使用のオペレーティング・システムに応じて、次のコマンドのいずれかを入力して、ファイル・システムに格納されているCRLの名前を変更します。

UNIXファイル・システムに格納されているCRLの名前を変更するには:

orapki crl hash -crl crl_filename [-wallet wallet_location]
-symlink crl_directory [-summary]

Windowsファイル・システムに格納されているCRLの名前を変更するには:

orapki crl hash -crl crl_filename
[-wallet wallet_location] -copy crl_directory [-summary]

このコマンドで、crl_filenameはCRLファイルの名前、wallet_locationはCRLを発行したCAの証明書を含むウォレットの場所、crl_directoryはCRLがあるディレクトリです。

-walletおよび-summaryの使用はオプションです。-walletを指定すると、CRLの名前を変更する前に、ツールによってCAの証明書に対するCRLの有効性が確認されます。-summaryオプションを指定すると、ツールによってCRL発行者名が表示されます。

G.1.6 orapkiユーティリティ・コマンドのサマリー

この項では、次のorapkiコマンドについて説明します。

- orapki cert create

- orapki cert display

- orapki crl create

- orapki crl hash

- orapki crl revoke

- orapki crl status

- orapki crl verify

- orapki wallet add

- orapki wallet change_pwd

- orapki wallet create

- orapki wallet enable_trust_flags

- orapki wallet assign_trust_flags

- orapki wallet display

- orapki wallet export

- orapki wallet export_trust_chain

- orapki wallet import_pkcs12

G.1.6.1 orapki cert create

次の各項では、このコマンドについて説明します。

G.1.6.1.1 用途

このコマンドは、テスト用の署名付き証明書を作成するために使用します。

G.1.6.1.2 構文

orapki cert create [-wallet wallet_location]
-request certificate_request_location
-cert certificate_location -validity number_of_days [-summary]

- -walletパラメータは、証明書リクエストへの署名に使用されるユーザー証明書と秘密鍵を含むウォレットを指定します。

- -requestパラメータ(必須)は、作成する証明書の証明書リクエストの場所を指定します。

- -certパラメータ(必須)は、ツールが新しい署名付き証明書を配置するディレクトリの場所を指定します。

- -validityパラメータ(必須)は、現在の日付から数えてこの証明書が有効である日数を指定します。

G.1.6.2 orapki cert display

次の各項では、このコマンドについて説明します。

G.1.6.2.1 用途

このコマンドは、特定の証明書の詳細を表示するために使用します。

G.1.6.3 orapki crl create

次の各項では、このコマンドについて説明します。

G.1.6.3.1 用途

このコマンドは、CRLを作成するために使用します。

G.1.6.3.2 構文

orapki crl create [-crl [url|filename]]
[-wallet [cawallet]]
[-nextupdate [days]]
[-pwd pwd]

- -crlは、CRLが作成される場所です(たとえば、./nzcrl.txt)。

- -walletは、自己署名証明書と対応する秘密鍵を含むCAウォレットです。

- -nextupdateは、次回更新までの日数です。

- -pwdは、CAウォレットのパスワードです。

G.1.6.4 orapki crl hash

次の各項では、このコマンドについて説明します。

G.1.6.4.1 用途

このコマンドは、証明書失効リスト(CRL)発行者のハッシュ値を生成して、証明書検証用にファイル・システム内のCRLの場所を特定するために使用します。

G.1.6.4.2 構文

orapki crl hash -crl crl_filename|URL
[-wallet wallet_location] [-symlink|-copy] crl_directory [-summary]

- -crlパラメータは、CRLまたはCRLがあるURLを含むファイル名を指定します。

- -walletパラメータ(オプション)は、CRLを発行した認証局(CA)の証明書を含むウォレットの場所を指定します。これを使用すると、CRLをディレクトリにアップロードする前に、ツールによってCAの証明書に対するCRLの有効性が確認されます。

- オペレーティング・システムに応じて、-symlinkパラメータまたは-copyパラメータのいずれかを使用します。

- UNIX: -symlinkを使用してcrl_directoryにCRLへのシンボリック・リンクを作成します。

- Windows: -copyを使用してcrl_directoryにCRLのコピーを作成します。

- -summaryパラメータ(オプション)を使用すると、ツールによってCRL発行者名が表示されます。

G.1.6.5 orapki crl revoke

次の各項では、このコマンドについて説明します。

G.1.6.5.1 用途

このコマンドは、証明書を取り消すために使用します。

G.1.6.5.2 構文

orapki crl revoke [-crl [url|filename]]
[-wallet [cawallet]]
[-cert [revokecert]]
[-pwd pwd]

説明:

- -crlは、URLまたはファイル名としてCRLを指定します。

- -walletは、自己署名証明書と対応する秘密鍵を含むCAウォレットです。

- -cert : 取り消す証明書

- -pwdは、CAウォレットのパスワードです。

G.1.6.6 orapki crl status

次の各項では、このコマンドについて説明します。

G.1.6.6.1 用途

このコマンドは、証明書がCRLで失効しているかどうかをチェックするために使用します。

G.1.6.6.2 構文

orapki crl status [-crl [url|filename]]
[-cert [cert]]

- -crlは、URLまたはファイル名としてCRLを指定します。

- -certはCAの証明書です。

G.1.6.7 orapki crl verify

次の各項では、このコマンドについて説明します。

G.1.6.7.1 用途

このコマンドは、CRL署名を確認するために使用します。

G.1.6.7.2 構文

orapki crl verify [-crl [url|filename]]
[-cert [cacert]]

説明:

- -crlは、URLまたはファイル名としてCRLを指定します。

- -certは、チェックする証明書を指定します。

G.1.6.8 orapki wallet add

次の各項では、このコマンドについて説明します。

G.1.6.8.1 用途

このコマンドは、証明書リクエストおよび証明書をOracleウォレットに追加するために使用します。

G.1.6.8.2 構文

関連項目:
DN構文の例は、第G.1.4.2.1項を参照してください。

証明書リクエストを追加するには:

orapki wallet add -wallet wallet_location -dn user_dn -keysize 512|1024|2048

- -walletパラメータは、証明書リクエストの追加先のウォレットの場所を指定します。

- -dnパラメータは、証明書の所有者の識別名を指定します。

- -keysizeパラメータは、証明書のキー・サイズを指定します。

- リクエストに署名するには、エクスポート・オプションを使用してそのリクエストをエクスポートします。第G.1.6.14項「orapki wallet export」を参照してください。

信頼できる証明書を追加するには:

orapki wallet add -wallet wallet_location -trusted_cert -cert certificate_location

- -trusted_certパラメータを使用すると、ツールによって、-certで指定された場所にある信頼できる証明書がウォレットに追加されます。

ルート証明書を追加するには:

orapki wallet add -wallet wallet_location -dn
certificate_dn -keysize 512|1024|2048 -self_signed
-valid_from [mm/dd/yyyy] -valid_until [mm/dd/yyyy]
-validity number_of_days

- -self_signedパラメータを使用すると、ツールによってルート証明書が作成されます。

- -validityパラメータを使用して、現在の日付から数えてこのルート証明書が有効である日数を指定できます。

- -valid_fromパラメータおよびvalid_untilパラメータを使用して、このルート証明書が有効である正確な日付範囲を指定できます。-validity number_of_daysのかわりに、この方法で有効期間を指定できます。

ユーザー証明書を追加するには:

orapki wallet add -wallet wallet_location -user_cert -cert certificate_location

- -user_certパラメータを使用すると、ツールによって、-certパラメータで指定された場所にあるユーザー証明書がウォレットに追加されます。ユーザー証明書をウォレットに追加する前に、証明書チェーンを構成するすべての信頼できる証明書を追加する必要があります。ユーザー証明書を追加する前に、すべての信頼できる証明書がウォレットに追加されていない場合、ユーザー証明書の追加は失敗します。

証明書リクエストにサブジェクト・キー識別子の拡張子を追加するには:

orapki wallet add -wallet wallet_location -dn user_dn -keysize 512|1024|2048 -addext_ski

バージョン3の自己署名証明書をウォレットに追加するには:

orapki wallet add -wallet wallet_location -dn certificate_dn -keysize 512|1024|2048 -self_signed -validity number_of_days -addext_ski

証明書のウォレットへの追加時に信頼フラグを追加するには:

orapki wallet add –wallet wallet_location
–[trusted_cert|user_cert|self_signed]
–cert cert_location –pwd password –trust_flags "flag(s)"

- -trust_flagsパラメータにより、指定したフラグが証明書に追加されます。使用方法の詳細は、第G.1.4.4.4項を参照してください。

DN構文の例は、第G.1.4.2.1項を参照してください。

G.1.6.9 orapki wallet change_pwd

次の各項では、このコマンドについて説明します。

G.1.6.9.1 用途

このコマンドは、Oracleウォレットのパスワードを変更するために使用します。

G.1.6.9.2 構文

orapki wallet change_pwd [-wallet [wallet_location]] [-oldpwd oldpassword] [-newpwd newpassword]

- -walletパラメータは、パスワードを変更するウォレットの場所を指定します。

- -oldpwdパラメータは、既存のウォレット・パスワードを指定します。

- -newpwdパラメータは、新しいウォレット・パスワードを指定します。

G.1.6.10 orapki wallet create

次の各項では、このコマンドについて説明します。

G.1.6.10.1 用途

このコマンドは、Oracleウォレットの作成、Oracleウォレットの自動ログインの設定、および証明書の信頼フラグの有効化のために使用します。

G.1.6.10.2 構文

orapki wallet create -wallet wallet_location
[–with_trust_flags] [-auto_login]

- -walletパラメータは、新しいウォレットの場所または自動ログインを有効にするウォレットの場所を指定します。

- -auto_loginパラメータにより、自動ログイン・ウォレットが作成されます。または、-walletオプションで指定されたウォレットの自動ログインが有効になります。

- –with_trust_flagsパラメータにより、ウォレットが信頼フラグをサポートできるようになります。

G.1.6.11 orapki wallet enable_trust_flags

次の各項では、このコマンドについて説明します。

G.1.6.11.1 用途

このコマンドは、信頼フラグをサポートするようにウォレットを変換するために使用します。

G.1.6.11.2 構文

orapki wallet enable_trust_flags –wallet wallet_location –pwd password

G.1.6.12 orapki wallet assign_trust_flags

次の各項では、このコマンドについて説明します。

G.1.6.12.1 用途

このコマンドは、ウォレット内の証明書に信頼フラグを割り当てるために使用します。

G.1.6.12.2 構文

orapki wallet assign_trust_flags –wallet wallet_location
–pwd password –trust_flags ""|"flags"
–dn "value" [–serial_num "value"  –issuer "value"]

- -dnパラメータは必須です。

- ウォレット内の単一の証明書に一意的に一致させるために、-serial_numおよび-issuerパラメータが必要になる場合があります。

追加の使用方法の詳細は、第G.1.4.4.3項を参照してください。

DN構文の例は、第G.1.4.2.1項を参照してください。

G.1.6.13 orapki wallet display

次の各項では、このコマンドについて説明します。

G.1.6.13.1 用途

このコマンドは、Oracleウォレット内の証明書リクエスト、ユーザー証明書および信頼できる証明書を表示するために使用します。

G.1.6.13.2 構文

orapki wallet display -wallet wallet_location

- -walletパラメータは、開くウォレットの場所を指定します(そのウォレットが現在の作業ディレクトリにない場合)。

G.1.6.14 orapki wallet export

次の各項では、このコマンドについて説明します。

関連項目:
dnパラメータの指定例は、第G.1.4.2.1項を参照してください。

G.1.6.14.1 用途

このコマンドは、証明書リクエストおよび証明書をOracleウォレットからエクスポートするために使用します。

G.1.6.14.2 構文

orapki wallet export -wallet wallet_location
-dn certificate_dn -cert certificate_filename

- -walletパラメータは、証明書のエクスポート元のウォレットがあるディレクトリを指定します。

- -dnパラメータは、証明書の識別名を指定します。

- -certパラメータは、エクスポートされる証明書を含むファイルのパスおよびファイル名を指定します。

証明書リクエストをOracleウォレットからエクスポートするには:

orapki wallet export -wallet wallet_location
-dn certificate_request_dn -request certificate_request_filename

- -requestパラメータは、エクスポートされる証明書リクエストを含むファイルのパスおよびファイル名を指定します。

G.1.6.15 orapki wallet export_trust_chain

次の各項では、このコマンドについて説明します。

G.1.6.15.1 用途

このコマンドは、ユーザーのトラストのチェーン(証明書チェーン)をエクスポートするために使用します。

G.1.6.15.2 構文

orapki wallet export_trust_chain [-wallet [wallet]]
[-certchain [filename]]
[-dn [user_cert_dn] ]
[-pwd pwd]

- -walletパラメータは、証明書チェーンのエクスポート元のウォレットの場所を指定します。

- -certchainパラメータは、エクスポートされる証明書チェーンを含むファイルの名前を指定します。

- -dnパラメータは、エクスポートされるエントリの識別名を指定します。

- -pwdは、ウォレット・パスワードを指定します。

-dnパラメータの指定方法の例は、第G.1.4.2.1項を参照してください。

G.1.6.16 orapki wallet import_pkcs12

次の各項では、このコマンドについて説明します。

G.1.6.16.1 用途

このコマンドは、PKCS#12ファイルをOracleウォレットにインポートするために使用します。

G.1.6.16.2 構文

orapki wallet import_pkcs12
–wallet wallet_location [-pwd wallet_password]
-pkcs12file pkcs12_file_location [-pkcs12pwd pkcs12_file_password]

- walletパラメータは、PKCS#12ファイルのインポート先のOracleウォレットの相対または絶対パスを指定します。このパラメータは必須です。

- pwdパラメータは、PKCS#12ファイルのインポート先のOracleウォレットのパスワードを指定します。このパラメータはオプションであり、必要に応じてプロンプトが表示されます。

- pkcs12fileパラメータは、OracleウォレットにインポートされるPKCS#12ファイルの相対または絶対パスを指定します。このパラメータは必須です。

- pkcs12pwdパラメータは、OracleウォレットにインポートされるPKCS#12ファイルのパスワードを指定します。このパラメータはオプションであり、必要に応じてプロンプトが表示されます。

次に例を示します。

orapki wallet import_pkcs12 –wallet /scratch/user/oracleWalletFolder/ewallet.p12 -pwd walletPassword -pkcs12file /scratch/userId/pkcs12fileFolder/certandkey.p12 -pkcs12pwd pkcs12filePassword

H Oracle Fusion Middlewareのトラブルシューティング

この付録では、Oracle Fusion Middlewareを使用しているときに発生する可能性のある障害のトラブルシューティング方法について説明します。内容は次のとおりです。

- Oracle Fusion Middlewareの障害の診断

- 一般的な障害と解決策

- SSLのトラブルシューティング

- FIPS構成のトラブルシューティング

- 他のヘルプが必要な場合

H.1 Oracle Fusion Middlewareの障害の診断

Oracle Fusion Middlewareコンポーネントは、起動および停止情報、エラー、警告メッセージ、HTTPリクエスト時のアクセス情報など、すべての種類のイベントを記録するメッセージが格納されたログ・ファイルを生成します。このログ・ファイルを、障害の特定と診断に使用できます。ログ・ファイルの使用と読取りの詳細は、第12章「ログ・ファイルと診断データの管理」を参照してください。

Oracle Fusion Middlewareには、問題の検出、診断および解決を支援する診断フレームワークが含まれています。特に対象としている障害は、コードのbug、メタデータの破損、顧客データの破損に起因する障害、スレッドのデッドロック、一貫性のない状態などのクリティカル・エラーです。

クリティカル・エラーが発生すると、そのエラーにはインシデント番号が割り当てられ、エラーの診断ログ(ログ・ファイルなど)が即座に取得され、その番号でタグ付けされます。データは、自動診断リポジトリ(ADR)に格納されます。ADRでは、後でデータをインシデント番号によって取得し、分析することができます。診断フレームワークの詳細は、第13章「問題の診断」を参照してください。

H.2 一般的な障害と解決策

この項では、一般的な障害と解決策について説明します。次の項目が含まれます。

- データ・ソース接続の不足

- 異なるバージョンのSpringの使用

- 管理対象サーバー起動時のClassNotFoundエラー

H.2.1 データ・ソース接続の不足

データベースのパフォーマンスが低下している場合や、Oracle WebLogic Serverのログ・ファイルに次のメッセージが出力された場合は、データ・ソース接続がリークしている可能性があります。

No resources currently available in pool datasource name

Any product functionality that depend on the datasource will not function as it can't connect database to get required data.

このメッセージが出力された場合は、管理コンソールのデータ・ソース・モニタリング・ページから接続使用量をモニターします。

1. 「ドメイン構造」で、「サービス」→「データ・ソース」を選択します。

2. モニターするデータ・ソースをクリックします。

3. 「モニタリング」タブ→「統計」タブを選択します。

4. 表に「現在アクティブな接続の数」が表示されない場合は、「この表のカスタマイズ」をクリックします。

5. 「列の表示」で、「現在アクティブな接続の数」を選択して、それを「使用可能」ボックスから「選択済み」ボックスに移動します。「適用」をクリックします。

6. 表内の「現在アクティブな接続の数」列の数に注目します。

現在アクティブなデータ・ソースの数が増え続け、減少しないようであれば、このデータ・ソースで接続がリークしています。Oracleサポートに連絡してください。

H.2.2 異なるバージョンのSpringの使用

JRFを使用して管理対象サーバーを構成すると、Spring 2.0.6がインストールされ、Oracle WebLogic Serverのシステム・クラスパスに配置されます。JRF環境で実行されているカスタム・アプリケーションが、異なるバージョンのSpringを必要とする場合、FilteringClassLoaderメカニズムを使用して、Springのバージョンを指定する必要があります。

Oracle WebLogic Serverは、デプロイメント記述を構成して特定のパッケージが常に(システム・クラス・ローダーによってではなく)アプリケーションからロードされることを明示的に指定できるように、FilteringClassLoaderメカニズムを提供します。この機能により、SpringやAntなど、アプリケーションの代替のバージョンを使用できます。

FilteringClassLoaderメカニズムの使用方法の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のFilteringClassLoaderの使用方法に関する項を参照してください。

H.2.3 管理対象サーバー起動時のClassNotFoundエラー

管理対象サーバーがノード・マネージャによって起動される場合(サーバーがOracle WebLogic Server管理コンソールまたはFusion Middleware Controlによって起動される場合)、管理対象サーバーを起動するときに起動スクリプトを使用するようにノード・マネージャが構成されていないと、ClassNotFoundエラーが発生する場合があります。この障害の解決方法の詳細は、第2.7.1項を参照してください。

H.3 SSLのトラブルシューティング

この項では、SSL構成を使用する場合の一般的な問題および解決策について説明します。次の項目が含まれます。

- コンポーネントですべてのサポートされている暗号が有効になる場合がある

- 特定のブラウザで必要なSSL証明書チェーン

- JDK7の証明書ではkeyUsage拡張機能が必要

H.3.1 コンポーネントですべてのサポートされている暗号が有効になる場合がある

暗号が明示的に構成されていない場合、12c (12.2.1)の一部のコンポーネントでDH_Anon (Diffie-Hellman匿名)暗号を含む、サポートされているすべてのSSL暗号が有効になることに注意してください。

この時点では、次のように暗号を設定することがわかっているコンポーネントはOracle HTTP Serverのみです。

DH_Anonが希望でない場合、希望する暗号でコンポーネントを構成します。

H.3.2 特定のブラウザで必要なSSL証明書チェーン

Oracle HTTP Server用にSSLを構成する場合、証明書チェーン全体(ルートCA、中間CAなど)のインポートが必要な場合があります。

Internet Explorerなどの特定のブラウザでは、SSLハンドシェイクが機能するように証明書チェーン全体をブラウザにインポートする必要があります。証明書が中間CAによって発行されている場合、証明書チェーン全体がブラウザで利用できることを確認する必要があり、そうしないとハンドシェイクが失敗します。チェーンの中間証明書の期限が切れている場合、チェーンのすべての証明書(OHS Serverの証明書など)とともに更新する必要があります。

H.3.3 JDK7の証明書ではkeyUsage拡張機能が必要

JDK6では、keyCertSignビットを有効化しなくても、自己署名付き証明書にkeyUsage拡張機能を含めることができます。これは、JDK7では拒否されます。

JDK7では、自己署名付きCA証明書を使用する場合は、keyUsage拡張機能のkeyCertSignビットを設定する必要があります。そうしないと、接続が次のような例外により失敗します。

weblogic.common.resourcepool.ResourceDeadException:
0:weblogic.common.ResourceException: Could not create pool connection. The
DBMS driver exception was: IO Error:
sun.security.validator.ValidatorException: PKIX path validation failed:
java.security.cert.CertPathValidatorException: Path does not chain with any
of the trust anchors

鍵使用目的の拡張機能は、証明書に設定されている鍵の使用目的(暗号用、署名用、証明書署名用など)を定義します。

準拠しているCAでは、公開鍵(その他の公開鍵証明書またはCRLでのデジタル署名の検証に使用される)が設定されている証明書にこの拡張機能を含める必要があります。

公開鍵証明書の署名の検証にサブジェクトの公開鍵が使用される場合は、keyCertSignビットがアサートされます。つまり、JDK7で自己署名付きCA証明書を生成するときには、keyUsageのkeyCertSignビットがオンであることを確認する必要があります。

これは、たとえば次のような方法で達成できます。

1. ku:c=keyCertSignオプションを指定して自己署名付きJKSキーストアを作成し、

2. キーストアからの証明書をルート・ウォレット(SSL DB接続で使用される)に移行します

orapki wallet jks_to_pkcs12 -wallet ./ -pwd password -keystore ./ewallet.jks-jkspwd password

H.4 FIPS構成のトラブルシューティング

この項目の詳細は、第8.5項を参照してください。

H.5 追加情報

この他の解決策は、My Oracle Support (http://support.oracle.com)で公開されています。発生した障害の解決策が見つからない場合は、サービス・リクエストを発行してください。

第H.5.1項で説明するように、Remote Diagnostic Agentを使用することもできます。

H.5.1 Remote Diagnostic Agentの使用

Remote Diagnostic Agent (RDA)は、ご使用の環境の全体像を提供するコマンド行診断ツールです。また、RDAでは、構成やセキュリティなど、様々な項目に関する推奨事項が提供されています。これは、ユーザーとOracleサポートの問題解決を支援します。

RDAは、できるだけ控えめであるように設計されており、システムを変更することはありません。必要に応じて、セキュリティ・フィルタが提供されます。

RDAの詳細は、次の場所にあるreadmeファイルを参照してください。

(UNIX) ORACLE_HOME/oracle_common/rda/README_Unix.txt
(Windows) ORACLE_HOME\oracle_common\rda\README_Windows.txt

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。