1 Workspace Managerの概要
Oracle Workspace Manager(Workspace Managerとも呼ばれる)は、作業領域を作成し、バージョンが異なる表の行の値を、異なる作業領域にグループ化できるインフラストラクチャを提供します。
ユーザーは、古いデータのコピーを保持しながら、更新するデータの新しいバージョンを作成することができます。アクティビティの結果が永続的に格納され、同時実行性および一貫性が保証されます。
Workspace Managerは、通常、次の操作を実行するアプリケーションに有効です。
-
更新および挿入を本番データに取り込む前に、これらの集合を1単位として管理する。
変更を公開する前に、変更内容を確認し、適切でない変更をロールバックできます。変更が公開されるまで、データベースの他のユーザー(通常の本番データのみにアクセスするユーザー)に対してはこの変更は表示されません。変更は、単純な一連の作業領域または複雑な作業領域階層に編成できます。一般的な例としては、ライフサイエンス・アプリケーションなどがあります。このようなアプリケーションでは、更新が本番データにマージされる前にWorkspace Managerが更新の集合を管理することで、検出プロセスおよび品質保証(QA)プロセスをサポートします。
-
共同開発作業をサポートする。
チームは、共同プロジェクトでの更新および挿入の集合へのアクセスを共有できます。作業領域権限により、作業領域および作業領域での操作へのアクセスが制御されます。また、作業領域へのアクセスを、単一ライター、読取り専用またはアクセス不可に制限できます。作業領域のロックによって、別々の作業領域内でのプロジェクト間の更新の競合が回避されます。一般的な例としては、複数のサブプロジェクトが別々の作業領域で同時に作成されるような、エンジニアリング・プロジェクトの設計アプリケーションなどがあります。
-
共通のデータ・セットを使用して、what-if分析用の使用例または公開するデータのエディションを複数作成する。
作業領域内の変更を編成して、データベース全体のコンテキストに表示できますが、データを実際に表の間でコピーする必要はありません。複数のユーザーが、同時に同一行に変更を加えた場合でも、競合を検出し解消できます。たとえば、通信アプリケーションでは、携帯電話のサービス区域のシナリオを複数作成し、最適な設計を判断できます。
-
データの変更履歴を保存する。
作業領域および行バージョンをナビゲートして、特定のマイルストンまたは時点におけるデータベースを表示できます。作業領域内の行または表に加えられた変更は、あるマイルストンまでロールバックできます。一般的な例としては、土地情報管理アプリケーションなどがあります。このようなアプリケーションでは、Workspace Managerは土地区画に加えられたすべての変更の履歴を保持することで、規制要件の遵守をサポートします。
Workspace Managerは、ロング・トランザクションの使用例を管理する場合にも有効です。複雑で継続時間の長いデータベース・トランザクションは完了するまでに数日かかることがあり、複数のユーザーが同一データベースにアクセスする必要があります。
この章では、Workspace Managerを使用するために理解しておく必要がある概念および操作について説明します。Workspace Managerの完全な例については、「Workspace Managerを使用した簡単な例」を参照してください。ただし、その例が示す概念を理解するには、まず、この章のこれ以降の説明を読む必要があります。
注:
デフォルトでは、Workspace Managerは、Oracleシード・データベース、およびDatabase Configuration Assistant(DBCA)を使用して作成された任意のデータベースにインストールされます。その他のOracleデータベースでWorkspace Managerを使用するには、まず「カスタム・データベースでのWorkspace Managerのインストール」に示すインストール手順を実行してください。
- Workspace Managerの概要
Workspace Managerでは、データベース内の1つ以上のユーザー表をバージョン対応にできます。バージョン対応表では、表内のすべての行で複数バージョンのデータをサポートできます。 - Workspace Managerのセッション・コンテキスト情報
ユーザーは標準のOracleセッション内でWorkspace Manager操作を実行します。 - Workspace Managerでのロック管理
- Workspace Managerでの権限管理
Workspace Managerには、標準のOracleデータベース権限とは異なる一連の権限があります。 - Workspace Managerのシステム・パラメータ
Workspace Managerには、WM_ADMINシステム権限を持つユーザーがデータベースに対してWorkspace Manager固有のグローバル設定を適用できるようにする一連のシステム・パラメータがあります。 - インポートおよびエクスポートの考慮点
Workspace Managerでは、完全なデータベースのインポートおよびエクスポート、Workspace Managerで必要なスキーマのみのインポートおよびエクスポート、Workspace Managerのプロシージャによる作業領域レベルのインポートおよびエクスポートのいずれかで、バージョン対応表をインポートおよびエクスポートできます。 - バージョン対応表へのバルク・ロード
SQL*Loaderを使用するとバージョン対応表へのバルク・ロードを実行できますが、特別なWorkspace Managerプロシージャもいくつかコールする必要があり、ある程度の制限が適用されます。 - バージョン対応表と関連するDDL操作
バージョン対応表に対してデータ定義言語(DDL)操作を実行するには、DDL操作の前後に特別なWorkspace Managerプロシージャを使用し、Workspace Managerによって作成される特別な表の名前を指定する必要があります。 - Workspace Managerによる制約のサポート
この項では、データベース制約の使用に関連するWorkspace Managerの考慮事項について説明します。 - バージョン対応表に対するトリガー
バージョン対応表には、トリガーを定義できます。ただし、次の考慮点および制限事項が適用されます。 - Virtual Private Databaseの考慮事項
Workspace ManagerはOracle Virtual Private Database(VPD)テクノロジと併用できます。 - 表のシノニムのサポート
Workspace Managerプロシージャまたは表名をコールするファンクションの入力パラメータの場合、表名のかわりにシノニムを指定できます。 - マテリアライズド・ビューのサポート
この項では、Workspace Managerとマテリアライズド・ビューを併用する場合の考慮事項について説明します。 - Spatial and Graphトポロジ・サポート
この項では、Oracle Spatial and Graphトポロジの表でWorkspace Managerを使用する際の特別な考慮事項と手法について説明します。 - Workspace Managerの予約語および予約文字
Workspace Managerは内部オブジェクトの作成に固有の命名規則を使用するため、ある種のオブジェクトの名前では、避ける必要のある語や文字があります。 - DBMS_WMサブプログラムのカテゴリ
Workspace ManagerのApplication Program Interface(API)は、単一のPL/SQLパッケージDBMS_WMにあるPL/SQLサブプログラム(プロシージャおよびファンクション)で構成されています。 - Workspace Managerを使用した簡単な例
このトピックでは、Workspace Managerを使用していくつかの使用例を試行し、その1つを選択するための簡単な例を2つ示します。
親トピック: 概要および使用情報
1.1 Workspace Managerの概要
Workspace Managerでは、データベース内の1つ以上のユーザー表をバージョン対応にできます。バージョン対応表では、表内のすべての行で複数バージョンのデータをサポートできます。
バージョニングのインフラストラクチャは、データベース・ユーザーからは見えません。また、データの選択、挿入、変更、削除を行うアプリケーションのSQL文は、通常どおり、バージョン対応表に対する処理を続けます。ただし、バージョン対応表の主キー列の値は更新できません。(Workspace Managerは、システム・ビューを維持し、INSTEAD OFトリガーを作成することによって、これらの機能を実装します。詳細は、「バージョン対応表のインフラストラクチャ」を参照してください。ただし、アプリケーション開発者とユーザーはビューやトリガーを表示または操作する必要がありません。)
表がバージョン対応になると、作業領域内のユーザーに必要なレコードの正確なバージョンが自動的に表示されます。表をバージョン対応にする必要がなくなった場合は、表のバージョニングを使用禁止にできます。
作業領域とは、データベース内のデータに対して変更を加えるために1人以上のユーザーが共有できる仮想環境です。作業領域は、1つ以上のバージョン対応表の新しい行バージョンの集合を論理的にグループ化し、これらのバージョンが本番データと明示的にマージされるか、または廃棄されるまで、切り離しておきます。これにより、同時実行性が最大限に引き出されます。ユーザーは、作業領域に対して様々な操作(移動、作成、リフレッシュ、マージ、ロールバック、削除、圧縮、変更など)を実行できます。
作業領域内にいるユーザーに対しては、トランザクションの一貫性を保持したデータベース全体のビューが常に表示されます。つまり、現行の作業領域で行われた変更の他に、作業領域の作成時、または親作業領域の変更によって作業領域が最後にリフレッシュされた時点でデータベースに存在したそれ以外のデータも表示されます。(作業領域階層、親作業領域および子作業領域の詳細は、「作業領域階層」を参照してください。)
Workspace Managerは競合を自動的に検出します。競合とは、作業領域および親作業領域内の同一行に対する変更によるデータ値の差異です。作業領域の変更をその親作業領域にマージする前に、競合を解消する必要があります。作業領域ロックを使用すると、競合を回避できます。
セーブポイントは、バージョン対応表の行変更をロールバックできる作業領域内のポイントで、その時点でデータベースに存在していた内容を調べることができます。通常、セーブポイントは、設計段階の完了時や支払い期限の終了時などビジネス関連指標に応じて作成されます。(セーブポイントの詳細は、「セーブポイントの使用」を参照してください。)
履歴オプションは、バージョン対応表のすべての行に加えられた変更にタイムスタンプを付け、各行に加えられたすべての変更または最新の変更のみのコピーを保存できます。表をバージョン対応にする際に(without overwrite履歴オプションを指定して)すべての変更を保存する場合は、すべての行バージョンに対して行われたすべての変更の永続履歴を保存します。また、ユーザーが希望する時点に移動して、その作業領域に存在していたデータベースを表示できるようにします。
Workspace Managerは、作業領域、セーブポイント、履歴情報、権限、アクセス・モードおよびWorkspace Managerロックを管理し、競合を検出および解消するために、新規アプリケーションおよび既存アプリケーションに追加できる総合的なPL/SQL APIを提供します。また、これらの操作のほとんどは、Oracle Enterprise Managerのグラフィカル・ユーザー・インタフェースを使用して実行することもできます。
Workspace Managerによって作成される別のデータベース・オブジェクトは、行バージョンを作業領域にマップするデータベース全体のシステム表です。この表は、ユーザーからは見えません。
- 作業領域階層
- セーブポイントの使用
- 作業領域内の変更のマージおよびロールバック
- マージまたはリフレッシュ操作前に行う競合の解消
- 作業領域のフリーズおよびアンフリーズ
- 作業領域の削除
- Workspace Managerイベントの使用
- Workspace Managerの操作の自動コミット
- 連続的にリフレッシュされる作業領域
- 複数の親を持つ作業領域
- バージョン対応表のインフラストラクチャ
- 行バージョンおよび履歴コピーの作成
- Workspace Managerのスキーマ、メタデータおよびパッケージ
親トピック: Workspace Managerの概要
1.1.1 作業領域階層
データベース内に、作業領域の階層を作成できます。たとえば、1つの作業領域が、1つ以上の作業領域(子作業領域)の親である可能性があります。デフォルトでは、作業領域は、最上位、つまりLIVEデータベース作業領域から作成されます。(作業領域名では大/小文字が区別され、LIVEデータベースの作業領域名のスペルはLIVEです。作業領域名の長さは30文字以下であり、作業領域階層の深さは30レベル以下である必要があります。)ユーザーは、GotoWorkspace操作によって作業領域に含められます。
図1-1に、作業領域の階層を示します。この図では、Workspace1およびWorkspace4はLIVEデータベース作業領域から、Workspace2およびWorkspace3はWorkspace1から、Workspace5はWorkspace4から形成されています。Workspace1の作成後、Workspace1を指定してGotoWorkspace操作を実行し、次にCreateWorkspace操作を実行してWorkspace2およびWorkspace3を作成しています。その後、Workspace4およびWorkspace5でも同様の手順を実行しています。
特定のニーズのために子作業領域を作成するか、またはセーブポイントを作成するかの決定は、設計段階で行います。詳細は、「設計面の問題: セーブポイントまたは子作業領域のいずれを作成するか」を参照してください。
親トピック: Workspace Managerの概要
1.1.2 セーブポイントの使用
セーブポイントとは、データ変更をロールバックできる作業領域内のポイントです。Workspace Managerは、不要な変更が含まれている行バージョンを削除して、ロールバックを実行します。
明示的セーブポイントとは、作成して名前を付けるセーブポイントです。バージョン対応表内の変更は、後でセーブポイントまでロールバックできます。または、セーブポイントに移動して、そのセーブポイントが作成された時点でのデータベース全体の状態(バージョン対応の行を含む)を表示できます。図1-2のSP1、SP2、SP3およびSP4は、指定された作業領域に作成された明示的セーブポイントです。(図1-2ではセーブポイントは破線で示されています。)
また、新規の作業領域が作成されると、暗黙的セーブポイントが自動的に作成されます。暗黙的セーブポイントは、子作業領域のユーザーが作業領域作成時にフリーズされたデータベースのビューを取得するために必要です。したがって、図1-2では、Workspace1およびWorkspace4の作成に対応してLIVE作業領域内に2つの暗黙的セーブポイント(SPaおよびSPd)が作成され、Workspace2およびWorkspace3の作成に対応してWorkspace1内に2つの暗黙的セーブポイント(SPbおよびSPc)が作成されます。また、Workspace5の作成に対応してWorkspace4内に1つの暗黙的セーブポイント(SPe)が作成されます。
Workspace Managerは、LATESTという名前を使用して、作業領域内の最新バージョンを示す論理セーブポイントを指定します。セーブポイントがDBMS_WMサブプログラム(プロシージャまたはファンクション)のオプションのパラメータであるときは、多くの場合、LATESTがデフォルトです。
削除可能なセーブポイントとは、CompressWorkspace、CompressWorkspaceTreeおよびDeleteSavepoint プロシージャによって削除可能なセーブポイントです。次の条件のいずれかに該当する場合、セーブポイントは削除可能です。
-
明示的セーブポイントである。
-
子作業領域と依存性がない暗黙的セーブポイントである。
1.1.2.1 設計面の問題: セーブポイントまたは子作業領域のいずれを作成するか
Workspace Managerでは、ある時点でプロジェクトを保存するために、セーブポイントを作成するか、子作業領域を作成するかという設計面の問題が発生する可能性があります。セーブポイントと子作業領域のいずれでも、一連の変更のグループ化、異なる行バージョンの変更の比較、および一連の変更のロールバックが可能です。ただし、セーブポイントを作成すると、同一作業領域内で継続して変更を加えることができ、その作業領域内の他のユーザーがすぐに変更にアクセスできるようになります。(別の作業領域内の変更は、現行の作業領域がリフレッシュまたはマージされるまで、ユーザーに対して表示されません。)また、セーブポイントを作成すると一連の変更を簡単にアーカイブできるため、後でそれらの変更にロールバックできます。
これに対し、子作業領域を作成すると、一連の複雑な変更を加えることができる分離された環境を提供でき、これらの変更を親作業領域(本番データなど)から完全に削除できます。あるシナリオに基づいて独立した環境を設定し、親作業領域内の通常のユーザーがこのシナリオのデータにアクセスする必要がない場合は、親作業領域内にセーブポイントを作成するかわりに、子作業領域を作成してください。
親トピック: セーブポイントの使用
1.1.3 作業領域内の変更のマージおよびロールバック
作業領域は、マージまたはロールバックできます。
作業領域のマージでは、子作業領域で行われた変更がその親作業領域に適用されます。その後、子作業領域は削除されます。作業領域をマージするには、MergeWorkspaceプロシージャを使用します。
作業領域のロールバックでは、作業領域内のすべてのデータ変更(行バージョン)、または明示的セーブポイント以降のすべての変更のいずれかが削除されます。
-
作業領域内のすべての変更をロールバックするには、RollbackWorkspaceプロシージャを使用します。
-
セーブポイント以降の作業領域内の変更をロールバックするには、RollbackToSPプロシージャを使用します。
注:
指定したセーブポイント以降に暗黙的セーブポイントが作成されている場合、まずその暗黙的セーブポイントが作成される原因となった子作業領域をマージまたは削除しないかぎり、そのセーブポイントにロールバックできません。たとえば、「セーブポイントの使用」の図では、
Workspace3(暗黙的セーブポイントSPcが作成された原因)がマージまたは削除されるまで、Workspace1内のユーザーはセーブポイントSP1にロールバックできません。
オープン状態のトランザクションがある作業領域は、ロールバックできません。作業領域のロールバックでは、作業領域構造は後で使用するために残され、作業領域内のデータのみが削除されます。(作業領域を完全に削除するには、RemoveWorkspaceプロシージャを使用します。詳細は、「作業領域の削除」を参照してください。)
親トピック: Workspace Managerの概要
1.1.4 マージまたはリフレッシュ操作前に行う競合の解消
子作業領域がマージされると、子作業領域内の行変更がその親作業領域に取り込まれます。子作業領域がリフレッシュされると、親作業領域内の行変更が子作業領域に取り込まれます。子作業領域と親作業領域の両方で行が変更されると、データの競合が発生します。マージまたはリフレッシュ操作が要求されると、競合が自動的に検出され、競合(xxx_CONF)ビューに表示されます。表ごとに1つの競合ビューがあります。詳細は、「xxx_CONFビュー」を参照してください。このビューには、競合が発生している2つの作業領域内の行の列値がリストされます。
競合は、セッションに対し作業領域競合のコンテキストを設定してからResolveConflictsプロシージャを使用して、手動で解消する必要があります。それぞれの競合について、子作業領域の行を保存するか、親作業領域の行を保存するか、または共通のベース行を保存するか(行の元のデータ値を保存する(変更なし))を選択できます。マージ操作(MergeWorkspace)またはリフレッシュ操作(RefreshWorkspace)を実行する前に、競合を解消する必要があります。
ベースの行は、子作業領域での最初の更新または削除操作時では、現在参照できる行です。挿入操作の場合、挿入される行が親作業領域の祖先バージョンで以前に削除されていれば、ベースの行はその削除された行ですが、それ以外では、ベースの行は存在しません。親の行は、競合解消時では、親作業領域で現在参照できる行であり、子の行は、競合解消時では、子作業領域で現在参照できる行です。
データが存在しないことは競合ではありません。この場合は、xxx_DIFFビュー(「xxx_DIFFビュー」を参照)を使用して、ある作業領域での変更を削除できます(他の作業領域に行が存在しないか行への変更が存在しない場合のみ)。
競合の一般的な解消手順は、次のとおりです。
-
GotoWorkspaceプロシージャまたはSetConflictWorkspaceプロシージャを使用して、セッションに対し作業領域競合のコンテキストを設定します。
-
xxx_CONFビュー(「xxx_CONFビュー」を参照)を調べて、どのような競合が存在するかを確認します。
-
BeginResolveプロシージャを実行します。
-
影響を受ける表と作業領域の組合せごとに1回、ResolveConflictsプロシージャを実行します。
-
すべての競合を解消した後で、次のいずれかのプロシージャを実行します。
-
CommitResolve: 前述のステップのすべての変更を永続的な変更にする場合。(ただし、次のステップに示すとおり、MergeWorkspaceまたはRefreshWorkspaceプロシージャを実行するまでは、データベース内の変更は永続的な変更にはなりません。)
-
RollbackResolve: 前述のステップのすべての変更を廃棄する場合。(すべての変更を破棄する場合、次のステップは実行しないでください。)
-
-
標準のデータベース・コミット操作を行い、MergeWorkspaceまたはRefreshWorkspaceプロシージャを実行します。
親トピック: Workspace Managerの概要
1.1.5 作業領域のフリーズおよびアンフリーズ
作業領域へのアクセス制限を設定および解除することにより、作業領域への読込みおよび書込みを制御できます。作業領域がアクセス制限されている場合は、作業領域へアクセスし、バージョン対応表内の行に変更を加えるためのユーザー権限が制限されます。作業領域へのアクセスは、アクセス不可、読取り専用、1ユーザーのみ(1WRITER)のいずれかのモードで制限できます。
作業領域へのアクセスを制限するには、FreezeWorkspaceプロシージャを使用します。作業領域へのアクセス制限を解除するには、UnfreezeWorkspaceプロシージャを使用します。
また、プロシージャによっては1つ以上の作業領域のアクセスを自動的に制限します。表1-1に、これらのプロシージャ、影響を受ける作業領域、およびアクセス制限される作業領域のモードを示します。(モードの値の詳細は、「DBMS_WMパッケージ: リファレンス」のFreezeWorkspaceプロシージャの説明を参照してください。)
表1-1 プロシージャのアクセス制限の結果
| プロシージャ | 作業領域およびモード |
|---|---|
|
指定された作業領域: |
|
|
指定された作業領域: 親作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: 親作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
親トピック: Workspace Managerの概要
1.1.6 作業領域の削除
作業領域は、RemoveWorkspaceプロシージャを使用して削除できます。RemoveWorkspaceを実行すると、作業領域内のデータがロールバックされ、その後、作業領域構造が削除されます。RemoveWorkspaceTreeプロシージャを使用すると、作業領域のツリー全体を削除できます。このプロシージャは、作業領域およびそのすべての子作業領域を削除します。作業領域内にユーザーがいる場合、その作業領域は削除できません。
親トピック: Workspace Managerの概要
1.1.7 Workspace Managerイベントの使用
数種類のWorkspace Manager操作をイベントとして取得し、Oracle Advanced Queuing(AQ)フレームワークを介してアプリケーションに通信できます。非同期通知、永続性、伝播、アクセス制御、履歴およびルールベースのサブスクリプションなど、AQのメッセージ機能をWorkspace Managerイベントに使用できます。
Workspace Managerイベントのサポートには、ALLOW_CAPTURE_EVENTS Workspace Managerシステム・パラメータ、SetCaptureEventプロシージャおよびWM_EVENTS_INFOメタデータ・ビューが含まれています。
Workspace Managerイベントおよびアプリケーションでの使用方法については、「Workspace Managerイベント」を参照してください。
親トピック: Workspace Managerの概要
1.1.8 Workspace Managerの操作の自動コミット
デフォルトでは、Workspace Managerの多くの操作は、自律型データベース・トランザクションとして実行され、終了時にコミットされます。つまり、このようなトランザクションは独立したトランザクションであり、現行のデータベース・トランザクション内部からコールされ、コール側トランザクションのコンテキストをそのまま残し、Workspace Manager操作を実行した後、その操作を自動的にコミットし、コール側トランザクションのコンテキストに戻り、そのトランザクションを継続します。このように動作するWorkspace Manager (DBMS_WM)サブプログラムには、オプションのauto_commitパラメータがあります。このパラメータのデフォルト値は、TRUEです。
たとえば、CompressWorkspaceプロシージャはデフォルトで自律型トランザクションを起動し、作業領域を圧縮し、圧縮操作をコミットした後、コール側トランザクションのコンテキストに戻り、現行のデータベース・トランザクションを継続します。
ただし、自律型トランザクションを開始するのではなく、コール側トランザクションのコンテキストでこのようなサブプログラムを実行する場合は、auto_commitパラメータ値をFALSEに指定します。この場合、Workspace Manager操作は現行のデータベース・トランザクションの一部として実行され、オープン状態の現行のトランザクションがない場合は、Workspace Manager操作は新しいトランザクションを開始します。いずれの場合も、そのトランザクションがコミット操作によって終了するまで、Workspace Manager操作は有効になりません。たとえば、auto_commitパラメータにFALSEを指定してCompressWorkspaceプロシージャをコールすると、トランザクションがコミットされるまで作業領域は圧縮されません。またトランザクションがロールバックされた場合、作業領域は圧縮されません。
auto_commitパラメータをFALSEに指定した場合は、トランザクションを明示的にコミットまたはロールバックする必要があることに注意してください。
auto_commitパラメータ値がTRUEで、オープン状態のトランザクションが存在する場合は、次の考慮点が適用されます。
-
CompressWorkspaceプロシージャおよびCompressWorkspaceTreeプロシージャでは、オープン状態のトランザクションが存在する場合、例外が発生します。
-
その他のすべてのWorkspace Managerプロシージャでは、修正が必要な表の親作業領域または子作業領域内にオープン状態のトランザクションが存在する場合、例外が発生します。
親トピック: Workspace Managerの概要
1.1.9 連続的にリフレッシュされる作業領域
連続的にリフレッシュされる作業領域とは、データ変更が親作業領域内でコミットされるか、別の子作業領域から親作業領域にマージされるたびに、親作業領域から自動的にリフレッシュされる作業領域です。連続的にリフレッシュされる作業領域の場合、RefreshWorkspaceプロシージャをコールする必要はありません。
作業領域ツリーのブランチにある作業領域は、連続的にリフレッシュできます。親作業領域が連続的にリフレッシュされるかどうかにかかわらず、子作業領域は連続的にリフレッシュされる作業領域にできます。ただし、親作業領域が連続的にリフレッシュされる作業領域である場合、その子作業領域も連続的にリフレッシュされる必要があります。
連続的にリフレッシュされる作業領域を作成するには、CreateWorkspaceプロシージャのコールでisrefreshedパラメータにTRUEを指定します。連続的にリフレッシュされる作業領域の作成に適用されるルールについては、CreateWorkspaceプロシージャの「使用上の注意」を参照してください。
連続的にリフレッシュされない作業領域を連続的にリフレッシュされるように変更するには、ChangeWorkspaceTypeプロシージャを使用します。
作業領域が連続的にリフレッシュされない場合は、親作業領域内のデータ変更を作業領域内で参照できるかどうかの確認が必要になるたびに、RefreshWorkspaceプロシージャをコールする必要があります。
親トピック: Workspace Managerの概要
1.1.10 複数の親を持つ作業領域
複数の親を持つ作業領域とは、2つ以上の親作業領域を持つ子作業領域です。作業領域は、最初は1つの親を持つ作業領域として作成されます。ただし、必要に応じて既存の作業領域に他の作業領域を親作業領域として追加し、複数の親を持つ作業領域にすることができます。複数の親を持つ作業領域では、すべての親作業領域と祖先作業領域のデータを参照でき、親作業領域とマージして親作業領域からリフレッシュできます。
図1-3は、図1-1の作業領域と同じ階層を示します。ただし、Workspace3は、Workspace1およびWorkspace4の2つの親を持つ作業領域である点が異なります。
複数の親を持つ作業領域を、複数の親を持つリーフ作業領域と呼ぶこともあります。したがって、図1-3では、作業領域3は複数の親を持つリーフ作業領域です。複数の親を持つリーフ作業領域のすべての親作業領域に共通して最も近い祖先を、複数の親を含むルート作業領域と呼びます。図1-3では、LIVE作業領域はWorkspace3の複数の親を含むルート作業領域です。リーフ作業領域の親として親作業領域を追加することにより形成される非循環有向グラフ(DAG)では、すべての作業領域を複数の親を持つグラフ作業領域と呼びます。図1-3では、Workspace1、Workspace4およびWorkspace3は、複数の親を持つグラフ作業領域です。
複数の親を持つ作業領域を使用できるのは、ALLOW_MULTI_PARENT_WORKSPACE Workspace Managerシステム・パラメータがONに設定されている場合のみです。また、連続的にリフレッシュされる作業領域を複数の親を持つ作業領域にするには、CR_WORKSPACE_MODE Workspace Managerシステム・パラメータをPESSIMISTIC_LOCKINGに設定する必要があり、連続的にリフレッシュされない作業領域を複数の親を持つ作業領域にするには、NONCR_WORKSPACE_MODE Workspace Managerシステム・パラメータをPESSIMISTIC_LOCKINGに設定する必要があります。」Workspace Managerのシステム・パラメータの詳細は、「Workspace Managerのシステム・パラメータ」を参照してください。
複数の親を持つ作業領域を作成するには、AddAsParentWorkspaceプロシージャを使用します。複数の親を持つ作業領域の親である作業領域を削除するには、RemoveAsParentWorkspaceプロシージャを使用します。複数の親を持つグラフ作業領域に対する権限を付与および取り消すには、それぞれGrantGraphPrivプロシージャおよびRevokeGraphPriv プロシージャを使用します。これらのプロシージャの詳細は、「DBMS_WMパッケージ: リファレンス」を参照してください。
Workspace Managerには、複数の親を持つ作業領域に関する情報を格納するために、次の静的データ・ディクショナリ・ビュー(「Workspace Managerの静的データ・ディクショナリ・ビュー」を参照)が用意されています。
-
USER_MP_GRAPH_WORKSPACESおよびALL_MP_GRAPH_WORKSPACESには、複数の親を持つグラフ作業領域の情報が含まれています。
-
USER_MP_PARENT_WORKSPACESおよびALL_MP_PARENT_WORKSPACESには、複数の親を持つリーフ作業領域の親作業領域の情報が含まれています。
親トピック: Workspace Managerの概要
1.1.11 バージョン対応表のインフラストラクチャ
EnableVersioningプロシージャを使用して表をバージョン対応にする場合、Workspace Managerは自動的に操作を実行し、DBA以外のユーザーには表示されないがWorkspace Manager自身の機能は許可されるデータ構造を作成します。Workspace Managerによって保持される情報には、静的データ・ディクショナリ・ビュー(「Workspace Managerの静的データ・ディクショナリ・ビュー」を参照)に格納されるものと、ユーザーがアクセスできないシステム・データ構造に格納されるものがあります。
バージョン対応表の場合、Workspace Managerはその表名を<table-name>_LTに変更し、この表にバージョニング・メタデータを格納するための列をいくつか追加します。追加される列の名前は、WM_で始まります(WM_VERSION、WM_CREATETIME、WM_RETIRETIME、WM_NEXTVER、WM_DELSTATUS、WM_LTLOCK)。
ユーザーやアプリケーションがSQL文に<table-name>_LT表を指定することはできません。引き続き元の表名(<table-name>)を指定してください。(バージョン対応表に関連付けられている<table_name>_LT表の名前を検索する必要がある場合や、<table_name>_LT表の有無をチェックして表がバージョン対応かどうかを調べる必要がある場合は、GetPhysicalTableNameファンクションを使用します。)
Workspace Managerは、元の表(<table-name>)にビューを作成するだけではなく、挿入、更新および削除操作用に、そのビューに対するINSTEAD OFトリガーも作成します。アプリケーションが、バージョン対応表内のデータを挿入、更新または削除するための文を実行すると、適切なINSTEAD OFトリガーが実際に操作を実行します。ビューにアクセスすると、作業領域のメタデータを使用して、ユーザーの現行の作業領域に関連する行バージョンのみ表示されます。
Workspace Managerでは、インフラストラクチャ・オブジェクトの作成時に元のオブジェクト名が使用されるため、オブジェクトの種類によっては、その名前に有効な長さの最大値が、Oracle Databaseで許可される最大値よりも短くなります。データベースの互換性設定に基づいて、30文字または128文字の識別子をサポートするようにデータベースを定義できます。互換性設定が12.2以上の場合、識別子の長さ(<DB–identifier–length>)は128であり、それ以外の場合は30です。特定のオブジェクトの長さ制限は、その<DB–identifier–length>値のオフセット(その値から減算される値)で表現されます。
表1-2に、バージョン対応表および関連オブジェクトに対する名前の長さの最大値のガイドラインを示します。(「Workspace Managerの予約語および予約文字」で、特定の名前に対する予約語および予約文字の詳細も参照してください。)
表1-2 Workspace Managerの名前の長さのガイドライン
| オブジェクトの種類 | 名前の文字数の最大値 |
|---|---|
|
表 |
<DB–identifier–length> – 5 |
|
列 |
<DB–identifier–length> – 2 |
|
索引 |
<DB–identifier–length> (<DB–identifier–length> — BeginDDLプロシージャおよびCommitDDLプロシージャのコール間で索引が作成または変更された場合は4) |
|
トリガー |
<DB–identifier–length> |
|
制約 |
<DB–identifier–length> (<DB–identifier–length> - BeginDDLプロシージャおよびCommitDDLプロシージャのコール間で制約が作成または変更された場合は4) |
Workspace Managerでは、バージョン対応表に対し、SQL MERGE文(あらゆる使用方法)、およびINSERT文またはUPDATE文でのRETURNING句をサポートしていません。RETURNING句の制約の原因は、Workspace Managerによりバージョン対応表でINSTEAD OFトリガーを持つビューが作成されても、Oracle Databaseはビュー上で定義されたINSTEAD OFトリガーを持つRETURNING句をサポートしていないことにあります。
親トピック: Workspace Managerの概要
1.1.12 行バージョンおよび履歴コピーの作成
この項では、Workspace Managerが新しい行バージョンを作成し、古いバージョンの履歴コピーをメンテナンスするプロセスについて説明します。
新しい行バージョンは、次のいずれかを実行すると、バージョン対応表に作成されます。
-
現行の作業領域で明示的セーブポイントを作成し、行を更新する。
-
現行の作業領域の下に子作業領域を作成する(CreateWorkspaceプロシージャを使用)、したがって現行の作業領域に暗黙的セーブポイントを作成する。GotoWorkspaceプロシージャを実行して子作業領域に移動し、行を更新する。
表で履歴が有効になっているか、別のセーブポイントが作成されないかぎり、その後のあらゆる現行の行の更新で、現行の行バージョンが上書きされます。
-
上書きを伴わない履歴を有効にする(
VIEW_WO_OVERWRITE)と、現行の行バージョンを更新するたびに、変更とトランザクション時間に基づくタイムスタンプが適用された現行の行バージョンの完全なコピーが作成されます。このコピーは、新しい現行の行バージョンになります。 -
上書きを伴う履歴を有効にする(
VIEW_W_OVERWRITE)と、現行の行バージョンが更新されるたびに現行の行バージョンが上書きされ、トランザクション・タイムスタンプが更新されます。 -
作業領域にセーブポイントが作成されると、行への次の変更によって新しいバージョンが作成され、履歴サイクルが再び開始されます。
作業領域で作成される行バージョンは、MergeWorkspaceプロシージャまたはMergeTableプロシージャを実行しないかぎり、親作業領域から参照できません。
子作業領域に対してMergeWorkspaceプロシージャを実行する場合、子作業領域の現行の行バージョンだけが親作業領域にマージされます。remove_workspaceパラメータをTRUEに指定すると、子作業領域が削除されるときに子作業領域のすべての中間行バージョンが削除されます。子作業領域に作成されたすべての中間バージョンを保持するには、remove_workspaceパラメータをFALSE(デフォルト)にする必要があります。
子作業領域でCompressWorkspaceプロシージャを実行して中間セーブポイントを削除する場合、その行バージョンの関連履歴コピーも削除することができます。これらのコピーを削除しない場合、これらのコピーは次のバージョンに関連付けられます。
中間行バージョンは、読取り専用アクセスのためにのみ選択できます。読取り専用アクセスのために中間行バージョンを選択するには、まだその作業領域に移動していない場合は移動し(GotoWorkspaceプロシージャ)、GotoDateプロシージャを実行してセッション・コンテキストを履歴時間に設定するか、GotoSavepointプロシージャを実行してセッション・コンテキストを特定のセーブポイントに設定します。後続のSELECT文は、読取り専用アクセスのために、指定された日付またはセーブポイントの時点で最新の行バージョンを選択します。
例1-1に、暗黙的セーブポイントと明示的セーブポイントの作成後にバージョン対応表の行バージョンが作成される例を示します。たとえば、EMP表にEMPNO、SALARYおよびCOMMISSIONという列が含まれているとします。
VIEW_WO_OVERWRITE履歴オプションが指定された表に対して例1-1を実行すると、xxx_HISTビュー(「xxx_HISTビュー」を参照)には、DML操作ごとに1行が含まれます。次に例を示します。
select salary, commission, wm_workspace, wm_optype from EMP_HIST where empno = 100;
| SALARY | COMMISSION | WM_WORKSPACE | WM_OPTYPE |
|---|---|---|---|
|
0 |
0 |
LIVE |
I |
|
10000 |
0 |
LIVE |
U |
|
10000 |
1000 |
LIVE |
U |
|
20000 |
1000 |
Workspace 1 |
U |
|
20000 |
2000 |
Workspace 1 |
U |
|
30000 |
3000 |
LIVE |
U |
|
40000 |
3000 |
LIVE |
U |
|
40000 |
4000 |
LIVE |
U |
|
40000 |
4000 |
LIVE |
D |
ただし、VIEW_W_OVERWRITE履歴オプションまたはNONE履歴オプションが指定された表に対して例1-1を実行すると、xxx_HISTビュー(「xxx_HISTビュー」を参照)には、セーブポイントごとに1行のみが含まれます。これは、同一セーブポイント内では行バージョンが後続のDML操作によってオーバーライドされるためです。次に例を示します。
select salary, commission, wm_workspace, wm_optype from EMP_HIST where empno = 100;
| SALARY | COMMISSION | WM_WORKSPACE | WM_OPTYPE |
|---|---|---|---|
|
10000 |
1000 |
LIVE |
U |
|
20000 |
2000 |
Workspace 1 |
U |
|
30000 |
3000 |
LIVE |
U |
|
40000 |
4000 |
LIVE |
D |
例1-1 暗黙的なセーブポイントと明示的なセーブポイントの作成後に作成される行バージョン
execute dbms_wm.GotoWorkspace('LIVE') ;
insert into EMP(empno, salary, commission) values (100, 0, 0) ;
update EMP set salary = 10000 ;
update EMP set commission = 1000 ;
commit ;
–- CreateWorkspace creates an implicit savepoint in 'LIVE'; DML operations
–- create new row versions for both workspaces.
execute dbms_wm.CreateWorkspace('WorkSpace 1') ;
execute dbms_wm.GotoWorkspace('WorkSpace 1') ;
update EMP set salary = 20000 ;
update EMP set commission = 2000 ;
commit ;
execute dbms_wm.GotoWorkspace('LIVE') ;
update EMP set salary = 30000, commission = 3000 ;
commit ;
-– CreateSavepoint creates an explicit savepoint in 'LIVE'; DML operations
-– create new row versions for only the LIVE workspace.
execute dbms_wm.CreateSavepoint('LIVE', 'SP1') ;
update EMP set salary = 40000 ;
update EMP set commission = 4000 ;
delete EMP where empno = 100 ;
commit ;
親トピック: Workspace Managerの概要
1.1.13 Workspace Managerのスキーマ、メタデータおよびパッケージ
Workspace Managerは、WMSYSという名前のユーザーを作成します。WMSYSスキーマは、Workspace Managerのすべてのメタデータ情報を格納するために使用します。DBMS_WMパブリック・シノニムを持つPL/SQLパッケージには、Workspace Managerサブプログラム(プロシージャおよびファンクション)が含まれています。
PUBLICユーザー・グループには、次の権限が付与されます。
-
Workspace Managerの静的データ・ディクショナリ・ビュー(「Workspace Managerの静的データ・ディクショナリ・ビュー」を参照)に対する
SELECT権限 -
DBMS_WMパッケージ(「DBMS_WMパッケージ: リファレンス」を参照)に対するEXECUTE権限
親トピック: Workspace Managerの概要
1.2 Workspace Managerのセッション・コンテキスト情報
ユーザーは、標準のOracleセッション内でWorkspace Managerの操作を実行します。
セッションとは、ユーザー・プロセスを使用した、ユーザーからOracleインスタンスへの特定の接続です。セッションは、ユーザーが接続した時点から、接続を切断するかデータベース・アプリケーションが終了する時点まで続きます。Workspace Managerの操作を実行すると、セッション・コンテキストに関連する情報が自動的に記録されます。
セッション・コンテキスト情報には、作業領域名およびコンテキスト値が含まれます。この情報により、作業領域内のセッションに表示できるデータ、およびセッションが入ることができる作業領域が決まります。コンテキスト値は次のいずれかです。
-
LATEST: セッションが現在LATESTセーブポイント(「セーブポイントの使用」を参照)に設定され、作業領域内で行われた変更がセッションに表示されます。セッションが作業領域に入ると(GotoWorkspaceプロシージャを使用)、コンテキストは自動的にLATESTに設定されます。 -
セーブポイント名: 現在、セッションが作業領域内のセーブポイントに設定されています。最新バージョンの作業領域で変更が行われても、セッションではこれらの変更は表示されませんが、セーブポイント作成時のデータの静的ビューが表示されます。GotoDateプロシージャがコールされた後、セッション・コンテキストはセーブポイント名に設定されます。
-
特定の時点: 現在、セッションは特定の時点に設定されています。最新バージョンの作業領域で変更が行われても、セッションではこれらの変更は表示されませんが、特定の時点におけるデータの静的ビューが表示されます。GotoDateプロシージャがコールされた後、セッション・コンテキストはある時点に設定されます。(正確な時点は、EnableVersioning プロシージャで設定されるか、あるいはSetWoOverwriteOFFプロシージャまたはSetWoOverwriteONプロシージャで変更される、変更追跡用の履歴オプションによって異なります。)
セッション・コンテキストに関する情報は、GetSessionInfoプロシージャを使用して取得できます。この情報を取得すると、GotoWorkspace操作、GotoSavepoint操作およびGotoDate操作を組み合せて実行した後など、セッションの場所(作業領域およびコンテキスト)を知る必要がある場合に有効です。
親トピック: Workspace Managerの概要
1.3 Workspace Managerでのロック管理
通常のOracleデータベース・トランザクションが提供するロックの他に、Workspace Managerは2種類のバージョン・ロックを提供します。このロックの主な目的は、親作業領域と子作業領域の間における行の競合を排除することにある。ロックは、作業領域、セッションまたは指定行に対して、あるいはそれらを組み合せて使用可能にできます。
-
データ変更が1つまたは少数の作業領域内で行われている場合、または作業領域内のすべてのデータ変更をロックする場合は、作業領域レベルでロックします(SetWorkspaceLockModeONプロシージャ)。
-
データ変更が多数の作業領域内で行われている場合は、セッション・レベルでロックします(SetLockingONプロシージャ)。セッションに対してロックを使用可能にすると、Workspace Managerはこのセッションが存在するすべての作業領域の行をロックします。
-
行が更新される前に行をロックするか、または行が挿入された後(または、更新後に
WHERE句を満たす場合は、更新された後)に行を自動的にロックする場合は、特定の行をロックします(LockRowsプロシージャ)。
作業領域およびセッションのロックは、作業領域またはセッションの存続期間中、あるいは作業領域がマージまたはロールバックされるまで持続します。
データベースのロックと同様に、Workspace Managerのロックには排他ロックまたは共有ロックがあります。
-
排他ロック: このロックは、データベース・トランザクションのロックに非常に類似しています。レコードが排他ロックされると、レコードをロックしたセッション(ユーザー)以外のデータベース内のユーザーは、そのレコードを変更できません。排他的ロックがユーザーに対して有効になっている場合、そのユーザーが変更を行ったすべての行が排他的にロックされます。また、その行の親である行も排他的にロックされます。このため、排他ロック操作を使用すると、子作業領域と親作業領域の間におけるデータの競合を排除できます(ただし、排他ロックと行バージョンの詳細と、更新操作における排他ロックのタイミングが、他ユーザーが行を更新できるかどうかにどのように影響するかの詳細は、「排他ロックと行バージョン」を参照してください。)
-
共有ロック - 行が一度共有ロックされると、行がロックされている作業領域のユーザーのみがその行を変更できます。その行の親バージョンも共有ロックされるため、その行は競合から保護されます。排他ロックにない共有ロックのメリットは、行がロックされている作業領域内のすべてのユーザーがその行にアクセスし、行を変更できることです。この種類のロックは、親である行との競合を避ける必要があり、グループ・プロジェクトのメンバーである複数のユーザーが変更する必要がある行に使用することが理想的です。共有ロック操作は、作業領域内の各セッションに対して個々に使用可能にする必要があることに注意してください。
作業領域排他ロックとバージョン排他ロックは、ユーザーがデータ値を変更できるかどうかを制御する排他ロックの一種ですが、排他ロックとは異なり、競合の発生は回避されません。作業領域排他ロックは、ロックを設定したユーザーのみが現行の作業領域内で値を変更できるように行をロックします。ただし、他の作業領域の他のユーザーは値を変更できます。バージョン排他ロックは、ロックを設定したユーザーのみが値を変更できる(またそのユーザーがどの作業領域でも操作できる)ように行をロックします。どの作業領域でも他のユーザーは値を変更できません。
次の表に、特定の作業領域内で特定のユーザーがロックした行を、どの作業領域のどのユーザーが変更できるかを示します。たとえば、この表の最初の2つの項目は、行が共有(S)ロックされていると、その行がロックされた作業領域のユーザーはだれでもその行を変更できますが、他の作業領域内のユーザーはその行を変更できないことを意味します。
表1-3 Workspace Managerのロック・モードとデータ変更の可否
| ロック・モード | ユーザー | ユーザーの作業領域 | 変更可能/不可 |
|---|---|---|---|
|
共有(S) |
すべてのユーザー |
行がロックされた作業領域 |
可能 |
|
共有(S) |
すべてのユーザー |
行がロックされたのとは異なる作業領域 |
不可 |
|
排他(E) |
行をロックしたユーザー |
行がロックされた作業領域 |
可能 |
|
排他(E) |
行をロックしたユーザー |
行がロックされたのとは異なる作業領域 |
不可 |
|
排他(E) |
行をロックしたのとは異なるユーザー |
すべての作業領域 |
不可 |
|
作業領域排他(WE) |
行をロックしたユーザー |
すべての作業領域 |
可能 |
|
作業領域排他(WE) |
行をロックしたのとは異なるユーザー |
行がロックされたのとは異なる作業領域 |
可能 |
|
作業領域排他(WE) |
行をロックしたのとは異なるユーザー |
行がロックされた作業領域 |
不可 |
|
バージョン排他(VE) |
行をロックしたユーザー |
すべての作業領域 |
可能 |
|
バージョン排他(VE) |
行をロックしたのとは異なるユーザー |
すべての作業領域 |
不可 |
行をロックすることは、作業領域のマージ操作、リフレッシュ操作およびロールバック操作には影響しませんが、これらの操作後、その行で何ができるかに影響します。これらの作業領域操作を実行する前に、作業領域権限を使用して、FreezeWorkspaceプロシージャをコールし、作業領域xxx_LOCKビュー(「xxx_LOCKビュー」を参照)を確認することにより、操作を制御できます。
xxx_LOCK静的データ・ディクショナリ・ビュー(「xxx_LOCKビュー」を参照)には、各バージョン対応表のロックに関する情報が含まれています。
参照整合性制約を持つ表に対するDML操作でのWorkspace Managerロック操作の詳細は、「参照整合性制約を持つ表のDML操作でのロック」を参照してください。
1.3.1 排他ロックと行バージョン
子作業領域内での更新操作に対する排他ロックのタイミングは、親作業領域内で、どの行のどのバージョン(バージョンがある場合)を更新できるかに影響します。たとえば、表がLIVE作業領域内でバージョン対応している場合、元の各行はバージョン0に割り当てられます。LIVE作業領域の子としてW1の名前の作業領域が作成されると想定します。作業領域W1の作成時、次の動作が発生します。
-
バージョン1は
LIVE作業領域に割り当てられる(ただし、追加の行は作成されない)。 -
バージョン2は作業領域
W1に割り当てられる(ただし、追加の行は作成されない)。作業領域W1内の問合せは、引き続きLIVE作業領域内にある行のバージョン0に戻されます。
この例を使用すると、作業領域W1内のユーザーが、更新される前の行に排他ロックをかけた場合、作業領域W1内のこのユーザーのみが行を更新できます。具体的には、次のようになります。
-
その行のバージョン0がロックされ、ロックが解除されるまで、他作業領域からその行へのすべての更新を排除します。
-
バージョン0は作業領域
W1の現在の物理行であるため、作業領域W1(またはW1の子孫作業領域)からロックをかけることができます。 -
作業領域
W1のユーザーがこの行を更新すると、作業領域W1およびそのすべての子作業領域からのみ参照できる新しい行(バージョン2)が作成されます。
ただし、この行がLIVE作業領域内でロックされていない場合は、作業領域W1内のユーザーが行を更新した後でこの行に排他ロックをかけると、LIVE作業領域内のユーザーはこの行を更新できます。具体的には、次のようになります。
-
作業領域
W1およびそのすべての子作業領域からのみ参照できる新しい行(バージョン2)が作成されます。 -
バージョン2の行がロックされます。ロックをかけたユーザー以外の作業領域
W1内のユーザー、または作業領域W1のすべての子作業領域内のユーザーは、行を更新したり、行の新しいバージョンを作成したりできません。 -
LIVE作業領域の行のバージョン0はロックされていません。LIVE作業領域内またはW1の兄弟作業領域内のユーザーが行を更新した場合、行の新しいバージョン(バージョン1)が作成されます。(バージョン0は、すでに作業領域W1内のユーザーにとって行の現行バージョンではないため、ロックされません。かわってバージョン2がその作業領域内の行の現行バージョンになっています。)
つまり、更新後の排他ロックは、作業領域ツリー内のロックされた作業領域の上位にある作業領域内の行、または作業領域ツリーの他ブランチ内の作業領域内の行の以前のバージョンをロックしません。
親トピック: Workspace Managerでのロック管理
1.3.2 Workspace Managerの操作に適用されるロック
Workspace Managerは、DBMS_WMサブプログラムに関連する特定の操作を実行するときに、自動的にロックを適用します。Workspace Managerは次の内容をチェックします。
-
必要なロックを正常に要求できるかどうか
-
作業領域が、要求された操作との互換性がないモードにアクセス制限されているかどうか
必要なロックを要求できない場合、または作業領域が互換性のないモードでアクセス制限されている場合は、エラーが生成されます。
表1-4に、Workspace Managerの操作と、その操作で特定の種類の作業領域(親作業領域、現行の作業領域、複数の親を持つ中間作業領域)がロックされる互換性のないアクセス制限モードを示します。表1-4の説明:
-
N/Aは適用外、つまり互換性のないアクセス制御モードがないことを意味します。
-
排他 +は、排他ロックに加えて、作業領域ではセッションを実行できないことを意味します。
-
半排他は、
DBMS_LOCKプロシージャで使用されているSX_MODE定数を意味します。詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。SX_MODEを集計オブジェクトで使用すると、排他ロックがオブジェクトのサブパーツに対して作動中であることを示すことができます。 -
共有半排他は、
DBMS_LOCKプロシージャで使用されているSSX_MODE定数を意味します。詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。SSX_MODEを使用すると、集計オブジェクト全体で共有ロックを使用している一方、一部のサブパーツでは排他ロックも使用している可能性があることを示すことができます。 -
半共有は、
DBMS_LOCKプロシージャで使用されているSS_MODE定数を意味します。詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。SS_MODEを集計オブジェクトで使用すると、共有ロックがオブジェクトのサブパーツに対して作動中であることを示すことができます。 -
共有(1)は、ROW_LEVEL_LOCKING=OFFの場合の共有半排他を除く共有を意味します。
CompressWorkspaceおよびCompressWorkspaceTreeでは、影響を受ける作業領域内の現在のバージョンが、1つ以上の他のバージョンとともに圧縮可能な範囲内にある場合、その作業領域に対する共有半排他ロックの取得が試行されます。取得できなかった場合、エラーは発生しませんが、現在のバージョンは圧縮されません。
create_savepointパラメータをtrueに設定してMergeTableプロシージャおよびMergeWorkspaceプロシージャが実行される場合、適用される親作業領域のロックはSSX(共有半排他)ロックです。
表1-4 操作および作業領域の種類別の互換性のないアクセス制限モード
| 操作 | 親作業領域 | 互換性のないアクセス制限モード | 現行の作業領域 | 互換性のないアクセス制限モード | 複数の親を持つ中間作業領域 | 互換性のないアクセス制限モード |
|---|---|---|---|---|---|---|
|
DML |
なし |
N/A |
共有 |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION、 WM_ONLY |
なし |
N/A |
|
なし |
N/A |
共有半排他 |
DEFERRED_REMOVAL |
なし |
N/A |
|
|
共有 |
N/A |
共有半排他 |
DEFERRED_REMOVAL、 NO_ACCESS、 ONEWRITER、 ONEWRITER_SESSION、 READ_ONLY |
排他 |
NO_ACCESS、 ONEWRITER、 ONEWRITER_SESSION、 READ_ONLY |
|
|
なし |
N/A |
共有半排他 |
DEFERRED_REMOVAL |
なし |
N/A |
|
|
なし |
N/A |
共有 |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
なし |
N/A |
|
|
なし |
N/A |
共有 |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
なし |
N/A |
|
|
なし |
N/A |
共有 |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
なし |
N/A |
|
|
なし |
N/A |
共有(新規バージョンを作成する必要がある場合は共有半排他) |
DEFERRED_REMOVAL、 NO_ACCESS |
なし |
N/A |
|
|
なし |
N/A |
共有(新規バージョンを作成する必要がある場合は共有半排他) |
DEFERRED_REMOVAL、 NO_ACCESS |
なし |
N/A |
|
|
なし |
N/A |
排他 + |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
なし |
N/A |
|
|
なし |
N/A |
共有 |
DEFERRED_REMOVAL、 NO_ACCESS |
なし |
N/A |
|
|
なし |
N/A |
共有半排他 |
DEFERRED_REMOVAL |
なし |
N/A |
|
|
なし |
N/A |
半共有 |
DEFERRED_REMOVAL、 NO_ACCESS脚注1 |
なし |
N/A |
|
|
なし |
N/A |
共有半排他 |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
なし |
N/A |
|
|
なし |
N/A |
共有 |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
なし |
N/A |
|
|
MergeTable (remove_data=>false) |
共有 |
NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
半排他 |
DEFERRED_REMOVAL、 NO_ACCESS |
半排他 |
NO_ACCESS |
|
MergeTable (remove_data=>true) |
共有 |
NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
半排他 |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
半排他 |
NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
|
MergeWorkspace (remove_workspace=>false) |
共有(1) |
NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
共有半排他 |
DEFERRED_REMOVAL、 NO_ACCESS |
排他 |
NO_ACCESS |
|
MergeWorkspace (remove_workspace=>true) |
共有(1) |
NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
排他 + |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
排他 + |
NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
|
なし |
N/A |
なし。排他モードで表をロック |
なし |
なし |
N/A |
|
|
共有(1) |
NO_ACCESS |
共有 |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
共有 |
NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
|
|
共有(1) |
NO_ACCESS |
共有 |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
排他 |
NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
|
|
なし |
N/A |
排他 + |
N/A |
なし |
N/A |
|
|
共有(1) |
N/A |
排他 + |
NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
共有 |
N/A |
|
|
なし |
N/A |
排他 + |
DEFERRED_REMOVAL NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
なし |
N/A |
|
|
なし |
N/A |
排他 + |
DEFERRED_REMOVAL NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
なし |
N/A |
|
|
なし |
N/A |
共有半排他 |
DEFERRED_REMOVAL |
なし |
N/A |
|
|
なし |
N/A |
共有半排他 |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
なし |
N/A |
|
|
なし |
N/A |
共有半排他 |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
なし |
N/A |
|
|
なし |
NO_ACCESS |
半共有 |
DEFERRED_REMOVAL、 NO_ACCESS |
なし |
N/A |
|
|
なし |
N/A |
半共有 |
DEFERRED_REMOVAL、 NO_ACCESS |
なし |
N/A |
|
|
なし |
N/A |
半共有 |
DEFERRED_REMOVAL、 NO_ACCESS |
なし |
N/A |
|
|
なし |
N/A |
共有半排他 |
DEFERRED_REMOVAL、 NO_ACCESS |
なし |
N/A |
|
|
なし |
N/A |
共有半排他 |
DEFERRED_REMOVAL、 NO_ACCESS |
なし |
N/A |
|
|
なし |
N/A |
共有半排他 |
DEFERRED_REMOVAL |
なし |
N/A |
|
|
なし |
N/A |
共有 |
DEFERRED_REMOVAL、 NO_ACCESS、 READ_ONLY、 ONEWRITER、 ONEWRITER_SESSION |
なし |
N/A |
脚注1
LIVE作業領域はNO_ACCESSモードにアクセス制限できません。
親トピック: Workspace Managerでのロック管理
1.4 Workspace Managerでの権限管理
Workspace Managerには、標準のOracleデータベース権限とは別の一連の権限があります。
Workspace Managerの作業領域レベルの権限(xxx_WORKSPACEという形式の名前)により、ユーザーは指定した作業領域を操作でき、システムレベルの権限(xxx_ANY_WORKSPACEという形式の名前)によって、ユーザーはあらゆる作業領域を操作できます。
表1-5に、Workspace Managerの権限を示します。
表1-5 Workspace Managerの権限
| 権限 | 説明 |
|---|---|
|
|
指定された作業領域に移動できます。その他のすべての権限には、 |
|
|
任意の作業領域に移動できます。その他のすべての権限には、 |
|
|
指定された作業領域内で子作業領域を作成できます。 |
|
|
任意の作業領域内で子作業領域を作成できます。 |
|
|
指定された作業領域へのアクセスを制限したりアクセス制限を解除したりできます。 |
|
|
任意の作業領域へのアクセスを制限したりアクセス制限を解除したりできます。 |
|
|
当該作業領域に対する権限を他のユーザーに付与できます。 |
|
|
任意の作業領域に対する権限を他のユーザーに付与できます。 |
|
|
指定された作業領域内の変更を、その親作業領域にマージできます。 |
|
|
任意の作業領域内の変更を、その親作業領域にマージできます。 |
|
|
指定された作業領域を削除できます。 |
|
|
任意の作業領域を削除できます。 |
|
|
指定された作業領域内の変更をロールバックできます。 |
|
|
任意の作業領域内の変更をロールバックできます。 |
|
|
Grant Option付きのWorkspace Manager関連の権限がすべてユーザーに付与されます。 |
各権限は、Grant Optionの有無にかかわらず付与できます。Grant Optionによって、権限が付与されたユーザーはその権限を他のユーザーに付与できます。
WM_ADMINシステム権限には、Grant Optionが付いたすべてのWorkspace Manager権限があります。デフォルトでは、WM_ADMINシステム権限はWM_ADMIN_ROLEに付与されます。このロールは、データベース管理者(DBAロール)に付与されます。そのため、どのユーザーにどの権限を付与するかを決定した後で、DBAにそれらの権限を付与させるか、またはDBAにWM_ADMIN_ROLEロールを1人以上の選択されたユーザーに付与させた後で、これらのユーザーから権限を付与させます。
GrantWorkspacePriv プロシージャおよびGrantSystemPrivプロシージャは、それぞれ作業領域レベルの権限およびシステム・レベルの権限を付与するために使用します。
RevokeWorkspacePriv プロシージャおよびRevokeSystemPriv プロシージャは、それぞれ作業領域レベルの権限およびシステム・レベルの権限を取り消すために使用します。これらのプロシージャを使用するには、指定された権限を指定されたユーザーから取り消すための十分な権限が必要です。権限を付与したユーザーは、その権限を取り消すことができます。
親トピック: Workspace Managerの概要
1.5 Workspace Managerのシステム・パラメータ
Workspace Managerには、WM_ADMINシステム権限を持つユーザーがデータベースに対してWorkspace Manager固有のグローバル設定を適用できるようにする一連のシステム・パラメータがあります。
WM_ADMINシステム権限の詳細は、「Workspace Managerでの権限管理」を参照してください。これらのWorkspace Managerシステム・パラメータは、Oracle初期化パラメータではありません。Workspace Managerシステム・パラメータを設定する唯一の方法は、SetSystemParameterプロシージャを使用する方法です。詳細は、「DBMS_WMパッケージ: リファレンス」を参照してください。
システム・パラメータを設定するには、SetSystemParameterプロシージャを使用します。現在のシステム・パラメータ設定を取得するには、GetSystemParameterプロシージャを使用します。これらのプロシージャの詳細は、「DBMS_WMパッケージ: リファレンス」を参照してください。
次の表に、Workspace Managerのシステム・パラメータを示します。
表1-6 Workspace Managerのシステム・パラメータ
| パラメータ名 | 値 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
連続的にリフレッシュされない作業領域の作成に適用されます。
|
|
|
既存の作業領域の名前。これは、データベースに初めて接続するときにユーザーが配置されるデフォルト作業領域を示します。これは、GotoWorkspaceプロシージャが明示的に実行されるまで、すべての問合せおよびDML操作に使用される作業領域です。デフォルトは |
|
|
|
|
|
|
|
|
|
|
|
1から1000の数値に設定して、 |
|
|
RemoveWorkspaceプロシージャおよびRemoveWorkspaceTreeプロシージャの
|
|
|
|
|
|
MergeTable操作、MergeWorkspace操作またはRefreshWorkspace操作の実行中に、行を選択してメモリーに取り込むために使用するメモリーの最大容量を示す数値(バイト単位)。デフォルトは8388608(8MB)です。Workspace Managerはこの値を使用して、一度にフェッチする行の最適な数を確認します。この値は、他のデータベース・プロセスに使用されるメモリー容量には影響しません。内部の作業領域操作にのみ影響します。 |
|
|
|
|
|
このパラメータは、これ以降にバージョン対応にする表にのみ影響します。既存のバージョン対応表のビューには影響しません。既存のバージョン対応表のビューを変更するには、AlterVersionedTableプロシージャを使用して、 |
|
|
|
親トピック: Workspace Managerの概要
1.6 インポートおよびエクスポートの考慮点
Workspace Managerでは、完全なデータベースのインポートおよびエクスポート、Workspace Managerで必要なスキーマのみのインポートおよびエクスポート、Workspace Managerのプロシージャによる作業領域レベルのインポートおよびエクスポートのいずれかで、バージョン対応表をインポートおよびエクスポートできます。
その他のエクスポート・モード(単一スキーマ、表、パーティション・レベルなど)は、現在サポートされていません。
バージョン対応データベースには、Oracleユーティリティを使用した全データベースのインポート操作およびエクスポート操作を実行できます。ただし、その場合は、次の考慮点および制限事項が適用されます。
-
バージョン対応表を含むデータベースは、Workspace Managerをインストール済で、現在バージョン対応表または作業領域(
LIVE作業領域以外)がない他のOracleデータベースにのみ、エクスポートできます。 -
Oracle Data Pump Importユーティリティによるインポート操作の場合、ダンプ・ファイルにWMSYSスキーマが含まれているときは、
table_exists_action=truncateを指定する必要があります。ダンプ・ファイルにWMSYSスキーマが含まれていない場合、インポートされるバージョン対応表がまだ存在しないか空であるときは、table_exists_action=appendを指定できます。(一般に、Oracle Databaseリリース10.2以上によって生成されるダンプ・ファイルにはWMSYSスキーマが含まれず、それより前のリリースによって生成されるダンプ・ファイルにはWMSYSスキーマが含まれます。)ダンプ・ファイルは、互換性のあるバージョンのWorkspace Managerによって生成される必要があります。一般に、
VERSION=12を指定して作成されたダンプ・ファイルはサポート対象になります。 -
データ・ポンプ・インポートを使用している場合は、データ・ポンプ・エクスポートを使用してダンプ・ファイルが作成されている必要があります。
-
データ・ポンプ・インポート・ユーティリティの
REMAP_SCHEMA機能は、バージョン対応データベースではサポートされていません。 -
Workspace Managerでは、このモードでの元のImportユーティリティとExportユーティリティの使用はサポートされていません。
Workspace Managerのインポート操作またはエクスポート操作を実行する場合は、SYSスキーマを使用しないでください。
次のように、(完全ではなく)限定的なエクスポートおよびインポートを実行できます。限定的なエクスポートおよびインポートでは、バージョン対応表と作業領域に関連するすべてのスキーマと、Workspace Managerメタデータが含まれますが、その他のスキーマはすべて除外されます。
-
Export_Schemasプロシージャをコールし、必要なオブジェクトとデータを含むダンプ・ファイルを生成します。
-
Import_Schemasプロシージャをコールします。(全データベースのインポートと同様に、Workspace Managerがすでにインストールされている必要があります。また、
LIVE作業領域以外の既存の作業領域やバージョン対応表がないようにしてください。)
作業領域レベルのエクスポート操作では、各バージョン対応表を作業領域レベルでエクスポートできます。1つのデータベースから他データベースへバージョン対応表をエクスポートするステップは、次のとおりです。
-
Exportプロシージャをコールして、ステージング表(たとえば、
t1)へエクスポートする必要があるすべてのデータを格納します。特定の作業領域、セーブポイントまたは時点から参照できるすべてのデータ、または特定の作業領域内で修正されたデータのみをエクスポートできます。詳細は、「DBMS_WMパッケージ: リファレンス」のExportプロシージャを参照してください。注:
有効期間のサポートを伴う表(WM_PERIOD型の_VALID列を含む表)は、Exportプロシージャではサポートされていません。(有効期間のサポートの詳細は、「Workspace Managerの有効期間のサポート」を参照してください。)
バージョン対応表に対して複数の作業領域をエクスポートするには、Exportプロシージャを再度コールして、元のステージング表およびエクスポートする必要がある新規作業領域を指定します。バージョン非対応の表にデータをインポートする場合、
versioned_dbパラメータにFALSEを指定します。 -
Oracle Data Pump Exportユーティリティまたは元のExportユーティリティを使用して、ステージング表(
t1など)をエクスポートします。 -
Oracle Data Pump Importユーティリティまたは元のImportユーティリティを使用して、ステージング表(
t1など)を宛先データベースにインポートします。 -
バージョン対応表へインポートする場合、Importプロシージャをコールし、ソース・データベース上にデータが常駐する作業領域、およびデータを格納する作業領域を指定して、ステージング表からバージョン対応表へデータを移動します。
ステージング表の構造は、バージョン対応表と一致する必要があります。デフォルトでは、インポート・プロシージャを正常に完了する前に、有効なすべての制約を検証する必要があります。
注:
バージョン対応トポロジをエクスポートまたはインポートする場合は、関連するDBMS_WMプロシージャ(Export_Schemas、Initialize_After_Importなど)の使用上の注意も参照してください。
親トピック: Workspace Managerの概要
1.7 バージョン対応表へのバルク・ロード
SQL*Loaderを使用するとバージョン対応表へのバルク・ロードを実行できますが、Workspace Managerの特殊プロシージャもコールする必要があり、ある程度の制限が適用されます。
最新バージョンの作業領域またはルート・バージョン(バージョン番号0のLIVE作業領域)に対して、データのダイレクト・パスによるバルク・ロードと従来型パスによるバルク・ロードの両方を実行できます。ルート・バージョンは他のすべてのバージョンの祖先であるため、ルート・バージョンのデータは他のすべての作業領域から参照可能です(LIVE以外の作業領域に更新済のデータがない場合)。
バージョン対応表に対してバルク・ロードを実行する一般ステップは、次のとおりです。
バルク・ロードによる変更をコミットすると、Workspace Managerでは必要な作業領域内およびバージョン内でデータが更新されていることが確認されます。デフォルトでは、バルク・ロードされたデータは、表に対して定義済の一意制約または参照制約に対してそれぞれチェックされ、バルク・ロードされた行のうち、いずれかの制約に違反する行はCommitBulkLoadingプロシージャのパラメータに指定した廃棄表に移動します。重複(つまり、バルク・ロードされたデータのうち主キー列に同じ値を持つレコード)の有無をチェックするように指定した場合は、重複レコードのうち最小のROWID値を持つレコードのみが表にロードされ、他のレコードは廃棄表に移動します。
現行のリリースの場合、バージョン対応表を使用したバルク・ロードには次の制限が適用されます。
-
自己参照型の整合性制約を持つ表にはバルク・ロードできません。
-
LIVEを除き、連続的にリフレッシュされる子作業領域を持つ作業領域にはバルク・ロードできません。 -
表の所有者または
WM_ADMINシステム権限が付与されているユーザーのみが、バージョン対応表へのバルク・ロードを実行できます。 -
バージョン対応表をバルク・ロードするユーザーには、<table_name>
_LTに対するINSERT権限が必要です。 -
バルク・ロード中は、バージョン対応表に対するユーザー定義トリガーは実行されません。
-
バルク・ロードされた行には、セッションのロック・モードは規定されません。この種の行をロックするにはLockRowsプロシージャを使用します。
親トピック: Workspace Managerの概要
1.8 バージョン対応表と関連するDDL操作
バージョン対応表に対してデータ定義言語(DDL)操作を実行するには、DDL操作の前後に特別なWorkspace Managerプロシージャを使用し、Workspace Managerによって作成される特別な表の名前を指定する必要があります。
表または表を参照する索引またはトリガーに対して、通常の方法でDDL操作を実行することはできません。たとえば、EMPLOYEESという名前のバージョン対応表に列を追加すると、ALTER TABLE EMPLOYEES ADD (column-name data-type)形式の文は入力できません。
これらの要件は、Workspace Managerのバージョニング・メタデータを更新して、DDL変更が反映されるようにするためのものです。そのため、バージョン対応表に影響するDDL操作の前にBeginDDLプロシージャをコールし、DDL操作の後にCommitDDLまたはRollbackDDLプロシージャをコールする必要があります。BeginDDLプロシージャは、<table-name>_LTS (Sはスケルトンを表す)形式の名前で空の一時表を作成します。実際のDDL文は、一時表<table-name>_LTSを指定する必要があり、<table-name>または<table-name>_LT 名は指定できません。The CommitDDLおよびRollbackDDLプロシージャを使用して、一時表<table-name>_LTSを削除します。
注:
有効期間のサポートを既存のバージョン対応表に追加する場合は、この手順の例外となります。有効期間のサポートを追加するには、「既存の表に対する有効期間サポートの追加」の説明に従ってAlterVersionedTableプロシージャを使用してください。
バージョン対応表と関連する次のDDL操作がサポートされています。
-
表に対する操作: 次の表プロパティの変更:
logging、pctfree、pctusedinitrans、next、minextents、maxextents、pctincrease、freelistsおよびbuffer_pool、表でのサプリメンタル・ロギングの追加および削除、表の圧縮オプションの変更 -
列に対する操作:
ADD、DROP、MODIFY(ただし、MODIFYでサポートされる操作は、列のデフォルト値の変更、NULL値のみを含む列のデータ型の変更、データ行が存在しない列のデータ型の変更、VARCHAR2、VARCHAR、CHAR、NCHAR、NVCHARまたはNVCHAR2型の列の長さの変更、NUMBER型の列の精度の変更のみです)、列名の変更。列について変更後の長さ、スケールまたは精度は、その列の既存のデータに対応できる必要があります。
-
索引に対する操作:
CREATE INDEX、DROP INDEX、ALTER INDEX(ただし、ALTER INDEXでサポートされているオプションは、logging、pctfree、initrans、initialextent、minextents、nextextent、maxextents、pctincrease、freelists、freelist groupsおよびbuffer_poolのみです)バージョン対応表の索引名が26文字を超える場合に索引名を変更するには、AlterVersionedTableプロシージャを使用する必要があります。RENAME句を指定したALTER INDEX文は使用できません。バージョン対応表の索引名が26文字以下の場合に索引名を変更するには、AlterVersionedTableプロシージャを使用する方法と、BeginDDLプロシージャとCommitDDLプロシージャのコールの間にRENAME句を指定したALTER INDEX文を使用する方法があります。詳細は、「AlterVersionedTable」の「使用上の注意」を参照してください。
-
トリガーに対する操作:
CREATE TRIGGER、DROP TRIGGER、ALTER TRIGGER ENABLE/DISABLE。 -
参照整合性制約に対する操作: 参照整合性制約の追加、削除、使用可能化、使用禁止。Workspace Managerの参照整合性のサポートの詳細は、「参照整合性のサポート」を参照してください。
-
一意制約に対する操作: 一意制約の追加、削除、使用可能化、使用禁止。Workspace Managerの一意制約のサポートの詳細は、「一意制約」を参照してください。
-
権限に関する操作: ユーザーへの表レベル権限の付与、およびユーザーからの権限の取消し。
バージョン対応表では、標準、ビットマップ、ファンクション標準、ファンクション・ビットマップ、不可視、逆およびドメインの索引を作成できます。バージョン対応表ではパーティション索引または結合索引は作成または削除できません。(ただし、パーティション索引または結合索引を持つ表をバージョン対応にすることはできます。)索引のDDL操作では、compressパラメータおよびprefix_lengthパラメータを使用できます。
どのDDL操作でも、不可視列はサポートされていません。
DDLセッションでID列が表に追加される場合、LIMIT VALUEキーワードはサポートされません。そのキーワードが指定されている場合、開始値は、skeleton _LTS表の開始値に基づいてリセットされます。
サポートされていないDDL操作を実行すると、変更は行われず、CommitDDLプロシージャによって例外が発生する場合があります。
ドメイン索引に対して、バージョン対応表が関連するDDL操作を実行する場合(たとえば、表にRツリー索引を作成する場合)は、CREATE TABLE権限が必要です。
Oracle Label Security(OLS)環境でバージョン対応表に対してDDL操作を実行する必要がある場合は、スケルトン(_LTS)表でSA_POLICY_ADMINパッケージのapply_table_policy、remove_table_policy、enable_table_policyおよびdisable_table_policyプロシージャを使用することができ、変更は、バージョン対応表に転送されます。
次の例に、COLA_MARKETING_BUDGET_LTSという名前の特別な表を使用して、COMMENTS列をCOLA_MARKETING_BUDGET表に追加する場合に必要な文を示します。この例には、列の追加を示すDESCRIBE文も含まれています。
例1-2 バージョン対応表のDDL操作
EXECUTE DBMS_WM.BeginDDL('COLA_MARKETING_BUDGET');
ALTER TABLE cola_marketing_budget_lts ADD (comments VARCHAR2(100));
DESCRIBE cola_marketing_budget_lts;
Name Null? Type
----------------------------------------- -------- ----------------------------
PRODUCT_ID NOT NULL NUMBER
PRODUCT_NAME VARCHAR2(32)
MANAGER VARCHAR2(32)
BUDGET NUMBER
COMMENTS VARCHAR2(100)
EXECUTE DBMS_WM.CommitDDL('COLA_MARKETING_BUDGET');
前述の例のALTER TABLE文には、BeginDDLプロシージャによって作成されるCOLA_MARKETING_BUDGET_LTS表が指定されています。CommitDDLプロシージャによって、COLA_MARKETING_BUDGET表に変更が適用され、COLA_MARKETING_BUDGET_LTS表が削除されます。
親トピック: Workspace Managerの概要
1.9 Workspace Managerによる制約のサポート
この項では、データベース制約の使用に関連するWorkspace Managerの考慮事項について説明します。
1.9.1 参照整合性のサポート
バージョン対応表には、CASCADEオプションおよびRESTRICTオプションを使用した制約などの参照整合性制約を定義できます。ただし、その場合は、次の考慮点および制限事項が適用されます。
-
参照整合性関係における親表がバージョン対応である場合、子表もバージョン対応である必要があります。(子表は、制約が定義されている表です。)たとえば、作成後に外部キー制約が追加された次の
EMPLOYEE表定義およびDEPARTMENT表定義があるとします(つまり、各EMPLOYEE行のdept_id値は、DEPARTMENT行の既存のdept_id値と一致する必要があります)。CREATE TABLE employee ( employee_id NUMBER, last_name VARCHAR2(32), first_name VARCHAR2(32), dept_id NUMBER); CREATE TABLE department ( dept_id NUMBER, name VARCHAR2(32); ALTER TABLE employee ADD CONSTRAINT emp_forkey_deptid FOREIGN KEY (dept_id) REFERENCES department (dept_id) ON DELETE CASCADE;
この例では、
DEPARTMENTが参照整合性関係における親、EMPLOYEEが子とみなされます。DEPARTMENTがバージョン対応である場合は、EMPLOYEEもバージョン対応である必要があります。この関係定義では、DEPARTMENT行が削除されると、EMPLOYEE表内のその子行もすべて削除されます(カスケード削除操作)。 -
参照整合性関係における子表は、その親表がバージョン対応でなくてもバージョン対応にすることができます。次の例(読みやすくするために少し編集されています)では、
ptという名前の親表とctという名前の子表を作成し、子表のj列と親表のid列との間の外部キー関係を指定して、子表をバージョン対応にします。SQL> create table pt(id integer primary key, j integer); Table created. SQL> create table ct(id integer primary key, j integer); Table created. SQL> alter table ct add foreign key(j) references pt(id); Table altered. SQL> exec dbms_wm.enableversioning('ct'); PL/SQL procedure successfully completed.参照整合性制約を追加するときに、子表がすでにバージョン対応である場合は、BeginDDLおよびCommitDDLの使用時に、子表の特別な<table-name>_LTS表を変更する必要があります。次に例を示します。
SQL> create table pt(id integer primary key, j integer); Table created. SQL> create table ct(id integer primary key, j integer); Table created. SQL> exec dbms_wm.enableversioning('ct'); PL/SQL procedure successfully completed. SQL> exec dbms_wm.beginddl('ct'); PL/SQL procedure successfully completed. SQL> alter table ct_lts add foreign key(j) references pt(id); Table altered. SQL> exec dbms_wm.commitddl('ct'); PL/SQL procedure successfully completed. -
子表の外部キーは親表の主キーを参照する必要があります。(前述の項目の例を参照してください。)
-
親表の主キーの値は更新できません。たとえば、
DEPARTMENTが親表でEMPLOYEEが子表の場合、DEPARTMENTのdepartment IDは変更できません。 -
マルチレベルの参照整合性制約はバージョン対応表に適用できます。たとえば、表
EMPLOYEE(emp_id、dept_id)に、部門IDが表DEPARTMENT(dept_id、dept_name、loc_id)に存在する必要があるという制約を適用でき、表DEPARTMENT(dept_id、dept_name、loc_id)に、位置IDが表LOCATION(loc_id、loc_name)に存在する必要があるという制約を適用できます。ただし、関連するすべての参照整合性制約がRestrictルールを伴わないかぎり、マルチレベルの参照整合性制約に関連するすべての表を、まとめてバージョン対応およびバージョン非対応にする必要があります。関連するすべての制約にRestrictルールがある場合は、表をまとめてバージョン対応にすることも、子表、親表の順で1つずつバージョン対応にすることもできます。表名は、カンマで区切ったリストとしてEnableVersioningプロシージャおよびDisableVersioningプロシージャに渡す必要があります。
Workspace Managerは、ALL_WM_RIC_INFO静的データ・ディクショナリ・ビューおよびUSER_WM_RIC_INFO静的データ・ディクショナリ・ビュー(「Workspace Managerの静的データ・ディクショナリ・ビュー」を参照)を使用して、参照整合性のサポートに関連する情報を保持します。
2つの表が関連する参照整合性制約を追加、削除、使用可能または使用禁止にする必要がある場合は、表をバージョン対応にする前に、これらの操作を実行すると便利です。ただし、次のステップを実行すると、バージョン対応表が関連する参照整合性制約を追加、削除、使用可能または使用禁止にできます。
-
親表がバージョン対応にされている場合、親表を指定してDDLセッションを開始します。
-
子表を指定して、DDLセッションを開始します。
-
子表の<table-name>_LTS表を変更して、外部キー制約を追加します。バージョン対応表が参照先表の場合は、親表の<table-name>_LTSを指定します。<table-name>_LTS表の詳細とバージョン対応表に対するDDL操作の実行の詳細は、「バージョン対応表と関連するDDL操作」を参照してください。)
-
子表を指定して、DDL変更をコミットします。
-
親表がバージョン対応にされている場合、親表を指定してDDLの変更をコミットします。
外部キー制約の追加例を例1-3に示します。EMPLOYEE表およびDEPARTMENT表はバージョン対応で、次のとおり定義されていると想定します。
EMPLOYEE(emp_id number primary key, dept_id number) DEPARTMENT(dept_id number primary key, dept_name varchar2(30))
例1-3 参照整合性制約の追加
-- Begin a DDL session on the parent table.
DBMS_WM.BeginDDL('DEPARTMENT');
-- Begin a DDL session on the child table.
DBMS_WM.BeginDDL('EMPLOYEE');
-- Add the constraint between EMPLOYEE_LTS and DAPATMENT_LTS.
ALTER TABLE employee_lts ADD CONSTRAINT employee_fk FOREIGN KEY (dept_id)
REFERENCES department_lts(dept_id);
-- Commit DDL on the child table (transfers the constraint on employee_lts
-- to employee and drops employee_lts).
EXECUTE DBMS_WM.CommitDDL('EMPLOYEE');
-- Commit DDL on the parent table (drops the department_lts table).
EXECUTE DBMS_WM.CommitDDL('DEPARTMENT');
DDLセッション中(BeginDDLプロシージャをコールした場合)、1つの表がバージョン対応で、もう1つの表がバージョン非対応の場合、2つの表が関連する参照整合性制約を追加、削除、使用可能または使用禁止にできません。両方の表が、バージョン対応である必要があります。
1.9.1.1 参照整合性制約を持つ表のDML操作でのロック
参照整合性制約を持つバージョン対応表に対してデータ操作言語(DML)操作が実行された場合、Workspace Managerは共有ロックを取得し、次の条件が規定されます。
-
子表の外部キーに影響する挿入または更新操作中は、親表での削除操作は実行できません。たとえば、
DEPARTMENTが親表、EMPLOYEEが子表の場合、新規従業員の追加中、または既存の従業員の異なる部門への割当て中に部門の削除はできません。 -
親表での削除操作中は、子表に対して外部キー列に影響する挿入または更新操作は実行できません。たとえば、部門の削除中、新規従業員の追加および既存の従業員の異なる部門へ割当てはできません。
注:
共有ロックおよび排他ロックの説明など、Workspace Managerによるロックについては、「Workspace Managerでのロック管理」を参照してください。
次のどちらかのDML操作を複数のセッションで同時に実行できます。ただし、次の両方を同時には実行できません。
-
子表の外部キー列に影響する挿入操作または更新操作。
-
親表での削除操作。
次のWorkspace Manager操作のいずれかを、複数のセッションで同時に実行できます。
-
MergeTableプロシージャを使用して、異なる作業領域で子表または親表に変更を適用します。
-
MergeTableプロシージャを使用して、1つの作業領域で子表に変更を適用し、別の作業領域で子表に挿入または更新をします。
-
MergeTableプロシージャを使用して、1つの作業領域で親表に変更を適用し、別の作業領域で親表から削除します。
次の場合、セッションは他のセッションが終了するまでブロックされます。
-
セッションが1つの作業領域で子表への変更をマージしようとしており、別のセッションが別の作業領域で親表への変更をマージしようとしている場合。
-
セッションが1つの作業領域で子表への変更をマージしようとしており、別のセッションが親表から削除しようとしている場合。
-
セッションが1つの作業領域で親表への変更をマージしようとしており、別のセッションが子表へ挿入、または子表の外部キーの値を変更しようとしている場合。
親トピック: 参照整合性のサポート
1.9.2 一意制約
一意制約が定義されている表をバージョン対応にすることができます。次の内容がサポートされています。
-
1列または複数列に対する
UNIQUE制約 -
1列または複数列の一意索引
-
表のファンクションの一意索引
NULL値の取扱いは、バージョン対応表の場合もバージョン対応でない表の場合も同じです。
Workspace Managerは、次の静的データ・ディクショナリ・ビュー(「Workspace Managerの静的データ・ディクショナリ・ビュー」を参照)を使用して、一意制約のサポートに関連する情報を保持します。
-
ALL_WM_CONSTRAINTSおよびUSER_WM_CONSTRAINTSには、バージョン対応表の一意制約の列に関する情報が含まれています。
-
ALL_WM_CONS_COLUMNSおよびUSER_WM_CONS_COLUMNSには、バージョン対応表の制約に関する情報が含まれています。
-
ALL_WM_IND_COLUMNSおよびUSER_WM_IND_COLUMNSには、バージョン対応表に対する一意制約の規定に使用される索引に関する情報が含まれています。
-
ALL_WM_IND_EXPRESSIONSおよびUSER_WM_IND_EXPRESSIONSには、バージョン対応表に対するファンクションの一意索引のファンクション式に関する情報が含まれています。
親トピック: Workspace Managerによる制約のサポート
1.9.3 SET NULL制約
SET NULL制約はWorkspace Managerでサポートされません。表がSET NULL制約を持つ場合、この制約は表がバージョン対応になったときRESTRICTオプションに変換されます。
たとえば、ON DELETE SET NULL制約はON DELETE RESTRICTへ変換されます。
親トピック: Workspace Managerによる制約のサポート
1.10 バージョン対応表に対するトリガー
バージョン対応表にはトリガーを定義できます。ただし、次の考慮点および制限事項が適用されます。
-
行レベル・トリガーのみがサポートされます。文単位のトリガーはサポートされません。
-
サポートされるコールアウトは、PL/SQLプロシージャのみです。したがって、
action_typeはPL/SQLである必要があります。
バージョン対応表でサポートされないすべてのトリガーは、バージョニングが使用可能になったときに解除され、バージョニングが使用禁止になったときにアクティブにされます。
SetTriggerEventsプロシージャを使用すると、イベントの種類を指定し、それに対して特定のユーザー定義トリガーを選択的に使用可能にすることができます。
親トピック: Workspace Managerの概要
1.11 Virtual Private Databaseの考慮事項
Workspace ManagerはOracle Virtual Private Database (VPD)テクノロジと併用できます。
Virtual Private Databaseの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。ただし、VPDでは、Workspace Managerに次の考慮事項が適用されます。
-
MergeWorkspaceなどの作業領域操作中には、行レベルのセキュリティ・ポリシーは規定されません。MergeWorkspaceのコールにより、現行のユーザーが参照できる変更のみでなく、作業領域内で行われた変更がすべてマージされます。Workspace Manager権限(
MERGE_WORKSPACEなど)を使用すると、作業領域操作を制御できます。 -
バージョン対応表に対する行レベルのセキュリティ・ポリシーは、指定の表(<table_name>)に対して定義するのみでは定義できません。かわりに、既存の<table_name>、<table_name>_LOCK、<table_name>_CONF、<table_name>_DIFFおよび<table_name>_HISTのすべてに対して、行レベルのセキュリティ・ポリシーを定義する必要があります。行レベルのセキュリティ・ポリシーを定義するときには、「バージョン対応表と関連するDDL操作」で説明されるWorkspace Manager DDLフレームワークは使用しないでください(つまり、BeginDDLプロシージャおよびCommitDDLプロシージャは使用しないでください)。
親トピック: Workspace Managerの概要
1.12 表のシノニムのサポート
Workspace Managerのプロシージャまたは表名をコールするファンクションの入力パラメータの場合、表名のかわりにシノニムを指定できます。
Workspace Managerは、次の順序で表を検索し、指定された名前と最初に一致した表を使用します。
-
指定されたスキーマ(スキーマが指定されていない場合は、ローカル・スキーマ)内にある表
-
指定されたスキーマ(スキーマが指定されていない場合は、ローカル・スキーマ)内にあるプライベート・シノニム
-
パブリック・シノニム
親トピック: Workspace Managerの概要
1.13 マテリアライズド・ビューのサポート
この項では、Workspace Managerとマテリアライズド・ビューを併用する場合の考慮事項について説明します。
バージョン対応表のマテリアライズド・ビューを作成できるのは、マテリアライズド・ビューの作成時に完全リフレッシュ方式(REFRESH COMPLETE)を指定する場合のみです。CREATE MATERIALIZED VIEW文には次の句を指定できません。
-
FAST(増分リフレッシュ) -
ON COMMIT -
FOR UPDATE
マテリアライズド・ビューまたはその実表はバージョン対応にできません。
マテリアライズド・ビューを作成する場合、その内容は作成時点のセッションの作業領域に基づきます。マテリアライズド・ビューをリフレッシュする場合、その内容はDBMS_MVIEW.REFRESH操作の実行時のセッションの作業領域に基づきます。マテリアライズド・ビューを作成またはリフレッシュすると、すべての作業領域に同じデータが表示されます。
親トピック: Workspace Managerの概要
1.14 Spatial and Graphトポロジ・サポート
この項では、Oracle Spatial and Graphトポロジの表でWorkspace Managerを使用する際の特別な考慮事項と手法について説明します。
トポロジの詳細は、『Oracle Spatial and Graphトポロジ・データ・モデルおよびネットワーク・データ・モデル・グラフ開発者ガイド』を参照してください。
トポロジは、フィーチャー表と、<topology-name>_NODE$、<topology-name>_EDGE$、<topology-name>_FACE$、<topology-name>_RELATION$および<topology-name>_HISTORY$形式の名前を持つ表で構成されています。トポロジ表をバージョン対応表にする場合は、そのトポロジに関連付けられている表をすべてバージョン対応にする必要があります。そのためには、EnableVersioningプロシージャのtable_nameパラメータにトポロジ名を指定し、isTopologyパラメータをTRUEに設定する必要があります。次に例を示します。
EXECUTE DBMS_WM.EnableVersioning(table_name => 'xyz_topo', isTopology => TRUE);
この例では、xyz_topoトポロジをバージョン対応にしています。つまり、xyz_topoトポロジに関連付けられているフィーチャー表すべてと、XYZ_TOPO_NODE$、XYZ_TOPO_FACE$、XYZ_TOPO_EDGE$、XYZ_TOPO_RELATION$およびXYZ_TOPO_HISTORY$の各表がバージョン対応になります。
バージョン対応トポロジには、1つ以上のフィーチャー表が必要です。
トポロジ表のバージョニングを使用禁止にするには、DisableVersioningプロシージャのtable_nameパラメータにトポロジ名を指定し、isTopologyパラメータをTRUEに設定して、そのトポロジに関連付けられている表すべてのバージョニングを使用禁止にする必要があります。
ただし、トポロジ表をバージョン対応またはバージョン非対応にする操作に関する前述のガイドラインには、次の例外があります。
-
トポロジのフィーチャー表が、そのトポロジにない表との
CASCADEオプションが指定されている参照整合性制約の子表である場合 -
トポロジのフィーチャー表が、そのトポロジにない表を含む参照整合性制約の親表である場合
この2つの場合は、フィーチャー表を個別にバージョン対応またはバージョン非対応にする必要があります。つまり、最初にフィーチャー表(および参照整合性制約で要求される表)に対してEnableVersioningまたはDisableVersioningプロシージャをコールしてから、トポロジ名を指定してEnableVersioningまたはDisableVersioningプロシージャをコールします。
1.14.1 トポロジ使用時のロックに関する考慮事項
トポロジに関連付けられている行をロックまたはロック解除するには、LockRowsまたはUnlockRowsプロシージャのtable_nameパラメータにトポロジ名を指定し、Xmin、Ymin、XmaxおよびYmaxパラメータを使用して、その行を含むウィンドウを識別する必要があります。また、where_clauseパラメータは指定できません。次に例を示します。
EXECUTE DBMS_WM.LockRows (workspace => 'ws1', table_name => 'xyz_topo', Xmin => 0.1, Ymin => 0.1, Xmax => 0.5, Ymax => 0.5 );
この例では、指定のウィンドウに含まれる指定のトポロジの行すべてにバージョン・ロックが適用されます。作業領域(LIVE作業領域を含む)内でトポロジの要素を編集するステップは、次のとおりです。
-
LockRowsプロシージャをコールして、対象ウィンドウに含まれるトポロジの要素すべてにバージョン・ロックを適用します。
-
同じ対象ウィンドウに対して、Oracle Spatial and Graph Topology Javaクライアントの
loadWindowメソッドをコールします。
親トピック: Spatial and Graphトポロジ・サポート
1.14.2 トポロジ使用時のその他の考慮事項
Workspace ManagerをSpatial and Graphトポロジとともに使用する場合は、さらに次の考慮事項が適用されます。
-
トポロジに関連付けられている表をバージョン対応にする前に、そのトポロジに対して少なくとも1回はSDO_TOPO.INITIALIZE_METADATAプロシージャをコールする必要があります。(SDO_TOPO.INITIALIZE_METADATAプロシージャは、トポロジをバージョン対応にした後も必要に応じてコールできます。)
-
トポロジに関連付けられているバージョン対応表では、MergeTable、RefreshTableまたはRollbackTableプロシージャを使用しないでください。トポロジに関連付けられている表のマージ、リフレッシュまたはロールバックには、かわりにMergeWorkspace、RefreshWorkspaceまたはRollbackWorkspaceプロシージャを使用してください。
親トピック: Spatial and Graphトポロジ・サポート
1.15 Workspace Managerの予約語および予約文字
Workspace Managerは内部オブジェクトの作成に固有の命名規則を使用するため、ある種のオブジェクトの名前では、避ける必要のある語や文字があります。
表1-7に、オブジェクトの種類と、それらの名前に適用される制限を示します。(「バージョン対応表のインフラストラクチャ」の表1-2に記載されている名前の長さに関するガイドラインも参照してください。)
表1-7 Workspace Managerの予約語および予約文字
| オブジェクト | 名前に使用できない文字(列) |
|---|---|
|
作業領域 |
|
|
バージョン対応表の列 |
|
|
バージョン対応表の索引 |
索引が存在する表の名前に応じた、 |
親トピック: Workspace Managerの概要
1.16 DBMS_WMサブプログラムのカテゴリ
Workspace ManagerのApplication Program Interface(API)は、単一のPL/SQLパッケージDBMS_WMにあるPL/SQLサブプログラム(プロシージャおよびファンクション)で構成されています。
各サブプログラムは、この項で説明するカテゴリに論理的にグループ化できます。
注:
ほとんどのWorkspace Managerサブプログラムはプロシージャですが、ファンクションもあります。(ファンクションは値を戻しますが、プロシージャは値を戻しません。)
ほとんどのファンクションの名前は、Get で始まります(GetConflictWorkspaceおよびCreateSavepoint など)。
すべてのサブプログラムのリファレンス情報については、「DBMS_WMパッケージ: リファレンス」を参照してください。
親トピック: Workspace Managerの概要
1.16.1 表管理サブプログラム
表管理サブプログラムは、表に対する作業領域管理を使用可能および使用禁止にし、その他の表関連操作を実行します。
表1-8に、表の管理に使用できるサブプログラムを示します。
表1-8 表管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
表をバージョン対応にし、表が複数バージョンの行をサポートできるように、必要な構造を作成します。 |
|
|
バージョン対応表内に作成された行のサポート構造をすべて削除します。 |
|
|
EnableVersioningプロシージャまたはSetWoOverwriteONプロシージャによって使用可能になった |
|
|
SetWoOverwriteOFFプロシージャによって使用禁止になった |
|
|
指定された表に対してDDLセッションを開始します。 |
|
|
DDLセッション中に指定された表に対して行われたDDL変更をコミットし、DDLセッションを終了します。 |
|
|
DDLセッション中に指定された表に対して行われたDDL変更をロールバックし(取り消し)、DDLセッションを終了します。 |
|
|
Workspace Managerの移行プロシージャが正常に実行されなかった場合、一貫性のない状態になっている表の移行プロセスを完了しようとします。 |
|
|
Workspace Managerの移行プロシージャが正常に実行されなかった場合、一貫性のない状態になっているすべての表の移行プロセスを完了しようとします。 |
|
|
バージョン対応表内のラージ・オブジェクト(LOB)列(BLOB、CLOBまたはNCLOB)を変更します。 |
|
|
バージョン対応表からステージング表にデータ(すべての行、または複数のパラメータの組合せで限定された行)をエクスポートします。 |
|
|
ステージング表から指定の作業領域内のバージョン対応表に、データ(すべての行、または複数のパラメータの組合せで限定された行)をインポートします。 |
親トピック: DBMS_WMサブプログラムのカテゴリ
1.16.2 作業領域管理サブプログラム
作業領域管理サブプログラムは、作業領域に対する操作を実行します。
表1-9に、作業領域の管理に使用できるサブプログラムを示します。
表1-9 作業領域管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
データベース内に新しい作業領域を作成します。 |
|
|
現行のセッションを指定された作業領域に移動します。 |
|
|
2つのセーブポイントまたは2つの作業領域間のバージョン対応表における値の差異を検索します。差異を記述する行を様々なビューに作成します。 |
|
|
SetDiffVersions操作が実行されたセッションの作業領域とセーブポイントのペアの名前を戻します。 |
|
|
作業領域内の表(すべての行、または |
|
|
作業領域内のすべての変更をその親作業領域に適用します。また、オプションで、その作業領域を削除できます。 |
|
|
作業領域内のバージョン対応表に対するすべての変更を廃棄します。 |
|
|
作業領域内の指定された表(すべての行、または |
|
|
指定されたセーブポイント以降に行われた作業領域内のバージョン対応表に対するすべての変更を廃棄します。 |
|
|
作業領域に対し、その親作業領域内の表(すべての行、または |
|
|
作業領域に対し、その親作業領域内のすべての変更を適用します。 |
|
|
作業領域の定義を変更します。 |
|
|
連続的にリフレッシュされない作業領域を連続的にリフレッシュされるように変更します。 |
|
|
作業領域に関連付けられたすべての行バージョンを廃棄し、作業領域を削除します。 |
|
|
作業領域およびその子作業領域に関連付けられたすべての行バージョンを廃棄し、影響を受ける作業領域を削除します。 |
|
|
作業領域へのアクセスおよび作業領域内で変更を行うユーザーの権限を制限します。 |
|
|
作業領域にアクセスできるようにし、また作業領域に対する変更を有効にし、FreezeWorkspaceプロシージャによる処理を元に戻します。 |
|
|
作業領域内の削除可能なセーブポイントを削除し、その作業領域のWorkspace Managerメタデータ構造を最小化します。 |
|
|
作業領域およびそのすべての子作業領域内の削除可能なセーブポイントを削除します。また、影響を受ける作業領域のWorkspace Managerメタデータ構造を最小化し、セーブポイントの削除によって不要となったデータを排除します。 |
|
|
作業領域内にアクティブなセッションがあるかどうかを確認します。 |
|
|
セッションの現行の作業領域を戻します。 |
|
|
指定された作業領域(1つまたは複数)をバージョン対応表の複数作業領域ビューで表示します。 |
|
|
バージョン対応表の複数作業領域ビューで参照できる作業領域の名前を戻します。 |
|
|
現行のセッションに対する現行の操作のコンテキストを戻します。 |
|
|
複数の親を持つ作業領域環境で、作業領域を子作業領域に親作業領域として追加します。 |
|
|
複数の親を持つ作業領域環境で、作業領域を親作業領域として削除します。 |
親トピック: DBMS_WMサブプログラムのカテゴリ
1.16.3 セーブポイント管理サブプログラム
セーブポイント管理サブプログラムは、セーブポイントに関連する操作を実行します。
表1-10に、セーブポイントの管理に使用できるサブプログラムを示します。
表1-10 セーブポイント管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
現行バージョンのセーブポイントを作成します。 |
|
|
現行の作業領域内の指定されたセーブポイントに移動します。 |
|
|
現行の作業領域内の指定された日付および時刻またはそれに近い時点のセーブポイントに移動します。 |
|
|
現行の作業領域およびセッション・コンテキストに関する情報を取得します。セッションの現行のセーブポイントまたはある時点を検索する場合に有効です。 |
|
|
セーブポイントの定義を変更します。 |
|
|
バージョン対応表内のセーブポイントおよび関連する行を削除します。 |
親トピック: DBMS_WMサブプログラムのカテゴリ
1.16.4 権限管理サブプログラム
権限管理サブプログラムは、Workspace Managerの権限の付与および取消しを行います。
表1-11に、権限の管理に使用できるサブプログラムを示します。
表1-11 権限管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
ユーザー、ロールまたは |
|
|
ユーザーおよびロールから作業領域レベルの権限を取り消します。 |
|
|
ユーザー、ロールまたは |
|
|
ユーザーおよびロールからシステム・レベルの権限を取り消します。 |
|
|
指定された作業領域に対して現行のユーザーが取得しているすべての権限のリストを戻します。このリストでは、権限がカンマで区切られます。 |
親トピック: DBMS_WMサブプログラムのカテゴリ
1.16.5 ロック管理サブプログラム
ロック管理サブプログラムは、Workspace Managerのロック操作を制御します。
表1-12に、ロックの管理に使用できるサブプログラムを示します。
表1-12 ロック管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
現行のセッションに対してWorkspace Managerのロック操作を使用可能にします。 |
|
|
現行のセッションに対してWorkspace Managerのロック操作を使用禁止にします。 |
|
|
指定された作業領域に対してWorkspace Managerのロック操作を使用可能にします。 |
|
|
指定された作業領域に対してWorkspace Managerのロック操作を使用禁止にします。 |
|
|
現行のセッションのロック・モードを戻します。これによって、バージョン対応行、および前回のバージョン内の対応する行にアクセスできるかどうかが決まります。 |
|
|
指定された表内のバージョン対応行、および親作業領域内のそれに対応する行へのアクセスを制御します。 |
|
|
指定された表内のバージョン対応行、および親作業領域内のそれに対応する行にアクセスできるようにします。 |
親トピック: DBMS_WMサブプログラムのカテゴリ
1.16.6 競合管理サブプログラム
競合管理サブプログラムは、作業領域間における競合を検出し、解消します。
表1-13に、競合の管理に使用できるサブプログラムを示します。
表1-13 競合管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
作業領域とその親作業領域の間に競合があるかどうかを判断します。 |
|
|
SetConflictWorkspaceプロシージャを実行したセッションの作業領域の名前を戻します。 |
|
|
競合解消セッションを開始します。 |
|
|
作業領域間における競合を解消します。 |
|
|
競合解消セッションを終了し、BeginResolveプロシージャの実行以降に作業領域内で行われたすべての変更を保存します(永続的な変更にします)。 |
|
|
競合解消セッションを終了し、BeginResolveプロシージャの実行以降に作業領域内で行われたすべての変更を廃棄します。 |
親トピック: DBMS_WMサブプログラムのカテゴリ
1.16.7 バルク・ロード・サポート・サブプログラム
バルク・ロード・サポート・サブプログラムは、バージョン対応表へのデータのバルク・ロードにSQL*Loaderを使用できるようにします。詳細は、「バージョン対応表へのバルク・ロード」を参照してください。
表1-14に、バルク・ロードのサポートに使用できるサブプログラムを示します。
表1-14 バルク・ロード・サポート・サブプログラム
| プロシージャ | 説明 |
|---|---|
|
BeginBulkLoadingプロシージャのコール時に指定するバージョン番号を戻します。 |
|
|
バージョン対応表のバルク・ロード処理を開始します。 |
|
|
バルク・ロードによる変更をコミットして、バージョン対応表のバルク・ロード処理を終了します。 |
|
|
バルク・ロード操作中にバージョン対応表に対して行われた変更をロールバックします。 |
親トピック: DBMS_WMサブプログラムのカテゴリ
1.17 Workspace Managerを使用した簡単な例
このトピックでは、Workspace Managerを使用していくつかの使用例を試行し、その1つを選択するための簡単な例を2つ示します。
それぞれの例では、複数の作業領域と1つ以上のセーブポイントを使用します。一方の例(例: 倉庫拡張のオプション)では、Oracleサンプル・スキーマ内のOE.WAREHOUSES表を使用します。
どちらの例でも、この章で説明した概念を示し、「DBMS_WMパッケージ: リファレンス」に示すプロシージャを使用します。
1.17.1 例: マーケティング予算のオプション
例1-4では、ある清涼飲料(コーラ)メーカーが4つの製品を製造し、その製品ごとにマーケティング・マネージャを配置し、マーケティング予算を計上している例を示します。1つの製品(cola_b)が市場で非常に大幅な成長が見込まれるため、この企業は、異なるマネージャや予算額を想定したwhat-if 分析を行っています。
例1-4 マーケティング予算のオプション
-------------------------------------------------------------------
-- INITIAL SET-UP
-------------------------------------------------------------------
-- Create the user for schema objects.
CREATE USER wm_developer IDENTIFIED BY password;
-- Grant regular privileges.
GRANT create session,
unlimited tablespace,
create table
TO wm_developer;
-- Grant WM-specific privileges (with grant_option = YES).
EXECUTE DBMS_WM.GrantSystemPriv ('ACCESS_ANY_WORKSPACE, MERGE_ANY_WORKSPACE,
CREATE_ANY_WORKSPACE, REMOVE_ANY_WORKSPACE, ROLLBACK_ANY_WORKSPACE',
'wm_developer', 'YES');
---------------------------------------------------------------------------
-- CREATE AND POPULATE DATA TABLE --
---------------------------------------------------------------------------
CONNECT wm_developer
-- Enter password when prompted.
-- Cleanup: remove B_focus_2 workspace if it exists from previous run.
EXECUTE DBMS_WM.RemoveWorkspace ('B_focus_2');
-- Create a table for the annual marketing budget for
-- several cola (soft drink) products.
-- Each row will contain budget data for a specific
-- product. Note: This table does not reflect recommended
-- database design. (For example, a manager ID should
-- be used, not a name.) It is deliberately oversimplified
-- for purposes of illustration.
CREATE TABLE cola_marketing_budget (
product_id NUMBER PRIMARY KEY,
product_name VARCHAR2(32),
manager VARCHAR2(32), -- Here a name, just for simplicity
budget NUMBER -- Budget in millions of dollars. Example: 3 = $3,000,000.
);
-- Version-enable the table. Specify hist option of VIEW_WO_OVERWRITE so that
-- the COLA_MARKETING_BUDGET_HIST view contains complete history information
-- about data changes.
EXECUTE DBMS_WM.EnableVersioning ('cola_marketing_budget', 'VIEW_WO_OVERWRITE');
INSERT INTO cola_marketing_budget VALUES(
1,
'cola_a',
'Alvarez',
2.0
);
INSERT INTO cola_marketing_budget VALUES(
2,
'cola_b',
'Baker',
1.5
);
INSERT INTO cola_marketing_budget VALUES(
3,
'cola_c',
'Chen',
1.5
);
INSERT INTO cola_marketing_budget VALUES(
4,
'cola_d',
'Davis',
3.5
);
COMMIT;
-- Relevant data values now in LIVE workspace:
-- 1, cola_a, Alvarez, 2.0
-- 2, cola_b, Baker, 1.5
-- 3, cola_c, Chen, 1.5
-- 4, cola_d, Davis, 3.5
---------------------------------------------------------------------------
-- CREATE WORKSPACES --
---------------------------------------------------------------------------
-- Create workspaces for the following scenario: a major marketing focus
-- for the cola_b product. Managers and budget amounts for each
-- product can change, but the total marketing budget cannot grow.
--
-- One scenario (B_focus_1) features a manager with more expensive
-- plans (which means more money taken from other products' budgets).
-- The other scenario (B_focus_2) features a manager with less expensive
-- plans (which means less money taken from other products' budgets).
--
-- Two workspaces (B_focus_1 and B_focus_2) are created as child workspaces
-- of the LIVE database workspace.
EXECUTE DBMS_WM.CreateWorkspace ('B_focus_1');
EXECUTE DBMS_WM.CreateWorkspace ('B_focus_2');
---------------------------------------------------------------------------
-- WORK IN FIRST WORKSPACE --
---------------------------------------------------------------------------
-- Enter the B_focus_1 workspace and change the cola_b manager to Beasley and
-- raise the cola_b budget amount by 1.5 to bring it to 3.0. Reduce all other
-- products' budget amounts by 0.5 to stay within the overall budget.
EXECUTE DBMS_WM.GotoWorkspace ('B_focus_1');
UPDATE cola_marketing_budget
SET manager = 'Beasley' WHERE product_name = 'cola_b';
UPDATE cola_marketing_budget
SET budget = 3 WHERE product_name = 'cola_b';
UPDATE cola_marketing_budget
SET budget = 1.5 WHERE product_name = 'cola_a';
UPDATE cola_marketing_budget
SET budget = 1 WHERE product_name = 'cola_c';
UPDATE cola_marketing_budget
SET budget = 3 WHERE product_name = 'cola_d';
COMMIT;
-- Relevant data values now in B_focus_1 workspace::
-- 1, cola_a, Alvarez, 1.5
-- 2, cola_b, Beasley, 3.0
-- 3, cola_c, Chen, 1.0
-- 4, cola_d, Davis, 3.0
-- Freeze this workspace to prevent any changes until workspace is unfrozen.
-- However, first go to the LIVE workspace, because a workspace cannot be frozen
-- if any users (including you) are in it.
EXECUTE DBMS_WM.GotoWorkspace ('LIVE');
EXECUTE DBMS_WM.FreezeWorkspace ('B_focus_1');
---------------------------------------------------------------------------
-- CREATE ANOTHER SCENARIO IN SECOND WORKSPACE --
---------------------------------------------------------------------------
-- Enter the B_focus_2 workspace and change the cola_b manager to Burton and
-- raise the cola_b budget amount by 0.5 to bring it to 2.0. Reduce only the
-- cola_d amount by 0.5 to stay within the overall budget.
EXECUTE DBMS_WM.GotoWorkspace ('B_focus_2');
UPDATE cola_marketing_budget
SET manager = 'Burton' WHERE product_name = 'cola_b';
UPDATE cola_marketing_budget
SET budget = 2 WHERE product_name = 'cola_b';
UPDATE cola_marketing_budget
SET budget = 3 WHERE product_name = 'cola_d';
COMMIT;
-- Relevant data values now in B_focus_2 workspace::
-- 1, cola_a, Alvarez, 2.0 (no change from LIVE)
-- 2, cola_b, Burton, 2.0
-- 3, cola_c, Chen, 1.5 (no change from LIVE)
-- 4, cola_d, Davis, 3.0 (same manager, new budget)
-- Create a savepoint (B_focus_2_SP1), then change scenario to
-- raise cola_b budget and reduce cola_d budget by 0.5 each.
EXECUTE DBMS_WM.CreateSavepoint ('B_focus_2', 'B_focus_2_SP1');
UPDATE cola_marketing_budget
SET budget = 2.5 WHERE product_name = 'cola_b';
UPDATE cola_marketing_budget
SET budget = 2.5 WHERE product_name = 'cola_d';
COMMIT;
-- Relevant data values now in B_focus_2 workspace:
-- 1, cola_a, Alvarez, 2.0 (no change from LIVE)
-- 2, cola_b, Burton, 2.5
-- 3, cola_c, Chen, 1.5 (no change from LIVE)
-- 4, cola_d, Davis, 2.5 (same manager, new budget)
-- Discard this scenario; roll back to row values at the time savepoint
-- B_focus_2_SP1 was created. First, though, get out of the workspace
-- so it can be rolled back (no users in it).
EXECUTE DBMS_WM.GotoWorkspace ('LIVE');
EXECUTE DBMS_WM.RollbackToSP ('B_focus_2', 'B_focus_2_SP1');
-- Go back to the B_focus_2 workspace and display current values
-- (should include budget of 2 for cola_b and 3 for cola_d).
EXECUTE DBMS_WM.GotoWorkspace ('B_focus_2');
SELECT * FROM cola_marketing_budget;
---------------------------------------------------------------------------
-- SELECT SCENARIO AND UPDATE DATABASE --
---------------------------------------------------------------------------
-- Assume that you have decided to adopt the scenario of the second
-- workspace (B_focus_2) using that workspace's current values.
-- First go to the LIVE workspace, because a workspace cannot be removed
-- or merged if any users (including you) are in it.
EXECUTE DBMS_WM.GotoWorkspace ('LIVE');
-- Unfreeze the first workspace and remove it to discard any changes there.
EXECUTE DBMS_WM.UnfreezeWorkspace ('B_focus_1');
EXECUTE DBMS_WM.RemoveWorkspace ('B_focus_1');
-- Apply changes in the second workspace to the LIVE database workspace.
-- Note that the workspace is not removed by default after MergeWorkspace.
EXECUTE DBMS_WM.MergeWorkspace ('B_focus_2');
-- Display the current data values as seen by the LIVE workspace.
SELECT * FROM cola_marketing_budget;
---------------------------------------------------------------------------
-- DISABLE VERSIONING --
---------------------------------------------------------------------------
-- Disable versioning on the table because you are finished testing scenarios.
-- Set force parameter to TRUE if you want to force the disabling even
-- if changes were made in a non-LIVE workspace.
EXECUTE DBMS_WM.DisableVersioning ('cola_marketing_budget', TRUE);親トピック: Workspace Managerを使用した簡単な例
1.17.2 例: 倉庫拡張のオプション
例1-5では、Oracleサンプル・スキーマを使用する企業で倉庫スペースの増設が必要であることが決定されています。この会社は2つの使用例を検討しようとしています。一方はTown Aに大規模倉庫を1つ建設する案、他方はTown BとTown Cに小規模倉庫を2つ建設して全体の保管能力を拡大する案です。どちらの使用例にも潜在的なメリットとデメリットがあり、それぞれに解決する必要のある財務上および法律上の課題があります。その後、この会社はそれぞれの使用例で倉庫スペースのさらなる増設が必要となる可能性があると判断したため、両方の使用例に同じ倉庫を追加する案を検討しようとしています。
例1-5では、使用例ごとに作業領域を1つ作成し、各作業領域内にセーブポイントを作成してから、新規倉庫を表に追加しています。これは、この会社が追加の倉庫を使用しないと判断する可能性があるためです。倉庫の行は、Oracleサンプル・スキーマの一部であるOE.WAREHOUSES表に格納されています。
例1-5 倉庫拡張のオプション
-------------------------------------------------------------------
-- INITIAL SET-UP
-------------------------------------------------------------------
-- Clean up from any previous running of this procedure.
DROP USER wm_developer CASCADE;
-- Create the user for schema objects.
CREATE USER wm_developer IDENTIFIED BY password;
-- Grant regular privileges.
GRANT create session,
unlimited tablespace,
create table
TO wm_developer;
-- Grant privileges on tables to be modified.
GRANT select, insert, delete, update ON oe.warehouses TO wm_developer;
GRANT select, insert, delete, update ON hr.locations TO wm_developer;
-- Grant WM-specific privileges (with grant_option = YES).
EXECUTE DBMS_WM.GrantSystemPriv ('ACCESS_ANY_WORKSPACE, MERGE_ANY_WORKSPACE,
CREATE_ANY_WORKSPACE, REMOVE_ANY_WORKSPACE, ROLLBACK_ANY_WORKSPACE',
'wm_developer', 'YES');
-- WM_ADMIN_ROLE grants the ability to version-enable a table in another schema.
GRANT wm_admin_role TO wm_developer;
-- Create rows for new locations, since a valid location ID is needed for each
-- proposed new warehouse.
INSERT INTO hr.locations VALUES
(4000, '123 Any Street', '01234', 'Town A', 'MA', 'US');
INSERT INTO hr.locations VALUES
(4100, '456 Some Street', '01235', 'Town B', 'MA', 'US');
INSERT INTO hr.locations VALUES
(4200, '789 Other Street', '01236', 'Town C', 'MA', 'US');
INSERT INTO hr.locations VALUES
(4300, '1 Yetanother Street', '01237', 'Town D', 'MA', 'US');
---------------------------------------------------------------------------
-- CREATE AND VERSION-ENABLE THE DATA TABLE --
---------------------------------------------------------------------------
CONNECT wm_developer
-- Enter password when prompted.
set echo on
set serveroutput on
-- Version-enable the OE.WAREHOUSES table. Specify hist option of
-- VIEW_WO_OVERWRITE so that the WAREHOUSES_HIST view contains
-- complete history information about data changes. However, because
-- OE.WAREHOUSES is the parent table in a referential integrity constraint
-- with OE.INVENTORIES, you must also version-enable that table.
EXECUTE DBMS_WM.EnableVersioning ('OE.WAREHOUSES, OE.INVENTORIES', hist => 'VIEW_WO_OVERWRITE');
------------------------------------------------------------------------
-- CREATE AND USE WORKSPACES --
------------------------------------------------------------------------
-- The company has decided that it needs additional warehouse space.
-- It wants to consider two scenarios: a single large warehouse in Town A,
-- and two smaller warehouses in Town B and Town C that together offer more
-- total storage capacity. There are potential advantages and disadvantages
-- to each scenario, and financial and legal issues to be resolved with each.
--
-- Later, the company decides that it might need even more warehouse
-- space under each scenario, so it wants to consider the same additional
-- warehouse in each scenario.
-- Create a workspace for each scenario, with both created as child
-- workspaces of the LIVE database workspace.
-- In workspace large_warehouse, add one row for the single large warehouse.
-- In workspace smaller_warehouses, add two rows, one for each warehouse.
--
-- Also, within each workspace create a savepoint before adding the
-- extra warehouse, because the company might decide it does not
-- need the warehouse.
EXECUTE DBMS_WM.CreateWorkspace (workspace => 'large_warehouse');
EXECUTE DBMS_WM.CreateWorkspace (workspace => 'smaller_warehouses');
-- Set up the first scenario: Go to the large_warehouse workspace and first add
-- one row for a warehouse.
EXECUTE DBMS_WM.GotoWorkspace (workspace => 'large_warehouse');
INSERT INTO oe.warehouses VALUES (10, NULL, 'Town A', 4000,
SDO_GEOMETRY(2001, 8307,
SDO_POINT_TYPE(-71.00703, 42.27099, NULL), NULL, NULL));
UPDATE oe.warehouses SET warehouse_spec = sys.xmltype.createxml(
'<?xml version="1.0"?>
<Warehouse>
<Building>Owned</Building>
<Area>100000</Area>
<Docks>2</Docks>
<DockType>Side load</DockType>
<WaterAccess>Y</WaterAccess>
<RailAccess>Y</RailAccess>
<Parking>Lot</Parking>
<VClearance>15 ft</VClearance>
</Warehouse>'
) WHERE warehouse_id = 10;
COMMIT;
-- Create a savepoint so that you can, if necessary, roll back to the point
-- before the extra warehouse was added.
EXECUTE DBMS_WM.CreateSavepoint ('large_warehouse', 'large_warehouse_add_wh');
-- Add another warehouse for this scenario.
INSERT INTO oe.warehouses VALUES (11, NULL, 'Town D', 4300,
SDO_GEOMETRY(2001, 8307,
SDO_POINT_TYPE(-71.00707, 42.35226, NULL), NULL, NULL));
UPDATE oe.warehouses SET warehouse_spec = sys.xmltype.createxml(
'<?xml version="1.0"?>
<Warehouse>
<Building>Leased</Building>
<Area>55000</Area>
<Docks>1</Docks>
<DockType>Rear load</DockType>
<WaterAccess>N</WaterAccess>
<RailAccess>N</RailAccess>
<Parking>Street</Parking>
<VClearance>10 ft</VClearance>
</Warehouse>'
) WHERE warehouse_id = 11;
COMMIT;
-- Freeze this workspace to prevent any changes until the workspace is unfrozen.
-- However, first go to the LIVE workspace, because a workspace cannot be frozen
-- if any users (including you) are in it.
EXECUTE DBMS_WM.GotoWorkspace ('LIVE');
EXECUTE DBMS_WM.FreezeWorkspace ('large_warehouse');
-- Set up the second scenario: Go to the smaller_warehouses workspace and first
-- add two rows for the smaller warehouses.
EXECUTE DBMS_WM.GotoWorkspace ('smaller_warehouses');
INSERT INTO oe.warehouses VALUES (10, NULL, 'Town B', 4100,
SDO_GEOMETRY(2001, 8307,
SDO_POINT_TYPE(-71.02439, 42.28628, NULL), NULL, NULL));
INSERT INTO oe.warehouses VALUES (11, NULL, 'Town C', 4200,
SDO_GEOMETRY(2001, 8307,
SDO_POINT_TYPE(-70.97980, 42.37961, NULL), NULL, NULL));
UPDATE oe.warehouses SET warehouse_spec = sys.xmltype.createxml(
'<?xml version="1.0"?>
<Warehouse>
<Building>Owned</Building>
<Area>60000</Area>
<Docks>1</Docks>
<DockType>Side load</DockType>
<WaterAccess>Y</WaterAccess>
<RailAccess>Y</RailAccess>
<Parking>Lot</Parking>
<VClearance>15 ft</VClearance>
</Warehouse>'
) WHERE warehouse_id = 10;
UPDATE oe.warehouses SET warehouse_spec = sys.xmltype.createxml(
'<?xml version="1.0"?>
<Warehouse>
<Building>Leased</Building>
<Area>550000</Area>
<Docks>1</Docks>
<DockType>Rear load</DockType>
<WaterAccess>N</WaterAccess>
<RailAccess>Y</RailAccess>
<Parking>Street</Parking>
<VClearance>12 ft</VClearance>
</Warehouse>'
) WHERE warehouse_id = 11;
COMMIT;
-- Create a savepoint so that you can, if necessary, roll back to the point
-- before the extra warehouse was added.
EXECUTE DBMS_WM.CreateSavepoint ('smaller_warehouses', 'smaller_warehouses_add_wh');
-- Add the extra warehouse for this scenario.
INSERT INTO oe.warehouses VALUES (12, NULL, 'Town D', 4300,
SDO_GEOMETRY(2001, 8307,
SDO_POINT_TYPE(-71.00707, 42.35226, NULL), NULL, NULL));
UPDATE oe.warehouses SET warehouse_spec = sys.xmltype.createxml(
'<?xml version="1.0"?>
<Warehouse>
<Building>Leased</Building>
<Area>55000</Area>
<Docks>1</Docks>
<DockType>Rear load</DockType>
<WaterAccess>N</WaterAccess>
<RailAccess>N</RailAccess>
<Parking>Street</Parking>
<VClearance>10 ft</VClearance>
</Warehouse>'
) WHERE warehouse_id = 12;
COMMIT;
---------------------------------------------------------------------------
-- SELECT A SCENARIO, AND APPLY IT --
---------------------------------------------------------------------------
-- Later, the company makes its decisions:
-- 1. Add two smaller warehouses.
-- 2. Do not add the extra warehouse (that is, no third new warehouse).
-- Consequently, you need to discard the first scenario (large_warehouse
-- workspace) completely, discard the warehouse addition in the second
-- scenario (roll back to smaller_warehouses_add_wh savepoint), and
-- apply the second scenario.
-- First go to the LIVE workspace, because a workspace cannot be removed
-- or merged if any users (including you) are in it.
EXECUTE DBMS_WM.GotoWorkspace ('LIVE');
-- Unfreeze the first workspace and remove it to discard any changes there.
EXECUTE DBMS_WM.UnfreezeWorkspace ('large_warehouse');
EXECUTE DBMS_WM.RemoveWorkspace ('large_warehouse');
-- Rollback the workspace for the second scenario to the savepoint created
-- before the extra warehouse was added.
EXECUTE DBMS_WM.RollbackToSP ('smaller_warehouses', 'smaller_warehouses_add_wh');
-- Apply changes in the smaller_warehouses workspace to the LIVE database
-- workspace; use the remove_workspace parameter to remove the
-- smaller_warehouses workspace after the merge.
EXECUTE DBMS_WM.MergeWorkspace ('smaller_warehouses', remove_workspace => TRUE);
-- The OE.WAREHOUSES table now has the desired data (two additional warehouses
-- from the smaller_warehouses scenario). Display the IDs and names just to be
-- sure.
SELECT warehouse_id, warehouse_name FROM oe.warehouses
ORDER BY warehouse_id;
-- Disable versioning on the table because you are finished testing scenarios.
-- Set the force parameter to TRUE to force disabling even though changes
-- were made in a non-LIVE workspace. You must also version-disable
-- the other tables previously version-enabled (along with OE.WAREHOUSES).
EXECUTE DBMS_WM.DisableVersioning ('OE.WAREHOUSES, OE.INVENTORIES', force => TRUE);
-- Clean up by deleting the rows that were added to the OE.WAREHOUSES table.
DELETE FROM oe.warehouses WHERE warehouse_id >= 10;
-- Clean up by deleting the locations that were added.
DELETE FROM hr.locations WHERE location_id >= 4000;
例1-5の終わり近くにあるSELECT文は、次の例に示すように、Town BとTown Cに新しく追加された倉庫を含め、OE.WAREHOUSES表にある倉庫のIDと名前を表示します。
SELECT warehouse_id, warehouse_name FROM oe.warehouses
ORDER BY warehouse_id;
WAREHOUSE_ID WAREHOUSE_NAME
------------ -----------------------------------
1 Southlake, Texas
2 San Francisco
3 New Jersey
4 Seattle, Washington
5 Toronto
6 Sydney
7 Mexico City
8 Beijing
9 Bombay
10 Town B
11 Town C 親トピック: Workspace Managerを使用した簡単な例