日本語PDF

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

ロジカル・スタンバイ・データベースの設定では、ロジカル・スタンバイ・データベースがプライマリ・データベースのデータ型と表を維持していることを確認する必要があります。

次の各項では、ロジカル・スタンバイ・データベースのサポート対象および対象外の各種データベース・オブジェクト、ストレージ・タイプ、PL/SQL供給パッケージをリストにまとめています。

• データ型に関する考慮事項

• ネイティブREDOサポートが欠如したデータ型のサポート

• 透過的データ暗号化(TDE)のサポート

• 表領域の暗号化のサポート

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

• Oracle Label Security

• Oracle E-Business Suite

• サポートされる表記憶域タイプ

• サポートされない表記憶域タイプ

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

• サポートされない表

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

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

• 分散トランザクションおよびXAのサポート

• SecureFile LOBのサポート

• データベース・ファイル・システム(DBFS)のサポート

• 文字セットに関する考慮事項

• DBMS_ROLLINGアップグレードの場合でのみ使用可能な追加のPL/SQLパッケージのサポート

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

サポート対象および対象外のデータベース・オブジェクトの詳細は、次の各項を参照してください。

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

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

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

ロジカル・スタンバイ・データベースでサポートされるデータ型を次に示します。

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

• 抽象データ型(ADT)およびADT表

  • ADTには、最上位の列型としてサポートされないデータ型(ネストされた表、PKREF、BFILE、サポートされない不透明型など)を含めることはできません。

  • サポートされるADT列のある表では、スカラー最上位列でのみ構成されているプライマリ・キーが存在する必要があります(スカラーADT属性はこうした候補キーの一部にはなりません)。

• BINARY_DOUBLE

• BINARY_FLOAT

• BasicFileおよびSecureFileとして格納されるBLOB、CLOBおよびNCLOB。SecureFilesは、圧縮、暗号化または重複除外できます。SecureFileサポートには、11.2以上の互換性で動作するプライマリ・データベースが必要です。「SecureFile LOBのサポート」を参照してください

• CHAR

• DATE

• INTERVALYEARTOMONTH

• INTERVALDAYTOSECOND

• 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を実行する関数コールを含む文をサポートしません。

ノート:

Oracle Database 12cリリース1 (12.1)現在、COMPATIBLE初期化パラメータを12.0以降に設定し、MAX_STRING_SIZE初期化パラメータをEXTENDEDに設定した場合、VARCHAR2、NVARCHAR2およびRAWデータ型の最大サイズは32 KBに増加しました。ロジカル・スタンバイ・データベースでは、ほとんどの場合、この増加したサイズがサポートされます。既知の制限については、「プライマリ・データベース内の表の行が一意に識別できることの確認」を参照してください。

C.1.1.1 互換性要件

これらの機能に対するSQL Applyサポートでは、プライマリ・データベースに対する互換性要件があります。

• マルチバイトのCLOBサポートには、10.1以上の互換性で動作するプライマリ・データベースが必要です。

• LOBおよびオーバーフローなしのIOTサポートには、10.1以上の互換性で動作するプライマリ・データベースが必要です。

• LOBおよびオーバーフローありのIOTサポートには、10.2以上の互換性で動作するプライマリ・データベースが必要です。

• TDEサポートには、11.1以上の互換性で動作するプライマリ・データベースが必要です。

• 基本圧縮および高度な行圧縮には、11.1以上の互換性で動作するプライマリ・データベースが必要です。

• ハイブリッド列圧縮サポートは、基礎となるストレージ・システムに依存します。

関連項目:

• ハイブリッド列圧縮の詳細は、『Oracle Database概要』を参照してください。

C.1.1.2 不透明型の制限

これらは、不透明型に関する制限事項です。

• インスタンスにユーザー定義の不透明データ型またはBFILEが格納されないかぎり、SYS.ANYDATAはサポートされます。

• SYS.ANYDATASET、SYS.ANYTYPEおよびユーザー定義の不透明型はサポートされていません。

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

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

表にサポートされていない次のデータ型が含まれている場合、SQL Applyを実行しても表全体が無視されます。(ネイティブのREDOベースのサポートが欠如したデータ型のサポートの詳細は、「ネイティブREDOサポートが欠如したデータ型のサポート」を参照してください。)

• ROWID、UROWID

  論理UROWID列のみがサポートされます。非論理UROWIDは実行時に検出され、DMLがスキップされて、トレース・メッセージがレポート・ファイルに書き込まれます。

• ネストされた表

• ネストされた表のあるオブジェクト

• ID列

C.2 ネイティブREDOサポートが欠如したデータ型のサポート

