1. PL/SQLパッケージおよびタイプ・リファレンス
  2. DBMS_LOGSTDBY

97 DBMS_LOGSTDBY

DBMS_LOGSTDBYパッケージは、ロジカル・スタンバイ・データベース環境を構成および管理するためのサブプログラムを提供します。

この章のトピックは、次のとおりです:

参照:

『Oracle Data Guard概要および管理』

97.1 DBMS_LOGSTDBYの概要

DBMS_LOGSTDBYパッケージを使用して、SQL適用(ロジカル・スタンバイ・データベース)環境を管理できます。

DBMS_LOGSTDBYパッケージのサブプログラムを使用すると、次の主な目的を実現できます。

  • SQL適用で使用される構成パラメータの管理

    たとえば、ロジカル・スタンバイ・データベースへのトランザクションの適用方法、使用する共有プールの大きさ、SQL適用での変更の調査および適用に使用するプロセスの数などを制御します。

  • 適切なレベルのサプリメンタル・ロギングが有効になっていること、およびLogMinerディクショナリがロジカル・スタンバイ・データベースの作成に対して適切に構築されていることの確認

  • ロジカル・スタンバイ・データベース内の選択した表またはスキーマ全体に対する変更の適用をスキップする方法の提供、およびSQL適用で発生する例外の処理方法の指定

  • メンテナンスが必要なロジカル・スタンバイ・データベース内の表へのアクセス制御

97.2 DBMS_LOGSTDBYのセキュリティ・モデル

DBMS_LOGSTDBYパッケージを使用するには、DBAロールが必要です。

プロトタイプのロールLOGSTDBY_ADMINISTRATORは、デフォルトではDBMS_LOGSTDBYに対するRESOURCE権限およびEXECUTE権限を伴って作成されます。このロールを使用する場合は、ロールを付与されたユーザーがSQL適用の開始と停止、およびデータベース・ガードの有効化と無効化を制御できるように、このロールに対してALTER DATABASE権限およびALTER SESSION権限を付与することを検討してください。

トランザクションのスキップに関連するプロシージャ(SKIPとUNSKIP、SKIP_ERRORとUNSKIP_ERROR、SKIP_TRANSACTIONとUNSKIP_TRANSACTION)を実行するには、それらのプロシージャのスコープにワイルドカード・スキーマが含まれている場合があるため、それらのすべてでDBA権限が必要です。SKIPプロシージャを指定する場合は、それらのプロシージャが動作するスキーマに対して適切な権限を持つ安全なアカウント(SYSなど)によってそれらのプロシージャが所有されるようにすることをお薦めします。

EDSベースのレプリケーションに関連するプロシージャでは、DBMS_LOGSTDBYパッケージに対するEXECUTE権限が必要です。また、ターゲット・スキーマのシャドウ表を作成(および削除)するために、CREATE TABLEシステム権限とDROP TABLEシステム権限も必要です。マテリアライズド・ビューが使用されている場合は、CREATE MATERIALIZED VIEWシステム権限とDROP ANY MATERIALIZED VIEWシステム権限も必要です。

ノート:

Oracle Database 12cリリース2 (12.2.0.2)からは、拡張データ型サポート(EDS)は推奨されていません。EDSでサポートされているすべてのOracleのデータ型は、ロジカル・スタンバイまたはOracle GoldenGateでネイティブにサポートされています。

97.3 DBMS_LOGSTDBYの定数

DBMS_LOGSTDBYパッケージは、パラメータ値の指定に使用するいくつかの列挙定数を定義します。列挙定数にはパッケージ名を接頭辞として付加する必要があります(DBMS_LOGSTDBY.SKIP_ACTION_SKIPなど)。

次の表では、DBMS_LOGSTDBY.SKIPプロシージャ内のproc_nameパラメータの定数について説明します。

表97-1 SKIPオプション・フラグの定数

定数 説明

MAX_EVENTS

DBA_LOGSTDBY_EVENTSビューで記録するイベントの最大数。DBMS_LOGSTDBYのAPPLY_SETプロシージャを参照してください。

SKIP_ACTION_APPLY

DBMS_LOGSTDBY.SKIP.に登録されたユーザー定義プロシージャ内で使用されますSQL適用でDDLまたはPL/SQL文の適用が必要な場合に、DBMS_LOGSTDBY_CONTEXTを使用してSKIP_ACTIONパラメータの値を設定するときはこの定数を使用します。

SKIP_ACTION_ERROR

DBMS_LOGSTDBY.SKIPに登録されたユーザー定義プロシージャ内で使用されます。SQL適用でエラー出力が必要な場合に、DBMS_LOGSTDBY_CONTEXTを使用してSKIP_ACTIONパラメータの値を設定するときはこの定数を使用します。

SKIP_ACTION_REPLACE

DBMS_LOGSTDBY.SKIPに登録されたユーザー定義プロシージャ内で使用されます。SQL適用で置換DDLの適用が必要な場合に、DBMS_LOGSTDBY_CONTEXTを使用してSKIP_ACTIONパラメータの値を設定するときはこの定数を使用します。(この定数は、オラクル社が提供するPL/SQLプロシージャ・コールの処理中に使用する必要はありません。)

SKIP_ACTION_SKIP

DBMS_LOGSTDBY.SKIPに登録されたユーザー定義プロシージャ内で使用されます。関連付けられたDDLまたはオラクル社が提供するPL/SQLプロシージャ・コールの省略がSQL適用で必要な場合に、DBMS_LOGSTDBY_CONTEXTを使用してSKIP_ACTIONパラメータの値を設定するときはこの定数を使用します。

97.4 DBMS_LOGSTDBYサブプログラムの要約

この表では、各プロシージャが詳しく説明されている項への参照を含め、DBMS_LOGSTDBYプロシージャの各サブプログラムについて説明します。

マルチテナント・コンテナ・データベース(CDB)では、一部のサブプログラムはルートからコールする必要があります。それ以外にも、違いがある可能性があります。詳細は、個々のサブプログラムの説明を参照してください。

ノート:

Oracle Database 12cリリース2 (12.2.0.2)からは、拡張データ型サポート(EDS)に関連するDBMS_LOGSTDBYサブプログラムは推奨されていません。EDSでサポートされているすべてのOracleのデータ型は、ロジカル・スタンバイまたはOracle GoldenGateでネイティブにサポートされています。

表97-2 DBMS_LOGSTDBYパッケージのサブプログラム

サブプログラム 説明

APPLY_SETプロシージャ

SQL適用を構成およびメンテナンスする様々なパラメータの値を設定します。

APPLY_UNSETプロシージャ

SQL適用を構成およびメンテナンスする様々なパラメータの値をデフォルトに戻します。

BUILDプロシージャ

サプリメンタル・ロギングが正しく有効化されていることを確認し、LogMinerディクショナリを作成します。

EDS_ADD_TABLE

表のEDSベースのレプリケーションを追加します。これは、プライマリ・データベース、スタンバイ・データベースの順に起動される必要があります。

EDS_EVOLVE_AUTOMATIC

EDS表の自動DDL処理を有効または無効にします。

EDS_EVOLVE_MANUAL

EDS表を手動で展開できます(つまり、EDSレプリケーションにおいて、元表に対するDDL操作に基づいた補足アクションを手動で実行できます)。

EDS_REMOVE_TABLE

指定した表のEDSベースのレプリケーションを削除します。シャドウ表やトリガーも削除されます。

INSTANTIATE_TABLEプロシージャ

プライマリ・データベース内の対応する表から、スタンバイ・データベース内に表を作成し、データを移入します。

IS_APPLY_SERVERファンクション

このファンクションは、ロジカル・スタンバイ適用サーバー・プロセスのコンテキストでPL/SQLから実行された場合、TRUEを戻します。このファンクションは、DBMS_DDL.SET_TRIGGER_FIRING_PROPERTYサブプログラムのfire_onceパラメータがFALSEに設定されている(デフォルトはTRUE)トリガーと一緒に使用します。このようなトリガーは、適用プロセスによって関連ターゲットが更新されると実行されます。このファンクションは、トリガー本体内で使用して、トリガーがプライマリまたはスタンバイで異なるアクションを実行する(またはアクションを実行しない)ようにすることができます。

MAP_PRIMARY_SCNファンクション

プライマリ・データベースに関連するSCNをロジカル・スタンバイ・データベースの対応するSCNにマップします。マップされたSCNは本質的に保守的なため、マップされたSCNを使用すると、ロジカル・スタンバイ・データベースをフラッシュバックして、プライマリ・データベースで実行されるフラッシュバック・データベース操作を補足できます。

PREPARE_FOR_NEW_PRIMARYプロシージャ

フェイルオーバーの後で使用され、フェイルオーバー動作に関係しなかったローカルのロジカル・スタンバイ・データベースで新しいプライマリ・データベースより多くのREDOが処理されないようにし、一貫性を保証するために置換する必要があるアーカイブREDOログ・ファイル・セットをレポートします。

PURGE_SESSIONプロシージャ

ロジカル・スタンバイ・データベースに適用済で、SQL適用で不要になったアーカイブREDOログ・ファイルを識別します。

REBUILDプロシージャ

フェイルオーバー操作に伴ってプライマリ・データベースに役割が変更されたデータベースで、フェイルオーバー・プロセス中にその役割の変更を処理できない場合、関連するメタデータ(LogMinerディクショナリを含む)をREDOストリームに記録します。

SET_TABLESPACEプロシージャ

SQL適用で必要なメタデータ表を、ユーザー指定の表領域に移動します。デフォルトでは、メタデータ表は、SYSAUX表領域内に作成されます。

SKIPプロシージャ

ロジカル・スタンバイ・データベースに適用しないデータベース操作を制御するルールを指定します。

SKIP_ERRORプロシージャ

エラー発生時に実行するアクションに関するルールを指定します。

SKIP_TRANSACTIONプロシージャ

ロジカル・スタンバイ・データベースに適用しないトランザクションを指定します。特定のトランザクションを適用しないことによって、ロジカル・スタンバイ・データベースのデータが破損する場合があるため、このプロシージャは注意して使用してください。

UNSKIPプロシージャ

SKIPプロシージャによって指定されたルールを削除します。

UNSKIP_ERRORプロシージャ

SKIP_ERRORプロシージャによって指定されたルールを削除します。

UNSKIP_TRANSACTIONプロシージャ

SKIP_TRANSACTIONプロシージャによって指定されたルールを削除します。

97.4.1 APPLY_SETプロシージャ

このプロシージャを使用して、ロジカル・スタンバイ・データベース環境でSQL適用を構成および管理するパラメータの値を設定します。PRESERVE_COMMIT_ORDERを除くすべてのパラメータは、SQL適用を停止しなくても変更できます。

