1.1 Workspace Managerの概要

Workspace Managerでは、データベース内の1つ以上のユーザー表をバージョン対応にできます。バージョン対応表では、表内のすべての行で複数バージョンのデータをサポートできます。

バージョニングのインフラストラクチャは、データベース・ユーザーからは見えません。また、データの選択、挿入、変更、削除を行うアプリケーションのSQL文は、通常どおり、バージョン対応表に対する処理を続けます。ただし、バージョン対応表の主キー列の値は更新できません。(Workspace Managerは、システム・ビューを維持し、INSTEAD OFトリガーを作成することによって、これらの機能を実装します。詳細は、「バージョン対応表のインフラストラクチャ」を参照してください。ただし、アプリケーション開発者とユーザーはビューやトリガーを表示または操作する必要がありません。)

表がバージョン対応になると、作業領域内のユーザーに必要なレコードの正確なバージョンが自動的に表示されます。表をバージョン対応にする必要がなくなった場合は、表のバージョニングを使用禁止にできます。

作業領域とは、データベース内のデータに対して変更を加えるために1人以上のユーザーが共有できる仮想環境です。作業領域は、1つ以上のバージョン対応表の新しい行バージョンの集合を論理的にグループ化し、これらのバージョンが本番データと明示的にマージされるか、または廃棄されるまで、切り離しておきます。これにより、同時実行性が最大限に引き出されます。ユーザーは、作業領域に対して様々な操作(移動、作成、リフレッシュ、マージ、ロールバック、削除、圧縮、変更など)を実行できます。

作業領域内にいるユーザーに対しては、トランザクションの一貫性を保持したデータベース全体のビューが常に表示されます。つまり、現行の作業領域で行われた変更の他に、作業領域の作成時、または親作業領域の変更によって作業領域が最後にリフレッシュされた時点でデータベースに存在したそれ以外のデータも表示されます。(作業領域階層、親作業領域および子作業領域の詳細は、「作業領域階層」を参照してください。)

Workspace Managerは競合を自動的に検出します。競合とは、作業領域および親作業領域内の同一行に対する変更によるデータ値の差異です。作業領域の変更をその親作業領域にマージする前に、競合を解消する必要があります。作業領域ロックを使用すると、競合を回避できます。

セーブポイントは、バージョン対応表の行変更をロールバックできる作業領域内のポイントで、その時点でデータベースに存在していた内容を調べることができます。通常、セーブポイントは、設計段階の完了時や支払い期限の終了時などビジネス関連指標に応じて作成されます。(セーブポイントの詳細は、「セーブポイントの使用」を参照してください。)

履歴オプションは、バージョン対応表のすべての行に加えられた変更にタイムスタンプを付け、各行に加えられたすべての変更または最新の変更のみのコピーを保存できます。表をバージョン対応にする際に(without overwrite履歴オプションを指定して)すべての変更を保存する場合は、すべての行バージョンに対して行われたすべての変更の永続履歴を保存します。また、ユーザーが希望する時点に移動して、その作業領域に存在していたデータベースを表示できるようにします。

Workspace Managerは、作業領域、セーブポイント、履歴情報、権限、アクセス・モードおよびWorkspace Managerロックを管理し、競合を検出および解消するために、新規アプリケーションおよび既存アプリケーションに追加できる総合的なPL/SQL APIを提供します。また、これらの操作のほとんどは、Oracle Enterprise Managerのグラフィカル・ユーザー・インタフェースを使用して実行することもできます。

Workspace Managerによって作成される別のデータベース・オブジェクトは、行バージョンを作業領域にマップするデータベース全体のシステム表です。この表は、ユーザーからは見えません。

親トピック: Workspace Managerの概要

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 作業領域ツリー

図1-1の説明が続きます
「図1-1 作業領域ツリー」の説明

特定のニーズのために子作業領域を作成するか、またはセーブポイントを作成するかの決定は、設計段階で行います。詳細は、「設計面の問題: セーブポイントまたは子作業領域のいずれを作成するか」を参照してください。

親トピック: Workspace Managerの概要

1.1.2 セーブポイントの使用

セーブポイントとは、データ変更をロールバックできる作業領域内のポイントです。Workspace Managerは、不要な変更が含まれている行バージョンを削除して、ロールバックを実行します。

