97 DBMS_LOGSTDBY
DBMS_LOGSTDBY
パッケージは、ロジカル・スタンバイ・データベース環境を構成および管理するためのサブプログラムを提供します。
この章のトピックは、次のとおりです:
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
システム権限も必要です。
97.3 DBMS_LOGSTDBYの定数
DBMS_LOGSTDBY
パッケージは、パラメータ値の指定に使用するいくつかの列挙定数を定義します。列挙定数にはパッケージ名を接頭辞として付加する必要があります(DBMS_LOGSTDBY
.SKIP_ACTION_SKIP
など)。
次の表では、DBMS_LOGSTDBY
.SKIP
プロシージャ内のproc_name
パラメータの定数について説明します。
表97-1 SKIPオプション・フラグの定数
定数 | 説明 |
---|---|
|
|
|
|
|
|
|
|
|
|
97.4 DBMS_LOGSTDBYサブプログラムの要約
この表では、各プロシージャが詳しく説明されている項への参照を含め、DBMS_LOGSTDBYプロシージャの各サブプログラムについて説明します。
マルチテナント・コンテナ・データベース(CDB)では、一部のサブプログラムはルートからコールする必要があります。それ以外にも、違いがある可能性があります。詳細は、個々のサブプログラムの説明を参照してください。
表97-2 DBMS_LOGSTDBYパッケージのサブプログラム
サブプログラム | 説明 |
---|---|
SQL適用を構成およびメンテナンスする様々なパラメータの値を設定します。 |
|
SQL適用を構成およびメンテナンスする様々なパラメータの値をデフォルトに戻します。 |
|
サプリメンタル・ロギングが正しく有効化されていることを確認し、LogMinerディクショナリを作成します。 |
|
表のEDSベースのレプリケーションを追加します。これは、プライマリ・データベース、スタンバイ・データベースの順に起動される必要があります。 |
|
EDS表の自動DDL処理を有効または無効にします。 |
|
EDS表を手動で展開できます(つまり、EDSレプリケーションにおいて、元表に対するDDL操作に基づいた補足アクションを手動で実行できます)。 |
|
指定した表のEDSベースのレプリケーションを削除します。シャドウ表やトリガーも削除されます。 |
|
プライマリ・データベース内の対応する表から、スタンバイ・データベース内に表を作成し、データを移入します。 |
|
このファンクションは、ロジカル・スタンバイ適用サーバー・プロセスのコンテキストでPL/SQLから実行された場合、 |
|
プライマリ・データベースに関連するSCNをロジカル・スタンバイ・データベースの対応するSCNにマップします。マップされたSCNは本質的に保守的なため、マップされたSCNを使用すると、ロジカル・スタンバイ・データベースをフラッシュバックして、プライマリ・データベースで実行されるフラッシュバック・データベース操作を補足できます。 |
|
フェイルオーバーの後で使用され、フェイルオーバー動作に関係しなかったローカルのロジカル・スタンバイ・データベースで新しいプライマリ・データベースより多くのREDOが処理されないようにし、一貫性を保証するために置換する必要があるアーカイブREDOログ・ファイル・セットをレポートします。 |
|
ロジカル・スタンバイ・データベースに適用済で、SQL適用で不要になったアーカイブREDOログ・ファイルを識別します。 |
|
フェイルオーバー操作に伴ってプライマリ・データベースに役割が変更されたデータベースで、フェイルオーバー・プロセス中にその役割の変更を処理できない場合、関連するメタデータ(LogMinerディクショナリを含む)をREDOストリームに記録します。 |
|
SQL適用で必要なメタデータ表を、ユーザー指定の表領域に移動します。デフォルトでは、メタデータ表は、 |
|
ロジカル・スタンバイ・データベースに適用しないデータベース操作を制御するルールを指定します。 |
|
エラー発生時に実行するアクションに関するルールを指定します。 |
|
ロジカル・スタンバイ・データベースに適用しないトランザクションを指定します。特定のトランザクションを適用しないことによって、ロジカル・スタンバイ・データベースのデータが破損する場合があるため、このプロシージャは注意して使用してください。 |
|
|
|
|
|
|
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プロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
変更の適用に使用する |
|
関連イベントの発生をSQL適用が記録する場所を制御します。値は次のいずれかとなります。
たとえば、SQL適用が このパラメータは、 |
|
このパラメータ設定が意味を持つのは、 |
|
外部アーカイブREDOログ・ファイルがロジカル・スタンバイ・データベースに適用されるとすぐに、そのファイルを自動的に削除します。デフォルトでは、外部アーカイブREDOログ・ファイルは、ロジカル・スタンバイ・データベースで適用されてから24時間( |
|
|
|
SQL適用で読取りとREDOの適用に使用するプロセスの数。デフォルト値は9です。最大値は2048です。 |
|
SQL適用で使用するシステム・グローバル領域(SGA)の共有プールのMB数。デフォルト値は、30MBまたは |
|
変更の準備に使用する |
|
選択したレベルに関係なく、同じ行に対する変更は、常にプライマリ・データベースで検出される順序と同じ順序で適用されます。詳細および推奨は「使用上のノート」を参照してください。 SQL適用の実行中は、このパラメータを変更できません。 |
|
ロジカル・スタンバイ・データベースに適用されたDDL文を
|
|
スキップしたDDL文を
|
|
スキップしたエラー(「
|
|
ロジカル・スタンバイ・データベースでサポートされない、プライマリ・データベースで実行中のトランザクションに関する情報を取得します。このプロシージャは、情報をイベントとして
|
SQL適用の実行中にパラメータを変更した場合、この変更は後で有効になります。このような場合、パラメータの変更が有効になった時点で、DBA_LOGSTDBY_EVENTS
ビューに情報行が挿入されます。
また、Oracle RAC構成でSQL適用を実行している間にパラメータを変更する場合は、SQL適用を実行しているインスタンスに接続する必要があります。
例外
表97-4 APPLY_SETプロシージャの例外
例外 | 説明 |
---|---|
|
この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。 |
|
ロジカル・スタンバイ・オプションのリクエストが無効です。 |
|
ロジカル・スタンバイ・メタデータ操作は進行中です。 |
使用上のノート
-
パラメータの設定をデフォルトに戻すには、
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プロシージャの例外
例外 | 説明 |
---|---|
|
この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。 |
|
ロジカル・スタンバイ・オプションのリクエストが無効です。 |
|
ロジカル・スタンバイ・メタデータ操作は進行中です。 |
使用上のノート
-
パラメータにデフォルト以外の値を指定するには、
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プロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
スタンバイ・データベースに作成または再作成する表の所有者。 |
|
スタンバイ・データベースに作成または再作成する表の名前。 |
|
プライマリ・データベースへのデータベース・リンク。 |
例外
表97-7 EDS_ADD_TABLEプロシージャの例外
例外 | 説明 |
---|---|
|
表またはビューが存在しません。 |
|
この操作を許可するにはSQL適用を停止する必要があります。 |
|
ログ・ストリームからのサプリメンタル・ログ情報がありません。 |
|
ロジカル・スタンバイ・メタデータ操作は進行中です。 |
|
指定したデータベース・リンクはプライマリ・データベースに対応していません。 |
|
指定した表でマルチオブジェクトのスキップ・ルールが定義されています。 |
|
指定したデータベース・リンクに、操作に必要なロールがありません。 |
|
拡張データ・タイプは指定した表ではサポートされていません。 |
|
指定した表には、このデータベースのEDSがすでに存在します。 |
|
プライマリ・データベースでは最初にプロシージャをコールする必要があります。 |
|
指定した表に主キーがありません。 |
使用上のノート
-
このプロシージャをプライマリでコールすると、ローカル表の定義を使用してシャドウ表が作成されます。その後、元表とシャドウ表が両方ともトリガーされます。
-
このプロシージャをスタンバイでコールすると、プライマリへのデータベース・リンク(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 |
|
例外
表97-9 EDS_EVOLVE_AUTOMATIC例外の説明
例外 | 説明 |
---|---|
|
指定されたパラメータは無効です。 |
|
ロジカル・スタンバイではプロシージャがサポートされていません |
使用上のノート
-
すべての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パラメータの説明
パラメータ | 説明 |
---|---|
|
有効なオプションは次のとおりです。
|
|
スタンバイ・データベースに作成または再作成する表の所有者。 |
|
スタンバイ・データベースに作成または再作成する表の名前。 |
例外
表97-11 EDS_EVOLVE_MANUAL例外の説明
例外 | 説明 |
---|---|
|
拡張データ・タイプは指定した表ではサポートされていません。 |
|
ロジカル・スタンバイではプロシージャがサポートされていません |
|
指定した表に主キーがありません。 |
|
拡張データ・タイプの操作をサポートするために表が準備されていません。 |
使用上のノート
-
展開操作を手動で実行するには、EDSを指定してレプリケートされる元表に影響を与える可能性があるDDLの前後で、
EDS_EVOLVE_MANUAL
をコールする必要があります。手動展開の規定の方法は次のとおりです。-
START
オプションを指定してEDS_EVOLVE_MANUAL
をコールします。 -
DDLを実行します。
-
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例外の説明
例外 | 説明 |
---|---|
|
この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。 |
使用上のノート
-
このプロシージャをスタンバイでコールする場合、ローカルではシャドウ表と両方のトリガーが削除されますが、プライマリでは削除されません。
このプロシージャをプライマリでコールする場合、シャドウ表と両方のトリガーが削除された後、適用エンジンによってプロシージャがスタンバイで再実行されます。つまり、ロジカル・スタンバイでサポートされているシャドウ表とトリガーも削除されます。このアプローチを使用すると、プライマリで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プロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
スキーマの名前を指定します。 |
|
スタンバイ・データベースに作成または再作成する表の名前。 |
|
プライマリ・データベース内の表の読込み権限およびロック権限があるデータベース・リンク・アカウントの名前、およびプライマリ・データベースの |
例外
表97-15 INSTANTIATE_TABLEプロシージャの例外
例外 | 説明 |
---|---|
|
この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。 |
|
ロジカル・スタンバイ・メタデータ操作は進行中です。 |
|
指定したデータベース・リンクはプライマリ・データベースに対応していません。 |
|
指定した表はロジカル・スタンバイ・データベースでサポートされていません。 |
|
指定した表でマルチオブジェクトのスキップ・ルールが定義されています。 |
使用上のノート
-
このプロシージャを使用すると、プライマリ・データベースとトランザクション的に一貫性のある状態にスタンバイ・データベースのデータを保つように、表が作成され、データが移入されます。
-
この表は、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ファンクションの例外
例外 | 説明 |
---|---|
|
プライマリSCNはマップ範囲の前にあります。 |
|
SCNマッピングでは、 |
使用上のノート
このファンクションは、プライマリ・データベースの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プロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
フェイルオーバー操作によって新しいプライマリ・データベースとなったスタンバイ・データベースのタイプ。有効な値は、' |
|
新しいプライマリ・データベースへのデータベース・リンクの名前。 |
例外
表97-18 PREPARE_FOR_NEW_PRIMARYプロシージャの例外
例外 | 説明 |
---|---|
|
ロジカル・スタンバイ・オプションのリクエストが無効です。 |
|
以前のプライマリからのログ・データの適用に失敗しました。 |
使用上のノート
-
このルーチンは、ロジカル・スタンバイ・システムのみを対象としています。新しいプライマリ・データベースが以前はロジカル・スタンバイ・データベースで、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プロシージャの例外
例外 | 説明 |
---|---|
|
セッションが無効です。 |
使用上のノート
-
このプロシージャでは、アーカイブ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ログ・ファイルをファイル・システムから削除します。
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プロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
メタデータ表が常駐することになる新しい表領域の名前 |
例外
表97-21 SET_TABLESPACEプロシージャの例外
例外 | 説明 |
---|---|
|
この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。 |
|
ロジカル・スタンバイ・メタデータ操作は進行中です。 |
例
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プロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
SQL文のセットまたは特定のSQL文を識別するキーワード。(通常はデータベース・オブジェクトで定義される)キーワードを使用すると、指定オブジェクトで動作するすべてのSQL文が識別されるため、構成が簡単になります。表97-23に、キーワードおよびそれに対応するSQL文を示しますが、いずれもこのパラメータの値として有効です。 キーワード |
|
|
|
|
|
SQL適用で、特定の文が
このプロシージャは、SQL適用に対して、文の実行、文のスキップまたは代替文の実行のいずれかを行うように指示する値を戻します。 DDLまたはPL/SQLの場合に呼び出されるプロシージャでは引数が取得されません。ネームスペース スキップ・プロシージャのコンテキストでアクセス可能なパラメータの完全なリストは、 DDLの場合に対象となるパラメータは、 PL/SQLの場合に対象となるパラメータは、 ノート1: ノート2: プロシージャの終了が処理されると、SQL適用はスキップ・ハンドラをコールします。 ノート3: PL/SQLではワイルドカードがサポートされていないため、 |
|
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); |
|
パターン・マッチングによって、ロジカル・スタンバイ・データベース上でスキップする表を区別することができます。 |
|
パターン・マッチングに使用できるエスケープ文字(文字"/"など)を識別します。パターン内の文字%または_の前にエスケープ文字があると、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文に対するキーワードはない。 |
|
|
|
|
「コンテナのスキップ」を参照してください。 |
|
|
|
|
|
|
|
|
|
表内のDML文を含む(例: |
|
|
|
特定のスキーマに関連付けられていないすべてのDDL ノート: |
|
オラクル社が提供するパッケージを実行します。 |
|
|
|
|
|
|
|
|
|
スキーマ・オブジェクト(例: 表、索引、列)の作成、変更または削除を行うすべてのDDL文 ノート: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
脚注1
すべてのディレクトリ・オブジェクトはSYS
が所有していまが、skipディレクティブでフィルタリングするためにスキーマは「'%'」と指定する必要があります。
脚注2
サポート対象パッケージの詳細は、『Oracle Data Guard概要および管理』を参照してください。
脚注3
Javaスキーマ・オブジェクト(ソース、クラス、リソース)は、SQL文をスキップ(無視)するためのプロシージャと同等とみなされます。
例外
表97-24 DBMS_LOGSTDBY.SKIPプロシージャの例外
例外 | 説明 |
---|---|
|
権限が不十分です。
|
|
この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。 |
|
ロジカル・スタンバイ・オプションのリクエストが無効です。 |
|
|
|
ロジカル・スタンバイ・メタデータ操作は進行中です。 |
例
- 例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文を処理できます。-
表領域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;
-
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プロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
SQL文のセットまたは特定のSQL文を識別するキーワード。(通常はデータベース・オブジェクトで定義される)キーワードを使用すると、指定オブジェクトで動作するすべてのSQL文が識別されるため、構成が簡単になります。表97-23に、キーワードおよびそれに対応するSQL文を示しますが、いずれもこのパラメータの値として有効です。 |
|
|
|
|
|
SQL適用でエラーが発生し、特定の文が
このプロシージャは、SQL適用に対して、次のいずれかを行うように指示するエラー・メッセージを戻します。
SQL適用に登録されたプロシージャではパラメータがまったく取得されません。
|
|
パターン・マッチングによって、ロジカル・スタンバイ・データベース上でスキップする表を区別することができます。 |
|
パターン・マッチングに使用できるエスケープ文字(文字"%"または"_"など)を識別します。パターン内の文字%または_の前にエスケープ文字があると、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プロシージャの例外
例外 | 説明 |
---|---|
|
権限が不十分です。
|
|
この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。 |
|
ロジカル・スタンバイ・オプションのリクエストが無効です。 |
|
ロジカル・スタンバイ・メタデータ操作は進行中です。 |
例1
次の例は、GRANT DDL
コマンドから発生したエラーをSQL適用でスキップするルールの指定方法を示しています。
SQL> EXECUTE DBMS_LOGSTDBY.SKIP_ERROR('GRANT')
例2
SYS
またはHR
スキーマで発生したGRANT
文のエラーをスキップするには、プロシージャhandle_error_ddl
を定義して登録します。次の例では、handle_error_ddl
が、SYS
スキーマ内の自立型プロシージャであることを想定しています。
-
エラー・ハンドラ・プロシージャを作成します。
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; /
-
エラー・ハンドラを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プロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
スキップ対象トランザクションのトランザクションID UNDOセグメント番号。 |
|
スキップ対象トランザクションのトランザクションIDスロット番号。 |
|
スキップ対象トランザクションのトランザクション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プロシージャの例外
例外 | 説明 |
---|---|
|
|
|
この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。 |
|
ロジカル・スタンバイ・オプションのリクエストが無効です。 |
例
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プロシージャの例外
例外 | 説明 |
---|---|
|
このプロシージャを実行するには、 |
|
この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。 |
|
ロジカル・スタンバイ・オプションのリクエストが無効です。 |
使用上のノート
警告:
表に対する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プロシージャの例外
例外 | 説明 |
---|---|
|
|
|
この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。 |
|
ロジカル・スタンバイ・オプションのリクエストが無効です。 |
使用上のノート
-
このプロシージャを実行するには、
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プロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
スキップ対象トランザクションのトランザクションID UNDOセグメント番号。 |
|
スキップ対象トランザクションのトランザクションIDスロット番号。 |
|
スキップ対象トランザクションのトランザクションID順序番号。 |
例外
表97-32 UNSKIP_TRANSACTIONプロシージャの例外
例外 | 説明 |
---|---|
|
このプロシージャを実行するには、 |
|
この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。 |
|
ロジカル・スタンバイ・オプションのリクエストが無効です。 |
使用上のノート
-
このプロシージャを実行するには、
DBA
権限が必要です。 -
DBA_LOGSTDBY_SKIP_TRANSACTION
ビューを問い合せると、SQL適用でスキップされる予定のトランザクションが示されます。
例
XIDUSN
、XIDSLT
、XIDSQN
がそれぞれ1、13、1726であるトランザクションの適用をスキップするように指定されていたルールを削除するには、次の文を発行します。
SQL> DBMS_LOGSTDBY.UNSKIP_TRANSACTION (XIDUSN => 1, XIDSLT => 13, XIDSQN => 1726);