Oracle® Enterprise Manager

ライフサイクル管理ガイド

12cリリース5 (12.1.0.5)

B66837-13(原本部品番号:E27046-33)

2015年6月

Oracle Enterprise Managerライフサイクル管理ガイド, 12cリリース5 (12.1.0.5)

B66837-13

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

原本著者: Namrata Bhakthavatsalam

原本協力者: Aravind Jayaraaman、Genevieve D'Souza、Pushpa Raghavachar、Pradeep Gopal、Jacqueline Gosselin、Jim Garrison、Leo Cloutier

協力者: Enterprise Manager Cloud Controlライフサイクル管理の開発チーム、品質保証チーム、カスタマ・サポート・チームおよび製品管理チーム。

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

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

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

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およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

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

はじめに

- 対象読者

- 対象範囲

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

- 関連ドキュメント

- 表記規則

本ガイドの改訂内容

- 最新の改訂版に追加された変更内容(公開済)

- 以前の改訂版に追加された変更内容(アーカイブ)

第I部 概要と設定の詳細

1 ライフサイクル管理の概要

- 1.1 新しいライフサイクル管理ソリューションの概要

- 1.2 ライフサイクル管理ソリューションの情報マップ

2 インフラストラクチャの設定

- 2.1 インフラストラクチャの設定の開始

- 2.2 Oracleソフトウェア・ライブラリの設定

- 2.3 資格証明の設定

- 2.4 Enterprise Managerユーザー・アカウントの作成

- 2.4.1 ユーザー・アカウントの概要

- 2.4.2 デザイナ・ユーザー・アカウントの作成

- 2.4.3 オペレータ・ユーザー・アカウントの作成

- 2.5 (オプション) My Oracle Supportの設定

- 2.6 (オプション)自己更新の構成

- 2.7 (オプション)電子メール通知の設定

第II部 検出

3 ホストおよびソフトウェア・デプロイメントの検出

- 3.1 ホストおよびターゲットの自動的な検出

- 3.2 ホストおよびターゲットの手動での検出

第III部 データベースのプロビジョニング

4 データベース・プロビジョニングの概要

- 4.1 データベースのプロビジョニングの概要

- 4.2 サポートされるユースケースおよびデータベース・プロビジョニング・プロシージャを使用してプロビジョニングされるターゲット

- 4.3 データベース・プロビジョニングの設定

- 4.3.1 基本インフラストラクチャとホスト要件を満たす

- 4.3.2 データベースのプロビジョニングに必要な管理者権限の理解

- 4.3.3 デザイナの前提条件

- 4.3.4 オペレータの前提条件

- 4.3.5 データベース・プロビジョニング・プロファイルの作成

- 4.3.6 EMCLIを使用したデータベース・プロビジョニング・プロファイルの記述、作成および削除

- 4.3.6.1 EMCLIを使用したデータベース・プロビジョニング・プロファイルの記述

- 4.3.6.2 EMCLIを使用したデータベース・プロビジョニング・プロファイルの作成

- 4.3.6.3 EMCLIを使用したデータベース・プロビジョニング・プロファイルの削除

- 4.3.7 インストール・メディアの作成

- 4.3.8 データベース・テンプレートの作成

- 4.3.9 ソフトウェア・ライブラリへのデータベース・テンプレートのアップロード

- 4.3.10 データベース・プロビジョニング・エンティティの作成

- 4.3.10.1 参照ホームからのOracle Databaseクローンの作成

- 4.3.10.2 外部記憶域からのOracle Databaseクローンの作成

- 4.3.10.3 参照ホームからのOracleクラスタウェア・クローンの作成

- 4.3.10.4 外部記憶域からのOracleクラスタウェア・クローンの作成

- 4.3.11 クラスタ検証ユーティリティのダウンロード

5 Oracle Databaseのプロビジョニング

- 5.1 Oracleデータベースのプロビジョニングの概要

- 5.2 Oracle Databaseトポロジ

- 5.3 Oracle Databaseのプロビジョニングおよび作成

- 5.3.1 データベースをプロビジョニングするための前提条件

- 5.3.2 データベースをプロビジョニングする手順

- 5.4 Oracle Automatic Storage Managementを使用したOracle Databaseのプロビジョニング

- 5.4.1 Oracle Automatic Storage Managementを使用してOracleデータベースをプロビジョニングするための前提条件

- 5.4.2 データベースをプロビジョニングする手順

- 5.5 Oracle Databaseソフトウェアのみのプロビジョニング

- 5.5.1 Oracle Databaseソフトウェアのみをプロビジョニングするための前提条件

- 5.5.2 Oracle Databaseソフトウェアのみをプロビジョニングする手順

- 5.6 Oracle Databaseのプロビジョニングでの非root資格証明の使用

6 Oracle Database用のOracle Grid Infrastructureのプロビジョニング

- 6.1 OracleデータベースでのOracle Grid Infrastructureのプロビジョニングの概要

- 6.2 Oracle Automatic Storage Managementを使用したOracle Grid InfrastructureおよびOracle Databaseのプロビジョニング

- 6.2.1 Oracle ASMを使用してOracle Grid InfrastructureおよびOracleデータベースをプロビジョニングするための前提条件

- 6.2.2 Oracle ASMを使用してOracle Grid InfrastructureおよびOracleデータベースをプロビジョニングする手順

- 6.3 Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのみのプロビジョニング

- 6.3.1 Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのみをプロビジョニングするための前提条件

- 6.3.2 Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのみをプロビジョニングする手順

7 Oracle Real Application Clustersデータベース用のOracle Grid Infrastructureのプロビジョニング

- 7.1 Oracle RACデータベースのグリッド・インフラストラクチャのプロビジョニングの概要

- 7.2 Oracle Real Application Clustersデータベース・トポロジ

- 7.3 Oracle Real Application Clustersデータベースを使用したグリッド・インフラストラクチャのプロビジョニングとOracle Automatic Storage Managementを使用したデータベースの構成

- 7.3.1 Oracle RACデータベースを使用してグリッド・インフラストラクチャをプロビジョニングするための前提条件

- 7.3.2 Oracle RACデータベースを使用してグリッド・インフラストラクチャをプロビジョニングする手順

- 7.3.2.1 グリッド・インフラストラクチャ・ソフトウェア位置のパスの前提条件

- 7.4 既存のクラスタ上のファイル・システムを使用したOracle Real Application Clustersデータベースのプロビジョニング

- 7.4.1 ファイル・システムを使用して既存のクラスタにOracle RACデータベースをプロビジョニングするための前提条件

- 7.4.2 ファイル・システムを使用して既存のクラスタにOracle RACをプロビジョニングする手順

- 7.5 新規クラスタ上のファイル・システムを使用したOracle Real Application Clustersデータベースのプロビジョニング

- 7.5.1 ファイル・システムを使用して新規のクラスタにOracle RACデータベースをプロビジョニングするための前提条件

- 7.5.2 ファイル・システムを使用して新規のクラスタにOracle RACデータベースをプロビジョニングする手順

- 7.6 Oracle Real Application Clusters (Oracle RAC)データベースのプロビジョニングでの非root資格証明の使用

8 Oracle Real Application Clusters One (Oracle RAC One) Nodeデータベースのプロビジョニング

- 8.1 Oracle RAC One Nodeデータベースのプロビジョニングの概要

- 8.2 Oracle RAC One Nodeデータベースをプロビジョニングするためのデプロイメント・プロシージャ

- 8.3 Oracle RAC One Nodeデータベースのプロビジョニング

- 8.3.1 Oracle RAC One Nodeデータベースをプロビジョニングするための前提条件

- 8.3.2 Oracle RAC One Nodeデータベースをプロビジョニングする手順

9 10gおよび11g用のOracle Real Application Clustersのプロビジョニング

- 9.1 10gおよび11g用のOracle Real Application Clustersのプロビジョニングの概要

- 9.2 Oracle RACのプロビジョニング時にデプロイされるコア・コンポーネント

- 9.3 実行中のOracle Real Application Clusterのクローニング

- 9.3.1 実行中のOracle Real Application Clustersをクローニングするための前提条件

- 9.3.2 実行中のOracle Real Application Clustersをクローニングする手順

- 9.4 ゴールド・イメージを使用したOracle Real Application Clusterのプロビジョニング

- 9.4.1 ゴールド・イメージを使用してOracle Real Application Clustersをプロビジョニングするための前提条件

- 9.4.2 ゴールド・イメージを使用してOracle Real Application Clustersをプロビジョニングする手順

- 9.5 アーカイブ・ソフトウェア・バイナリを使用したOracle Real Application Clusterのプロビジョニング

- 9.5.1 アーカイブ・ソフトウェア・バイナリを使用してOracle Real Application Clustersをプロビジョニングするための前提条件

- 9.5.2 アーカイブ・ソフトウェア・バイナリを使用してOracle Real Application Clustersをプロビジョニングする手順

- 9.5.2.1 サンプルのクラスタ構成ファイル

- 9.6 Oracle Real Application Clusters (Oracle RAC)データベースのプロビジョニングでの非root資格証明の使用

10 Oracle Real Application Clustersの拡張

- 10.1 Oracle Real Application Clustersの拡張の概要

- 10.2 Oracle Real Application Clustersの拡張

- 10.2.1 Oracle Real Application Clustersを拡張するための前提条件

- 10.2.2 Oracle Real Application Clustersを拡張する手順

11 Oracle Real Application Clustersの削除またはスケール・ダウン

- 11.1 Oracle Real Application Clustersの削除またはスケール・ダウンの概要

- 11.2 Oracle Real Application Clustersのコア・コンポーネントの削除

- 11.3 Oracle RAC全体の削除

- 11.3.1 Oracle RAC全体を削除するための前提条件

- 11.3.2 Oracle RAC全体を削除する手順

- 11.4 Oracle RACの一部のノードの削除によるスケール・ダウン

- 11.4.1 ノードの一部を削除してOracle RACをスケール・ダウンするための前提条件

- 11.4.2 ノードの一部を削除してOracle RACをスケール・ダウンする手順

12 Oracleデータベース・リプレイ・クライアントのプロビジョニング

- 12.1 Oracleデータベース・リプレイ・クライアントのプロビジョニングの概要

- 12.2 実行中のOracleデータベース・リプレイ・クライアントのクローニング

- 12.2.1 実行中のOracleデータベース・リプレイ・クライアントをクローニングするための前提条件

- 12.2.2 実行中のOracleデータベース・リプレイ・クライアントをクローニングする手順

- 12.3 ゴールド・イメージを使用したOracleデータベース・リプレイ・クライアントのプロビジョニング

- 12.3.1 ゴールド・イメージを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングするための前提条件

- 12.3.2 ゴールド・イメージを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングする手順

- 12.4 インストール・バイナリを使用したOracleデータベース・リプレイ・クライアントのプロビジョニング

- 12.4.1 インストール・バイナリを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングするための前提条件

- 12.4.2 インストール・バイナリを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングする手順

13 Oracleスタンバイ・データベースのプロビジョニング

- 13.1 スタンバイ・データベースの作成の概要

- 13.2 新規のフィジカル・スタンバイ・データベースの作成(単一インスタンスのみ)

- 13.2.1 ステップ1: バックアップ・タイプの決定

- 13.2.2 ステップ2: バックアップ・オプションの設定

- 13.2.3 ステップ3: スタンバイ・データベースを作成するOracleホームの選択

- 13.2.4 ステップ4: スタンバイ・データベース・ファイルの場所の設定

- 13.2.5 ステップ5: スタンバイ・データベースの構成パラメータの指定

- 13.2.6 ステップ6: 情報を確認してから「終了」をクリック

- 13.3 新規のロジカル・スタンバイ・データベースの作成(単一インスタンスのみ)

- 13.3.1 ステップ1: バックアップ・タイプの決定

- 13.3.2 ステップ2: バックアップ・オプションの設定

- 13.3.3 ステップ3: スタンバイ・データベースを作成するOracleホームの選択

- 13.3.4 ステップ4: スタンバイ・データベース・ファイルの場所の設定

- 13.3.5 ステップ5: スタンバイ・データベースの構成パラメータの指定

- 13.3.6 ステップ6: 情報を確認してから「終了」をクリック

- 13.4 Data Guard Brokerを使用した既存のスタンバイ・データベースの管理

- 13.5 プライマリ・データベースのバックアップのみを作成

14 Oracleデータベースおよびプラガブル・データベースのクローニング

- 14.1 フル・クローン・データベースの作成

- 14.1.1 クローン・ウィザードを使用したフル・クローン・データベースの作成

- 14.1.2 EM CLIを使用したフル・クローン・データベースの作成

- 14.2 テスト・マスター・データベースの作成

- 14.2.1 クローン・ウィザードを使用したテスト・マスター・データベースの作成

- 14.2.2 EM CLIを使用したテスト・マスター・データベースの作成

- 14.3 フル・クローン・プラガブル・データベースの作成

- 14.3.1 クローン・ウィザードを使用したフル・クローン・プラガブル・データベースの作成

- 14.3.2 EM CLIを使用したフル・クローン・プラガブル・データベースの作成

- 14.4 テスト・マスター・プラガブル・データベースの作成

- 14.4.1 クローン・ウィザードを使用したテスト・マスター・プラガブル・データベースの作成

- 14.4.2 EM CLIを使用したテスト・マスター・プラガブル・データベースの作成

- 14.5 クラシック・クローニング・ウィザードを使用したデータベースのクローニング

- 14.5.1 クラシック・クローニング・メソッドの概要

- 14.5.2 Recovery Manager (RMAN)バックアップを使用したOracle Databaseのクローニング

- 14.5.3 ステージング領域を使用したOracle Databaseのクローニング

- 14.5.4 既存のバックアップを使用したOracle Databaseのクローニング

15 Hybrid Cloud (Oracle PaaS)でのクローニング・ソリューション

- 15.1 Oracle PaaSでのクローニングの概要

- 15.2 Hybrid Cloudユースケースでのクローニング

- 15.3 Oracle PaaSでのクローニングの前提条件

- 15.4 Oracle Cloudへのクローニング

- 15.4.1 Oracle CloudへのPDBのクローニング

- 15.4.1.1 クローン・ウィザードを使用したOracle CloudへのPDBのクローニング

- 15.4.1.2 EM CLIを使用したOracle CloudへのPDBのクローニング

- 15.4.2 Oracle CloudのDBまたはPDBへのスキーマのクローニング

- 15.4.3 Oracle CloudのDBまたはPDBへのDBのクローニング

- 15.5 Oracle Cloudからのクローニング

- 15.5.1 Oracle CloudからのPDBのクローニング

- 15.5.1.1 クローン・ウィザードを使用したOracle CloudからのPDBのクローニング

- 15.5.1.2 EM CLIを使用したOracle CloudからのPDBのクローニング

- 15.5.2 Oracle CloudからDBまたはPDBへのスキーマのクローニング

- 15.5.3 Oracle CloudからDBまたはPDBへのDBのクローニング

- 15.6 Oracle Cloud内でのクローニング

- 15.6.1 Oracle PaaS内でのPDBのクローニング

- 15.6.2 Oracle PaaS内でのDBのクローニング

16 データベースの作成

- 16.1 データベースの作成の概要

- 16.2 Oracle Databaseの作成

- 16.2.1 Oracleデータベースを作成するための前提条件

- 16.2.2 Oracleデータベースを作成する手順

- 16.3 Oracle Real Application Clustersデータベースの作成

- 16.3.1 Oracle Real Application Clustersデータベースを作成するための前提条件

- 16.3.2 Oracle Real Application Clustersデータベースを作成する手順

- 16.4 Oracle Real Application Clusters One Nodeデータベースの作成

- 16.4.1 Oracle RAC One Nodeデータベースを作成するための前提条件

- 16.4.2 Oracle Real Application Clusters One Nodeデータベースを作成する手順

17 プラガブル・データベースの管理

- 17.1 プラガブル・データベースの管理の概要

- 17.2 プラガブル・データベースの管理の概要

- 17.3 プラガブル・データベースのプロビジョニング

- 17.3.1 新しいプラガブル・データベースの作成

- 17.3.1.1 新しいプラガブル・データベースを作成するための前提条件

- 17.3.1.2 新しいプラガブル・データベースの作成

- 17.3.2 切断されたプラガブル・データベースのプラグイン

- 17.3.2.1 切断されたプラガブル・データベースをプラグインするための前提条件

- 17.3.2.2 切断されたプラガブル・データベースのプラグイン

- 17.3.3 プラガブル・データベースのクローニング

- 17.3.3.1 プラガブル・データベースをクローニングするための前提条件

- 17.3.3.2 プラガブル・データベースのクローニング

- 17.3.4 非CDBのプラガブル・データベースとしての移行

- 17.3.4.1 非CDBをプラガブル・データベースとして移行するための前提条件

- 17.3.4.2 非CDBのプラガブル・データベースとしての移行

- 17.4 プラガブル・データベースの削除

- 17.4.1 プラガブル・データベースの切断および削除

- 17.4.1.1 プラガブル・データベースを切断および削除するための前提条件

- 17.4.1.2 プラガブル・データベースの切断および削除

- 17.4.2 プラガブル・データベースの削除

- 17.4.2.1 プラガブル・データベースを削除するための前提条件

- 17.4.2.2 プラガブル・データベースの削除

- 17.5 プラガブル・データベース・ジョブの詳細の表示

- 17.5.1 プラガブル・データベースの作成ジョブの詳細の表示

- 17.5.2 プラガブル・データベースの切断ジョブの詳細の表示

- 17.5.3 プラガブル・データベースの削除ジョブの詳細の表示

- 17.6 プラガブル・データベースの管理

- 17.6.1 プラガブル・データベース間の切替え

- 17.6.2 プラガブル・データベースの状態の変更

第IV部 データベースのアップグレード

18 データベースのアップグレード

- 18.1 開始

- 18.2 サポートされているリリース

- 18.3 デプロイメント・プロシージャを使用したデータベースのアップグレード

- 18.3.1 デプロイメント・プロシージャについて

- 18.3.2 前提条件の確認

- 18.3.3 デプロイメント・プロシージャを使用したOracleクラスタ・データベースのアップグレード

- 18.3.4 デプロイメント・プロシージャを使用したOracle Clusterwareのアップグレード

- 18.3.5 デプロイメント・プロシージャを使用したOracle Databaseインスタンスのアップグレード

- 18.4 データベース・アップグレード・ウィザードを使用したOracle DatabaseまたはOracle RACデータベース・インスタンスのアップグレード

- 18.4.1 前提条件の確認

- 18.4.2 アップグレード・プロシージャの実行

第V部 データベース・セキュリティ

19 Oracle Audit Vault and Database Firewallの管理

20 Oracle Data Redactionの使用

21 Oracle Database Vaultおよび権限分析の管理

第VI部 ミドルウェアのプロビジョニング

22 Middlewareプロビジョニングの概要

- 22.1 Middlewareプロビジョニングの概要

- 22.2 Oracle Fusion Middlewareプロビジョニングの用語

- 22.3 Middlewareプロビジョニング・プロシージャのサポートされるユースケース

- 22.3.1 ミドルウェア・ドメインおよびOracleホームのプロビジョニング

- 22.3.2 WebLogic Serverドメイン、SOAドメイン、Oracle Service BusドメインおよびWebCenterドメインのスケーリング

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

- 22.3.4 コヒーレンス・ノードおよびクラスタのプロビジョニング

- 22.3.5 SOAアーティファクトのプロビジョニング

- 22.3.6 Oracle Service Busリソースのプロビジョニング

- 22.3.7 Oracle BPELプロセスのプロビジョニング

- 22.3.8 Oracle Application Serverのプロビジョニング

23 Fusion MiddlewareドメインおよびOracleホームのプロビジョニング

- 23.1 Fusion Middlewareプロビジョニングの概要

- 23.2 Fusion Middlewareのプロビジョニング・デプロイメント・プロシージャ起動の別の方法

- 23.3 Middlewareプロビジョニングの手順概要

- 23.3.1 ステップ1: プロファイルの作成

- 23.3.2 ステップ2: プロファイルをプロビジョニングするFusion Middlewareのプロビジョニング・プロシージャの実行

- 23.4 Middlewareプロビジョニング・プロファイルからプロビジョニングするための前提条件

- 23.4.1 インストール・メディア・プロファイルまたはOracleホーム・プロファイルをプロビジョニングするための前提条件

- 23.4.2 WebLogicドメイン・プロファイルをプロビジョニングするための前提条件

- 23.4.3 ソフトウェア・ライブラリに格納されているカスタム・スクリプトの使用

- 23.4.3.1 入力パラメータを含むカスタム・スクリプトの使用

- 23.4.3.2 入力パラメータを含まないカスタム・スクリプトの使用

- 23.5 Middlewareプロビジョニング・プロファイルの作成

- 23.5.1 インストール・メディアに基づくプロビジョニング・プロファイルの作成

- 23.5.2 Oracleホームに基づくプロビジョニング・プロファイルの作成

- 23.5.3 WebLogicドメインに基づくプロビジョニング・プロファイルの作成

- 23.6 インストール・メディアに基づくプロファイルまたはOracleホームに基づくプロファイルからの新しいFusion Middlewareドメインのプロビジョニング

- 23.6.1 インストール・メディア・ベースのプロファイルまたはOracleホーム・ベースのプロファイルからの宛先環境のカスタマイズ

- 23.7 既存のOracleホームからのFusion Middlewareドメインのプロビジョニング

- 23.7.1 既存のOracleホームからの宛先環境のカスタマイズ

- 23.8 既存のWebLogicドメインに基づくプロファイルからのクローニング

- 23.8.1 既存のWeLogicドメイン・ベースのプロファイルからの宛先環境のカスタマイズ

24 SOAドメインおよびOracleホームのプロビジョニング

- 24.1 SOAドメインおよびOracleホームのプロビジョニングの概要

- 24.2 SOAプロビジョニング後のソース環境および接続先環境

- 24.2.1 新しいSOAプロビジョニング・ユースケースのソースおよび接続先環境

- 24.2.2 SOAクローニング・ユースケースのソースおよび接続先環境

- 24.3 プロビジョニングでサポートされるSOAのバージョン

- 24.4 SOAドメインおよびOracleホームのプロビジョニングを開始する前に

- 24.4.1 ミドルウェア・ロールの作成および権限の割当て

- 24.4.2 ミドルウェア・ターゲットの名前付き資格証明および特権資格証明の設定

- 24.4.3 (WebLogicドメインのクローニング・ユースケースにのみ適用可能) データベースのクローニング

- 24.5 ユースケース1: SOAドメインの初めてのプロビジョニング

- 24.6 ユースケース2: SOA Oracleホームに基づくプロビジョニング・プロファイルからのプロビジョニング

- 24.7 ユースケース3: 既存のSOAドメインに基づくプロビジョニング・プロファイルからのクローニング

- 24.8 ユースケース4: 既存のSOAホームからのプロビジョニング

- 24.9 ユースケース5: 既存のSOAドメインのスケール・アップ

25 Oracle Service BusドメインおよびOracleホームのプロビジョニング

- 25.1 OSBドメインおよびOracleホームのプロビジョニングの概要

- 25.2 プロビジョニングでサポートされるOSBのバージョン

- 25.3 OSBドメインおよびOracleホームのプロビジョニングを開始する前に

- 25.3.1 ミドルウェア・ロールの作成および権限の割当て

- 25.3.2 ミドルウェア・ターゲットの名前付き資格証明および特権資格証明の設定

- 25.3.3 (WebLogicドメインのクローニング・ユースケースにのみ適用可能) データベースのクローニング

- 25.4 ユースケース1: OSBドメインの初めてのプロビジョニング

- 25.5 ユースケース2: OSBホームに基づくプロビジョニング・プロファイルからのプロビジョニング

- 25.6 ユースケース3: 既存のOSBドメインに基づくプロビジョニング・プロファイルからのクローニング

- 25.7 ユースケース4: 既存のOSBホームからのプロビジョニング

- 25.8 ユースケース5: 既存のOSBドメインのスケール・アップ

26 Oracle WebCenterドメインおよびOracleホームのプロビジョニング

- 26.1 WebCenterドメインおよびOracleホームのプロビジョニングの概要

- 26.2 Enterprise ManagerでサポートされるWebCenterトポロジについて

- 26.3 WebCenterプロビジョニング後のソース環境および接続先環境

- 26.3.1 新しいWebCenterプロビジョニング・ユースケースのソースおよび接続先環境

- 26.3.2 WebCenterクローニング・ユースケースのソースおよび接続先環境

- 26.4 プロビジョニングでサポートされるWebCenterのバージョン

- 26.5 WebCenterドメインおよびOracleホームのプロビジョニングを開始する前に

- 26.5.1 ミドルウェア・ロールの作成および権限の割当て

- 26.5.2 ミドルウェア・ターゲットの名前付き資格証明および特権資格証明の設定

- 26.5.3 (WebLogicドメインのクローニング・ユースケースにのみ適用可能) データベースのクローニング

- 26.6 ユースケース1: ロックダウンを使用したWebCenter Portalの初めてのプロビジョニング

- 26.7 ユースケース2: WebCenterホームのプロビジョニング

- 26.8 ユースケース3: 既存のWebCenter Portal環境のクローニング

- 26.9 ユースケース4: 既存のWebCenterホームからのプロビジョニング

- 26.10 ユースケース5: 既存のWebCenterドメインのスケール・アップ

27 EM CLIを使用したMiddlewareプロビジョニング

- 27.1 Middlewareプロビジョニング・プロファイルの作成

- 27.1.1 WebLogicドメイン・プロファイルの作成

- 27.1.2 Oracleホーム・プロファイルの作成

- 27.1.3 インストール・メディア・プロファイルの作成

- 27.2 EM CLIを使用したプロシージャの発行

- 27.3 Middlewareプロビジョニング・プロファイルのリスト

- 27.3.1 すべてのプロファイルのリスト

- 27.3.2 すべてのWebLogicドメイン・プロファイルのリスト

- 27.3.3 すべてのOracleホーム・プロファイルのリスト

- 27.3.4 すべてのインストール・メディア・プロファイルのリスト

- 27.4 プロビジョニング・プロファイルの記述

- 27.4.1 WebLogicドメイン・プロファイルの説明

- 27.4.2 Oracleホーム・プロファイルの説明

- 27.4.3 インストール・メディア・プロファイルの説明

- 27.5 プロビジョニング・プロファイルの削除

28 REST APIを使用したミドルウェア・プロファイル

- 28.1 Middlewareプロビジョニング・プロファイルの作成

- 28.1.1 WebLogicドメイン・プロファイルの作成

- 28.1.2 Oracleホーム・プロファイルの作成

- 28.1.3 インストール・メディア・プロファイルの作成

- 28.2 Middlewareプロビジョニング・プロファイルのリスト

- 28.2.1 すべてのプロファイルのリスト

- 28.2.2 WebLogicドメイン・プロファイルのリスト

- 28.2.3 Oracleホーム・プロファイルのリスト

- 28.2.4 インストール・メディア・プロファイルのリスト

- 28.3 プロビジョニング・プロファイルの記述

- 28.3.1 WebLogicドメイン・プロファイルの説明

- 28.3.2 Oracleホーム・プロファイルの説明

- 28.3.3 インストール・メディア・プロファイルの説明

- 28.4 プロビジョニング・プロファイルの削除

- 28.4.1 WebLogicドメイン・プロファイルの削除

- 28.4.2 Oracleホーム・プロファイルの削除

- 28.4.3 インストール・メディア・プロファイルの削除

29 Fusion Middlewareドメインのスケール・アップ/スケール・アウト

- 29.1 開始

- 29.2 前提条件

- 29.3 「ミドルウェアのスケール・アップ/スケール・アウト」デプロイメント・プロシージャの実行

- 29.3.1 WebLogicドメイン・スケール・アップ: ソースの選択ページ

- 29.3.2 WebLogicドメイン・スケール・アップ: 管理対象サーバー・ページ

- 29.3.3 WebLogicドメイン・スケール・アップ/WebLogicドメイン・スケール・アウト: Web層

- 29.3.4 WebLogicドメイン・スケール・アップ/WebLogicドメイン・スケール・アウト: 資格証明ページ

- 29.3.5 WebLogicドメイン・スケール・アップ/WebLogicドメイン・スケール・アウト: スケジュール・ページ

- 29.3.6 WebLogicドメイン・スケール・アップ/WebLogicドメイン・スケール・アウト: 確認ページ

- 29.4 Middlewareのプロビジョニングおよびスケール・アップ/スケール・アウトのベスト・プラクティス

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

- 30.1 Java EEアプリケーションの概要

- 30.2 Java EEアプリケーションのデプロイ、アンデプロイまたは再デプロイ

- 30.3 Java EEアプリケーションでサポートされているリリース

- 30.4 Java EEアプリケーションをデプロイ/アンデプロイするための前提条件

- 30.5 Java EEアプリケーション・コンポーネントの作成

- 30.6 「Java EEアプリケーション」デプロイメント・プロシージャ

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

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

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

31 コヒーレンス・ノードおよびクラスタのプロビジョニング

- 31.1 開始

- 31.2 サポートされているリリース

- 31.3 コヒーレンス・ノードおよびクラスタのデプロイ

- 31.3.1 前提条件

- 31.3.2 コヒーレンス・コンポーネントの作成

- 31.3.3 デプロイメント・プロシージャ

- 31.3.3.1 コヒーレンス・ノードの追加

- 31.3.3.2 サンプル・スクリプト

- 31.4 トラブルシューティング

32 SOAアーティファクトおよびコンポジットのプロビジョニング

- 32.1 SOAアーティファクトのプロビジョニングの概要

- 32.2 SOAアーティファクトのプロビジョニングの理解

- 32.3 デプロイメント・プロシージャ、サポートされるリリース、およびデプロイされるコア・コンポーネント

- 32.4 SOAアーティファクトのプロビジョニング

- 32.4.1 参照インストールからのSOAアーティファクトのプロビジョニング

- 32.4.2 ゴールド・イメージからのSOAアーティファクトのプロビジョニング

- 32.5 SOAコンポジットのデプロイ

33 Oracle Service Busリソースのプロビジョニング

- 33.1 Oracle Service Busリソースのプロビジョニングの概要

- 33.2 サポートされているリリース

- 33.3 Oracle Service BusドメインからのOracle Service Busリソースのプロビジョニング

- 33.4 OSBリソースのエクスポート・モードの理解

- 33.5 Oracleソフトウェア・ライブラリからのOracle Service Busリソースのプロビジョニング

34 Oracle BPELプロセスのプロビジョニング

- 34.1 Oracle BPELプロセスの概要

- 34.2 Oracle BPELプロセスでサポートされているリリース

- 34.3 Oracle BPELプロセスのプロビジョニング

35 Oracle Application Serverのプロビジョニング

- 35.1 Oracle Application Serverのプロビジョニングの概要

- 35.2 デプロイメント・プロシージャ、サポートされるリリース、およびデプロイされるコア・コンポーネント

- 35.3 Oracle Application Server 10gリリース1 (10.1.3)のプロビジョニング

- 35.3.1 実行中のOracle Application Serverインスタンスのクローニング

- 35.3.1.1 既存のクラスタからクローニングし、既存のクラスタをスケール・アップし、同じインターネット・ディレクトリを使用

- 35.3.1.2 既存のクラスタからプロビジョニングし、インターネット・ディレクトリを使用せずに新規クラスタを作成

- 35.3.1.3 既存のクラスタからプロビジョニングし、インターネット・ディレクトリを使用して新規クラスタを作成

- 35.3.2 Oracle Application Serverのゴールド・イメージのプロビジョニング

- 35.3.2.1 プロビジョニングし、インターネット・ディレクトリを使用せずに新規クラスタを作成

- 35.3.2.2 プロビジョニングし、インターネット・ディレクトリを使用して新規クラスタを作成

- 35.3.2.3 プロビジョニングし、インターネット・ディレクトリを使用せずにスタンドアロン・インスタンスとしてOracle Application Serverを処理

- 35.3.2.4 プロビジョニングし、インターネット・ディレクトリを使用してスタンドアロン・インスタンスとしてOracle Application Serverを処理

- 35.4 Oracle SOA Suite 10g (10.1.3.4および10.1.3.5)のプロビジョニング

第VII部 ベアメタル・サーバーのプロビジョニング

36 ベアメタル・サーバーのプロビジョニング

- 36.1 ベアメタル・サーバーのプロビジョニングの概要

- 36.2 ベアメタル・プロビジョニングの概要

- 36.2.1 「ベアメタル・プロビジョニング」ページヘのアクセス

- 36.2.2 ベアメタルのプロビジョニング環境

- 36.2.2.1 ソフトウェア・ライブラリおよびそのエンティティ

- 36.2.2.2 ブート・サーバー

- 36.2.2.3 ステージング・サーバー

- 36.2.2.4 参照ホスト

- 36.2.2.5 RPMリポジトリ

- 36.2.3 ベアメタルのプロビジョニング

- 36.3 Linuxのサポート対象リリース

- 36.4 ベアメタル・プロビジョニングのインフラストラクチャの設定

- 36.4.1 ステージング・サーバーの設定

- 36.4.1.1 ステージング・サーバーを設定するための前提条件

- 36.4.1.2 ステージング・サーバーの設定および管理エージェント・ファイルへのアクセス

- 36.4.2 ブート・サーバーとDHCPサーバーの設定

- 36.4.3 RPMリポジトリの設定

- 36.4.3.1 RHEL 4 RPMリポジトリの設定

- 36.4.3.2 Oracle Linux 4 RPMリポジトリの設定

- 36.4.3.3 RHEL 5/Oracle Linux 5 RPMリポジトリの設定

- 36.4.3.4 HTTPまたはFTPでのRPMリポジトリの公開

- 36.4.4 ステージング・サーバーの構成

- 36.4.5 ブート・サーバーの構成

- 36.4.6 DHCPサーバーの構成

- 36.4.7 RPMリポジトリの構成

- 36.4.8 ブート・サーバー、ステージング・サーバー、RPMリポジトリ、参照ホストのチェックリスト

- 36.4.9 ソフトウェア・ライブラリ・コンポーネントの構成

- 36.4.9.1 オペレーティング・システム・コンポーネントの作成

- 36.4.9.2 ディスク・レイアウト・コンポーネントの作成

- 36.4.9.3 Oracle Virtual Serverコンポーネントの作成

- 36.5 ベアメタル・サーバーおよびOracle VM Serverのプロビジョニングの前提条件

- 36.6 ベアメタル・サーバーのプロビジョニング

- 36.7 Oracle VM Serverのプロビジョニング

- 36.8 保存済計画の表示

- 36.9 ベアメタル・サーバー上のLinuxオペレーティング・システムのプロビジョニングにおける保存済計画の使用

第VIII部 ホスト管理

37 ホスト管理の概要

- 37.1 ホスト統計

- 37.2 ホストの問題の診断

- 37.3 ホストでのターゲットの表示

- 37.4 ストレージ統計および履歴

38 ホストを監視する環境の設定

- 38.1 必須インストール

- 38.2 Linuxホストの場合 - YASTのインストール

- 38.3 資格証明の設定

- 38.4 ホストの監視に必要な設定

- 38.4.1 監視構成の表示

- 38.4.2 モニタリング資格証明の設定

- 38.5 ホストの管理に必要なターゲット設定

39 ホスト監視環境のカスタマイズ

- 39.1 「ホストのホームページ」のカスタマイズ

- 39.2 グループの使用

40 ホストの監視

- 40.1 全体的な監視

- 40.1.1 CPU詳細

- 40.1.2 メモリーの詳細

- 40.1.3 ディスクの詳細

- 40.1.4 プログラム・リソース使用率

- 40.1.5 ログ・ファイル・アラート

- 40.1.6 メトリック収集エラー

- 40.2 記憶域詳細

- 40.2.1 記憶域の使用状況

- 40.2.2 全体の使用量

- 40.2.3 プロビジョニング・サマリー

- 40.2.4 消費サマリー

- 40.2.5 ASM

- 40.2.6 データベース

- 40.2.7 ディスク

- 40.2.8 ファイル・システム

- 40.2.9 ボリューム

- 40.2.9.1 エンティティのタイプ

- 40.2.9.2 トップレベルのエンティティ

- 40.2.9.3 ボトムレベルのエンティティ

- 40.2.9.4 中間のエンティティ

- 40.2.10 ベンダーの配分

- 40.2.11 記憶域履歴

- 40.2.12 記憶域レイヤー

- 40.2.13 記憶域リフレッシュ

41 ホストの管理

- 41.1 ホストでの構成操作

- 41.1.1 ファイルおよびディレクトリの監視基準の構成

- 41.1.2 一般ログ・ファイル監視基準の構成

- 41.1.3 プログラム・リソース使用率監視基準の構成

- 41.2 管理タスク

- 41.2.1 サービス

- 41.2.2 デフォルトのシステム実行レベル

- 41.2.3 ネットワーク・カード

- 41.2.4 ホスト参照表

- 41.2.5 NFSクライアント

- 41.2.6 ユーザーとグループの管理(ユーザー)

- 41.2.7 ユーザーとグループの管理(グループ)

- 41.3 ツールおよびコマンドの使用

- 41.3.1 SudoおよびPower Brokerの有効化

- 41.3.2 SudoまたはPowerBrokerを使用したホスト・コマンドの実行

- 41.3.3 リモート・ファイル・エディタ

- 41.4 ホスト・ターゲットの追加

- 41.5 ホスト・コマンドの実行

- 41.5.1 ホスト・コマンドへのアクセス

- 41.5.2 SudoまたはPower Brokerを使用したホスト・コマンドの実行

- 41.5.3 ホスト・コマンドの実行 - 複数ホスト

- 41.5.3.1 ターゲットのプロパティ

- 41.5.4 ホスト・コマンドの実行 - グループ

- 41.5.5 ホスト・コマンドの実行 - 単一ホスト

- 41.5.6 OSスクリプトのロード

- 41.5.7 ジョブ・ライブラリからロード

- 41.5.8 実行履歴

- 41.5.9 実行結果

- 41.6 様々なタスク

- 41.6.1 WBEM Fetchletベースのメトリック収集の有効化

- 41.6.2 Dell PowerEdge Linuxホストでのハードウェア監視の有効化

- 41.6.3 ホスト構成の追加および編集

第IX部 パッチ管理

42 ソフトウェア・デプロイメントへのパッチ適用

- 42.1 新しいパッチ管理ソリューションの概要

- 42.1.1 現在のパッチ管理における課題の概要

- 42.1.2 新しいパッチ管理ソリューションについて

- 42.1.3 パッチ計画の概要

- 42.1.3.1 パッチ計画について

- 42.1.3.2 パッチ計画のタイプについて

- 42.1.3.3 計画の作成ウィザードについて

- 42.1.4 パッチ・テンプレートの概要

- 42.1.4.1 パッチ・テンプレートについて

- 42.1.4.2 テンプレートの編集ウィザードについて

- 42.1.5 パッチ適用にサポートされているターゲット、リリースおよびデプロイメント・プロシージャ

- 42.1.6 サポートされているパッチ適用モードの概要

- 42.1.6.1 オンライン・モードおよびオフライン・モードでのパッチ適用の概要

- 42.1.6.2 インプレース・モードおよびホーム外モードでのパッチ適用の概要

- 42.1.6.3 ローリング・モードおよびパラレル・モードでのパッチ適用の概要

- 42.1.7 パッチ適用ワークフローの理解

- 42.2 パッチ適用のインフラストラクチャの設定

- 42.2.1 パッチ適用のためのインフラストラクチャの基本要件

- 42.2.2 パッチ適用に必要なロールを持つ管理者の作成

- 42.2.3 オンライン・モードでパッチを適用するためのインフラストラクチャの設定(MOSに接続済)

- 42.2.3.1 パッチ適用のためのオンライン・モードの有効化

- 42.2.3.2 My Oracle Support用のプロキシ詳細の登録

- 42.2.4 オフライン・モードでパッチを適用するためのインフラストラクチャの設定(MOSに未接続)

- 42.2.4.1 パッチ適用のためのオフライン・モードの有効化

- 42.2.4.2 インターネット接続が可能な別のホストからのEnterprise ManagerカタログのZIPファイルのダウンロード

- 42.2.4.3 インターネット接続が不可能な使用ホストからのEnterprise ManagerカタログのZIPファイルのアップロード

- 42.2.4.4 Oracle Software Libraryへのパッチのアップロード

- 42.2.5 環境の分析およびターゲットにパッチを適用できるかどうかの確認

- 42.3 適用するパッチの特定

- 42.3.1 パッチ推奨について

- 42.3.2 パッチ適用のためのナレッジ記事について

- 42.3.3 パッチ適用のためのサービス・リクエストについて

- 42.3.4 My Oracle Supportでのパッチの検索

- 42.3.5 Oracleソフトウェア・ライブラリでのパッチの検索

- 42.4 パッチの適用

- 42.4.1 パッチ計画の作成

- 42.4.2 パッチ計画へのアクセス

- 42.4.3 パッチ計画の分析、準備およびデプロイ

- 42.4.4 パッチ計画のデプロイ後に元のOracleホームにスイッチバック

- 42.4.5 正常に分析されたまたはデプロイされたパッチ計画をパッチ・テンプレートとして保存

- 42.4.6 パッチ・テンプレートからのパッチ計画の作成およびパッチの適用

- 42.4.7 Oracle Grid Infrastructureターゲットのパッチ適用

- 42.4.8 Oracle Exadataへのパッチ適用

- 42.4.9 Oracle Data Guardターゲットへのパッチ適用

- 42.4.9.1 Oracle Data Guardのパッチ適用ワークフロー

- 42.4.9.2 Oracle Data Guardのパッチ適用の使用例

- 42.4.10 Oracle Identity Managementターゲットへのパッチ適用

- 42.4.11 Oracle Siebelターゲットへのパッチ適用

- 42.5 パッチ適用に関する問題の診断および解決

- 42.5.1 ターゲット関連エラーの回避策

- 42.5.1.1 プロパティの欠落エラーの回避策

- 42.5.1.2 サポートされない構成エラーの回避策

- 42.5.2 パッチ適用に関する一般的な問題

- 42.5.3 パッチ適用に関する問題の解決

- 42.5.4 パッチのロールバック

- 42.6 その他の実行可能パッチ適用タスク

- 42.6.1 パッチ・テンプレートの表示または変更

- 42.6.2 デプロイされたパッチ計画をパッチ・テンプレートとして保存

- 42.6.3 パッチ・テンプレートからのパッチのダウンロード

- 42.6.4 パッチ計画の削除

- 42.6.5 パッチ・テンプレートの削除

- 42.6.6 デプロイ可能なパッチ計画へのデプロイ不可能なパッチ計画の変換

- 42.6.7 パッチ計画のパッチへの追加ターゲットの関連付け

- 42.6.8 パッチを適用するルート・コンポーネントの手動によるステージング

- 42.6.9 パッチ適用のためのルート・ユーザー・アクセスの制限

- 42.6.10 パッチ競合の解決

- 42.6.11 パッチ適用操作の結果の分析

- 42.6.12 パッチ適用デプロイメント・プロシージャのカスタマイズ

- 42.6.12.1 静的パッチ適用デプロイメント・プロシージャのカスタマイズ

- 42.6.12.2 動的パッチ適用デプロイメント・プロシージャのカスタマイズ

- 42.6.13 ローリング・モードでのターゲットへのパッチ適用中のパッチ適用プロセスの一時休止

- 42.6.14 パッチのロールバック

- 42.7 エンドツーエンド・ユースケース: データ・センターのパッチ適用

- 42.8 サービス・プールとしてのデータベースのパッチ適用

43 Linuxホストへのパッチ適用

- 43.1 Linuxホストへのパッチ適用の概要

- 43.2 Linuxホストにパッチを適用するためのデプロイメント・プロシージャについて

- 43.3 サポートされているLinuxリリース

- 43.4 Linuxパッチ適用のインフラストラクチャの設定

- 43.4.1 Linuxパッチ適用機能を使用するための前提条件

- 43.4.2 Linuxパッチ適用のためのRPMリポジトリの設定

- 43.4.2.1 RPMリポジトリを設定するための前提条件

- 43.4.2.2 パッチ適用のためのRPMリポジトリの設定

- 43.4.3 コンプライアンス・レポート用のLinuxパッチ適用グループの設定

- 43.4.3.1 Linuxパッチ適用グループを設定するための前提条件

- 43.4.3.2 Linuxパッチ適用グループの設定

- 43.5 Linuxホストへのパッチ適用

- 43.5.1 コンプライアンスに基づいたLinuxパッチ適用グループへのパッチ適用

- 43.5.2 Linuxホストへのアド・ホックまたは緊急のパッチ適用

- 43.6 Linux構成ファイルの管理

- 43.6.1 Linux構成ファイルの概要

- 43.6.2 構成ファイルを管理するための前提条件

- 43.6.3 Linux構成ファイル・チャネルの作成

- 43.6.4 特定のチャネルへのLinux構成ファイルのアップロード

- 43.6.4.1 Linux構成ファイルをアップロードするための前提条件

- 43.6.4.2 Linux構成ファイルのアップロード

- 43.6.5 チャネル間でのLinux構成ファイルのインポート

- 43.6.5.1 Linux構成ファイルをインポートするための前提条件

- 43.6.5.2 Linux構成ファイルのインポート

- 43.6.6 特定のチャネルからのLinux構成ファイルのデプロイ

- 43.6.6.1 Linux構成ファイルをデプロイするための前提条件

- 43.6.6.2 Linux構成ファイルのデプロイ

- 43.6.7 Linux構成ファイル・チャネルの削除

- 43.6.7.1 Linux構成ファイル・チャネルを削除するための前提条件

- 43.6.7.2 Linux構成ファイル・チャネルの削除

- 43.7 その他の実行可能Linuxパッチ適用タスク

- 43.7.1 Linuxパッチ適用コンプライアンス履歴の表示

- 43.7.1.1 Linuxパッチ適用コンプライアンス履歴を表示するための前提条件

- 43.7.1.2 Linuxパッチ適用コンプライアンス履歴の表示

- 43.7.2 非コンプライアンスLinuxパッケージへのパッチ適用

- 43.7.2.1 非コンプライアンスLinuxパッケージにパッチを適用するための前提条件

- 43.7.2.2 非コンプライアンスLinuxパッケージへのパッチ適用

- 43.7.3 Linuxパッチ更新セッションのロールバックまたはパッケージの削除

- 43.7.3.1 Linuxパッチ更新セッションのロールバックまたはパッケージの削除の前提条件

- 43.7.3.2 Linuxパッチ更新セッションのロールバックまたはパッケージの削除

- 43.7.4 カスタム・パッケージ・チャネルの登録

- 43.7.4.1 カスタム・パッケージ・チャネルを登録するための前提条件

- 43.7.4.2 カスタム・パッケージ・チャネルの登録

- 43.7.5 パッケージ・チャネルのクローニング

- 43.7.5.1 パッケージ・チャネルをクローニングするための前提条件

- 43.7.5.2 パッケージ・チャネルのクローニング

- 43.7.6 チャネル間でのパッケージのコピー

- 43.7.6.1 チャネル間でパッケージをコピーするための前提条件

- 43.7.6.2 チャネル間でのパッケージのコピー

- 43.7.7 チャネルへのカスタム・パッケージの追加

- 43.7.7.1 カスタム・パッケージをチャネルに追加するための前提条件

- 43.7.7.2 チャネルへのカスタム・パッケージの追加

- 43.7.8 パッケージ・チャネルの削除

- 43.7.8.1 パッケージ・チャネルを削除するための前提条件

- 43.7.8.2 パッケージ・チャネルの削除

第X部 構成、コンプライアンスおよび変更管理

44 構成情報の管理

- 44.1 構成管理の概要

- 44.2 構成検索の概要

- 44.2.1 構成検索の管理

- 44.2.2 検索の設定

- 44.2.3 検索シナリオの確認

- 44.3 構成ブラウザの概要

- 44.3.1 構成データの表示

- 44.3.2 保存済の構成の処理

- 44.3.3 インベントリと使用状況の詳細の処理

- 44.4 構成履歴の概要

- 44.4.1 構成履歴へのアクセス

- 44.4.2 構成履歴の処理

- 44.4.2.1 履歴の検索

- 44.4.2.2 構成変更への注釈の追加

- 44.4.2.3 履歴検索のスケジュールおよび通知リストの作成

- 44.4.2.4 履歴のファイルへの保存

- 44.4.3 履歴ジョブ・アクティビティの表示

- 44.5 比較とテンプレートの概要

- 44.5.1 比較テンプレートについて

- 44.5.2 比較テンプレートの使用

- 44.5.2.1 比較テンプレートの作成または編集

- 44.5.2.2 比較テンプレートの管理

- 44.5.3 ルールの指定

- 44.5.3.1 値制約ルールの作成

- 44.5.3.2 一致ルールの作成

- 44.5.3.3 包含または除外ルールの作成

- 44.5.4 ルールの式と構文について

- 44.5.5 例によるルールの理解

- 44.5.5.1 一致ルールの例

- 44.5.5.2 包含または除外ルールの例

- 44.5.6 比較について

- 44.5.7 比較ウィザードの理解

- 44.5.7.1 比較対象の構成の選択

- 44.5.7.2 比較する構成の選択

- 44.5.7.3 比較で使用するテンプレートの選択

- 44.5.7.4 システム比較でのメンバーのマッピング

- 44.5.7.5 比較のスケジュールおよび通知リストの作成

- 44.5.7.6 比較パラメータの確認およびジョブの発行

- 44.5.8 比較結果の処理

- 44.5.8.1 比較とジョブ・アクティビティについて

- 44.5.8.2 システム比較結果について

- 44.5.8.3 標準のターゲット比較結果について

- 44.5.8.4 構成ファイルの同期

- 44.6 構成拡張および収集の概要

- 44.6.1 構成拡張の処理

- 44.6.1.1 カスタム・ターゲット・タイプの作成

- 44.6.1.2 構成拡張の作成または編集

- 44.6.1.3 「ファイルとコマンド」タブの使用

- 44.6.1.4 「SQL」タブの使用

- 44.6.1.5 構成拡張の作成時の資格証明の設定

- 44.6.1.6 ルールの設定

- 44.6.1.7 構成拡張の管理

- 44.6.1.8 構成拡張およびバージョニングについて

- 44.6.1.9 構成拡張および権限について

- 44.6.2 構成拡張およびデプロイについて

- 44.6.2.1 構成拡張のデプロイおよびアンデプロイ

- 44.6.2.2 構成拡張のデプロイメントの編集

- 44.6.2.3 構成収集の表示

- 44.6.3 構成データ収集の拡張

- 44.6.3.1 既存のターゲット収集の拡張

- 44.6.3.2 新規ターゲット・データ収集の追加

- 44.6.4 構成拡張のブループリントとしての使用

- 44.7 パーサーの概要

- 44.7.1 パーサーの管理

- 44.7.2 XMLパーサーについて

- 44.7.2.1 デフォルトXMLパーサーについて

- 44.7.2.2 汎用XMLパーサーについて

- 44.7.2.3 XMLパーサーの例

- 44.7.3 フォーマット固有のパーサーについて

- 44.7.3.1 データベース問合せパーサーのパラメータ

- 44.7.3.2 ディレクトリ・パーサーのパラメータ

- 44.7.3.3 E-Business Suiteパーサーのパラメータ

- 44.7.3.4 Galaxy CFGパーサーのパラメータ

- 44.7.3.5 MQ-Seriesパーサーのパラメータ

- 44.7.3.6 Siebelパーサーのパラメータ

- 44.7.3.7 UNIXインストール済パッチ・パーサーのパラメータ

- 44.7.3.8 UNIX再帰的ディレクトリ・リスティング・パーサーのパラメータ

- 44.7.4 列指向パーサーについて

- 44.7.4.1 列指向パーサーのパラメータ

- 44.7.5 プロパティ・パーサーについて

- 44.7.5.1 基本プロパティ・パーサーのパラメータ

- 44.7.5.2 拡張プロパティ・パーサーのパラメータ

- 44.7.5.3 拡張プロパティ・パーサーの構成

- 44.7.6 解析されたファイルおよびルールの使用

- 44.7.6.1 XMLファイルの解析およびルール適用の例

- 44.7.6.2 XML以外のファイルの解析およびルール適用の例

- 44.7.6.3 SQL問合せの解析およびルール適用の例

- 44.8 クライアント構成の概要

- 44.8.1 Cloud Controlのクライアント・システム・アナライザについて

- 44.8.2 クライアント・システム・アナライザの個別デプロイ

- 44.9 関係の概要

- 44.10 構成トポロジ・ビューアの概要

- 44.10.1 構成トポロジ・ビューアについて

- 44.10.2 トポロジの使用例

- 44.10.3 構成トポロジの表示

- 44.10.4 システム・コンポーネント構造の特定

- 44.10.5 ターゲットの構成状態の一般ステータスの確認

- 44.10.6 ターゲットの構成状態/コンプライアンス・スコアの取得

- 44.10.7 問題の分析と特定の問題の詳細表示

- 44.10.8 依存性分析について

- 44.10.9 影響分析について

- 44.10.10 カスタム・トポロジ・ビューの作成

- 44.10.11 カスタム・トポロジ・ビューの削除

- 44.10.12 カスタム・トポロジ・ビューからの関係の除外

- 44.10.13 カスタム・トポロジ・ビューにおけるターゲットへの関係の追加

- 44.10.14 ターゲットへの関係の作成

- 44.10.15 ターゲットからの関係の削除

- 44.10.16 構成トポロジ・グラフ上の情報の表示形式の制御

45 コンプライアンスの管理

- 45.1 コンプライアンスの概要

- 45.1.1 コンプライアンスで使用される用語

- 45.1.2 コンプライアンス機能へのアクセス

- 45.1.3 コンプライアンス機能の使用に必要なロールおよび権限

- 45.2 コンプライアンスの評価

- 45.2.1 コンプライアンス統計へのアクセス

- 45.2.1.1 コンプライアンス・ダッシュボードの効率的な使用

- 45.2.2 コンプライアンス・サマリー情報の表示

- 45.2.3 ターゲット・コンプライアンス評価結果の表示

- 45.2.4 コンプライアンス・フレームワークの評価結果の表示

- 45.2.5 違反の管理

- 45.2.6 コンプライアンス違反および評価結果の調査

- 45.2.6.1 リポジトリのコンプライアンス標準ルールの違反および違反の原因となるターゲットの調査

- 45.2.6.2 エンタープライズについて報告されたすべての違反の表示

- 45.2.6.3 違反の表示の例

- 45.2.7 評価エラーの調査

- 45.2.8 コンプライアンス・レポートの分析

- 45.2.9 コンプライアンス・スコアおよび重要度の概要

- 45.2.9.1 コンプライアンス標準ルールのコンプライアンス・スコア - ターゲット

- 45.2.9.2 リアルタイム監視ルールのコンプライアンス・スコア

- 45.2.9.3 ターゲットのコンプライアンス標準のコンプライアンス・スコア

- 45.2.9.4 コンプライアンス・フレームワークのコンプライアンス・スコア

- 45.2.9.5 親ノードのコンプライアンス・スコア

- 45.3 リアルタイム監視の調査

- 45.3.1 監視の表示

- 45.3.1.1 システム別の監視の表示

- 45.3.1.2 コンプライアンス・フレームワーク別の監視の表示

- 45.3.1.3 検索別の監視の表示

- 45.3.1.4 インシデントの詳細の表示

- 45.3.2 コンプライアンス評価時の監視の操作

- 45.3.2.1 監視の認証済または非認証への手動設定

- 45.3.2.2 監視が発生した場合のユーザーへの通知

- 45.3.2.3 認証された監視が発生した場合のユーザーへの通知

- 45.4 コンプライアンス管理の構成

- 45.4.1 コンプライアンス・フレームワークについて

- 45.4.2 コンプライアンス・フレームワークでの操作

- 45.4.2.1 コンプライアンス・フレームワークの作成

- 45.4.2.2 コンプライアンス・フレームワークの類似作成

- 45.4.2.3 コンプライアンス・フレームワークの編集

- 45.4.2.4 コンプライアンス・フレームワークの削除

- 45.4.2.5 コンプライアンス・フレームワークのエクスポート

- 45.4.2.6 コンプライアンス・フレームワークのインポート

- 45.4.2.7 コンプライアンス・フレームワークの参照

- 45.4.2.8 コンプライアンス・フレームワークの検索

- 45.4.2.9 コンプライアンス・フレームワークの評価結果の参照

- 45.4.2.10 コンプライアンス・フレームワークの評価結果の検索

- 45.4.2.11 コンプライアンス・フレームワークのエラーの参照

- 45.4.2.12 コンプライアンス・フレームワークのエラーの検索

- 45.4.2.13 データベース・ターゲットがコンプライアンス・フレームワークに準拠していることの検証

- 45.4.3 コンプライアンス標準について

- 45.4.4 コンプライアンス標準での操作

- 45.4.4.1 コンプライアンス標準の作成

- 45.4.4.2 コンプライアンス標準の類似作成

- 45.4.4.3 コンプライアンス標準の編集

- 45.4.4.4 コンプライアンス標準の削除

- 45.4.4.5 コンプライアンス標準のエクスポート

- 45.4.4.6 コンプライアンス標準のインポート

- 45.4.4.7 コンプライアンス標準の参照

- 45.4.4.8 コンプライアンス標準の検索

- 45.4.4.9 コンプライアンス標準の評価結果の参照

- 45.4.4.10 コンプライアンス標準の評価結果の検索

- 45.4.4.11 コンプライアンス標準のエラーの参照

- 45.4.4.12 コンプライアンス標準のエラーの検索

- 45.4.4.13 コンプライアンス標準のターゲットへの関連付け

- 45.4.4.14 リアルタイム監視コンプライアンス標準の警告の表示

- 45.4.4.15 セキュリティ・メトリックの有効化

- 45.4.4.16 コンプライアンス標準の作成時の考慮事項

- 45.4.5 コンプライアンス標準ルール・フォルダについて

- 45.4.5.1 ルール・フォルダの作成

- 45.4.5.2 コンプライアンス標準内のルール・フォルダの管理

- 45.4.6 コンプライアンス標準ルールについて

- 45.4.7 コンプライアンス標準ルールでの操作

- 45.4.7.1 リポジトリのコンプライアンス標準ルールの作成

- 45.4.7.2 WebLogic Serverの署名のコンプライアンス標準ルールの作成

- 45.4.7.3 リアルタイム監視のコンプライアンス標準ルールの作成

- 45.4.7.4 エージェント側ルールの作成

- 45.4.7.5 手動ルールの作成

- 45.4.7.6 コンプライアンス標準ルールの類似作成

- 45.4.7.7 コンプライアンス標準ルールの編集

- 45.4.7.8 コンプライアンス標準ルールの削除

- 45.4.7.9 コンプライアンス標準ルールのエクスポート

- 45.4.7.10 コンプライアンス標準ルールのインポート

- 45.4.7.11 コンプライアンス標準ルールの参照

- 45.4.7.12 コンプライアンス標準ルールの検索

- 45.4.7.13 Oracle提供のコンプライアンス標準ルール

- 45.5 リアルタイム監視ファセット

- 45.5.1 リアルタイム監視ファセットについて

- 45.5.1.1 ファセット・エンティティ・タイプ

- 45.5.1.2 ファセット・パターン

- 45.5.2 ファセットでの操作

- 45.5.2.1 ファセット・ライブラリの表示

- 45.5.2.2 ファセットの作成および編集

- 45.5.2.3 ファセット・フォルダの作成および編集

- 45.5.2.4 ファセットの削除

- 45.5.2.5 「類似作成」を使用した新規ファセットの作成

- 45.5.2.6 ファセットのインポートおよびエクスポート

- 45.5.2.7 ルールでまだ使用されていないベース・ファセット属性の変更

- 45.6 例

- 45.6.1 カスタム構成収集に基づくリポジトリ・ルールの作成

- 45.6.2 コンプライアンス標準エージェント側のルールおよび手動ルールの作成

- 45.6.3 違反の抑止

- 45.6.4 違反のクリア

46 Enterprise Data Governanceの管理

- 46.1 Enterprise Data Governanceの概要

- 46.1.1 Enterprise Data Governanceについて

- 46.1.2 保護ポリシーとは

- 46.1.3 アプリケーション署名とは

- 46.2 Enterprise Data Governanceの使用

- 46.2.1 Enterprise Data Governanceダッシュボード

- 46.2.2 機密データベースの検出結果の処理

- 46.2.3 メタデータ検出ジョブの処理

- 46.2.3.1 メタデータ検出ジョブの作成

- 46.2.3.2 自動メタデータの検出の管理

- 46.2.3.3 メタデータの検出結果の管理

- 46.2.4 データ検出ジョブの処理

- 46.2.4.1 データ検出ジョブの作成

- 46.2.4.2 データの検出結果の管理

- 46.2.5 カスタム・アプリケーション署名の作成

47 データベース・スキーマ変更の管理

- 47.1 データベースの変更管理の概要

- 47.2 スキーマ・ベースラインの使用

- 47.2.1 有効範囲指定の概要

- 47.2.2 スキーマ・ベースライン・バージョンの取得について

- 47.2.3 単一のスキーマ・ベースライン・バージョンの操作について

- 47.2.4 複数のスキーマ・ベースライン・バージョンの操作について

- 47.2.5 スキーマ・ベースラインのエクスポートおよびインポート

- 47.2.5.1 エクスポートおよびインポートのためのディクショナリ・オブジェクトの作成

- 47.3 スキーマの比較の使用

- 47.3.1 スキーマの比較の定義

- 47.3.2 スキーマの比較バージョンの操作について

- 47.4 スキーマの同期化の使用

- 47.4.1 スキーマの同期化の定義について

- 47.4.2 比較からの同期化定義の作成

- 47.4.3 スキーマの同期化バージョンの操作

- 47.4.3.1 スキーマの同期化サイクルについて

- 47.4.4 追加の同期化バージョンの作成

- 47.5 変更計画の使用

- 47.5.1 変更計画の使用について

- 47.5.2 変更計画の作成

- 47.5.2.1 スキーマ比較からの変更計画の作成および適用

- 47.5.2.2 外部クライアントを使用したCloud Controlでの変更計画の作成およびアクセス

- 47.5.3 SQL Developerインタフェースからのスキーマ変更計画の発行

- 47.6 データベース・データ比較の使用

- 47.6.1 データベース・データ比較の要件

- 47.6.2 データベース・データの比較および結果の表示

48 リアルタイム監視の追加設定

- 48.1 リアルタイム監視の概要

- 48.2 リソース消費に関する考慮事項の概要

- 48.2.1 OSファイル監視のアーカイブ

- 48.2.2 OSファイル読取りの監視

- 48.2.3 対象範囲が非常に大きいファセットの作成

- 48.2.4 Cloud Controlのリポジトリ・サイジング

- 48.3 監視資格証明の構成

- 48.4 Linuxホストを監視する準備

- 48.4.1 OSファイル監視

- 48.4.2 カーネル・モジュールまたは他のファイル監視の問題のデバッグ

- 48.5 Windowsホストを監視する準備

- 48.5.1 監査が適切に構成されているかの確認

- 48.5.2 外部subinaclの要件

- 48.6 Solarisホストを監視する準備

- 48.6.1 BSM監査の有効化

- 48.6.1.1 Solarisバージョン9および10を使用したBSM監査の有効化

- 48.6.1.2 Solaris 11を使用したBSM監査の有効化

- 48.6.2 監査ログ・ファイルの管理

- 48.7 AIXホストを監視する準備

- 48.7.1 AIX 5.3のインストール前提条件

- 48.7.2 AIX監査の管理

- 48.7.3 OSユーザー監視モジュールのAIXシステム・ログ・ファイルの検証

- 48.8 Oracleデータベースを監視する準備

- 48.8.1 監査ユーザー権限の設定

- 48.8.2 監査オプションの指定

- 48.9 変更リクエスト管理の統合の設定

- 48.9.1 BMC Remedy Action Request System 7.1の統合

- 48.9.1.1 Remedy ARSのインストールおよびカスタマイズ

- 48.10 リアルタイム監視機能に関連するリポジトリ・ビューの概要

- 48.11 データ保存期間の変更

- 48.12 リアルタイム監視がサポートされるプラットフォーム

- 48.12.1 OSユーザーの監視

- 48.12.2 OSプロセスの監視

- 48.12.3 OSファイルの監視

- 48.12.4 OS Windowsレジストリの監視

- 48.12.5 OS Windows Active Directoryユーザーの監視

- 48.12.6 OS Windows Active Directoryコンピュータの監視

- 48.12.7 OS Windows Active Directoryグループの監視

- 48.12.8 Oracle Database表の監視

- 48.12.9 Oracle Databaseビューの監視

- 48.12.10 Oracle Databaseマテリアライズド・ビューの監視

- 48.12.11 Oracle Database索引の監視

- 48.12.12 Oracle Database順序の監視

- 48.12.13 Oracle Databaseプロシージャの監視

- 48.12.14 Oracle Databaseファンクションの監視

- 48.12.15 Oracle Databaseパッケージの監視

- 48.12.16 Oracle Databaseライブラリの監視

- 48.12.17 Oracle Databaseトリガーの監視

- 48.12.18 Oracle Database表領域の監視

- 48.12.19 Oracle Databaseクラスタの監視

- 48.12.20 Oracle Databaseリンクの監視

- 48.12.21 Oracle Databaseディメンションの監視

- 48.12.22 Oracle Databaseプロファイルの監視

- 48.12.23 Oracle Databaseパブリック・リンクの監視

- 48.12.24 Oracle Databaseパブリック・シノニムの監視

- 48.12.25 Oracle Databaseシノニムの監視

- 48.12.26 Oracle Databaseタイプの監視

- 48.12.27 Oracle Databaseロールの監視

- 48.12.28 Oracle Databaseユーザーの監視

- 48.12.29 Oracle Database SQL問合せ文の監視

49 変更アクティビティ・プランナの概要

- 49.1 開始する前に

- 49.1.1 変更アクティビティ・プランナのロールおよび権限

- 49.1.2 変更アクティビティ・プランナで使用される用語

- 49.1.2.1 計画

- 49.1.2.2 タスク定義

- 49.1.2.3 タスク・グループ

- 49.1.2.4 タスク

- 49.2 変更アクティビティ計画の作成

- 49.2.1 タスク定義の作成

- 49.2.2 タスク・グループの作成

- 49.3 変更アクティビティ計画での操作

- 49.3.1 他の計画と類似の計画の作成

- 49.3.2 計画の編集

- 49.3.3 計画の削除

- 49.3.4 計画の非アクティブ化

- 49.3.5 計画のエクスポート

- 49.3.6 計画の印刷

- 49.3.7 計画の所有者の変更

- 49.4 変更アクティビティ計画の管理

- 49.4.1 「サマリー」タブ

- 49.4.2 「タスク」タブ

- 49.4.3 「コメントおよび監査証跡」タブ

- 49.5 マイ・タスクの表示

- 49.6 変更アクティビティ・プランナの使用例

- 49.6.1 アクティビティ計画の自動化

- 49.6.2 アクティビティ計画の自動化の追加手順

- 49.6.3 変更アクティビティ・プランナを使用したパッチ適用の例

第XI部 デプロイメント・プロシージャ

50 デプロイメント・プロシージャについて

- 50.1 「プロビジョニング」ページの概要

- 50.2 ロールと権限の管理者への付与

- 50.2.1 デプロイメント・プロシージャに関するロールと権限の管理者への付与

- 50.2.2 ソフトウェア・ライブラリに関するロールと権限の管理者への付与

- 50.3 プロシージャのコンポーネント

- 50.3.1 ターゲット・リスト

- 50.3.2 プロシージャ変数

- 50.3.3 フェーズおよびステップ

- 50.3.3.1 フェーズのタイプ

- 50.3.3.2 プロシージャ・ステップのタイプ

- 50.3.3.3 プロシージャ・ステップでのタスクの実行

- 50.4 プロシージャの作成

- 50.4.1 ローリング・フェーズまたはパラレル・フェーズの追加

- 50.4.2 ステップの追加

- 50.5 デプロイメント・プロシージャの管理

- 50.5.1 プロシージャの表示、編集、削除

- 50.5.2 プロシージャの権限の編集と保存

- 50.5.3 プロシージャの実行およびデプロイメント・プロシージャ・ステータスの追跡

- 50.5.4 プロシージャの再スケジュール

- 50.5.5 プロシージャの回復

- 50.5.6 ステップ・レベルの猶予期間の設定

- 50.6 ユーザー定義デプロイメント・プロシージャ(UDDP)の作成、保存および起動

- 50.6.1 ステップ1: ユーザー定義デプロイメント・プロシージャの作成

- 50.6.2 ステップ2: デフォルト入力のユーザー定義デプロイメント・プロシージャの保存と起動

- 50.6.2.1 ロック・ダウンを含むデプロイメント・プロシージャの保存と起動

- 50.6.3 ステップ3: 保存されているユーザー定義デプロイメント・プロシージャの起動と実行

- 50.6.4 ステップ4: 発行したユーザー定義デプロイメント・プロシージャの追跡

- 50.7 プロシージャ・インスタンス実行ページ

- 50.7.1 新旧のプロシージャ・インスタンスの実行ページの設計の比較

- 50.7.2 プロシージャ・インスタンス実行ページの概要

- 50.7.3 単一または一連のターゲットの失敗したステップの調査

- 50.7.4 失敗したステップの再試行

- 50.7.5 インシデントの作成

- 50.7.6 デプロイメント・プロシージャの実行時間の表示

- 50.7.7 ステップの検索

- 50.7.8 ステップ出力のダウンロード

- 50.7.9 「ジョブ・サマリー」ページヘのアクセス

51 デプロイメント・プロシージャのカスタマイズ

- 51.1 デプロイメント・プロシージャのカスタマイズ・タイプについて

- 51.2 デプロイメント・プロシージャのカスタマイズ

- 51.2.1 デプロイメント・プロシージャのローリングおよびパラレル・フェーズの編集

- 51.2.2 デプロイメント・プロシージャのジョブ・ステップの編集

- 51.2.3 デプロイメント・プロシージャのディレクティブ・ステップの編集

- 51.2.4 デプロイメント・プロシージャのコンポーネント・ステップの編集

- 51.2.5 デプロイメント・プロシージャのファイル転送ステップの編集

- 51.2.6 デプロイメント・プロシージャのホスト・コマンド・ステップの編集

- 51.2.7 デプロイメント・プロシージャの手動ステップの編集

- 51.3 実行時にデプロイメント・プロシージャ変数に値を割り当てるためのワークフロー例

- 51.3.1 ステップ1: 実行時にデプロイメント・プロシージャ変数に値を割り当てるPerlスクリプトの作成

- 51.3.2 ステップ2: ソフトウェア・ライブラリへのTestPingAndDPvariable.plのアップロード

- 51.3.3 ステップ3: デプロイメント・プロシージャの作成

- 51.3.4 ステップ4: プロシージャの起動および実行時の変数値の入力

- 51.3.5 ステップ5: デプロイメント・プロシージャ変数値の確認

- 51.4 デプロイメント・プロシージャのエラー処理モードの変更

- 51.5 デプロイメント・プロシージャのステータスに関する電子メール通知の設定

- 51.5.1 Enterprise Managerでの送信メール(SMTP)サーバーの構成

- 51.5.2 Enterprise Manager通知用の電子メール・アドレスの追加

- 51.6 カスタマイズしたプロビジョニング・エンティティをEnterprise Managerサイト間でコピー

- 51.6.1 カスタマイズしたプロビジョニング・エンティティをEnterprise Managerサイト間でコピーするための前提条件

- 51.6.2 カスタマイズしたプロビジョニング・エンティティをEnterprise Managerサイト間でコピー

- 51.7 ディレクティブをカスタマイズするためのワークフロー例

- 51.7.1 デフォルト・ディレクティブのコピーの作成とアップロード

- 51.7.2 新しいディレクティブを使用するデプロイメント・プロシージャのカスタマイズ

- 51.7.3 カスタマイズされたデプロイメント・プロシージャの実行

第XII部 追加情報

A Enterprise Managerコマンドライン・インタフェースの使用

- A.1 概要

- A.2 前提条件

- A.3 Enterprise Managerコマンドライン・インタフェース動詞

- A.3.1 プロビジョニングのEM CLI動詞

- A.3.1.1 新しいEnterprise Managerコマンドライン・インタフェース動詞

- A.3.1.2 不要なEnterprise Managerコマンドライン・インタフェース動詞

- A.3.1.3 プロシージャを実行するEnterprise Managerコマンドライン・インタフェース動詞

- A.3.2 パッチ適用のEM CLI動詞

- A.3.3 ソフトウェア・ライブラリのEM CLI動詞

- A.4 EM CLIを使用するプロビジョニング

- A.4.1 デプロイメント・プロシージャを発行するためのプロパティ・ファイルの作成

- A.4.2 すでに実行したデプロイメント・プロシージャのプロパティ・ファイルの使用

- A.4.3 既存の保存プロシージャを使用するプロシージャの起動

- A.4.3.1 プロシージャのプロシージャ構成の保存

- A.4.3.2 プロシージャのプロシージャ構成の更新

- A.4.4 プラガブル・データベースのプロビジョニング

- A.4.4.1 新しいプラガブル・データベースの作成

- A.4.4.2 スナップショット・プロファイルを使用したプラガブル・データベースのプロビジョニング

- A.4.4.3 非コンテナ・データベースのプラガブル・データベースとしての移行

- A.4.4.4 プラガブル・データベースの切断および削除

- A.5 EM CLIを使用するパッチ適用

- A.5.1 パッチ適用を開始する前に

- A.5.2 EM CLIを使用するパッチ適用

- A.5.2.1 パッチ適用ターゲットの新規プロパティ・ファイルの作成

- A.5.2.2 既存のパッチ計画のプロパティ・ファイルを使用してターゲットにパッチを適用

- A.6 EM CLIコマンドを使用するワークフローの例

- A.6.1 Oracleデータベース・ソフトウェアのプロビジョニング

- A.6.2 Oracle WebLogic Serverのプロビジョニング

- A.6.2.1 Oracle WebLogic Serverをプロビジョニングするための前提条件

- A.6.2.2 プロビジョニング・プロファイルを使用したOracle WebLogic Serverのプロビジョニング

- A.6.2.3 ミドルウェア・デプロイメント・プロシージャのスケール・アップまたはスケール・アウト

- A.6.3 ユーザー定義デプロイメント・プロシージャのプロビジョニング

- A.6.3.1 ユーザー定義デプロイメント・プロシージャをプロビジョニングするための前提条件

- A.6.3.2 GUIを使用したユーザー定義デプロイメント・プロシージャへのステップとフェーズの追加

- A.6.3.3 プロシージャのインスタンスを実行するためのEM CLIコマンドの使用

- A.6.4 WebLogic Serverターゲットへのパッチ適用

- A.6.5 ZIPファイルの関連付けによる新規汎用コンポーネントの作成

- A.6.5.1 ステップ1: ソフトウェア・ライブラリでの親フォルダの特定

- A.6.5.2 ステップ2: 汎用コンポーネント・エンティティの作成

- A.6.5.3 ステップ3: 汎用コンポーネントへのZIPファイルの関連付け

- A.6.5.4 ステップ4: 新規作成したエンティティの検証

- A.6.6 ソフトウェア・ライブラリの記憶域の場所の移行および削除

- A.6.6.1 ステップ1: ファイルを移行する宛先記憶域の場所の追加

- A.6.6.2 ステップ2: 既存の記憶域の場所の移行および削除

- A.6.7 ATSサービス・テストでのEM CLIの使用の追加

- A.6.8 Java EEアプリケーションのデプロイおよびアンデプロイ

- A.7 Enterprise Managerコマンドライン・インタフェースの使用に関する制限事項

B プロビジョニング前またはパッチ適用前のホスト準備状況のチェック

- B.1 プロビジョニング前のユーザー・アカウントの設定

- B.1.1 SSHの構成

- B.2 シェル制限

- B.3 rootの設定(権限の委任)

- B.4 環境設定

- B.4.1 カーネル要件

- B.4.2 ノード時刻要件

- B.4.3 パッケージ要件

- B.4.4 メモリーおよびディスク領域の要件

- B.4.5 ネットワークおよびIPアドレスの要件

- B.5 記憶域要件

- B.6 インストール・ディレクトリとOracleインベントリ

C emctl partoolユーティリティの使用

- C.1 プロビジョニング・アーカイブ・ファイルの概要

- C.2 emctl partoolユーティリティの概要

- C.3 Oracleソフトウェア・ライブラリのチェック

- C.4 デプロイメント・プロシージャのエクスポート

- C.4.1 デプロイメント・プロシージャのGUIDの取得

- C.4.2 PARファイルの作成

- C.5 PARファイルのインポート

- C.5.1 コマンドライン・インタフェースを使用したインポート

- C.5.1.1 特定のPARファイルのインポート

- C.5.1.2 すべてのPARファイルのインポート

- C.5.2 Cloud Controlコンソールを使用したインポート

D PXEブートおよびKickstartテクノロジについて

- D.1 PXEブートとKickstartテクノロジの概要

- D.2 サブネット・プロビジョニングのユースケース

E エンドツーエンド・ユースケース: データ・センターのパッチ適用

- E.1 データ・センターへのパッチ適用の課題

- E.2 Enterprise Managerソリューション

- E.2.1 データ・センターに関連するパッチの特定

- E.2.2 パッチの公開計画の準備、テストおよび認定

- E.2.3 パッチを公開するための変更アクティビティ計画の作成

- E.2.4 変更アクティビティの進捗の監視とステータスの報告

- E.3 サンプル・シナリオの実行

- E.3.1 必要なロールを持つ管理者の作成

- E.3.2 インフラストラクチャの設定

- E.3.3 環境の分析およびターゲットにパッチを適用できるかどうかの確認

- E.3.4 関連するパッチの特定

- E.3.5 パッチ計画の作成、パッチのテストおよびパッチの認定

- E.3.6 パッチを公開するための変更アクティビティ計画の作成

- E.3.7 パッチの公開

- E.3.8 変更アクティビティのステータスのチェックおよび報告

- E.3.9 ターゲットでのパッチ適用の確認

F 問題のトラブルシューティング

- F.1 データベース・プロビジョニングの問題のトラブルシューティング

- F.1.1 グリッド・インフラストラクチャ・ルート・スクリプトのエラー

- F.1.1.1 問題

- F.1.1.2 説明

- F.1.1.3 解決策

- F.1.2 デプロイメント・プロシージャ実行中のSUDOエラー

- F.1.2.1 問題

- F.1.2.2 説明

- F.1.2.3 解決策

- F.1.3 前提条件チェックのエラー

- F.1.3.1 問題

- F.1.3.2 原因

- F.1.3.3 解決策

- F.1.4 Oracle Automatic Storage Management (Oracle ASM)ディスク作成の失敗

- F.1.4.1 問題

- F.1.4.2 原因

- F.1.4.3 解決策

- F.1.5 Oracle ASMディスク権限のエラー

- F.1.5.1 問題

- F.1.5.2 説明

- F.1.5.3 解決策

- F.1.6 データ・プロビジョニング用のカスタム一時ディレクトリの指定

- F.1.7 デプロイメント・プロシージャが失敗した際のインシデントの作成

- F.1.7.1 問題

- F.1.7.2 解決策

- F.1.8 リモート・ログ・ファイルの読取り

- F.1.9 失敗したジョブの再試行

- F.1.9.1 問題

- F.1.9.2 解決策

- F.2 パッチ適用の問題のトラブルシューティング

- F.2.1 Oracleソフトウェア・ライブラリの構成の問題

- F.2.1.1 ファイルをステージングするときに発生するエラー

- F.2.1.2 パッチ・セットをアップロードするときに発生するエラー

- F.2.1.3 重複ディレクトリがソフトウェア・ライブラリで検出された場合のOPatchの更新ジョブの失敗

- F.2.2 My Oracle Supportの接続の問題

- F.2.2.1 ダイジェスト認証のみをサポートするプロキシ・サーバーのテスト中のエラー発生

- F.2.3 ホストおよびOracleホームの資格証明の問題

- F.2.3.1 通常Oracleホーム資格証明として特権資格証明を設定するとログ・ファイルを作成できない

- F.2.4 収集の問題

- F.2.4.1 計画のウィザードに詳細が表示されない

- F.2.4.2 ターゲットをパッチ計画に追加できない

- F.2.5 パッチ推奨の問題

- F.2.5.1 Oracle ExadataターゲットでのOracle Management Agentインストール後にパッチ推奨が表示されない

- F.2.6 パッチ計画の問題

- F.2.6.1 パッチ計画がデプロイできなくなり失敗する

- F.2.6.2 移行されないインスタンスも移行の影響を受けるターゲットとして表示される

- F.2.6.3 クラスタウェア・ターゲットのパッチ適用中に影響を受けるターゲットとしてクラスタASMとそのインスタンスが表示されない

- F.2.6.4 部分的に準備された計画のリカバリ

- F.2.6.5 パッチ計画の作成または編集時に計画の作成ウィザードに「エラー#1009」が表示される

- F.2.6.6 分析が成功したが「デプロイ」ボタンが無効になる

- F.2.6.7 パッチ計画名が64バイトを超えるとパッチ計画が失敗する

- F.2.6.8 11.2.0.3 Exadataクラスタウェアのホーム外パッチ適用が失敗する

- F.2.7 パッチ計画の分析の問題

- F.2.7.1 デプロイメント・プロシージャが終了してもパッチ計画の状態が「分析」から変わらない

- F.2.7.2 ホストのノード名プロパティがない場合にパッチ計画の分析が失敗する

- F.2.7.3 分析の詳しい進捗を表示するリンクが機能しない

- F.2.7.4 分析エラーの問題を解決できない場合のサービス・リクエストの発行

- F.2.8 ユーザー・アカウントとロールの問題

- F.2.8.1 パッチ・デザイナとパッチ・オペレータが必要な権限を持たない場合のホーム外パッチ適用エラー

- F.3 Linuxでのパッチ適用問題のトラブルシューティング

- F.4 Linuxプロビジョニングの問題のトラブルシューティング

- F.5 Linuxプロビジョニングのよくある質問

- F.6 構成のリフレッシュ

- F.6.1 ホスト構成のリフレッシュ

- F.6.2 Oracleホーム構成のリフレッシュ

- F.7 ログ・ファイルの確認

- F.7.1 OMS関連のログ・ファイル

- F.7.2 管理エージェント関連のログ・ファイル

- F.7.3 拡張オプション

- F.7.3.1 OMS側

- F.7.3.2 管理エージェント側

索引

はじめに

ライフサイクル管理ガイドでは、Oracle Enterprise Manager Cloud Control (Cloud Control)によって提供されるライフサイクル管理ソリューションの概要を示し、検出、プロビジョニング、パッチ適用、構成管理およびコンプライアンス管理の機能を使用してデータ・センターを管理する方法について詳細に説明します。

対象読者

このガイドは、Cloud Controlによって提供される検出、プロビジョニング、パッチ適用、構成管理およびコンプライアンス管理の機能を使用してライフサイクル管理の作業を行う管理者を主に対象としています。管理者は、システム管理者の職務を担い、クリティカルなデータ・センター作業を行うデザイナ、またはデフォルトやカスタムのデプロイメント・プロシージャ、パッチ計画およびパッチ・テンプレートを実行してエンタープライズ構成を管理するオペレータのいずれかです。

対象範囲

Oracle Enterprise Manager Cloud Controlライフサイクル管理ガイドでは、次のプラグインおよびプラットフォーム・リリースに関連する機能について説明します。

- Oracle Databaseプラグイン(12.1.0.8)

- Oracle Fusion Middlewareプラグイン(12.1.0.8)

- Oracle My Oracle Supportプラグイン(12.1.0.5)

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)

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

オラクル社のアクセシビリティへの取組みの詳細は、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 (聴覚障害者向け)を参照してください。

関連ドキュメント

詳細は、Cloud Controlのドキュメント・ライブラリ内にある次の資料を参照してください。

- 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』

- 『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』

- 『Oracle Enterprise Manager Cloud Controlアップグレード・ガイド』

- 『Oracle Enterprise Manager Cloud Control管理者ガイド』

前述のドキュメントおよびその他のOracleドキュメントの最新リリースについては、次のURLのOracle Technology Networkを確認してください。

http://www.oracle.com/technetwork/indexes/documentation/index.html

また、Cloud Controlには詳細なオンライン・ヘルプも用意されています。Enterprise Managerには詳細なオンライン・ヘルプも用意されています。

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

マニュアルのタイトル、強調、またはユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

その他のグラフィック

特定の概念やプロセスがわかりやすくなるようテキストの説明以外にグラフィックが広範に使用されています。

本ガイドの改訂内容

追加されたソフトウェア・リリースまたはパッチ・セット・リリースに対する本ガイドの更新に加え、Oracleでは本ガイドを定期的に改訂し、バグ修正およびカスタマ、製品マネージャ、サポート・チーム、その他主要な関係者からの付加価値のあるフィードバックを追記しています。本ガイドを改訂するたびに、改訂番号は1ずつ増え、Oracle Technology Network (OTN)で公開されます。

注意:
このガイドのMiddlewareプロビジョニングの部分(第I部)は、Fusion Middlewareプラグイン・リリース12.1.0.7を使用したOracle Enterprise Manager Cloud Control 12cリリース4に適用できます。以前のバージョンを使用している場合、自己更新を使用したアップグレードを考慮してください。
このガイドのデータベース・プロビジョニングの部分(第I部)は、データベース・プラグイン・リリース12.1.0.7を使用したOracle Enterprise Manager Cloud Control 12cリリース4に適用できます。以前のバージョンを使用している場合、自己更新を使用したアップグレードを考慮してください。

この章は、最新の改訂版(B66837-13)に追加された変更内容および『Oracle Enterprise Managerライフサイクル管理ガイド』(本ガイド)の以前のすべての改訂内容をリストしています。最新のリビジョン(B66837-13)とはOTNに公開されている現在のリビジョンであり、最新のリビジョンには以前のリビジョンで反映されたすべての変更が常に含まれていることに留意してください。

この章の具体的な内容は次のとおりです。

- 最新の改訂版に追加された変更内容(公開済)

- 以前の改訂版に追加された変更内容(アーカイブ)

最新の改訂版に追加された変更内容(公開済)

OTNに公開されている最新の改訂版(B66837-13)に追加された変更内容は、次のとおりです。

部、章または項

変更内容の説明

Hybrid Cloud (Oracle PaaS)でのクローニング・ソリューション

この新しい章では、コマンドライン・インタフェースおよびクローン・ウィザードを使用してソリューションをOracle Cloudにクローニングする方法について説明します。ユースケースは、Oracle Cloudへのクローニング、Oracle Cloudからのクローニング、およびOracle Cloud内でのクローニングで構成されています。

Oracleデータベースおよびプラガブル・データベースのクローニング

この章では、コマンドライン・インタフェースおよびクローン・ウィザードを使用してフル・クローン・データベース、フル・クローン・プラガブル・データベース、テスト・マスター・データベースおよびテスト・マスター・プラガブル・データベースを作成する方法について説明します。

以前の改訂版に追加された変更内容(アーカイブ)

次の項では、以前の改訂で追加された変更内容が説明されています。これらの改訂はアーカイブされているため、現在OTNで利用できません。

OTNに公開されている最新の改訂版(E27046-30)に追加された変更内容は、次のとおりです。

部、章または項

変更内容の説明

SOAドメインおよびOracleホームのプロビジョニング

SOAドメイン/Oracleホームのプロビジョニングに関する情報は、本章に含まれています。

Oracle Service BusドメインおよびOracleホームのプロビジョニング

OSBドメイン/Oracleホームのプロビジョニングに関する情報は、本章に含まれています。

Oracle WebCenterドメインおよびOracleホームのプロビジョニング

WebCenterドメイン/Oracleホームのプロビジョニングに関する情報は、本章に含まれています。

EM CLIを使用したMiddlewareプロビジョニング

コマンドライン・インタフェースを使用したミドルウェア・プロファイルの作成およびプロビジョニングに関する情報は、本章に含まれています。

REST APIを使用したミドルウェア・プロファイル

REST APIを使用したミドルウェア・プロファイルの作成、説明、リストおよび削除に関する情報は、本章に含まれています。

OTNに公開されている最新の改訂版(B66837-10)に追加された変更内容は、次のとおりです。

部、章または項

変更内容の説明

エンドツーエンド・ユースケース: データ・センターのパッチ適用

Enterprise Managerを使用して管理者がデータ・センター全体にパッチを公開する方法を説明する新しい付録が追加されています。

OTNに公開されている最新の改訂版(E27046-26)に追加された変更内容は、次のとおりです。

部、章または項

変更内容の説明

資格証明の設定

ほとんどの内容は『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』に移動し、セキュリティ・ガイド内で関連する項を指し示すために必要なトピックIDが追加されました。

パッチ適用にサポートされているターゲットおよびリリース

Oracle WebLogic Server 12c リリース1 (12.1.3)、Oracle SOA Infrastructure 11g リリース1 (11.1.1.7.0)およびOracle SOA Infrastructure 12c リリース1 (12.1.3.0.0)も、パッチ適用にサポートされています。これらのターゲット・バージョンが、パッチ適用にサポートされているターゲットおよびリリースのリストに追加されています。

E27046-25に追加された変更内容

OTNに公開されている最新の改訂版(E27046-25)に追加された変更内容は、次のとおりです。

部、章または項

変更内容の説明

パッチ計画の分析、準備およびデプロイ

Oracle Management Agent (管理エージェント)のパッチ適用に必要な資格証明の情報が、この項に追加されています。セキュアな管理エージェント・ターゲットにパッチを適用する際に、通常のOracleホーム資格証明を指定する必要はありません。

パッチ計画の分析、準備およびデプロイ

パッチを適用するルート・コンポーネントのステージングに関する情報が、この項に追加されています。

パッチを適用するルート・コンポーネントの手動によるステージング

これは、新しい項です。パッチを適用するルート・コンポーネントを手動でステージングする方法について説明しています。

パッチ適用のためのルート・ユーザー・アクセスの制限

これは、新しい項です。ここでは、管理エージェント・ユーザーに対する制限されたrootアクセス権の指定方法について説明していて、この方法により管理エージェント・ユーザーがrootとして実行できるコマンドは、すべてのコマンドではなく特定のコマンドのみを実行できます。

E27046-22に追加された変更内容

部、章または項

変更内容の説明

Middlewareプロビジョニングの概要

ミドルウェア・プロビジョニング・エリアの概要を説明する章が追加されました。

ホストおよびソフトウェア・デプロイメントの検出

以前は、この章は「ソフトウェア・デプロイメントの検出」と呼ばれていました。章のタイトルが更新されています。

E27046-21に追加された変更内容

パッチ、章または項

変更内容の説明

ホスト管理

この部には、次の章が追加されています。

- ホスト管理の概要

- ホストを監視するための環境の設定

- ホストの監視環境のカスタマイズ

- ホストの監視

- ホストの管理

構成情報の管理

この章には、次の情報が追加されています。

- 構成レポートの表示(第44.3.1項)

- 比較テンプレートの編集(第44.5.2.1項)

- 通知リストの作成(第44.5.7.5項)

- 構成の差異のレポートの表示(第44.5.8.1項)

コンプライアンスの管理

この章には、次の情報が追加されています。

- エージェント側のルール

- 手動ルール

- 違反の抑止およびクリア

Enterprise Managerコマンドライン・インタフェースの使用

スナップショット・プロファイルを使用したプラガブル・データベースのプロビジョニングの情報が追加されています。

ソフトウェアのデプロイのパッチ適用

この章には、次の情報が追加されています。

- Oracle Data Guardターゲットへのパッチ適用

- Oracle Identity Managementターゲットへのパッチ適用

- Oracle Siebelターゲットへのパッチ適用

- 動的パッチ適用デプロイメント・プロシージャのカスタマイズ

- パッチのスケジューリング(第42.4.3項)

- パッチの通知(第42.4.3項)

Linuxホストへのパッチ適用

この章には、次の情報が追加されています。

- コンプライアンスに基づくLinuxパッチ適用グループへのパッチ適用

- Linuxホストへのアド・ホック・パッチまたは緊急パッチの適用

- 「Linux構成ファイルの管理」の「Linux構成ファイルの概要」

第I部

概要と設定の詳細

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

- 第1章「ライフサイクル管理の概要」

- 第2章「インフラストラクチャの設定」

1 ライフサイクル管理の概要

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

- 新しいライフサイクル管理ソリューションの概要

- ライフサイクル管理ソリューションの情報マップ

注意:
Oracle Enterprise Manager Cloud Controlライフサイクル管理ガイドでは、次のプラグインおよびプラットフォーム・リリースに関連する機能について説明します。

- Oracle Databaseプラグイン(12.1.0.8)

- Oracle Fusion Middlewareプラグイン(12.1.0.8)

- Oracle My Oracle Supportプラグイン(12.1.0.6)

- Enterprise Manager Cloud Control 12cリリース5 (12.1.0.5)

1.1 新しいライフサイクル管理ソリューションの概要

現在の社会において、クラウド・インフラストラクチャを備えた、非常に多くの低コストサーバーとそれらのサーバーに配置されたソフトウェアに、一連のライフサイクル管理上の課題が新たに発生しました。この課題は、既存のソフトウェアのデプロイメントの検出と状態の監視から、新しいソフトウェアのデプロイメントのプロビジョニングや一定期間にわたる保守にまでおよびます。

それに加えて、これらのソフトウェアのデプロイメントおよびオペレーティング・システム間での整合性と互換性の管理、構成変更の管理、コンプライアンスの欠如を引き起こすセキュリティの脆弱性の管理における難しさなどの別の問題があります。

これらのライフサイクル管理上の課題により、結局、人的リソースをより多く必要とし、データ・センター操作の管理に非常の多くの時間を費やさなければならなくなります。

Oracle Enterprise Manager Cloud Control (Cloud Control)は、検出、初期プロビジョニング、クローニング、パッチ適用、構成管理、継続的な変更管理、コンプライアンス管理に関連する、時間のかかるタスクを自動化することで、すべてのライフサイクル管理上の課題に容易に対処することを支援するライフサイクル管理ソリューションです。

図1-1に、Cloud Controlで提供されるライフサイクル管理ソリューションを示します。

図1-1 ライフサイクル管理ソリューション

表1-1で、それぞれのライフサイクル管理ソリューションについて説明します。

表1-1 ライフサイクル管理ソリューション

ソリューション領域

範囲

検出

- IPスキャン技術(NMAP)を使用してソフトウェアのデプロイメントを自動的に検出します。

- 管理されていないソフトウェアのデプロイメントをCloud Controlで管理されるターゲットに変換して、その状態を監視できるようにします。

- Oracle Management Agentのデプロイと、選択した自動検出されたホストでのターゲットの検出に対する統合されたワークフローを提供します。

プロビジョニング

- ベア・メタル・サーバーおよびライブ・ターゲット・サーバーを検出します。

- ベア・メタル・サーバーでLinuxオペレーティング・システムをプロビジョニング(ハイパーバイザーおよび仮想マシン)します。

- パッチ適用テンプレートとプロビジョニングを関連付けて、オペレーティング・システムがプロビジョニングされたらパッチを自動的に適用できるようにします。

- Oracle Database、Oracle Real Application Clusters (Oracle RAC)、Oracle Grid Infrastructure (スタンドアロン・サーバーおよびクラスタ化環境用)、プラガブル・データベースをプロビジョニングします。

- OneCommandユーティリティを介した初期設定およびExadata Databaseマシンに対する継続中のデータベースのプロビジョニングをサポートします。

- Oracle Fusion Middleware、Oracle SOA Suite、SOA Artifacts、Oracle BPEL、Oracle Service Bus、Java EE Applications、Oracle Application Serverをプロビジョニングします。

- 単一インスタンス、Oracle RACおよびOracle RAC Oneデータベース・インスタンスの1つずつの一括アップグレードをサポートします。

パッチ適用

- 推奨へのアクセス、パッチの検索など、My Oracle Supportを使用したパッチ適用の統合されたワークフローを提供します。

- パッチ計画を使用して、デプロイメント・プロシージャの選択の自動化やパッチ競合の分析を含む、パッチ適用のワークフローを編成します。

- 環境におけるパッチの適用性を検証し、パッチ計画を検証し、競合を解決するパッチを自動的に受け取ります。

- ソース・パッチ計画から保存された事前決定済の一連のパッチおよびデプロイメント・オプションを含む、正常に分析されたまたはデプロイ可能なパッチ計画をパッチ・テンプレートとして保存できるようにします。

- ホーム外パッチ適用(スタンドアロン・データベースのみ)、インプレース・パッチ適用、ローリングおよびパラレル・パッチ適用モードを、オフラインおよびオンライン・モードの両方で提供します。

変更管理

- データベース・オブジェクトの定義および初期化パラメータを様々な時点で取得します。

- データベースの比較とベースラインの比較を行います。

- ベースラインまたはデータベースから取得したデータベース定義および初期化パラメータの変更をターゲット・データベースに伝播します。

- グループおよびパッケージのオブジェクト・メタデータの変更を指定します。非定型変更、比較ベースの差異、または開発者ツールから、変更計画を作成します。

- ローカルとリモートのデータベースでデータを比較し、シード・データのカスタマイズがアプリケーションのアップグレードで受ける影響を特定します。

構成管理

- 社内全体にわたって構成データを検索します。

- 1つの管理対象エンティティのコンテキストに、構成データを表示します。構成アイテム・タイプおよびプロパティ、システム構成データ、システム・ターゲット・リレーションシップ、カスタム構成データです。

- 社内全体にわたって変更アクティビティを監視します。これには構成に対する変更と、管理対象エンティティ間に存在する関係であるリレーションシップへの変更の両方が含まれます。

- 比較テンプレートを使用して、特定のターゲット・タイプの構成を比較します。これにより明白な相違を無視し、即時の対応が必要な重要な問題に警告を設定することができます。

- よく知られたターゲット・タイプまたはカスタム構成定義の一部として導入されたターゲット・タイプから、Cloud Controlがまだ収集していないファイルおよびその他の構成データを識別します。青写真と呼ばれるカスタム構成のセットを提供します。これにはApache Tomcatなどの指定されたプラットフォームで収集するファイルおよびデータが正確にレイアウトされます。

- トポロジ・ビューアまたは汎用のシステム・ターゲット・タイプを使用して、管理対象エンティティ間に新しいリレーションシップを作成します。トポロジ・ビューアを使用して、社内のアセットの依存性分析および影響分析を実行できます。

コンプライアンスの管理

- 構成、セキュリティおよび記憶域に対して、企業のベスト・プラクティスに関するターゲットおよびシステムのコンプライアンスを評価します。

- ターゲットおよびシステムをコンプライアンスに提示するために構成を変更する方法をアドバイスします。

- コンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールを定義、カスタマイズおよび管理できます。

- これらの自己定義エンティティを使用して、企業または規制機関に対し定義された条件に則して環境をテストできます。

Enterprise Data Governance

- 機密データが含まれている可能性があるエンタープライズ内のデータベースを特定し、その候補にあるデータを評価して機密データが存在するかどうかを判別するための手段が提供されます。

- メタデータ検出を使用して、保護ポリシーとして知られるセキュリティ機能により保護されているオブジェクトを含むデータベースを特定します。

- 機密データベース候補を、特定のアプリケーションに対して一意のアプリケーション署名や、スキーマ、表およびビューなどの一連のデータベースオブジェクトを特定することで検出します。

- データベース・ターゲットが検出されるごとに、メタデータ検出を自動的に実行します。メタデータ検出ジョブをいつどのように実行するかの制御を強化する場合、この機能を無効にできます。

- 機密データベース候補と新規または既存のアプリケーション・データ・モデル(ADM)を関連付けて、ADMに機密列を設定できます。

変更アクティビティ・プランナ

- データ・センター内の計画、管理および監視の操作を行うことができます。これらの操作には、チームおよびビジネス所有者間の依存性と調整、および複数のプロセスが含まれます。

- 1つ以上のタスクから構成される計画を作成する機能を提供します。タスクは、パッチ・テンプレート、コンプライアンス標準または手動ジョブなどの操作と関連付けることができます。

- すべての管理対象計画を監視できます。これにより、アクティビティ計画の完了期限が遅れる可能性のある問題を特定できます。

- レポート作成に使用できる計画を印刷します。情報には、すべての計画間の全体の要約、指定した計画内の計画に関する要約、計画間のすべてのタスクにわたる全タスク、および指定した計画内のタスク間のタスクに関する要約が含まれています。

注意:
プロビジョニングおよびパッチ管理ソリューションは基本的にデプロイメント・プロシージャに基づいています。これはプロビジョニングおよびパッチ適用タスクを実行できるOracle提供の作成済のプロシージャです。デプロイメント・プロシージャには階層構造になった一連のステップが含まれ、各ステップには一連の他のステップが含まれることもあります。基本的に、そこではプロビジョニングまたはパッチ適用操作のために実行する必要のあるすべてのタスクのワークフローがカプセル化されます。デプロイメント・プロシージャの詳細は、第50章を参照してください。プロビジョニングまたはパッチ適用操作のために使用する必要のあるデフォルトのデプロイメント・プロシージャの詳細は、それぞれの章を参照してください。

1.2 ライフサイクル管理ソリューションの情報マップ

表2-1に、Cloud Controlで提供される様々なライフサイクル管理ソリューションに関連する章および項を示します。ソリューションを理解するためにこの情報ロードマップを検討し、必要な操作を実行してください。

表1-2 ライフサイクル管理ソリューションの情報マップ

ターゲット名

ソリューション領域

参照リンク

データベース

単一インスタンス・データベース

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

- Oracle Databaseのプロビジョニング

- Oracle Database用のOracle Grid Infrastructureのプロビジョニング

- データベースの作成

アップグレード

データベースのアップグレード

パッチ適用

ソフトウェアのデプロイのパッチ適用

変更管理

データベース・スキーマ変更の管理

構成管理

構成情報の管理

コンプライアンスの管理

コンプライアンスの管理

Enterprise Data Governance

Enterprise Data Governanceの管理

変更アクティビティ・プランナ

変更アクティビティ・プランナの概要

Oracle Real Application Server (Oracle RAC)

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

- Oracle Real Application Clustersデータベース用のOracle Grid Infrastructureのプロビジョニング

- 10gおよび11g用のOracle Real Application Clustersのプロビジョニング

- Oracle Real Application Clustersの拡張

- Oracle Real Application Clustersの削除またはスケール・ダウン

パッチ適用

ソフトウェアのデプロイのパッチ適用

変更管理

データベース・スキーマ変更の管理

構成管理

構成情報の管理

コンプライアンスの管理

コンプライアンスの管理

Enterprise Data Governance

Enterprise Data Governanceの管理

変更アクティビティ・プランナ

変更アクティビティ・プランナの概要

Oracle RAC Oneデータベース

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

Oracle Real Application Clusters One (Oracle RAC One) Nodeデータベースのプロビジョニング

変更管理

データベース・スキーマ変更の管理

構成管理

構成情報の管理

コンプライアンスの管理

コンプライアンスの管理

Enterprise Data Governance

Enterprise Data Governanceの管理

変更アクティビティ・プランナ

変更アクティビティ・プランナの概要

プラガブル・データベース

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

プラガブル・データベースの管理

Oracleデータベース・リプレイ・クライアント

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

Oracleデータベース・リプレイ・クライアントのプロビジョニング

変更管理

データベース・スキーマ変更の管理

構成管理

構成情報の管理

コンプライアンスの管理

コンプライアンスの管理

Enterprise Data Governance

Enterprise Data Governanceの管理

変更アクティビティ・プランナ

変更アクティビティ・プランナの概要

Fusion Middleware

Oracle Fusion Middleware

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

- Fusion MiddlewareドメインおよびOracleホームのプロビジョニング

- Fusion Middlewareドメインのスケール・アップ/スケール・アウト

構成管理

構成情報の管理

コンプライアンスの管理

コンプライアンスの管理

変更アクティビティ・プランナ

変更アクティビティ・プランナの概要

Java EEアプリケーション

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

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

構成管理

構成情報の管理

コンプライアンスの管理

コンプライアンスの管理

変更アクティビティ・プランナ

変更アクティビティ・プランナの概要

コヒーレンス・ノードおよびクラスタ

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

コヒーレンス・ノードおよびクラスタのプロビジョニング

構成管理

構成情報の管理

コンプライアンスの管理

コンプライアンスの管理

変更アクティビティ・プランナ

変更アクティビティ・プランナの概要

Oracle SOAアーティファクトおよびコンポジット

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

Oracle SOAアーティファクトおよびコンポジットのプロビジョニング

構成管理

構成情報の管理

コンプライアンスの管理

コンプライアンスの管理

変更アクティビティ・プランナ

変更アクティビティ・プランナの概要

Oracle Service Bus

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

Oracle Service Busリソースのプロビジョニング

構成管理

構成情報の管理

コンプライアンスの管理

コンプライアンスの管理

変更アクティビティ・プランナ

変更アクティビティ・プランナの概要

Oracle BPEL Process Manager

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

Oracle BPELプロセスのプロビジョニング

構成管理

構成情報の管理

コンプライアンスの管理

コンプライアンスの管理

変更アクティビティ・プランナ

変更アクティビティ・プランナの概要

Oracle Application Server

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

Oracle Application Serverのプロビジョニング

パッチ適用

ソフトウェアのデプロイのパッチ適用

構成管理

構成情報の管理

コンプライアンスの管理

コンプライアンスの管理

変更アクティビティ・プランナ

変更アクティビティ・プランナの概要

パッチ適用およびプロビジョニングのサポートされているオペレーティング・システム

Oracle Linux、Red Hat Enterprise Linux (RHEL)、SuSE Linux (SLES)

検出

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

プロビジョニング

ベアメタル・サーバーのプロビジョニング

パッチ適用

Linuxホストへのパッチ適用

構成管理

構成情報の管理

コンプライアンスの管理

コンプライアンスの管理

変更アクティビティ・プランナ

変更アクティビティ・プランナの概要

2 インフラストラクチャの設定

この章では、ライフサイクル管理機能の使用を開始する前に満たす必要のあるインフラストラクチャの要件について説明します。この章は、基本的にインフラストラクチャを作成する管理者または設計者向けです。この章で説明している要件を実行する必要があるのは一度のみです。

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

- インフラストラクチャの設定の開始

- Oracleソフトウェア・ライブラリの設定

- 資格証明の設定

- Enterprise Managerユーザー・アカウントの作成

- (オプション) My Oracle Supportの設定

- (オプション)自己更新の構成

- (オプション)電子メール通知の設定

2.1 インフラストラクチャの設定の開始

この章では、インフラストラクチャの設定手順を含むすべての手順の概要を説明し、開始できるようにします。この項を、パッチ適用およびプロビジョニングを含むすべてのライフサイクル管理タスクを実行するためのインフラストラクチャを正常に設定するために、実行する必要のある一連のアクションを理解するためのドキュメント・マップとみなしてください。

図2-1は、インフラストラクチャを設定するために実行する一連の手順を図解したものです。

図2-1 インフラストラクチャ設定のワークフロー

各項の詳細は、表2-1のステップに記載されている参照先リンクをクリックしてください。

表2-1 インフラストラクチャの設定の開始

ステップ

説明

参照リンク

ステップ1

ソフトウェア・ライブラリの設定

第2.2項

ステップ2

資格証明の設定

第2.3項

ステップ3

Enterprise Managerユーザー・アカウントの作成

第2.4項

ステップ4

My Oracle Support資格証明の設定

第2.5項

ステップ5

追加/付加価値の設定(オプション)

自己更新の構成

第2.6項

ステップ6

追加/付加価値の設定(オプション)

電子メール通知の設定

第2.7項

注意:
OMSが必要なレベルまで適切にパッチ適用済であることを確認してください。プロビジョニングとパッチの機能を使用するためにEnterprise Manager Cloud Control Management Server (OMS)に適用する必要があるパッチの詳細は、My Oracle Supportのノート427577.1を参照してください。

2.2 Oracleソフトウェア・ライブラリの設定

Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)は、Oracle Enterprise Manager Cloud Control(Cloud Control)が提供するコア機能の1つです。技術的には、ソフトウェア・パッチ、仮想アプライアンス・イメージ、参照ゴールド・イメージ、アプリケーション・ソフトウェアおよび関連するディレクティブのスクリプトなど、認証済ソフトウェア・エンティティを格納する記憶域の場所です。これらを格納する以外に、ソフトウェア・エンティティのバージョン、成熟度レベルおよび状態を管理することもできます。

Cloud Controlで「ソフトウェア・ライブラリ」コンソール・ページにアクセスするには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。図2-2に示すように、「ソフトウェア・ライブラリ」ホームページには、Oracle所有のフォルダ(ロック記号が付いている)とユーザー所有のフォルダの2種類があります。

図2-2 「ソフトウェア・ライブラリ」コンソール

エンティティを作成または管理するためにソフトウェア・ライブラリの使用を開始するには、ソフトウェア・ライブラリの記憶域の場所が構成されている必要があります。システム管理者が、ソフトウェア・ライブラリの記憶域の場所を構成し、ソフトウェア・ライブラリを使用できるようにします。

Cloud Controlでは次のタイプの記憶域の場所が提供されます。

- アップロード・ファイルの場所: エンティティの作成または更新の一環としてソフトウェア・ライブラリによってアップロードされたファイルを格納するために構成された場所です。アップロード・ファイルの場所は、2つの記憶域オプションをサポートしています。

1. OMS共有ファイル・システム

2. OMSエージェント・ファイル・システム

- 参照先ファイルの場所: ソフトウェアのバイナリやスクリプトを保護するために組織の既存のITインフラストラクチャ(ファイル・サーバー、Webサーバーまたは記憶域システムなど)を活用できる場所です。このような場所を使用すると、エンティティはソフトウェア・ライブラリ記憶域にファイルを明示的にアップロードしなくてもそのファイルを参照できます。参照先ファイルの場所は、3つの記憶域オプションをサポートしています。

1. HTTPの場所

2. NFSの場所

3. 管理エージェントの場所

管理コンソールから記憶域の場所を構成できます。これを行うには、Cloud Controlで、「設定」メニューから「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。図2-3に示すように、「ソフトウェア・ライブラリ: 管理」ページが表示されます。

図2-3 ソフトウェア・ライブラリの管理

関連項目:
ソフトウェア・ライブラリの構成の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

注意:
Windowsホストで、「ソフトウェア・ライブラリ」のエンティティの実行を伴うプロシージャ(ディレクティブ・スクリプトなど)を実行するには、Windowsユーザーに次の権限を付与する必要があります。

- オペレーティング システムの一部として機能

- プロセスのメモリ クォータの増加

- バッチ・ジョブとしてログオンする権限

- プロセス レベル トークンの置き換え

これを行わない場合、プロシージャでディレクティブ・ステップの実行に失敗する可能性があります。

2.3 資格証明の設定

Enterprise Manager Cloud Controlでプロビジョニングおよびパッチ適用タスクを実行するには、オペレーティング・システムの通常ユーザー・アカウント(Oracle)用の名前付き資格証明と、特権ユーザー・アカウント(root)用の名前付き資格証明を設定する必要があります。

名前付き資格証明は、システムでのユーザーの認証情報を指定します。名前付き資格証明はオペレーティング・システムのログイン資格証明のようなユーザー名およびパスワードのペアで指定でき、Oracleホームの所有者の資格証明は主にジョブの実行、パッチ適用およびその他の管理タスクなどの操作を実行する場合に使用されます。

Enterprise Manager Cloud Controlを使用すると、システム資格証明を通常ユーザー(Oracle)の名前付き資格証明として登録できます。または、root権限がある場合には、rootアカウントの詳細を特権ユーザーの名前付き資格証明として登録することもできます。一度名前付き資格証明として登録されると、必要であればそれらを優先資格証明として保存できます。

資格証明を保存する利点は、次のとおりです。

- 資格証明の詳細をすべてのユーザーに公開する必要がありません。

- それぞれのOracleホームまたはホスト・マシンに対し、ユーザー名およびパスワードを毎回指定する必要はなく、かわりに、保存された資格証明を使用する名前付きプロファイルを選択できるので、時間と手間が省けます。

名前付き資格証明の詳細は、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』を参照してください。

デプロイメント・プロシージャのほとんどの手順は通常ユーザーとして実行することができますが、一部の手順には特別な権限および特権が必要であり、Oracleアカウントの資格証明またはrootアカウントの資格証明では十分でない場合があります。このような状況では、認証ユーティリティを使用して、別のユーザーの権限でデプロイメント・プロシージャ内の一部の手順を実行します。Enterprise Manager Cloud Controlでサポートされる認証ユーティリティはSUDOおよびPowerBrokerです。このサポートはEnterprise Manager Cloud Controlで使用可能な権限委任メカニズムを使用して提供されます。

権限委任および権限委任がサポートする認証ツールの概念の概要は、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』を参照してください。

表2-2は、資格証明に関するユースケースをリストし、資格証明を設定してプロビジョニングを行うために実行する手順について説明しています。ご自分の状況に最もよく一致するユースケースを選択して、提案されている手順に従います。

表2-2 Enterprise Manager資格証明の設定

ユースケース

実行する手順

直接アクセス、またはオペレーティング・システムの通常ユーザー・アカウント(Oracle)に必要な資格証明がない場合

または

直接アクセス、または特権アカウント(root)に必要な資格証明がない場合

次の手順を実行します。

1. 次のように権限委任を設定します。

1. SUDOまたはPowerBrokerのいずれかに対する権限委任(PDP)テンプレートを作成します。これを行うには、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』の権限委任の作成に関する項を参照してください。

2. 作成したテンプレートをターゲット・ホストの管理エージェントに適用します。

2. オペレーティング・システムの通常ユーザー・アカウント(Oracle)に対する名前付き資格証明を、SUDOまたはPowerBrokerを実行する権限を使用して作成する方法の詳細は、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』の名前付き資格証明の作成に関する項を参照してください。
または

オペレーティング・システムの特権ユーザー・アカウント(root)に対する名前付き資格証明を、SUDOまたはPowerBrokerを実行する権限を使用して作成する方法の詳細は、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』の特権資格証明の作成に関する項を参照してください。

3. オペレーティング・システムの通常アカウントに対する名前付き資格証明または特権ユーザー・アカウントに対する名前付き資格証明を優先資格証明として保存します。これを行うには、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』のホストおよびOracleホームの特権資格証明の保存に関する項およびMy Oracleサポートにアクセスするための特権資格証明の保存に関する項を参照してください。

直接アクセス、またはオペレーティング・システムの通常ユーザー・アカウント(Oracle)に必要な資格証明がある場合

または

直接アクセス、または特権アカウント(root)に必要な資格証明がある場合

次の手順を実行します。

1. オペレーティング・システムの通常ユーザー・アカウント(Oracle)に対する名前付き資格証明を作成する方法の詳細は、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』の名前付き資格証明の作成に関する項を参照してください。
または

特権ユーザー・アカウント(root)資格証明に対する名前付き資格証明を作成する方法の詳細は、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』の特権資格証明の作成に関する項を参照してください。

2. オペレーティング・システムの通常アカウントに対する名前付き資格証明または特権ユーザー・アカウントに対する名前付き資格証明を優先資格証明として保存します。これを行うには、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』のホストおよびOracleホームの特権資格証明の保存に関する項およびMy Oracleサポートにアクセスするための特権資格証明の保存に関する項を参照してください。

2.4 Enterprise Managerユーザー・アカウントの作成

この項では、次の項目について説明します。

- ユーザー・アカウントの概要

- デザイナ・ユーザー・アカウントの作成

- オペレータ・ユーザー・アカウントの作成

2.4.1 ユーザー・アカウントの概要

Cloud Controlから、新規のEnterprise Manager管理者アカウントを作成して管理できます。管理者アカウントには、それぞれ独自のログイン資格証明や、アカウントに割り当てられた一連のロールおよび権限が含まれています。

アクセス権に基づき、ユーザーは次のように分類できます。

- スーパー管理者

- デザイナ(EM_ALL_DESIGNER)

- オペレータ(EM_ALL_OPERATOR)

スーパー管理者

スーパー管理者はすべてのターゲットに対する完全なアクセス権限のある強力なCloud Control管理者です。Cloud Control環境でアカウントの作成および管理を担当します。たとえば、スーパー管理者はデザイナおよびオペレータ・ロールを作成し、そのロールを企業内の様々なユーザーおよびグループに付与します。

デザイナ

デザイナはデプロイメント・プロシージャおよびソフトウェア・ライブラリでの権限が高められた管理者のリーダーです。Cloud Control以降では、デザイナはロック・ダウン機能を使用してデプロイメント・プロシージャ・テンプレートを作成し、これらのテンプレートを保存して、標準化を実行し、整合性を保つことができます。オペレータの権限はこれらのテンプレートに付与されて、オペレータとしてログインした管理者がこれらのテンプレートを起動し、デプロイメント・プロシージャを正常に実行できるようにします。これを行うことで、プロシージャにエラーが発生しにくくなり、整合性が高まります。

ロック・ダウンを使用したデプロイメント・プロシージャの保存の詳細は、第50.6.2.1項を参照してください。

デザイナは次のようなすべての設計時のアクティビティの実行を担当します。

- ソフトウェア・ライブラリでのプロビジョニング・プロファイルの作成。

- コンポーネント、ディレクティブおよびイメージの作成、Oracle Software Libraryへの格納。

- 組織の必要性に応じたデフォルトのデプロイメント・プロシージャのカスタマイズ。

- パッチ計画とパッチ・テンプレートの作成。

事前定義済のデザイナ用のOracleロールはEM_ALL_DESIGNERで、このロールは次にプロビジョニング・タスク用にEM_PROVISIONING_DESIGNERを、パッチ適用タスク用にEM_PATCH_DESIGNERを、特別に設定できる詳細なロールを含みます。デザイナに付与される権限の詳細は、第50.2項を参照してください。

オペレータ

オペレータはデプロイメント・プロシージャおよびソフトウェア・ライブラリでの権限が制限された管理者です。通常、オペレータはデプロイメント・プロシージャを表示および発行できます。また、デザイナ・ユーザーがオペレータにターゲットまたはエンティティに対する必要な権限を付与することもできます。

オペレータはデザイナが作成したインフラストラクチャを使用して、次のような実行時アクティビティを実行します。

- プロシージャのプロビジョニングのためのソフトウェア・ライブラリにあるプロビジョニング・プロファイルへのアクセス。

- 選択したターゲットにソフトウェアをプロビジョニングするためのソフトウェア・デプロイメントの起動。

- パッチ計画とパッチ・テンプレートを使用したソフトウェア・デプロイメントのパッチ適用。

事前定義済のオペレータ用のOracleロールはEM_ALL_OPERATORで、このロールは次にプロビジョニング・タスク用にEM_PROVISIONING_OPERATORを、パッチ適用タスク用にEM_PATCH_OPERATORを、特別に設定できる詳細なロールを含みます。オペレータに付与される権限の詳細は、第50.2項を参照してください。

注意:
デザイナは設計時および実行時アクティビティの両方を選択する選択ができますが、オペレータは実行時アクティビティのみを実行できます。

2.4.2 デザイナ・ユーザー・アカウントの作成

デザイナ・ユーザー・アカウントを作成するには、次の手順に従います。

1. Cloud Controlで、「設定」メニューから「セキュリティ」、「管理者」の順に選択します。

2. 「管理者」ページで「作成」をクリックします。

3. 管理者の作成ウィザードで次を実行します。

1. 「プロパティ」ページで、名前に「デザイナ」を指定し、パスワードを入力します。他のフィールドは空白のままにして、「次へ」をクリックします。

2. 「ロール」ページでEM_ALL_DESIGNERを選択して、「次へ」をクリックします。

注意:
または、デザイナのアクセスをプロビジョニングまたはパッチ適用ドメインのいずれかに制限できます。明示的にプロビジョニングの権限を付与するために、EM_PROVISION_DESIGNERロールを選択します。同様に、明示的にパッチ適用の権限をデザイナに付与するために、EM_PATCH_DESIGNERロールを選択します。

3. 「ターゲット権限」ページで、デザイナ・ユーザー・アカウントに付与する必要のあるターゲット権限を選択します。デザイナ・ロールを持つ管理者の使用可能なターゲット権限の詳細は、第50.2.1項を参照してください。

4. 「リソース権限」ページで、各リソース・タイプに対し明示的に付与される権限を選択します。

5. 「確認」画面で、このユーザー・アカウントに対し入力した情報を確認して、「終了」をクリックします。

2.4.3 オペレータ・ユーザー・アカウントの作成

オペレータ・ユーザー・アカウントを作成するには、次の手順に従います。

1. Cloud Controlで、「設定」メニューから「セキュリティ」、「管理者」の順に選択します。

2. 「管理者」ページで「作成」をクリックします。

3. 管理者の作成ウィザードで次を実行します。

1. 「プロパティ」ページで、名前に「オペレータ」を指定し、パスワードを入力します。他のフィールドは空白のままにして、「次へ」をクリックします。

2. 「ロール」ページでEM_ALL_OPERATORを選択して、「次へ」をクリックします。

注意:
または、オペレータのアクセスをプロビジョニングまたはパッチ適用ドメインのいずれかに制限できます。明示的にプロビジョニングの権限を付与するために、EM_PROVISION_OPERATORロールを選択します。同様に、明示的にパッチ適用のデザイナ権限を付与するために、EM_PATCH_OPERATORロールを選択します。

3. 「ターゲット権限」ページで、オペレータ・ユーザー・アカウントに付与する必要のあるターゲット権限を選択します。オペレータ・ロールを持つ管理者の使用可能なターゲット権限の詳細は、第50.2.1項を参照してください。

4. 「リソース権限」ページで、各リソース・タイプに対し明示的に付与される権限を選択します。

5. 「確認」画面で、このユーザー・アカウントに対し入力した情報を確認して、「終了」をクリックします。

2.5 (オプション) My Oracle Supportの設定

エージェントへのパッチ適用、その他のターゲットへのパッチ適用、MOS関連タスク、および自己更新タスクのためにCloud ControlでMy Oracle Supportに接続するには、確実にプロキシ・サーバーが設定され詳細が登録されている必要があります。これを行うには、第42.2.3.2項で説明する手順に従います。

注意:
Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)以降、My Oracle Suppotからsupport.oracle.comに直接アクセスするようになりました。これは、このURLへのネットワーク・アクセスを提供するか、My Oracle SupportにアクセスするクライアントからこのURLにプロキシ・アクセスを付与する必要があることを意味します。

2.6 (オプション)自己更新の構成

自己更新機能により、Cloud Controlコンポーネントの更新に関する情報を取得できます。「自己更新」ホームページを使用して、新規の更新に関する情報を入手し、更新の確認、ダウンロードおよび適用を行うための共通ワークフローを提供できます。「自己更新」コンソールにより、インストールに適用可能な新しい更新がOracleにより使用可能になると、自動的に通知されます。

プロビジョニングおよびパッチ適用に使用できるソフトウェア・ライブラリ・コンポーネントおよびディレクティブはプロビジョニング・エンティティと呼ばれます。プロビジョニング・バンドルは、データベース・プロビジョニングまたはFMWプロビジョニングなど、特定のプロビジョニングまたはパッチ適用エリアを参照します。これを経由してCloud Controlは顧客に更新を配信します。

注意:
ユーザーにVIEW_ANY_SELFUPDATE権限があることを確認してください。

Oracleが提供する更新をプロビジョニング・エンティティに適用するには、次の手順に従います。

1. Cloud Controlで、「設定」メニューから「拡張性」、「自己更新」の順に選択します。

2. プロビジョニング・バンドルのダウンロードをスケジュールします。自己更新フレームワークが、バンドルを既知の場所にダウンロードします。自己更新の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

3. 「アクション」メニューで「サブスクライブ」を選択し、プロビジョニング・バンドルをダウンロードできるようになったとき必ず通知を受信するようにします。

4. 更新ホーム・ページで、「プロビジョニング・バンドル」タイプの更新を選択し、「アクション」メニューから「開く」を選択します。

5. プロビジョニング・バンドルの更新を手動で適用します。選択したプロビジョニング・バンドルの指示に従って、更新を手動で適用します。

6. 更新ホーム・ページで情報を確認し、更新が適用されたことを確認します。

2.7 (オプション)電子メール通知の設定

Cloud Controlはデプロイメント・プロシージャを実行するたびに電子メール通知を送信できます。ただし、デフォルトではデプロイメント・プロシージャのこの機能は有効ではありません。電子メール通知を送信するように構成するには、デプロイメント・プロシージャをカスタマイズする必要があります。

デプロイメント・プロシージャのカスタマイズの詳細は、第51章を参照してください。

第II部

検出

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

- 第3章「ホストおよびソフトウェア・デプロイメントの検出」

3 ホストおよびソフトウェア・デプロイメントの検出

検出はソフトウェア・デプロイメントの状態を監視および管理するための最初の手順です。検出は、管理対象外ホストとそのソフトウェア・デプロイメントを識別し、それを管理可能ターゲットとしてOracle Enterprise Manager Cloud Control (Cloud Control)に追加するプロセスのことです。

この章では、ホストとそのソフトウェア・デプロイメントを検出し、それらをCloud Controlに追加する方法について説明します。この章では特に、次のことについて説明します。

- ホストおよびターゲットの自動的な検出

- ホストおよびターゲットの手動での検出

3.1 ホストおよびターゲットの自動検出

自動検出は、Enterprise Manager Cloud Controlによって管理および監視できるOracleソフトウェアをホストでスキャンするプロセスを意味します。デフォルトでは、自動検出は24時間ごとに実行されてターゲットを検出します。

自動検出の場合は、ホストで管理エージェントを稼働させ、管理対象外ホストをスキャンするEnterprise Managerジョブを実行します。次に、これらの管理対象外ホストに監視エージェントをデプロイして管理対象ホストに変換し、管理対象ホスト上でターゲットを検索した上で、最終的にこれらのターゲットを管理対象ターゲットのステータスに昇格させます。

自動検出の構成を変更すれば、検出するスケジュール、ターゲット・タイプ、ターゲットをスキャンするホストを設定できます。その後、検出されたホストを昇格させてCloud Controlで管理対象ターゲットにすることが可能です。また、新しくインフラストラクチャに追加されたターゲットを定期的に識別し、監視用にCloud Controlに追加することもできます。

自動検出の構成後、「自動検出の結果」ページを定期的にチェックして、検出されたターゲットを確認する必要があります。

自動検出とターゲットの監視の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「ターゲットの検出と監視」を参照してください。

3.2 ホストおよびターゲットの手動での検出

自動検出に加えて、Cloud Controlでは、ホストおよび様々なOracleソフトウェアとコンポーネントを管理対象ターゲットとして手動で追加できます。ターゲットを手動で追加する場合、ターゲットを直接追加することにより、検出プロセスを実行せずに済みます。この方法でターゲットを検出すると、Oracle Management Agentで検出が不要なときに検出を実行するリソースを消費しなくて済みます。

手動検出とターゲットの監視の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「ターゲットの検出と監視」を参照してください。

第III部

データベースのプロビジョニング

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

- 第4章「データベースのプロビジョニングの概要」

- 第5章「Oracle Databaseのプロビジョニング」

- 第6章「Oracle Database用のOracle Grid Infrastructureのプロビジョニング」

- 第7章「Oracle Real Application Clustersデータベース用のOracle Grid Infrastructureのプロビジョニング」

- 第8章「Oracle Real Application Clusters One (Oracle RAC One) Nodeデータベースのプロビジョニング」

- 第9章「10gおよび11g用のOracle Real Application Clustersのプロビジョニング」

- 第10章「Oracle Real Application Clustersの拡張」

- 第11章「Oracle Real Application Clustersの削除またはスケール・ダウン」

- 第12章「Oracleデータベース・リプレイ・クライアントのプロビジョニング」

- 第13章「Oracleスタンバイ・データベースのプロビジョニング」

- 第14章「Oracleデータベースおよびプラガブル・データベースのクローニング」

- 第16章「データベースの作成」

- 第17章「プラガブル・データベースの管理」

4 データベース・プロビジョニングの概要

プロビジョニングでは、異なるプラットフォーム、環境および場所でのソフトウェア、アプリケーションまたはサーバーの、繰り返し可能で、信頼性のある、無人の自動化されたスケジュール済一括デプロイメントを行います。

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)のデータベース・プロビジョニング機能の概要、サポートされるターゲット、Cloud Controlにより提供されるデプロイメント・プロシージャ、およびデータベース・プロビジョニングを開始するために設定する必要のあるインフラストラクチャについて説明します。この章の具体的な内容は次のとおりです。

- データベースのプロビジョニングの概要

- サポートされるユースケースおよびデータベース・プロビジョニング・プロシージャを使用してプロビジョニングされるターゲット

- データベース・プロビジョニングの設定

4.1 データベースのプロビジョニングの概要

プロビジョニング・ソリューションはCloud Controlにより提供されるライフサイクル管理ソリューションの重要な部分です。データベース・プロビジョニング・ソリューションの一部として、Cloud Controlにより、Oracle Database (単一インスタンス・データベースとも呼ばれます)およびOracle Real Application Clustersデータベースのプロビジョニング、Oracle Real Application Clustersノードの拡張または削除、Oracle Real Application Clusters One Nodeデータベースのプロビジョニング、拡張可能および自動化された方法でのOracle単一インスタンス・データベースのアップグレードが可能です。図4-1に、Cloud Controlのデータベース・プロビジョニング・ソリューションを示します。

図4-1 Cloud Controlのデータベース・プロビジョニング・ソリューション

このリリースでのデータベース・プロビジョニング機能は次のとおりです。

デザイナおよびオペレータ・ロール

Cloud Controlでは、デザイナやオペレータなどの明確に定義された管理者ロールが提供されます。デザイナ・ロールでは、デプロイメント・プロシージャで1つ以上のフィールドをロック・ダウンすることによって、オペレータに事前に設定された標準構成のみでデプロイさせることが可能です。

デザイナ・ロールのロック・ダウン機能

データベース・プロビジョニングのロック・ダウン機能により、デザイナはホスト・ターゲット、資格証明、プロビジョニングされるOracleホーム、その他の変数のセットをロック・ダウンできます。これは標準のデプロイメントを強制し、一括デプロイメント中に構成内のエラーを最小限に抑えます。その後でオペレータはデザイナが構成しプロシージャ・ライブラリに保存したプロシージャをデプロイできます。デプロイメント・プロシージャのロック・ダウンの詳細は、第50.6.2.1項を参照してください。

プロビジョニング・プロファイルとデータベース・テンプレート

デプロイメントでの標準化を保証しエラーを最小限に抑えるためにデータベース・プロビジョニングで使用されるプロビジョニング・プロファイルを作成できます。Cloud Controlコンソールからプロビジョニング・アクティビティで使用されるデータベース・テンプレートも作成できます。

Cloud Controlを使用したデータベースの作成

Cloud ControlではCloud Controlコンソールからデータベースを作成できるようになりました。これにより、データベースのプロビジョニングおよび作成に単一インタフェースを使用することができます。データベースの作成の詳細は、第16章を参照してください。

データベースのプロビジョニング・ウィザード内の容易な移動

デザイナおよびオペレータはCloud Controlの強化されたデータベースのプロビジョニング・ウィザードを容易に使用および移動できます。

自己更新

自己更新機能を使用して、プロビジョニング・エンティティに対する更新を自動的にダウンロードおよびインストールできます。プロビジョニング・エンティティを更新する自己更新機能の使用の詳細は、第2.6項を参照してください。

すべてのデータベース・プロビジョニング・アクティビティの「データベースのプロビジョニング」コンソール

「データベースのプロビジョニング」コンソールは、データベース・プロビジョニング・アクティビティの開始ポイントです。コンソールには、プロビジョニングの設定、プロファイル、デプロイメント・プロシージャ、およびプロビジョニングの開始方法に関する情報が表示されます。

図4-2に、Cloud Controlコンソールから「データベースのプロビジョニング」画面にアクセスする方法を図示します。

図4-2 「データベースのプロビジョニング」画面へのアクセス

4.2 サポートされるユースケースおよびデータベース・プロビジョニング・プロシージャを使用してプロビジョニングされるターゲット

Cloud Controlではデプロイメント・プロシージャを使用してデータベース・プロビジョニングを実行できます。デプロイメント・プロシージャは、プロビジョニングのタスクを完了する一連の事前定義された手順です。一般的なデプロイメント・プロシージャの詳細は、第50章を参照してください。

表4-1に、Cloud Controlにより提供されるデータベース・デプロイメント・プロシージャと、プロビジョニングできる様々なターゲットを示します。

表4-1 データベース・デプロイメント・プロシージャおよびプロビジョニングされるターゲット

デプロイメント・プロシージャ

プロビジョニングされるターゲット

Oracle Databaseのプロビジョニング

- Oracle Database (単一インスタンス) 10gリリース1から12cリリース1

- Oracle Grid Infrastructure 12cリリース1

- Oracle Automatic Storage Management (Oracle ASM) 12cリリース1

- Oracle Restart (単一インスタンスの高可用性) 12c リリース1

Oracle Real Application Clusterのプロビジョニング

- Oracle Real Application Clusters (Oracle RAC) 12cリリース1

- Oracle RAC One Node 12cリリース1

- Oracle Grid Infrastructure 12cリリース1

- Oracle Automatic Storage Management (Oracle ASM) 12cリリース1

Oracle Databaseの作成

- Oracle Database (単一インスタンス・データベース) 12cリリース1

- Oracle Real Application Clusters (Oracle RAC) 12cリリース1

- Oracle RAC One Node 12cリリース1

プラガブル・データベースのプロビジョニング

注意: このデプロイメント・プロシージャは、「データベースのプロビジョニング」ページから手動で起動できません。プラガブル・データベースのプロビジョニング・コンソールまたはEM CLIを使用してプラガブル・データベースをプロビジョニングすると、このデプロイメント・プロシージャが内部的に起動されます。

プラガブル・データベース(Oracle Database 12cリリース1以降の一部としてのみ使用可能)

Oracle Clusterware/Oracle RAC for UNIXおよびRDBMSバージョン10g/11g/12cのプロビジョニング(UNIXプラットフォームに適用)

- Oracle Real Application Clusters (Oracle RAC) 10gリリース1から12cリリース1

- Oracle Clusterware 10gリリース1から12cリリース1

- Oracle Clusterware Automatic Storage Management (Oracle ASM) 10gリリース1から12cリリース1

Oracle Clusterware/Oracle RAC for WindowsおよびRDBMSバージョン10g/11g/12cのプロビジョニング(Windowsプラットフォームに適用)

- Oracle Real Application Clusters (Oracle RAC) 10gリリース1から12cリリース1

- Oracle Clusterware 10gリリース1から12cリリース1

- Oracle Clusterware Automatic Storage Management (Oracle ASM) 10gリリース1から12cリリース1

Oracle Real Application Clusterの拡張/スケール・アップ

Oracle Real Application Clusters (Oracle RAC) 10gリリース1から12cリリース1

Oracle Real Application Clustersの削除/縮小

Oracle Real Application Clusters (Oracle RAC) 10gリリース1から12cリリース1

Oracle Database Clientのプロビジョニング

Oracle Database Client 10gリリース2から12cリリース1

表4-2に、データベース・プロビジョニングのデプロイメント・プロシージャの様々なユースケースを示します。

表4-2 データベースのデプロイメント・プロシージャのユースケース

デプロイメント・プロシージャ

ユースケース

リンク

Oracle Databaseのプロビジョニング

- 単一インスタンス・データベースのプロビジョニングおよび作成

- Oracle Automatic Storage Managementを使用した単一インスタンス・データベースのプロビジョニング

- 単一インスタンス・データベース・ソフトウェアのみのプロビジョニング

- 単一インスタンス・データベースを使用したOracle Grid InfrastructureのプロビジョニングとOracle Automatic Storage Managementを使用したデータベースの構成

- Oracle Grid Infrastructureおよび単一インスタンス・データベース・ソフトウェアのみのプロビジョニング

- 第5.3項

- 第5.4項

- 第5.5項

- 第6.2項

- 第6.3項

Oracle Real Application Clusterのプロビジョニング

- Oracle Real Application Clustersデータベースを使用したグリッド・インフラストラクチャのプロビジョニングとOracle Automatic Storage Managementを使用したデータベースの構成

- 既存のクラスタ上のファイル・システムを使用したOracle Real Application Clustersデータベースのプロビジョニング

- 新規クラスタ上のファイル・システムを使用したOracle Real Application Clustersデータベースのプロビジョニング

- 第7.3項

- 第7.4項

- 第7.5項

Oracle Databaseの作成

- 単一インスタンス・データベースの作成

- Oracle Real Application Clustersデータベースの作成

- Oracle Real Application Clusters Oneデータベースの作成

- 16.2項

- 16.3項

- 16.4項

プラガブル・データベースのプロビジョニング

- 新しいプラガブル・データベースの作成

- 切断されたプラガブル・データベースのプラグイン

- プラガブル・データベースのクローニング

- 非コンテナ・データベースのプラガブル・データベースとしての移行

- プラガブル・データベースの切断および削除

- 17.3.1項

- 17.3.2項

- 17.3.3項

- 17.3.4項

- 17.4.1項

Oracle Clusterware/Oracle RAC for WindowsおよびRDBMSバージョン10g/11g/12cのプロビジョニング

Oracle Clusterware/Oracle RAC for UNIXおよびRDBMSバージョン10g/11g/12cのプロビジョニング

- 実行中のOracle Real Application Clusterのクローニング

- ゴールド・イメージを使用したOracle Real Application Clusterのプロビジョニング

- アーカイブ・ソフトウェア・バイナリを使用したOracle Real Application Clusterのプロビジョニング

- 第9.3項

- 第9.4項

- 第9.5項

Oracle Real Application Clusterの拡張/スケール・アップ

Oracle Real Application Clusterの拡張

第10.2項

Oracle Real Application Clustersの削除/縮小

Oracle Real Application Clusterの削除

第11.3項

第11.4項

Oracle Database Clientのプロビジョニング

- 実行中のOracleデータベース・リプレイ・クライアントのクローニング

- ゴールド・イメージを使用したOracleデータベース・リプレイ・クライアントのプロビジョニング

- インストール・バイナリを使用したOracleデータベース・リプレイ・クライアントのプロビジョニング

- 第12.2項

- 第12.3項

- 第12.4項

4.3 データベース・プロビジョニングの設定

Oracle Database、Oracle Real Application Clustersデータベース、Oracle RAC One Nodeデータベースをデータベース・テンプレート、インストール・メディア、データベース・エンティティを使用してプロビジョニングできます。また、プロビジョニング・プロファイルを使用してデプロイメントを標準化できます。

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

- 基本インフラストラクチャとホスト要件を満たす

- データベースのプロビジョニングに必要な管理者権限の理解

- デザイナの前提条件

- オペレータの前提条件

- データベース・プロビジョニング・プロファイルの作成

- EMCLIを使用したデータベース・プロビジョニング・プロファイルの記述、作成および削除

- インストール・メディアの作成

- データベース・テンプレートの作成

- ソフトウェア・ライブラリへのデータベース・テンプレートのアップロード

- データベース・プロビジョニング・エンティティの作成

- クラスタ検証ユーティリティのダウンロード

注意:
Cloud Controlバージョン12cに以前のバージョンからアップグレードした場合、データベース・プロビジョニング・デプロイメント・プロシージャを実行する前に、CSHシェルが/bin/cshとして存在することを確認する必要があります。

4.3.1 基本インフラストラクチャとホスト要件を満たす

これらの要件を満たすには、次の操作を実行します。

- 第2章の説明に従って、インフラストラクチャの基本要件を満たしてください。

- ホストがデータベース・プロビジョニング・エンティティ用に設定されていることを確認します。ホストの準備状況の詳細は、付録Bを参照してください。

- Microsoft Windowsホストでデータベース・ソフトウェアをプロビジョニングする場合、データベース・ソフトウェアをプロビジョニングする前にCygwinがホストにインストールされていることを確認する必要があります。
ホストへのCygwinのインストール方法の詳細は、『Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

4.3.2 データベースのプロビジョニングに必要な管理者権限の理解

表4-3では、データベース・デプロイメント・プロシージャの使用に必要なロールおよび最低限の権限について説明します。これらのロールは、Cloud Controlで使用できるデフォルトのロールです。作成する必要はありませんが、これらのロールに基づいて管理者を明示的に作成する必要があります。詳細は、2.4項を参照してください。

表4-3 デプロイメント・プロシージャの使用に必要な権限

ロール

ターゲット権限

リソース権限

実装の推奨

EM_PROVISIONING_DESIGNER

操作の任意のターゲット

- リソース・タイプ:
デプロイメント・プロシージャ

権限:

作成、起動アクセス権の管理

- リソース・タイプ:
ソフトウェア・ライブラリ・エンティティ

権限:

任意のソフトウェア・ライブラリ・エンティティの管理

デプロイメント・プロシージャへのアクセスを付与および制限する場合に必要です。

EM_PROVISIONING_OPERATOR

- 操作の任意のターゲット

- DP権限の起動

- リソース・タイプ:
デプロイメント・プロシージャ

権限:

作成、起動アクセス権の管理

- リソース・タイプ:
ソフトウェア・ライブラリ・エンティティ

権限:

任意のソフトウェア・ライブラリ・エンティティの管理

デプロイメント・プロシージャを起動する場合に必要です。

4.3.3 デザイナの前提条件

デザイナがデータベース・プロビジョニングを開始するための前提条件は、次のとおりです。

- 第2章で説明しているインフラストラクチャの前提条件を必ず満たしてください。

- Cloud Controlで宛先ホストを検出および監視します。このために、宛先ホスト上で最新バージョンのOracle Management Agent (管理エージェント)が必要です。詳細は、『Oracle Cloud Controlインストレーションおよび基本構成ガイド』を参照してください。エージェントがすべてのホスト上で同じ場所にインストールされていることを確認します。

- Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)を設定します。インストール・メディア、データベース・テンプレート、またはプロビジョニング・エンティティがソフトウェア・ライブラリで使用可能であることを確認します。それらの作成の詳細は、第4.3項を参照してください。また、プロビジョニング・プロファイルを使用して、データベース・テンプレートを格納します。データベース・プロビジョニング・プロファイルの作成の詳細は、第4.3.5項を参照してください。

- 宛先ホストのオペレーティング・システム資格証明を優先資格証明としてOracle Management Repository (管理リポジトリ)に格納するか、名前付き資格証明を使用します。
SUDOおよびPowerBrokerを使用する場合、これらの認証ユーティリティの設定に関する情報は、第2.3項を参照してください。

- 次のロールに対応するオペレーティング・システム・グループが、プロビジョニングに選択したホストにすでに存在していることを確認します。これらのグループが存在しない場合、デプロイメント・プロシージャによってこれらが自動的に作成されます。ただし、これらをNIS上で作成する必要がある場合、デプロイメント・プロシージャを実行する前にこれらを手動で作成する必要があります。このようなオペレーティング・システム・グループの作成の詳細は、『Oracle Grid Infrastructureインストレーション・ガイド 12c リリース1(11.2)』を参照してください。
Oracle Databaseユーザー(通常はoracle)は、次のグループのメンバーである必要があります。

- プライマリ・グループとしてのインベントリ・グループ(OINSTALL)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

グリッド・インフラストラクチャ・ユーザー(通常はgrid)は、次のグループのメンバーである必要があります。

- プライマリ・グループとしてのインベントリ・グループ(OINSTALL)

- ASMデータベース管理者(ASMDBA)

- ASMインスタンス・オペレータ(ASMOPER)

- ASMインスタンス管理者(OSASM)

- 次の場所に対する書込み権限を持つオペレーティング・システム・ユーザーを使用していることを確認します。

- グリッド・インフラストラクチャに関する診断データファイルを格納できる、グリッド・インフラストラクチャのOracleベース・ディレクトリ。

- データベースに関する診断データファイルを格納できる、データベースのOracleベース・ディレクトリ。

- グリッド・インフラストラクチャ・ソフトウェアをプロビジョニングできる、グリッド・インフラストラクチャ・ソフトウェアのディレクトリ。

- データベース・ソフトウェアをプロビジョニングできるデータベース・ソフトウェアの場所。 クローニングに関するファイルをステージングできる作業ディレクトリ。

- Cloud Controlで「操作の任意のターゲット」権限があることを確認してください。

- Oracle Real Application Clustersデータベース(Oracle RAC)のプロビジョニングの場合、次の追加の前提条件があります。

- ターゲット・ホストでOracle Grid InfrastructureおよびOracle RACインストールのハードウェア、ソフトウェア、ネットワーク要件を満たします。Oracle Grid InfrastructureおよびOracle RACインストールのハードウェア、ソフトウェアおよびネットワーク要件の詳細は、『Oracle Grid Infrastructureインストレーション・ガイド 12c リリース1(11.2)』を参照してください。

- Oracle RAC Databaseユーザーは、ASMデータベース管理者(ASMDBA)のメンバーである必要があります。

4.3.4 オペレータの前提条件

デプロイメント・プロシージャを実行するオペレータは、次の前提条件を満たしている必要があります。

- オペレータとして、(デザイナによって設定およびロックされた)資格証明の表示、ターゲットの表示、ジョブの発行、およびデプロイメント・プロシージャの起動を行う権限があることを確認してください。

- 次のロールに対応するオペレーティング・システム・グループが、プロビジョニングに選択したホストにすでに存在していることを確認します。これらのグループのオペレーティング・システム・ユーザーには、それぞれの権限が自動的に付与されます。

- インベントリ・グループ(OINSTALL)

- ASMデータベース管理者(ASMDBA)

- ASMインスタンス・オペレータ(ASMOPER)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

- ASMインスタンス管理者(OSASM)

- Cloud Controlで「操作の任意のターゲット」権限があることを確認してください。

4.3.5 データベース・プロビジョニング・プロファイルの作成

プロビジョニング・プロファイルはソフトウェア・ビットおよび構成を含むエンティティです。プロビジョニング・プロファイルが既存のインストールから作成される場合、グリッド・インフラストラクチャ(ソフトウェアまたは構成を含む)およびOracle Database (ソフトウェアまたは構成を含む)のいずれかをクローニングする柔軟性が提供されます。プロビジョニング・プロファイルを使用してデータベース・テンプレートを作成できます。デザイナまたは管理者は、一括デプロイメントにオペレータが使用できるデータベース・プロビジョニング・プロファイルを一度のアクティビティで作成できます。プロビジョニング・プロファイルを使用すると、デプロイメントを標準化でき、デプロイメント・プロシージャの構成中のエラーを回避してデプロイメントを再スケジュールする必要性を軽減します。

注意:
即時利用可能なプロファイルは必要なくなりました。ゴールド・イメージ・フローを使用して、11.2.0.4ゴールド・イメージのプロビジョニング・プロファイルを作成できます。グリッド・インフラストラクチャおよびデータベースの任意のバージョンに対して、インストール・メディアに基づくプロファイルを作成することもできます。
データベースをゴールド・イメージの参照として使用する場合、新しいプロファイルにデータベース・データが含まれます。ARCHIVE LOG MODE内に参照データベースがない場合、参照データベースはプロセス中に停止されてから再起動されます。

データベース・プロビジョニング・プロファイルを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. 「データベース・プロシージャ」ページの「プロファイル」セクションで、「作成」をクリックします。データベース・プロビジョニング・プロファイルの作成ウィザードが起動します。

3. 「参照ターゲット」ページで、検索アイコンをクリックします。

4. 「検索と選択: ターゲット」ウィンドウで、プロビジョニング・プロファイルの作成元の参照ターゲットを選択し、「選択」をクリックします。

5. 「参照ターゲット」ページのインクルード操作では、プロビジョニング・プロファイルに含めるコンポーネントを選択できます。参照ホスト構成に応じて、データベースのOracleホーム、グリッド・インフラストラクチャのOracleホームおよびその関連する構成を次のようにプロビジョニング・プロファイルの一部として含めるように選択できます。

- データベースのOracleホーム: Oracleデータベース・ゴールド・イメージをプロファイルに含めます。

- グリッド・インフラストラクチャのOracleホームとその構成プロパティ: プロファイルにグリッド・インフラストラクチャのゴールド・イメージおよびその構成を含めます。

- データ・コンテンツ: プロファイルにOracleデータベース・テンプレート(またはデータ)を含め、このプロファイルでは、「構造およびデータ」を選択して物理ファイルおよび構造ファイルをデータベースから組み込むか、「構造のみ」を選択してテンプレートに構造ファイルのみを組み込むことができます。

6. 「資格証明」セクションで、「優先資格証明」または「名前付き資格証明」を選択します。名前付き資格証明を使用する場合、資格証明を選択するか、「+」をクリックして新規「名前付き資格証明」を指定します。
「資格証明の追加」ウィンドウで、「ユーザー名」および「パスワード」を指定します。これらを優先資格証明として設定する場合は、「優先資格証明として設定」を選択します。「追加」をクリックします。

「次へ」をクリックします。

7. プロファイル・ページで、次の操作を実行します。

- 「プロファイル情報」セクションで、選択した一意のプロファイル名を入力します。

For example:
Cluster Profile [time when created]

ソフトウェア・ライブラリにプロビジョニング・プロファイルを格納する「プロファイルの場所」、「名前」、「説明」、「バージョン」、「ベンダー」、「注意」、およびプロファイルに含まれるコンポーネントの名前などのデフォルトの詳細を保持または編集します。

- 「スケジュール」セクションで、プロファイルの作成をすぐに開始するか、後でスケジュールできます。

- 「作業ディレクトリ」セクションで、データベース・プロビジョニング・プロファイルの作成中に使用する一時作業ディレクトリを指定します。

- 「ソフトウェア・ライブラリ・ストレージ」セクションで、「ソフトウェア・ライブラリの場所タイプ」および「ソフトウェア・ライブラリの場所名」を選択します。

- 「次へ」をクリックします。

8. 確認ページで、前のページで行った選択内容が正しく表示されていることを確認し、「発行」をクリックします。正しく表示されていない場合は、変更を行うページに達するまで「戻る」を繰り返しクリックします。プロビジョニング・プロファイルの作成を中断するには、「取消」をクリックします。「デプロイメント・インスタンス名」は、プロファイル名およびユーザー名を使用して生成されます。

9. プロビジョニング・プロファイルの作成ジョブを発行したら、このプロビジョニング・プロファイルがデータベースのプロビジョニング・ページに表示されることを確認します。

4.3.6 EMCLIを使用したデータベース・プロビジョニング・プロファイルの記述、作成および削除

この方法を使用すると、管理者またはプロビジョニング・オペレータはEMCLI動詞を使用してデータベース・プロビジョニング・プロファイルを作成または削除できます。

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

- EMCLIを使用したデータベース・プロビジョニング・プロファイルの記述

- EMCLIを使用したデータベース・プロビジョニング・プロファイルの作成

- EMCLIを使用したデータベース・プロビジョニング・プロファイルの削除

4.3.6.1 EMCLIを使用したデータベース・プロビジョニング・プロファイルの記述

プロビジョニング・プロファイルは、次の2つの方法のいずれかを使用して記述できます。

- 次のEMCLI動詞を使用して、データベース・プロビジョニング・プロファイルを記述します。

emcli describe_dbprofile_input

これにより、異なるタイプのプロファイルごとにレスポンス・ファイルが生成されます。

- プロファイル作成プロシージャの発行後、次の操作を実行します。

1. 次のEMCLI動詞を使用して、実行中のプロビジョニング・プロファイル・インスタンスを取得します。

emcli get_instances

2. 前の手順で取得したGUIDを使用して、レスポンス・ファイルを取得します。次に例を示します。

emcli get_instance_data -instance=<GUID>   >/tmp/profile.txt

3. 入力プロパティは、/tmp/profile.txtにリストされています。次のとおりです。

# Input properties are:
GI_GOLD_IMAGE_ENTITY_NAME=ust Profile 02-04-2014 08:03 PM - Grid infrastructure gold image
GI_GOLD_IMAGE_TYPE=GOLD_IMAGE
PROFILE_DESC=Grid Infrastructure Home Reference Profile 02-04-2014 08:03 PM from clustername
PROFILE_LOCATION=Grid Infrastructure Home Provisioning Profiles/11.2.0.2.0/linux_x64
PROFILE_NAME=Cluster clustname Profile 02-04-2014 08:03 PM
PROFILE_NOTES=Host Name: h1.example.com
Cluster: slxaclust
PROFILE_VENDOR=Oracle
PROFILE_VERSION=11.2.0.2.0
REFERENCE_DATABASE=clustername
REFERENCE_DATABASE_TYPE=cluster
REF_GI_CREDENTIALS=AIME_NORMAL:SYSMAN
REF_HOST_CREDENTIALS=AIME_NORMAL:SYSMAN
REF_NODE_SELECTED=h1.example.com
STORAGE_NAME_FOR_SOFTWARE=swlib
STORAGE_TYPE_FOR_SOFTWARE=OmsShared
WORKING_DIRECTORY=/tmp

4.3.6.2 EMCLIを使用したデータベース・プロビジョニング・プロファイルの作成

プロビジョニング・プロファイルを作成するには、次のEMCLI動詞を使用します。

emcli create_dbprofile -input_file=data:"<Prop file name>"

For example:
emcli create_dbprofile -input_file=data:"/tmp/profile.txt"

このコマンドは、作成されるプロファイルのタイプと使用されるオプションについて完全に記述するプロパティ・ファイルを受け入れます。

4.3.6.3 EMCLIを使用したデータベース・プロビジョニング・プロファイルの削除

プロビジョニング・プロファイルおよびそのサブコンポーネントを削除するには、次の手順に従います。

1. 次のEMCLI動詞を使用して、作成したデータベース・プロファイルをリストします。

emcli list_dbprofiles

2. 次のEMCLI動詞を使用して、データベース・プロファイルを削除します。

emcli delete_dbprofile -comp_loc= "<db profile name and location>"

For example:
emcli delete_dbprofile -comp_loc="Grid Infrastructure Home Provisioning Profiles/11.2.0.2.0/linux_x64/Cluster clustername Profile 02-04-2014 08:03 PM"

comp_locは、データベース・プロファイル名とプロファイルの場所の組合せです。

3. プロファイル削除のステータスをチェックするには、次のEMCLIコマンドを実行します。

emcli get_instance_status -instance=<GUID> -xml -details –showJobOutput

4.3.7 インストール・メディアの作成

データベース・プロビジョニングに使用できるインストール・メディアを作成するには、次の手順に従います。

1. 一時的な場所mkdir /tmp/installmediaを作成します。

2. 次のURLにナビゲートします。
http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html

3. データベースをプロビジョニングするオペレーティング・システム用のすべてを表示するリンクをクリックします。

4. 「ライセンス契約に同意する」オプションを選択します。

5. データベースおよびグリッド・インフラストラクチャ・ソフトウェア用のzipファイル1および2を、あらかじめ作成した一時ディレクトリにダウンロードします。

6. 一時ディレクトリに移動して、ZIPファイルのコンテンツを抽出します。
たとえば、データベース・ソフトウェアのZIPファイルのコンテンツを抽出するには、次のコマンドを実行します。

Unzip linux_11gR2_database_1of2.zip
Unzip linux_11gR2_database_2of2.zip

7. データベース・ファイルを圧縮します。

8. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

9. ソフトウェア・ライブラリで、データベースのインストール・メディア・コンポーネントを作成するディレクトリを選択します。

10. 「アクション」メニューから「エンティティの作成」、「コンポーネント」の順に選択します。

11. 「エンティティの作成: コンポーネント」ダイアログで、「インストール・メディア」に「サブタイプ」を選択し、「続行」をクリックします。

12. インストール・メディアの作成: 説明ページで、コンポーネントの「名前」および「説明」を入力し、「次へ」をクリックします。

13. インストール・メディアの作成: 構成ページで、リストから「製品バージョン」、「プラットフォーム」および「製品」を選択します。
「製品」には、Oracle Databaseの場合「Oracle Database」を、Oracleデータベース・リプレイ・クライアントの場合「Oracleクライアント」を、グリッド・インフラストラクチャ・ソフトウェアの場合「Oracle Grid Infrastructure」を選択します。

「次へ」をクリックします。

14. インストール・メディアの作成: ファイルの選択ページで、「ファイルのアップロード」を選択します。

1. 「宛先の指定」セクションで、データベース・ソフトウェアの「アップロード場所」としてソフトウェア・ライブラリの記憶域の場所を選択します。

2. 「ソースの指定」セクションで、エージェント・マシンとして「ファイル・ソース」を選択し、ファイルをアップロードする元のホストを選択します。

3. 「追加」をクリックします。

4. 「リモート・ファイル・ブラウザ」で「次のユーザーでログイン」をクリックします。

5. 「ホスト資格証明」を選択して「OK」をクリックします。

6. 一時ディレクトリに移動して、作成した圧縮されたデータベース・ファイルを選択します。

7. 「追加」を選択して「OK」をクリックします。

「次へ」をクリックします。

15. インストール・メディアの作成: 確認ページで、入力した詳細を確認し、「保存とアップロード」をクリックしてインストール・メディア・ファイルを保存してソフトウェア・ライブラリにアップロードします。

4.3.8 データベース・テンプレートの作成

Cloud Controlでは、追加のデータベースのクローニングまたは作成に使用できるデータベース・テンプレートを作成できます。データベース・テンプレートを作成するには、次の手順に従います。

1. 「ターゲット」メニューから「データベース」を選択します。

2. データベース・ページで、テンプレートの作成元のデータベースをクリックします。

3. データベース・ホームページで、「Oracle Database」メニューから、「プロビジョニング」、「データベース・テンプレートの作成」を選択します。

4. テンプレート・タイプ・ページで次を選択します。

- データと同様の構造を選択し、物理データファイルと構造情報をテンプレートに組み込みます。ユーザー定義スキーマとデータがテンプレートに組み込まれます。このタイプのテンプレートから作成されたデータベースはソース・データベースと同じものになります。

- 構造を選択し、表領域オプション、初期化パラメータ、データファイルを含むソース・データベースに関する構造情報を組み込みます。このテンプレートには、ユーザー定義スキーマとデータは組み込まれません。

ホスト資格証明を選択します。「優先資格証明」、「名前付き資格証明」または「資格証明を入力」を選択できます。

「次へ」をクリックします。

5. テンプレート・オプション・ページで、「テンプレート名」および「説明」を指定します。テンプレートの場所を指定します。

- 「ソフトウェア・ライブラリにテンプレートを格納」を選択し、OMSエージェント・ファイル・システムまたは共有ファイルシステム上の「記憶域のタイプ」および「場所」を指定します。

- 「管理対象ホストにテンプレートを保存」を選択し、ターゲットOracleホームのORACLE_HOME/assistants/dbca/templatesにテンプレートを保存します。

データベース・ファイルの場所を指定します。次のいずれかを選択します。

- Oracle Flexible Architectureを使用を選択し、テンプレートのファイルの場所からOFAに変換します。

- テンプレートのファイルの場所をソース・データベースと同じにする場合は、ファイル場所の保持を選択します。

「次へ」をクリックします。

6. スケジュール・ページで、ジョブ名およびスケジュールを指定します。ジョブを即時実行する場合、デフォルトで選択されている「1回(即時)」を選択します。ジョブを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。また、テンプレート作成プロセス中にデータベースのブラックアウトを選択することもできます。「次へ」をクリックします。

7. 確認ページで、ジョブに指定した詳細を確認し、詳細に満足した場合は、「ジョブの発行」をクリックして、設定したスケジュールのとおりジョブを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。

8. ジョブ・ページでジョブが正常に完了し、テンプレートが指定どおりに作成されているかどうかを確認します。

注意:
データベース・テンプレートの作成にDatabase Configuration Assistant (DBCA)を使用することもできます。
作成するデータベース・テンプレートを編集およびカスタマイズし、カスタマイズしたテンプレートをソフトウェア・ライブラリにアップロードできます。ソフトウェア・ライブラリへのデータベース・テンプレートの手動アップロードの詳細は、第4.3.9項を参照してください。

4.3.9 ソフトウェア・ライブラリへのデータベース・テンプレートのアップロード

データベース・テンプレートを編集およびカスタマイズし、次のようにこれらをソフトウェア・ライブラリにアップロードできます。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. ソフトウェア・ライブラリのホームページで、データベース・テンプレートをアップロードするフォルダを選択します。

3. 「アクション」メニューから「エンティティの作成」、「コンポーネント」の順に選択します。または、カスタム・フォルダを右クリックし、メニューから「エンティティの作成」、「コンポーネント」の順に選択します。

4. 「エンティティの作成: コンポーネント」ダイアログ・ボックスから「データベース・テンプレート」を選択し、「続行」をクリックします。
Cloud Controlに「データベース・テンプレートの作成」ページが表示されます。

5. 説明ページで、「名前」、「説明」、およびエンティティを説明する「その他の属性」を入力します。
注意: コンポーネント名は、属する親フォルダに対して一意である必要があります。一意の名前を入力したときでさえ、競合が報告される場合があります。これは、表示権限がないために表示できないが、フォルダ内に同じ名前のエンティティがあるために起こります。

「追加」をクリックし、データベース・テンプレートを添付します。templatename.dbtまたはtemplatename.dbcの形式でテンプレートをソース・ファイルとして選択します。ファイル名は表示されたままにします。ファイル・サイズが2 MB未満であることを確認してください。

「ノート」フィールドで、エンティティに対して行った変更や、追跡したい変更履歴など、エンティティに関連する情報を追加します。

6. 「ファイルの選択」ページで、データベース・テンプレートに関連するファイルをすべて追加します。
「ファイルのアップロード」を選択し、次のように、データベース・テンプレート・ファイルをすべてアップロードします。

1. 「宛先の指定」セクションで、ファイルをアップロードするソフトウェア・ライブラリの場所を選択します。

2. 「ソースの指定」セクションで、テンプレート・ファイルを格納した場所を選択します。この場所はローカル・マシンでもエージェント・マシンでもかまいません。

3. 「追加」をクリックし、データベース・テンプレート・ファイルをアップロードします。
構造テンプレートの場合、templatename.dbtファイルを再追加します。構造およびデータ・テンプレートの場合、templatename.dbc、datafiledump.dfbおよびcontrolfile.ctlファイルをアップロードします。templatename.dbcファイルをメイン・ファイルとしてマークします。

「ファイルの参照」を選択し、既存の参照先ファイルの保管場所からファイルを参照します。「参照されるファイルの場所」を選択し、ソース・ファイルを追加します。

7. 「確認」ページで詳細をすべて確認してから「保存とアップロード」をクリックすると、コンポーネントが作成されてバイナリがソフトウェア・ライブラリにアップロードされます。

4.3.10 データベース・プロビジョニング・エンティティの作成

Oracleデータベースのプロビジョニングに使用するソフトウェア・ライブラリのプロビジョニング・エンティティを作成および保存できます。Cloud Controlでは、次のタイプのデータベース・プロビジョニング・エンティティを作成できます。

- Oracle Databaseクローン

- Oracle Clusterwareクローン

次のサブ項目でこれらのプロビジョニング・エンティティの作成方法について説明します。

- 参照ホームからのOracle Databaseクローンの作成

- 外部ストレージからのOracle Databaseクローンの作成

- 参照ホームからのOracleクラスタウェア・クローンの作成

- 外部ストレージからのOracleクラスタウェア・クローンの作成

4.3.10.1 参照ホームからのOracle Databaseクローンの作成

参照ホームからOracle Databaseクローンを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ・ホーム」ページで、データベース・クローン・コンポーネントを作成するために任意のカスタム・フォルダを選択します。

3. 「アクション」メニューから「エンティティの作成」、「コンポーネント」の順に選択します。または、カスタム・フォルダを右クリックし、メニューから「エンティティの作成」、「コンポーネント」の順に選択します。

4. 「エンティティの作成: コンポーネント」ダイアログ・ボックスから「Oracle Databaseソフトウェア・クローン」を選択し、「続行」をクリックします。
Oracle Databaseソフトウェア・クローンの作成ページが表示されます。

5. 説明ページで、「名前」、「説明」、およびエンティティを説明する「その他の属性」を入力します。
注意: コンポーネント名は、属する親フォルダに対して一意である必要があります。一意の名前を入力したときでさえ、競合が報告される場合があります。これは、表示権限がないために表示できないが、フォルダ内に同じ名前のエンティティがあるために起こります。

追加をクリックし、readme、コラテラル、ライセンスなどの、エンティティをより適切に説明するファイルを添付します。ファイル・サイズが2 MB未満であることを確認してください。

「ノート」フィールドで、エンティティに対して行った変更や、追跡したい変更履歴など、エンティティに関連する情報を追加します。

6. 構成ページで、「コンポーネントの作成元」メニューから「参照Oracleホーム」を選択し、次のようにします。

1. 「参照Oracleホーム」セクションで、拡大鏡アイコンをクリックし、ホスト・マシン上で実行されているデータベースのリストから目的のデータベースのOracleホームを選択します。
「Oracleホームの場所」と「ホスト名」の各フィールドに適切な値が入ります。

2. 「Oracleホーム資格証明」セクションで、管理するターゲットへのアクセスに使用する資格証明のタイプを選択します。資格証明の設定の詳細は、第2.3項を参照してください。

3. 「作業ディレクトリ」および「除外するファイル」セクションで、書込み権限があるホスト上の「作業ディレクトリ」を入力し、クローニングされたzipファイルを作成して一時的に保管できるようにします。
「除外するファイル」フィールドは、クローニングされたzipファイルから除外される特定のタイプのファイルまたはパターンで事前に移入されます。ただし、要件に基づいて、このリストをカスタマイズできます。

4. 「ソフトウェア・ライブラリのアップロード場所」セクションで、データベース・クローン・ソフトウェアを格納する構成済の記憶域の場所をリストから選択します。
ソフトウェア・ライブラリの記憶域の場所を作成する方法については、第2.2項を参照してください。

7. 「確認」ページで詳細をすべて確認してから「保存とアップロード」をクリックすると、コンポーネントが作成されてバイナリがソフトウェア・ライブラリにアップロードされます。

4.3.10.2 外部記憶域からのOracle Databaseクローンの作成

外部記憶域からOracle Databaseクローンを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ・ホーム」ページで、データベース・クローン・コンポーネントを作成するために任意のカスタム・フォルダを選択します。

3. 「アクション」メニューから「エンティティの作成」、「コンポーネント」の順に選択します。または、カスタム・フォルダを右クリックし、メニューから「エンティティの作成」、「コンポーネント」の順に選択します。

4. 「エンティティの作成: コンポーネント」ダイアログ・ボックスから「Oracle Databaseソフトウェア・クローン」を選択し、「続行」をクリックします。
Oracle Databaseソフトウェア・クローンの作成ページが表示されます。

5. 説明ページで、「名前」、「説明」、およびエンティティを説明する「その他の属性」を入力します。
注意: コンポーネント名は、属する親フォルダに対して一意である必要があります。一意の名前を入力したときでさえ、競合が報告される場合があります。これは、表示権限がないために表示できないが、フォルダ内に同じ名前のエンティティがあるために起こります。

追加をクリックし、readme、コラテラル、ライセンスなどの、エンティティをより適切に説明するファイルを添付します。ファイル・サイズが2 MB未満であることを確認してください。

「ノート」フィールドで、エンティティに対して行った変更や、追跡したい変更履歴など、エンティティに関連する情報を追加します。

6. 「構成」ページで、「コンポーネントの作成元」メニューから「既存のOracleホームのアーカイブ」を選択し、次のようにします。

1. 「Oracleホーム・アーカイブ」セクションで、データベース・クローン・ソフトウェアを参照できる外部記憶域の場所を選択します。「外部ストレージの場所名」メニューから場所名を選択します。
外部記憶域の場所を構成する方法については、第2.2項を参照してください。

「Oracleホーム・アーカイブの場所」に正確なパスを入力します。これは基本的に、外部記憶域にあるアーカイブ・ファイルの、構成された場所からの相対的なパスです。アーカイブ・ファイルが有効なZIPファイルであることを確認してください。

注意:
Oracleホームのzipファイルを作成するには、次の構文を使用します。

<ZIP  PATH>/zip -r -S -9 -1 <archiveName.zip> <directory or list  of files to be archived> -x <patterns to exclude files>

2. 「Oracleホームのプロパティ」セクションで、「製品」、「バージョン」、「プラットフォーム」および「RACホーム」の各値を選択します。これらの構成プロパティはエンティティを検索または追跡する際に特に役に立ちます。

7. 「確認」ページで詳細をすべて確認してから「保存とアップロード」をクリックすると、コンポーネントが作成されてバイナリがソフトウェア・ライブラリにアップロードされます。

4.3.10.3 参照ホームからのOracleクラスタウェア・クローンの作成

参照ホームからOracleクラスタウェア・クローンを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ・ホーム」ページで、データベース・クローン・コンポーネントを作成するために任意のカスタム・フォルダを選択します。

3. 「アクション」メニューから「エンティティの作成」、「コンポーネント」の順に選択します。または、カスタム・フォルダを右クリックし、メニューから「エンティティの作成」、「コンポーネント」の順に選択します。

4. 「エンティティの作成: コンポーネント」ダイアログ・ボックスから「Oracleクラスタウェア・クローン」を選択し、「続行」をクリックします。
「Oracleクラスタウェア・クローンの作成: 説明」ページが表示されます。

5. 説明ページで、「名前」、「説明」、およびエンティティを説明する「その他の属性」を入力します。
注意: コンポーネント名は、属する親フォルダに対して一意である必要があります。一意の名前を入力したときでさえ、競合が報告される場合があります。これは、表示権限がないために表示できないが、フォルダ内に同じ名前のエンティティがあるために起こります。

追加をクリックし、readme、コラテラル、ライセンスなどの、エンティティをより適切に説明するファイルを添付します。ファイル・サイズが2 MB未満であることを確認してください。

「ノート」フィールドで、エンティティに対して行った変更や、追跡したい変更履歴など、エンティティに関連する情報を追加します。

6. 構成ページで、「コンポーネントの作成元」メニューから「参照ホーム」を選択し、次のようにします。

1. 「参照Oracleホーム」セクションで、拡大鏡アイコンをクリックし、ホスト・マシン上で実行されているクラスタウェア・ホームのリストから目的のOracleクラスタウェアのOracleホームを選択します。
「Oracleホームの場所」と「ホスト」の各フィールドに適切な値が入ります。

2. 「Oracleホーム資格証明」セクションで、管理するターゲットへのアクセスに使用する資格証明のタイプを選択します。資格証明の設定の詳細は、第2.3項を参照してください。

3. 「作業ディレクトリ」および「除外するファイル」セクションで、書込み権限があるホスト上の「作業ディレクトリ」を入力し、クローニングされたzipファイルを作成して一時的に保管できるようにします。
「除外するファイル」フィールドは、クローニングされたzipファイルから除外される特定のタイプのファイルまたはパターンで事前に移入されます。ただし、要件に基づいて、このリストをカスタマイズできます。

4. 「ソフトウェア・ライブラリのアップロード場所」セクションで、Oracleクラスタウェア・クローン・ソフトウェアを格納する構成済の記憶域の場所をリストから選択します。
ソフトウェア・ライブラリの記憶域の場所を作成する方法については、第2.2項を参照してください。

7. 「確認」ページで詳細をすべて確認してから「保存とアップロード」をクリックすると、コンポーネントが作成されてバイナリがソフトウェア・ライブラリにアップロードされます。

4.3.10.4 外部記憶域からのOracleクラスタウェア・クローンの作成

外部記憶域の場所からOracleクラスタウェア・クローンを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ・ホーム」ページで、データベース・クローン・コンポーネントを作成するために任意のカスタム・フォルダを選択します。

3. 「アクション」メニューから「エンティティの作成」、「コンポーネント」の順に選択します。または、カスタム・フォルダを右クリックし、メニューから「エンティティの作成」、「コンポーネント」の順に選択します。

4. 「エンティティの作成: コンポーネント」ダイアログ・ボックスから「Oracleクラスタウェア・クローン」を選択し、「続行」をクリックします。
「Oracleクラスタウェア・クローンの作成: 説明」ページが表示されます。

5. 説明ページで、「名前」、「説明」、およびエンティティを説明する「その他の属性」を入力します。
注意: コンポーネント名は、属する親フォルダに対して一意である必要があります。一意の名前を入力したときでさえ、競合が報告される場合があります。これは、表示権限がないために表示できないが、フォルダ内に同じ名前のエンティティがあるために起こります。

追加をクリックし、readme、コラテラル、ライセンスなどの、エンティティをより適切に説明するファイルを添付します。ファイル・サイズが2 MB未満であることを確認してください。

「ノート」フィールドで、エンティティに対して行った変更や、追跡したい変更履歴など、エンティティに関連する情報を追加します。

6. 「構成」ページで、「コンポーネントの作成元」メニューから「既存のOracleホームのアーカイブ」を選択し、次のようにします。

1. 「Oracleホーム・アーカイブ」セクションで、Oracleクラスタウェア・クローン・ソフトウェアを参照できる外部記憶域の場所を選択します。「外部ストレージの場所名」メニューから場所名を選択します。
外部記憶域の場所を構成する方法については、第2.2項を参照してください。

「Oracleホーム・アーカイブの場所」に正確なパスを入力します。これは基本的に、外部記憶域にあるアーカイブ・ファイルへの、構成された場所からの相対的なパスです。アーカイブ・ファイルが有効なZIPファイルであることを確認してください。

注意:
Oracleホームのzipファイルを作成するには、次の構文を使用します。

<ZIP  PATH>/zip -r -S -9 -1 <archiveName.zip> <directory or list  of files to be archived> -x <patterns to exclude files>

2. 「Oracleホームのプロパティ」セクションで、「製品」、「バージョン」および「プラットフォーム」の各値を選択します。これらの構成プロパティはエンティティを検索または追跡する際に特に役に立ちます。

7. 「確認」ページで詳細をすべて確認してから「保存とアップロード」をクリックすると、コンポーネントが作成されてバイナリがソフトウェア・ライブラリにアップロードされます。

4.3.11 クラスタ検証ユーティリティのダウンロード

クラスタ検証ユーティリティ(CVU)は、インストール、パッチ更新またはその他のシステム変更に備えてシステム・チェックを行います。クラスタ検証ユーティリティ(CVU)バイナリをソフトウェア・ライブラリと同期させることができます。

Enterprise Managerには、ソフトウェア・ライブラリ内の対応するバイナリを更新する必要がある場合、My Oracle Supportからバイナリを毎日ダウンロードするようスケジュールされたルーチン・ジョブがデフォルトで提供されています。Enterprise Managerデプロイメントが、My Oracle SupportへのHTTP接続が無効になるようにファイアウォールまたはDMZの内側にある場合、ルーチン・ジョブは実行をスキップします。この場合は、パッチ16766985をソースとして使用し、OTNまたはMy Oracle Supportからプラットフォームに対応するCVUバイナリを手動でダウンロードできます。手動でダウンロードしたクラスタ検証ユーティリティ(CVU)バイナリは、次のようにしてソフトウェア・ライブラリに同期できます。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. 「データベースのプロビジョニング」ページで「CVUの設定」をクリックします。

3. クラスタ検証ユーティリティのダウンロード・ページで次のいずれかを選択します。

1. ローカル・コンピュータからCVUバイナリを選択する場合は、「ローカル・マシン」。

2. エージェント・コンピュータからCVUバイナリを選択する場合は、「エージェント・マシン」。

4. 「OK」をクリックします。これによって、最新のクラスタ検証ユーティリティ・バイナリでソフトウェア・ライブラリが更新されます。

5 Oracle Databaseのプロビジョニング

この章では、Oracle Enterprise Manager Cloud Control(Cloud Control)を使用して、Oracle Database(単一インスタンスデータベースとも呼ばれます)を自動的、反復可能で、信頼できる方法で一括デプロイする方法について説明します。この章の具体的な内容は次のとおりです。

- Oracle Databaseのプロビジョニングの概要

- Oracle Databaseトポロジ

- Oracle Databaseのプロビジョニングおよび作成

- Oracle Automatic Storage Managementを使用したOracle Databaseのプロビジョニング

- Oracle Databaseソフトウェアのみのプロビジョニング

5.1 Oracleデータベースのプロビジョニングの概要

この項では、この章に取り組むための手引きとして、Oracle Databaseのプロビジョニング手順の概要を説明します。この項は、単一インスタンス・データベースのプロビジョニングを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表5-1 Oracle Databaseのプロビジョニングの概要

ステップ

説明

参照リンク

ステップ1

Oracle Databaseトポロジの理解

単一インスタンス・データベースのプロビジョニング用にCloud Controlにより提供されるデータベース・プロビジョニング機能について理解します。

Oracle Databaseトポロジの詳細は、第5.2項を参照してください。

ステップ2

ユースケースの選択

ここでは、Oracle Databaseのプロビジョニングのユースケースのいくつかを説明します。ご自身の要件に最適なユースケースを選択してください。

- Oracle Databaseのプロビジョニングおよび構成の詳細は、第5.3項を参照してください。

- 自動ストレージ管理を使用したOracle Databaseのプロビジョニングの前提条件の詳細は、第5.4項を参照してください。

- Oracle Databaseソフトウェアのプロビジョニングの詳細は、第5.5項を参照してください。

ステップ3

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

- Oracle Databaseをプロビジョニングおよび構成するための前提条件の詳細は、第5.3.1項を参照してください。

- 自動ストレージ管理を使用したOracle Databaseのプロビジョニングの前提条件の詳細は、第5.4.1項を参照してください。

- Oracle Databaseソフトウェアのプロビジョニングの前提条件の詳細は、第5.5.1項を参照してください。

ステップ4

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行してOracle Databaseを正常にプロビジョニングします。

- Oracle Databaseをプロビジョニングおよび構成するには、第5.3.2項を参照してください。

- 自動ストレージ管理を使用してOracle Databaseをプロビジョニングするには、第5.4.2項を参照してください。

- Oracle Databaseソフトウェアをプロビジョニングするには、第5.5.2項を参照してください。

5.2 Oracle Databaseトポロジ

図5-1に、Cloud Controlを使用してプロビジョニングできる一般的なOracle Database (単一インスタンス・データベース)トポロジを示します。

図5-1 Oracle Databaseトポロジ

このトポロジは、グリッド・インフラストラクチャ11.2.0.3の単一インスタンスの高可用性(SIHA)コンポーネントにより管理される11.2.0.3 RDBMSを示します。トポロジのソフトウェア・コンポーネントは、次のとおりです。

- グリッド・インフラストラクチャ・ホームから実行されるOracle High Availabilityデーモン。

- グリッド・インフラストラクチャ・ホームから実行される単一インスタンスOracle ASM。

- Oracle DatabaseのOracleホームから実行される単一インスタンスOracle Database。

トポロジのハードウェア・コンポーネントは、次のとおりです。

- パブリック・インタフェースを備えたデータベース・ホスト。

- ASMディスクRAIDにリンクする専用ストレージ・ネットワーク。

5.3 Oracle Databaseのプロビジョニングおよび作成

この項では、Oracleデータベースをプロビジョニングおよび作成する方法について説明します。

この項の具体的な内容は次のとおりです。

- データベースをプロビジョニングするための前提条件

- データベースをプロビジョニングする手順

5.3.1 データベースをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、第4.3項に示す前提条件を満たしている必要があります。

5.3.2 データベースをプロビジョニングする手順

データベースをプロビジョニングするためにデプロイメント・プロシージャを実行するには、次の手順を実行します。

1. デザイナとしてログインし、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. 「データベース・プロシージャ」ページで「Oracleデータベースのプロビジョニング」を選択し、「起動」をクリックします。Oracleデータベースのプロビジョニング・ウィザードが起動します。

3. 「ホストの選択」ページで、プロビジョニング・プロファイルをデプロイメントに使用する場合は、「プロビショニング・プロファイルを選択」で、事前に保存した構成パラメータを含むプロファイルを選択します。
「宛先ホストの選択」セクションで、「追加」をクリックし、ソフトウェアをデプロイおよび構成する宛先ホストを選択します。

「実行するタスクの選択」セクションで、プラットフォーム、プロセスのバージョンおよびプロビジョニングするコンポーネントを選択します。

- グリッド・インフラストラクチャをデプロイするには、グリッド・インフラストラクチャのデプロイと構成、「ソフトウェアのデプロイのみ」または「プロビジョニングしない」のいずれかを選択します。

- データベース・ソフトウェアをデプロイするには、「ソフトウェアのデプロイのみ」または新規データベースのデプロイと作成(スタンドアロンのOracle Databaseのインストール後に新規データベースを作成し構成する)のいずれかを選択します。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。デプロイメント・プロシージャのロック・ダウン機能の詳細は、第4.1項を参照してください。

「次へ」をクリックします。

4. 構成ページには、各種構成オプションが表示されます。ホスト設定、「ソフトウェアのデプロイ」、「グリッド・インフラストラクチャの構成」および「データベースの作成」タスクに値を入力します。

5. 「ホストの設定」リンクをクリックします。

6. 「OSユーザーの指定」ページで、データベースのOracleホームのオペレーティング・システム・ユーザーを指定します。

注意:
非root資格証明を使用するには、「Oracle Databaseのプロビジョニングでの非root資格証明の使用」を参照してください。

データベースの「Oracleホーム・ユーザー」については、OSグループに追加する「通常ユーザー」および「特権ユーザー」を選択します。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。

「次へ」をクリックします。

7. OSグループの指定ページで、オペレーティング・システム認証に使用するOSグループを指定します。次のロールに対応するグループが、プロビジョニングに選択したホストにすでに存在していることを確認します。

- インベントリ・グループ(OINSTALL)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

これらのグループが、選択したホストでプロビジョニング用にすでに存在することを確認します。それらが存在しない場合、ホスト上に存在する別のグループを指定するか、次で使用可能な『Oracle Databaseクイック・インストレーション・ガイド』に従って、新しいグループを作成します。

http://www.oracle.com/pls/db112/homepage

作成する新しいグループまたは指定する別のグループは、データベースが構成された後で、自動的にSYSDBAおよびSYSOPER権限を取得します。

詳細は、次で使用可能な『Oracle Database 2日でデータベース管理者ガイド』を参照してください。

http://www.oracle.com/pls/db112/homepage

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。

「次へ」をクリックします。構成ページに戻ります。宛先ホストを構成してある場合は、「ホストの設定」タスクが完了ステータスになります。

8. 「ソフトウェアのデプロイ」リンクをクリックします。

9. 「ソフトウェアの場所の選択」ページで、Oracle Databaseのソフトウェア・バイナリのソースおよび宛先の場所を指定します。
「ソース」セクションで「Oracleデータベース」のソフトウェア・ライブラリの場所を選択します。

注意:
Windowsオペレーティング・システムでは、選択されているOracle Databaseコンポーネントがバージョン12.1以上の場合に、すべてのサービスを、限られた権限を持つ指定されたOracleサービス・ユーザーとしてインストールできます。これにより、データベース・サービスのセキュリティが向上します。
「Windowsセキュリティ・オプション」セクションで、既存のユーザーのオプションを構成するかユーザーを追加し、「ユーザー名」および「パスワード」を指定できます。すべてのサービスを管理ユーザーとしてインストールおよび構成する場合は、「セキュリティ・オプションを却下」を選択します。

「宛先ロケーション」では、次を指定します。

- データベース用Oracleベース: 診断および管理ログ、およびその他のデータベース関連ログを格納できる宛先ホストの場所。この場所はダンプ・ファイルの格納にのみ使用され、データベース・ソフトウェアがインストールされるOracleホーム・ディレクトリとは別の場所になります。

- データベースのOracleホーム: データベース・ソフトウェアをプロビジョニングできる宛先ホストの場所。これはデータベース用のOracleホーム・ディレクトリです。

「追加パラメータ」セクションで、クローン関連のファイルを一時的に格納する宛先ホスト上で「作業ディレクトリ」を指定します。このディレクトリには、約7GBの空き領域があることを確認します。「インストーラ・パラメータ」には、Oracle Databaseのプロビジョニング時に実行する追加のOracle Universal Installer (OUI)パラメータを指定します。たとえば、-force (警告を上書き)、-debug (デバッグ情報を詳細に表示)、および-invPtrLoc <Location> (UNIXのみ)と指定します。パラメータは必ず空白で区切ります。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。

「次へ」をクリックします。構成ページに戻ります。ソフトウェアのソースおよび宛先の場所を構成してある場合は、「ソフトウェアの構成」タスクが完了ステータスになります。

10. 「データベースの作成」リンクをクリックします。

11. データベース・テンプレート・ページでは、データベース・テンプレートの場所を選択します。この場所はソフトウェア・ライブラリまたはOracleホームのいずれかにできます。選択したテンプレートは、選択したOracleホームのバージョンと互換性を保っている必要があります。
「ソフトウェア・ライブラリからのテンプレートの選択」を選択した場合は、検索アイコンをクリックして、「ソフトウェア・ライブラリ」からテンプレートを選択します。「管理対象ホスト上の一時的な格納場所」を指定します。この場所は、データベースを作成するすべてのホスト上に存在する必要があります。

「テンプレートの詳細の表示」をクリックし、選択したテンプレートの詳細を表示します。初期化パラメータ、表領域、データファイル、REDOログ・グループ、共通オプション、およびテンプレートの他の詳細を表示できます。

「Oracleホームからのテンプレートの選択」を選択した場合は、「Oracleホーム」からテンプレートを選択します。デフォルトの場所はORACLE_HOME/assistants/dbca/templatesです。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

12. 「IDおよび配置」ページでは、データベース構成の詳細を指定します。「グローバル・データベース名」および「SID」接頭辞を指定します。SYS、SYSTEMおよびDBSNMPデータベース・アカウントに対し、「データベース資格証明」を指定します。これらのアカウントでは、同じ管理パスワードを使用することも異なる管理パスワードを使用することもできます。

注意:

- SIDは1つのホスト上の1つのデータベースに対して一意である必要があります。つまり、あるホスト上の1つのデータベースに割り当てられたSIDは、同じホスト上の別のデータベースでは再使用できませんが、別のホスト上の別のデータベースでは再使用できます。たとえば、1つのホスト(host1)に2つのデータベース(db1およびdb2)がある場合、そのSIDは一意である必要があります。しかし、別のホスト(host2)に3つ目のデータベースをインストールする場合、そのSIDはdb1やdb2でもかまいません。

- グローバル・データベース名は、1つのホスト上の1つのデータベースに対しても、異なるホスト間でのデータベースに対しても一意である必要があります。つまり、あるホスト上の1つのデータベースに割り当てられたグローバル・データベース名は、同じホスト上の別のデータベースでも、別のホスト上の別のデータベースでも再使用できません。たとえば、1つのホスト(host1)に2つのデータベース(db1およびdb2)がある場合、そのグローバル・データベース名は一意である必要があります。さらに、別のホスト(host2)に3つ目のデータベースをインストールする場合、このデータベースのグローバル・データベース名は、Cloud Controlに登録された他のすべての名前とは異なり、一意である必要があります。

- ここで指定したデータベースの資格証明がすべての宛先ホストで使用されます。しかし、プロビジョニング後に、データベースのパスワードを変更する場合は、手動で変更する必要があります。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

13. 記憶域の場所ページで、記憶域タイプとして「ファイル・システム」または「自動ストレージ管理(ASM)」を選択します。
ファイル・システムを使用する場合は、「ファイルシステム」を選択し、データ・ファイルのある場所へのフルパスを指定します。たとえば、%ORACLE_BASE%/oradataや/u01/product/db/oradataなどです。

ASMを使用する場合は、「自動ストレージ管理(ASM)」を選択して懐中電灯アイコンをクリックし、ディスク・グループ名を選択してASMSNMPパスワードを指定します。「ディスク・グループ名リスト」ウィンドウに、すべての宛先ホストで共通のディスク・グループが表示されます。

「データベース・ファイルの場所」セクションで、データファイル、一時ファイル、REDOログおよび制御ファイルを格納する場所を指定します。

- テンプレートからのデータベース・ファイルの場所を使用を選択し、使用されているテンプレートからのデフォルトを選択します。

- 全データベース・ファイルの共通の場所の使用を選択し、別の場所を指定します。
「REDOログおよび制御ファイルを多重化」セクションで「Oracle Managed Files(OMF)の使用」オプションを選択すると、REDOログ・ファイルおよび制御ファイルの重複コピーを格納できます。多重化によって強力なフォルト・トレランスが提供されます。最大5つの場所を指定できます。

「リカバリ・ファイルの場所」セクションで、「データベース・ファイルの場所と同じ記憶域タイプを使用してください」を選択し、リカバリ・ファイルの記憶域タイプにデータベース・ファイルと同じタイプを使用します。「フラッシュ・リカバリ領域の使用」を選択し、リカバリ関連ファイルの場所および高速リカバリ領域サイズを指定します。

「アーカイブ有効化」を選択してアーカイブのログを有効にします。「アーカイブ・ロブの場所を指定してください」をクリックし、最大9箇所のアーカイブ・ログの場所を指定します。ログの場所を指定しない場合、ログはデフォルトの場所に保存されます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

14. 初期化パラメータ・ページで、メモリー管理タイプとして「自動メモリー管理」または「自動共有メモリー管理」を選択します。「メモリー設定として使用可能メモリーの割合」を選択し、メモリー設定として使用可能物理メモリーの割合を指定します。自動共有メモリー管理の場合は、「SGA合計」および「PGA合計」を指定します。自動メモリー管理の場合は、「Oracleで使用するメモリーの合計」を指定します。
「データベースのサイズ設定」セクションで、「ブロック・サイズ」および「プロセス」の数を指定します。データベース・テンプレート・ページでデータファイルとともにデータベース・テンプレートを選択した場合、ブロック・サイズは編集できません。

「ホストCPU数」を指定します。指定できる最大CPU数はホストに存在するCPUの数と同じです。

「キャラクタ・セット」セクションでは、デフォルトのキャラクタ・セットを選択します。デフォルトのキャラクタ・セットはロケールおよびオペレーティング・システムに基づいています。

各国語キャラクタ・セットを選択します。デフォルトはAL16UTF16です。

「データベース接続モード」セクションでは、専用サーバー・モードを選択します。共有サーバー・モードについては、共有サーバーの数を指定します。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

15. 「追加の構成オプション」に、Oracleホームから実行されているすべての使用可能なリスナーがリストされます。リスナーを選択するか、新規リスナーを作成できます。データベースに登録する複数のリスナーを選択できます。新規リスナーを作成するには、「リスナー名」および「ポート」を指定します。データベース・スキーマを選択し、カスタム・スクリプトがある場合はこれを指定します。データベースを作成するホストまたはソフトウェア・ライブラリからカスタム・スクリプトを選択します。複数のホストを選択した場合は、ソフトウェア・ライブラリからのみスクリプトを指定できます。
データベース・テンプレート・ページで「構造のみ」データベース・テンプレートを選択した場合、データベース・オプションを表示および編集することもできます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

16. データベースを作成するために指定した詳細を確認し、「次へ」をクリックします。構成ページに戻ります。データベースを構成してある場合は、「データベースの作成」タスクが完了ステータスになります。

17. 「コンプライアンス標準」リンクをクリックします。

18. 「構成標準ターゲット・アソシエーション」ページで、データベースと関連付けるコンプライアンス標準を選択します。「次へ」をクリックします。

19. 「スケジュール」ページで、デプロイメント・インスタンス名を指定します。プロシージャを即時に実行する場合は、デフォルトの選択(「1回(即時)」)を保持します。プロシージャを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。デプロイメント・プロシージャのステータスに応じて、通知プリファレンスを設定できます。前提条件のみを実行する場合は、「前提条件チェックの実行後に結果を分析するためにプロシージャを停止します」を選択すると、すべての前提条件チェックの実行後にプロシージャ実行を一時停止できます。
「次へ」をクリックします。

20. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。

21. オペレータ・ロールで、保存したデプロイメント・プロシージャを起動します。プロビジョニングのターゲットを追加し、デプロイメント・プロシージャの構成可能フィールドに値を指定します。

22. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各ステップの「ステータス」リンクをクリックし、各ステップの実行の詳細を表示します。「デバッグ」をクリックしてデバッグのロギング・レベルを設定し、「停止」をクリックしてプロシージャの実行を停止できます。

23. プロシージャの実行の完了後、「ターゲット」メニューをクリックし、「すべてのターゲット」を選択して、「すべてのターゲット」ページに移動し、新しく作成したデータベースがCloud Controlターゲットとして表示されることを確認します。

5.4 Oracle Automatic Storage Managementを使用したOracle Databaseのプロビジョニング

この項では、Oracle Automatic Storage Management(Oracle ASM)を使用して単一インスタンス・データベースをプロビジョニングする方法について説明します。

この項の具体的な内容は次のとおりです。

- Oracle Automatic Storage Managementを使用してOracleデータベースをプロビジョニングするための前提条件

- データベースをプロビジョニングする手順

5.4.1 Oracle Automatic Storage Managementを使用してOracleデータベースをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、第4.3項に示す前提条件を満たしている必要があります。

5.4.2 データベースをプロビジョニングする手順

Oracle Automatic Storage Management (Oracle ASM)を使用して単一インスタンス・データベースをプロビジョニングするには、次の手順を実行します。

1. デザイナとしてログインし、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. 「データベース・プロシージャ」ページで「Oracleデータベースのプロビジョニング」を選択し、「起動」をクリックします。Oracleデータベースのプロビジョニング・ウィザードが起動します。

3. 「ホストの選択」ページで、プロビジョニング・プロファイルをデプロイメントに使用する場合は、「プロビショニング・プロファイルを選択」で、事前に保存した構成パラメータを含むプロファイルを選択します。
「宛先ホストの選択」セクションで、「追加」をクリックし、ソフトウェアをデプロイおよび構成する宛先ホストを選択します。

「実行するタスクの選択」セクションで、プラットフォーム、プロセスのバージョンおよびプロビジョニングするコンポーネントを選択します。

- グリッド・インフラストラクチャをデプロイするには、グリッド・インフラストラクチャのデプロイと構成、「ソフトウェアのデプロイのみ」または「プロビジョニングしない」のいずれかを選択します。

- データベース・ソフトウェアをデプロイするには、「ソフトウェアのデプロイのみ」または新規データベースのデプロイと作成(スタンドアロンのOracle Databaseのインストール後に新規データベースを作成し構成する)のいずれかを選択します。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。デプロイメント・プロシージャのロック・ダウン機能の詳細は、第4.1項を参照してください。

「次へ」をクリックします。

4. 「構成」ページで、「ホストの設定」リンクをクリックします。

5. 「OSユーザーの指定」ページで、データベースのOracleホームのオペレーティング・システム・ユーザーを指定します。

注意:
非root資格証明を使用するには、「Oracle Databaseのプロビジョニングでの非root資格証明の使用」を参照してください。

データベースの「Oracleホーム・ユーザー」については、OSグループに追加する「通常ユーザー」および「特権ユーザー」を選択します。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。

「次へ」をクリックします。

6. OSグループの指定ページで、オペレーティング・システム認証に使用するOSグループを指定します。次のロールに対応するグループが、プロビジョニングに選択したホストにすでに存在していることを確認します。

- インベントリ・グループ(OINSTALL)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

これらのグループが、選択したホストでプロビジョニング用にすでに存在することを確認します。それらが存在しない場合、ホスト上に存在する別のグループを指定するか、次で使用可能な『Oracle Databaseクイック・インストレーション・ガイド』に従って、新しいグループを作成します。

http://www.oracle.com/pls/db112/homepage

作成する新しいグループまたは指定する別のグループは、データベースが構成された後で、自動的にSYSDBAおよびSYSOPER権限を取得します。

詳細は、次で使用可能な『Oracle Database 2日でデータベース管理者ガイド』を参照してください。

http://www.oracle.com/pls/db112/homepage

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。

「次へ」をクリックします。構成ページに戻ります。宛先ホストを構成してある場合は、「ホストの設定」タスクが完了ステータスになります。

7. 「ソフトウェアのデプロイ」リンクをクリックします。

8. 「ソフトウェアの場所の選択」ページで、Oracle Databaseのソフトウェア・バイナリのソースおよび宛先の場所を指定します。
「ソース」セクションで「Oracleデータベース」のソフトウェア・ライブラリの場所を選択します。

「宛先ロケーション」では、次を指定します。

- データベース用Oracleベース: 診断および管理ログ、およびその他のデータベース関連ログを格納できる宛先ホストの場所。この場所はダンプ・ファイルの格納にのみ使用され、データベース・ソフトウェアがインストールされるOracleホーム・ディレクトリとは別の場所になります。

- データベースのOracleホーム: データベース・ソフトウェアをプロビジョニングできる宛先ホストの場所。これはデータベース用のOracleホーム・ディレクトリです。

「追加パラメータ」セクションで、クローン関連のファイルを一時的に格納する宛先ホスト上で「作業ディレクトリ」を指定します。このディレクトリには、約7GBの空き領域があることを確認します。インストーラ・パラメータについては、Oracle Grid Infrastructureのプロビジョニング時に実行する追加のOracle Universal Installer (OUI)パラメータを指定します。たとえば、-force (警告を上書き)、-debug (デバッグ情報を詳細に表示)、および-invPtrLoc <Location> (UNIXのみ)と指定します。パラメータは必ず空白で区切ります。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。

「次へ」をクリックします。構成ページに戻ります。ソフトウェアのソースおよび宛先の場所を構成してある場合は、「ソフトウェアの構成」タスクが完了ステータスになります。

9. 「データベースの作成」リンクをクリックします。

10. データベース・テンプレート・ページでは、データベース・テンプレートの場所を選択します。この場所はソフトウェア・ライブラリまたはOracleホームのいずれかにできます。選択したテンプレートは、選択したOracleホームのバージョンと互換性を保っている必要があります。
「ソフトウェア・ライブラリからのテンプレートの選択」を選択した場合は、検索アイコンをクリックして、「ソフトウェア・ライブラリ」からテンプレートを選択します。「管理対象ホスト上の一時的な格納場所」を指定します。この場所は、データベースを作成するすべてのホスト上に存在する必要があります。

「テンプレートの詳細の表示」をクリックし、選択したテンプレートの詳細を表示します。初期化パラメータ、表領域、データファイル、REDOログ・グループ、共通オプション、およびテンプレートの他の詳細を表示できます。

「Oracleホームからのテンプレートの選択」を選択した場合は、「Oracleホーム」からテンプレートを選択します。デフォルトの場所はORACLE_HOME/assistants/dbca/templatesです。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

11. 「IDおよび配置」ページでは、データベース構成の詳細を指定します。「グローバル・データベース名」および「SID」接頭辞を指定します。SYS、SYSTEMおよびDBSNMPデータベース・アカウントに対し、「データベース資格証明」を指定します。これらのアカウントでは、同じ管理パスワードを使用することも異なる管理パスワードを使用することもできます。

注意:

- SIDは1つのホスト上の1つのデータベースに対して一意である必要があります。つまり、あるホスト上の1つのデータベースに割り当てられたSIDは、同じホスト上の別のデータベースでは再使用できませんが、別のホスト上の別のデータベースでは再使用できます。たとえば、1つのホスト(host1)に2つのデータベース(db1およびdb2)がある場合、そのSIDは一意である必要があります。しかし、別のホスト(host2)に3つ目のデータベースをインストールする場合、そのSIDはdb1やdb2でもかまいません。

- グローバル・データベース名は、1つのホスト上の1つのデータベースに対しても、異なるホスト間でのデータベースに対しても一意である必要があります。つまり、あるホスト上の1つのデータベースに割り当てられたグローバル・データベース名は、同じホスト上の別のデータベースでも、別のホスト上の別のデータベースでも再使用できません。たとえば、1つのホスト(host1)に2つのデータベース(db1およびdb2)がある場合、そのグローバル・データベース名は一意である必要があります。さらに、別のホスト(host2)に3つ目のデータベースをインストールする場合、このデータベースのグローバル・データベース名は、Cloud Controlに登録された他のすべての名前とは異なり、一意である必要があります。

- ここで指定したデータベースの資格証明がすべての宛先ホストで使用されます。しかし、プロビジョニング後に、データベースのパスワードを変更する場合は、手動で変更する必要があります。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

12. 「記憶域の場所」ページで、「自動ストレージ管理(ASM)」として記憶域タイプを選択して懐中電灯アイコンをクリックし、ディスク・グループ名を選択してASMSNMPパスワードを指定します。「ディスク・グループ名リスト」ウィンドウに、すべての宛先ホストで共通のディスク・グループが表示されます。
「データベース・ファイルの場所」セクションで、データファイル、一時ファイル、REDOログおよび制御ファイルを格納する場所を指定します。

- テンプレートからのデータベース・ファイルの場所を使用を選択し、使用されているテンプレートからのデフォルトを選択します。

- 全データベース・ファイルの共通の場所の使用を選択し、別の場所を指定します。
「REDOログおよび制御ファイルを多重化」セクションで「Oracle Managed Files(OMF)の使用」オプションを選択すると、REDOログ・ファイルおよび制御ファイルの重複コピーを格納できます。多重化によって強力なフォルト・トレランスが提供されます。最大5つの場所を指定できます。

「リカバリ・ファイルの場所」セクションで、「データベース・ファイルの場所と同じ記憶域タイプを使用してください」を選択し、リカバリ・ファイルの記憶域タイプにデータベース・ファイルと同じタイプを使用します。「フラッシュ・リカバリ領域の使用」を選択し、リカバリ関連ファイルの場所および高速リカバリ領域サイズを指定します。

「アーカイブ有効化」を選択してアーカイブのログを有効にします。「アーカイブ・ロブの場所を指定してください」をクリックし、最大9箇所のアーカイブ・ログの場所を指定します。ログの場所を指定しない場合、ログはデフォルトの場所に保存されます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

13. 初期化パラメータ・ページで、メモリー管理タイプとして「自動メモリー管理」または「自動共有メモリー管理」を選択します。「メモリー設定として使用可能メモリーの割合」を選択し、メモリー設定として使用可能物理メモリーの割合を指定します。自動共有メモリー管理の場合は、「SGA合計」および「PGA合計」を指定します。自動メモリー管理の場合は、「Oracleで使用するメモリーの合計」を指定します。
「データベースのサイズ設定」セクションで、「ブロック・サイズ」および「プロセス」の数を指定します。データベース・テンプレート・ページでデータファイルとともにデータベース・テンプレートを選択した場合、ブロック・サイズは編集できません。

「ホストCPU数」を指定します。指定できる最大CPU数はホストに存在するCPUの数と同じです。

「キャラクタ・セット」セクションでは、デフォルトのキャラクタ・セットを選択します。デフォルトのキャラクタ・セットはロケールおよびオペレーティング・システムに基づいています。

各国語キャラクタ・セットを選択します。デフォルトはAL16UTF16です。

「データベース接続モード」セクションでは、専用サーバー・モードを選択します。共有サーバー・モードについては、共有サーバーの数を指定します。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

14. 「追加の構成オプション」に、Oracleホームから実行されているすべての使用可能なリスナーがリストされます。リスナーを選択するか、新規リスナーを作成できます。データベースに登録する複数のリスナーを選択できます。新規リスナーを作成するには、「リスナー名」および「ポート」を指定します。データベース・スキーマを選択し、カスタム・スクリプトがある場合はこれを指定します。データベースを作成するホストまたはソフトウェア・ライブラリからカスタム・スクリプトを選択します。複数のホストを選択した場合は、ソフトウェア・ライブラリからのみスクリプトを指定できます。
データベース・テンプレート・ページで「構造のみ」データベース・テンプレートを選択した場合、データベース・オプションを表示および編集することもできます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

15. データベースを作成するために指定した詳細を確認し、「次へ」をクリックします。構成ページに戻ります。データベースを構成してある場合は、「データベースの作成」タスクが完了ステータスになります。

16. 「コンプライアンス標準」リンクをクリックします。

17. 「構成標準ターゲット・アソシエーション」ページで、データベースと関連付けるコンプライアンス標準を選択します。「次へ」をクリックします。

18. 「構成」ページで「次へ」をクリックします。

19. カスタム・パラメータが必要なユーザー・カスタマイズ済デプロイメント・プロシージャに対してのみカスタム・プロパティ・ページが表示されます。デプロイに関するカスタム・プロパティ(存在する場合)を指定します。「次へ」をクリックします。

20. 「スケジュール」ページで、デプロイメント・インスタンス名を指定します。プロシージャを即時に実行する場合は、デフォルトの選択(「1回(即時)」)を保持します。プロシージャを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。デプロイメント・プロシージャのステータスに応じて、通知プリファレンスを設定できます。前提条件のみを実行する場合は、「前提条件チェックの実行後に結果を分析するためにプロシージャを停止します」を選択すると、すべての前提条件チェックの実行後にプロシージャ実行を一時停止できます。
「次へ」をクリックします。

21. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。

22. オペレータ・ロールで、保存したデプロイメント・プロシージャを起動します。プロビジョニングのターゲットを追加し、デプロイメント・プロシージャの構成可能フィールドに値を指定します。

23. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各ステップの「ステータス」リンクをクリックし、各ステップの実行の詳細を表示します。「デバッグ」をクリックしてデバッグのロギング・レベルを設定し、「停止」をクリックしてプロシージャの実行を停止できます。

24. プロシージャの実行の完了後、「ターゲット」メニューをクリックし、「すべてのターゲット」を選択して、「すべてのターゲット」ページに移動し、新しく作成したデータベースがCloud Controlターゲットとして表示されることを確認します。

5.5 Oracle Databaseソフトウェアのみのプロビジョニング

この項では、単一インスタンス・データベース・ソフトウェアのプロビジョニングについて説明します。

この項の具体的な内容は次のとおりです。

- Oracle Databaseソフトウェアのみをプロビジョニングするための前提条件

- Oracle Databaseソフトウェアのみをプロビジョニングする手順

5.5.1 Oracle Databaseソフトウェアのみをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、第4.3項に示す前提条件を満たしている必要があります。

5.5.2 Oracle Databaseソフトウェアのみをプロビジョニングする手順

次の手順に従います。

1. デザイナとしてログインし、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. データベース・プロシージャ・ページでProvision Oracleデータベース・デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracleデータベースのプロビジョニング・ウィザードが起動します。

3. 「ホストの選択」ページで、プロビジョニング・プロファイルをデプロイメントに使用する場合は、「プロビショニング・プロファイルを選択」で、事前に保存した構成パラメータを含むプロファイルを選択します。
「宛先ホストの選択」セクションで、「追加」をクリックし、ソフトウェアをデプロイおよび構成する宛先ホストを選択します。

「実行するタスクの選択」セクションで、「データベース・ソフトウェアのデプロイ」を選択し、単一インスタンス・データベースをプロビジョニングします。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。デプロイメント・プロシージャのロック・ダウン機能の詳細は、第4.1項を参照してください。

「次へ」をクリックします。

4. 「構成」ページで、「ホストの設定」リンクをクリックします。

5. 「OSユーザーの指定」ページで、データベースのOracleホームのオペレーティング・システム・ユーザーを指定します。

注意:
非root資格証明を使用するには、「Oracle Databaseのプロビジョニングでの非root資格証明の使用」を参照してください。

データベースの「Oracleホーム・ユーザー」については、OSグループに追加する「通常ユーザー」および「特権ユーザー」を選択します。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。

「次へ」をクリックします。

6. OSグループの指定ページで、オペレーティング・システム認証に使用するOSグループを指定します。次のロールに対応するグループが、プロビジョニングに選択したホストにすでに存在していることを確認します。

- インベントリ・グループ(OINSTALL)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

これらのグループが存在しない場合、ホスト上に存在する別のグループを指定するか、次で使用可能な『Oracle Databaseクイック・インストレーション・ガイド』に従って、新しいグループを作成します。

http://www.oracle.com/pls/db112/homepage">>http://www.oracle.com/pls/db112/homepage

作成する新しいグループまたは指定する別のグループは、データベースが構成された後で、自動的にSYSDBAおよびSYSOPER権限を取得します。詳細は、次で使用可能な『Oracle Database 2日でデータベース管理者ガイド』を参照してください。

http://www.oracle.com/pls/db112/homepage

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。

「次へ」をクリックします。構成ページに戻ります。宛先ホストを構成してある場合は、「ホストの設定」タスクが完了ステータスになります。

7. 「ソフトウェアのデプロイ」リンクをクリックします。

8. 「ソフトウェアの場所の選択」ページで、Oracle Databaseのソフトウェア・バイナリのソースおよび宛先の場所を指定します。
「ソース」セクションで「Oracleデータベース」のソフトウェア・ライブラリの場所を選択します。

注意:
Windowsオペレーティング・システムでは、選択されているOracle Databaseコンポーネントがバージョン12.1以上の場合に、すべてのサービスを、限られた権限を持つ指定されたOracleサービス・ユーザーとしてインストールできます。これにより、データベース・サービスのセキュリティが向上します。
「Windowsセキュリティ・オプション」セクションで、既存のユーザーのオプションを構成するかユーザーを追加し、「ユーザー名」および「パスワード」を指定できます。すべてのサービスを管理ユーザーとしてインストールおよび構成する場合は、「セキュリティ・オプションを却下」を選択します。

「宛先ロケーション」では、次を指定します。

- データベース用Oracleベース: 診断および管理ログ、およびその他のデータベース関連ログを格納できる宛先ホストの場所。この場所はダンプ・ファイルの格納にのみ使用され、データベース・ソフトウェアがインストールされるOracleホーム・ディレクトリとは別の場所になります。

- データベースのOracleホーム: データベース・ソフトウェアをプロビジョニングできる宛先ホストの場所。これはデータベース用のOracleホーム・ディレクトリです。

「追加パラメータ」セクションで、クローン関連のファイルを一時的に格納する宛先ホスト上で「作業ディレクトリ」を指定します。このディレクトリには、約7GBの空き領域があることを確認します。「インストーラ・パラメータ」には、Oracle Databaseのプロビジョニング時に実行する追加のOracle Universal Installer (OUI)パラメータを指定します。たとえば、-force (警告を上書き)、-debug (デバッグ情報を詳細に表示)、および-invPtrLoc <Location> (UNIXのみ)と指定します。パラメータは必ず空白で区切ります。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。

「次へ」をクリックします。構成ページに戻ります。ソフトウェアのソースおよび宛先の場所を構成してある場合は、「ソフトウェアの構成」タスクが完了ステータスになります。

9. 「スケジュール」ページで、デプロイメント・インスタンス名を指定します。プロシージャを即時に実行する場合は、デフォルトの選択(「1回(即時)」)を保持します。プロシージャを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。デプロイメント・プロシージャのステータスに応じて、通知プリファレンスを設定できます。前提条件のみを実行する場合は、「前提条件チェックの実行後に結果を分析するためにプロシージャを停止します」を選択すると、すべての前提条件チェックの実行後にプロシージャ実行を一時停止できます。
「次へ」をクリックします。

10. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。

11. オペレータ・ロールで、保存したデプロイメント・プロシージャを起動します。プロビジョニングのターゲットを追加し、デプロイメント・プロシージャの構成可能フィールドに値を指定します。

12. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各ステップの「ステータス」リンクをクリックし、各ステップの実行の詳細を表示します。「デバッグ」をクリックしてデバッグのロギング・レベルを設定し、「停止」をクリックしてプロシージャの実行を停止できます。

13. プロシージャの実行の完了後、「ターゲット」メニューをクリックし、「すべてのターゲット」を選択して、「すべてのターゲット」ページに移動し、新しく作成したデータベースがCloud Controlターゲットとして表示されることを確認します。

5.6 Oracle Databaseのプロビジョニングでの非root資格証明の使用

Oracle Databaseのプロビジョニングでは、非root資格証明がサポートされています。この機能を使用するには、次の手順を実行します。

1. 「OSユーザーの指定」ページで、「優先資格証明の上書き」を指定します。表示された「OSユーザーの指定」ダイアログ・ボックスで、通常の名前の資格証明を作成して、「実行権限」を「なし」に設定します。「OK」をクリックします。

2. 通常ユーザーと特権ユーザーの両方に対して、通常の名前の新しい資格証明を選択します。

3. 「送信」をクリックします。
データベースのプロビジョニング・プロセスがroot資格証明を必要とするステップに到達したら、プロセスが停止します。この場合、コマンドラインを手動で実行する必要があります。これを実行するには、環境を$AGENT_HOME,に設定し、次の2つのステップで「方法」フィールドからコマンドラインのコピーを実行します。

- 修正の手動による実行

- rootスクリプトの手動による実行

4. 両方のステップでrootユーザーを使用してコマンドラインを手動で実行したら、「確認」をクリックします。これで、データベースのプロビジョニング・プロセスが、完了するまで続行されます。

6 Oracle Database用のOracle Grid Infrastructureのプロビジョニング

この章では、Oracle Enterprise Manager Cloud Control(Cloud Control)を使用して、Oracle Database(単一インスタンスデータベースとも呼ばれます)用のOracle Grid Infrastructureを自動的、反復可能で、信頼できる方法で一括デプロイする方法について説明します。この章の具体的な内容は次のとおりです。

- OracleデータベースでのOracle Grid Infrastructureのプロビジョニングの概要

- Oracle Automatic Storage Managementを使用したOracle Grid InfrastructureおよびOracle Databaseのプロビジョニング

- Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのみのプロビジョニング

6.1 OracleデータベースでのOracle Grid Infrastructureのプロビジョニングの概要

この項では、この章に取り組むための手引きとして、単一インスタンス・データベース用のOracle Grid Infrastructureのプロビジョニング手順の概要を説明します。この項は、単一インスタンス・データベースを含むOracle Grid Infrastructureのプロビジョニングを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表6-1 Oracle Grid Infrastructureのプロビジョニングの概要

ステップ

説明

参照リンク

ステップ1

ユースケースの選択

ここでは、Oracle Grid Infrastructureのプロビジョニングのユースケースのいくつかを説明します。ご自身の要件に最適なユースケースを選択してください。

- Oracle ASMを使用したグリッド・インフラストラクチャのプロビジョニング、Oracle Databaseのプロビジョニングおよびデータベースの構成の詳細は、第6.2項を参照してください。

- グリッド・インフラストラクチャおよびOracle Databaseソフトウェアのみのプロビジョニングの詳細は、第6.3項を参照してください。

ステップ2

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

- Oracle ASMを使用したグリッド・インフラストラクチャのプロビジョニング、Oracle Databaseのプロビジョニングおよびデータベースの構成を行うための前提条件の詳細は、第6.2.1項を参照してください。

- グリッド・インフラストラクチャおよび単一インスタンス・データベース・ソフトウェアのみをプロビジョニングするための前提条件の詳細は、第6.3.1項を参照してください。

ステップ3

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行してOracle Grid Infrastructureを正常にプロビジョニングします。

- Oracle ASMを使用したグリッド・インフラストラクチャのプロビジョニング、Oracle Databaseのプロビジョニングおよびデータベースの構成を行うには、第6.2.2項で説明する手順に従ってください。

- グリッド・インフラストラクチャおよびOracle Databaseソフトウェアのみをプロビジョニングするには、第6.3.2項で説明する手順に従ってください。

6.2 Oracle Automatic Storage Managementを使用したOracle Grid InfrastructureおよびOracle Databaseのプロビジョニング

この項では、Oracle Automatic Storage Management (Oracle ASM)を使用してOracle Grid Infrastructureおよび単一インスタンス・データベースをプロビジョニングする方法について説明します。

この項の具体的な内容は次のとおりです。

- Oracle ASMを使用してOracle Grid InfrastructureおよびOracleデータベースをプロビジョニングするための前提条件

- Oracle ASMを使用してOracle Grid InfrastructureおよびOracleデータベースをプロビジョニングする手順

6.2.1 Oracle ASMを使用してOracle Grid InfrastructureおよびOracleデータベースをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、第4.3項に示す前提条件を満たしている必要があります。

6.2.2 Oracle ASMを使用してOracle Grid InfrastructureおよびOracleデータベースをプロビジョニングする手順

Oracle ASMを使用してOracle Grid InfrastructureおよびOracleデータベースをプロビジョニングするには、次の手順を実行します。

1. デザイナとしてログインし、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. データベース・プロシージャ・ページでProvision Oracleデータベース・デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracleデータベースのプロビジョニング・ウィザードが起動します。

3. 「ホストの選択」ページで、プロビジョニング・プロファイルをデプロイメントに使用する場合は、「プロビショニング・プロファイルを選択」で、事前に保存した構成パラメータを含むプロファイルを選択します。
「宛先ホストの選択」セクションで、「追加」をクリックし、ソフトウェアをデプロイおよび構成する宛先ホストを選択します。

「実行するタスクの選択」セクションで、プラットフォーム、プロセスのバージョンおよびプロビジョニングするコンポーネントを選択します。

- グリッド・インフラストラクチャをデプロイするには、「ソフトウェアのデプロイのみ」を選択して単一インスタンス・データベースをプロビジョニングします。

- データベース・ソフトウェアをデプロイするには、新規データベースのデプロイと作成(スタンドアロンのOracle Databaseのインストール後に新規データベースを作成し構成する)のいずれかを選択します。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。デプロイメント・プロシージャのロック・ダウン機能の詳細は、第4.1項を参照してください。

「次へ」をクリックします。

4. 「構成」ページで、「ホストの設定」リンクをクリックします。

5. 「OSユーザーの指定」ページで、データベースおよびグリッド・インフラストラクチャのOracleホームのオペレーティング・システム・ユーザーを指定します。OSグループに追加する「通常ユーザー」および「特権ユーザー」を指定します。
「次へ」をクリックします。

6. OSグループの指定ページで、オペレーティング・システム認証に使用するOSグループを指定します。次のロールに対応するグループが、プロビジョニングに選択したホストにすでに存在していることを確認します。

- インベントリ・グループ(OINSTALL)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

- ASMインスタンス管理者(OSASM)

- ASMデータベース管理者(ASMDBA)

- ASMインスタンス・オペレータ(ASMOPER)

それらが存在しない場合、ホスト上に存在する別のグループを指定するか、次で使用可能な『Oracle Databaseクイック・インストレーション・ガイド』に従って、新しいグループを作成します。

http://www.oracle.com/pls/db112/homepage

作成する新しいグループまたは指定する別のグループは、データベースが構成された後で、自動的にSYSDBAおよびSYSOPER権限を取得します。

詳細は、次で使用可能な『Oracle Database 2日でデータベース管理者ガイド』を参照してください。

http://www.oracle.com/pls/db112/homepage

「次へ」をクリックします。構成ページに戻ります。宛先ホストを構成してある場合は、「ホストの設定」タスクが完了ステータスになります。

7. 「ソフトウェアのデプロイ」リンクをクリックします。

8. 「ソフトウェアの場所の選択」ページで、Oracle Databaseのソフトウェア・バイナリのソースおよび宛先の場所を指定します。
「ソース」セクションで「グリッド・インフラストラクチャ」および「Oracleデータベース」バイナリのソフトウェア・ライブラリの場所を選択します。

「宛先ロケーション」では、次を指定します。

- グリッド・インフラストラクチャ用Oracleベース: 診断および管理ログ、およびその他のグリッド・インフラストラクチャに関連するログが格納される宛先ホストの場所。

- グリッド・インフラストラクチャ・ホーム: グリッド・インフラストラクチャのソフトウェアをプロビジョニングできる宛先ホストの場所。これはグリッド・インフラストラクチャのOracleホーム・ディレクトリです。この場所には、グリッド・インフラストラクチャまたはデータベースのOracleベースのサブディレクトリを選択しないでください。

- データベース用Oracleベース: 診断および管理ログ、およびその他のデータベース関連ログを格納できる宛先ホストの場所。この場所はダンプ・ファイルの格納にのみ使用され、データベース・ソフトウェアがインストールされるOracleホーム・ディレクトリとは別の場所になります。

- データベースのOracleホーム: データベース・ソフトウェアをプロビジョニングできる宛先ホストの場所。これはデータベース用のOracleホーム・ディレクトリです。

グリッド・インフラストラクチャの場合、Oracleベースは/u01/app/userでOracleホームは%ORACLE_BASE%/sihahomeです。%ORACLE_BASE%および%GI_ORACLE_BASE%を使用して、それぞれの値に補完される相対パスを指定できます。

「追加パラメータ」セクションで、クローン関連のファイルを一時的に格納する宛先ホスト上で「作業ディレクトリ」を指定します。このディレクトリには、約7GBの空き領域があることを確認します。インストーラ・パラメータについては、Oracle Grid Infrastructureのプロビジョニング時に実行する追加のOracle Universal Installer (OUI)パラメータを指定します。たとえば、-force (警告を上書き)、-debug (デバッグ情報を詳細に表示)、および-invPtrLoc <Location> (UNIXのみ)と指定します。パラメータは必ず空白で区切ります。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。

「次へ」をクリックします。構成ページに戻ります。ソフトウェアのソースおよび宛先の場所を構成してある場合は、「ソフトウェアの構成」タスクが完了ステータスになります。

9. 「グリッド・インフラストラクチャの構成」リンクをクリックします。

10. 「グリッド・インフラストラクチャの構成」ページの「ASM記憶域」セクションで、「追加」をクリックしてASMディスク・グループを追加します。ディスク・グループの追加/編集ダイアログ・ボックスでは、「ディスク・グループ名」および「ディスク・リスト」を指定し、冗長性を「標準」、「高」または「外部」に指定します。「OK」をクリックします。
ASM 11.2以降では、パラメータ・ファイルの保存用に「ディスク・グループ名」を指定します。ASMSNMPおよびSYSユーザー用の「ASMパスワード」を指定します。ASMインスタンスを登録するためのリスナー・ポートを指定します。

設計者として、鍵アイコンをクリックしてこれらのフィールドをロックできます。ロックすると、これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。構成ページに戻ります。グリッド・インフラストラクチャおよびデータベースの記憶域オプションを構成してある場合は、「グリッド・インフラストラクチャの構成」タスクが完了ステータスになります。

11. 「データベースの作成」リンクをクリックします。

12. データベース・テンプレート・ページでは、データベース・テンプレートの場所を選択します。この場所はソフトウェア・ライブラリまたはOracleホームのいずれかにできます。選択したテンプレートは、選択したOracleホームのバージョンと互換性を保っている必要があります。
「ソフトウェア・ライブラリからのテンプレートの選択」を選択した場合は、検索アイコンをクリックして、「ソフトウェア・ライブラリ」からテンプレートを選択します。「管理対象ホスト上の一時的な格納場所」を指定します。この場所は、データベースを作成するすべてのホスト上に存在する必要があります。

「テンプレートの詳細の表示」をクリックし、選択したテンプレートの詳細を表示します。初期化パラメータ、表領域、データファイル、REDOログ・グループ、共通オプション、およびテンプレートの他の詳細を表示できます。

「Oracleホームからのテンプレートの選択」を選択した場合は、「Oracleホーム」からテンプレートを選択します。デフォルトの場所はORACLE_HOME/assistants/dbca/templatesです。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

13. 「IDおよび配置」ページでは、データベース構成の詳細を指定します。「グローバル・データベース名」および「SID」接頭辞を指定します。SYS、SYSTEMおよびDBSNMPデータベース・アカウントに対し、「データベース資格証明」を指定します。これらのアカウントでは、同じ管理パスワードを使用することも異なる管理パスワードを使用することもできます。

注意:

- SIDは1つのホスト上の1つのデータベースに対して一意である必要があります。つまり、あるホスト上の1つのデータベースに割り当てられたSIDは、同じホスト上の別のデータベースでは再使用できませんが、別のホスト上の別のデータベースでは再使用できます。たとえば、1つのホスト(host1)に2つのデータベース(db1およびdb2)がある場合、そのSIDは一意である必要があります。しかし、別のホスト(host2)に3つ目のデータベースをインストールする場合、そのSIDはdb1やdb2でもかまいません。

- グローバル・データベース名は、1つのホスト上の1つのデータベースに対しても、異なるホスト間でのデータベースに対しても一意である必要があります。つまり、あるホスト上の1つのデータベースに割り当てられたグローバル・データベース名は、同じホスト上の別のデータベースでも、別のホスト上の別のデータベースでも再使用できません。たとえば、1つのホスト(host1)に2つのデータベース(db1およびdb2)がある場合、そのグローバル・データベース名は一意である必要があります。さらに、別のホスト(host2)に3つ目のデータベースをインストールする場合、このデータベースのグローバル・データベース名は、Cloud Controlに登録された他のすべての名前とは異なり、一意である必要があります。

- ここで指定したデータベースの資格証明がすべての宛先ホストで使用されます。しかし、プロビジョニング後に、データベースのパスワードを変更する場合は、手動で変更する必要があります。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

14. 「記憶域の場所」ページで、「自動ストレージ管理(ASM)」として記憶域タイプを選択して懐中電灯アイコンをクリックし、ディスク・グループ名を選択してASMSNMPパスワードを指定します。「ディスク・グループ名リスト」ウィンドウに、すべての宛先ホストで共通のディスク・グループが表示されます。
「データベース・ファイルの場所」セクションで、データファイル、一時ファイル、REDOログおよび制御ファイルを格納する場所を指定します。

- テンプレートからのデータベース・ファイルの場所を使用を選択し、使用されているテンプレートからのデフォルトを選択します。

- 全データベース・ファイルの共通の場所の使用を選択し、別の場所を指定します。
「REDOログおよび制御ファイルを多重化」セクションで「Oracle Managed Files(OMF)の使用」オプションを選択すると、REDOログ・ファイルおよび制御ファイルの重複コピーを格納できます。多重化によって強力なフォルト・トレランスが提供されます。最大5つの場所を指定できます。

「リカバリ・ファイルの場所」セクションで、「データベース・ファイルの場所と同じ記憶域タイプを使用してください」を選択し、リカバリ・ファイルの記憶域タイプにデータベース・ファイルと同じタイプを使用します。「フラッシュ・リカバリ領域の使用」を選択し、リカバリ関連ファイルの場所および高速リカバリ領域サイズを指定します。

「アーカイブ有効化」を選択してアーカイブのログを有効にします。「アーカイブ・ロブの場所を指定してください」をクリックし、最大9箇所のアーカイブ・ログの場所を指定します。ログの場所を指定しない場合、ログはデフォルトの場所に保存されます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

15. 初期化パラメータ・ページで、メモリー管理タイプとして「自動メモリー管理」または「自動共有メモリー管理」を選択します。「メモリー設定として使用可能メモリーの割合」を選択し、メモリー設定として使用可能物理メモリーの割合を指定します。自動共有メモリー管理の場合は、「SGA合計」および「PGA合計」を指定します。自動メモリー管理の場合は、「Oracleで使用するメモリーの合計」を指定します。
「データベースのサイズ設定」セクションで、「ブロック・サイズ」および「プロセス」の数を指定します。データベース・テンプレート・ページでデータファイルとともにデータベース・テンプレートを選択した場合、ブロック・サイズは編集できません。

「ホストCPU数」を指定します。指定できる最大CPU数はホストに存在するCPUの数と同じです。

「キャラクタ・セット」セクションでは、デフォルトのキャラクタ・セットを選択します。デフォルトのキャラクタ・セットはロケールおよびオペレーティング・システムに基づいています。

各国語キャラクタ・セットを選択します。デフォルトはAL16UTF16です。

「データベース接続モード」セクションでは、専用サーバー・モードを選択します。共有サーバー・モードについては、共有サーバーの数を指定します。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

16. 「追加の構成オプション」に、Oracleホームから実行されているすべての使用可能なリスナーがリストされます。リスナーを選択するか、新規リスナーを作成できます。データベースに登録する複数のリスナーを選択できます。新規リスナーを作成するには、「リスナー名」および「ポート」を指定します。データベース・スキーマを選択し、カスタム・スクリプトがある場合はこれを指定します。データベースを作成するホストまたはソフトウェア・ライブラリからカスタム・スクリプトを選択します。複数のホストを選択した場合は、ソフトウェア・ライブラリからのみスクリプトを指定できます。
データベース・テンプレート・ページで「構造のみ」データベース・テンプレートを選択した場合、データベース・オプションを表示および編集することもできます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

17. データベースを作成するために指定した詳細を確認し、「次へ」をクリックします。構成ページに戻ります。データベースを構成してある場合は、「データベースの作成」タスクが完了ステータスになります。

18. 「コンプライアンス標準」リンクをクリックします。

19. 「構成標準ターゲット・アソシエーション」ページで、データベースと関連付けるコンプライアンス標準を選択します。「次へ」をクリックします。

20. カスタム・パラメータが必要なユーザー・カスタマイズ済デプロイメント・プロシージャに対してのみカスタム・プロパティ・ページが表示されます。デプロイに関するカスタム・プロパティ(存在する場合)を指定します。「次へ」をクリックします。

21. 「スケジュール」ページで、デプロイメント・インスタンス名を指定します。プロシージャを即時に実行する場合は、デフォルトの選択(「1回(即時)」)を保持します。プロシージャを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。デプロイメント・プロシージャのステータスに応じて、通知プリファレンスを設定できます。前提条件のみを実行する場合は、「前提条件チェックの実行後に結果を分析するためにプロシージャを停止します」を選択すると、すべての前提条件チェックの実行後にプロシージャ実行を一時停止できます。
「次へ」をクリックします。

22. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。

23. オペレータ・ロールで、保存したデプロイメント・プロシージャを起動します。プロビジョニングのターゲットを追加し、デプロイメント・プロシージャの構成可能フィールドに値を指定します。

24. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各ステップの「ステータス」リンクをクリックし、各ステップの実行の詳細を表示します。「デバッグ」をクリックしてデバッグのロギング・レベルを設定し、「停止」をクリックしてプロシージャの実行を停止できます。

25. プロシージャの実行の完了後、「ターゲット」メニューをクリックし、「すべてのターゲット」を選択して、「すべてのターゲット」ページに移動し、新しくプロビジョニングしたデータベースがCloud Controlターゲットとして表示されることを確認します。

注意:
デプロイメント・プロシージャが失敗した場合、第F.7項で説明されているログ・ファイルを確認します。

6.3 Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのみのプロビジョニング

この項では、Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのプロビジョニング方法について説明します。

この項の具体的な内容は次のとおりです。

- Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのみをプロビジョニングするための前提条件

- Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのみをプロビジョニングする手順

6.3.1 Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのみをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、第4.3項に示す前提条件を満たしている必要があります。

6.3.2 Oracle Grid InfrastructureおよびOracle Databaseソフトウェアのみをプロビジョニングする手順

Oracle Grid InfrastructureおよびOracle Databaseソフトウェアをプロビジョニングするには、次の手順に従います。

1. デザイナとしてログインし、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. データベース・プロシージャ・ページでOracleデータベース・デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracleデータベースのプロビジョニング・ウィザードが起動します。

3. 「ホストの選択」ページで、プロビジョニング・プロファイルをデプロイメントに使用する場合は、「プロビショニング・プロファイルを選択」で、事前に保存した構成パラメータを含むプロファイルを選択します。
「宛先ホストの選択」セクションで、「追加」をクリックし、ソフトウェアをデプロイおよび構成する宛先ホストを選択します。

「実行するタスクの選択」セクションで、プラットフォーム、プロセスのバージョンおよびプロビジョニングするコンポーネントを選択します。

- グリッド・インフラストラクチャをデプロイするには、「ソフトウェアのデプロイのみ」を選択して単一インスタンス・データベースをプロビジョニングします。

- データベース・ソフトウェアをデプロイするには、新規データベースのデプロイと作成(スタンドアロンのOracle Databaseのインストール後に新規データベースを作成し構成する)のいずれかを選択します。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。デプロイメント・プロシージャのロック・ダウン機能の詳細は、第4.1項を参照してください。

「次へ」をクリックします。

4. 「構成」ページで、「ホストの設定」リンクをクリックします。

5. 「OSユーザーの指定」ページで、データベースおよびグリッド・インフラストラクチャのOracleホームのオペレーティング・システム・ユーザーを指定します。OSグループに追加する「通常ユーザー」および「特権ユーザー」を指定します。
「次へ」をクリックします。

6. OSグループの指定ページで、オペレーティング・システム認証に使用するOSグループを指定します。次のロールに対応するグループが、プロビジョニングに選択したホストにすでに存在していることを確認します。

- インベントリ・グループ(OINSTALL)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

- ASMインスタンス管理者(OSASM)

- ASMデータベース管理者(ASMDBA)

- ASMインスタンス・オペレータ(ASMOPER)

それらが存在しない場合、ホスト上に存在する別のグループを指定するか、次で使用可能な『Oracle Databaseクイック・インストレーション・ガイド』に従って、新しいグループを作成します。

http://www.oracle.com/pls/db112/homepage

作成する新しいグループまたは指定する別のグループは、データベースが構成された後で、自動的にSYSDBAおよびSYSOPER権限を取得します。

詳細は、次で使用可能な『Oracle Database 2日でデータベース管理者ガイド』を参照してください。

http://www.oracle.com/pls/db112/homepage

「次へ」をクリックします。構成ページに戻ります。宛先ホストを構成してある場合は、「ホストの設定」タスクが完了ステータスになります。

7. 「ソフトウェアのデプロイ」リンクをクリックします。

8. 「ソフトウェアの場所の選択」ページで、Oracle Databaseのソフトウェア・バイナリのソースおよび宛先の場所を指定します。
「ソース」セクションで「グリッド・インフラストラクチャ」および「Oracleデータベース」バイナリのソフトウェア・ライブラリの場所を選択します。

「宛先ロケーション」では、次を指定します。

- グリッド・インフラストラクチャ用Oracleベース: 診断および管理ログ、およびその他のグリッド・インフラストラクチャに関連するログが格納される宛先ホストの場所。

- グリッド・インフラストラクチャ・ホーム: グリッド・インフラストラクチャのソフトウェアをプロビジョニングできる宛先ホストの場所。これはグリッド・インフラストラクチャのOracleホーム・ディレクトリです。この場所には、グリッド・インフラストラクチャまたはデータベースのOracleベースのサブディレクトリを選択しないでください。

- データベース用Oracleベース: 診断および管理ログ、およびその他のデータベース関連ログを格納できる宛先ホストの場所。この場所はダンプ・ファイルの格納にのみ使用され、データベース・ソフトウェアがインストールされるOracleホーム・ディレクトリとは別の場所になります。

- データベースのOracleホーム: データベース・ソフトウェアをプロビジョニングできる宛先ホストの場所。これはデータベース用のOracleホーム・ディレクトリです。

グリッド・インフラストラクチャの場合、Oracleベースは/u01/app/userでOracleホームは%ORACLE_BASE%/sihahomeです。%ORACLE_BASE%および%GI_ORACLE_BASE%を使用して、それぞれの値に補完される相対パスを指定できます。

「追加パラメータ」セクションで、クローン関連のファイルを一時的に格納する宛先ホスト上で「作業ディレクトリ」を指定します。このディレクトリには、約7GBの空き領域があることを確認します。インストーラ・パラメータについては、Oracle Grid Infrastructureのプロビジョニング時に実行する追加のOracle Universal Installer (OUI)パラメータを指定します。たとえば、-force (警告を上書き)、-debug (デバッグ情報を詳細に表示)、および-invPtrLoc <Location> (UNIXのみ)と指定します。パラメータは必ず空白で区切ります。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。

「次へ」をクリックします。構成ページに戻ります。ソフトウェアのソースおよび宛先の場所を構成してある場合は、「ソフトウェアの構成」タスクが完了ステータスになります。

9. 「スケジュール」ページで、デプロイメント・インスタンス名を指定します。プロシージャを即時に実行する場合は、デフォルトの選択(「1回(即時)」)を保持します。プロシージャを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。デプロイメント・プロシージャのステータスに応じて、通知プリファレンスを設定できます。前提条件のみを実行する場合は、「前提条件チェックの実行後に結果を分析するためにプロシージャを停止します」を選択すると、すべての前提条件チェックの実行後にプロシージャ実行を一時停止できます。
「次へ」をクリックします。

10. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。

11. オペレータ・ロールで、保存したデプロイメント・プロシージャを起動します。プロビジョニングのターゲットを追加し、デプロイメント・プロシージャの構成可能フィールドに値を指定します。

12. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各ステップの「ステータス」リンクをクリックし、各ステップの実行の詳細を表示します。「デバッグ」をクリックしてデバッグのロギング・レベルを設定し、「停止」をクリックしてプロシージャの実行を停止できます。

注意:
デプロイメント・プロシージャが失敗した場合、第F.7項で説明されているログ・ファイルを確認します。

7 Oracle Real Application Clustersデータベース用のOracle Grid Infrastructureのプロビジョニング

この章では、クラスタ環境用のOracle Grid InfrastructureおよびOracle Real Application Clusters (Oracle RAC)を自動的、反復可能で、信頼できる方法で一括デプロイする方法について説明します。この章の具体的な内容は次のとおりです。

- Oracle RACデータベースのグリッド・インフラストラクチャのプロビジョニングの概要

- Oracle Real Application Clustersデータベースを使用したグリッド・インフラストラクチャのプロビジョニングとOracle Automatic Storage Managementを使用したデータベースの構成

- 既存のクラスタ上のファイル・システムを使用したOracle Real Application Clustersデータベースのプロビジョニング

- 新規クラスタ上のファイル・システムを使用したOracle Real Application Clustersデータベースのプロビジョニング

注意:
この機能のオンライン・デモンストレーションを見るには、次のURLにアクセスします。
http://www.oracle.com/technology/obe/demos/admin/demos.html

7.1 Oracle RACデータベースのグリッド・インフラストラクチャのプロビジョニングの概要

この項では、この章に取り組むための手引きとして、Oracle Grid InfrastructureおよびOracle RACのプロビジョニング手順の概要を説明します。この項は、Oracle Grid InfrastructureおよびOracle RACのプロビジョニングを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表7-1 Oracle Grid InfrastructureおよびOracle RAC Databaseのプロビジョニングの概要

ステップ

説明

参照リンク

ステップ1

Oracle RACトポロジの理解

Cloud ControlによりプロビジョニングされたOracle Real Application Clustersデータベース・トポロジについて理解します。

トポロジの詳細は、第7.2項を参照してください。

ステップ2

ユースケースの選択

ここでは、Oracle Grid InfrastructureおよびOracle RACのプロビジョニングのユースケースのいくつかを説明します。ご自身の要件に最適なユースケースを選択してください。

- Oracle Grid InfrastructureおよびOracle RACデータベースのプロビジョニング、ASMおよびデータベースの構成の詳細は、第7.3項を参照してください。

- 既存のクラスタ上のファイル・システムを使用したOracle RACデータベースのプロビジョニングの詳細は、第7.4項を参照してください。

- 新規クラスタ上のファイル・システムを使用したOracle RACデータベースのプロビジョニングの詳細は、第7.5項を参照してください。

ステップ3

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

- Oracle Grid InfrastructureおよびOracle RACデータベースをプロビジョニングし、ASMおよびデータベースを構成するための前提条件の詳細は、第7.3.1項を参照してください。

- 既存のクラスタ上のファイル・システムを使用したOracle RACデータベースのプロビジョニングの前提条件の詳細は、第7.4.1項を参照してください。

- 新規クラスタ上のファイル・システムを使用したOracle RACデータベースのプロビジョニングの前提条件の詳細は、第7.5.1項を参照してください。

ステップ4

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行してOracle Grid InfrastructureおよびOracle RACを正常にプロビジョニングします。

- Oracle Grid InfrastructureおよびOracle RACデータベースをプロビジョニングし、ASMおよびデータベースを構成するには、第7.3.2項で説明する手順に従ってください。

- 既存のクラスタ上のファイル・システムを使用してOracle RACデータベースをプロビジョニングするには、第7.4.2項で説明する手順に従ってください。

- 新規クラスタ上のファイル・システムを使用してOracle RACデータベースをプロビジョニングするには、第7.5.2項で説明する手順に従ってください。

7.2 Oracle Real Application Clustersデータベース・トポロジ

Oracle Enterprise Manager Cloud Controlを使用すると、プロビジョニング・プロファイルを使用してOracle RACデータベースのゴールド・イメージ・ベースのデプロイを標準化し、デザイナ・ロールでロック・ダウンを入力し、コンプライアンス標準をデータベースに関連付けることができます。図7-1に、Cloud Controlを使用してプロビジョニングできる一般的なOracle RACデータベース・トポロジを示します。

図7-1 Oracle RACデータベース・トポロジ

このトポロジは、グリッド・インフラストラクチャ、クラスタASM、およびポロシー管理型Oracle RACデータベースを使用したNノード設定を示します。ASMディスク・アレイはクラスタ設定で完全に共有されます。グリッド・インフラストラクチャでは、Oracle Cluster Registry (OCR)および投票ディスク(ハートビート)に、QUORUMという名前のASMディスクグループを使用します。Oracle RACデータベースでは、DATAという名前の別のディスクグループを使用します。ここにはデータベースのデータファイルが保存されます。ノードは、ノード間の高速内部ネットワークによりクラスタ操作が促進され、パブリック・ネットワークが外部接続に使用されるように、マルチホーム化されています。ネットワークは、パブリック、プライベート、およびノードとASMディスク・アレイ間の記憶域ネットワークです。

7.3 Oracle Real Application Clustersデータベースを使用したグリッド・インフラストラクチャのプロビジョニングとOracle Automatic Storage Managementを使用したデータベースの構成

この項では、Oracle Real Application Clusters (Oracle RAC)データベースを使用してグリッド・インフラストラクチャをプロビジョニングし、Oracle Automatic Storage Management (Oracle ASM)を使用してデータベースを構成する方法について説明します。

この項の具体的な内容は次のとおりです。

- Oracle RACデータベースを使用してグリッド・インフラストラクチャをプロビジョニングするための前提条件

- Oracle RACデータベースを使用してグリッド・インフラストラクチャをプロビジョニングする手順

7.3.1 Oracle RACデータベースを使用してグリッド・インフラストラクチャをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、第4.3項に示す前提条件を満たしている必要があります。

7.3.2 Oracle RACデータベースを使用してグリッド・インフラストラクチャをプロビジョニングする手順

Oracle RACデータベースを使用してグリッド・インフラストラクチャをプロビジョニングし、Oracle ASMを使用してデータベースを構成するには、次の手順を実行します。

1. デザイナとしてログインし、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. 「データベース・プロシージャ」ページでOracle RACデータベースのプロビジョニング・デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracle RACデータベースのプロビジョニング・ウィザードが起動します。

3. 「ホストの選択」ページで、プロビジョニング・プロファイルをデプロイメントに使用する場合は、「プロビショニング・プロファイルを選択」で、事前に保存した構成パラメータを含むプロファイルを選択します。
「宛先ホストの選択」セクションで、「追加」をクリックし、ソフトウェアをデプロイおよび構成する宛先ホストを選択します。

「実行するタスクの選択」セクションで、プラットフォーム、プロセスのバージョンおよびプロビジョニングするコンポーネントを選択します。

- グリッド・インフラストラクチャをデプロイするには、「ソフトウェアのデプロイのみ」を選択してOracle RACデータベースをプロビジョニングします。

- データベース・ソフトウェアをデプロイするには、Oracle RACデータベースのインストール後に新規データベースを作成し構成するRAC One Nodeデータベースのデプロイと作成を選択します。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。デプロイメント・プロシージャのロック・ダウン機能の詳細は、第4.1項を参照してください。

「次へ」をクリックします。

4. 「構成」ページで、「ホストの設定」リンクをクリックします。

5. OSユーザーの指定ページで、データベースのプロビジョニングに必要なオペレーティング・システム・ユーザーとグループを指定します。

注意:
非root資格証明を使用するには、「Oracle Real Application Clusters (Oracle RAC)データベースのプロビジョニングでの非root資格証明の使用」を参照してください。

「データベース・ユーザー」とASMユーザーについては、OSグループへの追加対象として「通常ユーザー」および「特権ユーザー」を選択します。

「次へ」をクリックします。

6. OSグループの指定ページで、オペレーティング・システム認証に使用するOSグループを指定します。次のロールに対応するグループが、プロビジョニングに選択したホストにすでに存在していることを確認します。

- インベントリ・グループ(OINSTALL)

- ASMデータベース管理者(ASMDBA)

- ASMインスタンス・オペレータ(ASMOPER)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

- ASMインスタンス管理者(OSASM)

「次へ」をクリックします。構成ページに戻ります。宛先ホストを構成してある場合は、「ホストの設定」タスクが構成済ステータスになります。

7. 「ソフトウェアのデプロイ」リンクをクリックします。

8. ソフトウェアの場所ページで、Oracle Grid InfrastructureおよびOracle RACのソフトウェア・バイナリを配置する場所である$ORACLE_HOMEを指定します。設計者として、鍵アイコンをクリックしてこれらのフィールドをロックできます。ロックすると、これらのフィールドはオペレータ・ロールでは編集できなくなります。
「ソース」セクションで「グリッド・インフラストラクチャ」および「Oracleデータベース」バイナリのソフトウェア・ライブラリの場所を選択します。

注意:
Windowsオペレーティング・システムでは、選択されているOracle Grid InfrastructureまたはOracle Databaseコンポーネントがバージョン12.1以上の場合に、すべてのサービスを、限られた権限を持つ指定されたOracleサービス・ユーザーとしてインストールできます。これにより、データベース・サービスのセキュリティが向上します。
「Windowsセキュリティ・オプション」セクションで、既存のユーザーのオプションを構成し、「ユーザー名」および「パスワード」を指定できます。すべてのサービスを管理ユーザーとしてインストールおよび構成する場合は、「セキュリティ・オプションを却下」を選択します。

「宛先ロケーション」では、次を指定します。

- グリッド・インフラストラクチャ用Oracleベース: 診断および管理ログ、およびその他のグリッド・インフラストラクチャに関連するログが格納される宛先ホストの場所。

- グリッド・インフラストラクチャ・ホーム: グリッド・インフラストラクチャのソフトウェアをプロビジョニングできる宛先ホストの場所。これはグリッド・インフラストラクチャのOracleホーム・ディレクトリです。この場所には、グリッド・インフラストラクチャまたはデータベースのOracleベースのサブディレクトリを選択しないでください。「共有グリッド・インフラストラクチャ・ホーム」を選択し、共有の場所でグリッド・インストラクチャOracleホームを有効にします。指定するディレクトリ・パスが、第7.3.2.1項で説明している要件を満たすことを確認します。

- データベース用Oracleベース: 診断および管理ログ、およびその他のデータベース関連ログを格納できる宛先ホストの場所。この場所はダンプ・ファイルの格納にのみ使用され、データベース・ソフトウェアがインストールされるOracleホーム・ディレクトリとは別の場所になります。

- データベースのOracleホーム: データベース・ソフトウェアをプロビジョニングできる宛先ホストの場所。これはデータベース用のOracleホーム・ディレクトリです。「共有データベースOracleホーム」を選択し、共有の場所でデータベースOracleホームを有効にします。

グリッド・インフラストラクチャの場合、Oracleベースは/u01/app/userでOracleホームは%ORACLE_BASE/../../gridです。%ORACLE_BASE%および%GI_ORACLE_BASE%を使用して、それぞれの値に補完される相対パスを指定できます。

「追加パラメータ」セクションで、クローン関連のファイルを一時的に格納する宛先ホスト上で「作業ディレクトリ」を指定します。このディレクトリには、約7GBの空き領域があることを確認します。インストーラ・パラメータについては、Oracle Grid Infrastructureのプロビジョニング時に実行する追加のOracle Universal Installer (OUI)パラメータを指定します。たとえば、-force (警告を上書き)、-debug (デバッグ情報を詳細に表示)、および-invPtrLoc <Location> (UNIXのみ)と指定します。パラメータは必ず空白で区切ります。

OCFSデバイスは、「インストーラ・パラメータ」フィールドでデバイスをカンマで区切った次の形式で指定することもできます。

Device Number:Partition Number: Drive letter: [DATA | SOFTWARE]

次に例を示します。

「次へ」をクリックします。構成ページに戻ります。ソフトウェアのソースおよび宛先の場所を構成してある場合は、「ソフトウェアの構成」タスクが構成済ステータスになります。

9. 「グリッド・インフラストラクチャの構成」リンクをクリックします。

10. 記憶域の選択ページで、グリッド・インフラストラクチャとデータベースの記憶域タイプとして「自動ストレージ管理」または「共有ファイル・システム」を選択し、投票ディスクおよびOracle Cluster Registry (OCR)を格納するための記憶域タイプを指定します。投票ディスクおよびOCRは、Oracleクラスタウェアによってリソースを管理するために使用されます。次のオプションから選択できます:

- グリッド・インフラストラクチャおよびOracle RACデータベースの両方に対し「自動ストレージ管理」

- グリッド・インフラストラクチャに対し「自動ストレージ管理」、Oracle RACデータベースに対し「ファイル・システム」

- グリッド・インフラストラクチャおよびOracle RACデータベースの両方に対し「ファイル・システム」

- グリッド・インフラストラクチャに対し「ファイル・システム」、Oracle RACデータベースに対し「自動ストレージ管理」

設計者として、鍵アイコンをクリックしてこれらのフィールドをロックできます。ロックすると、これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

11. GIの構成ページの「基本設定」セクションで、「クラスタ名」、「SCAN名」および「SCANポート」を指定します。デフォルトのSCANポートはポート1521ですが、別のポートを選択して指定できます。指定したSCANポートが有効であるかどうか、および他の目的で使用されていないかどうかが確認されます。インストール後、TNSリスナーが、SCAN名へのクライアント接続に応答するためにこのポートをリスニングします。

クラスタの外部の仮想ホスト名に名前を動的に割り当てる場合、GNS設定セクションで、「GNSの構成とDHCPでの自動割当」を選択し、GNSサブシステムおよび「GNS VIPアドレス」を指定します。

デフォルトでは、GIネットワーク・セクションで、選択した宛先ホストと同じ名前とサブネットを持つネットワーク・インタフェースが自動的に検出され、表示されます。これらのネットワーク・インタフェース構成の詳細を検証します。「使用方法」列では、パブリック・インタフェースとしてインタフェースを構成するには「パブリック」を選択し、プライベート・インタフェースとしてインタフェースを構成するには「プライベート」を選択します。

「追加」をクリックしてインタフェースを追加し、「インタフェース名」と「インタフェース・サブネット」を指定して「OK」をクリックします。「使用方法」には、「パブリック」、「プライベート」、またはインタフェースを使用しない場合は「未使用」を選択します。

グリッド・インフラストラクチャおよびOracle RACデータベースのどちらかまたは両方の記憶域タイプに「自動ストレージ管理」を選択した場合、「ASM記憶域」セクションで、Cloud Controlにより検出されて表に表示されているASMディスク・グループから選択します。「追加」をクリックしてASMディスク・グループを追加します。ディスク・グループの追加/編集ダイアログ・ボックスでは、「ディスク・グループ名」および「ディスク・リスト」を指定し、冗長性を「標準」、「高」または「外部」に指定します。「OK」をクリックします。クラスタ・レジストリおよび投票ディスク・ファイルを格納する「OCR/投票ディスク」を選択し、ASMSNMPおよびSYSユーザー用のASM資格証明を指定します。

グリッド・インフラストラクチャまたはOracle RACデータベースの記憶域タイプに「ファイル・システム」を選択した場合、「ファイルシステム記憶域」セクションで、Oracle Cluster Registry (OCR)および投票ディスクの記憶域の場所を指定します。「標準」または「外部」を選択して冗長性レベルを指定し、その場所を指定します。

設計者として、鍵アイコンをクリックしてこれらのフィールドをロックできます。ロックすると、これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。構成ページに戻ります。グリッド・インフラストラクチャおよびデータベースの記憶域オプションを構成してある場合は、「グリッド・インフラストラクチャの構成」タスクが完了ステータスになります。

12. 「データベースの作成」リンクをクリックします。

13. データベース・テンプレート・ページでは、データベース・テンプレートの場所を選択します。この場所はソフトウェア・ライブラリまたはOracleホームのいずれかにできます。選択したテンプレートは、選択したOracleホームのバージョンと互換性を保っている必要があります。
「ソフトウェア・ライブラリ」を選択した場合、検索アイコンをクリックし、ソフトウェア・ライブラリからテンプレートを選択します。「管理対象ホスト上の一時的な格納場所」を指定します。この場所は、以前に選択した参照ノード上に存在する必要があります。

「テンプレートの詳細の表示」をクリックし、選択したテンプレートの詳細を表示します。初期化パラメータ、表領域、データファイル、REDOログ・グループ、共通オプション、およびテンプレートの他の詳細を表示できます。

「Oracleホーム」を選択した場合は、「Oracleホーム」からテンプレートを選択します。デフォルトの場所はORACLE_HOME/assistants/dbca/templatesです。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

14. 「IDおよび配置」ページで、Oracle RACデータベースの構成タイプ(「管理されたポリシー」または「管理されたAdmin」)を選択します。
管理者管理型データベースの場合、クラスタ・データベースを作成するノードを選択します。データベースのバージョンおよびタイプ・ページで参照ノードとして選択したノードを指定する必要があります。

ポリシー管理型データベースの場合、データベースの作成に使用するサーバー・プールを既存のサーバー・プールのリストから選択するか、新規サーバー・プールの作成を選択します。ポリシー管理型データベースは、データベース・バージョン11.2以上に対して作成できます。11.2未満のデータベース・バージョンの場合、ノードを選択してOracle RACデータベースを作成する必要があります。

「グローバル・データベース名」および「SID」接頭辞を指定します。SYS、SYSTEM、DBSNMPの「データベース資格証明」を指定します。これらのユーザー・アカウントのそれぞれに、同じ管理パスワードを使用することも異なる管理パスワードを指定することもできます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

15. 「記憶域の場所」ページで、記憶域の選択ページでOracle Databaseに対して指定したものと同じ記憶域タイプを選択します。
「データベース・ファイルの場所」セクションで、データファイル、一時ファイル、REDOログおよび制御ファイルを格納する場所を指定します。これらの場所は、クラスタ・ファイル・システムの場所やASMディスク・グループなどの共有記憶域上にある必要があります。

- テンプレートからのデータベース・ファイルの場所を使用を選択し、使用されているテンプレートからのデフォルトを選択します。

- 全データベース・ファイルの共通の場所の使用を選択し、別の場所を指定します。
「REDOログおよび制御ファイルを多重化」セクションで「Oracle Managed Files(OMF)の使用」オプションを選択すると、REDOログ・ファイルおよび制御ファイルの重複コピーを格納できます。多重化によって強力なフォルト・トレランスが提供されます。最大5つの場所を指定できます。

「リカバリ・ファイルの場所」セクションで、「データベース・ファイルの場所と同じ記憶域タイプを使用してください」を選択し、リカバリ・ファイルの記憶域タイプにデータベース・ファイルと同じタイプを使用します。「フラッシュ・リカバリ領域の使用」を選択し、リカバリ関連ファイルの場所および高速リカバリ領域サイズを指定します。

「アーカイブ有効化」を選択してアーカイブのログを有効にします。「アーカイブ・ロブの場所を指定してください」をクリックし、最大9箇所のアーカイブ・ログの場所を指定します。ログの場所を指定しない場合、ログはデフォルトの場所に保存されます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

16. 初期化パラメータ・ページで、メモリー管理タイプとして「自動メモリー管理」または「自動共有メモリー管理」を選択します。「メモリー設定として使用可能メモリーの割合」を選択し、メモリー設定として使用可能物理メモリーの割合を指定します。自動共有メモリー管理の場合は、「SGA合計」および「PGA合計」を指定します。自動メモリー管理の場合は、「Oracleで使用するメモリーの合計」を指定します。
「データベースのサイズ設定」セクションで、「ブロック・サイズ」および「プロセス」の数を指定します。データベース・テンプレート・ページでデータファイルとともにデータベース・テンプレートを選択した場合、ブロック・サイズは編集できません。

「ホストCPU数」を指定します。指定できる最大CPU数はホストに存在するCPUの数と同じです。

「キャラクタ・セット」セクションでは、デフォルトのキャラクタ・セットを選択します。デフォルトのキャラクタ・セットはロケールおよびオペレーティング・システムに基づいています。

各国語キャラクタ・セットを選択します。デフォルトはAL16UTF16です。

「データベース接続モード」セクションでは、専用サーバー・モードを選択します。共有サーバー・モードについては、共有サーバーの数を指定します。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

17. 「追加の構成オプション」ページで、ソフトウェア・ライブラリまたはローカル・ディスクからカスタム・スクリプトを選択します。データベース・テンプレート・ページで「構造のみ」データベース・テンプレートを選択した場合、データベース・オプションを表示および編集することもできます。
「ロック」アイコンをクリックし、フィールドをロックします。「次へ」をクリックします。

18. 指定した情報を確認し、「次へ」をクリックします。構成ページに戻ります。データベースを構成してある場合は、「データベースの作成」タスクが構成済ステータスになります。「次へ」をクリックします。

19. 「コンプライアンス標準」リンクをクリックします。

20. 「構成標準ターゲット・アソシエーション」ページで、データベースと関連付けるコンプライアンス標準を選択します。「次へ」をクリックします。

21. 「構成」ページで「次へ」をクリックします。

22. カスタム・パラメータが必要なユーザー・カスタマイズ済デプロイメント・プロシージャに対してのみカスタム・プロパティ・ページが表示されます。デプロイに関するカスタム・プロパティ(存在する場合)を指定します。「次へ」をクリックします。

23. 「スケジュール」ページで、デプロイメント・インスタンス名を指定します。プロシージャを即時に実行する場合は、デフォルトの選択(「1回(即時)」)を保持します。プロシージャを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。デプロイメント・プロシージャのステータスに応じて、通知プリファレンスを設定できます。前提条件のみを実行する場合は、「前提条件チェックの実行後に結果を分析するためにプロシージャを停止します」を選択すると、すべての前提条件チェックの実行後にプロシージャ実行を一時停止できます。
「次へ」をクリックします。

24. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。

25. オペレータ・ロールで、保存したデプロイメント・プロシージャを起動します。プロビジョニングのターゲットを追加し、デプロイメント・プロシージャの構成可能フィールドに値を指定します。

26. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各ステップの「ステータス」リンクをクリックし、各ステップの実行の詳細を表示します。「デバッグ」をクリックしてデバッグのロギング・レベルを設定し、「停止」をクリックしてプロシージャの実行を停止できます。

27. プロシージャの実行の完了後、「ターゲット」メニューをクリックし、「すべてのターゲット」を選択して、「すべてのターゲット」ページに移動し、新しくプロビジョニングしたデータベースがCloud Controlターゲットとして表示されることを確認します。

注意:
デプロイメント・プロシージャが失敗した場合、第F.7項で説明されているログ・ファイルを確認します。

7.3.2.1 グリッド・インフラストラクチャ・ソフトウェア位置のパスの前提条件

Oracle Grid InfrastructureバイナリをデプロイするためのOracle Grid Infrastructureホームのディレクトリ・パスを指定する場合、次の要件を満たしてください。

- 既存のOracleホーム外のパスに作成する必要があります。

- ユーザー・ホーム・ディレクトリには作成できません。

- すべてのファイルをrootが所有できるパス内のサブディレクトリとして作成するか、一意のパス内に作成します。

- インストール前に、Oracle Grid Infrastructureのインストール所有者(通常、すべてのOracleソフトウェアを対象とした単一インストール所有者の場合はoracle。ロールベースのOracleインストール所有者の場合はgrid)によって所有され、権限755に設定される必要があります。

7.4 既存のクラスタ上のファイル・システムを使用したOracle Real Application Clustersデータベースのプロビジョニング

この項では、ファイル・システムを使用して既存のクラスタにOracle Real Application Clusters (Oracle RAC)データベースをプロビジョニングする方法について説明します。この項の具体的な内容は次のとおりです。

- ファイル・システムを使用して既存のクラスタにOracle RACデータベースをプロビジョニングするための前提条件

- ファイル・システムを使用して既存のクラスタにOracle RACをプロビジョニングする手順

7.4.1 ファイル・システムを使用して既存のクラスタにOracle RACデータベースをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、第4.3項に示す前提条件を満たしている必要があります。

7.4.2 ファイル・システムを使用して既存のクラスタにOracle RACをプロビジョニングする手順

既存のクラスタ上のファイル・システムを使用してOracle RACデータベースをプロビジョニングするには、次の手順に従ってください。

次の手順に従います。

1. デザイナとしてログインし、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. 「データベース・プロシージャ」ページでOracle RACデータベースのプロビジョニング・デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracle RACデータベースのプロビジョニング・ウィザードが起動します。

3. 「ホストの選択」ページで、プロビジョニング・プロファイルをデプロイメントに使用する場合は、「プロビショニング・プロファイルを選択」で、事前に保存した構成パラメータを含むプロファイルを選択します。
「宛先ホストの選択」セクションで、「追加」をクリックし、ソフトウェアをデプロイおよび構成する宛先ホストを選択します。

「実行するタスクの選択」セクションで、プラットフォーム、プロセスのバージョンおよびプロビジョニングするコンポーネントを選択します。

- グリッド・インフラストラクチャをデプロイするには、「ソフトウェアのデプロイのみ」を選択してOracle RACデータベースをプロビジョニングします。

- データベース・ソフトウェアをデプロイするには、Oracle RACデータベースのインストール後に新規データベースを作成し構成するRAC One Nodeデータベースのデプロイと作成を選択します。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。デプロイメント・プロシージャのロック・ダウン機能の詳細は、第4.1項を参照してください。

「次へ」をクリックします。

4. 「構成」ページで、「ホストの設定」リンクをクリックします。

5. OSユーザーの指定ページで、データベースのプロビジョニングに必要なオペレーティング・システム・ユーザーとグループを指定します。

注意:
非root資格証明を使用するには、「Oracle Real Application Clusters (Oracle RAC)データベースのプロビジョニングでの非root資格証明の使用」を参照してください。

「データベース・ユーザー」については、OSグループに追加する「通常ユーザー」および「特権ユーザー」を選択します。

「次へ」をクリックします。

6. OSグループの指定ページで、オペレーティング・システム認証に使用するOSグループを指定します。次のロールに対応するグループが、プロビジョニングに選択したホストにすでに存在していることを確認します。

- インベントリ・グループ(OINSTALL)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

「次へ」をクリックします。構成ページに戻ります。宛先ホストを構成してある場合は、「ホストの設定」タスクが構成済ステータスになります。

7. 「ソフトウェアのデプロイ」リンクをクリックします。

8. 「ソフトウェアの場所の選択」ページで、Oracle RACデータベースのソフトウェア・バイナリを配置する場所である$ORACLE_HOMEを指定します。設計者として、鍵アイコンをクリックしてこれらのフィールドをロックできます。ロックすると、これらのフィールドはオペレータ・ロールでは編集できなくなります。
「ソース」セクションで「グリッド・インフラストラクチャ」および「Oracleデータベース」バイナリのソフトウェア・ライブラリの場所を選択します。

注意:
Windowsオペレーティング・システムでは、選択されているOracle Grid InfrastructureまたはOracle Databaseコンポーネントがバージョン12.1以上の場合に、すべてのサービスを、限られた権限を持つ指定されたOracleサービス・ユーザーとしてインストールできます。これにより、データベース・サービスのセキュリティが向上します。
「Windowsセキュリティ・オプション」セクションで、既存のユーザーのオプションを構成し、「ユーザー名」および「パスワード」を指定できます。すべてのサービスを管理ユーザーとしてインストールおよび構成する場合は、「セキュリティ・オプションを却下」を選択します。

「宛先ロケーション」では、次を指定します。

- データベース用Oracleベース: 診断および管理ログ、およびその他のデータベース関連ログを格納できる宛先ホストの場所。この場所はダンプ・ファイルの格納にのみ使用され、データベース・ソフトウェアがインストールされるOracleホーム・ディレクトリとは別の場所になります。

- データベースのOracleホーム: データベース・ソフトウェアをプロビジョニングできる宛先ホストの場所。これはデータベース用のOracleホーム・ディレクトリです。「共有データベースOracleホーム」を選択し、共有の場所でデータベースOracleホームを有効にします。

「追加パラメータ」セクションで、クローン関連のファイルを一時的に格納する宛先ホスト上で「作業ディレクトリ」を指定します。このディレクトリには、約7GBの空き領域があることを確認します。「インストーラ・パラメータ」には、Oracle RACデータベースのプロビジョニング時に実行する追加のOracle Universal Installer (OUI)パラメータを指定します。たとえば、-force (警告を上書き)、-debug (デバッグ情報を詳細に表示)、および-invPtrLoc <Location> (UNIXのみ)と指定します。パラメータは必ず空白で区切ります。

OCFSデバイスは、「インストーラ・パラメータ」フィールドでデバイスをカンマで区切った次の形式で指定することもできます。

Device Number:Partition Number: Drive letter: [DATA | SOFTWARE]

次に例を示します。

「次へ」をクリックします。構成ページに戻ります。ソフトウェアのソースおよび宛先の場所を構成してある場合は、「ソフトウェアの構成」タスクが構成済ステータスになります。

9. 「データベースの作成」リンクをクリックします。

10. データベース・テンプレート・ページでは、データベース・テンプレートの場所を選択します。この場所はソフトウェア・ライブラリまたはOracleホームのいずれかにできます。選択したテンプレートは、選択したOracleホームのバージョンと互換性を保っている必要があります。
「ソフトウェア・ライブラリ」を選択した場合、検索アイコンをクリックし、ソフトウェア・ライブラリからテンプレートを選択します。「管理対象ホスト上の一時的な格納場所」を指定します。この場所は、以前に選択した参照ノード上に存在する必要があります。

「テンプレートの詳細の表示」をクリックし、選択したテンプレートの詳細を表示します。初期化パラメータ、表領域、データファイル、REDOログ・グループ、共通オプション、およびテンプレートの他の詳細を表示できます。

「Oracleホーム」を選択した場合は、「Oracleホーム」からテンプレートを選択します。デフォルトの場所はORACLE_HOME/assistants/dbca/templatesです。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

11. 「IDおよび配置」ページで、Oracle RACデータベースの構成タイプ(「管理されたポリシー」または「管理されたAdmin」)を選択します。
管理者管理型データベースの場合、クラスタ・データベースを作成するノードを選択します。

ポリシー管理型データベースの場合、データベースの作成に使用するサーバー・プールを既存のサーバー・プールのリストから選択するか、新規サーバー・プールの作成を選択します。ポリシー管理型データベースは、データベース・バージョン11.2以上に対して作成できます。11.2未満のデータベース・バージョンの場合、ノードを選択してOracle RACデータベースを作成する必要があります。

「グローバル・データベース名」および「SID」接頭辞を指定します。SYS、SYSTEM、DBSNMPの「データベース資格証明」を指定します。これらのユーザー・アカウントのそれぞれに、同じ管理パスワードを使用することも異なる管理パスワードを指定することもできます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

12. 「記憶域の場所」ページで、Oracle RACデータベースの記憶域タイプに「ファイル・システム」を選択します。
「データベース・ファイルの場所」セクションで、データファイル、一時ファイル、REDOログおよび制御ファイルを格納する場所を指定します。これらの場所は、クラスタ・ファイル・システムの場所やASMディスク・グループなどの共有記憶域上にある必要があります。

- テンプレートからのデータベース・ファイルの場所を使用を選択し、使用されているテンプレートからのデフォルトを選択します。

- 全データベース・ファイルの共通の場所の使用を選択し、別の場所を指定します。
「REDOログおよび制御ファイルを多重化」セクションで「Oracle Managed Files(OMF)の使用」オプションを選択すると、REDOログ・ファイルおよび制御ファイルの重複コピーを格納できます。多重化によって強力なフォルト・トレランスが提供されます。最大5つの場所を指定できます。

「リカバリ・ファイルの場所」セクションで、「データベース・ファイルの場所と同じ記憶域タイプを使用してください」を選択し、リカバリ・ファイルの記憶域タイプにデータベース・ファイルと同じタイプを使用します。「フラッシュ・リカバリ領域の使用」を選択し、リカバリ関連ファイルの場所および高速リカバリ領域サイズを指定します。

「アーカイブ有効化」を選択してアーカイブのログを有効にします。「アーカイブ・ロブの場所を指定してください」をクリックし、最大9箇所のアーカイブ・ログの場所を指定します。ログの場所を指定しない場合、ログはデフォルトの場所に保存されます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

13. 初期化パラメータ・ページで、メモリー管理タイプとして「自動メモリー管理」または「自動共有メモリー管理」を選択します。「メモリー設定として使用可能メモリーの割合」を選択し、メモリー設定として使用可能物理メモリーの割合を指定します。自動共有メモリー管理の場合は、「SGA合計」および「PGA合計」を指定します。自動メモリー管理の場合は、「Oracleで使用するメモリーの合計」を指定します。
「データベースのサイズ設定」セクションで、「ブロック・サイズ」および「プロセス」の数を指定します。データベース・テンプレート・ページでデータファイルとともにデータベース・テンプレートを選択した場合、ブロック・サイズは編集できません。

「ホストCPU数」を指定します。指定できる最大CPU数はホストに存在するCPUの数と同じです。

「キャラクタ・セット」セクションでは、デフォルトのキャラクタ・セットを選択します。デフォルトのキャラクタ・セットはロケールおよびオペレーティング・システムに基づいています。

各国語キャラクタ・セットを選択します。デフォルトはAL16UTF16です。

「データベース接続モード」セクションでは、専用サーバー・モードを選択します。共有サーバー・モードについては、共有サーバーの数を指定します。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

14. 「追加の構成オプション」ページで、ソフトウェア・ライブラリまたはローカル・ディスクからカスタム・スクリプトを選択します。データベース・テンプレート・ページで「構造のみ」データベース・テンプレートを選択した場合、データベース・オプションを表示および編集することもできます。
「ロック」アイコンをクリックし、フィールドをロックします。「次へ」をクリックします。

15. 指定した情報を確認し、「次へ」をクリックします。構成ページに戻ります。データベースを構成してある場合は、「データベースの作成」タスクが構成済ステータスになります。「次へ」をクリックします。

16. 「コンプライアンス標準」リンクをクリックします。

17. 「構成標準ターゲット・アソシエーション」ページで、データベースと関連付けるコンプライアンス標準を選択します。「次へ」をクリックします。

18. 「構成」ページで「次へ」をクリックします。

19. カスタム・パラメータが必要なユーザー・カスタマイズ済デプロイメント・プロシージャに対してのみカスタム・プロパティ・ページが表示されます。デプロイに関するカスタム・プロパティ(存在する場合)を指定します。「次へ」をクリックします。

20. 「スケジュール」ページで、デプロイメント・インスタンス名を指定します。プロシージャを即時に実行する場合は、デフォルトの選択(「1回(即時)」)を保持します。プロシージャを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。デプロイメント・プロシージャのステータスに応じて、通知プリファレンスを設定できます。前提条件のみを実行する場合は、「前提条件チェックの実行後に結果を分析するためにプロシージャを停止します」を選択すると、すべての前提条件チェックの実行後にプロシージャ実行を一時停止できます。
「次へ」をクリックします。

21. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。

22. オペレータ・ロールで、保存したデプロイメント・プロシージャを起動します。プロビジョニングのターゲットを追加し、デプロイメント・プロシージャの構成可能フィールドに値を指定します。

23. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各ステップの「ステータス」リンクをクリックし、各ステップの実行の詳細を表示します。「デバッグ」をクリックしてデバッグのロギング・レベルを設定し、「停止」をクリックしてプロシージャの実行を停止できます。

24. プロシージャの実行の完了後、「ターゲット」メニューをクリックし、「すべてのターゲット」を選択して、「すべてのターゲット」ページに移動し、新しくプロビジョニングしたデータベースがCloud Controlターゲットとして表示されることを確認します。

注意:
デプロイメント・プロシージャが失敗した場合、第F.7項で説明されているログ・ファイルを確認します。

7.5 新規クラスタ上のファイル・システムを使用したOracle Real Application Clustersデータベースのプロビジョニング

この項では、ファイル・システムを使用して既存のクラスタにOracle Real Application Clusters (Oracle RAC)データベースをプロビジョニングする方法について説明します。この項の具体的な内容は次のとおりです。

- ファイル・システムを使用して既存のクラスタにOracle RACデータベースをプロビジョニングするための前提条件

- ファイル・システムを使用して既存のクラスタにOracle RACをプロビジョニングする手順

7.5.1 ファイル・システムを使用して新規のクラスタにOracle RACデータベースをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、第4.3項に示す前提条件を満たしている必要があります。

7.5.2 ファイル・システムを使用して新規のクラスタにOracle RACデータベースをプロビジョニングする手順

新規クラスタ上のOracle RACデータベースをプロビジョニングするには、次の手順に従ってください。

1. デザイナとしてログインし、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. 「データベース・プロシージャ」ページで「Oracle RACデータベースのプロビジョニング」デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracle RACデータベースのプロビジョニング・ウィザードが起動します。

3. 「ホストの選択」ページで、プロビジョニング・プロファイルをデプロイメントに使用する場合は、「プロビショニング・プロファイルを選択」で、事前に保存した構成パラメータを含むプロファイルを選択します。
「宛先ホストの選択」セクションで、「追加」をクリックし、ソフトウェアをデプロイおよび構成する宛先ホストを選択します。

「実行するタスクの選択」セクションで、プラットフォーム、プロセスのバージョンおよびプロビジョニングするコンポーネントを選択します。

- グリッド・インフラストラクチャをデプロイするには、「ソフトウェアのデプロイと構成」を選択してOracle RACデータベースをプロビジョニングします。

- データベース・ソフトウェアをデプロイするには、Oracle RACデータベースのインストール後に新規データベースを作成し構成するRAC One Nodeデータベースのデプロイと作成を選択します。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。デプロイメント・プロシージャのロック・ダウン機能の詳細は、第4.1項を参照してください。

「次へ」をクリックします。

4. 「構成」ページで、「ホストの設定」リンクをクリックします。

5. OSユーザーの指定ページで、データベースのプロビジョニングに必要なオペレーティング・システム・ユーザーとグループを指定します。
「データベース・ユーザー」とASMユーザーについては、OSグループへの追加対象として「通常ユーザー」および「特権ユーザー」を選択します。

「次へ」をクリックします。

6. OSグループの指定ページで、オペレーティング・システム認証に使用するOSグループを指定します。次のロールに対応するグループが、プロビジョニングに選択したホストにすでに存在していることを確認します。

注意:
非root資格証明を使用するには、「Oracle Real Application Clusters (Oracle RAC)データベースのプロビジョニングでの非root資格証明の使用」を参照してください。

- インベントリ・グループ(OINSTALL)

- ASMデータベース管理者(ASMDBA)

- ASMインスタンス・オペレータ(ASMOPER)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

- ASMインスタンス管理者(OSASM)

「次へ」をクリックします。構成ページに戻ります。宛先ホストを構成してある場合は、「ホストの設定」タスクが構成済ステータスになります。

7. 「ソフトウェアのデプロイ」リンクをクリックします。

8. ソフトウェアの場所ページで、Oracle Grid InfrastructureおよびOracle RACのソフトウェア・バイナリを配置する場所である$ORACLE_HOMEを指定します。設計者として、鍵アイコンをクリックしてこれらのフィールドをロックできます。ロックすると、これらのフィールドはオペレータ・ロールでは編集できなくなります。
「ソース」セクションで「グリッド・インフラストラクチャ」および「Oracleデータベース」バイナリのソフトウェア・ライブラリの場所を選択します。

注意:
Windowsオペレーティング・システムでは、選択されているOracle Grid InfrastructureまたはOracle Databaseコンポーネントがバージョン12.1以上の場合に、すべてのサービスを、限られた権限を持つ指定されたOracleサービス・ユーザーとしてインストールできます。これにより、データベース・サービスのセキュリティが向上します。
「Windowsセキュリティ・オプション」セクションで、既存のユーザーのオプションを構成し、「ユーザー名」および「パスワード」を指定できます。すべてのサービスを管理ユーザーとしてインストールおよび構成する場合は、「セキュリティ・オプションを却下」を選択します。

「宛先ロケーション」では、次を指定します。

- グリッド・インフラストラクチャ用Oracleベース: 診断および管理ログ、およびその他のグリッド・インフラストラクチャに関連するログが格納される宛先ホストの場所。

- グリッド・インフラストラクチャ・ホーム: グリッド・インフラストラクチャのソフトウェアをプロビジョニングできる宛先ホストの場所。これはグリッド・インフラストラクチャのOracleホーム・ディレクトリです。この場所には、グリッド・インフラストラクチャまたはデータベースのOracleベースのサブディレクトリを選択しないでください。「共有グリッド・インフラストラクチャ・ホーム」を選択し、共有の場所でグリッド・インストラクチャOracleホームを有効にします。指定するディレクトリ・パスが、第7.3.2.1項で説明している要件を満たすことを確認します。

- データベース用Oracleベース: 診断および管理ログ、およびその他のデータベース関連ログを格納できる宛先ホストの場所。この場所はダンプ・ファイルの格納にのみ使用され、データベース・ソフトウェアがインストールされるOracleホーム・ディレクトリとは別の場所になります。

- データベースのOracleホーム: データベース・ソフトウェアをプロビジョニングできる宛先ホストの場所。これはデータベース用のOracleホーム・ディレクトリです。「共有データベースOracleホーム」を選択し、共有の場所でデータベースOracleホームを有効にします。

グリッド・インフラストラクチャの場合、Oracleベースは/u01/app/userでOracleホームは%ORACLE_BASE/../../gridです。%ORACLE_BASE%および%GI_ORACLE_BASE%を使用して、それぞれの値に補完される相対パスを指定できます。

「追加パラメータ」セクションで、クローン関連のファイルを一時的に格納する宛先ホスト上で「作業ディレクトリ」を指定します。このディレクトリには、約7GBの空き領域があることを確認します。インストーラ・パラメータについては、Oracle Grid Infrastructureのプロビジョニング時に実行する追加のOracle Universal Installer (OUI)パラメータを指定します。たとえば、-force (警告を上書き)、-debug (デバッグ情報を詳細に表示)、および-invPtrLoc <Location> (UNIXのみ)と指定します。パラメータは必ず空白で区切ります。

OCFSデバイスは、「インストーラ・パラメータ」フィールドでデバイスをカンマで区切った次の形式で指定することもできます。

Device Number:Partition Number: Drive letter: [DATA | SOFTWARE]

次に例を示します。

「次へ」をクリックします。構成ページに戻ります。ソフトウェアのソースおよび宛先の場所を構成してある場合は、「ソフトウェアの構成」タスクが構成済ステータスになります。

9. 「グリッド・インフラストラクチャの構成」リンクをクリックします。

10. 「記憶域の選択」ページで、グリッド・インフラストラクチャの記憶域タイプとして「自動ストレージ管理」を選択し、データベースに対しては「ファイル・システム」を選択し、投票ディスクおよびOracle Cluster Registry (OCR)を格納するための記憶域タイプを示します。投票ディスクおよびOCRは、Oracleクラスタウェアによってリソースを管理するために使用されます。
設計者として、鍵アイコンをクリックしてこれらのフィールドをロックできます。ロックすると、これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

11. GIの構成ページの基本設定セクションで、「クラスタ名」、「SCAN名」および「SCANポート」を指定します。デフォルトのSCANポートはポート1521ですが、別のポートを選択して指定できます。指定したSCANポートが有効であるかどうか、および他の目的で使用されていないかどうかが確認されます。インストール後、TNSリスナーが、SCAN名へのクライアント接続に応答するためにこのポートをリスニングします。

クラスタの外部の仮想ホスト名に名前を動的に割り当てる場合、「GNS設定」セクションで、「GNSの構成」を選択し、「GNSサブシステム」および「GNS VIPアドレス」を指定します。

デフォルトでは、GIネットワーク・セクションで、選択した宛先ホストと同じ名前とサブネットを持つネットワーク・インタフェースが自動的に検出され、表示されます。これらのネットワーク・インタフェース構成の詳細を検証します。「使用方法」列では、パブリック・インタフェースとしてインタフェースを構成するには「パブリック」を選択し、プライベート・インタフェースとしてインタフェースを構成するには「プライベート」を選択します。

「追加」をクリックしてインタフェースを追加し、「インタフェース名」と「インタフェース・サブネット」を指定して「OK」をクリックします。「使用方法」には、「パブリック」、「プライベート」、またはインタフェースを使用しない場合は「未使用」を選択します。

グリッド・インフラストラクチャの記憶域タイプに「自動ストレージ管理」を選択した場合、「ASM記憶域」セクションで、Cloud Controlにより検出されて表に表示されているASMディスク・グループから選択します。「追加」をクリックしてASMディスク・グループを追加します。ディスク・グループの追加/編集ダイアログ・ボックスでは、「ディスク・グループ名」および「ディスク・リスト」を指定し、冗長性を「標準」、「高」または「外部」に指定します。「OK」をクリックします。クラスタ・レジストリおよび投票ディスク・ファイルを格納する「OCR/投票ディスク」を選択し、ASMSNMPおよびSYSユーザー用のASM資格証明を指定します。

Oracle RACデータベースの記憶域タイプに「ファイル・システム」を選択した場合、Oracle Cluster Registry (OCR)および投票ディスクの記憶域の場所を指定します。「標準」または「外部」を選択して冗長性レベルを指定し、その場所を指定します。

設計者として、鍵アイコンをクリックしてこれらのフィールドをロックできます。ロックすると、これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。構成ページに戻ります。グリッド・インフラストラクチャおよびデータベースの記憶域オプションを構成してある場合は、「グリッド・インフラストラクチャの構成」タスクが完了ステータスになります。

12. 「データベースの作成」リンクをクリックします。

13. データベース・テンプレート・ページでは、データベース・テンプレートの場所を選択します。この場所はソフトウェア・ライブラリまたはOracleホームのいずれかにできます。選択したテンプレートは、選択したOracleホームのバージョンと互換性を保っている必要があります。
「ソフトウェア・ライブラリ」を選択した場合、検索アイコンをクリックし、ソフトウェア・ライブラリからテンプレートを選択します。「管理対象ホスト上の一時的な格納場所」を指定します。この場所は、以前に選択した参照ノード上に存在する必要があります。

「テンプレートの詳細の表示」をクリックし、選択したテンプレートの詳細を表示します。初期化パラメータ、表領域、データファイル、REDOログ・グループ、共通オプション、およびテンプレートの他の詳細を表示できます。

「Oracleホーム」を選択した場合は、「Oracleホーム」からテンプレートを選択します。デフォルトの場所はORACLE_HOME/assistants/dbca/templatesです。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

14. 「IDおよび配置」ページで、Oracle RACデータベースの構成タイプ(「管理されたポリシー」または「管理されたAdmin」)を選択します。
管理者管理型データベースの場合、クラスタ・データベースを作成するノードを選択します。

ポリシー管理型データベースの場合、データベースの作成に使用するサーバー・プールを既存のサーバー・プールのリストから選択するか、新規サーバー・プールの作成を選択します。ポリシー管理型データベースは、データベース・バージョン11.2以上に対して作成できます。11.2未満のデータベース・バージョンの場合、ノードを選択してOracle RACデータベースを作成する必要があります。

「グローバル・データベース名」および「SID」接頭辞を指定します。SYS、SYSTEM、DBSNMPの「データベース資格証明」を指定します。これらのユーザー・アカウントのそれぞれに、同じ管理パスワードを使用することも異なる管理パスワードを指定することもできます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

15. 「記憶域の場所」ページで、Oracle RACデータベースの記憶域タイプに「ファイル・システム」を選択します。
「データベース・ファイルの場所」セクションで、データファイル、一時ファイル、REDOログおよび制御ファイルを格納する場所を指定します。これらの場所は、クラスタ・ファイル・システムの場所やASMディスク・グループなどの共有記憶域上にある必要があります。

- テンプレートからのデータベース・ファイルの場所を使用を選択し、使用されているテンプレートからのデフォルトを選択します。

- 全データベース・ファイルの共通の場所の使用を選択し、別の場所を指定します。
「REDOログおよび制御ファイルを多重化」セクションで「Oracle Managed Files(OMF)の使用」オプションを選択すると、REDOログ・ファイルおよび制御ファイルの重複コピーを格納できます。多重化によって強力なフォルト・トレランスが提供されます。最大5つの場所を指定できます。

「リカバリ・ファイルの場所」セクションで、「データベース・ファイルの場所と同じ記憶域タイプを使用してください」を選択し、リカバリ・ファイルの記憶域タイプにデータベース・ファイルと同じタイプを使用します。「フラッシュ・リカバリ領域の使用」を選択し、リカバリ関連ファイルの場所および高速リカバリ領域サイズを指定します。

「アーカイブ有効化」を選択してアーカイブのログを有効にします。「アーカイブ・ロブの場所を指定してください」をクリックし、最大9箇所のアーカイブ・ログの場所を指定します。ログの場所を指定しない場合、ログはデフォルトの場所に保存されます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

16. 初期化パラメータ・ページで、メモリー管理タイプとして「自動メモリー管理」または「自動共有メモリー管理」を選択します。「メモリー設定として使用可能メモリーの割合」を選択し、メモリー設定として使用可能物理メモリーの割合を指定します。自動共有メモリー管理の場合は、「SGA合計」および「PGA合計」を指定します。自動メモリー管理の場合は、「Oracleで使用するメモリーの合計」を指定します。
「データベースのサイズ設定」セクションで、「ブロック・サイズ」および「プロセス」の数を指定します。データベース・テンプレート・ページでデータファイルとともにデータベース・テンプレートを選択した場合、ブロック・サイズは編集できません。

「ホストCPU数」を指定します。指定できる最大CPU数はホストに存在するCPUの数と同じです。

「キャラクタ・セット」セクションでは、デフォルトのキャラクタ・セットを選択します。デフォルトのキャラクタ・セットはロケールおよびオペレーティング・システムに基づいています。

各国語キャラクタ・セットを選択します。デフォルトはAL16UTF16です。

「データベース接続モード」セクションでは、専用サーバー・モードを選択します。共有サーバー・モードについては、共有サーバーの数を指定します。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

17. 「追加の構成オプション」ページで、ソフトウェア・ライブラリまたはローカル・ディスクからカスタム・スクリプトを選択します。データベース・テンプレート・ページで「構造のみ」データベース・テンプレートを選択した場合、データベース・オプションを表示および編集することもできます。
「ロック」アイコンをクリックし、フィールドをロックします。「次へ」をクリックします。

18. 指定した情報を確認し、「次へ」をクリックします。構成ページに戻ります。データベースを構成してある場合は、「データベースの作成」タスクが構成済ステータスになります。「次へ」をクリックします。

19. 「コンプライアンス標準」リンクをクリックします。

20. 「構成標準ターゲット・アソシエーション」ページで、データベースと関連付けるコンプライアンス標準を選択します。「次へ」をクリックします。

21. 「構成」ページで「次へ」をクリックします。

22. カスタム・パラメータが必要なユーザー・カスタマイズ済デプロイメント・プロシージャに対してのみカスタム・プロパティ・ページが表示されます。デプロイに関するカスタム・プロパティ(存在する場合)を指定します。「次へ」をクリックします。

23. 「スケジュール」ページで、デプロイメント・インスタンス名を指定します。プロシージャを即時に実行する場合は、デフォルトの選択(「1回(即時)」)を保持します。プロシージャを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。デプロイメント・プロシージャのステータスに応じて、通知プリファレンスを設定できます。前提条件のみを実行する場合は、「前提条件チェックの実行後に結果を分析するためにプロシージャを停止します」を選択すると、すべての前提条件チェックの実行後にプロシージャ実行を一時停止できます。
「次へ」をクリックします。

24. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。

25. オペレータ・ロールで、保存したデプロイメント・プロシージャを起動します。プロビジョニングのターゲットを追加し、デプロイメント・プロシージャの構成可能フィールドに値を指定します。

26. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各ステップの「ステータス」リンクをクリックし、各ステップの実行の詳細を表示します。「デバッグ」をクリックしてデバッグのロギング・レベルを設定し、「停止」をクリックしてプロシージャの実行を停止できます。

27. プロシージャの実行の完了後、「ターゲット」メニューをクリックし、「すべてのターゲット」を選択して、「すべてのターゲット」ページに移動し、新しくプロビジョニングしたデータベースがCloud Controlターゲットとして表示されることを確認します。

注意:
デプロイメント・プロシージャが失敗した場合、第F.7項で説明されているログ・ファイルを確認します。

7.6 Oracle Real Application Clusters (Oracle RAC)データベースのプロビジョニングでの非root資格証明の使用

Oracle RACデータベースのプロビジョニングでは、非root資格証明がサポートされています。この機能を使用するには、次の手順を実行します。

1. 「OSユーザーの指定」ページで、「優先資格証明の上書き」を指定します。表示された「OSユーザーの指定」ダイアログ・ボックスで、通常の名前の資格証明を作成して、「実行権限」を「なし」に設定します。「OK」をクリックします。

2. 通常ユーザーと特権ユーザーの両方に対して、通常の名前の新しい資格証明を選択します。

3. 「送信」をクリックします。
データベースのプロビジョニング・プロセスがroot資格証明を必要とするステップに到達したら、プロセスが停止します。この場合、コマンドラインを手動で実行する必要があります。これを実行するには、環境を$AGENT_HOME,に設定し、次の3つのステップで「方法」フィールドからコマンドラインのコピーを実行します。

- 修正の手動による実行

- rootスクリプトの手動による実行(CRSインストール・フェーズ時)

- rootスクリプトの手動による実行(RACデータベースのインストール・フェーズ時)

4. 各ステップでrootユーザーを使用してコマンドラインを手動で実行したら、「確認」をクリックします。これで、データベースのプロビジョニング・プロセスが、完了するまで続行されます。

8 Oracle Real Application Clusters One (Oracle RAC One) Nodeデータベースのプロビジョニング

この章では、Oracle Enterprise Manager Cloud Control(Cloud Control)を使用して、Oracle Real Application Clusters One (Oracle RAC One) Nodeデータベースをプロビジョニングする方法について説明します。この章の具体的な内容は次のとおりです。

- Oracle RAC One Nodeデータベースのプロビジョニングの概要

- Oracle RAC One Nodeデータベースをプロビジョニングするためのデプロイメント・プロシージャ

- Oracle RAC One Nodeデータベースのプロビジョニング

8.1 Oracle RAC One Nodeデータベースのプロビジョニングの概要

この項では、この章に取り組むための手引きとして、Oracle RAC One Nodeデータベースのプロビジョニング手順の概要を説明します。この項は、Oracle RAC One Nodeのプロビジョニングを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表8-1 Oracle RAC One Nodeデータベースのプロビジョニングの概要

ステップ

説明

参照リンク

ステップ1

デプロイメント・プロシージャの理解

Oracle RAC One Nodeデータベースをプロビジョニングするには、2つのデプロイメント・プロシージャを実行する必要があります。

- Oracle RAC One Nodeデータベースのプロビジョニング用のデプロイメント・プロシージャの詳細は、第8.2項を参照してください。

ステップ2

ユースケースの理解

この項では、Oracle RAC One Nodeデータベースのプロビジョニングのユースケースを示します。

- Oracle RAC One Nodeデータベースのプロビジョニングのユースケースを理解するには、第8.3項を参照してください。

ステップ3

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

- Oracle RAC One Nodeデータベースのプロビジョニングの前提条件の詳細は、第8.3.1項を参照してください。

ステップ4

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行してOracle RAC One Nodeデータベースを正常にプロビジョニングします。

- Oracle RAC One Nodeデータベースをプロビジョニングするには、第8.3.2項で説明する手順に従います。

8.2 Oracle RAC One Nodeデータベースをプロビジョニングするためのデプロイメント・プロシージャ

Cloud Controlを使用してOracle RAC Oneデータベースをプロビジョニングするには、次のデプロイメント・プロシージャを使用します。

- 「Oracle RACデータベースのプロビジョニング」 + 「Oracleデータベースの作成」

「Oracle RACデータベースのプロビジョニング」デプロイメント・プロシージャを使用してOracle RACデータベース・ソフトウェアをプロビジョニングしてから、「Oracleデータベースの作成」デプロイメント・プロシージャを実行してOracle RAC Oneデータベースを作成します。

8.3 Oracle RAC One Nodeデータベースのプロビジョニング

この項では、Oracle RAC One Nodeデータベースのプロビジョニング方法について説明します。

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

- Oracle RAC One Nodeデータベースをプロビジョニングするための前提条件

- Oracle RAC One Nodeデータベースをプロビジョニングする手順

8.3.1 Oracle RAC One Nodeデータベースをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

設計者に対する前提条件

デプロイメント・プロシージャをプロビジョニングするためにインフラストラクチャを作成する管理者が満たす必要のあるインフラストラクチャ関連の前提条件は、次のとおりです。

- 第2章で説明されているインフラストラクチャの要件を満たしていることを確認します。

- ターゲット・ホストでOracle Grid InfrastructureおよびOracle RACインストールのハードウェア、ソフトウェア、ネットワーク要件を満たします。Oracle Grid InfrastructureおよびOracle RACインストールのハードウェア、ソフトウェアおよびネットワーク要件の詳細は、Oracle Grid Infrastructureのインストレーション・ガイドを参照してください。

- Cloud Controlで宛先ホストを検出および監視します。このために、宛先ホスト上で最新バージョンのOracle Management Agent (管理エージェント)が必要です。詳細は、Oracle Enterprise Manager Cloud Control基本インストレーション・ガイドを参照してください。エージェントがすべてのホスト上で同じ場所にインストールされていることを確認します。

- Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)を設定します。インストール・メディア、データベース・テンプレート、またはプロビジョニング・エンティティがソフトウェア・ライブラリで使用可能であることを確認します。それらの作成の詳細は、第4.3項を参照してください。また、プロビジョニング・プロファイルを使用して、データベース・テンプレートを格納します。データベース・プロビジョニング・プロファイルの作成の詳細は、第4.3.5項を参照してください。

- 宛先ホストのオペレーティング・システム資格証明を優先資格証明としてOracle Management Repository (管理リポジトリ)に格納するか、名前付き資格証明を使用します。
SUDOおよびPowerBrokerを使用する場合、これらの認証ユーティリティの設定に関する情報は、第2.3項を参照してください。

- デプロイメント・プロシージャを構成中のユーザーは、次に示すグループのメンバーである必要があります。これらのグループが存在しない場合、デプロイメント・プロシージャによってこれらが自動的に作成されます。ただし、これらをNIS上で作成する必要がある場合、デプロイメント・プロシージャを実行する前にこれらを手動で作成する必要があります。このようなオペレーティング・システム・グループの作成の詳細は、Oracle Grid Infrastructureのインストレーション・ガイドを参照してください。
Oracle Databaseユーザー(通常はoracle)は、次のグループのメンバーである必要があります。

- プライマリ・グループとしてのインベントリ・グループ(OINSTALL)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

グリッド・インフラストラクチャ・ユーザー(通常はgrid)は、次のグループのメンバーである必要があります。

- プライマリ・グループとしてのインベントリ・グループ(OINSTALL)

- ASMデータベース管理者(ASMDBA)

- ASMインスタンス・オペレータ(ASMOPER)

- ASMインスタンス管理者(OSASM)

Oracle RAC Databaseユーザーは、次のグループのメンバーである必要があります。

- ASMデータベース管理者(ASMDBA)

- 次の場所に対する書込み権限を持つオペレーティング・システム・ユーザーを使用していることを確認します。

- グリッド・インフラストラクチャに関する診断データファイルを格納できる、グリッド・インフラストラクチャのOracleベース・ディレクトリ。

- データベースに関する診断データファイルを格納できる、データベースのOracleベース・ディレクトリ。

- グリッド・インフラストラクチャ・ソフトウェアをプロビジョニングできる、グリッド・インフラストラクチャ・ソフトウェアのディレクトリ。

- データベース・ソフトウェアをプロビジョニングできるデータベース・ソフトウェアの場所。 クローニングに関するファイルをステージングできる作業ディレクトリ。

- Cloud Controlで「操作の任意のターゲット」権限があることを確認してください。

オペレータに対する前提条件

デプロイメント・プロシージャのプロビジョニングを実行するオペレータが満たす必要のあるデプロイメント・プロシージャ関連の前提条件は、次のとおりです。

- オペレータとして、(デザイナによって設定およびロックされた)資格証明の表示、ターゲットの表示、ジョブの発行、およびデプロイメント・プロシージャの起動を行う権限があることを確認してください。

- 次のグループに指定したオペレーティング・システム・グループが、プロビジョニングに選択したホストにすでに存在していることを確認します。これらのグループのオペレーティング・システム・ユーザーには、それぞれの権限が自動的に付与されます。

- インベントリ・グループ(OINSTALL)

- ASMデータベース管理者(ASMDBA)

- ASMインスタンス・オペレータ(ASMOPER)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

- ASMインスタンス管理者(OSASM)

- Cloud Controlで「操作の任意のターゲット」権限があることを確認してください。

8.3.2 Oracle RAC One Nodeデータベースをプロビジョニングする手順

Oracle RAC One Nodeデータベースをプロビジョニングするには、次の手順に従います。

1. デザイナとしてログインし、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. 「データベース・プロシージャ」ページでOracle RACデータベースのプロビジョニング・デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracle RACデータベースのプロビジョニング・ウィザードが起動します。

3. 「ホストの選択」ページで、プロビジョニング・プロファイルをデプロイメントに使用する場合は、「プロビショニング・プロファイルを選択」で、事前に保存した構成パラメータを含むプロファイルを選択します。
「宛先ホストの選択」セクションで、「追加」をクリックし、ソフトウェアをデプロイおよび構成する宛先ホストを選択します。

「実行するタスクの選択」セクションで、プラットフォーム、プロセスのバージョンおよびプロビジョニングするコンポーネントを選択します。

- グリッド・インフラストラクチャをデプロイするには、「ソフトウェアのデプロイと構成」を選択してOracle RACデータベースをプロビジョニングします。

- データベース・ソフトウェアをデプロイするには、Oracle RACデータベースのインストール後に新規データベースを作成し構成するRAC One Nodeデータベースのデプロイと作成を選択します。

オペレータ・ロールで編集しないフィールドの「ロック」アイコンをクリックします。デプロイメント・プロシージャのロック・ダウン機能の詳細は、第4.1項を参照してください。

「次へ」をクリックします。

4. 「構成」ページで、「ホストの設定」リンクをクリックします。

5. OSユーザーの指定ページで、データベースのプロビジョニングに必要なオペレーティング・システム・ユーザーとグループを指定します。
「データベース・ユーザー」とASMユーザーについては、OSグループへの追加対象として「通常ユーザー」および「特権ユーザー」を選択します。

「次へ」をクリックします。

6. OSグループの指定ページで、オペレーティング・システム認証に使用するOSグループを指定します。これらのグループが、選択したホストでプロビジョニング用にすでに存在することを確認します。

- インベントリ・グループ(OINSTALL)

- ASMデータベース管理者(ASMDBA)

- ASMインスタンス・オペレータ(ASMOPER)

- データベース管理者(OSDBA)

- データベース・オペレータ(OSOPER)

- ASMインスタンス管理者(OSASM)

「次へ」をクリックします。構成ページに戻ります。宛先ホストを構成してある場合は、「ホストの設定」タスクが構成済ステータスになります。

7. 「ソフトウェアのデプロイ」リンクをクリックします。

8. ソフトウェアの場所ページで、Oracle Grid InfrastructureおよびOracle RACのソフトウェア・バイナリを配置する場所である$ORACLE_HOMEを指定します。設計者として、鍵アイコンをクリックしてこれらのフィールドをロックできます。ロックすると、これらのフィールドはオペレータ・ロールでは編集できなくなります。
「ソース」セクションで「グリッド・インフラストラクチャ」および「Oracleデータベース」バイナリのソフトウェア・ライブラリの場所を選択します。

「宛先ロケーション」では、次を指定します。

- グリッド・インフラストラクチャ用Oracleベース: 診断および管理ログ、およびその他のグリッド・インフラストラクチャに関連するログが格納される宛先ホストの場所。

- グリッド・インフラストラクチャ・ホーム: グリッド・インフラストラクチャのソフトウェアをプロビジョニングできる宛先ホストの場所。これはグリッド・インフラストラクチャのOracleホーム・ディレクトリです。この場所には、グリッド・インフラストラクチャまたはデータベースのOracleベースのサブディレクトリを選択しないでください。「共有グリッド・インフラストラクチャ・ホーム」を選択し、共有の場所でグリッド・インストラクチャOracleホームを有効にします。指定するディレクトリ・パスが、第7.3.2.1項で説明している要件を満たすことを確認します。

- データベース用Oracleベース: 診断および管理ログ、およびその他のデータベース関連ログを格納できる宛先ホストの場所。この場所はダンプ・ファイルの格納にのみ使用され、データベース・ソフトウェアがインストールされるOracleホーム・ディレクトリとは別の場所になります。

- データベースのOracleホーム: データベース・ソフトウェアをプロビジョニングできる宛先ホストの場所。これはデータベース用のOracleホーム・ディレクトリです。「共有データベースOracleホーム」を選択し、共有の場所でデータベースOracleホームを有効にします。

「追加パラメータ」セクションで、クローン関連のファイルを一時的に格納する宛先ホスト上で「作業ディレクトリ」を指定します。このディレクトリには、約7GBの空き領域があることを確認します。インストーラ・パラメータについては、Oracle Grid Infrastructureのプロビジョニング時に実行する追加のOracle Universal Installer (OUI)パラメータを指定します。たとえば、-force (警告を上書き)、-debug (デバッグ情報を詳細に表示)、および-invPtrLoc <Location> (UNIXのみ)と指定します。パラメータは必ず空白で区切ります。

「次へ」をクリックします。構成ページに戻ります。ソフトウェアのソースおよび宛先の場所を構成してある場合は、「ソフトウェアの構成」タスクが構成済ステータスになります。

9. 「グリッド・インフラストラクチャの構成」リンクをクリックします。

10. 記憶域の選択ページで、グリッド・インフラストラクチャとデータベースの記憶域タイプとして「自動ストレージ管理」または「共有ファイル・システム」を選択し、投票ディスクおよびOracle Cluster Registry (OCR)を格納するための記憶域タイプを指定します。投票ディスクおよびOCRは、Oracleクラスタウェアによってリソースを管理するために使用されます。次のオプションから選択できます:

- グリッド・インフラストラクチャおよびOracle RACデータベースの両方に対し「自動ストレージ管理」

- グリッド・インフラストラクチャに対し「自動ストレージ管理」、Oracle RACデータベースに対し「ファイル・システム」

- グリッド・インフラストラクチャおよびOracle RACデータベースの両方に対し「ファイル・システム」

- グリッド・インフラストラクチャに対し「ファイル・システム」、Oracle RACデータベースに対し「自動ストレージ管理」

設計者として、鍵アイコンをクリックしてこれらのフィールドをロックできます。ロックすると、これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

11. GIの構成ページの基本設定セクションで、「クラスタ名」、「SCAN名」および「SCANポート」を指定します。デフォルトのSCANポートはポート1521ですが、別のポートを選択して指定できます。指定したSCANポートが有効であるかどうか、および他の目的で使用されていないかどうかが確認されます。インストール後、TNSリスナーが、SCAN名へのクライアント接続に応答するためにこのポートをリスニングします。
クラスタの外部の仮想ホスト名に名前を動的に割り当てる場合、GNS設定セクションで、「GNSの構成とDHCPでの自動割当」を選択し、GNSサブシステムおよび「GNS VIPアドレス」を指定します。

デフォルトでは、GIネットワーク・セクションで、選択した宛先ホストと同じ名前とサブネットを持つネットワーク・インタフェースが自動的に検出され、表示されます。これらのネットワーク・インタフェース構成の詳細を検証します。「使用方法」列では、パブリック・インタフェースとしてインタフェースを構成するには「パブリック」を選択し、プライベート・インタフェースとしてインタフェースを構成するには「プライベート」を選択します。

「追加」をクリックしてインタフェースを追加し、「インタフェース名」と「インタフェース・サブネット」を指定して「OK」をクリックします。「使用方法」には、「パブリック」、「プライベート」、またはインタフェースを使用しない場合は「未使用」を選択します。

グリッド・インフラストラクチャおよびOracle RACデータベースのどちらかまたは両方の記憶域タイプに「自動ストレージ管理」を選択した場合、「ASM記憶域」セクションで、Cloud Controlにより検出されて表に表示されているASMディスク・グループから選択します。「追加」をクリックしてASMディスク・グループを追加します。ディスク・グループの追加/編集ダイアログ・ボックスでは、「ディスク・グループ名」および「ディスク・リスト」を指定し、冗長性を「標準」、「高」または「外部」に指定します。「OK」をクリックします。クラスタ・レジストリおよび投票ディスク・ファイルを格納する「OCR/投票ディスク」を選択し、ASMSNMPおよびSYSユーザー用のASM資格証明を指定します。

グリッド・インフラストラクチャまたはOracle RACデータベースの記憶域タイプに「ファイル・システム」を選択した場合、「ファイルシステム記憶域」セクションで、Oracle Cluster Registry (OCR)および投票ディスクの記憶域の場所を指定します。「標準」または「外部」を選択して冗長性レベルを指定し、その場所を指定します。

設計者として、鍵アイコンをクリックしてこれらのフィールドをロックできます。ロックすると、これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。構成ページに戻ります。グリッド・インフラストラクチャおよびデータベースの記憶域オプションを構成してある場合は、「グリッド・インフラストラクチャの構成」タスクが完了ステータスになります。「次へ」をクリックします。

12. カスタム・パラメータが必要なユーザー・カスタマイズ済デプロイメント・プロシージャに対してのみカスタム・プロパティ・ページが表示されます。デプロイに関するカスタム・プロパティ(存在する場合)を指定します。「次へ」をクリックします。

13. プロシージャを即時実行する場合、スケジュール・ページで、デフォルトで選択されている「1回(即時)」を選択します。プロシージャを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。「次へ」をクリックします。

14. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。

15. データベース・プロシージャ・ページでは、Oracle Databaseデプロイメント・プロシージャの作成を選択し、「起動」をクリックします。Oracle Databaseの作成プロビジョニング・ウィザードが起動します。

16. データベース・バージョンおよびタイプ・ページで、データベースの「バージョン」を選択し、「Oracle RAC One Nodeデータベース」を選択します。
「クラスタ」セクションで、すでにプロビジョニングされているクラスタとOracleホームを選択します。クラスタ上でデータベースを作成するための参照として使用する検証を実行するための参照ホストを選択します。

「クラスタ資格証明」を選択するか新規に追加します。プラス記号のアイコンをクリックして、新規の資格証明を追加し、「ユーザー名」、「パスワード」および「実行権限」を指定して資格証明を保存します。

「次へ」をクリックします。

17. データベース・テンプレート・ページでは、データベース・テンプレートの場所を選択します。この場所はソフトウェア・ライブラリまたはOracleホームのいずれかにできます。選択したテンプレートは、選択したOracleホームのバージョンと互換性を保っている必要があります。
「ソフトウェア・ライブラリ」を選択した場合、検索アイコンをクリックし、ソフトウェア・ライブラリからテンプレートを選択します。「管理対象ホスト上の一時的な格納場所」を指定します。この場所は、以前に選択した参照ノード上に存在する必要があります。

「テンプレートの詳細の表示」をクリックし、選択したテンプレートの詳細を表示します。初期化パラメータ、表領域、データファイル、REDOログ・グループ、共通オプション、およびテンプレートの他の詳細を表示できます。

「Oracleホーム」を選択した場合は、「Oracleホーム」からテンプレートを選択します。デフォルトの場所はORACLE_HOME/assistants/dbca/templatesです。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

18. 識別および配置ページで、クラスタ・データベースを作成するノードを選択します。「グローバル・データベース名」および「SID」接頭辞を指定します。SYS、SYSTEM、DBSNMPの「データベース資格証明」を指定します。Oracle RACデータベースのタイプとして、「管理されたポリシー」または「管理されたAdmin」を選択します。「サービス名」を指定します。

注意:
データベース・サービス名は、アプリケーションがOracle RAC One Nodeデータベースに接続し、オンラインの再配置を簡略化するために使用されます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

19. 記憶域の場所ページで、記憶域タイプとして「ファイル・システム」または「自動ストレージ管理(ASM)」を選択します。
「データベース・ファイルの場所」セクションで、データファイル、一時ファイル、REDOログおよび制御ファイルを格納する場所を指定します。

- テンプレートからのデータベース・ファイルの場所を使用を選択し、使用されているテンプレートからのデフォルトを選択します。

- 全データベース・ファイルの共通の場所の使用を選択し、別の場所を指定します。
「REDOログおよび制御ファイルを多重化」セクションで「Oracle Managed Files(OMF)の使用」オプションを選択すると、REDOログ・ファイルおよび制御ファイルの重複コピーを格納できます。多重化によって強力なフォルト・トレランスが提供されます。最大5つの場所を指定できます。

「リカバリ・ファイルの場所」セクションで、「フラッシュ・リカバリ領域の使用」を選択し、リカバリ関連ファイルの場所および高速リカバリ領域サイズを指定します。

「アーカイブ・ログの設定」セクションで、「アーカイブ有効化」を選択し、アーカイブ・ロギングを有効にします。「アーカイブ・ログの場所を指定してください」で、最大9箇所のアーカイブ・ログの場所のデータ・ファイルを指定できます。ログの場所を指定しない場合、ログはデフォルトの場所に保存されます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

20. 初期化パラメータ・ページで、メモリー管理タイプとして「自動メモリー管理」または「自動共有メモリー管理」を選択します。「メモリー設定として使用可能メモリーの割合」を選択し、メモリー設定として使用可能物理メモリーの割合を指定します。自動共有メモリー管理の場合は、「SGA合計」および「PGA合計」を指定します。自動メモリー管理の場合は、「Oracleで使用するメモリーの合計」を指定します。
「データベースのサイズ設定」セクションで、「ブロック・サイズ」および「プロセス」の数を指定します。データベース・テンプレート・ページでデータファイルとともにデータベース・テンプレートを選択した場合、ブロック・サイズは編集できません。

「ホストCPU数」を指定します。指定できる最大CPU数はホストに存在するCPUの数と同じです。

「キャラクタ・セット」セクションでは、デフォルトのキャラクタ・セットを選択します。デフォルトのキャラクタ・セットはロケールおよびオペレーティング・システムに基づいています。

各国語キャラクタ・セットを選択します。デフォルトはAL16UTF16です。

「データベース接続モード」セクションでは、専用サーバー・モードを選択します。共有サーバー・モードについては、共有サーバーの数を指定します。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

21. 追加の構成オプション・ページで、ソフトウェア・ライブラリからカスタム・スクリプトを選択します。データベース・テンプレート・ページで「構造のみ」データベース・テンプレートを選択した場合、データベース・オプションを表示および編集することもできます。「ロック」アイコンをクリックし、フィールドをロックします。「次へ」をクリックします。

22. スケジュール・ページで、デプロイ用の「デプロイメント・プロシージャ・インスタンス名」およびスケジュールを指定します。プロシージャを即時実行する場合、デフォルトで選択されている「即時」を選択します。プロシージャを後で実行する場合は、「後で」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。「次へ」をクリックします。

23. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。

24. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各ステップの「ステータス」リンクをクリックし、各ステップの実行の詳細を表示します。「デバッグ」をクリックしてデバッグのロギング・レベルを設定し、「停止」をクリックしてプロシージャの実行を停止できます。

9 10gおよび11g用のOracle Real Application Clustersのプロビジョニング

この章では、Oracle Enterprise Manager Cloud Control(Cloud Control)を使用して、10gおよび11gリリース1用のOracle Real Application Clusters (Oracle RAC)をプロビジョニングする方法について説明します。この章の具体的な内容は次のとおりです。

- 10gおよび11g用のOracle Real Application Clustersのプロビジョニングの概要

- Oracle RACのプロビジョニング時にデプロイされるコア・コンポーネント

- 実行中のOracle Real Application Clusterのクローニング

- ゴールド・イメージを使用したOracle Real Application Clusterのプロビジョニング

- アーカイブ・ソフトウェア・バイナリを使用したOracle Real Application Clusterのプロビジョニング

9.1 10gおよび11g用のOracle Real Application Clustersのプロビジョニングの概要

この項では、この章に取り組むための手引きとして、10gおよび11gリリース1用のOracle RACのプロビジョニング手順の概要を説明します。この項は、10gおよび11gリリース1用のOracle RACのプロビジョニングを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表9-1 Oracle RACのプロビジョニングの概要

ステップ

説明

参照リンク

ステップ1

プロビジョニングされたコンポーネントの理解

プロビジョニングされたコア・コンポーネントについて理解します。

プロビジョニングされたコア・コンポーネントの詳細は、第9.2項を参照してください。

ステップ2

ユースケースの選択

ここでは、Oracle RACのプロビジョニングのユースケースのいくつかを説明します。ご自身の要件に最適なユースケースを選択してください。

- 既存のOracle RACのクローニングの詳細は、第9.3項を参照してください。

- ゴールド・イメージを使用したOracle RACのプロビジョニングの詳細は、第9.4項を参照してください。

- インストール・メディアからのソフトウェア・バイナリを使用したOracle RACのプロビジョニングの詳細は、第9.5項を参照してください。

ステップ3

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

- 既存のOracle RACのクローニングの前提条件の詳細は、第9.3.1項を参照してください。

- ゴールド・イメージを使用したOracle RACのプロビジョニングの前提条件の詳細は、第9.4.1項を参照してください。

- インストール・メディアからのソフトウェア・バイナリを使用したOracle RACのプロビジョニングの前提条件の詳細は、第9.5.1項を参照してください。

ステップ4

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行してOracle RACを正常にプロビジョニングします。

- 既存のOracle RACをクローニングするには、第9.3.2項で説明する手順に従います。

- ゴールド・イメージを使用してOracle RACをプロビジョニングするには、第9.4.2項で説明する手順に従います。

- インストール・メディアからのソフトウェア・バイナリを使用してOracle RACをプロビジョニングするには、第9.5.2項で説明する手順に従います。

9.2 Oracle RACのプロビジョニング時にデプロイされるコア・コンポーネント

Oracle RACをプロビジョニングする場合、基本的に、デプロイメント・プロシージャは次のコア・コンポーネントをデプロイします。

- Oracle Clusterware

- Oracle RACデータベース

- オプションで自動ストレージ管理 (ASM)
Oracle RACデータベース用と同じOracleホームにASMをデプロイすることも、完全に異なるOracleホームにデプロイする(推奨)こともできます。

注意:
デプロイメント・プロシージャを実行して共有ファイル・システム上にOracle RACをデプロイする場合、ソフトウェア・バイナリは共有された場所にインストールされますが、構成はすべてのノード上で行われます。新規ノードを構成するには、「ワンクリックでクラスタ・データベース拡張」プロシージャを実行して、Oracle RACスタックを別のノードに拡張します。

9.3 実行中のOracle Real Application Clusterのクローニング

この項では、Cloud Controlにより監視されるホストで実行中の既存のOracle RACインストールをクローニングする方法について説明します。

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

- 実行中のOracle Real Application Clustersをクローニングするための前提条件

- 実行中のOracle Real Application Clustersをクローニングする手順

9.3.1 実行中のOracle Real Application Clustersをクローニングするための前提条件

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

設計者に対する前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- Solarisプラットフォーム上でOracle RAC 11gリリース1 (11.1.0.6)をクローニングする場合、クローニングする必要のあるOracleホームにパッチ番号6486988を適用します。

- Oracle RACに必要なハードウェアおよびソフトウェアが、ターゲット・ホストに存在することを確認します。ハードウェア要件には、次の設定が含まれます。

- プライベート・ネットワーク: 各ノードにネットワーク・インタフェース・カードがインストールされており、互いに接続されている必要があります。

- ノード間の共有記憶域: 共有記憶域は、OCR、投票ディスクおよびデータファイルで必要です。

- 仮想IPがDNSで設定されていることを確認します。仮想IPをローカルに設定するように選択した場合は、デプロイメント・プロシージャを使用してIPアドレスを指定できます。この場合、プロシージャによって仮想IPが自動的に設定されます。

- カスタム・テンプレートを使用してデータベースの構造を作成するには、テンプレート(.dbtファイル)を作成し、ターゲット・ホストからアクセスできる場所にこれを格納します。このファイルは、ターゲット・ホストに格納することも共有場所に格納することもできます。テンプレートの作成の詳細は、第4.3.8項「データベース・テンプレートの作成」を参照してください。

- oracleおよびcrsuserなどのオペレーティング・システム・ユーザーが、クラスタのすべてのノードで使用可能であることを確認します。これらのユーザーはdbaおよびoinstallなどの関連するオペレーティング・システム・グループの一部である必要があります。
詳細は、次で使用可能な『Oracle Clusterwareインストレーション・ガイド』を参照してください。

http://www.oracle.com/pls/db111/homepage

- オペレーティング・システム・ユーザーのユーザーIDとオペレーティング・システム・グループのグループIDが、クラスタのすべてのノードで同一であることを確認します。

オペレータに対する前提条件

- NISベースのオペレーティング・システム・ユーザーは使用しないでください。

- ターゲット・ホストでデプロイメント・プロシージャおよびそのコマンドを実行する権限を持つオペレーティング・システム・ユーザーを使用していることを確認します。これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。カスタマイズの詳細は、第51章を参照してください。

- ソース・ホストとターゲット・ホストの構成を比較し、両者の構成が同じであることを確認します。構成が異なる場合は、システム管理者に連絡し、不一致を修正してから、デプロイメント・プロシージャを実行します。
ホストの構成を比較するには、Cloud Controlで「ターゲット」、「ホスト」の順にクリックします。「ホスト」ページで、ソース・ホスト名をクリックしてその「ホーム」ページにアクセスし、「ホスト」メニューから、「構成」、「比較」の順にクリックします。

- ソースの選択時に、sqlnet.oraを「除外するファイル」に示されたファイルのリストから削除することを忘れないでください。

- ターゲット・ホストのumask値が022であることを確認します。

9.3.2 実行中のOracle Real Application Clustersをクローニングする手順

既存のOracle RACインストールをクローニングするには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. 「データベースのプロビジョニング」ページで次のうちのいずれかを選択し、「起動」をクリックします。

1. デプロイメント・プロシージャをUNIXプラットフォームで実行するには、「Oracleクラスタウェアのプロビジョニング / UNIXとRDBMSバージョン10g/11g用のRAC」を選択します。

2. デプロイメント・プロシージャをMicrosoft Windowsプラットフォームで実行するには、「Oracleクラスタウェアのプロビジョニング / WindowsとRDBMSバージョン10g/11g用のRAC」を選択します。

デプロイメント・プロシージャの「ソースの選択」ページが表示されます。

3. 「ソースの選択」ページで、次を実行します。

1. 「ソースの選択」セクションで、「既存のインストールからの選択」を選択します。「参照ホスト」に対して懐中電灯アイコンをクリックして、既存のOracle RACインストールが実行しているホストを選択します。参照ホストを選択すると、アプリケーションは自動的に作業ディレクトリと選択したOracle ClusterwareおよびOracle Databaseの詳細を表示します。
選択したOracle ClusterwareおよびOracle Databaseをゴールド・イメージとしてソフトウェア・ライブラリに保存する場合、「ソフトウェア・ライブラリに保存」をクリックします。Oracle Clusterwareはクラスタウェア・クローン・コンポーネント・タイプとして、Oracle Databaseはデータベース・クローン・コンポーネント・タイプとして、それぞれ保存されます。

注意:

- 共有ディスクがソース・ホストと宛先ホスト間で使用される場合は、作業ディレクトリとして異なる場所を保持します。

- sqlnet.oraによりOracleベースがソース・インストールからハードコードされます。このファイルを削除しないと、Oracleツールおよびユーティリティは誤ったOracleベースを使用し、現在の場所は書込み可能ではないというエラー・メッセージが表示されます。

2. 「次へ」をクリックします。

4. 「ホストの選択」ページで、次を実行します。

1. 「クラスタに含めるホスト」セクションで、Addをクリックし、クラスタを形成するターゲット・ホストを選択します。選択したホストの詳細を表示するには、「オプションの表示」をクリックします。

注意:
「追加」をクリックすると、「ターゲットの選択」ポップアップ・ウィンドウが表示されます。このページでは、デフォルトで「適切なホストを表示」オプションが選択されており、プロビジョニングに最適なホストのみが表に示されています。追加するホストが見つからない場合、「すべてのホストを表示」を選択して、全部のホストのリストを表示します。

デフォルトでは、「プライベート・ホスト名」および「仮想ホスト名」に自動的に値が事前に入力されています。これらを編集し、環境に合った値を指定します。オプションで、IPアドレスを指定することもできます。

注意:
事前に入力された「プライベート・ホスト名」および「仮想ホスト名」のデフォルトの値が誤っている場合、付録F「問題のトラブルシューティング」で説明している回避策を参照してください。

これらの詳細をクラスタ構成ファイルに格納した場合、「ファイルからインポート」をクリックして、そのクラスタ構成ファイルを選択します。通常、このファイルには、追加される新しいホストの情報が含まれます。クラスタ構成ファイルの内容を理解するには、第9.5.2.1項「クラスタ構成ファイルのサンプル」を参照してください。

プライベートおよびパブリック・ネットワーク・インタフェースを構成するには、「インタフェースの選択」をクリックします。デフォルトでは、選択したターゲット・ホスト用の同じ名前とサブネットのあるインタフェースが表示されます。しかし、選択したターゲット・ホスト用のすべてのインタフェースを表示するように選択することもできます。既存のインタフェースのいずれかを選択することも、または使用したいインタフェースが存在しない場合は新しいインタフェースを指定することもできます。

2. 「ネットワーク・インタフェース構成」セクションで、プライベートおよびパブリック・インタフェースの詳細を確認します。

3. 「次へ」をクリックします。

5. 「資格証明/スケジュール」ページで、次の手順を実行します。

1. 「参照ホスト資格証明」セクションで、デフォルトの選択(「優先資格証明の使用」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

「ホスト資格証明」リストから、各Oracleホームごとに異なるオペレーティング・システム資格証明を使用する場合には「各Oracleホームごとに個別」を選択し、すべてのOracleホームで同じ資格証明を使用する場合には「すべてのOracleホームで同一」を選択します。選択に基づき、資格証明を指定します。ユーザーが同じグループ(dba/oinstall)に属していることを確認してください。

2. 「ターゲット・ホスト資格証明」セクションで、手順6 (a)で説明したとおりに資格証明を入力します。

注意:
ベンダー・クラスタウェアを使用している場合、rootおよびオペレーティング・システム・ユーザー(クラスタウェアや様々なOracleホームを所有しているoracleやcrsuserなど)は、ベンダー・クラスタウェアによって規定されているオペレーティング・システム・グループに含まれている必要があります。
たとえば、High Availability Cluster Multiprocessing (HACMP)クラスタウェアをシステムで使用している場合、hagsuserというグループを作成するか、またはこのグループが存在するかどうかをチェックします。関連するオペレーティング・システム・ユーザーおよびrootユーザーは、このグループのメンバーである必要があります。

詳細は、『Oracle ClusterwarおよびOracle Real Application Clustersインストレーションおよび構成ガイド』を参照してください。

3. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

4. 「次へ」をクリックします。

6. 「クラスタの構成」ページで、次を実行します。

1. 「クラスタの名前と場所」セクションでは、OracleクラスタウェアおよびOracle RACデータベースで指定されているデフォルト名とロケーション詳細を確認します。デフォルト値の保持をお薦めしますが、編集してカスタム値を指定することもできます。
セキュリティ上の目的のため、クラスタウェア構成により、Oracleクラスタウェア・ホームとその親ディレクトリがrootに所有されるよう設定されます。このため、OracleクラスタウェアはOracle RACホームのOracleベース外部にインストールすることをお薦めします。

ここに表示されるデフォルトのクラスタ名は、クラスタに管理エージェントをデプロイする際にCloud Controlでエージェント・デプロイ・アプリケーションに指定したホスト・クラスタ名に基づいています。ここに表示されるスクラッチ場所は、Oracle RACをプロビジョニングおよび構成する前に一時ファイルを置く、ターゲット・ホスト上の一時的な場所です。

「追加パラメータ」には、Oracleクラスタウェアをインストールする際に実行する追加パラメータを指定します。たとえば、-debugと指定します。

このプロビジョニング操作に使用できるOracle Universal Installer (OUI)パラメータはすべて指定可能です。このようなパラメータを使用して、データベースのインストール・タイプも変更できます。たとえば、INSTALL_TYPE=SEと指定します。パラメータは必ず空白で区切ります。

注意:

- 「クラスタ名」フィールドにデフォルトのクラスタ名が表示されない場合は、クラスタのマスター・ノードでないノードを選択している可能性があります。その場合、クラスタ名は手動で指定しますが、指定した名前が、クラスタ上での管理エージェントのデプロイの際にCloud Controlのエージェント・デプロイ・アプリケーションで指定したホスト・クラスタ名と同じであることを確認してください。

2. 「データベースの詳細」セクションでは、初期データベースの作成に使用するデフォルトの選択を保持します。

注意:
デプロイメント・プロシージャでデータベース作成ステップが無効化されている場合、このセクションは表示されません。

汎用データベースを作成する場合は、このセクションのフィールドをすべて空白のままにします。それ以外の場合は、このステップで説明する詳細を指定します。

オプションが有効化されているカスタム・レスポンス・ファイルがある場合は、「レスポンス・ファイルを使用してデータベースを作成してください」を選択し、そのファイルのある場所への完全パスを指定します。ファイルはターゲット・ホスト、ターゲット・ホストからアクセス可能な共有の場所、ソフトウェア・ライブラリまたは既存のデータベースが実行されている場所にあります。

注意:
ソフトウェア・ライブラリまたは既存のデータベースが実行されている場所から、.dbtテンプレート・ファイルを使用できます。ただし、ターゲット・ホストまたは共有の場所からは、すべてのテンプレート・ファイルを使用できます。

カスタム・レスポンス・ファイルがない場合は、「レスポンス・ファイルを使用しないでください」を選択し、グローバル・データベース名、資格証明、初期データベース作成時に実行する追加パラメータを指定します。

注意:
指定するデータベース名は、database_name.database_domainの形式にしてください。これには1から8までの英数字を使用します。たとえば、orcl.mydomain.comなどです。また、指定した資格証明は、SYS、SYSTEM、SYSMANおよびDBSNMPアカウントに使用されます。

既存のデータベースの構造を使用し、カスタム・テンプレートで新規データベースを構成する場合は、「データベースのテンプレート・ファイル」でテンプレート・ファイルを使用できる場所への完全パスを指定します。このファイルは、ターゲット・ホストまたはターゲット・ホストからアクセス可能な共有の場所にあります。

注意:
レスポンス・ファイルとテンプレートを一元的な場所に保存しない場合は、常にデプロイメント・プロシージャをカスタマイズし、データベース作成の構成ツールを起動する前に、レスポンス・ファイルまたはテンプレートをターゲット・ホストにコピーする別のステップを追加できます。

3. 「バックアップとリカバリの詳細」セクションでは、バックアップをとらない場合に「自動バックアップを使用しません」というデフォルトの選択を保持します。
一方、自動バックアップを有効にする場合は、「自動バックアップを使用します」を選択し、バックアップ・ファイルをリカバリするディレクトリの場所への完全パスを指定し、バックアップ・ジョブを実行するオペレーティング・システム資格証明を指定します。ファイルがバックアップされる場所とリカバリされる場所は同じであるため、リカバリ場所とバックアップ場所は同じになります。

4. 「ASMインスタンスの詳細」セクション(ASMのデプロイを選択した場合にのみ表示されます)では、「ASMインスタンスの作成」というデフォルトの選択を保持し、資格証明、使用する追加ASMパラメータ、およびASMディスク文字列を指定します。

重要:
Oracle Database 10gおよびOracle ASM 10gをプロビジョニングする場合は、ASMと同様に、データベースに同じパスワードを指定します。

カスタム・レスポンス・ファイルのオプションが有効化されている場合は、「レスポンス・ファイルを使用してASMデータベースを作成してください」を選択し、ファイルを使用できる場所への完全パスを指定します。このファイルは、ターゲット・ホストまたはターゲット・ホストからアクセス可能な共有の場所にあります。

レスポンス・ファイルを使用しない場合は、「レスポンス・ファイルを使用しないでください」を選択します。

5. 「次へ」をクリックします。

7. 「記憶域」ページで、次を実行します。

1. 「共有ストレージの構成」セクションで、ストレージ・デバイスの詳細を入力し、「次へ」をクリックします。パーティション名とマウント位置を指定し、マウント対象のフォーマットおよび、データを保存するストレージ・デバイスを選択します。パーティション名はデバイスをインストールする場所へのパスであり、マウント位置はパーティションの場所を表すマウント・ポイントです。
ストレージ・デバイスを構成する際には、少なくともOCR、投票ディスクおよびデータ・ファイルに使用するパーティションが必要です。複数のパーティションに同じストレージ・デバイスは指定できません。

OCRデバイスとOCRミラー・デバイスは別のパーティションに指定することをお薦めします。同様に、投票ディスク、投票ディスク1、投票ディスク2を異なるパーティションに指定することをお薦めします。

「次へ」をクリックする前に、次を実行してください。

- クラスタを作成および構成する前に、選択したRAWデバイスのデータをクリアする場合は、「RAWデバイスのクリア」を選択します。

- 少数のストレージ・デバイス用としてのみ構成してある場合は、プロビジョニングしないストレージ・デバイスに対して「ストレージをプロビジョニングしない」を選択します。

- 使用するASMディスク文字列を指定します。

2. 「オプション」セクションでASM冗長性モードを選択します。デフォルトは「なし」で、7 GBの容量が必要です。「標準」では16 GB、「高」では32 GBの容量が必要です。

8. (オプション)「拡張構成」ページで、次を実行します。

注意:
デプロイメント・プロシージャで構成ステップが無効化されている場合、このページは表示されません。

1. 「結合インタフェース(プライベート相互接続)」セクションでは、結合インタフェースを構成する場合に「結合インタフェースの構成」を選択します。インタフェースをバインドするには、表9-2で説明している詳細を指定します。

2. 「Sysctlファイル構成」セクションでは、sysctl.confファイルを構成する場合に「Sysctlの構成」を選択します。システム構成ファイルを編集するモード、およびカーネル・パラメータの編集に使用される参照システム構成ファイルの場所を指定します。
デフォルトのモードはappendです。ただし、変更する場合はedit、現在のsysctl.confファイルを置換する場合はreplaceを選択できます。

指定した参照ファイルは、Oracle Management Serviceからアクセス可能な共有場所で使用できる必要があります。

9. 「確認」ページで、Oracle RACをプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。入力した詳細がこのページにない場合、付録F「問題のトラブルシューティング」で説明している回避策を参照してください。

10. デプロイメント・プロシージャが正常に終了した後、構成情報を収集するようにデータベースをインストゥルメント化します。

9.4 Real Application Clusterのプロビジョニング

この項では、Oracle RACのゴールド・イメージをプロビジョニングする方法について説明します。

注意:
RACデータベースのOracleホームを使用して作成したゴールド・イメージを使用することを確認します。スタンドアロン・データベースのOracleホーム・ディレクトリを使用して作成したゴールド・イメージは使用できません。

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

- ゴールド・イメージを使用してOracle Real Application Clustersをプロビジョニングするための前提条件

- ゴールド・イメージを使用してOracle Real Application Clustersをプロビジョニングする手順

9.4.1 ゴールド・イメージを使用してOracle Real Application Clustersをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

設計者に対する前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- 既存のOracle RACデータベースおよびOracle Grid Infrastructureのゴールド・イメージを作成することを確認します。
ゴールド・イメージの作成方法を理解するには、第4.3項「データベース・プロビジョニングの設定」を参照してください。

- Oracle RACに必要なハードウェアおよびソフトウェアが、ターゲット・ホストに存在することを確認します。ハードウェア要件には、次の設定が含まれます。

- プライベート・ネットワーク: 各ノードにネットワーク・インタフェース・カードがインストールされており、互いに接続されている必要があります。

- ノード間の共有記憶域: 共有記憶域は、OCR、投票ディスクおよびデータファイルで必要です。

- 仮想IPがDNSで設定されていることを確認します。仮想IPをローカルに設定するように選択した場合は、デプロイメント・プロシージャを使用してIPアドレスを指定できます。この場合、プロシージャによって仮想IPが自動的に設定されます。

- カスタム・テンプレートを使用してデータベースの構造を作成するには、テンプレート(.dbtファイル)を作成し、ターゲット・ホストからアクセスできる場所にこれを格納します。このファイルは、ターゲット・ホストに格納することも共有場所に格納することもできます。
テンプレートが作成され、データベースの作成に使用される方法を理解するには、第4.3.8項「データベース・テンプレートの作成」を参照してください。

- oracleおよびcrsuserなどのオペレーティング・システム・ユーザーが、クラスタのすべてのノードで使用可能であることを確認します。これらのユーザーはdbaおよびoinstallなどの関連するオペレーティング・システム・グループの一部である必要があります。
詳細は、次で使用可能な『Oracle Clusterwareインストレーション・ガイド』を参照してください。

http://www.oracle.com/pls/db111/homepage

- オペレーティング・システム・ユーザーのユーザーIDとオペレーティング・システム・グループのグループIDが、クラスタのすべてのノードで同一であることを確認します。

オペレータに対する前提条件

- NISベースのオペレーティング・システム・ユーザーは使用しないでください。

- ターゲット・ホストでデプロイメント・プロシージャおよびそのコマンドを実行する権限を持つオペレーティング・システム・ユーザーを使用していることを確認します。これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。カスタマイズの詳細は、第51章を参照してください。

- ソースの選択時に、sqlnet.oraを「除外するファイル」に示されたファイルのリストから削除することを忘れないでください。

- ターゲット・ホストのumask値が022であることを確認します。

9.4.2 ゴールド・イメージを使用してOracle Real Application Clustersをプロビジョニングする手順

Oracle RACインストールのゴールド・イメージをプロビジョニングするには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. 「データベースのプロビジョニング」ページで次のうちのいずれかを選択し、「起動」をクリックします。

1. デプロイメント・プロシージャをUNIXプラットフォームで実行するには、「Oracleクラスタウェアのプロビジョニング / UNIXとRDBMSバージョン10g/11g用のRAC」を選択します。

2. デプロイメント・プロシージャをMicrosoft Windowsプラットフォームで実行するには、「Oracleクラスタウェアのプロビジョニング / WindowsとRDBMSバージョン10g/11g用のRAC」を選択します。

デプロイメント・プロシージャの「ソースの選択」ページが表示されます。

3. 「ソースの選択」ページで、次を実行します。

1. 「ソースの選択」セクションで、「ソフトウェア・ライブラリからの選択」を選択します。

2. 「クラスタウェアのソース」セクションで、懐中電灯アイコンをクリックし、Oracle Clusterwareのゴールド・イメージを含む汎用コンポーネントを選択します。「準備完了」のコンポーネントのみを選択してください。コンポーネント名を選択すると、コンポーネントの場所にアプリケーションが自動的に表示されます。

注意:
必要なコンポーネントがソフトウェア・ライブラリにない場合、付録Fで説明している回避策に従ってください。

3. 「RACのソース」セクションで、懐中電灯アイコンをクリックし、Oracle Databaseのゴールド・イメージを含む汎用コンポーネントを選択します。「準備完了」のコンポーネントのみを選択してください。コンポーネント名を選択すると、コンポーネントの場所にアプリケーションが自動的に表示されます。

注意:
必要なコンポーネントがソフトウェア・ライブラリにない場合、付録Fで説明している回避策に従ってください。

4. (オプション)「ASMのソース」セクションで、次のいずれかを実行します。
ASMをデプロイしない場合は、デフォルトで選択されている「ASMをプロビジョニングしない」を保持します。

Oracle RACと同じOracleホームにASMをデプロイする場合、RACホームと同じソースを使用を選択します。または、「コンポーネントの選択」を選択し、ソフトウェア・ライブラリからASMコンポーネントをアップロードします。

5. 「次へ」をクリックします。

4. 「ホストの選択」ページで、次を実行します。

1. 「クラスタに含めるホスト」セクションで、Addをクリックし、クラスタを形成するターゲット・ホストを選択します。選択したホストの詳細を表示するには、「オプションの表示」をクリックします。

注意:
「追加」をクリックすると、「ターゲットの選択」ポップアップ・ウィンドウが表示されます。このページでは、デフォルトで「適切なホストを表示」オプションが選択されており、プロビジョニングに最適なホストのみが表に示されています。追加するホストが見つからない場合、「すべてのホストを表示」を選択して、全部のホストのリストを表示します。

デフォルトでは、「プライベート・ホスト名」および「仮想ホスト名」に自動的に値が事前に入力されています。これらを編集し、環境に合った値を指定します。オプションで、IPアドレスを指定することもできます。

注意:
事前に入力された「プライベート・ホスト名」および「仮想ホスト名」のデフォルトの値が誤っている場合、付録Fで説明している回避策を参照してください。

これらの詳細をクラスタ構成ファイルに格納した場合、「ファイルからインポート」をクリックして、そのクラスタ構成ファイルを選択します。通常、このファイルには、追加される新しいホストの情報が含まれます。クラスタ構成ファイルの内容を理解するには、第9.5.2.1項に示すサンプル・ファイルを参照してください。

プライベートおよびパブリック・ネットワーク・インタフェースを構成するには、「インタフェースの選択」をクリックします。デフォルトでは、選択したターゲット・ホスト用の同じ名前とサブネットのあるインタフェースが表示されます。しかし、選択したターゲット・ホスト用のすべてのインタフェースを表示するように選択することもできます。既存のインタフェースのいずれかを選択することも、または使用したいインタフェースが存在しない場合は新しいインタフェースを指定することもできます。

2. 「ネットワーク・インタフェース構成」セクションで、プライベートおよびパブリック・インタフェースの詳細を確認します。

3. 「次へ」をクリックします。

5. 「資格証明/スケジュール」ページで、次の手順を実行します。

1. 「ターゲット・ホスト資格証明」セクションで、デフォルトの選択(「優先資格証明の使用」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

「ホスト資格証明」リストから、各Oracleホームごとに異なるオペレーティング・システム資格証明を使用する場合には「各Oracleホームごとに個別」を選択し、すべてのOracleホームで同じ資格証明を使用する場合には「すべてのOracleホームで同一」を選択します。選択に基づき、資格証明を指定します。ユーザーが同じグループ(dba/oinstall)に属していることを確認してください。

注意:
ベンダー・クラスタウェアを使用している場合、rootおよびオペレーティング・システム・ユーザー(クラスタウェアや様々なOracleホームを所有しているoracleやcrsuserなど)は、ベンダー・クラスタウェアによって規定されているオペレーティング・システム・グループに含まれている必要があります。
たとえば、High Availability Cluster Multiprocessing (HACMP)クラスタウェアをシステムで使用している場合、hagsuserというグループを作成するか、またはこのグループが存在するかどうかをチェックします。関連するオペレーティング・システム・ユーザーおよびrootユーザーは、このグループのメンバーである必要があります。

詳細は、『Oracle ClusterwarおよびOracle Real Application Clustersインストレーションおよび構成ガイド』を参照してください。

2. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

3. 「次へ」をクリックします。

6. 「クラスタの構成」ページで、次を実行します。

1. 「クラスタの名前と場所」セクションでは、OracleクラスタウェアおよびOracle RACデータベースで指定されているデフォルト名とロケーション詳細を確認します。デフォルト値の保持をお薦めしますが、編集してカスタム値を指定することもできます。
セキュリティ上の目的のため、クラスタウェア構成により、Oracleクラスタウェア・ホームとその親ディレクトリがrootに所有されるよう設定されます。このため、OracleクラスタウェアはOracle RACホームのOracleベース外部にインストールすることをお薦めします。

ここに表示されるデフォルトのクラスタ名は、クラスタに管理エージェントをデプロイする際にCloud Controlでエージェント・デプロイ・アプリケーションに指定したホスト・クラスタ名に基づいています。ここに表示されるスクラッチ場所は、Oracle RACをプロビジョニングおよび構成する前に一時ファイルを置く、ターゲット・ホスト上の一時的な場所です。

「追加パラメータ」には、Oracleクラスタウェアをインストールする際に実行する追加パラメータを指定します。たとえば、-debugと指定します。

このプロビジョニング操作に使用できるOracle Universal Installer (OUI)パラメータはすべて指定可能です。このようなパラメータを使用して、データベースのインストール・タイプも変更できます。たとえば、INSTALL_TYPE=SEと指定します。パラメータは必ず空白で区切ります。

2. 「データベースの詳細」セクションでは、初期データベースの作成に使用するデフォルトの選択を保持します。

注意:
デプロイメント・プロシージャでデータベース作成ステップが無効化されている場合、このセクションは表示されません。

汎用データベースを作成する場合は、このセクションのフィールドをすべて空白のままにします。それ以外の場合は、このステップで説明する詳細を指定します。

オプションが有効化されているカスタム・レスポンス・ファイルがある場合は、「レスポンス・ファイルを使用してデータベースを作成してください」を選択し、そのファイルのある場所への完全パスを指定します。ファイルはターゲット・ホスト、ターゲット・ホストからアクセス可能な共有の場所、ソフトウェア・ライブラリまたは既存のデータベースが実行されている場所にあります。

注意:
ソフトウェア・ライブラリまたは既存のデータベースが実行されている場所から、.dbtテンプレート・ファイルを使用できます。ただし、ターゲット・ホストまたは共有の場所からは、すべてのテンプレート・ファイルを使用できます。

カスタム・レスポンス・ファイルがない場合は、「レスポンス・ファイルを使用しないでください」を選択し、グローバル・データベース名、資格証明、初期データベース作成時に実行する追加パラメータを指定します。

注意:
指定するデータベース名は、database_name.database_domainの形式にしてください。これには1から8までの英数字を使用します。たとえば、orcl.mydomain.comなどです。また、指定した資格証明は、SYS、SYSTEM、SYSMANおよびDBSNMPアカウントに使用されます。

既存のデータベースの構造を使用し、カスタム・テンプレートで新規データベースを構成する場合は、「データベースのテンプレート・ファイル」でテンプレート・ファイルを使用できる場所への完全パスを指定します。このファイルは、ターゲット・ホストまたはターゲット・ホストからアクセス可能な共有の場所にあります。

注意:
レスポンス・ファイルとテンプレートを一元的な場所に保存しない場合は、常にデプロイメント・プロシージャをカスタマイズし、データベース作成の構成ツールを起動する前に、レスポンス・ファイルまたはテンプレートをターゲット・ホストにコピーする別のステップを追加できます。

3. 「バックアップとリカバリの詳細」セクションでは、バックアップをとらない場合に「自動バックアップを使用しません」というデフォルトの選択を保持します。
一方、自動バックアップを有効にする場合は、「自動バックアップを使用します」を選択し、バックアップ・ファイルをリカバリするディレクトリの場所への完全パスを指定し、バックアップ・ジョブを実行するオペレーティング・システム資格証明を指定します。ファイルがバックアップされる場所とリカバリされる場所は同じであるため、リカバリ場所とバックアップ場所は同じになります。

4. 「ASMインスタンスの詳細」セクション(ASMのデプロイを選択した場合にのみ表示されます)では、「ASMインスタンスの作成」というデフォルトの選択を保持し、資格証明、使用する追加ASMパラメータ、およびASMディスク文字列を指定します。

重要:
Oracle Database 10gおよびOracle ASM 10gをプロビジョニングする場合は、ASMと同様に、データベースに同じパスワードを指定します。

カスタム・レスポンス・ファイルのオプションが有効化されている場合は、「レスポンス・ファイルを使用してASMデータベースを作成してください」を選択し、ファイルを使用できる場所への完全パスを指定します。このファイルは、ターゲット・ホストまたはターゲット・ホストからアクセス可能な共有の場所にあります。

レスポンス・ファイルを使用しない場合は、「レスポンス・ファイルを使用しないでください」を選択します。

5. 「次へ」をクリックします。

7. 「記憶域」ページで、次を実行します。

1. 「共有ストレージの構成」セクションで、ストレージ・デバイスの詳細を入力し、「次へ」をクリックします。パーティション名とマウント位置を指定し、マウント対象のフォーマットおよび、データを保存するストレージ・デバイスを選択します。パーティション名はデバイスをインストールする場所へのパスであり、マウント位置はパーティションの場所を表すマウント・ポイントです。
ストレージ・デバイスを構成する際には、少なくともOCR、投票ディスクおよびデータ・ファイルに使用するパーティションが必要です。複数のパーティションに同じストレージ・デバイスは指定できません。

OCRデバイスとOCRミラー・デバイスは別のパーティションに指定することをお薦めします。同様に、投票ディスク、投票ディスク1、投票ディスク2を異なるパーティションに指定することをお薦めします。

「次へ」をクリックする前に、次を実行してください。

- クラスタを作成および構成する前に、選択したRAWデバイスのデータをクリアする場合は、「RAWデバイスのクリア」を選択します。

- 少数のストレージ・デバイス用としてのみ構成してある場合は、プロビジョニングしないストレージ・デバイスに対して「ストレージをプロビジョニングしない」を選択します。

- 使用するASMディスク文字列を指定します。

2. 「オプション」セクションでASM冗長性モードを選択します。デフォルトは「なし」で、7 GBの容量が必要です。「標準」では16 GB、「高」では32 GBの容量が必要です。

8. (オプション)「構成」ページで、次を実行します。

注意:
デプロイメント・プロシージャで構成ステップが無効化されている場合、このページは表示されません。

1. 「結合インタフェース(プライベート相互接続)」セクションでは、結合インタフェースを構成する場合に「結合インタフェースの構成」を選択します。インタフェースをバインドするには、表9-2で説明している詳細を指定します。

2. 「Sysctlファイル構成」セクションでは、sysctl.confファイルを構成する場合に「Sysctlの構成」を選択します。システム構成ファイルを編集するモード、およびカーネル・パラメータの編集に使用される参照システム構成ファイルの場所を指定します。
デフォルトのモードはappendです。ただし、変更する場合はedit、現在のsysctl.confファイルを置換する場合はreplaceを選択できます。

指定した参照ファイルは、Oracle Management Serviceからアクセス可能な共有場所で使用できる必要があります。

9. 「確認」ページで、Oracle RACをプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。入力した詳細がこのページにない場合、付録Fで説明している回避策を参照してください。

10. デプロイメント・プロシージャが正常に終了した後、構成情報を収集するようにデータベースをインストゥルメント化します。

9.5 アーカイブ・ソフトウェア・バイナリを使用したOracle Real Application Clusterのプロビジョニング

この項では、インストール・メディアで使用可能なものと同じOracle RACをプロビジョニングする方法について説明します。

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

- アーカイブ・ソフトウェア・バイナリを使用してOracle Real Application Clustersをプロビジョニングするための前提条件

- アーカイブ・ソフトウェア・バイナリを使用してOracle Real Application Clustersをプロビジョニングする手順

9.5.1 アーカイブ・ソフトウェア・バイナリを使用してOracle Real Application Clustersをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

設計者に対する前提条件

- 第9章で説明している前提条件を必ず満たしてください。

- 既存のOracle RACデータベースおよびOracle Grid Infrastructureのソフトウェア・バイナリをソフトウェア・ライブラリにアップロードすることを確認してください。

- Oracle RACに必要なハードウェアおよびソフトウェアが、ターゲット・ホストに存在することを確認します。ハードウェア要件には、次の設定が含まれます。

- プライベート・ネットワーク: 各ノードにネットワーク・インタフェース・カードがインストールされており、互いに接続されている必要があります。

- ノード間の共有記憶域: 共有記憶域は、OCR、投票ディスクおよびデータファイルで必要です。

- 仮想IPがDNSで設定されていることを確認します。仮想IPをローカルに設定するように選択した場合は、デプロイメント・プロシージャを使用してIPアドレスを指定できます。この場合、プロシージャによって仮想IPが自動的に設定されます。

- カスタム・テンプレートを使用してデータベースの構造を作成するには、テンプレート(.dbtファイル)を作成し、ターゲット・ホストからアクセスできる場所にこれを格納します。このファイルは、ターゲット・ホストに格納することも共有場所に格納することもできます。
どのようにテンプレートが作成され、データベースの作成に使用されるかを理解するには、第4.3.8項を参照してください。

- oracleおよびcrsuserなどのオペレーティング・システム・ユーザーが、クラスタのすべてのノードで使用可能であることを確認します。これらのユーザーはdbaおよびoinstallなどの関連するオペレーティング・システム・グループの一部である必要があります。
詳細は、次で使用可能な『Oracle Clusterwareインストレーション・ガイド』を参照してください。

http://www.oracle.com/pls/db111/homepage

- オペレーティング・システム・ユーザーのユーザーIDとオペレーティング・システム・グループのグループIDが、クラスタのすべてのノードで同一であることを確認します。

オペレータに対する前提条件

- NISベースのオペレーティング・システム・ユーザーは使用しないでください。

- ターゲット・ホストでデプロイメント・プロシージャおよびそのコマンドを実行する権限を持つオペレーティング・システム・ユーザーを使用していることを確認します。これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。カスタマイズの詳細は、第51章を参照してください。

- ターゲット・ホストのumask値が022であることを確認します。

9.5.2 アーカイブ・ソフトウェア・バイナリを使用してOracle Real Application Clustersをプロビジョニングする手順

新しいOracle RACインストールをプロビジョニングするには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. 「データベースのプロビジョニング」ページで次のうちのいずれかを選択し、「起動」をクリックします。

1. デプロイメント・プロシージャをUNIXプラットフォームで実行するには、「Oracleクラスタウェアのプロビジョニング / UNIXとRDBMSバージョン10g/11g用のRAC」を選択します。

2. デプロイメント・プロシージャをMicrosoft Windowsプラットフォームで実行するには、「Oracleクラスタウェアのプロビジョニング / WindowsとRDBMSバージョン10g/11g用のRAC」を選択します。

デプロイメント・プロシージャの「ソースの選択」ページが表示されます。

3. 「ソースの選択」ページで、次を実行します。

1. 「ソースの選択」セクションで、「ソフトウェア・ライブラリからの選択」を選択します。

2. 「クラスタウェアのソース」セクションで、懐中電灯アイコンをクリックし、Oracle Clusterwareのソフトウェア・バイナリを含む汎用コンポーネントを選択します。「準備完了」のコンポーネントのみを選択してください。コンポーネント名を選択すると、コンポーネントの場所にアプリケーションが自動的に表示されます。

注意:
必要なコンポーネントがソフトウェア・ライブラリにない場合、付録Fで説明している回避策に従ってください。

3. 「RACのソース」セクションで、懐中電灯アイコンをクリックし、Oracle Databaseのソフトウェア・バイナリを含む汎用コンポーネントを選択します。「準備完了」のコンポーネントのみを選択してください。コンポーネント名を選択すると、コンポーネントの場所にアプリケーションが自動的に表示されます。

注意:
必要なコンポーネントがソフトウェア・ライブラリにない場合、付録Fで説明している回避策に従ってください。

4. (オプション)「ASMのソース」セクションで、次のいずれかを実行します。
ASMをデプロイしない場合は、デフォルトで選択されている「ASMをプロビジョニングしない」を保持します。

Oracle RACと同じOracleホームにASMをデプロイする場合、RACホームと同じソースを使用を選択します。または、「コンポーネントの選択」を選択し、ソフトウェア・ライブラリからASMコンポーネントをアップロードします。

5. 「次へ」をクリックします。

4. 「ホストの選択」ページで、次を実行します。

1. 「クラスタに含めるホスト」セクションで、Addをクリックし、クラスタを形成するターゲット・ホストを選択します。選択したホストの詳細を表示するには、「オプションの表示」をクリックします。

注意:
「追加」をクリックすると、「ターゲットの選択」ポップアップ・ウィンドウが表示されます。このページでは、デフォルトで「適切なホストを表示」オプションが選択されており、プロビジョニングに最適なホストのみが表に示されています。追加するホストが見つからない場合、「すべてのホストを表示」を選択して、全部のホストのリストを表示します。

デフォルトでは、「プライベート・ホスト名」および「仮想ホスト名」に自動的に値が事前に入力されています。これらを編集し、環境に合った値を指定します。オプションで、IPアドレスを指定することもできます。

注意:
事前に入力された「プライベート・ホスト名」および「仮想ホスト名」のデフォルトの値が誤っている場合、付録Fで説明している回避策を参照してください。

これらの詳細をクラスタ構成ファイルに格納した場合、「ファイルからインポート」をクリックして、そのクラスタ構成ファイルを選択します。通常、このファイルには、追加される新しいホストの情報が含まれます。クラスタ構成ファイルの内容を理解するには、第9.5.2.1項に示すサンプル・ファイルを参照してください。

プライベートおよびパブリック・ネットワーク・インタフェースを構成するには、「インタフェースの選択」をクリックします。デフォルトでは、選択したターゲット・ホスト用の同じ名前とサブネットのあるインタフェースが表示されます。しかし、選択したターゲット・ホスト用のすべてのインタフェースを表示するように選択することもできます。既存のインタフェースのいずれかを選択することも、または使用したいインタフェースが存在しない場合は新しいインタフェースを指定することもできます。

2. 「ネットワーク・インタフェース構成」セクションで、プライベートおよびパブリック・インタフェースの詳細を確認します。

3. 「次へ」をクリックします。

5. 「資格証明/スケジュール」ページで、次の手順を実行します。

1. 「ターゲット・ホスト資格証明」セクションで、デフォルトの選択(「優先資格証明の使用」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

「ホスト資格証明」リストから、各Oracleホームごとに異なるオペレーティング・システム資格証明を使用する場合には「各Oracleホームごとに個別」を選択し、すべてのOracleホームで同じ資格証明を使用する場合には「すべてのOracleホームで同一」を選択します。選択に基づき、資格証明を指定します。ユーザーが同じグループ(dba/oinstall)に属していることを確認してください。

注意:
ベンダー・クラスタウェアを使用している場合、rootおよびオペレーティング・システム・ユーザー(クラスタウェアや様々なOracleホームを所有しているoracleやcrsuserなど)は、ベンダー・クラスタウェアによって規定されているオペレーティング・システム・グループに含まれている必要があります。
たとえば、High Availability Cluster Multiprocessing (HACMP)クラスタウェアをシステムで使用している場合、hagsuserというグループを作成するか、またはこのグループが存在するかどうかをチェックします。関連するオペレーティング・システム・ユーザーおよびrootユーザーは、このグループのメンバーである必要があります。

詳細は、『Oracle ClusterwarおよびOracle Real Application Clustersインストレーションおよび構成ガイド』を参照してください。

2. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

3. 「次へ」をクリックします。

6. 「クラスタの構成」ページで、次を実行します。

1. 「クラスタの名前と場所」セクションでは、OracleクラスタウェアおよびOracle RACデータベースで指定されているデフォルト名とロケーション詳細を確認します。デフォルト値の保持をお薦めしますが、編集してカスタム値を指定することもできます。
セキュリティ上の目的のため、クラスタウェア構成により、Oracleクラスタウェア・ホームとその親ディレクトリがrootに所有されるよう設定されます。このため、OracleクラスタウェアはOracle RACホームのOracleベース外部にインストールすることをお薦めします。

ここに表示されるデフォルトのクラスタ名は、クラスタに管理エージェントをデプロイする際にCloud Controlでエージェント・デプロイ・アプリケーションに指定したホスト・クラスタ名に基づいています。ここに表示されるスクラッチ場所は、Oracle RACをプロビジョニングおよび構成する前に一時ファイルを置く、ターゲット・ホスト上の一時的な場所です。

「追加パラメータ」には、Oracleクラスタウェアをインストールする際に実行する追加パラメータを指定します。たとえば、-debugと指定します。

このプロビジョニング操作に使用できるOracle Universal Installer (OUI)パラメータはすべて指定可能です。このようなパラメータを使用して、データベースのインストール・タイプも変更できます。たとえば、INSTALL_TYPE=SEと指定します。パラメータは必ず空白で区切ります。

2. 「データベースの詳細」セクションでは、初期データベースの作成に使用するデフォルトの選択を保持します。

注意:
デプロイメント・プロシージャでデータベース作成ステップが無効化されている場合、このセクションは表示されません。

汎用データベースを作成する場合は、このセクションのフィールドをすべて空白のままにします。それ以外の場合は、このステップで説明する詳細を指定します。

オプションが有効化されているカスタム・レスポンス・ファイルがある場合は、「レスポンス・ファイルを使用してデータベースを作成してください」を選択し、そのファイルのある場所への完全パスを指定します。ファイルはターゲット・ホスト、ターゲット・ホストからアクセス可能な共有の場所、ソフトウェア・ライブラリまたは既存のデータベースが実行されている場所にあります。

注意:
ソフトウェア・ライブラリまたは既存のデータベースが実行されている場所から、.dbtテンプレート・ファイルを使用できます。ただし、ターゲット・ホストまたは共有の場所からは、すべてのテンプレート・ファイルを使用できます。

カスタム・レスポンス・ファイルがない場合は、「レスポンス・ファイルを使用しないでください」を選択し、グローバル・データベース名、資格証明、初期データベース作成時に実行する追加パラメータを指定します。

注意:
指定するデータベース名は、database_name.database_domainの形式にしてください。これには1から8までの英数字を使用します。たとえば、orcl.mydomain.comなどです。また、指定した資格証明は、SYS、SYSTEM、SYSMANおよびDBSNMPアカウントに使用されます。

既存のデータベースの構造を使用し、カスタム・テンプレートで新規データベースを構成する場合は、「データベースのテンプレート・ファイル」でテンプレート・ファイルを使用できる場所への完全パスを指定します。このファイルは、ターゲット・ホストまたはターゲット・ホストからアクセス可能な共有の場所にあります。

注意:
レスポンス・ファイルとテンプレートを一元的な場所に保存しない場合は、常にデプロイメント・プロシージャをカスタマイズし、データベース作成の構成ツールを起動する前に、レスポンス・ファイルまたはテンプレートをターゲット・ホストにコピーする別のステップを追加できます。

3. 「バックアップとリカバリの詳細」セクションでは、バックアップをとらない場合に「自動バックアップを使用しません」というデフォルトの選択を保持します。
一方、自動バックアップを有効にする場合は、「自動バックアップを使用します」を選択し、バックアップ・ファイルをリカバリするディレクトリの場所への完全パスを指定し、バックアップ・ジョブを実行するオペレーティング・システム資格証明を指定します。ファイルがバックアップされる場所とリカバリされる場所は同じであるため、リカバリ場所とバックアップ場所は同じになります。

4. 「ASMインスタンスの詳細」セクション(ASMのデプロイを選択した場合にのみ表示されます)では、「ASMインスタンスの作成」というデフォルトの選択を保持し、資格証明、使用する追加ASMパラメータ、およびASMディスク文字列を指定します。

重要:
Oracle Database 10gおよびOracle ASM 10gをプロビジョニングする場合は、ASMと同様に、データベースに同じパスワードを指定します。

カスタム・レスポンス・ファイルのオプションが有効化されている場合は、「レスポンス・ファイルを使用してASMデータベースを作成してください」を選択し、ファイルを使用できる場所への完全パスを指定します。このファイルは、ターゲット・ホストまたはターゲット・ホストからアクセス可能な共有の場所にあります。

レスポンス・ファイルを使用しない場合は、「レスポンス・ファイルを使用しないでください」を選択します。

5. 「次へ」をクリックします。

7. 「記憶域」ページで、次を実行します。

1. 「共有ストレージの構成」セクションで、ストレージ・デバイスの詳細を入力し、「次へ」をクリックします。パーティション名とマウント位置を指定し、マウント対象のフォーマットおよび、データを保存するストレージ・デバイスを選択します。パーティション名はデバイスをインストールする場所へのパスであり、マウント位置はパーティションの場所を表すマウント・ポイントです。
ストレージ・デバイスを構成する際には、少なくともOCR、投票ディスクおよびデータ・ファイルに使用するパーティションが必要です。複数のパーティションに同じストレージ・デバイスは指定できません。

OCRデバイスとOCRミラー・デバイスは別のパーティションに指定することをお薦めします。同様に、投票ディスク、投票ディスク1、投票ディスク2を異なるパーティションに指定することをお薦めします。

「次へ」をクリックする前に、次を実行してください。

- クラスタを作成および構成する前に、選択したRAWデバイスのデータをクリアする場合は、「RAWデバイスのクリア」を選択します。

- 少数のストレージ・デバイス用としてのみ構成してある場合は、プロビジョニングしないストレージ・デバイスに対して「ストレージをプロビジョニングしない」を選択します。

- 使用するASMディスク文字列を指定します。

2. 「オプション」セクションでASM冗長性モードを選択します。デフォルトは「なし」で、7 GBの容量が必要です。「標準」では16 GB、「高」では32 GBの容量が必要です。

8. (オプション)「構成」ページで、次を実行します。

注意:
デプロイメント・プロシージャで構成ステップが無効化されている場合、このページは表示されません。

1. 「結合インタフェース(プライベート相互接続)」セクションでは、結合インタフェースを構成する場合に「結合インタフェースの構成」を選択します。インタフェースをバインドするには、表9-2で説明している詳細を指定します。

2. 「Sysctlファイル構成」セクションでは、sysctl.confファイルを構成する場合に「Sysctlの構成」を選択します。システム構成ファイルを編集するモード、およびカーネル・パラメータの編集に使用される参照システム構成ファイルの場所を指定します。
デフォルトのモードはappendです。ただし、変更する場合はedit、現在のsysctl.confファイルを置換する場合はreplaceを選択できます。

指定した参照ファイルは、Oracle Management Serviceからアクセス可能な共有場所で使用できる必要があります。

9. 「確認」ページで、Oracle RACをプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。入力した詳細がこのページにない場合、付録F「問題のトラブルシューティング」で説明している回避策を参照してください。

10. デプロイメント・プロシージャが正常に終了した後、構成情報を収集するようにデータベースをインストゥルメント化します。

表9-2 「構成」ページ - 「要素の説明」

要素

説明

結合デバイス名

作成する結合名を指定します。たとえば、bond0などです。

サブネット・マスク

IPアドレスのサブネット・マスクを指定します。たとえば、255.255.255.0などです。

デフォルトのゲートウェイ

結合デバイスのデフォルト・ゲートウェイを指定します。たとえば、10.1.2.3などです。

DNSサーバー

結合デバイスのドメイン・ネーム・サーバー(DNS)のリストを指定します。DNSサーバーが複数ある場合は、値をカンマで区切る必要があります。デフォルト値は、/etc/resolv.confファイルから取得されます。ここで指定するエントリが追加されます。

スレーブ・デバイス・リスト

結合デバイスのスレーブ・デバイスのリストを指定します。複数のスレーブ・デバイスの場合、値をカンマで区切る必要があります。たとえば、eth1,eth2,eth3などです。

結合モード

結合モジュールに適用可能な4つのポリシーの1つを指定します。このパラメータに使用可能な値は、次のとおりです。

- 0 (Balance-rr): フォルト・トレランスおよびロード・バランシングにラウンドロビン・ポリシーが設定されます。信号が受信され、各結合スレーブ・インタフェースで最初に使用可能になったものから順次送信されます。

- 1 (Active-backup): フォルト・トレランスにアクティブ・バックアップ・ポリシーが設定されます。信号が受信され、最初に使用可能になった結合スレーブ・インタフェースを介して送信されます。別の結合スレーブ・インタフェースは、アクティブな結合スレーブ・インタフェースが停止した場合にのみ使用されます。

- 2 (Balance-xor): フォルト・トレランスおよびロード・バランシングにXOR (exclusive-or)ポリシーが設定されます。この方法を使用すると、インタフェースにより、受信リクエストのMACアドレスとスレーブNICのいずれかのMACアドレスが組み合されます。このリンクが確立されると、信号は最初に使用可能になったインタフェースから順次送信されます。

- 3 (Broadcast): フォルト・トレランスおよびロード・バランシングにラウンドロビン・ポリシーが設定されます。各結合スレーブ・インタフェースで最初に使用可能になったものから順次信号が送信されます。

ドメイン名

割り当てられたホスト名のドメイン名を指定します。たとえば、foo.comなどです。

プライマリ・スレーブ・デバイス

プライマリ・デバイスのインタフェース名(eth0など)を指定します。プライマリ・デバイスは最初に使用される結合インタフェースで、停止するまで中止されません。この設定は、結合インタフェースの1つのNICが他より高速で、処理できる負荷の量が大きい場合に特に便利です。この設定は、結合インタフェースがアクティブ・バックアップ・モードの場合にのみ有効です。

ARP間隔

ARP監視を実行する頻度を指定します(ミリ秒単位)。モードが0または2 (2つのロード・バランシング・モード)の際にこの設定を使用する場合には、NIC全体に均一にパケットを配布するためにネットワーク・スイッチを構成する必要があります。値はデフォルトで、これを無効化する0に設定されています。

MII間隔

MIIリンクの監視を実行する頻度を指定します(ミリ秒単位)。MIIを使用して、NICがアクティブであることおよび特定のNIC用のドライバでMIIツールがサポートされていることを検証するために高可用性が要求される場合に便利です。高可用性を実現するために結合インタフェースを使用している場合には、各NICのモジュールでMIIをサポートする必要があります。値を0 (デフォルト)に設定すると、この機能は無効化されます。この設定を構成する場合、このパラメータを100に設定することをお薦めします。

MII間隔ダウン遅延

リンク障害後にリンクを無効化するまでに待機する期間を指定します(ミリ秒単位)。値は、miimonパラメータで指定した値の倍数である必要があります。値はデフォルトで、これを無効化する0に設定されています。

MII間隔アップ遅延

リンクを有効化するまでに待機する期間を指定します(ミリ秒単位)。値は、miimonパラメータで指定した値の倍数である必要があります。値はデフォルトで、これを無効化する0に設定されています。

NTPサーバー

割り当てられたホスト名のNTPサーバーを指定します。たとえば、1.2.3.4などです。

9.5.2.1 サンプルのクラスタ構成ファイル

一般的なクラスタ構成ファイルの内容は次のとおりです。

# Cluster Configuration file

# Node information

# Public Node Name

Private Node Name

Private IP (Optional)

Virtual Host Name

Virtual IP (Optional)

node1.domain.com

node1-priv.domain.com

-

node1-vip.domain.com

-

node2.domain.com

node2-priv.domain.com

10.2.109.103

node2-vip.domain.com

134.2.109.103

9.6 Oracle Real Application Clusters (Oracle RAC)データベースのプロビジョニングでの非root資格証明の使用

Oracle RACデータベースのプロビジョニングでは、非root資格証明がサポートされています。この機能を使用するには、次の手順を実行します。

1. 「OSユーザーの指定」ページで、「優先資格証明の上書き」を指定します。表示された「OSユーザーの指定」ダイアログ・ボックスで、通常の名前の資格証明を作成して、「実行権限」を「なし」に設定します。「OK」をクリックします。

2. 通常ユーザーと特権ユーザーの両方に対して、通常の名前の新しい資格証明を選択します。

3. 「送信」をクリックします。
データベースのプロビジョニング・プロセスがroot資格証明を必要とするステップに到達したら、プロセスが停止します。この場合、コマンドラインを手動で実行する必要があります。これを実行するには、環境を$AGENT_HOME,に設定し、次の3つのステップで「方法」フィールドからコマンドラインのコピーを実行します。

- 修正の手動による実行

- rootスクリプトの手動による実行(CRSインストール・フェーズ時)

- rootスクリプトの手動による実行(RACデータベースのインストール・フェーズ時)

4. 各ステップでrootユーザーを使用してコマンドラインを手動で実行したら、「確認」をクリックします。これで、データベースのプロビジョニング・プロセスが、完了するまで続行されます。

10 Oracle Real Application Clustersの拡張

この章では、Oracle Enterprise Manager Cloud Control(Cloud Control)を使用して、シングル・クリックで、既存のOracle RACスタック(Oracle Clusterware、Oracle ASM、Oracle RACデータベース)を拡張およびスケールアップする方法について説明します。この章の具体的な内容は次のとおりです。

- Oracle Real Application Clustersの拡張の概要

- Oracle Real Application Clustersの拡張

10.1 Oracle Real Application Clustersの拡張の概要

この項では、この章に取り組むための手引きとして、既存のOracle RACスタックの拡張の手順の概要を説明します。この項は、Oracle RACの拡張を成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表10-1 Oracle RACの拡張の概要

ステップ

説明

参照リンク

手順1

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

Oracle RACの拡張の前提条件の詳細は、第10.2.1項を参照してください。

手順2

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行して既存のOracle RACを正常に拡張します。

Oracle RACを拡張するには、第10.2.2項で説明する手順に従います。

10.2 Oracle Real Application Clustersの拡張

この項では、ワンクリックで、必要な数の追加ノードを含むように既存のOracle RACを拡張する方法について説明します。

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

- Oracle Real Application Clustersを拡張するための前提条件

- Oracle Real Application Clustersを拡張する手順

10.2.1 Oracle Real Application Clustersを拡張するための前提条件

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

設計者に対する前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- oinstallおよびdbaグループを使用可能にしておく必要があります。

- oracleおよびcrsuserなどのオペレーティング・システム・ユーザーが、クラスタのすべてのノードで使用可能であることを確認します。これらのユーザーはdbaおよびoinstallなどの関連するオペレーティング・システム・グループの一部である必要があります。

- この操作を実行するためにグループIDと一緒に使用される資格証明は、選択したクラスタのすべてのノードで同じであることが必要です。

オペレータに対する前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

- 既存のクラスタ・ノードで使用されている共有記憶域に、追加するノードからアクセスできることを確認します。

- ターゲット・ホストのumask値が022であることを確認します。確認するには、次のコマンドを実行します。
$ umask

使用しているシェルにより、この値は/etc/profile、/etc/bashrcまたは/etc/csh.cshrcで確認することもできます。

10.2.2 Oracle Real Application Clustersを拡張する手順

既存のOracle RACを拡張するには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. 「データベースのプロビジョニング」ページでOracle Real Application Clustersの拡張を選択し、「起動」をクリックします。
「Real Application Clustersの拡張」ページが表示されます。

3. 「Real Application Clustersの拡張」ページで、次を実行します。

1. Real Application Clusters (RAC)の選択セクションで、拡張するOracle RACを選択します。関連するクラスタウェアと自動ストレージ管理(ASM)もまた、すでに存在しない場合には拡張されます。
「検索」セクションを使用して、特定のOracle RACについて検索することもできます。「検索」リストから、検索のベースとなるターゲット・タイプを選択し、「実行」をクリックします。%や*などのワイルドカードを使用できます。

注意:
拡張するクラスタ・データベースがこのページに表示されない場合は、次を実行します。

- Cloud Controlでクラスタ・ターゲットのクラスタウェア・ホームの場所を指定します。Grid Controlで、「ターゲット」メニューをクリックして、「すべてのターゲット」をクリックします。「すべてのターゲット」ページの「検索」リストで、「クラスタ」を選択し「実行」をクリックします。結果表から、クラスタウェア・ホームの場所を指定するクラスタを選択します。「クラスタ・ホーム」ページで、「監視構成」をクリックします。「ターゲットの構成」ページで、クラスタウェア・ホームの場所を指定して、「更新」をクリックします。

- Cloud Control設定を構成して表示します。Cloud Controlで、「デプロイメント」ページの「デプロイメント」タブをクリックして、「ホスト構成のリフレッシュ」をクリックします。次のページの「使用可能なホスト」ペインからホストを選択し、それらを「選択したホスト」ペインに追加します。次に、「ホストのリフレッシュ」をクリックして、ジョブが成功するのを待機します。この「デプロイメント・プロシージャ」ページに戻り、検索問合せを再度実行し、検索結果のホストを表示します。

2. 「参照ホスト・オプション」セクションで、「参照ホスト」リストから、この操作を実行するプライマリ・ホストとして使用するホストを選択します。参照ホストとは、クローン・アーカイブの作成用に選択されて、追加される新規ターゲット・ノードに転送されるホストのことです。
「作業ディレクトリ」には、クローニング用のステージング・ファイルに使用できる選択したホスト上の既存のディレクトリへのフルパスを指定します。指定したディレクトリがターゲット・ホストに存在しない場合、デプロイメント・プロシージャにより作成されます。作業ディレクトリがノード上で共有されていないことを確認してください。

各Oracleホームの「除外するファイル」には、この操作の実行中に除外するファイルを指定します。ここで指定した正規表現に対応するファイルまたはフォルダが除外されることに注意してください。

3. 「Oracleホーム共有記憶域オプション」セクションでは、共有記憶域にあるOracleホームの場所を選択します。

4. 「新規ノードの選択」セクションで、「追加」をクリックし、選択したOracle RACに含める新しいノードを追加します。ノードの追加後、新しいノードそれぞれに仮想ノード名を指定し、その値がデフォルトで表示されることを確認します。

注意:
Oracle Management Agents 12cリリース1 (12.1.0.1)以降により監視される対象のノードを選択していることを確認します。

オプションで、「オプションの表示」をクリックして、「プライベート・ノード名」、「プライベートIP」、「仮想IP」および「作業ディレクトリ」を指定できます。「プライベート・ノード名」および「プライベートIP」が必要なのは、プライベート・ネットワークをプロシージャの一環として設定する場合のみです。「仮想ノード名」および「仮想IP」が必要なのは、ノードが固定されていてDHCPベースではない場合のみです。ノードがすでにOracle RACシステムの一部である場合、これは無視されます。ノードがすでにOracle Clusterwareの一部である場合、プライベート・ネットワークおよび仮想ホスト情報は無視されます。「作業ディレクトリ」について、指定する場所はノード上で共有されていないことを確認してください。

これらの詳細をクラスタ構成ファイルに格納した場合、「ファイルからインポート」をクリックして、そのクラスタ構成ファイルを選択します。通常、このファイルには、追加される新しいノードの情報が含まれます。また、Oracle RACが拡張される、プライベート・ノード名、プライベートIPアドレス、仮想ホスト名および仮想IPアドレスに関する情報を含めることも可能です。

5. 「ユーザー資格証明(優先資格証明の上書き)」セクションで、デフォルトの選択(「優先資格証明の使用」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。たとえば、ユーザーがAおよびBである2つの宛先ホストを追加した場合、それぞれのホストに対して異なる資格証明で優先資格証明を上書きする選択ができます。同様に、宛先ホストに同じ資格証明があり、それが優先資格証明とは異なる場合、すべてのホストに対して同一の資格証明で優先資格証明を上書きできます。
ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

「ホスト資格証明」リストから、各Oracleホームごとに異なるオペレーティング・システム資格証明を使用する場合には「各Oracleホームごとに個別」を選択し、すべてのOracleホームで同じ資格証明を使用する場合には「すべてのOracleホームで同一」を選択します。選択に基づき、資格証明を指定します。ユーザーが同じグループ(dba/oinstall)に属していることを確認してください。

注意:
ベンダー・クラスタウェアを使用している場合、rootおよびオペレーティング・システム・ユーザー(クラスタウェアや様々なOracleホームを所有しているoracleやcrsuserなど)は、ベンダー・クラスタウェアによって規定されているオペレーティング・システム・グループに含まれている必要があります。
たとえば、High Availability Cluster Multiprocessing (HACMP)クラスタウェアをシステムで使用している場合、hagsuserというグループを作成するか、またはこのグループが存在するかどうかをチェックします。関連するオペレーティング・システム・ユーザーおよびrootユーザーは、このグループのメンバーである必要があります。

詳細は、『Oracle ClusterwarおよびOracle Real Application Clustersインストレーションおよび構成ガイド』を参照してください。

6. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

7. 「前提条件(前提条件および修正の実行)」セクションでは、デフォルトでは「前提条件および修正のスキップ」は選択されていません。このため、デプロイメント・プロシージャは、選択されたノードで前提条件チェックと修正を実行します。
この操作のすべての要件を満たし、クラスタに追加する準備ができていることを確認するには、前提条件チェックが必要です。オプションは、選択されたノードで事前に前提条件チェックが実行されていないことを想定して選択されていません。

選択されたノードで前提条件チェックをすでに実行しており、デプロイメント・プロシージャでそれらの再実行をスキップする場合は、「前提条件および修正のスキップ」を選択します。

選択したノードで前提条件チェックを実行せず、デプロイメント・プロシージャでそれらを実行する場合は、「前提条件および修正のスキップ」を選択解除します。デプロイメント・プロシージャは前提条件チェックを実行し、問題があれば解決してから、拡張クラスタ操作に進みます。

前提条件のみチェックし、この時点で操作には進まない場合は、「前提条件チェックのみ実行」をクリックします。

8. 「確認」をクリックします。

4. 「確認」ページで、Oracle RACを拡張するために指定した詳細を確認し、「発行」をクリックします。

注意:
デプロイメント・プロシージャが失敗した場合、第F.7項で説明されているログ・ファイルを確認します。

注意:
Linux Itanium x64でデプロイメント・プロシージャを実行するときに「共有場所の検証用CVUの実行」ステップが失敗した場合、次のステップに進む前に、手動で修正してください。このプラットフォームでは自動修正は使用できません。

11 Oracle Real Application Clustersの削除またはスケール・ダウン

この章では、Oracle Real Application Clusters (Oracle RAC)を削除またはスケール・ダウンする方法について説明します。この章の具体的な内容は次のとおりです。

- Oracle Real Application Clustersの削除またはスケール・ダウンの概要

- Oracle Real Application Clustersのコア・コンポーネントの削除

- Oracle RAC全体の削除

- Oracle RACの一部のノードの削除によるスケール・ダウン

11.1 Oracle Real Application Clustersの削除またはスケール・ダウンの概要

この項では、この章に取り組むための手引きとして、既存のOracle RACスタックの削除またはスケール・ダウンの手順の概要を説明します。この項は、Oracle RACスタックの削除またはスケール・ダウンを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表11-1 既存のOracle RACの削除またはスケール・ダウンの概要

ステップ

説明

参照リンク

ステップ1

ユースケースの選択

ここでは、既存のOracle RACの削除およびスケール・ダウンのユースケースのいくつかを説明します。ご自身の要件に最適なユースケースを選択してください。

- Oracle RACスタック全体の削除の詳細は、第11.3項「Oracle RAC全体の削除」を参照してください。

- 所有する1つまたは複数のノードの削除による既存のOracle RACスタックのスケール・ダウンの詳細は、第11.4項「Oracle RACの一部のノードの削除によるスケール・ダウン」を参照してください。

ステップ2

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

- Oracle RACスタック全体を削除するための前提条件の詳細は、11.3.1項「Oracle RAC全体を削除するための前提条件」を参照してください。

- 所有する1つ以上のノードを削除して既存のOracle RACスタックをスケール・ダウンするための前提条件の詳細は、11.4.1項「ノードの一部を削除してOracle RACをスケール・ダウンするための前提条件」を参照してください。

ステップ3

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行して既存のOracle RACを正常に削除またはスケール・ダウンします。

- Oracle RACスタック全体を削除するには、11.3.2項「Oracle RAC全体を削除する手順」で説明する手順を実行します。

- 所有する1つ以上のノードを削除して既存のOracle RACスタックをスケール・ダウンするには、11.4.2項「ノードの一部を削除してOracle RACをスケール・ダウンする手順」で説明する手順に従います。

11.2 Oracle Real Application Clustersのコア・コンポーネントの削除

Oracle Real Application Clustersの削除およびスケール・ダウンのデプロイメント・プロシージャを使用して、既存のOracle RACのノードまたはOracle RAC全体を削除できます。結果として、デプロイメント・プロシージャにより、Oracle Clusterware、リスナー、および削除対象として選択されたノードと関連付けられたOracle RACおよびASMホームが削除されます。

このデプロイメント・プロシージャでは、シングル・クリックで、クラスタ・データベース・スタック全体(Oracle Clusterware、Oracle ASMおよびOracle RACデータベース)をスケール・ダウンすることも、Oracle RACクラスタの1つまたは複数のノードをスケール・ダウンすることもできます。これには、様々なプラットフォーム間で、第4.2項で説明されているような様々なリリースのクラスタ・データベースが含まれます。

このプロシージャは次のものを含むクラスタをスケール・ダウンまたは削除できます。

- Oracle CRS、Oracle ASMおよび同じまたは異なるユーザーが所有するOracle Databaseホーム。

- Oracle CRS、Oracle ASMおよびすべてのメンバー・ノードで共有される共有ストレージに存在するOracle Databaseホーム。

- 部分的にプロビジョニングされたかまたはインストールに失敗したOracle RACクラスタ(インストールされた1つまたは複数のスタックの層が含まれる可能性があります。たとえば、クラスタウェアのインストールが失敗した後のクリーンアップまたはクラスタウェアが部分的にのみプロビジョニングされた場合のクリーンアップ)。

- 再イメージ化または停止されたノード、およびCloud Controlでこのノードへのすべての参照を削除するために解決する必要のある既存の構成。

11.3 Oracle RAC全体の削除

この項では、Oracle RAC全体を削除する方法について説明します。この項の具体的な内容は次のとおりです。

- Oracle RAC全体を削除するための前提条件

- Oracle RAC全体を削除する手順

11.3.1 Oracle RAC全体を削除するための前提条件

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

設計者に対する前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- oinstallおよびdbaグループを使用可能にしておく必要があります。

- oracleおよびcrsuserなどのオペレーティング・システム・ユーザーが、クラスタのすべてのノードで使用可能であることを確認します。これらのユーザーはdbaおよびoinstallなどの関連するオペレーティング・システム・グループの一部である必要があります。

- この操作を実行するためにグループIDと一緒に使用される資格証明は、選択したクラスタのすべてのノードで同じであることが必要です。

オペレータに対する前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

- REMOVE_ANY_TARGET Enterprise Manager権限

11.3.2 Oracle RAC全体を削除する手順

Oracle RAC全体を削除するには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. 「データベースのプロビジョニング」ページで「Oracle Real Application Clustersの削除/縮小」を選択し、「起動」をクリックします。
「Oracle Real Application Clustersの削除/縮小」ページが表示されます。

3. 「Oracle Real Application Clustersの削除/縮小」ページで、次を実行します。

1. 「クラスタの選択」ページで、「クラスタの選択」のための懐中電灯アイコンをクリックし、削除するOracle Clusterwareインスタンスを選択します。選択したOracle Clusterwareとともに、関連付けられているOracle RACおよびASMインスタンスも削除されます。選択したOracle Clusterwareの一部であるメンバー・ノードについての詳細が表に表示されます。

注意:

懐中電灯アイコンを使用してOracle Clusterwareを選択するときに、探しているOracle Clusterwareが見つからない場合、表の下に示されるヒントから「ここ」をクリックして、クラスタウェアの詳細を手動で指定して検索します。

これは、部分的にプロビジョニングされた、または構成されたOracle Clusterwareインスタンスを削除する場合に特に有用です。デフォルトでは、懐中電灯アイコンのクリックでは、完全にプロビジョニングされたクラスタウェア・インスタンスのみが選択用に表示されるからです。この場合、部分的にプロビジョニングされたインスタンスを検索、選択、および削除するには、「ここ」をクリックし、「クラスタ詳細を入力」ウィンドウで、部分的にプロビジョニングされたインスタンスを含むクラスタ・ノードに関する詳細を指定して「OK」をクリックします。次に「削除するノードの選択」セクションに表示されるホストを選択し、削除対象としてマークすることができます。

2. 「参照ホスト・オプション」セクションで、「クラスタ・ノード」リストから、すべてのクリーンアップ操作を実行するプライマリ・ノードとして使用するノードを選択します。
「作業ディレクトリ」には、一時的にステージング・ファイルに使用できる選択したノード上の既存のディレクトリへのフルパスを指定します。

3. 「削除するノードの選択」セクションで、「すべてマーク」をクリックし、削除するすべてのノードを選択します。「すべてマーク」をクリックすると、すべてのノードの「削除」列に十字アイコンが表示されます。これらの十字アイコンは、ノードが削除対象として選択されていることを示します。

4. 「ユーザー資格証明(優先資格証明の上書き)」セクションで、デフォルトの選択(「優先資格証明の使用」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。たとえば、ユーザーがAおよびBである2つの宛先ホストを追加した場合、それぞれのホストに対して異なる資格証明で優先資格証明を上書きする選択ができます。同様に、宛先ホストに同じ資格証明があり、それが優先資格証明とは異なる場合、すべてのホストに対して同一の資格証明で優先資格証明を上書きできます。
たとえば、ユーザーがAおよびBである2つの宛先ホストを追加した場合、それぞれのホストに対して異なる資格証明で優先資格証明を上書きする選択ができます。同様に、宛先ホストに同じ資格証明があり、それが優先資格証明とは異なる場合、すべてのホストに対して同一の資格証明で優先資格証明を上書きできます。

ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

「ホスト資格証明」リストから、各Oracleホームごとに異なるオペレーティング・システム資格証明を使用する場合には「各Oracleホームごとに個別」を選択し、すべてのOracleホームで同じ資格証明を使用する場合には「すべてのOracleホームで同一」を選択します。選択に基づき、資格証明を指定します。ユーザーが同じグループ(dba/oinstall)に属していることを確認してください。

5. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

6. 「確認」をクリックします。

4. 「確認」ページで、Oracle RACを削除するために指定した詳細を確認し、「発行」をクリックします。

注意:
デプロイメント・プロシージャが失敗した場合、第F.7項で説明されているログ・ファイルを確認します。

11.4 Oracle RACの一部のノードの削除によるスケール・ダウン

この項では、Oracle RACを、その一部である1つまたは複数のノードと、その一部ではあるがCloud Controlでターゲットとして表示されないその他のノードを削除することでスケール・ダウンする方法について説明します。この項の具体的な内容は次のとおりです。

- ノードの一部を削除してOracle RACをスケール・ダウンするための前提条件

- ノードの一部を削除してOracle RACをスケール・ダウンする手順

11.4.1 ノードの一部を削除してOracle RACをスケール・ダウンするための前提条件

設計者に対する前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- oinstallおよびdbaグループを使用可能にしておく必要があります。

- oracleおよびcrsuserなどのオペレーティング・システム・ユーザーが、クラスタのすべてのノードで使用可能であることを確認します。これらのユーザーはdbaおよびoinstallなどの関連するオペレーティング・システム・グループの一部である必要があります。

- この操作を実行するためにグループIDと一緒に使用される資格証明は、選択したクラスタのすべてのノードで同じであることが必要です。

オペレータに対する前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

11.4.2 ノードの一部を削除してOracle RACをスケール・ダウンする手順

Oracle RACをその一部である1つまたは複数のノードの削除によりスケール・ダウンするには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. 「データベースのプロビジョニング」ページで「Oracle Real Application Clustersの削除/縮小」を選択し、「起動」をクリックします。
「Oracle Real Application Clustersの削除/縮小」ページが表示されます。

3. 「Oracle Real Application Clustersの削除/縮小」ページで、次を実行します。

1. 「クラスタの選択」ページで、「クラスタの選択」のための懐中電灯アイコンをクリックし、スケール・ダウンするOracle Clusterwareインスタンスを選択します。選択したOracle Clusterwareとともに、関連付けられているOracle RACおよびASMインスタンスも削除されます。選択したOracle Clusterwareの一部であるメンバー・ノードについての詳細が表に表示されます。

注意:
懐中電灯アイコンを使用してOracle Clusterwareを選択するときに、探しているOracle Clusterwareが見つからない場合、クラスタウェアの詳細を手動で指定して検索します。それには、表の下に示されるヒントから「ここ」をクリックします。

2. 「参照ホスト・オプション」セクションで、「クラスタ・ノード」リストから、すべてのクリーンアップ操作を実行するプライマリ・ノードとして使用するノードを選択します。
「作業ディレクトリ」には、ステージング・ファイルに使用できる選択したノード上の既存のディレクトリへのフルパスを指定します。

3. 「削除するノードの選択」セクションで、削除するノードを選択し、「削除対象としてマーク」をクリックします。「削除対象としてマーク」をクリックすると、選択したノードの「削除」列に十字アイコンが表示されます。これらの十字アイコンは、ノードが削除対象として選択されていることを示します。
クラスタに属するノードが表示されない場合は、「ノードの追加」をクリックし、それらのノードを追加して、Cloud Controlでターゲットとして表示されないノードも削除対象として選択されるようにします。

ノードの選択を解除するには、「マーク解除」をクリックします。一度にすべてのノードを選択するには「すべてマーク」をクリックし、すべてのノードの選択を解除するには「すべてマーク解除」をクリックします。

4. 「ユーザー資格証明(優先資格証明の上書き)」セクションで、デフォルトの選択(「優先資格証明の使用」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。たとえば、ユーザーがAおよびBである2つの宛先ホストを追加した場合、それぞれのホストに対して異なる資格証明で優先資格証明を上書きする選択ができます。同様に、宛先ホストに同じ資格証明があり、それが優先資格証明とは異なる場合、すべてのホストに対して同一の資格証明で優先資格証明を上書きできます。
ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

「ホスト資格証明」リストから、各Oracleホームごとに異なるオペレーティング・システム資格証明を使用する場合には「各Oracleホームごとに個別」を選択し、すべてのOracleホームで同じ資格証明を使用する場合には「すべてのOracleホームで同一」を選択します。選択に基づき、資格証明を指定します。ユーザーが同じグループ(dba/oinstall)に属していることを確認してください。

5. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

6. 「確認」をクリックします。

4. 「確認」ページで、Oracle RACを削除またはスケール・ダウンするために指定した詳細を確認し、「発行」をクリックします。

注意:
デプロイメント・プロシージャが失敗した場合、第F.7項で説明されているログ・ファイルを確認します。

12 Oracleデータベース・リプレイ・クライアントのプロビジョニング

この章では、Oracle Enterprise Manager Cloud Control(Cloud Control)を使用して、Oracleデータベース・リプレイ・クライアントをプロビジョニングする方法について説明します。この章の具体的な内容は次のとおりです。

- Oracleデータベース・リプレイ・クライアントのプロビジョニングの概要

- 実行中のOracleデータベース・リプレイ・クライアントのクローニング

- ゴールド・イメージを使用したOracleデータベース・リプレイ・クライアントのプロビジョニング

- インストール・バイナリを使用したOracleデータベース・リプレイ・クライアントのプロビジョニング

12.1 Oracleデータベース・リプレイ・クライアントのプロビジョニングの概要

この項では、この章に取り組むための手引きとして、Oracleデータベース・リプレイ・クライアントのプロビジョニング手順の概要を説明します。この項は、Oracleデータベース・リプレイ・クライアントのプロビジョニングを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表12-1 Oracleデータベース・リプレイ・クライアントのプロビジョニングの概要

ステップ

説明

参照リンク

ステップ1

ユースケースの選択

ここでは、Oracleデータベース・リプレイ・クライアントのプロビジョニングのユースケースのいくつかを説明します。ご自身の要件に最適なユースケースを選択してください。

- 既存のOracleデータベース・リプレイ・クライアントのクローニングの詳細は、第12.2項を参照してください。

- ゴールド・イメージを使用したOracleデータベース・リプレイ・クライアントのプロビジョニングの詳細は、第12.3項を参照してください。

- スタンドアロンOracleデータベース・リプレイ・クライアントのプロビジョニングの詳細は、第12.4項を参照してください。

ステップ2

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

- 既存のOracleデータベース・リプレイ・クライアントのクローニングの前提条件の詳細は、第12.2.1項を参照してください。

- ゴールド・イメージを使用したOracleデータベース・リプレイ・クライアントのプロビジョニングの前提条件の詳細は、第12.3.1項を参照してください。

- スタンドアロンOracleデータベース・リプレイ・クライアントのプロビジョニングの前提条件の詳細は、第12.4.1項を参照してください。

ステップ3

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行してOracleデータベース・リプレイ・クライアントを正常にプロビジョニングします。

- 既存のOracleデータベース・リプレイ・クライアントをクローニングするには、第12.2.2項で説明する手順に従います。

- ゴールド・イメージを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングするには、第12.3.2項で説明する手順に従います。

- スタンドアロンOracleデータベース・リプレイ・クライアントをプロビジョニングするには、第12.4.2項で説明する手順に従います。

12.2 実行中のOracleデータベース・リプレイ・クライアントのクローニング

この項では、Cloud Controlにより監視されるホストで実行中の既存のOracleデータベース・リプレイ・クライアントをクローニングする方法について説明します。

このオプションは、安定した、すべての最新パッチが適用されたOracleデータベース・リプレイ・クライアントの実行中のインスタンスがあり、複数のホスト上に同一のコピーを作成する場合に最適です。ただし、既存のインスタンスを使用することに含まれるリスクとして、いつでも事前通知なしにインスタンスが削除される可能性があり、結果として、デプロイメント・プロシージャが失敗する可能性があります。このため、このオプションは、実行中のインスタンスをクローニングに使用できることがわかっている場合にのみ使用してください。

この項の具体的な内容は次のとおりです。

- 実行中のOracleデータベース・リプレイ・クライアントをクローニングするための前提条件

- 実行中のOracleデータベース・リプレイ・クライアントをクローニングする手順

12.2.1 実行中のOracleデータベース・リプレイ・クライアントをクローニングするための前提条件

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

設計者に対する前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- ソース・ホストとターゲット・ホストの構成を比較し、両者の構成が同じであることを確認します。構成が異なる場合は、システム管理者に連絡し、不一致を修正してから、デプロイメント・プロシージャを実行します。
ホストの構成を比較するには、Cloud Controlで「ターゲット」、「ホスト」の順にクリックします。「ホスト」ページで、ソース・ホスト名をクリックしてその「ホーム」ページにアクセスし、「ホスト」メニューから、「構成」、「比較」の順にクリックします。

オペレータに対する前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

- ターゲット・ホストのumask値が022であることを確認します。確認するには、次のコマンドを実行します。
$ umask

使用しているシェルにより、この値は/etc/profile、/etc/bashrcまたは/etc/csh.cshrcで確認することもできます。

12.2.2 実行中のOracleデータベース・リプレイ・クライアントをクローニングする手順

既存のOracleデータベース・リプレイ・クライアントのインスタンスをクローニングするには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. 「データベース・プロシージャ」ページでOracleデータベース・クライアントのプロビジョニング・デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracleデータベース・クライアントのプロビジョニング・ウィザードが起動します。

3. 「ソースと宛先の選択」ページで、次を実行します。

1. 「ソースの選択」セクションで、「既存のデータベース・リプレイ・クライアントのインストール」を選択します。「ソース・ホスト」の懐中電灯アイコンをクリックして、既存のOracleデータベース・リプレイ・クライアントが実行しているホストを選択します。
「ソース・ホストの詳細」セクションでは、デフォルトで「Oracleホーム」、「作業ディレクトリ」および「除外するファイル」が事前に入力されています。「Oracleホーム」には既存のインスタンスがインストールされている場所が表示されますが、これは編集できないフィールドです。「作業ディレクトリ」には、クローニングに関連するファイルが一時的にステージングされるソース・ホスト上のディレクトリへのフルパスを指定します。「除外するファイル」には、ソース・ホストにクローニングしないファイル名を指定します。ファイル名を区切るにはカンマを使用し、同じ拡張子を持つすべてのファイルを示すにはワイルドカード(*)を使用します。たとえば、*.trcなどです。ここで指定した正規表現に対応するファイルまたはフォルダが除外されることに注意してください。

「ソース・ホスト資格証明」セクションで、「優先資格証明の使用」を選択して、管理リポジトリに格納されている優先資格証明を使用します。「優先資格証明のオーバーライド」を選択して、その他の資格証明を指定します。

2. 「宛先ホスト設定の指定」セクションで、「追加」をクリックし、Oracleデータベース・リプレイ・クライアントの既存のインスタンスをクローニングするターゲット・ホストを選択します。

注意:
「追加」をクリックすると、適したホストのリストがウィンドウに表示されます。目的のホストが表示されない場合、「すべてのホストを表示」を選択し、「実行」をクリックして、その他のすべてのホストを表示します。

デフォルトでは、「Oracleベース」、「Oracleホーム」および「作業ディレクトリ」にサンプル値が事前に入力されています。これらを編集し、環境と標準に合った値を指定します。指定したディレクトリがターゲット・ホストに存在しない場合、デプロイメント・プロシージャにより作成されます。

管理リポジトリに格納されている優先資格証明を使用できるように、「資格証明」リストのデフォルトで選択されている「優先」を保持します。ここでの資格証明は、オペレーティング・システムの資格証明を参照します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。たとえば、ユーザーがAおよびBである2つの宛先ホストを追加した場合、それぞれのホストに対して異なる資格証明で優先資格証明を上書きする選択ができます。同様に、宛先ホストに同じ資格証明があり、それが優先資格証明とは異なる場合、すべてのホストに対して同一の資格証明で優先資格証明を上書きできます。
ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

複数のホストを選択した場合、すべてのホストで同じパスを使用するには、「パス」リストから「すべてのホストで同一」を選択し、ホストごとに異なるパスを使用するには、「ホストごとに異なる」を選択します。

注意:
「すべてのホストで同一」を選択する場合、Oracleホームおよびユーザーがすべてのホスト上に存在することを確認してください。

ホストの設定をカスタマイズする場合、「ホスト設定のカスタマイズ」をクリックします。たとえば、管理エージェントのホームの資格証明、インストールの名前、またはシステムで検出された最初のホスト名のかわりの代替ホスト名を指定できます。

3. (オプション)「拡張インストール・パラメータ」セクションには、Oracleデータベース・リプレイ・クライアントをインストールする際に実行する追加パラメータを指定します。たとえば、-force (警告を上書き)、-debug (デバッグ情報を詳細に表示)、および-invPtrLoc <Location> (UNIXのみ)と指定します。パラメータは必ず空白で区切ります。
既存のOracleデータベース・リプレイ・クライアントの場所からソフトウェア・バイナリをインストールする際、これを共有場所にもステージングする場合は、「共有場所へのステージング」を選択し、すべての宛先ホスト間で共有される場所を指定します。このステージング先の場所は、将来のデプロイメントのソースとしても機能します。

4. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

5. 「続行」をクリックします。

4. 「確認」ページで、Oracleデータベース・リプレイ・クライアントをプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

注意:
デプロイメント・プロシージャが失敗した場合、第F.7項で説明されているログ・ファイルを確認します。

12.3 ゴールド・イメージを使用したOracleデータベース・リプレイ・クライアントのプロビジョニング

この項では、ソフトウェア・ライブラリからOracleデータベース・リプレイ・クライアントのゴールド・イメージをプロビジョニングする方法について説明します。

このオプションは、安定し、十分にテストされて、パッチが適用された、ソフトウェア・ライブラリに格納されたOracleデータベース・リプレイ・クライアントのコピーがある場合に最適です。このオプションは、新規インスタンスへのパッチ適用とテストの時間を節約するため、新規インストールよりも優れています。

この項の具体的な内容は次のとおりです。

- ゴールド・イメージを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングするための前提条件

- ゴールド・イメージを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングする手順

12.3.1 ゴールド・イメージを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

設計者に対する前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- ゴールド・イメージが、ソフトウェア・ライブラリ内、または共有のステージングの場所で使用可能になっている必要があります。

オペレータに対する前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

- Oracleデータベース・リプレイ・クライアントのソフトウェア・バイナリの配置に使用されるステージング領域に対する書込み権限を持つオペレーティング・システム・ユーザーを使用していることを確認します。
デプロイメント・プロシージャにより、バイナリの迅速なファイル転送のためにステージングの場所を使用し、ネットワークでのトラフィックの増加を防止することができます。ステージングの場所を指定するときに、使用するオペレーティング・システム・ユーザーに、それらのステージングの場所への書込み権限があることを確認します。

- ターゲット・ホストのumask値が022であることを確認します。確認するには、次のコマンドを実行します。
$ umask

使用しているシェルにより、この値は/etc/profile、/etc/bashrcまたは/etc/csh.cshrcで確認することもできます。

12.3.2 ゴールド・イメージを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングする手順

Oracleデータベース・リプレイ・クライアントのゴールド・イメージをソフトウェア・ライブラリからプロビジョニングするには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. 「データベース・プロシージャ」ページでOracleデータベース・クライアントのプロビジョニング・デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracleデータベース・クライアントのプロビジョニング・ウィザードが起動します。

3. 「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ」サブタブで、表から「Oracleデータベース・リプレイ・クライアントのプロビジョニング」を選択します。次に、「デプロイメントのスケジュール」をクリックします。
デプロイメント・プロシージャの「ソースと宛先の選択」ページが表示されます。

4. 「ソースと宛先の選択」ページで、次を実行します。

1. 「ソースの選択」セクションで、次のいずれかを実行します。
ゴールド・イメージがソフトウェア・ライブラリにコンポーネントとして格納されている場合は、「ソフトウェア・ライブラリ」を選択します。次に、「コンポーネント」の懐中電灯アイコンをクリックして、ゴールド・イメージがあるコンポーネントを選択します。「準備完了」のコンポーネントのみを選択してください。

注意:
必要なコンポーネントがソフトウェア・ライブラリにない場合、付録Fで説明している回避策に従ってください。

以前のデータベースのプロビジョニングのときにゴールド・イメージがステージングの場所にイメージとして格納された場合は、「外部ステージング・サーバー」、「ゴールド・イメージ」の順に選択します。「ホストの選択」の懐中電灯アイコンをクリックして、ゴールド・イメージが格納されているホストを選択します。次に、「ステージングの場所」の懐中電灯アイコンをクリックして、ゴールド・イメージが使用可能なホスト上の場所を選択します。「製品バージョン」では、プロビジョニングする製品のバージョンを指定します。

2. 「宛先ホスト設定の指定」セクションで、「追加」をクリックし、Oracleデータベース・リプレイ・クライアントのゴールド・イメージをインストールするターゲット・ホストを選択します。

注意:
「追加」をクリックすると、適したホストのリストがウィンドウに表示されます。目的のホストが表示されない場合、「すべてのホストを表示」を選択し、「実行」をクリックして、その他のすべてのホストを表示します。

デフォルトでは、「Oracleベース」、「Oracleホーム」および「作業ディレクトリ」にサンプル値が事前に入力されています。これらを編集し、環境と標準に合った値を指定します。指定したディレクトリがターゲット・ホストに存在しない場合、デプロイメント・プロシージャにより作成されます。

管理リポジトリに格納されている優先資格証明を使用できるように、「資格証明」リストのデフォルトで選択されている「優先」を保持します。ここでの資格証明は、オペレーティング・システムの資格証明を参照します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。たとえば、ユーザーがAおよびBである2つの宛先ホストを追加した場合、それぞれのホストに対して異なる資格証明で優先資格証明を上書きする選択ができます。同様に、宛先ホストに同じ資格証明があり、それが優先資格証明とは異なる場合、すべてのホストに対して同一の資格証明で優先資格証明を上書きできます。
ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

複数のホストを選択した場合、すべてのホストで同じパスを使用するには、「パス」リストから「すべてのホストで同一」を選択し、ホストごとに異なるパスを使用するには、「ホストごとに異なる」を選択します。

注意:
「すべてのホストで同一」を選択する場合、Oracleホームおよびユーザーがすべてのホスト上に存在することを確認してください。

ホストの設定をカスタマイズする場合、「ホスト設定のカスタマイズ」をクリックします。たとえば、管理エージェントのホームの資格証明、インストールの名前、またはシステムで検出された最初のホスト名のかわりの代替ホスト名を指定できます。

3. (オプション)「拡張インストール・パラメータ」セクションには、Oracleデータベース・リプレイ・クライアントをインストールする際に実行する追加パラメータを指定します。たとえば、-force (警告を上書き)、-debug (デバッグ情報を詳細に表示)、および-invPtrLoc <Location> (UNIXのみ)と指定します。パラメータは必ず空白で区切ります。
Oracleデータベース・リプレイ・クライアントをインストールする際、これを共有場所にもステージングする場合は、「共有場所へのステージング」を選択し、すべての宛先ホスト間で共有される場所を指定します。このステージング先の場所は、将来のデプロイメントのソースとしても機能します。

4. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

5. 「続行」をクリックします。

5. 「確認」ページで、Oracleデータベース・リプレイ・クライアントをプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

注意:
デプロイメント・プロシージャが失敗した場合、第F.7項で説明されているログ・ファイルを確認します。

12.4 インストール・バイナリを使用したOracleデータベース・リプレイ・クライアントのプロビジョニング

この項では、インストール・メディアで使用可能なものと同じOracleデータベース・リプレイ・クライアントをプロビジョニングする方法について説明します。

このオプションは、まったく新しいインストールを複数のホスト間でプロビジョニングする場合に最適です。これは新規インストールであるため、それまでにリリースされているすべての最新パッチを使用して更新する必要があります。

注意:
ワークロードのリプレイに使用されるOracleデータベース・リプレイ・クライアントのバージョンは、ワークロードがリプレイされる必要のあるテスト・データベースのバージョンと同じである必要があります。Oracleデータベース・リプレイ・クライアントはOracle Database 10gリリース4 (10.2.0.4)以降でサポートされます。Oracle Database Client 11gリリース1 (11.1.0.6)およびOracle Database Client 11gリリース2のインストールには、アーカイブされたソフトウェア・バイナリを使用できますが、テスト・データベースのバージョン10.2.0.4、10.2.0.5および11.1.0.7に対しては、Oracleデータベース・リプレイ・クライアント・ホームのそれぞれのバージョンのゴールド・イメージを作成し、同じものを使用する必要があります。

この項の具体的な内容は次のとおりです。

- インストール・バイナリを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングするための前提条件

- インストール・バイナリを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングする手順

12.4.1 インストール・バイナリを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングするための前提条件

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

設計者に対する前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

注意:
Oracleデータベース・リプレイ・クライアントのソフトウェア・バイナリのコンポーネントを作成する場合、ソフトウェア・ライブラリにアクセスする前に、My Oracle Supportノート815567.1を参照してください。このノートでは、Cloud Controlデプロイメント・プロシージャでメディアを使用する前の、各OSプラットフォームに対する様々な要件を説明しています。

注意:
Oracleデータベース・リプレイ・クライアントのソフトウェア・バイナリのコンポーネントを作成する場合、ソフトウェア・ライブラリの「コンポーネント」フォルダにshiphomeまたはコンポーネントを保存しないでください。ソフトウェア・ライブラリで新規フォルダを作成してから、コンポーネントを保存してください。

- インストール・バイナリがダウンロードされ、アーカイブされて、ソフトウェア・ライブラリのコンポーネントとしてアップロードされていることが必要です。

- ソース・ホストとターゲット・ホストの構成を比較し、両者の構成が同じであることを確認します。構成が異なる場合は、システム管理者に連絡し、不一致を修正してから、デプロイメント・プロシージャを実行します。
ホストの構成を比較するには、Cloud Controlで「ターゲット」、「ホスト」の順にクリックします。「ホスト」ページで、ソース・ホスト名をクリックしてその「ホーム」ページにアクセスし、「ホスト」メニューから、「構成」、「比較」の順にクリックします。

オペレータに対する前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

- ターゲット・ホストのumask値が022であることを確認します。確認するには、次のコマンドを実行します。
$ umask

使用しているシェルにより、この値は/etc/profile、/etc/bashrcまたは/etc/csh.cshrcで確認することもできます。

12.4.2 インストール・バイナリを使用してOracleデータベース・リプレイ・クライアントをプロビジョニングする手順

新しいOracleデータベース・リプレイ・クライアントをプロビジョニングするには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. 「データベース・プロシージャ」ページでOracleデータベース・クライアントのプロビジョニング・デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracleデータベース・リプレイ・クライアントのプロビジョニング・ウィザードを起動します。
デプロイメント・プロシージャの「ソースと宛先の選択」ページが表示されます。

3. 「ソースと宛先の選択」ページで、次を実行します。

1. 「ソースの選択」セクションで、次のいずれかを実行します。
ソフトウェア・バイナリがソフトウェア・ライブラリにコンポーネントとして格納されている場合は、「ソフトウェア・ライブラリ」を選択します。次に、「コンポーネント」の懐中電灯アイコンをクリックして、アーカイブ済ソフトウェア・バイナリがあるコンポーネントを選択します。「準備完了」のコンポーネントのみを選択してください。ソフトウェア・ライブラリからコンポーネントを選択すると、コンポーネントの場所に自動的に移入されます。

注意:
必要なコンポーネントがソフトウェア・ライブラリにない場合、付録Fで説明している回避策に従ってください。

ソフトウェア・バイナリがステージングの場所にアーカイブ・ファイルとして格納されている場合は、「外部ステージング・サーバー」、「Shiphome」の順に選択します。「ホストの選択」の懐中電灯アイコンをクリックして、アーカイブ済ファイルが格納されているホストを選択します。次に、「ステージングの場所」の懐中電灯アイコンをクリックして、アーカイブ・ファイルが使用可能なホスト上の場所を選択します。「製品バージョン」では、プロビジョニングする製品のバージョンを指定します。

2. 「宛先ホスト設定の指定」セクションで、「追加」をクリックし、Oracleデータベース・リプレイ・クライアントをインストールするターゲット・ホストを選択します。

注意:
「追加」をクリックすると、適したホストのリストがウィンドウに表示されます。目的のホストが表示されない場合、「すべてのホストを表示」を選択し、「実行」をクリックして、その他のすべてのホストを表示します。

デフォルトでは、「Oracleベース」、「Oracleホーム」および「作業ディレクトリ」にサンプル値が事前に入力されています。これらを編集し、環境と標準に合った値を指定します。指定したディレクトリがターゲット・ホストに存在しない場合、デプロイメント・プロシージャにより作成されます。

管理リポジトリに格納されている優先資格証明を使用できるように、「資格証明」リストのデフォルトで選択されている「優先」を保持します。ここでの資格証明は、オペレーティング・システムの資格証明を参照します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。たとえば、ユーザーがAおよびBである2つの宛先ホストを追加した場合、それぞれのホストに対して異なる資格証明で優先資格証明を上書きする選択ができます。同様に、宛先ホストに同じ資格証明があり、それが優先資格証明とは異なる場合、すべてのホストに対して同一の資格証明で優先資格証明を上書きできます。
ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

複数のホストを選択した場合、すべてのホストで同じパスを使用するには、「パス」リストから「すべてのホストで同一」を選択し、ホストごとに異なるパスを使用するには、「ホストごとに異なる」を選択します。

注意:
「すべてのホストで同一」を選択する場合、Oracleホームおよびユーザーがすべてのホスト上に存在することを確認してください。

ホストの設定をカスタマイズする場合、「ホスト設定のカスタマイズ」をクリックします。たとえば、管理エージェントのホームの資格証明、インストールの名前、またはシステムで検出された最初のホスト名のかわりの代替ホスト名を指定できます。

3. (オプション)「拡張インストール・パラメータ」セクションには、Oracleデータベース・リプレイ・クライアントをインストールする際に実行する追加パラメータを指定します。たとえば、-force (警告を上書き)、-debug (デバッグ情報を詳細に表示)、および-invPtrLoc <Location> (UNIXのみ)と指定します。パラメータは必ず空白で区切ります。
ソフトウェア・ライブラリからソフトウェア・バイナリをインストールする際、これを共有場所にもステージングする場合は、「共有場所へのステージング」を選択し、すべての宛先ホスト間で共有される場所を指定します。このステージング先の場所は、将来のデプロイメントのソースとしても機能します。

4. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

5. 「続行」をクリックします。

4. 「確認」ページで、Oracleデータベース・リプレイ・クライアントをプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

注意:
デプロイメント・プロシージャが失敗した場合、第F.7項で説明されているログ・ファイルを確認します。

13 Oracleスタンバイ・データベースのプロビジョニング

この章の構成は、次のとおりです。

- スタンバイ・データベースの作成の概要

- 新規のフィジカル・スタンバイ・データベースの作成(単一インスタンスのみ)

- 新規のロジカル・スタンバイ・データベースの作成(単一インスタンスのみ)

- Data Guard Brokerを使用した既存のスタンバイ・データベースの管理

- プライマリ・データベースのバックアップのみを作成

13.1 スタンバイ・データベースの作成の概要

スタンバイ・データベースを作成することは、データベースを管理して監視する前に実行する必要がある最初の作業です。Enterprise Manager Cloud Controlには、1つのプライマリ・データベースと1つ以上のスタンバイ・データベースを含むBroker構成を作成するためのスタンバイ・データベースの追加ウィザードが用意されています。

フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースを作成できます。フィジカル・スタンバイ・データベースは、プライマリ・データベースと物理的に同じものであり、リカバリ・モード時にマウントまたは読取り専用でオープンされ、すべてのデータ型とDDLをサポートしています。ロジカル・スタンバイ・データベースは、プライマリ・データベースとは物理的に異なり、リカバリ・モード時に読取り/書込みのみでオープンされます。また、データ保護およびレポート作成に使用でき、一部のデータバースとDDLのみをサポートしています。

スタンバイ・データベースの作成プロセスでは、次のステップが実行されます。

- プライマリ・データベースの制御ファイル、データファイルおよびアーカイブREDOログ・ファイルのオンライン・バックアップ(または、必要に応じて既存のバックアップを使用)を実行します

- プライマリ・ホストからスタンバイ・ホストにバックアップ・データを転送します

- 必要なその他のファイル(初期化、パスワードなど)をスタンバイ・ホスト上に作成します

- 制御ファイル、データファイルおよびアーカイブREDOログ・ファイルを、スタンバイ・ホスト上の指定した場所にリストアします

- オンラインREDOログ・ファイルとその他のファイルを、必要に応じてスタンバイ・データベースに追加します

- リカバリしたデータベースを、フィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースとして構成します

13.2 新規のフィジカル・スタンバイ・データベースの作成(単一インスタンスのみ)

新規のフィジカル・スタンバイ・データベースを作成するには(単一インスタンスのみ)、次の手順を実行します。

注意:
新規のフィジカル・データベースが単一インスタンス・データベースとして作成されます。Enterprise Managerのクラスタ・データベースへの変換機能を使用して、スタンバイ・データベースを作成後、そのスタンバイ・データベースをクラスタ・データベースに変換できます。

1. 「ターゲット」メニューから「データベース」を選択します。

2. 「データベース」ページで、データベースのリストを確認します。新規フィジカル・スタンバイ・データベースを作成する対象のプライマリ・データベースを選択します。

3. 「プライマリ・データベース」ホームページで、「可用性」をクリックしてから、「スタンバイ・データベースの追加」を選択します。

4. 「データベース・ログイン」ページで、資格証明を入力します。「ログイン」をクリックします。

注意:
プライマリ・データベースにまだ接続していない場合は、SYSDBA資格証明を使用して接続する必要があります。
SYSDBA権限を持つユーザーとしてログインした場合は、すべての監視および管理機能など、Data Guardのすべての機能を使用できます。SYSDBA権限を持たないユーザーとしてログインした場合は、監視機能のみを使用できます。スタンバイ・データベースの作成、スイッチオーバーおよびフェイルオーバーなどの機能は使用できません。

5. 「スタンバイ・データベースの追加」ページで、「新規のフィジカル・スタンバイ・データベースの作成」を選択します。「続行」をクリックします。

注意:
新規のフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースを作成する場合、Data Guardでは、「続行」をクリックすると、次の項目がチェックされます。

- サーバー・パラメータ・ファイル(SPFILE) -- Data Guardでは、構成内のすべてのデータベースがサーバー・パラメータ・ファイル(SPFILE)を使用する必要があります。SPFILEを使用していないプライマリ・データベースが見つかると、ウィザードは停止し、SPFILEの作成を要求するメッセージを戻します。デフォルト以外の名前で作成できます。Data Guardで必要になるのは、プライマリ・データベースがSPFILEを使用することのみです。

- NOARCHIVELOGモード -- いずれの方法でスタンバイ・データベースを追加する場合も、プライマリ・データベースをARCHIVELOGモードに設定する必要があります。プライマリ・データベースがNOARCHIVELOGモードの場合は、ウィザードを終了して、プライマリ・データベースをARCHIVELOGモードに変更するように要求されます。

6. スタンバイ・データベースの追加ウィザードが開きます。ウィザードでは、次の手順を実行します。

- バックアップ・タイプの決定。

- バックアップ・オプションの設定。

- スタンバイ・データベースを作成するOracleホームの選択。

- スタンバイ・データベース・ファイルの場所の設定。

- スタンバイ・データベースの構成パラメータの指定。

- 情報を確認してから「終了」をクリック。

13.2.1 ステップ1: バックアップ・タイプの決定

Enterprise Managerは、Oracle Recovery Manager (RMAN)を使用して、プライマリ・データベースの新規バックアップまたは既存のバックアップから単一インスタンスのスタンバイ・データベースを作成します。スタンバイ・データベースの作成で使用する2つのバックアップ操作のいずれかを選択できます。

- プライマリ・データベース稼働中にバックアップを実行し、RMANを使用してデータベース・ファイルをコピーするか、またはステージング領域を介してデータベース・ファイルをコピーします。

- 以前のスタンバイ・データベース作成時の既存のRMANバックアップまたは既存のバックアップを使用します。

「次へ」をクリックします。

「取消」をクリックして現在のプロセスを終了し、スタンバイ・データベースの追加ウィザードの最初のページから再度開始できます。

13.2.2 ステップ2: バックアップ・オプションの設定

RMANを使用したオンライン・バックアップの場合は、「並列度」を入力します(RMANがデータベース・ファイルをコピーするのに使用するパラレル・チャネルの数)。デフォルトの桁数は2です。

ステージング領域を介したデータベース・ファイルのコピーによるオンライン・バックアップの場合は、ステージング領域の場所を指定します。スタンバイ・データベースの作成後に、ディレクトリを保持または削除するよう選択することもできます。

RMANを使用したオンライン・バックアップの場合は、RMANバックアップの場所とステージング領域の場所を指定します。

プライマリ・ホストの資格証明を入力します。既存の資格証明を使用するか、または新しい資格証明を作成できます。新しい資格証明を作成した場合は、その資格証明を保存して、後で別のスタンバイ・データベースを作成する際に使用できます。これを実行するには、「優先資格証明として設定」ボックスをチェックします。

「次へ」をクリックします。

「取消」をクリックして現在のプロセスを終了し、スタンバイ・データベースの追加ウィザードの最初のページから再度開始できます。

13.2.3 ステップ3: スタンバイ・データベースを作成するOracleホームの選択

スタンバイ・データベースは、Oracle Enterprise Managerで検出された任意のOracleホームで作成できます。プライマリ・ホストのオペレーティング・システムに一致する、ホスト上のOracleホームのみが表示されます。検出されたOracleホームを選択し、スタンバイ・データベースに対して一意のインスタンス名を指定する必要があります。続行するには、スタンバイ・ホストの資格証明が必要です。

13.2.4 ステップ4: スタンバイ・データベース・ファイルの場所の設定

プライマリ・データベースとスタンバイ・データベースは同じホスト上に存在するため、スタンバイ・データベース・ファイルは、Oracle Optimal Flexible Architecture (OFA)ディレクトリ構造に置かれます。「カスタマイズ」をクリックして、個々のファイル名を変更します。

「リスナー構成」セクションで、スタンバイ・データベースで使用するリスナーの名前とポートを指定します。既存のリスナーが使用していない新しい名前とポートを指定すると、指定したポートを使用する新しいリスナーが作成されます。

「次へ」をクリックします。

「取消」をクリックして現在のプロセスを終了し、スタンバイ・データベースの追加ウィザードの最初のページから再度開始できます。

13.2.5 ステップ5: スタンバイ・データベースの構成パラメータの指定

スタンバイ・データベースの構成パラメータを設定する必要があります。これらのパラメータには、データベース名、データベースの一意の名前、ターゲット名およびスタンバイ・アーカイブの場所などが含まれます。スタンバイ・アーカイブの場所は、通常のディレクトリまたはフラッシュのリカバリ領域に設定できます。デフォルト値は、対応するプライマリ・データベースの設定に基づいています。

パラメータが正しいことを確認したら、「次」をクリックします。

「取消」をクリックして現在のプロセスを終了し、スタンバイ・データベースの追加ウィザードの最初のページから再度開始できます。

13.2.6 ステップ6: 情報を確認してから「終了」をクリック

スタンバイ・データベースの追加ウィザードでは、構成およびスタンバイ・データベースに対して最後に入力したデータを確認できます。情報がすべて正しいことを確認したら、「終了」をクリックします。

「取消」をクリックして現在のプロセスを終了し、スタンバイ・データベースの追加ウィザードの最初のページから再度開始できます。

「スタンバイ・データベース記憶域」をクリックすると、スタンバイ・データベース・ファイルのすべての場所に関する詳細な情報を表示できます。

「終了」をクリックすると、スタンバイ・データベースの作成プロセスがOracle Enterprise Managerのジョブとして実行されます。ジョブを発行する前であればいつでもスタンバイの作成を取り消すことができます。

ジョブが発行されると、「Data Guardの概要」ページが表示されます。「スタンバイ・データベース」表の「ステータス」列に、「作成の進行中」が一覧表示されます。そのリンクをクリックすると、スタンバイ・データベース作成の進行状況を監視できます。

注意:
最初に構成を作成した後にスタンバイ・データベースを追加するには、「スタンバイ・データベースの追加」をクリックして、再度スタンバイ・データベースの追加ウィザードを実行します。

13.3 新規のロジカル・スタンバイ・データベースの作成(単一インスタンスのみ)

新規のフィジカル・スタンバイ・データベースを作成するには(単一インスタンスのみ)、次の手順を実行します。

注意:
新規のロジカル・スタンバイ・データベースが単一インスタンス・データベースとして作成されます。Enterprise Managerのクラスタ・データベースへの変換機能を使用して、スタンバイ・データベースを作成後、そのスタンバイ・データベースをクラスタ・データベースに変換できます。

1. 「ターゲット」メニューから「データベース」を選択します。

2. 「データベース」ページで、データベースのリストを確認します。新規フィジカル・スタンバイ・データベースを作成する対象のプライマリ・データベースを選択します。

3. 「プライマリ・データベース」ホームページで、「可用性」をクリックしてから、「スタンバイ・データベースの追加」を選択します。

4. 「データベース・ログイン」ページで、資格証明を入力します。「ログイン」をクリックします。

注意:
プライマリ・データベースにまだ接続していない場合は、SYSDBA資格証明を使用して接続する必要があります。
SYSDBA権限を持つユーザーとしてログインした場合は、すべての監視および管理機能など、Data Guardのすべての機能を使用できます。SYSDBA権限を持たないユーザーとしてログインした場合は、監視機能のみを使用できます。スタンバイ・データベースの作成、スイッチオーバーおよびフェイルオーバーなどの機能は使用できません。

5. 「スタンバイ・データベースの追加」ページで、「新規のフィジカル・スタンバイ・データベースの作成」を選択します。「続行」をクリックします。

注意:
新規のフィジカル・スタンバイ・データベースまたはロジカル・スタンバイ・データベースを作成する場合、Data Guardでは、「続行」をクリックすると、次の項目がチェックされます。

- サーバー・パラメータ・ファイル(SPFILE) -- Data Guardでは、構成内のすべてのデータベースがサーバー・パラメータ・ファイル(SPFILE)を使用する必要があります。SPFILEを使用していないプライマリ・データベースが見つかると、ウィザードは停止し、SPFILEの作成を要求するメッセージを戻します。デフォルト以外の名前で作成できます。Data Guardで必要になるのは、プライマリ・データベースがSPFILEを使用することのみです。

- NOARCHIVELOGモード -- いずれの方法でスタンバイ・データベースを追加する場合も、プライマリ・データベースをARCHIVELOGモードに設定する必要があります。プライマリ・データベースがNOARCHIVELOGモードの場合は、ウィザードを終了して、プライマリ・データベースをARCHIVELOGモードに変更するように要求されます。

6. 「データベース」ページの「スタンバイ・データベース」セクションで、「スタンバイ・データベースの追加」をクリックします。

7. 次の手順では、1つのプライマリ・データベースと1つのフィジカル・スタンバイ・データベースを含むBroker構成がすでに存在していると仮定して、新規のロジカル・スタンバイ・データベースを作成します。次に、ウィザードにおいて、データベース用のOracleホームを選択して、データファイルをスタンバイ・データベースにコピーする詳細な手順を示します。
スタンバイ・データベースの追加ウィザードでは、次の手順を実行します。

1. バックアップ・タイプの決定。

2. バックアップ・オプションの設定。

3. スタンバイ・データベースを作成するOracleホームの選択。

4. スタンバイ・データベース・ファイルの場所の設定。

5. スタンバイ・データベースの構成パラメータの指定。

6. 情報を確認してから「終了」をクリック。

13.3.1 ステップ1: バックアップ・タイプの決定

Enterprise Managerは、Oracle Recovery Manager (RMAN)を使用して、プライマリ・データベースの新規バックアップまたは既存のバックアップから単一インスタンスのスタンバイ・データベースを作成します。スタンバイ・データベースの作成で使用する2つのバックアップ操作のいずれかを選択できます。

- プライマリ・データベース稼働中にバックアップを実行します。

- プライマリ・データベースの既存のバックアップを使用します。

「取消」をクリックして現在のプロセスを終了し、スタンバイ・データベースの追加ウィザードの最初のページから再度開始できます。

13.3.2 ステップ2: バックアップ・オプションの設定

プライマリ・データベースのバックアップ・ファイルを格納するための作業ディレクトリが必要です。将来の使用に備え、必要に応じて、追加のスタンバイ・データベースを作成するために保持して使用できます。作業ディレクトリを作成する、プライマリ・ホスト上の場所を指定します。

このステップでは、プライマリ・ホストの資格証明が必要になります。プライマリ・データベースのOracleサーバー・インストールの所有者の資格証明を入力します。この資格証明を保存するには、「優先資格証明として保存」ボックスをチェックします。

「取消」をクリックして現在のプロセスを終了し、スタンバイ・データベースの追加ウィザードの最初のページから再度開始できます。

13.3.3 ステップ3: スタンバイ・データベースを作成するOracleホームの選択

スタンバイ・データベースは、Oracle Enterprise Managerで検出された任意のOracleホームで作成できます。プライマリ・ホストのオペレーティング・システムに一致する、ホスト上のOracleホームのみが表示されます。検出されたOracleホームを選択し、スタンバイ・データベースに対して一意のインスタンス名を指定する必要があります。続行するには、スタンバイ・ホストの資格証明が必要です。

13.3.4 ステップ4: スタンバイ・データベース・ファイルの場所の設定

Broker構成の作成プロセスの一部として、プライマリ・データベースのデータファイルをスタンバイ・ホストが使用できるようにする操作があります。スタンバイ・データベース・ファイルの場所をカスタマイズするオプションもあります。続行するには、スタンバイ・ホストの資格証明が必要です。次のリストで、オプションについて説明します。

- バックアップ・ファイルへのアクセス・メソッドの指定
スタンバイ・ホストがプライマリ・データベースのバックアップ・ファイルにアクセスするためのメソッドを選択します。次の2つのオプションがあります。

- プライマリ・ホストの作業ディレクトリからスタンバイ・ホストの作業ディレクトリへのファイルの転送

- ネットワーク・パス名を使用した、スタンバイ・ホストからプライマリ・ホストの作業ディレクトリの場所への直接アクセス

- スタンバイ・データベース・ファイルの場所の指定
スタンバイ・データベース・ファイルの場所を選択します。次の2つのオプションがあります。

- Oracle OFA (Optimal Flexible Architecture)への変換

- プライマリ・データベースと同じファイル名と場所を保持

- ネットワーク構成ファイルの場所の指定
Data Guardでは、スタンバイ・データベースの構成情報が、スタンバイ・ホスト上で指定したディレクトリ内のネットワーク構成ファイル(listener.oraファイルとtnsnames.oraファイル)に追加されます。

「取消」をクリックして現在のプロセスを終了し、スタンバイ・データベースの追加ウィザードの最初のページから再度開始できます。

13.3.5 ステップ5: スタンバイ・データベースの構成パラメータの指定

スタンバイ・データベースの構成パラメータを設定する必要があります。これらのパラメータには、データベース名、データベースの一意の名前、ターゲット名およびスタンバイ・アーカイブの場所などが含まれます。スタンバイ・アーカイブの場所は、通常のディレクトリまたはフラッシュのリカバリ領域に設定できます。デフォルト値は、対応するプライマリ・データベースの設定に基づいています。

「取消」をクリックして現在のプロセスを終了し、スタンバイ・データベースの追加ウィザードの最初のページから再度開始できます。

13.3.6 ステップ6: 情報を確認してから「終了」をクリック

スタンバイ・データベースの追加ウィザードでは、構成およびスタンバイ・データベースに対して最後に入力したデータを確認できます。情報がすべて正しいことを確認したら、「終了」をクリックします。

「取消」をクリックして現在のプロセスを終了し、スタンバイ・データベースの追加ウィザードの最初のページから再度開始できます。

「スタンバイ・データベース記憶域」をクリックすると、スタンバイ・データベース・ファイルのすべての場所に関する詳細な情報を表示できます。

「終了」をクリックすると、スタンバイ・データベースの作成プロセスがOracle Enterprise Managerのジョブとして実行されます。ジョブを発行する前であればいつでもスタンバイの作成を取り消すことができます。

ジョブが発行されると、「Data Guardの概要」ページが表示されます。「スタンバイ・データベース」表の「ステータス」列に、「作成の進行中」が一覧表示されます。そのリンクをクリックすると、スタンバイ・データベース作成の進行状況を監視できます。

注意:
最初に構成を作成した後にスタンバイ・データベースを追加するには、「スタンバイ・データベースの追加」をクリックして、再度スタンバイ・データベースの追加ウィザードを実行します。

13.4 Data Guard Brokerを使用した既存のスタンバイ・データベースの管理

既存のスタンバイ・データベースを追加するには、次の手順を実行します。

1. 「ターゲット」メニューから「データベース」を選択します。

2. 「データベース」ページで、データベースのリストを確認します。既存のスタンバイ・データベースを管理するデータベースを選択します。

3. 「プライマリ・データベース」ホームページで、「可用性」をクリックしてから、「スタンバイ・データベースの追加」を選択します。

4. 「データベース・ログイン」ページで、資格証明を入力します。「ログイン」をクリックします。

注意:
プライマリ・データベースにまだ接続していない場合は、SYSDBA資格証明を使用して接続する必要があります。
SYSDBA権限を持つユーザーとしてログインした場合は、すべての監視および管理機能など、Data Guardのすべての機能を使用できます。SYSDBA権限を持たないユーザーとしてログインした場合は、監視機能のみを使用できます。スタンバイ・データベースの作成、スイッチオーバーおよびフェイルオーバーなどの機能は使用できません。

5. 「スタンバイ・データベースの追加」ページで、「Data Guard Brokerを使用した既存のスタンバイ・データベースの管理」を選択します。

6. Data Guard Brokerで管理する既存のスタンバイ・データベースを選択します。選択したデータベースはプライマリ・データベースから作成して、スタンバイ・データベースとして機能するように構成する必要があります。
環境内で検出されたすべてのデータベース(RACデータベースとRAC以外のデータベースの両方)がリストに表示されます。

「次へ」をクリックします。

注意:
随時「取消」をクリックして現在のプロセスを終了し、スタンバイ・データベースの追加ウィザードの最初のページから再度開始できます。

7. データベースのログイン資格証明を入力します。「名前付き」資格証明または「新規」資格証明を選択できます。新規の資格証明の場合は、一意の資格証明を作成します。この資格証明を再度使用する場合は、「優先資格証明」に設定します。
「次へ」をクリックします。

8. (オプション)既存のスタンバイ・クラスタ・データベースの「スタンバイ・アーカイブの場所」の設定を変更します。「次へ」をクリックします。

9. 構成およびスタンバイ・データベースのデータを確認します。「終了」をクリックします。

13.5 プライマリ・データベースのバックアップのみを作成

追加オプションでは、スタンバイ・データベースを作成せずにプライマリ・データベースのバックアップのみを作成します。このバックアップは、将来スタンバイ・データベースを作成する場合(スタンバイ・データベースの追加ウィザードを再度実行して、既存のバックアップからスタンバイ・データベースを作成)に使用できます。既存のバックアップは、プライマリ・ホストまたはスタンバイ・ホストから使用できます。Enterprise Managerが提供するプライマリ・ホストからスタンバイ・ホストへのバックアップ・ファイル転送用のファイル転送メカニズムを使用できず、かわりに独自のメカニズムを使用してスタンバイ・ホストにバックアップ・ファイルを転送およびステージングする場合に、このオプションを検討してください。

プライマリ・データベースのバックアップのみを作成するには、次の手順を実行します。

1. 「ターゲット」メニューから「データベース」を選択します。

2. 「データベース」ページで、データベースのリストを確認します。既存のスタンバイ・データベースを管理するデータベースを選択します。

3. 「プライマリ・データベース」ホームページで、「可用性」をクリックしてから、「スタンバイ・データベースの追加」を選択します。

4. 「データベース・ログイン」ページで、資格証明を入力します。「ログイン」をクリックします。

注意:
プライマリ・データベースにまだ接続していない場合は、SYSDBA資格証明を使用して接続する必要があります。
SYSDBA権限を持つユーザーとしてログインした場合は、すべての監視および管理機能など、Data Guardのすべての機能を使用できます。SYSDBA権限を持たないユーザーとしてログインした場合は、監視機能のみを使用できます。スタンバイ・データベースの作成、スイッチオーバーおよびフェイルオーバーなどの機能は使用できません。

5. 「スタンバイ・データベースの追加」ページで、「プライマリ・バックアップのみを作成」を選択します。
「続行」をクリックします。

6. 「バックアップ・オプション」ページで、プライマリ・データベースのバックアップ・ファイルを格納するためのディレクトリを作成する、プライマリ・ホスト上の場所を指定します。「次へ」をクリックします。

7. 「スケジュール」ページで、バックアップ・ジョブの名前、説明および開始時間を指定します。
バックアップをすぐに開始するか、または後で開始するかを選択できます。後で開始する場合は、バックアップを開始する日時を設定します。

「次へ」をクリックします。

8. 構成およびスタンバイ・データベースのデータを確認します。「終了」をクリックします。

14 Oracleデータベースおよびプラガブル・データベースのクローニング

Enterprise Manager Cloud Controlでは、「フル・クローン」方法を使用してデータベースをクローニングしたり、従来のクローニング・ウィザードを使用して、RMANバックアップ、ステージング領域または既存のバックアップを使用してデータベースをクローニングできます。

この章では、データベース・クローンの作成に使用できる次の手順について概説します。

- フル・クローン・データベースの作成

- テスト・マスター・データベースの作成

- フル・クローン・プラガブル・データベースの作成

- テスト・マスター・プラガブル・データベースの作成

- クラシック・クローニング・ウィザードを使用したデータベースのクローニング

14.1 フル・クローン・データベースの作成

フル・クローン・データベースを作成するには、次のいずれかのソリューションを使用できます。

- クローン・ウィザードを使用したフル・クローン・データベースの作成

- EM CLIを使用したフル・クローン・データベースの作成

14.1.1 クローン・ウィザードを使用したフル・クローン・データベースの作成

フル・クローン・データベースを作成するには、次の手順を実行します。

1. 「データベース」ページで、次のいずれかの方法でフル・クローン・データベース・ウィザードにアクセスできます。

- 表示されているデータベースのリストから、クローニングするデータベースを選択します。データベースのホームページで、「データベース」メニューをクリックし、「クローニング」→「フル・クローンの作成」を選択します。

- データベース・ターゲット名を右クリックし、「データベース」→「クローニング」→「フル・クローンの作成」を選択します。

- データベース・ターゲット名を右クリックし、「データベース」→「クローニング」→「クローンの管理」を選択します。「クローンの管理」ページの「フル・クローン・データベース」ボックスで、「作成」をクリックします。

2. フル・クローン・データベースの作成: ソースと宛先ページで、次の操作を実行します。

- 「ソース」セクションで、SYSDBAのデータベース資格証明とデータベース・ホスト資格証明の検索アイコンを選択して、資格証明セレクタを起動します。「OK」をクリックします。

- 「データ時系列」セクションで、「即時」または「前のポイント・イン・タイム」を選択します。
「即時」を選択した場合、SYSASMのASM資格証明を指定するか、検索して選択します。「現在」はライブ・クローンを参照します。

前の時点を選択した場合、「RMANバックアップ」イメージのカルーセルが表示されます。イメージで「選択」をクリックして、適切なRMANバックアップを選択します。

時点リストアを実行するためにバックアップを選択して時間およびSCNをオプションで変更し、フル・クローンを作成できます。「時間の選択」オプションには、現在のバックアップ時間に設定されている最大制限と次のバックアップ時間に設定されている最大時間制限があります。これらの2つの期間の間で新しいクローンを作成する必要がある場合、これを変更できます。同様に、「SCNの選択」オプションを選択して、SCNに同じ設定を実行できます。

3. 宛先データベースの定義セクションで、次を実行します。

- 表示名を指定します。

- グローバル・データベース名およびSIDを指定します。
データベースは、グローバル・データベース名で一意に識別されます。名前の一般的な形式は、name.domainです。データベースは、SIDで一意に識別される少なくとも1つのOracleインスタンスによって参照されます。

- 次のデータベース・タイプから1つ選択します。

- 単一インスタンス・データベース
「ホスト」セクションで、Oracleホームの場所を指定します。ホストはデフォルトで指定されます。次に、データベース・ホーム資格証明およびSYSASMのASM資格証明を選択します。

- RACデータベース
「ホスト」セクションで、クラスタ・ターゲットを指定または選択します。Oracleホームの場所は、デフォルトで指定されます。次に、データベース・ホスト資格証明およびSYSASMのASM資格証明を指定します。

「ノード」セクションで、クラスタおよびOracleホームを選択し、管理者の管理対象となるOracle RACデータベースが作成される1つ以上のホストを表示します。

- RAC One Nodeデータベース
「ホスト」セクションで、クラスタ・ターゲットを指定または選択します。Oracleホームの場所は、デフォルトで指定されます。次に、データベース・ホスト資格証明およびSYSASMのASM資格証明を指定します。

「ノード」セクションで、クラスタおよびOracleホームを選択し、管理者の管理対象となるOracle RACデータベースが作成される1つ以上のホストを表示します。

注意:
クローンの一部としてインライン・パッチ適用をサポートします。選択された宛先ホームに最新のCPUやPSUなどのパッチを適用する場合、クローニングされたデータベースはそのレベルで自動的に起動します。

「次へ」をクリックします。

4. 「フル・クローン・データベースの作成: 構成」ページで、次を実行します。

- 「データベース・ファイルの場所」で、データファイル、一時ファイル、REDOログ・ファイルおよび制御ファイルを作成する場所を指定します。「ファイル・システム」または「自動ストレージ管理(ASM)」を選択した後、データベース・ファイルに対して共通の場所を指定できます。
「Oracle Optimal Flexible Architecture (OFA)に準拠したディレクトリ構造を使用」オプションを使用すると、異なる場所を構成できます。

- アーカイブおよびREDOログ

- データ・ファイル

- 制御ファイル

- 一時ファイル

- 「リカバリ・ファイルの場所」で、アーカイブREDOログ、RMANバックアップ、その他の関連ファイルなどのリカバリ・ファイルを作成する場所を指定します。「高速リカバリ領域の使用」を選択して、高速領域リカバリを使用できます。その場合は、高速リカバリ領域サイズを指定します。高速リカバリ領域サイズのデフォルトはソースのサイズです。

- 「リスナー構成」セクションで、新しいOracleホームで実行されているリスナー・ターゲットを選択して、クローン・データベースを登録します。

- 「データベース資格証明」セクションで、クローン・データベースのSYS、SYSTEMおよびDBSNMP管理ユーザーのパスワードを指定します。3ユーザーすべてに同じパスワードを指定するか、ユーザーごとに異なるパスワードを指定するかを選択できます。

「次へ」をクリックします。

5. 「フル・クローン・データベースの作成: 構成」ページで、次を実行します。

- 「データベース・ファイルの場所」で、データファイル、一時ファイル、REDOログ・ファイルおよび制御ファイルを作成する場所を指定します。「ファイル・システム」または「自動ストレージ管理(ASM)」を選択した後、データベース・ファイルに対して共通の場所を指定できます。
「Oracle Optimal Flexible Architecture (OFA)に準拠したディレクトリ構造を使用」オプションを使用すると、異なる場所を構成できます。

- アーカイブおよびREDOログ

- データ・ファイル

- 制御ファイル

- 一時ファイル

- 「リカバリ・ファイルの場所」で、アーカイブREDOログ、RMANバックアップ、その他の関連ファイルなどのリカバリ・ファイルを作成する場所を指定します。「高速リカバリ領域の使用」を選択して、高速領域リカバリを使用できます。その場合は、高速リカバリ領域サイズを指定します。高速リカバリ領域サイズのデフォルトはソースのサイズです。

- 「リスナー構成」セクションで、新しいOracleホームで実行されているリスナー・ターゲットを選択して、クローン・データベースを登録します。

- 「データベース資格証明」セクションで、クローン・データベースのSYS、SYSTEMおよびDBSNMP管理ユーザーのパスワードを指定します。3ユーザーすべてに同じパスワードを指定するか、ユーザーごとに異なるパスワードを指定するかを選択できます。

「次へ」をクリックします。

6. フル・クローン・データベースの作成: 初期化パラメータ・ページで、データベース・インスタンスの操作に影響する様々な初期化パラメータの値を構成できます。パラメータの値を変更するには、そのパラメータを選択して「編集」をクリックします。

「次へ」をクリックします。

7. 「フル・クローン・データベースの作成: 後処理」ページで、次を指定します。

- マスキング定義 -- データ・マスキングは、テスト・データベースや本稼働していないデータベースの機密データをマスクするプロセスです。マスキング定義は、マスクされたデータの形式でマスクする列を定義します。データベースのクローニング後に適用するマスキング定義を指定します。

注意:
サブセット-マスキング・ライセンス・パックを保有している場合のみ、マスキング定義を使用できます。

- カスタム・スクリプト: データベースを作成する前後に実行が必要なカスタム・スクリプトを指定します。

- データ・プロファイルの作成: このオプションを使用すると、新しいクローニングされたインスタンスの作成後に自動的にバックアップを取得できます。クローンまたはテスト・マスターがリフレッシュされる場合、このセクションにはデータベースに作成された既存のプロファイルが表示されます。データベースとともにリフレッシュする必要があるプロファイルを選択できます。

- テスト・マスターとして作成: テスト・マスター・データベースとしてクローニングされたデータベースを作成する場合のオプション。

「次へ」をクリックします。

8. フル・クローン・データベースの作成: スケジュール・ページで、一意のデプロイメント・プロシージャ・インスタンス名を指定します。デプロイメント・プロシージャを即時起動するか、後で起動するかを選択できます。
「通知の詳細」セクションで、次の通知の設定を選択できます。

- スケジュール済

- 実行中

- アクション必須

- 一時停止中

- 成功

- 問題

「次へ」をクリックします。

9. フル・クローン・データベースの作成: 確認ページで、ソース・データベースの詳細、クローンのデータソース、および宛先データベースを確認します。
「送信」をクリックします。

14.1.2 EM CLIを使用したフル・クローン・データベースの作成

データベースのフル・クローンを作成するには、動詞emcli create_clone -input_file="location of file containing properties for creating the database cloneを実行します。

プロパティ・ファイルの例:

CLONE_TYPE=DUPLICATE
SRC_DB_TARGET_NAME=xxyy.us.example.com
SRC_DB_TARGET_TYPE=oracle_database
SRC_DB_CRED=NC_DB_CRED:SYSCO
SRC_HOST_NORMAL_NAMED_CRED=NC_HOST_CRED:SYSCO
COMMON_GLOBAL_DB_NAME=clonedb.example.com
COMMON_DB_SID=clonedb
DB_TARGET_NAME=clonedb.xxy.example.com
DATABASE_TYPE=dbTypeSI
TARGET_HOST_LIST=desthost.example.com
ORACLE_HOME_NAME=OraDB12Home2_29
ORACLE_HOME_LOC=/scratch/app/product/11.2.0./dbhome_1
ORACLE_BASE_LOC=/scratch/app/base
HOST_NORMAL_NAMED_CRED=NC_HOST_CRED2:SYSCO
DB_STORAGE_TYPE=FS
DB_FILE_LOC=/scratch/app/oradata
FRA_STORAGE_TYPE=FS
FLASH_REC_AREA=/scratch/user/app/fra
FRA_SIZE=4395
ARCHIVE_LOG_MODE=NO
DEST_LISTENER_SELECTION=DEST_DB_HOME
LISTENER_PORT=1526
ENABLE_LIVE_CLONE=true
DB_ADMIN_PASSWORD_SAME=true
DATABASE_PASSWORDS=right1
DB_TEMPLATE_STAGE=/tmp

データベース・クローン作成のステータスを確認するには、動詞emcli get_instance_status -instance={instance GUID}を実行します。

14.2 テスト・マスター・データベースの作成

テスト・マスター・データベースを作成するには、次のいずれかのソリューションを使用できます。

- クローン・ウィザードを使用したテスト・マスター・データベースの作成

- EM CLIを使用したテスト・マスター・データベースの作成

14.2.1 クローン・ウィザードを使用したテスト・マスター・データベースの作成

テスト・マスター・データベースとは、本番データベースのサニタイズされたバージョンです。テスト・マスターが作成される前に、オプションで本番データをマスキングできます。テスト・マスターは、前のポイント・イン・タイムで取得され、特定の間隔でリフレッシュされるスナップショットまたはRMANバックアップ・プロファイルから作成できます。このオプションは、ソース・データをマスクして機密データを隠す必要がある場合に便利です。

テスト・マスターを作成するには、次の手順に従います。

1. 「データベース」ページで、次のいずれかの方法でフル・クローン・データベース・ウィザードにアクセスできます。

- 表示されているデータベースのリストから、クローニングするデータベースを選択します。データベースのホームページで、「データベース」メニューをクリックし、「クローニング」→「テスト・マスターの作成」を選択します。

- データベース・ターゲット名を右クリックし、「データベース」→「クローニング」→「テスト・マスターの作成」を選択します。

- データベース・ターゲット名を右クリックし、「データベース」→「クローニング」→「クローンの管理」を選択します。「クローンの管理」ページの「テスト・マスター・データベース」ボックスで、「作成」をクリックします。

2. テスト・マスター・データベースの作成: ソースと宛先ページで、次の操作を実行します。

- 「ソース」セクションで、SYSDBAのデータベース資格証明とデータベース・ホスト資格証明の検索アイコンを選択して、資格証明セレクタを起動します。「OK」をクリックします。

- 「データ時系列」セクションで、「即時」または「前のポイント・イン・タイム」を選択します。
「即時」を選択した場合、SYSASMのASM資格証明を指定するか、検索して選択します。「現在」はライブ・クローンを参照します。

前の時点を選択した場合、「RMANバックアップ」イメージのカルーセルが表示されます。イメージで「選択」をクリックして、適切なRMANバックアップを選択します。

選択したバックアップまたはスナップショットと次のバックアップまたはスナップショット(あるいは最新の時点のソース)の間の時間を選択します。バックアップまたはダンプが特定の間隔で作成され、これらを基とするテスト・マスターには、特定時点の本番データベースが反映されます。本番データベースの最新データを反映するには、テスト・マスターを定期的にリフレッシュする必要があります。

3. 宛先データベースの定義セクションで、次を実行します。

- 表示名を指定します。

- グローバル・データベース名およびSIDを指定します。
データベースは、グローバル・データベース名で一意に識別されます。名前の一般的な形式は、name.domainです。データベースは、SIDで一意に識別される少なくとも1つのOracleインスタンスによって参照されます。

- 次のデータベース・タイプから1つ選択します。

- 単一インスタンス・データベース
「ホスト」セクションで、Oracleホームの場所を指定します。ホストはデフォルトで指定されます。次に、データベース・ホーム資格証明およびSYSASMのASM資格証明を選択します。

- RACデータベース
「ホスト」セクションで、クラスタ・ターゲットを指定または選択します。Oracleホームの場所は、デフォルトで指定されます。次に、データベース・ホスト資格証明およびSYSASMのASM資格証明を指定します。

「ノード」セクションで、クラスタおよびOracleホームを選択し、管理者の管理対象となるOracle RACデータベースが作成される1つ以上のホストを表示します。

- RAC One Nodeデータベース
「ホスト」セクションで、クラスタ・ターゲットを指定または選択します。Oracleホームの場所は、デフォルトで指定されます。次に、データベース・ホスト資格証明およびSYSASMのASM資格証明を指定します。

「ノード」セクションで、クラスタおよびOracleホームを選択し、管理者の管理対象となるOracle RACデータベースが作成される1つ以上のホストを表示します。

注意:
クローンの一部としてインライン・パッチ適用をサポートします。選択された宛先ホームに最新のCPUやPSUなどのパッチを適用する場合、クローニングされたデータベースはそのレベルで自動的に起動します。

「次へ」をクリックします。

4. 「テスト・マスター・データベースの作成: 構成」ページで、次の操作を実行します。

- データベース・ファイルの場所: データ・ファイル、一時ファイル、REDOログ・ファイルおよび制御ファイルが作成される場所を指定します。
次のいずれかを選択できます。

- ファイル・システム: Oracle Databaseのファイル・システムは、データベース表に格納されるファイルおよびディレクトリの標準ファイル・システム・インタフェースを作成します。このオプションを選択する場合、ファイル・システムの場所を指定するか選択する必要があります。すべてのファイルに共通の場所を指定することも、「Oracle Optimal Flexible Architecture (OFA)に準拠したディレクトリ構造を使用」チェック・ボックスを選択して、データ・ファイル、REDOログ・ファイルなどに別々の場所を指定することも可能です。

- 自動ストレージ管理: Oracle Automatic Storage Management (ASM)は、単一インスタンスおよびRAC構成をサポートするデータベース・ファイルのボリューム・マネージャおよびファイル・システムです。ASMでは、ストレージ・システム内のディスクを1つ以上のディスク・グループに分類します。ASMを選択した場合は、データベース・ファイルに共通の場所を選択してください。

- リカバリ・ファイルの場所: バックアップおよびリカバリ・ファイルの管理を簡略化するには、データベースに高速リカバリ領域を作成します。高速リカバリ領域にすることができるのは、バックアップおよびリカバリ・ファイル向けに一元化されたディスクの場所を提供するASMディスク・グループまたはファイル・システムです。セルフ・サービス・ユーザーがバックアップをスケジュールし、リストア操作を実行できるようにするには、「高速リカバリ領域の使用」チェック・ボックスを選択し、高速リカバリ領域および高速リカバリ・サイズの場所を指定します。高速リカバリ領域に割り当てるディスク領域の量は、データベースのサイズおよびアクティビティ・レベルによって異なります。

- リスナー構成: 「追加」をクリックして、新しいデータベースに関連付けるリスナー・ターゲットを1つ以上追加します。

- データベース資格証明: クローニングする新しいデータベースの管理ユーザー(SYS、SYSTEMおよびDBSNMP)のパスワードを指定します。すべてのスキーマに同じパスワードを使用するか、各スキーマに異なるパスワードを使用できます。

- 「次へ」をクリックします。

5. テスト・マスター・データベースの作成: 初期化パラメータ・ページで、データベース・インスタンスの操作に影響する様々な初期化パラメータの値を構成できます。
パラメータの値を変更するには、そのパラメータを選択して「編集」をクリックします。db_block_sizeなどの一部の値は変更できません。

「次へ」をクリックします。

6. 「テスト・マスター・プラガブル・データベースの作成: 後処理」ページの「データ・マスキング」セクションで、テスト・マスターPDBの作成後に適用するデータ・マスキング定義を指定します。データ・マスキングによって、データベース内の機密データがマスクされます。
データ・マスキング定義の作成方法の詳細は、『Oracle Data Masking and Subsettingガイド』を参照してください。データ・マスキング定義は、Subset-Maskingライセンス・パックを所有している場合にのみ適用できることに注意してください。

「カスタム・スクリプト」セクションの「前スクリプト」および「後スクリプト」で、テスト・マスターPDBの作成の前後に実行するスクリプトを含むOracleソフトウェア・ライブラリ・コンポーネントを指定します。また、「SQLスクリプト」で、テスト・マスターPDBの作成後に実行するSQLスクリプトを指定します。「実行ユーザー」で、SQLスクリプトの実行に使用するユーザー・アカウントを選択します。

「次へ」をクリックします。

7. 「テスト・マスター・データベースの作成: スケジュール」ページで、テスト・マスターの作成のスケジュールを指定します。すぐに作成することも(フィジカル・スタンバイを使用した場合は、すぐに作成されて、自動的にリフレッシュされます)、別の日/時間に作成して、指定した間隔でリフレッシュすることもできます。
「次へ」をクリックします。

8. 「テスト・マスター・データベースの作成: 確認」ページで、指定した情報をレビューして確認し、「発行」をクリックしてテスト・マスターを作成します。テスト・マスターが作成された後、必要に応じてテスト・マスターをリフレッシュして、テスト・マスターがベースとするプロファイルの新規バージョンを作成できます。

14.2.2 EM CLIを使用したテスト・マスター・データベースの作成

テスト・マスター・データベースを作成するには、動詞emcli create_clone -inputFile=/tmp/create_test_master.propsを実行します(create_test_master.propsは、テスト・マスターの作成に必要なパラメータと値が含まれたプロパティ・ファイルです)。

プロパティ・ファイルの例(create_test_master.props):

CLONE_TYPE=DUPLICATE
COMMON_DB_DBSNMP_PASSWORD=password
COMMON_DB_SID=clonedb
COMMON_DB_SYSTEM_PASSWORD=sunrise
COMMON_DB_SYS_PASSWORD=sunrise
DATABASE_PASSWORDS=Sumrise1
COMMON_GLOBAL_DB_NAME=clonedb.xyz.com
DB_ADMIN_PASSWORD_SAME=true
DEST_LISTENER_SELECTION=DEST_DB_HOME
HOST_NORMAL_NAMED_CRED=HOST:SYSCO
IS_TESTMASTER_DATABASE=Y
USAGE_MODE = testMaster
CLOUD_TARGET = true
LISTENER_PORT=1526
ORACLE_BASE_LOC=/scratch/app
ORACLE_HOME_LOC=/scratch/app/product/11.2.0./dbhome_1
EM_USER=sys
EM_PWD=Sunrise1
SRC_DB_CRED=DB:SYSCO
SRC_DB_TARGET_NAME=ora.xyz.com
SRC_HOST_NORMAL_NAMED_CRED=HOST:SYSCO
TARGET_HOST_LIST=bl1.xyz.com

テスト・マスター・データベース作成のステータスを確認するには、EM CLI動詞emcli get_instance_status -instance={instance GUI}を実行します。

14.3 フル・クローン・プラガブル・データベースの作成

フル・クローンPDBを作成するには、次のいずれかのソリューションを使用できます。

- クローン・ウィザードを使用したフル・クローン・プラガブル・データベースの作成

- EM CLIを使用したフル・クローン・プラガブル・データベースの作成

14.3.1 クローン・ウィザードを使用したフル・クローン・プラガブル・データベースの作成

Enterprise Manager for Oracle Database 12.1.0.8プラグインがシステムにデプロイされている場合は、新しいPDBのクローニング・ウィザードを使用してPDBのフル・クローンを作成できます。

フル・クローンPDBを作成するには、次の手順を実行します。

1. 「ターゲット」メニューから「データベース」を選択します。

2. 「表示」で、「検索リスト」を選択します。「表示」メニューから、「すべてを開く」を選択します。

3. リストでソースCDB (ソースPDBが含まれるCDB)を見つけ、クローニングするPDBの名前をクリックします。

4. 「Oracleデータベース」メニューから、「クローニング」→「フル・クローンの作成」を選択します。
別の方法として、手順3で、クローニングするPDBの名前を右クリックし、「Oracleデータベース」→「クローニング」→「フル・クローンの作成」を選択できます。

5. 「ソースと宛先: フル・クローン・プラガブル・データベースの作成」ページで、次の手順を実行します。

- ソースCDBのSYSDBA資格証明を指定します。優先資格証明を使用するか、名前付き資格証明の保存済セットを使用するか、資格証明の新規セットを指定するかを選択できます。

- 「プラガブル・データベース定義」セクションで、PDBクローンの名前と表示名を指定します。Enterprise Managerでは、PDBクローン・ターゲットの識別に表示名を使用します。

- 「PDB管理者資格証明」セクションで、PDBクローンの管理に使用する管理者ユーザー・アカウントの資格証明を指定します。

- ソースCDBとは異なるCDBにPDBをクローニングする場合、「プラガブル・データベースの異なるコンテナ・データベースへのクローニング」を選択し、宛先CDBを指定します。

- 「資格証明」セクションで、宛先CDBのホスト資格証明を指定します。ソースCDBとは異なるCDBにPDBをクローニングする場合、宛先CDBのSYSDBA資格証明を指定します。また、宛先CDBで自動ストレージ管理(ASM)を使用してディスク・ストレージを管理している場合、ASM資格証明を指定する必要があります。

6. これ以上詳細を指定する必要がなければ、「クローン」をクリックします。これにより、パブリック・クラウド設定にデプロイされたCDBにPDBをクローニングするためのデプロイメント・プロシージャが発行されます。
他の構成詳細の指定やデータのマスキング、クローニング・プロセスのスケジュールを行う場合は、「拡張」をクリックします。

「拡張」オプションを選択した場合は、それ以降の手順に従います。各ページにクローニングのためのオプションがあります。

7. 「フル・クローン・プラガブル・データベースの作成: ソースと宛先」ページで、詳細を確認して「次へ」をクリックします。

8. 「フル・クローン・プラガブル・データベースの作成: 構成」ページで、次の操作を実行します。

- 「データベース・ファイルの場所」セクションで、PDBクローンのデータファイルを格納する記憶域の場所を指定します。宛先CDBでASMを使用してディスク・ストレージを管理している場合、PDBクローンのデータファイルを格納するディスク・グループを指定します。

- ソースPDBのデータ・モデル定義のみをクローニングし、ソースPDBデータはクローニングしない場合、「ユーザー・データの除外」を選択します。

- 「拡張構成」セクションで、PDBクローンの最大サイズの記憶域制限と、PDBクローン内の共有表領域の最大サイズを指定します。デフォルトでは、これらの属性の値に制限はありません。

- 「その他」セクションで、PDBクローン内に作成される表領域に対して使用するロギング・オプションを選択します。

「次へ」をクリックします。

9. 「フル・クローン・プラガブル・データベースの作成: 後処理」ページで、次の操作を実行します。

- 「データ・マスキング」セクションで、PDBのクローニング後に適用するデータ・マスキング定義を指定します。データ・マスキングによって、データベース内の機密データがマスクされます。
データ・マスキング定義の作成方法の詳細は、『Oracle Data Masking and Subsettingガイド』を参照してください。データ・マスキング定義は、Subset-Maskingライセンス・パックを所有している場合にのみ適用できることに注意してください。

- 「カスタム・スクリプト」セクションの「前スクリプト」および「後スクリプト」で、PDBのクローニングの前後に実行するスクリプトを含むOracleソフトウェア・ライブラリ・コンポーネントを指定します。また、「SQLスクリプト」で、PDBのクローニング後に実行するSQLスクリプトを指定します。「実行ユーザー」で、SQLスクリプトの実行に使用するユーザー・アカウントを選択します。
「次へ」をクリックします。

10. 「フル・クローン・プラガブル・データベースの作成: スケジュール」ページで、クローニングのデプロイメント・プロシージャのインスタンス名を指定します。また、クローニング・プロシージャを開始する時点を指定します。
「通知」セクションで、電子メール通知を受信するデプロイメント・プロシージャの状態を選択します。たとえば、「通知のステータス」で「スケジュール済」および「成功」を選択すると、クローニング・デプロイメント・プロシージャがスケジュールされたときと、それが成功したときに電子メール通知を受信できます。

「次へ」をクリックします。

11. 「フル・クローン・プラガブル・データベースの作成: 確認」ページで、入力したすべての詳細を確認します。特定の詳細を編集する場合、「戻る」をクリックして必要なページに移動します。
「クローン」をクリックしてデプロイメント・プロシージャを発行し、ソースPDBのフル・クローンを作成します。

14.3.2 EM CLIを使用したフル・クローン・プラガブル・データベースの作成

プラガブル・データベースのフル・クローンを作成するには、動詞emcli pdb_clone_management -input_file=data:/xyz/sdf/pdb_clone.propsを実行します(pdb_clone.propsはプロパティ・ファイルです)。

プロパティ・ファイルの例(pdb_clone.props):

SRC_PDB_TARGET=cdb_prod_PDB
SRC_HOST_CREDS=NC_HOST_SCY:SYCO
SRC_CDB_CREDS=NC_HOST_SYC:SYCO
SRC_WORK_DIR=/tmp/source
DEST_HOST_CREDS=NC_SLCO_SSH:SYS
DEST_LOCATION=/scratch/sray/app/sray/cdb_tm/HR_TM_PDB6
DEST_CDB_TARGET=cdb_tm
DEST_CDB_TYPE=oracle_database
DEST_CDB_CREDS=NC_HOST_SYC:SYCO
DEST_PDB_NAME=HR_TM_PDB6

注意:
宛先PDBとソースPDBが異なるCDB内にあり、両方のCDBがOracle Cloud上にある場合、ソースPDBが読取り/書込みモードになっていることを確認してください。PDBをクローニングするためにデータベース・リンクが宛先CDBに作成され、そのデータベース・リンクを使用するために一時ユーザーがソースPDBに作成されるために、これが必要となります。宛先CDBに、ソースPDBと接続する既存のデータベース・リンクがある場合は、プロパティ・ファイル内でパラメータEXISTING_DB_LINK_NAMEを使用してデータベース・リンク名を指定します。

14.4 テスト・マスター・プラガブル・データベースの作成

テスト・マスターPDBを作成するには、次のいずれかのソリューションを使用できます。

- クローン・ウィザードを使用したテスト・マスター・プラガブル・データベースの作成

- EM CLIを使用したテスト・マスター・プラガブル・データベースの作成

14.4.1 クローン・ウィザードを使用したテスト・マスター・プラガブル・データベースの作成

Enterprise Manager for Oracle Database 12.1.0.8プラグインがシステムにデプロイされている場合は、新しいPDBのクローニング・ウィザードを使用して、ソースPDBからテスト・マスターPDBを作成できます。

ソースPDBからテスト・マスターPDBを作成するには、次の手順を実行します。

1. 「ターゲット」メニューから「データベース」を選択します。

2. 「表示」で、「検索リスト」を選択します。「表示」メニューから、「すべてを開く」を選択します。

3. リストでソースCDB (ソースPDBが含まれるCDB)を見つけ、テスト・マスターPDBの作成元にするPDBの名前をクリックします。

4. 「Oracleデータベース」メニューから、「クローニング」→「テスト・マスターの作成」を選択します。
別の方法として、手順3で、テスト・マスターPDBの作成元にするPDBの名前を右クリックし、「Oracleデータベース」→「クローニング」→「テスト・マスターの作成」を選択できます。

5. 「テスト・マスター・データベースの作成: ソースと宛先」ページで、次の操作を実行します。

- ソースCDBのSYSDBA資格証明を指定します。優先資格証明を使用するか、名前付き資格証明の保存済セットを使用するか、資格証明の新規セットを指定するかを選択できます。

- 「プラガブル・データベース定義」セクションで、テスト・マスターPDBの名前と表示名を指定します。Enterprise Managerでは、テスト・マスターPDBターゲットの識別に表示名を使用します。

- 「PDB管理者資格証明」セクションで、テスト・マスターPDBの管理に使用する管理者ユーザー・アカウントの資格証明を指定します。

- 「コンテナ・データベース」セクションで、宛先CDB (テスト・マスターPDBを含む必要のあるCDB)を指定します。

- 「資格証明」セクションで、宛先CDBのSYSDBA資格証明と、宛先CDBのホスト資格証明を指定します。また、宛先CDBで自動ストレージ管理(ASM)を使用してディスク・ストレージを管理している場合、ASM資格証明を指定する必要があります。
「次へ」をクリックします。

6. 「テスト・マスター・プラガブル・データベースの作成: 構成」ページで、次の操作を実行します。
「データベース・ファイルの場所」セクションで、テスト・マスターPDBのデータファイルを格納する記憶域の場所を指定します。宛先CDBでASMを使用してディスク・ストレージを管理している場合、テスト・マスターPDBのデータファイルを格納するディスク・グループを指定します。

ソースPDBのデータ・モデル定義のみをクローニングし、ソースPDBデータはクローニングしない場合、「ユーザー・データの除外」を選択します。

「PDB管理者資格証明」セクションで、テスト・マスターPDBの管理に使用する管理者ユーザー・アカウントの資格証明を指定します。

「拡張構成」セクションで、テスト・マスターPDBの最大サイズの記憶域制限と、テスト・マスターPDB内の共有表領域の最大サイズを指定します。デフォルトでは、これらの属性の値に制限はありません。「その他」セクションで、テスト・マスターPDB内に作成される表領域に対して使用するロギング・オプションを選択します。

宛先CDBがExadataマシンの一部である場合、「拡張構成」セクションのかわりに「アクセス制御および権限」セクションが表示されることに注意してください。この場合、データファイルに対する読取り専用権限を付与する必要がある所有者およびグループを指定する必要があります。

「次へ」をクリックします。

7. 「テスト・マスター・プラガブル・データベースの作成: 後処理」ページの「データ・マスキング」セクションで、テスト・マスターPDBの作成後に適用するデータ・マスキング定義を指定します。データ・マスキングによって、データベース内の機密データがマスクされます。
データ・マスキング定義の作成方法の詳細は、『Oracle Data Masking and Subsettingガイド』を参照してください。データ・マスキング定義は、Subset-Maskingライセンス・パックを所有している場合にのみ適用できることに注意してください。

「カスタム・スクリプト」セクションの「前スクリプト」および「後スクリプト」で、テスト・マスターPDBの作成の前後に実行するスクリプトを含むOracleソフトウェア・ライブラリ・コンポーネントを指定します。また、「SQLスクリプト」で、テスト・マスターPDBの作成後に実行するSQLスクリプトを指定します。「実行ユーザー」で、SQLスクリプトの実行に使用するユーザー・アカウントを選択します。

「次へ」をクリックします。

8. デプロイメント・プロシージャのインスタンス名を指定します。また、デプロイメント・プロシージャを開始する時点を指定します。
「通知」セクションで、電子メール通知を受信するデプロイメント・プロシージャの状態を選択します。たとえば、「通知のステータス」で「スケジュール済」および「成功」を選択すると、デプロイメント・プロシージャがスケジュールされたときと、それが成功したときに電子メール通知を受信できます。

「次へ」をクリックします。

9. 指定したすべての詳細を確認します。特定の詳細を編集する場合、「戻る」をクリックして必要なページに移動します。
「クローン」をクリックして、ソースPDBからテスト・マスターPDBを作成するデプロイメント・プロシージャを発行します。

14.4.2 EM CLIを使用したテスト・マスター・プラガブル・データベースの作成

テスト・マスター・プラガブル・データベースを作成するには、コマンドemcli pdb_clone_management -input_file=data:/xyz/sdf/pdb_test_master.propsを実行します(pdb_test_master.propsファイルの内容の例を次に示します)。

テスト・マスターPDBを作成するためのプロパティ・ファイルの例:

SRC_PDB_TARGET=cdb_prod_PDB
SRC_HOST_CREDS=NC_HOST_SCY:SYCO
SRC_CDB_CREDS=NC_HOST_SYC:SYCO
SRC_WORK_DIR=/tmp/source
DEST_HOST_CREDS=NC_SLCO_SSH:SYS
DEST_LOCATION=/scratch/sray/app/sray/cdb_tm/HR_TM_PDB6
DEST_CDB_TARGET=cdb_tm
DEST_CDB_TYPE=oracle_database
DEST_CDB_CREDS=NC_HOST_SYC:SYCO
DEST_PDB_NAME=HR_TM_PDB6
IS_CREATE_AS_TESTMASTER=true
MASKING_DEFINITION_NAME=CRM_Masking_Defn

注意:
Exadata ASMにテスト・マスターを作成する必要がある場合は、さらに2つのパラメータ(ACL_DF_OWNER=oracleおよびACL_DF_GROUP=oinstall)を追加する必要があります。

14.5 クラシック・クローニング・ウィザードを使用したデータベースのクローニング

古いクローニング・ウィザードを使用して、データベースをクローニングできます。この項の内容は次のとおりです。

- クラシック・クローニング・メソッドの概要

- Recovery Manager (RMAN)バックアップを使用したOracle Databaseのクローニング

- ステージング領域を使用したOracle Databaseのクローニング

- 既存のバックアップを使用したOracle Databaseのクローニング

14.5.1 クラシック・クローニング・メソッドの概要

Enterprise Managerのクローン・データベース・ウィザードを使用して、Oracle Databaseインスタンスを既存のOracleホームにクローニングできます。既知の状態のOracleデータベース・インスタンス(たとえば、構成、チューニングおよびテスト済のOracleデータベース・インスタンス)が存在する場合、そのデータベースを他の既存のOracleホームにクローニングできます。

次の表に、クローニング・メソッドおよびクローニング・プロセスを示します。

表14-1 Oracle Databaseのクローニング・メソッド

クローニング・メソッド

クローニング・プロセス

Recovery Manager (RMAN)バックアップを使用したOracle Databaseのクローニング

- ソースおよび宛先のOracleインスタンスを接続する

- RMANの複製機能を使用してデータベース・ファイルをコピーする

- クローニングしたデータベースをリカバリして開く

ステージング領域を使用したOracle Databaseのクローニング

- 各データベース・ファイルをバックアップして、そのファイルをステージング領域に格納する

- ソースから宛先に各バックアップ・ファイルを転送する

- 各バックアップ・ファイルを指定した場所にリストアする

- クローニングしたデータベースをリカバリして開く

既存のバックアップを使用したOracle Databaseのクローニング

- 指定したポイント・イン・タイムまたはSCN時点でクローニングしたデータベースを作成する

- クローン操作以前のバックアップを検証する

- 必要なアーカイブREDOログ・ファイルを宛先ホストに転送する

- クローニングしたデータベースをリカバリして開く

14.5.2 Recovery Manager (RMAN)バックアップを使用したOracle Databaseのクローニング

RMANバックアップを使用してOracle Databaseをクローニングするには、次の手順を実行します。

1. 「ターゲット」メニューから「データベース」を選択します。

2. 「データベース」ページで、クローニングするデータベースを選択します。

3. 「データベース・ターゲット」ページで、「Oracle Database」メニューから「プロビジョニング」を選択して、データベースのクローニングおよびリフレッシュをクリックします。

4. 「クローンおよびリフレッシュ」ページで、クラシック・クローンに切替えリンクをクリックします。

5. 「データベース・ログイン」ページで、資格証明を入力します。「ログイン」をクリックします。
データベースのクローニング・ウィザードが開きます。

6. 「クローン・データベース: ソース・タイプ」ページで、「オンライン・バックアップ」および「Recovery Manager (RMAN)を使用してデータベース・ファイルをコピーします」を選択します。
「続行」をクリックします。

注意:
RMANバックアップを使用してデータベースをクローニングする場合は、指定された宛先Oracleホームにソース・データベースが直接複製されます。ステージング領域は必要ありません。

7. 「クローン・データベース: ソース・オプション」ページの「並列度」ボックスに、RMANがデータベース・ファイルをコピーするのに使用するパラレル・チャネルの数を入力します。デフォルトの桁数は2です。

注意:
ネットワーク帯域幅が十分に使用できる場合は、並列度を増加させると処理速度が向上する可能性があります。

8. 「ソース・ホスト資格証明」セクションで、ソース・データベースのOracleサーバー・インストールを所有するユーザーの資格証明を入力します。「名前付き」資格証明または「新規」資格証明のいずれかを選択できます。
「新規」資格証明を選択した場合は、ユーザー名とパスワードを入力します。再度これらの資格証明のセットを使用する場合は、「優先資格証明として設定」チェックボックスを選択できます。資格証明が有効であるかどうかを確認するには、「テスト」をクリックします。

「次へ」をクリックします。

9. 「クローン・データベース: 接続先の選択」ページの「接続先Oracleホーム」セクションで、「検索」アイコンをクリックします。

注意:
指定されたホストにOracleホームが存在し、ソース・データベースのバージョンと一致している必要があります。

表示された「接続先Oracleホーム」ページで、接続先Oracleホームを検索して選択します。「次へ」をクリックします。

10. 「接続先ホスト資格証明」セクションで、「接続先Oracleホーム」セクションで指定したOracleホームを所有するユーザーの資格証明を入力します。

11. 「接続先データベース」セクションで、次の手順を実行して、グローバル・データベース名、インスタンス名およびデータベース・ストレージとして選択するファイル・システムを指定します。「次へ」をクリックします。

- グローバル・データベース名を指定します。
たとえば、clone1.example.comなどです

- 一意のインスタンス名を指定します。
たとえば、clone1などになります。

- データベース・ストレージとして「ファイル・システム」を選択します。

- 「次へ」をクリックします。

12. 「クローン・データベース: 接続先オプション」ページで、「データベース領域および高速リカバリ領域の使用」を選択します。
「次へ」をクリックします。

13. 「クローン・データベース: データベース構成」ページの「リスナー構成」セクションで、クローニングされたデータベースで使用するリスナーの名前とポートを指定します。既存のリスナーが使用していない新しい名前とポートを指定すると、指定したポートを使用する新しいリスナーが作成されます。
「データベース登録」セクションで、「クローン・データベースをユーザーDBSNMPが監視するEnterprise Managerターゲットとして登録」を選択します。ターゲット・データベースの名前を入力します。

「次へ」をクリックします。

14. 「クローン・データベース: スケジュール」ページで、クローン・ジョブ用の名前の説明を指定します。クローン・ジョブをすぐに実行するか、または後でジョブを実行する日時を指定できます。
「次へ」をクリックします。

15. 「クローン・データベース: 確認」ページで、ソース・データベースの詳細と構成、接続先データベースおよびデータベース・ストレージを確認します。データベース・ストレージ・ファイルを表示するには、「ソース・データベース・ファイルの表示」をクリックします。
「ジョブの発行」をクリックします。T

これで、クローン・データベース・ジョブが発行されています。ジョブが完了すると、「クローン・データベース: 確認」ページが表示されます。ジョブのステータスを表示するには、「ステータスの表示」をクリックします。ページを終了するには、「OK」をクリックします。

14.5.3 ステージング領域を使用したOracle Databaseのクローニング

ステージング領域を介してデータベース・ファイルをコピーすることによりOracle Databaseをクローニングするには、次の手順を実行します。

1. 「ターゲット」メニューから「データベース」を選択します。

2. 「データベース」ページで、クローニングするデータベースを選択します。

3. 「データベース・ターゲット」ページで、「Oracle Database」メニューから「プロビジョニング」を選択して、「データベースのクローニング」をクリックします。

4. 「クローンおよびリフレッシュ」ページで、クラシック・クローンに切替えリンクをクリックします。

5. 「データベース・ログイン」ページで、資格証明を入力します。「ログイン」をクリックします。
データベースのクローニング・ウィザードが開きます。

6. 「クローン・データベース: ソース・タイプ」ページで、「オンライン・バックアップ」および「ステージング領域を介してデータベース・ファイルをコピー」を選択します。
「続行」をクリックします。

注意:
このメソッドでは、ソースと宛先の両方のホストでステージング領域が必要になります。

7. 「クローン・データベース: ソース・オプション」ページの「ステージング領域」セクションで、「ステージング領域の場所」を入力します。

注意:
実行中のデータベースをクローニングするには、ソース・ホスト上でステージング領域が必要になります。データベースのバックアップが実行され、バックアップ・ファイルがステージング領域に保存されます。

8. クローニング操作後に、ステージング領域を削除または保持するよう選択できます。
クローニング操作後にステージング領域を保持すると、後で別のバックアップが実行されなくなります。ただし、この操作を実行するには、最低2230 MBのディスク領域が必要です。

9. 「ソース・ホスト資格証明」セクションで、ソース・データベースのOracleサーバー・インストールを所有するユーザーの資格証明を入力します。「名前付き」資格証明または「新規」資格証明のいずれかを選択できます。
「新規」資格証明を選択した場合は、ユーザー名とパスワードを入力します。再度これらの資格証明のセットを使用する場合は、「優先資格証明として設定」チェックボックスを選択できます。資格証明が有効であるかどうかを確認するには、「テスト」をクリックします。

「次へ」をクリックします。

10. 「クローン・データベース: 接続先の選択」ページの「接続先Oracleホーム」セクションで、「検索」アイコンをクリックします。

注意:
指定されたホストにOracleホームが存在し、ソース・データベースのバージョンと一致している必要があります。

表示された「接続先Oracleホーム」ページで、接続先Oracleホームを検索して選択します。「次へ」をクリックします。

11. 「接続先ホスト資格証明」セクションで、「接続先Oracleホーム」セクションで指定したOracleホームを所有するユーザーの資格証明を入力します。

12. 「接続先データベース」セクションで、次の手順を実行して、グローバル・データベース名、インスタンス名およびデータベース・ストレージとして選択するファイル・システムを指定します。「次へ」をクリックします。

- グローバル・データベース名を指定します。
たとえば、clone1.example.comなどです

- 一意のインスタンス名を指定します。
たとえば、clone1などになります。

- データベース・ストレージとして「ファイル・システム」を選択します。

- 「次へ」をクリックします。

13. 「クローン・データベース: 接続先オプション」ページで、「データベース領域および高速リカバリ領域の使用」を選択します。
「次へ」をクリックします。

14. 「クローン・データベース: データベース構成」ページの「リスナー構成」セクションで、クローニングされたデータベースで使用するリスナーの名前とポートを指定します。既存のリスナーが使用していない新しい名前とポートを指定すると、指定したポートを使用する新しいリスナーが作成されます。
「データベース登録」セクションで、「クローン・データベースをユーザーDBSNMPが監視するEnterprise Managerターゲットとして登録」を選択します。ターゲット・データベースの名前を入力します。

「次へ」をクリックします。

15. 「クローン・データベース: スケジュール」ページで、クローン・ジョブ用の名前の説明を指定します。クローン・ジョブをすぐに実行するか、または後でジョブを実行する日時を指定できます。
「次へ」をクリックします。

16. 「クローン・データベース: 確認」ページで、ソース・データベースの詳細と構成、接続先データベースおよびデータベース・ストレージを確認します。データベース・ストレージ・ファイルを表示するには、「ソース・データベース・ファイルの表示」をクリックします。
「ジョブの発行」をクリックします。T

これで、クローン・データベース・ジョブが発行されています。ジョブが完了すると、「クローン・データベース: 確認」ページが表示されます。ジョブのステータスを表示するには、「ステータスの表示」をクリックします。ページを終了するには、「OK」をクリックします。

14.5.4 既存のバックアップを使用したOracle Databaseのクローニング

既存のバックアップを使用してOracle Databaseをクローニングするには、次の手順を実行します。

1. 「ターゲット」メニューから「データベース」を選択します。

2. 「データベース」ページで、クローニングするデータベースを選択します。

3. 「データベース・ターゲット」ページで、「Oracle Database」メニューから「プロビジョニング」を選択して、「データベースのクローニング」をクリックします。

4. 「クローンおよびリフレッシュ」ページで、クラシック・クローンに切替えリンクをクリックします。

5. 「データベース・ログイン」ページで、資格証明を入力します。「ログイン」をクリックします。
データベースのクローニング・ウィザードが開きます。

6. 「クローン・データベース: ソース・タイプ」ページで、「既存のバックアップ」を選択します。
「続行」をクリックします。

7. 「データベースのクローニング: ソース・ホスト資格証明」ページで、使用するバックアップを選択します。

8. 「ソース・ホスト資格証明」セクションで、ソース・データベースのOracleサーバー・インストールを所有するユーザーの資格証明を入力します。「優先」、「名前付き」または「新規」のいずれかの資格証明を選択できます。
「新規」資格証明を選択した場合は、ユーザー名とパスワードを入力します。再度これらの資格証明のセットを使用する場合は、「優先資格証明として設定」チェックボックスを選択できます。資格証明が有効であるかどうかを確認するには、「テスト」をクリックします。

「次へ」をクリックします。

9. 「データベースのクローニング: バックアップ詳細」ページの「時点」セクションで、時間またはシステム変更番号(SCN)を指定します。これにより、クローン・データベースを作成するのに必要なバックアップが識別できます。

注意:
必要なアーカイブ・ログが既存のバックアップにすべて存在するとは限らない場合、Enterprise Managerはクローン操作の一部として、ソース・ホストから宛先ホストにそのログを転送します。

10. Oracle Databaseバックアップは、データベース・ウォレット、パスワード、またはその両方を使用して暗号化できます。バックアップが暗号化されている場合は、必要に応じて、「暗号化」セクションで暗号化モードおよびパスワードを指定します。デフォルトでは、暗号化モードは「なし」に設定されています。
「次へ」をクリックします。

11. 「接続先ホスト資格証明」セクションで、「接続先Oracleホーム」セクションで指定したOracleホームを所有するユーザーの資格証明を入力します。

12. 「接続先データベース」セクションで、次の手順を実行して、グローバル・データベース名、インスタンス名およびデータベース・ストレージとして選択するファイル・システムを指定します。「次へ」をクリックします。

- グローバル・データベース名を指定します。
たとえば、clone1.example.comなどです

- 一意のインスタンス名を指定します。
たとえば、clone1などになります。

- データベース・ストレージとして「ファイル・システム」を選択します。

13. 「並列性」セクションの「並列度」ボックスに、RMANがデータベース・ファイルをコピーするのに使用するパラレル・チャネルの数を入力します。デフォルトの桁数は2です。

注意:
ネットワーク帯域幅が十分に使用できる場合は、並列度を増加させると処理速度が向上する可能性があります。

「次へ」をクリックします。

14. 「データベースのクローニング: 接続先データベースの設定」ページの「メモリー・パラメータ」セクションで、「メモリー管理の構成」を選択し、ドロップダウン・リストから「自動共有メモリー管理」を選択します。
データベースでは、システム・グローバル領域(SGA)コンポーネント間の最適なメモリー配分が自動的に設定されます。このメモリー配分は、ワークロードの変化に対応するために時々変化します。さらに、集計プログラム・グローバル領域(PGA)のサイズを指定します。

15. 「リスナー構成」セクションで、データベース用に構成されるリスナーの名前とポートを指定します。指定したリスナーが接続先Oracleホームに存在しない場合は、そのリスナーが作成されます。

注意:
クローニングされたデータベースRACを後の時点で変換する場合は、クラスタ内のすべてのホスト間で共有されるストレージの場所を指定することをお薦めします。

16. 「リカバリ・ファイル」セクションで、アーカイブREDOログ・ファイル、RMANバックアップなどのリカバリ関連のファイルを作成する場所を指定します。
「次へ」をクリックします。

17. 「データベースのクローニング: 記憶域の場所」ページの「データベース・ファイルの場所」セクションで、データ・ファイル、一時ファイル、REDOログ・ファイルおよび制御ファイルが作成される場所を指定します。
「データベース登録」セクションで、「クローン・データベースをユーザーDBSNMPが監視するEnterprise Managerターゲットとして登録」を選択します。ターゲット・データベースの名前を入力します。

「次へ」をクリックします。

18. 「クローン・データベース: スケジュール」ページで、クローン・ジョブ用の名前の説明を指定します。クローン・ジョブをすぐに実行するか、または後でジョブを実行する日時を指定できます。
「次へ」をクリックします。

19. 「クローン・データベース: 確認」ページで、ソース・データベースの詳細と構成、接続先データベースおよびデータベース・ストレージを確認します。データベース・ストレージ・ファイルを表示するには、「ソース・データベース・ファイルの表示」をクリックします。
「ジョブの発行」をクリックします。T

これで、クローン・データベース・ジョブが発行されています。ジョブが完了すると、「クローン・データベース: 確認」ページが表示されます。ジョブのステータスを表示するには、「ステータスの表示」をクリックします。ページを終了するには、「OK」をクリックします。

15 Hybrid Cloud (Oracle PaaS)でのクローニング・ソリューション

この章の構成は、次のとおりです。

- Oracle PaaSでのクローニングの概要

- Hybrid Cloudユースケースでのクローニング

- Oracle PaaSでのクローニングの前提条件

- Oracle Cloudへのクローニング

- Oracle Cloudからのクローニング

- Oracle Cloud内でのクローニング

15.1 Oracle PaaSでのクローニングの概要

企業のITインフラストラクチャの管理中、オンプレミスで格納されたデータをOracle Cloudアプリケーションで使用および分析する場合があります。このような場合、オンプレミスで格納されたデータをOracle Cloudに移行する必要があることがあります。Enterprise Manager Cloud Control (Cloud Control) 12cリリース5 (12.1.0.5)には、この機能が用意されています。

Cloud Control 12.1.0.5によりHybrid Cloud管理が導入されるため、Enterprise Manager Command Line Interface (EM CLI)を使用して、オンプレミスのCloud Controlインスタンスを使用して特定のOracle Cloudターゲットを監視できるようになります。また、Hybrid Cloud管理を活用する新しいPDBのクローニング・ウィザードが導入されるため、オンプレミスのPDBをOracle CloudにデプロイされたCDBにクローニングできます。これによって、オンプレミス・データをOracle Public Cloudにコピーまたは移行できます。

また、Oracle Cloud内でのPDBのクローニングと同様に、PDBのクローニング・ウィザードまたはEM CLIを使用して、Oracle CloudにデプロイされたPDBをオンプレミスでデプロイされたCDBにクローニングすることもできます。

オンプレミスのPDBまたはスキーマをクローニングすると、そのコピーが作成され、Hybrid Cloud GatewayまたはOracle CloudへのSSH接続が可能な他のホストを介してデータが転送されます。その後、セキュアなコピーを使用してOracle CloudにPDBまたはデータベースが作成されます。

Oracleでは、クローンの一部としてインライン・パッチ適用をサポートしています。選択された宛先ホームに、最新のCPUやPSUなどのパッチが適用されている場合、クローニングされたデータベースはそのレベルで自動的に起動します。

15.2 Hybrid Cloudユースケースでのクローニング

次の表に、Hybrid Cloudでのクローニングに対応するユースケースを示します。

表15-1 Hybrid Cloudユースケースでのクローニング

クローニングのユースケース

クローニングのソリューション

Oracle Cloudへのクローニング

- Oracle CloudへのPDBのクローニング

- Oracle CloudのDBまたはPDBへのスキーマのクローニング

- Oracle CloudのDBまたはPDBへのDBのクローニング

Oracle Cloudからのクローニング

- Oracle CloudからのPDBのクローニング

- Oracle CloudからDBまたはPDBへのスキーマのクローニング

- Oracle CloudからDBまたはPDBへのDBのクローニング

Oracle Cloud内でのクローニング

- Oracle PaaS内でのPDBのクローニング

- Oracle PaaS内でのDBのクローニング

15.3 Oracle PaaSでのクローニングの前提条件

オンプレミスPDBをOracle CloudにデプロイされたCDB (つまり、宛先CDB)にクローニングするための前提条件は、次のとおりです。

- オンプレミスCloud Controlインスタンスは、バージョン12cリリース5 (12.1.0.5)である必要があります。

- 宛先CDBホスト(宛先CDBがデプロイされているホスト)に管理エージェントがデプロイされている必要があります。また、宛先CDBターゲットを検出する必要もあります。
管理エージェントをOracle Cloudターゲットにデプロイする方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

- クローニングがサポートされるのは、Oracleソフトウェア・ライブラリがOMSエージェント・ストレージ・タイプのアップロード場所で構成されていない場合のみです。

- Oracle Cloudとのやり取りで、またはOracle Cloud内部で、テスト・マスター・データベースまたはテスト・マスター・プラガブル・データベースを使用することをお薦めします。
テスト・マスター・データベースを作成するには、14.2項「テスト・マスター・データベースの作成」を参照してください。

テスト・マスター・プラガブル・データベースを作成するには、14.4項「テスト・マスター・プラガブル・データベースの作成」を参照してください。

- オンプレミスPDBとOracle CloudのPDBは暗号化されておらず、同じ文字セットを所有し、同じパッチ・セット・レベルを持つ必要があります。

- オンプレミスのPDB、データベースおよびスキーマがASM上にあり、Oracle CloudのPDB、データベースおよびスキーマはファイルシステム上に存在する必要があります。

- SSH認証がーゲット・データベース・ホストで可能です。SSH認証を構成するには、次のURLを参照してください。
http://docs.oracle.com/cd/E24628_01/doc.121/e36415/sec_features.htm#EMSEC12868">>http://docs.oracle.com/cd/E24628_01/doc.121/e36415/sec_features.htm#EMSEC12868

15.4 Oracle Cloudへのクローニング

データベース、スキーマまたはプラガブル・データベースをオンプレミスからOracle Cloudにクローニングする場合は、次のユースケースを参照してください。

- Oracle CloudへのPDBのクローニング

- Oracle CloudのDBまたはPDBへのスキーマのクローニング

- Oracle CloudのDBまたはPDBへのDBのクローニング

15.4.1 Oracle CloudへのPDBのクローニング

オンプレミスPDBをOracle CloudのPDBにクローニングするには、次のいずれかのソリューションを使用できます。

- クローン・ウィザードを使用したOracle CloudへのPDBのクローニング

- EM CLIを使用したOracle CloudへのPDBのクローニング

15.4.1.1 クローン・ウィザードを使用したOracle CloudへのPDBのクローニング

PDBをOracle CloudにデプロイされたCDBにクローニングするには、次の手順を実行します。

1. 「ターゲット」メニューから「データベース」を選択します。

2. 「表示」で、「検索リスト」を選択します。「表示」メニューから、「すべてを開く」を選択します。

3. リストでソースCDB (ソースPDBが含まれるCDB)を見つけ、クローニングするPDBの名前をクリックします。

4. 「Oracleデータベース」メニューから、「クローニング」→「Oracle Cloudへのクローン作成」を選択します。
別の方法として、手順3で、クローニングするPDBの名前を右クリックし、「Oracleデータベース」→「クローニング」→「Oracle Cloudへのクローン作成」を選択できます。

5. 「ソースと宛先: Oracle Cloudへのクローン作成」ページで、次の手順を実行します。

- 「資格証明」セクションで、ソースCDBのSYSDBA資格証明と、ソースCDBのホスト資格証明を指定します。優先資格証明を使用するか、名前付き資格証明の保存済セットを使用するか、資格証明の新規セットを指定するかを選択できます。

- 「プラガブル・データベース定義」セクションで、PDBクローンの名前と表示名を指定します。Enterprise Managerでは、PDBクローン・ターゲットの識別に表示名を使用します。

- 「PDB管理者資格証明」セクションで、PDBクローンの管理に使用する管理者ユーザー・アカウントの資格証明を指定します。

- 「コンテナ・データベース」セクションで、Oracle Cloudにデプロイされた宛先CDB (PDBクローンを含む必要のあるCDB)を指定します。

- 「資格証明」セクションで、宛先CDBのSYSDBA資格証明と、宛先CDBのホスト資格証明を指定します。

6. これ以上詳細を指定する必要がなければ、「クローン」をクリックします。これにより、Oracle CloudにデプロイされたCDBにPDBをクローニングするためのデプロイメント・プロシージャが発行されます。
他の構成詳細の指定やデータのマスキング、クローニング・プロセスのスケジュールを行う場合は、「拡張」をクリックします。

「拡張」オプションを選択した場合は、それ以降の手順に従います。

7. 「Oracle Cloudへのクローン作成: ソースと宛先」ページで、詳細を確認して「次へ」をクリックします。

8. 「Oracle Cloudへのクローン作成: 構成」ページの「データベース・ファイルの場所」セクションで、PDBクローンのデータファイルを格納する記憶域の場所を指定します。
「拡張構成」セクションで、PDBクローンの最大サイズの記憶域制限と、PDBクローン内の共有表領域の最大サイズを指定します。デフォルトでは、これらの属性の値に制限はありません。

「その他」セクションで、PDBクローン内に作成される表領域に対して使用するロギング・オプションを選択します。

「次へ」をクリックします。

9. 「Oracle Cloudへのクローン作成: 後処理」ページの「データ・マスキング」セクションで、PDBのクローニング後に適用するデータ・マスキング定義を指定します。データ・マスキングによって、データベース内の機密データがマスクされます。
データ・マスキング定義の作成方法の詳細は、「データ・マスキング定義の作成または編集」を参照してください。データ・マスキング定義を適用できるのは、Subset-Maskingライセンス・パックがある場合のみです。

「カスタム・スクリプト」セクションの「前スクリプト」および「後スクリプト」で、PDBのクローニングの前後に実行するスクリプトを含むOracleソフトウェア・ライブラリ・コンポーネントを指定します。また、「SQLスクリプト」で、PDBのクローニング後に実行するSQLスクリプトを指定します。「実行ユーザー」で、SQLスクリプトの実行に使用するユーザー・アカウントを選択します。

「次へ」をクリックします。

10. 「Oracle Cloudへのクローン作成: スケジュール」ページで、クローニングのデプロイメント・プロシージャのインスタンス名を指定します。また、クローニング・デプロイメント・プロシージャを開始する時点を指定します。
「通知」セクションで、電子メール通知を受信するデプロイメント・プロシージャの状態を選択します。たとえば、「通知のステータス」で「スケジュール済」および「成功」を選択すると、クローニング・デプロイメント・プロシージャがスケジュールされたときと、それが成功したときに電子メール通知を受信できます。

「次へ」をクリックします。

11. 「Oracle Cloudへのクローン作成: 確認」ページで、入力したすべての詳細を確認します。特定の詳細を編集する場合、「戻る」をクリックして必要なページに移動します。
「クローン」をクリックしてデプロイメント・プロシージャを発行し、Oracle CloudにデプロイされたCDBにPDBをクローニングします。

15.4.1.2 EM CLIを使用したOracle CloudへのPDBのクローニング

オンプレミスのプラガブル・データベースをOracle Cloudにクローニングできます。EM CLIコマンドを使用する前に、オンプレミスPDBのテスト・マスターを作成し、そのテスト・マスターを使用してクローンを作成することをお薦めします。これは、データをインターネットで転送する前にマスキングする目的で推奨されます。

テスト・マスターを作成するには、14.4.2項「EM CLIを使用したテスト・マスター・プラガブル・データベースの作成」を参照してください。

オンプレミス・プラガブル・データベースをOracle Cloudにクローニングするには、EM CLI動詞emcli pdb_clone_management -input_file=data:/xyz/sdf/pdb_clone.props -cloneToOracleCloudを入力します(pdb_clone.propsは、クローニング・パラメータとその値を提供するプロパティ・ファイルです)。

プラガブル・データベースをクローニングするには、3つの方法があります。これらの各方法では、プロパティ・ファイル内の特定のパラメータの構成に違いがあります。3つの方法および構成パラメータの詳細は、後述します。

- オペレーティング・システム(OS)イメージのバックアップ
ソースPDBのバックアップを作成し、新しいPDBを作成します。BACKUP_TYPEパラメータでは、バックアップのタイプを指定する必要があります。BACKUP_TYPEに使用可能な値は、OSIMAGE、RMANおよびTARです。EXISTING_BACKUPおよびEXISTING_BACKUP_METADATAパラメータは指定しないでください。

プロパティ・ファイルの例:

SRC_PDB_TARGET=cdb_prod_PDB
SRC_HOST_CREDS=NC_HOST_SCY:SYCO
SRC_CDB_CREDS=NC_HOST_SYC:SYCO
SRC_WORK_DIR=/tmp/source
DEST_HOST_CREDS=NC_SLCO_SSH:SYS
DEST_LOCATION=/scratch/sray/app/sray/cdb_tm/HR_TM_PDB6
DEST_CDB_TARGET=cdb_tm
DEST_CDB_TYPE=oracle_database
DEST_CDB_CREDS=NC_HOST_SYC:SYCO
DEST_PDB_NAME=HR_TM_PDB6
BACKUP_TYPE=OSIMAGE

- 既存のバックアップ
ソースPDBの既存のバックアップを使用し、新しいPDBを作成します。BACKUP_TYPEパラメータでは、バックアップのタイプを指定する必要があります。BACKUP_TYPEに使用可能な値は、OSIMAGE、RMANおよびTARです。EXISTING_BACKUPパラメータではバックアップ名のある場所を指定し、EXISTING_BACKUP_METADATAではバックアップの場所とメタデータ・ファイル名を指定します。

プロパティ・ファイルの例:

SRC_PDB_TARGET=cdb_prod_PDB
SRC_HOST_CREDS=NC_HOST_SCY:SYCO
SRC_CDB_CREDS=NC_HOST_SYC:SYCO
SRC_WORK_DIR=/tmp/source
DEST_HOST_CREDS=NC_SLCO_SSH:SYS
DEST_LOCATION=/scratch/sray/app/sray/cdb_tm/HR_TM_PDB6
DEST_CDB_TARGET=cdb_tm
DEST_CDB_TYPE=oracle_database
DEST_CDB_CREDS=NC_HOST_SYC:SYCO
DEST_PDB_NAME=HR_TM_PDB6
EXISTING_BACKUP=/user1/pdbbackup/PDB1_Backup_14297779
EXISTING_BACKUP_METADATA=/user1/pdbbackup/PDB1_Backup_14297779/PDB1.xml
BACKUP_TYPE=RMAN

注意:
PDBバックアップを作成するには、動詞emcli pdb_backup -inputFile="loaction of file containing properties required for taking backup of PDB"を入力します(プロパティ・ファイルの内容例は次のとおりです)。

TARGET_HOST_LIST=xyz.abccorp.com
HOST_NORMAL_NAMED_CRED=XYZ_CRED:CRED_OWNER
SRC_CDB_NAMED_CRED=CDB1_CRED:CRED_OWNER
SRC_CDB_TARGET_NAME=CDB1
SRC_CDB_TARGET_TYPE=oracle_database
SRC_PDB_TARGET_NAME=CDB1_PDB1
BACKUP_LOCATION=/user1/pdbbackup
WORK_DIR_LOCATION=/tmp
ORACLE_HOME_LOC=/scratch/d121hmcasm/product/12.1.0/dbhome_1

- 切断/接続
ソースPDBを切断し、切断されたソースを使用して宛先に新しいPDBを作成してから、ソースを再び接続します。EXISTING_BACKUP、EXISTING_BACKUP_METADATAおよびBACKUP_TYPEパラメータは指定しないでください。

プロパティ・ファイルの例:

SRC_PDB_TARGET=cdb_prod_PDB
SRC_HOST_CREDS=NC_HOST_SCY:SYCO
SRC_CDB_CREDS=NC_HOST_SYC:SYCO
SRC_WORK_DIR=/tmp/source
DEST_HOST_CREDS=NC_SLCO_SSH:SYS
DEST_LOCATION=/scratch/sray/app/sray/cdb_tm/HR_TM_PDB6
DEST_CDB_TARGET=cdb_tm
DEST_CDB_TYPE=oracle_database
DEST_CDB_CREDS=NC_HOST_SYC:SYCO
DEST_PDB_NAME=HR_TM_PDB6

注意:
前述の3つの方法のいずれについても、宛先PDBデータ・ファイルの場所がASMであれば、パラメータDEST_STAGE_DIRを追加します(その値は、ソースPDBデータ・ファイルの転送中に宛先として使用されます)。このパラメータはオプションであり、指定しない場合は一時ディレクトリが使用されます。Linuxシステムの場合、一時ディレクトリは/tmpです。

15.4.2 Oracle CloudのDBまたはPDBへのスキーマのクローニング

EM CLI動詞を使用して、オンプレミスのスキーマをデータベースまたはプラガブル・データベースとしてOracle Cloudにクローニングできます。

注意:
前提条件として、スキーマ・データベースのテスト・マスターを作成し、そのテスト・マスターのスキーマを使用してクローンを作成することをお薦めします。テスト・マスターを作成するには、14.2.2項「EM CLIを使用したテスト・マスター・データベースの作成」を参照してください。

オンプレミスのスキーマをデータベースまたはプラガブル・データベースとしてOracle Cloudにクローニングするには、次の手順を実行します。

1. EM CLI動詞emcli describe_dbprofile_input -data_mode=EXPORTを入力します。出力にはすべてのプロファイル作成入力変数が提供されます。

注意:
エクスポートはデータベースとスキーマでのみサポートされており、インポートはデータベースとPDBの両方でサポートされています。つまり、ソースは常にデータベースまたはスキーマである必要がありますが、宛先はデータベースかPDBのいずれでもかまいません。

2. 入力変数を使用して、すべての変数に対する値が設定されたプロパティ・ファイルを作成します。

3. データベース・プロファイルを作成して、ソース・データベースからデータをエクスポートします。このためには、動詞emcli create_dbprofile - input_file=data:<properties file name along with path>を入力します。

注意:
この動詞について、前の手順で作成したプロパティ・ファイルを使用します。

プロパティ・ファイルの例:

#-----------------------------------------------#
# SOURCE                                        #
#-----------------------------------------------#
REFERENCE_DATABASE=SS_REF_TD_DB
REFERENCE_DATABASE_TYPE=oracle_database
REF_DB_CREDENTIALS=SYSDBA:SYS
REF_HOST_CREDENTIALS=REF_NC_CRED:SYS

#-----------------------------------------------#
# DATA CONTENT DETAILS                          #
#-----------------------------------------------#
DATA_CONTENT_MODE=EXPORT
DATA_CONTENT=METADATA_AND_DATA

#-----------------------------------------------#
# EXPORT DETAILS                                #
#-----------------------------------------------#
EXPORT.EXPORT_TYPE=SELECTED_SCHEMAS
EXPORT.SCHEMA_INCLUDE_LIST.0=HR
EXPORT.SCHEMA_INCLUDE_LIST.1=PM
EXPORT.SCHEMA_INCLUDE_LIST.2=OE
EXPORT.SCHEMA_INCLUDE_LIST.3=IX
EXPORT.SCHEMA_INCLUDE_LIST.4=SH
EXPORT.SCHEMA_INCLUDE_LIST.5=BI
EXPORT.DEGREE_OF_PARALLELISM=1
EXPORT.DUMP_DIRECTORY_LIST.0=directory=SCHEMAS_DUMP_DIR,file_name=samplschemas.dmp,max_size=100
EXPORT.LOG_FILE_DIRECTORY=directory=SCHEMAS_DUMP_DIR,file_name=samplschemas.log

#-----------------------------------------------#
#         PROFILE DETAILS                       #
#-----------------------------------------------#
PROFILE_NAME=Export Dump of Sample schemas10
PROFILE_VERSION=11.2.0.4.0
PROFILE_LOCATION=Database Provisioning Profiles/12.1.0.1.0/linux_x64/
WORKING_DIRECTORY=/tmp

4. 動詞を入力して、データを転送します(emcli data_transfer -input_file=data:/u01/files/data_trans.props)。
プロパティ・ファイルの例:

#-----------------------------------------#
# SOURCE                                  #
#-----------------------------------------#
SRC_HOST_CREDS=NC_HOST_SRAY
SOURCE_LOCATION=/tmp/newp/PDB_Backup_142838
SRC_HOST=bl2.idc.example.com

#-----------------------------------------#
# DESTINATION                             #
#-----------------------------------------#
DEST_HOST_CREDS=NC_HOST_SRAY
DEST_LOCATION=/scratch/sray/app3/sray/oradata/migda
DEST_HOST=slo.us.example.com

#-----------------------------------------#
# HYBRID GATEAWAY / FORWARDER             #
#-----------------------------------------#
FORWARDER_HOST=slo.us.example.com
FORWARDER_CRED=ACD_NY:SYSCO
WORKING_DIRECTORY=/tmp

注意:
ソース・ホストと宛先ホストの間にSSH接続が存在する場合は、Hybrid Gatewayパラメータを削除してください。

5. データを宛先データベースにインポートするための動詞を入力します(emcli dbimport -input_file=data:/u01/files/dbimport.props)。

注意:
宛先をデータベースまたはプラガブル・データベースにクローニングするには、プロパティ・ファイル内にDESTINATION_TARGET_TYPEオプションで必要な値を入力してください。データベースの場合はoracle_databaseと入力し、PDBの場合はoracle_pdbと入力します。

プロパティ・ファイルの例:

#-----------------------------------------------#
#         DESTINATION                           #
#-----------------------------------------------#
DESTINATION_TARGET=SS_OPC_DB
DESTINATION_TARGET_TYPE=oracle_database
DATABASE_CREDENTIAL=SYSDBA:SYS
HOST_NAMED_CREDENTIAL=AE_NC:SYSCO

#-----------------------------------------------#
#         PROFILE                               #
#-----------------------------------------------#
PROFILE_LOCATION=Database Provisioning Profiles/12.1.0.1.0/linux_x64/Export Dump of Sample schemas10

#-----------------------------------------------#
#         SCHEMA DETAILS                        #
#-----------------------------------------------#
REMAP_SCHEMA_LIST.0=HR:HR
REMAP_SCHEMA_LIST.1=OE:OE
REMAP_SCHEMA_LIST.2=PM:PM
REMAP_SCHEMA_LIST.3=IX:IX
REMAP_SCHEMA_LIST.4=SH:SH
REMAP_SCHEMA_LIST.5=BI:BI
REMAP_TABLESPACE_LIST.0=EXAMPLE:MYTBSP1
REMAP_TABLESPACE_LIST.1=USERS:MYTBSP1
REMAP_TABLESPACE_LIST.2=SYSTEM:MYTBSP1
DEGREE_OF_PARALLELISM=1
DUMP_FILE_LIST.0=/scratch/ae/dumpdir/samplschemas.dmp
IMPORT_LOG_FILE_DIRECTORY=DATA_PUMP_DIR

15.4.3 Oracle CloudのDBまたはPDBへのDBのクローニング

EM CLI動詞を使用して、オンプレミスのデータベースをデータベースまたはプラガブル・データベースとしてOracle Cloudにクローニングできます。

注意:
前提条件として、データベースのテスト・マスターを作成し、そのテスト・マスターのスキーマを使用してクローンを作成することをお薦めします。テスト・マスターを作成するには、14.2.2項「EM CLIを使用したテスト・マスター・データベースの作成」を参照してください。

オンプレミスのデータベースをデータベースまたはプラガブル・データベースとしてOracle Cloudにクローニングするには、次の手順を実行します。

1. EM CLI動詞emcli describe_dbprofile_input -data_mode=EXPORTを入力します。出力にはすべてのプロファイル作成入力変数が提供されます。

注意:
エクスポートはデータベースとスキーマでのみサポートされており、インポートはデータベースとPDBの両方でサポートされています。つまり、ソースは常にデータベースまたはスキーマである必要がありますが、宛先はデータベースかPDBのいずれでもかまいません。

2. 入力変数を使用して、すべての変数に対する値が設定されたプロパティ・ファイルを作成します。

3. データベース・プロファイルを作成して、ソース・データベースからデータをエクスポートします。このためには、動詞emcli create_dbprofile - input_file=data:<properties file name along with path>を入力します。

注意:
この動詞について、前の手順で作成したプロパティ・ファイルを使用します。

プロパティ・ファイルの例:

#-----------------------------------------------#
# SOURCE                                        #
#-----------------------------------------------#
REFERENCE_DATABASE=SS_TM_DB
REFERENCE_DATABASE_TYPE=oracle_database
REF_DB_CREDENTIALS=SYSDBA:SYS
REF_HOST_CREDENTIALS=AE_NC:SYS

#-----------------------------------------------#
# DATA CONTENT DETAILS                          #
#-----------------------------------------------#
DATA_CONTENT_MODE=EXPORT
DATA_CONTENT=METADATA_AND_DATA

#-----------------------------------------------#
# EXPORT DETAILS                                #
#-----------------------------------------------#
EXPORT.EXPORT_TYPE=FULL_DATABASE
EXPORT.DEGREE_OF_PARALLELISM=1
EXPORT.DUMP_DIRECTORY_LIST.0=directory=SCHEMAS_DUMP_DIR,file_name=samplschemas.dmp,max_size=100
EXPORT.LOG_FILE_DIRECTORY=directory=SCHEMAS_DUMP_DIR,file_name=samplschemas.log

#-----------------------------------------------#
#         PROFILE DETAILS                       #
#-----------------------------------------------#
PROFILE_NAME=Export Dump of Sample schemas10
PROFILE_VERSION=11.2.0.4.0
PROFILE_LOCATION=Database Provisioning Profiles/12.1.0.1.0/linux_x64/
WORKING_DIRECTORY=/tmp

4. 動詞を入力して、データを転送します(emcli data_transfer -input_file=data:/u01/files/data_trans.props)。
プロパティ・ファイルの例:

#-----------------------------------------#
# SOURCE                                  #
#-----------------------------------------#
SRC_HOST_CREDS=NC_HOST_SRAY
SOURCE_LOCATION=/tmp/newp/PDB_Backup_1428003803938
SRC_HOST=b12.idc.example.com

#-----------------------------------------#
# DESTINATION                             #
#-----------------------------------------#
DEST_HOST_CREDS=NC_HOST_SRAY
DEST_LOCATION=/scratch/sray/app3/sray/oradata/migda
DEST_HOST=slo.us.example.com

#-----------------------------------------#
# HYBRID GATEAWAY / FORWARDER             #
#-----------------------------------------#
FORWARDER_HOST=slo.us.example.com
FORWARDER_CRED=ACD_NY:SYSCO
WORKING_DIRECTORY=/tmp

注意:
ソース・ホストと宛先ホストの間にSSH接続が存在する場合は、Hybrid Gatewayパラメータを削除してください。

5. データを宛先データベースにインポートするための動詞を入力します(emcli dbimport -input_file=data:/u01/files/dbimport.props)。

注意:
宛先をデータベースまたはプラガブル・データベースにクローニングするには、プロパティ・ファイル内にDESTINATION_TARGET_TYPEオプションで必要な値を入力してください。データベースの場合はoracle_databaseと入力し、PDBの場合はoracle_pdbと入力します。

プロパティ・ファイルの例:

#-----------------------------------------------#
#         DESTINATION                           #
#-----------------------------------------------#
DESTINATION_TARGET=SS_OPC_DB
DESTINATION_TARGET_TYPE=oracle_database
DATABASE_CREDENTIAL=SYSDBA:SYS
HOST_NAMED_CREDENTIAL=AE_NC:SYS

#-----------------------------------------------#
#         PROFILE                               #
#-----------------------------------------------#
PROFILE_LOCATION=Database Provisioning Profiles/12.1.0.1.0/linux_x64/Export Dump of Sample schemas10

#-----------------------------------------------#
#         SCHEMA DETAILS                        #
#-----------------------------------------------#
REMAP_SCHEMA_LIST.0=HR:HR
REMAP_SCHEMA_LIST.1=OE:OE
REMAP_SCHEMA_LIST.2=PM:PM
REMAP_SCHEMA_LIST.3=IX:IX
REMAP_SCHEMA_LIST.4=SH:SH
REMAP_SCHEMA_LIST.5=BI:BI
REMAP_TABLESPACE_LIST.0=EXAMPLE:MYTBSP1
REMAP_TABLESPACE_LIST.1=USERS:MYTBSP1
REMAP_TABLESPACE_LIST.2=SYSTEM:MYTBSP1
DEGREE_OF_PARALLELISM=1
DUMP_FILE_LIST.0=/scratch/ae/dumpdir/samplschemas.dmp
IMPORT_LOG_FILE_DIRECTORY=DATA_PUMP_DIR

15.5 Oracle Cloudからのクローニング

Oracle Cloudからデータベース、スキーマまたはPDBをクローニングする場合は、次のユースケースを参照してください。

- Oracle CloudからのPDBのクローニング

- Oracle CloudからDBまたはPDBへのスキーマのクローニング

- Oracle CloudからDBまたはPDBへのDBのクローニング

15.5.1 Oracle CloudからのPDBのクローニング

PDBをOracle CloudからオンプレミスPDBにクローニングするには、次のいずれかのソリューションを使用できます。

- クローン・ウィザードを使用したOracle CloudからのPDBのクローニング

- EM CLIを使用したOracle CloudからのPDBのクローニング

15.5.1.1 クローン・ウィザードを使用したOracle CloudからのPDBのクローニング

PDBをOracle CloudからオンプレミスPDBにクローニングするには、次の手順を実行します。

1. 「ターゲット」メニューから「データベース」を選択します。

2. 「表示」で、「検索リスト」を選択します。「表示」メニューから、「すべてを開く」を選択します。

3. リストでソースCDB (ソースPDBが含まれるCDB)を見つけ、クローニングするPDBの名前をクリックします。

4. 「Oracleデータベース」メニューから、「クローニング」→「Oracle Cloudへのクローン作成」を選択します。
別の方法として、手順3で、クローニングするPDBの名前を右クリックし、「Oracleデータベース」→「クローニング」→「Oracle Cloudへのクローン作成」を選択できます。

5. 「ソースと宛先: Oracle Cloudからクローン作成」ページで、次の手順を実行します。

- 「資格証明」セクションで、ソースCDBのSYSDBA資格証明と、ソースCDBのホスト資格証明を指定します。優先資格証明を使用するか、名前付き資格証明の保存済セットを使用するか、資格証明の新規セットを指定するかを選択できます。

- 「プラガブル・データベース定義」セクションで、PDBクローンの名前と表示名を指定します。Enterprise Managerでは、PDBクローン・ターゲットの識別に表示名を使用します。

- 「PDB管理者資格証明」セクションで、PDBクローンの管理に使用する管理者ユーザー・アカウントの資格証明を指定します。

- 「コンテナ・データベース」セクションで、パブリック・クラウド設定にデプロイされた宛先CDB (PDBクローンを含む必要のあるCDB)を指定します。

- 「資格証明」セクションで、宛先CDBのSYSDBA資格証明と、宛先CDBのホスト資格証明を指定します。

6. これ以上詳細を指定する必要がなければ、「クローン」をクリックします。これにより、パブリック・クラウド設定にデプロイされたCDBにPDBをクローニングするためのデプロイメント・プロシージャが発行されます。
他の構成詳細の指定やデータのマスキング、クローニング・プロセスのスケジュールを行う場合は、「拡張」をクリックします。

「拡張」オプションを選択した場合は、それ以降の手順に従います。

7. 「Oracle Cloudからクローン作成: ソースと宛先」ページで、詳細を確認して「次へ」をクリックします。

8. 「Oracle Cloudからクローン作成: 構成」ページの「データベース・ファイルの場所」セクションで、PDBクローンのデータファイルを格納する記憶域の場所を指定します。
「拡張構成」セクションで、PDBクローンの最大サイズの記憶域制限と、PDBクローン内の共有表領域の最大サイズを指定します。デフォルトでは、これらの属性の値に制限はありません。

「その他」セクションで、PDBクローン内に作成される表領域に対して使用するロギング・オプションを選択します。

「次へ」をクリックします。

9. 「Oracle Cloudからクローン作成: 後処理」ページの「データ・マスキング」セクションで、PDBのクローニング後に適用するデータ・マスキング定義を指定します。データ・マスキングによって、データベース内の機密データがマスクされます。
データ・マスキング定義の作成方法の詳細は、「データ・マスキング定義の作成または編集」を参照してください。データ・マスキング定義を適用できるのは、Subset-Maskingライセンス・パックがある場合のみです。

「カスタム・スクリプト」セクションの「前スクリプト」および「後スクリプト」で、PDBのクローニングの前後に実行するスクリプトを含むOracleソフトウェア・ライブラリ・コンポーネントを指定します。また、「SQLスクリプト」で、PDBのクローニング後に実行するSQLスクリプトを指定します。「実行ユーザー」で、SQLスクリプトの実行に使用するユーザー・アカウントを選択します。

「次へ」をクリックします。

10. 「Oracle Cloudからクローン作成: スケジュール」ページで、クローニングのデプロイメント・プロシージャのインスタンス名を指定します。また、クローニング・デプロイメント・プロシージャを開始する時点を指定します。
「通知」セクションで、電子メール通知を受信するデプロイメント・プロシージャの状態を選択します。たとえば、「通知のステータス」で「スケジュール済」および「成功」を選択すると、クローニング・デプロイメント・プロシージャがスケジュールされたときと、それが成功したときに電子メール通知を受信できます。

「次へ」をクリックします。

11. 「Oracle Cloudからクローン作成: 確認」ページで、入力したすべての詳細を確認します。特定の詳細を編集する場合、「戻る」をクリックして必要なページに移動します。
「クローン」をクリックして、パブリック・クラウド設定にデプロイされたCDBにPDBをクローニングするためのデプロイメント・プロシージャを発行します。

15.5.1.2 EM CLIを使用したOracle CloudからのPDBのクローニング

Oracle Cloudのプラガブル・データベースをオンプレミスのコンテナ・データベースにクローニングするには、EM CLI動詞emcli pdb_clone_management -input_file=data:/xyz/sdf/pdb_clone.props,を入力します(pdb_clone.propsは、クローニング・パラメータとその値を提供するプロパティ・ファイルです)。

プラガブル・データベースをクローニングするには、3つの方法があります。これらの各方法では、プロパティ・ファイル内の特定のパラメータの構成に違いがあります。3つの方法および構成パラメータの詳細は、後述します。

- オペレーティング・システム(OS)イメージのバックアップ
ソースPDBのバックアップを作成し、新しいPDBを作成します。BACKUP_TYPEパラメータでは、バックアップのタイプを指定する必要があります。BACKUP_TYPEに使用可能な値は、OSIMAGE、RMANおよびTARです。EXISTING_BACKUPおよびEXISTING_BACKUP_METADATAパラメータは指定しないでください。

プロパティ・ファイルの例:

SRC_PDB_TARGET=cdb_prod_PDB
SRC_HOST_CREDS=NC_HOST_SCY:SYCO
SRC_CDB_CREDS=NC_HOST_SYC:SYCO
SRC_WORK_DIR=/tmp/source
DEST_HOST_CREDS=NC_SLCO_SSH:SYS
DEST_LOCATION=/scratch/sray/app/sray/cdb_tm/HR_TM_PDB6
DEST_CDB_TARGET=cdb_tm
DEST_CDB_TYPE=oracle_database
DEST_CDB_CREDS=NC_HOST_SYC:SYCO
DEST_PDB_NAME=HR_TM_PDB6
BACKUP_TYPE=OSIMAGE

- 既存のバックアップ
ソースPDBの既存のバックアップを使用し、新しいPDBを作成します。BACKUP_TYPEパラメータでは、バックアップのタイプを指定する必要があります。BACKUP_TYPEに使用可能な値は、OSIMAGE、RMANおよびTARです。EXISTING_BACKUPパラメータではバックアップ名のある場所を指定し、EXISTING_BACKUP_METADATAではバックアップの場所とメタデータ・ファイル名を指定します。

プロパティ・ファイルの例:

SRC_PDB_TARGET=cdb_prod_PDB
SRC_HOST_CREDS=NC_HOST_SCY:SYCO
SRC_CDB_CREDS=NC_HOST_SYC:SYCO
SRC_WORK_DIR=/tmp/source
DEST_HOST_CREDS=NC_SLCO_SSH:SYS
DEST_LOCATION=/scratch/sray/app/sray/cdb_tm/HR_TM_PDB6
DEST_CDB_TARGET=cdb_tm
DEST_CDB_TYPE=oracle_database
DEST_CDB_CREDS=NC_HOST_SYC:SYCO
DEST_PDB_NAME=HR_TM_PDB6
EXISTING_BACKUP=/user1/pdbbackup/PDB1_Backup_14297779
EXISTING_BACKUP_METADATA=/user1/pdbbackup/PDB1_Backup_14297779/PDB1.xml
BACKUP_TYPE=RMAN

注意:
PDBバックアップを作成するには、動詞emcli pdb_backup -inputFile="loaction of file containing properties required for taking backup of PDB"を入力します(プロパティ・ファイルの内容例は次のとおりです)。

TARGET_HOST_LIST=xyz.abccorp.com
HOST_NORMAL_NAMED_CRED=XYZ_CRED:CRED_OWNER
SRC_CDB_NAMED_CRED=CDB1_CRED:CRED_OWNER
SRC_CDB_TARGET_NAME=CDB1
SRC_CDB_TARGET_TYPE=oracle_database
SRC_PDB_TARGET_NAME=CDB1_PDB1
BACKUP_LOCATION=/user1/pdbbackup
WORK_DIR_LOCATION=/tmp
ORACLE_HOME_LOC=/scratch/d121hmcasm/product/12.1.0/dbhome_1

- 切断/接続
ソースPDBを切断し、切断されたソースを使用して宛先に新しいPDBを作成してから、ソースを再び接続します。EXISTING_BACKUPおよびBACKUP_TYPEパラメータの両方は指定しないでください。

プロパティ・ファイルの例:

SRC_PDB_TARGET=cdb_prod_PDB
SRC_HOST_CREDS=NC_HOST_SCY:SYCO
SRC_CDB_CREDS=NC_HOST_SYC:SYCO
SRC_WORK_DIR=/tmp/source
DEST_HOST_CREDS=NC_SLCO_SSH:SYS
DEST_LOCATION=/scratch/sray/app/sray/cdb_tm/HR_TM_PDB6
DEST_CDB_TARGET=cdb_tm
DEST_CDB_TYPE=oracle_database
DEST_CDB_CREDS=NC_HOST_SYC:SYCO
DEST_PDB_NAME=HR_TM_PDB6

注意:
前述の3つの方法のいずれについても、宛先PDBデータ・ファイルの場所がASMであれば、パラメータDEST_STAGE_DIRを追加します(その値は、ソースPDBデータ・ファイルの転送中に宛先として使用されます)。このパラメータはオプションであり、指定しない場合は一時ディレクトリが使用されます。Linuxシステムの場合、一時ディレクトリは/tmpです。

15.5.2 Oracle CloudからDBまたはPDBへのスキーマのクローニング

EM CLI動詞を使用して、Oracle Cloudのスキーマをデータベースまたはプラガブル・データベースとしてオンプレミスにクローニングできます。このためには、次の手順を実行します。

1. EM CLI動詞emcli describe_dbprofile_input -data_mode=EXPORTを入力します。出力にはすべてのプロファイル作成入力変数が提供されます。

注意:
エクスポートはデータベースとスキーマでのみサポートされており、インポートはデータベースとPDBの両方でサポートされています。つまり、ソースは常にデータベースまたはスキーマである必要がありますが、宛先はデータベースかPDBのいずれでもかまいません。

2. 入力変数を使用して、すべての変数に対する値が設定されたプロパティ・ファイルを作成します。

3. データベース・プロファイルを作成して、ソース・データベースからデータをエクスポートします。このためには、動詞emcli create_dbprofile - input_file=data:<properties file name along with path>を入力します。

注意:
この動詞について、前の手順で作成したプロパティ・ファイルを使用します。

プロパティ・ファイルの例:

#-----------------------------------------------#
# SOURCE                                        #
#-----------------------------------------------#
REFERENCE_DATABASE=SS_TM_DB
REFERENCE_DATABASE_TYPE=oracle_database
REF_DB_CREDENTIALS=SYSDBA:SYS
REF_HOST_CREDENTIALS=AE_NC:SYS

#-----------------------------------------------#
# DATA CONTENT DETAILS                          #
#-----------------------------------------------#
DATA_CONTENT_MODE=EXPORT
DATA_CONTENT=METADATA_AND_DATA

#-----------------------------------------------#
# EXPORT DETAILS                                #
#-----------------------------------------------#
EXPORT.EXPORT_TYPE=SELECTED_SCHEMAS
EXPORT.SCHEMA_INCLUDE_LIST.0=HR
EXPORT.SCHEMA_INCLUDE_LIST.1=PM
EXPORT.SCHEMA_INCLUDE_LIST.2=OE
EXPORT.SCHEMA_INCLUDE_LIST.3=IX
EXPORT.SCHEMA_INCLUDE_LIST.4=SH
EXPORT.SCHEMA_INCLUDE_LIST.5=BI
EXPORT.DEGREE_OF_PARALLELISM=1
EXPORT.DUMP_DIRECTORY_LIST.0=directory=SCHEMAS_DUMP_DIR,file_name=samplschemas.dmp,max_size=100
EXPORT.LOG_FILE_DIRECTORY=directory=SCHEMAS_DUMP_DIR,file_name=samplschemas.log

#-----------------------------------------------#
#         PROFILE DETAILS                       #
#-----------------------------------------------#
PROFILE_NAME=Export Dump of Sample schemas10
PROFILE_VERSION=11.2.0.4.0
PROFILE_LOCATION=Database Provisioning Profiles/12.1.0.1.0/linux_x64/
WORKING_DIRECTORY=/tmp

4. 動詞を入力して、データを転送します(emcli data_transfer -input_file=data:/u01/files/data_trans.props)。
プロパティ・ファイルの例:

#-----------------------------------------#
# SOURCE                                  #
#-----------------------------------------#
SRC_HOST_CREDS=NC_HOST_SRAY
SOURCE_LOCATION=/tmp/newp/PDB_Backup_1428003803938
SRC_HOST=bl2.idc.example.com

#-----------------------------------------#
# DESTINATION                             #
#-----------------------------------------#
DEST_HOST_CREDS=NC_HOST_SRAY
DEST_LOCATION=/scratch/sray/app3/sray/oradata/migda
DEST_HOST=slo.us.example.com

#-----------------------------------------#
# HYBRID GATEAWAY / FORWARDER             #
#-----------------------------------------#
FORWARDER_HOST=slo.us.example.com
FORWARDER_CRED=ACD_NY:SYSCO
WORKING_DIRECTORY=/tmp

注意:
ソース・ホストと宛先ホストの間にSSH接続が存在する場合は、Hybrid Gatewayパラメータを削除してください。

5. データを宛先データベースにインポートするための動詞を入力します(emcli dbimport -input_file=data:/u01/files/dbimport.props)。

注意:
宛先をデータベースまたはプラガブル・データベースにクローニングするには、プロパティ・ファイル内にDESTINATION_TARGET_TYPEオプションで必要な値を入力してください。データベースの場合はoracle_databaseと入力し、PDBの場合はoracle_pdbと入力します。

プロパティ・ファイルの例:

#-----------------------------------------------#
#         DESTINATION                           #
#-----------------------------------------------#
DESTINATION_TARGET=SS_OPC_DB
DESTINATION_TARGET_TYPE=oracle_database
DATABASE_CREDENTIAL=SYSDBA:SYS
HOST_NAMED_CREDENTIAL=AE_NC:SYS

#-----------------------------------------------#
#         PROFILE                               #
#-----------------------------------------------#
PROFILE_LOCATION=Database Provisioning Profiles/12.1.0.1.0/linux_x64/Export Dump of Sample schemas10

#-----------------------------------------------#
#         SCHEMA DETAILS                        #
#-----------------------------------------------#
REMAP_SCHEMA_LIST.0=HR:HR
REMAP_SCHEMA_LIST.1=OE:OE
REMAP_SCHEMA_LIST.2=PM:PM
REMAP_SCHEMA_LIST.3=IX:IX
REMAP_SCHEMA_LIST.4=SH:SH
REMAP_SCHEMA_LIST.5=BI:BI
REMAP_TABLESPACE_LIST.0=EXAMPLE:MYTBSP1
REMAP_TABLESPACE_LIST.1=USERS:MYTBSP1
REMAP_TABLESPACE_LIST.2=SYSTEM:MYTBSP1
DEGREE_OF_PARALLELISM=1
DUMP_FILE_LIST.0=/scratch/ae/dumpdir/samplschemas.dmp
IMPORT_LOG_FILE_DIRECTORY=DATA_PUMP_DIR

15.5.3 Oracle CloudからDBまたはPDBへのDBのクローニング

EM CLI動詞を使用して、Oracle Cloudのデータベースをデータベースまたはプラガブル・データベースとしてオンプレミスにクローニングできます。このためには、次の手順を実行します。

1. EM CLI動詞emcli describe_dbprofile_input -data_mode=EXPORTを入力します。出力にはすべてのプロファイル作成入力変数が提供されます。

注意:
エクスポートはデータベースとスキーマでのみサポートされており、インポートはデータベースとPDBの両方でサポートされています。つまり、ソースは常にデータベースまたはスキーマである必要がありますが、宛先はデータベースかPDBのいずれでもかまいません。

2. 入力変数を使用して、すべての変数に対する値が設定されたプロパティ・ファイルを作成します。

3. データベース・プロファイルを作成して、ソース・データベースからデータをエクスポートします。このためには、動詞emcli create_dbprofile - input_file=data:<properties file name along with path>を入力します。

注意:
この動詞について、前の手順で作成したプロパティ・ファイルを使用します。

プロパティ・ファイルの例:

#-----------------------------------------------#
# SOURCE                                        #
#-----------------------------------------------#
REFERENCE_DATABASE=SS_TM_DB
REFERENCE_DATABASE_TYPE=oracle_database
REF_DB_CREDENTIALS=SYSDBA:SYS
REF_HOST_CREDENTIALS=AE_NC:SYS

#-----------------------------------------------#
# DATA CONTENT DETAILS                          #
#-----------------------------------------------#
DATA_CONTENT_MODE=EXPORT
DATA_CONTENT=METADATA_AND_DATA

#-----------------------------------------------#
# EXPORT DETAILS                                #
#-----------------------------------------------#
EXPORT.EXPORT_TYPE=FULL_DATABASE
EXPORT.DEGREE_OF_PARALLELISM=1
EXPORT.DUMP_DIRECTORY_LIST.0=directory=SCHEMAS_DUMP_DIR,file_name=samplschemas.dmp,max_size=100
EXPORT.LOG_FILE_DIRECTORY=directory=SCHEMAS_DUMP_DIR,file_name=samplschemas.log

#-----------------------------------------------#
#         PROFILE DETAILS                       #
#-----------------------------------------------#
PROFILE_NAME=Export Dump of Sample schemas10
PROFILE_VERSION=11.2.0.4.0
PROFILE_LOCATION=Database Provisioning Profiles/12.1.0.1.0/linux_x64/
WORKING_DIRECTORY=/tmp

4. 動詞を入力して、データを転送します(emcli data_transfer -input_file=data:/u01/files/data_trans.props)。
プロパティ・ファイルの例:

#-----------------------------------------#
# SOURCE                                  #
#-----------------------------------------#
SRC_HOST_CREDS=NC_HOST_SRAY
SOURCE_LOCATION=/tmp/newp/PDB_Backup_1428003803938
SRC_HOST=bl2.idc.example.com

#-----------------------------------------#
# DESTINATION                             #
#-----------------------------------------#
DEST_HOST_CREDS=NC_HOST_SRAY
DEST_LOCATION=/scratch/sray/app3/sray/oradata/migda
DEST_HOST=slo.us.example.com

#-----------------------------------------#
# HYBRID GATEAWAY / FORWARDER             #
#-----------------------------------------#
FORWARDER_HOST=slo.us.example.com
FORWARDER_CRED=ACD_NY:SYSCO
WORKING_DIRECTORY=/tmp

注意:
ソース・ホストと宛先ホストの間にSSH接続が存在する場合は、Hybrid Gatewayパラメータを削除してください。

5. データを宛先データベースにインポートするための動詞を入力します(emcli dbimport -input_file=data:/u01/files/dbimport.props)。

注意:
宛先をデータベースまたはプラガブル・データベースにクローニングするには、プロパティ・ファイル内にDESTINATION_TARGET_TYPEオプションで必要な値を入力してください。データベースの場合はoracle_databaseと入力し、PDBの場合はoracle_pdbと入力します。

プロパティ・ファイルの例:

#-----------------------------------------------#
#         DESTINATION                           #
#-----------------------------------------------#
DESTINATION_TARGET=SS_OPC_DB
DESTINATION_TARGET_TYPE=oracle_database
DATABASE_CREDENTIAL=SYSDBA:SYS
HOST_NAMED_CREDENTIAL=AE_NC:SYS

#-----------------------------------------------#
#         PROFILE                               #
#-----------------------------------------------#
PROFILE_LOCATION=Database Provisioning Profiles/12.1.0.1.0/linux_x64/Export Dump of Sample schemas10

#-----------------------------------------------#
#         SCHEMA DETAILS                        #
#-----------------------------------------------#
REMAP_SCHEMA_LIST.0=HR:HR
REMAP_SCHEMA_LIST.1=OE:OE
REMAP_SCHEMA_LIST.2=PM:PM
REMAP_SCHEMA_LIST.3=IX:IX
REMAP_SCHEMA_LIST.4=SH:SH
REMAP_SCHEMA_LIST.5=BI:BI
REMAP_TABLESPACE_LIST.0=EXAMPLE:MYTBSP1
REMAP_TABLESPACE_LIST.1=USERS:MYTBSP1
REMAP_TABLESPACE_LIST.2=SYSTEM:MYTBSP1
DEGREE_OF_PARALLELISM=1
DUMP_FILE_LIST.0=/scratch/ae/dumpdir/samplschemas.dmp
IMPORT_LOG_FILE_DIRECTORY=DATA_PUMP_DIR

15.6 Oracle Cloud内でのクローニング

Oracle Cloud内でデータベースまたはプラガブル・データベースをクローニングする場合は、次のユースケースを参照してください。

- Oracle PaaS内でのPDBのクローニング

- Oracle PaaS内でのDBのクローニング

15.6.1 Oracle PaaS内でのPDBのクローニング

Oracle Cloud内でプラガブル・データベースをクローニングするには、次のいずれかのソリューションを使用できます。

- 14.3.1項「クローン・ウィザードを使用したフル・クローン・プラガブル・データベースの作成」

- 14.3.2項「EM CLIを使用したフル・クローン・プラガブル・データベースの作成」

15.6.2 Oracle PaaS内でのDBのクローニング

Oracle Cloud内でデータベースをクローニングするには、次のいずれかのソリューションを使用できます。

- 14.1.1項「クローン・ウィザードを使用したフル・クローン・データベースの作成」

- 14.1.2項「EM CLIを使用したフル・クローン・データベースの作成」。

16 データベースの作成

この章では、Oracle Enterprise Manager Cloud Control(Cloud Control)を使用して、データベースを作成する方法について説明します。この章の具体的な内容は次のとおりです。

- データベースの作成の概要

- Oracle Databaseの作成

- Oracle Real Application Clustersデータベースの作成

- Oracle Real Application Clusters One Nodeデータベースの作成

注意:
この章には、単一インスタンス、Oracle Real Application Clusters (Oracle RAC)およびOracle Real Application Clusters One Node (Oracle RAC One Node)コンテナ・データベースの作成に関する情報も含まれます。
Oracle Database 12cリリース1 (12.1)以降がホストにインストールされている場合のみ、コンテナ・データベースをホストに作成できます。コンテナ・データベースの詳細は、『Oracle Database管理者ガイド』を参照してください。

16.1 データベースの作成の概要

この項では、この章に取り組むための手引きとして、データベースの作成の概要を説明します。この項は、Cloud Controlを使用したデータベースの作成を成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表16-1 Oracleデータベースの作成の概要

ステップ

説明

参照リンク

ステップ1

ユースケースの選択

ここでは、データベースの作成のユースケースのいくつかを説明します。ご自身の要件に最適なユースケースを選択してください。

- Oracle単一インスタンス・データベースの作成の詳細は、第16.2項を参照してください。

- Oracle RACデータベースの作成の詳細は、第16.3項を参照してください。

- Oracle RAC One Nodeデータベースの作成の詳細は、第16.4項を参照してください。

ステップ2

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

- Oracle Databaseの作成の前提条件の詳細は、第16.2.1項を参照してください。

- Oracle RACデータベースの作成の前提条件の詳細は、第16.3.2項を参照してください。

- Oracle RAC One Nodeデータベースの作成の前提条件の詳細は、第16.4.1項を参照してください。

ステップ3

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行してデータベースを正常に作成します。

- 単一インスタンス・データベースを作成するには、第16.2.2項を参照してください。

- Oracle RACデータベースを作成するには、第16.3.2項を参照してください。

- Oracle RAC One Nodeデータベースを作成するには、第16.4.2項を参照してください。

16.2 Oracleデータベースの作成

この項では、Oracleデータベース(単一インスタンス・データベースとも呼ばれます)の作成について説明します。

重要:
この項で説明されている情報を使用して、単一インスタンス・コンテナ・データベースを作成することもできます。
Oracle Database 12cリリース1 (12.1)以降がホストにインストールされている場合のみ、コンテナ・データベースをホストに作成できます。コンテナ・データベースの詳細は、『Oracle Database管理者ガイド』を参照してください。

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

- Oracleデータベースを作成するための前提条件

- Oracleデータベースを作成する手順

16.2.1 Oracleデータベースを作成するための前提条件

Cloud Controlを使用して単一インスタンス・データベースを作成するには、次の前提条件を満たしていることを確認してください。

1. 第2章で説明しているインフラストラクチャの前提条件を必ず満たしてください。

2. データベース・テンプレートを作成し、ソフトウェア・ライブラリまたはOracleホームに格納したことを確認してください。データベース・テンプレートの作成の詳細は、第4.3.8項参照してください。

3. 作成するデータベースのOracleホームがインストールされており、Oracleホームの所有者の資格証明をもっていることが必要です。プロビジョニング・データベース・デプロイメント・プロシージャ・ウィザードからデータベースの作成ウィザードを起動する場合、Oracleホームを先にインストールする必要はありません。この場合、プロシージャ・インタビュー時にOracleホームの検証はスキップされ、デプロイメント・プロシージャの実行時に実行されます。

4. 対応するデータベース・バージョンをサポートするデータベース・プラグインがOMSおよびエージェントにデプロイされている必要があります。プラグインのデプロイの詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

5. データベースの作成に十分な領域、およびリカバリ・ファイルの場所に対する書込み権限があることを確認してください。

6. データベース作成用としてソフトウェア・ライブラリのテンプレートを使用している場合、ステージング場所に対する書込み権限が必要です。

7. 自動ストレージ管理(ASM)を記憶域として使用する場合、データベースを作成する前にASMインスタンスおよびディスク・グループを構成する必要があります。

8. データベース・テンプレートを作成しているCloud Controlユーザーには、Cloud ControlでのCONNECT_ANY_TARGET権限が必要です。

16.2.2 Oracleデータベースを作成する手順

Oracleデータベースを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. データベースのプロビジョニング・ページで、Oracleデータベース・デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracleデータベースの作成ウィザードが起動します。

3. データベース・バージョンおよびタイプ・ページで、データベースの「バージョン」を選択し、「Oracle単一インスタンス・データベース」を選択します。
「ホスト」セクションで、データベースをプロビジョニングするホストおよびOracleホームを選択します。すべてのホストを対象として「ホスト資格証明」と「共通Oracleホーム」を指定することもできます。「ホスト資格証明」は「名前付き資格証明」または「優先資格証明」のいずれかにできます。

プラス(+)記号のアイコンをクリックしてホストを追加します。ホストを選択して「Oracleホーム」を指定します。「ホスト資格証明」を選択するか新規に追加します。プラス記号のアイコンをクリックして、新規の資格証明を追加し、「ユーザー名」、「パスワード」および「実行権限」を指定して資格証明を保存します。

「次へ」をクリックします。

4. データベース・テンプレート・ページでは、データベース・テンプレートの場所を選択します。この場所はソフトウェア・ライブラリまたはOracleホームのいずれかにできます。選択したテンプレートは、選択したOracleホームのバージョンと互換性を保っている必要があります。
「ソフトウェア・ライブラリ」を選択した場合、検索アイコンをクリックし、ソフトウェア・ライブラリからテンプレートを選択します。「管理対象ホスト上の一時的な格納場所」を指定します。この場所は、データベースを作成するすべてのホスト上に存在する必要があります。

「テンプレートの詳細の表示」をクリックし、選択したテンプレートの詳細を表示します。初期化パラメータ、表領域、データファイル、REDOログ・グループ、共通オプション、およびテンプレートの他の詳細を表示できます。

「Oracleホーム」を選択した場合は、「Oracleホーム」からテンプレートを選択します。デフォルトの場所はORACLE_HOME/assistants/dbca/templatesです。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

5. 「IDおよび配置」ページでは、データベース構成の詳細を指定します。「グローバル・データベース名」および「SID」接頭辞を指定します。
「データベースの統合」セクションで、コンテナ・データベースを作成する場合は「コンテナ・データベースとして作成」を選択します。デフォルトでは、空のコンテナ・データベースが作成されます。1つ以上のプラガブル・データベースをそのコンテナ・データベースに追加する場合、「1つ以上のPDBを持つコンテナ・データベースの作成」を選択し、PDBの数を設定します。

複数のPDBを作成する場合、ここで入力する一意の名前はすべてのクローニングされるPDBの接頭辞として使用され、接尾辞はPDBの数を示す数値です。

たとえば、accountsPDBという名前で5つのPDBを作成すると、PDBは、accountsPDB1、accountsPDB2、accountsPDB3、accountsPDB4、およびaccountsPDB5という名前で作成されます。

SYS、SYSTEMおよびDBSNMPデータベース・アカウントに対し、「データベース資格証明」を指定します。

データベース・バージョン12.1以上およびMicrosoft Windowsオペレーティング・システムの場合は、Oracleホームのインストール時に指定されたMicrosoft Windowsユーザーに対してデータベース・サービスが構成されます。このユーザーは、Oracleソフトウェアによって実行されるすべてのサービスを所有します。「OracleホームのWindowsユーザー資格証明」セクションで、データベース・サービスを構成するためのMicrosoft Windowsユーザー・アカウントのホスト資格証明を指定します。既存の名前付き資格証明を選択するか、新しい資格証明を指定します。新しい資格証明を指定するには、ユーザー名およびパスワードを入力します。これらの資格証明を保存し、優先資格証明として設定することもできます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

注意:

- SIDは1つのホスト上の1つのデータベースに対して一意である必要があります。つまり、あるホスト上の1つのデータベースに割り当てられたSIDは、同じホスト上の別のデータベースでは再使用できませんが、別のホスト上の別のデータベースでは再使用できます。たとえば、1つのホスト(host1)に2つのデータベース(db1およびdb2)がある場合、そのSIDは一意である必要があります。しかし、別のホスト(host2)に3つ目のデータベースをインストールする場合、そのSIDはdb1やdb2でもかまいません。

- グローバル・データベース名は、1つのホスト上の1つのデータベースに対しても、異なるホスト間でのデータベースに対しても一意である必要があります。つまり、あるホスト上の1つのデータベースに割り当てられたグローバル・データベース名は、同じホスト上の別のデータベースでも、別のホスト上の別のデータベースでも再使用できません。たとえば、1つのホスト(host1)に2つのデータベース(db1およびdb2)がある場合、そのグローバル・データベース名は一意である必要があります。さらに、別のホスト(host2)に3つ目のデータベースをインストールする場合、このデータベースのグローバル・データベース名は、Cloud Controlに登録された他のすべての名前とは異なり、一意である必要があります。

- ここで指定したデータベースの資格証明がすべての宛先ホストで使用されます。しかし、プロビジョニング後に、データベースのパスワードを変更する場合は、手動で変更する必要があります。

6. 記憶域の場所ページで、記憶域タイプとして「ファイル・システム」または「自動ストレージ管理(ASM)」を選択します。
ファイル・システムを使用する場合は、「ファイルシステム」を選択し、データ・ファイルのある場所へのフルパスを指定します。たとえば、%ORACLE_BASE%/oradataや/u01/product/db/oradataなどです。

ASMを使用する場合は、「自動ストレージ管理(ASM)」を選択して懐中電灯アイコンをクリックし、ディスク・グループ名を選択してASMSNMPパスワードを指定します。「ディスク・グループ名リスト」ウィンドウに、すべての宛先ホストで共通のディスク・グループが表示されます。

「データベース・ファイルの場所」セクションで、データファイル、一時ファイル、REDOログおよび制御ファイルを格納する場所を指定します。

- テンプレートからのデータベース・ファイルの場所を使用を選択し、使用されているテンプレートからのデフォルトを選択します。

- 全データベース・ファイルの共通の場所の使用を選択し、別の場所を指定します。
「REDOログおよび制御ファイルを多重化」セクションで「Oracle Managed Files(OMF)の使用」オプションを選択すると、REDOログ・ファイルおよび制御ファイルの重複コピーを格納できます。多重化によって強力なフォルト・トレランスが提供されます。最大5つの場所を指定できます。

「リカバリ・ファイルの場所」セクションで、「データベース・ファイルの場所と同じ記憶域タイプを使用してください」を選択し、リカバリ・ファイルの記憶域タイプにデータベース・ファイルと同じタイプを使用します。「フラッシュ・リカバリ領域の使用」を選択し、リカバリ関連ファイルの場所および高速リカバリ領域サイズを指定します。

「アーカイブ有効化」を選択してアーカイブのログを有効にします。「アーカイブ・ロブの場所を指定してください」をクリックし、最大9箇所のアーカイブ・ログの場所を指定します。ログの場所を指定しない場合、ログはデフォルトの場所に保存されます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

7. 初期化パラメータ・ページで、メモリー管理タイプとして「自動メモリー管理」または「自動共有メモリー管理」を選択します。「メモリー設定として使用可能メモリーの割合」を選択し、メモリー設定として使用可能物理メモリーの割合を指定します。自動共有メモリー管理の場合は、「SGA合計」および「PGA合計」を指定します。自動メモリー管理の場合は、「Oracleで使用するメモリーの合計」を指定します。
「データベースのサイズ設定」セクションで、「ブロック・サイズ」および「プロセス」の数を指定します。データベース・テンプレート・ページでデータファイルとともにデータベース・テンプレートを選択した場合、ブロック・サイズは編集できません。

「ホストCPU数」を指定します。指定できる最大CPU数はホストに存在するCPUの数と同じです。

「キャラクタ・セット」セクションでは、デフォルトのキャラクタ・セットを選択します。デフォルトのキャラクタ・セットはロケールおよびオペレーティング・システムに基づいています。

各国語キャラクタ・セットを選択します。デフォルトはAL16UTF16です。

「データベース接続モード」セクションでは、専用サーバー・モードを選択します。共有サーバー・モードについては、共有サーバーの数を指定します。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

8. 「追加の構成オプション」に、Oracleホームから実行されているすべての使用可能なリスナーおよびグリッド・インフラストラクチャ・リスナーがリストされます。リスナーを選択するか、新規リスナーを作成できます。データベースに登録する複数のリスナーを選択できます。新規リスナーを作成するには、「リスナー名」および「ポート」を指定します。データベース・スキーマを選択し、カスタム・スクリプトがある場合はこれを指定します。データベースを作成するホストまたはソフトウェア・ライブラリからカスタム・スクリプトを選択します。複数のホストを選択した場合は、ソフトウェア・ライブラリからのみスクリプトを指定できます。
データベース・テンプレート・ページで「構造のみ」データベース・テンプレートを選択した場合、データベース・オプションを表示および編集することもできます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

9. 「スケジュール」ページで、デプロイメント・インスタンス名とデプロイ用のスケジュールを指定します。プロシージャを即時実行する場合、デフォルトで選択されている「即時」を選択します。プロシージャを後で実行する場合は、「後で」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。「次へ」をクリックします。

10. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。「分析」をクリックして、前提条件を確認し、プロビジョニングのすべての要件が満たされていることを確認します。

11. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各ステップの「ステータス」リンクをクリックし、各ステップの実行の詳細を表示します。「デバッグ」をクリックしてデバッグのロギング・レベルを設定し、「停止」をクリックしてプロシージャの実行を停止できます。

16.3 Oracle Real Application Clustersデータベースの作成

この項では、Oracle Real Application Clustersデータベースの作成について説明します。

重要:
この項で説明されている情報を使用して、Oracle Real Application Clustersコンテナ・データベースを作成することもできます。
Oracle Database 12cリリース1 (12.1)以降がホストにインストールされている場合のみ、コンテナ・データベースをホストに作成できます。コンテナ・データベースの詳細は、『Oracle Database管理者ガイド』を参照してください。

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

- Oracle Real Application Clustersデータベースを作成するための前提条件

- Oracle Real Application Clustersデータベースを作成する手順

16.3.1 Oracle Real Application Clustersデータベースを作成するための前提条件

Cloud Controlを使用してOracle RACデータベースを作成するには、次の前提条件を満たしていることを確認してください。

1. 第2章で説明しているインフラストラクチャの前提条件を必ず満たしてください。

2. データベース・テンプレートを作成し、ソフトウェア・ライブラリまたはOracleホームに格納したことを確認してください。データベース・テンプレートの作成の詳細は、第4.3.8項参照してください。

3. 作成するデータベースのOracleホームがインストールされており、Oracleホームの所有者の資格証明をもっていることが必要です。プロビジョニング・データベース・デプロイメント・プロシージャ・ウィザードからデータベースの作成ウィザードを起動する場合、Oracleホームを先にインストールする必要はありません。この場合、プロシージャ・インタビュー時にOracleホームの検証はスキップされ、デプロイメント・プロシージャの実行時に実行されます。

4. 対応するデータベース・バージョンをサポートするデータベース・プラグインがOMSおよびエージェントにデプロイされている必要があります。プラグインのデプロイの詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

5. データベースの作成に十分な領域、およびリカバリ・ファイルの場所に対する書込み権限があることを確認してください。

6. データベース作成用としてソフトウェア・ライブラリのテンプレートを使用している場合、ステージング場所に対する書込み権限が必要です。

7. Oracle Real Application Clustersデータベースを作成する場合、グリッド・インフラストラクチャがインストールおよび構成されていることが必要です。プロビジョニング・データベース・デプロイメント・プロシージャ・ウィザードからデータベースの作成ウィザードを起動する場合、グリッド・インフラストラクチャをインストールおよび構成する必要はありません。この場合、プロシージャ・インタビュー時にグリッド・インフラストラクチャの検証はスキップされ、デプロイメント・プロシージャの実行時に実行されます。

8. 自動ストレージ管理(ASM)を記憶域として使用する場合、データベースを作成する前にASMインスタンスおよびディスク・グループを構成する必要があります。

9. データベース・テンプレートを作成しているCloud Controlユーザーには、Cloud ControlでのCONNECT_ANY_TARGET権限が必要です。

16.3.2 Oracle Real Application Clustersデータベースを作成する手順

Oracle Real Application Clusters (Oracle RAC)データベースを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. データベースのプロビジョニング・ページで、Oracleデータベース・デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracleデータベースの作成ウィザードが起動します。

3. データベース・バージョンおよびタイプ・ページで、データベースの「バージョン」を選択し、「Oracle Real Application Clusters (Oracle RAC)データベース」を選択します。
「クラスタ」セクションで、クラスタおよびOracleホームを選択します。クラスタ上でデータベースを作成するための参照として使用する検証を実行するための参照ホストを選択します。

「クラスタ資格証明」を選択するか新規に追加します。プラス記号のアイコンをクリックして、新規の資格証明を追加し、「ユーザー名」、「パスワード」および「実行権限」を指定して資格証明を保存します。

「次へ」をクリックします。

4. データベース・テンプレート・ページでは、データベース・テンプレートの場所を選択します。この場所はソフトウェア・ライブラリまたはOracleホームのいずれかにできます。選択したテンプレートは、選択したOracleホームのバージョンと互換性を保っている必要があります。
「ソフトウェア・ライブラリ」を選択した場合、検索アイコンをクリックし、ソフトウェア・ライブラリからテンプレートを選択します。「管理対象ホスト上の一時的な格納場所」を指定します。この場所は、以前に選択した参照ノード上に存在する必要があります。

「テンプレートの詳細の表示」をクリックし、選択したテンプレートの詳細を表示します。初期化パラメータ、表領域、データファイル、REDOログ・グループ、共通オプション、およびテンプレートの他の詳細を表示できます。

「Oracleホーム」を選択した場合は、「Oracleホーム」からテンプレートを選択します。デフォルトの場所はORACLE_HOME/assistants/dbca/templatesです。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

5. IDおよび配置ページで、Oracle RACデータベースのタイプ(「管理されたポリシー」または「管理されたAdmin」)を選択します。また、「グローバル・データベース名」および「SID」接頭辞を指定します。
管理者管理型データベースの場合、クラスタ・データベースを作成するノードを選択します。データベースのバージョンおよびタイプ・ページで参照ノードとして選択したノードを指定する必要があります。

ポリシー管理型データベースの場合、データベースの作成に使用するサーバー・プールを既存のサーバー・プールのリストから選択するか、新規サーバー・プールの作成を選択します。ポリシー管理型データベースは、データベース・バージョン11.2以上に対して作成できます。11.2未満のデータベース・バージョンの場合、ノードを選択してOracle RACデータベースを作成する必要があります。

「データベースの統合」セクションで、コンテナ・データベースを作成する場合は「コンテナ・データベースとして作成」を選択します。デフォルトでは、空のコンテナ・データベースが作成されます。1つ以上のプラガブル・データベースをそのコンテナ・データベースに追加する場合、「1つ以上のPDBを持つコンテナ・データベースの作成」を選択し、PDBの数を設定します。

複数のPDBを作成する場合、ここで入力する一意の名前はすべてのクローニングされるPDBの接頭辞として使用され、接尾辞はPDBの数を示す数値です。

たとえば、accountsPDBという名前で5つのPDBを作成すると、PDBは、accountsPDB1、accountsPDB2、accountsPDB3、accountsPDB4、およびaccountsPDB5という名前で作成されます。

SYS、SYSTEM、DBSNMPの「データベース資格証明」を指定します。

データベース・バージョン12.1以上およびMicrosoft Windowsオペレーティング・システムの場合は、Oracleホームのインストール時に指定されたMicrosoft Windowsユーザーに対してデータベース・サービスが構成されます。このユーザーは、Oracleソフトウェアによって実行されるすべてのサービスを所有します。「OracleホームのWindowsユーザー資格証明」セクションで、データベース・サービスを構成するためのMicrosoft Windowsユーザー・アカウントのホスト資格証明を指定します。既存の名前付き資格証明を選択するか、新しい資格証明を指定します。新しい資格証明を指定するには、ユーザー名およびパスワードを入力します。これらの資格証明を保存し、優先資格証明として設定することもできます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

6. 記憶域の場所ページで、記憶域タイプとして「ファイル・システム」または「自動ストレージ管理(ASM)」を選択します。
「データベース・ファイルの場所」セクションで、データファイル、一時ファイル、REDOログおよび制御ファイルを格納する場所を指定します。これらの場所は、クラスタ・ファイル・システムの場所やASMディスク・グループなどの共有記憶域上にある必要があります。

- テンプレートからのデータベース・ファイルの場所を使用を選択し、使用されているテンプレートからのデフォルトを選択します。

- 全データベース・ファイルの共通の場所の使用を選択し、別の場所を指定します。
「REDOログおよび制御ファイルを多重化」セクションで「Oracle Managed Files(OMF)の使用」オプションを選択すると、REDOログ・ファイルおよび制御ファイルの重複コピーを格納できます。多重化によって強力なフォルト・トレランスが提供されます。最大5つの場所を指定できます。

「リカバリ・ファイルの場所」セクションで、「フラッシュ・リカバリ領域の使用」を選択し、リカバリ関連ファイルの場所および高速リカバリ領域サイズを指定します。

「アーカイブ・ログの設定」セクションで、「アーカイブ有効化」を選択し、アーカイブ・ロギングを有効にします。「アーカイブ・ログの場所を指定してください」で、最大9箇所のアーカイブ・ログの場所を指定できます。ログの場所を指定しない場合、ログはデフォルトの場所に保存されます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

7. 初期化パラメータ・ページで、メモリー管理タイプとして「自動メモリー管理」または「自動共有メモリー管理」を選択します。「メモリー設定として使用可能メモリーの割合」を選択し、メモリー設定として使用可能物理メモリーの割合を指定します。自動共有メモリー管理の場合は、「SGA合計」および「PGA合計」を指定します。自動メモリー管理の場合は、「Oracleで使用するメモリーの合計」を指定します。
「データベースのサイズ設定」セクションで、「ブロック・サイズ」および「プロセス」の数を指定します。データベース・テンプレート・ページでデータファイルとともにデータベース・テンプレートを選択した場合、ブロック・サイズは編集できません。

「ホストCPU数」を指定します。指定できる最大CPU数はホストに存在するCPUの数と同じです。

「キャラクタ・セット」セクションでは、デフォルトのキャラクタ・セットを選択します。デフォルトのキャラクタ・セットはロケールおよびオペレーティング・システムに基づいています。

各国語キャラクタ・セットを選択します。デフォルトはAL16UTF16です。

「データベース接続モード」セクションでは、専用サーバー・モードを選択します。共有サーバー・モードについては、共有サーバーの数を指定します。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

8. 追加の構成オプション・ページで、ソフトウェア・ライブラリからカスタム・スクリプトを選択します。データベース・テンプレート・ページで「構造のみ」データベース・テンプレートを選択した場合、データベース・オプションを表示および編集することもできます。
「ロック」アイコンをクリックし、フィールドをロックします。「次へ」をクリックします。

9. 「スケジュール」ページで、デプロイメント・インスタンス名とデプロイ用のスケジュールを指定します。プロシージャを即時実行する場合、デフォルトで選択されている「即時」を選択します。プロシージャを後で実行する場合は、「後で」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。「次へ」をクリックします。

10. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。「分析」をクリックして、前提条件を確認し、プロビジョニングのすべての要件が満たされていることを確認します。

11. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各ステップの「ステータス」リンクをクリックし、各ステップの実行の詳細を表示します。「デバッグ」をクリックしてデバッグのロギング・レベルを設定し、「停止」をクリックしてプロシージャの実行を停止できます。

16.4 Oracle Real Application Clusters One Nodeデータベースの作成

この項では、Oracle Real Application Clusters One Nodeデータベース(Oracle RAC One Nodeデータベースとも呼ばれます)の作成について説明します。

重要:
この項で説明されている情報を使用して、Oracle Real Application Clusters One Nodeコンテナ・データベースを作成することもできます。
Oracle Database 12cリリース1 (12.1)以降がホストにインストールされている場合のみ、コンテナ・データベースをホストに作成できます。コンテナ・データベースの詳細は、『Oracle Database管理者ガイド』を参照してください。

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

- Oracle RAC One Nodeデータベースを作成するための前提条件

- Oracle Real Application Clusters One Nodeデータベースを作成する手順

16.4.1 Oracle RAC One Nodeデータベースを作成するための前提条件

Cloud Controlを使用してOracle RAC Oneデータベースを作成するには、次の前提条件を満たしていることを確認してください。

1. 第2章で説明しているインフラストラクチャの前提条件を必ず満たしてください。

2. データベース・テンプレートを作成し、ソフトウェア・ライブラリまたはOracleホームに格納したことを確認してください。データベース・テンプレートの作成の詳細は、第4.3.8項参照してください。

3. 作成するデータベースのOracleホームがインストールされており、Oracleホームの所有者の資格証明をもっていることが必要です。プロビジョニング・データベース・デプロイメント・プロシージャ・ウィザードからデータベースの作成ウィザードを起動する場合、Oracleホームを先にインストールする必要はありません。この場合、プロシージャ・インタビュー時にOracleホームの検証はスキップされ、デプロイメント・プロシージャの実行時に実行されます。

4. 対応するデータベース・バージョンをサポートするデータベース・プラグインがOMSおよびエージェントにデプロイされている必要があります。プラグインのデプロイの詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

5. データベースの作成に十分な領域、およびリカバリ・ファイルの場所に対する書込み権限があることを確認してください。

6. データベース作成用としてソフトウェア・ライブラリのテンプレートを使用している場合、ステージング場所に対する書込み権限が必要です。

7. Oracle Real Application Clustersデータベースを作成する場合、グリッド・インフラストラクチャがインストールおよび構成されていることが必要です。プロビジョニング・データベース・デプロイメント・プロシージャ・ウィザードからデータベースの作成ウィザードを起動する場合、グリッド・インフラストラクチャをインストールおよび構成する必要はありません。この場合、プロシージャ・インタビュー時にグリッド・インフラストラクチャの検証はスキップされ、デプロイメント・プロシージャの実行時に実行されます。

8. 自動ストレージ管理(ASM)を記憶域として使用する場合、データベースを作成する前にASMインスタンスおよびディスク・グループを構成する必要があります。

9. データベース・テンプレートを作成しているCloud Controlユーザーには、Cloud ControlでのCONNECT_ANY_TARGET権限が必要です。

16.4.2 Oracle Real Application Clusters One Nodeデータベースを作成する手順

Oracle Real Application Clusters One Nodeデータベースを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. データベースのプロビジョニング・ページで、Oracleデータベース・デプロイメント・プロシージャを選択し、「起動」をクリックします。Oracleデータベースの作成ウィザードが起動します。

3. データベース・バージョンおよびタイプ・ページで、データベースの「バージョン」を選択し、「Oracle RAC One Nodeデータベース」を選択します。
「クラスタ」セクションで、クラスタおよびOracleホームを選択します。クラスタ上でデータベースを作成するための参照として使用する検証を実行するための参照ホストを選択します。

「クラスタ資格証明」を選択するか新規に追加します。プラス記号のアイコンをクリックして、新規の資格証明を追加し、「ユーザー名」、「パスワード」および「実行権限」を指定して資格証明を保存します。

「次へ」をクリックします。

4. データベース・テンプレート・ページでは、データベース・テンプレートの場所を選択します。この場所はソフトウェア・ライブラリまたはOracleホームのいずれかにできます。選択したテンプレートは、選択したOracleホームのバージョンと互換性を保っている必要があります。
「ソフトウェア・ライブラリ」を選択した場合、検索アイコンをクリックし、ソフトウェア・ライブラリからテンプレートを選択します。「管理対象ホスト上の一時的な格納場所」を指定します。この場所は、以前に選択した参照ノード上に存在する必要があります。

「テンプレートの詳細の表示」をクリックし、選択したテンプレートの詳細を表示します。初期化パラメータ、表領域、データファイル、REDOログ・グループ、共通オプション、およびテンプレートの他の詳細を表示できます。

「Oracleホーム」を選択した場合は、「Oracleホーム」からテンプレートを選択します。デフォルトの場所はORACLE_HOME/assistants/dbca/templatesです。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

5. 識別および配置ページで、クラスタ・データベースを作成するノードを選択します。「グローバル・データベース名」および「SID」接頭辞を指定します。Oracle RACデータベースのタイプとして、「管理されたポリシー」または「管理されたAdmin」を選択します。「サービス名」を指定します。
「データベースの統合」セクションで、コンテナ・データベースを作成する場合は「コンテナ・データベースとして作成」を選択します。デフォルトでは、空のコンテナ・データベースが作成されます。1つ以上のプラガブル・データベースをそのコンテナ・データベースに追加する場合、「1つ以上のPDBを持つコンテナ・データベースの作成」を選択し、PDBの数を設定します。

複数のPDBを作成する場合、ここで入力する一意の名前はすべてのクローニングされるPDBの接頭辞として使用され、接尾辞はPDBの数を示す数値です。

たとえば、accountsPDBという名前で5つのPDBを作成すると、PDBは、accountsPDB1、accountsPDB2、accountsPDB3、accountsPDB4、およびaccountsPDB5という名前で作成されます。

SYS、SYSTEMおよびDBSNMPデータベース・アカウントに対し、「データベース資格証明」を指定します。

データベース・バージョン12.1以上およびMicrosoft Windowsオペレーティング・システムの場合は、Oracleホームのインストール時に指定されたMicrosoft Windowsユーザーに対してデータベース・サービスが構成されます。このユーザーは、Oracleソフトウェアによって実行されるすべてのサービスを所有します。「OracleホームのWindowsユーザー資格証明」セクションで、データベース・サービスを構成するためのMicrosoft Windowsユーザー・アカウントのホスト資格証明を指定します。既存の名前付き資格証明を選択するか、新しい資格証明を指定します。新しい資格証明を指定するには、ユーザー名およびパスワードを入力します。これらの資格証明を保存し、優先資格証明として設定することもできます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

6. 記憶域の場所ページで、記憶域タイプとして「ファイル・システム」または「自動ストレージ管理(ASM)」を選択します。
「データベース・ファイルの場所」セクションで、データファイル、一時ファイル、REDOログおよび制御ファイルを格納する場所を指定します。

- テンプレートからのデータベース・ファイルの場所を使用を選択し、使用されているテンプレートからのデフォルトを選択します。

- 全データベース・ファイルの共通の場所の使用を選択し、別の場所を指定します。
「REDOログおよび制御ファイルを多重化」セクションで「Oracle Managed Files(OMF)の使用」オプションを選択すると、REDOログ・ファイルおよび制御ファイルの重複コピーを格納できます。多重化によって強力なフォルト・トレランスが提供されます。最大5つの場所を指定できます。

「リカバリ・ファイルの場所」セクションで、「フラッシュ・リカバリ領域の使用」を選択し、リカバリ関連ファイルの場所および高速リカバリ領域サイズを指定します。

「アーカイブ・ログの設定」セクションで、「アーカイブ有効化」を選択し、アーカイブ・ロギングを有効にします。「アーカイブ・ログの場所を指定してください」で、最大9箇所のアーカイブ・ログの場所を指定できます。ログの場所を指定しない場合、ログはデフォルトの場所に保存されます。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

7. 初期化パラメータ・ページで、メモリー管理タイプとして「自動メモリー管理」または「自動共有メモリー管理」を選択します。「メモリー設定として使用可能メモリーの割合」を選択し、メモリー設定として使用可能物理メモリーの割合を指定します。自動共有メモリー管理の場合は、「SGA合計」および「PGA合計」を指定します。自動メモリー管理の場合は、「Oracleで使用するメモリーの合計」を指定します。
「データベースのサイズ設定」セクションで、「ブロック・サイズ」および「プロセス」の数を指定します。データベース・テンプレート・ページでデータファイルとともにデータベース・テンプレートを選択した場合、ブロック・サイズは編集できません。

「ホストCPU数」を指定します。指定できる最大CPU数はホストに存在するCPUの数と同じです。

「キャラクタ・セット」セクションでは、デフォルトのキャラクタ・セットを選択します。デフォルトのキャラクタ・セットはロケールおよびオペレーティング・システムに基づいています。

各国語キャラクタ・セットを選択します。デフォルトはAL16UTF16です。

「データベース接続モード」セクションでは、専用サーバー・モードを選択します。共有サーバー・モードについては、共有サーバーの数を指定します。

「ロック」アイコンをクリックし、構成したフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

8. 追加の構成オプション・ページで、ソフトウェア・ライブラリからカスタム・スクリプトを選択します。データベース・テンプレート・ページで「構造のみ」データベース・テンプレートを選択した場合、データベース・オプションを表示および編集することもできます。「ロック」アイコンをクリックし、フィールドをロックします。「次へ」をクリックします。

9. 「スケジュール」ページで、デプロイメント・インスタンス名とデプロイ用のスケジュールを指定します。プロシージャを即時実行する場合、デフォルトで選択されている「即時」を選択します。プロシージャを後で実行する場合は、「後で」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。「次へ」をクリックします。

10. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。「分析」をクリックして、前提条件を確認し、プロビジョニングのすべての要件が満たされていることを確認します。

11. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各ステップの「ステータス」リンクをクリックし、各ステップの実行の詳細を表示します。「デバッグ」をクリックしてデバッグのロギング・レベルを設定し、「停止」をクリックしてプロシージャの実行を停止できます。

17 プラガブル・データベースの管理

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用して、プラガブル・データベース(PDB)を管理する方法について説明します。この章の具体的な内容は次のとおりです。

- プラガブル・データベースの管理の概要

- プラガブル・データベースの管理の概要

- プラガブル・データベースのプロビジョニング

- プラガブル・データベースの削除

- プラガブル・データベース・ジョブの詳細の表示

- プラガブル・データベースの管理

17.1 プラガブル・データベースの管理の概要

この項では、この章に取り組むための手引きとして、新しいプラガブル・データベース(PDB)の作成、PDBのクローニング、非コンテナ・データベース(CDB)のPDBとしての移行、PDBの切断およびPDBの削除に関する手順の概要を説明します。この項は、Cloud Controlを使用したこれらのタスクの実行を成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表17-1 プラガブル・データベースの管理の概要

ステップ

説明

参照リンク

ステップ1

概要の確認

PDBの概念の概要を確認します。

PDBの概念の概要を確認するには、第17.2項を参照してください。

ステップ2

ユースケースの選択

次から、要件に最も一致するユースケースを選択してください。

- 新規PDBの作成

- 切断されたPDBの接続

- PDBのクローニング

- PDBとしての非CDBの移行

- PDBの切断および削除

- PDBの削除

ステップ3

前提条件の確認

選択したユースケースの前提条件を満たします。

- 新しいPDBの作成の前提条件を満たすには、第17.3.1.1項を参照してください。

- 切断されたPDBを接続するための前提条件を満たすには、第17.3.2.1項を参照してください。

- PDBのクローニングの前提条件を満たすには、第17.3.3.1項を参照してください。

- 非CDBのPDBとしての移行の前提条件を満たすには、第17.3.4.1項を参照してください。

- PDBの切断および削除の前提条件を満たすには、第17.4.1.1項を参照してください。

- PDBの削除の前提条件を満たすには、第17.4.2.1項を参照してください。

ステップ4

プロシージャの実行

選択したユースケースの手順に従います。

- 新しいPDBを作成するには、第17.3.1.2項を参照してください。

- 切断されたPDBに接続するには、第17.3.2.2項を参照してください。

- PDBをクローニングするには、第17.3.3.2項を参照してください。

- 非CDBをPDBとして移行するには、第17.3.4.2項を参照してください。

- PDBを切断および削除するには、第17.4.1.2項を参照してください。

- PDBを削除するには、第17.4.2.2項を参照してください。

17.2 プラガブル・データベースの管理の概要

Oracle Databaseには、Oracle Netクライアントに個別のデータベースとして表示される、スキーマ、スキーマ・オブジェクト、および非スキーマ・オブジェクトのポータブル・コレクションを含めることができます。この自己完結型コレクションは、プラガブル・データベース(PDB)と呼ばれます。マルチテナントのコンテナ・データベース(CDB)は、1つ以上のPDBを含むデータベースです。Oracle Database 12cリリース1 (12.1)以降のバージョンでは、単一のCDB内に多数のPDBを作成できます。データベースに接続するアプリケーションは、PDBおよびOracle Databaseの以前のバージョン(12.1より前)を同様な方法で参照します。

Cloud Controlで管理者は、CDBのプロビジョニング、PDBのプロビジョニング(シードまたは切断されたPDBから)、既存のPDBのクローニング、非CDBのPDBとしての移行、PDBの切断、PDBの削除を含むPDBのライフサイクル全体の管理を実行できます。

重要:
Cloud Controlを使用してPDBのライフサイクルを管理するには、Oracle Databaseプラグイン用に12.1.0.3 Enterprise Manager以降のバージョンがデプロイされている必要があります。Cloud Controlを使用してPDBを削除するには、Oracle Databaseプラグイン用に12.1.0.5 Enterprise Managerがデプロイされている必要があります。
プラグインのデプロイ方法および既存のプラグインのアップグレード方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

図17-1に、Cloud ControlでPDBのライフサイクルを管理する方法の概要を図示します。

図17-1 プラガブル・データベースの管理

PDBおよびCDBの詳細は、『Oracle Database管理者ガイド』の「プラガブル・データベースの管理」の説明を参照してください。

17.3 プラガブル・データベースのプロビジョニング

PDBは、CDB内に新しいPDBを作成するか、既存のPDBをクローンするか、既存の非CDBをPDBとしてCDBに移行してプロビジョニングできます。また切断したPDBをCDBに接続して、プロビジョニングすることも可能です。

この項では、Cloud Controlコンソールを使用したPDBのプロビジョニングについて説明します。この章の内容は次のとおりです。

- 新規プラガブル・データベースの作成

- 切断されたプラガブル・データベースのプラグイン

- プラガブル・データベースのクローニング

- 非CDBのプラガブル・データベースとしての移行

注意:
EM CLIを使用してPDBをプロビジョニングすることもできます。この方法の詳細は、第A.4.4項を参照してください。

17.3.1 新しいプラガブル・データベースの作成

この項では、Cloud Controlを使用して新しいPDBを作成する方法について説明します。この章の内容は次のとおりです。

- 新しいプラガブル・データベースを作成するための前提条件

- 新規プラガブル・データベースの作成

17.3.1.1 新しいプラガブル・データベースを作成するための前提条件

Cloud Controlを使用して新しいPDBを作成する前に、次の前提条件を満たしていることを確認してください。

- Cloud Control内にOracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)を設定する必要があります。
Cloud Controlでのソフトウェア・ライブラリの設定方法の詳細は、第2.2項を参照してください。

- PDBを作成するCDBが存在しており、Cloud Controlのターゲットである必要があります。

注意:
新しいCDBの作成方法の詳細は、第16章を参照してください。

- (PDBを作成する) CDBは読取り専用、アップグレード、ダウングレード・モードになることはありません。

- ターゲット・ホストのユーザーは、(PDBを作成する) CDBが属するOracleホームの所有者である必要があります。

17.3.1.2 新しいプラガブル・データベースの作成

Cloud Controlを使用して新しいPDBをCDBに作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。データベースのプロビジョニング・ページの左側のメニュー・ペインの「関連リンク」セクションで、「プラガブル・データベースのプロビジョニング」をクリックします。

注意:
CDBのホームページからもプラガブル・データベースのプロビジョニング・コンソールにアクセスできます。これを行うには、CDBのホームページで、「Oracle Database」メニューの「プロビジョニング」を選択して、「プラガブル・データベースのプロビジョニング」を選択します。

2. プラガブル・データベースのプロビジョニング・コンソールの「コンテナ・データベース」セクションで、新しいPDBを作成するCDBを選択します。

注意:
CDBのホームページからプラガブル・データベースのプロビジョニング・コンソールにアクセスした場合は、この手順をスキップします。

3. 「PDB操作」セクションで、新しいプラガブル・データベースの作成を選択します。

4. 「起動」をクリックします。
図17-2に、プラガブル・データベースのプロビジョニング・コンソールを示します。

図17-2 プラガブル・データベースのプロビジョニング・コンソール

注意:
Enterprise Managerを使用してまだログインしていない場合、データベースにログインするよう求められます。sysdbaユーザー・アカウントの資格証明を使用してログインしていることを確認します。

5. プラガブル・データベースの作成ウィザードの「作成オプション」ページにあるプラガブル・データベースの作成オプションセクションで、「新規PDBの作成」を選択します。

6. 「コンテナ・データベース・ホスト資格証明」セクションで、ターゲットのCDB Oracleホーム所有者のホスト資格証明を選択するか指定します。Enterprise Managerを使用してすでに資格証明を登録している場合、「優先」または「名前付き」を選択できます。そうでない場合、「新規」を選択して、資格証明を入力できます。
図17-3に、「作成オプション」ページを示します。

図17-3 「新しいプラガブル・データベースの作成: 作成オプション」ページ

7. 「次へ」をクリックします。

8. IDページで、作成するPDBの一意の名前を入力します。
この手順で複数のPDBを作成する場合、複数のコピーの作成を選択して、作成するPDBの数を設定します。1個のCDBの中に最大252個のPDBを作成できます。

注意:
複数のPDBを作成する場合、ここで入力する一意の名前はすべてのPDBの接頭辞として使用され、接尾辞はPDBの数を示す数値です。
たとえば、accountsPDBという名前で5つのPDBを作成すると、PDBは、accountsPDB1、accountsPDB2、accountsPDB3、accountsPDB4、およびaccountsPDB5という名前で作成されます。

9. 「PDB管理者」セクションで、PDBを管理するために作成する必要がある管理ユーザー・アカウントの資格証明を入力します。
図17-4に、「ID」ページを示します。

図17-4 「新しいプラガブル・データベースの作成: ID」ページ

注意:
複数のPDBを作成する場合、作成する各PDBに対して管理ユーザー・アカウントが同じ指定された資格証明セットとともに作成されます。

10. 「次へ」をクリックします。

11. 「記憶域」ページの「PDBデータファイルの場所」セクションで、データファイルを格納する場所のタイプを選択します。

- ターゲットCDB(PDBを作成しているCDB)がOracle Managed Filesで有効な場合および同じ設定を使用する場合、「Oracle Managed Files(OMF)の使用」を選択します。

- カスタムの場所を入力する場合、PDBデータファイルに共通の場所を使用を選択します。記憶域タイプおよびデータファイルを格納できる場所を選択します。

12. 「一時作業ディレクトリ」セクションで、PDB作成プロセスで生成された一時ファイルを格納できる場所を入力します。

13. 作成後スクリプトセクションで、PDBを作成した後にこのプロシージャの一部として実行するカスタムSQLスクリプトを選択します。
図17-5に、「記憶域」ページを示します。

図17-5 「新しいプラガブル・データベースの作成: 記憶域」ページ

14. 「次へ」をクリックします。

15. スケジュール・ページで、デプロイ用の一意のデプロイメント・プロシージャ・インスタンス名およびスケジュールを入力します。ここで入力するインスタンス名により、プロシージャ・アクティビティ・ページでこのプロシージャの進捗状況を識別および追跡できます。
プロシージャを即時実行する場合は、デフォルトで選択されている「即時」を選択します。そうでない場合、「後で」を選択して、タイムゾーン、開始日および開始時間の詳細を指定します。

このスケジュールの猶予期間をオプションで設定できます。猶予期間は、スケジュールされたプロシージャの実行を試行する際に許可される最大遅延を定義する期間です。プロシージャが設定した猶予期間内に起動しない場合、プロシージャは実行をスキップします。猶予期間を設定するには、「猶予期間」を選択して、許される遅延時間を設定します。

図17-6に、「スケジュール」ページを示します。

図17-6 新しいプラガブル・データベースの作成: 「スケジュール」ページ

16. 「次へ」をクリックします。

17. 確認ページで、デプロイメント・プロシージャに対して指定した詳細を確認します。詳細に問題がなければ「発行」をクリックします。
詳細を変更する場合、変更を加えるページに到達するまで、「戻る」をクリックします。

図17-7に、「確認」ページを示します。

図17-7 「新しいプラガブル・データベースの作成: 確認」ページ

18. プロシージャ・アクティビティ・ページで、プロシージャのステータスを表示します。「プロシージャ・アクション」メニューで、ロギング・レベルを「デバッグ」に設定するには「デバッグ」を、プロシージャの実行を停止するには、「停止」を選択します。
図17-8に、「プロシージャ・アクティビティ」ページを示します。

図17-8 「新しいプラガブル・データベースの作成: プロシージャ・アクティビティ」ページ

新しいPDBを作成すると、Enterprise Managerのジョブ・システムによりプラガブル・データベースの作成ジョブが作成されます。このジョブの詳細の表示方法については、第17.5.1項を参照してください。

17.3.2 切断されたプラガブル・データベースのプラグイン

この項では、Cloud Controlを使用して切断されたPDBをCDBに接続する方法について説明します。この章の内容は次のとおりです。

- 切断されたプラガブル・データベースをプラグインするための前提条件

- 切断されたプラガブル・データベースのプラグイン

17.3.2.1 切断されたプラガブル・データベースをプラグインするための前提条件

Cloud Controlを使用して切断されたPDBを接続する前に、次の前提条件を満たしていることを確認してください。

- Cloud Control内にOracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)を設定する必要があります。
Cloud Controlでのソフトウェア・ライブラリの設定方法の詳細は、第2.2項を参照してください。

- ターゲットCDB (切断したPDBを接続するCDB)が存在しており、Cloud Controlのターゲットである必要があります。

注意:
新しいCDBの作成方法の詳細は、第16章を参照してください。

- ターゲットCDBは読取り専用、アップグレード、ダウングレード・モードになることはありません。

- 切断したPDBを説明するXMLファイル、およびデータファイル、ウォレット・ファイルなど切断したPDBと関連付られているその他のファイルが存在しており、読取り可能である必要があります。

- ターゲット・ホストのユーザーは、(切断したPDBを接続する) CDBが属するOracleホームの所有者である必要があります。

- ソースCDBホスト(切断したPDBを以前含んでいたCDBがインストールされていたホスト)およびターゲットCDBのホスト(ターゲットCDBがインストールされていたホスト)のプラットフォームのエンディアンが同じで、互換性のあるデータベース・オプションがインストールされている必要があります。

- ソースCDB(切断したPDBを以前含んでいたCDB)とターゲットCDBが、互換性のあるキャラクタ・セットと各国語キャラクタ・セットを持っている必要があります。ソースCDBのキャラクタ・セットの各キャラクタは、ターゲットCDBのキャラクタ・セットで使用でき、ソースCDBのキャラクタ・セットで使用できる各キャラクタのコード・ポイント値は、ターゲットCDBのキャラクタ・セットの値と同じである必要があります。

17.3.2.2 切断されたプラガブル・データベースのプラグイン

Cloud Controlを使用して切断されたPDBをCDBにプラグインするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。データベースのプロビジョニング・ページの左側のメニュー・ペインの「関連リンク」セクションで、「プラガブル・データベースのプロビジョニング」をクリックします。

注意:
CDBのホームページからもプラガブル・データベースのプロビジョニング・コンソールにアクセスできます。これを行うには、CDBのホームページで、「Oracle Database」メニューの「プロビジョニング」を選択して、「プラガブル・データベースのプロビジョニング」を選択します。

2. プラガブル・データベースのプロビジョニング・コンソールの「コンテナ・データベース」セクションで、切断したPDBを追加するCDBを選択します。

注意:
CDBのホームページからプラガブル・データベースのプロビジョニング・コンソールにアクセスした場合は、この手順をスキップします。

3. 「PDB操作」セクションで、新しいプラガブル・データベースの作成を選択します。

4. 「起動」をクリックします。
図17-9に、プラガブル・データベースのプロビジョニング・コンソールを示します。

図17-9 プラガブル・データベースのプロビジョニング・コンソール

注意:
Enterprise Managerを使用してまだログインしていない場合、データベースにログインするよう求められます。sysdbaユーザー・アカウントの資格証明を使用してログインしていることを確認します。

5. プラガブル・データベースの作成ウィザードの「作成オプション」ページにあるプラガブル・データベースの作成オプションセクションで、「切断されたPDBの接続」を選択します。

6. 「コンテナ・データベース・ホスト資格証明」セクションで、ターゲットのCDB Oracleホーム所有者のホスト資格証明を選択するか指定します。Enterprise Managerを使用してすでに資格証明を登録している場合、「優先」または「名前付き」を選択できます。そうでない場合、「新規」を選択して、資格証明を入力できます。
図17-10に、「作成オプション」ページを示します。

図17-10 「切断したプラガブル・データベースの接続: 作成オプション」ページ

7. 「次へ」をクリックします。

8. IDページで、プラグインするPDBの一意の名前を入力します。
「クローンとして作成」を選択すると、Oracle Databaseは一意のPDB DBID、GUIDおよび新規PDBで予期されるその他の識別子を生成します。

この手順で複数のPDBを作成する場合、複数のコピーの作成を選択して、作成するPDBの数を設定します。1個のCDBの中に最大252個のPDBを作成できます。

注意:
複数のPDBを作成する場合、ここで入力する一意の名前はすべてのPDBの接頭辞として使用され、接尾辞はPDBの数を示す数値です。
たとえば、accountsPDBという名前で5つのPDBを作成すると、PDBは、accountsPDB1、accountsPDB2、accountsPDB3、accountsPDB4、およびaccountsPDB5という名前で作成されます。

9. 「PDB管理者」セクションで、次のいずれかを実行して、PDBを管理します。

- プラグインするソースPDBの一部として作成された管理ユーザー・アカウントを使用する場合、PDB管理者の作成の選択を解除します。

- プラグインするPDBの新しい管理ユーザー・アカウントを作成する場合、PDB管理者の作成を選択して、必要な資格証明を入力します。

注意:
複数のPDBを作成する場合、作成する各PDBに対して管理ユーザー・アカウントが同じ指定された資格証明セットとともに作成されます。

新規に作成したPDBのすべてのユーザー(新規に作成した管理者を除く)をロックして期限切れにするには、「既存のすべてのPDBユーザーのロック」を選択します。

図17-11に、「ID」ページを示します。

図17-11 「切断したプラガブル・データベースの接続: ID」ページ

10. 「PDBテンプレートの場所」セクションで、ソースPDBのテンプレートがある場所を選択し、次いでPDBテンプレートのタイプを選択します。

- PDBテンプレートをCDBホスト(切断されたPDBにプラグインするCDB)で使用可能な場合、「ターゲット・ホスト・ファイル・システム」を選択します。

- PDBテンプレートが単一のアーカイブ・ファイル(データファイルを含むTARファイルとそれに含まれるメタデータXMLファイル)の場合、PDBアーカイブからのPDBの作成、PDBテンプレートの順に選択します。

- PDBテンプレートがPDBファイル・セット(すべてのデータファイルを含む個別のDFBファイルおよび個別のメタデータXMLファイル)の場合、PDBファイル・セットを使用したPDBの作成を選択して、DBFおよびXMLファイルを選択します。

- PDBメタデータXMLファイルおよび既存のデータファイルを使用してPDBをプラグインする場合、メタデータ・ファイルを使用してPDBを作成を選択します。

- PDBテンプレートがOracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)で使用可能である場合、「ソフトウェア・ライブラリ」を選択して、PDBテンプレートを含むソフトウェア・ライブラリのコンポーネントを選択します。

図17-12に、「ID」ページの「PDBテンプレートの場所」セクションを示します。

図17-12 「切断したプラガブル・データベースの接続: PDBテンプレートの場所」セクション

11. 「次へ」をクリックします。

12. 記憶域ページで、次のいずれかを実行します。

- 前のページで、プラガブル・データベース・アーカイブ(単一のTARファイル)またはプラガブル・データベース・ファイル・セット(DFBファイルおよびXMLファイル)を使用してPDBを作成する場合、プラグインするPDBのターゲット・データファイルを格納する場所のタイプを選択します。

- ターゲットCDB(切断されたPDBにプラグインするCDB)がOracle Managed Filesで有効な場合および同じ設定を使用する場合、「Oracle Managed Files(OMF)の使用」を選択します。

- 共通のカスタムの場所を入力する場合、PDBデータファイルに共通の場所を使用を選択します。記憶域タイプおよびデータファイルを格納できる場所を選択します。

- 前のページで、プラガブル・データベース・テンプレート(XMLファイルのみ)を使用してPDBを作成した場合、次を実行します。
「PDBデータファイルの場所」セクションで、データファイルにマップされた場所を検証します。正しくない場合、パスを修正します。または、データファイルをすべて使用できる単一の場所がある場合、「共通のソース・ファイル・マッピングの場所を設定」フィールドに絶対パスを入力して、「設定」をクリックします。

ソース・データファイルと同じ場所にプラグインするPDBのターゲット・データファイルを格納できます。ただし、別の場所にターゲット・データファイルを格納する場合、「データファイルのコピー」を選択して、場所のタイプを選択します。

- ターゲットCDB(切断されたPDBにプラグインするCDB)がOracle Managed Filesで有効な場合および同じ設定を使用する場合、「Oracle Managed Files(OMF)の使用」を選択します。

- 共通のカスタムの場所を入力する場合、「プラガブル・データベース・ファイルに共通の場所を使用」を選択します。記憶域タイプおよびデータファイルを格納できる場所を選択します。

- 異なるデータファイルの異なるカスタムの場所を使用する場合、「カスタマイズされた場所」を選択して、カスタムの場所のパスを入力します。

13. 「一時作業ディレクトリ」セクションで、PDB作成プロセスで生成された一時ファイルを格納できる場所を入力します。

14. 作成後スクリプトセクションで、PDBをプラグインした後にこのプロシージャの一部として実行するカスタムSQLスクリプトを選択します。
スクリプトがソフトウェア・ライブラリで使用可能である場合、「ソフトウェア・ライブラリからの選択」を選択して、カスタム・スクリプトを含むコンポーネントを選択します。

図17-13に、「記憶域」ページを示します。

図17-13 「切断したプラガブル・データベースの接続: 記憶域」ページ

15. 「次へ」をクリックします。

16. スケジュール・ページで、デプロイ用の一意のデプロイメント・プロシージャ・インスタンス名およびスケジュールを入力します。ここで入力するインスタンス名により、プロシージャ・アクティビティ・ページでこのプロシージャの進捗状況を識別および追跡できます。
プロシージャを即時実行する場合は、デフォルトで選択されている「即時」を選択します。そうでない場合、「後で」を選択して、タイムゾーン、開始日および開始時間の詳細を指定します。

このスケジュールの猶予期間をオプションで設定できます。猶予期間は、スケジュールされたプロシージャの実行を試行する際に許可される最大遅延を定義する期間です。プロシージャが設定した猶予期間内に起動しない場合、プロシージャは実行をスキップします。猶予期間を設定するには、「猶予期間」を選択して、許される遅延時間を設定します。

図17-14に、「スケジュール」ページを示します。

図17-14 「切断したプラガブル・データベースの接続: スケジュール」ページ

17. 「次へ」をクリックします。

18. 確認ページで、デプロイメント・プロシージャに対して指定した詳細を確認します。詳細に問題がなければ「発行」をクリックします。
詳細を変更する場合、変更を加えるページに到達するまで、「戻る」をクリックします。

図17-15に、「確認」ページを示します。

図17-15 「切断したプラガブル・データベースの接続: 確認」ページ

19. プロシージャ・アクティビティ・ページで、プロシージャのステータスを表示します。「プロシージャ・アクション」メニューで、ロギング・レベルを「デバッグ」に設定するには「デバッグ」を、プロシージャの実行を停止するには、「停止」を選択します。
図17-16に、「プロシージャ・アクティビティ」ページを示します。

図17-16 切断されたプラガブル・データベースのプラグイン: 「プロシージャ・アクティビティ」ページ

切断したPDBを接続すると、Enterprise Managerのジョブ・システムによりプラガブル・データベースの作成ジョブが作成されます。このジョブの詳細の表示方法については、第17.5.1項を参照してください。

17.3.3 プラガブル・データベースのクローニング

完全クローン方式またはスナップ・クローン方式のどちらかを使用したPDBのクローニングが可能です。この項では、Cloud Controlでこれらの方式を使用してPDBをクローニングする方法について説明します。この章の内容は次のとおりです。

- プラガブル・データベースをクローニングするための前提条件

- プラガブル・データベースのクローニング

17.3.3.1 プラガブル・データベースをクローニングするための前提条件

Cloud Controlを使用してPDBをクローニングするには、次の前提条件を満たしていることを確認してください。

- Cloud Control内にOracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)を設定する必要があります。
Cloud Controlでのソフトウェア・ライブラリの設定方法の詳細は、第2.2項を参照してください。

- ソースPDB (クローンするPDB)が存在しており、Cloud Controlのターゲットである必要があります。

注意:
新しいPDBの作成方法の詳細は、第17.3.1項を参照してください。

- ソースPDBがオープンである必要があります。

- ターゲットCDB (クローンしたPDBを接続するCDB)が存在しており、Cloud Controlのターゲットである必要があります。

注意:
新しいCDBの作成方法の詳細は、第16章を参照してください。

- ターゲットCDBは読取り専用、アップグレード、ダウングレード・モードになることはありません。

- ターゲット・ホストのユーザーは、ターゲットCDBが属するOracleホームの所有者である必要があります。

スナップ・クローン方式を使用してPDBをクローニングするには、次の追加前提条件を満たしている必要があります。

- Oracle Databaseプラグイン用に12.1.0.5 Enterprise Managerがダウンロードされ、デプロイされている必要があります。また、SMF 12.1.0.3以上のプラグインがダウンロードされ、デプロイされている必要があります。

- クローニングするPDBは、登録済の記憶域サーバー上に存在する必要があります。この記憶域サーバーは同期している必要があります。
記憶域サーバーの登録方法および同期方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

- クローニングするPDBのすべてのデータファイルは、ローカル・ディスク上ではなく、記憶域サーバーの記憶域ボリューム上に存在する必要があります。

- メトリックの収集は、ソースCDB (クローニングするPDBを含むCDB)、ソースCDBホスト、およびクローニングするPDBで実行する必要があります。

- スナップ・クローン機能は、クローニングするPDBで有効になっている必要があります。
スナップ・クローン機能を有効化する方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

17.3.3.2 プラガブル・データベースのクローニング

完全クローン方式またはスナップ・クローン方式のどちらかを使用して既存のPDBをクローニングするには、次の手順に従います。

重要:
PDBのクローニングに完全クローン方式を使用する場合、PDBはソースCDB (クローニングするPDBを含むCDB)に対してのみクローニングできます。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。データベースのプロビジョニング・ページの左側のメニュー・ペインの「関連リンク」セクションで、「プラガブル・データベースのプロビジョニング」をクリックします。

注意:
CDBのホームページからもプラガブル・データベースのプロビジョニング・コンソールにアクセスできます。これを行うには、CDBのホームページで、「Oracle Database」メニューの「プロビジョニング」を選択して、「プラガブル・データベースのプロビジョニング」を選択します。

2. 「プラガブル・データベースのプロビジョニング」コンソールの「CDB」セクションで、クローニングされたPDBを追加するCDBを選択します。

注意:
CDBのホームページからプラガブル・データベースのプロビジョニング・コンソールにアクセスした場合は、この手順をスキップします。

3. 「PDB操作」セクションで、新しいプラガブル・データベースの作成を選択します。

4. 「起動」をクリックします。
図17-17に、プラガブル・データベースのプロビジョニング・コンソールを示します。

図17-17 プラガブル・データベースのプロビジョニング・コンソール

注意:
Enterprise Managerを使用してまだログインしていない場合、データベースにログインするよう求められます。sysdbaユーザー・アカウントの資格証明を使用してログインしていることを確認します。

5. プラガブル・データベースの作成ウィザードの「作成オプション」ページにあるPDB作成オプションセクションで、既存のPDBのクローニングを選択します。
PDBのデータファイルをクローニングする従来の方式を使用してPDBをクローニングするには、完全クローンを選択します。長期間の使用でPDBをクローニングする場合は、この方式を使用します。この方式は、PDBクローンに重要なデータ更新を行う場合のロード・テストに最適です。ただし、この方式はスナップ・クローン方式と比較して時間がかかり、この方式で作成されたクローンは大量の領域を占めます。

ストレージ管理フレームワーク(SMF)スナップ・クローン機能を使用してPDBをクローニングするには、スナップ・クローンを選択します。短期間の用途でPDBをクローニングする場合は、この方式を使用します。この方式では、クローニング・プロセスが迅速で、この方式で作成されたPDBクローンは領域をほとんど占めないため、機能テストに最適です。ただし、この方式は、PDBクローンに重要なデータ更新を行うする場合は適していません。

「ソースPDB」で、クローニングするPDBを選択します。

図17-18に、「作成オプション」ページのPDB作成オプションセクションを示します。

図17-18 「プラガブル・データベースのクローニング: 作成オプション」の指定

6. 「CDBホスト資格証明」セクションで、ターゲットのCDB Oracleホーム所有者のホスト資格証明を選択するか指定します。Enterprise Managerを使用してすでに資格証明を登録している場合、「優先」または「名前付き」を選択できます。そうでない場合、「新規」を選択して、資格証明を入力できます。
図17-19に、「作成オプション」ページの「CDBホスト資格証明」セクションを示します。

図17-19 「プラガブル・データベースのクローニング: CDBホスト資格証明」の指定

7. 「次へ」をクリックします。

8. IDページで、クローニングするPDBの一意の名前を入力します。
この手順で複数のPDBを作成する場合、複数のコピーの作成を選択して、作成するPDBの数を設定します。最大252個のPDBを作成できます。

注意:
複数のPDBを作成する場合、ここで入力する一意の名前はすべてのクローニングされるPDBの接頭辞として使用され、接尾辞はPDBの数を示す数値です。
たとえば、accountsPDBという名前で5つのPDBを作成すると、PDBは、accountsPDB1、accountsPDB2、accountsPDB3、accountsPDB4、およびaccountsPDB5という名前で作成されます。

9. 「PDB管理者」セクションで、次のいずれかを実行して、PDBを管理します。

- クローニングするソースPDBの一部として作成された管理ユーザー・アカウントを使用する場合、PDB管理者の作成の選択を解除します。

- クローニングするPDBの新しい管理ユーザー・アカウントを作成する場合、PDB管理者の作成を選択して、必要な資格証明を入力します。

図17-20に、「ID」ページを示します。

図17-20 「プラガブル・データベースのクローニング: ID」ページ

注意:
複数のPDBを作成する場合、作成する各PDBに対して管理ユーザー・アカウントが同じ指定された資格証明セットとともに作成されます。

10. 「ソース・コンテナ・データベース・ログイン資格証明」セクションで、ソースCDBのログイン資格証明を選択するか指定します。Enterprise Managerを使用してすでに資格証明を登録している場合、「優先」または「名前付き」を選択できます。そうでない場合、「新規」を選択して、資格証明を入力できます。
資格証明は、クローニング操作を開始する前にソースPDBを読取り専用モードにして、クローニング操作が終了した後に元の状態にリストアするために使用されます。

スナップ・クローン方式を選択して(プラガブル・データベースの作成ウィザードの「ソース」ページ)、PDBをクローニングする場合は、ソースCDBのホスト資格証明を指定します。

注意:
ソースPDBをソースCDB自身にクローニングする場合、ソースCDBログイン資格証明セクションは表示されません。つまり、ソースCDBログイン資格証明やソースCDBホスト資格証明を指定する必要はありません。
ソースPDBをソースCDBとは異なるCDBにクローニングし、そのCDBがソースCDBホスト上に存在する場合、ソースCDBログイン資格証明を指定する必要があります。ソースCDBホスト資格証明を指定する必要はありません。

ソースPDBをソースCDBとは異なるCDBにクローニングし、そのCDBがソースCDBホストとは異なるホスト上に存在する場合、ソースCDBログイン資格証明およびソースCDBホスト資格証明を指定する必要があります。

11. 「次へ」をクリックします。

12. 「ソース」ページで、記憶域情報を指定します。
PDBのクローニングで完全クローン方式を選択した場合は、次の方法で、PDBデータファイルを格納する場所のタイプを選択します。

- ソースCDBがOracle Managed Filesで有効な場合および同じ設定を使用する場合、「Oracle Managed Files (OMF)の使用」を選択します。

- カスタムの場所を入力する場合、PDBデータファイルに共通の場所を使用を選択します。記憶域タイプおよびデータファイルを格納できる場所を選択します。

図17-21に、完全クローン方式の「記憶域」ページを示します。

図17-21 「プラガブル・データベースのクローニング(完全クローン): 記憶域」ページ

PDBのクローニングでスナップ・クローン方式を選択した場合は、次を実行します。

- 「PDBデータファイルの場所」セクションで、「マウント・ポイント接頭辞」の値(記憶域ボリュームのマウント位置)を指定します。すべてのボリュームに同じ接頭辞を指定したり、ボリュームごとに異なる接頭辞を指定できます。また、「書込み可能領域」の値(PDBクローンへの変更を書き込むために割り当てる領域)も指定します。すべてのボリュームに同じ書込み可能領域を指定したり、ボリュームごとに異なる値を指定できます。

- 「特権ホスト資格証明」セクションで、rootユーザーの資格証明を指定します。これらの資格証明は、宛先ホスト上のクローン・ボリュームのマウントに使用されます。
Enterprise Managerを使用してすでに資格証明を登録している場合、「優先」または「名前付き」を選択できます。そうでない場合、「新規」を選択して、資格証明を入力できます。

図17-22に、スナップ・クローン方式の「記憶域」ページを示します。

図17-22 「プラガブル・データベースのクローニング(スナップ・クローン): 記憶域」ページ

13. 「一時作業ディレクトリ」セクションで、PDB作成プロセスで生成された一時ファイルを格納できる場所を入力します。

14. 作成後スクリプトセクションで、PDBをクローニングした後にこのプロシージャの一部として実行するカスタムSQLスクリプトを選択します。

15. 「次へ」をクリックします。

16. スケジュール・ページで、デプロイ用の一意のデプロイメント・プロシージャ・インスタンス名およびスケジュールを入力します。ここで入力するインスタンス名により、プロシージャ・アクティビティ・ページでこのプロシージャの進捗状況を識別および追跡できます。
プロシージャを即時実行する場合は、デフォルトで選択されている「即時」を選択します。そうでない場合、「後で」を選択して、タイムゾーン、開始日および開始時間の詳細を指定します。

このスケジュールの猶予期間をオプションで設定できます。猶予期間は、スケジュールされたプロシージャの実行を試行する際に許可される最大遅延を定義する期間です。プロシージャが設定した猶予期間内に起動しない場合、プロシージャは実行をスキップします。猶予期間を設定するには、「猶予期間」を選択して、許される遅延時間を設定します。

図17-23に、「スケジュール」ページを示します。

図17-23 「プラガブル・データベースのクローニング: スケジュール」ページ

17. 「次へ」をクリックします。

18. 確認ページで、デプロイメント・プロシージャに対して指定した詳細を確認します。詳細に問題がなければ「発行」をクリックします。
詳細を変更する場合、変更を加えるページに到達するまで、「戻る」をクリックします。

図17-24に、「確認」ページを示します。

図17-24 「プラガブル・データベースのクローニング: 確認」ページ

19. プロシージャ・アクティビティ・ページで、プロシージャのステータスを表示します。「プロシージャ・アクション」メニューで、ロギング・レベルを「デバッグ」に設定するには「デバッグ」を、プロシージャの実行を停止するには、「停止」を選択します。
図17-25に、「プロシージャ・アクティビティ」ページを示します。

図17-25 「プラガブル・データベースのクローニング: プロシージャ・アクティビティ」ページ

PDBをクローンすると、Enterprise Managerのジョブ・システムによりプラガブル・データベースの作成ジョブが作成されます。このジョブの詳細の表示方法については、第17.5.1項を参照してください。

17.3.4 非CDBのプラガブル・データベースとしての移行

この項では、Cloud Controlを使用して非CDBをPDBとして移行する方法について説明します。この章の内容は次のとおりです。

- 非CDBをプラガブル・データベースとして移行するための前提条件

- 非CDBのプラガブル・データベースとしての移行

17.3.4.1 非CDBをプラガブル・データベースとして移行するための前提条件

Cloud Controlを使用して非CDBをPDBとして移行する前に、次の前提条件を満たしていることを確認してください。

- Cloud Control内にOracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)を設定する必要があります。
Cloud Controlでのソフトウェア・ライブラリの設定方法の詳細は、第2.2項を参照してください。

- ターゲットCDB (非CDBをPDBとして移行するCDB)が存在しており、Cloud Controlのターゲットである必要があります。

注意:
新しいCDBの作成方法の詳細は、第16章を参照してください。

- ターゲットCDBは読取り専用、アップグレード、ダウングレード・モードになることはありません。

- 移行する非CDBおよびターゲットCDBは、ARCHIVELOGモードで実行されている必要があります。
データベースのアーカイブ・モードの設定については、『Oracle Database管理者ガイド』を参照してください。

- 移行するデータベースのデータベース管理者およびターゲットCDBに、SYSDBA権限が付与されている必要があります。

- ターゲット・ホストのユーザーは、ターゲットCDBが属するOracleホームの所有者である必要があります。

17.3.4.2 非CDBのプラガブル・データベースとしての移行

Cloud Controlを使用して非CDBをPDBとして移行するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。データベースのプロビジョニング・ページの左側のメニュー・ペインの「関連リンク」セクションで、「プラガブル・データベースのプロビジョニング」をクリックします。

注意:
CDBのホームページからもプラガブル・データベースのプロビジョニング・コンソールにアクセスできます。これを行うには、CDBのホームページで、「Oracle Database」メニューの「プロビジョニング」を選択して、「プラガブル・データベースのプロビジョニング」を選択します。

2. プラガブル・データベースのプロビジョニング・コンソールの「CDB」セクションで、PDBとして移行する非CDBのCDBを選択します。

注意:
CDBのホームページからプラガブル・データベースのプロビジョニング・コンソールにアクセスした場合は、この手順をスキップします。

3. プラガブル・データベースのプロビジョニング・ページの「PDB操作」セクションで、「既存のデータベースの移行」オプションを選択して、「起動」をクリックします。
図17-26に、プラガブル・データベースのプロビジョニング・コンソールを示します。

図17-26 プラガブル・データベースのプロビジョニング・コンソール

4. データベース・ログイン・ページで、ドロップダウン・リストから「資格証明名」を選択します。「ログイン」をクリックします。

5. 「非CDBの移行」起動ページで、データの移行方法(「Export/Import」または「PDBとしてプラグ」)を選択します。「PDBとしてプラグ」を選択した場合は、移行する非CDBがオープンされ、読取り専用モードであることを確認します。
「Oracleホーム資格証明」セクションに、適切な資格証明を入力します。

「次へ」をクリックします。

図17-27に、「メソッド」ページを示します。

Figure 17-27 「非CDBの移行: メソッド」ページ

6. データベース・ページで、移行する非CDBを選択します。複数のサーバーを選択できます。「追加」をクリックします。データベース・ペインで、適切な資格証明、プロパティ、エクスポート、インポート、およびデータファイルの場所の情報を指定します。「次へ」をクリックします。
Figure 17-28に、移行する非CDBの選択方法を示します。

Figure 17-28 非CDBの移行: 非CDBの選択

Figure 17-29に、データベースおよびデータベースのホスト資格証明の指定方法を示します。

Figure 17-29 非CDBの移行: 資格証明の指定

Figure 17-30に、移行に使用するステージングの場所の指定方法を示します。

Figure 17-30 非CDBの移行: ステージングの場所の指定

Figure 17-31に、PDB管理者の詳細およびデータファイルの場所の指定方法を示します。

Figure 17-31 非CDBの移行: PDBプロパティおよびデータファイルの場所の指定

Figure 17-32に、インポート・ディレクトリの指定方法を示します。

Figure 17-32 非CDBの移行: インポート・ディレクトリの指定

7. スケジュール・ページで、適切なジョブおよびスケジュールの詳細を入力します。「次へ」をクリックします。
図17-33に、「スケジュール」ページを示します。

Figure 17-33 「非CDBの移行: スケジュール」ページ

8. 確認ページで、入力したすべての詳細を確認します。必要な変更がない場合、「発行」をクリックします。
図17-34に、「確認」ページを示します。

Figure 17-34 「非CDBの移行: 確認」ページ

17.4 プラガブル・データベースの削除

この項では、PDBの切断および削除について説明します。この章の内容は次のとおりです。

- プラガブル・データベースの切断および削除

- プラガブル・データベースの削除

17.4.1 プラガブル・データベースの切断および削除

この項では、Cloud Controlを使用してPDBを切断および削除する方法について説明します。この章の内容は次のとおりです。

- プラガブル・データベースを切断および削除するための前提条件

- プラガブル・データベースの切断および削除

注意:
この項での説明する方法を使用するかわりに、EM CLIを使用して、PDBを切断および削除できます。詳細は、第A.4.4.4項を参照してください。

17.4.1.1 プラガブル・データベースを切断および削除するための前提条件

Cloud Controlを使用してPDBを切断および削除する前に、次の前提条件を満たしていることを確認してください。

- Cloud Control内にOracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)を設定する必要があります。
Cloud Controlでのソフトウェア・ライブラリの設定方法の詳細は、第2.2項を参照してください。

- 切断および削除するPDBは、最低1回はオープンしている必要があります。

- ターゲット・ホストのユーザーは、(切断および削除するPDBを含む) CDBが属するOracleホームの所有者である必要があります。

17.4.1.2 プラガブル・データベースの切断および削除

Cloud Controlを使用してPDBをそのCDBから切断するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。データベースのプロビジョニング・ページの左側のメニュー・ペインの「関連リンク」セクションで、「プラガブル・データベースのプロビジョニング」をクリックします。

注意:
CDBのホームページからもプラガブル・データベースのプロビジョニング・コンソールにアクセスできます。これを行うには、CDBのホームページで、「Oracle Database」メニューの「プロビジョニング」を選択して、「プラガブル・データベースのプロビジョニング」を選択します。

2. プラガブル・データベースのプロビジョニング・コンソールの「CDB」セクションで、PDBを切断するCDBを選択します。

注意:
CDBのホームページからプラガブル・データベースのプロビジョニング・コンソールにアクセスした場合は、この手順をスキップします。

3. 「PDB操作」セクションで、「プラガブル・データベースの切断」を選択します。

4. 「起動」をクリックします。
図17-35に、プラガブル・データベースのプロビジョニング・コンソールを示します。

図17-35 プラガブル・データベースのプロビジョニング・コンソール

注意:
Enterprise Managerを使用してまだログインしていない場合、データベースにログインするよう求められます。sysdbaユーザー・アカウントの資格証明を使用してログインしていることを確認します。

5. 「プラガブル・データベースの切断」ウィザードのPDBの選択ページの「プラガブル・データベースの選択」セクションで、切断するPDBを選択します。一度切断されたPDBは停止および削除されるので注意してください。

6. 「CDBホスト資格証明」セクションで、ターゲットのCDB Oracleホーム所有者のホスト資格証明を選択するか指定します。Enterprise Managerを使用してすでに資格証明を登録している場合、「優先」または「名前付き」を選択できます。そうでない場合、「新規」を選択して、資格証明を入力できます。
図17-36に、「PDBの選択」ページを示します。

図17-36 「プラガブル・データベースの切断: PDBの選択」ページ

7. 宛先ページで、PDBを切断するために生成するPDBテンプレートのタイプおよび格納する場所を選択します。PDBテンプレートは、すべてのデータファイルおよびメタデータXMLファイルで構成されます。

- CDBホスト(PDBを切断するCDB)にPDBテンプレートを格納する場合、「ターゲット・ホスト・ファイル・システム」を選択します。

- 単一のアーカイブ・ファイル(データファイルを含むTARファイルおよびそれに含まれるメタデータXMLファイル)を生成する場合、「PDBアーカイブの生成」を選択します。アーカイブ・ファイルを作成できる場所を選択します。

注意:
ソースCDBおよびターゲットCDBで記憶域にファイル・システムを使用している場合、このオプションを選択することをお薦めします。記憶域としてASMを使用しているPDBでは、このオプションはサポートされません。

- アーカイブ・ファイル・セット(すべてのデータファイルを含む個別のDFBファイルおよび個別のメタデータXMLファイル)を生成する場合、「PDBファイル・セットの生成」を選択します。DBFおよびXMLファイルを作成できる場所を選択します。

注意:
ソースCDBおよびターゲットCDBで記憶域にASMを使用している場合、このオプションを選択することをお薦めします。

- メタデータXMLファイルのみ生成し、データファイルは現在の場所にそのままにする場合、PDBメタデータ・ファイルの生成を選択します。メタデータXMLファイルを作成できる場所を選択します。

- Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)にPDBテンプレートを格納する場合、「ソフトウェア・ライブラリ」を選択します。

- 単一のアーカイブ・ファイル(データファイルを含むTARファイルおよびそれに含まれるメタデータXMLファイル)を生成する場合、「PDBアーカイブの生成」を選択します。アーカイブ・ファイル・セット(すべてのデータファイルを含む個別のDFBファイルおよび個別のメタデータXMLファイル)を生成する場合、「PDBファイル・セットの生成」を選択します。メタデータXMLファイルのみ生成し、データファイルは現在の場所にそのままにする場合、PDBメタデータ・ファイルの生成を選択します。

- 一意のPDBテンプレート名を入力します。
テンプレートは、次の形式でデフォルトの場所に作成されます。

Database Configuration/<db_release>/<platform>/Database Templates

次に例を示します。

Database Configuration/12.1.0.0.2/unix/Database Templates

- ソフトウェア・ライブラリにアップロードする前にEnterprise Managerでアーカイブを作成できる一時的な場所を入力します。

図17-37に、「宛先」ページを示します。

図17-37 「プラガブル・データベースの切断: 宛先」ページ

8. スケジュール・ページで、デプロイ用の一意のデプロイメント・プロシージャ・インスタンス名およびスケジュールを入力します。ここで入力するインスタンス名により、プロシージャ・アクティビティ・ページでこのプロシージャの進捗状況を識別および追跡できます。
プロシージャを即時実行する場合は、デフォルトで選択されている「即時」を選択します。そうでない場合、「後で」を選択して、タイムゾーン、開始日および開始時間の詳細を指定します。

このスケジュールの猶予期間をオプションで設定できます。猶予期間は、スケジュールされたプロシージャの実行を試行する際に許可される最大遅延を定義する期間です。プロシージャが設定した猶予期間内に起動しない場合、プロシージャは実行をスキップします。猶予期間を設定するには、「猶予期間」を選択して、許される遅延時間を設定します。

図17-38に、「スケジュール」ページを示します。

図17-38 「プラガブル・データベースの切断: スケジュール」ページ

9. 「次へ」をクリックします。

10. 確認ページで、デプロイメント・プロシージャに対して指定した詳細を確認します。詳細に問題がなければ「発行」をクリックします。
詳細を変更する場合、変更を加えるページに到達するまで、「戻る」をクリックします。

図17-39に、「確認」ページを示します。

図17-39 「プラガブル・データベースの切断: 確認」ページ

11. プロシージャ・アクティビティ・ページで、プロシージャのステータスを表示します。「プロシージャ・アクション」メニューで、ロギング・レベルを「デバッグ」に設定するには「デバッグ」を、プロシージャの実行を停止するには、「停止」を選択します。
PDBを切断および削除すると、Enterprise Managerのジョブ・システムによりプラガブル・データベースの切断ジョブが作成されます。このジョブの詳細の表示方法については、第17.5.2項を参照してください。

17.4.2 プラガブル・データベースの削除

この項では、Cloud Controlを使用してPDBをCDBから完全に削除する方法について説明します。この章の内容は次のとおりです。

- プラガブル・データベースを削除するための前提条件

- プラガブル・データベースの削除

17.4.2.1 プラガブル・データベースを削除するための前提条件

Cloud Controlを使用して一連のPDBをCDBから完全に削除する前に、次の前提条件を満たしていることを確認してください。

- Oracle Databaseプラグイン用に12.1.0.5 Enterprise Managerがダウンロードされ、デプロイされている必要があります。
プラグインをダウンロードおよびデプロイする方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

- Cloud Control内にOracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)を設定する必要があります。
Cloud Controlでのソフトウェア・ライブラリの設定方法の詳細は、第2.2項を参照してください。

- 削除するPDBは、1回以上オープンされている必要があります。

- ターゲット・ホストのユーザーは、(削除するPDBを含む) CDBが属するOracleホームの所有者である必要があります。

17.4.2.2 プラガブル・データベースの削除

Cloud Controlを使用して一連のPDBをCDBから完全に削除するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。データベースのプロビジョニング・ページの左側のメニュー・ペインの「関連リンク」セクションで、「プラガブル・データベースのプロビジョニング」をクリックします。

注意:
CDBのホームページからもプラガブル・データベースのプロビジョニング・コンソールにアクセスできます。これを行うには、CDBのホームページで、「Oracle Database」メニューの「プロビジョニング」を選択して、「プラガブル・データベースのプロビジョニング」を選択します。

2. 「プラガブル・データベースのプロビジョニング」コンソールの「CDB」セクションで、PDBを削除するCDBを選択します。

注意:
CDBのホームページからプラガブル・データベースのプロビジョニング・コンソールにアクセスした場合は、この手順をスキップします。

3. 「PDB操作」セクションで、プラガブル・データベースの削除を選択します。

4. 「起動」をクリックします。
図17-40に、プラガブル・データベースのプロビジョニング・コンソールを示します。

図17-40 プラガブル・データベースのプロビジョニング・コンソール

注意:
Enterprise Managerを使用してまだログインしていない場合、データベースにログインするよう求められます。sysdbaユーザー・アカウントの資格証明を使用してログインしていることを確認します。

5. プラガブル・データベースの削除ウィザードの「PDBの選択」ページで、「追加」をクリックします。削除するPDBを選択し、「選択」をクリックします。

注意:
スナップ・クローン方式を使用して作成されたPDBを削除する場合は、CDBホスト上のPDBマウント・ポイントがクリーンアップされます。記憶域サーバー上の対応する記憶域ボリュームも削除されます。この操作は元に戻すことができません。

図17-41に、「PDBの選択」ページを示します。

図17-41 「プラガブル・データベースの削除: PDBの選択」

6. 「CDBホスト資格証明」セクションで、ターゲットのCDB Oracleホーム所有者のホスト資格証明を選択するか指定します。Enterprise Managerを使用してすでに資格証明を登録している場合、「優先」または「名前付き」を選択できます。そうでない場合、「新規」を選択して、資格証明を入力できます。
削除するために選択したPDBの1つ以上が、別のPDBのスナップ・クローンの場合は、特権ホスト資格証明(rootユーザーの資格証明)も指定する必要があります。Enterprise Managerを使用してすでに資格証明を登録している場合、「優先」または「名前付き」を選択できます。そうでない場合、「新規」を選択して、資格証明を入力できます。

図17-42に、「PDBの選択」ページの「CDBホスト資格証明」セクションを示します。

図17-42 「プラガブル・データベースの削除: 資格証明」の指定

7. スケジュール・ページで、デプロイ用の一意のデプロイメント・プロシージャ・インスタンス名およびスケジュールを入力します。ここで入力するインスタンス名により、プロシージャ・アクティビティ・ページでこのプロシージャの進捗状況を識別および追跡できます。
プロシージャを即時実行する場合は、デフォルトで選択されている「即時」を選択します。そうでない場合、「後で」を選択して、タイムゾーン、開始日および開始時間の詳細を指定します。

このスケジュールの猶予期間をオプションで設定できます。猶予期間は、スケジュールされたプロシージャの実行を試行する際に許可される最大遅延を定義する期間です。プロシージャが設定した猶予期間内に起動しない場合、プロシージャは実行をスキップします。猶予期間を設定するには、「猶予期間」を選択して、許される遅延時間を設定します。

図17-43に、「スケジュール」ページを示します。

図17-43 「プラガブル・データベースの削除: スケジュール」ページ

8. 「次へ」をクリックします。

9. 確認ページで、デプロイメント・プロシージャに対して指定した詳細を確認します。詳細に問題がなければ「発行」をクリックします。
詳細を変更する場合、変更を加えるページに到達するまで、「戻る」をクリックします。

図17-44に、「確認」ページを示します。

図17-44 「プラガブル・データベースの削除: 確認」ページ

10. プロシージャ・アクティビティ・ページで、プロシージャのステータスを表示します。「プロシージャ・アクション」メニューで、ロギング・レベルを「デバッグ」に設定するには「デバッグ」を、プロシージャの実行を停止するには、「停止」を選択します。
図17-45に、「プロシージャ・アクティビティ」ページを示します。

図17-45 「プラガブル・データベースの削除: プロシージャ・アクティビティ」ページ

PDBを削除すると、Enterprise Managerジョブ・システムによって、プラガブル・データベースの削除ジョブが作成されます。このジョブの詳細の表示方法については、第17.5.3項を参照してください。

17.5 プラガブル・データベース・ジョブの詳細の表示

この項では、PDBの作成、切断、または削除時にEnterprise Managerジョブ・システムで作成されるジョブの詳細の表示について説明します。次の項目が含まれます。

- プラガブル・データベースの作成ジョブの詳細の表示

- プラガブル・データベースの切断ジョブの詳細の表示

- プラガブル・データベースの削除ジョブの詳細の表示

17.5.1 プラガブル・データベースの作成ジョブの詳細の表示

PDBジョブの作成の詳細を表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・アクティビティ」を選択します。

2. 必要とするPDBジョブの作成を含むデプロイメント・プロシージャをクリックします。

3. デプロイメント・プロシージャ・ステップを展開します。PDB作成ジョブを選択します。

4. 「ジョブ・サマリー」をクリックします。

5. ジョブ詳細のサマリーを表示するには、「サマリー」をクリックします。
「構成データの準備」ステップで、PDBの作成を準備します。

「前提条件の確認」ステップで、PDB作成の前提条件を確認します。

「検証と準備」ステップで、PDB作成前のタスクが実行されます。

「構成の実行」ステップで、PDBの作成が実行されます。実行されるタスクおよびステータスの詳細は、ホストにあるリモート・ログ・ファイルを参照してください。

「構成後処理」ステップで、新規に作成されたPDB詳細を使用してEnterprise Managerが更新され、カスタム・スクリプトが実行されます。

6. PDBジョブの作成プロセスを視覚的に表示するには、「結果」をクリックします。
「構成の進行状況」セクションで、ジョブの完了率と、保留中、現在実行中および完了したジョブ・ステップのリストを表示できます。エラー、警告およびログも表示できます。現在実行中のジョブ・ステップのログの末尾が表示されます。

17.5.2 プラガブル・データベースの切断ジョブの詳細の表示

PDBジョブの切断の詳細を表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・アクティビティ」を選択します。

2. 必要とするPDBジョブの切断を含むデプロイメント・プロシージャをクリックします。

3. デプロイメント・プロシージャ・ステップを展開します。PDBジョブの切断を選択します。

4. 「ジョブ・サマリー」をクリックします。

5. ジョブ詳細のサマリーを表示するには、「サマリー」をクリックします。
「構成データの準備」ステップで、PDBの切断を準備します。

「前提条件の確認」ステップで、PDB切断の前提条件を確認します。

「検証と準備」ステップで、PDB切断前のタスクが実行されます。

「構成の実行」ステップで、PDBの切断が実行されます。実行されるタスクおよびステータスの詳細は、ホストにあるリモート・ログ・ファイルを参照してください。

「構成後処理」ステップで、切断されたPDB詳細を使用してEnterprise Managerが更新されます。

6. PDBジョブの切断プロセスを視覚的に表示するには、「結果」をクリックします。
「構成の進行状況」セクションで、ジョブの完了率と、保留中、現在実行中および完了したジョブ・ステップのリストを表示できます。エラー、警告およびログも表示できます。現在実行中のジョブ・ステップのログの末尾が表示されます。

17.5.3 プラガブル・データベースの削除ジョブの詳細の表示

PDBの削除ジョブの詳細を表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・アクティビティ」を選択します。

2. 必要なPDBの削除ジョブが含まれるデプロイメント・プロシージャをクリックします。

3. デプロイメント・プロシージャ・ステップを展開します。PDBの削除ジョブを選択します。

4. 「ジョブ・サマリー」をクリックします。

5. ジョブ詳細のサマリーを表示するには、「サマリー」をクリックします。
「構成データの準備」ステップで、PDBの削除を準備します。

「検証と準備」ステップで、PDB削除前のタスクが実行されます。

「構成の実行」ステップで、PDBの削除が実行されます。実行されるタスクおよびステータスの詳細は、ホストにあるリモート・ログ・ファイルを参照してください。

「構成後処理」ステップでは、削除されたPDB詳細によってEnterprise Managerが更新されます。

6. PDBの削除ジョブのプロセスを視覚的に表示するには、「結果」をクリックします。
「構成の進行状況」セクションで、ジョブの完了率と、保留中、現在実行中および完了したジョブ・ステップのリストを表示できます。エラー、警告およびログも表示できます。現在実行中のジョブ・ステップのログの末尾が表示されます。

17.6 プラガブル・データベースの管理

この項では、Cloud Controlを使用してPDBの管理タスクを実行する方法について説明します。次の項目が含まれます。

- プラガブル・データベース間の切替え

- プラガブル・データベースの状態の変更

17.6.1 プラガブル・データベース間の切替え

ユーザー権限の付与やパフォーマンス・レポート作成などのタスクを実行していて、同じタスクを別のPDBで実行する必要がある場合、Cloud Controlを使用して別のPDBに切り替えることができます。同じ機能のページにアクセスしたまま、PDB間で切り替えるには、次の手順に従います。

1. 現在のPDBから、任意のPDBのスコープ・ページ(アドバンスト・キューの管理ページなど)を選択します。
ウィンドウの左上隅で、PDBの名前が更新され、ドロップダウン・メニューとしてコンテキスト・スイッチャが表示されます。

2. コンテキスト・スイッチャをクリックして、ドロップダウン・メニュー表示します。このメニューには、最後に使用したPDBが表示されます。
このリストからPDBを選択します。

3. ページが更新され、システム・キューが表示されます。

4. コンテキスト・スイッチャをクリックして、ドロップダウン・メニュー表示します。このメニューに希望のPDBが表示されない場合、「すべてのコンテナ」を選択します。

5. 「コンテナの切替え」ウィンドウが開き、監視対象ターゲットで使用可能なすべてのPDBが表示されます。
このリストからPDBを選択し、「OK」をクリックします。

6. ページが更新され、選択したPDBのデータが表示されます。

17.6.2 プラガブル・データベースの状態の変更

Cloud Controlを使用して単一インスタンスのPDBの状態をオープンまたはクローズに変更するには、次の手順を実行します。

1. 「Oracle Database」メニューから、「制御」→「プラガブル・データベースのオープン/クローズ」を選択します。

2. 「プラガブル・データベースのオープン/クローズ」ページで、PDBをリストから選択します。

3. 「アクション」ドロップダウン・メニューをクリックし、適切なアクションを選択します。「オープン」、「読取り専用でオープン」および「クローズ」のいずれかを選択できます。

4. 確認ダイアログ・ウィンドウで、「はい」をクリックして、変更を完了します。選択内容の進行状況を示す処理中ダイアログ・ウィンドウが表示されます。

5. 状態の変更が完了したら、「プラガブル・データベースのオープン/クローズ」ページが、PDBの新しい状態を示すために更新されます。

クラスタ/RACのPDBの状態を、オープンまたはクローズに変更するには、次の手順に従います。

1. 「Oracle Database」メニューから、「制御」→「プラガブル・データベースのオープン/クローズ」を選択します。

2. 「プラガブル・データベースのオープン/クローズ」ページで、PDBをリストから選択します。RACインスタンスは、そのインスタンス上で、PDBの現在の状態とともに表示されます。

3. PDBを選択すると、異なるRACインスタンス上のPDBの状態を示すために、リストの下にパネルが表示されます。オープンおよびクローズのオプションは、RACインスタンスのパネル上のPDBに適用します。任意の数の使用可能なRACインスタンス上で、PDBをオープンまたはクローズできます。

4. 確認ダイアログ・ウィンドウで、「はい」をクリックして、変更を完了します。選択内容の進行状況を示す処理中ダイアログ・ウィンドウが表示されます。

5. 状態の変更が完了したら、「プラガブル・データベースのオープン/クローズ」ページが、PDBの新しい状態を示すために更新されます。

第IV部

データベースのアップグレード

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

- 第18章「データベースのアップグレード」

18 データベースのアップグレード

この章では、Oracle Enterprise Manager Cloud Control(Cloud Control)を使用して、Oracle Databaseをアップグレードする方法について説明します。この章の具体的な内容は次のとおりです。

- 開始

- サポートされているリリース

- デプロイメント・プロシージャを使用したデータベースのアップグレード

- データベース・アップグレード・ウィザードを使用したOracle DatabaseまたはOracle RACデータベース・インスタンスのアップグレード

18.1 開始

この項では、この章に取り組むための手引きとして、データベースを一括アップグレードする、またはOracleホームをインストールしてデータベースをアップグレードする場合の手順の概要を説明します。この項は、Oracle Databaseのアップグレードを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表18-1 データベースのアップグレードの概要

ステップ

説明

参照リンク

ステップ1

ユースケースの選択

単一インスタンス・データベース、Oracle RACデータベース、Oracleデータベース・クラスタウェアをアップグレードするかどうかを決定し、それに対して実行するアップグレードのタイプを選択します。

Oracle Database

次のユースケースに従ったデプロイメント・プロシージャを使用して、複数のデータベース・インスタンスを一度にアップグレードできます。

- データベース・インスタンスのみのアップグレード

- クラスタ・データベースのアップグレード

- クラスタウェアのアップグレード

一度に1つのデータベース・インスタンスをアップグレードすることもできます。たとえば、以前にOracleホームの一部のデータベースをすでにアップグレードしており、今回は同じOracleホームの別のデータベースをアップグレードする場合です。

デプロイメント・プロシージャを使用してデータベースをアップグレードするには、第18.3項を参照してください。

単一インスタンス・データベースまたはOracle RACデータベース・インスタンスをアップグレードするには、第18.4項を参照してください。

ステップ2

サポートされているリリースの把握

デプロイメント・プロシージャによりアップグレードできるOracle Databaseのリリースを確認します。

デプロイメント・プロシージャでサポートされているリリースについては、第18.2項を参照してください。

ステップ3

デプロイメント・プロシージャの理解

選択する必要のあるデプロイメント・プロシージャ、およびその有効範囲とカバレッジを把握します。

データベース・アップグレードのためのデプロイメント・プロシージャの詳細は、第18.3.1項を参照してください。

ステップ4

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

- デプロイメント・プロシージャを使用したアップグレードの前提条件の詳細は、第18.3.2項を参照してください。

- データベース・インスタンスのアップグレードに関連するデプロイメント・フェーズの詳細は、第18.4.1項を参照してください。

ステップ5

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行してOracle Databaseを正常にアップグレードします。

- データベース・クラスタのアップグレード用のプロシージャの詳細は、第18.3.3項で説明する手順に従います。

- データベース・クラスタウェアのアップグレード用のプロシージャの詳細は、第18.3.4項で説明する手順に従います。

- デプロイメント・プロシージャを使用したデータベース・インスタンスのアップグレード用のプロシージャの詳細は、第18.3.5項で説明する手順に従います。

- データベース・アップグレード・ウィザードを使用してデータベース・インスタンスをアップグレードするプロシージャの詳細は、第18.4.2項を参照してください。

18.2 サポートされているリリース

このデプロイメント・プロシージャを使用して、複数ホストにまたがる次のリリースのOracle Databaseを一括アップグレードできます。

表18-2 Oracle Databaseの一括アップグレードがサポートされているリリース

サポートされているターゲット

アップグレードがサポートされるリリース

サポートされているプラットフォーム

Oracle Database (単一インスタンス・データベース)

11gリリース2

12cリリース1

すべてのプラットフォーム

1つのデータベース・インスタンスのアップグレードの場合、次のリリースがサポートされています。

表18-3 データベース・インスタンスのアップグレードがサポートされているリリース

サポートされているターゲット

アップグレードがサポートされるリリース

サポートされているプラットフォーム

Oracle Database (単一インスタンス・データベース)

11gリリース2

12cリリース1

すべてのプラットフォーム

Oracle Real Application Clusters(Oracle RAC)

11gリリース2

12cリリース1

すべてのプラットフォーム

Oracle RAC One

11gリリース2

12cリリース1

すべてのプラットフォーム

18.3 デプロイメント・プロシージャを使用したデータベースのアップグレード

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

- デプロイメント・プロシージャについて

- 前提条件の確認

- デプロイメント・プロシージャを使用したOracleクラスタ・データベースのアップグレード

- デプロイメント・プロシージャを使用したOracle Clusterwareのアップグレード

- デプロイメント・プロシージャを使用したOracle Databaseインスタンスのアップグレード

18.3.1 デプロイメント・プロシージャについて

Oracle Database 11gリリース2またはOracle Database 12cにアップグレードすると、最新のテクノロジにアクセスできるため、効率が高まり、アプリケーションのセキュアなデータ管理が可能になります。次の各ステップに従って計画、準備およびアップグレードを行うことにより、アップグレード・プロセスを最初から最後まで簡単、迅速かつ予測可能なものにすることができます。

データベース・アップグレード・デプロイメント・プロシージャは、データベースを一括アップグレードしたり、Oracleホームをインストールしてデータベースをアップグレードする際に使用します。

データベースの一括アップグレードでは、ソース・データベースを同じプラットフォームおよびバージョンの同種にする必要があります。新しいデータベース・バージョンに使用されるゴールド・イメージは、ユーザーが新しいリリースの単一の標準ゴールド・イメージを効果的に取得できるように、それらのデータベースに必要なすべてのパッチを含む必要があります。

Cloud ControlではOracleデータベースの一括アップグレード用に、「Oracleデータベースのアップグレード」デプロイメント・プロシージャが提供されます。デプロイメント・プロシージャでは、次のユースケースをサポートしています。

- データベース・インスタンスのみのアップグレード

- Database Real Application Clustersのアップグレード

- クラスタウェアのアップグレード

注意:
グリッド・インフラストラクチャをアップグレードすると、基となるASMターゲットも自動的にアップグレードされます。

一度に1つのOracle Databaseインスタンスをアップグレード、またはOracle RACデータベース・インスタンスをアップグレードする場合、アップグレードするデータベースのホームページからOracle Databaseのアップグレード・ウィザードにアクセスします。

注意:
データベースのアップグレードのデプロイメント・プロシージャでは、Oracle Data Guard構成内のデータベースおよびOracle Database Vaultを使用するデータベースのアップグレードはサポートされません。

デプロイメント・プロシージャは、デザイナ、またはオペレータの2タイプの管理者が実行できます。デザイナとして、テスト・データベースを設定し、新規ソフトウェアとパッチをデプロイし、アップグレード・プロセスを定義して、そこからゴールド・イメージを作成できます。次に、デプロイメント・プロシージャにアクセスし、必要な詳細を入力し、「プラットフォーム」、「バージョン」、「移動先」などのフィールドを1つ以上ロックします。最後にプロシージャを保存し、これをオペレータに公開します。

オペレータとしては、保存したプロシージャにアクセスし、ロック基準に基づくデータベース・セットの選択、ランタイム・アクティビティ固有の追加入力、プロシージャのスケジュールなど、特定の操作のみを実行できます。この方法で、オペレータは完全にテストされ、認証されたデプロイメント・プロシージャを本番稼働で実行するため、操作全体のエラーはより少なくなる傾向にあります。

このようなタイプの管理者の詳細、およびロック機能の使用方法の詳細は、第2.4項を参照してください。

18.3.2 前提条件の確認

Oracleデータベースをアップグレードする前に、次の前提条件に従います。

- 次の表に、各データベース・ターゲット・タイプに必要なソースおよび宛先の最小バージョンを示します。

表18-4 前提条件の確認

データベース・ターゲット・タイプ

サポートされているソースの最小バージョン

宛先バージョン

クラスタウェア

10gR2シリーズの10.2.0.4.0以上

10gR2シリーズの11.1.0.7.0以上

11gR2の11.2.0.1以上

11.2および12cシリーズ

クラスタ・データベース

10gR2シリーズの10.2.0.4.0以上

10gR2シリーズの11.1.0.7.0以上

11gR2の11.2.0.1以上

11.2および12cシリーズ

単一インスタンス・データベース

10gR2シリーズの10.2.0.4.0以上

10gR2シリーズの11.1.0.7.0以上

11gR2の11.2.0.1以上

11.2および12cシリーズ

単一インスタンスの高可用性

11gR2の11.2.0.1以上

11.2および12cシリーズ

Oracle RAC One Node

10gR2シリーズの10.2.0.4.0および11.1.0.7.0以上

11gR2の11.2.0.1以上

11.2および12cシリーズ

自動ストレージ管理

10.2.0.4以上の場合のみ適用

11.1.0.7以上(スタンドアロン・タイプ)

11.2および12cシリーズ

- データベース・ユーザーがSYSDBA権限を持つか、OSユーザーがDBAグループの一部である必要があります。

- アップグレードするデータベースおよびすべてのノード・インスタンス(クラスタ・データベースの場合)が稼働している必要があります。

- 必要な権限を持つデザイナ・ロールおよびオペレータ・ロールが作成されていることを確認する必要があります。デザイナにはEM_PROVISIONING_DESIGNERロールが必要であり、オペレータにはEM_PROVISIONING_OPERATORロールが必要です。

- デザイナには次の権限が必要です。

- ゴールド・イメージなどのソフトウェア・ライブラリのエンティティを管理するソフトウェア・ライブラリへの編集アクセス権。

- ターゲット権限の追加/編集。

- 名前付き資格証明の作成権限。

- オペレータには次の権限が必要です。

- ゴールド・イメージなどのソフトウェア・ライブラリ・エンティティを表示するためのソフトウェア・ライブラリへのアクセス権の表示。

- ターゲット権限の追加/表示。

- デザイナによって付与された名前付き資格証明への権限。

18.3.3 デプロイメント・プロシージャを使用したOracleクラスタ・データベースのアップグレード

デプロイメント・プロシージャを使用してOracleクラスタ・データベースをアップグレードするには、次の手順に従います。

1. デザイナ・ロールで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. 「データベースのプロビジョニング」コンソールで、「Oracleデータベースのアップグレード」デプロイメント・プロシージャを選択し、「起動」をクリックします。データベース・アップグレード・ウィザードが起動します。

3. 「ターゲット」ページの「ターゲットの選択」セクションで、「ターゲット・タイプ」として「クラスタ・データベース」を選択します。

注意:
「クラスタ・データベース」オプションでは、クラスタ・データベースをアップグレードし、オプションで基になる自動ストレージ管理ターゲットおよび管理対象のクラスタウェアを同じプロセスの一部としてアップグレードできます。

4. 「宛先」リストから、アップグレードするデータベースのバージョンを選択します。

5. 「ターゲットの追加」をクリックします。

6. 「アップグレードするターゲットの選択」で、クラスタ検索アイコンをクリックして、クラスタ・データベースを検索します。
「検索と選択: クラスタ・ターゲット」ダイアログ・ボックスで、アップグレードするクラスタ・データベースを選択し、「選択」をクリックします。

注意:
アップグレードするデータベースが表に表示されない場合、データベースが使用可能か、ターゲットに対するメトリック収集エラーがないかどうかを確認します。

注意:
選択したクラスタ・データベースが親クラスタの場合、HAS、ASM、クラスタ・データベースなどのすべての子ノードが自動的に選択されます。

クラスタ・データベース・バージョンを選択します。「OK」をクリックします。

7. 「ターゲット」ページで、「保存」をクリックします。

8. 「プロシージャの保存」ダイアログ・ボックスで、説明を入力します。
次に例を示します。

Upgrade Oracle Database Procedure 1

「保存」をクリックします。

9. 「情報」ダイアログ・ボックスが表示されます。「OK」をクリックします。
「ログアウト」をクリックします。

10. デザイナ・ロールが完了します。オペレータ資格証明でログインします。

11. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」を選択し、「データベースのプロビジョニング」を選択します。

12. 「データベースのプロビジョニング」ページで、「起動」を除くすべての操作がオペレータで無効になります。保存されたデータベース・アップグレード・デプロイメント・プロシージャが選択されます。「起動」をクリックします。

13. 「ターゲット」ページで、「次へ」をクリックします。

14. 「ソフトウェア詳細」ページの「グリッド・インフラストラクチャ」セクションで、「検索」アイコンをクリックし、グリッド・インフラストラクチャ・ソフトウェアをソフトウェア・ライブラリから選択して、新しいOracleホームを作成します。

注意:
ソフトウェアはゴールド・イメージまたは圧縮済のインストール・メディアとしてソフトウェア・ライブラリに格納されています。

表示されたダイアログ・ボックスから、グリッド・インフラストラクチャ・ソフトウェアを選択し、「選択」をクリックします。

15. 「Oracleデータベース」セクションで、次の詳細を指定します。

1. 「Oracle Databaseソフトウェア」セクションで、検索アイコンをクリックし、ソフトウェア・ライブラリから「Oracle Databaseソフトウェア」を選択して、新しいOracleホームを作成します。
ソフトウェアはゴールド・イメージまたは圧縮済のインストール・メディアとしてソフトウェア・ライブラリに格納されています。圧縮されたOracleホームに新規Oracleホーム用の重要なパッチがすべて含まれることを確認してください。

注意:
作成するゴールド・イメージにすべての推奨パッチが含まれていることを確認するには、次の手順に従います。

1. データベース・アップグレード・プランナリンクをクリックし、オンライン・モードでCloud Controlを使用してMy Oracle Supportにログインします。

2. ゴールド・イメージに適用するパッチのタイプを次から選択します。

- アップグレード先のリリースの推奨パッチ

- ベース・リリースに修正を含んだリリースの上位のパッチ

- 選択したパッチ間にマージの競合がある場合に解決するパッチ

3. パッチ計画を使用して、または手動で、アップグレードするリリースのOracleホームにパッチを適用します。

4. Oracleホームからゴールド・イメージを作成し、アップグレードに使用します。

2. 「ソフトウェアの場所」セクションで、データベースのOracleベースおよびデータベースのOracleホームのソフトウェアの場所を指定するか、ソフトウェアの場所が正しいかどうかを確認します。

3. 「ユーザー・グループ」セクションで、次のユーザー・グループに対して指定した値を指定するか、値が正しいかどうかを確認します。
- データベースのバックアップとテープのリカバリ(OSBACKUPDBA)グループ: このグループは、オペレーティング・システム・ユーザーの別のグループにバックアップおよびリカバリ関連の管理の制限付き権限セット(SYSBACKUP権限)を付与する場合に作成します。このグループの通常の名前はbackupdbaです。

- Data Guard管理(OSDBDBA)グループ: このグループは、オペレーティング・システム・ユーザーの別のグループにOracle Data Guardを管理および監視する制限付き権限セット(SYSDG権限)を付与する場合に作成します。このグループの通常の名前はdgdbaです。

- 暗号化鍵管理(OSKMDBA)グループ: このグループは、オペレーティング・システム・ユーザーの別のグループに、Oracle Wallet Managerの管理など暗号化鍵管理の制限付き権限セット(SYSKM権限)を付与する場合に作成します。このグループの通常の名前はkmdbaです。

4. 「作業ディレクトリ」セクションで、各ターゲット・ホスト上の作業ディレクトリを指定します。すべてのホストが、指定した作業ディレクトリに対する読取り/書込み権限があることを確認します。

注意:
「ロック」アイコンをクリックし、編集可能にしないフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

5. 「次へ」をクリックします。

16. 「資格証明」ページで、グリッド・インフラストラクチャおよびデータベースのオペレーティングシステム資格証明、権限付きのオペレーティング・システム資格証明(rootとして実行)、およびデータベース資格証明を指定します。「優先資格証明」の指定を選択した場合は、「通常ホスト資格証明」または「特権ホスト資格証明」のいずれかを選択します。「名前付き資格証明」については、Oracleホームと同じまたは別の資格証明を指定することができます。
「名前付き資格証明」を設定していない場合、「資格証明」セクションでプラス記号(+)をクリックします。新規データベース資格証明の追加ポップアップで、「ユーザー名」、「パスワード」、「ロール」を指定し、「詳細の保存」を指定します。「別名実行」を選択し、「ルート」を指定します。「OK」をクリックします。

「ロック」アイコンをクリックし、編集可能にしないフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

17. 「構成詳細」ページで、リストア方法の「バックアップとリストア」設定オプションがデフォルトで選択されます。
リストア方法セクションでは、次を選択できます。

- バックアップおよびリストアの設定のみ: アップグレードが失敗した場合、実際のデータではなく、データベース・アップグレード中に行われた構成の変更をリストアします。

- アップグレード前にRMANバックアップを作成: バックアップの場所を入力します。

注意:
RMANを使用してバックアップを実行する場合は、ファイルシステムまたはASMのデータファイルに関係なく、データベース全体をリストアできます。RMANを使用したバックアップは、12cにアップグレードした場合のみ使用できます。

- 既存のRMANバックアップの使用: 最新のRMANバックアップが使用されます。

- フラッシュバックおよび保証付きリストア・ポイントの使用

注意:
ソース・データベースのバージョンは11g以上である必要があります。ターゲット・ホームのバージョンは12cである必要があります。

- 全体バックアップ: データベースをバックアップし、アップグレードが失敗した場合、構成およびoratab設定をリストアします。デフォルトのバックアップの場所は、'$GDB''がグローバル・データベース名である$ORACLE_BASE/admin/$GDB/backupです。

- 無視: 独自のバックアップ・オプションがあり、Cloud Controlにデータベースのバックアップを実行させたくない場合。

注意:
「ロック」アイコンをクリックし、編集可能にしないフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

左側のパネルから「アップグレード・オプション」を選択します。

18. 「アップグレード・オプション」セクションで、次の操作を実行できます。

- 「アップグレード終了時に無効なオブジェクトを再コンパイル」を選択して、新しいデータベース・バージョンの有効なデータベース・オブジェクトを作成します。

- データベース・バージョン11.2.0.2以上にアップグレードする場合、タイムゾーン・アップグレード・オプションを設定できます。タイムゾーン・バージョンとTIMESTAMP WITH TIME ZONEデータをアップグレードを選択できます。

- アップグレード前に統計を収集を選択します。

- データベースでアーカイブ・ロギングがオンである場合、各データベースでアーカイブおよびフラッシュバック・ロギングを無効にするオプションを選択できます。

19. 「アップグレード前および後のスクリプト」セクションで、データベースのアップグレードの前後に実行するカスタム・スクリプトを指定します。次の各スクリプトで、データベースをアップグレードする前に実行されるSQLスクリプトが含まれるソフトウェア・ライブラリから、コンポーネントを選択します。

- アップグレード前のSQLスクリプト

- アップグレード後のSQLスクリプト

- アップグレード後のPerlスクリプト

「次へ」をクリックします。

20. カスタム・パラメータが必要なユーザー・カスタマイズ済デプロイメント・プロシージャに対してのみカスタム・プロパティ・ページが表示されます。アップグレードに関するカスタム・プロパティ(存在する場合)を指定します。「次へ」をクリックします。

21. 「スケジュール」ページで、「デプロイメント・インスタンス名」を指定し、アップグレード・ジョブをスケジュールします。プロシージャを即時実行する場合は、デフォルトで選択されている「即時」を選択します。ジョブを後で実行する場合は、「後で」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。Cloud Controlが指定の時刻にアップグレードを開始できなかった場合に、再度開始しようとするまでの間隔である「猶予期間」を指定します。
「ブレークポイント」セクションで、「ブレーク・ポイントの設定」を選択し、「次の後にブレーク・ポイントを設定」リストから、ブレークポイントを後にするステップを選択して、ブレークポイントを設定できます。

これらのブレークポイントを適切に設定することで、アップグレード・プロセスの実際の停止時間を短縮できます。

たとえば、停止時間はアプリケーションのみで、ソフトウェア・インストールの間ではなく実際のアップグレード・プロセスの間であるため、「クラスタ・データベースのアップグレード」の手順の前にブレークポイントを設定できます。

「データベース・アップグレード・インスタンスのトラッキング」ページから、ブレークポイントを変更して実行を再開することもできます。

「通知詳細の設定」セクションで、通知が必要なイベントを選択します。

「次へ」をクリックします。

22. 確認ページで、選択した詳細が正しく表示されていることを確認します。詳細を変更する場合、変更を加えるページに到達するまで、「戻る」をクリックします。
将来使用するためにデプロイメント・プロシージャを保存する場合、「保存」をクリックします。

デプロイメント・プロシージャを発行する場合、「発行」をクリックします。デプロイメント・プロシージャが実行を目的として発行されると、データベース・アップグレード・インスタンスの追跡ページが表示されます。また、ジョブ・アクティビティ・ページでプロシージャ・インスタンスをクリックしてこのページに移動することもできます。

23. 編集可能フィールドに値を入力した後で、構成されたデータベース・アップグレード・プロシージャを発行します。プロシージャを発行した後、実行中のプロシージャに関するサマリーが表示されます。

24. Oracleデータベースのアップグレード・プロシージャ実行ページの「現在の実行」タブで、アップグレード・ジョブのステップおよびステータスを表示します。

25. ブレークポイントを指定した場合、プロシージャ実行は、指定したステップで一時休止します。実行が一時停止すると、「実行する上限ステップ」リストを使用して、次のいずれかを実行できます。

- 適切なステップを選択して、新しいブレークポイントを設定する

- 「残りすべての手順」を選択する

「停止」、「再開」、「一時停止」、「クリーンアップ」、「再送信」および「ステップのスキップ」のアクションを実行することもできます。現在のインスタンスを実行するために再発行する場合は、「再送信」をクリックします。

- 一時停止: アップグレード・デプロイメント・プロシージャを一時停止します。

- 再開: 一時停止した後、アップグレード・デプロイメント・プロシージャを再開します。

- 停止: アップグレード・デプロイメント・プロシージャを停止します。

- リストア: グリッド・インフラストラクチャのロールバックを実行します。これにより、別のデプロイメント・プロシージャが送信されます。

注意:
ロールバック・インスタンスはアップグレード実行と同じページで追跡できます。これは、GIロールバックの間に致命的な障害が発生した場所で使用できます。

- 再試行: 失敗したステップを再試行します。このオプションは、以前の実行で失敗していた可能性のある前提条件ステップの再試行に使用できます(修正はフローの外側で実施済)。

- 無視: 失敗したステップを無視します。

- 再送信: アップグレード・デプロイメント・プロシージャを再送信します(通常は、見つかったエラーの修正後)。一般に、これは以前の実行を再試行することができない場合のみ使用する必要があります。

26. ステップのステータスが「失敗」である場合、「ログの表示」をクリックします。ステップの「ジョブ実行」がリストされます。「詳細」列の「表示」をクリックし、ログ全体を表示します。エラーを修正し、「再試行」をクリックします。

27. プロシージャの実行が完了した後で、「データベース」」メニューをクリックし、新たにアップグレードしたデータベースがCloud Controlターゲットとして表示されることを確認します。

18.3.4 デプロイメント・プロシージャを使用したOracle Clusterwareのアップグレード

デプロイメント・プロシージャを使用してOracle Clusterwareをアップグレードするには、次の手順に従います。

1. デザイナ・ロールで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. 「データベースのプロビジョニング」コンソールで、「Oracleデータベースのアップグレード」デプロイメント・プロシージャを選択し、「起動」をクリックします。データベース・アップグレード・ウィザードが起動します。

3. 「ターゲット」ページの「ターゲットの選択」セクションで、「ターゲット・タイプ」として「クラスタウェア」を選択します。

注意:
「クラスタウェア」オプションでは、クラスタウェアと、オプションで基になる自動ストレージ管理ターゲットを同じプロセスの一部としてアップグレードできます。

4. 「宛先」リストから、アップグレードするデータベースのバージョンを選択します。

5. 「ターゲットの追加」をクリックします。

6. 「アップグレードするターゲットの選択」ダイアログ・ボックスで、クラスタ検索アイコンをクリックして、クラスタを検索します。
「検索と選択: クラスタ・ターゲット」ダイアログ・ボックスで、アップグレードするクラスタを選択し、「選択」をクリックします。

注意:
アップグレードするデータベースが表に表示されない場合、データベースが使用可能か、ターゲットに対するメトリック収集エラーがないかどうかを確認します。

注意:
選択したクラスタ・データベースが親クラスタの場合、HAS、ASM、クラスタ・データベースなどのすべての子ノードが自動的に選択されます。

「OK」をクリックします。

7. 「ターゲット」ページで、「保存」をクリックします。

8. 「プロシージャの保存」ダイアログ・ボックスで、説明を入力します。
次に例を示します。

Upgrade Oracle Database Procedure 1

「保存」をクリックします。

9. 「情報」ダイアログ・ボックスが表示されます。「OK」をクリックします。
「ログアウト」をクリックします。

10. デザイナ・ロールが完了します。オペレータ資格証明でログインします。

11. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」を選択し、「データベースのプロビジョニング」を選択します。

12. 「データベースのプロビジョニング」ページで、「起動」を除くすべての操作がオペレータで無効になります。保存されたデータベース・アップグレード・デプロイメント・プロシージャが選択されます。「起動」をクリックします。

13. 「ターゲット」ページで、「次へ」をクリックします。

14. 「ソフトウェア詳細」ページの「グリッド・インフラストラクチャ」セクションで、「検索」アイコンをクリックし、グリッド・インフラストラクチャ・ソフトウェアをソフトウェア・ライブラリから選択して、新しいOracleホームを作成します。

注意:
ソフトウェアはゴールド・イメージまたは圧縮済のインストール・メディアとしてソフトウェア・ライブラリに格納されています。

表示されたダイアログ・ボックスから、グリッド・インフラストラクチャ・ソフトウェアを選択し、「選択」をクリックします。

15. 「作業ディレクトリ」セクションで、各ターゲット・ホスト上の作業ディレクトリを指定します。ホスト・ターゲット上の作業ディレクトリは、グリッド・インフラストラクチャまたはデータベースのインストールまたはアップグレード中にファイルをステージングするために必要です。すべてのホストが、指定した作業ディレクトリに対する読取り/書込み権限があることを確認します。

注意:
「ロック」アイコンをクリックし、編集可能にしないフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

16. 「資格証明」ページで、グリッド・インフラストラクチャのオペレーティングシステム資格証明、および権限付きのオペレーティング・システム資格証明(rootとして実行)を指定します。「優先資格証明」の指定を選択した場合は、「通常ホスト資格証明」または「特権ホスト資格証明」のいずれかを選択します。「名前付き資格証明」については、Oracleホームと同じまたは別の資格証明を指定することができます。
「名前付き資格証明」を設定していない場合、「資格証明」セクションでプラス記号(+)をクリックします。新規データベース資格証明の追加ポップアップで、「ユーザー名」、「パスワード」、「ロール」を指定し、「詳細の保存」を指定します。「別名実行」を選択し、「ルート」を指定します。「OK」をクリックします。

「ロック」アイコンをクリックし、編集可能にしないフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

17. カスタム・パラメータが必要なユーザー・カスタマイズ済デプロイメント・プロシージャに対してのみカスタム・プロパティ・ページが表示されます。アップグレードに関するカスタム・プロパティ(存在する場合)を指定します。「次へ」をクリックします。

18. 「スケジュール」ページで、「デプロイメント・インスタンス名」を指定し、アップグレード・ジョブをスケジュールします。プロシージャを即時実行する場合は、デフォルトで選択されている「即時」を選択します。ジョブを後で実行する場合は、「後で」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。Cloud Controlが指定の時刻にアップグレードを開始できなかった場合に、再度開始しようとするまでの間隔である「猶予期間」を指定します。
「ブレークポイント」セクションで、「ブレーク・ポイントの設定」を選択し、「次の後にブレーク・ポイントを設定」リストから、ブレークポイントを後にするステップを選択して、ブレークポイントを設定できます。

これらのブレークポイントを適切に設定することで、アップグレード・プロセスの実際の停止時間を短縮できます。

たとえば、停止時間はアプリケーションのみで、ソフトウェア・インストールの間ではなく実際のアップグレード・プロセスの間であるため、「クラスタウェアのアップグレード」の手順の前にブレークポイントを設定できます。

停止時間は、ソフトウェア・インストールの間ではなく、実際のアップグレードの間のみに適用されます。この停止時間は、実際のアップグレード・プロセス自体に対してのみです。DPには、「クラスタウェアのアップグレード」は停止時間を必要とするステップであることを表示するステップがあります。

「データベース・アップグレード・インスタンスのトラッキング」ページから、ブレークポイントを変更して実行を再開することもできます。

「通知詳細の設定」セクションで、通知が必要なイベントを選択します。

「次へ」をクリックします。

19. 確認ページで、選択した詳細が正しく表示されていることを確認します。詳細を変更する場合、変更を加えるページに到達するまで、「戻る」をクリックします。
将来使用するためにデプロイメント・プロシージャを保存する場合、「保存」をクリックします。

デプロイメント・プロシージャを発行する場合、「発行」をクリックします。デプロイメント・プロシージャが実行を目的として発行されると、データベース・アップグレード・インスタンスの追跡ページが表示されます。また、ジョブ・アクティビティ・ページでプロシージャ・インスタンスをクリックしてこのページに移動することもできます。

20. 編集可能フィールドに値を入力した後で、構成されたデータベース・アップグレード・プロシージャを発行します。プロシージャを発行した後、実行中のプロシージャに関するサマリーが表示されます。

21. Oracleデータベースのアップグレード・プロシージャ実行ページの「現在の実行」タブで、アップグレード・ジョブのステップおよびステータスを表示します。

22. ブレークポイントを指定した場合、プロシージャ実行は、指定したステップで一時休止します。実行が一時停止すると、「実行する上限ステップ」リストを使用して、次のいずれかを実行できます。

- 適切なステップを選択して、新しいブレークポイントを設定する

- 「残りすべての手順」を選択する

「停止」、「再開」、「一時停止」、「クリーンアップ」、「再送信」および「ステップのスキップ」のアクションを実行することもできます。現在のインスタンスを実行するために再発行する場合は、「再送信」をクリックします。

- 一時停止: アップグレード・デプロイメント・プロシージャを一時停止します。

- 再開: 一時停止した後、アップグレード・デプロイメント・プロシージャを再開します。

- 停止: アップグレード・デプロイメント・プロシージャを停止します。

- リストア: グリッド・インフラストラクチャのロールバックを実行します。これにより、別のデプロイメント・プロシージャが送信されます。

注意:
ロールバック・インスタンスはアップグレード実行と同じページで追跡できます。これは、GIロールバックの間に致命的な障害が発生した場所で使用できます。

- 再試行: 失敗したステップを再試行します。このオプションは、以前の実行で失敗していた可能性のある前提条件ステップの再試行に使用できます(修正はフローの外側で実施済)。

- 無視: 失敗したステップを無視します。

- 再送信: アップグレード・デプロイメント・プロシージャを再送信します(通常は、見つかったエラーの修正後)。一般に、これは以前の実行を再試行することができない場合のみ使用する必要があります。

23. ステップのステータスが「失敗」である場合、「ログの表示」をクリックします。ステップの「ジョブ実行」がリストされます。「詳細」列の「表示」をクリックし、ログ全体を表示します。エラーを修正し、「再試行」をクリックします。

24. プロシージャの実行の完了後、「ターゲット」メニューをクリックし、「すべてのターゲット」を選択して、「すべてのターゲット」ページに移動し、新しくアップグレードされたデータベースがCloud Controlターゲットとして表示されることを確認します。

18.3.5 デプロイメント・プロシージャを使用したOracle Databaseインスタンスのアップグレード

デプロイメント・プロシージャを使用してOracle Databaseインスタンスをアップグレードするには、次の手順に従います。

1. デザイナ・ロールで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. 「データベースのプロビジョニング」コンソールで、「Oracleデータベースのアップグレード」デプロイメント・プロシージャを選択し、「起動」をクリックします。データベース・アップグレード・ウィザードが起動します。

3. 「ターゲット」ページの「ターゲットの選択」セクションで、「ターゲット・タイプ」として「単一インスタンス・データベース」を選択します。

注意:
「単一インスタンス・データベース」オプションでは、単一インスタンス・データベースをアップグレードし、オプションで基になる自動ストレージ管理ターゲットおよび管理対象の高可用性サービスを同じプロセスの一部としてアップグレードできます。

4. 「宛先」リストから、アップグレードするデータベースのバージョンを選択します。

5. 「ターゲットの追加」をクリックします。

6. 「アップグレードするターゲットの選択」ダイアログ・ボックスで、アップグレードするデータベース・インスタンスのソース・バージョンとプラットフォームを選択します。「検索」をクリックします。
「検索と選択: クラスタ・ターゲット」ダイアログ・ボックスで、アップグレードするデータベース・インスタンス・ターゲットを選択します。

注意:
アップグレードするデータベースが表に表示されない場合、データベースが使用可能か、ターゲットに対するメトリック収集エラーがないかどうかを確認します。

リスナーのアップグレードを選択して、リスナーのアップグレードを選択できます。ソースOracleホームで選択したリスナーは、データベースの宛先Oracleホームに移行され、再起動されます。

「OK」をクリックします。

7. 「ターゲット」ページで、「保存」をクリックします。

8. 「プロシージャの保存」ダイアログ・ボックスで、説明を入力します。
次に例を示します。

Upgrade Oracle Database Procedure 1

「保存」をクリックします。

9. 「情報」ダイアログ・ボックスが表示されます。「OK」をクリックします。
「ログアウト」をクリックします。

10. デザイナ・ロールが完了します。オペレータ資格証明でログインします。

11. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」を選択し、「データベースのプロビジョニング」を選択します。

12. 「データベースのプロビジョニング」ページで、「起動」を除くすべての操作がオペレータで無効になります。保存されたデータベース・アップグレード・デプロイメント・プロシージャが選択されます。「起動」をクリックします。

13. 「ターゲット」ページで、「次へ」をクリックします。

14. 「Oracleデータベース」セクションで、「データベース・インスタンスのみのアップグレード」を選択します。データベースのOracleホームの場所を指定します。
「作業ディレクトリ」セクションで、各ターゲット・ホスト上の作業ディレクトリを指定します。ホスト・ターゲット上の作業ディレクトリは、グリッド・インフラストラクチャまたはデータベースのインストールまたはアップグレード中にファイルをステージングするために必要です。すべてのホストが指定した作業ディレクトリに対する読取り/書込み権限があることを確認します。

注意:
「ロック」アイコンをクリックし、編集可能にしないフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

15. 「資格証明」ページで、データベースのオペレーティングシステム資格証明、権限付きのオペレーティング・システム資格証明(rootとして実行)、およびデータベース資格証明を指定します。「優先資格証明」の指定を選択した場合は、「通常ホスト資格証明」または「特権ホスト資格証明」のいずれかを選択します。「名前付き資格証明」については、Oracleホームと同じまたは別の資格証明を指定することができます。
「名前付き資格証明」を設定していない場合、「資格証明」セクションでプラス記号(+)をクリックします。新規データベース資格証明の追加ポップアップで、「ユーザー名」、「パスワード」、「ロール」を指定し、「詳細の保存」を指定します。「別名実行」を選択し、「ルート」を指定します。「OK」をクリックします。

「ロック」アイコンをクリックし、編集可能にしないフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

「次へ」をクリックします。

16. 「構成詳細」ページで、リストア方法の「バックアップとリストア」設定オプションがデフォルトで選択されます。
リストア方法セクションでは、次を選択できます。

- バックアップおよびリストアの設定のみ: アップグレードが失敗した場合、実際のデータではなく、データベース・アップグレード中に行われた構成の変更をリストアします。

- アップグレード前にRMANバックアップを作成: バックアップの場所を入力します。

注意:
RMANを使用してバックアップを実行する場合は、ファイルシステムまたはASMのデータファイルに関係なく、データベース全体をリストアできます。RMANを使用したバックアップは、12cにアップグレードした場合のみ使用できます。

- 既存のRMANバックアップの使用: 最新のRMANバックアップが使用されます。

- フラッシュバックおよび保証付きリストア・ポイントの使用

注意:
ソース・データベースのバージョンは11g以上である必要があります。ターゲット・ホームのバージョンは12cである必要があります。

- 全体バックアップ: データベースをバックアップし、アップグレードが失敗した場合、構成およびoratab設定をリストアします。デフォルトのバックアップの場所は、'$GDB''がグローバル・データベース名である$ORACLE_BASE/admin/$GDB/backupです。

- 無視: 独自のバックアップ・オプションがあり、Cloud Controlにデータベースのバックアップを実行させたくない場合。

注意:
「ロック」アイコンをクリックし、編集可能にしないフィールドをロックします。これらのフィールドはオペレータ・ロールでは編集できなくなります。

左側のパネルから「アップグレード・オプション」を選択します。

17. 「アップグレード・オプション」セクションで、次の操作を実行できます。

- 「アップグレード終了時に無効なオブジェクトを再コンパイル」を選択して、新しいデータベース・バージョンの有効なデータベース・オブジェクトを作成します。

- データベース・バージョン11.2.0.2以上にアップグレードする場合、タイムゾーン・アップグレード・オプションを設定できます。タイムゾーン・バージョンとTIMESTAMP WITH TIME ZONEデータをアップグレードを選択できます。

- アップグレード前に統計を収集を選択します。

- データベースでアーカイブ・ロギングがオンである場合、各データベースでアーカイブおよびフラッシュバック・ロギングを無効にするオプションを選択できます。

18. 「アップグレード前および後のスクリプト」セクションで、データベースのアップグレードの前後に実行するカスタム・スクリプトを指定します。次の各スクリプトで、データベースをアップグレードする前に実行されるSQLスクリプトが含まれるソフトウェア・ライブラリから、コンポーネントを選択します。

- アップグレード前のSQLスクリプト

- アップグレード後のSQLスクリプト

- アップグレード後のPerlスクリプト

「次へ」をクリックします。

19. カスタム・パラメータが必要なユーザー・カスタマイズ済デプロイメント・プロシージャに対してのみカスタム・プロパティ・ページが表示されます。アップグレードに関するカスタム・プロパティ(存在する場合)を指定します。「次へ」をクリックします。

20. 「スケジュール」ページで、「デプロイメント・インスタンス名」を指定し、アップグレード・ジョブをスケジュールします。プロシージャを即時実行する場合は、デフォルトで選択されている「即時」を選択します。ジョブを後で実行する場合は、「後で」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。Cloud Controlが指定の時刻にアップグレードを開始できなかった場合に、再度開始しようとするまでの間隔である「猶予期間」を指定します。
「ブレークポイント」セクションで、「ブレーク・ポイントの設定」を選択し、「次の後にブレーク・ポイントを設定」リストから、ブレークポイントを後にするステップを選択して、ブレークポイントを設定できます。

これらのブレークポイントを適切に設定することで、アップグレード・プロセスの実際の停止時間を短縮できます。

たとえば、停止時間はアプリケーションのみで、ソフトウェア・インストールの間ではなく実際のアップグレード・プロセスの間であるため、「データベース・インスタンスのアップグレード」の手順の前にブレークポイントを設定できます。

「データベース・アップグレード・インスタンスのトラッキング」ページから、ブレークポイントを変更して実行を再開することもできます。

「通知詳細の設定」セクションで、通知が必要なイベントを選択します。

「次へ」をクリックします。

21. 確認ページで、選択した詳細が正しく表示されていることを確認します。詳細を変更する場合、変更を加えるページに到達するまで、「戻る」をクリックします。
将来使用するためにデプロイメント・プロシージャを保存する場合、「保存」をクリックします。

デプロイメント・プロシージャを発行する場合、「発行」をクリックします。デプロイメント・プロシージャが実行を目的として発行されると、データベース・アップグレード・インスタンスの追跡ページが表示されます。また、ジョブ・アクティビティ・ページでプロシージャ・インスタンスをクリックしてこのページに移動することもできます。

22. 編集可能フィールドに値を入力した後で、構成されたデータベース・アップグレード・プロシージャを発行します。プロシージャを発行した後、実行中のプロシージャに関するサマリーが表示されます。

23. Oracleデータベースのアップグレード・プロシージャ実行ページの「現在の実行」タブで、アップグレード・ジョブのステップおよびステータスを表示します。

24. ブレークポイントを指定した場合、プロシージャ実行は、指定したステップで一時休止します。実行が一時停止すると、「実行する上限ステップ」リストを使用して、次のいずれかを実行できます。

- 適切なステップを選択して、新しいブレークポイントを設定する

- 「残りすべての手順」を選択する

「停止」、「再開」、「一時停止」、「クリーンアップ」、「再送信」および「ステップのスキップ」のアクションを実行することもできます。現在のインスタンスを実行するために再発行する場合は、「再送信」をクリックします。

- 一時停止: アップグレード・デプロイメント・プロシージャを一時停止します。

- 再開: 一時停止した後、アップグレード・デプロイメント・プロシージャを再開します。

- 停止: アップグレード・デプロイメント・プロシージャを停止します。

- リストア: グリッド・インフラストラクチャのロールバックを実行します。これにより、別のデプロイメント・プロシージャが送信されます。

注意:
ロールバック・インスタンスはアップグレード実行と同じページで追跡できます。これは、GIロールバックの間に致命的な障害が発生した場所で使用できます。

- 再試行: 失敗したステップを再試行します。このオプションは、以前の実行で失敗していた可能性のある前提条件ステップの再試行に使用できます(修正はフローの外側で実施済)。

- 無視: 失敗したステップを無視します。

- 再送信: アップグレード・デプロイメント・プロシージャを再送信します(通常は、見つかったエラーの修正後)。一般に、これは以前の実行を再試行することができない場合のみ使用する必要があります。

25. ステップのステータスが「失敗」である場合、「ログの表示」をクリックします。ステップの「ジョブ実行」がリストされます。「詳細」列の「表示」をクリックし、ログ全体を表示します。エラーを修正し、「再試行」をクリックします。

26. プロシージャの実行が完了した後で、「データベース」」メニューをクリックし、新たにアップグレードしたデータベースがCloud Controlターゲットとして表示されることを確認します。

18.4 データベース・アップグレード・ウィザードを使用したOracle DatabaseまたはOracle RACデータベース・インスタンスのアップグレード

この項では、一度に単一インスタンス・データベースまたはOracle RACデータベース・インスタンスを1つずつアップグレードするウィザードの使用方法を説明します。

アップグレードすると、最新のテクノロジにアクセスできるため、効率が高まり、アプリケーションのセキュアなデータ管理が可能になります。次の各ステップに従って計画、準備およびアップグレードを行うことにより、アップグレード・プロセスを最初から最後まで簡単、迅速かつ予測可能なものにすることができます。

データベース・アップグレード機能を使用すると、データベース・アップグレード・ジョブをEnterprise Managerからリモートで発行したり、後で実行するようスケジュールできます。

このウィザードを使用して、Oracleホームがインストールまたはアップグレードされているスタンドアロン・データベースをアップグレードします。データベース・アップグレードを自動化する場合や、Oracleホームがインストールまたはアップグレードされていない場合は、「デプロイメント・プロシージャを使用したOracleデータベースのアップグレード」に説明のあるデータベース・アップグレード・デプロイメント・プロシージャを使用します。

注意:
現時点ではOracle RACデータベース・インスタンスの一括アップグレードはサポートされていないため、この項で説明するウィザードを使用して、一度にOracle RACデータベース・インスタンスを1つずつアップグレードすることをお薦めします。

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

- 前提条件の確認

- アップグレード・プロシージャの実行

18.4.1 前提条件の確認

Oracle Databaseインスタンスをアップグレードする前に、次の前提条件に従います。

- 11gまたは12cにアップグレードする場合は、データベース・バージョンを10.2.0.4以上にする必要があります。

- Oracle Real Application Clustersデータベースの場合、Oracle RACデータベース・インスタンスを選択し、データベース・アップグレード・プロセスを開始すると、クラスタ・データベース全体がアップグレードされます。

- OS認証がオンでない場合、アップグレードにはSYSDBA資格証明が必要です。

- アップグレードするデータベースは稼働中である必要があります。

- このプロシージャを実行するにはDBA権限が必要です。

18.4.2 アップグレード・プロシージャの実行

Oracle Databaseインスタンスをアップグレードするには、次の手順に従います:

1. 「エンタープライズ」メニューから、「ターゲット」、「データベース」の順に選択します。データベース・ページでは、アップグレードするソース・データベースを選択します。

2. 「データベース・インスタンス」ホーム・ページで、「Oracle Database」メニューから、「プロビジョニング」、「データベースをアップグレード」の順に選択します。

注意:
単一インスタンス・データベースのインスタンスについては、Oracleホームとインスタンスをアップグレードする別のメニュー・オプションが表示されます。このオプションを選択すると、第18.4項で説明するウィザードに進みますが、ウィザードへ移動する前のデータベース・インスタンスのみがアップグレード用に事前選択されています。

3. データベースのユーザーおよびパスワード資格証明を指定し、「続行」をクリックします。データベース・アップグレード・ウィザードが起動します。

4. Oracleホーム・ページで、アップグレードするデータベースのバージョンに基づき、アップグレード用の新規Oracleホームをインストールする「新規Oracleホーム」を選択します。
OracleホームがCloud Controlでの検出されたターゲットでない場合、Cloud Controlの検出機能を使用してOracleホームを検出してからアップグレード・プロセスを開始するか、手動でOracleホームのパスを入力します。Oracle Real Application Clustersデータベースの場合は、Oracle RACホームを指定します。

Cloud Controlでのターゲットの検出の詳細は、第3章を参照してください。

新規Oracleホームを指定する場合、ソースのOracleホームと接続先のOracleホームの両方にDBA権限があり、これらのOracleホームが同じホスト上にある必要があります。

5. 「Oracleホーム資格証明」セクションで、ホスト資格証明を指定します。ホスト資格証明にはDBA権限が必要であり、「優先資格証明」または「名前付き資格証明」にするか、「資格証明を入力」を選択してユーザー名とパスワードを指定して保存することもできます。選択したホスト資格証明に関する詳細を表示するには、「詳細」をクリックします。指定されたOracleホーム資格証明は、ソース・データベースのOracleホームと新しいOracleホームの両方の権限が必要です。資格証明が必須の権限を持っているかどうかを検証するには、「テスト」をクリックします。名前付き資格証明を使用している場合、ユーザーおよびパスワード資格証明であることを確認し、それ以外の場合はCloud Controlでサポートされません。

6. 「次へ」をクリックします。前提条件チェックのエラーおよび警告が表示されます。すべてのエラーおよび警告を修正して再検証します。「OK」をクリックし、次のステップに進みます。

7. オプション・ページで、診断先フィールドは、バージョン10.2.xから11.1.0.6へのデータベース・アップグレードについてのみ表示されます。診断先のデフォルト設定はOracleベースで、すべての診断およびトレース・ファイルはこの場所に格納されます。
バージョン11.1.0.7以上から11.2.xにアップグレードする場合、「診断先」フィールドは表示されません。

8. 「アップグレード並列度」はデフォルト値の4に設定されます。最大値は8です。この機能は、データベースを12cにアップグレードしている場合にのみ使用できます。
データベースに対するアーカイブ・ロギングがオンである場合、このオプションを無効化することも、アップグレード中はアーカイブ・ロギングを有効にままにすることもできます。

データベースにフラッシュ・リカバリ領域が構成されている場合、「フラッシュ・リカバリ」セクションが表示されます。「フラッシュ・リカバリ領域の場所」を指定して、「サイズ」に適切な領域を指定します。

9. データベース・バージョン11.2.0.2以上にアップグレードする場合、タイムゾーン・アップグレード・オプションを設定できます。タイムゾーンのバージョンとタイムスタンプをタイムゾーン・データでアップグレードするよう選択できます。
固定表でオプティマイザ統計を収集する場合は、「統計の収集」を選択できます。これにより、オプティマイザで最適な実行計画を生成できます。データベースをアップグレードする前に、固定オブジェクト統計を収集することをお薦めします。

「ユーザー表領域を読取り専用にする」を選択することもできます。これにより、データベースのアップグレード中に表領域が読取り専用になり、アップグレードが終了すると読取り-書込みに戻ります。

注意:
「統計の収集」および「ユーザー表領域を読取り専用にする」オプションは、12cにアップグレードした場合のみ使用できます。

注意:
データベースにASMが構成されている場合、「バックアップ」セクションは表示されません。

10. 「バックアップ」セクションでは、次を選択できます。

- リストア設定のみ: アップグレードが失敗した場合、実際のデータではなく、データベース・アップグレード中に行われた構成の変更をリストアします。

- 障害の発生時にアップグレードおよびリストア前に完全バックアップを実行: oratab構成をリストアします。「バックアップの場所」のファイルシステムの場所を指定します。以前に指定した資格証明には、この場所に対する読取り/書込み権限が必要です。

注意:
RMANを使用してバックアップを実行する場合は、ファイルシステムまたはASMのデータファイルに関係なく、データベース全体をリストアできます。RMANを使用したバックアップは、12cにアップグレードした場合のみ使用できます。

- 「既存のRMANバックアップを使用してデータベースをリストア」では、最新のRMANバックアップを使用してデータベースをリストアできます。このオプションは、データベースを12cにアップグレードする場合に固有です。

- 保証付きリストア・ポイントを使用して、データベースをフラッシュバックします。。

注意:
ソース・データベースのバージョンは11g以上である必要があります。ターゲット・ホームのバージョンは12cである必要があります。

- なし: データベース・バックアップを指定しない場合。

注意:
Oracle Database 12cリリース1 (12.1)以降、Oracle Databaseでは、Oracle Databaseのインストール時に指定されるOracleホーム・ユーザーの使用がサポートされます。このOracleホーム・ユーザーは、Oracleホームから実行されるOracleサービスの所有者で、インストール後は変更できません。システムの異なるOracleホームは、同じOracleホーム・ユーザーを共有したり、異なるOracleホーム・ユーザー名を使用できます。
Oracleホーム・ユーザーは、Oracleインストール・ユーザーとは異なります。Oracleインストール・ユーザーは、Oracle製品をインストールする管理権限を必要とするユーザーです。Oracleホーム・ユーザーは、Oracleホーム用のOracleで必要とするほとんどのWindowsサービスを実行するインストール中に指定される権限の弱いWindowsユーザー・アカウントです。Oracleホーム・ユーザーの詳細は、『Oracle Databaseプラットフォーム・ガイド』を参照してください。

データベース・バージョン12.1以上およびMicrosoft Windowsオペレーティング・システムの場合は、Oracleホームのインストール時に指定されたMicrosoft Windowsユーザーに対してデータベース・サービスが構成されます。このユーザーは、Oracleソフトウェアによって実行されるすべてのサービスを所有します。

「OracleホームのWindowsユーザー資格証明」セクションで、データベース・サービスを構成するためのMicrosoft Windowsユーザー・アカウントのホスト資格証明を指定します。既存の名前付き資格証明を選択するか、新しい資格証明を指定します。新しい資格証明を指定するには、ユーザー名およびパスワードを入力します。これらの資格証明を保存し、優先資格証明として設定することもできます。

「詳細」セクションで、データベース・アップグレードの前後に実行するカスタムSQLスクリプトを指定します。これらのスクリプトをホスト・ファイル・システムにコピーして選択します。カスタム・スクリプトがソフトウェア・ライブラリにコンポーネントとして格納されている場合、「これらのスクリプトをソフトウェア・ライブラリから選択」を選択してから、ソフトウェア・ライブラリでこれらのスクリプトを参照します。実行時には、ソフトウェア・ライブラリ・コンポーネントに指定されているメイン・ファイルが実行されます。このため、スクリプト・セットを実行する場合、これらをメイン・スクリプト・ファイル内で編成し、ソフトウェア・ライブラリ・コンポーネント内のメイン・スクリプトを指定します。

11. 「アップグレード終了時に無効なオブジェクトを再コンパイル」を選択して、新しいデータベース・バージョンの有効なデータベース・オブジェクトを作成します。「並列度」をより高く設定すると、オブジェクトをより高速に再コンパイルできます。デフォルト設定は、ホストのCPUの数です。
「次へ」をクリックします。

12. リスナー・ページは、単一インスタンス・データベース・アップグレードの場合にのみ表示されます。リスナー・ページには、Oracle Restartに登録されているリスナー、および新規Oracleホームで実行されているリスナーが表示されます。新規リスナーを作成するか、既存のリスナーを手動で移行して、データベースをアップグレードできます。新規リスナーを作成する場合、リスナーはCloud Controlのターゲットとなり、監視されます。既存のリスナーを移行する場合、アップグレード・ジョブによりそのリスナーでデータベースが登録されます。
ソースOracleホーム内でリスナーが実行されており、アップグレード後も同じリスナー・ポートを保持する必要がある場合、最初にリスナーを新規Oracleホームに手動で移行します。

Oracle Real Application Clustersデータベースの場合、アップグレードしたデータベースはクラスタウェア・リスナーに自動的に登録され、リスナー・ページは表示されません。

新規リスナーを追加するには、「名前」および「ポート番号」を指定します。

「次へ」をクリックします。

13. スケジュール・ページで、データベース・アップグレードのジョブの名前および説明を編集するか、そのまま使用します。ジョブを即時実行する場合は、デフォルトで選択されている「即時」を選択します。ジョブを後で実行する場合は、「後で」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。Cloud Controlが指定の時刻にアップグレードを開始できなかった場合に、再度アップグレード・ジョブを開始しようとするまでの間隔である「猶予期間」を指定します。
アップグレード時にCloud Controlによってデータベースが監視されず、アラートが呼び出されないようにする場合、「アップグレード中に、Enterprise Managerのデータベース・ターゲットをブラックアウトします」を選択します。

「次へ」をクリックします。

14. 確認ページで、検証サマリーに生成されているすべての警告が確認されていることを確認します。「検証サマリー」アイコンをクリックし、検証結果、重大度、および任意の警告に対して実行されたアクションを表示します。アップグレード・ジョブに対して指定した詳細が正しいことを確認してから、「ジョブの発行」をクリックして、設定したスケジュールに従ってジョブを実行します。詳細を変更する場合は、変更するページまで「戻る」を繰り返しクリックします。「保存」をクリックし、将来のデプロイ用としてデプロイメント・プロシージャを保存します。

15. ジョブを発行した後、実行中のジョブのサマリーを示すデータベース・アップグレード・ジョブ・ページが表示されます。ジョブ・ページで、ジョブ・サマリーおよびステップのリストを表示し、そのステータスを表示します。

注意:
なんらかの理由でデータベース・アップグレードが失敗したときにデータベース・アップグレード・ウィザードでバックアップ・オプションが指定されていない場合、データベースを手動でリストアし、アップグレードを再実行します。データベース・アップグレードは成功したが、アップグレード後のカスタム・スクリプトが実行されなかった場合、アップグレードは成功しているのでデータベースはリストアされません。

16. アップグレード・ジョブが正常に完了した後、「ターゲット」メニューをクリックし、「すべてのターゲット」を選択して、「すべてのターゲット」ページに移動し、新しくアップグレードされたデータベースがCloud Controlのターゲットとして正しいデータベース・バージョンで表示されることを確認します。

第V部

データベース・セキュリティ

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

- 第19章「Oracle Audit Vault and Database Firewallの管理」

- 第20章「Oracle Data Redactionの使用」

- 第21章「Oracle Database Vaultおよび権限分析の管理」

19 Oracle Audit Vault and Database Firewallの管理

Oracle Audit Vault and Database Firewall (AVDF)は、ITインフラストラクチャのデータベースとその他の重要なコンポーネントを保護します。ファイアウォール・ポリシーに基づいてネットワーク上のデータベース・アクティビティの監視およびSQL文のブロックを行うデータベース・ファイアウォールを提供します。監査データも収集し、データを監査レポートで使用できることを確認します。

Oracle AVDFプラグインを使用してEnterprise Manager Cloud Control (Cloud Control)のOracle AVDFコンポーネントを管理および監視できます。このプラグインのインストール方法およびCloud Controlを使用したOracle AVDFの管理方法の詳細は、『Oracle Enterprise Manager System Monitoring Plug-inユーザーズ・ガイドfor Audit Vault and Database Firewall』を参照してください。

20 Oracle Data Redactionの使用

Oracle Data Redactionは、アプリケーションが発行する問合せから戻されるデータをマスクできる(リダクションできる)Oracle Databaseセキュリティ機能です。Enterprise Manager Cloud Control (Cloud Control)は、Oracle Data Redactionポリシーおよび形式を作成および管理するユーザー・インタフェースを提供します。これらのタスクは、図20-1に示す「データ・リダクション」ページを使用して実行できます。

図20-1 「データ・リダクション」ページ

Oracle Data Redactionの使用の詳細は、『Oracle Database Advanced Securityガイド』を参照してください。

21 Oracle Database Vaultおよび権限分析の管理

OracleDatabase Vaultは、強力なセキュリティ統制のための機能であり、データベース・アプリケーション・データを不正アクセスから守るとともに、プライバシおよび規制の要件を順守するのに役立ちます。Oracle Database Vaultを使用すると、統制によって特権アカウントによるデータベース・アプリケーション・データへのアクセスをブロックすることや、データベース内での要注意操作を統制することができます。Oracle Database Vault with Oracle Database 12cには、権限分析と呼ばれる機能が組み込まれており、データベース・アプリケーションおよび操作のセキュリティを向上させることができます。権限分析ポリシーでは、使用されている権限と使用されていない権限を特定することによってデータベース・アプリケーションの攻撃面を縮小し、操作のセキュリティを強化します。

Enterprise Manager Cloud Controlを使用して、Oracle Database Vaultおよび権限分析ポリシーを管理できます。これを実行する方法の詳細は、『Oracle Database Vault 管理者ガイド』を参照してください。

第VI部

ミドルウェアのプロビジョニング

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

- 第22章「Middlewareプロビジョニングの概要」

- 第23章「Fusion MiddlewareドメインおよびOracleホームのプロビジョニング」

- 第24章「SOAドメインおよびOracleホームのプロビジョニング」

- 第25章「Oracle Service BusドメインおよびOracleホームのプロビジョニング」

- 第26章「Oracle WebCenterドメインおよびOracleホームのプロビジョニング」

- 第27章「EM CLIを使用したMiddlewareプロビジョニング」

- 第28章「REST APIを使用したMiddlewareプロファイル」

- 第29章「Fusion Middlewareドメインのスケール・アップ/スケール・アウト」

- 第30章「Java EEアプリケーションのデプロイ/再デプロイ/アンデプロイ」

- 第31章「コヒーレンス・ノードおよびクラスタのプロビジョニング」

- 第32章「SOAアーティファクトおよびコンポジットのプロビジョニング」

- 第33章「Oracle Service Busリソースのプロビジョニング」

- 第34章「Oracle BPELプロセスのプロビジョニング」

- 第35章「Oracle Application Serverのプロビジョニング」

22 Middlewareプロビジョニングの概要

プロビジョニングでは、異なるプラットフォーム、環境および場所でのソフトウェア、アプリケーションまたはサーバーの、繰り返し可能で信頼性のある、無人の自動化されたスケジュール済一括デプロイメントを行います。

Middlewareプロビジョニングでは、自動デプロイメント・プロシージャを使用したOracleホームおよび構成ドメインのリモート・インストールを行います。デプロイメント・プロシージャは、Cloud Controlによって監視されている1つ以上のホストで一連の操作を実行することを目的とした、一連の事前定義された手順です。

この章の具体的な内容は次のとおりです。

- Middlewareプロビジョニングの概要

- Oracle Fusion Middlewareプロビジョニングの用語

- Middlewareプロビジョニング・プロシージャのサポートされるユースケース

22.1 Middlewareプロビジョニングの概要

プロビジョニングは、WebLogicドメイン、Java EEアプリケーション、コヒーレンス・ノードおよびクラスタ、SOAアーティファクトおよびコンポジット、Oracle Service Busリソース、Oracle BPELプロセス、Oracle Application ServerおよびOracle WebCenterなどのミドルウェア・アーティファクトのプロビジョニングを可能にするライフサイクル管理の一部として提供される重要なソリューションです。

次の図に、Cloud Controlにより提供されるMiddlewareプロビジョニング・ソリューションを示します。

Cloud Controlで効果的にこれらのデプロイメント・プロシージャおよびプロファイルを管理するため、プロファイルおよびデプロイメント・プロシージャの作成、表示およびプロビジョニングなどのMiddlewareプロビジョニングに関連するすべての機能を公開する集中型Middlewareプロビジョニング・ページがあります。このページにアクセスするには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」をクリックします。

ターゲット・ホームページからプロファイル・ページを起動できます。これには、「ターゲット」メニューから「ミドルウェア」を選択します。SOAドメインなどのドメイン・タイプのターゲットを選択します。「WebLogicドメイン」メニューから、「プロビジョニング」を選択します。このメニューのオプションを使用すると、WebLogicドメインまたはOracleホームに基づいてプロビジョニング・プロファイルを作成できます。

「Middlewareプロビジョニング」ページは、次のセクションに分類されます。

- プロファイル

- デプロイメント・プロシージャ

プロファイル

プロファイル・セクションには、作成したすべてのプロビジョニング・プロファイルとアクセスが付与されているプロファイルがリストされます。次の操作を実行できます。

- プロファイル詳細を表示するには、プロファイルをクリックします。

- 「プロファイル」表に表示する内容に基づいてプロファイルをフィルタします。これを実行するには、「表示」メニューからプロファイルの表示を選択し、表示するオプションをクリックします。たとえば、「すべて」をクリックした場合、すべてのプロファイルが表示されます。

- WebLogicドメインまたはOracleホームをクローニングするには、プロファイルを選択し、「プロビジョニング」をクリックします。

- 新規プロファイルを作成するには、「作成」メニューからオプションを選択します。

- 既存のプロファイルを削除するには、プロファイル名を選択して「削除」をクリックします。

デプロイメント・プロシージャ

デプロイメント・プロシージャ・セクションには、すべてのOracle提供のデプロイメント・プロシージャ、作成したカスタム・デプロイメント・プロシージャ(CDP)、(ログインした管理者に)アクセスが付与されているプロシージャがリストされます。リストからデプロイメント・プロシージャを選択し、デプロイメント・プロシージャに対して次のいずれかの操作を実行します。

- デプロイメント・プロシージャを実行するには、プロシージャを選択し、「起動」をクリックします。

- Oracle提供のデプロイメント・プロシージャのコピーを作成するには、「類似作成」をクリックします。

- ユーザーが所有するデプロイメント・プロシージャを削除するには、プロシージャを選択して「削除」をクリックします。Oracle提供のプロシージャを削除できないことに注意してください。

- デプロイメント・プロシージャを編集するには、プロシージャを選択して「編集」をクリックします。
注意: Oracleが提供するプロシージャを編集することはできません。プロシージャを編集するには、最初に「類似作成」オプションを使用して、Oracleが提供するプロシージャをクローニングする必要があります。これで、所有する、新しくクローニングしたプロシージャを編集できます。これを実行するには、「編集」をクリックします。

- 他の管理者に特定のデプロイメント・プロシージャのEM_PROVISIONING_OPERATORロールなどのアクセス権を付与するには、「権限の編集」をクリックします。

22.2 Oracle Fusion Middlewareプロビジョニングの用語

この項で一覧表示されている用語の定義は、この章で説明されているミドルウェアの概念の理解に役立ちます。

- WebLogicドメイン: WebLogicドメインは、Javaコンポーネントの論理的関係があるグループです。ドメインには、管理サーバーと呼ばれる特別なWebLogic Serverインスタンスが含まれます。これは、ドメイン内のすべてのリソースを構成、管理する中心ポイントです。通常、ドメインは、管理対象サーバーという追加のWebLogic Serverインスタンスを含めるように構成します。Webアプリケーション、EJB、Webサービスやその他のリソースなどのJavaコンポーネントを管理対象サーバーにデプロイし、構成および管理の目的にのみ管理サーバーを使用します。

- 管理サーバー: 管理サーバーは、ドメイン全体を構成するための集中管理エンティティとして動作します。ここにはドメインの構成ドキュメントが保持され、構成ドキュメントの変更がここから管理対象サーバーに配布されます。管理サーバーは、ドメイン内のすべてのリソースを監視できる中央の場所です。WebLogic Serverのドメインごとに、管理サーバーとして動作するサーバー・インスタンスが1つ必要です。

- 管理対象サーバー: 管理対象サーバーでは、ビジネス・アプリケーション、アプリケーション・コンポーネント、Webサービスおよびそれらに関係するリソースがホストされます。パフォーマンスを最適化するために、管理対象サーバーは、ドメインの構成およびセキュリティ・ドキュメントの読取り専用のコピーを維持します。管理対象サーバーが起動すると、ドメインの管理サーバーに接続して、その構成ドキュメントと管理サーバーに保持されているドキュメントが同期化されます。

- ノード・マネージャ: ノード・マネージャは、Oracle WebLogic Serverと別個のプロセスとして実行されるJavaユーティリティです。これにより、管理サーバーとの位置関係にかかわらず、管理対象サーバーの一般的な操作を実行できます。ノード・マネージャの使用はオプションですが、Oracle WebLogic Server環境で高可用性が必要なアプリケーションをホストする場合、メリットがあります。
管理対象サーバーをホストするコンピュータでノード・マネージャを実行する場合には、管理コンソール、Fusion Middleware Controlコンソールまたはコマンド行を使用して、管理対象サーバーをリモートで起動および停止できます。ノード・マネージャを使用して、予期しない障害が発生した後に、管理対象サーバーを自動的に再起動することもできます。

- WebLogic Serverホーム: WebLogic Serverホームには、WebLogic Serverをホストするために必要な、インストール済のファイルが含まれています。WebLogic Serverホームのディレクトリは、Oracleホームのディレクトリのピアで、ミドルウェア・ホームのディレクトリ構造の内部にあります。

- Middlewareホーム: Middlewareホームは、Oracle WebLogic Serverホーム、および必要に応じてOracle共通ホームと1つ以上のOracleホームのコンテナです。ミドルウェア・ホームは、ローカル・ファイル・システムに配置できますし、NFSを介してアクセス可能なリモート共有ディスクにも配置できます。

- Oracleホーム: Oracleホームには、特定の製品をホストするために必要な、インストール済のファイルが含まれています。たとえば、SOA Oracleホームには、Oracle SOA Suiteのバイナリとライブラリ・ファイルを含むディレクトリが配置されます。Oracleホームは、ミドルウェア・ホームのディレクトリ構造の内部にあります。

- クローニング: ドメイン内に存在するWebLogicドメイン・バイナリおよびOracleホーム・バイナリのコピーを作成するプロセスは、クローニングと呼ばれます。通常、クローニングはWebLogicドメインレベルで実行されます。Fusion Middlewareドメインのクローニングは、既存のターゲットから実行するか、プロビジョニング・プロファイルを使用して行います。

- プロビジョニング・プロファイル: プロファイルは、ライブWebLogicドメインまたはOracleホームのスナップショットですが、単に製品スイートに関する一連のインストール・メディア・アーカイブを含むだけの場合もあります。プロファイルは、Cloud ControlからまたはEnterprise Managerコマンドライン・インタフェースまたはREST APIを使用して作成できます。

- ゴールド・イメージ: ゴールド・イメージは、Oracleホームのバイナリおよびライブラリ・ファイルを含む単一のイメージです。
Oracle Fusion Middleware 11g,の場合、Middlewareホームは複数の製品固有のOracleホームを含む最上位ディレクトリでした。次に例を示します。

[user1@slc01avn middhome]$ ls
Oracle_OSB1  Oracle_SOA1  coherence_3.7  domain-registry.xml  logs  modules  oracle_common  osb  patch_ocp371  patch_wls1036  registry.dat  registry.xml  utils  wlserver_10.3

Oracle Fusion Middleware 12cの場合、Middlewareホームの概念がありません。OracleホームとしてのMiddlewareホーム自体の機能とSOA、OSB、WebCenterなどのミドルウェア製品が直接このフォルダ内にインストールされます。次に例を示します。

[user1@slc01avn OH12JRF]$ ls
OPatch  cfgtoollogs  crs  em   install    jdeveloper  ldap  mft      nls  oep  oraInst.loc    oracore  oui   plsql    rdbms    root.sh.old    root.sh.old.2  soa      srvm     wlserver
bin     coherence    css  has  inventory  jlib        lib   network  odi  ohs  oracle_common  osb      perl  precomp  root.sh  root.sh.old.1  slax           sqlplus  webgate  xdk

- スケール・アップ: ドメインまたはクラスタにすでに存在するホストに管理対象サーバーを追加またはクローニングする場合。

- スケール・アウト: ドメインまたはクラスタに存在していないホストに管理対象サーバーを追加またはクローニングする場合。

22.3 Middlewareプロビジョニング・プロシージャのサポートされるユースケース

この項では、ミドルウェア領域でサポートされるすべてのユースケースおよびプロビジョニング対象の対応するターゲットをリストします。

この項の具体的な内容は次のとおりです。

- ミドルウェア・ドメインおよびOracleホームのプロビジョニング

- WebLogic Serverドメイン、SOAドメイン、Oracle Service BusドメインおよびWebCenterドメインのスケーリング

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

- コヒーレンス・ノードおよびクラスタのプロビジョニング

- SOAアーティファクトのプロビジョニング

- Oracle Service Busリソースのプロビジョニング

- Oracle BPELプロセスのプロビジョニング

- Oracle Application Serverのプロビジョニング

22.3.1 ミドルウェア・ドメインおよびOracleホームのプロビジョニング

この表では、SOAドメイン、Oracle Service Bus (OSB)ドメイン、WebLogicドメイン、WebCenterドメインおよびOracleホームのデプロイに関するユースケースを示します。

表22-1 ミドルウェア・ドメインおよびOracleホームのプロビジョニング

デプロイメント・プロシージャ

ユースケース

プロビジョニングされるターゲット

リンク

Fusion Middlewareのプロビジョニング

- WebLogic Serverインストール・メディアに基づくプロファイル

- WebLogic Serverゴールド・イメージ・プロファイルに基づくプロファイル

- WebLogicドメイン・プロファイル

- 既存のWebLogic Serverミドルウェア・ホーム・プロファイル

WLS 12.1.x、10.3.x.

第23章

Fusion Middlewareのプロビジョニング

- SOAインストール・メディアに基づくプロファイル

- SOAゴールド・イメージに基づくプロファイル

- SOAドメイン・プロファイル

- 既存のSOAミドルウェア・ホーム

SOA Domain 11g, 12.1.3

第24章

Fusion Middlewareのプロビジョニング

- OSBインストール・メディアに基づくプロファイル

- OSBゴールド・イメージに基づくプロファイル

- OSBドメイン・プロファイル

- 既存のOSBミドルウェア・ホーム

OSB Domain 11g, 12.1.3

第25章

Fusion Middlewareのプロビジョニング

- WebCenterインストール・メディアに基づくプロファイル

- WebCenter Serverゴールド・イメージに基づくプロファイル

- WebCenterドメイン・プロファイル

- 既存のWebCenterホーム・プロファイル

Oracle WebCenter Portal - 11g

Oracle WebCenter Content - 11g

第26章

22.3.2 WebLogic Serverドメイン、SOAドメイン、Oracle Service BusドメインおよびWebCenterドメインのスケーリング

この表では、既存のSOAドメイン、Oracle Service Bus (OSB)ドメイン、WebLogicドメインのスケーリングに関連するユースケースを示します。

表22-2 SOAドメイン、OSBドメイン、WLSドメインおよびWebCenterドメインのスケーリング

デプロイメント・プロシージャ

ユースケース

プロビジョニングされるターゲット

リンク

WLSドメインのスケーリング

WLS 12.1.x、10.3.x.

29.3項

ミドルウェアのスケール・アップまたはスケール・アウト

SOAドメインのスケーリング

SOA Domain 11g

29.3項

OSBドメインのスケーリング

OSB Domain 11g

29.3項

WebCenterドメインのスケーリング

Oracle WebCenter Portal - 11g

Oracle WebCenter Content - 11g

29.3項

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

この表では、Java EEアプリケーションのデプロイ、アンデプロイおよび再デプロイに関連するユースケースを示します。

表22-3 Java EEアプリケーションのデプロイ、アンデプロイまたは再デプロイ

デプロイメント・プロシージャ

ユースケース

プロビジョニングされるターゲット

リンク

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

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

WebLogicバージョン10.3.1以上(12.1.1および12.1.2を含む)間でのJava EEアプリケーションのデプロイ。

30.6.1項

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

WebLogicバージョン10.3.1以上(12.1.1および12.1.2を含む)間でのJava EEアプリケーションのアンデプロイ。

30.6.3項

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

WebLogicバージョン10.3.1以上(12.1.1および12.1.2を含む)間でのJava EEアプリケーションの再デプロイ。

30.6.2項

22.3.4 コヒーレンス・ノードおよびクラスタのプロビジョニング

この表では、コヒーレンス・ノードを正常にデプロイするユースケースを示します。

表22-4 コヒーレンス・ノードおよびクラスタのプロビジョニング

デプロイメント・プロシージャ

ユースケース

プロビジョニングされるターゲット

リンク

コヒーレンス・ノードのプロビジョニング

コヒーレンス・ノードおよびクラスタのデプロイ

Oracle Coherence 3.5、3.6および3.7。

Oracle Coherence 12.1.2スタンドアロン・バージョン。

31.3.3項

22.3.5 SOAアーティファクトのプロビジョニング

この表では、様々なSOAアーティファクトを正常にデプロイするユースケースを示します。

表22-5 SOAアーティファクトのプロビジョニング

デプロイメント・プロシージャ

ユースケース

プロビジョニングされるターゲット

リンク

SOAアーティファクトのプロビジョニング

参照インストールからのSOAアーティファクトのプロビジョニング

Oracle SOA Suite 11gR1 (11.1.1.2.0から11.1.1.7.0)。

- SOAコンポジット

- Oracle WebLogic Serverポリシー

- アサーション・テンプレート

- JPSポリシーおよび資格証明ストア

- ヒューマン・ワークフロー

- Oracle B2B

32.4.1項

ゴールド・イメージからのSOAアーティファクトのプロビジョニング

Oracle SOA Suite 11gR1 (11.1.1.2.0から11.1.1.7.0)。

- SOAコンポジット

- Oracle WebLogic Serverポリシー

- アサーション・テンプレート

- JPSポリシーおよび資格証明ストア

- ヒューマン・ワークフロー

- Oracle B2B

32.4.2項

SOAコンポジットのデプロイ

SOAコンポジットのプロビジョニング

Oracle SOA Suite 11gR1 (11.1.1.2.0から11.1.1.7.0)

SOAコンポジット

第32.5項

22.3.6 Oracle Service Busリソースのプロビジョニング

この表では、OSBリソースを正常にデプロイするユースケースを示します。

表22-6 Oracle Service Busリソースのプロビジョニング

デプロイメント・プロシージャ

ユースケース

プロビジョニングされるターゲット

リンク

Oracle Service Busリソース・プロビジョニング

OSBドメインからのOSBリソースのプロビジョニング

Oracle Service Bus 2.6.0 - 2.6.1, 3.0.0, 10.3.0.0 - 10.3.1.0, 11.1.1.3.0 - 11.1.1.7.0, 12.1.3.0.0

33.3項

ソフトウェア・ライブラリからのOSBリソースのプロビジョニング

Oracle Service Bus 2.6.0 - 2.6.1, 3.0.0, 10.3.0.0 - 10.3.1.0, 11.1.1.3.0 - 11.1.1.7.0, 12.1.3.0.0

33.5項

22.3.7 Oracle BPELプロセスのプロビジョニング

この表では、BPELリソースを正常にデプロイするユースケースを示します。

表22-7 Oracle BPELプロセスのプロビジョニング

デプロイメント・プロシージャ

ユースケース

プロビジョニングされるターゲット

リンク

BPELプロセスのプロビジョニング

BPELプロセスのプロビジョニング

Oracle BPEL Process Manager 10.1.3.1、10.1.3.3および10.1.3.4のBPELプロセス。

第34.3項

22.3.8 Oracle Application Serverのプロビジョニング

この表では、Oracle Application Serverを正常にデプロイするユースケースおよびプロビジョニングできる様々なターゲットを示します。

表22-8 Oracle Application Serverのプロビジョニング

デプロイメント・プロシージャ

ユースケース

プロビジョニングされるターゲット

リンク

Application Server Deployment 10.1.3

Application Server 10.1.3.xのプロビジョニング

Oracle Application Server 10gリリース3 (10.1.3.4および10.1.3.5)

デプロイされるコア・コンポーネント。

- アプリケーション層

- Web層

35.3項

Application Server Deployment 10.1.3.xSOA3

Application Server 10.1.3.xとSOA Suite 10.1.3.xをともにプロビジョニング

Oracle SOA Suite 10g (10.1.3.x)は、Oracle Application Server 10gリリース3 (10.1.3.4および10.1.3.5)のアプリケーション層およびWeb層とともにデプロイされます。

35.4項

23 Fusion MiddlewareドメインおよびOracleホームのプロビジョニング

プロビジョニングは、Enterprise Management Cloud Controlによるライフサイクル管理の一部として提供されるソリューションです。Middlewareプロビジョニング・ソリューションの一部として、Cloud Controlを使用すると、Oracle WebLogicドメイン(WebLogicドメイン)、サービス指向アーキテクチャ(SOA)、Oracle Service Bus (OSB)およびOracle WebCenterをプロビジョニングできます。ドメインをプロビジョニングする以外にも、既存のドメインを拡張して新しいOracleホームを含めることができます。ミドルウェア・エンティティをプロビジョニングするため、プロファイルを作成して保存し、保存されたプロファイルをプロビジョニングのソースとして使用できます。これを行うことで、以降のインストールでも標準の一貫した構成に準拠することができます。

注意:
Middlewareホームという用語は、WebLogic Serverバージョン10.3.xおよび12.1.xにのみ適用されます。WebLogic Serverバージョン12.1.2.0.0以降、MiddlewareホームはOracleホームと呼ばれます。
新しいMiddlewareドメインまたはOracleホームをプロビジョニングするには、JDKバージョン1.6以上を構成しておく必要があります。製品の最新かつ最上位のJDKバージョンを使用することをお薦めします。そのためには、support.oracle.comにログインして、「動作保証」タブをクリックします。「動作保証検索」セクションで、「製品」フィールドにOracle WebLogic Serverと入力します。「リリース」メニューから有効なWebLogic Serverバージョンを選択し、「プラットフォーム」メニューから有効なオペレーティング・システムを選択して、「検索」をクリックします。

既存のドメインをクローニングするには、クローニングされる宛先ホストで構成されているJDKバージョンがソース・ホストで使用可能なJDKバージョン以上であることを確認する必要があります。製品の最新かつ最上位のJDKバージョンを使用することをお薦めします。そのためには、support.oracle.comにログインして、「動作保証」タブをクリックします。「動作保証検索」セクションで、「製品」フィールドにOracle WebLogic Serverと入力します。「リリース」メニューから有効なWebLogic Serverバージョンを選択し、「プラットフォーム」メニューから有効なオペレーティング・システムを選択して、「検索」をクリックします。

この章では、Oracle Enterprise Manager Cloud Controlを使用してミドルウェア・ホームおよびWebLogicドメインの一般的なプロビジョニング操作を自動的に行う方法について説明します。この章の具体的な内容は次のとおりです。

- Fusion Middlewareプロビジョニングの概要

- Fusion Middlewareのプロビジョニング・デプロイメント・プロシージャ起動の別の方法

- Middlewareプロビジョニングの手順概要

- Middlewareプロビジョニング・プロファイルからプロビジョニングするための前提条件

- Middlewareプロビジョニング・プロファイルの作成

- インストール・メディアに基づくプロファイルまたはOracleホームに基づくプロファイルからの新しいFusion Middlewareドメインのプロビジョニング

- 既存のOracleホームからのFusion Middlewareドメインのプロビジョニング

- 既存のWebLogicドメインに基づくプロファイルからのクローニング

23.1 Fusion Middlewareプロビジョニングの概要

この項では、Fusion Middlewareデプロイメント・プロシージャを使用してWebLogicドメインおよびミドルウェア・ホームのプロビジョニングに関連する手順の概要を示します。

表23-1 Fusion Middlewareプロビジョニングの概要

ステップ

説明

参照リンク

手順1

Fusion Middlewareデプロイメント・プロシージャ起動の別の方法

Middlewareエンティティをプロビジョニングするために使用されるFusion Middlewareデプロイメント・プロシージャを起動する様々な方法の理解

デプロイメント・プロシージャを起動する方法については、第23.2項を参照してください。

手順2

Middlewareプロビジョニング・プロファイルの作成

この章では、プロビジョニング・プロファイルの3つのタイプを示します。ご自身の要件に最適なプロファイルを選択してください

様々なプロビジョニング・プロファイルの詳細は、第23.5項を参照してください

手順3

ミドルウェア・プロファイルをプロビジョニングするための前提条件

Fusion Middlewareデプロイメント・プロシージャを実行する前に、満たす必要があるいくつかの前提条件があります。

インストール・メディア/Oracleホーム・プロファイルをプロビジョニングするための前提条件の詳細は、第23.4.1項を参照してください

WebLogicドメイン・プロファイルをプロビジョニングするための前提条件の詳細は、第23.4.2項を参照してください。

手順4

Fusion Middlewareデプロイメント・プロシージャの実行

このデプロイメント・プロシージャを実行して、WeblogicドメインまたはOracleホームあるいはその両方を正常にプロビジョニングします。

インストール・メディア・プロファイルまたはOracleホーム・プロファイルからのプロビジョニングの詳細は、第23.6項を参照してください

WebLogicドメイン・プロファイルのプロビジョニングの詳細は、第23.7項を参照してください

既存のホームからプロビジョニングするには、第23.8項を参照してください

23.2 Fusion Middlewareのプロビジョニング・デプロイメント・プロシージャ起動の別の方法

ミドルウェア・プロビジョニング・デプロイメント・プロシージャを起動するには次のいずれかの方法を使用できます。

- (推奨オプション) すべての即時利用可能なデプロイメント・プロシージャに対して、「プロファイル」表からFusion Middlewareのプロビジョニング・プロシージャを起動してください。これを行うには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」をクリックします。Middlewareプロビジョニング・ページで、「プロファイル」表からプロファイルを選択し、「プロビジョニング」をクリックします。

- 既存のミドルウェア・ホームから新規ドメインをプロビジョニングしている場合、またはカスタマイズされたデプロイメント・プロシージャを使用している場合、「Fusion Middlewareのプロビジョニング」デプロイメント・プロシージャを直接実行できます。これを行うには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」をクリックします。Middlewareプロビジョニング・ページで、「デプロイメント・プロシージャ」表から「Fusion Middlewareのプロビジョニング」をクリックします。

- コマンドラインを使用してプロビジョニングのプロセスを自動化するには、Enterprise Managerコマンドライン・インタフェース(EMCLI)・ユーティリティを使用してプロシージャを発行します。EMCLIにより、各種オペレーティング・システムのテキスト・ベースのコンソール(シェルおよびコマンド・ウィンドウ)からEnterprise Manager Cloud Control機能にアクセスできます。Enterprise Manager機能は、SQL*Plus、OSのシェル、Perl、Tclなどのカスタム・スクリプトを使用して呼び出すことができるため、社内のビジネス・プロセスとの統合も容易です。

注意:
関連するEM CLI動詞の詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。

23.3 Middlewareプロビジョニングの手順概要

通常、プロビジョニングに対して、プロファイルを作成し、新しいWebLogicドメインおよびOracleホームを作成するソースとしてプロファイルを使用する必要があります。プロファイルを使用することで、以降のインストールでも標準の一貫した構成に準拠することができます。さらに、フレッシュ・インストールがサポートされますが、これはユーザーがインストール・メディアからプロファイルを作成し、「Fusion Middlewareのプロビジョニング」デプロイメント・プロシージャを実行して、このプロファイルをプロビジョニングできることを意味します。この場合、OracleホームまたはWebLogicドメインはあらかじめ手動でインストール/構成されている必要がなく、Enterprise Manager Cloudコンソールによって検出されている必要はありません。

Middlewareプロビジョニングは、2段階のプロセスです。

- ステップ1: プロファイルの作成

- ステップ2: プロファイルをプロビジョニングするFusion Middlewareのプロビジョニング・プロシージャの実行

23.3.1 ステップ1: プロファイルの作成

プロファイルは、ソフトウェア・ライブラリに作成および内部に格納されるテンプレートです。プロファイルが作成されたら、同じ特徴を持つWebLogicドメインおよび/またはOracleホームをプロビジョニングするために何度も起動できます。

プロファイルの作成に進む前に、要件に適したプロファイルを識別する必要があります。

- 既存のWebLogicドメインまたはOracleホームがない場合、インストール・メディア・プロファイルを使用します。このプロファイルにより、OTNからダウンロードしたshiphome (インストール・メディア・ファイル)を使用してドメインおよびホームを作成できます。詳細は、第23.5.1項を参照してください。

- バグを修正するためにパッチを適用する必要があるOracleホームがある場合、Oracleホーム・プロファイルを使用します。このプロファイルにより、Oracleホームに関連パッチを適用し、真のソースである可能性があるパッチを適用したOracleホームからプロファイルを作成できます。パッチを適用したプロファイルを使用して、データ・センターのすべてのOracleホームをプロビジョニングします。詳細は、第23.5.2項を参照してください。

- クローニングする既存のWeblogicドメインがある場合、WebLogicドメイン・プロファイルを使用します。このプロファイルにより、ソース・ドメインのコピーを作成できます。詳細は、第23.5.3項を参照してください。

23.3.2 ステップ2: プロファイルをプロビジョニングするFusion Middlewareのプロビジョニング・プロシージャの実行

デプロイメント・プロシージャは、Cloud Controlによって監視されている1つ以上のホストで一連の操作を実行することを目的とした、一連の事前定義された手順です。すでに作成したプロファイルを使用して、ドメインまたはOracleホームをプロビジョニングできます。この項では、プロファイルをプロビジョニングする様々な方法について説明します。特に、次の内容について説明します。

注意:
プロビジョニング・プロシージャに進む前に前提条件を満たしてください。前提条件の詳細なリストは、第23.4項を参照してください。
Fusion Middlewareプロシージャを起動する他の方法の詳細は、第23.2項を参照してください。

- インストール・メディア・プロファイルまたはOracleホーム・プロファイルからの新しいドメインのプロビジョニング。第23.6項を参照してください。

- 既存のOracleホームからの新しいドメインのプロビジョニング。第23.7項を参照してください

- 既存のドメインのクローニング。第23.8項を参照してください。

23.4 Middlewareプロビジョニング・プロファイルからプロビジョニングするための前提条件

この項では、Fusion Middlewareのプロビジョニング・デプロイメント・プロシージャを実際に起動する前に満たすすべての前提条件について説明します。特に、次の内容について説明します。

重要:
ドメイン・プロファイルまたはOracleホーム・プロファイルを使用してプロビジョニングする前に、次のパッチを適用する必要があります。

- SOAの場合: 20046866、20046898

- OSBの場合: 20046866

既存のMiddlewareホームを使用してドメイン・プロファイルからプロビジョニングする場合、Middlewareホームが適切にパッチ適用されていることを確認してください。

- インストール・メディア・プロファイルまたはOracleホーム・プロファイルをプロビジョニングするための前提条件

- WebLogicドメイン・プロファイルをプロビジョニングするための前提条件

注意:
第2章に記載されている基本前提条件を満たすこと。この章では、付与されている権限およびアクセス権に基づいた前提条件について説明します。

23.4.1 インストール・メディア・プロファイルまたはOracleホーム・プロファイルをプロビジョニングするための前提条件

次の前提条件を満たします。

- Cloud Control全体のエンティティをステージングおよびプロビジョニングするために使用される一時ディレクトリである作業ディレクトリの書込み権限。
作業ディレクトリが指定されていない場合、管理エージェントの作業ディレクトリが使用され、それに対する書込み権限が必要になります。

- Oracleホーム・ディレクトリでの次の権限。

1. 書込み(新規Oracleホームを作成する必要がある場合)。インストール・メディア・プロファイルの場合、新しいOracleホームの作成は必須です。

2. 読取り(既存のOracleホームを使用している場合)。これはOracleホーム・プロファイルにのみ適用可能で、インストール・メディア・プロファイルには適用不可です。

- 共有ストレージを使用している場合、すべてのホスト上のドライブ/ディレクトリを事前にマウントします。

- プロビジョニング操作に含まれるすべてのホストを、Enterprise Managerでターゲットとして監視する必要があります。

- サーバーおよびノード・マネージャのポートは空いている必要があります。

- ドメインでデータベース、LDAPまたはOracle HTTP Serverが使用される場合、サーバーがEnterprise Managerでターゲットとしてそれぞれ監視されていることを確認してください。

- ドメイン/アプリケーション/ノード・マネージャ・ディレクトリでの書込み権限。

23.4.2 WebLogicドメイン・プロファイルをプロビジョニングするための前提条件

第23.4.1項の要件に加えて、WebLogicドメイン・プロファイルを使用してクローニングするには、次の項目も満たす必要があります。

- 既存のFusion Middlewareドメインをクローニングする前に、スキーマのデータとソース・データベースを同期化するためにソース・データベースをクローニングする必要があります。ソース・データベースをまだクローニングしていない場合、Enterprise Manager Cloud Controlで使用できるデータベースのクローニング機能を使用して実行できます。データベースのクローニングの詳細は、第14章を参照してください。

注意:
ドメインをクローニングする前に、データベースで次のデータ修正SQLスクリプトを実行します。
SOAの場合

汎用コンポーネントを作成し、truncate_soa_oracle.sqlスクリプトをソフトウェア・ライブラリにアップロードします。汎用コンポーネントの作成の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。切捨てスクリプト(truncate_soa_oracle.sql)がSOAインストールの/MW_HOME/SOA_ORACLE_HOME/rcu/integration/soainfra/sql/truncateディレクトリにあることに注意してください。

OSBの場合

汎用コンポーネントを作成し、llr_table.sqlスクリプトをソフトウェア・ライブラリにアップロードします。このスクリプトを作成するには、OSBドメインに存在する各サーバーに対して、SQLスクリプトに次の文を追加する必要があります。

DROP table WL_LLR_<SERVER_NAME>

たとえば、OSBドメインに管理サーバーとOSB_SERVER1およびOSB_SERVER2という名前の2つの管理対象サーバーがある場合、SQLスクリプトの内容は次のようになります。

DROP table WL_LLR_ADMINSERVER

DROP table WL_LLR_OSB_SERVER1

DROP table WL_LLR_OSB_SERVER2

- ソース・ドメインがLDAPにワイヤリングされていた場合、既存のFusion Middlewareドメインをクローニングする前に、データ(ユーザー、ロールおよびポリシー)がソースLDAPから新規LDAPに移行されており、新規LDAPがEnterprise Managerでターゲットとして検出されていることを確認してください。

23.4.3 ソフトウェア・ライブラリに格納されているカスタム・スクリプトの使用

この項では、デプロイメント・プロシージャをカスタマイズするためにソフトウェア・ライブラリで使用できるカスタム・スクリプトを使用する方法について説明します。この項の具体的な内容は次のとおりです。

- 入力パラメータを含むカスタム・スクリプトの使用

- 入力パラメータを含まないカスタム・スクリプトの使用

23.4.3.1 入力パラメータを含むカスタム・スクリプトの使用

Fusion Middlewareのプロビジョニング・プロシージャの一部としてカスタム・スクリプトを使用する場合は、これらのスクリプトをディレクティブとしてソフトウェア・ライブラリに格納していることを確認する必要があります。

入力パラメータを含むカスタム・スクリプトをソフトウェア・ライブラリに格納するには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

2. Directiveというフォルダを作成します。

3. ソフトウェア・ライブラリ・ページで、「アクション」メニューから「エンティティの作成」を選択し「ディレクティブ」をクリックします。

4. 説明ページで、親フォルダに一意の名前を指定します。たとえば、My Custom Script With Parametersなどです。「次へ」をクリックします。

5. 構成ページの「コマンドライン引数」セクションで、「追加」をクリックします。

6. 「コマンドライン引数の追加」ダイアログ・ボックスでプロパティ名INPUT_FILEを入力し、「OK」をクリックします。コマンドラインに値: "${INPUT_FILE}"が含まれていることを確認します。

7. ファイルの選択ページで「ファイルのアップロード」を選択します。「宛先の指定」セクションで、アップロード場所を選択します。「ソースの指定」セクションで、アップロードするスクリプトを選択します。直接実行可能ファイルが「メイン・ファイル」メニューにあることを確認します。
たとえば、myscript.plはメインの実行可能ファイルで、listMyServers.pyはアップロードされる別のファイルです。参照できるスクリプトの例を次に示します。

Perlスクリプトの内容: myscript.pl

#!/usr/local/bin/perl

print "**********************\n";
print "*     This is a      *\n";
print "*    test script     *\n";
print "**********************\n";

my $inputFile = $ARGV[0];
my %properties;
open (FILE, "<$inputFile") or die "can't open $inputFile for reading: $!";
print "Input properties:\n";
while (<FILE>)
{
chomp;
my ($key, $val) = split /=/;
$properties{$key} = $val;
print "\t$key=$val\n";
}
close FILE;

my $mwHome = $properties{MIDDLEWARE_HOME};
my $protocol = $properties{ADMIN_PROTOCOL};
my $host =$properties{ADMIN_SERVER_LISTEN_ADDRESS};
my $port = $properties{ADMIN_SERVER_LISTEN_PORT};
my $cmd = $mwHome."/wlserver_10.3/common/bin/wlst.sh listMyServers.py $protocol $host $port";

print "\nExecuting:\n\t$cmd\n";
print "\nOutput is:\n\n";

system($cmd);

exit 0;

Pythonスクリプトの内容: listMyServers.py

#!/usr/bin/python

protocol = sys.argv[1];
host = sys.argv[2];
port = sys.argv[3];
username = 'weblogic';
password = 'welcome1';

connectUrl = protocol + '://' + host + ':' + port;

connect(username, password, connectUrl);
cd('/Servers');
ls();
disconnect();
exit();

「次へ」をクリックします。

8. 確認ページで、詳細を確認し「保存とアップロード」をクリックします。

23.4.3.2 入力パラメータを含まないカスタム・スクリプトの使用

Fusion Middlewareのプロビジョニング・プロシージャの一部としてカスタム・スクリプトを使用する場合は、これらのスクリプトをディレクティブとしてソフトウェア・ライブラリに格納していることを確認する必要があります。

入力パラメータを含まないカスタム・スクリプトをソフトウェア・ライブラリに格納するには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

2. Directiveというフォルダを作成します。

3. ソフトウェア・ライブラリ・ページで、「アクション」メニューから「エンティティの作成」を選択し「ディレクティブ」をクリックします。

4. 説明ページで、親フォルダに一意の名前を指定します。たとえば、My Custom Script Without Parametersなどです。「次へ」をクリックします。

5. 構成ページの「コマンドライン引数」セクションで、「次へ」をクリックします。

6. ファイルの選択ページで「ファイルのアップロード」を選択します。「宛先の指定」セクションで、アップロード場所を選択します。「ソースの指定」セクションで、アップロードするスクリプトを選択します。直接実行可能ファイルが「メイン・ファイル」メニューにあることを確認します。
たとえば、myscript1.plはメインの実行可能ファイルで、listMyServers.pyはアップロードされる別のファイルです。参照できるスクリプトの例を次に示します。

Perlスクリプトの内容: myscript1.pl

#!/usr/local/bin/perl

print "**********************\n";
print "*     This is a      *\n";
print "*    test script     *\n";
print "**********************\n";

my $mwHome = "/scratch/bbanthia/soa/middleware";
my $protocol = "t3";
my $host = "slc01mpj.us.example.com";
my $port = "7001";
my $cmd = $mwHome."/wlserver_10.3/common/bin/wlst.sh listMyServers.py $protocol $host $port";

print "Executing:\n\t$cmd\n";
print "\nOutput is:\n\n";

system($cmd);

exit 0;

Pythonスクリプトの内容: listMyServers.py

#!/usr/bin/python

protocol = sys.argv[1];
host = sys.argv[2];
port = sys.argv[3];
username = 'weblogic';
password = 'welcome1';

connectUrl = protocol + '://' + host + ':' + port;

connect(username, password, connectUrl);
cd('/Servers');
ls();
disconnect();
exit();

「次へ」をクリックします。

7. 確認ページで、詳細を確認し「保存とアップロード」をクリックします。

23.5 Middlewareプロビジョニング・プロファイルの作成

プロファイルは、ソフトウェア・ライブラリで作成および格納できるテンプレートに似ています。プロファイルが作成されたら、WebLogicドメインおよび/またはOracleホームをプロビジョニングするために何度も起動できます。プロファイルを使用するメリットは、将来のWebLogicインストールを一貫性のある標準構成に確実に準拠させることができる点です。

- インストール・メディアに基づくプロビジョニング・プロファイルの作成

- Oracleホームに基づくプロビジョニング・プロファイルの作成

- WebLogicドメインに基づくプロビジョニング・プロファイルの作成

23.5.1 インストール・メディアに基づくプロビジョニング・プロファイルの作成

リモート・ホストからインストール・メディアをアップロードし、選択したインストール・メディアに基づいてプロファイルを作成し、Middlewareプロビジョニング・ページからこのプロファイルをプロビジョニングできます。

Middlewareプロビジョニング・プロファイルの作成を開始する前に、次の前提条件を満たしていることを確認します。

- Oracle Technology Networkからインストール・メディア・ファイルをダウンロードします。

- SOA、OSB、WebCenter、RCUおよびWLSなどの各製品に対して1つのディレクトリを作成し、各ディレクトリの下に必要なファイルを追加していることを確認します。

インストール・メディア・プロファイルを作成するには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」を選択します。

2. Middlewareプロビジョニング・ホームページの「プロファイル」セクションで、「作成」メニューから「インストール・メディアから」を選択します。

3. Fusion Middlewareのプロビジョニング・プロファイルの作成ページで、プロファイルの一意の名前と説明を入力します。
デフォルトでは、すべてのプロファイルはソフトウェア・ライブラリで「Fusion Middlewareプロビジョニング/プロファイル」ディレクトリの下に一元的に配置されています。

4. 「製品詳細」セクションで、「製品」メニューから「Oracle WebLogic Server」または「Oracle SOA Suite」を選択します。選択したオプションに応じて、「プラットフォーム」およびバージョンメニューが更新されます。リストから適切なプラットフォーム名とバージョンを選択します。

5. 「ファイル」セクションで、次の手順を実行します。

1. 検索アイコンをクリックし、ホストを検索します。「ターゲットの選択」ダイアログ・ボックスで、インストール・メディア・ファイルがあるターゲットを検索および選択し、「選択」をクリックします。

2. リモート・ホスト上のファイルにアクセスするには、ホスト資格証明を指定する必要があります。これを行うには、検索をクリックし、「資格証明の選択」ダイアログ・ボックスで必要な資格証明を入力し、「OK」をクリックします。選択したターゲットに対してこれらの資格証明を検証するには、「テスト」をクリックします。

3. 選択した製品に基づいて、「ファイル」表が更新されます。次のオプションの1つが使用可能です。
「製品」メニューから「Oracle SOA Suite」を選択する場合、Oracle WebLogic Server、Oracle SOA、Oracle Service BusおよびOracle RCUファイルをアップロードできます。

ファイルを実際にアップロードする前に、前提条件として次の手順を実行する必要があります。

- Oracle Technology Networkからソフトウェア・バイナリ(インストール・メディア・ファイル)をダウンロードします。

- SOA、OSB、RCUおよびWLSなどの各製品に対して1つのディレクトリをソフトウェア・ライブラリに作成し、各ディレクトリの下に必要なファイルを追加していることを確認します。

ファイルを追加するには、「ファイル」表から製品名を選択し、「フォルダの選択」をクリックします。ファイルが存在するディレクトリに移動し、「OK」をクリックします。ファイルを削除するには、製品タイプを選択し、「削除」をクリックします。

「製品」メニューから「Oracle WebLogic Server」を選択した場合、Oracle WebLogic Serverファイルのみをアップロードする必要があります。これを行うには、「ファイル」表からOracle WebLogic Serverを選択し、「フォルダの選択」をクリックします。ファイルが存在するディレクトリに移動し、「OK」をクリックします。このファイルを削除するには、製品名を選択し、「削除」をクリックします。

注意:
各製品には、各フォルダ内で使用可能でなければならない必須インストール・ファイルがあり、これらが存在しない場合、インストール・メディア・プロファイルの作成が失敗します。
次の例では、Oracle WebLogic Serverはフォルダ名であり、wls1036_generic.jarはインストール・メディア・ファイルです。同様に、Oracle SOA、Oracle Service Bus、Oracle WebCenterおよびOracle RCUに必要なインストール・メディア・ファイルがリストされています。

- Oracle WebLogic Server: wls1036_generic.jar

- Oracle SOA: soa1.zip、soa2.zip、soa3.zip、soa4.zip、soa5.zipおよびsoa6.zip

- Oracle Service Bus: osb.zip

- Oracle RCU: rcuHome.zip

- Oracle WebCenter Portal: wc.zip

- Oracle WebCenter Content: ecm1.zip, ecm2.zip

これは単なる例であり、jarファイル名は選択したプラットフォームおよびバージョンによって変更される可能性があります。

6. 「記憶域」セクションで、「ソフトウェア・ライブラリ・ストレージ」の詳細を選択します。有効なストレージ・タイプおよびアップロードの場所を指定してインストール・メディア・プロファイルをアップロードしていることを確認してください。

7. 「作成」をクリックし、プロファイル作成ジョブを発行します。

8. ジョブが正常に実行されると、新しいエントリが「プロファイル」表で使用可能になります。プロファイル名をクリックすると、詳細を表示できます。

23.5.2 Oracleホームに基づくプロビジョニング・プロファイルの作成

このページを使用して、新規Oracleホーム・プロファイルを作成し、ソフトウェア・ライブラリに保存して、保存したプロファイルを、新規Oracleホームをプロビジョニングするためのソースとして使用します。

Middlewareプロビジョニング・プロファイルの作成を開始する前に、次の前提条件を満たしていることを確認します。

- Oracleホームは、Enterprise Manager Cloud Controlで検出された管理対象ターゲットである必要があります。

- Oracleホーム対する読取り権限を持っていることを確認します。

- 管理エージェントの作業ディレクトリ対する書込み権限を持っていることを確認します。作業ディレクトリは、Cloud Control全体のエンティティをステージングおよびプロビジョニングするために使用される一時ディレクトリです。

- 管理サーバーで管理エージェントが実行されている必要があります。

- 管理サーバーが稼働しているソース・マシンでホスト資格証明が設定されている必要があります。

- ゴールド・イメージの作成に必要なディスク領域は、次の式で計算されます。
ディスク領域 = ミドルウェア・ホームのサイズ + 一時スクリプト用の領域

ミドルウェア・ホーム・プロファイルを作成するには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」を選択します。

2. Middlewareプロビジョニング・ホームページの「プロファイル」セクションで、「作成」メニューから「Oracleホームから」を選択します。

3. Fusion Middlewareのプロビジョニング・プロファイルの作成ページで、プロファイルの一意の名前と説明を入力します。
デフォルトでは、すべてのプロファイルはソフトウェア・ライブラリで「Fusion Middlewareプロビジョニング/プロファイル」ディレクトリの下に一元的に配置されています。

4. 「参照ターゲット」セクションで、検索アイコンをクリックします。「ターゲットの選択」ダイアログ・ボックスで、Oracleホームを選択し、「選択」をクリックします。対応するホスト詳細が移入されます。
ミドルウェア・ターゲット・ページからミドルウェア・ホーム・プロファイルの作成を起動することもできます。次に手順を示します。これを行う場合、ターゲットのコンテキストが保持され、「タイプ」、「名前」、「ホスト」などのフィールドが事前移入されて表示されます。

5. 検索アイコンをクリックし、資格証明を指定します。「資格証明の選択」ダイアログ・ボックスで、すでに設定されているターゲットに必要な資格証明を指定し、「OK」をクリックします。選択したターゲットに対して資格証明を検証するには、「テスト」をクリックします。

6. 「記憶域」セクションで、「ソフトウェア・ライブラリ・ストレージ」の詳細を選択します。有効なストレージ・タイプおよびアップロードの場所の詳細を指定してOracleホーム・プロファイルを更新していることを確認してください。

7. 「プロファイルの作成」をクリックし、プロファイル作成ジョブを発行します。

8. ジョブが正常に実行されると、新しいエントリが「プロファイル」表で使用可能になります。プロファイル名をクリックすると、詳細を表示できます。

23.5.3 WebLogicドメインに基づくプロビジョニング・プロファイルの作成

プロファイルを作成し、それをソフトウェア・ライブラリに保存し、保存済のプロファイルを新規WebLogicドメインを作成するためのソースとして使用するには、このページを使用します。これにより、以降のWebLogicのインストールは、標準的で一貫性のある構成に従っていることが保証されます。

Middlewareプロビジョニング・プロファイルの作成を開始する前に、次の前提条件を満たしていることを確認します。

- 管理サーバーで管理エージェントが実行されている必要があります。

- 管理サーバーが稼働しているソース・マシンでホスト資格証明が設定されている必要があります。

- プロファイルを作成するWebLogicドメインが、Cloud Controlでの監視対象ターゲットである必要があります。

- プロファイルの作成に必要なディスク領域は、次の式で計算されます。
ディスク領域 = ミドルウェア・ホームのサイズ + WebLogicドメインのサイズ + 一時スクリプトの領域(約1GB)

WebLogicドメインのプロファイルを作成するには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」を選択します。

2. Middlewareプロビジョニング・ホームページの「プロファイル」セクションで、「作成」メニューから「WebLogicドメインから」を選択します。

3. Fusion Middlewareのプロビジョニング・プロファイルの作成ページの「プロファイル詳細」セクションで、プロファイルの一意の名前と説明を入力します。デフォルトでは、すべてのプロファイルはソフトウェア・ライブラリで「Fusion Middlewareプロビジョニング/プロファイル」ディレクトリの下に一元的に配置されています。

4. 「参照ターゲット」セクションで、WebLogicドメイン・ターゲットを検索および選択します。ターゲットを選択したら、ドメイン・ホーム、ホストおよびホストのOracleホーム詳細が移入されます。
WebLogicドメインの場合データベース・インスタンスがWebLogicドメインに関連付けられていることを確認する必要があります(これが不要な可能性があるプレーンWebLogicドメインの場合を除く)。データベースをドメインに関連付けるには、データベース・プロビジョニング・プロファイルの作成ウィザードを使用して、データベース・プロファイルを作成します。詳細。

選択したホスト・ターゲットへのログインに必要なOracleホーム資格証明を入力します。

ドメインのWebLogic管理者の既存の名前付き資格証明を入力するか、詳細を入力して新しい名前付き資格証明を作成します。

注意: ミドルウェア・ターゲット・ページからWebLogicドメイン・プロファイルを起動することもできます。これを行う場合、ターゲットのコンテキストが保持され、「タイプ」、「名前」、「ホスト」および「Oracleホーム」などのフィールドの詳細が事前移入されて表示されます。

5. ターゲットの選択に基づいて、次のいずれかのプロファイルを作成できます。

1. プレーンWebLogicドメイン・プロファイル: Oracleホーム・ファイルをアップロードしない場合、「参照ターゲット」セクションで使用できる「Oracleホームを含む」チェックボックスの選択を解除します。これを実行する場合、このドメイン・プロファイルからプロビジョニング中に、宛先にすでに存在する事前にデプロイしたOracleホームが必要です。Oracleホームの内容は、ドメイン・プロファイルで予期された内容と一致する必要があります。

2. WebLogicドメイン・プロファイル: 「ミドルウェア・ホームを含む」のデフォルトの選択を保持する場合、WebLogicドメインがドメイン構成、ミドルウェア・ホームおよびバイナリとともに作成されます。
資格証明を指定するには、検索アイコンをクリックします。「資格証明の選択」ダイアログ・ボックスで、すでに設定されている資格証明を選択し、「OK」をクリックします。選択したターゲットに対して資格証明を検証するには、「テスト」をクリックします。

6. 「ソフトウェア・ライブラリのアップロード場所」セクションで、ソフトウェア・ライブラリ・ストレージの詳細を選択します。有効なストレージ・タイプおよびアップロードの場所を指定してプロファイルを更新していることを確認してください。

7. 「作成」をクリックし、プロファイル作成ジョブを発行します。ジョブが正常に実行されると、新しいエントリが「プロファイル」表で使用可能になります。プロファイル名をクリックすると、詳細を表示できます。

23.6 インストール・メディアに基づくプロファイルまたはOracleホームに基づくプロファイルからの新しいFusion Middlewareドメインのプロビジョニング

インストール・メディア・プロファイルを使用して新しいSOAドメインまたはOracleホームをプロビジョニングするには、次の手順に従います。

注意:
Oracle Fusion Middleware 12.1.0.7のEnterprise Manager以降、SOAとOSBを単一の操作でプロビジョニングできます。これを行うには、SOAとOSBインストール・ファイルを指定してインストール・メディア・プロファイルを作成し、このプロファイルをプロビジョニングする必要があります。前のリリースまでは、1つのドメイン(SOAなど)のみをプロビジョニングし、他の製品(OSBなど)を含めるようにそのドメインを拡張できました。このリリースでは、SOAとOSBの両方を同時にプロビジョニングできる柔軟性を備えています。
Middlewareプロビジョニングでは、GridLinkデータ・ソースを使用するRACのみをサポートしています。

注意:
接続先環境をさらにカスタマイズするには、「拡張」をクリックします。カスタマイズ可能な設定および構成パラメータについては、「インストール・メディア・ベースのプロファイルまたはOracleホーム・ベースのプロファイルからの宛先環境のカスタマイズ」を参照してください。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」をクリックします。

2. Middlewareプロビジョニング・ホームページで、「プロファイル」表からインストール・メディア・プロファイルを選択し、「プロビジョニング」をクリックします。

3. Fusion Middlewareのプロビジョニング・ページの「一般」セクションにインストール・メディア・プロファイルが事前選択されて表示されます。

注意:
WebCenterプロファイルをプロビジョニングしている場合、開発トポロジまたは製品トポロジの使用を選択できます。指定しない場合、デフォルトで製品トポロジが選択されます。トポロジの詳細は、第26.2項を参照してください。

4. 「ホスト」セクションで、ミドルウェア・ホームおよびWebLogicドメインをクローニングする必要がある宛先ホストを検索および選択します。+追加をクリックしてターゲット・ホストを追加し、それらのログイン資格証明を指定します。複数のホストを選択し、そのすべてのログイン資格証明が同じ場合は、すべてに同じ資格証明を選択できます。

5. 「ミドルウェア」セクションに「ミドルウェア・ベース」および「Javaホーム」値が事前に移入されて表示され、必要に応じてこれらの値をカスタマイズできます。ドメイン管理者の資格証明を指定します。

6. 「データベース」セクションで、プロビジョニングしているプロファイルに応じて次のオプションを使用できます。

- インストール・メディア・プロファイルから:
インストール・メディア・プロファイルからプロビジョニングする場合、RCU shiphomeを含むプロファイルを使用して新しいスキーマを作成できます。これを実行するには、「スキーマの作成」オプションを選択します。「スキーマ接頭辞」のデフォルト値が移入されます。必要に応じてこれを変更できます。データベース・ターゲットと新規スキーマの資格証明を指定します。デフォルト・スキーマの作成オプションの選択を解除した場合は、データベース・ターゲットの既存のスキーマが使用されます。

- Oracleホーム・プロファイルから:
Oracleホーム・プロファイルからプロビジョニングする場合、新しいスキーマを作成できません。既存のスキーマを選択し、スキーマ・パスワードを指定する必要があります。

7. (オプション) 「アイデンティティとセキュリティ」セクションで、OIDターゲット名およびOID資格証明を入力する必要があります。これらは、LDAPオーセンティケータを作成するか、ドメインの資格証明ストアを再度関連付けるか、あるいはその両方を実行するための必須フィールドです。

注意:
WebCenterプロファイルをプロビジョニングしている場合、このセクションは、デフォルト・オプションである製品トポロシ゛にのみ表示されます。

これに加えて、OIDセクションで次のセットの入力を指定する必要があります。

- LDAPオーセンティケータ入力の構成。このセクションでは、LDAPオーセンティケータの作成方法を説明します。

- オーセンティケータ名: OIDAuthenticatorプロバイダの名前を入力します。例: MyOIDAuthenticator

- ユーザー・ベースDN: ユーザーが開始時に使用するDNを指定します。例: cn=users,dc=us,dc=mycompany,dc=com

- グループ・ベースDN: 「グループ」ノードを指すDNを指定します。例: cn=groups,dc=us,dc=mycompany,dc=com

注意:
前提条件として、LDAPのユーザーおよびグループをすでにプロビジョニングしている必要があります。

- セキュリティ・ストア入力の構成: このセクションでは、JPSルート・ノード情報を指定します。JPSルート・ノードは、すべてのデータの移行先となるターゲットLDAPリポジトリです。フォーマットは、cn=nodeNameです。

注意:
前提条件として、LDAPのルート・ノードをすでに作成している必要があります。

8. 「Web層」セクションで、+追加をクリックしてOracle HTTP Server (OHS)ターゲットを検索および選択します。「資格証明」フィールドで、ターゲットにアクセスするための資格証明を指定します。複数のOracle HTTP Serverがある場合、「外部ロード・バランサURL」を指定する必要があります。
外部ロード・バランサのURLの形式: (http|https://hostname:port)

例: http://wcp-prov.example.com:80

注意:
WebCenterターゲットをプロビジョニングする場合、内部ロード・バランサURLを追加で指定する必要があります。

内部ロード・バランサのURLの形式: (http|https|tcp:// hostname:port)

例: tcp://wcp-prov-ucm.example.com:4444

注意:
プレーンWebLogicドメインをプロビジョニングしている場合、このセクションは表示されません。

9. 「次へ」をクリックしてプロシージャをスケジュールします。「発行」をクリックした場合、プロシージャはすぐに実行されるように発行されます。「保存」をクリックしてこれをテンプレートとして保存します。この機能はロックダウンで特に有効です。たとえば、デザイナ・ロールでログインし、ロックダウンでテンプレートを作成し、このテンプレートを実行するために他の管理者/オペレータに必要な権限を割り当てることができます。「取消」をクリックしてプロシージャ構成を終了します。

10. 発行後、「プロシージャ・アクティビティ」ページからプロビジョニング操作の進行状況を追跡できます。この詳細は、第50章を参照してください。

11. 新しくプロビジョニングしたターゲットを表示するには、「ターゲット」メニューから「ミドルウェア」を選択します。

23.6.1 インストール・メディア・ベースのプロファイルまたはOracleホーム・ベースのプロファイルからの宛先環境のカスタマイズ

接続先環境をカスタマイズするには、「Fusion Middlewareプロビジョニング」ウィザードで使用できる「拡張」オプションをクリックします。宛先ホストを選択した後にのみ「拡張」オプションが有効であることに注意してください。

次の手順に従います。

注意:
デフォルト・オプション「標準」を選択された状態のままとし、すべての詳細を指定することをお薦めします。この後、「拡張」をクリックして接続先環境をカスタマイズできます。このようにすると、ほとんどのパラメータのデフォルト値は事前移入されて表示され、残り(デルタ)の詳細のみを入力する必要があります。また、「拡張」モードから通常モードに切り替えた場合、これまで行ったすべての変更が失われます。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」をクリックします。

2. Middlewareプロビジョニング・ホームページで、「プロファイル」表からインストール・メディア・プロファイルを選択し、「プロビジョニング」をクリックします。

3. Fusion Middlewareのプロビジョニング構成ページの「一般」セクションにインストール・メディア・プロファイルが事前選択されて表示されます。

注意:
WebCenterプロファイルをプロビジョニングしている場合、開発トポロジまたは製品トポロジの使用を選択できます。指定しない場合、デフォルトで製品トポロジが選択されます。トポロジの詳細は、第26.2項を参照してください。

デフォルトでは、ミドルウェア・ホームは選択されており、このオプションの選択は解除できません。ただし、ミドルウェア・ホームに新規ドメインを作成するかどうかを選択できます。「ドメインのプロビジョニング」を選択した場合、ミドルウェア・ホームが宛先ホストで作成され、新規ドメインが、宛先ホストのこのミドルウェア・ホームに設定されます。

注意: SOAまたはService Busプロファイルをプロビジョニングしている場合は、他の製品を含むようにドメインを拡張できます。たとえば、SOAドメインをプロビジョニングしている場合に「既存ドメインの拡張」オプションを選択すると、Service Busを含むようにSOAドメインを拡張できます。ドメインを拡張するには、ドメインを選択し、管理者資格証明を指定する必要があります。ドメインの拡張機能は、既存のドメインに追加の管理対象サーバーを追加するドメインのスケーリングとは異なります。拡張ドメインには、2つの製品を含むハイブリッド・ドメインを作成できます。現在は、SOAまたはOSBドメインのみ拡張できます。WebCenterなどの他の製品のサポートは使用できません。

複数の宛先ホストを追加した場合は、「共有記憶域の使用」オプションを選択して、これらのホストの共有場所を使用します。

ミドルウェア・ホームのみクローニングするには、「ドメインのプロビジョニング」の選択を解除します。

4. 「ホスト」セクションで、ミドルウェア・ホームおよびWebLogicドメインをクローニングする必要がある宛先ホストを検索および選択します。+追加をクリックしてターゲット・ホストを追加し、それらのログイン資格証明を指定します。複数のホストを選択し、そのすべてのログイン資格証明が同じ場合は、すべてに同じ資格証明を選択できます。

5. 「ミドルウェア」セクションに、「ミドルウェア・ベース」および「Javaホーム」フィールドの値が事前に移入されて表示されます。必要に応じて場所の詳細を変更できます。

- 「ミドルウェア・ホーム」には、ミドルウェア・ホームを作成するディレクトリのフルパスを入力します。

- 「Javaホーム」には、宛先ホストで使用されるJDKディレクトリの絶対パスを入力します。JDKをすべてのホストの同じパスですでにインストール済である必要があります。

6. 「ドメイン」セクションに、ソース・ドメインの構成がデフォルトで表示されます。次の属性を変更してドメインのプロパティをカスタマイズできます。

- ドメイン名: ドメイン名です。ドメインのための生成されたコンポーネントは、指定されたドメイン・ディレクトリに保存されます。たとえば、mydomainと入力すると、ドメイン・ファイルはデフォルトでMW_HOME\user_projects\domains\mydomainに保存されます。

- 管理者のユーザー名: デフォルトのドメイン管理者アカウントです。このアカウントは、ドメインの管理サーバーの起動および接続に使用されます。ユーザー名には、カンマ、タブ、または次の文字を含めることはできません: < > # | & ? ( ) { }。

- 管理者のパスワード: 管理者アカウントのためのパスワードです。パスワードは、8文字以上で、1文字以上の数字または以下の文字のうちのいずれかを1文字以上を含む必要があります: ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~

- 一意のドメイン識別子: ファームは、Enterprise Manager Cloud Controlによって管理されるコンポーネントのコレクションです。Oracle WebLogic Serverドメイン、1つの管理サーバー、1つ以上の管理対象サーバーおよびドメインにインストールされ、構成され、稼働しているOracle Fusion Middlewareで構成されます。「一意のドメイン識別子」は、同じドメイン名を持つファーム名を環境内で一意にするための接頭辞として使用されます。接頭辞としてWeblogicドメイン名と組み合せ、ファーム・ターゲットに名前を付けるために使用されます。たとえば、「一意のドメイン識別子」がfarm、ドメイン名がbase_domainである場合、ファーム名はfarm_base_domainになります。

- ドメイン・ディレクトリ: ドメイン・ディレクトリを格納する場所です。デフォルトでは、このディレクトリは、ミドルウェア・ホームの親ディレクトリの下に作成されますが、変更できません。例: ミドルウェア・ホームが/user/mwhにある場合、アプリケーション・ディレクトリは/user/domainsとして作成されます。ドメインの場所には、ローカル・ドライブまたはネットワーク上の任意の場所を指定できます。Windowsでは、このパスにドライブ文字も含める必要があります。

- アプリケーション・ディレクトリ: アプリケーションが宛先ホストにデプロイされるディレクトリ。デフォルトでは、このディレクトリは、ミドルウェア・ホームの親ディレクトリの下に作成されます。例: ミドルウェア・ホームが/user/mwhにある場合、アプリケーション・ディレクトリは/user/applicationsとして作成されます。

- ドメイン・モード: ドメインは次のいずれかのモードで動作できます。
本番: ドメインは本番用として使用されます。このモードでは、セキュリティ構成が比較的厳重であり、アプリケーションのデプロイにユーザー名とパスワードが要求されます。

開発: ドメインは開発に使用されます。このモードでは、セキュリティ構成が比較的緩和され、アプリケーションの自動デプロイが許可されます。

- サーバーの起動モード: 要件に応じて次のモードの1つでサーバーを起動できます。
すべてのサーバーおよびノード・マネージャを起動: これはデフォルト・オプションです。通常、変更がない場合、およびプロシージャが予期したとおりに稼働している場合は、このオプションを選択します。

管理サーバーのみを起動: このオプションは、管理サーバーまたはノード・マネージャのみを起動します。通常、カスタム・ステップを追加してWLSTオンライン・スクリプトを起動し、次にサーバーを起動する場合にこのオプションを選択します。

サーバーもノード・マネージャも起動しない: このオプションでは、サーバーまたはノード・マネージャは起動されません。通常、サーバーを起動する前にドメインをカスタマイズする必要がある場合に、このオプションを選択します。

7. 「クラスタ」セクションで、クラスタの名前を変更し、クラスタ内の管理対象サーバーを識別するクラスタ・アドレスを入力できます。メッセージング・モードとして「ユニキャスト」または「マルチキャスト」を選択できます。「マルチキャスト」モードを選択した場合は、クラスタでマルチキャスト通信専用に使用するアドレスとポート番号を入力します。+追加をクリックして、構成に1つ以上のクラスタを追加します。

8. 「マシン」セクションで、ドメイン内のマシンの構成情報を入力します。マシンとは、1つまたは複数のWebLogic Serverインスタンスをホストするシステムの論理的な表現です。管理サーバーおよびノード・マネージャは、マシン定義を使用してリモート・サーバーを起動します。+追加をクリックして、1つ以上のマシン構成を追加します。次の詳細を入力します。

- ノード・マネージャ・ホーム: ノード・マネージャがインストールされるディレクトリ。デフォルトでは、ノード・マネージャはミドルウェア・ホーム・ディレクトリの親ディレクトリの下にインストールされますが、これは変更できます。
ノード・マネージャ・ホームは常に管理サーバー・ドメイン・ホーム内にインストールされている必要があります。

- ノード・マネージャ資格証明: 管理サーバー資格証明と同じ資格証明を使用するか、別のノード・マネージャの資格証明を指定するオプションの選択を解除できます。

- マシン名: マシンに対して一意の名前を入力します。

- ホスト: メニューからホスト名を選択します。

- ノード・マネージャ・リスニング・アドレス: ノード・マネージャによって使用される、接続リクエストのリスニングのためのリスニング・アドレスを入力します。デフォルトでは、ドロップダウン・リストにローカル・システムに定義済のIPアドレスおよびlocalhostが表示されます。デフォルト値は、ソース・ドメインで指定した値と同じです。複数のマシンが同じホスト上で実行中の場合、各ホストのノード・マネージャ・ホームの場所は異なる必要があります。

- ノード・マネージャ・リスニング・ポート: ノード・マネージャによって使用される、接続リクエストのリスニングのためのリスニング・ポートの有効値を入力します。ノード・マネージャのリスニング・ポートの有効なポート範囲は1から65535です。デフォルトの値は5556です。ポート番号は、宛先マシンで使用可能である必要があります。

9. 「サーバー」セクションで、管理サーバーと1つ以上の管理対象サーバーの構成情報を入力します。

- 「Coherenceの構成」チェック・ボックスを選択します。

- Coherenceポート: このフィールドは、「Coherenceの構成」オプションを選択した場合にのみ有効になります。デフォルトで移入されるポート番号を保持するか、変更できます。

- リスニング・ポート: このオプションはデフォルトで選択されます。リスニング・ポートの値が事前に移入されます。1から65535までの任意の値を入力できます。ここで入力するポート番号は、宛先マシンで使用可能である必要があります。
ステータスが停止中のポート番号を使用してドメインがホストに登録されている場合は、デプロイメント・プロシージャを開始する前に、別のポートを選択するかドメインを手動で登録解除する必要があります。

- SSLリスニング・ポート: 「SSLリスニング・ポート」を有効にした場合は、セキュアなリクエストのためのSSLリスニング・ポートのポート番号を入力します。リスニング・ポートおよびSSLリスニング・ポートとして指定するポート番号が使用可能であることを確認する必要があります。SSL構成を使用する場合は、ファイル・システム上、ソースと同じパス配下にセキュリティ・ストアまたはアイデンティティ・ストアが存在し、宛先ホストのために生成された証明書で構成されていることを確認する必要があります。

- 管理ポート: このポートにより、ドメインが管理モードで実行可能になります。この場合、すべてのサーバーでSSLを有効にする必要があります。

- ホスト: 管理サーバーまたは管理対象サーバーがインストールされるホストを選択します。

- リスニング・アドレス: 管理サーバーまたは管理対象サーバーのインスタンスへの接続に使用するリスニング・アドレスを入力します。

- マシン: 管理サーバーまたは管理対象サーバーに関連付けられるマシン構成を選択します。

- クラスタ: 管理対象サーバーに関連付けられるクラスタを選択します。

- サーバーの起動: クリックしてサーバー起動パラメータを入力します。通常、ノード・マネージャは起動オプションを指定せずにサーバーを起動できますが、環境をカスタマイズしているため、「サーバー起動パラメータ」ダイアログ・ボックスで起動オプションを指定する必要があります。

- トランザクション・ログ・ディレクトリ: トランザクション・ログは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納します。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーでトランザクション回復サービスの移行機能を活用するには、管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

- 管理対象サーバーのドメイン・ディレクトリ: 管理対象サーバーがインストールされているディレクトリ。デフォルトでは、Middlewareホーム・ディレクトリの親ディレクトリの下にインストールされますが、これは変更できます。

10. 「JMSサーバー」セクションで、+追加をクリックして新しいJMS永続ストアとJMSサーバーを追加します。ストレージ・タイプは次のいずれかにすることができます。

- JMSファイル・ストアは、永続メッセージを保存できるディスクベースのファイルです。ドメインに構成したJMSファイル・ストアを変更できます。

- JDBCストア:

- データ・ソース

- ターゲット

11. 「データベース」セクションで、プロビジョニングしているプロファイルに応じて次のオプションを使用できます。

- インストール・メディア・プロファイルから:

データベース・ターゲットを検索および選択します。「スキーマ接頭辞」のデフォルト値が移入されます。必要に応じてこれを変更できます。

- 「スキーマの作成」オプションでは、デフォルトで選択されたRCUプロファイルの新規スキーマを作成できます。データベース・ターゲットと新規スキーマの資格証明を指定します。

- 選択したデータベース・ターゲット上のすべてのデータソースに同じユーザー名およびパスワードを使用する場合は、「すべてに同じパスワード」オプションを選択します。
デフォルト・スキーマの作成オプションの選択を解除した場合は、データベース・ターゲットの既存のスキーマが使用されます。

- Oracleホーム・プロファイルから:
デフォルト・スキーマの作成オプションの選択を解除した場合は、データベース・ターゲットの既存のスキーマが使用されます。

12. (オプション) 「アイデンティティとセキュリティ」セクションで、OIDターゲット名およびOID資格証明を入力する必要があります。これらは、LDAPオーセンティケータを作成するか、ドメインの資格証明ストアを再度関連付けるか、あるいはその両方を実行するための必須フィールドです。

注意:
WebCenterプロファイルをプロビジョニングしている場合、このセクションは、デフォルト・オプションである製品トポロシ゛にのみ表示されます。

これに加えて、OIDセクションで次のセットの入力を指定する必要があります。

- LDAPオーセンティケータ入力の構成。このセクションでは、LDAPオーセンティケータの作成方法を説明します。

- オーセンティケータ名: OIDAuthenticatorプロバイダの名前を入力します。例: MyOIDAuthenticator

- ユーザー・ベースDN: ユーザーが開始時に使用するDNを指定します。例: cn=users,dc=us,dc=mycompany,dc=com

- グループ・ベースDN: 「グループ」ノードを指すDNを指定します。例: cn=groups,dc=us,dc=mycompany,dc=com

注意:
前提条件として、LDAPのユーザーおよびグループをすでにプロビジョニングしている必要があります。

- セキュリティ・ストア入力の構成: このセクションでは、JPSルート・ノード情報を指定します。JPSルート・ノードは、すべてのデータの移行先となるターゲットLDAPリポジトリです。フォーマットは、cn=nodeNameです。

注意:
前提条件として、LDAPのルート・ノードをすでに作成している必要があります。

13. 「Web層」セクションで、+追加をクリックしてOracle HTTP Server (OHS)ターゲットを検索および選択します。「資格証明」フィールドで、ターゲットにアクセスするための資格証明を指定します。複数のOracle HTTP Serverがある場合、「外部ロード・バランサURL」を指定する必要があります。
外部ロード・バランサのURLの形式: (http|https://hostname:port)

例: http://wcp-prov.example.com:80

注意:
WebCenterターゲットをプロビジョニングする場合、内部ロード・バランサURLを追加で指定する必要があります。

内部ロード・バランサのURLの形式: (http|https|tcp:// hostname:port)

例: tcp://wcp-prov-ucm.example.com:4444

注意:
プレーンWebLogicドメインをプロビジョニングしている場合、このセクションは表示されません。

14. 「カスタム・スクリプト」セクションで、ソフトウェア・ライブラリにディレクティブとして格納されているスクリプトを選択して、デプロイメント・プロシージャをカスタマイズできます。次のオプションが可能であり、パラメータを含むスクリプトを渡すかどうかを選択できます。

1. 入力パラメータを含むスクリプトを渡すことができます。詳細は、23.4.3.1項を参照してください。
注意: 入力パラメータを渡す場合、「入力ファイル」のデフォルト・オプションの選択を許可していることを確認してください。たとえば、「前処理スクリプト」フィールドで、以前作成したMy Custom Script With Parametersを選択できます。詳細は、「入力パラメータを含むカスタム・スクリプトの格納」を参照してください。次に手順を示します。

サンプル入力プロパティ(input.properties)ファイルの内容を次に示します。

ADMIN_SERVER_LISTEN_ADDRESS=slc01.example.com
ADMIN_SERVER_LISTEN_PORT=7001
ADMIN_PROTOCOL=t3
MIDDLEWARE_HOME=/scratch/usr1/soa/middleware

2. または、入力パラメータを含まないスクリプトを渡すことを選択できます。詳細は、23.4.3.2項を参照してください。
注意: 入力パラメータを渡さない場合、「入力ファイル」オプションの選択を解除する必要があります。たとえば、「前処理スクリプト」フィールドで、以前作成したMy Custom Script Without Parametersを選択できます。詳細は、「入力パラメータを含まないカスタム・スクリプトの格納」を参照してください。次に手順を示します。

次のスクリプトを渡してプロシージャをカスタマイズできます。

15. 「次へ」をクリックしてプロシージャをスケジュールします。「発行」をクリックした場合、プロシージャはすぐに実行されるように発行されます。「保存」をクリックしてこれをテンプレートとして保存します。この機能はロックダウンで特に有効です。たとえば、デザイナ・ロールでログインし、ロックダウンでテンプレートを作成し、このテンプレートを実行するために他の管理者/オペレータに必要な権限を割り当てることができます。「取消」をクリックしてプロシージャ構成を終了します。

16. 発行後、「プロシージャ・アクティビティ」ページからプロビジョニング操作の進行状況を追跡できます。この詳細は、第50章を参照してください。

17. 新しくプロビジョニングしたターゲットを表示するには、「ターゲット」メニューから「ミドルウェア」を選択します。

23.7 既存のOracleホームからのFusion Middlewareドメインのプロビジョニング

既存のOracleホームから新しいドメインをプロビジョニングするには、次の手順に従います。

注意:
接続先環境をさらにカスタマイズするには、「拡張」をクリックします。カスタマイズ可能な設定および構成パラメータについては、「既存のOracleホームからの宛先環境のカスタマイズ」を参照してください。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」をクリックします。

2. Middlewareプロビジョニング・ホームページの「デプロイメント・プロシージャ」セクションで、「Fusion Middlewareのプロビジョニング」を選択し、「起動」をクリックします。

3. Middlewareプロビジョニング・ページの「一般」セクションで、「Oracleホーム」を選択します。検索アイコンをクリックすると、「ターゲットの選択」ダイアログ・ボックスが表示されます。再利用するWebLogic Serverホームを検索および選択します。

4. 「ホスト」セクションで、+追加をクリックして、クローンを作成したミドルウェア・ホームが置かれる宛先ホストを検索して選択します。クローニング操作の場合は、宛先ホストのログイン資格証明を指定する必要があります。複数のホストを選択し、そのすべてのログイン資格証明が同じ場合は、すべてに同じ資格証明オプションを選択できます。

5. 「ミドルウェア」セクションで、ドメインの管理者資格証明を指定します。

6. 「データベース」セクションで、データベース・ターゲットを選択し、既存のスキーマを選択してスキーマ・パスワードを指定します。

7. (オプション) 「アイデンティティとセキュリティ」セクションで、OIDターゲット名およびOID資格証明を入力する必要があります。これらは、LDAPオーセンティケータを作成するか、ドメインの資格証明ストアを再度関連付けるか、あるいはその両方を実行するための必須フィールドです。

注意:
WebCenterプロファイルをプロビジョニングしている場合、このセクションは、デフォルト・オプションである製品トポロシ゛にのみ表示されます。

これに加えて、OIDセクションで次のセットの入力を指定する必要があります。

- LDAPオーセンティケータ入力の構成。このセクションでは、LDAPオーセンティケータの作成方法を説明します。

- オーセンティケータ名: OIDAuthenticatorプロバイダの名前を入力します。例: MyOIDAuthenticator

- ユーザー・ベースDN: ユーザーが開始時に使用するDNを指定します。例: cn=users,dc=us,dc=mycompany,dc=com

- グループ・ベースDN: 「グループ」ノードを指すDNを指定します。例: cn=groups,dc=us,dc=mycompany,dc=com

注意:
前提条件として、LDAPのユーザーおよびグループをすでにプロビジョニングしている必要があります。

- セキュリティ・ストア入力の構成: このセクションでは、JPSルート・ノード情報を指定します。JPSルート・ノードは、すべてのデータの移行先となるターゲットLDAPリポジトリです。フォーマットは、cn=nodeNameです。

注意:
前提条件として、LDAPのルート・ノードをすでに作成している必要があります。

8. 「Web層」セクションで、+追加をクリックしてOracle HTTP Server (OHS)ターゲットを検索および選択します。「資格証明」フィールドで、ターゲットにアクセスするための資格証明を指定します。複数のOracle HTTP Serverがある場合、「外部ロード・バランサURL」を指定する必要があります。
外部ロード・バランサのURLの形式: (http|https://hostname:port)

例: http://wcp-prov.example.com:80

注意:
WebCenterターゲットをプロビジョニングする場合、内部ロード・バランサURLを追加で指定する必要があります。

内部ロード・バランサのURLの形式: (http|https|tcp:// hostname:port)

例: tcp://wcp-prov-ucm.example.com:4444

注意:
プレーンWebLogicドメインをプロビジョニングしている場合、このセクションは表示されません。

9. 「次へ」をクリックしてプロシージャをスケジュールします。「発行」をクリックした場合、プロシージャはすぐに実行されるように発行されます。「保存」をクリックしてこれをテンプレートとして保存します。この機能はロックダウンで特に有効です。たとえば、ロックダウンを使用してテンプレートを作成し、オペレータ権限を持つ他のユーザーにわずかな変更のあるテンプレートを複数回実行することを許可する場合です。
「取消」をクリックしてプロシージャ構成を終了します。

10. 発行後、「プロシージャ・アクティビティ」ページからプロビジョニング操作の進行状況を追跡できます。この詳細は、第50章を参照してください。

11. 新しくプロビジョニングしたターゲットを表示するには、「ターゲット」メニューから「ミドルウェア」を選択します。

23.7.1 既存のOracleホームからの宛先環境のカスタマイズ

接続先環境をカスタマイズするには、「Fusion Middlewareプロビジョニング」ウィザードで使用できる「拡張」をクリックします。宛先ホストを選択した後にのみ「拡張」オプションが有効であることに注意してください。

次の手順に従います。

注意:
デフォルト・オプション「標準」を選択された状態のままとし、すべての詳細を指定することをお薦めします。この後、「拡張」をクリックして接続先環境をカスタマイズできます。このようにすると、ほとんどのパラメータのデフォルト値は事前移入されて表示され、残り(デルタ)の詳細のみを入力する必要があります。また、「拡張」モードから通常モードに切り替えた場合、これまで行ったすべての変更が失われます。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」をクリックします。

2. Middlewareプロビジョニング・ホームページの「デプロイメント・プロシージャ」セクションで、「Fusion Middlewareのプロビジョニング」を選択し、「起動」をクリックします。

3. Fusion Middlewareのプロビジョニング構成ページの「一般」セクションにOracleホームが事前選択されて表示されます。
デフォルトでは、「ドメインのプロビジョニング」オプションが選択されます。基本的に、新しいドメインは既存のOracleホームでプロビジョニングされます。

ミドルウェア・ホームのみクローニングするには、「ドメインのプロビジョニング」の選択を解除します。

4. 「ホスト」セクションで、ミドルウェア・ホームおよびWebLogicドメインをクローニングする必要のある宛先ホストを検索し選択します。+追加をクリックしてターゲット・ホストを追加し、それらのログイン資格証明を指定します。複数のホストを選択し、そのすべてのログイン資格証明が同じ場合は、すべてに同じ資格証明を選択できます。

5. 「ドメイン」セクションに、ドメインの構成がデフォルトで表示されます。次の属性を変更してドメインのプロパティをカスタマイズできます。

- ドメイン名: ドメイン名です。ドメインのための生成されたコンポーネントは、指定されたドメイン・ディレクトリに保存されます。たとえば、mydomainと入力すると、ドメイン・ファイルはデフォルトでMW_HOME\user_projects\domains\mydomainに保存されます。

- 管理者のユーザー名: デフォルトのドメイン管理者アカウントです。このアカウントは、ドメインの管理サーバーの起動および接続に使用されます。ユーザー名には、カンマ、タブ、または次の文字を含めることはできません: < > # | & ? ( ) { }。

- 管理者のパスワード: 管理者アカウントのためのパスワードです。パスワードは、8文字以上で、1文字以上の数字または以下の文字のうちのいずれかを1文字以上を含む必要があります: ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~

- 一意のドメイン識別子: ファームは、Enterprise Manager Cloud Controlによって管理されるコンポーネントのコレクションです。Oracle WebLogic Serverドメイン、1つの管理サーバー、1つ以上の管理対象サーバーおよびドメインにインストールされ、構成され、稼働しているOracle Fusion Middlewareで構成されます。「一意のドメイン識別子」は、同じドメイン名を持つファーム名を環境内で一意にするための接頭辞として使用されます。接頭辞としてWeblogicドメイン名と組み合せ、ファーム・ターゲットに名前を付けるために使用されます。たとえば、「一意のドメイン識別子」がfarm、ドメイン名がbase_domainである場合、ファーム名はfarm_base_domainになります。

- ドメイン・ディレクトリ: ドメイン・ディレクトリを格納する場所です。デフォルトでは、このディレクトリは、ミドルウェア・ホームの親ディレクトリの下に作成されますが、変更できません。例: ミドルウェア・ホームが/user/mwhにある場合、アプリケーション・ディレクトリは/user/domainsとして作成されます。ドメインの場所には、ローカル・ドライブまたはネットワーク上の任意の場所を指定できます。Windowsでは、このパスにドライブ文字も含める必要があります。

- アプリケーション・ディレクトリ: アプリケーションが宛先ホストにデプロイされるディレクトリ。デフォルトでは、このディレクトリは、ミドルウェア・ホームの親ディレクトリの下に作成されます。例: ミドルウェア・ホームが/user/mwhにある場合、アプリケーション・ディレクトリは/user/applicationsとして作成されます。

- ドメイン・モード: ドメインは次のいずれかのモードで動作できます。
本番: ドメインは本番用として使用されます。このモードでは、セキュリティ構成が比較的厳重であり、アプリケーションのデプロイにユーザー名とパスワードが要求されます。

開発: ドメインは開発に使用されます。このモードでは、セキュリティ構成が比較的緩和され、アプリケーションの自動デプロイが許可されます。

- サーバーの起動モード: 要件に応じて次のモードの1つでサーバーを起動できます。
すべてのサーバーおよびノード・マネージャを起動: これはデフォルト・オプションです。通常、変更がない場合、およびプロシージャが予期したとおりに稼働している場合は、このオプションを選択します。

管理サーバーのみを起動: このオプションは、管理サーバーまたはノード・マネージャのみを起動します。通常、カスタム・ステップを追加してWLSTオンライン・スクリプトを起動し、次にサーバーを起動する場合にこのオプションを選択します。

サーバーもノード・マネージャも起動しない: このオプションでは、サーバーまたはノード・マネージャは起動されません。通常、サーバーを起動する前にドメインをカスタマイズする必要がある場合に、このオプションを選択します。

6. 「クラスタ」セクションで、クラスタの名前を変更し、クラスタ内の管理対象サーバーを識別するクラスタ・アドレスを入力できます。メッセージング・モードとして「ユニキャスト」または「マルチキャスト」を選択できます。「マルチキャスト」モードを選択した場合は、クラスタでマルチキャスト通信専用に使用するアドレスとポート番号を入力します。+追加をクリックして、構成に1つ以上のクラスタを追加します。

7. 「マシン」セクションで、ドメイン内のマシンの構成情報を入力します。マシンとは、1つまたは複数のWebLogic Serverインスタンスをホストするシステムの論理的な表現です。管理サーバーおよびノード・マネージャは、マシン定義を使用してリモート・サーバーを起動します。+追加をクリックして、1つ以上のマシン構成を追加します。次の詳細を入力します。

- ノード・マネージャ・ホーム: ノード・マネージャがインストールされるディレクトリ。デフォルトでは、ノード・マネージャはミドルウェア・ホーム・ディレクトリの親ディレクトリの下にインストールされますが、これは変更できます。
ノード・マネージャ・ホームは常に管理サーバー・ドメイン・ホーム内にインストールされている必要があります。

- ノード・マネージャ資格証明: 管理サーバー資格証明と同じ資格証明を使用するか、別のノード・マネージャの資格証明を指定するオプションの選択を解除できます。

- マシン名: マシンに対して一意の名前を入力します。

- ホスト: メニューからホスト名を選択します。

- ノード・マネージャ・リスニング・アドレス: ノード・マネージャによって使用される、接続リクエストのリスニングのためのリスニング・アドレスを入力します。デフォルトでは、ドロップダウン・リストにローカル・システムに定義済のIPアドレスおよびlocalhostが表示されます。デフォルト値は、ソース・ドメインで指定した値と同じです。複数のマシンが同じホスト上で実行中の場合、各ホストのノード・マネージャ・ホームの場所は異なる必要があります。

- ノード・マネージャ・リスニング・ポート: ノード・マネージャによって使用される、接続リクエストのリスニングのためのリスニング・ポートの有効値を入力します。ノード・マネージャのリスニング・ポートの有効なポート範囲は1から65535です。デフォルトの値は5556です。ポート番号は、宛先マシンで使用可能である必要があります。

8. 「サーバー」セクションで、管理サーバーと1つ以上の管理対象サーバーの構成情報を入力します。

- 「Coherenceの構成」チェック・ボックスを選択します。

- Coherenceポート: このフィールドは、「Coherenceの構成」オプションを選択した場合にのみ有効になります。デフォルトで移入されるポート番号を保持するか、変更できます。

- リスニング・ポート: このオプションはデフォルトで選択されます。リスニング・ポートの値が事前に移入されます。1から65535までの任意の値を入力できます。ここで入力するポート番号は、宛先マシンで使用可能である必要があります。
ステータスが停止中のポート番号を使用してドメインがホストに登録されている場合は、デプロイメント・プロシージャを開始する前に、別のポートを選択するかドメインを手動で登録解除する必要があります。

- SSLリスニング・ポート: 「SSLリスニング・ポート」を有効にした場合は、セキュアなリクエストのためのSSLリスニング・ポートのポート番号を入力します。リスニング・ポートおよびSSLリスニング・ポートとして指定するポート番号が使用可能であることを確認する必要があります。SSL構成を使用する場合は、ファイル・システム上、ソースと同じパス配下にセキュリティ・ストアまたはアイデンティティ・ストアが存在し、宛先ホストのために生成された証明書で構成されていることを確認する必要があります。

- 管理ポート: このポートにより、ドメインが管理モードで実行可能になります。この場合、すべてのサーバーでSSLを有効にする必要があります。

- ホスト: 管理サーバーまたは管理対象サーバーがインストールされるホストを選択します。

- リスニング・アドレス: 管理サーバーまたは管理対象サーバーのインスタンスへの接続に使用するリスニング・アドレスを入力します。

- マシン: 管理サーバーまたは管理対象サーバーに関連付けられるマシン構成を選択します。

- クラスタ: 管理対象サーバーに関連付けられるクラスタを選択します。

- サーバーの起動: クリックしてサーバー起動パラメータを入力します。通常、ノード・マネージャは起動オプションを指定せずにサーバーを起動できますが、環境をカスタマイズしているため、「サーバー起動パラメータ」ダイアログ・ボックスで起動オプションを指定する必要があります。

- トランザクション・ログ・ディレクトリ: トランザクション・ログは、サーバーが調整およびコミットする、完了していない可能性のあるトランザクションに関する情報を格納します。Oracle WebLogic Serverは、システム・クラッシュやネットワーク障害のリカバリでこのトランザクション・ログを使用します。クラスタ内の管理対象サーバーでトランザクション回復サービスの移行機能を活用するには、管理対象サーバーとそのバックアップ・サーバーからアクセス可能な場所にトランザクション・ログを格納します。

- 管理対象サーバーのドメイン・ディレクトリ: 管理対象サーバーがインストールされているディレクトリ。デフォルトでは、Middlewareホーム・ディレクトリの親ディレクトリの下にインストールされますが、これは変更できます。

9. 「JMSサーバー」セクションで、+追加をクリックして新しいJMS永続ストアとJMSサーバーを追加します。ストレージ・タイプは次のいずれかにすることができます。

- JMSファイル・ストアは、永続メッセージを保存できるディスクベースのファイルです。ドメインに構成したJMSファイル・ストアを変更できます。

- JDBCストア:

- データ・ソース

- ターゲット

10. 「データベース」セクションで、既存のスキーマを選択し、スキーマ・パスワードを指定します。選択したデータベース・ターゲット上のすべてのデータソースに同じユーザー名およびパスワードを使用する場合は、「すべてに同じパスワード」オプションを選択します。

11. (オプション) 「アイデンティティとセキュリティ」セクションで、OIDターゲット名およびOID資格証明を入力する必要があります。これらは、LDAPオーセンティケータを作成するか、ドメインの資格証明ストアを再度関連付けるか、あるいはその両方を実行するための必須フィールドです。

注意:
WebCenterプロファイルをプロビジョニングしている場合、このセクションは、デフォルト・オプションである製品トポロシ゛にのみ表示されます。

これに加えて、OIDセクションで次のセットの入力を指定する必要があります。

- LDAPオーセンティケータ入力の構成。このセクションでは、LDAPオーセンティケータの作成方法を説明します。

- オーセンティケータ名: OIDAuthenticatorプロバイダの名前を入力します。例: MyOIDAuthenticator

- ユーザー・ベースDN: ユーザーが開始時に使用するDNを指定します。例: cn=users,dc=us,dc=mycompany,dc=com

- グループ・ベースDN: 「グループ」ノードを指すDNを指定します。例: cn=groups,dc=us,dc=mycompany,dc=com

注意:
前提条件として、LDAPのユーザーおよびグループをすでにプロビジョニングしている必要があります。

- セキュリティ・ストア入力の構成: このセクションでは、JPSルート・ノード情報を指定します。JPSルート・ノードは、すべてのデータの移行先となるターゲットLDAPリポジトリです。フォーマットは、cn=nodeNameです。

注意:
前提条件として、LDAPのルート・ノードをすでに作成している必要があります。

12. 「Web層」セクションで、+追加をクリックしてOracle HTTP Server (OHS)ターゲットを検索および選択します。「資格証明」フィールドで、ターゲットにアクセスするための資格証明を指定します。複数のOracle HTTP Serverがある場合、「外部ロード・バランサURL」を指定する必要があります。
外部ロード・バランサのURLの形式: (http|https://hostname:port)

例: http://wcp-prov.example.com:80

注意:
WebCenterターゲットをプロビジョニングする場合、内部ロード・バランサURLを追加で指定する必要があります。

内部ロード・バランサのURLの形式: (http|https|tcp:// hostname:port)

例: tcp://wcp-prov-ucm.example.com:4444

注意:
プレーンWebLogicドメインをプロビジョニングしている場合、このセクションは表示されません。

13. 「カスタム・スクリプト」セクションで、ソフトウェア・ライブラリにディレクティブとして格納されているスクリプトを選択して、デプロイメント・プロシージャをカスタマイズできます。次のオプションが可能であり、パラメータを含むスクリプトを渡すかどうかを選択できます。

1. 入力パラメータを含むスクリプトを渡すことができます。詳細は、23.4.3.1項を参照してください。
注意: 入力パラメータを渡す場合、「入力ファイル」のデフォルト・オプションの選択を許可していることを確認してください。たとえば、「前処理スクリプト」フィールドで、以前作成したMy Custom Script With Parametersを選択できます。詳細は、「入力パラメータを含むカスタム・スクリプトの格納」を参照してください。次に手順を示します。

サンプル入力プロパティ(input.properties)ファイルの内容を次に示します。

ADMIN_SERVER_LISTEN_ADDRESS=slc01.example.com
ADMIN_SERVER_LISTEN_PORT=7001
ADMIN_PROTOCOL=t3
MIDDLEWARE_HOME=/scratch/usr1/soa/middleware

2. または、入力パラメータを含まないスクリプトを渡すことを選択できます。次に手順を示します。
注意: 入力パラメータを渡さない場合、「入力ファイル」オプションの選択を解除する必要があります。たとえば、「前処理スクリプト」フィールドで、以前作成したMy Custom Script Without Parametersを選択できます。詳細は、23.4.3.2項を参照してください。

次のスクリプトを渡してプロシージャをカスタマイズできます。

- 前処理スクリプト: このスクリプトは、前提条件チェックが終了してからOracleホームまたはWebLogicドメインがデプロイされるまでに実行されます。

- 管理サーバー起動後スクリプト: このスクリプトは、管理サーバーの起動後に実行されます。

- 後処理スクリプト: このスクリプトは、すべての管理対象サーバーの起動後に実行されます。

14. 「次へ」をクリックしてプロシージャをスケジュールします。「発行」をクリックした場合、プロシージャはすぐに実行されるように発行されます。「保存」をクリックしてこれをテンプレートとして保存します。この機能はロックダウンで特に有効です。たとえば、デザイナ・ロールでログインし、ロックダウンでテンプレートを作成し、このテンプレートを実行するために他の管理者/オペレータに必要な権限を割り当てることができます。「取消」をクリックしてプロシージャ構成を終了します。

15. 発行後、「プロシージャ・アクティビティ」ページからプロビジョニング操作の進行状況を追跡できます。この詳細は、第50章を参照してください。

16. 新しくプロビジョニングしたターゲットを表示するには、「ターゲット」メニューから「ミドルウェア」を選択します。

23.8 既存のWebLogicドメインに基づくプロファイルからのクローニング

既存のドメインをクローニングするには、次の手順を実行します。

注意:
接続先環境をさらにカスタマイズするには、「拡張」をクリックします。カスタマイズ可能な設定および構成パラメータについては、「既存のWeLogicドメイン・ベースのプロファイルからの宛先環境のカスタマイズ」を参照してください。

注意:
Middlewareプロビジョニングでは、GridLinkデータ・ソースを使用するRACのみをサポートしています。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」をクリックします。

2. Middlewareプロビジョニング・ホームページで、「プロファイル」表からWebLogicドメイン・プロファイルを選択し、「プロビジョニング」をクリックします。

3. Fusion Middlewareのプロビジョニング・ページの「一般」セクションにWebLogicドメイン・プロファイルが事前選択されて表示されます。

4. 「ホスト」セクションで、クローンを作成したWebLogicドメインが置かれる宛先ホストを検索して選択します。+追加をクリックしてターゲット・ホストを追加し、それらのログイン資格証明を指定します。複数のホストを選択し、そのすべてのログイン資格証明が同じ場合は、すべてに同じ資格証明を選択できます。
注意: クローニング操作を正常に実行するには、宛先ホストとソース・ホストのドメイン構成がまったく同じである必要があります。たとえば、ソース・ドメインが2つの異なるホスト上にサーバーを持つ場合は、2つの異なる宛先ホストを選択する必要があります。続行する前にその操作を行うためのプロンプトが表示されます。

5. 「ミドルウェア」セクションでは、Javaホームの値が事前に移入されて表示されます。ドメイン管理者の資格証明を指定します。

6. 「データベース」セクションで、クローニングされたデータベース・ターゲットを選択し、スキーマ・パスワードを指定します。

注意:
このセクションは、ソース・データベースにデータ・ソースがある場合にのみ表示されます。

7. (オプション) 「アイデンティティとセキュリティ」セクションで、OIDターゲット名および資格証明を入力します。前提条件として、接続先環境にソースOIDをクローニングしている必要があります。

8. 「Web層」セクションで、+追加をクリックしてOracle HTTP Server (OHS)ターゲットを検索および選択します。「資格証明」フィールドで、ターゲットにアクセスするための資格証明を指定します。複数のOracle HTTP Serverがある場合、「外部ロード・バランサURL」を指定する必要があります。
外部ロード・バランサのURLの形式: (http|https://hostname:port)

例: http://wcp-prov.example.com:80

注意:
WebCenterターゲットをプロビジョニングする場合、内部ロード・バランサURLを追加で指定する必要があります。

内部ロード・バランサのURLの形式: (http|https|tcp:// hostname:port)

例: tcp://wcp-prov-ucm.example.com:4444

注意:
プレーンWebLogicドメインをプロビジョニングしている場合、このセクションは表示されません。

9. 「次へ」をクリックしてプロシージャをスケジュールします。「発行」をクリックした場合、プロシージャはすぐに実行されるように発行されます。「保存」をクリックしてこれをテンプレートとして保存します。この機能はロックダウンで特に有効です。たとえば、ロックダウンを使用してテンプレートを作成し、オペレータ権限を持つ他のユーザーにわずかな変更のあるテンプレートを複数回実行することを許可する場合です。
「取消」をクリックしてプロシージャ構成を終了します。

10. 発行後、「プロシージャ・アクティビティ」ページからプロビジョニング操作の進行状況を追跡できます。この詳細は、第50章を参照してください。

11. 新しくプロビジョニングしたターゲットを表示するには、「ターゲット」メニューから「ミドルウェア」を選択します。

23.8.1 既存のWeLogicドメイン・ベースのプロファイルからの宛先環境のカスタマイズ

接続先環境をカスタマイズするには、「Fusion Middlewareプロビジョニング」ウィザードで使用できる「拡張」をクリックします。宛先ホストを選択した後にのみ「拡張」オプションが有効であることに注意してください。

次の手順に従います。

注意:
デフォルト・オプション「標準」を選択された状態のままとし、すべての詳細を指定することをお薦めします。この後、「拡張」をクリックして接続先環境をカスタマイズできます。このようにすると、ほとんどのパラメータのデフォルト値は事前移入されて表示され、残り(デルタ)の詳細のみを入力する必要があります。また、「拡張」モードから通常モードに切り替えた場合、これまで行ったすべての変更が失われます。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」をクリックします。

2. Middlewareプロビジョニング・ホームページの「デプロイメント・プロシージャ」セクションで、「Fusion Middlewareのプロビジョニング」を選択し、「起動」をクリックします。

3. Middlewareプロビジョニング・ページの「一般」セクションで、クローニングする、ソース・ドメインの詳細を含むWebLogicドメイン・プロファイルを選択します。
デフォルトでは、Oracleホームを含むWebLogicドメインをプロビジョニングします。ドメイン(ビットレス・プロファイル)のみプロビジョニングするには、「ミドルウェア・ホームのプロビジョニング」の選択を解除し、「ドメインのプロビジョニング」を選択します。または、ミドルウェア・ホームのみプロビジョニングするには、「ミドルウェア・ホームのプロビジョニング」オプションを保持し、「ドメインのプロビジョニング」の選択を解除します。

「共有記憶域の使用」は、複数の宛先ホストがある場合に特に便利です。このオプションにより、すべてのホストからアクセス可能なマウント場所を使用できます。

4. 「ホスト」セクションで、クローンを作成したWebLogicドメインが置かれる宛先ホストを検索して選択します。+追加をクリックしてターゲット・ホストを追加し、それらのログイン資格証明を指定します。複数のホストを選択し、そのすべてのログイン資格証明が同じ場合は、すべてに同じ資格証明を選択できます。
注意: クローニング操作を正常に実行するには、宛先ホストとソース・ホストのドメイン構成がまったく同じである必要があります。たとえば、ソース・ドメインが2つの異なるホスト上にサーバーを持つ場合は、2つの異なる宛先ホストを選択する必要があります。続行する前にその操作を行うためのプロンプトが表示されます。

5. 「ミドルウェア」セクションで、デフォルトで「ミドルウェア・ホーム」および「Javaホーム」の値が事前に移入されています。必要に応じて場所の詳細を変更できます。

- 「ミドルウェア・ホーム」には、ミドルウェア・ホームを作成するディレクトリのフルパスを入力します。

- 「Javaホーム」には、宛先ホストで使用されるJDKディレクトリの絶対パスを入力します。ソース・マシンに同様の構成が見られる場合は、このパスを指定する必要があります。

6. 「ドメイン」セクションに、ソース・ドメインの構成がデフォルトで表示されます。次の属性を変更してドメインのプロパティをカスタマイズできます。

1. ドメイン名: ドメイン名です。ドメインのための生成されたコンポーネントは、指定されたドメイン・ディレクトリに保存されます。たとえば、mydomainと入力すると、ドメイン・ファイルはデフォルトでMW_HOME\user_projects\domains\mydomainに保存されます。

2. 管理者のユーザー名: デフォルトのドメイン管理者アカウントです。このアカウントは、ドメインの管理サーバーの起動および接続に使用されます。ユーザー名には、カンマ、タブ、または次の文字を含めることはできません: < > # | & ? ( ) { }。

3. 管理者のパスワード: 管理者アカウントのためのパスワードです。パスワードは、8文字以上で、1文字以上の数字または以下の文字のうちのいずれかを1文字以上を含む必要があります: ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~

4. 一意のドメイン識別子: ファームは、Enterprise Manager Cloud Controlによって管理されるコンポーネントのコレクションです。Oracle WebLogic Serverドメイン、1つの管理サーバー、1つ以上の管理対象サーバーおよびドメインにインストールされ、構成され、稼働しているOracle Fusion Middlewareで構成されます。「一意のドメイン識別子」は、同じドメイン名を持つファーム名を環境内で一意にするための接頭辞として使用されます。接頭辞としてWeblogicドメイン名と組み合せ、ファーム・ターゲットに名前を付けるために使用されます。たとえば、「一意のドメイン識別子」がfarm、ドメイン名がbase_domainである場合、ファーム名はfarm_base_domainになります。

5. ドメイン・ディレクトリ: ドメイン・ディレクトリを格納する場所です。デフォルトでは、このディレクトリは、ミドルウェア・ホームの親ディレクトリの下に作成されますが、変更できません。例: ミドルウェア・ホームが/user/mwhにある場合、アプリケーション・ディレクトリは/user/mwh/domainsとして作成されます。ドメインの場所には、ローカル・ドライブまたはネットワーク上の任意の場所を指定できます。Windowsでは、このパスにドライブ文字も含める必要があります。

6. アプリケーション・ディレクトリ: アプリケーションが宛先ホストにデプロイされるディレクトリ。デフォルトでは、このディレクトリは、ミドルウェア・ホームの親ディレクトリの下に作成されます。例: ミドルウェア・ホームが/user/mwhにある場合、アプリケーション・ディレクトリは/user/mwh/applicationsとして作成されます。

7. サーバーの起動モード: 要件に応じて次のモードの1つでサーバーを起動できます。
すべてのサーバーおよびノード・マネージャを起動: これはデフォルト・オプションです。通常、変更がない場合、およびプロシージャが予期したとおりに稼働している場合は、このオプションを選択します。

管理サーバーのみを起動: このオプションは、管理サーバーまたはノード・マネージャのみを起動します。通常、カスタム・ステップを追加してWLSTオンライン・スクリプトを起動し、次にサーバーを起動する場合にこのオプションを選択します。

サーバーもノード・マネージャも起動しない: このオプションでは、サーバーまたはノード・マネージャは起動されません。通常、サーバーを起動する前にドメインをカスタマイズする必要がある場合に、このオプションを選択します。

7. 「クラスタ」セクションで、ソース・ドメイン内の使用可能なすべてのクラスタが宛先ホストにプロビジョニングされます。

8. 「マシン」セクションに、ソース・ドメイン内の構成情報が事前に移入されています。マシンとは、1つまたは複数のWebLogic Serverインスタンスをホストするシステムの論理的な表現です。管理サーバーおよびノード・マネージャは、マシン定義を使用してリモート・サーバーを起動します。ここではいずれの値もカスタマイズできません。

9. 「サーバー」セクションでは、管理サーバーおよび管理対象サーバーのすべての構成情報がソース・ドメインから選択されます。次の情報をカスタマイズできます。
a.「Coherenceの構成」チェック・ボックスを選択します。

b. Coherenceポート: カスタマイズできないポート値が事前に移入されます。

c. カスタム・アイデンティティとカスタム信頼: SSLモードでドメインを構成する場合にカスタム証明書を指定するには、このオプションを使用します。

10. 「JMSサーバー」セクションで、ソース・ドメインに対して構成されたすべてのJMSサーバーが宛先ホストにクローニングされます。ここではいずれの値もカスタマイズできません。

11. 「データベース」セクションで、データ・ソースのスキーマ・ユーザー名およびパスワードを変更できます。

注意:
このセクションは、ソース・データベースにデータ・ソースがある場合にのみ表示されます。

12. (オプション) 「アイデンティティとセキュリティ」セクションで、OIDターゲット名および資格証明を入力します。前提条件として、接続先環境にソースOIDをクローニングしている必要があります。

13. 「Web層」セクションで、+追加をクリックしてOracle HTTP Server (OHS)ターゲットを検索および選択します。「資格証明」フィールドで、ターゲットにアクセスするための資格証明を指定します。複数のOracle HTTP Serverがある場合、「外部ロード・バランサURL」を指定する必要があります。
外部ロード・バランサのURLの形式: (http|https://hostname:port)

例: http://wcp-prov.example.com:80

注意:
WebCenterターゲットをプロビジョニングする場合、内部ロード・バランサURLを追加で指定する必要があります。

内部ロード・バランサのURLの形式: (http|https|tcp:// hostname:port)

例: tcp://wcp-prov-ucm.example.com:4444

注意:
プレーンWebLogicドメインをプロビジョニングしている場合、このセクションは表示されません。

14. 「カスタム・スクリプト」セクションで、ソフトウェア・ライブラリにディレクティブとして格納されているスクリプトを選択して、デプロイメント・プロシージャをカスタマイズできます。次のオプションが可能であり、パラメータを含むスクリプトを渡すかどうかを選択できます。

1. 入力パラメータを含むスクリプトを渡すことができます。詳細は、23.4.3.1項を参照してください。
注意: 入力パラメータを渡す場合、「入力ファイル」のデフォルト・オプションの選択を許可していることを確認してください。たとえば、「前処理スクリプト」フィールドで、以前作成したMy Custom Script With Parametersを選択できます。詳細は、「入力パラメータを含むカスタム・スクリプトの格納」を参照してください。次に手順を示します。

サンプル入力プロパティ(input.properties)ファイルの内容を次に示します。

ADMIN_SERVER_LISTEN_ADDRESS=slc01.example.com
ADMIN_SERVER_LISTEN_PORT=7001
ADMIN_PROTOCOL=t3
MIDDLEWARE_HOME=/scratch/usr1/soa/middleware

2. または、入力パラメータを含まないスクリプトを渡すことを選択できます。詳細は、23.4.3.2項を参照してください。
注意: 入力パラメータを渡さない場合、「入力ファイル」オプションの選択を解除する必要があります。たとえば、「前処理スクリプト」フィールドで、以前作成したMy Custom Script Without Parametersを選択できます。詳細は、「入力パラメータを含まないカスタム・スクリプトの格納」を参照してください。次に手順を示します。

次のスクリプトを渡してプロシージャをカスタマイズできます。

- 前処理スクリプト: このスクリプトは、前提条件チェックが終了してからOracleホームまたはWebLogicドメインがデプロイされるまでに実行されます。

- 管理サーバー起動後スクリプト: このスクリプトは、管理サーバーの起動後に実行されます。

- 後処理スクリプト: このスクリプトは、すべての管理対象サーバーの起動後に実行されます。

15. 「次へ」をクリックしてプロシージャをスケジュールします。「発行」をクリックした場合、プロシージャはすぐに実行されるように発行されます。「保存」をクリックしてこれをテンプレートとして保存します。この機能はロックダウンで特に有効です。たとえば、ロックダウンを使用してテンプレートを作成し、オペレータ権限を持つ他のユーザーにわずかな変更のあるテンプレートを複数回実行することを許可する場合です。
「取消」をクリックしてプロシージャ構成を終了します。

16. 発行後、「プロシージャ・アクティビティ」ページからプロビジョニング操作の進行状況を追跡できます。この詳細は、第50章を参照してください。

17. 新しくプロビジョニングしたターゲットを表示するには、「ターゲット」メニューから「ミドルウェア」を選択します。

24 SOAドメインおよびOracleホームのプロビジョニング

この章では、Enterprise Manager Cloud Controlで提供されているMiddlewareプロビジョニング・ソリューションを使用してSOAドメインまたはOracleホームあるいはその両方をプロビジョニングする方法について説明します。

重要:
SOAドメイン/Oracleホームをプロビジョニングする前に、パッチ20046866および20046898をダウンロードして適用する必要があります。

この章では次のトピックについて説明します。

- SOAドメインおよびOracleホームのプロビジョニングの概要

- SOAプロビジョニング後のソース環境および接続先環境

- プロビジョニングでサポートされるSOAのバージョン

- SOAドメインおよびOracleホームのプロビジョニングを開始する前に

- ユースケース1: SOAドメインの初めてのプロビジョニング

- ユースケース2: SOA Oracleホームに基づくプロビジョニング・プロファイルからのプロビジョニング

- ユースケース3: 既存のSOAドメインに基づくプロビジョニング・プロファイルからのクローニング

- ユースケース4: 既存のSOAホームからのプロビジョニング

- ユースケース5: 既存のSOAドメインのスケール・アップ

24.1 SOAドメインおよびOracleホームのプロビジョニングの概要

この項では、Fusion Middlewareデプロイメント・プロシージャを使用してWebLogicドメインおよびミドルウェア・ホームのプロビジョニングに関連する手順の概要を示します。

表24-1 SOAプロビジョニングの概要

ステップ

説明

参照リンク

手順1

ユースケースの選択

この章では、Oracle SOAドメインおよびOracle SOAホームのプロビジョニングに関連するユースケースを示します。ご自身の要件に最適なユースケースを選択してください。

- SOAドメインの初めてのプロビジョニングの詳細は、第24.5項を参照してください。

- SOAホームに基づくプロビジョニング・プロファイルからのプロビジョニングの詳細は、第24.6項を参照してください。

- 既存のSOAドメインからのクローニングの詳細は、第24.7項を参照してください。

- 既存のSOAホームからのプロビジョニングの詳細は、第24.8項を参照してください。

- SOAドメインのスケール・アウトの詳細は、第24.9項を参照してください。

手順2

ミドルウェア・プロファイルをプロビジョニングするための前提条件

Fusion Middlewareデプロイメント・プロシージャを実行する前に、満たす必要があるいくつかの前提条件があります。

SOAドメインまたはホームをプロビジョニングするための前提条件の詳細は、第24.4項を参照してください。

手順3

Fusion Middlewareデプロイメント・プロシージャの実行

このデプロイメント・プロシージャを実行して、WeblogicドメインまたはOracleホームあるいはその両方を正常にプロビジョニングします。

インストール・メディア・プロファイルまたはOracleホーム・プロファイルからのプロビジョニングの詳細は、第23.6項を参照してください。

WebLogicドメイン・プロファイルのプロビジョニングの詳細は、第23.7項を参照してください。

既存のホームからプロビジョニングするには、第23.8項を参照してください。

SOAドメインからスケール・アウトするには、第29項を参照してください。

24.2 SOAプロビジョニング後のソース環境および接続先環境

この項では、プロビジョニング前のソース環境に含まれるミドルウェア・コンポーネントおよびFusion Middlewareのプロビジョニング・デプロイメント・プロシージャの実行後にプロビジョニングされるコンポーネントについて説明します。主に、通常のSOAトポロジを使用して、ここでは2つのユースケースを説明します。最初のユースケースは、インストール・メディアに基づくプロファイルまたはOracleホームに基づくプロファイルで開始し、新しいドメインまたはOracleホームあるいはその両方をプロビジョニングする新しいプロビジョニングです。2番目のユースケースは、既存のSOAドメインのクローニング方法を説明します。

この項には次のトピックが含まれます:

- 新しいSOAプロビジョニング・ユースケースのソースおよび接続先環境

- SOAクローニング・ユースケースのソースおよび接続先環境

24.2.1 新しいSOAプロビジョニング・ユースケースのソースおよび接続先環境

新しいSOAプロビジョニング・ユースケースの場合、開始する前に、次のトポロジ要件を満たしていることを確認する必要があります。

- Oracle HTTP Serverがインストールおよび検出されています。

- 仮想IPアドレス1および仮想IPアドレス2がすでに予約されています。

- APPHOST1およびAPPHOST2をCloud Controlで検出する必要があります。

- データベースを検出している必要があります。

注意:
Oracle HTTP Server、APPHOST1、APPHOST2およびRACデータベースをCloud Controlで管理対象ターゲットとして監視していることを確認してください。

Fusion Middlewareデプロイメント・プロシージャの実行後、接続先環境の緑色のボックス内に表示されるすべての製品がプロビジョニングされます。

24.2.2 SOAクローニング・ユースケースのソースおよび接続先環境

SOAクローニング・ユースケースの場合、開始する前に次のトポロジ要件を満たしていることを確認してください。

- Oracle HTTP Serverがインストールおよび検出されています。

- 仮想IPアドレス3および仮想IPアドレス4がすでに予約されています。

- APPHOST3およびAPPHOST4をCloud Controlで検出する必要があります。

- データベースをクローニングおよび検出する必要があります。

- ソース環境をOracle IDで構成する場合、OIDをクローニングおよび検出する必要があります。

注意:
Oracle HTTP Server、APPHOST3、APPHOST4およびRACデータベースをCloud Controlで管理対象ターゲットとして監視していることを確認してください。

クローニングの場合、WLS_SOA1およびWLS_SOA 2はAPPHOST1およびAPPHOST2の一部で、それぞれAPPHOST3およびAPPHOST4にクローニングされます。RAC DBは個別にクローニングされます。

24.3 プロビジョニングでサポートされるSOAのバージョン

次の表にリストされているバージョンは、SOAプロビジョニングをサポートします。

製品

バージョン

Oracleリポジトリ作成ユーティリティ(RCU)

11g

Oracle SOA

11g

24.4 SOAドメインおよびOracleホームのプロビジョニングを開始する前に

ミドルウェア・プロファイルの作成およびこれらのプロファイルからのプロビジョニングを実際に開始する前に注意する事項があります。

特に、この項には次のトピックが含まれます:

- ミドルウェア・ロールの作成および権限の割当て

- ミドルウェア・ターゲットの名前付き資格証明および特権資格証明の設定

- (WebLogicドメインのクローニング・ユースケースにのみ適用可能) データベースのクローニング

24.4.1 ミドルウェア・ロールの作成および権限の割当て

通常のデータ・センターでは、デプロイメント・プロシージャの主なユーザーはデザイナ(主任管理者)およびオペレータです。デプロイメント・プロシージャの権限を使用して、ユーザーは、設計時アクティビティ(プロファイルの作成、プロファイルのアクセス権の付与、プロファイルのロックダウンの作成など)や実行時アクティビティ(ソフトウェア・アプリケーションのプロビジョニングを行うデプロイメント・プロシージャの実行など)を実行できます。

Middlewareプロビジョニングでは、次のロールを持つ管理者を作成する必要があります。

ロール: EMスーパー管理者

表24-2は、Middlewareプロビジョニングの管理者を作成できるロールを示しています。

表24-2 必要なロールを持つ管理者の作成

Enterprise Managerロール

説明

EM_PROVISIONING_DESIGNER

ロールは、プロビジョニング・デザイナ用の権限を持ちます。

EM_PROVISIONING_OPERATOR

ロールは、プロビジョニング・オペレータ用の権限を持ちます。

これらのロールを持つ管理者の作成手順は、第2.4項を参照してください。

24.4.2 ミドルウェア・ターゲットの名前付き資格証明および特権資格証明の設定

通常のオペレーティング・システム・ユーザー・アカウント(Oracle)の名前付き資格証明および特権ユーザー・アカウント(root)の名前付き資格証明を設定してEnterprise Manager Cloud Controlのプロビジョニング・タスクを実行することをお薦めします。

名前付き資格証明の設定手順は、第2.3項を参照してください。

24.4.3 (WebLogicドメインのクローニング・ユースケースにのみ適用可能) データベースのクローニング

ドメインのクローニングと同時にソース・ドメインからデータベースをクローニングしている必要があります。データベースをクローニングするには、Enterprise Managerの管理対象ターゲットとしてソース・データベースを検出する必要があります。この後、ソース・データベースからプロファイルを作成し、プロファイルをプロビジョニングしてクローニング・プロセスを完了する必要があります。

24.5 ユースケース1: SOAドメインの初めてのプロビジョニング

このユースケースは、Oracle Fusion Middlewareソフトウェアの初めてのインストールおよびWebLogicドメインの初めてのプロビジョニングを実行する方法を説明します。これはデータ・センターに既存のドメインがない場合または既存のドメインに基づいてプロビジョニング・プロファイルからクローニングしない場合に特に役立ちます。次の手順を実行します。

注意:
Windowsマシンを使用してSOAドメインをプロビジョニングする場合、ソースSOAドメインを検出した後、ノード・マネージャを停止し、その場合のみSOAドメイン・プロファイルの作成を続行する必要があります。

1. デザイナ権限(EM_PROVISIONING_DESIGNERロール)でログインして、インストール・メディア・プロファイルを作成します。これを行うには、第23.5.1項に示される手順に従います。

2. (オプション) 前提条件チェックに合格した後に一部のロックダウンを作成してテンプレートとしてプロファイルを保存できます。ミドルウェア製品をプロビジョニングするために複数回同じプロファイルを実行する必要がある場合、これを実行すると役に立ちます。テンプレートとしてプロファイルを保存する付加価値は、オペレータにアクセス権を付与し、オペレータがプロファイルを実行してMiddlewareプロビジョニングを実行できることです。

3. インストール・メディア・プロファイルに基づくミドルウェア・プロファイルをプロビジョニングする前に、第23.4.1項に示されている前提条件を満たしてください。

4. オペレータ権限(EM_PROVISIONING_OPERATOR)でログインします。「デプロイメント・プロシージャ」表からテンプレートを選択して、「起動」をクリックします。
プロファイルからテンプレートを作成しない場合、「Middlewareプロビジョニング」ページの「プロファイル」表からプロファイルを選択して、「プロビジョニング」をクリックできます。

5. インストール・メディアからSOAドメインおよびOracleホームをプロビジョニングするため、第23.6項に示されている手順に従います。

6. 接続先環境の設定をカスタマイズする場合、第23.6.1項に示されている手順に従います。

24.6 ユースケース2: SOA Oracleホームに基づくプロビジョニング・プロファイルからのプロビジョニング

このユースケースは、パッチが適用されている可能性がある既存のOracleホーム(SOA)からゴールド・イメージを作成し、Oracleホーム・プロファイルを使用してこれをプロビジョニングする方法を説明します。これは新しいWebLogicドメインの使用に関係なくOracle Fusion Middlewareソフトウェアをインストールする必要がある場合に特に役立ちます。

1. EM_PROVISIONING_DESIGNERロールでログインして、Oracleホーム(SOA)・プロファイルを作成します。これを行うには、第23.5項に示される手順に従います。

2. Oracleホームに基づいてミドルウェア・プロファイルからプロビジョニングする前に、第23.4.1項に示されている前提条件を満たします。

3. 「Middlewareプロビジョニング」ページの「プロファイル」表からプロファイルを選択して、「プロビジョニング」をクリックします。

4. ドメイン構成のない既存のドメインのOracleホーム(バイナリおよびパッチを使用)のクローンを作成するには、第23.6項に示されている手順に従います。

5. 接続先環境の設定をカスタマイズする場合、第23.6.1項に示されている手順に従います。

24.7 ユースケース3: 既存のSOAドメインに基づくプロビジョニング・プロファイルからのクローニング

このユースケースは、既存のWebLogicドメインに基づいてプロビジョニング・プロファイルからWebLogicドメインをクローニングする方法を説明します。これはOracle Fusion Middlewareソフトウェアをインストールして新しいWebLogicドメインを構成する必要がある場合に特に役立ちます。

1. EM_PROVISIONING_DESIGNERロールでログインして、WebLogicドメイン・プロファイルを作成します。これを行うには、第23.5.3項に示される手順に従います。

2. WebLogicドメイン・プロファイルに基づいてミドルウェア・プロファイルをプロビジョニングする前に、第23.4.2項に示されている前提条件を満たします。

3. 「Middlewareプロビジョニング」ページの「プロファイル」表からプロファイルを選択して、「プロビジョニング」をクリックします。

4. プロファイルからSOAドメインおよびOracleホームをプロビジョニングするため、第23.8項に示されている手順に従います。

5. 接続先環境の設定をカスタマイズする場合、第23.8.1項に示されている手順に従います。

24.8 ユースケース4: 既存のSOAホームからのプロビジョニング

そのままプロビジョニングしたい(プロファイルを作成する必要がない)Oracleホームがある場合、Fusion Middlewareのプロビジョニング・プロシージャのOracleホーム・ソース・ターゲットを選択してこれを実行できます。詳細は、23.7項を参照してください。

24.9 ユースケース5: 既存のSOAドメインのスケール・アップ

SOAドメインをスケール・アップして1つ以上の管理対象サーバーを含むには、Middlewareプロビジョニング・ページの「デプロイメント・プロシージャ」表からミドルウェアのスケール・アップ/スケール・アウト・プロシージャを実行します。詳細は、29項を参照してください。

25 Oracle Service BusドメインおよびOracleホームのプロビジョニング

この章では、OSBまたはOracleホームあるいはその両方をプロビジョニングするためにEnterprise Manager Cloud Controlで提供されるMiddlewareプロビジョニング・ソリューションを使用する方法について説明します。

重要:
OSBドメイン/Oracleホームをプロビジョニングする前に、パッチ20046866をダウンロードして適用する必要があります。

この章では次のトピックについて説明します。

- OSBドメインおよびOracleホームのプロビジョニングの概要

- プロビジョニングでサポートされるOSBのバージョン

- OSBドメインおよびOracleホームのプロビジョニングを開始する前に

- ユースケース1: OSBドメインの初めてのプロビジョニング

- ユースケース2: OSBホームに基づくプロビジョニング・プロファイルからのプロビジョニング

- ユースケース3: 既存のOSBドメインに基づくプロビジョニング・プロファイルからのクローニング

- ユースケース4: 既存のOSBホームからのプロビジョニング

- ユースケース5: 既存のOSBドメインのスケール・アップ

25.1 OSBドメインおよびOracleホームのプロビジョニングの概要

この項では、Fusion Middlewareデプロイメント・プロシージャを使用してWebLogicドメインおよびミドルウェア・ホームのプロビジョニングに関連する手順の概要を示します。

表25-1 OSBプロビジョニングの概要

ステップ

説明

参照リンク

手順1

ユースケースの選択

この章では、OSBドメインおよびOSBホームのプロビジョニングに関連するユースケースを示します。ご自身の要件に最適なユースケースを選択してください。

- OSBドメインの初めてのプロビジョニングの詳細は、第25.4項を参照してください。

- OSBホームに基づくプロビジョニング・プロファイルの詳細は、第25.5項を参照してください。

- 既存のOSBドメインからのクローニングの詳細は、第25.6項を参照してください。

- 既存のOSBホームからのプロビジョニングの詳細は、第25.7項を参照してください。

- OSBドメインのスケール・アウトの詳細は、第25.8項を参照してください。

手順2

ミドルウェア・プロファイルをプロビジョニングするための前提条件

Fusion Middlewareデプロイメント・プロシージャを実行する前に、満たす必要があるいくつかの前提条件があります。

OSBドメインまたはホームをプロビジョニングするための前提条件の詳細は、第25.3項を参照してください。

手順3

Fusion Middlewareデプロイメント・プロシージャの実行

このデプロイメント・プロシージャを実行して、WeblogicドメインまたはOracleホームあるいはその両方を正常にプロビジョニングします。

インストール・メディア・プロファイルまたはOracleホーム・プロファイルからのプロビジョニングの詳細は、第23.6項を参照してください。

WebLogicドメイン・プロファイルのプロビジョニングの詳細は、第23.7項を参照してください。

既存のホームからプロビジョニングするには、第23.8項を参照してください。

OSBドメインからスケール・アウトするには、第29項を参照してください。

25.2 プロビジョニングでサポートされるOSBのバージョン

次の表にリストされているバージョンは、OSBプロビジョニングをサポートします。

製品

バージョン

Oracleリポジトリ作成ユーティリティ(RCU)

11g

Oracle OSB

11g

25.3 OSBドメインおよびOracleホームのプロビジョニングを開始する前に

ミドルウェア・プロファイルの作成およびこれらのプロファイルからのプロビジョニングを実際に開始する前に注意する事項があります。

特に、この項には次のトピックが含まれます:

- ミドルウェア・ロールの作成および権限の割当て

- ミドルウェア・ターゲットの名前付き資格証明および特権資格証明の設定

- (WebLogicドメインのクローニング・ユースケースにのみ適用可能) データベースのクローニング

25.3.1 ミドルウェア・ロールの作成および権限の割当て

通常のデータ・センターでは、デプロイメント・プロシージャの主なユーザーはデザイナ(主任管理者)およびオペレータです。デプロイメント・プロシージャの権限を使用して、ユーザーは、設計時アクティビティ(プロファイルの作成、プロファイルのアクセス権の付与、プロファイルのロックダウンの作成など)や実行時アクティビティ(ソフトウェア・アプリケーションのプロビジョニングを行うデプロイメント・プロシージャの実行など)を実行できます。

Middlewareプロビジョニングでは、次のロールを持つ管理者を作成する必要があります。

ロール: EMスーパー管理者

表25-2は、Middlewareプロビジョニングの管理者を作成できるロールを示しています。

表25-2 必要なロールを持つ管理者の作成

Enterprise Managerロール

説明

EM_PROVISIONING_DESIGNER

ロールは、プロビジョニング・デザイナ用の権限を持ちます。

EM_PROVISIONING_OPERATOR

ロールは、プロビジョニング・オペレータ用の権限を持ちます。

これらのロールを持つ管理者の作成手順は、第2.4項を参照してください。

25.3.2 ミドルウェア・ターゲットの名前付き資格証明および特権資格証明の設定

通常のオペレーティング・システム・ユーザー・アカウント(Oracle)の名前付き資格証明および特権ユーザー・アカウント(root)の名前付き資格証明を設定してEnterprise Manager Cloud Controlのプロビジョニング・タスクを実行することをお薦めします。

名前付き資格証明の設定手順は、第2.3項を参照してください。

25.3.3 (WebLogicドメインのクローニング・ユースケースにのみ適用可能) データベースのクローニング

ドメインのクローニングと同時にソース・ドメインからデータベースをクローニングしている必要があります。データベースをクローニングするには、Enterprise Managerの管理対象ターゲットとしてソース・データベースを検出する必要があります。この後、ソース・データベースからプロファイルを作成し、プロファイルをプロビジョニングしてクローニング・プロセスを完了する必要があります。

25.4 ユースケース1: OSBドメインの初めてのプロビジョニング

このユースケースは、Oracle Fusion Middlewareソフトウェアの初めてのインストールおよびWebLogicドメインの初めてのプロビジョニングを実行する方法を説明します。これはデータ・センターに既存のドメインがない場合または既存のドメインに基づいてプロビジョニング・プロファイルからクローニングしない場合に特に役立ちます。次の手順を実行します。

1. デザイナ権限(EM_PROVISIONING_DESIGNERロール)でログインして、インストール・メディア・プロファイルを作成します。これを行うには、第23.5.1項に示される手順に従います。

2. (オプション) 前提条件チェックに合格した後に一部のロックダウンを作成してテンプレートとしてプロファイルを保存できます。ミドルウェア製品をプロビジョニングするために複数回同じプロファイルを実行する必要がある場合、これを実行すると役に立ちます。テンプレートとしてプロファイルを保存する付加価値は、オペレータにアクセス権を付与し、オペレータがプロファイルを実行してMiddlewareプロビジョニングを実行できることです。

3. インストール・メディア・プロファイルに基づくミドルウェア・プロファイルをプロビジョニングする前に、第23.4.1項に示されている前提条件を満たしてください。

4. オペレータ権限(EM_PROVISIONING_OPERATOR)でログインします。「デプロイメント・プロシージャ」表からテンプレートを選択して、「起動」をクリックします。
プロファイルからテンプレートを作成しない場合、「Middlewareプロビジョニング」ページの「プロファイル」表からプロファイルを選択して、「プロビジョニング」をクリックできます。

5. インストール・メディアからOSBドメインおよびOracleホームをプロビジョニングするため、第23.6項に示されている手順に従います。

6. 接続先環境の設定をカスタマイズする場合、第23.6.1項に示されている手順に従います。

25.5 ユースケース2: OSBホームに基づくプロビジョニング・プロファイルからのプロビジョニング

このユースケースは、パッチが適用されている可能性がある既存のOracleホーム(OSB)からゴールド・イメージを作成し、Oracleホーム・プロファイルを使用してこれをプロビジョニングする方法を説明します。これは新しいWebLogicドメインの使用に関係なくOracle Fusion Middlewareソフトウェアをインストールする必要がある場合に特に役立ちます。

1. デザイナ権限(EM_PROVISIONING_DESIGNERロール)でログインして、Oracleホーム(OSB)・プロファイルを作成します。これを行うには、第23.5.2項に示される手順に従います。

2. Oracleホームに基づくミドルウェア・プロファイルをプロビジョニングする前に、第23.4.1項に示されている前提条件を満たします。

3. 「Middlewareプロビジョニング」ページの「プロファイル」表からプロファイルを選択して、「プロビジョニング」をクリックします。

4. ドメイン構成のない既存のドメインのOracleホーム(バイナリおよびパッチを使用)のクローンを作成するには、第23.6項に示されている手順に従います。

5. 接続先環境の設定をカスタマイズする場合、第23.6.1項に示されている手順に従います。

25.6 ユースケース3: 既存のOSBドメインに基づくプロビジョニング・プロファイルからのクローニング

このユースケースは、既存のWebLogicドメインに基づいてプロビジョニング・プロファイルからWebLogicドメインをクローニングする方法を説明します。これはOracle Fusion Middlewareソフトウェアをインストールして新しいWebLogicドメインを構成する必要がある場合に特に役立ちます。

1. デザイナ権限(EM_PROVISIONING_DESIGNERロール)でログインして、WebLogicドメイン・プロファイルを作成します。これを行うには、第23.5.3項に示される手順に従います。

2. WebLogicドメイン・プロファイルに基づいてミドルウェア・プロファイルをプロビジョニングする前に、第23.4.2項に示されている前提条件を満たします。

3. 「Middlewareプロビジョニング」ページの「プロファイル」表からプロファイルを選択して、「プロビジョニング」をクリックします。

4. プロファイルからOSBドメインおよびOracleホームをプロビジョニングするため、第23.8項に示されている手順に従います。

5. 接続先環境の設定をカスタマイズする場合、第23.8.1項に示されている手順に従います。

25.7 ユースケース4: 既存のOSBホームからのプロビジョニング

そのままプロビジョニングしたい(プロファイルを作成する必要がない)Oracleホームがある場合、Fusion Middlewareのプロビジョニング・プロシージャのOracleホーム・ソース・ターゲットを選択してこれを実行できます。詳細は、23.7項を参照してください。

25.8 ユースケース5: 既存のOSBドメインのスケール・アップ

OSBドメインをスケール・アップして1つ以上の管理対象サーバーを含むには、Middlewareプロビジョニング・ページの「デプロイメント・プロシージャ」表からミドルウェアのスケール・アップ/スケール・アウト・プロシージャを実行します。詳細は、29項を参照してください。

26 Oracle WebCenterドメインおよびOracleホームのプロビジョニング

この章では、Enterprise Manager Cloud Controlで提供されているMiddlewareプロビジョニング・ソリューションを使用してWebCenterドメインまたはOracleホームあるいはその両方をプロビジョニングする方法について説明します。

この章では次のトピックについて説明します。

- WebCenterドメインおよびOracleホームのプロビジョニングの概要

- Enterprise ManagerでサポートされるWebCenterトポロジについて

- プロビジョニングでサポートされるWebCenterのバージョン

- WebCenterプロビジョニング後のソース環境および接続先環境

- WebCenterドメインおよびOracleホームのプロビジョニングを開始する前に

- ユースケース1: ロックダウンを使用したWebCenter Portalの初めてのプロビジョニング

- ユースケース2: WebCenterホームのプロビジョニング

- ユースケース3: 既存のWebCenter Portal環境のクローニング

- ユースケース4: 既存のWebCenterホームからのプロビジョニング

- ユースケース5: 既存のWebCenterドメインのスケール・アップ

26.1 WebCenterドメインおよびOracleホームのプロビジョニングの概要

この項では、Fusion Middlewareデプロイメント・プロシージャを使用してWebLogicドメインおよびミドルウェア・ホームのプロビジョニングに関連する手順の概要を示します。

表26-1 WebCenterプロビジョニングの概要

ステップ

説明

参照リンク

手順1

ユースケースの選択

この章では、WebCenterドメインおよびWebCenterホームのプロビジョニングに関連するユースケースを示します。ご自身の要件に最適なユースケースを選択してください。

- WebCenterドメインの初めてのプロビジョニングの詳細は、第26.6項を参照してください。

- WebCenterホームに基づくプロビジョニング・プロファイルからのプロビジョニングの詳細は、第26.7項を参照してください。

- 既存のWebCenterドメインからのクローニングの詳細は、第26.8項を参照してください。

- 既存のWebCenterホームからのプロビジョニングの詳細は、第26.9項を参照してください。

- WebCenterドメインのスケール・アウトの詳細は、第26.10項を参照してください。

手順2

ミドルウェア・プロファイルをプロビジョニングするための前提条件

Fusion Middlewareデプロイメント・プロシージャを実行する前に、満たす必要があるいくつかの前提条件があります。

WebCenterドメインまたはホームをプロビジョニングするための前提条件の詳細は、第26.5項を参照してください。

手順3

Fusion Middlewareデプロイメント・プロシージャの実行

このデプロイメント・プロシージャを実行して、WeblogicドメインまたはOracleホームあるいはその両方を正常にプロビジョニングします。

インストール・メディア・プロファイルまたはOracleホーム・プロファイルからのプロビジョニングの詳細は、第23.6項を参照してください。

WebLogicドメイン・プロファイルのプロビジョニングの詳細は、第23.7項を参照してください。

既存のホームからプロビジョニングするには、第23.8項を参照してください。

WebCenterドメインからスケール・アウトするには、第29項を参照してください。

26.2 Enterprise ManagerでサポートされるWebCenterトポロジについて

Oracle WebCenter PortalプロビジョニングがEnterprise Manager Cloud Controlからサポートされるようになりました。

主に、次の使用例がサポートされています。

表26-2 WebCenterプロビジョニングのユースケース

タスク

説明

1. WebCenterプロビジョニング - フレッシュ・インストール

このユースケースは、新しい基本的なWebCenter (Oracle WebCenter Portal + Oracle WebCenter Content)環境をプロビジョニングする場合に役立ちます。

2. WebCenterプロビジョニング - クローニング (同種)

このユースケースは、WebCenter環境(Oracle WebCenter Portal + Oracle WebCenter Content)をすでにインストールし、後でその環境からコピー/クローニングする場合に役立ちます。

次のトポロジは、WebCenterをプロビジョニングするためにサポートされます。

表26-3 WebCenterのサポートされるトポロジ

トポロジ

コンポーネント

外部コンポーネント

1

開発トポロジ

WCP、WCC、OHS、DB、組込みLDAP、SAML/SSO

DB、OHS

2

製品トポロジ(HA)

WCP、WCC、DB、OHS、LBR、SES、LDAP w/SSO

DB、OHS、OTD、SES、LDAP

開発トポロジ詳細

開発トポロジは、次のトポロジ定義と一貫性がある単一ノード環境のみサポートします。

製品トポロジ詳細

製品トポロジは、マルチノード・クラスタ環境をサポートします。これは、クラスタごとに多くのノードを選択できることを意味します。プロビジョニング後、クラスタのノード数を再構成することもできます。

26.3 WebCenterプロビジョニング後のソース環境および接続先環境

この項では、ソース環境に含まれる可能性がある内容とFusion Middlewareデプロイメント・プロシージャの実行後にプロビジョニングされる内容について説明します。表示される2つのトポロジを確認できます。最初のトポロジは、インストール・メディアに基づくプロファイルまたはOracleホームに基づくプロファイルで開始してプロビジョニングする新しいプロビジョニング・ユースケースです。2番目は、既存のドメインのコピーを作成するクローニング・トポロジです。

この項には次のトピックが含まれます:

- 新しいWebCenterプロビジョニング・ユースケースのソースおよび接続先環境

- WebCenterクローニング・ユースケースのソースおよび接続先環境

26.3.1 新しいWebCenterプロビジョニング・ユースケースのソースおよび接続先環境

開始する前に、次のトポロジ要件を満たしていることを確認してください。

- Oracle HTTP Serverをインストールおよび検出している必要があります。

- APPHOST1およびAPPHOST2をCloud Controlで検出する必要があります。

- データベースを検出している必要があります。

注意:
Oracle HTTP Server、APPHOST1、APPHOST2およびRACデータベースをCloud Controlで管理対象ターゲットとして監視していることを確認してください。

26.3.2 WebCenterクローニング・ユースケースのソースおよび接続先環境

開始する前に、次のトポロジ要件を満たしていることを確認してください。

- Oracle HTTP Serverをインストールおよび検出しています。

- APPHOST3およびAPPHOST4をCloud Controlで検出する必要があります。

- データベースをクローニングおよび検出する必要があります。

- ソース環境をOracle IDで構成する場合、OIDをクローニングおよび検出する必要があります。

注意:
Oracle HTTP Server、APPHOST3、APPHOST4およびRACデータベースをCloud Controlで管理対象ターゲットとして監視していることを確認してください。

26.4 プロビジョニングでサポートされるWebCenterのバージョン

次の表にリストされているバージョンは、WebCenterプロビジョニングをサポートします。

製品

バージョン

Oracleリポジトリ作成ユーティリティ(RCU)

11g

Oracle WebCenter Portal

11g

Oracle WebCenter Content

11g

26.5 WebCenterドメインおよびOracleホームのプロビジョニングを開始する前に

ミドルウェア・プロファイルの作成およびこれらのプロファイルからのプロビジョニングを実際に開始する前に注意する事項があります。

特に、この項には次のトピックが含まれます:

- ミドルウェア・ロールの作成および権限の割当て

- ミドルウェア・ターゲットの名前付き資格証明および特権資格証明の設定

- (WebLogicドメインのクローニング・ユースケースにのみ適用可能) データベースのクローニング

26.5.1 ミドルウェア・ロールの作成および権限の割当て

通常のデータ・センターでは、デプロイメント・プロシージャの主なユーザーはデザイナ(主任管理者)およびオペレータです。デプロイメント・プロシージャの権限を使用して、ユーザーは、設計時アクティビティ(プロファイルの作成、プロファイルのアクセス権の付与、プロファイルのロックダウンの作成など)や実行時アクティビティ(ソフトウェア・アプリケーションのプロビジョニングを行うデプロイメント・プロシージャの実行など)を実行できます。

Middlewareプロビジョニングでは、次のロールを持つ管理者を作成する必要があります。

ロール: EMスーパー管理者

表26-4は、Middlewareプロビジョニングの管理者を作成できるロールを示しています。

表26-4 必要なロールを持つ管理者の作成

Enterprise Managerロール

説明

EM_PROVISIONING_DESIGNER

ロールは、プロビジョニング・デザイナ用の権限を持ちます。

EM_PROVISIONING_OPERATOR

ロールは、プロビジョニング・オペレータ用の権限を持ちます。

これらのロールを持つ管理者の作成手順は、第2.4項を参照してください。

26.5.2 ミドルウェア・ターゲットの名前付き資格証明および特権資格証明の設定

通常のオペレーティング・システム・ユーザー・アカウント(Oracle)の名前付き資格証明および特権ユーザー・アカウント(root)の名前付き資格証明を設定してEnterprise Manager Cloud Controlのプロビジョニング・タスクを実行することをお薦めします。

名前付き資格証明の設定手順は、第2.3項を参照してください。

26.5.3 (WebLogicドメインのクローニング・ユースケースにのみ適用可能) データベースのクローニング

ドメインのクローニングと同時にソース・ドメインからデータベースをクローニングしている必要があります。データベースをクローニングするには、Enterprise Managerの管理対象ターゲットとしてソース・データベースを検出する必要があります。この後、ソース・データベースからプロファイルを作成し、プロファイルをプロビジョニングしてクローニング・プロセスを完了する必要があります。

26.6 ユースケース1: ロックダウンを使用したWebCenter Portalの初めてのプロビジョニング

このユースケースは、Oracle Fusion Middlewareソフトウェアの初めてのインストールおよびWebLogicドメインの初めてのプロビジョニングを実行する方法を説明します。これはデータ・センターに既存のドメインがない場合または既存のドメインに基づいてプロビジョニング・プロファイルからクローニングしない場合に特に役立ちます。次の手順を実行します。

1. デザイナ権限(EM_PROVISIONING_DESIGNERロール)でログインして、インストール・メディア・プロファイルを作成します。これを行うには、第23.5.1項に示される手順に従います。

2. インストール・メディア・プロファイルに基づくミドルウェア・プロファイルをプロビジョニングする前に、第23.4.1項に示されている前提条件を満たしてください。

3. (オプション) プロファイルのプロビジョニング中に、このデプロイメント・プロシージャですでに入力されている入力からテンプレートを作成できます。このため、選択入力をロックして他のユーザーが将来これらの値を変更することを制限できるEnterprise Managerにより提供されているロックダウン機能を使用する必要があります。たとえば、「ミドルウェア」、「データベース」、「アイデンティティとセキュリティ」および「Web層」セクションに入力された値をロックできます。これらのロックダウンを使用してデプロイメント・プロシージャを保存して、他の管理者は、デフォルトの入力値を活用し、非常に少ない入力でプロシージャを発行できます。

4. オペレータ権限(EM_PROVISIONING_OPERATOR)でログインします。「デプロイメント・プロシージャ」表からテンプレートを選択して、「起動」をクリックします。
プロファイルからテンプレートを作成しない場合、「Middlewareプロビジョニング」ページの「プロファイル」表からプロファイルを選択して、「プロビジョニング」をクリックできます。

5. インストール・メディアからWebCenterドメインおよびOracleホームをプロビジョニングするため、第23.6項に示されている手順に従います。

6. 接続先環境の設定をカスタマイズする場合、第23.6.1項に示されている手順に従います。

26.7 ユースケース2: WebCenterホームのプロビジョニング

このユースケースは、パッチが適用されている可能性がある既存のOracleホーム(WebCenter)からゴールド・イメージを作成し、Oracleホーム・プロファイルを使用してこれをプロビジョニングする方法を説明します。これは新しいWebLogicドメインの使用に関係なくOracle Fusion Middlewareソフトウェアをインストールする必要がある場合に特に役立ちます。

1. デザイナ権限(EM_PROVISIONING_DESIGNERロール)でログインして、Oracleホーム(WebCenter)・プロファイルを作成します。これを行うには、第23.5.2項に示される手順に従います。

2. Oracleホームに基づくミドルウェア・プロファイルをプロビジョニングする前に、第23.4.1項に示されている前提条件を満たします。

3. デザイナ/オペレータ権限でログインして、「Middlewareプロビジョニング」ページの「プロファイル」表からプロファイルを選択して、「プロビジョニング」をクリックします。

4. ドメイン構成のない既存のドメインのOracleホーム(バイナリおよびパッチを使用)のクローンを作成するには、第23.6項に示されている手順に従います。

5. 接続先環境の設定をカスタマイズする場合、第23.6.1項に示されている手順に従います。

26.8 ユースケース3: 既存のWebCenter Portal環境のクローニング

このユースケースは、既存のWebLogicドメインに基づいてプロビジョニング・プロファイルからWebLogicドメインをクローニングする方法を説明します。これはOracle Fusion Middlewareソフトウェアをインストールして新しいWebLogicドメインを構成する必要がある場合に特に役立ちます。

1. デザイナ権限(EM_PROVISIONING_DESIGNERロール)でログインして、WebLogicドメイン・プロファイルを作成します。これを行うには、第23.5.3項に示される手順に従います。

2. WebLogicドメイン・プロファイルに基づいてミドルウェア・プロファイルをプロビジョニングする前に、第23.4.2項に示されている前提条件を満たします。

3. デザイナ/オペレータ権限でログインして、「Middlewareプロビジョニング」ページの「プロファイル」表からプロファイルを選択して、「プロビジョニング」をクリックします。

4. プロファイルからWebCenterドメインおよびOracleホームをプロビジョニングするため、第23.8項に示されている手順に従います。

5. 接続先環境の設定をカスタマイズする場合、第23.8.1項に示されている手順に従います。

26.9 ユースケース4: 既存のWebCenterホームからのプロビジョニング

そのままプロビジョニングしたい(プロファイルを作成する必要がない)Oracleホームがある場合、Fusion Middlewareのプロビジョニング・プロシージャのOracleホーム・ソース・ターゲットを選択してこれを実行できます。詳細は、23.7項を参照してください。

26.10 ユースケース5: 既存のWebCenterドメインのスケール・アップ

WebCenterドメインをスケール・アップして1つ以上の管理対象サーバーを含むには、Middlewareプロビジョニング・ページの「デプロイメント・プロシージャ」表からミドルウェアのスケール・アップ/スケール・アウト・プロシージャを実行します。詳細は、29項を参照してください。

27 EM CLIを使用したMiddlewareプロビジョニング

この章では、Oracleが提供するコマンドライン・オプションのEnterprise Managerコマンドライン・インタフェースを使用してMiddlewareプロファイルを作成、説明、リスト、削除およびカスタマイズする方法について説明します。

この章の具体的な内容は次のとおりです。

- Middlewareプロビジョニング・プロファイルの作成

- EM CLIを使用したプロシージャの発行

- Middlewareプロビジョニング・プロファイルのリスト

- プロビジョニング・プロファイルの説明

- プロビジョニング・プロファイルの削除

27.1 Middlewareプロビジョニング・プロファイルの作成

プロファイルは、ソフトウェア・ライブラリで作成および格納できるテンプレートに似ています。プロファイルが作成されたら、WebLogicドメインおよび/またはOracleホームをプロビジョニングするために何度も起動できます。プロファイルを使用するメリットは、将来のWebLogicインストールを一貫性のある標準構成に確実に準拠させることができる点です。

プロファイルを作成できます。

- WebLogicドメイン・プロファイルの作成

- Oracleホーム・プロファイルの作成

- インストール・メディア・プロファイルの作成

27.1.1 WebLogicドメイン・プロファイルの作成

WebLogicドメインからFusion Middlewareプロビジョニング・プロファイルを作成するには、EM CLI動詞create_fmw_domain_profileを使用します。

emcli create_fmw_domain_profile
-name="Profile Name"
-ref_target="Reference Target Name"
[-description="Profile Description"]
[-oh_cred="Oracle Home Owner Credentials"]
[-includeOh]
[-schedule=
start_time:yyyy/MM/dd HH:mm;
[tz:{java timezone ID}];
[grace_period:xxx];
]

[ ] indicates that the parameter is optional.

Description for the options:

-name
Name of the WebLogic Domain profile.

-ref_target
Name of the reference target used to create the WebLogic Domain profile.

-description
A short description for the WebLogic Domain profile you create.

-oh_cred
Named credential that will be used to access the reference host.
Format: CREDENTIAL_NAME:CREDENTIAL_OWNER.
All operations will be performed on the Administration Server host.
Credentials of the Oracle Home owner on the Administration Server host are required.
If no named credential is provided, then preferred host credentials for the Oracle Home target will be used.

-wls_cred
Named credential used to access the Administration Server. This is an optional parameter.
To pass the credential parameter, enter a name:value pair in the following format:

credential_name:credential_owner.
Where,
Credential_name is the name of the named credential.
Credential_owner is the credentials of the Administrator of the WebLogic Domain.
All operations are performed in online mode (using T2P) in case of a Fusion Middleware domain.
If no named credential is provided, the preferred administrator credentials for the domain target will be used.

-includeOh
Whether the Oracle Home binaries have to be included in the profile or not.

-schedule
The schedule for the Deployment Procedure.
If not specified, the procedure will be executed immediately.
start_time: when the procedure should start.
tz: the timezone ID.
grace_period: grace period in minutes.

次の例では、WebLogicドメイン・プロファイルの作成方法を説明します。

- BitlessDomainProfileという名前のWebLogicドメインは、指定されたスケジュールの参照ターゲット/Farm01_base_domain/base_domainを使用して作成されます。Oracleホーム・パラメータが渡されないため、Oracleホーム・バイナリのないプレーンWebLogicドメインが作成されます。また、Oracleホーム資格証明が指定されていないため、ターゲット・ホームの優先ホスト資格証明が使用されます。

emcli create_fmw_domain_profile
-name="BitlessDomainProfile"
-ref_target="/Farm01_base_domain/base_domain"
-description="A domain profile without software bits"
-schedule="start_time:2014/6/21 21:23;tz:America/New_York;grace_period:60"

- DomainProfilewithBitsという名前のWebLogicドメイン・プロファイルがOracleホーム・バイナリとともに即座に作成されます。指定された名前付き資格証明を使用して、このプロファイルが参照ターゲット/Farm01_base_domain/base_domainから作成されます。

emcli create_fmw_domain_profile
-name="DomainProfileWithBits"
-ref_target="/Farm01_base_domain/base_domain"
-oh_cred="MY_HOST_CRED:SYSMAN"
-includeMWH

- Fusion Middleware Provisioning/Profilesディレクトリのソフトウェア・ライブラリに作成されます。スケジュールが示されていないため、ジョブが即座に実行されます。

emcli create_fmw_domain_profile
-name=D=SoaProfile
-ref_target="="Farm01_SoaDomain/SoaDomain"

出力:

たとえば、プロファイルが正常に発行された場合に次の属性が表示されます。

- instance_name: 'CreateFmwProfile-SoaProfile_SYSMAN_07_09_2014_11_36_AM'

- instance_guid: 'FDC7FC56E2CF2972E04373B1F00A1512'

注意:
作成中のプロファイルのステータスを追跡するには、次のコマンドを使用します。
emcli get_instance_status -instance=FDC7FC56E2CF2972E04373B1F00A1512 -xml -details -showJobOutput

27.1.2 Oracleホーム・プロファイルの作成

Oracleホーム・ターゲットからFusion Middlewareプロビジョニング・プロファイルを作成するには、EM CLI動詞create_fmw_home_profile_verbを使用します。

emcli create_fmw_home_profile
-name="Profile Name"
-ref_target="Reference Target Name"
[-description="Profile Description"]
[-oh_cred="Oracle Home Owner Credentials"]
[-schedule=
start_time:yyyy/MM/dd HH:mm;
[tz:{java timezone ID}];
[grace_period:xxx];
]

[ ] indicates that the parameter is optional.

Description for the options:
-name
Name of the Oracle home profile.

-ref_target
Name of the Oracle Home target used as reference to create the profile.

-description
A short description for the Oracle home profile you create.

-oh_cred
Named credentials used to access the reference host. This is an optional parameter.
To pass the credential parameter, enter a name:value pair in the following format: credential_name:credential_owner.
Where,
Credential_name is the name of the named credential.
Credential_owner is the credentials of the Oracle home owner on the Administration Server host.
If no named credential is provided, the preferred host credential for the Oracle home target will be used.

-schedule
The schedule for the Deployment Procedure.
If not specified, the procedure will be executed immediately.
To specify a value, enter:
start_time: when the procedure should start.
tz: the timezone ID.
grace_period: grace period in minutes.

次の例では、Oracleホーム・プロファイルの作成方法について説明します。

- Oracleホーム・プロファイルがFusion Middleware Provisioning/Profilesディレクトリのソフトウェア・ライブラリに作成されます。スケジュールが示されていないため、ジョブが即座に実行されます。

emcli  create_fmw_home_profile
-name=SoaProfile
-ref_target="WebLogicServer10_3_6_0_slc00tkv.example.com_6316"

出力:

プロファイルが正常に発行された場合に次の属性が表示されます。

- instance_name: 'CreateFmwProfile-SoaProfile_SYSMAN_07_09_2014_11_36_AM'

- instance_guid: 'FDC7FC56E2CF2972E04373B1F00A1512'

注意:
作成中のプロファイルのステータスを追跡するには、次のコマンドを使用します。
emcli get_instance_status -instance=FDC7FC56E2CF2972E04373B1F00A1512 -xml -details -showJobOutput

- 優先資格証明を使用して指定されたスケジュールで参照ホスト・ターゲットを使用して、OhProfile1という名前のOracleホーム・プロファイルが作成されます。

emcli create_fmw_home_profile
-name="OhProfile1"
-ref_target=""WebLogicServer_10.3.6.0_myhost.example.com_5033""
-description="An Oracle Home profile"
-schedule="start_time:2014/6/21 21:23;tz:America/New_York;grace_period:60"

- 名前付き資格証明を使用して参照ホスト・ターゲットからOhProfile2という名前のOracleホーム・プロファイルが即座に作成されます。

emcli create_fmw_home_profile
-name="OhProfile2" -ref_target="WebLogicServer_11.4.1.0_myhost.example.com_5023"
-oh_cred="MY_HOST_CRED:SYSMAN"

27.1.3 インストール・メディア・プロファイルの作成

Oracle Fusion Middlewareインストール・メディアを使用してプロファイルを作成するには、EM CLI動詞create_inst_media_profile_verbを使用します。

emcli create_inst_media_profile
-name="Profile Name"
-host="Reference Target Name"
-version="Reference Target Name"
-platform="Reference Target Name"
[-description="Profile Description"]
[-host_cred="Oracle Home Owner Credentials"]
-files=
WebLogic:WLSFile1;
SOA:SOAFile1,SOAFile2;
OSB:OSBFile;
RCU:RCUFile;

[ ] indicates that the parameter is optional.

Description for the options:
-name
Name of the installation media profile.

-host
Name of the host target where the installation media files are stored.

-version
Version of the installation media files.

-platform
Platform for which the installation media is applicable.

-description
A short description for the installation media profile.

-host_cred
Named credentials used to access the reference host. This is an optional parameter. To pass the credential parameter, enter a name:value pair in the following format: credential_name:credential_owner.
Where,
Credential_name is the name of the named credential.
Credential_owner is the credentials of the Oracle home owner on the Administration Server host.
If no named credential is provided, the preferred host credential for the host target will be used.
.
-files
List of files that have to be uploaded to Software Library. These files are passed in the format product:file1,file2. The Installation Media profile supports the following products: WebLogic, SOA, OSB, and RCU. Note that, to create any of these profiles, you must upload the WebLogic media file.

次の例では、Oracleホーム・プロファイルの作成方法について説明します。

- ホストmyhost.example.comからwls1036_generic.jarという名前のWebLogic jarファイルを含むWebLogic1036Installerという名前のインストール・メディア・プロファイルをソフトウェア・ライブラリにアップロードします。また、インストール・メディア・ファイルのプラットフォームおよびバージョン詳細を指定する必要があります。パラメータとして資格証明を渡さなかったため、優先ホスト資格証明を使用してWebLogic jarファイルにアクセスします。

emcli create_inst_media_profile
-name="WebLogic1036Installer"
-host="myhost.example.com"
-description="WebLogic Server 10.3.6.0 installer"
-version="10.3.6.0"
-platform="Generic"
-files="WebLogic:/u01/media/weblogic/wls1036_generic.jar"

- ホストmyhost.example.comからSOAおよびWLSインストール・メディア・ファイルをソフトウェア・ライブラリにアップロードします。また、インストール・メディア・ファイルのプラットフォームおよびバージョン詳細を指定する必要があります。指定された名前付き資格証明を使用して、SOA+WLSInstallerという名前のプロファイルが作成されます。

emcli create_inst_media_profile
-name="SOA+WLSInstaller"
-host="myhost.example.com"
-description="SOA 11.1.1.7.0 and WebLogic Server 10.3.6.0 installer"
-version="11.1.1.7.0"
-platform="Generic"
-host_cred="MY_HOST_CRED:SYSMAN"
-files="WebLogic:/u01/media/weblogic/wls1036_generic.jar;SOA:/u01/media/soa/soa1.zip,/u01/media/soa/soa2.zip"

- Oracleホーム・プロファイルがFusion Middleware Provisioning/Profilesディレクトリのソフトウェア・ライブラリに作成されます。スケジュールが示されていないため、ジョブが即座に実行されます。

emcli  create_inst_media_profile
-name="WebCenter Install Media"
-host=slc03qtn.example.com
-description="WC 11.1.1.8.0 and WebLogic Server 10.3.6.0 installer and RCU"
-version="11.1.1.8.0"
-platform="2000"
-host_cred="BBANTHIA:SYSMAN"
-files="WebLogic:/net/adcnas438/export/emgpqa/provisioning/fmwprov/linux64/shiphomes/upinsmed_wls/wls1036_generic.jar;WCP:/net/slcnas478/export/farm_em_repos/emgpqa/provisioning/fmwprov/linux64/shiphomes/wcp_11.1.1.8.0/wc.zip;WCC:/net/slcnas478/export/farm_em_repos/emgpqa/provisioning/fmwprov/linux64/shiphomes/wcc_11.1.1.8.0/ecm_main1.zip,/net/slcnas478/export/farm_em_repos/emgpqa/provisioning/fmwprov/linux64/shiphomes/wcc_11.1.1.8.0/ecm_main2.zip;RCU:/net/slcnas478/export/farm_em_repos/emgpqa/provisioning/fmwprov/linux64/shiphomes/wcrcu_11.1.1.8.0/rcuHome.zip"

27.2 EM CLIを使用したプロシージャの発行

コマンドラインを使用してプロビジョニングのプロセスを自動化するには、Enterprise Managerコマンドライン・インタフェース(EMCLI)・ユーティリティを使用してプロシージャを発行します。EMCLIにより、各種オペレーティング・システムのテキスト・ベースのコンソール(シェルおよびコマンド・ウィンドウ)からEnterprise Manager Cloud Control機能にアクセスできます。Enterprise Manager機能は、SQL*Plus、OSのシェル、Perl、Tclなどのカスタム・スクリプトを使用して呼び出すことができるため、社内のビジネス・プロセスとの統合も容易です。

27.3 Middlewareプロビジョニング・プロファイルのリスト

この項では、Enterprise Managerで作成したすべてのFusion Middlewareプロビジョニング・プロファイルをリストする方法について説明します。

この項では、特に次の内容を説明します。

- すべてのプロファイルのリスト

- すべてのWebLogicドメイン・プロファイルのリスト

- すべてのOracleホーム・プロファイルのリスト

- すべてのインストール・メディア・プロファイルのリスト

27.3.1 すべてのプロファイルのリスト

すべてのFusion Middlewareプロファイルをリストするには、次のコマンドを実行します。

emcli list_fmw_profiles
[-source_type="Profile Source"]

Description for the options:
-source_type
Valid values: weblogic_domain, oracle_home or install_media.
Profiles of only this type as source will be shown.

次の例では、Oracleホーム・プロファイルの作成方法について説明します。

- すべてのMiddlewareプロビジョニング・プロファイルをリストするには、次のコマンドを実行します。

emcli list_fmw_profiles

出力:

ロケーション

製品

プラットフォーム

バージョン

所有者

Fusion Middleware Provisioning/Profiles/SoaBitlessProfile

Oracle SOA

Linux x86-64

10.3.6.0

SYSMAN

Fusion Middleware Provisioning/Profiles/SoaGoldImage

Oracle SOA

Linux x86-64

10.3.6.0

SYSMAN

Fusion Middleware Provisioning/Profiles/WebCenter Install Media

Oracle WebCenter Content

汎用プラットフォーム

11.1.1.8.0

SYSMAN

27.3.2 すべてのWebLogicドメイン・プロファイルのリスト

すべてのWebLogicドメイン・プロファイルをリストするには、次のコマンドを実行します。

emcli list_fmw_profiles
[-source_type="Profile Source"]

Description for the options:
-source_type
Valid values: weblogic_domain, oracle_home or install_media.
Profiles of only this type as source will be shown.

次の例では、Oracleホーム・プロファイルの作成方法について説明します。

- すべてのWebLogicドメイン・プロビジョニング・プロファイルをリストするには、次のコマンドを実行します。

emcli list_fmw_profiles
-source_type=weblogic_domain

出力:

ロケーション

製品

プラットフォーム

バージョン

所有者

Fusion Middleware Provisioning/Profiles/SoaBitlessProfile

Oracle SOA

Linux x86-64

10.3.6.0

SYSMAN

27.3.3 すべてのOracleホーム・プロファイルのリスト

すべてのOracleホーム・プロファイルをリストするには、次のコマンドを実行します。

emcli list_fmw_profiles
[-source_type="Profile Source"]

Description for the options:
-source_type
Valid values: weblogic_domain, oracle_home or install_media.
Profiles of only this type as source will be shown.

次の例では、Oracleホーム・プロファイルの作成方法について説明します。

- すべてのWebLogicドメイン・プロビジョニング・プロファイルをリストするには、次のコマンドを実行します。

emcli list_fmw_profiles
-source_type=oracle_home

出力:

ロケーション

製品

プラットフォーム

バージョン

所有者

Fusion Middleware Provisioning/Profiles/SoaGoldImage

Oracle SOA

Linux x86-64

10.3.6.0

SYSMAN

27.3.4 すべてのインストール・メディア・プロファイルのリスト

すべてのOracleホーム・プロファイルをリストするには、次のコマンドを実行します。

emcli list_fmw_profiles
[-source_type="Profile Source"]

Description for the options:
-source_type
Valid values: weblogic_domain, oracle_home or install_media.
Profiles of only this type as source will be shown.

次の例では、Oracleホーム・プロファイルの作成方法について説明します。

- すべてのWebLogicドメイン・プロビジョニング・プロファイルをリストするには、次のコマンドを実行します。

emcli list_fmw_profiles
-source_type=install_media

出力:

ロケーション

製品

プラットフォーム

バージョン

所有者

Fusion Middleware Provisioning/Profiles/WebCenter Install Media

Oracle WebCenter Content

汎用プラットフォーム

11.1.1.8.0

SYSMAN

27.4 プロビジョニング・プロファイルの記述

Cloud Controlで作成したFusion Middlewareプロビジョニング・プロファイルのサマリーを表示するには、次のコマンドを実行します。

使用方法:

emcli describe_fmw_profile
-location="Profile Location

Description for the options:
-location
Complete Software Library path to the Profile.
Use list_fmw_profiles to know the complete path.

この項では、特に次の内容を説明します。

- WebLogicドメイン・プロファイルの説明

- Oracleホーム・プロファイルの説明

- インストール・メディア・プロファイルの説明

27.4.1 WebLogicドメイン・プロファイルの説明

WebLogicドメイン・プロファイルのサマリーを表示するには、次のコマンドを実行します。

使用方法:

emcli describe_fmw_profile
-location="Fusion Middleware Provisioning/Profiles/SoaBitlessProfile"

Output
Location: Fusion Middleware Provisioning/Profiles/SoaBitlessProfile
Created By: SYSMAN
Created On: Sun, 6 Jul 2014
URN: oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FD8AEF47A15C0874E04373B1F00AEC31:0.1

添付ファイル:

名前

サイズ

コンテンツ・タイプ

追加者

追加日

nmMovePlan.xml

6.95KB

text/plain

SYSMAN

2014年7月6日日曜日

mdm-url-resolver.xml

268バイト

text/plain

SYSMAN

2014年7月6日日曜日

domainMovePlan.xml

56.91KB

text/plain

SYSMAN

2014年7月6日日曜日

Source: WebLogic Domain
Oracle Home Included: No
Node Manager Included: Yes
Platform: Linux x86-64
Version: 10.3.6.0

Oracleホーム:

Product: Oracle SOA
Version: 11.1.1.7.0

WebLogicドメイン:

Domain Name: SoaDomain
Size: 611.45 MB
Products: Oracle SOA

名前

ホスト

リスニング・アドレス

ポート・マシン

クラスタ

最大ヒープ

平均CPU使用率

AdminServer

slc00tkv.example.com

slc00tkv.example.com

7001 LocalMachine

1365

0.361

Soa_server1

slc00tkv.example.com

slc00tkv.example.com

8001LocalMachine

cluster_soa

1365

0.717

データソース:

名前

ユーザー名

URL

ターゲット

EDNDataSource

SOA_SOAINFRA

jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com

cluster_soa

EDNLocalTxDataSource

SOA_SOAINFRA

jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com

cluster_soa

OraSDPMDataSource

SOA_SOAINFRA

jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com

cluster_soa

OraSDPMDataSource

SOA_SOAINFRA

jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com

cluster_soa

SOALocalTxDataSource

SOA_SOAINFRA

dbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com

cluster_soa

mds-owsm

SOA_MDS

jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com

cluster_soa

mds-soa

SOA_MDS

jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com

cluster_soa

JMSサーバー:

名前

永続ストア

ディレクトリ

ターゲット

BPMJMSServer_auto_1

BPMJMSFileStore_auto_1

UMSJMSFileStore_auto_1

soa_server1

PS6SOAJMSServer_auto_1

PS6SOAJMSFileStore_auto_1

UMSJMSFileStore_auto_1

soa_server1

SOAJMSServer_auto_1

SOAJMSFileStore_auto_1

SOAJMSFileStore_auto_1

soa_server1

UMSJMSServer_auto_1

UMSJMSFileStore_auto_1

UMSJMSFileStore_auto_1

soa_server1

27.4.2 Oracleホーム・プロファイルの説明

Oracleホーム・プロファイルのサマリーを表示するには、次のコマンドを実行します。

使用方法:

emcli describe_fmw_profile
-location="Fusion Middleware Provisioning/Profiles/SoaGoldImage"

Output
Location: Fusion Middleware Provisioning/Profiles/SoaGoldImage
Created By: SYSMAN
Created On: Tue, 8 Jul 2014
URN: oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FDB228F176CA1B47E04373B1F00AF708:0.1
Source: Oracle Home
Platform: Linux x86-64
Version: 10.3.6.0

Oracleホーム:

Product: Oracle SOA
Version: 11.1.1.7.0

27.4.3 インストール・メディア・プロファイルの説明

インストール・メディア・プロファイルのサマリーを表示するには、次のコマンドを実行します。

使用方法:

emcli describe_fmw_profile
-location="Fusion Middleware Provisioning/Profiles/WebCenter Install Media"

Output:
Location: Fusion Middleware Provisioning/Profiles/WebCenter Install Media
Description: WC 11.1.1.8.0 and WebLogic Server 10.3.6.0 installer and RCU
Created By: SYSMAN
Created On: Sun, 6 Jul 2014
URN: oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_InstallationMedia:FD8AA7EEEEA369A5E04373B1F00AE77C:0.1
Source: Installation Media
Product: Oracle WebCenter
Platform: Generic Platform
Version: 11.1.1.8.0

ファイル:

製品

ファイル

サイズ

Oracle WebCenter Content

ecm_main1.zip
ecm_main2.zip

2.34GB
1.91GB

Oracle RCU

PS6SOAJMSFileStore_auto_1

496.16MB

Oracle WebCenter Portal

SOAJMSFileStore_auto_1

1.96GB

Oracle WebLogic Server

UMSJMSFileStore_auto_1

1,019.01MB

27.5 プロビジョニング・プロファイルの削除

ソフトウェア・ライブラリからFusion Middlewareプロビジョニング・プロファイルを削除するには、次を実行します。

使用方法:

emcli delete_fmw_profile
-location="Profile Location"

Description for the options:
-location
Complete Software Library path to the Profile.
Use list_fmw_profiles to know the complete path.

例:

MyProfileという名前のプロファイルを削除するには、次のコマンドを実行します。

emcli delete_fmw_profile
-location="Fusion Middleware Provisioning/Profiles/MyProfile"

DomainProfileを削除するには、次のコマンドを実行します。

emcli delete_fmw_profile
-location="Fusion Middleware Provisioning/Profiles/DomainProfile"

Output: The profile Fusion Middleware Provisioning/Profiles/DomainProfile has been deleted successfully.

28 REST APIを使用したミドルウェア・プロファイル

この章では、REST APIを使用してミドルウェア・プロファイルを作成、説明、リストおよび削除する方法について説明します。Cloud Controlコンソールからのみ実行可能だったすべての操作がRESTリクエスト/レスポンスの相互作用を使用してサポートされるようになりました。

プロファイルは、ソフトウェア・ライブラリで作成および格納できるテンプレートに似ています。プロファイルが作成されたら、WebLogicドメインおよび/またはOracleホームをプロビジョニングするために何度も起動できます。プロファイルを使用するメリットは、将来のWebLogicインストールを一貫性のある標準構成に確実に準拠させることができる点です。

この章の具体的な内容は次のとおりです。

- Middlewareプロビジョニング・プロファイルの作成

- Middlewareプロビジョニング・プロファイルのリスト

- プロビジョニング・プロファイルの説明

- プロビジョニング・プロファイルの削除

28.1 Middlewareプロビジョニング・プロファイルの作成

この項では、REST APIを使用してEnterprise Manager Cloud Controlでサポートされるプロビジョニング・プロファイルの3つの異なるタイプを作成する方法について説明します。

- WebLogicドメイン・プロファイルの作成

- Oracleホーム・プロファイルの作成

- インストール・メディア・プロファイルの作成

28.1.1 WebLogicドメイン・プロファイルの作成

WebLogicドメインからプロファイルを作成するには、次の手順を実行します。

1. URLのGET操作を実行して、プロファイルを作成するために指定する必要がある入力を表示します。

表28-1 WebLogicドメイン・プロファイルを作成するためのGETリクエスト構成

機能

説明

URL

:/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/create/weblogic_domain

本文

なし

パラメータ/制約

なし

リクエスト・メソッド

GET

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
name: "Name of the profile to be created."
targetName: "Name of the WebLogic Domain target that will be used as reference to create the profile."
description: "[Optional] Description of the profile that will be created."
credential: "[Optional] Named credential that will be used to access the reference host. Format: CREDENTIAL_NAME:CREDENTIAL_OWNER. All operations will be performed on the Administration Server host. Credentials of the Oracle Home owner on the Administration Server host are required. If no named credential is provided, then preferred host credentials for the Oracle Home target will be used."
wlsCredential: "[Optional] Named credential that will be used to access the Administration Server. Format: CREDENTIAL_NAME:CREDENTIAL_OWNER. If no named credential is provided, then preferred administrator credentials for the domain target will be used."
includeOh: "[Optional] Whether the Oracle Home binaries have to be included in the profile or not. Value: true/false"
schedule: "[Optional] The schedule for the Deployment Procedure. If not specified, the procedure will be executed immediately. Format: start_time:yyyy/MM/dd HH:mm; [tz:{java timezone ID}]; [grace_period:xxx];
}

2. 値を更新して、後操作を実行します。

表28-2 WebLogicドメイン・プロファイルを作成するためのPOSTリクエスト構成

機能

説明

URL

em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/create/weblogic_domain

リクエスト・ヘッダー

本文

{
"name":"DomainProfileViaRestAPI",
"targetName":"/Farm01_SoaDomain/SoaDomain",
"credential":"HOSTCRED:SYSMAN",
"description":"Domain Profile",
"includeOh":"false"
}

パラメータ

該当なし

リクエスト・メソッド

POST

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
instanceName: "CreateFmwProfile-DomainProfileViaRest_SYSMAN_07_09_2014_09_47_AM"
instanceGuid: "FDBDDB0C6767690CE04373B1F00A09E8"
executionGuid: "FDBDDB0C676A690CE04373B1F00A09E8"
executionUrl: "http://slc03qtn:7802/em/faces/core-jobs-procedureExecutionTracking?instanceGUID=FDBDDB0C6767690CE04373B1F00A09E8&showProcActLink=yes&executionGUID=FDBDDB0C676A690CE04373B1F00A09E8"
name: "DomainProfileViaRestAPI"
targetName: "/Farm01_SoaDomain/SoaDomain"
description: "Domain Profile"
credential: "HOSTCRED:SYSMAN"
includeOh: "false"
}

28.1.2 Oracleホーム・プロファイルの作成

Oracleホームからプロビジョニング・プロファイルを作成するには、次の手順に従います。

1. URLのGET操作を実行して、プロファイルを作成するために指定する必要がある入力を表示します。

表28-3 Oracleホーム・プロファイルを作成するためのGETリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/create/oracle_home

本文

該当なし

パラメータ/制約

該当なし

リクエスト・メソッド

GET

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
name: "Name of the profile to be created."
targetName: "Name of the Oracle Home target that will be used as reference to create the profile."
description: "[Optional] Description of the profile that will be created."
credential: "[Optional] Named credential that will be used to access the reference host. Format: CREDENTIAL_NAME:CREDENTIAL_OWNER. If no named credential is provided, then preferred host credentials for the Oracle Home target will be used."
schedule: "[Optional] The schedule for the Deployment Procedure. If not specified, the procedure will be executed immediately. Format: start_time:yyyy/MM/dd HH:mm; [tz:{java timezone ID}]; [grace_period:xxx];"
}

2. 値を更新して、後操作を実行します。

表28-4 Oracleホーム・プロファイルを作成するためのPOSTリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/create/oracle_home

本文

{
"name":"OhProfileViaRestAPI",
"targetName":"WebLogicServer10_3_6_0_slc00tkv.example.com_6316",
"credential":"HOSTCRED:SYSMAN",
"description":"OH Profile"
}

パラメータ

該当なし

リクエスト・メソッド

POST

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
instanceName: "CreateFmwProfile-OhProfileViaRestAPI_SYSMAN_07_09_2014_09_54_AM"
instanceGuid: "FDC6776FB9B31CCDE04373B1F00A2B1C"
executionGuid: "FDC6776FB9B61CCDE04373B1F00A2B1C"
executionUrl: "http://slc03qtn:7802/em/faces/core-jobs-procedureExecutionTracking?instanceGUID=FDC6776FB9B31CCDE04373B1F00A2B1C&showProcActLink=yes&executionGUID=FDC6776FB9B61CCDE04373B1F00A2B1C"
name: "OhProfileViaRestAPI"
targetName: "WebLogicServer10_3_6_0_slc00tkv.example.com_6316"
description: "OH Profile"
credential: "HOSTCRED:SYSMAN"
}

28.1.3 インストール・メディア・プロファイルの作成

インストール・メディアからプロビジョニング・プロファイルを作成するには、次の手順に従います。

1. URLのGET操作を実行して、プロファイルを作成するために指定する必要がある入力を表示します。

表28-5 インストール・メディア・プロファイルを作成するためのGETリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/create/install_media

本文

該当なし

パラメータ/制約

該当なし

リクエスト・メソッド

GET

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
name: "Name of the profile to be created."
targetName: "Name of the Host target that where all the installation files are stored."
description: "[Optional] Description of the profile that will be created."
credential: "[Optional] Named credential that will be used to access the files. Format: CREDENTIAL_NAME:CREDENTIAL_OWNER. If no named credential is provided, then normal preferred credentials for the Host target will be used."
platform: "Platform for which the installation media is applicable."
version: "Version of the installation media."
-files: [2]
-0:
{
product: "Product1"
-files: [1]
0:  "file1"
}
-1:
{
product: "Product2"
-files: [2]
0:  "file2"
1:  "file3"
}
}

2. 値を更新して、後操作を実行します。

表28-6 インストール・メディア・プロファイルを作成するためのPOSTリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/create/install_media

本文

{
"name":"ImProfileViaRestAPI",
"targetName":"slc03qtn.example.com",
"platform":"2000",
"version":"11.1.1.8.0",
"credential":"HOSTCRED:SYSMAN",
"description":"IM Profile",
"files":
[
{
"product":"WebLogic",
"files":
[ "/net/adcnas438/export/emgpqa/provisioning/fmwprov/linux64/shiphomes/upinsmed_wls/wls1036_generic.jar"
]
},
{
"product":"WCC",
"files":
[
"/net/slcnas478/export/farm_em_repos/emgpqa/provisioning/fmwprov/linux64/shiphomes/wcc_11.1.1.8.0/ecm_main1.zip",
"/net/slcnas478/export/farm_em_repos/emgpqa/provisioning/fmwprov/linux64/shiphomes/wcc_11.1.1.8.0/ecm_main2.zip"
]
},
{
"product":"WCP",
"files":
[
"/net/slcnas478/export/farm_em_repos/emgpqa/provisioning/fmwprov/linux64/shiphomes/wcp_11.1.1.8.0/wc.zip"
]
}
]
}

パラメータ

該当なし

リクエスト・メソッド

POST

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
instanceName: "CreateFmwProfile-ImProfileViaRestAPI_SYSMAN_07_09_2014_10_07_AM"
instanceGuid: "FDC6BDD54DA70346E04373B1F00A2DBE"
executionGuid: "FDC6BDD54DAA0346E04373B1F00A2DBE"
executionUrl: "http://slc03qtn:7802/em/faces/core-jobs-procedureExecutionTracking?instanceGUID=FDC6BDD54DA70346E04373B1F00A2DBE&showProcActLink=yes&executionGUID=FDC6BDD54DAA0346E04373B1F00A2DBE"
name: "ImProfileViaRestAPI"
targetName: "slc03qtn.example.com"
description: "IM Profile"
credential: "HOSTCRED:SYSMAN"
platform: "2000"
version: "11.1.1.8.0"
-files: [3]
-0:
{
product: "WebLogic"
-files: [1]
0:"/net/adcnas438/export/emgpqa/provisioning/fmwprov/linux64/shiphomes/upinsmed_wls/wls1036_generic.jar"
}
-1:
{
product: "WCC"
-files: [2]
0: "/net/slcnas478/export/farm_em_repos/emgpqa/provisioning/fmwprov/linux64/shiphomes/wcc_11.1.1.8.0/ecm_main1.zip"
1: "/net/slcnas478/export/farm_em_repos/emgpqa/provisioning/fmwprov/linux64/shiphomes/wcc_11.1.1.8.0/ecm_main2.zip"
}
-2:
{
product: "WCP"
-files: [1]
0: "/net/slcnas478/export/farm_em_repos/emgpqa/provisioning/fmwprov/linux64/shiphomes/wcp_11.1.1.8.0/wc.zip"
}
}

28.2 Middlewareプロビジョニング・プロファイルのリスト

この項では、Enterprise Managerで作成したすべてのプロファイルをリストする方法について説明します。サマリーには、各プロファイルの基本リンクが含まれています。このリンクを使用して、APIの説明とともにプロファイルのサマリーを表示できます。この詳細は、第28.3項を参照してください。

特に、この項には次のトピックが含まれます:

- すべてのプロファイルのリスト

- WebLogicドメイン・プロファイルのリスト

- Oracleホーム・プロファイルのリスト

- インストール・メディア・プロファイルのリスト

28.2.1 すべてのプロファイルのリスト

URLのGET操作を実行して、プロファイルを説明するために後で使用できる正規のリンクを取得します。

表28-7 すべてのプロファイルをリスト表示するためのGETリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/list

本文

該当なし

パラメータ/制約

該当なし

リクエスト・メソッド

GET

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
-profiles: [3]
-0:
{
canonicalLink: "http://slc03qtn:7802/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/describe/oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FD8AEF47A15C0874E04373B1F00AEC31:0.1"
location: "Fusion Middleware Provisioning/Profiles/SoaBitlessProfile"
products: "Oracle SOA"
source: "WebLogic Domain"
urn: "oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FD8AEF47A15C0874E04373B1F00AEC31:0.1"
}
-1:
{
canonicalLink: "http://slc03qtn:7802/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/describe/oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FDB228F176CA1B47E04373B1F00AF708:0.1"
location: "Fusion Middleware Provisioning/Profiles/SoaGoldImage"
products: "Oracle SOA"
source: "Oracle Home"
urn: "oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FDB228F176CA1B47E04373B1F00AF708:0.1"
}
-2:
{
canonicalLink: "http://slc03qtn:7802/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/describe/oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_InstallationMedia:FD8AA7EEEEA369A5E04373B1F00AE77C:0.1"
description: "WC 11.1.1.8.0 and WLS 10.3.6.0 installer and RCU"
location: "Fusion Middleware Provisioning/Profiles/WebCenter Install Media"
-products: [2]
0:  "Oracle WebCenter Content"
1:  "Oracle WebCenter Portal"
source: "Installation Media"
urn: "oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_InstallationMedia:FD8AA7EEEEA369A5E04373B1F00AE77C:0.1"
}
}

28.2.2 WebLogicドメイン・プロファイルのリスト

URLのGET操作を実行して、プロファイルを説明するために後で使用できる正規のリンクを取得します。

表28-8 WebLogicドメイン・プロファイルをリストするためのGETリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/list/weblogic_domain

本文

該当なし

パラメータ/制約

該当なし

リクエスト・メソッド

GET

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
-profiles:
{
canonicalLink: "http://slc03qtn:7802/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/describe/oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FD8AEF47A15C0874E04373B1F00AEC31:0.1"
location: "Fusion Middleware Provisioning/Profiles/SoaBitlessProfile"
products: "Oracle SOA"
source: "WebLogic Domain"
urn: "oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FD8AEF47A15C0874E04373B1F00AEC31:0.1"
}
}

28.2.3 Oracleホーム・プロファイルのリスト

URLのGET操作を実行して、プロファイルを説明するために後で使用できる正規のリンクを取得します。

表28-9 Oracleホーム・プロファイルをリストするためのGETリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/list/oracle_home

本文

該当なし

パラメータ/制約

該当なし

リクエスト・メソッド

GET

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
-profiles:
{
canonicalLink: "http://slc03qtn:7802/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/describe/oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FDB228F176CA1B47E04373B1F00AF708:0.1"
location: "Fusion Middleware Provisioning/Profiles/SoaGoldImage"
products: "Oracle SOA"
source: "Oracle Home"
urn: "oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FDB228F176CA1B47E04373B1F00AF708:0.1"
}
}

28.2.4 インストール・メディア・プロファイルのリスト

URLのGET操作を実行して、プロファイルを説明するために後で使用できる正規のリンクを取得します。

表28-10 インストール・メディア・プロファイルをリストするためのGETリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/list/install_media

リクエスト・ヘッダー

認証は必要ですか。

本文

該当なし

パラメータ/制約

該当なし

リクエスト・メソッド

GET

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
-profiles:
{
canonicalLink: "http://slc03qtn:7802/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/describe/oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_InstallationMedia:FD8AA7EEEEA369A5E04373B1F00AE77C:0.1"
description: "WC 11.1.1.8.0 and WLS 10.3.6.0 installer and RCU"
location: "Fusion Middleware Provisioning/Profiles/WebCenter Install Media"
-products: [2]
0:  "Oracle WebCenter Content"
1:  "Oracle WebCenter Portal"
source: "Installation Media"
urn: "oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_InstallationMedia:FD8AA7EEEEA369A5E04373B1F00AE77C:0.1"
}
}

28.3 プロビジョニング・プロファイルの記述

この項では、Enterprise Managerで作成したすべてのプロファイルのサマリーを表示する方法について説明します。このため、リストAPIを実行して、正規のリンクを取得する必要があります。この詳細は、第28.2項を参照してください。

この項では、特に次の内容を説明します。

- WebLogicドメイン・プロファイルの説明

- Oracleホーム・プロファイルの説明

- インストール・メディア・プロファイルの説明

28.3.1 WebLogicドメイン・プロファイルの説明

GET操作のリストAPIから取得される正規のリンクを使用して、選択されたプロファイルのサマリーを表示します。

表28-11 WebLogicドメイン・プロファイルを説明するためのGETリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/describe/oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FD8AEF47A15C0874E04373B1F00AEC31:0.1

リクエスト・ヘッダー

認証は必要ですか。

本文

該当なし

パラメータ/制約

該当なし

リクエスト・メソッド

GET

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
location: "Fusion Middleware Provisioning/Profiles/SoaBitlessProfile"
createdBy: "SYSMAN"
createdOn: "Sun, 6 Jul 2014"
urn: "oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FD8AEF47A15C0874E04373B1F00AEC31:0.1"
-attachments: [3]
-0:
{
fileName: "nmMovePlan.xml"
size: "6.95 KB"
contentType: "text/plain"
addedBy: "SYSMAN"
addedOn: "Sun, 6 Jul 2014"
}
-1:
{
fileName: "mdm-url-resolver.xml"
size: "268 Bytes"
contentType: "text/plain"
addedBy: "SYSMAN"
addedOn: "Sun, 6 Jul 2014"
}
-2:
{
fileName: "domainMovePlan.xml"
size: "56.91 KB"
contentType: "text/plain"
addedBy: "SYSMAN"
addedOn: "Sun, 6 Jul 2014"
}
source: "WebLogic Domain"
oracleHomeIncluded: "No"
nodeManagerIncluded: "Yes"
platform: "Linux x86-64"
wlsVersion: "10.3.6.0"
-oracleHome:
{
-products: [1]
-0:
{
name: "Oracle SOA"
version: "11.1.1.7.0"
}
}
-domain:
{
name: "SoaDomain"
size: "611.45 MB"
-products: [1]
0:  "Oracle SOA"
}
-servers: [2]
-0:
{
name: "AdminServer"
host: "slc00tkv.example.com"
listendAddress: "slc00tkv.example.com"
nonSslPortEnabled: "Yes"
nonSslPort: "7001"
sslPortEnabled: "No"
machine: "LocalMachine"
maxHeap: "1365"
averageCpuUsage(%): "0.361"
}
-1:
{
name: "soa_server1"
host: "slc00tkv.example.com"
listendAddress: "slc00tkv.example.com"
nonSslPortEnabled: "Yes"
nonSslPort: "8001"
sslPortEnabled: "No"
machine: "LocalMachine"
cluster: "cluster_soa"
maxHeap: "1365"
averageCpuUsage(%): "0.717"
}
-dataSources: [7]
-0:
{
name: "EDNDataSource"
schema: "SOA_SOAINFRA"
url: "jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com"
-targets: [1]
0:  "cluster_soa"
}
-1:
{
name: "EDNLocalTxDataSource"
schema: "SOA_SOAINFRA"
url: "jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com"
targets: [1]
0:  "cluster_soa"
}
-2:
{
name: "OraSDPMDataSource"
schema: "SOA_ORASDPM"
url: "jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com"
targets: [1]
0:  "cluster_soa"
}
-3:
{
name: "SOADataSource"
schema: "SOA_SOAINFRA"
url: "jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com"
targets: [1]
0:  "cluster_soa"
}
-4:
{
name: "SOALocalTxDataSource"
schema: "SOA_SOAINFRA"
url: "jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com"
targets: [1]
0:  "cluster_soa"
}
-5:
{
name: "mds-owsm"
schema: "SOA_MDS"
url: "jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com"
targets: [2]
0:  "cluster_soa"
1:  "AdminServer"
}
-6:
{
name: "mds-soa"
schema: "SOA_MDS"
url: "jdbc:oracle:thin:@slc00dbv.example.com:1521/dbv.example.com"
targets: [2]
0:  "cluster_soa"
1:  "AdminServer"
}
-jmsServers: [4]
-0:
{
name: "BPMJMSServer_auto_1"
persistentStore: "BPMJMSFileStore_auto_1"
storeType: "fileStore"
directory: "BPMJMSFileStore_auto_1"
target: "soa_server1"
}
-1:
{
name: "PS6SOAJMSServer_auto_1"
persistentStore: "PS6SOAJMSFileStore_auto_1"
storeType: "fileStore"
directory: "PS6SOAJMSFileStore_auto_1"
target: "soa_server1"
}
-2:
{
name: "SOAJMSServer_auto_1"
persistentStore: "SOAJMSFileStore_auto_1"
storeType: "fileStore"
directory: "SOAJMSFileStore_auto_1"
target: "soa_server1"
}
-3:
{
name: "UMSJMSServer_auto_1"
persistentStore: "UMSJMSFileStore_auto_1"
storeType: "fileStore"
directory: "UMSJMSFileStore_auto_1"
target: "soa_server1"
}
}

28.3.2 Oracleホーム・プロファイルの説明

GET操作のリストAPIから取得される正規のリンクを使用して、選択されたプロファイルのサマリーを表示します。

表28-12 Oracleホーム・プロファイルを説明するためのGETリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/describe/oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FDB228F176CA1B47E04373B1F00AF708:0.1

リクエスト・ヘッダー

認証は必要ですか。

本文

該当なし

パラメータ/制約

該当なし

リクエスト・メソッド

GET

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
location: "Fusion Middleware Provisioning/Profiles/SoaGoldImage"
createdBy: "SYSMAN"
createdOn: "Tue, 8 Jul 2014"
urn: "oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FDB228F176CA1B47E04373B1F00AF708:0.1"
source: "Oracle Home"
platform: "Linux x86-64"
wlsVersion: "10.3.6.0"
-oracleHome:
{
size: "3.51 GB"
-products: [1]
-0:
{
name: "Oracle SOA"
version: "11.1.1.7.0"
}
}
}

28.3.3 インストール・メディア・プロファイルの説明

GET操作のリストAPIから取得される正規のリンクを使用して、選択されたプロファイルのサマリーを表示します。

表28-13 インストール・メディア・プロファイルを説明するためのGETリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/describe/oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_InstallationMedia:FD8AA7EEEEA369A5E04373B1F00AE77C:0.1

リクエスト・ヘッダー

認証は必要ですか。

本文

該当なし

パラメータ/制約

該当なし

リクエスト・メソッド

GET

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

{
location: "Fusion Middleware Provisioning/Profiles/WebCenter Install Media"
description: "WC 11.1.1.8.0 and WebLogic Server 10.3.6.0 installer and RCU"
createdBy: "SYSMAN"
createdOn: "Sun, 6 Jul 2014"
urn: "oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_InstallationMedia:FD8AA7EEEEA369A5E04373B1F00AE77C:0.1"
source: "Installation Media"
product: "Oracle WebCenter"
platform: "Generic Platform"
version: "11.1.1.8.0"
-files: [4]
-0:
{
product: "Oracle WebCenter Content"
size: "2.34 GB"
-files: [2]
-0:
{
fileName: "ecm_main1.zip"
size: "1.91 GB"
}
-1:
{
fileName: "ecm_main2.zip"
size: "437.6 MB"
}
}
-1:
{
product: "Oracle RCU"
size: "496.16 MB"
-files: [1]
-0:
{
fileName: "rcuHome.zip"
size: "496.16 MB"
}
}
-2:
{
product: "Oracle WebCenter Portal"
size: "1.96 GB"
-files: [1]
-0:
{
fileName: "wc.zip"
size: "1.96 GB"
}
}
-3:
{
product: "Oracle WebLogic Server"
size: "1,019.01 MB"
-files: [1]
-0:
{
fileName: "wls1036_generic.jar"
size: "1,019.01 MB"
}
}
}

28.4 プロビジョニング・プロファイルの削除

この項では、Enterprise Managerで作成したプロファイルを削除する方法について説明します。

この項では、特に次の内容を説明します。

- WebLogicドメイン・プロファイルの削除

- Oracleホーム・プロファイルの削除

- インストール・メディア・プロファイルの削除

28.4.1 WebLogicドメイン・プロファイルの削除

GET操作のリストAPIから取得される正規のリンクを使用して、選択されたプロファイルのサマリーを表示します。

表28-14 WebLogicドメイン・プロファイルを削除するためのDELETEリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/describe/oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FD8AEF47A15C0874E04373B1F00AEC31:0.1

リクエスト・ヘッダー

認証は必要ですか。

本文

該当なし

パラメータ/制約

該当なし

リクエスト・メソッド

DELETE

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

削除に成功した後、次の行のようなメッセージが表示される場合があります。

Profile Fusion Middleware Provisioning/Profiles/MyProfile deleted successfully.

28.4.2 Oracleホーム・プロファイルの削除

GET操作のリストAPIから取得される正規のリンクを使用して、選択されたプロファイルのサマリーを表示します。

表28-15 Oracleホーム・プロファイルを削除するためのDELETEリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/describe/oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_FMWBundle:FDB228F176CA1B47E04373B1F00AF708:0.1

リクエスト・ヘッダー

認証は必要ですか。

本文

該当なし

パラメータ/制約

該当なし

リクエスト・メソッド

DELETE

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

削除に成功した後、次の行のようなメッセージが表示される場合があります。

Profile Fusion Middleware Provisioning/Profiles/MyProfile deleted successfully.

28.4.3 インストール・メディア・プロファイルの削除

GET操作のリストAPIから取得される正規のリンクを使用して、選択されたプロファイルのサマリーを表示します。

表28-16 インストール・メディア・プロファイルを削除するためのDELETEリクエスト構成

機能

説明

URL

/em/websvcs/restful/extws/cloudservices/fmw/provisioning/profile/describe/oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_InstallationMedia:FD8AA7EEEEA369A5E04373B1F00AE77C:0.1

リクエスト・ヘッダー

認証は必要ですか。

本文

該当なし

パラメータ/制約

該当なし

リクエスト・メソッド

DELETE

サポート開始リリース

FMW 12.1.0.7

レスポンスの例:

削除に成功した後、次の行のようなメッセージが表示される場合があります。

Profile Fusion Middleware Provisioning/Profiles/MyProfile deleted successfully.

29 Fusion Middlewareドメインのスケール・アップ/スケール・アウト

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用してSOAドメイン、OSBドメイン、WebLogicドメインおよびWebCenterドメインをスケール・アップおよびスケール・アウトする方法について説明します。この章の具体的な内容は次のとおりです。

- 開始

- 前提条件

- 「ミドルウェアのスケール・アップ/スケール・アウト」デプロイメント・プロシージャの実行

- Middlewareのプロビジョニングおよびスケール・アップ/スケール・アウトのベスト・プラクティス

注意:
SOAやOSBなどの複数の製品が構成されたFusion Middlewareドメインの場合、製品を一度に1つずつスケール・アウトする必要があります。SOAクラスタとOSBクラスタなど複数のクラスタを1つのセッションでスケール・アウトしようとすると、プロシージャによって、そのうちの1つの製品固有構成のみが実行されます。

29.1 開始

WebLogicドメインは、単独またはクラスタで動作する一連の管理対象サーバーで構成され、分散リソースを共有します。WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic管理対象サーバーで構成されます。クラスタを構成する複数のサーバー・インスタンスは同じマシン上で実行することも、複数のマシンに配置することもできます。クラスタの能力は、既存のマシン上のクラスタにさらにサーバー・インスタンスを追加することによって、または、新規サーバー・インスタンスをホストするためのマシンをクラスタに追加することによって、強化できます。ドメインのスケール・アップまたはスケール・アウトのデプロイメント・プロシージャを使用すると、ドメインのスケール・アップまたはスケール・アウトを自動的に実行できます。次の操作を実行できます。

- ドメインまたはクラスタにすでに存在するホストに管理対象サーバーを追加またはクローニングすることにより、ドメインをスケール・アップします。

- ドメインまたはクラスタに存在していないホストに管理対象サーバーを追加またはクローニングすることにより、ドメインをスケール・アウトします。

29.2 前提条件

ミドルウェアのスケール・アップまたはスケール・アウトのデプロイメント・プロシージャを実行する前に、この項にリストされた前提条件を満たしている必要があります。

注意:
Middlewareプロビジョニング用のインフラストラクチャの設定方法の詳細は、第23.4項を参照してください。

次の前提条件を満たしてから、WebLogicドメインの拡張を開始してください。

- スケール・アップまたはスケール・アウトするWebLogicドメインは、Cloud Controlで検出された既存のドメインにする必要があります。

- ドメインをスケール・アウトする場合、宛先のマシンに十分な領域があることを確認します。ソース・マシンのMiddlewareホームのサイズが3GBであれば、ソースと宛先マシンの作業ディレクトリに約3GBの空き領域が必要になります。さらに、宛先マシンには、Middlewareホーム用に3GBの領域が必要になります。デプロイメント・プロシージャが正常終了すれば、作業ディレクトリの中は空になります。

- 宛先マシンに指定するMiddlewareホームのディレクトリは、新規ディレクトリか空のディレクトリにする必要があります。

- 管理エージェントが、(管理サーバーが実行されている)ソース・マシンおよび宛先マシンにインストールされている必要があります。ドメインの管理サーバーが起動され、実行されている必要があります。

- 管理サーバーおよび管理対象サーバー(クローニングされるサーバー)は、デプロイメント・プロシージャを実行する前に稼働している必要があります。

- 管理対象サーバーおよびノード・マネージャのポートは、空いている必要があります。

- ドメインをスケール・アウトする場合、ユーザーは、次の権限を持っている必要があります。

- 次の読取り権限:

- 管理サーバーのホスト・ミドルウェア・ディレクトリ

- 管理サーバーのホスト・ドメイン・ディレクトリ

- 次の書込み権限:

- 管理サーバーのホスト作業ディレクトリ

- すべての宛先管理対象サーバー・ホストの作業ディレクトリ

- すべての宛先管理対象サーバー・ホストのミドルウェア・ディレクトリ

- すべての宛先管理対象サーバー・ホストのドメイン・ディレクトリ

- ドメインをスケール・アップする場合、ユーザーは、次の権限を持っている必要があります。

- 次の読取り権限:

- 管理サーバーのホスト作業ディレクトリ

- すべての宛先管理対象サーバー・ホストのドメイン・ディレクトリ

- スケール・アップ/スケール・アウトするドメインは編集モードではない必要があります。このドメインに対して実行されているWebLogicコンソールがあることを確認してください。

- 新しいマネージャ・サーバーを既存のノード・マネージャまたはマシンと関連付けることを選択する場合、ノード・マネージャが稼働中であることを確認してください。稼働中でない場合、デプロイメント・プロシージャは失敗します。

- Oracle HTTP Serverをフロントエンドとして使用する場合、Enterprise Managerで既存のOHSターゲットが検出されていることを確認してください。

29.3 「ミドルウェアのスケール・アップ/スケール・アウト」デプロイメント・プロシージャの実行

WebLogicドメインは、単独またはクラスタで動作する一連の管理対象サーバーで構成され、分散リソースを共有します。WebLogic Serverクラスタは、同時に動作し、連携して高度なスケーラビリティと信頼性を実現する複数のWebLogic管理対象サーバーで構成されます。クラスタを構成する複数のサーバー・インスタンスは同じマシン上で実行することも、複数のマシンに配置することもできます。クラスタの能力は、既存のマシン上のクラスタにさらにサーバー・インスタンスを追加することによって、または、新規サーバー・インスタンスをホストするためのマシンをクラスタに追加することによって、強化できます。

スケール・アップ(またはスケール・アウト)ミドルウェア・ウィザードでは、既存のマシン上のクラスタにサーバー・インスタンスを追加したり、クラスタにマシンを追加して新規のサーバー・インスタンスをホストすることで、クラスタのキャパシティを拡大できます。

注意:
Javaオブジェクト・キャッシュは常に、スケール・アップの前に使用可能であったかどうかに関係なく、スケール・アウトまたはスケール・アップされたMiddleware管理対象サーバーで構成されます。

ドメインをスケール・アップまたはスケール・アウトするには、次の手順を実行します。

1. 前提条件が満たされていることを確認します。29.2項を参照してください。

2. ソース・ドメインを指定する。29.3.1項を参照してください。

3. 新しい管理対象サーバーを追加するか、または既存のサーバーをクローニングする。29.3.2項を参照してください。

4. 選択したOHSを使用してフロントエンドに設定する新規サーバーを追加します。29.3.3項を参照してください。

5. 管理対象サーバーのホスト資格証明およびWebLogicドメイン管理者の資格証明を指定します。29.3.4項を参照してください。

6. 実行されるスケール・アップまたはスケール・アウトの操作を指定する。29.3.5項。

7. 入力を確認し、デプロイメント・プロシージャを発行します。29.3.6項を参照してください。

注意:
WebCenterドメインをスケール・アウトするため、次の手順を手動で実行する必要があります。

1. Oracle HTTP ServerをCloud Controlでインストール、検出、監視する必要があります。また、スケール・アウト・インスタンスに対して構成ファイルを手動で構成する必要があることを確認する必要があります。

2. Spacesサーバーがスケール・アウトする場合、次のコマンドを実行してWebServiceポリシーをアタッチする必要があります。

attachWebServicePolicy(application='WC_Spaces2/webcenter',
moduleName='webcenter', moduleType='web',
serviceName='SpacesWebService',
subjectName='SpacesWebServiceSoapHttpPort',
policyURI='oracle/wss11_saml_token_with_message_protection_service_policy')

3. ディスカッション・サーバーがスケール・アウトする場合、次のコマンドを実行してWebServiceポリシーをアタッチする必要があります。

attachWebServicePolicy(application='WC_Collaboration2/owc_discussions',
moduleName='owc_discussions', moduleType='web',
serviceName='OWCDiscussionsServiceAuthenticated',
subjectName='OWCDiscussionsServiceAuthenticated',
policyURI='oracle/wss10_saml_token_service_policy')

29.3.1 WebLogicドメイン・スケール・アップ: ソースの選択ページ

ドメイン・スケール・アップ/アウトのデプロイメント・プロシージャを使って、ドメインまたはクラスタのスケール・アップやスケール・アウトを自動化できます。次の方法で、既存のWebLogicドメインまたはクラスタ(あるいはその両方)に容量を追加できます。

- 既存のクラスタへの新規管理対象サーバーの属性の追加。

- 既存のクラスタへの新規管理対象サーバーの属性の追加およびコピー。

- 管理対象サーバーのクローニング。ソース・サーバーをクラスタ化する場合、既存の管理対象サーバーをクローニングすると、別の管理対象サーバーが同じクラスタに作成されます。

ウィザードに従って処理を行います。

1. 「ターゲット」メニューから、「ミドルウェア」を選択します。

2. Middlewareターゲットのリストが表示されます。クローニング操作のソースとして使用するWebLogicドメインを見つけます。そのWebLogicドメインを右クリックすると、コンテキスト依存メニューが表示されます。メニューから、「WebLogicドメインのスケール・アップ/スケール・アウト」を選択します。
または、「WebLogicドメイン」リンクをクリックできます。ドメインのホーム・ページの「WebLogicドメイン」メニューから、「プロビジョニング」および「WebLogicドメインのスケール・アップ/スケール・アウト」を選択します。

「WebLogicドメイン・スケール・アップ: ソース」ページが表示されます。

Middlewareプロビジョニング・ページからこれをプロシージャとして起動することもできます。これを行うには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「Middlewareプロビジョニング」を選択します。Middlewareプロビジョニング・ページで、「デプロイメント・プロシージャ」表から「ミドルウェアのスケール・アップ/スケール・アウト」を選択し、「起動」をクリックします。この場合、拡張する必要のあるWebLogicドメインを選択して、ソース情報を指定する必要があります。

3. 「作業ディレクトリ」フィールドで、ドメイン・スケール・アップに関連するファイルを一時的に保存する管理サーバー・マシンのディレクトリを指定します。一時ファイルを保存するには、1GB以上の空き容量が必要です。このディレクトリが存在しない場合は、作成されます。ドメイン・スケール・アップ操作が完了すると、このディレクトリの内容は削除されます。

注意:
ミドルウェア・ホームまたはWebLogicドメイン・ホームのディレクトリの下に、作業ディレクトリを作成しないでください。

4. 「ソース情報」セクションに、ミドルウェア・ホーム、WebLogic Serverホーム、Middlewareドメインの場所を含むソース・ドメインの詳細が表示されます。

5. 「宛先ホストの選択」セクションで、「ホストの追加」をクリックし、管理対象サーバーを追加するホストを選択します。

6. 「次へ」をクリックします。

29.3.2 WebLogicドメイン・スケール・アップ: 管理対象サーバー・ページ

管理対象サーバー・ページでは、次のタスクを実行できます。

- 新規管理対象サーバーの追加

- 既存の管理対象サーバーのクローニング: これを行うには、新規サーバーを追加するホストを選択し、「クローン」をクリックします。このオプションにより、新規管理対象サーバーがドメインに追加され、既存のサーバーから事前決定済の属性セットがコピーされます。
管理対象サーバーの更新の詳細は、「新規管理対象サーバーの追加」を参照してください。

- 管理対象サーバーの削除: これを行うには、管理対象サーバーを選択し、「サーバーの削除」をクリックします。

新規管理対象サーバーの追加

新規管理対象サーバーをWebLogicドメインに追加するには、次の手順に従います。

1. ドメインを選択し、「サーバーの追加」をクリックします。

2. 管理対象サーバー・ページで、新規管理対象サーバーの一意の名前、リスニング・アドレスおよびSSLポートなど、新規管理対象サーバーの構成の詳細を入力します。

3. 「マシンの構成」セクションで、次のいずれかを選択できます。

- マシン(ノード・マネージャ)に関連付けません: このオプションを選択した場合、管理対象サーバーはマシン(ノード・マネージャ)に関連付けられず、ノード・マネージャ・コンソールを使用して管理対象サーバー・ホストを起動できません。

- 既存のマシン(ノード・マネージャ)を使用します: 管理対象サーバーを既存のマシン(ノード・マネージャ)に関連付ける場合は、このオプションを選択します。管理対象サーバーの関連付けの元となるマシンを「マシン名」メニューから選択する必要があります。

- 新規マシン(ノード・マネージャ)を作成します: 新規マシンを作成し、マシン名、ノード・マネージャ・アドレスおよびポート番号を指定する場合は、このオプションを選択します。ノード・マネージャが稼働中および実行中ではない場合、この操作はタイムアウトします。

注意:
Enterprise Manager Cloud Controlから起動と停止のような管理操作を実行する場合は、ノード・マネージャを構成してから、マシンで実行する必要があります。

4. 「管理対象サーバーのキーストアの構成」セクションで、次のいずれかのオプションを選択できます。

1. デフォルトのデモ信頼証明書を使用します。

2. カスタム証明書を使用します: このオプションを選択する場合、すべての「キーストア」フィールドに有効な入力を指定する必要があります。

5. 「ソフトウェア・インストール」セクションの「作業ディレクトリ」フィールドでは、事前に移入されたディレクトリ・パスが使用可能です。これは、スケール・アップに必要なファイルがステージングされるディレクトリへのフルパスです。

29.3.3 WebLogicドメイン・スケール・アップ/WebLogicドメイン・スケール・アウト: Web層

「Web層」ページで、Oracle HTTP Server (OHS)をフロント・エンドとして使用するためのサーバーを追加できます。次の手順を実行します。

1. Web層ページで、「追加」をクリックします。

2. 「ターゲット・セレクタ」ダイアログ・ボックスから、任意のターゲット・サーバーを選択し、「選択」をクリックします。

3. 新しく追加されたOHSコンポーネントが「Web層」表に表示されます。

4. 「次へ」をクリックします。

29.3.4 WebLogicドメイン・スケール・アップ/WebLogicドメイン・スケール・アウト: 資格証明ページ

資格証明ページで、次のタイプの資格証明を設定できます。

- ホスト資格証明: このセクションでは、管理対象サーバーが稼働しているすべてのホストの資格証明を指定する必要があります。これを行うには、各ホストに対して追加アイコンをクリックし、「新規資格証明の追加」ダイアログ・ボックスで有効なユーザー名とパスワードを入力します。ジョブの実行時にターゲットごとにこれらの資格証明が使用されるようにするには、「優先資格証明として設定」チェック・ボックスを選択します。
OHSインスタンスが別のホストで実行されている場合、さらにOHSホストの資格証明を追加する必要があることに注意してください。

- WebLogic管理者資格証明: このセクションでは、WebLogic管理サーバーにアクセスするための資格証明を設定する必要があります。これを行うには、各WebLogicドメインに対して「追加」をクリックし、「新規管理者資格証明の追加」ダイアログ・ボックスで有効な管理者名とパスワードを入力します。ジョブの実行時にターゲットごとにこれらの資格証明が使用されるようにするには、「優先資格証明として設定」チェック・ボックスを選択します。

29.3.5 WebLogicドメイン・スケール・アップ/WebLogicドメイン・スケール・アウト: スケジュール・ページ

スケジュール・ページでデプロイメント・インスタンス名を指定します。プロシージャを即時実行する場合は、デフォルトで選択されている「即時」を選択します。

プロシージャを後で実行する場合は、「後で」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。

デプロイメント・プロシージャのステータスに応じて、通知プリファレンスを設定できます。

前提条件のみを実行する場合、「前提条件チェックの実行後に結果を分析するためにプロシージャを停止します」を選択します。これにより、すべての前提条件チェックを実行した後で、プロシージャの実行が一時停止されます。

「次へ」をクリックします。

29.3.6 WebLogicドメイン・スケール・アップ/WebLogicドメイン・スケール・アウト: 確認ページ

確認ページで、デプロイメント・プロシージャに対して指定した詳細を確認します。詳細に満足した場合は、「発行」をクリックして、設定したスケジュールに従ってプロシージャを実行します。詳細を変更する場合は、そのセクションにある「編集」リンクをクリックして変更するか、または「戻る」のクリックを繰り返して変更したいページに戻ります。

デプロイメント・プロシージャを発行すると、デプロイメント・プロシージャのステータスを見ることができるプロシージャ・アクティビティ・ページに戻ります。デプロイメント・プロシージャが完了すると、新しくクローニングされた環境がEnterprise Manager Cloud Controlの新規ターゲットとして追加され、その他のFusion Middlewareターゲットとともに監視できるようになります。

29.4 Middlewareのプロビジョニングおよびスケール・アップ/スケール・アウトのベスト・プラクティス

この項では、「Middlewareプロビジョニング」デプロイメント・プロシージャの使用時に従う必要のあるベスト・プラクティスのいくつかを示します。

- ソース・ドメインの構成は変更しない: これらのデプロイメント・プロシージャを実行する間は、ソース・ドメインで管理アクティビティ(ソース・ドメインでの構成変更やソフトウェア・パッチ適用など)を実行しないでください。構成を変更すると、管理対象サーバーがリクエストに応答せず、管理サーバーのステータスが「不明」になることがあります。

- 同じマシンでのプロビジョニング: デプロイメント・プロシージャを使用してソースと同じマシンにプロビジョニングまたはスケール・アップする場合、デフォルトでソース・マシンとターゲット・マシンの作業ディレクトリが移入されます。これらの値を変更した場合は、ソース・マシンと宛先マシンの作業ディレクトリを異なるディレクトリにする必要があります。たとえば、ソース・マシンの作業ディレクトリが/tmp/sourceの場合、宛先ディレクトリの作業ディレクトリは/tmp/destのようにします。また、管理サーバーと管理対象サーバーのリスニング・ポート番号およびSSLポート番号(有効になっている場合)をソース・サーバーと宛先サーバーで異なる値にする必要もあります。

- 一意のファーム接頭辞: 「Middlewareプロビジョニング」デプロイメント・プロシージャを使用する際は、必ずファーム接頭辞を一意にします。ファーム接頭辞がドメイン名に追加されて、Cloud Controlで各ドメインが一意に識別されます。

- JDBC構成: JDBCデータソースを構成する際は、データベース・ユーザーとスキーマ所有者が適切なパスワードを入力する必要があります。

- カスタムのJavaアプリケーションおよびそのデプロイメント・プラン: これらのデプロイメント・プロシージャでは、ステージング・モードのカスタムJavaアプリケーションがサポートされています。外部でステージングされたアプリケーションは手動でデプロイする必要があります。手動でのデプロイメント手順は、『WebLogic管理ガイド』を参照してください。

- 複数NICマシン: 宛先マシンが複数NICシステムの場合は、管理サーバーと管理対象サーバーの両方にアクセスできるリスニング・アドレスを入力します。

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

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用してJava EEアプリケーションをデプロイ、アンデプロイおよび再デプロイする方法について説明します。

この章の具体的な内容は次のとおりです。

- Java EEアプリケーションの開始

- Java EEアプリケーションのデプロイ、アンデプロイまたは再デプロイ

- Java EEアプリケーションでサポートされているリリース

- Java EEアプリケーションをデプロイ/アンデプロイするための前提条件

- Java EEアプリケーション・コンポーネントの作成

- 「Java EEアプリケーション」デプロイメント・プロシージャ

30.1 Java EEアプリケーションの概要

この項では、Java EEアプリケーションのデプロイ、再デプロイおよびアンデプロイに関連する手順の概要を示します。「Java EEアプリケーションのデプロイ/アンデプロイ」デプロイメント・プロシージャを使用すると、次の操作を実行できます。

- デプロイ

- アンデプロイ

- 再デプロイ

この項は、Java EEアプリケーションのプロビジョニングを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表30-1 Java EEアプリケーションのデプロイ、アンデプロイまたは再デプロイの概要

ステップ

説明

参照リンク

手順1

デプロイメント・プロシージャの理解

Cloud Controlで提供されている、Java EEアプリケーションをデプロイ、アンデプロイまたは再デプロイするためのデプロイメント・プロシージャについて理解します。デプロイメント・プロシージャの機能や、その対象となるユースケースなどを把握します。

デプロイメント・プロシージャの詳細は、第30.2項を参照してください。

手順2

ユースケースの選択

この章では、Java EEアプリケーションのデプロイ、アンデプロイおよび再デプロイに関連するユースケースを示します。ご自身の要件に最適なユースケースを選択してください。

- Java EEアプリケーションをデプロイするには、第30.6.1項を参照してください。

- Java EEアプリケーションを再デプロイするには、第30.6.2項を参照してください。

- Java EEアプリケーションをアンデプロイするには、第30.6.3項を参照してください。

手順3

前提条件の確認

デプロイメント・プロシージャを実行する前に、ソフトウェア・ライブラリの構成や「Java EEアプリケーションのデプロイ/アンデプロイ」デプロイメント・プロシージャの一部としてプロビジョニングするコンポーネントの作成など、前提条件を満たしていることを確認する必要があります。

Java EEアプリケーションをデプロイ、アンデプロイまたは再デプロイするための前提条件の詳細は、第30.4項を参照してください。

手順4

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行して、1つ以上のJava EEアプリケーションをデプロイ、再デプロイまたはアンデプロイします。

「Java EEアプリケーションのデプロイ/アンデプロイ」デプロイメント・プロシージャを実行するには、第30.6項で説明されている手順を実行します。

30.2 Java EEアプリケーションのデプロイ、アンデプロイまたは再デプロイ

このデプロイメント・プロシージャでは、Java EE仕様に基づいて.ear、.war、.jar、.rarまたは.garファイルとしてパッケージ化されたJava EEアプリケーションのデプロイメントをサポートしています。管理者は、WebLogic ServerやFusion Middleware管理コンソールにドリルダウンしなくても、Cloud Controlを使用して1つ以上のJava EEアプリケーションをデプロイ、再デプロイおよびアンデプロイできるようになりました。Java EEアプリケーションは、Cloud Controlソフトウェア・ライブラリに追加する前に事前構成する必要があります。事前構成されたJava EEアプリケーションは、Cloud Controlの1つ以上のWebLogicドメインにデプロイできます。

Java EEアプリケーション・プロビジョニング・ウィザードでは、GUIを多用した対話形式の画面により、1つ以上のWebLogicドメインから事前構成済のJava EEアプリケーションのデプロイ/再デプロイ、またはアンデプロイが可能です。

30.3 Java EEアプリケーションでサポートされているリリース

このデプロイメント・プロシージャは、WebLogicバージョン10.3.1以上(12.1.1、12.1.2および12.1.3を含む)間でのJava EEアプリケーションのデプロイ、アンデプロイまたは再デプロイに使用できます。

WebLogicバージョン8.xおよび9.xはサポートされていません。

30.4 Java EEアプリケーションをデプロイ/アンデプロイするための前提条件

「Java EEアプリケーションのデプロイ/アンデプロイ」デプロイメント・プロシージャを実行する前に、次の前提条件を満たしていることを確認してください。

- 「ソフトウェア・ライブラリ」が構成されていることを確認します。詳細は第2.2項を参照してください。

- Java EEアプリケーションのコンポーネントは、ソフトウェア・ライブラリ内に作成しておく必要があります。

- 管理エージェントは、Java EEアプリケーションをデプロイ、アンデプロイまたは再デプロイしているWebLogicドメインの管理サーバー・ホスト・マシンにインストールする必要があります。デプロイメント・コマンドは、管理サーバー・ホスト・マシンから実行されます。

- ターゲット実行スクリプトがデプロイメント・プロシージャの一部として実行されている場合、管理エージェントは、ターゲット実行スクリプトが実行されている管理対象サーバーのホスト・マシンにインストールする必要があります。

注意:
ターゲット実行スクリプトは、必要な環境の設定や、プロパティ・ファイルなどの追加ファイル内のトークンの交換に使用できます。このスクリプトは選択したターゲットで実行されます。

- このデプロイメント・プロシージャに必要なプラグインを、宛先マシンの管理エージェントにデプロイする必要があります。

30.5 Java EEアプリケーション・コンポーネントの作成

アーカイブ、デプロイ・プラン、デプロイ前スクリプト、デプロイ後スクリプト、ターゲット実行スクリプト、およびJava EEアプリケーションのデプロイに必要なその他のファイルを含む、Java EEアプリケーション・コンポーネントを作成できます。

注意:
ソフトウェア・ライブラリが構成されているホストにJava EEアプリケーション・コンポーネントを作成する場合、このホスト名および管理エージェント・ホスト名が一致していることを確認する必要があり、一致していない場合は、コンポーネントの作成中に次のエラーが表示されます。

An error was encountered during saving entity samples.gar.
Please see the log for details.
oracle.sysman.emSDK.app.exception.EMSystemException

Java EEアプリケーション・コンポーネントを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「ソフトウェア・ライブラリ」を選択します。

2. フォルダを作成するか、ソフトウェア・ライブラリからフォルダを選択し、「エンティティの作成」→「コンポーネント」を選択します。

3. エンティティの作成: コンポーネント・ダイアログ ボックスから「Java EEアプリケーション」を選択し、「続行」をクリックします。

4. Java EEアプリケーションの作成: 説明ページで、「名前」と「説明」を入力し、「次へ」をクリックします。

5. Java EEアプリケーションの作成: ファイルの選択ページで、Java EEアプリケーションと関連付ける1つまたは複数のファイルを選択します。ソフトウェア・ライブラリ記憶域の場所から、ファイルをアップロードできます。ソフトウェア・ライブラリを使用可能にするには、少なくとも1つのアップロード・ファイルの場所が構成されている必要があります。「宛先の指定」セクションで、「アップロード場所」フィールドの「参照」ボタンをクリックします。次のいずれかを選択します。

- OMS共有ファイル・システム: OMS共有ファイル・システムの場所は、すべてのOracle Management Server(OMS)ホスト間で共有(またはマウント)されている必要があります。このオプションはUNIXシステムに最適です。
OMS環境が1つのみの場合、OMSが実行されているホスト上にも共有場所にもソフトウェア・ライブラリを構成することにより、すべてのOMS環境からソフトウェア・ライブラリにアクセスできるように構成できます。OMS環境が複数ある場合、ソフトウェア・ライブラリを共有場所に構成することにより、NFSマウント・ポイントを通じて環境内のすべてのOracle Management Serverから記憶域にアクセスできるようにすることをお薦めします。

- OMSエージェント・ファイル・システム: OMSエージェント・ファイル・システムの場所は、OMSホストのエージェントの1つからアクセスできる場所です。このオプションは、WindowsホストにインストールされたOMSに最適です。ファイルのアップロード用としてこのオプションを選択することにより、参加しているすべてのOMSホスト間で場所を共有しなくてすむようになります。
OMS共有ファイル・システムまたはOMSエージェント・ファイル・システムを使用する前に資格証明を設定する必要があります。OMS共有ファイルシステムの場合、記憶域の場所を構成する前に通常ホスト資格証明を設定する必要があります。しかし、OMSエージェント・ファイル・システムの場所の構成の場合は、資格証明(優先または名前付き)を指定する必要があります。

6. 「ソースの指定」セクションで、標準のJava EEアーカイブ・ファイル(.ear、.war、.jar、.rar、.garなど)や、その他のオプション・ファイル(デプロイ前スクリプト、デプロイ後スクリプト、ターゲット実行スクリプト、実行計画、追加ファイルなど)を追加できます。各ファイルを個別に(個々のファイル)アップロードすることも、JavaEEAppComp.manifestファイルを含むzip形式のファイル(Zipファイル)をアップロードすることもできます。ファイルは次の場所からアップロードできます。

- ローカル・ファイルシステム: 「参照」をクリックして、ローカル・システムからファイルをアップロードします。

- エージェント・ファイルシステム: 管理エージェントにより監視されているリモート・ファイルシステムからファイルをアップロードできます。「参照」をクリックし、リストからホスト・マシンを選択して「選択」をクリックします。「追加」をクリックします。「リモート・ファイル・ブラウザ」ウィンドウが表示されます。「次のユーザーでログイン」ボタンをクリックして、ホスト・マシンの資格証明を入力します。ファイルが存在する場所を指定し、1つまたは複数のアーカイブ関連ファイルを選択して、「追加」をクリックします。選択したファイルは、「現在の選択」セクションにリストされます。OKをクリックして、「エンティティの作成: ファイルの選択」ページに戻ります。

7. ファイルは表にリストされます。「タイプ」フィールドのオプションを選択して、ファイルのタイプを指定します。「次へ」をクリックします。

8. これまでに入力した情報を確認および検証します。ファイルをアップロードし、Java EEアプリケーション・コンポーネントを作成するには、「保存とアップロード」をクリックします。

30.6 「Java EEアプリケーション」デプロイメント・プロシージャ

この項では、「Java EEアプリケーション」デプロイメント・プロシージャについて説明します。内容は次のとおりです。

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

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

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

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

Java EEアプリケーションをデプロイするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. リストからJava EEアプリケーション・プロシージャを選択し、「起動」をクリックします。また、次の方法でデプロイメント・プロシージャを起動することもできます。

- 「ターゲット」メニューから「ミドルウェア」をクリックします。

- リストからWebLogicドメインを右クリックして、コンテキスト依存メニューから「プロビジョニング」を選択し、「Java EEアプリケーションのデプロイ/アンデプロイ」を選択します。

- 「デプロイメント・プロシージャ・マネージャ」ページで、「Java EEアプリケーション・プロビジョニング」プロシージャを選択し、「起動」をクリックします。

3. 「Java EEアプリケーションのデプロイ/アンデプロイ: ターゲットの選択」ページで、「デプロイ」操作を選択します。

図30-1 Java EEアプリケーションのデプロイ/アンデプロイ: ターゲットの選択

4. WebLogicドメインを選択し、Java EEアプリケーションがデプロイされるターゲットを選択します。WebLogicドメインの追加をクリックします。リストから1つ以上のWebLogicドメインを選択し、「選択」をクリックします。

注意:
特定の機能をロックしてデプロイメント・プロシージャをカスタマイズできます。操作、ターゲットまたはアプリケーションをロックできます。デプロイメントを実行する前に、選択したドメインにアクティブな構成ロックが設定されていないことを確認する必要があります。選択したドメインがロックされている場合は、「ロック」アイコンをクリックして構成ロックを解除します。

5. 選択したWebLogicドメインが「ターゲット」表にリストされます。各ドメインのターゲット(クラスタまたは管理対象サーバー)を選択し、「次へ」をクリックします。

6. 「Java EEアプリケーションのデプロイ/アンデプロイ: アプリケーションの選択」ページで、ソフトウェア・ライブラリからデプロイするアーカイブおよびその他の関連ファイルを追加します。「追加」をクリックして、ソフトウェア・ライブラリから1つ以上のアーカイブとその他のアプリケーション関連のファイルまたはコンポーネントを選択します。「アプリケーションの追加」ポップアップが表示されます。「コンポーネント名」フィールドにファイル名またはワイルドカード・パターンを入力して、ソフトウェア・ライブラリからコンポーネントを検索して取得します。「Java EEアプリケーション・コンポーネントのみを表示」チェック・ボックスを選択すると、「ソフトウェア・ライブラリ」列にJava EEアプリケーション・コンポーネントのみが表示されます。アーカイブを選択し、右矢印をクリックしてそれらを「デプロイメント用に選択されたコンポーネント」セクションに移動します。

図30-2 Java EEアプリケーションのデプロイ/アンデプロイ: アプリケーションの追加

7. 「タイプ」フィールドに、各コンポーネントのタイプが表示されます。「タイプ」の値は次のとおりです。

- アーカイブ: アーカイブ・ファイルで、.ear、.war、.jar、.rarまたは.garファイルのいずれかです。

注意:
アーカイブ・ファイル.garを選択した場合は、アプリケーションがデプロイされるWebLogicドメインは12.1.2.0.0以降にする必要があります。

- プラン: このアプリケーションのデプロイメント・オプションを格納している.xmlファイルです。

- デプロイ前スクリプト: これはWLSTコマンドが入っているスクリプトです。アプリケーションがデプロイされる前に、各WebLogicドメインの管理サーバーでこのスクリプトが実行されます。このスクリプトを使用して、データ・ソース、JMSエンド・ポイント、およびデプロイするアプリケーションに必要になる可能性があるその他のリソースを作成できます。

- デプロイ後スクリプト: アプリケーションのデプロイ後、管理サーバー上の管理エージェントにより実行されるWLSTスクリプトです。このスクリプトを使用して、デプロイメント後の構成を実行できます。たとえば、デプロイ前スクリプトによって変更された内容をロールバックしたり取り消す必要がある場合に、このオプションを選択します。

注意:
アーカイブ、プラン、デプロイ前スクリプト、およびデプロイ後スクリプトは、管理サーバーのみに移動されます。

- 追加のファイル: アプリケーションに必要でアプリケーション・アーカイブに含まれていない1つ以上のファイルを追加できます。追加のファイルはあらゆるタイプが可能であり、選択したターゲット(管理対象サーバーおよびクラスタ)のみに移動できます。

- ターゲット実行スクリプト: このスクリプトは、必要な環境の設定や、プロパティ・ファイルなどの追加ファイル内のトークンの交換に使用できます。このスクリプトは選択したターゲットで実行されます。

8. 「ターゲットの場所」フィールドで、各コンポーネントに対し、アプリケーションがデプロイされるWebLogicサーバー・ホスト上の場所を指定します。これは選択したターゲットの絶対パスまたは$WLS_HOMEからの相対パスのどちらでもかまいません。

9. デプロイメントに必要なファイルを選択したら、アプリケーションの一意の名前を入力し、ステージング・モードを指定します。ステージング・モードの種類は次のとおりです。

- デフォルト: WebLogicドメイン内の各サーバーは、ステージング・モードとStagingDirectoryNameという2つの属性を維持しています。ステージング・モードはサーバーのデフォルトのステージング・モードであり、StagingDirectoryNameはステージングされるファイルが格納される場所です。すべてのターゲットにデフォルトのステージング・モードを使用する場合は、このオプションを選択します。

- ステージング: アーカイブ・ファイルを宛先マシンに移動する必要がある場合は、このオプションを選択します。

- ステージなし: アーカイブ・ファイルを宛先マシンに移動する必要がない場合は、このオプションを選択します。

10. アプリケーションを共有ライブラリとしてデプロイする場合は、「このアーカイブをライブラリとしてデプロイします」オプションを選択します。1つ以上のアプリケーションに同じファイル・セットが必要な場合は、このオプションを選択できます。

11. デプロイメントの「開始モード」を選択します。「開始モード」の値は次のとおりです。

- 完全モードで起動(すべてのリクエストの処理): デプロイするアプリケーションをすべてのユーザーが使用できるようにする場合は、このオプションを選択します。

- 管理モードでのアプリケーションの起動(管理リクエストのみ処理): このオプションを選択すると、デプロイするアプリケーションは管理者のみが使用可能になります。

- 起動しない: アプリケーションはデプロイされますが、起動されません。デプロイメント後に手動構成が必要な場合は、このオプションを選択できます。

12. 「OK」をクリックしてアーカイブを追加し、アプリケーションの選択ページに戻ります。他にもアーカイブを追加するか、「次へ」をクリックして次に進みます。1つ以上のアーカイブを追加した場合は、「失敗時にスキップ」チェック・ボックスを選択することで、失敗したデプロイメントがあればスキップして残りのアプリケーションのデプロイを続行します。

13. 「ロック」アイコンをクリックし、構成したフィールドをロックします。

注意:
デザイナは、フィールドを構成した後にこれらをロックできます。これにより、オペレータが最小限の入力でデプロイメント・プロシージャを実行できるようになります。

14. 「次へ」をクリックします。選択した各ドメイン、管理サーバーが稼働しているホスト、および追加ファイルまたは実行スクリプトを移動したホストの資格証明を指定します。次のうちから選択できます。

- 優先資格証明: このオプションはデフォルトで選択され、管理リポジトリに保存されている優先資格証明が使用されます。Cloud Controlでこれが定義されている場合にのみ、このオプションを使用できます。

- 名前付き資格証明: 名前付き資格証明は、ユーザーに対する認証情報を指定するもので、ユーザー名とパスワードの組合せや公開鍵と秘密鍵のペアにすることができ、プロビジョニング、パッチ適用、ジョブの実行、およびその他のシステム管理タスクを実行するために使用できます。

資格証明をクリックしたら、「適用」をクリックします。

資格証明の設定の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「Enterprise Managerのセキュリティ」の章を参照してください。

15. 「ロック」アイコンをクリックし、構成したフィールドをロックします。ロックされたフィールドは編集できません。

16. デプロイメントのスケジュール・ページで、Java EEアプリケーション・デプロイメント・プロシージャを起動する必要のある日付をスケジュールできます。

17. 「次へ」をクリックします。確認ページで、デプロイメント・プロシージャに対して指定した詳細を確認します。その詳細で問題がない場合は、「発行」をクリックし、スケジュール・セットに従ってデプロイメント・プロシージャを実行します。詳細を変更する場合は、そのセクション内の「編集」リンクをクリックするか、変更を行うページが表示されるまで「戻る」をクリックします。
デプロイメント・プロシージャを発行すると、デプロイメント・プロシージャのステータスを見ることができるプロシージャ・アクティビティ・ページに戻ります。Java EEアプリケーションのデプロイが完了すると、ターゲットを検索し、「ターゲット」ホームページに移動できます。

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

Java EEアプリケーションを再デプロイするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. リストからJava EEアプリケーション・プロシージャを選択し、「起動」をクリックします。また、次の方法でデプロイメント・プロシージャを起動することもできます。

- 「ターゲット」メニューから「ミドルウェア」をクリックします。

- リストからWebLogicドメインを右クリックして、コンテキスト依存メニューから「プロビジョニング」を選択し、「Java EEアプリケーションのデプロイ/アンデプロイ」を選択します。

- 「デプロイメント・プロシージャ・マネージャ」ページで、「Java EEアプリケーション・プロビジョニング」プロシージャを選択し、「起動」をクリックします。

3. ターゲットの選択ページで「再デプロイ」操作を選択します。

注意:
「ロック」アイコンをクリックし、操作またはウィザードの任意のページで構成しているフィールドをロックします。フィールドがロックされたら、オペレータは、デプロイメント・プロシージャの実行中に最小限の入力を行う必要があります。

4. WebLogicドメインの追加をクリックして、1つ以上のWebLogicドメインを追加します。表示されるターゲットのリストで、ターゲットを選択して「選択」をクリックします。

5. 「ターゲット」表にデプロイメント・ターゲットがリストされます。再デプロイするアプリケーションを選択し、「次へ」をクリックします。

6. アプリケーションの選択ページに、再デプロイ可能なアプリケーションのリストが表示されます。アーカイブの詳細やその他のアプリケーションに関連するファイルを変更するには、アプリケーションを選択し、「編集」をクリックします。「アプリケーションの詳細」ウィンドウで、ソフトウェア・ライブラリのファイルを検索し取得するためのファイル名またはワイルド・カード・パターンを入力します。アーカイブを選択し、右矢印をクリックしてそれらを「デプロイメント用に選択されたコンポーネント」セクションに移動します。

7. 「タイプ」フィールドに、各コンポーネントのタイプが表示されます。「タイプ」の値は次のとおりです。

- アーカイブ: アーカイブ・ファイルです。ファイルは.ear、.war、.jar、.rarのいずれかです。

- プラン: このアプリケーションのデプロイメント・オプションを格納している.xmlファイルです。

- デプロイ前スクリプト: これはWLSTコマンドが入っているスクリプトです。アプリケーションがデプロイされる前に、各WebLogicドメインの管理サーバーでこのスクリプトが実行されます。このスクリプトを使用して、データ・ソース、JMSエンド・ポイント、およびデプロイするアプリケーションに必要になる可能性があるその他のリソースを作成できます。

- デプロイ後スクリプト: これは、アプリケーションのデプロイ後に管理エージェントによって管理サーバーで実行されるWLSTスクリプトです。このスクリプトを使用して、デプロイメント後の構成を実行できます。たとえば、デプロイ前スクリプトによって変更された内容をロールバックしたり取り消す必要がある場合に、このオプションを選択します。

注意:
アーカイブ、プラン、デプロイ前スクリプト、およびデプロイ後スクリプトは、管理サーバーのみに移動されます。

- 追加のファイル: アプリケーションに必要でアプリケーション・アーカイブに含まれていない1つ以上のファイルを追加できます。追加のファイルはあらゆるタイプが可能であり、選択したターゲット(管理対象サーバーおよびクラスタ)のみに移動できます。

- ターゲット実行スクリプト: このスクリプトは、必要な環境の設定や、プロパティ・ファイルなどの追加ファイル内のトークンの交換に使用できます。このスクリプトは選択したターゲットで実行されます。

8. コンポーネントがあるマシン上のデフォルトの場所を確認します。これは選択したターゲットの絶対パスまたは$WLS_HOMEからの相対パスのどちらでもかまいません。

9. デプロイメントに必要なファイルを選択したら、アプリケーションの一意の名前を入力し、ステージング・モードを指定します。ステージング・モードの種類は次のとおりです。

- デフォルト: WebLogicドメイン内の各サーバーは、ステージング・モードとStagingDirectoryNameという2つの属性を維持しています。ステージング・モードはサーバーのデフォルトのステージング・モードであり、StagingDirectoryNameはステージングされるファイルが格納される場所です。すべてのターゲットにデフォルトのステージング・モードを使用する場合は、このオプションを選択します。

- ステージング: アーカイブ・ファイルを宛先マシンに移動する必要がある場合は、このオプションを選択します。

- ステージなし: アーカイブ・ファイルを宛先マシンに移動する必要がない場合は、このオプションを選択します。

10. デプロイメントの「開始モード」を選択します。「開始モード」の値は次のとおりです。

- 完全モードで起動(すべてのリクエストの処理): デプロイするアプリケーションをすべてのユーザーが使用できるようにする場合は、このオプションを選択します。

- 管理モードでのアプリケーションの起動(管理リクエストのみ処理): このオプションを選択すると、デプロイするアプリケーションは管理者のみが使用可能になります。

- 起動しない: アプリケーションはデプロイされますが、起動されません。デプロイメント後の構成が必要な場合に、このオプションを選択できます。

11. アプリケーションの「リタイア・ポリシー」を指定します。次のいずれかを選択できます。

- アプリケーションが現在のセッションを終了してリタイアできるようにします: 現在のすべてのセッションがリタイアの前に完了する必要がある場合は、このオプションを選択します。

- リタイア・タイムアウトの後に以前のバージョンをリタイアします: アプリケーションが自動的にリタイアしてからタイムアウトになるまでの時間を指定します。

12. 「OK」をクリックしてアーカイブを追加し、アプリケーションの選択ページに戻ります。他にもアーカイブを追加するか、「次へ」をクリックして次に進みます。1つ以上のアーカイブを追加した場合は、「失敗時にスキップ」チェック・ボックスを選択することで、失敗したデプロイメントがあればスキップして残りのアプリケーションのデプロイを続行します。

13. 「ロック」アイコンをクリックし、構成したフィールドをロックします。ロックされたフィールドは編集できません。

14. 「次へ」をクリックします。選択した各ドメイン、管理サーバーが稼働しているホスト、および追加ファイルまたは実行スクリプトを移動したホストの資格証明を指定します。次のうちから選択できます。

- 優先資格証明: このオプションはデフォルトで選択され、管理リポジトリに保存されている優先資格証明が使用されます。Cloud Controlでこれが定義されている場合にのみ、このオプションを使用できます。

- 名前付き資格証明: 名前付き資格証明は、ユーザーに対する認証情報を指定するもので、ユーザー名とパスワードの組合せや公開鍵と秘密鍵のペアにすることができ、プロビジョニング、パッチ適用、ジョブの実行、およびその他のシステム管理タスクを実行するために使用できます。

資格証明の設定の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「Enterprise Managerのセキュリティ」の章を参照してください。

15. 「ロック」アイコンをクリックし、構成したフィールドをロックします。ロックされたフィールドは編集できません。

16. デプロイメントのスケジュール・ページで、Java EEアプリケーション・デプロイメント・プロシージャを起動する必要のある日付をスケジュールできます。

17. 「次へ」をクリックします。確認ページで、デプロイメント・プロシージャに対して指定した詳細を確認します。その詳細で問題がない場合は、「発行」をクリックし、スケジュール・セットに従ってデプロイメント・プロシージャを実行します。詳細を変更する場合は、そのセクション内の「編集」リンクをクリックするか、変更を行うページが表示されるまで「戻る」をクリックします。
デプロイメント・プロシージャを発行すると、デプロイメント・プロシージャのステータスを見ることができるプロシージャ・アクティビティ・ページに戻ります。Java EEアプリケーションのデプロイが完了すると、ターゲットを検索し、「ターゲット」ホームページに移動できます。

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

Java EEアプリケーションをアンデプロイするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. リストからJava EEアプリケーション・プロシージャを選択し、「起動」をクリックします。また、次の方法でデプロイメント・プロシージャを起動することもできます。

- 「ターゲット」メニューから「ミドルウェア」をクリックします。

- リストからWebLogicドメインを右クリックして、コンテキスト依存メニューから「プロビジョニング」を選択し、「Java EEアプリケーションのデプロイ/アンデプロイ」を選択します。

- 「デプロイメント・プロシージャ・マネージャ」ページで、「Java EEアプリケーション・プロビジョニング」プロシージャを選択し、「起動」をクリックします。

3. ターゲットの選択ページで「アンデプロイ」操作を選択します。

4. WLSドメインの追加をクリックして、1つ以上のWebLogicドメインを追加します。表示されるターゲットのリストで、ターゲットを選択し、「選択」をクリックします。

5. 「ターゲット」表にデプロイメント・ターゲットがリストされます。アプリケーションをWebLogicドメインからアンデプロイする場合、アンデプロイするアプリケーションを選択し、「次へ」をクリックします。

6. 「次へ」をクリックします。選択した各ドメイン、管理サーバーが稼働しているホスト、および追加ファイルまたは実行スクリプトを移動したホストの資格証明を指定します。次のうちから選択できます。

- 優先資格証明: このオプションはデフォルトで選択され、管理リポジトリに保存されている優先資格証明が使用されます。Cloud Controlでこれが定義されている場合にのみ、このオプションを使用できます。

- 名前付き資格証明: 名前付き資格証明は、ユーザーに対する認証情報を指定するもので、ユーザー名とパスワードの組合せや公開鍵と秘密鍵のペアにすることができ、プロビジョニング、パッチ適用、ジョブの実行、およびその他のシステム管理タスクを実行するために使用できます。

資格証明の設定の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「Enterprise Managerのセキュリティ」の章を参照してください。

7. デプロイメントのスケジュールを指定し、「次へ」をクリックします。

8. 詳細を確認し、「アンデプロイ」をクリックします。「プロシージャ・アクティビティ」ページに戻ると、ステータスを確認できます。

31 コヒーレンス・ノードおよびクラスタのプロビジョニング

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用してコヒーレンス・ノードまたはクラスタをファーム内の複数のターゲットにプロビジョニングする方法について説明します。この章の具体的な内容は次のとおりです。

- 開始

- サポートされているリリース

- コヒーレンス・ノードおよびクラスタのデプロイ

- トラブルシューティング

31.1 開始

この項では、この章の手引きとして、コヒーレンス・ノードおよびクラスタのプロビジョニングに関連する手順の概要を示します。コヒーレンス・デプロイメント・プロシージャを使用すると、次の操作を実行できます。

- 新規クラスタに1つ以上のノードを追加し、このクラスタをCloud Control監視ターゲットとして追加します。

- 既存のクラスタに管理ノードを追加し、このクラスタをCloud Control監視ターゲットとして追加します。

- Cloud Controlによってすでに監視されているクラスタに1つ以上のノードを追加します。

- 変更されたソフトウェア・コンポーネントまたは構成ファイルをコピーして既存のノードを更新し、ノードを再起動します。

- 新規のコヒーレンス・クラスタを作成します。

この項は、コヒーレンス・ノードのデプロイを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表31-1 コヒーレンス・ノードのデプロイの概要

ステップ

説明

参照リンク

手順1

デプロイメント・プロシージャの理解

Cloud Controlで提供されている、コヒーレンス・ノードをデプロイするためのデプロイメント・プロシージャについて理解します。デプロイメント・プロシージャの機能や、その対象となるユースケースなどを把握します。

デプロイメント・プロシージャの詳細は、第31.3項を参照してください。

手順2

サポートされているリリースの把握

サポートされているOracle Coherenceのリリースを把握します。

デプロイメント・プロシージャでサポートされているリリースについては、第31.2項を参照してください。

手順3

前提条件の確認

デプロイメント・プロシージャを実行する前に、ターゲットとしてのコヒーレンス・ノードの追加、Oracleソフトウェア・ライブラリの設定などの前提条件を満たしていることを確認する必要があります。

コヒーレンス・ノードをデプロイするための前提条件の詳細は、第31.3.1項を参照してください。

手順4

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行して、コヒーレンス・ノードをプロビジョニングします。

コヒーレンス・ノードをデプロイするには、第31.3.3項で説明されている手順を実行します。

31.2 サポートされているリリース

この項では、このデプロイメント・プロシージャでサポートされているOracle Coherenceのリリースを示します。

- Oracle Coherence 3.5、3.6および3.7。

- Oracle Coherence 12.1.2スタンドアロン・バージョン。

31.3 コヒーレンス・ノードおよびクラスタのデプロイ

この項では、既存のクラスタへの1つ以上のノードの追加、または「コヒーレンス・ノード・プロビジョニング」プロシージャを使用する新規のクラスタ作成の方法について説明します。

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

- 前提条件

- コヒーレンス・コンポーネントの作成

- デプロイメント・プロシージャ

31.3.1 前提条件

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

- コヒーレンス・ノードを追加または更新するホストは、Cloud Controlの監視対象ターゲットである必要があります。

- コヒーレンス・ソフトウェアが格納されたZIPファイル、デフォルト構成ファイル、および開始スクリプトを作成する必要があります。このZIPファイルは、ソフトウェア・コンポーネントとしてOracleソフトウェア・ライブラリに追加する必要があります。このZIPファイルのサイズが25MBを超える場合、管理エージェントにより監視されているホストからこのファイルをアップロードする必要があります。デフォルト構成ファイルをオーバーライドするコンポーネントとして、特定の構成ファイルをソフトウェア・ライブラリに追加できます。これらの構成ファイルは、ノードのタイプ(記憶域、管理など)によって異なる場合があります。ソフトウェア・コンポーネントを追加するときに、「製品名」として「Coherence」を指定することをお薦めします。

- コヒーレンス・バイナリが存在しないホスト上で新しいノードをプロビジョニングする場合は、coherence.zipファイルおよびdefault-start-script.plをOracleソフトウェア・ライブラリにアップロードする必要があります。プロビジョニングに必要な各ファイルは、個々のソフトウェア・コンポーネントとしてアップロードする必要があります。

31.3.2 コヒーレンス・コンポーネントの作成

1つ以上のコヒーレンス・コンポーネントを作成して、ソフトウェア・ライブラリに保存できます。このコンポーネントは、コヒーレンス・ノードおよびクラスタをプロビジョニングするときに必要になります。コヒーレンス・コンポーネントを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「ソフトウェア・ライブラリ」を選択します。

2. コンポーネントを格納するフォルダを作成します。フォルダが作成されたら、フォルダを右クリックして、「アクション」メニューから「エンティティの作成」および「コンポーネント」を選択します。

3. 「コンポーネントの作成」ポップアップ・ウィンドウが表示されます。「サブタイプの選択」ドロップダウン・リストから「汎用コンポーネント」を選択し、「続行」をクリックします。

図31-1 「汎用コンポーネントの作成: 説明」ページ

4. 「汎用コンポーネントの作成: 説明」ページで、「製品」に「Coherence」と入力します。これは、コヒーレンス・プロビジョニングでファイルを検索する際に便利です。「次へ」をクリックします。

5. 「汎用コンポーネントの作成: ファイルの選択」ページで、「ファイルのアップロード」オプションを選択します。

図31-2 「汎用コンポーネントの作成: ファイルの選択」ページ

6. 「ソースの指定」セクションで、「ファイル・ソース」ドロップダウン・ボックスから「エージェント・マシン」を選択し、次のファイルをアップロードします。

- $AGENT_ROOT/plugins/oracle.sysman.emas.agent.plugin_12.1.0.1.0/archives/coherence/bulkoperationsmbean_11.1.1.jar

- $AGENT_ROOT/plugins/oracle.sysman.emas.agent.plugin_12.1.0.1.0/archives/coherence/coherenceEMIntg.jar

- $AGENT_ROOT/plugins/oracle.sysman.emas.agent.plugin_12.1.0.1.0/scripts/coherence/default-start-script.pl

Coherence.zipなどの大きいZIPファイルをアップロードする場合は、そのファイルをエージェント・マシンに保存する必要があります。ファイルのアップロード先のエージェント上のパスを指定します。このZIPファイルは、http://www.oracle.com/technetwork/middleware/coherence/downloads/index.htmからダウンロードする必要があります。

7. 「保存とアップロード」をクリックして、指定したアップロード場所にリモート・ファイルをアップロードするためのファイル転送ジョブを発行します。

31.3.3 デプロイメント・プロシージャ

コヒーレンス・ノードまたはクラスタをデプロイするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. 「コヒーレンス・ノード・プロビジョニング」デプロイメント・プロシージャを選択し、「起動」をクリックします。

注意:
また、次の方法でデプロイメント・プロシージャを起動することもできます。

- 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。リストから「Coherence」デプロイメント・プロシージャを選択し、「起動」をクリックします。

- 「Coherence」ホームページのメニューから、「コヒーレンス・ノード・プロビジョニング」オプションを選択します。

3. コヒーレンス・ノード・プロビジョニング・ウィザードの最初のページである「ソース選択」ページが表示されます。

図31-3 「ソース選択」ページ

4. コヒーレンス・クラスタの追加または更新に必要なすべてのソフトウェア・コンポーネントを追加できます。コヒーレンス・ホームがすでに作成されている場合は、「次へ」をクリックして次のページに進みます。
コヒーレンス・ホームが存在しない場合は、「追加」をクリックして、ソフトウェア・ライブラリからコヒーレンス・バイナリおよび開始スクリプトを追加します。「ソースの選択」ポップアップが表示されます。デフォルトでは、「ソフトウェア・ライブラリ」にある、製品名がCoherenceのソフトウェア・コンポーネントがすべて表示されます。必要なコンポーネントを選択し、「選択」.をクリックします。

5. 選択したコンポーネントごとに、ターゲット・マシン上の宛先ディレクトリを指定します。これは、絶対パスか、${INSTALL_DIR}または${COHERENCE_HOME}からの相対パスにします。coherence.zipファイルの内容がこのディレクトリに抽出されます。

注意:

- $INSTALL_DIRの値は、コヒーレンス・ノード・プロビジョニング: ターゲット選択ページで定義され、COHERENCE_HOMEディレクトリの上位のレベルで設定されます。

- ターゲット・マシンでソフトウェア・コンポーネントが使用可能になっている場合は、この手順を省略できます。

6. 「次へ」をクリックします。「ターゲット選択」ページが表示されます。このページでは、次の操作が可能です。

- ノードの追加: 新しいノードを追加するか、既存のノードをコピーすることができます。「ターゲット名」フィールドで「検索」アイコンをクリックし、リストからコヒーレンス・クラスタを選択します。次の詳細が表示されます。

- クラスタ名: クラスタの名前。

- クラスタ通信: 「マルチキャスト」または「Well Knownアドレス(WKA)」のいずれかです。

- ライセンス・モード: クラスタがデプロイされたモードです。

「新規ノード」セクションで「追加」をクリックして、Cloud Controlにより監視されている既存のコヒーレンス・クラスタに新規ノードを追加します。コヒーレンス・ノードの追加ページが表示されます。ノードの詳細を指定して「続行」をクリックし、ノードを追加したらコヒーレンス・ノード・プロビジョニング: ターゲットの選択ページに戻ります。詳細は第31.3.3.1項を参照してください。

- 既存ノードのコピーの作成: 既存ノードのコピーを作成できます。ノードの追加先のクラスタを選択すると、「既存のノード」セクションに、クラスタに存在するノードのリストが表示されます。リストからノードを選択し、「類似作成」をクリックします。コヒーレンス・ノードの追加ページが表示されます。ノードの詳細を指定して「続行」をクリックし、コヒーレンス・ノード・プロビジョニング: ターゲットの選択ページに戻ります。選択したノードのコピーが「新規ノード」セクションに表示され、デプロイ可能になります。

- クラスタの作成: 「クラスタの作成」をクリックして、新規のコヒーレンス・クラスタを作成します。クラスタ名と次の詳細を入力します。

- クラスタ名: クラスタに一意の名前を入力します。

- クラスタ通信: 「マルチキャスト」または「Well Knownアドレス(WKA)」を選択します。「マルチキャスト」を選択する場合、クラスタ・ポートおよびクラスタ・アドレスの入力を求められます。WKAを選択する場合は、1つ以上の<hostname>:<portエントリ・セットをカンマで区切って入力し、「コヒーレンス・ノード・プロビジョニング: ノードの追加」ページでWKAの詳細が指定されていることを確認します。

注意:

- WKAを選択する場合、WKAエントリ用のオーバーライド・ファイル(tangosol-coherence-override-em.xml)を作成し、このファイルにDtangosol.coherence.overrideパラメータを指定する必要があります。このファイルはdefault-start-script.plから作成され、必要に応じて変更できます。

- 既存のノードのコピーを作成する際に(「類似作成」オプション)、クラスタ通信にWKAを選択した場合、Well Knownアドレスフィールドにホスト名ではなくIPアドレスを入力するよう求められます。

- ライセンス・モード: クラスタがデプロイされるモードを指定します。これは、「開発」、「評価」または「本番」にすることができます。

「新規ノード」セクションで「追加」をクリックして、作成している新規クラスタにノードを追加します。コヒーレンス・ノードの追加ページが表示されます。ノードの詳細を指定して「続行」をクリックし、ノードを追加したらコヒーレンス・ノード・プロビジョニング: ターゲットの選択ページに戻ります。

クラスタを作成するには、coherenceEMIntg.jar、bulkoperationsmbean_11.1.1.jar、default-start-script.plおよびCoherence.zipコンポーネントが必要です。

7. ウィザードの次の手順に進むには「次へ」をクリックします。「コヒーレンス・ノード・プロビジョニング: 資格証明の設定」ページで、各ホストの資格証明を設定できます。リストから複数のホストを選択すると、複数ホストに同一の資格証明を適用できます。

8. ホストを選択し、次のいずれかの資格証明を指定します。

- 優先資格証明: このオプションはデフォルトで選択され、管理リポジトリに保存されている優先資格証明が使用されます。Cloud Controlでこれが定義されている場合にのみ、このオプションを使用できます。

- 名前付き資格証明: 優先資格証明をオーバーライドし、すべてのホストとWebLogicドメインに使用する共通の資格証明セットを選択できます。

- 新規資格証明: 優先資格証明をオーバーライドし、ホストごとに別々の資格証明セットを指定できます。

資格証明を選択し、「適用」をクリックして、選択したホストに資格証明を適用します。資格証明の設定の詳細は、『Enterprise Manager Cloud Control管理者ガイド』の「Enterprise Managerのセキュリティ」の章を参照してください。

9. 「次へ」をクリックします。「スケジュール」ページが表示されます。このページでは、ノードをデプロイするためのスケジュールを指定できます。ノードを即時にデプロイするか、後日デプロイするかを選択できます。

注意:
「猶予期間」を「未定義」に設定した場合、Cloud Controlではノードのデプロイが無期限に試行されます。このフィールドに日時を指定した場合、デプロイメント・プロセスはこの期間後に中止されます。

10. 「次へ」をクリックします。「確認」ページが表示されます。ノードをデプロイするために指定した詳細を確認できます。ノードを更新する場合、停止されるノード・プロセスをこのページで確認できます。「終了」をクリックして、ノードをデプロイまたは更新します。
新規の管理ノードが作成された後、ノードをクラスタに追加する前に、最初のコレクションを待機する必要があります。

31.3.3.1 コヒーレンス・ノードの追加

1つ以上の新規ノードを追加することにより、ノードを既存のクラスタに追加するか、新規クラスタを作成できます。ノードを追加するには、次の手順を実行します。

1. 「コヒーレンス・ノード・プロビジョニング: ターゲット選択」ページで、「追加」をクリックします。コヒーレンス・ノードの追加ページが表示されます。次の詳細を入力します。

図31-4 「コヒーレンス・ノードの追加」ページ

表31-2 「コヒーレンス・ノードの追加」ページ

フィールド名

説明

ホスト詳細

ホスト名

ノードを追加するホストを選択します。マシン構成とノード構成に応じて、ホストで複数のノードを使用できます。

注意: ここで選択したホスト名は、2つの起動パラメータの設定に使用されます。tangosol.coherence.machineパラメータの設定にはtangosol_coherence_machine環境変数を使用し、oracle.coherence.machineパラメータの設定にはoracle_coherence_machineを使用します。

ノード数

追加する必要のあるノード数を指定します。デフォルトでは、このフィールドの値は1ですが、マシンやノードの構成に応じて必要な数のノードを追加できます。値が1より大きい場合、すべてのノードが次のプロパティを持ちます。

- 各ノードで同じCOHERENCE_HOMEおよび開始スクリプトが使用されます。

- 「ノード名」の値が接頭辞として追加され、数字が各ノードに追加されます。たとえば、<node_name>_1、<node_name>_2のようになります。いずれの名前もクラスタ内で一意である必要があります。

- ノードが追加されるたびに、「JMXリモート・ポート」の値は1ずつ増えます。たとえば、1つ目のノードの「JMXリモート・ポート」の値が8088である場合、2つ目のノードの値は8089になります。

ノードの詳細

ノード名

一意のノード名を入力します。

サイト名

コヒーレンス・ノードの場所です。これは、ノードが実行されているラックとマシンを識別する地理的な物理サイト名です。

ラック名

マシンが設置されているサイト内のラックの名前です。

ロール名

ロールは記憶域/データ、アプリケーション/プロセス、プロキシまたは管理ノードのいずれかです。

注意: 「ノード名」、「サイト名」、「ラック名」および「ロール名」は32文字を超えることはできません。

ソフトウェア・コンポーネントをコピーしないでください。

コヒーレンス・ホームがすでに存在しているマシンにノードを追加する場合は、「ソフトウェア・コンポーネントをコピーしないでください。」チェック・ボックスを選択する必要があります。新規のホストにファイルをコピーする場合は、「ソフトウェア・コンポーネントをコピーしないでください。」チェック・ボックスの選択を解除して、「コヒーレンス・ノード・プロビジョニング: ソース選択」ページでバイナリが選択されていることを確認します。

Well Knownアドレス(WKA)

「コヒーレンス・ノード・プロビジョニング: ターゲット選択」ページで「クラスタ通信」がWKAに設定されている場合、ホストとポート番号をhost1:port1, host2:port2の形式で入力します。

JVM診断の詳細

JVMマネージャのホストおよびポート

このノードをJVM診断マネージャによって監視する場合は、JVM診断コンソールのアドレスとポート番号を指定します。

管理ノードの詳細

MBeanServerを使用した管理ノード

クラスタ内の複数の管理ノードを定義できますが、プライマリ管理ノードとしてマークできるのは1つの管理ノードのみです。フェイルオーバーに対応できるように、異なるホストまたはマシンで実行されている2つ以上の管理ノードを追加することをお薦めします。

JMXリモート・ポート

EMIntegration Mbeanサーバーのポート番号です。

JMXユーザー名

認証が有効になっている場合の、JMXサーバーのユーザー名です。

JMXパスワード

認証が有効になっている場合の、JMXサーバーのパスワードです。

注意: JMX認証を有効にするには、com.sun.management.jmxremote.authenticate=trueを設定する必要があります。JMXユーザー名とJMXパスワードは、$JDK_HOME/jre/lib/management/jmxremote.passwordファイルおよび$JDK_HOME/jre/lib/management/jmxremote.accessファイル内に設定する必要があります。

監視用に使用するプライマリ管理ノード

監視に使用するプライマリ管理ノードとして追加する管理ノードをマークする場合は、このチェック・ボックスを選択します。このノードがコヒーレンス・クラスタの検出に使用され、後から追加されたノードは新しく検出されたクラスタに追加されます。クラスタに複数のノードを追加する場合、プライマリ・ノードとしてマークできる管理ノードは1つのみです。プライマリ管理ノードに障害が発生した場合、他のいずれかの管理ノードを監視用に構成できます。他に使用可能な管理ノードがない場合、新規のプライマリ管理ノードを既存のクラスタに追加して、このノードを監視に使用することができます。

一括MBean操作の使用

このチェック・ボックスは、デフォルトで選択されます。このオプションを選択した場合、BulkOperationsMBeanを使用して新規の管理ノードが起動されます。

環境詳細

インストール・ディレクトリ

コヒーレンス・ソフトウェア・コンポーネントが格納されているフォルダの絶対パスを入力します。ここで指定したパスは、コヒーレンス・ノード・プロビジョニング: ソース選択ページで指定した「接続先ディレクトリ」として使用されます。この値は、ノードごとに異なっていても、1つ以上のノードに対して同じであってもかまいません。

開始スクリプト

このスクリプトがコヒーレンス・ノードの起動に使用されます。このスクリプトはオペレーティング・システムに固有であり、関連するシステム・パラメータを指定することでノードに必要な適切な環境を設定します。例は、「サンプル・スクリプト」を参照してください。

次の表に、デプロイメント時に指定した値が、開始スクリプト内に指定されている環境変数によってどのように使用されるかを示します。デプロイメント・プロシージャでは、エージェントのインストール詳細を使用してJAVA_HOME変数とAGENT_HOME変数も設定されます。開始スクリプトに適切な値を指定して、これらをオーバーライドできます。

表31-3 環境変数

UIパラメータ

設定されている環境変数

コヒーレンス・システム・パラメータ

CLUSTER_NAME

tangosol_coherence_cluster

tangosol.coherence.cluster

CLUSTER_ADDRESS

tangosol_coherence_clusteraddress

tangosol.coherence.clusteraddress

CLUSTER_PORT

tangosol_coherence_clusterport

tangosol.coherence.clusterport

NODE_NAME (32 chars)

tangosol_coherence_member

tangosol.coherence.member

SITE_NAME (32 chars)

tangosol_coherence_site

tangosol.coherence.site

RACK_NAME (32 chars)

tangosol_coherence_rack

tangosol.coherence.rack

MACHINE_NAME

tangosol_coherence_machine

tangosol.coherence.machine

ROLE_NAME (32 chars)

tangosol_coherence_role

tangosol.coherence.role

JMX_REMOTE_PORT

jmx_remote_port

com.sun.management.jmxremote.port

LICENSE_MODE

license_mode

tangosol.coherence.mode

COHERENCE_HOME

coherence_home

oracle.coherence.home

START_SCRIPT

start_script

oracle.coherence.startscript

JVM_CONSOLE_HOST

jvm_console_host

jamconhost

JVM_CONSOLE_PORT

jvm_console_port

jamconport

WKA_PORT

wka_port

tangosol.coherence.override=em-coherence-override.xml

2. ノードを追加した後、「続行」をクリックして「コヒーレンス・ノード・プロビジョニング: ターゲット選択」ページに戻ります。

3. ウィザードの次の手順に進むには「次へ」をクリックします。

31.3.3.2 サンプル・スクリプト

default-start-script.plスクリプトおよびgenerate-wka-override.plスクリプトは、$EMAS_PLUGIN_ROOT/scripts/coherence/ディレクトリ内にあります。

31.3.3.2.1 default-start-script.pl

このスクリプトは、コヒーレンス・ノードの起動に使用されるデフォルトの開始スクリプトです。サンプル・スクリプトを次に示します。

#!/usr/local/bin/perl

# Sample script to demonstrate starting of following Coherence nodes.
# When this script is passed in as a start script in Coherence Node Provisioning
Deployment Procedure, while executing start node step, the deployment procedure
sets all user entered options as environment variables. Based on the values of
these environment variables, you can start different types of Coherence nodes
#
# - Management Node with Oracle Bulk Operation MBean is started when
# "bulk_mbean" and "jmx_remote_port" variables are set. For this option,
# oracle.sysman.integration.coherence.EMIntegrationServer Java class is executed
# that starts a MBeanServer in this node and registers Oracle Bulk Operation
# MBean. You need coherenceEMIntg.jar and bulkoperationsmbean_11.1.1.jar in the
# classpath.

#
# - Management Node is started when "jmx_remote_port" is set, but "bulk_mbean" is
NOT set.
#
# - Managed node when "jmx_remote_port" is not set.
#
#
# Following variables are set from the deployment procedure. Use these values to
# define required system parameters to override Coherence default settings.

my $coherence_home=$ENV{'COHERENCE_HOME'};

my $start_script=$ENV{'START_SCRIPT'};
my $java_home=$ENV{'JAVA_HOME'};
my $agent_home=$ENV{'AGENT_HOME'};
my $wka_port=$ENV{'WKA_PORT'};
my $license_mode=$ENV{'LICENSE_MODE'};
my $jamhost=$ENV{'JAM_CONSOLE_HOST'};
my $jamport=$ENV{'JAM_CONSOLE_PORT'};

my $member=$ENV{'tangosol_coherence_member'};
my $site=$ENV{'tangosol_coherence_site'};
my $rack=$ENV{'tangosol_coherence_rack'};
my $machine=$ENV{'tangosol_coherence_machine'};

# tangosol.coherence.machine has a limitation of 32 chars
# As a workaround, use oracle.coherence.machine to set machine name
# This parameter is used to identify hosts for cluster management features
my $oracle_coherence_machine=$ENV{'oracle_coherence_machine'};
my $role=$ENV{'tangosol_coherence_role'};

my $jmxport=$ENV{'jmx_remote_port'};
my $cluster=$ENV{'tangosol_coherence_cluster'};
my $clusteraddr=$ENV{'tangosol_coherence_clusteraddress'};
my $clusterport=$ENV{'tangosol_coherence_clusterport'};
my $bulkmbean=$ENV{'bulk_mbean'};
my $jmx_auth=$ENV{'jmx_enable_auth'};

my $SYS_OPT="";
my $JVM_OPT="";

my $psep="";
my $dsep="";
if ( !&IsWindows() ) {
$psep=":";
$dsep="/";
}
else
{
$psep=";";
$dsep="\\";
}

print
"\n\n*************************************************************************\n"

print "Output from default-start-script\n";
print "Starting Node : $member\n";
print "Coherence Home : $coherence_home \n";
print "Start Script : $start_script \n";
print "Java Home : $java_home \n";
print "Agent Home : $agent_home \n";
print "WKA Port: $wka_port \n";
print "License Mode: $license_mode \n";

print "Site Name : $site \n";
print "Rack Name : $rack \n";
print "Machine Name : $machine \n";
print "Oracle Coherence Machine Name : $oracle_coherence_machine \n";
print "Role Name : $role \n";

print "Cluster Name : $cluster \n";
print "Cluster Addr : $clusteraddr \n";
print "Cluster Port : $clusterport \n";
print "JMX Port : $jmxport \n";
print "Bulk MBean : $bulkmbean \n";
print "JMX Auth Enabled : $jmx_auth \n";
#

# you may run a local script as part of this script and override those
# settings.
# Override JAVA_HOME variable by setting it locally
#
#. ./set-env.sh
#echo "After setting JAVA_HOME locally, JAVA_HOME: $JAVA_HOME"
# Options for Java Virtual Machine.
$JVM_OPT="-server -Xms512m -Xmx512m -Xincgc -verbose:gc";
#
# Set system parameters to Coherence node
$SYS_OPT="-Djava.net.preferIPv4Stack=true";
# This param allows the mbeans on this node to be registered to mbean servers
running on management nodes

$SYS_OPT="$SYS_OPT -Dtangosol.coherence.management.remote=true";
$SYS_OPT="$SYS_OPT -Dcom.sun.management.jmxremote.ssl=false";
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.cluster=$cluster";
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.member=$member";
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.site=$site";
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.rack=$rack";
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.machine=$machine";
# set this if machine name > 32 chars, tangosol.coherence.machine has a limitaion
# of 32 chars
$SYS_OPT="$SYS_OPT -Doracle.coherence.machine=$oracle_coherence_machine";
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.role=$role";

# Set coh home and start script so they will be part of input args

$SYS_OPT="$SYS_OPT -Doracle.coherence.home=$coherence_home";
$SYS_OPT="$SYS_OPT -Doracle.coherence.startscript=$start_script";

# set jmxremote.authenticate=true if $jmx_enable_auth is present.
# username/password needs to be set in $JDK_
HOME/jre/lib/management/jmxremote.password and

# $JDK_HOME/jre/lib/management/jmxremote.access files.
Uncomment the following block after adding these files.
#
if ($jmx_auth ne "") {
$SYS_OPT="$SYS_OPT -Dcom.sun.management.jmxremote.authenticate=$jmx_auth";
else {
$SYS_OPT="$SYS_OPT -Dcom.sun.management.jmxremote.authenticate=false";
}

# Default is true, so make sure to set it to false if not using authentication
# $SYS_OPT="$SYS_OPT -Dcom.sun.management.jmxremote.authenticate=false";
# set jmxremote.port only for management nodes, if user passes in.
# It enables monitoring from remote systems through this port.
if ($jmxport ne "") {
$SYS_OPT="$SYS_OPT -Dcom.sun.management.jmxremote.port=$jmxport";
}
#
# Define clusteraddress and clusterport if we have valid values.
#
if($clusteraddr ne "") {
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.clusteraddress=$clusteraddr";
}

if("$clusterport" ne "") {
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.clusterport=$clusterport";
}

if("$license_mode" ne "") {
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.mode=$license_mode";
}
#This is used to generate WKA override file. If you choose to use an existing
#override file, you can comment this out.
#Make sure you set "-Dtangosol.coherence.override" to the appropriate file name.
if("$wka_port" ne "") {
$wka_port = "\"".$wka_port."\"";
$wka_script = $agent_
home.$dsep."sysman".$dsep."admin".$dsep."scripts".$dsep."coherence".$dsep."genera
te-wka-override.pl";
print "executing $wka_script $wka_port\n";
if ( !&IsWindows() ) {
system("chmod 0700 $wka_script");
}
if(fork() == 0) {
exec("$wka_script $wka_port") or die "Could not execute
generate-wka-override.xml\n";
}
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.override=em-coherence-override.xml";
}
my $startup_class="";
my $cmd="";
# Note that Coherence lib is under $COHERENCE_HOME/coherence. Add any application
# specific jars to this classpath, if needed.
my $CLASSPATH=$coherence_home.$dsep."lib".$dsep."coherence.jar".$psep.$coherence
_home.$dsep."lib".$dsep."reporter.jar";
print "CLASSPATH: $CLASSPATH\n";
if($jamhost ne "" && $jamport ne "") {
$CLASSPATH=$CLASSPATH.$psep.$agent
_home.$dsep."archives".$dsep."jlib".$dsep."jamagent.war";
my $jamjvmid="$cluster/$member";
print "Using Oracle JVMD - $jamjvmid\n";
$SYS_OPT="$SYS_OPT -Doracle.coherence.jamjvmid=$jamjvmid";
$SYS_OPT="jamconshost=$jamhost $SYS_OPT";
$SYS_OPT="jamconsport=$jamport $SYS_OPT";
$SYS_OPT=" oracle.ad4j.groupidprop=$jamjvmid $SYS_OPT";
}
if ($bulkmbean ne "" && $jmxport ne "") {
# Management node with Bulk Operation MBean.
# add Oracle supplied jars for Bulk Operation MBean
$CLASSPATH=$CLASSPATH.$psep.$agent
_home.$dsep."..".$dsep."..".$dsep."lib".$dsep."coherenceEMIntg.jar".$psep.$agent
_home.$dsep."..".$dsep."..".$dsep."dependencies".$dsep."bulkoperationsmbean
_11.1.1.jar";
# Start MBeanServer
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.management=all";
print "Starting a management node with Bulk Operation MBean \n";
$startup_class="oracle.sysman.integration.coherence.EMIntegrationServer";
$cmd=$java_home.$dsep."bin".$dsep."java -cp $CLASSPATH $JVM_OPT $SYS_OPT $startup
_class";
} elsif ($jmxport ne "") {
# Management Node with out Bulk Operation MBean
# Start MBeanServer
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.management=all";
print "Starting a management node ...\n";
$startup_class="com.tangosol.net.DefaultCacheServer";
$cmd=$java_home.$dsep."bin".$dsep."java -cp $CLASSPATH $JVM_OPT $SYS_OPT $startup
_class";
} else {
# A simple managed node. Do not start MBeanServer.
$SYS_OPT="$SYS_OPT -Dtangosol.coherence.management=none";
print "Starting a simple managed node ...\n";
$startup_class="com.tangosol.net.DefaultCacheServer";
$cmd=$java_home.$dsep."bin".$dsep."java -cp $CLASSPATH $JVM_OPT $SYS_OPT $startup
_class";
}
if ( !&IsWindows() ) {
if (fork() == 0) {
print "Executing start script from child process... $cmd \n";
exec("$cmd") or die "Could not execute $cmd\n";
}
} else {
print "Command used to start node = $cmd\n";
exec($cmd);
}
print "exiting default start script\n";
exit 0;
sub IsWindows {
$osname = $^O;
if ( $osname eq "Windows_NT"
|| $osname eq "MSWin32"
|| $osname eq "MSWin64" )
{
return 1;
}
else {
return 0;
}
}

31.3.3.2.2 generate-wka-override.pl

「クラスタ通信」が「コヒーレンス・ノード・プロビジョニング: ターゲット選択」ページでWKAに設定されている場合、スクリプトはdefault-start-script.plによって起動されます。generate-wka-override.plは、オーバーライド・ファイルの生成に使用されます。独自のオーバーライド・ファイルがある場合は、default-start-script.plでgenerate-wka-override.plスクリプトを使用する部分をコメント・アウトできます。

#!/usr/local/bin/perl
#
# $Header: emas/sysman/admin/scripts/coherence/generate-wka-override.pl /main/1
# 2011/02/01 16:51:33 $
#
# generate-wka-override.pl
#
# Copyright (c) 2011, 2011, Oracle and/or its affiliates. All rights reserved.
#
# NAME
# generate-wka-override.pl - <one-line expansion of the name>
#
# DESCRIPTION
# <short description of component this file declares/defines>
# expects input args as:
# host1:port1,host2:port2,host3:port3
# writes the wka information to em-coherence-override.xml
# Sample xml file:
#<coherence xml-override="/tangosol-coherence-override-{mode}.xml">
# <cluster-config>
# <unicast-listener>
# <well-known-addresses>
# <socket-address id="1">
# <address>10.232.129.69</address>
# <port>8088</port>
# </socket-address>
# <socket-address id="2">
# <address>10.232.129.69</address>
# <port>8089</port>
# </socket-address>
# </well-known-addresses>
# <port>8088</port>
# </unicast-listener>
# </cluster-config>
#</coherence>
#
use Cwd;
use IPC::Open3;
my $host_port = $ARGV[0];
@host_port_array = split(',', $host_port);
$size = @host_port_array;

my $xmlfile="em-coherence-override.xml";
print "$xmlfile\n";
open(XMLFL,"> $xmlfile");
print XMLFL "<coherence
xml-override=\"/tangosol-coherence-override-{mode}.xml\">\n";
print XMLFL "<cluster-config>\n";
print XMLFL "<unicast-listener>\n";
print XMLFL "<well-known-addresses>\n";

my $id = 1;
for($i = 0; $i < $size; $i++) {
$single_host_port = $host_port_array[$i];
$single_host_port =~ s/^\s+|\s+$//g;
@single_host_port_array = split(':', $single_host_port);
$wka_host = $single_host_port_array[0];
$wka_port = $single_host_port_array[1];
$id = $id + $i;
print XMLFL "<socket-address id=\"$id\">\n";
print XMLFL "<address>$wka_host</address>\n";
print XMLFL "<port>$wka_port</port>\n";
print XMLFL "</socket-address>\n";
}
print XMLFL "</well-known-addresses>\n";
print XMLFL "</unicast-listener>\n";
print XMLFL "</cluster-config>\n";
print XMLFL "</coherence>";
close(XMLFL);
exit 0;

31.4 トラブルシューティング

コヒーレンス・クラスタ内に異なるマシンで実行されている2つ以上の管理ノードを設定することをお薦めします。監視で障害が発生した場合は、2番目の管理ノードを使用できます。一般的な障害の事例を次に示します。

- エラー条件: 管理ノードの消失
解決策: プライマリ管理ノードに障害が発生した場合、クラスタの監視構成を、クラスタ内の別の管理ノードを指定するように変更する必要があります。クラスタ内に他の管理ノードが存在しない場合は、「コヒーレンス・ノード・プロビジョニング」デプロイメント・プロシージャを使用して、既存のクラスタを選択し、新規の管理ノードを追加できます。このプロセスにより、クラスタの監視構成が更新されます。

- エラー条件: クラスタを監視するエージェントの消失
解決策: エージェントが使用可能でない場合、別の管理エージェントを使用して、コヒーレンス・クラスタの管理ノードを指定します。

- エラー条件: EMエージェントおよび管理ノードが存在するホストの消失
解決策: ホストが使用可能でない場合、別のマシンで実行されている別の管理ノードに切り替える必要があります。

32 SOAアーティファクトおよびコンポジットのプロビジョニング

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用してSOAアーティファクトおよびコンポジットをプロビジョニングする方法について説明します。この章の具体的な内容は次のとおりです。

- SOAアーティファクトのプロビジョニングの概要

- SOAアーティファクトのプロビジョニングの理解

- デプロイメント・プロシージャ、サポートされるリリース、およびデプロイされるコア・コンポーネント

- SOAアーティファクトのプロビジョニング

- SOAコンポジットのデプロイ

注意:
Enterprise Manager 12cリリース4では、SOA 11gアーティファクトのプロビジョニングをサポートします。SOA 12cアーティファクトはプロビジョニングできないことに注意してください。

32.1 SOAアーティファクトのプロビジョニングの概要

この項では、この章の手引きとして、SOAアーティファクトおよびコンポジットのプロビジョニングに関連する手順の概要を示します。この項は、SOAアーティファクトおよびコンポジットのプロビジョニングを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表32-1 SOAアーティファクトおよびコンポジットのプロビジョニングの概要

ステップ

説明

参照リンク

ステップ1

デプロイメント・プロシージャの理解

Cloud Controlで提供されている、SOAアーティファクトおよびコンポジットをプロビジョニングするための2つのデプロイメント・プロシージャについて理解します。2つのデプロイメント・プロシージャの機能、その対象となるユースケース、サポートされるリリース、およびプロビジョニングされるコア・コンポーネントについて把握します。

デプロイメント・プロシージャの詳細は、第32.3項を参照してください。

ステップ2

プロビジョニングするデプロイメント・プロシージャの選択

この章では、各種のSOAコンポーネントに関連するユースケースを示します。プロビジョニングするコンポーネントを特定し、それに対応するユースケースについて理解します。

- SOAアーティファクトのプロビジョニングの詳細は、第32.4項を参照してください。

- SOAコンポジットのプロビジョニングの詳細は、第32.5項を参照してください。

ステップ3

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

SOAアーティファクトおよびコンポジットをプロビジョニングするための前提条件の詳細は、手順2に示されている参照リンクにアクセスし、「前提条件」の項を参照してください。

ステップ4

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行して、SOAアーティファクトおよびコンポジットをプロビジョニングします。

SOAアーティファクトおよびコンポジットをプロビジョニングするには、手順2に示されている参照リンクにアクセスし、「前提条件」の項を参照してください。

32.2 SOAアーティファクトのプロビジョニングの理解

SOAアーティファクト・デプロイメント・プロシージャでは、SOAコンポジット、Webサービス・ポリシー、ポリシー・ストアおよび資格証明ストアのプロビジョニングをサポートしています。

以降に、SOAアーティファクトのプロビジョニングで使用される用語を示します。

SOAコンポジット

SOAコンポジットは論理構成です。そのコンポーネントは、1つのコンピュータで1つのプロセスにより実行することも、複数のコンピュータで複数のプロセスに分散することもできます。アプリケーション全体が1つのコンポジットのみで構成されることも、複数の異なるコンポジットの組合せで構成されることもあります。各コンポジットを構成する複数のコンポーネントで、同じテクノロジが使用されていることも、別々のテクノロジを使用して構築されていることもあります。

SOA Infraドメイン

SOAインフラストラクチャ・ドメインは、soa-infraバイナリを含むWebLogicドメインです。SOAインフラストラクチャには、SOAコンポジット・アプリケーション内の個々のコンポーネントのビジネス・ロジック(BPELプロセスなど)を実行する一連のサービス・エンジン(BPELプロセス、ヒューマン・ワークフロー、デシジョン・サービスおよびOracle Mediator)が含まれています。

Webサービス

Webサービスは、様々なXMLベース言語を使用してリモートにアクセスできるプログラムです。このプログラムで何を実行するか(どのような機能を実装するか)は、Webサービス記述言語(WSDL)と呼ばれる標準XMLボキャブラリで記述します。たとえば、銀行業務Webサービスは、口座の確認、取引明細書の印刷、資金の預入れや引出しを行う機能を実装します。これらの機能は、銀行Webサービスにアクセスするすべてのコンシューマが呼び出すことのできるWSDLファイル内に記述されています。このため、コンシューマ側でWebサービスについて把握しておく必要があることは、実行できる内容が記述されているWSDLファイルのことのみです。

Webサービス・コンシューマ(たとえば、デスクトップ・アプリケーション、Javaプラットフォーム、ポートレットなどのEnterprise Editionクライアント)からWebサービスを呼び出すには、Webサービス・プロバイダに対してXMLドキュメント形式のリクエストを送信します。Webサービス・プロバイダは、リクエストを処理し、その結果をXMLドキュメント形式でWebサービス・コンシューマに返します。

WSポリシーおよびアサーション

ポリシーとは、メッセージが保護されるかどうか、その保護方法、および信頼性の高いメッセージの配信方法など、Webサービスの機能と要件を示します。ポリシーは、信頼できるメッセージング、管理、WS-Addressing、セキュリティおよびMTOMのいずれかのカテゴリに属します。

ポリシーは1つ以上のアサーションで構成されます。ポリシー・アサーションは、特定のアクションを実行するポリシーの最小単位です。ポリシー・アサーションはリクエスト・メッセージおよびレスポンス・メッセージに対して実行され、同じアサーション・セットが両方のタイプのメッセージに対して実行されます。アサーションはポリシーに表示されている順序で実行されます。ポリシーなどのアサーションは、信頼できるメッセージング、管理、WS-Addressing、セキュリティ、およびMTOMのいずれかのカテゴリに属します。

ポリシー・ストア

ポリシー・ストアは、システムおよびアプリケーションに固有のポリシーとロールを格納するリポジトリです。アプリケーション・ロール(管理ロールなど)には、アプリケーション固有のエンタープライズ・ユーザーおよびグループを指定できます。ポリシーでは、これらのグループまたはユーザーをプリンシパルとして使用できます。ポリシー・ストアには、ファイルベースまたはLDAPベースのものがあります。ファイルベースのポリシー・ストアはXMLファイルであり、このストアは即時利用できるポリシー・ストア・プロバイダです。LDAPベースのポリシー・ストアでは、Oracle Internet DirectoryまたはOracle Virtual DirectoryのいずれかのLDAPサーバーを使用できます(ローカル・ストア・アダプタ(LSA)を使用)。

資格証明ストア

資格証明ストアは、ユーザー、Javaコンポーネントおよびシステム・コンポーネントの認証レベルを認定するセキュリティ・データ(資格証明)のリポジトリです。資格証明には、ユーザー名とパスワードの組合せ、チケットまたは公開鍵証明書を保持できます。このデータは、認証の際、プリンシパルをサブジェクトに移入するときに使用し、さらに認可時には、サブジェクトが実行できるアクションを決定するときに使用します。

ヒューマン・ワークフロー

ヒューマン・ワークフロー・コンポーネントは、エンド・ユーザーへのプレゼンテーションと同様、作成、割当て、有効期限、期限、および通知を含むヒューマン・タスクのライフサイクルを管理する役割を果たします。宣言的なパターンを利用し、ビジネス・ルールと強固に一体化した、洗練された動的なタスク・ルーティングをサポートします。ヒューマン・ワークフローの主なサブコンポーネントには、Task editor、Task Service Engine、およびWorklistアプリケーションの3つがあります。

Oracle B2B

Oracle B2Bは、ビジネスにおけるセキュアで信頼できるドキュメントのやりとりを提供します。たとえば、小売、供給および製造などのビジネスです。このタイプの電子商取引では、B2Bは成熟したビジネス文書および昔ながらのビジネス・プロセス、業界独自のメッセージング・サービスを特徴とし、完全なエンド・ツー・エンドのビジネス・プロセスを管理するアーキテクチャを必要とします。Oracle SOA Suiteのコンポーネントとして、Oracle B2Bはこの課題に対応し、ビジネス・プロセスのプラットフォーム、エンド・ツー・エンドのインスタンス追跡、可視性、監査、プロセス・インテリジェンス、統治、セキュリティの統合を可能にするアーキテクチャを提供します。

32.3 デプロイメント・プロシージャ、サポートされるリリース、およびデプロイされるコア・コンポーネント

Cloud Controlには、SOAアーティファクトおよびコンポジットをプロビジョニングするための次のデプロイメント・プロシージャが用意されています。

デプロイメント・プロシージャ

サポートされているリリース

移行されるアーティファクト

SOAアーティファクトのプロビジョニング

Oracle SOA Suite 11gR1パッチ・セット1からパッチ・セット4 (11.1.1.2.0から11.1.1.5.0)

- SOAコンポジット

- Oracle WebLogic Serverポリシー

- アサーション・テンプレート

- JPSポリシーおよび資格証明ストア

- ヒューマン・ワークフロー

- Oracle B2B

SOAコンポジットのデプロイ

Oracle SOA Suite 11gR1パッチ・セット1からパッチ・セット4 (11.1.1.2.0から11.1.1.5.0)

- SOAコンポジット

注意:
Microsoft Windows Vistaでは、ソフトウェア・ライブラリからのゴールド・イメージのプロビジョニングはサポートされていません。

注意:
ヒューマン・ワークフロー・アーティファクトおよびB2Bアーティファクトのクローニングはサポートされていません。ヒューマン・ワークフロー・アーティファクトのクローニングの詳細は、『Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド』を参照してください。B2Bアーティファクトのクローニングの詳細は、『Oracle Fusion Middleware Oracle B2Bユーザーズ・ガイド』を参照してください。これらのガイドは次の場所から入手可能です。
http://docs.oracle.com/docs/cd/E14571_01/index.htm

32.4 SOAアーティファクトのプロビジョニング

この項では、SOAアーティファクトをプロビジョニングする方法について説明します。この項の具体的な内容は次のとおりです。

- 参照インストールからのSOAアーティファクトのプロビジョニング

- ゴールド・イメージからのSOAアーティファクトのプロビジョニング

32.4.1 参照インストールからのSOAアーティファクトのプロビジョニング

この項では、異なるsoa-infraドメイン間でSOAアーティファクトをプロビジョニングする方法について説明します。

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

- 第32章に示されている前提条件を満たしていることを確認します。

- Oracle SOA Suite 11gおよびその基礎となるOracle WebLogic Serverドメインがすでにプロビジョニングされていることを確認します。

- (soa-infraドメインのみでなく)ソースのOracle WebLogic ServerドメインとターゲットのOracle WebLogic Serverドメイン内のすべてのコンポーネントが起動され、実行されていることを確認します。

- ソースおよび宛先のsoa-infraドメインのバージョンが同じであることを確認します。

参照インストールからSOAアーティファクト(コンポジット、Webサービス・ポリシー、JPS構成)をプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. 「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ・ライブラリ」サブタブで、表から「SOAアーティファクトのプロビジョニング」デプロイメント・プロシージャを選択します。「起動」を選択し、「実行」をクリックします。デプロイメント・プロシージャの「ソースの選択」ページが表示されます。

注意:
このデプロイメント・プロシージャには、次の方法でアクセスすることもできます。
「SOAインフラストラクチャ」ホームページから、次の手順を実行します。

1. 「ターゲット」メニューから、「ミドルウェア」をクリックします。

2. 「ミドルウェア」ページで、タイプが「SOAインフラストラクチャ」のターゲットをクリックします。

3. 「SOAインフラストラクチャ」ホームページで、SOAインフラストラクチャ固有のメニューから「SOAアーティファクトのプロビジョニング」を選択します。

3. 「ソースの選択」ページで、次を実行します。

1. デフォルトの選択(「参照環境からのプロビジョニング」)を保持します。

2. 「ドメイン名」フィールドに対する懐中電灯アイコンをクリックします。SOAアーティファクトのデプロイ元のOracle WebLogic Serverドメインを検索して選択します。ソースのOracle WebLogic Serverドメインが起動され、実行されていることを確認します。

3. 「資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトのセクション(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。Oracle WebLogic Serverドメインの資格証明とOracle WebLogic管理サーバー・ホストの資格証明を指定するように要求されます。「Oracle WebLogic Serverドメインの資格証明」セクションで、WebLogic Server管理コンソールへのアクセスに使用できる管理者資格証明を指定します。「Oracle WebLogic管理サーバー・ホストの資格証明」セクションで、管理サーバーをインストールしたユーザーのオペレーティング・システム資格証明を指定します。

4. オプションで、SOAアーティファクトをイメージとしてソフトウェア・ライブラリに保存する場合は、「SOAアーティファクトのゴールド・イメージをソフトウェア・ライブラリに保存します」を選択します。
たとえば、将来的にこの特定バージョンを他のOracle WebLogic Serverドメインにプロビジョニングする場合は、参照インストールを使用すると停止する可能性があるため、ソフトウェア・ライブラリに保存したゴールド・イメージを使用できます。

5. 「次へ」をクリックします。

4. 接続先の選択ページで、次を実行します。

1. 「ドメイン名」フィールドに対する懐中電灯アイコンをクリックします。SOAアーティファクトのデプロイ元のOracle WebLogic Serverドメインを検索して選択します。宛先のOracle WebLogic Serverドメインが起動され、実行されていることを確認します。

2. 「資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。Oracle WebLogic Serverドメインの資格証明とOracle WebLogic管理サーバー・ホストの資格証明を指定するように要求されます。「Oracle WebLogic Serverドメインの資格証明」セクションで、WebLogic Server管理コンソールへのアクセスに使用できる管理者資格証明を指定します。「Oracle WebLogic管理サーバー・ホストの資格証明」セクションで、管理サーバーをインストールしたユーザーのオペレーティング・システム資格証明を指定します。

3. 「次へ」をクリックします。

5. アーティファクトの選択ページで、次の手順を実行します。

1. 「プロビジョニングするSOAアーティファクトのタイプの選択」セクションで、「SOAコンポジット」、「Webサービス・ポリシー」および「Javaプラットフォーム・セキュリティ構成」を選択します。

2. 「次へ」をクリックします。

6. 「SOAコンポジット」ページで、次の手順を実行します。

1. プロビジョニングするコンポジットを選択し、ソフトウェア・ライブラリまたはディレクトリから構成プランを指定します。
構成プランは宛先マシンのディレクトリに格納することをお薦めします。あるいは、構成プランを宛先マシンからアクセス可能な他の共有場所に格納することもできます。

コンポジットがすでに宛先ホストに存在する場合は、「上書き」を選択して、既存のコンポーネントをソース・ドメインのコンポジットで上書きします。

2. 「次へ」をクリックします。

7. 「Webサービス・ポリシー」ページで、次の手順を実行します。

1. 「アサーション・テンプレート」セクションで、移行するアサーション・テンプレートを選択します。

2. 「Webサービス・ポリシー」セクションで、移行するポリシーを選択します。

3. 「次へ」をクリックします。

8. 「Javaプラットフォーム・セキュリティ」ページで、次の手順を実行します。

1. 「ポリシー・ストアと資格証明ストアの移行」セクションで、「ポリシー・ストアの移行」チェック・ボックスと「資格証明ストアの移行」チェック・ボックスを選択します。
ソースおよびターゲットのプロバイダのリストを表示するには、「プロバイダの詳細」リンクをクリックします。

2. 「次へ」をクリックします。

9. 「ヒューマン・ワークフロー」ページで、「ビュー」、「フレックス・フィールド・マッピング」および「属性ラベル」などの移行するすべてのワークフロー・アーティファクトを選択して、「次へ」をクリックします。

10. B2Bアーティファクトページで、「取引パートナ」、「取引契約」および「ドキュメント・プロトコル」などの移行するすべてのB2Bアーティファクトを選択して、「次へ」をクリックします。

11. スケジュール・ページで、デプロイメント・プロシージャを即時に、または後で実行するようにスケジュールします。

12. 「確認」ページで、SOAアーティファクトをプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

32.4.2 ゴールド・イメージからのSOAアーティファクトのプロビジョニング

この項では、ソフトウェア・ライブラリに格納されているゴールド・イメージからSOAアーティファクト(コンポジット、Webサービス・ポリシー、JPS構成)をプロビジョニングする方法について説明します。この項の具体的な内容は次のとおりです。

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

- 第2章に示されている前提条件を満たしていることを確認します。

- Oracle SOA Suite 11gおよびその基礎となるOracle WebLogic Serverドメインがすでにプロビジョニングされていることを確認します。

- ソースおよび宛先のsoa-infraドメインのバージョンが同じであることを確認します。

- 参照インストールからSOAアーティファクトをプロビジョニングする際には、ゴールド・イメージがすでにソフトウェア・ライブラリに保存されていることを確認します。

ゴールド・イメージからSOAアーティファクトをプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」をクリックします。

2. 「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ・ライブラリ」サブタブで、表から「SOAアーティファクトのプロビジョニング」デプロイメント・プロシージャを選択します。「起動」を選択し、「実行」をクリックします。デプロイメント・プロシージャの「ソースの選択」ページが表示されます。

注意:
このデプロイメント・プロシージャには、次の方法でアクセスすることもできます。

- 「SOAインフラストラクチャ」ホームページから、次の手順を実行します。

1. 「ターゲット」メニューから、「ミドルウェア」をクリックします。

2. 「ミドルウェア」ページで、タイプが「SOAインフラストラクチャ」のターゲットをクリックします。

3. 「SOAインフラストラクチャ」ホームページで、SOAインフラストラクチャ固有のメニューから「SOAアーティファクトのプロビジョニング」を選択します。

3. 「ソースの選択」ページで、次を実行します。

1. 「ゴールド・イメージからのプロビジョニング」を選択します。

2. ゴールド・イメージ名フィールドに対する懐中電灯アイコンをクリックします。SOAアーティファクトのプロビジョニング元のゴールド・イメージを検索して選択します。

3. 「次へ」をクリックします。

4. 接続先の選択ページで、次を実行します。

1. 「ドメイン名」フィールドに対する懐中電灯アイコンをクリックします。SOAアーティファクトのデプロイ元のOracle WebLogic Serverドメインを検索して選択します。

2. 「資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトのセクション(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。Oracle WebLogic Serverドメインの資格証明とOracle WebLogic管理サーバー・ホストの資格証明を指定するように要求されます。「Oracle WebLogic Serverドメインの資格証明」セクションで、WebLogic Server管理コンソールへのアクセスに使用できる管理者資格証明を指定します。「Oracle WebLogic管理サーバー・ホストの資格証明」セクションで、管理サーバーをインストールしたユーザーのオペレーティング・システム資格証明を指定します。

3. 「次へ」をクリックします。

5. アーティファクトの選択ページで、次の手順を実行します。

1. 「プロビジョニングするSOAアーティファクトのタイプの選択」セクションで、「SOAコンポジット」、「Webサービス・ポリシー」および「Javaプラットフォーム・セキュリティ構成」を選択します。

2. 「次へ」をクリックします。

6. 「SOAコンポジット」ページで、次の手順を実行します。

1. プロビジョニングするコンポジットを選択し、ソフトウェア・ライブラリまたはディレクトリから構成プランを指定します。
コンポジットがすでに宛先ホストに存在する場合は、「上書き」を選択して、既存のコンポーネントをソース・ドメインのコンポジットで上書きします。

2. 「次へ」をクリックします。

7. 「Webサービス・ポリシー」ページで、次の手順を実行します。

1. 「アサーション・テンプレート」セクションで、移行するアサーション・テンプレートを選択します。

2. 「Webサービス・ポリシー」セクションで、移行するポリシー・アサーションを選択します。

3. 「次へ」をクリックします。

8. 「Javaプラットフォーム・セキュリティ」ページで、次の手順を実行します。

1. 「ポリシー・ストアと資格証明ストアの移行」セクションで、「ポリシー・ストアの移行」チェック・ボックスと「資格証明ストアの移行」チェック・ボックスを選択します。
ターゲットのプロバイダのリストを表示するには、「プロバイダの詳細」リンクをクリックします。

2. 「次へ」をクリックします。

9. 「ヒューマン・ワークフロー」ページで、「ビュー」、「フレックス・フィールド・マッピング」および「属性ラベル」などの移行するすべてのワークフロー・アーティファクトを選択して、「次へ」をクリックします。

10. B2Bアーティファクトページで、「取引パートナ」、「取引契約」および「ドキュメント・プロトコル」などの移行するすべてのB2Bアーティファクトを選択して、「次へ」をクリックします。

11. 「確認」ページで、SOAアーティファクトをプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

32.5 SOAコンポジットのデプロイ

この項では、SOAコンポジットをデプロイする方法について説明します。この項の内容は次のとおりです。

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

- 第32章に示されている前提条件を満たしていることを確認します。

- Oracle SOA Suite 11gおよびその基礎となるOracle WebLogic Serverドメインがすでにプロビジョニングされていることを確認します。

- ソースおよび宛先のsoa-infraドメインのバージョンが同じであることを確認します。
ドメインには、SOAインフラストラクチャ・アプリケーションが実行されている管理対象サーバーが1つ以上存在する必要があります。SOAクラスタの場合、コンポジットがクラスタ内のいずれか1つの管理対象サーバーにデプロイされます。

- SOAコンポジットがソフトウェア・ライブラリか、管理サーバー・ホストからアクセス可能なファイル・システム内に存在していることを確認します。

SOAコンポジットをプロビジョニングするには、次の手順に従います。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. 「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ・ライブラリ」サブタブで、表から「SOAコンポジットのデプロイ」デプロイメント・プロシージャを選択します。「起動」を選択し、「実行」をクリックします。Cloud Controlでデプロイメント・プロシージャの「宛先の選択」ページが表示されます。

3. 「宛先」ページで、次の手順を実行します。

1. 「宛先ドメイン名」フィールドに対する懐中電灯アイコンをクリックします。SOAコンポジットのデプロイ先のOracle WebLogic Serverドメインを検索して選択します。

2. 「資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトのセクション(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。Oracle WebLogic Serverドメインの資格証明とOracle WebLogic管理サーバー・ホストの資格証明を指定するように要求されます。「Oracle WebLogic Serverドメインの資格証明」セクションで、WebLogic Server管理コンソールへのアクセスに使用できる管理者資格証明を指定します。「Oracle WebLogic管理サーバー・ホストの資格証明」セクションで、管理サーバーをインストールしたユーザーのオペレーティング・システム資格証明を指定します。

3. 「次へ」をクリックします。

4. 「ソース」ページで、次の手順を実行します。

1. 「コンポジット」セクションで、「追加」をクリックします。「コンポジット・ソース」で、コンポジットの場所に応じて「ソフトウェア・ライブラリ」または「ファイル・システム」を選択します。「プランのソース」の場所およびパスを選択します。
コンポジットがすでに宛先ホストに存在する場合は、「上書き」を選択して、既存のコンポーネントをソース・ドメインのコンポジットで上書きします。ここでデプロイするコンポジットをデフォルトのコンポーネントとして設定する場合は、「デフォルトを強制使用」の選択を保持します。

2. 宛先ドメインに存在しないアダプタを無視し、プロビジョニング操作を続行する場合は、「オプション」セクションで「アダプタ依存性の確認」を選択します。各コンポジットが1つ以上のアダプタを参照している場合、宛先ドメインに依存アダプタが存在しないと、コンポジットが適切に動作しないことがあります。しかし、このオプションを選択すると、このような存在しないアダプタをすべて無視できます。

3. 「次へ」をクリックします。

5. スケジュール・ページで、デプロイメント・プロシージャを即時に、または後で実行するようにスケジュールします。

6. 「確認」ページで、SOAコンポジットをプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

33 Oracle Service Busリソースのプロビジョニング

Oracle Service Busは、異種サービス間の相互作用を接続、仲介および管理する、エンタープライズクラスのサービスです。Oracle Service Busは、サービス構成、統合およびデプロイメントを促進することにより、サービス指向アーキテクチャ(SOA)にわたる共有サービスの管理を簡略化します。

Oracle Service Busのリソースは、個々のプロジェクトに編成できます。プロジェクトは、非階層型の分離された最上位グループ構成要素です。すべてのリソース(ビジネス・サービス、プロキシ・サービス、WS-Policy、WSDL、スキーマ、XQuery変換、JARなど)が、重ならない1つのプロジェクトに存在します。リソースは、プロジェクトのすぐ下に作成するか、フォルダにさらに整理できます。フォルダは、プロジェクトの内部または他のフォルダの内部に作成できます。フォルダはファイル・システム内のディレクトリに似ており、プロジェクト・レベルがルート・ディレクトリです。

Oracle Enterprise Manager Cloud Control (Cloud Control)では、これらのOracle Service Busターゲットを検出および監視できますが、Oracle Service Busリソースのプロビジョニングに使用できるデプロイメント・プロシージャも用意されています。

この章では、Oracle Service Busリソースをプロビジョニングする方法について説明します。この章の具体的な内容は次のとおりです。

- Oracle Service Busリソースのプロビジョニングの概要

- サポートされているリリース

- Oracle Service BusドメインからのOracle Service Busリソースのプロビジョニング

- Oracleソフトウェア・ライブラリからのOracle Service Busリソースのプロビジョニング

33.1 Oracle Service Busリソースのプロビジョニングの概要

この項では、この章の手引きとして、Oracle Service Busリソースのプロビジョニングに関連する手順の概要を示します。この項は、Oracle Service Busリソースのプロビジョニングを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表33-1 Oracle Service Busリソースのプロビジョニングの概要

ステップ

説明

参照リンク

手順1

サポートされているリリースの把握

このデプロイメント・プロシージャによりプロビジョニングできるOracle Service Busのリリースを把握します。

デプロイメント・プロシージャでサポートされているリリースについては、第33.2項を参照してください。

手順2

ユースケースの選択

この章では、Oracle Service Busリソースのプロビジョニングに関連するユースケースをいくつか示します。ご自身の要件に最適なユースケースを選択してください。

- Oracle Service BusドメインからのOracle Service Busリソースのプロビジョニングの詳細は、第33.3項を参照してください。

- ソフトウェア・ライブラリからのOracle Service Busリソースのプロビジョニングの詳細は、第33.5項を参照してください。

手順3

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

- Oracle Service BusドメインからOracle Service Busリソースをプロビジョニングするための前提条件の詳細は、第33.3項を参照してください。

- ソフトウェア・ライブラリからOracle Service Busリソースをプロビジョニングするための前提条件の詳細は、第33.5項を参照してください。

手順4

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行して、Oracle Service Busリソースをプロビジョニングします。

- Oracle Service BusドメインからOracle Service Busリソースをプロビジョニングするには、第33.3項で説明されている手順を実行します。

- ソフトウェア・ライブラリからOracle Service Busリソースをプロビジョニングするには、第33.5項で説明されている手順を実行します。

33.2 サポートされているリリース

このデプロイメント・プロシージャを使用すると、Oracle Service Bus 2.6、2.6.1、3.0および10gR3 (3.1)のリソースをプロビジョニングできます。

33.3 Oracle Service BusドメインからのOracle Service Busリソースのプロビジョニング

この項では、Oracle Service Busドメインから直接Oracle Service Busリソースをプロビジョニングする方法について説明します。

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

デザイナの前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- (エクスポートするリソースが含まれる)ソースOracle Service Busが、Cloud Controlですでに検出されて監視されていることを確認します。

- カスタマイズ・ファイルを使用して変更後の(ターゲット)環境の環境変数をカスタマイズする場合は、Oracleソフトウェア・ライブラリ内でそのカスタマイズ・ファイルが汎用コンポーネントとして使用可能になっていることを確認する必要があります。汎用コンポーネントの作成手順は、第2.2項を参照してください。

オペレータの前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第2.3項を参照してください。

ソースのOracle Service BusドメインからOracle Service Busリソースをプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. 「デプロイメント・プロシージャ」セクションで、リストから「Oracle Service Busリソース・プロビジョニング」プロシージャを選択し、「起動」をクリックします。

3. 「ソース選択」ページの「ソース」セクションで、「Oracle Service Busドメイン」を選択します。

1. 「ドメイン」で懐中電灯アイコンをクリックし、ターゲットのOracle Service Busドメインにエクスポートしてデプロイするリソースが含まれるソースのOracle Service Busドメインを選択します。ウィザードの次のページでは、エクスポートするドメインのプロジェクトを選択できます。

2. 「BEAホーム・ディレクトリ」で、すべてのBEA製品関連ファイルが格納されるBEAホーム・ディレクトリのフルパスを指定します。たとえば、/home/mark/beaのように指定します。

3. 「次へ」をクリックします。

4. 「プロジェクトの選択」ページで、次の手順を実行します。

1. 「リソース概要」セクションで、エクスポートしてターゲットOSBドメインにデプロイするプロジェクトを選択します。選択したプロジェクトがJARファイルにエクスポートされ、ターゲットOSBドメインが稼働しているホストにそのJARファイルが移動されます。

選択したプロジェクトのリソースのうち、ターゲットOSBドメインには存在するがエクスポート済のJARファイルには存在しないものは削除されます。

2. 「エクスポート・モード」セクションで、次のいずれかを実行します。
プロジェクト・レベルでリソースをエクスポートする場合は、「プロジェクトのエクスポート」を選択します。エクスポート済のJARファイルがターゲット・ホストにデプロイされるとき、プロジェクト全体がデプロイされます。このとき、ターゲット・ホスト上のリソースの可用性に応じて、リソースが追加、上書きまたは削除されることがあります。

リソース・レベルでリソースをエクスポートする場合は、「リソースのエクスポート」を選択します。エクスポート済のJARファイルがターゲット・ホストにデプロイされるとき、リソースのみがデプロイされます。このとき、ターゲット・ホスト上のリソースの可用性に応じて、リソースが追加または上書きされることがあります。

これらのオプションをさらに深く理解するには、第33.4項で説明されているユースケースをお読みください。

3. (オプション)エクスポートするプロジェクトに機密データを含むリソースが存在する場合は、「セキュリティ・オプション」セクションで、リソースを保護するためのパスフレーズを指定します。デプロイメント中、保護リソースをインポートするために同じパスフレーズが使用されます。

4. (オプション)エクスポート済のプロジェクトJARファイルを汎用コンポーネントとしてソフトウェア・ライブラリに保存する場合は、「ソフトウェア・ライブラリにプロジェクトを保存」セクションで「ソフトウェア・ライブラリにプロジェクトを保存」を選択し、コンポーネントの名前と場所を指定します。

デフォルトでは、ここで選択したプロジェクトがJARファイルにエクスポートされ、ターゲットのOracle Service Busドメインの管理サーバーが実行されているホストに移動されます。ただし、JARファイルが今後使用するためにソフトウェア・ライブラリに保存されるわけではありません。このオプションを使用すると、JARファイルを1つのコンポーネントとしてソフトウェア・ライブラリに保存できます。

5. 「ターゲットの選択」ページで、次の手順を実行します。

1. 「ターゲット」セクションで、次の項目を指定します。
「ドメイン」で懐中電灯アイコンをクリックし、選択したリソースをデプロイする先のOracle Service Busドメインを選択します。

「BEAホーム・ディレクトリ」で、すべてのBEA製品関連ファイルが格納されるBEAホーム・ディレクトリのフルパスを指定します。

2. (オプション)デプロイメントで選択したリソースをカスタマイズした場合、ターゲットのOracle Service Busドメインでもこれらの変更内容を保持するには、「拡張オプション」セクションで保持する設定を選択します。

Oracle Service Bus 2.6.xの場合、「セキュリティおよびポリシーの構成」、「資格証明」および「アクセス制御ポリシー」は保持できません。

3. 「カスタマイズ」セクションで、ターゲットOSBドメインで環境設定を変更する場合に使用できるカスタマイズ・ファイルの詳細を入力します。

カスタマイズ・ファイルを使用しない場合は、「なし」を選択します。

カスタマイズ・ファイルを使用している場合、ターゲットOSBドメインが稼働しているホスト上でそのカスタマイズ・ファイルが使用可能であれば、「ターゲット・ホストのカスタマイズ・ファイルを使用します」を選択し、ファイルの場所のフルパスを指定します。

カスタマイズ・ファイルを汎用コンポーネントとしてOracleソフトウェア・ライブラリに格納する場合は、「カスタマイズ・ファイルをソフトウェア・ライブラリから選択します」を選択し、Oracleソフトウェア・ライブラリ内の汎用コンポーネントの格納先のフルパスを指定します。

4. 「次へ」をクリックします。

6. 「資格証明の設定」ページで、次の項目を指定して「次へ」をクリックします。

1. ソースおよびターゲットのOracle Service Bus (OSB)ドメインのログイン資格証明を指定します。

2. OSBドメインの管理サーバーを監視している管理エージェントが稼働しているホストの資格証明を指定します。

7. 「スケジュール」ページで、デプロイメント・インスタンス名を指定します。プロシージャを即時に実行する場合は、デフォルトの選択(「1回(即時)」)を保持します。プロシージャを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。デプロイメント・プロシージャのステータスに応じて、通知プリファレンスを設定できます。前提条件のみを実行する場合は、「前提条件チェックの実行後に結果を分析するためにプロシージャを停止します」を選択すると、すべての前提条件チェックの実行後にプロシージャ実行を一時停止できます。「次へ」をクリックします。

8. 確認ページで、デプロイメント・プロシージャに対して指定した詳細を確認します。その詳細で問題がない場合は、「発行」をクリックし、スケジュール・セットに従ってデプロイメント・プロシージャを実行します。詳細を変更する場合は、そのセクションにある「編集」リンクをクリックして変更するか、または「戻る」のクリックを繰り返して変更したいページに戻ります。

9. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各手順の「ステータス」リンクをクリックすると、各手順の実行の詳細が表示されます。ロギング・レベルを「デバッグ」に設定するには、「デバッグ」をクリックし、プロシージャの実行を停止するには、「停止」をクリックします。

33.4 OSBリソースのエクスポート・モードの理解

この項では様々なユースケースについて説明し、それらの状況でエクスポート・モードがどのように動作するかを示します。

最初の列は、ソース・ドメインから選択したプロジェクトと、選択したプロジェクトに含まれるリソースを示し、第2列は、ターゲット・ドメイン内でのそのプロジェクトの可用性を示します。第3列には、プロジェクト・レベルでエクスポートの動作が表示され、第4列にはリソース・レベルでエクスポートの動作が表示されます。

表33-2 エクスポート・モードの理解

ソース・ドメイン

ターゲット・ドメイン

プロジェクト・レベルでのエクスポート

リソース・レベルでのエクスポート

ソース・ドメインから、Resource_1、Resource_2およびResource_3が含まれるProject_1を選択した。

ターゲット・ドメインにはプロジェクトが1つも存在しない。

Project_1全体がターゲット・ドメインにデプロイされます。

Project_1全体がターゲット・ドメインにデプロイされます。

ソース・ドメインから、Resource_1、Resource_2およびResource_3が含まれるProject_1を選択した。

ターゲット・ドメインには、Resource_1が含まれるProject_1が存在する。

Project_1全体がターゲット・ドメインにデプロイされます。このとき、Resource_1はターゲット・ドメインですでに使用可能になっているため上書きされ、Resource_2およびResource_3は追加されます。

Project_1のリソースのみがターゲット・ドメインにデプロイされます。このとき、Resource_1はターゲット・ドメインですでに使用可能になっているため上書きされ、Resource_2およびResource_3は追加されます。

ソース・ドメインから、Resource_1が含まれるProject_1を選択した。

ターゲット・ドメインには、Resource_1、Resource_2およびResource_3が含まれるProject_1が存在する。

Project_1全体がターゲット・ドメインにデプロイされます。このとき、Resource_1はターゲット・ドメインですでに使用可能になっているため上書きされ、Resource_2およびResource_3は削除されます。

Project_1のリソースのみがターゲット・ドメインにデプロイされますが、Resource_1はターゲット・ドメインですでに使用可能になっているため、Resource_1のみが上書きされます。ターゲット・ドメインですでに使用可能な他の2つのリソース(Resource_2およびResource_3)は、影響を受けません。

33.5 Oracleソフトウェア・ライブラリからのOracle Service Busリソースのプロビジョニング

この項では、ソフトウェア・ライブラリからOracle Service Busリソースをプロビジョニングする方法について説明します。

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

デザイナの前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- Oracle Service BusドメインのリソースをJARファイルとしてエクスポートします。これには、Oracle Service Busコンソールを使用します。

- Oracleソフトウェア・ライブラリ内でJARファイルが汎用コンポーネントとして使用可能になっていることを確認します。汎用コンポーネントの作成手順は、第2.2項を参照してください。

- カスタマイズ・ファイルを使用して変更後の(ターゲット)環境の環境変数をカスタマイズする場合は、Oracleソフトウェア・ライブラリ内でそのカスタマイズ・ファイルが汎用コンポーネントとして使用可能になっていることを確認する必要があります。汎用コンポーネントの作成手順は、第2.2項を参照してください。

オペレータの前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

ソースのOracle Service BusドメインからOracle Service Busリソースをプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. 「デプロイメント・プロシージャ」セクションで、リストから「Oracle Service Busリソース・プロビジョニング」プロシージャを選択し、「起動」をクリックします。

3. 「ソース選択」ページの「ソース」セクションで、「Oracleソフトウェア・ライブラリ」を選択します。

1. 「コンポーネント」で懐中電灯アイコンをクリックし、ターゲットのOracle Service Busドメインにデプロイするリソースが含まれる汎用コンポーネントを選択します。

2. (オプション)JARファイル内のリソースに保護対象の機密データが含まれる場合は、「パスフレーズ」にパスフレーズを指定します。これらのリソースをターゲット・ドメインにインポートするとき、同じパスフレーズが使用されます。

3. 「次へ」をクリックします。Cloud Controlで「ターゲットの選択」ページが表示されます。

4. 「ターゲットの選択」ページで、次の手順を実行します。

1. 「ターゲット」セクションで、次の項目を指定します。
「ドメイン」で懐中電灯アイコンをクリックし、選択したリソースをデプロイする先のOracle Service Busドメインを選択します。

「BEAホーム・ディレクトリ」で、すべてのBEA製品関連ファイルが格納されるBEAホーム・ディレクトリのフルパスを指定します。

2. (オプション)デプロイメントで選択したリソースをカスタマイズした場合、ターゲットのOracle Service Busドメインでもこれらの変更内容を保持するには、「オプション」セクションで保持する設定を選択します。

Oracle Service Bus 2.6.xの場合、「セキュリティおよびポリシーの構成」、「資格証明」および「アクセス制御ポリシー」は保持できません。

3. 「カスタマイズ」セクションで、ターゲットOSBドメインで環境設定を変更する場合に使用できるカスタマイズ・ファイルの詳細を入力します。

カスタマイズ・ファイルを使用しない場合は、「なし」を選択します。

カスタマイズ・ファイルを使用している場合、ターゲットOSBドメインが稼働しているホスト上でそのカスタマイズ・ファイルが使用可能であれば、「ターゲット・ホストのカスタマイズ・ファイルを使用します」を選択し、ファイルの場所のフルパスを指定します。

カスタマイズ・ファイルを汎用コンポーネントとしてOracleソフトウェア・ライブラリに格納する場合は、「カスタマイズ・ファイルをソフトウェア・ライブラリから選択します」を選択し、Oracleソフトウェア・ライブラリ内の汎用コンポーネントの格納先のフルパスを指定します。

4. 「次へ」をクリックします。

5. 「資格証明の設定」ページで、次の項目を指定して「次へ」をクリックします。

1. ソースおよびターゲットのOracle Service Bus (OSB)ドメインのログイン資格証明を指定します。

2. OSBドメインの管理サーバーを監視している管理エージェントが稼働しているホストの資格証明を指定します。

6. 「スケジュール」ページで、デプロイメント・インスタンス名を指定します。プロシージャを即時に実行する場合は、デフォルトの選択(「1回(即時)」)を保持します。プロシージャを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。デプロイメント・プロシージャのステータスに応じて、通知プリファレンスを設定できます。前提条件のみを実行する場合は、「前提条件チェックの実行後に結果を分析するためにプロシージャを停止します」を選択すると、すべての前提条件チェックの実行後にプロシージャ実行を一時停止できます。「次へ」をクリックします。

7. 確認ページで、デプロイメント・プロシージャに対して指定した詳細を確認します。その詳細で問題がない場合は、「発行」をクリックし、スケジュール・セットに従ってデプロイメント・プロシージャを実行します。詳細を変更する場合は、そのセクションにある「編集」リンクをクリックして変更するか、または「戻る」のクリックを繰り返して変更したいページに戻ります。

8. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各手順の「ステータス」リンクをクリックすると、各手順の実行の詳細が表示されます。ロギング・レベルを「デバッグ」に設定するには、「デバッグ」をクリックし、プロシージャの実行を停止するには、「停止」をクリックします。

34 Oracle BPELプロセスのプロビジョニング

Business Process Execution Language (BPEL)とは、Webサービスを組み合せて使用し、複数のエンタープライズ間でタスクを共有できるようにするためのXMLベース言語です。BPELは、XMLスキーマ、Simple Object Access Protocol (SOAP)、Web Services Description Language (WSDL)をベースにしています。BPELは、ビジネス・プロセスのオーケストレーションと実行に関する業界標準を企業に提供します。

Oracle BPEL Process Manager (BPEL Process Manager)は、BPEL標準に基づくプロセスの設計、デプロイ、監視および管理を簡単に行うためのフレームワークを提供します。

Oracle Enterprise Manager Cloud Control (Cloud Control)では、これらのBPEL Process Managerを検出および監視できますが、BPEL Process ManagerでのBPELプロセスのプロビジョニングに使用できるデプロイメント・プロシージャも用意されています。

この章では、BPEL Process ManagerのBPELプロセスをプロビジョニングする方法について説明します。この章の具体的な内容は次のとおりです。

- Oracle BPELプロセスの概要

- Oracle BPELプロセスでサポートされているリリース

- Oracle BPELプロセスのプロビジョニング

34.1 Oracle BPELプロセスの概要

この項では、この章の手引きとして、Oracle BPELプロセスのプロビジョニングに関連する手順の概要を示します。この項は、Oracle BPELプロセスのプロビジョニングを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表34-1 Oracle BPELプロセスのプロビジョニングの概要

ステップ

説明

参照リンク

手順1

サポートされているリリースの把握

このデプロイメント・プロシージャでサポートされているOracle BPEL Process Managerのリリースを把握します。

デプロイメント・プロシージャでサポートされているリリースについては、第34.2項を参照してください。

手順2

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

Oracle BPELをプロビジョニングするための前提条件の詳細は、第34.3項を参照してください。

手順3

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行して、Oracle BPELプロセスをプロビジョニングします。

Oracle BPELプロセスをプロビジョニングするには、第34.3項で説明されている手順を実行します。

34.2 Oracle BPELプロセスでサポートされているリリース

このデプロイメント・プロシージャを使用すると、Oracle BPEL Process Manager 10.1.3.1、10.1.3.3および10.1.3.4のBPELリソースをプロビジョニングできます。

34.3 Oracle BPELプロセスのプロビジョニング

この項では、Oracle BPEL Process ManagerのBPELプロセスをプロビジョニングする方法について説明します。

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

デザイナの前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- プロセス・スーツケース・ファイルのデプロイ先のBPEL Process Managerが、Cloud Controlですでに検出されて監視されていることを確認します。

- BPELプロセス・スーツケース・ファイルを汎用コンポーネントとしてソフトウェア・ライブラリに格納します。汎用コンポーネントの作成手順は、第2.2項を参照してください。

注意:
BPELプロセスの汎用コンポーネントを追加する際には、ソフトウェア・ライブラリ・ウィザードの「コンポーネントの作成: 説明」ページで、「タイプ」リストから「汎用コンポーネント」を選択して親フォルダの名前を指定し、「ファイルのアップロード」ページに移動してファイルをアップロードします。ディレクティブのカスタマイズおよび設定ページに詳細を入力する必要はありません。

- BPELプロセス・スーツケース・ファイル(JARファイル)と関連付けることができるデプロイ・プランを使用する場合は、このデプロイメント・ファイルを汎用コンポーネントとしてソフトウェア・ライブラリに格納します。汎用コンポーネントの作成手順は、第2.2項を参照してください。

オペレータの前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

BPELプロセスをターゲットのBPEL Process Managerにプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. 「デプロイメント・プロシージャ」セクションで、リストから「BPELプロセスのプロビジョニング」プロシージャを選択し、「起動」をクリックします。

3. 「ソース選択」ページで、次の手順を実行します。

1. 「ソース」セクションで「追加」をクリックし、ターゲットのBPEL Process ManagerにデプロイするBPELプロセス・スーツケース・ファイルを選択します。選択したファイルに基づいて表に値が移入されます。

複数のスーツケース・ファイルを選択した場合は、表からBPELプロセス・スーツケース・ファイルを選択し、「上に移動」および「下に移動」を使用して、デプロイメント・プロシージャによりデプロイする順序どおりにコンポーネントを並べ替えます。

2. 「デプロイ・プランの選択」で、BPELプロセス・スーツケース・ファイル(JARファイル)と関連付けることができるデプロイ・プランを選択します。

デプロイ・プランは、構成の詳細と、特定の環境に対して設定したパートナー・リンク・バインド・プロパティを実行時に変更するのに役立ちます。特定の環境に対して設定した文字列とURLを検索および置換するためにも使用できます。これにより、開発、テストおよび本番環境にあるBPEL Process Managerに同じBPELプロセスをデプロイできます。これらの環境で設定を再構成する必要はありません。

3. 「次へ」をクリックします。

4. 「ターゲット選択」ページの「ターゲット」セクションで、「追加」をクリックし、BPELプロセスのデプロイ先のBPEL Process Managerを選択します。BPELターゲットに使用可能なドメインが複数ある場合は、「BPELドメイン」リストから、スーツケース・ファイルをデプロイする適切なドメインを選択できます。「次へ」をクリックします。

注意:
「次へ」をクリックすると、コンテキスト・プロバイダURLが取得されたかどうかをCloud Controlが内部チェックします。このURLが取得されない場合、エラーが表示されることがあります。この問題を解決するには、BPELターゲットの「監視構成」ページでURLを設定します。

5. 「資格証明」ページで、次の項目を指定します。

1. 選択したBPEL Process Managerが稼働しているアプリケーション・サーバー・インスタンスの資格証明。

2. 選択したOracle BPEL Process ManagerのBPEL管理者資格証明(および10.1.2 BPELターゲット用のRMI資格証明)。

BPEL Process Managerに必要な資格証明は、サポートされているBPEL Process Managerバージョンによって異なります。BPEL 10.1.3ターゲットの場合、BPEL Process Managerへのアクセスに使用される一連の資格証明を指定するだけですみます。しかし、BPEL 10.1.2ターゲットの場合、BPEL管理者のパスワードと、リモート・アクセス用の別の一連のOC4J RMIアクセス資格証明を指定する必要があります。

優先資格証明がすでに設定されて管理リポジトリに格納されている場合は、デフォルトでその優先資格証明がこのページに事前入力されます。事前入力されたこれらの優先資格証明値を選択することも、これらの値を編集して変更した資格証明を使用することもできます。優先資格証明が格納されていない場合、フィールドは空白になります。この場合は、資格証明を指定する必要があります。ここで指定した資格証明は、現在のデプロイメント・プロシージャ・セッションにのみに適用され、今後使用するために管理リポジトリに格納されることはありません。

資格証明を変更した場合、変更は現在のデプロイメント・プロシージャ・セッションにのみ適用されるので、管理リポジトリに格納されている優先資格証明が上書きされることはありません。

3. 「次へ」をクリックします。

6. 「スケジュール」ページで、デプロイメント・インスタンス名を指定します。プロシージャを即時に実行する場合は、デフォルトの選択(「1回(即時)」)を保持します。プロシージャを後で実行する場合は、「1回(後で)」を選択し、タイムゾーン、開始日および開始時刻の詳細を指定します。デプロイメント・プロシージャのステータスに応じて、通知プリファレンスを設定できます。前提条件のみを実行する場合は、「前提条件チェックの実行後に結果を分析するためにプロシージャを停止します」を選択すると、すべての前提条件チェックの実行後にプロシージャ実行を一時停止できます。「次へ」をクリックします。

7. 確認ページで、デプロイメント・プロシージャに対して指定した詳細を確認します。その詳細で問題がない場合は、「発行」をクリックし、スケジュール・セットに従ってデプロイメント・プロシージャを実行します。詳細を変更する場合は、そのセクションにある「編集」リンクをクリックして変更するか、または「戻る」のクリックを繰り返して変更したいページに戻ります。

8. 「プロシージャ・アクティビティ」ページで、デプロイメント・プロシージャのジョブおよび手順の実行ステータスを確認します。各手順の「ステータス」リンクをクリックすると、各手順の実行の詳細が表示されます。ロギング・レベルを「デバッグ」に設定するには、「デバッグ」をクリックし、プロシージャの実行を停止するには、「停止」をクリックします。

35 Oracle Application Serverのプロビジョニング

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用してOracle Application Serverをプロビジョニングする方法について説明します。この章の具体的な内容は次のとおりです。

- Oracle Application Serverのプロビジョニングの概要

- デプロイメント・プロシージャ、サポートされるリリース、およびデプロイされるコア・コンポーネント

- Oracle Application Server 10gリリース1 (10.1.3)のプロビジョニング

- Oracle SOA Suite 10g (10.1.3.4および10.1.3.5)のプロビジョニング

35.1 Oracle Application Serverのプロビジョニングの概要

この項では、この章の手引きとして、Oracle Application Serverのプロビジョニングに関連する手順の概要を示します。この項は、Oracle Application Serverのプロビジョニングを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表35-1 Oracle Application Serverのプロビジョニングの概要

ステップ

説明

参照リンク

手順1

プロビジョニングするリリースの選択

この章では、Oracle Application Serverの各リリースに対応するユースケースを示します。プロビジョニングするリリースを特定し、各リリースに対応するユースケースについて理解します。

- Oracle Application Server 10g Release 1 (10.1.3)のプロビジョニングの詳細は、35.3項を参照してください。

- Oracle SOA Suite 10g (10.1.3.x)のプロビジョニングの詳細は、第35.4項を参照してください。

手順2

前提条件の確認

デプロイメント・プロシージャを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

Oracle Application Serverをプロビジョニングするための前提条件の詳細は、手順1に示されている参照リンクにアクセスし、「前提条件」の項を参照してください。

手順3

デプロイメント・プロシージャの実行

デプロイメント・プロシージャを実行して、Oracle Application Serverをプロビジョニングします。

Oracle Application Serverをプロビジョニングするには、手順1に示されている参照リンクにアクセスし、「前提条件」の項を参照してください。

35.2 デプロイメント・プロシージャ、サポートされるリリース、およびデプロイされるコア・コンポーネント

Cloud Controlには、Oracle Application Serverをプロビジョニングするための次のデプロイメント・プロシージャが用意されています。

デプロイメント・プロシージャ

サポートされているリリース

デプロイされるコア・コンポーネント

Application Server Deployment 10.1.3

Oracle Application Server 10gリリース3 (10.1.3.4および10.1.3.5)

- アプリケーション層

- Web層

Application Server Deployment 10.1.3.xSOA

Oracle SOA Suite 10g (10.1.3.4および10.1.3.5)

Oracle SOA Suite 10g (10.1.3.x)は、Oracle Application Server 10gリリース3 (10.1.3.4および10.1.3.5)のアプリケーション層およびWeb層とともにデプロイされます。

注意:
これらのデプロイメント・プロシージャではデータベース層はインストールされません。しかし、既存のデータ層を使用してJava Authentication and Authorization Service (JAAS)プロバイダ(JAZNとも呼ばれる)を簡単に構成できます。

プロビジョニングが可能なOracle Application Serverの形式として、Cloud Controlにより監視されたホストで実行中のインスタンス、Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)内のゴールド・イメージなどがあります。

「Application Server Deployment 10.1.3」デプロイメント・プロシージャを使用すると、いずれの形式でもプロビジョニングできます。これに対し、最新のパッチがすべて適用された安定性の高い実行中インスタンスをコピーする場合は、同じ構成設定を使用できるようにその既存のインスタンスをクローニングすることをお薦めします。同様に、必要なパッチが適用された安定性の高いこのアプリケーション・サーバー・インスタンスのゴールド・イメージをソフトウェア・ライブラリ内に作成した場合は、それを使用して、エンタープライズ構成内に同様のインスタンスをデプロイできます。

注意:
Microsoft Windows Vistaでは、ソフトウェア・ライブラリからのゴールド・イメージのプロビジョニングはサポートされていません。

35.3 Oracle Application Server 10gリリース1 (10.1.3)のプロビジョニング

この項では、Oracle Application Server 10gリリース1 (10.1.3)をプロビジョニングする方法について説明します。この項の具体的な内容は次のとおりです。

- 実行中のOracle Application Serverインスタンスのクローニング

- Oracle Application Serverのゴールド・イメージのプロビジョニング

35.3.1 実行中のOracle Application Serverインスタンスのクローニング

この項では、Cloud Controlで監視されているホストで実行中の既存のOracle Application Serverインスタンスをクローニングする方法について説明します。

このオプションは、最新のパッチがすべて適用された安定性の高いOracle Application Serverインスタンスが実行されており、複数のホストにその同一コピーを作成する場合に適しています。

ただし、既存のインスタンスを使用する場合は、インスタンスが予告なく削除またはアンインストールされることがあるため、その結果デプロイメント・プロシージャが失敗する可能性があります。このため、このオプションは、実行中のインスタンスをクローニングに使用できることがわかっている場合にのみ使用してください。

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

- 既存のクラスタからクローニングし、既存のクラスタをスケール・アップし、同じインターネット・ディレクトリを使用

- 既存のクラスタからプロビジョニングし、インターネット・ディレクトリを使用せずに新規クラスタを作成

- 既存のクラスタからプロビジョニングし、インターネット・ディレクトリを使用して新規クラスタを作成

35.3.1.1 既存のクラスタからクローニングし、既存のクラスタをスケール・アップし、同じインターネット・ディレクトリを使用

この項では、既存のクラスタからOracle Application Server 10gリリース1 (10.1.3)のアプリケーション層およびWeb層をプロビジョニングし、同じインターネット・ディレクトリを使用して新規のノードを含めてクラスタを拡張する方法について説明します。

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

デザイナの前提条件:

- 第2章に示されている前提条件を満たしていることを確認します。

- ソース・ホストとターゲット・ホストの構成を比較し、両者の構成が同じであることを確認します。構成が異なる場合は、システム管理者に連絡し、不一致を修正してから、デプロイメント・プロシージャを実行します。
ホストの構成を比較するには、Cloud Controlで「ターゲット」、「ホスト」の順にクリックします。「ホスト」ページで、ソース・ホストの名前をクリックしてそのホームページにアクセスし、「構成」タブをクリックします。「構成」ページで「構成の比較」をクリックし、ターゲット・ホストを選択します。

- 複数のWeb層をデプロイする場合は、ソフトウェア・ロード・バランサが設定されていて、Web層のホストからアクセス可能になっていることを確認します。
ソフトウェア・ライブラリには、選択したWeb層でF5 Networks社のBig-IP Application Switch(ソフトウェア・バージョン4.5 PTF.5)ロード・バランサを構成するためのスクリプトが用意されています。その他のシステム(Cisco CSM 3.1など)の場合は、独自の構成でこのスクリプトを上書きします。このスクリプトは、ソフトウェア・ライブラリの次の場所にあります。

Directives/Oracle Directives/Loadbalancer

- すべてのターゲット・ホストで、Web層およびアプリケーション層のインストール先のインストール・ベース・ディレクトリがアクセス可能になっている(ただし共有はされていない)ことを確認します。

オペレータの前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

Web層およびアプリケーション層をプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. 「デプロイメント・プロシージャ」セクションから、「アプリケーション・サーバー・プロビジョニング・プロシージャ」をクリックします。

3. 「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ」サブタブで、表から「Application Server Deployment 10.1.3」を選択します。次に、「デプロイメントのスケジュール」をクリックします。Cloud Controlでデプロイメント・プロシージャの「ソース選択」ページが表示されます。

4. 「ソース選択」ページで、「ソース選択」セクションの「インストールされたクラスタ環境からソースOracleホームを選択してください」サブセクションから、次の手順を実行します。

1. デフォルトの選択(「既存のクラスタ・インストールからの選択」)を保持します。

2. 「クラスタの選択」リストから、Web層およびアプリケーション層のデプロイ元の既存のクラスタを選択します。既存のクラスタを選択すると、その一部であるWeb層およびアプリケーション層に関する情報が表に移入されます。

3. 表の「除外するファイル」で、このデプロイメント・プロシージャの実行中に除外するOracleホーム内のファイルを指定します。ファイル名またはファイル拡張子を指定でき、複数のエントリはカンマで区切ることができます。
「作業ディレクトリ」で、デフォルト値を保持するか、クローニングでファイルのステージングに使用できる、ソース・ホストにすでに存在する別の場所を指定します。

4. 選択したソース・クラスタから2つの製品(アプリケーション・サーバーまたはWebサーバー)のいずれか一方のみをデプロイする場合、「リセット」をクリックして表のすべての値を削除します。値をリセットした後、デプロイする製品に対する懐中電灯アイコンをクリックし、必要なターゲットを選択します。

5. Oracleホームをイメージとしてソフトウェア・ライブラリに保存する場合は、「ソフトウェア・ライブラリに保存」を選択します。

6. 「次へ」をクリックします。

注意:
その特定プラットフォームに対してソフトウェア・ライブラリに前提条件がない場合、「次へ」をクリックすると、「警告を無視して次へ」オプションが表示されます。この場合、次のいずれかを実行できます。

- Components/Oracle Components/Prerequisite-fixup components/<Platform name>/Prerequisite-Fixup componentにあるソフトウェア・ライブラリにコンポーネントをアップロードし、「次へ」をクリックします。

- デプロイメント・プロシージャの実行中に前提条件チェックをスキップする場合は、「警告を無視して次へ」をクリックします。

5. 「ターゲット・リスト」ページで、次の手順を実行します。

1. 「Web層ホスト」セクションで、「追加」をクリックして、Web層のデプロイ先のホストを追加します。このホストのプラットフォームが、アプリケーション層のデプロイ先のホストのプラットフォームと同じであることを確認します。

2. 「アプリケーション層ホスト」セクションで、「追加」をクリックして、アプリケーション層のデプロイ先のホストを追加します。このホストのプラットフォームが、Web層のデプロイ先のホストのプラットフォームと同じであることを確認します。

3. 「次へ」をクリックします。

6. 「資格証明/スケジュール」ページで、次の手順を実行します。

1. 「ターゲット・ホストの資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

2. 「エージェント・ホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

3. 「ソースOracleホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

4. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

5. 「次へ」をクリックします。

7. 「アプリケーションおよびWeb層」ページで、次の手順を実行します。

1. 「クラスタ詳細」セクションで、デフォルトの選択(「既存のクラスタの拡張」)を保持します。

2. 「インスタンスの詳細」セクションで、デフォルトのインスタンス名を保持し、ソース・ホストとターゲット・ホストにOC4J管理者パスワードを指定します。
デフォルトのインスタンス名はいつでも変更して、別のカスタム名にすることができます。ただし、デフォルトでは、ここで指定するインスタンス名にそのホストのホスト名とドメイン名が追加されるため、必ず一意の名前を指定してください。

重要:

- どのユーザーがインストールを実行したかには関係なく、各Oracle Application Server 10gインスタンスにはそれぞれのパスワードがあります。同じユーザーが複数のインスタンスをインストールした場合でも、パスワードは複数のインスタンス間で共有されません。

- 異なるパスワードを持つ複数のOC4Jインスタンスを含むアプリケーション・サーバーをクローニングする場合は、「追加パラメータ」セクションで追加パラメータとして-forceコマンドを使用します。詳細は、手順7 (e)を参照してください。

- ここでは、5文字以上30文字以下の英数字を含むパスワードを指定する必要があります。アンダースコア(_)、ドル($)またはシャープ(#)文字も使用できます。最初の文字は英字にし、1文字以上の数値を含める必要があります。

3. 「ポートの詳細」セクションで、Oracle Web Cacheが構成されていない場合に表示されるデフォルトのポート番号(7777)を保持します。

4. F5 BIG-IP Local Traffic Managerロード・バランサが構成されている場合は、「ロード・バランサ詳細」セクションで「ロード・バランサの構成」を選択し、必要な情報を入力します。

注意:
Cloud Controlでは、F5 BIG-IP Local Traffic Managerのみがサポートされています。他のロード・バランサがある場合は、「ロード・バランサの構成」を選択解除し、そのロード・バランサと、関連付けられているHTTPサーバーを手動で構成します。この場合には、このセクションを使用しないでください。

5. 「追加パラメータ」セクションで、デプロイメント・プロシージャに渡すWeb層またはアプリケーション層に固有の追加パラメータがあれば指定します。たとえば、-debugと指定します。その他、このプロビジョニング操作で使用できる任意のOracle Universal Installer (OUI)パラメータを指定できます。

重要:
異なるパスワードを持つ複数のOC4Jインスタンスがあるアプリケーション・サーバーをクローニングする場合は、このセクションで-forceコマンドを追加パラメータとして使用します。
これにより、「インスタンスの詳細」セクションで指定したパスワードが、プロビジョニングされるすべてのOC4Jインスタンスに均一に伝播されます。

ただし、プロビジョニングされたOC4Jインスタンスに異なるパスワードを維持する場合は、デプロイメント・プロシージャが正常に終了した後で、アプリケーション・サーバー・コンソールにアクセスし、個々のOC4Jインスタンスのパスワードを変更します。

6. 「アイデンティティ管理構成」セクションで、デフォルトの選択を保持します。

7. 「次へ」をクリックします。

8. 「Oracleホームの構成」ページで、次の手順を実行します。

1. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定します。
セキュリティ更新およびインストール更新を受け取るには、電子メール・アドレスが必要です。任意の電子メール・アドレスを指定できますが、My Oracle Supportのユーザー名を指定することをお薦めします。たとえば、john.mathew@xyz.comのように指定します。

My Oracle Supportパスワードが間違っている場合は、さらに2回試行できます。ただし、3回の試行すべてでパスワードが間違っている場合や、空白のままにした場合は、匿名で登録されるため、構成情報は収集されてMy Oracle Supportにアップロードされますが、アップロードされた情報はMy Oracle Supportアカウントに関連付けられません。したがって、My Oracle Supportに資格証明を使用してログインした場合、アカウントに対してこの情報は表示されません。ただし、電子メール・アドレスを指定した場合は、オラクル社からセキュリティ・アップデートとその他の通知が引き続きその電子メール・アドレスに送信されます。

2. Web層およびアプリケーション層のプロビジョニング先のホストがプロキシ・サーバー経由でインターネットに間接的に接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定し、「接続の詳細」セクションでプロキシ・サーバーの詳細を指定します。

注意:
プロキシ・サーバー設定は、デプロイメント・プロシージャの終了後、いつでも変更できます。このためには、プロビジョニングされたアプリケーション・サーバーのOracleホーム・ディレクトリ内の/ccr/bin/ディレクトリからconfigCCRコマンドを実行します。

3. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接的にも間接的にも接続されていない場合は、電子メール・アドレスを指定し、その他のフィールドは空白のままにしておきます。
この場合、インストール・プロセスの完了後に、手動で構成情報を収集してMy Oracle Supportにアップロードしてください。

4. 「次へ」をクリックします。

9. 「確認」ページで、Web層およびアプリケーション層をプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

35.3.1.2 既存のクラスタからプロビジョニングし、インターネット・ディレクトリを使用せずに新規クラスタを作成

この項では、既存のクラスタからOracle Application Server 10gリリース1 (10.1.3)のアプリケーション層およびWeb層をプロビジョニングし、インターネット・ディレクトリを使用せずに新規のクラスタを作成する方法について説明します。

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

デザイナの前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- ソース・ホストとターゲット・ホストの構成を比較し、両者の構成が同じであることを確認します。構成が異なる場合は、システム管理者に連絡し、不一致を修正してから、デプロイメント・プロシージャを実行します。
ホストの構成を比較するには、Cloud Controlで「ターゲット」、「ホスト」の順にクリックします。「ホスト」ページで、ソース・ホストの名前をクリックしてそのホームページにアクセスし、「構成」タブをクリックします。「構成」ページで「構成の比較」をクリックし、ターゲット・ホストを選択します。

- 複数のWeb層をデプロイする場合は、ソフトウェア・ロード・バランサが設定されていて、Web層のホストからアクセス可能になっていることを確認します。
ソフトウェア・ライブラリには、選択したWeb層でF5 Networks社のBig-IP Application Switch(ソフトウェア・バージョン4.5 PTF.5)ロード・バランサを構成するためのスクリプトが用意されています。その他のシステム(Cisco CSM 3.1など)の場合は、独自の構成でこのスクリプトを上書きします。このスクリプトは、ソフトウェア・ライブラリの次の場所にあります。

Directives/Oracle Directives/Loadbalancer

- すべてのターゲット・ホストで、Web層およびアプリケーション層のインストール先のインストール・ベース・ディレクトリがアクセス可能になっている(ただし共有はされていない)ことを確認します。

オペレータの前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

Web層およびアプリケーション層をプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. 「デプロイメント・プロシージャ」セクションから、「アプリケーション・サーバー・プロビジョニング・プロシージャ」をクリックします。

3. 「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ」サブタブで、表から「Application Server Deployment 10.1.3」を選択します。次に、「デプロイメントのスケジュール」をクリックします。

4. 「ソース選択」ページで、「ソース選択」セクションの「インストールされたクラスタ環境からソースOracleホームを選択してください」サブセクションから、次の手順を実行します。

1. デフォルトの選択(「既存のクラスタ・インストールからの選択」)を保持します。

2. 「クラスタの選択」リストから、Web層およびアプリケーション層のデプロイ元の既存のクラスタを選択します。既存のクラスタを選択すると、その一部であるWeb層およびアプリケーション層に関する情報が表に移入されます。

3. 表の「除外するファイル」で、このデプロイメント・プロシージャの実行中に除外するOracleホーム内のファイルを指定します。ファイル名またはファイル拡張子を指定でき、複数のエントリはカンマで区切ることができます。
「作業ディレクトリ」で、デフォルト値を保持するか、クローニングでファイルのステージングに使用できる、ソース・ホストにすでに存在する別の場所を指定します。

4. 選択したソース・クラスタから2つの製品(アプリケーション・サーバーまたはWebサーバー)のいずれか一方のみをデプロイする場合、「リセット」をクリックして表のすべての値を削除します。値をリセットした後、デプロイする製品に対する懐中電灯アイコンをクリックし、必要なターゲットを選択します。

5. Oracleホームをイメージとしてソフトウェア・ライブラリに保存する場合は、「ソフトウェア・ライブラリに保存」を選択します。

6. 「次へ」をクリックします。

5. 「ターゲット・リスト」ページで、次の手順を実行します。

1. 「Web層ホスト」セクションで、「追加」をクリックして、Web層のデプロイ先のホストを追加します。このホストのプラットフォームが、アプリケーション層のデプロイ先のホストのプラットフォームと同じであることを確認します。

2. 「アプリケーション層ホスト」セクションで、「追加」をクリックして、アプリケーション層のデプロイ先のホストを追加します。このホストのプラットフォームが、Web層のデプロイ先のホストのプラットフォームと同じであることを確認します。

3. 「次へ」をクリックします。

6. 「資格証明/スケジュール」ページで、次の手順を実行します。

1. 「ターゲット・ホストの資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

2. 「エージェント・ホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

3. 「ソースOracleホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

4. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

5. 「次へ」をクリックします。

7. 「アプリケーションおよびWeb層」ページで、次の手順を実行します。

1. 「クラスタ詳細」セクションで、「新規クラスタの作成」を選択します。デフォルトでは、Cloud Controlにより既存のクラスタに基づいて詳細が事前に入力されます。デフォルト値を使用するか、新規のクラスタ名、インストール・ディレクトリ、マルチキャスト・アドレスおよびポートを指定できます。また、マルチキャスト・アドレスおよびポートがソース・クラスタに構成されている値と異なることを確認します。
「Web層インストールのベース・ディレクトリ」ではWeb層のデプロイ先のディレクトリの絶対パスを指定し、「アプリケーション層インストールのベース・ディレクトリ」ではアプリケーション層のデプロイ先のディレクトリの絶対パスを指定します。

「マルチキャスト・アドレス」で、アドレスの範囲が224.0.0.0から239.255.255.255までになっていることを確認します。これは、マルチキャスト・グループに結合される一連のノードに対する1つのIPアドレスです。

2. 「インスタンスの詳細」セクションで、Web層インスタンスとアプリケーション層インスタンスに一意のインスタンス名を指定し、ソース・ホストとターゲット・ホストにOC4J管理者パスワードを指定します。
デフォルトのインスタンス名はいつでも変更して、別のカスタム名にすることができます。ただし、デフォルトでは、ここで指定するインスタンス名にそのホストのホスト名とドメイン名が追加されるため、必ず一意の名前を指定してください。

重要:

- どのユーザーがインストールを実行したかには関係なく、各Oracle Application Server 10gインスタンスにはそれぞれのパスワードがあります。同じユーザーが複数のインスタンスをインストールした場合でも、パスワードは複数のインスタンス間で共有されません。

- 異なるパスワードを持つ複数のOC4Jインスタンスを含むアプリケーション・サーバーをクローニングする場合は、「追加パラメータ」セクションで追加パラメータとして-forceコマンドを使用します。詳細は、手順7 (e)を参照してください。

- ここでは、5文字以上30文字以下の英数字を含むパスワードを指定する必要があります。アンダースコア(_)、ドル($)またはシャープ(#)文字も使用できます。最初の文字は英字にし、1文字以上の数値を含める必要があります。

3. 「ポートの詳細」セクションで、クライアント・アプリケーションにより確立されたHTTP接続を管理するためのHTTPロード・バランサ・ホストおよびリスナー・ポートを指定します。あるいは、デフォルト値の7777を保持することもできます。通信を保護する場合は、「SSLの有効化」を選択します。

4. F5 BIG-IP Local Traffic Managerロード・バランサが構成されている場合は、「ロード・バランサ詳細」セクションで「ロード・バランサの構成」を選択し、必要な情報を入力します。

注意:
Cloud Controlでは、F5 BIG-IP Local Traffic Managerのみがサポートされています。他のロード・バランサがある場合は、「ロード・バランサの構成」を選択解除し、そのロード・バランサと、関連付けられているHTTPサーバーを手動で構成します。この場合には、このセクションを使用しないでください。

5. 「追加パラメータ」セクションで、デプロイメント・プロシージャに渡すWeb層またはアプリケーション層に固有の追加パラメータがあれば指定します。たとえば、-debugと指定します。その他、このプロビジョニング操作で使用できる任意のOracle Universal Installer (OUI)パラメータを指定できます。

重要:
異なるパスワードを持つ複数のOC4Jインスタンスがあるアプリケーション・サーバーをクローニングする場合は、このセクションで-forceコマンドを追加パラメータとして使用します。
これにより、「インスタンスの詳細」セクションで指定したパスワードが、プロビジョニングされるすべてのOC4Jインスタンスに均一に伝播されます。

ただし、プロビジョニングされたOC4Jインスタンスに異なるパスワードを維持する場合は、デプロイメント・プロシージャが正常に終了した後で、アプリケーション・サーバー・コンソールにアクセスし、個々のOC4Jインスタンスのパスワードを変更します。

6. 「アイデンティティ管理構成」セクションで、「なし」を選択します。

7. 「次へ」をクリックします。

8. 「Oracleホームの構成」ページで、次の手順を実行します。

1. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定します。
セキュリティ更新およびインストール更新を受け取るには、電子メール・アドレスが必要です。任意の電子メール・アドレスを指定できますが、My Oracle Supportのユーザー名を指定することをお薦めします。たとえば、john.mathew@xyz.comのように指定します。

My Oracle Supportパスワードが間違っている場合は、さらに2回試行できます。ただし、3回の試行すべてでパスワードが間違っている場合や、空白のままにした場合は、匿名で登録されるため、構成情報は収集されてMy Oracle Supportにアップロードされますが、アップロードされた情報はMy Oracle Supportアカウントに関連付けられません。したがって、My Oracle Supportに資格証明を使用してログインした場合、アカウントに対してこの情報は表示されません。ただし、電子メール・アドレスを指定した場合は、オラクル社からセキュリティ・アップデートとその他の通知が引き続きその電子メール・アドレスに送信されます。

2. Web層およびアプリケーション層のプロビジョニング先のホストがプロキシ・サーバー経由でインターネットに間接的に接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定し、「接続の詳細」セクションでプロキシ・サーバーの詳細を指定します。

注意:
プロキシ・サーバー設定は、デプロイメント・プロシージャの終了後、いつでも変更できます。このためには、プロビジョニングされたアプリケーション・サーバーのOracleホーム・ディレクトリ内の/ccr/bin/ディレクトリからconfigCCRコマンドを実行します。

3. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接的にも間接的にも接続されていない場合は、電子メール・アドレスを指定し、その他のフィールドは空白のままにしておきます。
この場合、インストール・プロセスの完了後に、手動で構成情報を収集してMy Oracle Supportにアップロードしてください。

4. 「次へ」をクリックします。

9. 「確認」ページで、Web層およびアプリケーション層をプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

35.3.1.3 既存のクラスタからプロビジョニングし、インターネット・ディレクトリを使用して新規クラスタを作成

この項では、既存のクラスタからOracle Application Server 10gリリース1 (10.1.3)のアプリケーション層およびWeb層をプロビジョニングし、インターネット・ディレクトリを使用して新規のクラスタを作成する方法について説明します。

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

デザイナの前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- ソース・ホストとターゲット・ホストの構成を比較し、両者の構成が同じであることを確認します。構成が異なる場合は、システム管理者に連絡し、不一致を修正してから、デプロイメント・プロシージャを実行します。
ホストの構成を比較するには、Cloud Controlで「ターゲット」、「ホスト」の順にクリックします。「ホスト」ページで、ソース・ホストの名前をクリックしてそのホームページにアクセスし、「構成」タブをクリックします。「構成」ページで「構成の比較」をクリックし、ターゲット・ホストを選択します。

- 複数のWeb層をデプロイする場合は、ソフトウェア・ロード・バランサが設定されていて、Web層のホストからアクセス可能になっていることを確認します。
ソフトウェア・ライブラリには、選択したWeb層でF5 Networks社のBig-IP Application Switch(ソフトウェア・バージョン4.5 PTF.5)ロード・バランサを構成するためのスクリプトが用意されています。その他のシステム(Cisco CSM 3.1など)の場合は、独自の構成でこのスクリプトを上書きします。このスクリプトは、ソフトウェア・ライブラリの次の場所にあります。

Directives/Oracle Directives/Loadbalancer

- すべてのターゲット・ホストで、Web層およびアプリケーション層のインストール先のインストール・ベース・ディレクトリがアクセス可能になっている(ただし共有はされていない)ことを確認します。

オペレータの前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

Web層およびアプリケーション層をプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. 「デプロイメント・プロシージャ」セクションから、「アプリケーション・サーバー・プロビジョニング・プロシージャ」をクリックします。

3. 「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ」サブタブで、表から「Application Server Deployment 10.1.3」を選択します。次に、「デプロイメントのスケジュール」をクリックします。

4. 「ソース選択」ページで、「ソース選択」セクションの「インストールされたクラスタ環境からソースOracleホームを選択してください」サブセクションから、次の手順を実行します。

1. デフォルトの選択(「既存のクラスタ・インストールからの選択」)を保持します。

2. 「クラスタの選択」リストから、Web層およびアプリケーション層のデプロイ元の既存のクラスタを選択します。既存のクラスタを選択すると、その一部であるWeb層およびアプリケーション層に関する情報が表に移入されます。

3. 表の「除外するファイル」で、このデプロイメント・プロシージャの実行中に除外するOracleホーム内のファイルを指定します。ファイル名またはファイル拡張子を指定でき、複数のエントリはカンマで区切ることができます。
「作業ディレクトリ」で、デフォルト値を保持するか、クローニングでファイルのステージングに使用できる、ソース・ホストにすでに存在する別の場所を指定します。

4. 選択したソース・クラスタから2つの製品(アプリケーション・サーバーまたはWebサーバー)のいずれか一方のみをデプロイする場合、「リセット」をクリックして表のすべての値を削除します。値をリセットした後、デプロイする製品に対する懐中電灯アイコンをクリックし、必要なターゲットを選択します。

5. Oracleホームをイメージとしてソフトウェア・ライブラリに保存する場合は、「ソフトウェア・ライブラリに保存」を選択します。

6. 「次へ」をクリックします。Cloud Controlで「ターゲット・リスト」ページが表示されます。

5. 「ターゲット・リスト」ページで、次の手順を実行します。

1. 「Web層ホスト」セクションで、「追加」をクリックして、Web層のデプロイ先のホストを追加します。このホストのプラットフォームが、アプリケーション層のデプロイ先のホストのプラットフォームと同じであることを確認します。

2. 「アプリケーション層ホスト」セクションで、「追加」をクリックして、アプリケーション層のデプロイ先のホストを追加します。このホストのプラットフォームが、Web層のデプロイ先のホストのプラットフォームと同じであることを確認します。

3. 「次へ」をクリックします。

6. 「資格証明/スケジュール」ページで、次の手順を実行します。

1. 「ターゲット・ホストの資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

2. 「エージェント・ホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

3. 「ソースOracleホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

4. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

7. 「アプリケーションおよびWeb層」ページで、次の手順を実行します。

1. 「クラスタ詳細」セクションで、「新規クラスタの作成」を選択します。デフォルトでは、Cloud Controlにより既存のクラスタに基づいて詳細が事前に入力されます。デフォルト値を使用するか、新規のクラスタ名、インストール・ディレクトリ、マルチキャスト・アドレスおよびポートを指定できます。また、マルチキャスト・アドレスおよびポートがソース・クラスタに構成されている値と異なることを確認します。
「Web層インストールのベース・ディレクトリ」ではWeb層のデプロイ先のディレクトリの絶対パスを指定し、「アプリケーション層インストールのベース・ディレクトリ」ではアプリケーション層のデプロイ先のディレクトリの絶対パスを指定します。

「マルチキャスト・アドレス」で、アドレスの範囲が224.0.0.0から239.255.255.255までになっていることを確認します。これは、マルチキャスト・グループに結合される一連のノードに対する1つのIPアドレスです。

2. 「インスタンスの詳細」セクションで、Web層インスタンスとアプリケーション層インスタンスに一意のインスタンス名を指定し、ソース・ホストとターゲット・ホストにOC4J管理者パスワードを指定します。
デフォルトのインスタンス名はいつでも変更して、別のカスタム名にすることができます。ただし、デフォルトでは、ここで指定するインスタンス名にそのホストのホスト名とドメイン名が追加されるため、必ず一意の名前を指定してください。

重要:

- どのユーザーがインストールを実行したかには関係なく、各Oracle Application Server 10gインスタンスにはそれぞれのパスワードがあります。同じユーザーが複数のインスタンスをインストールした場合でも、パスワードは複数のインスタンス間で共有されません。

- 異なるパスワードを持つ複数のOC4Jインスタンスを含むアプリケーション・サーバーをクローニングする場合は、「追加パラメータ」セクションで追加パラメータとして-forceコマンドを使用します。詳細は、手順7 (e)を参照してください。

- ここでは、5文字以上30文字以下の英数字を含むパスワードを指定する必要があります。アンダースコア(_)、ドル($)またはシャープ(#)文字も使用できます。最初の文字は英字にし、1文字以上の数値を含める必要があります。

3. 「ポートの詳細」セクションで、クライアント・アプリケーションにより確立されたHTTP接続を管理するためのHTTPロード・バランサ・ホストおよびリスナー・ポートを指定します。あるいは、デフォルト値の7777を保持することもできます。通信を保護する場合は、「SSLの有効化」を選択します。

4. F5 BIG-IP Local Traffic Managerロード・バランサが構成されている場合は、「ロード・バランサ詳細」セクションで「ロード・バランサの構成」を選択し、必要な情報を入力します。

注意:
Cloud Controlでは、F5 BIG-IP Local Traffic Managerのみがサポートされています。他のロード・バランサがある場合は、「ロード・バランサの構成」を選択解除し、そのロード・バランサと、関連付けられているHTTPサーバーを手動で構成します。この場合には、このセクションを使用しないでください。

5. 「追加パラメータ」セクションで、デプロイメント・プロシージャに渡すWeb層またはアプリケーション層に固有の追加パラメータがあれば指定します。たとえば、-debugと指定します。その他、このプロビジョニング操作で使用できる任意のOracle Universal Installer (OUI)パラメータを指定できます。

重要:
異なるパスワードを持つ複数のOC4Jインスタンスがあるアプリケーション・サーバーをクローニングする場合は、このセクションで-forceコマンドを追加パラメータとして使用します。
これにより、「インスタンスの詳細」セクションで指定したパスワードが、プロビジョニングされるすべてのOC4Jインスタンスに均一に伝播されます。

ただし、プロビジョニングされたOC4Jインスタンスに異なるパスワードを維持する場合は、デプロイメント・プロシージャが正常に終了した後で、アプリケーション・サーバー・コンソールにアクセスし、個々のOC4Jインスタンスのパスワードを変更します。

6. 「アイデンティティ管理構成」セクションで、「LDAPベース・プロバイダでJava Authentication and Authorization Service(JAZN)を構成」を選択します。
このオプションを使用すると、OC4Jアプリケーションの認証および認可に使用するJAZN LDAPベースのプロバイダを設定できます。

Java Authentication and Authorization Service (JAAS)は、サービスおよびアプリケーションによるユーザーのアクセス制御の認証と実施を可能にするJavaパッケージです。Oracle Application Server 10g Containers for J2EE (OC4J)は、JAASプロバイダ(JAZNとも呼ばれる)を実装することにより、JAASをサポートしています。

JAASプロバイダは、アプリケーション環境に統合するユーザー認証、認可および委任のサービスをアプリケーション開発者に提供します。また、JAASポリシーもサポートされています。ポリシーには、ユーザーにリソースの使用(ファイルの読取りなど)を許可するルール(権限)が含まれます。

7. 「次へ」をクリックします。Cloud Controlで「アイデンティティ管理」ページが表示されます。

8. 「アイデンティティ管理」ページで、次の手順を実行します。

1. 「アイデンティティ管理ホストの詳細」セクションで、Oracle Application Serverのユーザーおよびグループのアイデンティティ管理に使用するインターネット・ディレクトリの接続情報を指定します。インターネット・ディレクトリがインストールされていない場合は、OracleAS Infrastructureコンポーネントを使用してインストールします。

2. 「Internet Directoryのログイン詳細」セクションで、インターネット・ディレクトリのiASAdminグループに属するユーザーの資格証明を指定します。

3. 「次へ」をクリックします。Cloud Controlで「Oracleホームの構成」ページが表示されます。

9. 「Oracleホームの構成」ページで、次の手順を実行します。

1. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定します。
セキュリティ更新およびインストール更新を受け取るには、電子メール・アドレスが必要です。任意の電子メール・アドレスを指定できますが、My Oracle Supportのユーザー名を指定することをお薦めします。たとえば、john.mathew@xyz.comのように指定します。

My Oracle Supportパスワードが間違っている場合は、さらに2回試行できます。ただし、3回の試行すべてでパスワードが間違っている場合や、空白のままにした場合は、匿名で登録されるため、構成情報は収集されてMy Oracle Supportにアップロードされますが、アップロードされた情報はMy Oracle Supportアカウントに関連付けられません。したがって、My Oracle Supportに資格証明を使用してログインした場合、アカウントに対してこの情報は表示されません。ただし、電子メール・アドレスを指定した場合は、オラクル社からセキュリティ・アップデートとその他の通知が引き続きその電子メール・アドレスに送信されます。

2. Web層およびアプリケーション層のプロビジョニング先のホストがプロキシ・サーバー経由でインターネットに間接的に接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定し、「接続の詳細」セクションでプロキシ・サーバーの詳細を指定します。

注意:
プロキシ・サーバー設定は、デプロイメント・プロシージャの終了後、いつでも変更できます。このためには、プロビジョニングされたアプリケーション・サーバーのOracleホーム・ディレクトリ内の/ccr/bin/ディレクトリからconfigCCRコマンドを実行します。

3. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接的にも間接的にも接続されていない場合は、電子メール・アドレスを指定し、その他のフィールドは空白のままにしておきます。
この場合、インストール・プロセスの完了後に、手動で構成情報を収集してMy Oracle Supportにアップロードしてください。

10. 「確認」ページで、Web層およびアプリケーション層をプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

35.3.2 Oracle Application Serverのゴールド・イメージのプロビジョニング

この項では、Oracle Application Serverのゴールド・イメージをプロビジョニングする方法について説明します。この項の具体的な内容は次のとおりです。

- プロビジョニングし、インターネット・ディレクトリを使用せずに新規クラスタを作成

- プロビジョニングし、インターネット・ディレクトリを使用して新規クラスタを作成

- プロビジョニングし、インターネット・ディレクトリを使用せずにスタンドアロン・インスタンスとしてOracle Application Serverを処理

- プロビジョニングし、インターネット・ディレクトリを使用してスタンドアロン・インスタンスとしてOracle Application Serverを処理

35.3.2.1 プロビジョニングし、インターネット・ディレクトリを使用せずに新規クラスタを作成

この項では、ソフトウェア・ライブラリで使用可能なゴールド・イメージと同一のOracle Application Server 10gリリース1 (10.1.3)のアプリケーション層およびWeb層をプロビジョニングし、インターネット・ディレクトリを使用せずに新規のクラスタを作成する方法について説明します。

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

デザイナの前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- ソース・ホストとターゲット・ホストの構成を比較し、両者の構成が同じであることを確認します。構成が異なる場合は、システム管理者に連絡し、不一致を修正してから、デプロイメント・プロシージャを実行します。
ホストの構成を比較するには、Cloud Controlで「ターゲット」、「ホスト」の順にクリックします。「ホスト」ページで、ソース・ホストの名前をクリックしてそのホームページにアクセスし、「構成」タブをクリックします。「構成」ページで「構成の比較」をクリックし、ターゲット・ホストを選択します。

- 複数のWeb層をデプロイする場合は、ソフトウェア・ロード・バランサが設定されていて、Web層のホストからアクセス可能になっていることを確認します。
ソフトウェア・ライブラリには、選択したWeb層でF5 Networks社のBig-IP Application Switch(ソフトウェア・バージョン4.5 PTF.5)ロード・バランサを構成するためのスクリプトが用意されています。その他のシステム(Cisco CSM 3.1など)の場合は、独自の構成でこのスクリプトを上書きします。このスクリプトは、ソフトウェア・ライブラリの次の場所にあります。

Directives/Oracle Directives/Loadbalancer

- すべてのターゲット・ホストで、Web層およびアプリケーション層のインストール先のインストール・ベース・ディレクトリがアクセス可能になっている(ただし共有はされていない)ことを確認します。

オペレータに対する前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

Web層およびアプリケーション層をプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. 「デプロイメント・プロシージャ」セクションで、「アプリケーション・サーバー・プロビジョニング・プロシージャ」をクリックします。

3. 「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ」サブタブで、表から「Application Server Deployment 10.1.3」を選択します。次に、「デプロイメントのスケジュール」をクリックします。

4. 「ソース選択」ページで、「ソース選択」セクションの「ソフトウェア・ライブラリからshiphomeまたはOracleホームのゴールド・イメージを選択してください」サブセクションから、次の手順を実行します。

1. 「ソフトウェア・ライブラリからの選択」を選択します。

2. 「Web層のソース」セクションで、懐中電灯アイコンをクリックし、Web層を含む汎用コンポーネントを選択します。

3. 「アプリケーション層のソース」セクションで、懐中電灯アイコンをクリックし、アプリケーション層を含む汎用コンポーネントを選択します。

注意:
懐中電灯アイコンをクリックしてコンポーネントを検索すると、「コンポーネントの選択」ページに、ソフトウェア・ライブラリ内の使用可能なコンポーネントが表示されます。

- 新規インストールをデプロイする場合は、「準備完了」ステータスのshiphomeコンポーネントを選択します。デフォルトでは、「コンポーネントの選択」ページに「アクティブ」ステータスのコンポーネントは表示されません。

- ゴールド・イメージをデプロイする場合は、「準備完了」または「アクティブ」ステータスのゴールド・イメージ・コンポーネントを選択します。

4. 「次へ」をクリックします。

5. 「ターゲット・リスト」ページで、次の手順を実行します。

1. 「Web層ホスト」セクションで、「追加」をクリックして、Web層のデプロイ先のホストを追加します。このホストのプラットフォームが、アプリケーション層のデプロイ先のホストのプラットフォームと同じであることを確認します。

2. 「アプリケーション層ホスト」セクションで、「追加」をクリックして、アプリケーション層のデプロイ先のホストを追加します。このホストのプラットフォームが、Web層のデプロイ先のホストのプラットフォームと同じであることを確認します。

3. 「次へ」をクリックします。

6. 「資格証明/スケジュール」ページで、次の手順を実行します。

1. 「ターゲット・ホストの資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

2. 「エージェント・ホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

3. 「ソースOracleホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

4. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

5. 「次へ」をクリックします。

7. 「アプリケーションおよびWeb層」ページで、次の手順を実行します。

1. 「クラスタ詳細」セクションで、「新規クラスタの作成」を選択します。デフォルトでは、Cloud Controlにより既存のクラスタに基づいて詳細が事前に入力されます。デフォルト値を使用するか、新規のクラスタ名、インストール・ディレクトリ、マルチキャスト・アドレスおよびポートを指定できます。また、マルチキャスト・アドレスおよびポートがソース・クラスタに構成されている値と異なることを確認します。
「Web層インストールのベース・ディレクトリ」ではWeb層のデプロイ先のディレクトリの絶対パスを指定し、「アプリケーション層インストールのベース・ディレクトリ」ではアプリケーション層のデプロイ先のディレクトリの絶対パスを指定します。

「マルチキャスト・アドレス」で、アドレスの範囲が224.0.0.0から239.255.255.255までになっていることを確認します。これは、マルチキャスト・グループに結合される一連のノードに対する1つのIPアドレスです。

2. 「インスタンスの詳細」セクションで、Web層インスタンスとアプリケーション層インスタンスに一意のインスタンス名を指定し、ソース・ホストとターゲット・ホストにOC4J管理者パスワードを指定します。
デフォルトのインスタンス名はいつでも変更して、別のカスタム名にすることができます。ただし、デフォルトでは、ここで指定するインスタンス名にそのホストのホスト名とドメイン名が追加されるため、必ず一意の名前を指定してください。

重要:

- どのユーザーがインストールを実行したかには関係なく、各Oracle Application Server 10gインスタンスにはそれぞれのパスワードがあります。同じユーザーが複数のインスタンスをインストールした場合でも、パスワードは複数のインスタンス間で共有されません。

- 異なるパスワードを持つ複数のOC4Jインスタンスを含むアプリケーション・サーバーをクローニングする場合は、「追加パラメータ」セクションで追加パラメータとして-forceコマンドを使用します。詳細は、手順7 (e)を参照してください。

- ここでは、5文字以上30文字以下の英数字を含むパスワードを指定する必要があります。アンダースコア(_)、ドル($)またはシャープ(#)文字も使用できます。最初の文字は英字にし、1文字以上の数値を含める必要があります。

3. 「ポートの詳細」セクションで、クライアント・アプリケーションにより確立されたHTTP接続を管理するためのHTTPロード・バランサ・ホストおよびリスナー・ポートを指定します。あるいは、デフォルト値の7777を保持することもできます。通信を保護する場合は、「SSLの有効化」を選択します。

4. F5 BIG-IP Local Traffic Managerロード・バランサが構成されている場合は、「ロード・バランサ詳細」セクションで「ロード・バランサの構成」を選択し、必要な情報を入力します。

注意:
Cloud Controlでは、F5 BIG-IP Local Traffic Managerのみがサポートされています。他のロード・バランサがある場合は、「ロード・バランサの構成」を選択解除し、そのロード・バランサと、関連付けられているHTTPサーバーを手動で構成します。この場合には、このセクションを使用しないでください。

5. 「追加パラメータ」セクションで、デプロイメント・プロシージャに渡すWeb層またはアプリケーション層に固有の追加パラメータがあれば指定します。たとえば、-debugと指定します。その他、このプロビジョニング操作で使用できる任意のOracle Universal Installer (OUI)パラメータを指定できます。

重要:
異なるパスワードを持つ複数のOC4Jインスタンスがあるアプリケーション・サーバーをクローニングする場合は、このセクションで-forceコマンドを追加パラメータとして使用します。
これにより、「インスタンスの詳細」セクションで指定したパスワードが、プロビジョニングされるすべてのOC4Jインスタンスに均一に伝播されます。

ただし、プロビジョニングされたOC4Jインスタンスに異なるパスワードを維持する場合は、デプロイメント・プロシージャが正常に終了した後で、アプリケーション・サーバー・コンソールにアクセスし、個々のOC4Jインスタンスのパスワードを変更します。

6. 「アイデンティティ管理構成」セクションで、「なし」を選択します。

7. 「次へ」をクリックします。

8. 「Oracleホームの構成」ページで、次の手順を実行します。

1. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定します。
セキュリティ更新およびインストール更新を受け取るには、電子メール・アドレスが必要です。任意の電子メール・アドレスを指定できますが、My Oracle Supportのユーザー名を指定することをお薦めします。たとえば、john.mathew@xyz.comのように指定します。

My Oracle Supportパスワードが間違っている場合は、さらに2回試行できます。ただし、3回の試行すべてでパスワードが間違っている場合や、空白のままにした場合は、匿名で登録されるため、構成情報は収集されてMy Oracle Supportにアップロードされますが、アップロードされた情報はMy Oracle Supportアカウントに関連付けられません。したがって、My Oracle Supportに資格証明を使用してログインした場合、アカウントに対してこの情報は表示されません。ただし、電子メール・アドレスを指定した場合は、オラクル社からセキュリティ・アップデートとその他の通知が引き続きその電子メール・アドレスに送信されます。

2. Web層およびアプリケーション層のプロビジョニング先のホストがプロキシ・サーバー経由でインターネットに間接的に接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定し、「接続の詳細」セクションでプロキシ・サーバーの詳細を指定します。

注意:
プロキシ・サーバー設定は、デプロイメント・プロシージャの終了後、いつでも変更できます。このためには、プロビジョニングされたアプリケーション・サーバーのOracleホーム・ディレクトリ内の/ccr/bin/ディレクトリからconfigCCRコマンドを実行します。

3. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接的にも間接的にも接続されていない場合は、電子メール・アドレスを指定し、その他のフィールドは空白のままにしておきます。
この場合、インストール・プロセスの完了後に、手動で構成情報を収集してMy Oracle Supportにアップロードしてください。

4. 「次へ」をクリックします。

9. 「確認」ページで、Web層およびアプリケーション層をプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

35.3.2.2 プロビジョニングし、インターネット・ディレクトリを使用して新規クラスタを作成

この項では、ソフトウェア・ライブラリで使用可能なゴールド・イメージと同一のOracle Application Server 10gリリース1 (10.1.3)のアプリケーション層およびWeb層をプロビジョニングし、インターネット・ディレクトリを使用して新規のクラスタを作成する方法について説明します。

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

デザイナの前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- ソース・ホストとターゲット・ホストの構成を比較し、両者の構成が同じであることを確認します。構成が異なる場合は、システム管理者に連絡し、不一致を修正してから、デプロイメント・プロシージャを実行します。
ホストの構成を比較するには、Cloud Controlで「ターゲット」、「ホスト」の順にクリックします。「ホスト」ページで、ソース・ホストの名前をクリックしてそのホームページにアクセスし、「構成」タブをクリックします。「構成」ページで「構成の比較」をクリックし、ターゲット・ホストを選択します。

- 複数のWeb層をデプロイする場合は、ソフトウェア・ロード・バランサが設定されていて、Web層のホストからアクセス可能になっていることを確認します。
ソフトウェア・ライブラリには、選択したWeb層でF5 Networks社のBig-IP Application Switch(ソフトウェア・バージョン4.5 PTF.5)ロード・バランサを構成するためのスクリプトが用意されています。その他のシステム(Cisco CSM 3.1など)の場合は、独自の構成でこのスクリプトを上書きします。このスクリプトは、ソフトウェア・ライブラリの次の場所にあります。

Directives/Oracle Directives/Loadbalancer

- すべてのターゲット・ホストで、Web層およびアプリケーション層のインストール先のインストール・ベース・ディレクトリがアクセス可能になっている(ただし共有はされていない)ことを確認します。

オペレータの前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

Web層およびアプリケーション層をプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. 「デプロイメント・プロシージャ」セクションで、「アプリケーション・サーバー・プロビジョニング・プロシージャ」をクリックします。

3. 「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ」サブタブで、表から「Application Server Deployment 10.1.3」を選択します。次に、「デプロイメントのスケジュール」をクリックします。

4. 「ソース選択」ページで、「ソース選択」セクションの「ソフトウェア・ライブラリからOracleホームのゴールド・イメージを選択してください」サブセクションから、次の手順を実行します。

1. 「ソフトウェア・ライブラリからの選択」を選択します。

2. 「Web層のソース」セクションで、懐中電灯アイコンをクリックし、Web層を含む汎用コンポーネントを選択します。

3. 「アプリケーション層のソース」セクションで、懐中電灯アイコンをクリックし、アプリケーション層を含む汎用コンポーネントを選択します。

注意:
懐中電灯アイコンをクリックしてコンポーネントを検索すると、「コンポーネントの選択」ページに、ソフトウェア・ライブラリ内の使用可能なコンポーネントが表示されます。ゴールド・イメージをデプロイする場合は、「準備完了」または「アクティブ」ステータスのゴールド・イメージ・コンポーネントを選択します。

4. 「次へ」をクリックします。

5. 「ターゲット・リスト」ページで、次の手順を実行します。

1. 「Web層ホスト」セクションで、「追加」をクリックして、Web層のデプロイ先のホストを追加します。このホストのプラットフォームが、アプリケーション層のデプロイ先のホストのプラットフォームと同じであることを確認します。

2. 「アプリケーション層ホスト」セクションで、「追加」をクリックして、アプリケーション層のデプロイ先のホストを追加します。このホストのプラットフォームが、Web層のデプロイ先のホストのプラットフォームと同じであることを確認します。

3. 「次へ」をクリックします。

6. 「資格証明/スケジュール」ページで、次の手順を実行します。

1. 「ターゲット・ホストの資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

2. 「エージェント・ホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

3. 「ソースOracleホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

4. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

5. 「次へ」をクリックします。

7. 「アプリケーションおよびWeb層」ページで、次の手順を実行します。

1. 「クラスタ詳細」セクションで、「新規クラスタの作成」を選択します。デフォルトでは、Cloud Controlにより既存のクラスタに基づいて詳細が事前に入力されます。デフォルト値を使用するか、新規のクラスタ名、インストール・ディレクトリ、マルチキャスト・アドレスおよびポートを指定できます。また、マルチキャスト・アドレスおよびポートがソース・クラスタに構成されている値と異なることを確認します。
「Web層インストールのベース・ディレクトリ」ではWeb層のデプロイ先のディレクトリの絶対パスを指定し、「アプリケーション層インストールのベース・ディレクトリ」ではアプリケーション層のデプロイ先のディレクトリの絶対パスを指定します。

「マルチキャスト・アドレス」で、アドレスの範囲が224.0.0.0から239.255.255.255までになっていることを確認します。これは、マルチキャスト・グループに結合される一連のノードに対する1つのIPアドレスです。

2. 「インスタンスの詳細」セクションで、Web層インスタンスとアプリケーション層インスタンスに一意のインスタンス名を指定し、ソース・ホストとターゲット・ホストにOC4J管理者パスワードを指定します。
デフォルトのインスタンス名はいつでも変更して、別のカスタム名にすることができます。ただし、デフォルトでは、ここで指定するインスタンス名にそのホストのホスト名とドメイン名が追加されるため、必ず一意の名前を指定してください。

重要:

- どのユーザーがインストールを実行したかには関係なく、各Oracle Application Server 10gインスタンスにはそれぞれのパスワードがあります。同じユーザーが複数のインスタンスをインストールした場合でも、パスワードは複数のインスタンス間で共有されません。

- 異なるパスワードを持つ複数のOC4Jインスタンスを含むアプリケーション・サーバーをクローニングする場合は、「追加パラメータ」セクションで追加パラメータとして-forceコマンドを使用します。詳細は、手順7 (e)を参照してください。

- ここでは、5文字以上30文字以下の英数字を含むパスワードを指定する必要があります。アンダースコア(_)、ドル($)またはシャープ(#)文字も使用できます。最初の文字は英字にし、1文字以上の数値を含める必要があります。

3. 「ポートの詳細」セクションで、クライアント・アプリケーションにより確立されたHTTP接続を管理するためのHTTPロード・バランサ・ホストおよびリスナー・ポートを指定します。あるいは、デフォルト値の7777を保持することもできます。通信を保護する場合は、「SSLの有効化」を選択します。

4. F5 BIG-IP Local Traffic Managerロード・バランサが構成されている場合は、「ロード・バランサ詳細」セクションで「ロード・バランサの構成」を選択し、必要な情報を入力します。

注意:
Cloud Controlでは、F5 BIG-IP Local Traffic Managerのみがサポートされています。他のロード・バランサがある場合は、「ロード・バランサの構成」を選択解除し、そのロード・バランサと、関連付けられているHTTPサーバーを手動で構成します。この場合には、このセクションを使用しないでください。

5. 「追加パラメータ」セクションで、デプロイメント・プロシージャに渡すWeb層またはアプリケーション層に固有の追加パラメータがあれば指定します。たとえば、-debugと指定します。その他、このプロビジョニング操作で使用できる任意のOracle Universal Installer (OUI)パラメータを指定できます。

重要:
異なるパスワードを持つ複数のOC4Jインスタンスがあるアプリケーション・サーバーをクローニングする場合は、このセクションで-forceコマンドを追加パラメータとして使用します。
これにより、「インスタンスの詳細」セクションで指定したパスワードが、プロビジョニングされるすべてのOC4Jインスタンスに均一に伝播されます。

ただし、プロビジョニングされたOC4Jインスタンスに異なるパスワードを維持する場合は、デプロイメント・プロシージャが正常に終了した後で、アプリケーション・サーバー・コンソールにアクセスし、個々のOC4Jインスタンスのパスワードを変更します。

6. 「アイデンティティ管理構成」セクションで、「LDAPベース・プロバイダでJava Authentication and Authorization Service(JAZN)を構成」を選択します。
このオプションを使用すると、OC4Jアプリケーションの認証および認可に使用するJAZN LDAPベースのプロバイダを設定できます。

Java Authentication and Authorization Service (JAAS)は、サービスおよびアプリケーションによるユーザーのアクセス制御の認証と実施を可能にするJavaパッケージです。Oracle Application Server 10g Containers for e (OC4J)は、JAASプロバイダ(JAZNとも呼ばれる)を実装することにより、JAASをサポートしています。

JAASプロバイダは、アプリケーション環境に統合するユーザー認証、認可および委任のサービスをアプリケーション開発者に提供します。また、JAASポリシーもサポートされています。ポリシーには、ユーザーにリソースの使用(ファイルの読取りなど)を許可するルール(権限)が含まれます。

7. 「次へ」をクリックします。

8. 「アイデンティティ管理」ページで、次の手順を実行します。

1. 「アイデンティティ管理ホストの詳細」セクションで、Oracle Application Serverのユーザーおよびグループのアイデンティティ管理に使用するインターネット・ディレクトリの接続情報を指定します。インターネット・ディレクトリがインストールされていない場合は、OracleAS Infrastructureコンポーネントを使用してインストールします。

2. 「Internet Directoryのログイン詳細」セクションで、インターネット・ディレクトリのiASAdminグループに属するユーザーの資格証明を指定します。

3. 「次へ」をクリックします。

9. 「Oracleホームの構成」ページで、次の手順を実行します。

1. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定します。
セキュリティ更新およびインストール更新を受け取るには、電子メール・アドレスが必要です。任意の電子メール・アドレスを指定できますが、My Oracle Supportのユーザー名を指定することをお薦めします。たとえば、john.mathew@xyz.comのように指定します。

My Oracle Supportパスワードが間違っている場合は、さらに2回試行できます。ただし、3回の試行すべてでパスワードが間違っている場合や、空白のままにした場合は、匿名で登録されるため、構成情報は収集されてMy Oracle Supportにアップロードされますが、アップロードされた情報はMy Oracle Supportアカウントに関連付けられません。したがって、My Oracle Supportに資格証明を使用してログインした場合、アカウントに対してこの情報は表示されません。ただし、電子メール・アドレスを指定した場合は、オラクル社からセキュリティ・アップデートとその他の通知が引き続きその電子メール・アドレスに送信されます。

2. Web層およびアプリケーション層のプロビジョニング先のホストがプロキシ・サーバー経由でインターネットに間接的に接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定し、「接続の詳細」セクションでプロキシ・サーバーの詳細を指定します。

注意:
プロキシ・サーバー設定は、デプロイメント・プロシージャの終了後、いつでも変更できます。このためには、プロビジョニングされたアプリケーション・サーバーのOracleホーム・ディレクトリ内の/ccr/bin/ディレクトリからconfigCCRコマンドを実行します。

3. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接的にも間接的にも接続されていない場合は、電子メール・アドレスを指定し、その他のフィールドは空白のままにしておきます。
この場合、インストール・プロセスの完了後に、手動で構成情報を収集してMy Oracle Supportにアップロードしてください。

4. 「次へ」をクリックします。

10. 「確認」ページで、Web層およびアプリケーション層をプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

35.3.2.3 プロビジョニングし、インターネット・ディレクトリを使用せずにスタンドアロン・インスタンスとしてOracle Application Serverを処理

この項では、ソフトウェア・ライブラリで使用可能なゴールド・イメージと同一のOracle Application Server 10gリリース1 (10.1.3)のアプリケーション層およびWeb層をプロビジョニングし、インターネット・ディレクトリを使用せずに新規のクラスタを作成する方法について説明します。

この項の具体的な内容は次のとおりです。

- 前提条件

- プロビジョニング・プロシージャ

35.3.2.3.1 前提条件

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

設計者に対する前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- ソース・ホストとターゲット・ホストの構成を比較し、両者の構成が同じであることを確認します。構成が異なる場合は、システム管理者に連絡し、不一致を修正してから、デプロイメント・プロシージャを実行します。
ホストの構成を比較するには、Cloud Controlで「ターゲット」、「ホスト」の順にクリックします。「ホスト」ページで、ソース・ホストの名前をクリックしてそのホームページにアクセスし、「構成」タブをクリックします。「構成」ページで「構成の比較」をクリックし、ターゲット・ホストを選択します。

- 複数のWeb層をデプロイする場合は、ソフトウェア・ロード・バランサが設定されていて、Web層のホストからアクセス可能になっていることを確認します。
ソフトウェア・ライブラリには、選択したWeb層でF5 Networks社のBig-IP Application Switch(ソフトウェア・バージョン4.5 PTF.5)ロード・バランサを構成するためのスクリプトが用意されています。その他のシステム(Cisco CSM 3.1など)の場合は、独自の構成でこのスクリプトを上書きします。このスクリプトは、ソフトウェア・ライブラリの次の場所にあります。

Directives/Oracle Directives/Loadbalancer

- すべてのターゲット・ホストで、Web層およびアプリケーション層のインストール先のインストール・ベース・ディレクトリがアクセス可能になっている(ただし共有はされていない)ことを確認します。

オペレータに対する前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

35.3.2.3.2 プロビジョニング・プロシージャ

Web層およびアプリケーション層をプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. 「デプロイメント・プロシージャ」セクションで、「アプリケーション・サーバー・プロビジョニング・プロシージャ」をクリックします。

3. 「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ」サブタブで、表から「Application Server Deployment 10.1.3」を選択します。次に、「デプロイメントのスケジュール」をクリックします。

4. 「ソース選択」ページで、「ソース選択」セクションの「ソフトウェア・ライブラリからOracleホームのゴールド・イメージを選択してください」サブセクションから、次の手順を実行します。

1. 「ソフトウェア・ライブラリからの選択」を選択します。

2. 「Web層のソース」セクションで、懐中電灯アイコンをクリックし、Web層を含む汎用コンポーネントを選択します。

3. 「アプリケーション層のソース」セクションで、懐中電灯アイコンをクリックし、アプリケーション層を含む汎用コンポーネントを選択します。

注意:
懐中電灯アイコンをクリックしてコンポーネントを検索すると、「コンポーネントの選択」ページに、ソフトウェア・ライブラリ内の使用可能なコンポーネントが表示されます。ゴールド・イメージをデプロイする場合は、「準備完了」または「アクティブ」ステータスのゴールド・イメージ・コンポーネントを選択します。

4. 「次へ」をクリックします。

5. 「ターゲット・リスト」ページで、次の手順を実行します。

1. 「Web層ホスト」セクションで、「追加」をクリックして、Web層のデプロイ先のホストを追加します。このホストのプラットフォームが、アプリケーション層のデプロイ先のホストのプラットフォームと同じであることを確認します。

2. 「アプリケーション層ホスト」セクションで、「追加」をクリックして、アプリケーション層のデプロイ先のホストを追加します。このホストのプラットフォームが、Web層のデプロイ先のホストのプラットフォームと同じであることを確認します。

3. 「次へ」をクリックします。

6. 「資格証明/スケジュール」ページで、次の手順を実行します。

1. 「ターゲット・ホストの資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

2. 「エージェント・ホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

3. 「ソースOracleホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

4. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

5. 「次へ」をクリックします。

7. 「アプリケーションおよびWeb層」ページで、次の手順を実行します。

1. 「クラスタ詳細」セクションで、「スタンドアロンAS」を選択します。

2. 「インスタンスの詳細」セクションで、Web層インスタンスとアプリケーション層インスタンスに一意のインスタンス名を指定し、ソース・ホストとターゲット・ホストにOC4J管理者パスワードを指定します。
デフォルトのインスタンス名はいつでも変更して、別のカスタム名にすることができます。ただし、デフォルトでは、ここで指定するインスタンス名にそのホストのホスト名とドメイン名が追加されるため、必ず一意の名前を指定してください。

重要:

- どのユーザーがインストールを実行したかには関係なく、各Oracle Application Server 10gインスタンスにはそれぞれのパスワードがあります。同じユーザーが複数のインスタンスをインストールした場合でも、パスワードは複数のインスタンス間で共有されません。

- 異なるパスワードを持つ複数のOC4Jインスタンスを含むアプリケーション・サーバーをクローニングする場合は、「追加パラメータ」セクションで追加パラメータとして-forceコマンドを使用します。詳細は、手順7 (e)を参照してください。

- ここでは、5文字以上30文字以下の英数字を含むパスワードを指定する必要があります。アンダースコア(_)、ドル($)またはシャープ(#)文字も使用できます。最初の文字は英字にし、1文字以上の数値を含める必要があります。

3. 「ポートの詳細」セクションで、クライアント・アプリケーションにより確立されたHTTP接続を管理するためのHTTPロード・バランサ・ホストおよびリスナー・ポートを指定します。あるいは、デフォルト値の7777を保持することもできます。通信を保護する場合は、「SSLの有効化」を選択します。

4. F5 BIG-IP Local Traffic Managerロード・バランサが構成されている場合は、「ロード・バランサ詳細」セクションで「ロード・バランサの構成」を選択し、必要な情報を入力します。

注意:
Cloud Controlでは、F5 BIG-IP Local Traffic Managerのみがサポートされています。他のロード・バランサがある場合は、「ロード・バランサの構成」を選択解除し、そのロード・バランサと、関連付けられているHTTPサーバーを手動で構成します。この場合には、このセクションを使用しないでください。

5. 「追加パラメータ」セクションで、デプロイメント・プロシージャに渡すWeb層またはアプリケーション層に固有の追加パラメータがあれば指定します。たとえば、-debugと指定します。その他、このプロビジョニング操作で使用できる任意のOracle Universal Installer (OUI)パラメータを指定できます。

重要:
異なるパスワードを持つ複数のOC4Jインスタンスがあるアプリケーション・サーバーをクローニングする場合は、このセクションで-forceコマンドを追加パラメータとして使用します。
これにより、「インスタンスの詳細」セクションで指定したパスワードが、プロビジョニングされるすべてのOC4Jインスタンスに均一に伝播されます。

ただし、プロビジョニングされたOC4Jインスタンスに異なるパスワードを維持する場合は、デプロイメント・プロシージャが正常に終了した後で、アプリケーション・サーバー・コンソールにアクセスし、個々のOC4Jインスタンスのパスワードを変更します。

6. 「アイデンティティ管理構成」セクションで、「なし」を選択します。

7. 「次へ」をクリックします。

8. 「Oracleホームの構成」ページで、次の手順を実行します。

1. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定します。
セキュリティ更新およびインストール更新を受け取るには、電子メール・アドレスが必要です。任意の電子メール・アドレスを指定できますが、My Oracle Supportのユーザー名を指定することをお薦めします。たとえば、john.mathew@xyz.comのように指定します。

My Oracle Supportパスワードが間違っている場合は、さらに2回試行できます。ただし、3回の試行すべてでパスワードが間違っている場合や、空白のままにした場合は、匿名で登録されるため、構成情報は収集されてMy Oracle Supportにアップロードされますが、アップロードされた情報はMy Oracle Supportアカウントに関連付けられません。したがって、My Oracle Supportに資格証明を使用してログインした場合、アカウントに対してこの情報は表示されません。ただし、電子メール・アドレスを指定した場合は、オラクル社からセキュリティ・アップデートとその他の通知が引き続きその電子メール・アドレスに送信されます。

2. Web層およびアプリケーション層のプロビジョニング先のホストがプロキシ・サーバー経由でインターネットに間接的に接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定し、「接続の詳細」セクションでプロキシ・サーバーの詳細を指定します。

注意:
プロキシ・サーバー設定は、デプロイメント・プロシージャの終了後、いつでも変更できます。このためには、プロビジョニングされたアプリケーション・サーバーのOracleホーム・ディレクトリ内の/ccr/bin/ディレクトリからconfigCCRコマンドを実行します。

3. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接的にも間接的にも接続されていない場合は、電子メール・アドレスを指定し、その他のフィールドは空白のままにしておきます。
この場合、インストール・プロセスの完了後に、手動で構成情報を収集してMy Oracle Supportにアップロードしてください。

4. 「次へ」をクリックします。

9. 「確認」ページで、Web層およびアプリケーション層をプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

35.3.2.4 プロビジョニングし、インターネット・ディレクトリを使用してスタンドアロン・インスタンスとしてOracle Application Serverを処理

この項では、ソフトウェア・ライブラリで使用可能なゴールド・イメージと同一のOracle Application Server 10gリリース1 (10.1.3)のアプリケーション層およびWeb層をプロビジョニングし、インターネット・ディレクトリを使用して新規のクラスタを作成する方法について説明します。

デプロイメント・プロシージャを実行する前に、次の前提条件を満たしている必要があります。

デザイナの前提条件

- 第2章に示されている前提条件を満たしていることを確認します。

- ソース・ホストとターゲット・ホストの構成を比較し、両者の構成が同じであることを確認します。構成が異なる場合は、システム管理者に連絡し、不一致を修正してから、デプロイメント・プロシージャを実行します。
ホストの構成を比較するには、Cloud Controlで「ターゲット」、「ホスト」の順にクリックします。「ホスト」ページで、ソース・ホストの名前をクリックしてそのホームページにアクセスし、「構成」タブをクリックします。「構成」ページで「構成の比較」をクリックし、ターゲット・ホストを選択します。

- 複数のWeb層をデプロイする場合は、ソフトウェア・ロード・バランサが設定されていて、Web層のホストからアクセス可能になっていることを確認します。
ソフトウェア・ライブラリには、選択したWeb層でF5 Networks社のBig-IP Application Switch(ソフトウェア・バージョン4.5 PTF.5)ロード・バランサを構成するためのスクリプトが用意されています。その他のシステム(Cisco CSM 3.1など)の場合は、独自の構成でこのスクリプトを上書きします。このスクリプトは、ソフトウェア・ライブラリの次の場所にあります。

Directives/Oracle Directives/Loadbalancer

- すべてのターゲット・ホストで、Web層およびアプリケーション層のインストール先のインストール・ベース・ディレクトリがアクセス可能になっている(ただし共有はされていない)ことを確認します。

オペレータの前提条件

- 環境でPAM/LDAPが有効になっている場合は、ターゲット・エージェントがPAM/LDAPで構成されていることを確認します。詳細は、My Oracle Supportのノート422073.1を参照してください。

- オペレーティング・システム・ユーザーがデプロイメント・プロシージャを実行する権限を持っていることと、rootユーザーに切り替えて宛先ホストですべてのコマンドを実行できることを確認します。たとえば、mkdirやlsなどのコマンドです。
これを行う権限がない、つまり、ロックされたアカウントを使用している場合は、デプロイメント・プロシージャを別のユーザーとして実行できるように、または特別な権限を必要とする手順は無視できるように、管理者(設計者)にデプロイメント・プロシージャのカスタマイズを依頼します。

たとえば、ユーザー・アカウントAがroot権限を持っているが、ユーザー・アカウントBを使用してデプロイメント・プロシージャを実行できるようにするとします。この場合、デプロイメント・プロシージャをカスタマイズして、ユーザー・アカウントBからAに切り替えることができます。

カスタマイズの詳細は、第51章を参照してください。

Web層およびアプリケーション層をプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「Middlewareプロビジョニング」を選択します。

2. 「デプロイメント・プロシージャ」セクションで、「アプリケーション・サーバー・プロビジョニング・プロシージャ」をクリックします。

3. 「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ」サブタブで、表から「Application Server Deployment 10.1.3」を選択します。次に、「デプロイメントのスケジュール」をクリックします。

4. 「ソース選択」ページで、「ソース選択」セクションの「ソフトウェア・ライブラリからOracleホームのゴールド・イメージを選択してください」サブセクションから、次の手順を実行します。

1. 「ソフトウェア・ライブラリからの選択」を選択します。

2. 「Web層のソース」セクションで、懐中電灯アイコンをクリックし、Web層を含む汎用コンポーネントを選択します。

3. 「アプリケーション層のソース」セクションで、懐中電灯アイコンをクリックし、アプリケーション層を含む汎用コンポーネントを選択します。

注意:
懐中電灯アイコンをクリックしてコンポーネントを検索すると、「コンポーネントの選択」ページに、ソフトウェア・ライブラリ内の使用可能なコンポーネントが表示されます。ゴールド・イメージをデプロイする場合は、「準備完了」または「アクティブ」ステータスのゴールド・イメージ・コンポーネントを選択します。

4. 「次へ」をクリックします。

5. 「ターゲット・リスト」ページで、次の手順を実行します。

1. 「Web層ホスト」セクションで、「追加」をクリックして、Web層のデプロイ先のホストを追加します。このホストのプラットフォームが、アプリケーション層のデプロイ先のホストのプラットフォームと同じであることを確認します。

2. 「アプリケーション層ホスト」セクションで、「追加」をクリックして、アプリケーション層のデプロイ先のホストを追加します。このホストのプラットフォームが、Web層のデプロイ先のホストのプラットフォームと同じであることを確認します。

3. 「次へ」をクリックします。

6. 「資格証明/スケジュール」ページで、次の手順を実行します。

1. 「ターゲット・ホストの資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

2. 「エージェント・ホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。

注意:
これらの優先資格証明をオプションでオーバーライドできます。ここで指定した資格証明は、プロビジョニング操作を実行するデプロイメント・プロシージャによって使用されます。この環境が安全であり、ロックされたアカウントがある場合は、次の点を確認してください。

- プロビジョニング操作を実行するため、ここで指定した資格証明に、ロックされたアカウントに切り替えるための権限があること。

- ロックされた環境をサポートするよう、デプロイメント・プロシージャがカスタマイズされていること。

詳細は、第51章を参照してください。

複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

3. 「ソースOracleホーム資格証明」セクションで、管理リポジトリに格納されている優先資格証明が使用されるように、デフォルトの選択(「優先資格証明」)を保持します。
優先資格証明を別の資格証明セットでオーバーライドするには、「優先資格証明のオーバーライド」を選択します。複数のホストにわたって同じオペレーティング・システム資格証明を使用する場合は、「ホスト資格証明」リストから「すべてのOracleホームで同一」を選択し、ホストごとに別々の資格証明を使用する場合は、「各Oracleホームごとに個別」を選択します。選択した項目に応じて、資格証明を指定します。複数のユーザーが同じオペレーティング・システム・グループに属していることを確認します。

4. 「スケジュール」セクションで、デプロイメント・プロシージャを即時または後で実行するようにスケジュールします。

5. 「次へ」をクリックします。

7. 「アプリケーションおよびWeb層」ページで、次の手順を実行します。

1. 「クラスタ詳細」セクションで、「スタンドアロンAS」を選択します。

2. 「インスタンスの詳細」セクションで、Web層インスタンスとアプリケーション層インスタンスに一意のインスタンス名を指定し、ソース・ホストとターゲット・ホストにOC4J管理者パスワードを指定します。
デフォルトのインスタンス名はいつでも変更して、別のカスタム名にすることができます。ただし、デフォルトでは、ここで指定するインスタンス名にそのホストのホスト名とドメイン名が追加されるため、必ず一意の名前を指定してください。

重要:

- どのユーザーがインストールを実行したかには関係なく、各Oracle Application Server 10gインスタンスにはそれぞれのパスワードがあります。同じユーザーが複数のインスタンスをインストールした場合でも、パスワードは複数のインスタンス間で共有されません。

- 異なるパスワードを持つ複数のOC4Jインスタンスを含むアプリケーション・サーバーをクローニングする場合は、「追加パラメータ」セクションで追加パラメータとして-forceコマンドを使用します。詳細は、手順7 (e)を参照してください。

- ここでは、5文字以上30文字以下の英数字を含むパスワードを指定する必要があります。アンダースコア(_)、ドル($)またはシャープ(#)文字も使用できます。最初の文字は英字にし、1文字以上の数値を含める必要があります。

3. 「ポートの詳細」セクションで、クライアント・アプリケーションにより確立されたHTTP接続を管理するためのHTTPロード・バランサ・ホストおよびリスナー・ポートを指定します。あるいは、デフォルト値の7777を保持することもできます。通信を保護する場合は、「SSLの有効化」を選択します。

4. F5 BIG-IP Local Traffic Managerロード・バランサが構成されている場合は、「ロード・バランサ詳細」セクションで「ロード・バランサの構成」を選択し、必要な情報を入力します。

注意:
Cloud Controlでは、F5 BIG-IP Local Traffic Managerのみがサポートされています。他のロード・バランサがある場合は、「ロード・バランサの構成」を選択解除し、そのロード・バランサと、関連付けられているHTTPサーバーを手動で構成します。この場合には、このセクションを使用しないでください。

5. 「追加パラメータ」セクションで、デプロイメント・プロシージャに渡すWeb層またはアプリケーション層に固有の追加パラメータがあれば指定します。たとえば、-debugと指定します。その他、このプロビジョニング操作で使用できる任意のOracle Universal Installer (OUI)パラメータを指定できます。

重要:
異なるパスワードを持つ複数のOC4Jインスタンスがあるアプリケーション・サーバーをクローニングする場合は、このセクションで-forceコマンドを追加パラメータとして使用します。
これにより、「インスタンスの詳細」セクションで指定したパスワードが、プロビジョニングされるすべてのOC4Jインスタンスに均一に伝播されます。

ただし、プロビジョニングされたOC4Jインスタンスに異なるパスワードを維持する場合は、デプロイメント・プロシージャが正常に終了した後で、アプリケーション・サーバー・コンソールにアクセスし、個々のOC4Jインスタンスのパスワードを変更します。

6. 「アイデンティティ管理構成」セクションで、「LDAPベース・プロバイダでJava Authentication and Authorization Service(JAZN)を構成」を選択します。
このオプションを使用すると、OC4Jアプリケーションの認証および認可に使用するJAZN LDAPベースのプロバイダを設定できます。

Java Authentication and Authorization Service (JAAS)は、サービスおよびアプリケーションによるユーザーのアクセス制御の認証と実施を可能にするJavaパッケージです。Oracle Application Server 10g Containers for J2EE (OC4J)は、JAASプロバイダ(JAZNとも呼ばれる)を実装することにより、JAASをサポートしています。

JAASプロバイダは、アプリケーション環境に統合するユーザー認証、認可および委任のサービスをアプリケーション開発者に提供します。また、JAASポリシーもサポートされています。ポリシーには、ユーザーにリソースの使用(ファイルの読取りなど)を許可するルール(権限)が含まれます。

7. 「次へ」をクリックします。

8. 「アイデンティティ管理」ページで、次の手順を実行します。

1. 「アイデンティティ管理ホストの詳細」セクションで、Oracle Application Serverのユーザーおよびグループのアイデンティティ管理に使用するインターネット・ディレクトリの接続情報を指定します。インターネット・ディレクトリがインストールされていない場合は、OracleAS Infrastructureコンポーネントを使用してインストールします。

2. 「Internet Directoryのログイン詳細」セクションで、インターネット・ディレクトリのiASAdminグループに属するユーザーの資格証明を指定します。

3. 「次へ」をクリックします。Cloud Controlで「Oracleホームの構成」ページが表示されます。

9. 「Oracleホームの構成」ページで、次の手順を実行します。

1. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定します。
セキュリティ更新およびインストール更新を受け取るには、電子メール・アドレスが必要です。任意の電子メール・アドレスを指定できますが、My Oracle Supportのユーザー名を指定することをお薦めします。たとえば、john.mathew@xyz.comのように指定します。

My Oracle Supportパスワードが間違っている場合は、さらに2回試行できます。ただし、3回の試行すべてでパスワードが間違っている場合や、空白のままにした場合は、匿名で登録されるため、構成情報は収集されてMy Oracle Supportにアップロードされますが、アップロードされた情報はMy Oracle Supportアカウントに関連付けられません。したがって、My Oracle Supportに資格証明を使用してログインした場合、アカウントに対してこの情報は表示されません。ただし、電子メール・アドレスを指定した場合は、オラクル社からセキュリティ・アップデートとその他の通知が引き続きその電子メール・アドレスに送信されます。

2. Web層およびアプリケーション層のプロビジョニング先のホストがプロキシ・サーバー経由でインターネットに間接的に接続されている場合は、電子メール・アドレスおよびMy Oracle Supportパスワードを指定し、「接続の詳細」セクションでプロキシ・サーバーの詳細を指定します。

注意:
プロキシ・サーバー設定は、デプロイメント・プロシージャの終了後、いつでも変更できます。このためには、プロビジョニングされたアプリケーション・サーバーのOracleホーム・ディレクトリ内の/ccr/bin/ディレクトリからconfigCCRコマンドを実行します。

3. Web層およびアプリケーション層のプロビジョニング先のホストがインターネットに直接的にも間接的にも接続されていない場合は、電子メール・アドレスを指定し、その他のフィールドは空白のままにしておきます。
この場合、インストール・プロセスの完了後に、手動で構成情報を収集してMy Oracle Supportにアップロードしてください。

4. 「次へ」をクリックします。

10. 「確認」ページで、Web層およびアプリケーション層をプロビジョニングするために指定した詳細を確認し、「発行」をクリックします。

35.4 Oracle SOA Suite 10g (10.1.3.4および10.1.3.5)のプロビジョニング

Oracle SOA Suite 10g (10.1.3.4および10.1.3.5)のユースケースおよび各ユースケースの前提条件とデプロイ手順は、第35.3項で説明されているものとほぼ同じです。

唯一の違いは、手順3の「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ」サブタブで、表から「Application Server Deployment 10.1.3.xSOA」、「デプロイメントのスケジュール」の順に選択する必要がある点のみです。

第VII部

ベアメタル・サーバーのプロビジョニング

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

- 第36章「ベアメタル・サーバーのプロビジョニング」

36 ベアメタル・サーバーのプロビジョニング

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用してベアメタル・サーバー上のLinuxをプロビジョニングする方法を説明します。この章の具体的な内容は次のとおりです。

- ベアメタル・サーバーのプロビジョニングの概要

- ベアメタル・プロビジョニングの概要

- Linuxのサポート対象リリース

- ベアメタル・プロビジョニングのインフラストラクチャの設定

- ベアメタル・サーバーのプロビジョニング

- Oracle VM Serverのプロビジョニング

- 保存済計画の表示

- ベアメタル・サーバー上のLinuxオペレーティング・システムのプロビジョニングにおける保存済計画の使用

ヒント:
ベアメタル・ボックス上のLinuxのプロビジョニングを開始する前に、ステージング・サーバーの優先資格証明を設定することをお薦めします。そうしない場合は、第2.3項の手順に従って優先資格証明を設定します。参照ホストを使用する場合は、参照ホストの資格証明も設定します。Linuxをプロビジョニングするデプロイメント・プロシージャを構成するときに、優先資格証明も設定できます。

注意:
Linuxのプロビジョニング操作を開始する前に、sudo権限を構成してください。sudo権限の構成の詳細は、第2.3項を参照してください。

36.1 ベアメタル・サーバーのプロビジョニングの概要

このセクションでは、この章に取り組むための手引きとして、Linuxオペレーティング・システムのプロビジョニング手順の概要を説明します。このセクションは、Linuxオペレーティング・システムのプロビジョニングを成功させるために必要な一連の処理を理解するためのドキュメント・マップと考えてください。各手順の参照リンクをクリックすると、詳細情報が説明されている関連セクションが表示されます。

表36-1 Linuxオペレーティング・システムのプロビジョニングの概要

ステップ

説明

参照リンク

手順1

サポートされているリリースの把握

プロビジョニングがサポートされているLinuxのリリースを確認します。

Linuxのプロビジョニングでサポートされるリリースを確認するには、第36.3項を参照してください。

手順2

ユースケースの把握

この章ではLinuxのプロビジョニングについて説明します。Linuxのプロビジョニングのユースケースを理解します。

- ベアメタル・ボックスのプロビジョニングの詳細は、第36.6項を参照してください。

手順3

インフラストラクチャの設定

Linuxのプロビジョニングを実行する前に、プロビジョニング環境の設定、必須パッチの適用およびOracleソフトウェア・ライブラリの設定などの前提条件を満たす必要があります。

- ベアメタル・ボックスをプロビジョニングするために満たす必要がある前提条件の詳細は、第36.4項を参照してください。

手順4

Linuxのプロビジョニング

ベアメタル・ボックス上のLinuxをプロビジョニングします。

- ベアメタル・ボックス上のLinuxをプロビジョニングするには、第36.6項の説明に従います。

36.2 ベアメタル・プロビジョニングの概要

弊社のデータ・センターにおいて低コストのサーバーが普及したことにより、一連の管理上の課題が新たに発生しました。一般に認められている問題には、オペレーティング・システムとソフトウェアのデプロイ全体にわたる整合性および互換性の管理の難しさ、サーバー・ドリフトおよびセキュリティの脆弱性によるコンプライアンスの欠如、ソフトウェアのデプロイの難しさ、業務のコストの高さ、環境のワークロード変化への適応の難しさがあります。これらの結果として、システム管理者およびDBAはソフトウェアとサーバーのプロビジョニング業務に多大な時間を費やすことが余儀なくされます。

ソフトウェアおよびサーバー管理の課題に対するオラクル社の答えは、Enterprise Manager Cloud Controlに組み込まれるアプリケーションである、ベア・メタル・プロビジョニング・アプリケーションです。このアプリケーションは、ソフトウェアおよびサーバーを迅速かつ効率的にプロビジョニングすることで、すべてのデータ・センターおよびサーバー・ファームの課題に対応します。ベアメタル・サーバーとライブ・サーバーの両方をプロビジョニングするために標準化されたPXE (Pre Boot Execution環境)ブート・プロセスが使用されます。このプロセスにはロール・ベースのユーザー・インタフェースが用意されているため、ゴールド・イメージの作成、無人の自動インストールの開始が容易になります。

内容は次のとおりです。

- 「ベアメタル・プロビジョニング」ページヘのアクセス

- ベアメタルのプロビジョニング環境

- ベアメタルのプロビジョニング

36.2.1 「ベアメタル・プロビジョニング」ページヘのアクセス

「ベアメタル・プロビジョニング」ページにアクセスするには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ベアメタル・プロビジョニング」をクリックします。「ベアメタル・プロビジョニング」ホームページに、次のタブが表示されます。

図36-1 「ベアメタル・プロビジョニング」ホームページ

「デプロイ」タブでは、ベアメタル・ボックス上のLinuxオペレーティング・システムまたはOracle VM Serverをプロビジョニングできます。このページの「サーバー・イメージ」セクションには、プロビジョニングされたサーバーがすべて表示されます。

「インフラストラクチャ」では、ベアメタル・マシンのプロビジョニングに必要なインフラストラクチャを設定できます。ステージング・サーバー、ブート・サーバー、DHCPサーバーおよびRPMリポジトリの詳細は、第36.2.2項を参照してください。これらの各サーバーの設定および構成方法の詳細は、第36.4項を参照してください。

「保存済計画」タブでは、将来実行する場合に備えて、必須属性値をすべて含むテンプレートとして保存されているデプロイメント・プロシージャをすべて表示できます。ただし、これらの計画はこのタブからのみ表示可能です。これらの保存済計画を実行するには、第36.9項を参照してください。

36.2.2 ベアメタルのプロビジョニング環境

プロビジョニング・アプリケーションをサポートするために、データ・センター内のデプロイメント環境を一定の方法で設定する必要があります。プロビジョニング・アプリケーションを使用する前に、Cloud Controlおよびプロビジョニング・アプリケーションをホスティングするOracle Management Server (OMS)以外にも、次を設定および構成する必要があります。

36.2.2.1 ソフトウェア・ライブラリおよびそのエンティティ

ソフトウェア・ライブラリおよびエンティティの構成方法の詳細は、第2.2項を参照してください。

36.2.2.2 ブート・サーバー

アプリケーションの主要要件の1つには、ハードウェア・サーバーが(ローカル・ブート・デバイスからではなく)ネットワークを介して起動するための機能があります。ブート・サーバーは、指定されたハードウェア・サーバーがネットワークを介して起動することを求めるリクエストを処理できるよう設定する必要があります。ブート・サーバーは、Cloud Controlターゲットであるとともに、ネットワークを介してハードウェア・サーバーからのBOOTPおよびTFTP (Trivial File Transfer Protocol)リクエストを受信できる必要があります。DHCP/TFTPの組合せを使用したブート・サーバーの設定の詳細は、第36.4.2項を参照してください。また、第36.4.5項も参照してください。また、ブート・サーバーの設定を行う前に、DHCP、PXEおよびRedhat Kickstartテクノロジについても確認することをお薦めします。PXEの詳細は、付録Dを参照してください。

36.2.2.3 ステージング・サーバー

ハードウェア・サーバーのイメージのプロビジョニング中、必要なバイナリおよびファイルがステージング・サーバーに最初に転送されます。これはステージング・フェーズと呼ばれ、ネットワークを介してインストールされるイメージの準備を行い、インストール可能または実行可能なソフトウェア要素を、ネットワークを介してプロビジョニングされるターゲットのハードウェア・サーバーに公開します。

プロビジョニング・アプリケーションには、ステージングに関連するすべてのアクティビティを実行できるステージング・サーバーが少なくとも1つ必要です。ステージング・サーバーもCloud Controlターゲットである必要があります。ステージング・サーバーの設定の詳細は、第36.4.1項を参照してください。また、第36.4.4項も参照してください。

36.2.2.4 参照ホスト

参照ホスト(ゴールド・マシンと呼ばれる)は、プロビジョニング・アプリケーションがLinuxオペレーティング・システムの構成要素を作成するために参照として使用するマシンです。プロビジョニング・アプリケーションは、参照ホストにインストールされているRPMリストを(バージョンと一緒に)取得し、それらのRPMをRPMリポジトリからフェッチして、参照ホストにインストールされているオペレーティング・システムを表すLinux OSコンポーネントを作成します。参照ホストはCloud Controlターゲットであることが必要です。

36.2.2.5 RPMリポジトリ

プロビジョニング・アプリケーションは、オペレーティング・システムとしてRPMリポジトリからRPMを取得します。プロビジョニング・アプリケーションで使用するために少なくとも1つのリポジトリを設定する必要があります。ネットワークの観点からは、RPMリポジトリはターゲット・マシンにできるだけ近づけることをお薦めします。これで、RPMをRPMリポジトリからハードウェア・サーバーに転送する時間を短縮することにより、インストール時間を大幅に短縮できます。物理的に異なる場所に複数のハードウェア・サーバー・グループが点在する場合、これらの場所ごとに1つのRPMリポジトリを配置することをお薦めします。RPMリポジトリの設定の詳細は、第36.4.3項を参照してください。また、第36.4.7項も参照してください。

36.2.3 ベアメタルのプロビジョニング

プロビジョニング・プロセスは次の2つの主要タスクで構成されています。

1. プロビジョニング環境の設定(第36.4項):

- ブート/DHCPサーバーおよびステージング・サーバーの設定と構成、RPMリポジトリおよびソフトウェア・ライブラリの設定

- ベアメタル・プロビジョニング・エンティティの作成(オプション)

2. ベアメタル・プロビジョニング・アプリケーションを使用したLinuxのプロビジョニング(第36.6項):

- ベアメタル・プロビジョニング・ウィザードを起動し、MACアドレス、サブネットまたはCloud Controlホストの再イメージ化を使用してベアメタル・マシンを構成します。

- ネットワーク上のベアメタル・マシンを起動し、PXEベースのOSブートおよびインストール・プロセスを開始します。PXEブートおよびKickStartの詳細は、付録Dを参照してください。

36.3 Linuxのサポート対象リリース

Cloud Controlでは、次のオペレーティング・システムの32ビット版および64ビット版のベアメタル・プロビジョニングがサポートされます。

- Oracle Linux 4.x、Oracle Linux 5.x、Oracle Linux 6.x

- RedHat Enterprise Linux (RHEL) 4.x、RedHat Enterprise Linux (RHEL) 5.x、RedHat Enterprise Linux (RHEL) 6.x

- SuSE Linux (SLES) 10

- Oracle VM Server (OVS) 3.0.x、Oracle VM Server 3.1.x、Oracle VM Server 3.2.x

36.4 ベアメタル・プロビジョニングのインフラストラクチャの設定

ここでは、ベアメタル・マシンをプロビジョニングするために必要なインフラストラクチャの設定方法について説明します。特に、次の項目について説明します。

- ステージング・サーバーの設定

- ブート・サーバーとDHCPサーバーの設定

- RPMリポジトリの設定

- ステージング・サーバーの構成

- ブート・サーバーの構成

- DHCPサーバーの構成

- RPMリポジトリの構成

- ブート・サーバー、ステージング・サーバー、RPMリポジトリ、参照ホストのチェックリスト

- ソフトウェア・ライブラリ・コンポーネントの構成

36.4.1 ステージング・サーバーの設定

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

- ステージング・サーバーを設定するための前提条件

- ステージング・サーバーの設定および管理エージェント・ファイルへのアクセス

36.4.1.1 ステージング・サーバーを設定するための前提条件

次の前提条件が満たされていることを確認してから、ステージング・サーバーを設定してください。

- エージェントRPMをステージングする最上位ディレクトリ(ステージング・ディレクトリ)の作成に使用するユーザーまたはロールには、rootへのSudoアクセス権が必要です。ステージング・ストレージでのSudoアクセス権を確実にするには、Cloud Controlコンソールにログインして、Sudo権限を設定します。

注意:
ステージング・サーバーがホスティングするデータの重要性および機密性のため、ステージング・サーバーに対するアクセスは最小限に制限することをお薦めします。スーパー管理者は、ステージング・サーバー上で1つのアカウントを作成し、このアカウントをCloud Control内のすべてのプロビジョニング・ユーザーが使用する優先資格証明として設定することにより、この制限を徹底できます。また、この優先資格証明は、(ORACLE_HOME所有者のグループに属する)有効なORACLE_HOME資格証明であることも必要です。

- 最上位ディレクトリを作成するユーザーは、ディレクトリへの書込み権限が必要です。ステージング・サーバーでの書込み権限を確実にするには、Cloud Controlコンソールにログインして、ステージング・サーバー・ホストに特権優先資格証明を設定します。

- ステージング・ディレクトリの最低領域要件は、100 MBです。

36.4.1.2 ステージング・サーバーの設定および管理エージェント・ファイルへのアクセス

ステージング・サーバーを設定し管理エージェントのRPMファイルにアクセスするには、次の手順に従います。

1. NFSステージング・サーバーまたはHTTPサーバーを設定します。
NFSステージング・サーバーを設定するには、「NFSステージング・サーバーの設定」を参照してください。

HTTPサーバーを設定するには、「HTTPステージング・サーバーの設定」を参照してください。

2. 管理エージェントで実行しているステージング・サーバーにログインして、最上位ディレクトリを作成し、すべての管理エージェント・インストール・ファイルを格納します。
この項では、変数STAGE_TOP_LEVEL_DIRECTORYがステージング・サーバーの最上位ディレクトリの参照に使用されます。

次に例を示します。

User: aime
Stage Server: upsgc.example.com
Stage Directory: /scratch/stage

この場合、aimeユーザーはrootへのSudoアクセス権を持ち、/scratch/stageディレクトリでの書込み権限を持っている必要があります。

3. 管理エージェント・ファイルを作成してステージングの場所にコピーするには、OMSで次のコマンドを実行します。

For using the NFS Stage Server:
STAGE_TOP_LEVEL_DIRECTORY=/scratch/stage

For using the HTTP based Stage Server:
#STAGE_TOP_LEVEL_DIRECTORY=/var/www/html/stage

emcli get_agentimage_rpm -destination="${STAGE_TOP_LEVEL_DIRECTORY:?}" -platform="Linux x86-64"

[root@upgps1t12 stage]# pwd
/scratch/stage
[root@upgps1t12 stage]# ls
1  10  21  6  9  oracle-agt-12.1.0.2.0-1.0.x86_64.rpm

注意:

1. NFSが使用されている場合、ステージング・プロセスにより自動的にエージェントRPMが検出されるため、RPMのURLを指定する必要はありません。

2. HTTPが使用されている場合、エージェントRPMを参照するためにURLが必要です。エージェントのURLはhttp://host.example.com/agent_dir/oracle-agt-12.1.0.4.0-1.0.x86_64.rpmです。HTTPステージング・サーバーの設定の詳細は、第36.4.1.2.2項を参照してください。

36.4.1.2.1 NFSステージング・サーバーの設定

インストール時には、ハードウェア・サーバーは、インストールに必要なすべてのファイルがローカル・ファイルとなるようステージング・ディレクトリをマウントします。この場合、ステージング・サーバーはNFSサーバーとして、ハードウェア・サーバーはそのクライアントとして機能します。ステージング・サーバーがNFSサーバーの場合、NFSがエクスポートするすべてのファイルは、そのクライアントで使用できる必要があり、これに対応するために、NASストレージ上のファイルに対してNASの構成が必要な場合があります。

ステージング・サーバーで次の手順を実行してください。

1. 次のコマンドを実行して、NFSサービスをインストールします。

rpm --quiet -q nfs || yum -y install nfs

2. 次のコマンドを実行して、ステージング・サーバーの最上位ディレクトリ(STAGE_TOP_LEVEL_DIRECTORY)をエクスポートするようNFSを構成します。

STAGE_TOP_LEVEL_DIRECTORY=/scratch/stage
echo "${STAGE_TOP_LEVEL_DIRECTORY}*(ro,sync)" >>/etc/exports

3. これらの変更をNFSデーモンで反映するには、次のコマンドを実行します。

service nfs restart

4. 再起動時にNFSが起動し、稼働中であることを確認します。

chkconfig nfs on

5. 管理エージェントをインストールします。

関連項目:
『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照して、12.1.0.1.0以上のバージョンの管理エージェントをインストールします。

36.4.1.2.2 HTTPステージング・サーバーの設定

HTTPステージング・サーバーを設定するには、次の手順に従ってください。

1. 次のコマンドを実行して、ステージング・サーバーをインストールして起動します。

rpm --quiet -q httpd || yum -y install httpd
service httpd restart
chkconfig httpd on

2. 次のようにHTTPステージング・ディレクトリを作成します。

mkdir /var/www/html/stage

3. HTTPステージング・サーバーにアクセスするURLは次のとおりです。

http://host.example.com/stage

4. 管理エージェントをインストールします。

関連項目:
『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照して、12.1.0.1.0以上のバージョンの管理エージェントをインストールします。

/var/www/html/stageはステージング・ディレクトリで、http://host.example.com/stageはベースURLであることに注意してください。

36.4.2 ブート・サーバーとDHCPサーバーの設定

注意:
ブート・サーバー、ステージング・サーバーおよびRPMリポジトリ・サーバーでは2GBのRAMを用意してください。

必要なブート・サーバー、ステージング・サーバーおよびRPMリポジトリがすでに作成されている場合、優先資格証明を設定します。

次のステップを実行し、ブート・サーバーとしてのマシンを設定します。

1. DHCPおよびTFTPサーバーがまだインストールされていない場合、これらをインストールします。
これら2つのサーバーは同じマシンで実行されている場合と異なるマシンで実行されている場合があります。TFTPサーバーはDHCPサーバーと同じホスト・マシンで実行することをお薦めします。2つのサーバーが別のマシンでインストールおよび構成されている場合、TFTPサーバーがブート・サーバーと呼ばれます。

2. TFTPサーバーを構成します。

- TFTPサーバー用として構成されているディレクトリ(所定の例の/tftpboot/linux-install)内にpxelinuxブート・ローダー(pxelinux.0)が存在することを確認します。

3. DHCPサーバーを構成します。
dhcpd.conf (/etc/dhcpd.conf)ファイルを編集します。PXE設定用のdhcpd.confファイルの例は、次のとおりです。

allow booting;
allow bootp;

option domain-name  <domain_name>;
option domain-name-servers dns_servers;
option routers <default_router>;

subnet <subnet-number> netmask <netmask> {
[ parameters ]
[ declarations ]
}
# Group the PXE bootable hosts together

group {

# PXE-specific configuration directives...

next-server  <TFTP_server_IP_address>;

filename "linux-install/pxelinux.0";

host <hostname> {
hardware ethernet <MAC address>;
fixed-address <IP address>;
}
}

DHCP構成ファイル内のnext-serverオプションは、TFTPサーバーをホスティングしているマシンのホスト名またはIPアドレスを指定します。TFTPサーバーはDHCPサーバーと同じホスト・マシンで実行することをお薦めします。このため、このアドレスはローカル・マシンのホスト名またはIPアドレスにする必要があります。

filenameオプションは、TFTPサーバー上のブート・ローダーの場所を指定します。ファイルの場所は、メインのTFTPディレクトリに対する相対的な場所です。

標準DHCP構成ファイルがサポートされます。前述のサンプル・ファイル形式は、各ターゲット・ホストの1つのエントリ(行12-15)を示しています。構成ファイルを変更するたびに、DHCPサービスを再起動する必要があります。

4. tftpサービスを有効にします。/etc/xinetd.d/tftpファイルを編集し、無効化フラグをnoに変更します(デフォルトはnoです)。

5. 次のサービスを再起動します。

service dhcpd restart
service xinetd restart
service portmap restart

6. Oracle Management Agentをインストールします。DHCPサーバーとブート・サーバーがCloud Controlサーバーにインストールされる場合、このステップは必要ありません。

注意:
『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照して、12.1.0.1.0以上のバージョンの管理エージェントをブート・サーバーにインストールします。

36.4.3 RPMリポジトリの設定

注意:
2GBのRAMを使用することをお薦めします。

36.4.3.1 RHEL 4 RPMリポジトリの設定

RPMリポジトリは、新しいプロビジョニングしたベアメタル・ボックスにインストールする必要があるLinuxおよびアプリケーション・パッケージのソースとして使用されます。たとえば、Linux 32ビットRPMをすべて組み込むためにRPMリポジトリを作成し、Linux x86-64ビットRPMを組み込むために別のリポジトリを作成できます。これにより、2つの個別Linuxイメージをそれぞれ1つのリポジトリに基づいて作成できます。

使用するRHEL RPMリポジトリには、次のRed Hatインストール・ツリー構造が必要です。

RPMリポジトリには複数の作成方法があります。Red Hat Enterprise Linux CDを入手できる場合、次を実行します。

1. 最初のCDのすべてのコンテンツをRPM_REPOSなどのディレクトリにコピーします。

2. 他のCDのすべてのRPMを<RPM_REPOS>/Redhat/RPMSにコピーします。ディレクトリをRPMSディレクトリに変更します。

cd <RPM_REPOS>/Redhat/RPMS

3. 次のようにカスタムRPMをリポジトリに追加します。

1. ベアメタル・マシンでプロビジョニングする必要がある参照ホストにカスタムRPMがインストールされている場合、これらを次のリポジトリの場所にコピーするようにしてください。

<RPM_REPOS>/Redhat/RPMS

2. RPMリポジトリをホスティングするマシンにanaconda-runtime RPMをインストールします。これを行うには、他の依存パッケージのインストールが必要な場合があります。

3. 次のコマンドを実行します。

cd /usr/lib/anaconda-runtime
./genhdlist --productpath=RedHat --withnumbers --hdlist <RPM_REPOS>/RedHat/base/hdlist <RPM_REPOS>

4. yum-archを実行します。
これにより、headersディレクトリが作成されます。このディレクトリにはheader.infoファイルが含まれることを確認してください。

yumがインストールされていない場合は、これをLinuxベンダーのWebサイトからダウンロードします。

5. /var/www/htmlに<RPM_REPOS>ディレクトリへのシンボリック・リンクを作成します。
Apacheサーバーが実行されている場合、これで、HTTPを介してリポジトリを使用できるようになります。

注意:
Enterprise Manager Cloud Controlに用意されているApacheサーバーが使用されている場合、Apache構成(httpd.conf)ファイル内の「Options Indexes」ディレクティブを使用してApacheディレクトリ索引ページを有効にします。

36.4.3.2 Oracle Linux 4 RPMリポジトリの設定

Oracle Linux RPMリポジトリには、次に示すインストール・ツリー構造が必要です。

次のようにOracle Linuxインストール・メディアを使用することにより、Oracle Linuxリポジトリを設定できます。

1. Oracle Linuxをhttp://edelivery.oracle.com/linux">>http://edelivery.oracle.com/linuxからダウンロードします。

2. 最初のCDのすべてのコンテンツをRPM_REPOSなどのディレクトリにコピーします。

3. 他のCDのすべてのRPMを<RPM_REPOS>/Enterprise/RPMSにコピーします。ディレクトリをRPMSディレクトリに変更します。

cd <RPM_REPOS>/Enterprise /RPMS

4. カスタムRPMをリポジトリに追加します。

1. ベアメタル・マシンでプロビジョニングする必要がある参照ホストにカスタムRPMがインストールされている場合、これらを次のリポジトリの場所にコピーするようにしてください。

<RPM_REPOS>/Enterprise/RPMS

2. RPMリポジトリをホスティングするマシンにanaconda-runtime RPMをインストールします。これを行うには、他の依存パッケージのインストールが必要な場合があります。

3. 次のコマンドを実行します。

cd /usr/lib/anaconda-runtime
./genhdlist --productpath=Enterprise --withnumbers --hdlist <RPM_REPOS>/Enterprise/base/hdlist <RPM_REPOS>

5. yum-archを実行します。
これにより、headersディレクトリが作成されます。このディレクトリにはheader.infoファイルが含まれることを確認してください。

6. /var/www/htmlに<RPM_REPOS>ディレクトリへのシンボリック・リンクを作成します。

Apacheサーバーが実行されている場合、これで、HTTPを介してリポジトリを使用できるようになります。

36.4.3.3 RHEL 5/Oracle Linux 5 RPMリポジトリの設定

Oracle Linux RPMリポジトリには、次に示すインストール・ツリー構造が必要です。

次のようにOracle Linuxインストール・メディアを使用することにより、Oracle Linuxリポジトリを設定できます。

1. Oracle Linuxをhttp://edelivery.oracle.com/linux">>http://edelivery.oracle.com/linuxからダウンロードします。

2. 最初のCDのすべてのコンテンツをRoot Directoryなどのディレクトリにコピーします。

3. 他のCD内のCluster、ClusterStorage、ServerおよびVTディレクトリのすべてのコンテンツを各ディレクトリにコピーします。

4. 4つすべてのディレクトリに対してcreaterepoを実行します。次に例を示します。

createrepo <Root Directory>/cluster

5. 次のようにカスタムRPMをリポジトリに追加します。

1. ベアメタル・マシンでプロビジョニングする必要がある参照ホストにカスタムRPMがインストールされている場合、Cluster、VT、ClusterStorageおよびServerなどのRPMが含まれるディレクトリにこれらをコピーするようにしてください。

2. このディレクトリでcreaterepoコマンドを実行します。次に例を示します。

createrepo ClusterStorage

6. /var/www/htmlに<Root Directory>ディレクトリへのシンボリック・リンクを作成します。

Apacheサーバーが実行されている場合、これで、HTTPを介してリポジトリを使用できるようになります。

36.4.3.4 HTTPまたはFTPでのRPMリポジトリの公開

HTTPを使用してRPMリポジトリを公開するには、次の手順を実行します。

1. Apache Webサーバーがインストールされ、HTTPサービスが実行していることを確認します。

2. RPMリポジトリ・ディレクトリに対するシンボリック・リンクをドキュメント・ルートに作成します。たとえば、<RPM_REPOS>ディレクトリに対する/var/www/htmlです。

FTPを使用してRPMリポジトリを公開するには、FTPサーバーが実行していることを確認します。

36.4.4 ステージング・サーバーの構成

ハードウェア・サーバーのイメージのプロビジョニング中、必要なバイナリおよびファイルがステージング・サーバーに最初に転送されます。これはステージング・フェーズと呼ばれ、ネットワークを介してインストールされるイメージの準備を行い、インストール可能または実行可能なソフトウェア要素を、ネットワークを介してプロビジョニングされるターゲットのハードウェア・サーバーに公開します。

プロビジョニング・アプリケーションには、ステージングに関連するすべてのアクティビティを実行できるステージング・サーバーが少なくとも1つ必要です。ネットワークの観点からは、ステージング・サーバーはターゲット・マシンにできるだけ近づけることをお薦めします。これで、イメージ・データをステージング・サーバーからハードウェア・サーバーに転送する時間を短縮することにより、インストール時間を大幅に短縮できます。物理的に異なる場所に複数のハードウェア・サーバー・グループが点在する場合、これらの場所ごとに1つのステージング・サーバーを配置することをお薦めします。ステージング・サーバーもCloud Controlターゲットである必要があります。

次の手順に従います。

1. 管理者としてCloud Controlにログインします。

2. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ベアメタル・プロビジョニング」を選択します。

3. 「インフラストラクチャ」タブの「ステージング・サーバー」セクションで、「サーバーの追加」をクリックします。

4. 「ステージング・サーバーの追加」ダイアログで、「ステージング・サーバー」を選択し、「ステージング・ディレクトリ」(/scratch/stageなど)、および「ベースURL」(file://stgserver.example.com/scratch/stageなど)を指定します。「OK」をクリックします。

36.4.5 ブート・サーバーの構成

アプリケーションの主要要件の1つには、ハードウェア・サーバーが(ローカル・ブート・デバイスからではなく)ネットワークを介して起動するための機能があります。ブート・サーバーは、指定されたハードウェア・サーバーがネットワークを介して起動することを求めるリクエストを処理できるよう設定する必要があります。ブート・サーバーは、Cloud Controlターゲットであるとともに、ネットワークを介してハードウェア・サーバーからのBOOTPおよびTFTP (Trivial File Transfer Protocol)リクエストを受信できる必要があります。DHCP/TFTPの組合せを使用したブート・サーバーの設定の詳細は、「ブート・サーバーの設定」を参照してください。

次の手順に従います。

1. ブート・サーバーの設定を行う前に、DHCP、PXEおよびRedhat Kickstartテクノロジについて確認してください。

2. 管理者権限があることを確認します。

3. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ベアメタル・プロビジョニング」を選択します。

4. 「インフラストラクチャ」タブの「ブート・サーバー」セクションで、「追加」をクリックします。

5. 「ブート・サーバーの追加」ダイアログで、「ブート・サーバー」を選択し、「TFTPブート・ディレクトリ」(/tftpboot/linux-install/など)を指定します。「OK」をクリックします。

36.4.6 DHCPサーバーの構成

次の手順に従います。

1. 管理者権限があることを確認します。

2. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ベアメタル・プロビジョニング」を選択します。

3. 「インフラストラクチャ」タブの「DHCPサーバー」セクションで、「追加」をクリックします。

4. 「DHCPサーバーの追加」ダイアログで、「DHCPサーバー」を選択し、ターゲット・ホストをサポートするために変更されている「DHCP構成ファイル」(/etc/dhcpd.confなど)を指定します。「OK」をクリックします。

36.4.7 RPMリポジトリの構成

プロビジョニング・アプリケーションは、オペレーティング・システムとしてRPMリポジトリからRPMを取得します。プロビジョニング・アプリケーションで使用するために少なくとも1つのリポジトリを設定する必要があります。

次の手順に従います。

1. 管理者権限があることを確認します。

2. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ベアメタル・プロビジョニング」を選択します。

3. 「インフラストラクチャ」タブの「RPMリポジトリ」セクションで、「追加」をクリックします。

4. 「RPMリポジトリ・サーバーの追加」ダイアログで、「リポジトリ名」および「URL」を指定し、HTTPまたはローカル・サーバーでアクセス可能なRPMリポジトリには、http://example.com/OL5/などのHTTP形式のURLを指定します。NFSの場所には、file://example/OEL5/のURLを指定します。
「OK」をクリックします。

36.4.8 ブート・サーバー、ステージング・サーバー、RPMリポジトリ、参照ホストのチェックリスト

プロビジョニング前に、次の基準が満たされていることを確認してください。

表36-2 ブート・サーバー、ステージング・サーバー、RPMリポジトリ、参照ホストのチェックリスト

リソース名

チェックリスト

ブート・サーバー

DHCPサーバーが起動して実行されています。

/etc/dhcpd.confファイル内のnext_serverエントリがこのブート・サーバーを指し示しています。

TFTPが起動して実行されています。

ブート・サーバーが、プロビジョニングするターゲット・マシンが配置されているか配置される予定の同じサブネット内にあります。

管理エージェントがインストールされています。

ブート・サーバー・マシンがCloud Control内で管理ターゲットとして表示されています。

新規PXEブート可能ボックスがブート・サーバーを実際に検出し、(イメージがまだインストールされていなくても)この起動を開始します。

ステージング・サーバー

大規模な記憶域、大量かつ十分なメモリーがあります。

NASサーバーが記憶域として使用されている場合、このサーバーにはNFSのサポートが必要です。

管理エージェントがインストールされています。

ブート・サーバー・マシンがCloud Control内で管理ターゲットとして表示されています。

ターゲットにエージェントをインストールするために必要なエージェントRPMがステージングされています。

優先資格証明が設定されています。

プロビジョニングするボックス(または同じサブネット)からステージング・サーバーに到達可能です。

RPMリポジトリ

RPMリポジトリがターゲット・サーバーとできるだけ近い場所にあります。

インストール・ツリー構造が「RPMリポジトリの構成」の項の説明どおりです。

RPMリポジトリがHTTPを介して使用可能です。

正確なURLを指定し、HTTPを介したRPMリポジトリのアクセスをテストします。

参照ホスト

エージェントが、NFSがマウントされたディレクトリではなくローカル・ディスクにインストールされています。

優先資格証明が設定されています。

ソフトウェア・ライブラリ

ソフトウェア・ライブラリに使用される共有記憶域がNFSマウント・ポイントを介してすべてのOMSサーバーからアクセスできます。

36.4.9 ソフトウェア・ライブラリ・コンポーネントの構成

ソフトウェア・ライブラリを設定および構成するには、第2.2項を参照してください。

次のベアメタル・プロビジョニング・エンティティを作成して、ソフトウェア・ライブラリに格納できます。

- オペレーティング・システム・コンポーネントの作成

- ディスク・レイアウト・コンポーネントの作成

- Oracle Virtual Serverコンポーネントの作成

36.4.9.1 オペレーティング・システム・コンポーネントの作成

オペレーティング・システム・・コンポーネントを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ・ホーム」で、「アクション」メニューから「フォルダの作成」を選択します。

3. 「フォルダの作成」ポップアップで、フォルダの「名前」と「説明」を指定し、フォルダの場所を選択します。たとえば、フォルダBMP-OL56を作成し、Oracle Linux 5 Update 6のベアメタル・サーバーをプロビジョニングするために使用するコンポーネントを表します。「保存」をクリックします。

4. 「アクション」メニューで、「エンティティの作成」、「ベアメタル・プロビジョニング・コンポーネント」の順に選択します。

5. ベアメタル・プロビジョニング・コンポーネントダイアログ・ボックスで、「オペレーティング・システム・コンポーネント」を選択し、「続行」をクリックします。

6. 説明ページで、「名前」、「説明」、およびエンティティを説明する「その他の属性」を入力します。
注意: コンポーネント名は、属する親フォルダに対して一意である必要があります。一意の名前を入力したときでさえ、競合が報告される場合があります。これは、表示権限がないために表示できないが、フォルダ内に同じ名前のエンティティがあるために起こります。

追加をクリックし、readme、コラテラル、ライセンスなどの、エンティティをより適切に説明するファイルを添付します。ファイル・サイズが2 MB未満であることを確認してください。

「ノート」フィールドで、エンティティに対して行った変更や、追跡したい変更履歴など、エンティティに関連する情報を追加します。

7. 基本オペレーティング・システム・ページで、「タイムゾーン」を選択し、「ルート・パスワード」を指定します。
「オペレーティング・システム・ユーザー」リストで、「ユーザー名」、「パスワード」、「プライマリ・グループ」、追加のグループを指定し、オペレーティング・システムのユーザーを追加します。ユーザーに対するSudoアクセスの有効化を選択します。

「参照Enterprise Managerホスト・ターゲットから構成プロパティをフェッチします」セクションで、「プロパティのフェッチ」を選択して、ホスト・プロパティを適用します。参照ホストを選択し、フェッチする「構成」を選択します。

「次へ」をクリックします。

8. 拡張構成ページで、エージェントのプロパティ、ブート構成、その他の構成を表の説明に従って指定します。
「パッケージ選択の構成」セクションに、動作中のコンポーネントまたは前の画面で指定した参照ホストからのパッケージが表示されます。これらのパッケージは、そのままにすることも、パッケージから削除することもできます。

「次へ」をクリックします。

9. 確認ページで情報を確認し、「終了」をクリックします。
オペレーティング・システム・コンポーネントが、「準備完了」のステータスでソフトウェア・ライブラリに保存されます。

表36-3 エージェント設定

要素

説明

インストール・ユーザー

エージェントをインストールするユーザー名。

インストール・グループ

エージェントのインストール・グループ。

エージェント登録パスワード

Oracle Management Serverにエージェントを登録するために使用するパスワードを指定します。

RPM URL

エージェントRPMを格納する場所。

表36-4 追加OS構成

要素

説明

TTYが必要

sudoユーザーが個々の端末にログインする場合、このオプションを選択します。

SELinux

SELinuxを有効または無効にするよう選択できます。

マウント・ポイントの設定

/etc/fstabファイルのエントリを指定します。新規にプロビジョニングしたLinuxマシンにマウント・ポイントを指定できます。デフォルトでは、参照用のLinuxマシンからマウント・ポイントの設定が継承されます。

NIS設定

/etc/yp.confファイルのエントリを指定します。新規にプロビジョニングしたLinuxマシンのNIS設定を指定できます。デフォルトでは、参照用のLinuxマシンからNIS設定が継承されます。

NTP設定

/etc/ntp.confファイルのエントリを指定します。新規にプロビジョニングしたLinuxマシンのNTP設定を指定できます。デフォルトでは、参照用のLinuxマシンからNTP設定が継承されます。

カーネル・パラメータ設定

カーネル・パラメータのスクリプトを指定します。

initab設定

/etc/inittabファイルの設定を指定します。すべてのプロセスは、ブート・プロセスで初期化操作の一部として開始されます。初期化操作により、マシンの起動時または実行レベルの変更時に開始されるプロセスが決まります。

ファイアウォール設定

Linuxターゲットのファイアウォール設定を指定します。ファイアウォール設定はデフォルトでは無効で、構成可能です。管理エージェントで使用されるポートが管理サービスとの通信に対してオープンであることを確認してください。デフォルトでは、他のポートを使用するよう構成されていない場合、管理エージェントはポート3872または1830-1849の範囲のポート番号を使用します。

表36-5 ブート構成および構成スクリプト

要素

説明

電力制御インタフェース

/boot/grub/grub.confファイル内のカーネル(ACPI)のブート時パラメータの設定を指定します。

パラメータ仮想化されたカーネルを使用

パラメータ仮想化されたカーネルを使用する場合に選択します。

インストール後スクリプト

新規にプロビジョニングしたマシンで実行する必要のあるコマンドのセットを指定します。これらのコマンドは、kickstartファイルのポスト・セクションに追加されます。

初回ブート・スクリプト

最初に起動されたときに新規にプロビジョニングしたマシンで実行する必要のあるコマンドのセットを指定します。

36.4.9.2 ディスク・レイアウト・コンポーネントの作成

ディスク・レイアウト・コンポーネントを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ・ホーム」で、「アクション」メニューから「フォルダの作成」を選択します。

3. 「フォルダの作成」ポップアップで、フォルダの「名前」と「説明」を指定し、フォルダの場所を選択します。「保存」をクリックします。

4. 「アクション」メニューで、「エンティティの作成」、「ベアメタル・プロビジョニング・コンポーネント」の順に選択します。

5. ベアメタル・プロビジョニング・コンポーネントダイアログ・ボックスで、「ディスク・レイアウト・コンポーネント」を選択し、「続行」をクリックします。

6. 説明ページで、「名前」、「説明」、およびエンティティを説明する「その他の属性」を入力します。
注意: コンポーネント名は、属する親フォルダに対して一意である必要があります。一意の名前を入力したときでさえ、競合が報告される場合があります。これは、表示権限がないために表示できないが、フォルダ内に同じ名前のエンティティがあるために起こります。

追加をクリックし、readme、コラテラル、ライセンスなどの、エンティティをより適切に説明するファイルを添付します。ファイル・サイズが2 MB未満であることを確認してください。

「ノート」フィールドで、エンティティに対して行った変更や、追跡したい変更履歴など、エンティティに関連する情報を追加します。

7. 構成ページで、ハード・ディスク、RAID、パーティション、および論理構成を指定します。
ハードディスク・プロファイルを指定するには、「追加」をクリックします。「マウント・ポイント」、「RAIDレベル」、「パーティション」、「ファイルシステム・タイプ」を指定します。

パーティション構成を指定するには、「追加」をクリックします。「マウント・ポイント」、「デバイス名」、「ファイルシステム・タイプ」および「サイズ(MB)」を指定します。

RAID構成を指定するには、を指定するには、「追加」をクリックします。「デバイス名」および「容量」を指定します。

論理ボリューム・グループ構成を指定するには、「追加」をクリックします。「グループ名」、「パーティション」および「RAID」を指定します。

論理ボリューム構成を指定するには、「追加」をクリックします。「マウント・ポイント」、「論理ボリューム名」、「論理グループ名」、「ファイルシステム・タイプ」および「サイズ(MB)」を指定します。

「次へ」をクリックします。

8. 確認ページで情報を確認し、「終了」をクリックします。
ディスク・レイアウト・コンポーネントが、「準備完了」のステータスでソフトウェア・ライブラリに保存されます。

36.4.9.3 Oracle Virtual Serverコンポーネントの作成

オペレーティング・システム・・コンポーネントを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ・ホーム」で、「アクション」メニューから「フォルダの作成」を選択します。

3. 「フォルダの作成」ポップアップで、フォルダの「名前」と「説明」を指定し、フォルダの場所を選択します。

4. 「アクション」メニューで、「エンティティの作成」、「ベアメタル・プロビジョニング・コンポーネント」の順に選択します。

5. 「エンティティの作成: ベアメタル・プロビジョニング・コンポーネント」ダイアログ・ボックスで、Oracle Virtual Serverコンポーネントを選択し、「続行」をクリックします。

6. 説明ページで、「名前」、「説明」、およびエンティティを説明する「その他の属性」を入力します。
注意: コンポーネント名は、属する親フォルダに対して一意である必要があります。一意の名前を入力したときでさえ、競合が報告される場合があります。これは、表示権限がないために表示できないが、フォルダ内に同じ名前のエンティティがあるために起こります。

追加をクリックし、readme、コラテラル、ライセンスなどの、エンティティをより適切に説明するファイルを添付します。ファイル・サイズが2 MB未満であることを確認してください。

「ノート」フィールドで、エンティティに対して行った変更や、追跡したい変更履歴など、エンティティに関連する情報を追加します。

7. 基本オペレーティング・システム・ページで、「タイムゾーン」を選択し、「ルート・パスワード」および「OVMエージェント・パスワード」を指定します。
「オペレーティング・システム・ユーザー」リストで、「ユーザー名」、「パスワード」、「プライマリ・グループ」、追加のグループを指定し、オペレーティング・システムのユーザーを追加します。ユーザーに対するSudoアクセスの有効化を選択します。

「次へ」をクリックします。

8. 「拡張構成」ページで、次の表で説明するように、Dom0構成、ブート構成および追加のOSの詳細を指定します。
「次へ」をクリックします。

9. 確認ページで情報を確認し、「終了」をクリックします。
Oracle Virtual Serverコンポーネントは、「準備完了」のステータスでソフトウェア・ライブラリに保存されます。

表36-6 追加のOSの詳細

要素

説明

マウント・ポイントの設定

/etc/fstabファイルのエントリを指定します。新規にプロビジョニングしたLinuxマシンにマウント・ポイントを指定できます。デフォルトでは、参照用のLinuxマシンからマウント・ポイントの設定が継承されます。

NIS設定

/etc/yp.confファイルのエントリを指定します。新規にプロビジョニングしたLinuxマシンのNIS設定を指定できます。デフォルトでは、参照用のLinuxマシンからNIS設定が継承されます。

NTP設定

/etc/ntp.confファイルのエントリを指定します。新規にプロビジョニングしたLinuxマシンのNTP設定を指定できます。デフォルトでは、参照用のLinuxマシンからNTP設定が継承されます。

カーネル・パラメータ設定

カーネル・パラメータのスクリプトを指定します。

initab設定

/etc/inittabファイルの設定を指定します。すべてのプロセスは、ブート・プロセスで初期化操作の一部として開始されます。初期化操作により、マシンの起動時または実行レベルの変更時に開始されるプロセスが決まります。

ファイアウォール設定

Linuxターゲットのファイアウォール設定を指定します。ファイアウォール設定はデフォルトでは無効で、構成可能です。管理エージェントで使用されるポートが管理サービスとの通信に対してオープンであることを確認してください。デフォルトでは、他のポートを使用するよう構成されていない場合、管理エージェントはポート3872または1830-1849の範囲のポート番号を使用します。

表36-7 ブート構成および構成スクリプト

要素

説明

インストール後スクリプト

新規にプロビジョニングしたマシンで実行する必要のあるコマンドのセットを指定します。これらのコマンドは、kickstartファイルのポスト・セクションに追加されます。

初回ブート・スクリプト

最初に起動されたときに新規にプロビジョニングしたマシンで実行する必要のあるコマンドのセットを指定します。

36.5 ベアメタル・サーバーおよびOracle VM Serverのプロビジョニングの前提条件

- 「Oracleソフトウェア・ライブラリの設定」で説明されている前提条件を満たしていることを確認します。

- 第36.4項に従って、ベアメタル・プロビジョニング・インフラストラクチャを設定したことを確認します。

- Cloud Controlの管理者権限があることを確認します。

36.6 ベアメタル・サーバーのプロビジョニング

次の各項では、ベアメタル・ボックスでのLinuxのプロビジョニング方法について説明します。

注意:
管理エージェントRPMキットのダウンロード方法の詳細は、次のURLを参照してください。
http://www.oracle.com/technology/software/products/oem/htdocs/provisioning_agent.html

管理エージェントRPMキットのインストール方法は、ダウンロードする管理エージェントRPMキットに含まれているREADMEファイルを参照してください。

次の手順に従います。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ベアメタル・プロビジョニング」を選択します。

2. サーバー・イメージセクションで、「プロビジョニング」メニューから「オペレーティング・システム」を選択します。

3. 一般/ターゲットの選択ページの「一般」セクションで、「デプロイメント名」を指定します。プロビジョニングし説明を入力する「オペレーティング・システム」を選択します。システムに関連付ける「パッチ適用グループ」と「監視テンプレート」を選択します。
「ターゲット選択」セクションで「プロビジョニング・カテゴリ」に次のいずれかを選択します。

- 「MACアドレス」(MACアドレスを指定してベアメタル・システムをプロビジョニングする場合)。「追加」をクリックして、MACアドレスのリストを指定します。「MACの追加」ダイアログ・ボックスでMACアドレスを指定します。「OK」をクリックします。
オプションで、「ファイルから追加」をクリックして、ファイルからMACアドレスを追加します。「ファイルから追加」ダイアログ・ボックスで、「参照」をクリックし、格納した場所からファイルを選択します。

- 「サブネット」(ベアメタル・プロビジョニングのサブネットを指定する場合)。「プロビジョニングするサブネット」セクションで、「サブネットIP」、「ネットマスク」、「ネットワーク・インタフェース数」および「ブート可能ネットワーク・インタフェース」を指定します。

- 「EMホスト・ターゲットの再イメージ化」(既存のCloud Controlホスト・ターゲットを再プロビジョニングする場合)。プロビジョニングするEnterprise Managerホスト・セクションで、「追加」をクリックし、ホスト・ターゲットを検索および選択します。「OK」をクリックします。「ブート可能ネットワーク・インタフェース」を選択します。

オプションで、「プランとして保存」をクリックして指定した構成詳細を保存できます。名前および説明を指定し、「OK」をクリックしてプランを保存します。保存されたプランを後で使用してベアメタル・ボックスをプロビジョニングできます。ウィザードの任意のページにプランとして保存するか、ウィザードを完全に構成して、ウィザードの最後のページにプランを保存できます。

「次へ」をクリックします。

4. デプロイ・ページの「インフラストラクチャ」セクションで、次を指定します。

1. 「ステージング・サーバー」を指定し、「記憶域」を選択します。「ステージング・サーバーの前提条件チェックを実行」を選択し、ステージング・サーバーが正しく構成されているかどうかを確認します。

2. 「ブート・サーバー」を指定し、「ブート・サーバーの前提条件チェックを実行」を選択し、ブート・サーバーが正しく構成されているかどうかを確認します。

3. 「DHCPサーバー」を指定し、「DHCPサーバーの前提条件チェックを実行」を選択し、DHCPサーバーが正しく構成されているかどうかを確認します。

4. 「ローカルRPMリポジトリ」を指定します。

「事前作成されたコンポーネントから構成プロパティをフェッチします」セクションで、ソフトウェア・ライブラリから、「オペレーティング・システム・コンポーネント」、「ディスク・レイアウト・コンポーネント」および「プロビジョニング・ディレクティブ」を選択します。さもなければ、オペレーティング・システム、ディスク・レイアウトおよびその他のプロパティをそれぞれのページで指定できます。

「次へ」をクリックします。

5. 基本OS詳細ページで、「タイムゾーン」および「OSのルート・パスワード」を設定します。オペレーティング・システム・ユーザー・リストの追加セクションで、「追加」をクリックします。「ユーザー名」、「パスワード」、「プライマリ・グループ」および追加グループを指定して、オペレーティング・システム・ユーザーを追加します。sudoアクセスを有効または無効にします。「OK」をクリックします。
ベア・メタル・サーバーのプロビジョニング元の参照ホストがある場合、「参照Enterprise Managerホスト・ターゲットからプロパティをフェッチします」セクションで、「プロパティのフェッチ」を選択し、参照ホスト・プロパティを選択します。参照ホストを選択し、フェッチするプロパティを選択します。参照ホスト資格証明を指定します。指定する資格証明にルート・アクセス権があるか、ターゲットにsudo権限が付与されている必要があります。

優先資格証明か名前付き資格証明を使用する、または独自の資格証明を入力するよう選択できます。独自の資格証明を入力するよう選択した場合、ユーザー名およびパスワードを指定して、「実行権限」を選択します。将来のデプロイメントでこれらの資格証明を使用するために、「資格証明の保存」を選択します。

「次へ」をクリックします。

6. 「追加のOSの詳細」ページで、表36-8、表36-9および表36-10の説明にあるようにエージェント設定、構成スクリプト、パケージ選択、追加のオペレーティング・システム構成およびブート構成を指定します。
「パッケージ選択の構成」セクションに、動作中のコンポーネントまたは前の画面で指定した参照ホストからのパッケージが表示されます。プロビジョニング操作用としてこれらのパッケージを保持または削除できます。

ステップ4でOSコンポーネントを選択した場合、これらの設定がここに表示されます。これらの値を編集または保持できます。

「次へ」をクリックします。

7. ディスク・レイアウト・ページで、ハードディスク・プロファイル、パーティション構成、RAID構成、論理ボリューム・グループ構成および論理ボリューム構成を指定します。
ハードディスク・プロファイルを指定するには、「追加」をクリックします。「デバイス名」および「容量」を指定します。

パーティション構成を指定するには、「追加」をクリックします。「マウント・ポイント」、「デバイス名」、「ファイルシステム・タイプ」および「サイズ(MB)」を指定します。

RAID構成を指定するには、「追加」をクリックします。「マウント・ポイント」、「RAIDレベル」、「パーティション」、「ファイルシステム・タイプ」を指定します。RAIDを構成するには、ハードディスクに少なくとも2つのパーティションがあることを確認してください。

論理ボリューム・グループ構成を指定するには、「追加」をクリックします。「グループ名」、「パーティション」および「RAID」を指定します。

論理ボリューム構成を指定するには、「追加」をクリックします。「マウント・ポイント」、「論理ボリューム名」、「論理グループ名」、「ファイルシステム・タイプ」および「サイズ(MB)」を指定します。

ステップ4でディスク・レイアウト・コンポーネントを選択した場合、これらの設定がここに表示されます。これらの値を編集、削除または保持できます。

「次へ」をクリックします。

8. ネットワーク・ページに、ターゲット選択で指定したMACアドレスまたはサブネットのネットワーク・プロパティが表示されます。
「追加」をクリックして、ネットワーク・インタフェースを構成します。「入力ネットワーク・インタフェース・プロパティ」ダイアログ・ボックスで、「インタフェース名」を指定します。「構成タイプ」を次のように選択します。

- IPアドレスを指定する場合、「静的」を選択します。

- DHCPサーバーがネットワーク・アドレスの割当てを行う場合、「DHCP」を選択します。

- ネットワーク・プロファイルからネットワーク・アドレスを割り当てる場合、「ネットワーク・プロファイル」を選択します。

「インタフェース・タイプ」に、結合マスター、スレーブまたは「非結合」を選択します。

「次へ」をクリックします。

9. スケジュール/資格証明ページで、ジョブのスケジュールを即時または後日のいずれかで指定します。ステージング・サーバーおよびブート・サーバーの資格証明を指定します。優先資格証明か名前付き資格証明を使用する、または独自の資格証明を入力するよう選択できます。独自の資格証明を入力するよう選択した場合、ユーザー名およびパスワードを指定して、「実行権限」を選択します。将来のデプロイメントでこれらの資格証明を使用するために、「資格証明の保存」を選択します。
「次へ」をクリックします。

10. 確認ページで、選択した詳細が正しく表示されることを確認し、デプロイメントのジョブを発行します。詳細を変更する場合は、変更を加えるページに到達するまで、「戻る」をクリックします。「プランとして保存」をクリックして指定した構成詳細を保存します。名前および説明を指定し、「OK」をクリックしてプランを保存します。保存されたプランを後で使用してベアメタル・ボックスをプロビジョニングできます。詳細は、36.9項を参照してください。
「発行」をクリックします。

11. 「デプロイメント・プロシージャ」が、ベアメタル・プロビジョニング・ページに表示されます(「ステータス」が「実行中」)。ステータス・メッセージをクリックします。

12. プロシージャ・アクティビティ・ページにジョブ・ステップが表示されます。「ステータス」が「成功」であることを確認します。ステータスが「失敗」の場合はこれを修正し、ジョブを再発行します。

13. ベアメタル・システムがプロビジョニングされた後で、すべてのターゲット・ページに表示されることを確認します。

表36-8 エージェント設定

要素

説明

インストール・ユーザー

エージェントをインストールするユーザー名。

インストール・グループ

エージェントのインストール・グループ。

エージェント登録パスワード

Oracle Management Serverにエージェントを登録するために使用するパスワードを指定します。

エージェントRPM URL

エージェントRPMの場所。

表36-9 追加OS構成

要素

説明

TTYが必要

sudoユーザーが個々の端末にログインする場合、このオプションを選択します。

SELinux

SELinuxを有効または無効にするよう選択できます。

マウント・ポイントの設定

/etc/fstabファイルのエントリを指定します。新規にプロビジョニングしたLinuxマシンにマウント・ポイントを指定できます。デフォルトでは、参照用のLinuxマシンからマウント・ポイントの設定が継承されます。

NIS設定

/etc/yp.confファイルのエントリを指定します。新規にプロビジョニングしたLinuxマシンのNIS設定を指定できます。デフォルトでは、参照用のLinuxマシンからNIS設定が継承されます。

NTP設定

/etc/ntp.confファイルのエントリを指定します。新規にプロビジョニングしたLinuxマシンのNTP設定を指定できます。デフォルトでは、参照用のLinuxマシンからNTP設定が継承されます。

カーネル・パラメータ設定

カーネル・パラメータのスクリプトを指定します。

initab設定

/etc/inittabファイルの設定を指定します。すべてのプロセスは、ブート・プロセスで初期化操作の一部として開始されます。初期化操作により、マシンの起動時または実行レベルの変更時に開始されるプロセスが決まります。

ファイアウォール設定

Linuxターゲットのファイアウォール設定を指定します。ファイアウォール設定はデフォルトでは無効で、構成可能です。管理エージェントで使用されるポートが管理サービスとの通信に対してオープンであることを確認してください。デフォルトでは、他のポートを使用するよう構成されていない場合、管理エージェントはポート3872または1830-1849の範囲のポート番号を使用します。

表36-10 ブート構成および構成スクリプト

要素

説明

電力制御インタフェース

/boot/grub/grub.confファイル内のカーネル(ACPI)のブート時パラメータの設定を指定します。

パラメータ仮想化されたカーネルを使用

パラメータ仮想化されたカーネルを使用する場合に選択します。

インストール後スクリプト

新規にプロビジョニングしたマシンで実行する必要のあるコマンドのセットを指定します。これらのコマンドは、kickstartファイルのポスト・セクションに追加されます。

初回ブート・スクリプト

最初に起動されたときに新規にプロビジョニングしたマシンで実行する必要のあるコマンドのセットを指定します。

注意:
ベアメタル・システム上にLinuxをプロビジョニングすると、即時利用可能なデプロイメント・プロシージャを使用して、データベースやその他のOracle製品をそのサーバーにプロビジョニングできます。

36.7 Oracle VM Serverのプロビジョニング

ベアメタル・ボックス上のOracle VM Serverをプロビジョニングするには、次の手順を実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ベアメタル・プロビジョニング」を選択します。

2. 「サーバー・イメージ」セクションで、「プロビジョニング」メニューから「Oracle VM Server」を選択します。

3. 一般/ターゲットの選択ページの「一般」セクションで、一意の「デプロイメント名」を指定します。
「ターゲット選択」セクションで、次の「プロビジョニング・カテゴリ」のいずれかを選択します。

- 「MACアドレス」(MACアドレスを指定してベアメタル・システムをプロビジョニングする場合)。「追加」をクリックして、MACアドレスのリストを指定します。または、ファイルからアドレスを追加するには、「ファイルから追加」をクリックします。「ファイルから追加」ダイアログ・ボックスで、アドレスを含むファイルを選択して、「OK」をクリックします。

- 「サブネット」(ベアメタル・プロビジョニングのサブネットを指定する場合)。「プロビジョニングするサブネット」セクションで、「サブネットIP」、「ネットマスク」、「ネットワーク・インタフェース数」および「ブート可能ネットワーク・インタフェース」を指定します。

Oracle VMの登録セクションでは、クラウド内に登録されているOVMマネージャを選択して、プロビジョニングしているOracle VM Serverを管理できます。これを実行するには、検索アイコンをクリックします。「ターゲットの選択」ダイアログ・ボックスで、ターゲットのVMマシンを選択して、「選択」をクリックします。

「次へ」をクリックします。

4. 「デプロイ」ページの「インフラストラクチャ」セクションで、次を指定します。

1. 「ステージング・サーバー」、およびネットワークを介してインストールするイメージを準備するためのステージング・サーバー上の場所を選択します。「ステージング・サーバーの前提条件チェックを実行」を選択し、ステージング・サーバーが正しく構成されているかどうかを確認します。

2. 「ブート・サーバー」を選択してから、「ブート・サーバーの前提条件チェックを実行」を選択し、ブート・サーバーが正しく構成されているかどうかを確認します。

3. 「DHCPサーバー」を選択してから、「DHCPサーバーの前提条件チェックを実行」を選択し、DHCPサーバーが正しく構成されているかどうかを確認します。

4. 提供されているリストから「ローカルRPMリポジトリ」を選択します。

「事前作成されたコンポーネントから構成プロパティをフェッチします」セクションで、ソフトウェア・ライブラリ・ホームページから、既存の「オペレーティング・システム・コンポーネント」、「ディスク・レイアウト・コンポーネント」および「プロビジョニング・ディレクティブ」を選択します。これを実行すると、選択したエンティティのプロパティ値がソフトウェア・ライブラリからフェッチされてから、移入されます。また、ウィザードで残りのページの更新をスキップして、スケジューリング・ページに直接移動できます。ただし、ソフトウェア・ライブラリに必要なエンティティが存在しない場合は、後続のページでオペレーティング・システム、ディスク・レイアウトおよびその他のプロパティを指定できます。

「次へ」をクリックします。

5. 「基本OSの詳細」ページで、「タイムゾーン」、「OSのルート・パスワード」およびOracle VMエージェントのパスワードを設定します。「オペレーティング・システム・ユーザー・リスト」セクションで、「追加」をクリックします。「ユーザー名」、「パスワード」、「プライマリ・グループ」および追加グループを指定して、オペレーティング・システム・ユーザーを追加します。sudoアクセスを有効または無効にします。「OK」をクリックします。
「次へ」をクリックします。

6. 「追加のOSの詳細」ページで、次の手順を実行します。
「Dom0構成」セクションでは、プロビジョニングされるターゲットのメモリーおよび処理能力の要件を指定できます。

「追加のOSの詳細」では、構成アイコンをクリックして、その他の特定の構成に関する詳細(「マウント・ポイントの設定」、「NIS設定」、「NTP設定」、「カーネル・パラメータ設定」、「Inittab設定」、「ファイアウォール設定」など)を追加できます。

「ブート構成」セクションで、最初のブートをクリックして、インストール後、最初のブート時にシステムで実行する必要があるコマンド/スクリプトを追加します。「インストール後」をクリックして、インストールの完了時にシステムで実行するコマンドを指定します。

「次へ」をクリックします。

7. 「ディスク・レイアウト」ページで、「ハードディスク・プロファイル」、「RAID構成」および「論理構成」を指定します。
ハードディスク・プロファイルを指定するには、「追加」をクリックします。「デバイス名」および「容量」を指定します。

パーティション構成を指定するには、「追加」をクリックします。「マウント・ポイント」、「デバイス名」、「ファイルシステム・タイプ」および「サイズ(MB)」を指定します。

RAID構成を指定するには、「追加」をクリックします。「マウント・ポイント」、「RAIDレベル」、「パーティション」、「ファイルシステム・タイプ」を指定します。RAIDを構成するには、ハードディスクに少なくとも2つのパーティションがあることを確認してください。

論理ボリューム・グループ構成を指定するには、「追加」をクリックします。「グループ名」、「パーティション」および「RAID」を指定します。

論理ボリューム構成を指定するには、「追加」をクリックします。「マウント・ポイント」、「論理ボリューム名」、「論理グループ名」、「ファイルシステム・タイプ」および「サイズ(MB)」を指定します。

ステップ4でディスク・レイアウト・コンポーネントを選択した場合、これらの設定がここに表示されます。これらの値を編集、削除または保持できます。

「次へ」をクリックします。

8. ネットワーク・ページに、ターゲット選択で指定したMACアドレスまたはサブネットのネットワーク・プロパティが表示されます。
「追加」をクリックして、ネットワーク・インタフェースを構成します。「ネットワーク・インタフェースの追加」ダイアログ・ボックスで、「インタフェース名」を指定します。「構成タイプ」を次のように選択します。

- IPアドレスを指定する場合、「静的」を選択します。

- DHCPサーバーがネットワーク・アドレスの割当てを行う場合、「DHCP」を選択します。

- ネットワーク・プロファイルからネットワーク・アドレスを割り当てる場合、「ネットワーク・プロファイル」を選択します。

「インタフェース・タイプ」に、結合マスター、スレーブまたは「非結合」を選択します。

「次へ」をクリックします。

9. スケジュール/資格証明ページで、ジョブのスケジュールを即時または後日のいずれかで指定します。ステージング・サーバーおよびブート・サーバーの資格証明を指定します。優先資格証明か名前付き資格証明を使用する、または独自の資格証明を入力するよう選択できます。独自の資格証明を入力するよう選択した場合、ユーザー名およびパスワードを指定して、「実行権限」を選択します。将来のデプロイメントでこれらの資格証明を使用するために、「資格証明の保存」を選択します。
「次へ」をクリックします。

10. 確認ページで、選択した詳細が正しく表示されることを確認し、デプロイメントのジョブを発行します。詳細を変更する場合は、変更を加えるページに到達するまで、「戻る」をクリックします。
「発行」をクリックします。

11. 「デプロイメント・プロシージャ」が、ベアメタル・プロビジョニング・ページに表示されます(「ステータス」が「実行中」)。確認メッセージをクリックします。

12. プロシージャ・アクティビティ・ページにジョブ・ステップが表示されます。「ステータス」が「成功」であることを確認します。ステータスが「失敗」の場合はこれを修正し、ジョブを再発行します。

13. ベアメタル・システムがプロビジョニングされた後で、すべてのターゲット・ページに表示されることを確認します。

表36-11 追加OS構成

要素

説明

マウント・ポイントの設定

/etc/fstabファイルのエントリを指定します。新規にプロビジョニングしたLinuxマシンにマウント・ポイントを指定できます。デフォルトでは、参照用のLinuxマシンからマウント・ポイントの設定が継承されます。

NIS設定

/etc/yp.confファイルのエントリを指定します。新規にプロビジョニングしたLinuxマシンのNIS設定を指定できます。デフォルトでは、参照用のLinuxマシンからNIS設定が継承されます。

NTP設定

/etc/ntp.confファイルのエントリを指定します。新規にプロビジョニングしたLinuxマシンのNTP設定を指定できます。デフォルトでは、参照用のLinuxマシンからNTP設定が継承されます。

カーネル・パラメータ設定

カーネル・パラメータのスクリプトを指定します。

initab設定

/etc/inittabファイルの設定を指定します。すべてのプロセスは、ブート・プロセスで初期化操作の一部として開始されます。初期化操作により、マシンの起動時または実行レベルの変更時に開始されるプロセスが決まります。

ファイアウォール設定

Linuxターゲットのファイアウォール設定を指定します。ファイアウォール設定はデフォルトでは無効で、構成可能です。管理エージェントで使用されるポートが管理サービスとの通信に対してオープンであることを確認してください。デフォルトでは、他のポートを使用するよう構成されていない場合、管理エージェントはポート3872または1830-1849の範囲のポート番号を使用します。

表36-12 ブート構成および構成スクリプト

要素

説明

インストール後スクリプト

新規にプロビジョニングしたマシンで実行する必要のあるコマンドのセットを指定します。これらのコマンドは、kickstartファイルのポスト・セクションに追加されます。

初回ブート・スクリプト

最初に起動されたときに新規にプロビジョニングしたマシンで実行する必要のあるコマンドのセットを指定します。

36.8 保存済計画の表示

保存済計画を表示するには、次の手順を実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ベアメタル・プロビジョニング」を選択します。

2. 「ベアメタル・プロビジョニング」ページで、「保存済計画」をクリックします。

注意:
保存済計画を編集するには、第36.9項を参照してください。

36.9 ベアメタル・サーバー上のLinuxオペレーティング・システムのプロビジョニングにおける保存済計画の使用

保存済計画を編集するには、次の手順を実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ベアメタル・プロビジョニング」を選択します。

2. 「サーバー・イメージ」セクションで、「プロビジョニング」メニューから「保存済計画を使用」を選択します。

3. 「保存済計画」ダイアログ・ボックスで、テンプレートを選択してプロビジョニング・ウィザードに保存済の値を事前移入し、「続行」をクリックします。

4. 一般/ターゲットの選択ページの「デプロイメント名」、「プロビジョニング・カテゴリ」情報を更新します。

5. 36.6項の手順4から10までを実行します。

6. スケジュール/資格証明ページで、ジョブのスケジュールを即時または後日のいずれかで指定します。また、ステージング・サーバーおよびブート・サーバーの資格証明を指定します。

7. 「確認」ページで、選択した詳細をすべて確認し、「発行」をクリックしてデプロイメントのジョブを発行します。

第VIII部

ホスト管理

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

- 第37章「ホスト管理の概要」

- 第38章「ホストを監視する環境の設定」

- 第39章「ホスト監視環境のカスタマイズ」

- 第40章「ホストの監視」

- 第41章「ホストの管理」

37 ホスト管理の概要

ホストとは、管理対象のデータベースやその他のサービスが常駐するコンピュータです。ホストは、Oracle Enterprise Managerで監視および管理できる多数のコンポーネントやターゲットの1つです。

監視は、ホスト上のCloud Controlで管理されるターゲットのアクティビティ、ステータス、パフォーマンスおよび状態についての情報を収集し、追跡するプロセスを意味します。ホスト上にデプロイされた管理エージェントはプラグインと連携して、ホスト上の各管理対象ターゲットを監視します。Enterprise Managerによって検出および昇格されたホストは、監視することができます。

管理は、システム上のホストを管理および保持するプロセスです。

Oracle Enterprise Managerで監視しているすべてのホストを表示するには、Enterprise Manager Cloud Controlの「ターゲット」メニューから「ホスト」を選択します。

注意: ホストの検出と昇格、管理対象外ホストの検出、管理対象外ホストの管理対象ホストへの変換などの詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

37.1 ホスト統計

Enterprise Managerのホスト管理機能を使用すると、システム上のすべてのホストの概要を取得できます。これには、ライフサイクル・ステータスや構成変更などが含まれます。

ホストUIを使用することにより、次を行うことができます。

- 特定のホストが使用可能かどうか、およびそのホストに関してインシデントおよび問題があるかどうかを判別できます。

- 各ホストに適用可能な統計(メトリック)を表示できます。40を超えるメトリックから選択できます。メトリックの例としては、CPU、メモリー使用率、ファイルシステムおよびネットワーク統計があります。各ホスト・メトリックの詳細は、『Oracle Enterprise Managerフレームワーク、ホストおよびサービス・メトリック・リファレンス・マニュアル』を参照してください。

- 個々のホストを追加および構成します。

- Enterprise Managerのコンテキスト内で、複数のホストに対して管理操作を実行します。これを行うには、ホスト・コマンドを実行します。この方法では、複数のホストに対してオペレーティング・システムのコマンドを入力して、ただちに結果を確認できます。

- 問題ジョブの実行、一時停止中のジョブの実行および実行中のジョブなど、ジョブ・アクティビティの統計を分析します。

- 確立した標準に対するコンプライアンスのサマリー情報を分析します。これにより、ホストに関して問題が何であるかを判別でき、ただちにコンプライアンス違反を修正できます。

37.2 ホスト問題の診断

ホストの問題の診断するには、次の手順を実行します。

- ホストで報告されているインシデントおよび問題を調査します。

- CPU使用率、メモリー使用率、ファイルシステム使用状況およびネットワーク使用率で報告されている統計が、異なる期間ごとに、許容レベル内かどうかを確認します。

- 確立したコンプライアンス標準にホストが準拠していることを確認します。

- 問題のあるジョブの実行およびジョブが一時停止している理由を調査します。

37.3 ホスト上のターゲットの表示

Enterprise Managerでは、ホスト・ターゲット上のターゲットのサマリー情報を表示できます。インシデントや可用性の情報を分析することで個々のターゲットのパフォーマンスをすぐに判断できます。これにより、ターゲットが最高のパフォーマンスで機能するように、必要に応じて変更が可能です。

ホストに常駐できるターゲットには、データベース・インスタンス、Web CacheおよびOracle HTTP Serverなどがあります。

ホスト上のターゲットに対応する場合は、次を行います。

- インシデント情報を確認します。特定のインシデントに関連付けられたメッセージは、ターゲットの障害に関する詳細な説明を提供します。

- このターゲットに対してコンプライアンス違反があるかどうかを確認します。

- 必要に応じて、複数のターゲットをホストから削除します。
この機能は、監視が不要になったターゲットを管理リポジトリや管理エージェントから削除する際に特に役立ちます。監視対象のターゲットがコンピュータから削除された場合、あるいは管理エージェントやホストが使用されなくなった場合に、この機能が必要になります。

複数のターゲットを削除する場合は、次のことを確認してください。

- ターゲットを削除するときには、管理エージェントが稼働中であることを確認します。ターゲットの削除時に管理エージェントが停止していると、そのターゲットは管理リポジトリからのみ削除され、管理エージェントからは削除されません。したがって、管理エージェントが再び稼働すると、ターゲットは元どおりになります。

- 管理エージェントは、ホスト上に残っている唯一のターゲットでないかぎり削除できないので注意してください。

37.4 記憶域の統計と履歴

大規模なIT部門では、記憶域リソースの割当てと使用状況を追跡することが必須です。未割当てで十分に活用されていない記憶域を適切に使用できるようにします。ビジネス・エンティティ・レベルでの履歴傾向から今後の増加を予測して対応できます。

デフォルトでは、記憶域履歴の機能は有効ではありません。記憶域履歴を有効にすると、データベース・リソースに大きな負荷がかかります。履歴データを計算するために使用されるデータベース・リソースの量は、ホスト・ターゲットに関係付けられている記憶域データの量に依存します。

38 ホストを監視するための環境の設定

ホストの監視と管理を開始する前に、資格証明を設定し、必要なソフトウェアをインストールすることをお薦めします。この章では、次について説明します。

- 必須インストール

- Linuxホストの場合 - YASTのインストール

- 資格証明の設定

- ホストの監視で必要な設定

- ホスト管理で必要なターゲット設定

注意:
YASTのインストールは、Linuxオペレーティング・システムの場合のみ行います。

38.1 必須インストール

注意: これらの必須インストールは、Oracle Linux、Red Hat LinuxおよびSUSE Linuxのオペレーティング・システム(x86およびx64アーキテクチャのみ)が動作しているホストに対してのみ適用されます。

Enterprise Managerを通してホストを管理するには、スクリプトをインストールする必要があります。ホストにインストールする必要のあるスクリプトを判別するには、次の手順に従います。

1. 「ターゲット」メニューから「すべてのターゲット」または「ホスト」を選択します。

2. 「検索」フィールドに希望するホスト名を入力するか、「名前」列でそのホスト名までスクロール・ダウンします。

3. ホスト名をクリックします。

4. 「ホスト」メニューから「管理」を選択し、「サービス」を選択します。

5. 「必須インストール」ページが表示され、「管理」メニューで使用可能な任意のタスクを実行する前に、Linuxマシンにインストールする必要のあるソフトウェアのアプリケーションがリストされます。
たとえば、Linuxホストの場合、Yet Another Setup Tool (YAST)ラッパー・スクリプトおよびEMラッパー・スクリプトをインストールする必要があります。

38.2 Linuxホストの場合 - YASTのインストール

YASTは、SUSE Linuxディストリビューションの一部と同様の標準的なツールによる、オペレーティング・システムの設定および構成ツールです。Linuxの管理機能では、YASTを使用してスクリプトを実行します。Oracle LinuxおよびRHEL4 (Red Hat)では、YAST rpmに、Enterprise Managerのスクリプトが含まれています。そのため、次の場所からYAST rpmをインストールすると、Enterprise Managerのスクリプトもインストールされます。

http://oss.oracle.com/projects/yast

SUSEでは、次の場所から、Enterprise Managerのスクリプトおよびリモート・アクセス・モジュールをダウンロードする必要があります。

http://oss.oracle.com/projects/yast/files/sles9

YASTをインストールする前に、次の項目を確認します。

1. マシンのLinuxのバージョンを確認します。たとえば、uname -aコマンドを実行すると、RHEL (RedHat)、Oracle LinuxまたはSUSEのバージョンおよびコンピュータのビット(例: 32ビットまたは64ビット)がリストされます。YASTは、RHEL4以上およびOracle Linuxでサポートされます。

2. root権限を所有していることを確認します。

YASTをインストールするには、次の手順を実行します。

1. http://oss.oracle.com/projects/yastにアクセスします。Project: Yastページが表示されます。

2. 「ここ」リンクをクリックします。プロジェクトのダウンロード: Yastページが表示されます。お使いのLinuxのバージョン(EL5など)と一致するリンクをクリックします。

3. EL5のページで、マシンのビット数に関連したリンクをクリックします。32ビットではi386、64ビットではx86-64です。

4. yast_el5_x86_64.tarをクリックして、tarファイルをダウンロードします。

5. tarファイルがダウンロードされると、tarファイルが使用可能なディレクトリに移動します。

6. tar -xvf yast_el5_x86_64.tarを使用して、ファイルを解凍します。

7. yast_el5_x86_64ディレクトリに移動します。

8. sudo ./install.shを入力します。

9. YASTがインストールされたことを検証するには、/sbin/yast2を入力します。これにより、YASTコントロール・センターが表示されます。表示されない場合、YASTのインストールは失敗しています。

10. 「管理」メニューに戻ると、使用可能なLinux管理機能が「オプション」に表示されます。

YASTのインストール方法を説明するデモは、YouTubeのビデオ「Oracle Enterprise Manager 12c: Install YAST」(http://www.youtube.com/watch?v=7ZiwmxZVmAw)を参照してください。

38.3 資格証明の設定

ターゲット・インスタンスを管理するには、資格証明が必要です。

様々な資格証明を設定するには、UIページの右上にある「設定」メニューを選択し、「セキュリティ」を選択します。次のオプションを使用できます。

- 管理エージェントのインストールでは、名前付き資格証明を使用します。名前付き資格証明は、ホストに対する権限を明示的に付与します。

- 優先資格証明
ターゲットに優先資格証明が設定されている場合、そのターゲットにログインするアプリケーションは自動でその優先資格証明を使用します。優先資格証明を使用すると、管理対象ターゲットへのアクセスが簡易化されます。

デフォルトの資格証明を、各ターゲット・タイプに対して設定できます。デフォルトの資格証明は、優先資格証明が明示的に設定されていないすべてのターゲットで使用されます。

- 権限委任設定を設定すると、SudoまたはPowerBrokerを使用するように管理エージェントを設定でき、結果として権限付きスクリプトを実行できます。

詳細は、オンライン・ヘルプを参照してください。

38.4 ホストの監視で必要な設定

ホストの監視を開始する際には、どのメトリックを監視できるかを知る必要があります。また、ターゲット・インスタンスに対するモニタリング資格証明を設定することが必要な場合もあります。

この項では、これらのタスクで必要な手順について説明します。

38.4.1 監視構成の表示

「モニタリング構成」ページには、選択したホストで可能なモニタリングがレポートされます。

「モニタリング構成」ページにアクセスするには、次の手順を実行します。

1. 「ターゲット」メニューから「すべてのターゲット」または「ホスト」を選択します。

2. 「検索」フィールドに希望するホスト名を入力するか、「名前」列でそのホスト名までスクロール・ダウンします。

3. ホスト名をクリックします。

4. 「ホスト」メニューから「ターゲット設定」、「モニタリング構成」の順に選択します。

5. 「モニタリング構成」ページが表示されます。「詳細」には、たとえば、ディスク・アクティビティ・メトリック収集の最大行アップロードが含まれることがあります。
また、「モニタリング・ステータス」も表示されます。たとえば、Oracleは、このターゲットの可用性およびパフォーマンスの監視を自動で有効にしているため、それ以上の監視構成は不要です。

38.4.2 モニタリング資格証明の設定

モニタリング資格証明を使用すると、様々なターゲットの機能を監視したり、それらの機能にアクセスすることができます。モニタリング資格証明を使用することにより、様々なターゲット・タイプの既存の資格証明を管理できます。

モニタリング資格証明を編集するには、次の手順を実行します。

1. 「Enterprise Manager」ページで、ページ右上にある「設定」メニューを見つけます。

2. 「設定」メニューから「セキュリティ」を選択し、「モニタリング資格証明」を選択します。

3. 「モニタリング資格証明」ページで、「ホスト」を選択して、「モニタリング資格証明の管理」をクリックします。

4. ホストのモニタリング資格証明ページで、行を選択し、「資格証明の設定」をクリックして資格証明を編集します。

デフォルトでは、ホストには次の資格証明セットが定義されています。

- リアルタイム構成変更モニタリングのホスト資格証明

- ホストSNMP資格証明

- ホストWBEM資格証明

- 特権ホストの監視資格証明

emcli create_credential_set動詞を-monitoringオプションとともに使用することにより、資格証明セットを追加できます。

38.5 ホスト管理で必要なターゲット設定

ホストの管理を始める前に、管理者アクセス権を取得する必要があります。

「ホスト」ホームページの「ホスト」メニューから、「ターゲット設定」、「管理者アクセス」の順に選択します。このオプションを使用すると、ユーザー用のターゲット権限を判断できます。

39 ホストの監視環境のカスタマイズ

ホストの監視の使用を容易にするために、Enterprise Managerでは、ホスト・ページと環境のカスタマイズが可能です。次の項で説明します。

- 「ホスト」ホームページのカスタマイズ

- グループの使用

39.1 「ホスト」ホームページのカスタマイズ

デフォルトでは、「ホスト」ホームページには、次のリージョンが表示されます。

- サマリー

- 構成

- ジョブ・アクティビティ

- CPUとメモリー

- ファイルシステムとネットワーク

- インシデントと問題

- コンプライアンス標準サマリー

これらのリージョンは、幅の異なる(左側が狭い) 2列の形式で表示されます。

多くの顧客にとって、これらのリージョンと列の形式は、ニーズを満たしています。ただし、異なるリージョンの追加が必要なこともあります。

「ホスト」ホームページをカスタマイズするには、ページの右上にある「ページがリフレッシュされました」テキストの隣にある「ページのパーソナライズ」アイコンをクリックします。

リージョンを追加したり、削除することもできます。次のリージョンを追加できます。

- コンプライアンス・サマリー

- 構成詳細

- ホスト・ターゲットのCPUおよびメモリーのパフォーマンス・グラフ

- ホスト・ターゲットのファイル・システムおよびネットワークのパフォーマンス・グラフ

- インシデント・リスト

- ジョブ・アクティビティ・リージョン

- ジョブ・サマリー・リージョン

- パフォーマンス・メトリック・チャート

さらに、ページのレイアウトを、1つの列、2つの同じサイズの列および広い領域の上の2つの列などに変更できます。

39.2 グループの使用

グループは、グローバル環境内のターゲットを論理的に編成、管理および監視するための効果的な方法です。グループごとに、独自のグループ・ホームページがあります。グループ・ホームページにはグループに関する最も重要な情報が表示され、詳細情報にドリルダウンできます。ホームページには、グループの全体のステータスと、グループのメンバーに対する現在の可用性、インシデント、パッチ推奨などのその他の情報が表示されます。

『Oracle Enterprise Manager Cloud Control管理者ガイド』の「グループの管理」に、グループの様々なタイプと、グループを管理、編集および表示する方法が説明されています。

グループを作成するには、次の手順に従います。

1. Enterprise Managerコンソールから「ターゲット」、「グループ」の順に選択します。

2. 「作成」をクリックします。「グループ」、「動的グループ」または「管理グループ」を選択します。
ウィザードと同じように機能する一連のグループの作成ページが、Enterprise Managerコンソールに表示されます。各ページのフィールドの説明は、オンライン・ヘルプを参照してください。

3. 「グループの作成」ページまたは動的グループの作成ページの「一般」タブで、作成するグループの「名前」を入力します。これを権限伝播グループにする場合、「有効」をクリックして、「権限の伝播」オプションを有効にします。グループの「権限の伝播」を有効にした場合、グループで管理者(またはロール)に付与されているターゲット権限は、メンバー・ターゲットに伝播されます。
注意: 所有者が完全なターゲット権限を持つターゲットのみがメンバーになることができ、いずれのターゲットも基準に一致する可能性があり、システム全体への完全な権限が必要であるため、権限の伝播を有効にするには、完全なターゲット権限が必要です。通常の動的グループを作成するには、グループ所有者はメンバーシップ基準に一致する可能性があるすべてのターゲットを表示できる必要があるため、システム全体への「任意のターゲットの表示」権限が必要です。

4. 各ページを構成し、「OK」をクリックします。すべてのページを構成してから、「OK」をクリックする必要があります。これらの手順の詳細は、オンライン・ヘルプを参照してください。

グループを作成すると、グループ・ページからいつでも簡単にアクセスできます。

グループを編集して、グループを構成するターゲットの変更、または任意のターゲット・タイプの要約に使用するメトリックの変更ができます。グループを編集するには、次の手順に従います。

1. Enterprise Managerコンソールから「ターゲット」、「グループ」の順に選択します。

2. 編集するグループの「名前」をクリックします。

3. 「グループ」メニューから、「ターゲット設定」、「グループの編集」の順に選択します。

4. ページの構成を変更し、「OK」をクリックします。

または、グループ・ページのグループのリストから編集するグループを選択し、そのグループ表の上部の「編集」をクリックします。

40 ホストの監視

ホスト管理者は、ホストの動作状況を把握する必要があります。ホストを監視することで、次のような質問に答えることができます。

- ホストのスワップは発生していますか。

- ファイルシステムは一杯になりつつありますか。

- CPUは最大容量に達しつつありますか。

- リソースは効率的に使用されていますか。

- 複数のホストを監視するための最善の方法は何ですか。

- どのようにすれば、必要なリソースを事前にスケジュールして購入できますか。

これらの質問に対する回答は、日常の監視アクティビティにとって重要であり、この章で説明されるホストの監視のページで使用可能です。

注意: この章では、Enterprise Managerで使用可能な多くのメトリックを説明していますが、すべてが網羅されているわけではありません。使用可能なすべてのホスト・メトリックの完全な詳細は、『Oracle® Enterprise Managerフレームワーク、ホストおよびサービス・メトリック・リファレンス・マニュアル』を参照してください。

40.1 全体的な監視

ホストを監視する場合、主要なメトリックはCPU、メモリーおよびディスクの使用率です。

注意: この項で説明する機能にアクセスするには、ホストのホームページの「ホスト」メニューから、「モニタリング」を選択し、該当する機能を選択します。

40.1.1 CPU詳細

CPU統計を使用することにより、CPUリソースを追加する必要があるのか、または再分散させる必要があるのかを判断できます。特に次のことができます。

- CPUリソースを大量に消費するコマンドを判別し、任意の管理ツールを使用して、競合を軽減するための適切なアクションをターゲット・ホストに対して実行します。

- 過去24時間、過去1週間、過去1か月など様々な時間間隔における「CPU使用率」の傾向を表示します。

- すべてのCPU (集約ビューではなく、システム内のすべてのCPUのビュー)を監視します。

注意: Enterprise Managerでホスト・コマンドの実行機能を使用して、ホストでアクションを実行できます。

40.1.2 メモリーの詳細

メモリー統計を使用することにより、メモリー・リソースを追加する必要があるのか、または再分散させる必要があるのかを判断できます。特に、メモリー・リソースを最も多く使用しているプロセスを特定できます。

40.1.3 ディスクの詳細

ディスク統計を使用することにより、ディスク・リソースを追加する必要があるのか、あるいは既存のリソースに負荷をより効率的に分散できるのかを判断できます。特に、過度に使用されているディスク、またはサービス時間が長くなっているディスクを特定できます。

ディスク情報と、基礎となる記憶域を使用するアプリケーションからのレスポンスとを関連付けると、システムが適切にスケーリングされているかどうかを判断できます。さらに、次の質問に回答できます。ディスクの負荷を再分散する必要があるだろうか。記憶域の追加が必要だろうか。

負荷を再分散する場合は、ストレージを使用するアプリケーションを変更します。

40.1.4 プログラム・リソース使用率

プログラム・リソース使用率データを使用すると、次について、リソース使用率の傾向を確認できます。

- 特定のプログラムまたはプログラム・セット

- 特殊なユーザーまたはユーザー・セット

- プログラムとユーザーの組合せ

40.1.5 ログ・ファイル・アラート

Enterprise Managerはログ・ファイルを監視し、アラートを生成します。アラートが生成されると、次を行うことができます。

- オープン・アラートを選択してクリア、またはすべてクリアします。

- オープン・アラートを選択してパージ、またはすべてパージします。

注意:アラートをクリアした場合、そのアラートはクリア済としてマークされますが、管理リポジトリから削除されるわけではありません。ただし、アラートをパージした場合、そのアラートはシステムから完全に削除されます。

40.1.6 メトリック収集エラー

メトリック収集エラーは、ターゲット・メトリックの取得時に発生したエラーの詳細を提供します。これらの詳細によって、メトリックの収集時にエラーが発生した際に、ターゲットのパフォーマンスを正確に表さない場合があるメトリックの情報が提供されます。

40.2 記憶域詳細

大規模なIT部門では、記憶域リソースの割当てと使用状況を追跡することが必須です。未割当てで十分に活用されていない記憶域を適切に使用できるようにします。ビジネス・エンティティ・レベルでの履歴傾向から今後の増加を予測して対応できます。

記憶域の詳細は、1つ以上のホストに関連付けられているEnterprise Managerターゲットに関するものです。特に次の点が重要です。

- 表示されたサマリー属性は、1つ以上の関連ホストに対してロールアップされます。

- ホストは次のいずれかの方法でグループに関連付けられます。

- 明示的なメンバーシップ

- グループのメンバー・ターゲットから継承される、グループを構成する際の暗黙の関連付け

注意: 共有記憶域が正確にカウントされるのは、記憶域が複数システムからアクセスできるとき、または同一システムの複数の物理パスからアクセスできるときに1回ずつです。共有記憶域を正確にカウントするためにグローバル一意識別子が組み込まれています。

個々の記憶域統計が計算される方法の詳細は、オンライン・ヘルプを参照してください。

40.2.1 記憶域の使用状況

記憶域の使用状況は、ホスト・ターゲットのコンテキストで起動した場合にはホスト・レベルで、グループのコンテキストで起動した場合には関連ホスト・レベルで表示されます。

ホストのコンテキストでは、記憶域アイテムは、「ディスク」、「ボリューム」、「ASM(自動記憶域管理)」、「ファイルシステム」、「データベース」および「ベンダーの配分」です。

グループのコンテキストでは、関連付けられたホストに関する記憶域プロパティは、「ホスト別のプロビジョニング・サマリー」、「ホスト別の消費サマリー」および「ベンダーの配分」です。

グラフは、ある期間の履歴傾向を表示します。この情報に基づき、必要に応じてターゲット・ホストまたはグループに対する適切なアクションを実行できます。次のようなアクションがあります。

- ストレージを購入し追加

- 活用されていないアプリケーション・データをアーカイブ後に削除

- 不要なアプリケーション・データを削除

- ストレージのデプロイ構成を変更して最適化

注意: グループで表示される記憶域情報は、グループの関連ホストの各ホスト情報を集計したものです。

40.2.2 全体の使用量

「全体の使用量」では、システム・レベルの記憶域リソース使用率を示すサマリー属性(未割当て、オーバーヘッド、使用および空き)が提供されます。全体的な統計を使用することで、次を判別できます。

- 未割当ての記憶域はどのくらいか。

- デプロイ済アプリケーションの空き領域はどのくらいか。

40.2.3 プロビジョニング・サマリー

「プロビジョニング・サマリー」では、関連付けられたホストの「ファイルシステム」(書込み可能NFSの部分)、「ASM」、「ボリューム」および「ディスク」について、割当てに関連するサマリー属性(割当て済、未割当ておよびオーバーヘッド)が表示されます。

「プロビジョニング・サマリー」に表示される書込み可能NFSは、NFSを介してホストに接続されている記憶域の値であることに注意してください。各レイヤーは、アプリケーションに領域を割り当てるIT管理者によって管理されます。

割当てに関連する属性は頻繁に変更されることはありません。通常、変更が行われるのは、IT管理者が管理アクションを実行した場合です。この情報の計算方法の詳細は、「記憶域の計算式」のプロビジョニング・サマリーに関する項を参照してください。

ホストまたはグループの関連ホストのディスク、ボリューム、Oracle ASM、およびファイル・システム・レイヤーの書込み可能ネットワーク・ファイル・システム(NFS)部分に存在するすべてのエンティティについて、割当て済、未割当ておよびオーバーヘッドのサマリーが棒グラフで表示されます。

特定のレイヤーがデプロイされていない場合、対応するバーはグラフに表示されません。棒グラフにより、次のような疑問が解決されます。

- 指定したレイヤーにあるエンティティから割当て可能な領域はどのくらいか。

- 指定したレイヤーにあるエンティティから割り当てられた領域はどのくらいか。

- デプロイされたボリューム管理ソフトウェアのオーバーヘッドはどのくらいか。

- デプロイ済Oracle ASMソフトウェアのオーバーヘッドはどのくらいか。
注意: グループのコンテキストで起動した場合、グラフで表示されるロールアップ情報には、関連ホストに存在するローカル・ファイル・システムに基づくNFSマウントは含まれていません。

40.2.4 消費サマリー

「消費サマリー」では、「データベース」および「ファイルシステム」(ローカル・ファイル・システムと書込み可能NFSの2つの部分)について、使用状況に関連するサマリー属性(使用および空き)が表示されます。

使用状況に関連する属性の値は、割当てに関連する属性よりも頻繁に変更されます。この情報の計算方法の詳細は、「記憶域の計算式」の消費サマリーに関する項を参照してください。

ホストまたはグループの関連ホストのすべてのデータベース、すべてのローカル・ファイル・システム、およびすべての書込み可能ネットワーク・ファイル・システム(NFS)について、使用済および空き領域のサマリー情報が棒グラフで表示されます。

注意: グループのコンテキストで起動した場合、グラフで表示されるロールアップ情報には、関連ホストに存在するローカル・ファイル・システムに基づくNFSマウントは含まれていません。

40.2.5 ASM

Oracle Automatic Storage Management (ASM)は、Oracleデータベースでのボリューム・レイヤー・テクノロジの使用ニーズを抑制する、単純なストレージ管理ソリューションです。

40.2.6 データベース

データベースは、Real Application Cluster (RAC)データベースも含めたOracleデータベースを意味します。データベース上では他のアプリケーションを実行することができます。データベースは、ディスク、ボリューム、ファイル・システム、Oracle Automatic Storage Management (ASM)のレイヤーの領域を消費できます。

40.2.7 ディスク

ディスク統計では、ホスト上のすべてのディスクおよびディスク・パーティションについて割当て済および未割当ての記憶域が表示されます。EMCのストレージ・アレイなど外部ストレージ・システムの仮想ディスクも含めて、すべてのディスクが表示されます。

注意: 仮想ディスクのオーバーヘッドの情報は扱われません。表示もありません。

ディスクをデプロイして使用するには、最初にフォーマットする必要があります。フォーマットした後で、1つ以上のパーティションを含むように(ベンダー固有の構成ユーティリティを使用して)ディスクを構成できます。

ディスクまたはディスク・パーティションは、ホストの上位レイヤーのいずれか1つのエンティティ(ボリューム、Oracle ASM、データベースまたはファイル・システム)に(ベンダー固有の構成ユーティリティを使用して)関連付けることができます。ディスクまたはディスク・パーティションから上位レイヤーのエンティティへの関連付けがある場合、その関連付けは割当て済領域としてEnterprise Managerで報告されます。

40.2.8 ファイル・システム

ファイル・システム・レイヤーには、ディレクトリ(フォルダ)とファイルが含まれます。これらのアクセス、管理および更新は、データベース、中間層アプリケーションおよびエンドユーザー・ツールを使用して行えます。これは、広い意味では、ディスク・ベースのローカル・ファイル・システムやNFSのようなリモート・ファイル・システムに分類できます。Enterprise Managerでは、ファイル・システム・レイヤーのローカル・ファイル・システムと書込み可能NFSの部分にサマリー属性が提供されます。

ローカル・ファイルシステム

ローカル・ファイル・システムは、ホストで参照可能なディスク記憶域に基づいています。オペレーティング・システムによって、サポートされるローカル・ファイル・システムが異なります。次の表に例を示します。

ローカル・ファイルシステム

オペレーティング・システム

lofs

Solaris (ターゲット・インスタンスについてNMUPM_SUPPORT_LOFSプロパティが1に設定されている場合にのみ監視されます)

nfs

Solaris、Linux

tmpfs

Solaris

ufs

Solaris、Linux、AIX、HP

vxfs

Solaris、Linux、AIX、HP

zfs

Solaris、Linux、AIX

ext2

Linux、AIX

ext3

Linux、AIX

NFS

ネットワーク・ファイル・システム(NFS)には、ホストからネットワークを介してアクセスできます。実際のディスクへのI/Oはリモート・サーバー(NFSサーバー)が実行します。ネットワーク・アプライアンス・ファイラーなど、専用のNFSサーバー機能を提供するアプライアンスがあります。また、SolarisやLinuxなどのホスト・システムは、NFSサーバーとしてもクライアントとしても動作します。

書込み可能NFSは、書込み権限付きでホストにマウントされているNFSを指します。

NFSマウントの監視についての提案

次に、NFSマウントの監視についての提案を示します。

1. NFSエクスポートがEnterprise Managerによりサポートされている別のホストを起点にしている場合は、リモート・ホストを監視します。ファイルシステム・メトリックは、リモート・ホスト上のローカル・ファイルシステムを監視します。

2. NFSエクスポートがリモートNetApp Filerを起点としている場合は、NetApp Filerを監視します。ボリューム・メトリックおよびQtressメトリックは、リモートNetapp Filerからのエクスポートを監視します。

3. 前述の選択がニーズを満たさない場合は、「ファイルおよびディレクトリのモニタリング」メトリックを使用します。「ファイルまたはディレクトリのサイズ」メトリックに対してしきい値を設定して、特定のリモート・マウントを監視します。

40.2.9 ボリューム

ボリューム・マネージャ・テクノロジまたはSoftware*RAID (Redundant Arrays of Independent Disks)テクノロジと一般的に呼ばれるソフトウェア・パッケージが各種提供されています。このようなテクノロジは、基礎となる記憶域の信頼性、可用性およびスケーラビリティ(RAS)を改善するためにデプロイされます。たとえば、Veritas Volume Managerは複数のオペレーティング・システムで定評のある製品です。Enterprise Managerではこのようなテクノロジをボリュームと呼んでいます。

「ボリューム」オプションを使用すると、ボリューム・レイヤーに存在するすべてのエンティティの割当て済記憶域と未割当て記憶域の領域が表示されます。基礎となるボリューム・レイヤー・テクノロジに関連する属性も表示されます。

40.2.9.1 エンティティのタイプ

ボリューム・レイヤーの内部には様々なタイプのエンティティが含まれます。Enterprise Managerに表示されるエンティティ・タイプは、デプロイされたボリューム・レイヤー・テクノロジで定義されている用語に基づきます。たとえば、Veritas Volume Managerでは、ボリューム、プレックス、サブ・ディスク、VMディスク、VMスペア・ディスク、ディスク・グループというエンティティ・タイプが定義およびサポートされます。システムにデプロイされているボリューム・テクノロジの詳細は、ベンダーのドキュメントを参照してください。

40.2.9.2 トップレベルのエンティティ

各ベンダーのテクノロジにおいて、そのレイヤーの特定のタイプのエンティティを、上位レイヤーのエンティティと関連付けることができます。上位レイヤーの例としては、ファイル・システム、データベース、ASMがあります。たとえば、Veritas Volume Managerのエンティティのタイプであるボリュームは、上位レイヤーに関連付けられるエンティティです。このようなエンティティは、このドキュメントではトップレベルのボリューム・レイヤー・エンティティと呼ばれます。

トップレベルのボリューム・レイヤー・エンティティは、記憶域を上位レイヤーが使用するために提供します。トップレベル・エンティティが上位レイヤーへの関連付けを持たない場合、そのトップレベル・エンティティは未割当てであり、さらに割当て関連アクティビティで使用できます。

40.2.9.3 ボトムレベルのエンティティ

各ベンダーのテクノロジにおいて、そのレイヤーの特定のタイプのエンティティを、ディスク・レイヤーのエンティティと関連付けることができます。たとえば、Veritas Volume ManagerではVMディスクやVMスペア・ディスクがそのようなエンティティです。このようなエンティティは、このドキュメントではボトムレベルのボリューム・レイヤー・エンティティと呼ばれます。

ボトムレベルのボリューム・レイヤー・エンティティは、ディスク・レイヤーの記憶域を消費し、ボリューム・レイヤーのその他のエンティティに記憶域を提供します。予約タイプやスペア・タイプのボトムレベル・エンティティは、常に割当て済であるため、割当てのための領域はありません。スペア・エンティティはボリューム・テクノロジがディスク障害を処理するときに使用されるため、管理者が操作してボリューム・レイヤーに存在するその他のエンティティに割り当てることはできません。

スペアでないボトムレベル・エンティティは、各ベンダーの管理ユーティリティを使用して、構成済の中間エンティティまたはトップレベル・エンティティに関連付けることができます。スペアではないボトムレベル・エンティティに関連付けがない場合、そのエンティティは未割当てです。スペアではないボトムレベル・エンティティに1つ以上の関連付けがある場合、既存の関連付けを介して消費される領域が割当て済です。ボトムレベル・エンティティに関連付けが定義されている場合でも、そのエンティティに一部の領域が残る可能性があります。

スペアではないボトムレベル・エンティティが中間またはトップレベルのエンティティと関連付けられていない場合、その記憶域は割当てに使用することができ、ボトムレベル・エンティティの未割当て領域とみなされます。

40.2.9.4 中間のエンティティ

トップレベルやボトムレベルでないエンティティは、ボリューム・レイヤーの中間レベルのエンティティとみなされます。たとえば、Veritas Volume Managerではボリューム(レイヤーのあるボリュームの場合)、プレックス、サブ・ディスクなどがこのようなエンティティです。

中間エンティティが、別の中間エンティティまたはトップレベル・エンティティに関連付けられている場合、関連付けを介して消費される記憶域は割当て済です。関連付けを介して消費されない中間エンティティの領域は未割当てです。

次のベンダー製品が提供されています。

プラットフォーム

製品

Solaris

Solaris Volume Manager

Linux

mdadm、raidtool、Suse LVM

40.2.10 ベンダーの配分

ベンダーの配分統計は、関連付けられたホストについてホスト参照可能な記憶域を反映します。つまり、次の値です。

Sum of the size of all disks
+ Sum of the size of all Writeable NFS mounts

40.2.11 記憶域履歴

Enterprise Managerは、その記憶域統計の履歴傾向を提供します。履歴傾向は、過去1か月、過去3か月または過去1年について表示できます。この履歴傾向を使用して、将来的にどのくらいの記憶域が必要になるかを予測できます。

グループの場合、デフォルトでは履歴が有効になっていません。ユーザー・インタフェースを使用して、各グループの履歴の有効/無効を切り替えることができます。グループの履歴の計算には、Enterprise Managerリポジトリ・データベースのリソースを消費します。どのデプロイでも、グループのすべてのインスタンスについて履歴を持つことは有効でないと考えられるため、履歴を保持すべきグループは選択できるようになっています。

40.2.12 記憶域レイヤー

様々なストレージ管理テクノロジが1つのホストにデプロイされています。あるレイヤーにデプロイされたテクノロジは、それよりも上のすべてのレイヤーに記憶域リソースを提供でき、それよりも下のすべてのレイヤーの記憶域リソースを消費できます。

記憶域の最終的なコンシューマは、Oracleデータベースなどのアプリケーション・レベル・ソフトウェアまたはエンド・ユーザーです。Enterprise Managerでは、ボリュームは、様々なベンダーから提供されているボリューム管理とSoftware*RAID (Redundant Arrays of Independent Disks)のテクノロジを指します。

Enterprise Managerでは、記憶域の次のレイヤーと関連付けがモデル化されています。

記憶域レイヤー

記憶域の提供先

ディスク

ボリューム、ファイル・システム、データベース、ASM

ボリューム

ファイル・システム、データベース、ASM

ASM

Database

ファイルシステム

Database

40.2.13 記憶域リフレッシュ

記憶域のリフレッシュは、ホスト・ターゲットとグループ・ターゲットという2つのタイプについて実行されます。

ホスト・ターゲットでの記憶域のリフレッシュ

ホスト・ターゲットの場合、記憶域のリフレッシュ機能を使用すると、次のようにEnterprise Managerリポジトリの記憶域データをリフレッシュすることができます。

1. ホストからのすべての記憶域の属性のリアルタイム収集をEnterprise Managerで強制実行します。

2. 記憶域の属性をEnterprise Managerリポジトリにアップロードします。

リフレッシュ操作が終了したら、記憶域: UIページにホストの最新情報が表示されます。

グループ・ターゲットでの記憶域のリフレッシュ

グループ・ターゲットの場合、記憶域のリフレッシュ機能を使用すると、次のようにEnterprise Managerリポジトリの記憶域データをリフレッシュすることができます。

1. グループのすべてのメンバー・ホストからのすべての記憶域の属性のリアルタイム収集をEnterprise Managerで強制実行します。

2. 記憶域の属性をEnterprise Managerリポジトリにアップロードします。

関係するホスト数によって異なりますが、このリフレッシュには時間がかかることがあるため、この機能はEnterprise Managerのジョブ発行として提供されます。

リフレッシュ・ジョブが終了したら、記憶域: UIページにグループの最新情報が表示されます。

41 ホストの管理

ホストを監視すると、最適なレベルで動作するために微調整が必要であることがわかります。この章では、最大のパフォーマンスを達成するためにホストを管理する方法について説明します。特に、この章では次について説明します。

- ホストに関する構成操作

- 管理タスク

- ツールおよびコマンドの使用

- ホスト・ターゲットの追加

- ホスト・コマンドの実行

- 様々なタスク

41.1 ホストに関する構成操作

ホストの効率を高めるためにホストで実行可能な構成操作が数多くあります。次のような操作があります。

- ファイルおよびディレクトリの監視基準の構成

- 一般ログ・ファイルの監視基準の構成

- プログラム・リソース使用率監視基準の構成

この項で説明する構成操作にアクセスするには、次の手順を実行します。

1. 「ターゲット」メニューから「すべてのターゲット」または「ホスト」を選択します。

2. 「検索」フィールドに希望するホスト名を入力するか、「名前」列でそのホスト名までスクロール・ダウンします。

3. ホスト名をクリックします。

4. 「ホスト」メニューから、「監視」、「メトリックとコレクション設定」を選択します。

各構成説明の手順に従います。

41.1.1 ファイルおよびディレクトリの監視基準の構成

Enterprise Managerでは、様々なフレーバーのUNIXオペレーティング・システムを実行しているホスト上で、オペレータが指定した基準でファイルおよびディレクトリを監視します。オペレータは、目的のファイルおよびディレクトリを監視するための基準を構成する必要があります。

オペレータは監視設定ページを使用し、ファイルおよびディレクトリの監視基準を指定する必要があります。

ファイルおよびディレクトリの監視基準を構成するには、次の手順を実行します。

1. メトリックと収集設定ページで、「表示」メニューの「すべてのメトリック」を選択します。ファイルおよびディレクトリ監視メトリックを特定します。次のメトリックがあります。

- ファイルまたはディレクトリの属性が見つかりません

- ファイルまたはディレクトリの権限

- ファイルまたはディレクトリのサイズ(MB)

- ファイルまたはディレクトリ・サイズの変更率(KB/分)

2. 各メトリックを確認したら、どのメトリックを変更する必要があるかを判断します。鉛筆アイコンをクリックして、対応する詳細設定の編集ページにナビゲートします。

3. このページで「追加」をクリックして、新しい監視用の基準を指定できます。基準の構成の詳細は、「監視対象オブジェクトの指定に関する注意」を参照してください。

4. 「監視対象オブジェクト」表で行を選択し、「編集」または「削除」をクリックして既存の基準を編集または削除できます。

監視対象オブジェクトの指定に関する注意

「ファイル」または「ディレクトリ名」で監視対象の基準を指定します。「監視対象オブジェクト」表の各行で、監視対象の一意の基準を指定します。

「ファイル」または「ディレクトリ名」は、ホスト・オペレーティング・システムから監視するファイルまたはディレクトリの名前です。指定した値は、目的のファイルまたはディレクトリへの絶対パスに対応している必要があります。

正確な名前またはSQLワイルドカード(%および_)のいずれかを使用して、ファイルまたはディレクトリ名を指定できます。SQLワイルドカードは0文字以上の文字に一致します。SQLワイルドカード_は1つの文字に一致します。

41.1.2 一般ログ・ファイルの監視基準の構成

Enterprise Managerでは、オペレータが指定したパターンがログ・ファイルで発生しているかどうかを監視します。管理エージェント・ソフトウェアの所有者は、このパターンを読み取ることができます。この機能を使用して、ホスト上のログ・ファイルに記録された異常な状態を監視することができます。

ログ・ファイルは目的のパターンの出現について定期的にスキャンされ、スキャン中にそのパターンが出現するとアラートが生成されます。スキャン中、最終スキャン以降に作成された新規の内容が目的のパターンの出現について検索されます。

オペレータは「メトリックと収集設定」ページを使用して、ログ・ファイルの監視基準を指定する必要があります。ログ・ファイルの監視基準を構成するには、まず<log file name, match pattern in perl, ignore pattern in perl>の形式で監視基準を指定します。

Enterprise Managerコンソールで次の手順を実行します。

1. 「しきい値」フィルタが設定されているメトリックに表示される表で「ログ・ファイル・パターン一致行数」を検索します。この行の鉛筆アイコンをクリックして、詳細設定の編集: ログ・ファイル・パターン一致行数ページにナビゲートします。

2. 「監視対象オブジェクト」表で行を選択し、「編集」または「削除」をクリックして既存の基準を編集または削除できます。基準の構成の詳細は、「監視対象オブジェクトの指定に関する注意」を参照してください。

オプションとして、管理対象ホスト上の管理エージェントのORACLE_HOMEディレクトリで、次の手順を直接実行します。

1. デフォルトでは、一致する行数がログ・ファイルの監視を通じて報告されます。特定のファイルの一致するコンテンツをアップロードできるようにするには、$ORACLE_HOME/sysman/admin/lfm_ifilesファイルにファイルの絶対パスを追加します。$ORACLE_HOME/sysman/admin/lfm_ifiles.templateファイルは$ORACLE_HOME/sysman/admin/lfm_ifilesファイルの作成に必要なテンプレートです。

2. セキュリティの目的から、Enterprise Managerによる重要なファイルの監視を恒久的に無効にする必要がある場合があります。これには、重要なファイルの名前を$ORACLE_HOME/sysman/admin/lfm_efilesファイルに追加します。$ORACLE_HOME/sysman/admin/lfm_efiles.templateファイルは$ORACLE_HOME/sysman/admin/lfm_efilesファイルの作成に必要なテンプレートです。

監視対象オブジェクトの指定に関する注意

一連の列(Log File Name, Match Pattern In Perl, Ignore Pattern In Perl)により、監視対象の一意の基準を指定します。「監視対象オブジェクト」表の各行で、監視対象の一意の基準を指定します。同じログ・ファイルに対し、複数の基準を指定できます。

列

説明

ログ・ファイル名

この列では、監視対象のログ・ファイルへの絶対パスを指定します。SQLワイルドカード文字を使用して、複数のファイル名を指定できます。
例:

(a) /orahome/log/f1.log この値の場合、1つのログ・ファイルを監視します。(b) /orahome/log/%.log この値の場合、/orahome/logディレクトリ内の.log接尾辞を持つすべてのファイルを監視します。

Perlでのパターンの一致

この列では、一致するパターンを指定します。Perl式がサポートされています。
この列では、ログ・ファイルで監視する必要のあるパターンを指定します。それぞれのスキャン中に、指定したパターンに一致するものがないかどうかに関してファイルがスキャンされます。

例:

(a) Pattern Value = ERRORこのパターンの場合、errorを含むすべての行がtrueになります。

(b) Pattern Value = .*fan.*error.*このパターンの場合、fanおよびerrorを含む行がtrueになります。

Perlでのパターンの無視

この列では、無視するパターンを指定します。任意のログ・ファイル内で、行に無視するパターンが含まれている場合、一致するパターンを含む行は無視されます。
この列では、無視するパターンを指定します。Perl式がサポートされています。

無視する必要がない場合は、%を指定します。

タイム・スタンプ

この列が表示された場合には、常に%を指定してください。

41.1.3 プログラム・リソース使用率監視基準の構成

Enterprise Managerでは、様々なフレーバーのUNIXオペレーティング・システムを実行しているホスト上で、<program name, owner>の組合せにより消費されるCPUリソースを監視します。オペレータはリソース消費を監視する基準を構成する必要があります。この機能で、CPUリソースの消費量を追跡できます。

オペレータは監視設定ページを使用し、プログラム・リソース使用率の監視基準を指定する必要があります。

プログラム・リソース使用率の基準を構成する手順は、次のとおりです。

1. メトリックと収集設定ページで、「表示」メニューの「すべてのメトリック」を選択します。プログラム・リソース使用率メトリックを特定します。次のメトリックがあります。

- プログラムの最大CPU時間累積(分)

- プログラムの最大CPU使用率(%)

- プログラムの最大プロセス数

- プログラムの最大常駐メモリー(MB)

- プログラムの最小プロセス数

- プログラムの累積CPU時間合計(分)

- プログラムのCPU使用率の合計(%)

2. 各メトリックを確認したら、どのメトリックを変更する必要があるかを判断します。鉛筆アイコンをクリックして、対応する詳細設定の編集ページにナビゲートします。

3. 「監視対象オブジェクト」表で行を選択し、「編集」または「削除」をクリックして既存の基準を編集または削除できます。基準の構成の詳細は、「監視対象オブジェクトの指定に関する注意」を参照してください。

監視対象オブジェクトの指定に関する注意

一連の<Program Name, Owner>で監視対象の基準を指定します。「監視対象オブジェクト」表の各行で、監視対象の一意の基準を指定します。

列

説明

プログラム名

プログラム名は、ホスト・オペレーティング・システムで実行されているコマンドの名前です。UNIXシステムでは、psコマンドを使用して、実行中の各プロセスの名前を表示できます。プログラム名については、正確な名前またはSQLワイルド・カード(%および_)を含む名前のいずれかを指定できます。SQLワイルドカードは0文字以上の文字に一致します。SQLワイルドカード_は1つの文字に一致します。

所有者

所有者は、ホスト・オペレーティング・システムで任意のプロセスを実行しているユーザーの名前です。UNIXシステムでは、psコマンドを使用して、実行中の各プロセスの名前を表示できます。所有者については、正確な名前またはSQLワイルド・カード(%および_)を含む名前のいずれかを指定できます。SQLワイルドカードは0文字以上の文字に一致します。SQLワイルドカード_は1つの文字に一致します。

41.2 管理タスク

「管理」タブには、このホストで実行可能なすべての管理タスクにアクセスできます。リストされるカテゴリを使用して、システム・サービス、ネットワーク接続、ユーザーおよびグループ設定に関する適切なページに簡単にアクセスできます。管理タスクには、サービスの開始、ユーザーの設定およびネットワーク・カードの構成などがあります。

「管理」タブを使用すると、次を管理できます。

- サービス
個々のサービスの統計が表示され、サービスを編集できます。

注意: この機能は、Oracle Linux、Red Hat LinuxおよびSUSE Linuxのオペレーティング・システム(x86およびx64アーキテクチャのみ)が動作しているホストでのみ使用できます。

- デフォルトのシステム実行レベル

- ネットワーク・カード
ルーティング構成の管理、統計の構成の表示およびネットワーク・ファイル・システムのクライアントを表示できます。

- ホスト参照表

- NFSクライアント

- ユーザーとグループの管理
ユーザーおよびグループ設定を管理できます。

注意: Linuxシステムの場合、これらのアイテムについて管理タスクを実行するには、YASTラッパー・スクリプトおよびEMラッパー・スクリプトがインストールされている必要があります。詳細は、「ホストを監視するための環境の設定」の「必須インストール」を参照してください。

この項で説明する管理タスクにアクセスするには、次の手順を実行します。

1. 「ターゲット」メニューから「すべてのターゲット」または「ホスト」を選択します。

2. 「検索」フィールドに希望するホスト名を入力するか、「名前」列でそのホスト名までスクロール・ダウンします。

3. ホスト名をクリックします。

4. 「ホスト」メニューから、「管理」を選択し、次に変更対象のエンティティを選択します。

注意: 「管理」メニュー・オプションの操作を説明するビデオを表示するには、http://www.youtube.com/watch?v=ROfqR2GhQ_Eにアクセスしてください。

41.2.1 サービス

「サービス」ページには、このホストのすべてのサービスとそれらの統計のリストが表示されます。このページの機能は、次のとおりです。

- サービスの起動、停止および再起動。

- このページにアクセスして個々のサービスのプロパティを編集。

- 現行のシステムの実行レベルを表示。サービスの実行レベルが定義されていない場合、システムは現行のシステム実行レベルを使用します。

- サービスを有効にするかの決定およびサービスの実行レベルを表示。

実行レベル

説明

0

システム停止

1

シングル・ユーザー・モード
ログオンできるのは、常に1人のユーザーのみです。ログオンしているユーザーがシステムからログオフするまで、他のユーザーはログオンできません。

2

ネットワークを使用しないBasicマルチユーザー・モード

3

ネットワークを使用するフル・マルチユーザー・モード

4

この実行レベルは将来のOracleの使用に適しています。

5

ネットワークおよびX display managerを使用したフル・マルチユーザー・モード

6

システムの再起動

注意: 実行レベルを有効にするには、システムを再起動する必要があることに注意してください。

41.2.2 デフォルトのシステム実行レベル

デフォルトのシステム実行レベル・ページでは、システムが再起動するとき、システムが使用する実行レベルを変更できます。システムの再起動後、システムの実行レベルの変更が適用されます。

実行レベル

説明

0

システム停止。

1

シングル・ユーザー・モード

2

ネットワークを使用しないBasicマルチユーザー・モード

3

ネットワークを使用するフル・マルチユーザー・モード

4

未使用。この実行レベルは将来のOracleの使用に適しています。

5

ネットワークおよびX display managerを使用したフル・マルチユーザー・モード

6

システムの再起動。

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

- 「変更」をクリックして、ホスト資格証明を変更します。「デフォルトのシステム実行レベル」の操作を完了するには、SUDOERの資格証明が必要です。SUDOERの資格証明がない場合、このボタンで資格証明の変更ができます。

- 「取消」をクリックして、変更を中止し、ホスト: 管理ページに戻ります。

- 「保存」をクリックして、変更したデフォルトのシステム実行レベルを保持して、ホスト: 管理ページに戻ります。

- デフォルトのシステム実行レベル機能を使用するには、YASTツールキットをインストールする必要があります。「必須インストール」を参照してください。

システムが再起動されていない場合、実行レベルは即時発効しないので、デフォルトの実行レベルと現行の実行レベルは異なる可能性があります。

注意:
デフォルトの実行レベルは強力なツールです。十分な理解と経験がある場合のみ、デフォルトの実行レベルを変更する必要があります。デフォルトの実行レベルの変更が不適切に行われると、再起動後、システムの機能に障害が発生する可能性があります。

41.2.3 ネットワーク・カード

ネットワーク・カード・ページでは、企業のネットワーク・カードの詳細情報が表示されます。この情報を使用して、グローバルなドメイン・ネーム・システム(DNS)設定、およびルーティング表の構成に必要な編集を実行するか決定します。

ネットワーク・カード・ページを使用して、次の操作を実行できます

- ネットワーク・カードを構成、有効化および無効化します。

- Enterprise Managerが使用するネットワーク・カードのデバイス名およびIPアドレスが表示されます。

- DNS設定を表示して、「編集」をクリックして、リストされたドメインにあるグローバルなDNS設定を変更します。

- 使用可能なデフォルトのゲートウェイを編集するか、「追加」をクリックして、ルーティングの構成を定義します。

注意

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

- 「終了」をクリックすると、変更を行わずページを終了します。

- 「変更」をクリックすると、このページで使用する資格証明を編集します。

ネットワーク・カードの構成

「ネットワーク・カードの構成」ページを使用して、ネットワーク・カードの仕様を変更します。このページで、次の操作を実行できます。

- 「静的アドレス設定」またはDHCPを使用する「自動アドレス設定」のどちらかの設定メソッドを選択します。

- IPアドレスの追加

- サブネット・マスクの情報の追加

- 最大送信ユニット(バイト)

ルーティング構成の追加

「ルーティング構成の追加」ページを使用して、ルーティングのリクエストに対してゲートウェイまたはネットワーク・デバイスのいずれかを追加します。このページで、次の操作を実行できます。

- 使用するゲートウェイの指定

- 使用するデバイスの指定

- ネットワークにルーティングを構成するときのネットマスクおよび接続先の指定

41.2.4 ホスト参照表

ホスト参照表ページでは、ホスト名またはホストの別名からのIPアドレスのマッピングが表示されます。このページで、次の操作を実行できます。

- ホスト名および別名の編集

- 参照表からホストのエントリの削除

- ホスト構成の追加ページにアクセスして、参照表にホストのエントリを追加

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

- ホストは1つ以上の別名を持つことができます。

- 「終了」をクリックすると、変更を行わずページを終了します。

- 「変更」をクリックすると、このページで使用する資格証明を編集します。変更を発効するために再起動する必要はありません。

- 各別名はカンマで区切られる必要があります。

41.2.5 NFSクライアント

NFSクライアント・ページでは、現行のホストにマウントしているすべてのネットワーク・ファイル・システム(NFS)のクライアントをリストします。このページで、次の操作を実行できます。

- クライアントのマウント、アンマウントおよび削除

- このページにアクセスして個々のクライアントのプロパティの編集

- このページにアクセスしてホストへのNFSクライアントの追加

- 様々なクライアントの統計の表示

クライアント統計

説明

サーバー

リモートのNFSサーバーのホスト名

リモート・ファイルシステム

リモート・ファイル・システムの場所

マウント・ポイント

ローカル・マウント・ポイント

マウント済

リモート・ファイル・システムがマウントされているか示します。

再起動後も維持

再起動の間、マウント・ポイントを維持します。

オプション

マウント・オプションが表示されます。

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

- 「終了」をクリックすると、いかなる変更も行わずこのページを終了し、前のページに戻ります。

- 「変更」をクリックすると、このページで使用したホストの資格証明を編集します。

NFSクライアントの追加および編集

「NFSクライアントの追加」ページおよび「NFSクライアントの編集」ページでは、リモートのNFSサーバーにあるファイルシステムをローカル・ホストの場所にマウントできます。これらのページを使用すると、次のアイテムを入力して、NFSマウントの作成および編集を行うことができます。

- ローカル・マウント・ポイント

- NFSサーバー・ホスト名の名前

- リモート・ファイル・システムの場所

- マウント・オプション

オプション

ro

rsize=32768

wsize=32768

acregmin=1200

acregmax=1200

acdirmin=1200

acdirmax=1200

hard

intr

tcp

lock

rw

nosuid

nodev

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

- 「取消」をクリックして、すべての変更を無視して、NFSクライアント・ページに戻ります。

- 「OK」をクリックして、すべての変更を適用します。すべての変更は即時実装されます。

- 「再起動後も維持」を選択して、再起動の間、マウントが使用可能であることを確認します。

41.2.6 ユーザーとグループの管理(ユーザー)

ユーザーとグループの管理(ユーザー)ページでは、このホストのすべてのユーザー・アカウントが統計とともにリストされます。このページでは、次の処理を実行できます。

- ユーザー・アカウントの統計を編集するページにアクセス

- このページにアクセスしてホストにユーザー・アカウントを追加

- ホストからユーザー・アカウントを削除

- 特定のユーザー・アカウントの統計を表示

ユーザー統計

説明

ログイン

ソフトウェアにアクセス可能なユーザー・アカウント名

名前

ユーザー・アカウントの完全名
多くのログインに同じ名前を使用できます。たとえば、ログインaim1、aim2およびaim3にはすべて同じ名前、AIM Managerとすることができます。

UID

ユーザー・アカウント識別子
この識別子はログインに対して一意です。

グループ

ユーザー・アカウントが属するカテゴリ
ユーザー・アカウントは、グループに与えられた権限を継承します。

ローカル・ユーザーの追加または編集

次のオプションを使用すると、このホストにユーザー・アカウントを追加したり、このホストのユーザー・アカウントを編集できます。次の表に、フィールドの説明を示します。

グループ情報

説明

ユーザーのフルネーム

ユーザー・アカウントの完全名

ユーザー名

ログインに使用する名前

パスワード

ユーザー名とともに、ホストにアクセス可能な文字セット
パスワードは5文字以上72文字以下にする必要があります。ユーザーのパスワードを変更した場合、この変更をユーザーに通知してください。

パスワードの確認

このフィールドで入力するパスワードは、「パスワード」フィールドで入力したものと完全に一致する必要があります。
「パスワード」フィールドで入力したパスワードと、入力したパスワードが一致しない場合、パスワードを再入力するか、新しいパスワードを定義し、入力します。

ユーザーID (UID)

ユーザー識別子
識別子はユーザー・アカウントに対して一意です。IDは499より大きい整数である必要があります。

ホーム・ディレクトリ

ホーム・ディレクトリがスラッシュ(/)から始まることを確認します。

ユーザーの追加情報

ユーザーの追加情報を入力します。

ログイン・シェル

ドロップダウン・リストで使用可能なシェルのリストからログイン・シェルを選択します。

デフォルト・グループ

使用可能なグループのドロップダウン・リストからデフォルト・グループを選択します。

グループ・メンバーシップ

ユーザー・アカウントが属するグループ
グループ名はカンマで区切られます。スペースを入れないでください。たとえば、adm,daemon,rootのように区切ります。

ローカル・ユーザーを編集する場合、次を行うことができます。

- パスワードの変更

- デフォルト・グループなどのプロファイル情報の変更

41.2.7 ユーザーとグループの管理(グループ)

「ユーザーとグループの管理(グループ)」ページでは、ホストにあるすべてのグループとその統計をリストします。このページで、次の操作を実行できます。

- このページにアクセスしてグループ統計を編集

- このページにアクセスしてグループをホストに追加

- ホストからグループを削除

- 特定のグループの統計を表示

グループ統計

説明

グループ名

グループの名前

グループID

グループ識別子。このIDはグループに対して一意です。

グループ・メンバー

そのグループに属するグループ。グループでは下位グループに与えた権限を共有します。

注意: この機能は、Linuxでのみ使用可能です。

ローカル・グループの追加または編集

新規ローカル・グループの追加ページでは、このホストにグループを追加できます。新規ローカル・グループの追加ページでは、次の表にリストされたフィールドに情報を追加できます。

グループ情報

説明

グループ名

グループの名前

グループID

グループ識別子。このIDはグループに対して一意です。

グループ・メンバー

このグループに属するグループ。グループでは下位グループに与えた権限を共有します。グループ名はカンマで区切られます。スペースを入れないでください。たとえば、adm,daemon,rootのように区切ります。

ローカル・グループを編集する場合、次を行うことができます。

- グループIDの変更

- グループ・メンバーの追加、削除または変更

41.3 ツールおよびコマンドの使用

ホストを容易に管理できるようにするツールおよびコマンドが数多く提供されています。この項では、次について説明します。

- SudoおよびPower Broker

- ホスト・コマンド

- リモート・ファイル・エディタ

41.3.1 SudoおよびPower Brokerの有効化

sudoコマンドは、UNIX型オペレーティング・システムにおいて、ユーザーが別のユーザー(通常はrootユーザー)のセキュリティ権限でプログラムを実行できるプログラムです。監査の機能もあります。

PowerBrokerは、ユーザーが実行できるコマンドの種類を制限し、ユーザーが実行した、または実行を試行した操作の監査証跡を管理できるツールです。PowerBrokerを使用すると、ポリシーで定義した認証の制御が可能になるので、rootまで含めて、使用を許可された他のアカウントにエンドユーザーがいつ、どこでアクセスできるかを管理者が定義できます。

SudoまたはPowerBrokerを有効にするには、次の手順を実行します。

1. ページの右上にある「設定」メニューから、「セキュリティ」を選択し、「名前付き資格証明」を選択します。

2. 「名前付き資格証明」ページで、「作成」をクリックします。

3. 資格証明の作成ページで、ホスト資格証明にroot権限を指定します。

4. 「資格証明プロパティ」セクションで、「実行権限」から「Sudo」または「PowerBroker」を選択します。

5. SudoまたはPowerBrokerの詳細を指定し、システムが管理タスクを実行します。

SudoまたはPower Brokerの使用

Linux管理者としてSudoまたはPower Brokerを使用するには、次の手順を実行します。

- ホスト・ターゲットのページに移動します。

- ホスト・ターゲットの管理アクティビティのリストを表示します。

- 管理タスクを選択します。

- ルート権限を持つホスト資格証明を指定します。Sudo (runas)サポートまたはPower Broker (profile)サポートの情報を入力します。

- 詳細を入力すると、システムが管理タスクを実行します。

41.3.2 SudoまたはPowerBrokerを使用したホスト・コマンドの実行

SudoまたはPowerBrokerを使用してホスト・コマンドを実行するには、次の手順を実行します。

1. ホスト・ターゲットのページに移動します。
「ターゲット」メニューから「ホスト」を選択します。ホスト・ページで、興味のあるホストの名前をクリックします。

2. 「ホスト・コマンドの実行」ボタンをクリックします。

3. ホスト・ターゲット資格証明を指定します。Sudo (runas)サポートまたはPowerBroker (profile)サポートの情報を入力します。
注意: ターゲット・ホストには、ターゲット・ユーザー情報が挿入された/etc/sudoersファイルが存在する必要があります。

4. システムで実行する特定のコマンドを入力し、コマンドの出力を表示します。

41.3.3 リモート・ファイル・エディタ

リモート・ファイル・エディタを使用すると、リモート・ホスト上のテキスト・ファイルを表示および編集できます。たとえば、このユーティリティを使用して、リモート・ホスト上にある構成ファイルの内容を更新できます。また、次の操作も可能です。

- 適切な権限があれば、リモート・ホスト上のテキスト・ファイルを表示および編集できます。

- 「保存」をクリックして、リモート・ホスト上で編集したファイルを保存します。

- 「コピーの保存」をクリックして、内容をリモート・ホスト上の別のファイルに保存します。

- 「ユーザー」の横の「変更」をクリックして、他のユーザー・アカウントに変更または他のホストの優先資格証明セットを使用します。

- 編集するファイルを開いた後に、「ファイル名」の横の「変更」をクリックして新しく編集するファイルを選択します。

- 「元に戻す」をクリックして、最後に保存した時点のテキストに戻します。

リモート・ファイル・エディタへのアクセス

リモート・ファイル・エディタに移動するには、次のステップを実行します。

1. 「ターゲット」メニューから「ホスト」を選択します。ホスト・ページで、興味のあるホストの名前をクリックします。

2. 表示された「ホスト」ホームページで、(ページの左上にある)「ホスト」メニューから「リモート・ファイル・エディタ」を選択します。

3. ホスト・ターゲットに優先資格証明が設定されていない場合、ホスト資格証明ページが表示されます。「優先」、「名前付き」および「新規」の3つのオプションを使用できます。
ターゲット・ホスト上で操作を実行する権限が必要です。

4. 資格証明が設定されたら、リモート・ファイル・エディタ・ページで次を実行できます。

- ディレクトリにあるファイルのリスト表示、ファイルのオープンと読取り、編集、保存などのファイル操作を実行します。

- ホスト・ターゲット資格証明を指定します。

- ファイルの詳細および実行する操作のタイプを指定します。

注意

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

- ファイルは、100KB以下のASCIIテキスト・ファイルである必要があります。

- 資格証明チェックに成功し、ファイルが存在してそのファイルに対する読込み権限がある場合、ファイルの内容が編集用にロードされます。

- 書込み権限がない場合、ファイルの保存はできません。「コピーの保存」をクリックして、書込み権限のあるディレクトリにファイルを保存します。

- ファイルが存在しないが、ディレクトリに対して書込み権限がある場合、テキストの入力用に新規ファイルが開きます。

41.4 ホスト・ターゲットの追加

ホスト・ターゲットを追加するには、管理するホスト・コンピュータにOracle Management Agentをインストールします。

次の詳細情報が使用可能です。

- 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』の「Oracle Management Agentのインストール」。ホスト・ターゲットの追加ウィザードについて詳細に説明しています。

- 『Oracle Enterprise Manager Cloud Control管理者ガイド』の「ターゲットの検出、昇格および追加」。

41.5 ホスト・コマンドの実行

ホスト・コマンドを使用すると、1つのホスト、複数のホストまたは複数ホストで構成されるグループに対して管理操作を対話形式で実行できます。たとえば、このコマンドを使用すると、DBAは一連のホストの共通ディレクトリの内容をリスト表示することができます。

41.5.1 ホスト・コマンドへのアクセス

ホストに対する管理操作を実行するためにホスト・コマンドの実行ページにアクセスするには、次の手順を実行します。

1. 「ターゲット」メニューから「すべてのターゲット」または「ホスト」を選択します。

2. 「検索」フィールドに希望するホスト名を入力するか、「名前」列でそのホスト名までスクロール・ダウンします。

3. ホスト名をクリックします。そのホストのホームページが表示されます。

4. 「ホスト」メニューから「ホスト・コマンドの実行」を選択します。

5. ホスト資格証明ページで、ホストに対するユーザー名とパスワードを入力します。

6. ホスト・コマンドの実行ページが表示されます。

41.5.2 SudoまたはPower Brokerを使用したホスト・コマンドの実行

SudoまたはPower Brokerを使用してホスト・コマンドを実行するには、次の手順を実行します。

- ホスト・ターゲットのページに移動します。

- ホスト・ターゲットでコマンドを実行します。

- ホスト・ターゲット資格証明を指定します。Sudo (runas)サポートまたはPower Broker (profile)サポートの情報を入力します。

- システムで実行する特定のコマンドを入力し、コマンドの出力を表示します。

注意: 資格証明(Sudo/PowerBrokerとして実行)が設定されていない場合は、資格証明を作成するように求められます。資格証明を作成するには、「設定」メニューから「セキュリティ」を選択し、「名前付き資格証明」または「優先資格証明」のいすれかを選択します。

41.5.3 ホスト・コマンドの実行 - 複数のホスト

ホスト・コマンドの実行ページでは、複数のホストに対してオペレーティング・システムのコマンドを入力し、ただちに結果を表示できます。これにより、Enterprise Managerのコンテキスト内で複数のホストに管理操作を実行できます。

このページでは、次の操作が可能です。

- コマンドの改良、コマンドの再実行、および実行結果の表示を、すべて同じページで実行できます。

- オペレーティング・システムのコマンドを入力、ブラウザ・マシンまたはホストのスクリプトからコマンドをロード、またはジョブ・ライブラリで定義されているジョブからホスト・コマンドをロードします。

- ホストを個別に選択するか、グループを使用して選択します。1つのホスト・ターゲットに対してのみ作用する単一ターゲット・モードに切り替えることもできます。

- 対話形式でコマンド実行結果を表示するか、結果を非表示にして後で表示します。

- 優先資格証明を使用またはオーバーライドします。

- ターゲットを追加し、ターゲット・リストを変更します。

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

- コマンドは「実行」をクリックして再実行します。

- 処理中: ホスト・コマンドを実行していますページが表示されたときに、コマンドの実行を取り消すことができます。

- 実行履歴には、「このコマンドの実行履歴を保存」オプションを選択して実行した以前のセッションで実行されたすべてのホスト・コマンドとともに、現行のホスト・コマンドの実行セッションで実行されたホスト・コマンドが示されます。

- 「追加」をクリックすると、ターゲット・タイプ・リストがホスト・ターゲットおよびホスト・ターゲットを含むグループに限定されたターゲット選択ページが起動します。

- OSスクリプトまたは実行結果を保存すると、保存済ファイルはブラウザ・マシン上に配置されます。

- 履歴リストに表示できるのは500行までです。

- ターゲット表には最大10行のコマンド実行結果データが表示されます。それを超えるデータが返された場合、表で「実行ステータス」アイコンをクリックするか、「実行結果の完了」をクリックします。

- 複数ターゲット・モードから単一ターゲット・モードに切り替えると、ターゲット表内の最初のホストが使用されます。

41.5.3.1 ターゲットのプロパティ

ホスト・コマンドはEnterprise Managerジョブ・システムを使用して実行されます。ジョブ・システムを使用して、ターゲット・プロパティと呼ばれるシステム変数を指定できます。サポートされているターゲット・プロパティを次の表に示します。ジョブを実行するターゲットのタイプにより、使用できるプロパティが異なる点に注意してください。

名前

説明

ターゲット・タイプ

%emd_root%

管理エージェントの場所

ホスト、データベース・インスタンス

%perlbin%

管理エージェントが使用するPerlバイナリの場所

ホスト、データベース・インスタンス

%TargetName%

ターゲット名

ホスト、データベース・インスタンス

%TargetType%

ターゲット・タイプ

ホスト、データベース・インスタンス

%orcl_gtp_comment%

コメント

ホスト、データベース・インスタンス

%orcl_gtp_contact%

連絡先

ホスト、データベース・インスタンス

%orcl_gtp_deployment_type%

デプロイメント・タイプ

ホスト、データベース・インスタンス

%orcl_gtp_line_of_bus%

ライン・オブ・ビジネス

ホスト、データベース・インスタンス

%orcl_gtp_location%

ロケーション

ホスト、データベース・インスタンス

%OracleHome%

Oracleホーム・パス

データベース・インスタンス

%Port%

ポート

データベース・インスタンス

%SID%

データベースのSID

データベース・インスタンス

%Role%

データベース・ロール

データベース・インスタンス

%MachineName%

リスナー・マシン名

データベース・インスタンス

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

- プロパティ名では大文字と小文字が区別されます。

- プロパティは、「コマンド」フィールドと「OSスクリプト」フィールドの両方に使用できます。

- ターゲット・プロパティ以外に%文字を使用するには、2つ目の%を使用してエスケープしてください。

- データベース・インスタンスのターゲット・タイプを使用するには、1つ以上のホスト・ターゲットを含むグループから「ホスト・コマンドの実行」を起動し、「ターゲット・タイプ」を切り替えてください。

例:

Perlスクリプトを実行するには、引数としてターゲット名を渡し、「コマンド」フィールドに%perlbin%/perl myPerlScript %TargetName%と入力します。

Windowsホスト上のTEMP環境変数で指定されているディレクトリでプログラムを実行する場合は、%%TEMP%%/myProgramとなります。

41.5.4 ホスト・コマンドの実行 - グループ

ホスト・コマンドの実行ページでは、グループのコンテキストで、複数のホストに対してオペレーティング・システムのコマンドを入力し、ただちに結果を表示できます。これにより、Enterprise Managerのコンテキスト内で複数のホストに管理操作を実行できます。

このページでは、次の操作が可能です。

- ターゲット・タイプを選択します。ホストを直接選択するか、データベース・インスタンス・ターゲットを介してホストを選択できます。

- コマンドの改良、コマンドの再実行、および実行結果の表示を、すべて同じページで実行できます。

- オペレーティング・システムのコマンドを入力、ブラウザ・マシンまたはホストのスクリプトからコマンドをロード、またはジョブ・ライブラリで定義されているジョブからホスト・コマンドをロードします。

- ホストを個別に選択するか、グループを使用して選択します。1つのホスト・ターゲットに対してのみ作用する単一ターゲット・モードに切り替えることもできます。

- 対話形式でコマンド実行結果を表示するか、結果を非表示にして後で表示します。

- 優先資格証明を使用またはオーバーライドします。

- ターゲットを追加し、ターゲット・リストを変更します。

注意

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

- コマンドは「実行」をクリックして再実行します。

- 処理中: ホスト・コマンドを実行していますページで「取消」をクリックして、コマンドの実行を取り消します。

- 現在のターゲット・タイプがホストである場合、「追加」をクリックすると、ターゲット・タイプ・リストがホスト・ターゲットおよびホスト・ターゲットを含むグループに限定されたターゲット選択ページが起動します。

- 現在のターゲット・タイプがデータベース・インスタンスである場合、「追加」をクリックすると、ターゲット・タイプ・リストがデータベース・ターゲットおよびデータベース・ターゲットを含むグループに限定されたターゲット選択ページが起動します。

- 実行履歴には、「このコマンドの実行履歴を保存」オプションを選択して実行した以前のセッションで実行されたすべてのホスト・コマンドとともに、現行のホスト・コマンドの実行セッションで実行されたホスト・コマンドが示されます。

- ターゲット・タイプを変更すると、ホストの資格証明、コマンド、OSスクリプトおよびターゲット表が再初期化されます。

- OSスクリプトまたは実行結果を保存すると、保存済ファイルはブラウザ・マシン上に配置されます。

- ターゲット表には最大10行のコマンド実行結果データが表示されます。それを超えるデータが返された場合、表で「実行ステータス」アイコンをクリックするか、「実行結果の完了」をクリックします。

- 複数ターゲット・モードから単一ターゲット・モードに切り替えると、ターゲット表内の最初のホストが使用されます。

41.5.5 ホスト・コマンドの実行 - 単一ホスト

ホスト・コマンドの実行ページでは、1つのホストに対してオペレーティング・システムのコマンドを入力し、ただちに結果を表示できます。これにより、Enterprise Managerのコンテキスト内でそのホストに管理操作を実行できます。

このページでは、次の操作が可能です。

- コマンドの改良、コマンドの再実行、および実行結果の表示を、すべて同じページで実行できます。

- 複数のホスト・ターゲットに作用する複数ターゲット・モードに切り替えます。

- 資格証明を変更します。

注意

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

- コマンドは「実行」をクリックして再実行します。

- 「中断」をクリックして、コマンド実行を取り消します。

- 複数ターゲット・モードに切り替えると、ホスト・コマンド、ホストおよび資格証明を含め、コンテキストが保存されます。

41.5.6 OSスクリプトのロード

OSスクリプトのロード・ページは、スクリプトからホスト・コマンドの実行ページの「OSスクリプト」フィールドにコマンドをロードするために使用されます。

このページでは、次の操作が可能です。

- 「参照」をクリックして、ブラウザのファイル選択ウィンドウを起動し、スクリプト・ファイルを検索して選択します。

- 「ホスト」フィールドの検索アイコンをクリックして、検索するホストを選択し、次に「ホスト・ファイル」フィールドの検索アイコンをクリックして、そのホストのスクリプト・ファイルを検索して選択します。

41.5.7 ジョブ・ライブラリからロード

ジョブ・ライブラリからロード・ページには、ジョブ・ライブラリ・ディレクトリで既存のジョブを検索するメカニズムがあります。これにより既存のジョブを再利用できます。

このページで、任意の行の「ロード」列のアイコンをクリックすると、ホスト・コマンドの実行ページに戻り、その行のライブラリ・ジョブの完全なコンテキストをロードできます。完全なコンテキストには、ホスト・コマンド、OSスクリプト、ターゲットおよび資格証明が含まれます。

注意: このページの表に表示されるジョブは、現在のEnterprise Managerユーザーが所有するジョブ・ライブラリからのホスト・コマンド・ジョブです。

41.5.8 実行履歴

実行履歴ページには、「このコマンドの実行履歴を保存」オプションを選択して実行した以前のセッションで実行されたすべてのホスト・コマンドとともに、現行のEnterprise Managerセッション中に実行されたホスト・コマンドのリストが表示されます。

このページでは、次の操作が可能です。

- 任意の行の「ロード」列のアイコンをクリックして、ホスト・コマンドの実行ページに戻り、その行のホスト・コマンドの完全な実行コンテキストをロードします。完全な実行コンテキストには、ホスト・コマンド、OSスクリプト、ターゲット、資格証明および結果が含まれます。

- 任意の行の「コマンドおよびOSスクリプトのみロード」列のアイコンをクリックして、ホスト・コマンドの実行ページに戻り、その行のホスト・コマンドおよびOSスクリプトのみをロードします。ターゲット、資格証明および最近の結果は残ります。

- 任意の行の「削除」列のアイコンをクリックして、その行のホスト・コマンドを、すべての実行コンテキストとともに実行履歴から削除します。これにより、そのホスト・コマンドの実行に使用されたジョブは削除されます。

41.5.9 実行結果

実行結果ページには、特定のホストについて、実行済ホスト・コマンドの完全な結果リストが表示されます。このリストには、実行のすべての情報が実行順に表示されます。

このページでは、次の操作が可能です。

- リストからテキストを切り取り、別のスクリプトに貼り付けます。

- 中断されていない結果を調べ、他のすべての実行と区別します。

注意: 編集機能の限度は、結果を表示するブラウザに依存します。

41.6 様々なタスク

この項では、実行可能な様々なタスクについて説明します。

- WBEM Fetchletベースのメトリック収集の有効化

- Dell PowerEdge Linuxホストでのハードウェア監視の有効化

- ホスト構成の追加および編集

41.6.1 WBEM Fetchletベースのメトリック収集の有効化

ホスト・ターゲットでWeb-Based Enterprise Management (WBEM) Fetchletベースの収集を有効にするには、WBEMホスト名およびWBEMホスト・パスワードのプロパティを構成します。

注意: LinuxおよびWindowsオペレーティング・システムを実行しているホスト・ターゲットでは、デフォルトではWBEM Fetchletベースのメトリック収集ができません。これは、デフォルトでは、これらのオペレーティング・システムで、DMTF (Distributed Management Task Force) WBEM準拠のCommon Information Model (CIM) Object Managerが実行されないためです。システムがWBEM準拠のCIMオブジェクト・マネージャを実行するように構成されている場合には、WBEM Fetchletベースのメトリック収集が可能になります。

WBEM準拠のCIMオブジェクト・マネージャを持つシステムで収集を構成する手順は次のとおりです。

1. 特定のホストのホームページにナビゲートします。

2. 「ホスト」メニューから「ターゲット設定」、「監視構成」の順に選択します。

3. 「ユーザー名」および「パスワード」の値を設定します。

41.6.2 Dell PowerEdge Linuxホストでのハードウェアの監視の有効化

Enterprise ManagerではDell PowerEdge Linuxホストのハードウェアのみを監視することができます。Dell PowerEdge Linuxホストのハードウェア監視を有効にするには、次の手順を実行します。

1. Dell FTPサイト(http://ftp.dell.com/sysman/)にアクセスして、使用しているLinux OSに対応する最新のDell OpenManage Server Administrator (OMSA)ソフトウェアをダウンロードします。
注意: このリンクはこのヘルプの作成時には正確でした。リンクが無効になっている場合は、Dellのサポートに連絡してください。

最新のOMSAソフトウェアを識別するには、次の手順を実行します。

- Webサイトで最新のom??_lnx_managed_system*.gzファイルを検索します。

- 2004年6月13日時点での最新バージョンは、次のとおりです。
http://ftp.dell.com/sysman/om38_lnx_managed_system_A01.tar.gz

2. Dellの指示に従ってソフトウェアをインストールします。

3. 次の手順を実行してインストールが成功したことを確認します。

- snmpデーモンが起動され実行していることを確認します。
% ps -ef | grep snmpd

- 次のコマンドを実行してエラーが発生しないことを確認します。
% /usr/bin/omreport about

% /usr/bin/omreport system version

4. Dell OpenManage Server AdministratorのWebサイトが起動されて実行していることを調べ、Dell OMSAソフトウェアが正常に作動していることを確認します。

- Webブラウザを使用して、URL https://target_hostname:1311にアクセスします。

- オペレーティング・システムのアカウントを使用してログインします。ログインに成功しWebサイトでのナビゲートが可能なことを確認します。

5. Linuxホストで実行しているSNMPデーモンのSNMPコミュニティ文字列がpublicでない場合、次の手順を実行してEnterprise ManagerでSNMPコミュニティ文字列のプロパティを設定します。

1. Enterprise Manager Cloud Controlにログインします。

2. 特定のホストのホームページにナビゲートします。

3. 「ホスト」メニューから「ターゲット設定」、「監視構成」の順に選択します。

4. このページでSNMPコミュニティ文字列のプロパティを正しい値に設定します。

6. ホストで管理エージェントを再起動します。
% login into host as the owner account of emagent software

% emctl stop agent

% emctl start agent

7. 注意: 管理エージェントを起動する前にDell OMSAソフトウェアが正常に機能していた場合、次の手順は必要ありません。
次の手順を実行して、ハードウェアの監視が正常に機能していることを確認します。

1. Enterprise Manager Cloud Controlにログインします。

2. 特定のホストのホームページにナビゲートします。

3. 「ホスト」メニューから「監視」、「すべてのメトリック」の順に選択します。

4. このページに、メトリック(ファン、メモリー・デバイス、PCIデバイス、電源装置、プロセッサ、リモート・アクセス・カード、システムBIOS、温度)が表示されていることを確認します。

5. 前の手順に示したメトリックのいずれかをクリックすると、そのメトリック・データのページにナビゲートでき、Enterprise Managerがフェッチできるデータを表示できます。

41.6.3 ホスト構成の追加および編集

ホスト構成の追加ページでは、/etc/hostsファイルにホストを追加できます。/etc/hostsファイルにホストを追加するとき、Enterprise Managerで、ホスト名はIPアドレスに変更されます。多くの場合、IPアドレスよりホスト名の方が記憶するのが簡単です。

ホスト構成の追加ページでは、次の操作を実行できます。

- ホストのIPアドレスとホスト名との関連付け

- ホストに関連した別名の追加、削除または変更

注意: 変更は「OK」をクリックすると、有効になります。

ホスト構成を編集する場合、次を行うことができます。

- ホスト名の変更

- ホストに関連する別名の追加、削除または変更

注意: 変更は「OK」をクリックすると、すぐに有効になります。

第IX部

パッチ管理

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

- 第42章「ソフトウェアのデプロイのパッチ適用」

- 第43章「Linuxホストへのパッチ適用」

42 ソフトウェア・デプロイメントへのパッチ適用

パッチ適用は、製品ライフサイクルの重要フェーズの1つで、ソフトウェア製品をバグ修正で常に更新できます。オラクル社では、製品保守を支援するため、様々な種類のパッチを定期的にリリースしています。しかし、パッチ適用は、複雑でリスクが伴い、多くの時間を必要とし、停止時間も含まれるため、以前からずっとライフサイクルで最も難易度の高いフェーズでした。様々な方法でパッチを特定し、データベースにパッチを適用できますが、残念ながら課題は変わらず同じままです。

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)の新しいパッチ管理ソリューションでこれらのパッチ管理の課題に対処する方法について説明します。この章の具体的な内容は次のとおりです。

- 新しいパッチ管理ソリューションの概要

- パッチ適用のインフラストラクチャの設定

- 適用するパッチの特定

- パッチの適用

- パッチ適用に関する問題の診断および解決

- その他の実行可能パッチ適用タスク

- エンドツーエンド・ユースケース: データ・センターのパッチ適用

- サービス・プールとしてのデータベースのパッチ適用

42.1 新しいパッチ管理ソリューションの概要

この項では、次の項目について説明します。

- 現在のパッチ管理における課題の概要

- 新しいパッチ管理ソリューションについて

- パッチ計画の概要

- パッチ・テンプレートの概要

- パッチ適用にサポートされているターゲット、リリースおよびデプロイメント・プロシージャ

- サポートされているパッチ適用モードの概要

- パッチ適用ワークフローの理解

42.1.1 現在のパッチ管理における課題の概要

Cloud Controlによって提供される新しいパッチ管理ソリューションを理解する前に、データベースへのパッチ適用に現在使用している一部のツールと、それらのツールを使用しているときに発生する可能性がある課題について時間をとって確認してください(表42-1)。

表42-1 現在のパッチ管理ツールおよび課題

方法

説明

課題

OPatch

Oracle Database、管理エージェント、SOAなどのOracle製品とともにインストールされるOracle固有のツール。

- 公開するパッチの特定が難しい

- 一度に1つのOracleホームにしかパッチを適用できない

- パッチ適用前およびパッチ適用後のスクリプト処理に対して提供されるサポートに制限がある

カスタム・スクリプト

OPatch、SQLPlusなどに基づいて開発されたユーザー作成のスクリプト。

- 公開するパッチの特定が難しい

- 単一サーバーでのみ使用可能

- 新しいバージョンおよび構成のニーズを満たすのにかなりの保守オーバーヘッドが必要

デプロイメント・プロシージャ

パッチ適用操作を自動化するためにCloud Controlによって提供されるデフォルトのプロシージャ

- 選択するデプロイメント・プロシージャについて混乱

- デプロイメント・プロシージャで選択したパッチおよびターゲットの検証範囲に制限がある

- ローリング・モードとパラレル・モードでのパッチ適用にデプロイメント・プロシージャが異なる

- パッチの競合の処理が難しい

42.1.2 新しいパッチ管理ソリューションについて

Cloud Controlでは、停止時間が最小限でこれまでになく簡単に使用できる大幅に改善されたパッチ管理ソリューションを使用することにより、第42.1.1項で説明されている課題に対処しています。新しいパッチ管理ソリューションには次の利点があります。

- パッチ適用フローがMy Oracle Support (MOS)と統合されたため、推奨の確認、パッチの検索、パッチの公開をすべて同じユーザー・インタフェースを使用して実行できます。
ただし、Cloud Controlは、いずれのデータもMOSにアップロードしません。MOSを使用するのは、最新の更新をダウンロードする場合のみです。

- デプロイメント・プロシージャの自動選択やパッチ競合の分析など、パッチ計画を使用してパッチ適用ワークフローの完全なエンドツーエンド編成。このため、必要な手動作業が最小限になります。パッチ計画の詳細は、第42.1.3項を参照してください。

- デザイナとオペレータ間の責任の分担が明確。デザイナはパッチ計画の作成、テスト・システムでのテストおよびパッチ・テンプレートとしての保存に集中できます。オペレータは、本番システムでパッチを公開するためにテンプレートからパッチ計画を作成することに集中できます。

- 環境の適用性、パッチ計画の検証、検証による問題を解決するパッチの自動受信についてパッチを簡単に確認できます。

- 正常に分析されたまたはデプロイ可能なパッチ計画をパッチ・テンプレートとして保存できます。テンプレートには、ソース・パッチ計画から保存された事前決定済の一連のパッチおよびデプロイメント・オプションが含まれます。

- スタンドアロン(単一インスタンス)のデータベース・ターゲット、Oracle Real Application Clusters (RAC)ターゲット、Oracle Data GuardターゲットおよびOracle Grid Infrastructureターゲット(Oracle Exadataの一部かどうかにはかかわりません)用のホーム外パッチ適用。

注意:

- Oracle Exadataの一部ではないOracle RACターゲットおよびOracle Grid Infrastructureターゲットへのホーム外パッチ適用は、Oracle Databaseプラグイン用に12.1.0.5 Enterprise Managerがデプロイされている場合のみサポートされています。

- Oracle Data Guardターゲットへのホーム外パッチ適用は、Oracle Databaseプラグイン用に12.1.0.6 Enterprise Managerがデプロイされている場合のみサポートされています。

- オフラインとオンラインの両モードで、ローリングやパラレルなどのフレキシブルなパッチ適用オプション。

図42-1に、Cloud Controlコンソールから「パッチと更新版」画面へのアクセス方法を示します。

図42-1 「パッチと更新版」画面へのアクセス

42.1.3 パッチ計画の概要

この項では、次の項目について説明します。

- パッチ計画について

- パッチ計画のタイプについて

- 計画の作成ウィザードについて

42.1.3.1 パッチ計画について

パッチ計画は、1つ以上のターゲットに1グループとして適用するパッチの統合リストを作成するのに役立ちます。パッチ計画では、構成変更管理プロセスの主要ステップに対応する状態(ステータス)を保持します。表示権限のある管理者またはロールがパッチ計画にアクセスできます。

パッチ計画では、次のパッチ・タイプをサポートします。

- パッチ・セット

注意:

- Oracle Database 10gリリース2 (10.2.0.x)およびOracle Database 11gリリース1 (11.1.0.x)用のパッチ・セットが使用できます。パッチ計画を使用してこれらのパッチ・セットを適用できます。ただし、Oracle Database 11gリリース2 (11.2.0.x)用のパッチ・セットは完全インストール(フル・リリース)であり、データベース・アップグレード機能を使用して適用する必要があります。データベース・アップグレード機能はホーム外パッチ適用方式に従います。

- パッチ・セットは、Oracle WebLogic Serverターゲット、Oracle Fusion ApplicationターゲットおよびOracle SOAインフラストラクチャ・ターゲットではサポートされません。

- パッチ(個別)

- 個別パッチ: 必要に応じて提供される単一のバグ修正、またはバグ修正のコレクションが含まれます。また、顧客固有のセキュリティ・バグ修正用の個別パッチも含まれます。

- 診断パッチ: 単一の修正またはバグ修正のコレクションの診断または検証を支援します。

- パッチ・セット更新(PSU): 特定の製品またはコンポーネント用の、影響が大きくリスクが低い証明された修正のコレクションが含まれます。

- クリティカル・パッチ・アップデート(CPU): セキュリティ・バグ修正のコレクションが含まれます。

注意:
パッチ・セットとパッチの両方を1つのパッチ・プランに追加することはできません。かわりに、パッチ・セットに対して1つのパッチ計画、パッチに対して別のパッチ計画を作成できます。

計画のターゲットにパッチを追加できるのは、パッチのリリースとプラットフォームが追加対象のターゲットと同一の場合のみです。追加するパッチの製品が、パッチの追加対象のターゲットに関連付けられている製品と異なる場合は、警告が表示されます。警告は表示されますが、計画にパッチを追加できます。

計画には、任意のターゲットに対する任意のパッチを含めることができます。また、計画ではOracle Database、Fusion Middleware、Cloud Controlのパッチを各環境と比較して検証し、インストールされたパッチに競合がないかどうかをチェックします。

パッチ計画は、追加するパッチに応じて、パッチの適用に使用する適切なデプロイメント・プロシージャを自動的に選択します。各種データベース・ターゲット・タイプに使用するパッチ適用デプロイメント・プロシージャの詳細は、表42-2を参照してください。

注意:

- パッチ計画は、現在ハードウェアまたはオペレーティング・システム・パッチ適用では利用できません。

- 表示権限のある管理者またはロールがパッチ計画にアクセスできます。パッチ計画およびパッチ・テンプレートに必要なロールおよび権限の詳細は、第42.2.2項を参照してください。

42.1.3.2 パッチ計画のタイプについて

この項では、パッチ計画のタイプについて説明します。内容は次のとおりです。

デプロイ可能な計画とデプロイ不可能な計画

パッチ計画は、デプロイできてもデプロイできなくてもかまいません。

- パッチ計画は次のような場合にデプロイできます。

- 同じタイプのパッチ(同種パッチ)のみが含まれている場合。

- パッチ適用がサポートされ、構成が似ており、同じ製品タイプ、プラットフォームおよびバージョンのターゲット(同種ターゲット)が含まれている場合。

- 計画内でその他の競合がない場合。

- デプロイ可能な計画について示した条件のいずれかを満たしていないパッチ計画が、デプロイ不可能な計画です。パッチ計画をデプロイできない場合は、パッチ計画を使用してパッチをデプロイすることはできませんが、一部の分析やチェックの実行、パッチのダウンロード、それらのパッチの手動での適用は可能です。

エラー計画

パッチ計画にOracle Management Agent (Management Agent)のターゲットとパッチが含まれている場合は、一部のManagement Agentで分析が失敗し、パッチ計画が2つの計画に分割されます。分析が成功したManagement Agentとそれに関連付けられたパッチは、元の計画に保持されます。失敗したターゲットとそれに関連付けられたパッチは、新しいエラー計画に移動されます。デプロイメント・オプションもエラー計画にコピーされます。エラー計画には、パッチと更新版ページからアクセスできます。

42.1.3.3 計画の作成ウィザードについて

図42-2に、パッチ計画の作成、表示および変更ができる計画の作成ウィザードを示します。

図42-2 計画の作成ウィザード

ウィザードには次の画面があります。

画面1: 計画の情報

一意の計画名、予定デプロイメント日、簡単な説明など、計画に関する基本情報を指定できます。また、パッチ計画にアクセスできる管理者またはロールを追加できます。

画面2: パッチ

パッチがパッチ計画にすでに含まれているかを確認し、パッチを計画に手動で追加し、パッチを適用する必要があるターゲットを関連付けることができます。

画面3: デプロイメント・オプション

ニーズに合ったデプロイメント・オプションを使用してパッチ計画を構成できます。このステップはすべてのターゲット・タイプに共通ですが、このステップで表示されるデプロイメント・オプションは、パッチ計画で選択されているターゲット・タイプによって異なります。

すべてのターゲット・タイプで、パッチのデプロイにカスタマイズされたデプロイメント・プロシージャを選択し、使用される資格証明を指定できます。データベース・ターゲットでは、パッチの格納にデフォルト以外のステージングの場所を選択でき、パッチがすでにステージングされている場合はステージング・プロセスをスキップできます。スタンドアロン(単一インスタンス)のデータベース・ターゲット、Oracle RACデータベース・ターゲット、Oracle Data GuardターゲットおよびOracle Grid Infrastructureターゲット(Oracle Exadataの一部かどうかにはかかわりません)では、ホーム外パッチ適用とホーム内パッチ適用のどちらかを選択できます。Oracle RACデータベース・ターゲットおよびOracle Grid Infrastructureのターゲットでは、システムの停止時間を制御するために、ローリング・モードまたはパラレル・モードのどちらでパッチを適用するかを選択できます。

画面4: 検証

パッチ計画を検証し、問題なくパッチを公開できるかどうかを判断できます。基本的に、Oracleのパッチ情報、システム上のパッチのインベントリ(Configuration Managerで収集)および候補パッチの情報を使用して、次のチェックを実行できます。

- パッチ競合チェック

- パッチ計画に追加されたパッチとOracleホームにすでに存在するパッチとの競合

- パッチ計画内のパッチ間の競合

- ターゲットの健全性チェック

- ターゲットのステータスおよび構成チェック

- OPatchおよびOUIチェック

- インベントリの健全性チェック(ロック、アクセスなど)

- ハード・ディスク領域チェック

- クラスタ検証チェック(cluvfy、srvctl config)

- SQLPlusチェック(サンプルSQL付き)

注意:
Oracle WebLogicターゲットの場合、OPatchおよびOUIチェックのかわりに、SmartUpdateバージョン・チェックを実行する必要があります。

競合のチェックに加えて、計画にリストされたパッチ間のパッチ競合のチェックもできます。

画面5: レビューおよびデプロイ

パッチ計画に指定した詳細を確認し、計画をデプロイできます。また、実行した処理ですべてのターゲットがどんな影響を受けたか把握できるように、影響を受けたすべてのターゲットを確認できます。

42.1.4 パッチ・テンプレートの概要

この項では、次の項目について説明します。

- パッチ・テンプレートについて

- テンプレートの編集ウィザードについて

42.1.4.1 パッチ・テンプレートについて

パッチ・テンプレートは、パッチ管理ソリューションのもう1つの重要な側面です。パッチ・テンプレートは、正常に分析されたまたはデプロイ可能な既存のパッチ計画に基づいて事前に設計され、ターゲットが選択されていない計画を作成するのに役立ちます。パッチ・テンプレートには、ソース・パッチ計画から保存された事前決定済の一連のパッチおよびデプロイメント・オプションが含まれ、まったく新しいターゲットのセットを選択できます。

このように、パッチ・デザイナは、一連のパッチでパッチ計画を作成して自分の環境でテストし、正常に分析されたパッチ計画をパッチ・テンプレートとして保存してパッチ・オペレータに公開できます。パッチ・オペレータは、テンプレートからパッチ計画を作成して別のターゲットのセットを追加し、再帰的方法でパッチを本番環境に公開できます。

このように、新しいパッチ計画の作成に必要な時間と作業を減らし、パッチ・デザイナは正常に分析され、承認された計画のみをパッチ・オペレータに公開します。

注意:
パッチ・テンプレートの作成権限とテンプレートの作成に使用されるパッチ計画の表示権限を持っている管理者またはロールが、パッチ・テンプレートを作成できます。

42.1.4.2 テンプレートの編集ウィザードについて

図42-3に、パッチ計画テンプレートの内容を表示して、説明を編集できるテンプレートの編集ウィザードを示します。

図42-3 テンプレートの編集ウィザード

パッチ計画テンプレートを表示または編集するには、テンプレートの編集ウィザードを開きます。ウィザードには次の画面があります。

画面1: 計画の情報

テンプレートに関する一般情報を表示し、説明やデプロイメント日を編集できます。

画面2: パッチ

パッチ計画テンプレートに含まれているパッチのリストを表示できます。ここにリストされるパッチは、テンプレートを作成するために選択したソース・パッチ計画からコピーされたパッチです。

画面3: デプロイメント・オプション

パッチ計画テンプレートで構成されているデプロイメント・オプションを表示できます。

42.1.5 パッチ適用にサポートされているターゲット、リリースおよびデプロイメント・プロシージャ

表42-2に、新しいパッチ管理ソリューションを使用して異なるプラットフォームにパッチを適用できるターゲットおよびそのリリースと、ターゲット・タイプに応じてパッチ計画が自動的に選択するデフォルトのデプロイメント・プロシージャを示します。デプロイメント・プロシージャは、パッチ計画でのみサポートされます。「デプロイメント・プロシージャ・マネージャ」ページで公開されますが、単独で選択して実行することはできません。常にパッチ計画を作成して実行する必要があります。

注意:
Oracle WebLogic Serverターゲットにパッチを適用する前に、次の前提条件を満たす必要があります。

1. OMSにEnterprise Manager for My Oracle Support 12.1.0.5プラグインが適用されていることを確認します。これは、複数OMS環境ではすべてのOMSインスタンスに適用する必要があります。

2. Oracle WebLogic Serverターゲットを監視するOMSおよび管理エージェントに、Enterprise Manager for Oracle Fusion Middleware 12.1.0.4プラグインが適用されていることを確認します。

表42-2 パッチ適用にサポートされているターゲットおよびリリース

サポートされているターゲット・タイプ

サポートされているターゲットおよびリリース

サポートされているプラットフォーム

サポートされているデフォルトのデプロイメント・プロシージャ

Oracle Database

Oracle Database (スタンドアロン) 10gリリース1から11gリリース2

すべてのプラットフォーム

Oracleデータベースへのパッチ適用

Oracle Automated Storage Management (Oracle ASM) 10gリリース1から11gリリース2

すべてのプラットフォーム

スタンドアロンOracle ASMへのパッチ適用

Oracle Real Application Cluster (Oracle RAC) 10gリリース1から11gリリース2

すべてのプラットフォーム

- Oracle RACデータベースへのパッチ適用(ローリング)

- Oracle RACデータベースへのパッチ適用(すべてのノード)

Oracle RAC One Node 10gリリース1から11gリリース2

すべてのプラットフォーム

Oracle RACデータベースへのパッチ適用 - パラレル

Oracle Exadata RAC Databases脚注 1 11gリリース2 (11.2.0.1、11.2.0.2および11.2.0.3)

すべてのプラットフォーム

デフォルトのデプロイメント・プロシージャはありません。動的に作成されます。

Oracle Restart 10gリリース1から11gリリース2

すべてのプラットフォーム

Oracle Restartへのパッチ適用

Oracle Clusterware 10gリリース1から11gリリース1

Microsoft Windowsを除くすべてのプラットフォーム

- Oracleクラスタウェアへのパッチ適用(ローリング)

- Oracleクラスタウェアへのパッチ適用(すべてのノード)

Oracle Grid Infrastructure 11gリリース2

Microsoft Windowsを除くすべてのプラットフォーム

- Oracleクラスタウェアへのパッチ適用(ローリング)

- Oracleクラスタウェアへのパッチ適用(すべてのノード)

Oracle Database 12c Multitenant Database (コンテナ・データベースおよびプラガブル・データベース)

すべてのプラットフォーム

デフォルトのデプロイメント・プロシージャはありません。内部的に起動されます。

Oracle WebLogic Server

Oracle WebLogic Server 10g リリース3 (10.3.1)、(10.3.2)、(10.3.3)、(10.3.4)、(10.3.5)、(10.3.6)および12c リリース1 (12.1.1)、(12.1.2)、(12.1.3)

すべてのプラットフォーム

- パラレル・モードでOracle WebLogic Serverにパッチを適用

- ローリング・モードでOracle WebLogic Serverにパッチを適用

Oracle Fusion Applications

Oracle Fusion Applications 11gリリース1 (11.1.1.5.1)および(11.1.2.0.0) (RUP1)

すべてのプラットフォーム

Oracle Fusion Applicationsのパッチ適用

Oracle Application Server

Oracle Application Server 10gリリース1

すべてのプラットフォーム

アプリケーション・サーバーへのパッチ適用

Oracle SOAインフラストラクチャ

Oracle SOAインフラストラクチャ 11g リリース1 (11.1.1.1.0 - 11.1.1.7.0)および12c リリース1 (12.1.3.0.0)

すべてのプラットフォーム

- パラレル・モードでOracle SOAインフラストラクチャにパッチを適用

- ローリング・モードでOracle SOAインフラストラクチャにパッチを適用

Oracle Identity Management (Oracle Access Management ServerおよびOracle Identity Management Serverターゲットのみサポートされます)

Oracle Identity Management 11gリリース2 (11.1.2.2.0)

すべてのプラットフォーム

パッチ適用IDM

Oracle Siebel (Siebel ServerおよびSiebel Gateway Serverターゲットのみサポートされます)

Oracle Siebel 8.1.1.9、8.1.1.10、8.1.1.11および8.2.x

すべてのプラットフォーム

パッチ適用Siebelターゲット

脚注 1 Oracle Exadata Database Machine推奨のバンドル・パッチに対して排他的にテストされます。

注意:

- Oracle Data Guardで構成されたプライマリ・データベースとスタンバイ・データベースにもパッチを適用できます。これらのターゲットにパッチを適用する方法の詳細は、第42.4.9項を参照してください。

- Oracleデータベース・ホーム所有者と異なるユーザーによってリスナーが起動されたOracleデータベースのパッチ適用はサポートされていません。そのようなデータベースにパッチを適用するには、データベース・リスナーを停止し、データベース・ホーム所有者として再起動してから、パッチ計画を使用して必要なパッチを適用します。

42.1.6 サポートされているパッチ適用モードの概要

この項では、次のパッチ適用モードについて説明します。

- オンライン・モードおよびオフライン・モードでのパッチ適用の概要

- インプレース・モードおよびホーム外モードでのパッチ適用の概要

- ローリング・モードおよびパラレル・モードでのパッチ適用の概要

42.1.6.1 オンライン・モードおよびオフライン・モードでのパッチ適用の概要

パッチ適用のオンライン・モードとオフライン・モードのどちらにするか柔軟に選択できます。

オンライン・モード

オンライン・モードは、Cloud Controlがインターネット接続を使用してMy Oracle Support (MOS)に接続できる場合に便利です。このモードを使用すると、適用するパッチについての推奨を確認し、パッチを直接MOSで手動で検索してパッチ計画に追加できます。さらに、コミュニティ情報、ナレッジ記事、サービス・リクエストなどにアクセスできます。また、直接MOSからマージ・マッチとのパッチ競合を自動的に解決することもできます。

Cloud Controlは、いずれのデータもMOSにアップロードしないことに注意してください。MOSを使用するのは、最新の更新をダウンロードする場合のみです。

オフライン・モード

オフライン・モードは、Cloud ControlがMy Oracle Supportに接続できない場合に便利です。このモードを使用すると、ソフトウェア・ライブラリに手動でアップロードされたパッチを検索し、パッチ計画に追加できます。オフライン・モードでは、次の操作を実行できません。

- My Oracle Supportからのパッチの検索およびダウンロード

- パッチに関する追加情報の表示

- コミュニティ情報、ナレッジ記事、サービス・リクエストへのアクセス

- 関連アクティビティ・リージョンの表示

注意:
デフォルトでは、パッチ適用モードはオンラインに設定されています。モードをオフラインに切り替えるには、「設定」メニューから、「プロビジョニングとパッチ適用」を選択してから、「オフライン・パッチ」を選択します。「接続」については、「オフライン」を選択します。

42.1.6.2 インプレース・モードおよびホーム外モードでのパッチ適用の概要

インプレース・モードとホーム外モードのパッチ適用を選択できる柔軟性があります。

インプレース・モード

インプレース・モードのパッチ適用は、データベース・ホームに直接パッチを適用するパッチ適用メカニズムです。このモードでは、パッチの適用前に、そのデータベース・ホームから実行されているすべてのデータベース・インスタンスを停止します。つまり、停止時間があります。パッチの適用後に、すべてのデータベース・インスタンスを再起動します。すべてのデータベース・インスタンスに同じ方法でパッチが適用されます。このモードでは、パッチを適用したOracleホームは元のデータベース・ホームであり、コピーではないため、問題がある場合はリカバリの時間が長くなります。

図42-4に、Oracleホームから実行されている複数のデータベース・インスタンスがインプレース・パッチ適用モードでどのようにパッチが適用されるかを図示します。

図42-4 インプレース・モードのパッチ適用

ホーム外モード

ホーム外モードのパッチ適用は、既存のデータベース・ホームをクローニングして、元のホームではなくクローニングしたホームにパッチを適用するパッチ適用メカニズムです。クローニングしたホームにパッチを適用すると、データベース・インスタンスを移行してクローニングしたホームから実行できます。これによって停止時間が最小限になることが保証されます。

重要:

- ホーム外パッチ適用は、スタンドアロン(単一インスタンス)のデータベース・ターゲット、Oracle RACデータベース・ターゲット、Oracle Data GuardターゲットおよびOracle Grid Infrastructureターゲット(Oracle Exadataの一部かどうかにはかかわりません)でサポートされています。
Oracle Exadataの一部ではないOracle RACデータベース・ターゲットおよびOracle Grid Infrastructureターゲットにホーム外モードでパッチを適用するには、Oracle Databaseプラグイン用に12.1.0.5 Enterprise Managerが必要です。ホーム外モードでOracle Data Guardターゲットにパッチ適用するには、Oracle Databaseプラググイン用の12.1.0.6 Enterprise Managerが必要です。

- クローニングされたホームに、SQL文を含む(パッチ計画に追加されていない)特定の追加パッチが含まれていると、データベース・インスタンスをクローニングされたホームに移行する際、それらのパッチに対するSQL文は自動的に実行されません。これらのパッチでは、SQL文を手動で実行する必要があります。

データベース・インスタンスの移行中、データ・センターで許容できる停止時間に応じて、すべてのインスタンスを移行するか、一部のインスタンスのみを移行するかを選択できます。あるセッションでごく少数のインスタンスのみを移行することにした場合は、次のセッションで残りを必ず移行します。このように、移行アクティビティを分割するので、データ・センターでの停止時間を制御できます。これは、Oracleホームから実行されているデータベース・インスタンスが複数ある場合、特に便利です。

注意:
計画の作成ウィザードを使用してパッチ計画を作成する間に、移行するデータベース・インスタンスを選択します。選択したデータベース・インスタンスは、パッチ計画がデプロイ状態にあるときに移行されます。移行に少数のデータベース・インスタンスのみを選択した場合、別のパッチ計画を作成して他のインスタンスを移行します。「デプロイメント・オプション」ページで、既存のホームを選択し、移行が必要な他のデータベース・インスタンスを選択します。

停止時間が最小で問題がある場合のリカバリが簡単であるため、いつでもホーム外パッチ適用をお薦めします。クローン・ホームに問題がある場合、必ず元のデータベース・ホームに戻ることができます。

注意:
ホーム外パッチ適用モードで、Oracle RACターゲット、Oracle単一インスタンス・データベース・ターゲットまたはOracle Grid Infrastructureターゲット(Oracle Exadataの一部かどうかにはかかわりません)にパッチを適用した場合、計画の作成ウィザードから元のホームに直接スイッチバックできます。このウィザードには、スイッチバック操作を実行できる「スイッチバック」ボタンがあります。ただし、他のターゲット・タイプにはこの操作は実行できません。

図42-5に、Oracleホームから実行されている複数のデータベース・インスタンスがホーム外パッチ適用モードでどのようにパッチが適用されるかを図示します。

図42-5 ホーム外モードのパッチ適用

注意:
また、必要なパッチを持つ新しいOracleホームを取得するには、プロビジョニング・デプロイメント・プロシージャを使用して(必要なパッチを持つ)ソフトウェア・イメージから直接プロビジョニングし、分析およびパッチ適用後ステップにパッチ計画を使用します。この実行方法の詳細は、第42.4.3項を参照してください。

42.1.6.3 ローリング・モードおよびパラレル・モードでのパッチ適用の概要

Oracle Real Application Cluster (Oracle RAC)ターゲット、Oracle Grid Infrastructureターゲット(Oracle Exadataの一部かどうかにはかかわりません)、Oracle Data Guardターゲット、Oracle WebLogic Serverターゲット、Oracle Fusion ApplicationターゲットまたはOracle SOAインフラストラクチャ・ターゲットにパッチを適用する場合、ローリング・モードまたはパラレル・モードのどちらでクラスタのインスタンスにパッチを適用するかを選択できます。

ローリング・モード

ローリング・モードは、クラスタのノードに個別に(1つずつ)パッチを適用するパッチ適用方法です。たとえば、5つのノードがあるクラスタウェア・ターゲットにパッチを適用する場合、1つ目のノードを停止し、パッチを適用してから再起動します。その後、すべてのノードに正常にパッチが適用されるまでプロセスは次のノードにロールオーバーされます。

注意:
パッチのReadMeには、ローリング・モードを使用してパッチを適用できるかどうかについて明記されています。そのため、このモードを使用するのは、ReadMeにそれが記載されている場合のみです。

図42-6に、ローリング・モードの使用時に、2つのノードがあるOracle RACターゲットにどのようにパッチが適用されるかを図示します。

図42-6 ローリング・モードのパッチ適用

パラレル・モード

パラレル・モードは、すべてのノードに一度に(まとめて)パッチを適用するパッチ適用方法です。この方法では、すべてのノードを停止し、同時にすべてのノードにパッチを適用します。

図42-7に、パラレル・モードの使用時に、2つのノードがあるOracle RACターゲットにどのようにパッチが適用されるかを図示します。

図42-7 パラレル・モードのパッチ適用

42.1.7 パッチ適用ワークフローの理解

次の図に、Cloud Controlコンソールの統合された機能によって提供されるパッチ管理ソリューションのワークフロー全体を示します。

ステップ

ステップ名

説明

参照リンク

ステップ1

インフラストラクチャの設定

パッチを公開するための前提条件を満たしてインフラストラクチャを設定します。基本的に、パッチ計画およびパッチ・テンプレートを作成するための管理者ロールを作成し、他の必須および任意の前提条件を満たしてオンラインまたはオフラインのパッチ適用設定を行います。

第42.2項「パッチ適用のインフラストラクチャの設定」

ステップ2

パッチの特定

適用するパッチに関する推奨を表示し、適用するパッチを特定します。(無数の顧客からの)コミュニティ情報にアクセスします。

第42.3項「適用するパッチの特定」

ステップ3

パッチの適用

パッチとそれに関連付けられたターゲットでパッチ計画を作成して前提条件チェックを実行し、競合についてパッチを分析して問題を解決した後、正常に分析された計画をパッチ・テンプレートとして保存します。次に、パッチ・テンプレートから新しいパッチ計画を作成し、それを使用してパッチを環境にデプロイします。

42.4項「パッチの適用」

42.2 パッチ適用のインフラストラクチャの設定

この項では、パッチ適用のインフラストラクチャの設定方法について説明します。パッチの公開を開始する前にこれらの前提条件を満たしてください。

この項は主に、いつでもパッチを公開できるようにインフラストラクチャを維持するパッチ管理者またはパッチ・デザイナに対するものです。これは、パッチを適用する方法(オンラインまたはオフライン)を決定している場合、ほとんど1回かぎりのタスクです。

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

- パッチ適用のためのインフラストラクチャの基本要件

- パッチ適用に必要なロールを持つ管理者の作成

- オンライン・モードでパッチを適用するためのインフラストラクチャの設定(MOSに接続済)

- オフライン・モードでパッチを適用するためのインフラストラクチャの設定(MOSに未接続)

- 環境の分析およびターゲットにパッチを適用できるかどうかの確認

42.2.1 パッチ適用のためのインフラストラクチャの基本要件

第2章の説明に従って、インフラストラクチャの基本要件を満たしてください。この章では、必須と任意の両方の要件について説明しています。

注意:
パッチを適用するターゲットをMicrosoft Windowsホストにデプロイする場合、ターゲットのパッチを適用する前にCygwinがターゲット・ホストにインストールされていることを確認する必要があります。
ホストへのCygwinのインストール方法の詳細は、『Enterprise Manager Cloud Control基本インストレーション・ガイド』を参照してください。

42.2.2 パッチ適用に必要なロールを持つ管理者の作成

表42-3に、パッチ計画およびパッチ・テンプレートの使用に必要なロールおよび最小限の権限を示します。これらのロールは、Cloud Controlで使用できるデフォルトのロールです。作成する必要はありませんが、これらのロールに基づいて管理者を明示的に作成する必要があります。詳細は、2.4項を参照してください。

表42-3 パッチ計画およびパッチ・テンプレートを使用するためのロールおよび権限

ロール

パッチ計画の範囲

パッチ・テンプレートの範囲

パッチ計画およびパッチ・テンプレートの権限

ターゲット権限

リソース権限

実装の推奨

パッチ管理者

作成、表示、変更、削除

作成、表示、変更、削除

FULL_ANY_PATCH_PLAN

FULL_ANY_PLAN_TEMPLATE

GRANT_PRIV_PATCH_PLAN

操作の任意のターゲット

(あるいは、パッチを適用する特定のターゲットを選択し、それにオペレータ権限を付与できます。)

- リソース・タイプ: デプロイメント・プロシージャ
権限: 作成

- リソース・タイプ: ジョブ・システム
権限: 作成

- リソース・タイプ: ソフトウェア・ライブラリ・エンティティ
権限: 任意のソフトウェア・ライブラリ・エンティティの管理

パッチ・デザイナおよびパッチ・オペレータの各ロールを作成および管理する場合は、必須。

SUPER ADMINまたはSYSMANとしてこれらのロールを直接作成することもできます。

パッチ・デザイナ

作成、表示

作成、表示

FULL_PATCH_PLAN

FULL_PLAN_TEMPLATE

- 同上 -

- 同上 -

アクセス権を付与し、制限もある場合は、必須。

あるいは、パッチ・デザイナ・ロールを持つEMユーザーを作成できます。

パッチ・オペレータ

作成

表示

CREATE_PATCH_PLAN

VIEW_ANY_PLAN_TEMPLATE

- 同上 -

- 同上 -

- 同上 -

42.2.3 オンライン・モードでパッチを適用するためのインフラストラクチャの設定(MOSに接続済)

Cloud Controlがオンラインのとき(MOSに接続しているとき)にターゲットへのパッチ適用を選択した場合、次の設定要件を満たしてください。

- パッチ適用のためのオンライン・モードの有効化

- My Oracle Support用のプロキシ詳細の登録

42.2.3.1 パッチ適用のためのオンライン・モードの有効化

注意:

- これは、Cloud Controlでのパッチ適用に対するデフォルト・モードです。そのため、初めにこの設定を手動で設定する必要はありません。ただし、ある理由でオフライン・モードに設定し、オンライン・モードにリセットする場合は、この項に記載されている手順に従ってください。

- Cloud Controlは、いずれのデータもMOSにアップロードしません。MOSを使用するのは、最新の更新をダウンロードする場合のみです。

オンライン・モードでターゲットにパッチを適用するには、Cloud Controlの接続設定を「オンライン」モードに設定する必要があります。これを実行するには、パッチ管理者ロールを持つユーザーとしてログインし、次の手順に従います。

1. 「設定」メニューから、「プロビジョニングとパッチ適用」を選択し、「オフライン・パッチ」を選択します。

2. 「接続」については、「オンライン」を選択します。

42.2.3.2 My Oracle Support用のプロキシ詳細の登録

オンライン・モードでは、Cloud ControlはMOSに接続し、パッチ、パッチ・セットおよびARUシード・データ(製品、プラットフォーム、リリース、コンポーネント、動作保証詳細、パッチ推奨など)をダウンロードします。このために、Cloud Controlでは、OMSホストで設定したインターネット接続を使用してMOSに接続します。ただし、環境でプロキシ・サーバーを設定している場合は、プロキシの詳細を登録する必要があります。MOSの「プロキシ設定」ページを使用して、My Oracle Support用のプロキシ詳細を登録できます。

注意:
Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)以降、My Oracle Supportからsupport.oracle.comに直接アクセスするようになりました。これは、このURLへのネットワーク・アクセスを提供するか、My Oracle SupportにアクセスするクライアントからこのURLにプロキシ・アクセスを付与する必要があることを意味します。

My Oracle Support (MOS)用のプロキシ詳細を登録するには、次の手順を実行します。

1. 「設定」メニューから、「プロキシ設定」を選択してから、「My Oracle Support」を選択します。

2. OMSがプロキシ・サーバーを使用せずにMOSに直接接続する必要がある場合は、次の手順を実行します。

1. 「プロキシなし」を選択します。

2. 「テスト」をクリックして、OMSがMOSに直接接続できるかどうかをテストします。

3. 接続が成功した場合、「適用」をクリックしてプロキシ設定をリポジトリに保存します。

3. OMSがプロキシ・サーバーを使用してMOSに接続する必要がある場合は、次の手順を実行します。

1. 「手動プロキシ構成」を選択します。

2. 「https」にプロキシ・サーバーのホスト名を、「ポート」に適切なポート値を指定します。

3. 指定したプロキシ・サーバーがセキュリティ・レルムまたはログイン資格証明(あるいはその両方)を使用して構成されている場合、「パスワード/拡張設定」を選択してから、「レルム」、「ユーザー名」および「パスワード」に値を指定します。

4. 「テスト」をクリックして、指定したプロキシ・サーバーを使用してOMSがMOSに接続できるかどうかをテストします。

5. 接続が成功した場合、「適用」をクリックしてプロキシ設定をリポジトリに保存します。

注意:

- 設定でプロキシ・サーバーを使用している場合、aru-akam.oracle.com、ccr.oracle.com、login.oracle.com、support.oracle.comおよびupdates.oracle.comに接続できることを確認します。
Microsoftプロキシ・サーバーに基づいたNTLM (NT LAN Manager)はサポートされていません。Microsoftプロキシ・サーバーに基づいたNTLMを使用している場合、前述のサイトにアクセスできるようにするには、プロキシ・サーバーの認証されていないサイト・プロパティに前述のURLを追加します。

- MOSのプロキシ設定ページで指定したMOSプロキシ・サーバーの詳細は、複数のOMS環境内のすべてのOMSに適用されます。

42.2.4 オフライン・モードでパッチを適用するためのインフラストラクチャの設定(MOSに未接続)

Cloud Controlがオフラインのとき(My Oracle Supportに接続していないとき)にターゲットへのパッチ適用を選択した場合、次の設定要件を満たしてください。

- パッチ適用のためのオフライン・モードの有効化

- インターネット接続が可能な別のホストからのEnterprise ManagerカタログのZIPファイルのダウンロード

- インターネット接続が不可能な使用ホストからのEnterprise ManagerカタログのZIPファイルのアップロード

- Oracle Software Libraryへのパッチのアップロード

42.2.4.1 パッチ適用のためのオフライン・モードの有効化

オフライン・モードでターゲットにパッチを適用するには、Cloud Controlの接続設定を「オフライン」モードに設定する必要があります。次の手順を実行します。

1. 「設定」メニューから、「プロビジョニングとパッチ適用」を選択し、「オフライン・パッチ」を選択します。

2. 「接続」については、「オフライン」を選択します。

注意:
Cloud Controlがオフライン・モードで実行されたら、インターネット接続しているホストから最新のEnterprise Managerカタログ・ファイルをダウンロードして、そのカタログ・ファイルをローカル・ホストに転送し、管理リポジトリにアップロードする必要があります。この方法の詳細は、第42.2.4.2項および第42.2.4.3項を参照してください。

42.2.4.2 インターネット接続が可能な別のホストからのEnterprise ManagerカタログのZIPファイルのダウンロード

オフライン・モードでは、インターネット接続が可能な別のホストを使用し、em_catalog.zipファイルをMy Oracle Supportから手動でダウンロードする必要があります。次のURLを使用して、最新のカタログ・ファイルをダウンロードします。

https://updates.oracle.com/download/em_catalog.zip

最新のパッチ、手動でダウンロードする必要があるパッチなどの影響を受けるターゲットに関する情報は、カタログのZIPファイルから入手できます。

42.2.4.3 インターネット接続が不可能な使用ホストからのEnterprise ManagerカタログのZIPファイルのアップロード

前項の説明に従ってカタログのZIPファイルをダウンロードしたら、FTPまたは他のファイル転送方法を使用して、ダウンロードした最新のem_catalog.zipファイルをローカル・ホストに転送して戻します。これで、ローカル・ホストからCloud Controlにログインして、ZIPファイルをアップロードできるようになります。次の手順を実行します。

1. 「設定」メニューから、「プロビジョニングとパッチ適用」を選択し、「オフライン・パッチ」を選択します。

2. 「参照」をクリックして、最新のem_catalog.zipファイルの場所を指定します。

3. 「アップロード」をクリックして、管理リポジトリにファイルをアップロードします。
「アップロード」をクリックすると、「My Oracle Supportからのリフレッシュ」ジョブが作成され、Enterprise Managerジョブ・システムに送信されます。

42.2.4.4 Oracle Software Libraryへのパッチのアップロード

オフライン・モードでターゲットにパッチを適用する場合、ソフトウェア・ライブラリから検索、選択、パッチ計画への追加を実行できるように、パッチとそのメタデータ・ファイルがすでにソフトウェア・ライブラリに格納されている必要があります。このために、まずパッチとそのメタデータ・ファイルをMy Oracle Supportから手動でダウンロードし、次にソフトウェア・ライブラリにアップロードする必要があります。

この項では、次の項目について説明します。

My Oracle Supportからのパッチのダウンロード

My Oracle Supportからパッチとそのメタデータ・ファイルをダウンロードするには、次の手順を実行します。

1. My Oracle Support (https://support.oracle.com/)にログインし、「パッチと更新版」タブをクリックします。

2. 「パッチと更新版」ページの「パッチ検索」セクションで、検索するパッチ番号を入力し(図42-8を参照)、「検索」をクリックします。

図42-8 パッチの検索

3. 「パッチの簡易検索結果」ページで、ダウンロードするパッチのある行を選択します。「ダウンロード」をクリックします。ファイル・ダウンロードダイアログで、パッチZIPファイルの名前をクリックして、そのファイルをローカル・ホストにダウンロードします。「パッチ・メタデータのダウンロード」をクリックし、「パッチ・メタデータのダウンロード」ダイアログで「ダウンロード」をクリックしてパッチ・メタデータ・ファイルをダウンロードします。このステップについては、図42-9で説明します。

注意:
パッチのZIPファイルおよびメタデータXMLファイルを管理エージェント・ホストに転送することをお薦めします。管理エージェントは、OMSマシン上のエージェントでもターゲット・ホスト上のエージェントでもかまいません。これらのファイルは、管理エージェント・ホストからソフトウェア・ライブラリにアップロードします。

図42-9 My Oracle Supportからのパッチのダウンロード

Cloud Controlコンソールを使用したソフトウェア・ライブラリへのパッチのアップロード

このメソッドを使用すると、1回につき1つのパッチのみをアップロードできます。そのため、このメソッドは、いくつかのパッチをアップロードする必要がある場合にのみ使用してください。また、このメソッドは、アップロードするパッチのサイズが小さい場合に使用してください。

Cloud Controlコンソールを使用してパッチをソフトウェア・ライブラリにアップロードするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「保存されたパッチ」の順に選択します。

2. 「アップロード」をクリックします。

3. 「パッチZIPファイル」で、ローカル・ホストにダウンロードするパッチZIPファイルの場所を指定します。ダウンロードするパッチZIPファイルにPatchSearch.xmlファイル(パッチID、製品、プラットフォーム、言語などのパッチ・メタデータ情報を含むファイル)が含まれている場合、「パッチ・メタデータ」に値を指定する必要はありません。ただし、ダウンロードするパッチZIPファイルにPatchSearch.xmlファイルが含まれておらず、パッチ・メタデータ・ファイルをローカル・ホストに別にダウンロードする場合、「パッチ・メタデータ」にパッチ・メタデータ・ファイルの場所を指定します。
UNIXベースのオペレーティング・システムで、次のコマンドを実行してPatchSearch.xmlファイルがパッチのzipファイルに含まれているかどうかを確認します。

unzip -l <patch zip file path> | grep PatchSearch.xml

パッチのメタデータ・ファイルのダウンロード方法の詳細は、第42.2.4.4項を参照してください。

4. 「アップロード」をクリックして、パッチをソフトウェア・ライブラリにアップロードします。

これらの手順については、図42-10に示します。

図42-10 ソフトウェア・ライブラリへのパッチのアップロード

注意:
パッチのサイズが大きすぎるためアップロードできないというエラー・メッセージが表示された場合、EM CLIを使用してパッチをアップロードするか(第42.2.4.4項で説明)、または次のコマンドを実行してOMSを再起動し、パッチのアップロードを再試行します。
emctl set property -name "oracle.sysman.emSDK.ui.trinidad.uploadedfilemaxdiskspace" -sysman_pwd sysman -value 2589934592

-valueに指定した値がバイト単位であり、アップロードするパッチのサイズよりも大きいことを確認してください。

EM CLIを使用したソフトウェア・ライブラリへのパッチのアップロード

このメソッドを使用すると、複数のパッチを1回でアップロードできます。また、このメソッドは、Cloud Controlコンソールを使用してパッチをアップロードするよりも高速です。このため、このメソッドは、複数のパッチを1回でアップロードする場合、またはアップロードするパッチのサイズが大きい場合に使用してください。

EM CLIを使用してソフトウェア・ライブラリにパッチをアップロードするには、次の手順を実行します。

1. アップロード用としてダウンロードしたパッチ・ファイルが置かれているホストでEM CLIを設定します。
デフォルトでは、すべてのOMSホストでEM CLIが設定されています。OMSを実行していないホストでのEM CLIの設定方法の詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』の「コマンドライン・インタフェースの概要およびインストール」の章を参照してください。

2. EM CLIのインストール場所からEM CLIにログインします。

<emcli_install_location>/emcli login -username=<username> -password=<password>

次に例を示します。

<emcli_install_location>/emcli login -username=sysman -password=2benot2be

注意:
EM CLIログイン・ユーザーにADD_TARGET権限が付与されていることを確認します。

3. EM CLIを同期します。

<emcli_install_location>/emcli sync

4. 動詞upload_patchesを実行して、必要なパッチをソフトウェア・ライブラリにアップロードします。

<emcli_install_location>/emcli upload_patches
-location=<patch_location> | -patch_files=<metadata_file_path;ZIP_file path;second_part_of_ZIP_file_path;>
-from_host=<host_name>
[-cred_name=<credential_name> [-cred_owner=<credential_owner>]]

[ ]が付いているパラメータはオプションです。

-from_hostオプションを使用して、ダウンロードしたパッチZIPファイルとメタデータ・ファイルが置かれているホストを指定します。-locationオプションを使用すると、-from_hostで指定したホストにおけるダウンロードしたパッチ・ファイルの場所を指定できます。-locationを指定すると、指定した場所に置かれているパッチZIPファイルとメタデータ・ファイルがすべてソフトウェア・ライブラリにアップロードされます。このため、このオプションを使用すると、複数のパッチを1回でソフトウェア・ライブラリにアップロードできます。次に例を示します。

./emcli upload_patches -location=/scratch/aime/patches -from_host=h1.example.com

この例では、ホストh1.example.com上の/scratch/aime/patchesに置かれているすべてのパッチZIPファイルとメタデータ・ファイルがソフトウェア・ライブラリにアップロードされます。

-patch_filesオプションを使用して、パッチZIPファイルとそのメタデータ・ファイルの絶対パスを指定します。このオプションを使用する場合、指定できるのは1つのパッチZIPファイルのみです。このため、このオプションを使用すると、1回につき1つのパッチのみをアップロードできます。また、-cred_nameオプションを使用して、指定したホストにアクセスするのに使用する必要がある名前付き資格証明を指定します。さらに、-cred_ownerオプションを使用して、指定した名前付き資格証明の所有者を指定します。-cred_nameオプションを指定していない場合は、通常の優先資格証明を使用してホストにアクセスします。-cred_ownerオプションを指定していない場合、資格証明の所有者は現在のユーザーであると判断されます。次に例を示します。

./emcli upload_patches -patch_files="/scratch/p13741363_112310_Linux-x86-64_M.xml;/scratch/p13741363_112310_Linux-x86-64.zip" -from_host=h1.example.com -cred_name=AIMECRED -cred_owner=SYSMAN

この例では、SYSMANが所有する名前付き資格証明AIMECREDを使用して、ホストh1.example.com上に置かれているパッチZIPファイルp13741363_112310_Linux-x86-64.zipとメタデータ・ファイルp13741363_112310_Linux-x86-64_M.xmlをソフトウェア・ライブラリにアップロードしています。

注意:
動詞upload_patchesで、-locationオプションまたは-patch_filesオプションのいずれかを指定します。ただし、両方は指定しないでください。-locationオプションを指定すると、複数のパッチを1回でアップロードできるため、このオプションを使用することをお薦めします。

動詞upload_patchesの構文および使用方法の詳細を表示するには、次のコマンドを実行します。

$<OMS_HOME>/bin/emcli help upload_patches

42.2.5 環境の分析およびターゲットにパッチを適用できるかどうかの確認

パッチ計画を作成してターゲットにパッチを適用する前に、パッチ適用機能レポートを表示して環境を分析し、パッチを適用するターゲットがパッチ適用操作に適しているかどうかを確認することをお薦めします。これらのレポートには、パッチ適用できるターゲットとパッチ適用できないターゲットのサマリーが記載されており、デプロイ可能なパッチ計画の作成に役立ちます。パッチ適用できない、設定内のターゲットの問題を識別し、それらの問題に対する推奨事項を提案します。

パッチ適用機能レポートは、Oracle Database、Oracle WebLogic ServerおよびOracle SOAインフラストラクチャのターゲットで使用できます。

注意:
Oracle Fusion Middlewareターゲット(Oracle WebLogic ServerおよびOracle SOAインフラストラクチャのターゲット)のパッチ適用機能レポートを表示するには、Enterprise Manager for Oracle Fusion Middleware 12.1.0.4プラグインを設定にデプロイする必要があります。

パッチ適用機能レポートを表示するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「レポート」、「情報パブリッシャ・レポート」の順に選択します。

2. 「情報パブリッシャ・レポート」の下にあるすべてのブランチを表示するには、「すべて開く」をクリックします。

3. Oracle Databaseターゲットのパッチ適用機能レポートを表示するには、「デプロイおよび構成」ブランチの下の「パッチ適用の自動化レポート」サブ・ブランチで、「EMターゲットのパッチ適用機能レポート」を選択します。

4. Oracle Fusion Middleware (Oracle WebLogic ServerおよびOracle SOAインフラストラクチャ)ターゲットのパッチ適用機能レポートを表示するには、「デプロイおよび構成」ブランチの下の「パッチ適用の自動化レポート」サブ・ブランチで、「EMターゲットのパッチ適用機能レポート」をクリックします。

注意:
プロパティの欠落に関連するエラーがある場合は、第42.5.1.1項で説明されている回避策でエラーを解決します。サポートされない構成に関連するエラーがある場合は、第42.5.1.2項で説明されている回避策でエラーを解決します。

42.3 適用するパッチの特定

この項では、適用するパッチの特定方法について説明します。

この項は主に、各種パッチ・リリースの把握、推奨の検索、環境に公開するパッチの特定を行うパッチ・デザイナに対するものです。

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

- パッチ推奨について

- パッチ適用のためのナレッジ記事について

- パッチ適用のためのサービス・リクエストについて

- My Oracle Supportでのパッチの検索

- Oracleソフトウェア・ライブラリでのパッチの検索

42.3.1 パッチ推奨について

パッチ推奨は、潜在的なシステム上の問題と、システム・パフォーマンスの向上やシステム停止の回避を支援する推奨に関するプロアクティブな通知です。

「パッチ推奨」リージョンでは、すべての推奨パッチへのポータルが提供されます。棒グラフから推奨パッチのリストにドリルダウンし、それらのパッチの詳細を表示したり、パッチをダウンロードしたり、またはパッチ計画にパッチを追加できます。棒グラフには、検出された問題の数が要約されています(1つの問題は1つのターゲットに対する1つの推奨に対応します)。

「パッチ推奨」セクションに記載されているパッチは、MOS内で提供されたパッチのコレクションで、1つのグループとして1つ以上のターゲットに適用できます。使用環境向けの最新のパッチを使用して「パッチ推奨」セクションを最新の状態に維持するために、パッチ適用ジョブの発行時にパッチ警告の一部として実行される構成コレクション手順と呼ばれる手順があります。基本的に、構成コレクションを使用すると、パッチまたはロールバックの追加が原因で発生する変更を収集できます。これらの更新は、管理エージェントを介してOMSに伝達されます。管理エージェントは最終的に「パッチの推奨」リージョンの更新をサポートします。

注意:
Enterprise Manager 12c以降、パッチ適用の最後にトリガーされる構成コレクションは非同期的に行われます。つまり、計画の実行が完了してもコレクションは完了しない可能性があります。このような場合、エンタープライズ用のパッチ推奨の再計算が必要な場合があります。また、ターゲット・コレクションが正しく行われなかった場合も、パッチ推奨の再計算が必要な場合があります。
次の手順を実行します。

1. 次のEM CLIコマンドを実行し、パッチ計画のターゲット情報を取得します。

emcli get_patch_plan_data -name=<name of the plan>

2. 次の手順を実行し、ターゲットに計画がデプロイされた時刻を確認します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「パッチと更新版」をクリックします。

2. 「パッチと更新版」ページで、「計画」セクションからパッチ計画を選択します。

3. 計画の作成ウィザードから、「確認およびデプロイ」を選択します。

4. リンクをクリックし、デプロイの詳細を追跡します。

5. ジョブUIページからジョブの開始時刻をメモします。

3. 構成管理側で、次の属性を使用して、次のようにMGMT$ECM_CURRENT_SNAPSHOTSビューを使用してコレクションのタイムスタンプを計算します。

start_timestamp  - timestamp of the collection (in target timezone)
last_upload_timestamp (in DB timezone) when a collection was processed for this snapshot type.

開始タイムスタンプと最後の更新されたタイムスタンプ属性の組合せにより、コレクションがいつ行われたのかを確認できるため、「パッチ推奨」リージョンで使用可能な情報が最新のものであるかどうかを確認できます。

「パッチと更新版」ページには、デフォルトで「推奨パッチ」リージョンが表示されます。このリージョンを編集してそのコンテンツをフィルタできます。

推奨パッチの詳細を表示するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「パッチ推奨」リージョンで、目的のパッチに関連する棒グラフをクリックします。

注意:
「パッチ推奨」リージョンが表示されない場合は、右上隅から「ページのカスタマイズ」をクリックし、ページに「パッチ推奨」リージョンをドラッグします。

あるいは、「すべての推奨」をクリックして、「パッチの推奨」ページにすべての推奨を表示します。「パッチの推奨」ページには、Cloud Controlターゲットで現在使用できる推奨がすべて表示されます。

3. 「パッチ推奨」ページで、表示する推奨パッチを選択してコンテキスト・メニューを表示します。コンテキスト・メニューから、「全画面」をクリックします。

42.3.2 パッチ適用のためのナレッジ記事について

ナレッジ記事は、My Oracle Supportで公開されているドキュメントです。これらの記事は、お知らせまたは既知の問題に対する回避策のいずれかです。

既知の問題に対する回避策について説明しているナレッジ記事によっては、パッチ番号が記載されている場合があります。このパッチ番号をメモし、それぞれ第42.3.4項と第42.3.5項で説明しているように、My Oracle SupportまたはOracleソフトウェア・ライブラリで検索することができます。

あるいは、ナレッジ記事のパッチ番号をクリックすることもできます。この操作で「パッチ検索」ページが表示されます。「パッチ検索」ページで、パッチのコンテキスト・メニューから、「計画に追加」をクリックし、パッチを新しいパッチ計画に追加する場合は「新規に追加」を選択するか、パッチを既存のパッチ計画に追加する場合は「既存に追加」を選択します。

42.3.3 パッチ適用のためのサービス・リクエストについて

サービス・リクエストは、My Oracle Supportで発生するサポート・リクエストで、問題のレポートおよび追跡と、これらの問題を解決する際にオラクル社からオンライン支援を受けるためのものです。

既知の問題に対する回避策について説明しているサービス・リクエストによっては、パッチ番号が記載されている場合があります。このパッチ番号をメモし、それぞれ第42.3.4項と第42.3.5項で説明しているように、My Oracle SupportまたはOracleソフトウェア・ライブラリで検索することができます。

あるいは、ナレッジ記事のパッチ番号をクリックすることもできます。この操作で「パッチ検索」ページが表示されます。「パッチ検索」ページで、パッチのコンテキスト・メニューから、「計画に追加」をクリックし、パッチを新しいパッチ計画に追加する場合は「新規に追加」を選択するか、パッチを既存のパッチ計画に追加する場合は「既存に追加」を選択します。

42.3.4 My Oracle Supportでのパッチの検索

ブログ、Oracle Technologyフォーラムなどの外部ソースや同僚から、パッチが存在していることをすでに把握している場合は、検索機能を使用してそれらのパッチを検索します。検索機能を使用すると、より柔軟な拡張検索を実行できます。また、頻繁に使用される検索を保存したり、既存の保存済検索に基づいて検索するなどの機能があります。これにより、検索時間を短縮し、効率的に検索を実行できます。

My Oracle Supportでパッチを検索するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「パッチ検索」リージョンで、使用する検索パラメータを入力して「検索」をクリックします。

注意:
「パッチ検索」リージョンが表示されない場合は、右上隅から「ページのカスタマイズ」をクリックし、ページに「パッチ検索」リージョンをドラッグします。

あるいは、「保存」タブを使用して、以前に保存した検索を検索できます。また、「最近」タブを使用して、最近実行した同一の(または類似の)検索にアクセスできます。

パッチ検索が完了すると、結果が「パッチ検索結果」ページに表示されます。このページでは、パッチを選択してローカル・ホスト(デスクトップ)またはソフトウェア・ライブラリにダウンロードできます。

注意:
My Oracle Supportでパッチを検索する他の方法については、My Oracle Supportヘルプを参照してください。

42.3.5 Oracleソフトウェア・ライブラリでのパッチの検索

デフォルトでは、「パッチと更新版」画面でパッチを検索すると、Cloud Controlはそのホストで使用できるインターネット接続を使用してMy Oracle Supportに接続し、リクエストされたパッチをMy Oracle Supportで検索します。これは、デフォルトでは検索機能がオンライン・モードで実行するように設定されているためです。

しかし、ホストにインターネット接続が設定されていない場合、Oracle Software Library (ソフトウェア・ライブラリ)で検索を実行できるように、オフライン・モードに切り替える必要があります。

オフライン・モードに切り替えるには、次の手順を実行します。

1. 「設定」メニューから、「プロビジョニングとパッチ適用」を選択し、「オフライン・パッチ」を選択します。

2. 「接続」については、「オフライン」を選択します。

注意:
オフライン・モードでは、次の操作を実行できません。

- My Oracle Supportからのパッチの検索およびダウンロード

- パッチのマージによるパッチ競合の解決

- 関連アクティビティ・リージョンの表示

- クイックリンクへのアクセス

- アップグレード計画の表示または作成

ソフトウェア・ライブラリでパッチを検索するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「ソフトウェア・ライブラリ・パッチ検索」リージョンで、使用する検索パラメータを入力して「検索」をクリックします。

注意:
「パッチ検索」リージョンが表示されない場合は、右上隅から「ページのカスタマイズ」をクリックし、ページに「パッチ検索」リージョンをドラッグします。

パッチ検索が完了すると、結果が「パッチ検索結果」ページに表示されます。

42.4 パッチの適用

この項では、パッチでパッチ計画を作成してパッチ・テンプレートとして保存し、そのテンプレートから新しいパッチ計画を作成してパッチを適用する方法について説明します。

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

- パッチ計画の作成

- パッチ計画へのアクセス

- パッチ計画の分析、準備およびデプロイ

- パッチ計画のデプロイ後に元のOracleホームにスイッチバック

- 正常に分析されたまたはデプロイされたパッチ計画をパッチ・テンプレートとして保存

- パッチ・テンプレートからのパッチ計画の作成およびパッチの適用

- Oracle Grid Infrastructureターゲットへのパッチ適用

- Oracle Exadataへのパッチ適用

- Oracle Data Guardターゲットへのパッチ適用

- Oracle Identity Managementターゲットへのパッチ適用

- Oracle Siebelターゲットへのパッチ適用

42.4.1 パッチ計画の作成

この項は主に、パッチ計画を作成するパッチ・デザイナに対するものです。

パッチ計画を作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページで、適用するパッチを特定します(第42.3項を参照)。

3. 「パッチ推奨」ページまたは「パッチ検索」ページで(パッチを特定した方法による)、パッチ計画に追加するパッチを選択します。

4. コンテキスト・メニューから、「計画に追加」をクリックして「新規に追加」を選択します。

注意:
パッチ計画をすでに作成し、そのパッチ計画にパッチを追加する場合は、「既存に追加」を選択できます。

5. 「新規計画の作成」ウィンドウで、パッチ計画の一意の名前を入力して「計画の作成」をクリックします。
選択したパッチと、そのパッチが関連付けられているターゲットが計画に追加されます。

注意:

- 選択したパッチが他のターゲットに影響する場合は、影響を受けるターゲットも追加するように要求されます。

- パッチ計画の作成時、Cloud Controlでシステム・ターゲットのメンバーであるターゲットを追加できます。これを実行すると、そのシステムの他のメンバー・ターゲットが、パッチ計画に自動的に追加されます。システムとは、相互に機能することでアプリケーションをホスティングする、一連のインフラストラクチャ・コンポーネント(ホスト、データベース、アプリケーション・サーバーなど)を指します。Cloud Controlでは、システムとその中の各コンポーネントは、監視可能な個々のターゲット・タイプとしてモデル化されています。

- Oracle WebLogic Serverでは、Enterprise Manager for Oracle Fusion Middleware 12.1.0.4プラグインをデプロイしている場合、単一のパッチ計画に任意の数のWebLogicドメイン・ターゲットを追加できます。Enterprise Manager for Oracle Fusion Middleware 12.1.0.4プラグインをデプロイしていない場合、単一のパッチ計画に追加できるWebLogicドメイン・ターゲットは1つのみです。新しいプラグインのデプロイ方法または既存のプラグインのアップグレード方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。
パッチ計画に追加するWebLogicドメイン・ターゲットが共有ドメインの場合、パッチが適用されるドメインと共有されるドメインで稼働する管理サーバーおよび管理対象サーバーはすべて、自動的に同じパッチ計画に追加されます。

- Oracle SOAインフラストラクチャ・ターゲットでは、SOAターゲットにパッチを適用するために停止する必要のあるすべてのSOA WebLogicドメインが、影響を受けるターゲットとしてパッチ計画に追加されます。したがって、それらの各ドメインで稼働している管理サーバーおよび管理対象サーバーも影響を受け、パッチ計画を作成する際、影響を受けるその他のターゲットとされます。

42.4.2 パッチ計画へのアクセス

この項は主に、自分が作成したパッチ計画にアクセスするパッチ・デザイナに対するものです。

第42.4.1項で作成したパッチ計画にアクセスするには、次の方法のいずれかを使用します。

方法1: 「計画」リージョンからパッチ計画にアクセスする方法

「計画」リージョンからパッチ計画にアクセスするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「計画」リージョンで、表示するパッチ計画をクリックします。あるいは、パッチ計画を選択し、コンテキスト・メニューで「表示」をクリックします。計画の作成ウィザードが表示されます。
計画表をフィルタするには、プリファレンスに応じて「すべての計画タイプ」または「パッチ」を選択します。計画を検索するには、検索ボックスに計画名または計画名の一部を入力して、「検索」ボタンをクリックします。

注意:

- 「計画」リージョンが表示されない場合は、右上隅から「ページのカスタマイズ」をクリックし、ページに「計画」リージョンをドラッグします。

- 自分が作成した計画のみを表示するには、「計画」リージョンの人のアイコンをクリックします。

方法2: 「パッチ推奨」リージョンからパッチ計画にアクセスする方法

「パッチ推奨」リージョンからパッチ計画にアクセスするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「パッチ推奨」リージョンで、「すべての推奨」をクリックします。

注意:
「パッチ推奨」リージョンが表示されない場合は、右上隅から「ページのカスタマイズ」をクリックし、ページに「パッチ推奨」リージョンをドラッグします。

3. 「パッチ推奨」ページの表には、計画にすでに含まれているパッチが「計画内」列に計画アイコンとともに表示されます。アイコンをクリックすると、パッチが関連付けられているすべての計画が表示されます。計画をクリックすると、計画の作成ウィザードが表示されます。

42.4.3 パッチ計画の分析、準備およびデプロイ

この項は主に、パッチ計画を分析し、パッチを公開するためにデプロイするパッチ・デザイナに対するものです。

第42.4.1項で作成したパッチ計画を分析してデプロイする(またはパッチ・テンプレートとして保存する)には、次の手順を実行します。

1. 第42.4.2項で説明する方法のうち1つを使用してパッチ計画にアクセスします。
Cloud Controlに計画の作成ウィザードが表示されます。

2. 計画の情報ページで、次のようにします。

1. 「概要」セクションで、パッチ計画名を検証します。必要な場合は、計画名を編集できます。

2. (オプション)パッチ計画に関する簡単な説明を入力します。

3. (オプション)「アクセス許可対象」セクションで、「追加」をクリックして管理者またはロールに現在のパッチ計画へのパッチ計画アクセス権限を付与します。
「管理者に権限を追加」ウィンドウで、管理者またはロール、付与するアクセス権限を選択して、「権限の追加」をクリックします。

注意:

- パッチ計画内から、Cloud Controlで以前に作成した管理者またはロールにパッチ計画権限のみを付与できます。パッチ計画内から管理者またはロールを作成することはできません。パッチ計画およびパッチ・テンプレートに必要なロールおよび権限の詳細は、第42.2.2項を参照してください。

- 管理者またはロールを削除するには、「アクセス許可対象」セクションで、削除する管理者またはロールを選択して「削除」をクリックします。

4. 「次へ」をクリックします。

3. 「パッチ」ページで、次のようにします。

1. パッチ計画に追加したパッチを確認します。構成の推奨パッチは、自動的にパッチ計画に追加されます。また、手動で追加したパッチも表示されます。
Oracle Exadataの一部であるOracle Grid Infrastructureターゲットにパッチを適用する際に、Oracle Databaseプラグイン用に12.1.0.5 Enterprise Managerがデプロイされている場合、1つのExadataバンドル・パッチと、任意の数の個別グリッド・インフラストラクチャおよびOracle Databaseパッチを単一のパッチ計画に追加できます。このシナリオでは、パッチ計画の作成の間にExadataバンドル・パッチを追加し、その後個別グリッド・インフラストラクチャおよびOracle Databaseパッチを追加パッチとして追加するようにします。

Oracle Databaseプラグイン用に12.1.0.5 Enterprise Managerがデプロイされていない場合、個別パッチはすでにExadataバンドル・パッチを含むパッチ計画に追加できません。

Oracle Exadataの一部でないOracle Grid Infrastructureターゲットにパッチを適用する際に、Oracle Databaseプラグイン用に12.1.0.5 Enterprise Managerがデプロイされている場合、1つのグリッド・インフラストラクチャ・パッチ・セット更新(PSU)と、任意の数の個別グリッド・インフラストラクチャおよびOracle Databaseパッチを単一のパッチ計画に追加できます。このシナリオでは、パッチ計画の作成の間にグリッド・インフラストラクチャPSUを追加し、その後個別グリッド・インフラストラクチャおよびOracle Databaseパッチを追加パッチとして追加するようにします。

Oracle Databaseプラグイン用に12.1.0.5 Enterprise Managerがデプロイされていない場合、個別パッチはすでにグリッド・インフラストラクチャPSUを含むパッチ計画に追加できません。

パッチ計画にすでにあるパッチと追加のターゲットを関連付けるには、第42.6.7項で説明する手順に従います。

パッチの詳細を表示するには、パッチを選択してコンテキスト・メニューから「表示」をクリックします。分析およびデプロイメントからパッチを一時的に削除するには、「抑制」をクリックします。これでパッチはパッチ計画には残りますが、分析およびデプロイメントの対象とはみなされません。

2. 「次へ」をクリックします。

注意:
Oracleデータベース・ホーム所有者と異なるユーザーによってリスナーが起動されたOracleデータベースのパッチ適用はサポートされていません。そのようなデータベースにパッチを適用するには、データベース・リスナーを停止し、データベース・ホーム所有者として再起動してから、パッチ計画を使用して必要なパッチを適用します。

4. 「デプロイメント・オプション」ページで、次のようにします。

1. 「パッチ適用方法」セクションで、使用するパッチのモードを選択します。
スタンドアロン(単一インスタンス)のデータベース・ターゲット、Oracle RACターゲット、Oracle Data GuardターゲットおよびOracle Grid Infrastructureターゲット(Oracle Exadataの一部かどうかにはかかわりません)では、ホーム内パッチ適用とホーム外パッチ適用のどちらかを選択できます。Oracle Exadataの一部ではないOracle RACターゲットおよびOracle Grid Infrastructureターゲットへのホーム外パッチ適用は、Oracle Databaseプラグイン用に12.1.0.5 Enterprise Managerがデプロイされている場合のみ使用可能です。Oracle Data Guardターゲットへのホーム外パッチ適用は、Oracle Databaseプラグイン用に12.1.0.5 Enterprise Managerがデプロイされている場合のみサポートされています。

Oracle WebLogic Server、Oracle Fusion ApplicationsおよびOracle SOAインフラストラクチャ・ターゲットに対しては、提供されるパッチ適用メカニズムはインプレース・パッチ適用のみです。ホーム外パッチ適用は、これらのターゲットには提供されていません。インプレース・パッチ適用およびホーム外パッチ適用の詳細は、第42.1.6.2項を参照してください。

データベースの既存のOracleホームをクローニングし、元のOracleホームではなくクローニングしたOracleホームにパッチを適用する場合、「ホーム外」を選択します。元のOracleホームをクローニングせずに、ターゲットの既存の元のOracleホームに直接パッチを適用する場合、「ホーム内」をクリックします。

また、Oracle RACターゲット、Oracle Grid Infrastructureターゲット(Oracle Exadataの一部かどうかにはかかわりません)、Oracle Data Guardターゲット、Oracle WebLogic Serverターゲット、Oracle Fusion ApplicationターゲットおよびOracle SOAインフラストラクチャ・ターゲットには、ローリング・モードまたはパラレル・モードのどちらでパッチを適用するかを選択できます。ローリング・モードおよびパラレル・モードでのターゲットへのパッチ適用の詳細は、第42.1.6.3項を参照してください。

一度にターゲットの単一ノードにパッチを適用する場合は、「ローリング」を選択します。これはデフォルトのオプションで、停止時間はほとんどありません。ローリング・モードでターゲットにパッチを適用する際は、各ノードにパッチが適用された後、パッチ適用デプロイメント・プロシージャの実行を一時休止することもできます。この方法の詳細は、第42.6.13項を参照してください。

同時にターゲットのすべてのノードにパッチを適用する場合は、「パラレル」を選択します。これは、ある程度の時間、システム全体を停止するため停止時間があります。ただし、すべてのターゲット・ノードが同時にパッチ適用されるため、このプロセスは時間がかかりません。

2. (スタンドアロンのデータベース・ターゲット、Oracle RACターゲット、Oracle Data GuardターゲットおよびOracle Grid Infrastructureターゲットの場合のみ表示されます)「パッチ適用対象」セクションで、次を実行します。
インプレース・パッチ適用を選択した場合、パッチを適用するOracleホームの詳細を確認します。デフォルトでは、すべてのデータベース・インスタンスが移行されます。

ホーム外パッチ適用を選択した場合、クローニング対象のOracleホームに対して「新規ロケーションの作成」をクリックし、書込み権限のある空の場所へのパスを入力します。ターゲットにパッチが適用されるホスト上の任意のディレクトリにOracleホームをクローニングできます。場所の指定後にその場所を変更する場合は、「編集」をクリックします。

スタンドアロン・データベース・ターゲット、Oracle RACターゲット、Oracle Data GuardターゲットおよびOracle Grid Infrastructureターゲット(Oracle Exadataの一部かどうかにはかかわりません)には、すべてを移行するオプションと、指定されたOracleホームから作成された一部のデータベース・インスタンスのみを移行するオプションがあります。移行する対象を選択します。

注意:

- クローニングされたOracleホームにパッチが適用され、データベース・インスタンスがクローニングされたOracleホームに移行されたら、元のOracleホームを保持するか、そのOracleホームから実行されているターゲットが他にない場合は削除するかを選択できます。

- クローニングされたホームに、SQL文を含む(パッチ計画に追加されていない)特定の追加パッチが含まれていると、データベース・インスタンスをクローニングされたホームに移行する際、それらのパッチに対するSQL文は自動的に実行されません。これらのパッチでは、SQL文を手動で実行する必要があります。

3. ステージング先セクションで、次のようにします。
パッチをターゲットに適用する前に、ウィザードを使用してソフトウェア・ライブラリから一時的な場所にパッチをステージングする場合、「パッチのステージング」セクションで「はい」を選択します。ステージの場所を指定します。適用するパッチをすでに手動でステージングしている場合、「パッチのステージング」で「いいえ」を選択します。パッチを手動でステージングするには、パッチをダウンロードし、パッチをステージングする場所(親ディレクトリ)に移動し、パッチのZIPファイルと同じ名前でサブディレクトリを作成してから、パッチのZIPファイルの内容をこのサブディレクトリに抽出してください。「ステージングの場所」に親ディレクトリを指定します。ステージング場所が共有の場所である場合、「共有場所」を選択します。

たとえば、パッチ699099.zip,をダウンロードし、ステージング場所の親ディレクトリが/u01/app/oracle/em/stagepatchの場合は、この親ディレクトリ内に699099という名前のサブディレクトリを作成し、その中に内容を解凍します。ステージングの場所として/u01/app/oracle/em/stagepatchを指定します。

重要:
WebLogic Server 10.3.6またはそれ以前のバージョンのターゲットへのパッチの適用の際に、カスタムのステージング場所を指定している場合、指定した場所は無視され、選択したパッチはSmartUpdateで構成されたデフォルトのディレクトリ(つまり<WEBLOGIC_HOME>/utils/bsu/cache_dir)にステージングされます。

「ルート・コンポーネントのステージング」セクションで、ウィザードがパッチを適用するルート・コンポーネントをステージングするかどうかを指定します。ルート・コンポーネントは、実行に対してroot権限を必要とする、一連のPerlスクリプト(デプロイメント・プロシージャのディレクティブ・ステップの一部)です。Oracle Databaseターゲットにパッチを適用するには、ルート・コンポーネントが必要です。

ウィザードを使用してルート・コンポーネントをステージングする場合は、「ルート・コンポーネントのステージング」に「はい」を選択し、ルート・コンポーネントをステージングする場所(パッチ・ディスパッチャの場所)を指定します。root_dispatcher.shおよびpatching_root_dispatcher.shが、この場所にコピーされます。ただし、すでにルート・コンポーネントをステージングしている場合、「ルート・コンポーネントのステージング」に「いいえ」を選択し、ルート・コンポーネントを適用する場所、つまりパッチ・ディスパッチャの場所を指定します。パッチ・ディスパッチャの場所を共有している場合、「共有のディスパッチャの場所」を選択します。

パッチを適用するコンポーネントを手動でステージングする方法の詳細は、第42.6.8項を参照してください。

4. 「資格証明情報」セクションに、必要な資格証明を入力します。優先資格証明を使用することも、別の資格証明を使用することもできます。
Oracle WebLogic ServerターゲットおよびOracle SOAインフラストラクチャ・ターゲットにパッチを適用するには、次の資格証明セットが必要です。

- Oracle WebLogicドメインの管理者資格証明: これらの資格証明は、ドメイン内のすべての管理対象サーバーを監視する、そのドメインの管理サーバーに接続するために必要です。

- Oracle WebLogic Serverホーム資格証明: これらの資格証明は、異なるホストに存在するすべてのOracleホームに接続するために必要です。

また、「Weblogicドメインの管理者資格証明のオーバーライド」およびWebLogicホームの優先資格証明のオーバーライドを選択することにより、既存の資格証明のオーバーライドを選択することもできます。ただし、優先資格証明をオーバーライドする場合、その資格証明を検証する必要があります。Oracle WebLogic Serverターゲットでは、Oracle WebLogic Serverホーム資格証明のみを検証できます。管理者資格証明は検証できません。

注意:
資格証明の検証は、管理エージェントが停止するか、資格証明が不適切な場合に失敗します。

Enterprise Manager Cloud Control 12c リリース4 (12.1.0.4)では、セキュアな管理エージェント・ターゲットへパッチを適用する際に、通常のOracleホームの資格証明は必要ありません。特定のタスクを実行するために、管理エージェント・ターゲットに適用するパッチが、rootユーザー・アクセスを必要とする場合は、管理エージェント・ターゲットに特権Oracleホーム資格証明を指定する必要があります。

パッチを適用する管理エージェント・ターゲットがセキュアでない場合、パッチを適用するすべての管理エージェント・ターゲットに優先管理エージェント・ホスト資格証明を設定する必要があります。管理エージェント・ターゲットに優先ホスト資格証明を設定するには、「設定」メニューから、「セキュリティ」を選択し、次に「優先資格証明」を選択します。Select the 「エージェント」ターゲット・タイプを選択して、次に「優先資格証明の管理」をクリックします。必要な管理エージェント・ターゲットに優先ホスト資格証明を設定します。

5. (オプション)「カスタマイズ」セクションを使用して、パッチ計画が使用するデフォルトのデプロイメント・プロシージャをカスタマイズし、カスタマイズしたデプロイメント・プロシージャを使用してターゲットにパッチを適用します。
デフォルトでは、パッチ計画では、Oracleが提供する静的なデプロイメント・プロシージャ、または動的に生成されるOPlanベースのデプロイメント・プロシージャを使用してパッチを適用します。

注意:
OPlanは、動的デプロイメント・プロシージャを作成および実行してターゲットにパッチを適用する独立したツールです。Linux x64、Solaris x64、Solaris SPARCおよびAIXの各プラットフォームにデプロイされた、バージョン11.2.0.2.0以上のOracle Databaseターゲットへのパッチ適用をサポートします。

システムに、Oracle Database 12.1.0.6プラグイン(またはこれ以上のバージョン)向けのEnterprise Managerがデプロイされている場合、動的に生成されるデプロイメント・プロシージャは、Grid Infrastructureターゲット(Oracle Exadataの一部であるものと、Oracle Exadataの一部ではないもの)、Oracle RACデータベース・ターゲットおよびOracle Data Guardターゲットに、ホーム内とホーム外の両方のパッチ適用モードでパッチを適用するために使用されます。ただし、システムに、Oracle Database 12.1.0.6プラグイン向けのEnterprise Managerがデプロイされていない場合、動的に生成されるデプロイメント・プロシージャは、Grid Infrastructureターゲット(Oracle Exadataの一部であるものと、Oracle Exadataの一部ではないもの)、およびOracle RACデータベース・ターゲットにホーム外パッチ適用モードでパッチを適用するためにのみ使用されます。静的デプロイメント・プロシージャは、他のすべてのパッチ適用操作で使用されます。この両方のタイプのデプロイメント・プロシージャをカスタマイズし、カスタマイズしたデプロイメント・プロシージャを使用してターゲットにパッチを適用することを選択できます。

パッチ適用手順が静的デプロイメント・プロシージャから構成される場合は、「類似作成および編集」をクリックしてデフォルトのデプロイメント・プロシージャをカスタマイズします。カスタマイズしたデプロイメント・プロシージャを使用するには、「デプロイメント・オプション」ページの「カスタマイズ」セクションに表示されたリストからカスタマイズしたプロシージャを選択します。詳細は、42.6.12.1項を参照してください。

パッチ適用手順がOPlanに基づく動的に生成されたデプロイメント・プロシージャから構成される場合は、「生成されたパッチ適用デプロイメント・プロシージャに追加されるカスタム・ステップの指定」を選択し、デプロイメント・プロシージャを編集します。動的に生成されたデプロイメント・プロシージャの編集方法は、第42.6.12.2項を参照してください。

Oracle WebLogic ServerまたはOracle SOA Infrastructureのターゲットにパッチを適用する場合、サーバーがデフォルトで停止されない場合に強制的に停止されるタイムアウト値を設定できます。デフォルトでは、停止時間は30分です。これは、「シャットダウンのタイムアウト(分単位)」フィールドに値を入力することで変更できます。タイムアウト値を設定し、この値がリアルタイム・システムの監視に基づいていることを確認することをお薦めします。適用しているSOA InfrastructureのパッチにSQLアプリケーションの機能が含まれている場合は、「インストール後SQLスクリプト・メタデータ」フィールドに、使用されるSQLスクリプトへの絶対パスを指定する必要があります。SQLスクリプトの場所に関する詳細は、各パッチのそれぞれのReadmeドキュメントを参照してください。入力したSQLスクリプトがJDBCに準拠していることを確認してください。

Windowsホストで実行されているSOAインフラストラクチャ・ターゲットにパッチを適用するには、SOAパッチ内のSQLファイルに相対パスを提供するために、次の図に表示されている%FMW_ORACLE_HOME%環境変数を必ず使用してください。

絶対パスを指定したり、%ORACLE_HOME%環境変数を使用すると、エラーが発生します。また、Windowsホストで実行されているSOAインフラストラクチャ・ターゲットへのパッチ適用を実行する前に、パッチを適用するSOAインスタンス・ホームから実行されているすべてのサーバーを停止する必要があります。SOAインスタンス・ホーム外で実行されているサーバーのみを停止すると、エラーが発生します。

6. 「通知」セクションに、パッチ計画がスケジュール済、開始、アクションが必要、一時停止、成功、失敗の場合に、電子メール通知を有効化するかどうかを指定します。
電子メール通知を有効化するには、「パッチ適用プロセス時に通知の電子メールを受信」を選択して、必要なオプションを選択します。送信者または受信者の電子メール・アドレスが設定されていないという内容の警告のメッセージが表示される場合は、警告に記載されているアクションを実行してください。

7. 「ロールバック」セクションで、「計画内のパッチをロールバックします」を選択し、計画にリストされているパッチをデプロイするかわりにロールバックします。
ロールバック操作は、管理エージェント、Oracle WebLogicサーバー、Oracle SOA Infrastructure、Oracle Restart、単一インスタンスOracle Database、Oracle RACデータベース、Oracle Grid InfrastructureおよびOracle Exadataの一部であるOracle Grid Infrastructureターゲットのみをサポートします。

パッチをロールバックする方法の詳細は、第42.6.14項を参照してください。

注意:

- Oracle WebLogic Serverターゲットでは、パッチ適用およびロールバックはドメイン・レベルで発生します。ロールバック対象としてOracle WebLogic Serverターゲットを選択すると、管理サーバーおよび決定対象サーバーとともにドメインがロールバックされます。ロールバックするインスタンスを選択することや、ロールバックしないインスタンスをドメインから選択解除することはできません。

- SOAインフラストラクチャ・ターゲットでは、パッチ適用およびロールバックはインスタンス・ホーム・レベルで発生します。つまり、パッチを適用するSOA Oracleホーム・インスタンスを選択したり、既存のパッチのロールバックを開始する位置を選択できます。ロールバック対象のSOAホームから実行されているサーバーが他にある場合、それらのサーバーすべてと対応するドメイン、ロールバック可能なSQLメタデータ・スクリプトもロールバックされます。一部のSQLメタデータ・スクリプトはロールバックできません。この場合、パッチ(Oracleホーム内のビット)はロールバックされますが、SQLは変更されずにそのまま保持されます。
SOA構成にパッチを適用する際、パッチ適用が管理対象サーバーの1つで失敗し、他の管理対象サーバーで成功した場合、パッチが正常に適用されたすべての管理対象サーバーからパッチを削除する自動ロールバック処理は行われません。ただし、失敗について通知はされるため、手動でパッチをロールバックできます。

通常、パッチをロールバックする理由は次のとおりです。

- Oracleホームのパッチと競合している受信パッチを強制的に適用したが、後でその適用したパッチをアンインストールする場合。

- 適用したパッチが要件を十分に満たしていない場合(パッチによってバグが修正される可能性がありますが、同時に、プロセスに他のバグが侵入します)。

8. 「競合チェック」セクションで、分析ステージでパッチ計画内のパッチの競合を検索する際に、Oracle自動リリース更新(ARU)が使用される、ARU競合チェックを有効化または無効化するかを指定します。また、デプロイ時にパッチ競合が発生した場合に、パッチ適用手順で実行する必要のあるアクションを指定します。
競合発生時にパッチ適用手順で、計画のデプロイを停止する場合は、「競合」で「競合で停止」を、競合しているパッチをロールバックして受信パッチを適用する場合は、強制適用を、競合していないパッチのみを適用して競合しているパッチの適用をスキップする場合は、「競合のスキップ」を選択します。

9. 「次へ」をクリックします。

5. 「検証」ページで、「分析」をクリックして競合をチェックします。「検証」画面で実行されるチェック内容の詳細は、第42.1.3.3項を参照してください。

6. 「レビューおよびデプロイ」ページで詳細を確認し、次のいずれかを実行します。

- ホーム外パッチ適用モードでデータベース・ターゲットにパッチを適用している場合は、「準備」をクリックします。この操作は、基本的に、ソースOracleホームをクローニングし、パッチを適用します。この状況が発生した場合、ソースOracleホームおよびデータベース・インスタンスは稼働中です。
「準備」をクリックすると、「デプロイの確認」ダイアログ・ボックスが表示され、「準備」操作をスケジュールできます。「準備」を選択します。「準備」操作を即時に開始する場合は、「即時」を選択します。「準備」操作を後で開始するようにスケジュールする場合は、「後で」を選択し、時間を指定します。「送信」をクリックします。

「準備」操作に成功したら、「デプロイ」をクリックします。この操作は、基本的に、ソースOracleホームからクローニングおよびパッチ適用したOracleホームにデータベース・インスタンスを切り替えます。「準備」および「デプロイ」操作では、停止時間を最小化できます。

「デプロイ」をクリックすると、「デプロイの確認」ダイアログ・ボックスが表示され、「デプロイ」操作をスケジュールできます。「デプロイ」を選択します。「デプロイ」操作を即時に開始する場合は、「即時」を選択します。「デプロイ」操作を後で開始するようにスケジュールする場合は、「後で」を選択し、時間を指定します。「送信」をクリックします。

注意:
ホーム外パッチ適用モードでOracleホームにパッチを適用するかわりに、(必要なパッチが存在する)ソフトウェア・ライブラリに保存したソフトウェア・イメージから直接Oracleホームをプロビジョニングできます。これを実行するには、次の手順に従います。

1. 「Oracleデータベースのプロビジョニング」デプロイメント・プロシージャを使用して、ソフトウェア・ライブラリに保存したソフトウェア・イメージをホスト上の必要な場所にプロビジョニングします。

2. パッチ計画を作成します。プロビジョニングしたOracleホームの一部であるすべてのパッチをこの計画に追加します。

3. 「デプロイメント・オプション」ページの「パッチ適用対象」セクションで、プロビジョニングしたOracleホームの場所を指定します。

4. 計画を分析およびデプロイします。
データベース・インスタンスが以前のOracleホームから新しくプロビジョニングしたOracleホームに切り替わり、パッチ適用後ステップが実行されます。

- 他のモードで他のターゲットにパッチを適用する場合は、「デプロイ」をクリックします。
「デプロイ」をクリックすると、「デプロイの確認」ダイアログ・ボックスが表示され、「デプロイ」操作をスケジュールできます。「デプロイ」を選択します。「デプロイ」操作を即時に開始する場合は、「即時」を選択します。「デプロイ」操作を後で開始するようにスケジュールする場合は、「後で」を選択し、時間を指定します。「送信」をクリックします。

注意:

- 「準備」または「デプロイ」操作をスケジューリングすると、「レビューおよびデプロイ」ページの「準備」または「デプロイ」ボタンの名前が「再スケジュール」に変更されます。「準備」または「デプロイ」操作を再スケジュールする場合は、「再スケジュール」をクリックし、「送信」をクリックします。

- 「準備」または「デプロイ」操作をスケジューリングした後、スケジュールを破棄してパッチ計画を最後の有効な状態に戻す場合は、「スケジュールの停止」をクリックします。

- 「準備」または「デプロイ」操作のスケジュールは、パッチ計画デプロイメント・オプションまたはパッチ・ターゲットを編集した場合には破棄されます。この場合は、パッチ計画を再度検証する必要があります。

OPlanはターゲットにパッチを適用するために動的にデプロイメント・プロシージャを作成し実行する独立したツールで、多くのパッチ適用操作で使用されています。パッチ計画用のOPlanのreadmeファイルには、パッチ計画の段階的な実行手順についての詳しい情報が含まれています。Oracle Databaseプラグイン用に12.1.0.5 Enterprise Managerがデプロイされている場合、このファイルを表示できます。このファイルを表示するには、「レビューおよびデプロイ」ページでパッチ適用ステップの隣に表示されている「ダウンロード」リンクをクリックします。

注意:
正常に分析またはデプロイされたパッチ計画をパッチ・テンプレートとして保存するには、第42.4.5項を参照してください。

42.4.4 パッチ計画のデプロイ後に元のOracleホームにスイッチバック

ホーム外パッチ適用モードで、Oracle RACターゲット、Oracle単一インスタンス・データベース・ターゲットまたはOracle Grid Infrastructureターゲット(Oracle Exadataの一部かどうかにはかかわりません)にパッチを適用した後、なんらかの理由により、元のホームにスイッチバックする必要がある場合、計画の作成ウィザードにある「スイッチバック」オプションを使用できます。このオプションを使用する利点は、クローニングおよびパッチ適用したOracleホームからパッチを実際にロールバックしないことです。この場合、パッチなしで存在する元の古いOracleホームにスイッチバックするのみです。

注意:

- 「スイッチバック」オプションは、Oracle RAC、Oracle単一インスタンス・データベースおよびOracle Grid Infrastructureターゲット(Oracle Exadataの一部かどうかにはかかわりません)に対してのみ、およびこれらのターゲットがホーム外パッチ適用モードでパッチ適用されている場合にのみ使用できます。

- スイッチバックできるのは、パッチ計画が正常に分析およびデプロイされた場合のみです。

パッチ計画のデプロイ後に元のOracleホームにスイッチバックするには、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「計画」領域で、Oracle RAC、Oracle単一インスタンス・データベースまたはOracle Grid Infrastructureターゲットへのパッチ適用に使用する正常に分析およびデプロイされたパッチ計画をクリックします。あるいは、パッチ計画を選択し、コンテキスト・メニューで「表示」をクリックします。計画の作成ウィザードが表示されます。

3. 計画の作成ウィザードの「レビューおよびデプロイ」ページで、「スイッチバック」をクリックします。

42.4.5 正常に分析されたまたはデプロイされたパッチ計画をパッチ・テンプレートとして保存

この項は主に、オペレータが承認されたパッチや事前定義されたデプロイメント・オプションで新しいパッチ計画を作成するために使用できるよう、正常に分析されたまたはデプロイされたパッチ計画をパッチ・テンプレートとして保存するパッチ・デザイナに対するものです。

パッチ計画をパッチ・テンプレートとして保存するには、42.4.3項に記載されている手順(1)から手順(5)を実行し、手順(6)の「レビューおよびデプロイ」ページで「テンプレートとして保存」をクリックします。新規計画テンプレートの作成ダイアログで、パッチ・テンプレートの一意の名前を入力して「テンプレートの作成」をクリックします。

管理者が多く、長期間にわたって大規模に公開する必要がある場合、ベスト・プラクティスとしてこの方法を実行することをお薦めします。大規模なデータ・センターがある場合は、パッチ・デザイナとして、パッチ計画を作成していくつかのデータベースにパッチを適用し、パッチが正常に適用されるかテストしてから、計画をテンプレートとして保存します。後で、パッチ・オペレータにこれらのテンプレートからパッチ計画を作成させ、データ・センターの残りのデータベースに同じセットのパッチを公開できるようにします。

42.4.6 パッチ・テンプレートからのパッチ計画の作成およびパッチの適用

正常に分析されたまたはデプロイされたパッチ計画がパッチ・テンプレートとして保存されると、テンプレートからパッチ計画を作成し、パッチを適用するターゲットを関連付け、新しく作成したパッチ計画をデプロイできます。

これは、まったくのオプションのステップです。パッチを公開するのに、パッチ計画をテンプレートとして保存する必要はありません。第42.4.3項の説明に従って、パッチ計画から直接パッチを公開できます。

この項は主に、パッチを公開するためにパッチ・テンプレートからパッチ計画を作成するパッチ・オペレータに対するものです。

方法1

パッチ・テンプレートからパッチ計画を作成するには、次の方法のいずれかを使用します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「計画」リージョンで、パッチ計画の作成元として使用するパッチ・テンプレートを選択します。

3. コンテキスト・メニューから、「計画の作成」を選択します。

4. テンプレートから計画を作成ダイアログで、パッチ計画の一意の名前を入力してパッチを適用するターゲットを選択し、「計画の作成」をクリックします。

5. 「パッチと更新版」ページに戻り、「計画」リージョンで、使用するパッチ計画をクリックします。あるいは、パッチ計画を選択し、コンテキスト・メニューで「表示」をクリックします。計画の作成ウィザードが表示されます。

6. 計画の作成ウィザードの「検証」ページに移動し、「再分析」をクリックして新たにターゲットが関連付けられたパッチ計画を分析します。

7. パッチ計画が正常に分析されたら、「検証」ページで「次へ」をクリックします。

8. 「レビューおよびデプロイ」ページで、「デプロイ」をクリックします。

方法2

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「計画」リージョンで、次のいずれかを実行します。

- パッチ・テンプレートを選択します。コンテキスト・メニューから、「表示」を選択します。テンプレートの編集ウィザードが表示されます。

- パッチ・テンプレートの名前をクリックします。テンプレートの編集ウィザードが表示されます。

3. テンプレートの編集ウィザードで、「計画の作成」をクリックします。

4. テンプレートから計画を作成ダイアログで、パッチ計画の一意の名前を入力してパッチを適用するターゲットを選択し、「計画の作成」をクリックします。

5. 「パッチと更新版」ページに戻り、「計画」リージョンで、使用するパッチ計画をクリックします。あるいは、パッチ計画を選択し、コンテキスト・メニューで「表示」をクリックします。計画の作成ウィザードが表示されます。

6. 計画の作成ウィザードの「検証」ページに移動し、「再分析」をクリックして新たにターゲットが関連付けられたパッチ計画を分析します。

7. パッチ計画が正常に分析されたら、「検証」ページで「次へ」をクリックします。

8. 「レビューおよびデプロイ」ページで、「デプロイ」をクリックします。

42.4.7 Oracle Grid Infrastructureターゲットへのパッチ適用

パッチ計画を使用してOracle Grid Infrastructureターゲットにパッチを適用できます。次の手順を実行します。

1. 第42.3項の説明に従って、適用するOracle Grid Infrastructureパッチ・セット更新(PSU)または個別パッチを特定します。

2. 第42.4.1項の説明に従って、パッチ計画を作成します。

3. 第42.4.3項の説明に従って、パッチ計画を分析およびデプロイします。

重要:

- Oracle Databaseプラグイン用に12.1.0.5 Enterprise Manager以上がデプロイされている場合、1つのグリッド・インフラストラクチャPSUと、任意の数の個別グリッド・インフラストラクチャおよびOracle Databaseパッチを単一のパッチ計画に追加できます。このシナリオでは、パッチ計画の作成の間にグリッド・インフラストラクチャPSUを追加し、その後個別グリッド・インフラストラクチャおよびOracle Databaseパッチを追加パッチとして追加するようにします。
Oracle Databaseプラグイン用に12.1.0.5 Enterprise Manager以上がデプロイされていない場合、個別パッチはすでにグリッド・インフラストラクチャPSUを含むパッチ計画に追加できません。

- 管理対象のRACデータベースのバージョンが異なり、Oracle Databaseプラグイン用に12.1.0.5 Enterprise Manager以上がデプロイされている場合、グリッド・インフラストラクチャ・ターゲットにグリッド・インフラストラクチャPSUを適用できます。このプラグインがデプロイされておらず、管理対象のRACデータベースのバージョンが異なる場合、グリッド・インフラストラクチャ・ターゲットにグリッド・インフラストラクチャPSUを適用できません。
たとえば、Oracle Databaseプラグイン用に12.1.0.5 Enterprise Manager以上がデプロイされ、バージョン11.2.0.3のグリッド・インフラストラクチャで構成されているグリッド・インフラストラクチャ・ターゲットがバージョン11.2.0.2および11.2.0.3のRACデータベースを管理している場合、グリッド・インフラストラクチャ・ターゲットに11.2.0.3グリッド・インフラストラクチャPSUを適用できます。この場合、グリッド・インフラストラクチャ・バイナリおよび11.2.0.3 RACデータベースにはパッチが適用されますが、11.2.0.2 RACデータベースには適用されません。グリッド・インフラストラクチャ・ターゲットに11.2.0.2グリッド・インフラストラクチャPSUを適用することも可能です。この場合、11.2.0.2 RACデータベースにはパッチが適用されますが、グリッド・インフラストラクチャ・バイナリおよび11.2.0.3 RACデータベースには適用されません。

42.4.8 Oracle Exadataへのパッチ適用

パッチ計画を使用すると、Exadataデータベース・マシンで稼働しているOracle RACデータベース・ターゲットおよびOracle Grid Infrastructureターゲット(Oracle Clusterware)にパッチを適用できます。

Exadataパッチ適用は、インプレース・パッチ適用とホーム外パッチ適用の2つのモードで実行できますが、付随する停止時間がより短くなるため、ホーム外パッチ適用メカニズムを使用することをお薦めします。

サポートされているExadataリリースの詳細は、第42.1.5項を参照してください。

ただし、パッチ計画では、Exadataデータベース・マシンの計算ノード・エンティティ(オペレーティング・システムおよびファームウェアなど)には、そのストレージ・セルとともにパッチを適用しません。パッチを適用するのは、マシンで稼働している関連付けられたOracle RACデータベース・ターゲットおよびOracle Grid Infrastructure (Oracle Clusterware)ターゲットのみです。

注意:
Oracle RACターゲットおよびOracle Grid Infrastructureターゲット(Oracle Clusterware)に適用される、Oracle Exadata Database Machine推奨のバンドル・パッチは、Cloud Controlでテストされ、動作保証されています。

そのため、Exadataデータベース・マシン推奨のバンドル・パッチでパッチ計画を作成するとき、Exadataデータベース・マシンで稼働しているクラスタ・ターゲットまたはOracle RACデータベース・ターゲットを必ず追加してください。パッチ計画は、Exadataデータベース・マシンとのアソシエーションを自動的に認識し、そのマシンで稼働している影響を受けるターゲットをすべて追加するように要求します。たとえば、クラスタ・ターゲットを選択すると、そのクラスタに含まれていてExadataデータベース・マシンで稼働しているOracle RACデータベース・ターゲットおよびOracle Grid Infrastructureターゲットをすべて追加するように要求されます。

Exadataデータベース・マシンにパッチを適用するには、次の手順を実行します。

1. 適用する必要があるExadataデータベース・マシン推奨のバンドル・パッチを特定します(第42.3項を参照)。

2. 第42.4.1項の説明に従って、パッチ計画を作成します。

3. Exadataデータベース・マシンで稼働しているクラスタ・ターゲットまたはOracle RACデータベース・ターゲットを追加し、第42.4.3項の説明に従って、パッチ計画を分析およびデプロイします。
次の図に、Exadataデータベース・マシン推奨のバンドル・パッチを新しいパッチ計画に追加し、クラスタ・ターゲット、その他すべての関連付けられたOracle RACデータベース・ターゲットおよびOracle Grid Infrastructureターゲットを選択する方法を図示します。

図42-11 パッチ計画へのExadataデータベース・マシンのバンドル・パッチの追加

重要:

- Oracle Databaseプラグイン用に12.1.0.5 Enterprise Manager以上がデプロイされている場合、1つのExadataバンドル・パッチと、任意の数の個別グリッド・インフラストラクチャおよびOracle Databaseパッチを単一のパッチ計画に追加できます。このシナリオでは、パッチ計画の作成の間にExadataバンドル・パッチを追加し、その後個別グリッド・インフラストラクチャおよびOracle Databaseパッチを追加パッチとして追加するようにします。
Oracle Databaseプラグイン用に12.1.0.5 Enterprise Manager以上がデプロイされていない場合、個別パッチはすでにExadataバンドル・パッチを含むパッチ計画に追加できません。

- 管理対象のRACデータベースのバージョンが異なり、Oracle Databaseプラグイン用に12.1.0.5 Enterprise Manager以上がデプロイされている場合、グリッド・インフラストラクチャ・ターゲット(Oracle Exadataの一部)にExadataバンドル・パッチを適用できます。このプラグインがデプロイされておらず、管理対象のRACデータベースのバージョンが異なる場合、グリッド・インフラストラクチャ・ターゲットにExadataバンドル・パッチを適用できません。
たとえば、Oracle Databaseプラグイン用に12.1.0.5 Enterprise Manager以上がデプロイされ、バージョン11.2.0.3のグリッド・インフラストラクチャで構成されているグリッド・インフラストラクチャ・ターゲット(Oracle Exadataの一部)がバージョン11.2.0.2および11.2.0.3のRACデータベースを管理している場合、グリッド・インフラストラクチャ・ターゲットに11.2.0.3 Exadataバンドル・パッチを適用できます。この場合、グリッド・インフラストラクチャ・バイナリおよび11.2.0.3 RACデータベースにはパッチが適用されますが、11.2.0.2 RACデータベースには適用されません。グリッド・インフラストラクチャ・ターゲットに11.2.0.2 Exadataバンドル・パッチを適用することも可能です。この場合、11.2.0.2 RACデータベースにはパッチが適用されますが、グリッド・インフラストラクチャ・バイナリおよび11.2.0.3 RACデータベースには適用されません。

Oracle Grid InfrastructureおよびOracle RACターゲットのExadataのホーム外パッチ適用

Exadataのホーム外パッチ適用メカニズムを使用すると、既存のOracleホームのコピーを作成し、クローニングしたOracleホームにパッチを適用することにより、Oracle Grid InfrastructureおよびOracle RACターゲットにパッチを適用できます。クローニングしたホームにパッチを適用すると、インスタンスを移行してクローニングしたホームから実行できます(つまり、インスタンスの切替え中、停止時間は最小限になり、長時間にはなりません)。

図42-12に、Exadataデータベース・マシンで実行されているOracle Grid InfrastructureおよびOracle RACターゲットがどのようにホーム外パッチ適用モードでパッチが適用されるかを示します。

図42-12 クラスタのホーム外パッチ適用

これらのインスタンスの移行は、次のモードで実行できます。

- 完全移行: データ・センター内で実行されているすべてのデータベース・インスタンスを1回のセッションで移行することを選択する場合、これは完全移行と呼ばれます。

- 部分移行: データ・センター内で許容される停止時間に基づいて一部のインスタンスのみを1回のセッションで移行することを選択する場合、これは部分移行と呼ばれます。ただし、残りのインスタンスは後続のセッションで必ず移行する必要があります。この方法は、Oracleホーム外で実行されているインスタンスが複数ある場合、特に便利です。

注意:
Exadataデータベース・マシンで実行されているOracle Grid InfrastructureおよびOracle RACターゲットの完全移行または部分移行の実行方法の手順については、第42.4.3項を参照してください。

「スイッチバック」は、Exadataマシンで実行されているOracle Grid InfrastructureおよびOracle RACターゲットで使用可能なオプションです。このオプションを使用すると、なんらかの問題がある場合に、新しくクローニングしたOracleホームのインスタンスを元のOracleホームに切り替えることができます。

スイッチバックを実行する方法の詳細は、第42.4.4項を参照してください。

42.4.9 Oracle Data Guardターゲットへのパッチ適用

この項では、Oracle Grid InfrastructureのPSUまたはOracle DatabaseのPSUをOracle Data Guardターゲットの様々な構成に適用する方法を説明します。ホーム内パッチ適用モードまたはホーム外パッチ適用モードのどちらでOracle Data Guardターゲットにパッチを適用するかを選択できます。

内容は次のとおりです。

- Oracle Data Guardへのパッチ適用ワークフロー

- Oracle Data Guardへのパッチ適用シナリオ

42.4.9.1 Oracle Data Guardへのパッチ適用ワークフロー

プライマリおよびスタンバイのデータベースが同じクラスタから実行されている場合、次の手順に従います。

1. 必要なパッチを検索して、クラスタ・ターゲットを選択してパッチ計画を作成します。

2. 必要なデプロイメント・オプションを指定します。

3. 計画を分析およびデプロイします。

プライマリおよびスタンバイのデータベースが異なるクラスタから実行されている場合、次の手順に従います。

1. 必要なパッチを検索して、スタンバイ・データベースを含むクラスタ・ターゲットを選択してパッチ計画を作成します。

2. 必要なデプロイメント・オプションを指定します。

3. 計画を分析およびデプロイします。

4. (オプション)スタンバイ・データベースが新規のプライマリ・データベースになるように、データベース・スイッチオーバーを実行します(この逆の場合も同様です)。データベースの停止時間を短縮できるスイッチオーバーの実行
データベース・スイッチオーバーを実行する方法の詳細は、『Oracle® Data Guard Broker』を参照してください。

5. 必要なパッチを検索して、プライマリ・データベース(またはスイッチオーバーを実行した場合は新規のスタンバイ・データベース)を含むクラスタ・ターゲットを選択して別のパッチ計画を作成します。

6. 必要なデプロイメント・オプションを指定します。

7. 計画を分析およびデプロイします。

重要:

- 最初にスタンバイ・データベースにパッチを適用してから、プライマリ・データベースにパッチを適用することをお薦めします。

- 複数のスタンバイ・データベースで構成された環境の場合、最初にすべてのスタンバイ・データベースにパッチを適用してから、プライマリ・データベースにパッチを適用します。スイッチオーバーを実行する場合は、最初に1つのスタンバイ・データベースにパッチを適用してからスイッチオーバーを実行し、次に残りのスタンバイ・データベースと新規のスタンバイ・データベースにパッチを適用します。

42.4.9.2 Oracle Data Guardへのパッチ適用シナリオ

この項では、様々なシナリオでのOracle Data Guardへのパッチ適用手順を説明します。

シナリオ1: プライマリ・データベースおよびスタンバイ・データベースがRACデータベースの場合。

表42-4では、プライマリおよびスタンバイのデータベースがRACデータベースの場合に、Oracle Grid InfrastructureのPSUまたはOracle DatabaseのPSUを適用する手順を示します。

表42-4 Oracle Data Guardへのパッチ適用(RAC - RAC)

プライマリ・データベースおよびスタンバイ・データベースの構成

パッチの適用方法

プライマリおよびスタンバイのRACデータベースが同じクラスタから実行されている場合。

1. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、クラスタ・ターゲットを選択して、パッチ計画を作成します。

2. 必要なデプロイメント・オプションを指定します。

3. 計画を分析およびデプロイします。

プライマリおよびスタンバイのRACデータベースが異なるクラスタから実行されている場合。

1. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、スタンバイRACデータベースが含まれるクラスタ・ターゲットを選択して、パッチ計画を作成します。

2. 必要なデプロイメント・オプションを指定します。

3. 計画を分析およびデプロイします。

4. (オプション)スタンバイRACデータベースが新規のプライマリ・データベースになるように、データベース・スイッチオーバーを実行します(この逆の場合も同様です)。
データベース・スイッチオーバーを実行する方法の詳細は、『Oracle® Data Guard Broker』を参照してください。

5. 必要なOracle Grid InfrastructureのPSUまたはOracle DatabaseのPSUを検索して、プライマリRACデータベース(またはスイッチオーバーを実行した場合は新規のスタンバイ・データベース)を含むクラスタ・ターゲットを選択して別のパッチ計画を作成します。

6. 必要なデプロイメント・オプションを指定します。

7. 計画を分析およびデプロイします。

2つのプライマリRACデータベース(P1およびP2)が、2つの異なるクラスタ(C1およびC2)からそれぞれに実行されている場合。スタンバイRACデータベース(S1およびS2)は、それぞれC2およびC1から実行されています。

1. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、1つ目のクラスタ・ターゲット(C1)を選択して、パッチ計画を作成します。

2. 必要なデプロイメント・オプションを指定します。

3. 計画を分析およびデプロイします。

4. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、2つ目のクラスタ・ターゲット(C2)を選択して、別のパッチ計画を作成します。

5. 必要なデプロイメント・オプションを指定します。

6. 計画を分析およびデプロイします。

注意: クラスタにパッチを適用する順序は問題ではないため、C1、C2の順でも、C2、C1の順でもかまいません。

シナリオ2: プライマリ・データベースがRACデータベースで、スタンバイ・データベースが、Cluster Ready Services (CRS)ターゲットまたは単一インスタンスの高可用性(SIHA)ターゲットによって管理されている単一インスタンス・データベースの場合。

表42-5では、プライマリ・データベースがRACデータベースで、スタンバイ・データベースがCRSターゲットまたはSIHAターゲットで管理される単一インスタンスのデータベースの場合、Oracle Grid InfrastructureのPSUまたはOracle DatabaseのPSUを適用する手順を示します。

表42-5 Oracle Data Guardへのパッチ適用(RAC - SIDB)

プライマリ・データベースおよびスタンバイ・データベースの構成

パッチの適用方法

プライマリRACデータベースおよびスタンバイの単一インスタンス・データベースが同じクラスタから実行されている場合。

1. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、クラスタ・ターゲットを選択して、パッチ計画を作成します。

2. 必要なデプロイメント・オプションを指定します。

3. 計画を分析およびデプロイします。

プライマリRACデータベースおよびスタンバイの単一インスタンス・データベースが異なるクラスタから実行されている場合。

1. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、スタンバイの単一インスタンス・データベースが含まれるクラスタ・ターゲットを選択して、パッチ計画を作成します。

2. 必要なデプロイメント・オプションを指定します。

3. 計画を分析およびデプロイします。

4. (オプション)単一インスタンスのスタンバイ・データベースが新規のプライマリ・データベースになるように、データベース・スイッチオーバーを実行します(この逆の場合も同様です)。
データベース・スイッチオーバーを実行する方法の詳細は、『Oracle® Data Guard Broker』を参照してください。

5. 必要なOracle Grid InfrastructureのPSUまたはOracle DatabaseのPSUを検索して、プライマリRACデータベース(またはスイッチオーバーを実行した場合は新規のスタンバイ・データベース)を含むクラスタ・ターゲットを選択して別のパッチ計画を作成します。

6. 必要なデプロイメント・オプションを指定します。

7. 計画を分析およびデプロイします。

2つのプライマリRACデータベース(P1およびP2)が、2つの異なるクラスタ(C1およびC2)からそれぞれに実行されている場合。スタンバイの単一インスタンス・データベース(S1およびS2)は、それぞれC2およびC1から実行されています。

1. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、1つ目のクラスタ・ターゲット(C1)を選択して、パッチ計画を作成します。

2. 必要なデプロイメント・オプションを指定します。

3. 計画を分析およびデプロイします。

4. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、2つ目のクラスタ・ターゲット(C2)を選択して、別のパッチ計画を作成します。

5. 必要なデプロイメント・オプションを指定します。

6. 計画を分析およびデプロイします。

注意: クラスタにパッチを適用する順序は問題ではないため、C1、C2の順でも、C2、C1の順でもかまいません。

シナリオ3: プライマリ・データベースおよびスタンバイ・データベースが、CRSまたはSIHAターゲットによって管理されている単一インスタンス・データベースの場合。

表42-6では、プライマリおよびスタンバイのデータベースがCRSターゲットまたはSIHAターゲットで管理される単一インスタンスのデータベースの場合、Oracle Grid InfrastructureのPSUまたはOracle DatabaseのPSUを適用する手順を示します。

表42-6 Oracle Data Guardへのパッチ適用(SIDB - SIDB)

プライマリ・データベースおよびスタンバイ・データベースの構成

パッチの適用方法

プライマリおよびスタンバイの単一インスタンス・データベースが同じクラスタから実行されている場合。

1. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、クラスタ・ターゲットを選択して、パッチ計画を作成します。

2. 必要なデプロイメント・オプションを指定します。

3. 計画を分析およびデプロイします。

プライマリおよびスタンバイの単一インスタンス・データベースが異なるクラスタから実行されている場合。

1. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、スタンバイの単一インスタンス・データベースが含まれるクラスタ・ターゲットを選択して、パッチ計画を作成します。

2. 必要なデプロイメント・オプションを指定します。

3. 計画を分析およびデプロイします。

4. (オプション)単一インスタンスのスタンバイ・データベースが新規のプライマリ・データベースになるように、データベース・スイッチオーバーを実行します(この逆の場合も同様です)。
データベース・スイッチオーバーを実行する方法の詳細は、『Oracle® Data Guard Broker』を参照してください。

5. 必要なOracle Grid InfrastructureのPSUまたはOracle DatabaseのPSUを検索して、単一インスタンスのプライマリ・データベース(またはスイッチオーバーを実行した場合は新規のスタンバイ・データベース)を含むクラスタ・ターゲットを選択して別のパッチ計画を作成します。

6. 必要なデプロイメント・オプションを指定します。

7. 計画を分析およびデプロイします。

2つのプライマリの単一インスタンス・データベース(P1およびP2)が、2つの異なるクラスタ(C1およびC2)からそれぞれに実行されている場合。スタンバイの単一インスタンス・データベース(S1およびS2)は、それぞれC2およびC1から実行されています。

1. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、1つ目のクラスタ・ターゲット(C1)を選択して、パッチ計画を作成します。

2. 必要なデプロイメント・オプションを指定します。

3. 計画を分析およびデプロイします。

4. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、2つ目のクラスタ・ターゲット(C2)を選択して、別のパッチ計画を作成します。

5. 必要なデプロイメント・オプションを指定します。

6. 計画を分析およびデプロイします。

注意: クラスタにパッチを適用する順序は問題ではないため、C1、C2の順でも、C2、C1の順でもかまいません。

シナリオ4: プライマリRACデータベース(P1)および、CRSまたはSIHAターゲットによって管理されているプライマリの単一インスタンス・データベース(P2)が、2つの異なるクラスタ(C1およびC2)からそれぞれに実行されている場合。CRSまたはSIHAターゲットによって管理されているスタンバイの単一インスタンス・データベース(S1およびS2)は、それぞれC2およびC1から実行されています。

この構成に、Oracle Grid InfrastructureのPSUまたはOracle DatabaseのPSUを適用するには、次の手順に従います。

1. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、1つ目のクラスタ・ターゲット(C1)を選択して、パッチ計画を作成します。

2. 必要なデプロイメント・オプションを指定します。

3. 計画を分析およびデプロイします。

4. Oracle Grid InfrastructureまたはOracle Databaseの必要なPSUを検索し、2つ目のクラスタ・ターゲット(C2)を選択して、別のパッチ計画を作成します。

5. 必要なデプロイメント・オプションを指定します。

6. 計画を分析およびデプロイします。

注意:
クラスタにパッチを適用する順序は問題ではないため、C1、C2の順でも、C2、C1の順でもかまいません。

42.4.10 Oracle Identity Managementターゲットへのパッチ適用

パッチ計画を使用して、Identity Management Lifecycleツールを使用してプロビジョニングされたOracle Access Management ServerおよびOracle Identity Management Serverターゲットにパッチを適用できます。他のOracle Identity Managementターゲットのパッチ適用はサポートされていません。

パッチ計画を使用して、Oracle Access Management ServerおよびOracle Identity Management Serverターゲット(ID管理ライフサイクル・ツールを使用してプロビジョニング)にパッチを適用するには、Identity Management Pack Plusのライセンスが必要です。また、OMS、およびOracle Access Management ServerとOracle Identity Management Serverターゲットがデプロイされているホストで実行されているすべての管理エージェントに、Oracle Fusion Middlewareプラグイン向けのEnterprise Manager 12.1.0.6がデプロイされている必要があります。

パッチ計画を使用してOracle Access Management ServerおよびOracle Identity Management Serverターゲットにパッチを適用するには、次の手順に従います。

1. 第42.3項の説明に従って、適用するパッチを特定します。

2. 第42.4.1項の説明に従って、パッチ計画を作成します。

3. 第42.4.3項の説明に従って、パッチ計画を分析およびデプロイします。

42.4.11 Oracle Siebelターゲットへのパッチ適用

パッチ計画を使用して、Siebel Gateway ServerおよびSiebel Serverターゲットにパッチを適用できます。他のOracle Siebelターゲットのパッチ適用はサポートされていません。Siebel Gateway ServerおよびSiebel Serverターゲットにパッチを適用するには、12.1.0.5 Enterprise Manager for Oracle Siebelプラグインがシステムにデプロイされている必要があります。

パッチ計画を使用してSiebel Gateway ServerおよびSiebel Serverターゲットにパッチを適用するには、次の手順に従います。

1. 第42.3項の説明に従って、適用するパッチを特定します。

2. 第42.4.1項の説明に従って、パッチ計画を作成します。

3. 第42.4.3項の説明に従って、パッチ計画を分析およびデプロイします。

42.5 パッチ適用に関する問題の診断および解決

この項では、次の項目について説明します。

- ターゲット関連エラーの回避策

- パッチ適用に関する一般的な問題

- パッチ適用に関する問題の解決

- パッチのロールバック

42.5.1 ターゲット関連エラーの回避策

この項ではターゲット関連エラーの回避策について説明し、内容は次のとおりです。

- プロパティの欠落エラーの回避策

- サポートされない構成エラーの回避策

42.5.1.1 プロパティの欠落エラーの回避策

表42-7に、発生する可能性のあるプロパティの欠落エラーと、それを解決するために試行できる回避策を示します。

表42-7 プロパティの欠落エラーと回避策

問題

解決策

ターゲット・プロパティのバージョンが空

ターゲットが正しく構成されていないか、ターゲットが使用できない可能性があります。ターゲットを再構成するか、メトリック収集エラーをチェックします。

Oracle Management Agentによって収集されたターゲット情報が不適切または不完全。

この問題を解決するには、動的プロパティを再計算し、管理リポジトリがホストの最新構成で更新されるようにホスト構成をリフレッシュします。次の手順を実行します。

1. 動的プロパティを再計算するには、次のいずれかを実行します。
オプションA: 管理エージェントを停止して再起動します。ターゲット・モデルを理解する必要がないため、このオプションの方が簡単です。

$ emctl stop agent

$ emctl start agent

クラスタの場合は、クラスタのすべてのノードで管理エージェントを再起動します。

オプションB: すべてのターゲットの動的プロパティをリロードします。監視のためのブラックアウトや停止時間がないため、このオプションの方が適切です。

管理エージェントで監視されているターゲットのリストを表示するには、次のコマンドを実行します。

$ emctl config agent listtargets

特定のターゲットの動的プロパティをリロードするには、次のコマンドを実行します。

$ emctl reload agent dynamicproperties [<Target_name>:<Target_Type>]

次に例を示します。

$ emctl reload agent dynamicproperties oradb:oracle_database

$ emctl reload agent dynamic properties racdb_1:rac_database

$ emctl reload agent dynamicproperties crs:cluster

$ emctl reload agent dynamic properties wls:weblogic_j2eeserver

$ emctl reload agent dynamicproperties server1.xyz.com:host

2. 管理リポジトリを最新の構成情報で更新するには、「エンタープライズ」メニューから、「構成」、「ホスト構成のリフレッシュ」の順に選択します。「ホスト構成のリフレッシュ」ページで、構成を更新する必要があるホストを選択して「ホストのリフレッシュ」をクリックします。

検出時に収集されたターゲット情報が不適切または不完全であるため、ターゲットが正しく検出されない。

この問題を解決するには、ドメインを再検出し、ドメイン内のすべてのターゲットが効率的に検出されるようにします。次の手順を実行します。

1. 適切な資格証明を使用してドメインのホームページにログインします。たとえば、Farm01_base_domainなどです。

2. (Farm01_base_domain)ホームページで、「ファーム」メニューから「WebLogicドメインのリフレッシュ」を選択し、後続のすべてのページで「OK」をクリックし、プロセスを完了します。プロセスが正常に完了すると、ドメインのホームページがリフレッシュされ、すべてのターゲットが再度検出されます。

42.5.1.2 サポートされない構成エラーの回避策

表42-8に、発生する可能性のあるサポートされていない構成エラーと、それを解決するために試行できる回避策を示します。

表42-8 サポートされない構成エラーの回避策

問題

回避策

Oracle RACインスタンスにOracle RACデータベースが関連付けられていない

Oracle RACターゲットを再検出し、Oracle RACインスタンスをOracle RACデータベースに追加します。

データベースがOMSによって仲介されない

ターゲット検出が不適切です。Cloud Controlからターゲットを削除し、クラスタ内のすべての管理エージェントで再検出します。

42.5.2 パッチ適用に関する一般的な問題

パッチ計画の分析またはデプロイ時に、次の事柄に該当する場合、エラーが発生することがあります。

- OMSまたは管理エージェントが停止している場合

- ソフトウェア・ライブラリが正しく構成されていない場合

- My Oracle Supportへの接続がない(オンライン・モード)場合

- 管理リポジトリがない場合

- 収集がない場合

- ホストまたはOracleホーム・セキュリティの問題がある場合

- 固有のOPatchまたはSQLのエラーがある場合

- パッチ計画が異種パッチ(個別パッチとパッチ・セットの組合せなど)で構成される場合

- (Oracle WebLogicターゲットの場合のみ)SmartUpdateツールに固有の問題がある場合。

- (Oracle WebLogicターゲットの場合のみ) OMSにレポートするOracle WebLogicターゲットの検出に問題がある場合

これらのエラーは、次の場所に表示されます。

- 計画の作成ウィザードの「検証」ページまたは「確認」ページのヘッダー・セクション(図42-13)

- 「検証」ページの解決する問題セクション(図42-14)

- 「パッチと更新版」ページの「計画」リージョン(図42-15)。

図42-13 「検証」ページに表示されるパッチ計画のエラー

図42-14 解決する問題セクションに表示されるパッチ計画のエラー

図42-15 「計画」リージョンに表示されるパッチ計画のエラー

42.5.3 パッチ適用に関する問題の解決

表42-9に、パッチ計画が処理される様々なフェーズ、フェーズが取りうる状態、エラーを診断および解決する方法を示します。

注意:
第F.2項に記載されているトラブルシューティングのヒントも参照してください。

表42-9 パッチ適用に関する問題の診断

フェーズ

状態

診断および解決方法

分析

分析の実行中

該当なし

分析エラー

次のログ・ファイルを参照します。

<gc_inst>/sysman/log/emoms.log

問題が解決していません

計画の作成ウィザードの「検証」ページで、解決する問題セクションにリストされる問題を確認します。

解決する問題セクションで、エラー・メッセージが「詳細結果をここに表示」をクリックする必要があることを示している場合は、クリックします。プロシージャ・アクティビティ・ステータス・ページの「ステータスの詳細」表で、各ステップのステータスを確認します。ログの詳細を表示するには、ステータスをクリックします。

検出された競合

計画の作成ウィザードの「検証」ページで、解決する問題セクションにリストされる問題を確認します。

解決する問題セクションで、エラー・メッセージが「詳細結果をここに表示」をクリックする必要があることを示している場合は、クリックします。プロシージャ・アクティビティ・ステータス・ページの「ステータスの詳細」表で、各ステップのステータスを確認します。ログの詳細を表示するには、ステータスをクリックします。

デプロイの準備完了

該当なし

準備

準備中

該当なし

準備エラー

次のログ・ファイルを参照します。

<gc_inst>/sysman/log/emoms.log

準備に失敗しました

「検証」ページで、「詳細結果をここに表示」をクリックします。プロシージャ・アクティビティ・ステータス・ページの「ステータスの詳細」表で、各ステップのステータスを確認します。ログの詳細を表示するには、ステータスをクリックします。

準備に成功しました

該当なし

デプロイ

デプロイ中

該当なし

デプロイ・エラー

次のログ・ファイルを参照します。

<gc_inst>/sysman/log/emoms.log

デプロイに失敗しました

「検証」ページで、「詳細結果をここに表示」をクリックします。プロシージャ・アクティビティ・ステータス・ページの「ステータスの詳細」表で、各ステップのステータスを確認します。ログの詳細を表示するには、ステータスをクリックします。

デプロイに成功しました

該当なし

42.5.4 パッチのロールバック

パッチをロールバックする場合は、適用したパッチとともにパッケージされたReadMeに記載されているロールバック手順に従ってください。

ロールバック機能は、管理エージェント、Oracle WebLogicサーバー、Oracle SOA Infrastructure、Oracle Restart、単一インスタンスOracle Database、Oracle RACデータベース、Oracle Grid InfrastructureおよびOracle Exadataの一部であるOracle Grid Infrastructureの各ターゲットをサポートします。ロールバックの手順の詳細は、第42.6.14項を参照してください。他のすべてのターゲットでは、Cloud Controlはパッチの自動ロールバックをサポートしていないため、手動でパッチをロールバックする必要があります。

42.6 その他の実行可能パッチ適用タスク

この項では、パッチ計画とともに実行できるその他のタスクについて説明します。特に、次の内容について説明します。

- パッチ・テンプレートの表示または変更

- デプロイされたパッチ計画をパッチ・テンプレートとして保存

- パッチ・テンプレートからのパッチのダウンロード

- パッチ・テンプレートの削除

- パッチ計画の削除

- デプロイ可能なパッチ計画へのデプロイ不可能なパッチ計画の変換

- パッチ計画のパッチへの追加ターゲットの関連付け

- パッチを適用するルート・コンポーネントの手動によるステージング

- パッチ適用のためのルート・ユーザー・アクセスの制限

- パッチ競合の解決

- パッチ適用操作の結果の分析

- パッチ適用デプロイメント・プロシージャのカスタマイズ

- パッチのロールバック

42.6.1 パッチ・テンプレートの表示または変更

パッチ・テンプレートを表示または変更するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「計画」リージョンで、次のいずれかを実行します。

- パッチ・テンプレートを選択します。コンテキスト・メニューから、「表示」を選択します。テンプレートの編集ウィザードが表示されます。

- パッチ・テンプレートの名前をクリックします。テンプレートの編集ウィザードが表示されます。

注意:

- パッチ・テンプレートを作成した管理者とCloud Controlのスーパー管理者が、パッチ・テンプレートを変更できます。

- パッチ・テンプレートで編集できるのは、説明とデプロイメント日のみです。

42.6.2 デプロイされたパッチ計画をパッチ・テンプレートとして保存

パッチ計画をすでに分析およびデプロイし、そのパッチ計画をパッチ・テンプレートとして保存する場合は、次の方法のいずれかを使用します。

方法1

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「計画」リージョンで、正常に分析されたデプロイ可能なパッチ計画を選択します。コンテキスト・メニューが表示されます。

注意:
パッチ・テンプレートは、一度に1つのパッチ計画からのみ作成できます。

3. コンテキスト・メニューから、「テンプレートの作成」を選択します。「新規計画テンプレートの作成」ダイアログが表示されます。

4. テンプレートの一意の名前を入力し、続いて「テンプレートの作成」をクリックします。

注意:
計画を選択するとき、次の場合には「テンプレートの作成」オプションは表示されません。

- デプロイ不可能なパッチ計画、または、未分析か、分析後にエラーが発生したデプロイ可能なパッチ計画を選択した場合。

- 選択したパッチ計画を表示する権限がない場合。

- テンプレートを作成する権限がない場合。

方法2

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「計画」リージョンで、次のいずれかを実行します。

- 正常に分析されたデプロイ可能なパッチ計画を選択します。コンテキスト・メニューから、「表示」を選択します。計画の作成ウィザードが表示されます。

- 正常に分析されたデプロイ可能なパッチ計画の名前をクリックします。計画の作成ウィザードが表示されます。

3. 計画の作成ウィザードの「レビューおよびデプロイ」ページで、「テンプレートとして保存」をクリックします。

4. テンプレートの一意の名前を入力し、続いて「テンプレートの作成」をクリックします。

注意:
一意の名前を持つパッチ・テンプレートのみを作成する必要があります。

42.6.3 パッチ・テンプレートからのパッチのダウンロード

パッチ・テンプレートからパッチをダウンロードするには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「計画」リージョンで、パッチ・テンプレートを選択します。

3. コンテキスト・メニューから、「表示」を選択します。テンプレートの編集ウィザードが表示されます。

4. テンプレートの編集ウィザードの「パッチ」ページで、パッチ番号をクリックします。「パッチ詳細」ページが表示されます。

5. パッチ詳細ページで、「ダウンロード」をクリックします。

42.6.4 パッチ計画の削除

パッチ計画を削除するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「計画」リージョンで、削除するパッチ計画をクリックします。コンテキスト・メニューから、「削除」をクリックします。

注意:
「計画」リージョンが表示されない場合は、右上隅から「ページのカスタマイズ」をクリックし、ページに「計画」リージョンをドラッグします。

42.6.5 パッチ・テンプレートの削除

パッチ・テンプレートを削除するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「計画」リージョンで、1つ以上のパッチ・テンプレートを選択します。コンテキスト・メニューが表示されます。

3. コンテキスト・メニューから「削除」を選択します。

注意:
パッチ・テンプレートを作成した管理者とCloud Controlのスーパー管理者が、パッチ・テンプレートを変更できます。

42.6.6 デプロイ可能なパッチ計画へのデプロイ不可能なパッチ計画の変換

デプロイ不可能なパッチ計画をデプロイ可能にするには、パッチ計画を、同種のパッチおよびターゲットのみが含まれるデプロイ可能なより小さい計画に分割します。

注意:
詳細は、第F.2.6.1項を参照してください。

42.6.7 パッチ計画のパッチへの追加ターゲットの関連付け

追加ターゲットをパッチ計画のパッチに関連付けるには、次の方法のいずれかを使用します。

方法1

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「計画」リージョンで、パッチが属するパッチ計画を選択します。表示されるコンテキスト・メニューから、「表示」を選択します。

注意:
「計画」リージョンが表示されない場合は、右上隅から「ページのカスタマイズ」をクリックし、ページに「計画」リージョンをドラッグします。

3. 計画の作成ウィザードの「パッチ」ページで、「パッチの追加」をクリックします。検索の編集ウィンドウが表示されます。

4. 「検索の編集」ウィンドウで、追加ターゲットを関連付けるパッチを検索します。

5. 追加するパッチを選択して「この計画に追加」をクリックします。パッチを計画に追加ウィンドウが表示されます。

6. 「パッチを計画に追加」ウィンドウで、パッチに関連付ける追加ターゲットを検索して選択し、「パッチを計画に追加」をクリックします。

注意:
必ず同種ターゲットのみを選択してください。
Oracle WebLogic Serverでは、Enterprise Manager for Oracle Fusion Middleware 12.1.0.4プラグインをデプロイしている場合、単一のパッチ計画に任意の数のWebLogicドメイン・ターゲットを追加できます。Enterprise Manager for Oracle Fusion Middleware 12.1.0.4プラグインをデプロイしていない場合、単一のパッチ計画に追加できるWebLogicドメイン・ターゲットは1つのみです。新しいプラグインのデプロイ方法または既存のプラグインのアップグレード方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

パッチ計画に追加するWebLogicドメイン・ターゲットが共有ドメインの場合、パッチが適用されるドメインと共有されるドメインで稼働する管理サーバーおよび管理対象サーバーはすべて、自動的に同じパッチ計画に追加されます。

方法2

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「パッチ推奨」リージョンで、グラフをクリックします。

注意:
「パッチ推奨」リージョンが表示されない場合は、右上隅から「ページのカスタマイズ」をクリックし、ページに「パッチ推奨」リージョンをドラッグします。

3. 「パッチ推奨」ページで、パッチを選択します。

4. コンテキスト・メニューから「計画に追加」→「既存に追加」の順に選択し、パッチに追加する計画を選択します。
選択したパッチと、そのパッチが関連付けられているターゲットが既存の計画に追加されます。

方法3

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択します。

2. 「パッチと更新版」ページの「検索」リージョンで、パッチ計画に追加するパッチを検索します。

注意:
「検索」リージョンが表示されない場合は、右上隅から「ページのカスタマイズ」をクリックし、ページに「検索」リージョンをドラッグします。

3. 「パッチ検索」ページで、詳細を表示するパッチをクリックします。

4. パッチ詳細ページで、「計画に追加」、「既存に追加」の順にクリックし、パッチを追加する計画を選択します。
選択したパッチと、そのパッチが関連付けられているターゲットが既存の計画に追加されます。

42.6.8 パッチを適用するルート・コンポーネントの手動によるステージング

Oracle Databaseターゲットにパッチを適用するには、管理エージェント・ユーザーは、rootユーザーとして、perl、patching_root_dispatcher.sh、root_dispatcher.shおよびidエンティティを実行できる必要があります。これらのエンティティは、パッチを適用するルート・コンポーネントの一部を構成しています。

Oracle Databaseターゲットにパッチを適用中に、パッチを適用するルート・コンポーネントは、デフォルトで、(%emd_emstagedir%によって定義される場所で)自動的にターゲット・ホストにステージングされます。ただし、パッチ・プロセスを開始する前に、パッチを適用するルート・コンポーネントをカスタムの場所に手動でステージングする場合は、次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. Patching/Common/DB/All/Generic/Componentsに移動します。

3. 「アクション」メニューから「ルート・コンポーネント」を選択し、「ステージング・エンティティ」を選択します。

4. ホスト(パッチを適用するルート・コンポーネントをステージングする場所)、およびディスパッチャの場所、つまり、パッチを適用するルート・コンポーネントのステージング先として指定したホストの場所を指定します。「発行」をクリックして、パッチを適用するルート・コンポーネントを手動でステージングします。

重要:

パッチを適用するルート・コンポーネントをカスタムの場所で手動でステージングする前に、パッチを適用するユーザーに、カスタムのパッチ・ディスパッチャの場所およびpatching_root_dispatcher.shに対する読取りおよび実行権限が付与されていることを確認します。

5. パッチ・ディスパッチャの場所にrootComponent/component/patchingサブディレクトリを作成します。

6. patching_root_dispatcher.shを除くすべてのファイルをディスパッチャの場所から<dispatcher_location>/rootComponent/component/patchingにコピーします。

注意:
パッチを適用するルート・コンポーネントを手動でステージングした後、必要なOracle Databaseパッチを適用するために作成するパッチ計画にこれを指定する必要があります。作成したパッチ計画の「デプロイ・オプション」ページにアクセスします。「ステージングの場所」セクションで、「ルート・コンポーネントのステージング」に「いいえ(ステージ済)」を選択し、パッチを適用するルート・コンポーネントを手動でステージングしたディスパッチャの場所を指定します。ディスパッチャが共有の場所である場合、「共有のディスパッチャの場所」を選択します。

42.6.9 パッチ適用のためのルート・ユーザー・アクセスの制限

Enterprise Manager Cloud Control 12c リリース4 (12.1.0.4)では、管理エージェント・ユーザーに対する制限されたrootアクセス権を指定できるため、管理エージェント・ユーザーがrootとして実行できるコマンドは、すべてのコマンドではなく特定のコマンドのみとなります。これを実行するには、etc/sudoersポリシー・ファイルを編集します。

Oracle Databaseターゲットにパッチを適用するには、管理エージェント・ユーザーは、rootユーザーとして、perl、patching_root_dispatcher.sh、root_dispatcher.shおよびidエンティティを実行できる必要があります。これらのエンティティは、パッチを適用するルート・コンポーネントの一部を構成しています。

制限されたrootアクセス権を管理エージェント・ユーザー(aime)に指定して、このユーザーがperl、patching_root_dispatcher.sh、root_dispatcher.shおよびidエンティティのみをrootユーザーとして実行できるようにするには、etc/sudoersファイルを次のコンテンツが含まれるように編集します。

Cmnd_Alias <command_alias> = \
<agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION perl *, \
<agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION <dispatcher_loc>/patching_root_dispatcher.sh *,\
<agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION <dispatcher_loc>/root_dispatcher.sh *,\
<agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION id

aime ALL=(root) <command_alias>
root ALL=(ALL) ALL

<command_alias>は、aimeをrootとして実行できるエンティティを説明するエイリアスを表します。

<agent_home>は、管理エージェントのホームを表します。

<dispatcher_loc>は、パッチを適用するルート・コンポーネントがステージングされるパッチ・ディスパッチャの場所を表します。デフォルトでは、パッチを適用するルート・コンポーネントは、%emd_emstagedir%で自動的にステージングされます。自動ステージングにカスタムの場所を選択した場合、または(第42.6.9項の説明に従って)パッチを適用するルート・コンポーネントをカスタムの場所に手動でステージングした場合、<dispatcher_loc>にこの場所を指定していることを確認してください。または、デフォルトの場所、つまり%emd_emstagedir%を指定します。

42.6.10 パッチ競合の解決

パッチ計画のパッチが、相互に競合しているか、Oracleホームのパッチと競合している場合、次のいずれかの方法を実行して競合を解決できます。

- 競合している各パッチのマージ・パッチをリクエストします。これを実行するには、検証ページの「パッチのリクエスト」をクリックします。

- Oracleホームで競合しているパッチをロールバックし、受信パッチを強制的に適用します。これを実行するには、「デプロイメント・オプション」ページの拡張パッチ・オプション・セクションで、「競合解決」リストから受信パッチの強制適用を選択します。

- 競合しているパッチをスキップします。これを実行するには、「デプロイメント・オプション」ページの拡張パッチ・オプション・セクションで、「競合解決」リストから「競合するパッチのスキップ」を選択します。

42.6.11 パッチ適用操作の結果の分析

一定期間にわたって実行したパッチ適用操作の結果を分析する場合は、EMデプロイ可能なパッチ計画実行サマリーを実行します。このレポートには、過去に保持していたデプロイ可能な計画とデプロイ不可能な計画の数と、デプロイ可能な計画の内訳(成功と失敗の数、分析済とデプロイ済の数など)が表示されます。

EMデプロイ可能なパッチ計画実行サマリー・レポートを実行するには、次の手順を実行します。

1. 「エンタープライズ」メニューから、「レポート」、「情報パブリッシャ・レポート」の順に選択します。

2. 「情報パブリッシャ・レポート」ページの表で、「デプロイおよび構成」、「パッチ適用の自動化レポート」の順に開き、「EMデプロイ可能なパッチ計画実行サマリー」を選択します。

42.6.12 パッチ適用デプロイメント・プロシージャのカスタマイズ

この項では、パッチ適用デプロイメント・プロシージャをカスタマイズする方法について説明します。一般的なデプロイメント・プロシージャのカスタマイズ方法は、第51章を参照してください。この章では、カスタマイズの概要、デプロイメント・プロシージャの様々なカスタマイズ方法などについて詳しく説明しています。

デフォルトでは、パッチ計画では、Oracleが提供する静的なデプロイメント・プロシージャ、または動的に生成されるOPlanベースのデプロイメント・プロシージャを使用してパッチを適用します。これらの両方の種類のデプロイメント・プロシージャをカスタマイズできます。この項の内容は次のとおりです。

- 静的パッチ適用デプロイメント・プロシージャのカスタマイズ

- 動的パッチ適用デプロイメント・プロシージャのカスタマイズ

42.6.12.1 静的パッチ適用デプロイメント・プロシージャのカスタマイズ

デフォルトの静的なデプロイメント・プロシージャをカスタマイズし、ターゲットへのパッチ適用に使用するには、次の手順に従います。

1. 「デプロイ・オプション」ページにアクセスします。

2. 「カスタマイズ」セクションで、「類似作成および編集」をクリックします。

3. デプロイメント・プロシージャを編集し(デプロイメント・プロシージャに、手動ステップを追加することもできます)、一意のカスタムの名前で保存します。
デプロイメント・プロシージャの編集および保存方法は、第51.2項を参照してください。

4. カスタマイズされたデプロイメント・プロシージャを使用するには、「デプロイ・オプション」ページの「カスタマイズ」セクションに戻り、カスタマイズしたデプロイメント・プロシージャを選択します。
カスタマイズしたデプロイメント・プロシージャを編集する場合は、「カスタマイズ」セクションで、カスタマイズしたデプロイメント・プロシージャを選択し、「カスタマイズ」をクリックします。

42.6.12.2 動的パッチ適用デプロイメント・プロシージャのカスタマイズ

動的に生成されたデプロイメント・プロシージャをカスタマイズし、ターゲットへのパッチ適用に使用するには、次の手順に従います。

1. 「デプロイ・オプション」ページにアクセスします。

2. 「カスタマイズ」セクションで、「生成されたパッチ適用デプロイメント・プロシージャに追加されるカスタム・ステップの指定」を選択します。
デプロイメント・プロシージャの各プレースホルダ・ステップでは、3つのカスタム・ステップ、ディレクティブ・ステップ(ソフトウェア・ライブラリに格納されたディレクティブを実行できる)、ホスト・コマンド・ステップ(パッチ・ターゲットでコマンド・スクリプトを実行できる)および手動ステップ(ユーザーに手動の手順を提供できる)を追加できます。

3. プレースホルダ・ステップに追加するすべてのカスタム・ステップを選択し、「有効化」をクリックします。
有効にしたカスタム・ステップを無効にするには、カスタム・ステップを選択し、「無効化」をクリックします。

4. 追加するカスタム・ステップを選択し、「編集」をクリックします。
選択したカスタム・ステップがディレクティブ・ステップの場合は、「カスタム・ステップの編集」ダイアログ・ボックスが表示され、実行するディレクティブの詳細を指定できます。新規ディレクティブまたは表示されているのとは異なるディレクティブを指定するには、「ディレクティブ名」の横に表示されているアイコンをクリックします。ソフトウェア・ライブラリに存在する必要なディレクティブを検索して選択し、「選択」をクリックします。「ディレクティブのプロパティ」セクションで、各ディレクティブ・プロパティに対して値を指定するか、変数(動的に生成されたデプロイメント・プロシージャで定義されます)を選択します。「資格証明」セクションで、「資格証明の使用方法」に対して、カスタム・ディレクティブ・ステップの実行に使用する必要のある資格証明を選択します。「OK」をクリックします。

選択したカスタム・ステップがホスト・コマンド・ステップの場合は、「カスタム・ステップの編集」ダイアログ・ボックスが表示され、パッチ・ターゲットで実行するコマンド・スクリプトの詳細を指定できます。「スクリプト」に、パッチ・ターゲットで実行するコマンドを指定します。「インタプリタ」に、指定したコマンド・スクリプトの実行に使用する必要のあるインタプリタの完全パスを指定します。「資格証明の使用方法」で、カスタム・ホスト・コマンド・ステップの実行に使用する必要のある資格証明を選択します。「OK」をクリックします。

選択したカスタム・ステップが手動ステップの場合は、「カスタム・ステップの編集」ダイアログ・ボックスが表示され、デプロイメント・プロシージャの実行中にユーザーに手動の手順を提供できます。「手順」で、ユーザーがこのカスタム・ステップで実行する必要のある手動タスクの手順を指定します。「OK」をクリックします。指定した手順は、デプロイメント・プロシージャのこのカスタム・ステップが実行されたときに表示されます。

5. 有効にしたすべてのカスタム・ステップに対してステップ4を繰り返します。

42.6.13 ローリング・モードでのターゲットへのパッチ適用中のパッチ適用プロセスの一時休止

ローリング・モードでターゲットにパッチを適用する際は、各ノードにパッチが適用された後、パッチ適用デプロイメント・プロシージャの実行を一時休止することもできます。この機能は、パッチ適用プロセスを次のノードで開始する前にパッチ適用ノードがあるホストでクリーンアップを実行する場合、パッチがノードに正常に適用されるかを確認する場合などに便利です。

重要:
この機能は、Oracle Databaseプラグイン用に12.1.0.5 Enterprise Manager以上がデプロイされている場合のみ使用できます。

この機能を使用するには、次の手順を実行します。

1. 第42.6.12.1項の説明に従って、カスタム静的デプロイメント・プロシージャを作成します。「類似作成プロシージャ」ページで「プロシージャ・ステップ」タブの「ユーザー確認の待機」オプションを選択し、「保存」をクリックします。

2. ローリング・モードでターゲットにパッチを適用するためにパッチ計画を作成する際に、(「デプロイメント・オプション」ページの「カスタマイズ」タブでこのカスタム・デプロイメント・プロシージャを指定して)カスタム・デプロイメント・プロシージャを使用します。
ノードにパッチが適用されると、パッチ適用デプロイメント・プロシージャは一時休止し、「プロシージャ・アクティビティ」ページから実行を再開できます。

42.6.14 パッチのロールバック

パッチをロールバックするには、新規パッチ計画を作成し、ロールバックする関連パッチを選択し、ロールバック・チェック・ボックスを選択します。これには次の手順を実行します。

注意:
ロールバック機能は、次のターゲットでサポートされています。

- Oracle Management Agents

- Oracle WebLogic Server

- Oracle単一インスタンス・データベース

- Oracle SOAインフラストラクチャ

- Oracle Restart

- Oracle RACデータベース

- Oracle Grid Infrastructure

- Oracle Exadataの一部であるOracle Grid Infrastructureターゲット

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「パッチと更新版」をクリックします。

2. パッチと更新版ページの「パッチ検索」領域に、ロールバックするパッチを入力します。

3. 「パッチを計画に追加」ダイアログ・ボックスに計画の一意の名前を入力し、パッチをロールバックするすべてのターゲットを選択します。

4. 「計画の作成」をクリックします。

5. 「計画の作成」ウィザードで、「デプロイ・オプション」ページを選択します。

6. デプロイメント・オプション・ページの、「パッチ適用方法」セクションで「ホーム内」を選択し、「ロールバック」セクションで「計画内のパッチをロールバックします」を選択します。「次へ」をクリックします。

7. 検証ページで、「分析」をクリックして計画を検証します。分析が成功したら、「次へ」をクリックします。

8. 「レビューおよびデプロイ」ページで、パッチ計画に対して指定した詳細を確認し、「ロールバック」をクリックして、計画に指定された対応するターゲットで選択済のパッチをロールバックします。

42.7 エンドツーエンド・ユースケース: データ・センターのパッチ適用

Enterprise Managerを使用してデータ・センター全体にパッチを公開する方法を説明するエンドツーエンド・ユースケースは、付録Eを参照してください。

42.8 サービス・プールとしてのデータベースのパッチ適用

サービス・プールとしてデータベースのパッチを適用するには、プール・メンテナンス・オプションを使用する必要があります。サービス・プールとしてデータベースのパッチを適用する方法の詳細は、『Enterprise Manager Cloud管理ガイド』の第18章「データベース・プールの保守」を参照してください。

また、エンタープライズ全体でソフトウェアを標準化して同種ソフトウェア構成を使用し、サブスクリプションに基づくソフトウェア・メンテナンスを実行するには、ソフトウェア標準化アドバイザ機能を使用します。

43 Linuxホストへのパッチ適用

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用してLinuxホストにパッチを適用する方法について説明します。この章の具体的な内容は次のとおりです。

- Linuxホストへのパッチ適用の概要

- Linuxホストにパッチを適用するためのデプロイメント・プロシージャについて

- サポートされているLinuxリリース

- Linuxパッチ適用のインフラストラクチャの設定

- Linuxホストへのパッチ適用

- その他の実行可能Linuxパッチ適用タスク

- Linux構成ファイルの管理

注意:
Enterprise Manager Ops Centerを使用してLinuxホストに対して更新またはパッチ適用を実行する方法を理解するには、『Oracle Enterprise Manager Ops Centerプロビジョニングおよび更新ガイド』のオペレーティング・システムの更新に関する章を参照してください。

43.1 Linuxホストへのパッチ適用の概要

Linuxホスト・パッチ適用は、特にデータ・センターやサーバー・ファームで、企業内のホストをセキュリティ修正および重要なバグ修正で常に更新するCloud Controlの機能です。Cloud Controlでこの機能を使用すると、次の操作が可能です。

- Unbreakable Linuxネットワーク(ULN)チャネルに基づいたLinux RPMリポジトリの設定

- ULNからのアドバイザ(正誤表)のダウンロード

- Linuxホストのグループを更新し、コンプライアンス情報を収集するLinuxパッチ適用グループの設定

- 非コンプライアンス・パッケージへのパッチ適用の許可

- ホストからのパッケージのロールバック/アンインストール

- RPMリポジトリおよびチャネルの管理(チャネルのクローニング、チャネル間でのパッケージのコピー、チャネルの削除)

- カスタム・チャネルへのRPMの追加

- 構成ファイル・チャネルの管理(チャネルの作成と削除、ファイルのアップロード、チャネル間でのファイルのコピー)

次に、Linuxパッチ適用に関連する概念を示します。

Linuxホスト

Linuxオペレーティング・システムを実行している、Cloud Controlのホスト・ターゲット。

Linuxパッチ適用グループ

RPMリポジトリの共通リストに関連付けられている管理対象Linuxホストのセット。各グループは、1つの更新スケジュールで構成されており、このスケジュールに基づき、グループ内のホストを関連付けられているRPMリポジトリで更新する再帰ジョブがトリガーされます。

Unbreakable Linuxネットワーク(ULN)

Unbreakable Linuxネットワーク(ULN)は、Oracle Linux用の更新を提供するためにオラクル社が開設しているWebサイトです。

ULNチャネル

チャネルはULN上のRPMパッケージのグループです。たとえば、el4_latestチャネルには、Oracle Linux 4用のすべてのパッケージが含まれています。

RPMリポジトリ

RPMリポジトリは、RPMパッケージとそのメタデータ(yum-archおよびcreaterepoを実行して抽出)が格納されているディレクトリです。RPMリポジトリには、HTTPまたはFTP経由でアクセスできます。複数のチャネルからのパッケージが格納されるように、RPMリポジトリを編成できます。
たとえば、/var/www/html/yum/Enterprise/EL4/latestには、ULN上のel4_latestチャネルからのパッケージを格納できます。

カスタム・チャネル

カスタムRPMパッケージのセットを格納するためにユーザーによって作成されるチャネル。カスタム・チャネルは、RPMリポジトリに追加できます。

構成チャネル

Linux構成ファイルのセットを格納するためにユーザーによって作成されるチャネル。構成チャネルをLinuxパッチ適用アプリケーションのGUIで使用すると、Linuxホストに構成ファイルをデプロイできます。

43.2 Linuxホストにパッチを適用するためのデプロイメント・プロシージャについて

Cloud Controlには、Linuxパッチ適用のために、次のデプロイメント・プロシージャがあります。

- Linuxホストのパッチ
このデプロイメント・プロシージャを使用すると、Linuxホストにパッチを適用できます。

- Linux RPMリポジトリ・サーバーの設定
このデプロイメント・プロシージャを使用すると、Linux RPMリポジトリ・サーバーを設定できます。Linux RPMリポジトリ・サーバーを設定するには、第43.4.2.2項を参照してください。

43.3 サポートされているLinuxリリース

Linuxパッチ適用では、次のリリースがサポートされています。

- Oracle Linux 4

- Oracle Linux 5

- Oracle Linux 6

- Red Hat Enterprise Linux 4

- Red Hat Enterprise Linux 5

- Red Hat Enterprise Linux 6

43.4 Linuxパッチ適用のインフラストラクチャの設定

この項では、Linuxパッチ適用の設定要件について説明します。特に、次の項目について説明します。

- Linuxパッチ適用機能を使用するための前提条件

- Linuxパッチ適用のためのRPMリポジトリの設定

- コンプライアンス・レポート用のLinuxパッチ適用グループの設定

43.4.1 Linuxパッチ適用機能を使用するための前提条件

Linuxパッチ適用機能を使用するには、次の前提条件を満たしてください。

1. 第2章に記載されている基本前提条件を満たすこと。

2. すべてのOracle Linux 6ターゲット・ホストに、yumをインストールします。すべてのOracle Linux 5ターゲット・ホストに、yumおよびup2dateをインストールします。

3. SUDOを使用して次のコマンドを有効にすること。

- /bin/cp

- /bin/rm

- /bin/chmod

- /sbin/chkconfig

- yum

- up2date

- sed

- rpm

43.4.2 Linuxパッチ適用のためのRPMリポジトリの設定

この項では、RPMリポジトリの設定方法について説明します。特に、次の項目について説明します。

- RPMリポジトリを設定するための前提条件

- パッチ適用のためのRPMリポジトリの設定

注意:
RPMリポジトリは共有の場所に設定できます。この構成はサポートされています。

43.4.2.1 RPMリポジトリを設定するための前提条件

RPMリポジトリの設定前に、次の前提条件を満たしてください。

- RedhatまたはOracle Linuxホストを特定して管理エージェントをインストールし、OMSを指すようにすること。このホストには、sudoパッケージがインストールされている必要があります。

- Oracleの販売担当者から有効なカスタマ・サポートID (CSI)番号を取得すること。
有効なCSI番号を取得した後、必ずULNアカウントを作成してください。ULNアカウントを作成するには、次のURLにアクセスしてください。

https://linux.oracle.com/register

- 次のURLからup2dateパッケージをダウンロードします。
https://linux.oracle.com/switch.html">>https://linux.oracle.com/switch.html

RPMリポジトリを設定するホストが次のいずれかのプラットフォームで実行されている場合は、ダウンロードしたパッケージをソフトウェア・ライブラリにアップロードします。

- Red Hat Enterprise Linux 4 (x86_64)

- Red Hat Enterprise Linux 4 (ia64)

- Red Hat Enterprise Linux 5 (i386)

- Red Hat Enterprise Linux 5 (x86_64)

- Red Hat Enterprise Linux 5 (ia64)

重要:
RPMリポジトリを設定するホストがOracle Linuxプラットフォーム上で実行中の場合、up2dateパッケージをソフトウェア・ライブラリにアップロードする必要はありません。

次の手順に従って、up2dateパッケージをソフトウェア・ライブラリにアップロードします。

注意:
マルチOMS設定の場合、次の手順の実行が必要なのは1つのOMSに対してのみです。

1. up2dateおよびup2date-gnomeをzipファイルに圧縮し、up2date_comp.zipという名前を付けます。

2. OMSのOracleホーム内にある<ORACLE_HOME>/sysman/metadata/swlib/patch/stageServerComponentsディレクトリにZIPファイルをコピーします。

3. OMSのOracleホーム内にあるソフトウェア・ライブラリのパッチ適用のエンティティ・メタデータ・ファイルswlib.xmlを編集し、ソフトウェア・ライブラリ・エンティティ「Up2date Package Component」のExternalIDをアップグレードします。
次の手順を実行します。

(1)次の場所にあるswlib.xmlファイルを開きます: $ORACLE_HOME/sysman/metadata/swlib/patch/。

(2)サブタグExternalIDを持つタグ<Entity name="Install up2date RPM">を検索します。

(3) ExternalIDの値を0.1増分します。

たとえば、ソフトウェア・ライブラリのExternalID内のエンティティの元の値が2.0の場合、値を0.1更新してExternalIDを2.1にアップグレードします。

4. 次のコマンドを実行して、ZIPファイルをソフトウェア・ライブラリにアップロードします。
$ emctl register oms metadata -service swlib -file $ORACLE_HOME/sysman/metadata/swlib -core

- RPMリポジトリを設定するホストの/var/www/html/ディレクトリに、1つのチャネル当たり60GB以上の空きディスク領域があることを確認します。

- Apacheがインストール済であり、ポート80でリスニング中であることを確認します。これを確認するために、URL: http://hostへの接続を試すことができます。
たとえば、http://h1.example.comなどです。これが機能した場合、Apacheがインストール済であり、ポート80でリスニング中であることが確定します。

- createrepoパッケージがRPMリポジトリ・ホストにインストールされていることを確認します。このパッケージを取得するには、el*_addonまたはol*_addonチャネルをサブスクライブします。

- yum-arch、uln-yum-proxyおよびyum-utilsパッケージがRPMリポジトリ・ホストにインストールされていることを確認します。yum-archおよびuln-yum-proxyパッケージを取得するには、add onsチャネルをサブスクライブします。yum-utilsパッケージを取得するには、latestチャネルをサブスクライブします。

- RPMリポジトリ・ホストでOracle Linux 6 (OL6)が実行中でなく、名前がol6_*形式のOL6チャネルをサブスクライブしている場合、OL6公開鍵を手動でインポートします。次の手順を実行します。

1. OL 6の鍵を次からダウンロードします。
http://public-yum.oracle.com/RPM-GPG-KEY-oracle-ol6

2. 鍵をホスト上の次のディレクトリに格納します。
/usr/share/rhn

3. 次のコマンドを実行します。
rpm --import /usr/share/rhn/RPM-GPG-KEY-oracle-ol6

- Enterprise ManagerユーザーにEM_LINUX_PATCHING_ADMINロールおよびFULL_LINUX_PATCHING_SETUP権限が付与されていることを確認します。Enterprise Managerユーザーにこれらが付与されていない場合、スーパー・ユーザーがこれらを付与します。

- RPMリポジトリを設定するホストに、Oracle GPG鍵がインストールされていることを確認します。
Oracle Linux 5またはOracle Linux 6プラットフォームを実行中のホストにOracle GPG鍵をインストールするには、 次のコマンドを実行します。

rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY

43.4.2.2 パッチ適用のためのRPMリポジトリの設定

最新のRPMパッケージおよびアドバイザをULNからダウンロードするRPMリポジトリを設定するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「パッチ適用設定」ページの「Linuxパッチ適用設定」タブで「RPMリポジトリの設定」をクリックします。

3. 「RPMリポジトリの設定」ページの「RPMリポジトリ・サーバー」セクションで、検索アイコンをクリックしてRPMリポジトリ・サーバーを選択します。ULNへのサブスクライブ用に割り当てられたホストを選択します。

4. 「資格証明」セクションで、通常ホスト資格証明ユーザーにステージ場所への書込み権限があること、および特権ホスト資格証明ユーザーがroot権限でsudoを使用できることを確認します。「適用」をクリックします。

5. デプロイメント・プロシージャの発行確認で、「Linux RPMリポジトリ・サーバーの設定」をクリックします。デプロイメント・プロシージャによってジョブが開始され、サブスクライブしたULNチャネルから最新のRPMパッケージおよびアドバイザがダウンロードされます。

6. (オプション)リフレッシュ・モードを30秒に変更する場合は、「データの表示」リストから「実行時間: 30秒リフレッシュ」を選択します。

7. 「ステップ」タブの「ステータスの詳細」セクションで、このステップのステータスをチェックします。ステップ「Up2dateのインストール」が完了するか、スキップされるまで待機します。

8. 手動ステップ「ULNに登録」のステータスをクリックして、ホストがULNに登録済であるかどうかを確認します。
ホストをULNに登録している場合、ターゲットを選択して「確認」をクリックし、「終了」をクリックしてメイン・フローに移動します。

ホストをULNに登録していない場合、Linuxホストで次の手順を実行します。

1. RPMリポジトリ・サーバー・マシンにログインします。

2. ホストがULNに接続できるかどうかを確認します。ホストがULNに直接接続できない場合、プロキシ・サーバーを使用するようにup2dateを構成できます。プロキシ・サーバーを使用したULNへのアクセスを構成するには、次の手順を実行します。

https://linux.oracle.com/uln_faq.html#9

3. 次のURLの手順に従ってホストをULNに登録します。

https://linux.oracle.com/uln_faq.html#2

注意:
登録時に、ユーザー名とパスワードを選択できます。この資格証明は、http://linux.oracle.com">>http://linux.oracle.comへのログインに使用されます。

9. ステップ「ULNチャネルにサブスクライブ」のステータスをクリックします。
LinuxサーバーをULNに登録すると、適切なアーキテクチャの最新のOracle Linuxパッケージがあるチャネルにサブスクライブされます。追加のチャネルをホストにサブスクライブする必要がない場合、ターゲットを選択して「確認」をクリックし、「終了」をクリックしてメイン・フローに移動します。

追加のチャネルをホストにサブスクライブする必要がある場合、次の手順を実行します。

1. ULNにログインします。
http://linux.oracle.com/

2. 「システム」タブをクリックして、サブスクライブした各サーバーのサブスクリプションを管理します。

3. 必要なすべての追加チャネルにサブスクライブします。

注意:

- Linuxホストにcreaterepoパッケージがインストールされていない場合、el*_addonまたはol*_addonチャネルをサブスクライブします。

- yum-arch、uln-yum-proxyおよびyum-utilsパッケージがLinuxホストにインストールされていることを確認します。yum-archおよびuln-yum-proxyパッケージを取得するには、add onsチャネルをサブスクライブします。yum-utilsパッケージを取得するには、latestチャネルをサブスクライブします。

4. サブスクライブしているチャネルのリストをULNで確認します。

10. デプロイメント・プロシージャが正常に終了したら、「設定」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

11. 「パッチ適用設定」ページの「Linuxパッチ適用設定」タブで、「RPMリポジトリの管理」をクリックしてULNチャネルがCloud Controlコンソールに表示されるかどうかを確認します。

12. 「RPMリポジトリの管理」ページで、サブスクライブしたチャネルがリストされているかどうかと、すべてのパッケージがダウンロードされているかどうかを確認します。

43.4.3 コンプライアンス・レポート用のLinuxパッチ適用グループの設定

この項では、グループと第43.4.2項で作成したRPMリポジトリ(サブスクライブした各ULNチャネルが1つのリポジトリ)を関連付けて、コンプライアンス・レポート用のLinuxパッチ適用グループを設定する方法について説明します。

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

- Linuxパッチ適用グループを設定するための前提条件

- Linuxパッチ適用グループの設定

43.4.3.1 Linuxパッチ適用グループを設定するための前提条件

Linuxパッチ適用グループの設定前に、次の前提条件を満たしてください。

- RPMリポジトリ・サーバーを設定するか、カスタムRPMリポジトリをCloud Controlでチャネルとして設定します。

- すべてのOracle Linux 6ターゲット・ホストに、yumをインストールします。すべてのOracle Linux 5ターゲット・ホストに、yumおよびup2dateをインストールします。

- Sudoをターゲット・ホストにインストールします。

- Enterprise ManagerユーザーにEM_LINUX_PATCHING_ADMINロールおよびFULL_LINUX_PATCHING_SETUP権限が付与されていることを確認します。Enterprise Managerユーザーにこれらが付与されていない場合、スーパー・ユーザーがこれらを付与します。

43.4.3.2 Linuxパッチ適用グループの設定

Linuxパッチ適用グループを設定するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「Linuxパッチ適用設定」ページで「パッチ適用グループの設定」をクリックします。

3. 「パッチ適用グループの設定」ページで、「作成」をクリックします。

4. 「グループの作成: プロパティ」ページで、グループの一意の名前を入力します。成熟度レベル、Linuxディストリビューションおよびグループに追加するLinuxホストを選択します。「次へ」をクリックします。

5. 「グループの作成: パッケージ・リポジトリ」ページで、パッチ適用グループに関連付ける必要のあるRPMリポジトリを選択します(検索アイコンをクリックしてリポジトリを選択します)。
「GPG署名のチェック」セクションで、「GPG署名のチェック」を選択し、yumまたはup2dateにより、指定したリポジトリから取得したパッケージでGPG署名チェックが実行されていることを確認します。yumまたはup2dateには、リポジトリから取得したパッケージを検証するために公開GPGキーが必要な場合があります。このキーは、事前にRPMデータベースにインポートできません。このキーを確実にインポートするには、「GPGキーのインポート」を選択して、GPGキーのURLを指定します。

「ステージングの場所」セクションで、Linuxへのパッチ適用構成およびログ・ファイルを作成する場所を指定します。

「ホストの更新」セクションで、ホストを自動更新する、つまり更新ジョブ(後続ステップの1つとして指定されるスケジュール)をスケジュールして選択したパッケージ・リポジトリからの非コンプライアンス・パッケージをすべて更新する場合は、「ホストを自動的に更新」を選択します。

「除外するパッケージ」セクションの「除外するパッケージ」で、Linuxホストへのパッチ適用中に更新しないパッケージのリストを指定します。パッチ適用プロセス中に更新しないパッケージのリストがファイルにある場合、「ファイルからインポート」をクリックしてファイルの場所を指定します。ウィザードに、指定したファイルから必要なパッケージが表示されます。

「最終更新セッションのロールバック」セクションで、「最終更新セッションのロールバックの有効化」を選択し、パッチ適用を元に戻すウィザード内のグループに対して、最終更新セッションのロールバック機能を有効にします。ここで、この機能を有効にしない場合、パッチ適用を元に戻すウィザードにグループが表示されません。

「パッケージ・コンプライアンス」セクションで、コンプライアンス・レポートにローグ・パッケージを含めるかどうかを選択します。

「再起動時に更新されたパッケージ」セクションの「再起動時に更新されたパッケージ」で、ホストの再起動時にのみ更新する必要のあるパッケージのリストを指定します。

6. 「次へ」をクリックします。

7. 「グループの作成: 資格証明」ページで、ホスト資格証明を入力するか、優先資格証明の使用を選択します。「次へ」をクリックします。

8. 「グループの作成: パッチ適用スクリプト」ページで、実行するパッチ適用前またはパッチ適用後の操作を入力します。この手順は必須ではありません。「次へ」をクリックします。

注意:
手順(8)、(9)は、「ホストを自動的に更新」を選択しなかった場合、スキップします。

9. 「スケジュール」ページで、更新ジョブのスケジュールを設定します。「次へ」をクリックします。

10. 「確認」ページで、すべてのパラメータを確認します。「終了」をクリックします。

11. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。生成されたコンプライアンス・レポートを確認します。作成されたグループには、最新でないパッケージが少なくとも1つあります。
表43-1では、Linuxパッチ適用グループを設定するために発行されるジョブについて説明します。

表43-1 Linuxパッチ適用グループを設定するために発行されるジョブ

ジョブ

説明

パッチ適用構成

このジョブは、パッチ適用のためにすべてのホストを構成します。各ホストのyumおよびup2dateツールで使用される構成ファイルを作成します。

このジョブは、Linuxパッチ適用グループに含まれるすべてのホストでただちに1回のみ実行されます。

コンプライアンスの収集

Linuxパッチ適用グループに含まれる各マシンにすでにインストール済のパッケージのバージョンを、選択したRPMリポジトリ内のパッケージ・バージョンと比較して、どのパッケージが期限切れかを示すコンプライアンス・レポートを生成します。

このジョブは、Linuxパッチ適用グループに含まれるすべてのホストで24時間に1度(グループが設定された後)実行されます。

パッケージ情報

選択したRPMリポジトリに含まれる各パッケージのメタデータ情報を収集します。

このジョブは、毎日実行されます。

パッケージの更新

非コンプライアンス・パッケージを更新します。

このジョブでグループ内のホスト上にインストールされたパッケージが更新され、そのグループのパッケージ・リポジトリが最新になります。Linuxパッチ適用グループ・ウィザードのステップ「パッケージ・リポジトリ」でオプション「ホストの更新」が選択されており、そのスケジュールをステップ「スケジュール」でカスタマイズできる場合のみ、このジョブは発行されます。

43.5 Linuxホストへのパッチ適用

この項では、Linuxホストにパッチを適用する方法を説明します。内容は次のとおりです。

- コンプライアンスに基づくLinuxパッチ適用グループへのパッチ適用

- Linuxホストへのアド・ホック・パッチまたは緊急パッチの適用

重要:
Linuxホストにパッチを適用する前に、Enterprise ManagerユーザーにEM_PATCH_DESIGNERロールおよびOPERATOR_ANY_TARGET権限が付与されていることを確認します。Enterprise Managerユーザーにこれらが付与されていない場合、スーパー・ユーザーがこれらを付与します。

43.5.1 コンプライアンスに基づくLinuxパッチ適用グループへのパッチ適用

Linuxパッチ適用コンプライアンス・ホーム・ページで、特定のLinuxパッチ適用グループが非準拠であることが報告された場合、そのグループにパッチを適用するよう選択できます。このLinuxパッチ適用グループにパッチを適用するには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「Linuxパッチ適用」ページの「コンプライアンス・レポート」セクションで、パッチを適用するLinuxパッチ適用グループを選択して「パッチのスケジュール」をクリックします。

3. 「パッケージ・リポジトリ」ページの「Linuxディストリビューション」セクションで、RPMの更新に使用するツールを選択します。YellowDog Updater modified (yum)およびup2dateは、Linuxホストへのパッチ適用に一般的に使用される2つのツールです。

注意:
パッチ適用するLinuxホストがOracle Linux 6 (OL6)で実行されている場合、パッチ適用にはyumツールを使用する必要があります。このLinuxバージョンでは、up2dateパッチ適用ツールはサポートされていません。このシナリオでyumを使用しない場合、パッチ適用プロセスは「パッチ適用のためのホストの構成」ステップで次のエラーにより失敗します。
このシステム内のRPMを更新するためのツールとしてyumを選択していません。yumはOracle Linux 6オペレーティング・システム内のRPMを更新するためにサポートされている唯一のツールです。

(yumをパッチ適用ツールとして選択した場合のみ)使用するパッチ適用モードが選択されていることを確認します。既存のパッケージを更新し、さらに新しいパッケージをインストールする場合は、パッケージの更新および新しいパッケージのインストールを選択します。既存のパッケージの更新のみを行い、新しいパッケージをインストールしない場合は、「パッケージの更新のみ」を選択します。

「ステージングの場所」セクションで、Linuxへのパッチ適用構成およびログ・ファイルを作成する場所を指定します。

「パッケージ・リポジトリ」セクションで、使用するRPMリポジトリを選択します。

「GPG署名のチェック」セクションで、「GPG署名のチェック」を選択し、yumまたはup2dateにより、指定したリポジトリから取得したパッケージでGPG署名チェックが実行されていることを確認します。yumまたはup2dateには、リポジトリから取得したパッケージを検証するために公開GPGキーが必要な場合があります。このキーは、事前にRPMデータベースにインポートできません。このキーを確実にインポートするには、「GPGキーのインポート」を選択して、GPGキーのURLを指定します。

「詳細オプション」セクションでは、デフォルトで「無効な更新を非表示」オプションが選択されています。このオプションを選択すると、「更新の選択」ページで無効なパッケージが非表示になります。これらのパッケージを「更新の選択」ページで表示する場合は、このオプションを選択解除してください。

(yumをパッチ適用ツールとして選択した場合のみ)「詳細オプション」セクションで、次のいずれかのパッチ・アプリケーション・モードを選択します。

- 最も適したアーキテクチャ: パッチ適用しているLinuxホストにインストールされる適切なRPMアーキテクチャに対して、yumを使用して選択したパッケージの最新バージョンをインストールするか、またはパッケージの既存のバージョンを最新バージョンに更新する場合。
このオプションを選択した場合、Cloud Controlにより次のyumコマンドが実行されます。

yum install|update packagename

- 特定のアーキテクチャ: 選択したパッケージのRPMアーキテクチャを持つLinuxホストのみに、yumを使用して選択したパッケージの最新バージョンをインストールするか、またはパッケージの既存のバージョンを最新バージョンに更新する場合。
このオプションを選択した場合、Cloud Controlにより次のyumコマンドが実行されます。

yum install|update packagename.arch

- 特定のバージョンとアーキテクチャ: 選択したパッケージのRPMアーキテクチャを持つLinuxホストのみに、yumを使用して「更新の選択」ページで選択したパッケージの特定のバージョンのみをインストールするか、またはパッケージの既存のバージョンをこの特定のバージョンに更新する場合。
このオプションを選択した場合、Cloud Controlにより次のyumコマンドが実行されます。

yum install|update epoch:packagename-ver-rel.arch

「次へ」をクリックします。

4. 「更新の選択」ページで、更新するパッケージを選択します。

注意:
前の手順で「無効な更新を非表示」オプションが選択されている場合、「使用可能な合計パッケージ」および「このビューで使用可能な合計パッケージ」の値が異なる場合があります。この相違は、リポジトリ内に存在する無効なパッケージの数に対応しています。

「次へ」をクリックします。

5. 「ホストの選択」ページで、更新するLinuxホストを選択します。また、ターゲット・タイプをグループに変更して、グループを選択することもできます。
デフォルトでは、検出されたすべてのLinuxホストがこのページに表示され、選択できます。ただし、(前の手順で更新操作に選択した)少なくとも1つのパッケージの以前のバージョンを持つホストのみをこのページに表示する場合、次のコマンドを実行します。

$<OMS_HOME>/bin/emctl set property -name 'oracle.sysman.core.ospatch.filter_uptodate_hosts' -value 'true'

「次へ」をクリックします。

6. 「資格証明」ページで、更新に使用する資格証明を入力します。
「次へ」をクリックします。

7. 「前処理/後処理スクリプト」ページで、パッチ適用プロセスの前後に実行する必要のあるスクリプト(存在する場合)を入力します。
「次へ」をクリックします。

8. 「スケジュール」ページで、使用する必要のあるパッチ適用スケジュールの詳細を入力します。
「次へ」をクリックします。

9. 「確認」ページで、更新パラメータを確認します。
「終了」をクリックします。デプロイメント・プロシージャが発行され、選択したパッケージが更新されます。正常に完了するまで、プロシージャのすべてのステップを実行します。

43.5.2 Linuxホストへのアド・ホック・パッチまたは緊急パッチの適用

アド・ホックな方法でまたは緊急時に、Linuxパッチ適用グループを使用せずにLinuxホストに素早くパッチを適用するには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「プロシージャ・ライブラリ」の順に選択します。

2. 「デプロイメント・プロシージャ・マネージャ」ページの「プロシージャ・ライブラリ」タブで、「Linuxホストのパッチ」を選択して「起動」をクリックします。

3. 「パッケージ・リポジトリ」ページの「Linuxディストリビューション」セクションで、RPMの更新に使用するツールを選択します。YellowDog Updater modified (yum)およびup2dateは、Linuxホストへのパッチ適用に一般的に使用される2つのツールです。

注意:
パッチ適用するLinuxホストがOracle Linux 6 (OL6)で実行されている場合、パッチ適用にはyumツールを使用する必要があります。このLinuxバージョンでは、up2dateパッチ適用ツールはサポートされていません。このシナリオでyumを使用しない場合、パッチ適用プロセスは「パッチ適用のためのホストの構成」ステップで次のエラーにより失敗します。
このシステム内のRPMを更新するためのツールとしてyumを選択していません。yumはOracle Linux 6オペレーティング・システム内のRPMを更新するためにサポートされている唯一のツールです。

(yumをパッチ適用ツールとして選択した場合のみ)ツール操作モードの場合、「パッケージの更新および新しいパッケージのインストール」が選択されていることを確認します。Linuxパッチ適用グループを使用せずにLinuxホストにパッチを適用するこの方法は、緊急時を対象としており、コンプライアンス・レポートに基づいていないため、新しいパッケージのインストールのみに使用でき、既存のパッケージは更新できません。

「ステージングの場所」セクションで、Linuxへのパッチ適用構成およびログ・ファイルを作成する場所を指定します。

「パッケージ・リポジトリ」セクションで、使用するRPMリポジトリを選択します。

「GPG署名のチェック」セクションで、「GPG署名のチェック」を選択し、yumまたはup2dateにより、指定したリポジトリから取得したパッケージでGPG署名チェックが実行されていることを確認します。yumまたはup2dateには、リポジトリから取得したパッケージを検証するために公開GPGキーが必要な場合があります。このキーは、事前にRPMデータベースにインポートできません。このキーを確実にインポートするには、「GPGキーのインポート」を選択して、GPGキーのURLを指定します。

「詳細オプション」セクションでは、デフォルトで「無効な更新を非表示」オプションが選択されています。このオプションを選択すると、「更新の選択」ページで無効なパッケージが非表示になります。これらのパッケージを「更新の選択」ページで表示する場合は、このオプションを選択解除してください。

(yumをパッチ適用ツールとして選択した場合のみ)「詳細オプション」セクションで、次のいずれかのパッチ・アプリケーション・モードを選択します。

- 最も適したアーキテクチャ: パッチ適用しているLinuxホストにインストールされる適切なRPMアーキテクチャに対して、yumを使用して選択したパッケージの最新バージョンをインストールするか、またはパッケージの既存のバージョンを最新バージョンに更新する場合。
このオプションを選択した場合、Cloud Controlにより次のyumコマンドが実行されます。

yum install|update packagename

- 特定のアーキテクチャ: 選択したパッケージのRPMアーキテクチャを持つLinuxホストのみに、yumを使用して選択したパッケージの最新バージョンをインストールするか、またはパッケージの既存のバージョンを最新バージョンに更新する場合。
このオプションを選択した場合、Cloud Controlにより次のyumコマンドが実行されます。

yum install|update packagename.arch

- 特定のバージョンとアーキテクチャ: 選択したパッケージのRPMアーキテクチャを持つLinuxホストのみに、yumを使用して「更新の選択」ページで選択したパッケージの特定のバージョンのみをインストールするか、またはパッケージの既存のバージョンをこの特定のバージョンに更新する場合。
このオプションを選択した場合、Cloud Controlにより次のyumコマンドが実行されます。

yum install|update epoch:packagename-ver-rel.arch

「次へ」をクリックします。

4. 「更新の選択」ページで、更新するパッケージを選択します。

注意:
前の手順で「無効な更新を非表示」オプションが選択されている場合、「使用可能な合計パッケージ」および「このビューで使用可能な合計パッケージ」の値が異なる場合があります。この相違は、リポジトリ内に存在する無効なパッケージの数に対応しています。

「次へ」をクリックします。

5. 「ホストの選択」ページで、更新するLinuxホストを選択します。また、ターゲット・タイプをグループに変更して、グループを選択することもできます。
デフォルトでは、検出されたすべてのLinuxホストがこのページに表示され、選択できます。ただし、(前の手順で更新操作に選択した)少なくとも1つのパッケージの以前のバージョンを持つホストのみをこのページに表示する場合、次のコマンドを実行します。

$<OMS_HOME>/bin/emctl set property -name 'oracle.sysman.core.ospatch.filter_uptodate_hosts' -value 'true'

「次へ」をクリックします。

6. 「資格証明」ページで、更新に使用する資格証明を入力します。
「次へ」をクリックします。

7. 「前処理/後処理スクリプト」ページで、パッチ適用プロセスの前後に実行する必要のあるスクリプト(存在する場合)を入力します。
「次へ」をクリックします。

8. 「スケジュール」ページで、使用する必要のあるパッチ適用スケジュールの詳細を入力します。
「次へ」をクリックします。

9. 「確認」ページで、更新パラメータを確認します。
「終了」をクリックします。デプロイメント・プロシージャが発行され、選択したパッケージが更新されます。正常に完了するまで、プロシージャのすべてのステップを実行します。

43.6 Linux構成ファイルの管理

この項では、Linux構成ファイルを管理する方法を説明します。内容は次のとおりです。

- Linux構成ファイルの概要

- 構成ファイルを管理するための前提条件

- Linux構成ファイル・チャネルの作成

- 特定のチャネルへのLinux構成ファイルのアップロード

- チャネル間でのLinux構成ファイルのインポート

- 特定のチャネルからのLinux構成ファイルのデプロイ

- Linux構成ファイル・チャネルの削除

43.6.1 Linux構成ファイルの概要

構成ファイル機能を使用すると、Linux構成ファイルを効率的で簡単な方法で管理できます。この機能(「Linuxパッチ適用」ホームページからアクセス)を使用すると、Linux構成ファイル・チャネルを作成して、ローカル・ホスト(または管理エージェントがデプロイされたリモート・ホスト)にある必要なLinux構成ファイルを作成したチャネルにアップロードし、1回の操作でチャネル内の構成ファイルを多数のターゲット・ホストにデプロイできます。

この機能により、Linux構成ファイルを各ターゲット・ホストに手動でコピーする手間を省くことができます。たとえば、多数のターゲット・ホストにコピーするHTTPサーバー構成ファイルがローカル・ホストにある場合、「Linuxパッチ適用」ホームページを使用してLinux構成ファイル・チャネルを作成し、このチャネルにHTTPサーバー構成ファイルをアップロードして、ターゲット・ホストにそのファイルをデプロイできます。

43.6.2 構成ファイルを管理するための前提条件

ソフトウェア・ライブラリがOMSですでに構成されていることを確認してください。

43.6.3 Linux構成ファイル・チャネルの作成

構成ファイル・チャネルを作成するには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「Linuxパッチ適用」ページで、「構成ファイル」タブをクリックします。

3. 「構成ファイル」タブで、「構成ファイル・チャネルの作成」をクリックします。

4. 「構成ファイル・チャネルを作成します」ページで、一意のチャネル名とチャネルの説明を入力して「OK」をクリックします。
新しい構成ファイル・チャネルを作成することを示す確認メッセージが表示されます。

43.6.4 特定のチャネルへのLinux構成ファイルのアップロード

この項では、特定のチャネルに構成ファイルをアップロードする方法を説明します。この項の具体的な内容は次のとおりです。

- Linux構成ファイルをアップロードするための前提条件

- Linux構成ファイルのアップロード

43.6.4.1 Linux構成ファイルをアップロードするための前提条件

特定のチャネルに構成ファイルをアップロードする前に、ローカル・ホストまたはリモート・ホストに1つ以上の構成ファイルがあることを確認します。

43.6.4.2 Linux構成ファイルのアップロード

構成ファイルをアップロードするには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「Linuxパッチ適用」ページで、「構成ファイル」タブをクリックします。

3. 「構成ファイル」タブで、構成ファイルをアップロードするチャネルを選択し、「構成ファイルのアップロード」をクリックします。

4. 適切なアップロード・モードを選択します。(ブラウザを実行している)ローカル・ホストまたはリモート・ホスト(管理エージェントがインストールされているホストで、管理エージェントはOMSと通信している必要があります)のいずれかからファイルをアップロードできます。

5. 「ファイルのアップロード」セクションで、ファイル名、ファイルがデプロイされるターゲット・ホストのパスを入力し、アップロード・ホストのファイルを参照します。

6. リモート・マシンからアップロードする場合は、「エージェント・マシンからアップロード」をクリックします。「ターゲットの選択」をクリックし、リモート・マシンを選択します。
このマシンのファイルを参照する前に、このマシンの優先資格証明を設定します。

7. ファイルを選択したら、「OK」をクリックします。
ファイルがアップロードされたことを示す確認メッセージが表示されます。

43.6.5 チャネル間でのLinux構成ファイルのインポート

この項では、チャネル間で構成ファイルをインポートする方法を説明します。この項の具体的な内容は次のとおりです。

- Linux構成ファイルをインポートするための前提条件

- Linux構成ファイルのインポート

43.6.5.1 Linux構成ファイルをインポートするための前提条件

構成ファイルをインポートする前に、チャネルが少なくとも2つ存在することを確認してください。

43.6.5.2 Linux構成ファイルのインポート

構成ファイルをソース・チャネルからターゲット・チャネルにインポートするには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「Linuxパッチ適用」ページで、「構成ファイル」タブをクリックします。

3. 「構成ファイル」タブで、ソース・チャネルを選択し、「ファイルのインポート」をクリックします。

4. ターゲット・チャネルを選択します。

5. 「ソース・チャネル」セクションから、ファイルを選択して「ターゲット・チャネル」セクションにコピーします。「OK」をクリックします。
選択したファイルが正常にインポートされたことを示す確認メッセージが表示されます。

43.6.6 特定のチャネルからのLinux構成ファイルのデプロイ

この項では、特定のチャネルから構成ファイルをデプロイする方法を説明します。この項の具体的な内容は次のとおりです。

- Linux構成ファイルをデプロイするための前提条件

- Linux構成ファイルのデプロイ

43.6.6.1 Linux構成ファイルをデプロイするための前提条件

構成ファイルをデプロイする前に、次の前提条件を満たしてください。

- 特権パッチ適用ユーザーに、各構成ファイルがステージングされるターゲット・マシンの場所への書込み権限があり、またSUDO権限もあることを確認します。

- アップロード済の複数のファイルで構成されるチャネルが少なくとも1つ存在すること。

43.6.6.2 Linux構成ファイルのデプロイ

特定のチャネルから構成ファイルをデプロイするには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「Linuxパッチ適用」ページで、「構成ファイル」タブをクリックします。

3. 「構成ファイル」タブで、ソース・チャネルを選択し、「ファイルのデプロイ」をクリックします。

4. 表示されたウィザードで、デプロイするファイルを選択して「次へ」をクリックします。

5. 「追加」をクリックして、ファイルをデプロイするターゲットを選択します。

6. 選択したターゲットの資格証明を入力します。

7. ファイルのデプロイ前またはデプロイ後に実行する前処理/後処理スクリプトを入力します。

8. デプロイ・パラメータを確認して「終了」をクリックします。
「デプロイ」ジョブが発行されます。正常に完了するまで、ジョブのリンクを実行します。

43.6.7 Linux構成ファイル・チャネルの削除

この項では、構成ファイル・チャネルを削除する方法について説明します。この項の具体的な内容は次のとおりです。

- Linux構成ファイル・チャネルを削除するための前提条件

- Linux構成ファイル・チャネルの削除

43.6.7.1 Linux構成ファイル・チャネルを削除するための前提条件

構成ファイル・チャネルを削除する前に、構成ファイルが少なくとも1つ存在することを確認してください。

43.6.7.2 Linux構成ファイル・チャネルの削除

構成ファイル・チャネルを削除するには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「Linuxパッチ適用」ページで、「構成ファイル」タブをクリックします。

3. 「構成ファイル」タブで、チャネルを選択して「削除」をクリックします。「はい」をクリックします。
チャネルが正常に削除されたことを示す構成メッセージが表示されます。

43.7 その他の実行可能Linuxパッチ適用タスク

この項では、「Linuxパッチ適用」ホームページを使用して実行できる追加タスクについて説明します。

- Linuxパッチ適用コンプライアンス履歴の表示

- 非コンプライアンスLinuxパッケージへのパッチ適用

- Linuxパッチ更新セッションのロールバックまたはパッケージの削除

- カスタム・パッケージ・チャネルの登録

- パッケージ・チャネルのクローニング

- チャネル間でのパッケージのコピー

- チャネルへのカスタム・パッケージの追加

- パッケージ・チャネルの削除

43.7.1 Linuxパッチ適用コンプライアンス履歴の表示

この項では、特定期間の選択したグループのコンプライアンス履歴を表示する方法について説明します。この項の具体的な内容は次のとおりです。

- Linuxパッチ適用コンプライアンス履歴を表示するための前提条件

- Linuxパッチ適用コンプライアンス履歴の表示

43.7.1.1 Linuxパッチ適用コンプライアンス履歴を表示するための前提条件

- Linuxパッチ適用グループを少なくとも1つ定義しておくこと。

- パッチ適用グループで構成されるLinuxホストに対して表示権限を持っていること。

43.7.1.2 Linuxパッチ適用コンプライアンス履歴の表示

Linuxパッチ適用グループのコンプライアンス履歴を表示するには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「コンプライアンスのホーム」ページの「関連リンク」セクションで、「コンプライアンス履歴」をクリックします。

3. 「コンプライアンス履歴」ページの「グループ」表には、すべてのアクセス可能なLinuxパッチ適用グループと、各グループに対応するホストの数がリストされます。

4. 複数のLinuxパッチ適用グループが存在する場合、「コンプライアンス履歴」ページには、その表にリストされた最初のグループの履歴データ(特定期間)が表示されます。

5. Linuxパッチ適用グループのコンプライアンス履歴を表示するには、そのグループに対応する「表示」アイコンをクリックします。

注意:
デフォルトでは、表示されるコンプライアンス・データは過去7日間から取得されたものです。これより長い期間のコンプライアンス履歴を表示するには、「データの表示」ドロップダウン・リストから適切な値を選択します。ページがリフレッシュされ、選択した期間のコンプライアンス・データが表示されます。

43.7.2 非コンプライアンスLinuxパッケージへのパッチ適用

この項では、「Linuxパッチ適用」ホームページから非コンプライアンス・パッケージにパッチを適用する方法について説明します。この項の具体的な内容は次のとおりです。

- 非コンプライアンスLinuxパッケージにパッチを適用するための前提条件

- 非コンプライアンスLinuxパッケージへのパッチ適用

43.7.2.1 非コンプライアンスLinuxパッケージにパッチを適用するための前提条件

非コンプライアンス・パッケージにパッチを適用する前に、Linuxパッチ適用グループを作成し、「コンプライアンスの収集」ジョブが正常に終了していることを確認してください。

43.7.2.2 非コンプライアンスLinuxパッケージへのパッチ適用

非コンプライアンス・パッケージにパッチを適用するには、次の手順を実行します。

1. Linuxホストのパッチ・ウィザードで必要な詳細をインタビュー画面に指定し、「確認」ページで「終了」をクリックします。

2. デプロイメント・プロシージャが発行され、ホストが更新されます。すべてのステップが正常に終了したかどうかをチェックします。

43.7.3 Linuxパッチ更新セッションのロールバックまたはパッケージの削除

この項では、パッチ更新セッションをロールバックする方法、あるいはパッチ・バージョンが不適切で、バグまたはセキュリティ上の脆弱性があることがわかった場合に、不安定なバージョンを完全にアンインストールする方法について説明します。この項の具体的な内容は次のとおりです。

- Linuxパッチ更新セッションのロールバックまたはパッケージの削除の前提条件

- Linuxパッチ更新セッションのロールバックまたはパッケージの削除

注意:

- アップグレードのロールバックは、特定のエクステントにサポートされています。OEL 5.2からOEL 5.3にといったアップグレードを実行すると、他のRPMに依存している多くのRPMがアップグレードされます。RPMへの適用時には、この依存性を追うことができます。ただし、パッチ更新セッションのロールバック時には、この依存性を逆の順序で追う必要があります。この逆操作は、yumまたはup2dateではサポートされていません。そのため、パッチ更新セッションのロールバックには、ロールバック機能を使用します。ただし、OEL 5.2からOEL 5.3にといったメジャー・アップグレードを完全にロールバックすることはできません。

- アップグレードのロールバックは、Oracle Linux 6で実行中のホストではサポートされていません。

43.7.3.1 Linuxパッチ更新セッションのロールバックまたはパッケージの削除の前提条件

パッチ更新セッションのロールバックまたはパッケージの削除の前に、次の前提条件を満たしてください。

- Linuxパッチ適用グループが作成されていること。

- パッケージの下位バージョンがRPMリポジトリに存在することを確認します。

43.7.3.2 Linuxパッチ更新セッションのロールバックまたはパッケージの削除

パッチ更新セッションをロールバックするか、またはパッケージをアンインストールするには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「Linuxパッチ適用」ページの「コンプライアンス・レポート」セクションで、グループを選択して「パッチ適用を元に戻す」をクリックします。

3. 「パッチ適用を元に戻す: アクション」ページで、適切なオプションを選択します。

- パッケージのアンインストール: パッケージを削除します。

- 最終更新セッションのロールバック: 前回のパッチ更新セッションの効果を元に戻します。

4. 「次へ」をクリックします。

5. 必要な詳細をウィザードに指定し、「確認」ページで「終了」をクリックします。

6. ジョブが発行され、前回のセッションで実行された更新がロールバックされます。

7. 発行されたジョブを調べ、すべてのステップが正常に終了したかどうかを確認します。

43.7.4 カスタム・パッケージ・チャネルの登録

この項では、カスタム・チャネルを登録する方法について説明します。この項の具体的な内容は次のとおりです。

- カスタム・パッケージ・チャネルを登録するための前提条件

- カスタム・パッケージ・チャネルの登録

43.7.4.1 カスタム・パッケージ・チャネルを登録するための前提条件

カスタム・チャネルを登録する前に、次の前提条件を満たしてください。

- RPMリポジトリが/var/www/htmlの下にあり、HTTPプロトコルでアクセスできること。

- Apacheがインストール済であり、ポート80でリスニング中であることを確認します。これを確認するために、URL: http://hostへの接続を試すことができます。
たとえば、http://h1.example.comなどです。これが機能した場合、Apacheがインストール済であり、ポート80でリスニング中であることが確定します。

- yum-archコマンドとcreaterepoコマンドを実行して、メタデータ・ファイルを作成していること。

- 管理エージェントがRPMリポジトリ・ホストにインストールされており、OMSと通信していること。

- Enterprise Managerユーザーが、カスタム・チャネルを登録するためのスーパー・ユーザー権限でログインしていることを確認します。

43.7.4.2 カスタム・パッケージ・チャネルの登録

カスタムRPMリポジトリを登録するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「パッチ適用設定」ページの「Linuxパッチ適用設定」タブで「RPMリポジトリの管理」をクリックします。

3. 「リポジトリの管理」ホームページで、「カスタム・チャネルの登録」をクリックします。

4. 「カスタム・チャネルの登録」ページで、一意のチャネル名を入力します。

5. 「参照」をクリックして、カスタムRPMリポジトリを設定したホストを選択します。

6. RPMリポジトリが存在するパスを入力します。ディレクトリの場所は、/var/www/html/で始まる必要があります。

7. 「OK」をクリックします。
パッケージ情報ジョブが発行されます。正常に完了するまで、ジョブを実行します。

43.7.5 パッケージ・チャネルのクローニング

この項では、チャネルをクローニングする方法について説明します。この項の具体的な内容は次のとおりです。

- パッケージ・チャネルをクローニングするための前提条件

- パッケージ・チャネルのクローニング

43.7.5.1 パッケージ・チャネルをクローニングするための前提条件

チャネルをクローニングする前に、次の前提条件を満たしてください。

1. チャネルが少なくとも1つ存在すること。

2. ターゲット・チャネル・ホストに十分な領域があること。

3. ソース・ホストのステージング場所にcreateLikeSrcという名前のディレクトリがないこと、およびターゲット・チャネルのディレクトリが存在しないことを確認します。

4. Apacheがインストール済であり、ポート80でリスニング中であることを確認します。これを確認するために、URL: http://hostへの接続を試すことができます。
たとえば、http://h1.example.comなどです。これが機能した場合、Apacheがインストール済であり、ポート80でリスニング中であることが確定します。

5. Enterprise Managerユーザーがスーパー・ユーザー権限でOMSにログインしていることを確認します。

43.7.5.2 パッケージ・チャネルのクローニング

チャネルをクローニングするには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「パッチ適用設定」ページの「Linuxパッチ適用設定」タブで「RPMリポジトリの管理」をクリックします。

3. 「RPMリポジトリの管理」ページで、クローニングするソース・チャネルを選択し、「類似作成」をクリックします。

4. ソース・チャネルに使用する資格証明を入力します。この資格証明には、読取り権限と書込み権限の両方が必要です。

5. 一意のターゲット・チャネル名を入力します。

6. 「参照」をクリックして、ターゲット・ホスト名を選択します。

7. ターゲット・チャネルのディレクトリの場所を入力します。このディレクトリは、/var/www/htmlの下にあります。

8. ターゲット・チャネルに使用する資格証明を入力します。この資格証明には、読取り権限と書込み権限の両方が必要です。

9. 「OK」をクリックします。
「類似作成」ジョブが発行されます。正常に完了するまで、ジョブを実行します。

43.7.6 チャネル間でのパッケージのコピー

この項では、チャネル間でパッケージをコピーする方法について説明します。この項の具体的な内容は次のとおりです。

- チャネル間でパッケージをコピーするための前提条件

- チャネル間でのパッケージのコピー

43.7.6.1 チャネル間でパッケージをコピーするための前提条件

チャネル間でパッケージをコピーする前に、次の前提条件を満たしてください。

1. チャネルが少なくとも2つ存在すること。

2. ターゲット・チャネル・マシンに十分な領域があること。

3. ソース・ホストのステージング場所にcopyPkgsSrcという名前のディレクトリがないこと、およびターゲット・ホストのステージング場所にcopyPkgsDestという名前のディレクトリがないことを確認します。

4. Apacheがインストール済であり、ポート80でリスニング中であることを確認します。これを確認するために、URL: http://hostへの接続を試すことができます。
たとえば、http://h1.example.comなどです。これが機能した場合、Apacheがインストール済であり、ポート80でリスニング中であることが確定します。

5. Enterprise Managerユーザーがスーパー・ユーザー権限でOMSにログインしていることを確認します。

43.7.6.2 チャネル間でのパッケージのコピー

チャネル間でパッケージをコピーするには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「パッチ適用設定」ページの「Linuxパッチ適用設定」タブで「RPMリポジトリの管理」をクリックします。

3. 「RPMリポジトリの管理」ページで、ソース・チャネルを選択し、「パッケージのコピー」をクリックします。

4. ターゲット・チャネルを選択します。

5. 「ソース・チャネル」セクションから、パッケージを選択して「ターゲット・チャネル」セクションにコピーします。

6. ソース・チャネルとターゲット・チャネルの資格証明を入力します。これらの資格証明には、読取り権限と書込み権限の両方が必要です。

7. 「OK」をクリックします。
「パッケージのコピー」ジョブが発行されます。正常に完了するまで、ジョブを実行します。

43.7.7 チャネルへのカスタム・パッケージの追加

この項では、カスタム・パッケージをチャネルに追加する方法について説明します。この項の具体的な内容は次のとおりです。

- カスタム・パッケージをチャネルに追加するための前提条件

- チャネルへのカスタム・パッケージの追加

43.7.7.1 カスタム・パッケージをチャネルに追加するための前提条件

カスタム・パッケージをチャネルに追加する前に、次の前提条件を満たしてください。

1. チャネルが少なくとも1つ存在すること。

2. ソース・ホストのステージング場所にaddPkgsSrcという名前のディレクトリがないこと、および宛先チャネルのステージング場所にaddPkgsDestという名前のディレクトリがないことを確認します。

43.7.7.2 チャネルへのカスタム・パッケージの追加

カスタムRPMをチャネルに追加するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「パッチ適用設定」ページの「Linuxパッチ適用設定」タブで「RPMリポジトリの管理」をクリックします。

3. 「RPMリポジトリの管理」ページで、RPMを追加するチャネル名を選択し、「追加」をクリックします。

4. ソース・ターゲット名とホストに使用する資格証明を選択します。使用する資格証明には、ソース・ホストのemd_emstagedirディレクトリへの書込みアクセス権が必要です。

5. 「ファイルのアップロード」セクションで、検索アイコンをクリックしてRPMファイルを参照します。

6. 選択チャネルでの書込みアクセス権を持つ通常ホスト資格証明を選択します。

7. 選択チャネルでの書込みアクセス権を持ち、root権限としてSUDO権を持つ特権ホスト資格証明を選択します。

8. 「OK」をクリックします。
「パッケージの追加」ジョブが発行されます。正常に完了するまで、ジョブを実行します。

43.7.8 パッケージ・チャネルの削除

この項では、チャネルを削除する方法について説明します。この項の具体的な内容は次のとおりです。

- パッケージ・チャネルを削除するための前提条件

- パッケージ・チャネルの削除

43.7.8.1 パッケージ・チャネルを削除するための前提条件

チャネルを削除する前に、次の前提条件を満たしてください。

1. チャネルが少なくとも1つ存在すること。

2. Enterprise Managerユーザーがスーパー・ユーザー権限でOMSにログインしていることを確認します。

43.7.8.2 パッケージ・チャネルの削除

チャネルを削除するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから、「プロビジョニングとパッチ適用」、「Linuxパッチ適用」の順に選択します。

2. 「パッチ適用設定」ページの「Linuxパッチ適用設定」タブで「RPMリポジトリの管理」をクリックします。

3. 「RPMリポジトリの管理」ページで、削除するチャネル名を選択し、「削除」をクリックします。

4. RPMリポジトリ・マシンからパッケージを削除する場合、チェック・ボックスを選択してRPMリポジトリ・マシンの資格証明を入力します。「はい」をクリックします。

5. RPMリポジトリ・マシンからパッケージを削除することを選択しなかった場合、「パッケージ・チャネル<チャネル名>は正常に削除されました」という確認メッセージが表示されます。パッケージの削除オプションを選択した場合、ジョブが発行されてRPMリポジトリ・マシンからパッケージが削除されます。正常に完了するまで、ジョブを実行します。

第X部

構成、コンプライアンスおよび変更管理

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

- 第44章「構成情報の管理」

- 第45章「コンプライアンスの管理」

- 第47章「データベース・スキーマ変更の管理」

- 第48章「リアルタイム監視の追加設定」

44 構成情報の管理

この章では、Oracle Enterprise Manager Cloud Control (Cloud Control)を使用して、エンタープライズ内のデプロイメントを簡単に監視および管理する方法について説明します。

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

- 構成管理の概要

- 構成検索の概要

- 構成ブラウザの概要

- 構成履歴の概要

- 比較とテンプレートの概要

- 構成拡張および収集の概要

- パーサーの概要

- クライアント構成の概要

- 関係の概要

- 構成トポロジ・ビューアの概要

44.1 構成管理の概要

Cloud Controlでは、エンタープライズ全体のすべての管理対象ターゲットに関する情報が収集されます。収集された構成情報は、HTTPまたはHTTPSで管理リポジトリに定期的に送信され、Cloud Controlを介してエンタープライズ全体の最新の構成情報にアクセスできます。

Cloud Controlは、Enterprise Managerで認識されたすべての管理対象ターゲットについて収集された構成情報を表示、保存、追跡、比較、検索およびカスタマイズする機能を備えています。さらに、構成トポロジ・ビューアでは、ターゲットと他のターゲットの関係がビジュアルなレイアウトで示されます。たとえば、システムのメンバーとその相互関係を表示することで、システムの構造を判断できます。

表44-1に、ターゲット・タイプの小さいサンプリングについて収集された構成情報の一部を例として示します。

表44-1 各種ターゲットの収集済構成

ターゲット・タイプ

収集される構成情報

ホスト脚注1

- ハードウェア(メモリー、CPU、I/Oデバイス、ネットワーク情報など)

- オペレーティング・システム(インストールされたパッチとパッチ・セットなど)

- Oracleソフトウェア(インストール済の製品とそれらのコンポーネント、パッチ・セット、OPatchを使用して適用された個別パッチなど)

- その他のソフトウェア(オペレーティング・システムに登録されたすべてのソフトウェアなど)

データベース脚注2

- データベースおよびインスタンスのプロパティ

- 初期化およびシステム・グローバル領域のパラメータ

- 表領域、データファイルおよび制御ファイル情報

- REDOログ、ロールバック・セグメントおよび高可用性情報

- ライセンス情報

ミドルウェア(WebLogicサーバーなど)

- ノード・マネージャ、マシン、WebサービスおよびWebサービス・ポートの構成

- リソース・アダプタ(アウトバウンドなど)

- WebおよびEJBモジュール

- サーバー情報

- JDBCデータソースおよびマルチ・データソース

- リソース使用率

- 仮想ホスト

- 起動クラスと停止クラス

- Jolt接続プール

- ワーク・マネージャ

- JMSトピック、キューおよびコネクション・ファクトリ

- ネットワーク・チャネル

Elastic Cloud Infrastructure

- スイッチの詳細

- ストレージ・アプライアンスの詳細

- コンピュータ・ノードの詳細(関連するホスト・ターゲットのGUIDも含む)

- スイッチ・ポートの構成

- ネットワーク・トポロジ(スイッチ・ポートとデバイスの関連付けのメトリック)

VMサーバー・プール

- サーバー・プールの構成詳細(ディスク領域の合計、使用可能メモリーなど)

- VMゲスト・メンバーの詳細

VMサーバー・メンバーの詳細

クライアント脚注3

- ハードウェア

- オペレーティング・システム(プロパティ、ファイル・システム、パッチなど)

- オペレーティング・システムに登録されたソフトウェア

- ネットワーク・データ(Webサーバーへの待機時間と帯域幅)

- クライアント固有のデータで、クライアント構成収集アプレットのアクセスに使用したブラウザの構成を記述したもの

- その他のクライアント指向型データ項目

Oracle以外のシステム

- ハードウェア詳細(ベンダー、アーキテクチャ、CPU、I/Oデバイス情報など)

- オペレーティング・システム詳細(名前、バージョン、ソフトウェアとパッケージのリスト、カーネル・パラメータ、ファイル・システム情報など)

- OS登録済ソフトウェア(製品名、ベンダー、場所、インストール時間など)

脚注1 ホスト構成情報のデフォルト収集時間は24時間です。

脚注2 データベース構成情報のデフォルト収集時間は12時間です。

脚注3 詳細は、この章の第44.8項を参照してください。

Cloud Controlを使用してエンタープライズ構成を管理します。

- 収集された構成データの検索

- 構成の比較

- 最新かつ保存済の構成、ならびにインベントリおよび使用率の詳細の表示

- 構成履歴の変更の監視

- 構成拡張の構築およびカスタム・ターゲット・タイプの導入

- 外部クライアント構成の収集および分析

- 根本原因分析と影響分析の実行

注意:
構成管理に関する視覚的なデモを表示するには、次のURLで提供されているビデオ「Oracle Enterprise Manager 12c: Database Lifecycle - Manage Configuration」をご覧ください。

https://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:5775,1

44.2 構成検索の概要

構成検索を使用して、エンタープライズ全体の構成データを検索します。Cloud Controlには即時利用可能な一連の構成検索が含まれており、これを使用して、収集した大量の構成データの確認を始めることができます。検索結果を操作する際は、検索基準を調整して結果を絞り込み、または拡大し、変更後の結果を新しい名前で保存できます。

検索フィルタ、オプションおよび関連性を機能的に組み合せることで、エンタープライズ全体の強力な検索を実行します。次に検索の例を示します。

- デュアルコアCPUを持つすべてのホストの表示

- 100MBのデータファイルが少なくとも1つあるすべての表領域の表示

- Linux 5.6ホストにインストールされているすべてのOracleホームの表示

- 初期化パラメータp1およびp2の値がそれぞれv1とv2である全データベース・インスタンスの検索

検索フィルタリング基準を向上させるには、独自のSQL問合せ文を追加します。興味深い検索結果は、レポートに出力するかファイルにエクスポートして保存します。

検索機能にアクセスするには、「エンタープライズ」メニューから「構成」を選択し、「検索」を選択します。構成検索の設定および実行の詳細は、Cloud Controlオンライン・ヘルプを参照してください。

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

- 構成検索の管理

- 検索の設定

- 検索シナリオの確認

注意:
構成検索に関する視覚的なデモを表示するには、次のURLで提供されているビデオ「Oracle Enterprise Manager 12c: Configuration Search」を視聴してください。

https://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:6047,1

44.2.1 構成検索の管理

構成検索ライブラリには、そのままで、または類似した検索のための基礎として使用できるOracle提供およびユーザー作成の構成の検索が含まれています。または、最初から検索を作成するよう選択することもできます。

構成検索ライブラリにアクセスするには、「エンタープライズ」メニューから「構成」を選択し、「検索」を選択します。

既存の構成の検索ですべてのターゲット・タイプを検索するか、基準を使用して検索を絞り込みます。検索名および所有者フィールドは包含を識別するため、部分的な名前としてテキスト文字列を指定して、名前または所有者に文字列を含むすべての検索を見つけることができます。「検索」をクリックすると、結果がページ下部の表に表示されます。

ライブラリの構成検索を選択して、「実行」をクリックして、検索を実行します。検索の実行に適用される検索パラメータを反映する新しいページが表示され、結果があればページ下部に結果が表示されます。

次の追加タスクを実行します。

- 既存の構成検索を編集するには、表で検索を選択し、「編集」をクリックします。検索を構成する検索パラメータを示している新しいページが表示されます。目的の結果を得るように、検索基準を変更します。問題がない場合、検索を保存します。「保存」によって、既存の検索が上書きされます。「別名保存」によって、編集した検索を新しい名前で保存できます。Oracle提供の検索で作業している場合、別名保存を使用します。

- 既存の検索に基づいて新しい検索を作成するには、表で検索を選択し、「類似作成」をクリックします。開いたダイアログで、コピーされた検索の名前を指定します。表で新しい行を選択し、「編集」をクリックします。検索パラメータに目的の変更を行って、新しい名前で保存します。

- 既存の検索を削除するには、表で検索を選択し、「削除」をクリックします。開いたダイアログで、操作を確認します。検索を削除するには、所有者または管理者である必要があります。使用中の検索は削除できません。即時利用可能な検索は削除しないことをお薦めします。

44.2.2 検索の設定

構成の検索を作成、類似作成または編集する場合は、次の手順に従います。

1. 基本の基準を指定します。これを行うには、「よく使用される検索基準」を展開する必要がある場合があります。ターゲット・タイプを選択すると、その選択内容によりその他の基準の値のリスト(選択したターゲット・タイプの使用可能な構成アイテム・タイプなど)が決まります。
メンバーであるターゲット・タイプを検索するには、システムまたはグループを選択します。または、特定のホスト上のすべてのターゲット・タイプを検索します。

2. 「関係」をクリックし、ターゲット・タイプを他のターゲットに関連付けます。たとえば、選択したホストを監視している管理エージェントを確認できます。

3. 組込み機能を使用して、プロパティのフィルタ基準を追加します。

- ドロップダウン・リストから構成説明を選択できます。これにより、アイテム内のすべてのプロパティのフィールド・エントリがページに移入されます。

- 右側にある「プロパティ」をクリックします。これにより、ダイアログが表示され、特定の構成アイテム内にドリルダウンし、フィルタ基準として含める特定のプロパティを選択できます。

このため、たとえば、ターゲット・タイプ・ホストの場合、ドロップダウン・リストからファイルシステム構成アイテムを選択し、6つすべてのプロパティのプロパティ・フィルタを取得できます。または、「プロパティ」をクリックし、ダイアログ(「オペレーティング・システム」の「ファイル・システム」)内でドリルダウンし、特定のフィルタ・プロパティ(「リソース名」や「マウント位置」など)を選択できます。

4. 追加するプロパティ・フィルタごとに、演算子の選択や値の指定によって式を作成します。たとえば、ハードウェアという構成アイテムにはコアCPU数プロパティがあります。演算子>を選択して2を指定し、2を超えるコアCPU数に検索を絞り込みます。演算子にはワイルドカードを使用できます。%を指定してすべてに一致するようにします。包括演算子はワイルドカードを示しており、値なしで包括を指定すると、すべてのものと一致します。
各プロパティ・フィルタの横にあるチェックマークを使用して、検索結果にプロパティを含めるよう指定します。検索時にプロパティ値を参考にするだけで十分で、不要な列で結果を散乱させたくない場合もあります。この場合、結果に表示したくないプロパティの選択を解除します。

5. 選択した構成のアイテム・タイプの「拡張オプション」をクリックして、アイテムに指定されたフィルタのすべてと照合するか、または1つと照合するかを指定し、検索結果に表示する内容を調整します。

6. 基準を追加しながら「検索」をクリックして結果を表示します。結果が満足できるものになるまでフィルタを追加および削除して検索を修正し続けます。
検索結果表内の列名は、表示対象として指定および選択するフィルタが連結されたものです。このため、たとえば、ターゲット・タイプ・ホストのハードウェア・ベンダー名をフィルタ処理する場合、検索結果表内の列名は「ホストのハードウェア・ベンダー名」のようになります。

7. 構成の検索の特性を反映したわかりやすい名前を付けて検索を保存します。

納得のいく結果が得られない場合

すべてのフィルタ基準を指定しても、検索結果が不十分な場合があります。検索をさらに絞り込むには、「SQLを使用した検索」をクリックします。表示されるダイアログで、SQL問合せ文を編集して検索の式を拡張し、検索を再実行することができます。この場合、ビューを使用することに注意してください。基になっている表にはアクセスできません。SQLの編集内容が適用されるのは現在実行している検索のみであるため、編集した文を保存する場合は、今後の使用に備えてテキスト・ファイルにコピーして貼り付けておきます。

拡張オプション

フィルタの設定または条件(あるいはその両方)以外にも、「拡張オプション」ダイアログを使用して、結果の観点から表示する内容を指定します。ダイアログのタイトルは、ダイアログを起動したコンテキストを反映しています。つまり、フィルタを設定する構成のアイテム・タイプおよびアイテムが表示されます。

- 一致条件を適切に設定します。つまり、構成アイテム・プロパティで、1つの基準と照合するか、すべての基準と照合するかを指定します。

- EXISTS条件は次のように設定します:

- None: EXISTS条件はありません。プロパティ値を含め、検索基準を満たすすべてのターゲットに対して結果が表示されます。

- EXISTS: 指定したプロパティ値が含まれるすべてのターゲット(たとえば、パッチ13343438が適用されたすべてのデータベース・インスタンスなど)に対して結果が表示されます。パッチ・プロパティ値は検索基準に指定されていないため、検索結果に含まれません。

- NOT EXISTS: 指定したプロパティ値が含まれていないすべてのターゲット(たとえば、パッチ13343438が適用されていない、すべてのデータベース・インスタンスなど)に対して結果が表示されます。パッチ・プロパティ値は検索基準に指定されていないため、検索結果に含まれません。

最初の選択オプションは、一致するエンティティのみでなく、実際のプロパティ値も戻します。残りのオプションは一致するエンティティのみを戻します。

拡張オプション設定が表示され、それぞれのレベルにカッコが付けられます。そのため、たとえば、フィルタを任意、選択を検索基準を満たすハードウェアがないに設定すると、ハードウェアの後に(拡張オプション - 一致: 任意のプロパティ・フィルタ; 条件: NOT_EXISTS)が表示されます。優先順位は上位から下位なので、下位レベルは上位のオーバーライド設定の設定です。

シナリオ結果の処理

検索結果が興味深いもので保存する価値がある場合、必要に応じて次のように結果をエクスポートして印刷できます。

- 「エクスポート」をクリックし、エクスポート・ダイアログの指示に従い、結果をCSVファイルに保存します。

- 「印刷」をクリックし、結果の印刷先を選択します。

44.2.3 検索シナリオの確認

インタフェースの使用例として、簡単な検索をいくつか次に示します。例では、構成検索ライブラリを開き、「作成」ボタンをクリックしたものとします。検索を設定する際のベスト・プラクティスとして即時利用可能な検索を確認します。

特定のホストで実行中のWebLogic Serverターゲットを見つける

1. ターゲット・タイプとして「Oracle WebLogic Server」を選択します。

2. 共通基準領域で「対象ホスト」検索アイコンをクリックし、ホストを特定します。

3. 「検索」ボタンをクリックして、検索を実行します。
ページの下部に結果が表示されます。

コアCPUが2超のホストで稼働しているデータベース・インスタンスの検索

1. ターゲット・タイプに「データベース・インスタンス」を選択します。

2. 「関係」をクリックし、開いたダイアログで、「ホスト」を選択します。「OK」をクリックします。

3. ホスト基準レベルで「プロパティ」をクリックします。

4. 表示されたダイアログで「ハードウェア」を展開し、「コアCPU数」を選択して「OK」をクリックします。

5. コアCPU数を> 2に制限します。スクロール・ダウンしてプロパティを見つけます。

6. 「検索」ボタンをクリックして、検索を実行します。
ページの下部に結果が表示されます。

表領域のステータスがONLINEの100MBより大きいデータファイルの検索

1. ターゲット・タイプに「データベース・インスタンス」を選択します。

2. 「プロパティ」をクリックします。

3. 開いたダイアログで、次を実行します。

1. 「表領域」を展開し、「ステータス」を選択します。

2. スクロール・ダウンして「データファイル」を展開し、「サイズ」を選択します。(複数選択するには、[Ctrl]を押しながらクリックします)。

3. 「OK」をクリックします。

4. 表領域ステータスをis ONLINEに制限します。

5. データファイルのサイズを> 104857600に制限します。

6. すべての条件に一致するオプションが設定されていることを確認し、「検索」ボタンをクリックして検索を実行します。
ページの下部に結果が表示されます。

44.3 構成ブラウザの概要

単一の管理対象エンティティの構成データを表示するには、構成ブラウザを使用します。構成データの内容は次のとおりです。

- 構成アイテムとプロパティ

- すべてのシステム・メンバーとその構成データ、およびシステム構成データ

- システムおよびターゲットの関係(即時、メンバー所属先、使用、使用者など)

- 構成拡張収集データ

ブラウザ・ウィンドウは左右のペインで構成されています。左ペインはツリー階層です。右ペインには、表に情報が表示されたタブがあります。ツリー内を移動すると、選択されているもののコンテンツが右ペインに表示されます。選択内容に応じて、プロパティと値、関係、システムとそのメンバーの階層構造、ファイル・コンテンツなどのデータが、解析された形式とRAWテキスト形式の両方で含まれるタブが表示されます。

ブラウザで構成を表示しながら、複数あるアクションのいずれかを実行できます。これらのアクションは、タブの上にある「アクション」メニューから実行できます。左ペインのツリー階層にも使用可能なコンテキスト・メニューがあります。

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

- 構成データの表示

- 保存済の構成の処理

- インベントリと使用状況の詳細の処理

44.3.1 構成データの表示

構成ブラウザによって、ターゲットの最新または保存済の構成データを表示できます。構成データの表示中に、比較や履歴などの構成機能にアクセスできます。

1. 「ターゲット」メニューから「すべてのターゲット」を選択します。

2. 返されたターゲットの表の、目的のターゲットの行で右クリックします。

3. ポップアップ・メニューで、「構成」を選択し、「最新収集」または「保存済」を選択します。保存済の構成の場合、保存済構成の表で参照する構成を選択し、「表示」をクリックします。ブラウザが開き、選択したターゲットの(最新または保存済の)構成データが表示されます。
これらの選択(「最新収集」および「保存済」)は、左上隅に表示されるターゲットのホームページの「構成」メニューで使用でき、通常、ホストやWebキャッシュなどのターゲット・タイプの名前を取得することに注意してください。

4. ターゲット・タイプによってブラウザの表示は異なります。

- 標準のターゲットの場合、左側のツリー階層の最上部にターゲット・ノードが表示され、その下に構成アイテム・カテゴリとネストした構成アイテムが表示されます。ターゲット・ノードを選択すると、右側のタブにターゲットのプロパティと様々な関係(即時、メンバー所属先、使用、使用者)が表示されます。即時の関係は、方向(ソースおよび宛先)を示します。このため、たとえばデータベースのソース・ターゲット・タイプには、ホストの宛先ターゲット・タイプとの即時の関係(ホストされる)があります。
左側のツリーを移動すると、右側のタブはツリーで選択されたものになり、表の行に選択されたもののプロパティと値が表示されます。たとえば、ターゲット・タイプがホストで、左側のツリーで「ハードウェア」を選択すると、右側のタブがハードウェアになり、表の行にホスト名、ドメイン、ベンダー名などの値が表示されます。表の表示が変更されたときは、右下隅を参照して、表に含まれる行数を確認します。複数行の表では、検索フィルタを使用して特定のプロパティおよび値へドリルダウンします。必要に応じて検索フィルタを追加します。

- ターゲット・タイプがシステムの場合、左側のツリー階層には次のものが表示されます。

- 最上位レベルにルート・ターゲット

- ルート・ターゲットに関連付けられている構成アイテムごとに、1レベル下にネストした1つのノード

- メンバー・タイプごとに、ネストしたノードと同じレベルの1つのフォルダ

- メンバー・フォルダ下のメンバー・タイプ内のメンバーごとに1つのノード

ルート・ターゲットを選択すると、右側のタブにターゲットのプロパティ、システム・トポロジ表および様々な関係(即時、メンバー所属先、使用、使用者)が表示されます。左側のツリーで構成アイテムを選択すると、右側のタブにアイテムのプロパティと値が表示されます。これには、ルート・ターゲットに関連付けられている構成アイテムのみが該当することに注意してください。左側でメンバー・ターゲットを選択すると、右側のタブにメンバー・ターゲットのプロパティが表示されます。ただし、ターゲットの構成データは表示されないことに注意してください。

メンバー・ターゲットの構成データを確認するには、メンバーを右クリックし、「最新の構成」を選択する必要があります。ブラウザの表示が、標準ターゲットと同じになります。左側のツリー階層の上にブレッドクラムがあり、システム・ビューに戻ることができます。その後、メンバー構成を保存すると、構成データへのリンクが「保存された構成」に変わります。

- 左側のツリー内の構成拡張ファイルを選択します。右側の表の個別のタブに、ファイルの解析済ビューおよびRAWテキスト・ビューが表示されます。

5. ターゲットのすべてのメンバーの構成詳細を表示するには、「構成レポート」をクリックします。これにより、すべての構成詳細が、ダウンロード可能なzipファイルにエクスポートされます。XLSファイルを抽出して、メンバーのすべての構成詳細を表示します。

6. (オプション)この構成のスナップショットを保存する場合、タブの上の「アクション」ドロップダウン・メニューで、「最新を保存」を選択します。表示されたダイアログで、構成を区別するための説明を入力し、「ジョブの発行」をクリックします。「OK」をクリックして、ダイアログを終了します。保存操作は、ターゲット・ツリー・ノードを選択して右クリックで表示されるメニューからも行えます。構成を保存すると、選択されたターゲットのすべての構成と関係データが保存されます。すべてのメンバー・ターゲットの関係と構成データも保存されます。

7. 「アクション」メニューの他のオプションは次のとおりです。

- ホームページに戻る - 選択したターゲットのホームページに戻ります。

- エクスポート - ファイルの場所を参照し、構成をCSVファイルに保存できるダイアログが開きます。

- トポロジ - 表示されたターゲットの関係を示す構成トポロジ・ビューアが開きます。

- 比較 - 表示されたターゲットの構成が、他の構成と比較する構成として事前選択される、比較のワークフロー・ページが表示されます。

- 検索 - 表示されたターゲットが検索オブジェクトである、構成検索ページが表示されます。

- 履歴 - 表示されたターゲットの構成の履歴ページが表示されます。

- リフレッシュ - 表示されたターゲットの構成データの収集およびブラウザのツリー階層の後続のリフレッシュをトリガーします。最新の構成(最新の収集)を表示している場合のみ適用可能です。コンポジット・ターゲットに対する手動リフレッシュは、ターゲット自身にのみ適用され、メンバーには適用されないことに注意してください。

44.3.2 保存済の構成の処理

保存された構成は、今後の参照用に保存されたデータを収集したときのスナップショットです。保存されたデータを表示することも、比較の基準として使用することもできます。

標準の構成もコンポジット構成も保存できます。構成を保存すると、選択されたターゲットとすべてのメンバー・ターゲットのすべての構成アイテムと関係データが保存されます。

構成を保存するには、様々な方法があることに注意してください。

- すべてのターゲットの表が表示されているときにターゲットを右クリックし、「構成」を選択して「保存」を選択します。

- 直近に収集されたターゲットの構成が構成ブラウザに表示されているときに、「アクション」ドロップダウン・メニューから「最新を保存」を選択します。

保存(特に、システムまたはグループを含む場合)には数分かかることがあります。このため、パフォーマンス上の理由から、保存アクションでは、非同期に行われるジョブが発行されます。ジョブのステータスをチェックするには、次のようにします。

1. 「エンタープライズ」メニューから「ジョブ」、「アクティビティ」の順に選択します。

2. 「拡張検索」をクリックして、次の基準を指定します。

- 「ジョブ・タイプ」をECM保存(または「最新を保存」)に設定します。

- 「ターゲット・タイプ」を「ターゲットなし」に設定します。

3. 「実行」をクリックします。

4. 保存の詳細について検索結果をドリルダウンします。

保存済の構成を表示するには:

1. 「エンタープライズ」メニューから「構成」を選択し、「保存済」を選択します。

2. 保存済構成の表で、参照する構成を選択し、「表示」をクリックします。

3. 次のデータのカテゴリが表示されるようツリー階層を移動します。

- 管理対象エンティティ、構成アイテム、これらのプロパティおよび関係

- システム構造

- 構成拡張収集

保存済構成を構成ブラウザに表示することもできます。ターゲット・ツリー・ノードを右クリックし、「構成」を選択して「保存済」を選択します。

保存済の構成を比較するには:

1. 「エンタープライズ」メニューから「構成」を選択し、「保存済」を選択します。

2. 保存済構成の表で、比較する構成を選択し、「比較」をクリックします。

3. 選択した構成は、比較のワークフローで最初の構成になります。比較の設定プロセスを続行します。

以前にエクスポートした構成をインポートするには:

1. 「エンタープライズ」メニューから「構成」を選択し、「保存済」を選択します。

2. 「インポート」ボタンをクリックします。

3. 開いたダイアログで、エクスポートした構成データの場所を参照し、「インポート」をクリックします。
リフレッシュすると、インポートした構成が保存済構成の表に表示されます。

44.3.3 インベントリと使用状況の詳細の処理

インベントリと使用状況の詳細ページでは、次を行えます:

- エンタープライズ・ベースのホスト、データベース・インストレーションおよびFusion Middlewareインストレーションなどのデプロイ、または特定のターゲットのインベントリ・サマリーを表示します。

- 異なるディメンションのコンテキストでインベントリ・サマリーを表示します。たとえばホストのインベントリ・サマリーの場合は、プラットフォーム、ベンダーまたはOSのバージョンごとに表示できます。

- インベントリ詳細の複数レベルをドリルダウンします。

- タイムラインに沿ってグラフ化されているインベントリ数の傾向を参照します。グラフ・バーはビューの選択に一致するよう色分けされています。

- ロールアップ・オプションのインベントリ・データを色分けした割合別にブレークダウンするには、円グラフに切り替えます。

- ホスト(OSパッチ)とデータベース(適用されているパッチ)の場合、パッチ・インジケータをクリックしてパッチの詳細にリンクします。

- 選択内容を繰り返し修正し、新しい選択内容に基づいてグラフと詳細をリフレッシュします。

- デプロイメントと詳細の表をCSVファイルにエクスポートします。

インベントリと使用状況の詳細を表示するには:

1. 「エンタープライズ」メニューから「構成」を選択し、「インベントリと使用状況の詳細」を選択します。
また、グリッド・サマリー・ページの「インベントリおよび使用状況」リージョンの「詳細を表示」をクリックすることもできます。

2. 調査するエンティティを選択し、ロールアップ・オプションを選択します。たとえば、プラットフォームごとにロールアップされたすべてのデプロイ済ホストを表示します。選択時にページが自動的にリフレッシュされることに注意してください。

3. パッチ更新については、「はい」をクリックして、パッチの詳細を表示します。

4. ラジオ・ボタンを選択して、インベントリ・グラフの表示方法を指定します。

- トレンド・グラフにはタイムラインに沿ってインベントリ数が表示されます。虫眼鏡アイコンを使用して、ビューをズームします。グラフの下の水平スクロール・バーをスライドして、日付範囲を調整できます。

- 円グラフには、選択したロールアップ・オプションのインベントリ・データがパーセント別に目立つように色分けされています。

5. 「表ビュー」をクリックし、トレンド・グラフを表形式に変換します。表を閉じると、グラフ表示に戻ります。

6. デプロイ表内の1つ以上の行を選択し、「詳細の表示」ボタンをクリックし、選択した行に基づいてグラフおよび詳細表をリフレッシュします。

7. 最上位表の任意の行に、最大数に占めるパーセントを表す数の横にカウント・バーがあります。たとえば、プラットフォームのホストの最大数が4である場合、2つのプラットフォーム上に表されるホストのバーの長さは半分になります。バーをクリックすると、詳細表および行のグラフがリフレッシュされます。

マスター(デプロイ)表または詳細表はエクスポートできます。いずれの場合も、「エクスポート」ボタンをクリックするとダイアログが開き、ファイルの場所に移動し、表をCSVファイルとして保存できます。

44.4 構成履歴の概要

構成履歴は、1年間に記録された管理対象エンティティ(ターゲット)に行われた変更のログです。構成の変更と関係の変更の両方が履歴に記録されます。関係とは、管理対象エンティティ間に存在するアソシエーションです。

構成履歴は、エンタープライズ全体の変更アクティビティを監視する強力なツールです。次のような使用方法があります。

- 前月のOracle RACシステムのパフォーマンスが低下していることに気付きました。管理者として、その期間に発生した変更を把握する場合に便利です。メンバーが追加または削除されたか。システム自体の構成変更が発生したか。

- 日勤の管理者が、検出された変更内容が適用されたパッチの結果であることに気付き、その結果に関する注釈を追加します。夜勤の管理者が変更についてのアラートを受信し、フォローアップに関する注釈を見られます。

- 本番ホストへのハードウェア・メモリーの変更が検出されました。管理者は、この領域での今後すべての変更に関し、継続してITグループを転送することにします。管理者は、本番ホストのハードウェア・メモリーへの変更履歴のみを確認し、そのような変更内容のITグループを通知する再帰ジョブをスケジュールできます。

構成履歴を表示して、次のことを実行できます。

- 検索条件を指定して絞り込むことで、一定期間のターゲットへの変更を追跡できます。

- 変更履歴を表示し、情報の表示方法を操作できます。

- 変更履歴の一部となる変更レコードにコメント付きで注釈を付けることができます。注釈にはタイムスタンプと所有者が含まれます。

- 履歴検索をスケジュールし、同じ条件に基づいて今後の変更を取得できます。

- スケジュール済履歴ジョブのステータスを表示できます。

- 今後変更が検出されたら他のユーザーに通知できます。

- 変更履歴の詳細をファイルに保存できます。

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

- 構成履歴へのアクセス

- 構成履歴の処理

- 履歴ジョブ・アクティビティの表示

44.4.1 構成履歴へのアクセス

次の方法のいずれかを使用して、構成履歴にアクセスします。

- 「エンタープライズ」メニューから「構成」を選択し、「履歴」を選択します。構成履歴の検索に進みます。

- すべてのターゲットの検索を実行します。戻されるターゲットの行を右クリックして、「構成」を選択して、ポップアップ・メニューの「履歴」を選択します。選択されたターゲットの結果を表示して、それぞれの検索基準フィールドのタイプおよび名前で識別します。異なる結果を表示するには、フィルタ基準を変更します。特定の構成アイテムなどを選択するか、日付範囲を変更します。

- ターゲット・ホームページで、「構成」を選択して、ターゲット・タイプ固有のメニュー(左上隅)の「履歴」を選択します。ターゲットの結果を表示して、それぞれの検索基準フィールドのタイプおよび名前で識別します。異なる結果を表示するには、フィルタ基準を変更します。特定の構成アイテムなどを選択するか、日付範囲を変更します。

44.4.2 構成履歴の処理

構成履歴内で次のタスクを実行します。

- 構成の変更履歴内でのドリルダウン

- 注釈やコメントの入力

- 繰返し行われる履歴検索のスケジュールと結果の送信

- 変更履歴のファイルへの保存

44.4.2.1 履歴の検索

様々なフィルタを使用して、構成の変更履歴の検索を調整します。

1. ターゲット・タイプから始めて基本検索基準を指定します。

- コンポジット・ターゲット・タイプ(システムまたはグループ)を選択した場合のみ、「メンバー・ターゲットの変更を含む」チェック・ボックスがアクティブになります。

- 参照アイコンをクリックして、対応するフィールドを選択するダイアログを開きます。ターゲット・タイプを選択するまでは、構成アイテムは非アクティブです。

- 構成アイテム・セレクタには、構成アイテムおよび関係の区切りタブが含まれています。これらは相互排他的です。

- 現在の日付から時間オフセットを選択するか、日付範囲を指定します。デフォルトは過去7日間です。

- 検索の範囲を特定のタイプの変更に制限します。たとえば、削除されたアイテムがある構成のみを検索します。

- 基準ベースのすべての履歴レコード表示するか、タイムスタンプおよびターゲットごとにグループ化するかを選択します。後者がデフォルトです。

2. 「フィルタの追加」ドロップダウン・リストから選択して拡張検索基準を指定します。

- 最上位の3つの選択肢(「メンバー所属先」、「ホスト上」、「注釈」)は定数です。たとえば、指定したテキストでコメントされた変更に検索を制限するには、注釈の部分テキストを入力します。

- ドロップダウン・リストの残りは、ターゲット・タイプに対して選択した構成アイテムによって異なります。ホストのハードウェア・ネットワーク・インタフェース・カードを選択すると、NICに適したプロパティがリストの残りに移入されます。

- アイコンは、リストのキー・フィールドを示します。たとえば、NIC名がキー・フィールドです。通常、キー・フィールドは時間とともに変更されないようにする必要があります。つまり、検索の制約は、キー以外のフィールドのように古い値、新しい値の形式で使用しません。

「フィルタの追加」リストから選択される各アイテムにより、検索基準に行が追加されます。

3. 「検索」をクリックして、操作をトリガーします。進行インジケータが実行中の検索アクティビティを検証します。最下部の表に結果が表示されます。

注意:
考慮すべき検索方法として、全体レベルの検索を実行して、変更のボリュームを確認します。元に戻り、フィルタを追加して、検索を絞り込みます。

履歴検索結果の処理

各行は、変更が検出され、変更が追加、削除または変更されたものから構成される場合の、検索基準を満たすターゲットを表しています。タブのカッコ内の数は、検出された対応する構成および関係の変更数に反映されます。関係のターゲット名で検索すると、すべてのソース・ターゲット、宛先ターゲットおよびターゲット名を含むターゲットでの一致を返します。

- 「リアルタイム監視の参照」をクリックして、コンプライアンス・ルールにより監視されるアクションを検索します。監視は、ユーザーがホストで実行したアクションまたはリアルタイム監視ルールで監視対象として構成されたターゲットです。

- 「エクスポート」をクリックして、検索結果をスプレッドシートなどのCSVファイルに保存します。各列の値はカンマ区切り値を表しています。

- 「履歴レコード」列の番号をクリックし、選択したターゲットで検出された変更を表示します。

変更された詳細表で、表の行を選択し、次のいずれかを実行します。

- 「詳細」をクリックし、ポップアップ・ウィンドウに変更詳細を表示します。これには古い値と新しい値、および注釈の詳細が含まれます。「変更のタイプ」列のChangeリンクが同じウィンドウにポップアップ表示されます。

- 「リアルタイム監視の参照」をクリックして、コンプライアンス・ルールにより監視されるアクションを検索します。監視は、ユーザーがホストで実行したアクションまたはリアルタイム監視ルールで監視対象として構成されたターゲットです。

- 「注釈の追加」をクリックして、変更に関するコメントを入力します。

- 「エクスポート」をクリックして、検索結果をスプレッドシートなどのCSVファイルに保存します。各列の値はカンマ区切り値を表しています。

44.4.2.2 構成変更への注釈の追加

構成変更に注釈を追加するには:

1. 結果表で変更する行を選択します。複数の行に同じ注釈を追加するには、複数選択機能([Ctrl] +クリックまたは[Shift] +クリック)を使用します。

2. 注釈の追加ボタンをクリックします。

3. ポップアップするウィンドウで、コメントを入力し、「OK」をクリックします。指定した列にコメントが表示されます。ログイン名およびタイムスタンプは、コメントに関連付けられ、変更詳細を表示するときに開くポップアップ・ウィンドウで使用できます。

コメントを入力した本人である(またはスーパー管理者権限がある)場合、注釈を削除することもできます。注釈が含まれる行を選択し、「注釈の削除」ボタンをクリックします。表示されたポップアップ・メッセージで削除を確認します。

44.4.2.3 履歴検索のスケジュールおよび通知リストの作成

変更履歴検索を、バックグラウンド・ジョブで実行するようにスケジュールできます(「スケジュールと通知」ボタンをクリックします)。検索は、一度のみまたは繰り返し実行するよう選択できます。即時または後日のいずれかで検索を実行します。検索結果へのリンクを送信する電子メール・アドレスを指定することもできます。

スケジュールされた履歴検索を、変更の発生時にアラートを生成する追跡メカニズムとして使用します。

1. ジョブのスケジュールを指定します。

- すぐに実行しない場合は、いつ実行するかを指定します。「後で」をクリックして、日時の選択が可能なカレンダ・ウィジェットをアクティブ化します。

- 頻度を指定します。ドロップダウン・リストでレポート頻度を選択します。デフォルトは一度のみです。

- 待機期間を指定します。ジョブがスケジュールどおりに実行されない場合は、指定された時間枠内で取り消されます。

- スケジュールを維持する期間を指定します。指定された期間の間ジョブ・スケジュールが維持されます。

2. 変更履歴の検索結果を知らせる相手の電子メール・アドレスを入力します。アドレスはカンマで区切ります。

3. 「OK」をクリックして、ジョブをスケジュールします。

44.4.2.4 履歴のファイルへの保存

選択した変更履歴のスナップショットを取得し、さらに確認するために、変更の詳細をCSVファイルに保存して、幅広いユーザーと共有できます。「エクスポート」をクリックし、エクスポート・ダイアログで指示に従います。

44.4.3 履歴ジョブ・アクティビティの表示

現在および過去のすべての履歴検索のリストを表示します。検索基準を使用して履歴ジョブのリストをフィルタします(「履歴ジョブ・アクティビティ」ボタンをクリックします)。たとえば、過去24時間以内に開始されたすべてのスケジュール済履歴検索を表示したり、過去31日以内に開始されて成功したホストを含むすべての履歴検索を表示します。31日より古い履歴ジョブはパージされます。

自分の権限を超えて表示できる履歴ジョブは、付与されているロールおよびアクセス・レベルによって異なります。

表の行を選択して「結果の表示」をクリックし、履歴検索が報告されたジョブ・ページに移動します。ここから、履歴検索によって検出された変更にドリルダウンできます。ジョブ名は、同じ場所まで移動するためのハイパーリンクです。ジョブ・ページ上のブレッドクラムを使用して、リストに戻ります。

ジョブ所有者であるか、適切なアクセス・レベルを有する場合、関係なくなった履歴ジョブを削除することによってリストのメンテナンスを実行できます。

44.5 比較とテンプレートの概要

この項では、テンプレート作成プロセスとプロセスにおけるルールの使用について説明します。また、比較の設定と、比較テンプレートの管理の情報も提供します。

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

- 比較テンプレートについて

- 比較テンプレートの使用

- ルールの指定

- ルールの式と構文について

- 例によるルールの理解

- 比較について

- 比較ウィザードの理解

- 比較結果の処理

44.5.1 比較テンプレートについて

比較テンプレートは、類似した構成の比較の微調整を行うための見本です。テンプレートは、特定のターゲット・タイプに関連付けられ、比較する構成アイテム・タイプ、アイテムおよびプロパティを決定します。デフォルトのテンプレート・セットでは、特定のターゲット・タイプをサポートする即時利用可能なものが提供されます。テンプレートによって、指定したターゲット・タイプの構成の比較時に、考慮する特定の設定を指定できます(たとえば、どのプロパティの違いを無視するか、およびどのプロパティの違いでアラートをトリガーするかなど)。制限を使用して、特定のプロパティの許容値を設定することもできます。制限に適合しない構成を比較すると、違いが発生します。

テンプレートは、比較の目的と一致するものがあるかどうか、または比較時に見つかった差異をいつ無視するかを決定する際に評価するためのルールまたは式を呼び出すことができます。

テンプレートは、そのまま使用したり、ガイドラインとして使用できます。このため、たとえば、若干の調整を行うだけで既存の比較テンプレートが要件に合うかどうかを判断できます。場合によっては、関心のあるプロパティの差異がテンプレートでは無視されることがあります。この場合、類似作成機能を使用して、既存のテンプレートを調整し、別の名前で保存します。

システムでは、システムを構成するターゲット・タイプに基づいて、メンバー・テンプレートを参照するシステム・テンプレートを設計します。システム・テンプレートを作成する前に、メンバー・テンプレートを作成します。

44.5.2 比較テンプレートの使用

この項では、比較テンプレートを作成、編集および管理する方法について説明します。

44.5.2.1 比較テンプレートの作成または編集

新規テンプレートを作成する場合、または既存のテンプレートを編集する場合、次の指示に従います。これには、擬似作成が含まれます。

1. 「エンタープライズ」メニューから「構成」を選択し、「比較テンプレート」を選択します。

2. テンプレートを検索するには、「検索」をクリックします。ターゲット・タイプ・リストの複数のターゲット・タイプに対して検索を実行できます。検索対象のターゲット・タイプを選択します。テンプレート名および所有者の名前も指定できます。また、テンプレートがデフォルトのテンプレートであるか、またはOracle提供のテンプレートであるかも指定できます。「検索」をクリックします。

3. 各テンプレートには、テンプレート名の隣にロックがあります。閉じたロックは、Oracle提供のテンプレートであることを表します。これらのテンプレートは編集できません。ロックが開いているテンプレートは、ユーザー定義の比較テンプレートで、編集できます。

4. 新規テンプレートについては、「作成」をクリックして名前およびターゲット・タイプを指定します。既存のテンプレートをベースにする場合は、テンプレート行を選択し、「類似作成」をクリックして名前を指定します。どちらの場合でも、その操作によって新規のテンプレートがすぐに作成されます。

5. 表内で適切なテンプレート行を選択して、「編集」ボタンをクリックします。「テンプレート設定」タブが表示されます。
比較された構成のターゲット・タイプにより、左側の構成アイテム・タイプおよび構成アイテムの階層が変わります。右側の対応するプロパティで有効な設定は、選択したテンプレートから導出されます。ただし、新規テンプレートを最初から作成する場合は例外で、この場合は設定は存在しません。

6. メンバーごとに比較テンプレートを作成または編集するには、「メンバー設定」タブを選択します。
ツリーまたは表のいずれかの形式でマッピングを表示するように選択できます。「マッピング表示」を「ツリー」に設定した場合は、「マッピングの表示」および「比較結果」に、システム・メンバーが階層ツリー形式で表示されます。「マッピング表示」を「表」に設定した場合は、「マッピングの表示」および「比較結果」に、システム・メンバーが表形式で表示されます。次の詳細を編集できます。

- オプションで、システム・メンバー・タイプごとに使用するメンバー・テンプレートを選択します。

- 一部のメンバー・タイプについて構成を比較しない場合には、チェック・ボックスの選択を解除します。

注意:
システム・メンバーのチェック・ボックスをクリアすると、このテンプレートを使用した比較時に、システム・メンバーの子インスタンスが自動的に無視されます。

- 比較するメンバー・タイプについて、照合キーとして使用するターゲット・プロパティを選択します。デフォルトはターゲット名ですが、比較対象をそろえるためには、部門や場所のように識別しやすいプロパティを使用するのが一般的です。

7. 「テンプレート設定」タブの左ペインで構成アイテム・タイプまたはアイテムを選択して、右ペインにそのプロパティを表示します。キー・アイコンは、構成アイテム・タイプのメタデータでキー列として定義されているプロパティを示します。

ヒント:
「テンプレート設定」タブの「比較」チェック・ボックス列に注意してください。これは強力な機能で、比較対象の構成アイテムを選択するのみで比較を効率的に実行できます。このチェック・ボックスを選択すると、比較エンジンは構成の比較時に対応する構成アイテム・タイプのみを対象にします。子アイテムは、親アイテムから独立しています。親を選択することなく、子アイテムを選択できます。
このため、たとえばホスト構成の比較で、CPUプロパティの差異のみを比較することを決定できます。ハードウェア構成のアイテム・タイプを展開し、「CPU」チェック・ボックスを選択するだけで、そのアイテムに関連するすべてのプロパティを比較できます。

8. 「プロパティ設定」タブをクリックし、比較対象であり、異なる場合は通知されるプロパティ差異のボックスをチェックします。これらは相互排他的です。この方法でプロパティ値の差異を比較する場合、構成アイテム・タイプのプロパティ値で検出されたすべての差異を無条件で比較することになります。
プロパティ値をフィルタ処理するには値の制約ルールを使用します。この場合、比較対象の構成(2番目の構成からn番目の構成まで)のプロパティ値が制約値に対して比較されます。制約を満たせないプロパティ値により、差異が構成されます。たとえば、6以上のバージョンをテストするとします。バージョン・プロパティ値が6より小さい比較対象構成内のインスタンスによって差異が構成されます。差異の無視を選択した場合は、値制約は設定されていないはずです。詳細は第44.5.3項を参照してください。

9. その他の構成アイテムで追加プロパティ設定を設定する場合は、前述の手順を繰り返します。

10. オプションで、左ペインでアイテムを選択し、「構成アイテムの一致のためのルール」タブをクリックします。指定されたプロパティに、構成インスタンス間の照合を実行する場合を決定するために評価するルール式を指定します。つまり、式がtrueに解決された場合にインスタンスが比較されます。詳細は第44.5.3項を参照してください。
一致ルールは列ベースであり、AND論理演算子が適用されます。複数のプロパティにルールを指定する場合は、すべてがtrueに解決された場合にのみ一致とみなされます。

11. オプションで、左ペインでアイテムを選択し、「構成アイテムを含める/除外のためのルール」タブをクリックします。比較する必要のある構成アイテムを識別できます。比較の範囲として、「すべて」、「ルールを満たすものを除外」または「ルールを満たすものだけを含める」のいずれかを選択できます。詳細は第44.5.3項を参照してください。
含める/除外のためのルールは行ベースであり、ルールのサブセット内ではAND論理演算子が適用され、ルール・サブセット間ではOR論理演算子が適用されます。つまり、プロパティAに2つのルールを指定し、プロパティBに2つのルールを指定した場合には、プロパティAに設定したルールが2つとも、またはプロパティBに設定したルールが2つともtrueに解決された場合にのみ一致とみなされます。

44.5.2.2 比較テンプレートの管理

比較テンプレートの作成および編集以外に、次の操作を実行してテンプレートを管理します。

- テンプレートの設定および比較の表示(読取り専用)

- テンプレートの削除(適切な権限が必要)

- テンプレートをXMLファイル形式でエクスポートし、他のCloud Controlシステムにインポートすることによる共有

比較テンプレートの表示

即時利用可能なテンプレートと、他のユーザーのテンプレート(アクセス権があるもの)を表示できます。テンプレートの表示は読取り専用です。テンプレートの構成は参照できますが、たとえ一時的にでも変更することはできません。

1. 比較テンプレート・マネージャでテンプレートを選択し「表示」ボタンをクリックします。

2. 左側のツリー内の項目を拡張し、様々なタブ上の設定およびルールを詳細に調べます。

3. 「保存」ボタンは無効です。「戻る」をクリックして比較テンプレート・マネージャに戻ります。

比較テンプレートの削除

テンプレートの削除は次の制約の対象です。

- Oracle提供の(即時利用可能な)テンプレートは削除できません。Oracle提供のテンプレートは、テンプレート名の隣の閉じたロックにより示されます。

- 適切な権限がないかぎり、比較テンプレートは削除できません。

- デフォルトの比較テンプレートは削除できません。

- 現在使用されている比較テンプレートは削除できません。

テンプレートを削除するには、比較テンプレート・マネージャでテンプレートを選択して、「削除」ボタンをクリックしてから、操作を確認します。

比較テンプレートのエクスポート

他のCloud Controlシステムにインポートできる外部ファイルとしてテンプレートを保存するには、エクスポート機能を使用します。

1. 比較テンプレート・マネージャでテンプレートを選択し、「アクション」メニューを選択して、「エクスポート」ボタンをクリックします。
プラットフォーム固有のファイル・ダイアログが開きます。たとえば、Firefoxを使用している場合、XMLファイルとして識別される名前付きテンプレートのオープンを選択したことがダイアログによって示されます。ダイアログにより、Firefoxの処理として、XMLエディタでファイルを開くか、ファイルを保存するかを確認されます。

2. 保存のラジオ・ボタンを選択し、「OK」をクリックします。

3. ファイル・システム内の目的の場所を参照して、ファイルを保存し、必要な場合は名前も変更します。エクスポート時にデフォルト(即時利用可能)・テンプレートの名前は変更できません。

比較テンプレートのインポート

比較テンプレートのインポートは、比較テンプレート.xsdに準拠している必要があります。したがって、確実に準拠するために、インポートするテンプレートは実際に以前にエクスポートされたテンプレートである必要があります。

1. 比較テンプレート・マネージャで、「アクション」メニューを選択して、「インポート」ボタンをクリックします。

2. テンプレートのファイルの場所を参照し、「インポート」をクリックします。
インポートされたテンプレートが、テンプレート表の新しい行として表示されます。

エクスポートされたテンプレートはその所有者に関連付けられます。テンプレートの所有者が、そのテンプレートをインポートしているユーザーのログインIDと異なる場合は、元の所有権が継続されます。インポートしたテンプレートの所有者になる場合は、インポートする前にテンプレートXMLファイルのowner属性を編集して、その値を自分のログインIDに変更する必要があります。または、その属性を単純に削除することもできます。この場合、デフォルト所有者は、インポート操作を開始したユーザーのIDに設定されます。

テンプレート・マネージャでは、同じ名前のデフォルトのテンプレートおよびOracle提供の(即時利用可能な)テンプレートはインポートできません。同様に、インポートできるようにするには、インポートを実行する前に、テンプレートXMLファイルのname属性を変更します。

44.5.3 ルールの指定

比較テンプレートの作成または編集のコンテキストにおけるルールを指定します(第44.5.2.1項を参照してください)。

ルールによって、比較を微調整するために構成データを解析できます。比較において、ルールは、ベンチマーク構成と比較する構成インスタンスの選択したアイテムの値に式を適用します。一致ルールは、比較するインスタンスを調整する比較キーを構築することを目的としています。ルールの無視は、比較するインスタンス間で検出された違いを無視して基本設定を行うことを目的としています。

44.5.3.1 値制約ルールの作成

次のように値制約ルールを指定します。

1. 左側のペインで構成アイテムを選択します。

2. 右側のペインの「プロパティ設定」タブをクリックし、値制約を設定するプロパティを選択します。

3. ツールバーで「ルールの編集」ボタンをクリックします。開いたダイアログで、次を実行します。

1. ドロップダウン・リストから演算子を選択します。

2. オペランド式を入力し、「OK」をクリックします。

ルールを消去するには、表の行を選択して、ツールバーで「ルールの削除」ボタンをクリックします。

ルール式の形式の詳細は、第44.5.4項を参照してください。

44.5.3.2 一致ルールの作成

次のように一致ルールを指定します。

1. 左側のペインで構成アイテムを選択します。

2. 右側のペインの「構成アイテムの一致のためのルール」タブをクリックし、「新規」をクリックします。
「キー・プロパティの表示」をクリックして、どのプロパティが選択した構成アイテム・タイプのメタデータにキー列として定義されているかを確認します。

3. 「プロパティ名」の下に表示されるドロップダウン・リストで、プロパティを選択します。

4. ルールを作成するには、表の行を選択して、ツールバーで「ルールの編集」ボタンをクリックします。開いたダイアログで、次を実行します。

1. ドロップダウン・リストから演算子を選択します。

2. オペランド式を入力し、「OK」をクリックします。

3. 追加のルールを指定するには、「新規」をクリックし、ステップaおよびbを繰り返します。

ルールを消去するには、表の行を選択して、ツールバーで「ルールの削除」ボタンをクリックします。

ルール式の形式の詳細は、第44.5.4項を参照してください。

同じ構成アイテムまたは異なる構成アイテムに追加ルールを入力できます。複数のルールがある場合、これらは指定した順序で解決されます。一致ルールはAND論理演算子を使用します。つまり、一致を構成するには、すべての条件がtrueに解決される必要があります。

44.5.3.3 包含または除外ルールの作成

次のように無視ルールを指定します。

1. 左側のペインで構成アイテムを選択します。

2. 右側のペインの「構成アイテムを含める/除外のためのルール」タブをクリックし、「新規」をクリックします。
「キー・プロパティの表示」をクリックして、どのプロパティが選択した構成アイテム・タイプのメタデータにキー列として定義されているかを確認します。

3. 「プロパティ名」の下に表示されるドロップダウン・リストで、プロパティを選択します。

4. ルールを作成するには、表の行を選択して、ツールバーで「ルールの編集」ボタンをクリックします。開いたダイアログで、次を実行します。

1. ドロップダウン・リストから演算子を選択します。

2. オペランド式を入力し、「OK」をクリックします。

3. 追加のルールを指定するには、「新規」をクリックし、ステップaおよびbを繰り返します。

ルールを消去するには、表の行を選択して、ツールバーで「ルールの削除」ボタンをクリックします。

ルール式の形式の詳細は、第44.5.4項を参照してください。

同じ構成アイテムまたは異なる構成アイテムに追加ルールを入力できます。複数のルールがある場合、これらは指定した順序で解決されます。無視ルールは、サブセット内のルールに対してはAND論理演算子、サブセット間ではOR論理演算子を使用します。このため、それぞれ複数のルールを持つサブセットが2つある場合、一致を構成するには、最初のサブセット内のすべてのルール、または2番目のサブセット内のすべてのルールがtrueに解決される必要があります。

5. 「新規OR」を選択し、1つのルール・サブセットの最後と、別のルール・サブセットの開始を示します。

44.5.4 ルールの式と構文について

ルールは、演算子とオペランドで構成されます。これらをまとめて、選択したアイテムの値と比較する値に分解する式を形成します。TRUE条件によってルールが満たされます。

オペランドは、リテラル(文字リテラルは一重引用符で囲まれています)、有効な数字またはYYYY-MM-DD HH24:MI:SS.FF形式の日付のいずれかです。構成アイテムの値を直接参照するオペランドは、その値と同じデータ型である必要があります。構文内の大カッコで囲まれたオペランドは、オプションです。

演算子

オペランド

等しい*

一致するリテラル値はオプションです。文字列値は大/小文字を区別します。指定しない場合、式はルールが適用するプロパティの値を評価します。
一致ルールでは、各構成内の構成アイテムの値を、3番目に指定された値とではなく相互に比較します。このため、この場合、演算子にオペランドは使用されません。

[match-literal]

大文字小文字を無視して次に一致*

大/小文字を区別する文字列リテラルはオプションです。指定しない場合、式はルールが適用するプロパティの値を評価します。
一致ルールでは、各構成内の構成アイテムの値を、3番目に指定された値とではなく相互に比較します。このため、この場合、演算子にオペランドは使用されません。

['match-literal']

以上†

一致するリテラル値は必須です。

match-literal

より大きい†

一致するリテラル値は必須です。

match-literal

以下†

一致するリテラル値は必須です。

match-literal

未満†

一致するリテラル値は必須です。

match-literal

の1つ†

リテラル値のカンマ区切りのリスト。少なくとも1つを指定する必要がありますが、一致する必要があるのは1つのみです。

match-literal-1[,match-literal-n,...]

範囲内†

開始および終了のリテラル値に指定された範囲。両方指定する必要があります。境界は含まれます。

start-range-literal , end-range-literal

含む†

パターン一致を実行するための文字列リテラル。必須。

[FALSE|TRUE,] 'pattern-literal'

FALSE: (デフォルト)文字列はOracleのLIKE演算子構文に従う必要があります。TRUE: 文字列はPosixの正規表現構文に従う必要があります。

置換‡

一致する文字列リテラル。2番目の文字列リテラルに置換します。

[FALSE|TRUE,]'pattern-literal'[,'replacement-literal'][,position-integer][,occurrence-integer]

FALSE: (デフォルト)文字列はOracleのLIKE演算子構文に従う必要があります。TRUE: 文字列はPosixの正規表現構文に従う必要があります。

TRUEの場合、文字列を抽出する列値内の位置を示す位置の整数の引数(オプション)、および置換する位置の数を示す発生の整数の引数(オプション)を有効にします。

必須パターン・リテラルは、一致する文字列値を示します

置換の文字列リテラルを指定しない場合、一致した文字列リテラルは何も置換されません。

部分文字列‡

文字列値の指定したセグメントを抽出します。

[FALSE|TRUE,]position-integer[,length-integer][,'pattern-literal'[,occurrence-integer]]

FALSE: (デフォルト)文字列はOracleのLIKE演算子構文に従う必要があります。TRUE: 文字列はPosixの正規表現構文に従う必要があります。

文字列の抽出を開始する位置を示す位置の整数の引数(必須)

- 0または1の場合、すべての文字を返します。

- 正の整数の場合、最初から抽出を開始します。

- 負の整数の場合、最後から戻って抽出を開始します。

長さの整数の引数(オプション)は位置の整数で開始する文字数を示します。

パターン・リテラルは一致する値を示します。最初の引数がFALSEの場合はオプション、TRUEの場合は必須です。

一致する文字数を示す発生の整数の引数。パターン・リテラルを指定した場合のみ有効です。

表記法は次のとおりです。

*–値の制限、一致ルールおよびルールの無視に有効
†–値の制限およびルールの無視のみに有効
‡–一致ルールのみに有効

44.5.5 例によるルールの理解

これらのルールの例では、テンプレートの作成または編集中に、左側のツリーで構成アイテムを選択したところであることを前提としています。

44.5.5.1 一致ルールの例

ホスト構成のハードウェアを比較する際に、一致を目的として、各ベンダー名の大文字小文字を無視するとします。ここでは、大文字小文字の比較を行うために簡単なルールを使用します。

1. 一致のルール・タブで、「新規」をクリックします。

2. ドロップダウン・リストで「ベンダー名」を選択します。

3. 表の行を選択して、ツールバーで「ルールの編集」ボタンをクリックすると、ルール・ダイアログが開かれます。

- 「演算子」を「大文字小文字を無視して次に一致」に設定します。この演算子では一致ルールにオペランドが使用されないため、これで完了です。

- 「OK」をクリックします。

サーバー名に基づいてWebLogic Serverを比較する際に、ManagedServer1やManagedServer2などのように名前が異なるとします。比較を確実に実行するには、サーバー名の照合を行う必要があります。

1. 「構成アイテムの一致のためのルール」タブで、「新規」をクリックします。

2. ドロップダウン・リストで「マシン名」を選択します。

3. 表の行を選択して、ツールバーで「ルールの編集」ボタンをクリックすると、ルール・ダイアログが開かれます。

- 「演算子」を「部分文字列」に設定します。

- 「オペランド」を「1, 13」に設定します。

- 「OK」をクリックします。

実質的に、このルールでは、名前の最初の13文字(ManagedServer)を使用し、修飾部の整数は除外することを表します。

4. これと同じ結果を得るもう1つの方法は、次のとおりです。

- 「演算子」を「置換」に設定します。

- 「オペランド」を「true, '(*)(\d*)', '\1'」に設定します。

- 「OK」をクリックします。

この例では、正規表現(TRUE)を使用して修飾部の整数の前にあるすべての文字を解決しています。

より詳細な例については、ファイル名が次の形式である表領域内のデータファイル・ファイル名との一致が必要なデータベース・インスタンス比較を検討してください。

/u01/jblack_abc2d/oracle/dbs/dabc2/mgmt_ad4j.dbf

1. 「構成アイテムの一致のためのルール」タブで、「新規」をクリックします。

2. ドロップダウン・リストで「ファイル名」を選択します。

3. 表の行を選択して、ツールバーで「ルールの編集」ボタンをクリックすると、ルール・ダイアログが開かれます。

- 「演算子」を「置換」に設定します。

- 「オペランド」を「true, '(/u01/)(.*)(oracle.*/dabc[0-9]+.*/)(.*)', '\2\4'」に設定します。

- 「OK」をクリックします。

実質的に、このルールでは、正規表現(TRUE)を使用して、/u01/からoracleまでの間の値にdabc2 /より後の元のファイル名の残りを結合したもの(またはjblack_abc2d/mgmt_ad4j.dbf)から一致キーを構築することを表します。

44.5.5.2 含める/除外のためのルールの例

通常、含めるルールまたは除外のルールを使用して、列指向ではなく行指向のコレクション内の差異を含めるまたは除外します。たとえば、構成拡張スナップショットは行指向のデータ・コレクションです。

たとえば、構成拡張解析済データで、プロパティ「属性」によって内部IDまたはチェックサムが識別された任意の行を無視するとします。

1. 「構成アイテムを含める/除外のためのルール」タブで、「新規」をクリックします。

2. ドロップダウン・リストで「属性」を選択します。

3. 表の行を選択して、ツールバーで「ルールの編集」ボタンをクリックすると、ルール・ダイアログが開かれます。

- 「演算子」を「次のいずれか」に設定します。

- 「オペランド」を「'id', 'checksum'」に設定します。

- 「OK」をクリックします。

このルールにより、比較時に指定した値のいずれかが含まれるコレクション内の任意の行を無視するようにします。

ここで、比較エンジンが論理演算子ANDおよびORを同じ構成アイテム・タイプに対して適用する方法を示す無視ルールを検討してください。この例の目的は、3つのルール・セットのいずれかが次の条件を満たすときに構成拡張解析済データ内の行を無視することにあります。

Data Source = &rsquor;sqlnet.ora' AND Attribute = &rsquor;ADR_BASE'
OR
Data Source = &rsquor;tnsnames.ora' AND Attribute = &rsquor;HOST'
OR
Data Source = &rsquor;resources.xml' AND Attribute = &rsquor;authMechanismPreference'

比較エンジンによってAND演算子がセット内のルールに適用され、OR演算子がルール・セット間に適用されます。インスタンスを無視するためのルールによって継承がサポートされるため、この場合、この例で示すように、「データソース」プロパティがルール作成時に使用可能になります。

1. 「構成アイテムを含める/除外のためのルール」タブで、「新規」をクリックします。

2. ドロップダウン・リストで「データソース」を選択します。

3. 表の行を選択して、ツールバーで「ルールの編集」ボタンをクリックすると、ルール・ダイアログが開かれます。

- 「演算子」を「次と等しい」に設定します。

- 「オペランド」を「'sqlnet.ora'」に設定します。

- 「OK」をクリックします。

4. 「新規」をクリックし、ドロップダウン・リストで「属性」を選択します。

5. 表の行を選択して、ツールバーで「ルールの編集」ボタンをクリックすると、ルール・ダイアログが開かれます。

- 「演算子」を「次と等しい」に設定します。

- 「オペランド」を「'ADR_BASE'」に設定します。

- 「OK」をクリックします。

6. 「新規OR」をクリックして論理演算子ORを挿入し、最初のルール・セットの最後を示します。

7. 「データソース」が'tnsnames.ora'と等しく、「属性」が'HOST'と等しい2つの新規ルールを追加します。

8. 「新規OR」をクリックして論理演算子ORを挿入し、2番目のルール・セットの最後を示します。

9. 「データソース」が'resources.xml'と等しく、「属性」が'authMechanismPreference'と等しい2つの新規ルールを追加します。

この比較では、3つのルール・セットのいずれかを満たすコレクション・データ内の任意の行が無視されます。

44.5.6 比較について

エンタープライズ構成管理では、企業内の管理対象エンティティに関連付けられた構成データの収集、格納および監視に対応します。たとえば、ホストには、ハードウェアおよびソフトウェアのコンポーネント(CPU数、メモリー、IOデバイス、OSプラットフォームとバージョン、インストール済ソフトウェア製品など)に関連する構成アイテム・タイプがあります。

通常、パッチやアップグレードなどの共通のイベントによって、構成データの変更は常に発生します。ある時点で、1つのコンポーネントへの変更がシステム全体に悪影響を及ぼすことがあります。根本原因を検出することが最優先になります。

比較ツールによって、ターゲットの構成を、同じタイプの別のターゲットの構成と比較できます。現在の構成または以前に保存した構成(たとえば、パッチ適用やアップグレードの実行前など)で比較できます。

比較によって次を実行できます。

- 比較中に特定の属性を無視

- 違いが検出された場合に主要な担当者へ通知

- 比較テンプレートの設計および他の管理者との共有

- 比較を繰り返し実行するようスケジュール

- 完全なターゲット・システムの比較。ターゲット・システム・メンバーを自動または手動で一致させます。

- RAWファイル・コンテンツとして、または解析済フォーマットでの構成ファイル・データの比較

44.5.7 比較ウィザードの理解

比較は、エンタープライズの管理における重要な要素です。比較ウィザードでは比較の設定プロセスの手順が示されます。比較の設定には5つのステップがあり、システムを比較する場合は6つのステップがあります。

- 比較の最初の構成(比較対象の構成)を選択します。

- 別の構成(最初の構成と比較する1つ以上の構成)を選択します。

- 比較を構成するための比較テンプレートを選択します(テンプレートを選択しなくてもかまいません)。

- システムを比較する場合は、最初の構成のシステム・メンバーを比較対象の構成のメンバーにマップします。

- 比較ジョブをスケジュールし、電子メール通知を設定します。

- 内容を確認してジョブを発行します。

後続の手順で結果と差異の詳細を確認します。

44.5.7.1 比較対象の構成の選択

比較を設定する最初の手順は、1つ以上の構成の比較対象となる構成を選択することです。比較ウィザードを開くと(「エンタープライズ」メニューで「構成」を選択し、「比較」を選択)、下部の表に使用可能な構成のコレクションが表示されます。

1. 最新の構成と保存された構成から選択します。最新の構成と保存された構成を相互に比較できるように組み合せることが可能です。保存された構成を選択すると、右側のフィルタ基準がアクティブになり、日付と説明を入力できるようになります。

2. フィルタリング基準を指定して、検索結果を絞り込みます。最小限でも、ターゲット・タイプを選択し、保存された構成については前後の日付も選択します。「検索」をクリックします。

3. ページ下部に表示される一致する構成のリストで基準となる構成を選択し、ワークフロー・トレインで「次へ」をクリックするか、「比較構成」をクリックします。

44.5.7.2 比較する構成の選択

次の手順は、選択した最初の構成と比較する1つ以上の構成を選択することです。

1. 「構成の追加」をクリックして、構成の検索および選択ダイアログを開きます。

2. 最初の構成と同じように、最新の構成と保存された構成から選択し、フィルタ基準を入力して検索を絞り込みます。「検索」をクリックします。

3. 結果リストで1つ以上の構成を選択(複数選択可)し、「OK」をクリックします。

4. ワークフロー・トレインで「次へ」をクリックするか、「比較テンプレート」をクリックします。

44.5.7.3 比較で使用するテンプレートの選択

オプションで、テンプレートを使用しないこと(デフォルト)も選択可能であり、その場合はこの手順をスキップできます。選択したテンプレートはそのまま使用してください。つまり、この特定の比較に対して設定を変更することはできません。テンプレートの特定の設定を変更する場合は、類似作成機能を使用して、既存のテンプレートを基に新しいテンプレートを作成します。

比較ターゲット・タイプに応じて、デフォルト・テンプレートを使用できる場合があります。テンプレートを選択し終わったら、必要に応じてワークフロー・トレインで「次へ」、「スケジュールと通知」または「マッピング」をクリックします。

44.5.7.4 システム比較でのメンバーのマッピング

マッピングはシステムの比較にのみ関連します。これは、それぞれのシステムのメンバーを比較でどのように組み合せるかを選択して指定する方法です。

テンプレート設定においてすでにテンプレートを選択している場合は、マッピング・ステップの表示形式としても、テンプレート定義で設定されたツリーまたは表のいずれかの形式のマッピング表示が使用されます。ただし、テンプレート・ステップにおいて「テンプレートなし」を選択している場合は、マッピング・ページに「マッピング表示」オプションが表示されます。デフォルトでは、「ツリー」ビューが選択されています。システムの比較が完了すると、その結果が選択したマッピング表示の形式で表示されます。

注意:
システム比較の設定に関する視覚的なデモを表示するには、次のURLで提供されているビデオ「Oracle Enterprise Manager 12c: Manage Application Stack Configuration with System Comparisons」を視聴してください。

https://apex.oracle.com/pls/apex/f?p=44785:24::::24:P24_CONTENT_ID,P24_PREV_PAGE:5449,1

表の列と「マッピング概要」を選択すると、システム・ターゲット・タイプ階層および第1ターゲットと第2ターゲットの間に存在するマッピングが表示されます。これらのマッピングは、前の手順で選択したテンプレートに対して定義されたターゲットの一致ルールか、テンプレートが選択されていない場合にはシステム定義のターゲットの一致ルールによって決定されます。複数のシステムと比較する場合は、別のシステム・ターゲットを選択してそのシステムのマッピングを確認します。

ヒント:
マッピング表示により、実際に比較を実行する前に、左のみの一致と右のみの一致に関するフィードバックが提供されるため、テンプレートで一致ルールを作成して問題に対処することができます。

メンバー・ターゲットの横の「無視」チェック・ボックスを選択して、そのメンバーを比較で無視できます。このチェック・ボックスを選択すると、すべての子メンバーも自動的に無視されます。表見出しのチェック・ボックスを選択すると、すべてのメンバーが無視されます。

テンプレートベースのマッピングまたはシステムベースのマッピングで、すべての状況に対応できるわけではありません。第1のシステムのメンバーを第2のシステムのメンバーに手動でマップするには、「マッピングの作成」ボタンをクリックします。

ポップアップ・ダイアログに、それぞれのシステム・ターゲットのツリー階層が表示されます。第1のシステムのメンバーを選択すると、チェック・ボックスで第2のシステムの適切なターゲット・メンバーが指定されます。第1のシステムのメンバーをマップする、1つ以上のメンバーを選択します。マッピングには、マップされたメンバーの子も自動的に含められます。第1のシステムの別のメンバーを選択すると、先程設定したマッピングはビューで非表示になりますが、保持されます。終了したら、「OK」をクリックして手動マッピングを確認し、ダイアログを閉じます。

「ステータス」列の「手動マップ済」アイコンで示されるように、マッピング概要階層に先程作成した手動マッピングが追加されました。他のアイコンは、システムベース・マッピングとテンプレートベース・マッピングの両方を含むシステムでマップ済、無視されたメンバー、および左のみまたは右のみのメンバーを示します。「ステータス」列のアイコンの上にマウス・ポインタを置くと、アイコンの説明が表示されます。

手動で作成したマッピングを削除するには、「マッピングの削除」ボタンをクリックします。ポップアップ・ダイアログに、各システム・ターゲットのツリー階層が表示され、作成された手動マッピングが示されます。元に戻す手動マッピングの、「削除」列のチェック・ボックスを選択します。メンバーのマッピングを削除すると、すべての子のマッピングが自動的に削除されます。

マッピングが完了したら、ワークフロー・トレインで「次へ」または「スケジュールと通知」をクリックします。

44.5.7.5 比較のスケジュールおよび通知リストの作成

スケジュールおよび通知ページでは、バックグラウンド・ジョブとして実行する比較をスケジュールします。比較は一度のみ実行することも、繰返し実行することも可能です。また、すぐに実行することも後日実行することもできます。このページでは、差異のアラートを送信する電子メール・アドレスも指定できます。

注意:
繰返しのジョブをスケジュールする場合、ジョブ関連の設定は、「ジョブ」ページで結果を参照する際に後から変更できます。「編集」ボタンをクリックして「スケジュール」タブに移動します。

1. 比較ジョブには名前が必要です。構成比較として日時によって比較ジョブを識別するデフォルト名が付けられますが、意味のある名前をジョブに入力することもできます。

2. ジョブのスケジュールを指定します。

- すぐに実行しない場合は、いつ実行するかを指定します。「後で」をクリックして、日時の選択が可能なカレンダ・ウィジェットをアクティブ化します。

- 頻度を指定します。ドロップダウン・リストでレポート頻度を選択します。デフォルトは一度のみです。

- 待機期間を指定します。ジョブがスケジュールどおりに実行されない場合は、指定された時間枠内で取り消されます。

- スケジュールを維持する期間を指定します。指定された期間の間ジョブ・スケジュールが維持されます。

3. 比較で差異が検出された場合に通知するユーザーの電子メール・アドレスを入力します。アドレスはカンマで区切ります。差異のアラートが出るのは、比較テンプレートで明示的に選択されているプロパティです。
ログイン・ユーザーおよび比較の作成者として、Enterprise Manager Notification Systemから通知を送信するためにアカウントを適切に設定(コンソール・ホーム・ページで「設定」メニューから「通知」、「通知メソッド」の順に選択)しておく必要があります。「送信者ID」および「送信者の電子メール・アドレス」の設定は、比較ジョブで検出された差異の結果として生成された電子メールに表示されます。

注意:
電子メール通知には、次が表示されます。

- 単純なシステム以外のターゲットの場合、電子メール通知には、各第2構成に関して表示される総差異数リンクが含まれます。このリンクをクリックして、1:1の比較結果ページに移動します。このページから、構成の差異をXMSファイルにエクスポートできます。電子メール通知には、1つ以上の差異通知のある構成アイテムの表も表示されます。
第2構成に通知が有効化された属性差異がまったくない場合、第2構成は電子メールに含まれません。

- システム・ターゲットの場合、電子メール通知には、各第2システム構成に関して、比較されたメンバー・レベル・ペアに対する差異合計と差異通知が表示されます。
表差異合計数は、表の先頭に表示されます。リンクをクリックして、システム比較結果ページを表示します。このページから、システム結果をXLSファイルにエクスポートできます。

第2構成セクションは、メンバー・ペアに1つ以上の差異通知がある場合のみ電子メールに含まれます。

システムの差異合計は、通知のあるメンバーのみでなく、すべてのメンバーの差異の合計です。

4. ワークフロー・トレインで「次へ」をクリックするか、確認および送信をクリックします。

44.5.7.6 比較パラメータの確認およびジョブの発行

ジョブを発行する前に比較パラメータを確認します。

- 基準の構成、つまり、最初のパラメータは適切か。

- 基準と比較する構成が間違っていないか。

- 適切なテンプレートを使用しているか。

- ジョブ名が適切か。

- ジョブが予定どおりにスケジュールされているか。

- 差異をアラートする電子メール・アドレスが適切な形式で入力されているか。

変更が必要な場合は該当のページに戻ります。それ以外の場合は、「発行」をクリックして比較ジョブをスケジュールします。

ターゲット同士で比較を行うために、プログレス・ウィンドウが開きます。比較の完了後、比較結果ページが開きます。プログレス・ウィンドウを閉じることもできます。自動的に、比較ジョブ・アクティビティ・ページに移動します。

複数のターゲットとの比較を行うために、ジョブを発行すると、比較ジョブ・アクティビティ・ウィンドウが開きます。

比較結果ページに発行済ジョブのサマリーが表示されます。比較ジョブ・アクティビティ・ページには、差異が検出されたかまたは構成が同じであるかどうかの比較結果が表示されます。どちらの場合(差異がある、または同じ)でも、報告された結果は比較の詳細にリンクしていますが、おそらく、差異がある方が興味深い結果となります。比較された各構成に対して別々のエントリが表示されます。つまり、構成BとCがAに対して比較された場合、Bと比較したAの結果とCと比較したAの結果が表示されます。

比較ジョブ・アクティビティ・ページには、ターゲット・タイプ、第1ターゲット、第2ターゲット(第1ターゲットと比較したターゲット)、ターゲットの所有者、比較のステータス、スケジュール済の開始日および比較実行日も表示されます。

44.5.8 比較結果の処理

この項では、比較結果に関する次の視点について説明します。

- 比較とジョブ・アクティビティについて

- システム比較結果について

- 標準のターゲット比較結果について

- 構成ファイルの同期

44.5.8.1 比較とジョブ・アクティビティについて

比較はスケジュール済のジョブとして実行されます。比較の設定プロセスの中にスケジュールの定義があります。つまり、1回のみまたは繰返し実行することや、即時または後日実行すること、あるいは失敗後の再試行などです。順列を考慮すれば、多数のジョブを追跡することが可能です。

比較ジョブ・アクティビティを表示するには、「エンタープライズ」メニューから「構成」を選択し、「比較ジョブ・アクティビティ」を選択します。

比較ジョブ・アクティビティ・ページでは、すでに実行中の比較を再発行することもできます。つまり、同じ比較を続いて実行する際にすべての比較ワークフローを繰り返す必要はありません。

1つのターゲットを複数のターゲットと比較する場合、「比較ジョブ・アクティビティ」ページにデータがツリー表の形式で表示されます。ツリー表のルート・ノードには、比較全体の結果が表示されます。ノードを拡張すると、個別のターゲットの組合せを含む行がすべて表示されます。

1つのターゲットを別の単一ターゲットと比較すると、1行のみの比較結果が表示されます。

「比較名」はジョブ・ステータス・ページに移動できるハイパーリンクです。

比較結果を表示するには、「比較結果」列リンクをクリックします。これによって比較結果ページに移動します。

1つのターゲットを複数のターゲットと比較する場合、「比較結果」リンクはそれぞれのターゲット構成の組合せに対応するリーフ・ノードで有効です。

1つのターゲットを別の単一のターゲットと比較する場合、「比較結果」リンクはルート・ノードで有効です。

表内の行を選択して「比較を今すぐ再発行」をクリックすると、以前実行した比較の新規発行を実行できます。この発行には次の特徴があります。

これは新規のジョブのため、日付および時間のスタンプによって前のジョブと区別されます。

ジョブはすぐに実行されるようにスケジュールされます。

ジョブは1回のみ実行されます。

ジョブを確認する情報メッセージが、表内の新規行として表示されます。

ジョブ所有者であるか、適切なアクセス・レベルを有する場合、関係なくなった比較ジョブを削除することによってリストのメンテナンスを実行できます。これには比較のパージの効果もあります。

44.5.8.2 システム比較結果について

スケジュールされていた比較ジョブが完了したときに「ジョブ」ページ上の「差異」リンクをクリックすると、システム比較の結果が表示されます。「同一」リンクをクリックして結果を表示することもできますが、一般に、比較を行う目的は、差異を表示して解決することです。

上部領域には、比較およびジョブの詳細が要約されます。下部領域には、システム比較結果の要約表が表示されます。システム比較結果は多くの行にまたがることがあるため、結果をフィルタリングして表示を縮小できます。フィルタ基準を表示するには、「検索」下矢印をクリックします。検索結果で、基準を満たすメンバーが強調表示され、ルートへの祖先が示されます。

表には、システムおよびメンバー・ターゲット・タイプの階層が表示されます。

- 「ターゲット・タイプ」列には、システムおよびメンバーのツリー階層が表示されます。

- 「結果」列には、比較設定の一部として確立されたマッピングに基づく比較結果が表示されます。四角で囲まれた1(左のみ)または2 (右のみ)はそれぞれ、最初または2番目のメンバー・ターゲットには比較対象がなかったことを示します。親ターゲット構成が同じでも、どちらかの親に左のみまたは右のみとしてマークされた子がある場合、これらの親は差異としてマークされることに注意してください。

- 一致していないメンバーを解決するには、ウィザードで比較を再実行し、今度はマッピング手順で左および右のメンバー・ペアがマップされたメンバー表に表示されることを確認します。これらのメンバーがマップされるように、ターゲットの一致ルールが定義された適切なシステム比較テンプレートを選択するか、または手動でペアをマップします。

- システム比較の目的で、指定したターゲット・タイプのメンバーを比較したくない場合(たとえば、メンバー・レベルでの差異が関連付けられていないシステムの設定の問題の診断中)、マッピング手順で「無視」チェック・ボックスを選択して、指定したメンバー・タイプをバイパスします。

- メンバー・ターゲット間の差異を表示するには、標準の比較結果ページに表示される「差異」リンクをクリックします。詳細ページの上部にあるブレッドクラム・リンクを使用して、システム比較結果ページに戻ります。
「結果」列に「等しい」アイコンと「等しくない」アイコンの両方が表示される場合、親レベルでは等しいが、一部のメンバーに差異があることを示します。

- システム・ターゲットおよびすべてのメンバー・ターゲットの比較時に発見されたすべての差異のサマリーを表示するには、システム・メンバーを表示する表の上部にある「すべての差異をエクスポート」をクリックします。XLSレポートがダウンロードされます。結果レポートはExcelで開くことができ、次の3つの表を示します。

- 表1には、すべての非構成拡張アイテムの差異が表示されます。

- 表2には、比較されたすべての構成拡張データ・ソースと関連付けられたデータ・ソースのリストおよびソース属性が異なっているかどうかを示すインジケータが表示されます。データ・ソース属性には、サイズ、収集エラー、解析エラー、生成元などが含まれます。
属性の差異が「第1のみ」の場合は、データ・ソース全体が第1ターゲットのみに含まれ、第2ターゲットにはないことを示しています。

属性の差異が「第2のみ」の場合は、データ・ソース全体が第2ターゲットのみに含まれ、第1ターゲットにはないことを示しています。

データ・ソース属性が「同一」の場合は、データ・ソースが両方のターゲットにあり、ファイルのコンテンツに依然として差異がある可能性があるが、すべての属性が同じであることを示しています。

データ・ソース属性が「差異」の場合は、データ・ソースが両方のターゲットにあり、各ターゲットで属性値が異なっていることを示しています。値は結果の一部として表示されます。

- 表3には、構成拡張データ・ソースの「解析済データ」が表示されます。構成拡張データ・ソースに解析済データがあり(つまり、ファイルのコンテンツが解析可能である)、データ・ソースが第1ターゲットと第2ターゲットの両方に存在し、解析済データに差異がある場合、それらの解析済データがこの表に表示されます。

注意:
第1ターゲットまたは第2ターゲットのいずれかのみに存在するデータ・ソースは、表3でレポートされません。第1データ・ソースまたは第2データ・ソースは、表2で表示されます。どのデータ・ソースが第1のみなのかまたは第2のみなのかを確認するには、2つ目の表の結果を使用します。

44.5.8.3 標準のターゲット比較結果について

差異詳細は、ジョブ・ページ上の比較結果ビュー内の「差異」リンクをクリックすると表示されます。詳細ビューには、比較およびジョブの詳細が要約されます。これらのリージョンを閉じて、差異詳細に関するページ上のスペースをより広く確保することもできます。

差異詳細は次のように分けられます。

- 左ペインには、比較対象のターゲット・タイプの構成アイテムの階層とともに、必要に応じて構成拡張が表示されます。次のように、範囲の比較結果を絞り込みます。

- 「差分のみ表示」チェック・ボックスを選択し、同じ結果や無視された結果の不要情報を除去します。

- 比較テンプレートで無視されたプロパティを表示するには、「無視を表示」チェック・ボックスを選択します。デフォルトでは、キー・プロパティおよび同一または異なるプロパティが表示されます。左ペインで「差分のみ表示」を選択した場合、このオプションは無効化されます。

- システム・ターゲットおよびすべてのメンバー・ターゲットの比較時に発見されたすべての差異のサマリーを表示するには、システム・メンバーを表示する表の上部にある「すべての差異をエクスポート」をクリックします。XLSレポートがダウンロードされます。

- 右側の表示は左側の選択内容によって異なります。

- 左側での選択には最大6つのキー・プロパティが含まれますが値プロパティは1つのみで、右側の表にはすべてのキー列が最初に表示されてから、値列が表示され、それぞれの値が最初と2番目の構成に対して表示されます。値は最初の場所で比較される行に対して同じである必要があるので、キー列は2度は表示されません。
前述の右側の表のフィルタ機能を使用して、キーまたは値列が一致する構成アイテムを検索します。

- 左側の選択肢に複数の値プロパティが含まれる場合、右側には選択(キー)構成プロパティの行を含む最上位の表と、キーおよび値プロパティの両方を含むすべての構成プロパティの行を含む最下位の表が表示されます。
最上位の表内の行を選択し、その構成プロパティを最下位の表の最上位の行に移動します。

- 単一行構成アイテム・タイプの場合、つまりキー・プロパティを含まないが多くの属性プロパティを含むアイテム・タイプの場合、右側のペインには1つの表に最初と2番目の構成の比較されたプロパティ値が表示され、表の最初の列にはプロパティ名がリストされます。

- 左側の構成仕様を選択して、最上位の表に差異を含む構成ファイル、最下位の表に構成プロパティおよび値の行を含む表を右側に表示します。このビューでは、ファイルの差異を同期できる(「ファイルの同期の有効化」)ことに注意してください。ファイルの同期の詳細は、第44.5.8.4項を参照してください。

- 左側の構成拡張ファイルを選択し、右側にフィルタ・コンテンツを表示します。比較対象の構成のプロパティ値が含まれるファイル・コンテンツが個別タブ上にRAW形式と解析済形式の両方で表示されます。

このビューに表示されるアイコンはほとんど直観的に判断できます(等しい-同じ、等しくない-異なる)。キー・アイコンは、構成アイテム・タイプのキー・プロパティを示します。範囲外を表す表示は、プロパティに設定されている値制約をプロパティ値が満たさなかったことを示します。四角で囲まれた1(左のみ)または2(右のみ)はそれぞれ、最初の構成または2番目の構成に相当する一致アイテムが比較によって見つからなかったことを示します。この場合、「比較詳細」ラベルの下に表示されるリンクを使用して編集モードのテンプレートを開き、一致を作成するルールを起動してから比較を再実行することができるようにします。

構成キー・プロパティ

右側の最上位の表に表示される列名について不思議に思われるかもしれません。これらの列は、構成アイテム・タイプのキー・プロパティを表します。構成アイテム・タイプに宣言されたキー・プロパティがない場合、CIタイプ・データベース表内の上位4つのプロパティが採用され、構成を照合するためのキーの代用として使用されます。なんらかの理由により、キー・プロパティを無視するよう比較が設定されている場合(このような設定はお薦めしません)、この優先順位(データベース表内の上位4つのプロパティ)が維持されます。

44.5.8.4 構成ファイルの同期

この機能を使用して、ファイルベースの構成の比較で差異が返されたときに、オンデマンドでファイルの同期を実行します。多くの場合は、ユーザーが作成する構成拡張が関係します。構成拡張の詳細は、第44.6項「構成拡張および収集の概要」を参照してください。

注意:
この機能は、ファイルベースの構成に対してのみ使用できます。コマンドベースまたはSQL問合せベースの構成拡張の比較の結果発生した差異は、同期化できません。

1. 比較結果の差異の表示中に、左側のツリーで構成の仕様を選択します。

2. 「ファイルの同期の有効化」チェック・ボックスが表示されます。これを選択します。

3. チェック・ボックスの横にドロップダウン・リストが表示されます。更新の方向を選択します。つまり、2番目の構成を最初の構成に一致するように変更するか、またはその逆です。

4. 表示される新しい「ファイルの同期化」列で、更新するファイルを選択します。複数のファイルを選択でき、その場合それらすべてを同じ方向で更新することになります。

5. オプションで、プレビュー機能を使用して、ファイルごとに更新の影響を表示します。眼鏡のアイコンをクリックして、更新の前後のファイルをRAW形式で表示します。

6. 結果に問題がなければ、「ファイルの同期化」ボタンをクリックします。

7. 開くダイアログで、次のように入力します。

- 必要に応じてログインの資格証明を指定します。ターゲットの宛先に対するログイン・アクセス権と、更新するディレクトリに対する書込み権限が必要です。

- 宛先ディレクトリを示す適切なラジオ・ボタンを選択します。どちらの場合も(元のディレクトリまたは別のディレクトリ)、ディレクトリに対する書込み権限が必要です。

- 競合時の続行方法について適切なラジオ・ボタンを選択します。比較は、リポジトリからのデータを使用して実行されます。競合は、更新するファイルがターゲットで変更され、比較に使用したデータと異なる場合に発生します。この場合、続行または停止のどちらを行うかを指定します。

- 宛先ディレクトリ(元のディレクトリまたは別のディレクトリ)の選択に関係なく、競合チェックは、元のディレクトリ内のファイルに対して常に実行されることに注意してください。

- 必要なバックアップ・オプションを指定します(更新ターゲットが元のディレクトリの場合、デフォルトで両方が選択されます)。

- 同期前に更新する構成のスナップショットを保存する場合、適切なチェック・ボックスを選択します(保存した構成からファイルを容易に取得できるような説明的な名前を付けます。デフォルトは汎用名のCCS同期保存スナップショットで、これはフィールドを空白にした場合も適用されます)。

- 更新する前に、構成ファイルのバックアップ・コピーを作成する場合は、該当するチェック・ボックスを選択します。書込み権限のあるディレクトリを参照します。

これらは相互に排他的なオプションではありません。前者では、タイムスタンプ付き収集データをOMSリポジトリに保存するのに対し、後者では、ファイルのコピーをファイル・システムに格納します。

- 必要な場合、ファイルの同期後すぐに、宛先ターゲットの構成データの収集のリフレッシュをオンデマンドで実行します。この方法で、比較を再実行する、または構成ブラウザで構成を表示する場合、更新の影響が表示されます。いつでも手動でリフレッシュを実行することも、次のスケジュールされた収集まで待つこともできます。
元の宛先ディレクトリが更新ターゲットの場合は、デフォルトでチェック・ボックスが選択されます。別のディレクトリを指定した場合、この場合はリフレッシュ対象がないので、チェック・ボックスは無効です。

- 「OK」をクリックします。

- 「はい」をクリックして、ファイルの更新を確認します。

「確認」領域のリンクを使用して同期化ジョブを追跡します。ジョブが完了したら、リフレッシュを要求したと想定して、比較を再実行して更新を検証することができます。構成ブラウザで構成拡張を開き、そこで更新を確認することもできます。

すべての構成ファイルが同期化できるわけではない

比較結果の差異ビューでは、一部のファイルは差異であっても同期化を選択できません(チェック・ボックスが無効)。次に示すような、考えられる原因がいくつかあります。

- 宛先ファイルが書込み不可能です。

- リソース・ファイルがありません。

- 構成拡張の定義中、逆変換(効果的に、ファイルの解析された形式を構文ツリー構造に戻し、次に物理的な表現へとレンダリングできる機能)と呼ばれるプロセスをサポートしないパーサーにファイルが関連付けられました。すべてのパーサーが逆変換をサポートするわけではありません。

44.6 構成拡張および収集の概要

構成拡張は、Cloud Controlがまだ収集していないファイルおよびその他の構成データを識別する方法を提供します。よく知られたターゲット・タイプまたは構成拡張定義の一部として導入されたターゲット・タイプで、カスタマイズされた構成を収集できます。ブループリントと呼ばれる構成拡張のセットが、Oracleからダウンロードできます。ブループリントと呼ばれるのは、特定のプラットフォーム(Apache Tomcatなど)について収集するファイルとデータを詳細に規定しているためです。

構成拡張の一般的なライフサイクルは次のとおりです。

- 構成拡張を作成し、いくつかのターゲットにデプロイします。

- 一定期間の有効性を評価します。

- 指定を変更および微調整し、より広範に再デプロイします。

- 適切でなくなったら、指定をアンデプロイし、削除します。

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

- 構成拡張の処理

- 構成拡張およびデプロイについて

- 構成データ収集の拡張

- 構成拡張のブループリントとしての使用

44.6.1 構成拡張の処理

この項では、構成拡張の作成、編集およびその他の管理を行う方法を説明します。カスタム・ターゲット・タイプを使用する構成拡張を作成する場合、最初にカスタム・ターゲット・タイプを作成するワークフローが推奨されます。それと同時に、サンプル・ターゲット・インスタンスとして機能する補完的な新しいターゲットも追加できます。

44.6.1.1 カスタム・ターゲット・タイプの作成

構成拡張の要件を満たす既存のターゲット・タイプがない場合、カスタム・ターゲット・タイプを作成できます。

新規ターゲット・タイプを作成する前に、管理者がソフトウェア・ライブラリをインストールしてあることを確認します(「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」を選択します)。これは、Cloud Controlのインストール後に一度行う必要があります。

1. 構成拡張ライブラリで、「アクション」メニューから「カスタム・ターゲット・タイプの作成」を選択します。

2. 表示されるダイアログでカスタム・ターゲット・タイプの名前を指定し、「OK」をクリックします。前述したとおり、プロセスの完了にはしばらく時間がかかります。

3. 完了後、ターゲット・タイプの作成を確認するメッセージが表示され、そこでサンプル・ターゲット・インスタンスを追加するかどうかを確認されます。サンプル・ターゲットは、構成データの収集の基礎となります。「はい」をクリックします。

4. 追加したカスタム・ターゲット・タイプに関連付けられたダイアログが表示されます。「検索」アイコンをクリックして追加したターゲットを監視する管理エージェントを選択し、「ターゲットの追加」をクリックします。

5. 表示されるダイアログで、インスタンスのターゲット・タイプに適したターゲット・プロパティを指定します。特に、適切なターゲット・プロパティはインストール・ホームへのパスです。カスタム・ターゲット・タイプに関連する構成ファイルの場所として適しているためです。オプションで、コスト・センターおよびライフサイクル・ステータスなどのグローバル・プロパティを指定します。「OK」をクリックします。
これで、カスタム・ターゲット・タイプ用の構成拡張を作成したときに、ターゲットはサンプル・ターゲットとして利用可能になります。

カスタム・ターゲット・タイプの作成の間に、新しいターゲット・インスタンスを追加することは必須ではありません。「アクション」メニューから「新しいカスタム・ターゲットの追加」を選択し、前述のプロセスのステップ4および5に従うことで、後からこれを行うことができます。その際、ドロップダウン・リストからカスタム・ターゲット・タイプを選択します。

44.6.1.2 構成拡張の作成または編集

構成拡張を作成、類似作成または編集する場合は、次の手順に従います。

適切な権限が与えられている場合、構成拡張を編集してその編集済バージョンを保存できます。この場合、バージョン番号が増加します。また、ドラフトとして編集および保存することや、ドラフトを公開のために編集することができます。構成拡張を編集する際、ターゲット・タイプは変更できません。変更すると、基盤となるメタデータで、構成拡張の既存のデプロイとの互換性がなくなる可能性があるためです。

構成拡張についての様々なアクションの実行に必要となる権限の詳細は、第44.6.1.9項を参照してください。

注意:
デプロイ済の構成拡張を編集する場合、保存時に自動的に再デプロイされます。これは、ドラフトとしての保存には適用されません。

1. 構成拡張ライブラリで、「作成」ボタンをクリックします。または、ライブラリで既存の仕様を選択し、「類似作成」または「編集」をクリックします。

2. 「構成拡張の作成」ページで、構成拡張の名前および説明(オプション)を入力します。類似作成アクションでは、仕様の名前の変更が最小限、必要です。

3. ドロップダウン・メニューからターゲット・タイプを選択します。

4. オプションで、サンプル・ターゲットを設定します。サンプル・ターゲットは、構成データを収集するホストにあります。サンプル・ターゲットを設定しない場合、ファイル・システムを参照できず、仕様の入力時にプレビュー機能を使用できません。
「検索」アイコンをクリックします。ターゲット・タイプの既知のインスタンスを含むダイアログが開きます。必要に応じてフィルタ基準を使用して、目的のインスタンスを検索し、「選択」をクリックします。

5. 「ファイルとコマンド」タブの入力手順は、第44.6.1.3項を参照してください。

6. 「SQL」タブの入力手順は、第44.6.1.4項を参照してください。

7. 仕様の定義が終了し、資格証明をターゲット・タイプにマップしたら、プレビュー機能を使用してエントリを検証します。特に、解析済のビューが適切な内容であるかを確認します。

8. 新規または編集済の仕様を保存します。構成拡張はパブリック・ドメイン内にあることに注意してください。「ドラフトで保存」機能を使用して、テスト中に仕様をプライベートのままにし、仕様を絞り込みます。様々な保存アクションの詳細は、第44.6.1.8項を参照してください。
ドラフトを編集する場合、ボタンは次のように変更されます。

- 「公開」は、ドラフトを公開することを意味します。

- 「保存」は、ドラフトの新規バージョンを作成することを意味します。

終了したら、構成拡張をターゲット・インスタンスにデプロイして、構成データの収集を開始できます。詳細は、第44.6.2項を参照してください。

44.6.1.3 「ファイルとコマンド」タブの使用

次の手順に従って、ファイルとコマンドの仕様を作成します。

1. 検索アイコンをクリックしてデフォルトのベース・ディレクトリの場所に移動します。ここが、構成ファイルがある場所か、指定するコマンドが実行される場所です。
「プロパティの使用」ボタンをクリックして、ターゲット・プロパティを選択してディレクトリ・パスの一部として含めることができるダイアログを開きます。これらのプロパティは変数として機能し、中カッコで示され、実行時に実際の値に置き換えられます。選択内容を補うボックスに追加テキストを入力できます。たとえば、OracleHomeを選択し、ディレクトリ{OracleHome}/configを追加して、Oracle Homeのパスの下の構成サブディレクトリにあるターゲット上のファイルを収集します。ターゲット・タイプの定義によって使用可能なターゲット・プロパティが判別されることに注意してください。ユーザー定義のプロパティは管理エージェントで使用できないため、リストには表示されません。

2. 「詳細設定」をクリックして、次を指定します。

- サンプル・ターゲットの代替ベース・ディレクトリ。

- 管理エージェントでデータを収集する際に使用するエンコーディング。構成データはリポジトリにUTF-8形式で保管されます。「Oracleデフォルト」ではXMLファイルにはUTF-8、その他のファイル・タイプにはターゲットのロケール・エンコーディングが使用されます。「ターゲット・ロケール」では、XMLを含むすべてのファイル・タイプがターゲットのロケール・エンコーディングに格納されます。その他の場合は、ドロップダウン・リストからエンコーディングを選択します。リストから直接選択すると、対応するラジオ・ボタンが自動的に選択されます。

- ターゲットのデータにアクセスするのに管理エージェント資格証明(ファイル仕様のみ)または他の事前定義済の資格証明セットのどちらを使用するか。カスタマイズした資格証明セットがドロップダウン・リストに表示されない場合、「作成」をクリックして、使用する資格証明セットを特定します。次に、作成する資格証明セット名にマップする資格証明を指定する必要があります。マップされた名前が不明な場合、ステップ3で説明しているように、リモート・ファイル・ブラウザを開いてファイルを追加するときに、資格証明セットを指定できます。詳細は、第44.6.1.5項を参照してください。

3. 「追加」をクリックして、仕様タイプとしてファイルまたはコマンドを選択します。
ファイル仕様の場合、指定されたスペースにファイル名を入力するか、ベース・ディレクトリを参照してターゲット上のファイルを選択します。ワイルドカード(*および**)が使用可能で、**は0以上のサブディレクトリを表します。ワイルドカードの使用では(および一般的な注意事項として)、収集によって生じるファイルが多すぎる(または大きすぎる)ようにならないことと、収集されるファイルが構成に関連することに注意します。つまり、管理下にあるファイルの変更を比較的最小限に抑えることで、Cloud Controlがオーバーロードしないようにします。

コマンド仕様の場合、指定されたスペースにコマンド構文を入力するか、スクリプトまでベース・ディレクトリを参照します。コマンドに一意の別名を割り当てる必要があります。割り当てた別名が、構成拡張階層を表示する際のリンクとして、構成ブラウザに表示されます。リンクをクリックすると、右側のタブにコマンド仕様が開かれます。ファイルについて前述した注意事項はコマンド出力にも当てはまります。つまり、その結果は数量およびサイズの制約と、構成に関連したデータにするという制約があります。

パーサーを選択して、リポジトリ内に格納するために、構成ファイルまたはコマンド出力を標準フォーマットに変換します。デフォルトはありません。パーサーを指定しない場合、RAWデータ・フォーマットのみが格納され、表示に使用できます。詳細は、第44.7.1項を参照してください。

オプション。ツリー・ノードを調整する解析後ルールを指定します。ルールの入力の詳細は、第44.6.1.6項を参照してください。

4. ステップ3を繰り返して、追加のファイルまたはコマンドを指定します。

第44.6.1.2項に戻り、7から再開します。

44.6.1.4 「SQL」タブの使用

次の手順に従って、SQL問合せの仕様を作成します。

1. データベースへの接続に使用する資格証明を選択します。カスタマイズした資格証明セットがドロップダウン・リストに表示されない場合、「作成」をクリックして、使用する資格証明セットを特定します。作成する資格証明セット名にマップする資格証明を指定する必要があることに注意してください(第44.6.1.5項を参照してください)。構成拡張は、SYSDBA、SYSOPERまたはその他のロールではなく、NORMALロールのデータベース資格証明のみをサポートします。

2. SQL問合せによってデータを抽出するOracleデータベースへのJDBC接続を指定します。接続文字列は、URLまたはデータベース・ターゲット・プロパティの抽出のいずれかです。これら2つの組合せ(部分的なURLと一部のターゲット・プロパティなど)ではありません。
URLには、ターゲット・データベース・ホストの名前、適用可能なポート番号およびOracle Service名(SID)が含まれている必要があります。例: mydatabase.example.com:1521:ORCL

ターゲット・プロパティを使用する場合、フィールドを空白のままにします。アプリケーションの実行時に、接続を確立するために、これらのターゲット・プロパティ{MachineName}{Port}{SID}が値に置き換えられます。

3. 「追加」をクリックし、表示されたテキスト・ボックスに、SQL問合せを入力または貼付けします。問合せが、管理可能なサイズおよび範囲の該当する構成関連のデータのみを返すのに十分に選択的であることを確認してください。
問合せに一意の別名を割り当てる必要があります。割り当てた別名が、構成拡張階層を表示する際のリンクとして、構成ブラウザに表示されます。リンクをクリックすると、右側のタブでSQL問合せが開きます。

ドロップダウン・リストで、データベース問合せパーサーを事前選択する必要があります。

オプション。ツリー・ノードを調整する解析後ルールを指定します。ルールの入力の詳細は、第44.6.1.6項を参照してください。

4. ステップ3を繰り返して、追加のSQL問合せを指定します。

第44.6.1.2項に戻り、ステップ7から再開します。

44.6.1.5 構成拡張の作成時の資格証明の設定

構成拡張の作成時に資格証明セットを作成する場合は、資格証明セットを構成する資格証明を指定する必要があります。これを実行するには、構成拡張ライブラリに戻り、次の手順を実行する必要があります。

1. 「設定」メニュー(「ヘルプ」メニューの横にあるページの最上部右側)から、「セキュリティ」を選択し、「監視資格証明」を選択します。

2. 表内で適切なターゲット・タイプを選択して、「監視資格証明の管理」をクリックします。

3. 指定したターゲット・タイプに対して、構成拡張定義中に作成した資格証明セット名のある行を選択して、「資格証明の設定」をクリックします。

4. 資格証明セットのユーザー名およびパスワードを入力して、「保存」(またはデータベース資格証明の場合は「テストと保存」)をクリックします。

5. 「ファイルとコマンド」タブ(第44.6.1.3項)または「SQL」タブ(第44.6.1.4項)の説明に戻ります。

44.6.1.6 ルールの設定

ルールを使用して、解析対象の表現で同じ名前を持つノードを区別します。これは、解析対象のツリーのノードに一致させようとする場合や、コンプライアンスを検証するためのSQL問合せを表現する場合の比較および変更履歴で特に重要です。ルールは、ノードを一意に識別する方法としてツリー内のノード・テキストに大括弧で追加された識別子に解決します。これにより、比較などの操作では、ノード・テキストとカッコで囲まれた識別子の組合せが評価用として使用されます。

ルールは、条件および式で構成され、どちらも有効なXPath式である必要があります。条件は、識別子を必要とするノードに解決します。式は、識別子の文字列計算に解決します。条件で指定されたノードをバイパスするには、特殊なケースのSKIP式を使用できます。これはノイズを排除するのに有益な方法です。つまり、比較が目的の場合は、条件で解決されるノードは無視してください。

一部のルールには、すでに定義済のデフォルト・パーサー・ルールがあります。このルールは、解析対象の表現で自動的に実行されます。デフォルト・ルールのサブセットを使用する、デフォルト・ルールを編集する、または定義したカスタム・ルールで上書きするなどできます。

「ルール」列の数値は意味があります。最初は、この数値はゼロ(0)です。ゼロよりも大きいすべての数値は、定義されているカスタム・ルールの数を示します。ゼロは、デフォルトのパーサー・ルールを持つパーサーにも表示されます。したがって、この列に整数が表示されている場合、その数値によって表されるカスタム・ルールにより、デフォルト・パーサー・ルールがあったとしても上書きされることを意味します。

次の手順に従い、ルールを設定します。

1. 「パーサー・ルール」ボタンをクリックします。パーサー・ルールの編集ページが表示されます。

2. カスタム・ルールを定義するには、「追加」をクリックします。表示された表の列で、条件および式を有効なXPath式として入力します。
複数のルールを定義できます。これらは、指定した順序で解析されるコンテンツに適用されます。操作が終わったら「戻る」をクリックします。

カスタム・ルールを削除するには、表の列を選択します。

3. デフォルト・ルールを操作するには、「デフォルト・ルールの追加」をクリックします。
ルールは表の行に表示され、選択したパーサーにはデフォルト・パーサー・ルールがあります。目的に合せて、デフォルト・ルールを適宜、編集および削除します。作業しているのは対象のルールのコピーであり、コピー元のルールは元の状態のまま保管されています。

すべてのルールを削除したとしても、インポートしたコピーを削除したにすぎないことに注意してください。デフォルト・パーサー・ルールは、カスタム・ルールによって上書きされないかぎり、依然として存在します。

ルールの例は、第44.7.6項を参照してください。

「ファイルとコマンド」タブ(第44.6.1.3項)または「SQL」タブ(第44.6.1.4項)の説明に戻ります。

44.6.1.7 構成拡張の管理

構成拡張の作成と編集に加え、次の操作を実行して構成拡張を管理できます。

- 選択した指定内容を表示します(読取り専用)。

- リアルタイムでファセットを監視するため、選択した仕様をコンプライアンス・ライブラリ内のファセットと同期します。

- XMLファイル・フォーマットへのエクスポート、ローカル・ファイル・システムからインポートによって、構成拡張を共有します。

- 選択された指定を削除します(適切な権限が必要です)。

構成拡張の表示

構成拡張を読取り専用モードで表示すると、仕様の構造を理解できます。たとえば、新規構成のベース候補となるかどうかなどを確認できます。

1. 構成拡張ライブラリで、仕様表の行を選択して「詳細の表示」をクリックします。

2. 様々なタブで設定およびルールを詳細に確認します。

ファセットの同期の有効化

構成拡張仕様をリアルタイム監視ファセットと同期することで、構成ファイルと、構成拡張の要素である問合せに対するリアルタイムの変更を監視できます。リアルタイムの監視では、ファイルおよびデータベース設定が変更された日時、変更したユーザー、監視が自動的に調整されたかどうか、監視されたアクションが認可されたかどうか、などを知ることができます。

構成拡張をリアルタイム監視ファセットと同期する場合、構成拡張への今後の変更は対応するファセットに自動的に伝播します。つまり、構成の収集、比較、追跡などが行われるのみでなく、認可済のリアルタイム変更の監視も行われます。構成拡張をファセットと関連付けて、ファセットと同期した構成拡張を続いて編集するためには、EM_COMPLIANCE_DESIGNERの追加的なロールが必要です。

1. 構成拡張ライブラリで、仕様表の行を選択して、「アクション」メニューから「ファセットの同期の有効化」を選択します。

2. 「ファセットの同期」列には、構成拡張表の行の「ファセットの使用」リンクが表示されます。リンクをクリックすると、コンプライアンス・ライブラリの「リアルタイム監視ファセット」タブに移動します。ここではファセットと構成拡張の同期を管理できます。

構成拡張のエクスポート

構成拡張を、後で同じまたは別のシステムにインポートできるXMLファイルとしてエクスポートできます。

1. 構成拡張ライブラリで、仕様表の行を選択して、「アクション」メニューから「エクスポート」を選択します。

2. XMLファイルとして仕様を保存するファイル・システムの場所を参照します。保存されたファイルは、デフォルトで構成拡張の名前を取得します。

構成拡張のインポート

適切な権限が与えられている場合、以前にXMLファイルとしてエクスポートされた構成拡張をインポートできます。

1. 構成拡張ライブラリで、仕様表の行を選択して、「アクション」メニューから「インポート」を選択します。

2. ファイルの場所を参照します。ファイルを選択し、ダイアログで「インポート」ボタンをクリックします。
インポートされた仕様は構成拡張ライブラリに表示されます。

構成拡張の削除

構成拡張を削除するには、所有者であるか、十分な権限を持っている必要があります。依存性があるため、削除によりデプロイメント、ジョブ・スケジュール、既存の収集などに影響を与える可能性があることに注意してください。

1. 構成拡張ライブラリで、仕様表の行を選択して「削除」をクリックします。

2. 構成拡張を含むジョブの発行まで、一部の依存性は検証できませんが、システムによって、権限が検証され、削除を回避する依存性がチェックされます。

44.6.1.8 構成拡張およびバージョニングについて

構成拡張を作成する場合、保存またはドラフトで保存を選択できます。通常の保存アクションでは、一般ユーザーのコミュニティに公開して使用できる仕様を作成します。ドラフトで保存アクションでは、仕様はプライベートのままです。仕様の作成および編集時にこれらのアクションをどのように使用するかによって、バージョニングの方法が異なります。次の例を考えてみます。

- 構成拡張を作成して保存すると、これはパブリック・バージョン1です。その後で、パブリック1を編集してドラフトで保存すると、これはドラフト1になります。パブリック1は通常、まだ使用できます。ドラフト1を編集して公開すると、これはパブリック2になります。適切な権限を持つ別のユーザーも同時にパブリック1を編集してドラフトで保存でき、ドラフト2のバージョン1が作成されることに注意してください。

- 構成拡張を作成してドラフトとして保存すると、これはドラフト1のバージョン1です。このドラフトを編集して再度保存すると、これはドラフト1のバージョン2になります。編集と保存の操作を繰り返すと、これはドラフト1のバージョン3になります。ドラフト1のバージョン3を編集して公開すると、これはパブリック・バージョン1になります。

44.6.1.9 構成拡張および権限について

構成拡張の処理には、実行する特定の操作に特有の権限が必要です。

操作

必要な権限(ロール)

新規ターゲット・タイプの作成

EM_PLUGIN_OMS_ADMIN
新規ターゲット・タイプを作成するには、管理者がソフトウェア・ライブラリをインストールしてあることを確認します(「設定」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」を選択します)。これは、Cloud Controlのインストール後に一度行う必要があります。

新規ターゲット・インスタンスの作成

EM_PLUGIN_AGENT_ADMIN

構成拡張の作成またはインポート

「ユーザーが所有する構成拡張の管理」(「すべてのユーザーが所有する構成拡張の管理」の方がより強力です)

構成拡張と自動的に同期されたリアルタイム監視ファセットの関連付け

EM_COMPLIANCE_DESIGNER

構成拡張の編集または削除

編集のレルム内の特定のアクティビティに応じて異なります。

- 構成拡張の所有者は「ユーザーが所有する構成拡張の管理」が必要。所有者でない場合は「すべてのユーザーが所有する構成拡張の管理」が必要です。

- すでにデプロイされたターゲットの再デプロイメント・ジョブをスケジュールには、ジョブ・システム・リソース・タイプに対する作成権限が必要です。

- リアルタイム監視ファセットに関連付けられた構成拡張では、EM_COMPLIANCE_DESIGNERが必要です。

ターゲットへの構成拡張のデプロイまたはアンデプロイ

ターゲット・インスタンスに対する「ターゲット・メトリックの管理」権限。「ジョブ・システム」リソース・タイプに対する「作成」権限(デプロイメント/アンデプロイメントをスケジュールする場合)。EM_PLUGIN_AGENT_ADMIN(プラグインを管理エージェントにデプロイする場合)

新規資格証明セットの作成

スーパーユーザー

構成拡張定義の表示

なし

構成拡張収集データの表示

通常の「ターゲット・インスタンス・ビュー」権限

インポートされた構成拡張を編集すると、エクスポート中に設定されたオプションによっては、バージョンを変更しない編集に制限されることがあることに注意してください。このような許容可能な編集は資格証明セット情報に対して存在します。

44.6.2 構成拡張およびデプロイについて

構成拡張をデプロイすることは、監視する管理エージェントが指定内容の定義に基づいて構成データを収集するターゲットに、指定内容を指示することです。構成拡張は複数のターゲットにデプロイできます。構成拡張をデプロイおよびアンデプロイするには、十分な権限を持っている必要があります。

デプロイは、次のアクションを実行して管理します。

- 構成拡張のデプロイおよびアンデプロイ

- 構成拡張のデプロイメントの編集

- 構成収集の表示

44.6.2.1 構成拡張のデプロイおよびアンデプロイ

構成拡張をデプロイすることは、監視する管理エージェントが指定内容の定義に基づいて構成データを収集するターゲットに、指定内容を指示することです。構成拡張は複数のターゲットにデプロイできます。構成拡張をデプロイおよびアンデプロイするには、十分な権限を持っている必要があります。

構成拡張をデプロイするには、次の手順を実行します。

1. 構成拡張ライブラリで、仕様表の行を選択して「デプロイメントの管理」をクリックします。

2. デプロイ・ページで、「追加」をクリックします。開いたダイアログで、構成拡張をデプロイする指定したターゲット・タイプのターゲットを検索および選択します。

3. ダイアログを閉じると(「選択」をクリック)、デプロイ処理が保留中であることを示す新しい列が表示され、ステータスが「デプロイ用に選択されました」となります。

4. 次のようにします。

- デプロイ・ページで、「適用」をクリックして、アクションを確定します。アクション列が表示されなくなり、ステータスが「デプロイメント・ジョブが進行中」となります。

- デプロイをスケジュールし、ライブラリに戻るには、「OK」をクリックします。

- リクエストを無効にし、ライブラリに戻るには、「取消」をクリックします。

5. デプロイ・ページで「ステータスのリフレッシュ」をクリックし、結果が正常であることを確認します。

デプロイ済の構成拡張を更新した場合、再デプロイが自動的に行われます。

構成拡張をアンデプロイするには、次の手順を実行します。

1. デプロイ・ページで、表内のデプロイメントを選択します。

2. 「削除」をクリックします。「アンデプロイ」処理が保留中であることを示す新しい列が表示されます。ステータスは「デプロイ済」のままです。

3. 次のようにします。

- デプロイ・ページで、「適用」をクリックして、アクションを確定します。アクション列が表示されなくなり、ステータスが「アンデプロイ・ジョブが進行中」となります。

- アンデプロイをスケジュールして、ライブラリに戻るには、「OK」をクリックします。

- リクエストを無効にし、ライブラリに戻るには、「取消」をクリックします。

4. デプロイ・ページで「ステータスのリフレッシュ」をクリックし、結果が正常であることを確認します。

ライブラリ内の構成拡張の表示では、現在デプロイされている構成拡張が、デプロイ列の緑色のチェック・マークで示されます。チェック・マークをクリックすると、デプロイ・ページが表示されます。

44.6.2.2 構成拡張のデプロイメントの編集

デプロイメントを編集するには、次の手順を実行します。

1. 構成拡張ライブラリで、適切な行を見つけ、デプロイ・リンクをクリックします。

2. デプロイ・ページで、表内のデプロイメントを選択し、「編集」をクリックします。

3. 構成拡張のタイプ(ファイル/コマンド・ベースまたはSQLベース)によって、開いたダイアログの構成が決定します。ベース・ディレクトリを指定して、現在有効なデフォルト・ベース・ディレクトリをオーバーライドするか、JDBC URLを適切に変更します。

4. 次のようにします。

- デプロイ・ページで、「適用」をクリックして、アクションを確定します。アクション列が表示されなくなり、ステータスが再デプロイ・ジョブが進行中となります。

- 再デプロイをスケジュールし、ライブラリに戻るには、「OK」をクリックします。

- リクエストを無効にし、ライブラリに戻るには、「取消」をクリックします。

5. デプロイ・ページで「ステータスのリフレッシュ」をクリックし、結果が正常であることを確認します。

編集内容は仕様のデプロイに適用されることに注意してください。これにより、構成拡張定義が変更されます。

44.6.2.3 構成収集の表示

構成拡張の収集されたデータを表示するには、十分な権限を持っている必要があります。

1. 構成拡張ライブラリで、適切な行を見つけ、デプロイ・リンクをクリックします。

2. デプロイ・ページで、表内のデプロイメントを選択し、「構成の表示」をクリックします。

3. 構成ブラウザのポップアップ・ウィンドウで、次のように左側のツリー階層でノードを選択して、構成拡張の詳細を調べます。

- ルート・ノードは、監視されているターゲット・インスタンスを示します。右側のペインに、ターゲット・プロパティおよび即時の関係が表示されます。

- ツリーの次のレベルは、仕様のテンプレートを示します。右側のペインに、収集する構成などの仕様の詳細、および収集元のベース・ディレクトリが表示されます。

- ツリーの残りのリーフ・ノードは、収集された構成データを示します。右側のペインに、解析済フォーマットおよびRAWフォーマットの両方で構成データが表示されます。

収集されたデータをターゲットのホームページに表示することもできます。ターゲット・タイプ・メニューから「構成」を選択し、「最新収集」を選択します。

44.6.3 構成データ収集の拡張

構成拡張仕様を使用して構成データ収集を拡張する場合、2つのオプションを使用できます。

- 既存のターゲット・タイプへの追加収集アイテムの追加

- 新規収集アイテムを使用するカスタム・ターゲット・タイプの追加

44.6.3.1 既存のターゲット収集の拡張

次の手順では、Cloud Controlで既存のターゲット・タイプについて収集する構成データを拡張する方法を示します。たとえば、リスナー・ターゲット・タイプの場合、そのままではsqlnet.oraファイルは収集されません。このアイテムを含むようリスナーのデータ収集を拡張するには、次のようにします。

1. 「エンタープライズ」メニューから「構成」を選択し、「構成拡張」を選択します。

2. 構成拡張ライブラリで、「作成」ボタンをクリックします。

3. 構成拡張に適切な名前を指定し、ターゲット・タイプとして「リスナー」を選択します。

4. 「ターゲット・インスタンスの選択」をクリックして、すでにデプロイされているリスナー・インスタンスを選択します。これで、ファイルの場所に移動できます。

5. 「デフォルト・ベース・ディレクトリ」を「Oracleホーム」に設定します。

6. これで、収集データの指定を作成する準備ができました。「追加」をクリックし、検索アイコンをクリックしてリモート・ファイル・ブラウザにログインします。適切な資格証明を設定します。

7. リスナー・インスタンスのOracleホーム・ディレクトリでnetwork/adminサブディレクトリに移動し、sqlnet.oraファイルを選択します。選択内容の表に追加し、「OK」をクリックします。

8. ファイルが追加された「ファイルとコマンド」タブで、ドロップダウン・リストから適切なパーサー(この場合は「Oracle ORAパーサー」)を選択します。収集されたデータに含まれるファイル属性を解析された形式とRAW形式で表示する場合、「プレビュー」をクリックします。
「保存」をクリックして構成拡張の作成を終了します。

9. 構成拡張ライブラリで、新しい構成拡張を選択して「デプロイメントの管理」をクリックします。

10. デプロイの管理ページで、「追加」をクリックします。表示されたダイアログで、構成拡張をデプロイするターゲットを選択します。

11. ステータスが発行済と表示されたら、「適用」をクリックします。ステータスが成功になるまでビューをリフレッシュし、「保存」をクリックします。

12. 追加されたデータ収集を確認するには、ターゲット・インスタンスのホームページに移動します。「Oracleリスナー」メニューから「構成」、「最新収集」の順に選択します。
構成ブラウザで、左側のツリー構造に構成拡張が表示されます。ディレクトリ構造をドリルダウンし、sqlnet.ora属性と値を解析された形式とRAW形式で右側に表示できます。

既存の構成データ収集を拡張するテンプレートとしてこの説明を使用してください。

44.6.3.2 新規ターゲット・データ収集の追加

次の手順では、新規ターゲット・タイプを追加してCloud Controlで収集する構成データを拡張する方法を示します。例では、カスタムApache Webサーバー・ターゲット・タイプについてデータを収集するものとします。

まず、カスタム・ターゲット・タイプを作成します。

1. 「エンタープライズ」メニューから「構成」を選択し、「構成拡張」を選択します。

2. 「アクション」メニューから、「カスタム・ターゲット・タイプの作成」を選択します。

3. 表示されたダイアログで、ターゲット・タイプ名(MyApacheなど)を入力します。「OK」をクリックします。

4. しばらくすると、ターゲット・タイプ作成の確認メッセージが表示されます。「はい」をクリックして、サンプル・ターゲット・インスタンスを追加します。

5. 検索アイコンをクリックし、アプリケーション(Apache Tomcat)が配置されているホストの管理エージェントを選択します。管理エージェントを選択し、「選択」をクリックしてダイアログを閉じ、「ターゲットの追加」をクリックします。

6. 表示されたターゲット・プロパティのダイアログで名前(MyApache)を入力し、インストール・ホーム・パスを管理エージェントのアプリケーション(Apache Tomcat)の開始場所に設定します。「OK」をクリックします。

7. 構成拡張ライブラリで、「作成」ボタンをクリックします。

- 名前(たとえば、MyApache)を入力します。

- ドロップダウン・メニューから、カスタム・ターゲット・タイプMyApacheを選択します。

- 「ターゲットの選択」をクリックし、MyApacheサンプル・ターゲット・インスタンスを選択します。

8. これで、収集データの指定を作成する準備ができました。{INSTALL_LOCATION}変数が 「デフォルト・ベース・ディレクトリ」フィールドに移入されることに注意してください。「追加」をクリックし、検索アイコンをクリックしてリモート・ファイル・ブラウザにログインします。適切な資格証明を設定します。

9. 管理エージェントのApacheインストール・ホームでconfディレクトリに移動し、httpd1.confファイルを選択します。選択内容の表に追加し、「OK」をクリックします。

10. ファイルが追加された「ファイルとコマンド」タブで、ドロップダウン・リストから適切なパーサー(この場合は「Apache HTTPDパーサー」)を選択します。収集されたデータに含まれるファイル属性を解析された形式とRAW形式で表示する場合、「プレビュー」をクリックします。
「保存」をクリックして構成拡張の作成を終了します。

11. 構成拡張ライブラリで、新しい構成拡張を選択して「デプロイメントの管理」をクリックします。

12. デプロイの管理ページで、「追加」をクリックします。表示されたダイアログで、構成拡張をデプロイするターゲット(構成拡張のベースとなったホストなど)を選択します。

13. ステータスが発行済と表示されたら、「適用」をクリックします。ステータスが成功になるまでビューをリフレッシュし、「保存」をクリックします。

14. 新規データ収集を確認するには、すべてのターゲットの検索を行い、左側の「その他」カテゴリでカスタム・ターゲット・タイプを特定してクリックし、そのタイプのすべてのデプロイメントを右側に表示します。

15. 右側のデプロイメント・リストでターゲット・インスタンス(MyApache)をクリックします。構成ブラウザで、左側のツリー構造に構成拡張が表示されます。ディレクトリ構造をドリルダウンし、httpd1.confの属性と値を解析された形式とRAW形式で右側に表示できます。

カスタム・ターゲット・タイプを介して構成データ収集を拡張するテンプレートとしてこの説明を使用してください。

44.6.4 構成拡張のブループリントとしての使用

特別に作成されたブループリントと呼ばれる構成拡張が、Oracleからダウンロードできます。ブループリントと呼ばれるのは、特定のプラットフォームについて収集するファイルとデータを詳細に規定しているためです。現在サポートされているプラットフォームは次のとおりです。

- Apache Tomcat

- Apache Webサーバー

- GlassFish

- iPlanet

- JBoss

- JRun

- Tuxedo

これらのブループリント(構成拡張とも呼ばれる)は、構成管理ベスト・プラクティス・センターからダウンロードできます。ここで、新たなプラットフォームのサポートもチェックできます。

44.7 パーサーの概要

パーサーは、RAW構成データを取得し、ネストされた属性構造に解析します。この構造はツリー階層で、ノードがコンテナで、リーフが名前と値のペアの属性、またはプロパティです。

構成拡張には、即時利用可能なパーサーが多数含まれています。各パーサーは、ベース・パーサーとパーサー・パラメータで構成されています。一部のパーサーには、解析後ルールも含まれます。ベース・パーサーは、基本的に、特定のフォーマットのデータを解析できるパーサーのカテゴリです。パーサー・パラメータは、データのフォーマットでの変動に対応するために、ベース・フォーマットを調整する方法を提供します。解析後ルールは、他に明確なアイデンティティがないツリー内のノードを調整するためのメカニズムです。これは、構成の比較や変更履歴の追跡によって誤検出の差異にフラグを付けることを回避する際に重要になります。またはこのメカニズムは、検索基準の指定やコンプライアンス・ルールで使用されるSQL問合せの作成に役に立ちます。

ベース・パーサーには次の4つがあります。

- XML

- フォーマット固有

- 列指向

- プロパティ

一部のパーサーには即時利用可能なデフォルト・ルールがあります。これらのルールは、ノードを調整する必要がある周知のインスタンスに対応します。特に、WebLogicおよびWebSphereパーサーには、このようなインスタンスに対応するデフォルト・ルールが含まれています。これらのルールはそのままにしておいても問題なく、これらのサブセットを実行することも、または独自のカスタム・ルールで置き換えることもできます。

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

- パーサーの管理

- XMLパーサーについて

- フォーマット固有のパーサーについて

- 列指向パーサーについて

- プロパティ・パーサーについて

- 解析されたファイルおよびルールの使用

44.7.1 パーサーの管理

構成拡張の作成、編集または表示の間、使用可能なパーサーのリスト、デフォルトのパラメータおよび該当する場合は解析後ルールを詳細に調べることができます。パーサー・パラメータは、コメント文字、デリミタ、開始および終了文字などの書式を決定します。これらのパラメータは編集できませんが、パーサーをXMLファイルとしてエクスポートし、ファイルを編集して、新しい名前でアプリケーションにインポートできます。また、一部のパーサーには、比較などを行うために、解析対象のツリー内のノードをそろえるデフォルト・ルールがあります。

1. 構成拡張ライブラリで、「アクション」メニューから「パーサーの管理」を選択します。使用可能なパーサーのリストが表に表示されます。右側の列(ベース・パーサー)は一般的なパーサー・カテゴリ、たとえばプロパティを示しており、これはファイル・タイプを表し、名前/値のペアが含まれます。

2. パーサーを選択して、「詳細」をクリックします。このダイアログには、デフォルト・ルール(存在する場合)も表示されます。

- 「パラメータ」をクリックし、有効なパラメータのデフォルトを参照します。これにより、ファイル形式の規則に準拠するようにパーサーを編集する必要があるかどうかを判断できます。

- 「デフォルト・ルール」タブをクリックし、特定のパーサーとともに出荷される解析後ルールを参照します。これは、ルールの構成を把握するための便利な方法です。

3. 指定されたパーサーのデリミタ文字を変更する場合は、次のようにします。

1. 表でパーサーを選択した状態で、「エクスポート」をクリックします。

2. 表示されるダイアログで「保存」をクリックして、ファイルシステムの場所に移動します。XMLファイルを適切な名前で保存します。

3. すぐに利用可能なパーサーのカスタマイズ版を作成しているため、編集時には、XMLのパーサーIDとパーサー名も変更してください。

4. 構成拡張の作成に使用するために保存した新しいパーサーをインポートする場合は、次のようにします。

1. パーサー表が開いた状態で、「インポート」をクリックします。

2. 表示されるダイアログで、エクスポートされたパーサー・ファイルを保存したファイルの場所を参照します。そのファイルを選択して、ダイアログの「インポート」をクリックします。

新しいパーサーが、構成拡張の作成に使用できる「パーサー」表に表示されます。

「ファイルとコマンド」タブの下の「パーサーの管理」リンクをクリックして、構成拡張を処理しているときにパーサーを管理することもできます。

44.7.2 XMLパーサーについて

Cloud Controlには2つのXMLパーサーがあります。デフォルト(属性キー)XMLパーサーと汎用XMLパーサーです。

44.7.2.1 デフォルトXMLパーサーについて

解析は次のように行われます。

- XML属性または子要素のないXML要素は解析対象属性になります。その他の要素はすべてコンテナになります。

- XML属性は解析対象属性になります。

- 要素テキスト・コンテンツは解析対象属性になり、その名前はタグにXML属性が含まれているかどうかによって異なります。タグにXML属性が含まれている場合、解析対象属性の名前はSTORE_CONTENT_ASパラメータで指定された値を取得します。含まれていない場合、解析対象属性の名前はタグ名を取得します。

デフォルトXMLパーサーが受け入れるパラメータは次のとおりです。

パラメータ

説明

MULTIKEY_DELIMITER

CONTAINER_NAMEパラメータでXML属性名のリストを区切るデリミタ。デフォルト: チルダ(~)

STORE_CONTENT_AS

要素にXML属性が含まれる場合に、要素テキスト・コンテンツから取得される、解析対象属性に付与される名前。デフォルト: text_value

CONTAINER_NAME

MULTIKEY_DELIMITERパラメータの値で区切られるXML属性名のリスト。このリストの属性名が元のファイルのタグに表示される場合、タグはXML属性の値で名付けられたコンテナになります。その他のすべてのXML属性は、通常どおり解析対象属性になります。タグ名自体は無視されます。
たとえば、リストに属性名のMoeおよびLarryがこの順序で含まれます。元のファイルにはXMLタグのStoogesが含まれ、そのタグには属性Moe、LarryおよびCurlyがあります。区切られたリストでMoeが最初に表示されるため、その値、leaderは解析対象コンテナ名になります。LarryおよびCurlyは解析対象属性になります。タグ名Stoogesは無視されます。元のXMLフラグメントは次のようになります。

<?xml version="1.0" encoding="UTF-8"?>
<Comedy>
<Stooges Moe="leader", Larry="zany", Curly="bald">
</Stooges>
</Comedy>

WebLogic属性キー・パーサー

Cloud Controlは、特にWebLogic config.xmlファイルの解析用に設計されている即時利用可能な属性キー・パーサーを提供します。これはデフォルトXMLパーサーと同じパラメータを保有し、同じ名前のノードを一意に特定するための26のデフォルト解析後ルールを備えています。

WebSphere属性キー・パーサー

Cloud Controlは、特定のWebSphere構成ファイルの解析用に設計されている即時利用可能な属性キー・パーサーを複数提供します。各パーサーはデフォルトXMLパーサーと同じパラメータを保有し、同じ名前のノードを一意に特定するための一連のデフォルト解析後ルールを備えています。次のWebSphere構成ファイルのためのパーサーがあります。

- node.xml (1つのデフォルト解析後ルール)

- plugin-cfg.xml (7つのデフォルト解析後ルール)

- resource.xml (9つのデフォルト解析後ルール)

- server.xml (13のデフォルト解析後ルール)

- variables.xml (1つのデフォルト解析後ルール)

44.7.2.2 汎用XMLパーサーについて

解析は次のように行われます。

- すべてのXML要素がコンテナになります。

- すべてのXML属性は解析対象属性になります。

- 要素テキスト・コンテンツは名前text_valueを取得する解析対象属性になり、ここでテキスト・コンテンツは解析対象属性値になります。

汎用XMLパーサーはパラメータを受け入れません。

WebSphere汎用パーサー

Cloud Controlは、WebSphere serverindex.xml構成ファイルの解析用に設計されている即時利用可能な1つの汎用パーサーを提供します。これは同じ名前のノードを一意に特定するための3つのデフォルト解析後ルールを備えています。

44.7.2.3 XMLパーサーの例

この項には、3つのXMLパーサーの例が記載されています。

- 即時利用可能なパラメータ値とともにデフォルトXMLパーサーを使用して解析される場合

- 変更されたパラメータ値とともにデフォルトXMLパーサーを使用して解析される場合

- 汎用XMLパーサーを使用して解析される場合

解析例は次のような元のXMLファイルから導かれます。

<?xml version="1.0" encoding="UTF-8"?>
<Application>
<AppName>foo</AppName>
<Server name="ajax" os="linux">production</Server>
</Application>

デフォルトXMLパーサー(即時利用可能なパラメータ値)

即時利用可能なパラメータ値とともにデフォルトXMLパーサーを使用して解析される場合、解析後バージョンは次のように表示されます。

Application
AppName = foo
Server
name = ajax
os = linux
text_value = production

この解析後バージョンでは次の点に注意してください。

- AppNameタグおよびServerタグの要素コンテンツが解析対象属性になります。

- AppNameタグにXML属性が含まれていないため、解析対象属性名はタグ名を取得します。

- XML属性(nameおよびos)を持つServerタグとの対比。ここではタグで名付けられたコンテナ(Server)が生成されます。これには3つの解析対象属性があり、この中の2つは2つのXML属性に対するものです。もう1つはServerタグのテキスト・コンテンツに対するもので、これはSTORE_CONTENT_ASパラメータの値(text_value)に設定されます。

デフォルトXMLパーサー(変更されたパラメータ値)

パラメータ値を変更するには新規パーサーを作成する必要があります。これにはデフォルトXMLパーサーのエクスポート、エクスポートされたXMLファイルの変更、および変更されたパーサーの(新規の名前およびパーサーIDを使用した)インポートが必要です。

このプロセスに従い、次の変更を行ったと仮定します。

- STORE_CONTENT_ASパラメータを値myValに設定

- CONTAINER_NAMEパラメータを値nameに設定

変更されたパラメータ値とともにデフォルトXMLパーサーを使用して解析される場合、解析後バージョンは次のように表示されます。

Application
AppName = foo
ajax
os = linux
myVal = production

この解析後バージョンでは次の点に注意してください。

- AppNameタグはそのまま同じです。つまり、XML属性がないため、解析対象属性になります。

- ServerタグにはCONTAINER_NAMEの値に一致するXML属性があるため、コンテナは属性の値(ajax)を取得し、name=ajax解析対象属性が不要になります。即時利用可能なCONTAINER_NAMEパラメータにはプレースホルダがありますが、実際のデフォルト値はありません。したがって、このバージョンの解析対象の表現との差異になります。

- 残りのServerタグ属性(os)は通常どおり解析対象属性になります。タグに関連付けられたテキスト・コンテンツは、編集されたSTORE_CONTENT_ASパラメータごとに、属性myValの値になります。

汎用XMLパーサー

(パラメータをまったく使用しない)汎用XMLパーサーを使用して解析される場合、解析後バージョンは次のように表示されます。

Application
AppName
text_value = foo
Server
name = ajax
os = linux
text_value = production

解析手順については第44.7.2.1項を参照してください。

44.7.3 フォーマット固有のパーサーについて

フォーマット固有のベース・パーサーは、特定のデータ・フォーマットにのみ適用可能です。フォーマット固有のパーサーは、フォーマットを調整するパラメータがまったくないものから、少しあるもの、多数あるものまで様々です。

パーサー

説明

Blue Martini DNA

Blue Martini DNAファイル用のパーサー(パラメータなし)。

Connect:Direct

Connect:Direct .cfgファイル用のパーサー(パラメータなし)。

データベース問合せ(サンプルは第44.7.6.3項を参照)

構成拡張のデータベース問合せ出力用のパーサー。Cloud Controlは、問合せ結果をパーサーが受入れできる形式に自動的に変換し、Windowsの.iniファイルと同様に結果をセクションに編成します。各セクションは1レコードを表し、セクション内の各行には表列名と値が含まれます。44.7.3.1項を参照してください。

Db2

DB2 GET DATABASE CONFIGURATIONコマンドの出力用のパーサー(パラメータなし)。

ディレクトリ

同じ行に複数の名前と値のペアが含まれる(つまり、各行に様々な数のペアが含まれる)ファイル用のパーサー。たとえば、第1行がa=b j=k、第2行がc=d m=n y=zのような場合です。44.7.3.2項を参照してください。

E-Business Suite

E-Business Suite .drvファイル用のパーサー。パーサーはファイル内のIF...THEN...ELSE構造を解析対象の表現内のコンテナに変換して、残りの行を固定された数の解析対象属性があるコンテナに変換します。これらの行は2種類に分けられます。解析対象属性の名前がDIR_HEADERパーサー・パラメータで指定されているディレクトリ仕様と、解析対象属性の名前がHEADERパーサー・パラメータで指定されている構成ファイル仕様です。44.7.3.3項を参照してください。

Galaxy CFG

Galaxy .cfgファイル用のパーサー。44.7.3.4項を参照してください。

Introscope

Introscopeファイル用のパーサー(パラメータなし)。

MQ-Series

MQ-Seriesファイル用のパーサー。44.7.3.5項を参照してください。

Odin

Odinファイル用のパーサー(パラメータなし)。

Oracle ORA

tnsnames.oraなどのOracle .oraファイル用のパーサー(パラメータなし)。

Siebel

Siebel siebnsファイル用のパーサー。パーサーはファイル内の一意の各パスに対するコンテナと、名前と値のペアに対する属性を作成します。ただし、行に文字列Type=emptyが含まれる場合は例外で、この場合、パーサーは行に対して解析対象属性を作成しません。44.7.3.6項を参照してください。

UbbConfig

BEA Tuxedoファイル用のパーサー(パラメータなし)。パーサーは先頭にアスタリスク(*)があるセクションと、新規行の最初にある二重引用符で囲まれた名前を、コンテナに変換します。その他のすべてのデータを属性に変換します。

UNIXインストール済パッチ

UNIXインストール済パッチ・データ用のパーサー。パーサーはファイルの(コメント行ではない)各行ごとに1つのコンテナを作成します。パーサーは、各行でコロン(:)で終了するすべてのフィールドをプロパティ名フィールドとして扱い、それに続く値(がある場合)はプロパティ値として扱います。プロパティには値が必ずしも必要ではありません。44.7.3.7項を参照してください。

UNIX再帰的ディレクトリ・リスティング

UNIX再帰的ディレクトリ・リスティング(ls -l -R)の出力用のパーサー。パーサーは各サブディレクトリ行をコンテナに変換して、各ファイル情報の行を固定された一連の属性があるコンテナに変換します。詳細は、44.7.3.8項を参照してください。

フォーマット固有のパーサーを変更するには新規パーサーを作成する必要があります。これには特定のパーサーのエクスポート、エクスポートされたXMLファイルの変更、および変更されたパーサーの(新規の名前およびパーサーIDを使用した)インポートが必要です。

44.7.3.1 データベース問合せパーサーのパラメータ

次の表で、データベース問合せパーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ

説明

CELL_DELIMITER

名前と値のペアを区切る文字。デフォルトは=です。

PROPERTY_DELIMITER

名前または値の長さを値そのものから区切る文字。デフォルトは_です。

COMMENT

次に続く行を無視するようにパーサーに伝える文字。デフォルトは#です。

SECTION_START

セクションの開始を示す文字。デフォルトは\[です(バックスラッシュはエスケープ文字です)。

SECTION_END

セクションの終了を示す文字。デフォルトは\]です(バックスラッシュはエスケープ文字です)。

USE_INI_SECTION

Windows .iniタイプ・セクションを使用するようにパーサーに伝えるフラグ。デフォルトはtrueです。

44.7.3.2 ディレクトリ・パーサーのパラメータ

次の表で、ディレクトリ・パーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ

説明

CELL_DELIMITER

あるプロパティを別のプロパティと区切る文字。デフォルトはスペースです。

EXTRA_DELIMITER

プロパティ名をその値から区切る文字。デフォルトは=です。

COMMENT

次に続く行を無視するようにパーサーに伝える文字。デフォルトは#です。

44.7.3.3 E-Business Suiteパーサーのパラメータ

次の表で、E-Business Suiteパーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ

説明

DIR_HEADER

ディレクトリ仕様の属性名のチルダ区切りリスト。

STRUCTURE_START

構造の開始を表す正規表現のチルダ区切りリスト。

CELL_DELIMITER

名前と値のペア・デリミタを表す正規表現のチルダ区切りリスト。

HEADER

ファイル仕様の属性名のチルダ区切りリスト。

COMMENT

コメントを表す正規表現のチルダ区切りリスト。

STRUCTURE_END

構造の終了を表す正規表現のチルダ区切りリスト。

LAST_FREE_FORM

ディレクトリ仕様またはファイル仕様の最後の値のセル・デリミタを無視するようにパーサーに伝えるフラグ。デフォルトはtrueです。

ELEMENT_FIELD

ファイル仕様の属性名のチルダ区切りリスト。パーサーは指定された属性の値を連結して、ファイル仕様に関連付けられたコンテナの名前を生成します。

DIR_ELEMENT_FIELD

ディレクトリ仕様に関連付けられたコンテナの名前を決定する際にパーサーで使用される、ディレクトリ仕様の属性名のチルダ区切りリスト。

44.7.3.4 Galaxy CFGパーサーのパラメータ

次の表で、Galaxy CFGパーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ

説明

COMMENT

次に続く行を無視するようにパーサーに伝える文字。デフォルトは!です。

ADD_SUFFIX

コンテナ名に追加する値を保有する属性の名前。

MONO_PROP_SECTION

単一のプロパティを持つセクションの名前。

MULTI_PROP_SECTION

複数のプロパティを持つセクションの名前。

NODES_SECTION

セクションの開始および終了要素の名前

44.7.3.5 MQ-Seriesパーサーのパラメータ

MQ-Seriesパーサーのカスタマイズ可能なパラメータはCOMMENTの1つのみで、このデフォルト値は*です。

44.7.3.6 Siebelパーサーのパラメータ

次の表で、Siebelパーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ

説明

LINES_TO_SKIP

ファイルの開始時に無視する行数をパーサーに伝えます。デフォルトは4です。

CELL_DELIMITER

名前と値のペア・デリミタを表す正規表現のチルダ区切りリスト。

COMMENT

コメントを表す正規表現のチルダ区切りリスト。

SECTION_START

一意のパス仕様セクションの開始を表す正規表現のチルダ区切りリスト。

SECTION_END

一意のパス仕様セクションの終了を表す正規表現のチルダ区切りリスト。

USE_INI_SECTION

Windows .iniタイプ・セクションを使用するようにパーサーに伝えるフラグ。デフォルトはtrueです。

44.7.3.7 UNIXインストール済パッチ・パーサーのパラメータ

次の表で、UNIXインストール済パッチ・パーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ

説明

CELL_DELIMITER

名前と値のペアを区切る文字。デフォルトはスペースです。

EXTRA_DELIMITER

プロパティ名をその値から区切る文字。デフォルトは:です。

COMMENT

次に続く行を無視するようにパーサーに伝える文字。デフォルトは#です。

44.7.3.8 UNIX再帰的ディレクトリ・リスティング・パーサーのパラメータ

次の表で、UNIX再帰的ディレクトリ・リスティング・パーサーのカスタマイズに使用できるパラメータについて説明します。

パラメータ

説明

LINES_TO_SKIP

ファイルの開始時に無視する行数をパーサーに伝えます。デフォルトは4です。

CELL_DELIMITER

名前と値のペア・デリミタを表す正規表現のチルダ区切りリスト。

COMMENT

コメントを表す正規表現のチルダ区切りリスト。

HEADER

属性名のチルダ区切りリスト。

LAST_FREE_FORM

行の最後の値のセル・デリミタを無視するようにパーサーに伝えるフラグ。デフォルトはtrueです。

SECTION_START

サブディレクトリ・セクションの開始を表す正規表現のチルダ区切りリスト。

SECTION_END

サブディレクトリ・セクションの終了を表す正規表現のチルダ区切りリスト。

ELEMENT_FIELD

属性名のチルダ区切りリスト。パーサーは指定された属性の値を連結して、行に関連付けられたコンテナの名前を生成します。

44.7.4 列指向パーサーについて

列指向パーサーは、フォーマットの調整のために受け入れるパラメータによって、本質的に柔軟性があります。すべての列指向パーサーは、同じパラメータのサブセットを使用します。

パーサー

説明

Cronアクセス

cron.allowファイルおよびcron.denyファイル用のパーサー。

Cronディレクトリ

UNIXのetcファイルおよびcron.dファイル用のパーサー。

CSV

カンマ区切り値データ用のパーサー。即時利用可能なパラメータ値は次の特徴を持つCSVファイルをサポートしています。

- 各行に同じ数の値があります。

- 最初に解析された行(つまり、非コメント行)がヘッダー行で、そのコンテンツが列名のカンマ区切り値リストです。

- 二重引用符で囲まれたカンマは値のデリミタではなく、値の一部とみなされます。

- 列名の1つが"name"で、この値が各行に関連付けられたコンテナの名前になります。

二重引用符で囲まれたテキストは値の一部とみなされます。二重引用符が含まれる値を指定する場合は、二重引用符をバックスラッシュ(\)でエスケープします。バックスラッシュ文字そのものをエスケープするには、バックスラッシュを使用します(\\)。

ホスト・アクセス

hosts.allowファイルおよびhosts.denyファイル用のパーサー。

Kernelモジュール

kernel modulesファイル用のパーサー。

Linuxディレクトリ・リスティング

Linuxディレクトリ・リスティングのデータ形式(例: ls -lコマンドの出力)用のパーサー。

PAM構成

pam.confファイル用のパーサー。

PAMディレクトリ

UNIX etc/pam.dファイル用のパーサー。

プロセス・ローカル

process.localファイル用のパーサー。

Secure TTY

UNIX etc/securettyファイル用のパーサー。

Solarisインストール済パッケージ

Solarisインストール済パッケージ・ファイル用のパーサー。

UNIX Crontab

UNIX Crontabファイル用のパーサー。

UNIXディレクトリ・リスティング

UNIXディレクトリ・リスティングのデータ形式(例: ls -lコマンドの出力)用のパーサー。

UNIX Groups

UNIX etc/groupファイル用のパーサー。パーサーはグループ名とパスワード情報を無視します。

UNIX GShadow

UNIX etc/gshadowファイル用のパーサー。

UNIX Hosts

UNIX etc/hostsファイル用のパーサー。

UNIX INETD

UNIX etc/inetd.confファイル用のパーサー。

UNIX Passwd

UNIX etc/passwdファイル用のパーサー。パーサーはパスワード値を無視します。

UNIX Protocols

UNIX etc/hostsファイル用のパーサー。

UNIX Services

UNIX etc/services.confファイル用のパーサー。

UNIX Shadow

UNIX etc/shadowファイル用のパーサー。

UNIXシステムCrontab

UNIXシステムcrontabファイル用のパーサー。システムcrontabファイルはcrontabファイルと非常に似ていますが、PATH=/a/bなどの名前と値のペアが含まれる場合があります。

44.7.4.1 列指向パーサーのパラメータ

この項では、すべての列指向ベース・パーサーのパラメータについて説明します。ベース・パーサーは次のどのパラメータの値も受入れできますが、指定されたパーサー仕様はすべてのパラメータの値を必ずしも提供する必要はありません。すべてのパラメータにはデフォルト値があり、これらは指定された値がないときに使用されますが、パラメータに明示的な値がある場合もあります。

デリミタまたはその他の特殊なテキスト(コメント文字や新規行など)がある値の一部を表すときは、引用符を使用します。QUOTE_DELIMITERは使用する文字値を決定します。文字をエスケープする必要がある場合は、引用符デリミタの先頭にバックスラッシュ(\)を追加します。引用された文字列でバックスラッシュ文字そのものをエスケープするには、バックスラッシュを使用します(\\)。

パラメータ

説明

COMMENT

コメントの文字またはシーケンスを示す正規表現のチルダ区切りリスト。たとえば、#[^\r\n]*は、行の上で#文字に続くすべてがコメントであることを指定します。デフォルトは空のリストです。つまり、すべてのファイル・コンテンツを解析します。

LINES_TO_SKIP

解析のために無視し、事実上、コメントとして扱う初期行の数(ブランク行またはコメント行を除く)。デフォルトは0です。つまり、行をスキップしません。

CELL_DELIMITER

行の値を区切る正規表現のチルダ区切りリスト。デフォルトは空のリストです。つまり、デリミタはありません(デフォルトを使用することはまれです)。

QUOTE_DELIMITER

引用された値の開始および終了方法を定義する正規表現のチルダ区切りリスト(通常は一重引用符または二重引用符のいずれか)。開始および終了の引用符デリミタは同じである必要があります。デフォルトは空のリストです。つまり、パーサーは引用された値を認識しません。

PROPERTY_DELIMITER

プロパティの名前と値を区切る正規表現のチルダ区切りリスト。デフォルトは空のリストです。つまり、プロパティ・デリミタはありません。
まれに、構文a=bの名前と値のペアが列指向ファイルに含まれる場合があります。

RESERVED_DIRECTIVES

プロパティ・キーワードのチルダ区切りリスト。一部のcrontabファイルには、デリミタで区切られた単純な名前と値のペアが含まれます(foo=bar)。したがって、各行に同じ数のフィールドが含まれるという要件に違反します。このパラメータはプロパティ・キーワードを指定するための回避策を提供します。この例では、プロパティ・キーワードはfooになります。つまり実際は、ルート・コンテナ下にある解析対象属性の名前と値のペアとして、このキーワードで始まる行を解析します。デフォルトは空のリストです。つまり、プロパティ・キーワードはありません。

ALTERNATE_DELIMITER

プロパティの名前と値に対する代替デリミタ。デフォルトは'/'です(ALTERNATE_FIELDパラメータが空ではない場合のみ使用されます)。

ALTERNATE_FIELD

代替デリミタで区切られるフィールドのチルダ区切りリスト。デフォルトは空のリストです。つまり、代替デリミタはありません。

HEADER_FLAG

列名を示すヘッダー行がファイルに含まれるかどうかを指定するフラグ。デフォルトはfalseです。

HEADER

ヘッダー行がない場合に使用する列名のチルダ区切りリスト。デフォルトは空のリストです。つまり、列名はありません(デフォルトを使用することはまれです)。

ELEMENT_FIELD

行に関連付けられたコンテナの名前を作成する際にパーサーで連結される値を持つ、列名のチルダ区切りリスト。デフォルトは空のリストです。つまり、列名はありません(デフォルトを使用することはまれです)。

IGNORE_FIELD

無視する列名のチルダ区切りリスト。この列の値の解析は行われません。デフォルトは空のリストです。つまり、何も無視されません。

LAST_FREE_FORM

最後の列が自由形式かどうかを指定するフラグ。パーサーは自由形式の列値ですべてのデリミタを無視します。デフォルトはfalseです。

USE_LINE_COMMENT

データの解析対象の表現に表示される値として、行終了コメントを扱うかどうかを指定するフラグ。デフォルトはfalseです。

44.7.5 プロパティ・パーサーについて

プロパティ・パーサーは、フォーマットの調整のために受け入れ、異なる組織的な要素を処理できるパラメータによって、本質的に柔軟性があります。すべてのプロパティ・パーサーは、基本パラメータおよび拡張パラメータ、さらに拡張構成と同じパラメータ・セットを使用します。

パーサー

説明

AIXインストール済パッケージ

AIXインストール済パッケージ・ファイル用のパーサー。

Apache HTTPD

Apache HTTPD.confファイル用のパーサー。

Autosys

Autosys.jilファイル用のパーサー。

カスタムCFG

カスタム.cfgファイル用のパーサー。この構文はE = {}構文のある要素を定義します。ここで中カッコの中には名前と値のペア、ネストされた要素、あるいはその両方が含まれる場合があります。

Java Policy

java.policyファイル用のパーサー。

Javaプロパティ

java.propertiesファイル用のパーサー。

LDAP

LDAP .cfgファイル用のパーサー。

MIMEタイプ

mime.typesファイル用のパーサー。

Radia

Radia .cfgファイル用のパーサー。

セクション・プロパティ

セクションに編成されている名前と値のペアが含まれるファイル(Windowsの.iniファイルなど)用のパーサー。

SiteMinderエージェント

SiteMinderエージェント・ファイル用のパーサー。

SiteMinder Registry

SiteMinder .registryファイル用のパーサー。

SiteMinder Report

SiteMinder SmReport.txtファイル用のパーサー。

SmWalker

SiteMinder SmWalker.datファイル用のパーサー。

Sun ONE Magnus

Sun ONE magnus.confファイル用のパーサー。

Sun ONE Obj

Sun ONE obj.confファイル用のパーサー。

Tuxedo

Tuxedoファイル用のパーサー。

UNIX Config

UNIX etc/configファイル用のパーサー。

UNIX Login

UNIX etc/login.defsファイル用のパーサー。

UNIX PROFTPD

UNIX etc/proftpd.confファイル用のパーサー。

UNIX Resolve

UNIX etc/resolve.confファイル用のパーサー。

UNIX SSH Config

UNIX etc/ssh/sshd.confファイル用のパーサー。

UNIX System

UNIX etc/systemファイル用のパーサー。

UNIX VSFTPD

UNIX etc/vsftpd.confファイル用のパーサー。

UNIX XINETD

UNIX etc/xinetd.confファイル用のパーサー。

WebAgent

WebAgentファイル用のパーサー。

Windowsチェックサム

fciv.exeで生成されたWindowsチェックサム出力用のパーサー。

44.7.5.1 基本プロパティ・パーサーのパラメータ

この項では、シンプル・プロパティのデータ形式の解析に必要な、基本プロパティ・パーサーのパラメータについて説明します。シンプル・プロパティのデータ形式は、通常は名前と値を区切る定義済のデリミタによって、プロパティを名前と値のペアとして指定します: foo=bar。基本データ形式はプロパティのリストで、1行につき1つのプロパティがオプションのコメントとともにあります。例としてjava.propertiesファイルがあります。すべてのパラメータにはデフォルト値があり、これらは指定された値がないときに使用されます。

デリミタまたはその他の特殊なテキスト(コメント文字や新規行など)がある値の一部を表すときは、引用符を使用します。QUOTE_DELIMITERは使用する文字値を決定します。文字をエスケープする必要がある場合は、引用符デリミタの先頭にバックスラッシュ(\)を追加します。引用された文字列でバックスラッシュ文字そのものをエスケープするには、バックスラッシュを使用します(\\)。

ポンド記号(#)などのコメント文字や、特定の文字シーケンス(//)は通常、コメントを示します。Cスタイル・コメント(/*….*/)などの特殊なシーケンスは、コメントの開始および終了を示す場合があります。最初の数行に一般的な情報コンテンツが含まれるファイルもあります。この場合は、対象の行を無視するようにパーサーに伝えるパラメータを使用できます。

パラメータ

説明

COMMENT

コメントの文字またはシーケンスを示す正規表現のチルダ区切りリスト。たとえば、#[^\r\n]*は、行の上で#文字に続くすべてがコメントであることを指定します。デフォルトは空のリストです。つまり、すべてのファイル・コンテンツを解析します。

LINES_TO_SKIP

解析のために無視し、事実上、コメントとして扱う初期行の数(ブランク行またはコメント行を除く)。デフォルトは0です。つまり、行をスキップしません。

CELL_DELIMITER

行の値を区切る正規表現のチルダ区切りリスト。デフォルトは空のリストです。つまり、デリミタはありません(デフォルトを使用することはまれです)。

QUOTE_DELIMITER

引用された値の開始および終了方法を定義する正規表現のチルダ区切りリスト(通常は一重引用符または二重引用符のいずれか)。開始および終了の引用符デリミタは同じである必要があります。デフォルトは空のリストです。つまり、パーサーは引用された値を認識しません。

ALLOW_NAME_ONLY_PROPERTIES

デリミタまたは値のないプロパティ名をパーサーが許可するかどうかを示すフラグ。デフォルト: false。

REVERSE_PROPERTY

デリミタおよびプロパティ名の前に存在する値をパーサーが許可するかどうかを示すフラグ。デフォルト: false。

44.7.5.2 拡張プロパティ・パーサーのパラメータ

この項では、より複雑なプロパティのデータ形式の解析に必要な、拡張プロパティ・パーサーのパラメータについて説明します。すべてのパラメータにはデフォルト値があり、これらは指定された値がないときに使用されます。

パラメータ

説明

PROPERTY_DELIMITER

プロパティ・デリミタを表す正規表現のチルダ区切りリスト。たとえば、テキスト"a=b : x=y"は次の2通りに解釈できます。

- 値"b : x=y"を持つ"a"という1つのプロパティ

- "a=b"と"x=y"という2つのプロパティ

コロン(:)がプロパティ・デリミタの場合、解析エンジンはこのテキストを、2つのプロパティが含まれるテキストと解釈します。デフォルトは空のリストです。つまり、パーサーはプロパティ・デリミタを認識しません。

LINE_END_DELIMITER

行およびシーケンスを表す正規表現のチルダ区切りリスト。パーサーで行終了デリミタが検知されると、新規のプロパティまたは構造が次の行で開始するとみなされます。デフォルトは空のリストです。つまり、パーサーは行終了デリミタを認識しません。

CONTINUE_LINE

継続行シーケンスを表す正規表現のチルダ区切りリスト。パーサーで継続行パターンが検知されると、次の行のデータが、前の行の構造またはプロパティの続きとして解釈されます。これは、新規のプロパティまたは構造の開始として新規行が解釈される場合と対照的です。たとえば、複数の行に渡るプロパティ値をパーサーが認識するには、行継続パターンが検知される必要があります。デフォルトは空のリストです。つまり、パーサーは行継続パターンを認識しません。

SECTION_START

セクションの開始を表す正規表現のチルダ区切りリスト。セクションはネストできません。デフォルトは空のリストです。つまり、パーサーはセクションを認識しません。

SECTION_END

セクションの終了を表す正規表現のチルダ区切りリスト。デフォルトは空のリストです。

STRUCTURE_START

構造の開始を表す正規表現のチルダ区切りリスト。構造はネストできません。デフォルトは空のリストです。つまり、パーサーは構造を認識しません。

STRUCTURE_END

構造の終了を表す正規表現のチルダ区切りリスト。デフォルトは空のリストです。

XML_STYLE_TAG

ファイル内の構造がXMLスタイル・タグかどうかを示すフラグ。デフォルト: false。

USE_INI_SECTION

INIスタイル・セクションが存在するかどうかを示すフラグ。デフォルト: false。

RESERVED_DIRECTIVES

予約されたディレクティブの開始を示す予約名のチルダ区切りリスト。デフォルトは空のリストです。つまり、パーサーは予約されたディレクティブを認識しません。

RESERVED_FUNCTIONS

予約された関数の開始を示す予約名のチルダ区切りリスト。デフォルトは空のリストです。つまり、パーサーは予約された関数を認識しません。

DIRECTIVE_PROPERTIES

予約されたディレクティブ - 暗黙的なプロパティ名のチルダ区切りリスト。デフォルトは空のリストです。

FUNCTION_PROPERTIES

必須の予約された関数 - 明示的なプロパティ名のチルダ区切りリスト。デフォルトは空のリストです。

SECTION_PROPERTIES

セクション - 暗黙的なプロパティ名のチルダ区切りリスト。デフォルトは空のリストです。

STRUCTURE_PROPERTIES

構造 - 暗黙的なプロパティ名のチルダ区切りリスト。デフォルトは空のリストです。

ELEMENT_FIELD

プロパティの解析時にパーサーで無視されるキーワード。これは一般的に、名前と値のペアの前にキーワードを指定するデータ形式に適用されます。例として、"set a=b"があります。デフォルトは空のリストです。つまり、パーサーでは何も無視されません。

ALLOW_ELEMENT_CELL

ファイル形式が要素セル構造をサポートするかどうかを示すフラグ。デフォルト: false。

SECTION_EXPLICIT_PROPERTIES

セクションが明示的なプロパティをサポートするかどうかを示すフラグ。デフォルト: false。

STRUCTURE_EXPLICIT_PROPERTIES

構造が明示的なプロパティをサポートするかどうかを示すフラグ。デフォルト: false。

NEWLINE_CONTINUE_LIN

新規行が行継続シーケンスになるかどうかを示すフラグ。デフォルト: false。

KEYWORD_FIELD

空白デリミタを使用するプロパティの前にあるキーワードを表す、正規表現のチルダ区切りリスト。デフォルトは空のリストです。つまり、パーサーはキーワードを認識しません。

44.7.5.3 拡張プロパティ・パーサーの構成

プロパティ・ファイルは様々なファイル形式で表されます。幅広い範囲の形式に対応するため、汎用プロパティのベース・パーサーはほとんどのファイルで見つかる構成の組合せを使用します。

構成は2つのカテゴリに分類されます。

- コンテナ構成: 予約された関数、予約されたディレクティブ、XML構造、構造、区切られた構造、INIセクション、区切られたセクション、セクション、および要素セル

- プロパティ構成: シンプル・プロパティ、リバース・プロパティ、キーワード・プロパティ、キーワード名プロパティ、大カッコ・プロパティ、暗黙的なプロパティ、および明示的なプロパティ

要素構成の中で、セクション構成はネストできませんが、その他の構成を含むことはできます。構造構成はネストが可能で、セクション以外のその他の構成を含むことができます。要素セルはネストできますが、要素セルおよびシンプル・プロパティのみを含むことができます。予約されたディレクティブと予約された関数はネストすることも、その他の構成を含むこともできません。

この項では次に、基本プロパティ・パーサーがサポートする構成について説明します。

シンプル・プロパティ

シンプル・プロパティはプロパティ名、セル・デリミタ、プロパティ値および新規行シーケンスでこの順序どおりに構成されます。シンプル・プロパティは複数の行に渡る場合がありますが、複数の行に渡るプロパティには通常、行継続文字またはシーケンスが含まれます。空白に何か意味があるとパラメータで指定(例: セル・デリミタ)されていないかぎり、パーサーはタブやスペースなどの空白を無視します。

たとえば、name=value_that_wraps_to_next_line_/では、フォワードスラッシュが行継続文字として機能します。Javaプロパティ・ファイルがこのデータ形式の代表的な例です。

キーワード・プロパティ

この構成はシンプル・プロパティとほとんど同じで、キーワードが先頭にありますがこれはパーサーで無視されます。

たとえば、set name=valueでは、setが無視されるキーワードです。UNIXシステム・ファイルがこのデータ形式の代表的な例です。

キーワード名プロパティ

この構成は、プロパティ名がKEYWORD_FIELDパーサー・パラメータで指定される正規表現に一致する、シンプル・プロパティです。これはUNIX XINETDパーサーに固有の、特殊なケースのプロパティ・タイプです。XINETDファイルは等記号(=)をセル・デリミタとして使用します。ただし、プロパティがキーワード"include"または"includedir"で始まる場合は、セル・デリミタが空白となるので例外です。

特にXINETDファイルに対して追加されますが、適切な場合はその他のファイル・タイプにもプロパティを使用できます。

たとえば、includedir /etcでは、includedirがパーサー・パラメータの正規表現で、空白がセル・デリミタです。

明示的なプロパティ

明示的なプロパティはプロパティ名、デリミタおよびプロパティ値で構成されます。シンプル・プロパティまたはキーワード・プロパティと異なり、明示的なプロパティはセクションまたは構造などのコンテナ構成に制限されます。例として、XMLタグ属性があります。

例:

[SectionName p1=v1 p2=v2]

<StructureName p1=v1 p2=v2>
...
</StructureName>

これらの構成では、p1 v1とp2 v2の名前と値のペアが明示的なプロパティです。Sun ONE Objファイルがこのデータ形式の代表的な例です。

暗黙的なプロパティ

暗黙的なプロパティは、関連付けられたプロパティ名がないプロパティ値です。明示的なプロパティと同様に、暗黙的なプロパティはコンテナ構成(通常は予約されたディレクティブ)に制限されます。DIRECTIVE_PROPERTIESパーサー・パラメータには暗黙的なプロパティのプロパティ名が含まれます。

例:

[SectionName myName myPath]

<StructureName myName myPath>
...
</StructureName>

これらの構成で、DIRECTIVE_PROPERTIESパーサー・パラメータで宣言されたとおり、推定されたプロパティ名のnameおよびpathとともに、暗黙的なプロパティはmyNameおよびmyPathという値を持ちます。Apache HTTPDファイルがこのデータ形式の代表的な例です。

予約された関数

予約された関数は、明示的なプロパティが1つ以上後ろに続くキーワードです。RESERVED_FUNCTIONSパーサー・パラメータは、予約された関数を表すキーワードを指定します。

たとえば、Error fn="query-handler" type="forbidden"では、RESERVED_FUNCTIONSパーサー・パラメータで指定される予約された関数のキーワードはErrorです。Sun ONE Magnusファイルがこのデータ形式の代表的な例です。

予約されたディレクティブ

予約されたディレクティブは、暗黙的なプロパティが1つ以上後ろに続くキーワードです。RESERVED_DIRECTIVESパーサー・パラメータは、予約されたディレクティブを表すキーワードを指定します。

たとえば、LoadModule cgi_module "/bin/modules/std/cgi"では、RESERVED_DIRECTIVESパーサー・パラメータで指定される予約された関数のキーワードはLoadModuleです。Apache HTTPDファイルがこのデータ形式の代表的な例です。

XML構造

XML構造は標準的なXMLタグで、名前のみ、明示的なプロパティが後ろに続く名前、または暗黙的なプロパティが後ろに続く名前を含むことができます。

例:

<Name>
...
</Name>

<Name p1=v1 p2=v2>
...
</Name>
<Name "implicit_property1" "implicit_property2">
...
</Name>

WebAgentファイルがこのデータ形式の代表的な例です。

区切られた構造

区切られた構造は、次の要素で(指定された順序で)構成されます。

- 構造名

- デリミタ

- 開始構造文字または文字シーケンス

- 構造コンテンツ

- 終了構造文字または文字シーケンス

例:

StructureName = {
...
}

明示的および暗黙的なプロパティは使用できません。Javaポリシー・ファイルとCustom CFGファイルがこのデータ形式の代表的な例です。

構造

構造は、次の要素で(指定された順序で)構成されます。

- 構造名

- 開始構造文字または文字シーケンス

- 構造コンテンツ

- 終了構造文字または文字シーケンス

区切られた構造と構造の違いはデリミタのみです。つまり、構造では、構造名と開始構造インジケータの間にデリミタは不要です。

例:

StructureName {
...
}

明示的および暗黙的なプロパティは使用できません。UNIX XINETDファイルがこのデータ形式の代表的な例です。

INIセクション

INIセクションはWindows .iniファイルのセクション見出しに似ており、次のような特徴があります。

- セクション開始文字または文字シーケンス

- セクション名

- オプション(明示的および暗黙的)プロパティ

- セクション終了文字または文字シーケンス

例:

[SectionName]

[SectionName p1=v1 p2=v2]

[SectionName "implicit_property1" "implicit_ property2"]

SmWalkerファイルとセクション・プロパティ・ファイルがこのデータ形式の代表的な例です。

区切られたセクション

区切られたセクションは共通パターンで開始する行ですが、他の点ではシンプル・プロパティに似ています。

例:

HKEY_LOCAL_MACHINE\SOFTWARE\A\B\C=789

HKEY_LOCAL_MACHINE\SOFTWARE\X\Y\Z=123

これらは、共通パターンがHKEY_の、2つの区切られたセクション見出しです。SiteMinder RegistryファイルとLDAPファイルがこのデータ形式の代表的な例です。

要素セル

要素セルは、A = B = Cというフォームの、要素セル名とプロパティ名の名前と値のペアで構成されます。要素セルは通常、行継続シーケンスとネストを使用して構造を明確にします。複数のプロパティを持つ要素セルは、プロパティ・デリミタを使用してプロパティを区切ります。

例1:

EC = \
B = C, D = F

この例はECという名前の要素セルで、B = CとD = Fの2つのプロパティの名前と値のペアがカンマで区切られます。構造はバックスラッシュ文字(\)を使用して行継続を示します。拡張プロパティのパーサー・パラメータのPROPERTY_DELIMITERおよびCONTINUE_LINEは、個々のフォーマット文字を定義します。

例2:

EC = \
EC2 = \
A = B, \
C = D

この例はECという名前の要素セルで、EC2というネストされた要素セルを持ち、A = BとC = Dの2つのプロパティの名前と値のペアが含まれます。この例は同じデリミタと行継続文字を使用します。

44.7.6 解析されたファイルおよびルールの使用

収集された構成ファイルは、RAWフォームでRAW形式で格納され、パーサーが指定されている場合は、ノード、コンテナ、属性またはプロパティのツリー構造に格納されます。このファイルはまた、XPath条件および式で構成された解析後のルールを適用することを目的として内部的にXML形式でも生成されます。この内部形式には、XML以外のファイルも生成されます。この内部形式は、他のファイル・タイプにも対応する必要があるため、属性名および名前しかないJavaプロパティ・ファイルなどのファイルを償うためにXMLに別のルート・ノードを導入します。

次を参照すると、ファイルの解析および表示方法の例と解析後のルールの効果が明らかになります。

- XMLファイルの解析およびルール適用の例

- XML以外のファイルの解析およびルール適用の例

- SQL問合せの解析およびルール適用の例

44.7.6.1 XMLファイルの解析およびルール適用の例

次の簡単なXMLファイルについて検討してください。

<dir name="/a/b/c">
<file name="file1" size=120/>
<file name="file2" size=350/>
</dir>

デフォルトのXMLパーサーを使用して解析された形式が、ユーザー・インタフェースに次のツリー構造で表示されます。

dir
name    = /a/b/c
file
name = file1
size = 120
file
name = file2
size = 350

2つのコンテナの名前(file)が同じであるため、少なくともコンテナ・レベルでは2つを区別できません。このため、このファイルは解析後のルールの候補です。前述のとおり、ルールのXPath条件および式の適用対象である特別な内部XML形式があります。この形式では、ノードおよび属性がXML要素として処理され、属性値が対応する要素テキスト・コンテンツに変換されます。また、元のファイルに表示されないルート要素も追加されます。

<root>
<dir>
<name>/a/b/c</name>
<file>
<name>file1</name>
<size>120</size>
</file>
<file>
<name>file2</name>
<size>350</size>
</file>
</dir>
</root>

同じ名前のコンテナが2つある解析された形式の問題がある場合、ルール解決を次で構成することもできます。

条件: /root/dir/file
式: name/text()

この場合、事実上、ファイルごとにname/text()が評価され、dirノード内のファイルを区別する識別子を生成されます。

解析後のルールを適用した後、解析されたツリー構造は次のようになります。

dir
name = /a/b/c
file[file1]
name = file1
size = 120
file[file2]
name = file2
size = 350

ルールは、大カッコで囲まれてコンテナ名に追加された識別子に解決されます。この組合せ(file [file1]など)により、比較、検索、変更履歴などの様々な操作でファイル・コンテナを区別できます。

44.7.6.2 XML以外のファイルの解析およびルール適用の例

次の簡単なORAファイルについて検討してください。

acme=
(DESCRIPTION=
(SOURCE_ROUTE=yes)
(ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=1630))
(ADDRESS_LIST=
(FAILOVER=on)
(LOAD_BALANCE=off)
(ADDRESS=(PROTOCOL=tcp)(HOST=host2a)(PORT=1630))
(ADDRESS=(PROTOCOL=tcp)(HOST=host2b)(PORT=1630)))
(ADDRESS=(PROTOCOL=tcp)(HOST=host3)(PORT=1630))
(CONNECT_DATA=(SERVICE_NAME=Sales.us.acme.com)))

Oracle ORAパーサーを使用して解析された形式が、ユーザー・インタフェースに次のツリー構造で表示されます。

acme
DESCRIPTION
SOURCE_ROUTE    yes
ADDRESS
PROTOCOL         tcp
HOST             host1
PORT             1630
ADDRESS_LIST
FAILOVER         on
LOAD_BALANCE     off
ADDRESS
PROTOCOL          tcp
HOST              host2a
PORT              1630
ADDRESS
PROTOCOL          tcp
HOST              host2b
PORT              1630
ADDRESS
PROTOCOL         tcp
HOST             host3
PORT             1630
CONNECT_DATA
SERVICE_NAME     Sales.us.acme.com

スタンドアロンでもADDRESS_LIST内でも、アドレス・コンテナは区別できません。このため、このファイルは解析後のルールの候補です。前述のとおり、ルールのXPath条件および式の適用対象である特別な内部XML形式があります。この形式では、ノードおよび属性がXML要素として処理され、属性値が対応する要素テキスト・コンテンツに変換されます。また、元のファイルに表示されないルート要素も追加されます。

<root>
<acme>
<DESCRIPTION>
<SOURCE_ROUTE>yes</SOURCE_ROUTE>
<ADDRESS>
<PROTOCOL>tcp</PROTOCOL>
<HOST>host1</HOST>
<PORT>1630</PORT>
</ADDRESS>
<ADDRESS_LIST>
<FAILOVER>on</FAILOVER>
<LOAD_BALANCE>off</LOAD_BALANCE>
<ADDRESS>
<PROTOCOL>tcp</PROTOCOL>
<HOST>host2a</HOST>
<PORT>1630</PORT>
</ADDRESS>
<ADDRESS>
<PROTOCOL>tcp</PROTOCOL>
<HOST>host2b</HOST>
<PORT>1630</PORT>
</ADDRESS>
</ADDRESS_LIST>
<ADDRESS>
<PROTOCOL>tcp</PROTOCOL>
<HOST>host3</HOST>
<PORT>1630</PORT>
</ADDRESS>
<CONNECT_DATA>
<SERVICE_NAME>Sales.us.acme.com</SERVICE_NAME>
</CONNECT_DATA>
</DESCRIPTION>
</acme>
</root>

同じ名前のコンテナがある解析された形式の問題がある場合、ルール解決を次で構成することもできます。

条件: //ADDRESS
式:/HOST/text()

この場合、事実上、アドレス要素ごとに/HOST/text()が評価され、ホスト名がアドレス識別子として抽出されます。

解析後のルールを適用した後、解析されたツリー構造は次のようになります。

acme
DESCRIPTION
SOURCE_ROUTE    yes
ADDRESS[host1]
PROTOCOL         tcp
HOST             host1
PORT             1630
ADDRESS_LIST
FAILOVER         on
LOAD_BALANCE     off
ADDRESS[host2a]
PROTOCOL          tcp
HOST              host2a
PORT              1630
ADDRESS[host2b]
PROTOCOL          tcp
HOST              host2b
PORT              1630
ADDRESS[host3]
PROTOCOL         tcp
HOST             host3
PORT             1630
CONNECT_DATA
SERVICE_NAME     Sales.us.acme.com

ルールは、大カッコで囲まれてコンテナ名に追加された識別子に解決されます。この組合せ(ADDRESS [host2a]など)により、比較、検索、変更履歴などの様々な操作でアドレス・コンテナを区別できます。

44.7.6.3 SQL問合せの解析およびルール適用の例

次の3列のデータベース表SERVER_DETAILSについて検討してください。

SERVER_NAME

ENVIRONMENT

HOSTED_APPLICATIONS

webserver-100

QA

5

webserver-200

PERFORMANCE

6

webserver-500

PRODUCTION

3

構成拡張作成の一部として表されたSQL問合せは、次のとおりです。

select * from SERVER_DETAILS

この問合せでは、次のようなRAW出力が戻されます。

[row]
11_SERVER_NAME=13_ webserver-100
11_ENVIRONMENT=2_ QA
19_HOSTED_APPLICATIONS=1_5
[row]
11_SERVER_NAME=13_ webserver-200
11_ENVIRONMENT=11_ PERFORMANCE
19_HOSTED_APPLICATIONS=1_6
[row]
11_SERVER_NAME=13_ webserver-500
11_ENVIRONMENT=10_ PRODUCTION
19_HOSTED_APPLICATIONS=1_3

コンフィグレーション・ブラウザ・ソース・タブでも、データは同じようにレンダリングされます。

データベース問合せパーサーを使用して解析された形式が、ユーザー・インタフェースに次のツリー構造で表示されます。

row
SERVER_NAME=webserver-100
ENVIRONMENT=QA
HOSTED_APPLICATIONS=5
row
SERVER_NAME=webserver-200
ENVIRONMENT=PERFORMANCE
HOSTED_APPLICATIONS=6
row
SERVER_NAME=webserver-500
ENVIRONMENT=PRODUCTION
HOSTED_APPLICATIONS=3

rowコンテナは区別できません。このため、この問合せ結果は解析後のルールの候補です。前述のとおり、ルールのXPath条件および式の適用対象である特別な内部XML形式があります。この形式では、ノードおよび属性がXML要素として処理され、属性値が対応する要素テキスト・コンテンツに変換されます。また、元のファイルに表示されないルート要素も追加されます。

<root>
<row>
<SERVER_NAME>webserver-100</SERVER_NAME>
<ENVIRONMENT>QA</ENVIRONMENT>
<HOSTED_APPLICATIONS>5</HOSTED_APPLICATIONS>
</row>
<row>
<SERVER_NAME>webserver-200</SERVER_NAME>
<ENVIRONMENT>PERFORMANCE</ENVIRONMENT>
<HOSTED_APPLICATIONS>6</HOSTED_APPLICATIONS>
</row>
<row>
<SERVER_NAME>webserver-500</SERVER_NAME>
<ENVIRONMENT>PRODUCTION</ENVIRONMENT>
<HOSTED_APPLICATIONS>3</HOSTED_APPLICATIONS>
</row>
</root>

同じ名前のコンテナが3つある解析された形式の問題がある場合、ルール解決を次で構成することもできます。

条件: /root/row/SERVER_NAME
式: SERVER_NAME/text()

この場合、事実上、行ごとにSERVER_NAME/text()が評価され、ツリー構造内の行を区別する識別子が生成されます。

解析後のルールを適用した後、解析されたツリー構造は次のようになります。

row[webserver-100]
SERVER_NAME=webserver-100
ENVIRONMENT=QA
HOSTED_APPLICATIONS=5
row[webserver-200]
SERVER_NAME=webserver-200
ENVIRONMENT=PERFORMANCE
HOSTED_APPLICATIONS=6
row[webserver-500]
SERVER_NAME=webserver-500
ENVIRONMENT=PRODUCTION
HOSTED_APPLICATIONS=3

ルールは、大カッコで囲まれてコンテナ名に追加された識別子に解決されます。この組合せ(row[webserver-100]など)により、比較、検索、変更履歴などの様々な操作で行コンテナを区別できます。

44.8 クライアント構成の概要

クライアントとは、エンド・ユーザー、すなわち顧客のシステム(独自のITインフラストラクチャには含まれないシステム)を表します。クライアント構成とは、エンド・ユーザーのシステムに関して収集された構成データを表します。この構成は、Cloud Controlを使用して管理する内部デプロイメントとは異なります。

クライアント・システム・アナライザ(CSA)アプリケーションにより、Webサーバー管理者は、エンド・ユーザー・システムからのデータを収集および分析できます。クライアント・データは、アプレットにより収集され、診断されてCSAアプリケーションに戻されます。Cloud ControlにプレインストールされているCSAアプリケーションを使用することも、CSAをWebサーバーに単独でデプロイすることもできます。

クライアント構成にアクセスするには、「エンタープライズ」メニューから「構成」を選択し、「ホスト構成のリフレッシュ」を選択します。「ホスト構成のリフレッシュ」ページの「関連リンク」で、「クライアント構成」をクリックします。クライアント構成に関連するタスクの実行の詳細は、Cloud Controlオンライン・ヘルプを参照してください。

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

- Cloud Controlのクライアント・システム・アナライザについて

- クライアント・システム・アナライザの個別デプロイ

44.8.1 Cloud Controlのクライアント・システム・アナライザについて

プレインストールされたアプリケーションを使用すると、別個にWebサーバーを設定することなくクライアント・データを収集できます。管理エージェントは、クライアント・データの収集、分析およびそのデータの管理リポジトリへのアップロードを実行します。エンド・ユーザーは、Cloud Controlにアクセスするためのログイン資格証明が必要ありません。次のような使用例が想定されています。

- ヘルプ・デスクに連絡したエンド・ユーザーが、定義済のCSAページへ移動するように求められる場合があります。これにより、エンド・ユーザーのシステム情報がアップロードされます。テクニカル・サポートは、このシステム情報を確認してソリューションを提供できます。

- クライアントのアプリケーションでは、Cloud Controlアプリケーションのクライアント・システム・アナライザにシステム情報をアップロードするためのリンクを提供するように変更できます。このリンクは、クライアント・システム・アナライザを実行した後に戻るためのURLなど、特定の構成パラメータを指定できます。

- クライアントのアプリケーションでは、ログイン中またはアプリケーション内の他の時点にいるユーザーをCloud Controlのクライアント・システム・アナライザ・ページへリダイレクトするように変更できます。収集された情報は、Cloud Controlでクライアント・システムに関する様々な情報を得るために使用できます。例には、最も一般的なブラウザのバージョン、あるいは必要なオペレーティング・システム・パッチを適用していないシステムまたはRAMが不足しているシステムがあります。

CSAアプリケーションにアクセスするには、「エンタープライズ」メニューから「構成」を選択し、「ホスト構成のリフレッシュ」を選択します。「ホスト構成のリフレッシュ」ページの「関連リンク」で、「クライアント・システム・アナライザ」をクリックします。CSAアプリケーションの操作の詳細は、Cloud Controlオンライン・ヘルプを参照してください。

44.8.2 クライアント・システム・アナライザの個別デプロイ

CSAは、単独でJ2EE対応Webサーバーにデプロイできます。このデプロイメント計画は、次の場合に適切です。

- CSAにアクセスするクライアントが、たとえばファイアウォールが原因でCloud Controlのデプロイメントにアクセスできないかアクセスが制限される場合

- たとえば次のように、CSAアプリケーションをさらにカスタマイズする必要がある場合

- CSAアプリケーションにカスタム・ルールを提供して、システムが一定の制約を満たしているかどうかについてエンド・ユーザーがすぐにフィードバックするようにします。

- アプレットの動作を変更して、追加情報を収集するか、エンド・ユーザーに追加または別のインタフェースを提示するようにします。

- 管理サービスWebサーバーの負荷を削減する必要があります。

プレインストールおよびスタンドアロンの両タイプのデプロイメントでは、クライアント構成収集タグと呼ばれる構成可能な識別子がすべてのクライアント構成収集に割り当てられます。クライアント構成データがクライアント構成収集アプレットによって収集され、CSAアプリケーションによって指定されたWebサーバーのディレクトリに書き込まれた後、クライアント構成データを収集して管理リポジトリにアップロードするようCloud Controlを構成する必要があります。

クライアント構成の収集および表示の詳細は、Cloud Controlオンライン・ヘルプを参照してください。

44.9 関係の概要

関係は、ターゲット間(広義では管理対象エンティティ間)に存在するアソシエーションを定義します。一般に、関係はターゲット・タイプ定義に固有です。しかし、ターゲット・タイプの作成時にすべての関係を予測することはできません。このため、Cloud Controlで追加の関係の作成がサポートされます。新規関係の作成に使用できる方法は2つあります。

- 手動(汎用システム・ターゲットの追加による)

- インタラクティブ(構成トポロジ・ビューア内)

この項では、手動のプロセスについて説明します。構成トポロジ・ビューア内での関係の作成の詳細は、第44.10.14項を参照してください。

汎用システム・ウィザードにアクセスする方法は2つあります。

- 「設定」メニューから「ターゲットの追加」を選択し、「汎用システム」を選択します。

- 「ターゲット」メニューから 「システム」を選択し、「追加」ボタンをクリックします。

一般

汎用システムの全般的な詳細を指定します。

- ターゲットの意味のある名前を指定します。

- これが権限伝播システムかどうかを指定します。

- コスト・センターやライフサイクル・ステータスなどのシステム・プロパティを設定します。

- システム・メンバーを追加します。選択に論理的な相関性がある必要があります。

- メンバーの依存性を確認し、それを含めるかどうかを指定します。

- 適切なタイムゾーンを設定します(デフォルトはグリニッジ標準時)。

終了したら、「次へ」をクリックします。

アソシエーションの定義

システムに追加されているメンバーに基づいてCloud Controlで自動的に検出されたアソシエーション(関係)を表示するチェック・ボックスを選択します。次のようにしてアソシエーションを追加します。

1. 「追加」をクリックします。

2. 開くダイアログで、次のように入力します。

1. 左側の表でメンバー・ターゲットを選択します。これが右側の表に移入されます。

2. 右側の表で関連付けられているターゲットを選択します。これがアソシエーション・ドロップダウン・リストに移入されます。

3. 作成するアソシエーションを選択します。

4. 「OK」をクリックします。新規アソシエーションがアソシエーション表に表示されます。

3. 「追加」をクリックし、追加アソシエーションの作成を繰り返します。

終了したら、「次へ」をクリックします。

可用性の基準

このページを使用してシステムの主要なメンバー(システムが使用可能とみなされるために稼働している必要のあるメンバー)を宣言します。1つ、複数あるいはすべてのメンバーを選択できますが、少なくとも1つのメンバーを選択する必要があります。

終了したら、「次へ」をクリックします。

チャート

システム・チャート・ページでのチャートの表示方法をカスタマイズします。

- チャートを追加して提示されたチャートを補います。

- ニーズに合せて、提示されたチャートを編集します。

- 提示されたチャートのチェック・ボックスを選択解除し、ページ全体をカスタマイズします。

- 列や略称の追加や削除を行い、「メンバー」ページの外観を変更します。

終了したら、「次へ」をクリックします。

確認

汎用システム・ターゲットの構成を確認します。問題がなければ、「終了」をクリックします。

ターゲットが正常に作成されたことを確認したら、構成トポロジ・ビューアを使用して、作成した関係を確認し、走査します。

44.10 構成トポロジ・ビューアの概要

構成トポロジ・ビューアでは、複数ターゲット間の関係がビジュアルなレイアウトで示されます。

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

- 構成トポロジ・ビューアについて

- トポロジの使用例

- 構成トポロジの表示

- システム・コンポーネント構造の特定

- ターゲットの構成状態の一般ステータスの確認

- ターゲットの構成状態/コンプライアンス・スコアの取得

- 問題の分析と特定の問題の詳細表示

- 依存性分析について

- 影響分析について

- カスタム・トポロジ・ビューの作成

- カスタム・トポロジ・ビューの削除

- カスタム・トポロジ・ビューからの関係の除外

- カスタム・トポロジ・ビューにおけるターゲットへの関係の追加

- ターゲットへの関係の作成

- ターゲットからの関係の削除

- 構成トポロジ・グラフ上の情報の表示形式の制御

44.10.1 構成トポロジ・ビューアについて

構成トポロジ・ビューアでは、複数ターゲット間の関係がビジュアルなレイアウトで示されます。ターゲットのホームページから構成トポロジ・ビューアにアクセスするには、「構成」を選択し、動的ターゲットのメニューで「トポロジ」を選択します。現在のターゲットについて、トポロジ・グラフが表示されます。このビューアで、次の操作が可能です。

- ターゲットのヘルス問題の発生源を特定する、つまり失敗の原因と考えられるターゲットを検出します。たとえば、ホストが停止しているためにデータベースが停止しているなどです。

- ターゲットが他のターゲットに及ぼす影響を分析します。たとえば、給与および財務アプリケーションは、データベースが停止していると影響を受けます。

- システムのメンバーとその相互関係を表示し、システムの構造を判定します。

- ターゲット間に関係を追加します。この関係は、他のCloud Controlツールに反映されます。

- 自分が担当しているターゲットのみに焦点を当てられるように、構成トポロジ・ビューをカスタマイズします。

- 作成したカスタム・トポロジ・ビューを、他のCloud Controlユーザーと共有します。

44.10.2 トポロジの使用例

どのようなときにトポロジ機能を使用するか、その例を次に示します。

- システムのコンポーネント構造を特定します(第44.10.4項を参照してください)。

- 関係内の依存性を分析します(第44.10.8項を参照してください)。

- 関係内の影響を分析します(第44.10.9項を参照してください)。

44.10.3 構成トポロジの表示

構成トポロジ・ビューアでは、複数ターゲット間の関係がビジュアルなレイアウトで示されます。

表示しているトポロジがブラウザ・ウィンドウより大きい場合、次の方法により、ビューを調整できます。

- ウィンドウの右下にある小さい矢印アイコンをクリックしてナビゲータを起動します。これにより、トポロジのどの部分を表示するかを選択できます。

- 画面の左上にあるズーム・コントロールを使用して画面内のノードのサイズを小さくします。

次のステップを実行します。

1. 構成トポロジ・ビューアにアクセスします。
Cloud Controlホームページの「ターゲット」メニューから「すべてのターゲット」を選択します。表で、適切なターゲットをクリックします。メニューが表示されたら、動的ターゲット・メニューから「構成」、「トポロジ」の順に選択します。

2. 「ビュー」リストから、次のいずれかを選択します。

- 使用
このビューを使用すると、選択したターゲットが依存するターゲットを確認しやすくなります。ターゲットに問題がある場合、ターゲットが依存する別のターゲットに問題の原因があるかどうかを確認する上でこのビューが役に立ちます。

- 使用者
このビューには、選択したターゲットに依存するターゲットが表示されます。たとえば、ターゲットを停止し、その影響を受ける他のターゲットを確認する必要がある場合、このビューが役に立ちます。

- システム・メンバー
このビューには、システムのメンバーが表示されます(システム・ターゲットに対してのみ使用できます)。

- エンド・ユーザーによって定義され。共有されているカスタム・ビュー(他のユーザーが使用できるようにするには、カスタム・ビューを明示的に共有する必要があります)。

「使用」、「使用者」および「システム・メンバー」ビューは、即時利用可能なビューです。これらは変更できません。

3. 「トポロジ」ページでは、次の操作を行えます。

- カスタム・トポロジ・ビューの作成(第44.10.10項を参照)

- カスタム・トポロジ・ビューの削除(第44.10.11項を参照)

- カスタム・トポロジ・ビューからの関係の除外(第44.10.12項を参照)

- カスタム・トポロジ・ビューにおけるターゲットへの関係の追加(第44.10.13項を参照)

44.10.4 システム・コンポーネント構造の特定

ITシステムを構成しているコンポーネント(ターゲットとターゲット・コンポーネント)とその関係を特定するには、構成トポロジ・ビューアを使用します。

次のステップを実行します。

1. 構成トポロジ・ビューアにアクセスします。

2. 「ビュー」メニューで「システム・メンバー」を選択します(ターゲットがシステムの場合のみ使用できます)。ビューに、ターゲット間の関係が表示されます。デフォルトで表示されるビューは、ターゲット・タイプによって異なります。

2つのターゲット間の特定の関係を表示するには、これらの間のリンクの上にカーソルを置いて関係名をポップアップさせるか、「注釈」メニューから「リンク・ラベル」を選択してすべてのリンク上の関係名を表示します。

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

- トポロジ機能は、ターゲットのコンテキストにある場合は常に使用可能です。ターゲット・タイプ・メニューから「構成」、「トポロジ」の順に選択します。

- すべてのターゲット・タイプに構成データがあるわけではありません。構成データがないターゲット・タイプの場合、「構成」メニューおよびトポロジ・グラフは使用できません。

44.10.5 ターゲットの構成状態の一般ステータスの確認

トポロジを利用すると、システム・エンティティの関係やターゲットの構造、ターゲット・コンポーネントを表示してシステム状態を確認し、構成状態と構成のステータスを分析することかできます。

次のステップを実行します。

1. 構成トポロジ・ビューアにアクセスします。

2. 構成トポロジ・ビューア・ページで、ターゲットが停止中であるかがアイコンで示されます。特定のページ、たとえば「使用」や「使用者」などを選択できます。また、アイコンは、ターゲットにインシデントが関連付けられているかどうかも示します。

44.10.6 ターゲットの構成状態/コンプライアンス・スコアの取得

ターゲットの構成状態とコンプライアンス・スコアを特定するには、次の手順を実行します。

1. 構成トポロジ・ビューアにアクセスします。

2. 問題のあるターゲットにズームインします。問題が、問題のターゲット・ステータスを示すアイコン、ターゲット・インシデントを示すアイコンによって表されます。すべてのターゲット・ページで選択したタイプは常にハイライトされています。

3. ターゲットに上にコンソールを置いて、ポップアップ上の「詳細」リンクをクリックします。ターゲットのプロパティは、「一般」、「インシデント・サマリー」および「構成」タブに表示されます。「構成」タブには、ターゲット・コンプライアンス、過去1週間の構成の変更、および推奨パッチに関する情報が表示されます。これらの値からのリンクを使用すると、詳細なレポートにアクセスできます。
インシデントが「インシデント・サマリー」タブにレポートされている場合、レポートされているイベントおよびインシデントを解決します。コンプライアンス情報は「構成」タブで確認できます。ターゲットがコンプライアンスしていない場合、問題を解決します。また、パッチが適用されていない場合は、パッチを適用します。

4. すべてのターゲットが正常に機能するまで、各ターゲットの分析プロセスを繰り返します。

44.10.7 問題の分析と特定の問題の詳細表示

トポロジ・グラフをドリルダウンすると、問題の原因と考えられる特定の問題点を詳細に表示できます。

次のステップを実行します。

1. 構成トポロジ・ビューアにアクセスします。
Cloud Controlホームページの「ターゲット」メニューから「すべてのターゲット」を選択します。表で、適切なターゲットをクリックします。メニューが表示されたら、動的ターゲット・メニューから「構成」、「トポロジ」の順に選択します。

ターゲット・データを表示するには、ノードの上にカーソルを置いて「>>」の方向に移動し続けます。データが含まれるポップアップが表示されます。詳細は、「詳細」を参照してください。データに関連付けられたリンクを選択すると、詳細ページが表示されます。

2. 構成履歴の変更を表示します。
動的ターゲット・メニューから、「構成」、「履歴」の順に選択します。構成履歴ページで、過去24時間以内に履歴の変更があったかどうかを確認します。変更があった場合には、特定のターゲットについて変更の詳細を表示します。

3. コンプライアンスの違反、インシデント、却下の変更を表示します。

4. 特定のターゲットについて生成されたクリティカルまたは警告のインシデントを表示します。
「エンタープライズ」メニューから、「監視」、「インシデント・マネージャ」の順に選択します。

5. パッチに関する推奨事項があるかどうかを確認します。
トポロジ・ページで要素にカーソルを置き、ポップアップで「詳細」をクリックします。「構成」タブをクリックし、パッチ・アドバイザが対応されているかどうかを確認します。

44.10.8 依存性分析について

依存性分析(根本原因分析とも呼ばれる)では、上位から下位に関係を走査し、アイテムが依存するアセットでの問題を原因とする問題があるかとうかを調べます。

ターゲットの状態の問題の原因を見つけるには、次の手順を実行します。

1. 構成トポロジ・ビューアにアクセスします。

2. 「表示」リストで、「使用」を選択します。これにより、選択したターゲットが依存するターゲットのトポロジが表示されます。
問題の原因である可能性がある1つ以上のターゲットへのパスに色が付いています。

ターゲットが起動していない場合、問題の原因である可能性がある1つ以上のターゲットへのパスに色が付いています。赤色のリンクはユーザーのターゲットから停止中のターゲットへリンクしており、黄色のリンクはステータスが不明のターゲットにリンクしています。

デフォルトでは、トポロジには、ターゲット間の依存関係を含むツリーのすべての深さが含まれます。

44.10.9 影響分析について

影響分析では、ツリーの下位から上位へと関係を走査し、要素(ターゲットまたはシステム)に変更を加えた場合に問題が起こるかどうかを調べます。これによって、要素に変更を加えた場合に影響を受ける、要素に依存するアイテムは何かがわかります。たとえば、リスナーを停止したら、どのデータベースが影響を受けるか、などです。

次のステップを実行します。

1. 構成トポロジ・ビューアにアクセスします。

2. トポロジ・ページで、「使用者」ビューを分析します。トポロジには、選択したターゲットに依存するターゲットが表示されます。

44.10.10 カスタム・トポロジ・ビューの作成

特定のタスクやレポートなど、興味のあるターゲットのみを格納するカスタム・トポロジ・ビューを作成します。カスタム・ビューから、Cloud Controlによって提供される関係データを増補することもできます。

次のステップを実行します。

1. 構成トポロジ・ビューアにアクセスします。

2. 「カスタマイズ」メニューから、「カスタム・ビューの作成」を選択します。トポロジの名前および説明を指定し、初期コンテンツの1つを選択します。

- 現在のビューをコピー: 表示しているトポロジ・ビューと類似したトポロジ・ビューを作成します。

- 空のビューを作成: ルート・ノードから始まるトポロジ・ビューを作成します。

また、次のいずれかの公開オプションを選択します。

- 現在のターゲット・タイプのすべてのターゲットのカスタム・ビューを公開します。たとえば、データベース・ターゲットのトポロジ・ビューで作成している場合、新規ビューはすべてのデータベース・ターゲットに対して使用可能になります。

- 現在のターゲットに対してのみカスタム・ビューを公開します。

ビューを共有するには、「このカスタム・ビューを他のユーザーと共有」をクリックします。

「OK」をクリックします。

3. トポロジで不要な情報を非表示にするには、ターゲットをハイライトし、「カスタマイズ」メニューで「関係を非表示」を選択します。
ターゲットを選択することにより、表示されていない関係を表示することもできます。「カスタマイズ」メニューから、「ターゲット」、「ターゲット・タイプとの関係をさらに表示」の順に選択します。

特権ユーザーは、カスタム・ビューを他のユーザーと共有するよう選択することもできます。カスタム・ビューを共有するには、「このカスタム・ビューを他のユーザーと共有」というラベルのチェック・ボックスを選択します。

4. 「OK」をクリックします。

44.10.11 カスタム・トポロジ・ビューの削除

使用しなくなったカスタム・トポロジ・ビューは、「ビュー」リストが煩雑にならないように、削除します。注意: システム所有のビューは削除できません。

次のステップを実行します。

1. 構成トポロジ・ビューアにアクセスします。

2. 「ビュー」リストで、削除するトポロジ・ビューを選択します。

3. 「カスタマイズ」メニューから、「カスタム・ビューの削除」を選択します。

4. 確認ポップアップで「カスタム・ビューの削除」をクリックします。

44.10.12 カスタム・トポロジ・ビューからの関係の除外

トポロジ・ビューの作成後、カスタム・ビューに表示されているターゲットの一部を削除できます。システム既存のトポロジ・ビューである使用、使用者、システム・メンバーは変更できません。

次のステップを実行します。

1. 構成トポロジ・ビューアにアクセスします。

2. 「ビュー」リストで、変更するトポロジ・ビューを選択し、ターゲットを選択します。
注意: システム作成のビューは変更できません。

3. 「カスタマイズ」メニューから、「関係の非表示」を選択します。

4. グラフに表示されている関係のリストが関係の非表示ページに表示されます。グラフから除外する関係は複数選択できます。「OK」をクリックします。

44.10.13 カスタム・トポロジ・ビューにおけるターゲットへの関係の追加

トポロジ・ビューを作成した後、カスタム・ビューに関係を追加する必要がある場合があります。これにより、追加する関係を使用して現在表示中のターゲットに関連するターゲットがある場合、これらのターゲットがカスタム・ビューに追加されます。

次のステップを実行します。

1. 構成トポロジ・ビューアにアクセスします。

2. 「表示」リストから、所有しているか、変更の権限を持つカスタム・トポロジ・ビューを選択します。使用、使用者およびシステム・メンバーなどのシステム・ビューは変更できません。

3. トポロジを拡張するターゲットをハイライトします。「カスタマイズ」メニューから、「ターゲット」、「ターゲット・タイプとの関係をさらに表示」の順に選択します。

4. 表示されたダイアログに、選択したターゲット・タイプが参加できる関係のリストが表示されます。興味のある関係を選択し、「OK」をクリックします。選択した関係を使用して選択したターゲット・タイプに関連するターゲットがトポロジ・ビューに追加されます。

44.10.14 ターゲットへの関係の作成

Cloud Controlにあるシステムに関する情報が不完全である場合、ターゲット間の関係を作成できます。

注意: 新しい関係を作成すると、指定した関係を示しターゲットを含むトポロジに、自動的に新しい関係が表示されます。

次のステップを実行します。

1. 構成トポロジ・ビューアにアクセスします。

2. 「ビュー」リストで、変更するトポロジ・ビューを選択し、ターゲットを選択します。

3. 関係の一方の側にするトポロジ内のターゲットを選択します。

4. カスタム・ビューの作成ページで、名前および説明を指定し、初期コンテンツを選択し、このカスタム・ビューを公開する方法を決定します。「OK」をクリックします。

5. 「カスタマイズ」メニューから、「ターゲット」、「ターゲットとの関係を作成」の順に選択します。

6. ターゲットとの関係を作成ページで、関連付けられたターゲット、およびターゲット間の関係を選択します。リストには、このターゲット・タイプが参加できる関係のみが表示されます。互いにすべてのターゲット・タイプを関連付けることができるわけではありません。
注意: 作成した関係はビューからは独立しています。作成した関係は、Cloud Controlの他の箇所(システム・テンプレート、トポロジ・ビュー、構成比較など)で表示したり、使用できます。カスタム・ビューを削除しても、新規関係は削除されません。

7. 確認ページで、「作成」をクリックします。

関連付けられたターゲットがビューに追加されます。

44.10.15 ターゲットからの関係の削除

2つのターゲット間の関係を作成した場合、この関係がもはや存在していないことが判明することがあります。この変化を反映するには、必要に応じて不要な関係を削除します。一度削除した関係は、どのトポロジ・ビューにも表示されなくなります。

次のステップを実行します。

1. 構成トポロジ・ビューアにアクセスします。

2. 「表示」リストから、カスタム・ビューを選択します。

3. 削除する関係へのリンクを選択します。ノードを右クリックし、コンテキスト・メニューを表示して関係を削除するか、「カスタマイズ」メニューから「関係」、「関係の削除」の順に選択します。

4. 確認ページで、「削除」をクリックします。

関係は、システム・テンプレート、トポロジ・ビュー、構成比較などのCloud Control内の様々な場所で使用されます。このトポロジから関係を削除すると、これらの他の領域に影響する可能性があります。

関係を作成する場合、「関係の削除」メニュー項目を使用して後で関係を削除できます。

44.10.16 構成トポロジ・グラフ上の情報の表示形式の制御

カスタム・トポロジにターゲットが表示される形式を制御するには、ターゲット・タイプが表示される層をカスタマイズし、ターゲット・タイプをまとめることができます。

ターゲット・タイプが表示される層は、レイアウトが左右または上下のどちらであるかに応じて、トポロジ内の垂直配置または水平配置に影響します。

表示形式をカスタマイズするには、次の手順に従います。

1. 構成トポロジ・ビューアにアクセスします。

2. 既存のカスタム・ビューを作成または選択します。

3. 停止しているターゲットへの、ハイライトされたパスを制御するには、「「停止」の根本原因を強調表示」メニュー項目を切り替えます。
ルート・ターゲットが停止している場合にこのメニュー項目を選択すると、ルート・ノードから停止している他のターゲットへのパスがハイライトされます。ハイライトされたパスを目で追っていくと、どのターゲットがルート・ターゲットの停止ステータスの原因になっているかを特定できる場合があります。

注意:
このオプションを選択した場合、ノードをグループ化することはできません。

4. 層を操作するには、次のようにします。

1. 「カスタマイズ」メニューで、「層の選択」を選択します。

2. 「層の指定」または「デフォルト層の使用を選択します。層の指定を選択する場合、ターゲット・タイプを目的の層にドラッグします。

5. リンクの色付けの有効/無効を切り替えるには、「カスタマイズ」メニューで「「停止」の根本原因を強調表示」を選択します。

6. ターゲットをグループ化するには、次のようにします。

1. ソース・ターゲット・タイプとコピー先ターゲット・タイプ間の1つ以上のアソシエーションを表すリンクを選択します。

2. 「カスタマイズ」メニューで「関係」を選択し、「ターゲットのグループ化」を選択します(「ターゲットのグループ化」を選択する別の方法は、リンクを右クリックし、「ターゲットのグループ化」を選択することです)。
一致するすべてのアソシエーションがグループ・ボックスに配置されます。

注意:
「「停止」の根本原因を強調表示」を選択している場合、ターゲットのグループ化はできません。

45 コンプライアンスの管理

コンプライアンス管理では、構成、セキュリティおよび記憶域に関する企業のベスト・プラクティスについて、ターゲットおよびシステムのコンプライアンスを評価できます。これは、コンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールを定義、カスタマイズおよび管理することで実現します。また、コンプライアンス管理によって、ターゲットおよびシステムがコンプライアンスに対応するよう構成を変更する方法に関する情報が提供されます。

この章では、エンタープライズ内のアプリケーションが事前に確立されている規格に準拠していることをコンプライアンス管理で検証する方法、およびコンプライアンス構造の管理方法について説明します。この章の内容は次のとおりです。

- コンプライアンスの概要

- コンプライアンスの評価

- リアルタイム監視の調査

- コンプライアンス管理の構成

- リアルタイム監視ファセット

- 例

45.1 コンプライアンスの概要

コンプライアンス管理ソリューションでは、構成、セキュリティ、記憶域などに関する企業のベスト・プラクティスについて、ターゲットおよびシステムのコンプライアンスを評価できます。さらに、コンプライアンス管理は、コンプライアンスの評価に使用するエンティティを定義、カスタマイズおよび管理する機能を提供します。

コンプライアンス・ソリューションは次のとおりです。

- ターゲットとシステムは有効な構成設定がされているか、および構成関連の脆弱性にさらされていないかを自動的に判断します。

- ベスト・プラクティスに関するコンプライアンスにターゲットおよびシステムを提示するために構成を変更する方法をアドバイスします。

- Oracle Enterprise Manager Cloud Control (Cloud Control)ユーザーに構成の変更や非認証アクションが環境内のどこで行われているかを知らせるために、ターゲットのファイル、プロセスおよびユーザーをリアルタイムで監視します。

- コンプライアンス標準ルールにマップするために、Oracle提供のコンプライアンス・フレームワーク(Oracleの汎用コンプライアンス・フレームワークなど)およびコンプライアンス標準を提供します。このマッピングによって、コンプライアンスに従っていない設定およびアクションが組織で従うコンプライアンス・フレームワークにどのように影響を及ぼすかを視覚化できます。

- 部門オーナー、ITマネージャおよびコンプライアンス・マネージャが定期的に参照して組織のコンプライアンスの適用範囲を確認するのに適したIT構成および変更のビューをコンプライアンスに焦点を合せて提供します。

コンプライアンス機能の使用を開始する前に、理解しておく必要がある基本事項がいくつかあります。詳細は、次を参照してください。

- コンプライアンスで使用される用語

- コンプライアンス機能へのアクセス

- コンプライアンス機能の使用に必要なロールおよび権限

45.1.1 コンプライアンスで使用される用語

次の用語は、コンプライアンス機能について説明する際に、この章全体で使用されます。

- コンプライアンス・フレームワーク
コンプライアンス・フレームワークは、会社が業界におけるコンプライアンスを維持するために遵守する必要がある制御領域が編成されたリストです。Enterprise Managerでは、コンプライアンス・フレームワークをフォルダリング構造として使用することにより、標準およびルールをこれらが影響する制御領域にマップします。コンプライアンス・フレームワークは、これらの業界フレームワークを直接的に表現できるよう、階層的になっています。

1つのフレームワーク制御領域が1つ以上のコンプライアンス標準にマップされます。これらのコンプライアンス標準評価の結果、特定のフレームワーク領域のスコアが生成されます。

- コンプライアンス標準
コンプライアンス標準は、幅広く受け入れられたベスト・プラクティスに従うチェックまたはルールのコレクションです。それは、制御に従っているかどうかを判断するために、ITインフラストラクチャのセットに対してテストする必要があるコンプライアンス制御をCloud Controlによって表現したものです。これにより、ITインフラストラクチャ、アプリケーション、ビジネス・サービスおよびビジネス・プロセスが適切に編成、構成、管理および監視されていることを確認します。コンプライアンス標準の評価は、プラットフォーム互換性、類似の構成を持つ他のカスタマに影響する既知の問題、セキュリティ脆弱性、パッチ推奨などに関連する情報を提供します。また、コンプライアンス標準は、リアルタイム変更の監視を実行する場所を定義するためにも使用されます。

コンプライアンス標準は、1つ以上のコンプライアンス標準ルールにマップされ、評価が必要な1つ以上のターゲットに関連付けられます。

- コンプライアンス標準ルール
コンプライアンス標準ルールは、構成データの変更がコンプライアンスに影響するかどうかを決定するための特別なテストです。コンプライアンス標準ルールは、1つ以上のコンプライアンス標準にマップされます。

Cloud Controlには、次のタイプのコンプライアンス標準ルールがあります。

- リポジトリ・ルール
管理リポジトリのメトリック収集データに対してチェックを実行するために使用されます。

- WebLogic Server署名ルール
ベスト・プラクティスの構成をサポートするためにWebLogicターゲットのチェックに使用されます。

- リアルタイム監視ルール
変更が発生した際にファイル、プロセスおよびデータベース・エンティティへのアクションをリアルタイムで監視するために使用されます。ユーザーのログイン/ログアウトおよびSU/SUDOアクティビティの取得も行います。

- エージェント側のルール
エージェントで構成チェックを実行するために使用され、違反を管理リポジトリにアップロードします。

- 手動ルール
実行する必要があるが、自動化できないチェック。例: インストール、アップグレードおよびパッチをテストするための計画は、本番での実装前に記述し、遵守する必要があります。

- コンプライアンス標準ルール・フォルダ
コンプライアンス標準ルール・フォルダは、コンプライアンス標準ルールを含む階層構造です。

- 重要度
重要度は、コンプライアンス・フレームワーク、標準およびルールのマップ時に行うことができる設定です。重要度を使用して、そのフレームワーク制御領域またはコンプライアンス標準のコンプライアンス・スコアにコンプライアンス違反が及ぼす影響を計算します。

コンプライアンス・フレームワークの場合、コンプライアンス標準のマップ時におけるこのコンプライアンス標準の重要度は、このフレームワーク内の他のコンプライアンス標準に対する相対的な重要度を示します。

コンプライアンス標準の場合、コンプライアンス標準ルールのマップ時における重要度は、コンプライアンス標準内の他のすべてのコンプライアンス標準ルールに対するコンプライアンス標準ルールの相対的な重要度を示します。

- スコア
ターゲットのコンプライアンス標準に対するコンプライアンス・スコアは、ターゲットがコンプライアンス標準にどの程度準拠しているかを表すために使用されます。コンプライアンス・スコアは0%から100%(100%を含む)の範囲の数値です。コンプライアンス・スコアが100%の場合、ターゲットはコンプライアンス標準に完全にコンプライアンスしています。

- リアルタイム・ファセット
リアルタイム監視ルール定義には、指定したターゲット・タイプ、ターゲット・プロパティおよびエンティティ・タイプに対する監視で何が重要かを指定するファセットが含まれています。ファセットは、ターゲット・タイプの属性を構成するパターンの集合です。たとえば、オペレーティング・システムのネットワーク構成ファイルは、複数のファイル名またはファイル・パターンが含まれた1つのファセットによって定義できます。

- リアルタイム監視
監視は、ホストに表示されたアクションまたはリアルタイム監視ルールで監視対象として構成されたターゲットです。各ユーザー・アクションが1つの監視結果になります。

- 監視監査ステータス
監視にはすべて、監視が認証済または非認証またはそのどちらでもない(非監査)かを決定する監査ステータスがあります。監査ステータスは、手動で設定することも、リアルタイム監視コンプライアンス標準ルール構成を介して自動的に設定することもできます。

- 監視バンドル
単一の監視が管理エージェントからサーバーにレポートされることはありません。かわりに、これらは、同じターゲット、ルール、およびアクションの実行ユーザーに対して他の監視とともにバンドルされます。バンドルを使用すると、類似する監視を簡単にまとめることができるため、Cloud Controlで監視を管理しやすくなります。

45.1.2 コンプライアンス機能へのアクセス

コンプライアンス機能にアクセスするには、「エンタープライズ」メニューにナビゲートし、「コンプライアンス」を選択し、次のうちの1つを選択します。

- ダッシュボード
ダッシュボードには、ユーザーの組織または領域のコンプライアンスまたはリスクの度合いを示す結果が非常に詳しく表示されます。ダッシュボードには、選択したフレームワークのコンプライアンス・スコア、最も準拠していないシステムとターゲット、および検出された管理対象外ホストを表すダイアルがあります。

- 結果
コンプライアンス結果には、コンプライアンス・フレームワーク、コンプライアンス標準およびターゲット・コンプライアンスの評価結果およびエラーが含まれます。

- ライブラリ
「コンプライアンス・ライブラリ」ページには、標準を定義するのに使用されるエンティティが含まれています。コンプライアンス・ライブラリ・ページでは、コンプライアンス・フレームワーク、コンプライアンス標準、コンプライアンス標準ルールおよびリアルタイム監視ファセットを操作できます。

注意: リアルタイム監視ファセットは、リアルタイム監視ルール専用です。

- リアルタイム監視
監視は、ホストに表示されたアクションまたはリアルタイム監視ルールで監視対象として構成されたターゲットです。各ユーザー・アクションが1つの監視結果になります。同じリアルタイム監視ルールに対して同じターゲットの同じユーザーが短い期間に複数の監視を実行する場合、監視が追加でバンドルされます。監視対象のアクションを分析するために複数のUIベース・レポートが用意されています。

45.1.3 コンプライアンス機能の使用に必要なロールおよび権限

コンプライアンス標準機能を使用するには、次のロールおよび権限へのアクセス権限を持っている必要があります。

ロール

説明

含まれる権限

EM_COMPLIANCE_DESIGNER

コンプライアンス・フレームワーク、コンプライアンス標準、コンプライアンス標準ルールおよびリアルタイム監視ファセットを作成、変更および削除できます。

ターゲット権限:

- 任意のターゲット・コンプライアンスの管理

- 任意のターゲット・メトリックの管理

- 任意のターゲットの表示

リソース権限:

- コンプライアンス・フレームワーク(コンプライアンス・エンティティの作成、完全な任意のコンプライアンス・エンティティ)

- 構成拡張(任意のユーザーにより所有されている構成拡張の管理)

- ジョブ・システム(作成)

EM_COMPLIANCE_OFFICER

コンプライアンス・フレームワーク定義および結果を表示できます。

ターゲット権限なし
リソース権限

- コンプライアンス・フレームワーク(任意のコンプライアンス・フレームワークの表示)

コンプライアンスで使用されるターゲット権限およびリソース権限には、次が含まれます。

権限

権限のタイプ

含まれるロール

説明

任意のターゲット・コンプライアンスの管理

ターゲット

EM_COMPLIANCE_DESIGNER

コンプライアンス標準のターゲットへの関連付けを含めて、任意のターゲットのコンプライアンスを管理できます。

任意のターゲット・メトリックの管理

ターゲット

EM_COMPLIANCE_DESIGNER

任意のターゲットのメトリックを管理できます。

任意のターゲットの表示

ターゲット

EM_COMPLIANCE_DESIGNER

Enterprise Managerでのすべての管理対象ターゲットを表示できます。

任意のコンプライアンス・フレームワークの表示

ターゲット

EM_COMPLIANCE_OFFICER
EM_COMPLIANCE_DESIGNER

コンプライアンス・フレームワーク定義および結果を表示できます。
注意: この権限は、コンプライアンス・フレームワーク・リソース権限に含まれます。この権限はEM_COMPLIANCE_OFFICERロールに対してはデフォルトで付与されますが、EM_COMPLIANCE_DESIGNERロールに対してはデフォルトで付与されません。

コンプライアンス・エンティティの作成

リソース

EM_COMPLIANCE_DESIGNER

コンプライアンス・フレームワーク、コンプライアンス標準、コンプライアンス標準ルールおよびリアルタイム監視ファセットを作成できます。
この権限は、コンプライアンス・フレームワーク・リソース権限に含まれます。

完全な任意のコンプライアンス・エンティティ

リソース

EM_COMPLIANCE_DESIGNER

コンプライアンス・フレームワーク、コンプライアンス標準、コンプライアンス標準ルールおよびリアルタイム監視ファセットを編集および削除できます。
この権限は、コンプライアンス・フレームワーク・リソース権限に含まれます。

コンプライアンス・フレームワーク

リソース

EM_COMPLIANCE_DESIGNER
EM_COMPLIANCE_OFFICER

コンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールの定義、カスタマイズおよび管理を行うことができます。また、ターゲットおよびシステムが、構成、セキュリティおよび記憶域などの観点から企業のベスト・プラクティスに準拠しているかどうかを評価できます。
この権限には、次の権限があります。

- コンプライアンス・エンティティの作成(EM_COMPLIANCE_DESIGNERロールではデフォルトで付与されます)

- 完全な任意のコンプライアンス・エンティティ(EM_COMPLIANCE_DESIGNERロールではデフォルトで付与されます)

- 任意のコンプライアンス・フレームワークの表示(EM_COMPLIANCE_OFFICERロールではデフォルトで付与されます)

構成拡張

リソース

EM_COMPLIANCE_DESIGNER

ターゲット構成収集を拡張できます。
この権限には、次の権限があります。

- 任意のユーザーが所有する構成拡張の管理(デフォルトで付与されます)

- ユーザーが所有する構成拡張の管理

ジョブ・システム

リソース

EM_COMPLIANCE_DESIGNER

ジョブは、通常実行されるタスクの自動化が管理者によって定義される、スケジュール可能な作業単位です。
この権限には、次の権限があります。

- 作成(デフォルトで付与されます)

- 表示アクセス権の管理

次の表には、コンプライアンス・タスクとそれに必要なロールおよび権限がリストされています。

タスク

必要なロールおよび権限

コンプライアンス・フレームワークの作成

コンプライアンス・エンティティの作成権限
任意のコンプライアンス・フレームワークの表示権限

コンプライアンス・フレームワークの編集および削除

完全な任意のコンプライアンス・エンティティ権限
任意のコンプライアンス・フレームワークの表示権限

コンプライアンス・フレームワークの作成、編集および削除

EM_COMPLIANCE_DESIGNERロール
EM_COMPLIANCE_OFFICERロール

コンプライアンス標準のターゲットへの関連付け

任意のターゲット・コンプライアンスの管理権限
または

ターゲットに対するMANAGE_TARGET_COMPLIANCE権限

コンプライアンス・フレームワークのインポートまたはエクスポート

EM_COMPLIANCE_DESIGNERロール
EM_COMPLIANCE_OFFICERロール

リアルタイム監視ルールの作成

EM_COMPLIANCE_DESIGNERロール

リアルタイム監視ファセットの作成

EM_COMPLIANCE_DESIGNERロール

注意: コンプライアンス標準と関連付けるターゲットへのアクセス権限も持っていることを確認してください。特に、ターゲットに対する任意のターゲット・コンプライアンスの管理権限が必要です。

45.2 コンプライアンスの評価

コンプライアンス評価とは、コンプライアンス標準にマップされたコンプライアンス標準ルールをターゲットに対してテストし、管理リポジトリに違反を記録するプロセスです。

コンプライアンス標準に対してターゲットを評価することによって、ターゲットが標準のチェックに準拠しているかどうかを判別します。ターゲットが所定の状態を満たしていない場合、そのターゲットを準拠させるのに必要な変更事項をテストで提案します。

コンプライアンス評価によって、ターゲットがどの程度標準に準拠しているかに基づいてターゲットのスコアが生成されます。100%のコンプライアンス・スコアとは、ターゲットがコンプライアンス標準のすべてのチェックに合格したことを意味します。リアルタイム監視の場合、手動または変更リクエスト管理統合を介して非認証とマークされた監視があると、コンプライアンス・スコアは下がります。これらの非認証監視がクリアされるか認証済に変更されると、スコアは向上します。

ターゲット・コンプライアンスを定期的に監視する必要があるため、コンプライアンス標準をターゲットに関連付ける必要があります。ターゲットの状態がリフレッシュする、つまり、ターゲットから新規データが収集されると、関連するターゲットに対して評価が自動的に実行されます。リポジトリ・ルールの場合、ターゲットの新規データが管理リポジトリにロードされると、評価が再度行われます。リアルタイム監視の場合、ユーザー・アクションの監視が行われるたびに評価が行われます。

コンプライアンスを保証するために実行可能な操作

Cloud Controlを使用してコンプライアンスを評価する場合、次のアクションを定期的に実行する必要があります。

- 組織のコンプライアンス・スコアが低いか組織が危険な状態にあることを示す可能性がある領域を検出するためのコンプライアンス・ダッシュボードの定期的監視

- 評価の結果の表示
評価結果を検討し、ターゲットに必要な変更を行います。

表示権限のあるターゲットの結果のみを表示できます。コンプライアンス標準ルールの評価結果は、コンプライアンス標準の評価状態とコンプライアンス・サマリーを生成するためにロールアップされます。

- Oracle提供のレポートの確認
リアルタイム監視UIレポートを定期的に監視し、検出した監視が正常か異常かを確認します。非認証の変更を元に戻せるようになるまで、または監査者が求めるレベルまでアクションを調査できるまでは、異常のある監視を非認証に設定します。

- 評価結果としての傾向の概要の検討
傾向の概要ページのグラフを使用して、ターゲットがコンプライアンス標準に準拠する傾向にあるのか、コンプライアンスのベスト・プラクティスから遠ざかる傾向にあるのかを視覚的に判断します。

コンプライアンス標準の「傾向の概要」ページにアクセスするには、次の手順を実行します。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. 「コンプライアンス標準」タブから「評価結果」を選択します。

3. 評価結果ページで、調査するコンプライアンス標準を選択し、「詳細を表示」をクリックします。

4. 結果の詳細ページで、「傾向の概要」タブをクリックします。

注意: コンプライアンス・フレームワークの「傾向の概要」ページをレビューすることもできます。

- 構成比較機能の上位でルールを作成することで、環境がベースライン(または相互)に一致していることを確認してください。リアルタイム監視を使用して、構成の変動を監視します。

- 構成設定の妥当性の評価

- 構成関連の脆弱性の存在、記憶域およびセキュリティの評価

- 準拠するターゲットおよびシステムの変更

- 構成変更またはユーザー・アクションの認証の検証

- システム、サービスおよびターゲットを継続的にテストして、システムを最大限に保護し、最高のパフォーマンスを実現します。

- Oracle提供のコンプライアンス標準およびコンプライアンス標準ルールを使用して、コンプライアンスを判断します。ここをクリックすると、この機能のデモが表示されます。

- 使用環境内でコンプライアンスについて監視されていないホストは、使用環境に多大なコンプライアンス・リスクをもたらすため、これらを監視します。

次の各項では、その他の詳細について説明します。

- コンプライアンス統計へのアクセス

- コンプライアンス・サマリー情報の表示

- ターゲット・コンプライアンス評価結果の表示

- コンプライアンス・フレームワークの評価結果の表示

- 違反の管理

- コンプライアンス違反および評価結果の調査

- 評価エラーの調査

- コンプライアンス・レポートの分析

- コンプライアンス・スコアおよび重要度の概要

45.2.1 コンプライアンス統計へのアクセス

コンプライアンス統計は、コンプライアンス・ダッシュボード、「エンタープライズ・サマリー」ページ、およびターゲットのホームページなどのページにある「コンプライアンス・サマリー」リージョンのインタフェース全体で使用できます。

これらのリージョンでは、特定のターゲットの違反およびコンプライアンス・スコアを報告します。ただし、リージョンでは違反があることのみ報告され、詳細は表示されません。たとえば、「ホストのセキュアな構成」コンプライアンス標準の一部である「セキュア・ポート」コンプライアンス標準ルールに対して違反があるとします。しかし、「コンプライアンス・サマリー」リージョンを参照しているだけでは、詳細はわかりません。

45.2.1.1 コンプライアンス・ダッシュボードの効率的な使用

コンプライアンス・ダッシュボードはCloud Controlコンプライアンス機能の最上位レベルのビューです。ダッシュボードにはいくつかのリージョンがあり、これによりIT環境のコンプライアンスが定義済の標準に従っている状況を非常によく把握できます。

コンプライアンス・ダッシュボードへのアクセスの手順:

1. 「エンタープライズ」メニューから「コンプライアンス」を選択します。

2. 「ダッシュボード」を選択します。

コンプライアンス・ダッシュボードは、ホームの選択ページから選択できるページの1つでもあり、Cloud Controlにログインするときにホームページとして設定することもできます。

コンプライアンス・ダッシュボードには、次のリージョンがあります。

- コンプライアンス・フレームワーク・サマリー
このリージョンで、ユーザーは1つのコンプライアンス・フレームワークを選択し、そのコンプライアンス・フレームワークの下の第2レベルの各フォルダに対するコンプライアンス・スコアを表示します。ダイアル上の針は、指定されたフレームワーク要素に関する現在のコンプライアンスのスコアを示しています。このスコアは、Enterprise Managerのログイン・ユーザーが表示できるターゲットに基づいています。

このダイアルをクリックすると、指定した第2レベルのフレームワーク・フォルダの「コンプライアンス結果」ページに移動し、次のフレームワーク・フォルダまたはこのフォルダに属しているコンプライアンス標準(またはその両方)のより詳細な情報が提供されます。

- コンプライアンス・サマリー
このリージョンにはフレームワークのビューと標準のビューがあります。「フレームワーク」ビューのこのリージョンには、すべての定義済のコンプライアンス・フレームワークとその全体のスコアおよび違反の詳細のリストが示されます。「標準」ビューのこのリージョンには、最も低いスコアのコンプライアンス標準がその違反の詳細とともにリストされます。フレームワークまたは標準の名前をクリックすると、そのフレームワークまたは標準のより詳細な情報を示す画面に移動します。

このリージョンから、「傾向の表示」リンクをクリックし、コンプライアンス・スコアの履歴の傾向のグラフを表示することもできます。

- 最少コンプライアンス汎用システム
このリージョンには、最小のコンプライアンス・スコアの汎用システムが示されます。指定したシステムのスコアは、そのシステムのすべての要素に関連付けられたすべてのルールを含むことで計算されます。汎用システムは、HRISやPayrollなどのITビジネス・アプリケーションを定義するために使用します。スコアが最低であるシステムをレポートすることにより、監査時間の原因となるコンプライアンス・リスクがあるビジネス単位を特定しやすくなります。

- 最新の検出済管理対象外ホスト
このリージョンには、Cloud Control自動ホスト検出機能を使用して最近検出された、管理対象ホストに昇格されなかったホストが示されます。T環境内の管理対象外ホストは多くのアクセス制御およびデータ・アクセスのリスクの原因となる可能性があるので、これらのホストは特定のコンプライアンス・リスクを表しています。このリージョンの目的は、最近検出され、コンプライアンス制御下にない可能性のあるホストを強調することです。

- 最少コンプライアンス・ターゲット
このリージョンは「最少コンプライアンス汎用システム」と類似していますが、すべてのターゲットを示す(汎用システムを再度含む)点が異なります。このリージョンは、どの個別のターゲットが使用されているかが明確でない場合があるので、IT管理または監査者の視点からは、あまり役に立ちません。しかし、ITコンプライアンス監査の増加につながる最もリスクの高い領域を探す別のデータ・ポイントとして使用できます。

45.2.2 コンプライアンス・サマリー情報の表示

コンプライアンス・サマリー情報は、Cloud Controlの「コンプライアンス結果」ページおよび個々のターゲット・ホームページから使用できます。

「Cloud Control」ホームページからコンプライアンス・サマリー情報を表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

ターゲットのホームページからコンプライアンス・サマリー情報を表示するには、次の手順に従います。

1. 「ターゲット」メニューから、ターゲット・タイプを選択し、ターゲットをクリックします。

2. ターゲットのホームページで、「コンプライアンス標準サマリー」リージョンにスクロール・ダウンします。

ターゲットのホームページの「ターゲット」メニューからコンプライアンス・サマリー情報を表示するには、次の手順に従います。

1. 「ターゲット」メニューから、ターゲット・タイプを選択し、ターゲットをクリックします。

2. ターゲットのホームページで、ページの左上にある「ターゲット」メニューをクリックします。

3. 「コンプライアンス」を選択し、「結果」を選択します。「結果」ページで、「ターゲット・コンプライアンス」をクリックします。

45.2.3 ターゲット・コンプライアンス評価結果の表示

ターゲット固有のコンプライアンス評価結果は、Cloud Controlホームページおよび個々のターゲット・ホームページによって使用できます。コンプライアンスのルールおよび標準を評価することによって得られる評価結果は、次のとおりです。

評価結果

説明

コンプライアンス

ターゲットは目的の状態にあり、非認証のリアルタイム監視はありません。

非コンプライアンス

ターゲットが所定の状態にありません。コンプライアンス標準の少なくとも1回のテストによって目的の状態からの逸脱が検出されたか、非認証のリアルタイム監視が少なくとも1つあります。

エラー

エラーにより結果が返されませんでした。エラーは、予期しない内部エラーまたはテスト中のエラーです。テスト中にエラーが発生するのは、次のような処理を試行した場合です。

- ゼロ除算

- 誤ったパラメータ値による関数の起動

「Cloud Control」ホームページを使用して結果を表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. 「ターゲット・コンプライアンス」タブをクリックします。ターゲット結果ページに、ターゲットが平均コンプライアンス・スコアとともに表示されます。

ターゲットのホームページからコンプライアンス評価結果を表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから、「ターゲット」を選択し、ターゲット・タイプを選択します。

2. 目的とするターゲットの名前をクリックします。

3. ターゲットのホームページで、「コンプライアンス標準サマリー」リージョンにスクロールします。

ページまたはリージョンを使用して、一定期間におけるターゲットのコンプライアンスを概観します。表およびグラフを使用して、進行中の傾向および変化を簡単に監視できます。

注意: コンプライアンス標準からターゲットへの初回アソシエーション後に傾向概要データが時系列グラフに表示されるまでに最大6時間かかる可能性があります。

45.2.4 コンプライアンス・フレームワークの評価結果の表示

コンプライアンス・フレームワークを効率的に使用するには、組織内で使用するコンプライアンス・フレームワークの制御領域を反映するように、フレームワークを編成します。フレームワークの階層構造は、使用するフレームワークの制御領域に直接マップする必要があります。

Oracleは、Oracleの汎用コンプライアンス・フレームワーク、Fusion Applicationsコンプライアンスおよびセキュリティ技術導入ガイド(STIG)など、多くのフレームワークを提供します。これらのフレームワークは、ニーズに応じて独自のフレームワークを作成する際の起点にしたり、内部標準やSOX、HIPAA、NIST-800または他の一般的なフレームワークに基づいて独自のフレームワークを最も効率的に編成する方法について理解するために使用できます。

コンプライアンス・フレームワーク評価の結果を表示するには、「コンプライアンス・フレームワーク」タブからアクセスする「評価結果」ページを使用します。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. 「コンプライアンス結果」ページで、「コンプライアンス・フレームワーク」タブをクリックし、対象のコンプライアンス・フレームワークをハイライトします。

コンプライアンス・フレームワークは階層構造であるため、フレームワークの各フォルダまたはノードには独自のスコアがあります。階層の最下位の子のスコアは親フォルダなどにまとめられます。これらのレポートを参照するユーザーが、使用するフレームワークの1つの制御領域に主に興味がある場合、フレームワークの下で参照するフォルダによって表される特定の制御領域のスコアに焦点を当てることができます。

45.2.5 違反の管理

コンプライアンス結果機能を使用することにより、違反の抑止と抑止解除および手動違反のクリアを行うことができます。

違反を抑止すると、コンプライアンス・スコア計算から違反を削除するときに、既存の違反を確認できます。違反を抑止することにより、違反リストから違反を削除することなく、違反がコンプライアンス・スコアに悪影響を及ぼさないようにすることができます。抑止は、無期限に有効にすることも、特定期間だけ有効にすることもできます。

違反の抑止を解除すると、コンプライアンス・スコアが、抑止解除された違反を考慮して再計算されます。

手動ルール違反をクリアすると、違反がクリアされます。また、コンプライアンス・スコアが対応するコンプライアンス標準またはターゲットに対して上昇します。手動ルール違反のクリアは、無期限に有効にすることも、特定期間だけ有効にすることもできます。

違反管理機能へのアクセス

違反管理機能にアクセスするには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. コンプライアンス標準をハイライト表示し、「違反の管理」をクリックします。

次のタブがあります。

- 抑止解除された違反

- 抑止された違反

- 手動ルール違反

「抑止解除された違反」タブ

このタブを使用して、違反を抑止します。

1. 1つ以上の違反を選択します。

2. 「違反の抑止」をクリックします。

3. 「違反の抑止の確認」ポップアップで、違反を無期限に抑止することを選択するか、または抑止の終了日を指定できます。オプションで、抑止の説明を入力できます。

4. 「OK」をクリックします。

これで、抑止を非同期に行うジョブが発行され、結果ライブラリページが再表示されます。抑止を有効にすると、違反が抑止されたこととその理由(理由が入力されている場合)を示す注釈が、基礎となるイベントに追加されます。注意: ジョブの効果はすぐには現われません。効果が現われるまでに数分かかることがあります。

「抑止された違反」タブ

このタブを使用して、違反の抑止を解除します。

1. 1つ以上の違反を選択します。

2. 「違反の抑止解除」をクリックします。

3. 「違反の抑止解除の確認」ポップアップで、抑止を解除する理由を入力できます。

4. 「OK」をクリックします。

これで、抑止の解除を非同期に行うジョブが発行され、結果ライブラリに戻ります。抑止を解除すると、違反の抑止が解除されたこととその理由(理由が入力されている場合)を示す注釈が、基礎となるイベントに追加されます。注意: ジョブの効果はすぐには現われません。効果が現われるまでに数分かかることがあります。

「手動ルール違反」タブ

手動ルール違反をクリアするには、次の手順に従います。

1. 1つ以上の手動ルール違反を選択します。

2. 「違反のクリア」をクリックします。

3. 「違反のクリアの確認」ポップアップで、違反を無期限にクリアすることを選択するか、またはクリアの終了日を指定できます。オプションで、クリアの説明を入力できます。

4. 「OK」をクリックします。

これで、手動ルール違反を非同期にクリアするジョブが発行され、結果ライブラリページが再表示されます。手動ルール違反をクリアすると、基礎となる違反イベントもクリアされます。注意: ジョブの効果はすぐには現われません。効果が現われるまでに数分かかることがあります。

45.2.6 コンプライアンス違反および評価結果の調査

ここでは、コンプライアンス違反の調査に関するいくつかの提案事項を示します。最もクリティカルな違反やITエンタープライズのコンプライアンス全体に対する影響が最も大きい違反に注意してください。

- コンプライアンス・ダッシュボードでスコアの最も低いシステムおよびターゲットとともにコンプライアンス・フレームワークのスコアを監視します。

- 最近検出されたホストがCloud Controlを使用してコンプライアンス・リスクについて監視されているかITコンプライアンスに潜在的なリスクをもたらしていないかを確認します。

- 「エンタープライズ・サマリー」ホームページ上の統計を検討します。特に、「コンプライアンス・サマリー」リージョン内の統計を参照します。重大度が「クリティカル」であるコンプライアンス違反を最初に処理する必要があります。

- コンプライアンス・スコアの最も低い汎用システム(ITビジネス・アプリケーション)およびターゲットに対処します。

- 特定のターゲットのコンプライアンス違反については、そのターゲットのホームページを調査してください。「コンプライアンス標準サマリー」リージョンには概要情報が示されていますが、そのターゲットの傾向にもアクセスできます。

- Cloud Controlのインシデント管理領域でコンプライアンス違反関連のイベントを確認します。

- 特定のコンプライアンス標準の「結果」ページにナビゲートします。ナビゲーション・ツリーで、コンプライアンス標準の名前をクリックすると、サマリー・ページに、すべてのターゲットが違反の数とともにリストされます。

- 「傾向の概要」ページにナビゲートすると、評価されたターゲット数、ターゲットごとの平均違反数、コンプライアンス・スコア別のターゲット数、および平均コンプライアンス・スコアの各グラフが表示されます。

注意:
表示権限のあるターゲットの結果のみを表示できます。

45.2.6.1 リポジトリのコンプライアンス標準ルールの違反および違反の原因となるターゲットの調査

「エンタープライズ・サマリー」ページを参照していて、「ホストのセキュアな構成」コンプライアンス標準に対するクリティカル違反があることに気づいた場合、違反の原因となるターゲットを特定する必要があります。次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. コンプライアンス標準の「評価結果」タブで、「ホストのセキュアな構成」コンプライアンス標準をハイライトします。「詳細の表示」をクリックします。

3. 「コンプライアンス標準結果詳細」ページの「サマリー」タブで、ターゲット別とコンプライアンス標準ルール別に、結果を参照できます。この例では、コンプライアンス標準ルール別の結果を使用します。

4. ナビゲーション・リストで、「セキュア・ポート」コンプライアンス標準ルールをクリックします。表示された「セキュア・ポート・サマリー」タブに、「セキュア・ポート」ルールに違反しているすべてのターゲットのリストが示されます。これは、対処する必要があるセキュリティの問題です。

45.2.6.2 エンタープライズについて報告されたすべての違反の表示

コンプライアンス標準に準拠していないすべてのターゲットを参照したいとします。

- 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
コンプライアンス標準およびコンプライアンス・フレームワークに関連する違反を表示するオプションがあります。

- すべてのターゲットにわたるすべての違反、つまりコンプライアンスに従っていないすべてのターゲットのロールアップ・ビューの「ターゲット・コンプライアンス」タブをクリックします。

- 「コンプライアンス標準」タブをクリックして、違反があるコンプライアンス標準のリストを表示します。このタブから、「エラー」タブにアクセスして、コンプライアンス標準に対するエラーを表示することもできます。

- 特定のターゲットのホームページに移動します。「コンプライアンス標準サマリー」リージョンでは、重大度レベルに従ってコンプライアンス違反がリストされます。対象のコンプライアンス標準の名前をクリックして、違反の詳細を表示します。

45.2.6.3 違反の表示の例

前の項で説明したとおり、コンプライアンス機能では、コンプライアンスの問題を解決するのに役立つ違反の詳細が提供されます。違反の詳細にアクセスする方法は複数あります。

違反には次の場所からアクセスできます。

- 「エンタープライズ・サマリー」ページにある「コンプライアンス・サマリー」リージョン。
コンプライアンス標準およびコンプライアンス・フレームワークに対する違反を簡単に確認できます。

- 「コンプライアンス結果」ページ。「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

違反の詳細を確認する方法の例は、次のとおりです。

例1: コンプライアンス・フレームワークの違反の詳細へのアクセス

コンプライアンス・フレームワークの違反を参照するには、「コンプライアンス・フレームワーク」タブ、「評価結果」タブの順にクリックします。「違反」列に、各フレームワークに存在する違反の数がリストされます。「違反」列の数値をクリックすると、すべてのターゲットが、関連付けられたコンプライアンス標準とともにリストされます。

一方、「違反数」列の数値をクリックすると、表示される違反ページには、違反があるコンプライアンス標準ルールがリストされます。また、「違反数」列の数値をクリックすると、表示される違反の詳細ページには、違反の原因となる特定のコンプライアンス標準ルールのすべてのメトリックがリストされます。

例2: コンプライアンス標準の違反の詳細へのアクセス

「コンプライアンス標準」タブ、「評価結果」タブの順にクリックすると、「違反」列に、各コンプライアンス標準に存在する違反の数がレポートされます。

「違反」列の数値をクリックすると、標準に違反しているすべてのターゲットがリストされた「違反」ポップアップが表示されます。図45-1を参照してください。

図45-1 コンプライアンス標準の違反

また、「違反数」列の数値をクリックすると、「違反」ポップアップが表示されます。すべてのコンプライアンス標準ルール(セキュリティ推奨など)がリストされます。

「違反」ポップアップの「違反数」列の数値を再クリックして、処理を続行します。後続のポップアップに「違反の詳細」に表示されます。たとえば、「違反の詳細」ポップアップには、問題の原因であるパッチの名前が表示されます。

例3 - ターゲットの違反へのアクセス

「ターゲット・コンプライアンス」タブをクリックすると、「違反」列に、各ターゲットに存在する違反の数がレポートされます。

「違反」列の数値をクリックすると、標準に違反しているすべてのターゲットがリストされた「違反」ポップアップが表示されます。図45-2を参照してください。

図45-2 「ターゲット・コンプライアンス」タブを使用した違反

また、「違反数」列の数値をクリックすると、「違反」ポップアップが表示されます。すべてのコンプライアンス標準ルール(セキュリティ・ポートなど)がリストされます。

「違反」ポップアップの「違反数」列の数値を再クリックして、処理を続行します。後続のポップアップに「違反の詳細」が表示されます。たとえば、「違反の詳細」ポップアップには、コンプライアンス標準に違反しているポートの数が表示されます。

例4 - 「コンプライアンス標準」ページの「詳細を表示」を使用した違反

「コンプライアンス結果」ページの「詳細を表示」オプションを使用して、違反にドリルダウンすることもできます。標準を強調表示し、「詳細を表示」をクリックします。図45-3を参照してください。

図45-3 「詳細を表示」ページ

結果のページには、ターゲットまたはコンプライアンス標準ルール別に違反を表示するオプションがあります。

「違反」タブをクリックすると、「イベントの詳細」および「ガイドされた解決」を含むコンプライアンス標準に関する詳細がリストされます。図45-4を参照してください。

図45-4 「イベントの詳細」および「ガイドされた解決」

例5: 「エンタープライズ・サマリー」ページからの違反へのアクセス

「エンタープライズ・サマリー」ページの「コンプライアンス・サマリー」リージョンでコンプライアンス標準の名前をクリックすると、「コンプライアンス標準結果詳細」ページが表示されます。「違反」タブをクリックすると、特定のコンプライアンス標準に違反するすべてのターゲットを表示できます。図45-5を参照してください。

図45-5 「エンタープライズ・サマリー」ページの「コンプライアンス・サマリー」リージョン

「コンプライアンス標準結果詳細」ページで、「サマリー」タブ、「ターゲット別の結果」タブの順にクリックすると、ターゲットに対する違反の数が表示されます。違反列の数値をクリックすると、違反の原因となるコンプライアンス標準ルールがリストされた「違反」ポップアップが表示されます。次に、「違反数」列の数値をクリックすると、原因となっているメトリックまたはパッチの名前が表示されます。

注意: 「ターゲット・コンプライアンス」タブから、同様のドリルダウンが使用できます。

ヒント: 違反の最終結果に到達するには、「違反数」列の数値をクリックし続けます。さらに詳細が示され、問題の原因が絞り込まれます。

45.2.7 評価エラーの調査

「評価エラー」ページでは、評価中に発生した問題に関する統計が報告されます。まず、評価エラー・ページに、すべての評価エラーが表示されます。

- 評価エラー・ページには、メトリック収集の結果発生したエラー、および最後のポリシー評価中に発生したエラーが表示されます。

- 検索フィルタを使用して、指定する検索基準セットと一致する評価エラーのみを表示します。

- 「メッセージ」列のメッセージをクリックして、エラーを解決するための対策を決定します。

- 通常、評価の結果は、前回の評価結果を上書きします。ただし、評価が失敗またはデータ・プロバイダ収集が失敗した場合は、前回の結果は上書きされず、そのまま残ります。

根本の問題が解決されると、エラーは報告されません。

標準エラーの検索フィルタ

デフォルトでは、エンタープライズ構成内のすべての評価エラーが結果表に表示されます。ただし、検索基準のセットを指定し、基準と一致する評価エラーのみが結果表に表示されるように検索を実行できます。

たとえば、「ターゲット・タイプ」リストで「ホスト」、「ターゲット名」リストで「次を含む」、その隣の「ターゲット名」テキスト・フィールドで「-sun」を選択し、「実行」をクリックすると、Cloud Controlは、名前に「-sun」を含むホストのコンプライアンス標準ルールの評価エラーのみを結果表に表示します。

45.2.8 コンプライアンス・レポートの分析

Cloud Controlでは、コンプライアンス固有のレポートが提供されます。これらのレポートへのアクセスの手順:

1. 「エンタープライズ」メニューから、「レポート」、「情報パブリッシャ・レポート」の順に選択します。

2. 「コンプライアンス」セクションまでスクロールします。

コンプライアンス・レポートには、次が含まれます。

- 説明レポート
説明レポートには、コンプライアンス・ライブラリで使用可能なすべてのコンプライアンス標準、コンプライアンス・フレームワークおよびコンプライアンス標準ルールがリストされます。これらのレポートによって、エンタープライズが標準へのコンプライアンスを獲得および維持するために、コンプライアンス標準およびコンプライアンス・フレームワークを追加で定義する必要があるかどうかを判断できます。

- 結果レポート
結果レポートでは、コンプライアンス標準およびコンプライアンス・フレームワークに対する様々な評価の詳細が提供されます。結果レポートを使用すると、定義済の標準に対するエンタープライズのコンプライアンスに関するすべての統計を、1つの場所に表示できます。即時対応が必要な可能性が最も高いターゲットを表示するには、「最下位AVG COMPLIANCE SCOREのターゲット」レポートを表示します。次に、提供されているレポートの例を示します。

- コンプライアンス標準結果詳細
ターゲットに対して評価されたすべてのコンプライアンス標準のコンプライアンス・サマリーを表示します。データには、コンプライアンス・スコア、コンプライアンス、コンプライアンス・ルールおよび非コンプライアンス・ルール、違反および最終評価日が含まれます。

- コンプライアンス標準結果サマリー
特定のコンプライアンス標準のコンプライアンス・サマリーを表示します。たとえば、Oracle製品のコンプライアンスに関するセキュリティ推奨事項についてそれぞれがレポートするターゲットが3つある場合、結果サマリーでは、情報が1つのレポートにロールアップされます。データには、平均コンプライアンス・スコア、即時対応が必要なターゲットの数、および非コンプライアンス・ルールの数が含まれます。

Cloud ControlではBIパブリッシャ統合を使用して一連のレポートを提供することもできます。次のレポートを使用できます。

- リアルタイム監視違反レポート
リアルタイム監視ルール・タイプに基づいて現在の違反を示します。

- コンプライアンス・サマリー・レポート
現在のコンプライアンス・スコア、コンプライアンス傾向、上位10の最小コンプライアンス・システム・ターゲット、特定のコンプライアンス・フレームワークに対するフレームワーク違反サマリー、および第2レベルのフレームワーク・フォルダを示します。

- 監視ジャーナル・レポート
一定期間に発生した監視を示す表形式のレポートです。ユーザーがレポートのターゲット、開始時間および終了時間を選択できます。

注意: コンプライアンス・フレームワークが含まれるBI Publisherレポートが機能するようにするには、レポートを実行するユーザーがEM_COMPLIANCE_OFFICERロールを持つ必要があります。

45.2.9 コンプライアンス・スコアおよび重要度の概要

ターゲットのコンプライアンス標準に対するコンプライアンス・スコアは、ターゲットがそのコンプライアンス標準にどの程度準拠しているかを表すために使用されます。コンプライアンス・スコアは0%から100%(100%を含む)の範囲の数値です。コンプライアンス・スコアが100%の場合、ターゲットはコンプライアンス標準に完全にコンプライアンスしています。

評価時に、ターゲットがそのコンプライアンス標準に対してコンプライアンスであるか非コンプライアンスできるかが判断されます。

重要度のタイプ

重要度は、コンプライアンス・フレームワーク、標準およびルールのマップ時に行うことができる設定です。重要度を使用して、そのフレームワーク制御領域またはコンプライアンス標準のコンプライアンス・スコアにコンプライアンス違反が及ぼす影響を計算します。

コンプライアンス・フレームワークの場合、コンプライアンス標準のマップ時におけるこのコンプライアンス標準の重要度は、このフレームワーク内の他のコンプライアンス標準に対する相対的な重要度を示します。

コンプライアンス標準の場合、コンプライアンス標準ルールのマップ時における重要度は、コンプライアンス標準内の他のすべてのコンプライアンス標準ルールに対するコンプライアンス標準ルールの相対的な重要度を示します。

ただし、コンプライアンス標準ルールの重要度が「低」であるからといって、このルールを無視しても差し支えないわけではありません。修正または補正制御によってリスクが解消されたら、すべてのコンプライアンス違反の優先順位を決定してクリアする必要があります。

重要度は、コンプライアンス・スコアがコンプライアンス標準階層内でロールアップする際に重み付けするために使用されます。

次の各項では、コンプライアンス・スコアの計算方法の例について説明します。

45.2.9.1 コンプライアンス標準ルールのコンプライアンス・スコア - ターゲット

注意: この計算は、WebLogic Server署名ルールおよびリポジトリ・ルールに使用されます。

コンプライアンス標準ルール・ターゲットのコンプライアンス・スコアは、コンプライアンス標準ルールの重大度および重要度を使用し、この結果に、このターゲットに対して評価された行の合計数で違反の合計数を割った値を掛けることによって計算されます。

式は次のとおりです。

hirange - (hirange - lorange) * (number of violations / number of rows evaluated)

次の表は、コンプライアンス・スコアの計算に使用される重大度と重要度の値の組合せを示します。

表45-1 重要度と重大度の範囲

重要度

クリティカル重大度(1)

警告重大度(1)

マイナー警告重大度(1)

高

0-25 (2)

66-75

95-96

標準

26-50

76-85

97-98

低

51-75

86-95

99-99

(1)重大度の低範囲および高範囲

(2)低範囲は0、高範囲は25

45.2.9.2 リアルタイム監視ルールのコンプライアンス・スコア

リアルタイム監視ルールのコンプライアンス・スコアは、違反のある監視バンドルの数を、一定期間に発生した監視バンドルの数と比較した結果に基づいています。監視バンドルは、短い時間(数分)内に、同じターゲットに対する同じユーザーによって発生するすべての監視のコレクションです。たとえば、ユーザーAがホストにログインし、5分間に10ファイルの変更を行うとします。これらの10の監視はすべて同じバンドルに属することが可能です。バンドルはEnterprise Managerによって自動的に処理されます。

過去の監視バンドルの数を計算する際は、最新のバンドルの方が高く重み付けされ、古くなるにつれて重み付けが変化します。

スコアは、次の計算式を使用して計算されます。

1 - V/T
where T is the sum of all the weighted bundle counts
and V is the count of the current bundles in violation

1-V/Tの計算結果は、Vが0 (100%コンプライアンス)の場合は1に近い値となり、VがT (0%コンプライアンス)の値に近い場合は0に近い値となります。

45.2.9.3 ターゲットのコンプライアンス標準のコンプライアンス・スコア

各ターゲットのコンプライアンス標準のコンプライアンス・スコアは、各ルール・ターゲットの個別のコンプライアンス・スコアにその重要度を掛けることによって計算されます。この乗算がルールごとに繰り返された後、算出された各積が加算されます。次に、各積の合計が各ルールの重要度の合計で割られます。図45-6を参照してください。

図45-6 コンプライアンス標準ターゲットのコンプライアンス・スコアの計算方法

45.2.9.4 コンプライアンス・フレームワークのコンプライアンス・スコア

コンプライアンス・フレームワーク・スコアは、コンプライアンス・フレームワーク階層内のすべてのコンプライアンス標準にわたるすべてのコンプライアンス標準・ターゲット・スコアについて重み付けされてロールアップされた平均です。この重み付けは、コンプライアンス標準の重要度に基づいています。図45-7では、コンプライアンス・フレームワークCFにはCS1とCS2の2つの標準があります。CS1はターゲットt1およびt2に対して関連付けられて評価され、CS2はターゲットt3およびt4に対して関連付けられて評価されます。

図45-7 コンプライアンス・フレームワークのコンプライアンス・スコアの計算方法

45.2.9.5 親ノードのコンプライアンス・スコア

階層ノード/親ノードのコンプライアンス・スコアは、図45-8に示すように計算されます。コンプライアンス標準は階層的であるため、ツリー内の上位ノードは親ノードと呼ばれます。

図45-8 親ノードのコンプライアンス・スコア

次に、図45-8について説明します。

- i: 子の数

- S: 子ノードのスコア

- I: 子ノードの重要度

45.3 リアルタイム監視の調査

前に説明したとおり、監視は、ホストに表示されたアクションまたはリアルタイム監視ルールで監視対象として構成されたターゲットです。各ユーザー・アクションが1つの監視結果になります。

監視は多くの監査ステータスの1つを持つことができます。基本監査ステータスである非監査は、監視が検出されたが、このアクションが良好であるか不良であるかは示されていないことを意味します。認証済ステータスは、監視に対してなんらかの確認が行われており、これは発生が予期される(良好な変更であった)ものとして処理する必要があることを意味します。非認証ステータスは、この監視が確認されており、ポリシーに違反することが判明したことを意味します。この結果、修正、ポリシーの変更、または補正制御が行われる場合があります。監視の監査ステータスをルールによって自動的に設定することにより、ルールによってトリガーされるすべての監視をデフォルトの監査ステータスにすることができます。また、後述するUIレポートを介してステータスを手動で設定することもできます。最も高度な機能には、アクションの実行が想定されていたかどうかを監視ごとに自動的に確認するためにCloud Controlコネクタを介して変更管理リクエスト・サーバーと統合する機能が含まれます。

次の各項で、リアルタイム監視の詳細を示します。

- 監視の表示

- コンプライアンス評価時の監視の操作

45.3.1 監視の表示

使用環境内で発生したリアルタイム監視の観察を確認する方法は主に4通りあります。

- システム別の監視の表示

- コンプライアンス・フレームワーク別の監視の表示

- 検索別の監視の表示

- インシデントの詳細の表示

最初の3つの監視画面は、「エンタープライズ」メニューから「コンプライアンス」、「リアルタイム監視」の順に選択することによってアクセスできます。このページでは、3つのレポートのうちどれを参照するかを選択でき、リアルタイム監視ルール構成に関連する管理エージェントの警告も表示されます。これらの警告は、管理エージェントからレポートされ、Cloud Controlサーバーへの監視の配信に影響を及ぼす可能性があります。予期される監視が欠落している場合は、これらの警告を確認し、それらの原因である構成問題に対処します。

45.3.1.1 システム別の監視の表示

監視が発生したときに、その監視を自動的に認証済または非認証としてマークできます。これは、調査する必要のある重要な監視を見つける1つの方法を提供します。ただし、監視を変更管理サーバーと調整するようにルールが構成されていない場合、属性検索のみで重要な監視を見つけることは困難な可能性があります。ビジネス・アプリケーション(汎用システム)別に監視を表示し、監視の詳細にドリルダウンできる機能により、監視の監査ステータスとは関係なく、調査する必要のある問題が発生している可能性のある場所を特定できます。

通常、ITマネージャと部門所有者は、ビジネス・アプリケーションで好ましくない構成の変化が発生したかどうかを識別する必要があります。監視をシステム別に表示することにより、どの変更がビジネス・アプリケーションに影響を与えているかを容易に確認できます。監視は、認証済、非認証、未監査、または非認証と未監査の両方を基準にフィルタできます。また、時間別にフィルタすることもできます。

これは、1つ以上のビジネス・アプリケーションを選択し、監視の相対数を参照できることから始まります。ITマネージャおよびコンプライアンス監査者がターゲットの使用目的を把握していない可能性があるため、このレポートはビジネス・アプリケーション・レベル(汎用システム)で開始されます。ビジネス・アプリケーションはCloud Controlで汎用システムとしてモデル化されます。

より熟達したユーザーであれば、これが作業対象のビジネス・アプリケーションである場合、このビジネス・アプリケーション・レベルで開始してもかまいません。

システム別に監視を表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」、「リアルタイム監視」の順に選択します。

2. 「システム・ターゲット別の監視の参照」をクリックします。
「ルート・ターゲットの選択」ページが表示され、各システム・ターゲットのターゲット名がリストされます。また、システム・ターゲットの属していないすべてのターゲットに対するリンクもあります。

3. 1つ以上のシステム・ターゲットを選択し、「選択したシステムの詳細を表示」ボタンをクリックすることにより、特定のシステム・ターゲットのレポートの表示を開始できます。
選択した時間範囲別に選択した各システム・ターゲットに対するカウントが表示されます。たとえば、月次時間範囲を参照している場合、表内の各列は月内の1日を表します。カウントは、この日およびシステム・ターゲットの監視のカウントになります。

システム・ターゲット名をクリックしてドリルダウンし、システム・ターゲットを構成する各ターゲット別のカウントを表示します。監視が行われたエンティティ(例: ファイル名、プロセス名、ユーザー・アカウントなど)に達するまで、ドリルダウンする表の先頭列内のリンクをクリックし続けることができます。

カウントをクリックすると、その期間中に発生した実際の監視を示す画面が表示されます。

45.3.1.2 コンプライアンス・フレームワーク別の監視の表示

コンプライアンス標準の構造に関係する場合の監視を表示する機能は、ITマネージャ、部門オーナー、コンプライアンス・マネージャ、経営者など技術者以外が実行するのが一般的です。

組織が準拠しているITコンプライアンス・フレームワークが反映されている特定のコンプライアンス・フレームワーク・セットを識別できます。監視は、認証済、非認証、未監査、または非認証と未監査の両方を基準にフィルタできます。また、時間別にフィルタすることもできます。

コンプライアンス・フレームワーク別に監視を表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」、「リアルタイム監視」の順に選択します。
カウントをクリックすると、その期間中に発生した実際の監視を示す画面が表示されます。

2. 「コンプライアンス・フレームワーク別の監視の参照」をクリックします。
「コンプライアンス・フレームワークの選択」ページが表示され、定義されている各コンプライアンス・フレームワークがリストされます。

3. 1つ以上のフレームワークを選択し、「選択したフレームワークの詳細を表示」ボタンをクリックすることにより、特定のフレームワークのレポートの表示を開始できます。
選択した時間範囲別に選択した各フレームワークに対するカウントが表示されます。たとえば、月次時間範囲を参照している場合、表内の各列は月内の1日を表します。カウントは、この日およびフレームワークの監視のカウントになります。フレームワーク名をクリックし、選択したフレームワーク内にある第2レベルのフレームワーク・フォルダ別にカウントをドリルダウンして表示します。監視が行われたエンティティ(例: ファイル名、プロセス名、ユーザー・アカウントなど)に達するまで、ドリルダウンする表の先頭列内のリンクをクリックし続けることができます。

4. カウントをクリックすると、その期間中に発生した実際の監視を示す画面が表示されます。

これらの画面で提供されるこのドリルダウン機能により、監視の発生箇所を容易に特定できます。数百のビジネス・アプリケーションにわたって数万のターゲットが存在する環境では、ユーザーが検索条件を正確に把握していないかぎり、表と検索を使用して単純に監視を表示することが重要です。このような大規模な環境では、たとえアクティビティが少ない場合でも、数時間のうちに数千の監視が発生する可能性があります。

45.3.1.3 検索別の監視の表示

2画面による参照でも、使用環境内でどのような監視が行われたかに関する最適なビューを得られない場合は、監視を検索するための検索機能を使用することもできます。

監視を検索するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」、「リアルタイム監視」の順に選択します。

2. 「監視の検索」をクリックします。
「監視の検索」ページが表示されます。ページの上半分には検索フィルタがあり、下半分には検索結果が表示されます。

3. 検索領域では任意の数のフィルタを設定できます。また、「フィールドの追加」ボタンをクリックすると、検索結果表で使用可能な任意のフィールドを追加することもできます。

4. 検索内で使用可能なオプションを使用すると、一定の時間範囲内に実行された監視を、特定のユーザー、特定のターゲット、特定のエンティティの変更などを基準に検索できます。監視の検索に関するほぼすべてのユースケースは、検索フィールドの組合せによって解決できます。

45.3.1.4 インシデントの詳細の表示

監視は、コンプライアンス基準ルール、ターゲット、およびアクションを実行したユーザーに基づいて論理的にバンドルされます。このバンドルの詳細は、リアルタイム監視ルールの作成に関する項を参照してください。

バンドルの1つ以上の監視が認証されない場合、そのバンドルは違反とみなされます。この違反の結果、Cloud Controlインシデント管理でイベントが作成されます。イベント名は、リアルタイム監視ルールに定義されているメッセージ・フィールドに基づいて付けられます。インシデント管理UIでこのイベントを表示する場合、ターゲット・タイプ、エンティティ・タイプ、バンドル内の監視の数、監査ステータス別の監視などのバンドルの詳細が複数のフィールドに表示されます。「監査ステータスの更新」リンクをクリックすると、バンドル監視ページに移動できます。

この「監視」ページには、このイベントの監視バンドルに含まれている監視のリストが表示されます。各監視は、認証済/非認証ステータス、ユーザー、時間などの様々な属性でフィルタできます。

45.3.2 コンプライアンス評価時の監視の操作

次の各項では、リアルタイム監視の監査ステータスを調整する方法や、コンプライアンス結果を評価する上で通知がどのように役立つかについて説明します。

- 監視の認証済または非認証への手動設定

- 監視が発生した場合のユーザーへの通知

- 認証された監視が発生した場合のユーザーへの通知

45.3.2.1 監視の認証済または非認証への手動設定

リアルタイム監視の詳細を表示している場合は常に、監視の監査ステータスを変更できます。ユーザー処理を調査して、アクティビティが異なる監査ステータスになる必要があると判断した場合、監視の監査ステータスを上書きできます。リアルタイム監視ルールに基づいて、すべての監視は、事前設定された監査ステータスを持つか、変更リクエスト管理サーバーとの統合によって決定された監査ステータスを持ちます。使用可能な監査ステータスは、次のとおりです。

- 非監査: 監視が良好か不良かを確認する評価が行われていません。

- 認証済: 監視は良好で、実行することが望ましいアクションであったことが確認されました。

- 非認証: 監視は不良で、不要なアクションであったことが確認されました。

- 非認証-クリア済: 監視は不良で、不要なアクションであったことが前に確認されましたが、修正、ポリシー変更または補正制御によって処理されており、現在はクリアされています。

監視の監査ステータスを変更するには、UIページ、監視検索ページ、またはインシデント・マネージャUIを使用した参照によって監視を表示します。監視を選択し、「監査ステータスの更新」をクリックします。ポップアップが表示され、新規監査ステータス、およびステータスの変更理由を説明するコメントを選択できます。監視ごとに監査ステータスのすべての変更の履歴が保持されます。

Cloud Controlインスタンスによって統合用の変更リクエスト管理サーバー・コネクタが使用されている場合、特別な考慮事項があります。

- 非認証の監視を認証済の監視に変更する場合、変更を認証する変更リクエストIDを入力するオプションがあります。この変更リクエストIDは、変更リクエスト管理システムにすでに存在するリクエストと一致する必要があります。コメントも入力できます。変更リクエストIDが提供されると、システムが自動的に認証したかのように、変更リクエストに変更の注釈が付けられます。監視バンドルにインシデントが作成された場合、イベント/インシデントが新しい数の非認証の監視で更新されます。

- 認証済の監視を非認証または未監査の監視に変更する場合、変更リクエストに付加された注釈はロールバックされます。監視バンドルに対してすでにインシデントが発生している場合は、注釈が変更され、インシデント内の非認証の監視の数が更新されます。これがグループ内の最初の非認証の監視である場合は、イベントが作成され、インシデントが発生します。変更に関するコメントを入力できます。

- 監視を手動で認証済に設定して変更リクエストIDを入力し、ルールで変更管理との統合が有効化されている場合、変更リクエストの属性は監視と比較されません。その変更リクエストは、単に監視詳細によって更新されます。

- 変更管理サーバーで注釈をロールバックすると、監視の注釈は実際に削除されるのではなく、ロールバック済としてマークされます。これは、注釈が削除された理由がわからないことなどによってユーザーが混乱するのを防ぐためです。また、後で監視が再び認証済になった場合は、単にロールバック済のマーキングが削除され、注釈が戻されます。

45.3.2.2 監視が発生した場合のユーザーへの通知

コンプライアンス基準ルールが作成され、そのルールとの変更管理リコンシリエーションを使用しない場合、監視で認証/非認証の自動チェックは実行されません。このルールに、各監視バンドルに対して情報イベントが生成されるように指定できます。この構成方法の詳細は、リアルタイム監視ルールの作成に関する項を参照してください。

イベントには注釈が付きます。ユーザーは、インシデント管理コンソールからイベントおよびインシデントを参照できます。単一イベントを参照する場合、その監視バンドルのイベントに関連付けられている監視を参照できるリンクがあります。各監視バンドルには、1つのイベントのみが作成されます。バンドル内の少なくとも1つの監視が認証されないと、そのバンドルは違反とみなされ、イベントが生成されます。

この通知はユーザーによる操作または後続処理を必要としないため、情報として扱われます。後から誰かがこれらの未監査の監視のいずれかを認証済または非認証の監視に変更した場合、未監査の監視に対する新規情報イベントは再配信されません。イベントは、監視バンドルに対して1回のみ配信されます。ただし、いずれかの監視が手動で非認証に設定された場合は、その監視バンドル全体に対して違反が発生します。

バンドル内の少なくとも1つの監視が非認証状態である場合、違反が作成されます。この違反は、インシデント・マネージャ・コンソールでイベントになります。「インシデント・マネージャ」機能を使用して通知を設定します。この詳細は、インシデント・マネージャ・ページで、オンライン・ヘルプの概要に関する章の通知の設定に関する項にある、ルールを使用した通知の設定に関する項のリンクをクリックしてください。

45.3.2.3 認証された監視が発生した場合のユーザーへの通知

認証された監視が発生した場合、監視の原因となったアクティビティは想定されたものであるため、これらの監視について通知を受け取るのは一般的ではありません。変更管理リコンシリエーションを使用している場合、オプションとして、認証する変更リクエストに監視の詳細に関する注釈を付けることができます。変更リクエストに対する更新は、カスタマが認証されたアクティビティについて知ることのできる方法の1つです。変更管理システムでフィルタを設定して、変更リクエストによってアクティビティが認証されたことを知らせることができます。

45.4 コンプライアンス管理の構成

コンプライアンス機能を使用する前に、コンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールを、エンタープライズに対して定義する必要があります。

次の各項では、これらのコンプライアンス・エンティティを定義および維持する方法について説明します。

- コンプライアンス・フレームワークについて

- コンプライアンス・フレームワークでの操作

- コンプライアンス標準について

- コンプライアンス標準での操作

- コンプライアンス標準ルール・フォルダについて

- コンプライアンス標準ルールについて

- コンプライアンス標準ルールでの操作

45.4.1 コンプライアンス・フレームワークについて

コンプライアンス・フレームワークは、1つ以上のコンプライアンス標準、コンプライアンス標準ルール・フォルダおよびコンプライアンス標準ルールに任意のノードをマップできる階層構造です。コンプライアンス・フレームワークは、会社で使用する規制または標準ベースのコンプライアンス構造と類似した構造に標準をマップする方法を提供します。

コンプライアンス・フレームワークの管理

コンプライアンス・フレームワークを管理するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・フレームワーク」タブをクリックします。

3. 管理するコンプライアンス・フレームワークをハイライト表示し、実行するアクションを選択します。

Oracle提供のフレームワークおよびユーザー定義のコンプライアンス・フレームワーク

Oracle提供のコンプライアンス・フレームワークと、ユーザー定義のコンプライアンス・フレームワークがあります。

- Oracle提供のコンプライアンス・フレームワークには、次が含まれます。

- Oracleサポート・コンプライアンスは、Oracleサポータビリティに対して期待される環境コンプライアンスをチェックするコントロールのコレクションです。

- Oracleの汎用コンプライアンス・フレームワークは、変更を追跡するためのコンプライアンス標準と関連付けられた制御、および組織がITポリシーにどの程度準拠しているかを判断するためにITインフラストラクチャ全体に実行されるイベントの標準的なセットです。

- セキュリティ技術導入ガイド(STIG)は、セキュリティ技術導入ガイド(STIG)コンプライアンスを確認するための一連の標準です。

- ユーザー定義のコンプライアンス・フレームワーク
組織のニーズを満たすコンプライアンス・フレームワークを定義できます。

Oracleの提供するコンプライアンス・フレームワークは、削除または編集できません。ただし、これらのフレームワークを拡張する場合、類似作成機能を使用して、Oracle提供のフレームワークに基づいて独自のユーザー定義フレームワークを作成してから、新規フレームワークを編集することができます。

推奨: STIGおよびOracleの汎用コンプライアンス用として提供されているコンプライアンス・フレームワークのような上位レベルのコンプライアンス・フレームワークを作成することを強くお薦めします。

コンプライアンス・フレームワークを作成する利点

コンプライアンス標準は、ターゲットに対するテストを実行するために定義します。これには、構成値が正しく設定されているかのテスト、リアルタイム・ファイルの変更が行われているかを確認するテストなどがあります。コンプライアンス・フレームワークによって、コンプライアンス構想のどの制御領域までこれらのテストの結果が影響するかをマップします。

ある組織で、Oracle提供のコンプライアンス・フレームワークを拡張するコンプライアンス・フレームワークを定義するとします。これを行うには、Oracle提供のコンプライアンス・フレームワークなどの新規コンプライアンス・フレームワークを作成し、新規または既存のコンプライアンス標準を組み込みます。これにより、各コンプライアンス標準は適切なフレームワーク階層フォルダにマップされ、標準に対する違反もこのフレームワーク・フォルダにマップされるようになります。フレームワーク内の各フォルダは1つの制御領域を表します。

コンプライアンス・フレームワークを使用する理由

コンプライアンス・フレームワークを作成するのは、次のようないくつかの理由があります。

- 企業で使用される規制および基準のコンプライアンス制御への基本的なIT違反のマッピングによる、違反の影響を受けるコンプライアンス制御領域の簡単な特定

- コンプライアンス指定レベルでのコンプライアンス監査

- 監査、セキュリティ評価および傾向分析

コンプライアンス・フレームワークで実行可能な操作

コンプライアンス・フレームワークでは、次のことを実行できます。

- 業界標準のコンプライアンス制御領域を表し、使用している内部フレームワークに合せて作成します。
多くの会社が、業界標準のフレームワークを使用して開始しますが、独自のニーズや監査要件に応じて変更します。

- 危険な状態にあり、違反に基づく補正制御が必要な可能性があるコンプライアンス制御を特定することにより、IT監査をサポートします。影響を受ける制御領域にコンプライアンス・チェックをマップしない場合、コンプライアンス監査における実質的な影響を特定することが困難になります。

- コンプライアンス・フレームワークには様々なタイプのコンプライアンス標準(リポジトリ、WebLogic Serverの署名、リアルタイム監視)を組み込むことができるため、レポートを目的として様々なタイプの類似チェックをグループ化する上で役立ちます。

使用上の注意

リポジトリ・ルールの評価結果は、コンプライアンス・フレームワーク内のコンプライアンス標準ルールが変更または削除された場合に無効化されることがあります。コンプライアンス標準の評価では、コンプライアンス標準内の各コンプライアンス標準ルールの現在のコンプライアンス標準ルールの定義を常に参照しています。

45.4.2 コンプライアンス・フレームワークでの操作

コンプライアンス・フレームワークで次の操作を実行できます。

- コンプライアンス・フレームワークの作成

- コンプライアンス・フレームワークの類似作成

- コンプライアンス・フレームワークの編集

- コンプライアンス・フレームワークの削除

- コンプライアンス・フレームワークのエクスポート

- コンプライアンス・フレームワークのインポート

- コンプライアンス・フレームワークの参照

- コンプライアンス・フレームワークの検索

次の各項では、これらの操作について説明します。

注意: コンプライアンス・フレームワークで操作を実行する前に、必要な権限があることを確認します。たとえば、コンプライアンス・フレームワークを作成する場合、フレームワークの定義時に含めるコンプライアンス標準へのアクセス権限を持っていることを確認します。(45.1.3項を参照。)

45.4.2.1 コンプライアンス・フレームワークの作成

コンプライアンス・フレームワークを作成しやすくするには、コンプライアンス・フレームワークによって参照されるコンプライアンス標準がCloud Controlですでに定義されていることを確認します。システムの即時利用可能なコンプライアンス標準およびユーザー定義のコンプライアンス標準をコンプライアンス・フレームワークの任意の要素に追加できます。コンプライアンス標準を事前に定義しない場合、これらを後で追加する必要があります。

コンプライアンス・フレームワークを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・フレームワーク」タブをクリックします。

3. 「作成」ボタンをクリックします。

4. 名前および作成者を指定し、「OK」をクリックします。

5. 一度、定義ページで情報を指定すると、(ページの左上にある)コンプライアンス・フレームワークの名前を右クリックして、使用可能なオプションを参照できます。このリストから、コンプライアンス標準などのサブグループを作成できます。

6. 「保存」をクリックします。

使用上の注意

- ライフサイクル・ステータスには、開発または本番があります。

- 開発
コンプライアンス・フレームワークが開発中で、定義された作業はまだ進行中であることを示します。開発モードの間、コンプライアンス・フレームワークの編集およびコンプライアンス・フレームワークの削除など、コンプライアンス・フレームワークのすべての管理機能がサポートされます。開発のコンプライアンス標準の結果は、ターゲットとコンソールのホームページ、およびコンプライアンス・ダッシュボードには表示されません。

ライフサイクル・ステータスのデフォルトは開発です。これを「本番」に一度のみ更新できます。本番から開発には変更できません。

- 本番
コンプライアンス・フレームワークが承認され、本番の品質を持つことを示します。コンプライアンス・フレームワークが本番モードの場合、結果はコンプライアンス・ダッシュボード、ターゲットおよびコンソール・ホームページにロールアップされます。

本番のコンプライアンス・フレームワークは、本番のコンプライアンス標準のみを参照できます。本番のコンプライアンス・フレームワークを編集して、本番のコンプライアンス標準への参照のみを追加/削除できます。

ライフサイクル・ステータスは、本番から開発には変更できません。

- 「キーワード」列でソートすると、同じキーワードを持つすべてのコンプライアンス・フレームワークはグループ化されます。

- コンプライアンス・フレームワークに追加されたリポジトリまたはWebLogic Serverの署名のコンプライアンス標準を変更する場合は、コンプライアンス標準を直接編集するか、「インポート」を使用してコンプライアンス標準を新規の設定で上書きし、既存の評価を無効にします。つまり、変更したコンプライアンス標準が評価済のコンプライアンス・フレームワークに含まれており、評価結果がある場合は、これらの結果は表示されなくなります。

コンプライアンス標準をコンプライアンス・フレームワークに追加

コンプライアンス標準のマップ先のフレームワーク・フォルダ要素をクリックします。右クリックして「基準の追加」を選択し、このフォルダにマップする標準を選択できるポップアップを表示します。

検索基準を使用して、選択リストに表示されるコンプライアンス標準の数を最小化します。

選択し終わったら、「OK」をクリックします。フレームワーク階層画面がリフレッシュされ、新しく組み込んだコンプライアンス標準がフレームワーク・フォルダ要素の下に表示されます。

重要度の編集

選択したコンプライアンス・フレームワーク・フォルダの一部に組み込むコンプライアンス標準をマップした後、指定したこのフォルダの各コンプライアンス標準の重要度を編集できます。

重要度は、このフレームワーク・フォルダ内のこのコンプライアンス標準に対してコンプライアンス・スコアを計算する方法に影響します。

このスコアの計算方法の詳細は、「コンプライアンス・スコアおよび重要度の概要」を参照してください。

45.4.2.2 コンプライアンス・フレームワークの類似作成

別のコンプライアンス・フレームワークに類似したコンプライアンス・フレームワークを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・フレームワーク」タブをクリックします。

3. コンプライアンス・フレームワーク・ライブラリ・ページで、ベースとして使用するコンプライアンス・フレームワークをハイライトし、「類似作成」ボタンをクリックします。

4. 必要に応じて、フィールドをカスタマイズします。
コンプライアンス・フレームワーク名が、元のコンプライアンス・フレームワークおよび他の既存のコンプライアンス・フレームワークと異なることを確認します。

5. 「保存」をクリックします。

6. これにより、新しく作成したこのフレームワークの編集、標準、サブフォルダの追加または削除、または重要度レベルの変更が可能になります。

45.4.2.3 コンプライアンス・フレームワークの編集

コンプライアンス・フレームワークの編集機能を使用して、新規コンプライアンス標準ルールをコンプライアンス・フレームワークに追加するか、既存のコンプライアンス・フレームワークの詳細を編集するか、または、コンプライアンス・フレームワークからコンプライアンス標準を削除します。

コンプライアンス・フレームワークを編集するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・フレームワーク」タブをクリックします。

3. 編集するコンプライアンス・フレームワークをハイライト表示し、「編集」ボタンをクリックします。

4. 必要に応じて、プロパティを更新します。
標準またはサブグループを追加するには、ページの左上にあるフレームワークの名前を右クリックします。

5. 「保存」をクリックします。

使用上の注意

- コンプライアンス・フレームワークの定義を変更すると、傾向分析に影響を与える場合があります。

- コンプライアンス・フレームワークに追加するコンプライアンス標準は、「コンプライアンス標準ライブラリ」ページで表示されるように、システム定義およびユーザー定義のコンプライアンス標準になります。

- コンプライアンス・フレームワークに追加されたリポジトリまたはWebLogic Serverの署名のコンプライアンス標準を変更する場合は、コンプライアンス標準を直接編集するか、「インポート」を使用してコンプライアンス標準を新規の設定で上書きし、既存の評価を無効にします。つまり、変更したコンプライアンス標準が評価済のコンプライアンス・フレームワークに含まれており、評価結果がある場合は、これらの結果は表示されなくなります。このコンプライアンス・フレームワークの評価結果は、次の評価を行った後に再度表示されるようになります。新しい評価には、コンプライアンス・フレームワーク内でのコンプライアンス標準の変更も対象になります。

- 重要度は、このフレームワーク・フォルダ内のこのコンプライアンス標準に対してコンプライアンス・スコアを計算する方法に影響します。

- 1つのコンプライアンス標準を複数のコンプライアンス・フレームワークに追加し、追加されたコンプライアンス・フレームワークごとに異なる重要度を持たせることができます。たとえば、ユーザー・アカウントにパスワードが期限切れになったというフラグを設定する「Check Password Expired」というコンプライアンス標準を設定できます。このコンプライアンス標準は、「All System Passwords Secure」と「30-day Password Validation」という2つのコンプライアンス・フレームワークのメンバーになる場合があります。「All System Passwords Secure」コンプライアンス・フレームワークでは、パスワードのセキュリティが検証され、「30-day Password Validation」コンプライアンス・フレームワークでは、前回このパスワードを設定した日付がチェックされます。

- 「30-day Password Validation 」コンプライアンス・フレームワークでは、「Check Password Expired」コンプライアンス標準の重要度は非常に高いになります。このチェックにより、パスワードが期限切れになることがユーザーに警告されるためです。

- 「All System Passwords Secure」コンプライアンス・フレームワークでは、「Check Password Expired」コンプライアンス標準の重要度は「標準」であり、このコンプライアンス・フレームワークでは、セキュリティ・チェックを実行するその他の追加コンプライアンス標準の方が重要度が高くなります。

45.4.2.4 コンプライアンス・フレームワークの削除

コンプライアンス・フレームワークを削除するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・フレームワーク」タブをクリックします。

3. 削除するコンプライアンス・フレームワークをハイライト表示し、「削除」ボタンをクリックします。

4. 「OK」をクリックし、コンプライアンス・フレームワークを削除することを確認します。

使用上の注意

- コンプライアンス・フレームワークは1つずつ、またはリストで削除できます。コンプライアンス・フレームワークを削除すると、関連するメタデータと評価結果も削除されます。

- ORACLEによって定義されたコンプライアンス・フレームワークは削除できません。これらは、コンプライアンス・フレームワークのリスト・ページ上のコンプライアンス・フレームワーク名の前にあるロック・アイコンの存在によって示されます。

45.4.2.5 コンプライアンス・フレームワークのエクスポート

エクスポート機能は、管理リポジトリおよびCloud Controlインスタンス間でユーザー定義のコンプライアンス・フレームワーク定義をトランスポートするためのメカニズムです。エクスポートによって、オペレーティング・システム・ファイルに定義を格納します。エクスポートしたコンプライアンス・フレームワーク定義は、XMLフォーマットであるため、Oracleコンプライアンス標準定義(XSD)フォーマットに準拠しています。コンプライアンス・フレームワークの定義を変更でき、生成されたコンプライアンス・フレームワーク定義を別の管理リポジトリに再インポートできます。

コンプライアンス・フレームワークをエクスポートするには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・フレームワーク」タブをクリックします。

3. エクスポートするコンプライアンス・フレームワークをハイライトします。

4. 「アクション」メニューから、「エクスポート」を選択します。

5. コンプライアンス・フレームワーク定義をエクスポートするファイル名を指定します。リーフ・レベルのルールおよびコンプライアンス標準がエクスポートされます。

指定するディレクトリおよびファイルにコンプライアンス・フレームワークのXML表現が生成されます。

45.4.2.6 コンプライアンス・フレームワークのインポート

インポートにより、すでに所有しているコンプライアンス・フレームワークの再使用、Cloud Controlの複数のインスタンス間でのフレームワーク定義の共有、フレームワークのオフライン編集の有効化が可能になります。

コンプライアンス・フレームワークをインポートする前に、インポートするコンプライアンス・フレームワークがファイルに定義されていることを確認します。このファイルには、Cloud Controlにアクセスするために使用しているブラウザからローカルにアクセスできる必要があります。また、インポートするコンプライアンス・フレームワーク定義XMLファイルへのアクセス権限を持っていることも確認します。

注意:
ルールを含むコンプライアンス標準(または、標準を含むフレームワーク)をUIまたはコマンドライン・インタフェースからインポートする場合は、<ComplianceContent>を含むxmlファイルをルートとしてインポートします。このルート・ファイルには、ルール、標準、フレームワークおよび標準グループのリストが含まれています。
これにより、フレームワークおよび標準の定義が正常にインポートされていることがわかります。さらに、関連するターゲットはすべて、変更された定義に基づいて再評価されます。

コンプライアンス・フレームワークをインポートするには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・フレームワーク」タブをクリックします。

3. 「アクション」メニューから、「インポート」を選択します。

4. コンプライアンス・フレームワーク定義(コンプライアンス・フレームワークXSDに従う)をインポートするファイル名を指定します。コンプライアンス・フレームワーク定義がすでに存在する場合に既存の定義をオーバーライドするかどうかを指定します。参照コンテンツをインポートするかどうか、およびすべてのリーフ・レベルのルールおよびコンプライアンス標準がインポートされるかどうかを指定します。ルールのリアルタイム監視タイプでは、リアルタイム監視ファセットもインポートされます。

5. 「OK」をクリックします。

45.4.2.7 コンプライアンス・フレームワークの参照

コンプライアンス・フレームワークを参照するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・フレームワーク」タブをクリックします。

3. 特定のコンプライアンス・フレームワークの詳細を表示するには、コンプライアンス・フレームワークをハイライトして「詳細を表示」をクリックします。

45.4.2.8 コンプライアンス・フレームワークの検索

コンプライアンス・フレームワークを検索するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・フレームワーク」タブをクリックします。

3. ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。

4. 「検索」をクリックします。

45.4.2.9 コンプライアンス・フレームワークの評価結果の参照

コンプライアンス・フレームワークの評価結果を参照するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. コンプライアンス・フレームワークタブをクリックし、「評価結果」タブをクリックします。

3. コンプライアンス・フレームワークをハイライト表示し、「詳細を表示」をクリックして、特定のコンプライアンス・フレームワークの詳細を表示します。

結果には、次のものがあります。

- コンプライアンス・フレームワークで参照されるコンプライアンス標準に対して評価される異なるターゲットの平均コンプライアンス・スコア

- コンプライアンス・フレームワークで参照される異なるコンプライアンス標準のターゲット評価(クリティカル、警告、コンプライアンス)の数

- コンプライアンス・フレームワークで参照されるコンプライアンス標準に関連する違反(クリティカル、警告、マイナー警告)の数

45.4.2.10 コンプライアンス・フレームワークの評価結果の検索

コンプライアンス・フレームワークの評価結果を検索するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. コンプライアンス・フレームワークタブをクリックし、「評価結果」タブをクリックします。

3. ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。

4. 「検索」をクリックします。

45.4.2.11 コンプライアンス・フレームワークのエラーの参照

コンプライアンス・フレームワークのエラーを参照するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. コンプライアンス・フレームワークタブをクリックし、「エラー」タブをクリックします。

使用上の注意

エラーは、予期しない内部エラーまたはテスト中のエラーです。

通常、評価エラーの原因となるのは構成およびインストールの問題です。次のマニュアルの情報を参照してください。

- 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』

- 『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』

インストールおよび構成を正しく行ってもエラーが解消されない場合は、オラクル社にサポートを依頼してください。

45.4.2.12 コンプライアンス・フレームワークのエラーの検索

コンプライアンス・フレームワークのエラーを検索するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. コンプライアンス・フレームワークタブをクリックし、「エラー」タブをクリックします。

3. ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。

4. 「検索」をクリックします。

使用上の注意

エラーは、予期しない内部エラーまたはテスト中のエラーです。

通常、評価エラーの原因となるのは構成およびインストールの問題です。次のマニュアルの情報を参照してください。

- 『Oracle Enterprise Manager Cloud Control基本インストレーション・ガイド』

- 『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』

インストールおよび構成を正しく行ってもエラーが解消されない場合は、オラクル社にサポートを依頼してください。

45.4.2.13 データベース・ターゲットがコンプライアンス・フレームワークに準拠していることの検証

監査者が、データベース・ターゲットがコンプライアンス・フレームワークに準拠していることを検証するには、Cloud Control構造が定義されている必要があります。この構造を指定する手順は次のとおりです。

1. スーパー管理者が、コンプライアンス作成者、IT管理者、コンプライアンス監査者という3つのCloud Controlユーザーを作成します。

2. スーパー管理者が、コンプライアンス作成者とIT管理者に適したロールおよび権限を割り当てます。

3. スーパー管理者が、IT管理者とコンプライアンス監査者に同じターゲット権限を割り当てます。

4. コンプライアンス作成者がCloud Controlにログインし、Oracle提供のコンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールを表示します。
次に、適切なコンプライアンス標準ルールを有効化および無効化し、新規コンプライアンス標準ルールを作成します。

5. IT管理者が、Cloud Controlにログインし、ターゲット権限のあるターゲットを適切なコンプライアンス標準に関連付けます。

6. IT管理者が、特定のターゲットのコンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールの適切な構成パラメータおよび設定を設定します。
次に、このターゲットから監視テンプレートを作成し、コンプライアンス標準が必要な、権限のある他のターゲットにこれを適用します。

7. コンプライアンス監査者が、Cloud Controlにログインし、表示権限のあるエンタープライズ・レベルと各ターゲット・レベルの違反およびエラーを表示します。
次に、違反およびエラーを修正するのに必要なアクションを実行します。

45.4.3 コンプライアンス標準について

コンプライアンス標準は、チェックまたはルールのコレクションです。それは、制御に従っているかどうかを判断するために、ITインフラストラクチャのセットに対してテストする必要があるコンプライアンス制御をCloud Controlによって表現したものです。

コンプライアンス標準は、階層構造内の次の各要素で構成されています(図45-9を参照)。

- コンプライアンス標準ルール

- ネストしたルール・フォルダおよび個別コンプライアンス標準ルールを含めることができるルール・フォルダ。
ルール・フォルダは、コンプライアンス標準ルールを含む階層構造です。ルール・フォルダには、同じレベルの兄弟に対するルール・フォルダの重要性を示す重要度属性があります。この重要度は、他の兄弟ルール・フォルダからロールアップされているコンプライアンス・スコアの算出時に考慮されます。特定のルール・フォルダでは発生するテストが複数になる可能性がありますが、この方法で、特定のテストを他のテストより大きく重み付けできます。

- 含まれているコンプライアンス標準。コンプライアンス標準には、他のコンプライアンス標準を含めることができます。

図45-9 コンプライアンス標準定義

コンプライアンス標準で実行可能な操作

- 業界全般の標準を表すことが可能。コンプライアンス標準は、単一のターゲット・タイプに適用可能です。

- 参照構成または認定構成として使用可能

- 企業のベスト・プラクティスを記述したコンプライアンス標準のルールの集合とすることが可能

たとえば、ターゲットがコンプライアンス標準に準拠していない場合、そのターゲットにはコンプライアンス標準へのコンプライアンスがないということになります。

コンプライアンス標準へのアクセス

即時利用可能なコンプライアンス標準(Oracleが提供するものを含む)は、コンプライアンス標準ライブラリ・ページの「コンプライアンス標準」で使用できます。このページにアクセスするには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準」タブをクリックします。

コンプライアンス標準に関連するコンプライアンス標準ルールを表示するには、コンプライアンス標準の名前をクリックし、「詳細を表示」をクリックします。「コンプライアンス標準詳細」ページが表示されたら、ページの左上にある標準の名前を右クリックし、「縮小」、「下をすべて開く」または「下をすべて閉じる」のいずれかを選択します。

注意: Oracleにより定義されたコンプライアンス標準は変更できません。ただし、類似作成機能を使用して、Oracle提供の標準に類似した標準を作成することはできます。

コンプライアンス標準の一般的な使用上の注意

既存のコンプライアンス標準の上書きチェック・ボックスを選択して、既存のコンプライアンス標準をオーバーライドできます。この結果、コンプライアンス標準の評価時に、コンプライアンス標準が1つ以上のターゲットに関連付けられていることが必要になります。

- リポジトリ・コンプライアンス標準の場合、評価は、管理リポジトリ内のターゲットから収集されたデータに基づいて標準がこのターゲットに関連付けられた後に開始されます。

- WebLogic Serverコンプライアンス標準の場合、評価は、管理エージェント側の標準メトリックがリフレッシュされた後に行われます。Oracle WebLogicドメイン、Oracle WebLogic Java EEサーバーおよびOracle WebLogicクラスタの各ターゲットの場合、リフレッシュは24時間ごとに1回行われます。

- リアルタイム監視コンプライアンス標準の場合、管理エージェントでの監視は、コンプライアンス標準がターゲットに関連付けられる際に行われます。監視バンドルに非認証の監視が少なくとも1つ含まれると、違反が発生します。

リポジトリ・ルール固有の使用上の注意

コンプライアンス標準ルールのXML定義でWHERE句を手動で入力する場合、有効なXMLドキュメントを作成するには、<(より小さい)記号を&lt;と表現する必要があります。次に例を示します。

<WhereClause>:status &lt; 100</WhereClause>

監査で使用するためのコンプライアンス標準の設定方法の例

監査者が、データベース・ターゲットがコンプライアンス・フレームワークに準拠していることを検証するには、Cloud Control構造が定義されている必要があります。この構造を指定する手順は次のとおりです。

1. スーパー管理者が、コンプライアンス作成者、IT管理者、コンプライアンス監査者という3つのCloud Controlユーザーを作成します。

2. スーパー管理者が、コンプライアンス作成者とIT管理者に適したロールおよび権限を割り当てます。

3. スーパー管理者が、IT管理者とコンプライアンス監査者に同じターゲット権限を割り当てます。

4. コンプライアンス作成者がCloud Controlにログインし、Oracle提供のコンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールを表示します。
次に、適切なコンプライアンス標準ルールを有効化および無効化し、新規コンプライアンス標準ルールを作成します。

5. IT管理者が、Cloud Controlにログインし、ターゲット権限のあるターゲットを適切なコンプライアンス標準に関連付けます。

6. IT管理者が、特定のターゲットのコンプライアンス・フレームワーク、コンプライアンス標準およびコンプライアンス標準ルールの適切な構成パラメータおよび設定を設定します。
次に、このターゲットから監視テンプレートを作成し、コンプライアンス標準が必要な、権限のある他のターゲットにこれを適用します。

7. コンプライアンス監査者が、Cloud Controlにログインし、コンプライアンス・ダッシュボード、および表示権限のあるエンタープライズ・レベルと各ターゲット・レベルの違反およびエラーを表示します。
次に、違反およびエラーを修正するのに必要なアクションを実行します。

45.4.4 コンプライアンス標準での操作

コンプライアンス標準で次の操作を実行できます。

- コンプライアンス標準の作成

- コンプライアンス標準の類似作成

- コンプライアンス標準の編集

- コンプライアンス標準の削除

- コンプライアンス標準のエクスポート

- コンプライアンス標準のインポート

- コンプライアンス標準の参照

- コンプライアンス標準の検索

次の各項では、これらの操作について説明します。

注意: コンプライアンス標準に対する操作を実行する前に、必要な権限があることを確認します。たとえば、コンプライアンス標準を作成する場合、コンプライアンス標準の定義時に含めるコンプライアンス標準ルールへのアクセス権限を持っていることを確認します。(45.1.3項を参照。)

45.4.4.1 コンプライアンス標準の作成

Oracleデータベースのセキュリティ構成など、Oracle提供のコンプライアンス標準を使用することも、独自の基準を作成することもできます。

コンプライアンス標準を作成する前に、コンプライアンス標準およびコンプライアンス標準ルールは、コンプライアンス標準によって参照され、管理リポジトリで定義されていることを確認します。

コンプライアンス標準を作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準」タブをクリックします。

3. 「作成」ボタンをクリックします。名前、作成者、標準を適用可能なターゲット・タイプおよび標準タイプの入力を求められます。標準タイプは次のとおりです。

- リポジトリ

- WebLogic Serverの署名

- リアルタイム・モニタリング

- エージェント側

「続行」をクリックします。

4. 結果の「プロパティ」タブで、プロパティ値を入力します。
「追加」をクリックして、この基準を識別するキーワードを追加することも、既存のキーワードを使用することもできます。

5. コンプライアンス標準をさらに定義するには、ページの左上にあるコンプライアンス標準の名前を右クリックします。このメニューから、ルール・フォルダを作成し、ルールおよび組み込まれているコンプライアンス標準を追加できます。
ルール・フォルダを使用して、選択したルール・フォルダに対して評価されたターゲットおよび選択したルール・フォルダに評価されたコンプライアンス標準ルールによって分類された、結果のサマリーを表示できます。

6. 「保存」をクリックします。

コンプライアンス標準を定義したら、標準をターゲットに関連付け、ターゲットのタイプ固有の設定を定義します。

1. コンプライアンス標準ライブラリ・ページで、正しいコンプライアンス標準がハイライトされていることを確認します。

2. ターゲットの関連付けボタンをクリックします。

3. コンプライアンス標準に対するターゲットの関連付けページで、「追加」をクリックし、標準に対して評価するターゲットを選択します。

4. 「検索と選択: ターゲット」ポップアップで、適切なターゲットを選択します。

5. 「選択」をクリックします。

ターゲットをコンプライアンス標準に関連付けたら、ターゲットに関連付けられたパラメータを編集できます。

1. コンプライアンス標準に対するターゲットの関連付けページで、「編集」をクリックします。

2. コンプライアンス標準パラメータのカスタマイズ・ページで、必要に応じてパラメータを変更します。

注意:
ターゲットのホームページからコンプライアンス標準をターゲットに関連付けることもできます。ターゲットのホームページの左上で、ターゲットの名前を右クリックします。表示されたメニューで、「コンプライアンス」、「標準アソシエーション」の順に選択します。

別のコンプライアンス標準へのコンプライアンス標準の組込み

コンプライアンス標準を含めるページを使用して、1つ以上のコンプライアンス標準を選択し、コンプライアンス標準に組み込みます。このリストは、コンプライアンス標準のターゲット・タイプで事前にフィルタ処理されます。

別のコンプライアンス標準へのコンプライアンス標準の組込みの手順:

1. コンプライアンス標準ライブラリ・ページで、別のコンプライアンス標準を追加するコンプライアンス標準をハイライトします。

2. 「編集」ボタンをクリックします。

3. 「プロパティ」ページで、ページの左上にあるノードを右クリックします。

4. 表示されたメニューで、「標準の追加」を選択します。

5. 含めるコンプライアンス標準を選択します。「OK」をクリックします。
別の最上位コンプライアンス標準内にコンプライアンス標準を含める場合、含める標準は、最上位コンプライアンス標準と同じターゲット・タイプである必要があります。コンポジット・ターゲット・タイプの場合、最上位標準のコンポジット・ターゲット・タイプのメンバー・ターゲット・タイプの1つが最上位コンポジット・ターゲット・タイプ内のメンバー・ターゲット・タイプです。

ルート・コンプライアンス標準は、(コンポジット・ターゲット・タイプの)ルート・ターゲットに関連付けられます。コンプライアンス標準は、同じ適切なターゲット・タイプおよびターゲット・フィルタ基準のメンバー・ターゲットに関連付けられます。

6. プロパティ・ページで、含めたコンプライアンス標準の「重要度」を選択します。「保存」をクリックします。

7. コンプライアンス標準が含まれた後、ルート・コンプライアンス標準をハイライトします。プロパティ・ページにパラメータのセットが表示されます。
パラメータは、コンプライアンス標準に含まれる1つ以上のコンプライアンス標準ルールで使用できる変数です。コンプライアンス標準ルールがパラメータを参照している場合、コンプライアンス標準ルールの評価時にパラメータが実際の値に置き換えられます。この場合、コンプライアンス標準のカスタマイズがサポートされているパラメータを使用しています。

使用上の注意

- コンプライアンス標準は階層的であるため、ツリー内の上位ノードはルート・ノードと呼ばれます。

- コンプライアンス標準を作成すると、バージョンは1になります。

- ライフサイクル・ステータスのデフォルトは開発です。これを「本番」に一度のみ更新できます。本番から開発には変更できません。

- 開発
コンプライアンス標準が開発中で、定義された作業はまだ進行中であることを示します。開発モードの間、コンプライアンス標準の完全な編集およびコンプライアンス標準の削除など、コンプライアンス標準のすべての管理機能がサポートされます。ただし、コンプライアンス標準が開発モードの間、その結果は、「コンプライアンス結果」内、およびターゲットや「Cloud Control」ホームページには表示されません。

- 本番
コンプライアンス標準が承認され、本番の品質を持つことを示します。コンプライアンス標準が本番モードの場合、本番ルールへの参照を追加でき、ルールへの参照のみをコンプライアンス標準から削除できるなど、編集機能が制限されます。コンプライアンス標準の表示およびコンプライアンス標準の削除など、他のすべての管理機能はサポートされます。本番のコンプライアンス標準の結果は、ターゲットとコンソールのホームページ、およびコンプライアンス・ダッシュボードに表示されます。本番のコンプライアンス標準は、本番のコンプライアンス標準および本番のコンプライアンス標準ルールのみを参照できます。

本番モードに変更すると、その結果はコンプライアンス・ダッシュボード、ターゲット・ホームページおよび「Cloud Control」ホームページにロールアップされます。本番のコンプライアンス標準は、他の本番のコンプライアンス標準および本番のコンプライアンス標準ルールのみを参照できます。本番のコンプライアンス標準を編集して、本番のコンプライアンス標準および本番のコンプライアンス標準ルールへの参照のみを追加および削除できます。

45.4.4.2 コンプライアンス標準の類似作成

別のコンプライアンス標準に類似したコンプライアンス標準を作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準」タブをクリックします。

3. 「類似作成」ボタンをクリックします。

4. 必要に応じて、フィールドをカスタマイズします。
名前は既存のコンプライアンス標準とは異なる必要があります。

5. 「保存」をクリックします。

45.4.4.3 コンプライアンス標準の編集

既存のコンプライアンス標準ルール設定を編集して、コンプライアンス標準をカスタマイズできます。コンプライアンス・スコア計算に追加されたルールの重要度の変更、テンプレートのオーバーライドの回避、デフォルトのパラメータ値のオーバーライド(可能な場合)、およびコンプライアンス標準ルールの評価からのオブジェクトの除外(可能な場合)が可能です。

注意: Oracle提供のコンプライアンス標準、つまり、Oracleが定義するコンプライアンス標準は編集できません。

コンプライアンス標準を編集するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準」タブをクリックします。

3. 編集する基準をハイライト表示し、「編集」ボタンをクリックします。

4. 必要に応じて、パラメータを更新します。

5. 「保存」をクリックします。

45.4.4.4 コンプライアンス標準の削除

コンプライアンス標準を削除する前に、コンプライアンス標準がコンプライアンス・フレームワークによって使用されていないことを確認します。すべてのコンプライアンス・フレームワーク内のコンプライアンス標準に対する任意の参照を削除する必要があります。

注意: Oracle提供のコンプライアンス標準、つまり、Oracleが提供するコンプライアンス標準は削除できません。

コンプライアンス標準を削除するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準」タブをクリックします。

3. 削除するコンプライアンス標準をハイライト表示し、「削除」ボタンをクリックします。

4. 「OK」をクリックして、基準を削除するかどうかを確認します。

45.4.4.5 コンプライアンス標準のエクスポート

エクスポート機能は、管理リポジトリおよびCloud Controlインスタンス間でユーザー定義のコンプライアンス標準定義をトランスポートするためのメカニズムです。エクスポートによって、オペレーティング・システム・ファイルに定義を格納します。エクスポートしたコンプライアンス標準定義は、XMLフォーマットであるため、Oracleコンプライアンス標準定義(XSD)フォーマットに準拠しています。コンプライアンス標準の定義を変更でき、生成されたコンプライアンス標準定義を別の管理リポジトリに再インポートできます。

コンプライアンス標準をエクスポートする前に、エクスポートするコンプライアンス標準へのアクセス権限を持っていることを確認します。

コンプライアンス標準をエクスポートするには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準」タブをクリックします。

3. エクスポートする基準をハイライト表示します。

4. 「アクション」メニューから、「エクスポート」を選択します。

5. 基準定義をエクスポートするファイル名を指定します。リーフ・レベルのルールおよびコンプライアンス標準がエクスポートされます。

6. コンプライアンス標準のXML表現が生成されます。このファイルは、指定したディレクトリ内にあります。

45.4.4.6 コンプライアンス標準のインポート

インポート機能では、単一のユーザー定義のコンプライアンス標準、またはユーザー定義のコンプライアンス標準のリストの定義が含まれている、XMLベースのコンプライアンス標準定義ファイルをアップロードします。このアップロードによって、ユーザー定義のコンプライアンス標準またはユーザー定義のコンプライアンス標準のリストが新規作成されます。このコンプライアンス標準は、以前にエクスポートされたものである必要があります。

コンプライアンス標準のXML定義は、「ユーザー定義のコンプライアンス標準のXMLスキーマ定義」に定義されているコンプライアンス標準のXMLスキーマ定義(XSD)に準拠している必要があります。

コンプライアンス標準をインポートする前に、インポートするコンプライアンス標準がファイルに定義されていることを確認します。このファイルには、Cloud Controlにアクセスするために使用しているブラウザからローカルにアクセスできる必要があります。また、インポートするコンプライアンス標準定義XMLファイルへのアクセス権限を持っていることも確認します。

コンプライアンス標準をインポートするには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準」タブをクリックします。

3. 「アクション」メニューから、「インポート」を選択します。

4. コンプライアンス・フレームワーク定義(コンプライアンス・フレームワークXSDに従う)をインポートするファイル名を指定します。コンプライアンス・フレームワーク定義がすでに存在する場合に既存の定義をオーバーライドするかどうかを指定します。参照コンテンツもインポートするかどうかを指定します。

5. 「OK」をクリックします。

既存のコンプライアンス標準の上書きチェック・ボックスを選択して、既存のコンプライアンス標準をオーバーライドできます。結果は次のようになります。

- コンプライアンス標準をオーバーライドする場合、オーバーライドによって、そのコンプライアンス標準の評価結果のみでなく、すべてのターゲットおよびテンプレートの関連付けも削除されます。

- 上書きされたコンプライアンス標準がコンプライアンス・フレームワークの一部である場合、コンプライアンス・フレームワーク内でコンプライアンス標準が更新されます。ただし、コンプライアンス・フレームワーク内のそのコンプライアンス標準の評価結果は無効化されます。

45.4.4.7 コンプライアンス標準の参照

コンプライアンス標準を参照するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準」タブをクリックします。

3. 特定の基準の詳細を表示するには、基準をハイライト表示し、「詳細を表示」をクリックします。

45.4.4.8 コンプライアンス標準の検索

コンプライアンス標準を検索するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準」タブをクリックします。

3. ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。

4. 「検索」をクリックします。

45.4.4.9 Browsing コンプライアンス標準の評価結果の参照

コンプライアンス標準の評価結果を参照するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. 「コンプライアンス標準」タブをクリックし、「評価結果」タブをクリックします。

3. コンプライアンス標準をハイライト表示し、「詳細を表示」をクリックして、特定の基準の詳細を表示します。
結果には、次のものがあります。

- 異なるターゲットの平均コンプライアンス・スコア

- ターゲット評価(クリティカル、警告、コンプライアンス)の数

- 違反(クリティカル、警告、マイナー警告)の数

45.4.4.10 コンプライアンス標準の評価結果の検索

コンプライアンス標準の評価結果を検索するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. 「コンプライアンス標準」タブをクリックし、「評価結果」タブをクリックします。

3. ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。

4. 「検索」をクリックします。

45.4.4.11 コンプライアンス標準のエラーの参照

コンプライアンス標準の評価エラーを参照するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. 「コンプライアンス標準」タブをクリックし、「エラー」タブをクリックします。

45.4.4.12 コンプライアンス標準のエラーの検索

コンプライアンス標準のエラーを検索するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。

2. 「コンプライアンス標準」タブをクリックし、「エラー」タブをクリックします。

3. ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。

4. 「検索」をクリックします。

使用上の注意

- 評価エラー・ページには、メトリック収集の結果発生したエラー、および最後のポリシー評価中に発生したエラーが表示されます。

- 検索フィルタを使用して、指定する検索基準セットと一致する評価エラーのみを表示します。

- 「メッセージ」列のメッセージをクリックして、エラーを解決するための対策を決定します。

- まず、評価エラー・ページに、すべての評価エラーが表示されます。

- 通常、評価の結果は、前回の評価結果を上書きします。ただし、評価が失敗またはデータ・プロバイダ収集が失敗した場合は、前回の結果は上書きされず、そのまま残ります。

根本の問題が解決されると、エラーは報告されません。

検索フィルタの例

デフォルトでは、エンタープライズ構成内のすべての評価エラーが結果表に表示されます。ただし、検索基準のセットを指定し、基準と一致する評価エラーのみが結果表に表示されるように検索を実行できます。

たとえば、「ターゲット・タイプ」リストで「ホスト」、「ターゲット名」リストで「次を含む」、その隣の「ターゲット名」テキスト・フィールドで「-sun」を選択し、「実行」をクリックすると、Cloud Controlは、名前に「-sun」を含むホストのコンプライアンス標準ルールの評価エラーのみを結果表に表示します。

45.4.4.13 コンプライアンス標準のターゲットへの関連付け

コンプライアンス標準を作成したら、標準を1つ以上のターゲットに関連付けることができます。関連付けの一部として、ターゲットに関連する基準の重要度、コンプライアンス標準の評価のステータス、評価ステータスの変更理由およびしきい値などのパラメータをカスタマイズできます。

コンプライアンス標準をターゲットに関連付ける前に、コンプライアンス標準を関連付けるターゲットへのアクセス権限を持っていることを確認します。

コンプライアンス標準をターゲットに関連付けるには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準」タブをクリックします。

3. 様々なターゲットに関連付けるコンプライアンス標準をハイライト表示します。ターゲットの関連付けボタンをクリックします。

4. このコンプライアンス標準に関連付けるターゲットを選択します。「OK」をクリックします。

5. コンプライアンス標準をハイライト表示したままで、「ターゲット・タイプ設定のオーバーライド」ボタンをクリックします。

6. 必要に応じて、クリティカルのしきい値と警告のしきい値および重要度をカスタマイズします。
クリティカルのしきい値と警告のしきい値を変更することにより、コンプライアンス標準スコア・イベントを生成する方法を指定します。たとえば、実際のスコアがクリティカルのしきい値より低い場合、クリティカル・スコア・イベントが呼び出されます。

重要度を変更すると、コンプライアンス・スコアが変更される可能性があります。重要度は、階層内のコンプライアンス標準の重要度を示します。

7. 「OK」をクリックします。

ターゲットに対するコンプライアンス標準の評価をさらにカスタマイズするために、コンプライアンス標準パラメータ(重要度、クリティカルのしきい値および警告のしきい値)を変更できます。コンプライアンス標準内で使用されたコンプライアンス標準ルールで、カスタマイズを行うこともできます。たとえば、「セキュア・ポート」コンプライアンス標準ルールの場合、DFLT_PORTはオーバーライド・パラメータです。ポートのデフォルト値を変更できます。オブジェクトを評価から除外することもできます(たとえば、特定のポートを評価から除外するなど)。

注意: リアルタイム監視の場合、ファセット・パターンで使用されているパラメータを変更できます。自動変更管理のリコンシリエーション設定を変更することもできます。

クリティカルのしきい値と警告のしきい値を変更することにより、コンプライアンス標準スコア・イベントを生成する方法を指定します。たとえば、実際のスコアがクリティカルのしきい値より低い場合、クリティカル・スコア・イベントが呼び出されます。

ベスト・プラクティス

コンプライアンス・アソシエーションの実行方法には、テストと編集に対するものと、本番と一括アソシエーションに対するものの2つがあります。

- 標準/ターゲットと標準ルール、またはルール・フォルダ/ターゲット・アソシエーション設定のテストと編集目的の場合、この項での前述のようにターゲットとコンプライアンス標準を関連付けます。
コンプライアンスのUIを使用して次のことができます。

- アソシエーションをテストし、テストが完了したら削除します。

- 重要度、評価ステータスおよびしきい値についてアソシエーションを編集します。
注意: アソシエーションは、管理グループ」ページおよび「テンプレート・コレクション」ページを使用して編集できません。

- 本番および一括アソシエーションの場合、管理グループ」ページおよび「テンプレート・コレクション」ページを使用してターゲットを関連付けます。
「設定」メニューから「ターゲットの追加」を選択し、「管理グループ」を選択します。「アソシエーション」タブをクリックします。

階層内の各管理グループは、メンバーシップ基準によって定義されているため、ターゲットはグループのメンバーシップ基準を満たす場合にのみグループに追加されます。したがって、ターゲットがグループに正常に追加されると、そのグループの適切なコンプライアンス標準に自動的に関連付けられます。これによって、ターゲットの多数のコンプライアンス標準への関連付けが容易になります。

45.4.4.14 リアルタイム監視コンプライアンス標準の警告の表示

リアルタイム監視コンプライアンス標準をターゲットに関連付ける場合、ターゲットでリアルタイム監視を有効化するための設定手順が実行されていなかったり、構成に不整合がある場合があります。この場合、「ターゲットの関連付け」画面に警告が表示されます。この画面にアクセスするには、コンプライアンス標準を選択し、「ターゲットの関連付け」ボタンを選択します。警告が存在する場合、ターゲット・アソシエーションの上にあるリンクに警告アイコンが表示されます。このリンクをクリックすると、このコンプライアンス標準に関する現在の警告がすべてリストされた画面が表示されます。

監視対象のホスト/ターゲット上の構成問題を解決したり、ルール/ファセットのコンテンツを修正することにより、警告はすべて修正できます。根本の問題が解決されると、これらの警告は自動的にクリアされます。

この警告のリストは、「リアルタイム監視」ページ(「Enterprise」メニューから「コンプライアンス」、「リアルタイム監視」の順に選択)から入手することもできます。ここでは、監視を参照するために3つのタイプのレポートの1つを選択できます。画面の下半分には、リアルタイム監視に関連するすべてのターゲットおよびコンプライアンス標準に対してアクティブな警告がすべて表示されます。

45.4.4.15 セキュリティ・メトリックの有効化

セキュリティ・コレクションはデフォルトでは無効であるため、セキュリティ・コンプライアンス標準およびレポートなどのセキュリティ機能を使用する前に有効にする必要があります。セキュリティ・メトリックを有効にするには、次の手順に従います。

1. 「エンタープライズ」メニューから、「監視」、「監視テンプレート」の順に選択します。

2. 「検索」領域で「オラクル社提供のテンプレートとオラクル社認定のテンプレートを表示」を選択し、「実行」をクリックします。

3. 「オラクル社認定-データベース・セキュリティ構成メトリックの有効化」を選択し、「適用」をクリックします。

4. 「監視テンプレートオラクル社認定-データベース・セキュリティ構成メトリックの有効化の適用: 一般」ページで「追加」をクリックします。

5. 「検索と選択: ターゲット」ページで目的のデータベース・インスタンスを選択し、「選択」をクリックします。

6. 「監視テンプレートオラクル社認定-データベース・セキュリティ構成メトリックの有効化の適用: 一般」ページの「コピー先ターゲット」リージョンで、目的のデータベース・インスタンスを選択し、「OK」をクリックします。

「OK」をクリックすると、「監視テンプレート」ページに確認メッセージが表示されます。

45.4.4.16 コンプライアンス標準の作成時の考慮事項

コンプライアンス標準は、1つ以上のコンプライアンス標準ルールを参照します。コンプライアンス標準を作成する際には、標準は、1つ以上の関連するコンプライアンス・フレームワークに適切にマッピングできるほど十分に詳細である必要があります。たとえば、Oracleの汎用コンプライアンス・フレームワークに存在する、次のようなコンプライアンス・フレームワーク構造を考えてみます。

- 変更および構成管理(コンプライアンス・フレームワーク・サブグループ)

- データベース変更(コンプライアンス・フレームワーク・サブグループ)

- Oracle Databaseを構成するためのベスト・プラクティス(コンプライアンス標準)

- Oracle RACデータベースを構成するためのベスト・プラクティス(コンプライアンス標準)

- Oracleプラガブル・データベースを構成するためのベスト・プラクティス(コンプライアンス標準)

このコンプライアンス・フレームワーク構造の一部にマップされる必要がある多くのコンプライアンス標準が存在し、それぞれに、この特定の要件に対処するための独自のルールがあります。ある標準は、構成設定が正しく設定されていることをチェックします。別の標準は、構成設定が変更されたかどうかをリアルタイムでチェックするために使用されます。

この例では、データベース変更コンプライアンス・フレームワーク・サブグループは、多くの異なるタイプのターゲットに関連しています。すべてのOracle Database、Oracle RACデータベースおよびOracleプラガブル・データベースには、すべてが保護される必要がある独自のタイプの構成があります。これらのターゲット固有の構成を監視するために作成されたすべての標準は、同じデータベース変更サブグループにマップされます。

コンプライアンス標準が、既存および将来のコンプライアンス・フレームワークにマップできるように詳細な方法で構造化される場合、ルール内の違反をロールアップし、コンプライアンス・フレームワークのスコアに正しく影響を与えることができます。

45.4.5 コンプライアンス標準ルール・フォルダについて

ルール・フォルダは、コンプライアンス標準内の類似したコンプライアンス標準ルールのグループ化に使用されるオプションの階層構造です。コンプライアンス標準に個別コンプライアンス標準ルールを追加したり、標準内に多数のルールが存在する場合はこれらをグループ化できます。コンプライアンス標準内の重要度設定がそれぞれ異なる複数のルール・フォルダに同じコンプライアンス標準ルールを追加できます。コンプライアンス標準内に、ルール・フォルダをネストできます。

ルール・フォルダには、同じレベルの兄弟に対するルール・フォルダの重要性を示す重要度属性があります。この重要度は、他の兄弟ルール・フォルダからロールアップされているコンプライアンス・スコアの算出時に考慮されます。特定のルール・フォルダでは発生するテストが複数になる可能性がありますが、この方法で、特定のテストを他のテストより大きく重み付けできます。

次の各トピックでは、コンプライアンス標準ルール・フォルダについて説明します。

- ルール・フォルダの作成

- コンプライアンス標準内のルール・フォルダの管理

45.4.5.1 ルール・フォルダの作成

ルール・フォルダを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準」タブをクリックします。

3. コンプライアンス標準ライブラリ・ページで、コンプライアンス標準をハイライトし、「編集」をクリックします。

4. プロパティページで、コンプライアンス標準の名前を右クリックします。標準の名前は、ページの左上隅にあります。

5. 「ルール・フォルダの作成」を選択します。

6. フォルダの名前を入力し、「OK」をクリックします。

7. 「プロパティ」ページで、説明、参照URLおよび重要度を指定します。重要度に関する詳細は、第45.2.9項を参照してください。

45.4.5.2 コンプライアンス標準内のルール・フォルダの管理

フォルダを作成し、フォルダにコンプライアンス標準ルールを移入したら、フォルダについて次のアクションを実行できます。

- ツリー内のルール・フォルダ・ノード、ルール参照ノード、およびコンプライアンス標準参照ノードを並べ替えるか、これらのノードを削除して、ツリー構造を編集します。

- 任意のノード(最上位レベルのコンプライアンス標準ノードを除く)・オブジェクトを選択し、コンテキスト・メニューから「削除」メニュー・アイテムをクリックします。削除オプションは、ルート・ノードでは使用できません。複数のオブジェクトを選択し、「削除」をクリックして、複数のノードを削除します。

45.4.6 コンプライアンス標準ルールについて

コンプライアンス標準ルールは、構成データの変更がコンプライアンスに影響するかどうかを決定するためのテストです。テストの結果に基づいて、コンプライアンス・スコアが計算されます。これらのルール・コンプライアンス・スコアがロールアップされてコンプライアンス標準スコアが計算されることにより、このスコアをコンプライアンス・フレームワーク・スコアとともにロールアップおよびレポートできるようになります。

コンプライアンス標準ルールのタイプ

3つのタイプのコンプライアンス標準ルールがあります。

- リポジトリ・ルール
管理リポジトリのメトリック収集データに対してチェックを実行するために使用されます。

1つまたは複数のターゲットの構成状態をチェックするのに使用します。構成アイテムが実際に所定の状態を満たすと判断され、ルールのテストが違反を特定するのに失敗した場合、ルールはコンプライアンスと言います。それ以外の場合、ルールに1つ以上の違反がある場合、ルールは非コンプライアンスと言います。コンプライアンス標準ルールのテスト条件によって評価されるデータソースは、Cloud Control管理リポジトリに対する問合せに基づきます。コンプライアンス標準ルールのテスト条件は、基本的なメトリック/問合せの列の値またはSQL式またはPL/SQL関数に基づくしきい値の条件を使用して実装できます。ルールを使用するには、1つ以上のコンプライアンス標準にルールを関連付ける必要があります。これにより、コンプライアンス標準は1つ以上のターゲットに関連付けられます。この結果、このルールをこれらのターゲットに対して効率的に評価できるようになります。

- WebLogic Server署名ルール
WebLogic Server署名ルールでは、WebLogic Serverおよびそれらがデプロイされている環境(Java Virtual Machines(JVM)、オペレーティング・システムおよびデータベースなど)に関する情報に基づく潜在的な問題について説明します。署名ルールには、これらの製品の特定のバージョンおよびこれらの構成設定を識別できる実行可能なロジックが含まれます。

- リアルタイム監視ルール
リアルタイム監視ルールでは、ユーザーがターゲットで実行するアクションを監視します。監視可能なアクションのタイプには、ファイルの変更、プロセスの開始と停止、ユーザーのログイン/ログアウト、およびデータベースの変更が含まれます。これらのアクションによって構成が変更されたりコンプライアンスのリスクが生じる可能性があります。アクションはアクションの発生時にリアルタイムで監視として検出されるため、アクションのユーザー、プロセスおよび正確な時間を把握できます。

- エージェント側のルール
エージェントの構成の問題の検出に使用します。これにより、Security Technical Implementation Guide (STIG)のセキュリティ仕様の実装が可能になります。エージェント側のルールでは、基礎となる構成拡張ターゲット用に収集された結果データに基づく、ターゲットの違反が生成されます。

- 手動ルール
実行する必要があるが、自動化できないチェックがあります。たとえば、一般的なセキュリティ・チェックは、データ・センターへのセキュアなアクセスを確保することです。これらのタイプのチェックは、コンプライアンス・フレームワークで考慮されるようになりました。

標準がターゲットに関連付けられている場合、すべての手動ルールにはそれぞれ1つの違反があります。ユーザーは、ルールのポジティブ・ステータスを手動で確認する必要があります。これは、いずれかのユーザーが、タスクを自分で実行したことを検証したことを意味します。ソフトウェアは、手動チェックの違反を報告できるように、手動チェックの違反がいつ、だれによってクリアされたかを記録します。

45.4.7 コンプライアンス標準ルールでの操作

次の各項では、コンプライアンス標準ルールで実行できる操作について説明します。

- リポジトリのコンプライアンス標準ルールの作成

- WebLogic Serverの署名のコンプライアンス標準ルールの作成

- リアルタイム監視のコンプライアンス標準ルールの作成

- エージェント側ルールの作成

- 手動ルールの作成

- コンプライアンス標準ルールの類似作成

- コンプライアンス標準ルールの編集

- コンプライアンス標準ルールの削除

- コンプライアンス標準ルールのエクスポート

- コンプライアンス標準ルールのインポート

- コンプライアンス標準ルールの参照

- コンプライアンス標準ルールの検索

注意: コンプライアンス標準ルールに対する操作を実行する前に、必要な権限があることを確認します。(第45.1.3項「コンプライアンス機能の使用に必要なロールおよび権限」を参照してください。)

45.4.7.1 リポジトリのコンプライアンス標準ルールの作成

収集された構成データに基づいてターゲットが必要な構成状態にあることを確認するためのリポジトリのコンプライアンス標準ルールを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準ルール」タブをクリックします。

3. 「作成」ボタンをクリックします。

4. 「ルールの作成」ポップアップで、タイプとして「リポジトリ・ルール」を選択します。

5. 「続行」をクリックします。

6. 次の画面で、ルールの複数の主要属性を入力するよう求められます。

- ルール名
一意のルール名を入力します。

- コンプライアンス・ルールの状態
このルールの状態が開発と本番のどちらであるかを設定します。開発とは、ルールがまだ定義またはチューニング中であり、ターゲットで使用する準備がまだ整っていないことを意味します。ルールを本番に昇格した後、ルールを開発に戻すことはできません。

- 重大度
ルールには、重大度レベルがあり、クリティカル(ルールが違反している場合の深刻な問題)、警告(違反している場合の深刻ではない問題)、またはマイナー警告(違反している場合のマイナーな問題)のいずれかです。重大度は、このルールがコンプライアンス標準に追加されるときにこのルールに設定される可能性がある重要度とともにコンプライアンス・スコアに影響します。

- 適用可能対象
このルールが適用されるターゲット・タイプ。

- ターゲット・プロパティ・フィルタ
このルールがコンプライアンス標準に関連付けられているときにこのルールを適用可能なターゲットを決定する特定のターゲット・プロパティを指定できます。このようなプロパティには、オペレーティング・システム、ターゲット・ライフサイクルの状態、バージョンおよびプラットフォームがあります。たとえば、Linux OSなど、このルールにターゲット・プロパティ・フィルタを指定すると、このルールはLinuxオペレーティング・システムに対してのみ適用可能になります。

- 説明
ルールの説明

- 論理
このルールの確認対象、およびこのルールの違反による影響を表すテキスト。

- 推奨
違反が発生した際の問題の修正方法を表す推奨テキスト。

- 参照URL
コンプライアンス制御を詳細に説明するドキュメントへのURL。多くの場合、これらのドキュメントはコンテンツ管理システムに格納できます。

- キーワード
キーワードは、データを様々なレポートに編成する方法を制御できるようルールに割り当てることができます。

7. 「次へ」をクリックします。

8. 次の画面で、Cloud Control管理リポジトリに対して実行するSQL問合せを指定する必要があります。SQL問合せを直接入力することも、「モデル問合せ」ボタンをクリックし、問合せのコンテンツの選択方法が順を追って説明される画面にアクセスすることもできます。

9. コンプライアンス・メッセージおよび非コンプライアンス・メッセージを入力します。これらは、評価に関して表示されるメッセージです。違反が発生すると、非コンプライアンス・メッセージが、インシデント管理機能下におけるイベントを説明する文字列になります。

10. 「推奨」を入力します。推奨テキストは、違反が発生した際の問題の修正方法を表します。

11. 「次へ」をクリックします。

12. 次の画面には、標準結果の一部としてこの問合せから返される列が表示されます。各列の表示名は必要に応じて変更できます。

13. この画面では、違反を検索するために返された問合せ結果に対してチェックする条件も設定する必要があります。条件チェックは、列名および値の比較演算子に基づく単純なものにすることができます。または、パラメータ名を指定し、評価問合せに追加するWHERE句を指定することにより、SQL条件を構成することもできます。

14. SQL条件を使用する場合、「WHERE句の検証」ボタンをクリックすると、条件に問題があるかどうかをチェックできます。

15. 「次へ」をクリックします。

16. 次の画面では、ルールをテストできます。使用環境内のターゲットを選択し、「テストの実行」ボタンをクリックできます。ルールに関する問題が表示され、ルールを保存する前にこれらを解決できます。

17. 「次へ」をクリックします。

18. 最終ページでは、このルールに対して構成したすべての内容を確認できます。内容がすべて正しいことを確認し、「終了」ボタンをクリックしてルールを保存します。

リポジトリ・ルールに関する追加の注意事項

- ルールはすべてグローバル・ルール・ライブラリに表示され、すべてのユーザーが参照できます。

- コンプライアンス基準ルールの作成後、そのルールは自動的に評価されません。ルールは、使用する前にコンプライアンス標準に関連付ける必要があります。コンプライアンス標準が1つ以上のターゲットに関連付けられている場合のみ、ルールの評価が行われます。ルールを直接評価することはできません。

- 1つのルールを複数のコンプライアンス標準に関連付けることができます。

- このルールが関連付けられているコンプライアンス標準を介してルールの様々な属性をカスタマイズできます。これらのカスタマイズは「コンプライアンス標準」画面で行います。コンプライアンス標準ごとにカスタマイズできるこれらの属性の1つに、この標準に関連するルールの重要度があります。

- ユーザー定義コンプライアンス基準ルールは特権ユーザーによって定義されるため、コンプライアンス基準ルールを変更できるのは特権ユーザーのみです。違反結果は、すべてのユーザーが表示できます。

- このユーザー定義のコンプライアンス標準ルールを他の特権ユーザーと共有するには、これらのユーザーが管理リポジトリにコンプライアンス標準ルールをインポートできるように、(エクスポート機能を使用して)XMLスキーマ定義を指定します。

- 「説明」、「影響」および「推奨」情報の参照中のスクロールを最小限に抑えるには、1行当たりのテキストを50文字に制限します。50を超える文字数が必要な場合は、改行してテキストを続けます。

- コンプライアンス標準ルール・ウィザード内の各ページに関する具体的な手順の詳細は、コンテキスト依存ヘルプを参照してください。

- コンプライアンス標準ルールのXML定義でWHERE句を手動で入力する場合、有効なXMLドキュメントを作成するには、<(より小さい)記号を&lt;と表現する必要があります。次に例を示します。

<WhereClause>:status &lt; 100</WhereClause>

45.4.7.2 WebLogic Serverの署名のコンプライアンス標準ルールの作成

一般に知れわたった思いがけない危険やベスト・プラクティスに関する詳細な知識に主に基づいて、WebLogicのインストールにおいて発生すると確認されているコンプライアンス違反を発見するために、数百の即時利用可能なWebLogic Serverの署名ルールが設計されています。また、実行するチェックを拡張するために独自のルールを作成することもできます。

署名は、WebLogicのインストールにおける潜在的な問題を説明しています。カテゴリ化のメタデータ、ユーザー読取り可能な問題の記述、および問題がターゲットに存在するがとうかを評価するXQuery式で構成されます。

WLS署名ルールは管理エージェント側ルールの1つであり、関連付けられたターゲットに対して署名定義をチェックし、その署名で定義される問題が存在することを検証します。WebLogicサーバーのターゲットには、WLSドメイン、WLSクラスタ、WebLogic管理対象サーバーがあります。最初の2つはコンポジット・ターゲット・タイプであり、単純なWebLogicサーバー・ターゲットのインスタンスの論理グループです。有意な違反結果を得るには、ドメインまたはクラスタの全体に対してルールを評価する必要があります。

WLS署名ルールは、他のコンプライアンス・ルールと同様、コンプライアンス標準にグループ化されます。コンプライアンス標準は、重大度や処置など署名のメタデータに基づく論理グループです。

特定の構成設定が既知の良質な構成要件を満たしているかどうかを評価するためにWebLogic Serverの署名のコンプライアンス標準ルールを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準ルール」タブをクリックします。

3. 「作成」ボタンをクリックします。

4. 「ルールの作成」ポップアップで、「WebLogic Serverの署名」ルール・タイプを選択します。

5. 「続行」をクリックします。

6. 次の画面で、ルールの複数の主要属性を入力するよう求められます。

- ルール名
一意のルール名を入力します。

- コンプライアンス・ルールの状態
このルールの状態が開発と本番のどちらであるかを設定します。開発とは、ルールがまだ定義またはチューニング中であり、ターゲットで使用する準備がまだ整っていないことを意味します。ルールを本番に昇格した後、ルールを開発に戻すことはできません。

- 重大度
ルールには、重大度レベルがあり、クリティカル(ルールが違反している場合の深刻な問題)、警告(違反している場合の深刻ではない問題)、またはマイナー警告(違反している場合のマイナーな問題)のいずれかです。重大度は、このルールがコンプライアンス標準に追加されるときにこのルールに設定される可能性がある重要度とともにコンプライアンス・スコアに影響します。

- 適用可能対象
このルールが適用されるターゲット・タイプ。

- ターゲット・プロパティ・フィルタ
このルールがコンプライアンス標準に関連付けられているときにこのルールを適用可能なターゲットを決定する特定のターゲット・プロパティを指定できます。このようなプロパティには、オペレーティング・システム、ターゲット・ライフサイクルの状態、バージョンおよびプラットフォームがあります。たとえば、Linux OSなど、このルールにターゲット・プロパティ・フィルタを指定すると、このルールはLinuxオペレーティング・システムに対してのみ適用可能になります。

- 説明
ルールの説明

- 論理
このルールの確認対象、およびこのルールの違反による影響を表すテキスト。

- 推奨
違反が発生した際の問題の修正方法を表す推奨テキスト。

- 参照URL
コンプライアンス制御を詳細に説明するドキュメントへのURL。多くの場合、これらのドキュメントはコンテンツ管理システムに格納できます。

- キーワード
キーワードは、データを様々なレポートに編成する方法を制御できるようルールに割り当てることができます。

7. 「次へ」をクリックします。

8. 次の画面で、署名の定義ファイルを指定する方法を選択します。ファイルのアップロードによってロードすることも、UIにテキストを直接入力することもできます。

9. コンプライアンス・メッセージおよび非コンプライアンス・メッセージを入力します。これらは、評価に関して表示されるメッセージです。違反が発生すると、非コンプライアンス・メッセージが、インシデント管理機能下におけるイベントを説明する文字列になります。

10. 違反とともに表示する列を選択します。これらの列は、署名定義で戻り列として定義する必要があります。

11. 「次へ」をクリックします。

12. 次の画面では、ルールをテストできます。使用環境内のターゲットを選択し、「テストの実行」ボタンをクリックできます。ルールに関する問題が表示され、ルールを保存する前にこれらを解決できます。

13. 「次へ」をクリックします。

14. 最終ページでは、このルールに対して構成したすべての内容を確認できます。内容がすべて正しいことを確認し、「終了」ボタンをクリックしてルールを保存します。

1つ以上のコンプライアンス標準に関連付けられ、これらのコンプライアンス標準がターゲットに関連付けられるまでは、新しく作成したこのルールは機能しません。この関連付けが行われると、このルールのワークフローは次のようになります。

- 標準とルールの組合せは転送され、コンプライアンスを判定するためにコンプライアンス標準およびターゲット・タイプごとに管理エージェント側で収集されたメトリックに対して評価されます。

- 評価から違反が生成されます(違反がある場合)。

- 違反はCloud Controlサーバーにアップロードされ、そこから管理リポジトリ表の違反に処理されます。

- これで、違反がコンプライアンス結果のページとコンプライアンス・ダッシュボードで表示できるようになります。

WebLogic Serverの署名の例

ルール作成ウィザードを使用すると、新規ルールを追加しやすくなりますが、WebLogic Serverの署名ルールの重要な部分は署名定義です。署名定義は、Managed Bean(MBean)のリストおよびXQuery式で構成されます。Managed Beanは、収集する構成データを表します。これは、収集するタイプおよびタイプ内での属性を定義します。また、違反があるかどうかを判断する際に考慮する属性の宣言も行います。XQuery式は、コンプライアンスに対して収集されたデータを評価する際に使用するロジックを定義します。署名定義のXMLの例は次のとおりです。

<SignatureDefinition>
<MBeanList>
<MBean scoreBase="true" mBeanType="ServerRuntime">
<AttributeName>Name</AttributeName>
<AttributeName>WeblogicVersion</AttributeName>
</MBean>
</MBeanList>
<XQueryLogic>declare function local:getServerRuntimesEqualToVersionWithPatch($targetData, $major as xs:integer,
$minor as xs:integer, $servicePack as xs:integer, $crNumber as xs:string) {
for $ServerRuntime in $targetData/DataCollection/ServerRuntime
let $weblogicVersion := fn:replace($ServerRuntime/@WeblogicVersion, &quot;WebLogic Server Temporary Patch&quot;, &quot;&quot;)
let $majorVersion :=
let $spaceParts :=  fn:tokenize(fn:substring-after($weblogicVersion, &quot;WebLogic Server &quot;), &quot; &quot;)
let $majorVersionParts := fn:tokenize($spaceParts[1], &quot;\.&quot;)
return
$majorVersionParts[1] cast as xs:integer
let $SP_MP :=
if ($majorVersion = 8) then
&quot;SP&quot;
else
if ($majorVersion &gt;= 9) then
&quot;MP&quot;
else &quot; &quot;
let $minorVersion :=
let $spaceParts := fn:tokenize(fn:substring-after($weblogicVersion, &quot;WebLogic Server &quot;), &quot; &quot;)
let $minorVersionParts := fn:tokenize($spaceParts[1], &quot;\.&quot;)
return
$minorVersionParts[2] cast as xs:integer
let $servicePackVersion :=
let $spaceParts := fn:tokenize(fn:substring-after($weblogicVersion, &quot;WebLogic Server &quot;), &quot; &quot;)
let $servicePackParts :=  fn:substring-after($spaceParts[2], $SP_MP)
return
if ($servicePackParts = &quot;&quot;) then
0
else
$servicePackParts cast as xs:integer
where $majorVersion = $major and $minorVersion = $minor and $servicePackVersion = $servicePack and
fn:contains(fn:upper-case($ServerRuntime/@WeblogicVersion),fn:upper-case($crNumber))
return
$ServerRuntime
};
for $server in local:getServerRuntimesEqualToVersionWithPatch(/,10,0,1,&quot;CR366527&quot;)
|
local:getServerRuntimesEqualToVersionWithPatch(/,10,0,0,&quot;CR366527&quot;)
return &lt;Server
Name=&quot;{fn:data($server/@Name)}&quot;/&gt;</XQueryLogic>
</SignatureDefinition>

実質的に、この定義では、すべてのランタイム・サーバーのサーバー名およびWebLogicバージョンを収集します。定義の大部分では、バージョン(メジャー・パッチとマイナー・パッチ)、サービス・パック、CR番号などの詳細が繰り返されます。サーバーに指定されたパッチ(10.0.1 CR366527または10.0.0 CR 366527)のいずれかがある場合、違反が発生し、この場合、違反で報告するサーバーの名前が返されます。そのため、ルール定義には、サーバー名の表示を説明するための列が含まれる必要があります。バージョンは、表示のコンテキストでは無関係です。アラートの表示は、どのサーバーが違反しているかについてのみ関与しています。

WebLogic Server署名ルールを使用するための重要な前提条件ステップ

監視しようとするWebLogicのバージョンに固有の必須ステップは、次のとおりです。

1. 10.3.3より前のWebLogicバージョン: v10.3.3より前のWeblogic ServerターゲットでWeblogicサーバー署名ベースのルールのデータ・コレクションを有効にするには、bea-guardian-agent.warのコピーが必要です。このwarファイルのコピーは、OMSインストールの作業ディレクトリにあります。
$T_WORK/middleware/wlserver_10.3/server/lib/bea-guardian-agent.war

2. WebLogic Server v9およびv10.0: ドメイン内のすべてのサーバーにbea-guardian-agent.warをインストールおよびデプロイします。コンテキスト・ルートは変更しないでください。Webアプリケーションのインストールの詳細は、http://<host>:<port>/console-help/doc/en-us/com/bea/wlserver/core/index.htmlを参照してください。

3. WebLogic Server v10.3以前(v10.3.2を含む): OMSインストールから各ターゲットの$WL_HOME/server/libディレクトリにwarファイルをコピーします。ターゲット・ドメイン内のすべてのサーバーを再起動します。

4. WebLogic Server v.10.3.3以降: 必要なアクションはありません。

WebLogic Server署名ルールに関する追加の注意事項

- ルールはすべてグローバル・ルール・ライブラリに表示され、すべてのユーザーが参照できます。

- コンプライアンス基準ルールの作成後、そのルールは自動的に評価されません。ルールは、使用する前にコンプライアンス標準に関連付ける必要があります。コンプライアンス標準が1つ以上のターゲットに関連付けられている場合のみ、ルールの評価が行われます。ルールを直接評価することはできません。

- 1つのルールを複数のコンプライアンス標準に関連付けることができます。

- このルールが関連付けられているコンプライアンス標準を介してルールの様々な属性をカスタマイズできます。これらのカスタマイズは「コンプライアンス標準」画面で行います。コンプライアンス標準ごとにカスタマイズできるこれらの属性の1つに、この標準に関連するルールの重要度があります。

- ユーザー定義コンプライアンス基準ルールは特権ユーザーによって定義されるため、コンプライアンス基準ルールを変更できるのは特権ユーザーのみです。違反結果は、すべてのユーザーが表示できます。

- このユーザー定義のコンプライアンス標準ルールを他の特権ユーザーと共有するには、これらのユーザーが管理リポジトリにコンプライアンス標準ルールをインポートできるように、(エクスポート機能を使用して)XMLスキーマ定義を指定します。

- 「説明」、「影響」および「推奨」情報の参照中のスクロールを最小限に抑えるには、1行当たりのテキストを50文字に制限します。50を超える文字数が必要な場合は、改行してテキストを続けます。

- コンプライアンス標準ルール・ウィザード内の各ページに関する具体的な手順の詳細は、コンテキスト依存ヘルプを参照してください。

- コンプライアンス標準ルール・ウィザード内の各ページに関する具体的な手順の詳細は、コンテキスト依存ヘルプを参照してください。

45.4.7.3 リアルタイム監視コンプライアンス標準ルールの作成

ファイル変更、ユーザー・アクセスおよびプロセス・アクティビティなど、ターゲットで発生したユーザー・アクションを監視するためのリアルタイム監視のコンプライアンス標準ルールを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準ルール」タブをクリックします。

3. 「作成」ボタンをクリックします。

4. 「ルールの作成」ポップアップで、「リアルタイム監視」タイプを選択します。

5. 「OK」をクリックします。

6. 次の画面で、ルールの複数の主要属性を入力するよう求められます。

- ルール名
一意のルール名を入力します。

- コンプライアンス・ルールの状態
このルールの状態が開発と本番のどちらであるかを設定します。開発とは、ルールがまだ定義またはチューニング中であり、ターゲットで使用する準備がまだ整っていないことを意味します。ルールを本番に昇格した後、ルールを開発に戻すことはできません。

- 重大度
ルールには、重大度レベルがあり、クリティカル(ルールが違反している場合の深刻な問題)、警告(違反している場合の深刻ではない問題)、またはマイナー警告(違反している場合のマイナーな問題)のいずれかです。重大度は、このルールがコンプライアンス標準に追加されるときにこのルールに設定される可能性がある重要度とともにコンプライアンス・スコアに影響します。

- 適用可能対象
このルールが適用されるターゲット・タイプ。

- エンティティ・タイプ
監視対象のターゲットの一部であるオブジェクトのタイプ。たとえば、オペレーティング・システム(OS)の場合、エンティティ・タイプにはOSファイル、OSプロセスまたはOSユーザーなどがあります。データベースの場合、エンティティ・タイプにはデータベース表、データベース機能、データベース・プロシージャまたはデータベース・ユーザーなどがあります。

- ターゲット・プロパティ・フィルタ
このルールがコンプライアンス標準に関連付けられているときにこのルールを適用可能なターゲットを決定する特定のターゲット・プロパティを指定できます。このようなプロパティには、オペレーティング・システム、ターゲット・ライフサイクルの状態、バージョンおよびプラットフォームがあります。たとえば、Linux OSなど、このルールにターゲット・プロパティ・フィルタを指定すると、このルールはLinuxオペレーティング・システムに対してのみ適用可能になります。

- 説明
ルールの説明

- 論理
このルールの確認対象、およびこのルールの違反による影響を表すテキスト。

- 詳細URL
コンプライアンス制御を詳細に説明するドキュメントへのURL。多くの場合、これらのドキュメントはコンテンツ管理システムに格納できます。

- メッセージ
監視が非認証であると確認されたときに違反に使用されるメッセージ。

- メッセージのクリア
前の違反がクリアされた後にこの違反に使用されるメッセージ。

- キーワード
キーワードは、データを様々なレポートに編成する方法を制御できるようルールに割り当てることができます。

詳細は、「リアルタイム監視ルールのターゲット・プロパティ・フィルタの重要度」を参照してください。

7. 「次へ」をクリックします。

8. 次のページで、このルールに対して監視するファセットを選択します。すでに定義されているファセットを組み込むことも、このルール作成に従ってインラインで新規ファセットを作成することもできます。ファセットは、監視するパターンの単なるリストです。たとえば、ファイル、ユーザー名、プロセスなどのリストです。ファセットについてはこの後、後半のリアルタイム監視ファセットに関する項で説明します。

9. 既存のファセットを組み込むか新規ファセットを追加した後に「次」をクリックします。

10. 次の画面で、監視するアクションを選択します。選択するアクションは、ルールに対して選択するエンティティ・タイプによって異なります。たとえば、OSファイル監視の場合、ファイルの作成、変更、削除、名前変更などのアクションを監視できます。OSユーザー監視の場合、ログイン、ログアウト、SU、SSHなどのアクションを監視できます。ルールに対して監視するアクションを少なくとも1つ選択する必要があります。
詳細は、「監視する処理タイプの選択」を参照してください。

11. 「次へ」をクリックします。

12. 次の画面で、必要に応じて、監視用のフィルタを構成できます。フィルタは、アクションを監視するタイミングまたは条件を制限するために使用します。たとえば、ファイル・ファセットFILES1を監視しているときに、特定のユーザーのリストによって行われたファイル変更のみが取得されるようにフィルタを追加したり、特定の時間ウィンドウに変更が行われた場合、またはファイルを変更するために特定のプロセスが使用された場合に設定することもできます。フィルタはまた、異なるエンティティ・タイプのファセットでもあります。OSファイル・エンティティ・タイプを監視している場合、OSユーザー、OSプロセスまたは時間ウィンドウのファセットをフィルタとして適用できます。既存のファセットを組み込むことも、ルール作成に従ってインラインで新規ファセットを作成することもできます。ルール・ウィザードを取り消しても、インラインで作成したファセットはファセット・ライブラリ内にそのまま存在します。
詳細は、「リアルタイム監視ルールのフィルタとしてのファセットの使用」を参照してください。

13. 「次へ」をクリックします。

14. 次の画面で、監視が管理エージェントで検出されたときの処理方法に関連する複数の設定を構成できます。

- 監視を手動で認証

- 変更リクエスト管理システムを使用して監視を自動認証

- 収集の設定

詳細は、「監査ステータスの構成」および「監視バンドルの存続期間の制御」を参照してください。

15. 「次へ」をクリックします。

16. この画面で、ルールの設定を確認できます。

17. 「終了」をクリックし、ルールを保存し、ルール・リスト・ページに戻ります。

リアルタイム監視ルールのターゲット・プロパティ・フィルタの重要度

ルールの作成時に、ルールのターゲット・タイプを選択する必要があります。管理エージェントのリアルタイム監視機能は、オペレーティング・システムおよびオペレーティング・システムのバージョンに一部依存しているため、ユーザーはルールの基準の設定が許可されている必要があります。ターゲットはターゲット・タイプごとに異なる可能性があるため、ファセットのパターンも異なる可能性があります。たとえば、Microsoft Windows上のOracleデータベースは、UNIXオペレーティング・システム上のそれと同じではありません。

ターゲット・プロパティ・フィルタが設定されていない場合、すべてのルールのオプションが使用可能になり、target-csのアソシエーション時にターゲットの設定が一致しないと、ルールおよびファセットは無視されます。たとえば、プラットフォーム名のみを設定し、バージョンを設定しない場合は、そのプラットフォームのすべてのバージョンに共通のオプションのみが使用可能になります。

ルールの作成時に選択可能なファセットのリストは、ファセットの作成時に設定されるターゲット・プロパティ別にフィルタされます。たとえば、LinuxまたはHPUX上で機能するファセットFACET1があり、Windowsに対するルールを作成する場合、FACET1はそのルールには選択できません。これは、監視ファセットを選択する場合と、ファセットをフィルタとして使用する場合の両方に当てはまります。ただし、LinuxまたはHPUXのいずれかでルールを作成する場合は、ルールの基準が少なくともファセットの基準と重複するため、FACET1は使用可能になります。

リアルタイム監視ルールのフィルタとしてのファセットの使用

ルールを作成する際、ファセットの使用方法は2つあります。最初の方法は、ファセットを使用して、ルールで監視されるエンティティを決定することです。2つ目の方法は、ファセットをフィルタとして使用して、管理エージェントによって検出されたアクティビティ全体に適用することです。

同じファセットをあるルールでは監視ファセットとして使用し、別のルールではフィルタ・ファセットとして使用できます。この利点は、たとえば、管理ユーザーを定義するためにパターンの集合を定義した後、その集合を再定義することなく、様々な方法で使用できることです。

ルール内のフィルタは、取得され、Cloud Controlにレポートされる監視の数を減らすために設定されます。フィルタが定義されていない場合、ルールで選択された監視ファセットに関連するすべての監視が取得されます。ファセットをフィルタとして選択した場合、デフォルトでは、一致する属性を持つ監視のみが含まれます。次のITコンプライアンス制御の例は、フィルタリングの例を示しています。

IT制御: 本番時間中に、管理者によるクリティカルOS構成ファイルへの変更を監視します。

このIT制御を実装するには、次のようなコンプライアンス基準を作成します。

1. ルールを作成し、クリティカルOS構成ファイルをすべてカバーするパターンを含む監視ファセットとして、ファイル・ファセット「クリティカルOS構成ファイル」を選択します。

2. 取得するアクション・タイプとして、「コンテンツ変更」を選択します。

3. ファセット「管理者」を選択して、OSユーザー・フィルタを追加します。このファセットは、管理者とみなされるすべてのOSユーザー・アカウントを記述するパターンをリストします。

4. ファセット「本番時間」を選択して、時間ウィンドウ・フィルタを追加します。これは、本番時間とみなされる週のうちの時間を記述するパターンをリストします。たとえば、毎日4am-2pm PSTなどです。

管理エージェントがクリティカルOS構成ファイル内のパターンにコンテンツ変更を確認すると、エージェントは、その変更が本番時間中に発生し、管理者のファセットに記述されているユーザーによって行われたものである場合にのみ、変更をCloud Controlにレポートします。また、フィルタを反転して、管理者グループ以外のユーザーまたは本番時間以外の変更のみがレポートされるようにすることもできます。

フィルタの使用方法の詳細は、前述のリアルタイム監視ルールの作成に関する項を参照してください。

監査ステータスの構成

各監視には監査ステータスがあります。この監査ステータスは時間が経つにつれて変化する場合があり、手動で設定することもCloud Controlによって自動的に設定することもできます。監査ステータスの管理方法は、リアルタイム監視ルールの作成または編集時に構成します。

ウィザードの設定ページでルールを作成する場合、このルールに対して検出されたすべての監視の監査ステータスは、ユーザーから手動で取得するか、変更リクエスト管理サーバーとのコネクタ統合を使用して自動的に取得するかを選択するオプションが用意されています。

監査ステータスをルールに手動で設定することを選択する場合、2つのオプションを使用できます。

- このルールに対して検出されたすべての監視がデフォルトで非監査、認証済または非認証になるようにデフォルト監査ステータスを設定できます。非監査とは、これらが確認されておらず、監視が良好と不良のどちらであるか決定されていないということを意味します。

- 手動認証時には情報イベントを選択することを選択できます。これを使用して、新規監視バンドルの発生時にインシデント・マネージャで情報クラスの新規イベントを作成します。このイベントに基づいてイベント・ルールを作成することにより、監視バンドルに基づいて通知を送信したり、インシデント・マネージャが実行できる他の任意のアクションを実行できます。

変更リクエスト管理サーバーを使用して自動リコンシリエーションを使用することを選択する場合、変更管理用のCloud Controlコネクタを設定する手順に従う必要があります。この詳細は、この後のリアルタイム監視の追加設定に関する項を参照してください。

コネクタが構成されると、ルール作成ウィザードのこの設定ステップに、このルールに使用するコネクタを選択するためのドロップダウンが表示されます。監視の属性およびオープンな変更リクエストに定義されている監視に基づいて、一致するオープンな変更リクエストが存在する場合、監視は自動的に認証済だとみなされ、そうでない場合、非認証だとみなされます。

自動リコンシリエーションを使用する場合、監視の認証を許可した変更リクエスト管理サーバーの変更リクエストに認証済監視の詳細を注釈し戻すよう指定する追加オプションが用意されています。

同じ監視バンドルに複数の監視が属することが可能です。監視はグループの一部ですが、認証済または非認証の決定は、グループ・レベルではなく個別の監視に対して行われます。グループに非認証としてマークされた監視が少なくとも1つ含まれている場合、そのグループは違反とみなされ、このグループの違反に対してイベントまたはインシデントが発生する可能性があります。

監視バンドルの存続期間の制御

監視バンドルとは、比較的短い期間内に、同じターゲット上の同じルールに対して、同じユーザーによって発生する監視の論理グループです。3つの要素は、管理エージェントがCloud Controlサーバーへ返す前に監視をグループ化する方法を決定する要素であるため、ユーザーが構成することはできません。

ただし、ルールを作成するユーザーは、次の3つの変数を構成できる必要があります。

1. アイドル・タイムアウト: 特定のターゲットに関する特定のルールに対するユーザーの最後のアクティビティ以降にアクティビティが実行されなかった時間の長さ。このユースケースは、ユーザーがサーバーにログインし、いくつかのファイルの変更を開始して、その後15分間ファイルが変更されない状態です。この15分の待ち時間がアイドル・タイムアウトです。このアイドル・タイムアウト時間を過ぎると、現在の監視バンドルがクローズしてCloud Controlサーバーに送信されます。次回、新規監視が検出されると、新規グループが開始され、プロセスが再度開始されます。

2. グループの最大存続期間: ユーザーがアイドル・タイムアウトを15分間に設定し、ホスト上のユーザーが10分ごとに、無期限に(たとえばスクリプトを利用して、あるいは手動で)1つのファイルを変更したとすると、監視バンドルは終了しないままとなり、Cloud Controlサーバーに送信されてレポート/処理されることもありません。グループに最大存続期間を設定すれば、指定された最大時間までしかグループを累積で存続させないように管理エージェントに指示することができます。たとえば、最大存続期間を30分、または1時間に設定できます。

3. バンドル内の最大監視数: 1つのアクティビティによって多数の監視が検出され、そのアクティビティによってルールがトリガーされる場合、監視が多すぎるときはすべての監査をまとめてバンドル化しない方がよいことがあります。バンドルには管理ライフサイクルがあり、Cloud Controlサーバーに到達した後に、このライフサイクル内で監視を認証済または非認証などに設定できます。1つの監視バンドルに何万もの監視が含まれていると、管理が困難になります。

ルールを作成しているユーザーは、バンドル化を無効にするよう選択することはできませんが、Cloud Controlサーバーへのレポートの遅延を減らす必要がある場合は、アイドル・タイムアウトとバンドルの最大存続期間により低い値を設定できます。

イベント/インシデント・サブシステムでは、個別の監視ではなく監視バンドルのみが追跡されます。1つの監視が非認証とマークされている場合、バンドル全体が違反になります。このバンドルは、インシデント管理イベントによって追跡されるエンティティになります。

監視バンドルは管理エージェントで構築され、前述の基準に応じてバンドルが完了した場合のみCloud Controlサーバーに送信されます。ほとんどのコンプライアンスのユースケースでは、結果を即時に参照する必要がないため、これは許容範囲です。何が行われているかを理解したり監視を管理しやすくする上でより重要なのは、結果を取得してまとめてバンドル化することです。

複数のルールで同じファセットを使用しているために、または同じホスト上の複数のターゲットがエンティティを共有する同じファセットを監視しているために、1つの監視が管理エージェントで複数のバンドルに属している場合、最初のバンドルがそのいずれかの終了条件(アイドル・タイムアウト、グループの最大存続期間、またはグループ・エントリの最大数)に達すると、共有の監視を含むバンドルはすべて同時に終了します。

監視バンドルの存続期間を制御するには、リアルタイム監視ルールを作成してルール作成ウィザードの「設定」ページで適切な設定を行う方法に関する前述の項を参照してください。

監視する処理タイプの選択

ルールを作成する際、監視してCloud Controlにレポートすることが重要な監視またはユーザー処理のタイプを決定できます。管理エージェントには、エンティティ・タイプごとに使用できる特定の監視セットが用意されています。一部のオプションは、オペレーティング・システムのプラットフォームまたはバージョンに固有です。これらのオプションを1つ以上選択できます。

選択可能な監視タイプは、ルールに対して選択されたターゲット・プロパティとターゲット基準によっても制限される場合があります。たとえば、いくつかのオペレーティング・システムには、すべてのファイル監視機能が備わっていない可能性があります。使用可能な監視タイプのリストを構築する際には、ターゲット・タイプ、エンティティ・タイプおよびターゲット・プロパティをすべて考慮して使用可能な監視タイプが決定されます。

ルールで監視する監視タイプを選択するには、次の手順を実行します。

1. 現在存在するルールの監視を選択するには、「ルール」表でリアルタイム監視ルールをクリックし、「編集」をクリックします。
ルールの編集: リアルタイム監視ウィザードが開き、「詳細」ページが表示されます。監視ページに移動します。

新規ルールの作成中に監視を選択するには、「作成」をクリックして新規ルールを作成します。ルールの作成: リアルタイム監視ウィザードが開き、「詳細」ページが表示されます。このウィザードの詳細ページとファセット・ページに関連情報を入力した後、監視ページに移動します。

2. 監視ページで、表示されるリストから監視するアクティビティを1つ以上選択します。このルールへのターゲット・アソシエーション中に、選択された詳細を取得するために監査を有効にする必要があります。異なるオペレーティング・システムと異なる機能には、それぞれ固有の監査要件があることに注意してください。

3. 「パラメータ」セクションで、追加の監視パラメータがある場合は、パラメータを確認して更新できます。

リアルタイム監視ルールに関する追加の注意事項

- ルールはすべてグローバル・ルール・ライブラリに表示され、すべてのユーザーが参照できます。

- コンプライアンス基準ルールの作成後、そのルールは自動的に評価されません。ルールは、使用する前にコンプライアンス標準に関連付ける必要があります。コンプライアンス標準が1つ以上のターゲットに関連付けられている場合のみ、ルールの評価が行われます。ルールを直接評価することはできません。

- 1つのルールを複数のコンプライアンス標準に関連付けることができます。

- このルールが関連付けられているコンプライアンス標準を介してルールの様々な属性をカスタマイズできます。これらのカスタマイズは「コンプライアンス標準」画面で行います。コンプライアンス標準ごとにカスタマイズできるこれらの属性の1つに、この標準に関連するルールの重要度があります。

- ユーザー定義コンプライアンス基準ルールは特権ユーザーによって定義されるため、コンプライアンス基準ルールを変更できるのは特権ユーザーのみです。違反結果は、すべてのユーザーが表示できます。

- このユーザー定義のコンプライアンス標準ルールを他の特権ユーザーと共有するには、これらのユーザーが管理リポジトリにコンプライアンス標準ルールをインポートできるように、(エクスポート機能を使用して)XMLスキーマ定義を指定します。

- 1行当たりのテキストを50文字に制限することにより、「説明」、「影響」および「推奨」情報の参照中のスクロールを最小限に抑えることができます。50を超える文字数が必要な場合は、改行してテキストを続けます。

- コンプライアンス標準ルール・ウィザード内の各ページに関する具体的な手順の詳細は、コンテキスト依存ヘルプを参照してください。

- OSファイル・エンティティ・タイプの監視を選択する場合、アクション・タイプの1つとして「ファイル・コンテンツの変更(成功) - ファイルのコピーのアーカイブ[リソース消費型]」が表示されます。このオプションを選択すると、ファイルの変更アクションが検出されるたびに、ファイルのコピーが管理エージェントにローカルでアーカイブされます。これは後で、ファイルの2つのバージョン間で変更された内容を視覚的に比較するために使用できます。ルール作成ウィザードの「監視するアクション」ページには、アーカイブしたコピーを格納する数を設定する追加設定があります。

- ルール作成ウィザードに従ってインラインでファセットを監視ファセットまたはフィルタ・ファセットとして追加する場合、ルール・ウィザードを取り消しても、新しく作成したファセットはそのまま残り、将来のルールで使用できるようになります。これらのファセットは、ファセット・ライブラリにアクセスすることによって削除できます。リアルタイム監視ファセットの詳細は、このドキュメントの後半にある個別の項を参照してください。

45.4.7.4 エージェント側ルールの作成

注意: エージェント側のルールを作成する前に、構成拡張を作成する必要があります。

収集された構成データに基づいてターゲットが必要な構成状態にあることを確認するためのエージェント側のコンプライアンス標準ルールを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準ルール」タブをクリックします。

3. 「作成」ボタンをクリックします。

4. 「ルールの作成」ポップアップで、タイプとして「エージェント側のルール」を選択します。

5. 「続行」をクリックします。

6. 次の画面で、ルールの複数の主要属性を入力するよう求められます。

- ルール名
一意のルール名を入力します。

- コンプライアンス・ルールの状態
このルールの状態が開発と本番のどちらであるかを設定します。開発とは、ルールがまだ定義またはチューニング中であり、ターゲットで使用する準備がまだ整っていないことを意味します。ルールを本番に昇格した後、ルールを開発に戻すことはできません。

- 重大度
ルールには、重大度レベルがあり、クリティカル(ルールが違反している場合の深刻な問題)、警告(違反している場合の深刻ではない問題)、またはマイナー警告(違反している場合のマイナーな問題)のいずれかです。重大度は、このルールがコンプライアンス標準に追加されるときにこのルールに設定される可能性がある重要度とともにコンプライアンス・スコアに影響します。

- 適用可能対象
このルールが適用されるターゲット・タイプ。

- ターゲット・プロパティ・フィルタ
このルールがコンプライアンス標準に関連付けられているときにこのルールを適用可能なターゲットを決定する特定のターゲット・プロパティを指定できます。このようなプロパティには、オペレーティング・システム、ターゲット・ライフサイクルの状態、バージョンおよびプラットフォームがあります。たとえば、Linux OSなど、このルールにターゲット・プロパティ・フィルタを指定すると、このルールはLinuxオペレーティング・システムに対してのみ適用可能になります。

- 説明
ルールの説明

- 論理
このルールの確認対象、およびこのルールの違反による影響を表すテキスト。

- 推奨
違反が発生した際の問題の修正方法を表す推奨テキスト。

- 参照URL
コンプライアンス制御を詳細に説明するドキュメントへのURL。多くの場合、これらのドキュメントはコンテンツ管理システムに格納できます。

- キーワード
キーワードは、データを様々なレポートに編成する方法を制御できるようルールに割り当てることができます。

7. 「次へ」をクリックします。

8. 「チェック定義」ページで、ドロップダウン・リストから該当する「構成拡張-別名」を選択して、構成拡張の詳細を設定します。

9. コンプライアンス・メッセージおよび非コンプライアンス・メッセージを入力します。これらは、評価に関して表示されるメッセージです。違反が発生すると、非コンプライアンス・メッセージが、インシデント管理機能下におけるイベントを説明する文字列になります。

10. 「次へ」をクリックします。

11. 「テキスト」画面では、ルールをテストできます。使用環境内のターゲットを選択し、「テストの実行」ボタンをクリックできます。ルールに関する問題が表示され、ルールを保存する前にこれらを解決できます。

12. 「次へ」をクリックします。

13. 最終ページでは、このルールに対して構成したすべての内容を確認できます。内容がすべて正しいことを確認し、「終了」ボタンをクリックしてルールを保存します。

45.4.7.5 手動ルールの作成

収集された構成データに基づいてターゲットが必要な構成状態にあることを確認するための手動コンプライアンス標準ルールを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準ルール」タブをクリックします。

3. 「作成」ボタンをクリックします。

4. 「ルールの作成」ポップアップで、タイプとして「手動ルール」を選択します。

5. 「続行」をクリックします。

6. 次の画面で、ルールの複数の主要属性を入力するよう求められます。

- ルール名
一意のルール名を入力します。

- コンプライアンス・ルールの状態
このルールの状態が開発と本番のどちらであるかを設定します。開発とは、ルールがまだ定義またはチューニング中であり、ターゲットで使用する準備がまだ整っていないことを意味します。ルールを本番に昇格した後、ルールを開発に戻すことはできません。

- 重大度
ルールには、重大度レベルがあり、クリティカル(ルールが違反している場合の深刻な問題)、警告(違反している場合の深刻ではない問題)、またはマイナー警告(違反している場合のマイナーな問題)のいずれかです。重大度は、このルールがコンプライアンス標準に追加されるときにこのルールに設定される可能性がある重要度とともにコンプライアンス・スコアに影響します。

- 適用可能対象
このルールが適用されるターゲット・タイプ。

- ターゲット・プロパティ・フィルタ
このルールがコンプライアンス標準に関連付けられているときにこのルールを適用可能なターゲットを決定する特定のターゲット・プロパティを指定できます。このようなプロパティには、オペレーティング・システム、ターゲット・ライフサイクルの状態、バージョンおよびプラットフォームがあります。たとえば、Linux OSなど、このルールにターゲット・プロパティ・フィルタを指定すると、このルールはLinuxオペレーティング・システムに対してのみ適用可能になります。

- 説明
ルールの説明

- 論理
このルールの確認対象、およびこのルールの違反による影響を表すテキスト。

- 推奨
違反が発生した際の問題の修正方法を表す推奨テキスト。

- コンプライアンス・メッセージ
このメッセージは、ターゲットが準拠している場合に表示されます。

- 非コンプライアンス・メッセージ
違反が発生すると、非コンプライアンス・メッセージが、インシデント管理機能下におけるイベントを説明する文字列になります。

- 参照URL
コンプライアンス制御を詳細に説明するドキュメントへのURL。多くの場合、これらのドキュメントはコンテンツ管理システムに格納できます。

- キーワード
キーワードは、データを様々なレポートに編成する方法を制御できるようルールに割り当てることができます。

7. 「終了」をクリックします。

45.4.7.6 コンプライアンス標準ルールの類似作成

別のコンプライアンス標準ルールに類似したコンプライアンス標準ルールを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準ルール」タブをクリックします。

3. レプリケートするルールをハイライト表示します。

4. 「類似作成」ボタンをクリックします。

5. 必要に応じて、フィールドをカスタマイズします。

6. 「保存」をクリックします。

45.4.7.7 コンプライアンス標準ルールの編集

コンプライアンス標準ルールを編集するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準ルール」タブをクリックします。

3. 編集するルールをハイライト表示し、「編集」ボタンをクリックします。

4. 以前のルールの作成時に説明したルール作成ウィンドウ属性の各画面の指示に順に従います。

5. 「保存」をクリックします。

使用上の注意

- リポジトリ・ルールの場合、ルール名、状態(すでに本番である場合)、および適用可能対象以外のすべてのルール・プロパティを変更できます。
リアルタイム監視ルールの場合、ルール名、状態(すでに本番である場合)、適用可能対象、ターゲット・プロパティ・フィルタおよびエンティティ・タイプは変更できません。

- ルール問合せ、違反条件、パラメータまたは重大度など、リポジトリ・ルールの重要なルール・プロパティを変更する場合、ルールの編集によって、ルールを参照するコンプライアンス標準の結果は無効になります。コンプライアンス標準のコンプライアンス・スコアは、次のルール評価で再評価されます。

- 本番モードのルールでは、ルールのドラフトを作成および保存するか、既存の本番ルールを上書きするかを選択できます。ドラフトを作成する場合、ドラフト・ルールを編集し、後でそれをテストし、ドラフトが作成された元の本番ルールに上書きおよびマージできます。注意: コンプライアンス標準にドラフト・ルールを含めることはできません。

- WebLogic Server署名ルールまたはリアルタイム監視ルールについては、編集中のルールが、ターゲットに関連付けられているコンプライアンス標準によって参照されている場合、ルール定義はターゲットを監視する管理エージェントにデプロイされ、これによって管理エージェントは最新のルール定義を評価できるようになります。管理エージェントが停止しているか、アクセス不可能な場合は、管理エージェントが使用可能になった直後にルール定義の変更が管理エージェントに伝播されます。

45.4.7.8 コンプライアンス標準ルールの削除

ルールを削除する前に、コンプライアンス標準ルールを削除する前にコンプライアンス標準ルールの参照がコンプライアンス標準から削除されていることを確認する必要があります。コンプライアンス標準によって使用されているルールを削除することはできません。

コンプライアンス標準ルールを削除するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準ルール」タブをクリックします。

3. 削除するルールをハイライト表示し、「削除」ボタンをクリックします。

4. 「OK」をクリックして、ルールを削除するかどうかを確認します。

45.4.7.9 コンプライアンス標準ルールのエクスポート

エクスポート機能は、管理リポジトリおよびCloud Controlインスタンス間でユーザー定義のコンプライアンス標準ルール定義をトランスポートするためのメカニズムです。エクスポートによって、オペレーティング・システム・ファイルに定義を格納します。エクスポートしたコンプライアンス標準ルール定義は、XMLフォーマットであるため、Oracleコンプライアンス標準定義(XSD)フォーマットに準拠しています。コンプライアンス標準ルールの定義を変更でき、生成されたコンプライアンス標準ルール定義を別の管理リポジトリに再インポートできます。

コンプライアンス標準ルールをエクスポートするには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準ルール」タブをクリックします。

3. エクスポートするルールをハイライト表示します。

4. 「アクション」メニューから、「エクスポート」を選択します。

5. 基準ルールをエクスポートするファイル名を指定します。

6. コンプライアンス標準ルールのXML表現が生成され、指定したディレクトリおよびファイルに配置されます。

45.4.7.10 コンプライアンス標準ルールのインポート

インポートにより、すでに所有しているコンプライアンス標準ルールの再使用、Cloud Controlの複数のインスタンス間でのルール定義の共有、ルールのオフライン編集の有効化が可能になります。

コンプライアンス標準ルールをインポートする前に、インポートするコンプライアンス標準ルールがファイルに定義されていることを確認します。このファイルには、Cloud Controlにアクセスするために使用しているブラウザからローカルにアクセスできる必要があります。また、インポートするコンプライアンス標準ルール定義XMLファイルへのアクセス権限を持っていることも確認します。

コンプライアンス標準ルールをインポートするには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準ルール」タブをクリックします。

3. 「アクション」メニューから、「インポート」を選択します。

4. ルール定義(コンプライアンス標準ルールXSDに従う)をインポートするファイル名を指定します。コンプライアンス・フレームワーク定義がすでに存在する場合に既存の定義をオーバーライドするかどうかを指定します。オーバーライド・オプションはリアルタイム監視ルールには使用できません。

5. 「OK」をクリックします。

45.4.7.11 コンプライアンス標準ルールの参照

コンプライアンス標準ルールを参照するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準ルール」タブをクリックします。

3. 特定の基準ルールの詳細を表示するには、ルールをハイライト表示し、「詳細を表示」をクリックします。

45.4.7.12 コンプライアンス標準ルールの検索

コンプライアンス標準ルールを検索するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準ルール」タブをクリックします。

3. ページの検索部分に、条件を指定して、検索結果を絞り込むのに使用します。
デフォルトでは、コンプライアンス標準ルール・ライブラリ内のすべてのコンプライアンス標準ルールが結果表に表示されます。ただし、検索基準のセットを指定し、基準と一致するコンプライアンス標準ルールのみが結果表に表示されるように検索を実行できます。

たとえば、「カテゴリ」リストで「セキュリティ」、「コンプライアンス標準ルール」リストで「次を含む」、その隣の「コンプライアンス標準ルール」テキスト・フィールドで「port」、「ターゲット・タイプ」リストで「ホスト」を選択し、「実行」をクリックすると、Cloud Controlは、名前に「port」を含むホスト・セキュリティ・カテゴリのコンプライアンス標準ルールのみを表示します。

4. 「検索」をクリックします。

45.4.7.13 Oracle提供のコンプライアンス標準ルール

Oracleでは、1600を超えるコンプライアンス標準ルールを提供しています。

45.5 リアルタイム監視ファセット

リアルタイム監視ルール定義には、指定したターゲット・タイプ、ターゲット・プロパティおよびエンティティ・タイプに対する監視で何が重要かを判別するのに使用するファセットが含まれています。ファセットは、ターゲット・タイプの属性を構成するパターンの集合です。

次の各項では、リアルタイム監視ファセットについて詳しく説明します。

- リアルタイム監視ファセットについて

- ファセットでの操作

45.5.1 リアルタイム監視ファセットについて

ターゲット・タイプには複数のファセットがあります。ターゲット・タイプには、重要な構成ファイルはどれか、ログ・ファイルはどれか、実行可能ファイルはどれか、機密構成データが保存されているデータベース表はどれかなどのファセットがあります。指定されたターゲット・タイプのこれらすべてのファセットの総合で、コンプライアンスという観点から、指定されたターゲット・タイプで監視することが重要なすべてのことが決定されます。

特定のターゲット・タイプに対して、任意の数のファセットを作成できます。ファセットは、特定のターゲット・タイプに対してのみでなく、特定のターゲット・タイプといくつかのターゲット・タイプ・プロパティの組合せに対しても作成できます。たとえば、Windows上のホスト・ターゲット・タイプに対するファセットの作成は、Linux上のホスト・ターゲット・タイプに対するファセットの作成とは異なります。1つのファセットに複数のターゲット・タイプ・プロパティを設定したり、プロパティを指定せずに任意のターゲットがファセットを使用できるようにすることができます。

ファセットは多くのルールで再使用できます。この利点は、すべてのルールを変更しなくてもファセットのエントリを追加または削除できる点です。たとえば、今日監視したいログ・ファイルが5つある場合、これら5つのファイルをリストするファセットを監視するルールを設定できます。明日新規ログ・ファイルを追加する必要がある場合、各ルールではなく、ファセットを変更するのみですみます。

ファセットは独自に作成するか、リアルタイム監視ルールの作成に従ってインラインで作成できます。作成方法に関係なく、後から任意の数のルールで再利用できます。

ターゲット・タイプに基づくリアルタイム監視ファセットを使用して、リアルタイム監視ルールで監視するエンティティを指定します。たとえば、ファイルの変更のためにホストを監視する場合、ファセットに個別の単一ファイルのリスト、多くのファイルを含むワイルドカードを使用したパターンまたは全体のディレクトリを指定できます。これらのパターンにデフォルトを使用するパラメータも含めることができますが、各ターゲットの必要に応じて上書きできます。ORACLE_HOMEなどの組込みパラメータは各ターゲットに動的に入力されます。データベース構成ファイルtnsnames.oraの監視を指定した場合、パターンが{ORACLE_HOME}/network/admin/tnsnames.oraになります。

ファセットは、完全に異なる2つの方法で使用できます。第一に、ファセットは監視の内容を表します。ルール作成ウィザードでは、これらのファセットはウィザードのステップ「監視するエンティティ」で選択します。また、ファセットは、監視結果をフィルタするために使用することもできます。これらのフィルタ・ファセットは、ルール作成ウィザードの「フィルタ」ステップで指定します。たとえば、OSファイル・エンティティ・タイプを監視する場合、ファイルの変更を行ったユーザー、ファイルの変更が行われた時刻、またはファイルの変更を行うために使用されたプロセスに基づいて結果をフィルタできます。

継続的なリアルタイム監視を実行する場合、監視の範囲を重要なエンティティのみに制限することが重要です。組織によって重要でない多数のアクティビティを監視すると、管理エージェントのCPU負荷が高くなり、Oracle Enterprise Managerサーバーによって処理および格納されるデータの量が非常に多くなります。

45.5.1.1 ファセット・エンティティ・タイプ

各ファセットには、ファセットが示すエンティティの種類を定義するエンティティ・タイプがあります。たとえば、OSレベルの監視では、OSファイル、OSプロセス、OSユーザー、Windowsレジストリおよび複数のActive Directoryエンティティ・タイプがあります。データベースの監視では、エンティティ・タイプに表、ビュー、索引、プロシージャが特に含まれます。使用可能なエンティティ・タイプは、管理エージェントから使用可能な継続的なリアルタイム構成変更監視機能によって固定されています。

ファセットは、「ファセット・ライブラリ」画面を使用して作成できます。この画面で、ファセットのパターンの追加および編集、およびルールによって消費されているファセットの確認を実行できます。

次の表に、Cloud Controlでリアルタイム監視用としてサポートされるエンティティ・タイプをリストします。

表45-2 監視されるエンティティ・タイプ

エンティティ・タイプ

OSファイル

Oracleデータベース表

Oracleデータベース・パッケージ

OSプロセス

Oracleデータベース・ビュー

Oracleデータベース・ライブラリ

OSユーザー

Oracleデータベース・プロシージャ

Oracleデータベース・トリガー

Microsoft Windowsレジストリ

Oracleデータベース・ユーザー

Oracleデータベース表領域

Microsoft Active Directoryユーザー

Oracleデータベース索引

Oracleデータベースのマテリアライズド・ビュー

Microsoft Active Directoryコンピュータ

Oracleデータベース順序

Oracleデータベース・クラスタ

Microsoft Active Directoryグループ

Oracleデータベース関数

Oracleデータベース・リンク

Oracleデータベースのディメンション

Oracleデータベース・プロファイル

Oracleデータベース・パブリックDBリンク

Oracleデータベースのシノニム

Oracleデータベースのパブリック・シノニム

Oracleデータベース・セグメント

Oracleデータベース・タイプ

Oracleデータベース・ロール

OracleデータベースのSQL問合せ文

45.5.1.2 ファセット・パターン

ファセットには、1つ以上のパターンが含まれています。これらのパターンは、包含および除外フィルタを表すことができます。たとえば、次のような重要な構成ファイルのファセットを定義できます。

include c:\myapp1\config

exclude c:\myapp1\config\dummy.cfg

この場合、個別のファイルc:\myapp1\config\dummy.cfgを除き、c:\myapp1\configの下にあるすべてのものがこのファセットのメンバーであるとみなされます。通常、パターンがどのように機能するかを指定するいくつかのルールがあり、最も一般的なユースケースを次に示します。各エンティティ・タイプには、特別なケースまたは特別なパターンの形式がある場合があります。

- 包含と除外のパターンが同じ詳細レベルで指定された場合、包含が優先されます。

- より具体的なパターンが優先されます(前述の例では、exclude dummy.cfgによって、最初のパターンから継承されたinclude c:\dummy.cfgが上書きされます)。

- パターンが存在しない場合、exclude *が想定されます(たとえば、ファセットにエンティティがない場合など)。

ファセットに追加する各パターンには、そのパターンについて記述できるオプションの説明フィールドがあります。

45.5.2 ファセットでの操作

次の各項では、ファセットで実行できる操作について説明します。

- ファセット・ライブラリの表示

- ファセットの作成および編集

- ファセット・フォルダの作成および編集

- ファセットの削除

- 「類似作成」を使用した新規ファセットの作成

- ファセットのインポートおよびエクスポート

- ルールでまだ使用されていないベース・ファセット属性の変更

これらの構成がコンプライアンス監視に関連しているため、ファセットを作成、削除および変更する権限を持っていることを確認します。詳細は、第45.1.3項「コンプライアンス機能の使用に必要なロールおよび権限」を参照してください。

45.5.2.1 ファセット・ライブラリの表示

監視データを表示できるユーザーは、ファセット・ライブラリを表示し、ファセットのファセット履歴を参照することもできます。

ファセット・ライブラリを表示する方法には、検索モードと参照モードの2つがあります。検索モードの場合、検索基準を満たすすべてのファセットがフラット・リストに表示されます。参照モードの場合、ファセットが属するフォルダ階層とともにファセットが表示されます。このフォルダ構造は、Cloud Control内で非常に多数のファセットを管理する上で役立ちます。

検索モードでファセット・ライブラリを表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. リアルタイム監視ファセット・ライブラリ・タブを選択します。
Cloud Controlで「ファセット・ライブラリ」ページが表示され、既存のすべてのファセットが、ターゲット・タイプ、エンティティ・タイプなど、ファセットに関する詳細とともにリストされます。監査作成者ロールを持っている場合、このページから、作成、類似作成、表示、削除、インポートおよびエクスポートなどの管理タスクを実行できます。

3. 「ファセットの検索」タブをクリックします。
ファセット・ライブラリ・ページには、ファセット名、作成者、ターゲット・タイプ、エンティティ・タイプ、ファセットを使用するルール、説明、およびファセットの最終更新時間が表示されます。ファセットの詳細を参照するには、そのファセットを表から選択して「詳細を表示」をクリックします。

4. 表に表示する列を選択するには、「表示」をクリックしてから「列」を選択します。「すべて表示」列を選択するか、表に表示する列を個別に選択できます。列を並べ替えるには、「表示」をクリックしてから「並替え」をクリックし、矢印キーを使用して列を上下に移動して列の表示順序を変更します。

5. 「検索」というタイトルのページの領域を拡張すると、ファセットの表示に適用する検索基準を選択できます。

6. 選択したファセットの履歴を参照するには、そのファセットを表から選択して「履歴」をクリックします。「履歴の表示」ページが表示されます。

参照モードでファセット・ライブラリを表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. リアルタイム監視ファセット・ライブラリ・タブを選択します。
Cloud Controlで「ファセット・ライブラリ」ページが表示され、既存のすべてのファセットが、ターゲット・タイプ、エンティティ・タイプなど、ファセットに関する詳細とともにリストされます。監査作成者ロールを持っている場合、このページから、作成、類似作成、表示、削除、インポートおよびエクスポートなどの管理タスクを実行できます。

3. 「ファセットの参照」タブをクリックします。
表示される「ファセット・ライブラリ」ページは2つのビューに分割されています。左側には、ファセット・フォルダ階層が表示されます。右側には、左側で選択したフォルダ内のファセットがリストされます。左側の表には、ファセット名、作成者、ターゲット・タイプ、エンティティ・タイプ、ファセットを使用するルール、説明、およびファセットの最終更新時間が表示されます。ファセットの詳細を参照するには、そのファセットを表から選択して「詳細を表示」をクリックします。

4. 表に表示する列を選択するには、「表示」をクリックしてから「列」を選択します。「すべて表示」列を選択するか、表に表示する列を個別に選択できます。列を並べ替えるには、「表示」をクリックしてから「並替え」をクリックし、矢印キーを使用して列を上下に移動して列の表示順序を変更します。

5. この画面で使用可能な唯一のフィルタは、異なるフォルダの選択です。選択したフォルダ内にあるファセットのみが常に表示されます。

6. 選択したファセットの履歴を参照するには、そのファセットを表から選択して「履歴」をクリックします。履歴の表示ページが表示されます。

45.5.2.2 ファセットの作成および編集

ファセットを作成し、リアルタイム監視コンプライアンス基準ルールでファセットを使用する場合、コンプライアンス・ルールはファセットの参照のみを行います。コンテンツが変更されると、ルールでは自動的に新しいコンテンツが使用されます。

ファセットのコンテンツの使用が開始されるのは、1つ以上のターゲットに関連付けられたコンプライアンス標準の一部であるルールにファセットが追加された場合のみです。

各ファセットには、ユーザーがそのファセットを記述できる説明が割り当てられます。各パターンにもオプションの説明フィールドがあります。使用が開始されるのは、1つ以上のターゲットに関連付けられたコンプライアンス標準の一部であるルールにファセットが追加された場合のみです。

ファセットを作成または編集するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. リアルタイム監視ファセット・ライブラリ・タブを選択します。
Cloud Controlで「ファセット・ライブラリ」ページが表示され、既存のすべてのファセットが、ターゲット・タイプ、エンティティ・タイプなど、ファセットに関する詳細とともにリストされます。このページから、作成、類似作成、表示、削除、インポートおよびエクスポートなどの管理タスクを実行できます。このページを参照する場合、検索または参照という2つのビューがあります。検索ビューの場合、すべてのファセットがフラット・リストにリストされます。参照ビューの場合、ファセットを見つけやすいように、ファセットはフォルダにグループ化されます。

3. 新規ファセットを作成するには、「作成」をクリックします。

4. このファセットが属する対象のファセット・フォルダを選択します。そのフォルダがまだ作成されていない場合、これを未整理フォルダに追加できます。このフォルダは常に存在し、削除できません。後で、作成する新規フォルダにファセットを移動するには、UIのドラッグ・アンド・ドロップを使用して未整理フォルダから新規フォルダに移動します。

5. ファセットに割り当てる名前を「ファセット名」フィールドに入力し、作成するファセットのターゲット・タイプを「ターゲット・タイプ」フィールドのドロップダウン・リストから選択します。ターゲット・タイプを選択した後、ターゲット・プロパティ・フィルタ・フィールドに値を入力できます。
ここで追加するターゲット・プロパティは、このファセットを最終的に割り当てることができるターゲットを制限します。たとえば、64ビット・サーバーのLinuxバージョン5でのみ動作するファセットを定義できます。

6. ドロップダウンから「エンティティ・タイプ」を選択します。このリストは、前に選択したターゲット・タイプによっては制限されます。

7. 「説明」フィールドにファセットの説明を入力します。

8. 「ファセットの作成」ページには、作成するファセットのパターンやパラメータを入力するために使用できる2つのタブがあります。「パターン」タブを使用して、パターンを「含める」または「除外」に追加します。ファセット定義にパターンを追加、またはファセット定義から選択したパターンを削除するには、「追加」または「削除」ボタンを使用します。各パターンをUIに手動で入力するかわりにパターンがリストされたテキストを貼り付けることができるポップアップ・ウィンドウを表示する一括追加ボタンがあります。

9. OSファイル・エンティティ・タイプのファセットを定義している場合、ホストを参照して監視するファイルを検出するオプション機能があります。ページの右側には、ファイル検索の基本として使用するホストを選択できる領域があります。パターン領域では、「参照」ボタンをクリックして、選択したホストのファイルを対話形式で参照し、パターンに含めるファイルを選択できます。ホストからパターンを選択した後、既存のファイルを引き続き手動で追加または編集できます。

10. 「パラメータ」タブでは、新しいファセットの一部となるパラメータを表示します。Oracleでは、定義済の即時利用可能なターゲット・パラメータ(ORACLE_HOMEなど)に基づいた事前定義済パラメータのセットを提供しています。これらのパラメータにはデフォルト値は必要なく、常にターゲットの値に応じて設定されます。パラメータは、パターンで使用される際にこのタブの下に表示されます。新規パラメータの使用を開始するには、そのパラメータを波括弧{}で囲んでパターンに追加するだけです。たとえば、{INSTALL_DIR}\config\main.confのパターンは、このタブの下にリストされるINSTALL_DIRのパラメータになります。すべてのパラメータは、このファセットを使用するすべてのターゲットに自動的に使用されるデフォルト値を持つ必要があります。この値は、リアルタイム監視ルールを含むコンプライアンス標準を1つ以上のターゲットに関連付ける際にオーバーライドできます。「パラメータ」タブには、「パラメータ名」、「デフォルト値」、パターンで使用、「説明」が表示されます。「パターンで使用」は、そのパラメータが現在使用中であることを示します。このパラメータは、パターンのある点で定義されてから削除されることがあります。パターンが現在使用されていない場合でも、そのパターンは、後で再度使用できます。パターンを追加するエンティティに{または}が含まれる場合、パターン内でそれぞれ{{}および{}}を使用して、これらの文字をエスケープできます。これらは、パラメータとみなされません。

11. 3番目のタブである「時間ウィンドウ」タブは、作成中または編集中のファセットのエンティティ・タイプが時間ウィンドウである場合にのみ使用できます。このエンティティ・タイプのファセットは、リアルタイム監視ルールのフィルタとしてのみ使用できます。たとえば、ルールで、指定した期間(たとえば「本番時間」)にのみファセットを監視するように指定できます。「期間」セクションで、24時間間隔または次の時間に制限を選択し、開始時間と時間単位および分単位の間隔を入力できます。「繰返し」セクションで、常時を選択するか、「繰返し」を選択して操作を繰り返す曜日を選択できます。

12. 「OK」をクリックして、ファセットを作成します。

45.5.2.3 ファセット・フォルダの作成および編集

ファセットの参照モードでファセットを表示する場合、ページ上に2つのリージョンが表示されます。左側には、存在するファセット・フォルダが表示されます。右側には、現在選択されているフォルダ内に存在するファセットが表示されます。フォルダが表示されている左側には、フォルダに対して使用可能なアクションが3つあります。

- 作成: 新規フォルダを作成できます。作成するフォルダ名を尋ねるポップアップが表示されます。また、この新規フォルダを最上位フォルダにするか、現在選択されているフォルダの子として追加するかを選択することもできます。

- 名前の変更: 既存のユーザー定義フォルダの名前の変更できます。

- 削除: ユーザー定義フォルダを削除できます。ファセットまたは他のフォルダが含まれるフォルダを削除することはできません。

Oracleによって移入された即時利用可能なフォルダの削除、名前変更または移動を行うことはできません。

未整理と呼ばれるデフォルトのフォルダが存在します。フォルダを指定せずに作成またはインポートされたファセットは常にこの未整理フォルダに移動されます。

移動するファセットを右側で特定し、これを選択し、これを配置する左側のフォルダまでドラッグするのみで、ファセットをフォルダに移動できます。ファイルはそのフォルダに移動します。1つのファセットが一度に属することができるのは1つのフォルダのみであり、ファセットは常に(未整理フォルダであっても)フォルダに属する必要があります。また、ファセットをクリックし、「移動」ボタンをクリックすることもできます。ポップアップ・ウィンドウが表示され、ファセットの移動先のフォルダを選択できます。

フォルダは監視分析やコンプライアンス・スコアには影響しません。これらは、「リアルタイム監視ファセット」ライブラリ画面で、存在する非常に多数のファセットを管理しやすくするためにのみ使用されます。

45.5.2.4 ファセットの削除

ファセットは、ルールの監視ファセットまたはルールのフィルタ・ファセットとして使用されている間は削除できません。ファセットがどのルールでも使用されていない場合、ファセットを削除できます。ファセットが使用されている場合、現在使用されていることを示すアラートがユーザーに表示され、そのファセットを使用しているルールが変更されてそのファセットが含まれなくなるまで、そのファセットの削除は許可されません。

ファセットを削除すると、ファセットで履歴監視データが参照されず、かわりに関連するファセットの名前として「(削除されたファセット)」が表示されます。「参照」ページではなく「監視の検索」ページでのみこの監視データを使用できます。

コンプライアンスに焦点を当てたユーザーの場合、顧客は通常、コンプライアンス・データが失われないように未使用のファセットを使用可能なまま保持することを求めます。また、収集された監視を保持するために実際のファセットを保持しているかぎり、パターンを削除することもできます。この場合、この古いファセットに関連するコンプライアンス・データが使用可能でなくなった後にのみ、データを損失せずにファセットを削除できます。

ファセットを削除するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. リアルタイム監視ファセット・ライブラリ・タブを選択します。
Cloud Controlで「ファセット・ライブラリ」ページが表示され、既存のすべてのファセットが、ターゲット・タイプ、エンティティ・タイプなど、ファセットに関する詳細とともにリストされます。このページから、作成、類似作成、表示、削除、インポートおよびエクスポートなどの管理タスクを実行できます。

3. ページ内の表にあるファセットのリストから、ファセットを選択します。

4. 「削除」をクリックして、ファセットを削除します。ファセットの削除を確認するメッセージが表示されます。

45.5.2.5 「類似作成」を使用した新規ファセットの作成

製品またはプラグインとともに出荷されるファセットは、変更できません。Oracle提供のコンテンツを強化または変更する場合、類似作成機能を使用して、ファセットのコピーを作成し、それを後で編集する必要があります。

類似作成機能の重要な制限は、ターゲット・タイプまたはエンティティ・タイプを変更できないことです。ファセットに含まれるパターンは、ターゲット・タイプまたはエンティティ・タイプによって異なる場合があります。類似作成を使用してこれらの属性を変更する場合、「エクスポート」を使用して元のファセットをエクスポートし、XMLの名前、ターゲット・タイプおよびエンティティ・タイプを編集して、新しいファセットとしてインポートする必要があります。

類似作成機能を使用して新しいファセットを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. リアルタイム監視ファセット・ライブラリ・タブを選択します。
Cloud Controlで「ファセット・ライブラリ」ページが表示され、既存のすべてのファセットが、ターゲット・タイプ、エンティティ・タイプなど、ファセットに関する詳細とともにリストされます。このページから、作成、類似作成、表示、削除、インポートおよびエクスポートなどの管理タスクを実行できます。

3. 作成する新規ファセットのベースとして使用するファセットをファセット表から選択します。

4. 「類似作成」をクリックします。
Cloud Controlに「ファセットの作成」ページが表示されます。クローニングするファセットに適用可能なすべての値が入力されています。このページを使用して、新規ファセットの値を編集し、「OK」をクリックします。

類似作成アクティビティで使用した元のベース・ファセットが変更された場合、その変更は新規作成されたファセットには反映されないことを理解しておくことが重要です。「類似作成」を使用する際に関係は保持されません。

5. 「ファセットの作成」ページの使用の詳細は、第45.5.2.2項「ファセットの作成および編集」を参照してください。

45.5.2.6 ファセットのインポートおよびエクスポート

ファセットを選択して、エクスポートまたはインポートできます。選択したすべてのファセットは、1つの出力ファイルにエクスポートされます。

インポートする際、同じ名前、ターゲット・タイプおよびエンティティ・タイプの組合せのファセットがすでに存在する場合は、インポートが失敗し、そのファセットがすでに存在することを示すエラーが表示されます。ユーザーはインポート・ファイルを変更して重複する名前を削除し、インポートを再試行する必要があります。

名前、ターゲット・タイプおよびエンティティ・タイプの組合せにより、一意のファセットが定義されます。異なるターゲット・タイプおよびエンティティ・タイプには、同じ名前のファセットを定義できます。

ファセットをエクスポートするには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. リアルタイム監視ファセット・ライブラリ・タブを選択します。
Cloud Controlで「ファセット・ライブラリ」ページが表示され、既存のすべてのファセットが、ターゲット・タイプ、エンティティ・タイプなど、ファセットに関する詳細とともにリストされます。このページから、作成、類似作成、表示、削除、インポートおよびエクスポートなどの管理タスクを実行できます。

3. ファセット・ライブラリ・ページにあるファセットのリストから、エクスポートするファセットを1つ以上選択し、「エクスポート」をクリックします。

4. 「オープン」ダイアログ・ボックスで、任意のXMLエディタを使用してファセットxmlファイルをオープンまたは保存することを選択し、ファイルを編集するか、別の場所に保存します。

ファセットをインポートするには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. リアルタイム監視ファセット・ライブラリ・タブを選択します。
Cloud Controlで「ファセット・ライブラリ」ページが表示され、既存のすべてのファセットが、ターゲット・タイプ、エンティティ・タイプなど、ファセットに関する詳細とともにリストされます。このページから、作成、類似作成、表示、削除、インポートおよびエクスポートなどの管理タスクを実行できます。

3. 「インポート」をクリックして、ファセット・ライブラリにインポートするファセットXMLファイルを選択します。

4. Cloud Controlで、インポートされたXMLファイルに指定されているファセットがすべてインポートされます。その後、ファセットを編集したり、ライブラリ内の他のファセットの場合と同様に任意のアクションを使用できます。

45.5.2.7 ルールでまだ使用されていないベース・ファセット属性の変更

ファセットが少なくとも1つのルールで(監視ファセットまたはフィルタ・ファセットとして)使用された後、作成されたルールはすでにファセットの属性にバインドされているため、ファセットのファセット名、ターゲット・タイプ、エンティティ・タイプまたはターゲット基準は変更できません。変更可能な属性は、ファセット・パターン、「パラメータ」および「説明」フィールドのみです。ルールはファセット名に依存しませんが、ユーザーはファセット名に基づいてファセットをルールで使用してきました。消費後のファセット名の変更を許可することは、ルールの作成者のコンプライアンス結果および監視の分析時にルール作成者に混乱をもたらすだけです。

現在使用していないファセットを過去に使用したことがある場合、履歴監視データがまだ過去のファセットに関連付けられるため、使用中のファセットと同一に扱われます。

Cloud Control製品に含まれているOracle提供のファセットを変更することはできません。Oracle提供のファセットを変更して使用するには、「類似作成」操作を実行し、新しく作成したファセットを必要に応じて変更します。

ベース・ファセット属性を変更するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. リアルタイム監視ファセット・ライブラリ・タブを選択します。
Cloud Controlで「ファセット・ライブラリ」ページが表示され、既存のすべてのファセットが、ターゲット・タイプ、エンティティ・タイプなど、ファセットに関する詳細とともにリストされます。このページから、作成、類似作成、表示、削除、インポートおよびエクスポートなどの管理タスクを実行できます。

3. 属性を変更して新規ファセットを作成するファセットを選択します。「類似作成」をクリックします。

4. 「ファセット名」に新しい名前を入力し、任意の属性を変更して、以前のファセットに基づいて新規ファセットを作成します。

45.6 例

この項では、コンプライアンスの使用例を示します。たとえば、次のものがあります。

- カスタム構成収集に基づくリポジトリ・ルールの作成

- エージェント側のコンプライアンス標準ルールと手動ルールの作成

- 違反の抑止

- 違反のクリア

45.6.1 カスタム構成収集に基づくリポジトリ・ルールの作成

この例では、ホスト・タイプのターゲットのサンプルの構成ファイル(この例では、/tmp/foo.xml)を収集するカスタム構成でコンプライアンス・ルールを作成および実行する方法について説明します。

この例では、次のコンテンツでサンプルの/tmp/foo.xmlファイルを作成します。

<some_config>
<prop foo="1"/>
<prop bar="2"/>
</some_config>

この手順には、次の方法が含まれます。

- カスタム構成の作成

- カスタムベースのリポジトリ・ルールの作成

- コンプライアンス標準の作成

- ターゲットの関連付け

- 結果の表示

カスタム構成の作成の手順:

次の手順では、カスタム構成の作成方法について説明します。

1. 「エンタープライズ」メニューから、「構成」、「構成拡張」の順に選択します。

2. 「構成拡張」ページから、「作成」をクリックします。「構成拡張の作成」ページが表示されます。

1. 「名前」(compliance_ccsなど)、説明(オプション)を入力し、「ターゲット・タイプ」(この例の場合は「ホスト」)を選択します。

2. 「ファイルとコマンド」セクションで、「デフォルト・ベース・ディレクトリ」を入力します(ディレクトリとして/tmpを使用します)。
これは例です。実際のターゲットの場合、ターゲットの構成ファイルが含まれるディレクトリにする必要があります。

注意: カスタム構成によって収集されるすべてのファイルは日次ベースで変更しないようにし、管理者の明示的なアクションによる非常にまれな変更のみにしてください。

3. 「追加」をクリックします。
- 「タイプ」列で、「ファイル」を選択します。

- 「ファイル/コマンド」列で、foo.xmlを入力します。「別名」列にfoo.xmlが自動的に入力されます。

注意: xmlのみ、またはfoo.xml表現のみでなく、任意のファイルを使用できます。カスタム構成は、多くのファイルおよび対応するパーサーをサポートしています。

- 「パーサー」列で、「XMLパーサー(デフォルト)」を選択します。

4. ページの下部にある「保存」をクリックします。

3. 「カスタム構成」ページで、compliance_cssを強調表示し、「デプロイ」をクリックします。デプロイページが表示されます。

1. 「追加」をクリックし、CSSをデプロイする必要があるターゲットを選択します。

2. 「検索と選択: ターゲット」ページで、ファイル/tmp/foo.xmlが作成されたホスト・ターゲットを強調表示し、「選択」をクリックします。

3. 「デプロイ」ページで「適用」をクリックします。

4. 「保留中のデプロイメント・アクションの発行」ポップアップで、「はい」を選択します。このアクションにより、デプロイメント・アクションが発行されます。
「デプロイ」ページで、「ステータス」列に「デプロイは成功しました」と表示されるまで「ステータスのリフレッシュ」をクリックしてデプロイのステータスをリフレッシュします。

5. これでデプロイが発行されたので、「取消」をクリックしてページを終了します。(注意: 前述の「適用」のかわりに「保存」をクリックしていたら、デプロイ・アクションの発行の直後にページが終了していました。)

カスタム構成収集に基づくカスタムベースのリポジトリ・ルールの作成の手順:

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・ライブラリ」ページで、「コンプライアンス標準ルール」タブをクリックします。

3. 「作成」をクリックします。

1. 「ルールの作成」ポップアップで、「リポジトリ・ルール」を選択し、「続行」をクリックします。

2. 「ルールの作成: リポジトリ・ルール: 詳細」ページで、「ルール名」に入力します(compliance_css_ruleなど)。

3. 「コンプライアンス・ルールの状態」では「開発」を選択し、「重大度」では「マイナー警告」を選択します。「適用可能対象」では「ホスト」を選択します。ページの右上にある「次」をクリックします。

4. 「ルールの作成: リポジトリ・ルール: チェック定義(問合せ)」ページで、「モデル問合せ」をクリックします。「新しい検索基準」ページが表示されます。

1. 「よく使用される検索基準」の下の「構成アイテム」メニューから「compliance_css (解析済データ)」を選択します。

2. 「ホスト」セクションおよび「解析済データ」サブセクションで、「データソース」の「次を含む」にfoo.xmlを入力します。「属性」では、「完全一致」比較演算子を選択し、fooを入力し、サンプル・ファイル内でfooを参照します。(注意: 「データソース」および「属性」のこれらの式にはワイルドカード文字として%を使用することもできます。)

3. 「検索」をクリックし、このフィルタで返された行を表示します。このファイル内の属性fooに対して値1を持つデータが表に表示されます。

4. 「OK」をクリックします。

5. 「ルールの作成: リポジトリ・ルール: チェック定義(問合せ)」が再表示されますが、今回は「SQLソース」が表示されます。

6. 「次へ」をクリックします。注意: 通常、必要に応じて、処理を続行する前に問合せを更新することもできます。

5. 「ルールの作成: リポジトリ・ルール: チェック定義(違反条件)」ページが表示されます。

1. 「情報」列を除くすべての列を「キー」列(「値」、「属性」、「コンテナ」および「データソース名」)として選択します。

2. ページの「条件タイプ」セクションで「単純条件」を選択し、「列名」で「値」を選択し、「比較演算子」を等号(=)に変更します。「デフォルト値」列に1を入力します。「次へ」をクリックします。

6. 「ルールの作成: リポジトリ・ルール: テスト」ページで、「ターゲット名」フィールドの横にあるアイコンをクリックします。「検索と選択: ターゲット」ポップアップが表示されます。カスタム構成がデプロイされたホストを特定します。属性を選択して、「選択」をクリックします。

7. 「ルールの作成: リポジトリ・ルール: テスト」ページで、「テストの実行」をクリックします。テストが正常に実行されたら、「テストの実行 - 正常に完了しました」という内容の確認が表示されます。
前述の手順5で違反条件として値1を指定したこと、およびサンプル・ファイルの属性fooの値が1であったことから、テストの実行後に1つの違反が表示されます。「閉じる」をクリックします。

8. 「ルールの作成: リポジトリ・ルール: テスト」ページで、「次」をクリックします。

9. 「ルールの作成: リポジトリ・ルール: 確認」ページで、追加した情報がすべて正しいことを確認します。「終了」をクリックします。

コンプライアンス標準の作成の手順:

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス標準」タブをクリックし、「作成」をクリックします。

3. 「コンプライアンス標準の作成」ポップアップで、「名前」フィールドにcompliance_css_csを入力し、「適用可能対象」メニューから「ホスト」を選択し、「標準タイプ」として「リポジトリ」を選択します。「続行」をクリックします。

4. コンプライアンス標準ページに、compliance_css_csコンプライアンス標準に関する情報が表示されます。左側にあるcompliance_css_csを右クリックし、右クリック・メニューで「ルールの追加...」オプションを選択します。

5. 「ルール参照を含める」ポップアップで、compliance_css_ruleを選択します。「OK」をクリックします。「保存」をクリックし、compliance_css_csを保存します。

6. 「コンプライアンス・ライブラリ」ページに、コンプライアンス標準が作成されたことを示す確認メッセージが表示されます。「OK」をクリックします。

ターゲットを関連付けるには、次の手順に従います。

1. 作成したcompliance_css_csを選択します。「ターゲットの関連付け」をクリックします。

2. 「コンプライアンス標準へのターゲット・アソシエーション: compliance_css_cs」ページで、「追加」をクリックし、ターゲットを追加します。

3. 「検索と選択: ターゲット」ページで、/tmp/foo.xmlが存在するターゲットを選択し、「選択」をクリックします。「OK」をクリックします。
これにより、関連付けを保存するかどうかが尋ねられます。「はい」または「いいえ」をクリックします。これにより、コンプライアンス標準が処理のためにターゲットに対して発行されたことを示す情報メッセージが表示されます。

結果を表示するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「結果」を選択します。
「コンプライアンス結果」ページで、compliance_css_csコンプライアンス標準を選択し、「詳細を表示」をクリックして、作成したコンプライアンス標準の詳細を表示します。

2. compliance_css_ruleに関連付けられた「違反」タブをクリックします。ターゲットは1つ違反に関連付けられています。

3. ツリー内のルール・ノードをクリックして「違反イベント」タブを表示してから、このタブをクリックし、ルールの違反の詳細を表示します。違反表内の違反行をクリックし、違反の詳細を表示します。

45.6.2 エージェント側のコンプライアンス標準ルールと手動ルールの作成

この例の目的は、DBMSの権限アクションをテストするエージェント側のコンプライアンス標準ルールと手動ルールを作成することです。

エージェント側のコンプライアンス標準ルールを作成するには、次の手順を実行します。

1. 構成拡張を作成します。

2. エージェント側のコンプライアンス・ルールを作成します。

3. 手動ルールを作成します。

4. コンプライアンス標準の作成

5. ルールを構成標準に追加します。

6. コンプライアンス標準をターゲットに関連付けます。

構成拡張の作成

次の手順を実行して、構成拡張を作成します。

1. 「エンタープライズ」メニューから「構成」を選択し、「構成拡張」を選択します。

2. 構成拡張ページで、「作成」をクリックします。

3. 拡張の名前(例: DG0142 DBMS Privileged action audit)を入力します。この名前は、チェック定義ページで使用します。

4. ターゲット・タイプに「データベース・インスタンス」を選択します。

5. 「SQL」タブを選択します。

6. 「加算」をクリックして、最初のSQL文を追加します。

- 「SQL」フィールドで、次のように入力します。

select distinct 'Unauthorized user '||owner||' owns application objects in the database.' value
from dba_objects where
owner not in ('ANONYMOUS','AURORA$JIS$UTILITY$', 'AURORA$ORB$UNAUTHENTICATED', 'CTXSYS','DBSNMP','DIP','DVF','DVSYS','EXFSYS','LBACSYS','MDDATA',
'MDSYS','MGMT_VIEW','ODM','ODM_MTR', 'OLAPSYS','ORDPLUGINS', 'ORDSYS',
'OSE$HTTP$ADMIN','OUTLN','PERFSTAT', 'PUBLIC','REPADMIN','RMAN','SI_INFORMTN_SCHEMA',
'SYS','SYSMAN','SYSTEM','TRACESVR', 'TSMSYSWK_TEST','WKPROXY','WKSYS',
'WKUSER','WMSYS','XDB', 'OWBSYS', 'SCOTT', 'ORACLE_OCM', 'ORDDATA', 'APEX_030200',
'OWBSYS_AUDIT', 'APPQOSSYS', 'FLOWS_FILES')
and owner not in (select grantee from dba_role_privs
where granted_role='DBA')

- 別名(たとえば、DBMS application object ownership)を入力します。この別名は、この構成拡張の最上部にルールを定義する際に役立ちます。

- 「パーサー」には、データベース問合せパーサーを使用します。

7. 「加算」をクリックして、2つ目のSQL文を追加します。

- SQL

select distinct 'Application object owner account '||owner||' is not disabled.' value
from dba_objects, dba_users where
owner not in ('ANONYMOUS','AURORA$JIS$UTILITY$',
'AURORA$ORB$UNAUTHENTICATED','CTXSYS','DBSNMP','DIP','DVF',
'DVSYS','EXFSYS','LBACSYS','MDDATA','MDSYS','MGMT_VIEW','ODM',
'ODM_MTR','OLAPSYS','ORDPLUGINS','ORDSYS','OSE$HTTP$ADMIN',
'OUTLN','PERFSTAT','PUBLIC','REPADMIN','RMAN',
'SI_INFORMTN_SCHEMA','SYS','SYSMAN','SYSTEM','TRACESVR', 'TSMSYS',
'WK_TEST','WKPROXY','WKSYS','WKUSER','WMSYS','XDB')
and owner in (select distinct owner from dba_objects where object_type <>
'SYNONYM')
and owner = username and upper(account_status) not like '%LOCKED%'

- 別名(たとえば、DBMS application object owner accounts)を入力します。

- 「パーサー」には、データベース問合せパーサーを使用します。

8. 「保存」をクリックし、次に「構成」ボックスで「はい」をクリックします。

図45-10 完了した「構成拡張の作成」ページ

エージェント側のコンプライアンス標準ルールの作成

エージェント側のコンプライアンス・ルールを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・ライブラリ」で、「コンプライアンス標準ルール」をクリックします。

3. 「作成」をクリックします。「ルールの作成」ポップアップで、「エージェント側のルール」を選択します。

4. 「続行」をクリックします。

5. 「ルールの作成: エージェント側のルール: 詳細」ページで、次の情報を設定します(図45-11を参照)。

1. 名前: DBMS application object ownership

2. コンプライアンス・ルールの状態: 開発

3. 重大度: クリティカル

4. 適用可能対象: データベース・インスタンス

5. 説明: アプリケーション・オブジェクトは、所有権が承認されたアカウントにより所有される必要があります。

6. 原理: データベース・オブジェクトの所有権は、所有するオブジェクトへのアクセス権を他のサブジェクトに割り当てる権限を含めて、所有するオブジェクトに対する完全な権限を意味します。オブジェクトの所有権が管理または制御されていないと、オブジェクトに対する承認されていないアクセスまたは変更が発生する可能性があります。

7. 「次へ」をクリックします。

図45-11 完了したコンプライアンス標準ルールの「詳細」ページ

6. 「ルールの作成: エージェント側のルール: チェック定義」ページで、以前に定義した構成拡張と別名を検索します。図45-12を参照してください。
注意: 構成拡張名と別名は、1つに結合されて「構成拡張」の名前と「名前」フィールドに表示されます。この例では、完全な名前は、DG0142 DBMS Privileged action audit-DBMS application object ownershipです。

「次へ」をクリックします。

図45-12 完了したコンプライアンス標準ルールの「チェック定義」ページ

7. 「ルールの作成: エージェント側のルール: テスト」ページで、ターゲットを検索し、「テストの実行」をクリックします。テストが実行中であることを示すポップアップが表示されます。確認ポップアップの「閉じる」をクリックします。図45-13を参照してください。
注意: 違反のあるテスト結果を故意に生成することもできます。たとえば、target type equal to hostをテストして、ホスト・ターゲットを評価すると、違反結果が表示されます。

「次へ」をクリックします。

図45-13 完了したコンプライアンス標準ルールの「テスト」ページ

8. 「ルールの作成: エージェント側のルール: 確認」ページで、情報が意図したものであることを確認します。意図したものとは異なる場合、「戻る」をクリックし、必要に応じて修正します。情報が正しい場合は、「終了」をクリックします。図45-14を参照してください。

図45-14 完了したコンプライアンス標準ルールの「確認」ページ

9. これらの手順を2つ目のルールに対して繰り返します。

注意: コンプライアンス標準ルールは、「終了」をクリックするまで定義されません。

手動ルールの作成

この手動ルールを作成する目的は、自動化できないチェックを追跡し、テスト計画とプロシージャが遵守していることを本番での実装前に確認することです。

手動ルールを作成するには、次の手順に従います。

1. 「コンプライアンス・ライブラリ」で、「コンプライアンス標準ルール」をクリックします。

2. 「作成」をクリックします。「ルールの作成」ポップアップで、「手動ルール」を選択します。

3. 「続行」をクリックします。

4. 「手動ルールの作成」ページで、次の情報を設定します(図45-15を参照)。

1. 名前: DBMS testing plans and procedures

2. コンプライアンス・ルールの状態: Production

3. 重大度: 警告

4. 適用可能対象: データベース・インスタンス

5. 説明: DBMSのインストール、アップグレードおよびパッチをテストするための計画およびプロシージャは、本番での実装前に定義し、遵守する必要があります。

6. 原理: 既存のソフトウェアに対する更新とパッチの適用には、セキュリティの強化、製品の機能の強化または製品への機能の追加の意図があります。ただし、残念なことに、更新またはパッチの適用が、本番システムを動作不能にしたり、重大な脆弱性をもたらすことがよくあります。また、一部の更新は、セキュリティ要件を満たさない許容不可能な設定にセキュリティ構成を戻します。これらの理由により、更新とパッチをオフラインでテストしてから本番環境に導入することがよい方法です。

7. 推奨: DBMSのインストール、アップグレードおよびパッチをテストするためのプロシージャを開発、文書化および実装してから、本番システムにデプロイします。

8. コンプライアンス・メッセージ: DBMSのインストール、アップグレードおよびパッチをテストするための計画およびプロシージャは、本番での実装前に定義し、遵守します。

9. 非コンプライアンス・メッセージ: DBMSのインストール、アップグレードおよびパッチをテストするための計画およびプロシージャは、本番での実装前に定義または遵守されません。

10. 参照URL: http://iase.disa.mil/stigs/index.html

11. ルールのキーワード: セキュリティ

12. 「終了」をクリックします。

図45-15 完了した「手動ルール」ページ

コンプライアンス標準の作成

標準コンプライアンスを作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・ライブラリ」ページで、「コンプライアンス標準」をクリックします。

3. 「作成」をクリックします。「コンプライアンス標準の作成」ポップアップで、次を設定します(図45-16を参照)。

- 名前: CS1 - DB Check

- 適用可能対象: データベース・インスタンスの選択

- 作成者: SYSMAN

- 標準タイプ: エージェント側

- 「続行」をクリックします。

図45-16 完了した「コンプライアンス標準の作成」ポップアップ

4. 「コンプライアンス標準: CS1 - DB Check」ページのナビゲーション・ツリーで、標準を右クリックします。「ルールの追加」を選択します。「ルール参照を含める」で、DBMS application object ownership、DBMS application owner accountsおよびDBMS testing plans and proceduresを選択します。図45-17を参照してください。「OK」をクリックします。

図45-17 コンプライアンス標準ルール

5. 「保存」をクリックします。

ターゲットへのコンプライアンス標準の関連付け

コンプライアンス標準をターゲットに関連付けるには、次の手順に従います。

1. 「エンタープライズ」メニューから「コンプライアンス」を選択し、「ライブラリ」を選択します。

2. 「コンプライアンス・ライブラリ」ページで、「コンプライアンス標準」をクリックします。

図45-18 「コンプライアンス標準ライブラリ」ページ

3. 新たに作成した標準(CS1 - DB Check)をハイライト表示し、「ターゲットの関連付け」ボタンをクリックします。

4. 「コンプライアンス標準へのターゲット・アソシエーション: CS1 - DB Check」ページで、「追加」をクリックします。

5. 1つ以上のターゲット(Oemrep_Databaseなど)を選択します。図45-19を参照してください。

図45-19 完了した「ターゲット・アソシエーション」ページ

6. 「選択」をクリックします。「OK」をクリックします。

7. 「はい」をクリックして、アソシエーションを保存します。

45.6.3 違反の抑止

この例の目的は、違反を抑止することです。「エージェント側のコンプライアンス標準ルールと手動ルールの作成」で定義した手動ルールにより発生する違反を抑止します。

次の手順に従います。

1. 「コンプライアンス」メニューから、「結果」を選択します。

2. 「評価結果」タブで、CS1 - DB Checkという名前のコンプライアンス標準を見つけます。標準に対する違反があることに注意してください。

図45-20 「評価結果」タブでのCS1 - DB Checkコンプライアンス標準

3. コンプライアンス標準を選択し、「違反の管理」タブをクリックします。

4. 「違反の管理」ページで、「抑止解除された違反」タブが選択されていることを確認します。

5. 「DBMS testing plans and procedures」を選択します。図45-21を参照してください。

図45-21 「違反の管理」ページ - 「抑止解除された違反」

6. 違反を抑止するには、「違反の抑止」タブをクリックします。

7. 「違反の抑止の確認」ポップアップで、「無期限に違反を抑止」を選択します。

8. 抑止された違反は、「評価結果」ページに表示されなくなります。図45-22を参照してください。

図45-22 違反が抑止された後の「評価結果」ページ

9. 違反の抑止を解除するには、「抑止された違反」タブを使用します(図45-23参照)。行を選択し、「違反の抑止解除」をクリックします。
違反の抑止を解除すると、コンプライアンス・スコアが、抑止解除された違反を考慮して再計算されます。

図45-23 「抑止された違反」タブを表示している「違反の管理」ページ

45.6.4 違反のクリア

手動ルール違反をクリアすると、違反がクリアされます。また、コンプライアンス・スコアが対応するコンプライアンス標準またはターゲットに対して上昇します。違反をクリアするには、次の手順に従います。

1. 「コンプライアンス」メニューから、「結果」を選択します。CS1 - DB Checkコンプライアンス標準を選択します。

2. 「違反の管理」をクリックします。

3. 「違反の管理」ページで、DBMS testing plans and proceduresルールをハイライト表示します。

4. ルール違反の管理タブをクリックします。

5. 「違反の管理」ページで、ルールをハイライト表示し、「手動ルール違反」タブをクリックします。

図45-24 手動ルール違反のクリア

6. 行を選択し、「違反のクリア」をクリックします。「違反のクリアの確認」ポップアップで、「無期限に違反をクリア」を選択するか、または「違反のクリア期間」を選択して日付を指定します。完全を期すために、違反をクリアした理由を入力します。

46 Enterprise Data Governanceの管理

この章では、Enterprise Data Governanceを紹介し、その機能を使用して機密データを保護する方法を説明します。この章の内容は次のとおりです。

- Enterprise Data Governanceの概要

- Enterprise Data Governanceの使用

46.1 Enterprise Data Governanceの概要

この項では、Enterprise Data Governanceの概要について説明します。この項の内容は次のとおりです:

- Enterprise Data Governanceについて

- 保護ポリシーについて

- アプリケーション署名について

46.1.1 Enterprise Data Governanceについて

エンタープライズ・データ・ガバナンスでは、データ・センター内の機密データを識別、保護、管理および追跡するための包括的なソリューションが提供されます。このソリューションは、この保護を提供するための二又のアプローチが含まれます。

- 機密データが含まれる可能性のあるデータベースのユーザー開始の自動検出を定期的に実行します。これはメタデータの検出で、スキーマ、表および列名のパターンを含むメタデータのみを参照するため、浅いスキャンとも呼ばれます。

- メタデータ検出で識別されるデータベースの機密データのユーザー開始の検出を実行します。これはデータ検出で、実際のデータをドリル・ダウンして、ユーザー指定の機密タイプおよびオブジェクト・レベルの保護の詳細に一致するものを検索するため、ディープ・スキャンとも呼ばれます。

エンタープライズ・データ・ガバナンスでは、推奨されるワークフローの最初のステップを形成し、機密データをマスクします。

1. 機密データを含む可能性のあるデータベースを検出します。

2. データベース候補の検出結果により(それに限定されない)、機密データをさらに識別するためにデータベースの表および列内のデータにドリルダウンします。

3. この検出結果により、機密としてフラグ列にフラグを付け、アプリケーション・データ・モデル(ADM)のコンテキスト内で識別します。

4. ADM内でこれらの列を選択し、テスト環境でデータを保護するマスキング・フォーマットを適用します。

46.1.2 保護ポリシーについて

保護ポリシーの定義では、機密データ・オブジェクトを保護するためのセキュリティシ・メカニズムを定義します。これは、機密データ・オブジェクトが保護される方法を制御します。機密オブジェクトのポリシーが作成されると、同様のタイプおよび構造のすべての機密データ・オブジェクトに適用可能なテンプレートとして機能します。これにより、データベース・クラウド内の場所に関係なく、機密データ・オブジェクトは常に保護されます。

保護ポリシーは、Oracle Databaseで使用可能なセキュリティ機能にマップされます。メタデータ検出機能では、次のデータベース・セキュリティ機能の1つ以上で保護されるオブジェクトを含むデータベースを識別します。

- 透過的データ暗号化(TDE): データベースへの書込み時にデータを自動的に暗号化し、データのアクセス時に自動的に復号化するデータベース機能。

- データ・リダクション: マスクされたバージョンのデータを非特権ユーザーに表示することでデータを保護するデータベース機能。マスクされたバージョンのデータは、データのフォーマットおよび参照整合性を保持するため、データを使用するアプリケーションは想定どおりに引き続き機能します。

- 仮想プライベート・データベース(VPD): セキュリティ条件を使用してデータを保護し、行および列レベルでデータ・アクセスを強制するデータベース機能。

- Oracle Label Security (OLS): データ分類を提供し、セキュリティ・ラベルを使用してアクセスを制御するデータベース機能。

メタデータ検出は、リストされる各セキュリティ機能に関してチェックします。ただし、スキャンでは、保護ポリシーの詳細は収集されず、必ずしもすべてのポリシーが考慮されるわけではありません。検出された保護ポリシーは、機密の可能性があるものとしてデータベースのフラグ付けに十分です。この戦略は、高速および軽量なスキャンを維持します。

46.1.3 アプリケーション署名について

アプリケーション署名は、特定のアプリケーションを一意に識別するスキーマ、表、ビューなどのデータベース・オブジェクトのセットです。これらのオブジェクトを含むデータベースは、アプリケーションを含むものと想定され、機密データベースと候補として記載されています。Oracleでは、次のアプリケーションの署名を提供しています。

- Oracle E-Business Suite

- Oracle Fusion Applications

- Oracle PeopleSoft Enterprise

また、カスタム・アプリケーション署名を作成することもできます(46.2.5項を参照)。

46.2 Enterprise Data Governanceの使用

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

- Enterprise Data Governanceダッシュボード

- 機密データベースの検出結果の処理

- メタデータ検出ジョブの処理

- データ検出ジョブの処理

- カスタム・アプリケーション署名の作成

46.2.1 Enterprise Data Governanceダッシュボード

Enterprise Data Governanceでは、機密データが含まれている可能性があるエンタープライズ内のデータベースを特定し、その候補にあるデータを評価して機密データが存在するかどうかを判別するための手段が提供されます。

Enterprise Data Governanceダッシュボードは、検出アクティビティのサマリーを表示し、次へのリンクを提供します。

- 機密検出ジョブの結果を確認します(第46.2.2項を参照)。

- メタデータ検出ジョブを管理および確認します(第46.2.3項を参照)。

- データ検出ジョブを管理および確認します(第46.2.4項を参照)。

- アプリケーション署名を作成します(46.2.5項を参照)。

ダッシュボードから、アプリケーション・データ・モデル(ADM)環境および機密列タイプも管理できます。これらのアクティビティの詳細は、『Oracle Data Masking and Subsettingガイド』の第2章「アプリケーション・データ・モデル」を参照してください。

Cloud Controlコンソール内のダッシュボードに移動するには、「ターゲット」メニューで「データベース」を選択し、「セキュリティ」メニューで「Enterprise Data Governance」を選択します。ダッシュボードから移動するたびに、上部にある「Enterprise Data Governance」ブレッド・クラムを使用して戻ります。

46.2.2 機密データベースの検出結果の処理

機密データベース検出サマリー・ページで、次のタスクを実行できます。

- 機密データを持つとして検出されたデータベース、または機密データ候補と考えられるデータベースを確認します。

- メタデータ検出ジョブを作成します(第46.2.3.1項を参照)。

- データ検出ジョブを作成します(第46.2.4.1項を参照)。

- メタデータ列の数字をクリックして、検出されたアイテムのポップアップ・リストを表示します。たとえば、データ保護列の数字をクリックして、どのデータ保護がデータベース候補に対して機能しているかを確認します。

- データベース名自体をクリックして、データベース・インスタンス・ホームページを開きます。

46.2.3 メタデータ検出ジョブの処理

メタデータ検出ジョブ・ページで、次のタスクを実行できます。

- メタデータ検出ジョブを作成します(第46.2.3.1項を参照)。

- 自動メタデータ検出を管理します。

- ジョブの結果を管理します。

メタデータ検出ジョブは、スキーマ、表および列名のパターンでのみ検索し、データ自体では検索しないため、ジョブの実行に必要なデータベース資格証明はありません。

46.2.3.1 メタデータ検出ジョブの作成

データベース・メタデータをスキャンして機密データを含む可能性のある候補を検索するメタデータ検出ジョブを実行します。

メタデータ検出ジョブの作成には、次の手順が含まれます。

1. メタデータ検出ジョブの作成をクリックします。

2. 機密列タイプ、アプリケーション署名およびデータ保護の基準を設定します。
機密列タイプの場合、行を選択し、「検索基準の表示」をクリックして、適用可能な基準(パターン一致、正規表現フォーマット、ブール条件など)を表示します。

終了したら、「次へ」をクリックして続行します。

3. メタデータ検出を実行するターゲットを選択します。最初にターゲット・タイプを選択してから、「追加」をクリックして、指定したタイプからターゲットを選択します。ターゲット検索基準の一部として、構成検索ライブラリから検索を含めることができます。
異なるタイプのターゲットを選択できません。あるタイプのターゲットを選択してから別のタイプのターゲットを選択した場合、最初に選択したタイプのターゲットは選択解除されます。

終了したら、「選択」をクリックして選択ダイアログを閉じ、「次」をクリックして続行します。

4. ジョブをスケジュールします。意味のわかりやすい名前および説明を指定します。必要に応じて他のパラメータを設定します。メタデータ検出は、データベースの機密データを慎重に監視するために、通常は繰り返し実行されるジョブであることに注意してください。
終了したら、「発行」をクリックします。

5. ページの上部に確認メッセージが表示されます。リンクをクリックして、ジョブ・システムのジョブ詳細を表示します。メタデータ検出ジョブ・ページをリフレッシュして、完了したジョブを表示します。

46.2.3.2自動メタデータ検出の管理

自動メタデータ検出は、ユーザーが開始するメタデータ検出と独立して行われ、ターゲット検出に直接関連付けます。デフォルトでは、ターゲット検出の一部としてデータベースが検出されるたびに、メタデータ検出ジョブがそのデータベースで実行されます。「自動メタデータ検出」ドロップダウン・メニューから「ターゲット検出中のメタデータ検出の無効化」を選択することにより、この機能を無効にできます。メタデータ検出ジョブをいつ実行するか、およびどのデータベースで実行するかの制御を強化する場合、この機能を無効にできます。この機能を無効にすると、メニュー選択はターゲット検出中にメタデータ検出を有効化に切り替わり、それにより、自動メタデータ検出を再開するオプションが表示されます。

この機能を保持するよう選択することもできますが、別の基準のセットが必要です。自動メタデータ検出の即時利用可能な基準では、Oracle定義の機密列タイプ、データ保護ポリシーおよびアプリケーション署名を使用しますが、デフォルト設定を変更し、ユーザー定義のエンティティを追加することもできます。自動メタデータ検出ドロップダウン・メニューから自動メタデータ検出パラメータの編集を選択して、基準を編集します。

46.2.3.3 メタデータの検出結果の管理

メタデータ検出ジョブの結果によって、どのデータベースに実際に機密データおよび機密性が含まれるかを確認できます。

メタデータ検出ジョブの結果を処理するには、次を実行します。

1. 表の上部にあるジョブを選択して、下部の検出結果を表示します。

2. 「表示」ドロップダウン・リストを使用して、評価されるすべてのデータベース、または機密データを持つデータベースのみ、または機密データを持たないデータベースのみを基にして、表示をフィルタ処理します。

3. 自動結果の詳細の表示をクリックして、指定した基準に基づいて一致するメタデータを表示します。

4. メタデータ列の数字をクリックして、検出されたアイテムのポップアップ・リストを表示します。たとえば、データ保護列の数字をクリックして、どのデータ保護がデータベース候補に対して機能しているかを確認します。

5. データベース名自体をクリックして、データベース・インスタンス・ホームページを開きます。

46.2.4 データ検出ジョブの処理

データ検出ジョブ・ページで、次のタスクを実行できます。

- データ検出ジョブの作成

- ジョブの結果の管理

46.2.4.1 データ検出ジョブの作成

メタデータ検出ジョブで特定されたデータベース候補内の機密データを検索するデータ検出ジョブを実行します。

データ検出ジョブの作成には、次の手順が含まれます。

1. データ検出ジョブの作成をクリックします。

2. 検索アイコンをクリックして、データ検出を実行するデータベースの候補を選択します。ターゲット検索基準の一部として、構成検索ライブラリから検索を含めることができます。
終了したら、「選択」をクリックして選択ダイアログを閉じます。

3. 機密列タイプ、アプリケーション署名およびデータ保護の基準を設定します。
機密列タイプの場合、指定した列の行を選択し、「検索基準の表示」をクリックして、適用可能な基準(パターン一致、正規表現フォーマット、ブール条件など)を表示します。適切なサンプル・サイズを構成すると思われる行数を設定します。空の表をスキャンするかどうかを示します。

データは列を機密にするものであるということに基づいて、データ検出ジョブでは、空の表を無視します。ただし、列名やコメント・パターンなど、他の要素に基づいた検出検索で、空の表を含めることがあります。空の表はデータ値がない表として定義されますが、メタデータ検出ジョブでは、統計収集ジョブがまだ実行されていない場合、空ではない表を空としてレポートすることがあります。

終了したら、「次へ」をクリックして続行します。

4. スキーマおよび表パラメータ(含めるまたは除外するもの)を指定します。パターン一致を使用して、検索の有効範囲を指定します。あるいは、いずれかまたは両方のエンティティのすべてを含めるよう選択できます。
終了したら、「次へ」をクリックして続行します。

5. ジョブをスケジュールします。意味のわかりやすい名前および説明を指定します。データベースにアクセスするための資格証明を指定します。ジョブ・スケジュールを設定します。
終了したら、「発行」をクリックします。

6. ページの上部に確認メッセージが表示されます。リンクをクリックして、ジョブ・システムのジョブ詳細を表示します。データ検出ジョブ・ページをリフレッシュして、完了したジョブを表示します。

46.2.4.2 データの検出結果の管理

データ検出の結果を使用して、機密的な列を特定し、データベースをアプリケーション・データ・モデルに関連付けます。

データ検出ジョブの結果を処理するには、次を実行します。

1. ジョブ行のデータベース名のリンクをクリックして、データベース・インスタンス・ホームページを開きます。ジョブ・ステータスのリンクをクリックして、ジョブ・システムのジョブ・サマリー・ページを開きます。

2. オプションで、新規ADMまたは既存ADMのいずれかにデータベースを関連付けます。データ検出ジョブ行を選択し、アプリケーション・データ・モデルの割当てをクリックして、適切なオプションを選択します。

3. 表の上部にあるジョブを選択して、下部の検出結果を表示します。ジョブ基準のタブをクリックして、ジョブの結果を確認します。必要に応じてタブ・コンテンツを展開して、詳細にドリルダウンします。

4. 機密データ列タブをクリックして、機密列のデータの元および性質を表示します。示されているように、割り当てられたADMがある場合、行を選択し、「機密ステータスの設定」ドロップダウン・メニューからステータスを選択して、機密性ステータスをインタラクティブに設定できます。
表の情報を使用して、列を機密として宣言する決定を通知します。たとえば、名前とデータの割合での両方の基準に一致するサンプル・データおよび列は、列の機密性の強力なインジケータとなります。

データ検出ジョブに割り当てられたADMがない場合、機密性ステータスは無効になり、関連するスキーマがアプリケーションのかわりに表示されます。

5. アプリケーション署名タブをクリックして、アプリケーションを一意に識別するデータベース・オブジェクトを表示します。

6. データ保護ポリシーを使用したオブジェクトタブをクリックして、サポートされた保護ポリシーによって保護されている、ジョブが検出した特定のオブジェクトを表示します。
検出されたオブジェクトで、機密列ステータスを次のように設定します。

1. 機密列の選択をクリックします。

2. ジョブによって検出されたデータベースにログインするための資格証明を指定します。

3. 列のリスト・ボタンをクリックして、保護ポリシーの対象となる表内のすべての列を表示します。

4. ステータスを機密に設定し、アプリケーション内で機密とみなされている列に対して関連付けられている機密列タイプを選択します。

5. 選択内容の確認が終了したら、「OK」をクリックします。

選択された列は、割当て済のADM内で機密と識別されます。

データ検出ジョブに割り当てられたADMがない場合、機密ステータス機能は無効になり、関連するスキーマがアプリケーションのかわりに表示されます。

46.2.5 カスタム・アプリケーション署名の作成

企業内の機密データ検出が容易になるように、アプリケーション署名をカスタマイズします。

カスタム・アプリケーション署名の作成では、次の手順を実行します。

1. Enterprise Data Governanceダッシュボードから、アプリケーション署名リンクを開きます。
「作成」をクリックします。エディタ・ページが開きます。

2. 名前および説明(オプション)を指定します。

3. 「追加」をクリックし、使用可能なオブジェクトから選択して、署名に含めます。これらのオブジェクト・タイプのいずれかに指定された名前を明示的に指定することも、パターン(HR%など)を使用して指定することもできます。

- スキーマ - スキーマ名は必須です。

- 表 - スキーマ名はオプションです。表名は必須です。

- ビュー - スキーマ名はオプションです。ビュー名は必須です。

「OK」をクリックします。オブジェクトが表に表示されます。

4. 署名に追加のオブジェクトを含める場合は、手順3を繰り返します。すべての署名オブジェクトが、一致するようにデータベースで検出される必要があることに注意してください。

5. 終了したら、「OK」をクリックして、署名の定義を完了します。
エディタ・ウィンドウが閉じ、アプリケーション署名ページの表に署名が表示されます。メタデータ検出ジョブおよびデータ検出ジョブの検索基準として、署名を使用できるようになります。

47 データベース・スキーマ変更の管理

この章では、次の各項でデータベースの変更管理ソリューションの概要について説明します。

- データベースの変更管理の概要

- スキーマ・ベースラインの使用

- スキーマ比較の使用

- スキーマ同期の使用

- 変更計画の使用

- データベース・データ比較の使用

47.1 データベースの変更管理の概要

エンタープライズ・アプリケーションのライフサイクルを管理するには、開発、ステージング、本番およびテストなどの様々な目的のためにアプリケーション・データベースのコピーを複数保持する必要があります。これらの各データベースは、それぞれのプロセスに合せる必要があります。たとえば、本番データベースの場合、適切な本番用コントロール・プロシージャに必ず従う必要があります。管理者は、非認証の変更(必要な変更の承認なしで索引が削除されるなど)を検出する手段を持っている必要があります。そのような場合、本番データベースへの変更を毎日または毎週監視することが重要になります。

ライフサイクル管理のもう1つの重要な側面は、データベース・コンプライアンス(すべてのデータベースを基準となる構成に準拠させること)です。組織の標準またはベスト・プラクティスに準拠することで、データベースの効率性、メンテナンス性および運用の容易性が保証されます。

開発データベースの場合、開発者が変更を加えますが、その変更はデータベース管理者がステージング・データベースまたはテスト・データベースに統合および伝播する必要があります。その目的は、開発環境に加えられた変更を識別し、本番データベースにすでに存在する他の変更を考慮しながら、ステージング・データベースまたはテスト・データベースに同じ変更を加えることです。

通常、ほとんどのアプリケーションは、時間の経過とともにアップグレードされます。また、ほとんどのアプリケーションは、要件に合うようにビジネス・ユーザーによってカスタマイズされます。アプリケーションのカスタマイズは、通常、アプリケーション・ベンダーにより提供されるデータベース・オブジェクトまたはPL/SQLモジュールに依存します。アップグレード・スクリプトはアプリケーション・ベンダーから提供されるため、顧客はアップグレード手順が独自のカスタマイズ内容にどの程度影響するかについてほとんどわかりません。顧客は、アップグレード・データベースをテストする場合、アップグレードの前後にアプリケーション・スキーマのベースラインを取得できます。前後のベースラインを比較することで、アプリケーションにより変更されたモジュールがわかります。これにより、アプリケーションをアップグレードした結果としてカスタマイズ内容が受ける影響の程度をより正確に把握できます。

開発者およびデータベース管理者がデータベース環境の変更を管理できる変更管理の主な機能は次のとおりです。

- スキーマ・ベースライン: ある時点におけるデータベースおよび関連データベース・オブジェクトの定義

- スキーマ比較: ベースライン(またはデータベース)と他のベースライン(またはデータベース)間の相違の完全なリスト

- スキーマ同期化: ベースラインのデータベース定義取得から(またはデータベースから)ターゲット・データベースに変更を移行するプロセス

- スキーマ変更計画: 特定の変更を開発環境から1つ以上のターゲット・データベースにデプロイする方法。

- データの比較: 2つのデータベース間の行データの相違のリスト。

データベースのバージョン9.x以上では、Cloud Controlを通じてデータベース・ターゲットにログインするユーザーは、データベースの取得または比較のためにSELECT ANY DICTIONARY権限およびSELECT_CATALOG_ROLEロールを保持している必要があります。スキーマの同期を実行するには、宛先データベースにログインしているユーザーにSYSDBA権限が必要です。変更計画の作成または削除を行うには、Cloud Controlユーザーは「変更計画の管理」リソース権限、EM_ALL_OPERATOR権限、ターゲットに対するVIEWおよびCONNECT権限、ジョブ・システムに対するリソースの作成権限および新規名前付き資格証明の作成リソース権限を保持している必要があります。ユーザーに、特定の変更計画に対する「表示」権限と「編集」権限を付与することもできます。

データ比較ジョブを発行する場合、参照データベースと候補データベースに対して指定されている資格証明のユーザーは、それぞれ参照オブジェクトと候補オブジェクトに対するSELECT権限を保持している必要があります。また、ユーザーには、SELECT ANY DICTIONARY、SELECT_CATALOG_ROLEおよびCREATE VIEWの各権限も必要です。LOB型の列が含まれるオブジェクトを比較する場合、実際の列値ではなく、列の暗号化ハッシュ値が比較されるため、ユーザーにSYS.DBMS_CRYPTOパッケージに対するEXECUTE権限が付与される必要があります。タイムスタンプまたはシステム変更番号(SCN)に基づいて比較を行うよう指定する場合、各データベース内の参照オブジェクトと候補オブジェクトに対するFLASHBACK権限もユーザーに直接付与されている必要があります。

また、参照データベース資格証明として指定されている資格証明のユーザーは、DBMS_COMPARISONプログラムに対するEXECUTE権限を持つDBAである必要があります。参照データベースと候補データベースが異なる場合、CREATE DATABASE LINK権限も必要です。

データベース・リンク、比較定義およびビューが、データ比較ジョブによって参照データベースに作成されることがあります。ビューが候補データベースに作成される場合があります。比較処理時に作成されるこれらのオブジェクトは、削除時に削除をスキップするオプションを指定しないかぎり、比較が削除されると削除されます。

SYSの資格証明はデータベース・リンク越しに使用できないため、リモート候補データベースにSYSとして接続してデータの比較を実行することはできません。

47.2 スキーマ・ベースラインの使用

スキーマ・ベースラインには、特定の時点で取得された一連のデータベース定義が含まれます。ベースラインは、Cloud ControlリポジトリにXMLドキュメントとして格納されます。

各ベースラインには、一意の名前を割り当てる必要があります。ベースラインは、そのベースラインで取得されるデータベース・オブジェクトの有効範囲と一致するように命名すると便利です(Financial 11.5.10、HR Benefits、PO Check Printなど)。1つのベースラインは、異なる時点で取得された一連のバージョンを保持できます。ベースラインの複数のバージョンを作成すると、一連のデータベース・オブジェクトの定義に対する変更を時間経過に合せて追跡できます。同じベースラインの2つのバージョンを比較することで、そのバージョン間で発生した変更を確認できます。

ベースラインの作成時、対応するベースラインの有効範囲指定も作成します。有効範囲指定には、データベース・オブジェクトの名前とタイプ、およびその取得元となるスキーマが示されます。ベースライン定義を作成したら、Cloud Controlジョブを発行してベースラインの最初のバージョンを取得できます。後で、あるいは定期的に同じベースラインの追加バージョンを取得できます。各ベースラインのバージョンには、バージョンの取得時に存在するメタデータ定義が記録されます。

変更管理スキーマ・ベースラインは、削除するまでシステムに保持されます。ベースラインを削除すると、システムから永久に削除されます。削除操作は元に戻すことができません。ただし、ベースラインが今後必要になる可能性がある場合、まずベースラインをダンプ・ファイル(リポジトリ・データベース・サーバー・ホストに作成)にエクスポートし、それからベースラインを削除します。ベースラインがその後必要になったら、ファイルからインポートして戻すことができます。

47.2.1 有効範囲指定の概要

有効範囲指定では、ベースラインに取得されるデータベース・オブジェクトが識別されます。(有効範囲指定では、スキーマの比較と同期化で処理されるオブジェクトも識別されます。)ベースラインの有効範囲を指定したら、有効範囲指定を変更できません。この制限によって、ベースラインのすべてのバージョンが同じルールのセットを使用して取得されることが保証されます。つまり、バージョン間の相違は、データベースに加えられた変更によるもので、有効範囲指定の変更によるものではないということです。異なる有効範囲指定を使用してスキーマ・オブジェクトを取得するには、ベースラインを新たに作成する必要があります。

ベースラインの有効範囲指定には、次の3つの形式があります。

- 取得するスキーマおよびオブジェクト・タイプを指定できます。たとえば、スキーマAPPL1およびAPPL2のすべての表、索引およびビューを取得できます。この形式の有効範囲指定は、アプリケーション・オブジェクトを含む適切に定義されたスキーマのセットが存在する場合に適切です。スキーマ・オブジェクトに加え、非スキーマ・オブジェクト(ユーザー、ロール、表領域など)や、ユーザーおよびロールに対する権限付与も取得できます。

- 除外するスキーマと、オブジェクト・タイプを指定できます。この形式の有効範囲指定では、指定したスキーマ以外のすべてのスキーマに含まれるオブジェクトが取得されます。たとえば、SYSTEMおよびSYS以外のスキーマのすべてのオブジェクト・タイプを取得できます。この形式の有効範囲指定は、Oracle付属のスキーマに含まれるオブジェクトを除き、すべてのデータベース・オブジェクトを取得する場合に適切です。有効範囲指定の最初の形式と同様に、非スキーマ・オブジェクトと権限付与も取得できます。

- 最後の形式として、個々のオブジェクトのタイプ、スキーマおよび名前を指定することで、それらのスキーマ・オブジェクトを個別に取得できます。この形式の有効範囲指定は、1つ以上のスキーマ内に含まれるすべてのオブジェクトではなく、一部の特定のオブジェクトを取得する場合に適切です。個々のスキーマ・オブジェクトを取得する一方で、非スキーマ・オブジェクトと権限付与も取得できます。

有効範囲指定にユーザーやロールなどの非スキーマ・オブジェクト・タイプを含めると、そのタイプのオブジェクトがすべて取得されます。個々の非スキーマ・オブジェクトを取得する方法はありません。図47-1に、有効範囲を指定する「スキーマ・ベースライン: オブジェクト」ページを示します。

図47-1 取得するスキーマおよびオブジェクト・タイプを選択する形式のベースラインの有効範囲指定

47.2.2 スキーマ・ベースライン・バージョンの取得について

ベースラインを定義する最後の手順として、ベースラインの最初のバージョンを取得する時期を指定します。最初のバージョンは、即座に取得するか、後で(たとえば、データベースがアクティブな開発作業に使用されていないときに)取得できます。また、追加の手動操作を行わずに一定の間隔で追加のベースライン・バージョンを取得するように指定することもできます。

ベースラインを選択して「すぐに再取得」を指定することで、任意の時点の新しいベースライン・バージョンを取得することも可能です。

最初のバージョンの後に処理されるベースラインは、通常、最初のバージョンよりもずっと高速に処理されます。変更のあったオブジェクトのみが新規バージョンに取得されます。つまり、変更されたオブジェクトが数パーセントであれば、追加のベースライン・バージョンに必要とされる記憶域は、最初のバージョンで使用された記憶域よりほんの少し多くなるだけです。図47-2に、スキーマ・ベースラインの最初のバージョンを示します。

図47-2 スキーマ・ベースライン

47.2.3 単一のスキーマ・ベースライン・バージョンの操作について

単一のスキーマ・ベースライン・バージョン内で、個々のオブジェクト属性の調査、個々のオブジェクトに対応するDDLの生成、およびベースライン・バージョンのすべてのオブジェクトに対応するDDLの生成を行うことができます。ベースライン・バージョンに取得されたオブジェクト定義は、特定の時点でのオブジェクトの状態を表すことを意図しているため、変更することはできません。

- ベースライン・オブジェクトを表示すると、オブジェクトの属性がグラフィカルに表示されます。

- ベースライン・オブジェクトを選択して「DDLの生成」を指定すると、オブジェクトの作成に使用されるDDLが表示されます。図47-3に、ベースライン・オブジェクトに対して生成されたDDLを示します。

図47-3 選択したベースライン・オブジェクトに対して生成されたDDL

- ベースライン・バージョンを選択して「DDLの生成」を指定すると、ベースライン・バージョンのすべてのオブジェクトに対応するDDLが生成されます。正しい順序でオブジェクトを作成する作業が行われますが(索引の前に表を作成するなど)、生成されたDDLをデータベースで実行しても、ベースライン・バージョンのオブジェクトを作成できるとはかぎりません。たとえば、スキーマAPPL1に含まれるすべてのスキーマ・オブジェクトを取得し、ユーザーAPPL1を含まないデータベースでベースライン・バージョンのDDLを実行しようとしても、生成されたDDLは実行に失敗します。

ベースライン・バージョンは、比較や同期化などの他のDatabase Lifecycle Management Packアプリケーションでも使用されます。ベースライン・バージョンは、データベース(または他のベースライン・バージョン)と比較できます。また、ベースライン・バージョンを同期化のオブジェクト定義のソースとして使用し、別のデータベースにその定義を再作成できます。

47.2.4 複数のスキーマ・ベースライン・バージョンの操作について

ベースラインに複数のバージョンが含まれる場合、バージョン間の相違を調査できます。

- あるバージョンとその先行バージョンの間における変更点を確認するには、バージョンを選択して「前のバージョン以降の変更を表示」を指定します。画面に、前のバージョン以降に変更されたオブジェクト(図47-4)、追加または削除されたオブジェクト、および変更されていないオブジェクトが表示されます。変更されたオブジェクトを選択すると、そのオブジェクトの2つのバージョン間の相違が表示されます。

図47-4 前のバージョン以降の変更の表示

- ベースラインのすべてのバージョンにわたり変更された個々のオブジェクトを確認するには、オブジェクトを選択して「バージョン履歴の表示」を指定します。画面に、オブジェクトが最初に取得、変更または削除されたときのバージョンが表示されます(図47-5を参照)。この表示で、任意の2つのベースライン・バージョンに含まれるオブジェクトの定義を比較できます。

図47-5 選択したベースライン・オブジェクトのバージョン履歴の表示

47.2.5 スキーマ・ベースラインのエクスポートおよびインポート

ベースラインのエクスポート/インポート機能を使用して次のことを行えます。

- 異なるリポジトリを持つ2つのCloud Controlサイト間でのベースラインの転送。

- オフラインでのベースラインの保管。ベースラインは、ファイルにエクスポートし、削除した後、ファイルからインポートして戻すことが可能です。

スキーマ・ベースラインまたはバージョンを選択して、ファイルにエクスポートできます。エクスポートおよびインポートにはデータ・ポンプが使用されます。ダンプ・ファイルおよびログ・ファイルは、Cloud Controlリポジトリ・データベース・サーバー・ホストに保管されます。また、OracleによってサポートされているNASデバイス上のファイル・システムなど、NFSファイル・システムに設定されているディレクトリに保管することも可能です。

47.2.5.1 エクスポートおよびインポートのためのディクショナリ・オブジェクトの作成

スキーマ・ベースライン・バージョンをリポジトリからエクスポート・ファイルにエクスポートする場合、またはスキーマ・ベースラインをリポジトリ・データベース・サーバー上のインポート・ファイルからインポートする場合、エクスポートまたはインポートするディレクトリ・オブジェクトをリポジトリ・データベースで選択し、エクスポートまたはインポート・ファイルの名前を指定します。

エクスポートまたはインポートする新しいディレクトリ・オブジェクトを作成するには、次のようにします。

1. CREATE ANY DIRECTORY権限またはDBAロールを持つユーザーとしてリポジトリ・データベースにログインします。

2. ベースラインのエクスポート先またはインポート・ダンプ・ファイルの格納場所であるリポジトリ・データベース・サーバーのファイル・システム上に、ディレクトリの別名としてディレクトリ・オブジェクトを作成します。

3. ディレクトリ・オブジェクトのREADおよびWRITE権限をSYSMANに付与します。

新たに作成されたディレクトリは、Cloud Controlの管理者がスキーマ・ベースラインのエクスポートおよびインポートを行う際に選択できるようになります。エクスポートおよびインポート操作で作成されるデータ・ポンプのログ・ファイルも、同じディレクトリに書き込まれます。

インポート中、名前、所有者およびソース・データベースに新しい値を設定できます。スーパー管理者は、インポート時に別の管理者を所有者として設定できます。

エクスポート操作では、ベースラインに関連付けられたジョブ情報はエクスポートされません。したがって、インポート時、ジョブ・ステータスは不明となります。

非スーパー管理者には、次が適用されます。

- 非スーパー管理者は、自分自身のベースラインをエクスポートできます。また、非スーパー管理者は、別の管理者が所有しているベースラインのバージョンを表示しバージョン内のスキーマ・オブジェクト・リストを確認できる権限を持っている場合、そのバージョンをエクスポートできます。

- インポート時、非スーパー管理者は、インポートされているベースラインの所有者となる必要があります。非スーパー管理者は、別の管理者を所有者として設定できません。インポート・ダンプ・ファイル内のベースラインが別の管理者によって所有されている場合、ログインしている非スーパー管理者が新規所有者としてインポート時に設定されます。

- 非スーパー管理者に付与されているベースラインの表示権限はインポート時に失われ、インポート後は、関連付けられたジョブ情報がないため再付与できません。

47.3 スキーマの比較の使用

スキーマの比較により、ベースライン(またはデータベース)とベースライン(またはデータベース)間、あるいは単一のデータベースまたはベースライン内の2つのスキーマ間で、データベース・オブジェクト定義の相違が識別されます。

比較の指定は、左側と右側のソース、有効範囲および所有者により定義されます。有効範囲指定では、比較に含めるデータベース・オブジェクト定義の名前とタイプ、およびそれらのオブジェクト定義を含むスキーマを記述します。

比較により、任意のタイプのオブジェクト間で属性値の相違が識別されます。比較を使用して、複数の比較バージョンを作成できます。各バージョンには、一意のバージョン番号と比較日が割り当てられます。これらのバージョンを使用して、現在までに作成されたデータベース(スキーマ)の比較を関連付けます。

比較により、アプリケーションの元のベースラインと現在のデータベースの定義間の相違を表示できます。新しい比較バージョンを作成すると、開発サイクルの開始時における元の定義と、現時点における同じ定義との間の相違を識別できます。

他の比較指定を使用して、最新のベースラインの定義と以前のベースラインの定義を比較することもできます。比較指定を使用して比較の新規バージョンを作成するたびに、その比較バージョンにより前のベースライン以降の定義の相違を識別できます。

47.3.1 スキーマの比較の定義

スキーマの比較の定義は、左側と右側のメタデータ定義のソース、有効範囲指定、オプションのスキーマ・マップおよび比較オプションで構成されます。一度作成したら、スキーマの比較の定義を変更することはできません。これにより、スキーマの比較の各バージョンが、比較の定義の変更ではなく、比較対象のデータベースの変更を反映していることが保証されます。

スキーマの比較のソース

各比較には、左側のソースと右側のソースがあります。比較では、左側のソースと右側のソースのオブジェクト定義が照合されます。ソースには、データベースまたはベースライン・バージョンを指定できます。

- ソースがデータベースの場合、オブジェクト定義は比較バージョンの作成時点のデータベースから直接取得されます。

- ソースがベースラインの場合、オブジェクト定義は指定したベースライン・バージョンから取得されます。ベースライン・バージョンを使用すると、データベース(または別のベースライン・バージョン)を、過去のある時点で存在していたデータベースと比較できます。たとえば、ベースライン・バージョンは、アプリケーション開発サイクルの基礎となる時点や、アプリケーションの以前のリリースを表すことがあります。

ベースライン・ソースの場合、使用するバージョンを指定するための様々な方法があります。

- 特定のベースライン・バージョンを比較のすべてのバージョンで使用する場合、ベースライン・バージョン番号を指定します。この方法は、適切に定義されたデータベースの以前の状態(任意のリリースなど)と、その現在の状態を比較する場合に適しています。

- 最新のバージョンまたはその1つ前のバージョンを比較で使用することもできます。「最新」を選択すると、比較を実行する前にベースライン・バージョンを取得するよう指定できます。このオプションにより、単一の操作でベースラインを取得してそれを他のソースと比較できます。たとえば、毎晩開発データベースの現在の状態を表すベースライン・バージョンを取得し、それを前日の夜のベースラインや、開発の基礎となる時点を表す固定ベースラインと比較できます。

有効範囲指定

スキーマの比較の有効範囲指定では、左側と右側のソースで比較するオブジェクトを識別します。比較の有効範囲指定の作成方法は、「スキーマ・ベースライン」に記載されているベースラインの有効範囲指定の作成方法と同じです。ベースラインと同様に、比較するオブジェクト・タイプとスキーマを指定するか、比較する個々のオブジェクトを指定します。

スキーマ・マップ

通常、一方のソースのスキーマ・オブジェクトは、他方のソースの同じスキーマに含まれるオブジェクトと比較されます。たとえば、左側のソースのAPPL1.T1表は、右側のソースのAPPL1.T1と比較されます。

しかし、あるスキーマのオブジェクトを、別のスキーマの対応するオブジェクトと比較したいこともあります。たとえば、DEV1とDEV2という2つのスキーマがあり、それぞれ同じオブジェクト・セットを含んでいるとします。異なるアプリケーション開発者が、DEV1とDEV2で作業しています。オプションのスキーマ・マップ機能を使用すると、DEV1のオブジェクトを、同じタイプおよび名前を持つDEV2のオブジェクトと比較できます。

スキーマ・マップにエントリを追加するには、比較の「オブジェクト」ページのマップされたオブジェクト・セクションを開きます。マップされたスキーマの1つ以上のペアを作成できます。各ペアでは、左側のスキーマと対応する右側のスキーマを指定します。

スキーマ・マップを使用すると、単一のデータベースまたはベースライン・バージョン内のオブジェクトを比較できます。前述の例では、同じデータベース内にDEV1とDEV2が存在します。左側と右側の両方のソースとしてそのデータベースを指定し、スキーマ・マップを入力してDEV1のオブジェクトとDEV2のオブジェクトを比較します。

比較オプション

オブジェクトの比較方法を指定する複数のオプションを選択できます。これらのオプションにより、重要ではない相違を無視できます。オプションには次のものがあります。

- 「表領域を無視」および「物理属性を無視」 - これら2つのオプションでは、格納されているオブジェクトを比較する際に、それらの格納されている表領域や、記憶域関連の属性の設定を無視できます。このオプションは、異なるサイズ構成および記憶域構成を持つデータベース内のオブジェクトを比較する場合や、オブジェクトの記憶域に関連する相違を考慮しない場合に便利です。

- 「一致制約」の「定義別」または「名前別」 - 表制約の定義をより重視する場合(主キー制約または一意制約に関連する列など)、「一致制約」の「定義別」を選択します。これにより、同じ定義を持つ制約が照合され、その名前が相違として示されます(「名前の違いを無視」を選択していない場合)。制約の名前に意味がある場合、「一致制約」の「名前別」を選択します。この選択では、同じ名前を持つ制約が照合され、その定義が相違として示されます。

- 「パーティション化されたオブジェクト: パーティション化を無視」 - このオプションを選択すると、表および索引のパーティション化を無視します。

- 「パーティション化されたオブジェクト: 上限を無視」 - 異なる環境では、同じ表が異なるパーティション上限値を持つ可能性があります。このオプションを選択すると、上限値の相違を無視できます。

- 「論理SQL比較」 - このオプションを選択すると、ソース・オブジェクト(パッケージ、パッケージ本体、プロシージャ、ファンクションなど)の意味のない書式の相違やコメント内の空白の相違を無視できます。

- 「統計の比較」 - このオプションを選択すると、表および索引のオプティマイザ統計を比較できます。

- 「表の列位置を無視」 - 列の位置のみが異なる表を同じであるとみなす場合、このオプションを選択します。

比較バージョンの作成

比較の定義が終了したら、最初の比較バージョンを作成する時期を指定します。最初のバージョンは、即座に作成するか、後で作成できます。一定の間隔で新しい比較バージョンをスケジュールすることもできます。

比較バージョンをスケジュールする以外に、比較を選択して「すぐに繰返す」を指定することで、いつでも新しい比較バージョンを作成できます。

最初のバージョンの後に処理される比較は、通常、最初の比較よりもずっと高速に処理されます。左側または右側で変更のあったオブジェクトのみが、新規バージョンで比較されます。つまり、変更されたオブジェクトが数パーセントであれば、追加の比較バージョンに必要とされる記憶域は、最初のバージョンで使用された記憶域よりほんの少し多くなるだけです。

47.3.2 スキーマの比較バージョンの操作について

スキーマの比較バージョンには、有効範囲指定に応じて左側と右側のソースを比較した結果が記録されます。比較バージョンのオブジェクトの状態は、次の4つのうちのいずれかです。

- 左のみ - オブジェクトは左側のソースにのみ存在します。

- 右のみ - オブジェクトは右側のソースにのみ存在します。

- 同一 - オブジェクトは左側と右側のソースに存在し、同一です。

- 差分あり - オブジェクトは左側と右側のソースに存在し、異なります。

図47-6 同一ではないオブジェクトのリストが表示された比較バージョンのページ

ページには比較のすべてのバージョンがリストされ、バージョンごとに各状態のオブジェクトの数が表示されます。図47-6の比較バージョンのページには、各状態のオブジェクトが個別に表示されています。図47-7のように、同一ではないオブジェクトを選択して相違を表示し、左側と右側の定義のDDLを生成できます。

図47-7 選択した同一ではないオブジェクトの属性の相違の表示

比較バージョンにオブジェクトの情報を記録する場合、さらに次の2つの操作を実行できます。

- オブジェクトにコメントを追加できます。たとえば、コメントで2つのオブジェクトが異なる理由を記述します。

- オブジェクトを無視できます。オブジェクトを無視すると、比較バージョンのオブジェクトのリストからそのオブジェクトが削除されます。相違が重要ではないと判断した場合、異なるオブジェクトを無視できます。

47.4 スキーマの同期化の使用

スキーマの同期化では、2つのデータベース間またはベースラインとデータベース間のデータベース・オブジェクト定義の相違が同期化されます。データベースの同期化の基本アクションは、選択されたオブジェクト定義をデータベースで作成または変更し、別のデータベースまたはベースラインのオブジェクト定義と一致させることです。

同期化は、同期化指定を使用して生成されます。同期化の場合、有効範囲の指定に個々のオブジェクトの名前は含まれていません。有効範囲にはタイプ、追加または除外するスキーマのみを指定できます。また、接頭辞を追加して、その接頭辞で始まる名前のオブジェクトのみを選択できます。

スキーマの同期化では、サポートされる任意のタイプのオブジェクト間で属性値の相違が同期化されます。同期化指定を使用して、複数の同期化バージョンを作成できます。各バージョンには、一意のバージョン番号と同期化日が割り当てられます。これらのバージョンを使用して、現在までに作成されたデータベース(スキーマ)の同期化を関連付けます。

47.4.1 スキーマの同期化の定義について

ソースと宛先

同期化のソースにより、宛先データベースの同期元となるオブジェクト定義(およびオプションでデータ)が提供されます。同期化のソースには、データベースまたはベースライン・バージョンを指定できます。ソースがベースライン・バージョンの場合、ベースラインではデータが取得されないため、宛先にデータを伝播することはできません。

同期化の宛先には、常にデータベースを指定する必要があります。同期化の目的は、ソースのオブジェクト定義と一致するように宛先のオブジェクト定義を作成または変更することです。

使用するソース・ベースラインのバージョンの指定オプションは、スキーマの比較で使用されるオプションとほぼ同じです。固定ベースライン・バージョンを指定するか、「最新」または「最新 - 1」を指定できます。「最新」を選択すると、宛先を同期化する前にベースライン・バージョンを取得するよう指定できます。

同期化のソースとして使用するベースラインを定義する場合、同期化するすべてのオブジェクトがそのベースラインに含まれていることが重要です。このため、ベースラインの有効範囲指定には、最低でも同期化するすべてのスキーマとオブジェクト・タイプが含まれている必要があります。また、ベースラインには、ユーザーおよびロール・オブジェクトと、権限付与も含まれている必要があります。変更が頻繁にソース・データベースに適用されることが予測され、データベースのポイント・イン・タイム・スナップショット(つまり、同期化のソースとなるベースライン)が必要とされる環境では、データベースの同期化にベースラインを使用することをお薦めします。

有効範囲指定

スキーマの同期化の有効範囲指定の定義方法は、スキーマのベースラインまたは比較の有効範囲指定の定義方法とほぼ同じです。ただし、有効範囲指定に含めることができる項目については、次の制限があります。

- 同期化に個々のオブジェクトを指定することはできません。オブジェクト・タイプと、含めるスキーマまたは除外するスキーマを指定する必要があります。

- SYSやSYSTEMなどの特定のスキーマは、同期化できません。

- 同期化にユーザーおよびロール・オブジェクトを直接含めることはできません。(ただし、ユーザーとロールは、同期化プロセス中に必要に応じて自動的に含められます。)

- 表、索引、クラスタ、マテリアライズド・ビューおよびマテリアライズド・ビュー・ログの各オブジェクト・タイプは、グループとして選択することをお薦めします。

同期化の有効範囲指定は、アプリケーションに合せて慎重に調整する必要があります。不要なスキーマを含めないでください。たとえば、大規模なアプリケーションのモジュールを同期化する場合、そのモジュールを構成するスキーマのみを含めます。大規模なアプリケーション(またはデータベース全体)を一度に同期化することは避けてください。

スキーマ・マップ

スキーマの同期化におけるスキーマ・マップの定義および使用方法は、スキーマの比較の場合と同じです。スキーマ・マップを使用すると、各スキーマ・マップのオブジェクト定義は、同じ名前のスキーマではなく、宛先のマップされたスキーマに同期化されます。また、スキーマ修飾参照(PL/SQLブロックおよびビュー問合せに含まれるもの以外)は、スキーマ・マップに応じて変更されます。

たとえば、スキーマ・マップに次の2つのエントリが含まれるとします。

- DEV1A -> DEV2A

- DEV1B -> DEV2B

表DEV1A.T1には索引DEV1A.T1_IDXがあります。DEV1B.T2を参照する外部キー制約もあります。同期化で、次のようなオブジェクトが作成されます。

- 表DEV2B.T2

- 表DEV2A.T1(表DEV2B.T2に対する外部キー参照付き)

- 索引DEV2A.T1_IDX(表DEV2A.T1内)

同期化オプション

スキーマの同期化オプションは、スキーマの比較で指定できるオプションとほぼ同じです。同期化では、オプションで次の2つの機能を実行します。

- ソース・オブジェクトと宛先オブジェクトの最初の比較中に、オプションにより相違を重要視するかどうかを決定します。たとえば、「表領域を無視」オプションを選択すると、表領域の相違は無視されます。2つの表が表領域以外は同一の場合、宛先表に対する変更操作は行われません。

- 宛先にオブジェクトを作成するスクリプトを生成する場合、一部のオプションでスクリプトの内容を制御します。たとえば、「表領域を無視」を選択すると、TABLESPACE句は生成されません。

スキーマの比較で提供されるオプション以外に、同期化に固有の次のオプションがあります。

- 「宛先のデータを保持」および「ソースからデータをコピー」: これらの2つのオプションでは、ソース・データベースから宛先データベースに表データをコピーするかどうかを制御します。(ソースがベースラインの場合、このオプションは使用できません。)デフォルトでは、同期化により宛先表のデータは保持されます。「ソースからデータをコピー」を選択すると、同期化により、宛先のデータがソース表のデータで置き換えられます。

- 「宛先のみのスキーマ・オブジェクトを削除」: このオプションを選択すると、宛先に存在してソースに存在しないスキーマ・オブジェクトを削除するよう同期化に指示されます。たとえば、ソースに表DEV1.T1が含まれ、宛先にDEV1.T1およびDEV1.T2が含まれる場合にこのオプションを選択すると、同期化によりDEV1.T2は削除されます。この処理は、有効範囲指定内のスキーマ・オブジェクトにのみ適用されます。デフォルトでは、同期化により宛先のみに存在するオブジェクトは削除されません。非スキーマ・オブジェクトは、同期化で削除されることはありません。

同期化モード

同期化を定義する次の手順は、同期化モードの選択です。次の2つのオプションがあります。

- 自動同期化モードでは、同期化プロセス全体が1ステップで実行され、最後に同期化スクリプトが実行されます。ただし、適切なスクリプトの生成を妨げるエラーが検出された場合、プロセスはスクリプトを実行せずに終了します。

- インタラクティブ同期化モードでは、ソース・オブジェクトと宛先オブジェクトの最初の比較後に処理が一時停止し、同期化スクリプトの生成後に再開します。インタラクティブ・モードでは、比較とスクリプト生成の結果を検討し、次のステップに進む前に適切な操作を実行できます。

同期化バージョンの作成

同期化の定義が終了したら、最初の同期化バージョンを作成する時期を指定します。最初のバージョンは、即座に作成するか、後で作成できます。一定の間隔で新しい同期化バージョンをスケジュールすることもできます。

選択した同期化モードに応じて、同期化は最後まで実行されるか(自動モード)、最初のオブジェクト比較の後に一時停止します(インタラクティブ・モード)。インタラクティブ・モードの場合、同期化の各後続フェーズは新規ジョブとして実行します。

インタラクティブ・モードを使用する場合、宛先データベースは、オブジェクトの最初の比較時から同期化スクリプトを実行するまで変更できません。変更すると、スクリプトに問題が発生します。たとえば、宛先に存在しない表がソースに含まれているとします。オブジェクトの比較で、ソースのみに存在する表が認識され、生成されるスクリプトにはその表を作成する文が組み込まれます。このとき、オブジェクトの比較後で、スクリプトの実行前に宛先データベースに手動でその表を作成します。表はすでに存在するため、表を作成しようとするとスクリプトは失敗します。

図47-8に、同期化のリストを示します。

図47-8 同期化のリスト

同期化プロセスの詳細は、「スキーマの比較バージョンの操作について」を参照してください。

47.4.2 比較からの同期化定義の作成

スキーマの比較を同期化の開始点として使用できます。比較を選択して、「同期化」を選択します。これにより、比較に基づく次の初期情報を含んだ新しい同期化が作成されます。

- ソースと宛先(比較の左側のソースと右側のソースにそれぞれ対応)。この場合、右側のソースがベースラインである比較からは、同期化を作成できません。

- 有効範囲指定。比較の有効範囲指定オプションの一部は、同期化で使用できません。たとえば、ユーザー・オブジェクトやロール・オブジェクトなどの個々のスキーマ・オブジェクトは同期化できません。

- 比較オプション。

47.4.3 スキーマの同期化バージョンの操作

各同期化バージョンは、対応するソース・オブジェクトに一致するように、有効範囲指定で選択された宛先オブジェクトを変更しようとする試行のことです。(「試行」であるのは、様々な理由からプロセスが完了しない場合があるためです。)この項では、スキーマの同期化バージョンの処理のされ方、およびプロセスの監視と制御の方法について説明します。

47.4.3.1 スキーマの同期化サイクルについて

同期化バージョンの処理には、3つのステップが関連します。前述したとおり、(自動モードを選択して)3つのステップを1つに結合するか、(インタラクティブ・モードを選択して)各ステップを個別に実行します。どちらの場合でも、同期化バージョンを正常に処理するには、3つのステップをすべて実行する必要があります。

次の項では、3つの各ステップについて詳しく説明します。また、インタラクティブ・モードでの操作時に各ステップの後に実行できる処理について説明します。

オブジェクト比較ステップ

最初のステップでは、ソースのオブジェクトを宛先の対応するオブジェクトと比較します。有効範囲指定により選択されたオブジェクトのみが比較されます。このステップの最後の時点で、同期化バージョンにはすべてのオブジェクトが記録されています。各オブジェクトの状態は、次のいずれかです。

- ソースのみ

- 宛先のみ

- 同一

- 差分あり

インタラクティブ・モードでは、各状態のオブジェクトを表示するか、すべてのオブジェクトを同時に表示できます。同一ではないオブジェクトの場合、オブジェクト間の相違を表示できます。この段階で、次のように各宛先オブジェクトに対する処理を予想できます。

- ソースのみに存在するオブジェクトは、宛先に作成されます。

- 宛先のみに存在するオブジェクトは、影響を受けません。ただし、「宛先のみのスキーマ・オブジェクトを削除」オプションを選択した場合、宛先のオブジェクトは削除されます。

- 同一のオブジェクトは、影響を受けません。ただし、「ソースからデータをコピー」オプションを選択した場合、同一の表のデータはソースのデータで置き換えられます。

- 同一ではないオブジェクトは、ソース・オブジェクトと一致するように変更されます。変更は、相違に応じて、ALTER文の使用を通じて、またはオブジェクトの削除と再作成を通じて行われます。

スクリプト生成に進む前に(図47-9)、同期化からオブジェクトを除外できます。たとえば、宛先には作成しないソース専用のビューが存在する場合、ここで除外できます。

図47-9 インタラクティブ・モードの「スクリプト生成を続行」ステップ

スクリプト生成ステップ

スクリプトの生成時に、同期化では、比較ステップの結果を使用して、ソースと一致するように宛先でオブジェクトを作成および変更するPL/SQLスクリプトを作成します。スクリプト生成の一環として、次のいくつかのアクティビティが実行されます。

- 依存性分析により、宛先データベースが各オブジェクトに適切な環境を提供していることと、オブジェクトが正しい順序で作成および変更されることが保証されます。

- 変更分析により、ALTER文を使用してオブジェクトを変更できるかどうか、またはオブジェクトを削除して再作成する必要があるかどうかが決定されます。

- 同期化バージョンの影響レポートにメッセージが配置されます。これらのメッセージには、同期化プロセスに関する情報が含まれており、状況によっては、使用可能なスクリプトを生成できない1つ以上のエラー状態がレポートされます。

- 同期化を実行するのに必要なDDL文が生成され、同期化バージョンに記録されます。

依存性分析では、各オブジェクトを調べ、他のオブジェクトとの関係を明らかにします。これらの他のオブジェクトが宛先に存在する(または作成される)ことを確認します。これらの関係の例として、次のようなものがあります。

- スキーマ・オブジェクトは、それを所有するユーザー・オブジェクトに依存します。たとえば、表DEV1.T1はユーザーDEV1に依存します。

- 索引は、それが存在する表に依存します。たとえば、索引DEV1.T1_IDXは表DEV1.T1に依存します。

- 外部キー制約が存在する表は、制約の参照先の表に依存します。

- パッケージ本体などのソース・オブジェクトは、他のソース・オブジェクト、表、ビューなどに依存します。

- ストアド・オブジェクトは、それが格納されている表領域に依存します(「表領域を無視」が選択されていない場合)。

依存性分析の際に確認された関係は、スクリプトの文を正しい順序で処理するために後でスクリプト生成プロセスで使用されます。

依存性分析により、宛先データベースに必須オブジェクトが存在しないことが判明する場合があります。たとえば、スキーマ・オブジェクトの所有者が、宛先データベースに存在しないことがあります。または、異なるスキーマに存在する別の表に対する外部キー制約が表に含まれることがあります。処理結果は次のようになります。

- 必須オブジェクトがソースに存在し、有効範囲指定で選択されている場合、同期化でそのオブジェクトが作成されます。たとえば、DEV1.T1にDEV2.T2を参照する外部キー制約があり、DEV1とDEV2の両方とも有効範囲指定に含まれる場合、同期化でDEV2.T2が作成されます。

- 必須オブジェクトがユーザーまたはロールで、そのオブジェクトがソースに存在する場合、自動的に同期化にそのユーザーまたはロールが追加され、宛先に作成されます。この処理は、ユーザー・オブジェクトとロール・オブジェクトが同期化の有効範囲指定に含まれていない場合でも発生します。

- 必要なスキーマ・オブジェクトがソースにあって、有効範囲指定で選択されていない場合、オブジェクトは自動的に含められません。かわりに、エラーレベルのメッセージが影響レポートに出力されます。この制限によって、有効範囲の指定外のオブジェクトが無制御に同期化されることがなくなります。有効範囲指定に、アプリケーション・モジュールを構成するすべてのスキーマを含める必要があるのは、このためです。

- ソースがベースライン・バージョンの場合、必須オブジェクトは含まれない可能性があります。たとえば、ベースラインでは、ユーザーとロールが取得されないことがあります。同期化では、ベースライン・バージョンの外部のオブジェクトは検索できないため、図47-10のように影響レポートにエラー・レベルのメッセージが配置されます。このため、同期化に使用するベースラインにユーザー、ロールおよび権限付与を含めることが重要です。

図47-10 必須スキーマ・オブジェクトが有効範囲指定で選択されていないために表示されたエラー・レベルの影響レポート・メッセージ

スクリプト生成ステップの最後に、同期化により影響レポートとスクリプトが同期化バージョンに追加されます。インタラクティブ・モードでは、スクリプトを実行する前にスクリプトと影響レポートを検討できます。

影響レポートには、スクリプトの生成中に発生した状態に関するメッセージが含まれます。メッセージには次の3つのタイプがあります。

- 情報メッセージでは、ユーザー側の処置は必要ありません。このメッセージは、単なる留意事項をレポートします。たとえば、スクリプト生成にユーザー・オブジェクトが自動的に含まれる場合、影響レポートに情報メッセージが追加されます。

- 警告メッセージは、注意が必要だが、通常は処置の必要がない状態をレポートします。たとえば、ソース・オブジェクト内の参照を解決できるかどうか同期化で判断できない場合、影響レポートに警告メッセージが追加されます。警告メッセージにレポートされた状態によりスクリプトの実行が妨げられないかどうかを検証する必要があります。

- エラー・メッセージは、修正しないとスクリプトを実行できない状態を示します。たとえば、同期化で必須依存オブジェクトの場所を特定できない場合、影響レポートにエラー・メッセージが追加されます。メッセージによっては、新しい同期化を作成する必要があります。たとえば、依存オブジェクトが同期化の有効範囲に存在しない場合や、ソースが依存オブジェクトを含まないベースラインである場合、有効範囲を拡張するか異なるソース・ベースラインを使用して新しい同期化を作成する必要があります。その他の場合は、同期化から1つ以上のオブジェクトを除外してスクリプトを再生成することで、エラー状態を解決できます。

スクリプト表示には、生成されたスクリプトの文が実行される順序どおりに含まれます。正確さに懸念がある場合は、スクリプトを調査できます。この表示により、特定のオブジェクトまたはオブジェクト・タイプに関連する文を特定できます。

図47-11 インタラクティブ・モードでの「スクリプト実行を続行」ステップ(「影響レポート」タブ)

スクリプトの生成後、スクリプト生成ステップでエラーが発生していなければ、スクリプト実行に進むことができます(図47-11および図47-12)。エラーが発生した場合、影響レポートに、問題と解決策について詳しく説明した1つ以上のエラー・レベルのメッセージが含まれます。「スクリプトの再生成」を選択し、同期化からオブジェクトを除外してスクリプトを再生成することで、問題を解決できることもあります。

図47-12 インタラクティブ・モードでの「スクリプト実行を続行」ステップ(「スクリプト」タブ)

状況によっては、問題を修正するために同期化の新規バージョンを作成する必要があります。たとえば、ソースまたは宛先のオブジェクトの定義を変更する場合や、宛先にオブジェクトを追加する場合、新規バージョンを作成する必要があります。これにより、比較ステップで新規オブジェクトまたは変更されたオブジェクトが検出されます。この場合、古いバージョンは、スクリプト生成を続行できないため破棄されます。

スクリプト実行ステップ

スクリプトの生成に成功したら、スクリプトをいつでも実行できます。自動モードでは、スクリプトは生成が完了すると同時に実行されます。インタラクティブ・モードでは、影響レポートとスクリプトの確認後、ただちにスクリプトの実行に進みます。

スクリプトは、Cloud Controlのジョブ・システムで実行されます。図47-13に、同期化ジョブの出力を示します。スクリプトの実行が完了したら、実行ログを表示できます。スクリプトの実行に失敗した場合、状況に応じて問題を修正し、障害が発生した時点からスクリプトの実行を再開できます。たとえば、表領域の領域不足によりスクリプトが失敗した場合、表領域のサイズを増やしてからスクリプトを再実行できます。

図47-13 Cloud Controlジョブの「同期スクリプト実行」ステップの出力

47.4.4 追加の同期化バージョンの作成

最初の初期化バージョンの処理後に、同期化の追加バージョンを作成できます。同期化を選択し、「再同期化」を選択します。新しい同期化バージョンを作成する場合、異なるソースまたは宛先を選択することや、有効範囲指定または同期化オプションを変更することはできません。ただし、新しい同期化バージョンの開始時に、異なるモード(自動またはインタラクティブ)を選択できます。

追加の同期化バージョンを作成すると、ソースの増分変更を宛先に伝播できます。たとえば、開発システムに加えられた最新の変更でテスト・データベースをリフレッシュできます。

最初のバージョンの後に処理される同期化は、通常、最初の同期化よりもずっと高速に処理されます。

47.5 変更計画の使用

変更計画は、Cloud Control Database Lifecycle Management Packの新しい機能です。変更計画は、ユーザーがメタデータ変更を選択およびパッケージングして複数のデータベースにデプロイできるようにすることで、既存の変更管理コンポーネントの機能を補完し、拡張します。変更計画では、スキーマの同期化など、既存のDatabase Lifecycle Management Packツールでは十分にサポートされていないデータベース・アプリケーション開発方法がサポートされます。

変更計画は、多様な開発方法をサポートできる柔軟性を備えているだけでなく、以前はカスタム・スクリプトを使用して実行していた多数のデータベース管理タスクを自動化できる強力さも備えています。次のようなタスクがあります。

- プロジェクト固有の開発の変更を、共有開発データベースから統合、テスト、本番のステージングなどの1つ以上の宛先データベースにデプロイします。

- スタンドアロンのプロジェクト開発データベースからの開発の変更を、複数の開発データベースから変更を収集する1つの統合データベースにデプロイします。

- 複数の開発データベースにある共通モジュールを中央の統合データベースからアップグレードします。

変更計画は、Database Lifecycle Management Packの他のツールと緊密に統合されています。具体的には次のとおりです。

- オブジェクトを作成する変更計画の変更リクエストは、変更管理スキーマ・ベースラインからオブジェクト定義を取得できます。

- オブジェクトを変更する変更リクエストは、変更管理のスキーマの比較でオブジェクトの内容を使用して、変更を指定できます。

- 変更計画は、より細やかな変更の制御と変更専用の変更リクエストを可能にし、変更管理のスキーマの同期を補完します。

47.5.1 変更計画の使用について

変更計画を使用してオブジェクト定義を作成または変更する最初のフェーズは、変更内容を計画し、定義することです。たとえば、1つ以上のデータベース内の既存のオブジェクト定義を1つ以上変更します。あるいは、あるスキーマまたはデータベースで、別のスキーマまたはデータベースから1つ以上のオブジェクト定義を再生成します。

図47-14 変更計画のステップ

図47-14に、変更計画の各ステップを示します。変更計画は、変更リクエストの名前付きコンテナです。宛先データベースのオブジェクト定義を再生成または変更する変更リクエストを定義できます。宛先データベースは、変更計画の変更リクエストの適用先のデータベースです。変更の計画および定義ができたら、変更の影響を評価します。

特定のデータベースでの変更リクエストの影響を評価するには、変更計画とその宛先データベースに対するスクリプトと影響レポートを生成します。影響レポートには、スクリプトが宛先データベースで実行された場合に行われる変更が示されます。宛先データベースで適用できない変更リクエストも示されます。

宛先データベースで変更計画の変更リクエストを実装するには、宛先データベースでスクリプトを実行します。

47.5.2 変更計画の作成

この項では、変更計画を作成する別の方法について説明します。

次の方法で変更計画を作成できます。

- スキーマ比較からの変更計画の作成および適用

- 外部クライアントを使用したCloud Controlでの変更計画の作成およびアクセス

47.5.2.1 スキーマ比較からの変更計画の作成および適用

この項では、スキーマの比較から変更計画を作成する方法について説明します。

変更計画の作成の前提条件

前提条件は次のとおりです。

- アプリケーション開発者(AD)が次の権限を持つCloud Controlユーザーであることを確認します。

- 開発データベースおよび本番のステージング・データベース・ターゲットに対する「ターゲットの接続」権限または「任意のターゲットの接続」権限

- 開発データベースのDBA権限

- ジョブ・システムの作成権限(リソース権限)

- 新しい名前付き資格証明の作成(リソース権限)

- 変更計画に対する「リソースの編集」権限

- 任意の場所でのコマンドの実行(ターゲット権限)

- EM_ALL_OPERATOR権限

- データベース管理者(DBA)が次の権限を持つCloud Controlユーザーであることを確認します。

- 開発データベースおよび本番のステージング・データベース・ターゲットに対する「ターゲットの接続」権限または「任意のターゲットの接続」権限

- 開発データベースのDBA権限

- ジョブ・システムの作成権限(リソース権限)

- 新しい名前付き資格証明の作成(リソース権限)

- 変更計画の管理(リソース権限)

- 任意の場所でのコマンドの実行(ターゲット権限)

- EM_ALL_OPERATOR権限

- 開発作業の開始時点では、開発データベースと宛先データベースが同一であることをお薦めします。たとえば、両方のデータベースを現在の製品バージョンにするか、両方のデータベースを共通の仮開発バージョンに更新します。

- アプリケーション開発者が開発データベースに変更を加えている場合があります。変更計画の作成後、アプリケーション開発者はSQL Developerなどの外部クライアントを使用して、変更計画内の変更アイテムを作成および更新できます。詳細は、「外部クライアントを使用したCloud Controlでの変更計画の作成およびアクセス」を参照してください。

変更計画の作成

変更計画を作成するには、次の手順を実行します。

1. データベース管理者(DBA)としてCloud Controlにログインします。

2. アプリケーション・オブジェクトを含むスキーマを識別します。

3. メタデータ・ベースライン・ウィザードを使用して、該当するスキーマを含むベースラインを定義します。最初のバージョンのベースラインを取得するジョブをスケジュールします。

4. ベースラインを保存します。

5. スキーマの比較ウィザードを使用して、ベースライン・バージョンと開発データベース間の比較を定義します。

6. 最初のバージョンの比較を作成するジョブをスケジュールし、比較を保存します。

7. スキーマ変更計画ページで、「作成」をクリックします。

8. 変更計画の名前および説明を指定し、「OK」をクリックして変更計画を保存します。

9. 変更アイテム・ページで、比較から作成をクリックします。

10. 「スキーマ比較からの変更項目の作成」ページで、以前に作成した比較バージョンを選択し、「比較の割当て」で開発データベースを「変更後」側に、本番のステージング・データベースを「変更前」側に指定して、「OK」をクリックします。

11. スキーマ比較からの変更アイテムの作成: 差分の選択ページで、次を選択します。

- スキーマ比較のすべての差分: 比較のすべての差分を変更計画に追加する場合に選択します。

- スキーマ比較の特定の差分: 変更計画に追加する比較の差分を選択する場合に選択します。差分を選択します。

「終了」をクリックします。

12. 宛先データベースに変更計画を適用するリクエストを発行します。

変更計画の適用

変更計画を適用するには、次の手順を実行します。

1. データベース管理者(DBA)としてCloud Controlにログインします。

2. DBAロールで、変更計画を検証して、指定されたデータベースへの適用に適しているかどうかを評価します。必要に応じて、個々の変更リクエストを削除します。

3. スキーマ変更計画ページで、変更計画から同期を作成をクリックします。

4. スキーマの同期ウィザードで、以前に作成した変更計画インスタンスを参照して詳細を指定します。スキーマの同期ウィザードの使用方法の詳細は、本番のステージングとの同期化を参照してください。デフォルトでは、変更から作成された同期はインタラクティブ・モードで機能します。

5. スクリプト生成をスケジュールします。

6. 影響レポートをチェックして、スクリプト実行をスケジュールします。

7. 完了したスクリプト実行ジョブにエラーがないかどうかをチェックします。変更計画ジョブが失敗した場合は、次の手順を実行します。

- 影響レポートで警告されたエラーが失敗の原因である場合、推奨されたユーザー処理を実行します。

- 失敗の原因がソースまたは宛先データベースの状態にあり、それが手動で修正可能な場合は、問題を修正してから再び操作を実行します。

- スクリプトの実行フェーズで失敗した場合、ジョブ詳細でスクリプトの出力を確認します。不足している権限の付与などの処理によって問題を解決できる場合は、問題をデータベースで手動で修正し、「スクリプト実行の再試行」をクリックします。

8. エラーを修正して、変更計画作成ジョブを再び発行します。

47.5.2.2 外部クライアントを使用したCloud Controlでの変更計画の作成およびアクセス

Cloud Controlでは、SQL Developerなどの外部クライアントを使用した変更計画の作成およびアクセスがサポートされています。これらのアプリケーションを使用してCloud Controlリポジトリに接続し、変更計画を作成して、リポジトリ内で変更アイテムの追加や更新を行うことができます。

クライアント・ユーザーのタイプは次の2つです。

- すべての変更計画の作成およびアクセスが可能なユーザー

- 特定の変更計画のアクセス(表示、場合によっては編集)が可能なユーザー

手順は次のとおりです。

1. 信頼できるクライアントによるアクセスが可能になるようリポジトリ・データベース・リスナーを構成します。リポジトリ・データベースは、信頼できないクライアントのログインからはアクセスできないようにすることをお薦めします。リスナーの構成の詳細は、『Oracle® Database Net Services管理者ガイド』を参照してください。

2. 外部クライアントが使用するためのCloud Control管理者を設定します。

次の項では、計画の変更、およびCloud Controlと外部クライアントからのアクセス用の管理者の設定方法を説明します。

変更計画用のCloud Control管理者の設定

次の手順に従います。

1. スーパー・ユーザーとしてCloud Controlにログインします。

2. 「設定」メニューから「セキュリティ」をクリックし、「管理者」を選択します。

3. 管理者ページで、「作成」をクリックします。

4. 管理者の作成: プロパティ・ページで、ユーザーの「名前」と「パスワード」を指定します。これにより、指定した名前とパスワードのデータベース・ユーザー、およびCloud Control管理者が作成されます。「次へ」をクリックします。

5. 管理者の作成: ロール・ページで、「次へ」をクリックします。

6. 管理者の作成: ターゲット権限ページで、「次へ」をクリックします。

7. 管理者の作成: リソース権限ページで「変更計画セキュリティ・クラス」を選択し、「権限付与の管理」アイコンをクリックします。

8. 管理者の作成: 権限の管理ページで、次のステップを実行します。

- すべての変更計画に対してすべてのアクセス権を持つ管理者を作成する場合は、「リソース・タイプ権限」セクションで「変更計画の管理」を選択します。

- 1つ以上の変更計画に対して特定のアクセス権を持つ管理者を作成する場合は、「リソース権限」セクションで「追加」を選択します。すでに作成されている変更計画のリストから1つ以上の変更計画を選択し、「選択」をクリックします。選択した計画が「リソース権限」セクションに追加されます。デフォルトでは、管理者には「変更計画の表示」権限が付与されます。これを編集して、「変更計画の編集」権限を付与することができます。

9. 「続行」をクリックします。

10. 「管理者の作成: 確認」ページで「終了」をクリックすると、新しい管理者が作成されます。

11. これらの権限タイプのいずれかを使用して外部クライアントが変更計画にアクセスできるようにするには、次の手順を実行します。

1. DBA権限を持つユーザーとしてリポジトリ・データベースにログインします。

2. 新しい管理者に該当するデータベース・ユーザーにCHANGE_PLAN_USERデータベース・ロールを付与します(Enterprise Manager管理者の「スキーマ」→「ユーザー」、またはSQL Plusを使用)。

47.5.3 SQL Developerインタフェースからのスキーマ変更計画の発行

開発者がSQL Developerインタフェースを介してスキーマ変更をEnterprise Managerスキーマ変更計画に発行できるようにするには、次の手動の構成手順を実行します。

1. リポジトリ管理者が、SQL Developerからのリモート・データベース接続を受け入れるようリポジトリ・データベースを構成してあることを確認します。これは、リポジトリ・リスナー・プロセスを構成することで行うことができます。

2. OMSでローカル管理者アカウントを作成します。

3. リポジトリ・データベースでSYSとして次のSQLコマンドを実行し、ローカルOMSアカウント権限のリポジトリ・ユーザーを変更計画ユーザーにします。

grant CHANGE_PLAN_USER to PUBLIC;

または

grant CHANGE_PLAN_USER to <repos_user>;

4. OMSユーザーのリソース権限を編集し、変更計画を編集するためのアクセス権をユーザーに付与します。

47.6 データベース・データ比較の使用

データの比較操作では、候補データベースのデータベース・オブジェクト・セット内のデータを参照データベースのものと比較します。同じデータベース内に存在するオブジェクトを比較するには、そのデータベースを参照および候補として選択します。比較の対象となるオブジェクトを指定して比較を作成し、比較を行うCloud Controlジョブをすぐに、あるいは後で発行できます。ジョブが完了したら、データの比較を選択し、結果を表示します。比較を削除すると、結果はパージされます。

Cloud Controlのデータの比較では、比較にDBMS_COMPARISONパッケージが使用されます。次のタイプのデータベース・オブジェクトを比較できます。

- 表

- 単一表ビュー

- マテリアライズド・ビュー

- 表、単一表ビューおよびマテリアライズド・ビューのシノニム

異なるデータベースにある異なるタイプのデータベース・オブジェクトを比較できます。たとえば、あるデータベースにある表と、別のデータベースにあるマテリアライズド・ビューを比較できます。

47.6.1 データベース・データ比較の要件

データの比較では、この項で説明する要件を満たす必要があります。

データベース・キャラクタ・セットは、比較対象のデータベース・オブジェクトが含まれているデータベースのものと同じである必要があります。

索引列、数値列、タイムスタンプ列および期間列のデータ型は次のとおりです。

- 数値列のデータ型は、NUMBER、FLOAT、BINARY_FLOATおよびBINARY_DOUBLEです。

- タイムスタンプ列のデータ型は、TIMESTAMP、TIMESTAMP WITH TIME ZONEおよびTIMESTAMP WITH LOCAL TIME ZONEです。

- 期間列のデータ型は、INTERVAL YEAR TO MONTHおよびINTERVAL DAY TO SECONDです。

データベース・オブジェクトには、次のいずれかのタイプの索引が必要です。

- 数値、タイムスタンプ、期間、DATEデータ型、VARCHAR2データ型またはCHARデータ型の列に対する単一列索引。

- 数値、タイムスタンプ、期間、DATE、VARCHAR2またはCHARの列のみが含まれているコンポジット索引。コンポジット索引内の各列は、NOTNULL制約を含んでいるか、または主キーの一部である必要があります。

データベース・オブジェクトにこれらのタイプの索引のいずれかが含まれていない場合、そのデータベース・オブジェクトはEMのデータの比較ではサポートされません。たとえば、データベース・オブジェクトにNVARCHAR2列に対する単一索引のみが含まれている場合、そのデータベース・オブジェクトはデータの比較でサポートされません。また、データベース・オブジェクトに1つのみの索引が含まれていて、その索引がNUMBER列およびNCHAR列を含むコンポジット索引である場合、そのデータベース・オブジェクトはデータの比較でサポートされません。

比較の索引列は、比較に関連するすべての行を一意に識別する必要があります。次の制約は、この要件を満たしている必要があります。

- 主キー制約

- 1つ以上のNULL以外の列に対する一意制約

索引を指定する場合は、索引の列が、これらの比較の要件を満たしていることを確認してください。

Cloud Controlのデータの比較機能では、次のデータ型の列のデータを比較できます。

- VARCHAR2

- NVARCHAR2

- NUMBER

- FLOAT

- DATE

- BINARY_FLOAT

- BINARY_DOUBLE

- TIMESTAMP

- TIMESTAMPWITHTIMEZONE

- TIMESTAMPWITHLOCALTIMEZONE

- INTERVALYEARTOMONTH

- INTERVALDAYTOSECOND

- RAW

- CHAR

- NCHAR

TIMESTAMP WITH LOCAL TIME ZONEデータ型の列を比較する場合、2つのデータベースで同じタイムゾーンが使用される必要があります。また、データ型がNVARCHAR2またはNCHARの列を比較する場合、2つのデータベースで同じ各国語キャラクタ・セットが使用される必要があります。

データの比較機能では、次のデータ型の列のデータは比較できません。

- LONG

- LONG RAW

- ROWID

- UROWID

- CLOB

- NCLOB

- BLOB

- BFILE

- ユーザー定義型(オブジェクト型、REF、VARRAY、ネストした表など)

- オラクル社提供のタイプ(任意のタイプ、XMLタイプ、空間タイプ、メディア・タイプなど)

比較の指定時にサポートされていない列を除外することによって、サポートされていない列が含まれているデータベース・オブジェクトを比較できます。比較アイテムを編集し、「含める列」リストの列名にサポートされている列のみを含めます。

データの比較では、LOB列値は直接比較できないため、かわりに暗号化ハッシュが比較に使用されます。LOB型の列を比較に含める場合、参照データベースと候補データベースに接続するデータベース・ユーザーにSYS.DBMS_CRYPTOパッケージに対するEXECUTE権限があることを確認します。DBMS_COMPARISONの詳細は、参照データベースのバージョンの『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

47.6.2 データベース・データの比較および結果の表示

次の手順を使用すると、参照および候補データベースで比較するオブジェクトのペアを指定し、選択内容を処理するジョブを発行し、ジョブが正常に完了した後に差異を表示できます。

1. データの比較メイン・ページから、「作成」をクリックします。「データ比較の作成」ページが表示されます(図47-15)。

図47-15 「データ比較の作成」ページ

2. 必要な入力を行います。

1. 2つのデータベース内に存在するオブジェクトを比較するには、1つのデータベースを参照、もう1つのデータベースを候補として選択します。

- 比較は常に参照データベースによって実行されるため、このデータベースはバージョン11g以上である必要があります。候補データベースはバージョン10g以上である必要があります。

- 参照データベースでは、処理負荷が余計にかかるため、(行全体ではなく)異なる行の行IDを格納するための領域が必要です。本番システムとテスト・システム間のデータを比較する場合、結果を処理してテスト・システムに格納する方が適切な場合があります。

2. 作業を終了後、「OK」をクリックします。データの比較仕様ページが表示されます。

ヒント:
比較指定を一度定義してそれを何度も実行することをお薦めします。

3. 「アクション」メニューを開き、「オブジェクト・ペアの追加」または「複数オブジェクトの追加」を選択します。「オブジェクト・ペア」を選択する場合、次のサブステップを続けます。「複数のオブジェクト」を選択する場合、ステップ4に進みます。

1. 参照および候補オブジェクトを指定します。参照データベースは候補データベースと同じでかまいません。この場合、オブジェクトは同じデータベースのものになります。

2. 比較用として参照または候補データベースで1つ以上の列を選択します。含まれる列は両方のオブジェクトで共通している必要があります。

3. 必要に応じて、比較用として使用する索引を選択します。比較索引内の列は、比較に含まれるすべての行を一意に識別している必要があります。1つ以上のNULL以外の列に対する主キー制約または一意キー制約に使用される索引はこの要件を満たします。この比較で指定した索引を使用できるのは、含める列のリスト内のすべての列を選択する場合のみです。
複数の索引列を追加する場合、コンポジット索引を選択できます。

4. 比較対象のオブジェクトのペアごとにオプションのWhere条件を指定します。

5. バケットの最大数およびバケット当たりの最小行を指定するか自動的に計算させます。

関連項目:
後述の「データベース・データの比較および結果の表示」。

6. データを比較する時点を指定します。

- システム変更番号(SCN)は、データベース内のある時点を正確かつ一意に識別する順次カウンタです。これは、ある時点を識別する最も正確な方法です。トランザクションをコミットするたびに、新規SCNが記録されます。SCNはアラート・ログから取得できます。

7. 構成が終了したら、「OK」をクリックします。
データの比較仕様ページが再表示され、選択したオブジェクトがリストに表示されます。

8. 「OK」をクリックし、ステップ5に進みます。

4. 「アクション」メニューを開き、「複数オブジェクトの追加」を選択します。

- 複数のオブジェクトを追加すると、参照データベースから仕様に対する複数のオブジェクトの一括追加を簡単に行うことができます。多数の表やビューなどの複数のオブジェクトを参照データベースの値リストから検索および選択し、必要に応じて各項目を編集できます。

1. スキーマ名、および1つ以上のオブジェクト・タイプを指定し、「検索」をクリックします。
表にはオブジェクト名が移入されています。

2. 比較するオブジェクトを選択し、「OK」をクリックします。
データの比較仕様ページが再表示され、選択したオブジェクトがリストに表示されます。

5. リストから比較名を選択し、「アクション」メニューを開き、比較ジョブの発行を選択します。参照データベースと候補データベースのユーザー資格証明に必要な権限の詳細は、「データベースの変更管理の概要」を参照してください。

6. ページで必要な資格情報を指定し、ジョブをスケジュールして「OK」をクリックします。
「データの比較」ページが再度表示され、次の確認メッセージが表示されます。

ジョブが正常に発行されました。ジョブ・ステータスを確認するには、「ジョブ・ステータス」列のリンクをクリックしてください。

「ジョブ・ステータス」列に「成功」と表示されたら、次の手順に進みます。

7. リストから比較名を選択し、「アクション」メニューを開き、「結果の表示」を選択します。データ比較結果ページが表示されます。

8. 参照行データと候補行データ間に差異があることを示す「=/=」記号がある「結果」列内の行を検索します。

- データ比較では、すべての表を比較します。エラーがあった場合、エラー・メッセージは、「メッセージ」タブを選択すると表示できます。エラー・メッセージは、「=」または「=/=」記号ではなく「X」で示されます。

- 比較を行うために実行中のSQL文を表示するには、「実行された文」タブをクリックします。

9. 異なる「参照」/「候補」行を選択し、「ビュー行の差異」をクリックして、「行データの差異」ページで、参照のみ、候補のみ、および差異ありの変更済の各行の詳細な索引付きリストを表示します(図47-16)。

- 「行ソース」列は、データの各行の元を全体的に示します。また、参照と候補で異なる行内のデータは対照的な色で表示され、データのソースが参照データベースと候補データベースのどちらであるかを示します。

- 比較はキー列に基づいて(選択した一意の索引に応じて)表示されます。キー列値が異なる場合、行は候補または参照のみの行として表示されます。他の列が異なる場合、行は差分行として表示されます。

図47-16 「行データの差異」ページ

スキーマ・マッピング

デフォルトでは、参照オブジェクトは、参照スキーマと同じ名前のスキーマの候補オブジェクトと比較されます。スキーマ・マッピングを使用すると、オプションで参照スキーマのオブジェクトと、異なる候補スキーマのオブジェクトを比較できます。スキーマをマップできるのは一度のみです。「データ比較仕様」ページの「スキーマ・マッピング」セクションで、マッピングの参照と候補のスキーマ名を指定します。これで、指定されたスキーマ・マッピングからデフォルトの候補スキーマが選択されます。

さらに、アイテムを編集して各アイテムの候補スキーマをオーバーライドできます。「候補オブジェクト」フィールドの横にある「オーバーライド」ボタンをクリックし、任意のスキーマに属する候補オブジェクトを明示的に指定します。このようにしてオーバーライドされた候補オブジェクトのアイテムの場合、スキーマ・マッピングは無視されます。

バケットの使用

バケットとは、比較中のデータベース・オブジェクト内の行の範囲です。バケットを使用すると、データベース・オブジェクトが複数の範囲に分割され、別々に比較されるため、パフォーマンスが向上します。それぞれの比較で、比較される行が適切な数のバケットに分割されます。使用されるバケットの数はデータベース・オブジェクトのサイズに応じて変化し、比較に指定されているバケットの最大数よりも常に少なくなります。

バケットを比較すると、次のような結果になる可能性があります。

- 違いが見つからない場合 —
次のバケットの比較に進みます。

- 違いが見つかった場合 -
そのバケットをより小さいパケットに分割して、それぞれのバケットを比較できます。小さいバケットで違いが検出された場合、そのバケットはさらに小さいバケットに分割されます。このプロセスは、バケットに許可される最小行数になるまで続行され、バケットに違いがあるかどうかを示す比較レポートが作成され、各行の違いが特定されます。

特定のデータベース・オブジェクトを比較する際にパフォーマンスを最適化するために、バケットの最大数とバケット当たりの最小行数を調整できます。

比較プログラムは、バケットのすべての行の指定列に対してORA_HASH関数を使用し、そのバケットのハッシュ値を計算します。2つの対応するバケットのハッシュ値が一致する場合、バケットの内容も一致するとみなされます。ORA_HASH関数では、行の値がデータベース間で転送されないため、効率よくバケットが比較されます。かわりにハッシュ値のみが転送されます。

注意:
比較の索引列がVARCHAR2またはCHAR列である場合は、バケット数がバケットの最大数に指定されている値を超える可能性があります。

48 リアルタイム監視の追加設定

Oracle Enterprise Manager Cloud Control (Cloud Control)のコンプライアンス機能を使用すると、ターゲットの特定の要素をリアルタイムで監視して、構成変更または構成変更につながるアクションを検分できます。

これらの機能には、オペレーティング・システム・レベルのファイル変更の監視、プロセスの開始と停止、オペレーティング・システムのユーザー・ログインおよびログアウト、Oracleデータベースの変更などがあります。

これらの機能のリアルタイム監視は、Cloud Controlエージェントから行います。この機能の中には、実行する監視のタイプや監視対象のオペレーティング・システムに応じて特定の設定手順を必要とするものもあります。

この項では、コンプライアンスのリアルタイム監視機能を使用するための特定の要件および前提条件について概説します。Cloud Controlからリアルタイム監視を使用する方法の詳細は、このドキュメントのコンプライアンス管理に関する章を参照してください。この章の構成は、次のとおりです。

- リアルタイム監視の概要

- リソース消費に関する考慮事項の概要

- 監視資格証明の構成

- Linuxホストを監視する準備

- Windowsホストを監視する準備

- Solarisホストを監視する準備

- AIXホストを監視する準備

- Oracleデータベースを監視する準備

- 変更リクエスト管理の統合の設定

- リアルタイム監視機能に関連するリポジトリ・ビューの概要

- データ保存期間の変更

- リアルタイム監視がサポートされるプラットフォーム

48.1 リアルタイム監視の概要

リアルタイム監視は、Cloud Controlサーバーを使用して構成します。EM_COMPLIANCE_DESIGNERロールを持つユーザーは、「リアルタイム監視ルール」タイプのコンプライアンス標準ルールを作成します。これらのルールはコンプライアンス標準と関連付けられ、続いてこれらの標準が1つ以上のターゲットに関連付けられます。

コンプライアンス標準とターゲットの関連付けが完了すると、一連の監視ルールがエージェントに送信されて、リアルタイム監視が有効になります。リアルタイム監視の監視はすべてエージェントで行われ、監視されたアクション・データはすべてエージェントからCloud Controlサーバーに送信され、レポートやデータ管理に使用されます。

48.2 リソース消費に関する考慮事項の概要

リアルタイム監視機能は、Cloud Controlエージェントに組み込まれています。リアルタイム監視機能を使用する場合、リソースに関する特定の考慮事項がいくつかあります。次の項では、リアルタイム監視機能を使用する際に考慮が必要な事項について説明します。

48.2.1 OSファイル監視のアーカイブ

ファイル変更をリアルタイムで監視する際は、オプションでエージェントにファイルのアーカイブ・コピーを作成するように設定できます。監視が最初に開始されると、その時点のファイルのコピーが作成されて、エージェントのORACLE_HOMEディレクトリ内のプライベート・ディレクトリに格納されます。その後は、そのファイルを変更すると、ファイルの追加コピーがその同じディレクトリ内にアーカイブされます。この機能を使用すると、後でユーザー・インタフェースからファイル差分を実行したり、ファイルを前のバージョンにロールバックするジョブを発行できます。

ただし、この機能では、ファイルのコピーを作成するためにディスク領域が使用されます。この機能は非常に重要なファイルに対してのみ有効にするように注意してください。作成時には、保存するファイルのコピー数を指定できます。デフォルトは5つの履歴バージョンです。これを調整することにより、潜在的なリソース消費をチューニングすることもできます。

Oracleデータベースの監視モジュールを初めて実行する際に以前のOracleデータベースの変更イベントをすべて無視するには、「ルール前のイベントを無視」フィールドでチェック・ボックスを選択します。

48.2.2 OSファイル読取りの監視

オペレーティング・システム・ファイル・レベルの監視では多くのタイプのファイル変更を監視できますが、ファイル読取りの監視も可能です。ファイル・パターンが頻繁に読み取られるファセットを監視するルールを使用すると、非常に多数の監視が生成されることがあります。監視の数を減らすには、ファイルを読み取ることのない時間またはユーザーに対するフィルタがルールに適用されていることを確認します。

たとえば、すべてのユーザーによる/etc/passwdファイルの読取りを監視すると、多数の監視が作成されます。しかし、特定のユーザーに関する/etc/passwdファイルのみを監視すれば、ルール作成時にその特定のユーザーに対するユーザー・フィルタを作成できます。これにより、その特定のユーザーがファイルの読取りを試行したときにのみ監視が送信されるようになります。

48.2.3 対象範囲が非常に大きいファセットの作成

ファセットは、セキュリティまたはコンプライアンスの目的で監視することが重要なファイルを指定するために作成するものですので注意してください。インスタンスの場合、数秒ごとに変化するログ・ファイルへの変更内容をすべて監視すると、レポートするファイルの変更点の数が多くなるため、確認する必要がある重要なファイルの変更点を識別するのが困難になってしまいます。この場合は、ログ・ファイルのすべての変更を監視するルールを作成し、非アプリケーション・ユーザーによりログ変更が行われた場合にのみフィルタ処理することをお薦めします。こうすることで、アプリケーションによりログ・ファイルが更新された場合は除外され、一般ユーザーがログの変更や改ざんを試行した場合のみログ・ファイル変更が取得されます。

48.2.4 Cloud Controlのリポジトリ・サイジング

リアルタイム監視でのデータベース・サイジングに関する考慮事項は、いくつかの要因に依存します。最も重要な要因は、予測される1か月当たりの監視数です。2番目の要因は、データがリポジトリに保存される月数です。リポジトリの保存率については、Enterprise Manager管理ガイドを参照してください。

一般に、1回の監視でデータベースの領域が約1.5KB消費されます。これはガイドラインであり、各インストールで多くの要因に応じて様々に異なります。

たとえば、すべてのターゲットにわたるリアルタイム監視数が月当たり合計1,000万件で、データの保存期間が12か月である場合、必要なデータベース・サイズは約180GBです。

10,000,000(監視)x 12(月)x 1500(バイト)= 180,000,000,000(バイト)

このサイズはリアルタイム監視データのみを表したものであり、他のCloud Control領域に必要なデータベース記憶域要件は含まれていません。

月当たりの予測監視数は環境によって異なり、また構成する監視のタイプによっても異なります。ルールおよびファセットを一定期間有効にし、組織の要件に合うように構成した後で、時間をかけて予測サイズを調整する必要があることがあります。1か月間の監視使用量を調べるには、「エンタープライズ」メニューから「コンプライアンス」を選択し、「リアルタイム監視」ページからシステムによる参照のUIレポートを選択してシステムを選択し、一定の期間の各システムの関連する監視数を表示します。

48.3 監視資格証明の構成

リアルタイム監視機能の多くには監視資格証明が必要であり、これにより常にルート権限で監視プログラムを起動できます。リアルタイム監視で使用されるこれらのプロセスの先頭には接頭辞nmxcがあります。低レベルの監視では、一般ユーザーには使用できないオペレーティング・システムAPIが使用されます。

ターゲット・ホストでリアルタイム監視機能の使用を開始する前に、Enterprise Managerコンソールから次の設定を構成しておく必要があります。

1. エージェントのインストール後にエージェントのroot.shスクリプトが実行されていることを確認します。
エージェントのインストール後、ルート・ユーザーとしてroot.shスクリプトを実行する必要があります。以降の資格証明手順を構成する前に、このスクリプトを実行する必要があります。

2. 権限委任を構成します。
「権限委任」設定を表示するには、「設定」メニューから「セキュリティ」、「権限委任」の順に選択します。このページでは、各ホストの権限委任を手動で設定することも、権限委任設定テンプレートを作成することもできます。

リアルタイム監視を行う各ホストに権限委任を設定するには、適切なSUDOコマンド(/usr/local/bin/sudoなど)を入力してSUDO設定を有効にする必要があります。

3. 監視資格証明を構成します。
「監視資格証明」設定には、「設定」メニューからアクセスできます。「セキュリティ」、「監視資格証明」の順に選択します。このページから、「ホスト」ターゲット・タイプを選択し、「監視資格証明の管理」をクリックします。

「リアルタイム構成変更監視のホスト資格証明」の資格証明が設定されている各エントリについて、エントリを選択して「資格証明の設定」をクリックします。使用する資格証明を指定するように要求されます。また、必ず「別名実行」エントリにrootを追加してください。「別名実行」が表示されない場合は、前の手順で権限委任が適切に設定されていないということです。

複数のホストに対して資格証明の一括監視を一度に設定するには、EMCLIを使用できます。EMCLIを使用した監視資格証明の設定の詳細は、『Oracle Enterprise Manager管理』のセキュリティに関する章でEMCLIを使用した資格証明の管理に関する項を参照してください。また、Cloud Controlでの監視資格証明の構成の詳細は、『Oracle Enterprise Manager管理』のセキュリティに関する章を参照してください。

48.4 Linuxホストを監視する準備

次の各項では、Linuxホストを監視する準備を行う方法について説明します。

48.4.1 OSファイル監視

Linuxのリアルタイム・ファイル監視を使用する前に、ロード可能なカーネル・モジュールをホストにインストールしておく必要があります。このロード可能カーネル・モジュールは、ホストを監視する最も効率的な手段です。このロード可能カーネル・モジュールは、ファイル監査モジュール(あるいは単に監査モジュール)と呼ばれます。

カーネル・モジュールの取得

カーネル監査モジュールは、http://oss.oracle.com/projects/fileauditmoduleから入手可能です。ファイル監査カーネル・モジュールを取得するには、2つの方法があります。

1. 事前作成.koファイル。Oracleで事前作成されたこのファイルを環境内で使用できます。事前作成カーネル・モジュールは、「ダウンロード」リンクから検索できます。一致する事前作成バージョンを調べるには、監視対象のホストでuname -rコマンドを実行し、そのバージョンを事前作成モジュールのバージョンと比較します。バージョン文字列全部が完全に一致する必要があります。32ビットのマシンの場合、.koファイル名の修正後の名前は.koになります。64ビットのマシンの場合、.koファイル名の修正後の名前は.k64.koになります。

2. 独自のカーネル・モジュールの作成。独自のカーネル・モジュールを作成するには、「ダウンロード」リンクから次のRPMをダウンロードできます。
Fileauditmodule-emversion-revision-noarch.rpm

このモジュールをインストールする際は必ず、その時点で入手可能な最新のリビジョンを取得してください。emversionフィールドは、使用しているCloud Controlエージェントおよびサーバーのバージョンと一致する必要があります。

このRPMをルートとして監視対象ホストにインストールします。このRPMのインストールは、ホストに存在する実行中のカーネルと一致するkernel-develパッケージに依存します。このkernel-develパッケージには、Linuxインストーラと同じメディアが付属しています。

このパッケージをインストールし、さらにホストで使用可能なgccのバージョンがカーネルの作成に使用されたバージョンと一致していることを確認する必要があります。このためには、/proc/versionファイルを参照してカーネルの作成に使用されたgccバージョンを確認し、続いてコマンドgcc –vを実行して使用中のgccバージョンを確認します。これらのバージョンは、一致している必要があります。

また、ファイル/boot/System.map-{version}が存在することを確認します。ここで、{version}は、uname -rコマンドを実行すると表示されるカーネル・バージョンと一致している必要があります。リアルタイムの変更を監視するには、このファイルに含まれるシステム・シンボルが、カーネル・シンボルのデコードのために必要です。このファイルがない場合、リアルタイムのファイル監視は機能しません。このファイルは、すべてのデフォルトのLinuxインストールで標準となっています。

このパッケージのインストールと前提条件のチェックが正常に完了したら、パッケージ・コンテンツがインストールされたディレクトリ(デフォルトでは/opt/fileauditmodule)に移動し、次のスクリプトを実行します。

compmod.sh

これによって、カーネル・モジュール・ファイル(OSのバージョンに応じて拡張子はko、.k64または.oのいずれかになる)が作成され、/opt/fileauditmoduleディレクトリに格納されます。

監査モジュール・ファイルが作成されていない場合は、make.logファイルとbuild.logファイルでモジュール作成のエラーを調べてください。

すべてのホストのカーネル・バージョンが、コマンドuname –rを使用して表示されたカーネル・バージョンと一致していれば、1つのマシンでモジュールをコンパイルするだけで済みます。その後は、.ko、.k64または.oファイルを他のサーバーにコピーできます。これらのファイルを特定のホスト上に作成する必要はありません。

カーネル・モジュールのデプロイ

事前作成.koファイルまたはソースRPMから作成した.koファイルは、適切なディレクトリに配置する必要があります。このファイルのデフォルトの場所は、エージェントのホーム・ディレクトリ内のbinフォルダです。また、このファイルをホスト上の任意の場所に格納して、エージェント・ホームのAGENT_INST/sysman/configディレクトリ内のnmxc.propertiesファイルを変更することもできます。プロパティnmxcf.kernel_module_dirは、.koディレクトリの絶対パスを指定します。

カーネル・モジュールのインストール・ジョブ

エージェントへの.KOファイルの手動配置以外にも、「リアルタイム監視カーネル・モジュールのインストール」という名前のCloud Controlジョブがあります。このジョブは、カーネル・モジュールをインストールできるLinuxホストのリストを使用して構成します。事前作成.koファイルまたはソースRPMファイルが、Cloud Controlサーバー・ディスクのディレクトリでローカルに検索されます。一致する事前作成.koファイルが見つかると、一致するエージェントに送信されます。見つからない場合、RPMがエージェントに送信、インストールおよびコンパイルされ、新しい.KOファイルが生成されます。

このジョブを使用する前に、ユーザーはOSS.ORACLE.COMからファイルを手動で取得して、
%ORACLE_HOME%/gccompliance/fileauditmodule/resources/linuxディレクトリに格納する必要があります。このディレクトリは、このディレクトリがこれらのファイルの格納場所であることを示すREADMEファイルとともに、すでにサーバー上に存在しています。ここに格納する必要のあるファイルは、事前作成.KOファイルまたはソースRPMファイルです。環境内に独自の.KOファイルを作成した場合は、これらの.KOファイルをサーバー上のこのディレクトリに格納して、環境内の他のホストにデプロイすることもできます。

Enterprise Linux 5以上に関する特別な考慮事項

Enterprise Linux 5以上の場合、カーネル監査モジュールは必要ありません。起動時にカーネル・モジュールが検出されない場合、監視には組込みの監査サブシステムが使用されます。ただし、監査サブシステムの機能はカーネル監査モジュールの機能ほど堅牢ではありません。

作成アクションであっても変更アクションであっても、どのようなタイプの変更がファイルに行われたかまでを調べる機能は失われます。カーネル・モジュールがない場合、ファイルに対するすべての変更は変更アクションとみなされます。また、まだ存在しないディレクトリの監視や、現在存在するが後で削除される可能性があるディレクトリの監視は、基礎となるLinux監査サブシステムによってこれらの監視が処理されないため、中断される可能性があります。

新バージョンのLinuxを使用する場合でも、可能であれば、カーネル監査モジュールを使用することをお薦めします。

48.4.2 カーネル・モジュールまたは他のファイル監視の問題のデバッグ

カーネル・モジュールに関する問題は、次の方法で検出できます。

1. 行われたはずのファイル変更に関して、Enterprise Managerコンソールにリアルタイム・ファイル変更が表示されていない場合があります。

2. ユーザー・インタフェースの「コンプライアンス標準ターゲット・アソシエーション」または「リアルタイム監視」ページに、カーネル・モジュールの問題を示すエージェント警告が表示されていることがあります。

3. AGENT_INST/sysman/logs内のnmxcf.logファイルを調べると、様々な理由でカーネル・モジュールをロードまたは使用できなかったことを示すエラーが表示されていることがあります。

このいずれかの問題が発生した場合、実行時にLinuxカーネル・モジュールのコンパイルまたは挿入に関連する問題があった可能性があります。

次のコマンドを実行すると、監査モジュールが適切にロードされたかどうかを確認できます。

grep -i auditmodule /proc/modules

出力が得られない場合、監査モジュールがロードされず、エージェントによってリアルタイム・ファイル監視は実行されません。

監査モジュール・ファイルが適切に生成されているのに、前述のモジュール・リストに表示されていない場合、手動でモジュールのロードを試行してエラーがないか確認してください。次のコマンドを使用します。{audit module file name}の箇所は、compmod.shから作成された.koファイルの名前全部で置き換えます。

insmod {audit module file name}

このコマンドでエラーが発生しなかった場合は、前述のgrepコマンドを使用して、モジュール・リストを再び確認します。監査モジュールが表示されれば、ファイル監査機能に問題はありません。エージェントは再起動する必要があります。ただし、ファイル監視プロセスで.koファイルの検出に関する問題が残っている可能性があり、ホストを次に再起動してもこの問題は再び発生します。

ファイル監視プロセスに関する問題をデバッグする追加手順の1つは、これを手動で実行する方法です。これを実行するには、次の手順に従います。

1. エージェントのTMMainプロセスのプロセスIDを取得します。
ps -eaf |grep TMMain

2. {}内の値を、正しいパス要素または前のコマンドからのプロセスIDに置き換え、次のコマンドを使用して、nmxcfプロセスを実行します。
sudo {agent_home}/core/{agent_version}/bin/nmxcf -e {agent_home}/agent_inst/ -m {agent_home}/agent_inst/sysman/emd/state/fetchlet_state/CCCDataFetchlet -w {process id of TMMAIN}

nmxcfプロセスをこの方法で実行しても、エージェントの再起動時に再開されないため、長期的にはこの方法は機能しませんが、プロセスを開始できない理由に関して問題をデバッグしようとする上で役立ちます。

モジュールがまだロードされず、この問題についてOracleサポートに連絡する場合は、必ず次の情報をサポート・チケットとともに提供してください。

- コマンドの出力: uname -a

- コマンドの出力: grep –i auditmodule /proc/modules

- コマンドの出力: rpm –q –a |grep –i kernel-devel

- compmod.shを実行した/opt/fileauditmoduleディレクトリからのmake.logファイルとbuild.logファイル(独自の.koファイルを作成した場合)

- ファイルAGENT_INST/sysman/log/nmxc*.log

- nmxcfを手動で開始しようとするときに受け取る任意の警告またはエラー

この情報は、エージェントのリアルタイム・ファイル監視の監査モジュールを環境内に作成できるかどうかをOracleサポートが判断する際に役立ちます。

警告:
カーネル・モジュールをアンロードするために使用されるLinux OSコマンドrmmodを使用する場合は注意が必要です。nmxcfバイナリの実行中にrmmodを使用する場合、使用中のカーネル・モジュールをアンロードしようとするとカーネル・パニックが発生する可能性があります。どのようなモジュールをアンロードする場合でも、Linuxでrmmodを使用する場合は慎重に作業する必要があります。

48.5 Windowsホストを監視する準備

リアルタイム監視機能は、Windows Server 2003および2008とともにWindows XPをサポートしています。Windowsでのリアルタイム監視モジュールは、アクションに関するすべての情報を収集する際に、オペレーティング・システムの様々な機能に依存しています。その1つは、Windowsイベント・ログから変更を行ったユーザーを取得することです。変更を行ったユーザーを取得するようにWindowsを構成していない場合、エージェントによりこの情報は取得されません。ただしその場合も、変更が行われたこと、およびいつ行われたかは取得されます。

リアルタイム監視と連携するようにイベント・ログを構成するには、次の手順を実行します。

1. Windowsエクスプローラから、リアルタイム監視ルールにより監視するディレクトリを選択し、右クリックして「プロパティ」を選択します。

2. 「セキュリティ」タブに移動します。

3. 「詳細設定」をクリックします。

4. 「監査」タブを選択します。

5. 「追加」をクリックします。(Microsoft XPでは、「監査エントリ」ウィンドウをダブルクリックします。)

6. 名前「Everyone」を選択し、「OK」をクリックします。また、Configuration Change Consoleルールで特定のユーザーによる変更のみを監視する場合は、特定のユーザーを選択することもできます。ルールでは、ユーザーによっても結果がフィルタされるため、すべてのユーザーの監査を有効にした場合でも、ルールで変更を監視するユーザーのみが取得されます。

7. 「アクセス」ウィンドウで次のオプション(「成功」または「失敗」あるいは両方)を選択します。Windows XPおよびWindows 2003の場合。

- ファイルの作成/データの書き込み

- フォルダの作成/データの追加

- サブフォルダとファイルの削除

- 削除

Windows 2008およびWindows 7の場合。

- ファイルの作成/データの書き込み

- フォルダの作成/データの追加

- 書込み属性

- 書き込み拡張属性

- サブフォルダとファイルの削除

- 削除

- 権限の変更

- 所有権の取得

8. 「OK」をクリックして終了します。

9. 監視対象の他のすべてのディレクトリまたはファイルについて、ステップ1から7を繰り返します。

10. 「スタート」メニューから、「設定」、「コントロール パネル」、「管理ツール」、「ローカル セキュリティ ポリシー」、「ローカル ポリシー」、「監査ポリシー」の順に選択します。次のポリシーをダブルクリックしてオンにします(「成功」または「失敗」あるいは両方)。

- アカウント ログオン イベントの監査

- ログオン イベントの監査

- オブジェクト アクセスの監査

11. 「ローカル セキュリティ設定」画面を閉じます。

12. 「スタート」メニューから、「設定」、「コントロール パネル」、「管理ツール」、「イベント ビューア」の順に選択します。

13. 「システム」ログを選択し、メニュー・バーの「操作」をクリックして「プロパティ」を選択します。

14. 「システム ログのプロパティ」パネルの「全般」タブで、「最大ログ サイズ」を5120KB(5MB)以上に設定し、「必要に応じてイベントを上書きする」を選択します。ログ・サイズは、2分間の報告期間にシステムで生成されるイベント数に依存することに注意してください。ログ・サイズは、それらのイベントを収容できるサイズに設定する必要があります。低い変更率が予測されるため、ファイル・イベントの監視時間を延長する場合は、Windowsの監査ログがイベントの取得に十分な大きさであることを確認する必要があります。

15. 「適用」、「OK」の順にクリックして終了します。

Windows監査が適切に設定されていない場合、Cloud Controlユーザー・インタフェースの「コンプライアンス標準ターゲット・アソシエーション」ページに警告が表示されます。このページは、リアルタイム監視のコンプライアンス標準をターゲットと関連付けたページです。

48.5.1 監査が適切に構成されているかの確認

ホストでログイン・イベントおよびログアウト・イベントが記録されることを確認するには、次の手順を実行します。

1. ホストからログアウトして、再びそのホストにログインします。

2. 「スタート」から、「設定」、「コントロール パネル」、「管理ツール」、「イベント ビューア」の順に選択します。

3. 「セキュリティ」ログを選択し、「表示」メニューから「フィルタ」を選択します。「イベント ソース」に「Security」を、「カテゴリ」フィールドに「ログオン/ログオフ」を選択します。

4. 「OK」をクリックします。

「イベント ビューア」では、このアクティビティがイベント528として記録されます。

48.5.2 外部subinaclの要件

前述のように、監査設定が適切に設定されていない場合、エージェントによりサーバーに警告が送信されます。ただし、これはWindows機能のSUBINACLがインストールされている場合のみ行われます。この機能がホストにインストールされていない場合は、監査設定が正しいかどうかをエージェントが検出できないという警告がサーバーに送信されます。この警告は、コンプライアンス標準ターゲット・アソシエーション・ページに表示されます。

subinaclを含むディレクトリの絶対パスを指定するには、AGENT_INST/sysman/config/nmxc.propertiesファイル内に次のプロパティを設定します。

nmxcf.subinacl_dir=

SubInACLはMicrosoft社のWebサイトからダウンロードできます。

48.6 Solarisホストを監視する準備

Solarisシステムでのリアルタイム監視には、Solaris Basic Security Model(BSM)の一部であるSolaris監査システムが使用されます。システム管理者はBSM監査を行って、イベントを監視し、ユーザー・アカウントのログインおよびログアウトやファイルの変更を検出することができます。

ルート権限で次のコマンドを実行して、BSM監査が有効になっていることを確認します。

/usr/sbin/auditconfig –getcond

次の出力が表示されます。

audit condition = auditing

出力がこれと異なる場合、別のSolarisリリースの別の方法を介してBSM監査を有効にする必要があることを意味します。

48.6.1 BSM監査の有効化

次の各環境に対して、次の手順を使用してBSM監査を有効にすることができます。

48.6.1.1 Solarisバージョン9および10を使用したBSM監査の有効化

BSM監査を有効にするには、ルート権限で次のコマンドを使用します。

/etc/security/bsmconv

BSM監視の設定の詳細は、『Solaris BSM Auditing』マニュアルを参照してください。

監査がサーバーですでに有効になっている場合は、次に詳しく示す構成と監査システム構成が一致することを確認してください。

監視ファイルは、特定のイベントを含むように構成できます。/etc/security/audit_controlファイルは、監査ファイルに含めるイベントを制御します。この項では、構成について要約します。詳細は、Sunの製品オンライン・ドキュメント・サイトを参照してください。

エンティティ・タイプOS FILE(ファイル変更)およびOS USER(ユーザー・ログイン/ログアウト)を監視する場合、ファイル/etc/security/audit_control内のフラグ行を次のように設定する必要があります。

フラグ: +fw、+fc、+fd、+fm、+fr、+lo

この構成により、ファイルの書込み(fw)、ファイルの作成(fc)、ファイルの削除(fd)、ファイル属性の変更(fm)、ファイルの読取り(fr)およびログイン/ログアウト・イベント(lo)の成功/失敗の監査が有効になります。+は、成功したイベントのみを記録するという意味です。

失敗したイベントのロギングも行う場合は、フラグの各イベントの前の+記号を削除します。

注意:
既存のホストにBSMをインストールする場合は、そのホストを再起動する必要があります。
ユーザーの監査: audit_userファイルは、監査対象のユーザーを制御します。このファイル内の設定は特定のユーザーに対するものであり、すべてのユーザーに適用されるaudit_controlファイル内の設定を上書きします。

監査ログおよびディスク領域: audit_controlファイルは、監査ログの格納場所や監査システムで使用されるディスク領域の最大容量を制御するためのエントリを使用します。ファイル監視の最小要件は、10分間(または構成されている報告間隔)でハード・ドライブに格納されるデータの容量にほぼ相当します。

48.6.1.2 Solaris 11を使用したBSM監査の有効化

Solaris 11では、監査はデフォルトで有効になっていますが、デフォルトで監視されるのはユーザーのログイン/ログアウトのみです。OSファイルの変更イベントとOSユーザーのログイン/ログアウトの両方の監視については、ルート権限で次のコマンドを実行できます。

/usr/sbin/auditconfig -setflags fw,fd,fc,fm,fr,lo

構成フラグの意味は、最後のセクションで定義されているものと同じです。

注意:
この構成は、ユーザーがすでにホストにログインしている既存のセッションには影響しないため、既存のセッションをすべて終了してから再度ログインするかマシンをそのまま再起動し、この変更を有効にする必要があります。
Solaris 11ではbsmconvコマンドが取り除かれているため、必要な場合、次のコマンドを使用して監査機能を有効にすることができます。

audit -s

48.6.2 監査ログ・ファイルの管理

Cloud Controlのリアルタイム監視では、監査ログが読み取られるのみであり、ログが削除されることはありません。このため、システムにログ・ファイルがあふれて、追加のイベントのロギングができなくなることがあります。監視の最小要件を保持しながら古い監査イベントを管理および削除するには、次の手順に従います。

1. 監査ポリシーを設定して、すべてのプロセスを一時停止するのではなく、新しいイベントを自動的に削除することができます(削除イベントの件数のみを記録)。これには、次のコマンドを実行します。
# auditconfig -setpolicy cnt

2. 次のコマンドを実行すると、監査デーモンが現在の監査ログ・ファイルを閉じて、新しいログ・ファイルを使用するように強制されます。
/usr/sbin/audit -n

3. 次のコマンドを実行すると、閉じている既存の監査ログ・ファイルがすべて.trashという拡張子の1つのファイルにマージされ、続いてそれらのファイルが削除されます。
/usr/sbin/auditreduce -D trash

4. 前述の手順2と3でコマンドを定期的に実行するためのcronジョブを作成します。これらの2つのコマンドを実行する頻度は、予測されるイベント件数と監査に割り当てられているディスク領域の容量に基づいて調整できます。要件は、audit -sコマンドとauditreduce - Dトラッシュ・コマンドの間の時間が15分間以上あるか、報告期間の2倍(変更された場合)であることのみです。

48.7 AIXホストを監視する準備

AIXシステムでのリアルタイム監視では、OSによって提供される基礎となるAIX監査サブシステムを使用します。現在サポートされているバージョンはIBM AIX 5.3および6.1のみです。

48.7.1 AIX 5.3のインストール前提条件

AIX 5.3ホストでリアルタイム監視を使用する前に、AIX 5.3 5300-08サービス・パック以降を使用していることを確認してください。このメンテナンス・パッケージはIBMから入手できます。

48.7.2 AIX監査の管理

AIX監査サブシステムを使用すると、管理者は、既存のセキュリティ・ポリシーに対する分析やセキュリティ違反の検出のために、ユーザーのログインやログアウトおよびファイルの変更といったセキュリティ関連の情報を記録できます。

監査の設定では、既存の監査構成ファイルを変更します。監査を設定するには、次の手順に従います。

1. rootユーザーとしてAIXマシンにログインします。

2. ターミナル・ウィンドウを開き、ディレクトリを/etc/security/auditに変更します。

3. viで構成ファイルを開きます。

4. 次のセクションを探して、ここに示す値を更新または追加します。

start:
binmode = off
streammode = on

stream:
cmds = /etc/security/audit/cccstream

classes:
…
filewatch = PROC_Create,PROC_Delete,FILE_Open,FILE_Write,FILE_Close,FILE_ Link,FILE_Unlink,FILE_Rename,FILE_Owner,FILE_Mode,FILE_Fchmod,FILE_Fchown,FS_Chdir,FS_Fchdir,FS_Chroot,FS_Mkdir,FS_Rmdir,FILE_Symlink,FILE_Dupfd,FILE_Mknod,FILE_Utimes

users:
root = filewatch
default = filewatch

注意:
この場合、defaultはroot以外のすべてのユーザーを意味します。また、構成ファイルの最後の行は空白行にする必要があります。

注意:
各パラメータ(binmode、streammode,、filewatch、rootおよびdefault)に対しては、前の部分にそれぞれタブを1つ用意する必要があります。監査システムですべての変数が適切に使用されていることを確認するには、audit queryコマンドを使用します。出力にfilewatchプロパティが表示されていることを確認します。

5. 変更を保存して、viを終了します。

6. 同じディレクトリ(/etc/security/audit/)で、viでファイルstreamcmdsを開きます。

7. このファイルのすべてのテキストを消去します。ファイル監視エージェント・モジュール(nmxcfプロセス)が直接の監査リーダーとして確認するため、このファイルのデフォルト構成は必要ありません。このファイルの内容を消去すると、CPU使用率が低減し、監査パフォーマンスが全体的に向上します。

8. ファイルを保存し、viを終了します。

9. ターミナル・プロンプトで、次のコマンドを入力してシステム起動時に監査を初期化します。
mkitab "audit:2:once:/usr/sbin/audit start"

10. プロンプトで、コマンド/usr/sbin/audit shutdownおよび/usr/sbin/audit startを使用して監査を再開するか、ホストを直接再起動して監査を有効にします。

11. プロンプトで、コマンドaudit queryを使用して、監査システムが使用している構成を表示します。プロパティが正しく設定されており、filewatchに必要な設定が行われていることを確認します。

48.7.3 OSユーザー監視モジュールのAIXシステム・ログ・ファイルの検証

OSユーザー監視モジュールは、次のシステム・ログ・ファイルに依存します。

- /etc/security/failedlogin

- /var/adm/wtmp

- /var/adm/sulog

AIXホストでOSユーザー監視モジュールを実行する前にログ・ファイルが存在することを確認してください。ログ・ファイルが欠落している場合は、その生成方法の詳細は、AIXシステムのドキュメントを参照してください。

48.8 Oracleデータベースを監視する準備

ここでは、Oracleデータベース内で監査を設定するための手順を説明します。Oracleエンティティ・タイプを使用してOracleデータベースを監視する場合は、イベントが取得される前にこれらの手順を実行する必要があります。

監査を構成する前に、『Oracle Database管理者ガイド』のデータベース使用の監査に関する項を参照してください。このドキュメントでは、Oracleの監査機能の概要および監査構成の基本概念とガイドラインが説明されています。Oracle監査システムの構成や細かいチューニングに関する詳細のすべては含まれないことに注意してください。このドキュメントは、リアルタイム監視ルールを使用したリアルタイム監視が有効になるようにOracle監査システムを構成する基本手順の一例を示したものです。

48.8.1 監査ユーザー権限の設定

リアルタイム監視のコンプライアンス標準ルールを作成してOracleインスタンス・ターゲットを監視すると、エージェントによって監査証跡が読み取られて、その監視が実行されます。

Oracleエンティティ・タイプのリアルタイム監視を行う場合は、監査証跡をファイルではなくデータベースに格納する必要があります。設定が正しいかどうかを確認するには、次の手順を実行します。

1. Cloud Controlで、リアルタイム監視を有効にするOracleデータベース・ターゲットのターゲット・ホームページに移動します。

2. 「管理」メニューから、初期化パラメータを選択します。

3. sysユーザーとしてデータベースにログインし、SYSDBAとして接続します。

4. audit_trailパラメータを探して、それがDBに設定されていることを確認します。そうでない場合、Oracleデータベース内でこのパラメータを変更する必要があります。

5. この変更ではデータベースの再起動が必要です。

48.8.2 監査オプションの指定

Oracle DBAは、SQL plusを介してaudit文およびnoaudit文を使用して、データベースの監査オプションを構成できます。audit文では次の3つのレベルで監査オプションを設定できます。

表48-1 監査オプション表

レベル

効果

文

特定のタイプのデータベース・オブジェクトに影響する特定のSQL文または文のグループを監査します。たとえば、AUDIT TABLEは、CREATE TABLE、TRUNCATE TABLE、COMMENT ON TABLEおよびDELETE [FROM] TABLEの各文を監査します。

権限

指定したシステム権限の下で実行されるSQL文を監査します。たとえば、AUDIT CREATE ANY TRIGGERは、CREATE ANY TRIGGERシステム権限を使用して発行された文を監査します。

オブジェクト

特定のオブジェクトに対する特定の文を監査します(employee表に対するALTER TABLEなど)。

audit文を使用して文や権限の監査オプションを設定するには、DBAにAUDIT SYSTEM権限が割り当てられている必要があります。audit文を使用してオブジェクトの監査オプションを設定するには、DBAが監査対象のオブジェクトを所有しているか、Oracle内でAUDIT ANY権限がDBAに割り当てられている必要があります。権限の割当てについては次の項で説明します。

文や権限の監査オプションを設定するaudit文にはBY句を含めることができ、監査する特定のユーザーまたはアプリケーション・プロキシのリストを指定できます。こうすることで、文と権限の監査オプションの範囲が限定されます。

次に監査文の例をいくつか示します。これらは、データベース内で指定する監査設定の基礎として自由に使用してください。すべての監査設定が完了すると、Oracleデータベース・インスタンスの監視に使用するOracle(SQLトレース)エージェント・モジュールを使用してアプリケーション・ポリシーを作成できるようになります。

文の監査オプション(ユーザー・セッション)

次の文は、BillおよびLoriというユーザーのユーザー・セッションを監査します。

AUDIT SESSION BY scott, lori;

権限の監査オプション

次の文は、DELETE ANY TABLEシステム権限の、成功および失敗したすべての使用を監査します。

AUDIT DELETE ANY TABLE BY ACCESS WHENEVER NOT SUCCESSFUL;

オブジェクトの監査オプション

次の文は、ユーザーjwardが所有するdept表に対する、成功したすべてのSELECT文、INSERT文およびDELETE文を監査します。

AUDIT SELECT, INSERT, DELETE ON jward.dept BY ACCESS WHENEVER SUCCESSFUL;

Oracle Audit Monitorの構成例

次のコマンドは、すべての基本文を監査します。それ以外の文は監査しません。

Audit all by access;

次の文は、基本以外のすべての文を監査します。

audit ALTER SEQUENCE, ALTER TABLE, DELETE TABLE, EXECUTE PROCEDURE, GRANT DIRECTORY, GRANT PROCEDURE, GRANT SEQUENCE, GRANT TABLE, GRANT TYPE, INSERT TABLE, LOCK TABLE, UPDATE TABLE by access;

次のコマンドは、文の監査設定を表示します。

SELECT * FROM DBA_STMT_AUDIT_OPTS;

監査構成を指定した後は、Cloud ControlサーバーからOracleデータベース・エンティティ・タイプを使用するリアルタイム監視ルールを作成できます。

48.9 変更リクエスト管理の統合の設定

この項では、変更管理サーバーのインストールおよび変更管理サーバーとの統合の構成を行う方法、および発生した変更が自動的に認可されたものかどうかを判断する方法を説明します。

48.9.1 BMC Remedy Action Request System 7.1の統合

Remedy ARS 7.1は、監視の自動リコンシリエーションを行うためにサポートされている変更管理システムです。次の手順では、Remedyの設定方法およびCloud Controlとの統合の構成方法について概説します。

48.9.1.1 Remedy ARSのインストールおよびカスタマイズ

Remedy ARS 7.1をインストールおよびカスタマイズするには、次の手順を実行します。

1. Remedy ARS 7.1をインストールします。次のコンポーネントがすべてインストールされ、適切にライセンスされていることを確認します。
ARS 7.1.00 Patch 011

Midtier 7.1.00 Patch 011

Flashboard Server 7.0.03

Assignment Engine 7.1

Asset Management 7.0.03*

CMDB 2.1.00 Patch 4

CMDB Extension Loader

Approval Server 7.1

Change Management Server 7.0.03 Patch 008*

Problem Management Server 7.0.03*

Incident Management Server 7.0.0*3

User Client

Administrator Client

これらのパッケージはすべてIT Service Management Packに付属しています。Oracleは、ITSM 7.0.03 Patch 008環境におけるRemedyのカスタマイズのサンプルを提供しています。バージョンが異なる場合、Remedyのバージョン間の違いに対応するためにカスタマイズを調整する必要があることがあります。

2. RemedyがインストールされているホストにCloud Control EMCLI_Clientをインストールします。この場合、Cloud Controlサーバーとの通信が可能である必要があります。

1. Enterprise Managerコンソールにログインします。

2. 「設定」を選択し、「プリファレンス」メニューから「コマンドライン・インタフェース」を選択します。

3. 「EM CLIキットをワークステーションにダウンロードします。」をクリックし、jarをRemedyサーバーにダウンロードします。

4. ページに示された手順に従って、EMCLIクライアントをRemedyサーバーにインストールします。

3. 変更リクエスト管理のコネクタ自己更新パッケージの最新バージョンを取得します。また、Cloud Controlバージョン12cのRemedy ARSカスタマイズのサンプルの最新バージョンも取得します。
これらの定義ファイルには、統合のために環境内で行う必要のあるカスタマイズのガイドラインが示されています。これらのカスタマイズ・ファイルでは、Remedy ARSのフレッシュ・インストールが前提となっています。Remedyの本番インスタンスと統合する際は、これらのカスタマイズがRemedyインスタンスに以前に行われたカスタマイズと互換しているか慎重に確認する必要があります。

- ActiveLinks _Customization.def

- Forms_Customization.def

- Menus_Customization.def

- Webservices_Customization.def

これらの定義ファイルを取得するには、Enterprise Manager自己更新ユーザー・インタフェースで、コネクタをエクスポートします。定義ファイルは、このコネクタ・パッケージの内部にあります。

4. 次の手順を実行して、実行中のRemedy環境に4つの定義ファイル(.DEF)をインストールします。

1. Remedy Administratorツールにログインします。

2. 左側の階層から「Remedy」インスタンスを選択します。

3. 「Tools」メニューから「Import Definitions」を選択し、「From Definition File...」を選択します。

4. 前述のリストから、インポートする定義ファイルを選択します。

5. 「Replace Objects on the Destination Server」というラベルのボックスを選択します。

6. ドロップダウン・オプション「Replace With New Type」を選択します。

7. 「Import」をクリックします。

8. このプロセス中にエラーは発生しないはずです。インポートが終わると、インポートの完了を示すメッセージが表示されます。

9. 完了したら、残りのカスタマイズ・ファイルについても同じ手順を実行します。

5. Webサービスをカスタマイズします。

1. Remedy Administratorツールにログインします。

2. 「Webservices」を選択し、Webサービス「EMCCC_GetCR」を選択します。右クリックし、「Open」を選択します。

3. 「WSDL」タブを選択します。

4. 一番上の入力で、「WSDL Handler URL」内のmidtier_serverおよびservernameの値を変更します。

5. 中間層がlocalhost上にある場合、http://の直後にlocalhostを入力できます。

6. 中間層でポート80が使用されている場合、ポートを省略できます。それ以外の場合は、サーバー名の後にポートを指定します。

7. servernameのpublic/の後に、Remedyサーバーの名前を入力します。

8. 「View」をクリックします。

9. WebサービスにはWebサービスWSDLファイルを表すXMLが表示されます。

10. エラーが表示される場合は、midtier_serverの名前、ポートまたはservernameを確認してください。また、servernameのドメイン部分を追加または削除してみてください。Remedyの「System」 > 「General」 > 「Serverinfo」 >「Connection Settings」で設定したmidtierパスワードが正しくない可能性がある場合、別の問題が発生することがあります。WSDL XMLが返されていない場合は、必ずこのことも確認してください。

11. 「View」をクリックした後にXMLコンテンツが表示されたら、このウィンドウを閉じて変更を保存します。

12. WebサービスEMCCC_PublishCSDataおよびEMCCC_UpdateChangeRequestに関して、前述の手順すべてを繰り返します。

6. アクティブ・リンクをカスタマイズします。

1. Remedy Administratorツールにログインします。

2. アクティブ・リンクを選択してから、アクティブ・リンク「EMCCCC_ApprovedCR」を選択します。右クリックし、「Open」を選択します。

3. 「If Action」タブをクリックします。

4. アクション・リストの最後にある現行アクション「Run Process」をクリックします。

5. 「Command Line」フィールドで、パスをemcli.batに変更して、emcliをインストールしたローカル・ホスト上のパスに一致させます。

7. 自動監視リコンシリエーションに使用されるリクエストを作成するためのユーザーをRemedy内に作成します。

1. 管理ユーザーとしてBMC Remedy User Clientにログインします。

2. User Clientのホームページで「Application Administration Console」をクリックします。

3. このウィザードのステップ1から4までを行う際は、そのたびに「Create」をクリックします。

4. 人を追加する場合、「Support Groups」タブでサポート・グループを追加します。

5. 「Support Groups」タブで、「Support Group Functional Roles」サブ・タブを選択します。

6. 機能的役割が「Infrastructure Change Management」のサポート・グループを追加します。これを行わない場合、「Infrastructure Change Manager」フィールドにサポート・グループの値がないために、変更リクエストを作成できなくなります。

7. AR System Administratorコンソールに移動します。

8. 左のサイド・バーで「Application」、「Users/Groups/Roles」、「Select Users」の順に選択します。

9. これにより、ユーザー検索ページがロードされます。右上の「Search」をクリックします。

10. 前述の手順で新規に作成したユーザーをダブルクリックして、ユーザー・フォームを表示します。

11. 「Group List」フィールドの隣の下矢印をクリックし、「Infrastructure Change Master」を選択します。

12. 前の手順を繰り返し、次のグループもこのユーザーに追加します。
Infrastructure Change Submit

Infrastructure Change User

Infrastructure Change Viewer

13. ウィンドウの右上隅にある「Save」ボタンをクリックして、このユーザーに対する変更を保存します。

48.9.1.1.1 Cloud Controlへのコネクタの追加

Cloud Controlにコネクタを追加するには、次の手順を実行します。

1. 変更管理コネクタをCloud Controlに追加します。

1. コネクタの作成権限を持つ管理ユーザーとしてEnterprise Managerにログインします。

2. 「設定」メニューで、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

3. 「アクション」をクリックし、「管理」を選択します。

4. 「追加」をクリックします。

5. 名前(self update swlibなど)を指定します。

6. swlibファイルを格納するCloud Controlサーバー上の場所を指定します。これはどこでもかまいませんが、Cloud Controlユーザーがアクセスできるパスである必要があります。ここには絶対パス全部を入力する必要があります。

7. このプロセスの完了には数分かかります。

8. コネクタ自己更新パッケージ・ファイルを見つけます。
コネクタjarは、自己更新コンソールを使用してCloud ControlストアからEM@Customerにダウンロードできます。また、自己更新のエクスポート機能を使用して、任意のローカル・ディレクトリにエクスポートできます。

9. emcli import_update -file=<full path>/connector.zip –omslocalを実行します(connector.zipは自己更新パッケージの名前の一例です)。

10. 前の手順でエラーが発生した場合は、emcliを実行したユーザーにこのディレクトリおよびファイルへのアクセス権限があることを確認してください。また、-fileスイッチに絶対パスを使用していることを確認してください。

11. 成功すると、次のメッセージが表示されます。
操作は正常に完了しました。更新はCloud Controlにアップロードされました。この更新を管理するには、自己更新ホームを使用してください。

12. Enterprise Managerコンソールにログインします。

13. 「設定」メニューで、「拡張性」、「自己更新」の順に選択します。

14. 「管理コネクタ」タイプを見つけて、このエントリの「ダウンロードされた更新」の下にあるリンク「1」をクリックします。

15. 表からコネクタを選択し、「適用」をクリックします。

2. 変更管理コネクタ・インスタンスを作成します。

1. Enterprise Managerコンソールにログインします。

2. 「設定」メニューで、「拡張性」、「管理コネクタ」の順に選択します。

3. 「コネクタの作成」の後のドロップダウンから「Remedy Change Management Connector」を選択し、「実行」をクリックします。

4. コネクタの名前と説明を入力します。この名前は、リアルタイム監視コンプライアンス標準ルールの作成でコネクタを選択する際に使用されます。

5. 管理コネクタ・リストのページに戻った後、新しく追加した行を選択し、「構成」をクリックします。

6. 「Webサービス・エンドポイント」ラベルで、[servername]および[port]を、RemedyインスタンスのWebサービスと一致するように変更します。ここには、先のWebサービスの手順で構成した値と同様の値を入力します。

7. コネクタ統合に使用するRemedyユーザー名およびパスワードを入力します。

8. ロケール(enなど)を入力します。

9. UTCからのRemedyサーバーのタイムゾーン・オフセット(-08:00など)を入力します。

10. テストとして使用する変更IDを入力します。これは、Cloud ControlとRemedyの間の接続のテストに使用される、Remedyに存在する有効な変更リクエストIDである必要があります。

48.9.1.1.2 自動リコンシリエーション・ルールの使用

自動リコンシリエーション機能を使用するようにRemedyをカスタマイズしてCloud Controlコネクタを構成した後は、自動リコンシリエーションを使用するように構成したリアルタイム監視ルールを作成する必要があります。次の手順を実行します。

1. リアルタイム監視ルールを作成します。

1. リアルタイム監視ルールを作成するための標準の手順を実行します。

2. 設定ページで「変更リクエスト管理システムを使用して監視を自動認証」を選択します。これにより、検出されたリアルタイム監視のリコンシエーションに対してRemedyによるこの変更リクエストが使用されるように、Cloud Controlが構成されます。

3. ドロップダウンからコネクタを選択します。

4. 認可済監視チェック・ボックスをクリックして、変更リクエストに注釈を付けます。

5. この後、引き続きルールを保存します。このリアルタイム監視ルールは、他のリアルタイム監視ルールと同様に使用できます。自動リコンシリエーションを使用したルールを持つ1つ以上のリアルタイム監視標準がターゲットに関連付けられるまで、新しい変更管理サーバーとの統合は開始されません。コンプライアンス標準を作成して、このルールをコンプライアンス標準に追加し、このコンプライアンス標準を1つ以上のターゲットに関連付けます。

ルールの構成の詳細は、コンプライアンス管理に関する項を参照してください。

48.9.1.1.3 今後の変更に使用する変更リクエストの作成

統合が設定され、リアルタイム監視ルールが作成されたので、RemedyユーザーはRemedyインタフェースで変更リクエストを作成できるようになります。これらの変更リクエストは発生した監視と比較されて、これらの監視が変更リクエストにより認可されたアクションに対応しているかどうかが自動的に判断されます。

この関係付けを行うには、変更リクエスト・ファイラによって、変更リクエスト・フォームに追加された新規のフィールドに入力する必要があります。すべてのフィールドが必須というわけではありません。関係付けは、変更リクエストに存在するフィールドに対してのみ行われます。

たとえば、Oracle Enterprise Managerの「統合」タブの変更リクエスト・フォームに次のフィールドが追加されたとします。

- コネクタ: Cloud Controlと統合するためにこの変更リクエストで使用するCloud Controlコネクタを選択します。

- ホスト名: この変更リクエストに対応するホスト名。この変更リクエストで誰かが変更する必要があることが指定されているホストです。このフィールドの値が空の場合、すべてのホストがこの変更リクエストに関係付けられます。

- ターゲット・ユーザー・リスト: この変更に対応するターゲット・ユーザーのユーザー名。変更を行うためにターゲットにログインするターゲット・ユーザーです。このフィールドの値が空の場合、ターゲット上のすべてのユーザーがこの変更リクエストに関係付けられます。

- ターゲット・タイプ: この変更リクエストのターゲット・タイプ。このフィールドの値が空の場合、任意のターゲット・タイプがこの変更リクエストに関係付けられます。

- ターゲット: この変更リクエストの特定のターゲット。このフィールドの値が空の場合、任意のターゲット・タイプがこの変更リクエストに関係付けられます。

- ファセット: この変更リクエストの特定のファセット。このフィールドの値が空の場合、前述のターゲット・タイプおよびターゲットのすべてのファセットがこの変更リクエストに関係付けられます。

リアルタイム監視ルールにより検出された変更の認可に使用する変更リクエストを作成する際は、変更リクエストの作成に必要な実装を組織が行うことに加え、次の手順を実行します。

1. 変更リクエスト・フォームの「日付」タブで、「スケジュール開始日」と「スケジュール終了日」を入力します。これらは、リクエストのリコンシリエーションが有効になる日付範囲です。この時間外にアクションが行われた場合、そのアクションはリアルタイム監視機能によって未認可としてマークされます。

2. Oracle Enterprise Managerの「統合」タブを選択します。

3. ドロップダウン・リストからCloud Controlコネクタを選択します。

4. オプションで、前述の5つのリコンシリエーション基準の値(「ホスト名」、「ターゲット・ユーザー・リスト」、「ターゲット・タイプ」、「ターゲット」および「ファセット」)を選択します。最後の3つ(「ターゲット・タイプ」、「ターゲット」および「ファセット」)は、Cloud Controlで作成された、ターゲットに関連付けられているコンプライアンス標準に属するリアルタイム監視ルールのコンテンツに基づいて、選択リストとなります。複数の値をカンマで区切って追加できます。

注意:
このフォームは、Remedyでカスタマイズして外観を変更できます。先にロードされたカスタマイズのサンプル・フォーム要素は、単なる例です。

5. 監査可能ステータスをTrueに変更します。これにより、検出されたリアルタイム監視のリコンシエーションに対してCloud Controlでこの変更リクエストを使用できるように、Remedyが構成されます。

6. 変更リクエストを保存します。

7. ポップアップが表示され、アクティブ・リンクによりコンテンツがCloud Controlに送信されることが通知されます。DOSコマンド・ウィンドウが開かれた後、閉じられます。

48.9.1.1.4 リコンシリエーション機能の概要

リアルタイム監視ルールにより監視されるターゲットまたはファセット(あるいはその両方)を参照する変更リクエストを作成すると、そのルールに対して発生した監視は、一致するすべてのオープン変更リクエストに関係付けられます。

監視がCloud Controlサーバーに到達すると、アクティブであった(スケジュール開始/停止時間に基づいて)、Cloud Controlの「統合」タブの相関基準と一致する、開いている変更リクエストがすべて評価されます。監視の基準と一致する変更リクエストが存在する場合、この監視には「認可済」の監査ステータスのマークが付けられます。ルール構成で「注釈」チェック・ボックスを選択した場合、これらの認可済監視の詳細がRemedy変更リクエストのEnterprise Managerの統合タブの表に取り込まれます。

監視に関係付けできるオープン変更リクエストがない場合、自動リコンシリエーションを使用するようにルールが構成されていれば、この監視は「未認可」監査ステータスに設定されます。この監視が属していた監視バンドルは違反とみなされ、その結果Cloud Controlイベントが作成されます。このイベントは、Cloud Controlイベント・ルールを作成することにより、さらに使用できます。

監視監査ステータスを確認するには、「コンプライアンス」、「リアルタイム監視」、「監視の検索」または参照画面のいずれかを選択して監視の詳細を確認します。適切なロールを持つユーザーは、これらのページから個々の監視の監査ステータスを上書きすることもできます。

未認可の監視が含まれるために違反となっているバンドルはすべて、コンプライアンス結果ページに違反として反映されます。これらの違反によって、コンプライアンス・スコア・スキューは低くなります。これらの違反がクリアされれば、スコアは高くなります。ただし、特定の監視についてのこれらの監査ステータス変更の履歴は保存されます。

48.10 リアルタイム監視機能に関連するリポジトリ・ビューの概要

リアルタイム監視データにアクセスできるビューは、次のとおりです。

ビュー: mgmt$ccc_all_observations

説明: このビューは、発生したすべての監視を戻します。このビューに対する問合せでは、適切なフィールドに対してフィルタ処理が行われるようにする必要があります。パーティションを最初に利用するフィールドはaction_timeにします。

フィールド:

フィールド

説明

OBSERVATION_ID

エージェントにより検出された監視に割り当てられる一意のID

BUNDLE_ID

ルール・バンドル設定に基づいてこの監視が属するバンドル

TARGET

この監視に対応するターゲット

TARGET_TYPE

ターゲットのタイプ

ENTITY_TYPE

アクションが行われたエンティティのエンティティ・タイプ

ACTION

監視されたアクション

ACTION_TIME

アクションが発生した時刻

USER_TYPE

アクションを実行したユーザーのタイプ(OSユーザー、DBユーザーなど)

USER_PERFORMING_ACTION

アクションを実行したユーザーの名前

ORIGINAL_USER_NAME

SU/SUDOアクションの場合、直前のユーザー名(一部のエンティティ・タイプにのみ適用可能)

AFFECTED_ENTITY_NAME

このアクションによる影響を受けたエンティティの名前(ファイル名など)

AFFECTED_ENTITY_PREVIOUS_NAME

アクションの前のエンティティの名前。たとえば、ファイル名変更アクションの場合、これは古いファイル名になります。

SOURCE_HOST_IP

アクションが別のホストから行われた場合、接続のソースIP(一部のエンティティ・タイプにのみ適用可能)

ACTION_PROCESS_ID

アクションを実行したプロセスのPID(一部のエンティティ・タイプにのみ適用可能)

ACTION_PROCESS_NAME

アクションを実行したプロセスの名前(一部のエンティティ・タイプにのみ適用可能)

ACTION_PARENT_PROCESS_ID

アクションを実行したプロセスの親プロセスのPID(一部のエンティティ・タイプにのみ適用可能)

ACTION_PARENT_PROCESS_NAME

アクションを実行したプロセスの親プロセスの名前(一部のエンティティ・タイプにのみ適用可能)

ENTITY_PREVIOUS_VALUE

エンティティの前の値(一部のエンティティ・タイプにのみ適用可能)

ENTITY_NEW_VALUE

エンティティの新しい値(一部のエンティティ・タイプにのみ適用可能)

FILE_ENTITY_PREVIOUS_MD5_HASH

エンティティの前のMD5ハッシュ値(一部のエンティティ・タイプにのみ適用可能)

FILE_ENTITY_NEW_MD5_HASH

エンティティの新しいMD5ハッシュ値(一部のエンティティ・タイプにのみ適用可能)

AUDIT_STATUS

監視の現行監査ステータス(unaudited、authorized、unauthorized,など)

AUDIT_STATUS_SET_DATE

最新の監査ステータスが設定された日付

AUDIT_STATUS_SET_BY_USER

最新の監査ステータスを設定したユーザー

ビュー: mgmt$ccc_all_obs_bundles

説明: このビューは、すべての監視バンドルのサマリーを戻します。このビューに対する問合せでは、適切なフィールドに対してフィルタ処理が行われるようにする必要があります。パーティションを最初に利用するフィールドはbundle_start_timeにします。

フィールド:

フィールド

説明

BUNDLE_ID

ルール・バンドル設定に基づいてこの監視が属するバンドル

TARGET

この監視に対応するターゲット

TARGET_TYPE

ターゲットのタイプ

RULE_NAME

リアルタイム監視コンプライアンス標準ルールの名前

ENTITY_TYPE

アクションが行われたエンティティのエンティティ・タイプ

USER_PERFORMING_ACTION

アクションを実行したユーザーの名前

BUNDLE_IN_VIOLATION

バンドルが現在違反しているかどうかを示すブール値。つまり、バンドル内の少なくとも1つの監視が未認可です。Trueは、バンドルが違反していることを示します。

BUNDLE_START_TIME

このバンドル内の最初の監視の日付

BUNDLE_CLOSE_TIME

このバンドルが閉じられた日付

BUNDLE_CLOSE_REASON

このバンドルが閉じられた理由の説明

DISTINCT_OBS_COUNT

このバンドル内の監視数の合計

AUTHORIZED_OBS_COUNT

このバンドル内の現在認可されている監視数

UNAUTHORIZED_OBS_COUNT

このバンドル内の現在未認可の監視数

UNAUTH_CLEARED_OBS_COUNT

このバンドル内の(一時は未認可であったが)現在クリアされている監視数

UNAUDITED_OBS_COUNT

このバンドル内の現在未監査の監視数。これらは、監査ステータスを判別するために手動あるいは変更管理統合による評価が行われていないものです。

ビュー: mgmt$ccc_all_violations

説明: このビューは、少なくとも1つの非認証監視が含まれる監視バンドルが原因で発生したリアルタイム監視違反をすべて戻します。

フィールド:

フィールド

説明

ROOT_CS_ID

ルート・コンプライアンス標準GUID。これは、違反コンテキストの内部表現に使用されます。

RQS_ID

ランタイム・コンプライアンス標準GUID。これは、違反コンテキストの内部表現に使用されます。

RULE_ID

ルールGUID。違反のあるルールの内部ID。

TARGET_ID

ターゲットGUID。違反のあるターゲットの内部ID。

ROOT_TARGET_ID

ルート・ターゲットGUID。ターゲット階層の内部ID。

RULE_TYPE

ルールのタイプ(リポジトリ、Weblogic Server署名、リアルタイム監視)

SEVERITY

ルールの重大度レベル(情報、警告、クリティカル)

BUNDLE_ID

違反のある監視バンドルの内部ID。この監視バンドルには、1つ以上の非認証監視が含まれます。

BUNDLE_START_TIME

監視バンドルが開始された時刻

BUNDLE_CLOSE_TIME

監視バンドルが閉じられた時刻

TARGET_TYPE

監視バンドルおよびこのバンドル内のすべての監視のターゲット・タイプ。

ENTITY_TYPE

監視バンドルおよびこのバンドル内のすべての監視のエンティティ・タイプ。

USER_NAME

このバンドル内のアクションを実行したユーザー名

AUTHORIZED_OBS_COUNT

この開発に関わる監視バンドル内の認証済監視の数。

UNAUTHORIZED_OBS_COUNT

この開発に関わる監視バンドル内の非認証監視の数。

UNAUDITED_OBS_COUNT

この開発に関わる監視バンドル内の非監査監視の数。

RULE_NAME

この違反があるルール名。

COMPLIANCE_STANDARD_NAME

この違反があるコンプライアンス標準。

TARGET

この違反があるターゲット名。

ビュー: mgmt$compliant_targets

説明: このビューは、すべてのターゲットのすべての評価および違反の詳細を戻します。これは、ターゲットの「コンプライアンス・サマリー」ダッシュボード・リージョンに表示されるものと同じデータです。

フィールド:

フィールド

説明

TARGET_ID

ターゲットの内部表現

TARGET_NAME

ターゲットの名前

TARGET_TYPE

ターゲットのターゲット・タイプ

TARTGET_TYPE_INAME

ターゲット・タイプの内部表現

CRIT_EVALS

クリティカル・レベルの評価の数

WARN_EVALS

警告レベルの評価の数

COMPLIANT_EVALS

コンプライアンス評価の数

CRIT_VIOLATIONS

クリティカル・レベルの違反の数

WARN_VIOLATIONS

警告レベルの違反の数

MWARN_VIOLATIONS

マイナー警告レベルの違反の数

COMPLIANCE_SCORE

ターゲットの現在のコンプライアンス・スコア

ビュー: mgmt$compliance_summary

説明: このビューは、コンプライアンス標準およびフレームワークのすべての評価および違反の詳細を戻します。これは、標準およびフレームワークの「コンプライアンス・サマリー」ダッシュボード・リージョンに表示されるものと同じデータです。

フィールド:

フィールド

説明

ELEMENT_NAME

コンプライアンス標準またはコンプライアンス・フレームワークの名前を表示します。

ELEMENT_ID

コンプライアンス標準またはコンプライアンス・フレームワークの内部ID

FRAMEWORK_ID

コンプライアンス・フレームワークの内部ID

CRIT_EVALS

クリティカル・レベルの評価の数

WARN_EVALS

警告レベルの評価の数

COMPLIANT_EVALS

コンプライアンス評価の数

CRIT_VIOLATIONS

クリティカル・レベルの違反の数

WARN_VIOLATIONS

警告レベルの違反の数

MWARN_VIOLATIONS

マイナー警告レベルの違反の数

COMPLIANCE_SCORE

標準またはフレームワークの現在のコンプライアンス・スコア

NON_COMPLIANT_SCORE

標準またはフレームワークの現在の非コンプライアンス・スコア

ELEMENT_TYPE

要素のタイプ(1=コンプライアンス標準、4=コンプライアンス・フレームワーク)

AUTHOR

標準またはフレームワークの作成者

VERSION

標準またはフレームワークのバージョン

ELEMENT_INAME

標準またはフレームワークの内部表現

ビュー: mgmt$compliance_trend

説明: このビューは、コンプライアンス・フレームワークおよびコンプライアンス標準の過去31日間のコンプライアンス傾向情報を戻します。これは、標準およびフレームワークの「コンプライアンス・サマリー」ダッシュボード傾向リージョンに表示されるものと同じデータです。

フィールド:

フィールド

説明

ELEMENT_ID

標準またはフレームワークの内部ID表現

FRAMEWORK_ID

コンプライアンス・フレームワークの内部ID表現

ELEMENT_NAME

コンプライアンス標準またはコンプライアンス・フレームワークの名前を表示します。

ELEMENT_INAME

標準またはフレームワークの内部表現

AVG_COMPLIANCE_SCORE

過去31日間の平均コンプライアンス・スコア

DAILY_AVG_VIOLATIONS

過去31日間の1日当たりの違反の平均数

SNAPSHOT_TS

スナップショットのタイムスタンプ

TOTAL_EVALS

過去31日間の合計評価

ELEMENT_TYPE

要素のタイプ(1=コンプライアンス標準、4=コンプライアンス・フレームワーク)

48.11 データ保存期間の変更

リアルタイム監視機能では、パーティション化およびデータ保存構成が使用されます。

各表とそのデフォルトの保存期間を次に示します。保存期間を変更する場合は、各種機能にわたってデータが整合するように、リアルタイム監視に関連するすべての表を同じ値に変更する必要があります。

注意:
データ保存値の変更の詳細は、『Oracle Enterprise Manager管理』の管理リポジトリのメンテナンスおよびトラブルシューティングに関する章を参照してください。

表名

デフォルトの保存期間

説明

EM_CCC_WATCHDOG_ALERTS

366日

該当する監視がアクティブではなかったときにエージェントが通知した警告が格納されています。

EM_CCC_HISTORY_JOBEXEC

366日

リアルタイム監視機能の一部として実行されるすべてのEnterprise Managerジョブの履歴が格納されています。

EM_CCC_OBSERVATION

366日

ユーザー・アクションの個別の監視内容が格納されています(各ファイルの変更、ログイン/ログアウト、プロセスの開始/停止、各データベース・オブジェクトの変更など)。

EM_CCC_OBSGROUP

366日

リアルタイム監視ルールのユーザー・インタフェースで設定したバンドル設定に基づいて、単一の監視が1つのバンドルにどのように関連しているかを示す情報が格納されています。

EM_CCC_OBS_GROUP_MAP

366日

単一の各監視バンドルとターゲット、ルール、および該当する監視アクションで監視していた標準の間の関係が格納されています。

EM_CCC_HISTORY_OBS_STATUS

366日

監視ごとの監査ステータス(非監査、未認可、認可)の状態変化に関する履歴が格納されています。

EM_CCC_HA_OBS

366日

1時間ごとの監視数の分析に関する要約、およびレポートされるその他の属性が格納されています。

EM_CCC_HA_OBSGROUP

366日

1時間ごとの監視バンドル数の分析に関する要約、およびレポートされるその他の属性が格納されています。

EM_CCC_FILEOBS_DIFF

366日

OSファイル・ベースの監視における以前のファイル比較内容が格納されています。

EM_CCC_AUTHOBS_CR_MAP

366日

この表には、監視を認可するのに使用された変更管理リクエスト・システムの変更リクエスト間のマッピングが格納されています。

EM_CCC_CMPUBACTION

366

コネクタを使用して、EMサーバーから統合変更管理サーバーにデータを公開するためのリクエストが格納されています。

EM_CCC_CMPUBACTION_DETAIL

366

コネクタを使用して、EMサーバーから統合変更管理サーバーにデータを公開するためのリクエストに関する追加の詳細が格納されています。

48.12 リアルタイム監視がサポートされるプラットフォーム

次の表に、リアルタイム監視がサポートされる様々なプラットフォームを示します。すべての表で、Xは、リストされているアクションがサポートされることを表し、NSは、サポートされない(not supported)ことを表します。

この時点では、次のオペレーティング・システムのプラットフォームの組合せはサポートされていません。

- Microsoft Windows -- IA64

- 任意のLinux -- IA64、PA-RISC、POWER

48.12.1 OSユーザーの監視

次の表に、OSユーザーの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-2 OSユーザーの監視

監視するアクション

Oracle/Redhat Linux

Windows

V4

V5

V6

XP

2003 Server

2008 Server (R1およびR2)

X86 32ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

Telnetログイン(成功)

X

X

X

X

X

NS

NS

NS

NS

NS

NS

Telnetログアウト(成功)

X

X

X

X

X

NS

NS

NS

NS

NS

NS

Telnetログイン(失敗)

X

X

X

X

X

NS

NS

NS

NS

NS

NS

SSHログイン(成功)

X

X

X

X

X

NS

NS

NS

NS

NS

NS

SSHログアウト(成功)

X

X

X

X

X

NS

NS

NS

NS

NS

NS

SSHログイン(失敗)

X

X

X

X

X

NS

NS

NS

NS

NS

NS

コンソール・ログイン(成功)

X

X

X

X

X

X

X

X

X

X

X

コンソール・ログアウト(成功)

X

X

X

X

X

X

X

X

X

X

X

コンソール・ログイン(失敗)

X

X

X

X

X

X

X

X

X

X

X

FTPログイン(成功)

NS

NS

NS

X

X

NS

NS

NS

NS

NS

NS

FTPログアウト(成功)

NS

NS

NS

X

X

NS

NS

NS

NS

NS

NS

FTPログイン(失敗)

X

X

X

X

X

NS

NS

NS

NS

NS

NS

SUログイン(成功)

X

X

X

X

X

NS

NS

NS

NS

NS

NS

SUログアウト(成功)

X

X

X

X

X

NS

NS

NS

NS

NS

NS

SUログイン(失敗)

X

X

X

X

X

NS

NS

NS

NS

NS

NS

SUDO(成功)

X

X

X

X

X

NS

NS

NS

NS

NS

NS

SUDO(失敗)

X

X

X

X

X

NS

NS

NS

NS

NS

NS

RDPログイン(成功)

NS

NS

NS

NS

NS

X

X

X

X

X

X

RDPログアウト(成功)

NS

NS

NS

NS

NS

X

X

X

X

X

X

RDPログイン(失敗)

NS

NS

NS

NS

NS

X

X

X

X

X

X

表48-3 OSユーザーの監視

監視するアクション

SUSE Linux

Solaris

AIX

V10

V11

V9

V10

V11

V 5.3

V 6.1

X86 32ビット

X86 32ビット

X86 64ビット

X86 64ビット

Sparc

X86 64ビット

Sparc

X86 64

Sparc

「POWER」

「POWER」

Telnetログイン(成功)

X

X

X

X

X

X

X

X

X

X

X

Telnetログアウト(成功)

X

X

X

X

X

X

X

X

X

X

X

Telnetログイン(失敗)

X

X

X

X

X

X

X

X

X

X

X

SSHログイン(成功)

X

X

X

X

X

X

X

X

X

X

X

SSHログアウト(成功)

X

X

X

X

X

X

X

X

X

X

X

SSHログイン(失敗)

X

X

X

X

X

X

X

X

X

X

X

コンソール・ログイン(成功)

NS

X

X

X

X

X

X

X

X

NS

NS

コンソール・ログアウト(成功)

NS

X

X

X

X

X

X

X

X

NS

NS

コンソール・ログイン(失敗)

NS

X

X

X

X

X

X

X

X

NS

NS

FTPログイン(成功)

X

NS

NS

X

X

X

X

X

X

X

X

FTPログアウト(成功)

NS

NS

NS

X

X

X

X

X

X

X

X

FTPログイン(失敗)

X

X

X

X

X

X

X

X

X

X

X

SUログイン(成功)

X

X

X

X

X

X

X

X

X

X

X

SUログアウト(成功)

NS

X

X

NS

NS

NS

NS

X

X

NS

NS

SUログイン(失敗)

X

X

X

X

X

X

X

X

X

X

X

SUDO(成功)

X

X

X

NS

NS

NS

NS

NS

NS

NS

NS

SUDO(失敗)

X

X

X

NS

NS

NS

NS

NS

NS

NS

NS

RDPログイン(成功)

NS

NS

NS

NS

NS

NS

NS

NS

NS

NS

NS

RDPログアウト(成功)

NS

NS

NS

NS

NS

NS

NS

NS

NS

NS

NS

RDPログイン(失敗)

NS

NS

NS

NS

NS

NS

NS

NS

NS

NS

NS

48.12.2 OSプロセスの監視

次の表に、OSユーザーの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-4 OSプロセスの監視

監視するアクション

Oracle/Redhat Linux

Windows

Solaris

V4

V5

V6

XP

2003 Server

2008 Server (R1およびR2)

V9

V10

V11

X86 32ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

X86 64ビット

Sparc

X86 64ビット

Sparc

X86 64ビット

Sparc

プロセス開始(成功)

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

プロセス停止(成功)

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

表48-5 OSプロセスの監視(続き)

監視するアクション

SUSE Linux

AIX

V10

V11

V5.3

V6.1

X86 32ビット

X86 32ビット

X86 64ビット

「POWER」

「POWER」

プロセス開始(成功)

X

X

X

X

X

プロセス停止(成功)

X

X

X

X

X

48.12.3 OSファイルの監視

Linux v5では、監視を行う方法は2つあります。次に示す監視対象アクションの中には、一方の方法でのみ監視できるものがあります。2つの方法は、ロード可能なカーネル・モジュールを使用することです。この方法によってのみ検出可能なアクションは、"(KO)"という注釈で示します。別のオプションはロード可能なカーネル・モジュールを使用しないことで、Linuxに組み込まれている監査方法を使用することになります。この方法でのみ監視可能なアクションは、"(非KO)"という注釈で示します。チェックマーク以外の注釈のないアクションは、いずれの方法でも監視できます。

Microsoft Windowsオペレーティング・システムのごみ箱からファイルをリストアする場合、この機能はオペレーティング・システムからは使用できないため、変更を加えたユーザーを特定することはできません。

Linuxオペレーティング・システムで、Oracleカーネル監査モジュール・メソッドではなくauditd監視メソッドを使用している場合、ディレクトリ作成操作はファイル作成操作としてレポートされます。さらに、ファイル作成アクティビティは、作成ではなくファイル変更としてレポートされます。これらは、監視でauditdメソッドを使用する際の制限事項です。LinuxでのOSファイル監視にOracleカーネル監査モジュールの手法を使用する場合、これらの制限事項は適用されません。

Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-6 OSファイルの監視

監視するアクション

Linux

Windows

Solaris

V4

V5

V6

XP

2003 Server

2008 Server (R1およびR2)

V9

V10

V11

X86 32ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

X86 64ビット

Sparc

X86 64ビット

Sparc

X86 64ビット

Sparc

ファイルの読込み(成功)

X

X

(KO)

X

(KO)

X (KO)

X (KO)

X

X

X

X

X

X

X

X

X

X

X

X

ファイル削除(成功)

X

X

X

X (KO)

X (KO)

X

X

X

X

X

X

X

X

X

X

X

X

ファイルの名前変更(成功)

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

ファイル作成(成功)

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

ファイル・コンテンツの変更(成功)

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

コンテンツ変更なしのファイル変更

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

ファイル変更(失敗)

NS

X (非KO)

NS

X (非KO)

X

NS

NS

NS

NS

NS

NS

NS

NS

NS

NS

NS

NS

ファイル権限の変更(成功)

NS

X (非KO)

X (非KO)

X (KO)

X

NS

NS

NS

NS

NS

NS

X

X

X

X

X

X

ファイル所有権の変更(成功)

NS

X (非KO)

X (非KO)

X (KO)

X

NS

NS

NS

NS

NS

NS

X

X

X

X

X

X

ファイル・コンテンツの変更(成功)アーカイブ・ファイル

NS

X (非KO)

X (非KO)

X

X

X

X

X

X

X

X

X

X

X

X

X

X

ファイルの読込み(失敗)

NS

NS

NS

NS

NS

NS

NS

NS

NS

NS

NS

X

X

X

X

X

X

ファイル削除(失敗)

NS

X

(非KO)

X

(非KO)

NS

NS

NS

NS

NS

NS

NS

NS

X

X

X

X

X

X

ファイルの名前変更(失敗)

NS

X

(非KO)

X

(非KO)

X (非KO)

X (非KO)

NS

NS

NS

NS

NS

NS

X

X

X

X

X

X

ファイル作成(失敗)

NS

X (非KO)

X (非KO)

X (非KO)

X (非KO)

NS

NS

NS

NS

NS

NS

X

X

X

X

X

X

ファイル権限の変更(失敗)

NS

X

(非KO)

X

(非KO)

NS

X (非KO)

NS

NS

NS

NS

NS

NS

X

X

X

X

X

X

ファイル所有権の変更(失敗)

NS

X

(非KO)

X

(非KO)

NS

X (非KO)

NS

NS

NS

NS

NS

NS

X

X

X

X

X

X

表48-7 OSファイルの監視(続き)

監視するアクション

SUSE Linux

AIX

V10

V11

V5.3

V6.1

X86 32ビット

X86 32ビット

X86 64ビット

「POWER」

「POWER」

ファイルの読込み(成功)

X

X (KO)

X (KO)

X

X

ファイル削除(成功)

X

X (KO)

X (KO)

X

X

ファイルの名前変更(成功)

X

X

X

X

X

ファイル作成(成功)

X

X

X

X

X

ファイル・コンテンツの変更(成功)

X

X

X

X

X

コンテンツ変更なしのファイル変更(成功)

X

X

X

X

X

ファイル変更(失敗)

NS

NS

NS

X

X

ファイル権限の変更(成功)

X

X (KO)

X

X

X

ファイル所有権の変更(成功)

X

X (KO)

X

X

X

ファイル・コンテンツの変更(成功)アーカイブ・ファイル

X

X

X

X

X

ファイルの読込み(失敗)

NS

NS

NS

X

X

ファイル削除(失敗)

NS

NS

NS

X

X

ファイルの名前変更(失敗)

NS

X (非KO)

X (非KO)

X

X

ファイル作成(失敗)

NS

NS

X (非KO)

X

X

ファイル権限の変更(失敗)

NS

X (非KO)

X (非KO)

X

X

ファイル所有権の変更(失敗)

NS

X (非KO)

X (非KO)

X

X

48.12.4 OS Windowsレジストリの監視

次の表に、OS Windowsレジストリの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-8 OS Windowsレジストリの監視

監視するアクション

Windows

XP

2003 Server

2008 Server (R1およびR2)

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

キーの作成(成功)

X

NS

X

X

X

X

キーの削除(成功)

X

NS

X

X

X

X

値の作成(成功)

X

NS

X

X

X

X

値の変更(成功)

X

NS

X

X

X

X

値の削除(成功)

X

NS

X

X

X

X

キーの作成(失敗)

X

NS

X

NS

NS

NS

値の作成(失敗)

X

NS

X

NS

NS

NS

値の変更(失敗)

X

NS

X

NS

NS

NS

値の削除(失敗)

X

NS

X

X

X

X

48.12.5 OS Windows Active Directoryユーザーの監視

次の表に、OS Windows Active Directoryユーザーの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-9 OS Windows Active Directoryユーザーの監視

監視するアクション

Windows

2003 Server

2008 Server (R1およびR2)

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

ユーザー作成(成功)

X

X

X

X

ユーザー削除(成功)

X

X

X

X

ユーザー属性変更(成功)

X

X

X

X

48.12.6 OS Windows Active Directoryコンピュータの監視

次の表に、OS Windows Active Directoryコンピュータの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-10 OS Windows Active Directoryコンピュータの監視

監視するアクション

Windows

2003 Server

2008 Server (R1およびR2)

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

コンピュータ作成(成功)

X

X

X

X

コンピュータ削除(成功)

X

X

X

X

コンピュータ属性変更(成功)

X

X

X

X

48.12.7 OS Windows Active Directoryグループの監視

次の表に、OS Windows Active Directoryグループの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-11 OS Windows Active Directoryグループの監視

監視するアクション

Windows

2003 Server

2008 Server (R1およびR2)

X86 32ビット

X86 64ビット

X86 32ビット

X86 64ビット

グループ作成(成功)

X

X

X

X

グループ削除(成功)

X

X

X

X

グループ属性変更(成功)

X

X

X

X

グループ・メンバー追加(成功)

X

X

X

X

グループ・メンバー削除(成功)

X

X

X

X

48.12.8 Oracle Database表の監視

次の表に、Oracle Database表の監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-12 Oracle Database表の監視

監視するアクション

Oracle Database

9i

10g

11g

12g

挿入(成功)

X

X

X

X

選択(成功)

X

X

X

X

更新(成功)

X

X

X

X

削除(成功)

X

X

X

X

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

切捨て(成功)

X

X

X

X

変更(成功)

X

X

X

X

コメント(成功)

X

X

X

X

名前変更(成功)

X

X

X

X

ロック(成功)

X

X

X

X

付与(成功)

X

X

X

X

取消し(成功)

X

X

X

X

監査(成功)

X

X

X

X

NOAUDIT使用

X

X

X

X

フラッシュバック(成功)

X

X

X

48.12.9 Oracle Databaseビューの監視

次の表に、Oracle Databaseビューの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-13 Oracle Databaseビューの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

挿入(成功)

X

X

X

X

選択(成功)

X

X

X

X

更新(成功)

X

X

X

X

削除(成功)

X

X

X

X

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

コメント(成功)

X

X

X

X

名前変更(成功)

X

X

X

X

ロック(成功)

X

X

X

X

付与(成功)

X

X

X

X

取消し(成功)

X

X

X

X

監査(成功)

X

X

X

X

NOAUDIT使用

X

X

X

X

フラッシュバック(成功)

X

X

X

48.12.10 Oracle Databaseマテリアライズド・ビューの監視

次の表に、Oracle Databaseマテリアライズド・ビューの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-14 Oracle Databaseマテリアライズド・ビューの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

挿入(成功)

X

X

X

X

選択(成功)

X

X

X

X

更新(成功)

X

X

X

X

削除(成功)

X

X

X

X

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

変更(成功)

X

X

X

X

コメント(成功)

X

X

X

X

ロック(成功)

X

X

X

X

付与(成功)

X

X

X

X

取消し(成功)

X

X

X

X

監査(成功)

X

X

X

X

NOAUDIT使用

X

X

X

X

48.12.11 Oracle Database索引の監視

次の表に、Oracle Database索引の監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-15 Oracle Database索引の監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

変更(成功)

X

X

X

X

分析(成功)

NS

X

X

X

48.12.12 Oracle Database順序の監視

次の表に、Oracle Database順序の監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-16 Oracle Database順序の監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

変更(成功)

X

X

X

X

選択(成功)

X

X

X

X

付与(成功)

X

X

X

X

取消し(成功)

X

X

X

X

監査(成功)

X

X

X

X

NOAUDIT使用

X

X

X

X

48.12.13 Oracle Databaseプロシージャの監視

次の表に、Oracle Databaseプロシージャの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-17 Oracle Databaseプロシージャの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

実行(成功)

X

X

X

X

付与(成功)

X

X

X

X

取消し(成功)

X

X

X

X

監査(成功)

X

X

X

X

NOAUDIT使用

X

X

X

X

48.12.14 Oracle Databaseファンクションの監視

次の表に、Oracle Databaseファンクションの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-18 Oracle Databaseファンクションの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

実行(成功)

X

X

X

X

付与(成功)

X

X

X

X

取消し(成功)

X

X

X

X

監査(成功)

X

X

X

X

NOAUDIT使用

X

X

X

X

48.12.15 Oracle Databaseパッケージの監視

次の表に、Oracle Databaseパッケージの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-19 Oracle Databaseパッケージの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

実行(成功)

X

X

X

X

付与(成功)

X

X

X

X

取消し(成功)

X

X

X

X

監査(成功)

X

X

X

X

NOAUDIT使用

X

X

X

X

48.12.16 Oracle Databaseライブラリの監視

次の表に、Oracle Databaseライブラリの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-20 Oracle Databaseライブラリの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

実行(成功)

X

X

X

X

付与(成功)

X

X

X

X

取消し(成功)

X

X

X

X

48.12.17 Oracle Databaseトリガーの監視

次の表に、Oracle Databaseトリガーの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-21 Oracle Databaseトリガーの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

48.12.18 Oracle Database表領域の監視

次の表に、Oracle Database表領域の監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-22 Oracle Database表領域の監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

変更(成功)

X

X

X

X

48.12.19 Oracle Databaseクラスタの監視

次の表に、Oracle Databaseクラスタの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-23 Oracle Databaseクラスタの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

変更(成功)

X

X

X

X

切捨て(成功)

X

X

X

X

48.12.20 Oracle Databaseリンクの監視

次の表に、Oracle Databaseリンクの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-24 Oracle Databaseリンクの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

48.12.21 Oracle Databaseディメンションの監視

次の表に、Oracle Databaseディメンションの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-25 Oracle Databaseディメンションの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

変更(成功)

X

X

X

X

48.12.22 Oracle Databaseプロファイルの監視

次の表に、Oracle Databaseプロファイルの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-26 Oracle Databaseプロファイルの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

変更(成功)

X

X

X

X

48.12.23 Oracle Databaseパブリック・リンクの監視

次の表に、Oracle Databaseパブリック・リンクの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-27 Oracle Databaseパブリック・リンクの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

48.12.24 Oracle Databaseパブリック・シノニムの監視

次の表に、Oracle Databaseパブリック・シノニムの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-28 Oracle Databaseパブリック・シノニムの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

48.12.25 Oracle Databaseシノニムの監視

次の表に、Oracle Databaseシノニムの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-29 Oracle Databaseシノニムの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

48.12.26 Oracle Databaseタイプの監視

次の表に、Oracle Databaseタイプの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-30 Oracle Databaseタイプの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

タイプ本体の作成(成功)

X

X

X

X

削除(成功)

X

X

X

X

変更(成功)

X

X

X

X

タイプ本体の削除(成功)

X

X

X

X

付与(成功)

X

X

X

X

取消し(成功)

X

X

X

X

監査(成功)

X

X

X

X

NOAUDIT使用

X

X

X

X

48.12.27 Oracle Databaseロールの監視

次の表に、Oracle Databaseロールの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-31 Oracle Databaseロールの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

変更(成功)

X

X

X

X

タイプ本体の削除(成功)

X

X

X

X

設定(成功)

X

X

X

X

48.12.28 Oracle Databaseユーザーの監視

次の表に、Oracle Databaseユーザーの監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-32 Oracle Databaseユーザーの監視

監視するアクション

Oracle Database

9i

10g

11g

12g

作成(成功)

X

X

X

X

ログオン(成功)

X

X

X

X

削除(成功)

X

X

X

X

変更(成功)

X

X

X

X

ログオフ

X

X

X

X

ロールの付与(成功)

X

X

X

X

ロールの取消し(成功)

X

X

X

X

システム権限の付与(成功)

X

X

X

X

システム権限の取消し(成功)

X

X

X

X

48.12.29 Oracle Database SQL問合せ文の監視

次の表に、Oracle Database SQL問合せ文の監視がサポートされるプラットフォームを示します。Xは、リストされているアクションがサポートされていることを表し、NSは、サポートされていない(Not Supported)ことを表します。

表48-33 Oracle Database SQL問合せ文の監視

監視するアクション

Oracle Database

9i

10g

11g

12g

変更されたSQL問合せ出力

X

X

X

X

49 変更アクティビティ・プランナの概要

変更アクティビティ・プランナ(CAP)を使用すると、データ・センター内の計画、管理および監視の操作を行うことができます。これらの操作には、チームおよびビジネス所有者間の依存性と調整、および複数のプロセスが含まれます。操作には、四半期ごとのセキュリティ・パッチのロールアウト、ビジネス要求に合せた新しいサーバーの構築、データ・センターの移行または統合、および環境全体へのコンプライアンス標準の導入を含めることができます。

CAPを使用すると、次のことが可能です。

- 開始日および終了日の設定、タスク・ステータスの作成、割当ておよび追跡などの変更アクティビティの計画。

- 自動化されたタスクの割当ておよび実行サポートを使用した、多数のタスクおよびターゲットの管理。

- ダッシュボードの使用(計画を監視して遅延の可能性を確認し、計画全体のステータスを迅速に評価できます)。

- タスクの優先度とスケジュールを表示する、タスクベースのダッシュボードを使用した、タスク所有者による自分のタスクの管理。

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

- 開始する前に

- 変更アクティビティ計画の作成

- 変更アクティビティ計画での操作

- 変更アクティビティ計画の管理

- マイ・タスクの表示

- 変更アクティビティ・プランナの使用例

49.1 開始する前に

変更アクティビティ・プランナを使用するには、必要な権限が付与されていることを確認して、さらにCAPで使用される用語について理解しておく必要があります。

49.1.1 変更アクティビティ・プランナのロールおよび権限

セキュリティ上の目的から、変更アクティビティ・プランナは次のロールを提供します。

- EM_CAP_ADMINISTRATOR

- EM_CAP_USER

EM_CAP_ADMINISTRATORロールはCREATE_JOB、CREATE_CAP_PLANおよびBASIC_CAP_ACCESS権限を付与します。計画を作成、類似作成、編集および削除するには、EM_CAP_ADMINISTRATORロールを付与されている必要があります。EM_CAP_USERロールはBASIC_CAP_ACCESS権限のみを付与します。基本のアクセス権限が有効でない場合、変更アクティビティ計画およびマイ・タスク機能にアクセスできなくなります。

変更アクティビティ・プランナ・セキュリティモデルは、所有者ベースの管理に準拠しています。オブジェクト・レベルの権限は現在サポートされていません。

49.1.2 変更アクティビティ・プランナで使用される用語

変更アクティビティ・プランナの主な概念は、計画、タスク定義、タスク・グループおよびタスクです。ここでは、これらの概念について詳細に説明します。

- 計画

- タスク定義

- タスク・グループ

- タスク

49.1.2.1 計画

計画により、新しい変更が組織に導入され、必要な変更の開始日と終了日が指定されます。これにより、必要な変更のセット、および変更が必要なターゲットが指定されます。

計画を作成するには、EM_CAP_ADMINISTRATORロールが付与されている必要があります。(詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の権限とロール管理に関する項を参照してください。)計画が作成されると、計画の進行状況を監視できます。計画を構成するすべてのタスクがクローズされると、計画は完了とみなされます。

計画を処理する場合は、次の用語が使用されます。

計画に関する用語

説明

アクティブ化の進行中

計画はアクティブ化されているプロセスの最中です。タスクの作成中です。計画は編集できません。

アクティブ化

計画の定義が完了していて、計画はアクティブ化されています。アクティブ化とは、タスクが作成されていて、計画の進行状況の管理を開始できるということです。

期限が切れた計画

オープン・タスクがまだ存在しているが、計画のスケジュール終了日を過ぎたアクティブな計画。

1週間以内の期限

7日以内に期限が切れるアクティブな計画。

計画の様々なステータスは次のとおりです:

計画のステータス

説明

アクティブ

タスクが作成され、すでに進行中の計画です。アクティブ化され、CAPがタスクを作成中である計画もアクティブとみなされます。CAPがタスクを作成している間、計画の進行状況は「アクティブ化の進行中」と表示されます。

完了

計画が完了しています。すべてのタスクが完了しているか、取り消されています

非アクティブ化済

計画がアクティブ化されたが、取り消されています。計画に関連付けられたすべてのタスクが取り消されています。計画はまだ「変更アクティビティ計画」ページに表示できます。類似作成、管理および削除などの操作は可能です。非アクティブ化した計画の計画の管理ページを表示できます。

進行中の定義

計画が部分的に定義されていて、将来の使用のために保存されています。計画を編集して定義を続行または完了し、計画をアクティブ化します。

アクティブ化に失敗しました

計画がアクティブ化されたときに、エラーが発生しました。「コメントおよび監査証跡」またはログ・ファイルにエラーの詳細が示されます。

アクティブ化を保留中

計画を後でアクティブ化するようにスケジュールされています。

49.1.2.2 タスク定義

計画の目的を満たすように実行する作業の手順を説明します。

タスク定義で記述されるアクションはターゲット・タイプに関連付けることができます。または、ターゲット・タイプは、オプションで「なし」に設定できます。これは、ターゲットはタスクに関連付けられないということです。通常これは、タスクで手動アクション(管理承認を得てから続行するなど)を定義している場合に当てはまります。この場合、タスク所有者は、管理承認を得て、タスクを完了としてマークして承認を確認し、その後、以降のタスクを続行します。

タスク定義でターゲット・タイプを指定した場合、1つ以上のターゲットに関連付けることができます。計画がアクティブ化されたときに、タスクがタスク定義とターゲットの各組合せに対して作成されます。ターゲット・タイプが指定されていない場合、単一のタスクが作成されます。

タスクには開始日およびスケジュール終了日が指定され、所有者に割り当てられます。

- タスク・タイプ: ユーザー用に生成するタスクのタイプを指定します。

- カスタム(または手動)
タスク定義に関連付けるアクションを指定できます。カスタム・タスク・タイプでは、次の2つのモードの検証をサポートしています:

- 手動
タスクの所有者はタスク・ステータスを更新する必要があります。

- コンプライアンス標準ルールの評価結果を使用して、ステータスを更新します。(ターゲット・タイプが指定されたタスク定義でのみ使用可能です。)
コンプライアンス標準ルールはタスク定義に関連付けることができます。タスクが生成され、ターゲットの作業が実行されたとき、このルールが評価されます。この結果を使用して、タスクがまだオープンなのか、またはタスクが自動的にクローズされるのかが判定されます。

- パッチ計画
これを選択すると、My Oracle Supportのパッチの更新のサポートと統合されます。パッチ・テンプレートがタスク定義に関連付けられます。タスクを割り当てると、テンプレートを使用して、パッチ計画を作成したりデプロイしたりできます。

パッチ・テンプレートとコンプライアンス・ルールの両方で、評価のベースとなるターゲット・タイプの選択が必要です。

- ジョブ
計画の作成者は、ジョブに基づいてタスクを作成できます。次に、タスク所有者が、タスクのジョブ発行や、既存のジョブ実行とタスクの関連付けを行います。ジョブの発行やタスクの関連付けには、マイ・タスク・ページまたは計画タスクの管理タブを使用します。

ライブラリ・ジョブは、タスクに関連付ける必要があります。ターゲット・タイプがタスクのターゲット・タイプと一致するライブラリ・ジョブのみを選択できます。

タスクの完了は複数の方法で指定できます。

- タスクは、ジョブが正常に完了したときに「完了」とマークされます。これはデフォルトの設定です。1日に1回、CAPにより、関連付けられているジョブ実行のステータスに基づき、ジョブベース・タスクが更新されます。
ジョブベース・タスクのステータスをすぐに更新するには、「マイ・タスク」ページまたは計画タスクの管理タブで、そのタスクを選択します。

- タスクは、タスク所有者により手動で「完了」とマークされます。

- タスクは、コンプライアンス・ルールの評価に基づいて「完了」とマークされます。

注意: CAPタスク定義で使用するジョブを選択する場合は、タスク所有者がジョブおよび適切なジョブ実行のアクセス権を持っていることを確認します。ジョブのアクセス権は、「ジョブ・ライブラリ」ページで変更できます。ジョブを作成または後で編集する場合は、「アクセス」タブを選択します。該当するユーザーのアクセス権を追加します。適切なアクセス権を付与できないと、タスク所有者のタスクに関連付けられているジョブをタスク所有者が表示できなくなります。

- デプロイメント・プロシージャ
計画の作成者は、構成済のデプロイメント・プロシージャとタスク定義を関連付けられます。使用可能な構成済のデプロイメント・プロシージャがポップアップに表示されます。

構成済のデプロイメント・プロシージャのみを選択できることに注意してください。構成済のデプロイメント・プロシージャを作成するには、プロシージャ・ライブラリ・ページからプロシージャを選択します。「起動」ボタンをクリックして、目的の属性を入力し、構成を保存します。

タスク所有者は、CAPタスクと「プロシージャ・ライブラリ」から起動されたプロシージャ実行を関連付けることができます。

タスクの完了は複数の方法で指定できます。

- タスクは、デプロイメント・プロシージャが正常に完了したときに「完了」とマークされます。これはデフォルトの設定です。

- タスクは、タスク所有者により手動で「完了」とマークされます。

- タスクは、コンプライアンス・ルールの評価に基づいて「完了」とマークされます。

注意: CAPタスク定義で使用するデプロイメント・プロシージャを選択する場合は、タスク所有者が、プロシージャ定義と、選択したプロシージャのプロシージャ実行に適切なアクセス権を持っていることを確認します。プロシージャ定義のアクセス権は、プロシージャ・ライブラリ・ページから編集できます。プロシージャ実行のアクセス権は、プロシージャ・アクティビティ・ページから編集できます。プロシージャを起動したら、CAPタスクに関連付けられているプロシージャ実行の権限を編集し、適切な管理者にアクセス権を付与します。適切なアクセス権を付与できないと、タスク所有者のタスクに関連付けられているプロシージャをタスク所有者が表示できなくなります。

- タスク・ステータス: タスク定義およびタスク・グループにはすべて、アイコンで示される、関連するステータスがあります。このステータスは、タスク定義またはタスク・グループを構成するタスクのステータスで判定されます。
例: タスク定義に4つの関連タスクが含まれていて、タスク1が「未確認」、タスク2が「完了」、タスク3が「進行中」、タスク4が「取消済」の場合、タスク定義のステータスは「進行中」です。

- 依存タスク(依存性): 別のタスクが完了するまで開始できないタスク。
タスク定義またはタスク・グループを作成する場合、別のタスク定義またはタスク・グループに単一の依存性を定義できます。計画がアクティブ化されたとき、タスクが生成されます。タスクの依存性は、計画の作成時に定義された依存性に基づいて決定されます。タスクが別のタスクに依存している場合、そのタスクが完了するのを待機しているときにフラグが設定されます。タスクがタスク・グループに依存している場合、そのタスク・グループ内のすべてのタスクが完了するのを待機しているときにフラグが設定されます。

49.1.2.3 タスク・グループ

1つ以上のタスク定義を含むフォルダ。計画のフェーズを示すために使用できます。計画を定義する際に、ターゲットをタスク・グループに割り当てることができます。タスク・グループ内のすべてのタスク定義は、ターゲットの割当てを継承します。タスク・グループを他のタスク定義またはグループに依存するように設定できます。これにより、タスク定義セット内での依存性を素早く設定できるようになります。

少なくとも1つのタスクが進行中の場合、タスク・グループは進行中になります。タスク・グループは、グループのすべてのタスクがクローズされると完了します。

49.1.2.4 タスク

計画がアクティブ化されたときに、タスクがタスク定義に基づいて作成されます。タスク定義にターゲットがある場合、タスクは各ライセンス対象のターゲットに対して作成されます。

タスクを処理する場合は、次の用語が使用されます。

タスクに関する用語

説明

未割当て

所有者がいないタスク。

オープン

ステータスが「未確認」、「確認済」または「進行中」のタスク。

クローズ

ステータスが「完了」、「取消済」または「非アクティブ化済」のタスク。

待機中

タスクが別のタスクに依存していて、依存される方のタスクがクローズしていないことを示します。タスクが待機中の場合、「タスク」表の「待機中」列に示されます。詳細を表示するには、タスクをクリックします。「トラッキング」セクションにタスクの依存性についての情報が表示されます。

対応が必要

特定の条件のタスクがチェックされます。見つかると、対応が必要としてタスクにフラグが設定されます。システムでは、次の条件のタスクがチェックされます:

- 期限切れ - タスクはまだオープンで、スケジュール済終了日が過ぎていることを示します。

- 1週間以内に期限切れ - タスクは7日以内に期限が切れることを示します。

- 計画終了日を超える終了日 - タスクのスケジュール済終了日が計画のスケジュール済終了日の後にあることを示します。

- 割り当てられていない - タスクに所有者がいないことを示します。

- 異常で完了しました - タスクは待機中に、「完了」に設定されました。

タスク・ステータスは、タスクがライフサイクルのどの位置にいるのかを示します。タスク・ステータスには次のものがあります:

タスク・ステータス

説明

未確認

計画がアクティブ化されたとき、すべてのタスクは確認済として開始されます。

確認済

ユーザーはタスクを確認したが、まだそのタスクについて作業を開始していないことを示します。

進行中

タスクの作業が開始したことを示します。

完了

タスクの作業が完了したことを示します。想定される変更が行われたことが検証されたときに、自動検証のタスクでは、このステータスが入力されます。手動タスクの場合、ユーザーは作業が完了すると、タスク・ステータスに「完了」を設定します。タスクが完了すると、詳細情報は読取り専用になります。注意: タスクの完了は取り消すことができません。

取消済

タスクで指定された作業が不要で、実行されないことを示します。タスクが取り消されると、詳細情報は読取り専用になります。注意: タスクの取消しは元に戻せません。

非アクティブ化済

計画を非アクティブ化すると、関連付けられたすべてのタスクが非アクティブ化済としてマークされます。

49.2 変更アクティビティ計画の作成

計画を作成する際には、計画の完了に必要なタスクを指定します。タスクを定義する際には、次の処理を行います。

- ターゲットとタスクの関連付け。

- タスク間の依存性の定義。依存性を設定すると、自動的、またはタスクの所有者が完了とマークしたときに、依存される方のタスクが完了するかキャンセルされるまで依存する方のタスクは開始できないという、警告シグナルが示されます。これによって、タスクの実行が必要になるタイミングをタスク所有者が検出できるようになります。

- 関連する依存性を持つ、ネストされたグループのタスクが含まれるタスク階層の指定。タスク・グループを使用すると、タスクを編成し、計画を処理するフローを構成できます。

- 計画のアクティブ化時のタスクの自動割当てまたは手動割当て。

- タスクの完了や、ターゲットに適用する必要のあるパッチ・テンプレートの選択のためのカスタムの指示の指定。

- タスクが終了したことをシステムで自動的に検出するかどうか、またはタスクの所有者が手動でタスクをクローズするかどうかの指定。

変更アクティビティ計画を作成する手順:

1. 「エンタープライズ」メニューから「構成」を選択し、「変更アクティビティ計画」を選択します。

2. 「変更アクティビティ計画」ページで、「作成」をクリックします。これにより、計画の作成ウィザードがアクティブ化します。

3. 計画の作成: プロパティ・ページで、次の一般的な情報を指定します:

- 名前

- ターゲット・タイプ - 計画のターゲット・タイプによって、計画のタスクと関連付けられるターゲットのタイプを決定します。

- 優先度 - 計画を管理する際に、優先度を使用して、タスクの所有権を割り当てて完了日に間に合うようにする重要性の順位を指定する場合があります。

- 説明 - 該当する情報を指定します。

- 外部リンク - 計画に関するドキュメントのリンクを追加することもできます。たとえば、リンクには、特定のパッチ・セットを説明するドキュメント、特定の内部手順またはポリシー、タスクによって影響を受けるアプリケーションのセットなどがあります。リンクの名前を指定して、URLを入力します。

「次へ」をクリックします。

4. 計画の作成: タスク定義ページの「追加」メニューで、「タスク・グループ」または「タスク定義」を選択して、この計画で実行するタスク・アクションの階層を作成します。
詳細は、「タスク定義の作成」および「タスク・グループの作成」を参照してください。

「次へ」をクリックします。

5. 計画の作成: スケジュール・ページでは、次のことを実行できます。

- 計画をすぐにアクティブ化するか、後で一度にアクティブ化します。

- 計画を完了するのに必要な期間または完了日を決定する。計画を完了する必要がある正確な日付、または計画をアクティブ化する日付に関連する完了日を指定します。

- タスクを自動または手動で割り当てる。タスクの手動割当てを選択する場合は、計画がアクティブ化されてからタスクを割り当てます。タスクを自動的に割り当てることを選択した場合、計画がアクティブ化されたときに、タスクはターゲットの所有者に割り当てられます。タスク所有者を作成する手順については、「グループ所有者へのタスクの割当て」を参照してください。

注意: 「アクティブ化」ページは、計画のアクティブ化の準備ができるまでブランクのままにできます。

「次へ」をクリックします。

6. 計画の作成: 確認ページで、入力したすべての情報が目的どおりに入力されていることを確認します。更新が必要な場合は、「戻る」ボタンをクリックして、必要な変更を加えます。
進行中の計画定義を保存するには、フロー(確認ステップ)の最後に移動し、「保存して終了」ボタンをクリックします。

注意: このページの情報は、「計画の作成: 確認」ページで「保存して終了」または「計画のアクティブ化」をクリックするまでは、保存されません。

49.2.1 タスク定義の作成

タスク定義を作成する際には、次の情報を入力してください。

1. タスクの名前を入力します。タスク・グループ名とタスク定義名は計画内で一意にする必要があります。
注意: 既存のタスクを選択した場合は、その前後にタスクを作成できるだけでなく、それに平行するタスクや、その内部にタスクを作成することも可能です。「前」または「後」を選択すると、タスクを実行する順序が指定され、それに応じたタスクの依存性が設定されます。順序が適切でない場合は、「移動」または「依存性の設定」を使用すると、順序を変更できます。

2. タスク定義が関連付けられているターゲット・タイプを選択します。
タスク定義がターゲットに基づいていない場合は、「なし」オプションを使用します。

3. タスク・タイプを選択します。次のオプションがあります。

- カスタム(または手動)
カスタムタスクとは、各自で定義するタスクです。カスタム・タスクには、手動で実行するタスク(通常はEnterprise Manager外)を含めることができますが、計画の一部になるようにしてください。

タスク所有者がタスクを完了するために必要な情報を「アクション」フィールドに入力するか、「リンク」セクションにURLとタスクの手順を追加します。

さらに、タスクが完了していることを確認する方法を指定します。

- 適切な場合にタスク所有者がタスクを完了済として手動でマークすることを示すには、「タスク所有者がステータスを更新します。」を選択します。タスクは、「計画の管理」ページまたは「マイ・タスク」ページから完了済としてマークできます。

- 選択したコンプライアンス・ルールにターゲットが準拠している場合に、タスクが完了済として自動的にマークされることを示すには、「コンプライアンス標準ルールの評価結果を使用して、ステータスを更新します。」を選択します。タスク・ターゲット・タイプに適したルールのリストからコンプライアンス・ルールを選択するには、拡大鏡をクリックして、「コンプライアンス標準ルールの検索と選択」ダイアログ・ボックスにアクセスします。

- パッチ計画
このオプションを選択した場合は、「テンプレートのパッチ提供」ダイアログ・ボックスを使用して、タスクのターゲットに適用するパッチのリストが指定されたパッチ・テンプレートを選択します。

このタスク定義の各ターゲットのタスクは、パッチがターゲットにデプロイされたことが検出されると自動的にクローズされます。

「アクション」フィールドに詳細な手順を追加したり、タスク所有者の詳細情報のURLを「リンク」セクションに追加したりできます。

- ジョブ
このオプションを使用すると、計画の作成者は、ジョブに基づいてタスクを作成できます。拡大鏡をクリックして「ジョブの検索と選択」ダイアログ・ボックスにアクセスし、実行するジョブを選択します。

タスク所有者は、タスクのジョブ発行や、既存のジョブ実行とタスクの関連付けを行います。ジョブの発行やタスクの関連付けには、マイ・タスク・ページまたは計画タスクの管理タブを使用します。

ライブラリ・ジョブは、タスクに関連付ける必要があります。ターゲット・タイプがタスクのターゲット・タイプと一致するライブラリ・ジョブのみを選択できます。

タスクの完了は複数の方法で指定できます。

- タスクは、ジョブが正常に完了したときに「完了」とマークされます。これはデフォルトの設定です。
1日に1回、CAPにより、関連付けられているジョブ実行のステータスに基づき、ジョブベース・タスクが更新されます。ジョブベース・タスクのステータスをすぐに更新するには、マイ・タスク・ページまたは計画タスクの管理タブで、そのタスクを選択します。

- タスクは、タスク所有者により手動で「完了」とマークされます。

- タスクは、コンプライアンス・ルールの評価に基づいて「完了」とマークされます。

注意: CAPタスクで使用するジョブを選択する場合は、タスク所有者がジョブおよび適切なジョブ実行のアクセス権を持っていることを確認します。ジョブのアクセス権は、「ジョブ・ライブラリ」ページで変更できます。ジョブを作成または後で編集する場合は、「アクセス」タブを選択します。該当するユーザーのアクセス権を追加します。適切なアクセス権を付与できないと、タスク所有者のタスクに関連付けられているジョブをタスク所有者が表示できなくなります。

- デプロイメント・プロシージャ
計画の作成者は、デプロイメント・プロシージャとタスク定義を関連付けられます。拡大鏡をクリックして「デプロイメント・プロシージャの検索と選択」ダイアログ・ボックスにアクセスし、適切なデプロイメント・プロシージャを選択します。

注意: 構成済のデプロイメント・プロシージャのみを選択できます。構成済のデプロイメント・プロシージャを作成するには、プロシージャ・ライブラリ・ページからプロシージャを選択します。「起動」ボタンをクリックして、目的の属性を入力し、構成を保存します。

タスク所有者は、CAPタスクと「プロシージャ・ライブラリ」から起動されたプロシージャ実行を関連付けることができます。必要なプロシージャ実行を表示する権限をタスク所有者が持っていることを確認します。

タスクの完了は複数の方法で指定できます。

- タスクは、デプロイメント・プロシージャが正常に完了したときに「完了」とマークされます。これはデフォルトの設定です。

- タスクは、タスク所有者により手動で「完了」とマークされます。

- タスクは、コンプライアンス・ルールの評価に基づいて「完了」とマークされます。

注意: CAPタスクで使用するデプロイメント・プロシージャを選択する場合は、タスク所有者が、プロシージャ定義と、選択したプロシージャのプロシージャ実行に適切なアクセス権を持っていることを確認します。プロシージャ定義のアクセス権は、プロシージャ・ライブラリ・ページから編集できます。プロシージャ実行のアクセス権は、プロシージャ・アクティビティ・ページから編集できます。プロシージャを起動したら、CAPタスクに関連付けられているプロシージャ実行の権限を編集し、適切な管理者に権限を付与します。適切なアクセス権を付与できないと、タスク所有者のタスクに関連付けられているプロシージャをタスク所有者が表示できなくなります。

4. このタスク定義のアクション(例: ブラックアウトのスケジュール、データベースのバックアップなど)を指定します。

5. 検証方式を選択します。表示される方法は、タスクのタイプによって異なります。次のような方法があります。

- タスク所有者は手動でタスク・ステータスを更新しますTask owner will manually update the status

- ジョブ実行のステータスを使用して、ステータスを更新します。

- プロシージャ実行のステータスを使用して、ステータスを更新します。

- コンプライアンス標準ルールの評価結果を使用して、ステータスを更新します。。コンプライアンス標準ルールを選択します。

パッチ計画デプロイメントは、システムによって自動的に検証されます。

6. 「追加」をクリックして、タスク定義に関するドキュメントのリンクを追加します。リンクの名前を指定して、URLを入力します。

7. 「次へ」をクリックします。

注意: このページの情報は、「計画の作成: 確認」ページで「保存して終了」または「計画のアクティブ化」をクリックするまでは、保存されません。

依存性の設定

タスク定義を計画に追加する場合、「後に追加」または「前に追加」オプションを使用すると、タスク依存性が自動的に設定され、タスクを完了する順序が指定されます。順序を変更する場合は、「移動」オプションを使用して、別のタスクの前後に1つのタスクを移動します。

タスク定義間に依存性を手動で指定し、別のタスク定義を開始する前にタスク定義を完了する必要があるかどうかを指定できます。「依存性の設定」を使用して、タスクを移動し、そのタスクの後に、別のタスクの後で実行するすべてのタスクを移動します。依存性を設定するには、タスク定義を選択して、ツールバーの「依存性の設定」をクリックします。選択したタスク定義の開始前に完了するタスク定義を指定します。これにより、タスク所有者が異なる順序でタスク定義を完了できなくなることはありません(タスク所有者は依存性を確認できるようになり、依存性が完了するまでタスク定義を待機するように警告が表示されます)。

依存性は、同じレベルのタスク定義ツリーで定義されていて、選択したタスク定義上に表示されるタスク定義でのみ作成できます。

タスク定義の移動

タスク定義を選択して「移動」ボタンをクリックすることによって、タスク定義をツリー内の別の場所に移動できます。タスク定義を移動して依存性を削除する必要がないかぎり、タスク定義の実行の順序が影響を受けることはありません。ターゲットがタスク・グループから継承される場合に、タスク定義をタスク・グループに移動したり、タスク・グループから移動したりすると、タスク定義に追加したターゲットが影響を受ける可能性があります。

注意: このページの情報は、「計画の作成: 確認」ページで「保存して終了」をクリックするまでは、保存されません。

ターゲットの追加

タスクに関連付けられたターゲットを選択するには、「ターゲットの追加」をクリックします。計画をアクティブ化するには、ターゲット・タイプが「なし」のタスクを除き、各タスクに1つ以上のターゲットが関連付けられている必要があります。

計画のターゲット・タイプがシステムの場合、タスク定義に適したシステムのターゲットにのみタスクが作成されます。

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

- 追加できるのは、計画のターゲット・タイプに対応するターゲットのみです。計画のターゲット・タイプがシステムの場合、タスク定義に適したターゲットにのみタスクが作成されます。
たとえば、計画ターゲット・タイプがデータベース・システムで、タスク定義の対象がリスナーの場合、選択したデータベース・システムに関連付けられたリスナー・ターゲットにタスクが作成されます。

- タスク・グループへのタスクの割当て
ターゲットをタスク・グループに割り当てると、ターゲットはグループ内のすべてのタスクにも追加されます。

- タスクによりターゲット・タイプを指定する場合は、計画をアクティブ化する前に、少なくとも1つのターゲットを関連付けておく必要があります。

- タスクまたはタスク・グループに追加されたターゲットを確認するには、タスク定義を選択し、「ターゲットの編集」ボタン、または表のターゲット数をクリックします。
「ターゲットの編集」ダイアログ・ボックスに、選択したタスクに直接追加したターゲットと、包含するタスク・グループから継承されたターゲットが表示されます。

49.2.2 タスク・グループの作成

タスク・グループを使用してタスクを整理します。タスク・グループは、ターゲットをタスクに割り当てる場合に便利です。ターゲットがタスク・グループに追加されると、ターゲットはグループ内のタスクにも追加されます。

次の情報を指定します。

1. タスク・グループの名前を入力します。タスク・グループ名とタスク定義名は計画内で一意である必要があります。
注意: 既存のタスク・グループを選択した場合は、その前後にタスク・グループ(またはタスク定義)を作成できるだけでなく、それに平行するタスク・グループや、その内部にタスク・グループを作成することも可能です。「前」または「後」を選択すると、タスク・グループ(またはタスク定義)を実行する順序が指定され、それに応じたタスク・グループ(またはタスク定義)の依存性が設定されます。順序が適切でない場合は、「移動」または「依存性の設定」を使用すると、順序を変更できます。

2. タスク・グループの説明を入力します(例: グループの目的)。タスク・グループは関連するタスク定義をグループ化するために使用するフォルダです。

3. 「OK」をクリックします。

注意: このページの情報は、「計画の作成: 確認」ページで「保存して終了」をクリックするまでは、保存されません。

49.3 変更アクティビティ計画での操作

計画では次の操作を実行できます。

- 他の計画と類似の計画の作成

- 計画の編集

- 計画の削除

- 計画の非アクティブ化

- 計画のエクスポート

- 計画の印刷

- 計画の所有者の変更

49.3.1 他の計画と類似の計画の作成

要件を満たす計画がある場合は、他の計画と類似する計画を作成できます。こにより、時間とコストを節約できます。

1. 「変更アクティビティ計画」ページで、類似作成する計画をハイライト表示します。「類似作成」をクリックします。ダイアログ・ボックスで、新しい計画の名前を入力します。「OK」をクリックします。
これにより、計画の作成ウィザードがアクティブ化します。「変更アクティビティ計画の作成」の手順に従います。次の手順で、他の計画と類似した計画を作成する場合に影響を及ぼす変更について確認します。

2. 「計画の作成: プロパティ」ページでは、計画の名前を変更できます。ターゲット・タイプを変更することもできますが、そうすると、すべてのタスク定義が削除されます。
「次へ」をクリックします。

3. 「計画の作成: タスク」ページでは、タスク定義およびタスク・グループを追加、編集および削除できます。計画内のタスク定義およびタスク・グループを移動することもできます。
タスク定義およびタスク・グループの移動またはコピーを行う場合、依存性(設定されている場合)は維持されます。すべてのタスク名は一意にすることを強くお薦めします。これにより、計画をアクティブ化した後のタスク管理が容易になります。コピー操作中に、索引が更新された新しい名前を指定し、一意のネーミングを伝播します。名前は、編集によって変更できます。

「次へ」をクリックします。

4. 「計画の作成: ターゲット」ページでは、タスク定義に関連付けられているターゲットを追加および編集できます。表示されるダイアログ・ボックスで、タスク定義に関連付けられているターゲットを選択します。各タスク定義には、少なくとも1つのターゲットを関連付ける必要があります。変更を加えたら、「OK」をクリックします。「次へ」をクリックします。

5. 「計画の作成: アクティブ化」ページでは、スケジュールをアクティブ化できます。
注意: 「アクティブ化」ページは、計画のアクティブ化の準備ができるまでブランクのままにできます。

「次へ」をクリックします。

6. 「確認」ページで、入力したすべての情報が目的どおりに入力されていることを確認します。更新が必要な場合は、「戻る」ボタンをクリックして、必要な変更を加えます。
計画をアクティブ化する準備ができていない場合に、「保存して終了」オプションも用意されています。

計画をアクティブ化する準備ができたら、「アクティブ化」をクリックします。「変更アクティビティ計画」ページで「リフレッシュ」をクリックして、計画がアクティブ化されていることを確認します。管理できるのは、アクティブ化された後の計画のみです。

49.3.2 計画の編集

アクティビティ計画の所有者を除き、アクティビティ計画で実行可能な変更のタイプは、アクティビティ計画のステータスに依存します。

- アクティブ化を保留中 - 計画が将来開始されるようにスケジュールされていることを示します。この計画は、計画がアクティブになる開始日まで変更できます。
まだアクティブ化されていないアクティビティ計画では、「編集」ボタンが有効になっています。「編集」ボタンをクリックすると、計画の作成ウィザードと基本的に同じウィザードが表示されます。すべての編集が可能です。「変更アクティビティ計画の作成」の手順に従います。

- アクティブ - アクティビティ計画がアクティブ化されると、編集は計画の管理ページからのみ可能です。このページからは、アクティビティ計画のスケジュール終了日の更新、タスクのステータスに応じたタスクの割当て、タスクの開始日およびスケジュール終了日の更新、およびタスクの取消しが可能です。

- 完了、非アクティブ化済 - 編集はできません。

- 進行中の定義 - 編集は許可されています

計画を編集するには、「変更アクティビティ計画」ページで、「変更アクティビティ計画」表にある計画をハイライト表示します。「編集」をクリックします。これにより、計画の作成ウィザードがアクティブ化します。

計画の所有者の変更方法の詳細は、「計画の所有者の変更」を参照してください。

49.3.3 計画の削除

計画が不要になった場合は削除します。

計画を削除する手順は、次のとおりです。

1. 「変更アクティビティ計画」ページで、「変更アクティビティ計画」表にある計画をハイライト表示します。

2. 「削除」をクリックします。

3. 表示される「確認」ダイアログ・ボックスで、「はい」をクリックします。

49.3.4 計画の非アクティブ化

計画を元のタスクまたはプロジェクトに関連付ける必要がなくなったときは、計画を非アクティブ化します。ただし、将来参照したり監査したりする場合に役に立つ場合があります。また、この計画の構造が、将来のプロジェクトに役に立つかどうかも考慮してください。

計画を非アクティブ化すると、計画のタスクが取り消され、計画の進行状況が監視されなくなります。ただし、表示が目的の場合、計画は引き続き「変更アクティビティ計画」ページから表示できます。

計画を表示する必要がなくなった場合は、計画を非アクティブ化するかわりに削除することを検討してください。

注意: 計画を非アクティブ化すると、再アクティブ化できなくなります。

1. 「変更アクティビティ計画」ページで、「変更アクティビティ計画」表にある計画をハイライト表示します。

2. 「アクション」メニューから、「非アクティブ化」を選択します。

3. 表示される「確認」ダイアログ・ボックスで、「はい、計画を非アクティブ化します」をクリックします。

49.3.5 計画のエクスポート

計画をエクスポートすると、変更アクティビティ計画のステータスが外部ドキュメントに取得されます。

アクティビティ計画をエクスポートするには、次の手順に従います:

1. 「変更アクティビティ計画」ページの「アクション」メニューから、「エクスポート」を選択します。

2. ファイルを保存するか、スプレッドシートとして開きます。

エクスポート機能では、個々の計画ではなく、すべての計画のリストがエクスポートされます。

注意: 表示されるスプレッドシートは読取り専用形式です。

49.3.6 計画の印刷

レポート作成はプロジェクト追跡および監査の重要な部分であるため、経営者に情報を提供するために計画を印刷します。

計画を印刷するには、次の手順を実行します。

1. 「変更アクティビティ計画」ページの「アクション」メニューから、「印刷」を選択します。

2. 印刷では、別のタブに印刷可能なページが作成されます。タブと印刷の内容を選択します。内容は個々の計画ではなく、すべての計画のリストです。

49.3.7 計画の所有者の変更

アクティビティ計画の所有者は、アクティビティ計画のステータスに関係なく更新できます。アクティビティ計画の所有者を変更する手順:

1. 「変更アクティビティ計画」ページにある「変更アクティビティ計画」表で、所有者を変更する計画をハイライト表示します。

2. 「アクション」メニューから、「所有者の変更」を選択します。

3. 表示される表で、新しい所有者の名前を選択します。「選択」をクリックします。

注意: 計画の所有者またはスーパー管理者が所有者を変更できます。

ターゲット所有者に基づいてタスクの所有者を変更できます。タスクにターゲットがあり、そのターゲットに所有者が定義されている場合は、タスク所有者をターゲット所有者に設定できます。

グループ所有者へのタスクの割当て

プロジェクトの関係上、マネージャにタスクを割り当てることが必要になる場合があります。これにより、マネージャは、チームのワークロードや可用性を評価し、それに応じてタスクを割り当てることができるようになります。

グループ所有者にタスクを割り当てるには、最初にターゲット・プロパティを作成する必要があります。次のステップでは、ターゲット・プロパティの作成方法について説明します。

1. emcliプロパティを作成するには、次の手順を実行します。

emcli login -username=sysman
emcli add_target_property -property=CAP_assignments  -target_type="*"

where CAP_assignments represents any property (NOTE: The property MUST begin with CAP_)
and * represents all targets in the Enterprise Manager Repository

2. 「ターゲット」メニューから「ホスト」を選択します。表から、該当するホストをクリックします。左上隅にある「ホスト」メニューから、表示された「ホスト」ホームページで「ターゲット設定」を選択してから、「プロパティ」を選択します。ターゲットのターゲット・プロパティ値を入力します。

CAPのUIでこのターゲット・プロパティを使用して、タスクを再割当てできます。たとえば、「計画の管理」ページにある「タスク」タブで、「所有者の変更」をクリックしてから「ターゲット・プロパティによるタスクの割当て」を選択します。

49.4 変更アクティビティ計画の管理

計画を作成すると、その計画を管理する必要があります。「変更アクティビティ計画」ページに、計画表が計画のステータスおよび進行状況とともに表示されます。計画がアクティブ化されたら、計画を管理する必要が生じます。

変更アクティビティ・プランナの管理機能を使用して、次の操作を行うことができます。

- アクティブ化されたすべての計画の表示、およびアクティブ化された計画の取消し。

- 計画のドリルダウンと詳細の取得、および個々のタスクの管理。これにより、アクティビティ計画の完了期限が遅れる可能性のある問題を特定できます。

- 計画の変更者および変更内容に関する監査証跡の表示。

- リンクの表示および更新。作成時に計画に関連付けられたリンクを計画の管理時に表示できます。計画の所有者および特権ユーザーは既存のリンクを更新できます。

- 別の計画所有者への計画の再割当て、および別のタスク所有者へのタスクの再割当て。

- 計画でスケジュールされている終了日の変更。

- タスクの管理

- タスクのステータスを確認、進行中または取消しするために手動で更新します。

- 手動タスクに対してステータスを完了に更新します。

- 計画の変更者および変更内容に関する監査証跡を管理します。

- 依存タスクを表示します。

計画を管理するには、「変更アクティビティ計画」ページで、アクティブ化されている計画をハイライト表示し、「管理」をクリックするか、または計画名をクリックします。

計画の管理ページには、計画を管理するために次の機能が用意されています:

- 「サマリー」タブ
タスクのステータスや計画サマリーなど、計画のステータスの全体のサマリーを表示します。

- 「タスク」タブ
計画のタスクのすべてについて管理できます。タスクは個別またはまとめて更新できます。

- 「コメントおよび監査証跡」タブ
監査証跡を表示して、計画の変更者およびタスクの変更内容を確認できます。

49.4.1 「サマリー」タブ

「サマリー」タブでは、計画のステータスの全体のサマリーを表示します。次の情報を指定します。

- 概要 - 計画の達成の進行状況が表示されます。計画の詳細には、ステータス、スケジュール済終了日、優先度、所有者およびリンクなどがあります。
推定終了日は、計画を構成するすべてのタスクの最大のスケジュール済終了日です。

- 計画サマリー - 計画を構成するタスク定義およびタスク・グループのビジュアル表現。依存性は計画のオブジェクト間の矢印で示され、タスクが実行される順序を表します。
計画サマリーをグラフまたは表形式で表示できます。トポロジ・グラフ(および代替の表ビュー)には、計画を構成するすべてのタスク定義およびタスク・グループと、タスクを実行する順序が表示されます。

タスク定義およびタスク・グループにはすべて、アイコンで示される、関連するステータスがあります。このステータスは、タスク定義またはタスク・グループを構成するタスクのステータスで判定されます。

例: タスク定義に4つの関連タスクが含まれていて、タスク1が「未確認」、タスク2が「完了」、タスク3が「進行中」、タスク4が「取消済」の場合、タスク定義のステータスは「進行中」です。

表ビュー

「表ビュー」では、各タスク定義/タスク・グループに数が関連付けられます。リンクをクリックすると、検索フィルタが自動的に追加される「タスク」タブが表示され、クリックしたリンクに基づいて、該当のタスク定義/タスク・グループの詳細を確認できます。たとえば、「期限超過」リンクをクリックすると、タスク・タブが表示されます(タスク・タブでは、タスク名が設定され、注意を促す「期限超過」フラグがチェックされています)。表で確認したタスク定義で未処理のすべての期限超過タスクが表示されます。

「計画サマリー」の「表ビュー」からは、計画を印刷またはエクスポートできます。

グラフ・ビュー

グラフ形式を使用する場合、上から下または左から右のいずれかのグラフ形式を選択できます。「スケジュール開始日」、「スケジュール終了日」または「タスクの合計」の注釈をグラフに表示することもできます。

グラフ・ビューでは、依存関係のあるタスク定義の間に矢印が描画されます。矢印の向きは、最初に完了する必要のあるタスク定義から、完了を待機する必要のあるタスク定義になります。

タスク・グループは、他のタスク定義を囲むボックスとして描画されます。

タスク定義名と表示されている矢印の上にカーソルを置くと、このタスク定義の結果として作成されたタスクに関する情報が表示されます。

グラフの空白領域を右クリックするとメニューが表示され、グラフの向きの変更またはグラフの内容の印刷を行うことができます。

「表示」オプションを使用すると、グラフ・ビューと表ビューを切り替えることができます。

- 計画がまだ完了していない場合は、「概要」セクションの「スケジュール終了日」の横にあるカレンダー・アイコンをクリックすると、スケジュール終了日を変更できます。

- タスクの完了の進行状況は、「概要」セクションの「進行状況(%)」の横にある折れ線グラフ・アイコンをクリックすると表示できます。

49.4.2 「タスク」タブ

「タスク」タブを使用して、計画のすべてのタスクを管理します。タスクは個別またはまとめて更新できます。

- タスクのステータス
円グラフによる、タスク・ステータス別の計画のブレークダウン。

- ビュー
このセクションには、対応が必要なタスクを素早く見つけることができるクイック・リンクが表示されます。サポートされるビューは、未割当てのタスク、未確認のタスク、期限切れのタスク、1週間以内に期限が切れるタスクおよび「すべてアクティブ」です。

「すべてアクティブ」には、すべてのオープン・タスクが表示されます。完了したタスクおよび取り消されたタスクを含む、すべての計画のタスクを表示する、「すべて表示」リンクもあります。

- タスク
このセクションはタスク表を表示し、計画タスクを検索、表示および更新できます。「アクション」メニューと表のボタンは、日付の設定、タスク所有者の変更、タスクの確認と取消しなどの操作について一括のタスク更新をサポートしています。デフォルトでは、オープン・タスクのみを表示するようにタスクがフィルタ処理されています。

タスクを1つ選択して、タスクの詳細を表示および更新します。あるいは、複数のタスクを選択し、表の上部にある、表の「アクション」メニュー内の一括操作のボタンを使用します。

計画タスク・ビューは、クローズしたタスクを自動的にフィルタ処理しますが、検索セクションを展開したり、ビュー・リンクを使用したりすることで、検索フィルタを設定できます。

単一のタスク

単一のタスクを選択すると、「一般」タブを使用して、ターゲット名などのタスク情報を表示および編集できます。タスクのコメントを追加したり、「コメントおよび監査証跡」タブを使用して、計画の変更者および変更内容を確認したりできます。この情報は確認中のタスクに固有です。これにより、手動で追加したコメントを含む、そのタスクに加えたすべての変更が追跡されます。

複数のタスク(一括操作)

複数のタスクが選択されている場合は、次の手順を実行します。

- タスクを確認します。タスクを確認するということは、タスクは表示されたが、そのタスクの作業が開始されていないということです。タスクに「確認済」を設定できるユーザーは、タスクの所有者、計画の所有者およびスーパー管理者のみです。タスクを割り当てられているユーザーの場合、タスクが含まれる計画を表示できます。

- タスクを取り消します。

- スケジュール開始日および終了日を設定します。

- 所有者を変更します。

- ジョブを発行します。ジョブを発行できるのは、タスクが同じタスク定義に含まれる場合のみです。

- パッチ計画を作成します。パッチ計画は、パッチ計画ベースのタスクが選択されている場合に作成できます。タスクが、同じタスク定義に含まれている必要があります。パッチ計画をデプロイするには、パッチと更新版ページを使用します。

- 既存のパッチ計画に関連付けます。タスク定義のパッチ・テンプレートのパッチがタスクのターゲットに適用されている場合、パッチ計画がタスクに関連付けられているかどうかに関係なく、タスクは自動的に閉じます。

- 既存のプロシージャ実行に関連付けます。このオプションは、同じタスク定義のタスクに対して有効化されます。アソシエーションを作成したら、デプロイメント・ライブラリ・ページを使用して、デプロイメント・プロシージャを起動します。

タスク表は、タスク・リストのエクスポートおよび出力もサポートしています。これらの操作には「アクション」メニューを使用します。

対応が必要

表内の「対応が必要」アイコンをクリックすると、「一般」タブと「コメントおよび監査証跡」タブが表示されます。使用可能な情報を調べて、次に必要な作業を判定します。たとえば、計画が期限切れになっている場合、遅延の原因になっているタスクを判定します。

特定のタスクの監査証跡を調べることができます(例: 日付、依存性が存在するかどうか、およびタスク変更の所有者またはステータス)。

所有者の変更

特に便利なことは、所有者を変更できることです。これは、ジョブの責任およびユーザーのロールが変更される場合に特に便利です。「所有者の変更」には、ユーザーのリストが表示されます。新規ユーザーを選択します。

49.4.3 「コメントおよび監査証跡」タブ

監査証跡を表示して、計画の変更者およびタスクの変更内容を確認します。

49.5 マイ・タスクの表示

マイ・タスク・ページを使用すると、ユーザーに割り当てられたタスクを管理できます。マイ・タスクでは、タスクの概要を示し、これによってタスクを検索、表示および更新できます。

ページにアクセスする方法:

1. 「エンタープライズ」メニューから「構成」を選択し、「マイ・タスク」を選択します。

2. 次の操作を実行するタスクをハイライト表示します。

- タスクの所有者の変更。

- タスクの取消し。

- タスクのスケジュール開始日および終了日の設定。

注意: 表内の1つ以上のタスクを選択して、所有者の確認および変更などの操作にまとめてアクセスできます。

デフォルトでは、オープン・タスクのみを表示するようにタスクがフィルタ処理されています。

次のセクションがマイ・タスク・ページに表示されます:

- タスクのステータス - 円グラフによる、ステータス別のユーザーのタスクのサマリー。

- 「拡張」検索オプション。

- ビュー - 対応が必要なタスクを素早く見つけることができるクイック・リンクが表示されます。サポートされるビューは、期限切れのタスク、1週間以内に期限が切れるタスク、未確認のタスクおよび「すべてアクティブ」です。
「すべてアクティブ」には、すべてのオープン・タスクが表示されます。「すべて表示」リンクには、完了したタスクおよび取り消されたタスクを含む、すべてのタスクが表示されます。

- タスク - タスク表を表示し、タスクを検索、表示および更新できます。「アクション」メニューと表のボタンは、日付の設定、タスク所有者の変更、タスクの確認と取消しなどの操作について一括のタスク更新をサポートしています。
単一のタスクの選択

単一のタスクを選択すると、タスクの詳細を表示および編集できます。また、タスクにコメントを追加したり、タスクのコメントおよび監査証跡を確認したりすることもできます。

単一のタスクを選択した際に、タスクに関連付けられたデータが次のタブに表示されます:

- 一般: タスクの詳細とトラッキング情報を表示します

- タスクの詳細: 計画、ターゲットおよびタスク・アクションなどの基本的なタスク情報を表示します。このセクションでは、タスクのスケジュール済開始日とスケジュール済終了日を更新できます。
タスクの詳細セクションから、ジョブの発行、パッチ計画の作成、タスクとパッチ計画の関連付け、ジョブとジョブ実行の関連付け、ジョブとデプロイメント・プロシージャ実行の関連付けが可能です。

複数タスクの選択

タスク表でタスクを複数選択する場合は、表のボタン(および「アクション」メニュー)を使用して、タスク全体でアクションを実行できます。たとえば、複数のタスクで一度に確認、所有者の変更、取消、スケジュール開始日の設定およびスケジュール終了日の設定を実行できます。また、ジョブの発行、既存のジョブ実行との関連付け、パッチ計画の作成、既存のパッチ計画との関連付け、既存のデプロイメント・プロシージャ実行との関連付けが可能です。

- 所有者の一括変更機能では、所有者の設定の次の方法がサポートされています。

- ユーザーへのタスクの割当て(Enterprise Managerユーザー・セレクタの使用を選択)。

- ターゲット所有者へのタスクの割当て: (ターゲットを持つタスクのみに適用されます。割当てが実行されるターゲットにターゲット所有者を設定する必要があります)。注意: 変更アクティビティ・プランナ・ターゲット・プロパティを環境に追加すると、このラベルをターゲット・プロパティでタスクを割り当てるに変更できます。詳細は、Oracle Enterprise Manager Lifecycle Management管理者ガイドの「変更アクティビティ・プランナの概要」の章を参照してください。

- タスクを未割当てに設定する(タスクから所有者を削除)。

- ジョブベース・タスクについては、タスクに同じ定義が含まれている場合、複数のタスクを選択し、1つのジョブを発行してタスクを完了できます。
選択したタスクのタスク定義がすべて同じジョブを参照していない場合は、「ジョブの発行」オプションが無効になります。

- デプロイメント・プロシージャ・ベースのタスクの場合は、すべてのタスクのタスク定義を同じにする必要があります。選択したタスクのタスク定義がすべて同じデプロイメント・プロシージャを参照していない場合は、「既存のデプロイメント・プロシージャ実行との関連付け」オプションが表示されます。

- パッチ・テンプレート・ベースのタスクの場合、タスクの作成者は、タスク定義をパッチ・テンプレートと関連付けます。タスク所有者は、タスクと既存のパッチ計画を関連付けるか、新しいパッチ計画を作成できます。パッチ・テンプレートは、選択したすべてのタスクで同じである必要があります。

- トラッキング: 現在の所有者とタスク・ステータスを表示できます。タスクが別のタスクに依存している場合、依存性が表示されます。タスクがこの依存性のために待機している場合、待機アイコンが表示されます。このタスクに対応が必要な場合、問題の詳細がこのセクションに表示されます。

- コメントおよび監査証跡: すべてのコメントおよび監査証跡の注釈を表示します。

注意:
ジョブおよびデプロイメント・プロシージャを含むタスクで、割り当てられたタスクが「タスク」領域にない場合は、ジョブおよびデプロイメント・プロシージャの参照に必要な権限があることを確認します。適切なアクセス権を持っていない場合は、ジョブまたはデプロイメント・プロシージャを作成した個人に連絡してください。

49.6 変更アクティビティ・プランナの使用例

この項では、変更アクティビティ・プランナのユースケースについて説明します。

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

- アクティビティ計画の自動化

- アクティビティ計画の自動化の追加手順

- 変更アクティビティ・プランナを使用したパッチ適用の例

49.6.1 アクティビティ計画の自動化

たとえば、システム・マネージャまたはDBAが、3か月以内にすべての本番データベースにクリティカル・セキュリティ・パッチを適用し、その状況を追跡するとします。

システム・マネージャまたはDBAは次の手順を実行します。

1. 新しい計画を作成し、アクティビティ計画の優先度、アクティビティ計画の説明、およびアクティビティ計画が適用されるターゲット・タイプを指定します。
新しいアクティビティ計画は、選択したターゲット・タイプに関連付けられます。

2. 新しいタスク定義またはタスク・グループをこの計画に作成します。このプロセスは、すべてのタスク定義およびタスク・グループの入力を終了するまで反復します。
タスク定義は、コンプライアンス標準ルールの評価に基づいて自動的に完了するか、またはタスク所有者がステータスを手動で更新するかのいずれかに設定できます。

コンプライアンス標準ルールの詳細は、第45章「コンプライアンスの管理」を参照してください。

3. (オプションの手順)。少なくとも1つのターゲットを、タスクを実行する必要のあるタスクに割り当てます。
指定したターゲット・タイプを持つタスク定義には、指定したタイプのターゲットを少なくとも1つ割り当てる必要があります。複数のターゲットが1つのタスク定義に割り当てられている場合、別々のタスクが各ターゲットについて作成されます。注意: ターゲット・タイプが「なし」のタスク定義には、ターゲットの選択は不要です。

注意: ジョブおよびデプロイメント・プロシージャを含むタスクで、割り当てられたタスクに関連付けられたジョブまたはデプロイメント・プロシージャがタスクの詳細領域にない場合は、ジョブおよびデプロイメント・プロシージャの参照に必要な権限があることを確認します。アクセス権を持っていない場合は、ジョブまたはデプロイメント・プロシージャを作成した個人に連絡してください。別のユーザーによって発行されている場合は、特定のジョブまたはプロシージャ実行を参照する権限をリクエストする必要が生じる場合があります。

4. Enterprise Managerがこれらの新しいタスクに所有者を自動的に割り当てるか、または計画のアクティブ化の決定後に所有者をタスクに手動で割り当てるかを決定します。

5. アクティビティ計画をすぐにアクティブ化するか、後の時点でアクティブ化します。
アクティビティ計画はすぐにアクティブ化されるか、マネージャによって指定された時刻にアクティブ化されるようにスケジュールされます。アクティビティ計画がアクティブ化されると、タスクが作成され、タスク所有者に割り当てられます。タスクは、ターゲット所有者に自動的に割り当てられるか、またはユーザーが割り当てた所有者に割り当てられます。

タスク所有者がタスク・ステータスを更新するようにタスクが定義された場合、タスク所有者はステータスを完了済として手動でマークする必要があります。タスク・ステータスがコンプライアンス標準ルールに基づいて更新された場合は、タスクのターゲットがルールに準拠している場合、タスクは完了済として自動的にマークされます。

タスク・グループは、すべてのサブ・タスクが完了すると完了とマークされます。

49.6.2 アクティビティ計画の自動化の追加手順

アクティビティ計画を自動化する場合に実行可能な追加手順は、次のとおりです。

- URLリンクをアクティビティ計画またはタスクに指定します

- アクティビティ計画のトポロジ上のグラフィカル・ビューを取得します。

- コンプライアンス標準ルールを使用して、タスクを自動的にクローズします。選択したターゲットについてルール・チェックが合格した場合、自動的にタスクがクローズされます。

- タスクを手動でクローズします。

- ターゲットをタスク・グループに割り当てると、タスク・グループ内のすべてのタスクが割り当てられます。タスク・グループ・レベルまたは個々のタスク・レベルでターゲットを割り当てることができます。したがって、すべてのタスクがデータベース1で実行される場合、タスク・グループ・フォルダを選択してデータベース1のターゲット・タイプを割り当てると、グループ内のすべてのタスクはデータベース1を割り当てられます。引き続きグループ内でタスクを1つ選択して、必要に応じて他のデータベース・ターゲットに割り当てることができます。

- タスク・グループを自動的にクローズします。すべてのサブタスクが完了すると、タスク・グループが自動的にクローズされます。

- タスク定義のフェーズ中に、削除、移動およびコピー機能を使用して、タスクを再調整します。適切な依存性とフローを実現するように、タスク定義とタスク・グループを計画の階層に再配置できます。

- タスク作成フェーズ中に、2つのタスク間の依存性を作成します(たとえば、タスクBがタスクAに依存している場合、タスクBはタスクAが完了するまで開始できません)。ユーザーが同じレベルの依存性(兄弟間のみの依存性)を作成できるようにします。

49.6.3 変更アクティビティ・プランナを使用したパッチ適用の例

パッチ適用タスクを作成するには、パッチ・テンプレートを選択して、ターゲットをパッチ適用タスクに関連付けます。ターゲット所有者にタスクを割り当てたら、ターゲット所有者はパッチ計画ツールを使用して、パッチ・テンプレート内にあるパッチを適用できるようになります。

ターゲットへのパッチ適用の詳細は、第42章「ソフトウェアのデプロイのパッチ適用」を参照してください。

第XI部

デプロイメント・プロシージャ

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

- 第50章「デプロイメント・プロシージャについて」

- 第51章「デプロイメント・プロシージャのカスタマイズ」

50 デプロイメント・プロシージャについて

この章では、デプロイメント・プロシージャの概要を示し、理解する必要がある重要な点について説明します。この章の具体的な内容は次のとおりです。

- 「プロビジョニング」ページの概要

- ロールと権限の管理者への付与

- プロシージャのコンポーネント

- プロシージャの作成

- デプロイメント・プロシージャの管理

- ユーザー定義デプロイメント・プロシージャ(UDDP)の作成、保存および起動

- プロシージャ・インスタンスの実行ページ

50.1 「プロビジョニング」ページの概要

Enterprise Managerには、複数のOracleホーム上で実行可能なタスクを自動化、編成および追跡するためのフレームワークが備わっています。プロビジョニング、パッチ適用、アップグレードなどの複雑なソフトウェア・ライフ・サイクル管理アクティビティは、Cloud Controlコンソールから実行できます。特定のライフ・サイクル管理アクティビティで実行する必要のあるすべてのタスクのワークフローが、プロシージャ内にカプセル化されます。プロシージャとは、階層構造になった一連のプロビジョニング・ステップであり、各ステップには一連の他のステップが含まれることもあります。プロシージャにより、特定のアプリケーションおよびプロシージャを構築できるフレームワークが提供されます。

Oracle Enterprise Manager Cloud Control (Cloud Control)には、プロビジョニングやパッチに関連する一般的なタスクを実行するための一連のデフォルト・プロシージャが含まれています。各プロシージャは固有の機能を備え、プロビジョニングするソースやパッチを適用するターゲットに応じて特定の操作を実行するように設計されています。たとえば、単一インスタンスのデータベースにパッチを適用するプロシージャは、Oracle RAC環境またはアプリケーション・サーバーにパッチを適用するものとは異なります。

プロビジョニング・ページには「プロシージャ・ライブラリ」、「プロシージャ・アクティビティ」、「ごみ箱」の3つのタブがあります。

- 「プロシージャ・ライブラリ」タブ: このタブを使用して、使用可能なプロシージャをすべて表示します。プロシージャを実行、新しいプロシージャを作成、またはOracle社が提供するプロシージャからプロシージャ作成する際には、デプロイメント・プロシージャが作成されます。デプロイメント・プロシージャは一連のプロビジョニング・ステップおよびフェーズであり、各フェーズに一連のステップが含まれることがあります。
オラクル社により、「作成者」フィールドの下にOracleのマークが付いたベスト・プラクティスのデプロイメント・プロシージャが提供されています。これらのプロシージャは編集も削除もできません。

「プロシージャ・ライブラリ」ページから実行できるタスクの詳細は、第50.5項を参照してください。

- 「プロシージャ・アクティビティ」タブ: このタブを使用して、実行用に発行されたすべてのプロシージャ実行と、すべての実行中のプロシージャのリストを表示します。また、プロシージャ実行のステータスを表示することもできます。この他に、発行されたプロシージャで複数のアクション(停止、一時停止、再開、再試行、削除、再スケジュールなど)を実行できます。プロシージャで実行する該当のアクションを確認するには、そのプロシージャを選択します。たとえば、失敗したプロシージャを停止または再試行できます。Enterprise Manager 12.1.01.3以降では、「再スケジュール」と呼ばれる新しいオプションが導入されており、このオプションは、進行中で繰り返しスケジュールが設定されているジョブに対して有効になります。
プロシージャが実行されると、そのプロシージャのインスタンスが作成されます。このインスタンスにより、現在実行されているステップが追跡され、ユーザーが収集したデータや、アクション・ステップの実行によって自動的に収集されたデータはすべて格納されます。

「プロシージャ・アクティビティ」タブの概要は、第50.7.2項を参照してください。

- 「ごみ箱」タブ: プロシージャおよび実行を削除できます。プロシージャまたは実行を削除すると、それらには削除済のマークが付けられ、「ごみ箱」タブに表示されます。

図50-1に、Cloud Controlから「プロビジョニング」画面にアクセスする方法を示します。

図50-1 「プロビジョニング」ページへのアクセス

50.2 ロールと権限の管理者への付与

管理者とは、Enterprise Managerにログインして管理タスクを実行できる、Enterprise Managerのユーザーです。Enterprise Managerで実行できる管理タスクの範囲は、管理者に割り当てられた権限とロールによって異なります。ロールによってEnterprise Managerセキュア・リソース権限をグループ分けすることができます。ロールは管理者または他のロールに付与することができます。管理者は、割り当てられたロールと権限に応じてデザイナとオペレータに二分されます。通常、ロールと権限は、デプロイメント・プロシージャ・レベルおよびソフトウェア・ライブラリ・レベルでユーザーまたは他のロールに付与されます。

ここでは、Oracleで提供される事前定義済のロールおよび権限を管理者に付与する方法について説明します。

- デプロイメント・プロシージャに関するロールと権限の管理者への付与

- ソフトウェア・ライブラリに関するロールと権限の管理者への付与

50.2.1 デプロイメント・プロシージャに関するロールと権限の管理者への付与

通常のデータ・センターでは、デプロイメント・プロシージャの主なユーザーはデザイナ(主任管理者)およびオペレータです。デプロイメント・プロシージャの権限を使用して、ユーザーは、設計時アクティビティ(権限委任の設定やデプロイメント・プロシージャのカスタマイズなど)や実行時アクティビティ(ソフトウェア・アプリケーションのプロビジョニングまたはパッチ適用を行うデプロイメント・プロシージャの実行など)を実行できます。

次に、デプロイメント・プロシージャのためにOracleで事前定義されている主なユーザーとロール、およびそれらの権限を示します。

- スーパー管理者ロールでは、すべての管理操作を実行できます。すべてのターゲットに対する完全な権限が含まれます。

- EM_ALL_DESIGNER (デザイナ): このロールでは、エンティティに対する設計時の操作を実行できます。たとえば、デプロイメント・プロシージャ・テンプレートの作成や監視です。
次の表に、デザイナのために事前定義されているすべてのロールとその説明を示します。

表50-1 デザイナの事前定義済ロール

ロール

説明

EM_PATCH_DESIGNER

ロールは、パッチ計画を作成および表示するための権限を持ちます。

EM_PROVISIONING_DESIGNER

ロールは、プロビジョニング・デザイナ用の権限を持ちます。

EM_TC_DESIGNER

ロールは、テンプレート・コレクションを作成するための権限を持ちます。

ユーザーには次のいずれかのターゲット権限を付与できます。

- 「権限伝播グループの作成」。権限伝播グループに付与される権限は、そのグループのメンバーにも自動的に付与されます。

- 「Enterprise Managerでターゲットを追加します。」。

ユーザーには次のリソース権限をどれでも付与できます。

- 「コンプライアンス・エンティティの作成」。

- 「エンタープライズ・ルール・セットの作成」。エンタープライズ・ルール・セットは、基本的にはEnterprise Managerの要素(ターゲットやジョブなど)に適用するルールのコレクションです。

- 「メトリック拡張の作成」。メトリック拡張を使用すると、新しいメトリックを追加してターゲット・タイプの監視を拡張できます。

- 「名前付き資格証明の新規作成」。これは、Enterprise Manager管理操作を実行するために必要です。

- 「任意のソフトウェア・ライブラリ・エンティティの作成」、「任意のソフトウェア・ライブラリ・エンティティのインポート」、「任意のソフトウェア・ライブラリ・エンティティのエクスポート」など。

- 「テンプレート・コレクションの作成」。

注意:
EM_PATCH_DESIGNERの詳細は表42-3を、EM_PROVISIONING_DESIGNERの詳細は表4-3を参照してください。

- EM_ALL_OPERATOR (オペレータ): このロールのアクセス権は制限されています。実行時アクティビティしか実行できません。たとえば、デプロイメント・プロシージャの起動です。
次の表に、オペレータのために事前定義されているすべてのロールとその説明を示します。

表50-2 オペレータの事前定義済ロール

ロール

説明

EM_ALL_VIEWER

ロールの説明

EM_HOST_DISCOVERY_OPERATOR

ロールは、ホストの検出を行うための権限を持ちます

EM_PATCH_OPERATOR

パッチ計画をデプロイするためのロール

EM_PROVISIONING_OPERATOR

ロールは、プロビジョニング・オペレータ用の権限を持ちます。

EM_TARGET_DISCOVERY_OPERATOR

ロールは、ターゲットの検出を行うための権限を持ちます。

EM_USER

ロールの説明

ユーザーには次のいずれかのターゲット権限を付与できます。

- 「表示可能な任意のターゲットを接続、管理する機能」。

- 「Enterprise Managerでターゲットを追加します。」。

- 「すべての管理対象ターゲットに対する管理操作を実行する機能」

- 任意の管理エージェントでの任意のオペレーティング・システム・コマンドの実行

ユーザーには次のリソース権限をどれでも付与できます。

- 「アプリケーション・リプレイ・オペレータ」。アプリケーション・リプレイ・エンティティには、キャプチャ、リプレイ・タスクおよびリプレイが含まれます。

- ユーザーが所有するカスタム構成の管理

- 「名前付き資格証明の新規作成」。これは、Enterprise Manager管理操作を実行するために必要です。

注意:
EM_PATCH_OPERATORの詳細は表42-3を、EM_PROVISIONING_OPERATORの詳細は表4-3を参照してください。

50.2.2 ソフトウェア・ライブラリに関するロールと権限の管理者への付与

ソフトウェア・ライブラリは、すべてのEnterprise Managerエンティティが集中管理されるメディア・ストレージです。Enterprise Managerのインストールが完了すると、スーパー管理者がソフトウェア・ライブラリを構成します。ソフトウェア・ライブラリは、「記憶域の場所」で構成した後で、エンティティの格納に使用できるようになります。デザイナとオペレータがソフトウェア・ライブラリの主なユーザーであり、それぞれ設計時と実行時のアクティビティを実行します。設計時のアクティビティには、エンティティのカスタマイズ、エンティティの作成、エンティティのインポート、エンティティのエクスポートなどがあります。オペレータが実行する実行時のアクティビティには、デプロイメント・プロシージャの実行が含まれます。この際に、ソフトウェア・ライブラリに格納されている任意のエンティティが使用されます。

ソフトウェア・ライブラリのユーザー、ロールおよび関連する権限の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

注意:
Windowsホストで、「ソフトウェア・ライブラリ」のエンティティの実行を伴うプロシージャ(ディレクティブ・スクリプトなど)を実行するには、Windowsユーザーに次の権限を付与する必要があります。

- オペレーティング システムの一部として機能

- プロセスのメモリ クォータの増加

- バッチ・ジョブとしてログオンする権限

- プロセス レベル トークンの置き換え

これを行わない場合、プロシージャでディレクティブ・ステップの実行に失敗する可能性があります。

50.3 プロシージャのコンポーネント

この項では、次の項目について説明します。

- ターゲット・リスト

- プロシージャ変数

- フェーズおよびステップ

50.3.1 ターゲット・リスト

ターゲット・リストは、ジョブを実行できるターゲットを事前に移入したリストです。フェーズは、Enterprise Managerターゲットのセット(まとめてターゲット・リストと呼ばれる)上で動作します。各フェーズにはターゲット・リストを関連付ける必要があります。デプロイメント・プロシージャの実行を選択すると、デプロイメント・プロシージャ・マネージャによって、ターゲットをターゲット・リストに割り当てるように要求されます。

Enterprise Manager 12c (12.1.0.2)から、カスタムのターゲット・リストが導入されています。デフォルトのターゲット・リストに加えて、独自にカスタマイズしたターゲット・リストを指定し、それに対して指定したフェーズを実行できます。このアプローチには、複数のカスタム・ターゲット・リストを使用し、プロシージャでフェーズごとに割り当てることができるという利点があります。そのため、フェーズを反復実行するターゲット・リストを選択できます。

次の例では、プロシージャでターゲットを1つ、2つ、3つ利用するシナリオについて説明します。

- 複数のホストにjarファイルをコピーする場合、必要なターゲット・リストは1つのみです。この目的には、デフォルトのターゲット・リストを選択できます。

- Oracleホームをクローニングして複数のターゲットにプロビジョニングする場合、少なくとも2つのターゲット・リストが必要になります。1つ目は1つのターゲットのみを含むソースのターゲット・リスト、2つ目はすべての宛先ターゲットを含むターゲット・リストです。

- WebLogicサーバーに対するプロビジョニングまたはパッチ適用の場合、管理サーバー用、管理対象サーバー用、データベース用と3つのターゲット・リストが必要になる場合があります。

50.3.2 プロシージャ変数

プロシージャ変数は、プロシージャをカスタマイズするときに使用できるユーザー定義の変数です。通常は、カスタム・ステップをユーザー所有のプロシージャに追加するときや、Oracle所有のプロシージャをカスタマイズするときに、場合によってはプロシージャ変数を宣言する必要があります。この変数は後でカスタム・ステップまたはカスタム・フェーズで使用できます。

「プロシージャ変数」タブを表示するには、「エンタープライズ」メニューで「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。メニューから「新規作成」を選択し、「実行」をクリックします。次のページが表示されます。

プロシージャ変数を宣言するには、一意の名前と説明を入力する必要があります。必要に応じて、「パスワード」チェック・ボックスを選択して変数を保護できます。

2種類のプロシージャ変数を作成し、後でデプロイメント・プロシージャの起動中に使用できます。パラメータは次のとおりです。

- 文字列: 設計時にこの変数を宣言すると、オペレータが実行時に値を指定できます。たとえば、DBVER (データベースのバージョン)などです。

- テキスト: 変数の値を1つ入力できます。たとえば、ステージングの場所、ホスト名、プロファイル名などです。

- パスワード: パスワード変数を指定できます。たとえば、ホスト・パスワードやWLSパスワードなどです。

- 値のリスト: 変数の値を多数入力できます。変数の複数の値を提供するには、「加算」をクリックし、変数の値、表示名、説明などの詳細を入力します。たとえば、次のように複数の値を使用して、countryという名前の変数を宣言してみましょう。

値

表示テキスト

IDC

インド

US

アメリカ

IE

アイルランド

- ソフトウェア・ライブラリ・エンティティ: この変数を使用すると、プロシージャの起動時にソフトウェア・ライブラリ・ディレクティブまたはコンポーネントに変数を柔軟にバインドできます。以前は、プロシージャを作成している設計時にこれらの値を指定する必要がありましたが、現在はソフトウェア・ライブラリ・エンティティ変数が導入されたため、プロシージャの起動時に動的に値を指定できるようになっています。

注意:
Oracleが所有するデプロイメント・プロシージャにはプロシージャ変数を追加できません。

50.3.3 フェーズおよびステップ

デプロイメント・プロシージャは様々なフェーズとステップで構成されており、特定のプロビジョニング操作またはパッチ操作を実行するためにこれらがシリアルまたはパラレルで実行します。この項の内容は次のとおりです。

- フェーズのタイプ

- プロシージャ・ステップのタイプ

- プロシージャ・ステップでのタスクの実行

50.3.3.1 フェーズのタイプ

1つのフェーズにはステップまたは別のフェーズが含まれます。フェーズのタイプは次のとおりです。

- ローリング・フェーズ
ローリング・フェーズは、ステップがターゲット間でシリアル実行するフェーズです。

- パラレル・フェーズ
パラレル・フェーズは、ステップがターゲット間でパラレル実行するフェーズです。

50.3.3.2 プロシージャ・ステップのタイプ

ステップは、作業単位を表す概念です。たとえば、データベースの起動はステップです。フェーズに含まれる場合と独立している場合があります。ステップのタイプは次のとおりです。

- 手動ステップ
手動ステップは、ユーザー操作を必要とする自動化できないタスクです。通常、ユーザーが実行する必要のある手順は、デプロイメント・マネージャによって表示されます。操作を実行した後、次のステップに進みます。

手動ステップの例:

- システムにログオンしてカーネル・パラメータを更新します。

- システムを再起動します。

- ユーザーに特殊な権限を付与します。たとえば、SSH設定などです。

- 計算ステップ
計算ステップは、デプロイメント・エンジン内部で操作が実行され、ユーザー操作を必要としないタスクです。このステップでは、プロシージャを実行するための追加情報が収集されます。このステップを挿入できるのはオラクル社のみで、ユーザーが挿入することはできません。

計算ステップの例:

- Enterprise Managerスキーマに対してSQL問合せを実行して、他のステップを実行するための追加データを収集します。

- リポジトリからターゲット・プロパティを取得し、ランタイム情報を更新します。

- ファイル転送ステップ
ファイル転送ステップは、1つのホストから1つ以上のホストにファイルまたはディレクトリ(あるいはその両方)をコピーする場合に使用するステップです。ソース・ホストから宛先ホストに転送されるファイルおよびディレクトリをアーカイブできます。このステップをフェーズ内に挿入する場合、既存の変数を使用してソース・ターゲットおよびコピー先ターゲットを設定できます。

たとえば、ホストXから、フェーズに関連付けられたホストにディレクトリをコピーするには、「ソース・ターゲット」には「設定値」を選択してホストXを割り当て、「コピー先ターゲット」には「変数の選択」を選択して「ターゲット変数: 現在のターゲット」オプションに割り当てます。

- アクション・ステップ
アクション・ステップは、1つ以上のターゲットに対して操作を実行するタスクです。これらは1つのフェーズに含める必要があります。デプロイメント・プロシージャによって、アクション・ステップとターゲットの組合せがEnterprise Managerジョブ・システム内のジョブにマップされます。デプロイメント・プロシージャでは、ターゲットごと、アクション・ステップごとに、ジョブをスケジュール、発行および実行できます。たとえば、スクリプトの実行、パッチの適用、Oracleホームのアップグレードなどです。

また、アクション・ステップが正常に完了したといえるのは、関連するすべてのジョブが正常に完了した場合のみであることに注意してください。1つのジョブが異常終了すると、アクション・ステップも異常終了します。その場合は、問題のあるジョブを手動で再起動するか、またはそれを無視してデプロイメント・プロシージャに続行を指示することができます。

アクション・ステップのタイプは次のとおりです。

- ジョブ
ジョブ・ステップは、ターゲット上で事前定義済のジョブ・タイプを実行する特殊なタイプのアクション・ステップです。これは、デプロイメント・プロシージャの一部としてジョブ・タイプを実行する場合に使用します。ステップに対するジョブ・パラメータを渡す必要があります。

ジョブ・ステップの例:

- 既存のOracleホームのクローニング。

- パッチのステージング。

- データベースの起動。

- ライブラリ: ディレクティブ
ディレクティブ・ステップは、ディレクティブのみをデプロイするための特殊なタイプのアクション・ステップです。これは、カスタム・スクリプトをソフトウェア・ライブラリに格納し、デプロイメント・プロシージャ内でそのスクリプトを再利用する場合に便利です。

ディレクティブの詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

ディレクティブ・ステップの例:

- ルート・スクリプトの実行。

- catpatch.sqlの適用およびデータベースの再起動。

- 前提条件が満たされているかどうかの確認。

- ライブラリ: コンポーネント
コンポーネント・ステップとは、ソフトウェア・ライブラリ・コンポーネントおよび関連するディレクティブをデプロイするための特殊なタイプのアクション・ステップです。デプロイメント・プロシージャ・マネージャは、コンポーネントに関してディレクティブを実行します。汎用コンポーネント・ステップに使用されるコンポーネントには、通常1つのディレクティブが関連付けられています。このアソシエーションは、ステップの作成時に、コンポーネントとディレクティブの両方を選択して行います。ソフトウェア・ライブラリへのアップロード中にコンポーネントに関連付けたディレクティブはすべて、ステップの実行中には無視されます。

コンポーネントの詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

コンポーネント・ステップの例:

- パッチの適用。

- インストール実行前の前提条件チェックの実行。

- ターゲット・マシンへのOracleソフトウェアのインストール。

- ホスト・コマンド
ホスト・コマンド・ステップは、単純なホスト・コマンドをカプセル化する特殊なタイプのアクション・ステップです。このステップを使用すると、ターゲット・ホスト上で実行されるコマンドラインまたはスクリプト(複数のコマンド)を入力できます。

ホスト・コマンド・ステップの例:

- 管理エージェントの起動(emctl start agent)

- OPMNの停止(opmnctl stopall)

- OIDの再起動

50.3.3.3 プロシージャ・ステップでのタスクの実行

「プロシージャ・ステップ」タブでは、選択したステップまたはフェーズで次の操作を実行できます。

- 有効化/無効化: デプロイメント・プロシージャにフェーズまたはステップを表示したくない場合は、削除するのではなく、いつでも無効にできます。一度削除したステップまたはフェーズは復元できませんが、無効にしたステップまたはフェーズは後からいつでも有効にできるため、この方法をお薦めします。次の手順を実行します。

1. フェーズまたはステップを無効化するには、無効にするフェーズまたはステップを選択して、「無効化」をクリックします。

2. フェーズまたはステップを有効化するには、有効にするフェーズまたはステップを選択して、「有効化」をクリックします。

- 削除: 削除するステップまたはフェーズを選択し、「削除」をクリックします。

注意:
一度削除したステップまたはフェーズは復元できませんが、無効にすれば後からいつでも有効にできるため、ステップまたはフェーズは削除せずに無効にすることをお薦めします。

- 挿入: 新しいステップまたはフェーズを追加するには、「挿入」をクリックします。作成ウィザードで、次のいずれかの操作を行います。
- フェーズの追加。50.4.1項を参照してください。

- ステップの追加。50.4.2項を参照してください。

- ステップの編集: ステップまたはフェーズを編集するには、「ステップの編集」をクリックします。選択に応じて、フェーズの編集またはステップの編集ウィザードが表示されます。必要に応じて、次の手順に従います:
- フェーズの編集。参照先

- ステップの編集。参照先

50.4 プロシージャの作成

カスタム・プロシージャを作成するには、次の手順を実行します。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. 「プロシージャ・ライブラリ」にあるアクションのリストから「新規作成」を選択し、「ジャンプ」をクリックします。

3. 新規プロシージャの作成ページの「一般情報」タブで、プロシージャの名前と説明、プロシージャ・ユーティリティのステージング・パスおよび、環境変数を指定します。

4. 新規プロシージャの作成ページで、「ターゲット・リスト」タブをクリックします。所定のフェーズが実行できる独自のカスタム・ターゲット・リストを作成できます。50.3.1項を参照してください。
このアプローチには、複数のカスタム・ターゲット・リストを使用し、プロシージャでフェーズごとに割り当てることができるという利点があります。

5. 新規プロシージャの作成ページで、「プロシージャ変数」タブをクリックします。独自のプロシージャ変数を作成できます。50.3.2項を参照してください。

6. 新規プロシージャの作成ページで、「プロシージャ・ステップ」タブをクリックします。このタブでは、プロシージャにフェーズおよびステップを追加できます。フェーズまたはステップの追加する手順の詳細は、第50.4.1項および第50.4.2項を参照してください。

50.4.1 ローリング・フェーズまたはパラレル・フェーズの追加

フェーズを作成する前に、ターゲット・リストを作成したことを確認します。次に手順を示します。

フェーズを挿入するには、次の手順に従います。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. プロビジョニング・ページの「プロシージャ・ライブラリ」タブで、メニューから「新規作成」を選択し、「実行」をクリックします。

3. 新規プロシージャの作成ページで、「プロシージャ・ステップ」タブをクリックします。

4. 「デフォルト・フェーズ」を選択し、「挿入」をクリックして、フェーズを追加します。

注意:
別のフェーズ内にフェーズを作成する場合、挿入の場所として「"デフォルト・フェーズ"の後」または「"デフォルト・フェーズ"の前」を選択します。"デフォルト・フェーズ"の内部を選択すると、次のページでターゲットを選択できなくなります。

5. 作成ウィザードで、次の手順を実行します。

1. 作成ページで、次の表の説明に従って、フェーズの一般情報を指定します。

表50-3 フィールドの説明 - ローリング・フェーズの追加

フィールド名

説明

選択

「フェーズ」を選択します。

名前

カスタム・フェーズの名前を指定します。

説明

カスタム・フェーズの説明を指定します。

条件

このフィールドを空白のままにします。

挿入場所

選択したフェーズまたはステップの後にカスタム・フェーズを挿入する場合は、「"フェーズ名またはステップ名"の後」を選択します。選択したフェーズまたはステップの内側に挿入するには「フェーズまたはステップの中」、それ以外の場合は「"フェーズまたはステップ"の前」を選択します。

タイプ

ローリング・フェーズを追加する場合は、「ローリング」を選択します。パラレル・フェーズを追加する場合は、「パラレル」を選択します。

エラー処理

カスタム・フェーズに設定するエラー処理モードを選択します。デプロイメント・プロシージャのすべてのステップには、エラー処理モードが事前に構成されています。これにより、フェーズまたはステップでエラーが発生した際にデプロイメント・プロシージャの動作が指示されます。Cloud Controlでは次のエラー処理モードが提供されています。

- 継承 - 包含するフェーズに設定されているエラー処理モードを継承します。(フェーズの外部のステップに設定されると、デプロイメント・プロシージャのエラー処理モードを継承します)。

- エラー時に停止 - エラーが発生した場合に停止します。エラーを修正するか、オーバーライドするまでは、デプロイメント・プロシージャは次のステップに進みません。

- エラー時も続行 - エラーが発生した場合でも続行します。

- ターゲットをスキップ - リストで失敗したターゲットを無視し、他のターゲットで続行します。

2. ターゲット・リストの選択ページで、新しいフェーズを実行するターゲットのタイプを指定します。
プロシージャの作成中に宣言されたターゲット・リストがすべてドロップダウン・メニューにリストされるので、このフェーズで使用するターゲット・リストを選択します。実際のターゲットは、プロシージャの起動時に選択できます。

3. 確認ページで、新しいフェーズを作成するために指定した情報を確認して、「終了」をクリックします。

50.4.2 ステップの追加

この項では、デプロイメント・プロシージャに様々なタイプのステップを追加する方法について説明します。特に、次の内容について説明します。

- ジョブ・ステップの追加

- ディレクティブ・ステップの追加

- コンポーネント・ステップの追加

- ファイル転送ステップの追加

- ホスト・コマンド・ステップの追加

- 手動ステップの追加

ジョブ・ステップの追加

作成ウィザードで、次の手順を実行します。

1. 作成ページで、ステップの一般的な情報(表50-4)を指定します。

2. タイプの選択ページで、ステップによって実行するタスクをよく表しているジョブ・タイプを選択します。たとえば、ジョブでファイルをネットワークに転送する場合は、「ファイル転送」を選択します。

3. プロパティのマップ・ページで、選択したジョブ・タイプで必要なパラメータの値を指定します。また、このステップに適用するターゲット・リストを設定できます。

4. 確認ページで、新しいステップを作成するために指定した情報を確認して、「終了」をクリックします。

ディレクティブ・ステップの追加

ディレクティブ・ステップをデプロイメント・プロシージャに追加するには、次の手順を実行します。

作成ウィザードで、次の手順を実行します。

1. 作成ページで、ステップの一般的な情報(表50-4)を指定します。

2. ディレクティブの選択ページの「プロシージャ・ライブラリ」タブで、ソフトウェア・ライブラリ変数を選択した場合は、次のいずれかのオプションを選択できます。そうでない場合は、ディレクティブを表から直接選択し、「次へ」をクリックします。
- 新規ディレクティブの選択: ソフトウェア・ライブラリで使用できるすべてのディレクティブがリストされます。このリストから、ターゲットで実行するディレクティブを選択します。検索結果を絞り込むには、「ディレクティブの選択」セクションで必要な値を指定します。

- 新しいソフトウェア・ライブラリ・エンティティ変数の選択: 「ソフトウェア・ライブラリ・エンティティ変数」ドロップダウン・メニューから、プロシージャの作成中に宣言したソフトウェア・ライブラリ変数を選択します。この変数はプレースホルダとして機能するので、プロシージャの起動時に動的にディレクティブにバインドできるという柔軟性があります。基本的には、この変数を使用して、パラメータを必要としない特定のエンティティを選択します。

たとえば、パラメータを渡す必要のない現在のディレクトリの場所を印刷する、Perlなどのユーザー定義のスクリプトです。

- ディレクティブ・プロパティとともに新しいソフトウェア・ライブラリ・エンティティ変数を選択: このオプションでは、ソフトウェア・ライブラリで使用可能なディレクティブで、ソフトウェア・ライブラリ・エンティティ変数をバインドできます。必ず、宣言されたエンティティにプロパティ(シグネチャ)が一致するディレクティブを選択してください。

選択したディレクティブの最新版のみが常に使用されるように、「常に最新の改訂を使用」を選択します。

3. プロパティのマップ・ページで、次の詳細を指定します。

- デフォルトでは、「ディレクティブの実行」および「クリーンアップの実行」オプションが有効になり、スクリプトの実行、およびステップの実行後のファイルの削除が可能です。

- 「ディレクティブのプロパティ」セクションで、選択したディレクティブに関連付けられているプロパティに値を指定します。この時点では、プロパティ値を指定しても指定しなくてもかまいません。プロパティ値を指定しない場合は、プロシージャの起動時に要求されます。

- 「資格証明」セクションで、このステップに適用するターゲット・リストを設定します。

- 「時間制限のプロパティ」セクションで、操作の完了にかけることのできる最大時間(秒)を設定できます。たとえば、多数のステップを持つ巨大なプロシージャがある場合、1つのステップが失敗したときに、(エージェントが停止するため)全体の実行をブロックしないようにするとします。このようなシナリオでは、ステップの時間制限を設定すると非常に効果的です。ステップで75秒の制限時間を設定した場合、ジョブがこの設定時間を超えると、ステップはスキップされます。

4. 確認ページで、新しいステップを作成するために指定した情報を確認して、「終了」をクリックします。

コンポーネント・ステップの追加

汎用コンポーネント・ステップをデプロイメント・プロシージャに追加するには、次の手順を実行します。

作成ウィザードで、次の手順を実行します。

1. 作成ページで、ステップの一般的な情報(表50-4)を指定します。

2. コンポーネントの選択ページで、表からコンポーネント名を選択し、「次へ」をクリックします。ただし、「プロシージャ・ライブラリ」タブで、ソフトウェア・ライブラリ変数を選択した場合は、次のいずれかのオプションを選択する必要があります。
- 新規コンポーネントの選択: ソフトウェア・ライブラリで使用できるすべてのコンポーネントがリストされます。このリストから、ターゲットで実行するコンポーネントを選択します。検索結果を絞り込むには、「コンポーネントの選択」セクションで必要な値を指定します。

- 新しいソフトウェア・ライブラリ・エンティティ変数の選択: 「ソフトウェア・ライブラリ・エンティティ変数」ドロップダウン・メニューから、プロシージャの作成中に宣言したソフトウェア・ライブラリ変数を選択します。この変数はプレースホルダとして機能するので、プロシージャの起動時に動的にコンポーネントにバインドできるという柔軟性があります。基本的には、この変数を使用して、パラメータを必要としない特定のエンティティを選択します。

たとえば、パラメータを渡す必要のない現在のディレクトリの場所を印刷する、Perlなどのユーザー定義のスクリプトです。

- コンポーネント・プロパティとともに新しいソフトウェア・ライブラリ・エンティティ変数を選択: ソフトウェア・ライブラリで使用できるコンポーネントに、ソフトウェア・ライブラリ・エンティティ変数をバインドできます。必ず、宣言されたエンティティにプロパティ(シグネチャ)が一致するコンポーネントを選択してください。

「常に最新の改訂を使用」を選択すると、選択したコンポーネントの最新版のみが常に使用されます。

3. ディレクティブの選択ページで、表からディレクティブを選択し、「次へ」をクリックします。ただし、「プロシージャ・ライブラリ」タブで、ソフトウェア・ライブラリ変数を選択した場合は、次のいずれかのオプションを選択する必要があります。
- 新規ディレクティブの選択: ソフトウェア・ライブラリで使用できるすべてのディレクティブがリストされます。このリストから、ターゲットで実行するディレクティブを選択します。検索結果を絞り込むには、「ディレクティブの選択」セクションで必要な値を指定します。

- 新しいソフトウェア・ライブラリ・エンティティ変数の選択: 「ソフトウェア・ライブラリ・エンティティ変数」ドロップダウン・メニューから、プロシージャの作成中に宣言したソフトウェア・ライブラリ変数を選択します。この変数はプレースホルダとして機能するので、プロシージャの起動時に動的にディレクティブにバインドできるという柔軟性があります。基本的には、この変数を使用して、パラメータを必要としない特定のエンティティを選択します。

たとえば、パラメータを渡す必要のない現在のディレクトリの場所を印刷する、Perlなどのユーザー定義のスクリプトです。

- ディレクティブ・プロパティとともに新しいソフトウェア・ライブラリ・エンティティ変数を選択: このオプションでは、ソフトウェア・ライブラリで使用可能なディレクティブで、ソフトウェア・ライブラリ・エンティティ変数をバインドできます。必ず、宣言されたエンティティにプロパティ(シグネチャ)が一致するディレクティブを選択してください。

選択したディレクティブの最新版のみが常に使用されるように、「常に最新の改訂を使用」を選択します。

4. プロパティのマップ・ページで、次の詳細を指定します。

- デフォルトでは、「ディレクティブの実行」および「クリーンアップの実行」オプションが有効になり、スクリプトの実行、およびステップの実行後のファイルの削除が可能です。

- 「ディレクティブのプロパティ」セクションで、選択したディレクティブに関連付けられているプロパティに値を指定します。この時点では、プロパティ値を指定しても指定しなくてもかまいません。プロパティ値を指定しない場合は、プロシージャの起動時に要求されます。

- 「資格証明」セクションで、このステップに適用するターゲット・リストを設定します。

- 「時間制限のプロパティ」セクションで、操作の完了にかけることのできる最大時間(秒)を設定できます。たとえば、多数のステップを持つ巨大なプロシージャがある場合、1つのステップが失敗したときに、(エージェントが停止するため)全体の実行をブロックしないようにするとします。このようなシナリオでは、ステップの時間制限を設定すると非常に効果的です。ステップで75秒の制限時間を設定した場合、ジョブがこの設定時間を超えると、ステップはスキップされます。

5. 確認ページで、新しいステップを作成するために指定した情報を確認して、「終了」をクリックします。

ファイル転送ステップの追加

作成ウィザードで、次の手順を実行します。

1. 作成ページで、ステップの一般的な情報(表50-4)を指定します。

2. プロパティのマップ・ページで、ファイル転送元の「ソース・ターゲット」とソース・ターゲットのパス、ファイル転送先のコピー先ターゲットとコピー先のパスを選択します。「ソース資格証明」と「接続先資格証明」の「使用状況」、ホスト資格証明と特権ホスト資格証明のどちらかを指定します。「次へ」をクリックします。
このパスのすべてのファイルを転送オプションを選択した場合は、ソース・パスのすべてのファイルが転送されます。このオプションを選択しない場合、「ソース・ファイル名」フィールドは必須になります。

3. 確認ページで、新しいステップを作成するために指定した情報を確認して、「終了」をクリックします。

ホスト・コマンド・ステップの追加

作成ウィザードで、次の手順を実行します。

1. 作成ページで、ステップの一般的な情報(表50-4)を指定します。

2. コマンドの入力ページで、ターゲットで実行するコマンドまたはスクリプトと、実行するための権限を指定します。
ホスト・コマンドをスクリプトとして実行するには、「コマンド・タイプ」メニューから「スクリプト」を選択します。スクリプトを解析できるシェルを指定してください。スクリプトは、指定したインタプリタに標準入力として渡されます。

ホスト・コマンドをコマンドラインとして実行するには、「コマンド・タイプ」メニューから「単一操作」を選択します。コマンドラインとして実行するテキストを指定してください。このコマンドラインを解析するシェルは想定されていません。コマンドラインの最初の入力は生成するプロセスとみなされ、コマンドラインの残りはこのプロセスに引数として渡されます。このため、ls -a /tmpのコマンドラインにより、(現在のパスに対して、あるいはOracle Management Agentによって設定されたパスに対して) lsのプロセスが生成され、このプロセスに-aが1番目の引数、/tmpが2番目の引数として渡されます。

注意: コマンドライン・モードでは、コマンドラインの最初の部分が生成するプロセスとみなされます。このため、解決のためにPATH環境変数に依存するシェルの内部処理とコマンドは認識されません。そのようなコマンドを使用する場合は、そのコマンドラインを解釈するシェルを付加する必要があります。

たとえば、コマンドcd /tmp && rm -rf xは、"cd"がプロセス、"/tmp, &&, rm, -rf, x"が引数として展開されます。これを修正するには、コマンドラインを/bin/csh -c "cd /tmp && rm -rf x"に変更します。

別の例では、コマンドexport PATH=/opt:${PATH}; myopt -installは、"export"をプロセス、"PATH=/opt:${PATH};, myopt, -install"を引数として展開されます。これを修正するには、/bin/sh -c "export PATH=/opt:${PATH}; myopt -install"を使用します。

3. 「時間制限のプロパティ」セクションで、スクリプトにかけることのできる最大時間(秒)を設定できます。たとえば、この値を75秒に設定した場合、スクリプトの実行時に設定時間を超えると、このステップはスキップされます。

4. 確認ページで、新しいステップを作成するために指定した情報を確認して、「終了」をクリックします。

手動ステップの追加

作成ウィザードで、次の手順を実行します。

1. 作成ページで、ステップの一般的な情報(表50-4)を指定します。

2. 方法の入力ページで、手動ステップに関してオペレータに通知するメッセージを指定します。たとえば、システムにログインしてカーネル・パラメータを更新するようにオペレータに指示する場合は、次のように指定します。

You have been logged out of the system. Log in and update the Kernel parameters.

3. 確認ページで、新しいステップを作成するために指定した情報を確認して、「終了」をクリックします。

表50-4 フィールドの説明 - ステップの追加

フィールド名

説明

選択

「ステップ」を選択します。

名前

カスタム・ステップの名前を指定します。

説明

カスタム・ステップの説明を指定します。

条件

このフィールドを空白のままにします。

挿入場所

選択したステップの後にカスタム・ステップを挿入する場合は、「"ステップ名"の後」を選択します。それ以外の場合は、「"ステップ"の前」を選択します。

タイプ

- ジョブ・ステップの場合は「ジョブ」を選択します。

- ディレクティブ・ステップの場合は「ライブラリ: ディレクティブ」を選択します。

- 汎用コンポーネントの場合は「ライブラリ: コンポーネント」を選択します。

- ファイル転送ステップの場合は「ファイル転送」を選択します。

- 手動ステップの場合は「手動」を選択します。

- ホスト・コマンド・ステップの場合は「ホスト・コマンド」を選択します。

エラー処理

カスタム・フェーズに設定するエラー処理モードを選択します。デプロイメント・プロシージャのすべてのステップには、エラー処理モードが事前に構成されています。これにより、フェーズまたはステップでエラーが発生した際にデプロイメント・プロシージャの動作が指示されます。Cloud Controlでは次のエラー処理モードが提供されています。

- 継承 - 包含するフェーズに設定されているエラー処理モードを継承します。(フェーズの外部のステップに設定されると、デプロイメント・プロシージャのエラー処理モードを継承します)。

- エラー時に停止 - エラーが発生した場合に停止します。エラーを修正するか、オーバーライドするまでは、デプロイメント・プロシージャは次のステップに進みません。

- エラー時も続行 - エラーが発生した場合でも続行します。

- ターゲットをスキップ - リストで失敗したターゲットを無視し、他のターゲットで続行します。

50.5 デプロイメント・プロシージャの管理

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

- プロシージャの表示、編集、削除

- プロシージャの権限の編集と保存

- プロシージャの実行およびデプロイメント・プロシージャ・ステータスの追跡

- プロシージャの再スケジュール

- プロシージャの回復

50.5.1 プロシージャの表示、編集、削除

既存のプロシージャを表示、編集または削除するには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. プロビジョニング・ページで次のようにします。

- プロシージャを表示するには、デプロイメント・プロシージャを選択し、アクション・メニューで「プロシージャ定義の表示」をクリックします。

- プロシージャを編集するには、ユーザー定義プロシージャを選択し、アクション・メニューで「プロシージャ定義の編集」を選択して「実行」をクリックします。Oracle提供のプロシージャをカスタマイズする場合には、アクション・メニューから「類似作成」を選択し、「実行」をクリックします。プロシージャを保存してからカスタマイズします。

- プロシージャを削除するには、デプロイメント・プロシージャを選択し、アクション・メニューで「削除」をクリックします。

50.5.2 プロシージャの権限の編集と保存

スーパー管理者権限を持つデザイナには、デプロイメント・プロシージャの権限を編集して保存するためのアクセス権があります。

デプロイメントの権限を編集するには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. プロビジョニング・ページのアクション・メニューで「権限の編集」を選択し、「実行」をクリックします。

3. 権限の編集: <target name>ページで、「追加」をクリックします。「管理者またはロールの検索および選択」ダイアログで、権限を付与する管理者またはロールを選択し、「選択」をクリックします。

4. 権限の編集: <target name>ページで、ロールと、各ロールに付与する権限を選択します。「完全」権限では、オペレータがデプロイメント・プロシージャを編集できます。「起動」権限では、オペレータはデプロイメント・プロシージャの表示と実行しかできません。「OK」をクリックして、これらの付与内容を保存します。

50.5.3 プロシージャの実行およびデプロイメント・プロシージャ・ステータスの追跡

デプロイメント・プロシージャを発行した後で、プロシージャ完了ステータス・ページでステータスを追跡できます。このページにアクセスするには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. プロビジョニング・ページで「プロシージャ・アクティビティ」タブをクリックします。

3. プロシージャ・アクティビティ・ページで、プロシージャをクリックし、ライフサイクルの様々なステージにおけるすべてのデプロイメント・プロシージャのステータスを表示します。

表50-5 デプロイメント・プロシージャのステータス

ステータス

説明

スケジュール済

デプロイメント・プロシージャが、指定した日時に実行されるようにスケジュールされていることを示します。

実行中

デプロイメント・プロシージャが現在実行されていることを示します。

アクション必須

ユーザー操作が必要であるためにデプロイメント・プロシージャが停止していることを示します。

一時停止中

デプロイメント・プロシージャが一時的に実行を休止したことを示します。後で、一時休止したステップから再開できます。

失敗

デプロイメント・プロシージャが失敗し、残りのステップを実行できないことを示します。ただし、失敗したステップを再試行することは、いつでも可能です。あるいは、エラーを無視して続行することもできます。

成功

デプロイメント・プロシージャの実行が正常に完了したことを示します。

スキップ

デプロイメント・プロシージャが、このステップの実行をスキップしたことを示します。ステップがスキップされるのは主として、ステップに指定された条件がfalseと評価された場合です。

停止

ユーザーによってデプロイメント・プロシージャの実行が完全に停止されたことを示します。

保存済

実行するデプロイメント・プロシージャが発行されておらず、保存されていることを示します。

エラーで完了

デプロイメント・プロシージャが完了したが、エラーが発生したことを示します。一部のステップが異常終了し、ステップで「ターゲットをスキップ」/エラー時も続行フラグが有効になっていた可能性があります。

次の操作も実行できます。

1. 「検索」セクションを使用して特定のデプロイメント・プロシージャを検索します。「検索」をクリックして検索基準を絞り込みます。

2. すべてのデプロイメント・プロシージャのステータスを表示します。ページを手動でリフレッシュしてステータスを更新するには、「リフレッシュ」をクリックします。

3. 特定のリフレッシュ間隔(30秒、1分または5分など)に基づいてリアルタイムのステータス情報を表示します。

4. デプロイメント・プロシージャを停止または一時停止します。デプロイメント・プロシージャを選択してから、「停止」または「一時停止」をクリックします。「再開」または「再試行」をクリックしていつでも再開できます。

5. デプロイメント・プロシージャを削除します。選択して「削除」をクリックします。

注意:
ジョブの追跡の詳細は、参照してください。

50.5.4 プロシージャの再スケジュール

このページを使用して、プロシージャを再スケジュールします。プロシージャのステータスが「スケジュール済」の場合にのみ、プロシージャを再スケジュールできます。その他すべての場合では、このボタンはグレー表示されます。プロシージャを再スケジュ作成するには、次の手順に従います。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・アクティビティ」タブを選択します。

2. プロシージャ・アクティビティ・ページで、スケジュール済プロシージャを表から選択し、「再スケジュール」をクリックします。

3. 再スケジュール・ページで、プロシージャを実行する日付と時刻を選択します。

4. 「繰返し」メニューからオプションを選択し、選択した頻度でジョブを実行します。

5. 目的のパラメータをすべて選択したら、「再スケジュール」をクリックします。

50.5.5 プロシージャの回復

このページを使用して、プロシージャを以前のバージョンに回復します。別のバージョンのプロシージャに戻すには、次の手順に従います:

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. 「プロシージャ・ライブラリ」で、メニューから「元に戻す」を選択します。「元に戻す」オプションは、プロシージャがユーザーによって編集された場合にのみ有効になります。

3. 「実行」をクリックします。

たとえば、最新バージョンが1.5の場合、バージョン1.3に戻すと新しいバージョンである1.6が作成されますが、これはバージョン1.3と同じ内容です。

50.5.6 ステップ・レベルの猶予期間の設定

Enterprise Managerのコマンドライン(emctl)ユーティリティを使用して、OMS全体のステップ・レベルの猶予期間を設定できます。プロシージャを送信する際に、猶予期間を超えてもまだエージェントが到達しない場合、このステップはfailedとしてマークされます。

ステップ・レベルの猶予期間を設定するには、次のコマンドを実行します。

emctl set property -sysman_pwd sysman -name
oracle.sysman.core.procedure.steplevel_graceperiod -value <value of the grace period>

For example, to set a grace period of 12 mins for a step, run the following command:

emctl set property -sysman_pwd sysman -name
oracle.sysman.core.procedure.steplevel_graceperiod -value 12

Submit any procedure using the Cloud Control UI, if the agent machine is not reachable for a time period longer than 12 minutes, then the step is marked as failed.

注意:
注意事項:

- 猶予期間は分単位でカウントされます。

- デフォルトでは、猶予期間の最低値は10分です。

- 猶予期間は、プロシージャ内のステップにのみ適用されます。Cloud ControlまたはEMCLIを使用してプロシージャを送信する場合は、プロシージャ・レベルの猶予期間が割り当てられます。

50.6 ユーザー定義デプロイメント・プロシージャ(UDDP)の作成、保存および起動

「ユーザー定義デプロイメント・プロシージャ」では、必要なフェーズ、ステップ、変数などを挿入して、最初からプロシージャを作成することができます。この機能はEnterprise Manager 12cに導入されました。これにより、ユーザーが要件に合うようにプロシージャを自由にカスタマイズできます。

注意:
ユーザー定義デプロイメント・プロシージャの作成および使用に関するビデオ・チュートリアルについては、次を参照してください。
「Oracle Enterprise Manager 12c: Implement User-Defined Deployment Procedures」

プロセスは、次のように2つのサブカテゴリに大別することができます。

- ステップ1: ユーザー定義デプロイメント・プロシージャの作成

- ステップ2: デフォルト入力のユーザー定義デプロイメント・プロシージャの保存と起動

- ステップ3: 保存されているユーザー定義デプロイメント・プロシージャの起動と実行

- ステップ4: 発行したユーザー定義デプロイメント・プロシージャの追跡

注意:
Linuxホストabc.example.comでJRE6をプロビジョニングする手順を含むユーザー定義デプロイメント・プロシージャのワークフローの例は、第A.6.3項を参照してください。

50.6.1 ステップ1: ユーザー定義デプロイメント・プロシージャの作成

デザイナ権限でEnterprise Manager Cloud Controlにログインし、UDDPテンプレートを作成します。これには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. プロビジョニング・ページのアクション・リストで「新規作成」を選択し、「実行」をクリックします。

3. 「新規プロシージャの作成」ページの「一般情報」タブで、プロシージャの一意の名前と説明を入力します。

4. 「ターゲット・リスト」タブで、デフォルトのhost_target_list変数を使用するか、任意の数の新しいカスタムのターゲット・リストを追加します。新しいカスタムのターゲット・リストを追加すると、ターゲットをグループ化でき、各フェーズで個別のターゲット・リスト(ターゲット)を使用して反復実行できます。

5. 「プロシージャ変数」タブで、「行を追加」をクリックしてプロシージャ変数を定義します。「文字列」型に加え、「ソフトウェア・ライブラリ・エンティティ」変数も追加できます。詳細は、第50.3.2項を参照してください。
ドロップダウン・メニューから「変数名」、「表示名」、「説明」および「タイプ」を指定します。変数がパスワードと必須フィールドかどうかも定義します。

6. 「プロシージャ・ステップ」タブでデフォルトのフェーズを選択し、次の手順を実行します。

1. 「デフォルト・フェーズ」を選択し、「挿入」をクリックします。フェーズの挿入の詳細は、第50.4.1項を参照してください。

注意:
ターゲット・リストを宣言しないと、フェーズの作成を続行することはできません。

2. 作成したフェーズを選択し、「挿入」をクリックしてステップを挿入します。ステップの挿入の詳細は、第50.4.2項を参照してください。

7. ステップ6を繰り返し、作成するプロシージャに従ってスクリプトとフェーズを挿入します。

8. 「保存して閉じる」をクリックしてプロシージャを保存します。将来のデプロイのために構成を実行できます。

50.6.2 ステップ2: デフォルト入力のユーザー定義デプロイメント・プロシージャの保存と起動

オペレータ権限でEnterprise Manager Cloud Controlにログインし、デフォルト値で保存されているUDDPを起動します。これには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. 「プロビジョニング」ページで、保存されていたUDDPを選択し、「起動」をクリックします。

3. 「ターゲットの選択」ページで、ドロップダウン・メニューからターゲット・リストを選択し、「追加」をクリックしてターゲット・リストを移入します。「次へ」をクリックします。

4. プロシージャの作成時に定義しなかった変数を宣言した場合は、「変数の設定」ページで詳細を指定する必要があります。バインドされていない変数がすべて表示されるので、適切な値を入力します。
ソフトウェア・ライブラリ・エンティティ変数を宣言した場合は、「ソフトウェア・ライブラリ」から任意のエンティティを検索して選択できます。値が移入されたら、プロシージャに対する権限を持たないオペレータがこの値を更新できないように、この値をロックすることもできます。各種の変数については、第50.3.2項を参照してください。「次へ」をクリックします。

5. 「資格証明の設定」ページで、host_target_list変数の一部として追加したターゲット・ホスト・マシンの資格証明を設定する必要があります。「次へ」をクリックします。

6. 「スケジュールと通知の設定」ページで、ジョブをすぐに実行するか指定した時刻に実行するか、スケジュールします。

7. 「保存」をクリックして構成名を指定し、デフォルト値でジョブ・テンプレートを保存します。

プロシージャによっては、デフォルト値で保存するのみでなく、ロックすることもできます。たとえば、次のデータベースのプロビジョニングの手順では、ロック・ダウンを含むプロシージャの保存および起動方法について説明します。

50.6.2.1 ロック・ダウンを含むデプロイメント・プロシージャの保存と起動

ロック・ダウンはOracle Enterprise Manager Cloud Control 12cの新機能です。これを使用すると、デザイナ権限を持つ管理者が、企業内でデプロイメント・プロシージャを標準化することができます。スーパー管理者権限を持つデザイナが、ロック・ダウンを含むデプロイメント・プロシージャ・テンプレートを作成して保存すると、オペレータがこのようなテンプレートを使用できます。オペレータは、保存されたデプロイメント・プロシージャの起動、編集可能なフィールドの変更、プロシージャの実行を行うことができます。

ロック・ダウンを含むデプロイメント・プロシージャを作成する場合、管理者はデザイナ権限を使用してログインし、デプロイメント・プロシージャを起動します。デプロイメント・プロシージャのインタビュー・ウィザードで、デザイナは特定のフィールドに値を入力してロックし、他のユーザーがアクセスしたときに編集できないようにします。たとえば、次の図で、データベース・バージョンやデータベース・タイプのフィールドはデザイナによってロックされています。オペレータが同じデプロイメント・プロシージャを起動すると、これらのフィールドはグレー表示されて編集できません。

次のユースケースでは、ユーザーはデザイナ権限でログインし、Linuxホスト上の単一インスタンス・データベースをプロビジョニングします。デザイナは、オペレータなど他のユーザーが値を編集できないように、ウィザードでプロンプト表示されるほとんどの値を更新してロックします。ターゲットの追加や詳しい構成のための一部のフィールドはロックしません。その後、デプロイメント・プロシージャに一意のプロシージャ名を付けて保存しますが、発行はしません。オペレータ権限を持つユーザーがログインして、編集可能なすべてのフィールド(ターゲットの追加や詳しい詳細など)を更新した後で、保存されたプロシージャを実行します。

これは次のような2段階のプロセスです。

- ステップ1: ロック・ダウンを含む単一インスタンス・データベース・デプロイメント・プロシージャの保存

- ステップ2: 保存されている単一インスタンス・データベースのデプロイメント・プロシージャの起動

ステップ1: ロック・ダウンを含む単一インスタンス・データベース・デプロイメント・プロシージャの保存

ここでは、ユーザーがCloud Controlにデザイナ(ATBARBOZ1)としてログインし、ロック・ダウンを含む単一インスタンス・データベースをプロビジョニングします。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」を選択します。

2. 「データベースのプロビジョニング」ページで「Oracleデータベースのプロビジョニング」を選択して、「起動」をクリックします。

3. ホストの選択ページの「ホストの選択」セクションで、「追加」をクリックし、ソフトウェアをデプロイおよび構成する宛先ホストを選択します。
プロビジョニング・プロファイルをデプロイメントに使用する場合は、「プロビショニング・プロファイルを選択」で、事前に保存した構成パラメータを含むプロファイルを選択します。

「実行するタスクの選択」セクションで、次を実行して値をロックします。

- 「データベース・ソフトウェアのデプロイ」の選択による単一インスタンス・データベースのプロビジョニング

- スタンドアロンOracle Databaseをインストールした後で、「新規データベースの作成」を選択して新しいデータベースを作成および構成します。

4. 構成ページに、次の構成オプションが表示されます。

- 構成ページで「ホストの設定」をクリックします。オペレーティング・システム・ユーザー・ページで、データベースのOracleホームのオペレーティング・システム・ユーザーを指定します。データベースのOracleホーム・ユーザーについて、「通常ユーザー」と「特権ユーザー」を選択してOSグループに追加し、値をロックします。「次へ」をクリックして先に進みます。「OSグループの指定」ページで、次の図に示すように、オペレーティング・システム認証のためのOSグループを指定して値をロックします。

「次へ」をクリックして構成ページに戻ります。

- 構成ページで「ソフトウェアのデプロイ」をクリックします。ソフトウェアの場所の選択ページで、Oracle Databaseのソフトウェア・バイナリのコピー元とコピー先の場所を指定します。次の図に示すように、すべてのフィールドの値を更新し、ロック・アイコンをクリックして、オペレータ権限を持つユーザーがフィールドを編集できないようにします。

「次へ」をクリックして構成ページに戻ります。

- 構成ページで「データベースの作成」をクリックすると、次の画面が表示されます。必須フィールドのみを更新し、「次へ」をクリックして進みます。このウィザードではどの値もロックしないでください。

- 構成ページで「コンプライアンス標準」をクリックします。構成標準ターゲット・アソシエーション・ページでデータベースに関連付けるコンプライアンス標準を選択します。「次へ」をクリックします。値はロックしないでください。

5. スケジュール・ページでデプロイメント・インスタンス名を指定します。「スケジュール」セクションで「即時」を選択します。デプロイメント・プロシージャのステータスに対応する通知プリファレンスを設定できます。「次へ」をクリックします。

6. 確認ページで、デプロイメント・プロシージャに対して指定した詳細を確認します。「保存」をクリックして、一意名prov_db_templateでデプロイメント・プロシージャを保存し、次に「取消」をクリックします。保存したプロシージャがプロシージャ・ライブラリ・ページに表示されます。

ステップ2: 保存されている単一インスタンス・データベースのデプロイメント・プロシージャの起動

ここでは、ユーザーがオペレータ(SSIRAJUD1)としてログインし、保存されているデプロイメント・プロシージャprov_db_templateを実行し、単一インスタンス・データベースをプロビジョニングします。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. プロシージャ・ライブラリでプロシージャprov_db_templateを選択し、「起動」をクリックします。

3. ホストの選択ページの「ホストの選択」セクションで、「追加」をクリックし、ソフトウェアをデプロイおよび構成する宛先ホストを選択します。その後、「次へ」をクリックします。

4. 構成ページに、次の構成オプションが表示されます。

- 構成ページで「ホストの設定」をクリックします。これらの値はデザイナによってロックされているため編集できません。「次へ」をクリックして構成ページに戻ります。

- 構成ページで「ソフトウェアのデプロイ」をクリックします。これらの値はデザイナによってロックされているため編集できません。「次へ」をクリックして構成ページに戻ります。

- 構成ページで「データベースの作成」をクリックします。次の画面が表示されます。すべてのフィールドを更新し、「次へ」をクリックして進みます。
データベースの作成ウィザードの更新の詳細は、第5.3項を参照してください。

- 構成ページで「コンプライアンス標準」をクリックします。構成標準ターゲット・アソシエーション・ページでデータベースに関連付けるコンプライアンス標準を選択します。「次へ」をクリックします。

5. スケジュール・ページでデプロイメント・インスタンス名を指定します。「スケジュール」セクションで「即時」を選択します。デプロイメント・プロシージャのステータスに対応する通知プリファレンスを設定できます。「次へ」をクリックします。

6. 確認ページで、デプロイメント・プロシージャに指定した詳細を確認し、詳細に満足した場合は、「終了」をクリックして、設定したスケジュールのとおりデプロイメント・プロシージャを実行します。

50.6.3 ステップ3: 保存されているユーザー定義デプロイメント・プロシージャの起動と実行

オペレータ権限でEnterprise Manager Cloud Controlにログインし、デフォルト値で保存されているUDDPを実行します。これには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. 「プロビジョニング」ページで、前の手順で保存したUDDP構成テンプレートを選択し、「起動」をクリックします。

注意:
UDDPテンプレートの作成中にロックした値がある場合には、読取り専用の値でありここでは編集できないため、グレー表示されます。

3. 「ターゲットの選択」ページで、ドロップダウン・メニューからターゲット・リストを選択し、「追加」をクリックしてターゲット・リストを移入します。「次へ」をクリックします。

4. プロシージャの作成時に定義しなかった変数を宣言した場合は、「変数の設定」ページで詳細を指定する必要があります。
ソフトウェア・ライブラリ・エンティティ変数を宣言した場合は、「ソフトウェア・ライブラリ」から任意のエンティティを検索して選択できます。値が移入されたら、プロシージャに対する権限を持たないオペレータがこの値を更新できないように、この値をロックすることもできます。各種の変数については、第50.3.2項を参照してください。「次へ」をクリックします。

5. 「資格証明の設定」ページで、host_target_list変数の一部として追加したターゲット・ホスト・マシンの資格証明を設定する必要があります。「次へ」をクリックします。

6. 「スケジュールと通知の設定」ページで、ジョブをすぐに実行するか指定した時刻に実行するか、スケジュールします。

7. 「発行」をクリックし、ジョブに一意の「発行名」を指定します。

50.6.4 ステップ4: 発行したユーザー定義デプロイメント・プロシージャの追跡

次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・アクティビティ」を選択します。

2. 「プロシージャ・アクティビティ」ページで、発行するジョブをクリックします。

3. ジョブの新しいインスタンスの実行ページが表示され、すべてのターゲットについてジョブの成功と失敗に関する情報が示されます。
新しいインスタンスの実行ページの詳細は、第50.1項を参照してください。

50.7 プロシージャ・インスタンスの実行ページ

プロシージャ・インスタンスの実行ページから、次のタスクを実行できます。

- 新旧のプロシージャ・インスタンスの実行ページの設計の比較

- プロシージャ・インスタンス実行ページの概要

- 単一または一連のターゲットの失敗したステップの調査

- 失敗したステップの再試行

- インシデントの作成

- デプロイメント・プロシージャの実行時間の表示

- ステップの検索

- ステップ出力のダウンロード

- 「ジョブ・サマリー」ページヘのアクセス

注意:
プロシージャの実行追跡ページに関するビデオ・チュートリアルについては、次を参照してください。
「Oracle Enterprise Manager 12c: View Deployment Procedure Execution Details」

50.7.1 新旧のプロシージャ・インスタンスの実行ページの設計の比較

現在の「プロシージャ・アクティビティ」ページには、デプロイメント・プロシージャで実行されたすべてのステップのステータスが表示されます。このページには、失敗したステップと、それを修正するために必要な処置の情報も表示されます。

新しい「プロシージャ・アクティビティ」ページについて理解する前に、現在の「プロシージャ・アクティビティ」ページを使用する際に想定される課題を考えてみましょう。

表50-6 従来の「プロシージャ・アクティビティ」ページと新しい「プロシージャ・アクティビティ」ページの比較

カテゴリ

従来の「プロシージャ・アクティビティ」ページ

新しい「プロシージャ・アクティビティ」ページ

画面設計

一度に1ステップずつ処理できる画面設計。

ドリルダウンする必要がなく、同じページからすべてのステップとターゲットにアクセスできる、最適な画面設計。

複数選択

複数を選択することはできません。

単一ページから複数の選択が可能。たとえば、失敗したステップのみを選択する場合、新しい設計を使用して行うことができます。

ターゲット中心型の設計

ステップ中心型のアプローチのため、1つの画面からすべてのターゲットへのアクセスが制限されます。したがって、これまでのアプローチでは、一度に1つの失敗したステップにしかドリルダウンできず、別の失敗したステップに対してはプロシージャ全体を繰り返す必要がありました。

フィルタが導入されたターゲット中心型の設計により、同じページから失敗したすべてのステップの分析と、ステップでの必要なアクションの実行が容易になりました。

ステップ出力

ステップ中心型の設計なので、実際のステップまでドリルダウンするには多数のページをトラバースする必要があります。

ターゲット中心型の設計では、これまでのステップ中心型とは異なり、同じページからステップの詳細をすべて表示できます。

詳細な出力

これまでの設計では、ステップの詳細な出力は利用できませんでした。ログ全体をダウンロードする必要がありました。

詳細な出力はステップ・レベルで使用可能な新しいオプションで、選択されたそのステップに関連するログ情報を取得し、失敗した場合のステップの表示およびデバッグを容易にします。

インシデントの作成

これまでの設計では、インシデントを作成できませんでした。

インシデント作成はプロシージャ・レベルで導入された新しい機能で、失敗した場合に後でプロシージャのデバッグに使用できる実行用のインシデントを作成できます。

Cloud Controlは、最大限に簡略化され最短の時間で、単一ページからすべてのターゲットおよび手順にアクセスできる、大幅に改良されたターゲット中心型のプロシージャ管理ソリューションを使用して、既存のプロシージャ・アクティビティ・ページの課題に対処します。新しい「プロシージャ・アクティビティ」ページには、次の利点があります。

50.7.2 プロシージャ・インスタンス実行ページの概要

プロシージャ・アクティビティ・ページは主に発行したプロシージャ・インスタンスの実行の追跡に役立ちます。プロシージャ・インスタンスの実行ページを表示するには、実行中のインスタンスをクリックします。図50-2に示すように、このページは大きく次のように分けられます。

注意:
Enterprise Manager 12.1.0.3 (パッチ・セット2)以上では、「プロシージャの実行」ページに次の拡張機能が追加されています。

- 追加のフィルタが導入され、表示メニューのサブメニューのかわりに、表レベルでステップをフィルタ処理できるようになっています。詳細は、図50-2のポイント6を参照してください。

- デフォルトでは、ステップの詳細をタブ・レイアウトで表示できます。ただし、スタック・ビューに切り替えるオプションも残されています。タブ・レイアウトを使用するメリットは、次のとおりです。
a> ログの詳細がすべて画面に表示されます。

b> ログ・ファイルをダウンロードするプロビジョンが用意されています。

c> 「ジョブ・サマリー」リンクをクリックして、基本的なジョブに関する詳細を表示できます。

図50-2 「プロシージャの実行」ページ

注意:
プロシージャ・インスタンスの実行ページから実行できるタスクの詳細は、第50.7項を参照してください。

1. ブレッドクラム証跡

2. データの表示

3. 「プロシージャ・アクション」セクション

4. 「スタック・ビューに切替え」

5. 「ステップ詳細」セクション

6. 「プロシージャ・ステップ」セクション

ブレッドクラム証跡

シングル・クリックでプロシージャ・アクティビティ・ページに戻ることができます。

データの表示

プロシージャ・レベルまたはステップ・レベルでの更新後、ページをリフレッシュできます。これを行うには、「データの表示」メニューで使用できるリフレッシュ・オプションを選択する必要があります。バックグラウンドでプロシージャのリフレッシュを実行するには、30秒間リフレッシュ、「1分間リフレッシュ」、または「5分間リフレッシュ」のような自動リフレッシュ・オプションのいずれかを選択し、別の領域での作業を継続することができます。

「プロシージャ・アクション」セクション

プロシージャがステータス「成功」で正常に完了した場合、「プロシージャ・アクション」メニュー項目はグレー表示され、成功したプロシージャでアクションを実行することはできません。しかし、プロシージャがなんらかの理由で停止または一時停止した場合、プロシージャの実行を制御できるように、対応するメニュー項目が有効になります。

プロシージャ・レベルで、次のアクションを実行できます。

アクション

説明

デバッグ

プロシージャでのエラーをデバッグします。これは1回かぎりのアクションで、つまり最初にこのオプションが使用されると、このメニューは無効になります。

停止

プロシージャの実行を停止します。

一時停止

プロシージャの実行を一時停止します。

再開

プロシージャを停止または一時停止された段階から再開します。

再試行

デプロイメント・プロシージャ・インスタンスの失敗したすべてのステップおよびフェーズをもう一度実行します。

インシデント

実行のインシデントを作成し、これによりデプロイメント・プロシージャの一部として実行されるすべてのステップおよびフェーズをデバッグおよび理解することができます。

「スタック・ビューに切替え」

「スタック・ビューに切替え」オプションを選択して、ビューをデフォルトのタブ・ビューからスタック・ビューに変更します。

タブ・ビューを使用するメリットは、次のとおりです。

- ログ・ファイルの詳細を同じページに表示できます。

- 「ジョブ詳細」ページアクセスして、基本的なジョブに関する詳細を表示できます。

- ログ・ファイルをローカル・システムにダウンロードできます。

「ステップ詳細」セクション

選択したステップの詳細を表示できます。基本的に、ステップの「ステップのタイプ」、「開始日」、「完了日」および「経過時間」などの情報が表示されます。しかし、各ステップ・タイプのテンプレートは同じではありません。たとえば、手動ステップではユーザー操作が必要で、つまり、ジョブの詳細を確認して続行する必要がある場合があります。ステップ・ウィンドウを閉じると、「プロシージャ・ステップ」セクションからステップの選択が解除されます。

ステップを実行したら、「ジョブ・サマリー」オプションをクリックして「ジョブ詳細」ページにアクセスし、基本的なジョブに関する詳細を表示できます。

「ダウンロード」オプションをクリックして、対応するステップのログ・ファイルをダウンロードします。

ステップが失敗した場合、「アクション」メニューを使用して、ステップで次のアクションを実行できます。

アクション

説明

無視

ステップの失敗を無視し、デプロイメント・プロシージャの別のステップを続行します。

再試行

ステップをもう一度実行

更新と再試行

ステップを編集することができ、その後、発行されたらステップを実行します。

「プロシージャ・ステップ」セクション

プロシージャ・インスタンスが実行のために発行されると実行されるすべてのステップを表示できます。「表示」メニューから「すべて開く」を選択し、ステップ名、ステップのタイプ、およびステップのステータスなどのステップの詳細を表示します。

たとえば、「サポートされている構成のチェック」という名前のステップを選択したときに表示されるように、対応する実行の詳細が新しいタブに表示されます。

50.7.3 単一または一連のターゲットの失敗したステップの調査

設計がターゲット中心、つまりすべてのターゲットおよびそれに対応するステップが「プロシージャ・ステップ」セクションにリストされるため、同じページから1つのターゲットを選択または一連のターゲットを選択(複数選択)して、ステップのステータスを表示できます。これを行うには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・アクティビティ」を選択します。

2. 「プロシージャ・アクティビティ」ページで、プロシージャ名をクリックしてプロシージャを選択します。

3. 「プロシージャ・ステップ」セクションで、「表示」メニューから「失敗した手順」を選択します。
失敗したすべてのステップが、「プロシージャ・ステップ」セクションに表示されます。再試行、無視、または更新するステップを選択できるようになり、対応する詳細が「ステップ詳細」セクションに表示されます。

50.7.4 失敗したステップの再試行

失敗したステップを再試行するには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・アクティビティ」を選択します。

2. 「プロシージャ・アクティビティ」ページで、プロシージャ名をクリックしてプロシージャを選択します。

3. 「プロシージャ・ステップ」セクションから失敗したステップを選択します。失敗したステップの選択の詳細は、第50.7.3項を参照してください。
ステップの詳細が「設定詳細」セクションに表示されます。

4. 「ステップ詳細」セクションで、「アクション」メニューから「再試行」をクリックします。ステップに変更を加える場合は、「更新と再試行」オプションを選択します。

5. 「再試行」確認ダイアログ・ボックスで、「OK」をクリックして、ステップを再度実行します。

50.7.5 インシデントの作成

プロシージャの実行のためのインシデントを作成するには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・アクティビティ」を選択します。

2. 「プロシージャ・アクティビティ」ページで、プロシージャ名をクリックしてプロシージャを選択します。

3. プロシージャ・インスタンスの実行ページで、「プロシージャ・アクション」メニューから「インシデント」を選択します。

4. 「インシデント」確認ダイアログ・ボックスで、「OK」をクリックして、実行のためのインシデントを作成します。
インシデントが作成されると、確認ダイアログ・ボックスが表示されます。インシデントの作成、パッケージ化、およびSRへのアップロードについては、『Oracle Database管理者ガイド』を参照してください。

50.7.6 デプロイメント・プロシージャの実行時間の表示

デプロイメント・プロシージャの実行時間は、「プロシージャ・アクション」セクションのページの上部に、「経過時間」として表示されます。経過時間は、プロシージャが正常に完了するか停止するまで更新され続けます。「プロシージャ・アクション」メニューから「再開」を選択して、停止したプロシージャを再開できます。

50.7.7 ステップの検索

内部に深く埋め込まれているステップを検索するには、「表示」メニューの「すべて開く」オプションを使用できます。展開されたリストが「プロシージャ・ステップ」セクションに表示されると、目的のステップを簡単に検索できます。

50.7.8 ステップ出力のダウンロード

ステップ出力をダウンロードするには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・アクティビティ」を選択します。

2. 「プロシージャ・アクティビティ」ページで、プロシージャ名をクリックしてプロシージャを選択します。

3. 「プロシージャ・ステップ」セクションで、ステップを選択します。次の図に示すように、「ステップ詳細」セクションで「ダウンロード」をクリックし、ステップ出力をダウンロードします。

50.7.9 「ジョブ・サマリー」ページヘのアクセス

「ジョブ・サマリー」ページにアクセスするには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・アクティビティ」を選択します。

2. 「プロシージャ・アクティビティ」ページで、プロシージャ名をクリックしてプロシージャを選択します。

3. 「プロシージャ・ステップ」セクションで、ステップを選択します。「ステップ詳細」セクションで使用可能な「ジョブ・サマリー」リンクをクリックして、基本的なジョブに関する詳細を表示します。

51 デプロイメント・プロシージャのカスタマイズ

Oracle Enterprise Manager Cloud Control (Cloud Control)で提供されているデプロイメント・プロシージャは、業界でのすべてのベスト・プラクティスを考慮して作成されているデフォルトのプロシージャです。デプロイメント・プロシージャに含まれている手順により、プロビジョニングとパッチ適用に関するすべての要件を満たすことができます。デフォルトの設定のままデプロイメント・プロシージャを使用して、環境内のターゲットに対してプロビジョニングまたはパッチ適用を行うことはできますが、デプロイメント・プロシージャをカスタマイズして、カスタム手順を追加する、不要な手順を無効化する、認証ツールを使用して別のユーザーとしての一部の手順を実行するといったことも可能です。

デプロイメント・プロシージャをカスタマイズして、様々なエラー処理方法を実装することもできます。たとえば、複数のホストにパラレルでパッチを適用するパッチ操作では、エラーが発生したホストのスキップが適切な場合があります。ただし、デバイス作成におけるエラーによって、その後のプロビジョニング操作が無効になることがあります。したがって、場合によってはこのようなステップのエラーの際にプロシージャ全体を中止する必要があります。

この章では、ニーズに合うようにデプロイメント・プロシージャをカスタマイズする方法を理解することができます。この章の具体的な内容は次のとおりです。

- デプロイメント・プロシージャのカスタマイズ・タイプについて

- デプロイメント・プロシージャのカスタマイズ

- 実行時にデプロイメント・プロシージャ変数に値を割り当てるためのワークフロー例

- デプロイメント・プロシージャのエラー処理モードの変更

- デプロイメント・プロシージャのステータスに関する電子メール通知の設定

- カスタマイズしたプロビジョニング・エンティティをEnterprise Managerサイト間でコピー

- ディレクティブをカスタマイズするためのワークフロー例

51.1 デプロイメント・プロシージャのカスタマイズ・タイプについて

次に、デプロイメント・プロシージャに対して行えるカスタマイズのタイプを説明します。

タイプ1

タイプ2

カスタム・デプロイメント・プロシージャの編集
Cloud Controlで提供されている既存のカスタム・デプロイメント・プロシージャを編集して、新しいフェーズとステップを追加できます。ただし、パッチ適用の場合、追加できるステップはディレクティブ・ステップまたはホスト・コマンド・ステップのみです。

次のタスクを実行できます。

- プロシージャ構造の事前定義済ブロックに独自のフェーズとステップを追加します。

- フェーズとステップを有効化または無効化します。

- フェーズとステップを削除します。

- 権限レベルを変更します。

- エラー処理モードを変更します。

- 電子メール通知を有効化します。

注意: Oracle所有のデプロイメント・プロシージャは編集できません。そのためには、類似作成の機能を使用してOracle所有のプロシージャをクローニングし、それを編集して変更を含める必要があります。

ユーザー定義デプロイメント・プロシージャの作成
新しいステップ、フェーズ、権限レベルなどを含む独自のデプロイメント・プロシージャを作成できます。

次のタスクを実行できます。

- プロシージャ構造の事前定義済デフォルト・フェーズに独自のフェーズとステップを追加します。

- フェーズとステップを有効化または無効化します。

- 権限レベルを変更します。

- エラー処理モードを変更します。

- 電子メール通知を有効化します。

注意: ユーザー定義デプロイメント・プロシージャを作成するための手順は、第50.6項を参照してください。

次の図では、デプロイメント・プロシージャのカスタマイズ・ページを使用して、Cloud Controlで提供されるデフォルト・デプロイメント・プロシージャのコピーを作成する方法を示します。その後、新しいステップやフェーズを追加するか、コピーに含まれる既存のステップやフェーズを編集して、プロシージャをカスタマイズできます。

ステップとフェーズの追加方法の詳細は、第51.2項を参照してください。

51.2 デプロイメント・プロシージャのカスタマイズ

デプロイメント・プロシージャをカスタマイズするための最初の手順は、Cloud Controlで提供されるデフォルト・デプロイメント・プロシージャのコピーの作成です。独自の変更内容で編集およびカスタマイズできるのはコピーだけです。デフォルト・デプロイメント・プロシージャは絶対に変更しないでください。

デプロイメント・プロシージャにフェーズまたはステップを追加して、追加のカスタム・スクリプト、ホスト・コマンドまたはジョブを実行することができます。フェーズとステップの詳細は、第50.3.3項を参照してください。

注意:
フェーズの外部でステップを追加する場合、追加できるステップのタイプは「ジョブ・ステップ」または「手動ステップ」に限定されます。フェーズの外部で、他のステップは追加できません。一方フェーズの内部では、この項で説明するすべてのステップを追加できます。

ここでは、デプロイメント・プロシージャで様々なタイプのフェーズまたはステップを編集する方法を説明します。特に、次の内容について説明します。

- デプロイメント・プロシージャのローリングおよびパラレル・フェーズの編集

- デプロイメント・プロシージャのジョブ・ステップの編集

- デプロイメント・プロシージャのディレクティブ・ステップの編集

- デプロイメント・プロシージャのコンポーネント・ステップの編集

- デプロイメント・プロシージャのファイル転送ステップの編集

- デプロイメント・プロシージャのホスト・コマンド・ステップの編集

- デプロイメント・プロシージャの手動ステップの編集

51.2.1 デプロイメント・プロシージャのローリングおよびパラレル・フェーズの編集

フェーズの一般情報を編集するには、次の手順に従います。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. プロビジョニング・ページの「プロシージャ・ライブラリ」タブで、メニューから「新規作成」を選択し、「実行」をクリックします。

3. 新規プロシージャの作成ページで、「プロシージャ・ステップ」タブをクリックします。

4. フェーズを選択し、「ステップの編集」をクリックして、フェーズを編集します。

5. 作成ウィザードで、次の手順を実行します。

1. 作成ページに、フェーズの一般情報が表示されます。必要に応じてを変更し、「次へ」をクリックします。

2. ターゲット・リストの選択ページで、新しいフェーズを実行するターゲットのタイプを指定します。
プロシージャの作成中に宣言されたターゲット・リストがすべてドロップダウン・メニューにリストされるので、このフェーズで使用するターゲット・リストを選択します。実際のターゲットは、プロシージャの起動時に選択できます。

3. 確認ページで、新しいフェーズを作成するために指定した情報を確認して、「終了」をクリックします。フェーズの変更が保存されます。

51.2.2 デプロイメント・プロシージャのジョブ・ステップの編集

編集ウィザードで、次の操作を実行します。

1. 編集ページで、ステップの一般情報を確認します。値を更新する場合は、表51-1で説明されているステップの一般情報に従います。

2. タイプの選択ページでは、ジョブ・タイプの詳細を表示できます。

3. パラメータのマップ・ページでは、変数値を更新するか、新しい変数値を設定できます。また、ターゲット・リストに使用する資格証明を更新することもできます。

4. 確認ページで、更新を確認し、「終了」をクリックします。

51.2.3 デプロイメント・プロシージャのディレクティブ・ステップの編集

編集ウィザードで、次の操作を実行します。

1. 編集ページで、ステップの一般情報を確認します。値を更新する場合は、表51-1で説明されているステップの一般情報に従います。

2. 「ディレクティブの選択」ページで、次のいずれかのオプションを選択できます。
- 新規ディレクティブの選択: ソフトウェア・ライブラリで使用できるすべてのディレクティブがリストされます。このリストから、ターゲットで実行するディレクティブを選択します。検索結果を絞り込むには、「ディレクティブの選択」セクションで必要な値を指定します。

- ディレクティブの選択の保持: このオプションでは、このステップの作成時に選択したのと同じディレクティブを使用できます。

3. プロパティのマップ・ページで、次の詳細を確認します。

- デフォルトでは、「ディレクティブの実行」および「クリーンアップの実行」オプションが有効になり、スクリプトの実行、およびステップの実行後のファイルの削除が可能です。必要に応じて無効にできます。

- 「ディレクティブのプロパティ」セクションで、選択したディレクティブに関連付けられているプロパティに値を指定します。この時点では、プロパティ値を指定しても指定しなくてもかまいません。プロパティ値を指定しない場合は、プロシージャの起動時に要求されます。

- 「資格証明」セクションで、このステップに適用するターゲット・リストを設定します。

- 「時間制限のプロパティ」セクションで、操作の完了にかけることのできる最大時間(秒)を更新できます。

4. 確認ページで、更新を確認し、「終了」をクリックします。

51.2.4 デプロイメント・プロシージャのコンポーネント・ステップの編集

編集ウィザードで、次の操作を実行します。

1. 編集ページで、ステップの一般情報を確認します。値を更新する場合は、表51-1で説明されているステップの一般情報に従います。

2. 「コンポーネントの選択」ページで、次のいずれかのオプションを選択できます。
- 選択の保持: このオプションでは、このステップの作成時に選択したのと同じコンポーネントを使用できます。

- 新規コンポーネントの選択: ソフトウェア・ライブラリで使用できるすべてのコンポーネントがリストされます。このリストから、ターゲットで実行するコンポーネントを選択します。検索結果を絞り込むには、「コンポーネントの選択」セクションで必要な値を指定します。

「プロシージャ変数」タブでソフトウェア・ライブラリ変数を設定した場合は、次の2つのオプションが追加で表示されます。

- 新しいソフトウェア・ライブラリ・エンティティ変数の選択: 「ソフトウェア・ライブラリ・エンティティ変数」ドロップダウン・メニューから、プロシージャの作成中に宣言したソフトウェア・ライブラリ変数を選択します。この変数はプレースホルダとして機能するので、プロシージャの起動時に動的にコンポーネントにバインドできるという柔軟性があります。基本的には、この変数を使用して、パラメータを必要としない特定のエンティティを選択します。

たとえば、パラメータを渡す必要のない現在のディレクトリの場所を印刷する、Perlなどのユーザー定義のスクリプトです。

- コンポーネント・プロパティとともに新しいソフトウェア・ライブラリ・エンティティ変数を選択: ソフトウェア・ライブラリで使用できるコンポーネントに、ソフトウェア・ライブラリ・エンティティ変数をバインドできます。必ず、宣言されたエンティティにプロパティ(シグネチャ)が一致するコンポーネントを選択してください。

3. 「ディレクティブの選択」ページで、次のいずれかのオプションを選択できます。
- ソフトウェア・ライブラリ・エンティティ変数の選択の保持: このオプションでは、このステップの作成時に選択したのと同じディレクティブを使用できます。

- 新規ディレクティブの選択: ソフトウェア・ライブラリで使用できるすべてのディレクティブがリストされます。このリストから、ターゲットで実行するディレクティブを選択します。検索結果を絞り込むには、「ディレクティブの選択」セクションで必要な値を指定します。

「プロシージャ変数」タブでソフトウェア・ライブラリ変数を設定した場合は、次の2つのオプションが追加で表示されます。

- 新しいソフトウェア・ライブラリ・エンティティ変数の選択: 「ソフトウェア・ライブラリ・エンティティ変数」ドロップダウン・メニューから、プロシージャの作成中に宣言したソフトウェア・ライブラリ変数を選択します。この変数はプレースホルダとして機能するので、プロシージャの起動時に動的にディレクティブにバインドできるという柔軟性があります。基本的には、この変数を使用して、パラメータを必要としない特定のエンティティを選択します。

たとえば、パラメータを渡す必要のない現在のディレクトリの場所を印刷する、Perlなどのユーザー定義のスクリプトです。

- ディレクティブ・プロパティとともに新しいソフトウェア・ライブラリ・エンティティ変数を選択: このオプションでは、ソフトウェア・ライブラリで使用可能なディレクティブで、ソフトウェア・ライブラリ・エンティティ変数をバインドできます。必ず、宣言されたエンティティにプロパティ(シグネチャ)が一致するディレクティブを選択してください。

4. プロパティのマップ・ページで、次の詳細を確認します。

- デフォルトでは、「ディレクティブの実行」および「クリーンアップの実行」オプションが有効になり、スクリプトの実行、およびステップの実行後のファイルの削除が可能です。必要に応じて無効にできます。

- 「ディレクティブのプロパティ」セクションで、選択したディレクティブに関連付けられているプロパティに値を指定します。この時点では、プロパティ値を指定しても指定しなくてもかまいません。プロパティ値を指定しない場合は、プロシージャの起動時に指定するよう求められます。

- 「資格証明」セクションで、このステップに適用するターゲット・リストを設定します。

- 「時間制限のプロパティ」セクションで、操作の完了にかけることのできる最大時間(秒)を更新できます。2つのオプションがある場合は、インタビュー時間にラジオ・ボタンが表示されます。3つ以上のオプションがある場合は、表示メニューが表示されます。

5. 確認ページで、更新を確認し、「終了」をクリックします。

51.2.5 デプロイメント・プロシージャのファイル転送ステップの編集

編集ウィザードで、次の操作を実行します。

1. 編集ページで、ステップの一般情報を確認します。値を更新する場合は、表51-1で説明されているステップの一般情報に従います。

2. プロパティのマップ・ページで、ファイル転送元の「ソース・ターゲット」とソース・ターゲットのパス、ファイル転送先のコピー先ターゲットとコピー先のパスを選択します。「ソース資格証明」と「接続先資格証明」の「使用状況」、ホスト資格証明と特権ホスト資格証明のどちらかを指定します。「次へ」をクリックします。
このパスのすべてのファイルを転送オプションを選択した場合は、ソース・パスのすべてのファイルが転送されます。このオプションを選択しない場合、「ソース・ファイル名」フィールドは必須になります。

3. 確認ページで、更新を確認し、「終了」をクリックします。

51.2.6 デプロイメント・プロシージャのホスト・コマンド・ステップの編集

編集ウィザードで、次の操作を実行します。

1. 編集ページで、ステップの一般情報を確認します。値を更新する場合は、表51-1で説明されているステップの一般情報に従います。

2. コマンドの入力ページで、ターゲットで実行するコマンドまたはスクリプトと、実行するための権限を指定します。
ホスト・コマンドをスクリプトとして実行するには、「コマンド・タイプ」リストから「スクリプト」を選択します。スクリプトを解析できるシェルを指定してください。スクリプトは、指定したインタプリタに標準入力として渡されます。

ホスト・コマンドをコマンドラインとして実行するには、「コマンド・タイプ」リストから「単一操作」を選択します。コマンドラインとして実行するテキストを指定してください。このコマンドラインを解析するシェルは想定されていません。コマンドラインの最初の入力は生成するプロセスとみなされ、コマンドラインの残りはこのプロセスに引数として渡されます。このため、ls -a /tmpのコマンドラインにより、(現在のパスに対して、あるいはOracle Management Agentによって設定されたパスに対して) lsのプロセスが生成され、このプロセスに-aが1番目の引数、/tmpが2番目の引数として渡されます。

注意: コマンドライン・モードでは、コマンドラインの最初の部分が生成するプロセスとみなされます。このため、解決のためにPATH環境変数に依存するシェルの内部処理とコマンドは認識されません。そのようなコマンドを使用する場合は、そのコマンドラインを解釈するシェルを付加する必要があります。

たとえば、コマンドcd /tmp && rm -rf xは、"cd"がプロセス、"/tmp, &&, rm, -rf, x"が引数として展開されます。これを修正するには、コマンドラインを/bin/csh -c "cd /tmp && rm -rf x"に変更します。

別の例では、コマンドexport PATH=/opt:${PATH}; myopt -installは、"export"をプロセス、"PATH=/opt:${PATH};, myopt, -install"を引数として展開されます。これを修正するには、/bin/sh -c "export PATH=/opt:${PATH}; myopt -install"を使用します。

3. 「時間制限のプロパティ」セクションで、スクリプトにかけることのできる最大時間(秒)を設定できます。たとえば、この値を75秒に設定した場合、スクリプトの実行時に設定時間を超えると、このステップはスキップされます。

4. 確認ページで、更新を確認し、「終了」をクリックします。

51.2.7 デプロイメント・プロシージャの手動ステップの編集

編集ウィザードで、次の操作を実行します。

1. 編集ページで、ステップの一般情報を確認します。値を更新する場合は、表51-1で説明されているステップの一般情報に従います。

2. 方法の入力ページで、手動ステップに関してオペレータに通知するメッセージを指定します。たとえば、システムにログインしてカーネル・パラメータを更新するようにオペレータに指示する場合は、次のように指定します。

You have been logged out of the system. Log in and update the Kernel parameters.

3. 確認ページで、更新を確認し、「終了」をクリックします。

表51-1 フィールドの説明 - ステップのカスタマイズ

フィールド名

説明

選択

「ステップ」を選択します。

名前

カスタム・ステップの名前を指定します。

説明

カスタム・ステップの説明を指定します。

条件

このフィールドを空白のままにします。

挿入場所

選択したステップの後にカスタム・ステップを挿入する場合は、「"ステップ名"の後」を選択します。それ以外の場合は、「"ステップ"の前」を選択します。

タイプ

- ジョブ・ステップの場合は「ジョブ」を選択します。

- ディレクティブ・ステップの場合は「ライブラリ: ディレクティブ」を選択します。

- 汎用コンポーネントの場合は「ライブラリ: コンポーネント」を選択します。

- ファイル転送ステップの場合は「ファイル転送」を選択します。

- 手動ステップの場合は「手動」を選択します。

- ホスト・コマンド・ステップの場合は「ホスト・コマンド」を選択します。

エラー処理

カスタム・フェーズに設定するエラー処理モードを選択します。デプロイメント・プロシージャのすべてのステップには、エラー処理モードが事前に構成されています。これにより、フェーズまたはステップでエラーが発生した際にデプロイメント・プロシージャの動作が指示されます。Cloud Controlでは次のエラー処理モードが提供されています。

- 継承 - 包含するフェーズに設定されているエラー処理モードを継承します。(フェーズの外部のステップに設定されると、デプロイメント・プロシージャのエラー処理モードを継承します)。

- エラー時に停止 - エラーが発生した場合に停止します。エラーを修正するか、オーバーライドするまでは、デプロイメント・プロシージャは次のステップに進みません。

- エラー時も続行 - エラーが発生した場合でも続行します。

- ターゲットをスキップ - リストで失敗したターゲットを無視し、他のターゲットで続行します。

51.3 実行時にデプロイメント・プロシージャ変数に値を割り当てるためのワークフロー例

Enterprise Manager 12.1.0.3 (パッチ・セット2)以上では、PAF機能ドメイン内のコマンド・ブロックを使用する新しい機能が導入されています。コマンド・ブロックは、ホストで実行中のスクリプトにより出力ストリームに印刷される必要のある一連の文字列です。次の形式に従います。

$$$--*$$'
<commandBlock>
<executeProc name="MGMT_PAF_UTL.UPDATE_RUNTIME_DATA">
<scalar>%job_execution_id%</scalar>
<scalar>${data.<DP_VARIABLE_NAME>}</scalar>
<scalar><DP_VARIABLE_VALUE></scalar>
</executeProc>
</commandBlock>
$$$*--$$

Where,you need to enter the values for <DP_VARIABLE_NAME> and <DP_VARIABLE_VALUE>

Example:
In the following example, isPingSuccessful is the DP variable, and true is the value.
print '$$$--*$$';
print '<commandBlock>';
print '<executeProc name="MGMT_PAF_UTL.UPDATE_RUNTIME_DATA"> ';
print '<scalar>%job_execution_id%</scalar> ';
print '<scalar>${data.isPingSuccessful}</scalar> ';
print '<scalar>true</scalar> ';
print '</executeProc>';
print '</commandBlock>';
print '$$$*--$$';

任意の言語(シェル、Perlなど)を使用して、ホストで実行するスクリプトを記述できます。前述のコマンド・ブロックを出力ストリームに印刷できるかぎり、プロシージャ変数は更新されます。

この機能を使用すると、ランタイム時にプロシージャで宣言された変数の値を更新できます。また、コマンド・ブロック機能を使用すると、リモート・マシン(エージェント)から生成された出力の自動後処理の実行が可能になり、この出力はOMSにアップロードされてジョブ・システムで処理されます。PAFでは、この機能を使用して、コマンド・ブロック形式の出力を持つプロシージャ内のステップを定義できます。コマンド・ブロック内では、SQLプロシージャを起動して、プロシージャ変数に値を割り当てることができます。

注意:
実行時にコマンド・ブロックを使用してプロシージャで宣言された変数を更新できるのは、ディレクティブ・ステップ、コンポーネント・ステップおよびジョブ・ステップのみです。

次の例に、ターゲットでコマンドを実行して、ランタイム時にプロシージャの変数を更新する方法を示します。この例では、プロシージャのディレクティブ・ステップを使用して、pingコマンドをホストで実行します。pingコマンドが成功すると、ディレクティブはプロシージャの値をtrueに設定します。失敗すると、ディレクティブはプロシージャの値をfalseに設定します。

次に示すのは、高レベルのステップです。

表51-2 ランタイム時の変数値の割当て

ステップ

詳細

手順1

ローカル・ホストで、TestPingAndSetDPVariable.plという名前のPerlファイルを作成します。詳細は、51.3.1項を参照してください。

手順2

Perlスクリプトをソフトウェア・ライブラリにアップロードします。手順の詳細なリストについては、第51.3.2項を参照してください。

手順3

変数isPingSucessfullを追加するプロシージャと、コマンド・ブロックの印刷と前の手順で作成したディレクティブのコールを行ういくつかのプロシージャ・ステップを作成します。詳細は、51.3.3項を参照してください。

手順4

プロシージャを実行します。詳細は、第51.3.4項を参照してください。

手順5

変数の詳細を確認します。詳細は、第51.3.5項を参照してください。

51.3.1 ステップ1: 実行時にデプロイメント・プロシージャ変数に値を割り当てるPerlスクリプトの作成

任意のエディタを開き、次のコード行をコピーして、ファイルをPerlスクリプトとして保存します。

system("ping", "-c", "1", "127.0.0.1");
if ( $? == 0 )
{
# below 9 lines of print statements set the DP variable "isPingSuccessful" as "true" string
print '$$$--*$$';
print '<commandBlock>';
print '<executeProc name="MGMT_PAF_UTL.UPDATE_RUNTIME_DATA"> ';
print '<scalar>%job_execution_id%</scalar> ';
print '<scalar>${data.isPingSuccessful}</scalar> ';
print '<scalar>true</scalar> ';
print '</executeProc>';
print '</commandBlock>';
print '$$$*--$$';
}
else
{
# below 9 lines of print statements set the DP variable "isPingSuccessful" as "false" string
print '$$$--*$$';
print '<commandBlock> ';
print '<executeProc name="MGMT_PAF_UTL.UPDATE_RUNTIME_DATA"> ';
print '<scalar>%job_execution_id%</scalar> ';
print '<scalar>${data.isPingSuccessful}</scalar> ';
print '<scalar>false</scalar> ';
print '</executeProc> ';
print '</commandBlock>';
print '$$$*--$$ ';
}

51.3.2 ステップ2: ソフトウェア・ライブラリへのTestPingAndDPvariable.plのアップロード

ソフトウェア・ライブラリでディレクティブ・エンティティを作成するには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

2. ソフトウェア・ライブラリ・ホームページで、任意のユーザー所有のディレクティブ・フォルダを右クリックします。コンテキスト・メニューから、「エンティティの作成」を選択し、「ディレクティブ」をクリックします。「ディレクティブの作成」ページが表示されます。

3. 「説明」ページで、フォルダの一意の名前を入力します。たとえば、TestPingAndSetDPVariableを入力します。「次へ」をクリックします。

4. 「構成」ページの「プロパティの構成」セクションで、「シェル・タイプ」リストから「Perl」を選択します。「次へ」をクリックします。

5. 「ファイルの選択」ページの「宛先の指定」セクションで、指定したファイルをアップロードするための任意のソフトウェア・ライブラリのアップロード場所を選択します。
「ソースの指定」セクションで、「ファイル・ソース」を「ローカル・マシン」として選択します。「加算」をクリックし、ローカル・ホストからPerlスクリプトTestPingAndDPVariable.plを選択します。「次へ」をクリックします。

6. すべての詳細を確認し、「保存とアップロード」をクリックします。

関連項目:
詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

51.3.3 ステップ3: デプロイメント・プロシージャの作成

プロシージャを作成するには、次の手順に従います。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」をクリックします。

2. 「プロシージャ・ライブラリ」ページでメニューから、「新規作成」を選択し、「実行」をクリックします。

3. 「一般情報」ページで、プロシージャの一意の名前を入力します。

4. 「新規プロシージャの作成」ページで、「プロシージャ変数」をクリックします。「行を追加」をクリックし、次の詳細を入力します。

5. 「プロシージャ・ステップ」タブをクリックします。「デフォルト・フェーズ」を選択し、「挿入」をクリックして、次のステップをデフォルト・フェーズに追加します。

1. プロシージャを実行する前に変数の値を印刷するホスト・コマンド・ステップを追加します。次に手順を示します。「作成」ページで、メニューから「ホスト・コマンド」を選択して、ステップの一意の名前を入力し、「次」をクリックします。「コマンドの入力」ページで、値echo Before String is: "${data.isPingSuccessful}"を入力します。
注意: DPコードのDP変数isPingSuccessfulにアクセスする式は、${data.isPingSuccessful}です。

「次へ」をクリックします。詳細を確認して、「終了」をクリックします。

2. ソフトウェア・ライブラリにアップロードされたディレクティブをコールするためのpingと呼ばれるディレクティブ・ステップを追加します。これを行うには、「作成」ページで、ステップに対して一意の名前を入力し、「タイプ」メニューから「ディレクティブ」を選択します。「ディレクティブの選択」ページで、文字列%Ping%を検索します。アップロードしたディレクティブを選択し、次をクリックします。「プロパティのマップ」ページで、すべてをデフォルト値のままにすることができます。「確認」ページで、「終了」をクリックします。

3. プロシージャを実行した後に変数の値を印刷するホスト・コマンド・ステップを追加します。次に手順を示します。「作成」ページで、メニューから「ホスト・コマンド」を選択して、ステップの一意の名前を入力し、「次」をクリックします。「コマンドの入力」ページで、値echo After String is: "${data.isPingSuccessful}"を入力します。「次へ」をクリックします。詳細を確認して、「終了」をクリックします。

6. 「保存して閉じる」をクリックします。

51.3.4 ステップ4: プロシージャの起動および実行時の変数値の入力

次のようにプロシージャを実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」をクリックします。

2. 「プロシージャ・ライブラリ」ページで、前の手順で作成したプロシージャを選択し、「起動」をクリックします。「プロシージャ・インタビュー」ページが表示されます。

3. 「ターゲットの選択」ページで、このプロシージャを実行するターゲットを選択します。「次へ」をクリックします。

4. 「変数の設定」ページで、isPingSuccessful変数に対して、次の値を入力します。

This is the Value I Entered.

「次へ」をクリックします。

5. 「資格証明」ページで、ターゲットの資格証明を設定します。

6. 「スケジュール」ページで、「即時」を選択し、「発行」をクリックします。

7. 「発行名」を入力し、「OK」をクリックします。

51.3.5 ステップ5: デプロイメント・プロシージャ変数値の確認

プロシージャ発行の様々な段階で変数値を確認するには、次の手順に従います。

1. 「プロシージャ・アクティビティ」ページで、発行したプロシージャ・インスタンスを選択します。

2. プロシージャ・インスタンスの実行ページで、ステップPrint Beforeを選択します。このステップは、発行時に入力した変数値を印刷します。

「コマンドの実行」ブロックに次の出力が表示されます。

Before String is: This is the Value I entered.

3. プロシージャ・インスタンスの実行ページで、ステップPingを選択します。

注意:
Pingステップが実行され、pingコマンドが正常に終了します。ただし、Perlスクリプト内でコマンド・ブロック文字列を印刷するprint文は、表示されません。これは、これらの特別なコマンド・ブロック文字列は、ジョブ・ストリームにより解析され、プロシージャ変数の割当てロジックを処理するために使用されるためです。

4. プロシージャ・インスタンスの実行ページで、ステップPrint Afterを選択します。このステップは、変数値をtrueとして印刷します。この値は、ホストで実行したディレクティブにより設定されます。

「コマンドの実行」ブロックに次の出力が表示されます。

After String is: true

このように、ターゲットで実行した他のコマンドにより戻される出力に応じて、ディレクティブ・ステップを使用してプロシージャ変数をランタイム時に操作できます。

51.4 デプロイメント・プロシージャのエラー処理モードの変更

デプロイメント・プロシージャのすべてのステップには、エラー処理モードが事前に構成されています。これにより、フェーズまたはステップでエラーが発生した際にデプロイメント・プロシージャの動作が指示されます。Cloud Controlでは次のエラー処理モードが提供されています。

- 継承 - 含まれるフェーズに設定されたエラー処理モードを継承します。(フェーズの外部のステップに設定されると、デプロイメント・プロシージャのエラー処理モードを継承します)。

- エラー時に停止 - エラーが発生すると停止します。エラーを修正するか、オーバーライドするまでは、デプロイメント・プロシージャは次のステップに進みません。

- エラー時も続行 - エラーが発生しても続行します。

- ターゲットをスキップ: - リスト上の失敗したターゲットを無視し、他のターゲットに進みます。

ステップの詳細は、第50.3.3項を参照してください。

エラー処理モードを変更するには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. プロビジョニング・ページで、カスタマイズするデプロイメント・プロシージャを選択して、「類似作成」をクリックします。

3. 類似作成プロシージャ・ページで「プロシージャ・ステップ」タブをクリックし、ステップまたはフェーズを選択して、「エラー処理モード」を変更します。
リストからモードを選択すると、該当のフェーズまたはステップに対して新たに選択されたモードを使用してページが自動的にリフレッシュされます。

次の例は、「Oracleデータベースのプロビジョニング」デプロイメント・プロシージャをカスタマイズして、「宛先ユーザー権限のチェック」フェーズのエラー処理モードを変更する様子です。

51.5 デプロイメント・プロシージャのステータスに関する電子メール通知の設定

Cloud Controlは、デプロイメント・プロシージャのステータスを報告するために電子メール通知を送信できます。ただし、デフォルトではデプロイメント・プロシージャのこの機能は有効ではありません。電子メール通知を送信するには、スーパー管理者がEnterprise Manager内で送信メール(SMTP)サーバーを構成する必要があります。その後、管理者が、通知を受信するための電子メール・アドレスとパスワードを指定する必要があります。

電子メール通知の有効化は次のような2段階のプロセスです。

- Enterprise Managerでの送信メール(SMTP)サーバーの構成

- Enterprise Manager通知用の電子メール・アドレスの追加

重要:
前提条件として、Cloud Controlでメール・サーバーを構成し、電子メール・アドレスを設定しておく必要があります。

51.5.1 Enterprise Managerでの送信メール(SMTP)サーバーの構成

Enterprise Managerが電子メール通知を送信するには、送信メール(SMTP)サーバーを設定しておく必要があります。

注意:
権限を持つユーザーのみがSMTPサーバーを構成できます。

SMTPサーバーを設定するには、次の手順を実行します。

1. Cloud Controlで、「設定」メニューから「通知」を選択し、「通知メソッド」を選択します。

2. 設定ページの「メール・サーバー」セクションで、1つ以上の送信メール・サーバーとオプションのポート番号を入力します(ポート番号を空白にしておくとデフォルトでポート25が使用されます)。

3. 「ユーザー名」、「パスワード」など、メール・サーバーの認証資格証明を入力します。「ユーザー名」フィールドと「パスワード」フィールドで、すべてのメール・サーバーに使用される1セットの認証資格証明を指定できます。メール・サーバーの認証が必要ない場合は、「ユーザー名」および「パスワード」(および「パスワードの確認」)フィールドをブランクのままにしておいてください。

4. 通知メッセージの送信者として表示する名前を「送信者ID」フィールドに入力します。

5. 電子メール通知の送信に使用する電子メール・アドレスを「送信者の電子メール・アドレス」に入力します。インシデント・ルールを使用する際、電子メールの送信に関する問題はすべて自動的に「送信者の電子メール・アドレス」に送信されます。

注意:
このページで指定する電子メール・アドレスは、通知の送信先の電子メール・アドレスではありません。この電子メール・アドレス(通知の送信先)は「プリファレンス」の「一般」ページで指定する必要があります。電子メール通知のために電子メール・アドレスを指定する方法については、第51.5.2項を参照してください。

6. 「セキュアな接続を使用」では、使用するSMTP暗号化方法を選択できます。次の3つのオプションがあります。

- いいえ: 電子メールが暗号化されません。

- SSL: 電子メールは、Secure Sockets Layerプロトコルで暗号化されます。

- 使用可能な場合はTLS: メール・サーバーがTransport Layer Security (TLS)プロトコルをサポートしている場合、電子メールはTLSを使用して暗号化されます。サーバーがTLSをサポートしない場合、電子メールは自動的にプレーン・テキストで送信されます。

次に例を示します。

次の例では、ポート587のsmtp01.example.comとポート25 (デフォルト・ポート)のsmtp02.example.comという、2つのメール・サーバーが指定されています。1つの管理者アカウント(myadmin)が両方のサーバーで使用されます。

送信メール(SMTP)サーバー: smtp01.example.com:587、smtp02.example.com

ユーザー名: myadmin

パスワード: ********

パスワードの確認: ********

送信者の識別: EMD Notifications

送信者の電子メール・アドレス: mgmt_rep@example.com

セキュアな接続を使用: SSL

51.5.2 Enterprise Manager通知用の電子メール・アドレスの追加

通知スケジュールを定義する場合、通知の送信先の電子メール・アドレスを1つ以上指定します。通知用電子メール・アドレスを定義する以外に、各電子メール・アドレスで使用される通知メッセージの書式(長いまたは短い)を関連付けます。

電子メール・アドレスは128文字以内で、必要な数だけ指定できます。

電子メール・アドレスを追加する手順は、次のとおりです。

1. Cloud Controlで、「設定」メニューから「通知」を選択し、「通知スケジュール」を選択します。

2. Enterprise Manager管理者を指定し、「スケジュールの定義」をクリックします。

3. 事前に電子メール・アドレスが管理者に定義されていない場合、管理者の電子メール・アドレスの定義を求めるメッセージが表示されます。「電子メール・アドレスを設定するにはここをクリックします。」をクリックします。「一般」ページが表示されます。

4. 「行の追加」をクリックすると、新規の電子メール項目が「電子メール・アドレス」表に作成されます。

5. Enterprise Managerアカウントに関連付けられた電子メール・アドレスを指定します。Enterprise Managerから受信するすべての電子メール通知が、指定した電子メール・アドレスに送信されます。たとえば、user1@example.comやuser2@example.comなどです。

6. 追加の電子メール・アドレスが必要な場合は、「行の追加」をクリックして、電子メール・アドレスを入力し、書式を選択します。

7. 電子メール・アドレスを選択し、「テスト」をクリックすることで、そのアドレスがEnterprise Managerからの電子メールを受信するように正しく構成されているかどうかを確認できます。

8. テストの終了後、「適用」をクリックして変更を保存します。

通知用電子メール・アドレスを定義すると、これらのアドレスは通知スケジュールを定義する際に表示されます。たとえば、user1@example.com、user2@example.com、user3@example.comです。これらの電子メール・アドレスの1つ以上を、インシデント・ルールの電子メール通知の送信先として使用するように選択できます。

51.6 カスタマイズしたプロビジョニング・エンティティをEnterprise Managerサイト間でコピー

Enterprise Managerインストール環境で、他のEnterprise Manager環境に適用したいプロビジョニング・バンドルをカスタマイズした場合には、次の手順を実行します。プロビジョニング・エンティティには、プロシージャ定義またはソフトウェア・ライブラリ・エンティティ、あるいはその組合せを含めることができます。

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

- カスタマイズしたプロビジョニング・エンティティをEnterprise Managerサイト間でコピーするための前提条件

- カスタマイズしたプロビジョニング・エンティティをEnterprise Managerサイト間でコピー

51.6.1 カスタマイズしたプロビジョニング・エンティティをEnterprise Managerサイト間でコピーするための前提条件

次の点を確認します。

- カスタムしたプロビジョニング・エンティティが、ソース・サイトのシステムにあること。

- ソース管理者が、カスタマイズしたプロビジョニング・エンティティにソース・サイトでアクセスできること。

- ソース管理者が、プロビジョニング・エンティティのエクスポートに必要な権限を持っていること。

- コピー先サイトがソース・サイトと同じように設定されており、両方に同じバージョンのEnterprise Managerがインストールされていること。

- コピー先の管理者は、プロビジョニング・エンティティのインポートに必要な権限を持っています。

51.6.2 カスタマイズしたプロビジョニング・エンティティをEnterprise Managerサイト間でコピー

次の手順に従います。

1. 次のコマンドでPARファイルをエクスポートします。

emctl partool export -guid <procedure guid> -file <file> -displayName <name> -description <desc> -metadataOnly(optional)

2. プロビジョニング・エンティティをインポートする場合には、次のようにしてemctl partoolを使用できます。

emctl partool <deploy|view> -parFile <file> -force(optional)
emctl partool <deploy|view> -parFile <file> -force(optional) -ssPasswd <password>
emctl partool <deploy|view> -parDir <dir> -force(optional)

3. あるいは、次の手順で説明するようにCloud ControlからPARファイルをインポートする方法もあります。

1. 「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. プロシージャ・ライブラリ・ページのリストで「インポート」を選択し、「実行」をクリックします。

4. プロシージャ・ファイルのアップロード・ページで、次のいずれかを選択します。

- ローカル・マシンからアップロード: PARファイルがローカル・マシンに格納されている場合。「参照」をクリックし、アップロードするPARファイルを選択します。「インポート」をクリックします。

- 管理エージェント・マシンからアップロード: PARファイルを管理エージェント・マシンに格納した場合。「ターゲット」をクリックし、ホストを選択します。「ファイルの選択」をクリックし、PARファイルを選択します。「インポート」をクリックします。

5. インポートしたエンティティを適用します。

51.7 ディレクティブをカスタマイズするためのワークフロー例

基本的にディレクティブはソフトウェア・ライブラリに格納されるスクリプトです。デプロイメント・プロシージャ内のディレクティブ・ステップという特別なタイプのアクション・ステップで使用されます。ディレクティブ・ステップを追加する手順の詳細は、「ディレクティブ・ステップの追加」を参照してください。

Cloud Controlで提供されるディレクティブをカスタマイズする場合は、まず、そのディレクティブに関連付けられているPerlスクリプトのコピーを作成し、そのコピーから新しいディレクティブを作成します。次に、デプロイメント・プロシージャをカスタマイズして、この新しいディレクティブを使用するステップを変更し、デプロイメントをスケジュールします。この項の内容は次のとおりです。

- デフォルト・ディレクティブのコピーの作成とアップロード

- 新しいディレクティブを使用するデプロイメント・プロシージャのカスタマイズ

- カスタマイズされたデプロイメント・プロシージャの実行

51.7.1 デフォルト・ディレクティブのコピーの作成とアップロード

デフォルト・ディレクティブを使用してカスタマイズしたディレクティブを新たに作成するには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」を選択します。

2. ソフトウェア・ライブラリ・ページの表で、ソフトウェア・ライブラリを展開し、そのカテゴリの下のレベルをさらに展開して、コピーするディレクティブを表示します。
たとえば、パッチ適用操作の「パッチの適用」ディレクティブをコピーする場合は、「ソフトウェア・ライブラリ」を展開してから「パッチ適用」を展開します。このレベルで、「共通」、「すべて」、最後に「汎用」を展開します。「汎用」の下にディレクティブ「パッチの適用」が表示されます。

3. コピーするディレクティブを選択して「類似作成」をクリックし、このディレクティブのコピーをカスタム・フォルダ「ディレクティブ」に格納します。

4. このカスタム・ディレクティブを選択し、「編集」をクリックします。

5. ディレクティブの作成ウィザードで、次の手順を実行します。

1. 説明ページに、作成するディレクティブの説明を入力します。

2. 構成ページで、「追加」をクリックして、コマンドライン引数がディレクティブに渡されるように指定します。Perlスクリプトを追加するため、「シェル・タイプ」は「Perl」に設定します。スクリプトがPerlでもBashでもない場合は、「スクリプトで定義」に設定します。
各エントリは1つのコマンドライン引数を表します。各引数に含まれる変数には、後で設定するもの、接頭辞および接尾辞があります。接頭辞と接尾辞のテキストが、プロパティ値の前や後に付加されて、コマンドライン引数になります。

このステップを繰り返して、すべてのコマンドライン引数を追加します。

3. ファイルの選択ページで「ファイルのアップロード」を選択します。ソースの指定セクションで「ローカル・マシン」を選択し、「追加」をクリックして、変更したperlファイルを選択します。

4. 「保存とアップロード」をクリックします。

51.7.2 新しいディレクティブを使用するデプロイメント・プロシージャのカスタマイズ

新しいディレクティブを使用するようにデプロイメント・プロシージャをカスタマイズするには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. プロビジョニング・ページで、この新しいディレクティブを使用するデプロイメント・プロシージャを選択して、「類似作成」をクリックします。

3. 類似作成プロシージャ・ページで「プロシージャ・ステップ」タブを選択し、次の手順を実行します。

1. このデプロイメント・プロシージャ内のすべてのステップが含まれる表で、新しいディレクティブを関連付けるディレクティブ・ステップを選択し、「ステップの編集」をクリックします。

2. ディレクティブ・ステップの編集ウィザードで次の手順を実行します。

1. 編集ページで「次へ」をクリックします。

2. ディレクティブの選択ページで「新規ディレクティブの選択」を選択します。次に、作成した新しいディレクティブを検索して選択し、「次へ」をクリックします。

3. プロパティのマップ・ページで、ディレクティブ・プロパティの値を指定し、「次へ」をクリックします。

4. 確認ページで「終了」をクリックします。

3. 「保存」をクリックします。

51.7.3 カスタマイズされたデプロイメント・プロシージャの実行

カスタマイズされたデプロイメント・プロシージャを実行するには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. プロビジョニング・ページで、カスタマイズされたデプロイメント・プロシージャを選択して、「デプロイメントのスケジュール」をクリックします。

第XII部

追加情報

この部は、次の付録で構成されています。

- 付録A「Enterprise Managerコマンドライン・インタフェースの使用」

- 付録B「プロビジョニング前またはパッチ適用前のホスト準備状況のチェック」

- 付録C「emctl partoolユーティリティの使用」

- 付録D「PXEブートおよびKickstartテクノロジについて」

- 付録F「問題のトラブルシューティング」

A Enterprise Managerコマンドライン・インタフェースの使用

ここでは、Enterprise Managerコマンドライン・インタフェース(EM CLI)を使用して、パッチ計画を使用するパッチのデプロイ、プロシージャのプロビジョニング、および一部のソフトウェア・ライブラリ・タスクの実行を行う方法について説明します。

注意:
Enterprise Manager 12cの動詞の使用方法、構文および例は、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。

この章の具体的な内容は次のとおりです。

- 概要

- 前提条件

- Enterprise Managerコマンドライン・インタフェース動詞

- EM CLIを使用するプロビジョニング

- EM CLIを使用するパッチ適用

- EM CLIコマンドを使用するワークフローの例

- Enterprise Managerコマンドライン・インタフェースの使用に関する制限事項

注意:
様々なデプロイメント・プロシージャを実行するためのEM CLIの実装は、Oracle Enterprise Manager Cloud Control (Cloud Control)で全体的に改良されています。

A.1 概要

Enterprise Managerコマンドライン・インタフェース(EM CLI)は、Oracle Enterprise Manager Cloud Control (Cloud Control)の上級ユーザー向けのコマンドライン・ユーティリティで、コンソールでの操作のほとんどを実行することができます。各種オペレーティング・システムのテキストベースのコンソール(シェルおよびコマンド・ウィンドウ)からCloud Control機能にアクセスできます。

EM CLIを使用すると、次のことが可能です。

- ターゲットとジョブの監視や管理、デプロイメント・プロシージャの実行、Enterprise Managerターゲットへのパッチ適用など、様々なコマンドライン操作を実行できます。

- EM CLIの動詞という機能を使用して、オペレーティング・システム・シェル、Perl、Pythonなど、様々なプログラミング環境でカスタム・スクリプトを構築できます。これにより、Oracle Enterprise Managerの機能を自社のビジネス・プロセスと密接に統合することができます。

- Cloud Controlコンソールと同等のセキュリティと機密性で、操作を実行できます。

A.2 前提条件

EM CLIを使用する前に、次の要件を満たしていることを確認してください。

- EM CLIクライアントを設定する必要があります。このためには、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。

- デプロイメント・プロシージャに提供されるターゲットは、Enterprise Management 12c管理エージェントで管理されている必要があります。

- インターネット接続がないオフライン・モードでパッチを適用する場合は、EM CLIコマンドを実行する前に、ソフトウェア・ライブラリでパッチを使用できることを確認します。

A.3 Enterprise Managerコマンドライン・インタフェース動詞

この項では主として、様々なパッチとプロビジョニングのタスクを実行する際に使用するEM CLI動詞をすべてリストします。大きくわけて次の内容があります。

- プロビジョニングのEM CLI動詞

- パッチ適用のEM CLI動詞

- ソフトウェア・ライブラリのEM CLI動詞

A.3.1 プロビジョニングのEM CLI動詞

ここでは、Enterprise Manager 12cでデプロイメント・プロシージャを実行するときのEM CLI動詞の使用方法を説明します。

- 新しいEnterprise Managerコマンドライン・インタフェース動詞

- 不要なEnterprise Managerコマンドライン・インタフェース動詞

- プロシージャを実行するEnterprise Managerコマンドライン・インタフェース動詞

A.3.1.1 新しいEnterprise Managerコマンドライン・インタフェース動詞

Cloud Controlに導入された新しいEM CLI動詞は次のとおりです。

- describe_procedure_input

- save_procedure_input

- update_procedure_input

- get_executions

- get_instance_data (replaces get_instance_data_xml)

Enterprise Manager 12cに追加された引数に対応するように変更されたEM CLI動詞は、submit_procedureです。次の表では、submit_procedure動詞が対応する以前の引数と現在の引数を比較しています。

submit_procedureの引数(EM 11g)

submit_procedureの引数(EM 12c)

emcli submit_procedure
-procedure='guid of the procedure'
-input_file="data:file_path"
[-instance_name="name of the procedure instance"]
[-schedule=start_time:yyyy/MM/dd HH:mm;tz:{java timezone ID}]

emcli submit_procedure
[-name={name of the procedure}]
[-owner={owner of the procedure}]
[-procedure={guid of the procedure}]
-input_file={data:{file_path}/file name}
[-instance_name={name of the procedure instance}]
[-notifications={procedure status}]
[-grants={users and their corresponding accessing levels}]
[-schedule=start_time:yyyy/MM/dd HH:mm;tz:{java timezone ID}]

注意: 新しい引数はすべて太字で示しています。

プロシージャの発行は、プロシージャGUIDを使用しないとできませんでした。

Enterprise Manager 12c以降では、プロシージャGUIDを使用してもプロシージャ名/所有者のペアを使用してもプロシージャを発行できます。

A.3.1.2 不要なEnterprise Managerコマンドライン・インタフェース動詞

次のEM CLI動詞は下位互換性を保つために含まれていますが非推奨です。新しいコマンドの使用をお薦めします。

- get_instance_data_xml

- set_instance_jobgrants

注意:
Enterprise Manager 11gの動詞の詳細は、次のドキュメント・ライブラリにある『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。
http://www.oracle.com/pls/em111/docindex

A.3.1.3 プロシージャを実行するEnterprise Managerコマンドライン・インタフェース動詞

次のリストは、デプロイメント・プロシージャを実行するために使用されるすべてのEM CLI動詞です。

表A-1 EM CLIのプロビジョニング動詞とその使用方法

動詞

使用方法

例

confirm_instance

emcli confirm_instance [-instance={instance guid}] [-exec={execution guid}] -stateguid={state guid}

emcli confirm_instance -instance=234RTGHJ096YHN5KM2IKJM567 -stateguid=56IUJMN029IJ3ERFG09IKJ

describe_procedure_input

emcli describe_procedure_input [-procedure={procedure GUID}] [-name={procedure name or procedure configuration}] [-owner={owner of the procedure or procedure configuration}] [-parent_proc={procedure of the procedure configuration. this only applies to describe a procedure configuration with the same name}]

emcli get_procedure_xml -procedure=16B15CB29C3F9E6CE040578C96093F61 > proc.properties

delete_instance

emcli delete_instance [-instance={instance guid}] [-exec={execution guid}]

emcli delete_instance -instance=234RTGHJ096YHN5KM2IKJM567

get_executions

emcli get_executions -instance={instance GUID}

emcli get_exections -instance=16B15CB29C3F9E6CE040578C96093F61

get_instances

emcli get_instances [-type={procedure type}]

emcli get_instances -type=DemoNG

get_instance_data

emcli get_instance_data [-instance={instance guid}] [-exec=execution guid]

emcli get_instance_data -instance=16B15CB29C3F9E6CE040578C96093F61 > instanceData.properties

get_instance_status

emcli get_instance_status [-instance={instance guid}] [-exec=execution guid] [-xml [-details] [-showJobOutput] [-tailLength={last N characters}]]]

emcli get_instance_status -instance=1TYUIOPLKMUHKJANGS09OIJ -xml -details -showJobOutput

get_retry_argument

emcli get_retry_arguments [-instance={instance guid}] [-exec=execution guid] [-stateguid={state guid}]

emcli get_retry_argument -instance=16B15CB29C3F9E6CE040578C96093F61 -stateguid=4IUOHNAG29KLNLOKJGA

get_procedures

emcli get_procedures [-type={procedure type}] [-parent_proc={procedure associate with procedure configuration}]

emcli get_procedures -type=DemoNG -parent_proc=ComputeStepTest

get_procedure_xml

emcli get_procedure_xml [-procedure={procedure guid}] [-name={procedure name}] [-owner={procedure owner}]

emcli get_procedure_xml -procedure=16B15CB29C3F9E6CE040578C96093F61 > proc.xml

get_procedure_types

emcli get_procedure_types

emcli get_procedure_types

ignore_instance

emcli ignore_instance [-instance={instance guid}] [-exec=execution guid] [-stateguid={state guid}]

emcli get_retry_argument -instance=16B15CB29C3F9E6CE040578C96093F61 -stateguid=4IUOHNAG29KLNLOKJGA,29C3F9E6CE040578C96093F61KNALK

reschedule_instance

emcli reschedule_instance [-instance={instance guid}] [-exec=execution guid] -schedule=start_time:yyyy/MM/dd HH:mm;tz:{java timezone id};

emcli reschedule_instance -instance=1TYUIOPLKMUHKJANGS09OIJ -schedule="start_time:2012/12/25 00:00;tz:American/New York;grace_period:60"

resume_instance

emcli resume_instance [-instance={instance guid}] [-exec=execution guid]

emcli resume_instance -instance=1TYUIOPLKMUHKJANGS09OIJ

save_procedure

emcli save_procedure_input -name={name of procedure configuration} -procedure={Procedure name} [-owner={owner of procedure}]- input_file=data:/file path/file name [-grants={users and their corresponding accessing levels}] [-notification={procedure status}] [-schedule=start_time:yyyy/MM/dd HH:mm;tz:{java timezone id};grace_period:xxx]

emcli save_procedure_input -name=procConfiguration -procedure=ComputeStepTest -input_file=data:/home/data.properties -grants="user1:VIEW_JOB;

user2:FULL_JOB" -notification="sheduled, action required, running" -schedule="start_time:2012/12/25 00:00;tz:American/New York;grace_period:60"

stop_instance

emcli stop_instance [-instance={instance guid}] [-exec=execution guid]

emcli stop_instance -instance=1TYUIOPLKMUHKJANGS09OIJ

submit_procedure

emcli submit_procedure [-name={name of the procedure}] [-owner={owner of the procedure}] [-procedure={guid of the procedure}] -input_file={data:{file_path}/file name" [-instance_name={name for the procedure instance}] [-notification={procedure status}] [-grants={users and their corresponding accessing levels}] [-schedule=start_time:yyyy/MM/dd HH:mm; tz:{java timezone ID}]

emcli submit_procedure -input_file=data:data.xml -procedure=16B15CB29C3F9E6CE040578C96093F61 -schedule="start_time:2006/6/21 21:23; tz:America/New_York" -grants="user1:VIEW_JOB; user2:FULL_JOB" -notification="sheduled, action required, running"

suspend_instance

emcli stop_instance [-instance={instance guid}] [-exec=execution guid]

emcli suspend_instance -instance=1TYUIOPLKMUHKJANGS09OIJ

update_and_retry_step

emcli update_and_retry_step [-instance={instance guid}] [-exec=execution guid] [-stateguid={stateguid1, stateguid2, ...}] [-args="command1:value1;command2:value2;...]

emcli get_retry_argument -instance=16B15CB29C3F9E6CE040578C96093F61 -stateguid="4IUOHNAG29KLNLOKJGA,PO82NLKBSAKBNIUPOQTG" -args="command1:a; command2:b"

update_procedure_input

emcli update_procedure_input -name={name of procedure configuration} -input_file="data:/file path/file name" [-notification={procedure status}][-grants={users and their corresponding accessing levels}] [-schedule=start_time:yyyy/MM/dd HH:mm;tz:{java timezone id};grace_period:xxx]

emcli update_procedure_input -name=procConfiguration -input_file=data:/home/data.properties -grants="user1:VIEW_JOB;user2:FULL_JOB"

-notification="sheduled, action required, running" -schedule="start_time:2012/12/25 00:00;tz:American/New York;grace_period:60"

switch_swlib_oms_agent_storage

emcli switch_swlib_oms_agent_storage -name="location_name"-host="hostname" [-credential_set_name="setname"] | [-credential_name="name" -credential_owner="owner"]

emcli switch_swlib_oms_agent_storage -name="myOMSAgtLocation" -host="fs1.us.example.com" -credential_name="MyAcmeCreds" -credential_owner="ACME_USER"

OMSエージェント・ファイルシステム記憶域の場所(myOMSAgtLocation)を変更し、指定したホスト(fs1.us.example.comおよびACME_USER)が所有する資格証明(MyAcmeCreds)を使用して、この場所との間でファイルの読取り/書込みを行います。

verify_swlib

emcli verify_swlib [-report_type="storage|entity|uploadjobs|all"]

emcli verify_swlib -report_type="all"

ストレージを生成して、ジョブおよびエンティティの検証レポートをアップロードします。

A.3.2 パッチ適用のEM CLI動詞

コマンドライン・インタフェースを使用して、1つの同じパッチ計画から任意の数のターゲットにパッチを適用できるようになりました。パッチ適用に使用される重要なEM CLI動詞の一部を次に示します。

表A-2 EM CLIのパッチ適用動詞とその使用方法

動詞

使用方法

例

create_patch_plan

emcli create_patch_plan -name="name" -input_file=data:"file_path" [-impact_other_targets="add_all | add_original_only | cancel"][-problems_assoc_patches="ignore_all_warnings | cancel"]

emcli create_patch_plan -name="plan name" -input_file=data:"/tmp/patchplan.pros" -impact_other_targets="add_all"

describe_patch_plan_input

emcli describe_patch_plan_input -name="name"

emcli describe_patch_plan_input -name="plan_name"

get_patch_plan_data

emcli get_patch_plan_data -name="name"

emcli get_patch_plan_data -name="plan_name"

set_patch_plan_data

emcli set_patch_plan_data-name="name"[-impact_other_targets =" add_all | add_original_only | cancel"][-problems_assoc_patches =" ignore_all_warnings | cancel"]

emcli set_patch_plan_data -name="plan name" -input_file=data:"/tmp/patchplan.pros" -impact_other_targets="add_all"

list_aru_languages

emcli list_aru_languages [-name="language name" | -id="language id"] [-noheader] [-script | -format= [name:<pretty|script|csv>]; [column_separator:"column_sep_string"]; [row_separator:"row_sep_string"];]

emcli list_aru_languages -noheader

list_aru_platforms

emcli list_aru_platforms [-name="platform name" | -id="platform id"] [-noheader] [-script | -format= [name:<pretty|script|csv>]; [column_separator:"column_sep_string"]; [row_separator:"row_sep_string"];]

emcli list_aru_platforms -noheader

list_aru_products

emcli list_aru_products [-name="product name" | -id="product id"] [-noheader] [-script | -format= [name:<pretty|script|csv>]; [column_separator:"column_sep_string"]; [row_separator:"row_sep_string"]; ]

emcli list_aru_products -id="product id"

list_aru_releases

emcli list_aru_releases [-name="release name" | -id="release id" | -productId="product id"] [-noheader] [-script | -format= [name:<pretty|script|csv>]; [column_separator:"column_sep_string"]; [row_separator:"row_sep_string"];]

emcli list_aru_releases -noheader

list_patch_plans

emcli list_patch_plans -name="name" [-noheader] [-script | -format= [name:<pretty|script|csv>]; [column_separator:"column_sep_string"]; [row_separator:"row_sep_string"];]

emcli list_patch_plans -name="plan name" -noheader

search_patches

emcli search_patches [-swlib] [-patch_name="patch_name"] [-product="product id" [-include_all_products_in_family]] [-release="release id"] [-platform="platform id" | -language="language id"] [-type="patch | patchset"] [-noheader] [-script | -xml | -format= [name:<pretty|script|csv>]; [column_separator:"column_sep_string"]; [row_separator:"row_sep_string"];]

emcli search_patches -patch_name="patch number" -platform="platform id"

get_connection_mode

emcli get_connection_mode

emcli get_connection_mode

set_connection_mode

emcli set_connection_mode -mode="online | offline"

emcli set_connection_mode -mode="offline"

show_patch_plan

emcli show_patch_plan -name="name" [-info [-showPrivs]] [-actions [-onlyShowEnabled]] [-patches] [-targets] [-deplOptions] [-analysisResults][-conflictFree][-impactedTargets][-deploymentProcedures]

emcli show_patch_plan -name="plan name" -info -showPrivs

submit_patch_plan

emcli submit_patch_plan -name="name" -action="action name"

emcli submit_patch_plan -name="plan name" -action="analyze"

get_targets

emcli get_targets [-targets="[name1:]type1;[name2:]type2;..."] [-alerts][-noheader][-script | -format=[name:<pretty|script|csv>];[column_separator:"column_sep_string"];[row_separator:"row_sep_string"];]

emcli get_targets -targets="databa%:%oracle%"

get_instance_status

emcli get_instance_status [-instance={instance_guid}] [-exec={execution_guid}] [-name={execution name}] [-owner={execution owner}] [-xml [-details]

emcli get_instance_status -instance=16B15CB29C3F9E6CE040578C96093F61 -xml -showJobOutput -tailLength=1024

get_job_execution_detail

emcli get_job_execution_detail -execution={execution_id}[-xml [-showOutput [-tailLength={length}]]]

emcli get_job_execution_detail -execution=12345678901234567890123456789012 -xml

create_named_credential

emcli create_named_credential -cred_name=<name> -auth_target_type=<authenticating target type> -cred_type=<Credential type> -cred_scope=<Credential Scope> -cred_desc=<Credential Description> -target_name=<target name> -target_type=<target type> -input_file=<tag:value> -input_bfile=<tag:value> -properties_file=<filename> -attributes=<p1:v1;p2:v2;...>

emcli create_named_credential-cred_name=NC1 -auth_target_type=host-cred_type=HostCreds -attributes="HostUserName:foo;HostPassword:"

get_named_credential

emcli get_named_credential -cred_owner=<owner> -cred_name=<name>-out=<filename>

emcli get_named_credential -cred_name=NC1

set_preferred_credential

emcli set_preferred_credential -set_name="set_name" -target_name="target_name" -target_type="ttype" -credential_name="cred_name" [-credential_owner ="owner]"

emcli set_preferred_credential -target_type=oracle_database -target_name=myDB -set_name=DBCredsSYSDBA -credential_name=MyDBCredentials -credential_owner="Joe"

show_credential_set_info

emcli show_credential_type_info [-target_type="target_type"] [-type_name="credential_type_name"]

emcli show_credential_type_info -target_type=oracle_database

setup

emcli setup - url="http[s]://host:port/em/" [-username=<EM Console Username]> [-password=<EM Console Password>][-licans=YES|NO][-dir=<local emcli configuration directory>][-trustall][-novalidate][-noautologin][-custom_attrib_file=<Custom attribute file path>][-nocertvalidate]

emcli setup -url=https://dadvmi0128.us.example.com:4473/em -username=sysman -password=sysman

upload_patches

emcli upload_patches -from_host="host name" -patch_files="metadata file path;ZIP file path" [-cred_name="name" -cred_owner="owner"]

emcli upload_patches -patch_files="/scratch/p13741363_112310_Linux-x86-64_M.xml;/scratch/p13741363_112310_Linux-x86-64.zip" -from_host=abc.example.com

delete_patches

emcli delete_patches -patch_name="patch name" -release="release id" -platform= "platform id"

emcli delete_patches -patch_name=13741363 -release=80112310 -platform=226

A.3.3 ソフトウェア・ライブラリのEM CLI動詞

Oracle Enterprise Manager Cloud Control 12cリリース2 (12.1.0.2)では、ソフトウェア・ライブラリの構成、エンティティの作成、それらの使用がサポートされるようになりました。

注意:
Enterprise Manager UIかコマンドライン・ユーティリティ(EM CLI)を使用して、フォルダIDとエンティティ・リビジョンIDを取得できます。その方法と、EM CLI動詞を効率的に使用して次の表にリストされている多くのソフトウェア・ライブラリ・タスクを実行する方法については、第A.6.5項でワークフローの例を参照してください。

ソフトウェア・ライブラリのアクションの実行に使用される重要なEM CLI動詞の一部を次に示します。

表A-3 ソフトウェア・ライブラリのEM CLI動詞とその使用方法

動詞

使用方法

例

add_swlib_storage_location

(ソフトウェア・ライブラリ・ストレージの場所の追加)

emcli add_swlib_storage_location -name="location_name" -path="location_path" [-type="OmsShared|OmsAgent|Http|Nfs|ExtAgent"] [-host="hostname"] [-credential_set_name="setname"] | [-credential_name="name" -credential_owner="owner"]

emcli add_swlib_storage_location -name="myOMSAgtLocation" -path="/u01/swlib" -type="OmsAgent"-host="fs1.us.example.com" -credential_name="MyexampleCreds" -credential_owner="example_USER"

create_swlib_folder

(ソフトウェア・ライブラリ・フォルダの作成)

emcli create_swlib_folder -name="folder_name" -parent_id="parent folder id" [-desc="folder description"]

emcli create_swlib_folder -name="myFolder" -parent_id="oracle:defaultService:em:provisioning:1:cat:B13B3B7B086458CFE040E80A19AA560C" -desc="myFolder description"

create_swlib_entity

(ソフトウェア・ライブラリ・エンティティの作成)

emcli create_swlib_entity -name="entity_name" -folder_id="folder_id" [-type]="type internal id"] [-subtype]="subtype internal id"] [-desc="entity_desc"] [-attr="<attr name>:<attr value>"] [-prop="<prop name>:<prop value>"] [-secret_prop="<secret prop name>:<secret prop value>"] [-note="note text"]

emcli create_swlib_entity -name="myexampleInstall" -folder_id="oracle:defaultService:em:provisioning:1:cat:B13B3B7B086458CFE040E80A19AA560C" -desc="myexampleInstall description" -attr="PRODUCT:example" -attr="PRODUCT_VERSION:3.0" -attr="VENDOR:example Corp" -prop="DEFAULT_HOME:/u01/example3/" -note="myexampleInstall for test servers"

list_swlib_entities

(ソフトウェア・ライブラリ・エンティティのリスト)

emcli list_swlib_entities [-name="entity_name"] [-folder_id="folder internal id"] [-desc="entity_desc"] [-attr="<attr name>:<attr value>"] [-type]="type internal id"][-subtype]="subtype internal id"][-maturity]="maturity"][-owner]="owner"][-status]="status"][-show_folder_path] [-show_folder_id] [-show_entity_rev_id]

emcli list_swlib_entities -name="myEntity" -attr="PRODUCT=Oracle Database" -show_folder_id

list_swlib_entity_subtypes

(ソフトウェア・ライブラリ・エンティティ・サブタイプのリスト)

emcli list_swlib_entity_subtypes -entity_type_id="type internal name"] [-show_subtype_id]

emcli list_swlib_entity_subtypes -entity_type_id="COMP_Component" -show_type_id

list_swlib_entity_types

(ソフトウェア・ライブラリ・エンティティ・タイプのリスト)

emcli list_swlib_entity_types [-show_type_id]

emcli list_swlib_entity_types -show_type_id

list_swlib_folders

(ソフトウェア・ライブラリ・フォルダのリスト)

emcli list_swlib_folders[-parent_id="parent folder id"] [-show_folder_path][-show_folder_id]

emcli list_swlib_folders -parent_id="oracle:defaultService:em:provisioning:1:cat:B13B3B7B086458CFE040E80A19AA560C" -show_folder_id

list_swlib_storage_locations

(ソフトウェア・ライブラリ・ストレージの場所のリスト)

emcli list_swlib_storage_locations [-type="OmsShared|OmsAgent|Http|Nfs|ExtAgent"]

emcli list_swlib_storage_locations -type="OmsAgent"

refer_swlib_entity_files

(ソフトウェア・ライブラリ・エンティティからのファイルの参照)

emcli refer_swlib_entity_files -entity_rev_id="entity_rev_id" [-file="<relative file path>[;<new file name>]" | [-removefile="<existing file name>"] -refer_storage="<storage location name>;<storage type>" [-use_latest_revision]

emcli refer_swlib_entity_files -entity_rev_id="oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_Generic:B1B1880C6A8C62AAE040548C42832D14:0.1" -file="scripts/perl/script1.pl;new_script.pl" -removefile="ALL" -refer_storage="myScripts;Http" -use_latest_revision

reimport_swlib_metadata

(ソフトウェア・ライブラリ・メタデータの再インポート)

emcli reimport_swlib_metadata

emcli reimport_swlib_metadata

remove_swlib_storage_location

(ソフトウェア・ライブラリ・ストレージの場所の削除)

emcli remove_swlib_storage_location -name="src location name"-type="OmsShared|OmsAgent|Http|Nfs|ExtAgent" -migrate_to_loc="dest location name"[-migrate_to_type="OmsShared|OmsAgent|Http|Nfs|ExtAgent"]

emcli remove_swlib_storage_location -name="myOMSSharedLocation" -type="OmsShared"-migrate_to_loc="myNewAGTLocation" -migrate_to_type="OmsAgent"

update_swlib_entity

(ソフトウェア・ライブラリ・エンティティの変更)

emcli update_swlib_entity -entity_rev_id="entity_rev_id"[-desc="entity_desc"][-attr="<attr name>:<attr value>"][-prop="<prop name>:<prop value>"][-secret_prop="<secret prop name>:<secret prop value>"][-note="note text"] [-use_latest_revision]

emcli update_swlib_entity -entity_rev_id="oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_Generic:B1B1880C6A8C62AAE040548C4D14:0.1" -entity_desc="myexampleInstall description" -attr="PRODUCT:example" -attr="PRODUCT_VERSION:3.0" -attr="VENDOR:example Corp" -prop="DEFAULT_HOME:/u01/example3/" -note="myexampleInstall for test servers"

upload_swlib_entity_files

(ソフトウェア・ライブラリ・エンティティへのファイルのアップロード)

emcli upload_swlib_entity_files -entity_rev_id="entity_rev_id" -host="hostname" [-file="<abs file path>[;<new file name>]" | [-removefile="<existing file name>"] [-credential_set_name="setname"] | [-credential_name="name" -credential_owner="owner"] [-upload_storage="<storage location name>;<storage type>"][-use_latest_revision]

emcli upload_swlib_entity_files -entity_rev_id="oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_Generic:B1B1880C6A8C62AAE040548C42832D14:0.1" -file="/u01/example_downloads/file1.zip;newfile1.zip" -file="/u01/example_downloads/file2.zip" -removefile="ALL" -host="fs1.us.example.com" -credential_name="MyexampleCreds" -credential_owner="example_USER" -use_latest_revision

A.4 EM CLIを使用するプロビジョニング

デプロイメント・プロシージャは、EM CLIを使用してコマンドラインから実行するか、Cloud Control UIから実行できます。コマンドラインまたはGUIからプロシージャを起動する際には、一連の入力値を提供する必要があります。ただし、このような入力値を入力するモードはそれぞれのケースで異なります。デプロイメント・プロシージャをUIから実行するときは、ウィザードを使用して、プロシージャを実行するために必要なすべての入力値を入力できます。ただし、EM CLIでは入力値を入力するためにプロパティ・ファイルを使用します。プロパティ・ファイルは、デプロイメント・プロシージャを実行するために必要なすべての入力値を含むファイルです。この後で、プロパティ・ファイルを新規作成してプロシージャで使用する方法、すでに実行されたプロシージャのプロパティ・ファイルを使用する方法、デプロイメント・プロシージャを実行するためのプロパティ・ファイルと他の属性を使用してテンプレートを作成する方法を説明します。

注意:

- EM CLIを使用してデプロイメント・プロシージャを実行することにより、プラガブル・データベースをプロビジョニングすることはできません。EM CLIを使用したプラガブル・データベースのプロビジョニング方法の詳細は、第A.4.4項を参照してください。

- -swlib引数は、Oracle Database 9iリリース2のみのクローニングに使用します。それ以降のリリースに対して、この引数は使用しないでください。

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

- デプロイメント・プロシージャを発行するためのプロパティ・ファイルの作成

- すでに実行したデプロイメント・プロシージャのプロパティ・ファイルの使用

- 既存の保存プロシージャを使用するプロシージャの起動

- プラガブル・データベースのプロビジョニング

A.4.1 デプロイメント・プロシージャを発行するためのプロパティ・ファイルの作成

次の図は、テンプレート・プロパティ・ファイルを作成し、ファイルの値を更新してから、更新したプロパティ・ファイルを入力としてプロシージャを発行する手順を示します。

ステップ1: プロシージャ定義からのテンプレート・プロパティ・ファイルの作成

プロシージャをコマンドラインから正常に発行するために、選択したデプロイメント・プロシージャで必要なすべての詳細情報(変数名、ターゲット、資格証明など)をこのステップで指定します。プロパティ・ファイルの生成は次のように2段階で行います。

1. プロシージャのGUIDまたは名前を取得するために、次のコマンドを実行します。

emcli get_procedures
[-type={procedure type}]

Example:
./emcli get_procedures -type=DBPROV

Output:
B3FCE84B1ED96791E040578CD7810EC5, DBPROV, Prov_112_db_using_SH_locked_acc_without_env_shift_ssubbura11, Prov_112_db_using_SH_locked_acc_without_env_shift_ssubbura11, 1.0, SSUBBURA1, SIHA_SIDB_PROC
B35E10B1F430B4EEE040578CD78179DC, DBPROV, DBREPLAYCLIENTDP_NG, Provision Oracle Database Client, 6.1, ORACLE
B35E10B1F427B4EEE040578CD78179DC, DBPROV, SIHA_SIDB_PROC, Provision Oracle Database, 1.0, ORACLE

2. GUIDまたは名前を次のコマンドで使用して、テンプレート・プロパティ・ファイルを生成します。デプロイメント・プロシージャを最初に実行する場合、または更新するプロシージャの変数があまり多くない場合は、次のコマンドを使用します。

emcli describe_procedure_input
[-procedure={procedure GUID}]
[-name={procedure name or procedure configuration}]
[-owner={owner of the procedure or procedure configuration}][-parent_proc={procedure of the procedure configuration. this only applies to describe a procedure configuration with the same name}]

The following examples describe how to use the procedure GUID to generate the properties file template:

./emcli describe_procedure_input -procedure=B35E10B1F427B4EEE040578CD78179DC > procConfiguration.properties

EM CLI動詞では、デプロイメント・プロシージャまたはプロシージャ構成の入力データを名前/値ペアの形式(プロパティ・ファイル形式とも呼ばれる)で記述します。プロシージャの名前/値のファイル形式の利点は、柔軟性が高く、複数の宛先ターゲットを受け入れられることです。

ステップ2: プロパティ・ファイルへの新しい値の入力

任意のエディタを使用してプロパティ・ファイルを開き、名前に対して値を入力します。すべてのフィールドを更新したら、プロパティ・ファイルを保存して閉じます。

このステップの目的は、一般的な入力値をデフォルトとして設定したプロパティ・ファイルのライブラリを作成することです。こうしておくと、オペレータのミスが減少し、オペレータが入力すべき入力数も減少します。

For example, vi procConfiguration.properties

注意:
プロパティ・ファイルの例は、第A.6.1項または第A.6.2項を参照してください。

ステップ3: 更新済プロパティ・ファイルを入力とするプロシージャの発行

デプロイメント・プロシージャを実行するための正しい名前/値ペアを設定してプロパティ・ファイルが準備できると、EM CLI動詞submit_procedureを使用する必要があります。このコマンドは、編集したプロパティ・ファイルを入力として受け取ります。

emcli submit_procedure
[-name={name of the procedure}]
[-owner={owner of the procedure}]
[-procedure={guid of the procedure}]
-input_file={data:{file_path}/file name"  [-instance_name={name for the procedure instance}] [-notification={procedure status}]
[-grants={users and their corresponding accessing levels}]  [-schedule=start_time:yyyy/MM/dd HH:mm; tz:{java timezone ID}]

次の例のように、Cloud Control 12c以降では、プロシージャを発行するときにプロシージャGUIDを使用することも、プロシージャ名/所有者のペアを使用することもできます。

- プロシージャのGUIDを使用したプロパティ・ファイルの発行:

emcli submit_procedure -input_file=data:procConfiguration.properties -procedure=B35E10B1F427B4EEE040578CD78179DC -schedule="start_time:2006/6/21 21:23; tz:America/New_York" -grants="user1:VIEW_JOB; user2:FULL_JOB" -notification="scheduled, action required, running"

- プロシージャ名/所有者ペアを使用したプロパティ・ファイルの発行:

emcli submit_procedure -input_file=data:procConfiguration.properties -name=SIHA_SIDB_PROC -owner=sysman -schedule="start_time:2006/6/21 21:23; tz:America/New_York" -grants="user1:VIEW_JOB; user2:FULL_JOB" -notification="scheduled, action required, running"

出力:

Verifying parameters ...
B35E10B1F427B4EEE040578CD78179DC
Deployment procedure submitted successfully
Note: The instanceId is B35E10B1F427B4EEE040578CD78179F1

この動詞は非待機モードで機能します。つまり、実行のためにプロシージャを発行すると、完了を待機せずに終了します。この動詞の出力は、プロシージャの発行が成功したかどうか、またはエラーが生成されたかどうかを示します。正常に発行された場合は、出力としてインスタンスGUIDが表示されます。

ステップ4: プロシージャのステータスの確認

最後のステップでは、プロシージャの進捗とステータスを追跡できます。プロシージャ発行の動詞がデプロイメント・プロシージャの完了を待機しないため、これは特に重要です。

emcli get_instance_status
[-instance={instance guid}]
[-exec=execution guid]
[-xml
[-details]
[-showJobOutput]
[-tailLength={last N characters}]]]

Example:

emcli get_instance_status -instance=B35E10B1F427B4EEE040578CD78179F1 -details -showJobOutput

Output:
B35E10B1F427B4EEE040578CD78179F1, WEBLOGIC_WSM, DANS_SCALEUP_WSM12, FAILED

A.4.2 すでに実行したデプロイメント・プロシージャのプロパティ・ファイルの使用

次の図は、すでに実行されたデプロイメント・プロシージャのプロパティ・ファイルを取得し、ファイルの値を更新してから、更新済プロパティ・ファイルを入力としてプロシージャを発行する手順を示します。

既存の実行からのプロパティ・ファイルの取得

プロシージャをコマンドラインから正常に発行するために、選択したデプロイメント・プロシージャで必要なすべての入力値(変数名、ターゲット、資格証明など)をこのステップで指定します。プロパティ・ファイルの生成は次のように2段階で行います。

1. プロシージャのGUIDまたは名前を取得するために、次のコマンドを実行します。

emcli get_procedures
[-type={procedure type}]
[-parent_proc={procedure associate with procedure configuration}]

Example:
./emcli get_procedures -parent_proc=SIHA_SIDB_PROC

Output:
B3FCE84B1ED96791E040578CD7810EC5, DBPROV, Prov_112_db_using_SH_locked_acc_without_env_shift_ssubbura11, Prov_112_db_using_SH_locked_acc_without_env_shift_ssubbura11, 1.0, SSUBBURA1, SIHA_SIDB_PROC

2. GUIDを使用し、プロシージャのインスタンスIDを取得します。

emcli get_instances
[-type={procedure type}]

Example:
./emcli get_instances -type=DBPROV

Output:
B3FE0C8302EA4A4CE040578CD781133C, B3FE0C8302F64A4CE040578CD781133C, DBPROV, Prov_112_db_using_SH_locked_acc_without_env_shift_ssubbur, Failed
B3FE34D472C00AD9E040578CD781107B, B3FE34D472CC0AD9E040578CD781107B, DBPROV, Prov_112_db_using_SH_locked_acc_without_env_shift_ssubbura1, Failed

3. 次のコマンドでインスタンスIDを使用して、インスタンスの入力プロパティ・ファイルを取得します。

emcli get_instance_data
[-instance={instance guid}]
[-exec=execution guid]

The following examples describe how to use the procedure GUID to generate the properties file template:

emcli get_instance_data -instance=B3FE0C8302EA4A4CE040578CD781133C > instanceData.properties

ステップ2: プロパティ・ファイルの既存値の更新

このステップの目的は、プロパティ・ファイルの値の更新です(必要な場合)。これには、任意のエディタを使用してプロパティ・ファイルを開き、更新した値を名前に対して入力します。必要なフィールドを更新したら、プロパティ・ファイルを保存して閉じます。

Example:
vi instanceData.properties

ステップ3: 更新済プロパティ・ファイルを入力とするプロシージャの発行

コマンドラインからプロシージャを実行するには、EM CLI動詞submit_procedureを使用する必要があります。「ステップ3: 更新済プロパティ・ファイルを入力とするプロシージャの発行」を参照してください。

ステップ4: プロシージャのステータスの確認

プロシージャのステータスを確認するには、「ステップ4: プロシージャのステータスの確認」を参照してください。

A.4.3 既存の保存プロシージャを使用するプロシージャの起動

繰返し使用されるプロシージャは、プロパティ・ファイル、ジョブ権限、スケジュール、通知などと一緒に、一意の名前を付けて保存できます。この特別にパッケージ化したプロシージャは、必要な際にいつでも、一意の名前を使用して実行できます。これはプロシージャを何度も実行する必要があるときに非常に役立ち、時間と労力を大幅に節約できます。動詞emcli get_proceduresを実行すると、プロシージャ構成も含むすべてのプロシージャがフェッチされます。

既存のプロシージャ構成ファイルを使用してプロシージャをきどうするには、次の手順を実行します。

1. 動詞emcli get_proceduresを実行して、既存のプロシージャ構成ファイルをフェッチします。

2. 必要であればプロパティ・ファイルを更新します。

3. 更新したプロパティ・ファイルおよび他の属性(ジョブ権限、スケジュール、通知など)を含むプロシージャ構成を保存します。これを行うには、第A.4.3.1項を参照してください。

4. 「ステップ3: 更新済プロパティ・ファイルを入力とするプロシージャの発行」の説明に従って、プロシージャ構成ファイルを発行します。

注意:
update_procedure_input動詞を使用してプロシージャ構成を更新できます。第A.4.3.2項を参照してください。プロシージャ構成を更新した後で、ステップ4を実行して、プロシージャを再発行します。

5. プロシージャのステータスを確認するには、「ステップ4: プロシージャのステータスの確認」を参照してください。

A.4.3.1 プロシージャのプロシージャ構成の保存

プロシージャを実行するためにプロパティ・ファイルを繰返し使用する必要がある場合、プロパティ・ファイルと一緒にそのプロシージャを保存して、保存したプロシージャに名前を付けることをお薦めします。このプロシージャを同じプロパティ・ファイルを使用して実行するときは常に、名前を指定して保存済のプロシージャを実行できます。プロシージャを保存するには、次のコマンドを実行します。

emcli save_procedure_input -name={name of procedure configuration} -procedure={Procedure name}
[-owner={owner of procedure}]
-input_file=data:/file path/file name
[-grants={users and their corresponding accessing levels}] [-notification={procedure status}]
[-schedule=start_time:yyyy/MM/dd HH:mm;tz:{java timezone id};grace_period:xxx]

Example:
emcli save_procedure_input -name=procConfiguration -procedure=ComputeStepTest -input_file=data:/tmp/instanceData.properties -grants="user1:VIEW_JOB;
user2:FULL_JOB" -notification="scheduled, action required, running" -schedule="start_time:2012/12/25 00:00;tz:American/New York;grace_period:60"

A.4.3.2 プロシージャのプロシージャ構成の更新

保存したプロシージャの既存の値を更新するには、次のコマンドを実行します。

emcli update_procedure_input -name={name of procedure configuration} -input_file="data:/file path/file name"
[-notification={procedure status}]
[-grants={users and their corresponding accessing levels}]
[-schedule=start_time:yyyy/MM/dd HH:mm;tz:{java timezone id};grace_period:xxx]

Example:
emcli update_procedure_input -name=procConfiguration -input_file=data:/tmp/instanceData.properties -grants="user1:VIEW_JOB;user2:FULL_JOB"
-notification="scheduled, action required, running" -schedule="start_time:2012/12/25 00:00;tz:American/New York;grace_period:60"

A.4.4 プラガブル・データベースのプロビジョニング

この項では、EM CLIを使用したプラガブル・データベース(PDB)のプロビジョニング方法について説明します。次の項目が含まれます。

- 新規プラガブル・データベースの作成

- スナップショット・プロファイルを使用したプラガブル・データベースのプロビジョニング

- 非コンテナ・データベースのプラガブル・データベースとしての移行

- プラガブル・データベースの切断および削除

A.4.4.1 新規プラガブル・データベースの作成

EM CLIを使用して新しいPDBを作成するには、次の手順に従います。

1. 前提条件を満たします。
新しいPDBの作成の前提条件の詳細は、第17.3.1.1項を参照してください。切断されたPDBをプラグインすることによりPDBを作成する際の前提条件の詳細は、第17.3.2.1項を参照してください。既存のPDBをクローニングすることによりPDBを作成する際の前提条件の詳細は、第17.3.3.1項を参照してください。

2. OMSホストで次のコマンドを実行して、EM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<name_of_user> -password=<password>

3. 次のコマンドを実行して、動詞create_pluggable_databaseのヘルプ・ファイルを表示します。

$<OMS_HOME>/bin/emcli help create_pluggable_database

4. 動詞create_pluggable_databaseを実行します。

$<OMS_HOME>/bin/emcli create_pluggable_database
-cdbTargetName=<Specify the CDB target name for creating new PDB>
-cdbTargetType=<Specify the CDB target type - oracle_database, rac_database>
-cdbHostCreds=<Specify the host credentials on which the CDB target is located>
[-cdbTargetCreds=<Specify the credentials of container database on which the new PDB will be created.>]
-pdbName=<Specify a name for the new PDB>
[-numOfPdbs=<Specify the number of PDBs to be created>]
-sourceType=<Type of pdb to be created - DEFAULT, UNPLUGGED_PDB, CLONE, PROFILE>
[-sourceFromSWLIB=<If -sourceType is 'UNPLUGGED_PDB', specify if the dump location is SWLIB or not.>]
[-pdbTemplateInSWLIB=<If -sourceFromSWLIB, specify the URN of pdb template component in SWLIB.>]
[-sourcePDBTempStagingLocation=<If from SWLIB, specify fully qualified location for staging the source pdb dump temporarily>]
[-unpluggedPDBType=<If -sourceType is 'UNPLUGGED_PDB', specify pdb dump type -  ARCHIVE, RMAN, XML.>]
[-sourcePDBArchiveLocation=<If -unpluggedPDBType=ARCHIVE, this is fully qualified archive location>]
[-sourcePDBMetadataFile=<If -unpluggedPDBType=RMAN or XML, this is fully qualified path of the source PDB metadata file>]
[-sourcePDBDatabackup=<If -unpluggedPDBType=RMAN, this is fully qualified path of the source PDB datafile>]
[-sourcePDBName=<If -sourceType is 'CLONE', specify the name of an existing PDB which is a valid em target>]
[-sourceCDBCreds=<If -sourceType is 'CLONE', specify the credentials of container database on which the -sourcePDBName is present>]
[-pdbAdminCreds=<Name of pdb credentials with admin role>]
[-useOMF=<Specifies that the datafiles can be stored in OMF location>]
[-sameAsSource=<Specifies that the datafiles of new PDB can be stored in the same location as that of source CDB>]
[-newPDBFileLocation=<Specify the storage location for datafiles of the created PDB.>]
[-createAsClone=<If -sourceType is 'UNPLUGGED_PDB' and if 'createAsClone' is specified, the PDB will be created as clone.>]
[-lockAllUsers=<If -sourceType is 'UNPLUGGED_PDB' and if 'lockAllUsers' is specified, all PDB users of the new PDB will be locked.>]
[-noUserTablespace=<Specifies that the new DEFAULT PDB will not be created with USERS tablespace.>]
[-useSnapClone=<If -sourceType is 'CLONE', specifies that Snap Clone must be used for cloning the PDB.>]
[-sourceCDBHostCreds=<If -sourceType is 'CLONE' and -useSnapClone is specified, this specifies the host credentials for the source CDB.>]
[-mountPointPrefix=<If -sourceType is 'CLONE' and -useSnapClone is specified, this specifies the mount point prefix for the cloned volumes.>]
[-writableSpace=<If -sourceType is 'CLONE' and -useSnapClone is specified, this specifies the writable space, in GB, for the cloned volumes.>]
[-privHostCreds=<If -sourceType is 'CLONE' and -useSnapClone is specified, this specifies the privileged host credentials required to mount the cloned volumes at the specified locations.>]

たとえば、次のコマンドを実行して新しいPDBを作成できます。

$<OMS_HOME>/bin/emcli create_pluggable_database -cdbTargetName=database -cdbTargetType=oracle_database -pdbName=pdb -sourceType=UNPLUGGED_PDB -unpluggedPDBType=ARCHIVE  -sourcePDBArchiveLocation=/u01/app/oracle/product/12.1.0/dbhome_2/assistants/dbca/templates/a.tar.gz

emcli create_pluggable_database -cdbTargetName=database -cdbTargetType=oracle_database -cdbHostCreds=HOST_CREDS -cdbTargetCreds=CDB_SYS_CREDS -pdbName=pdb -sourceType=CLONE -sourcePDBName=source_pdb -sourceCDBCreds=CDB_SYS_CREDS -useSnapClone -srcCDBHostCreds=HOST_CREDS -mountPointPrefix=/oracle -writableSpace=1 -sourcePDBTempStagingLocation=/tmp -privHostCreds=ROOT_CREDS

A.4.4.2 スナップショット・プロファイルを使用したプラガブル・データベースのプロビジョニング

スナップ・クローン方法を使用してPDBのクローンを作成する場合、作成したスナップショットからスナップショット・プロファイルを作成して、ソフトウェア・ライブラリにスナップショット・プロファイルを保存し、後でスナップショット・プロファイルを使用してPDBをプロビジョニングできます。この方法を使用すると、各プロビジョニング操作時にソースPDBのスナップショットを作成する必要なく、ステーブルで標準化された最新のPDBを大量のホスト上にプロビジョニングできます。

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

- スナップショット・プロファイルを使用してプラガブル・データベースをプロビジョニングするための前提条件

- スナップショット・プロファイルを使用してプラガブル・データベースをプロビジョニングする手順

A.4.4.2.1 スナップショット・プロファイルを使用してプラガブル・データベースをプロビジョニングするための前提条件

スナップショット・プロファイルを使用してPDBをプロビジョニングする前に、次の前提条件を満たしていることを確認します。

- Oracle Databaseプラグイン用に12.1.0.6 Enterprise Manager以上のバージョンをシステムにダウンロードおよびデプロイする必要があります。

- スナップ・クローン方法(第17.3.3.1項を参照)を使用したPDBのクローニングの前提条件を満たす必要があります。

A.4.4.2.2 スナップショット・プロファイルを使用してプラガブル・データベースをプロビジョニングする手順

スナップショット・プロファイルを使用してPDBをプロビジョニングするには、次の手順に従います。

1. OMSホストで次のコマンドを実行して、EM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<name_of_user> -password=<password>

2. 次のコマンドを実行して、動詞create_pluggable_databaseのヘルプ・ファイルを表示します。

$<OMS_HOME>/bin/emcli help create_pluggable_database

3. 動詞create_pluggable_databaseを実行して、ソースPDBのスナップ・クローンとスナップショット・プロファイルを作成します(この際、-sourceTypeパラメータをCLONEとして指定し、-sourcePDBName、-sourceCDBCreds、-useSnapClone、-sourceCDBHostCreds、-mountPointPrefix、-writableSpace、-privHostCreds、-saveProfile、-profileNameおよび-profileLocationの各パラメータを指定します)。

$<OMS_HOME>/bin/emcli create_pluggable_database
-cdbTargetName=<Specify the CDB target name for creating new PDB>
-cdbTargetType=<Specify the CDB target type - oracle_database, rac_database>
-cdbHostCreds=<Specify the host credentials on which the CDB target is located>
-pdbName=<Specify a name for the new PDB>
-sourceType=CLONE
-sourcePDBName=<Specify the name of the existing PDB that you want to clone>
-sourceCDBCreds=<Specify the credentials of the CDB within which the source PDB is present>
-useSnapClone
-sourceCDBHostCreds=<Specify the host credentials for the source CDB.>
-mountPointPrefix=<Specify the mount point prefix for the cloned volumes.>
-writableSpace=<Specify the writable space, in GB, for the cloned volumes.>
-privHostCreds=<Specify the privileged host credentials required to mount the cloned volumes at the specified locations.>
-saveProfile
-profileName=<The name of the profile that you want to create>
-profileLocation=<The location in software library where you want to create the profile>
[-cdbTargetCreds=<Specify the credentials of container database on which the new PDB will be created.>]
[-numOfPdbs=<Specify the number of PDBs to be created>]
[-pdbAdminCreds=<Specify the PDB credentials having the admin role>]
[-useOMF=<Specifies that the datafiles can be stored in OMF location>]
[-sameAsSource=<Specifies that the datafiles of new PDB can be stored in the same location as that of source CDB>]
[-newPDBFileLocation=<Specify the storage location for datafiles of the created PDB.>]
[-noUserTablespace=<Specifies that the new DEFAULT PDB will not be created with USERS tablespace.>]

このコマンドは、スナップ・クローン機能を使用してソースPDBをクローニングし、ソースPDBのスナップショット・プロファイルを作成します。スナップショット・プロファイルは、ソフトウェア・ライブラリの指定した場所に格納されます。

4. -nameパラメータおよび-show_entity_rev_idパラメータを指定して動詞list_swlib_entitiesを実行し、作成したスナップショット・プロファイルのUniform Resource Name (URN)を取得します。

$<OMS_HOME>/bin/emcli list_swlib_entities
-name="<The name of the snapshot profile>"
-show_entity_rev_id

5. 動詞create_pluggable_databaseを実行し、作成したスナップショット・プロファイルを使用してPDBをプロビジョニングします。この際、-sourceTypeパラメータをPROFILEとして指定し、-profileURNパラメータを指定します。

$<OMS_HOME>/bin/emcli create_pluggable_database
-cdbTargetName=<Specify the CDB target name for creating new PDB>
-cdbTargetType=<Specify the CDB target type - oracle_database, rac_database>
-cdbHostCreds=<Specify the host credentials on which the CDB target is located>
-pdbName=<Specify a name for the new PDB>
-sourceType=PROFILE
-profileURN=<URN of the snapshot profile that you want to use to provision PDBs>
[-cdbTargetCreds=<Specify the credentials of container database on which the new PDB will be created.>]
[-numOfPdbs=<Specify the number of PDBs to be created>]
[-pdbAdminCreds=<Name of pdb credentials with admin role>]
[-useOMF=<Specifies that the datafiles can be stored in OMF location>]
[-sameAsSource=<Specifies that the datafiles of new PDB can be stored in the same location as that of source CDB>]
[-newPDBFileLocation=<Specify the storage location for datafiles of the created PDB.>]
[-noUserTablespace=<Specifies that the new DEFAULT PDB will not be created with USERS tablespace.>]

A.4.4.3 非コンテナ・データベースのプラガブル・データベースとしての移行

非コンテナ・データベース(CDB)をPDBとして移行するには、次の手順を実行します。

1. 前提条件を満たします。
非コンテナ・データベースをPDBとして移行する際の前提条件の詳細は、第17.3.4.1項を参照してください。

2. OMSホストで次のコマンドを実行して、EM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<name_of_user> -password=<password>

3. 次のコマンドを実行して、動詞migrate_noncdb_to_pdbのヘルプ・ファイルを表示します。

$<OMS_HOME>/bin/emcli help migrate_noncdb_to_pdb

4. 動詞migrate_noncdb_to_pdbを実行します。

$<OMS_HOME>/bin/emcli migrate_noncdb_to_pdb
-cdbTargetName=<EM CDB target into which the database will be added as PDB>
-cdbTargetType=<EM CDB target type (oracle_database|rac_database)>
-cdbDBCreds=<Named DB credentials of CDB user having sysdba privileges>
-cdbHostCreds=<Named host credentials for Oracle Home owner of CDB>
-migrationMethod=<Migration method to be used (DATAPUMP|PLUG_AS_PDB)>
-noncdbTargetName=<EM non-CDB target to be migrated>
-noncdbTargetType=<EM non-CDB target type (oracle_database|rac_database)>
-noncdbDBCreds=<Named DB credentials for non-CDB user having sysdba privileges>
-noncdbHostCreds=<Named host credentials for Oracle Home owner of non-CDB>
-pdbName=<Name of the PDB to be created on the CDB>
-pdbAdminName=<Username of the PDB administrator to be created>
-pdbAdminPassword=<Password for the PDB administrator>
[-exportDir=<Temporary file system location on the non-CDB host where the exported files will be stored>]
[-importDir=<Temporary file system location on the CDB host used to stage the migration metadata and/or datafiles>]
[-useOMF=<Use OMF for datafile location if CDB is OMF enabled (Y|N)>]
[-dataFilesLoc=<Location on the CDB host where datafiles for the newly created DB will be stored. Disk Group name in case of ASM>]
[-encryptionPwd=<Password to decrypt/encrypt datapump dump file. Mandatory if non-CDB contains encrypted tablespaces>]
[-cdbWalletPwd=<Wallet password of the CDB. Mandatory if non-CDB contains encrypted tablespaces>]
[-objectExistsAction=<Action to be taken when the exported object with same name is found on the newly created PDB (SKIP|REPLACE). Defaulted to SKIP>]
[-precheck=<Perform pre-requisite checks (YES|NO|ONLY). Defaulted to YES>]
[-ignoreWarnings=<Ignore the warnings from precheck (Y|N)>]

たとえば、次のコマンドを実行して非CDBをPDBとして移行できます。

$<OMS_HOME>/bin/emcli migrate_noncdb_to_pdb -migrationMethod=datapump -noncdbTargetName=NON_CDB_NAME -noncdbTargetType=oracle_database -noncdbHostCreds=NON_CDB_HOST_CREDS -noncdbDBCreds=NON_CDB_DB_CREDS -cdbTargetName=CDB_NAME -cdbTargetType=oracle_database -cdbHostCreds=CDB_HOST_CREDS -cdbDBCreds=CDB_DB_CREDS -pdbName=NEW_PDB -pdbAdminName=pdbAdmin -pdbAdminPassword=welcome -precheck=ONLY -ignoreWarnings

A.4.4.4 プラガブル・データベースの切断および削除

PDBを切断して削除するには、次の手順を実行します。

1. 前提条件を満たします。
PDBの切断および削除の前提条件の詳細は、第17.4.1.1項を参照してください。

2. OMSホストで次のコマンドを実行して、EM CLIにログインします。

$<OMS_HOME>/bin/emcli login -username=<name_of_user> -password=<password>

3. 次のコマンドを実行して、動詞unplug_pluggable_databaseのヘルプ・ファイルを表示します。

$<OMS_HOME>/bin/emcli help unplug_pluggable_database

4. 動詞unplug_pluggable_databaseを実行します。

$<OMS_HOME>/bin/emcli unplug_pluggable_database
-cdbTargetName=<Specify the CDB target name from which PDB needs to be unplugged>
-cdbTargetType=<Specify the CDB target type - oracle_database, rac_database>
-cdbHostCreds=<Specify the host credentials on which the CDB target is located>
-cdbTargetCreds=<Specify the credentials of container database on which the PDB will be unplugged.>
-pdbName=<Specify name of the PDB that needs to be unplugged>
[-unplugPDBToSWLIB=<Specifies that unplugged PDB should be uploaded to Software Library (SWLIB)>]
[-pdbTemplateNameInSWLIB=<If -unplugPDBToSWLIB, specify the name to be used for PDB Template component in SWLIB.>]
[-tempStagingLocation=<If -unplugPDBToSWLIB, specify a temporary working directory for copying staging SWLIB files.>]
-unplugPDBTemplateType=<Specify the PDB template type -  ARCHIVE, RMAN, XML.>
[-pdbArchiveLocation=<If -unplugPDBTemplateType=ARCHIVE, this is fully qualified archive location with file name>]
[-pdbMetadataFile=<If -unplugPDBTemplateType=RMAN or XML, this is fully qualified path for the PDB metadata file>]
[-pdbDatabackup=<If -unplugPDBTemplateType=RMAN, this is fully qualified path for the PDB datafile backup>]

たとえば、次のコマンドを実行してPDBを切断および削除できます。

$<OMS_HOME>/bin/emcli unplug_pluggable_database -cdbTargetName=db -cdbTargetType=oracle_database -cdbHostCreds=HOST_CREDS -cdbTargetCreds=CDB_CREDS -pdbName=db_pdb -unplugPDBTemplateType=ARCHIVE -pdbArchiveLocation=/u01/app/unplugged/db_pdb.tar.gz

A.5 EM CLIを使用するパッチ適用

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

- パッチ適用を開始する前に

- EM CLIを使用するパッチ適用

A.5.1 パッチ適用を開始する前に

EM CLIを使用してターゲットにパッチを適用する前に、次の点に注意してください。

1. ターゲット名、ターゲット・タイプ、ターゲット・バージョン、リリース番号、プラットフォーム、製品などのターゲット情報を用意してあること。

2. パッチ名(パッチ番号)、リリースID、プラットフォームID、言語IDなどのパッチ情報を用意してあること。

3. パッチ適用プロセスを開始する前に、ターゲット・ホスト・マシンのOracleホームで次のいずれかの資格証明を設定します。

- Oracleホームの名前付き資格証明

- Oracleホームの名前付き特権資格証明

4. Oracleアカウントまたはrootアカウントへのアクセス権(ユーザー名/パスワード)がない場合には、SudoまたはPowerBrokerを通じて権限委任を設定し、ホスト・ターゲットにテンプレートを適用します。

5. パッチを適用する前に次のいずれかのモードを設定します。

- オンライン・モード: このモードはインターネット接続があるときに役立ちます。ただし、My Oracle Supportからパッチを検索してダウンロードするには、My Oracle Supportの優先資格証明を設定する必要があります。

- オフライン・モード: このモードは、すでにパッチをソフトウェア・ライブラリにダウンロードしている場合のパッチ適用に使用できます。この場合は、ソフトウェア・ライブラリで検索できます。

A.5.2 EM CLIを使用するパッチ適用

Enterprise Manager 12cからは、Enterprise Managerのコマンドライン・インタフェースを使用してターゲットにパッチを適用できます。パッチのダウンロードと適用にCloud Controlは必須ではありません。

次の表は、EM CLIのパッチ適用シナリオを示しています。

表A-4 EM CLIのパッチ適用シナリオ

ケースNo

シナリオ

高レベルのステップ

ケース1

パッチ適用ターゲットの新規プロパティ・ファイルの作成

新規プロパティ・ファイルを使用してターゲットにパッチを適用するには、次の手順を実行します。

1. ターゲットを選択し、計画に追加するパッチを検索します。

2. プロパティ・ファイルを作成し、一時的な場所に保存します。

3. プロパティ・ファイルを入力として使用して計画を作成します。

4. 送信前にパッチ計画を確認し、特定のパッチ計画が送信可能かどうかを判断します。アクションの内容に応じて、次のようにします。
- 「分析」の場合は、分析するパッチ計画を送信できます。

- 「デプロイ」の場合は、デプロイするパッチ計画を送信できます。

5. 送信した計画のステータスを検証します。

EM CLIコマンドを使用して各ステップを実行する方法の詳細は、第A.5.2.1項を参照してください。

ケース2

既存のパッチ計画のプロパティ・ファイルを更新してターゲットにパッチを適用

既存のパッチ計画から取得したプロパティ・ファイルを更新するには、次の手順を実行します。

1. 特定のパッチ計画についてユーザー編集可能なデータを取得し、出力をプロパティ・ファイルとして保存します。

2. エディタを使用してプロパティ・ファイルを編集します。たとえば、viエディタなどを使用します。

3. 編集したユーザー・データを保存します。

4. 送信前にパッチ計画を確認し、特定のパッチ計画が送信可能かどうかを判断します。アクションの内容に応じて、次のようにします。
- 「分析」の場合は、分析するパッチ計画を送信できます。

- 「デプロイ」の場合は、デプロイするパッチ計画を送信できます。

5. 送信した計画のステータスを検証します。

EMCLIコマンドを使用して各ステップを実行する方法の詳細は、第A.5.2.2項を参照してください。

A.5.2.1 パッチ適用ターゲットの新規プロパティ・ファイルの作成

パッチ計画を最初から作成する場合は、新規のプロパティ・ファイルを作成し、計画を作成するための入力としてこのプロパティ・ファイルを送信する必要があります。次の手順を実行します。

1. パッチを適用する必要のあるターゲットを選択します。これを行うには、次のEM CLIコマンドを実行します。

emcli get_targets
[-targets="[name1:]type1;[name2:]type2;..."]

For example:
emcli get_targets -targets=oracle_emd

Output:
Displays all the Management Agent targets.

ステータスID

ステータス

ターゲット・タイプ

ターゲット名

2

エラー時のメトリック収集

oracle_emd

h1.us.example.com:5125

2

エラー時のメトリック収集

oracle_emd

h2.us.example.com:5125

1

稼働中

oracle_emd

slc01nha.us.example.com:11852

1

稼働中

oracle_emd

slc00bng.us.example.com:1833

1

稼働中

oracle_emd

adc2101349.us.example.com:1832

2. 適用するパッチを検索します。計画に該当するパッチを検索するには、「パッチID」を使用するか(基本検索)、「リリースID」、「プラットフォームID」および「製品ID」の組合せを使用して(拡張検索)、必要なパッチまでドリルダウンする必要があります。これを行うには、次のEM CLIコマンドを実行します。

emcli search_patches
[-swlib]
[-patch_name="patch_name"]
[-product="product id" [-include_all_products_in_family]]
[-release="release id"]
[-platform="platform id" | -language="language id"]
[-type="patch | patchset"]
[-noheader]
[-script | -xml | -format=
[name:<pretty|script|csv>];
[column_separator:"column_sep_string"];
[row_separator:"row_sep_string"];
]

注意:
パッチは、次のいずれかの場所で検索できます。
• ARUサイト

• ソフトウェア・ライブラリ

インターネット接続があってオンライン・モードの場合は、デフォルトでARUサイトのパッチを検索できます。一方、オフライン・モードの場合には、パッチを使用できるようにソフトウェア・ライブラリにパッチがすでにアップロードされていることを確認する必要があります。

EM CLIを使用して、次のいずれかの方法で検索を実行できます。

• 簡易検索: このモードでは、パッチID情報を使用してARUサイトまたはソフトウェア・ライブラリを検索できます。

• 拡張検索: このモードでは、プラットフォームID、言語ID、リリースID、製品IDなどのキー値を組み合せて指定し、検索するパッチまでドリルダウンすることができます。

次の構文を使用できます。EM CLIコマンドを使用して、対応する簡易検索と拡張検索を実行する例は次のとおりです。

1. (基本検索)「パッチID」を使用してパッチを検索するには、次の手順を実行します。

emcli search_patches
[-swlib]
[-patch_name="patch_name"]
[-product="product id" [-include_all_products_in_family]]
[-release="release id"]
[-platform="platform id" | -language="language id"]
[-type="patch | patchset"]
[-noheader]
[-script | -xml | -format=
[name:<pretty|script|csv>];
[column_separator:"column_sep_string"];
[row_separator:"row_sep_string"];
]

Example 1: Basic Search (Online Mode)
To search for patches on My Oracle Support using the Patch ID:
emcli search_patches -patch_name=11993573

Output:
11993573        Agent Plugin PATCH      Cloud Control (Agent) 12.1.0.1.0        Linux x86-64    American English        General Enterprise Manager Base Platform - Plugin

Example 2: Basic Search (Offline Mode)
To search for patches on Software Library using the patch ID:
emcli search_patches -patch_name=11993573 -swlib -script

Output:
11993573        Agent Plugin PATCH      Cloud Control (Agent) 12.1.0.1.0        Linux x86-64    American English        General Enterprise Manager Base Platform - Plugin

2. (拡張検索)「製品ID」、「リリースID」、「プラットフォームID」(または「言語ID」)を使用して、パッチ計画に追加するパッチの詳細を取得します。

Example:
To search for patches using a combination of Product ID, Release ID, and Platform ID (obtained from the earlier steps):
emcli search_patches -product=12383 -release=9800371121010   -platform=226

Output:
13491785        ENTERPRISE MANAGER BASE PLATFORM  - AGENT 12.1.0.1.0 BP1 (PORT) Cloud Control (Agent) 12.1.0.1.0        Linux x86-64    American English        Recommended     Enterprise Manager Base Platform13481721        WRONG ERROR MESSAGE RETURNED FROM NMO   Cloud Control (Agent) 12.1.0.1.0        Linux x86-64    American English        General Enterprise Manager Base Platform

3. 任意のエディタを使用してパッチとターゲットのマップを作成し(プロパティ・ファイルに格納される)、パッチID、リリースID、プラットフォームID、言語IDなどの情報を指定します。次にサンプルのプロパティ・ファイルを示します。

vi demo.props

patch.0.patch_id=13426630
patch.0.release_id=9800371121010
patch.0.platform_id=2000
patch.0.language_id=0
patch.0.target_name=abc1.example.com:1836
patch.0.target_type=oracle_emd
patch.1.patch_id=13426630
patch.1.release_id=9800371121010
patch.1.platform_id=2000
patch.1.language_id=0
patch.1.target_name=abc2.us.example.com:1839
patch.1.target_type=oracle_emd

4. create_patch_planコマンドを実行して計画を作成し、新規作成したプロパティ・ファイル(demo.props)を入力として指定します。

emcli create_patch_plan
-name="name"
-input_file=data:"file_path"
[-impact_other_targets="add_all | add_original_only | cancel"]

Example:
emcli create_patch_plan -name=demo_agent -input_file=data:demo.props -impact_other_targets=add_all

注意:
選択したターゲットが他のターゲットに影響する場合は、impact_other_targets with the value "add_all"を追加する必要があります。たとえば、NFSホームで稼働しているエージェントのいずれかをパッチの対象として選択すると、同じNFSホームに基づく他のエージェントもパッチ適用の影響を受けるため、パッチ計画にすべてを含める必要があります。

5. 関連するすべてのデータを使用してパッチ計画の作成が終了すると、「分析」モードで送信し、計画がデプロイ可能かどうかを検証できます。これを行うには、次のコマンドを実行します。

emcli submit_patch_plan -name=demo_agent -action=analyze

Output:
The action "analyze" is successfully submitted on the Patch Plan "demo_agent", now "analyze" is in progress.

「分析」モードを使用すると、計画がデプロイ可能かどうかを確認するために、計画ですべての検証を実行しやすくなります。計画は、分析が成功してからでないとデプロイできません。

6. パッチ計画のステータスを検証するには、次のEM CLIコマンドを実行します。

emcli show_patch_plan -name=demo_agent -info | grep plan_status

Output:
<plan_status>CONFLICTS</plan_status>

なんらかの競合がある場合には、計画をデプロイする前に解決してください。ユーザー・インタフェースを使用して問題を解決し、ステータスがCLEANになるまで計画を再実行できます。

7. 分析が成功すると、パッチ計画をデプロイできるようになります。これを行うには、actionにdeployを指定して次のコマンドを実行します。

emcli submit_patch_plan -name=agent_demo -action=deploy

Output:
The action "deploy" is successfully submitted on the Patch Plan "demo_agent", now "deploy" is in progress

8. 計画のステータスを検証するには、ステップ6で説明しているようにEM CLIコマンドshow_patch_planを実行します。コマンドの出力がDEPLOY_SUCCESSの場合のみ、計画が正常にデプロイされ、パッチ計画に指定されたターゲットにパッチが適用されたことを意味します。

emcli show_patch_plan -name=demo_agent -info

Output:
<plan>
<planDetails>
<plan_id>79CAF6A6DAFCFEE6654C425632F19411</plan_id>
<name>demo</name>
<type>PATCH</type>
<description/>
<conflict_check_date>Tue Feb 21 18:04:04 PST 2012</conflict_check_date>
<conflict_check_date_ms>1329876244000</conflict_check_date_ms>
<is_deployable>1</is_deployable>
<plan_status>CONFLICTS</plan_status>
<review_status>CONFLICT_FREE</review_status>
<created_date>Tue Feb 21 17:40:47 PST 2012</created_date>
<created_date_ms>1329874847000</created_date_ms>
<created_by>SYSMAN</created_by>
<last_updated_date>Tue Feb 21 17:58:29 PST 2012</last_updated_date>
<last_updated_date_ms>1329875909000</last_updated_date_ms>
<last_updated_by>SYSMAN</last_updated_by>
<grant_priv>yes</grant_priv>
<user_plan_privilege>FULL</user_plan_privilege>
<see_all_targets>N</see_all_targets>
<homogeneousGroupLabel>Database Instance 10.2.0.1.0 (Linux x86-64)</homogeneousGroupLabel>
<executeGuid/>
<executeUrl/>
<planDetails/>

9. 発行したパッチ適用プロシージャ/ジョブの詳細を取得するには、コマンドget_job_execution_detailsで、実行のGUIDを使用します。

emcli get_job_execution_detail
-execution={execution_id}
[-xml  [-showOutput [-tailLength={length}]]]

For Example:
emcli get_job_execution_detail -execution=79CAF6A6DAFCFEE6654C425632F19411 -xml

A.5.2.2 既存のパッチ計画のプロパティ・ファイルを使用してターゲットにパッチを適用

パッチとターゲットのペア、または一般情報やデプロイ・オプションを更新するために、作成後の既存のパッチ計画を編集するには、次にリストする手順に従います。

1. 既存の計画のユーザー編集可能なフィールドを表示するには、次のようにget_patch_plan_dataコマンドを実行し、出力をプロパティ・ファイルに保存します。

$ emcli get_patch_plan_data -name=demo_agent >demo_agent.props

Output:
name=demo_agent
description=
deployment_date=
planPrivilegeList=VIEWER:ADMIN:VIEW;OPER:ADMIN:VIEW;DESIGNER:ADMIN:VIEW
patch.0.patch_id=13426630
patch.0.release_id=9800371121010
patch.0.platform_id=2000
patch.0.language_id=0
patch.0.target_name=abc1.example.com:1836
patch.0.target_type=oracle_emd
patch.1.patch_id=13426630
patch.1.release_id=9800371121010
patch.1.platform_id=2000
patch.1.language_id=0
patch.1.target_name=abc2.example.com:4473
patch.1.target_type=oracle_emd
deploymentOptions.StageLocation=%emd_emstagedir%
deploymentOptions.AdvancedOPatchOptions=null
deploymentOptions.StagePatches=true

2. 任意のエディタを使用してプロパティ・ファイル(demo_agent.props)を編集します。次のように、記憶域の場所を変更します。

name=demo_agent
description=
deployment_date=
planPrivilegeList=VIEWER:ADMIN:VIEW;OPER:ADMIN:VIEW;DESIGNER:ADMIN:VIEW
patch.0.patch_id=13426630
patch.0.release_id=9800371121010
patch.0.platform_id=2000
patch.0.language_id=0
patch.0.target_name=abc1.example.com:1836
patch.0.target_type=oracle_emd
patch.1.patch_id=13426630
patch.1.release_id=9800371121010
patch.1.platform_id=2000
patch.1.language_id=0
patch.1.target_name=abc2.example.com:4473
patch.1.target_type=oracle_emd
deploymentOptions.StageLocation=%emd_emstagedir%/demo
deploymentOptions.AdvancedOPatchOptions=null
deploymentOptions.StagePatches=true

3. 編集後の新規データでパッチ計画を保存するには、次のようにset_patch_plan_dataコマンドを実行します。

emcli set_patch_plan_data -name=demo_agent -input_file=data:demo_agent.props

Output:
It is successfully on updating deployment options from the patch plan.

注意:
選択したターゲットが他のターゲットに影響する場合は、impact_other_targets with the value "add_all"を追加する必要があります。たとえば、NFSホームで稼働しているエージェントのいずれかをパッチの対象として選択すると、同じNFSホームに基づく他のエージェントもパッチ適用の影響を受けるため、パッチ計画にすべてを含める必要があります。

4. 第A.5.2.1項で説明されているステップ5、6、7、8、9に従い、パッチ適用プロセスを完了します。

A.6 EM CLIコマンドを使用するワークフローの例

次の項では、EM CLIコマンドを使用して実行できるプロビジョニング、パッチ適用およびソフトウェア・ライブラリの各タスクの一部について説明します。

- Oracleデータベース・ソフトウェアのプロビジョニング

- Oracle WebLogic Serverのプロビジョニング

- ユーザー定義デプロイメント・プロシージャのプロビジョニング

- WebLogic Serverターゲットへのパッチ適用

- ZIPファイルの関連付けによる新規汎用コンポーネントの作成

- ソフトウェア・ライブラリの記憶域の場所の移行および削除

- EM CLIを使用したATSサービス・テストの追加

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

A.6.1 Oracleデータベース・ソフトウェアのプロビジョニング

このユースケースでは、Cloud Controlに含まれるEM CLIコマンドを使用してOracle Databaseソフトウェアをプロビジョニングする方法を説明します。最初のステップでは、社内で実行しているデータベース・プロシージャをフィルタ処理でリストから除外し、単一インスタンス・データベース・プロシージャと対応するGUIDを選択します。SI DBプロシージャについて、新しいプロパティ・ファイルを新規作成します。最初はテンプレートの名前/値ペアは空になっています。プロパティ・ファイルの属性を編集して、値を講師する必要があります。その後、更新したプロパティ・ファイルを入力としてプロシージャを発行し、完了するまで追跡します。

注意:
次の動詞の場合、Oracle Database 9i Release 2のみクローニングされます。emcli clone_database_home -swlib true

ステップごとの手順を出力とともに次に示します。

1. デプロイメント・プロシージャのGUIDを取得するには、次のコマンドを実行します。

./emcli get_procedures | grep DB_

For Example:
./emcli get_procedures | grep DB
B3F.CE84B1ED96791E040578CD7810EC5, DBPROV, Prov_112_db_using_SH_1ocked_acc_without_env_shift_username1, Prov_112_db_using_SH_1ocked_acc_without_env_shift_ssubbura11, 1.0, USERNAME1, SIHA_SIDB_PROC
B35E10B1F42AB4EEE040578CD78179DC, DB_PROV_UPGRADE, DbProvUpgradeDP, Upgrade Oracle Database, 1.0, ORACLE
B35E10B1F427B4EEE040578CD78179DC, DBPROV, SIHA_SIDB_PROC, Provision Oracle Database, 1.0, ORACLE

Select the GUID corresponding to the SIHA_SIDB_PROC , which is B35E10B1F427B4EEE040578CD78179DC

2. 次のコマンドを使用してプロパティ・ファイル・テンプレートを作成します。

./emcli describe_procedure_input -procedure=B35E10B1F427B4EEE040578CD78179DC > sihasidb.properties

3. エディタを使用して、生成されたプロパティ・ファイルsihasidb.propertiesのコンテンツを表示し、必要な値を入力します。
たとえば、使用されたサンプル・プロパティ・ファイル(更新された値を含む)を次に示します。

# The Procedure Configuration with name emcli_11202 has input and arguments as follows:
# Input properties are:
DB_COMPONENT=11<ADMIN_NAME>/Oracle Database Installation Media
DB_HOST_NORMAL_CREDNAMES=AIME_USER1:<USERNAME>
DB_HOST_ROOT_CREDNAMES=AIME_ROOT:<USERNAME>
DB_ORACLE_BASE_LOC=/scratch/db11202
DB_ORACLE_HOME_LOC=/scratch/db11202/app/product/11.2.0/db
DB_PRODUCT_VERSION=11.2.0.2.0
DEPLOY_MODE=DEPLOY_DB
OINSTALL_GROUP=svrtech
OSDBA_GROUP=dba
OSOPER_GROUP=oper
PAUSE_AFTER_PREREQ=false
RAC_HOME_SHARED=false
SOURCE_TYPE=SOFTWARE_LIBRARY
TARGET_HOST_LIST=host.us.example.com
WORK_DIR_LOC=/tmp

4. 次のコマンドを使用してプロシージャを発行します。

./emcli submit_procedure -input_file=data:sihasidb.properties
-instance="emcli_db1" -procedure=B35E10B1F427B4EEE040578CD78179DC
Verifying parameters ...
Schedule not specified, defaults to immediate
A8F7700333BAE9FAE040E40A45D866F1
Deployment procedure submitted successfully

A.6.2 Oracle WebLogic Serverのプロビジョニング

このユースケースでは、Cloud ControlのEM CLIコマンドを使用して、Oracle WebLogic Serverをプロビジョニングする方法、およびミドルウェア・プロシージャをスケール・アップおよびスケール・アウトする方法を説明します。

Cloud Controlでは、EM CLIコマンドを使用してOracle WebLogic Serverをプロビジョニングする次のユースケースがサポートされます。

- プロビジョニング・プロファイルを使用したOracle WebLogic Serverのプロビジョニング

- ミドルウェア・デプロイメント・プロシージャのスケール・アップまたはスケール・アウト

A.6.2.1 Oracle WebLogic Serverをプロビジョニングするための前提条件

- 管理サーバーおよび管理対象サーバーを含むWebLogicドメインを設定しておきます。また、ホスト・ターゲットがMiddlewareプロビジョニング・ページで検出されるように、ターゲットをOMSに登録しておきます。

- WebLogicドメイン・プロビジョニング・プロファイルを作成します。こうすると、選択されたドメインとMiddlewareホームが、将来のクローニング操作のためにアーカイブされてソフトウェア・ライブラリに格納されます。このプロファイルは、WebLogicドメインをクローニングするときに使用できます。

A.6.2.2 プロビジョニング・プロファイルを使用したOracle WebLogic Serverのプロビジョニング

最初のステップでは、社内で実行しているFMWプロシージャをフィルタ処理でリストから除外し、FMWPROVと対応するGUIDを選択します。FMWPROVプロシージャについて、新しいプロパティ・ファイル・テンプレートを新規作成します。最初はテンプレートの名前/値ペアは空になっています。プロパティ・ファイルの属性を編集して、値を講師する必要があります。その後、更新したプロパティ・ファイルを入力としてプロシージャを発行し、完了するまで追跡します。

次の手順に従います。

1. デプロイメント・プロシージャのGUIDを取得するには、次のコマンドを実行します。

./emcli get_procedures | grep FMWPROV_

The output appears in the following format:
<proc_guid>, <procedure_type>, <Procedure_name>, <Dsplay name>, <version>, <Parent procedure name>

For example:
./emcli get_procedures | grep FMWPROV_
B35E10B1F154B4EEE040578CD78179DC, FMW Provisioning, FMWPROV_DP, Provision Middleware, 2.0, ORACLE

2. 前のステップで取得したGUIDを使用して、次のコマンドを使用してプロパティ・ファイル・テンプレートを準備します。

./emcli describe_procedure_input - procedure=<proc_guid> -name = <proc_name>

For example:

./emcli describe_procedure_input -procedure=B35E10B1F154B4EEE040578CD78179DC > instanceFMWData.properties
A properties file with the name instanceFMWData.properties is created

3. エディタを使用して、生成されたプロパティ・ファイルinstanceFMWData.propertiesを開き、必要な値を入力します。
たとえば、使用されたサンプル・プロパティ・ファイル(更新された値を含む)を次に示します。

# Input properties are:

APPS_GOLD_IMAGE_FILENAME=apps.zip
ARCHIVE_FILE_NAME=archive.jar
CLONING_JAR_NAME=cloningclient.jar
CONFIG_PLAN_OBJECT_DP_VARIABLE=Type:JDBCSystemResource;Action:Set; Attributes[Name:mds-owsm~Target:Cluster_1,Cluster_2]<BR>
CREATE_DOMAIN=true
DEST_ADMIN_HOST.0.ADMIN_SQL_HOME=
DEST_ADMIN_HOST.0.DATASOURCE_PROPERTY_FILE_DIR=
DEST_ADMIN_HOST.0.DATASOURCE_PROPERTY_FILE_NAME=
DEST_ADMIN_HOST.0.DOMAIN_HOME_DEST_ADMIN_HOST=/scratch/FFT4_EMCLI
DEST_ADMIN_HOST.0.DOMAIN_NAME_DEST_ADMIN_HOST=FFT4_EMCLI
DEST_ADMIN_HOST.0.FMW_HOME_DEST_ADMIN_HOST=/scratch/fmwprov
DEST_ADMIN_HOST.0.HAS_MANAGED_SERVER_REMOTE=false
DEST_ADMIN_HOST.0.MS_TEMPLATE_DEST_ADMIN_HOST=testMA.jar
DEST_ADMIN_HOST.0.MS_TEMPLATE_NAME=mytemplate
DEST_ADMIN_HOST.0.ORACLE_HOME_DEST_ADMIN_HOST=
DEST_ADMIN_HOST.0.PORT_DETAILS_DEST_ADMIN_HOST=7001:Listen Port,7002:SSL Listen Port
DEST_ADMIN_HOST.0.PRODUCT_TYPE_DEST_ADMIN_HOST=SOA
DEST_ADMIN_HOST.0.SERVER_NAME_DEST_ADMIN_HOST=AdminServer
DEST_ADMIN_HOST.0.START_SERVER_REQUIRED_DEST_ADMIN_HOST=true
DEST_ADMIN_HOST.0.WLS_HOME_DEST_ADMIN_HOST=/scratch/fmwprov/wlserver_10.3
DEST_ADMIN_HOST.0.WLS_PASSWORD_DEST_ADMIN_HOST=welcome1
DEST_ADMIN_HOST.0.WLS_USERNAME_DEST_ADMIN_HOST=weblogic
DEST_ADMIN_HOST.0.WORK_DIR_LOC_DEST_ADMIN_HOST=/tmp/fmwProvDest
DEST_ADMIN_HOST.0.defaultHostCred=PREF:HostCredsNormal
DEST_ADMIN_HOST.0.name=host.us.example.com
DEST_ADMIN_HOST.0.type=host
DEST_ADMIN_HOST_NAME=host.us.example.com
DEST_ADMIN_PORT=7001
DEST_ADMIN_WORK_DIR_LOC=/tmp/fmwProvDest
DEST_FMW_HOST.0.FMW_HOME_DEST_FMW_HOST=/scratch/fmwprov
DEST_FMW_HOST.0.JDK_HOME_DEST_FMW_HOST=
DEST_FMW_HOST.0.JRE_LOC=%emd_root%/jdk
DEST_FMW_HOST.0.LOG_DIR=
DEST_FMW_HOST.0.ORACLE_HOME_DEST_FMW_HOST=
DEST_FMW_HOST.0.OUI_HOME=
DEST_FMW_HOST.0.PREREQ_PATH=
DEST_FMW_HOST.0.WLS_HOME_DEST_FMW_HOST=/scratch/fmwprov/wlserver_10.3
DEST_FMW_HOST.0.WORK_DIR_LOC_DEST_FMW_HOST=/tmp/fmwProvDest
DEST_FMW_HOST.0.defaultHostCred=PREF:HostCredsNormal
DEST_FMW_HOST.0.name=host.us.example.com
DEST_FMW_HOST.0.type=host
DEST_MANAGED_SERVERS.0.ADMIN_HOST_NAME_DEST_MANAGED_SERVERS=host.us.example.com
DEST_MANAGED_SERVERS.0.ADMIN_HOST_PASSWORD_DEST_MANAGED_SERVERS=welcome1
DEST_MANAGED_SERVERS.0.ADMIN_HOST_USERNAME_DEST_MANAGED_SERVERS=weblogic
DEST_MANAGED_SERVERS.0.ADMIN_PORT_DEST_MANAGED_SERVERS=7001
DEST_MANAGED_SERVERS.0.DOMAIN_HOME_DEST_MANAGED_SERVERS=/scratch/FFT4_EMCLI
DEST_MANAGED_SERVERS.0.FMW_HOME_DEST_MANAGED_SERVERS=/scratch/fmwprov
DEST_MANAGED_SERVERS.0.MACHINE_NAME_DEST_MANAGED_SERVERS=Machine_1
DEST_MANAGED_SERVERS.0.MANAGED_SERVER_REMOTE_DEST_MANAGED_SERVERS=false
DEST_MANAGED_SERVERS.0.MS_PORT_DETAILS_DEST_MANAGED_SERVERS=9001:Listen Port,9002:SSL Listen Port
DEST_MANAGED_SERVERS.0.MS_TEMPLATE_DEST_MANAGED_SERVERS=testMA.jar
DEST_MANAGED_SERVERS.0.NM_LISTEN_ADDRESS=localhost
DEST_MANAGED_SERVERS.0.NM_LISTEN_PORT=5556
DEST_MANAGED_SERVERS.0.NM_PORT_DETAILS_DEST_MANAGED_SERVERS=5556:Listen Port
DEST_MANAGED_SERVERS.0.ORACLE_HOME_DEST_MANAGED_SERVERS=
DEST_MANAGED_SERVERS.0.SERVER_NAME_DEST_MANAGED_SERVERS=bam_server1
DEST_MANAGED_SERVERS.0.START_NM=true
DEST_MANAGED_SERVERS.0.START_SERVER_REQUIRED_DEST_MANAGED_SERVERS=true
DEST_MANAGED_SERVERS.0.WLS_HOME_DEST_MANAGED_SERVERS=/scratch/fmwprov/wlserver_10.3
DEST_MANAGED_SERVERS.0.WORK_DIR_LOC_DEST_MANAGED_SERVERS=/tmp/fmwProvDest
DEST_MANAGED_SERVERS.0.defaultHostCred=PREF:HostCredsNormal
DEST_MANAGED_SERVERS.0.name=host.us.example.com
DEST_MANAGED_SERVERS.0.type=host
DEST_MANAGED_SERVERS.1.ADMIN_HOST_NAME_DEST_MANAGED_SERVERS=slc00ave.us.example.com
DEST_MANAGED_SERVERS.1.ADMIN_HOST_PASSWORD_DEST_MANAGED_SERVERS=welcome1
DEST_MANAGED_SERVERS.1.ADMIN_HOST_USERNAME_DEST_MANAGED_SERVERS=weblogic
DEST_MANAGED_SERVERS.1.ADMIN_PORT_DEST_MANAGED_SERVERS=7001
DEST_MANAGED_SERVERS.1.DOMAIN_HOME_DEST_MANAGED_SERVERS=/scratch/FFT4_EMCLI
DEST_MANAGED_SERVERS.1.FMW_HOME_DEST_MANAGED_SERVERS=/scratch/fmwprov
DEST_MANAGED_SERVERS.1.MACHINE_NAME_DEST_MANAGED_SERVERS=
DEST_MANAGED_SERVERS.1.MANAGED_SERVER_REMOTE_DEST_MANAGED_SERVERS=false
DEST_MANAGED_SERVERS.1.MS_PORT_DETAILS_DEST_MANAGED_SERVERS=8001:Listen Port,8002:SSL Listen Port
DEST_MANAGED_SERVERS.1.MS_TEMPLATE_DEST_MANAGED_SERVERS=testMA.jar
DEST_MANAGED_SERVERS.1.NM_LISTEN_ADDRESS=
DEST_MANAGED_SERVERS.1.NM_LISTEN_PORT=
DEST_MANAGED_SERVERS.1.NM_PORT_DETAILS_DEST_MANAGED_SERVERS=
DEST_MANAGED_SERVERS.1.ORACLE_HOME_DEST_MANAGED_SERVERS=
DEST_MANAGED_SERVERS.1.SERVER_NAME_DEST_MANAGED_SERVERS=soa_server1
DEST_MANAGED_SERVERS.1.START_NM=false
DEST_MANAGED_SERVERS.1.START_SERVER_REQUIRED_DEST_MANAGED_SERVERS=true
DEST_MANAGED_SERVERS.1.WLS_HOME_DEST_MANAGED_SERVERS=/scratch/fmwprov/wlserver_10.3
DEST_MANAGED_SERVERS.1.WORK_DIR_LOC_DEST_MANAGED_SERVERS=/tmp/fmwProvDest
DEST_MANAGED_SERVERS.1.defaultHostCred=PREF:HostCredsNormal
DEST_MANAGED_SERVERS.1.name=host.us.example.com
DEST_MANAGED_SERVERS.1.type=host
DEST_TEMPLATE_FILE_NAME=testMA.jar
DOMAIN_GOLD_IMAGE_FILENAME=DomainTemplate.jar
DO_EXTERNAL_APPS=false
DO_SQL_SCRIPTS=false
EXTRA_FILES_ARCHIVE=extra_files.jar
FARM_PREFIX=Farm01_EMCLI
FMWPROV_ISCLONE=false
FMWPROV_ISDBPROV=false
FMWPROV_ISGOLD=true
FMWPROV_ISINSTALL=false
FMW_COMPONENT=DANS_FFT4/Dans_FFT4_GI_FMWHome
FMW_COMPONENT_FILE=archive.jar
GOLD_IMAGE_FILE_NAME=archive.jar
INSTALL_FMW=true
INSTALL_PRODUCT=false
INSTALL_RCU=false
IS_EXTERNAL_FILE=false
NOT_WINDOWS=true
PREREQ_ONLY_DP=false
PROVISION_MODE=GOLD
RCU_COMPONENT=n/a
REF_SIZE_FILE=sizeprereq
REF_TARGET_ZIP=prereq.zip
REF_TEMPLATE_FILE_NAME=template.jar
REF_TEMPLATE_NAME=mytemplate
RUNNING_WITH_INTERVIEW=true
RUN_RCU=false
SECURE_CONFIG_PROPERTIES=.PasswordEncrypted:welcome1,welcome1,welcome1,welcome1,welcome1,welcome1,welcome1,welcome1
SESSION_TS_LOC=//20110711090737
SIZE_STRING=mw_home_size=1635861705,work_dir_size=3271723410
SQL_ARCHIVE_FILE_NAME=sql-files.zip
START_MODE=ALL
TEMPLATE_COMPONENT=DANS_FFT4/Dans_FFT4_GI_Domain
TEMPLATE_COMPONENT_FILE=DomainTemplate.jar
USE_OWNER_CREDENTIALS=true
USE_SHARED_FMW_HOME=false

4. 生成されたinstanceFMWData.propertiesプロパティ・ファイルを入力としてプロシージャを発行します。

emcli submit_procedure -input_file=data:<input_properties_file> -procedure=<proc_guid> -instance_name=<optional_DP_Instance_Name>

./emcli submit_procedure -input_file=data:instanceFMWData.properties -procedure=B35E10B1F154B4EEE040578CD78179DC

A.6.2.3 ミドルウェア・デプロイメント・プロシージャのスケール・アップまたはスケール・アウト

既存のマシン上のクラスタにさらにサーバー・インスタンスを追加したり、新規サーバー・インスタンスをホストするためのマシンをクラスタに追加したりして、クラスタの能力を強化するプロセスは、スケール・アップと呼ばれます。管理対象サーバーのスケール・アップおよびスケール・アウトは、Enterprise Manager 12cのEM CLIコマンドを使用してコマンドラインから実行できます。

このユースケースでは、SCALEUPプロシージャのインスタンスGUIDを取得してから、それを使用して、プロシージャのそのインスタンスの入力プロパティ・ファイルを取得します。プロパティ・ファイルに必要な更新(ユーザーフレンドリ値の追加など)を行ってから、更新済プロパティ・ファイルを入力としてプロシージャを発行します。

ステップごとの手順を次に示します。

1. デプロイメント・プロシージャのGUIDを取得するには、次のコマンドを実行します。

./emcli get_procedures | grep SCALEUP_

The output appears in the following format:
<proc_guid>, <procedure_type>, <Procedure_name>, <Dsplay name>, <version>, <Parent procedure name>

For example:
./emcli get_procedure | grep SCALEUP
B35E10B1F154B4EEE040578CD78179DC, FMW Provisioning, SCALEUP DP, Scale up/Scale out Middleware, 2.0, ORACLE

2. 前のステップで取得されたインスタンスGUIDを使用して、プロシージャのインスタンスの入力プロパティを取得します。

./emcli get_instance_data -instance=<instance_guid> -exec=<execution_guid>

For example:

emcli get_instance_data -instance=B35E10B1F140B4EEE040578CD78179DC > instanceData.properties
A properties file with the name instanceData.properties is created.

注意:
このステップが有効なのは、プロシージャのインスタンスが使用可能な場合のみです。つまり、これまでに少なくとも1回はプロシージャが発行されていることが必要です。プロシージャを1回も発行していない場合は、次のようなエラー・メッセージが表示されます。
GUID=<guid>のインスタンスがリポジトリにありません。値が正しいことを確認してから再試行してください。

3. エディタを使用して、生成されたプロパティ・ファイルinstanceData.propertiesを開き、プロパティ・ファイルの既存の値を更新します。

4. 生成されたプロパティ・ファイルを入力としてプロシージャを発行します。

./emcli submit_procedure -input_file=data:<input_properties_file> -procedure=<proc_guid> -instance_name=<optional_DP_Instance_Name>

./emcli submit_procedure -input_file=data:instanceData.properties -procedure=B35E10B1F140B4EEE040578CD78179DC

A.6.3 ユーザー定義デプロイメント・プロシージャのプロビジョニング

このユースケースでは、Cloud Controlに含まれるEM CLIコマンドを使用してユーザー定義デプロイメント・プロシージャ(UDDP)をプロビジョニングする方法を説明します。このユースケースでは、Cloud Control UIを使用したUDDPの作成と、EM CLIコマンドを使用したUDDPの再発行の基本を説明します。

このユースケースでは、Cloud Control UIを使用して、linuxホストabc.example.com上のJRE6をプロビジョニングするユーザー定義デプロイメント・プロシージャを作成します。JREの転送やJREバージョンのチェックなどのステップをプロシージャに追加し、一意の発行名を使用してプロシージャを発行します。次に、EM CLIコマンドを使用して、発行されたプロシージャのインスタンスGUIDを取得します。プロパティ・ファイルを少し変更し、EM CLIで発行します。

A.6.3.1 ユーザー定義デプロイメント・プロシージャをプロビジョニングするための前提条件

次の前提条件を満たしていることを確認します。

- デザイナとしてCloud Controlにログインします。

- ソフトウェア・ライブラリ・ディレクティブを作成して、Linuxの/software_library/provisioning/install_jre6_linux32ディレクトリにJRE6をインストールします。任意のディレクトリを選択できることに注意してください。

- LinuxのホットスポットJRE6を含むソフトウェア・ライブラリ・コンポーネントを、/software_library/provisioning/hotspot_jre6_linux32ディレクトリに作成します。

A.6.3.2 GUIを使用したユーザー定義デプロイメント・プロシージャへのステップとフェーズの追加

フェーズやステップをユーザー定義デプロイメント・プロシージャ(UDDP)に追加するには、デザイナとしてCloud Controlにログインして次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」を選択します。

2. プロビジョニング・ページの「アクション」メニューで「新規作成」を選択し、「実行」をクリックします。

3. プロシージャUDDPTestに一意の名前を付けて、「プロシージャ・ステップ」タブをクリックします。

4. 「プロシージャ変数」タブで、プロシージャ変数destination_pathを追加します。

5. 「デフォルト・フェーズ」を選択し、「挿入」をクリックして新しいステップをフェーズに追加します。作成ウィザードで「タイプ」として「ライブラリ: コンポーネント」を選択します。ページがリフレッシュされ、5つのステップで構成されるウィザードが表示されます。

1. 作成ページで一意名としてJREの転送を入力し、「次へ」をクリックします。

2. コンポーネントの選択ページで、コンポーネントhotspot_jre6_linux32を選択します。

3. ディレクティブの選択ページで、ディレクティブinstall_jre6_linux32を選択します。

4. プロパティのマップ・ページで、ディレクティブのプロパティに定義した変数をマップします。たとえば、destination_pathディレクティブ・プロパティを「変数の選択」に設定してから、destination_pathを設定したプロシージャ変数を選択します。

5. 確認ページで詳細を確認し、「終了」をクリックします。

6. JREの転送ステップを選択し、「挿入」をクリックします。作成ウィザードで「タイプ」として「ホスト・コマンド」を選択します。ページがリフレッシュされ、3つのステップで構成されるウィザードが表示されます。

1. 作成ページで一意名としてJREバージョンのチェックを入力し、「次へ」をクリックします。

2. コマンドの入力ページに次のコマンドを入力します。

${data.destination_path}/jre1.6.0_23/bin/java -version

3. 確認ページで詳細を確認し、「終了」をクリックします。

7. プロシージャ・ライブラリ・ページで、作成したばかりのUDDPTestプロシージャを選択し、「起動」をクリックします。ウィザードを完了するには、プロシージャをプロビジョニングするターゲット、変数(宛先パス: /tmp)、資格証明情報、通知情報を入力します。

8. すべての詳細情報を指定したら、「発行」をクリックします。一意の発行名FirstUDDPを入力します。

9. プロシージャが実行された後で、JREバージョンのチェック・ステップの出力を確認します。正常な場合、バージョンはJRE6になります。

A.6.3.3 プロシージャのインスタンスを実行するためのEM CLIコマンドの使用

EM CLIコマンドを使用してプロシージャ・インスタンスを発行します。

1. 次のコマンドを実行して、発行したすべてのプロシージャのリストを取得し、インスタンスIDを記録します。

emcli get_instances
For example: emcli get_instances -type=DemoNG

2. 次のコマンドを実行して、プロシージャについて発行された入力のリストを取得します。

emcli get_instance_data - instance=<procedure_instance_ID>
For example: emcli get_instance_data -instance=16B15CB29C3F9E6CE040578C96093F61 > mydp.properties

3. ファイル(mydp.properties)を編集し、プロパティの宛先パスの値を/scratchに変更します。

4. 変更されたプロパティ・ファイルを入力としてプロシージャを発行します。

emcli submit_procedure -input_file=data:<input_file> -name=<procedure_name> -procedure=<procedure_guid>
For example: emcli submit_procedure -input_file=data:mydp.properties -name=UDDPTest -procedure=16B15CB29C3F9E6CE040578C96093F61

A.6.4 WebLogic Serverターゲットへのパッチ適用

次の手順では、パッチ計画を作成してその値を更新し、送信して、選択したターゲットにパッチをデプロイする方法を説明します。このワークフローは、WLSターゲットへのパッチ適用でエンドツーエンドの手順を取得します。パッチ適用のプロセスは、選択したターゲットにかかわらず同じです。

WebLogicサーバー・ターゲットにパッチを適用するには、次の手順を実行します。

1. 次のコマンドを実行して、Oracle WebLogic Release 10.3.5のリリースIDを検索します。

emcli list_aru_releases -name="10.3.5"
Output:
Release ID     Release Name    Long Release Name
8191035020     10.3.5.0.2      WLS 10.3.5.0.2
8191035010     10.3.5.0.1      WLS 10.3.5.0.1
8191035000     10.3.5          WLS 10.3.5
95103500       10.3.5          WLS 10.3.5

2. 次のコマンドを実行して、Oracle WebLogicの製品IDを検索します。

emcli list_aru_products -name="Oracle WebLogic Server"
Output:
Product ID    Product Name
15991         Oracle WebLogic Server
16725         Oracle WebLogic Server Virtual Edition

3. 次のコマンドを実行して、汎用プラットフォームのプラットフォームIDを検索します。

emcli list_aru_platform -name="Generic Platform"
Output:
Platform ID    Platform Name
2000            Generic Platform
1204            NLS Generic Platform

4. 前の手順で取得した製品、リリース、プラットフォームの詳細を使用して、次のようにパッチIDを検索します。

emcli search_patches -product=15991 -release=8191035000   -platform=2000

Output:
9561331    Generic PLATFORM  -  10.3.5 Oracle WebLogic Server 10.3.5    Generic    American English        Recommended     Generic Platform

5. viエディタを使用してパッチとターゲットのマップ(プロパティ)ファイルを作成し、パッチID、リリースID、プラットフォームID、言語IDなどの情報を指定します。次にサンプルのプロパティ・ファイルを示します。

vi create.props

patch.0.patch_id=9561331
patch.0.release_id=8191035000
patch.0.platform_id=2000
patch.0.language_id=0
patch.0.target_name=/Farm01_soa_domain/soa_domain
patch.0.target_type=weblogic_domain

6. 次のコマンドを実行して計画を作成し、新規作成したプロパティ・ファイル(create.props)を入力として指定します。

emcli create_patch_plan -name=demo1 -input_file=data:create.props

Output:
The Patch Plan "demo1" is successfuly created.

7. 既存の計画のユーザー編集可能なフィールドを表示し、出力をプロパティ・ファイルに保存するには、次のコマンドを実行します。

emcli get_patch_plan_data -name=demo1 >set.props

vi set.props
Output:
name=demo1
description=
deployment_date=
planPrivilegeList=VIEWER:ADMIN:VIEW;OPER:ADMIN:VIEW;DESIGNER:ADMIN:VIEW

patch.0.patch_id=9561331
patch.0.release_id=8191035000
patch.0.platform_id=2000
patch.0.language_id=0
patch.0.target_name=/Farm01_soa_domain/soa_domain
patch.0.target_type=weblogic_domain

deploymentOptions.StageLocation=%emd_emstagedir%
deploymentOptions.AdvancedOPatchOptions=AllNodes
deploymentOptions.StagePatches=true
deploymentOptions.rollbackMode=false

8. 任意のエディタを使用してプロパティ・ファイル(set.props)を編集し、ロールバック・モードをtrueに変更します。

name=demo1
description=
deployment_date=
planPrivilegeList=VIEWER:ADMIN:VIEW;OPER:ADMIN:VIEW;DESIGNER:ADMIN:VIEW

patch.0.patch_id=9561331
patch.0.release_id=8191035000
patch.0.platform_id=2000
patch.0.language_id=0
patch.0.target_name=/Farm01_soa_domain/soa_domain
patch.0.target_type=weblogic_domain

deploymentOptions.StageLocation=%emd_emstagedir%
deploymentOptions.AdvancedOPatchOptions=AllNodes
deploymentOptions.StagePatches=true
deploymentOptions.rollbackMode=true

9. 編集後の新規データでパッチ計画を保存するには、次のコマンドを実行します。

emcli set_patch_plan_data -name=demo1 -input_file=data:set.props

Output:
It is successfully updating deployment options from the patch plan.

10. パッチ計画のステータスを検証するには、次のEM CLIコマンドを実行します。

emcli show_patch_plan -name=demo1 -info

Output:
<plan>
<planDetails>
<plan_id>EDD74FFF006DD0EE6D28394B8AAE</plan_id>
<name>demo1</name>
<type>PATCH</type>
<description/>
<conflict_check_date>Tue Feb 21 18:04:04 PST 2012</conflict_check_date>
<conflict_check_date_ms>1329876244000</conflict_check_date_ms>
<is_deployable>1</is_deployable>
<plan_status>CONFLICTS</plan_status>
<review_status>CONFLICT_FREE</review_status>
<created_date>Tue Feb 21 17:40:47 PST 2012</created_date>
<created_date_ms>1329874847000</created_date_ms>
<created_by>SYSMAN</created_by>
<last_updated_date>Tue Feb 21 17:58:29 PST 2012</last_updated_date>
<last_updated_date_ms>1329875909000</last_updated_date_ms>
<last_updated_by><USERNAME></last_updated_by>
<grant_priv>yes</grant_priv>
<user_plan_privilege>FULL</user_plan_privilege>
<see_all_targets>N</see_all_targets>
<homogeneousGroupLabel>Oracle WebLogic Domain 10.3.5.0 (Linux x86-64)</homogeneousGroupLabel>
<executeGuid/>
<executeUrl/>
<planDetails/>

11. 関連するすべてのデータを使用してパッチ計画の作成と更新が終了すると、次の一連のモードでパッチ計画を送信できます。パッチ計画を送信するEM CLIコマンドは、次のとおりです。

emcli submit_patch_plan -name=demo1 -action=analyze

Output:
The action "analyze" is successfully submitted on the Patch Plan "demo1", now "analyze" is in progress.

12. 送信されたパッチ計画のステータスを検証するには、次のEM CLIコマンドを実行します。

emcli show_patch_plan -name=demo1 -info

Output:
<plan>
<planDetails>
<plan_id>EDD74FFF006DD0EE6D28394B8AAE</plan_id>
<name>demo1</name>
<type>PATCH</type>
<description/>
<conflict_check_date>Tue Feb 21 18:04:04 PST 2012</conflict_check_date>
<conflict_check_date_ms>1329876244000</conflict_check_date_ms>
<is_deployable>1</is_deployable>
<plan_status>CONFLICTS</plan_status>
<review_status>CONFLICT_FREE</review_status>
<created_date>Tue Feb 21 17:40:47 PST 2012</created_date>
<created_date_ms>1329874847000</created_date_ms>
<created_by>USERNAME</created_by>
<last_updated_date>Tue Feb 21 17:58:29 PST 2012</last_updated_date>
<last_updated_date_ms>1329875909000</last_updated_date_ms>
<last_updated_by>USERNAME</last_updated_by>
<grant_priv>yes</grant_priv>
<user_plan_privilege>FULL</user_plan_privilege>
<see_all_targets>N</see_all_targets>
<homogeneousGroupLabel>Oracle WebLogic Domain 10.3.5.0 (Linux x86-64)</homogeneousGroupLabel>
<executeGuid/>
<executeUrl/>
<planDetails/>

13. 競合があるかどうかを確認するには、次のコマンドを実行します。

emcli show_patch_plan -name=planName -analysisResults

Output:
<plan_status>CONFLICTS</plan_status>

作成した計画を検証するには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」、「パッチと更新版」の順に選択してEnterprise Manager Cloud Controlにログインします。ホームページに、コマンドラインで作成したパッチ計画demo1が次のように表示されます。

UIを使用して競合を解決し、パッチ計画を送信します。

14. 競合を解決したら、次のようにコマンドshow_patch_planを実行して計画のステータスを検証します。

Output:
<plan>
<planDetails>
<plan_id>EDD74FFF006DD0EE6D28394B8AAE</plan_id>
<name>demo</name>
<type>PATCH</type>
<description/>
<conflict_check_date>Tue Feb 21 18:04:04 PST 2012</conflict_check_date>
<conflict_check_date_ms>1329876244000</conflict_check_date_ms>
<is_deployable>1</is_deployable>
<plan_status>INPROGRESS</plan_status>
<review_status>CONFLICT_FREE</review_status>
<created_date>Tue Feb 21 17:40:47 PST 2012</created_date>
<created_date_ms>1329874847000</created_date_ms>
<created_by>USERNAME</created_by>
<last_updated_date>Tue Feb 21 17:58:29 PST 2012</last_updated_date>
<last_updated_date_ms>1329875909000</last_updated_date_ms>
<last_updated_by>USERNAME</last_updated_by>
<grant_priv>yes</grant_priv>
<user_plan_privilege>FULL</user_plan_privilege>
<see_all_targets>N</see_all_targets>
<homogeneousGroupLabel>Oracle WebLogic Domain 10.3.5.0 (Linux x86-64)</homogeneousGroupLabel>
<executeGuid>BA8E3904DDB36CFFE040F00A5E644D13</executGuid>
<executeUrl>/em/console/paf/procedureStatus?executionGUID=BA8E3904DDB36CFFE040F00A5E644D13</executeUrl>
<planDetails/>

15. 次のコマンドを実行して、パッチ計画の実行ステータスを確認します。

emcli get_instance_status -instance=BA8E3904DDB36CFFE040F00A5E644D13

Output:
BA8E3904DDB36CFFE040F00A5E644D13, PatchOracleSoftware, demo1_Analysis_Tue Mar 06 02:08:02 PST 012, EXECUTING

16. 分析が成功すると、パッチ計画をデプロイ/準備できるようになります。これを行うには、actionにdeployを指定して次のコマンドを実行します。

emcli submit_patch_plan -name=demo1 -action=deploy

Output:
The action "deploy" is successfully submitted on the Patch Plan "demo1", now "deploy" is in progress

17. Cloud Control UIを使用して、送信した計画が正常にデプロイされたかどうかを確認します。あるいは、EM CLIコマンドでも同じ検証を実行できます。

emcli get_job_execution_detail -execution=79CAF6A6DAFCFEE6654C425632F19411 -xml

A.6.5 ZIPファイルの関連付けによる新規汎用コンポーネントの作成

ZIPファイルを新規コンポーネントとしてアップロードするには、次の手順を実行します。

- ステップ1: ソフトウェア・ライブラリでの親フォルダの特定

- ステップ2: 汎用コンポーネント・エンティティの作成

- ステップ3: 汎用コンポーネントへのZIPファイルの関連付け

- ステップ4: 新規作成したエンティティの検証

A.6.5.1 ステップ1: ソフトウェア・ライブラリでの親フォルダの特定

ソフトウェア・ライブラリで作成した新規エンティティは、フォルダに配置する必要があります。既存のフォルダを選択することも、新規のフォルダを作成することもできます。これを行うには、次の各項に従います。

- 新規フォルダの作成

- 既存フォルダの選択

新規フォルダの作成

新規フォルダを作成する場合は、親フォルダを指定する必要があります。親フォルダがルート・フォルダの場合(最上位レベルの「Software Library」フォルダとして表示される)は、次のEM CLI動詞を使用します。

emcli create_swlib_folder
-name="myFolder"
-desc="myFolder description"
-parent_id=ROOT

出力:

Software Libraryフォルダにフォルダ'myFolderが作成されました。識別子はoracle:defaultService:em:provisioning:1:cat:C771B5A38A484CE3E40E50AD38A69D2です。

新規作成したフォルダについて出力メッセージで表示される識別子は、エンティティの作成または変更時に、あるいは他のサブフォルダを作成する目的で使用できます。

既存フォルダの選択

既存フォルダを選択する場合は、次のいずれかのアプローチを使用します。

- アプローチ1: Enterprise Manager UIを使用

- アプローチ2: Enterprise Managerコマンドライン・インタフェースを使用

アプローチ1: Enterprise Manager UIを使用

次の手順に従います。

1. 「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。

2. 「ソフトウェア・ライブラリ」ホームページで、「表示」メニューから「列」、「内部ID」の順に選択します。デフォルトでは、「内部ID」列は表示されていません。

3. 必要なフォルダの「内部ID」列の値をコピーします。

アプローチ2: Enterprise Managerコマンドライン・インタフェースを使用

次のEM CLI動詞を使用します。

emcli list_swlib_folders
-parent_id=ROOT
-show_folder_id

出力:

Java EE Provisioning,Java EE Application Provisioning Entities,oracle:defaultService:em:provisioning:1:cat:C771B5AAF4A4EED9E040E50AD38A6E98

MultiOMS,List of Oracle shipped Directives,oracle:defaultService:em:provisioning:1:cat:C771B5AAF1ACEED9E040E50AD38A6E98

myFolder,myFolder description,oracle:defaultService:em:provisioning:1:cat:C771B5A38A484CE3E040E50AD38A69D2

OSBProvisioning,OSBProvisioning Entities,oracle:defaultService:em:provisioning:1:cat:C771B5AAF3F1EED9E040E50AD38A6E98

..........

アクセスしようとするフォルダがmyFolderのサブフォルダの場合は、次の動詞を使用し、myFolderの識別子を指定してサブフォルダをリストします。

emcli list_swlib_folders
-parent_id='oracle:defaultService:em:provisioning:1:cat:C771B5A38A484CE3E040E50AD38A69D2'
-show_folder_id

出力:

mySubFolder,mySubFolder description,oracle:defaultService:em:provisioning:1:cat:C771B5A38A494CE3E040E50AD38A69D2

A.6.5.2 ステップ2: 汎用コンポーネント・エンティティの作成

mySubFolderフォルダの下に、タイプがComponent、サブタイプがGeneric Componentのエンティティを作成し、次の各項に従います。

- ステップ1a エンティティ・タイプの指定

- ステップ1b エンティティ・サブタイプの指定

- ステップ2. 汎用コンポーネント・エンティティの作成

ステップ1a. エンティティ・タイプの指定

ソフトウェア・ライブラリで使用可能なタイプをすべてリストするには、次の動詞を使用します。

emcli list_swlib_entity_types
-show_type_id

出力:

Component, COMP_Component
Directives, COMP_Directives
Bare Metal Provisioning, BMPType
Virtualization, Virtualization

ステップ1b. エンティティ・サブタイプの指定

componentタイプのすべてのサブタイプをリストするには、次の動詞を使用します。

emcli list_swlib_entity_subtypes
-entity_type_id=COMP_Component
-show_subtype_id

出力:

Generic Component, SUB_Generic
Oracle Database Software Clone, SUB_OracleDB
Configuration Template, SUB_ConfigTmpl
Oracle Application Server, SUB_OracleAS
Self Update, SUB_SelfUpdate
Oracle Clusterware Clone, SUB_OracleCRS
OSB Resource, SUB_OSBResource
Oracle Software Update, SUB_OraSoftUpdate
Java EE Application, SUB_JavaEEApplication
Installation Media, SUB_InstallationMedia
Database Template, SUB_DbCreateTemplate
Database Provisioning Profile, SUB_DbProfile
WebLogic Domain Provisioning Profile, SUB_FMWBundle
WebLogic Domain Clone, SUB_WLSTemlpate
Oracle Middleware Home Gold Image, SUB_FMWImage

手順2. 汎用コンポーネント・エンティティの作成

汎用コンポーネントを作成するには、次の動詞を実行します。

emcli create_swlib_entity
-name=myEntity
-type=COMP_Component
-subtype=SUB_Generic
-folder_id='oracle:defaultService:em:provisioning:1:cat:C771B5A38A494CE3E040E50AD38A69D2'
-desc='myEntity description'
-attr="PRODUCT:Example"
-attr="PRODUCT_VERSION:3.1"
-attr="VENDOR:Example Corp"
-note='first comment for myEntity

注意:
タイプとサブタイプは、汎用コンポーネントを作成する際にはオプションですが、この説明では明示的に指定しています。

出力:

Entity 'myEntity' is created in 'mySubFolder' folder, identifier is 'oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_Generic:C77200CA9DC1E7AAE040E50AD38A1599:0.1'

注意:
新規作成したエンティティについて出力メッセージで表示される識別子は、ファイルのアップロードやエンティティの変更時に使用できます。
新規作成したエンティティを検証するには、次の動詞を使用します。

emcli list_swlib_entities
-name=myEntity
-folder_id='oracle:defaultService:em:provisioning:1:cat:C771B5A38A494CE3E040E50AD38A69D2'

出力:

myEntity,0.1,myEntity description,Ready,Component,Generic Component,Untested,SYSMAN

A.6.5.3 ステップ3: 汎用コンポーネントへのZIPファイルの関連付け

既存のエンティティmyEntityにZIPファイルをアップロードするには、次の動詞を使用します。

emcli upload_swlib_entity_files
-entity_rev_id='oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_Generic:C77200CA9DC1E7AAE040E50AD38A1599:0.1'
-file="/scratch/user1/patch13653908.zip;newfile1.zip"
-host="host.us.example.com"
-credential_name=mycred11
-credential_owner=sysman

注意:
アップロードが完了すると、エンティティmyEntityの新規リビジョンが作成されます。

出力:

Upload of file(s) initiated, this may take some time to complete...
Upload of file(s) completed successfully.
Entity 'myEntity (0.2)' in 'mySubFolder' folder has been created, identifier is 'oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_Generic:C77200CA9DC1E7AAE040E50AD38A1599:0.2'.

あるいはHTTPの参照先、たとえばmyScriptsにあるZIPファイルを参照するには、次の動詞を使用します。

emcli refer_swlib_entity_files
-entity_rev_id='oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_Generic:C77200CA9DC1E7AAE040E50AD38A1599:0.1'
-file='scripts/perl/script1.pl;new_script.pl'
-refer_storage='myScripts;Http'

出力:

Entity 'myEntity (0.2)' in 'mySubFolder' folder has been created, identifier is 'oracle:defaultService:em:provisioning:1:cmp:COMP_Component:SUB_Generic:C77200CA9DC1E7AAE040E50AD38A1599:0.2'.

A.6.5.4 ステップ4: 新規作成したエンティティの検証

新規作成したエンティティを検証するには、次の動詞を使用します。

emcli list_swlib_entities
-name=myEntity
-folder_id='oracle:defaultService:em:provisioning:1:cat:C771B5A38A494CE3E040E50AD38A69D2'

出力:

myEntity,0.1,myEntity description,Ready,Component,Generic Component,Untested,USERNAME

A.6.6 ソフトウェア・ライブラリの記憶域の場所の移行および削除

このユースケースは、既存の記憶域の場所の移行および削除方法を説明しています。次の例では、ソフトウェア・ライブラリ・アップロード・ファイルの記憶域の場所がすでに構成されています。ファイルは、この記憶域の場所から、同じ記憶域タイプまたは別の記憶域タイプの別の場所に移行できます。

次の例では、最初の記憶域の場所の名前はfirstLocで、記憶域タイプはOMSエージェント・ファイル・システムです。2番目の記憶域の場所はOMS共有ファイル・システムで、名前はsecondLocです。

- ステップ1: ファイルを移行する宛先記憶域の場所の追加

- ステップ2: 既存の記憶域の場所の移行および削除

A.6.6.1 ステップ1: ファイルを移行する宛先記憶域の場所の追加

ソフトウェア・ライブラリ内のエンティティに関連付けられているファイルを置くことができるのは、1つの記憶域の場所のみです。アップロード・ファイルの記憶域の場所を削除する処理は、ファイルを別の既存のアップロード・ファイルの記憶域の場所に移行する処理よりも常に後に実行されます。このステップの一部として、タイプがOMS共有ファイル・システムである宛先記憶域の場所が十分なディスク領域を指定して作成され、ソース記憶域の場所firstLocにあるすべてのファイルのコピーが保持されます。

OMS共有ファイル・システム記憶域の場所の追加

emcli add_swlib_storage_location

-name=secondLoc

path=/u01/swlib

type=OmsShared

出力例:

Location configuration initiated, this may take some time to complete...

Location 'secondLoc' created.

OMS共有ファイル・システム記憶域の場所の表示

新しい記憶域の場所が作成されたことを確認するには、次のコマンドを実行します。

emcli list_swlib_storage_locations

type=OmsShared

出力例:

secondLoc, /u01/swlib/, Active

A.6.6.2 ステップ2: 既存の記憶域の場所の移行および削除

記憶域の場所firstLocを削除して、すべてのファイルを記憶域の場所secondLocに移行するには、次のコマンドを使用します。

emcli remove_swlib_storage_location

name=firstLoc

type=OmsAgent

migrate_to_loc=secondLoc -migrate_to_type=OmsShared

出力例:

Job 'MigrateEntityFiles_1352113174929' has been successfully submitted for migrating the files.

ジョブが正常に実行されると、場所firstLocは削除されます。ジョブ実行の詳細を確認するには、「エンタープライズ」、「ジョブ」、「アクティビティ」ページにナビゲートします。

ソースOMSエージェント・ファイル・システム記憶域の場所のステータスの確認

記憶域の場所firstLocに対して移行操作および削除操作を開始した直後に、その場所は「非アクティブ」としてマークされ、この場所に新しいファイルがアップロードできなくなります。この場所のステータスを確認するには、次のコマンドを実行します。

emcli list_swlib_storage_locations

-type=OmsAgent

出力例:

firstLoc, /u01/swlib/, Inactive

移行ジョブが完了したら、場所firstLocは削除されるため、表示されなくなります。

A.6.7 EM CLIを使用したATSサービス・テストの追加

このユースケースは、カスタム・データバンクを使用して、テスト・リポジトリで使用可能な既存のATSサービス・テスト・インスタンスをカスタマイズする方法を説明します。

注意:
このプロシージャを続行する前に、ATSサービス・テスト・タイプをテスト・リポジトリにアップロードしていることを確認します。詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「サービスの構成および使用」を参照してください。

リポジトリで使用可能なサービス・テストを使用してATSテスト・インスタンスを作成し、カスタム・データバンクを適用することによりテストをカスタマイズするには、次の手順に従います。

1. 既存のサービスに対して、my_serviceという名前のATSサービス・テスト・インスタンスを作成します。

emcli apply_template_tests -targetName='my_service' -targetType=generic_service -input_file=template:'my_template.xml'  -swlibPath='/service/test/entity'

Where,
-input_file=template:'my_template.xml' contains all the ATS test related information.
-swlibPath: holds the path to retrieve the ATS Zip file from software library.

Here is an example for a sample input file:
<?xml version = '1.0' encoding = 'UTF-8'?>
<transaction-template template_type="generic_service" xmlns="template">
<variables/>
<transactions>
<mgmt_bcn_transaction>
<mgmt_bcn_txn_with_props>
<mgmt_bcn_txn is_representative="true" name="ats91_with_databanks" monitoring="true" txn_type="OATS"/>
<properties>
<property name="Collection Interval" num_value="5.0" prop_type="2" encrypt="false"/>
<property name="scriptDescription" string_value="[1] Oracle Secure Enterprise Search&#xA;[2] Oracle Secure Enterprise Search&#xA;[3] No Title&#xA;[4] No Title" prop_type="1" encrypt="false"/>
<property name="fileUploadTime" string_value="2010-09-10 13:49:46.0" prop_type="1" encrypt="false"/>
<property name="OpenScriptJwgName" string_value="ats91_with_databanks.zip" prop_type="1" encrypt="false"/>
<property name="thinkTimeMaxSec" num_value="5.0" prop_type="2" encrypt="false"/>
<property name="usageOptions" string_value="userDefined" prop_type="1" encrypt="false"/>
<property name="thinkTimeOption" num_value="1.0" prop_type="2" encrypt="false"/>
<property name="fileSize" string_value="93699" prop_type="1" encrypt="false"/>
<property name="beaconDistributionOverride" string_value="people=1;middle=1" prop_type="1" encrypt="false"/>
<property name="FilePropertyValue" prop_type="7" encrypt="false"/>
<property name="databankFilesJar" prop_type="7" encrypt="false"/>
<property name="databankFiles" string_value="people,people.csv,3;middle,middle.csv,3;" prop_type="1" encrypt="false"/>
<property name="granularity" string_value="transaction" prop_type="1" encrypt="false"/>
<property name="thinkTimeMinSec" num_value="0.0" prop_type="2" encrypt="false"/>
<property name="oatsVersion" string_value="9.1.0" prop_type="1" encrypt="false"/>
<property name="databankValues" string_value="people.firstname=yang.,people.lastName=wang,middle.middlename_col=x." prop_type="1" encrypt="false"/>
<property name="modules" string_value="oracle.oats.scripting.modules.utilities;version=2.4.0&#xA;oracle.oats.scripting.modules.http;version=2.4.0&#xA;oracle.oats.scripting.modules.basic;version=2.4.0" prop_type="1" encrypt="false"/>
<property name="databankAliasMapping" string_value="middle=middle.csv,people=people.csv" prop_type="1" encrypt="false"/>
</properties>
<per_bcn_properties/>
</mgmt_bcn_txn_with_props>
<steps_defn_with_props/>
<stepgroups_defn/>
<txn_thresholds/>
<step_thresholds/>
<stepgroup_thresholds/>
</mgmt_bcn_transaction>
</transactions>
</transaction-template>

2. ATSTest1という名前の新しいデータバンク・ファイルをサービスmy_serviceのATSテスト・タイプにアップロードします。

emcli upload_ats_test_databank_file  -name='my_service' -type='generic_service' -testname='ATSTest1' -testtype='OATS'  -databankAlias='alias1' -input_file='databank:databankFile.csv'
Where,
-input_file=databank: contains the databank file path

3. サービスmy_serviceに対して、テストATSTest1を有効にします。

emcli enable_test -name="my_service" -type="generic_service"   -testname="ATSTest1" -testtype="OATS"

A.6.8 Java EEアプリケーションのデプロイおよびアンデプロイ

このユースケースは、Cloud Controlで使用可能なEM CLIコマンドを使用して、Java EEアプリケーションをデプロイ、アンデプロイおよび再デプロイする方法を説明します。

次の手順に従います。

1. デプロイメント・プロシージャのGUIDを取得するには、次のコマンドを実行します。

./emcli get_procedures

For example:

./emcli get_procedures | grep JAVAEE_

F7A60FD5AF1B3E8FE043D97BF00AC094  Java EE Application Provisioning JAVAEE_APP_ORACLE_SOFTWARE Deploy/Undeploy Java EE Applications 1.2 ORACLE

2. 前のステップで取得したGUIDを使用して、次のコマンドを使用してプロパティ・ファイル・テンプレートを準備します。

./emcli describe_procedure_input - procedure=<proc_guid> -name = <proc_name>

For example:
emcli describe_procedure_input -procedure=F7A60FD5AF1B3E8FE043D97BF00AC094 > inst.properties
properties file with the name inst.properties is created

3. エディタを使用して、生成されたプロパティ・ファイルinst.propertiesを開きます。次にサンプルのプロパティ・ファイルを示します。

# Input properties are:
deployMode=true
domains.0.continueOnDeployError=true
domains.0.domainName=
domains.0.javaeeApps.0.appHome=n/a
domains.0.javaeeApps.0.appName=ExampleApp
domains.0.javaeeApps.0.appVer=n/a
domains.0.javaeeApps.0.archivePath=/tmp/ExampleApp.ear
domains.0.javaeeApps.0.copyComponents=true
domains.0.javaeeApps.0.copyingComponentsList.0.componentPath=swlib/ExampleApp
domains.0.javaeeApps.0.copyingComponentsList.0.defaultHostCred=PREF:HostCredsNormal
domains.0.javaeeApps.0.copyingComponentsList.0.destinationDirectory=/tmp/destinationDir
domains.0.javaeeApps.0.copyingComponentsList.0.fileNameWithoutPath=ExampleApp.war
domains.0.javaeeApps.0.copyingComponentsList.0.name=host.us.example.com
domains.0.javaeeApps.0.copyingComponentsList.0.type=host
domains.0.javaeeApps.0.defaultHostCred=PREF:HostCredsNormal
domains.0.javaeeApps.0.deleteTarget=
domains.0.javaeeApps.0.deplMode=Deploy
domains.0.javaeeApps.0.domainName=
domains.0.javaeeApps.0.isSharedLib=false
domains.0.javaeeApps.0.name=host.us.example.com
domains.0.javaeeApps.0.planPath=n/a
domains.0.javaeeApps.0.postDeployScript=n/a
domains.0.javaeeApps.0.preDeployScript=n/a
domains.0.javaeeApps.0.retirementPolicy=true
domains.0.javaeeApps.0.retirementTimeout=0
domains.0.javaeeApps.0.runExecutionScript=false
domains.0.javaeeApps.0.stageMode=DEFAULT
domains.0.javaeeApps.0.startMode=full
domains.0.javaeeApps.0.targets="ManagedServer_1"
domains.0.javaeeApps.0.type=host
domains.0.javaeeApps.0.wlsAdminURL=t3s://host.us.example.com:7022
# domains.0.javaeeApps.0.wlsDomainPassword=***
domains.0.javaeeApps.0.wlsDomainUserName=weblogic
domains.0.javaeeApps.0.wlsHome=/tmp/work/middleware/wlserver_10.3
domains.0.name=host.us.example.com
domains.0.stopOnDeployError=false
domains.0.type=host
undeployMode=false

4. 生成されたinst.propertiesプロパティ・ファイルを入力としてプロシージャを発行します。

./emcli submit_procedure -input_file=data:<input_properties_file> -procedure=<proc_guid> -instance_name=<optional_DP_Instance_Name>

For example:

./emcli submit_procedure -input_file=data:inst.properties -procedure=F7A60FD5AF1B3E8FE043D97BF00AC094

A.7 Enterprise Managerコマンドライン・インタフェースの使用に関する制限事項

次に、デプロイメント・プロシージャを実行するためのEM CLIの使用に関する制限事項を示します。

- EM CLIコマンドを使用してステップとフェーズの追加または編集を行うことはできません。これを実行するには、Cloud Controlにログインし、項33.2.1の手順を実行する必要があります。

- デプロイメント・プロシージャで使用される新しい変数はEM CLIでは定義できません。Cloud Control UIのみで定義できます。プロシージャ変数の詳細は、項32.3.2を参照してください。

- インスタンスの詳しい実行情報(失敗など)は、EM CLIでは追跡できません。Cloud Control UIでは可能です。

- My Oracle Supportの優先資格証明を設定するには、Enterprise Manager Cloud Controlにログインする必要があります。これを実行するコマンドライン・オプションはありません。

B プロビジョニング前またはパッチ適用前のホスト準備状況のチェック

ここでは、プロビジョニングおよびパッチ適用タスクのためにホストを使用する前に、ホストに対して行う必要がある設定について説明します。特に、次の内容について説明します。

- プロビジョニング前のユーザー・アカウントの設定

- シェル制限

- rootの設定(権限の委任)

- 環境設定

- 記憶域要件

- インストール・ディレクトリとOracleインベントリ

B.1 プロビジョニング前のユーザー・アカウントの設定

データベースのプロビジョニングでホストを使用するには、oinstall、dba、operおよびasmadminなどのグループが設定されていることを確認する必要があります。また、これらのプロビジョニング・タスクを実行するユーザーを、これらのグループに追加する必要があります。次のグループを作成し、ホスト・ユーザーがそれらのグループに含まれることを確認するには、次のコマンドを実行できます。

- データベース・グループを作成する場合:

- groupadd oinstall

- groupadd dba

- groupadd oper

- groupadd asmadmin

- これらのグループにホスト・ユーザーを追加するには、次のコマンドを実行し、プロンプト表示されたらパスワードを入力します。
useradd -u 500 -g oinstall -G dba,oper,asmdba oracle

各パラメータの意味は次のとおりです。

-uオプションは、ユーザーIDを指定します。

-gオプションはプライマリ・グループを指定します。プライマリ・グループは、oinstallなどのOracleインベントリ・グループである必要があります。

-Gオプションは、セカンダリ・グループを指定します。これは、OSDBAグループ、および必要に応じてOSOPERグループおよびASMDBAグループを含む必要があります(dba、asmdbaまたはoper)。

B.1.1 SSHの構成

クラスタ環境の場合、クラスタの各ノードにSSHを構成するには、Oracleユーザーとしてログインし、すべてのノードで次のコマンドを実行する必要があります。

su - oracle
mkdir ~/.ssh
chmod 700 ~/.ssh
/usr/bin/ssh-keygen -t rsa # Accept the default settings

B.2 シェル制限

Linuxシステムでソフトウェアのパフォーマンスを向上させるには、Oracleソフトウェア所有者ユーザー(crs、oracle、asmなど)に対する次のシェル制限を増やします。このためには、次のコマンドを実行します。

- /etc/security/ディレクトリにあるlimits.confファイルに次の値を追加します。

- oracle soft nproc 2047

- oracle hard nproc 16384

- oracle soft nofile 1024

- oracle hard nofile 65536

- 次の行を/etc/pam.d/loginファイルに追加します。つまり、この行がまだ存在していない場合は、この行を含むように/etc/pam.d/loginファイルを編集します。
session required pam_limits.so

B.3 rootの設定(権限の委任)

アプリケーションのプロビジョニングでは、一部のスクリプトをスーパー・ユーザーとして実行する必要があります。このためには、ホスト・ユーザーにroot権限があることを確認してください。他のユーザーのroot権限を承認するには、SUDOやPowerBrokerなどの認証ユーティリティを使用できます。このサポートは権限委任メカニズムを使用してCloud Controlで提供されます。技術的には、権限委任とは、SUDOまたはPowerBrokerを使用して、別のユーザー(ロックされたアカウント)の権限に関するアクティビティを実行できるフレームワークです。

権限委任設定の構成の詳細は、第2.3項を参照してください。

B.4 環境設定

プロビジョニング・タスクを進める前に、次の推奨ホスト設定を満たすようにしてください。

- カーネル要件

- ノード時刻要件

- パッケージ要件

- メモリーおよびディスク領域の要件

- ネットワークおよびIPアドレスの要件

注意:
すべての推奨パラメータの詳細は、http://www.oracle.com/technetwork/topics/linux/validated-configurations-085828.htmlを参照してください。

B.4.1 カーネル要件

次の表に示すコマンドを入力して、カーネル・パラメータの現行の値を表示します。現行の値をメモし、変更が必要な値を識別します。どの既存値を変更する場合も、/etc/sysctl.confファイルで変数値を追加または編集する必要があります。

注意:
現行のカーネル・パラメータを変更するには、rootユーザー権限を使用して次のコマンドを実行します。
/sbin/sysctl -p

パラメータ

コマンド

semmsl、semmns、semopmおよびsemmni

# /sbin/sysctl -a | grep sem
このコマンドでは、リストされた順にセマフォ・パラメータの値が表示されます。

shmall、shmmaxおよびshmmni

# /sbin/sysctl -a | grep shm
このコマンドでは、共有メモリーのセグメント・サイズの詳細が表示されます。

file-max

# /sbin/sysctl -a | grep file-max
このコマンドでは、最大ファイル・ハンドラ数が表示されます。

ip_local_port_range

# /sbin/sysctl -a | grep ip_local_port_range
このコマンドでは、ポート番号の範囲が表示されます。

rmem_default

# /sbin/sysctl -a | grep rmem_default

rmem_max

# /sbin/sysctl -a | grep rmem_max

wmem_default

# /sbin/sysctl -a | grep wmem_default

wmem_max

# /sbin/sysctl -a | grep wmem_max

注意:
カーネル要件の詳細は、Oracle Databaseのインストレーション・ガイドを参照してください。これは、http://www.oracle.com/pls/db112/portal.portal_db?selected=11&frame=#linux_installation_guidesで入手できます。

B.4.2 ノード時刻要件

クラスタ環境の場合、クラスタの各メンバー・ノードができるだけ近い日時になるように設定してください。このためには、すべてのノードで同一のネットワーク・タイム・プロトコル・サーバーを参照して、オペレーティング・システムのネットワーク・タイム・プロトコル(NTP)機能を使用することをお薦めします。

Oracleクラスタ時刻同期化サービス(ctssd)でOracle RACノードの時刻を同期化するには、NTPを構成する必要があります。NTPを使用している場合は、次の手順を実行します。

1. 次のように、-xオプションを/etc/sysconfig/ntpdファイルに追加し、ntpdを起動します。
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"

2. ネットワーク・タイム・プロトコル・サーバーを再起動します。
# service ntpd restart

3. 次の構成レベルをチェックします。
chkconfig --level 35 nscd on

4. ネーム・サービス・キャッシュ・デーモン(nscd)を起動します。
service nscd start

B.4.3 パッケージ要件

rootユーザーとして次のコマンドを実行し、必要なパッケージがインストールされていることを確認します。

rpm -q binutils elfutils-libelf elfutils-libelf-devel glibc glibc-common glibc-devel gcc gcc-c++ libaio libaio-devel libstdc++ libstdc++-devel make compat-libstdc++ sysstat unixODBC unixODBC-devel iscsi-initiator-utils libgcc

パッケージがインストールされていない場合、次のリンクを参照して、必要なパッケージをダウンロードしてインストールします。

http://www.oracle.com/technetwork/topics/linux/validated-configurations-085828.html

B.4.4 メモリーおよびディスク領域の要件

ホストが次のメモリー要件を満たしていることを確認します。

1. 少なくとも1GBの物理RAMが必要です。ホストの現在の物理RAMサイズを判別するには、次のコマンドを実行します。
grep MemTotal /proc/meminfo

2. 次の表は、インストールされているRAMと構成済スワップ領域の推奨サイズの関係を示したものです。

使用可能なRAM

スワップ領域要件

1から2GB

RAMサイズの1.5倍

2GBから8GB

RAMサイズと同等

8GB超

RAMサイズの0.75倍

3. 次のコマンドを実行して、/tmpディレクトリで使用できるディスク領域の大きさを確認します。
df -kh /tmp

B.4.5 ネットワークおよびIPアドレスの要件

クラスタ環境の場合、少なくとも2つのネットワーク・アダプタまたはネットワーク・インタフェース・カード(NICs)が各ノードにあることを確認します。一方はパブリック・ネットワーク・インタフェース用、もう一方はプライベート・ネットワーク・インタフェース(インターコネクト)用です。

ネットワーク構成の要件は次のとおりです。

パブリック・ネットワーク・インタフェース

プライベート・ネットワーク・インタフェース

各ネットワークのネットワーク・アダプタに関連付けられているパブリック・インタフェース名は、すべてのノードで同じである必要があります。

ネットワーク・アダプタに関連付けられているプライベート・インタフェース名は、すべてのノードで同じである必要があります。

各ネットワーク・アダプタはTCP/IPをサポートする必要があります。

インターコネクトにTCP/IPをサポートする高速ネットワーク・アダプタおよびスイッチ(ギガビット・イーサネット以上が必要)を使用して、ユーザー・データグラム・プロトコル(UDP)がサポートされている必要があります。
注意: プライベート・ネットワークでは、指定されているすべてのインターコネクト・インタフェースのエンドポイントがネットワークで確実にアクセス可能である必要があります。ノードはすべてのプライベート・ネットワーク・インタフェースに接続されている必要があります。pingコマンドを使用して、インターコネクト・インタフェースが接続可能かどうかをテストできます。

インストールを開始する前に、各ノードで使用可能な次のIPアドレスを準備しておく必要があります。

1. パブリック・インタフェースのDNSに登録されているIPアドレスおよび対応するホスト名(ネットワーク名)。使用可能なDNSがない場合は、システムのhostsファイル(/etc/hosts)にホスト名とIPアドレスを記述します。

2. DNSに登録されている仮想IP(VIP)アドレスおよび対応するホスト名。使用可能なDNSがない場合は、システムのhostsファイル(/etc/hosts)にホスト名とVIPアドレスを記述します。

3. 各プライベート・インタフェースのプライベートIPアドレスおよびホスト名。

たとえば、各ノードに1つのパブリック・インタフェースと1つのプライベート・インタフェースがある2ノードのクラスタの場合、ネットワーク・インタフェースとして、次の表に示す構成が考えられます。ここでは、hostsファイルは/etc/hostsです。

VIPのフェイルオーバーを有効にするために、前述の表に示す構成では、同じサブネット(143.46.43)で両方のノードのパブリックおよびVIPアドレスを定義しています。

B.5 記憶域要件

Oracle Clusterwareファイルの格納には、次の2つの方法があります。

- Oracle Automatic Storage Management (Oracle ASM): Oracle Clusterwareファイル(Oracle Cluster Registryおよび投票ディスク)をOracle ASMのディスク・グループにインストールできます。

- サポートされている共有ファイル・システム: サポートされているファイル・システムには、NFSやOCFSがあります。

次の表に、Oracle ClusterwareとOracle RACの様々なオプションを示します。

次の表に、ファイル・システムのボリューム・サイズ要件を示します。

B.6 インストール・ディレクトリとOracleインベントリ

Oracle製品をプロビジョニングする予定のインストール・ディレクトリがクリーンアップされていることを確認します。Optimal Flexible Architecture (OFA)標準では、Oracleベースのディレクトリが次のパスにあることが必要です。

/mount_point/app/oracle_sw_owner

ここで、mount_pointは、Oracleソフトウェアを含むファイル・システムのマウント・ポイント・ディレクトリです。

注意:
インストールを実行するユーザーがマウント・ポイントに対する書込みアクセス権を持っていることを確認します。必要な権限がユーザーにあることを確認するには、次のコマンドを実行します。
chown -R oracle:oinstall <mount point>

次に例を示します。

マウントの際に権限がない場合:

[root@node2-pub ~]# mkdir -p /u01/app/test

[root@node2-pub ~]# permission denied

権限の問題を解決するには、次のコマンドを実行します。

[root@node2-pub root]# chown -R oracle:oinstall /u01

C emctl partoolユーティリティの使用

ここでは、emctl partoolユーティリティの概要を示し、デプロイメント・プロシージャのPARファイルとしてのエクスポートやPARファイルのインポートなど、クリティカルなタスクの実行に使用する方法について説明します。特に、次の内容について説明します。

- プロビジョニング・アーカイブ・ファイルの概要

- emctl partoolユーティリティの概要

- Oracleソフトウェア・ライブラリのチェック

- デプロイメント・プロシージャのエクスポート

- PARファイルのインポート

注意:
Enterprise Manager 12cよりも前のバージョンでエクスポートされたプロビジョニング・アーカイブ・ファイルは、Enterprise Manager 12cにインポートできません。

C.1 プロビジョニング・アーカイブ・ファイルの概要

プロビジョニング・アーカイブ(PAR)ファイルは、コレクションを含むアーカイブ・ファイルです。このコレクションは、多数のライフサイクル管理タスク(アプリケーションのプロビジョニングやパッチ適用など)で使用される、デプロイメント・プロシージャとソフトウェア・ライブラリ・エンティティのバンドルです。

デプロイメント・プロシージャの場合、partoolはユーザー定義プロシージャのみをエクスポートし、Oracle所有のプロシージャはエクスポートされません。ユーザー定義プロシージャをエクスポートする際には、デプロイメント・プロシージャがすべてエクスポートされるわけではなく、カスタマイズ(変更の差分)のみがエクスポートされます。

また、アップグレードの場合には、12cより前に作成されたプロシージャをpartoolユーティリティですべてエクスポートできるわけではないことにも注意してください。

注意:
ソフトウェア・ライブラリ・エンティティを含むPARファイルをインポートする場合は、自らのソフトウェア・ライブラリが構成されていることを確認します。ソフトウェア・ライブラリの構成の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。

C.2 emctl partoolユーティリティの概要

時間の経過につれて、デプロイメント・プロシージャをカスタマイズしている可能性がありますが、このようなデプロイメント・プロシージャをCloud Controlの別のインスタンスで再利用するとします。このような状況では、カスタマイズしたデプロイメント・プロシージャをCloud Controlのインスタンスからエクスポートして、Cloud Controlの別のインスタンスにデプロイすることができます。

emctl partoolユーティリティは、コマンドライン・インタフェースを使用してこれらの機能を実行するためのCloud Control提供のツールです。emctl partoolユーティリティの基本機能は次のとおりです。

- デプロイメント・プロシージャと関連するコンポーネントやディレクティブをPARファイルとしてエクスポートします。

- PARファイルをCloud Controlの同一インスタンスまたは別のインスタンスにインポートします。

emctl partoolユーティリティは$ORACLE_HOME/binディレクトリにあります。

次のように、$ORACLE_HOME/bin/emctl partoolを実行した場合、使用状況に関する情報が表示されます。

emctl partool <deploy|view> -parFile <file> -force(optional)
emctl partool <deploy|view> -parFile <file> -force(optional) -ssPasswd <password>
emctl partool <deploy|view> -parDir <dir> -force(optional)
emctl partool export -guid <procedure guid> -file <file>  -displayName <name> -description <desc> -metadataOnly(optional)
emctl partool check
emctl partool help

表C-1に、emctl partoolユーティリティで使用できる追加オプションを示します。

表C-1 emctl partoolのオプション

オプション

説明

-repPasswd <repPassword>

リポジトリのパスワードを指定します。-repPasswdがコマンドラインに指定されない場合は、リポジトリのパスワードを入力するようにユーザーが求められます。

注意: コマンドラインでのパスワードの指定は安全性が低いため、本番環境では行わないでください。

-force

ソフトウェア・ライブラリ・エンティティの再作成または再アップロードを強制的に行います。すでに存在する場合は、新しいバージョンが作成されます。

check

ソフトウェア・ライブラリが構成されているかどうかをチェックします。

-file <file>

PARファイルを指定します。

-action <deploy|view|export>

PARファイルのデプロイ、表示またはエクスポートを指定します。

-verbose

冗長モードを指定します。

help

ヘルプ情報を表示します。

-displayName <displayName>

PARファイル名を示します。

-parDir <dir>

PARファイルが存在する場所。

-metadataOnly

メタデータのみをエクスポートするためのフラグ。

-guid <guid>

エクスポートするプロシージャGUID。

複数のプロシージャをエクスポートするときは、GUIDを「,」で区切って指定します。

-parFile <file>

PARファイルのパス。

-description <description>

PARファイルの説明。

-ssPasswd <secretStorePassword>

これはオプションです。

-action exportと一緒に使用する場合 - エクスポートされるソフトウェア・ライブラリ・エンティティのいずれかにシークレット・プロパティが含まれる場合、シークレット・プロパティの値を格納するためにOracle Walletが作成されます。指定したパスワードを使用してOracle Walletが作成されます。-ssPasswdスイッチを使用するが、コマンドライン引数としてパスワードを指定しないと、パスワードの入力を求められます。新しいリポジトリにPARファイルをインポートするときは、同じパスワードを使用する必要があります。

-action <deploy|view>と一緒に使用する場合 - パスワード保護されたOracle Wallet (エンティティのシークレット・プロパティ値を含む)がPARファイルに含まれる場合、このストアを開くためにこのパラメータが必要です。-ssPasswdスイッチを使用するが、コマンドライン引数としてパスワードを指定しないと、パスワードの入力を求められます。

C.3 Oracleソフトウェア・ライブラリのチェック

emctl partoolユーティリティを実行してPARファイルをエクスポートまたはインポートする前に、$ORACLE_HOME環境変数にOracle Management Service (OMS)のOracleホーム・ディレクトリが設定され、ソフトウェア・ライブラリのパスが構成されていることを確認します。

ソフトウェア・ライブラリをチェックするには、次のコマンドを実行します。

$ORACLE_HOME/bin/emctl partool check

C.4 デプロイメント・プロシージャのエクスポート

デプロイメント・プロシージャをエクスポートするには、まずそれらのデプロイメント・プロシージャのGUIDを取得する必要があります。その後、emctl partoolユーティリティを実行してPARファイルを作成します。この項の内容は次のとおりです。

- デプロイメント・プロシージャのGUIDの取得

- PARファイルの作成

C.4.1 デプロイメント・プロシージャのGUIDの取得

Cloud Controlを使用してデプロイメント・プロシージャのGUIDを取得するには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」をクリックします。

2. プロビジョニング・ページで、デプロイメント・プロシージャ名を右クリックし、メニューからリンク場所のコピーを選択します。

3. コピーしたリンクをメモ帳に貼り付けて、guidを探します。

例: https://adc2171248.us.example.com:14500/em/console/paf/procedureView?guid=B3B4B6C76AE46A67E040E50A65751782

GUIDはB3B4B6C76AE46A67E040E50A65751782です。

または、次のEMCLIコマンドを使用してプロシージャのGUIDを取得できます。

emcli get_procedures [-type={procedure type}] [-parent_proc={procedure associate with procedure configuration}]

Example:
emcli get_procedures -type=DemoNG -parent_proc=ComputeStepTest

Output Column:
GUID, Procedure type, name, display name, version, Parent procedure name

注意:
EMCLIの設定の詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。

C.4.2 PARファイルの作成

1つ以上のデプロイメント・プロシージャを含むPARファイルを作成するには、exportオプションをactionに指定し、エクスポートするデプロイメント・プロシージャのGUIDを指定して、emctl partoolユーティリティを実行します。GUIDはカンマで区切ってください。

$ORACLE_HOME/bin/emctl partool export -guid <GUID> -file exportedDP.par -displayName "User exported DP" -description "<description>"

たとえば、エクスポートするデプロイメント・プロシージャのGUIDがFAC05DD31E3791C3E030579D23106C67の場合は、次のコマンドを実行します。

$ORACLE_HOME/bin/emctl partool export -guid FAC05DD31E3791C3E030579D23106C67 -file exportedDP.par -displayName "User exported DP" -description "Deployment Procedure to be copied to other OMS"

このコマンドを実行すると、exportedDP.parという名前の新しいPARファイルが、コマンドを実行したディレクトリに作成されます。このPARファイルは、Cloud Controlの同じインスタンスまたは別のインスタンスに何回でもインポートできます。

複数のデプロイメント・プロシージャをエクスポートするには、次のようにGUIDをカンマで区切って指定します。

$ORACLE_HOME/bin/emctl partool export -guid "06B62B6ED5DA20BCE040578C850862A7,0C96E96D9818BC5FE040578C8508620F,09AEFF331025AAD0EE40578C85FB5772" -file $ENV{T_WORK}/tvmgf_partool_multi_dp.par -displayName "partool multi dp test" -description "partool multi dp test description" -repPasswd sysman

注意:
emctl partoolを使用してプロシージャをエクスポートすると、プロシージャで参照されるディレクティブまたはコンポーネントもエクスポートされます。ただし、エクスポートされるのはこれらのディレクティブまたはコンポーネントの最新バージョンのみです。コンポーネントまたはディレクティブをエクスポートしない場合は、emctl partoolを実行するときに-metadataOnlyフラグを指定します。

C.5 PARファイルのインポート

PARファイルは、コマンドライン・インタフェースまたはCloud Controlで提供されるグラフィカル・ユーザー・インタフェース(コンソール)を使用してインポートできます。この項の内容は次のとおりです。

- コマンドライン・インタフェースを使用したインポート

- Cloud Controlコンソールを使用したインポート

注意:
既存のPARファイル(以前のリリース)のEnterprise Manager Cloud Control 12cへのインポートはサポートされていません。たとえば、Enterprise Manager 11g Grid Controlリリース1 (11.1.0.0)をEnterprise Manager Cloud Control 12cにインポートすることはできません。

C.5.1 コマンドライン・インタフェースを使用したインポート

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

- 特定のPARファイルのインポート

- すべてのPARファイルのインポート

C.5.1.1 特定のPARファイルのインポート

特定のPARファイルをインポートまたはデプロイするには、次のコマンドを実行します。

$ORACLE_HOME/bin/emctl partool deploy -parFile $ORACLE_HOME/sysman/prov/paf/<par_file_name>

次に例を示します。

$ORACLE_HOME/bin/emctl partool deploy -parFile $ORACLE_HOME/sysman/prov/paf/asprov.par

注意:
ソフトウェア・ライブラリまたはプロシージャがすでにEnterprise Managerに存在しているときに、PARファイルの新しいリビジョンを作成する場合は、次のように-force属性を使用します。
$ORACLE_HOME/bin/emctl partool deploy -parFile $ORACLE_HOME/sysman/prov/paf/asprov.par -force

注意:
複数のOMSが環境にある場合でも、PARファイルをデプロイしたり他の関連操作を実行したりするためにemctl partoolユーティリティを実行するのは1回のみです。

PARファイルのインポート時に、ユーザー・プロシージャがすでに設定に存在する場合は、常に改訂(増加)後のバージョンでこのプロシージャがインポートされます。

C.5.1.2 すべてのPARファイルのインポート

ディレクトリ内のすべてのPARファイルをインポートまたはデプロイするには、次のコマンドを実行します。

$ORACLE_HOME/bin/emctl partool deploy -parDir $ORACLE_HOME/sysman/prov/paf/ -force

C.5.2 Cloud Controlコンソールを使用したインポート

OMSにPARファイルをインポートまたはデプロイするには、emctl partoolユーティリティを使用します。または、Cloud Controlからインポートすることもできます。

PARファイルをインポートするには、次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「プロシージャ・ライブラリ」をクリックします。

2. 「デプロイメント・プロシージャ・マネージャ」ページでプロシージャを選択し、ドロップダウン・メニューから「インポート」を選択して、「実行」をクリックします。

3. プロシージャ・ファイルのアップロード・ページで次のいずれかを選択します。

- ローカル・マシンからアップロード: PARファイルをローカル・マシンからアップロードします。「参照」をクリックしてPARファイルを選択します。ファイルをインポートするには「インポート」をクリックします。

- 管理エージェント・マシンからアップロード: 管理エージェント・ターゲットを選択します。ファイルが存在する管理エージェント・マシンにアクセスするための通常または特権ホスト資格証明の詳細を入力してから、「インポート」をクリックしてファイルをインポートします。

関連項目:
「プロシージャ・ファイルのアップロード」機能の使用に関するユースケースは、第51.6項を参照してください。

注意:
シークレット・プロパティ値を含むコンポーネントまたはディレクティブ(あるいは両方)をインポートまたはエクスポートするときは、-ssPasswdコマンドを使用し、Oracle Walletを作成するためにシークレット・ストアのパスワードを指定する必要があります。これにより、シークレット・プロパティ値がOracle Walletを使用して安全に格納されます。インポート時にはOracle Walletパスワードを使用しないとアクセスできません。
-ssPasswdコマンドの詳細は、表C-1を参照してください。

D PXEブートおよびKickstartテクノロジについて

ここでは、PXEブートおよびKickstartテクノロジについて次の項で説明します。

- PXEブートとKickstartテクノロジの概要

- サブネット・プロビジョニングのユースケース

D.1 PXEブートとKickstartテクノロジの概要

プロビジョニングの主要な要求の1つが、ディスクやCD-ROMにかわるネットワークを介してのハードウェア・サーバーのブート機能です。ネットワークを介してコンピュータをブートする方法はいくつかあり、Preboot Execution Environment(PXE)はその1つです。PXEは、いくつかのハードウェア・ベンダーおよびソフトウェア・ベンダーによってサポートされているオープンな業界標準です。PXEはWired for Management (WfM)仕様に含まれます。これは、1998年にIntelとMicrosoftによって定められたPC98仕様の一部です。PXEの仕様の詳細は、http://www.pix.net/software/pxeboot/archive/pxespec.pdfを参照してください。

PXEはシステムのネットワーク・インタフェース・カード(NIC)と連動し、NICをブート・デバイスのように使用します。クライアントのPXE対応NICは、ブロードキャスト・リクエストをDHCPサーバーに送信します。サーバーは、クライアントのIPアドレスの他に、TFTPサーバーのアドレスとTFTPサーバー上のブート・ファイルの場所を返します。この仕組みを次の手順で説明します。

1. ターゲット・マシン(ベアメタルまたはブート・セクターを除去したマシン)がブートされます。

2. マシンのネットワーク・インタフェース・カード(NIC)がDHCPリクエストをトリガーします。

3. DHCPサーバーがリクエストをインターセプトして、標準の情報(IP、サブネット・マスク、ゲートウェイ、DNSなど)で応答します。また、TFTPサーバーの場所とブート・イメージ(pxelinux.0)の情報も提供します。

4. クライアントはこの情報を受信すると、ブート・イメージを取得するためにTFTPサーバーにアクセスします。

5. TFTPサーバーはブート・イメージ(pxelinux.0)を送信し、クライアントがそれを実行します。

6. デフォルトでは、ブート・イメージは、TFTPサーバーのpxelinux.cfgディレクトリでTFTPサーバーのブート構成ファイルを、次の方法を使用して検索します。
まず、MACアドレスに対応する名前(16進数が小文字で表記されハイフンで区切られたもの)のブート構成ファイルを検索します。たとえば、MACアドレスが88:99:AA:BB:CC:DDの場合は、01-88-99-aa-bb-cc-ddというファイルを検索します。

次に、ブートされるマシンのIPアドレスに対応する名前(大文字の16進数)の構成ファイルを検索します。たとえば、IPアドレスが192.0.2.91の場合は、C000025Bというファイルを検索します。

このファイルが見つからない場合は、末尾の16進数を1つ削除して再試行します。この方法でも見つからない場合は、default (小文字)という名前のファイルを検索します。

たとえば、ブート・ファイル名が/tftpboot/pxelinux.0、Ethernet MACアドレスが88:99:AA:BB:CC:DD、IPアドレスが192.0.2.91の場合、ブート・イメージは次の順序でファイル名を検索します。

/tftpboot/pxelinux.cfg/01-88-99-aa-bb-cc-dd
/tftpboot/pxelinux.cfg/C000025B
/tftpboot/pxelinux.cfg/C000025
/tftpboot/pxelinux.cfg/C00002
/tftpboot/pxelinux.cfg/C0000
/tftpboot/pxelinux.cfg/C000
/tftpboot/pxelinux.cfg/C00
/tftpboot/pxelinux.cfg/C0
/tftpboot/pxelinux.cfg/C

7. クライアントが、必要なすべてのファイル(カーネルおよびルート・ファイル・システム)をダウンロードし、それらをロードします。

8. ターゲット・マシンがリブートします。
プロビジョニング・アプリケーションは、RedhatのKickstart方法を使用してターゲット・マシンでのRedhat Linuxのインストールを自動化します。Kickstartを使用すると、システム管理者は、一般的なRed Hat Linuxのインストールの際に尋ねられるすべての質問の答えを含む1つのファイルを作成できます。

ホスト固有のブート構成ファイルには、kickstartファイルの場所が含まれます。このkickstartファイルは、ユーザーの入力に基づいてOSイメージのステージング・ディレクティブによって事前に作成されます。

D.2 サブネット・プロビジョニングのユースケース

次にサブネット・プロビジョニングのユースケース例を示します。

サイズ256のサブネット

IP接頭辞: 192.168.1.0

サブネット・マスク: 255.255.255.0

IPの範囲 - 192.168.1.0から192.168.1.255

サイズ16のサブネット

IP接頭辞: 192.168.1.0

サブネット・マスク: 255.255.255.240

E エンドツーエンド・ユースケース: データ・センターのパッチ適用

この付録では、Enterprise Managerを使用して、管理者がデータ・センター全体にパッチを公開する方法を説明します。

この章は次の項で構成されています。

- データ・センターへのパッチ適用の課題

- Enterprise Managerソリューション

- サンプル・シナリオの実行

E.1 データ・センターへのパッチ適用の課題

どのような企業でも、データ・センターは、IT機能の稼働を維持してビジネスを遂行するためにクリティカルな役割を果しています。データ・センターの規模は企業によって様々ですが、データ・センターがビジネスの成功にとってクリティカルであるという事実に疑問の余地はありません。

データ・センターの管理者は、連日、データ保守、データ・バックアップ、ライフサイクル管理の操作を行っています。こうしたシステム管理アクティビティを実行する際に管理者が直面する課題がきわめて大きいこともあります。データ・センターが複数のタイム・ゾーンにまたがって距離が離れている場合、このような問題はさらに深刻になります。

管理者が恒常的に直面するライフサイクル管理の課題の1つは、エコシステム全体にパッチを適用して、データ・センターをセキュアかつ最新の状態に保つことです。複数のタイプのパッチがある場合、この要件はさらに複雑になります。データ・センターに関連するパッチを特定するのが困難であり、パッチ適用操作全体が手動で、エラーが発生しやすく時間もかかるためです。

E.2 Enterprise Managerソリューション

これ以降の項では、Enterprise Managerの機能を活用した、前述の課題に対するソリューションを提供します。1つに統合されたパッチ適用ワークフローを使用することが目標です。データ・センターに関連するパッチを特定できるだけではなく、パッチのダウンロードから公開まで自動的に行えるようにします。また、データ・センターのポリシーと標準に100%準拠できるようにします。

このユースケースの基本フローは次のとおりです。

E.2.1 データ・センターに関連するパッチの特定

Enterprise Managerによって提供されるパッチ推奨を使用して、データ・センターに関連するパッチを特定します。パッチ推奨は、潜在的なシステム上の問題と、システム・パフォーマンスの向上やシステム停止の回避を支援する推奨に関するプロアクティブな通知です。推奨されるパッチは、セキュリティ・パッチと、企業の構成に基づくその他のパッチです。

E.2.2 パッチの公開計画の準備、テストおよび認定

環境を分析して、データ・センターのターゲットにパッチを適用できるかどうかを確認します。パッチを適用できることを確認したら、推奨されたパッチでパッチ計画を作成し、パッチ計画を使用してパッチをテストし、事前にパッチの競合をすべて診断して解決しておきます。パッチ計画がデプロイ可能な状態になったら、パッチ計画をテンプレートに変換することで認定します。

E.2.3 パッチを公開するための変更アクティビティ計画の作成

変更アクティビティ計画を作成します。具体的には、ターゲット・タイプを関連付け、実行する一連のタスク(パッチ適用前と後のタスクを含む)を作成し、使用するパッチ計画テンプレートを選択し、パッチ適用手順の優先度を指定し、データ・センターでの正式公開のために変更アクティビティ計画のスケジュールを設定します。

E.2.4 変更アクティビティの進捗の監視とステータスの報告

様々な変更アクティビティの進捗を監視し、パッチ公開操作のステータスを追跡し、ドリフトがあれば識別し、全体のステータスを管理職に報告します。

E.3 サンプル・シナリオの実行

次の表に、このサンプル・シナリオで実行されるタスクと、タスクを実行できるユーザー・ロールを示します。

タスク

ユーザー・ロール

必要なロールを持つ管理者の作成

EMスーパー管理者

インフラストラクチャの設定

EM_PATCH_DESIGNER

環境の分析およびターゲットにパッチを適用できるかどうかの確認

EM_PATCH_DESIGNER

関連するパッチの特定

EM_PATCH_DESIGNER

パッチ計画の作成、パッチのテストおよびパッチの認定

EM_PATCH_DESIGNER

パッチを公開するための変更アクティビティ計画の作成

EM_CAP_ADMINISTRATOR

パッチの公開

EM_CAP_USER

変更アクティビティのステータスのチェックおよび報告

EM_CAP_ADMINISTRATOR

ターゲットでのパッチ適用の確認

EM_CAP_ADMINISTRATOR

E.3.1 必要なロールを持つ管理者の作成

ロール: EMスーパー管理者

表E-1に示すロールを使用して、この章で説明するシナリオのために管理者を作成します。

表E-1 必要なロールを持つ管理者の作成

Enterprise Managerロール

権限

EM_PATCH_DESIGNER

CREATE_PATCH_PLAN、VIEW_ANY_PLAN_TEMPLATE

EM_CAP_ADMINISTRATOR

CREATE_JOB、CREATE_CAP_PLAN、BASIC_CAP_ACCESS

EM_CAP_USER

BASIC_CAP_ACCESS

これらのロールを持つ管理者を作成するための手順は、次のURLで説明する手順を参照してください。

http://docs.oracle.com/cd/E24628_01/em.121/e27046/infrastructure_setup.htm#BABGJAAC

E.3.2 インフラストラクチャの設定

ロール: EM_PATCH_DESIGNER

パッチのデプロイメントのためにオンライン・パッチ適用モードを使用することをお薦めします。オンライン・パッチ適用モードは、Enterprise Managerでのパッチ適用のデフォルト・モードです。したがって、初回は手動で設定する必要はありません。ただし、ある理由でオフライン・モードに設定し、オンライン・モードにリセットする場合、またはオンライン・モードが設定されていることを確認したい場合は、次のURLに記載されている手順に従ってください。

http://docs.oracle.com/cd/E24628_01/em.121/e27046/pat_mosem_new.htm#BABIGJHG

オンライン・モードでは、Enterprise ManagerはMy Oracle Supportに接続し、パッチ、パッチ・セットおよびARUシード・データ(製品、プラットフォーム、リリース、コンポーネント、動作保証詳細、パッチ推奨など)をダウンロードします。このために、Enterprise Managerでは、OMSホストで設定したインターネット接続を使用してMy Oracle Supportに接続します。ただし、環境でプロキシ・サーバーを設定している場合は、プロキシの詳細を登録する必要があります。Enterprise Managerにプロキシ・サーバーの詳細を登録するには、次のURLに記載されている手順を参照してください。

http://docs.oracle.com/cd/E24628_01/em.121/e27046/pat_mosem_new.htm#BGGIGCJD

E.3.3 環境の分析およびターゲットにパッチを適用できるかどうかの確認

ロール: EM_PATCH_DESIGNER

パッチ計画を作成してターゲットにパッチを適用する前に、パッチ適用機能レポートを表示して環境を分析し、パッチを適用するターゲットがパッチ適用操作に適しているかどうかを確認することをお薦めします。これらのレポートには、パッチ適用できるターゲットとパッチ適用できないターゲットのサマリーが記載されており、デプロイ可能なパッチ計画の作成に役立ちます。パッチ適用できない、設定内のターゲットの問題を識別し、それらの問題に対する推奨事項を提案します。

パッチ適用機能レポートは、Oracle Database、Oracle WebLogic ServerおよびOracle SOAインフラストラクチャのターゲットで使用できます。

パッチ適用機能レポートを表示するには、次のURLに記載されている手順を参照してください。

http://docs.oracle.com/cd/E24628_01/em.121/e27046/pat_mosem_new.htm#BGGDJDEC

E.3.4 関連するパッチの特定

ロール: EM_PATCH_DESIGNER

「パッチ推奨」リージョンを表示して、データ・センターに公開するために、推奨されているパッチの中から関連するものを特定します。「パッチ推奨」セクションに記載されているパッチは、MOS内で提供されたパッチのコレクションで、1つのグループとして1つ以上のターゲットに適用できます。

「パッチ推奨」リージョンでは、推奨パッチ・リストをドリルダウンして、詳細の表示、パッチのダウンロードまたはパッチ計画へのパッチの追加を行うことができます。

推奨されているパッチを表示するには、次のURLに記載されている手順を参照してください。

http://docs.oracle.com/cd/E24628_01/em.121/e27046/pat_mosem_new.htm#CHDCGJAJ

E.3.5 パッチ計画の作成、パッチのテストおよびパッチの認定

ロール: EM_PATCH_DESIGNER

推奨されたパッチでパッチ計画を作成し、パッチ計画を使用してパッチをテストし、事前にパッチの競合をすべて診断して解決しておきます。パッチ計画がデプロイ可能な状態になったら、パッチ計画をテンプレートに変換することで認定します。

パッチ計画を作成するには、次のURLに記載されている手順を参照してください。

http://docs.oracle.com/cd/E24628_01/em.121/e27046/pat_mosem_new.htm#CHDHBDCE

新しく作成したパッチ計画にアクセスするには、次のURLに記載されている手順を参照してください。

http://docs.oracle.com/cd/E24628_01/em.121/e27046/pat_mosem_new.htm#CHDIGHCF

パッチをパッチ計画に追加し、パッチを分析およびテストし、パッチ計画をパッチ・テンプレートとして保存するには、次のURLに記載されている手順(1)から手順(5)を実行し、手順(6)の「レビューおよびデプロイ」ページで「テンプレートとして保存」をクリックします。新規計画テンプレートの作成ダイアログで、パッチ・テンプレートの一意の名前を入力して「テンプレートの作成」をクリックします。

http://docs.oracle.com/cd/E24628_01/em.121/e27046/pat_mosem_new.htm#CHDHBEBD

E.3.6 パッチを公開するための変更アクティビティ計画の作成

ロール: EM_CAP_ADMINISTRATOR

変更アクティビティ計画を作成し、変更アクティビティを指定し、所有者をアクティビティに割り当てます。さらに、ターゲット・タイプを関連付け、実行する一連のタスク(パッチ適用前と後のタスクを含む)を作成し、使用するパッチ計画テンプレートを選択し、パッチ適用手順の優先度を指定し、データ・センターでの正式公開のために変更アクティビティ計画のスケジュールを設定します。

これを行うには、次のURLに記載されている手順を参照してください。

http://docs.oracle.com/cd/E24628_01/em.121/e27046/cap.htm#BEHGEIFD

E.3.7 パッチの公開

ロール: EM_CAP_USER

自分に割り当てられたタスクを確認し、タスクの終了予定日を監視し、パッチ適用前タスクを完了し、パッチ計画を公開し、パッチ適用後タスクをすべて完了し、タスク・ステータスを更新します。

これを行うには、次のURLに記載されている手順を参照してください。

http://docs.oracle.com/cd/E24628_01/em.121/e27046/cap.htm#BEHGFCFF

E.3.8 変更アクティビティのステータスのチェックおよび報告

ロール: EM_CAP_ADMINISTRATOR

作成した変更アクティビティ計画に含まれるタスクのステータスを追跡し、全体のステータスを管理職に報告します。

これを行うには、次のURLに記載されている手順を参照してください。

http://docs.oracle.com/cd/E24628_01/em.121/e27046/cap.htm#BEHICBJG

E.3.9 ターゲットでのパッチ適用の確認

ロール: EM_CAP_ADMINISTRATOR

パッチ適用対象として指定されたターゲットで、選択したパッチによるパッチ適用が正常に終了したことを確認します。

これを実行するには、次のURLに記載されているように、構成検索ライブラリでオラクル社提供の構成検索「Oracle製品に適用されたパッチの検索」を実行します。ターゲットに適用したパッチIDを検索します。検索結果に、そのパッチIDを含むすべてのターゲットがリスト表示されます。自分のリストのターゲットがこの検索結果に含まれることを確認します。

http://docs.oracle.com/cd/E24628_01/em.121/e27046/config_mgmt.htm#CHDEGHFG

F 問題のトラブルシューティング

ここでは、プロビジョニングやパッチ適用のデプロイメント・プロシージャを使用する際に発生する可能性がある一般的な問題の解決方法を説明します。特に、次の内容について説明します。

- データベース・プロビジョニングの問題のトラブルシューティング

- Linuxプロビジョニングの問題のトラブルシューティング

- パッチ適用の問題のトラブルシューティング

- Linuxでのパッチ適用問題のトラブルシューティング

- Linuxプロビジョニングのよくある質問

- 構成のリフレッシュ

- ログ・ファイルの確認

F.1 データベース・プロビジョニングの問題のトラブルシューティング

ここでは、一般的なデータベース・プロビジョニングの問題に関してトラブルシューティングのヒントを示します。

F.1.1 グリッド・インフラストラクチャ・ルート・スクリプトのエラー

後述の詳細を参照してください。

F.1.1.1 問題

グリッド・インフラストラクチャ・ルート・スクリプトが失敗します。

F.1.1.2 説明

グリッド・インフラストラクチャ・ビットを配置した後の基本ステップは、グリッド・インフラストラクチャ・ルート・スクリプトの実行です。これはデプロイメント・プロシージャでプロセスの負荷が最も高いフェーズです。このプロセスにおいて、GIスタックは、すべてのサブシステムが稼働してアクティブになるように自らを構成します。ルート・スクリプトが実行できない場合があります。

F.1.1.3 解決策

1. エラーが報告された各ノードにアクセスし、n-1ノードで次のコマンドを実行します。

$GI_ORACLE_HOME/crs/install/rootcrs.pl -deconfig -force

2. ルート・スクリプトがいずれかのノードで正常に実行できなかった場合、n番目のノードの-lastNodeスイッチを(条件付きで)最後の呼出しに渡します。

$GI_ORACLE_HOME/crs/install/rootcrs.pl -deconfig -force -lastNode

ここで、プロシージャ・アクティビティ・ページで、失敗したステップを再試行します。

F.1.2 デプロイメント・プロシージャ実行中のSUDOエラー

後述の詳細を参照してください。

F.1.2.1 問題

デプロイメントの実行中に、SUDOエラーが発生します。

F.1.2.2 説明

デプロイメントの実行中、すべてのroot関連の操作がsudoで実行されます。セキュリティを向上させるため、本番環境ではsudoを強化する傾向があります。それにより、sudoに関連するエラーが発生することがあります。

F.1.2.3 解決策

sudoersファイルに次の変更を加えます。

1. Default requirettyエントリがsudoersファイルに存在する場合は、そのエントリを削除します。

2. sudoersファイルにエントリDefault env_resetが含まれる場合は、このパラメータの後に次のエントリを追加します。

Defaults env_keep="JRE_HOME PERL5LIB EMDROOT"

F.1.3 前提条件チェックのエラー

後述の詳細を参照してください。

F.1.3.1 問題

デプロイメント・プロシージャを発行した際に前提条件チェックが失敗します。

F.1.3.2 原因

前提条件チェックの出力を詳しく分析します。ほとんどの前提条件の失敗は自動的に修正されますが、デプロイメント・プロシージャが自動修正の環境要件のために失敗した可能性があります。次の原因が考えられます。

- システムに対してローカルではないユーザーのグループ・メンバーシップ。ユーザーはディレクトリ・サービスに登録されるため、rootアクセス権を使用しても、デプロイメント・プロシージャでユーザーの属性を変更することはできません。

- Solarisのゾーン分離。デプロイメント・プロシージャの実行ゾーンに、システム属性を変更する権限がない場合、デプロイメント・プロシージャの自動修正操作が失敗します。

F.1.3.3 解決策

デプロイメント・プロシージャが適切な権限を持つようにします。

F.1.4 Oracle Automatic Storage Management (Oracle ASM)ディスク作成の失敗

後述の詳細を参照してください。

F.1.4.1 問題

Oracle ASMディスク作成が失敗します。

F.1.4.2 原因

ASMディスクは使用とパージに時間がかかる傾向があります。ASMインスタンスがパージされても、物理ASMディスクが従来の疑似状態のままになっている場合、含まれているディスクグループ情報が、将来のASM作成と競合することがあります。これが発生するのは、新たに作成されるASMが、RAWディスクのヘッダーに存在するのと同じディスクグループ名を使用する場合です。このような疑似ディスクが、新たに作成されるASMのディスク検出パスに存在すると、疑似ディスクが使用されて予期しないエラーが発生します。

F.1.4.3 解決策

ディスク検出パスをできるだけ限定的に設定してください。また、ASMがパージされるとすぐにASMディスクを消去する必要があります。11.2よりも後のRDBMSをサポートするデプロイメント・プロシージャには、ユースケースを検出する強力なチェック機能があり、あらかじめユーザーに警告します。

F.1.5 Oracle ASMディスク権限のエラー

後述の詳細を参照してください。

F.1.5.1 問題

Oracle ASMディスク権限のエラーが発生します。

F.1.5.2 説明

NFSマウント済ストレージ(いずれか1つのノードに設定された権限が全体で確認できる)とは異なり、ASMディスクグループでは、参加ノードすべての各RAWディスクに権限を設定する必要があります。

F.1.5.3 解決策

クラスタのすべての参加ノードで、使用される各RAWディスクに660権限を設定します。

F.1.6 データ・プロビジョニング用のカスタム一時ディレクトリの指定

データベースのプロビジョニングでバイナリを置くため、/tmpを除く一時ディレクトリを指定するには、次の手順を実行します。

1. デザイナとしてログインし、「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「データベースのプロビジョニング」の順に選択します。

2. 「データベース・プロシージャ」ページで「Oracleデータベースのプロビジョニング」を選択し、「類似作成」をクリックします。

3. 「類似作成プロシージャ」ページの「一般情報」タブで、デプロイメント・プロシージャの名前を入力します。
「プロシージャ・ユーティリティのステージング・パス」で、/tmpのかわりに使用するディレクトリ(例: /u01/working)を指定します。

4. 「保存」をクリックします。
このデプロイメント・プロシージャはOracleデータベースのプロビジョニングに使用します。

F.1.7 デプロイメント・プロシージャが失敗した際のインシデントの作成

後述の詳細を参照してください。

F.1.7.1 問題

デプロイメント・プロシージャの実行中に、データベースおよびOracle ASMストレージを作成するステップが失敗します。

F.1.7.2 解決策

デプロイメント・プロシージャ内のステップが正常に実行したとき、返される終了コードは正の値です。ステップが失敗し、終了コードが正の値ではない場合、インシデントが生成され、OMSに格納されます。関連するすべてのログ・ファイルと診断情報(メモリー使用状況、ディスク・スペース、実行中プロセス情報など)が、パッケージ化されて格納されます。インシデント・コンソールにアクセスして、この情報をサービス・リクエストとしてパッケージ化して、My Oracle Supportにアップロードすることができます。新しいサービス・リクエストの作成方法の詳細は、インシデント・マネージャ・ページの「ヘルプ」をクリックします。

F.1.8 リモート・ログ・ファイルの読取り

デプロイメント・プロシージャの実行ページでは、プロビジョニング操作に関連するすべてのリモート・ログ・ファイルがハイパーリンクとしてジョブ・ステップに表示されます。これらのハイパーリンクをクリックして、リモート・ログを表示できます。リモート・ログはOMSリポジトリに格納され、トラブルシューティングの際にMy Oracle Supportがアクセスすることができます。

F.1.9 失敗したジョブの再試行

後述の詳細を参照してください。

F.1.9.1 問題

デプロイメント・プロシージャの実行が失敗します。

F.1.9.2 解決策

デプロイメント・プロシージャの実行が失敗した場合は、ジョブの実行詳細をチェックします。失敗したジョブ実行は再試行できます。または、失敗したステップを無視するように選択できます。たとえば、ディスク・スペース不足のためにデプロイメント・プロシージャの実行が失敗した場合は、ファイルを削除してからプロシージャの実行を再試行できます。デプロイメント・プロシージャの実行全体に影響しない問題(cluvyチェック・エラーなど)については、失敗したステップを無視して、デプロイメント・プロシージャを実行することができます。

ジョブ実行処理の再試行によって、「実行中」ステータスの新規ジョブ実行処理が作成されます。元のジョブ実行処理のステータスは変更されません。

失敗したステップを無視してプロシージャを再試行するには、次の手順を実行します。

1. プロシージャ・アクティビティ・ページで、関連するプロシージャをクリックします。

2. ジョブ・ステータス・ページで、失敗したステップのステータスをクリックします。

3. ステップ・ステータス・ページで、「無視」をクリックします。確認ページで「はい」をクリックします。

4. 「再試行」をクリックします。失敗したステップが再試行されます。

F.2 パッチ適用の問題のトラブルシューティング

ここでは、一般的なパッチ適用の問題に関してトラブルシューティングのヒントを示します。

- Oracleソフトウェア・ライブラリの構成の問題

- My Oracle Supportの接続の問題

- ホストおよびOracleホームの資格証明の問題

- 収集の問題

- パッチ推奨の問題

- パッチ計画の問題

- パッチ計画の分析の問題

- ユーザー・アカウントとロールの問題

F.2.1 Oracleソフトウェア・ライブラリの構成の問題

ここでは、次のパッチ適用の問題について説明します。

- ファイルをステージングするときに発生するエラー

- パッチ・セットをアップロードするときに発生するエラー

F.2.1.1 ファイルをステージングするときに発生するエラー

後述の詳細を参照してください。

F.2.1.1.1 問題

パッチ計画の分析中にパッチ計画が予期しないエラーで失敗しますが、資格証明は正しく、EMステージングの場所への書込み権限もあります。

たとえば、次のエラーがジョブの出力ページに表示されます。

”Unexpected error occurred while checking the Normal Oracle Home Credentials”

F.2.1.1.2 原因

ソフトウェア・ライブラリをOMSエージェント・ファイル・システムを使用して設定しており、ソフトウェア・ライブラリの設定に使用された指定の資格証明へのアクセス権がない可能性があります。

F.2.1.1.3 解決策

この問題を解決するには、ソフトウェア・ライブラリの設定に使用された指定の資格証明へのアクセス権を自分自身に明示的に付与します。

F.2.1.2 パッチ・セットをアップロードするときに発生するエラー

後述の詳細を参照してください。

F.2.1.2.1 問題

ソフトウェア・ライブラリへのパッチのアップロード・ページを使用してパッチ・セットをアップロードするとき、パッチ属性を読み取れないというエラーが表示されることがあります。

次に例を示します。

ERROR:Failed to read patch attributes from the uploaded patch file <filename>.zip

F.2.1.2.2 原因

メタデータ・ファイルをパッチ・セットのZIPファイルと一緒にアップロードしますが、パッチ属性をメタデータ・ファイルから読み取れない場合があります。結果として、処理が失敗し、属性を読み取れなかったことが報告されます。

F.2.1.2.3 解決策

この問題を解決するには、ソフトウェア・ライブラリへのパッチのアップロード・ページの「パッチ情報」セクションにすべてのパッチ属性を手動で入力します。たとえば、パッチ番号、作成日時、説明、プラットフォームおよび言語です。

F.2.1.3 重複ディレクトリがソフトウェア・ライブラリで検出された場合のOPatchの更新ジョブの失敗

後述の詳細を参照してください。

F.2.1.3.1 問題

OPatchの更新ジョブを実行するとき、次のエラーで失敗することがあります。

2011-11-28 10:31:19,127 RemoteJobWorker 20236 ERROR em.jobs startDownload.772- OpatchUpdateLatest: java.lang.NullPointerException: Category, 'Oracle Software Updates', has no child named, 'OPatch' at oracle.sysman.emInternalSDK.core.patch.util. ComponentUtil.getComponentCategory (ComponentUtil.java:854)

2012年1月にリリースされたCloud Controlパッチを適用した後でも、次のエラーが表示されることがあります。

Category, 'Oracle Software Updates' already exists.

F.2.1.3.2 原因

エラーが発生するのは、2つの「Patch Components」ディレクトリがソフトウェア・ライブラリで見つかった場合です。特に、パッチのアップロードまたはダウンロードのジョブを2つ(たとえば、OPatchパッチ・ダウンロード・ジョブと通常のパッチ・ダウンロード・ジョブ)実行すると、競合状態が生成し、Patch Componentsという名前のディレクトリが2つ作成されます。このように重複したディレクトリが作成されても、ソフトウェア・ライブラリにはエラーは表示されませんが、OPatchの更新ジョブを実行すると、ジョブがNullPointerExceptionで失敗します。

F.2.1.3.3 解決策

この問題を解決するには、次のいずれかを実行します。

ソフトウェア・ライブラリに2つの「Patch Components」ディレクトリが表示される場合は、エントリ数が少ない方のディレクトリを削除してから、失敗したパッチのアップロードまたはダウンロードのジョブを再試行します。ソフトウェア・ライブラリにアクセスするには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。

「Patch Components」ディレクトリは1つしか表示されないが、Oracleソフトウェアの更新がすでに存在するというエラーが表示される場合は、失敗したパッチのアップロードまたはダウンロードのジョブを再試行します。

F.2.2 My Oracle Supportの接続の問題

この項では、次の問題について説明します。

- ダイジェスト認証のみをサポートするプロキシ・サーバーのテスト中のエラー発生

F.2.2.1 ダイジェスト認証のみをサポートするプロキシ・サーバーのテスト中のエラー発生

後述の詳細を参照してください。

F.2.2.1.1 問題

「プロキシ設定」ページの「My Oracle Supportとプロキシ接続」タブで、手動でプロキシ構成の詳細を指定すると、図F-1のような例外エラーが表示されることがあります。

図F-1 プロキシ設定エラー

F.2.2.1.2 原因

ダイジェスト認証スキーマのみをサポートするプロキシ・サーバーの詳しい構成を指定した可能性があります。デフォルトでは、プロキシ・サーバーはBasic認証スキーマのみにマップされます。現在、ダイジェスト認証スキーマはサポートされていません。

F.2.2.1.3 解決策

この問題を解決するには、Basic認証スキーマを使用するようにプロキシ・サーバーを再構成します。

ヒント:
HTTPクライアント・ロギングに関する接続の問題をより理解するため、次の手順を実行します。

1. GCインスタンス・ディレクトリでstartup.propertiesファイルを探します。
user_projects/domains/EMGC_DOMAIN/servers/EMGC_OMS1/data/nodemanager/startup.properties

2. 次の文字列をプロパティ「引数」の値に追加します。
-DHTTPClient.log.level\=ALL -DHTTPClient.log.verbose\=true

3. 次のコマンドを実行して、OMSとWebLogic Server Administration Managerを再起動します。
emctl stop oms-all

emctl start oms

4. 次の場所に移動し、ログ・ファイルを確認します。
user_projects/domains/EMGC_DOMAIN/servers/EMGC_OMS1/logs/EMGC_OMS1-diagnostic.log

または、次のようにgrepコマンドを使用して、すべてのHTTP接続ログを検索できます。

grep HTTPClient EMGC_OMS1-diagnostic*.log

F.2.3 ホストおよびOracleホームの資格証明の問題

ここでは、次のセキュリティの問題について説明します。

- 通常Oracleホーム資格証明として特権資格証明を設定するとログ・ファイルを作成できない

F.2.3.1 通常Oracleホーム資格証明として特権資格証明を設定するとログ・ファイルを作成できない

後述の詳細を参照してください。

F.2.3.1.1 問題

パッチ計画を作成するときに、Oracleホーム優先資格証明の上書きを選択し、誤って、特権資格証明を通常Oracleホーム資格証明として設定すると(図F-2)、ログ・ファイルをEMStagedPatchesディレクトリに作成できないというエラーが表示されます。

次に例を示します。

”Unable to create the file <RAC_HOME>/EMStagedPatches/PA_APPLY_PATCH_09_02_2011_14_27_13.log"

次のエラーも表示されることがあります。

ERROR: SharedDeviceException.
ACTION: Please check whether the configuration is supported or not.

図F-2 通常資格証明として特権資格証明を誤って選択

F.2.3.1.2 原因

パッチ計画がデプロイされるとき、パッチ計画はデプロイメント・プロシージャを内部的に使用して、パッチのデプロイメントをオーケストレートします。デプロイメント・プロシージャの一部のステップは通常Oracleホーム資格証明を使用して実行されますが、特権Oracleホーム資格証明を使用して実行されるものもあります。ただし、通常Oracleホーム資格証明を特権Oracleホーム資格証明として設定すると、デプロイメント・プロシージャはステップをOracleホーム所有者ではなくルート・ユーザーとして実行します。このためにエラーが発生します。

F.2.3.1.3 解決策

この問題を解決するには、計画の作成ウィザードに戻り、デプロイ・オプション・ページの「資格証明」タブで、通常資格証明を通常Oracleホーム資格証明として設定します。

F.2.4 収集の問題

この項では、次の問題について説明します。

- 計画のウィザードに詳細が表示されない

- ターゲットをパッチ計画に追加できない

F.2.4.1 計画のウィザードに詳細が表示されない

後述の詳細を参照してください。

F.2.4.1.1 問題

パッチ計画を表示したとき、計画の作成ウィザードに予期される情報が表示されません。ウィザードでページやセクションが空白になることがあります。

F.2.4.1.2 原因

この問題は、管理リポジトリの詳細または計画の作成ウィザードで発生することがあります。

F.2.4.1.3 解決策

問題が管理リポジトリの詳細と計画の作成ウィザードのどちらに関連するかを判別します。このためには、ここで説明するコマンドとURLを使用して、管理リポジトリの詳細を取得してみてください。

- URLによって正しい情報が返されるが、コンソールに表示されない場合は、計画の作成ウィザードに技術的な問題があります。この問題を解決するには、Oracleサポート・サービスにお問い合せください。

- URLで返される情報が正しくない場合は、管理リポジトリに問題があります。この問題を解決するには、パッチ計画を再作成します。

管理リポジトリから詳細を取得するには、次のようにします。

- パッチ計画のGUIDを取得します。次のコマンドを実行します。
select plan_guid from em_pc_plans where name='<name of the plan>”;

次に例を示します。

select plan_guid from em_pc_plans where name='t8';

このコマンドの結果は次のようになります。計画のGUIDをメモしてください。

PLAN_GUID
--------------------
96901DF943F9E3A4FF60B75FB0FAD62A

- パッチ計画の一般情報(名前、タイプ、ステータス、計画の特権など)を取得します。このために次のURLを使用します。このような情報は、計画情報ステップや「レビューおよびデプロイ」ステップをデバッグするときに役立ちます。
https://<hostname>:<port>/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=planInfo

注意:
このURLを使用してパッチ計画の情報を取得する前に、Cloud Controlにログインし、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「パッチと更新版」を選択します。

- パッチの情報とパッチ計画に含まれる関連するターゲットの情報を取得します。このために次のURLを使用します。このような情報は、「パッチ」ステップや「確認」ステップをデバッグするときに役立ちます。
https://<hostname>:<port>/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=patches

- パッチ計画で選択されたデプロイメント・オプションの情報を取得します。このために次のURLを使用します。このような情報は、「デプロイ・オプション」ステップや「資格証明」ステップをデバッグするときに役立ちます。
https://<hostname>:<port>/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=deploymentOptions

- パッチ計画で設定された優先資格証明の情報を取得します。このために次のURLを使用します。このような情報は、「資格証明」ステップをデバッグするときに役立ちます。
https://<hostname>:port/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=preferredCredentials

- パッチ計画で設定されたターゲット資格証明の情報を取得します。このために次のURLを使用します。このような情報は、「資格証明」ステップをデバッグするときに役立ちます。
https://<hostname>:port/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=targetCredentials

- パッチ計画の競合のないパッチの情報を取得します。このために次のURLを使用します。このような情報は、「検証」ステップや「レビューおよびデプロイ」ステップをデバッグするときに役立ちます。
https://<hostname>:port/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=conflictFree

- パッチ計画の抑制されたパッチの情報を取得します。このために次のURLを使用します。このような情報は、「パッチ」ステップをデバッグするときに役立ちます。
https://<hostname>:port/em/console/CSP/main/patch/plan?planId=<plan_guid>&client=emmos&cmd=get&subset=removedPatchList

F.2.4.2 ターゲットをパッチ計画に追加できない

後述の詳細を参照してください。

F.2.4.2.1 問題

新しいパッチ計画を作成するとき、または既存のパッチ計画を編集するときに、新しいターゲットを追加すると、次のエラーが表示されます。

Wrong Platform. Expected: Oracle Solaris on SPARC (64-bit), found: null

F.2.4.2.2 原因

管理リポジトリに、そのターゲットのプラットフォーム情報が含まれていない可能性があります。デフォルトでは、すべてのターゲットについて、ターゲットのOracleホームに存在するoraclehomeproperties.xmlファイルからインベントリ詳細が定期的に収集されます。インベントリ収集が完了していないか、失敗したために、管理リポジトリにデータが存在していない可能性があります。このような理由のため、該当のターゲットを追加することができません。

F.2.4.2.3 解決策

この問題を解決するには、ターゲットのOracleホームからインベントリ詳細を強制的に再収集します。

Oracleホームの詳細を取得するには、次の手順を実行します。

1. 「ターゲット」メニューから「すべてのターゲット」を選択します。

2. 「すべてのターゲット」ページの左側の「検索の絞込み」ペインで、「ターゲット・タイプ」メニューをクリックして展開します。

3. 「ターゲット・タイプ」から「その他」をクリックし、「Oracleホーム」を選択します。

4. タイプが「Oracleホーム」のすべてのターゲットがリストされます。ホスト名を検索して、検索している「Oracleホーム」の詳細をドリルダウンすることもできます。

ターゲット・ホストの「Oracleホーム」からインベントリ詳細を取得するには、$EMDROOT/binディレクトリから次のコマンドを実行します。

$ emctl control agent runCollection <Oracle_Home_Target>:oracle_home oracle_home_config

ここで、<Oracle_Home_Target>は、プラットフォーム情報が存在しないターゲットのOracleホームの名前です。

次に例を示します。

$ emctl control agent runCollection db2_2_adc2170603:oracle_home oracle_home_config

F.2.5 パッチ推奨の問題

この項では、次の問題について説明します。

- Oracle ExadataターゲットでのOracle Management Agentインストール後にパッチ推奨が表示されない

F.2.5.1 Oracle ExadataターゲットでのOracle Management Agentインストール後にパッチ推奨が表示されない

後述の詳細を参照してください。

F.2.5.1.1 問題

Oracle ExadataターゲットにManagement Agentをインストールした後、パッチ推奨が表示されません。

F.2.5.1.2 原因

パッチ推奨は、Exadataプラグインがデプロイされていないため表示されません。

F.2.5.1.3 解決策

この問題を解決するには、Exadataターゲットで明示的にExadataプラグインをデプロイします。次の手順を実行します。

1. 「Enterprise」メニューから、「拡張性」、「プラグイン」の順に選択します。

2. 「プラグイン」ページの表から、デプロイするOracle Exadataプラグイン・バージョンを選択します。

3. 「デプロイ先」をクリックし、「管理エージェント」を選択します。

4. 「管理エージェント上のプラグインをデプロイします」ダイアログの「選択した管理エージェント」セクションで、「追加」をクリックしてプラグインをデプロイする管理エージェントを1つ以上選択し、「続行」をクリックします。次に「次へ」、「デプロイ」をクリックします。

F.2.6 パッチ計画の問題

この項では、次の問題について説明します。

- パッチ計画がデプロイできなくなり失敗する

- 移行されないインスタンスも移行の影響を受けるターゲットとして表示される

- クラスタウェア・ターゲットのパッチ適用中に影響を受けるターゲットとしてクラスタASMとそのインスタンスが表示されない

- 部分的に準備された計画のリカバリ

- パッチ計画の作成または編集時に計画の作成ウィザードにエラー#1009が表示される

- 分析が成功したが「デプロイ」ボタンが無効になる

- パッチ計画名が64バイトを超えるとパッチ計画が失敗する

- 11.2.0.3 Exadataクラスタウェアのホーム外パッチ適用が失敗する

F.2.6.1 パッチ計画がデプロイできなくなり失敗する

後述の詳細を参照してください。

F.2.6.1.1 問題

パッチ計画が失敗し、デプロイ不可能な計画と示されます。

F.2.6.1.2 原因

パッチ計画のターゲットにパッチを追加できるのは、パッチのリリースとプラットフォームが追加対象のターゲットと同一の場合のみです。追加するパッチの製品が、パッチの追加対象のターゲットに関連付けられている製品と異なる場合は、警告が表示されます。警告は表示されますが、パッチ計画にパッチを追加できます。ただし、デプロイしようとすると計画が失敗することがあります。

F.2.6.1.3 解決策

デプロイできないパッチ計画をデプロイ可能にするには、パッチ計画を、同種のパッチおよびターゲットのみが含まれるデプロイ可能なより小さい計画に分割します。

F.2.6.2 移行されないインスタンスも移行の影響を受けるターゲットとして表示される

後述の詳細を参照してください。

F.2.6.2.1 問題

ホーム外パッチ適用モードでパッチ計画をデプロイするとき、移行のために選択されていないインスタンスでも、影響を受けるターゲットとして識別されることがあります(図F-3)。

図F-3 移行されないインスタンスが影響を受けるターゲットとして表示される

F.2.6.2.2 原因

デフォルトでは、パッチ計画は、1つのモード(インプレース・パッチ適用モード)のみに基づいて影響を受けるターゲットを計算します。したがって、ホーム外パッチ適用モードを選択しても、パッチ計画はそのモードを無視し、インプレース・パッチ適用モードのみを選択されたオプションとみなし、移行で影響を受けるターゲットとしてすべてのターゲットを表示します。

F.2.6.2.3 解決策

この問題を解決するには、移行対象として選択していないターゲットを無視します。これらは、どのような場合でも停止も移行もされません。

F.2.6.3 クラスタウェア・ターゲットのパッチ適用中に影響を受けるターゲットとしてクラスタASMとそのインスタンスが表示されない

後述の詳細を参照してください。

F.2.6.3.1 問題

クラスタウェア・ターゲットにパッチを適用するパッチ計画を作成する際、「デプロイ・オプション」ページのパッチ対象セクションに、影響を受けるターゲットとなるクラスタASMとそのインスタンスが表示されません。これらは影響を受けるターゲットセクションにも表示されません。また、ホーム外モードでパッチ計画をデプロイした後、クラスタASMとそのインスタンスにメトリック収集エラーが表示されます。

F.2.6.3.2 原因

Cloud Controlにあるクラスタウェア・ターゲット名が、mgmt$target_properties表のクラスタ名ターゲット名と一致しない場合、問題が発生します。

F.2.6.3.3 解決策

この問題を解決するには、次の問合せを実行し、クラスタウェア・ターゲットのターゲット・プロパティClusterNameを検証します。

select property_value from mgmt$target_properties where target_name=<CRS Target Name> and property_name="ClusterName"

戻り値がCloud Controlのクラスタウェア・ターゲット名と異なる場合は、クラスタウェア・ターゲットとその他の関連ターゲットを削除し、再度検出します。この回の検出では、クラスタウェア・ターゲット名が前の問合せで戻された名前と一致することを確認します。

F.2.6.4 部分的に準備された計画のリカバリ

後述の詳細を参照してください。

F.2.6.4.1 問題

ホーム外パッチ適用モードで複数のOracleホームにパッチを適用するパッチ計画を作成し、実際に計画をデプロイする前に、計画の作成ウィザードで「準備」をクリックしてパッチ計画を準備するときに、「準備に失敗しました」というメッセージが生成され、準備処理が失敗することがあります。

F.2.6.4.2 原因

パッチ計画により、選択したOracleホームの一部でクローニングとパッチ適用が正常に行われたが、他の少数のOracleホームで処理が失敗した可能性があります。パッチ計画全体のステータスは、すべてのOracleホームで正常終了したパッチ適用処理に基づきます。ほとんどのOracleホームでパッチ適用処理が正常終了し、ごく一部のOracleホームで失敗した場合でも、全体のステータスは、パッチ計画がステップの1つで失敗した場合と同様になります。

F.2.6.4.3 解決策

この問題を解決するには、失敗したOracleホームでのエラーを修正します。次に、プロシージャ・インスタンスのページに移動し、失敗したステップを再試行します。

F.2.6.5 パッチ計画の作成または編集時に計画の作成ウィザードに「エラー#1009」が表示される

後述の詳細を参照してください。

F.2.6.5.1 問題

新しいパッチ計画の作成または既存のパッチ計画の編集の際に、計画の作成ウィザードに次のエラーが表示されることがあります。

Error #1009

F.2.6.5.2 原因

このエラーが発生するのは、管理リポジトリにアクセスして、パッチ計画、ターゲット、またはコミットされる処理の詳細を抽出するときです。通常は、SQLException、NullPointerExceptionまたはUnhandled例外によってこのようなエラーが引き起こされます。

F.2.6.5.3 解決策

この問題を解決するには、次のファイルを調べて、記録された正確なエラーまたは例外をメモし、Oracleサポート・サービスに問い合せてください。

$MIDDLEWARE_HOME/gc_inst/em/EMGC_OMS1/sysman/log/emoms.log

F.2.6.6 分析が成功したが「デプロイ」ボタンが無効になる

後述の詳細を参照してください。

F.2.6.6.1 問題

パッチ計画の分析が正常に終了した後で、計画の作成ウィザードの「確認」にナビゲートすると、「デプロイ」ボタンが無効になっていることがあります。また、確認ページの表も空です(パッチが表示されません)。このために、パッチ計画をデプロイできないことがあります。

F.2.6.6.2 原因

このエラーが発生するのは、パッチ計画のパッチがターゲットOracleホームにすでに適用されている場合です。そのような場合は、検証ページで、パッチがすでに適用済であり、そのためにスキップされたことが確認されます。また、確認ページでは「デプロイ」ボタンが無効になります。

F.2.6.6.3 解決策

パッチはすでに適用されているため、再び適用する必要はありません。必要な場合には、ターゲットOracleホームからパッチを手動でロールバックし、パッチの適用を再試行してください。

F.2.6.7 パッチ計画名が64バイトを超えるとパッチ計画が失敗する

後述の詳細を参照してください。

F.2.6.7.1 問題

英語以外のロケールでは、分析、準備またはデプロイの際に、あるいはスイッチバックするときに、計画名が長いパッチ計画が失敗します。エラーは表示されません。かわりに、パッチ計画に対して、すぐに「失敗」状態が反映され、例外が<INSTANCE_HOME>/sysman/log/emoms.logファイルにロギングされます。

F.2.6.7.2 原因

このエラーが発生するのは、パッチ計画名が長すぎる(64バイトを超える)場合です。プロビジョニング・アーカイブ・フレームワークではインスタンス名が64バイトに制限されます。このため、64バイト未満の計画名しか受け入れることができません。通常、インスタンス名は、パッチ計画名、計画操作およびタイム・スタンプを使用して構成されます(PlanName_PlanOperation_TimeStamp)。インスタンス名全体が64バイトを超えると、このエラーが表示されます。

F.2.6.7.3 解決策

この問題を解決するには、次のいずれかを実行します。

パッチ計画の分析、準備またはデプロイが失敗した場合は、計画名を編集して短くし、パッチ適用処理を再試行します。

パッチ計画が正常にデプロイされるとパッチ計画はロックされるため、スイッチバックがこのエラーで失敗した場合には、ウィザードで計画名を編集することはできません。かわりに、次のSQL updateコマンドを実行して、管理リポジトリ内の計画名を直接更新します。

update em_pc_plans set name = 'New shorter name' where name = 'Older longer name';

commit;

F.2.6.8 11.2.0.3 Exadataクラスタウェアのホーム外パッチ適用が失敗する

後述の詳細を参照してください。

F.2.6.8.1 問題

パッチ計画の「準備」フェーズで、ホーム外パッチ適用によるクローンOracleホームのロック解除に失敗したため、クローンOracleホームでのパッチ計画が失敗しました。クローンOracleホームでのclone.pl実行手順が失敗しました。

F.2.6.8.2 原因

この問題は、新規Oracleホームが、グリッド・インフラストラクチャ・ホームにあるcrsconfig_filepermsおよび前述の<gi_home>/crs/utl/crsconfig_dirsファイルにあるOracleホームと異なる場合に発生します。11.2.0.3 Exadata Clusterwareでは、フレームワークのロック解除は、これらのファイルを操作して実行できます。

F.2.6.8.3 解決策

この問題を解決するには、次のいずれかの手順を実行します。

- Exadata Clusterの新規パッチ計画を作成し、必要なパッチを選択し、次にパッチ適用方法セクションでインプレースを選択してパッチ計画をデプロイします。

- クラスタのすべてのノードで、クラスタウェアのOracleホームに手動でパッチを適用します。次に、すべてのノードで一部のクローンOracleホームをクリーンアップし、パッチ計画の「準備」操作を再試行します。

F.2.7 パッチ計画の分析の問題

ここでは、次の問題について説明します。

- デプロイメント・プロシージャが終了してもパッチ計画の状態が「分析」から変わらない

- ホストのノード名プロパティがない場合にパッチ計画の分析が失敗する

- 分析の詳しい進捗を表示するリンクが機能しない

- 分析エラーの問題を解決できない場合のサービス・リクエストの発行

F.2.7.1 デプロイメント・プロシージャが終了してもパッチ計画の状態が「分析」から変わらない

後述の詳細を参照してください。

F.2.7.1.1 問題

パッチ計画を分析すると、そのパッチ計画に関して分析が進行中と表示され、対応するデプロイメント・プロシージャまたはジョブが正常に終了した後でもそのままになっていることがあります。

F.2.7.1.2 原因

この問題は次のいずれかの原因によって発生することがあります。

- デプロイメント・プロシージャの完了についてジョブ・システムからの通知が遅れているか、通知がない場合。通常、デプロイメント・プロシージャが終了すると、ジョブ・システムがデプロイメント・プロシージャに通知します。場合によっては、通知が遅れることや、ジョブ・システムからまったく通知されないことがあり、パッチ計画のステータスに常に「分析」状態と表示される原因になります。

- パッチ計画のステータスの変更が遅れている場合。通常は、ジョブ・システムがデプロイメント・プロシージャに完了を通知した後、ジョブ・システムは新しいジョブを発行して、パッチ計画のステータスを変更します。負荷によっては新しいジョブが実行キューに長い間とどまることがあり、そのためにパッチ計画のステータスに常に「分析」状態と表示される原因になります。

- パッチ計画のステータスを変更するジョブのエラー。場合によっては、パッチ計画のステータスを変更するために新しいジョブが発行された後で、管理リポジトリの更新の問題やシステム関連の問題があると、その新しいジョブが失敗することがあります。

- 管理リポジトリのタイムゾーンの問題。管理リポジトリがOracle RACデータベースで構成されている場合に、Oracle RACの各インスタンスが異なるタイムゾーンで実行しているとき、現在のシステム時刻を確認するために問合せが実行されると、そのリクエストを処理するインスタンスによっては不正確な時刻詳細が返されることがあります。時刻詳細が不正確なために、パッチ計画のステータスを変更するジョブが実行されないことがあります。これが、パッチ計画のステータスに常に「分析」状態と表示される原因になります。

F.2.7.1.3 解決策

タイムゾーンに関連する問題の場合は、まずOracle RACノードでタイムゾーンの設定を修正してから再起動します。それ以外のすべての問題については、ログを収集してOracleサポート・サービスに問い合せます。

F.2.7.2 ホストのノード名プロパティがない場合にパッチ計画の分析が失敗する

後述の詳細を参照してください。

F.2.7.2.1 問題

Oracle Clusterwareのパッチ適用のために作成されたパッチ計画を検証するとき、検証が失敗し(図F-4)、タイプhostのターゲット<target_name>のノード名がないと示されます。また、検証ページに示される解決方法は正しくありません。

図F-4 ターゲットのノード名プロパティがないために分析が失敗する

F.2.7.2.2 原因

このエラーは、計画の作成ウィザードが、実際の問合せまたは実行しているジョブと同期していないために発生します。また、プロパティNodeNameはHASターゲットの動的プロパティであり、クリティカル・プロパティとしてマークされないため、管理リポジトリからなくなることがあります。本来は、HASターゲットのノード名プロパティがないと表示される必要があります。

F.2.7.2.3 解決策

この問題を解決するには、次のコマンドを実行して、HASターゲットの動的プロパティをOracle Clusterwareの各ノードから再ロードします。

emctl reload dynamicproperties -upload_timout 600 <target_name>:has

次に例を示します。

emctl reload dynamicproperties -upload_timout 600 <myhastarget1>:has

F.2.7.3 分析の詳しい進捗を表示するリンクが機能しない

後述の詳細を参照してください。

F.2.7.3.1 問題

パッチ計画を分析した後で、「検証」ページの「分析の実行中」というテキストが通常よりも小さくなり、進捗の詳細のための「ここ」リンクが使用できなくなります(図F-5)。

図F-5 詳しい進捗を表示するリンクが使用できない

F.2.7.3.2 原因

このエラーの原因は、このリンクをレンダリングする際の技術的な問題です。

F.2.7.3.3 解決策

この問題を解決するには、計画の作成ウィザードを終了します。パッチと更新版ページの「プラン」リージョンで、この問題が発生したパッチ計画のステータス「分析の実行中」をクリックします。

F.2.7.4 分析エラーの問題を解決できない場合のサービス・リクエストの発行

これまでに説明したように、分析エラーにはいくつかの原因があります。My Oracle Supportの接続の問題、ARUの問題、または管理リポジトリにアクセスして、パッチ計画、ターゲット、またはコミットされる処理の詳細を抽出する際の問題などです。このような問題が発生した場合は、該当する項で説明した解決方法に従います。それでも解決できない場合は、次の手順を実行して、ステップから収集する情報を含むサービス・リクエストまたはバグを発行します。

- (オンライン・モードのみ)使用されているMy Oracle Support Webサイトが現在使用可能化どうかを確認します。

- (オンライン・モードのみ)計画の分析が、発行されるターゲット分析の前に失敗した場合は、次のURLを実行してパッチ分析が予定どおりに機能しているかどうかを確認します。<em_url>を正しいEM URLで置き換え、<plan_name>を実際のパッチ計画名で置き換えます。
<em_url>/em/console/CSP/main/patch/plan?cmd=getAnalysisXML&type=att&planName=<plan_name>

返されるXMLに、パッチ計画に含まれる各Oracleホームに関する競合チェックのリクエストとレスポンスのXMLが含まれることを確認します。

- 次のファイルを開き、記録された正確なエラーまたは例外をチェックし、Oracleサポート・サービスに問い合せてください。
$<MIDDLEWARE_HOME>/gc_inst/em/EMGC_OMS1/sysman/log/emoms.log

F.2.8 ユーザー・アカウントとロールの問題

この項では、次の項目について説明します。

- パッチ・デザイナとパッチ・オペレータが必要な権限を持たない場合のホーム外パッチ適用エラー

F.2.8.1 パッチ・デザイナとパッチ・オペレータが必要な権限を持たない場合のホーム外パッチ適用エラー

後述の詳細を参照してください。

F.2.8.1.1 問題

ホーム外パッチ適用を試行する際に、Oracleホームの構成をリフレッシュしていると、パッチ計画が次のエラーで失敗します。

12:58:38 [ERROR] Command failed with error: Can't deploy oracle.sysman.oh on https://<hostname>:<port>/emd/main/

F.2.8.1.2 原因

このエラーが発生するのは、パッチ・デザイナまたはパッチ・オペレータとして次のロールを持たない場合です。

- ORACLE_PLUGIN_USER (プラグイン・ユーザー・インタフェースを表示)

- ORACLE_PLUGIN_OMS_ADMIN (OMSにプラグインをデプロイ)

- ORACLE_PLUGIN_AGENT_ADMIN (管理エージェントにプラグインをデプロイ)

これらのロールは、「Oracleホーム昇格ターゲットの検出」ジョブを発行するために必要です。このジョブは、Oracleホーム・プラグインがまだデプロイされていない場合に管理エージェントにデプロイします。

F.2.8.1.3 解決策

ユーザー・アカウントを作成するときにこれらのロールを明示的に付与します。または、EM_PROVISIONING_OPERATORおよびEM_PROVISIONING_DESIGNERがすでに含まれているプロビジョニング・ロールを付与します。権限を付与した後で、失敗したデプロイメント・プロシージャのステップを再試行し、ホーム外パッチ適用の準備を完了します。

F.3 Linuxでのパッチ適用問題のトラブルシューティング

ステージング・サーバー設定DPのチャネル情報収集ステップが、チャネルを正常にフェッチできませんでしたというエラー・メッセージで失敗します。これはどのように修正すればよいでしょうか。

このエラーが発生するのは、ネットワーク通信エラーがup2dateとULNの間にある場合です。https://linux.oracle.com/uln_faq.html - 9に従って、up2dateが正しいプロキシ設定で構成されていることをチェックします。問題が解決されたかどうかを確認するには、コマンドup2date -nox -show-channelsを使用します。このコマンドで、サブスクライブされたすべてのチャネルがリストされる場合、問題は解決されています。

「up2date –nox –show-channels」コマンドを使用しても、サブスクライブされたチャネルが正しくリストされません。これはどのように修正すればよいでしょうか。

/etc/sysconfig/rhn/sourcesファイルで、up2date defaultのコメントを解除し、構成されたすべてのローカルRPMリポジトリをコメント化します。

他のアーキテクチャとリリースのチャネルに登録するにはどうすればよいですか。

この方法や詳細(関連するFAQなど)は、https://linux.oracle.com/uln_faq.htmlを参照してください。

他のページを使用した後でグループの設定ページに戻ると、発行したジョブへのリンクが表示されなくなります。元に戻す方法はありますか。

詳細列の「表示」をクリックします。

エラー: パッケージ・リポジトリが見つかりませんでしたまたは「不明なホスト」エラーで、パッケージ情報ジョブが失敗します。これはどのように修正すればよいでしょうか。

選択したパッケージ・リポジトリが適切ではありません。yum-archコマンドとcreaterepoコマンドを実行してメタデータ・ファイルが作成されるかどうかをチェックします。OMSからRPMリポジトリへの接続が原因になることもあります。

デプロイメント・プロシージャの実行が正常に終了した後でも、コンプライアンス・レポートで、グループが準拠していないと表示されます。どうしてですか。

「コンプライアンスの収集」は24時間ごとに実行されるジョブです。コンプライアンス・レポートの更新は、ジョブの次回の実行まで待ってください。または、「ジョブ」タブに移動し、ジョブを編集してスケジュールを変更します。

エラー: パッケージ・リポジトリが見つかりませんでしたまたは「不明なホスト」エラーで、パッケージ情報ジョブが失敗します。これはどのように修正すればよいでしょうか。

選択したパッケージ・リポジトリが適切ではありません。yum-archコマンドとcreaterepoコマンドを実行してメタデータ・ファイルが作成されるかどうかをチェックします。OMSからRPMリポジトリへの接続が原因になることもあります。

パッケージ・リストが長すぎますというUIエラー・メッセージが表示されます。これはどのように修正すればよいでしょうか。

選択したパッケージの一部を選択解除します。このUIエラー・メッセージにより、選択解除するパッケージが示されます。

F.4 Linuxプロビジョニングの問題のトラブルシューティング

プロビジョニング・アプリケーションに関して構成するステージング・サーバー/ブート・サーバーがUIに表示されません。

管理エージェントがステージングまたはブート・サーバー・マシンにインストールされていないか、データをOMSにアップロードしていません。トラブルシューティング情報や既知の問題は、『Oracle Enterprise Manager Cloud Controlアドバンスト・インストレーションおよび構成ガイド』を参照してください。

ベア・メタル・マシンがブート・ファイルを見つけられないため、起動しません。

ターゲット・マシンのdhcp設定(/etc/dhcpd.conf)およびtftp設定を確認します。サービス(dhcpd、xinted、portmap)が実行しているかどうかをチェックします。必要であれば必要な設定の変更を行い、必要なサービスが停止している場合は起動します。

環境が正しく設定されていても、ベア・メタル・ボックスはネットワーク上ではブートされません。

または

DHCPサーバーは、ベア・メタル・マシンのMACアドレスに関するDHCPDISCOVERメッセージを取得しません。

ベア・メタル・マシンがブートされるサブネットのIPアドレスを含むようにDHCP構成を編集します。

オペレーティング・システムがベア・メタル・ボックスにプロビジョニングされた後で、「エージェント・インストール」が失敗します。

または

オペレーティング・システムのプロビジョニング後に、ホスト名がベア・メタル・ボックスに割り当てられていないでしょうか。

これは、dhcpd.confファイルのget-lease-hostnamesエントリがtrueに設定されている場合に発生することがあります。dhcpd.confファイルを編集してget-lease-hostnamesエントリをfalseに設定します。

また、ホスト名の長さがオペレーティング・システムのホスト名の長さに準拠していることを確認します。

ベア・メタル・マシンが最初のブートの後でハングします(tftpエラー/カーネル・エラー)。

これは、tftpサービスが実行していない場合に発生することがあります。tftpサービスを有効にします。/etc/xinetd.d/tftpファイルでdisableフラグをnoに変更します(disable=no)。dhcpの設定も確認します。

ベア・メタル・マシンがブートするときにカーネル・パニックが発生します。

ターゲット・マシンのdhcp設定およびtftp設定を確認し、必要に応じて変更します。まれに、コピーされたintirdとvmlinuzが破損している場合があります。RPMリポジトリからこれらを再びコピーすると、問題が修正されます。

初期カーネル・イメージをロードした後でベア・メタル・マシンがハングします。

これは、ネットワークが半二重の場合に発生することがあります。半二重ネットワークは直接サポートされませんが、次の手順を実行すると問題を修正できます。

- キックスタート・ファイルでethtool -s eth0 duplex halfエントリをethtool -s eth0 duplex fullに変更します。

ベア・メタル・マシンがキックスタート・ファイルを見つけることができません(languageやkeyboardなどの値を手動で入力するためにRedhatの画面が表示されます)。

これは、STAGE_TOP_LEVEL_DIRECTORYがマウント不可またはアクセス不可の場合に発生します。ステージのトップ・レベルがターゲット・マシンにネットワークでアクセスできるようにします。非常にまれですが、ステージング・サーバーのホスト名の解決に関する問題があるために発生することあります。ファイルが存在しているホスト名のかわりにステージング・サーバーまたはNASサーバーのIPアドレスを入力し、プロビジョニング操作を再試行します。

ベア・メタル・マシンで、サイレント・インストールを実行できません(ネットワークの詳細を手動で入力するためにRedhatの画面が表示されます)。

DNSがステージング・サーバー・ホスト名について構成されており、正しいDNS情報をターゲット・マシンに配信するようにDHCPが構成されていることを確認します。問題が解消しない場合は、ホスト名のかわりにステージング・サーバーまたはNASサーバーのIPアドレスを入力し、プロビジョニング操作を再試行します。

プロビジョニングの後で、マシンがEnterprise Managerに登録されません。

これは、プロビジョニング操作の前にEnterprise ManagerエージェントがSTAGE_TOP_LEVEL_DIRECTORYに配置されていない場合に発生します。Enterprise Managerエージェントをこのディレクトリに配置し、操作を再試行します。また、エージェントを保護するために指定されたOMS登録パスワードが正しくない場合にも発生します。ターゲット・マシンのエージェントoracleホームに移動し、正しいOMS登録パスワードを指定してemctl secure agentコマンドを実行します。

OMSとプロビジョニングされたオペレーティング・システムのタイムゾーンをチェックします。プロビジョニングされたオペレーティング・システムのタイムゾーンがOMSのタイムゾーンと一致するように変更します。

64ビットOSのプロビジョニングで、エージェントがインストールされません。

OSのプロビジョニング中に、拡張OSプロパティ・ページでエージェントRPMのフルパスを指定します。

インフラストラクチャ・ページで、1つまたはすべてのステージング・サーバー、ブート・サーバーおよびRPMリポジトリが構成されていないため、プロビジョニング操作を開始できません。

Linuxのプロビジョニングで使用するために少なくとも1つのステージング・サーバー、ブート・サーバーおよびRPMリポジトリを設定します。

デプロイメント操作を発行すると、エラー「予期しないエラーが発生しました。詳細はログ・ファイルを確認してください。」がスローされます。ログには対応するメッセージ「内部名がBMPTypeのComponentTypeが見つかりませんでした」が含まれます。

ソフトウェア・ライブラリ・コンソールでソフトウェア・ライブラリを設定します。

デプロイメント・プロシージャがディレクトリ権限エラーで失敗します。

このエラーは、ターゲット・サーバー・マシンに対するユーザーの権限が不十分なために発生します。STAGE_TOP_LEVEL_DIRECTORYには、ステージング・サーバー・ユーザーの書込み権限が必要です。NASの場合、NASディレクトリはステージング・サーバーにマウントする必要があります。このエラーがブート・ディレクトリへの書込み中に発生した場合は、ブート・サーバー・ユーザーに書込み権限が必要です。

反転ユーザー名の検索に失敗しましたというエラーでベア・メタル・ボックスがブートできません。

DNSに、IPアドレスとホスト名のエントリがあることを確認します。

リファレンス・マシンからプロパティをフェッチすると、エラー「指定された資格証明にはルート・アクセス権がありません。」がスローされます。

リファレンス・マシンに指定された資格証明にsudoアクセス権が含まれることを確認します。

次のパッケージ/パッケージ・グループがRPMリポジトリにありません。パッケージ・リストを更新するか、デプロイメント・ページで正しいRPMリポジトリを選択してください。

このエラー・メッセージで示されたRPMパッケージがリポジトリに存在すること、およびスペリングが正しいことを確認します。存在しない場合は、パッケージをリポジトリにコピーするか、インストールを行わないでください。

F.5 Linuxプロビジョニングのよくある質問

PXE (プリブート実行環境)とは何ですか。

プリブート実行環境(PXEまたはPre-Execution Environment)は、使用可能なデータ・ストレージ・デバイス(ハード・ディスクなど)またはインストールされているオペレーティング・システムに依存せずに、ネットワーク・インタフェース・カードを使用してコンピュータをブートストラップする環境です。詳細は、付録D「PXEブートおよびKickstartテクノロジについて」を参照してください。

ベア・メタル・ボックスが追加されるサブネットとは別のサブネットにブート・サーバーを配置することはできますか。

はい。ただし、ベア・メタル・ボックスが追加されるのと同じサブネットへのブート・サーバーの配置をベスト・プラクティスとしてお薦めします。ネットワークが複数の仮想ネットワークに分割されており、各ネットワークに別のDHCP/PXEブート・サーバーがある場合、「割当て」では、指定のハードウェア・サーバーと同じネットワーク上のブート・サーバーを指定する必要があります。

リモート・サブネットのブート・サーバーを使用する場合は、次のいずれかを実行する必要があります。

-- DHCPトラフィックをリモート・サブネット上のDHCPサーバーに転送するように、ルーターを構成する必要があります。このトラフィックはブロードキャスト・トラフィックです。通常ルーターは、構成しないかぎりブロードキャスト・トラフィックを転送しません。ネットワーク・ルーターとしては、ハードウェアベースのルーター(Cisco Corporation製など)またはソフトウェアベースのルーター(Microsoft's RoutingやRemote Access Services (RRAS)など)を使用できます。どちらの場合も、DHCPトラフィックを指定のDHCPサーバーに送るようにルーターを構成する必要があります。

-- DHCP/BOOTPリレーにルーターを使用できない場合は、各サブネットで1つのマシンにDHCP/BOOTPリレー・エージェントを設定します。DHCP/BOOTPリレー・エージェントは、ローカル・ネットワーク上のDHCP対応クライアントと別の物理ネットワーク上のリモートDHCPサーバーの間で、リモートDHCPサーバーのIPアドレスを使用してDHCPおよびBOOTPメッセージ・トラフィックを送信します。

エージェントrpmがステージング・サーバーにステージングされるのはどうしてですか。

PXEを使用してネットワーク上でブートした後、エージェントrpmがターゲット・マシンにエージェントをインストールするために使用されます。オペレーティング・システムのプロビジョニングでは、「拡張プロパティ」で指定されたステージングの場所からエージェント・ビットもマシンにプッシュされます。

ステージング・サーバーとブート・サーバーにエージェントをインストールするためにエージェントrpmを使用できますか。

これができるのは、ステージング・サーバーまたはブート・サーバー・マシンのオペレーティング・システムがRedHat Linux 4.0、3.1または3.0、あるいはOracle Linux 4.0以降の場合のみです。詳細は、次のページにある「Oracle Management Agentインストールのためのエージェントrpmの使用」を参照してください。

http://www.oracle.com/technology/software/products/oem/htdocs/provisioning_agent.html

HTTP以外のプロトコルを使用してyumリポジトリにアクセスできますか。

rpmリポジトリはfile://またはftp://でも公開できますが、推奨する方法はhttp://です。これが高速かつ安全性も高い方法です。

ディレクティブのステータスの意味は何ですか。どうすれば変更できますか。

次の表で、ステータスの値と意味を確認してください。

表F-1 ステータス値

ステータス

説明

不完全

このステータスは、ディレクティブの作成中に一部のステップ(ディレクティブの実際のスクリプトのアップロードなど)が完了しなかったことを示します。または、ユーザーが作成中にディレクティブを保存し、ディレクティブの作成を完了するために実行する必要があるステップがあることを示します。

準備完了

これは、ディレクティブの作成が正常に終了し、コンポーネントやイメージと一緒に使用できる状態であることを示します。

アクティブ

ユーザーは、「準備完了」ディレクティブのステータスを「アクティブ」に手動で変更して、プロビジョニングの準備ができたことを示すことができます。「アクティブにする」をクリックするとステータスが「アクティブ」に変更されます。

ディレクティブの成熟度レベルとは何ですか。どうすれば変更できますか。

表F-2で、ステータスの値と意味を確認してください。

表F-2 成熟度レベル

成熟度レベル

成熟度レベルの説明

未テスト

これは、ディレクティブがテストされていないことを示します。ディレクティブが作成されたときに割り当てられるデフォルトの成熟度レベルです。

ベータ

ディレクティブをテストすると、「昇格」ボタンを使用して「ベータ」に手動で昇格できます。

本番

本番システムの実際のプロビジョニングにディレクティブを使用できるとユーザーが確認したら、「昇格」ボタンを使用して「本番」に手動で昇格できます。

複数のデプロイメントで同じコンポーネントを使用できますか。

はい。コンポーネントは再利用可能です。所定のコンポーネントを複数のデプロイメントに同時に含めることができます。

コンポーネントが編集された場合、そのコンポーネントに関連するスケジュール済デプロイメントを編集する必要がありますか。

はい。

Linux OSコンポーネントを作成する際に、リファレンス・マシンで管理エージェントが実行している必要がありますか。

はい。リファレンス・マシンは、Enterprise Managerの管理対象ターゲットの1つであることが必要です。

ディレクティブのステータスの意味は何ですか。どうすれば変更できますか。

コンポーネントのステータスはディレクティブのステータスと似ています。「ディレクティブのステータスの意味は何ですか。どうすれば変更できますか。」を参照してください。

コンポーネントの成熟度レベルとは何ですか。どうすれば変更できますか。

コンポーネントの成熟度レベルはディレクティブの成熟度レベルと似ています。「ディレクティブの成熟度レベルとは何ですか。どうすれば変更できますか。」を参照してください。

F.6 構成のリフレッシュ

問題が発生して、ホストまたはOracleホームで構成をリフレッシュすることになった場合は、次に説明する手順に従います。

- ホスト構成のリフレッシュ

- Oracleホーム構成のリフレッシュ

F.6.1 ホスト構成のリフレッシュ

デプロイメント・プロシージャを実行する前に、ホストの構成をリフレッシュすることをお薦めします。次の手順を実行します。

1. Cloud Controlで、「エンタープライズ」メニューから「構成」を選択し、「ホスト構成のリフレッシュ」をクリックします。

2. ホスト構成のリフレッシュ・ページの「使用可能なホスト」ペインでデプロイメント・プロシージャが使用するホストを選択し、「選択したホスト」ペインに移動します。

3. 「ホストのリフレッシュ」をクリックします。

F.6.2 Oracleホーム構成のリフレッシュ

ホスト構成情報は、ホストで稼働しているOracle Management Agentによって24時間ごとに自動的に更新されますが、ホストの構成情報を手動で更新することもできます。

注意:
ターゲットにパッチを適用した後、Oracleホーム構成のリフレッシュがデプロイメント・プロシージャによって内部的に処理されます。ただし、なんらかの理由でリフレッシュが行われない場合は、ここで説明するようにOracleホーム構成を手動でリフレッシュできます。

1つのホストのホスト構成を手動で更新する手順は、次のとおりです。

1. Cloud Controlで、「ターゲット」メニューから「すべてのターゲット」を選択します。

2. すべてのターゲット・ページの「検索の絞込み」セクションで、「ターゲット・タイプ」をクリックしてメニューを展開し、メニューの「その他」をクリックし、さらに「Oracleホーム」をクリックします。
ページの右側がリフレッシュされ、Oracleホーム・ターゲットのみが表示されます。

3. ターゲット名をクリックして選択します。

4. <target_name>ホームページの「Oracleホーム」メニューで「構成」を選択し、「最新収集」をクリックします。

5. 最新の構成: <target_name>ページの「アクション」メニューで、「リフレッシュ」を選択して、ホストのOracleホーム構成をリフレッシュします。

次の例は、ターゲット11107CRSHome_1_slc00eiiのOracleホーム構成をリフレッシュするためのステップです。

F.7 ログ・ファイルの確認

ここでは、デプロイメント・プロシージャの実行中に発生した問題を解決するために確認する必要があるログ・ファイルをしめします。

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

- OMS関連のログ・ファイル

- 管理エージェント関連のログ・ファイル

- 拡張オプション

F.7.1 OMS関連のログ・ファイル

OMS関連のログ・ファイルを次に示します。

Enterprise Managerの一般的なトレース・ファイル

<EM_INSTANCE_BASE>/em/<OMS_NAME>/sysman/log/emoms.trc

Enterprise Managerの一般的なログ・ファイル

<EM_INSTANCE_BASE>/em/<OMS_NAME>/sysman/log/emoms.log

<EM_INSTANCE_BASE>は、OMSインスタンス・ベースのディレクトリです。デフォルトでは、OMSインスタンス・ベースのディレクトリはgc_instで、これはOracle Middlewareホームの親ディレクトリの下にあります。

F.7.2 管理エージェント関連のログ・ファイル

管理エージェント関連のログ・ファイルを次に示します。

EMSTATE/sysman/log/gcagent.log

EMSTATE/sysman/log/gcagent.trc

F.7.3 拡張オプション

必要であれば、詳細を取得するために、次の手順を実行してログ・レベルを再設定し、前の項で説明したログを取得します。

注意:
古いログをアーカイブし、ログ・レベルを再設定した後で、新たに実行して新しいログを取得することをお薦めします。

F.7.3.1 OMS側

OMS側で次の手順を実行します。

1. OMSのOracleホームにある次のファイルを開きます。
$<ORACLE_HOME>/sysman/config/emomslogging.properties

2. @log4j.category.oracle.sysman.emdrep.jobs =パラメータにDEBUGを設定します。

F.7.3.2 管理エージェント側

管理エージェント側で次の手順を実行します。

1. 次のファイルを開きます。
EMSTATE/sysman/config/emd.properties

2. 次のように設定します。
Logger.log4j.rootCategory=DEBUG, Rolling, Errors

索引
A B C D E F G H I J K L M N O P R S T U V W X Y

A

アクセス

コンプライアンス標準, 45.4.3

コンプライアンス違反, 45.2.5

「ソフトウェア・ライブラリ」コンソールへのアクセス, 2.2 追加

ホスト構成, 41.6.3

ホスト・ターゲット, 41.4

ローカル・ホスト・グループ, 41.2.7

ローカル・ユーザー, 41.2.6

新規ターゲット・データ収集の追加, 44.6.3.2 プラガブル・データベースの管理, 17.6 ホストの管理, 41 管理タスク, 41.2 エージェント側のルール

コンプライアンス標準ルール, 45.4.6

定義, 45.1.1

AIXインストール済パッケージ・パーサー, 44.7.5 構成状態の分析, 44.10.5 AND/OR論理演算子

比較ルール, 44.5.5.2

Apache HTTPDパーサー, 44.7.5 アプリケーション・データ・モデル, 46.2.1 アプリケーション・シグネチャ, 46.1.3

Oracle E-Business Suite, 46.1.3

Oracle Fusion Applications, 46.1.3

Oracle PeopleSoft Enterprise, 46.1.3

ASM, 記憶域, 40.2.5 変更アクティビティ計画でのタスクのグループ所有者への割当て, 49.3.7 コンプライアンス標準のターゲットへの関連付け, 45.6.2 アソシエーション，「関係」を参照 監査, コンプライアンス標準を設定する方法, 45.4.3 自動メタデータ検出, 46.2.3.2 変更アクティビティ計画の自動化, 49.6.1 Autosysパーサー, 44.7.5

B

ベアメタル・プロビジョニング

概要

ブート・サーバー, 36.2.2.2

参照ホスト, 36.2.2.4

RPMリポジトリ, 36.2.2.5

ステージング・サーバー, 36.2.2.3

概要, 36.2 設定, 36.4 サポートされているリリース, 36.3 ベース・パーサー

列指向, 44.7.4

フォーマット固有, 44.7.3

プロパティ, 44.7.5

BEA Tuxedoパーサー，「Ubb Configパーサー」を参照 Blue Martini DNAパーサー, 44.7.3 ブループリント, 構成拡張, 44.6.4 ブート・サーバー, 36.2.2.2

概要, 36.2.2.2

設定, 36.4.2

ブラウズ

コンプライアンス・フレームワーク, 45.4.2.7

コンプライアンス標準ルール, 45.4.7.11

コンプライアンス標準, 45.4.4.7

Business Process Execution Language (BPEL), 34

C

変更アクティビティ計画

グループ所有者へのタスクの割当て, 49.3.7

自動化, 49.6.1

所有者の変更, 49.3.7

作成, 49.2

他の計画の類似計画, 49.3.1

タスク定義, 49.2.1

タスク・グループ, 49.2.2

非アクティブ化, 49.3.4 削除, 49.3.3 編集, 49.3.2 例, 49.6 エクスポート, 49.3.5 計画の管理, 49.4 操作, 49.3 概要, 49 計画, 49.1.2.2 印刷, 49.3.6 ロールおよび権限, 49.1.1 サマリー, 49.4.1 タスク定義, 49.1.2.2 タスク・グループ, 49.1.2.3 タスク, 49.1.2.4, 49.4.2 用語, 49.1.2 パッチ適用に使用, 49.6.3 タスクの表示, 49.5 変更管理, 47, 47.1 変更計画

変更計画の作成, 47.5.2

変更計画の提出, 47.5.3

変更計画

概要, 47.5

変更アクティビティ計画の所有者の変更, 49.3.7 違反のクリア, 45.6.4 クライアント構成収集タグ, 44.8.2 クライアント構成, 44.8 クライアント・システム・アナライザ(CSA)

クライアント構成, 44.8

単独にデプロイ, 44.8.2

クローン

実行中のOracle Application Serverインスタンスのクローニング, 35.3.1

実行中のOracleデータベース・リプレイ・クライアントのクローニング, 12.2

実行中のOracle RACインスタンスのクローニング, 9.3

データベースのクローニング

既存のバックアップ, 14.5.4

RMANバックアップ, 14.5.2

ステージング領域, 14.5.3

データベースのクローニング・メソッド, 14.5.1 プラガブル・データベースのクローニング, 17.3.3 クラスタ検証ユーティリティ, 4.3.11 コヒーレンス・ノードのプロビジョニング

コヒーレンス・ノードおよびクラスタのデプロイ

トラブルシューティング, 31.4

コヒーレンス・ノードのプロビジョニング

コヒーレンス・ノードおよびクラスタのデプロイ, 31.3

コヒーレンス・コンポーネントの作成, 31.3.2

デプロイメント・プロシージャ, 31.3.3

前提条件, 31.3.1

はじめに, 31.1 サポートされているリリース, 31.2 ターゲットの収集済構成, 44.1 列

パーサーのパラメータ, 44.7.4.1

パーサー, 44.7.4

コマンド

ホスト, 41.3

構成の比較, 44.5.7.1 データの比較, 47.6.2 比較

ルール, 1.1

比較ジョブ・アクティビティ, 44.5.8.1 比較結果, 44.5.8, 44.5.8.2

標準ターゲット, 44.5.8.3

構成ファイルの同期, 44.5.8.4

比較テンプレート

作成または編集, 44.5.2.1

削除, 44.5.2.2

エクスポート, 44.5.2.2

インポート, 44.5.2.2

管理, 44.5.2.2, 44.6.1.7

「メンバー設定」タブ, 44.5.2.1

無視のルール・タブ, 44.5.2.1

一致のルール・タブ, 44.5.2.1

「テンプレート設定」タブ, 44.5.2.1

表示, 44.5.2.2

比較テンプレート, 44.5

テンプレートの作成, 44.5.2.1

テンプレートの編集, 44.5.2.1

プロパティの設定, 44.5.2.1

一致のルール, 44.5.2.1

テンプレートの設定, 44.5.2.1

比較ウィザード, 44.5.7, 44.5.7 比較, 44.5.6

メンバーのマッピング, 44.5.7.4

スケジュール, 44.5.7.5

構成の選択, 44.5.7.2

テンプレートの選択, 44.5.7.3

ジョブの発行, 44.5.7.6

法令順守

アクセス, 45.1.2

コンプライアンス・フレームワーク, 45.4.1

コンプライアンス標準ルール・フォルダ, 45.4.5

コンプライアンス標準ルール, 45.4.6

コンプライアンス標準, 45.4.3

構成, 45.4

ダッシュボード, 45.1.2, 45.2.1.1

評価, 45.2, 45.2

評価

リアルタイム監視の操作, 45.3.2

結果, 45.2.3, 45.2.4

重要度, 45.2.9 評価エラーの調査, 45.2.7 ライブラリ, 45.1.2 管理, 45.4 概要, 45.1 使用に必要な権限, 45.1.3 リアルタイム

監視ファセット, 45.5

監視, 45.1.2

レポート, 45.2.8 結果, 45.1.2 使用に必要なロール, 45.1.3 スコア, 45.2.9 統計, アクセス, 45.2.1 サマリー情報, 45.2.2 使用される用語, 45.1.1 違反

アクセス, 45.2.5

表示の例, 45.2.6.3

管理, 45.2.5

手動ルール, 45.2.5

ターゲット, 45.2.6.3

抑止, 45.2.5

抑止解除, 45.2.5

コンプライアンス・フレームワーク権限, 45.1.3 コンプライアンス・フレームワーク

概要, 45.4.1

アクセス, 45.4.1

コンプライアンス標準の追加, 45.4.2.1

使用することの利点, 45.4.1, 45.4.1

データベース・ターゲットのコンプライアンス, 45.4.2.13

コンプライアンス・スコア, 45.2.9.4

定義, 45.1.1

重要度の編集, 45.4.2.1

エラー, 45.4.2.11, 45.4.2.12

評価結果, 45.4.2.9, 45.4.2.10

ライフサイクル・ステータス, 45.4.2.1

操作, 45.4.2

参照, 45.4.2.7

作成, 45.4.2.1

類似作成, 45.4.2.2

削除, 45.4.2.4

編集, 45.4.2.3

エクスポート, 45.4.2.5

インポート, 45.4.2.6

検索, 45.4.2.8

Oracle提供, 45.4.1 使用する理由, 45.4.1 ユーザー定義, 45.4.1 違反の詳細, 45.2.6.3 コンプライアンスのロール

EM_COMPLIANCE_DESIGNER, 45.1.3

EM_COMPLIANCE_OFFICER, 45.1.3

コンプライアンス・スコア

コンプライアンス・フレームワーク, 45.2.9.4

コンプライアンス標準, 45.2.9.3

コンプライアンス標準ルール, 45.2.9.1

定義, 45.1.1

親ノード, 45.2.9.5

リアルタイム監視ルール, 45.2.9.2

コンプライアンス標準ルール・フォルダ

概要, 45.4.5

作成, 45.4.5.1

定義, 45.1.1

コンプライアンス標準内の管理, 45.4.5.2

コンプライアンス標準ルール

概要, 45.4.6

エージェント側のルール, 45.4.6

定義, 45.1.1

重要度, 45.4.6

手動ルール, 45.4.6

操作, 45.4.7

参照, 45.4.7.11

エージェント側のルールの作成, 45.4.7.4, 45.6.2

類似作成, 45.4.7.6

手動ルールの作成, 45.4.7.5, 45.6.2

リアルタイム監視ルールの作成, 45.4.7.3

リポジトリ・ルールの作成, 45.4.7.1

WebLogic Serverの署名ルールの作成, 45.4.7.2

削除, 45.4.7.8

編集, 45.4.7.7

エクスポート, 45.4.7.9

インポート, 45.4.7.10

検索, 45.4.7.12

Oracle提供, 45.4.7.13 リアルタイム監視ルール, 45.4.6 リポジトリ・ルール, 45.4.6 タイプ, 45.4.6 WebLogic Server署名ルール, 45.4.6 コンプライアンス標準

概要, 45.4.3

アクセス, 45.4.3

別のコンプライアンス標準への追加, 45.4.4.1

コンプライアンス・フレームワークへの追加, 45.4.2.1

使用することの利点, 45.4.3

ターゲットへの関連付け, 45.4.4.13

定義, 45.1.1

エラー, 45.4.4.11, 45.4.4.12

評価結果, 45.4.4.9, 45.4.4.10

違反の調査, 45.2.6

操作, 45.4.4

参照, 45.4.4.7

作成, 45.4.4.1

類似作成, 45.4.4.2

カスタマイズ, 45.4.4.3

削除, 45.4.4.4

編集, 45.4.4.3

エクスポート, 45.4.4.5

インポート, 45.4.4.6

検索, 45.4.4.8

セキュリティ・メトリック, 有効化, 45.4.4.15 使用を監査するための設定, 45.4.3 違反の詳細, 45.2.6.3, 45.2.6.3, 45.2.6.3 コンプライアンス違反, 調査, 45.2.6 構成ブラウザ, 44.3

インベントリと使用状況の詳細, 44.3.3

保存された構成, 44.3.2

構成データの表示, 44.3.1

構成ブラウザ, 構成の表示, 44.3 構成の変更, 44.4 構成収集, 44.6 構成の比較

構成の追加, 44.5.7.2

最初の構成, 44.5.7.1

無視ルール, 44.5.3.3

無視ルールの例, 44.5.5.2

キー・プロパティ, 44.5.8.3

一致ルール, 44.5.3.2

一致ルールの例, 44.5.5.1

確認と発行, 44.5.7.6

ルールの例, 44.5.5

ルール言語, 44.5.4

ルール, 44.5.3

スケジュールと通知, 44.5.7.5

テンプレートの選択, 44.5.7.3

単一ターゲットの結果, 44.5.8.3

システムの結果, 44.5.8.2

値制約ルール, 44.5.3.1

ウィザード, 44.5.7

構成データの収集, 44.6.3 構成データ, 収集の拡張, 44.6.3 構成拡張

ブループリント, 44.6.4

作成, 44.6.1.2

資格証明, 44.6.1.5

データベース・ロール, 44.6.1.4

削除, 44.6.1.7

デプロイ, 44.6.2.1

編集, 44.6.1.2

デプロイの編集, 44.6.2.2

ファセットの同期の有効化, 44.6.1.7

エンコーディング, 44.6.1.3

エクスポート, 44.6.1.7

「ファイルとコマンド」タブ, 44.6.1.3

インポート, 44.6.1.7

解析後のルール, 44.7.6.1, 44.7.6.2, 44.7.6.3

権限, 44.6.1.9

ロール, 44.6.1.9

ルール, 44.6.1.6

解析されたXML以外のファイルの例, 44.7.6.2

解析されたSQL問合せの例, 44.7.6.3

解析されたXMLファイルの例, 44.7.6.1

アンデプロイ, 44.6.2.1

バージョニング, 44.6.1.8

収集データの表示, 44.6.2.3

仕様の詳細の表示, 44.6.1.7

XML解析の例(デフォルト), 44.7.2.3

XML解析の例(汎用), 44.7.2.3

XML解析の例(変更), 44.7.2.3

XPath, 44.6.1.6

構成拡張, 作成, 45.6.2 構成拡張, 44.6

コマンド・タブ, 44.6.1.3

作成, 44.6.1.2

デプロイメント, 44.6.2

ファセットの同期の有効化, 44.6.1.7

権限, 44.6.1.9

資格証明の設定, 44.6.1.5

ルールの設定, 44.6.1.6

「SQL」タブ, 44.6.1.4

バージョニング, 44.6.1.8

構成拡張権限, 45.1.3 構成履歴, 44.4

アクセス, 44.4.1

注釈の付加, 44.4.2.2

通知リストの作成, 44.4.2.3

スケジュール, 44.4.2.3

検索履歴, 44.4.2.1

構成履歴, ジョブ・アクティビティ, 44.4.3 構成管理, 44.1 構成の検索, 44.2

詳細オプション, 44.2.2

作成, 44.2.2

構成検索の管理, 44.2.1

検索シナリオの確認, 44.2.3

シナリオ, 44.2.3

設定, 44.2.2

SQL問合せ, 44.2.2

構成トポロジ・ビューア, 44.10 構成トポロジ, 表示, 44.10.3 構成

クライアント, 44.8

クライアント・システム・アナライザ(CSA), 44.8

ハードウェアおよびソフトウェア, 44.1

履歴, 1.1

検索, 1.1, 44.2

表示, 44.3

グリッド・インフラストラクチャの構成, 7.3.2, 7.5.2 監査ステータスの構成

リアルタイム監視ルール, 45.4.7.3

ホストの構成, 41.1 Connect:Directパーサー, 44.7.3 消費サマリー, 記憶域, 40.2.4 コンテナ・データベース(CDB)

作成の前提条件, 16.2.1, 16.3.1, 16.4.1

手順, 16.2.2, 16.3.2, 16.4.2

グラフ上の情報の表示形式の制御, 44.10.16 CPU統計

ホストの監視, 40.1.1

コンプライアンス・エンティティの作成権限, 45.1.3 作成

エージェント側のコンプライアンス標準ルール, 45.4.7.4, 45.6.2

変更アクティビティ計画, 49.2

別の計画に類似, 49.3.1

タスク定義, 49.2.1

タスク・グループ, 49.2.2

比較テンプレート, 44.5.2.1 コンプライアンス・フレームワーク, 45.4.2.1 コンプライアンス手動ルール, 45.6.2 コンプライアンス標準の例, 45.6.2 コンプライアンス標準ルール・フォルダ, 45.4.5.1 コンプライアンス標準, 45.4.4.1 コンプライアンス標準, 考慮, 45.4.4.16 構成拡張, 45.6.2 構成の検索, 44.2.2 カスタム・ターゲット・タイプ, 44.6.1.1 手動コンプライアンス標準ルール, 45.4.7.5 新規関係, 44.9 リアルタイム監視コンプライアンス標準ルール, 45.4.7.3 リアルタイム監視ファセット・フォルダ, 45.5.2.3 リアルタイム監視ファセット, 45.5.2.2 リポジトリ・コンプライアンス標準ルール, 45.4.7.1 WebLogic Server署名コンプライアンス標準ルール, 45.4.7.2 外部クライアントを使用した変更計画の作成, 47.5.2.2 データベース・プロビジョニング・エンティティの作成, 4.3.10 データベース・テンプレートの作成, 4.3.8 データベースの作成, 7.5.2, 16.2

前提条件, 16.2.1

手順, 16.2.2

ディスク・レイアウト・コンポーネントの作成, 36.4.9.2 インストール・メディアの作成, 4.3.7 類似作成

コンプライアンス・フレームワーク, 45.4.2.2

コンプライアンス標準ルール, 45.4.7.6

コンプライアンス標準, 45.4.4.2

リアルタイム監視ファセット, 45.5.2.5

Oracle Databaseの作成, 16.2

前提条件, 16.2.1

Oracle RAC One Nodeデータベースの作成, 16.4

前提条件, 16.4.1

手順, 16.4.2

Oracle Real Application Clustersデータベースの作成, 16.3

前提条件, 16.3.1

手順, 16.3.2

プロビジョニング・プロファイルの作成, 4.3.5 ターゲットへの関係の作成, 44.10.14 カスタム構成収集に基づくリポジトリ・ルールの作成, 45.6.1

例, 45.6.1

ユーザーの作成

デザイナ, 2.4.2

オペレータ, 2.4.3

資格証明

ホスト, 38.3, 38.3, 38.3

監視の設定, 38.4.2

資格証明, 構成拡張, 44.6.1.5 Cronアクセス・パーサー, 44.7.4 Cronディレクトリ・パーサー, 44.7.4 CSVパーサー, 44.7.4 カスタムCFGパーサー, 44.7.5 カスタム構成

カスタム・ターゲット・タイプ, 44.6.1.1

カスタマイズ

エラー処理モードの変更, 51.4

カスタマイズのタイプ, 51.1

ディレクティブ・ワークフロー, 51.7

概要, 51.1

電子メール通知の設定, 51.5

カスタマイズ

ホスト環境, 39

トポロジ・ビューのカスタマイズ, 44.10.10 CVU, 4.3.11

D

データの比較, 47.1

概要, 47.6

要件, 47.6.1

データ検出, 46.1.1 データ検出ジョブ, 46.2.4 データの検出結果, 46.2.4.2 データ・リダクション, 46.1.2 データベース資格証明, 44.6.1.4 データベース・ホストの準備状況, B

ユーザー・アカウントの追加, B.1

SSHの構成, B.1.1

環境設定, B.4

カーネル要件, B.4.1

メモリー要件, B.4.4

ネットワークおよびIP要件, B.4.5

ノード時刻要件, B.4.2

パッケージ要件, B.4.3

インストール・ディレクトリとOracleインベントリ, B.6 PDP設定, B.3 ユーザー・アカウントの設定, B.1 シェル制限, B.2 記憶域要件, B.5 データベースのプロビジョニング

管理者権限, 4.3.2

デプロイメント・プロシージャ, 4.2

はじめに, 5.1

ホストの要件, 4.3.1

Oracle Databaseソフトウェア, 5.5

Oracle ASMを使用したOracle Database, 5.4

Oracle Grid InfrastructureおよびOracle Databaseソフトウェア, 6.3

Oracle ASMを使用したOracle Grid InfrastructureおよびOracle Database, 6.2

Oracle Real Application Clustersデータベース用のOracle Grid Infrastructure, 7

既存のクラスタ上のファイル・システムを使用したOracle RACデータベース, 7.4

新規クラスタ上のファイル・システムを使用したOracle RACデータベース, 7.5

Oracle Real Application Clusters One Nodeデータベース, 8

デザイナの前提条件, 4.3.3

オペレータの前提条件, 4.3.4

Oracle Databaseのプロビジョニングおよび作成, 5.3

Oracle RACのプロビジョニング, 9

設定, 4.3

サポートされるターゲット, 4.2

ユースケース, 4.2

データベース・プロビジョニングの概要, 4.1 データベース・プロビジョニング・ソリューション

画面へのアクセス, 4.1

データベース問合せ

パーサー, 44.7.3

パーサーのパラメータ, 44.7.3.1

データベース・テンプレート

ソフトウェア・ライブラリへのアップロード, 4.3.9

データベース

記憶域, 40.2.6

Db2パーサー, 44.7.3 非アクティブ化

変更アクティビティ計画, 49.3.4

デフォルトのシステム実行レベル

ホスト内, 41.2.2

Oracle RACの削除, 11.2, 11.3

前提条件, 11.3.1

Oracle RACのノードの削除, 11.4 削除

変更アクティビティ計画, 49.3.3

比較テンプレート, 44.5.2.2

コンプライアンス・フレームワーク, 45.4.2.4

コンプライアンス標準ルール, 45.4.7.8

コンプライアンス標準, 45.4.4.4

構成拡張, 44.6.1.7

カスタム・トポロジ・ビュー, 44.10.11

リアルタイム監視ファセット, 45.5.2.4

ターゲットからの関係, 44.10.15

Oracle RACの削除

コア・コンポーネントの削除, 11.2

Oracle RAC全体の削除, 11.3

プラガブル・データベースの削除, 17.4 Dell PowerEdge Linuxホストの監視, 41.6.2 依存性分析, 44.10.8 デプロイ可能なパッチ計画, 42.1.3.2 コヒーレンス・ノードおよびクラスタのデプロイ

デプロイメント・プロシージャ

コヒーレンスの追加, 31.3.3.1

環境変数, 31.3.3.1

スクリプト例, 31.3.3.2

構成拡張のデプロイ, 44.6.2.1 SOAコンポジットのデプロイ, 32.5 Java EEアプリケーションのデプロイ、アンデプロイおよび再デプロイ

Java EEアプリケーション・コンポーネントの作成, 30.5

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

はじめに, 30.1

「Java EEアプリケーション」デプロイメント・プロシージャ, 30.6

前提条件, 30.4

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

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

Java EEアプリケーションのデプロイ、アンデプロイまたは再デプロイ, 30.2 デプロイメント・プロシージャ, 8.2

権限の編集, 50.5.2

フェーズおよびステップ, 50.3.3

ターゲット・リスト, 50.3.1

ステータスの追跡, 50.5.3

ユーザー、ロールと権限, 50.2

変数, 50.3.2

表示、編集および削除, 50.5.1

デプロイメント

クライアント構成収集タグ, 44.8.2

クライアント・システム・アナライザ(CSA), 44.8.2

管理リポジトリ, 44.1

デザイナおよびオペレータ・ロール, 4.1 構成状態コンプライアンス・スコアの特定, 44.10.6 dhcpサーバー

設定, 36.4.2

診断

コンプライアンス違反, 45.2.6

ディレクトリ

パーサー, 44.7.3

パーサーのパラメータ, 44.7.3.2

ホストの検出, 3.1

自動, 3.1

手動, 3.2

ディスク

統計, ホストの監視, 40.1.3

ストレージ, 40.2.7

E

E-Business Suite

パーサー, 44.7.3

パーサーのパラメータ, 44.7.3.3

編集

変更アクティビティ計画, 49.3.2

比較テンプレート, 44.5.2.1

コンプライアンス・フレームワーク, 45.4.2.3

コンプライアンス標準ルール, 45.4.7.7

コンプライアンス標準, 45.4.4.3

構成拡張のデプロイ, 44.6.2.2

ホスト構成, 41.6.3

ローカル・ホスト・グループ, 41.2.7

ローカル・ユーザー, 41.2.6

リアルタイム監視ファセット・フォルダ, 45.5.2.3

リアルタイム監視ファセット, 45.5.2.2

EM_ALL_DESIGNER

EM_PATCH_DESIGNER, 50.2.1

EM_PROVISIONING_DESIGNER, 50.2.1

EM_TC_DESIGNER, 50.2.1

EM_ALL_OPERATOR

EM_ALL_VIEWER, 50.2.1

EM_HOST_DISCOVERY_OPERATOR, 50.2.1

EM_PATCH_OPERATOR, 50.2.1

EM_PROVISIONING_OPERATOR, 50.2.1

EM_TARGET_DISCOVERY_OPERATOR, 50.2.1

EM_CAP_ADMINISTRATORロール, 49.1.1 EM_CAP_USERロール, 49.1.1 em_catalog.zipファイル, 42.2.4.2, 42.2.4.3 EM_COMPLIANCE_DESIGNERロール, 44.6.1.9, 45.1.3 EM_COMPLIANCE_OFFICERロール, 45.1.3 EM_LINUX_PATCHING_ADMINロール, 43.4.3.1 EM_PLUGIN_AGENT_ADMINロール, 44.6.1.9 EM_PLUGIN_OMS_ADMINロール, 44.6.1.9 電子メール通知

送信メール・サーバーの構成, 51.5.1

管理者の電子メールおよびパスワードの入力, 51.5.2

概要, 2.7

EMCLI, 42.2.4.4, A

ATSサービス・テストの追加, A.6.7

利点, A.1

ZIPファイルの関連付けによる新規汎用コンポーネントの作成, A.6.5

プロパティ・ファイルの作成, A.4.1

Java EEアプリケーションのデプロイおよびアンデプロイ, A.6.8

既存の保存プロシージャを使用するプロシージャの起動, A.4.3

制限事項, A.7

ソフトウェア・ライブラリの記憶域の場所の移行および削除, A.6.6

概要, A.1

パッチ適用, A.5

新しいプロパティ・ファイルの作成, A.5.2.1

既存のプロパティ・ファイルの使用, A.5.2.2

パッチ適用の動詞, A.3.2 WebLogic Serverターゲットへのパッチ適用, A.6.4 前提条件, A.2 Oracle WebLogic Serverのプロビジョニング

プロビジョニング・プロファイルの使用, A.6.2.2

Oracle Databaseソフトウェアのプロビジョニング, A.6.1 Oracle WebLogic Serverのプロビジョニング, A.6.2

スケール・アップまたはスケール・アウト, A.6.2.3

プラガブル・データベースのプロビジョニング, A.4.4

新規プラガブル・データベースの作成, A.4.4.1

プラガブル・データベースとしてのデータベースの移行, A.4.4.3

スナップショット・プロファイルの使用, A.4.4.2

ユーザー定義デプロイメント・プロシージャのプロビジョニング, A.6.3

ステップ/フェーズの追加, A.6.3.2

前提条件, A.6.3.1

プロシージャの実行, A.6.3.3

プロビジョニングの動詞, A.4 ソフトウェア・ライブラリの動詞, A.3.3 プラガブル・データベースの切断, A.4.4.4 既存のプロパティ・ファイルの使用, A.4.2 動詞, A.3

デプロイメント・プロシージャ動詞, A.3.1.3

新しいデプロイメント・プロシージャ動詞, A.3.1.1

古いデプロイメント・プロシージャ動詞, A.3.1.2

EMCLI動詞

confirm_instance, A.3.1.3, A.3.2

create_pluggable_database, A.4.4.1, A.4.4.2.2

describe_instance, A.3.1.3, A.3.2

describe_procedure_input, A.3.1.1, A.3.1.3

get_executions, A.3.1.1, A.3.1.3, A.3.2

get_instance_data, A.3.1.1, A.3.1.3, A.3.2

get_instance_status, A.3.1.3, A.3.2

get_instances, A.3.1.3, A.3.2

get_procedure_types, A.3.1.3, A.3.2

get_procedure_xml, A.3.1.3, A.3.2

get_procedures, A.3.1.3, A.3.2

get_retry_argument, A.3.1.3, A.3.2

ignore_instance, A.3.1.3, A.3.2

migrate_noncdb_to_pdb, A.4.4.3

reschedule_instance, A.3.1.3, A.3.2

resume_instance, A.3.1.3

save_procedure, A.3.1.3, A.3.2

save_procedure_input, A.3.1.1

stop_instance, A.3.1.3

submit_procedure, A.3.1.3

suspend_instance, A.3.1.3

unplug_pluggable_database, A.4.4.4

update_and_retry_step, A.3.1.3

update_procedure_input, A.3.1.1, A.3.1.3

upload_patches, 42.2.4.4

emctl partoolユーティリティ, C

emctl partoolのオプション, C.2

デプロイメント・プロシージャのエクスポート

PARファイルの作成, C.4.2

GUIDの取得, C.4.1

デプロイメント・プロシージャのエクスポート, C.4 PARファイルのインポート, C.5

Cloud Controlの使用, C.5.2

コマンドラインの使用, C.5.1

概要, C.2 PARの概要, C.1 ソフトウェア・ライブラリ, C.3 ファセットの同期の有効化

構成拡張, 44.6.1.7

Enterprise Data Governanceダッシュボード, 46.2.1 Enterprise Managerユーザー

デザイナ, 2.4.1

オペレータ, 2.4.1

スーパー管理者, 2.4.1

エラー処理モード

エラー時も続行, 51.4

継承, 51.4

ターゲットをスキップ, 51.4

エラー時に停止, 51.4

エラー

コンプライアンス標準内, 45.4.4.11, 45.4.4.12

コンプライアンスの評価, 45.2, 45.2 評価エラー

コンプライアンス, 45.2.7

評価結果

コンプライアンス, 45.2.3, 45.2.4

コンプライアンス標準, 45.4.4.9

例

ターゲットへの関連付け, 45.6.1

コンプライアンス標準の作成, 45.6.1

カスタム構成の作成, 45.6.1

カスタム構成収集に基づくカスタムベースのリポジトリ・ルールの作成, 45.6.1

変更アクティビティ計画の使用, 49.6

コンプライアンス結果の表示, 45.6.1

コンプライアンス違反の表示, 45.2.6.3

カスタム・トポロジ・ビューからの関係の除外, 44.10.12 ホスト・コマンドの実行

グループ, 41.5.4

複数のホスト, 41.5.3

単一ホスト, 41.5.5

実行履歴

ホスト・コマンド, 41.5.8

実行結果

ホスト・コマンド, 41.5.9

エクスポート

変更アクティビティ計画, 49.3.5

比較テンプレート, 44.5.2.2

コンプライアンス・フレームワーク, 45.4.2.5

コンプライアンス標準ルール, 45.4.7.9

コンプライアンス標準, 45.4.4.5

構成拡張, 44.6.1.7

リアルタイム監視ファセット, 45.5.2.6

Oracle RACの拡張, 10.2

前提条件, 10.2.1

Oracle RACの拡張

前提条件, 10.2.1

プロシージャ, 10.2.2

F

ファイルの同期, 44.5.8.4

ファイル・システム

記憶域, 40.2.8

フォーマット固有のパーサー, 44.7.3 完全な任意のコンプライアンス・エンティティ権限, 45.1.3 FULL_LINUX_PATCHING_SETUP権限, 43.4.2.1, 43.4.3.1

G

Galaxy CFG

パーサー, 44.7.3

パーサーのパラメータ, 44.7.3.4

汎用システムと新規関係, 44.9 GNS設定, 7.5.2 ゴールド・イメージ

ゴールド・イメージを使用したOracleデータベース・リプレイ・クライアントのプロビジョニング, 12.3

ゴールド・イメージを使用したOracle RACのプロビジョニング, 9.4

GPGキー, 43.4.2.1, 43.4.3.2 GPGシグネチャ, 43.4.3.2 グループ管理, 41.2.6, 41.2.7 グループ

ホスト内, 39.2

H

ハードウェア構成, 情報の収集, 44.1

履歴

統計, 37.4

記憶域, 40.2.11

履歴ジョブ・アクティビティ, 44.4.3 履歴, 構成の変更, 44.4 履歴, 構成, 1.1 ホスト・コマンド

SudoまたはPowerBrokerを使用しての実行, 41.3.2

実行, 41.5

ホスト

ホスト・ターゲットの追加, 41.4

管理, 41

管理, ターゲット設定, 38.5

コマンド, 41.3

実行履歴, 41.5.8

実行結果, 41.5.9

構成

追加および編集, 41.6.3

構成, 41.1 環境のカスタマイズ, 39 デフォルトのシステム実行レベル, 41.2.2 Dell PowerEdge Linuxの監視, 41.6.2 問題の診断, 37.2 グループ管理, 41.2.6 グループ, 39.2 YASTのインストール, 38.2 ログ・ファイル・アラート, 40.1.5 参照表

ホスト管理, 41.2.4

メトリック収集エラー, 40.1.6 監視, 40 監視の設定, 38.4 NFSクライアント, 41.2.5 概要, 37 優先資格証明, 38.3 ホスト・コマンドの実行, 41.5 サービス, 41.2.1 資格証明の設定, 38.3 統計, 37.1

CPU, 40.1.1

ディスク, 40.1.3

メモリー, 40.1.2

プログラム・リソース使用率, 40.1.4

記憶域, 40.2 ツール, 41.3

PowerBroker, 41.3.1

リモート・ファイル・エディタ, 41.3.3

Sudoコマンド, 41.3.1

ユーザー管理, 41.2.6 ターゲットの表示, 37.3 ホスト・アクセス・パーサー, 44.7.4

I

無視ルールの例, 比較, 44.5.5.2

無視ルール, 比較, 44.5.3.3

影響分析, 44.10.9

重要度

定義, 45.1.1

コンプライアンス標準での編集, 45.4.2.1

インポート

比較テンプレート, 44.5.2.2

コンプライアンス・フレームワーク, 45.4.2.6

コンプライアンス標準ルール, 45.4.7.10

コンプライアンス標準, 45.4.4.6

構成拡張, 44.6.1.7

リアルタイム監視ファセット, 45.5.2.6

インシデント

詳細の表示, 45.3.1.4

カスタム・トポロジ・ビューでの関係の追加, 44.10.13 情報マップ, 1.2 インフラストラクチャ要件, 2 Introscopeパーサー, 44.7.3 インベントリと使用状況の詳細, 44.3.3

J

Java Policyパーサー, 44.7.5

Javaプロパティ・パーサー, 44.7.5

ジョブ・アクティビティ

履歴, 44.4.3

ジョブ・システム権限, 45.1.3

K

Kernelモジュール・パーサー, 44.7.4

キー・プロパティ, 44.5.8.3

L

レイヤー, 記憶域, 40.2.12

LDAPパーサー, 44.7.5

ライブラリ

コンプライアンス, 45.1.2

ライフサイクル管理

概要, 1.1

ソリューション領域, 1.1

変更管理, 1.1

コンプライアンスの管理, 1.1

構成管理, 1.1

検出, 1.1

パッチ適用, 1.1

プロビジョニング, 1.1

ソリューションの説明, 1.1 ライフサイクル・ステータス

コンプライアンス・フレームワーク, 45.4.2.1

Linuxディレクトリ・リスティング・パーサー, 44.7.4 Linuxホスト, YASTのインストール, 38.2 Linuxパッチ適用

パッケージ・コンプライアンス, 43.4.3.2

前提条件, 43.4.1

ULNへの登録, 43.4.2.2

グループの設定, 43.4.3

インフラストラクチャの設定, 43.4

コンプライアンス・レポート用のLinuxパッチ適用グループの設定, 43.4.3

RPMリポジトリの設定, 43.4.2, 43.4.2.2

Linuxパッチ適用グループ, 43.1

ジョブ, 43.4.3.2

ローカル・ファイルシステム, 記憶域, 40.2.8 ロック・ダウン, 50.6.2.1 ロック・ダウン機能, 4.1 ログ・ファイル・アラート, ホストの監視, 40.1.5 論理演算子

AND/OR, 44.5.5.2

M

ターゲット・メトリック権限の管理, 45.1.3

任意のターゲット・コンプライアンスの管理権限, 45.1.3

管理リポジトリ, 44.1

管理

変更アクティビティ計画, 49.4

コンプライアンス標準ルール・フォルダ, 45.4.5.2

必須インフラストラクチャ要件

ユーザー・アカウントの作成, 2.4

資格証明の設定, 2.3

必須インフラストラクチャ要件

ソフトウェア・ライブラリの設定, 2.2

手動ルール

コンプライアンス標準ルール, 45.4.6

定義, 45.1.1

違反, 45.2.5

一致ルール

例, 44.5.5.1

一致ルールの例, 比較, 44.5.5.1 一致ルール, 比較, 44.5.3.2 メモリー統計

ホストの監視, 40.1.2

メタデータ検出, 46.1.1 メタデータ検出ジョブ, 46.2.3 メタデータの検出結果, 46.2.3.3 メタデータXMLファイル

ファイルのダウンロード, 42.2.4.2

ファイルのアップロード, 42.2.4.3

メトリック収集エラー

ホストの監視, 40.1.6

ミドルウェア

as a Service (MWaaS)有効化, 23.1, 24.1, 25.1, 26.1

Middleware as a Service (MWaaS)

有効化, 23.1, 24.1, 25.1, 26.1

ミドルウェアのプロビジョニング

BPELプロセス, 22.3.7

コヒーレンス・ノードおよびクラスタ, 22.3.4

Java EEアプリケーションのデプロイ/再デプロイ/アンデプロイ, 22.3.3

デプロイメント・プロシージャ, 22.1

概要, 22.1

主要概念, 22.2

Oracle Application Server, 22.3.8

概要, 22

プロファイル, 22.1

SOA、Service BusおよびWebLogic Serverのスケーリング, 22.3.2

サービス・バスのリソース, 22.3.6

SOAアーティファクト, 22.3.5

WebLogicドメインおよびOracleホームのプロビジョニング, 22.3.1

ミドルウェアのプロビジョニング

Middlewareのプロビジョニングおよびスケール・アップ/スケール・アウトのベスト・プラクティス, 29.4

Middlewareプロビジョニング・コンソール, 22.1 Middlewareプロビジョニング・ソリューション, 22.1 プラガブル・データベースとしてのデータベースの移行, 17.3.4 MIMEタイプ・パーサー, 44.7.5 監視

資格証明, 設定, 38.4.2

ホスト, 40

NFSマウント, 40.2.8

移動

変更アクティビティ計画でのタスク定義, 49.2.1

MQ-Series

パーサー, 44.7.3

パーサーのパラメータ, 44.7.3.5

N

名前付き資格証明, ホスト, 38.3

ネットワーク・カード

構成, 41.2.3

ホスト内, 41.2.3

ネットワーク・ファイルシステム 「NFS」を参照 NFS (ネットワーク・ファイルシステム)

クライアント

追加および編集, 41.2.5

ホスト管理, 41.2.5

マウントの監視, 40.2.8 記憶域, 40.2.8 デプロイ不可能な計画, 42.1.3.2 通知, 2.7

O

監視

ユーザーへの通知, 45.3.2.3

Odinパーサー, 44.7.3 OPlan, 42.4.3, 42.4.3 オプションのインフラストラクチャ要件

ホスト構成, F.6.1

プロビジョニング用自己更新, 2.6

電子メール通知の設定, 2.7

Oracleクラスタウェア・クローン, 4.3.10.3 Oracleクラスタウェア・クローン, 4.3.10.4 Oracle Databaseクローン, 4.3.10.2 Oracle Databaseトポロジ, 5.2 Oracle Label Security, 46.1.2 Oracle ORAパーサー, 44.7.3 Oracle RACデータベース・トポロジ, 7.2 Oracle Real Application Clustersデータベース・トポロジ, 7.2 Oracle Service Bus, 33 OSスクリプト, ロード, 41.5.6

P

PAM構成パーサー, 44.7.4

パーサー

AIXインストール済パッケージ, 44.7.5

Apache HTTPD, 44.7.5

Autosys, 44.7.5

Blue Martini DNA, 44.7.3

列指向, 44.7.4

Connect:Direct, 44.7.3

Cronアクセス, 44.7.4

Cronディレクトリ, 44.7.4

CSV, 44.7.4

カスタムCFG, 44.7.5

データベース問合せ, 44.7.3

Db2, 44.7.3

ディレクトリ, 44.7.3

E-Business Suite, 44.7.3

フォーマット固有, 44.7.3

Galaxy CFG, 44.7.3

ホスト・アクセス, 44.7.4

Introscope, 44.7.3

Java Policy, 44.7.5

Javaプロパティ, 44.7.5

Kernelモジュール, 44.7.4

LDAP, 44.7.5

Linuxディレクトリ・リスティング, 44.7.4

MIMEタイプ, 44.7.5

MQ-Series, 44.7.3

Odin, 44.7.3

Oracle ORA, 44.7.3

PAM構成, 44.7.4

プロセス・ローカル, 44.7.4

プロパティ, 44.7.5

Radia, 44.7.5

セクション・プロパティ, 44.7.5

Secure TTY, 44.7.4

Siebel, 44.7.3

SiteMinderエージェント, 44.7.5

SiteMinder Registry, 44.7.5

SiteMinder Report, 44.7.5

SmWalker, 44.7.5

Solarisインストール済パッケージ, 44.7.4

Sun ONE Magnus, 44.7.5

Sun ONE Obj, 44.7.5

Tuxedo, 44.7.5

UbbConfig, 44.7.3

UNIX Config, 44.7.5

UNIX Crontab, 44.7.4

UNIXディレクトリ・リスティング, 44.7.4

UNIX Groups, 44.7.4

UNIX GShadow, 44.7.4

UNIX Hosts, 44.7.4

UNIX INETD, 44.7.4

UNIXインストール済パッチ, 44.7.3

UNIX Login, 44.7.5

UNIX Passwd, 44.7.4

UNIX PROFTPD, 44.7.5

UNIX Protocols, 44.7.4

UNIX再帰的ディレクトリ・リスティング, 44.7.3

UNIX Resolve, 44.7.5

UNIX Services, 44.7.4

UNIX Shadow, 44.7.4

UNIX SSH Config, 44.7.5

UNIX System, 44.7.5

UNIXシステムCrontab, 44.7.4

UNIX VSFTPD, 44.7.5

UNIX XINETD, 44.7.5

WebAgent, 44.7.5

WebLogic (属性キー), 44.7.2.1

WebSphere (属性キー), 44.7.2.1

WebSphere (汎用), 44.7.2.2

Windowsチェックサム, 44.7.5

XMLデフォルト(属性キー), 44.7.2.1

XML (汎用), 44.7.2.2

パッチ管理ソリューション

画面へのアクセス, 42.1.2

競合チェック, 42.4.3

計画の作成ウィザード, 42.1.3.3

デプロイメント・プロシージャのカスタマイズ, 42.4.3, 42.6.12

パッチ適用に関する問題の診断および解決, 42.5

カタログ・ファイルのダウンロード, 42.2.4.2

概要, 42.1.2

ナレッジ記事, 42.3.2

概要, 42.1

パッチ推奨, 42.3.1

パッチ・テンプレート, 42.4.5, 42.6.2

パッチ適用機能レポート 42.2.5

パッチ適用モード

インプレース・モード, 42.1.6.2, 42.4.3

オフライン・モード, 42.1.6.1, 42.2.4.1

オンライン・モード, 42.1.6.1, 42.2.3.1

ホーム外モード, 42.1.6.2, 42.4.3

パラレル・モード, 42.1.6.3, 42.4.3

ローリング・モード 42.1.6.3, 42.4.3

Oracle Data Guardターゲットへのパッチ適用, 42.4.9 Oracle Exadataへのパッチ適用, 42.4.8 Oracle Grid Infrastructureターゲットへのパッチ適用, 42.4.7 Oracle Identity Managementターゲットへのパッチ適用, 42.4.10 Oracle Siebelターゲットへのパッチ適用, 42.4.11 パッチ適用ワークフロー, 42.1.7 スイッチバックの実行, 42.4.4 データベース・ターゲットの準備, 42.4.3 プロキシ詳細の登録, 42.2.3.2 パッチ競合の解決, 42.6.10 パッチのロールバック, 42.4.3, 42.5.4, 42.6.14 パッチ計画のスケジューリング, 42.4.3 パッチの検索, 42.3.4 インフラストラクチャの設定, 42.2 サポートされているターゲット, 42.1.5 カタログ・ファイルのアップロード, 42.2.4.3 ソフトウェア・ライブラリへのパッチのアップロード, 42.2.4.4 パッチ計画の確認, 42.4.3 パッチ計画

アクセス, 42.4.2

パッチの追加, 42.4.3

ターゲットの追加, 42.4.3, 42.6.7

分析, 42.4.3

作成, 42.4.1

デプロイメント・プロシージャのカスタマイズ, 42.4.3, 42.6.12

削除, 42.6.4

計画の削除, 42.6.4

通知の有効化, 42.4.3

競合チェックの有効化または無効化, 42.4.3

概要, 42.1.3.1

パッチの競合, 42.1.3.3

パッチ計画タイプ, 42.1.3.2

パッチ計画の準備, 42.4.3

ロールおよび権限, 42.2.2

パッチ・テンプレートとしての保存, 42.4.5

スケジュール, 42.4.3

資格証明の指定, 42.4.3

デプロイメント・オプションの指定, 42.4.3

計画情報の指定, 42.4.3

パッチのステージング, 42.4.3

サポートされているパッチ・タイプ, 42.1.3.1

スイッチバック, 42.4.4

計画の作成ウィザードの使用, 42.1.3.3

検証, 42.4.3

検証と競合の解決, 42.1.3.3

パッチ推奨, 42.3.1 パッチ・テンプレート

削除, 42.6.5

テンプレートの削除, 42.6.5

パッチのダウンロード, 42.6.3

テンプレートの変更, 42.6.1

テンプレートの編集ウィザードの使用, 42.1.4.2

テンプレートの表示, 42.6.1

パッチ適用

環境の分析, 42.2.5

問題の診断, 42.5.2

適用可能なパッチの特定

ソフトウェア・ライブラリでの検索, 42.3.5

MOSでの検索, 42.3.4

ナレッジ記事の使用, 42.3.2, 42.3.3

パッチ推奨の使用, 42.3.1

概要, 42.1.1 Linuxパッチ適用, 43.1 パッチ管理ソリューション, 42.1.2 パッチ適用機能レポート 42.2.5 Linuxホストへのパッチ適用, 43 問題の解決, 42.5.3 変更アクティビティ計画の使用, 49.6.3 Linuxホストへのパッチ適用

概念, 43.1

デプロイメント・プロシージャ, 43.2

前提条件の確認, 43.4.1

概要, 43.1

パッケージ・コンプライアンス, 43.4.3.2

ULNへの登録, 43.4.2.2

インフラストラクチャの設定, 43.4

コンプライアンス・レポート用のLinuxパッチ適用グループの設定, 43.4.3

RPMリポジトリの設定, 43.4.2, 43.4.2.2

サポートされているLinuxリリース, 43.3

フェーズ

パラレル, 50.3.3.1

ローリング, 50.3.3.1

プラガブル・データベースの管理

プラガブル・データベースの状態の変更, 17.6.2

プラガブル・データベースのオープン/クローズ, 17.6.2

プラガブル・データベース間の切替え, 17.6.1

プラガブル・データベース・ジョブ

作成, 17.3.1.2, 17.3.2.2, 17.3.3.2, 17.5.1

削除, 17.4.2.2, 17.5.3

切断, 17.4.1.2, 17.5.2

プラガブル・データベースの管理の要件, 17.2 プラガブル・データベースのプロビジョニング

プラガブル・データベースのクローニング

フル・クローンの使用, 17.3.3

スナップ・クローンの使用, 17.3.3.1

新規プラガブル・データベースの作成, 17.3.1 プラガブル・データベースとしてのデータベースの移行, 17.3.4 プラガブル・データベースのプラグイン, 17.3.2 プラガブル・データベースの削除

プラガブル・データベースの削除, 17.4.2

プラガブル・データベースの切断, 17.4.1

プラガブル・データベース

管理, 17.6

はじめに, 17.1

ジョブ, 17.5

概要, 17.2

プロビジョニング, 17.3

削除, 17.4

解析後のルール, 44.7.6 PowerBrokerツール, 41.3.1

ホスト・コマンドの実行, 41.3.2

優先資格証明, ホスト, 38.3 印刷

変更アクティビティ計画, 49.3.6

権限委任設定, 38.3 権限

コンプライアンス・フレームワーク, 45.1.3

構成拡張, 45.1.3

コンプライアンス・エンティティの作成, 45.1.3

完全な任意のコンプライアンス・エンティティ, 45.1.3

ジョブ・システム, 45.1.3

任意のターゲット・コンプライアンスの管理, 45.1.3

任意のターゲット・メトリックの管理, 45.1.3

変更アクティビティ計画での使用, 49.1.1

任意のコンプライアンス・フレームワークの表示, 45.1.3

任意のターゲットの表示, 45.1.3

権限, 構成拡張, 44.6.1.9 問題

ホストでの診断, 37.2

プロセス・ローカル・パーサー, 44.7.4 プログラム・リソース使用率統計, ホストの監視, 40.1.4 プロパティ・パーサーの構成

区切られたセクション, 44.7.5.3

区切られた構造, 44.7.5.3

要素セル, 44.7.5.3

明示的なプロパティ, 44.7.5.3

暗黙的なプロパティ, 44.7.5.3

INIセクション, 44.7.5.3

キーワード名プロパティ, 44.7.5.3

キーワード・プロパティ, 44.7.5.3

予約されたディレクティブ, 44.7.5.3

予約された関数, 44.7.5.3

シンプル・プロパティ, 44.7.5.3

構造, 44.7.5.3

XML構造, 44.7.5.3

プロパティ・パーサー, 44.7.5

拡張構成, 44.7.5.3

拡張パラメータ, 44.7.5.2

基本パラメータ, 44.7.5.1

保護ポリシー

データ・リダクション, 46.1.2

Oracle Label Security, 46.1.2

透過的データ暗号化, 46.1.2

仮想プライベート・データベース, 46.1.2

データベースのプロビジョニング

Grid InfrastructureとOracle RACデータベース, 7.3

Oracle Grid InfrastructureとOracle Real Application Clusters, 7

Linuxのプロビジョニング, 36

概要, 36.1

Oracle RACデータベースのプロビジョニング

新規クラスタ上のファイル・システムの使用, 7.5

既存のクラスタ上のファイル・システムの使用, 7.4

Oracle RACデータベースのプロビジョニング, 7.5.2 プロビジョニング

Oracle RAC (Real Application Cluster)の削除またはスケール・ダウン, 11

Oracle RAC (Real Application Cluster)の拡張, 10

Linuxオペレーティング・システムのプロビジョニング, 36

Oracle Application Serverのプロビジョニング, 32, 35

Oracle BPELプロセスのプロビジョニング, 34

Oracleデータベース・リプレイ・クライアントのプロビジョニング, 12

Oracle Service Busリソースのプロビジョニング, 33

記憶域, 40.2.3

ベアメタル・サーバーのプロビジョニング, 36.6 データベース・クライアントのプロビジョニング

はじめに, 12.1

Oracle BPELプロセスのプロビジョニング, 34.3

概要, 34.1

Oracleデータベース・クライアントのプロビジョニング, 12.4 Oracle RACのプロビジョニング

アーカイブされたソフトウェア・バイナリ, 9.5

ゴールド・イメージ, 9.4

非root資格証明, 9.6

Oracle Real Application Clusters Oneデータベースのプロビジョニング, 8.3 Oracleスタンバイ・データベースのプロビジョニング

ロジカル・スタンバイ・データベースの作成, 13.3

フィジカル・スタンバイ・データベースの作成, 13.2

プライマリ・データベースのバックアップを作成, 13.5

既存のスタンバイ・データベースの管理, 13.4

Oracleスタンバイ・データベースのプロビジョニング, 13 プラガブル・データベースのプロビジョニング, 17.3 プロビジョニング・プロファイル, 4.1 SOAアーティファクトのプロビジョニング, 32.4

ゴールド・イメージ, 32.4.2

R

Radiaパーサー, 44.7.5

リアルタイム監視ファセット・フォルダ, 編集, 45.5.2.3

リアルタイム監視ファセット, 45.5

概要, 45.5.1

ベース属性の変更, 45.5.2.7

作成, 45.5.2.2, 45.5.2.3

類似作成, 45.5.2.5

定義, 45.1.1

削除, 45.5.2.4

編集, 45.5.2.2

エンティティ・タイプ, 45.5.1.1

エクスポート, 45.5.2.6

インポート, 45.5.2.6

操作, 45.5.2

パターン, 45.5.1.2

ライブラリの表示, 45.5.2.1

リアルタイム監視ルール

コンプライアンス・スコア, 45.2.9.2

コンプライアンス標準ルール, 45.4.6

定義, 45.1.1

ターゲット・プロパティ・フィルタ, 45.4.7.3

ファセットの使用, 45.4.7.3

リアルタイム監視, 警告, 45.4.4.14 リアルタイム監視の監査ステータス, 定義, 45.1.1 リアルタイム監視バンドルの存続期間, 制御, 45.4.7.3 リアルタイム監視バンドル, 定義, 45.1.1 リアルタイム監視

定義, 45.1.1, 45.1.2

調査, 45.3

手動設定, 45.3.2.1

ユーザーへの通知, 45.3.2.2

操作, 45.3.2

ルール, アクションのタイプ, 45.4.7.3

表示, 45.3.1

参照ホスト, 36.2.2.4, 36.2.2.4 リフレッシュ, 記憶域, 40.2.13 関係, 44.9 リモート・ファイル・エディタ・ツール, 41.3.3 プラガブル・データベースの削除, 17.4 レポート, コンプライアンス, 45.2.8 リポジトリ・ルール

定義, 45.1.1

コンプライアンス標準, 45.4.6

結果

コンプライアンス評価, 45.2.3, 45.2.4

逆変換, 44.5.8.4 ロール

EM_CAP_ADMINISTRATOR, 49.1.1

EM_CAP_USER, 49.1.1

変更アクティビティ計画, 49.1.1

ロール, 構成拡張, 44.6.1.9 ロールアップ・オプション, 44.3.3 根本原因分析，「依存性分析」を参照 ルーティング構成, ネットワーク・カード, 41.2.3 RPMパッケージ, 43.1, 43.4.2.2 RPMリポジトリ, 36.2.2.5, 43.1, 43.4.2.1

概要, 36.2.2.5

設定, 36.4.3, 43.4.2

ルールの例, 比較, 44.5.5 ルールの式, 比較, 44.5.4 ルール, 44.5.3

包含または除外ルール, 44.5.3.3

一致ルール, 44.5.3.2

値制約ルール, 44.5.3.1

ルール式, 44.5.4 ルール構文, 44.5.4 ルール, 比較, 1.1, 44.5.3 ルール, 構成拡張, 44.6.1.6

S

ドラフトとして保存, 構成拡張, 44.6.1.8

保存された構成, 44.3.2, 44.3.2

Oracle RACのスケール・ダウン, 11.4

WebLogicドメインのスケール・アップ/スケール・アウト

前提条件, 29.2

「ミドルウェアのスケール・アップ/スケール・アウト」デプロイメント・プロシージャの実行, 29.3

SOAドメイン、Service BusドメインおよびWebLogic Serverドメインのスケール・アップ/スケール・アウト, 29 比較のスケジュール, 44.5.7.5 スキーマ・ベースライン, 47.1

複数バージョン, 47.2.4

スキーマ・ベースライン・バージョン, 47.2.2 スキーマ・ベースライン

エクスポート, 47.2.5

インポート, 47.2.5

概要, 47.2

スキーマ変更計画, 47.1 スキーマの比較, 47.1 スキーマの比較バージョン, 47.3.2 スキーマの比較, 47.3.1

比較オプション, 47.3.1

概要, 47.3

スキーマ・マップ, 47.3.1, 47.3.1

有効範囲指定, 47.3.1

スキーマの同期化, 47.1

概要, 47.4

バージョン, 47.4.3

スキーマの同期化バージョン

スキーマの同期化サイクル, 47.4.3.1

スキーマの同期化

スキーマ・マップ, 47.4.1

有効範囲指定, 47.4.1, 47.4.1

同期化モード, 47.4.1

同期化オプション, 47.4.1

有効範囲指定, 47.2.1 構成の検索

事前定義済, 1.1, 44.2

ユーザー定義, 1.1, 44.2

検索

コンプライアンス・フレームワーク, 45.4.2.8

コンプライアンス標準ルール, 45.4.7.12

コンプライアンス標準, 45.4.4.8

セクション・プロパティ・パーサー, 44.7.5 Secure TTYパーサー, 44.7.4 セキュリティ・メトリック

有効化, 45.4.4.15

コンプライアンス標準, 45.4.4.15

機密列タイプ, 46.2.3.1 機密データ検出, 46.2.2 Service Busプロビジョニング, 23, 24, 25, 26 サービス

ホスト内, 41.2.1

タスク定義での依存性の設定, 49.2.1 設定

ホストを監視するための環境, 38

ホスト資格証明, 38.3

ホストの監視, 38.4

監視資格証明, 38.4.2

ホスト管理のターゲット, 38.5

MOSの設定, 2.5 Siebel

パーサー, 44.7.3

パーサーのパラメータ, 44.7.3.6

SiteMinderエージェント・パーサー, 44.7.5 SiteMinder Registryパーサー, 44.7.5 SiteMinder Reportパーサー, 44.7.5 SmWalkerパーサー, 44.7.5 SOAプロビジョニング, 23, 24, 25, 26 ソフトウェア・ライブラリ

パッチのアップロード, 42.2.4.4

ソフトウェア・ライブラリの管理, 2.2, 2.2 ソフトウェア・ライブラリ・コンソール, 2.2 Solarisインストール済パッケージ・パーサー, 44.7.4 OSユーザーの指定, 7.5.2 ルールの指定, 44.5.3 SQL, 構成検索での使用, 44.2.2 ステージング・サーバー, 36.2.2.3

概要, 36.2.2.3

統計

ホスト, 37.1

記憶域, 37.4

統計, コンプライアンスへのアクセス, 45.2.1 手順

アクション, 50.3.3.2

計算, 50.3.3.2

ファイル転送, 50.3.3.2

ホスト・コマンド, 50.3.3.2

ジョブ, 50.3.3.2

ライブラリ・コンポーネント, 50.3.3.2

ライブラリ・ディレクティブ, 50.3.3.2

手動, 50.3.3.2

ストレージ

ファイル・システム, 40.2.8

履歴, 40.2.11

ホストの監視, 40.2

レイヤー, 40.2.12

ネットワーク・ファイル・システム, 40.2.8

リフレッシュ, 40.2.13

統計, 37.4

使用率, 40.2.1

ベンダーの配分, 40.2.10

ボリューム, 40.2.9

Sudoコマンド, 41.3.1

ホスト・コマンドの実行, 41.3.2

サマリー

変更アクティビティ計画, 49.4.1

Sun ONE Magnusパーサー, 44.7.5 Sun ONE Objパーサー, 44.7.5 違反の抑止, 45.2.5, 45.6.3 ファイルの同期, 44.5.8.4 システム比較結果, 44.5.8.2 システム・コンポーネント構造, 44.10.4

T

ターゲット設定

ホスト管理, 38.5

ターゲット・タイプ, カスタム, 44.6.1.1 ターゲット

コンプライアンス標準の関連付け, 45.4.4.13, 45.6.2

ホスト, 37.3

変更アクティビティ計画でのタスク・グループ, 49.1.2.3 タスク

変更アクティビティ計画内, 49.4.2

テンプレート, 比較用の選択, 44.5.7.3 ツール

ホスト, 41.3

トポロジ

Oracle RACデータベース・トポロジ, 7.2

トポロジ・ビューア

グラフ上の情報の表示形式の制御, 44.10.16

作成

ターゲットへの関係, 44.10.14

ビューのカスタマイズ, 44.10.10 カスタム・ビューの削除, 44.10.11 ターゲットからの関係の削除, 44.10.15 依存性分析, 44.10.8 カスタム・ビューからの関係の除外, 44.10.12 影響分析, 44.10.9 カスタム・ビューにおける関係の追加, 44.10.13 構成変更の追跡, 44.4 透過的データ暗号化, 46.1.2 プロパティの欠落エラーのトラブルシューティング, 42.5.1.1 サポートされない構成エラーのトラブルシューティング, 42.5.1.2 Tuxedoパーサー, 44.7.5

U

UbbConfigパーサー, 44.7.3

ULNチャネル, 43.1, 43.4.2.2

ULN構成チャネル, 43.1

ULNカスタム・チャネル, 43.1

Unbreakable Linuxネットワーク(ULN), 43.1

構成拡張のアンデプロイ, 44.6.2.1

UNIX Configパーサー, 44.7.5

UNIX Crontabパーサー, 44.7.4

UNIXディレクトリ・リスティング・パーサー, 44.7.4

UNIX Groupsパーサー, 44.7.4

UNIX GShadowパーサー, 44.7.4

UNIX Hostsパーサー, 44.7.4

UNIX INETDパーサー, 44.7.4

UNIXインストール済パッチ

パーサー, 44.7.3

パーサーのパラメータ, 44.7.3.7

UNIX Loginパーサー, 44.7.5 UNIX Passwdパーサー, 44.7.4 UNIX PROFTPDパーサー, 44.7.5 UNIX Protocolsパーサー, 44.7.4 UNIX再帰的ディレクトリ・リスティング

パーサー, 44.7.3

パーサーのパラメータ, 44.7.3.8

UNIX Resolveパーサー, 44.7.5 UNIX Servicesパーサー, 44.7.4 UNIX Shadowパーサー, 44.7.4 UNIX SSH Configパーサー, 44.7.5 UNIXシステムCrontabパーサー, 44.7.4 UNIX Systemパーサー, 44.7.5 UNIX VSFTPDパーサー, 44.7.5 UNIX XINETDパーサー, 44.7.5 プラガブル・データベースの切断, 17.4.1 違反の抑止解除, 45.2.5 up2dateパッチ適用ツール, 43.4.1, 43.4.2.1, 43.4.3.1 up2date_comp.zipファイル, 43.4.2.1 データベース・インスタンスのアップグレード, 18.4 データベースのアップグレード

開始, 18.1

データベースのアップグレード, 18

データベース・アップグレード・ウィザード, 18.4

デプロイメント・プロシージャ, 18.3

前提条件, 18.3.2

Oracleクラスタ・データベースのアップグレード, 18.3.3

Oracle Clusterwareのアップグレード, 18.3.4

Oracleデータベース・インスタンスのアップグレード, 18.3.5, 18.3.5

ユーザー・アカウント

概要, 2.4

ユーザー管理, 41.2.6, 41.2.7 ユーザー定義デプロイメント・プロシージャ, 50.6 UTF-8, 構成拡張のエンコーディング, 44.6.1.3

V

値制約ルール, 比較, 44.5.3.1

ベンダーの配分, 記憶域, 40.2.10

任意のコンプライアンス・フレームワークの表示権限, 45.1.3

任意のターゲットの表示権限, 45.1.3

表示

変更アクティビティ計画タスク, 49.5

比較テンプレート, 44.5.2.2

構成データ, 44.3.1

構成拡張仕様の詳細, 44.6.1.7

構成状態の問題の詳細, 44.10.7

インシデントの詳細, 45.3.1.4

リアルタイム監視ファセット・ライブラリ, 45.5.2.1

リアルタイム監視, 45.3.1

違反の詳細

コンプライアンス標準, 45.2.6.3

違反

クリア, 45.6.4

法令順守

管理, 45.2.5

例の表示, 45.2.6.3

詳細

コンプライアンス・フレームワーク, 45.2.6.3

コンプライアンス標準, 45.2.6.3, 45.2.6.3

ターゲット, 45.2.6.3 抑止, 45.2.5, 45.6.3 抑止解除, 45.2.5 仮想プライベート・データベース, 46.1.2 ボリューム, 記憶域, 40.2.9

W

WebAgentパーサー, 44.7.5

Web-Based Enterprise Management (WBEM) Fetchletのメトリック, 41.6.1

WebLogicパーサー(属性キー), 44.7.2.1

WebLogic Serverプロビジョニング, 23, 24, 25, 26

WebLogic Server署名ルール, コンプライアンス標準内, 45.4.6

WebLogicサーバー・ターゲット, 44.2.3

WebSphereパーサー(属性キー), 44.7.2.1

WebSphereパーサー(汎用), 44.7.2.2

Windowsチェックサム・パーサー, 44.7.5

X

XMLデフォルト・パーサー(属性キー), 44.7.2.1

XMLパーサー(汎用), 44.7.2.2

XPath

条件および式, 44.7.6

構成拡張, 44.6.1.6

Y

YAST, Linuxホストでのインストール, 38.2

yumパッチ適用ツール, 43.4.1, 43.4.3.1

オラクル社の法律上の注意点について

コピーライトについて

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

商標と登録商標について

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

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

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。