明示的セーブポイントとは、作成して名前を付けるセーブポイントです。バージョン対応表内の変更は、後でセーブポイントまでロールバックできます。または、セーブポイントに移動して、そのセーブポイントが作成された時点でのデータベース全体の状態(バージョン対応の行を含む)を表示できます。図1-2のSP1、SP2、SP3およびSP4は、指定された作業領域に作成された明示的セーブポイントです。(図1-2ではセーブポイントは破線で示されています。)

図1-2 セーブポイント

図1-2の説明が続きます。
「図1-2 セーブポイント」の説明

また、新規の作業領域が作成されると、暗黙的セーブポイントが自動的に作成されます。暗黙的セーブポイントは、子作業領域のユーザーが作業領域作成時にフリーズされたデータベースのビューを取得するために必要です。したがって、図1-2では、Workspace1およびWorkspace4の作成に対応してLIVE作業領域内に2つの暗黙的セーブポイント(SPaおよびSPd)が作成され、Workspace2およびWorkspace3の作成に対応してWorkspace1内に2つの暗黙的セーブポイント(SPbおよびSPc)が作成されます。また、Workspace5の作成に対応してWorkspace4内に1つの暗黙的セーブポイント(SPe)が作成されます。

Workspace Managerは、LATESTという名前を使用して、作業領域内の最新バージョンを示す論理セーブポイントを指定します。セーブポイントがDBMS_WMサブプログラム(プロシージャまたはファンクション)のオプションのパラメータであるときは、多くの場合、LATESTがデフォルトです。

削除可能なセーブポイントとは、CompressWorkspace、CompressWorkspaceTreeおよびDeleteSavepoint プロシージャによって削除可能なセーブポイントです。次の条件のいずれかに該当する場合、セーブポイントは削除可能です。

  • 明示的セーブポイントである。

  • 子作業領域と依存性がない暗黙的セーブポイントである。

親トピック: Workspace Managerの概要

1.1.2.1 設計面の問題: セーブポイントまたは子作業領域のいずれを作成するか

Workspace Managerでは、ある時点でプロジェクトを保存するために、セーブポイントを作成するか、子作業領域を作成するかという設計面の問題が発生する可能性があります。セーブポイントと子作業領域のいずれでも、一連の変更のグループ化、異なる行バージョンの変更の比較、および一連の変更のロールバックが可能です。ただし、セーブポイントを作成すると、同一作業領域内で継続して変更を加えることができ、その作業領域内の他のユーザーがすぐに変更にアクセスできるようになります。(別の作業領域内の変更は、現行の作業領域がリフレッシュまたはマージされるまで、ユーザーに対して表示されません。) また、セーブポイントを作成すると一連の変更を簡単にアーカイブできるため、後でそれらの変更にロールバックできます。

これに対し、子作業領域を作成すると、一連の複雑な変更を加えることができる分離された環境を提供でき、これらの変更を親作業領域(本番データなど)から完全に削除できます。あるシナリオに基づいて独立した環境を設定し、親作業領域内の通常のユーザーがこのシナリオのデータにアクセスする必要がない場合は、親作業領域内にセーブポイントを作成するかわりに、子作業領域を作成してください。

親トピック: セーブポイントの使用

1.1.3 作業領域内の変更のマージおよびロールバック

作業領域は、マージまたはロールバックできます。

作業領域のマージでは、子作業領域で行われた変更がその親作業領域に適用されます。その後、子作業領域は削除されます。作業領域をマージするには、MergeWorkspaceプロシージャを使用します。

作業領域のロールバックでは、作業領域内のすべてのデータ変更(行バージョン)、または明示的セーブポイント以降のすべての変更のいずれかが削除されます。

  • 作業領域内のすべての変更をロールバックするには、RollbackWorkspaceプロシージャを使用します。

  • セーブポイント以降の作業領域内の変更をロールバックするには、RollbackToSPプロシージャを使用します。

    ノート:

    指定したセーブポイント以降に暗黙的セーブポイントが作成されている場合、まずその暗黙的セーブポイントが作成される原因となった子作業領域をマージまたは削除しないかぎり、そのセーブポイントにロールバックできません。たとえば、「セーブポイントの使用」の図では、Workspace3 (暗黙的セーブポイントSPcが作成された原因)がマージまたは削除されるまで、Workspace1内のユーザーはセーブポイントSP1にロールバックできません。

