| Oracle® Database PL/SQLパッケージおよびタイプ・リファレンス 12c リリース1 (12.1) B71281-05 |
|
 前 |
 次 |
DBMS_LOGSTDBYパッケージは、ロジカル・スタンバイ・データベース環境を構成および管理するためのサブプログラムを提供します。
|
関連項目: SQL適用およびロジカル・スタンバイ・データベースの詳細は、『Oracle Data Guard概要および管理』を参照してください。 |
この章では、次の項目について説明します。
概要
セキュリティ・モデル
定数
この項では、DBMS_LOGSTDBYパッケージの使用に関連する項目について説明します。
DBMS_LOGSTDBYパッケージを使用して、SQL適用(ロジカル・スタンバイ・データベース)環境を管理できます。DBMS_LOGSTDBYパッケージのサブプログラムを使用すると、次の主な目的を実現できます。
たとえば、ロジカル・スタンバイ・データベースへのトランザクションの適用方法、使用する共有プールの大きさ、SQL適用での変更の調査および適用に使用するプロセスの数などを制御します。
適切なレベルのサプリメンタル・ロギングが有効になっていること、およびLogMinerディクショナリがロジカル・スタンバイ・データベースの作成に対して適切に構築されていることの確認
ロジカル・スタンバイ・データベース内の選択した表またはスキーマ全体に対する変更の適用をスキップする方法の提供、およびSQL適用で発生する例外の処理方法の指定
メンテナンスが必要なロジカル・スタンバイ・データベース内の表へのアクセス制御
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システム権限も必要です。
DBMS_LOGSTDBYパッケージは、パラメータ値の指定に使用するいくつかの列挙定数を定義します。列挙定数にはパッケージ名を接頭辞として付加する必要があります(DBMS_LOGSTDBY.SKIP_ACTION_SKIPなど)。
表92-1では、DBMS_LOGSTDBY.SKIPプロシージャ内のproc_nameパラメータの定数について説明します。
表92-1 SKIPオプション・フラグの定数
| 定数 | 説明 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
マルチテナント・コンテナ・データベース(CDB)では、一部のサブプログラムはルートからコールする必要があります。それ以外にも、違いがある可能性があります。詳細は、個々のサブプログラムの説明を参照してください。
表92-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適用で必要なメタデータ表を、ユーザー指定の表領域に移動します。デフォルトでは、メタデータ表は、 |
|
|
ロジカル・スタンバイ・データベースに適用しないデータベース操作を制御するルールを指定します。 |
|
|
エラー発生時に実行するアクションに関するルールを指定します。 |
|
|
ロジカル・スタンバイ・データベースに適用しないトランザクションを指定します。特定のトランザクションを適用しないことによって、ロジカル・スタンバイ・データベースのデータが破損する場合があるため、このプロシージャは注意して使用してください。 |
|
|
|
|
|
|
|
|
|
このプロシージャを使用して、ロジカル・スタンバイ・データベース環境でSQL適用を構成および管理するパラメータの値を設定します。PRESERVE_COMMIT_ORDERを除くすべてのパラメータは、SQL適用を停止しなくても変更できます。
CDBでは、APPLY_SETプロシージャはルート・データベースからコールする必要があります。
パラメータ
表92-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適用を実行しているインスタンスに接続する必要があります。
APPLY_UNSETプロシージャで変更したパラメータの値をデフォルトに戻すには、APPLY_SETプロシージャを使用します。
CDBでは、APPLY_UNSETプロシージャはルート・データベースからコールする必要があります。
このプロシージャをプライマリ・データベースで使用して、関連するメタデータ(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構成内のすべてのロジカル・スタンバイが使用できなくなります。すでにスイッチオーバーまたはフェイルオーバーが行われ、サプリメンタル・ロギングが有効でない場合は、すべてのロジカル・スタンバイ・データベースを再作成する必要があります。 |
使用上の注意
サプリメンタル・ログ情報には、ロジカル・スタンバイ・データベース内の変更行を一意に識別する、REDOログ内の追加情報が含まれています。また、ロジカル・スタンバイ・データベースへの変更を効率的に適用するための情報も含まれています。
LogMinerディクショナリ情報を使用すると、SQL適用でREDOログ内のデータを解析できます。
DBMS_LOGSTDBY.BUILDは、作成する各ロジカル・スタンバイ・データベースに対して1回のみ実行する必要があります。各Oracle RACインスタンスに対してDBMS_LOGSTDBY.BUILDを使用する必要はありません。
DBMS_LOGSTDBY.BUILDは、プロシージャ起動時にアクティブなすべてのトランザクション(分散トランザクションを含む)が完了するまで待機してから戻ります。インダウト・トランザクションの処理方法の詳細は、『Oracle Database管理者ガイド』を参照してください。
このプロシージャは、表のEDSベースのレプリケーションを追加します。これは、プライマリ・データベース、スタンバイ・データベースの順に起動される必要があります。
構文
DBMS_LOGSTDBY.EDS_ADD_TABLE (
table_owner IN VARCHAR2,
table_name IN VARCHAR2,
p_dblink IN VARCHAR2);
例外
表92-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;
このプロシージャは、EDS表の自動DDL処理を有効または無効にします。
使用上の注意
すべての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表を手動で展開できます(つまり、EDSレプリケーションにおいて、元表に対するDDL操作に基づいた補足アクションを手動で実行できます)。
構文
DBMS_LOGSTDBY.EDS_EVOLVE_MANUAL (
options IN VARCHAR2,
table_owner IN VARCHAR2,
table_name IN VARCHAR2);
使用上の注意
展開操作を手動で実行するには、EDSを指定してレプリケートされる元表に影響を与える可能性があるDDLの前後で、EDS_EVOLVE_MANUALをコールする必要があります。手動展開の規定の方法は次のとおりです。
STARTオプションを指定してEDS_EVOLVE_MANUALをコールします。
DDLを実行します。
FINISHオプションを指定してEDS_EVOLVE_MANUALをコールします。
この順序に従わないと、データが失われる可能性があります。指定した表について、FINISHオプションを指定したプロシージャ・コールがSTARTオプションを指定したプロシージャ・コールよりも前に実行される場合、エラーが戻されます。STARTオプションを指定したプロシージャのコール時に、展開トリガーによって表に対するDMLがブロックされます。
このプロシージャは、プライマリ・データベースでのみ起動できます。
このプロシージャをスタンバイで実行する場合、SQL適用を停止して、データベース・ガードをSTANDBYまたはNONEのいずれかに設定する必要があります。プロシージャの実行が完了すると、表はデータベース・ガードによって保護されます。
このプロシージャは、指定した表のEDSベースのレプリケーションを削除します。シャドウ表やトリガーも削除されます。
使用上の注意
このプロシージャをスタンバイでコールする場合、ローカルではシャドウ表と両方のトリガーが削除されますが、プライマリでは削除されません。
このプロシージャをプライマリでコールする場合、シャドウ表と両方のトリガーが削除された後、適用エンジンによってプロシージャがスタンバイで再実行されます。つまり、ロジカル・スタンバイでサポートされているシャドウ表とトリガーも削除されます。このアプローチを使用すると、プライマリで1回コールするだけで、表の全構成からEDSを削除できます。
マルチスタンバイ構成で1つのスタンバイのサポートを削除する場合は、そのスタンバイでこのプロシージャをコールできます。
このプロシージャは、同じ表に対するユーザーの継続的な書込みが行われている間でも、排他表ロックを解消することでデータの独立性を確保します。つまり、表への行ロックが残っている現行の書込みトランザクションが完了するまで、プロシージャがブロックします。
このプロシージャをスタンバイで実行する場合、SQL適用を停止して、データベース・ガードをSTANDBYまたはNONEのいずれかに設定する必要があります。プロシージャの実行が完了すると、表はデータベース・ガードによって保護されます。
このプロシージャは、プライマリ・データベース内の対応する表から、スタンバイ・データベース内に表を作成し、データを移入します。表には、入力パラメータとしてデータベース・リンク(dblink)名が必要です。ロジカル・スタンバイ・データベース内に表がすでに存在する場合、その表は削除され、プライマリ・データベースの表定義に基づいて再作成されます。このプロシージャは、表に関連付けられているデータに対してのみ適用され、関連付けられている索引および制約には適用されません。
INSTANTIATE_TABLEプロシージャを使用すると、次のことを実行できます。
スタンバイ・データベースへの表の追加
スタンバイ・データベース内の表の再作成
CDBでは、INSTANTIATE_TABLEプロシージャは、インスタンス化する表が存在するコンテナ内からコールする必要があります。また、プライマリ・データベースで用意されているデータベース・リンクが、プライマリの対応するコンテナをポイントする必要があります。
構文
DBMS_LOGSTDBY.INSTANTIATE_TABLE (
schema_name IN VARCHAR2,
table_name IN VARCHAR2,
dblink IN VARCHAR2);
使用上の注意
このプロシージャを使用すると、プライマリ・データベースとトランザクション的に一貫性のある状態にスタンバイ・データベースのデータを保つように、表が作成され、データが移入されます。
この表は、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コールを再試行する前に、この表に関連するマルチオブジェクト・スキップ・ルールをすべて削除または変更する必要があります。
このファンクションは、ロジカル・スタンバイ適用サーバー・プロセスのコンテキストでPL/SQLから実行された場合、TRUEを戻します。このファンクションは、DBMS_DDL.SET_TRIGGER_FIRING_PROPERTYサブプログラムのfire_onceパラメータがFALSEに設定されている(デフォルトはTRUE)トリガーと一緒に使用します。このようなトリガーは、適用プロセスによって関連ターゲットが更新されると実行されます。このファンクションは、トリガー本体内で使用して、トリガーがプライマリまたはスタンバイで異なるアクションを実行する(またはアクションを実行しない)ようにすることができます。
|
関連項目: DBMS_DDL.SET_TRIGGER_FIRING_PROPERTYサブプログラムの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』 |
プライマリ・データベースの指定SCNより5分以上先行している、スタンバイのSCNを戻します。このファンクションを使用すると、プライマリ・データベースでのフラッシュバック・データベース操作またはPoint-in-Timeリカバリ操作の後に、ロジカル・スタンバイ・データベースでフラッシュバック・データベース操作を補足するときに使用する安全なSCNを判別できます。
PREPARE_FOR_NEW_PRIMARYプロシージャは、フェイルオーバーの発生後、ロジカル・スタンバイ・データベースがフェイルオーバーの対象でなかった場合、そのスタンバイ・データベースで起動する必要があります。このようなスタンバイ・データベースでは、新しいプライマリ・データベースで処理されるREDOログ・セットと同じREDOログ・セットを処理する必要があります。このルーチンは、ローカルのロジカル・スタンバイ・データベースで新しいプライマリ・データベースより多くのREDOが処理されないようにし、一貫性を保証するために置換する必要があるアーカイブ・ログ・ファイル・セットをレポートします。一連の置換ログは、アラート・ログにレポートされます。これらのログは、ロジカル・スタンバイにコピーし、ALTER DATABASE REGISTER LOGICAL LOGFILE文を使用して登録する必要があります。
CDBでは、PREPARE_FOR_NEW_PRIMARYプロシージャはルート・データベースからコールする必要があります。
使用上の注意
このルーチンは、ロジカル・スタンバイ・システムのみを対象としています。新しいプライマリ・データベースが以前はロジカル・スタンバイ・データベースで、LogMinerディクショナリの作成が正常に完了していない場合、このルーチンは失敗します。アラート・ログに表示されるログ・ファイルは、端末ログと呼ばれます。ファイル・パスは、新しいプライマリ・データベースに対する相対パスであり、ローカルに解決できない場合があることに注意してください。端末ログを手動で登録する際は、START LOGICAL STANDBY APPLY(新しいプライマリ・データベースが、以前はフィジカル・スタンバイ・データベースだった場合)またはSTART LOGICAL STANDBY APPLY NEW PRIMARY(新しいプライマリ・データベースが、以前はロジカル・スタンバイ・データベースだった場合)のいずれかをコールして、処理を完了する必要があります。例外が発生した理由の詳細は、アラート・ログを参照してください。
ロジカル・スタンバイ・データベースに適用済で、SQL適用で不要になったすべてのアーカイブREDOログ・ファイルを識別します。識別後、オペレーティング・システム・コマンドを発行して、一部またはすべての不要なアーカイブREDOログ・ファイルを削除できます。
CDBでは、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ログ・ファイルをファイル・システムから削除します。
このプロシージャは、フェイルオーバー操作に伴ってプライマリ・データベースに役割が変更されたデータベースで、関連するメタデータ(LogMinerディクショナリを含む)を他のロジカル・スタンバイ・データベースで必要なREDOストリームに記録できない場合に使用します。
CDBでは、REBUILDプロシージャはルート・データベースからコールする必要があります。
SQL適用で必要なメタデータ表を、ユーザー指定の表領域に移動します。デフォルトでは、メタデータ表は、SYSAUX表領域内に作成されます。このプロシージャを起動しているときは、SQL適用を実行できません。
CDBでは、SET_TABLESPACEプロシージャはルート・データベースからコールする必要があります。
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);
パラメータ
表92-22 SKIPプロシージャのパラメータ
| パラメータ | 説明 |
|---|---|
|
|
SQL文のセットまたは特定のSQL文を識別するキーワード。(通常はデータベース・オブジェクトで定義される)キーワードを使用すると、指定オブジェクトで動作するすべてのSQL文が識別されるため、構成が簡単になります。表92-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など)を含むことはできません。
スキップ文のオプション
表92-23に、SKIPプロシージャのstmtパラメータに対してサポートされる値を示します。表の左の列は、その右側のSQL文のセットを識別するために使用されるキーワードです。また、sys.audit_actions表に示されたSQL文(表92-23の右列を参照)はすべて、有効な値でもあります。キーワードは通常、データベース・オブジェクトによって定義されることに注意してください。
表92-23 stmtパラメータに対してサポートされる値
| キーワード | 対応するSQL文 |
|---|---|
|
SQL文のこのグループには、キーワードはありません。 |
|
|
|
|
|
|
「コンテナのスキップ」を参照してください。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表に対するDML文( |
|
|
|
|
|
特定のスキーマに関係しないすべてのDDL 注意: |
|
|
オラクル社が提供するパッケージを実行します。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
スキーマ・オブジェクト(表、索引、列など)を作成、変更または削除するすべてのDDL文 注意: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1 すべてのディレクトリ・オブジェクトはSYSが所有していまが、skipディレクティブでフィルタリングするためにスキーマは「'%'」と指定する必要があります。
2 サポート対象パッケージの詳細は、『Oracle Data Guard概要および管理』を参照してください。
3 Javaスキーマ・オブジェクト(ソース、クラスおよびリソース)は、SQL文をスキップする(処理しない)という目的に関してはプロシージャと同様であるとみなされます。
例外
表92-24 DBMS_LOGSTDBY.SKIPプロシージャの例外
| 例外 | 説明 |
|---|---|
|
|
権限が不足しています。
|
|
|
この操作を許可するにはロジカル・スタンバイ適用を停止する必要があります。 |
|
|
ロジカル・スタンバイ・オプションのリクエストが無効です。 |
|
|
|
|
|
ロジカル・スタンバイ・メタデータ操作は進行中です。 |
例
次の例は、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);
たとえば、ファイル・システムの編成がロジカル・スタンバイ・データベースとプライマリ・データベースで異なる場合は、ファイルが指定された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');
|
注意: コンテナに対するその他のスキップ・ルールを作成するには、コンテナ内でルールを作成します。ルールが適用されるコンテナは、そのルールが作成されたコンテナで自動的に判断されます。 |
エラーが発生すると、ロジカル・スタンバイ・データベースは、このプロシージャに含まれている基準を使用して、アクションを決定します。一致するものが見つかったときのデフォルトのアクションは、エラーをスキップして変更の適用を継続することです。ただし、プロシージャが指定された場合、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);
パラメータ
表92-25 SKIP_ERRORプロシージャのパラメータ
| パラメータ | 説明 |
|---|---|
|
|
SQL文のセットまたは特定のSQL文を識別するキーワード。(通常はデータベース・オブジェクトで定義される)キーワードを使用すると、指定オブジェクトで動作するすべてのSQL文が識別されるため、構成が簡単になります。表92-23に、キーワードおよびそれに対応するSQL文を示しますが、いずれもこのパラメータの値として有効です。 |
|
|
|
|
|
|
|
|
SQL適用でエラーが発生し、特定の文が
このプロシージャは、SQL適用に対して、次のいずれかを行うように指示するエラー・メッセージを戻します。
SQL適用に登録されたプロシージャではパラメータがまったく取得されません。
|
|
|
パターン・マッチングによって、ロジカル・スタンバイ・データベース上でスキップする表を区別することができます。 |
|
|
パターン・マッチングに使用できるエスケープ文字(文字"%"または"_"など)を識別します。パターン内の文字%または_の前にエスケープ文字があると、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
例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');
このプロシージャは、ロジカル・スタンバイ・データベースへのトランザクションの適用をスキップする(処理しない)方法を提供します。トランザクション識別情報を指定することによって、特定のトランザクションをスキップできます。
使用上の注意
特定のトランザクション(例: DDLトランザクション)が原因でSQL適用が停止した場合、そのトランザクションIDを指定して、適用を継続できます。このプロシージャは、SQL適用で処理しないトランザクションの数と同じ回数コールできます。
|
注意:
DMLの失敗をスキップするには、 |
このプロシージャを実行するには、DBA権限が必要です。
DBA_LOGSTDBY_SKIP_TRANSACTIONビューを使用すると、SQL適用でスキップされる予定のトランザクションが示されます。
『Oracle Database SQL言語リファレンス』のALTER DATABASE START LOGICAL STANDBY SKIP FAILED TRANSACTION文に関する項も参照してください。
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);
使用上の注意
|
注意: 表に対するDML変更をスキップし、その補足が行われていない場合、 |
このプロシージャを実行するには、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プロシージャは、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);
使用上の注意
このプロシージャを実行するには、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プロシージャは、実際にはいずれのルールとも一致しません。
