Chat now with support
Chat with Support

SharePlex 8.6.6 - 管理ガイド

このガイドについて このガイドで使用されている表記規則 SharePlex の概要 SharePlex の実行 複数の SharePlex インスタンスの実行 sp_ctrl でのコマンドの実行 SharePlex パラメータ 複製のための Oracle 環境の準備 設定ファイルの作成 オープンターゲットのターゲットへの複製の設定 複製方法の設定 分割レプリケーションの設定 名前付きキューの設定 変更履歴ターゲットを維持するための SharePlex の設定 Oracle DDL の複製 エラー処理のセットアップ データの変換 SharePlex セキュリティ機能の設定 実稼動環境での複製のアクティベート SharePlex の監視 複製上の問題の防止および解決方法 非同期データの修復 Oracle の高可用性を維持するための手順 アクティブな複製環境の変更 Oracle アプリケーションのパッチまたはアップグレードの適用 ソースまたはターゲット上の Oracle データのバックアップ Capture プロセスのチューニング Post プロセスのチューニング 付録 A:ピアトゥピアの説明図 付録 B:SharePlex 環境変数

複製のための Oracle 環境の準備

複製のための Oracle 環境の準備

この章には、複製用の Oracle ソースまたはターゲットデータベース環境を用意する手順が記載されています。この章で概略を説明した作業を実行してから、最初の同期を実行して実際の環境で複製を開始する必要があります。実際のデータおよび複製目的に適用されるすべての作業を実行します。

コンテンツ

SharePlex をサポートするための Oracle redo ロギングのセットアップ

複製のための Oracle 環境の準備 > SharePlex をサポートするための Oracle redo ロギングのセットアップ

SharePlex は、オンラインおよびアーカイブの Oracle redo ログからキャプチャします。SharePlex は、ローデバイス、ファイルシステムデバイス、および ASM インスタンスに保存されている redo ログおよびデータファイルをサポートしています。

適切なロギングレベルの設定

最低限のサプリメンタルロギングを設定してから、SharePlex の複製設定をアクティベートする必要があります。

さらに、SharePlex は、プライマリキーと一意キーの両方のサプリメンタルロギングを設定する、またはレプリケーション内の各テーブルに、一意の列のサプリメンタルロググループを定義することをお勧めします。行更新のキー列が redo ログにある場合は、SharePlex がその情報をデータベースからフェッチする必要はありません。ビジー状態のシステムでは、これで Read プロセスのパフォーマンスが大幅に向上します。一部の SharePlex 機能では、プライマリキーと一意キーのロギングを有効にする必要があります。

テーブルの rowid を変更する ALTER TABLE DDL コマンドは、複製中のテーブルのプライマリキーまたは一意キーがログに記録されていない場合、その後の DML 操作に影響する可能性があります。キーがログに記録されていない場合、SharePlex は rowid に基づいて値をフェッチします。ALTER TABLE...MOVE などの rowid を変更する操作により、その後の DML 操作で誤ったキー値が使用される可能性があります。

キー値を定義する場合の詳細については、「複製する Oracle データベースオブジェクトのセットアップ」を参照してください。

正しいキーがロギング対象であることの確認

プライマリキーと一意キーのサプリメンタルロギングを有効にしており、テーブルにプライマリキーがない場合、どのタイプの一意キーをログに記録するのかを Oracle が決定する必要があります。テーブルに複数の種類の一意キーがある場合、Oracle は使用する最適なキーを決定して、UPDATE ごとにこれらの列値をログに記録します。テーブルにどの種類のキーもない場合は、Oracle は LONG または LOB ではないすべての列をログに記録します。

SharePlex は、データの複製に使用するキーも識別する必要があります。Oracle と同様に、SharePlex は次の順序でキーを選択します。

  • プライマリキー(存在する場合)
  • 最適な(または唯一の)一意キー(存在する場合)
  • すべての列

SharePlex が複製しているテーブルにプライマリキーがなく、複数種類の一意キーが存在している場合、Oracle がログに記録したキー列が SharePlex が必要とするキー列ではない可能性があります。

キー値を定義する場合の詳細については、「複製する Oracle データベースオブジェクトのセットアップ」を参照してください。

アーカイブログの設定

複製がアクティブであるときに、Capture プロセスが停止した(または SharePlex ユーザーによって停止された)場合、Capture はその場所を REDO ログに記録し、再開した時点でその場所から継続します。もし REDO ログが Capture が再開する前にラップした場合は、Capture は欠損したレコードを見つけるためにアーカイブログを読み込みます。