オープン状態のトランザクションがある作業領域は、ロールバックできません。作業領域のロールバックでは、作業領域構造は後で使用するために残され、作業領域内のデータのみが削除されます。(作業領域を完全に削除するには、RemoveWorkspaceプロシージャを使用します。詳細は、「作業領域の削除」を参照してください。)

親トピック: Workspace Managerの概要

1.1.4 マージまたはリフレッシュ操作前に行う競合の解消

子作業領域がマージされると、子作業領域内の行変更がその親作業領域に取り込まれます。子作業領域がリフレッシュされると、親作業領域内の行変更が子作業領域に取り込まれます。子作業領域と親作業領域の両方で行が変更されると、データの競合が発生します。マージまたはリフレッシュ操作が要求されると、競合が自動的に検出され、競合(xxx_CONF)ビューに表示されます。表ごとに1つの競合ビューがあります。詳細は、「xxx_CONFビュー」を参照してください。このビューには、競合が発生している2つの作業領域内の行の列値がリストされます。

競合は、セッションに対し作業領域競合のコンテキストを設定してからResolveConflictsプロシージャを使用して、手動で解消する必要があります。それぞれの競合について、子作業領域の行を保存するか、親作業領域の行を保存するか、または共通のベース行を保存するか(行の元のデータ値を保存する(変更なし))を選択できます。マージ操作(MergeWorkspace)またはリフレッシュ操作(RefreshWorkspace)を実行する前に、競合を解消する必要があります。

ベースの行は、子作業領域での最初の更新または削除操作時では、現在参照できる行です。挿入操作の場合、挿入される行が親作業領域の祖先バージョンで以前に削除されていれば、ベースの行はその削除された行ですが、それ以外では、ベースの行は存在しません。親の行は、競合解消時では、親作業領域で現在参照できる行であり、子の行は、競合解消時では、子作業領域で現在参照できる行です。

データが存在しないことは競合ではありません。この場合は、xxx_DIFFビュー(「xxx_DIFFビュー」を参照)を使用して、ある作業領域での変更を削除できます(他の作業領域に行が存在しないか行への変更が存在しない場合のみ)。

競合の一般的な解消手順は、次のとおりです。

  1. GotoWorkspaceプロシージャまたはSetConflictWorkspaceプロシージャを使用して、セッションに対し作業領域競合のコンテキストを設定します。

  2. xxx_CONFビュー(「xxx_CONFビュー」を参照)を調べて、どのような競合が存在するかを確認します。

  3. BeginResolveプロシージャを実行します。

  4. 影響を受ける表と作業領域の組合せごとに1回、ResolveConflictsプロシージャを実行します。

  5. すべての競合を解消した後で、次のいずれかのプロシージャを実行します。

    • CommitResolve: 前述のステップのすべての変更を永続的な変更にする場合。(ただし、次のステップに示すとおり、MergeWorkspaceまたはRefreshWorkspaceプロシージャを実行するまでは、データベース内の変更は永続的な変更にはなりません。)

    • RollbackResolve: 前述のステップのすべての変更を廃棄する場合。(すべての変更を破棄する場合、次のステップは実行しないでください。)

  6. 標準のデータベース・コミット操作を行い、MergeWorkspaceまたはRefreshWorkspaceプロシージャを実行します。

親トピック: Workspace Managerの概要

1.1.5 作業領域のフリーズおよびアンフリーズ

作業領域へのアクセス制限を設定および解除することにより、作業領域への読込みおよび書込みを制御できます。作業領域がアクセス制限されている場合は、作業領域へアクセスし、バージョン対応表内の行に変更を加えるためのユーザー権限が制限されます。作業領域へのアクセスは、アクセス不可、読取り専用、1ユーザーのみ(1WRITER)のいずれかのモードで制限できます。

作業領域へのアクセスを制限するには、FreezeWorkspaceプロシージャを使用します。作業領域へのアクセス制限を解除するには、UnfreezeWorkspaceプロシージャを使用します。

また、プロシージャによっては1つ以上の作業領域のアクセスを自動的に制限します。表1-1に、これらのプロシージャ、影響を受ける作業領域、およびアクセス制限される作業領域のモードを示します。(モードの値の詳細は、「DBMS_WMパッケージ: リファレンス」のFreezeWorkspaceプロシージャの説明を参照してください。)

