ロジカル・スタンバイ・データベースの設定では、ロジカル・スタンバイ・データベースがプライマリ・データベースのデータ型と表を維持していることを確認する必要があります。この付録では、ロジカル・スタンバイ・データベースのサポート対象および対象外の各種データベース・オブジェクト、ストレージ・タイプ、PL/SQL供給パッケージをリストにまとめています。この付録には、次の項があります。
次の各項では、データベース・オブジェクトについて、サポートされるものとサポートされないものを示します。
ロジカル・スタンバイ・データベースでは、次のデータ型がサポートされます。
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 TIMEZONE
TIMESTAMP WITH LOCAL TIMEZONE
VARCHAR
およびVARCHAR2
SecureFileとして格納されるLOBには、11.2以上の互換性で動作するプライマリ・データベースが必要です。C.14項「SecureFile LOBのサポート」を参照してください。
次のプライマリ・データベース互換性要件を仮定した場合は、すべてのストレージ・モデルのXMLType
データ。
CLOB
形式で格納されるXMLType
には、11.1以上の互換性で動作するプライマリ・データベースが必要です。
オブジェクト・リレーショナル形式またはバイナリXMLで格納されるXMLType
には、11.2.0.3以上のREDO互換性が設定されたOracle Database 11gリリース2(11.2.0.3)以上でプライマリ・データベースを実行している必要があります。
次に対するSQL Applyサポートでは、プライマリ・データベースに対する互換性要件があります。
マルチバイトのCLOB
サポートには、10.1以上の互換性で動作するプライマリ・データベースが必要です。
LOB
およびオーバーフローなしのIOTサポートには、10.1以上の互換性で動作するプライマリ・データベースが必要です。
LOB
およびオーバーフローありのIOTサポートには、10.2以上の互換性で動作するプライマリ・データベースが必要です。
TDEサポートには、11.1以上の互換性で動作するプライマリ・データベースが必要です。
セグメント圧縮には、11.1以上の互換性で動作するプライマリ・データベースが必要です。
ハイブリッド列圧縮サポートは、基礎となるストレージ・システムに依存します。
関連項目:
|
Data Guard SQL Applyを使用すると、透過的データ暗号化(TDE)を有効に設定したプライマリ・データベースにデータ保護を提供できます。ロジカル・スタンバイ・データベースを使用し、高度なセキュリティ要件を伴うアプリケーションにデータ保護を提供する場合は、次のことを考慮してください。
サーバーが保持する鍵を使用する透過的データ暗号化が指定された表は、プライマリ・データベースとスタンバイ・データベースの両方が11.1以上の互換性レベルで稼働している場合のロジカル・スタンバイ・データベースで複製されます。
ハードウェア・セキュリティ・モジュールの下での透過的データ暗号化は、11gリリース1のロジカル・スタンバイ・データベースではサポートされません。
ロジカル・スタンバイ・データベースの下では、暗号化された列が含まれる表をレプリケートするときに、次の制限事項を考慮する必要があります。
暗号化されたREDOレコードを変換するには、透過的データ暗号化鍵を含むオープン・ウォレットへのアクセス権がSQL Applyに必要です。そのため、鍵を含むウォレットの作成後に、そのウォレットをプライマリ・データベースからスタンバイ・データベースにコピーする必要があります。
ウォレットは、マスター鍵が変更されるたびに、プライマリ・データベースからロジカル・スタンバイ・データベースにコピーする必要があります。
ロジカル・スタンバイ・データベースでは、プライマリ・データベースから暗号化された表をレプリケートしている間、マスター鍵をREKEY(鍵の変更)しないことをお薦めします。これは、暗号化されたREDOレコードの検出時にSQL Applyが停止する原因になります。
ロジカル・スタンバイ・データベースでは、レプリケートされた表の暗号化鍵をREKEYできます。このためには、REKEYコマンドを発行する前にガード設定をNONE
にして低くする必要があります。
レプリケートされた暗号化された表では、プライマリ・データベースで使用された暗号化方式とは異なる方式を列に対して使用できます。たとえば、HR.EMPLOYEES
表のSALARY
列がプライマリ・データベースでAES102暗号化アルゴリズムを使用して暗号化される場合、ロジカル・スタンバイではAES256暗号化アルゴリズムを使用して暗号化することができます。あるいは、ロジカル・スタンバイ・データベースでは、SALARY
列を暗号化しないままにしておくことも可能です。
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'); |
Oracle Database 11gでは、ロジカル・スタンバイによってDBMS_RLS
およびDBMS_FGA
PL/SQLパッケージで提供されているセキュリティ環境を自動的にレプリケートすることができます。このサポートによりセキュリティ環境が透過的に維持されるので、サーバーをスタンバイにフェイルオーバーする際に、セキュリティに配慮した管理の手間が軽減されます。また、プライマリ・データに適用されたアクセス・コントロール・ポリシーを自動的にスタンバイに必ず転送し、スタンバイ・データに同等な保護レベルを付与することができます。スタンバイ・サーバーを11gで新しく作成すると、このレプリケーションはデフォルト設定で有効化されますが、それ以外の場合はDBAが適宜有効化する必要があります。
これらのPL/SQLパッケージのレプリケーションをサポートするには、プライマリとスタンバイの両方が11.1以上の互換性設定で稼働している必要があります。
また、参照される表は、ロジカル・スタンバイよって保持されるオブジェクトである必要があります。たとえば、ROWID列を含む表のデータがロジカル・スタンバイによって保持されない場合、その表を参照するDBMS_RLS
およびDBMS_FGA
コールも保持されません。
行レベルのセキュリティは、仮想プライベート・データベース(VPD)とも呼ばれる機能で、表、ビューまたはシノニムにアクセスするときに、セキュリティの粒度をFINEレベルにまで強化します。VPDポリシーで保護された表、ビューまたはシノニムに直接または間接的にユーザーがアクセスすると、サーバーはそのユーザーのSQL文を動的に変更します。この変更では、セキュリティ・ポリシーを実装するファクンションによって戻されるWHERE
条件(述語)が作成されます。文は、ファンクションで表される条件あるいはファンクションによって戻される条件を使用して、ユーザーに対して透過的に、動的に変更されます。VPDポリシーは、SELECT
、INSERT
、UPDATE
、INDEX
およびDELETE
文に適用されます。VPDは、DBMS_RLS
パッケージを使用してセキュリティ・ポリシーを適用すると実装されます。
DBMS_RLS
プロシージャをプライマリで実行すると、追加情報がREDOに取得されるため、スタンバイでプロシージャ・コールを論理的に再構築して実行することができます。ロジカル・スタンバイでは、VPDの補助オブジェクト(コンテキスト、データベース・ログオン、トリガー、サポート対象パッケージなど)をレプリケートできます。これらのオブジェクトが保持されるスキーマに存在し、レプリケーションを停止させるDDLスキップが構成されていないことを確認する必要があります。
きめ細かい監査により、select文を監査することができます。DBMS_FGA
パッケージでは、表にアクセスするすべてのselect文を、アクセスしたデータとともに取得することができます。FGAポリシーは特定の列、または指定された述語戻り値がTRUE
の行を戻す、select文にも適用することができます。
DBMS_FGA
プロシージャをプライマリで実行すると、追加情報がREDOに取得されるため、スタンバイでプロシージャ・コールを論理的に再構築して実行することができます。
パッケージとプロシージャでのワイルドカードの指定がサポートされていない点を除き、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に対するスキップ・プロシージャは代用文を戻しません。
ロジカル・スタンバイ・データベースでは、Oracle Label Securityをサポートしません。Oracle Label Securityをプライマリ・データベースにインストールすると、開始時に内部エラーが発生してSQL Applyはロジカル・スタンバイ・データベースで失敗します。
ロジカル・スタンバイ・データベースは、サポートされていないデータ型を含む表があるため、Oracle E-Business Suite実装を完全にはサポートしていません。しかし、SKIP
ルールを使用して、E-Business Suiteスキーマと表のサブセットを複製し、アプリケーションをロジカル・スタンバイにオフロードすることは可能です。
関連項目: Oracle E-Business Suiteでのロジカル・スタンバイ使用の詳細は、http://support.oracle.com のMy Oracle Supportノート851603.1を参照してください。 |
ロジカル・スタンバイ・データベースでは、次の表記憶域タイプがサポートされます。
クラスタ表(索引クラスタおよびヒープ・クラスタを含む)
索引構成表(オーバーフロー・セグメントを含むパーティション化および非パーティション化)
ヒープ構成表(パーティション化および非パーティション化)
OLTP表圧縮(COMPRESS FOR OLTP
)および基本表圧縮(COMPRESS BASIC
)OLTP表圧縮および基本表圧縮では、プライマリ・データベースの互換性設定が11.1.0以上に設定されている必要があります。
仮想列を含む表(表にロジカル・スタンバイでサポートされていない他の列またはプロパティがない場合)。これは、Oracle Database 11g リリース2(11.2.0.3)以上でのみサポートされます。
ハイブリッド列圧縮を使用する表
関連項目:
|
ロジカル・スタンバイでは、次のデータ型のみを含む表はサポートされません。
LOB
(CLOB
、NCLOB
、BLOB
)
LONG
LONG
RAW
OBJECT
TYPE
COLLECTIONS
XML
この項では、PL/SQLパッケージに関する次の考慮事項について説明します。
関連項目: Oracle PL/SQL供給パッケージの詳細は、『Oracle Database 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
、およびDBMS_REDEFINITION
の3つのパッケージを使用して実行されるアクションのレプリケーションがサポートされます。
システムのメタデータを変更する、オラクル社が提供するPL/SQLパッケージは、通常、SQL Applyではサポートされないため、その影響はロジカル・スタンバイ・データベースでは参照できません。この種のパッケージの例には、DBMS_JAVA
、DBMS_REGISTRY
、DBMS_ALERT
、DBMS_SPACE_ADMIN
、DBMS_REFRESH
およびDBMS_AQ
があります。
DBMS_JOB
に固有のサポートが用意されています。プライマリ・データベースで作成されたジョブはスタンバイ・データベースで複製されますが、このスタンバイがスタンバイ・ロールを維持しているかぎり、実行されません。スイッチオーバーまたはフェイルオーバーが発生すると、元のプライマリ・データベースでスケジュールされていたジョブの実行は、新規のプライマリ・データベースで自動的に開始されます。
ロジカル・スタンバイでジョブを作成することもできます。これらのジョブは、ロジカル・スタンバイがスタンバイ・ロールを維持している間のみ実行されます。
スタンバイ・データベースでジョブを実行できるように、DBMS_SCHEDULER
に固有のサポートが用意されています。database_role
と呼ばれるスケジューラ・ジョブの新しい属性が11gで作成されました。この内容は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パッケージおよびタイプ・リファレンス』を参照してください。 |
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.9.3.1項からC.9.3.6項を参照してください。
次のパッケージには、サポートされないプロシージャが含まれます。
DBMS_XMLSCHEMA
DBMS_XMLINDEX
これらのパッケージに加えて、ロジカル・スタンバイではXDBスキーマへの変更もサポートしません。XDBスキーマ内のオブジェクトは、システム・メタデータとみなされ、直接の変更はレプリケートされません。
Oracle XML DBリポジトリで管理される表は、階層対応表とも呼ばれますが、ロジカル・スタンバイではサポートされません。これらの表は、XMLデータの格納に使用され、通常のSQLアクセスに加えてFTPおよびHTTPプロトコルを使用してアクセスできます。これらの表の詳細は、『Oracle XML DB開発者ガイド』を参照してください。
DBMS_XMLSCHEMAパッケージ内の次のプロシージャは、ロジカル・スタンバイではサポートされず、レプリケートできません。ロジカル・スタンバイは、これらのプロシージャへのコールを検出すると、これらのコールに対してユーザーが補正アクションを実行できるように停止します。これらのサポートされないプロシージャの処理に使用できる代替方法の詳細は、C.9.3.3項からC.9.3.6項を参照してください。
REGISTERSCHEMA
REGISTERURI
DELETESCHEMA
PURGESCHEMA
COPYEVOLVE
INPLACEEVOLVE
COMPILESCHEMA
XDBスキーマは、Oracle管理スキーマです。このスキーマに対する変更は、ロジカル・スタンバイによって自動的にスキップされます。次のプロシージャは、XDBスキーマを変更しますが、レプリケートされません。
GENERATEBEAN
次のプロシージャおよびファンクションは、REDOを生成しないため、ロジカル・スタンバイは停止しません。
GENERATESCHEMAS
GENERATESCHEMA
DBMS_XMLINDEX
パッケージ内のSYNCINDEX
プロシージャは、ロジカル・スタンバイではサポートされず、レプリケートできません。ロジカル・スタンバイは、このプロシージャへのコールを検出すると停止します。
次のファンクションおよびプロシージャは、REDOを生成しないため、ロジカル・スタンバイは停止しません。
NODEREFGETREF
NODEREFGETVALUE
NODEREFGETPARENTREF
NODEREFGETNAME
NODEREFGETNAMESPACE
サポートされないPL/SQLプロシージャの処理には、2つのオプションがあります。1つ目のオプションは、ロジカル・スタンバイの適用プロセスが停止してなんらかの補正アクションを手動で実行できるようにする方法です。2つ目のオプションは、事前対応アクションを実行し、さらにロジカル・スタンバイのスキップ・プロシージャを使用してサポートされないPL/SQLをスキップする方法です。次の各項で、これらのオプションについてそれぞれ説明します。
ロジカル・スタンバイでサポートされないものが検出されると、適用プロセスは停止し、エラーがDBA_LOGSTDBY_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_LOGSTDBY_EVENTS
表を調べ、適用が停止した原因を確認します。
スタンバイで、サポートされないPL/SQLについてなんらかの補正アクションを実行します。
スタンバイで適用を再開します。
プライマリ・データベースで実行する予定のアクションが、スタンバイの停止原因となることがわかっている場合があります。その場合、事前にアクションを実行してスタンバイがREDOを適用していない時間を最小限に抑えるか、なくなるようにすることが可能です。
たとえば、新しいアプリケーションのインストール予定があることを知っていると仮定します。インストレーションでは大量のXMLスキーマの登録が必要になります。これらのスキーマをプライマリに登録する前に、スタンバイに登録しておくことができます。DBMS_XMLSCHEMA.REGISTERSCHEMA
プロシージャについても、スタンバイでスキップ・プロシージャをインストールすることができます。このプロシージャはXMLスキーマが登録済かどうかを確認し、登録済であればロジカル・スタンバイにそのPL/SQLコールをスキップするように伝えます。
この方法は、他のサポートされていないPL/SQLプロシージャの一部にも使用できます。たとえば、DBMS_XMLSCHEMA.DELETESCHEMA
は、同様の方法で処理できます。スタンバイにスキーマがインストールされているかどうかを確認し、インストールされていない場合は、スタンバイには大きな影響がまったくないので、そのPL/SQLが安全にスキップされるように、スキップ・プロシージャを作成できます。
前述のアプローチは有効ですが、すべての場合に使用できるわけではありません。他のトランザクションとの相対的なPL/SQL実行時間が重要ではない場合にかぎり、安全に使用することができます。使用すべきではない場合の例として、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
ロジカル・スタンバイ・データベースを作成する前にプライマリ・データベース・オブジェクトでサポートされていないデータベース・オブジェクトを識別しておくことが重要です。プライマリ・データベース上でサポートされていないデータ型や表に対して行った変更は、ロジカル・スタンバイ・データベース上では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 - > 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 - > 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サービスによって、その表が自動的に除外されます。
注意: プライマリ・データベースの重要な表がロジカル・スタンバイ・データベースでサポートされない場合は、フィジカル・スタンバイ・データベースの使用を考慮することもできます。フィジカル・スタンバイ・データベースには、このようなデータ型の制約はありません。 |
デフォルトでは、次の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-1に、DBMS_LOGSTDBY.SKIP
プロシージャのstmt
パラメータについて、サポートされる値を示します。表の左側の列には、キーワードの右側にあるSQL文セットの識別に使用される可能性のあるキーワードを示します。また、sys.audit_actions
表に示されたSQL文(表1-13の右列を参照)はすべて、有効な値でもあります。キーワードは、通常、データベース・オブジェクトによって定義されます。
関連項目: DBMS_LOGSTDBY パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』および10.5.3項「DDL文のスキップ・ハンドラの設定」を参照してください。 |
表C-1 DBMS_LOGSTDBY.SKIPプロシージャのstmtパラメータの値
キーワード | 関連するSQL文 |
---|---|
このグループのSQL文に対するキーワードはない。 |
GRANT REVOKE ANALYZE TABLE ANALYZE INDEX ANALYZE CLUSTER |
|
|
|
|
|
|
|
|
|
|
|
表内のDML文を含む(例: |
|
|
|
特定のスキーマに関連付けられていないすべてのDDL 注意: |
|
|
|
|
|
|
|
|
|
|
|
|
|
スキーマ・オブジェクト(例: 表、索引、列)の作成、変更または削除を行うすべてのDDL文 注意: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
脚注 1 Javaスキーマ・オブジェクト(ソース、クラス、リソース)は、SQL文をスキップ(無視)するためのプロシージャと同等とみなされます。
関連項目: SKIP およびUNSKIP オプションの使用例を示した次の各項
|
SQL Applyは、データベース・リンクを参照する次のようなDDL文を正しく適用できない場合があります。
CREATE TABLE tablename AS SELECT * FROM bar@dblink
これは、ロジカル・スタンバイ・データベースでdblink
がプライマリ・データベースと同じデータベースを指さないことがあるためです。このようなDDL文の実行中にSQL Applyに障害が発生した場合は、表の作成にDBMS_LOGSTDBY.INSTANTIATE_TABLE
プロシージャを使用して、SQL APPLYの操作を再開する必要があります。
ロジカル・スタンバイでは、監査およびファイングレイン監査がサポートされています。プライマリ・データベースでAUD$
およびFGA_AUD$
表に対して行われた変更は、ロジカル・スタンバイにレプリケートされます。
AUD$
表およびFGA_AUD$
表の両方に、DBID列があります。DBID値がプライマリ・データベースの値の場合、その行は、プライマリでのアクティビティに基づいてロジカル・スタンバイにレプリケートされています。DBID値がロジカル・スタンバイ・データベースの値の場合、その行は、ロジカル・スタンバイのローカル・アクティビティの結果として挿入されています。
ロジカル・スタンバイ・データベースで、プライマリ・ロールをロールの推移(スイッチオーバーまたはフェイルオーバー)の結果とみなした後、新しいプライマリ(元のロジカル・スタンバイ)および新しいロジカル・スタンバイ(元のプライマリ)のAUD$
表およびFGA_AUD$
表は、必ず同期されるとはかぎりません。このため、新しいプライマリ・データベースのAUD$
表またはFGA_AUD$
表のすべての行が、新しいロジカル・スタンバイ・データベースに存在するとはかぎりません。ただし、データベースがプライマリ・ロールの際に挿入されたAUD$
およびFGA_LOG$
のすべての行はレプリケートされ、ロジカル・スタンバイ・データベースに存在します。
次のいずれかの方法を使用して分散トランザクションを実行できます。
データベース・リンクを使用した調整方法により複数のデータベース内の表を変更します。
提供PL/SQLパッケージ内でDBMS_XA
パッケージによって公開されたXAインタフェース、あるいはOCIまたはJDBCライブラリを介してXAインタフェースを使用します。XAインタフェースによって、X/Open分散トランザクション処理(DTP)アーキテクチャが実装されます。
これら2つの方法のいずれかを使用した分散トランザクション中に、プライマリ・データベースに対して変更が行われると、ロジカル・スタンバイ・データベースにレプリケートされます。
ただし、分散トランザクションの状態はレプリケートされません。ロジカル・スタンバイ・データベースは、その種のトランザクションの未決定、または準備状態は継承しません。またXAトランザクション用にプライマリ・データベースで使用されたものと同じグローバル・トランザクション識別子はレプリケートしません。その結果、分散トランザクションにコミットする前にロジカル・スタンバイ・データベースにフェイルオーバーすると、変更がロジカル・スタンバイにロールバックされます。プライマリ・データベース上の分散トランザクションが準備状態で、2段階から成るコミット・プロトコルのうち最初の段階を正常に終了した場合でも、ロールバックが発生します。スイッチオーバー操作はすべてのアクティブ分散トランザクションの完了を待機するので、この制約には影響されません。
XAトランザクションは次の2つの方法で実行できます。
密結合(異なるXAブランチがロックを共有する)
疎結合(異なるXAブランチがロックを共有しない)
疎結合のXAブランチによって行われる変更のレプリケーションは、COMPATIBLE
パラメータの値に関係なくサポートされます。Oracle RACプライマリ上で緊密に連結されたブランチ(11gリリース1で新たに提供)への変更のレプリケーションは、COMPATIBLE=11.2
以上でのみサポートされています。
SecureFile LOBは、データベースの互換性レベルが11.2以降に設定されている場合にサポートされます。
プライマリ・データベースでは、SecureFile LOB列で透過的なデータ暗号化およびデータ圧縮を使用できます。SecureFile LOB列の重複除外はサポートされていません。また、DBMS_LOB
PL/SQLパッケージに含まれる次の操作は、SecureFile LOB列ではサポートされていません。
FRAGMENT_DELETE
、FRAGMENT_INSERT
、FRAGMENT_MOVE
、FRAGMENT_REPLACE
、COPY_FROM_DBFS_LINK
、MOVE_TO_DBFS_LINK
、SET_DBFS_LINK
、COPY_DBFS_LINK
、SETCONTENTTYPE
SQL Applyがこれらの操作によって生成されたREDOを検出すると、「ORA-16211:
サポートされていないレコードが、アーカイブREDOログで見つかりました。」エラーとともに停止します。続行するには、DBMS_LOGSTDBY.SKIP
を使用した該当する表にスキップ・ルールを追加し、SQL Applyを再開します。