73 DBMS_LOGSTDBY

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

DBMS_LOGSTDBYの使用方法

この項では、DBMS_LOGSTDBYパッケージの使用に関連する項目について説明します。

概要
使用上の注意

概要

DBMS_LOGSTDBYパッケージを使用して、SQL適用（ロジカル・スタンバイ・データベース）環境を管理できます。 DBMS_LOGSTDBYパッケージのサブプログラムを使用すると、次の主な目的を実現できます。

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

たとえば、ロジカル・スタンバイ・データベースへのトランザクションの適用方法、使用する共有プールの大きさ、SQL適用での変更の調査および適用に使用するプロセスの数などを制御します。
適切なレベルのサプリメンタル・ロギングが有効になっていること、およびLogMinerディクショナリがロジカル・スタンバイ・データベースの作成に対して適切に構築されていることの確認
ロジカル・スタンバイ・データベース内の選択した表またはスキーマ全体に対する変更の適用をスキップする方法の提供、およびSQL適用で発生する例外の処理方法の指定
メンテナンスが必要なロジカル・スタンバイ・データベース内の表へのアクセス制御

使用上の注意

権限およびセキュリティ

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

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

DBMS_LOGSTDBYサブプログラムの要約

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

サブプログラム	説明
APPLY_SETプロシージャ	SQL適用を構成およびメンテナンスする様々なパラメータの値を設定します。
APPLY_UNSETプロシージャ	SQL適用を構成およびメンテナンスする様々なパラメータの値をデフォルトに戻します。
BUILDプロシージャ	サプリメンタル・ロギングが正しく有効化されていることを確認し、LogMinerディクショナリを作成します。
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`プロシージャによって指定されたルールを削除します。

APPLY_SETプロシージャ

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

構文

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

パラメータ

表73-2 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ログ・ファイルがロジカル・スタンバイ・データベースに適用された後、そのファイルを自動的に削除します。`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`表に記録します。

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

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

例外

表73-3 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);

APPLY_UNSETプロシージャ

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

構文

DBMS_LOGSTDBY.APPLY_UNSET (
     inname          IN VARCHAR);

パラメータ

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

例外

表73-4 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');

BUILDプロシージャ

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

構文

DBMS_LOGSTDBY.BUILD;

使用上の注意

サプリメンタル・ログ情報には、ロジカル・スタンバイ・データベース内の変更行を一意に識別する、REDOログ内の追加情報が含まれています。また、ロジカル・スタンバイ・データベースへの変更を効率的に適用するための情報も含まれています。
LogMinerディクショナリ情報を使用すると、SQL適用でREDOログ内のデータを解析できます。
DBMS_LOGSTDBY.BUILDは、作成する各ロジカル・スタンバイ・データベースに対して1回のみ実行する必要があります。各RACインスタンスに対して使用する必要はありません。

例

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

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

INSTANTIATE_TABLEプロシージャ

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

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

スタンバイ・データベースへの表の追加
スタンバイ・データベース内の表の再作成

構文

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

パラメータ

表73-5 INSTANTIATE_TABLEプロシージャのパラメータ

パラメータ	説明
`schema_name`	スキーマの名前。
`table_name`	スタンバイ・データベースに作成または再作成する表の名前。
`dblink`	プライマリ・データベース内の表の読込み権限およびロック権限があるデータベース・リンク・アカウントの名前、およびプライマリ・データベースの`SELECT_CATALOG_ROLE`。

例外

表73-6 INSTANTIATE_TABLEプロシージャの例外

例外	説明
`ORA-16103`	この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。
`ORA-16236`	ロジカル・スタンバイ・メタデータ操作は進行中です。
`ORA-16276`	指定したデータベース・リンクはプライマリ・データベースに対応していません。
`ORA-16277`	指定した表はロジカル・スタンバイ・データベースでサポートされていません。
`ORA-16278`	指定した表でマルチオブジェクトのスキップ・ルールが定義されています。

使用上の注意

このプロシージャを使用すると、プライマリ・データベースとトランザクション的に一貫性のある状態にスタンバイ・データベースのデータを保つように、表が作成され、データが移入されます。
この表は、SQL適用によってメンテナンスされる他の表とは同期されません。また、SQL適用によるこの表のメンテナンスは、プライマリからの表のインスタンス化後に発生したREDOが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');

IS_APPLY_SERVERファンクション

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

MAP_PRIMARY_SCNファンクション

プライマリ・データベースの指定SCNより5分以上先行している、スタンバイのSCNを戻します。このファンクションを使用すると、プライマリ・データベースでのフラッシュバック・データベース操作またはPoint-in-Timeリカバリ操作の後に、ロジカル・スタンバイ・データベースでフラッシュバック・データベース操作を補足するときに使用する安全なSCNを判別できます。

構文

DBMS_LOGSTDBY.MAP_PRIMARY_SCN(primary_scn NUMBER) RETURN NUMBER;

例外

表73-7 MAP_PRIMARY_SCNファンクションの例外

例外	説明
`ORA-20001`	プライマリSCNはマップ範囲の前にあります。
`ORA-20002`	SCNマッピングでは、`PRESERVE_COMMIT_ORDER`を`TRUE`にする必要があります。

使用上の注意

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

PREPARE_FOR_NEW_PRIMARYプロシージャ

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

構文

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

パラメータ

表73-8 PREPARE_FOR_NEW_PRIMARYプロシージャのパラメータ

パラメータ説明

パラメータ	説明
`FORMER_STANDBY_TYPE`	フェイルオーバー操作によって新しいプライマリ・データベースとなったスタンバイ・データベースのタイプ。有効な値は、'`PHYSICAL`'（新しいプライマリ・データベースが、以前はフィジカル・スタンバイ・データベースだった場合）および'`LOGICAL`'（新しいプライマリ・データベースが、以前はロジカル・スタンバイ・データベースだった場合）です。
`DBLINK`	新しいプライマリ・データベースへのデータベース・リンクの名前。

FORMER_STANDBY_TYPE

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

DBLINK

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

例外

表73-9 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');

PURGE_SESSIONプロシージャ

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

構文

DBMS_LOGSTDBY.PURGE_SESSION;

例外

表73-10 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プロシージャ」を参照）に基づいて自動的にパージされます。

例

不要なファイルを識別して削除するには、次の手順を実行します。

ロジカル・スタンバイ・データベースで、次の文を入力します。
```
SQL> EXECUTE DBMS_LOGSTDBY.PURGE_SESSION;
```

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

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

REBUILDプロシージャ

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

構文

DBMS_LOGSTDBY.REBUILD;

使用上の注意

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

例

SQL> EXECUTE DBMS_LOGSTDBY.REBUILD;

SET_TABLESPACEプロシージャ

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

構文

DBMS_LOGSTDBY.SET_TABLESPACE(
           NEW_TABLESPACE IN VARCHAR2)

パラメータ

表73-11 SET_TABLE SPACEプロシージャのパラメータ

パラメータ	説明
`NEW_TABLESPACE`	メタデータ表が常駐することになる新しい表領域の名前

例外

表73-12 SET_TABLESPACEプロシージャの例外

例外	説明
`ORA-16103`	この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。
`ORA-16236`	ロジカル・スタンバイ・メタデータ操作は進行中です。

例

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

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

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);

パラメータ

表73-13 SKIPプロシージャのパラメータ

パラメータ	説明
`stmt`	SQL文のセットまたは特定のSQL文を識別するキーワード。キーワード（通常はデータベース・オブジェクトで定義）を使用すると構成が簡単になります。キーワードによって、指定オブジェクトで動作するすべてのSQL文が識別されるためです。表73-14に、キーワードおよびそれに対応するSQL文を示します。いずれもこのパラメータの値として有効です。キーワード`PL/SQL`は、レプリケーション用にサポートされているオラクル社提供のパッケージを実行する場合に使用します。サポート対象パッケージの詳細は、『Oracle Data Guard概要および管理』を参照してください。
`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の場合、SQL適用は、次のコール識別記号を指定してストアド・プロシージャをコールします。 `IN STATEMENT VARCHAR2` -- フィルタと一致するSQL文。 `IN STATEMENT_TYPE VARCHAR2` -- `フィルタのstmt`。 `IN SCHEMA VARCHAR2` -- フィルタの`schema_name`（該当する場合）。 `IN NAME VARCHAR2` -- フィルタの`object_name`（該当する場合）。 `IN XIDUSN NUMBER` -- トランザクションIDパート1。 `IN XIDSLT NUMBER` -- トランザクションIDパート2。 `IN XIDSQN NUMBER` -- トランザクションIDパート3。 `OUT SKIP_ACTION NUMBER` -- このルーチンの完了時にSQL適用で実行する処理。有効な値は、次のとおりです。 `SKIP_ACTION_APPLY` -- 文の実行 `SKIP_ACTION_SKIP` -- 文のスキップ `SKIP_ACTION_ERROR` -- DBAが適切な手順を実行できるように適用を停止（補足アクションの実行など） `SKIP_ACTION_REPLACE` -- `NEW_STATEMENT`出力パラメータで提供された代替文の実行 PL/SQLの場合、SQL適用は、次のコール識別記号を指定してストアド・プロシージャをコールします。 `IN STATEMENT VARCHAR2` -- フィルタと一致するSQL文。 `IN PACKAGE_SCHEMA VARCHAR2` -- スキップ中のパッケージのスキーマ（`SYS`、`XDB`など）。 `IN PACKAGE_NAME VARCHAR2` -- スキップ中のパッケージの名前（`DBMS_RLS`など）。 `IN PROCEDURE_NAME VARCHAR2` – スキップ中のプロシージャの名前（`ADD_POLICY`など）。 `IN CURRENT_SCHEMA VARCHAR2` -- プライマリでPL/SQLを実行した現在のスキーマの名前。 `IN XIDUSN NUMBER` – トランザクションIDパート1。 `IN XIDSLT NUMBER` -- トランザクションIDパート2。 `IN XIDSQN NUMBER` -- トランザクションIDパート3。 `IN EXIT_STATUS` – PL/SQLがプライマリで成功した場合は0（ゼロ）。それ以外の場合は1。
`proc_name`（続き）	`OUT SKIP_ACTION NUMBER` -- このルーチンの完了時にSQL適用で実行する処理。有効な戻り値は、次のとおりです。 `SKIP_ACTION_APPLY` -- 文の実行 `SKIP_ACTION_APPLY` -- 文の実行 `SKIP_ACTION_ERROR` – DBAが適切な手順を実行できるように適用を停止するエラーを生成注意1: `SKIP_ACTION_REPLACE`は、PL/SQLではサポートされていません。注意2: プロシージャの終了が処理されると、SQL適用はスキップ・ハンドラをコールします。注意3: PL/SQLではワイルドカードがサポートされていないため、`use_like`パラメータを`FALSE`に設定する必要があります。次の例では、`DBMS_RLS.DROP_POLICY`の条件付きスキップ・ルールの設定方法を示します。 Create or replace procedure sec_mgr.skip_drop_policy ( statement in varchar2, pkgown in varchar2, pkgname in varchar2, procnm in varchar2, cuser in varchar2, xidusn in number, xidslt in number, xidsqn in number, exstatus in number, skip_action out number) Is Begin If 0 = exstatus Then Insert Into sec_mgr.logit Values ('Success: '\|\|pkgown\|\|'.'\|\|pkgname\|\|'.'\|\|procnm\|\| ' by '\|\|cuser); If cuser != 'TESTSCHEMA' Then skip_action := DBMS_LOGSTDBY.SKIP_ACTION_APPLY; Else skip_action := DBMS_LOGSTDBY.SKIP_ACTION_SKIP; End If; End If; End skip_drop_policy; Execute dbms_logstdby.skip('PL/SQL', 'SYS', 'DBMS_RLS', 'DROP_POLICY', 'SEC_MGR.SKIP_DROP_POLICY', 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イベントのルールおよび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-1031: 権限が不足しています。」メッセージが戻されます。
このプロシージャによってREPLACEMENT文が戻された場合、このREPLACEMENT文は、プロシージャの所有者のSYSTEMおよびOBJECT権限を使用して実行されます。
SKIPプロシージャのPL/SQLブロックは、自律型トランザクションであると宣言されていないかぎり、トランザクション制御文（COMMIT、ROLLBACK、SAVEPOINT、SET CONSTRAINTなど）を含むことはできません。

スキップ文のオプション

表73-14に、SKIPプロシージャのstmtパラメータに対してサポートされる値を示します。表の左の列は、その右側のSQL文のセットを識別するために使用されるキーワードです。また、sys.audit_actions表に示されたSQL文（表73-14の右列を参照）はすべて、有効な値でもあります。キーワードは通常、データベース・オブジェクトによって定義されることに注意してください。

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

キーワード	対応するSQL文
SQL文のこのグループには、キーワードはありません。	`GRANT` `REVOKE`
`CLUSTER`	`AUDIT CLUSTER` `CREATE CLUSTER` `DROP CLUSTER` `TRUNCATE CLUSTER`
`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`	`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`¹	オラクル社が提供するパッケージを実行します。
`PROCEDURE`²	`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`

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

²Javaスキーマ・オブジェクト（ソース、クラスおよびリソース）は、SQL文をスキップする（処理しない）という目的に関してはプロシージャと同様であるとみなされます。

例外

表73-15 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', -
     table_name => '%', -
     proc_name => null);