理想的には、SharePlex がアーカイブログを読み込まないで済むように、REDO ログを設定するべきです。ほとんどの場合、オンラインログの読み込みはアーカイブの読み込みよりも高速です。アーカイブログからの処理を最小化するために、オンライン REDO ログが十分に大きく多数であることを確認します。最小でも、ラップせずに数時間分を保持できる REDO ログの容量が必要です。

:Exadata システムでは、ログを異なるシステムに多重化することで、Capture を高速化できる可能性があります。「Exadata での Capture のチューニング」を参照してください。

適切なオンラインログの設定をテストするには

実稼働前のテストでは、次の手順を実行することで、Capture がアーカイブログを読み込むかどうかを決定できます。

  1. SHAREPLEX_ACTID テーブルをクエリすることで、SharePlex が処理しているログを判断します。

    SQL> select seqno from splex.shareplex_actid

  2. Oracle の V$LOG テーブルをクエリすることで、Oracle が書き込んでいるログを判断します。

    SQL> select sequence# from v$log where status='CURRENT'

  3. sequence# の値から、seqno の値を引き算します。こうすることで、Capture がいくつのログで Oracle から遅れをとっているかが分かります。
  4. オンライン REDO ログをその値から引き算します。この数が負である場合は、SharePlex はアーカイブログを処理しています。たとえば、10 個の REDO ログがあり、SharePlex が 11 ログ分遅れている場合は、アーカイブログを処理しています。さらに、この結果を使用して、オンラインロギングの設定を調整できます。

Capture が停止してから再開するまでの間に長い遅延が発生している場合、Capture が Oracle の処理に追いつかず、ソースデータとターゲットデータの間で遅延が生じる可能性があります。このような場合、必要なログがオンラインではなくなるので、Capture は通常、アーカイブを読み込む必要があります。Capture の問題を回避するには、次のようにアーカイブログを設定して、高速な連続複製をサポートします。

要件 説明
ソースシステムでのアーカイブログの有効化 アーカイブログをソースシステムで有効にする必要があります。この操作を実行しないと、Capture がオンラインログの処理を終了する前にラップが発生した場合に、ソースデータとターゲットデータの再同期が必要になります。
圧縮の適切なタイミング SharePlex が処理を終了するまでアーカイブログを圧縮しないでください。これに反した場合、SharePlex はデータを処理できなくなるため、「Log wrap detected」というメッセージを返して停止します。SharePlex のカレントログを判断するには、ソースシステム上の sp_ctrl で、detail オプションをつけて show capture コマンドを発行します。カレントログの前に生成されたすべてのログを圧縮できます。
デフォルト以外のアーカイブ先の指定 Oracle のデフォルト以外の場所にアーカイブログを保存している場合は、アーカイブログがあるディレクトリのフルパス名に SP_OCT_ARCH_LOC パラメータを設定します。REDO ログがラップした場合は、SharePlex は Oracle のアーカイブログリストの中のアーカイブログを検索します。そこでアーカイブログが見つからなかった場合は、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 は、この場所にある対象を読み込むことができません。

Exadata 上のアーカイブログからの読み込み

通常、オンライン redo ログからの読み込み時に、SharePlex は遅延を最小限に抑えることができます。ただし Exadata では、SharePlex が処理できるデータ量が増えるのは、Exadata ASM ファイルシステムの外部にある多重化されたアーカイブ先から読み込む場合です。詳細については、次を参照: Exadata での Capture のチューニング

重要:Capture が Oracle による redo の生成量のペースに追いつけない場合、次に当てはまる可能性があります。

  • アーカイブログからのキャプチャによる SharePlex でのパリティの復元を待機する代わりに、データを再同期する方が実際的である可能性があります。
  • 失われた操作を Capture が処理およびキューイングしている間に、ソースシステムのディスクスペースが不足する可能性があります。
  • 特に、必要なアーカイブログを利用できなくなった場合に、Post が SQL 文を作成するために必要な情報を SharePlex が失う可能性があります。SharePlex の実行中は常に、ディスクスペースと遅延を監視します。

複製する Oracle データベースオブジェクトのセットアップ

複製のための Oracle 環境の準備 > 複製する Oracle データベースオブジェクトのセットアップ

このトピックでは、SharePlex を使用して複製する Oracle データベースオブジェクトの特定の特性を設定する方法について説明します。

