C ロジカル・スタンバイ・データベースでサポートされるデータ型およびDDL

ロジカル・スタンバイ・データベースを設定する際、ロジカル・スタンバイ・データベースが、プライマリ・データベースのデータ型と表を保持できることを確認する必要があります。この付録では、様々なデータベース・オブジェクト、記憶域タイプおよびPL/SQLパッケージについて、ロジカル・スタンバイ・データベースでサポートされるものとサポートされないものを示します。この章は、次の項目で構成されています。

C.1 データ型に関する考慮事項

次の各項では、データベース・オブジェクトについて、サポートされるものとサポートされないものを示します。

C.1.1 ロジカル・スタンバイ・データベースでサポートされるデータ型

ロジカル・スタンバイ・データベースでは、次のデータ型がサポートされます。

BINARY_DOUBLE
BINARY_FLOAT
BLOB
CHAR
CLOBおよびNCLOB
DATE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
LONG
LONG RAW
NCHAR
NUMBER
NVARCHAR2
RAW
TIMESTAMP
TIMESTAMP WITH LOCAL TIMEZONE
TIMESTAMP WITH TIMEZONE
VARCHAR2およびVARCHAR
CLOBとして格納されるXMLType 注意 次のデータ型に対するSQL Applyサポートでは、プライマリ・データベースに対する互換性要件があります。 マルチバイトのCLOBサポート（10.1以上の互換性で動作するプライマリ・データベースが必要） LOBおよびオーバーフローなしのIOTサポート（10.1以上の互換性で動作するプライマリ・データベースが必要） LOBおよびオーバーフローありのIOTサポート（10.2以上の互換性で動作するプライマリ・データベースが必要） CLOBとして格納されるXMLType（11.1以上の互換性で動作するプライマリ・データベースが必要） TDEサポート（11.1以上の互換性で動作するプライマリ・データベースが必要）

C.1.2 ロジカル・スタンバイ・データベースでサポートされないデータ型

ロジカル・スタンバイ・データベースでは、次のデータ型がサポートされません。

BFILE
コレクション（VARRAYSおよびネストした表を含む）
マルチメディア・データ型（Spatial、ImageおよびOracle Textを含む）
ROWID、UROWID
ユーザー定義型
セキュア・ファイルとして格納されるLOB
オブジェクト・リレーショナルとして格納されるXMLType
バイナリXML

C.2 透過的データ暗号化（TDE）のサポート

Data Guard SQL Applyを使用すると、透過的データ暗号化（TDB）を有効に設定したプライマリ・データベースにデータ保護を提供できます。ロジカル・スタンバイ・データベースを使用し、高度なセキュリティ要件を伴うアプリケーションにデータ保護を提供する場合は、次のことを考慮してください。

サーバーが保持する鍵を使用する透過的データ暗号化が指定された表は、プライマリ・データベースとスタンバイ・データベースの両方が11.1以上の互換性レベルで稼働している場合のロジカル・スタンバイ・データベースの下でサポートされます。
ハードウェア・セキュリティ・モジュールの下での透過的データ暗号化は、11gリリース1のロジカル・スタンバイ・データベースの下ではサポートされません。

ロジカル・スタンバイ・データベースの下では、暗号化された列が含まれる表をレプリケートするときに、次の制限事項を考慮する必要があります。

暗号化されたREDOレコードを変換するには、透過的データ暗号化鍵を含むオープン・ウォレットへのアクセス権がSQL Applyに必要です。そのため、鍵を含むウォレットの作成後に、そのウォレットをプライマリ・データベースからスタンバイ・データベースにコピーする必要があります。
ウォレットは、マスター鍵が変更されるたびに、プライマリ・データベースからロジカル・スタンバイ・データベースにコピーする必要があります。
ロジカル・スタンバイ・データベースでは、プライマリ・データベースから暗号化された表をレプリケートしている間、マスター鍵をREKEY（鍵の変更）しないことをお薦めします。これは、暗号化されたREDOレコードの検出時にSQL Applyが停止する原因になります。
ロジカル・スタンバイ・データベースでは、レプリケートされた表の暗号化鍵をREKEYできます。このためには、REKEYコマンドを発行する前にガード設定をNONEにして低くする必要があります。
レプリケートされた暗号化された表では、プライマリ・データベースで使用された暗号化方式とは異なる方式を列に対して使用できます。たとえば、HR.EMPLOYEES表のSALARY列がプライマリ・データベースでAES102暗号化アルゴリズムを使用して暗号化される場合、ロジカル・スタンバイではAES256暗号化アルゴリズムを使用して暗号化することができます。あるいは、ロジカル・スタンバイ・データベースでは、SALARY列を暗号化しないままにしておくことも可能です。

