ヘッダーをスキップ
Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス
11g リリース2(11.2)
B56262-06
  目次へ移動
目次		 索引へ移動
索引
前
前 		 次
次		  

86 DBMS_LOGSTDBY

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


関連項目:

SQL適用およびロジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。

この章では、次の項目について説明します。

DBMS_LOGSTDBYの使用方法

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

概要

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

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

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

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

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

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

セキュリティ・モデル

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

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

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

DBMS_LOGSTDBYサブプログラムの要約

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

パラメータ

表86-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ログ・ファイルがロジカル・スタンバイ・データベースに適用されるとすぐに、そのファイルを自動的に削除します。デフォルトでは、外部アーカイブ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適用を実行しているインスタンスに接続する必要があります。

例外

表86-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プロシージャに関する情報と同じです。パラメータ情報の詳細は、表86-2を参照してください。

例外

表86-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適用で使用されます。このプロシージャによって、必要に応じて、データベース全体でのプライマリ・キーおよび一意キーのサプリメンタル・ロギングが可能になります。


注意:

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;

INSTANTIATE_TABLEプロシージャ

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

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

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

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

構文

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

パラメータ

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

パラメータ 説明

schema_name

スキーマの名前。

table_name

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

dblink

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

例外

表86-6 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');

IS_APPLY_SERVERファンクション

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


関連項目:

DBMS_DDL.SET_TRIGGER_FIRING_PROPERTYサブプログラムの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

構文

DBMS_LOGSTDBY.IS_APPLY_SERVER
RETURN BOOLEAN;

パラメータ

なし

MAP_PRIMARY_SCNファンクション

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

構文

DBMS_LOGSTDBY.MAP_PRIMARY_SCN(primary_scn NUMBER) RETURN NUMBER;

例外

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

パラメータ

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

パラメータ 説明

FORMER_STANDBY_TYPE

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

DBLINK

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

例外

表86-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;

例外

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

例

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

  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ログ・ファイルをファイル・システムから削除します。

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)

パラメータ

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

パラメータ 説明

NEW_TABLESPACE

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

例外

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

パラメータ

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

パラメータ 説明

stmt

SQL文のセットまたは特定のSQL文を識別するキーワード。(通常はデータベース・オブジェクトで定義される)キーワードを使用すると、指定オブジェクトで動作するすべてのSQL文が識別されるため、構成が簡単になります。表86-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( -
     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など)を含むことはできません。

スキップ文のオプション

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

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

キーワード 対応するSQL文

SQL文のこのグループには、キーワードはありません。

 
GRANT
REVOKE
ANALYZE TABLE
ANALYZE INDEX
ANALYZE CLUSTER

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 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文をスキップする(処理しない)という目的に関してはプロシージャと同様であるとみなされます。

例外

表86-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', -
     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 (

  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;

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

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

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

パラメータ

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

パラメータ 説明

stmt

SQL文のセットまたは特定のSQL文を識別するキーワード。(通常はデータベース・オブジェクトで定義される)キーワードを使用すると、指定オブジェクトで動作するすべてのSQL文が識別されるため、構成が簡単になります。表86-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適用を継続する。

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

  • 何もせず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-01031: 権限が不足しています」メッセージが戻されます。

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

    PRAGMA AUTONOMOUS_TRANSACTION

例外

表86-17 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 ( 
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_error OUT VARCHAR2 
) AS 
BEGIN 
-- Default to what we already have 
new_error := error; 
-- Ignore any GRANT errors on SYS or HR schemas 
IF INSTR(UPPER(old_stmt),'GRANT') > 0 
THEN 
IF schema IS NULL 
OR (schema IS NOT NULL AND 
(UPPER(schema) = 'SYS' OR UPPER(schema) = 'HR' ) 
THEN 
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; 
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');

SKIP_TRANSACTIONプロシージャ

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

構文

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

パラメータ

表86-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文に関する項も参照してください。

例外

表86-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プロシージャで説明した情報と同じです。パラメータ情報の詳細は、表86-13を参照してください。

例外

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

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

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

    TABLE_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プロシージャに関する情報と同じです。パラメータ情報の詳細は、表86-16を参照してください。

例外

表86-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プロシージャを使用して、指定済のルールを削除することはできません。

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

UNSKIP_TRANSACTIONプロシージャ

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

構文

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

パラメータ

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

パラメータ 説明

XIDUSN

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

XIDSLT

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

XIDSQN

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

例外

表86-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);
  前
前 		 次
次
  目次へ移動
目次		 索引へ移動
索引