表1-1 プロシージャのアクセス制限の結果

プロシージャ 作業領域およびモード

BeginResolve

指定された作業領域: 1WRITER

MergeWorkspace

指定された作業領域: NO_ACCESS

親作業領域: READ_ONLY

CompressWorkspace

指定された作業領域: NO_ACCESS(LATEST以外のセーブポイントにセッションがないことも確認します)

CompressWorkspaceTree

指定された作業領域: NO_ACCESS(LATEST以外のセーブポイントにセッションがないことも確認します)

CreateSavepoint

指定された作業領域: READ_ONLY

DeleteSavepoint

指定された作業領域: NO_ACCESS

CreateWorkspace

指定された作業領域: READ_ONLY

RemoveWorkspace

指定された作業領域: NO_ACCESS

RefreshWorkspace

指定された作業領域: READ_ONLY

親作業領域: READ_ONLY

RollbackResolve

指定された作業領域: 1WRITER

RollbackWorkspace

指定された作業領域: NO_ACCESS

親トピック: Workspace Managerの概要

1.1.6 作業領域の削除

作業領域は、RemoveWorkspaceプロシージャを使用して削除できます。RemoveWorkspaceを実行すると、作業領域内のデータがロールバックされ、その後、作業領域構造が削除されます。RemoveWorkspaceTreeプロシージャを使用すると、作業領域のツリー全体を削除できます。このプロシージャは、作業領域およびそのすべての子作業領域を削除します。作業領域内にユーザーがいる場合、その作業領域は削除できません。

親トピック: Workspace Managerの概要

1.1.7 Workspace Managerイベントの使用

数種類のWorkspace Manager操作をイベントとして取得し、Oracle Advanced Queuing(AQ)フレームワークを介してアプリケーションに通信できます。非同期通知、永続性、伝播、アクセス制御、履歴およびルールベースのサブスクリプションなど、AQのメッセージ機能をWorkspace Managerイベントに使用できます。

Workspace Managerイベントのサポートには、ALLOW_CAPTURE_EVENTS Workspace Managerシステム・パラメータ、SetCaptureEventプロシージャおよびWM_EVENTS_INFOメタデータ・ビューが含まれています。

Workspace Managerイベントおよびアプリケーションでの使用方法については、「Workspace Managerイベント」を参照してください。

親トピック: Workspace Managerの概要

1.1.8 Workspace Managerの操作の自動コミット

デフォルトでは、Workspace Managerの多くの操作は、自律型データベース・トランザクションとして実行され、終了時にコミットされます。つまり、このようなトランザクションは独立したトランザクションであり、現行のデータベース・トランザクション内部からコールされ、コール側トランザクションのコンテキストをそのまま残し、Workspace Manager操作を実行した後、その操作を自動的にコミットし、コール側トランザクションのコンテキストに戻り、そのトランザクションを継続します。このように動作するWorkspace Manager (DBMS_WM)サブプログラムには、オプションのauto_commitパラメータがあります。このパラメータのデフォルト値は、TRUEです。

たとえば、CompressWorkspaceプロシージャはデフォルトで自律型トランザクションを起動し、作業領域を圧縮し、圧縮操作をコミットした後、コール側トランザクションのコンテキストに戻り、現行のデータベース・トランザクションを継続します。

ただし、自律型トランザクションを開始するのではなく、コール側トランザクションのコンテキストでこのようなサブプログラムを実行する場合は、auto_commitパラメータ値をFALSEに指定します。この場合、Workspace Manager操作は現行のデータベース・トランザクションの一部として実行され、オープン状態の現行のトランザクションがない場合は、Workspace Manager操作は新しいトランザクションを開始します。いずれの場合も、そのトランザクションがコミット操作によって終了するまで、Workspace Manager操作は有効になりません。たとえば、auto_commitパラメータにFALSEを指定してCompressWorkspaceプロシージャをコールすると、トランザクションがコミットされるまで作業領域は圧縮されません。またトランザクションがロールバックされた場合、作業領域は圧縮されません。

auto_commitパラメータをFALSEに指定した場合は、トランザクションを明示的にコミットまたはロールバックする必要があることに注意してください。