CDBでは、APPLY_SETプロシージャはルート・データベースからコールする必要があります。

構文

DBMS_LOGSTDBY.APPLY_SET (
     inname             IN VARCHAR,
     value              IN VARCHAR);

パラメータ

表97-3 APPLY_SETプロシージャのパラメータ

パラメータ 説明

APPLY_SERVERS

変更の適用に使用するAPPLIERプロセスの数を制御します。最大値は1024です(MAX_SERVERSパラメータに、対応できる値が設定されている場合)。

EVENT_LOG_DEST

関連イベントの発生をSQL適用が記録する場所を制御します。値は次のいずれかとなります。

  • DEST_ALL: すべてのイベントがDBA_LOGSTDBY_EVENTSビューおよびアラート・ログに記録されます。

  • DEST_EVENTS_TABLE: ユーザー・データに関する情報を含むすべてのイベントが、DBA_LOGSTDBY_EVENTSビューにのみ記録されます。これはデフォルト値です。

たとえば、SQL適用がORA-1403エラーを取得すると、そのイベント全体がDBA_LOGSTDBY_EVENTSビューに記録されます。一方、アラート・ログには、SQL適用の停止原因がORA-1403であることのみが記録されます。ユーザー表または問題となる文に関する情報は、アラート・ログに記録されません。ただし、SQL適用エンジンを停止すると、これらの情報がDBA_LOGSTDBY_EVENTSビューとアラート・ログの両方に記録されます。

このパラメータは、RECORD_APPLIED_DDL、RECORD_SKIP_DDL、RECORD_SKIP_ERRORSおよびRECORD_UNSUPPORTED_OPERATIONSパラメータの動作に影響します。たとえば、RECORD_APPLIED_DDLはTRUEに設定されているが、EVENT_LOG_DESTはDEST_EVENTS_TABLEに設定されている場合、適用されるDDL文字列は、DBA_LOGSTDBY_EVENTSビューのみに記録されます。

LOG_AUTO_DEL_RETENTION_TARGET

このパラメータ設定が意味を持つのは、LOG_AUTO_DELETEがTRUEに設定されている場合のみです。このパラメータ値は、ログに含まれるすべてのREDOレコードがロジカル・スタンバイ・データベースに適用された場合に、プライマリ・データベースから受信したリモート・アーカイブ・ログをロジカル・スタンバイ・データベースに保持する期間(分)を制御します。デフォルト値は1440分です。

LOG_AUTO_DELETE

外部アーカイブREDOログ・ファイルがロジカル・スタンバイ・データベースに適用されるとすぐに、そのファイルを自動的に削除します。デフォルトでは、外部アーカイブREDOログ・ファイルは、ロジカル・スタンバイ・データベースで適用されてから24時間(LOG_AUTO_DEL_RETENTION_TARGETパラメータのデフォルト値)が経過するまで削除されません。TRUEに設定すると、アーカイブREDOログ・ファイルの自動削除が有効になります。FALSEに設定すると、自動削除は無効になります。デフォルト値はTRUEです。

MAX_EVENTS_RECORDED

DBA_LOGSTDBY_EVENTSビューで表示可能な最新イベントの数。SQL適用で発生したすべてのイベントを記録するには、数値として定数DBMS_LOGSTDBY.MAX_EVENTSを使用します。デフォルト値は10,000です。

MAX_SERVERS

SQL適用で読取りとREDOの適用に使用するプロセスの数。デフォルト値は9です。最大値は2048です。

MAX_SGA

SQL適用で使用するシステム・グローバル領域(SGA)の共有プールのMB数。デフォルト値は、30MBまたはSHARED_POOL_SIZEに設定された値の4分の1のいずれか小さい方です。最大サイズは4095MBです。

PREPARE_SERVERS

変更の準備に使用するPREPARERプロセスの数を制御します。最大値は1024です(MAX_SERVERSパラメータに、対応できる値が設定されている場合)。

PRESERVE_COMMIT_ORDER

TRUE: トランザクションは、プライマリ・データベースでコミットされた順序と同じ順序でロジカル・スタンバイ・データベースに適用されます。これがデフォルトのパラメータ設定です。

FALSE: オーバーラップしていない行セットが含まれるトランザクションは、プライマリ・データベースでコミットされた順序とは異なる順序でコミットされる場合があります。

選択したレベルに関係なく、同じ行に対する変更は、常にプライマリ・データベースで検出される順序と同じ順序で適用されます。詳細および推奨は「使用上のノート」を参照してください。

SQL適用の実行中は、このパラメータを変更できません。

RECORD_APPLIED_DDL

ロジカル・スタンバイ・データベースに適用されたDDL文をEVENT_LOG_DESTパラメータで指定された場所に記録するかどうかを制御します。次のいずれかの値を指定します。

TRUE: ロジカル・スタンバイ・データベースに適用されたDDL文が、DBA_LOGSTDBY_EVENTS表およびアラート・ログに記録されることを示します。

FALSE: 適用したDDL文は記録されないことを示します。これがデフォルトのパラメータ設定です。

RECORD_SKIP_DDL

スキップしたDDL文をEVENT_LOG_DESTパラメータで指定された場所に記録するかどうかを制御します。次のいずれかの値を指定します。

TRUE: スキップしたDDL文はDBA_LOGSTDBY_EVENTS表およびアラート・ログに記録されます。これがデフォルトのパラメータ設定です。

FALSE: スキップしたDDL文はDBA_LOGSTDBY_EVENTS表およびアラート・ログに記録されません。

RECORD_SKIP_ERRORS

スキップしたエラー(「SKIP_ERRORプロシージャ」を参照)をEVENT_LOG_DESTパラメータで指定された場所に記録するかどうかを制御します。次のいずれかの値を指定します。

TRUE: スキップしたエラーはDBA_LOGSTDBY_EVENTS表およびアラート・ログに記録されます。これがデフォルトのパラメータ設定です。

FALSE: スキップしたエラーはDBA_LOGSTDBY_EVENTS表およびアラート・ログに記録されません。

RECORD_UNSUPPORTED_OPERATIONS

ロジカル・スタンバイ・データベースでサポートされない、プライマリ・データベースで実行中のトランザクションに関する情報を取得します。このプロシージャは、情報をイベントとしてDBA_LOGSTDBY_EVENTS表に記録します。次のいずれかの値を指定します。

TRUE: 情報が取得され、DBA_LOGSTDBY_EVENTS表にイベントとして記録されます。

FALSE: 情報が取得されません。これはデフォルトです。

SQL適用の実行中にパラメータを変更した場合、この変更は後で有効になります。このような場合、パラメータの変更が有効になった時点で、DBA_LOGSTDBY_EVENTSビューに情報行が挿入されます。

また、Oracle RAC構成でSQL適用を実行している間にパラメータを変更する場合は、SQL適用を実行しているインスタンスに接続する必要があります。

例外

表97-4 APPLY_SETプロシージャの例外

例外 説明

ORA-16103

この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。

ORA-16104

ロジカル・スタンバイ・オプションのリクエストが無効です。

ORA-16236

ロジカル・スタンバイ・メタデータ操作は進行中です。

使用上のノート

  • パラメータの設定をデフォルトに戻すには、APPLY_UNSETプロシージャを使用します。

  • SQL適用のチューニングおよび様々なパラメータの適切な値の設定については、『Oracle Data Guard概要および管理』を参照してください。

例

DBA_LOGSTDBY_EVENTSビューおよびアラート・ログにDDLを記録するには、次の文を発行します。 

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('RECORD_APPLIED_DDL', TRUE);

97.4.2 APPLY_UNSETプロシージャ

APPLY_UNSETプロシージャで変更したパラメータの値をデフォルトに戻すには、APPLY_SETプロシージャを使用します。

CDBでは、APPLY_UNSETプロシージャはルート・データベースからコールする必要があります。

構文

DBMS_LOGSTDBY.APPLY_UNSET (
     inname          IN VARCHAR);

パラメータ

APPLY_UNSETプロシージャのパラメータ情報は、APPLY_SETプロシージャに関する情報と同じです。パラメータ情報の詳細は、表97-3を参照してください。

例外

表97-5 APPLY_UNSETプロシージャの例外

例外 説明

ORA-16103

この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。

ORA-16104

ロジカル・スタンバイ・オプションのリクエストが無効です。

ORA-16236

ロジカル・スタンバイ・メタデータ操作は進行中です。

使用上のノート

  • パラメータにデフォルト以外の値を指定するには、APPLY_SETプロシージャを使用します。

例

適用したDDLがDBA_LOGSTDBY_EVENTSビューおよびアラート・ログに記録されるように以前に指定していた場合は、次の文を実行して、適用したDDL文に関するSQL適用の動作をデフォルトに戻すことができます。 

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('RECORD_APPLIED_DDL');

97.4.3 BUILDプロシージャ

このプロシージャをプライマリ・データベースで使用して、関連するメタデータ(LogMinerディクショナリ)情報をREDOログに記録し、その後、このREDOログはSQL適用で使用されます。このプロシージャによって、必要に応じて、データベース全体でのプライマリ・キーおよび一意キーのサプリメンタル・ロギングが可能になります。

CDBでは、BUILDプロシージャはプライマリのルート・データベースからコールする必要があります。また、このプロシージャの実行中は、CDBにPDBを追加したり、CDBからPDBを削除することはできません。

ノート:

Oracle Database 11gリリース2 (11.2)以上を使用して作成されたデータベースでは、サプリメンタル・ロギング情報は、既存のフィジカル・スタンバイ・データベースすべてに自動的に伝播されます。ただし、それより前のリリースのデータベースの場合や、それより前のリリースを使用してデータベースを作成してから11.2にアップグレードした場合、サプリメンタル・ロギングがプライマリ・データベースで有効化されているときは、それがフィジカル・スタンバイでも有効化されているかどうかを確認する必要があります。それがフィジカル・スタンバイで有効化されていない場合、スイッチオーバーまたはフェイルオーバーを実行する前に、すべての既存のフィジカル・スタンバイ・データベースでサプリメンタル・ロギングを有効化する必要があります。これを行うには、各フィジカル・スタンバイで、次のSQLコマンドを発行します。 

SQL>  ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;

これを行わないと、フィジカル・スタンバイ・データベースの1つに対してスイッチオーバーまたはフェイルオーバーが行われた場合に、同じData Guard構成内のすべてのロジカル・スタンバイが使用できなくなります。スイッチオーバーやフェイルオーバーがすでに発生しており、サプリメンタル・ロギングが有効化されていない場合、すべてのロジカル・スタンバイ・データベースを再作成する必要があります。

構文

DBMS_LOGSTDBY.BUILD;