行の一意性の保証

SharePlex では、ターゲット上で変更する行がソース行と一致する正しい行であることを保証できる必要があります。これは、キーとインデックスを使用して 1 対 1 の関係を保証することで実現できます。

キーの役割

SharePlex は複製するすべてのソーステーブルおよびターゲットテーブル、特に大きなテーブルや LONG 列を含むテーブルに対してプライマリキーまたは一意のキーが存在する場合に、最も速く動作します。使用するキーを選択するとき、SharePlex は最適なキー列を次の優先順位で使用します。

  • 主キー
  • 少なくとも列の 1 つが NULL でない、最小の列のある一意のキー
  • 最小の列ある一意のキー。

最高のパフォーマンスを実現するには、プライマリキーおよび一意のキーのサプリメンタルロギングを有効にすることをお勧めします。

テーブルにプライマリキーまたは一意のキーがない場合、または SharePlex の誤った一意のキーが Oracle によってログに記録された場合は、設定ファイルを作成するときに SharePlex でキーとして使用する列を指定できます。これはキー定義と呼ばれ、設定ファイルに指定します。詳細については、次を参照: 一意のキーの定義

キー定義の別の手段として、一意性を確立する 1 つまたは複数の列を基とする一意のインデックスを作成または使用することもできます。

キーまたは一意のインデックスのないテーブル

テーブルにキーまたは一意のインデックスが見つからない場合、SharePlex は、LONG と LOB を除くすべての列を使用してキーを構築します。このキーは内部で保守され、テーブル自体に作成されません。

この方法はお勧めしません。結果の WHERE 句によって、Oracle がターゲットテーブルに対してフルスキャンを実行して行を検索するため、複製速度が大幅に低下するためです。また、行の一意性を強制することもできません。

たとえば、さまざまな行の非 LONG 列に同じ値が含まれる一方で、LONG 列に異なる値が含まれる場合、ユーザーや SharePlex が認識することなくテーブルが非同期になる可能性があります。次の図を使って、この問題を説明します。テーブルにある行は LONG 列を除いて同一のもので、主キーまたは一意のキーはありません。

列 A 列 B 列 C (LONG)
10 20 100
10 20 200
10 20 300

ソースシステムのユーザーが列 A の 1 行目を 15 に変更したとします。変更をターゲットテーブルに対して適用するために SQL 文を構築するとき、SharePlex は変更する行を検索するために列 A と B(UPDATE tablename SET Column A to 15 WHERE Column A = 10 and Column B = 20)を使用してキーを構築します。この条件を満たす行は 3 行あるため、SharePlex は誤った行への変更を post する可能性があります。

NULL を含むキー

もしキーで NULL が許可されている場合は、SharePlex は UPDATE および DELETE で行の一意性を保証することができず、ターゲットシステムで誤った行を変更してしまう可能性があります。SharePlex で NULL が可能なキーを制御するには SP_SYS_IN_SYNC パラメータを設定します。詳細については、『 SharePlex リファレンスガイド』を参照してください。

キーの値の変更

SharePlex では、特別な設定をしなくてもキー列の値に対する変更が処理されます。ただし、キーにシーケンスが使用されている場合で、もしキーの値が更新される可能性がある場合は、更新によってターゲットシステムでキーが重複しないように、シーケンスを作成します。そうしないと、操作を適用するために新しい値が使用されたときにターゲットテーブルの他の行にその値がキーとしてすでに存在している場合、SharePlex は一意キー制約違反および非同期エラーを返します。このようなエラーは、「x +n」式(n は増分値)を使用して値を更新した場合に発生する可能性があります。「x +n」の値の 1 つが既存の値に等しい可能性があります。

以下の例では、キー列の値が 1 ずつ増分されます。

Key_Col

1

4

5

7

SQL> update table X set a=a+1; commit

新しい値は次のようになり、ターゲットシステムに複製されます。

Key_Col

2

5

6

8

SharePlex は、REDO ログに入力された順に更新操作を実行します。

update x set a=2 where a=1;(成功)

update x set a=5 where a=4;(これは、5 がすでに存在するため、失敗します。)

update x set a=6 where a=5;(成功)

update x set a=8 where a=7;(成功)

Post がターゲットシーケンスに対して使用するプリイメージ値は、ソースから複製された増加した値と同じです。Oracle は、一意の制約違反としてこの操作を拒否します。別の例として、A から B に更新し、そして B から C へ更新するトランザクションがあります。