C.3 表領域の暗号化のサポート

Data Guard SQL Applyを使用すると、表領域の暗号化を有効に設定したプライマリ・データベースにデータ保護を提供できます。その場合、C.2項「透過的データ暗号化（TDE）のサポート」に示した制限事項1、2および3が適用されます。

注意
暗号化された表領域の表に対する変更に、SQL ApplyがREDOレコードをマイニングおよび適用した際、暗号化されていない形式のユーザー・データのレコードが長時間維持される場合があります。これを許容できない場合、次のコマンドを発行して、暗号化された表領域へのSQL Applyのコンポーネントのマイニングに関係するすべてのメタデータ表を移動します。
SQL> DBMS_LOGMNR_D.SET_TABLESPACE(NEW_TABLESPACE =>
'ENCRYPTED_LOGMNR_TS');

C.4 行レベル・セキュリティおよびファイングレイン監査のサポート

Oracle Database 11g現在、ロジカル・スタンバイでは、DBMS_RLSおよびDBMS_FGA PL/SQLパッケージによって提供されるセキュリティ環境を自動的にレプリケートできます。このサポートにより、セキュリティ環境は透過的に維持されるため、サーバーがスタンバイにフェイルオーバーした場合のセキュリティに関する考慮事項が簡単に管理できるようになります。また、プライマリ・データに適用されるアクセス制御ポリシーをスタンバイに自動転送できるため、スタンバイ・データに同じレベルの保護を透過的に提供できます。11gを使用してスタンバイ・サーバーを新規作成する場合、このレプリケーションはデフォルトで有効に設定されます。それ以外の場合は、適宜DBAが有効に設定する必要があります。

これらのPL/SQLパッケージのレプリケーションをサポートするには、プライマリとスタンバイの両方が11.1以上の互換性設定で稼働している必要があります。

また、参照される表は、ロジカル・スタンバイよって保持されるオブジェクトである必要があります。（たとえば、ROWID列を含む表のデータがロジカル・スタンバイによって保持されない場合、その表を参照するDBMS_RLSおよびDBMS_FGAコールも保持されません。）

C.4.1 行レベルのセキュリティ

行レベルのセキュリティは、仮想プライベート・データベース（VPD）とも呼ばれるセキュリティ機能です。この機能を使用すると、表、ビューまたはシノニムに対して直接、セキュリティの粒度をFINEレベルにまで強化できます。VDPポリシーで保護された表、ビューまたはシノニムに直接または間接的にユーザーがアクセスすると、サーバーはそのユーザーのSQL文を動的に変更します。この変更では、セキュリティ・ポリシーを実装するファクンションによって戻されるWHERE条件（述語）が作成されます。文は、ファンクションで表される条件あるいはファンクションによって戻される条件を使用して、ユーザーに対して透過的に、動的に変更されます。VPDポリシーは、SELECT、INSERT、UPDATE、INDEXおよびDELETE文に適用されます。VPDは、DBMS_RLSパッケージを使用してセキュリティ・ポリシーを適用すると実装されます。

DBMS_RLSプロシージャをプライマリで実行すると、追加情報がREDOに取得されるため、スタンバイでプロシージャ・コールを論理的に再構築して実行することができます。ロジカル・スタンバイでは、VPDの補助オブジェクト（コンテキスト、データベース・ログオン、トリガー、サポート対象パッケージなど）をレプリケートできます。これらのオブジェクトが保持されるスキーマに存在し、レプリケーションを停止させるDDLスキップが構成されていないことを確認する必要があります。

C.4.2 ファイングレイン監査

ファイングレイン監査は、SELECT文を監査する方法です。DBMS_FGAパッケージを使用すると、表にアクセスするすべてのSELECT文をアクセスされたデータとともに取得できます。FGAポリシーは、特定の列に適用できます。あるいは、指定した述語がTRUEを戻す行を返すSELECT文に限定しても適用できます。

DBMS_FGAプロシージャをプライマリで実行すると、追加情報がREDOに取得されるため、スタンバイでプロシージャ・コールを論理的に再構築して実行することができます。

C.4.3 PL/SQLレプリケーションのスキップおよび有効化

PL/SQLは、DDL文そのものとしてskipおよびskip_errorルールを指定して構成できます。ただし、パッケージおよびプロシージャに対してワイルドカードは使用できません。たとえば、VPDを全面的にスキップするには、次のようにします。

DBMS_LOGSTDBY.Skip (
stmt => 'PL/SQL',
schema_name => 'SYS',
object_name =>'DBMS_RLS',
use_like => FALSE);

