内容は次のとおりです。
Oracle GoldenGateではDBFS向けに次のものがサポートされています。
DBFSオブジェクトに対する、CREATE
文以外のサポートされているDDL(TRUNCATE
、ALTER
など)。DBFSに対するCREATE
は、作成されたDBFSオブジェクトを保持するすべてのスキーマ同様、構成から除外される必要があります。CREATE
を除外するのは、DBFSのメタデータがSYSディクショナリ表(それ自体がデフォルトでOracle GoldenGateキャプチャから除外される)に正しく移入される必要があるためです。
DBFSファイル・システムの基礎となる表でのDMLのキャプチャおよびレプリケーション。
後続の手順では、Oracle GoldenGateがアクティブ/アクティブ構成をサポートするよう、正しく構成されていることを前提とします。つまり、次のように設定されている必要があります。
このガイド内の指示に従ってインストールされています。
『Oracle GoldenGate Windows and UNIX管理者ガイド』の指示に従って構成されています。
親トピック: アクティブ/アクティブ構成のためのDBFSの準備
両方のデータベースにOracle Bug#9651229用のOracle DBFSパッチを適用します。パッチがインストールされているかどうかを判断するには、次の問合せを実行します。
connect / as sysdba select procedure_name from dba_procedures where object_name = 'DBMS_DBFS_SFS_ADMIN' and procedure_name = 'PARTITION_SEQUENCE';
問合せでは1行が返されます。それ以外の場合は、パッチが適用された適切なバージョンのDBFSがデータベースに存在しないことを示します。
親トピック: アクティブ/アクティブ構成のためのDBFSの準備
次のプロシージャでは、2つのシステムがあると仮定し、両方のシステムのDBFSユーザーが、Oracle GoldenGateとの同期が維持されている同一のDBFSファイル、ディレクトリおよびコンテンツを参照できるように環境を構成します。これらの概念を、3つ以上のピア・システムのサポートに適用することも可能です。
親トピック: アクティブ/アクティブ構成のためのDBFSの準備
DBFSでは内部順序番号ジェネレータを使用して、一意の名前と一意のIDが作成されます。これらの手順では、データベース間で競合することがないように順序が識別可能な範囲にパーティション化されます。これが実行された後は、DMLの伝播中に名前、主キーまたはIDが競合することなく、他のDBFS操作(新しいファイル・システムと後続のファイル・システム操作の両方)を実行できます。
注意:
Oracle Bug#9651229のパッチが適用される前、またはDBFS順序番号が調整される前に作成されたDBFSファイル・システムを伝播用に構成できますが、このドキュメントで説明されていない追加の手順が必要になります。古いファイル・システムを保持する必要がある場合は、Oracleサポートでサービス・リクエストをオープンしてください。
親トピック: アクティブ/アクティブ構成のためのDBFSの準備
DBFSファイル・システム操作をレプリケートするには、DML用の標準の双方向構成と同様の構成を使用します。
構造が同一である表の組合せを使用します。
各データベースが組合せのもう一方の表に対する書込み権限を持つように設定し、もう一方を読取り専用に設定します。次に例を示します。
ノード1がローカル表t1
に書き込み、これらの変更がノード2のt1
にレプリケートされます。
ノード2がローカル表t2
に書き込み、これらの変更がノード1のt2
にレプリケートされます。
ノード1では、t2
は読取り専用です。ノード2では、t1
は読取り専用です。
DBFSファイル・システムでこのような表の組合せを簡単に行える理由は、次のとおりです。
DBFSファイル・システムの基礎となる表が同じ構造である。
これらの表は、高レベルのファイル・システム操作中に、従来型の単純なDMLにより変更される。
DBFS ContentAPIにより、読取り/書込みまたは読取り専用として修飾可能なマウント・ポイントを使用して、個別のDBFSストアのネームスペースを統一する方法が提供される。
次の手順では、2つのDBFSファイル・システム(この場合はFS1
およびFS2
という名前)を作成し、必要に応じてそれらを読取り/書込みまたは読取りに設定します。
例F-1
declare dbms_dbfs_sfs.createfile system('FS1'); dbms_dbfs_sfs.createfile system('FS2'); dbms_dbfs_content.registerStore('FS1', 'posix', 'DBMS_DBFS_SFS'); dbms_dbfs_content.registerStore('FS2', 'posix', 'DBMS_DBFS_SFS'); commit; end; /
例F-2 ノード1
declare dbms_dbfs_content.mountStore('FS1', 'local'); dbms_dbfs_content.mountStore('FS2', 'remote', read_only => true); commit; end; /
例F-3 ノード2
declare dbms_dbfs_content.mountStore('FS1', 'remote', read_only => true); dbms_dbfs_content.mountStore('FS2', 'local'); commit; end; /
親トピック: アクティブ/アクティブ構成のためのDBFSの準備
DBFSファイル・システムの基礎となる表の名前は内部的および動的に生成されます。前の例に引き続き、次のものがあるとします。
2つのノード(この例ではノード1とノード2)。
各ノードに2つずつ、4つのストア(この例ではFS1
とFS2
)。
各ストアに2つずつ(tableとptable)、基礎となる8つの表。これらの表は、ExtractのTABLE
文で識別、指定され、ReplicatのMAP
文でマップされる必要があります。
例F-4
select fs.store_name, tb.table_name, tb.ptable_name from table(dbms_dbfs_sfs.listTables) tb, table(dbms_dbfs_sfs.listfile systems) fs where fs.schema_name = tb.schema_name and fs.table_name = tb.table_name and fs.store_name in ('FS1', 'FS2') ;
例F-5 出力例: ノード1(実際の表名は異なります。)
STORE NAME TABLE_NAME PTABLE_NAME ------------- ------------- ------------- FS1 SFS$_FST_100 SFS$_FSTP_100 FS2 SFS$_FST_118 SFS$_FSTP_118
例F-6 出力例: ノード2(実際の表名は異なります。)
STORE NAME TABLE_NAME PTABLE_NAME ------------- ------------- ------------- FS1 SFS$_FST_101 SFS$_FSTP_101 FS2 SFS$_FST_119 SFS$_FSTP_119
例F-7 ノード1
TABLE [container
.]schema
.SFS$_FST_100 TABLE [container
.]schema
.SFS$_FSTP_100;
例F-8 ノード2
TABLE [container
.]schema
.SFS$_FST_119 TABLE [container
.]schema
.SFS$_FSTP_119;
例F-9 ノード1
MAP [container
.]schema
.SFS$_FST_119, TARGET [container
.]schema
.SFS$_FST_118; MAP [container
.]schema
.SFS$_FSTP_119, TARGET [container
.]schema
.SFS$_FSTP_118
例F-10 ノード2
MAP [container
.]schema
.SFS$_FST_100, TARGET [container
.]schema
.SFS$_FST_101;MAP [container
.]schema
.SFS$_FSTP_100, TARGET [container
.]schema
.SFS$_FSTP_101;
親トピック: アクティブ/アクティブ構成のためのDBFSの準備