拡張データ型サポート(EDS)機能では、ネイティブなREDOベースのサポートが欠如した特定のデータ型をサポートするためのロジカル・スタンバイ用のメカニズムが提供されます。

ノート:

Oracle Database 18c以降では、拡張データ型サポート(EDS)は非推奨になりました。EDSでサポートされているすべてのOracleデータ型がロジカル・スタンバイまたはOracle GoldenGateでネイティブにサポートされるようになりました。

たとえば、SDO_GEOMETRY列を含む表はEDSを使用してレプリケートできます。(ソース表には主キーがある必要があります。)

DBA_LOGSTDBY_EDS_SUPPORTEDビューを問い合せて、EDSの候補の表を探すことができます。

C.3 透過的データ暗号化(TDE)のサポート

Oracle Data Guard SQL Applyを使用すると、透過的データ暗号化(TDE)を有効に設定したプライマリ・データベースにデータ保護を提供できます。

ロジカル・スタンバイ・データベースを使用し、高度なセキュリティ要件を伴うアプリケーションにデータ保護を提供する場合は、次のことを考慮してください。

• サーバーが保持するキーを使用する透過的データ暗号化が指定された表は、プライマリ・データベースとスタンバイ・データベースの両方が11.1以上の互換性レベルで稼働している場合のロジカル・スタンバイ・データベースで複製されます。

• ハードウェア・セキュリティ・モジュールの下での透過的データ暗号化は、Oracle Database 11gリリース2 (11.2)以降のロジカル・スタンバイ・データベースではサポートされません。

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

1. 暗号化されたREDOレコードを変換するには、透過的データ暗号化キーを含むオープン・ウォレットへのアクセス権がSQL Applyに必要です。そのため、キーを含むウォレットの作成後に、そのウォレットをプライマリ・データベースからスタンバイ・データベースにコピーする必要があります。

2. ウォレットは、マスター・キーが変更されるたびに、プライマリ・データベースからロジカル・スタンバイ・データベースにコピーする必要があります。

3. ロジカル・スタンバイ・データベースでは、プライマリ・データベースから暗号化された表をレプリケートしている間、マスター・キーをREKEY(キーの変更)しないことをお薦めします。これは、暗号化されたREDOレコードの検出時にSQL Applyが停止する原因になります。

4. ロジカル・スタンバイ・データベースでは、レプリケートされた表の暗号化キーをREKEYできます。このためには、REKEYコマンドを発行する前にガード設定をNONEにして低くする必要があります。

5. レプリケートされた暗号化された表では、プライマリ・データベースで使用された暗号化方式とは異なる方式を列に対して使用できます。たとえば、HR.EMPLOYEES表のSALARY列がプライマリ・データベースでAES102暗号化アルゴリズムを使用して暗号化される場合、ロジカル・スタンバイではAES256暗号化アルゴリズムを使用して暗号化することができます。あるいは、ロジカル・スタンバイ・データベースでは、SALARY列を暗号化しないままにしておくことも可能です。

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

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'); 

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

Oracle Database 11gでは、ロジカル・スタンバイによってDBMS_RLSおよびDBMS_FGA PL/SQLパッケージで提供されているセキュリティ環境を自動的にレプリケートすることができます。

このサポートによりセキュリティ環境が透過的に維持されるため、サーバーをスタンバイにフェイルオーバーする際に、セキュリティに配慮した管理の手間が軽減されます。また、プライマリ・データに適用されたアクセス・コントロール・ポリシーを自動的にスタンバイに必ず転送し、スタンバイ・データに同等な保護レベルを付与することができます。スタンバイ・サーバーを11gで新しく作成すると、このレプリケーションはデフォルト設定で有効化されますが、それ以外の場合はDBAが適宜有効化する必要があります。

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

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

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

行レベルのセキュリティは、仮想プライベート・データベース(VPD)とも呼ばれる機能で、表、ビューまたはシノニムにアクセスするときに、セキュリティの粒度をFINEレベルにまで強化します。

VPDポリシーで保護された表、ビューまたはシノニムに直接または間接的にユーザーがアクセスすると、サーバーはそのユーザーのSQL文を動的に変更します。この変更では、セキュリティ・ポリシーを実装するファクンションによって戻されるWHERE条件(述語)が作成されます。文は、ファンクションで表される条件あるいはファンクションによって戻される条件を使用して、ユーザーに対して透過的に、動的に変更されます。VPDポリシーは、SELECT、INSERT、UPDATE、INDEXおよびDELETE文に適用されます。VPDは、DBMS_RLSパッケージを使用してセキュリティ・ポリシーを適用すると実装されます。

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

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