指定されたスキーマが、パッケージが定義されているスキーマであることに注意してください。パッケージの個々のプロシージャをスキップする場合の構文は、次のようになります。

DBMS_LOGSTDBY.Skip (
stmt => 'PL/SQL',
schema_name => 'SYS',
object_name =>'DBMS_RLS.Add_Policy',
use_like => FALSE);

特定のスキーマまたは表についてVPDをスキップするには、スキップ・プロシージャを使用する必要があります。スキップ・プロシージャに、実行予定の完全修飾されたPL/SQL文を渡します。次に例を示します。

DBMS_RLS.Drop_Policy(
object_schema => 'SCOTT, 
object_name  => 'EMP',
policy_name => 'MYPOLICY');

すると、プロシージャは、文を解析してスキップするか、適用するか、適用を中止してDBAに補正アクションを実行させるかを決定します。

DDLとは異なり、PL/SQLに対するスキップ・プロシージャは代用文を戻しません。

C.5 Oracle Label Security

ロジカル・スタンバイ・データベースでは、Oracle Label Securityをサポートしません。Oracle Label Securityをプライマリ・データベースにインストールすると、開始時に内部エラーが発生してSQL Applyはロジカル・スタンバイ・データベースで失敗します。

C.6 サポートされる表記憶域タイプ

ロジカル・スタンバイ・データベースでは、次の表記憶域タイプがサポートされます。

クラスタ表（索引クラスタおよびヒープ・クラスタを含む）
索引構成表（オーバーフロー・セグメントを含むパーティション化および非パーティション化）
ヒープ構成表（パーティション化および非パーティション化）

C.7 サポートされない表記憶域タイプ

ロジカル・スタンバイ・データベースでは、次の表記憶域タイプがサポートされません。

セグメント圧縮が有効に設定されて格納される表
セキュア・ファイルとして格納されるLOB列を含む表
仮想列を含む表

C.8 PL/SQLパッケージに関する考慮事項

この項では、PL/SQLパッケージに関する次の考慮事項について説明します。

ロジカル・スタンバイでのXMLおよびXDB PL/SQLパッケージの処理

関連項目
オラクル社が提供するPL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

C.8.1 サポートされるPL/SQLパッケージ

システムのメタデータやユーザー・データを変更しない、オラクル社が提供するPL/SQLパッケージは、アーカイブREDOログ・ファイルにフットプリントを残さないため、プライマリ・データベースで安全に使用できます。この種のパッケージの例には、DBMS_OUTPUT、DBMS_RANDOM、DBMS_PIPE、DBMS_DESCRIBE、DBMS_OBFUSCATION_TOOLKIT、DBMS_TRACE、DBMS_METADATA、DBMS_CRYPTOがあります。

システムのメタデータは変更せず、ユーザー・データを変更することがある、オラクル社が提供するPL/SQLパッケージは、変更されるデータがC.1.1項に示すサポートされるデータ型に属するかぎり、SQL Applyでサポートされます。この種のパッケージの例には、DBMS_LOB、DBMS_SQL、DBMS_TRANSACTIONがあります。

Data Guardのロジカル・スタンバイでは、DBMS_RLSとDBMS_FGAの2つのパッケージを使用して実行されるアクションのレプリケーションがサポートされます。

C.8.2 サポートされないPL/SQLパッケージ

システムのメタデータを変更する、オラクル社が提供するPL/SQLパッケージは、通常、SQL Applyではサポートされないため、その影響はロジカル・スタンバイ・データベースでは参照できません。この種のパッケージの例には、DBMS_JAVA、DBMS_REGISTRY、DBMS_ALERT、DBMS_SPACE_ADMIN、DBMS_REFRESH、DBMS_REDEFINITION、DBMS_AQがあります。

DBMS_JOBに固有のサポートが用意されています。ジョブの実行はロジカル・スタンバイ・データベース上で一時停止され、スタンバイ・データベース上ではジョブを直接スケジュールできません。ただし、プライマリ・データベースで発行されたジョブは、スタンバイ・データベースにレプリケートされます。スイッチオーバーまたはフェイルオーバーが発生すると、元のプライマリ・データベースでスケジュールされていたジョブの実行は、新規のプライマリ・データベースで自動的に開始されます。

DBMS_SCHEDULERに固有のサポートが用意されているため、スタンバイ・データベースでジョブを実行できます。11gでは、database_roleというスケジューラ・ジョブの新しい属性が作成されています。この属性の内容は、V$DATABASEのdatabase_role属性と同じです。スケジューラ・ジョブが作成されると、デフォルトでローカル・ロールに設定されます（すなわち、スタンバイで作成されたジョブはデフォルトでLOGICAL STANDBYのdatabase_roleに設定されます）。ジョブ・スケジューラは、現行ロールに固有のジョブのみを実行します。スイッチオーバーまたはフェイルオーバーでは、スケジューラは、新しいロールに固有のジョブを実行するように自動的に切り替ります。