使用上のノート

  • サプリメンタル・ログ情報には、ロジカル・スタンバイ・データベース内の変更行を一意に識別する、REDOログ内の追加情報が含まれています。また、ロジカル・スタンバイ・データベースへの変更を効率的に適用するための情報も含まれています。

  • LogMinerディクショナリ情報を使用すると、SQL適用でREDOログ内のデータを解析できます。

  • DBMS_LOGSTDBY.BUILDは、作成する各ロジカル・スタンバイ・データベースに対して1回のみ実行する必要があります。各Oracle RACインスタンスに対してDBMS_LOGSTDBY.BUILDを使用する必要はありません。

  • DBMS_LOGSTDBY.BUILDは、プロシージャ起動時にアクティブなすべてのトランザクション(分散トランザクションを含む)が完了するまで待機してから戻ります。インダウト・トランザクションの処理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。

例

プライマリ・データベースのREDOストリーム内にLogMinerディクショナリを作成して、ロジカル・スタンバイ・データベースをインスタンス化するための追加情報を記録するには、プライマリ・データベースで次のSQL文を発行します。

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

97.4.4 EDS_ADD_TABLE

このプロシージャは、表のEDSベースのレプリケーションを追加します。これは、プライマリ・データベース、スタンバイ・データベースの順に起動される必要があります。

構文

DBMS_LOGSTDBY.EDS_ADD_TABLE (
     table_owner        IN VARCHAR2,
     table_name         IN VARCHAR2,
			     p_dblink           IN VARCHAR2);

パラメータ

表97-6 EDS_ADD_TABLEプロシージャのパラメータ

パラメータ 説明

table_owner

スタンバイ・データベースに作成または再作成する表の所有者。

table_name

スタンバイ・データベースに作成または再作成する表の名前。

p_dblink

プライマリ・データベースへのデータベース・リンク。

例外

表97-7 EDS_ADD_TABLEプロシージャの例外

例外 説明

ORA-942

表またはビューが存在しません。

ORA-16103

この操作を許可するにはSQL適用を停止する必要があります。

ORA-16130

ログ・ストリームからのサプリメンタル・ログ情報がありません。

ORA-16236

ロジカル・スタンバイ・メタデータ操作は進行中です。

ORA-16276

指定したデータベース・リンクはプライマリ・データベースに対応していません。

ORA-16278

指定した表でマルチオブジェクトのスキップ・ルールが定義されています。

ORA-16279

指定したデータベース・リンクに、操作に必要なロールがありません。

ORA-16302

拡張データ・タイプは指定した表ではサポートされていません。

ORA-16303

指定した表には、このデータベースのEDSがすでに存在します。

ORA-16304

プライマリ・データベースでは最初にプロシージャをコールする必要があります。

ORA-16306

指定した表に主キーがありません。

使用上のノート

  • このプロシージャをプライマリでコールすると、ローカル表の定義を使用してシャドウ表が作成されます。その後、元表とシャドウ表が両方ともトリガーされます。

  • このプロシージャをスタンバイでコールすると、プライマリへのデータベース・リンク(p_dblink)が必要とされます。これにより、プライマリの表定義を使用して、スタンバイのシャドウ表とそのトリガーを作成できるようになります。スタンバイでシャドウ表とそのトリガーを作成した後は、プライマリへのデータベース・リンクを使用してDBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャが元表に対してコールされます。プライマリでのコールではp_dblinkパラメータは無視され、デフォルトのNULLに設定されます。

  • エラー・チェックが事前に実行されます。一般的には、このプロシージャでサポートされていないデータ・タイプが表で見つかると、エラーが発生します。

    表がSQL適用によってすでにサポートされている場合、例外が発生します。表が拡張データ・タイプ・サポート(EDS)の対象であるかどうかを確認するには、プライマリのDBA_LOGSTDBY_EDS_SUPPORTEDビューを問い合せます。

  • このプロシージャは、プライマリで実行してからスタンバイで実行する必要があります。そうでないと、エラーが発生します。

  • ロジカル・スタンバイでのロール変更では、ロール変更を行う前に、EDSをプライマリとスタンバイの両方に追加する必要があります。プライマリにのみ追加した場合は、EDSをロール変更後に削除する必要があります。EDSコンテキストが無効になるからです。

  • ローリング・アップグレードでは、このプロシージャをプライマリでコールするだけで済みます。

  • このプロシージャはロジカル・スタンバイにはレプリケートされないため、プライマリ・データベースとスタンバイ・データベースの両方で実行する必要があります。フィジカル・スタンバイにはレプリケートされるため、ローリング・アップグレードでプロシージャを使用する際には、プライマリでのみコールしてください。

  • このプロシージャをスタンバイで実行する場合、SQL適用を停止して、データベース・ガードをSTANDBYまたはNONEのいずれかに設定する必要があります。プロシージャの実行が完了すると、表はデータベース・ガードによって保護されます。

例

表OE.CUSTOMERSのEDSを追加するには、プライマリ、スタンバイの順に、次の各コマンドを実行します。

プライマリ・データベースでは、次のコマンドを実行します。

execute dbms_logstdby.eds_add_table('OE','CUSTOMERS');

スタンバイ・データベースでは、次のコマンドを実行します。

alter database stop logical standby apply;
execute dbms_logstdby.eds_add_table('OE','CUSTOMERS','dblink-to-primary');
alter database start logical standby apply immediate;

97.4.5 EDS_EVOLVE_AUTOMATIC

このプロシージャは、EDS表の自動DDL処理を有効または無効にします。

構文

DBMS_LOGSTDBY.EDS_EVOLVE_AUTOMATIC (
     options            IN VARCHAR2);

パラメータ

表97-8 EDS_EVOLVE_AUTOMATICパラメータの説明

パラメータ 説明

options

ENABLEを指定して、EDSの自動DDL処理を有効にします。

DISABLEを指定して、EDSの自動DDL処理を無効にします。

例外

表97-9 EDS_EVOLVE_AUTOMATIC例外の説明

例外 説明

ORA-16104

指定されたパラメータは無効です。

ORA-16305

ロジカル・スタンバイではプロシージャがサポートされていません

使用上のノート

  • すべてのEDS対応表のDDLを透過的に処理するには、EDS_ADD_TABLEを最初にコールする前に、このプロシージャをプライマリ・データベースで1回コールする必要があります(ENABLEオプションを指定する)。

  • EDS固有のDDLトリガーが有効な場合、DDLを実行するたびにこのトリガーが起動されます。これにより、現在EDSが有効な表のうち、DDLによってEDSレプリケーションの実行可能性がなくなったものがないかどうかが調べられます。そのような表が存在する場合、EDS固有のメタデータを修復する補足アクションが取られるまで、影響を受けた元表に対するDMLを禁止する別個のEVOLVINGトリガーがその表で生成されます。

  • EDSを保持する表でSQL文ALTER TABLEまたはCREATE UNIQUE INDEXを実行すると、自動展開が有効にされている場合は、展開操作が開始されます。

  • このプロシージャはプライマリ・データベースでのみコールすることができ、SQL適用を介してロジカル・スタンバイ・データベースにレプリケートされます。

  • このプロシージャをスタンバイで実行する場合、データベース・ガードの設定、適用の実行の有無に関係なく正常に完了します。

例

EDSを保持するすべての表で自動展開を有効にするには、次の文を発行します。

execute dbms_logstdby.eds_evolve_automatic('ENABLE');

自動展開を有効にした後は、eds_evolveコマンドを発行する必要がなくなります。EDS表に対して発行されたDDLコマンドの実行後に自動的に発行されるからです。

EDSを保持するすべての表で自動展開を無効にするには、次の文を発行します。

execute dbms_logstdby.eds_evolve_automatic('DISABLE');

97.4.6 EDS_EVOLVE_MANUAL

このプロシージャでは、EDS表を手動で展開できます(つまり、EDSレプリケーションにおいて、元表に対するDDL操作に基づいた補足アクションを手動で実行できます)。

構文

DBMS_LOGSTDBY.EDS_EVOLVE_MANUAL (
     options            IN VARCHAR2,
     table_owner        IN VARCHAR2,
     table_name         IN VARCHAR2);

パラメータ

表97-10 EDS_EVOLVE_MANUALパラメータの説明

パラメータ 説明

options

有効なオプションは次のとおりです。

  • START: DDLの実行前に展開操作を開始します。

  • FINISH: DDLの実行後に展開操作を終了します。

  • CANCEL: 開始した展開操作をキャンセルします。

table_owner

スタンバイ・データベースに作成または再作成する表の所有者。

table_name

スタンバイ・データベースに作成または再作成する表の名前。

例外

表97-11 EDS_EVOLVE_MANUAL例外の説明

例外 説明

ORA-16302

拡張データ・タイプは指定した表ではサポートされていません。

ORA-16305

ロジカル・スタンバイではプロシージャがサポートされていません

ORA-16306

指定した表に主キーがありません。

ORA-16307

拡張データ・タイプの操作をサポートするために表が準備されていません。

使用上のノート

  • 展開操作を手動で実行するには、EDSを指定してレプリケートされる元表に影響を与える可能性があるDDLの前後で、EDS_EVOLVE_MANUALをコールする必要があります。手動展開の規定の方法は次のとおりです。

    1. STARTオプションを指定してEDS_EVOLVE_MANUALをコールします。

    2. DDLを実行します。

    3. FINISHオプションを指定してEDS_EVOLVE_MANUALをコールします。

    この順序に従わないと、データが失われる可能性があります。指定した表について、FINISHオプションを指定したプロシージャ・コールがSTARTオプションを指定したプロシージャ・コールよりも前に実行される場合、エラーが戻されます。STARTオプションを指定したプロシージャのコール時に、展開トリガーによって表に対するDMLがブロックされます。

  • このプロシージャは、プライマリ・データベースでのみ起動できます。

  • このプロシージャをスタンバイで実行する場合、SQL適用を停止して、データベース・ガードをSTANDBYまたはNONEのいずれかに設定する必要があります。プロシージャの実行が完了すると、表はデータベース・ガードによって保護されます。

例

EDS表を手動で展開するには、プライマリ・データベースで次のコマンドを実行します。

execute dbms_logstdby.eds_evolve_manual('START','OE','CUSTOMERS');
alter table oe.customers some_DDL_construct;
execute dbms_logstdby.eds_evolve_manual('FINISH','OE','CUSTOMERS');

97.4.7 EDS_REMOVE_TABLE

このプロシージャは、指定した表のEDSベースのレプリケーションを削除します。シャドウ表やトリガーも削除されます。

構文

