| Oracle® Enterprise Managerライフサイクル管理ガイド 12cリリース5 (12.1.0.5) B66837-13 |
|
 前 |
 次 |
この章では、次の各項でデータベースの変更管理ソリューションの概要について説明します。
エンタープライズ・アプリケーションのライフサイクルを管理するには、開発、ステージング、本番およびテストなどの様々な目的のためにアプリケーション・データベースのコピーを複数保持する必要があります。これらの各データベースは、それぞれのプロセスに合せる必要があります。たとえば、本番データベースの場合、適切な本番用コントロール・プロシージャに必ず従う必要があります。管理者は、非認証の変更(必要な変更の承認なしで索引が削除されるなど)を検出する手段を持っている必要があります。そのような場合、本番データベースへの変更を毎日または毎週監視することが重要になります。
ライフサイクル管理のもう1つの重要な側面は、データベース・コンプライアンス(すべてのデータベースを基準となる構成に準拠させること)です。組織の標準またはベスト・プラクティスに準拠することで、データベースの効率性、メンテナンス性および運用の容易性が保証されます。
開発データベースの場合、開発者が変更を加えますが、その変更はデータベース管理者がステージング・データベースまたはテスト・データベースに統合および伝播する必要があります。その目的は、開発環境に加えられた変更を識別し、本番データベースにすでに存在する他の変更を考慮しながら、ステージング・データベースまたはテスト・データベースに同じ変更を加えることです。
通常、ほとんどのアプリケーションは、時間の経過とともにアップグレードされます。また、ほとんどのアプリケーションは、要件に合うようにビジネス・ユーザーによってカスタマイズされます。アプリケーションのカスタマイズは、通常、アプリケーション・ベンダーにより提供されるデータベース・オブジェクトまたはPL/SQLモジュールに依存します。アップグレード・スクリプトはアプリケーション・ベンダーから提供されるため、顧客はアップグレード手順が独自のカスタマイズ内容にどの程度影響するかについてほとんどわかりません。顧客は、アップグレード・データベースをテストする場合、アップグレードの前後にアプリケーション・スキーマのベースラインを取得できます。前後のベースラインを比較することで、アプリケーションにより変更されたモジュールがわかります。これにより、アプリケーションをアップグレードした結果としてカスタマイズ内容が受ける影響の程度をより正確に把握できます。
開発者およびデータベース管理者がデータベース環境の変更を管理できる変更管理の主な機能は次のとおりです。
データベースのバージョン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として接続してデータの比較を実行することはできません。
スキーマ・ベースラインには、特定の時点で取得された一連のデータベース定義が含まれます。ベースラインは、Cloud ControlリポジトリにXMLドキュメントとして格納されます。
各ベースラインには、一意の名前を割り当てる必要があります。ベースラインは、そのベースラインで取得されるデータベース・オブジェクトの有効範囲と一致するように命名すると便利です(Financial 11.5.10、HR Benefits、PO Check Printなど)。1つのベースラインは、異なる時点で取得された一連のバージョンを保持できます。ベースラインの複数のバージョンを作成すると、一連のデータベース・オブジェクトの定義に対する変更を時間経過に合せて追跡できます。同じベースラインの2つのバージョンを比較することで、そのバージョン間で発生した変更を確認できます。
ベースラインの作成時、対応するベースラインの有効範囲指定も作成します。有効範囲指定には、データベース・オブジェクトの名前とタイプ、およびその取得元となるスキーマが示されます。ベースライン定義を作成したら、Cloud Controlジョブを発行してベースラインの最初のバージョンを取得できます。後で、あるいは定期的に同じベースラインの追加バージョンを取得できます。各ベースラインのバージョンには、バージョンの取得時に存在するメタデータ定義が記録されます。
変更管理スキーマ・ベースラインは、削除するまでシステムに保持されます。ベースラインを削除すると、システムから永久に削除されます。削除操作は元に戻すことができません。ただし、ベースラインが今後必要になる可能性がある場合、まずベースラインをダンプ・ファイル(リポジトリ・データベース・サーバー・ホストに作成)にエクスポートし、それからベースラインを削除します。ベースラインがその後必要になったら、ファイルからインポートして戻すことができます。
有効範囲指定では、ベースラインに取得されるデータベース・オブジェクトが識別されます。(有効範囲指定では、スキーマの比較と同期化で処理されるオブジェクトも識別されます。)ベースラインの有効範囲を指定したら、有効範囲指定を変更できません。この制限によって、ベースラインのすべてのバージョンが同じルールのセットを使用して取得されることが保証されます。つまり、バージョン間の相違は、データベースに加えられた変更によるもので、有効範囲指定の変更によるものではないということです。異なる有効範囲指定を使用してスキーマ・オブジェクトを取得するには、ベースラインを新たに作成する必要があります。
ベースラインの有効範囲指定には、次の3つの形式があります。
取得するスキーマおよびオブジェクト・タイプを指定できます。たとえば、スキーマAPPL1およびAPPL2のすべての表、索引およびビューを取得できます。この形式の有効範囲指定は、アプリケーション・オブジェクトを含む適切に定義されたスキーマのセットが存在する場合に適切です。スキーマ・オブジェクトに加え、非スキーマ・オブジェクト(ユーザー、ロール、表領域など)や、ユーザーおよびロールに対する権限付与も取得できます。
除外するスキーマと、オブジェクト・タイプを指定できます。この形式の有効範囲指定では、指定したスキーマ以外のすべてのスキーマに含まれるオブジェクトが取得されます。たとえば、SYSTEMおよびSYS以外のスキーマのすべてのオブジェクト・タイプを取得できます。この形式の有効範囲指定は、Oracle付属のスキーマに含まれるオブジェクトを除き、すべてのデータベース・オブジェクトを取得する場合に適切です。有効範囲指定の最初の形式と同様に、非スキーマ・オブジェクトと権限付与も取得できます。
最後の形式として、個々のオブジェクトのタイプ、スキーマおよび名前を指定することで、それらのスキーマ・オブジェクトを個別に取得できます。この形式の有効範囲指定は、1つ以上のスキーマ内に含まれるすべてのオブジェクトではなく、一部の特定のオブジェクトを取得する場合に適切です。個々のスキーマ・オブジェクトを取得する一方で、非スキーマ・オブジェクトと権限付与も取得できます。
有効範囲指定にユーザーやロールなどの非スキーマ・オブジェクト・タイプを含めると、そのタイプのオブジェクトがすべて取得されます。個々の非スキーマ・オブジェクトを取得する方法はありません。図47-1に、有効範囲を指定する「スキーマ・ベースライン: オブジェクト」ページを示します。
ベースラインを定義する最後の手順として、ベースラインの最初のバージョンを取得する時期を指定します。最初のバージョンは、即座に取得するか、後で(たとえば、データベースがアクティブな開発作業に使用されていないときに)取得できます。また、追加の手動操作を行わずに一定の間隔で追加のベースライン・バージョンを取得するように指定することもできます。
ベースラインを選択して「すぐに再取得」を指定することで、任意の時点の新しいベースライン・バージョンを取得することも可能です。
最初のバージョンの後に処理されるベースラインは、通常、最初のバージョンよりもずっと高速に処理されます。変更のあったオブジェクトのみが新規バージョンに取得されます。つまり、変更されたオブジェクトが数パーセントであれば、追加のベースライン・バージョンに必要とされる記憶域は、最初のバージョンで使用された記憶域よりほんの少し多くなるだけです。図47-2に、スキーマ・ベースラインの最初のバージョンを示します。
単一のスキーマ・ベースライン・バージョン内で、個々のオブジェクト属性の調査、個々のオブジェクトに対応するDDLの生成、およびベースライン・バージョンのすべてのオブジェクトに対応するDDLの生成を行うことができます。ベースライン・バージョンに取得されたオブジェクト定義は、特定の時点でのオブジェクトの状態を表すことを意図しているため、変更することはできません。
ベースライン・オブジェクトを表示すると、オブジェクトの属性がグラフィカルに表示されます。
ベースライン・オブジェクトを選択して「DDLの生成」を指定すると、オブジェクトの作成に使用されるDDLが表示されます。図47-3に、ベースライン・オブジェクトに対して生成されたDDLを示します。
ベースライン・バージョンを選択して「DDLの生成」を指定すると、ベースライン・バージョンのすべてのオブジェクトに対応するDDLが生成されます。正しい順序でオブジェクトを作成する作業が行われますが(索引の前に表を作成するなど)、生成されたDDLをデータベースで実行しても、ベースライン・バージョンのオブジェクトを作成できるとはかぎりません。たとえば、スキーマAPPL1に含まれるすべてのスキーマ・オブジェクトを取得し、ユーザーAPPL1を含まないデータベースでベースライン・バージョンのDDLを実行しようとしても、生成されたDDLは実行に失敗します。
ベースライン・バージョンは、比較や同期化などの他のDatabase Lifecycle Management Packアプリケーションでも使用されます。ベースライン・バージョンは、データベース(または他のベースライン・バージョン)と比較できます。また、ベースライン・バージョンを同期化のオブジェクト定義のソースとして使用し、別のデータベースにその定義を再作成できます。
ベースラインに複数のバージョンが含まれる場合、バージョン間の相違を調査できます。
あるバージョンとその先行バージョンの間における変更点を確認するには、バージョンを選択して「前のバージョン以降の変更を表示」を指定します。画面に、前のバージョン以降に変更されたオブジェクト(図47-4)、追加または削除されたオブジェクト、および変更されていないオブジェクトが表示されます。変更されたオブジェクトを選択すると、そのオブジェクトの2つのバージョン間の相違が表示されます。
ベースラインのすべてのバージョンにわたり変更された個々のオブジェクトを確認するには、オブジェクトを選択して「バージョン履歴の表示」を指定します。画面に、オブジェクトが最初に取得、変更または削除されたときのバージョンが表示されます(図47-5を参照)。この表示で、任意の2つのベースライン・バージョンに含まれるオブジェクトの定義を比較できます。
ベースラインのエクスポート/インポート機能を使用して次のことを行えます。
異なるリポジトリを持つ2つのCloud Controlサイト間でのベースラインの転送。
オフラインでのベースラインの保管。ベースラインは、ファイルにエクスポートし、削除した後、ファイルからインポートして戻すことが可能です。
スキーマ・ベースラインまたはバージョンを選択して、ファイルにエクスポートできます。エクスポートおよびインポートにはデータ・ポンプが使用されます。ダンプ・ファイルおよびログ・ファイルは、Cloud Controlリポジトリ・データベース・サーバー・ホストに保管されます。また、OracleによってサポートされているNASデバイス上のファイル・システムなど、NFSファイル・システムに設定されているディレクトリに保管することも可能です。
スキーマ・ベースライン・バージョンをリポジトリからエクスポート・ファイルにエクスポートする場合、またはスキーマ・ベースラインをリポジトリ・データベース・サーバー上のインポート・ファイルからインポートする場合、エクスポートまたはインポートするディレクトリ・オブジェクトをリポジトリ・データベースで選択し、エクスポートまたはインポート・ファイルの名前を指定します。
エクスポートまたはインポートする新しいディレクトリ・オブジェクトを作成するには、次のようにします。
CREATE ANY DIRECTORY権限またはDBAロールを持つユーザーとしてリポジトリ・データベースにログインします。
ベースラインのエクスポート先またはインポート・ダンプ・ファイルの格納場所であるリポジトリ・データベース・サーバーのファイル・システム上に、ディレクトリの別名としてディレクトリ・オブジェクトを作成します。
ディレクトリ・オブジェクトのREADおよびWRITE権限をSYSMANに付与します。
新たに作成されたディレクトリは、Cloud Controlの管理者がスキーマ・ベースラインのエクスポートおよびインポートを行う際に選択できるようになります。エクスポートおよびインポート操作で作成されるデータ・ポンプのログ・ファイルも、同じディレクトリに書き込まれます。
インポート中、名前、所有者およびソース・データベースに新しい値を設定できます。スーパー管理者は、インポート時に別の管理者を所有者として設定できます。
エクスポート操作では、ベースラインに関連付けられたジョブ情報はエクスポートされません。したがって、インポート時、ジョブ・ステータスは不明となります。
非スーパー管理者には、次が適用されます。
非スーパー管理者は、自分自身のベースラインをエクスポートできます。また、非スーパー管理者は、別の管理者が所有しているベースラインのバージョンを表示しバージョン内のスキーマ・オブジェクト・リストを確認できる権限を持っている場合、そのバージョンをエクスポートできます。
インポート時、非スーパー管理者は、インポートされているベースラインの所有者となる必要があります。非スーパー管理者は、別の管理者を所有者として設定できません。インポート・ダンプ・ファイル内のベースラインが別の管理者によって所有されている場合、ログインしている非スーパー管理者が新規所有者としてインポート時に設定されます。
非スーパー管理者に付与されているベースラインの表示権限はインポート時に失われ、インポート後は、関連付けられたジョブ情報がないため再付与できません。
スキーマの比較により、ベースライン(またはデータベース)とベースライン(またはデータベース)間、あるいは単一のデータベースまたはベースライン内の2つのスキーマ間で、データベース・オブジェクト定義の相違が識別されます。
比較の指定は、左側と右側のソース、有効範囲および所有者により定義されます。有効範囲指定では、比較に含めるデータベース・オブジェクト定義の名前とタイプ、およびそれらのオブジェクト定義を含むスキーマを記述します。
比較により、任意のタイプのオブジェクト間で属性値の相違が識別されます。比較を使用して、複数の比較バージョンを作成できます。各バージョンには、一意のバージョン番号と比較日が割り当てられます。これらのバージョンを使用して、現在までに作成されたデータベース(スキーマ)の比較を関連付けます。
比較により、アプリケーションの元のベースラインと現在のデータベースの定義間の相違を表示できます。新しい比較バージョンを作成すると、開発サイクルの開始時における元の定義と、現時点における同じ定義との間の相違を識別できます。
他の比較指定を使用して、最新のベースラインの定義と以前のベースラインの定義を比較することもできます。比較指定を使用して比較の新規バージョンを作成するたびに、その比較バージョンにより前のベースライン以降の定義の相違を識別できます。
スキーマの比較の定義は、左側と右側のメタデータ定義のソース、有効範囲指定、オプションのスキーマ・マップおよび比較オプションで構成されます。一度作成したら、スキーマの比較の定義を変更することはできません。これにより、スキーマの比較の各バージョンが、比較の定義の変更ではなく、比較対象のデータベースの変更を反映していることが保証されます。
スキーマの比較のソース
各比較には、左側のソースと右側のソースがあります。比較では、左側のソースと右側のソースのオブジェクト定義が照合されます。ソースには、データベースまたはベースライン・バージョンを指定できます。
ソースがデータベースの場合、オブジェクト定義は比較バージョンの作成時点のデータベースから直接取得されます。
ソースがベースラインの場合、オブジェクト定義は指定したベースライン・バージョンから取得されます。ベースライン・バージョンを使用すると、データベース(または別のベースライン・バージョン)を、過去のある時点で存在していたデータベースと比較できます。たとえば、ベースライン・バージョンは、アプリケーション開発サイクルの基礎となる時点や、アプリケーションの以前のリリースを表すことがあります。
ベースライン・ソースの場合、使用するバージョンを指定するための様々な方法があります。
特定のベースライン・バージョンを比較のすべてのバージョンで使用する場合、ベースライン・バージョン番号を指定します。この方法は、適切に定義されたデータベースの以前の状態(任意のリリースなど)と、その現在の状態を比較する場合に適しています。
最新のバージョンまたはその1つ前のバージョンを比較で使用することもできます。「最新」を選択すると、比較を実行する前にベースライン・バージョンを取得するよう指定できます。このオプションにより、単一の操作でベースラインを取得してそれを他のソースと比較できます。たとえば、毎晩開発データベースの現在の状態を表すベースライン・バージョンを取得し、それを前日の夜のベースラインや、開発の基礎となる時点を表す固定ベースラインと比較できます。
スキーマの比較の有効範囲指定では、左側と右側のソースで比較するオブジェクトを識別します。比較の有効範囲指定の作成方法は、「スキーマ・ベースライン」に記載されているベースラインの有効範囲指定の作成方法と同じです。ベースラインと同様に、比較するオブジェクト・タイプとスキーマを指定するか、比較する個々のオブジェクトを指定します。
通常、一方のソースのスキーマ・オブジェクトは、他方のソースの同じスキーマに含まれるオブジェクトと比較されます。たとえば、左側のソースのAPPL1.T1表は、右側のソースのAPPL1.T1と比較されます。
しかし、あるスキーマのオブジェクトを、別のスキーマの対応するオブジェクトと比較したいこともあります。たとえば、DEV1とDEV2という2つのスキーマがあり、それぞれ同じオブジェクト・セットを含んでいるとします。異なるアプリケーション開発者が、DEV1とDEV2で作業しています。オプションのスキーマ・マップ機能を使用すると、DEV1のオブジェクトを、同じタイプおよび名前を持つDEV2のオブジェクトと比較できます。
スキーマ・マップにエントリを追加するには、比較の「オブジェクト」ページのマップされたオブジェクト・セクションを開きます。マップされたスキーマの1つ以上のペアを作成できます。各ペアでは、左側のスキーマと対応する右側のスキーマを指定します。
スキーマ・マップを使用すると、単一のデータベースまたはベースライン・バージョン内のオブジェクトを比較できます。前述の例では、同じデータベース内にDEV1とDEV2が存在します。左側と右側の両方のソースとしてそのデータベースを指定し、スキーマ・マップを入力してDEV1のオブジェクトとDEV2のオブジェクトを比較します。
オブジェクトの比較方法を指定する複数のオプションを選択できます。これらのオプションにより、重要ではない相違を無視できます。オプションには次のものがあります。
「表領域を無視」および「物理属性を無視」 - これら2つのオプションでは、格納されているオブジェクトを比較する際に、それらの格納されている表領域や、記憶域関連の属性の設定を無視できます。このオプションは、異なるサイズ構成および記憶域構成を持つデータベース内のオブジェクトを比較する場合や、オブジェクトの記憶域に関連する相違を考慮しない場合に便利です。
「一致制約」の「定義別」または「名前別」 - 表制約の定義をより重視する場合(主キー制約または一意制約に関連する列など)、「一致制約」の「定義別」を選択します。これにより、同じ定義を持つ制約が照合され、その名前が相違として示されます(「名前の違いを無視」を選択していない場合)。制約の名前に意味がある場合、「一致制約」の「名前別」を選択します。この選択では、同じ名前を持つ制約が照合され、その定義が相違として示されます。
「パーティション化されたオブジェクト: パーティション化を無視」 - このオプションを選択すると、表および索引のパーティション化を無視します。
「パーティション化されたオブジェクト: 上限を無視」 - 異なる環境では、同じ表が異なるパーティション上限値を持つ可能性があります。このオプションを選択すると、上限値の相違を無視できます。
「論理SQL比較」 - このオプションを選択すると、ソース・オブジェクト(パッケージ、パッケージ本体、プロシージャ、ファンクションなど)の意味のない書式の相違やコメント内の空白の相違を無視できます。
「統計の比較」 - このオプションを選択すると、表および索引のオプティマイザ統計を比較できます。
「表の列位置を無視」 - 列の位置のみが異なる表を同じであるとみなす場合、このオプションを選択します。
比較バージョンの作成
比較の定義が終了したら、最初の比較バージョンを作成する時期を指定します。最初のバージョンは、即座に作成するか、後で作成できます。一定の間隔で新しい比較バージョンをスケジュールすることもできます。
比較バージョンをスケジュールする以外に、比較を選択して「すぐに繰返す」を指定することで、いつでも新しい比較バージョンを作成できます。
最初のバージョンの後に処理される比較は、通常、最初の比較よりもずっと高速に処理されます。左側または右側で変更のあったオブジェクトのみが、新規バージョンで比較されます。つまり、変更されたオブジェクトが数パーセントであれば、追加の比較バージョンに必要とされる記憶域は、最初のバージョンで使用された記憶域よりほんの少し多くなるだけです。
スキーマの比較バージョンには、有効範囲指定に応じて左側と右側のソースを比較した結果が記録されます。比較バージョンのオブジェクトの状態は、次の4つのうちのいずれかです。
左のみ - オブジェクトは左側のソースにのみ存在します。
右のみ - オブジェクトは右側のソースにのみ存在します。
同一 - オブジェクトは左側と右側のソースに存在し、同一です。
差分あり - オブジェクトは左側と右側のソースに存在し、異なります。
ページには比較のすべてのバージョンがリストされ、バージョンごとに各状態のオブジェクトの数が表示されます。図47-6の比較バージョンのページには、各状態のオブジェクトが個別に表示されています。図47-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ステップで実行され、最後に同期化スクリプトが実行されます。ただし、適切なスクリプトの生成を妨げるエラーが検出された場合、プロセスはスクリプトを実行せずに終了します。
インタラクティブ同期化モードでは、ソース・オブジェクトと宛先オブジェクトの最初の比較後に処理が一時停止し、同期化スクリプトの生成後に再開します。インタラクティブ・モードでは、比較とスクリプト生成の結果を検討し、次のステップに進む前に適切な操作を実行できます。
同期化バージョンの作成
同期化の定義が終了したら、最初の同期化バージョンを作成する時期を指定します。最初のバージョンは、即座に作成するか、後で作成できます。一定の間隔で新しい同期化バージョンをスケジュールすることもできます。
選択した同期化モードに応じて、同期化は最後まで実行されるか(自動モード)、最初のオブジェクト比較の後に一時停止します(インタラクティブ・モード)。インタラクティブ・モードの場合、同期化の各後続フェーズは新規ジョブとして実行します。
インタラクティブ・モードを使用する場合、宛先データベースは、オブジェクトの最初の比較時から同期化スクリプトを実行するまで変更できません。変更すると、スクリプトに問題が発生します。たとえば、宛先に存在しない表がソースに含まれているとします。オブジェクトの比較で、ソースのみに存在する表が認識され、生成されるスクリプトにはその表を作成する文が組み込まれます。このとき、オブジェクトの比較後で、スクリプトの実行前に宛先データベースに手動でその表を作成します。表はすでに存在するため、表を作成しようとするとスクリプトは失敗します。
図47-8に、同期化のリストを示します。
同期化プロセスの詳細は、「スキーマの比較バージョンの操作について」を参照してください。
スキーマの比較を同期化の開始点として使用できます。比較を選択して、「同期化」を選択します。これにより、比較に基づく次の初期情報を含んだ新しい同期化が作成されます。
ソースと宛先(比較の左側のソースと右側のソースにそれぞれ対応)。この場合、右側のソースがベースラインである比較からは、同期化を作成できません。
有効範囲指定。比較の有効範囲指定オプションの一部は、同期化で使用できません。たとえば、ユーザー・オブジェクトやロール・オブジェクトなどの個々のスキーマ・オブジェクトは同期化できません。
比較オプション。
各同期化バージョンは、対応するソース・オブジェクトに一致するように、有効範囲指定で選択された宛先オブジェクトを変更しようとする試行のことです。(「試行」であるのは、様々な理由からプロセスが完了しない場合があるためです。)この項では、スキーマの同期化バージョンの処理のされ方、およびプロセスの監視と制御の方法について説明します。
同期化バージョンの処理には、3つのステップが関連します。前述したとおり、(自動モードを選択して)3つのステップを1つに結合するか、(インタラクティブ・モードを選択して)各ステップを個別に実行します。どちらの場合でも、同期化バージョンを正常に処理するには、3つのステップをすべて実行する必要があります。
次の項では、3つの各ステップについて詳しく説明します。また、インタラクティブ・モードでの操作時に各ステップの後に実行できる処理について説明します。
オブジェクト比較ステップ
最初のステップでは、ソースのオブジェクトを宛先の対応するオブジェクトと比較します。有効範囲指定により選択されたオブジェクトのみが比較されます。このステップの最後の時点で、同期化バージョンにはすべてのオブジェクトが記録されています。各オブジェクトの状態は、次のいずれかです。
ソースのみ
宛先のみ
同一
差分あり
インタラクティブ・モードでは、各状態のオブジェクトを表示するか、すべてのオブジェクトを同時に表示できます。同一ではないオブジェクトの場合、オブジェクト間の相違を表示できます。この段階で、次のように各宛先オブジェクトに対する処理を予想できます。
ソースのみに存在するオブジェクトは、宛先に作成されます。
宛先のみに存在するオブジェクトは、影響を受けません。ただし、「宛先のみのスキーマ・オブジェクトを削除」オプションを選択した場合、宛先のオブジェクトは削除されます。
同一のオブジェクトは、影響を受けません。ただし、「ソースからデータをコピー」オプションを選択した場合、同一の表のデータはソースのデータで置き換えられます。
同一ではないオブジェクトは、ソース・オブジェクトと一致するように変更されます。変更は、相違に応じて、ALTER文の使用を通じて、またはオブジェクトの削除と再作成を通じて行われます。
スクリプト生成に進む前に(図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のように影響レポートにエラー・レベルのメッセージが配置されます。このため、同期化に使用するベースラインにユーザー、ロールおよび権限付与を含めることが重要です。
スクリプト生成ステップの最後に、同期化により影響レポートとスクリプトが同期化バージョンに追加されます。インタラクティブ・モードでは、スクリプトを実行する前にスクリプトと影響レポートを検討できます。
影響レポートには、スクリプトの生成中に発生した状態に関するメッセージが含まれます。メッセージには次の3つのタイプがあります。
情報メッセージでは、ユーザー側の処置は必要ありません。このメッセージは、単なる留意事項をレポートします。たとえば、スクリプト生成にユーザー・オブジェクトが自動的に含まれる場合、影響レポートに情報メッセージが追加されます。
警告メッセージは、注意が必要だが、通常は処置の必要がない状態をレポートします。たとえば、ソース・オブジェクト内の参照を解決できるかどうか同期化で判断できない場合、影響レポートに警告メッセージが追加されます。警告メッセージにレポートされた状態によりスクリプトの実行が妨げられないかどうかを検証する必要があります。
エラー・メッセージは、修正しないとスクリプトを実行できない状態を示します。たとえば、同期化で必須依存オブジェクトの場所を特定できない場合、影響レポートにエラー・メッセージが追加されます。メッセージによっては、新しい同期化を作成する必要があります。たとえば、依存オブジェクトが同期化の有効範囲に存在しない場合や、ソースが依存オブジェクトを含まないベースラインである場合、有効範囲を拡張するか異なるソース・ベースラインを使用して新しい同期化を作成する必要があります。その他の場合は、同期化から1つ以上のオブジェクトを除外してスクリプトを再生成することで、エラー状態を解決できます。
スクリプト表示には、生成されたスクリプトの文が実行される順序どおりに含まれます。正確さに懸念がある場合は、スクリプトを調査できます。この表示により、特定のオブジェクトまたはオブジェクト・タイプに関連する文を特定できます。
スクリプトの生成後、スクリプト生成ステップでエラーが発生していなければ、スクリプト実行に進むことができます(図47-11および図47-12)。エラーが発生した場合、影響レポートに、問題と解決策について詳しく説明した1つ以上のエラー・レベルのメッセージが含まれます。「スクリプトの再生成」を選択し、同期化からオブジェクトを除外してスクリプトを再生成することで、問題を解決できることもあります。
状況によっては、問題を修正するために同期化の新規バージョンを作成する必要があります。たとえば、ソースまたは宛先のオブジェクトの定義を変更する場合や、宛先にオブジェクトを追加する場合、新規バージョンを作成する必要があります。これにより、比較ステップで新規オブジェクトまたは変更されたオブジェクトが検出されます。この場合、古いバージョンは、スクリプト生成を続行できないため破棄されます。
スクリプト実行ステップ
スクリプトの生成に成功したら、スクリプトをいつでも実行できます。自動モードでは、スクリプトは生成が完了すると同時に実行されます。インタラクティブ・モードでは、影響レポートとスクリプトの確認後、ただちにスクリプトの実行に進みます。
スクリプトは、Cloud Controlのジョブ・システムで実行されます。図47-13に、同期化ジョブの出力を示します。スクリプトの実行が完了したら、実行ログを表示できます。スクリプトの実行に失敗した場合、状況に応じて問題を修正し、障害が発生した時点からスクリプトの実行を再開できます。たとえば、表領域の領域不足によりスクリプトが失敗した場合、表領域のサイズを増やしてからスクリプトを再実行できます。
最初の初期化バージョンの処理後に、同期化の追加バージョンを作成できます。同期化を選択し、「再同期化」を選択します。新しい同期化バージョンを作成する場合、異なるソースまたは宛先を選択することや、有効範囲指定または同期化オプションを変更することはできません。ただし、新しい同期化バージョンの開始時に、異なるモード(自動またはインタラクティブ)を選択できます。
追加の同期化バージョンを作成すると、ソースの増分変更を宛先に伝播できます。たとえば、開発システムに加えられた最新の変更でテスト・データベースをリフレッシュできます。
最初のバージョンの後に処理される同期化は、通常、最初の同期化よりもずっと高速に処理されます。
変更計画は、Cloud Control Database Lifecycle Management Packの新しい機能です。変更計画は、ユーザーがメタデータ変更を選択およびパッケージングして複数のデータベースにデプロイできるようにすることで、既存の変更管理コンポーネントの機能を補完し、拡張します。変更計画では、スキーマの同期化など、既存のDatabase Lifecycle Management Packツールでは十分にサポートされていないデータベース・アプリケーション開発方法がサポートされます。
変更計画は、多様な開発方法をサポートできる柔軟性を備えているだけでなく、以前はカスタム・スクリプトを使用して実行していた多数のデータベース管理タスクを自動化できる強力さも備えています。次のようなタスクがあります。
プロジェクト固有の開発の変更を、共有開発データベースから統合、テスト、本番のステージングなどの1つ以上の宛先データベースにデプロイします。
スタンドアロンのプロジェクト開発データベースからの開発の変更を、複数の開発データベースから変更を収集する1つの統合データベースにデプロイします。
複数の開発データベースにある共通モジュールを中央の統合データベースからアップグレードします。
変更計画は、Database Lifecycle Management Packの他のツールと緊密に統合されています。具体的には次のとおりです。
オブジェクトを作成する変更計画の変更リクエストは、変更管理スキーマ・ベースラインからオブジェクト定義を取得できます。
オブジェクトを変更する変更リクエストは、変更管理のスキーマの比較でオブジェクトの内容を使用して、変更を指定できます。
変更計画は、より細やかな変更の制御と変更専用の変更リクエストを可能にし、変更管理のスキーマの同期を補完します。
変更計画を使用してオブジェクト定義を作成または変更する最初のフェーズは、変更内容を計画し、定義することです。たとえば、1つ以上のデータベース内の既存のオブジェクト定義を1つ以上変更します。あるいは、あるスキーマまたはデータベースで、別のスキーマまたはデータベースから1つ以上のオブジェクト定義を再生成します。
図47-14に、変更計画の各ステップを示します。変更計画は、変更リクエストの名前付きコンテナです。宛先データベースのオブジェクト定義を再生成または変更する変更リクエストを定義できます。宛先データベースは、変更計画の変更リクエストの適用先のデータベースです。変更の計画および定義ができたら、変更の影響を評価します。
特定のデータベースでの変更リクエストの影響を評価するには、変更計画とその宛先データベースに対するスクリプトと影響レポートを生成します。影響レポートには、スクリプトが宛先データベースで実行された場合に行われる変更が示されます。宛先データベースで適用できない変更リクエストも示されます。
宛先データベースで変更計画の変更リクエストを実装するには、宛先データベースでスクリプトを実行します。
この項では、変更計画を作成する別の方法について説明します。
次の方法で変更計画を作成できます。
この項では、スキーマの比較から変更計画を作成する方法について説明します。
変更計画の作成の前提条件
前提条件は次のとおりです。
アプリケーション開発者(AD)が次の権限を持つCloud Controlユーザーであることを確認します。
開発データベースおよび本番のステージング・データベース・ターゲットに対する「ターゲットの接続」権限または「任意のターゲットの接続」権限
開発データベースのDBA権限
ジョブ・システムの作成権限(リソース権限)
新しい名前付き資格証明の作成(リソース権限)
変更計画に対する「リソースの編集」権限
任意の場所でのコマンドの実行(ターゲット権限)
EM_ALL_OPERATOR権限
データベース管理者(DBA)が次の権限を持つCloud Controlユーザーであることを確認します。
開発データベースおよび本番のステージング・データベース・ターゲットに対する「ターゲットの接続」権限または「任意のターゲットの接続」権限
開発データベースのDBA権限
ジョブ・システムの作成権限(リソース権限)
新しい名前付き資格証明の作成(リソース権限)
変更計画の管理(リソース権限)
任意の場所でのコマンドの実行(ターゲット権限)
EM_ALL_OPERATOR権限
開発作業の開始時点では、開発データベースと宛先データベースが同一であることをお薦めします。たとえば、両方のデータベースを現在の製品バージョンにするか、両方のデータベースを共通の仮開発バージョンに更新します。
アプリケーション開発者が開発データベースに変更を加えている場合があります。変更計画の作成後、アプリケーション開発者はSQL Developerなどの外部クライアントを使用して、変更計画内の変更アイテムを作成および更新できます。詳細は、「外部クライアントを使用したCloud Controlでの変更計画の作成およびアクセス」を参照してください。
変更計画の作成
変更計画を作成するには、次の手順を実行します。
データベース管理者(DBA)としてCloud Controlにログインします。
アプリケーション・オブジェクトを含むスキーマを識別します。
メタデータ・ベースライン・ウィザードを使用して、該当するスキーマを含むベースラインを定義します。最初のバージョンのベースラインを取得するジョブをスケジュールします。
ベースラインを保存します。
スキーマの比較ウィザードを使用して、ベースライン・バージョンと開発データベース間の比較を定義します。
最初のバージョンの比較を作成するジョブをスケジュールし、比較を保存します。
スキーマ変更計画ページで、「作成」をクリックします。
変更計画の名前および説明を指定し、「OK」をクリックして変更計画を保存します。
変更アイテム・ページで、比較から作成をクリックします。
「スキーマ比較からの変更項目の作成」ページで、以前に作成した比較バージョンを選択し、「比較の割当て」で開発データベースを「変更後」側に、本番のステージング・データベースを「変更前」側に指定して、「OK」をクリックします。
スキーマ比較からの変更アイテムの作成: 差分の選択ページで、次を選択します。
スキーマ比較のすべての差分: 比較のすべての差分を変更計画に追加する場合に選択します。
スキーマ比較の特定の差分: 変更計画に追加する比較の差分を選択する場合に選択します。差分を選択します。
「終了」をクリックします。
宛先データベースに変更計画を適用するリクエストを発行します。
変更計画の適用
変更計画を適用するには、次の手順を実行します。
データベース管理者(DBA)としてCloud Controlにログインします。
DBAロールで、変更計画を検証して、指定されたデータベースへの適用に適しているかどうかを評価します。必要に応じて、個々の変更リクエストを削除します。
スキーマ変更計画ページで、変更計画から同期を作成をクリックします。
スキーマの同期ウィザードで、以前に作成した変更計画インスタンスを参照して詳細を指定します。スキーマの同期ウィザードの使用方法の詳細は、本番のステージングとの同期化を参照してください。デフォルトでは、変更から作成された同期はインタラクティブ・モードで機能します。
スクリプト生成をスケジュールします。
影響レポートをチェックして、スクリプト実行をスケジュールします。
完了したスクリプト実行ジョブにエラーがないかどうかをチェックします。変更計画ジョブが失敗した場合は、次の手順を実行します。
影響レポートで警告されたエラーが失敗の原因である場合、推奨されたユーザー処理を実行します。
失敗の原因がソースまたは宛先データベースの状態にあり、それが手動で修正可能な場合は、問題を修正してから再び操作を実行します。
スクリプトの実行フェーズで失敗した場合、ジョブ詳細でスクリプトの出力を確認します。不足している権限の付与などの処理によって問題を解決できる場合は、問題をデータベースで手動で修正し、「スクリプト実行の再試行」をクリックします。
エラーを修正して、変更計画作成ジョブを再び発行します。
Cloud Controlでは、SQL Developerなどの外部クライアントを使用した変更計画の作成およびアクセスがサポートされています。これらのアプリケーションを使用してCloud Controlリポジトリに接続し、変更計画を作成して、リポジトリ内で変更アイテムの追加や更新を行うことができます。
クライアント・ユーザーのタイプは次の2つです。
すべての変更計画の作成およびアクセスが可能なユーザー
特定の変更計画のアクセス(表示、場合によっては編集)が可能なユーザー
手順は次のとおりです。
信頼できるクライアントによるアクセスが可能になるようリポジトリ・データベース・リスナーを構成します。リポジトリ・データベースは、信頼できないクライアントのログインからはアクセスできないようにすることをお薦めします。リスナーの構成の詳細は、『Oracle® Database Net Services管理者ガイド』を参照してください。
外部クライアントが使用するためのCloud Control管理者を設定します。
次の項では、計画の変更、およびCloud Controlと外部クライアントからのアクセス用の管理者の設定方法を説明します。
変更計画用のCloud Control管理者の設定
次の手順に従います。
スーパー・ユーザーとしてCloud Controlにログインします。
「設定」メニューから「セキュリティ」をクリックし、「管理者」を選択します。
管理者ページで、「作成」をクリックします。
管理者の作成: プロパティ・ページで、ユーザーの「名前」と「パスワード」を指定します。これにより、指定した名前とパスワードのデータベース・ユーザー、およびCloud Control管理者が作成されます。「次へ」をクリックします。
管理者の作成: ロール・ページで、「次へ」をクリックします。
管理者の作成: ターゲット権限ページで、「次へ」をクリックします。
管理者の作成: リソース権限ページで「変更計画セキュリティ・クラス」を選択し、「権限付与の管理」アイコンをクリックします。
管理者の作成: 権限の管理ページで、次のステップを実行します。
すべての変更計画に対してすべてのアクセス権を持つ管理者を作成する場合は、「リソース・タイプ権限」セクションで「変更計画の管理」を選択します。
1つ以上の変更計画に対して特定のアクセス権を持つ管理者を作成する場合は、「リソース権限」セクションで「追加」を選択します。すでに作成されている変更計画のリストから1つ以上の変更計画を選択し、「選択」をクリックします。選択した計画が「リソース権限」セクションに追加されます。デフォルトでは、管理者には「変更計画の表示」権限が付与されます。これを編集して、「変更計画の編集」権限を付与することができます。
「続行」をクリックします。
「管理者の作成: 確認」ページで「終了」をクリックすると、新しい管理者が作成されます。
これらの権限タイプのいずれかを使用して外部クライアントが変更計画にアクセスできるようにするには、次の手順を実行します。
DBA権限を持つユーザーとしてリポジトリ・データベースにログインします。
新しい管理者に該当するデータベース・ユーザーにCHANGE_PLAN_USERデータベース・ロールを付与します(Enterprise Manager管理者の「スキーマ」→「ユーザー」、またはSQL Plusを使用)。
開発者がSQL Developerインタフェースを介してスキーマ変更をEnterprise Managerスキーマ変更計画に発行できるようにするには、次の手動の構成手順を実行します。
リポジトリ管理者が、SQL Developerからのリモート・データベース接続を受け入れるようリポジトリ・データベースを構成してあることを確認します。これは、リポジトリ・リスナー・プロセスを構成することで行うことができます。
OMSでローカル管理者アカウントを作成します。
リポジトリ・データベースでSYSとして次のSQLコマンドを実行し、ローカルOMSアカウント権限のリポジトリ・ユーザーを変更計画ユーザーにします。
grant CHANGE_PLAN_USER to PUBLIC;
または
grant CHANGE_PLAN_USER to <repos_user>;
OMSユーザーのリソース権限を編集し、変更計画を編集するためのアクセス権をユーザーに付与します。
データの比較操作では、候補データベースのデータベース・オブジェクト・セット内のデータを参照データベースのものと比較します。同じデータベース内に存在するオブジェクトを比較するには、そのデータベースを参照および候補として選択します。比較の対象となるオブジェクトを指定して比較を作成し、比較を行うCloud Controlジョブをすぐに、あるいは後で発行できます。ジョブが完了したら、データの比較を選択し、結果を表示します。比較を削除すると、結果はパージされます。
Cloud Controlのデータの比較では、比較にDBMS_COMPARISONパッケージが使用されます。次のタイプのデータベース・オブジェクトを比較できます。
表
単一表ビュー
マテリアライズド・ビュー
表、単一表ビューおよびマテリアライズド・ビューのシノニム
異なるデータベースにある異なるタイプのデータベース・オブジェクトを比較できます。たとえば、あるデータベースにある表と、別のデータベースにあるマテリアライズド・ビューを比較できます。
データの比較では、この項で説明する要件を満たす必要があります。
データベース・キャラクタ・セットは、比較対象のデータベース・オブジェクトが含まれているデータベースのものと同じである必要があります。
索引列、数値列、タイムスタンプ列および期間列のデータ型は次のとおりです。
数値列のデータ型は、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-15)。
必要な入力を行います。
2つのデータベース内に存在するオブジェクトを比較するには、1つのデータベースを参照、もう1つのデータベースを候補として選択します。
比較は常に参照データベースによって実行されるため、このデータベースはバージョン11g以上である必要があります。候補データベースはバージョン10g以上である必要があります。
参照データベースでは、処理負荷が余計にかかるため、(行全体ではなく)異なる行の行IDを格納するための領域が必要です。本番システムとテスト・システム間のデータを比較する場合、結果を処理してテスト・システムに格納する方が適切な場合があります。
作業を終了後、「OK」をクリックします。データの比較仕様ページが表示されます。
|
ヒント: 比較指定を一度定義してそれを何度も実行することをお薦めします。 |
「アクション」メニューを開き、「オブジェクト・ペアの追加」または「複数オブジェクトの追加」を選択します。「オブジェクト・ペア」を選択する場合、次のサブステップを続けます。「複数のオブジェクト」を選択する場合、ステップ4に進みます。
参照および候補オブジェクトを指定します。参照データベースは候補データベースと同じでかまいません。この場合、オブジェクトは同じデータベースのものになります。
比較用として参照または候補データベースで1つ以上の列を選択します。含まれる列は両方のオブジェクトで共通している必要があります。
必要に応じて、比較用として使用する索引を選択します。比較索引内の列は、比較に含まれるすべての行を一意に識別している必要があります。1つ以上のNULL以外の列に対する主キー制約または一意キー制約に使用される索引はこの要件を満たします。この比較で指定した索引を使用できるのは、含める列のリスト内のすべての列を選択する場合のみです。
複数の索引列を追加する場合、コンポジット索引を選択できます。
比較対象のオブジェクトのペアごとにオプションのWhere条件を指定します。
バケットの最大数およびバケット当たりの最小行を指定するか自動的に計算させます。
データを比較する時点を指定します。
システム変更番号(SCN)は、データベース内のある時点を正確かつ一意に識別する順次カウンタです。これは、ある時点を識別する最も正確な方法です。トランザクションをコミットするたびに、新規SCNが記録されます。SCNはアラート・ログから取得できます。
構成が終了したら、「OK」をクリックします。
データの比較仕様ページが再表示され、選択したオブジェクトがリストに表示されます。
「OK」をクリックし、ステップ5に進みます。
「アクション」メニューを開き、「複数オブジェクトの追加」を選択します。
複数のオブジェクトを追加すると、参照データベースから仕様に対する複数のオブジェクトの一括追加を簡単に行うことができます。多数の表やビューなどの複数のオブジェクトを参照データベースの値リストから検索および選択し、必要に応じて各項目を編集できます。
スキーマ名、および1つ以上のオブジェクト・タイプを指定し、「検索」をクリックします。
表にはオブジェクト名が移入されています。
比較するオブジェクトを選択し、「OK」をクリックします。
データの比較仕様ページが再表示され、選択したオブジェクトがリストに表示されます。
リストから比較名を選択し、「アクション」メニューを開き、比較ジョブの発行を選択します。参照データベースと候補データベースのユーザー資格証明に必要な権限の詳細は、「データベースの変更管理の概要」を参照してください。
ページで必要な資格情報を指定し、ジョブをスケジュールして「OK」をクリックします。
「データの比較」ページが再度表示され、次の確認メッセージが表示されます。
ジョブが正常に発行されました。ジョブ・ステータスを確認するには、「ジョブ・ステータス」列のリンクをクリックしてください。
「ジョブ・ステータス」列に「成功」と表示されたら、次の手順に進みます。
リストから比較名を選択し、「アクション」メニューを開き、「結果の表示」を選択します。データ比較結果ページが表示されます。
参照行データと候補行データ間に差異があることを示す「=/=」記号がある「結果」列内の行を検索します。
データ比較では、すべての表を比較します。エラーがあった場合、エラー・メッセージは、「メッセージ」タブを選択すると表示できます。エラー・メッセージは、「=」または「=/=」記号ではなく「X」で示されます。
比較を行うために実行中のSQL文を表示するには、「実行された文」タブをクリックします。
異なる「参照」/「候補」行を選択し、「ビュー行の差異」をクリックして、「行データの差異」ページで、参照のみ、候補のみ、および差異ありの変更済の各行の詳細な索引付きリストを表示します(図47-16)。
「行ソース」列は、データの各行の元を全体的に示します。また、参照と候補で異なる行内のデータは対照的な色で表示され、データのソースが参照データベースと候補データベースのどちらであるかを示します。
比較はキー列に基づいて(選択した一意の索引に応じて)表示されます。キー列値が異なる場合、行は候補または参照のみの行として表示されます。他の列が異なる場合、行は差分行として表示されます。
スキーマ・マッピング
デフォルトでは、参照オブジェクトは、参照スキーマと同じ名前のスキーマの候補オブジェクトと比較されます。スキーマ・マッピングを使用すると、オプションで参照スキーマのオブジェクトと、異なる候補スキーマのオブジェクトを比較できます。スキーマをマップできるのは一度のみです。「データ比較仕様」ページの「スキーマ・マッピング」セクションで、マッピングの参照と候補のスキーマ名を指定します。これで、指定されたスキーマ・マッピングからデフォルトの候補スキーマが選択されます。
さらに、アイテムを編集して各アイテムの候補スキーマをオーバーライドできます。「候補オブジェクト」フィールドの横にある「オーバーライド」ボタンをクリックし、任意のスキーマに属する候補オブジェクトを明示的に指定します。このようにしてオーバーライドされた候補オブジェクトのアイテムの場合、スキーマ・マッピングは無視されます。
バケットの使用
バケットとは、比較中のデータベース・オブジェクト内の行の範囲です。バケットを使用すると、データベース・オブジェクトが複数の範囲に分割され、別々に比較されるため、パフォーマンスが向上します。それぞれの比較で、比較される行が適切な数のバケットに分割されます。使用されるバケットの数はデータベース・オブジェクトのサイズに応じて変化し、比較に指定されているバケットの最大数よりも常に少なくなります。
バケットを比較すると、次のような結果になる可能性があります。
違いが見つからない場合 —
次のバケットの比較に進みます。
違いが見つかった場合 -
そのバケットをより小さいパケットに分割して、それぞれのバケットを比較できます。小さいバケットで違いが検出された場合、そのバケットはさらに小さいバケットに分割されます。このプロセスは、バケットに許可される最小行数になるまで続行され、バケットに違いがあるかどうかを示す比較レポートが作成され、各行の違いが特定されます。
特定のデータベース・オブジェクトを比較する際にパフォーマンスを最適化するために、バケットの最大数とバケット当たりの最小行数を調整できます。
比較プログラムは、バケットのすべての行の指定列に対してORA_HASH関数を使用し、そのバケットのハッシュ値を計算します。2つの対応するバケットのハッシュ値が一致する場合、バケットの内容も一致するとみなされます。ORA_HASH関数では、行の値がデータベース間で転送されないため、効率よくバケットが比較されます。かわりにハッシュ値のみが転送されます。
|
注意: 比較の索引列がVARCHAR2またはCHAR列である場合は、バケット数がバケットの最大数に指定されている値を超える可能性があります。 |
