| Oracle® GoldenGate Oracle DatabaseのためのOracle GoldenGateのインストールおよび構成 12c (12.1.2) E49844-07 |
|
 前 |
 次 |
この付録では、Oracle Database File System (DBFS)が両方(またはすべて)のシステムで使用されているアクティブ/アクティブの双方向環境または多方向環境内で機能するよう、Oracle GoldenGateを構成する手順について説明します。
この付録の内容は次のとおりです。
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管理者ガイド』の指示に従って構成されています。
両方のデータベースに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がデータベースに存在しないことを示します。
次のプロシージャでは、2つのシステムがあると仮定し、両方のシステムのDBFSユーザーが、Oracle GoldenGateとの同期が維持されている同一のDBFSファイル、ディレクトリおよびコンテンツを参照できるように環境を構成します。これらの概念を、3つ以上のピア・システムのサポートに適用することも可能です。
DBFSでは内部順序番号ジェネレータを使用して、一意の名前と一意のIDが作成されます。これらの手順では、データベース間で競合することがないように順序が識別可能な範囲にパーティション化されます。これが実行された後は、DMLの伝播中に名前、主キーまたはIDが競合することなく、他のDBFS操作(新しいファイル・システムと後続のファイル・システム操作の両方)を実行できます。
各データベースにsysdbaとして接続します。
次の問合せを各データベースで発行します。
select last_number from dba_sequences where sequence_owner = 'SYS' and sequence_name = 'DBFS_SFS_$FSSEQ'
この問合せから、両方のシステム間でLAST_NUMBERの最大値を選択するか、いずれかのシステム上にある順序の現在値よりも大幅に大きい値を選択します。
次のプロシージャの両方で、この値(ここではプレースホルダとして"maxval"を使用)を置換します。これらのプロシージャでは、各システムはmyid=0およびmyid=1として論理的に索引付けされます。
ノード1
declare
begin
dbms_dbfs_sfs_admin.partition_sequence(nodes => 2, myid => 0, newstart => :maxval);
commit;
end;
/
ノード2
declare
begin
dbms_dbfs_sfs_admin.partition_sequence( nodes => 2, myid => 1, newstart => :maxval);
commit;
end;
/
|
注意: myidパラメータに指定された値の違いに注意してください。これが索引値の違いです。 |
3つ以上のデータベース間での多方向構成の場合は、次のように変更できます。
maxvalに設定されている最大値を適切に増加して調整し、すべてのノードでその値を使用します。
プロシージャ内のmyidの値として、最初のノードには0、2番目のノードには1、3番目には2、などというように異なる値を設定します。
(推奨) DBFS順序ジェネレータがパーティション化された後(された後でのみ)、各システム上に新しいDBFSファイル・システムを作成し、Oracle GoldenGateを使用したDML伝播にこれらのファイル・システムのみを使用します。F.5項「DBFSファイル・システムの構成」を参照してください。
|
注意: Oracle Bug#9651229のパッチが適用される前、またはDBFS順序番号が調整される前に作成されたDBFSファイル・システムを伝播用に構成できますが、このドキュメントで説明されていない追加の手順が必要になります。古いファイル・システムを保持する必要がある場合は、Oracleサポートでサービス・リクエストをオープンしてください。 |
DBFSファイル・システム操作をレプリケートするには、DML用の標準の双方向構成と同様の構成を使用します。
構造が同一である表の組合せを使用します。
各データベースが組合せのもう一方の表に対する書込み権限を持つように設定し、もう一方を読取り専用に設定します。例:
ノード1がローカル表t1に書き込み、これらの変更がノード2のt1にレプリケートされます。
ノード2がローカル表t2に書き込み、これらの変更がノード1のt2にレプリケートされます。
ノード1では、t2は読取り専用です。ノード2では、t1は読取り専用です。
DBFSファイル・システムでこのような表の組合せを簡単に行える理由は、次のとおりです。
DBFSファイル・システムの基礎となる表が同じ構造である。
これらの表は、高レベルのファイル・システム操作中に、従来型の単純なDMLにより変更される。
DBFS ContentAPIにより、読取り/書込みまたは読取り専用として修飾可能なマウント・ポイントを使用して、個別のDBFSストアのネームスペースを統一する方法が提供される。
次の手順では、2つのDBFSファイル・システム(この場合はFS1およびFS2という名前)を作成し、必要に応じてそれらを読取り/書込みまたは読取りに設定します。
次のプロシージャを実行して、2つのファイル・システムを作成します。(FS1およびFS2をご使用のストア名に置換します。)
次のプロシージャを実行し、各ファイル・システムに適切なアクセス権限を付与します。(FS1およびFS2をご使用のストア名に置換します。)
例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;
/
この例において、ノード1ではストアFS1は読取り/書込み、ストアFS2は読取り専用であるのに対し、ノード2ではストアFS1が読取り専用、ストアFS2が読取り/書込みというように逆になる点に注意してください。
また、読取り/書込みストアはローカルとしてマウントされ、読取り専用ストアはリモートとしてマウントされる点にも注意してください。これにより、読取り操作と書込み操作に対して、同一のネームスペースおよび同一のセマンティクスが各システム上のユーザーに提供されます。ローカルのパス名は変更できますが、リモートのパス名は変更できません。
DBFSファイル・システムの基礎となる表の名前は内部的および動的に生成されます。前の例に引き続き、次のものがあるとします。
2つのノード(この例ではノード1とノード2)。
各ノードに2つずつ、4つのストア(この例ではFS1とFS2)。
各ストアに2つずつ(tableとptable)、基礎となる8つの表。これらの表は、ExtractのTABLE文で識別、指定され、ReplicatのMAP文でマップされる必要があります。
各ファイル・システムの基礎となる表の名前を識別するには、次の問合せを発行します。(FS1およびFS2をご使用のストア名に置換します。)
例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')
;
出力は次の例のようになります。
Extractパラメータ・ファイルで次のTABLE文を作成することにより、Extractに対してローカルで読取り/書込みである表を識別します。(必要に応じて、ご使用のプラガブル・データベース名、スキーマ名および表名に置き換えます。)
Replicatパラメータ・ファイルに次のMAP文を作成することにより、各リモート・ファイル・システム上の変更を対応するローカル・ファイル・システムにリンク付けします。(ご使用のプラガブル・データベース名、スキーマ名および表名に置き換えます。)
例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;
このマッピングにより、ローカルの読取り/書込みソース表がキャプチャされ、リモートの読取り専用のピア表にレプリケートされます。
ノード1のFS1に行われたファイル・システムの変更は、ノード2のFS1に伝播されます。
ノード2のFS2に行われたファイル・システムの変更は、ノード1のFS2に伝播されます。
ファイル・システムへの変更は、データベースのDBFS ContentAPI (パッケージDBMS_DBFS_CONTENT)またはdbfs_clientマウントおよび従来のファイル・システム・ツールを使用して行うことができます。
すべての変更は両方のディレクトリに伝播されます。
各システム上のDBFSネームスペースの仮想ルートで、ユーザーは同一の内容を確認できます。
可変操作の場合は、各システム上の/localサブディレクトリを使用します。
読取り操作の場合は、ローカル・コンテンツとリモート・コンテンツのどちらを確認するかに応じて、/localか/remoteのいずれかのサブディレクトリを使用できます。
