SharePlexは、オンラインおよびアーカイブされたOracle REDOログからキャプチャします。SharePlexは、rawデバイス、ファイルシステムデバイス、およびASMインスタンスに格納されたREDOログとデータファイルをサポートしています。
レプリケーションがアクティブなときに、Captureプロセスが停止した場合（またはSharePlexユーザにより停止された場合）、CaptureはREDOログにその場所を記録し、再開時にその場所から続行します。ただし、以下の状況が発生した場合、CaptureはREDOログの代わりにアーカイブログを読み込む必要があります。
オンラインログが利用できないときにCaptureが中断されないように、ソースシステム上で、またカスケードレプリケーション戦略の中間システムなど、SharePlexがデータをキャプチャするあらゆるシステムでアーカイブログを有効にする必要があります。そのようにしないと、Captureの処理が完了する前にオンラインログがラップし、ソースデータとターゲットデータの再同期が必要になります。
Captureの問題を回避するには、以下のようにアーカイブロギングを構成し、より高速で中断のないレプリケーションをサポートします。
| 要件 | 説明 |
|---|---|
| 適切な時間圧縮と除去 | アーカイブログの圧縮または削除は、SharePlexの処理が終了するまで行わないでください。そのようにしないと、SharePlexはメッセージ「log wrap detected（ログのラップを検出しました）」を返し、データを処理できないため停止します。SharePlexの現在のログを確認するには、show captureコマンドを、ソースシステムでdetailオプシとともにsp_ctrlで指定し、実行します。現在のログより前に生成されたログも圧縮できます。 |
| デフォルト以外のアーカイブ場所を指定する | アーカイブログをデフォルトのOracleの場所以外に保存する場合は、SP_OCT_ARCH_LOCパラメーターをアーカイブログを含むディレクトリのフルパス名に設定します。REDOログがラップした場合、SharePlexはOracleのアーカイブ・ログ・リストでアーカイブログを検索します。SharePlexはここでアーカイブログを見つけられない場合、SP_OCT_ARCH_LOCパラメーターによって指定されたディレクトリを検索します。Captureが直接SP_OCT_ARCH_LOCの場所に移動し、Oracleログリストの読み取りをスキップするには、SP_OCT_CK_LOC_FIRSTを1に設定します。 |
| ログ管理プロセスを待機するようにCaptureを設定する | SP_OCT_ARCH_LOCを使用しているときに、自動化された方法でログをその場所に移動する場合、移動が完了するまで一定時間待つようにCaptureを設定できます。これにより、必要とするログがまだ利用できないためにCaptureが停止するのを防ぐことができます。Captureは待機し、ログをチェックし、まだ利用できなければ停止し、ログが利用可能になるまでチェックと停止を続けます。待機するようにCaptureを設定するには、SP_OCT_LOGWRAP_RESTARTパラメーターに、Captureで待機する秒数を設定します。レプリケーションのレイテンシを防ぐために、これらのプロセスを定期的に監視します。 |
| ターゲットでアーカイブロギングを無効にする | 高可用性またはピアツーピア戦略を除き、ターゲットシステムでのアーカイブロギングを無効にして、そのシステム上の不要なOracleアクティビティを排除することができます。 |
| ルートASMの場所にログを置かない |
データベースでASMを使用している場合、OracleのREDOログ（オンラインおよびアーカイブ）をASMルートディレクトリの下に配置することはできません。SharePlexは、その場所ではそれらを読み取ることができません。 |
| ASM rawデバイスの権限 | ASMの「oracle」ユーザには、rawデバイスにアクセスする権限がなければなりません。例えば、rawデバイスの権限に関するデフォルトがu:root g:diskの場合、「oracle」ユーザグループ「disk」を追加します。「grid」ユーザだけに権限を与えても不十分です。 |
理想的には、SharePlexがアーカイブログの読み取りを回避できるようにREDOログを設定する必要があります。ほとんどの場合、オンラインログの方がアーカイブログよりも読み込みが速くなります。オンラインREDOログに、アーカイブログからの処理を最小限に抑えるために十分な大きさと個数があることを確認します。少なくとも、数時間分のデータをラップせずに保持できるだけのREDOログ容量が必要です。
適切なオンラインログ設定をテストするには:
本番稼働前のテストでは、Captureがアーカイブログを読み取っているかどうかを、以下の方法で確認できます。
SharePlexが処理するログを、SHAREPLEX_ACTIDテーブルに対するクエリによって確認できます。
SQL> select seqno from splex.shareplex_actid
OracleのV$LOGテーブルに対するクエリによって、Oracleが書き込んでいるログを確認します。
SQL> select sequence# from v$log where status='CURRENT'
重要: OracleがREDOログを生成するペースよりもCaptureが遅れている場合、以下が考えられます。
最小のサプリメンタルロギングに加えて、プライマリキーと一意キーのサプリメンタルロギングの両方を有効にするか、レプリケーションの各テーブルに対して一意の列のサプリメンタル・ログ・グループを作成することを強くお勧めます。行を更新するためのキー列の値がREDOログにある場合、SharePlexではデータベースからそれらを取得する必要はありません。処理量の多いシステムでは、この結果、Readプロセスのパフォーマンスが大幅に向上します。SharePlexの機能によっては、プライマリキーと一意キーのロギングを有効にする必要があります。
| 注意:
テーブルの行IDを変更するALTER TABLE DDLコマンドは、レプリケーション対象のテーブルのプライマリキーまたは一意キーがログに記録されていない場合、後続のDML操作に影響を与える可能性があります。キーがログに記録されていない場合、SharePlexはrowidに基づいてその値を取得します。行IDを変更する操作（ALTER TABLE…MOVEなど）を行うと、その後のDML操作で間違ったキー値が使用される可能性があります。 |
このトピックでは、SharePlexでレプリケートするOracleデータベースオブジェクトの特定の特性を設定する方法について説明します。
SharePlexには、ターゲット上で変更している行がソース行と一致する正しい行であることを確認する方法が必要です。これは、キーとインデックスの使用によって1対1の関係を確保することで達成されます。
SharePlexは、レプリケートされるすべてのソーステーブルとターゲットテーブル、特に大きなテーブルやLONG列を含むテーブルにプライマリキーまたは一意キーがある場合に最も速く動作します。使用するキーを選択するときに、SharePlexは、利用できる最も適切なキー列を以下の優先度で使用します。
列数が最も少ない一意キー
パフォーマンスを最大化するために、プライマリキーと一意キーのサプリメンタルロギングを有効にすることをお勧めします。
テーブルが主キーまたは一意キーを持たない場合、またはOracleがSharePlexに対して間違った一意キーを記録する場合、構成ファイルを作成するときにキーとして使用する列をSharePlexに指定できます。これはキー定義と呼ばれ、設定ファイルで指定されます。詳細については、『SharePlex管理ガイド』の「一意キーの定義 」を参照してください。
キー定義に代わる方法として、一意性を確立する1つまたは複数の列に基づく一意のインデックスを作成または使用する方法があります。
プライマリキーと一意キーのサプリメンタルロギングが有効で、テーブルにプライマリキーがない場合、Oracleはログに記録する一意キーのタイプを決定する必要があります。テーブルに複数の一意キーがある場合、Oracleは使用する最適なキーを決定し、UPDATEごとにそれらの列の値をログに記録します。テーブルにどのタイプのキーもない場合、OracleはLONGまたはLOBではないすべての列をログに記録します。
SharePlexは、データのレプリケーションに使用するキーも特定しなければなりません。Oracleと同様に、SharePlexは次の順序でキーを選択します。
SharePlexによってレプリケートされるテーブルにプライマリキーがなく、複数の一意キーがある場合、Oracleがログに記録するキー列がSharePlexで要求されるものでない可能性があります。
SharePlexがテーブルのキーや一意のインデックスを検出できない場合、LONGとLOBを除くすべての列を使用してキーを構築します。このキーは内部で管理され、テーブル自体には作成されません。
これは好ましいオプションではありません。WHERE句の結果、Oracleは行を見つけるためにターゲットテーブルのフル・テーブル・スキャンを実行することになり、レプリケーションが著しく遅くなるからです。さらに、行の一意性を強制することはできません。
例えば、異なる行のLONG以外の列に同一の値が含まれていても、LONG列に異なる値が含まれる可能性がある場合は、テーブルの同期が外れていることをユーザやSharePlexが検出できないままになることがあります。以下の例でその問題を説明します。テーブルの行はLONG列を除いて同一であり、プライマリキーも一意キーもありません。
| 列A | 列B | 列C（LONG） |
|---|---|---|
| 10 | 20 | 100 |
| 10 | 20 | 200 |
| 10 | 20 | 300 |
ソースシステムのあるユーザが、最初の行の列Aを15に変更したと仮定します。変更をターゲットテーブルに適用するようにSQLステートメントを構築するときに、SharePlexは列AおよびBを使用してキーを構築し（UPDATEtablename SET ColumnA to 15 WHERE Column A = 10 and Column B = 20）、変更する行を特定します。この条件を満たす行は3つあるので、SharePlexは、間違った行に変更を投稿してしまう可能性があります。
キーがNULLを許容する場合、SharePlexは、UPDATEやDELETEに対して行の一意性を保証できないため、ターゲットシステム上で間違った行を変更する可能性があります。SharePlexがNULLを許可するキーを指定する方法を制御するには、SP_SYS_IN_SYNCパラメーターを設定します。詳細については『SharePlexリファレンスガイド』を参照してください。
SharePlexは、特別な設定なしにキー列の値の変更を処理します。ただし、キーにシーケンスを使用している場合、またその値が更新される可能性がある場合は、更新によってターゲットシステム上でキーが重複しないようにシーケンスを作成します。そのようにしないと、新しい値が使用されて操作が適用され、その値がターゲットテーブルの別の行のキーとして既に存在する場合、SharePlexは一意キー制約違反と非同期エラーを返します。このタイプのエラーは、式「x+n」（nは増分）を使用して値を更新する場合に発生する可能性があります。値「x+n」のいずれかが既存の値と等しくなる可能性があります。
以下は、キー列の値を1だけ大きくする例です。
Key_Col
1
4
5
7
SQL> update table X set a=a+1; commit
新しい値は以下のようになり、ターゲットシステムにレプリケートされます。
Key_Col
2
5
6
8
SharePlexは、操作をREDOログに記録する順序で更新します。
updatexseta=2wherea=1;（成功）
updatexseta=5wherea=4;(5の値が既に存在するため失敗)
updatexseta=6wherea=5;（成功）
updatexseta=8wherea=7;（成功）
Postがターゲット配列に使用するプリイメージ値は、ソースからレプリケートされる増加値と同じです。Oracleはこの操作を一意制約違反として拒否します。別の例として、AをBに更新し、BをCに更新するトランザクションがあります。
重要!ピアツーピアレプリケーションを使用する予定がある場合は、キーに関する要件がさらにあります。詳細については、『SharePlex管理ガイド』の「複数のピアデータベースを維持するためのレプリケーションの設定」のセクションを参照してください
レプリケーション環境では、インデックスを正しく使用することが重要です。インデックスはターゲットデータの完全性を維持します。
テーブルに外部キーがある場合は、外部キーの変更によってテーブルのフルスキャンが発生しないように、適切な列にインデックスが付けられていることを確認してください。
ターゲットテーブルにインデックスが多すぎる場合、Oracleは行の追加や削除に応じてインデックスをすべて更新しなければなりません。このため、レプリケーションを含むシステム全体の速度が遅くなります。インデックスの数を、最も有用性の高いものに限定することを検討してください。
ほぼ1つのタイプのDMLを実行するアプリケーションの場合、以下を考慮します。
何百万ものSQL操作を行う大規模なバッチジョブを実行する場合は、バッチジョブの前に不要なインデックスを削除し、最後にインデックスを再構築します。これにより、SharePlexの実行速度が上がり、その後、インデックスがより整理された状態になります。
パフォーマンスの理由から、Postプロセスがデータを適用している間は、ビットマップインデックスの使用を避けてください。これらのインデックスは、Postプロセスのパフォーマンスにマイナスの影響を及ぼす可能性があります。
ターゲットテーブルでビットマップインデックスを使用しなければならない場合は、Postによって適用されるトランザクションへの影響と、クエリに対するその利点を比較します。
注意: ビットマップインデックスのレプリケーションは推奨されません。ビットマップインデックスを持つテーブルを変更するたびに、インデックスは再構築されます。この再構築に関連するコスト（Oracleの時間とリソース）は、SQL UPDATEステートメントに追加されます。
ソースシステムでのトリガの起動によるDMLの変更は、REDOログに記録され、SharePlexによってターゲットシステムにレプリケートされます。その結果、同じトリガがターゲットシステムで起動され、同じDMLの変更（レプリケーションによって既に行われた）が開始された場合には非同期エラーが発生します。
例えば、ソースシステムでのテーブルAへのINSERTがテーブルBへのINSERTをトリガする場合、SharePlexは両方のINSERTをターゲットシステムにレプリケートします。Postプロセスは、ターゲットシステム上のTableAに最初のINSERTを適用し、TableBへのINSERTをトリガします。したがって、レプリケートされたINSERTをPostがTableBにポストしようとすると、一意キー違反が発生します。テーブルAに対してトリガが起動されたため、この行は既に存在しています。
トリガは、レプリケーション戦略に応じて以下のように処理できます。
| レプリケーション戦略 | ターゲットでのトリガの取り扱い方 |
|---|---|
|
高可用性 および ピアツーピア |
|
| レポート作成、データ共有、その他の基本的な一方向レプリケーション |
|
レプリケーション設定にないオブジェクトのトリガは、アクティブのままにしておくことができます。
トリガスクリプトの使用方法に関する重要な情報については、『SharePlexリファレンスガイド』を参照してください。
整合性制約はレプリケーションに影響を与えます。以下のガイドラインに従って確実に取り扱ってください。
外部キー制約は、ターゲットテーブルで無効にする必要があります。SharePlexは、ソース外部キー制約の結果をレプリケートします。ソースの外部キーの結果を正確にレプリケートするためには、互いに対する外部キーを持つテーブルをすべてレプリケーションの設定に含める必要があります。参照制約を持つテーブルはすべてターゲットデータベースに存在していなければなりません。もし1つでも欠けると、参照整合性が崩れる可能性があります。
注意: ターゲットテーブルの制約がDEFERREDの場合、Postトランザクションは制約の検証で失敗する可能性があります。この問題を回避するには、SP_OPO_DISABLE_OBJNUMパラメーターを有効にして、トランザクションを成功させます。再同期されるまで、基礎となるターゲットテーブルは引き続き非同期のままになります。
SharePlexには、ON DELETE CASCADE制約をターゲットテーブル上で有効なままに維持する機能がありますが、パラメーターの設定を通じて、明示的に有効にする必要があります。PostはON DELETE CASCADEの依存関係を検出し、レプリケートされたカスケード削除の子テーブルへのポストを抑制します。
SharePlexを使用してこのサポートを有効にしていない場合、ターゲット上でこれらの制約を手動で無効にする必要があります。そのようにしないと、SharePlexは、プライマリ削除とカスケード削除の両方をレプリケートするため、ターゲット上で削除がカスケードされるとコンフリクトやエラーが発生します。
ON DELETE CASCADEのサポートを有効にするには:
以下のSharePlexパラメーターを設定します。
注意: ピアツーピアレプリケーションでは、SP_OPO_REDUCED_KEYを0に設定する必要があります。
ターゲットシステムのチェック制約を無効にします。これらの制約により不必要なオーバーヘッドが増えます。これらのチェックはソースシステム上で行われるため、十分にメンテナンスされ同期化されたレプリケーション環境では冗長になります。高可用性を目的とする場合は、フェールオーバー手順の一環として制約を再アクティベーションするスクリプトを作成できます。
ピアツーピアレプリケーション以外のすべての状況では、SharePlexデータベースユーザは、ターゲットオブジェクトでDMLまたはDDLを実行できる唯一のユーザでなければなりません。他のユーザ、ジョブ、またはアプリケーションによってターゲットオブジェクトにDMLまたはDDLの変更が加えられた場合、ターゲットデータはソースシステム上のデータの状態を反映しなくなる可能性があります。詳細については、『SharePlex管理ガイド』の「同期の概念の理解」のセクションを参照してください。
SharePlexは、ALTER SEQUENCEおよびDROP SEQUENCEコマンドやDMLトランザクションで行われたOracleシーケンスへの変更をレプリケートします。特定のレプリケート戦略では、配列をレプリケートする必要がない場合があります。
高可用性:必要あり
SharePlexがシーケンスをレプリケートする方法により、ユーザはシーケンスの増分や再利用を気にすることなく、直ちにフェールオーバーデータベースを使い始めることができます。
レポート作成、データ共有、その他の基本的な一方向レプリケーション:必要なし
ターゲットシステムでシーケンスが不要な場合は、レプリケートしないでください。レプリケーションが遅くなる可能性があります。ソーステーブルのキー生成にシーケンスが使用されている場合でも、レプリケートされた行がターゲットシステムに挿入されると、シーケンス値がキー列の一部になります。シーケンス自体をレプリケートする必要はありません。
ピアツーピア:必要なし
SharePlexは同一シーケンスのピアツーピアレプリケーションをサポートしていません。詳細については、『SharePlex管理ガイド』の「複数のピアデータベースを維持するためのレプリケーションの設定」のセクションを参照してください
レプリケーション用にシーケンスを設定するには:
シーケンスをレプリケートするには、データベースレベルでプライマリキーとユニークキーのサプリメンタルロギングを有効にするか、sys.seq$テーブルでプライマリキーのサプリメンタルロギングを有効にする必要があります。
ターゲットシステムでのシーケンスの一意性を確保するために、ターゲットシーケンスの開始値をソースシーケンスの開始値よりも大きくする必要があります。以下の式を使用して、ターゲットのSTART_WITH値を決定します。
source_current_value+ (source_INCREMENT_BY_value x source_CACHE_value) =target_START_WITH_value
重要!(source_INCREMENT_BY_value x source_CACHE_value)は2GBを超えてはなりません。超えるとシーケンスのレプリケーションに失敗します。
SharePlexは、ALTER SEQUENCEコマンドを使用して、以下のようにターゲットデータベースのシーケンスを更新します。
増分値を以下のように変更します。
source_INCREMENT_BY_valuexsource_CACHE_value
以下の値を設定して、シーケンスを再度変更します。
Increment_value=source_INCREMENT_BY_value
Cache_value=source_CACHE_value
SharePlexは、シーケンスに対する単純なSELECT（UPDATE）操作と同じようにALTER SEQUENCE操作を扱います。これは、REDOログレコードではこれらの2つの操作が区別されないからです。
一部のOracleデータベースの設定にはレプリケーションに影響を与えるものがあるため、適切に設定する必要があります。
SharePlexでは、Oracle OPEN_CURSORSパラメーターの値がターゲットデータベース上で正しく設定されている必要があります。OPEN_CURSORSの値を表示するには、以下のSQLステートメントを使用してデータベースに問い合わせます。
select value from V$PARAMETER where name = 'open_cursors';
Postプロセスは、終了すると閉じるルーチン呼び出し用に10個のカーソルと、SQL Cache機能が有効になっている場合は（これがデフォルト）、これに加えてトランザクションごとに少なくとも50個のカーソルを保持しています。詳細については、「SQLキャッシュの調整』で参照してください。
SQLキャッシュを無効にするつもりであれば、アプリケーションが生成する同時更新トランザクション（セッション）のピーク数を見積もり、次の式に従います。
10 + (同時トランザクションのピーク数 x 2) =必要な最小限のオープンカーソル数
OPEN_CURSORSの値は、変更することも、ない場合に追加することもできます。Oracleのパラメーターを変更する前に、Oracleのドキュメントを参照してください。
PROCESSESおよびSESSIONSパラメーターの場合、現在のトランザクション量を処理するのに十分なSQL接続をターゲットデータベースにオープンできるように、SharePlexのPostプロセスで必要となる最小値は65です。この値は、SP_OPO_THREADS_MAXパラメーターのデフォルト設定に、メインのPostスレッド用の1を加えたものです。
init.oraファイルのPROCESSESパラメーターは、SharePlexおよびデータベースユーザによって作成された接続に対応できるように設定する必要があります。この値は、データベースがソースデータベースであるかターゲットデータベースであるか、またはソースデータベースとターゲットデータベースの両方を兼ねるデータベースであるかによって異なります。
データベースがソースとしてのみ機能する場合、以下の式はReadプロセスによるログインを考慮します。
(ソース・データベース・セッションのピーク数)+(バックグラウンドのOracleプロセス)+(SP_ORD_LDA_ARRAY_SIZEパラメーターの値+3)=PROCESSESの設定
Postプロセスは、トランザクションの一貫性を維持するために、ソースシステム上のセッション数と同じ数の接続をターゲットシステム上に作成します。
ターゲットシステムのPROCESSESパラメーターは、これらのすべての接続に加えて、以下に対応できるように十分に大きい値に設定しなければなりません。
以下の計算式をガイドとして使用します。
(ソース・データベース・セッションのピーク数)+(ターゲット・データベース・セッションのピーク数)+(バックグラウンドのOracleプロセス)=PROCESSESの設定
データベースがソースとターゲットの両方を兼ねている場合、以下の式は次により生成される接続を考慮します。
(ソース・データベース・セッションのピーク数)+(ターゲット・データベースのピーク数)+(バックグラウンドのOracleプロセス)+(SP_ORD_LDA_ARRAY_SIZEパラメータの値+3)=PROCESSESの設定
データベースライターの数は、特に多数の同時トランザクションがある場合、レプリケーションに影響を与えます。トランザクションがコミットされるたびに、バッファ内のデータはディスクにフラッシュされます。ほとんどのトランザクションが小規模であるにもかかわらずバッファが大きい場合、ポストが遅くなる可能性があります。大規模なトランザクションがコミットされている間に、別の通常のサイズのトランザクションがコミットされた場合、2番目のCOMMITは、バッファ全体がディスクにフラッシュされる間は待機しなければなりません。
ディスクにフラッシュされるバッファのサイズを小さくすることで、Postプロセスを高速化することができます。可能であれば、ログバッファのサイズを1024 KBまたは512 KBまで下げてみてください。
SharePlex はSHAREPLEX_TRANSテーブルを更新し、ターゲットデータベースの読み取りの一貫性を維持します。レプリケーションのパフォーマンスを向上させ、テーブルの競合を減らすために、このテーブルのinitransの設定を調整しなければならないことがあります。
このトピックでは、SharePlexがOracleソースとOracleターゲット間、またOracleソースと非Oracleターゲット間の文字セット変換をどのように処理するかを説明します。
SharePlexが、使用しているOracleの文字セット内のすべての文字を複製するには、以下のいずれかが真でなければなりません。
SharePlexでは、以下の文字セットがテストされ、サポートされています。
US7ASCII
UTF8
WE8ISO8859P1
AL16UTF16
AL32UTF8
KO16KSC5601
デフォルトでは、SharePlexにより、Oracleターゲットデータベースは文字変換を行うことができます。Postはソースデータの文字エンコーディングをOracleに通知し、Oracleは必要な変換を実行します。
関係する文字セットによっては、Oracleの変換はデータロスにつながる可能性があります。次などを考慮します。
例1: JA16SJIS文字セットの「米」という日本語文字は、US7ASCII文字セットには対応する記号がありません。この記号をUS7ASCIIデータベースに複製しようとすると、Oracleはこの記号を「?」文字に変換します。
例2: Oracleによると、WE8ISO8859P1文字セットはUS7ASCII文字セットのスーパーセットであるため、US7ASCIIの文字はすべて、変換されずにWE8ISO8859P1ターゲットデータベースにポストされると考えるのが論理的です。これは、0x00から0x7Fの範囲の文字に当てはまります。しかし、Oracleは、0x80から0xFFの範囲の文字の最上位ビットを除去します。この「変換」は、ソースのスーパーセットである文字セットにレプリケートする際に、データロスを引き起こす可能性があります。
注意: Oracleは、文字セットが同一の場合は文字を変換しません。したがって、WE8ISO8859P1のデータをWE8ISO8859P1の文字セットを持つデータベースにポストすると、Oracleの変換プロセスがバイパスされます。
データを変換せずに適用するには:
SP_OPO_NLS_CONVERSIONパラメーターを1に設定し、データを変換して適用します。
注意: ソースデータベースのNLS_NCHAR_CHARACTERSETとターゲットデータベースのNLS_NCHAR_CHARACTERSETが異なる場合、SharePlexは、常にNVARCHARとNCLOBのデータを変換します。
Open Targetターゲット（Oracle以外のターゲット）にレプリケートする場合、SharePlexは、任意のOracle Unicode文字セットおよびUS7ASCII文字セットからのレプリケーションをサポートします。SharePlexはUnicode文字セットでOpen Targetターゲットにデータをポストするため、ソースデータがUnicodeまたはUS7ASCIIの場合、ターゲット上で変換する必要はありません。
ただし、以下の項目に当てはまる場合は、ターゲット上で変換が必要となります。
Linux上のOracleクライアントで変換を実行するには:
UnicodeとUS7ASCIIのデータを変換せずに適用するには:
ソースデータがUnicodeまたはUS7ASCIIで、LOBデータをレプリケートしない場合は、変換やOracleクライアントは必要ありません。SP_OPX_NLS_CONVERSIONパラメーターを0に設定して変換を無効にし、Postが実行中であれば再起動します。
このトピックには、Oracleの特定のデータ型に適用されるセットアップガイドラインが含まれています。これらのガイドラインは、初めてレプリケーションを開始する前に対応が必要です。
注意: 共有メモリセグメントを大きくすると、システム上で大量のスワップスペースが使用される可能性があるため、十分なディスク容量を確保してください。
データベース・セットアップ・ユーティリティは、選択したテーブルスペースにいくつかのテーブルをインストールします。SHAREPLEX_LOBMAPテーブル以外は、テーブルスペースのデフォルトのストレージ設定を使用します。
SHAREPLEX_LOBMAPテーブルには、行の外に格納されたLOBのエントリが含まれています。これは、1 MBのINITIALエクステント、1 MBのNEXTエクステント、および10のPCTINCREASEで作成されます。MAXEXTENTSは120で、テーブルの最大許容値サイズは120 MBです。
推奨アクション: プライマリキーと一意キーのサプリメンタルロギングを有効にしている場合、SP_OCT_ENABLE_LOBMAPパラメーターを0に設定すると、SHAREPLEX_LOBMAPテーブルには何も保存されません。この場合、サイズが大きくなることを考慮する必要はありません。Readプロセスのパフォーマンスを最大化するために、プライマリキーと一意キーのサプリメンタルロギングを有効にすることを推奨します。
代替アクション: 通常、デフォルトのストレージはSHAREPLEX_LOBMAPに十分であり、400万以上のLOBエントリが許可されます。複製するOracleテーブルに、頻繁に挿入または更新される多数のLOB列がある場合は、SharePlexのテーブルスペースのサイズを適宜大きくすることを検討してください。このテーブルが、SharePlexの他のテーブルとテーブルスペースを共有していることを考慮してください。
データベースがコスト・ベース・オプティマイザ（CBO）を使用しており、SharePlexが処理するテーブルに多数のLOBが含まれる場合は、SHAREPLEX_LOBMAPテーブルを分析スケジュールに組み込みます。
注意: SharePlexを新規にインストールしても、以前のインストールからストレージパラメーターは変更されません。
Oracleや他のプロセスにリソースの優先順位が割り当てられている場合、SharePlexは、デフォルト設定のままでリソースをほとんど割り当てないようにできます。Oracleはピーク処理時にCPU使用率を増加させます。SharePlexがOracleよりも遅れる場合は、プロセスの優先度を上げてみてください。
Unixでプロセスの優先度を設定するには:
niceコマンドを使用します。システム管理者に相談し、システム上で実行されているすべてのソフトウェアの要件に基づいて適切な値を選択してください。rootユーザは、どのプロセスのniceness値も変更できます。SharePlex管理者ユーザはSharePlexのnicenesの値を調整できます。
デフォルトにより、SharePlexは、SQL*Loaderのダイレクトパスロードによってテーブルに加えられた変更をレプリケートします（DIRECT=TRUEキーワードパラメーター）。異なるテーブルに同時にロードできますが、1つのテーブルに対するロードは1回のみです（PARALLEL=FALSE）。データベースをアーカイブモードにし、テーブルロギングを有効にしなければなりません。
ソースシステムでダイレクトパスロードが長時間持続すると予想される場合は、レプリケーションに頼らず、ターゲットデータベースにデータを直接ロードする方が効率的な場合があります。ダイレクトパスロードが大きいと、ユーザアプリケーションのアクティビティによってREDOログに記録される変更にCaptureが遅れを取る可能性があります。
ロード後にチェック制約を無効にする必要があります。ONDELETECASCADE制約を有効にしたままにすることができます。
SP_OCT_REPLICATE_DLOADパラメーターで、ダイレクトパスロードをレプリケートするかどうかを制御します。ダイレクトパスロードのレプリケーションを無効にするには、このパラメーターを0に変更します。詳しくは、『SharePlexリファレンスガイド』を参照してください。
圧縮を有効にすると、SharePlexがネットワーク経由で送信するデータ量を減らすことができます。SharePlexはLZIPロスレス圧縮を使用します。ソースのSharePlexインスタンスで圧縮を有効にすると、ソースのSharePlexインスタンスのすべてのターゲットへの圧縮が自動的に有効になります。
デフォルトでは圧縮は無効になっています。圧縮は単独で、または暗号化と組み合わせて有効にすることができます。暗号化の詳細については、『SharePlex管理ガイド』を参照してください。
圧縮を有効にするには
SP_XPT_ENABLE_COMPRESSIONパラメーターを1に設定します。
sp_ctrl> set param SP_XPT_ENABLE_COMPRESSION 1
設定後にパラメーターを有効にするには、Exportを停止して開始します。
Oracle Data Pumpエクスポート操作をレプリケートする場合は、SP_OCT_ALLOW_DP_DDLパラメーターを1に設定し、Captureを再開します。
このパラメーターは、Oracle Data Pumpのexport/importを実行する際に発生するDDL操作のレプリケーションにSharePlexが失敗した場合に有効にすることができます。場合によっては、SharePlexは、Data PumpのロードでDDLを無視すべき再帰的なDDLとして識別することがあります。このパラメーターは、そのDDLをキャプチャするようにSharePlexに指示します。
1を設定すると、このパラメーターが有効になります。ロード終了後、このパラメーターを0に戻し、Captureを再開します。
© ALL RIGHTS RESERVED. 利用規約 プライバシー Cookie Preference Center