auto_commitパラメータ値がTRUEで、オープン状態のトランザクションが存在する場合は、次の考慮点が適用されます。

  • CompressWorkspaceプロシージャおよびCompressWorkspaceTreeプロシージャでは、オープン状態のトランザクションが存在する場合、例外が発生します。

  • その他のすべてのWorkspace Managerプロシージャでは、修正が必要な表の親作業領域または子作業領域内にオープン状態のトランザクションが存在する場合、例外が発生します。

親トピック: Workspace Managerの概要

1.1.9 連続的にリフレッシュされる作業領域

連続的にリフレッシュされる作業領域とは、データ変更が親作業領域内でコミットされるか、別の子作業領域から親作業領域にマージされるたびに、親作業領域から自動的にリフレッシュされる作業領域です。連続的にリフレッシュされる作業領域の場合、RefreshWorkspaceプロシージャをコールする必要はありません。

作業領域ツリーのブランチにある作業領域は、連続的にリフレッシュできます。親作業領域が連続的にリフレッシュされるかどうかにかかわらず、子作業領域は連続的にリフレッシュされる作業領域にできます。ただし、親作業領域が連続的にリフレッシュされる作業領域である場合、その子作業領域も連続的にリフレッシュされる必要があります。

連続的にリフレッシュされる作業領域を作成するには、CreateWorkspaceプロシージャのコールでisrefreshedパラメータにTRUEを指定します。連続的にリフレッシュされる作業領域の作成に適用されるルールについては、CreateWorkspaceプロシージャの「使用上のノート」を参照してください。

連続的にリフレッシュされない作業領域を連続的にリフレッシュされるように変更するには、ChangeWorkspaceTypeプロシージャを使用します。

作業領域が連続的にリフレッシュされない場合は、親作業領域内のデータ変更を作業領域内で参照できるかどうかの確認が必要になるたびに、RefreshWorkspaceプロシージャをコールする必要があります。

親トピック: Workspace Managerの概要

1.1.10 複数の親を持つ作業領域

複数の親を持つ作業領域とは、2つ以上の親作業領域を持つ子作業領域です。作業領域は、最初は1つの親を持つ作業領域として作成されます。ただし、必要に応じて既存の作業領域に他の作業領域を親作業領域として追加し、複数の親を持つ作業領域にすることができます。複数の親を持つ作業領域では、すべての親作業領域と祖先作業領域のデータを参照でき、親作業領域とマージして親作業領域からリフレッシュできます。

図1-3は、図1-1の作業領域と同じ階層を示します。ただし、Workspace3は、Workspace1およびWorkspace4の2つの親を持つ作業領域である点が異なります。

図1-3 作業領域階層内で複数の親を持つ作業領域

図1-3の説明が続きます
「図1-3 作業領域階層内で複数の親を持つ作業領域」の説明

複数の親を持つ作業領域を、複数の親を持つリーフ作業領域と呼ぶこともあります。したがって、図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の静的データ・ディクショナリ・ビュー」を参照)が用意されています。

親トピック: Workspace Managerの概要

1.1.11 バージョン対応表のインフラストラクチャ

EnableVersioningプロシージャを使用して表をバージョン対応にする場合、Workspace Managerは自動的に操作を実行し、DBA以外のユーザーには表示されないがWorkspace Manager自身の機能は許可されるデータ構造を作成します。Workspace Managerによって保持される情報には、静的データ・ディクショナリ・ビュー(「Workspace Managerの静的データ・ディクショナリ・ビュー」を参照)に格納されるものと、ユーザーがアクセスできないシステム・データ構造に格納されるものがあります。

バージョン対応表の場合、Workspace Managerはその表名を<table-name>_LTに変更し、この表にバージョニング・メタデータを格納するための列をいくつか追加します。追加される列の名前は、WM_で始まります(WM_VERSION、WM_CREATETIME、WM_RETIRETIME、WM_NEXTVER、WM_DELSTATUS、WM_LTLOCK)。

ユーザーやアプリケーションがSQL文に<table-name>_LT表を指定することはできません。引き続き元の表名(<table-name>)を指定してください。(バージョン対応表に関連付けられている<table_name>_LT表の名前を検索する必要がある場合や、<table_name>_LT表の有無をチェックして表がバージョン対応かどうかを調べる必要がある場合は、GetPhysicalTableNameファンクションを使用します。)

