SharePlex 11.4 - 管理者ガイド

INDEXヒントの使用

OracleのINDEXヒントの使用

Oracleターゲットで有効

SharePlexがターゲットテーブルでUPDATEやDELETE を実行すると、OracleはSharePlexで最も効率的なインデックスを選択しないことがあります。適切なインデックスがないと、複数のUPDATEやDELETEが実行されるときに、Postプロセスの処理速度が低下します。SharePlexでは、OracleのINDEXヒントを使用して、ターゲットオブジェクトで適切なインデックスを強制的に使用させることができます。

INDEXヒントを使用するには、hints.SIDファイルを使用します。ここで、SIDはターゲットインスタンスのORACLE_SIDです。Postは、SQLステートメントを適用するときにヒントファイルを読み込みます。ファイルにエントリが含まれている場合、Postはデータをメモリに読み込んでから、処理する各UPDATE文とDELETE文をチェックします。これらの操作のいずれかがヒントファイルにリストされたテーブルを含む場合、PostはヒントをOracleに送信します。

ヒントが必要なテーブルにのみヒントを使用します。例えば、定義されたインデックスがあるテーブルに対してPostがフルテーブルスキャンを行うと、ヒントはそれらのテーブルだけで使用されます。ヒントを使用すると、Postはhints.SIDファイルを読み込んで、ファイルに記載されているテーブル上の各操作用に使用します。多数のテーブルがリストされていると、処理速度が低下する場合があります。

ヒント（テーブルとインデックスのペア）のデフォルトの最大数は100です。この値はSP_OPO_HINTS_LIMITパラメーターで調整できます。詳細については『SharePlexリファレンスガイド』を参照してください。

すべてのインデックスが有効であることを確認します。SharePlexは無効なインデックスをヒントとして使用しますが、Oracleは無効なヒントを無視し、エラーは返しません。SharePlexは、指定されたヒントに関連する異常な状態を検出した場合、event_Logに以下の情報を書き込みます。

15050 – hint file not found（ヒントファイルが見つかりません）

17000 – error opening hint file（ヒントファイルを開くときにエラーが発生しました）

15051 – missing column in the hint file (either table or index name)（ヒントファイルに列がありません（テーブルまたはインデックス名））

15052 – syntax error for tablename（tablenameのシンタックスエラー）

15053 – syntax error for indexname（indexnameのシンタックスエラー）

15054 – source table’s object_id not found in object cache（ソーステーブルの object_id がオブジェクトキャッシュで見つかりませんでした）

15055 – more than 20 valid entries were entered into the hints file（ヒントファイルに有効なエントリが21件以上入力されました）

ヒントファイルを使用するには:

空白のhints.SIDファイルが、各システム上のSharePlex変数データディレクトリにあります。hints.SIDファイルは、targetシステムにあるものを使用します。ヒントファイルがない場合は、このディレクトリに作成し、その際にhints.SIDの命名形式を必ず使用してください。

1. Postを停止します（実行中の場合）。
2. ファイルを開きます。
3. ファイル内のどこにでもコメント行を追加できます。コメント行の先頭にはポンド記号（#）を付けます。

4. コメント行以外の行で以下のテンプレートを使用し、ソーステーブルとそのテーブルに使用するインデックスを指定します。テーブル名とインデックス名の間には少なくとも1つのスペースを入れます。各指定は別の行に配置します。

   "src_owner"."table"

   "tgt_owner"."index"

   例

   "scott"."emp"

   "scott"."emp_index"

SQLキャッシュの調整

SharePlexは、頻繁に使用されるSQLステートメントを再利用できるようにキャッシュし、繰り返し使用されるたびに解析やバインドを行う必要がないようにします。これはSharePlexの調整可能な機能で、SQL Cacheと呼ばれます。この機能は、アプリケーションが生成する繰り返しステートメントの量に応じて、その利点を最大限に生かすように調整することができます。

SQLキャッシュがPostのパフォーマンスを向上させるのは、同じSQLステートメントが何度も発行され、データ値以外に変化がない場合に限られます。これがお客様の環境に当てはまらない場合、SQLキャッシュはPostプロセスに不要なオーバーヘッドを追加するため、無効にする必要があります。

サポート対象

すべて

SQLキャッシュの有効化または無効化

SQLキャッシュを以下のように制御します。

Oracle

Open Target

最高のパフォーマンスを得るためのSQLキャッシュの調整

以下の手順に従って、アクティブなステートメントの数が複製される操作に最適であることを確認してください。

1. sp_ctrlを実行し、show post detailコマンドを実行して、キャッシュされたステートメントのヒット率を測定します。
2. SQL cache hit countフィールドを探します。これは、シンタックス解析とバインディングを行わずに実行されたメッセージの総数を、INSERT、UPDATE、およびDELETE操作の総数で割った比率を示しています。例えば、36 %のヒット率は、キャッシュされたステートメントをPostがある一定時間の36 %という割合で使用していることを示します。
3. 典型的なレプリケーションアクティビティを数日間行った後にヒット率を表示し、アクティブなステートメント数の理想的な設定を測定します。ヒット率が50 %未満の場合は、パラメーター値を約5ステートメントなどのように少しずつ増やしていきます。
4. その後、ヒット率を数日間監視します。ヒット率が増加する場合、アクティブステートメントに許可されているすべてのカーソルをアプリケーションが使用していることを意味します。ヒット率が一定になるまで、パラメーターの値を少しずつ大きくし続けます。

