9.1 SQL Apply アーキテクチャの概要 アーキテクチャの概要 アーキテクチャの概要 アーキテクチャの概要
9.4.4 DDL 文のスキップ・ハンドラの設定 文のスキップ・ハンドラの設定 文のスキップ・ハンドラの設定 文のスキップ・ハンドラの設定
特定のDDL文をインターセプトして元のDDL文を別のDDL文で置き換えるプロシージャを 作成できます。たとえば、ロジカル・スタンバイ・データベース内のファイル・システムの編 成がプライマリ・データベースとは異なる場合、DBMS_LOGSTDBY.SKIPプロシージャを作成 し、ファイルを指定してDDLトランザクションを透過的に処理できます。
次のプロシージャでは、ファイル指定文字列に特定のネーミング規則を使用するかぎり、プラ イマリ・データベースとスタンバイ・データベース間で異なるファイル・システム編成を処理 できます。
1. 次のように、表領域のDDLトランザクションを処理するスキップ・プロシージャを作成し ます。
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;
ロジカル・スタンバイ・データベースのカスタマイズ
ロジカル・スタンバイ・データベースの管理 9-17 EXCEPTION
WHEN OTHERS THEN
ACTION := DBMS_LOGSTDBY.SKIP_ACTION_ERROR;
NEW_STMT := NULL;
END HANDLE_TBS_DDL;
2. SQL Applyを停止します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
3. スキップ・プロシージャをSQL Applyに登録します。
SQL> EXECUTE DBMS_LOGSTDBY.SKIP (stmt => 'TABLESPACE', proc_name => 'sys.handle_tbs_ddl');
4. SQL Applyを開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
9.4.5 ロジカル・スタンバイ・データベースの変更 ロジカル・スタンバイ・データベースの変更 ロジカル・スタンバイ・データベースの変更 ロジカル・スタンバイ・データベースの変更
デフォルトでは、ロジカル・スタンバイ・データベースはデータベース・ガードがALL（最も 限定的な設定）に設定されている状態で作動し、ユーザーはデータベースに対して変更を実行 できません。データベース・ガードを無視して、ロジカル・スタンバイ・データベースを変更 可能にするには、ALTER SESSION DISABLE GUARD文を実行します。権限を付与されている ユーザーは、この文を発行して、現行のセッションでデータベース・ガードをオフにできます。
次の各項で、例を示します。これらの例では、データベース・ガードがALLまたはSTANDBY に設定されていると仮定しています。
9.4.5.1 ロジカル・スタンバイ・データベースでの ロジカル・スタンバイ・データベースでの ロジカル・スタンバイ・データベースでの ロジカル・スタンバイ・データベースでの DDL の実行 の実行 の実行 の実行
この項では、SQL Applyを介してメンテナンスされている表に制約を追加する方法を説明しま す。
デフォルトでは、SYS権限を持つアカウントのみがデータベースを変更でき、データベース・
ガードはALLまたはSTANDBYに設定されています。SYSTEMまたは権限を付与されている別 のアカウントでログインした場合、最初はセッションに対するデータベース・ガードをバイパ スしていないので、ロジカル・スタンバイ・データベースではDDL文を発行できません。
次の例は、SQL Applyを停止し、データベース・ガードをバイパスしてロジカル・スタンバ イ・データベースでSQL文を実行した後、データベース・ガードを再び使用可能にする方法を 示しています。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.
SQL> ALTER SESSION DISABLE GUARD;
PL/SQL procedure successfully completed.
SQL> ALTER TABLE SCOTT.EMP ADD CONSTRAINT EMPID UNIQUE (EMPNO);
Table altered.
SQL> ALTER SESSION ENABLE GUARD;
PL/SQL procedure successfully completed.
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
Database altered.
オラクル社では、データベース・ガードのバイパスが使用可能になっている間は、SQL Apply により保守される表に対してDML操作を実行しないことをお薦めします。DML操作を実行す ると、プライマリ・データベースとスタンバイ・データベース間で違いが生じ、ロジカル・ス タンバイ・データベースをメンテナンスできないようになります。
ロジカル・スタンバイ・データベースのカスタマイズ
9.4.5.2 SQL Apply でメンテナンスされていない表の変更 でメンテナンスされていない表の変更 でメンテナンスされていない表の変更 でメンテナンスされていない表の変更
場合によっては、レポート生成アプリケーションが、要約した結果を収集してその結果を一時 的に格納したり、レポートが実行された回数を追跡する必要があります。アプリケーションの 主な目的はレポート・アクティビティを実行することですが、ロジカル・スタンバイ・データ ベースに対してDML（挿入、更新および削除）操作の発行が必要な場合があります。さらに、
アプリケーションで表の作成や削除が必要になることもあります。
データがSQL Applyを介してメンテナンスされていない場合は、レポート生成操作でデータを
変更できるように、データベース・ガードを設定できます。次の設定を行う必要があります。
■ DBMS_LOGSTDBY.SKIPプロシージャを実行して、アプリケーションによるデータの書込 みを可能にする、ロジカル・スタンバイ・データベース上の表のセットを指定します。ス キップされた表は、SQL Applyでメンテナンスされません。
■ スタンバイ表のみを保護するようにデータベース・ガードを設定します。
次の例では、レポートによって書込みが行われる表がプライマリ・データベース上にあると仮 定しています。
この例では、変更をロジカル・スタンバイ・データベースに適用できるように、SQL Applyを 停止し、表をスキップした後、SQL Applyを再開しています。この操作によって、レポート生 成アプリケーションは、MYSCHEMAのMYTABLES%に書込みができるようになります。スキッ プされた表は、SQL Applyでメンテナンスされません。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.
SQL> EXECUTE DBMS_LOGSTDBY.SKIP(stmt => schema_name => 'HR',
object_name => 'TESTEMP%');
PL/SQL procedure successfully completed.
SQL> EXECUTE DBMS_LOGSTDBY.SKIP('DML','HR','TESTEMP%');
PL/SQL procedure successfully completed.
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.
SQL Applyでは、開始後に、新しく指定されてスキップ・ルールに追加された表について、ス
タンバイ・データベースのメタデータを更新する必要があります。 SQL Applyによりメタデー タが更新される前に、新しくスキップされる表を変更しようとすると失敗します。追加したば
かりのSKIPルールがSQL Applyで正常に考慮されたかどうかは、次の問合せを発行すると確
認できます。
SQL> SELECT VALUE FROM DBA_LOGSDTBY_PARAMETERS WHERE NAME = 'GUARD_STANDBY';
VALUE
---Ready
VALUE列にReadyと表示される場合、SQL Applyではスキップされる表の関連メタデータが すべて正常に更新されており、その表を変更しても安全です。
関連項目関連項目
関連項目関連項目: C.6項「ロジカル・スタンバイ・データベースでサポートされる DDL文」および『Oracle Database PL/SQLパッケージ・プロシージャおよ びタイプ・リファレンス』のDBMS_LOGSTDBYパッケージに関する項
ロジカル・スタンバイ・データベースのカスタマイズ
ロジカル・スタンバイ・データベースの管理 9-19
9.4.6 ロジカル・スタンバイ・データベースでの表の追加または再作成 ロジカル・スタンバイ・データベースでの表の追加または再作成 ロジカル・スタンバイ・データベースでの表の追加または再作成 ロジカル・スタンバイ・データベースでの表の追加または再作成
通常、リカバリ不能な操作の後に表を再作成するには、表のインスタンス化を使用します。ま た、プロシージャを使用して、以前はスキップしていた表に対するSQL Applyを使用可能にす ることもできます。
表を作成する前に、4.1.2項「プライマリ・データベース内の表の行が一意に識別できることの 確認」に記載されている要件を満たす必要があります。その後、次の手順に従って表
HR.EMPLOYEESを再作成し、SQL Applyを再開できます。この手順は、プライマリ・データ ベースにアクセスするデータベース・リンクBOSTONが定義済であることを前提としています。
次のリストは、表を再作成し、その表に対してSQL Applyを再開する方法を示しています。
1. SQL Applyを停止します。
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
2. DBA_LOGSTDBY_SKIPビューを問い合せ、問題の表で操作がスキップされていないことを 確認します。
SQL> SELECT * FROM DBA_LOGSTDBY_SKIP;
ERROR STATEMENT_OPT OWNER NAME PROC ---- --- - ---N SCHEMA_DDL HR EMPLOYEES
N DML HR EMPLOYEES N SCHEMA_DDL OE TEST_ORDER N DML OE TEST_ORDER
ロジカル・スタンバイ・データベース上で再作成する表には、すでにスキップ・ルールが 関連付けられているため、最初にそのルールを削除する必要があります。そのためには、
DBMS_LOGSTDBY.UNSKIPプロシージャをコールします。次に例を示します。
SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'DML', schema_name => 'HR',
object_name => 'EMPLOYEES');
SQL> EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'SCHEMA_DDL', schema_name => 'HR',
object_name => 'EMPLOYEES');
3. DBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャを使用し、ロジカル・スタンバイ・
データベース内で全データを使用して表HR.EMPLOYEESを再作成します。次に例を示し ます。
SQL> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE(shema_name => 'HR', object+_name => 'EMPLOYEES',
dblink => 'BOSTON');
4. SQL Applyを開始します。
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
関連項目 関連項目 関連項目
関連項目: DBMS_LOGSTDBY.UNSKIPおよびDBMS_
LOGSTDBY.INSTANTIATE_TABLEプロシージャについては、『Oracle
Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレン
ス』を参照してください。
ロジカル・スタンバイ・データベースのコンテキストにおける特定のワークロードの管理
新規にインスタンス化された表とデータベースの残りの部分にまたがってビューの一貫性が得 られるように、SQL Applyがプライマリ・データベースと一致するまで待機してから、この表 を問い合せます。手順は次のとおりです。
1. プライマリ・データベースで、V$DATABASEビューを問い合せて現在のSCNを判別しま す。
SQL> SELECT CURRENT_SCN FROM V$DATABASE@BOSTON;
CURRENT_SCN
---345162788
2. 前の問合せで戻されたCURRENT_SCNより前のコミット済のトランザクションがすべて、
SQL Applyにより適用されていることを確認します。
SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS;
APPLIED_SCN
---345161345
この問合せで戻されたAPPLIED_SCNが最初の問合せで戻されたCURRENT_SCNよりも大 きい場合は、新規に再作成された表を問い合せても安全です。
9.5 ロジカル・スタンバイ・データベースのコンテキストにおける ロジカル・スタンバイ・データベースのコンテキストにおける ロジカル・スタンバイ・データベースのコンテキストにおける ロジカル・スタンバイ・データベースのコンテキストにおける 特定のワークロードの管理
特定のワークロードの管理 特定のワークロードの管理 特定のワークロードの管理
この項は、次の項目で構成されています。
■ プライマリ・データベースへのトランスポータブル表領域のインポート
■ マテリアライズド・ビューの使用
■ ロジカル・スタンバイ・データベースでのトリガーと制約の処理方法
■ OPEN RESETLOGS文を使用したリカバリ