DBMS_LOGSTDBY.EDS_REMOVE_TABLE (
     table_owner        IN VARCHAR2,
     table_name         IN VARCHAR2,

パラメータ

表97-12 EDS_REMOVE_TABLEパラメータの説明

パラメータ 説明

table_owner

スタンバイ・データベースに作成または再作成する表の所有者。

table_name

スタンバイ・データベースに作成または再作成する表の名前。

例外

表97-13 EDS_REMOVE_TABLE例外の説明

例外 説明

ORA-16103

この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。

使用上のノート

  • このプロシージャをスタンバイでコールする場合、ローカルではシャドウ表と両方のトリガーが削除されますが、プライマリでは削除されません。

    このプロシージャをプライマリでコールする場合、シャドウ表と両方のトリガーが削除された後、適用エンジンによってプロシージャがスタンバイで再実行されます。つまり、ロジカル・スタンバイでサポートされているシャドウ表とトリガーも削除されます。このアプローチを使用すると、プライマリで1回コールするだけで、表の全構成からEDSを削除できます。

  • マルチスタンバイ構成で1つのスタンバイのサポートを削除する場合は、そのスタンバイでこのプロシージャをコールできます。

  • このプロシージャは、同じ表に対するユーザーの継続的な書込みが行われている間でも、排他表ロックを解消することでデータの独立性を確保します。つまり、表への行ロックが残っている現行の書込みトランザクションが完了するまで、プロシージャがブロックします。

  • このプロシージャをスタンバイで実行する場合、SQL適用を停止して、データベース・ガードをSTANDBYまたはNONEのいずれかに設定する必要があります。プロシージャの実行が完了すると、表はデータベース・ガードによって保護されます。

例

表OE.CUSTOMERSに対するEDSを削除するには、プライマリ・データベースで次のコマンドを実行します。 

execute dbms_logstdby.eds_remove_table('OE','CUSTOMERS');

97.4.8 INSTANTIATE_TABLEプロシージャ

このプロシージャは、プライマリ・データベース内の対応する表から、スタンバイ・データベース内に表を作成し、データを移入します。

表には、入力パラメータとしてデータベース・リンク(dblink)名が必要です。ロジカル・スタンバイ・データベース内に表がすでに存在する場合、その表は削除され、プライマリ・データベースの表定義に基づいて再作成されます。このプロシージャは、表に関連付けられているデータに対してのみ適用され、関連付けられている索引および制約には適用されません。

INSTANTIATE_TABLEプロシージャを使用すると、次のことを実行できます。

  • スタンバイ・データベースへの表の追加

  • スタンバイ・データベース内の表の再作成

CDBでは、INSTANTIATE_TABLEプロシージャは、インスタンス化する表が存在するコンテナ内からコールする必要があります。また、プライマリ・データベースで用意されているデータベース・リンクが、プライマリの対応するコンテナをポイントする必要があります。

構文

DBMS_LOGSTDBY.INSTANTIATE_TABLE (
     schema_name         IN VARCHAR2,
     table_name          IN VARCHAR2,
     dblink              IN VARCHAR2);

パラメータ

表97-14 INSTANTIATE_TABLEプロシージャのパラメータ

パラメータ 説明

schema_name

スキーマの名前を指定します。

table_name

スタンバイ・データベースに作成または再作成する表の名前。

dblink

プライマリ・データベース内の表の読込み権限およびロック権限があるデータベース・リンク・アカウントの名前、およびプライマリ・データベースのSELECT_CATALOG_ROLE。

例外

表97-15 INSTANTIATE_TABLEプロシージャの例外

例外 説明

ORA-16103

この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。

ORA-16236

ロジカル・スタンバイ・メタデータ操作は進行中です。

ORA-16276

指定したデータベース・リンクはプライマリ・データベースに対応していません。

ORA-16277

指定した表はロジカル・スタンバイ・データベースでサポートされていません。

ORA-16278

指定した表でマルチオブジェクトのスキップ・ルールが定義されています。

使用上のノート

  • このプロシージャを使用すると、プライマリ・データベースとトランザクション的に一貫性のある状態にスタンバイ・データベースのデータを保つように、表が作成され、データが移入されます。

  • この表は、SQL適用によってメンテナンスされる他の表とは同期されず、プライマリからの表のインスタンス化後に発生したREDOがSQL適用によって検出されるまで、SQL適用によるこの表のメンテナンスは開始されません。プライマリ・データベースから表をインスタンス化したSCNは、DBA_LOGSTDBY_EVENTSビューで使用できます。

  • 指定した表はロジカル・スタンバイでサポートされている必要があります(つまり、プライマリ・データベースのDBA_LOGSTDBY_UNSUPPORTED_TABLESビューに表示されません)。

  • この表を(ワイルドカードを使用しないで)明示的に指定するスキップ・ルールがある場合は、INSTANTIATE_TABLEの処理中にこれらのスキップ・ルールが削除されるため、表は引き続きSQL適用で適切に保持されます。この表を間接的に参照するスキップ・ルール(schema_nameまたはtable_name内にワイルドカードがあり、文タイプがTABLE、DMLまたはSCHEMA_DDLであるスキップ・ルール)がある場合は、INSTANTIATE_TABLEに失敗し、ORA-16278エラーが発生します。INSTANTIATE_TABLEコールを再試行する前に、この表に関連するマルチオブジェクト・スキップ・ルールをすべて削除または変更する必要があります。

例

SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE (-
     SCHEMA_NAME => 'HR', TABLE_NAME => 'EMPLOYEES', -
     DBLINK => 'INSTANTIATE_TBL_LINK');

97.4.9 IS_APPLY_SERVERファンクション

このファンクションは、ロジカル・スタンバイ適用サーバー・プロセスのコンテキストでPL/SQLから実行された場合、TRUEを戻します。

このファンクションは、DBMS_DDL.SET_TRIGGER_FIRING_PROPERTYサブプログラムのfire_onceパラメータがFALSEに設定されている(デフォルトはTRUE)トリガーと一緒に使用します。このようなトリガーは、適用プロセスによって関連ターゲットが更新されると実行されます。このファンクションは、トリガー本体内で使用して、トリガーがプライマリまたはスタンバイで異なるアクションを実行する(またはアクションを実行しない)ようにすることができます。

構文

DBMS_LOGSTDBY.IS_APPLY_SERVER
RETURN BOOLEAN;

パラメータ

なし

97.4.10 MAP_PRIMARY_SCNファンクション

このファンクションは、プライマリ・データベースの指定SCNより5分以上先行している、スタンバイのSCNを戻します。

これを使用すると、プライマリ・データベースでのフラッシュバック・データベース操作またはPoint-in-Timeリカバリ操作の後に、ロジカル・スタンバイ・データベースでフラッシュバック・データベース操作を補足するときに使用する安全なSCNを判別できます。

構文

DBMS_LOGSTDBY.MAP_PRIMARY_SCN(primary_scn NUMBER) RETURN NUMBER;

例外

表97-16 MAP_PRIMARY_SCNファンクションの例外

例外 説明

ORA-20001

プライマリSCNはマップ範囲の前にあります。

ORA-20002

SCNマッピングでは、PRESERVE_COMMIT_ORDERをTRUEにする必要があります。

使用上のノート

このファンクションは、プライマリ・データベースのSCNに対応するロジカル・スタンバイ・データベースの保守的SCNを取得する場合に使用します。このファンクションは、プライマリ・データベースでのフラッシュバック・データベース操作またはPoint-in-Timeリカバリ操作の後に、ロジカル・スタンバイでフラッシュバック・データベース操作を補足する場合に役立ちます。

97.4.11 PREPARE_FOR_NEW_PRIMARYプロシージャ

PREPARE_FOR_NEW_PRIMARYプロシージャは、フェイルオーバーの発生後、ロジカル・スタンバイ・データベースがフェイルオーバーの対象でなかった場合、そのスタンバイ・データベースで起動する必要があります。

このようなスタンバイ・データベースでは、新しいプライマリ・データベースで処理されるREDOログ・セットと同じREDOログ・セットを処理する必要があります。このルーチンは、ローカルのロジカル・スタンバイ・データベースで新しいプライマリ・データベースより多くのREDOが処理されないようにし、一貫性を保証するために置換する必要があるアーカイブ・ログ・ファイル・セットをレポートします。一連の置換ログは、アラート・ログにレポートされます。これらのログは、ロジカル・スタンバイにコピーし、ALTER DATABASE REGISTER LOGICAL LOGFILE文を使用して登録する必要があります。

CDBでは、PREPARE_FOR_NEW_PRIMARYプロシージャはルート・データベースからコールする必要があります。

構文

DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY (
           FORMER_STANDBY_TYPE         IN VARCHAR2,
           DBLINK                      IN VARCHAR2);

パラメータ

表97-17 PREPARE_FOR_NEW_PRIMARYプロシージャのパラメータ

パラメータ 説明

FORMER_STANDBY_TYPE

フェイルオーバー操作によって新しいプライマリ・データベースとなったスタンバイ・データベースのタイプ。有効な値は、'PHYSICAL'(新しいプライマリ・データベースが、以前はフィジカル・スタンバイ・データベースだった場合)および'LOGICAL'(新しいプライマリ・データベースが、以前はロジカル・スタンバイ・データベースだった場合)です。

DBLINK

新しいプライマリ・データベースへのデータベース・リンクの名前。

例外

表97-18 PREPARE_FOR_NEW_PRIMARYプロシージャの例外

例外 説明

ORA-16104

ロジカル・スタンバイ・オプションのリクエストが無効です。

ORA-16109

以前のプライマリからのログ・データの適用に失敗しました。

使用上のノート

  • このルーチンは、ロジカル・スタンバイ・システムのみを対象としています。新しいプライマリ・データベースが以前はロジカル・スタンバイ・データベースで、LogMinerディクショナリの作成が正常に完了していない場合、このルーチンは失敗します。アラート・ログに表示されるログ・ファイルは、端末ログと呼ばれます。ファイル・パスは、新しいプライマリ・データベースに対する相対パスであり、ローカルに解決できない場合があることに注意してください。端末ログを手動で登録する際は、START LOGICAL STANDBY APPLY(新しいプライマリ・データベースが、以前はフィジカル・スタンバイ・データベースだった場合)またはSTART LOGICAL STANDBY APPLY NEW PRIMARY(新しいプライマリ・データベースが、以前はロジカル・スタンバイ・データベースだった場合)のいずれかをコールして、処理を完了する必要があります。例外が発生した理由の詳細は、アラート・ログを参照してください。

例

SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY (  -
                FORMER_STANDBY_TYPE => 'LOGICAL',    -
                DBLINK => 'dblink_to_newprimary');

97.4.12 PURGE_SESSIONプロシージャ

PURGE_SESSIONは、ロジカル・スタンバイ・データベースに適用済で、SQL適用で不要になったすべてのアーカイブREDOログ・ファイルを識別します。

識別後、オペレーティング・システム・コマンドを発行して、一部またはすべての不要なアーカイブREDOログ・ファイルを削除できます。

CDBでは、PURGE_SESSIONプロシージャはルート・データベースからコールする必要があります。

構文

DBMS_LOGSTDBY.PURGE_SESSION;

例外

表97-19 PURGE_SESSIONプロシージャの例外

例外 説明

ORA-01309

セッションが無効です。

使用上のノート

  • このプロシージャでは、アーカイブREDOログ・ファイルは削除されません。不要なファイルは、オペレーティング・システム・コマンドを発行して削除する必要があります。

  • このプロシージャを実行すると、ロジカル・スタンバイ・データベースに適用されたアーカイブREDOログ・ファイルを表示するDBA_LOGMNR_PURGED_LOGビューが更新されます。

  • Oracle Database 10g リリース2(10.2)では、アーカイブREDOログ・ファイルに関連するメタデータ(および実際のアーカイブREDOログ・ファイル)が、LOG_AUTO_DELETEパラメータのデフォルト設定(「DBMS_LOGSTDBY.APPLY_SETプロシージャ」を参照)に基づいて自動的にパージされます。

例

不要なファイルを識別して削除するには:

  1. ロジカル・スタンバイ・データベースで、次の文を入力します。 

    SQL> EXECUTE DBMS_LOGSTDBY.PURGE_SESSION;

  2. DBA_LOGMNR_PURGED_LOGビューを問い合せて、削除できるアーカイブREDOログ・ファイルのリストを表示します。 

    SQL> SELECT * FROM DBA_LOGMNR_PURGED_LOG;

FILE_NAME
   ------------------------------------
   /boston/arc_dest/arc_1_40_509538672.log
   /boston/arc_dest/arc_1_41_509538672.log
   /boston/arc_dest/arc_1_42_509538672.log
   /boston/arc_dest/arc_1_43_509538672.log
   /boston/arc_dest/arc_1_44_509538672.log
   /boston/arc_dest/arc_1_45_509538672.log
   /boston/arc_dest/arc_1_46_509538672.log
   /boston/arc_dest/arc_1_47_509538672.log

  3. オペレーティング・システム固有のコマンドを使用して、アーカイブREDOログ・ファイルをファイル・システムから削除します。

97.4.13 REBUILDプロシージャ

このプロシージャは、フェイルオーバー操作に伴ってプライマリ・データベースに役割が変更されたデータベースで、関連するメタデータ(LogMinerディクショナリを含む)を他のロジカル・スタンバイ・データベースで必要なREDOストリームに記録できない場合に使用します。

CDBでは、REBUILDプロシージャはルート・データベースからコールする必要があります。

構文

DBMS_LOGSTDBY.REBUILD;

使用上のノート

  • LogMinerディクショナリ情報はREDOログ・ファイルに記録されます。スタンバイREDOログ・ファイル(存在する場合)は、アーカイブされます。

例

SQL> EXECUTE DBMS_LOGSTDBY.REBUILD;

97.4.14 SET_TABLESPACEプロシージャ

このプロシージャは、SQL適用で必要なメタデータ表を、ユーザー指定の表領域に移動します。

デフォルトでは、メタデータ表は、SYSAUX表領域内に作成されます。このプロシージャを起動しているときは、SQL適用を実行できません。

CDBでは、SET_TABLESPACEプロシージャはルート・データベースからコールする必要があります。

構文

DBMS_LOGSTDBY.SET_TABLESPACE(
           NEW_TABLESPACE IN VARCHAR2)

パラメータ

表97-20 SET_TABLE SPACEプロシージャのパラメータ

パラメータ 説明

NEW_TABLESPACE

メタデータ表が常駐することになる新しい表領域の名前

例外

表97-21 SET_TABLESPACEプロシージャの例外

例外 説明

ORA-16103

この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。

ORA-16236

ロジカル・スタンバイ・メタデータ操作は進行中です。

例

LOGSTDBY_TBSという新しい表領域にメタデータ表を移動するには、次の文を発行します。 

SQL> EXECUTE DBMS_LOGSTDBY.SET_TABLESPACE (new_tablespace => 'LOGSTDBY_TBS');

97.4.15 SKIPプロシージャ

SKIPプロシージャを使用すると、SQL適用で特定の変更がロジカル・スタンバイ・データベースに適用されないようにする場合に使用するルールを定義できます。

たとえば、SKIPプロシージャを使用すると、ロジカル・スタンバイ・データベース内の表のサブセットへの変更をスキップできます。また、ロジカル・スタンバイ・データベースで適用しないDDL文、またはロジカル・スタンバイ・データベースに適用する前に変更の必要があるDDL文の指定もできます。DDL文の変更は、ロジカル・スタンバイ・データベースで別のディレクトリ構造に対応する場合などに行う必要があります。

ノート:

コンテナのスキップの詳細は、「コンテナのスキップ」を参照してください。

構文

DBMS_LOGSTDBY.SKIP (
     stmt                      IN VARCHAR2,
     schema_name               IN VARCHAR2 DEFAULT NULL,
     object_name               IN VARCHAR2 DEFAULT NULL,
     proc_name                 IN VARCHAR2 DEFAULT NULL,
     use_like                  IN BOOLEAN DEFAULT TRUE,
     esc                       IN CHAR1 DEFAULT NULL);

パラメータ

表97-22 SKIPプロシージャのパラメータ

パラメータ 説明

stmt

SQL文のセットまたは特定のSQL文を識別するキーワード。(通常はデータベース・オブジェクトで定義される)キーワードを使用すると、指定オブジェクトで動作するすべてのSQL文が識別されるため、構成が簡単になります。表97-23に、キーワードおよびそれに対応するSQL文を示しますが、いずれもこのパラメータの値として有効です。

キーワードPL/SQLは、レプリケーション用にサポートされているオラクル社提供のパッケージを実行する場合に使用します。

schema_name

stmtパラメータによって識別されるSQL文と関連付けられる1つ以上のスキーマの名前(ワイルドカードの使用可)。必要でない場合は、この値をNULLに設定してください。

object_name

stmtパラメータによって識別されるSQL文と関連付けられる1つ以上のオブジェクトの名前(ワイルドカードの使用可)。必要でない場合は、この値をNULLに設定してください。

proc_name

SQL適用で、特定の文がstmt、schema_nameおよびobject_nameの各パラメータによって定義されたフィルタと一致していると判断されたときにコールされるストアド・プロシージャの名前です。次のフォーマットで指定します。

'schema.package.procedure'

このプロシージャは、SQL適用に対して、文の実行、文のスキップまたは代替文の実行のいずれかを行うように指示する値を戻します。

DDLまたはPL/SQLの場合に呼び出されるプロシージャでは引数が取得されません。ネームスペースLSBY_APPLY_CONTEXTに関連付けられたコンテキストにアクセスすることで、プロシージャ内で必要な様々な情報にアクセスできます。

スキップ・プロシージャのコンテキストでアクセス可能なパラメータの完全なリストは、DBMS_LOGSTBDY_CONTEXTパッケージを参照してください。

DDLの場合に対象となるパラメータは、STATEMENT、STATEMENT_TYPE、SCHEMA、NAME、CURENT_SCHEMA、XIDUSN、XIDSLT、XIDSQNおよびSKIP_ACTIONです。

PL/SQLの場合に対象となるパラメータは、STATEMENT、PACKAGE_SCHMEMA、PACKAGE_NAME、PROCEDURE_NAME、CURRENT_SCHEMA、XIDUSN、XIDSLT、XIDSQN、EXIT_STATUSおよびSKIP_ACTIONです。

ノート1: DBMS_LOGSTDBY.SKIP_ACTION_REPLACE定数はPL/SQLではサポートされません。

ノート2: プロシージャの終了が処理されると、SQL適用はスキップ・ハンドラをコールします。

ノート3: PL/SQLではワイルドカードがサポートされていないため、use_likeパラメータをFALSEに設定する必要があります。

proc_name (続き)

DBMS_RLS.DROP_POLICY上の条件付きスキップ・ルールの例は次のとおりです。

create or replace procedure sec.mgr.skip_drop_policy 
is
l_stmt  CLOB; 
l_pkgown varchar2(30); 
l_pkgnam varchar2(30);
l_procnm varchar2(30);
l_cur_schema varchar2(30);
l_xidusn   number;
l_xidslt   number;
l_xidsqn   number;
l_exit_status number;
l_skip_action number;
Begin
-- read all relevant info
dbms_logstdby_context.get_context(name => 'STATEMENT', value => l_stmt);
dbms_logstdby_context.get_context(name => 'PACKAGE_SCHEMA', value => l_pkgown);
dbms_logstdby_context.get_context(name => 'PACKAGE_NAME', value => l_pkgnam);
dbms_logstdby_context.get_context(name => 'PROCEDURE_NAME', value => l_procnm);
dbms_logstdby_context.get_context(name => 'CURRENT_SCHEMA', value => l_cur_schema);
dbms_logstdby_context.get_context(name => 'XIDUSN', value => l_xidusn);
dbms_logstdby_context.get_context(name => 'XIDSLT', value => l_xidslt);
dbms_logstdby_context.get_context(name => 'XIDSQN', value => l_xidsqn);
dbms_logstdby_context.get_context(name => 'EXIT_STATUS', value => l_ext_status);
 
if 0 == l_ext_status then
Insert Into sec_mgr.logit Values
      ('Success: '||l_pkgown||'.'||l_pkgnm||'.'||l_procnm|| ' by '||l_current_user);
 
If l_current_user != 'TESTSCHEMA' Then  
      l_skip_action := DBMS_LOGSTDBY.SKIP_ACTION_APPLY;
    Else
      l_skip_action := DBMS_LOGSTDBY.SKIP_ACTION_SKIP;
    End If;  
  End If;
 
dbms_logstdby_context.set_context(name=>'SKIP_ACTION',
value => l_skip_action);
 
End skip_drop_policy;

EXECUTE DBMS_LOGSTDBY.SKIP( -
     stmt => 'PL/SQL', -
     schema_name => 'SYS', -
     object_name => 'DBMS_RLS.DROP_POLICY', -
     proc_name => 'SEC_MGR.SKIP_DROP_POLICY' -
     use_like=> FALSE);

use_like

パターン・マッチングによって、ロジカル・スタンバイ・データベース上でスキップする表を区別することができます。use_likeパラメータは、2番目の値に指定されたパターンの最初の値を検索して、文字列値の一部を比較し、入力文字セットによって定義された文字を使用して、文字列を予想します。このパラメータは、『Oracle Database SQL言語リファレンス』で説明されているパターン・マッチングと同じ規則に従います。

esc

パターン・マッチングに使用できるエスケープ文字(文字"/"など)を識別します。パターン内の文字%または_の前にエスケープ文字があると、Oracleではこの文字を特殊なパターン・マッチング文字としてではなく、パターン内の文字通りに解釈します。パターン・マッチングの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

使用上のノート

  • このプロシージャを実行するには、DBA権限が必要です。

  • DML文のコンテキストで起動されるストアド・プロシージャは、関連付けできません。たとえば、次の文は、「ORA-16104: ロジカル・スタンバイ・オプションのリクエストが無効です。」エラーを戻します。 

    SQL> EXECUTE DBMS_LOGSTDBY.SKIP(-
     stmt => 'DML', -
     schema_name => 'HR', -
     object_name => 'EMPLOYEES', -
     proc_name => 'DML_HANDLER');

    また、ルールの指定時にワイルドカードを使用したか、またはルールを重複して指定したため、1つのイベントが複数のルールに一致する場合は、次のようになります。たとえば、HR.EMPLOYEES表にSCHEMA_DDLイベントのルールおよびHR.EMPLOYEES表にALTER TABLEイベントのルールを指定すると、(プロシージャ名のアルファベット順に従って)一致するプロシージャのいずれか1つのみが起動されます。次のコード例のルールを指定したとします。 

    SQL> EXECUTE DBMS_LOGSTDBY.SKIP( -
     stmt => 'SCHEMA_DDL', -
     schema_name => 'HR', -
     object_name => 'EMPLOYEES', -
     proc_name => 'SCHEMA_DDL_HANDLER');
SQL> EXECUTE DBMS_LOGSTDBY.SKIP( -
     stmt => 'ALTER TABLE', -
     schema_name => 'HR', -
     object_name => 'EMPLOYEES', -
     proc_name => 'TABLE_ALTER_HANDLER');

    ALTER TABLE文が検出されると、schema_ddl_handlerプロシージャが起動されますが、これは、このプロシージャの名前が、この文に関連するプロシージャのアルファベット順にソートされたリストの最上位にあるためです。ワイルドカードを使用して指定したためにルール・セットで競合が発生した場合も、同様に解決されます。たとえば、次の例のルールでは、ALTER TABLE HR.EMPLOYEES ADD COLUMN RATING NUMBER文が検出されると、empddl_handlerプロシージャが起動されます。 

    SQL> EXECUTE DBMS_LOGSTDBY.SKIP(-
     stmt => 'ALTER TABLE', -
     schema_name => 'HR', -
     object_name => 'EMP%', -
     proc_name => 'EMPDDL_HANDLER');
SQL> EXECUTE DBMS_LOGSTDBY.SKIP( -
     stmt => 'ALTER TABLE', -
     schema_name => 'HR', -
     object_name => 'EMPLOYEES', -
     proc_name => 'EMPLOYEE_DDL_HANDLER');

  • SKIPプロシージャは、DDL文をスキップする場合は特に注意して使用してください。たとえば、CREATE TABLE文をスキップする場合は、その表を参照する他のDDL文もSKIPプロシージャで指定する必要があります。このように処理しないと、文が失敗し、例外が発生する原因となります。例外が発生すると、SQL適用の実行が停止します。

  • SKIPプロシージャをコールする前に、SQL適用を停止する必要があります。これを行うには、ALTER DATABASE STOP LOGICAL STANDBY APPLY文を発行します。必要なフィルタをすべて指定した後、ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE文を発行して、新しいフィルタ設定でSQL適用を開始します。

  • SKIPプロシージャの設定を元に戻す(UNDOする)方法は、「UNSKIPプロシージャ」を参照してください。

  • USER文では、SCHEMA_NAMEパラメータはユーザーになります。OBJECT_NAMEパラメータには'%'を指定する必要があります。

  • PROC_NAMEパラメータを指定する場合は、このプロシージャがDBA_PROCEDURESにすでに存在している必要があり、DEFINER権限で実行する必要があります。このプロシージャをINVOKER権限で宣言すると、「ORA-01031: 権限が不足しています」メッセージが戻されます。

  • このプロシージャによってREPLACEMENT文が戻された場合、このREPLACEMENT文は、プロシージャの所有者のSYSTEMおよびOBJECT権限を使用して実行されます。

  • SKIPプロシージャのPL/SQLブロックは、自律型トランザクションであると宣言されていないかぎり、トランザクション制御文(COMMIT、ROLLBACK、SAVEPOINT、SET CONSTRAINTなど)を含むことはできません。

スキップ文のオプション

表97-23に、SKIPプロシージャのstmtパラメータに対してサポートされる値を示します。表の左側の列には、キーワードの右側にあるSQL文セットの識別に使用される可能性のあるキーワードを示します。また、sys.audit_actions表に示されたSQL文(表97-23の右列を参照)はすべて、有効な値でもあります。キーワードは、通常、データベース・オブジェクトによって定義されます。

表97-23 stmtパラメータに対してサポートされる値

キーワード 関連するSQL文

このグループのSQL文に対するキーワードはない。

 
GRANT
REVOKE
ANALYZE TABLE
ANALYZE INDEX
ANALYZE CLUSTER

CLUSTER

 
AUDIT CLUSTER
CREATE CLUSTER
DROP CLUSTER
TRUNCATE CLUSTER

CONTAINER

「コンテナのスキップ」を参照してください。

CONTEXT

 
CREATE CONTEXT
DROP CONTEXT

DATABASE LINK

 
CREATE DATABASE LINK
CREATE PUBLIC DATABASE LINK
DROP DATABASE LINK
DROP PUBLIC DATABASE LINK

DIMENSION

 
ALTER DIMENSION
CREATE DIMENSION
DROP DIMENSION

DIRECTORY 1

 
CREATE DIRECTORY
DROP DIRECTORY

DML

表内のDML文を含む(例: INSERT、UPDATE、DELETE)

INDEX

 
ALTER INDEX
CREATE INDEX
DROP INDEX

NON_SCHEMA_DDL

特定のスキーマに関連付けられていないすべてのDDL

ノート: SCHEMA_NAMEおよびOBJECT_NAMEはNULLである必要があります。

PL/SQL 2

オラクル社が提供するパッケージを実行します。

PROCEDURE 3

 
ALTER FUNCTION
ALTER PACKAGE
ALTER PACKAGE BODY
ALTER PROCEDURE
CREATE FUNCTION
CREATE LIBRARY
CREATE PACKAGE
CREATE PACKAGE BODY
CREATE PROCEDURE
DROP FUNCTION
DROP LIBRARY
DROP PACKAGE
DROP PACKAGE BODY
DROP PROCEDURE

PROFILE

 
ALTER PROFILE
CREATE PROFILE
DROP PROFILE

ROLE

 
ALTER ROLE
CREATE ROLE
DROP ROLE
SET ROLE

ROLLBACK STATEMENT

 
ALTER ROLLBACK SEGMENT
CREATE ROLLBACK SEGMENT
DROP ROLLBACK SEGMENT

SCHEMA_DDL

スキーマ・オブジェクト(例: 表、索引、列)の作成、変更または削除を行うすべてのDDL文

ノート: SCHEMA_NAMEおよびOBJECT_NAMEはNULL以外である必要があります。

SEQUENCE

 
ALTER SEQUENCE
CREATE SEQUENCE
DROP SEQUENCE

SYNONYM

 
CREATE PUBLIC SYNONYM
CREATE SYNONYM
DROP PUBLIC SYNONYM
DROP SYNONYM

SYSTEM AUDIT

 
AUDIT SQL_statements
NOAUDIT SQL_statements

TABLE

 
CREATE TABLE
ALTER TABLE
DROP TABLE
TRUNCATE TABLE

TABLESPACE

 
CREATE TABLESPACE
DROP TABLESPACE
ALTER TABLESPACE

TRIGGER

 
ALTER TRIGGER
CREATE TRIGGER
DISABLE ALL TRIGGERS
DISABLE TRIGGER
DROP TRIGGER
ENABLE ALL TRIGGERS
ENABLE TRIGGER

TYPE

 
ALTER TYPE
ALTER TYPE BODY
CREATE TYPE
CREATE TYPE BODY
DROP TYPE
DROP TYPE BODY

USER

 
ALTER USER
CREATE USER
DROP USER

VIEW

 
CREATE VIEW
DROP VIEW

VIEW

 
CREATE VIEW
DROP VIEW

脚注1

すべてのディレクトリ・オブジェクトはSYSが所有していまが、skipディレクティブでフィルタリングするためにスキーマは「'%'」と指定する必要があります。

脚注2

サポート対象パッケージの詳細は、『Oracle Data Guard概要および管理』を参照してください。

脚注3

Javaスキーマ・オブジェクト(ソース、クラス、リソース)は、SQL文をスキップ(無視)するためのプロシージャと同等とみなされます。

例外

表97-24 DBMS_LOGSTDBY.SKIPプロシージャの例外

例外 説明

ORA-01031

権限が不十分です。

  • プロシージャでINVOKER権限が使用されました。

  • プロシージャにDBA権限が必要です。

ORA-16103

この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。

ORA-16104

ロジカル・スタンバイ・オプションのリクエストが無効です。

ORA-16203

SKIPプロシージャの戻り値を解釈できません。

SKIPプロシージャで例外が発生したか、または戻り値が明確でないことを示します。DBA_LOGSTDBY_EVENTSビューを調べると、例外が発生したプロシージャを識別できます。

ORA-16236

ロジカル・スタンバイ・メタデータ操作は進行中です。

例

例1.スキーマに対して行われたすべてのDMLとDDLの変更のスキップ

次の例は、HRスキーマに対するDDL文とDML文の両方をSQL適用でスキップするルールの指定方法を示しています。

SQL> EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'SCHEMA_DDL', -
     schema_name => 'HR', -
     object_name => '%', -
     proc_name => null);
