双方向レプリケーション
双方向構成では、各システムのトランザクション変更をもう一方のシステムにレプリケーションすることをサポートするために、ソースおよびターゲットの両方のシステムにExtractおよびReplicatプロセスがあります。この構成をサポートするには、適用されたトランザクションが再キャプチャされてソースに送られることが繰り返されることのないよう、各ExtractがローカルのReplicatで適用されたトランザクションをフィルタできる必要があります。さらに、各システムで値の不整合が起こらないようにAUTO_INCREMENT列も設定する必要があります。
トピック:
双方向レプリケーションの前提条件
トピック:
双方向ループ検出の有効化
Oracle GoldenGateの双方向実装には、1つのソース・データベースのExtractが、別のソース・データベースからReplicatによって送信されたトランザクションを再取得しないように、ループ検出が必須です。
CDC Extractキャプチャ方法の場合、デフォルトでは、Replicatの配信先の表に対してサプリメンタル・ロギングが有効なかぎり、Extractが構成されているデータベースにReplicatによってコミットされたトランザクションは、Replicatからのトランザクションを再取得します。
Replicatによって適用されるトランザクションの再取得を無視するには、CDC Extractに対してTRANLOGOPTIONS FILTERTABLEパラメータを使用する必要があります。フィルタリング表として使用する表は、Replicatのために作成が必要なOracle GoldenGateチェックポイント表です。
ノート:
双方向および複数方向レプリケーションがサポートされるのは、クラシックReplicatおよび調整Replicatのみです。パラレルReplicatではサポートされません。
フィルタ表を作成してサプリメンタル・ロギングを有効化する手順:
-
各ソース・データベースで、Replicatで使用するチェックポイント表が作成されていることを確認します。たとえば:
ADD CHECKPOINTTABLE ggadmin.oggcheck -
チェックポイント表のサプリメンタル・ロギングを有効にします。たとえば:
ADD TRANDATA ggadmin.ggcheckpoint ALLCOLS -
チェックポイント表の情報を使用してReplicatが作成されていることを確認します。
ADD REPLICAT reptgt1, EXTTRAIL ./dirdat/e2, CHECKPOINTTABLE ggadmin.ggcheckpoint -
フィルタリング表用のReplicatのチェックポイント表を使用して、
IGNOREREPLICATES(デフォルトでオン)およびFILTERTABLEパラメータにより各Extractを構成します。TRANLOGOPTIONS IGNOREREPLICATES TRANLOGOPTIONS FILTERTABLE ggadmin.ggcheckpointノート:
Oracle GoldenGate for PostgreSQLでは、Extractごとに1つの
FILTERTABLE文のみがサポートされるため、複数方向の実装では、各Replicatが配信先のデータベース内の同じチェックポイント表を必ず使用するようにします。
親トピック: 双方向レプリケーションの前提条件
アクティブ/アクティブ構成の考慮事項
アクティブ/アクティブ構成では、次の点を考慮する必要があります。また、使用中のデータベース・タイプに対応するOracle GoldenGateのインストレーションおよび構成のドキュメントを参照し、双方向構成をサポートする上で他になんらかの制限や要件がないか確認してください。
アプリケーション設計
アクティブ/アクティブ型のレプリケーションを使用する場合は、タイムゾーンを両方のシステムで同じにする必要があるため、そのタイムスタンプベースの競合解決および検出を動作できます。
アクティブ/アクティブ型のレプリケーションは、市販のパッケージ・ビジネス・アプリケーションでサポートされていない場合、それらのアプリケーションで使用することは推奨されません。これらのアプリケーションで障害となるのは次の点です。
-
パッケージ・アプリケーションには、Oracle GoldenGateでサポートされないオブジェクトおよびデータ型が含まれる可能性があります。
-
パッケージ・アプリケーションでは、ユーザーが制御できない自動DML操作が実行される可能性がありますが、その操作がOracle GoldenGateによってレプリケートされると、Replicatによる適用時に競合が発生します。
-
通常、ユーザーは、アクティブ/アクティブ型のレプリケーションに必要とされる変更を行うためのデータ構造を制御できません。
親トピック: アクティブ/アクティブ構成の考慮事項
キー
競合を正確に検出するためには、すべてのレコードは一意の非NULL識別子である必要があります。可能であれば、主キーを作成してください。不可能な場合は、一意キーを使用するか、MAPパラメータおよびTABLEパラメータのKEYCOLSオプションを使用して代替キーを作成します。一意の識別子がないと、Oracle GoldenGateでは、WHERE句で有効なすべての列が使用されますが、表に大量の列が含まれる場合、これによってパフォーマンスが低下します。
データ整合性を保持してエラーを防止するため、特定の表で使用するキーには次のことが求められます。
-
その特定の表が存在するすべてのデータベースで同じ列が含まれる必要があります。
-
データベース間の対応する行の各セットで同じ値が含まれる必要があります。
親トピック: アクティブ/アクティブ構成の考慮事項
データベース生成による値
双方向構成では、データベース生成による順序値(Oracle順序など)をレプリケートしないでください。値の範囲は、重複しないように各システムで異なっている必要があります。たとえば、2つのデータベースが存在する環境では、一方のサーバーで偶数値を生成し、他方で奇数値を生成します。n個のサーバーが存在する環境では、各キーを異なる値で開始し、環境内のサーバーの数を単位として値を増分します。この方法は、すべてのタイプのアプリケーションまたはデータベースに使用できるわけではありません。アプリケーションが対応している場合、値に位置識別子を追加して強制的に一意性を確保できます。
親トピック: アクティブ/アクティブ構成の考慮事項
データベース構成
データベースの1つを、信頼できるソースとして指定する必要があります。これは、初期同期フェーズや必要な後続のすべての再同期時に他のデータベースの導出元になるプライマリ・データベースおよびそのホスト・システムです。信頼できるソースのデータは定期的にバックアップしてください。
親トピック: アクティブ/アクティブ構成の考慮事項
データ・ループの防止
双方向構成では、あるシステムから別のシステムにレプリケートされたSQL変更は、最初のシステムに再度レプリケートされないようにする必要があります。そうしないと、システム間でデータの移動が繰り返され、次の例のように無限ループに陥ります。
-
ユーザー・アプリケーションがシステムAのある行を更新します。
-
Extractは、システムAでその行を抽出してシステムBに送信します。
-
Replicatは、システムBでその行を更新します。
-
Extractは、システムBでその行を抽出してシステムAに戻します。
-
その行がシステムAに適用されます(2回目)。
-
このループが無限に継続します。
データのループバックを防止するには、状況に応じて次の処理を行う必要があります。
-
Replicatによって生成されるSQL操作を取得しないようにします。ただし、Extractのパラメータ・ファイルに指定されているオブジェクトがビジネス・アプリケーションに含まれる場合は、それらのビジネス・アプリケーションによって生成されるSQL操作の取得を有効化します。
-
ローカルReplicatトランザクションを識別します(Extractプロセスでそれらのトランザクションを無視するため)。
Replicatトランザクションの識別
Replicatトランザクションを識別するようにExtractを構成するには、Extractがデータを取得するデータベースについて、次の手順に従います。
トピック:
DB2 z/OS
Extractのパラメータ・ファイルで次のパラメータ文を使用して、Replicatユーザー名を識別します。
TRANLOGOPTIONS EXCLUDEUSER user
このパラメータ文によって、このユーザーにより生成されるすべてのDDLおよびDMLトランザクションがReplicatトランザクションとしてマークされます。ユーザー名は、Extractによって読み取られるトランザクション・レコードに含まれます。
親トピック: Replicatトランザクションの識別
MySQL
Extractのパラメータ・ファイルで次のパラメータ文を使用して、Replicatのチェックポイント表の名前を識別します。
TRANLOGOPTIONS FILTERTABLE table_name
Replicatは、その各トランザクションの終了時に、チェックポイント手順の一環としてチェックポイント表にチェックポイントを書き込みます。(これは、ADD CHECKPOINTTABLEコマンドを使用して作成される表です。)各Replicatトランザクションにこの表への書込みが含まれるため、この表を使用して双方向構成のReplicatトランザクションを識別できます。FILTERTABLEによってチェックポイント表の名前を識別し、その表に対する操作が含まれるトランザクションをExtractで無視するようにします。
親トピック: Replicatトランザクションの識別
PostgreSQLおよびSQL Server
Extractのパラメータ・ファイルで次のパラメータ文を使用して、Replicatのチェックポイント表の名前を識別し、ADD TRANDATAコマンドによるサプリメンタル・ロギングに対してReplicatのチェックポイント表が有効になっていることを確認します。
TRANLOGOPTIONS FILTERTABLE table_name
Replicatは、その各トランザクションの終了時に、チェックポイント手順の一環としてチェックポイント表にチェックポイントを書き込みます。(これは、ADD CHECKPOINTTABLEコマンドを使用して作成される表です。)各Replicatトランザクションにこの表への書込みが含まれるため、この表を使用して双方向構成のReplicatトランザクションを識別できます。FILTERTABLEによってチェックポイント表の名前を識別し、その表に対する操作が含まれるトランザクションをExtractで無視するようにします。
親トピック: Replicatトランザクションの識別
Oracle
Oracle環境でReplicatトランザクションを識別する方法は複数あります。Replicatがクラシックまたは統合モードである場合は、次のパラメータを使用します。
-
Replicatはデフォルトで00のタグを設定します。Replicatのパラメータ・ファイルで
SETTAGオプションを指定してDBOPTIONSを使用し、Replicatで設定されるタグを変更します。Replicatは、指定した値(これらのトランザクションをREDOストリーム内で識別)で適用されるトランザクションにタグ付けします。有効値は、16進数で構成される単一のTAG値です。
-
Extractパラメータ・ファイルで
TRANLOGOPTIONSパラメータをEXCLUDETAGオプションとともに使用します。Extractに関連付けられたログマイニング・サーバーは、SETTAG値のタグが付いたREDOを除外します。Replicatのパラメータ・ファイルで
SETTAGを設定する方法は次のとおりです。DBOPTIONS SETTAG 0935
Extractのパラメータ・ファイルで
EXCLUDETAGを設定する方法は次のとおりです。TRANLOGOPTIONS EXCLUDETAG 0935
複数のタグを除外する場合は、個別の
TRANLOGOPTIONS EXCLUDETAG文をそれぞれ指定する必要があります。
トランザクション名またはReplicatユーザーのUSERIDを使用して、Replicatトランザクションを識別することもできます。Extractの構成時に、どちらを無視するか選択できます。
親トピック: Replicatトランザクションの識別
Replicat操作の取得の防止
使用中のデータベースに応じて、Replicat操作を取得しないように明示的に指示する必要がある場合とない場合があります。
親トピック: 双方向レプリケーションの前提条件
Oracle: Replicatトランザクションの取得の防止
ReplicatによってOracleデータベースに適用されるSQLの取得を防止するには、TRANLOGOPTIONSパラメータをEXCLUDETAG tagオプションとともに使用します。このパラメータを使用すると、Extractプロセスは、指定されたREDOタグの付いたトランザクションを無視します。
タグ値の設定は、「Replicatトランザクションの識別」を参照してください。これはOracleの場合に推奨されるアプローチです。
親トピック: Replicat操作の取得の防止
Oracle Database以外: Replicatトランザクションの取得の防止
Replicatによって他のデータベース・タイプに適用されるSQLの取得を防止するには、次のパラメータを使用します。
-
GETAPPLOPS | IGNOREAPPLOPS: Replicat以外のビジネス・アプリケーションによって生成されたデータ操作(DML)を、Extractが特定の証跡またはファイルに書き込む内容に含めるかどうかを制御します。 -
GETREPLICATES | IGNOREREPLICATES: Replicatによって生成されたDML操作を、Extractが特定の証跡またはファイルに書き込む内容に含めるかどうかを制御します。
親トピック: Replicat操作の取得の防止
競合の管理
アクティブ/アクティブ構成では、統一された競合解決手順をすべてのシステムに用意しておく必要があります。競合は即座に識別され、可能なかぎり自動的に処理される必要がありますが、様々なビジネス・アプリケーションがこの処理に関する独自の要件セットを持っています。
Oracle GoldenGateは非同期ソリューションであるため、個別のシステム上にある同一のデータセットに対して(ほぼ)同時に変更が行われた場合、競合が発生する可能性があります。競合は、同時変更のタイミングが次の非同期状態のいずれかにつながる場合に発生します。
-
Replicatが、一意性整合性制約(
PRIMARY KEY制約やUNIQUE制約など)に違反する挿入操作または更新操作を適用すると、一意性競合が発生します。この競合タイプの例としては、2つの異なるデータベースから2つのトランザクションが発生し、各トランザクションが同じ主キー値で表に行を挿入する場合があげられます。 -
Replicatが、同じ行への別の更新と競合する更新を適用すると、更新競合が発生します。更新競合が発生するのは、異なるデータベースから生じた2つのトランザクションがほぼ同時に同じ行を更新した場合です。証跡レコードに格納されている古い値(変更前の値)とターゲット・データベース内の同じ行の現行値との間に差異があると、Replicatは更新競合を検出します。
-
2つのトランザクションが異なるデータベースから生じ、一方が行を削除するのと同時にもう一方が同じ行を更新または削除すると、削除競合が発生します。この場合、その行は存在せず、更新も削除もできません。主キーが存在しないため、Replicatは行を見つけられません。
たとえば、データベースAのユーザーAがある行を更新し、データベースBのユーザーBが同じ行を更新するとします。ユーザーAのトランザクションがデータベースBに同期されるより前にユーザーBのトランザクションが実行されると、レプリケートされたトランザクションで競合が発生します。
3つのデータベースが関与するさらに複雑な例を基に、順序にまつわるさらに複雑な競合について説明します。A、B、Cという3つのデータベースがあるとします。あるユーザーがデータベースAに行を挿入すると、その行はデータベースBにレプリケートされます。次に、別のユーザーがその行をデータベースBで変更すると、行の変更がデータベースCにレプリケートされます。Bからの行の変更が、データベースAからの行の挿入より前にデータベースCに到着した場合、Cは競合を検出します。
可能であれば、競合発生のすべての可能性を最小化または排除してください。そのいくつかの方法を次に示します。
-
各データベースで変更できる列を制限するようにアプリケーションを構成します。たとえば、地理的地域に基づいてアクセスを制限できます(異なる販売地域でその独自の顧客レコードのみを変更できるようにするなど)。別の例として、あるデータベースの顧客サービス・アプリケーションには顧客表の
NAME列とADDRESS列の変更のみを許可し、別のデータベースの財務アプリケーションにはBALANCE列の変更のみを許可することが可能です。どちらの例の場合でも、同じレコードの同時更新による競合は発生しません。 -
同期のレイテンシを最小限に抑えます。データベースAのユーザーAとデータベースBのユーザーBがほぼ同時に同じ行を更新しても、ユーザーBのトランザクションが完了する前にユーザーAのトランザクションがターゲット行にレプリケートされていれば、競合は回避されます。Oracle GoldenGateプロセスのパフォーマンス向上に関する推奨事項は、競合の管理を参照してください。
競合を回避するには、レプリケーション・レイテンシを最小限に抑える必要があります。競合が避けられない場合は、Oracle GoldenGateの競合検出および解決(CDR)機能または独自に開発した方法によって、競合をすみやかに特定し、可能なかぎり自動的に解決する必要があります。独自の方法は、SQLEXECとユーザー・イグジット機能を通じてOracle GoldenGate処理に統合できます。Oracle GoldenGateを使用した競合の処理の詳細は、「手動の競合検出および解決」を参照してください。
Oracleデータベースには、自動競合検出解決(CDR)機能があります。詳細は、「自動競合検出および解決」を参照してください。
親トピック: Replicat操作の取得の防止
MySQL: 双方向レプリケーション
双方向構成では、各システムのトランザクション変更をもう一方のシステムにレプリケーションすることをサポートするために、ソースおよびターゲットの両方のシステムにExtractおよびReplicatプロセスがあります。この構成をサポートするには、適用されたトランザクションが再キャプチャされてソースに送られることが繰り返されることのないよう、各ExtractがローカルのReplicatで適用されたトランザクションをフィルタできる必要があります。さらに、各システムで値の不整合が起こらないようにAUTO_INCREMENT列も設定する必要があります。
親トピック: 双方向レプリケーション
PostgreSQL: 双方向レプリケーション
双方向構成では、各システムのトランザクション変更をもう一方のシステムにレプリケーションすることをサポートするために、ソースおよびターゲットの両方のシステムにExtractおよびReplicatプロセスがあります。この構成をサポートするには、適用されたトランザクションが再キャプチャされてソースに送られることが繰り返されることのないよう、各ExtractがローカルのReplicatで適用されたトランザクションをフィルタできる必要があります。
親トピック: 双方向レプリケーション
アクティブ/アクティブ構成のためのDBFSの準備
Oracle Database File System (DBFS)が両方(またはすべて)のシステムで使用されているアクティブ/アクティブの双方向環境または多方向環境内で機能するよう、Oracle GoldenGateを構成するステップについて学習します。
トピック:
- サポートされている操作および前提条件
この項では、Oracle GoldenGateによってDBFS向けにサポートされているものを示します。 - 必要なパッチの適用
両方のデータベースにOracle Bug#9651229用のOracle DBFSパッチを適用します。 - これらのプロシージャで使用されている例
次のプロシージャでは、2つのシステムがあると仮定し、両方のシステムのDBFSユーザーがOracle GoldenGateとの同期が維持されている同一のDBFSファイル、ディレクトリおよびコンテンツを参照できるように、環境を構成します。 - DBFS順序番号のパーティション化
DBFSでは、内部順序番号ジェネレータを使用して、一意の名前と一意のIDが作成されます。 - DBFSファイル・システムの構成
DBFSファイル・システム操作をレプリケートするには、DML用の標準の双方向構成と同様の構成を使用します。 - ローカル・ピアとリモート・ピアの正しいマップ
DBFSファイル・システムの基礎となる表の名前は内部的および動的に生成されます。
親トピック: 双方向レプリケーション
サポートされている操作および前提条件
この項では、Oracle GoldenGateによってDBFS向けにサポートされているものを示します。
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順序番号のパーティション化
DBFSでは内部順序番号ジェネレータを使用して、一意の名前と一意のIDが作成されます。
これらのステップでは、データベース間で競合することがないように順序が識別可能な範囲にパーティション化されます。これが実行された後は、DMLの伝播中に名前、主キーまたはIDが競合することなく、他のDBFS操作(新しいファイル・システムと後続のファイル・システム操作の両方)を実行できます。
ノート:
Oracle Bug#9651229のパッチが適用される前、またはDBFS順序番号が調整される前に作成されたDBFSファイル・システムを伝播用に構成できますが、このドキュメントで説明されていない追加のステップが必要になります。古いファイル・システムを保持する必要がある場合は、Oracleサポートでサービス・リクエストをオープンしてください。
親トピック: アクティブ/アクティブ構成のためのDBFSの準備
DBFSファイル・システムの構成
DBFSファイル・システム操作をレプリケートするには、DML用の標準の双方向構成と同様の構成を使用します。
Oracle GoldenGateをDBFS向けに構成する際に従うガイドラインの一部は次のとおりです。
-
構造が同一である表の組合せを使用します。
-
各データベースが組合せのもう一方の表に対する書込み権限を持つように設定し、もう一方を読取り専用に設定します。たとえば:
-
ノード1がローカル表
t1に書き込み、これらの変更がノード2のt1にレプリケートされます。 -
ノード2がローカル表
t2に書き込み、これらの変更がノード1のt2にレプリケートされます。 -
ノード1では、
t2は読取り専用です。ノード2では、t1は読取り専用です。
-
DBFSファイル・システムでこのような表の組合せを簡単に行える理由は、次のとおりです。
-
DBFSファイル・システムの基礎となる表が同じ構造である。
-
これらの表は、高レベルのファイル・システム操作中に、従来型の単純なDMLにより変更される。
-
DBFS ContentAPIにより、読取り/書込みまたは読取り専用として修飾可能なマウント・ポイントを使用して、個別のDBFSストアのネームスペースを統一する方法が提供される。
次のステップでは、2つのDBFSファイル・システム(この場合はFS1およびFS2という名前)を作成し、必要に応じてそれらを読取り/書込みまたは読取りに設定します。
例11-8
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;
/
例11-9 ノード1
DECLARE
DBMS_DBFS_CONTENT.MOUNTSTORE('FS1', 'LOCAL');
DBMS_DBFS_CONTENT.MOUNTSTORE('FS2', 'REMOTE',
READ_ONLY => TRUE);
COMMIT;
END;
/
例11-10 ノード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文でマップされる必要があります。
例11-11
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')
;
例11-12 出力例: ノード1 (実際の表名は異なります。)
STORE NAME TABLE_NAME PTABLE_NAME ------------- ------------- ------------- FS1 SFS$_FST_100 SFS$_FSTP_100 FS2 SFS$_FST_118 SFS$_FSTP_118
例11-13 出力例: ノード2 (実際の表名は異なります。)
STORE NAME TABLE_NAME PTABLE_NAME ------------- ------------- ------------- FS1 SFS$_FST_101 SFS$_FSTP_101 FS2 SFS$_FST_119 SFS$_FSTP_119
例11-14 ノード1
TABLE [container.]schema.SFS$_FST_100 TABLE [container.]schema.SFS$_FSTP_100;
例11-15 ノード2
TABLE [container.]schema.SFS$_FST_119 TABLE [container.]schema.SFS$_FSTP_119;
例11-16 ノード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
例11-17 ノード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の準備