| Oracle® Enterprise Manager概要 11gリリース11.1.0.1 B61020-01 |
|
 戻る |
 次へ |
この章では、変更管理の概要について説明します。内容は次のとおりです。
エンタープライズ・アプリケーションのライフサイクルを管理するため、組織では、開発、ステージング、本稼働、テストなどの様々な目的でアプリケーション・データベースの複数のコピーを維持する必要があります。これらの各データベースは、異なるプロセスに準拠する必要があります。たとえば、本番データベースの場合、適切な生産管理手順に準拠することが不可欠です。管理者は、許可されない変更（必要な変更承認を得ていない索引の削除など）を検出するツールを保持する必要があります。この場合、本番データベースに対する変更を毎日または毎週監視することが非常に重要になります。
ライフサイクル管理のもう1つの重要な側面は、データベース・コンプライアンス（すべてのデータベースを基準となる構成に準拠させること）です。組織の標準またはベスト・プラクティスに準拠することで、データベースの効率性、メンテナンス性および運用の容易性が保証されます。
開発データベースの場合、開発者が変更を加えますが、その変更はデータベース管理者がステージング・データベースまたはテスト・データベースに統合および伝播する必要があります。その目的は、開発環境に加えられた変更を識別し、本番データベースにすでに存在する他の変更を考慮しながら、ステージング・データベースまたはテスト・データベースに同じ変更を加えることです。
通常、ほとんどのアプリケーションは、時間の経過とともにアップグレードされます。また、ほとんどのアプリケーションは、要件に合うようにビジネス・ユーザーによってカスタマイズされます。アプリケーションのカスタマイズは、通常、アプリケーション・ベンダーにより提供されるデータベース・オブジェクトまたはPL/SQLモジュールに依存します。アップグレード・スクリプトはアプリケーション・ベンダーから提供されるため、顧客はアップグレード手順が独自のカスタマイズ内容にどの程度影響するかについてほとんどわかりません。顧客は、アップグレード・データベースをテストする場合、アップグレードの前後にアプリケーション・スキーマのベースラインを取得できます。前後のベースラインを比較することで、アプリケーションにより変更されたモジュールがわかります。これにより、アプリケーションをアップグレードした結果としてカスタマイズ内容が受ける影響の程度をより正確に把握できます。
変更管理には、開発者およびデータベース管理者がデータベース環境の変更を管理できるようにする次の3つのコア機能があります。
ベースライン: ある時点におけるデータベースおよび関連データベース・オブジェクトの定義
比較: ベースライン（またはデータベース）と他のベースライン（またはデータベース）間の相違の完全なリスト
同期化: ベースラインのデータベース定義取得から（またはデータベースから）ターゲット・データベースに変更を移行するプロセス
データベースのリリース9.x以上では、Enterprise Managerを通じてデータベース・ターゲットにログインするユーザーは、データベースの取得または比較のためにSELECT ANY DICTIONARY権限およびSELECT_CATALOG_ROLEロールを保持している必要があります。ディクショナリの同期化を作成するために宛先データベースにログインするユーザーは、SELECT ANY DICTIONARY権限およびSELECT_CATALOG_ROLEロールに加え、データベース管理者（DBA）であるか、同期化するオブジェクトに対する適切な権限を保持している必要があります。
ディクショナリ・ベースラインは、特定の時点で取得された一連のデータベース定義を含みます。ベースラインは、Simple XMLまたはSXMLというXML文書の形式で、Enterprise Managerリポジトリに格納されます。
各ベースラインには、一意の名前を割り当てる必要があります。ベースラインは、そのベースラインで取得されるデータベース・オブジェクトの有効範囲と一致するように命名すると便利です（Financial 11.5.10、HR Benefits、PO Check Printなど）。1つのベースラインは、異なる時点で取得された一連のバージョンを保持できます。ベースラインの複数のバージョンを作成すると、一連のデータベース・オブジェクトの定義に対する変更を時間経過に合せて追跡できます。同じベースラインの2つのバージョンを比較することで、そのバージョン間で発生した変更を確認できます。
ベースラインを作成する場合、対応するベースラインの有効範囲の指定も作成します。有効範囲の指定では、取得するデータベース・オブジェクトおよびスキーマの名前とタイプを記述します。ベースライン定義を作成したら、Enterprise Managerジョブを発行することで、ベースラインの最初のバージョンを取得できます。後で（または一定の間隔で）、同じベースラインの追加のバージョンを取得できます。各ベースライン・バージョンには、バージョンの取得時点で存在したメタデータ定義が記録されます。
有効範囲の指定では、ベースラインに取得するデータベース・オブジェクトを識別します。（有効範囲の指定では、ディクショナリの比較および同期化で処理するオブジェクトも識別します。）一度ベースラインの有効範囲を指定したら、その有効範囲指定を変更することはできません。この制限により、ベースラインのすべてのバージョンが、同じルール・セットを使用して取得されたことが保証されます。つまり、バージョン間の相違は、有効範囲指定の変更ではなく、データベースの変更に基づきます。異なる有効範囲指定を使用してディクショナリ・オブジェクトを取得するには、新しいベースラインを作成する必要があります。
ベースラインの有効範囲指定には、次の3つの形式があります。
取得するスキーマおよびオブジェクト・タイプを指定できます。たとえば、スキーマAPPL1およびAPPL2のすべての表、索引およびビューを取得できます。この形式の有効範囲指定は、アプリケーション・オブジェクトを含む適切に定義されたスキーマのセットが存在する場合に適切です。スキーマ・オブジェクトに加え、非スキーマ・オブジェクト（ユーザー、ロール、表領域など）や、ユーザーおよびロールに対する権限付与も取得できます。
除外するスキーマと、オブジェクト・タイプを指定できます。この形式の有効範囲指定では、指定したスキーマ以外のすべてのスキーマに含まれるオブジェクトが取得されます。たとえば、SYSTEMおよびSYS以外のスキーマのすべてのオブジェクト・タイプを取得できます。この形式の有効範囲指定は、Oracle付属のスキーマに含まれるオブジェクトを除き、すべてのデータベース・オブジェクトを取得する場合に適切です。有効範囲指定の最初の形式と同様に、非スキーマ・オブジェクトと権限付与も取得できます。
最後の形式として、個々のオブジェクトのタイプ、スキーマおよび名前を指定することで、それらのスキーマ・オブジェクトを個別に取得できます。この形式の有効範囲指定は、1つ以上のスキーマ内に含まれるすべてのオブジェクトではなく、一部の特定のオブジェクトを取得する場合に適切です。個々のスキーマ・オブジェクトを取得する一方で、非スキーマ・オブジェクトと権限付与も取得できます。
有効範囲指定にユーザーやロールなどの非スキーマ・オブジェクト・タイプを含めると、そのタイプのオブジェクトがすべて取得されます。個々の非スキーマ・オブジェクトを取得する方法はありません。図7-1は、有効範囲を指定できる「ディクショナリ・ベースラインの作成: オブジェクト」ページを示しています。
図7-1 取得するスキーマおよびオブジェクト・タイプを選択する形式のベースラインの有効範囲指定
ベースラインを定義する最後の手順として、ベースラインの最初のバージョンを取得する時期を指定します。最初のバージョンは、即座に取得するか、後で（たとえば、データベースがアクティブな開発作業に使用されていないときに）取得できます。また、追加の手動操作を行わずに一定の間隔で追加のベースライン・バージョンを取得するように指定することもできます。
ベースラインを選択して「すぐに再取得」を指定することで、任意の時点の新しいベースライン・バージョンを取得することも可能です。
最初のバージョンの後に処理されるベースラインは、通常、最初のバージョンよりもずっと高速に処理されます。変更のあったオブジェクトのみが新規バージョンに取得されます。つまり、変更されたオブジェクトが数パーセントであれば、追加のベースライン・バージョンに必要とされる記憶域は、最初のバージョンで使用された記憶域よりほんの少し多くなるだけです。図7-2に、ディクショナリ・ベースラインの最初のバージョンを示します。
単一のディクショナリ・ベースライン・バージョン内で、個々のオブジェクト属性の調査、個々のオブジェクトに対応するDDLの生成、およびベースライン・バージョンのすべてのオブジェクトに対応するDDLの生成を行うことができます。ベースライン・バージョンに取得されたオブジェクト定義は、特定の時点でのオブジェクトの状態を表すことを意図しているため、変更することはできません。
ベースライン・オブジェクトを表示すると、オブジェクトの属性がグラフィカルに表示されます。
ベースライン・オブジェクトを選択して「DDLの生成」を指定すると、オブジェクトの作成に使用されるDDLが表示されます。図7-3に、ベースライン・オブジェクトに対して生成されたDDLを示します。
ベースライン・バージョンを選択して「DDLの生成」を指定すると、ベースライン・バージョンのすべてのオブジェクトに対応するDDLが生成されます。正しい順序でオブジェクトを作成する作業が行われますが（索引の前に表を作成するなど）、生成されたDDLをデータベースで実行しても、ベースライン・バージョンのオブジェクトを作成できるとはかぎりません。たとえば、スキーマAPPL1に含まれるすべてのスキーマ・オブジェクトを取得し、ユーザーAPPL1を含まないデータベースでベースライン・バージョンのDDLを実行しようとしても、生成されたDDLは実行に失敗します。
ベースライン・バージョンは、比較や同期化などの他のChange Management Packアプリケーションでも使用されます。ベースライン・バージョンは、データベース（または他のベースライン・バージョン）と比較できます。また、ベースライン・バージョンを同期化のオブジェクト定義のソースとして使用し、別のデータベースにその定義を再作成できます。
ベースラインに複数のバージョンが含まれる場合、バージョン間の相違を調査できます。
あるバージョンとその先行バージョンの間における変更点を確認するには、バージョンを選択して「前のバージョン以降の変更を表示」を指定します。画面に、前のバージョン以降に変更されたオブジェクト（図7-4）、追加または削除されたオブジェクト、および変更されていないオブジェクトが表示されます。変更されたオブジェクトを選択すると、そのオブジェクトの2つのバージョン間の相違が表示されます。
ベースラインのすべてのバージョンにわたり変更された個々のオブジェクトを確認するには、オブジェクトを選択して「バージョン履歴の表示」を指定します。画面に、オブジェクトが最初に取得、変更または削除されたときのバージョンが表示されます（図7-5を参照）。この表示で、任意の2つのベースライン・バージョンに含まれるオブジェクトの定義を比較できます。
ベースラインのエクスポート/インポート機能を使用して次のことを行えます。
異なるリポジトリを持つ2つのGrid Control間でのベースラインの転送。
オフラインでのベースラインの保管。ベースラインは、ファイルにエクスポートし、削除した後、ファイルからインポートして戻すことが可能です。
ディクショナリ・ベースラインまたはバージョンを選択して、ファイルにエクスポートできます。エクスポートおよびインポートにはデータ・ポンプが使用されます。ダンプ・ファイルおよびログ・ファイルは、Enterprise Managerリポジトリ・データベース・サーバー・ホストに保管されます。また、OracleによってサポートされているNASデバイス上のファイル・システムなど、NFSファイル・システムに設定されているディレクトリに保管することも可能です。
ディクショナリ・ベースライン・バージョンをリポジトリからエクスポート・ファイルにエクスポートする場合、またはディクショナリ・ベースラインをリポジトリ・データベース・サーバー上のインポート・ファイルからインポートする場合、エクスポートまたはインポートするディレクトリ・オブジェクトをリポジトリ・データベースで選択し、エクスポートまたはインポート・ファイルの名前を指定します。
エクスポートまたはインポートする新しいディレクトリ・オブジェクトを作成するには、次のようにします。
CREATE ANY DIRECTORY権限またはDBAロールを持つユーザーとしてリポジトリ・データベースにログインします。
ベースラインのエクスポート先またはインポート・ダンプ・ファイルの格納場所であるリポジトリ・データベース・サーバーのファイル・システム上に、ディレクトリの別名としてディレクトリ・オブジェクトを作成します。
ディレクトリ・オブジェクトのREADおよびWRITE権限をSYSMANに付与します。
新たに作成されたディレクトリは、Enterprise Managerの管理者がディクショナリ・ベースラインのエクスポートおよびインポートを行う際に選択できるようになります。エクスポートおよびインポート操作で作成されるデータ・ポンプのログ・ファイルも、同じディレクトリに書き込まれます。
インポート中、名前、所有者およびソース・データベースに新しい値を設定できます。スーパー管理者は、インポート時に別の管理者を所有者として設定できます。
エクスポート操作では、ベースラインに関連付けられたジョブ情報はエクスポートされません。したがって、インポート時、ジョブ・ステータスは不明となります。
非スーパー管理者には、次が適用されます。
非スーパー管理者は、自分自身のベースラインをエクスポートできます。また、非スーパー管理者は、別の管理者が所有しているベースラインのバージョンを表示しバージョン内のディクショナリ・オブジェクト・リストを確認できる権限を持っている場合、そのバージョンをエクスポートできます。
インポート時、非スーパー管理者は、インポートされているベースラインの所有者となる必要があります。非スーパー管理者は、別の管理者を所有者として設定できません。インポート・ダンプ・ファイル内のベースラインが別の管理者によって所有されている場合、ログインしている非スーパー管理者が新規所有者としてインポート時に設定されます。
非スーパー管理者に付与されているベースラインの表示権限はインポート時に失われ、インポート後は、関連付けられたジョブ情報がないため再付与できません。
ディクショナリの比較により、ベースライン（またはデータベース）とベースライン（またはデータベース）間、あるいは単一のデータベースまたはベースライン内の2つのスキーマ間で、データベース・オブジェクト定義の相違が識別されます。
比較の指定は、左側と右側のソース、有効範囲および所有者により定義されます。有効範囲指定では、比較に含めるデータベース・オブジェクト定義の名前とタイプ、およびそれらのオブジェクト定義を含むスキーマを記述します。
比較により、任意のタイプのオブジェクト間で属性値の相違が識別されます。比較を使用して、複数の比較バージョンを作成できます。各バージョンには、一意のバージョン番号と比較日が割り当てられます。これらのバージョンを使用して、現在までに作成されたデータベース（スキーマ）の比較を関連付けます。
例:
比較により、アプリケーションの元のベースラインと現在のデータベースの定義間の相違を表示できます。新しい比較バージョンを作成すると、開発サイクルの開始時における元の定義と、現時点における同じ定義との間の相違を識別できます。
他の比較指定を使用して、最新のベースラインの定義と以前のベースラインの定義を比較することもできます。比較指定を使用して比較の新規バージョンを作成するたびに、その比較バージョンにより前のベースライン以降の定義の相違を識別できます。
ディクショナリの比較の定義は、左側と右側のメタデータ定義のソース、有効範囲指定、オプションのスキーマ・マップおよび比較オプションで構成されます。一度作成したら、ディクショナリの比較の定義を変更することはできません。これにより、ディクショナリの比較の各バージョンが、比較の定義の変更ではなく、比較対象のデータベースの変更を反映していることが保証されます。
ディクショナリの比較のソース
各比較には、左側のソースと右側のソースがあります。比較では、左側のソースと右側のソースのオブジェクト定義が照合されます。ソースには、データベースまたはベースライン・バージョンを指定できます。
ソースがデータベースの場合、オブジェクト定義は比較バージョンの作成時点のデータベースから直接取得されます。
ソースがベースラインの場合、オブジェクト定義は指定したベースライン・バージョンから取得されます。ベースライン・バージョンを使用すると、データベース（または別のベースライン・バージョン）を、過去のある時点で存在していたデータベースと比較できます。たとえば、ベースライン・バージョンは、アプリケーション開発サイクルの基礎となる時点や、アプリケーションの以前のリリースを表すことがあります。
ベースライン・ソースの場合、使用するバージョンを指定するための様々な方法があります。
特定のベースライン・バージョンを比較のすべてのバージョンで使用する場合、ベースライン・バージョン番号を指定します。この方法は、適切に定義されたデータベースの以前の状態（任意のリリースなど）と、その現在の状態を比較する場合に適しています。
最新のバージョンまたはその1つ前のバージョンを比較で使用することもできます。「最新」を選択すると、比較を実行する前にベースライン・バージョンを取得するよう指定できます。このオプションにより、単一の操作でベースラインを取得してそれを他のソースと比較できます。たとえば、毎晩開発データベースの現在の状態を表すベースライン・バージョンを取得し、それを前日の夜のベースラインや、開発の基礎となる時点を表す固定ベースラインと比較できます。
有効範囲の指定
ディクショナリの比較の有効範囲指定では、左側と右側のソースで比較するオブジェクトを識別します。比較の有効範囲指定の作成方法は、「ディクショナリ・ベースライン」に記載されているベースラインの有効範囲指定の作成方法と同じです。ベースラインと同様に、比較するオブジェクト・タイプとスキーマを指定するか、比較する個々のオブジェクトを指定します。
スキーマ・マップ
通常、一方のソースのスキーマ・オブジェクトは、他方のソースの同じスキーマに含まれるオブジェクトと比較されます。たとえば、左側のソースのAPPL1.T1表は、右側のソースのAPPL1.T1と比較されます。
しかし、あるスキーマのオブジェクトを、別のスキーマの対応するオブジェクトと比較したいこともあります。たとえば、DEV1とDEV2という2つのスキーマがあり、それぞれ同じオブジェクト・セットを含んでいるとします。異なるアプリケーション開発者が、DEV1とDEV2で作業しています。オプションのスキーマ・マップ機能を使用すると、DEV1のオブジェクトを、同じタイプおよび名前を持つDEV2のオブジェクトと比較できます。
スキーマ・マップにエントリを追加するには、比較の「オブジェクト」ページのマップされたオブジェクト・セクションを開きます。マップされたスキーマの1つ以上のペアを作成できます。各ペアでは、左側のスキーマと対応する右側のスキーマを指定します。
スキーマ・マップを使用すると、単一のデータベースまたはベースライン・バージョン内のオブジェクトを比較できます。前述の例では、同じデータベース内にDEV1とDEV2が存在します。左側と右側の両方のソースとしてそのデータベースを指定し、スキーマ・マップを入力してDEV1のオブジェクトとDEV2のオブジェクトを比較します。
比較オプション
オブジェクトの比較方法を指定する複数のオプションを選択できます。これらのオプションにより、重要ではない相違を無視できます。オプションには次のものがあります。
「表領域を無視」および「物理属性を無視」: これら2つのオプションでは、格納されているオブジェクトを比較する際に、それらの格納されている表領域や、記憶域関連の属性の設定を無視できます。このオプションは、異なるサイズ構成および記憶域構成を持つデータベース内のオブジェクトを比較する場合や、オブジェクトの記憶域に関連する相違を考慮しない場合に便利です。
「一致制約」の「定義別」または「名前別」: 表制約の定義をより重視する場合（主キー制約または一意制約に関連する列など）、「一致制約」の「定義別」を選択します。これにより、同じ定義を持つ制約が照合され、その名前が相違として示されます（「名前の違いを無視」を選択していない場合）。制約の名前に意味がある場合、「一致制約」の「名前別」を選択します。この選択では、同じ名前を持つ制約が照合され、その定義が相違として示されます。
「パーティション化されたオブジェクト: 上限を無視」: 異なる環境では、同じ表が異なるパーティション上限値を持つ可能性があります。このオプションを選択すると、上限値の相違を無視できます。
論理SQL比較: このオプションを選択すると、ソース・オブジェクト（パッケージ、パッケージ本体、プロシージャ、ファンクションなど）の意味のない書式の相違を無視できます。
統計の比較: このオプションを選択すると、表および索引のオプティマイザ統計を比較できます。
表の列位置を無視: 列の位置のみが異なる表を同じであるとみなす場合、このオプションを選択します。
比較バージョンの作成
比較の定義が終了したら、最初の比較バージョンを作成する時期を指定します。最初のバージョンは、即座に作成するか、後で作成できます。一定の間隔で新しい比較バージョンをスケジュールすることもできます。
比較バージョンをスケジュールする以外に、比較を選択して「すぐに繰返す」を指定することで、いつでも新しい比較バージョンを作成できます。
最初のバージョンの後に処理される比較は、通常、最初の比較よりもずっと高速に処理されます。左側または右側で変更のあったオブジェクトのみが、新規バージョンで比較されます。つまり、変更されたオブジェクトが数パーセントであれば、追加の比較バージョンに必要とされる記憶域は、最初のバージョンで使用された記憶域よりほんの少し多くなるだけです。
ディクショナリの比較バージョンには、有効範囲指定に応じて左側と右側のソースを比較した結果が記録されます。比較バージョンのオブジェクトの状態は、次の4つのうちのいずれかです。
左のみ: オブジェクトは左側のソースにのみ存在します。
右のみ: オブジェクトは右側のソースにのみ存在します。
同一: オブジェクトは左側と右側のソースに存在し、同一です。
差分あり: オブジェクトは左側と右側のソースに存在し、異なります。
ページには比較のすべてのバージョンがリストされ、バージョンごとに各状態のオブジェクトの数が表示されます。図7-6の比較バージョンのページには、各状態のオブジェクトが個別に表示されています。図7-7のように、同一ではないオブジェクトを選択して相違を表示し、左側と右側の定義のDDLを生成できます。
比較バージョンにオブジェクトの情報を記録する場合、さらに次の2つの操作を実行できます。
オブジェクトにコメントを追加できます。たとえば、コメントで2つのオブジェクトが異なる理由を記述します。
オブジェクトを無視できます。オブジェクトを無視すると、比較バージョンのオブジェクトのリストからそのオブジェクトが削除されます。相違が重要ではないと判断した場合、異なるオブジェクトを無視できます。
ディクショナリの同期化では、2つのデータベース間またはベースラインとデータベース間のデータベース・オブジェクト定義の相違が同期化されます。データベースの同期化の基本アクションは、選択されたオブジェクト定義をデータベースで作成または変更し、別のデータベースまたはベースラインのオブジェクト定義と一致させることです。
同期化は、同期化指定を使用して生成されます。同期化では、有効範囲の指定に個々のオブジェクトの名前は含まれません。指定できるのは、同期化のタイプと、包含または除外するスキーマのみです。追加で接頭辞を指定して、その接頭辞で始まる名前を持つオブジェクトのみを選択することも可能です。
ディクショナリの同期化では、サポートされる任意のタイプのオブジェクト間で属性値の相違が同期化されます。同期化指定を使用して、複数の同期化バージョンを作成できます。各バージョンには、一意のバージョン番号と同期化日が割り当てられます。これらのバージョンを使用して、現在までに作成されたデータベース（スキーマ）の同期化を関連付けます。
ソースと宛先
同期化のソースにより、宛先データベースの同期元となるオブジェクト定義（およびオプションでデータ）が提供されます。同期化のソースには、データベースまたはベースライン・バージョンを指定できます。ソースがベースライン・バージョンの場合、ベースラインではデータが取得されないため、宛先にデータを伝播することはできません。
同期化の宛先には、常にデータベースを指定する必要があります。同期化の目的は、ソースのオブジェクト定義と一致するように宛先のオブジェクト定義を作成または変更することです。
使用するソース・ベースラインのバージョンの指定オプションは、ディクショナリの比較で使用されるオプションとほぼ同じです。固定ベースライン・バージョンを指定するか、「最新」または「最新 - 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ステップで実行され、最後に同期化スクリプトが実行されます。ただし、適切なスクリプトの生成を妨げるエラーが検出された場合、プロセスはスクリプトを実行せずに終了します。
インタラクティブ同期化モードでは、ソース・オブジェクトと宛先オブジェクトの最初の比較後に処理が一時停止し、同期化スクリプトの生成後に再開します。インタラクティブ・モードでは、比較とスクリプト生成の結果を検討し、次のステップに進む前に適切な操作を実行できます。
同期化バージョンの作成
同期化の定義が終了したら、最初の同期化バージョンを作成する時期を指定します。最初のバージョンは、即座に作成するか、後で作成できます。一定の間隔で新しい同期化バージョンをスケジュールすることもできます。
選択した同期化モードに応じて、同期化は最後まで実行されるか（自動モード）、最初のオブジェクト比較の後に一時停止します（インタラクティブ・モード）。インタラクティブ・モードの場合、同期化の各後続フェーズは新規ジョブとして実行します。
インタラクティブ・モードを使用する場合、宛先データベースは、オブジェクトの最初の比較時から同期化スクリプトを実行するまで変更できません。変更すると、スクリプトに問題が発生します。たとえば、宛先に存在しない表がソースに含まれているとします。オブジェクトの比較で、ソースのみに存在する表が認識され、生成されるスクリプトにはその表を作成する文が組み込まれます。このとき、オブジェクトの比較後で、スクリプトの実行前に宛先データベースに手動でその表を作成します。表はすでに存在するため、表を作成しようとするとスクリプトは失敗します。
図7-8に、同期化のリストを示します。
同期化プロセスの詳細は、「ディクショナリの同期化バージョンの操作」を参照してください。
ディクショナリの比較を同期化の開始点として使用できます。比較を選択して、「同期化」を選択します。これにより、比較に基づく次の初期情報を含んだ新しい同期化が作成されます。
ソースと宛先（比較の左側のソースと右側のソースにそれぞれ対応）。この場合、右側のソースがベースラインである比較からは、同期化を作成できません。
有効範囲指定。比較の有効範囲指定オプションの一部は、同期化で使用できません。たとえば、ユーザー・オブジェクトやロール・オブジェクトなどの個々のスキーマ・オブジェクトは同期化できません。
比較オプション。
各同期化バージョンは、有効範囲指定により選択された宛先オブジェクトを変更し、対応するソース・オブジェクトに一致させる試行操作を表します。（「試行操作」となっているのは、様々な理由でプロセスが完了しない可能性があるためです。）この項では、ディクショナリの同期化バージョンの処理方法と、プロセスの監視および制御方法について説明します。
同期化バージョンの処理には、3つのステップが関連します。前述したとおり、（自動モードを選択して）3つのステップを1つに結合するか、（インタラクティブ・モードを選択して）各ステップを個別に実行します。どちらの場合でも、同期化バージョンを正常に処理するには、3つのステップをすべて実行する必要があります。
次の項では、3つの各ステップについて詳しく説明します。また、インタラクティブ・モードでの操作時に各ステップの後に実行できる処理について説明します。
オブジェクト比較ステップ
最初のステップでは、ソースのオブジェクトを宛先の対応するオブジェクトと比較します。有効範囲指定により選択されたオブジェクトのみが比較されます。このステップの最後の時点で、同期化バージョンにはすべてのオブジェクトが記録されています。各オブジェクトの状態は、次のいずれかです。
ソースのみ
宛先のみ
同一
差分あり
インタラクティブ・モードでは、各状態のオブジェクトを表示するか、すべてのオブジェクトを同時に表示できます。同一ではないオブジェクトの場合、オブジェクト間の相違を表示できます。この段階で、次のように各宛先オブジェクトに対する処理を予想できます。
ソースのみに存在するオブジェクトは、宛先に作成されます。
宛先のみに存在するオブジェクトは、影響を受けません。ただし、「宛先のみのスキーマ・オブジェクトを削除」オプションを選択した場合、宛先のオブジェクトは削除されます。
同一のオブジェクトは、影響を受けません。ただし、「ソースからデータをコピー」オプションを選択した場合、同一の表のデータはソースのデータで置き換えられます。
同一ではないオブジェクトは、ソース・オブジェクトと一致するように変更されます。変更は、相違に応じて、ALTER文の使用を通じて、またはオブジェクトの削除と再作成を通じて行われます。
スクリプト生成に進む前に（図7-9）、同期化からオブジェクトを除外できます。たとえば、宛先には作成しないソース専用のビューが存在する場合、ここで除外できます。
スクリプト生成ステップ
スクリプトの生成時に、同期化では、比較ステップの結果を使用して、ソースと一致するように宛先でオブジェクトを作成および変更するPL/SQLスクリプトを作成します。スクリプト生成の一環として、次のいくつかのアクティビティが実行されます。
依存性分析により、宛先データベースが各オブジェクトに適切な環境を提供していることと、オブジェクトが正しい順序で作成および変更されることが保証されます。
変更分析により、ALTER文を使用してオブジェクトを変更できるかどうか、またはオブジェクトを削除して再作成する必要があるかどうかが決定されます。
同期化バージョンの影響レポートにメッセージが配置されます。これらのメッセージには、同期化プロセスに関する情報が含まれており、状況によっては、使用可能なスクリプトを生成できない1つ以上のエラー状態がレポートされます。
同期化を実行するのに必要なDDL文が生成され、同期化バージョンに記録されます。
依存性分析により、各オブジェクトが調査され、他のオブジェクトとの関係が特定されます。これにより、他のオブジェクトが宛先に存在する（または作成される）ことが保証されます。これらの関係の例は、次のとおりです。
スキーマ・オブジェクトは、それを所有するユーザー・オブジェクトに依存します。たとえば、表DEV1.T1はユーザーDEV1に依存します。
索引は、それが存在する表に依存します。たとえば、索引DEV1.T1_IDXは表DEV1.T1に依存します。
外部キー制約が存在する表は、制約の参照先の表に依存します。
パッケージ本体などのソース・オブジェクトは、他のソース・オブジェクト、表、ビューなどに依存します。
ストアド・オブジェクトは、それが格納されている表領域に依存します（「表領域を無視」が選択されていない場合）。
依存性分析の際に確認された関係は、スクリプトの文を正しい順序で処理するために後でスクリプト生成プロセスで使用されます。
依存性分析により、宛先データベースに必須オブジェクトが存在しないことが判明する場合があります。たとえば、スキーマ・オブジェクトの所有者が、宛先データベースに存在しないことがあります。または、異なるスキーマに存在する別の表に対する外部キー制約が表に含まれることがあります。処理結果は次のようになります。
必須オブジェクトがソースに存在し、有効範囲指定で選択されている場合、同期化でそのオブジェクトが作成されます。たとえば、DEV1.T1にDEV2.T2を参照する外部キー制約があり、DEV1とDEV2の両方とも有効範囲指定に含まれる場合、同期化でDEV2.T2が作成されます。
必須オブジェクトがユーザーまたはロールで、そのオブジェクトがソースに存在する場合、自動的に同期化にそのユーザーまたはロールが追加され、宛先に作成されます。この処理は、ユーザー・オブジェクトとロール・オブジェクトが同期化の有効範囲指定に含まれていない場合でも発生します。
必須スキーマ・オブジェクトがソースに存在するが、有効範囲指定で選択されていない場合、そのオブジェクトは同期化に自動的に追加されません。かわりに、影響レポートにエラー・レベルのメッセージが配置されます。この制限により、有効範囲指定外のオブジェクトが制御なしで同期化されることが防止されます。有効範囲指定にアプリケーションまたはモジュールを構成するすべてのスキーマを含める必要があるのは、この理由からです。
ソースがベースライン・バージョンの場合、必須オブジェクトは含まれない可能性があります。たとえば、ベースラインでは、ユーザーとロールが取得されないことがあります。同期化では、ベースライン・バージョンの外部のオブジェクトは検索できないため、図7-10のように影響レポートにエラー・レベルのメッセージが配置されます。このため、同期化に使用するベースラインにユーザー、ロールおよび権限付与を含めることが重要です。
図7-10 必須スキーマ・オブジェクトが有効範囲指定で選択されていないために表示されたエラー・レベルの影響レポート・メッセージ
スクリプト生成ステップの最後に、同期化により影響レポートとスクリプトが同期化バージョンに追加されます。インタラクティブ・モードでは、スクリプトを実行する前にスクリプトと影響レポートを検討できます。
影響レポートには、スクリプトの生成中に発生した状態に関するメッセージが含まれます。メッセージには次の3つのタイプがあります。
情報メッセージでは、ユーザー側の処置は必要ありません。このメッセージは、単なる留意事項をレポートします。たとえば、スクリプト生成にユーザー・オブジェクトが自動的に含まれる場合、影響レポートに情報メッセージが追加されます。
警告メッセージは、注意が必要だが、通常は処置の必要がない状態をレポートします。たとえば、ソース・オブジェクトに対する参照を解決できるかどうか同期化で判断できない場合、影響レポートに警告メッセージが追加されます。警告メッセージにレポートされた状態によりスクリプトの実行が妨げられないかどうかを検証する必要があります。
エラー・メッセージは、修正しないとスクリプトを実行できない状態を示します。たとえば、同期化で必須依存オブジェクトの場所を特定できない場合、影響レポートにエラー・メッセージが追加されます。メッセージによっては、新しい同期化を作成する必要があります。たとえば、依存オブジェクトが同期化の有効範囲に存在しない場合や、ソースが依存オブジェクトを含まないベースラインである場合、有効範囲を拡張するか異なるソース・ベースラインを使用して新しい同期化を作成する必要があります。その他の場合は、同期化から1つ以上のオブジェクトを除外してスクリプトを再生成することで、エラー状態を解決できます。
スクリプト表示には、生成されたスクリプトの文が実行される順序どおりに含まれます。正確さに懸念がある場合は、スクリプトを調査できます。この表示により、特定のオブジェクトまたはオブジェクト・タイプに関連する文を特定できます。
図7-11 インタラクティブ・モードの「スクリプト実行を続行」ステップ（「影響レポート」タブ）
スクリプトの生成後、スクリプト生成ステップでエラーが発生していなければ、スクリプト実行に進むことができます（図7-11および図7-12）。エラーが発生した場合、影響レポートに、問題と解決策について詳しく説明した1つ以上のエラー・レベルのメッセージが含まれます。「スクリプトの再生成」を選択し、同期化からオブジェクトを除外してスクリプトを再生成することで、問題を解決できることもあります。
状況によっては、問題を修正するために同期化の新規バージョンを作成する必要があります。たとえば、ソースまたは宛先のオブジェクトの定義を変更する場合や、宛先にオブジェクトを追加する場合、新規バージョンを作成する必要があります。これにより、比較ステップで新規オブジェクトまたは変更されたオブジェクトが検出されます。この場合、古いバージョンは、スクリプト生成を続行できないため破棄されます。
スクリプト実行ステップ
スクリプトの生成に成功したら、スクリプトをいつでも実行できます。自動モードでは、スクリプトは生成が完了すると同時に実行されます。インタラクティブ・モードでは、影響レポートとスクリプトの確認後、ただちにスクリプトの実行に進みます。
スクリプトは、Enterprise Managerのジョブ・システムで実行されます。図7-13に、同期化ジョブの出力を示します。スクリプトの実行が完了したら、実行ログを表示できます。スクリプトの実行に失敗した場合、状況に応じて問題を修正し、障害が発生した時点からスクリプトの実行を再開できます。たとえば、表領域の領域不足によりスクリプトが失敗した場合、表領域のサイズを増やしてからスクリプトを再実行できます。
最初の初期化バージョンの処理後に、同期化の追加バージョンを作成できます。同期化を選択し、「再同期化」を選択します。新しい同期化バージョンを作成する場合、異なるソースまたは宛先を選択することや、有効範囲指定または同期化オプションを変更することはできません。ただし、新しい同期化バージョンの開始時に、異なるモード（自動またはインタラクティブ）を選択できます。
追加の同期化バージョンを作成すると、ソースの増分変更を宛先に伝播できます。たとえば、開発システムに加えられた最新の変更でテスト・データベースをリフレッシュできます。
最初のバージョンの後に処理される同期化は、通常、最初の同期化よりもずっと高速に処理されます。