スケジューラ・ジョブはスタンバイにレプリケートされません。しかし、既存のジョブはDBMS_SCHEDULER.Set_Attributeプロシージャを使用して、新しいロールの下でアクティブ化できます。あるいは、両方のロールで実行する必要があるジョブをクローニングし、コピーを他のロールに固有のものにすることが可能です。DBA_SCHEDULER_JOB_ROLESビューには、どのジョブがどのロールに固有かが表示されます。

スケジューラ・ジョブは、ロジカル・スタンバイ・データベースで実行される場合、データベース・ガードに準拠します。そのため、メンテナンスされていない表を変更する必要があるジョブを実行するには、データベース・ガードをSTANDBYに設定する必要があります。（ALTER SESSION DISABLE GUARD文をPL/SQLブロック内で使用して有効にすることはできません。）

関連項目
特定のパッケージの詳細は、『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。

C.8.3 ロジカル・スタンバイでのXMLおよびXDB PL/SQLパッケージの処理

Oracle Database 11gリリース1（11.1）では、XMLがCLOB形式で格納される場合は、ロジカル・スタンバイでXMLをサポートします。しかし、完全にはサポートされないXMLとともに使用されるPL/SQLパッケージがいくつかあります。

ロジカル・スタンバイでサポートされるPL/SQLパッケージおよびプロシージャは、メモリー内構造のみを変更します。データベースに格納されたデータは変更しません。これらのパッケージは、REDOを生成しないため、ロジカル・スタンバイにはレプリケートされません。

ロジカル・スタンバイでサポートされなくても、レプリケーション・アクティビティの続行にロジカル・スタンバイ・データベースで対応する起動が必要なXMLおよびXDBに関連する特定のPL/SQLパッケージおよびプロシージャは、プライマリ・データベースでこれらのプロシージャが起動することにより、プロシージャの起動を示す追加のREDOレコードが生成されるように装備されています。SQL ApplyでこのようなREDOレコードが検出されると、SQL Applyは停止し、プロシージャ名を示すエラー・メッセージがDBA_LOGSTDBY_EVENTS表に書き込まれます。これにより、DBAは対応するプロシージャを適切な時期にロジカル・スタンバイ・データベースで起動し、プライマリ・データベースで生成された後続のREDOレコードをロジカル・スタンバイ・データベースに正常に適用することができます。これらのサポートされないプロシージャの処理の詳細は、C.8.3.1項～C.8.3.6項を参照してください。

次のパッケージには、サポートされないプロシージャが含まれます。

DBMS_XMLSCHEMA
DBMS_XMLINDEX

これらのパッケージに加えて、ロジカル・スタンバイではXDBスキーマへの変更もサポートしません。XDBスキーマ内のオブジェクトは、システム・メタデータとみなされ、直接の変更はレプリケートされません。

Oracle XML DBリポジトリで管理される表は、階層対応表とも呼ばれますが、ロジカル・スタンバイではサポートされません。これらの表は、XMLデータの格納に使用され、通常のSQLアクセスに加えてFTPおよびHTTPプロトコルを使用してアクセスできます。これらの表の詳細は、『Oracle XML DB開発者ガイド』を参照してください。

C.8.3.1 DBMS_XMLSCHEMAスキーマ

DBMS_XMLSCHEMAパッケージ内の次のプロシージャは、ロジカル・スタンバイではサポートされず、レプリケートできません。ロジカル・スタンバイは、これらのプロシージャへのコールを検出すると、これらのコールに対してユーザーが補正アクションを実行できるように停止します。次のサポートされないプロシージャの処理に使用できる代替方法の詳細は、C.8.3.3項～C.8.3.6項を参照してください。

REGISTERSCHEMA
REGISTERURI
DELETESCHEMA
PURGESCHEMA
COPYEVOLVE
INPLACEEVOLVE
COMPILESCHEMA

XDBスキーマは、Oracle管理スキーマです。このスキーマに対する変更は、ロジカル・スタンバイによって自動的にスキップされます。次のプロシージャは、XDBスキーマを変更しますが、レプリケートされません。

GENERATEBEAN

次のプロシージャおよびファンクションは、REDOを生成しないため、ロジカル・スタンバイは停止しません。

GENERATESCHEMAS
GENERATESCHEMA

C.8.3.2 DBMS_XMLINDEXパッケージ