SQL> EXECUTE DBMS_LOGSTDBY.SKIP(STMT => 'DML', -
     schema_name => 'HR', -
     table_name => '%', -
     proc_name => null);

例2 異なるファイル・システムの編成を処理するプロシージャの作成

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

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

CREATE OR REPLACE PROCEDURE sys.handle_tbs_ddl (

  old_stmt  IN  VARCHAR2,
  stmt_typ  IN  VARCHAR2,
  schema    IN  VARCHAR2,
  name      IN  VARCHAR2,
  xidusn    IN  NUMBER,
  xidslt    IN  NUMBER,
  xidsqn    IN  NUMBER,
  action    OUT NUMBER,
  new_stmt  OUT VARCHAR2
) AS
BEGIN

-- All primary file specification that contains a directory
-- /usr/orcl/primary/dbs
-- should go to /usr/orcl/stdby directory specification


  new_stmt = replace(old_stmt,
                     '/usr/orcl/primary/dbs',
                     '/usr/orcl/stdby');

  action := DBMS_LOGSTDBY.SKIP_ACTION_REPLACE;

EXCEPTION
  WHEN OTHERS THEN
    action := DBMS_LOGSTDBY.SKIP_ACTION_ERROR;
    new_stmt := NULL;
END handle_tbs_ddl;

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

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