きめ細かい監査により、select文を監査することができます。

DBMS_FGAパッケージでは、表にアクセスするすべてのselect文を、アクセスしたデータとともに取得することができます。FGAポリシーは特定の列、または指定された述語戻り値がTRUEの行を戻す、select文にも適用することができます。

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

C.5.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.6 Oracle Label Security

Oracle Database 12cリリース2 (12.2)以降では、Oracle Label Security (OLS)を使用するデータベースを、Oracle Data Guardデータベースのローリング・アップグレードを一時ロジカル・スタンバイ・データベースおよびPL/SQLパッケージDBMS_ROLLINGとともに使用して、新しいOracleデータベースのリリースおよびパッチ・セットにアップグレードできます。

C.7 Oracle Database Vault

Oracle Data Guardのローリング・アップグレードは、Oracle Database Vaultを使用するデータベースをサポートしています。

Oracle Database 12cリリース2 (12.2.0.1)以降では、Oracle Database Vaultを使用するデータベースを、Oracle Data Guardデータベースのローリング・アップグレードを一時ロジカル・スタンバイおよびPL/SQLパッケージDBMS_ROLLINGとともに使用して、新しいOracleデータベースのリリースおよびパッチ・セットにアップグレードできます。

C.8 Oracle E-Business Suite

ロジカル・スタンバイ・データベースは、サポートされていないデータ型を含む表があるため、Oracle E-Business Suite実装を完全にはサポートしていません。

しかし、SKIPルールを使用して、E-Business Suiteスキーマと表のサブセットを複製し、アプリケーションをロジカル・スタンバイにオフロードすることは可能です。

関連項目:

Oracle E-Business Suiteでのロジカル・スタンバイ使用の詳細は、http://support.oracle.comのMy Oracle Supportノート851603.1を参照してください。

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

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

• クラスタ表(索引クラスタおよびヒープ・クラスタを含む)

• 索引構成表(オーバーフロー・セグメントを含むパーティション化および非パーティション化)。

• ヒープ構成表(パーティション化および非パーティション化)

• 高度な行圧縮および基本表圧縮。どちらのオプションでも、プライマリ・データベースの互換性設定が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

  • INTERVALYEARTOMONTH

  • INTERVALDAYTOSECOND

  関連項目:

  • プライマリ・データベース内の表の行が一意に識別できることの確認

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

表にこれらのデータ型しか含まれない場合、ロジカル・スタンバイではサポートされません。

• LOB (CLOB、NCLOB、BLOB)

• LONG

• LONG RAW

• OBJECT TYPE

• COLLECTIONS

• XML

• VARCHAR2 (宣言済の列の長さ> 4000バイト)

• NVARCHAR2 (宣言済の列の長さ> 4000バイト)

• RAW (宣言済の列の長さ> 4000バイト)

関連項目:

• SecureFile LOBのサポート

• プライマリ・データベース内の表の行が一意に識別できることの確認

C.10.1 パーティション化の結果としてのサポートされない表

ロジカル・スタンバイでは、システム・パーティション化または参照パーティション化を使用する表はサポートされません。

可能な場合、DBA_LOGSTDBY_UNSUPPORTEDビューのATTRIBUTES列には、SQL Applyによって表がサポートされない理由が表示されます。表構造そのものがSQL Applyでサポートされていない場合(たとえば、表がシステム・パーティション化されている)、ATTRIBUTES列はNULLになることがあります。

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

サポート対象および対象外のPL/SQLパッケージについては、次の考慮事項に注意してください。

• サポートされるPL/SQLパッケージ

• サポートされないPL/SQLパッケージ

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

関連項目:

Oracle PL/SQL供給パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。

C.11.1 サポートされる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';

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

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

この種のパッケージの例には、DBMS_JAVA、DBMS_REGISTRY、DBMS_ALERT、DBMS_SPACE_ADMIN、DBMS_REFRESHおよびDBMS_AQがあります。

また、DBMS_RESOURCE_MANAGERパッケージはフィジカル・スタンバイのローリング・アップグレードにはサポートされません。

C.11.2.1 DBMS_JOBのサポート

DBMS_JOBに固有のサポートが用意されています。プライマリ・データベースで作成されたジョブはスタンバイ・データベースで複製されますが、このスタンバイがスタンバイ・ロールを維持しているかぎり、実行されません。

スイッチオーバーまたはフェイルオーバーが発生すると、元のプライマリ・データベースでスケジュールされていたジョブの実行は、新規のプライマリ・データベースで自動的に開始されます。