DBMS_XMLINDEXパッケージ内のSYNCINDEXプロシージャは、ロジカル・スタンバイではサポートされず、レプリケートできません。ロジカル・スタンバイは、このプロシージャへのコールを検出すると停止します。

次のファンクションおよびプロシージャは、REDOを生成しないため、ロジカル・スタンバイは停止しません。

NODEREFGETREF
NODEREFGETVALUE
NODEREFGETPARENTREF
NODEREFGETNAME
NODEREFGETNAMESPACE

C.8.3.3 サポートされないPL/SQLプロシージャの処理

サポートされないPL/SQLプロシージャの処理には、2つのオプションがあります。1つ目のオプションは、ロジカル・スタンバイの適用プロセスが停止してなんらかの補正アクションを手動で実行できるようにする方法です。2つ目のオプションは、事前対応アクションを実行し、さらにロジカル・スタンバイのスキップ・プロシージャを使用してサポートされないPL/SQLをスキップする方法です。次の各項で、これらのオプションについてそれぞれ説明します。

C.8.3.4 サポートされないPL/SQLの手動による補正

ロジカル・スタンバイでサポートされないものが検出されると、適用プロセスは停止し、エラーがDBA_LOGSTBDY_EVENTS表に記録されます。この表を問い合せると、スタンバイが停止した原因となるアクションと、該当する場合は補正のために必要なアクションを確認できます。

次の例に、問合せ内容のサンプルとその出力を示します。

select status, event from dba_logstdby_events
          where commit_scn >= (select applied_scn from dba_logstdby_progress) and
          status_code = 16265
          order by commit_scn desc;
 
