| Oracle® Data Guard概要および管理 12c リリース1 (12.1) B71304-07 |
|
 前 |
 次 |
ロジカル・スタンバイ・データベースの設定では、ロジカル・スタンバイ・データベースがプライマリ・データベースのデータ型と表を維持していることを確認する必要があります。次の各項では、ロジカル・スタンバイ・データベースのサポート対象および対象外の各種データベース・オブジェクト、ストレージ・タイプ、PL/SQL供給パッケージをリストにまとめています。
次の各項では、データベース・オブジェクトについて、サポートされるものとサポートされないものを示します。
注意:
Oracle Database 12cリリース1 (12.1)現在、COMPATIBLE初期化パラメータを12.0以降に設定し、MAX_STRING_SIZE初期化パラメータをEXTENDEDに設定した場合、VARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズは32 KBに増加しました。ロジカル・スタンバイ・データベースでは、ほとんどの場合、この増加したサイズがサポートされます。既知の制限については、「プライマリ・データベース内の表の行が一意に識別できることの確認」を参照してください。
ロジカル・スタンバイ・データベースでは、次のデータ型がサポートされます。
抽象データ型(ADT)およびADT表
ADTには、単純なスカラー・タイプのVARRAYを除き、最上位の列型としてサポートされないデータ型(ネストされた表、REF、BFILE、サポートされない不透明型など)を含めることはできません。
サポートされるADT列のある表では、スカラー最上位列でのみ構成されているプライマリ・キーが存在する必要があります(スカラーADT属性はこうした候補キーの一部にはなりません)。
BINARY_DOUBLE
BINARY_FLOAT
BasicFileおよびSecureFileとして格納されるBLOB、CLOBおよびNCLOB。SecureFilesは、圧縮、暗号化または重複除外できます。SecureFileサポートには、11.2以上の互換性で動作するプライマリ・データベースが必要です。「SecureFile LOBのサポート」を参照してください
CHAR
DATE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
LONG
LONG RAW
NCHAR
NUMBER
NVARCHAR2
VARRAYとして格納されているオブジェクト(コレクションを除く)
Oracle Text
RAW
マルチメディア(「ロジカル・スタンバイ・データベースでサポートされないデータ型」にリストされている例外を参照)。
ORDAudio
ORDDataSource (内部)
ORDDicom
ORDDoc
ORDImage
ORDSource (内部)
ORDVideo
空間型(「ロジカル・スタンバイ・データベースでサポートされないデータ型」にリストされている例外を参照)。
TIMESTAMP
TIMESTAMP WITH TIMEZONE
TIMESTAMP WITH LOCAL TIMEZONE
VARCHARおよびVARCHAR2
次のプライマリ・データベース互換性要件を仮定した場合は、すべてのストレージ・モデルのXMLTypeデータ。
CLOB形式で格納されているXMLTypeには、11.0以降の互換性設定で実行するプライマリ・データベースが必要です(CLOBとして格納されているXMLTypeはOracle Database 12cリリース1 (12.1)では非推奨です)。
オブジェクト・リレーショナル形式またはバイナリXMLで格納されるXMLTypeには、11.2.0.3以上のREDO互換性が設定されたOracle Database 11gリリース2(11.2.0.3)以上でプライマリ・データベースを実行している必要があります。
注意:
SQL Applyは、ADT、LOBまたはXMLType列でDMLを実行する関数コールを含む文をサポートしません。
次に対するSQL Applyサポートでは、プライマリ・データベースに対する互換性要件があります。
マルチバイトのCLOBサポートには、10.1以上の互換性で動作するプライマリ・データベースが必要です。
LOBおよびオーバーフローなしのIOTサポートには、10.1以上の互換性で動作するプライマリ・データベースが必要です。
LOBおよびオーバーフローありのIOTサポートには、10.2以上の互換性で動作するプライマリ・データベースが必要です。
TDEサポートには、11.1以上の互換性で動作するプライマリ・データベースが必要です。
基本圧縮および高度な行圧縮には、11.1以上の互換性で動作するプライマリ・データベースが必要です。
ハイブリッド列圧縮サポートは、基礎となるストレージ・システムに依存します。
関連項目:
ハイブリッド列圧縮の詳細は、『Oracle Database概要』を参照してください。
次のデータ型はロジカル・スタンバイ・データベースではサポートされていません。表にサポートされていないこれらのデータ型が含まれている場合、SQL Applyを実行しても表全体が無視されます。(ネイティブのREDOベースのサポートが欠如したデータ型のサポートの詳細は、「ネイティブREDOサポートが欠如したデータ型のサポート」を参照してください。)
BFILE
ROWID、UROWID
コレクション( VARRAYおよびネストされた表を含む)
ネストされた表およびREFを含むオブジェクト
次の空間型はサポートされていません。
MDSYS.SDO_GEORASTER
MDSYS.SDO_TOPO_GEOMETRY
ID列
拡張データ型サポート(EDS)機能では、ネイティブなREDOベースのサポートが欠如した特定のデータ型をサポートするためのロジカル・スタンバイ用のメカニズムが提供されます。たとえば、SDO_GEOMETRY列を含む表はEDSを使用してレプリケートできます。(ソース表には主キーがある必要があります。)
DBA_LOGSTDBY_EDS_SUPPORTEDビューを問い合せて、EDSの候補の表を探すことができます。
関連項目:
EDSの詳細は、「レプリケーション中の拡張データ型サポートの使用」を参照してください
Oracle Data Guard SQL Applyを使用すると、透過的データ暗号化(TDE)を有効に設定したプライマリ・データベースにデータ保護を提供できます。ロジカル・スタンバイ・データベースを使用し、高度なセキュリティ要件を伴うアプリケーションにデータ保護を提供する場合は、次のことを考慮してください。
サーバーが保持する鍵を使用する透過的データ暗号化が指定された表は、プライマリ・データベースとスタンバイ・データベースの両方が11.1以上の互換性レベルで稼働している場合のロジカル・スタンバイ・データベースで複製されます。
ハードウェア・セキュリティ・モジュールの下での透過的データ暗号化は、Oracle Database 11gリリース2 (11.2)以降のロジカル・スタンバイ・データベースではサポートされません。
ロジカル・スタンバイ・データベースの下では、暗号化された列が含まれる表をレプリケートするときに、次の制限事項を考慮する必要があります。
暗号化されたREDOレコードを変換するには、透過的データ暗号化鍵を含むオープン・ウォレットへのアクセス権がSQL Applyに必要です。そのため、鍵を含むウォレットの作成後に、そのウォレットをプライマリ・データベースからスタンバイ・データベースにコピーする必要があります。
ウォレットは、マスター鍵が変更されるたびに、プライマリ・データベースからロジカル・スタンバイ・データベースにコピーする必要があります。
ロジカル・スタンバイ・データベースでは、プライマリ・データベースから暗号化された表をレプリケートしている間、マスター鍵をREKEY(鍵の変更)しないことをお薦めします。これは、暗号化されたREDOレコードの検出時にSQL Applyが停止する原因になります。
ロジカル・スタンバイ・データベースでは、レプリケートされた表の暗号化鍵をREKEYできます。このためには、REKEYコマンドを発行する前にガード設定をNONEにして低くする必要があります。
レプリケートされた暗号化された表では、プライマリ・データベースで使用された暗号化方式とは異なる方式を列に対して使用できます。たとえば、HR.EMPLOYEES表のSALARY列がプライマリ・データベースでAES102暗号化アルゴリズムを使用して暗号化される場合、ロジカル・スタンバイではAES256暗号化アルゴリズムを使用して暗号化することができます。あるいは、ロジカル・スタンバイ・データベースでは、SALARY列を暗号化しないままにしておくことも可能です。
Oracle Data Guard SQL Applyを使用すると、表領域の暗号化を有効に設定したプライマリ・データベースにデータ保護を提供できます。その場合、「透過的データ暗号化(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を参照してください。
ロジカル・スタンバイ・データベースでは、次の表記憶域タイプがサポートされます。
クラスタ表(索引クラスタおよびヒープ・クラスタを含む)。
索引構成表(オーバーフロー・セグメントを含むパーティション化および非パーティション化)。
ヒープ構成表(パーティション化および非パーティション化)。
高度な行圧縮および基本表圧縮。どちらのオプションでも、プライマリ・データベースの互換性設定が11.1.0以上に設定されている必要があります。
SecureFilesとして格納されるLOB列を含む表(互換性が11.2以降に設定されている場合)。
ハイブリッド列圧縮を使用している表(互換性が11.2.0.2以降に設定されている場合)。
関連項目:
ハイブリッド列圧縮の詳細は、『Oracle Database概要』を参照してください。
仮想列を含む表(表にロジカル・スタンバイでサポートされていない他の列またはプロパティがない場合)
主キーもNULL値が許容されていない一意制約/索引もない場合、宣言最大長が4000バイトのすべての列が、変更された行を識別するためにUPDATE文の一部としてログに記録されます。行の識別の目的では、ロジカル・スタンバイには次のデータ型のいずれか1つ以上の表示可能な(仮想ではない)列を含む表が必要です。
CHAR
VARCHAR
VARCHAR2 (宣言済の列の長さ<= 4000バイト)
NVARCHAR
NVARCHAR2 (宣言済の列の長さ<= 4000バイト)
NUMBER
DATE
RAW
BINARY FLOAT
BINARY DOUBLE
TIMESTAMP
TIMESTAMPWITHTIMEZONE
TIMESTAMPWITHLOCALTIMEZONE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
ロジカル・スタンバイでは、次のデータ型のみを含む表はサポートされません。
LOB (CLOB、NCLOB、BLOB)
LONG
LONG RAW
OBJECT TYPE
COLLECTIONS
XML
VARCHAR2 (宣言済の列の長さ> 4000バイト)
NVARCHAR2 (宣言済の列の長さ> 4000バイト)
RAW (宣言済の列の長さ> 4000バイト)
この項では、PL/SQLパッケージに関する次の考慮事項について説明します。
関連項目:
Oracle PL/SQL供給パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
システムのメタデータやユーザー・データを変更しない、オラクル社が提供するPL/SQLパッケージは、アーカイブREDOログ・ファイルにフットプリントを残さないため、プライマリ・データベースで安全に使用できます。この種のパッケージの例には、DBMS_OUTPUT、DBMS_RANDOM、DBMS_PIPE、DBMS_DESCRIBE、DBMS_TRACE、DBMS_METADATA、DBMS_CRYPTOがあります。
システムのメタデータは変更せず、ユーザー・データを変更することがある、オラクル社が提供するPL/SQLパッケージは、変更されるデータが「ロジカル・スタンバイ・データベースでサポートされるデータ型」に示すサポートされるデータ型に属するかぎり、SQL Applyでサポートされます。この種のパッケージの例には、DBMS_LOB、DBMS_SQL、DBMS_TRANSACTIONがあります。
Oracle Data Guardのロジカル・スタンバイでは、DBMS_DDL、DBMS_FGA、SDO_META、DBMS_REDACT、DBMS_REDEFINITION、DBMS_RLS、DBMS_SQL_TRANSLATOR、DBMS_XDS、DBMS_XMLINDEXおよびDBMS_XMLSCHEMAのパッケージを使用して実行されるアクションのレプリケーションがサポートされます。
ロジカル・スタンバイでサポートされているパッケージを特定するために、DBA_LOGSTDBY_PLSQL_SUPPORTビューを問い合せることができます。たとえば、次の問合せを実行すると、汎用ロジカル・スタンバイでサポートされているパッケージを探すことができます。
SQL> SELECT OWNER, PKG_NAME FROM DBA_LOGSTDBY_PLSQL_SUPPORT - > where support_level = 'ALWAYS';
DBMS_ROLLINGパッケージを使用して実行したローリング・アップグレードの場合にサポートされるパッケージを特定するために、次のようにしてDBA_LOGSTDBY_PLSQL_SUPPORTビューを問い合せることができます。
SQL> SELECT OWNER, PKG_NAME FROM DBA_LOGSTDBY_PLSQL_SUPPORT - > where support_level = 'DBMS_ROLLING';
システムのメタデータを変更する、オラクル社が提供するPL/SQLパッケージは、通常、SQL Applyではサポートされないため、その影響はロジカル・スタンバイ・データベースでは参照できません。この種のパッケージの例には、DBMS_JAVA、DBMS_REGISTRY、DBMS_ALERT、DBMS_SPACE_ADMIN、DBMS_REFRESHおよびDBMS_AQがあります。
また、DBMS_RESOURCE_MANAGERパッケージはフィジカル・スタンバイのローリング・アップグレードにはサポートされません。
DBMS_JOBに固有のサポートが用意されています。プライマリ・データベースで作成されたジョブはスタンバイ・データベースで複製されますが、このスタンバイがスタンバイ・ロールを維持しているかぎり、実行されません。スイッチオーバーまたはフェイルオーバーが発生すると、元のプライマリ・データベースでスケジュールされていたジョブの実行は、新規のプライマリ・データベースで自動的に開始されます。
ロジカル・スタンバイでジョブを作成することもできます。これらのジョブは、ロジカル・スタンバイがスタンバイ・ロールを維持している間のみ実行されます。
スタンバイ・データベースでジョブを実行できるように、DBMS_SCHEDULERに固有のサポートが用意されています。database_roleと呼ばれるスケジューラ・ジョブの新しい属性がOracle Database 11gで作成されました。この内容はV$DATABASEのdatabase_role属性と一致しています。スケジューラ・ジョブを作成すると、ローカル・ロールにデフォルト設定されます。したがって、スタンバイで作成されたジョブは、LOGICAL STANDBYのdatabase_roleにデフォルト設定されます。ジョブ・スケジューラは、現行のロールに固有のジョブだけを実行します。スイッチオーバーまたはフェイルオーバーの際は、スケジューラが新しいロールに固有のジョブ実行に切り替わります。
スケジューラ・ジョブはスタンバイにレプリケートされません。ただし、DBMS_ROLLING PL/SQLパッケージを使用して実行したローリング・アップグレードの場合を除きます。しかし、既存のジョブはDBMS_SCHEDULER.Set_Attributeプロシージャを使用して、新しいロールの下でアクティブ化できます。あるいは、両方のロールで実行する必要があるジョブをクローニングし、コピーを他のロールに固有のものにすることが可能です。DBA_SCHEDULER_JOB_ROLESビューには、どのジョブがどのロールに固有かが表示されます。
スケジューラのジョブをロジカル・スタンバイ・データベースで実行する際は、データベース・ガードに従います。したがって、維持されていない表の変更が必要なジョブを実行するには、データベース・ガードをSTANDBYに設定します。(ALTER SESSION DISABLE GUARD文をPL/SQLブロック内で使用しても、効果がありません。)
次の互換性要件を伴い、ロジカル・スタンバイはすべてのストレージ・モデルのXMLTypeデータをサポートします。
CLOB形式で格納されているXMLTypeには、11.0以降の互換性設定で実行するプライマリ・データベースが必要です(CLOBとして格納されているXMLTypeはOracle Database 12cリリース1 (12.1)では非推奨です)。
オブジェクト・リレーショナル形式またはバイナリXMLで格納されるXMLTypeには、11.2.0.3以上のREDO互換性が設定されたOracle Database 11gリリース2(11.2.0.3)以上でプライマリ・データベースを実行している必要があります。
完全にはサポートされないXMLとともに使用されるPL/SQLパッケージがいくつかあります。
ロジカル・スタンバイがサポートしているPL/SQLパッケージとプロシージャは、インメモリー構造だけで変更を行い、データベースに格納されたデータは変更しません。これらのパッケージはREDOを生成しないため、ロジカル・スタンバイにはレプリケートされません。
ロジカル・スタンバイでサポートされなくても、レプリケーション・アクティビティの続行にロジカル・スタンバイ・データベースで対応する起動が必要なXMLおよびXDBに関連する特定のPL/SQLパッケージおよびプロシージャは、プライマリ・データベースでこれらのプロシージャが起動することにより、プロシージャの起動を示す追加のREDOレコードが生成されるように装備されています。SQL ApplyでこのようなREDOレコードが検出されると、SQL Applyは停止し、プロシージャ名を示すエラー・メッセージがDBA_LOGSTDBY_EVENTS表に書き込まれます。これにより、DBAは対応するプロシージャを適切な時期にロジカル・スタンバイ・データベースで起動し、プライマリ・データベースで生成された後続のREDOレコードをロジカル・スタンバイ・データベースに正常に適用することができます。これらのサポートされないプロシージャの処理方法の詳細は、「DBMS_XMLSCHEMAスキーマ」から「順序に依存するサポートされないPL/SQLの補正」を参照してください。
次のパッケージには、サポートされないプロシージャが含まれます。
DBMS_XMLSCHEMA(互換性が11.2以降に設定されている場合にサポートされます。)
DBMS_XMLINDEX
これらのパッケージに加えて、ロジカル・スタンバイではXDBスキーマへの変更もサポートしません。XDBスキーマ内のオブジェクトは、システム・メタデータとみなされ、直接の変更はレプリケートされません。
Oracle XML DBリポジトリで管理される表は、階層対応表とも呼ばれますが、ロジカル・スタンバイではサポートされません。これらの表は、XMLデータの格納に使用され、通常のSQLアクセスに加えてFTPおよびHTTPプロトコルを使用してアクセスできます。これらの表の詳細は、『Oracle XML DB開発者ガイド』を参照してください。
DBMS_XMLSCHEMAパッケージ内の次のプロシージャは、ロジカル・スタンバイではサポートされず、レプリケートできません。ロジカル・スタンバイは、これらのプロシージャへのコールを検出すると、これらのコールに対してユーザーが補正アクションを実行できるように停止します。これらのサポートされないプロシージャの処理に使用できる代替方法の詳細は、「サポートされないPL/SQLプロシージャの処理」から「順序に依存するサポートされないPL/SQLの補正」を参照してください。
COPYEVOLVE
INPLACEEVOLVE
COMPILESCHEMA
XDBスキーマは、Oracle管理スキーマです。このスキーマに対する変更は、ロジカル・スタンバイによって自動的にスキップされます。次のプロシージャは、XDBスキーマを変更しますが、レプリケートされません。
GENERATEBEAN
次のプロシージャおよびファンクションは、REDOを生成しないため、ロジカル・スタンバイは停止しません。
GENERATESCHEMAS
GENERATESCHEMA
注意:
Oracle Database 12cリリース1 (12.1)現在、GENERATESCHEMASおよびGENERATESCHEMAプロシージャは非推奨です。
DBMS_XMLINDEXパッケージ内のプロシージャはすべてサポートされています。ただし、次のものは除きます。
DBMS_XMLINDEX.REGISTERPARAMETER
DBMS_XMLINDEX.MODIFYPARAMETER
DBMS_XMLINDEX.DROPPARAMETER
サポートされない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"."REGISTERPARAMETER" (
"NAME" => 'myIndexParam',
"PARAMETER" => 'PATH TABLE
ORA-16265: Unsupported PL/SQL procedure encountered
begin
"XDB"."DBMS_XMLSCHEMA"."REGISTERPARAMETER" (
"NAME" => 'myIndexParam',
"PARAMETER" => 'PATH TABLE
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についてなんらかの補正アクションを実行します。
スタンバイで適用を再開します。
前述のアプローチは有効ですが、すべての場合に使用できるわけではありません。他のトランザクションとの相対的な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サービスによって、その表が自動的に除外されます。
注意:
この項で示される問合せでは、マルチテナント・データベース(CDB)環境で作業している場合、DBAビューの多くに代替として使用する必要のある類似のCDBビューがあります。たとえば、DBA_LOGSTDBY_SKIPビューのかわりにCDB_LOGSTDBY_SKIPビューを問合せます。
ローリング・アップグレードを実行する前に、含まれるいずれかの表にロジカル・スタンバイ・データベースでサポートされないデータ型が含まれるかどうかを判別してください。これを行うには、実行中のローリング・アップグレードのタイプに応じて、DBA_LOGSTDBY_UNSUPPORTEDビューまたはDBA_ROLLING_UNSUPPORTEDビューのいずれかを問い合せることができます。
DBMS_ROLLINGを使用したローリング・アップグレードの実行に説明されているように、DBMS_ROLLING PL/SQLパッケージを使用したローリング・アップグレードを実行している場合、DBA_ROLLING_UNSUPPORTEDビューを問い合せてください。
DBMS_ROLLINGパッケージを使用せず、SQL Applyを使用したOracle Databaseのアップグレードに説明されている手動プロセスに従っている場合、DBA_LOGSTDBY_UNSUPPORTEDビューを問い合せてください。
DBMS_ROLLINGを使用して実行されるローリング・アップグレードは、手動ローリング・アップグレード操作よりも多くのオブジェクト型をサポートします。たとえば、DBMS_ROLLINGを使用して実行されるアップグレードのみキュー表をサポートします。さらに、DBMS_ROLLINGを使用して実行されるローリング・アップグレードは、より多くのPL/SQLパッケージをサポートします。
関連項目:
手動ローリング・アップグレードの実行の詳細は、「SQL Applyを使用したOracle Databaseのアップグレード」を参照してください
DBMS_ROLLING PL/SQLパッケージを使用したローリング・アップグレードの実行の詳細は、「DBMS_ROLLINGを使用したローリング・アップグレードの実行」を参照してください
DBMS_ROLLINGアップグレードの場合でのみ使用可能なPL/SQLパッケージのサポートの詳細は、「DBMS_ROLLINGアップグレードの場合でのみ使用可能な追加のPL/SQLパッケージのサポート」を参照してください
DBMS_ROLLING PL/SQLパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』
ビューの詳細情報は、『Oracle Databaseリファレンス』を参照してください。
デフォルトでは、次のSQL文がSQL Applyにより自動的にスキップされます。
ALTER DATABASEALTER MATERIALIZED VIEWALTERMATERIALIZEDVIEWLOGALTER SESSIONALTER SYSTEMCREATE CONTROL FILECREATE DATABASECREATE DATABASE LINKCREATE PFILE FROM SPFILECREATE MATERIALIZED VIEWCREATEMATERIALIZEDVIEWLOGCREATE SCHEMA AUTHORIZATIONCREATE SPFILE FROM PFILEDROP DATABASE LINKDROP MATERIALIZED VIEWDROPMATERIALIZEDVIEWLOGEXPLAINLOCK TABLEPURGE DBA_RECYCLEBINPURGE INDEXSET CONSTRAINTSSET ROLESET TRANSACTIONプライマリ・データベースで実行されるこの他のSQL文はすべて、ロジカル・スタンバイ・データベースに適用されます。
表C-1に、DBMS_LOGSTDBY.SKIPプロシージャのstmtパラメータについて、サポートされる値を示します。表の左側の列には、キーワードの右側にあるSQL文セットの識別に使用される可能性のあるキーワードを示します。また、sys.audit_actions表に示されたSQL文(表1-13の右列を参照)はすべて、有効な値でもあります。キーワードは通常、データベース・オブジェクトによって定義されます。
関連項目:
DBMS_LOGSTDBYパッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』および「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オプションの使用例を示した次の各項
ロジカル・スタンバイでは、監査およびファイングレイン監査がサポートされています。プライマリ・データベースで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列の重複除外およびSecureFile Database File System (DBFS)操作は完全にサポートされています。フラグメント操作は拡張データ型サポート(EDS)経由でのみサポートされています。
SQL Applyがサポートされていない操作によって生成されたREDOを検出すると、「ORA-16211: サポートされていないレコードが、アーカイブREDOログで見つかりました。」エラーとともに停止します。続行するには、DBMS_LOGSTDBY.SKIPを使用した該当する表にスキップ・ルールを追加し、SQL Applyを再開します。
ロジカル・スタンバイでは、データベース・ファイル・システム(DBFS)がサポートされています。DBFSは、データベース表に格納されたファイルおよびディレクトリの上に標準ファイル・システム・インタフェースを作成するため、データベースに格納されたファイルへのアクセスおよび管理が簡単になります。DBFSの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。
次のパッケージのレプリケーションは、DBMS_ROLLINGパッケージを使用して実行したローリング・アップグレードの場合でのみ使用可能です。
DBFS
DBMS_DBFS_CONTENT_ADMIN
DBMS_DBFS_SFS
DBMS_DBFS_SFS_ADMIN
軽量セキュリティ
XS_ACL
XS_DATA_SECURITY
XS_NAMESPACE
XS_PRINCIPAL
XS_ROLESET
XS_SECURITY_CLASS
Oracle Streams Advanced Queuing(AQ)
DBMS_AQ
DBMS_AQJMS
DBMS_AQADM (次のプロシージャを除く。SCHEDULE_PROPAGATION、RECOVER_PROPAGATION、UNSCHEDULE_PROPAGATION、ALTER_PROPAGATION_SCHEDULE、ENABLE_PROPAGATION_SCHEDULEおよびDISABLE_PROPAGATION_SCHEDULE)
Oracle Text
CTX_ADM
CTX_ANL
CTX_CLS
CTX_DDL
CTX_DOC
CTX_ENTITY
CTX_OUTPUT
CTX_QUERY
CTX_THES
CTX_TREE
スケジューラ
DBMS_SCHEDULER
XDB関連
DBMS_RESCONFIG
DBMS_XDB_CONFIG (特定のプロシージャはサポートされていません。(詳細は、『Oracle XML DB開発者ガイド』を参照してください。)
DBMS_XDB_REPOS
DBMS_XDBRESOURCE
DBMS_XDB_VERSION
DBMS_XDBZ (特定のプロシージャはサポートされていません。(詳細は、『Oracle XML DB開発者ガイド』を参照してください。)
関連項目:
軽量セキュリティ・パッケージの詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。
DBMS_SCHEDULER、XDB関連およびDBFS関連パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