SKIP_ERRORプロシージャ

エラーが発生すると、ロジカル・スタンバイ・データベースは、このプロシージャに含まれている基準を使用して、SQL適用を停止するかどうかを判断します。スキップされるエラーはすべて、例外の処理方法を記述するシステム表に格納されます。

構文

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

パラメータ

表73-16 SKIP_ERRORプロシージャのパラメータ

パラメータ	説明
`stmt`	SQL文のセットまたは特定のSQL文を識別するキーワード。キーワード（通常はデータベース・オブジェクトで定義）を使用すると構成が簡単になります。キーワードによって、指定オブジェクトで動作するすべてのSQL文が識別されるためです。表73-14に、キーワードおよびそれに対応する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適用は、次のコール識別記号を指定してストアド・プロシージャをコールします。 `IN STATEMENT VARCHAR(4000)` -- 文の先頭4K。 `IN STATEMENT_TYPE VARCHAR2` -- `フィルタのstmt`。 `IN SCHEMA VARCHAR2` -- フィルタの`schema_name`（該当する場合）。 `IN NAME VARCHAR2` -- フィルタの`object_name`（該当する場合）。 `IN XIDUSN NUMBER` -- トランザクションIDパート1。 `IN XIDSLT NUMBER` -- トランザクションIDパート2。 `IN XIDSQN NUMBER` -- トランザクションIDパート3。 `IN ERROR VARCHAR(4000)` -- 記録されるエラー・テキスト（オプション）。 `OUT NEW_ERROR VARCHAR(4000)` -- NULLまたは修正されたエラー・テキスト。
`use_like`	パターン・マッチングによって、ロジカル・スタンバイ・データベース上でスキップする表を区別することができます。`use_like`パラメータは、2番目の値に指定されたパターンの最初の値を検索して、文字列値の一部を比較し、入力キャラクタ・セットによって定義された文字を使用して、文字列を予想します。このパラメータは、『Oracle Database SQL言語リファレンス』で説明されているパターン・マッチングと同じ規則に従います。
`esc`	パターン・マッチングに使用できるエスケープ文字（文字"%"または"_"など）を識別します。パターン内の文字%または_の前にエスケープ文字があると、Oracleではこの文字を特殊なパターン・マッチング文字としてではなく、パターン内の文字通りに解釈します。パターン・マッチングの詳細は、『Oracle Database SQL言語リファレンス』を参照してください。