STATUS
--------------------------------------------------------------------------------
EVENT
--------------------------------------------------------------------------------
ORA-16265: Unsupported PL/SQL procedure encountered
begin
 "XDB"."DBMS_XMLSCHEMA"."REGISTERSCHEMA" (
   "SCHEMAURL" => 'xmlplsqlsch2
 
ORA-16265: Unsupported PL/SQL procedure encountered
begin
 "XDB"."DBMS_XMLSCHEMA"."REGISTERSCHEMA" (
   "SCHEMAURL" => 'xmlplsqlsch2
 
 
2 rows selected.

同じ情報で2行が戻されます。これは、ロジカル・スタンバイが失敗したトランザクションを自動的に再試行するためです。この結果は、xmlplsqlsch2スキーマについてDBMS_XMLSCHEMA.REGISTERSCHEMAへのコールが検出されたときに、スタンバイが停止したことを示しています。この情報を使用して必要なファイルをプライマリから転送し、スタンバイでこのスキーマを登録します。

スタンバイでこのスキーマが正常に登録されると、ロジカル・スタンバイで適用プロセスを再開できます。これは、SKIP FAILED TRANSACTION オプションを使用して実行する必要があります。次に例を示します。

alter database start logical standby apply skip failed transaction'

ロジカル・スタンバイは、問題となるトランザクションをスキップし、プライマリからのREDOの適用を続行します。

サポートされないPL/SQLを手動でレプリケートするための一般的な手順は、次のとおりです。

サポートされないPL/SQLをプライマリ・データベースで実行します。
スタンバイ・データベースでサポートされないPL/SQLが検出され、適用が停止します。
DBA_LOGSTBDY_EVENTS表を調べ、適用が停止した原因を確認します。
スタンバイで、サポートされないPL/SQLについてなんらかの補正アクションを実行します。
スタンバイで適用を再開します。

C.8.3.5 サポートされないPL/SQLの事前対応的な補正

プライマリ・データベースで実行する予定のアクションが、スタンバイの停止原因となることがわかっている場合があります。その場合、事前にアクションを実行してスタンバイがREDOを適用していない時間を最小限に抑えるか、なくなるようにすることが可能です。

たとえば、新しいアプリケーションがインストールされる予定であることがわかっているとします。インストールの一貫として、大量のXMLスキーマを登録する必要があります。スタンバイでこれらのスキーマを登録した後に、プライマリで登録することができます。また、スタンバイでDBMS_XMLSCHEMA.REGISTERSCHEMAプロシージャ用にスキップ・プロシージャをインストールすることもできます。このプロシージャは、XMLスキーマが登録されているかどうかチェックし、登録されている場合はロジカル・スタンバイにそのPL/SQLコールをスキップするように指示します。

この方法は、他のサポートされていないPL/SQLプロシージャの一部にも使用できます。たとえば、DBMS_XMLSCHEMA.DELETESCHEMAは、同様の方法で処理できます。スタンバイにスキーマがインストールされているかどうかを確認し、インストールされていない場合は、スタンバイには大きな影響がまったくないので、そのPL/SQLが安全にスキップされるように、スキップ・プロシージャを作成できます。

C.8.3.6 順序に依存するサポートされないPL/SQLの補正

前述の方法は役に立ちますが、どんな場合にも使用できるわけではありません。安全に使用できるのは、PL/SQLが実行される時期が他のトランザクションに対して重要ではない場合に限られます。この方法を使用してはいけない事例の1つは、DBMS_XMLSCHEMA.copyEvolveです。

このプロシージャは、スキーマを発展（変更）させ、列を追加または削除（あるいはその両方）して表を変更できます。また、XML文書が有効か無効かを変更することもできます。ロジカル・スタンバイでこのプロシージャを実行する時期は重要です。安全が保証される唯一の時期は、ロジカル・スタンバイで、このプロシージャがプライマリ・データベースで実行されたことを認識し、適用が停止しているときです。

スキーマを発展させる前に、プライマリでそのスキーマを使用するトラフィックをすべてQUIESCE（静止）させることも重要です。そうしないと、2つのトランザクション間の依存性がロジカル・スタンバイには識別できないため、プライマリではevolveSchemaに間に合うようにクローズされるトランザクションが、ロジカル・スタンバイでは異なる順序で実行される可能性があります。そのため、順序に依存するPL/SQLが含まれる場合は、次の手順に従う必要があります。

プライマリで依存表への変更をQUIESCEさせます。
プライマリでCopyEvolveを実行します。
スタンバイでのCopyEvolve PL/SQLの停止を待機します。
スタンバイで補正CopyEvolveを適用します。
スタンバイで適用を再開します。

例C-1に、RegisterSchemaコールの処理方法を決定するために使用されるプロシージャのサンプルを示します。

例C-1 RegisterSchema用のPL/SQLスキップ・プロシージャ

-- Procedures to determine how to handle registerSchema calls
 
-- This procedure extracts the schema URL, or name, from the statement
-- string that is passed into the skip procedure.
 
Create or replace procedure sec_mgr.parse_schema_str(
  statement             in varchar2,
  schema_name      out varchar2)
Is
  pos1 number;
  pos2 number;
  workingstr   varchar2(32767);
Begin
 
-- Find the correct argument
pos1 := instr(statement, '"SCHEMAURL" => ''');
workingstr := substr(statement, pos1 + 16);
 
-- Find the end of the schema name
pos1 := instr(workingstr, '''');
 
-- Get just the schema name
workingstr := substr(workingstr, 1, pos1 - 1);
 
schema_name := workingstr;
 
End parse_schema_str;
/
show errors
 
 
-- This procedure checks if a schema is already registered. If so,
-- it returns the value DBMS_LOGSTDBY.SKIP_ACTION_SKIP to indicate that
-- the PL/SQL should be skipped. Otherwise, the value 
-- DBMS_LOGSTDBY.SKIP_ACTION_SKIP is returned and Logical Standby apply 
-- will halt to allow the DBA to deal with the registerSchema call.
 
Create or replace procedure sec_mgr.skip_registerschema(
  statement          in varchar2,
  package_owner            in varchar2,
  package_name             in varchar2,
  procedure_name          in varchar2,
  current_user              in varchar2,
  xidusn             in number,
  xidslt               in number,
  xidsqn             in number, 
  exit_status           in number, 
  skip_action      out number)
Is
  schema_exists number;
  schemastr varchar2(2000);
Begin
 
  skip_action := DBMS_LOGSTDBY.SKIP_ACTION_SKIP;
 
  -- get the schame name from statement
  parse_schema_str(statement, schemastr);
 
  -- see if the schema is already registered
  select count(*) into schema_exists from sys.all_xml_schemas s 
                                     where s.schema_url = schemastr and
                                           s.owner = current_user;
 
  IF schema_exists = 0 THEN
      -- if the schema is not  registered, then we must stop apply
      skip_action := DBMS_LOGSTDBY.SKIP_ACTION_APPLY;     
  ELSE
      -- if the schema is already registered, then we can skip this statement
      skip_action := DBMS_LOGSTDBY.SKIP_ACTION_SKIP;     
  END IF;
 
End skip_registerschema;
/
show errors
 
-- Register the skip procedure to deal with the unsupported registerSchema 
-- PL/SQL.
Begin
   sys.dbms_logstdby.skip(stmt => 'PL/SQL', 
        schema_name => 'XDB', 
                object_name   => 'DBMS_XMLSCHEMA.REGISTERSCHEMA', 
                          proc_name     => 'SEC_MGR.SKIP_REGISTERSCHEMA',
        use_like         => FALSE );
                  End;
    /
show errors

C.9 サポートされない表

ロジカル・スタンバイ・データベースを作成する前に、プライマリ・データベースでサポートされないデータベース・オブジェクトを識別することが重要です。これは、プライマリ・データベースでサポートされないデータ型および表に対して行われた変更が、ロジカル・スタンバイ・データベースではSQL Applyによって自動的にスキップされるためです。さらに、エラー・メッセージは戻されません。

ロジカル・スタンバイのサポートの観点から、データベースには次の3種類のオブジェクトがあります。

SQL Applyによって明示的にメンテナンスされるオブジェクト
SQL Applyによって暗黙的にメンテナンスされるオブジェクト
SQL Applyによってメンテナンスされないオブジェクト

Oracleデータベースに同梱される一部のスキーマ（SYSTEMなど）には、SQL Applyによって暗黙的にメンテナンスされるオブジェクトが含まれます。しかし、ユーザー定義の表をSYSTEMに入れると、サポートされるデータ型の列が含まれている場合でもその表はメンテナンスされません。SQL Applyによってメンテナンスされないオブジェクトを検出するには、次の2つの問合せを実行する必要があります。1つ目の問合せは次のとおりです。

SQL> SELECT OWNER FROM DBA_LOGSTDBY_SKIP WHERE STATEMENT_OPT = 'INTERNAL SCHEMA';

この問合せは、内部スキーマとみなされるスキーマをすべて戻します。これらのスキーマにあるユーザー表は、ロジカル・スタンバイ・データベースでレプリケートされず、DBA_LOGSTDBY_UNSUPPORTEDビューにも表示されません。スキーマに実装された機能がロジカル・スタンバイの下でサポートされる場合、オラクル社で作成されたこれらのスキーマ内の表は、ロジカル・スタンバイで保持されます。

実行する必要がある2つ目の問合せは次のとおりです。この問合せは、内部スキーマに属さず、サポートされないデータ型が含まれるためにSQL Applyによってメンテナンスされない表を戻します。

SQL> SELECT DISTINCT OWNER,TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED 
  2> ORDER BY OWNER,TABLE_NAME;

OWNER        TABLE_NAME
-----------  --------------------------
HR           COUNTRIES
OE           ORDERS
OE           CUSTOMERS
OE           WAREHOUSES

前述の問合せでリストされたいずれかの表の列名とデータ型を表示するには、次のようなSELECT文を使用します。

SQL> SELECT COLUMN_NAME,DATA_TYPE FROM DBA_LOGSTDBY_UNSUPPORTED
  2> WHERE OWNER='OE' AND TABLE_NAME = 'CUSTOMERS';

COLUMN_NAME                      DATA_TYPE
-------------------------------  -------------------
CUST_ADDRESS                     CUST_ADDRESS_TYP
PHONE_NUMBERS                    PHONE_LIST_TYP
CUST_GEO_LOCATION                SDO_GEOMETRY

プライマリ・データベースにサポートされない表が含まれている場合、REDOデータをロジカル・スタンバイ・データベースに適用すると、SQL Applyサービスによって、その表が自動的に除外されます。

注意
プライマリ・データベースの重要な表がロジカル・スタンバイ・データベースでサポートされない場合は、フィジカル・スタンバイ・データベースの使用を考慮することもできます。フィジカル・スタンバイ・データベースには、このようなデータ型の制約はありません。

C.10 ロジカル・スタンバイ・データベースでスキップされるSQL文

デフォルトでは、次のSQL文がSQL Applyにより自動的にスキップされます。

ALTER DATABASE
ALTER MATERIALIZED VIEW
ALTER MATERIALIZED VIEW LOG
ALTER SESSION
ALTER SYSTEM
CREATE CONTROL FILE
CREATE DATABASE
CREATE DATABASE LINK
CREATE PFILE FROM SPFILE
CREATE MATERIALIZED VIEW
CREATE MATERIALIZED VIEW LOG
CREATE SCHEMA AUTHORIZATION
CREATE SPFILE FROM PFILE
DROP DATABASE LINK
DROP MATERIALIZED VIEW
DROP MATERIALIZED VIEW LOG
EXPLAIN
LOCK TABLE
SET CONSTRAINTS
SET ROLE
SET TRANSACTION

プライマリ・データベースで実行されるこの他のSQL文はすべて、ロジカル・スタンバイ・データベースに適用されます。

C.11 ロジカル・スタンバイ・データベースでサポートされるDDL文

表C-1に、DBMS_LOGSTDBY.SKIPプロシージャのstmtパラメータについて、サポートされる値を示します。表の左側の列には、キーワードの右側にあるSQL文セットの識別に使用される可能性のあるキーワードを示します。キーワードは、通常、データベース・オブジェクトによって定義されます。

関連項目
DBMS_LOGSTDBYパッケージの詳細は『Oracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンス』を参照してください。また、10.5.3項「DDL文のスキップ・ハンドラの設定」も参照してください。

表C-1 DBMS_LOGSTDBY.SKIPプロシージャのstmtパラメータの値

キーワード	関連するSQL文
このグループのSQL文に対するキーワードはない。	GRANT OBJECT REVOKE OBJECT SYSTEM GRANT SYSTEM REVOKE
`CLUSTER`	`AUDIT CLUSTER` `CREATE CLUSTER` `DROP CLUSTER` `TRUNCATE CLUSTER`
`CONTEXT`	`CREATE CONTEXT` `DROP CONTEXT`
`DATABASE LINK`	`CREATE DATABASE LINK` `CREATE PUBLIC DATABASE LINK` `DROP DATABASE LINK` `DROP PUBLIC DATABASE LINK`
`DIMENSION`	`ALTER DIMENSION` `CREATE DIMENSION` `DROP DIMENSION`
`DIRECTORY`	`CREATE DIRECTORY` `DROP DIRECTORY`
`DML`	表内のDML文を含む（例: `INSERT`、`UPDATE`、`DELETE`）
`INDEX`	`ALTER INDEX` `CREATE INDEX` `DROP INDEX`
`NON_SCHEMA_DDL`	特定のスキーマに関連付けられていないすべてのDDL 注意: `SCHEMA_NAME`および`OBJECT_NAME`はNULLである必要があります。
`PROCEDURE`¹	`ALTER FUNCTION` `ALTER PACKAGE` `ALTER PACKAGE BODY` `ALTER PROCEDURE` `CREATE FUNCTION` `CREATE LIBRARY` `CREATE PACKAGE` `CREATE PACKAGE BODY` `CREATE PROCEDURE` `DROP FUNCTION` `DROP LIBRARY` `DROP PACKAGE` `DROP PACKAGE BODY` `DROP PROCEDURE`
`PROFILE`	`ALTER PROFILE` `CREATE PROFILE` `DROP PROFILE`
`PUBLIC DATABASE LINK`	`CREATE PUBLIC DATABASE LINK` `DROP PUBLIC DATABASE LINK`
`PUBLIC SYNONYM`	`CREATE PUBLIC SYNONYM` `DROP PUBLIC SYNONYM`
`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` `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`

¹ Javaスキーマ・オブジェクト（ソース、クラス、リソース）は、SQL文をスキップ（無視）するためのプロシージャと同等とみなされます。

C.11.1 DBLINKを使用するDDL文

SQL Applyは、データベース・リンクを参照する次のようなDDL文を正しく適用できない場合があります。

CREATE TABLE tablename AS SELECT * FROM bar@dblink

これは、ロジカル・スタンバイ・データベースでdblinkがプライマリ・データベースと同じデータベースを指さないことがあるためです。このようなDDL文の実行中にSQL Applyに障害が発生した場合は、表の作成にDBMS_LOGSTDBY.INSTANTIATE_TABLEプロシージャを使用して、SQL APPLYの操作を再開する必要があります。

C.11.2 ロジカル・スタンバイ・プロセス上のAUD$およびFGA_LOG$のレプリケーション

ロジカル・スタンバイでは、監査およびファイングレイン監査がサポートされています。プライマリ・データベースでのAUD$およびFGA_AUD$表に対する変更は、ロジカル・スタンバイでレプリケートされます。

AUD$表およびFGA_AUD$表の両方に、DBID列があります。DBID値がプライマリ・データベースの値の場合、その行は、プライマリでのアクティビティに基づいてロジカル・スタンバイにレプリケートされています。DBID値がロジカル・スタンバイ・データベースの値の場合、その行は、ロジカル・スタンバイのローカル・アクティビティの結果として挿入されています。

ロジカル・スタンバイ・データベースで、プライマリ・ロールをロールの推移（スイッチオーバーまたはフェイルオーバー）の結果とみなした後、新しいプライマリ（元のロジカル・スタンバイ）および新しいロジカル・スタンバイ（元のプライマリ）のAUD$表およびFGA_AUD$表は、必ず同期されるとはかぎりません。このため、新しいプライマリ・データベースのAUD$表またはFGA_AUD$表のすべての行が、新しいロジカル・スタンバイ・データベースに存在するとはかぎりません。ただし、データベースがプライマリ・ロールの際に挿入されたAUD$およびFGA_LOG$のすべての行はレプリケートされ、ロジカル・スタンバイ・データベースに存在します。