Workspace Managerは、元の表(<table-name>)にビューを作成するだけではなく、挿入、更新および削除操作用に、そのビューに対するINSTEAD OFトリガーも作成します。アプリケーションが、バージョン対応表内のデータを挿入、更新または削除するための文を実行すると、適切なINSTEAD OFトリガーが実際に操作を実行します。ビューにアクセスすると、作業領域のメタデータを使用して、ユーザーの現行の作業領域に関連する行バージョンのみ表示されます。

Workspace Managerでは、インフラストラクチャ・オブジェクトの作成時に元のオブジェクト名が使用されるため、オブジェクトの種類によっては、その名前に有効な長さの最大値が、Oracle AI Databaseで許可される最大値よりも短くなります。データベースの互換性設定に基づいて、30文字または128文字の識別子をサポートするようにデータベースを定義できます。互換性設定が12.2以上の場合、識別子の長さ(<DB–identifier–length>)は128であり、それ以外の場合は30です。特定のオブジェクトの長さ制限は、その<DB–identifier–length>値のオフセット(その値から減算される値)で表現されます。

表1-2に、バージョン対応表および関連オブジェクトに対する名前の長さの最大値のガイドラインを示します。(「Workspace Managerの予約語および予約文字」で、特定の名前に対する予約語および予約文字の詳細も参照してください。)

表1-2 Workspace Managerの名前の長さのガイドライン

オブジェクトの種類 名前の文字数の最大値

表

<DB–identifier–length> – 5

列

<DB–identifier–length> – 2

索引

<DB–identifier–length> (<DB–identifier–length> — BeginDDLプロシージャおよびCommitDDLプロシージャのコール間で索引が作成または変更された場合は4)

トリガー

<DB–identifier–length>

制約

<DB–identifier–length> (<DB–identifier–length> - BeginDDLプロシージャおよびCommitDDLプロシージャのコール間で制約が作成または変更された場合は4)

Workspace Managerでは、バージョン対応表に対し、SQL MERGE文(あらゆる使用方法)、およびINSERT文またはUPDATE文でのRETURNING句をサポートしていません。RETURNING句の制約の原因は、Workspace Managerによりバージョン対応表でINSTEAD OFトリガーを持つビューが作成されても、Oracle AI Databaseはビュー上で定義されたINSTEAD OFトリガーを持つRETURNING句をサポートしていないことにあります。

親トピック: Workspace Managerの概要

1.1.12 行バージョンおよび履歴コピーの作成

この項では、Workspace Managerが新しい行バージョンを作成し、古いバージョンの履歴コピーをメンテナンスするプロセスについて説明します。

新しい行バージョンは、次のいずれかを実行すると、バージョン対応表に作成されます。

  • 現行の作業領域で明示的セーブポイントを作成し、行を更新する。

  • 現行の作業領域の下に子作業領域を作成する(CreateWorkspaceプロシージャを使用)、したがって現行の作業領域に暗黙的セーブポイントを作成する。GotoWorkspaceプロシージャを実行して子作業領域に移動し、行を更新する。

表で履歴が有効になっているか、別のセーブポイントが作成されないかぎり、その後のあらゆる現行の行の更新で、現行の行バージョンが上書きされます。

  • 上書きを伴わない履歴を有効にする(VIEW_WO_OVERWRITE)と、現行の行バージョンを更新するたびに、変更とトランザクション時間に基づくタイムスタンプが適用された現行の行バージョンの完全なコピーが作成されます。このコピーは、新しい現行の行バージョンになります。

  • 上書きを伴う履歴を有効にする(VIEW_W_OVERWRITE)と、現行の行バージョンが更新されるたびに現行の行バージョンが上書きされ、トランザクション・タイムスタンプが更新されます。

  • 作業領域にセーブポイントが作成されると、行への次の変更によって新しいバージョンが作成され、履歴サイクルが再び開始されます。

作業領域で作成される行バージョンは、MergeWorkspaceプロシージャまたはMergeTableプロシージャを実行しないかぎり、親作業領域から参照できません。

子作業領域に対してMergeWorkspaceプロシージャを実行する場合、子作業領域の現行の行バージョンだけが親作業領域にマージされます。remove_workspaceパラメータをTRUEに指定すると、子作業領域が削除されるときに子作業領域のすべての中間行バージョンが削除されます。子作業領域に作成されたすべての中間バージョンを保持するには、remove_workspaceパラメータをFALSE(デフォルト)にする必要があります。