使用上の注意

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-1031: 権限が不足しています。」メッセージが戻されます。
SKIP_ERRORプロシージャのPL/SQLブロックは、次に示す構文を使用して自律型トランザクションであると宣言されていないかぎり、トランザクション制御文（COMMIT、ROLLBACK、SAVEPOINT、SET CONSTRAINTなど）を含むことはできません。
```
PRAGMA AUTONOMOUS_TRANSACTION
```

例外

表73-17 SKIP_ERRORプロシージャの例外

例外	説明
`ORA-01031`	権限が不足しています。プロシージャで`INVOKER`権限が使用されました。プロシージャに`DBA`権限が必要です。
`ORA-16103`	この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。
`ORA-16104`	ロジカル・スタンバイ・オプションのリクエストが無効です。
`ORA-16236`	ロジカル・スタンバイ・メタデータ操作は進行中です。

例

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

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

CREATE OR REPLACE PROCEDURE sys.handle_error_ddl (
  old_stmt    IN  VARCHAR2,
  stmt_type   IN  VARCHAR2,
  schema      IN  VARCHAR2,
  name        IN  VARCHAR2,
  xidusn      IN  NUMBER,
  xidslt      IN  NUMBER,
  xidsqn      IN  NUMBER,
  error       IN  VARCHAR2,
  new_stmt    OUT VARCHAR2
) AS