オープンカーソルの調整

Oracleターゲットで有効

OracleのパラメーターOPEN_CURSORSの値は、Postプロセスに期待されるパフォーマンスレベルをサポートするために十分に大きい値に設定する必要があります。このパラメーターは、プロセス（Postなど）が開くことができるカーソルの最大数を定義します。

内部的に、PostはOPEN_CURSORSの値からルーチン呼び出しに必要な10個を除いたオープンカーソルの最大総数を設定します。この値はevent_logで確認できます。以下の例では、OPEN_CURSORSは512に設定されています。

Notice: sp_opst_mt (for o.oracle-o.oracle queue oracle) Post will not open more than 502 cursors (OPEN_CURSORS – 10).

Postは開いているカーソル数の記録を保持します。Postはカーソルの最大数を超えることを検出した場合、最も長い間使用されていないセッション内の最も長い間使用されていないカーソルを閉じます。

カーソル不足を回避するために、Postプロセスは開始時にOPEN_CURSORSの値を問い合わせます。この値が十分でない場合、Postは以下の警告をevent_logに書き込みます。

Warning: (sp_opst_mt for o.oracle-o.oracle queue oracle)Oracle parameter 'OPEN_CURSORS' is < number. Check 'OPEN_CURSORS' setting.

OPEN_CURSORSの値は、変更することも、ない場合に追加することもできます。

OPEN_CURSORSの値を表示するには、以下のSQLステートメントを使用してデータベースに問い合わせます。

select value from v$parameter where name = 'open_cursors';

Postプロセスに十分なOPEN_CURSORSの値を見積もるには:

1. ターゲットインスタンスで予想される同時トランザクション（セッション）のピーク数を見積もります。Postは、ソースシステム上の各セッションに対してターゲットシステム上のセッションを開きます。本番環境が最大レベルのときにsp_ctrlでshowpost detailコマンドを実行することによりトランザクション数の適切な概算を得ることができます。ディスプレイのNumber of Open Transactionsフィールドは、同時トランザクションの数を示します。

2. 以下の式を使用して、SharePlex（およびターゲットデータにアクセスする可能性のある他のアプリケーション）をサポートするためのOPEN_CURSORSの適切な設定を決定します。

   SQLキャッシュが有効（デフォルト）: デフォルトでは、Postは、終了すると閉じるルーチン呼び出しのために10個のカーソルと、トランザクションごとに少なくとも7個のカーソルを確保する必要があります（基本は少なくとも2個と追加の5個）。計算式は以下の通りです。

   10 + (同時トランザクションのピーク数 x 7) =必要な最小限のオープンカーソル数

   SQLキャッシュが無効: Postプロセスは、終了すると閉じるルーチン呼び出しのために10個のカーソルと、トランザクションごとに少なくとも2個のカーソルを確保する必要があります。計算式は以下の通りです。

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

メンテナンスDMLのスキップ

大規模なメンテナンストランザクションのスキップ

Oracleターゲットで有効

アプリケーションのパッチやその他のOracleの内部操作で適用される大規模トランザクションは、ユーザアプリケーションに必要なデータと関連がない場合、レプリケーションから除外できます。これらの操作は、Postによって適用されるSharePlexの数千または数百万の個別のUPDATE文またはDELETE文に変換することができます。このようなトランザクションは、ポストのパフォーマンスに悪影響を及ぼし、ユーザアプリケーションの作業実行に必要なソースデータとターゲットデータ間のレイテンシを増加させる可能性があります。他のDML操作がターゲットデータベースにポストされるのを防止する理由があるかもしれません。

このようなトランザクションの取り扱いには以下の2つの方法があります。

• これらの操作とユーザデータとの間に参照関係がないと仮定して、これらの操作が専用の名前付きpostキューを通して処理されるように設定します。詳細については、名前付きpostキューの設定を参照してください。
• 操作をスキップするようにPostを設定し、Oracleを通してSQLステートメントを直接適用します。以下の説明を参照してください。

メンテナンスDMLをスキップするには:

1. ソースシステムで、SharePlexの製品ディレクトリのutilサブディレクトリからcreate_ignore.sqlスクリプトを実行します。このスクリプトは、データベースにSHAREPLEX_IGNORE_TRANSパブリックプロシージャを作成します。トランザクションの開始時に実行されると、このプロシージャは、トランザクションがコミットまたはロールバックされるまで、行われたDML操作を無視するようにCaptureプロセスに指示します。そのため、影響を受ける操作は複製されません。スクリプトの詳細、制限、実行方法については、『SharePlexリファレンスガイド』の「create_ignore.sql」を参照してください。
2. パッチスクリプトを編集して、UPDATEまたはDELETE操作の前にSHAREPLEX_IGNORE_TRANSを呼び出します。これにより、SharePlexでトランザクションを無視し、ターゲットに送信しないように設定できます。このスクリプトは、データベースを同期させるためにターゲットでも実行する必要があります。

注意: SHAREPLEX_IGNORE_TRANSプロシージャの影響を受けるのはDML操作のみです。SharePlexにTRUNCATEを含むDDL操作をスキップさせることはありません。DDL操作はOracleによって暗黙的にコミットされるため、プロシージャは無効になります。