子作業領域でCompressWorkspaceプロシージャを実行して中間セーブポイントを削除する場合、その行バージョンの関連履歴コピーも削除することができます。これらのコピーを削除しない場合、これらのコピーは次のバージョンに関連付けられます。

中間行バージョンは、読取り専用アクセスのためにのみ選択できます。読取り専用アクセスのために中間行バージョンを選択するには、まだその作業領域に移動していない場合は移動し(GotoWorkspaceプロシージャ)、GotoDateプロシージャを実行してセッション・コンテキストを履歴時間に設定するか、GotoSavepointプロシージャを実行してセッション・コンテキストを特定のセーブポイントに設定します。後続のSELECT文は、読取り専用アクセスのために、指定された日付またはセーブポイントの時点で最新の行バージョンを選択します。

例1-1に、暗黙的セーブポイントと明示的セーブポイントの作成後にバージョン対応表の行バージョンが作成される例を示します。たとえば、EMP表にEMPNO、SALARYおよびCOMMISSIONという列が含まれているとします。

VIEW_WO_OVERWRITE履歴オプションが指定された表に対して例1-1を実行すると、xxx_HISTビュー(「xxx_HISTビュー」を参照)には、DML操作ごとに1行が含まれます。たとえば: 

select salary, commission, wm_workspace, wm_optype from EMP_HIST where empno = 100;
SALARY COMMISSION WM_WORKSPACE WM_OPTYPE

0

0

LIVE

I

10000

0

LIVE

U

10000

1000

LIVE

U

20000

1000

Workspace 1

U

20000

2000

Workspace 1

U

30000

3000

LIVE

U

40000

3000

LIVE

U

40000

4000

LIVE

U

40000

4000

LIVE

D

ただし、VIEW_W_OVERWRITE履歴オプションまたはNONE履歴オプションが指定された表に対して例1-1を実行すると、xxx_HISTビュー(「xxx_HISTビュー」を参照)には、セーブポイントごとに1行のみが含まれます。これは、同一セーブポイント内では行バージョンが後続のDML操作によってオーバーライドされるためです。たとえば: 

select salary, commission, wm_workspace, wm_optype from EMP_HIST where empno = 100;
SALARY COMMISSION WM_WORKSPACE WM_OPTYPE

10000

1000

LIVE

U

20000

2000

Workspace 1

U

30000

3000

LIVE

U

40000

4000

LIVE

D

例1-1 暗黙的なセーブポイントと明示的なセーブポイントの作成後に作成される行バージョン

execute dbms_wm.GotoWorkspace('LIVE') ;
insert into EMP(empno, salary, commission) values (100, 0, 0) ;
update EMP set salary = 10000 ;
update EMP set commission = 1000 ;
commit ;
 
–- CreateWorkspace creates an implicit savepoint in 'LIVE'; DML operations
–- create new row versions for both workspaces.
execute dbms_wm.CreateWorkspace('WorkSpace 1') ;
execute dbms_wm.GotoWorkspace('WorkSpace 1') ;
update EMP set salary = 20000 ;
update EMP set commission = 2000 ; 
commit ;
 
execute dbms_wm.GotoWorkspace('LIVE') ;
update EMP set salary = 30000, commission = 3000 ;
commit ;
 
-– CreateSavepoint creates an explicit savepoint in 'LIVE'; DML operations
-– create new row versions for only the LIVE workspace.
execute dbms_wm.CreateSavepoint('LIVE', 'SP1') ;
update EMP set salary = 40000 ;
update EMP set commission = 4000 ; 
delete EMP where empno = 100 ;
commit ;

親トピック: Workspace Managerの概要

1.1.13 Workspace Managerのスキーマ、メタデータおよびパッケージ

Workspace Managerは、WMSYSという名前のユーザーを作成します。WMSYSスキーマは、Workspace Managerのすべてのメタデータ情報を格納するために使用します。

Oracle AI Database 26aiより前では、ワークスペース対応表(ビュー、トリガー、プロシージャなど)に関連するセカンダリ・オブジェクトが、WMSYSスキーマの下に作成されました。したがって、WMSYSスキーマには、ユーザー・スキーマからのデータにアクセスするための広範な権限がありました。ただし、リリース26ai以降では、ワークスペース対応表に対応するすべてのセカンダリ・オブジェクトが、これらの表を所有するユーザー・スキーマに格納されます。WMSYSには、WMSYSスキーマに格納されたメタデータを保持するために必要な最小限の権限のみが付与されます。