重要! ピアトゥピアレプリケーションを使用する場合は、キーに関する追加の要件があります。詳細については、次を参照: 複数のピアデータベースを保持するための複製の設定

インデックス

複製環境ではインデックスを正しく使うことが重要です。インデックスにより、ターゲットデータの整合性が保たれます。

  • 一意のインデックスを持つソーステーブルを複製する場合、ターゲットテーブルにも一意のインデックスがある必要があります。
  • すべての大きなテーブルは、ターゲットシステムに一意のインデックスを持っている必要があります。一意のインデックスがない場合は、Oracle は Post で変更する行を見つけるためにテーブル全体をスキャンします。
  • いくつかのアプリケーションでは主キーの制約が使用されないため、デフォルトで一意のインデックスが作成されません。しかし、人の名前または従業員の ID 番号などの一意の値が入力された 1 つまたは複数の列に対してインデックスが作成されたのに、一意なインデックスとして名前が付けられない(CREATE UNIQUE INDEX コマンドが使用されなかった)場合もあります。テーブルに対して一意のインデックスが存在しない場合は、設定ファイルを作成するときに一意のインデックスを作成するか、ユーザー定義のキーを指定することをお勧めします。詳細については、次を参照: 一意のキーの定義
  • 一度一意のインデックスを識別または作成したら、SharePlex の hints 機能を使って Oracle が確実にそのインデックスを使用するようにできます。詳細については、次を参照: Oracle INDEX ヒントの使用
  • テーブルに外部キーがある場合は、外部キーへの変更によってフルテーブルスキャンが実行されることのないように、正しい列に対してインデックスを作成します。

  • インデックスは常に更新しないと、Post プロセスが遅くなります。断片化されたものは再構築します。

ターゲットテーブルのインデックスが多すぎると、行の追加や削除の際に、Oracle がそれらをすべて更新する必要があります。これにより複製を含み、システム全体が遅くなります。インデックスの数は、最も有用性が高いものに限定することを検討してください。

主に 1 種類の DML を実行するアプリケーションでは、以下の点を考慮します。

  • INSERT:メンテナンスを制限するために、使用するインデックスの数を数個に抑えます。
  • UPDATE:INSERT 文の後で変更されない列のインデックスを使用します。
  • DELETE:できる限りインデックスを削除します。

何百万もの SQL 操作を行う、大きなバッチジョブを実行するときは、不要なインデックス群をバッチジョブの前に削除し、最後に再構築します。これによって、SharePlex の動作速度が向上し、以後のインデックスが整理されます。

ビットマップインデックス

パフォーマンス向上のため、Post プロセスがデータを適用している間は、ビットマップインデックスを使用しないでください。これらのインデックスによって Post プロセスのパフォーマンスに悪影響が及ぶ可能性があります。

ターゲットテーブルでビットマップインデックスを使用する必要がある場合は、クエリの利点と Post によって適用されるトランザクションへの影響とを比較検討してください。

  • Oracle がビットマップエントリを追加または更新するとき、ビットマップセグメントに関連付けられたすべての行をロックします。
  • 1 つのビットマップセグメントは何百もの行への参照を含むことができます。その結果、異なる Post セッションによる変更(ソースシステムの 1 つのセッションについて 1 つの Post セッションがあります)が、同じビットマップセグメント内のビットマップエントリを更新する場合、互いにブロックする可能性があります。
  • 続行するには、Post がこのブロックを検出し解決しなければなりませんが、ロックされた数が多い場合は Post が著しく遅れます。
  • 一般的に、複数の同時セッションによるビットマップインデックスを持つテーブルへの頻繁な挿入はロック競合の原因となりますが、このようなテーブルへの任意の更新および削除は競合が発生することはありません。SharePlex では Oracle からの推奨に従い、静的なテーブル上にビットマップインデックスを持ちます。

注: ビットマップインデックスを複製することはお勧めしません。ビットマップインデックスを持つテーブルを変更するたびに、インデックスが再構築されます。この再構築に関連するコスト(Oracle の時間およびリソース)は、SQL UPDATE 文に追加されます。

ターゲットでのトリガの起動の防止

ソースシステム上でトリガが実行された結果である DML 変更は、REDO ログに入力されるため、SharePlex によって複製され、ターゲットデータベースに post されます。その結果、同じトリガがターゲット上で実行され、(既に複製によって追加済みの)同じ DML 変更が開始された場合、非同期エラーが生じます。