ロジカル・スタンバイでジョブを作成することもできます。これらのジョブは、ロジカル・スタンバイがスタンバイ・ロールを維持している間のみ実行されます。

C.11.2.2 DBMS_SCHEDULERのサポート

スタンバイ・データベースでジョブを実行できるように、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ブロック内で使用しても、効果がありません。)

C.11.3 ロジカル・スタンバイでのXMLおよびXDB 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開発者ガイド』を参照してください。

C.11.3.1 DBMS_XMLSCHEMAスキーマ

DBMS_XMLSCHEMAパッケージ内の特定のプロシージャは、ロジカル・スタンバイではサポートされず、レプリケートできません。

ロジカル・スタンバイは、これらのプロシージャへのコールを検出すると、これらのコールに対してユーザーが補正アクションを実行できるように停止します。これらのサポートされないプロシージャの処理に使用できる代替方法の詳細は、「サポートされないPL/SQLプロシージャの処理」から「順序に依存するサポートされないPL/SQLの補正」を参照してください。

• COPYEVOLVE

• INPLACEEVOLVE

• COMPILESCHEMA

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

• GENERATEBEAN

C.11.3.2 DBMS_XMLINDEXパッケージ

DBMS_XMLINDEXパッケージ内のプロシージャはすべてサポートされています。ただし、次のものは除きます。

• DBMS_XMLINDEX.REGISTERPARAMETER

• DBMS_XMLINDEX.MODIFYPARAMETER

• DBMS_XMLINDEX.DROPPARAMETER

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

サポートされないPL/SQLプロシージャの処理には、2つのオプションがあります。

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

C.11.3.4 サポートされない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を手動でレプリケートするための一般的な手順は、これらのステップに従います:

1. サポートされないPL/SQLをプライマリ・データベースで実行します。

2. スタンバイ・データベースでサポートされないPL/SQLが検出され、適用が停止します。

3. DBA_LOGSTDBY_EVENTS表を調べ、適用が停止した原因を確認します。

4. スタンバイで、サポートされないPL/SQLについてなんらかの補正アクションを実行します。

5. スタンバイで適用を再開します。

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

前述のアプローチは有効ですが、すべての場合に使用できるわけではありません。他のトランザクションとの相対的なPL/SQL実行時間が重要ではない場合にかぎり、安全に使用することができます。使用すべきではない場合の例として、DBMS_XMLSCHEMA.copyEvolveがあげられます。DBMS_XMLSCHEMA.copyEvolveプロシージャはスキーマを進化、または変化させ、列の追加または削除によって表を変更することがあり、XMLドキュメントの有効性/無効性も変更します。

ロジカル・スタンバイでのこのプロシージャの実行タイミングは非常に重要です。このプロシージャがプライマリ・データベースで実行されたことがわかった場合、ロジカル・スタンバイ上で適用を停止したタイミングが唯一安全です。

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

1. プライマリで依存表への変更をQUIESCEさせます。

2. プライマリでCopyEvolveを実行します。

3. スタンバイでのCopyEvolve PL/SQLの停止を待機します。

4. スタンバイで補正CopyEvolveを適用します。

5. スタンバイで適用を再開します。

例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.12 サポートされない表

ロジカル・スタンバイ・データベースを作成する前に、プライマリ・データベースでサポートされないデータベース・オブジェクトを特定することが重要です。

プライマリ・データベースでサポートされないデータ型や表に対する変更は、ロジカル・スタンバイ・データベース上のSQL Applyで自動的にスキップされるためです。また、エラー・メッセージは返されません。

ノート:

Oracle Databaseリリース12.2以降では、新しいタイプまたは機能(長い識別子を含む)は、DBMS_ROLLINGパッケージまたはOracle Golden Gateを使用した論理レプリケーションでのみサポートされます。

ノート:

ソートされたハッシュ・クラスタ表は、ロジカル・スタンバイ・データベースではサポートされていません。

ロジカル・スタンバイのサポートの観点から、データベースには次の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ビューを問合せます。

C.12.1 ローリング・アップグレード中にサポートされない表

ローリング・アップグレードを実行する前に、含まれるいずれかの表にロジカル・スタンバイ・データベースでサポートされないデータ型が含まれるかどうかを判別してください。

これを行うには、実行中のローリング・アップグレードのタイプに応じて、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リファレンス』を参照してください。

C.12.2 PL/SQLファンクションで実行されたDMLの結果としてのサポートされない表

サポートされている表での挿入または更新DML操作中に、表外の列(LOB、XMLTypeまたはADT)がPL/SQLファンクションを介して変更され、次にそのファンクションがその実行の途中で別の表でDMLを実行する場合、生成されるREDOパターンはLogMinerでサポートされません。