DBMS_WMパブリック・シノニムを持つPL/SQLパッケージには、Workspace Managerサブプログラム(プロシージャおよびファンクション)が含まれています。

PUBLICユーザー・グループには、次の権限が付与されます。

親トピック: Workspace Managerの概要

1.1.13.1 ユーザー・スキーマで作成されるセカンダリ・メタデータ・オブジェクト

各バージョン対応表には、通常のメタデータ・オブジェクトに加えて、他のセカンダリ・オブジェクトがユーザー・スキーマに作成されます。

これらのセカンダリ・オブジェクトは、接頭辞WM$を使用して作成されます。リリース26aiより前では、これらのWM$接頭辞付き表がWMSYSスキーマに作成されていたことに注意してください。

たとえば、次のように表をバージョン対応にする場合:

EXECUTE DBMS_WM.enableversioning('scott.dept_table');

次のような類似したセカンダリ・オブジェクトがユーザー・スキーマに作成されます。

WM$PK_TMP_TAB_1$
WM$1$$
WM$1$_MW$
WM$1$_CONS$
WM$1$_HIST$
WM$1$_BPKC$
WM$1$_PKC$
WM$1$_CONF$
WM$1$_PKDB$
WM$1$_PKDC$
WM$1$_PKD$
WM$1$_DIFF$
WM$1$_LOCK$
DEPT_TABLE_CONF
DEPT_TABLE_DIFF
DEPT_TABLE_HIST
DEPT_TABLE_LOCK
DEPT_TABLE_MW
WM$1$_BASE$
DEPT_TABLE_LT
DEPT_TABLE
DEPT_TABLE_AUX

関連トピック

親トピック: Workspace Managerのスキーマ、メタデータおよびパッケージ

1.1.13.2 デフォルトのWMSYSユーザー権限

WMSYSスキーマのデフォルトのデータベース権限は、リリース26aiで更新されています。

次に、WMSYSユーザーに付与されるデフォルトの権限を示します。

  • ADMINISTER ROW LEVEL SECURITY POLICY
  • INHERIT ANY PRIVILEGES
  • SELECT ANY DICTIONARY
  • ADMINISTER DATABASE TRIGGER
  • EXECUTE ANY TYPE
  • CREATE TABLE UNLIMITED TABLESPACE
  • ALTER SESSION
  • CREATE SESSION

親トピック: Workspace Managerのスキーマ、メタデータおよびパッケージ

1.1.13.3 リリース26aiへのアップグレード後のメタデータの移行

Oracle AI Database 26ai以降では、ワークスペース対応表のすべてのセカンダリ・オブジェクトが、これらの表を所有するユーザー・スキーマに作成されます。

リリース26aiより前では、これらのセカンダリ・メタデータ・オブジェクトの一部がWMSYSスキーマの下に作成されました。このスキーマの変更により、リリース26aiにアップグレードすると、以前のワークスペース対応表が使用できなくなります。したがって、データベースのアップグレードが完了したら、SYSユーザーとしてデータベースに接続し、次のアップグレード後のステップを実行します。

GRANT INHERIT PRIVILEGES ON USER SYS TO WMSYS;
 
EXECUTE wmsys.owm_mig_pkg.enableversionTopoIndexTables;
EXECUTE wmsys.owm_mig_pkg.AllLwEnableVersioning(:old_owm_version_for_upgrade);
EXECUTE wmsys.owm_mig_pkg.recreatePtUpdDelTriggers;
EXECUTE wmsys.owm_mig_pkg.fixWMMetaData(:old_owm_version_for_upgrade);
EXECUTE wmsys.owm_mig_pkg.recompileAllObjects;
EXECUTE wmsys.owm_mig_pkg.modifySystemTriggers('ENABLE_T');
 
REVOKE INHERIT PRIVILEGES ON USER SYS FROM WMSYS;
 
SELECT * FROM wm_installation ORDER BY 1;
SELECT version, status FROM dba_registry WHERE comp_id='OWM';

親トピック: Workspace Managerのスキーマ、メタデータおよびパッケージ