BEGIN
  -- Default to what we already have
  new_stmt := old_stmt;

  -- Ignore any GRANT errors on SYS or HR schemas
IF ((INSTR(UPPER(old_stmt),'GRANT')) > 0) OR
((INSTR(UPPER(old_stmt),'REVOKE')) > 0)
  THEN
    IF schema IS NULL
    OR (schema IS NOT NULL AND
          (UPPER(schema) = 'SYS'  OR UPPER(schema) = 'HR' ))
    THEN
      new_stmt := NULL;
      -- record the fact that we just skipped an error on 'SYS' or 'HR' schemas
      -- code not shown here
    END IF;
  END IF;

END handle_error_ddl;
/

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

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

SKIP_TRANSACTIONプロシージャ

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

構文

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

パラメータ

表73-18 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適用でスキップされる予定のトランザクションが示されます。
『Oracle Database SQL言語リファレンス』のALTER DATABASE START LOGICAL STANDBY SKIP FAILED TRANSACTION文に関する項も参照してください。

例外

表73-19 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);

UNSKIPプロシージャ

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

構文

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

パラメータ

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

例外

表73-20 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);
```
次の例では、OBJECT_NAMEパラメータにワイルドカードが使用されていますが、これで指定済のルールを削除することはできません。
```
SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP (STMT => 'DML',-
     SCHEMA_NAME => 'HR', -
     OBJECT_NAME => 'EMP%');
```
OBJECT_NAMEパラメータのワイルドカード文字は展開されないため、このUNSKIPプロシージャは、実際にはいずれのルールとも一致しません。この場合、ワイルドカード文字は完全一致で使用され、対応するSKIPルールが検索されます。

UNSKIP_ERRORプロシージャ

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

構文

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

パラメータ

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

例外

表73-21 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_ERRORプロシージャを使用して、指定済のルールを削除することはできません。
```
SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP_ERROR (STMT => 'DML',-
     SCHEMA_NAME => 'HR', -
     OBJECT_NAME => 'EMP%');
```
OBJECT_NAMEパラメータのワイルドカード文字は展開されないため、このUNSKIP_ERRORプロシージャは、実際にはいずれのルールとも一致しません。

例

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

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

UNSKIP_TRANSACTIONプロシージャ

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

構文

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

パラメータ

表73-22 UNSKIP_TRANSACTIONプロシージャのパラメータ

パラメータ	説明
`XIDUSN`	スキップ対象トランザクションのトランザクションID UNDOセグメント番号。
`XIDSLT`	スキップ対象トランザクションのトランザクションIDスロット番号。
`XIDSQN`	スキップ対象トランザクションのトランザクションID順序番号。

例外

表73-23 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);