たとえば、ソースシステム上で TableA への INSERT が TableB への INSERT をトリガした場合、SharePlex は両方の INSERT をターゲットシステムに複製します。Post プロセスは 1 つ目の INSERT をターゲットシステム上の TableA に適用し、それによってTableB へ INSERT がトリガされます。したがって、Post が複製された INSERT を TableB に post しようとすると、一意キー違反が発生します。TableA に対してトリガが起動されているため、この行はすでに存在します。

トリガは、複製方法に応じて以下のように処理できます。

複製方法 ターゲットでのトリガの処理方法

高可用性

および

ピアトゥピア

  1. フェイルオーバーに備えて、またはトランザクションが複数のソースシステムで実行されるため、SharePlex 以外のユーザーのトリガを有効にします。
  2. sp_add_trigger.sql スクリプトを実行して、SharePlex ユーザーのトリガを無効にします。このスクリプトは個々のトリガの文に、SharePlex ユーザーによって post された操作を無視するように指示する WHEN 句を置きます。
レポート作成、データ共有、その他の基本的な一方向の複製
  • ターゲットシステムでトリガを完全に無効にするか、または sp_add_trigger.sql スクリプトを実行して、SharePlex ユーザーによって post される操作を無視します。
  • トリガスクリプトの使用方法に関する重要な情報については、『 SharePlex リファレンスガイド』を参照してください。

    整合性制約の設定

    整合性制約は複製に影響します。以下のガイドラインに従って、整合性制約が確実に処理されるようにしてください。

    外部キー制約

    外部キー制約は、ターゲットテーブルで無効にする必要があります。SharePlex は、ソースの外部キー制約の結果を複製します。ソースの外部キーの結果を正確に複製するには、相互に外部キーを持つテーブルをすべて複製設定に含める必要があります。参照制約を持つすべてのテーブルが、ターゲットデータベースに存在している必要があります。1 つまたは複数のテーブルが欠けている場合は参照整合性が破損してしまう場合があります。

    注: ターゲットテーブルで制約が DEFERRED の場合、Post トランザクションが制約の検証で失敗する可能性があります。この問題に対応するには、SP_OPO_DISABLE_OBJNUM パラメータを有効にして、トランザクションが成功するようにします。再同期するまで、基礎となるターゲットテーブルは非同期のままになります。

    ON DELETE CASCADE 制約

    SharePlex では、ターゲットテーブルで ON DELETE CASCADE 制約を有効にしたままにできますが、この機能は有効にする必要があります。Post は、ON DELETE CASCADE 依存性を検出し、子テーブルへの複製されたカスケード削除の post 操作をすべて抑止します。

    SharePlex を介してこのサポートを有効にしない場合は、ターゲットでこれらの制約を手動で無効にする必要があります。そうしないと、SharePlex によってプライマリ削除とカスケード削除の両方が複製され、ターゲットで削除がカスケードされたときに競合とエラーが発生します。

    ON DELETE CASCADE のサポートを有効にするには

    • ソースでのプライマリキー、一意のインデックス列、および外部キー列のロギングを有効にします。
    • 以下の SharePlex パラメータを設定します。

      • SP_OPO_DEPENDENCY_CHECK パラメータを 2
      • SP_OCT_REDUCED_KEY パラメータを 0
      • SP_OPO_REDUCED_KEY パラメータを 0、1、または 2(:ピアトゥピアレプリケーションでは、このパラメータは 0 に設定する必要があります)

    チェック制約

    ターゲットシステムでチェック制約を無効にします。チェック制約により、不要なオーバーヘッドが増加します。これらのチェックはソースシステム上で満たされているため、適切に管理および同期された複製環境では冗長です。高可用性を目的とする場合は、フェイルオーバーの手順の一部として制約を再度有効にするスクリプトを構築することができます。

    ターゲットオブジェクトへのアクセスの防止

    ピアトゥピアレプリケーションを除くすべてのシナリオにおいて、SharePlex データベースユーザーのみがターゲットオブジェクトに対して DML または DDL を実行できるようにする必要があります。他のユーザー、ジョブ、またはアプリケーションによってターゲットオブジェクトに DML または DDL の変更が加えられた場合、ターゲットデータはもはやソースシステム上のデータの状態を反映していない可能性があります。詳細については、次を参照: 同期の概念について

    シーケンスの設定

    SharePlex は、ALTER SEQUENCE および DROP SEQUENCE コマンドの実行、または DML トランザクション中に加えられた Oracle シーケンスの変更を複製します。必ずしも特定の複製方法のシーケンスを複製する必要はありません。

    • 高可用性はい

      SharePlex がシーケンスを複製する方法によって、ユーザーはフェイルオーバーデータベースをシーケンスを増分したり、再利用したりすることなく、直ちに使用し始めることができます。

    • レポート作成、データ共有、その他の基本的な一方向の複製いいえ

      シーケンスがターゲットシステムで不要な場合は、複製しないでください。複製を低速する可能性があります。ソーステーブルでキーを生成するためにシーケンスを使用した場合でも、シーケンスの値は、複製された行がターゲットシステムに挿入されたときのキー列の一部です。シーケンスそのものは複製する必要がありません。

    • ピアトゥピアいいえ

      SharePlex は同一シーケンスのピアトゥピア複製をサポートしません。詳細については、次を参照: 複数のピアデータベースを保持するための複製の設定

    シーケンスを複製用に設定するには

    • キャッシュを使用して、キャッシュの増分を 20 以上に設定します。シーケンスがキャッシュに格納されると、SharePlex は値をグループとして複製できます。シーケンスがキャッシュされない場合、SharePlex はシーケンスから値を取得する度にディスクをアクセスする必要があるため、重要なデータの複製を低速してしまいます。
    • テーブルの場合と同じように、所有者と名前で設定のシーケンスを指定します。詳細については、次を参照: 設定ファイルの作成を参照してください。
    • シーケンスのターゲットシステムでの一意性を保証するには、ターゲットシーケンスの開始値がソースシーケンスの開始点より大きくなければなりません。次の公式を使って、ターゲットの 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) は、2 GB 以下でなければなりません。そうでないと、シーケンスの複製が失敗します。

    SharePlex では、以下のように ALTER SEQUENCE コマンドを使用してターゲットデータベース内のシーケンスを更新します。

    • 増分値を以下の値に変更します。

      source_INCREMENT_BY_valuexsource_CACHE_value

    • NOCACHE に設定します。
    • シーケンスを UPDATE します。
    • 次の値を設定して再度シーケンスを ALTER します。

      Increment_value=source_INCREMENT_BY_value

      Cache_value=source_CACHE_value

    SharePlex では、ALTER SEQUENCE 操作はシーケンスに対する単純な SELECT(UPDATE)のように処理されます。これは、REDO ログレコードでこの 2 つの操作が区別されないためです。

    SharePlex をサポートするための Oracle データベースのセットアップ

    複製のための Oracle 環境の準備 > SharePlex をサポートするための Oracle データベースのセットアップ

    特定の Oracle データベース設定は複製に影響を及ぼすので、適切に設定する必要があります。

    Post カーソルをサポートするための OPEN_CURSORS の調整

    SharePlex では、ターゲットデータベースで Oracle OPEN_CURSORS パラメータの値を正しく設定する必要があります。OPEN_CURSORS の値を表示するには、次の SQL 文を使用してデータベースをクエリします。

    select value from V$PARAMETER where name = 'open_cursors' ;

    Post プロセスは、終了時に閉じるルーチンコール用の 10 個のカーソルのほか、SQL Cache 機能が有効になっている場合(デフォルト設定)はトランザクション当たり 50 個以上のカーソルを予約しています。詳細については、次を参照: SQL Cache のチューニング

    SQL Cache を無効にする場合は、アプリケーションが生成する並行更新トランザクション(セッション)のピーク数を概算し、次の公式に従います。

    10 +(並行トランザクションのピーク数 x 2)= 必要最小オープンカーソル数

    OPEN_CURSORS の値が存在しない場合、変更または追加できます。Oracle パラメータに変更を加える前に、Oracle マニュアルを参照してください。

    接続をサポートするための PROCESSES パラメータの調整

    SharePlex およびデータベースユーザーによって作成された接続を処理するためにinit.ora ファイルの PROCESSES パラメータを設定する必要があります。その値は、データベースがソースデータベース、ターゲットデータベース、またはその両方として機能するかどうかによって決まります。

    データベースがソースとしてのみ機能する場合

    データベースがソースとしてのみ機能する場合、次の公式では Read プロセスによるログインが考慮されます。

    (ソースデータベースセッションのピーク数) + (バックグランドの Oracle プロセス) + (SP_ORD_LDA_ARRAY_SIZE パラメータ値 + 3) = PROCESSES 用の設定

    データベースがターゲットとしてのみ機能する場合

    Post プロセスはトランザクションの一貫性を保つため、ソースシステム上のセッション数と同じ数の接続をターゲットシステムに作成します。ターゲットシステムの PROCESSES パラメータは、これらすべての接続に加えて、次の内容に十分対応できるように高く設定する必要があります。

    • 一連の接続によって生成されるバックグラウンドの Oracle プロセス
    • クエリ目的でターゲットデータベースにアクセスするユーザーのピーク数

    次の公式で説明します。

    (ソースデータベースセッションのピーク数) + (ターゲットデータベースセッションのピーク数) + (バックグランドの Oracle プロセス) = PROCESSES 用の設定

    データベースがソースおよびターゲットの両方として機能する場合

    データベースがソースとターゲットの両方として機能する場合、次の公式では、以下による接続が考慮されます。

    • Read プロセス
    • Post プロセス
    • バックグラウンドの Oracle プロセス
    • ユーザー接続

    (ソースデータベースセッションのピーク数) + (ターゲットデータベースセッションのピーク数) + (バックグランドの Oracle プロセス) + (SP_ORD_LDA_ARRAY_SIZE パラメータの値 + 3) = PROCESSES 用の設定

    post を改善するためのログバッファサイズの調整

    データベースライターの数は特に複数の並行トランザクションがある場合、複製に影響を及ぼします。トランザクションがコミットされるとき、そのバッファデータがディスクにフラッシュされます。もしほとんどのトランザクションが小さく、しかしそのバッファが大きい場合は、Post が遅くなる原因となります。大きいトランザクションがコミットされ、そして標準サイズのトランザクションがコミットされた場合は、2 つ目の COMMIT はバッファ全体がディスクにフラッシュされるまで待たなければなりません。

    ディスクにフラッシュするバッファのサイズを減少することで Post プロセスを高速化することができます。ログバッファのサイズを 1024 KB または可能であれば 512 KB まで減少してください。

    ユーザー数に基づく SharePlex トランザクションテーブルの調整

    SharePlex はターゲットデータベースの read の一貫性を維持するために、SHAREPLEX_TRANS テーブルを更新します。テーブルの複製のパフォーマンスを改善して競合を減らすため、このテーブルの initrans 設定の調整が必要な場合があります。

    • プロダクションデータベースが 500 から 1,000 人の同時ユーザーを持っている場合、SHAREPLEX_TRANS テーブルの initrans が 30 になるように再構築します。
    • プロダクションデータベースが 1,000 人以上の同時ユーザーを持っている場合、SHAREPLEX_TRANS テーブルの initrans が 40 になるように再構築します。

    キャラクタセットの変換の制御

    このトピックでは、Oracle ソースと Oracle ターゲットの間および Oracle ソースと非 Oracle ターゲットの間のキャラクタセットの変換が SharePlex でどのように処理されるのかを説明します。

    Oracle ソースと Oracle ターゲットの間の複製

    使用している Oracle キャラクタセット内のすべての文字を SharePlex で複製するには、次のいずれかを満たしている必要があります。

    • キャラクタセットは、ソースとターゲットで同じであること
    • ソースデータベースのキャラクタセットは、ターゲットデータベースのキャラクタセットのサブセットであること(ソースに含まれているすべての文字がターゲットのキャラクタセット内に存在すること)

    次のキャラクタセットが SharePlex 向けにテストされ、サポートされています。

    US7ASCII

    UTF8

    WE8ISO8859P1

    AL16UTF16

    AL32UTF8

    KO16KSC5601

    デフォルトでは、SharePlex は Oracle ターゲットデータベースによるキャラクタ変換の実行を許可します。Post がソースデータのキャラクタエンコーディングについて Oracle に通知し、Oracle が必要に応じて変換を実行します。

    関連するキャラクタセットによって Oracle 変換はデータ損失が生じる可能性があります。例:

    例 1:JA16SJIS キャラクタセットに含まれる日本語の「米印(※)」の文字に対応する記号は、US7ASCII キャラクタセットには含まれていません。この記号を US7ASCII データベース内で複製しようとした場合、Oracle が「?」文字に変換します。

    例 2:Oracle によると、WE8ISO8859P1 キャラクタセットは US7ASCII キャラクタセットのスーパーセットであるので、US7ASCII に含まれる文字は変換されずに WE8ISO8859P1 ターゲットデータベースに post されると想定するのが論理的です。これは、0x00 から 0x7F. までの範囲に適応されます。しかし、Oracle は 0x80 から 0xFF までの範囲の文字は、先頭ビットを取り去ります。この「変換」はソースのスーパーセットであるキャラクタセットに複製する際に、データ損失となる可能性があります。

    注: Oracle はキャラクタセットが同一である場合は、文字の変換はしません。このため、キャラクタセットが WE8ISO8859P1 のデータベースに対して WE8ISO8859P1 データを post した場合、Oracle のデータ変換処理はバイパスされます。

    変換なしでデータを適用するには

    SP_OPO_NLS_CONVERSION パラメータを 1 に設定して、変換なしでデータを適用します。詳細については、「SharePlex SharePlex リファレンスガイド」を参照してください。

    注: NLS_NCHAR_CHARACTERSET がソースデータベースとターゲットデータベースで異なる場合、SharePlex は常に NVARCHAR および NCLOB データを変換します。

    Oracle ソースと非 Oracle ターゲットの間の複製

    オープンターゲットのターゲット(非 Oracle ターゲット)に複製する場合、SharePlex は任意の Oracle Unicode キャラクタセットと US7ASCII キャラクタセットからの複製をサポートします。SharePlex は Unicode キャラクタセットでオープンターゲットにデータを post するので、ソースデータが Unicode または US7ASCII の場合、ターゲットでの変換は必要ありません。

    ただし、次に該当する場合、ターゲットでの変換が必要です。

    • ソースデータのキャラクタセットが Oracle Unicode または US7ASCII 以外のものである場合は、Oracle クライアントをターゲットにインストールして、ターゲットに post するために Unicode への変換を実行する必要があります。
    • Unicode 以外のキャラクタセットでターゲットデータベースにデータを post する必要がある場合は、ターゲットに Oracle クライアントをインストールして変換を実行し、target コマンドを使用して、Post が使用するターゲットキャラクタセットを識別する必要があります。このコマンドの詳細については、『 SharePlex リファレンスガイド』を参照してください。

    Linux 上で Oracle クライアントとの変換を実行するには

    1. ターゲットシステムに Oracle Administrator Client をインストールします。クライアントは、管理者インストールタイプでなければなりません。Instant Client および Runtime のインストールタイプはサポートされていません。
    2. ORACLE_HOME をクライアントインストールに設定します。ORACLE_SID をエイリアスまたは存在しない SID に設定します。SharePlex ではそれらは使用されないので、データベースを実行する必要はありません。
    3. ターゲットシステムに SharePlex をインストールするには、オープンターゲットインストーラではなく、Oracle ベースの SharePlex インストーラをダウンロードします。Oracle ベースのインストーラには、ターゲットデータベースに post する前に、Oracle クライアントライブラリの変換関数を使用してデータを変換するように Post に指示する機能が含まれています。
    4. SharePlex for Oracle の手順に従ってください(オープンターゲットへのインストール用ではありません)。
    5. SP_OPX_NLS_CONVERSION パラメータがデフォルトの 1 に設定されていることを確認します。

    Windows 上で Oracle クライアントとの変換を実行するには

    1. ターゲットシステムに Oracle Administrator Client をインストールします。クライアントは、管理者インストールタイプでなければなりません。Instant Client および Runtime のインストールタイプはサポートされていません。
    2. SharePlex レジストリキー \HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\QuestSoftware\SharePlex\port_number で、ORACLE_HOME を Oracle クライアントのインストール場所に設定し、ORACLE_SID をエイリアスまたは存在しない SID に設定します。Oracle データベースは必要ありません。SharePlex は、クライアントライブラリのみを使用する必要があります。
    3. Windows インストーラを使用して SharePlex をします。
    4. SP_OPX_NLS_CONVERSION パラメータがデフォルトの 1 に設定されていることを確認します。

    Unicode および US7ASCII データを変換せずに適用するには

    ソースデータが Unicode または US7ASCII であり、LOB データを複製していない場合、変換または Oracle クライアントは必要ありません。SP_OPX_NLS_CONVERSION パラメータを 0 に設定して変換を無効にし、Post が実行中の場合は再起動します。

    Related Documents

    The document was helpful.

    Select Rating

    I easily found the information I needed.

    Select Rating