SQL> EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'DML', -
     schema_name => 'HR', -
     object_name => '%', -
     proc_name => null);
例2.異なるファイル・システムの編成を処理するプロシージャの作成

たとえば、ファイル・システムの編成がロジカル・スタンバイ・データベースとプライマリ・データベースで異なる場合は、ファイルが指定されたDDL文を透過的に処理するSKIPプロシージャを作成できます。次のプロシージャは、ファイル指定文字列に関する特定のネーミング規則に従っているかぎり、DDL文を処理できます。

  1. 表領域DDL文を処理するSKIPプロシージャを作成します。 

    CREATE OR REPLACE PROCEDURE sys.handle_tbs_ddl 
IS
l_old_stmt varchar2(4000);
l_stmt_typ varcahr2(40);
l_schema   varchar2(30);
l_name     varchar2(30);
l_xidusn   number;
l_xidslt   number;
l_xidsqn   number;
l_skip_action number;
l_new_stmt varchar2(4000);
 
-- read all information
dbms_logstdby_context.get_context(name=>'STATEMENT',value=>l_old_stmt);
  dbms_logstdby_context.get_context(name=>'STATEMENT_TYPE',value=>l_stmt_type);
  dbms_logstdby_context.get_context(name=>'OWNER',value=>l_schema);
  dbms_logstdby_context.get_context(name=>'NAME',value=>l_name);
  dbms_logstdby_context.get_context(name=>'XIDUSN',value=>l_xidusn);
  dbms_logstdby_context.get_context(name=>'XIDSLT',value=>l_xidslt);
  dbms_logstdby_context.get_context(name=>'XIDSQN',value=>l_xidsqn);
  dbms_logstdby_context.get_context(name=>'CONTAINER_NAME',value=>l_conname);
 