結果としてこのようなワークロードのREDOは、LogMinerを使用して確実にマイニングすることはできません。

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

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

影響を受ける文は次のとおりです。

• ALTER DATABASE
• ALTER MATERIALIZED VIEW
• ALTERMATERIALIZEDVIEWLOG
• ALTER SESSION
• ALTER SYSTEM
• CREATE CONTROL FILE
• CREATE DATABASE
• CREATE DATABASE LINK
• CREATE PFILE FROM SPFILE
• CREATE MATERIALIZED VIEW
• CREATEMATERIALIZEDVIEWLOG
• CREATE SCHEMA AUTHORIZATION
• CREATE SPFILE FROM PFILE
• DROP DATABASE LINK
• DROP MATERIALIZED VIEW
• DROPMATERIALIZEDVIEWLOG
• EXPLAIN
• LOCK TABLE
• PURGE DBA_RECYCLEBIN
• PURGE INDEX
• SET CONSTRAINTS
• SET ROLE
• SET TRANSACTION

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

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

DBMS_LOGSTDBY.SKIPプロシージャには、オプションのキーワードがいくつかあります。

表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
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脚注1	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 SEGMENT	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 ALTER 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

^脚注1

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

関連項目:

SKIPおよびUNSKIPオプションの使用例を示した次の各項

• DBMS_LOGSTDBY.SKIPによる特定のスキーマ・オブジェクトに対する変更の防止

• DDL文のスキップ・ハンドラの設定

• ロジカル・スタンバイ・データベースの変更

• ロジカル・スタンバイ・データベースでの表の追加または再作成

C.14.1 DBLINKSを使用するDDL文

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

このような文の例を次に示します。

CREATE TABLE tablename AS SELECT * FROM bar@dblink

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

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

ロジカル・スタンバイでは、監査およびファイングレイン監査がサポートされています。

プライマリ・データベースでAUD$およびFGA_AUD$表に対して行われた変更は、ロジカル・スタンバイにレプリケートされます。

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

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

C.15 分散トランザクションおよびXAのサポート

複数の異なる方法を使用して分散トランザクションを実行できます。

• データベース・リンクを使用した調整方法により複数のデータベース内の表を変更します。

• 提供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以上でのみサポートされています。

C.16 SecureFile LOBのサポート

SecureFile LOBは、データベースの互換性レベルが11.2以降に設定されている場合にサポートされます。

プライマリ・データベースでは、SecureFile LOB列で透過的なデータ暗号化およびデータ圧縮を使用できます。

SecureFile LOB列の重複除外およびSecureFile Database File System (DBFS)操作は完全にサポートされています。

SQL Applyがサポートされていない操作によって生成されたREDOを検出すると、「ORA-16211: サポートされていないレコードが、アーカイブREDOログで見つかりました。」エラーとともに停止します。続行するには、DBMS_LOGSTDBY.SKIPを使用した該当する表にスキップ・ルールを追加し、SQL Applyを再開します。

C.17 データベース・ファイル・システム(DBFS)のサポート

データベース・ファイル・システム(DBFS)では、データベース表に格納されたファイルおよびディレクトリの上に標準ファイル・システム・インタフェースが作成されるため、データベースに格納されたファイルへのアクセスおよび管理が簡単になります。

ロジカル・スタンバイでは、データベース・ファイル・システム(DBFS)がサポートされています。DBFSの詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

C.18 文字セットに関する考慮事項

文字セットについては、注意が必要な考慮事項があります。

• プライマリ・データベースとロジカル・スタンバイ・データベースでの使用文字セットが異なるData Guard構成を持つことはサポートされません。

• マルチテナント・コンテナ・データベース(CDB)が混合文字セットを持つ構成は、ローリング・アップグレードにDBMS_ROLLINGを使用するときにのみサポートされます。混合文字セットは、CDB$ROOTとCDBの1つ以上のプラガブル・データベース(PDB)が異なる文字セットを持つことを意味します。

C.19 DBMS_ROLLINGアップグレードの場合でのみ使用可能な追加のPL/SQLパッケージのサポート

特定のパッケージのレプリケーションは、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開発者ガイド』を参照してください。)

関連項目:

• DBMS_ROLLINGを使用したローリング・アップグレードの実行

• 軽量セキュリティ・パッケージの詳細は、『Oracle Database Real Application Security管理者および開発者ガイド』を参照してください。

• DBMS_SCHEDULER、XDB関連およびDBFS関連パッケージの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。