1 Workspace Managerの概要
Oracle Workspace Manager(Workspace Managerとも呼ばれる)は、作業領域を作成し、バージョンが異なる表の行の値を、異なる作業領域にグループ化できるインフラストラクチャを提供します。
ユーザーは、古いデータのコピーを保持しながら、更新するデータの新しいバージョンを作成することができます。アクティビティの結果が永続的に格納され、同時実行性および一貫性が保証されます。
Workspace Managerは、通常、次の操作を実行するアプリケーションに有効です。
-
更新および挿入を本番データに取り込む前に、これらの集合を1単位として管理する。
変更を公開する前に、変更内容をレビューして、望ましくないものをロールバックできます。変更を公開するまで、データベースの他のユーザーはそれらの変更を表示できず、通常の本番データにのみアクセスします。作業領域の単純なセットまたは複雑な作業領域階層で変更を編成できます。一般的な例として、更新の集合が本番データにマージされる前にそれらの更新を管理することで、Workspace Managerが検出および品質保証(QA)プロセスをサポートするライフサイエンス・アプリケーションなどがあります。
-
共同開発作業をサポートする。
チームは、コラボレーション可能なプロジェクトに対する更新と挿入の集合へのアクセスを共有できます。作業領域の権限により、作業領域とその操作へのアクセスが制御されます。作業領域へのアクセスを、1名の書き込みユーザー、読取り専用、またはアクセス不可に制限できます。作業領域のロックにより、個別作業領域のプロジェクト間での更新の競合を回避できます。一般的な例として、複数のサブプロジェクトが個別の作業領域で同時に開発される、エンジニアリング・プロジェクトを設計するアプリケーションなどがあります。
-
共通のデータ・セットを使用して、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のシステム・パラメータ
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トポロジのサポート
この項では、Workspace ManagerとOracle Spatial and Graphトポロジの表を使用するための特別な考慮事項および手法について説明します。 - 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では、競合が自動的に検出されます。競合は、作業領域とその親作業領域の同じ行への変更により生成されるデータ値の相違です。作業領域の変更をその親作業領域にマージする前に、競合を解消する必要があります。競合を回避するために、作業領域のロックを使用できます。
セーブポイントは、バージョン対応表の行変更をロールバックできる作業領域内のポイントで、その時点でデータベースに存在していた内容を調べることができます。通常、セーブポイントは、設計段階の完了時や支払い期限の終了時などビジネス関連指標に応じて作成されます。(セーブポイントの詳細は、セーブポイントの使用を参照してください。)
履歴オプションにより、バージョン対応表内のすべての行に加えられた変更にタイムスタンプを付けること、および各行に加えられたすべての変更または最新の変更のいずれかのコピーを保存することができます。表をバージョン対応表にするときに、(「上書きなし」履歴オプションを指定して)すべての変更を維持する場合、すべての行バージョンに加えられたすべての変更の永続的な履歴が保持され、ユーザーは、任意の時点に移動して、存在していたデータベースの状態をその作業領域の視点で表示できます。
Workspace Managerは、作業領域、セーブポイント、履歴情報、権限、アクセス・モードおよびWorkspace Managerロックを管理し、競合を検出および解消するために、新規アプリケーションおよび既存アプリケーションに追加できる総合的なPL/SQL APIを提供します。また、これらの操作のほとんどは、Oracle Enterprise 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でも同様の手順を実行しています。
特定のニーズのために子作業領域を作成するか、またはセーブポイントを作成するかの決定は、設計段階で行います。詳細は、設計面の問題: セーブポイントまたは子作業領域のいずれを作成するかを参照してください。
1.1.2 セーブポイントの使用
セーブポイントとは、データ変更をロールバックできる作業領域内のポイントです。Workspace Managerは、不要な変更が含まれている行バージョンを削除して、ロールバックを実行します。
明示的セーブポイントは、作成して名前を指定したセーブポイントです。バージョン対応表の変更は、後でセーブポイントにロールバックできます。また、セーブポイントに移動して、セーブポイントが作成された時点のデータベース全体(バージョン対応行を含む)の状態を表示することもできます。図1-2で、SP1、SP2、SP3およびSP4は、示されている作業領域で作成された明示的セーブポイントです。(図1-2では、セーブポイントは破線で示されています。)
また、新規の作業領域が作成されると、暗黙的セーブポイントが自動的に作成されます。暗黙的セーブポイントは、子作業領域のユーザーが作業領域作成時にフリーズされたデータベースのビューを取得するために必要です。したがって、図1-2では、2つの暗黙的セーブポイント(SPaおよびSPd)が、Workspace1およびWorkspace4の作成に対応するLIVE作業領域で作成され、2つの暗黙的セーブポイント(SPbおよびSPc)が、Workspace2およびWorkspace3の作成に対応するWorkspace1で作成され、1つの暗黙的セーブポイント(SPe)が、Workspace5の作成に対応するWorkspace4で作成されています。
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プロシージャを使用します。詳細は、作業領域の削除を参照してください。)
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プロシージャを実行します。
1.1.5 作業領域のフリーズおよびアンフリーズ
作業領域へのアクセス制限を設定および解除することにより、作業領域への読込みおよび書込みを制御できます。作業領域がアクセス制限されている場合は、作業領域へアクセスし、バージョン対応表内の行に変更を加えるためのユーザー権限が制限されます。作業領域へのアクセスは、アクセス不可、読取り専用、1ユーザーのみ(1WRITER)のいずれかのモードで制限できます。
作業領域へのアクセスを制限するには、FreezeWorkspaceプロシージャを使用します。作業領域へのアクセス制限を解除するには、UnfreezeWorkspaceプロシージャを使用します。
また、プロシージャによっては1つ以上の作業領域のアクセスを自動的に制限します。表1-1に、これらのプロシージャ、影響を受ける作業領域、およびアクセス制限される作業領域のモードを示します。(モードの値については、DBMS_WMパッケージ: リファレンスのFreezeWorkspaceプロシージャの説明を参照してください。)
表1-1 プロシージャのアクセス制限の結果
| プロシージャ | 作業領域およびモード |
|---|---|
|
指定された作業領域: |
|
|
指定された作業領域: 親作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: 親作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
1.1.6 作業領域の削除
作業領域は、RemoveWorkspaceプロシージャを使用して削除できます。RemoveWorkspaceを実行すると、作業領域内のデータがロールバックされ、その後、作業領域構造が削除されます。RemoveWorkspaceTreeプロシージャを使用すると、作業領域のツリー全体を削除できます。このプロシージャは、作業領域およびそのすべての子作業領域を削除します。作業領域内にユーザーがいる場合、その作業領域は削除できません。
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イベントを参照してください。
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プロシージャでは、修正が必要な表の親作業領域または子作業領域内にオープン状態のトランザクションが存在する場合、例外が発生します。
1.1.9 連続的にリフレッシュされる作業領域
連続的にリフレッシュされる作業領域とは、データ変更が親作業領域内でコミットされるか、別の子作業領域から親作業領域にマージされるたびに、親作業領域から自動的にリフレッシュされる作業領域です。連続的にリフレッシュされる作業領域の場合、RefreshWorkspaceプロシージャをコールする必要はありません。
作業領域ツリーのブランチにある作業領域は、連続的にリフレッシュできます。親作業領域が連続的にリフレッシュされるかどうかにかかわらず、子作業領域は連続的にリフレッシュされる作業領域にできます。ただし、親作業領域が連続的にリフレッシュされる作業領域である場合、その子作業領域も連続的にリフレッシュされる必要があります。
連続的にリフレッシュされる作業領域を作成するには、CreateWorkspaceプロシージャのコールでisrefreshedパラメータにTRUEを指定します。連続的にリフレッシュされる作業領域の作成に適用されるルールについては、CreateWorkspaceプロシージャの「使用上の注意」を参照してください。
連続的にリフレッシュされない作業領域を連続的にリフレッシュされるように変更するには、ChangeWorkspaceTypeプロシージャを使用します。
作業領域が連続的にリフレッシュされない場合は、親作業領域内のデータ変更を作業領域内で参照できるかどうかの確認が必要になるたびに、RefreshWorkspaceプロシージャをコールする必要があります。
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には、複数の親を持つリーフ作業領域の親作業領域の情報が含まれています。
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の識別子の長さ>)は128で、12.2未満の場合は30です。 特定のオブジェクトの長さの制限は、その<DBの識別子の長さ>(から減算される値)のオフセットとして表されます。
表1-2に、バージョン対応表および関連オブジェクトに対する名前の長さの最大値のガイドラインを示します。(特定の名前の予約語および予約文字については、Workspace Managerの予約語および予約文字の情報も参照してください。)
表1-2 Workspace Managerの名前の長さのガイドライン
| オブジェクトの型 | 名前の文字数の最大値 |
|---|---|
|
表 |
<DBの識別子の長さ> – 5 |
|
列 |
<DBの識別子の長さ> – 2 |
|
索引 |
<DBの識別子の長さ> (BeginDDLおよびCommitDDLプロシージャのコール間で索引が作成または変更された場合は<DBの識別子の長さ> — 4) |
|
トリガー |
<DBの識別子の長さ> |
|
制約 |
<DBの識別子の長さ> (BeginDDLおよびCommitDDLプロシージャのコール間で制約が作成または変更された場合は<DBの識別子の長さ> - 4) |
Workspace Managerでは、バージョン対応表に対するSQL MERGE文(あらゆる使用)と、INSERT文またはUPDATE文を含むRETURNING句はサポートされません。RETURNING句の制約の原因は、Workspace Managerによりバージョン対応表でINSTEAD OFトリガーを持つビューが作成されても、Oracle Databaseはビュー上で定義されたINSTEAD OFトリガーを持つRETURNING句をサポートしていないことにあります。
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という名前の列が含まれているとします。
例1-1がVIEW_WO_OVERWRITE履歴オプションが指定された表に対して実行された場合、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 |
作業領域1 |
U |
|
20000 |
2000 |
作業領域1 |
U |
|
30000 |
3000 |
LIVE |
U |
|
40000 |
3000 |
LIVE |
U |
|
40000 |
4000 |
LIVE |
U |
|
40000 |
4000 |
LIVE |
D |
ただし、例1-1がVIEW_W_OVERWRITEまたはNONE履歴オプションが指定された表に対して実行された場合、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 |
作業領域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 ;
1.1.13 Workspace Managerのスキーマ、メタデータおよびパッケージ
Workspace Managerは、WMSYSという名前のユーザーを作成します。WMSYSスキーマは、Workspace Managerのすべてのメタデータ情報を格納するために使用します。DBMS_WMパブリック・シノニムを持つPL/SQLパッケージには、Workspace Managerサブプログラム(プロシージャおよびファンクション)が含まれています。
PUBLICユーザー・グループには、次の権限が付与されます。
-
Workspace Managerの静的データ・ディクショナリ・ビューに対する
SELECT権限(Workspace Managerの静的データ・ディクショナリ・ビューを参照) -
DBMS_WMパッケージに対するEXECUTE権限(DBMS_WMパッケージ: リファレンスを参照)
1.2 Workspace Managerのセッション・コンテキスト情報
ユーザーは、標準のOracleセッション内でWorkspace Managerの操作を実行します。
セッションは、ユーザー・プロセスを通じたOracleインスタンスへのユーザーの固有の接続です。セッションは、ユーザーが接続してから、ユーザーが切断またはデータベース・アプリケーションを終了するまで存続します。Workspace Managerの操作を実行すると、セッション・コンテキストに関連する情報が自動的に記録されます。
セッション・コンテキスト情報には、作業領域名とコンテキスト値が含まれ、そのセッションで作業領域にどのデータを表示できるか、およびそのセッションでどの作業領域に入ることができるかが決定されます。コンテキスト値は次のいずれかです。
-
LATEST: 現在、セッションがLATESTセーブポイント(セーブポイントの使用を参照)に設定され、作業領域内で行われた変更が表示されます。セッションが作業領域に入ると(GotoWorkspaceプロシージャを使用)、コンテキストは自動的にLATESTに設定されます。 -
セーブポイント名: 現在、セッションが作業領域内のセーブポイントに設定されています。最新バージョンの作業領域で変更が行われても、セッションではこれらの変更は表示されませんが、セーブポイント作成時のデータの静的ビューが表示されます。GotoDateプロシージャがコールされた後、セッション・コンテキストはセーブポイント名に設定されます。
-
特定の時点: 現在、セッションは特定の時点に設定されています。最新バージョンの作業領域で変更が行われても、セッションではこれらの変更は表示されませんが、特定の時点におけるデータの静的ビューが表示されます。GotoDateプロシージャがコールされた後、セッション・コンテキストはある時点に設定されます。(正確な時点は、EnableVersioning プロシージャで設定されるか、あるいはSetWoOverwriteOFFプロシージャまたはSetWoOverwriteONプロシージャで変更される、変更追跡用の履歴オプションによって異なります。)
セッション・コンテキストに関する情報は、GetSessionInfoプロシージャを使用して取得できます。この情報を取得すると、GotoWorkspace操作、GotoSavepoint操作およびGotoDate操作を組み合せて実行した後など、セッションの場所(作業領域およびコンテキスト)を知る必要がある場合に有効です。
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およびそのすべての子作業領域からのみ参照できる新しい行(バージョン2)が作成されます。
ただし、この行がLIVE作業領域内でロックされていない場合、作業領域W1内のユーザーが行を更新した後でこの行に排他ロックをかけた場合、LIVE作業領域内のユーザーはこの行を更新できます。具体的には、次のようになります。
-
作業領域
W1およびそのすべての子作業領域からのみ参照できる新しい行(バージョン2)が作成されます。 -
バージョン2の行がロックされます。ロックをかけたユーザー以外の作業領域
W1内のユーザー、または作業領域W1のすべての子作業領域内のユーザーは、行を更新したり、行の新しいバージョンを作成したりできません。 -
LIVE作業領域内のバージョン0の行はロックされません。LIVE作業領域またはW1の兄弟作業領域のユーザーが行を更新すると、行の新しいバージョン(バージョン1)が作成されます。(バージョン0はロックされません。これは、このバージョンが、作業領域W1のユーザーに対して行の現行バージョンではないためです。バージョン2がその作業領域内で行の現行バージョンとなります。)
つまり、更新後の排他ロックは、作業領域ツリー内のロックされた作業領域の上位にある作業領域内の行、または作業領域ツリーの他ブランチ内の作業領域内の行の以前のバージョンをロックしません。
1.3.2 Workspace Managerの操作に対して取得されるロック
DBMS_WMサブプログラムに関連する特定の操作を実行すると、Workspace Managerは自動的にロックを取得します。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 |
なし |
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モードでアクセス制限できません。
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 プロシージャは、それぞれ作業領域レベルの権限およびシステム・レベルの権限を取り消すために使用します。これらのプロシージャを使用するには、指定された権限を指定されたユーザーから取り消すための十分な権限が必要です。権限を付与したユーザーは、その権限を取り消すことができます。
1.5 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プロシージャを使用し、 |
|
|
|
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は、このモードでの元のインポート・ユーティリティとエクスポート・ユーティリティの使用をサポートしなくなりました。
Workspace Managerのインポートまたはエクスポート操作を実行する場合、SYSスキーマは使用しないでください。
次のように、バージョン対応表および作業領域に関連するすべてのスキーマ、およびWorkspace Managerメタデータを含み、他のすべてのスキーマを含まない、(完全とは反対の)制限されたエクスポートおよびインポートを実行できます。
-
Export_Schemasプロシージャをコールして、必要なオブジェクトおよびデータを含むダンプ・ファイルを生成します。
-
Import_Schemasプロシージャをコールします。(全データベースのインポートと同様に、Workspace Managerがすでにインストールされている必要があります。また、既存のバージョン対応表および
LIVE作業領域以外の作業領域が存在していてはなりません。)
作業領域レベルのエクスポート操作では、各バージョン対応表を作業領域レベルでエクスポートできます。1つのデータベースから他データベースへバージョン対応表をエクスポートする手順は、次のとおりです。
-
Exportプロシージャをコールして、ステージング表(たとえば、
t1)へエクスポートする必要があるすべてのデータを格納します。特定の作業領域、セーブポイントまたは時点から参照できるすべてのデータ、または特定の作業領域内で修正されたデータのみをエクスポートできます。詳細は、DBMS_WMパッケージ: リファレンスのExportプロシージャに関する情報を参照してください。注意:
Exportプロシージャでは、有効期間サポートがある表(つまり、WM_PERIOD型のWM_VALIDという名前の列がある表)はサポートされません。(有効期間サポートの詳細は、Workspace Managerの有効期間のサポートを参照してください。)
バージョン対応表に対して複数の作業領域をエクスポートするには、Exportプロシージャを再度コールして、元のステージング表およびエクスポートする必要がある新規作業領域を指定します。バージョン非対応の表にデータをインポートする場合、
versioned_dbパラメータにFALSEを指定します。 -
Oracle Data Pumpエクスポート・ユーティリティまたは元のエクスポート・ユーティリティを使用して、ステージング表(たとえば、
t1)をエクスポートします。 -
Oracle Data Pumpインポート・ユーティリティまたは元のインポート・ユーティリティを使用して、ステージング表(たとえば、
t1)を宛先データベースにインポートします。 -
バージョン対応表へインポートする場合、Importプロシージャをコールし、ソース・データベース上にデータが常駐する作業領域、およびデータを格納する作業領域を指定して、ステージング表からバージョン対応表へデータを移動します。
ステージング表の構造は、バージョン対応表と一致する必要があります。デフォルトでは、インポート・プロシージャを正常に完了する前に、有効なすべての制約を検証する必要があります。
注意:
バージョン対応のトポロジのエクスポートまたはインポートについては、Export_Schemas、Initialize_After_Importなど、関連するDBMS_WMプロシージャの「使用上の注意」も参照してください。
1.7 バージョン対応表へのバルク・ロード
SQL*Loaderを使用するとバージョン対応表へのバルク・ロードを実行できますが、Workspace Managerの特殊プロシージャもコールする必要があり、ある程度の制限が適用されます。
最新バージョンの作業領域またはルート・バージョン(バージョン番号0のLIVE作業領域)に対して、データのダイレクト・パスによるバルク・ロードと従来型パスによるバルク・ロードの両方を実行できます。ルート・バージョンは他のすべてのバージョンの祖先であるため、ルート・バージョンのデータは他のすべての作業領域から参照可能です(LIVE以外の作業領域に更新済のデータがない場合)。
バージョン対応表に対してバルク・ロードを実行する一般手順は、次のとおりです。
バルク・ロードによる変更をコミットすると、Workspace Managerでは必要な作業領域内およびバージョン内でデータが更新されていることが確認されます。デフォルトでは、バルク・ロードされたデータは、表に対して定義済の一意制約または参照制約に対してそれぞれチェックされ、バルク・ロードされた行のうち、いずれかの制約に違反する行はCommitBulkLoadingプロシージャのパラメータに指定した廃棄表に移動します。重複(つまり、バルク・ロードされたデータのうち主キー列に同じ値を持つレコード)の有無をチェックするように指定した場合は、重複レコードのうち最小のROWID値を持つレコードのみが表にロードされ、他のレコードは廃棄表に移動します。
現行のリリースの場合、バージョン対応表を使用したバルク・ロードには次の制限が適用されます。
-
自己参照型の整合性制約を持つ表にはバルク・ロードできません。
-
LIVEを除き、連続的にリフレッシュされる子作業領域を持つ作業領域にはバルク・ロードできません。 -
バージョン対応表にバルク・ロードできるのは、表の所有者または
WM_ADMINシステム権限を持つユーザーのみです。 -
バージョン対応表をバルク・ロードするユーザーには、<table_name>
_LTに対するINSERT権限が必要です。 -
バルク・ロード中は、バージョン対応表に対するユーザー定義トリガーは実行されません。
-
バルク・ロードされた行には、セッションのロック・モードは規定されません。この種の行をロックするにはLockRowsプロシージャを使用します。
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、pctused、initrans、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キーワードはサポートされなくなります。このキーワードが指定されている場合、開始値は、スケルトン_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表が削除されます。
1.9 Workspace Managerによる制約のサポート
この項では、データベース制約の使用に関連するWorkspace Managerの考慮事項について説明します。
トピック:
1.9.1 参照整合性のサポート
バージョン対応表には、CASCADEオプションおよびRESTRICTオプションを使用した制約などの参照整合性制約を定義できます。ただし、その場合は、次の考慮点および制限事項が適用されます。
-
参照整合性関係の親表がバージョン対応表である場合、子表もバージョン対応表にする必要があります。(子表は、制約が定義されている表です。)たとえば、作成後に外部キー制約(つまり、各
EMPLOYEE行のdept_id値がDEPARTMENT行の既存のdept_id値に一致する必要がある)が追加された、次のEMPLOYEE表およびDEPARTMENT表の定義を考えてみます。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表のそのすべての子行も削除されます(削除操作のカスケーディング)。 -
参照整合性関係における子表は、その親表がバージョン対応でなくてもバージョン対応にすることができます。
-
子表の外部キーは親表の主キーを参照する必要があります。
-
親表の主キーの値は更新できません。たとえば、
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には、バージョン対応表に対するファンクションの一意索引のファンクション式に関する情報が含まれています。
1.10 バージョン対応表に対するトリガー
バージョン対応表には、トリガーを定義できます。ただし、その場合は、次の考慮点および制限事項が適用されます。
-
行レベル・トリガーのみがサポートされます。文単位のトリガーはサポートされません。
-
サポートされるコールアウトは、PL/SQLプロシージャのみです。したがって、
action_typeはPL/SQLである必要があります。
バージョン対応表でサポートされないすべてのトリガーは、バージョニングが使用可能になったときに解除され、バージョニングが使用禁止になったときにアクティブにされます。
SetTriggerEventsプロシージャを使用すると、イベントの種類を指定し、それに対して特定のユーザー定義トリガーを選択的に使用可能にすることができます。
1.11 Virtual Private Databaseの考慮事項
Workspace Managerは、Oracle Virtual Private Database (VPD)テクノロジとともに使用できます。
仮想プライベート・データベースの詳細は、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プロシージャは使用しないでください)。
1.12 表のシノニムのサポート
Workspace Managerのプロシージャまたは表名をコールするファンクションの入力パラメータの場合、表名のかわりにシノニムを指定できます。
Workspace Managerは、次の順序で表を検索し、指定された名前と最初に一致した表を使用します。
-
指定されたスキーマ(スキーマが指定されていない場合は、ローカル・スキーマ)内にある表
-
指定されたスキーマ(スキーマが指定されていない場合は、ローカル・スキーマ)内にあるプライベート・シノニム
-
パブリック・シノニム
1.13 マテリアライズド・ビューのサポート
この項では、Workspace Managerとマテリアライズド・ビューを併用する場合の考慮事項について説明します。
バージョン対応表のマテリアライズド・ビューを作成できるのは、マテリアライズド・ビューの作成時に完全リフレッシュ方式(REFRESH COMPLETE)を指定する場合のみです。CREATE MATERIALIZED VIEW文には次の句を指定できません。
-
FAST(増分リフレッシュ) -
ON COMMIT -
FOR UPDATE
マテリアライズド・ビューまたはその実表はバージョン対応にできません。
マテリアライズド・ビューを作成する場合、その内容は作成時点のセッションの作業領域に基づきます。マテリアライズド・ビューをリフレッシュする場合、その内容はDBMS_MVIEW.REFRESH操作の実行時のセッションの作業領域に基づきます。マテリアライズド・ビューを作成またはリフレッシュすると、すべての作業領域に同じデータが表示されます。
1.14 Spatial and Graphトポロジのサポート
この項では、Workspace ManagerとOracle Spatial and Graphトポロジの表を使用するための特別な考慮事項および手法について説明します。
トポロジの詳細は、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トポロジJavaクライアントの
loadWindowメソッドをコールします。
1.14.2 トポロジ使用時のその他の考慮事項
Workspace ManagerをSpatial and Graphトポロジで使用する場合は、次の考慮事項が追加適用されます。
-
トポロジに関連付けられている表をバージョン対応にする前に、そのトポロジに対して少なくとも1回はSDO_TOPO.INITIALIZE_METADATAプロシージャをコールする必要があります。(SDO_TOPO.INITIALIZE_METADATAプロシージャは、トポロジをバージョン対応にした後も必要に応じてコールできます。)
-
トポロジに関連付けられているバージョン対応表では、MergeTable、RefreshTableまたはRollbackTableプロシージャを使用しないでください。トポロジに関連付けられている表のマージ、リフレッシュまたはロールバックには、かわりにMergeWorkspace、RefreshWorkspaceまたはRollbackWorkspaceプロシージャを使用してください。
1.15 Workspace Managerの予約語および予約文字
Workspace Managerは内部オブジェクトの作成に固有の命名規則を使用するため、ある種のオブジェクトの名前では、避ける必要のある語や文字があります。
表1-7に、オブジェクトの種類と、それらの名前に適用される制限を示します。(バージョン対応表のインフラストラクチャの表1-2の名前の長さに関するガイドラインも参照してください。)
表1-7 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パッケージ: リファレンスを参照してください。
トピック:
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)を変更します。 |
|
|
バージョン対応表からステージング表にデータ(すべての行、または複数のパラメータの組合せで限定された行)をエクスポートします。 |
|
|
ステージング表から指定の作業領域内のバージョン対応表に、データ(すべての行、または複数のパラメータの組合せで限定された行)をインポートします。 |
1.16.2 作業領域管理サブプログラム
作業領域管理サブプログラムは、作業領域に対する操作を実行します。
表1-9に、作業領域の管理に使用できるサブプログラムを示します。
表1-9 作業領域管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
データベース内に新しい作業領域を作成します。 |
|
|
現行のセッションを指定された作業領域に移動します。 |
|
|
2つのセーブポイントまたは2つの作業領域間のバージョン対応表における値の差異を検索します。差異を記述する行を様々なビューに作成します。 |
|
|
SetDiffVersions操作が実行されたセッションの作業領域とセーブポイントのペアの名前を戻します。 |
|
|
作業領域内の表(すべての行、または |
|
|
作業領域内のすべての変更をその親作業領域に適用します。また、オプションで、その作業領域を削除できます。 |
|
|
作業領域内のバージョン対応表に対するすべての変更を廃棄します。 |
|
|
作業領域内の指定された表(すべての行、または |
|
|
指定されたセーブポイント以降に行われた作業領域内のバージョン対応表に対するすべての変更を廃棄します。 |
|
|
作業領域に対し、その親作業領域内の表(すべての行、または |
|
|
作業領域に対し、その親作業領域内のすべての変更を適用します。 |
|
|
作業領域の定義を変更します。 |
|
|
連続的にリフレッシュされない作業領域を連続的にリフレッシュされるように変更します。 |
|
|
作業領域に関連付けられたすべての行バージョンを廃棄し、作業領域を削除します。 |
|
|
作業領域およびその子作業領域に関連付けられたすべての行バージョンを廃棄し、影響を受ける作業領域を削除します。 |
|
|
作業領域へのアクセスおよび作業領域内で変更を行うユーザーの権限を制限します。 |
|
|
作業領域にアクセスできるようにし、また作業領域に対する変更を有効にし、FreezeWorkspaceプロシージャによる処理を元に戻します。 |
|
|
作業領域内の削除可能なセーブポイントを削除し、その作業領域のWorkspace Managerメタデータ構造を最小化します。 |
|
|
作業領域およびそのすべての子作業領域内の削除可能なセーブポイントを削除します。また、影響を受ける作業領域のWorkspace Managerメタデータ構造を最小化し、セーブポイントの削除によって不要となったデータを排除します。 |
|
|
作業領域内にアクティブなセッションがあるかどうかを確認します。 |
|
|
セッションの現行の作業領域を戻します。 |
|
|
指定された作業領域(1つまたは複数)をバージョン対応表の複数作業領域ビューで表示します。 |
|
|
バージョン対応表の複数作業領域ビューで参照できる作業領域の名前を戻します。 |
|
|
現行のセッションに対する現行の操作のコンテキストを戻します。 |
|
|
複数の親を持つ作業領域環境で、作業領域を子作業領域に親作業領域として追加します。 |
|
|
複数の親を持つ作業領域環境で、作業領域を親作業領域として削除します。 |
1.16.3 セーブポイント管理サブプログラム
セーブポイント管理サブプログラムは、セーブポイントに関連する操作を実行します。
表1-10に、セーブポイントの管理に使用できるサブプログラムを示します。
表1-10 セーブポイント管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
現行バージョンのセーブポイントを作成します。 |
|
|
現行の作業領域内の指定されたセーブポイントに移動します。 |
|
|
現行の作業領域内の指定された日付および時刻またはそれに近い時点のセーブポイントに移動します。 |
|
|
現行の作業領域およびセッション・コンテキストに関する情報を取得します。セッションの現行のセーブポイントまたはある時点を検索する場合に有効です。 |
|
|
セーブポイントの定義を変更します。 |
|
|
バージョン対応表内のセーブポイントおよび関連する行を削除します。 |
1.16.4 権限管理サブプログラム
権限管理サブプログラムは、Workspace Managerの権限の付与および取消しを行います。
表1-11に、権限の管理に使用できるサブプログラムを示します。
表1-11 権限管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
ユーザー、ロールまたは |
|
|
ユーザーおよびロールから作業領域レベルの権限を取り消します。 |
|
|
ユーザー、ロールまたは |
|
|
ユーザーおよびロールからシステム・レベルの権限を取り消します。 |
|
|
指定された作業領域に対して現行のユーザーが取得しているすべての権限のリストを戻します。このリストでは、権限がカンマで区切られます。 |
1.16.5 ロック管理サブプログラム
ロック管理サブプログラムは、Workspace Managerのロック操作を制御します。
表1-12に、ロックの管理に使用できるサブプログラムを示します。
表1-12 ロック管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
現行のセッションに対してWorkspace Managerのロック操作を使用可能にします。 |
|
|
現行のセッションに対してWorkspace Managerのロック操作を使用禁止にします。 |
|
|
指定された作業領域に対してWorkspace Managerのロック操作を使用可能にします。 |
|
|
指定された作業領域に対してWorkspace Managerのロック操作を使用禁止にします。 |
|
|
現行のセッションのロック・モードを戻します。これによって、バージョン対応行、および前回のバージョン内の対応する行にアクセスできるかどうかが決まります。 |
|
|
指定された表内のバージョン対応行、および親作業領域内のそれに対応する行へのアクセスを制御します。 |
|
|
指定された表内のバージョン対応行、および親作業領域内のそれに対応する行にアクセスできるようにします。 |
1.16.6 競合管理サブプログラム
競合管理サブプログラムは、作業領域間における競合を検出し、解消します。
表1-13に、競合の管理に使用できるサブプログラムを示します。
表1-13 競合管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
作業領域とその親作業領域の間に競合があるかどうかを判断します。 |
|
|
SetConflictWorkspaceプロシージャを実行したセッションの作業領域の名前を戻します。 |
|
|
競合解消セッションを開始します。 |
|
|
作業領域間における競合を解消します。 |
|
|
競合解消セッションを終了し、BeginResolveプロシージャの実行以降に作業領域内で行われたすべての変更を保存します(永続的な変更にします)。 |
|
|
競合解消セッションを終了し、BeginResolveプロシージャの実行以降に作業領域内で行われたすべての変更を廃棄します。 |
1.16.7 バルク・ロード・サポート・サブプログラム
バルク・ロード・サポート・サブプログラムは、バージョン対応表へのデータのバルク・ロードにSQL*Loaderを使用できるようにします。詳細は、バージョン対応表へのバルク・ロードを参照してください。
表1-14に、バルク・ロードのサポートに使用できるサブプログラムを示します。
表1-14 バルク・ロード・サポート・サブプログラム
| プロシージャ | 説明 |
|---|---|
|
BeginBulkLoadingプロシージャのコール時に指定するバージョン番号を戻します。 |
|
|
バージョン対応表のバルク・ロード処理を開始します。 |
|
|
バルク・ロードによる変更をコミットして、バージョン対応表のバルク・ロード処理を終了します。 |
|
|
バルク・ロード操作中にバージョン対応表に対して行われた変更をロールバックします。 |
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);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