--
-- All primary file specification that contains a directory
-- /usr/orcl/primary/dbs
-- should go to /usr/orcl/stdby directory specification
 
  BEGIN
  l_new_stmt := replace (l_old_stmt, '/usr/orcl/primary/dbs','/usr/orcl/stdby');
l_skip_action := DBMS_LOGSTDBY.SKIP_ACTION_REPLACE;
  EXCEPTION
  WHEN OTHERS THEN
    l_skip_action := DBMS_LOGSTDBY.SKIP_ACTION_ERROR;
    l_new_stmt := NULL;
  END;
 
  dbms_logstdby_context.set_context(name=>new_statement, value => l_new_stmt);
dbms_logstdby_context.set_context(name=>'SKIP_ACTION', value => l_skip_action);
END handle_tbs_ddl;

  2. SKIPプロシージャをSQL適用に登録します。 

    SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'TABLESPACE', -
             proc_name => 'SYS.HANDLE_TBS_DDL');

コンテナのスキップ

コンテナ(PDBまたはルートのいずれか)をスキップするには、CONTAINERキーワードを使用します。コンテナで実行されたすべてのSQL文や、コンテナに対して実行されたアクションがスキップされます。

CDB内で特定のPDBをスキップできます。たとえば、次のコマンドはPDB1というPDBをスキップします。次のように、コマンドをルート・レベルで実行する必要があります。 

SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'CONTAINER', object_name => 'PDB1');

次の例に示すように、CDBのルートのみをスキップして、そのルートの下のPDBはスキップしないように指定することもできます。次のように、コマンドをルート・レベルで実行する必要があります。

SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'CONTAINER', object_name => 'CDB$ROOT');

ノート:

コンテナに対するその他のスキップ・ルールを作成するには、コンテナ内でルールを作成します。ルールが適用されるコンテナは、そのルールが作成されたコンテナで自動的に判断されます。

97.4.16 SKIP_ERRORプロシージャ

SKIP_ERRORプロシージャは、ロジカル・スタンバイ・データベースによってエラーが検出されたときに実行するアクションを指定します。

エラーが発生すると、ロジカル・スタンバイ・データベースは、このプロシージャに含まれている基準を使用して、アクションを決定します。一致するものが見つかったときのデフォルトのアクションは、エラーをスキップして変更の適用を継続することです。ただし、プロシージャが指定された場合、SKIP_ERRORは状況に応じて他のアクションを行うことができます。何もしない(SQL適用は停止します)、エラー・メッセージ・テキストを変更してSQL適用を停止する、または、実際にエラーをスキップすることができます。

構文

DBMS_LOGSTDBY.SKIP_ERROR (
     stmt                      IN VARCHAR2,
     schema_name               IN VARCHAR2 DEFAULT NULL,
     object_name               IN VARCHAR2 DEFAULT NULL,
     proc_name                 IN VARCHAR2 DEFAULT NULL,
     use_like                  IN BOOLEAN  DEFAULT NULL,
     esc                       IN CHAR1    DEFAULT NULL);

パラメータ

表97-25 SKIP_ERRORプロシージャのパラメータ

パラメータ 説明

stmt

SQL文のセットまたは特定のSQL文を識別するキーワード。(通常はデータベース・オブジェクトで定義される)キーワードを使用すると、指定オブジェクトで動作するすべてのSQL文が識別されるため、構成が簡単になります。表97-23に、キーワードおよびそれに対応するSQL文を示しますが、いずれもこのパラメータの値として有効です。

schema_name

stmtパラメータによって識別されるSQL文と関連付けられる1つ以上のスキーマの名前(ワイルドカードの使用可)。必要でない場合は、この値をNULLに設定してください。

object_name

stmtパラメータによって識別されるSQL文と関連付けられる1つ以上のオブジェクトの名前(ワイルドカードの使用可)。必要でない場合は、この値をNULLに設定してください。

proc_name

SQL適用でエラーが発生し、特定の文がstmt、schema_nameおよびobject_nameパラメータによって定義されたフィルタと一致していると判断されたときにコールされるストアド・プロシージャの名前。次のフォーマットで指定します。

'"schema"."package"."procedure"'

このプロシージャは、SQL適用に対して、次のいずれかを行うように指示するエラー・メッセージを戻します。

  • サイレントでエラーをスキップし、SQL適用を継続する。

  • 作成されるエラー・メッセージをカスタムのメッセージと置換し、SQL適用を停止する。

  • 何もせずSQL適用を停止させ元のエラー・メッセージをログに記録させる。

SQL適用に登録されたプロシージャではパラメータがまったく取得されません。LSBY_APPLY_CONTEXTに関連付けられたコンテキストを使用することで、エラーに関連する情報をすべて取得できます。LSBY_APPLY_CONTEXTに関連付けられたすべてのパラメータのリストは、DBMS_LOGSTDBY_CONTEXTパッケージを参照してください。

SKIP_ERRORに登録されたプロシージャで対象となるパラメータは、CONTAINER_NAME、STATEMENT、STATEMENT_TYPE、SCHEMA、NAME、XIDUSN、XIDSLT、XIDSQN、ERRORおよびNEW_ERRORです。

use_like

パターン・マッチングによって、ロジカル・スタンバイ・データベース上でスキップする表を区別することができます。use_likeパラメータは、2番目の値に指定されたパターンの最初の値を検索して、文字列値の一部を比較し、入力文字セットによって定義された文字を使用して、文字列を予想します。このパラメータは、『Oracle Database SQL言語リファレンス』で説明されているパターン・マッチングと同じ規則に従います。

esc

パターン・マッチングに使用できるエスケープ文字(文字"%"または"_"など)を識別します。パターン内の文字%または_の前にエスケープ文字があると、Oracleではこの文字を特殊なパターン・マッチング文字としてではなく、パターン内の文字通りに解釈します。

使用上のノート

  • SKIP_ERRORプロシージャに提供されているストアド・プロシージャは、SQL適用で、スタンバイ・データベースへのREDOログの適用を停止する可能性のあるエラーが発生した場合にコールされます。

  • このストアド・プロシージャの実行は、DBA_LOGSTDBY_EVENTS表のSTATUS列に書き込まれるエラーに作用します。STATUS_CODE列は変更されません。ストアド・プロシージャの効果がない、つまり適用が停止された場合は、NEW_ERRORがイベント表に書き込まれます。まったく効果がないようにするには、そのプロシージャでNEW_ERRORをERRORに設定します。

  • ストアド・プロシージャで停止の回避が必要な場合は、NEW_ERRORをNULLに設定します。

  • このプロシージャを実行するには、DBA権限が必要です。

  • USER文では、SCHEMA_NAMEパラメータはユーザーになります。OBJECT_NAMEパラメータには'%'を指定する必要があります。

  • PROC_NAMEパラメータを指定する場合は、このプロシージャがDBA_PROCEDURESにすでに存在している必要があり、DEFINERS権限で実行する必要があります。このプロシージャをINVOKERS権限で宣言すると、「ORA-01031: 権限が不足しています」メッセージが戻されます。

  • SKIP_ERRORプロシージャのPL/SQLブロックは、次に示す構文を使用して自律型トランザクションであると宣言されていないかぎり、トランザクション制御文(COMMIT、ROLLBACK、SAVEPOINT、SET CONSTRAINTなど)を含むことはできません。 

    PRAGMA AUTONOMOUS_TRANSACTION

例外

表97-26 SKIP_ERRORプロシージャの例外

例外 説明

ORA-01031

権限が不十分です。

  • プロシージャでINVOKER権限が使用されました。

  • プロシージャにDBA権限が必要です。

ORA-16103

この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。

ORA-16104

ロジカル・スタンバイ・オプションのリクエストが無効です。

ORA-16236

ロジカル・スタンバイ・メタデータ操作は進行中です。

例1

次の例は、GRANT DDLコマンドから発生したエラーをSQL適用でスキップするルールの指定方法を示しています。 

SQL> EXECUTE DBMS_LOGSTDBY.SKIP_ERROR('GRANT')

例2

SYSまたはHRスキーマで発生したGRANT文のエラーをスキップするには、プロシージャhandle_error_ddlを定義して登録します。次の例では、handle_error_ddlが、SYSスキーマ内の自立型プロシージャであることを想定しています。

  1. エラー・ハンドラ・プロシージャを作成します。

    CREATE OR REPLACE PROCEDURE sys.handle_error_ddl
is
l_stmt    VARCHAR2(4000);
l_stmt_type VARCHAR2(40); 
l_schema    VARCHAR2(30);
l_name      VARCHAR2(30);
l_xidusn      NUMBER;   
l_xidslt      NUMBER;   
l_xidsqn      NUMBER;
l_error     VARCHAR2(4000);
l_conname    VARCHAR2(30); 
l_newerr   VARCHAR2(4000);
 
BEGIN
 dbms_logstdby_context.get_context(name=>'STATEMENT',value=>l_stmt);
  dbms_logstdby_context.get_context(name=>'STATEMENT_TYPE',value=>l_stmt_type);
  dbms_logstdby_context.get_context(name=>'SCHEMA',value=>l_schema);
  dbms_logstdby_context.get_context(name=>'NAME',value=>l_name);
  dbms_logstdby_context.get_context(name=>'XIDUSN',value=>l_xidusn);
  dbms_logstdby_context.get_context(name=>'XIDSLT',value=>l_xidslt);
  dbms_logstdby_context.get_context(name=>'XIDSQN',value=>l_xidsqn);
  dbms_logstdby_context.get_context(name=>'ERROR',value=>l_error);
  dbms_logstdby_context.get_context(name=>'CONTAINER_NAME',value=>l_conname);
 
-- default error to what we already have
l_new_error := l_error;
 
-- Ignore any GRANT errors on SYS or HR schemas
 
