| Oracle Database Workspace Manager開発者ガイド 11gリリース1（11.1） E05678-02 |
|
 戻る |
 次へ |
Oracle Workspace Manager（Workspace Managerとも呼ばれる）は、作業領域を作成し、バージョンが異なる表の行の値を、異なる作業領域にグループ化できるインフラストラクチャを提供します。ユーザーは、古いデータのコピーを保持しながら、更新するデータの新しいバージョンを作成することができます。アクティビティの結果が永続的に格納され、同時実行性および一貫性が保証されます。
Workspace Managerは、通常、次の操作を実行するアプリケーションに有効です。
更新および挿入を本番データに取り込む前に、これらの集合を1単位として管理する。
変更を公開する前に、内容を確認し、適切でない変更をロールバックできます。変更が公開されるまで、データベースの他のユーザーはこの変更を見ることはできず、通常の本番データへのアクセスのみが可能です。変更は、単純な一連の作業領域または複雑な作業領域階層に編成できます。たとえば、ライフサイエンス・アプリケーションなどです。このアプリケーションでは、更新が本番データにマージされる前に、Workspace Managerが更新の集合を管理することによって、検出プロセスおよび品質保証（QA）プロセスをサポートします。
共同開発作業をサポートする。
ある共同プロジェクト・チームは、共同プロジェクトのための更新および挿入の集合へのアクセスを共有できます。作業領域権限によって、作業領域および作業領域での操作へのアクセスを制御します。また、作業領域へのアクセスを1ユーザーのみ、読込み専用またはアクセス不可に制限できます。作業領域のロックによって、別々の作業領域内でのプロジェクト間の更新の競合が回避されます。たとえば、エンジニアリング・プロジェクトを設計するアプリケーションなどです。このアプリケーションでは、複数のサブプロジェクトが別々の作業領域で同時に作成されます。
共通のデータ・セットを使用して、what-if 分析用の使用例または公開するデータのコピーを複数作成する。
作業領域内の変更を編成して、データベース全体のコンテキストに表示できますが、データを実際に表の間でコピーする必要はありません。複数のユーザーが、同時に同一行に変更を加えた場合でも、競合を検出し解消できます。たとえば、通信アプリケーションでは、携帯電話のサービス区域のシナリオを複数作成し、最適な設計を判断できます。
データの変更履歴を保存する。
作業領域および行バージョンをナビゲートして、特定の指標または時点のデータベースを表示できます。作業領域内の行または表に加えられた変更は、ある指標までロールバックできます。たとえば、土地情報管理アプリケーションなどです。このアプリケーションでは、Workspace Managerは、土地区画に加えられたすべての変更履歴を保持して、法的要求事項に対応します。
Workspace Managerは、ロング・トランザクションの使用例を管理する場合にも有効です。複雑で継続時間の長いデータベース・トランザクションは、完了するまでに数日かかり、複数のユーザーが同一データベースにアクセスする必要があります。
この章では、Workspace Managerを使用するために理解しておく必要がある概念および操作について説明します。この章の内容は次のとおりです。
Workspace Managerの完全な例については、第1.17項を参照してください。ただし、その例が示す概念を理解するには、まず、この章のこれ以降の説明を読む必要があります。
|
注意: デフォルトでは、Workspace Managerは、Oracleシード・データベース、およびDatabase Configuration Assistant（DBCA）を使用して作成された任意のデータベースにインストールされます。その他のOracleデータベースでWorkspace Managerを使用するには、まず、付録A「カスタム・データベースでのWorkspace Managerのインストール」に示すインストール手順を実行してください。 |
Workspace Managerでは、データベース内の1つ以上のユーザー表をバージョン対応にすることができます。バージョン対応表では、表内のすべての行は複数バージョンのデータをサポートします。バージョニングのインフラストラクチャは、データベース・ユーザーからは見えません。また、データの選択、挿入、変更、削除を行うアプリケーションのSQL文は、通常どおり、バージョン対応表に対する処理を続けます。ただし、バージョン対応表の主キー列の値は更新できません。（Workspace Managerは、システム・ビューを保持し、INSTEAD OFトリガーを作成することによって、これらの機能を実装します。詳細は、第1.1.11項を参照してください。ただし、アプリケーション開発者およびユーザーは、ビューおよびトリガーを調べたり、対話したりする必要はありません。）
表がバージョン対応になると、作業領域内のユーザーに必要なレコードの正確なバージョンが自動的に表示されます。表をバージョン対応にする必要がなくなった場合は、表のバージョニングを使用禁止にできます。
作業領域とは、データベース内のデータに対して変更を加えるために1人以上のユーザーが共有できる仮想環境です。作業領域は、1つ以上のバージョン対応表の新しい行バージョンの集合を論理的にグループ化し、これらのバージョンが本番データと明示的にマージされるか、または廃棄されるまで切り離しておきます。そのため、最大の同時実行性が得られます。ユーザーは、作業領域に対して様々な操作（移動、作成、リフレッシュ、マージ、ロールバック、削除、圧縮、変更など）を実行できます。
ユーザーが作業領域内にいる場合は、トランザクションの一貫性を保持したデータベース全体のビューが常に表示されます。つまり、現行の作業領域で行われた変更の他に、作業領域の作成時、または親作業領域の変更によって作業領域が最後にリフレッシュされた時点でデータベースに存在したそれ以外のデータも表示されます。（作業領域階層、親作業領域および子作業領域については、第1.1.1項を参照してください。）
Workspace Managerは競合を自動的に検出します。競合とは、作業領域および親作業領域内の同一行に対する変更によるデータ値の差異です。作業領域内の変更を親作業領域にマージする前に、競合を解消する必要があります。作業領域ロックを使用すると、競合を回避できます。
セーブポイントは、バージョン対応表の行変更をロールバックできる作業領域内のポイントで、その時点でデータベースに存在していた内容を調べることができます。通常、セーブポイントは、設計段階の完了時や支払い期限の終了時などビジネス関連指標に応じて作成されます。（セーブポイントの詳細は、第1.1.2項を参照してください。）
履歴オプションは、バージョン対応表のすべての行に加えられた変更にタイムスタンプを付け、各行に加えられたすべての変更または最新の変更のみのコピーを保存できます。バージョン対応表で、すべての変更を保存する場合（without overwrite履歴オプションを指定）は、すべての行バージョンに対して行われたすべての変更の永続履歴を保存します。また、ユーザーが希望するポイントに移動して、その作業領域に存在していたデータベースを表示できるようにします。
Workspace Managerは、作業領域、セーブポイント、履歴情報、権限、アクセス・モードおよびWorkspace Managerロックを管理し、競合を検出および解消するために、新規アプリケーションおよび既存アプリケーションに追加できる総合的なPL/SQL APIを提供します。また、これらの操作のほとんどは、Oracle Enterprise ManagerのGraphical User Interface（GUI）を使用して実行することもできます。
Workspace Managerによって作成される別のデータベース・オブジェクトは、行バージョンを作業領域にマップするデータベース全体のシステム表です。この表は、ユーザーからは見えません。
データベース内には、作業領域の階層が存在する可能性があります。たとえば、1つの作業領域が1つ以上の作業領域（子作業領域）の親である可能性があります。デフォルトでは、作業領域は、最上位、つまりLIVEデータベース作業領域から作成されます。（作業領域名には大/小文字区別があり、LIVEデータベースの作業領域名の綴りはLIVEとなります。作業領域名の長さは30文字以下であり、作業領域階層の深さは30レベル以下である必要があります。）ユーザーは、GotoWorkspace操作によって作業領域内に移動します。
図1-1に、作業領域の階層を示します。この図では、作業領域1および作業領域4はLIVEデータベース作業領域から、作業領域2および作業領域3は作業領域1から、作業領域5は作業領域4から形成されています。作業領域1の作成後、作業領域1を指定してGotoWorkspace操作を実行し、次にCreateWorkspace操作を実行して作業領域2および作業領域3を作成しています。その後、作業領域4および作業領域5でも同様の手順を実行しています。
特定のニーズのために子作業領域を作成するか、またはセーブポイントを作成するかの決定は、設計段階で行います。詳細は、第1.1.2.1項を参照してください。
セーブポイントとは、データ変更をロールバックできる作業領域内のポイントです。Workspace Managerは、不要な変更が含まれている行バージョンを削除して、ロールバックを実行します。
明示的セーブポイントとは、作成して名前を付けるセーブポイントです。バージョン対応表内の変更は、後でセーブポイントまでロールバックできます。または、セーブポイントに移動して、そのセーブポイントが作成された時点でのデータベース全体の状態（バージョン対応の行を含む）を表示できます。図1-2に、作業領域内に作成された明示的セーブポイント（SP1、SP2、SP3およびSP4）を示します。（図1-2では、セーブポイントが破線で示されています。）
また、新しい作業領域が作成されるたびに、暗黙的セーブポイントが自動的に作成されます。暗黙的セーブポイントは、子作業領域内のユーザーが、作業領域の作成時にアクセス制限されたデータベースのビューを取得するために必要です。したがって、図1-2では、作業領域1および作業領域4の作成に対応してLIVE作業領域内に2つの暗黙的セーブポイント（SPaおよびSPd）が作成され、作業領域2および作業領域3の作成に対応して作業領域1内に2つの暗黙的セーブポイント（SPbおよびSPc）が作成されます。また、作業領域5の作成に対応して作業領域4内に1つの暗黙的セーブポイント（SPe）が作成されます。
Workspace Managerは、LATESTという名前を使用して、作業領域内の最新バージョンを示す論理セーブポイントを指定します。セーブポイントがDBMS_WMサブプログラム（プロシージャまたはファンクション）のオプションのパラメータであるときは、多くの場合、LATESTがデフォルトです。
削除可能なセーブポイントとは、CompressWorkspace、CompressWorkspaceTreeおよびDeleteSavepointプロシージャによって削除可能なセーブポイントです。次の条件のいずれかに該当する場合、セーブポイントは削除可能です。
明示的セーブポイントである。
子作業領域と依存性がない暗黙的セーブポイントである。
Workspace Managerでは、ある時点でプロジェクトを保存するために、セーブポイントを作成するか、子作業領域を作成するかという設計面の問題が発生する可能性があります。セーブポイントと子作業領域のいずれを使用しても、一連の変更のグループ化、異なる行バージョンの変更の比較、および一連の変更のロールバックが可能です。ただし、セーブポイントを作成すると、同一作業領域内で継続して変更を加えることができ、その作業領域内の他のユーザーがすぐに変更にアクセスできるようになります。（別の作業領域内の変更は、現行の作業領域がリフレッシュまたはマージされるまで、ユーザーには表示されません。）また、セーブポイントを作成すると、一連の変更を簡単にアーカイブできるようになります。これらの変更は、後でロールバックできます。
これに対し、子作業領域を作成すると、一連の複雑な変更を加えることができる分離された環境を提供でき、これらの変更を親作業領域（本番データなど）から完全に削除できます。あるシナリオに基づいて独立した環境を設定し、親作業領域内の通常のユーザーがこのシナリオのデータにアクセスする必要がない場合は、親作業領域内にセーブポイントを作成するかわりに、子作業領域を作成してください。
作業領域は、マージまたはロールバックできます。
作業領域のマージでは、子作業領域で行われた変更がその親作業領域に適用されます。その後、子作業領域は削除されます。作業領域をマージするには、MergeWorkspaceプロシージャを使用します。
作業領域のロールバックでは、作業領域内のすべてのデータ変更（行バージョン）、または明示的セーブポイント以降のすべての変更のいずれかが削除されます。
作業領域内のすべての変更をロールバックするには、RollbackWorkspaceプロシージャを使用します。
セーブポイント以降の作業領域内の変更をロールバックするには、RollbackToSPプロシージャを使用します。
作業領域内にオープン状態のトランザクションがある場合、その作業領域はロールバックできません。作業領域のロールバックでは、作業領域構造は後で使用するために残され、作業領域内のデータのみが削除されます。（作業領域を完全に削除するには、RemoveWorkspaceプロシージャを使用します。詳細は、第1.1.6項を参照してください。）
子作業領域がマージされると、子作業領域内の行変更がその親作業領域に取り込まれます。子作業領域がリフレッシュされると、親作業領域内の行変更が子作業領域に取り込まれます。子作業領域と親作業領域の両方で行が変更されると、データの競合が発生します。マージまたはリフレッシュ操作が要求されると、競合は自動的に検出され、競合（xxx_CONF）ビューに表示されます。表ごとに1つの競合ビューがあります。詳細は、第5.45項を参照してください。このビューには、競合が発生している2つの作業領域内の行の列値が表示されます。
競合は、セッションに対し作業領域競合のコンテキストを設定してからResolveConflictsプロシージャを使用して、手動で解消する必要があります。それぞれの競合について、子作業領域の行を保存するか、親作業領域の行を保存するか、または共通のベース行を保存するか（行の元のデータ値を保存する（変更なし））を選択できます。マージ操作（MergeWorkspace）またはリフレッシュ操作（RefreshWorkspace）を実行する前に、競合を解消する必要があります。
ベースの行は、子作業領域での最初の更新または削除操作時では、現在参照できる行です。挿入操作の場合、挿入される行が親作業領域の祖先バージョンで以前に削除されていれば、ベースの行はその削除された行ですが、それ以外では、ベースの行は存在しません。親の行は、競合解消時では、親作業領域で現在参照できる行であり、子の行は、競合解消時では、子作業領域で現在参照できる行です。
データが存在しないことは競合ではありません。この場合は、xxx_DIFFビュー（第5.46項を参照）を使用して、ある作業領域での変更を削除することができます（他の作業領域に行が存在しないか行への変更が存在しない場合のみ）。
競合の一般的な解消手順は、次のとおりです。
GotoWorkspaceプロシージャまたはSetConflictWorkspaceプロシージャを使用して、セッションに対し作業領域競合のコンテキストを設定します。
xxx_CONFビュー（第5.45項を参照）を調べて、どのような競合が存在するかを確認します。
BeginResolveプロシージャを実行します。
影響を受ける表と作業領域の組合せごとに1回、ResolveConflictsプロシージャを実行します。
すべての競合を解消した後で、次のいずれかのプロシージャを実行します。
CommitResolve: 前述の手順のすべての変更を永続的な変更にする場合。（ただし、次の手順に示すとおり、MergeWorkspaceまたはRefreshWorkspaceプロシージャを実行するまでは、データベース内の変更は永続的な変更にはなりません。）
RollbackResolve: 前述の手順のすべての変更を廃棄する場合。（すべての変更を破棄する場合、次の手順は実行しないでください。）
標準のデータベース・コミット操作を行い、MergeWorkspaceまたはRefreshWorkspaceプロシージャを実行します。
作業領域へのアクセス制限を設定および解除することにより、作業領域への読込みおよび書込みを制御できます。作業領域がアクセス制限されている場合は、作業領域へアクセスし、バージョン対応表内の行に変更を加えるためのユーザー権限が制限されます。作業領域へのアクセスは、アクセス不可、読取り専用、1ユーザーのみ（1WRITER）のいずれかのモードで制限できます。
作業領域へのアクセスを制限するには、FreezeWorkspaceプロシージャを使用します。作業領域へのアクセス制限を解除するには、UnfreezeWorkspaceプロシージャを使用します。
また、プロシージャによっては1つ以上の作業領域のアクセスを自動的に制限します。表1-1に、これらのプロシージャ、影響を受ける作業領域、およびアクセス制限される作業領域のモードを示します。（モードの値については、第4章のFreezeWorkspaceプロシージャの説明を参照してください。）
表1-1 プロシージャのアクセス制限の結果
| プロシージャ | 作業領域およびモード |
|---|---|
|
|
指定された作業領域: |
|
|
指定された作業領域: 親作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: 親作業領域: |
|
|
指定された作業領域: |
|
|
指定された作業領域: |
作業領域は、RemoveWorkspaceプロシージャを使用して削除できます。RemoveWorkspaceを実行すると、作業領域内のデータがロールバックされ、その後、作業領域構造が削除されます。RemoveWorkspaceTreeプロシージャを使用すると、作業領域のツリー全体を削除できます。このプロシージャは、作業領域およびそのすべての子作業領域を削除します。作業領域内にユーザーがいる場合、その作業領域は削除できません。
数種類のWorkspace Manager操作をイベントとして取得し、Oracle Advanced Queuing（AQ）フレームワークを介してアプリケーションに通信できます。非同期通知、永続性、伝播、アクセス制御、履歴およびルールベースのサブスクリプションなど、AQのメッセージ機能をWorkspace Managerイベントに使用できます。
Workspace Managerイベントのサポートには、ALLOW_CAPTURE_EVENTS Workspace Managerシステム・パラメータ、SetCaptureEventプロシージャおよびWM_EVENTS_INFOメタデータ・ビューが含まれています。
Workspace Managerイベントおよびアプリケーションでの使用方法については、第2章を参照してください。
デフォルトでは、Workspace Managerのほとんどの操作は、自律型データベース・トランザクションとして実行され、終了時にコミットされます。つまり、これらのトランザクションは、現行のデータベース・トランザクション内部でコールされ、コール側トランザクションのコンテキストをそのまま残し、Workspace Manager操作を実行した後、その操作を自動的にコミットし、コール側トランザクションのコンテキストに戻り、そのトランザクションを継続する独立したトランザクションです。このように動作するWorkspace Manager（DBMS_WM）サブプログラムには、オプションのauto_commitパラメータがあります。このパラメータのデフォルト値は、TRUEです。
たとえば、CompressWorkspaceプロシージャはデフォルトで自律型トランザクションを起動し、作業領域を圧縮し、圧縮操作をコミットした後、コール側トランザクションのコンテキストに戻り、現行のデータベース・トランザクションを継続します。
ただし、自律型トランザクションを起動するかわりに、コール側トランザクションのコンテキストで実行する場合は、auto_commitパラメータ値をFALSEに指定します。この場合、Workspace Manager操作は現行のデータベース・トランザクションの一部として実行されます。オープン状態の現行のトランザクションがない場合は、新しいトランザクションが起動されます。いずれの場合も、そのトランザクションがコミット操作によって終了するまで、Workspace Manager操作は有効になりません。たとえば、auto_commitパラメータをFALSEに指定してCompressWorkspaceプロシージャをコールすると、トランザクションがコミットされるまで作業領域は圧縮されません。トランザクションがロールバックされた場合、作業領域は圧縮されません。
auto_commitパラメータをFALSEに指定した場合は、トランザクションを明示的にコミットまたはロールバックする必要があることに注意してください。
auto_commitパラメータ値がTRUEで、オープン状態のトランザクションが存在する場合は、次の考慮点が適用されます。
CompressWorkspaceプロシージャおよびCompressWorkspaceTreeプロシージャでは、オープン状態のトランザクションが存在する場合、例外が発生します。
その他のすべてのWorkspace Managerプロシージャでは、修正が必要な表の親作業領域または子作業領域内にオープン状態のトランザクションが存在する場合、例外が発生します。
連続的にリフレッシュされる作業領域とは、データ変更が親作業領域内でコミットされるか、別の子作業領域から親作業領域にマージされるたびに、親作業領域から自動的にリフレッシュされる作業領域です。連続的にリフレッシュされる作業領域の場合、RefreshWorkspaceプロシージャをコールする必要はありません。
作業領域ツリーのブランチにある作業領域は、連続的にリフレッシュできます。親作業領域が連続的にリフレッシュされるかどうかにかかわらず、子作業領域は連続的にリフレッシュされる作業領域にできます。ただし、親作業領域が連続的にリフレッシュされる作業領域である場合、その子作業領域も連続的にリフレッシュされる必要があります。
連続的にリフレッシュされる作業領域を作成するには、CreateWorkspaceプロシージャのコールでisrefreshedパラメータにTRUEを指定します。連続的にリフレッシュされる作業領域の作成に適用されるルールについては、CreateWorkspaceプロシージャの「使用上の注意」を参照してください。
連続的にリフレッシュされない作業領域を連続的にリフレッシュされるように変更するには、ChangeWorkspaceTypeプロシージャを使用します。
作業領域が連続的にリフレッシュされない場合は、親作業領域内のデータ変更を作業領域内で参照できるかどうかの確認が必要になるたびに、RefreshWorkspaceプロシージャをコールする必要があります。
複数の親を持つ作業領域とは、2つ以上の親作業領域を持つ子作業領域です。作業領域は、最初は1つの親を持つ作業領域として作成されます。ただし、必要に応じて既存の作業領域に他の作業領域を親作業領域として追加し、複数の親を持つ作業領域にすることができます。複数の親を持つ作業領域では、すべての親作業領域と祖先作業領域のデータを参照でき、親作業領域とマージして親作業領域からリフレッシュできます。
図1-3は、図1-1の作業領域と同じ構造を示します。ただし、作業領域3は、作業領域1および作業領域4の2つの親を持つ作業領域である点が異なります。
複数の親を持つ作業領域を、複数の親を持つリーフ作業領域と呼ぶこともあります。したがって、図1-3では、作業領域3は複数の親を持つリーフ作業領域です。複数の親を持つリーフ作業領域のすべての親作業領域に共通して最も近い祖先を、複数の親を含むルート作業領域と呼びます。図1-3では、LIVE作業領域は作業領域3の複数の親を含むルート作業領域です。リーフ作業領域の親として親作業領域を追加することにより形成される非循環有向グラフ（DAG）では、すべての作業領域を複数の親を持つグラフ作業領域と呼びます。図1-3では、作業領域1、作業領域4および作業領域3は、複数の親を持つグラフ作業領域です。
複数の親を持つ作業領域を作成できるのは、ALLOW_MULTI_PARENT_WORKSPACE Workspace Managerシステム・パラメータがONに設定されている場合のみです。また、連続的にリフレッシュされる作業領域を複数の親を持つ作業領域にするには、CR_WORKSPACE_MODE Workspace Managerシステム・パラメータをPESSIMISTIC_LOCKINGに設定する必要があり、連続的にリフレッシュされない作業領域を複数の親を持つ作業領域にするには、NONCR_WORKSPACE_MODE Workspace Managerシステム・パラメータをPESSIMISTIC_LOCKINGに設定する必要があります。Workspace Managerシステム・パラメータの詳細は、第1.5項を参照してください。
複数の親を持つ作業領域を作成するには、AddAsParentWorkspaceプロシージャを使用します。複数の親を持つ作業領域の親である作業領域を削除するには、RemoveAsParentWorkspaceプロシージャを使用します。複数の親を持つグラフ作業領域に対する権限を付与および取り消すには、それぞれGrantGraphPrivプロシージャおよびRevokeGraphPrivプロシージャを使用します。これらのプロシージャについては、第4章を参照してください。
Workspace Managerには、複数の親を持つ作業領域に関する情報を格納するために、次の静的データ・ディクショナリ・ビュー（第5章を参照）が用意されています。
USER_MP_GRAPH_WORKSPACESおよびALL_MP_GRAPH_WORKSPACESには、複数の親を持つグラフ作業領域の情報が含まれています。
USER_MP_PARENT_WORKSPACESおよびALL_MP_PARENT_WORKSPACESには、複数の親を持つリーフ作業領域の親作業領域の情報が含まれています。
EnableVersioningプロシージャを使用して表をバージョン対応にする場合、Workspace Managerは自動的に操作を実行し、DBA以外のユーザーには表示されないがWorkspace Manager自身の機能は許可されるデータ構造を作成します。Workspace Managerによって保持される情報には、静的データ・ディクショナリ・ビュー（第5章を参照）に格納されるものと、ユーザーがアクセスできないシステム・データ構造に格納されるものがあります。
表がバージョン対応の場合、Workspace Managerはその表名を<table-name>_LTという形式に変更し、この表に数列を追加してバージョニング・メタデータを格納します。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で許可される最大値よりも短くなります。表1-2に、バージョン対応表および関連オブジェクトに対する名前の長さの最大値のガイドラインを示します。（第1.15項にある、特定の名前に対する予約語および予約文字の項も参照してください。）
Workspace Managerでは、バージョン対応表でINSERT文、MERGE文またはUPDATE文を持つRETURNING句はサポートしていません。この制約の原因は、Workspace Managerによりバージョン対応表でINSTEAD OFトリガーを持つビューが作成されても、Oracle Databaseはビュー上で定義されたINSTEAD OFトリガーを持つRETURNING句をサポートしていないことにあります。
この項では、Workspace Managerが新しい行バージョンを作成し、古いバージョンの履歴コピーをメンテナンスするプロセスについて説明します。
新しい行バージョンは、次のいずれかを実行すると、バージョン対応表に作成されます。
現行の作業領域で明示的セーブポイントを作成し、行を更新する。
現行の作業領域の下に子作業領域を作成する（CreateWorkspaceプロシージャを使用）、したがって現行の作業領域に暗黙的セーブポイントを作成する。GotoWorkspaceプロシージャを実行して子作業領域に移動し、行を更新する。
表で履歴が有効になっているか、別のセーブポイントが作成されないかぎり、その後のあらゆる現行の行の更新で、現行の行バージョンが上書きされます。
上書きを伴わない履歴を有効にする（VIEW_WO_OVERWRITE）と、現行の行バージョンを更新するたびに、変更とトランザクション時間に基づくタイムスタンプが適用された現行の行バージョンの完全なコピーが作成されます。このコピーは、新しい現行の行バージョンになります。
上書きを伴う履歴を有効にする（VIEW_W_OVERWRITE）と、現行の行バージョンが更新されるたびに、現行の行バージョンが上書きされ、トランザクション・タイムスタンプが更新されます。
作業領域にセーブポイントが作成されると、行への次の変更によって新しいバージョンが作成され、履歴サイクルが再び開始されます。
作業領域で作成される行バージョンは、MergeWorkspaceプロシージャまたはMergeTableプロシージャを実行しないかぎり、その作業領域から参照することができません。
子作業領域に対してMergeWorkspaceプロシージャを実行する場合、子作業領域の現行の行バージョンだけが親作業領域にマージされます。remove_workspaceパラメータをTRUEに指定すると、子作業領域が削除されるときに子作業領域のすべての中間行バージョンが削除されます。子作業領域に作成されたすべての中間バージョンを保持するには、remove_workspaceパラメータをFALSE（デフォルト）にする必要があります。
子作業領域でCompressWorkspaceプロシージャを実行して中間セーブポイントを削除する場合、その行バージョンの関連履歴コピーも削除することができます。これらのコピーを削除しない場合、これらのコピーは次のバージョンに関連付けられます。
中間行バージョンは、読取り専用アクセスのためにのみ選択できます。読取り専用アクセスのために中間行バージョンを選択するには、まだその作業領域に移動していない場合は移動し（GotoWorkspaceプロシージャ）、GotoDateプロシージャを実行してセッション・コンテキストを履歴時間に設定するか、GotoSavepointプロシージャを実行してセッション・コンテキストを特定のセーブポイントに設定します。後続のSELECT文は、読取り専用アクセスのために、指定された日付またはセーブポイントの時点で最新の行バージョンを選択します。
Workspace Manager操作は、標準のOracleセッションで実行します。（セッションとは、ユーザー・プロセスを使用した、ユーザーからOracleインスタンスへの特定の接続で、ユーザーが接続した時点から、接続を切断するかデータベース・アプリケーションが終了する時点まで続きます。）Workspace Managerの操作を実行すると、セッション・コンテキストに関連する情報が自動的に記録されます。
セッション・コンテキスト情報には、作業領域名およびコンテキスト値が含まれます。この情報により、作業領域内のセッションに表示できるデータ、およびセッションに入ることができる作業領域が決まります。コンテキスト値は、次のいずれかです。
LATEST: 現在、セッションがLATESTセーブポイント（第1.1.2項を参照）に設定され、作業領域内で行われた変更が表示されます。セッションが作業領域に入ると（GotoWorkspaceプロシージャを使用）、コンテキストは自動的にLATESTに設定されます。
セーブポイント名: 現在、セッションが作業領域内のセーブポイントに設定されています。最新バージョンの作業領域で変更が行われても、セッションではこれらの変更は表示されませんが、セーブポイント作成時のデータの静的ビューが表示されます。GotoDateプロシージャがコールされた後、セッション・コンテキストはセーブポイント名に設定されます。
特定の時点: 現在、セッションは特定の時点に設定されています。最新バージョンの作業領域で変更が行われても、セッションではこれらの変更は表示されませんが、特定の時点におけるデータの静的ビューが表示されます。GotoDateプロシージャがコールされた後、セッション・コンテキストはある時点に設定されます。（正確な時点は、EnableVersioning プロシージャで設定されるか、あるいはSetWoOverwriteOFFプロシージャまたはSetWoOverwriteONプロシージャで変更される、変更追跡用の履歴オプションによって異なります。）
セッション・コンテキストに関する情報は、GetSessionInfoプロシージャを使用して取得できます。この情報を取得すると、GotoWorkspace操作、GotoSavepoint操作およびGotoDate操作を組み合せて実行した後など、セッションの場所（作業領域およびコンテキスト）を知る必要がある場合に有効です。
通常のOracleデータベース・トランザクションが提供するロックの他に、Workspace Managerは2種類のバージョン・ロックを提供します。このロックの主な目的は、親作業領域と子作業領域の間における行の競合を排除することにある。ロックは、作業領域、セッションまたは指定行に対して、あるいはそれらを組み合せて使用可能にできます。
データ変更が1つまたは少数の作業領域内で行われている場合、または作業領域内のすべてのデータ変更をロックする場合は、作業領域レベルでロックします（SetWorkspaceLockModeONプロシージャ）。
データ変更が多数の作業領域内で行われている場合は、セッション・レベルでロックします（SetLockingONプロシージャ）。セッションに対してロックを使用可能にすると、Workspace Managerはこのセッションが存在するすべての作業領域の行をロックします。
行が更新される前に行をロックするか、または行が挿入された後（または、更新後にWHERE句を満たす場合は、更新された後）に行を自動的にロックする場合は、特定の行をロックします（LockRowsプロシージャ）。
作業領域およびセッションのロックは、作業領域またはセッションの存続期間中、あるいは作業領域がマージまたはロールバックされるまで持続します。
データベースのロックと同様に、Workspace Managerのロックには排他ロックまたは共有ロックがあります。
排他ロック: このロックは、データベース・トランザクションのロックに非常に類似しています。レコードが排他ロックされると、レコードをロックしたセッション（ユーザー）以外のデータベース内のユーザーは、そのレコードを変更できません。排他ロック操作がユーザーに対して使用可能になっている場合、そのユーザーが変更を行ったすべての行が排他的にロックされます。また、その行の親である行も排他的にロックされます。そのため、排他ロック操作を使用すると、子作業領域と親作業領域の間におけるデータの競合を排除できます。（ただし、排他ロックの行バージョンの詳細、および更新操作における排他ロックのタイミングが、他ユーザーが行を更新できるかどうかにどのように影響するかの詳細は、第1.3.1項を参照してください。）
共有ロック: 行が一度共有ロックされると、行がロックされている作業領域のユーザーのみがその行を変更できます。その行の親バージョンも共有ロックされるため、その行は競合から保護されます。排他ロックにない共有ロックのメリットは、行がロックされている作業領域内のすべてのユーザーがその行にアクセスし、行を変更できることです。この種類のロックは、親である行との競合を避ける必要があり、グループ・プロジェクトのメンバーである複数のユーザーが変更する必要がある行に使用することが理想的です。共有ロック操作は、作業領域内の各セッションに対して個々に使用可能にする必要があることに注意してください。
作業領域排他ロックとバージョン排他ロックは、ユーザーがデータ値を変更できるかどうかを制御する形式の排他ロックですが、排他ロックとは異なり、競合の発生は回避されません。作業領域排他ロックは、ロックを設定したユーザーのみが現行の作業領域内で値を変更できるように行をロックします。ただし、他の作業領域の他のユーザーは値を変更できます。バージョン排他ロックは、ロックを設定したユーザーのみが値を変更できる（および、そのユーザーがどの作業領域でも操作できる）ように行をロックします。どの作業領域でも他のユーザーは値を変更できません。
表1-3に、特定の作業領域内で特定のユーザーがロックした行を、どの作業領域のどのユーザーが変更できるかを示します。たとえば、表1-3の最初の2つの項目は、行が共有（S）ロックされていると、その行がロックされた作業領域のユーザーはだれでもその行を変更できますが、他の作業領域内のユーザーはその行を変更できないことを意味します。
表1-3 Workspace Managerのロック・モードとデータ変更の可否
| ロック・モード | ユーザー | ユーザーの作業領域 | 変更可能/不可 |
|---|---|---|---|
|
共有（S） |
すべてのユーザー |
行がロックされた作業領域 |
可能 |
|
共有（S） |
すべてのユーザー |
行がロックされたのとは異なる作業領域 |
不可 |
|
排他（E） |
行をロックしたユーザー |
行がロックされた作業領域 |
可能 |
|
排他（E） |
行をロックしたユーザー |
行がロックされたのとは異なる作業領域 |
不可 |
|
排他（E） |
行をロックしたのとは異なるユーザー |
すべての作業領域 |
不可 |
|
作業領域排他（WE） |
行をロックしたユーザー |
すべての作業領域 |
可能 |
|
作業領域排他（WE） |
行をロックしたのとは異なるユーザー |
行がロックされたのとは異なる作業領域 |
可能 |
|
作業領域排他（WE） |
行をロックしたのとは異なるユーザー |
行がロックされた作業領域 |
不可 |
|
バージョン排他（VE） |
行をロックしたユーザー |
すべての作業領域 |
可能 |
|
バージョン排他（VE） |
行をロックしたのとは異なるユーザー |
すべての作業領域 |
不可 |
行をロックすることは、作業領域のマージ操作、リフレッシュ操作およびロールバック操作には影響しませんが、これらの操作後、その行で何ができるかに影響します。操作を実行する前に、作業領域権限を使用して、FreezeWorkspaceプロシージャをコールし、作業領域xxx_LOCKビュー（第5.48項を参照）を確認することにより、これらの作業領域操作を制御できます。
xxx_LOCK静的データ・ディクショナリ・ビュー（第5.48項を参照）には、各バージョン対応表のロックに関する情報が含まれています。
参照整合性制約を持つ表のDML操作でのWorkspace Managerロック操作の詳細は、第1.9.1.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がその作業領域内の現行バージョンになっています。）
つまり、更新後の排他ロックは、作業領域ツリー内のロックされた作業領域の上位にある作業領域内の行、または作業領域ツリーの他ブランチ内の作業領域内の行の以前のバージョンをロックしません。
Workspace Managerには、標準のOracleデータベース権限とは異なる一連の権限があります。Workspace Managerの作業領域レベルの権限（xxx_WORKSPACE 形式の名前が付いている）によって、指定された作業領域に対して影響を与えることができます。また、システム・レベルの権限（xxx_ANY_WORKSPACE 形式の名前が付いている）によって、任意の作業領域に対して影響を与えることができます。
表1-4に、Workspace Managerの権限を示します。
表1-4 Workspace Managerの権限
| 権限 | 説明 |
|---|---|
|
指定された作業領域に移動できます。その他のすべての権限には、 |
|
|
任意の作業領域に移動できます。その他のすべての権限には、 |
|
|
指定された作業領域内で子作業領域を作成できます。 |
|
|
任意の作業領域内で子作業領域を作成できます。 |
|
|
指定された作業領域を削除できます。 |
|
|
任意の作業領域を削除できます。 |
|
|
指定された作業領域内の変更を、その親作業領域にマージできます。 |
|
|
任意の作業領域内の変更を、その親作業領域にマージできます。 |
|
|
指定された作業領域内の変更をロールバックできます。 |
|
|
任意の作業領域内の変更をロールバックできます。 |
|
|
指定された作業領域へのアクセスを制限したりアクセス制限を解除したりできます。 |
|
|
任意の作業領域へのアクセスを制限したりアクセス制限を解除したりできます。 |
各権限は、Grant Optionの有無にかかわらず付与できます。Grant Optionによって、権限が付与されたユーザーはその権限を他のユーザーに付与できます。
WM_ADMIN_ROLEロールには、Grant Optionが付いたすべてのWorkspace Manager権限があります。デフォルトでは、データベース管理者（DBAロール）にWM_ADMIN_ROLEロールが付与されます。そのため、どのユーザーにどの権限を付与するかを決定した後で、DBAにそれらの権限を付与させるか、またはDBAにWM_ADMIN_ROLEロールを1人以上の選択されたユーザーに付与させた後で、これらのユーザーから権限を付与させます。
GrantWorkspacePrivプロシージャおよびGrantSystemPrivプロシージャは、それぞれ作業領域レベルの権限およびシステム・レベルの権限を付与するために使用します。
RevokeWorkspacePrivプロシージャおよびRevokeSystemPrivプロシージャは、それぞれ作業領域レベルの権限およびシステム・レベルの権限を取り消すために使用します。これらのプロシージャを使用するには、指定された権限を指定されたユーザーから取り消すための十分な権限が必要です。権限を付与したユーザーは、その権限を取り消すことができます。
このリリースのWorkspace Managerには、WM_ADMIN_ROLEロール（第1.4項を参照）を持つユーザーがデータベースに対してグローバルなWorkspace Manager固有設定を規定できるように、一連のシステム・パラメータが用意されています。（これらのWorkspace Managerシステム・パラメータは、Oracle初期化パラメータではありません。Workspace Managerシステム・パラメータを設定するには、SetSystemParameterプロシージャを使用する必要があります。第4章を参照してください。）
システム・パラメータを設定するには、SetSystemParameterプロシージャを使用します。現在のシステム・パラメータ設定を取得するには、GetSystemParameterプロシージャを使用します。これらのプロシージャについては、第4章を参照してください。
表1-5に、Workspace Managerのシステム・パラメータを示します。
表1-5 Workspace Managerのシステム・パラメータ
| パラメータ名 | 値 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1〜1000の数値に設定して、 |
|
|
|
|
|
メモリーの最大容量を表す数。バイトで指定され、MergeTable、MergeWorkspaceまたはRefreshWorkspace操作の間、メモリーへの行の選択に使用されます。デフォルトは8388608（8MB）。Workspace Managerはこの値を使用して、一度にフェッチする行の最適数を確認します。この値は、他のデータベースのプロセスに使用されるメモリー容量には影響しません。内部作業領域操作にのみ影響します。 |
|
|
|
|
|
このパラメータは、これ以降にバージョン対応にする表にのみ影響します。既存のバージョン対応表のビューには影響しません。既存のバージョン対応表のビューを変更するには、AlterVersionedTableプロシージャを使用して、 |
|
|
|
Workspace Managerでは、バージョン対応表のインポートおよびエクスポートがサポートされています。全データベースのインポートおよびエクスポート、およびWorkspace Managerプロシージャを使用した作業領域レベルのインポートおよびエクスポートの2つの方法があります。その他のエクスポート・モード（スキーマ、表、パーティション・レベルなど）はサポートされません。
バージョン対応データベースには、Oracleユーティリティを使用した全データベースのインポート操作およびエクスポート操作を実行できます。ただし、その場合は、次の考慮点および制限事項が適用されます。
バージョン対応表を含むデータベースは、Workspace Managerをインストール済で、現在バージョン対応表または作業領域（LIVE作業領域以外）がない他のOracleデータベースにのみ、エクスポートできます。
Oracle Data Pump Importユーティリティによるインポート操作の場合、ダンプ・ファイルにWMSYSスキーマが含まれているときは、table_action_exists=truncateを指定する必要があります。ダンプ・ファイルにWMSYSスキーマが含まれていない場合、インポートされるバージョン対応表がまだ存在しないか空であるときは、table_action_exists=appendを指定することができます。（一般に、Oracle Databaseリリース10.2以上によって生成されるダンプ・ファイルにはWMSYSスキーマが含まれず、それより前のリリースによって生成されるダンプ・ファイルにはWMSYSスキーマが含まれます。）
ダンプ・ファイルは、互換性のあるバージョンのWorkspace Managerによって生成される必要があります。一般に、同時に（特定のOracle Databaseリリースに対してなど）リリースされたWorkspace Managerキットは、相互に互換性があります。
データ・ポンプ・インポートを使用している場合はダンプ・ファイルがデータ・ポンプ・エクスポートを使用して作成されている必要があります。元のインポート・ユーティリティを使用している場合は、ダンプ・ファイルが元のエクスポート・ユーティリティを使用して作成されている必要があります。
元のインポート・ユーティリティによるインポート操作では、IGNORE=Yを指定する必要があります。
どのインポート操作に対しても、FROMUSER機能とTOUSER機能は、バージョン対応データベースではサポートされません。
作業領域レベルのエクスポート操作では、各バージョン対応表を作業領域レベルでエクスポートできます。1つのデータベースから他データベースへバージョン対応表をエクスポートする手順は、次のとおりです。
Exportプロシージャをコールして、ステージング表（たとえば、t1）へエクスポートする必要があるすべてのデータを格納します。特定の作業領域、セーブポイントまたは時点から参照できるすべてのデータ、または特定の作業領域内で修正されたデータのみをエクスポートできます。詳細は、第4章の「Exportプロシージャ」を参照してください。
バージョン対応表に対して複数の作業領域をエクスポートするには、Exportプロシージャを再度コールして、元のステージング表およびエクスポートする必要がある新規作業領域を指定します。バージョン非対応の表にデータをインポートする場合、versioned_dbパラメータにFALSEを指定します。
Oracle Exportユーティリティを使用して、ステージング表（たとえば、t1）をエクスポートします。
Oracle Importユーティリティを使用して、宛先データベースへステージング表（たとえば、t1）をインポートします。
バージョン対応表へインポートする場合、Importプロシージャをコールし、ソース・データベース上にデータが常駐する作業領域、およびデータを格納する作業領域を指定して、ステージング表からバージョン対応表へデータを移動します。
ステージング表の構造は、バージョン対応表と一致する必要があります。デフォルトでは、インポート・プロシージャを正常に完了する前に、有効なすべての制約を検証する必要があります。
SQL*Loaderを使用するとバージョン対応表へのバルク・ロードを実行できますが、Workspace Managerの特殊プロシージャもコールする必要があり、ある程度の制限が適用されます。最新バージョンの作業領域またはルート・バージョン（バージョン番号0のLIVE作業領域）に対して、データのダイレクト・パスによるバルク・ロードと従来型パスによるバルク・ロードの両方を実行できます。ルート・バージョンは他のすべてのバージョンの祖先であるため、ルート・バージョンのデータは他のすべての作業領域から参照可能です（LIVE以外の作業領域に更新済のデータがない場合）。
バージョン対応表に対してバルク・ロードを実行する一般手順は、次のとおりです。
GetBulkLoadVersionファンクションをコールして、バルク・ロード後にタグ付けが必要なデータに使用する予約済バージョン番号をフェッチします。バージョン対応表にバルク・ロードしたすべてのデータは、バージョン番号でタグ付けする必要があります。バージョン番号は、データの最終的な宛先、つまり、作業領域の最新バージョンまたはルート・バージョンによって決まります。GetBulkLoadVersionファンクションから戻されるバージョン番号をSQL*Loader制御ファイル内で使用します。手順3を参照してください。
BeginBulkLoadingプロシージャをコールして、表をバルク・ロード用に準備します。バージョン対応表へのデータのバルク・ロード中は、表に対するDML操作も作業領域操作も実行できませんが、この表に関係しない作業領域操作は実行できます。BeginBulkLoadingプロシージャにより、この表に対する無効な操作の実行が回避されます。
SQL*Loaderを使用してバルク・ロードを実行します。制御ファイルの1行のみを変更し、<table_name>_LT名を指定して、手順1でフェッチされたバージョン番号を挿入します。たとえば、既存の制御ファイルに次の行があると仮定します。
Load data into table departments (name, loc)
手順1でフェッチされたバージョン番号が5であれば、制御ファイル内でバージョン対応表へのバルク・ロードに関する行を次のように変更する必要があります。
Load data into table departments_LT (name, loc, version constant '5')
これにより、バルク・ロードされるすべての行が確実にバージョン5でタグ付けされ、各行ではWorkspace Manager固有の他の列が確実にNULL値となります。表が履歴オプション指定のあるバージョン対応だった場合は、作成時刻と削除または変更時刻を<table_name>_LTのcreatetime列とretiretime列にバルク・ロードできます。
バルク・ロード処理を完了するには、CommitBulkLoadingプロシージャをコールしてバルク・ロードによる変更をコミットするか、RollbackBulkLoadingプロシージャをコールしてバルク・ロードによる変更をロールバックします。
バルク・ロードによる変更をコミットすると、Workspace Managerでは必要な作業領域内およびバージョン内でデータが更新されていることが確認されます。デフォルトでは、バルク・ロードされたデータは、表に対して定義済の一意制約または参照制約に対してそれぞれチェックされ、バルク・ロードされた行のうち、いずれかの制約に違反する行はCommitBulkLoadingプロシージャのパラメータに指定した廃棄表に移動します。重複（つまり、バルク・ロードされたデータのうち主キー列に同じ値を持つレコード）の有無をチェックするように指定した場合は、重複レコードのうち最小のROWID値を持つレコードのみが表にロードされ、他のレコードは廃棄表に移動します。
現行のリリースの場合、バージョン対応表を使用したバルク・ロードには次の制限が適用されます。
自己参照型の整合性制約を持つ表にはバルク・ロードできません。
LIVEを除き、連続的にリフレッシュされる子作業領域を持つ作業領域にはバルク・ロードできません。
バージョン対応表にバルク・ロードできるのは、表の所有者またはWM_ADMIN_ROLEロールを取得しているユーザーのみです。
バージョン対応表をバルク・ロードするユーザーには、<table_name>_LTに対するINSERT権限が必要です。
バルク・ロード中は、バージョン対応表に対するユーザー定義トリガーは実行されません。
バルク・ロードされた行には、セッションのロック・モードは規定されません。この種の行をロックするにはLockRowsプロシージャを使用します。
バージョン対応表に対してデータ定義言語（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プロシージャを使用します。第3.11項を参照してください。 |
バージョン対応表と関連する次の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の参照整合性のサポートの詳細は、第1.9.1項を参照してください。
一意制約に対する操作: 一意制約の追加、削除、使用可能化、使用禁止。Workspace Managerの一意制約のサポートの詳細は、第1.9.2項を参照してください。
権限に関する操作: ユーザーへの表レベル権限の付与、およびユーザーからの権限の取消し。
バージョン対応表で、標準、ビットマップ、ファンクション標準、ファンクション・ビットマップおよびドメインの索引を作成できます。バージョン対応表ではパーティション索引、逆索引、または結合索引は作成または削除できません。（ただし、パーティション索引、逆索引または結合索引を持つバージョン対応表は作成または削除できます。）
サポートされていないDDL操作を実行すると、変更は行われず、CommitDDLプロシージャによって例外が発生する場合があります。
ドメイン索引に対して、バージョン対応表が関連するDDL操作を実行する場合（たとえば、表にRツリー索引を作成する場合）は、CREATE TABLE権限が必要です。
レプリケーション環境でバージョン対応表に対してDDL操作を実行する必要がある場合のガイドラインは、第C.3項を参照してください。
Oracle Label Security（OLS）環境でバージョン対応表に対してDDL操作を実行する必要がある場合は、スケルトン（_LTS）表でSA_POLICY_ADMINパッケージのapply_table_policy、remove_table_policy、enable_table_policyおよびdisable_table_policyプロシージャを使用することができ、変更は、バージョン対応表に転送されます。
例1-1に、COLA_MARKETING_BUDGET_LTSという名前の特別な表を使用して、COMMENTS列をCOLA_MARKETING_BUDGET表に追加する場合に必要な文を示します。この例には、列の追加を示すDESCRIBE文も含まれています。
例1-1 バージョン対応表の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');
例1-1のALTER TABLE文には、BeginDDLプロシージャによって作成されるCOLA_MARKETING_BUDGET_LTS表が指定されています。CommitDDLプロシージャによって、COLA_MARKETING_BUDGET表に変更が適用され、COLA_MARKETING_BUDGET_LTS表が削除されます。
この項では、データベース制約の使用に関連するWorkspace Managerの考慮事項について説明します。
バージョン対応表には、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)に存在する必要があるという制約があります。ただし、関連するすべての参照整合性制約が制限ルールを伴わないかぎり、マルチレベルの参照整合性制約と関連するすべての表を、まとめてバージョン対応およびバージョン非対応にする必要があります。関連するすべての制約に制限ルールがある場合は、表をまとめてバージョン対応にできます。または子表、親表の順で、1つずつバージョン対応にできます。表名は、カンマで区切ったリストとしてEnableVersioningプロシージャおよびDisableVersioningプロシージャに渡す必要があります。
Workspace Managerは、ALL_WM_RIC_INFO静的データ・ディクショナリ・ビューおよびUSER_WM_RIC_INFO静的データ・ディクショナリ・ビュー（第5章を参照）を使用して、参照整合性のサポートに関連する情報を保持します。
2つの表が関連する参照整合性制約を追加、削除、使用可能または使用禁止にする必要がある場合は、表をバージョン対応にする前に、これらの操作を実行すると便利です。ただし、次の手順を実行すると、2つのバージョン対応表が関連する参照整合性制約を追加、削除、使用可能または使用禁止にできます。
親表を指定して、DDLセッションを開始します。
子表を指定して、DDLセッションを開始します。
子表の<table-name>_LTS表を変更して、外部キー制約を追加します。（<table-name>_LTS表およびバージョン対応表に対するDDL操作の実行については、第1.8項を参照してください。）
子表を指定して、DDL変更をコミットします。
親表を指定して、DDL変更をコミットします。
外部キー制約の追加例を例1-2に示します。EMPLOYEE表およびDEPARTMENT表はバージョン対応で、次のとおり定義されていると想定します。
EMPLOYEE(emp_id number primary key, dept_id number) DEPARTMENT(dept_id number primary key, dept_name varchar2(30))
例1-2 参照整合性制約の追加
-- 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つの表が関連する参照整合性制約を追加、削除、使用可能または使用禁止にできません。両方の表が、バージョン対応である必要があります。
参照整合性制約を持つバージョン対応表に対してデータ操作言語（DML）操作が実行された場合、Workspace Managerは共有ロックを取得し、次の条件が規定されます。
子表の外部キーに影響する挿入または更新操作中は、親表での削除操作は実行できません。たとえば、DEPARTMENTが親表、EMPLOYEEが子表の場合、新規従業員の追加中、または既存の従業員の異なる部門への割当て中に部門の削除はできません。
親表での削除操作中は、子表に対して外部キー列に影響する挿入または更新操作は実行できません。たとえば、部門の削除中、新規従業員の追加および既存の従業員の異なる部門へ割当てはできません。
次のどちらかのDML操作を複数のセッションで同時に実行できます。ただし、次の両方を同時には実行できません。
子表の外部キー列に影響する挿入操作または更新操作。
親表での削除操作。
次のWorkspace Manager操作のいずれかを、複数のセッションで同時に実行できます。
MergeTableプロシージャを使用して、異なる作業領域で子表または親表に変更を適用します。
MergeTableプロシージャを使用して、1つの作業領域で子表に変更を適用し、別の作業領域で子表に挿入または更新をします。
MergeTableプロシージャを使用して、1つの作業領域で親表に変更を適用し、別の作業領域で親表から削除します。
次の場合、セッションは他のセッションが終了するまでブロックされます。
セッションが1つの作業領域で子表への変更をマージしようとしており、別のセッションが別の作業領域で親表への変更をマージしようとしている場合。
セッションが1つの作業領域で子表への変更をマージしようとしており、別のセッションが親表から削除しようとしている場合。
セッションが1つの作業領域で親表への変更をマージしようとしており、別のセッションが子表へ挿入、または子表の外部キーの値を変更しようとしている場合。
一意制約が定義されている表をバージョン対応にすることができます。サポート対象は次のとおりです。
1列または複数列に対するUNIQUE制約
1列または複数列の一意索引
表のファンクションの一意索引
NULL値の取扱いは、バージョン対応表の場合もバージョン対応でない表の場合も同じです。
Workspace Managerは、次の静的データ・ディクショナリ・ビュー（第5章を参照）を使用して、一意制約のサポートに関連する情報を保持します。
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には、バージョン対応表に対するファンクションの一意索引のファンクション式に関する情報が含まれています。
バージョン対応表には、トリガーを定義できます。ただし、その場合は、次の考慮点および制限事項が適用されます。
行レベル・トリガーのみがサポートされます。文単位のトリガーはサポートされません。
行全体のトリガーのみがサポートされます。特定の列に対するBEFORE UPDATEおよびAFTER UPDATEのトリガーはサポートされません。
サポートされるコールアウトは、PL/SQLプロシージャのみです。したがって、action_typeはPL/SQLである必要があります。
バージョン対応表でサポートされないすべてのトリガーは、バージョニングが使用可能になったときに解除され、バージョニングが使用禁止になったときにアクティブにされます。
SetTriggerEventsプロシージャを使用すると、イベントの種類を指定し、それに対して特定のユーザー定義トリガーを選択的に使用可能にすることができます。
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のすべてに対して、行レベルのセキュリティ・ポリシーを定義する必要があります。行レベルのセキュリティ・ポリシーを定義するときには、第1.8項で説明したWorkspace Manager DDLフレームワークは使用しないでください（つまり、BeginDDLおよびCommitDDLプロシージャは使用しないでください）。
Workspace Managerのプロシージャまたは表名をコールするファンクションの入力パラメータの場合、表名のかわりにシノニムを指定できます。Workspace Managerは、次の順序で表を検索し、指定された名前と最初に一致した表を使用します。
指定されたスキーマ（スキーマが指定されていない場合は、ローカル・スキーマ）内にある表
指定されたスキーマ（スキーマが指定されていない場合は、ローカル・スキーマ）内にあるプライベート・シノニム
パブリック・シノニム
この項では、Workspace Managerとマテリアライズド・ビューを併用する場合の考慮事項について説明します。
バージョン対応表のマテリアライズド・ビューを作成できるのは、マテリアライズド・ビューの作成時に完全リフレッシュ方式（REFRESH COMPLETE）を指定する場合のみです。CREATE MATERIALIZED VIEW文には次の句を指定できません。
FAST（増分リフレッシュ）
ON COMMIT
FOR UPDATE
マテリアライズド・ビューまたはその実表はバージョン対応にできません。
マテリアライズド・ビューを作成する場合、その内容は作成時点のセッションの作業領域に基づきます。マテリアライズド・ビューをリフレッシュする場合、その内容はDBMS_MVIEW.REFRESH操作の実行時のセッションの作業領域に基づきます。マテリアライズド・ビューを作成またはリフレッシュすると、すべての作業領域に同じデータが表示されます。
この項では、Oracle Spatialのトポロジによる表でWorkspace Managerを使用する場合の特別な考慮事項と手法について説明します。Oracle Spatialのトポロジの詳細は、『Oracle Spatialトポロジおよびネットワーク・データ・モデル開発者ガイド』を参照してください。
トポロジは、フィーチャー表と、<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プロシージャをコールします。
トポロジに関連付けられている行をロックまたはロック解除するには、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 Topology JavaクライアントのloadWindowメソッドをコールします。
Workspace Managerを空間トポロジで使用する場合は、次の考慮事項が追加適用されます。
トポロジに関連付けられている表をバージョン対応にする前に、そのトポロジに対して少なくとも1回はSDO_TOPO.INITIALIZE_METADATAプロシージャをコールする必要があります。（SDO_TOPO.INITIALIZE_METADATAプロシージャは、トポロジをバージョン対応にした後も必要に応じてコールできます。）
トポロジに関連付けられているバージョン対応表では、MergeTable、RefreshTableまたはRollbackTableプロシージャを使用しないでください。トポロジに関連付けられている表のマージ、リフレッシュまたはロールバックには、かわりにMergeWorkspace、RefreshWorkspaceまたはRollbackWorkspaceプロシージャを使用してください。
Workspace Managerは内部オブジェクトの作成に固有の命名規則を使用するため、ある種のオブジェクトの名前では、避ける必要のある語や文字があります。表1-6に、オブジェクトの種類と、それらの名前に適用される制限を示します。（名前の長さのガイドラインについては、第1.1.11項の表1-2を参照してください。）
表1-6 Workspace Managerの予約語および予約文字
| オブジェクト | 名前に使用できない文字（列） |
|---|---|
|
作業領域 |
|
|
バージョン対応表 |
|
|
バージョン対応表の列 |
さらに、表に有効期間サポート（第3章を参照）がある場合、列の名前に |
|
バージョン対応表の索引 |
|
Workspace ManagerのApplication Program Interface（API）は、単一のPL/SQLパッケージDBMS_WMにあるPL/SQLサブプログラム（プロシージャおよびファンクション）で構成されています。各サブプログラムは、この項で説明するカテゴリに論理的にグループ化できます。
|
注意: ほとんどのWorkspace Managerサブプログラムはプロシージャですが、ファンクションもいくつかあります（ファンクションは値を戻しますが、プロシージャは値を戻しません）。ほとんどのファンクションの名前は、Get で始まります（GetConflictWorkspaceおよびCreateSavepointなど）。 |
すべてのサブプログラムのリファレンス情報については、第4章を参照してください。
表管理サブプログラムは、表に対する作業領域管理を使用可能および使用禁止にし、その他の表関連操作を実行します。
表1-7に、表の管理に使用できるサブプログラムを示します。
表1-7 表管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
|
表をバージョン対応にし、表が複数バージョンの行をサポートできるように、必要な構造を作成します。 |
|
|
バージョン対応表内に作成された行のサポート構造をすべて削除します。 |
|
|
EnableVersioningプロシージャまたはSetWoOverwriteONプロシージャによって使用可能になった |
|
|
SetWoOverwriteOFFプロシージャによって使用禁止になった |
|
|
指定された表に対してDDLセッションを開始します。 |
|
|
DDLセッション中に指定された表に対して行われたDDL変更をコミットし、DDLセッションを終了します。 |
|
|
DDLセッション中に指定された表に対して行われたDDL変更をロールバックし（取り消し）、DDLセッションを終了します。 |
|
|
Workspace Managerの移行プロシージャが正常に実行されなかった場合、一貫性のない状態になっている表の移行プロセスを完了しようとします。 |
|
|
Workspace Managerの移行プロシージャが正常に実行されなかった場合、一貫性のない状態になっているすべての表の移行プロセスを完了しようとします。 |
|
|
バージョン対応表内のラージ・オブジェクト（LOB）列（BLOB、CLOBまたはNCLOB）を変更します。 |
|
|
バージョン対応表からステージング表にデータ（すべての行、または複数のパラメータの組合せで限定された行）をエクスポートします。 |
|
|
ステージング表から指定の作業領域内のバージョン対応表に、データ（すべての行、または複数のパラメータの組合せで限定された行）をインポートします。 |
作業領域管理サブプログラムは、作業領域に対する操作を実行します。
表1-8に、作業領域の管理に使用できるサブプログラムを示します。
表1-8 作業領域管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
|
データベース内に新しい作業領域を作成します。 |
|
|
現行のセッションを指定された作業領域に移動します。 |
|
|
2つのセーブポイントまたは2つの作業領域間のバージョン対応表における値の差異を検索します。差異を記述する行を様々なビューに作成します。 |
|
|
SetDiffVersions操作が実行されたセッションの作業領域とセーブポイントのペアの名前を戻します。 |
|
|
作業領域内の表（すべての行、または |
|
|
作業領域内のすべての変更をその親作業領域に適用します。また、オプションで、その作業領域を削除できます。 |
|
|
作業領域内のバージョン対応表に対するすべての変更を廃棄します。 |
|
|
作業領域内の指定された表（すべての行、または |
|
|
指定されたセーブポイント以降に行われた作業領域内のバージョン対応表に対するすべての変更を廃棄します。 |
|
|
作業領域に対し、その親作業領域内の表（すべての行、または |
|
|
作業領域に対し、その親作業領域内のすべての変更を適用します。 |
|
|
作業領域の定義を変更します。 |
|
|
連続的にリフレッシュされない作業領域を連続的にリフレッシュされるように変更します。 |
|
|
作業領域に関連付けられたすべての行バージョンを廃棄し、作業領域を削除します。 |
|
|
作業領域およびその子作業領域に関連付けられたすべての行バージョンを廃棄し、影響を受ける作業領域を削除します。 |
|
|
作業領域へのアクセスおよび作業領域内で変更を行うユーザーの権限を制限します。 |
|
|
作業領域にアクセスできるようにし、また作業領域に対する変更を有効にし、FreezeWorkspaceプロシージャによる処理を元に戻します。 |
|
|
作業領域内の削除可能なセーブポイントを削除し、その作業領域のWorkspace Managerメタデータ構造を最小化します。 |
|
|
作業領域およびそのすべての子作業領域内の削除可能なセーブポイントを削除します。また、影響を受ける作業領域のWorkspace Managerメタデータ構造を最小化し、セーブポイントの削除によって不要となったデータを排除します。 |
|
|
作業領域内にアクティブなセッションがあるかどうかを確認します。 |
|
|
セッションの現行の作業領域を戻します。 |
|
|
指定された作業領域（1つまたは複数）をバージョン対応表の複数作業領域ビューで表示します。 |
|
|
バージョン対応表の複数作業領域ビューで参照できる作業領域の名前を戻します。 |
|
|
現行のセッションに対する現行の操作のコンテキストを戻します。 |
|
|
複数の親を持つ作業領域環境で、作業領域を子作業領域に親作業領域として追加します。 |
|
|
複数の親を持つ作業領域環境で、作業領域を親作業領域として削除します。 |
セーブポイント管理サブプログラムは、セーブポイントに関連する操作を実行します。
表1-9に、セーブポイントの管理に使用できるサブプログラムを示します。
権限管理サブプログラムは、Workspace Managerの権限の付与および取消しを行います。
表1-10に、権限の管理に使用できるサブプログラムを示します。
ロック管理サブプログラムは、Workspace Managerのロック操作を制御します。
表1-11に、ロックの管理に使用できるサブプログラムを示します。
表1-11 ロック管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
|
現行のセッションに対してWorkspace Managerのロック操作を使用可能にします。 |
|
|
現行のセッションに対してWorkspace Managerのロック操作を使用禁止にします。 |
|
|
指定された作業領域に対してWorkspace Managerのロック操作を使用可能にします。 |
|
|
指定された作業領域に対してWorkspace Managerのロック操作を使用禁止にします。 |
|
|
現行のセッションのロック・モードを戻します。これによって、バージョン対応行、および前回のバージョン内の対応する行にアクセスできるかどうかが決まります。 |
|
|
指定された表内のバージョン対応行、および親作業領域内のそれに対応する行へのアクセスを制御します。 |
|
|
指定された表内のバージョン対応行、および親作業領域内のそれに対応する行にアクセスできるようにします。 |
競合管理サブプログラムは、作業領域間における競合を検出し、解消します。
表1-12に、競合の管理に使用できるサブプログラムを示します。
表1-12 競合管理サブプログラム
| プロシージャ | 説明 |
|---|---|
|
|
作業領域とその親作業領域の間に競合があるかどうかを判断します。 |
|
|
SetConflictWorkspaceプロシージャを実行したセッションの作業領域の名前を戻します。 |
|
|
競合解消セッションを開始します。 |
|
|
作業領域間における競合を解消します。 |
|
|
競合解消セッションを終了し、BeginResolveプロシージャの実行以降に作業領域内で行われたすべての変更を保存します（永続的な変更にします）。 |
|
|
競合解消セッションを終了し、BeginResolveプロシージャの実行以降に作業領域内で行われたすべての変更を廃棄します。 |
レプリケーション・サポート・サブプログラムは、Workspace Manager環境におけるOracle Replicationをサポートします。レプリケーションの使用方法の詳細は、付録Cを参照してください。
表1-13に、レプリケーションのサポートに使用できるサブプログラムを示します。
表1-13 レプリケーション・サポート・サブプログラム
| プロシージャ | 説明 |
|---|---|
|
|
Workspace Managerオブジェクトのマルチマスター・レプリケーションに必要な構造体を作成し、新しく作成されたマスター・グループに対するマスター・アクティビティを開始します。 |
|
|
GenerateReplicationSupportプロシージャによって作成されたレプリケーション・サポート・オブジェクトを削除します。 |
|
|
Workspace Managerのレプリケーション環境のnonwriterサイトの1つを新しいwriterサイトにします。（以前のwriterサイトは、nonwriterサイトの1つになります。） |
|
|
RelocateWriterSiteプロシージャを使用して、writerサイトが移動した後、Workspace Managerのレプリケーション環境のローカル・サイト（以前のwriterサイト）を最新の状態に更新します。 |
バルク・ロード・サポート・サブプログラムは、バージョン対応表へのデータのバルク・ロードにSQL*Loaderを使用できるようにします。詳細は、第1.7項を参照してください。
表1-14に、バルク・ロードのサポートに使用できるサブプログラムを示します。
表1-14 バルク・ロード・サポート・サブプログラム
| プロシージャ | 説明 |
|---|---|
|
|
BeginBulkLoadingプロシージャのコール時に指定するバージョン番号を戻します。 |
|
|
バージョン対応表のバルク・ロード処理を開始します。 |
|
|
バルク・ロードによる変更をコミットして、バージョン対応表のバルク・ロード処理を終了します。 |
|
|
バルク・ロード操作中にバージョン対応表に対して行われた変更をロールバックします。 |
この項では、Workspace Managerを使用していくつかの使用例を試行し、その1つを選択するための簡単な例を2つ示します。それぞれの例では、複数の作業領域と1つ以上のセーブポイントを使用します。一方の例（第1.17.2項）では、Oracleサンプル・スキーマ内のOE.WAREHOUSES表を使用します。
どちらの例でも、この章で説明した概念を示し、第4章に示すプロシージャを使用します。
例1-3では、ある清涼飲料（コーラ）メーカーが4つの製品を製造し、その製品ごとにマーケティング・マネージャを配置し、マーケティング予算を計上している例を示します。1つの製品（cola_b）が市場で非常に大幅な成長が見込まれるため、この企業は、異なるマネージャや予算額を想定したwhat-if 分析を行っています。
例1-3 マーケティング予算のオプション
-------------------------------------------------------------------
-- INITIAL SET-UP
-------------------------------------------------------------------
-- Create the user for schema objects.
CREATE USER wm_developer IDENTIFIED BY password;
-- Grant regular privileges.
GRANT connect, resource to wm_developer;
GRANT 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 (which are in the LIVE database
-- workspace, which is the only workspace currently existing).
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-4では、Oracleサンプル・スキーマを使用している会社が、倉庫面積を拡張する必要があると決定している例を示します。この会社は2つの使用例を考慮しようとしています。一方はTown Aに1つの大規模倉庫を建設する案、他方はTown BとTown Cに2つの小規模倉庫を建設して全体の保管能力を拡大する案です。どちらの使用例にも潜在的なメリットとデメリットがあり、それぞれに財務上と法律上の課題があります。その後、この会社はそれぞれの使用例では倉庫面積が足りないと判断したため、両方の使用例に同じ倉庫を追加する案を検討しようとしています。
例1-4では、使用例ごとに作業領域を1つ作成し、各作業領域内にセーブポイントを作成してから、表に対して新規倉庫を追加しています。これは、会社が倉庫の追加使用を決定しない可能性があるためです。倉庫の行は、Oracleサンプル・スキーマの一部であるOE.WAREHOUSES表に格納されています。
例1-4 倉庫拡張のオプション
-------------------------------------------------------------------
-- 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 connect, resource TO wm_developer;
GRANT 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 required 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,
MDSYS.SDO_GEOMETRY(2001, 8307,
MDSYS.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,
MDSYS.SDO_GEOMETRY(2001, 8307,
MDSYS.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,
MDSYS.SDO_GEOMETRY(2001, 8307,
MDSYS.SDO_POINT_TYPE(-71.02439, 42.28628, NULL), NULL, NULL));
INSERT INTO oe.warehouses VALUES (11, NULL, 'Town C', 4200,
MDSYS.SDO_GEOMETRY(2001, 8307,
MDSYS.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,
MDSYS.SDO_GEOMETRY(2001, 8307,
MDSYS.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-4の終わり近くにある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