IF INSTR(UPPER(l_stmt), 'GRANT') > 0
THEN
IF l_schema is NULL 
OR (l_schema is NOT NULL AND
(UPPER(l_schema) = 'SYS' OR
UPPER(l_schema) = 'HR')
THEN
l_new_error := NULL;
-- record the fact that we just skipped an error on 'SYS' or 'HR' schemas 
-- code not shown here 
END IF;
END IF;
 
dbms_logstdby_context.set_context(name => 'NEW_ERROR', value => l_new_error);
 
END handle_error_ddl;
/

  2. エラー・ハンドラをSQL適用に登録します。

    SQL> EXECUTE DBMS_LOGSTDBY.SKIP_ERROR ( -
     statement => 'NON_SCHEMA_DDL', -
     schema_name => NULL, -
     object_name => NULL, -
     proc_name => 'SYS.HANDLE_ERROR_DDL');

97.4.17 SKIP_TRANSACTIONプロシージャ

このプロシージャは、ロジカル・スタンバイ・データベースへのトランザクションの適用をスキップする(処理しない)方法を提供します。トランザクション識別情報を指定することによって、特定のトランザクションをスキップできます。

構文

DBMS_LOGSTDBY.SKIP_TRANSACTION (
     xidusn          IN NUMBER,
     xidslt          IN NUMBER,
     xidsqn          IN NUMBER);

パラメータ

表97-27 SKIP_TRANSACTIONプロシージャのパラメータ

パラメータ 説明

XIDUSN NUMBER

スキップ対象トランザクションのトランザクションID UNDOセグメント番号。

XIDSLT NUMBER

スキップ対象トランザクションのトランザクションIDスロット番号。

XIDSQN NUMBER

スキップ対象トランザクションのトランザクションID順序番号。

使用上のノート

特定のトランザクション(例: DDLトランザクション)が原因でSQL適用が停止した場合、そのトランザクションIDを指定して、適用を継続できます。このプロシージャは、SQL適用で処理しないトランザクションの数と同じ回数コールできます。

警告:

SKIP_TRANSACTIONは、本質的に危険な操作です。このプロシージャは、問題のトランザクションをV$LOGMNR_CONTENTSビューで検査し、ロジカル・スタンバイ・データベースで補足アクションを行うまで起動しないでください。SKIP_TRANSACTIONは、表へのDML変更をスキップするために起動するプロシージャとして適切ではありません。

DMLの失敗をスキップするには、SKIP('DML','MySchema','MyFailed Table')というように、SKIPプロシージャを使用します。DMLトランザクションにSKIP_TRANSACTIONプロシージャを使用すると、他の表の変更をスキップすることになり、それらを論理的に壊してしまう可能性があります。

  • このプロシージャを実行するには、DBA権限が必要です。

  • DBA_LOGSTDBY_SKIP_TRANSACTIONビューを使用すると、SQL適用でスキップされる予定のトランザクションが示されます。

例外

表97-28 SKIP_TRANSACTIONプロシージャの例外

例外 説明

ORA-01031

DBA権限が必要です。

ORA-16103

この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。

ORA-16104

ロジカル・スタンバイ・オプションのリクエストが無効です。

例

XIDUSN、XIDSLT、XIDSQNがそれぞれ1、13、1726であるDDLトランザクションをスキップするには、次の例に示すルールを登録します。 

SQL> EXECUTE DBMS_LOGSTDBY.SKIP_TRANSACTION (- 
     XIDUSN => 1, XIDSLT => 13, XIDSQN => 1726);

97.4.18 UNSKIPプロシージャ

UNSKIPプロシージャは、SKIPプロシージャで指定済のルールを削除するために使用します。

指定済のルールを削除するには、UNSKIPプロシージャで指定するパラメータが正確に一致している必要があります。

container_name引数は、CDBでのみ有効です。

構文

DBMS_LOGSTDBY.UNSKIP (
     stmt                      IN VARCHAR2,
     schema_name               IN VARCHAR2 DEFAULT NULL,
     object_name               IN VARCHAR2 DEFUALT NULL,
     container_name            IN VARCHAR2 DEFAULT NULL);

パラメータ

UNSKIPプロシージャのパラメータ情報は、SKIPプロシージャで説明した情報と同じです。パラメータ情報の詳細は、表97-22を参照してください。

例外

表97-29 UNSKIPプロシージャの例外

例外 説明

ORA-01031

このプロシージャを実行するには、DBA権限が必要です。

ORA-16103

この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。

ORA-16104

ロジカル・スタンバイ・オプションのリクエストが無効です。

使用上のノート

警告:

表に対するDML変更をスキップし、その補足が行われていない場合、UNSKIPプロシージャのコールの後に、INSTANTIATE_TABLEプロシージャをコールして、その表を、SQL適用によってメンテナンスされる表と同期させる必要があります。

  • このプロシージャを実行するには、DBA権限が必要です。

  • schema_nameパラメータまたはobject_nameパラメータに渡されたワイルドカードは展開されません。ワイルドカード文字は、文字レベルで照合されます。したがって、UNSKIPプロシージャを起動することで削除できる指定済のルールは1つのみであり、指定済のルールを削除するにはUNSKIPプロシージャを個別にコールする必要があります。

    たとえば、HR.EMPLOYEE表およびHR.EMPTEMP表へのDML文の適用をスキップする次の2つのルールが指定済であるとします。 

    SQL> EXECUTE DBMS_LOGSTDBY.SKIP (STMT => 'DML',-
     SCHEMA_NAME => 'HR', -
     OBJECT_NAME => 'EMPLOYEE', -
     PROC_NAME => null);
SQL> EXECUTE DBMS_LOGSTDBY.SKIP (STMT => 'DML',-
     SCHEMA_NAME => 'HR', -
     OBJECT_NAME => 'EMPTEMP', -
     PROC_NAME => null);

    次の例では、TABLE_NAMEパラメータにワイルドカードが使用されていますが、これで指定済のルールを削除することはできません。 

    SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP (STMT => 'DML',-
     SCHEMA_NAME => 'HR', -
     OBJECT_NAME => 'EMP%');

    TABLE_NAMEパラメータのワイルドカード文字は展開されないため、このUNSKIPプロシージャは、実際にはいずれのルールとも一致しません。この場合、ワイルドカード文字は完全一致で使用され、対応するSKIPルールが検索されます。

97.4.19 UNSKIP_ERRORプロシージャ

UNSKIP_ERRORプロシージャは、SKIP_ERRORプロシージャで指定済のルールを削除するために使用します。

指定済のルールを削除するには、UNSKIP_ERRORプロシージャで指定するパラメータが正確に一致している必要があります。

container_name引数は、CDBでのみ有効です。

構文

DBMS_LOGSTDBY.UNSKIP_ERROR (
     stmt                      IN VARCHAR2,
     schema_name               IN VARCHAR2 DEFAULT NULL,
     object_name               IN VARCHAR2 DEFAULT NULL,
     container_name            IN VARCHAR2 DEFAULT NULL);

パラメータ

UNSKIP_ERRORプロシージャのパラメータ情報は、SKIP_ERRORプロシージャに関する情報と同じです。パラメータ情報の詳細は、表97-25を参照してください。

例外

表97-30 UNSKIP_ERRORプロシージャの例外

例外 説明

ORA-01031

DBA権限が必要です。

ORA-16103

この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。

ORA-16104

ロジカル・スタンバイ・オプションのリクエストが無効です。

使用上のノート

  • このプロシージャを実行するには、DBA権限が必要です。

  • schema_nameパラメータまたはobject_nameパラメータに渡されたワイルドカードは展開されません。そのかわりに、ワイルドカード文字は他の文字として扱われ、完全一致検索が行われます。したがって、UNSKIP_ERRORプロシージャを起動することで削除できる指定済のルールは1つのみであり、指定済のルールを削除するにはUNSKIP_ERRORプロシージャを個別にコールする必要があります。

    たとえば、HR.EMPLOYEE表およびHR.EMPTEMP表を処理する次の2つのルールが指定済であるとします。 

    SQL> EXECUTE DBMS_LOGSTDBY.SKIP_ERROR (STMT => 'DML',-
     SCHEMA_NAME => 'HR', -
     OBJECT_NAME => 'EMPLOYEE', -
     PROC_NAME => 'hr_employee_handler');
SQL> EXECUTE DBMS_LOGSTDBY.SKIP_ERROR (STMT => 'DML',-
     SCHEMA_NAME => 'HR', -
     OBJECT_NAME => 'EMPTEMP', -
     PROC_NAME => 'hr_tempemp_handler');

    この場合、次のUNSKIPプロシージャを使用して、指定済のルールを削除することはできません。 

    SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP_ERROR (STMT => 'DML',-
     SCHEMA_NAME => 'HR', -
     OBJECT_NAME => 'EMP%');

    OBJECT_NAMEパラメータのワイルドカード文字は展開されないため、このUNSKIPプロシージャは、実際にはいずれのルールとも一致しません。

例

SQL適用に登録済のハンドラを削除して、エラー発生時にコールされないようにするには、次の文を発行します。

DBMS_LOGSTDBY.UNSKIP_ERROR ( -
      statement => 'NON_SCHEMA_DDL', -
      schema_name => NULL, -
      object_name => NULL);

97.4.20 UNSKIP_TRANSACTIONプロシージャ

UNSKIP_TRANSACTIONプロシージャは、SKIP_TRANSACTIONプロシージャで指定済のルールを削除するために使用します。

指定済のルールを削除するには、UNSKIP_TRANSACTIONプロシージャで指定するパラメータが正確に一致している必要があります。

構文

DBMS_LOGSTDBY.UNSKIP_TRANSACTION (
     xidusn_p         IN NUMBER,
     xidslt_p         IN NUMBER,
     xidsqn_p         IN NUMBER);

パラメータ

表97-31 UNSKIP_TRANSACTIONプロシージャのパラメータ

パラメータ 説明

XIDUSN

スキップ対象トランザクションのトランザクションID UNDOセグメント番号。

XIDSLT

スキップ対象トランザクションのトランザクションIDスロット番号。

XIDSQN

スキップ対象トランザクションのトランザクションID順序番号。

例外

表97-32 UNSKIP_TRANSACTIONプロシージャの例外

例外 説明

ORA-01031

このプロシージャを実行するには、DBA権限が必要です。

ORA-16103

この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。

ORA-16104

ロジカル・スタンバイ・オプションのリクエストが無効です。

使用上のノート

  • このプロシージャを実行するには、DBA権限が必要です。

  • DBA_LOGSTDBY_SKIP_TRANSACTIONビューを問い合せると、SQL適用でスキップされる予定のトランザクションが示されます。

例

XIDUSN、XIDSLT、XIDSQNがそれぞれ1、13、1726であるトランザクションの適用をスキップするように指定されていたルールを削除するには、次の文を発行します。 

SQL> DBMS_LOGSTDBY.UNSKIP_TRANSACTION (XIDUSN => 1, XIDSLT => 13, XIDSQN => 1726);