Chat now with support
Chat with Support

SharePlex 8.6.6 - リファレンス・ガイド

このガイドについて このガイドで使用されている表記規則 SharePlex コマンド SharePlex パラメータ SharePlex ユーティリティ 付録 B:SharePlex 環境変数

複数のピアデータベースを保持するための複製の設定

ここでは、複数の Oracle データベースを保持する目的で SharePlex をセットアップする方法について説明します。Oracle データベースでは、各システム上のアプリケーションが同じデータを変更できると同時に、SharePlex で複製されることによって、すべてのデータが同期済みの状態となります。これは、ピアトゥピアまたはアクティブ / アクティブレプリケーションと呼ばれています。この方法において、データベースは、通常、相互にミラーイメージであり、すべてのオブジェクトが欠けることなくすべてのシステムに存在します。ピアトゥピア方式と高可用性方式には同様のメリットがあります。ただし、ピアトゥピア方式では同じデータを同時に変更できますが、高可用性方式ではプライマリデータベースがオフラインになった場合にのみセカンダリデータベースへの変更が許可される点が異なります。

この方法では、以下のビジネス要件がサポートされます。

  • 異なる場所で複数のインスタンスを動作させることによって、ミッションクリティカルなデータの可用性を保つ。
  • オンライントランザクション処理アプリケーション(OLTP)の大きな負荷を複数のアクセスポイント間で分散する。
  • 重要なデータベースへの直接アクセスを制限する一方で、ファイアウォールの外部のユーザーが自分のデータのコピーを更新できるようにする。

ピアトゥピアレプリケーションの例として、3 つの同じデータベースを利用している電子商取引会社があります。ユーザーが Web ブラウザからアプリケーションにアクセスしたとき、Web サーバはこれらのデータベースのいずれかに総当りで順に接続します。もしそのうち 1 つのデータベースが使用不可の場合、サーバは使用可能な別のデータベースサーバに接続します。したがって、この設定は、フェイルオーバーリソースとしてだけでなく、すべてのピアの間で均一に負荷を分散する手段としても役立ちます。会社がビジネスレポートを作成する必要がある場合は、いずれかのデータベースへのユーザーアクセスを一時的に停止し、そのデータベースを使用してレポートを実行できます。

:ピアトゥピアレプリケーションで加えられたデータの変更はマシン間でループバックされません。これは、Post プロセスによってローカルシステム上で実行されたトランザクションは Capture で無視されるためです。

ピアトゥピアレプリケーションは、すべての複製環境に適していません。データベースデザインに対する大規模なコミットメントを要するので、パッケージアプリケーションを使用している場合は、実用的でない可能性があります。さらに、conflict resolution ルーチンを開発する必要もあります。これは、同時刻またはほぼ同時刻に同じデータに対して複数の変更が加えられた場合に、SharePlex が特定のデータベースに post するトランザクションを優先順位付けするために使用します。

サポートされるターゲット

Oracle

機能

この複製方法では以下がサポートされます。

  • 名前付き export キューおよび post キューの使用

この複製方法では、次の項目はサポートされません。

  • LOB の複製。LOB を含むテーブルが複製に含まれている場合、LOB は conflict resolution によってバイパスされます。そのため、データが非同期になる可能性があります。
  • 列マッピングおよび分割レプリケーションは、ピアトゥピア設定には適していません。

必要条件

  • ピアトゥピアレプリケーションに関係するすべてのテーブルには、プライマリキーか、null が許容される列を持たない一意のキーが存在している必要があります。各キーは、複製に関係するすべてのデータベースの同じ owner.table.row を一意に識別する必要があります。このトピックの追加の要件を参照してください。
  • ピアトゥピア設定のすべてのデータベースでプライマリキー、一意のキー、および外部キーのサプリメンタルロギングを有効にします。
  • すべてのシステムでアーカイブログを有効にします。
  • 複製先の環境を用意します。詳細については、次を参照: 複製のための Oracle 環境の準備
  • 同期の概念を理解する必要があります。詳細については、次を参照: 同期の概念について

概要

ピアトゥピアレプリケーションでは、DML の変更は、通常別のシステムにある異なるデータベースの同一テーブルのコピーに対して許可されます。SharePlex は、複製によってすべてのデータベースを最新の状態に保ちます。複数のデータベースで同時に(またはほぼ同時に)レコードが変更されると競合が発生する可能性があるため、不一致を解決するために conflict resolution ロジックを適用する必要があります。

競合とは

競合は、ソースおよびターゲットテーブルが同一でない非同期状態として定義されます。次の理由によりターゲットテーブルの行に SharePlex が作成した DML メッセージを実行できない場合、非同期(競合)状態を予期することができます。

  • Post が複製された INSERT を適用したときに、同じキーを持つ行がすでにターゲットに存在します。Post は、以下のロジックを適用します。

    • ターゲット行のすべての現在の値が INSERT の値と同じ場合、Post は行が同期されているとみなし、この操作を破棄します。
    • いずれかの値が INSERT の値と異なる場合、Post はこれを非同期状態とみなします。

    注: Post が INSERT を post するときに非キー値を考慮しないように設定できます。『 SharePlex リファレンスガイド』の SP_OPO_SUPPRESSED_OOS パラメータの説明を参照してください。

  • Post が複製された UPDATE を適用したときに、UPDATE とキー値が同じ行がターゲットに見つからないか、正しい行が見つかったが行の値が UPDATE の前の値と一致しません。Post は、以下のロジックを適用します。

    • ターゲット行の現在の値が UPDATE の後の値と一致する場合、Post は行が同期されているとみなし、この操作を破棄します。
    • ターゲット行の値が UPDATE の前または後の値と一致しない場合、Post はこれを非同期状態とみなします。

    注: ターゲット行の現在の値が UPDATE の後の値と一致する場合に非同期メッセージを返すように Post を設定できます。『 SharePlex リファレンスガイド』の SP_OPO_SUPPRESSED_OOS パラメータの説明を参照してください。

  • ソースデータに対して DELETE が実行されたが、Post がキーを使用してターゲット行を見つけられません。Post は、DELETE 文を作成するときに、キー値のみを WHERE 句に含めます。行がターゲットに存在しない場合、Post はこの操作を破棄します。

ピアトゥピアレプリケーションで競合が発生する理由

SharePlex による非同期の決定方法は、次の通常および非同期の例を参照してください。この例では、3 つのシステム(SysA、SysB、SysC)が使用されています。

例では、次のテーブルが使用されています。

Scott.employee_source

jane.employee_backup

列の名前と定義は同じです。

EmpNo number(4) not null,
SocSec number(11) not null,
EmpName char(30),
Job char(10),
Salary number(7,2),
Dept number(2)

同期状態の両方のテーブルの値は次のとおりです。

EmpNo(キー) SocSec EmpName Job Salary Dept
1 111-22-3333 Mary Smith Manager 50000 1
2 111-33-4444 John Doe Data Entry 20000 2
3 000-11-2222 Mike Jones Assistant 30000 3
4 000-44-7777 Dave Brown Manager 45000 3
非同期のないピアトゥピアレプリケーションの例
  1. 午前 9 時、 SysA の UserA が EmpNo 1 の「Dept」列の数値を 2 に変更します。SharePlex がその変更を SysB および SysC に複製し、両データベースが同期したままになります。
  2. 同日午前 9 時 30 分、SysB の UserB が EmpNo が 1 になっている「Dept」列の数値を 3 に変更します。SharePlex がその変更を SysA および SysC に複製し、両データベースが同期したままになります。

行は次のように表示されます。

EmpNo(キー) SocSec EmpName Job Salary Dept
1 111-22-3333 Mary Smith Manager 50000 3
UPDATE 非同期のあるピアトゥピアレプリケーションの例
  1. 午前 11 時、SysA の UserA が EmpNo 1 の Dept の数値を 1 に更新します。同日午前 11 時 2 分、ネットワークに障害が発生します。キャプチャされた変更は、すべてのシステムの export キューに格納されます。
  2. 同日午前 11 時 5 分、ネットワークが復旧するに、SysB の UserB が EmpNo 1 の Dept 列の数値を 2 に変更します。同日午前11時10分、ネットワークが復旧します。複製データの転送を再開します。
  3. SharePlex は、UserA からの変更を SysB のデータベースに post するときに Dept 列の値を 3 と想定します(プリイメージ)。しかし、UserB によって変更されているため、この値は 2 です。プリイメージが一致しないため、SharePlex は非同期エラーを生成します。
  4. SharePlex は、UserB による変更を SysA に post するときに列の値を 3 と想定します。しかし、UserA によって変更されているため、この値は 1 です。SharePlex が非同期エラーを発生します。
  5. SharePlex が UserA および User B に作成された変更を SysC のデータベースに post しようとする場合、プリイメージが一致しないため両方の文が表示されません。SharePlex が非同期エラーを発生します。

:このシナリオを視覚的に把握するには、付録の「付録 A:ピアトゥピアの説明図」を参照してください。

展開

ピアトゥピアレプリケーションを展開するには、次のタスクを実行します。

  1. ピアトゥピア環境への適合性についてデータを評価します。推奨される変更を加えます。「データの評価」を参照してください。
  2. 各システムのデータがピアトゥピア環境の他のすべてのシステムに複製されるように SharePlex を設定します。「複製の設定」を参照してください。
  3. Post が競合を処理するルールを提供する conflict resolution ルーチンを開発します。「conflict resolution ルーチンの開発」を参照してください。
  4. conflict resolution ファイルを作成します。SharePlex はこのファイルを参照し、競合が発生したときに使用する適切な手順を決定します。「conflict_resolution.SID を使用したルーチンのリストの作成」を参照してください。

データの評価

ピアトゥピア設定で SharePlex を展開するには、次のことができる必要があります。

  • 隔離キー
  • キーの変更防止
  • シーケンス生成の制御
  • トリガ使用の制御
  • カスケード削除の解消
  • 信頼されるホストの指定
  • 優先順位の定義

アプリケーションとの連携が要求されるため、プロジェクトの構造上フェーズの間、これらの要件を考慮する必要があります。その結果、多数のパッケージアプリケーションがガイドラインに沿って作成されていないため、ピアトゥピアの展開には適していません。

各要件の詳細は、次のとおりです。

キー

ピアトゥピアレプリケーションでは、プライマリキーのみを使用できます。テーブルにプライマリキーがなく、一意の非 NULL キーがある場合、そのキーをプライマリキーに変換することができます。LONG 列をキーの一部とすることができません。

プライマリキーを配置できない場合、またすべての行が一意であるとわかっている場合は、すべてのテーブルに一意のインデックスを作成できます。

プライマリキーは、ピアトゥピアレプリケーションネットワークのすべてのデータベースで一意である必要があります。

  • つまり、全データベースにある、対応する各テーブルの同じ列を使用する必要があります。
  • 対応する行のキー列は、同じ値を持っている必要があります。

プライマリキーは、行の一意性が保証されるよう、行に関する十分な情報を含めて作成する必要があります。これで、複製された操作が一意性に反する場合に競合が発生します。また、プライマリキー値は変更できません。

プライマリキーとしてシーケンスを使用するだけでは、ピアトゥピアレプリケーションに対して十分ではない場合があります。たとえば、サンプルテーブルでシーケンスを使用してキー列 EmpNo の値を生成するとします。UserA が SysA 上で次のシーケンス値を取得し、「Jane Wilson」に対する行を挿入する場合を考えてみましょう。UserB は SysB 上で次のシーケンス値を取得し、「Jane Wilson」に対する行を挿入します。それぞれのシステムでシーケンス番号が異なり、複製された INSERT に一意キー違反がない場合でも、データの整合性が損なわれます。これは、それぞれ異なるキーを持つ「Jane Wilson」のエントリが 2 つデータベースに存在するためです。その後の UPDATE は失敗します。解決策としては、キーに他の一意の列を含めて、一意性を保証し、解決ロジックを介して解決可能な競合を発生させるのに十分な情報を提供します。

シーケンス

SharePlex は、シーケンスのピアトゥピアレプリケーションをサポートしません。アプリケーションでシーケンスを使用してキーの全部または一部を生成する場合、ピアトゥピア設定の他のすべてのシステムにおいて同じ範囲の数値が生成されないようにする必要があります。シーケンスサーバを使用するか、シーケンスを各サーバで別個に管理して、それぞれに一意の範囲が割り当てられるようにすることができます。Quest は n+1 のシーケンス生成を推奨します(n = 複製のシステム数)。アプリケーションのタイプに応じて、一意性を強制するためにプライマリキーのシーケンス値にシステム名など位置の識別子を追加することができます。

トリガ

ソースシステム上でトリガが実行された結果である DML 変更は、REDO ログに入力され、SharePlex によってターゲットシステムに複製されます。同じトリガがターゲットシステムで実行される場合、非同期エラーを返します。

ピアトゥピア設定でトリガを処理するには、次のいずれかの操作を行います。

  • トリガを無効にする。
  • トリガを有効のままにするが、ピアトゥピア設定のすべてのインスタンスで SharePlex ユーザーを無視するように変更する。SharePlex には、この目的のための sp_add_trigger.sql スクリプトが用意されています。このスクリプトは、トリガの手続き文に、Post プロセスを無視するように指示する WHEN 句を置きます。トリガおよびこのスクリプトの詳細については、「複製する Oracle データベースオブジェクトのセットアップ」を参照してください。

ON DELETE CASCADE 制約

ON DELETE CASCADE 制約は、ピアトゥピアレプリケーション設定のすべてのインスタンスで有効のままにできます。ただし、以下のパラメータを設定して、これらの制約を無視するように Post に指示する必要があります。

  • SP_OPO_DEPENDENCY_CHECK パラメータ:2
  • SP_OCT_REDUCED_KEY パラメータ:0
  • SP_OPO_REDUCED_KEY パラメータ:0(他の複製シナリオではこのパラメータを異なるレベルに設定できますが、ピアトゥピア設定では 0 に設定する必要があります)

UPDATE を使用して維持される勘定値

UPDATE 文を使用して、在庫や会計バランスなど数量の変更を記録するアプリケーションは、ピアトゥピアレプリケーションの問題点を提示します。次に挙げられたオンライン書店についての例で、理由を説明します。

書店の在庫テーブルに、以下の列が含まれています。

Book_ID (primary key)

Quantity

以下の一連のイベントが発生するとします。

  1. 顧客が、1 つのサーバ上のデータベースを通して本を購入します。手元にある数量は 100 冊から 99 冊に減少します。SharePlex は UPDATE 文を他のサーバに複製します(UPDATE inventory SET quantity = 99 WHERE book_ID = 51295)。
  2. 元の UPDATE が到着する前に、他の顧客が他のサーバで同じ本を 2 冊購入します(UPDATE inventory SET quantity = 98 WHERE book_ID = 51295)。すると、そのサーバ上の数量は 100 冊から 98 冊に減ります。
  3. Post プロセスが最初のトランザクションを post しようとしたときに、プロセスは最初のシステム上のプリイメージ(100 冊)が 2 番目のシステム上の期待された値に一致しないことを認識します(2 番目のトランザクションの結果として、現在 98 冊)。Post が非同期エラーを返します。

conflict resolution プロシージャを書き込むことはできますが、正しい数値は次のように決定します。2 つのトランザクション実行後、両データベース内の正しい数値は 97 冊ですが、2 つの UPDATE 文のどちらを承認しても、結果は不適切な値になります。

このため、ピアトゥピアレプリケーションは UPDATE を使用した会計または在庫バランスを維持するアプリケーションには推奨されません。会計バランスの維持に、借方/信用勘定を使用する場合、UPDATE 文の代わりに INSERT 文(INSERT into inventory values “n”,...)を使用することができます。INSERT 文は UPDATE 文同様、 WHERE 句との前後の比較を必要としません。

アプリケーションが UPDATE 文を使用する必要がある場合、conflict resolution プロシージャを書き込んで、異なるシステムの異なる UPDATE 文から発生する絶対(または純)変動を決定することができます。たとえば、前述のオンライン書店の場合、最初の顧客の購入が 2 番目のシステムに複製されるとき、次の conflict resolution プロシージャが実行されます。

if existing_row.quantity <> old.quantity then old.quantity - new.quantity = quantity_change; update existing_row set quantity = existing_row.quantity - quantity_change;

conflict resolution ロジックは、ターゲットデータベース内にある既存の行の数値(98)が以前の数値(100 のプリイメージ)を一致しない場合、プリイメージから新しい数値(複製された数値 99)を引き算して純変動(1)を取得するよう、SharePlex に指示します。その後 UPDATE 文を発行し、「Quantity」列が 98-1 が 97 となるよう設定します。

2 番目のユーザーの変更が最初のシステムに複製されるとき、同様の conflict resolution プロシージャが実行されます。この場合、純変動(プリイメージ 100 から新しい数値 98 を引く)は 2 となります。このシステムの UPDATE 文も 99 (最初の顧客が購入した後の既存行の値)から純変動 2 を引いた値 97 を導きます。手順のロジックの結果として、各システムの「Quantity」列は 97 冊に更新され、3 冊の本を販売した正味効率となります。

財務記録の会計バランスを使用したコンセプトを、次の例で説明しています。

account_number (primary key)

balance

  1. SysA のサンプルテーブルの行(会計)に $1500 の勘定が記載されているとします。CustomerA がそのシステムで $500 の預金をしたとします。アプリケーションは UPDATE 文を使用し、勘定を $2000 に変更します。変更は SysB に UPDATE 文として (UPDATE...SET balance=$2000 WHERE account_number=51295 など)複製されます。
  2. 変更が到着する前に CustomerA の配偶者が $250 を SysB で引き出すと、アプリケーションはそのシステムのデータベースを $1250 に更新します。CustomerA のトランザクションが SysA から到着し Post がそれを SysB に post しようとすると、配偶者のトランザクションが一致せず、ソースシステムからのプリイメージが $1500 であるのに対し、ターゲットのプリイメージが $1250 であるため、競合が生じます。

conflict resolution ルーチンを書き込んで取引の絶対(または純)変動を計算してこの種のトランザクションに対処し、その値を使用して競合を解決することができます。例:

if existing_row.balance <> old.balance then old.balance - new.balance = balance_change; update existing_row set balance = existing_row.balance - balance_change;

この手順の結果により、会計バランスを預金 $500 および引き出し $250 の正味効率である $1750 に更新します。SysB では、ルーチンが SharePlex に、古い勘定 1500 新しい(複製)勘定 2000 を引き、純変動の -500 を導くよう指示します。UPDATE 文は勘定値を正しい値「1250 - (-500) = 1750 」に設定します。

SysA では、複製された値 1250 が古い勘定 1500 から差し引かれ、純変動の 250 が取得されます。UPDATE 文は既存の勘定 2000 からその数値を差し引き、正しい値の 1750 を取得します。

優先度

SharePlex が変更する正しい行を検索するとき、競合を回避または解決するために環境が確立される場合、同じ行の同じ列に対する値が 2 つまたはそれ以上のシステムで異なる場合に変更して承認する「実際の」データにのみ、競合の可能性を保持します。このため、アプリケーションは「timestamp」および「source」列の追加を承認し、ソースの名前がテーブルのローカルシステムとする必要があります。

優先順位を確定する conflict resolution ルーチンを使用するとき、これらの列が果たす重要な役割を、次のとおり説明します。

信頼されたソース

次の2つの理由で、一般的もしくは信頼されたソースとなる特定のデータベースまたはサーバを割り当てる必要があります。

  • conflict resolution ルーチンは、多くのシステムを所有するほど、非常に大きく複雑になる可能性があります。いくつかのポイントで、再同期を要求する失敗が発生する場合があります。設定のシステムの 1 つは、他のシステムが必要に応じて再同期する真のソースとみなされる必要があります。
  • conflict resolution ルーチンを書き込み、信頼されたソースシステムからの操作が他のシステムからの競合する操作に優先順位を持つことができます。たとえば、本社のサーバに行われた変更は、支社が行った同様の変更に対し優先されます。
タイムスタンプ

テーブルに「timestamp」列を表示し、 conflict resolution ルーチンの優先順位を最初のもしくは最新のタイムスタンプに割り当てることが推奨されます。ただし、競合を引き起こす場合があるため、タイムスタンプはキーの一部となることはできません。SharePlex は、キー値が変更する場合は行を検索することができ、列の 1 つがタイムスタンプである場合、キー値が変更されます。

実行するタイムスタンプの優先順位に対し、すべてのサーバがデータと時間に関し常任されていることを確認する必要があります。異なるタイムゾーンのテーブルは、グリニッジ標準時(GMT)を使用することができます。

SharePlex conflict resolution のデフォルトの日付フォーマットは、MMDDYYYY HH24MISS です。デフォルトの日付のテーブルはそのフォーマットを使用しますが、そうでない場合、conflict resolution ではエラーが返されます。デフォルトの日付のテーブルを作成する前に、次のコマンドを使用して SQL*Plus の日付フォーマットを変更します。

ALTER SESSION SET nls_date_format = 'MMDDYYYYHH24MISS'

複製の設定

ピアトゥピア設定内のシステム上の設定ファイルは、データソース指定とルーティングを除き、すべて同じになります。

構文で使用されている規則

このトピックの設定構文に使用されているプレースホルダは、環境内の以下の項目を表します。このドキュメントでは 3 つのシステムを想定していますが、さらに多くのシステムを使用することもできます。

  • hostA は、1 番目のシステムです。

  • hostB は、2 番目のシステムです。
  • hostC は、3 番目のシステムです。
  • ownerA.object は、hostA 上のオブジェクトの完全修飾名またはワイルドカード指定です。
  • ownerB.object は、hostB 上のオブジェクトの完全修飾名またはワイルドカード指定です。
  • ownerC.object は、hostC 上のオブジェクトの完全修飾名またはワイルドカード指定です。
  • oraA は、hostA 上の Oracle インスタンスです。
  • oraB は、hostB 上の Oracle インスタンスです。
  • oraC は、hostC 上の Oracle インスタンスです。

重要!

hostA での設定

Datasource:o.oraA

ownerA.object ownerB.object hostB@o.oraB
ownerA.object ownerB.object hostB@o.oraB
ownerA.object ownerC.object hostC@o.oraC
ownerA.object ownerC.object hostC@o.oraC

注:すべてのシステムですべての所有者名とテーブル名が同じ場合は、これらの各設定ファイルに対して複合ルーティングマップを使用できます。 例として、hostA からの複製の複合ルーティングを次に示します。

Datasource:o.oraA
owner.object owner.object hostB@o.oraB+hostC@o.oraC

hostB での設定

Datasource:o.oraB

ownerB.object ownerA.object hostA@o.oraA
ownerB.object ownerA.object hostA@o.oraA
ownerB.object ownerC.object hostC@o.oraC
ownerB.object ownerC.object hostC@o.oraC

hostC での設定

Datasource:o.oraC

ownerC.object ownerA.object hostA@o.oraA
ownerC.object ownerA.object hostA@o.oraA
ownerC.object ownerB.object hostB@o.oraB
ownerC.object ownerB.object hostB@o.oraB
例:
Datasource:o.oraA
hr.emp hr.emp hostB@o.oraB
hr.sal hr.sal hostB@o.oraB
cust.% cust.% hostB@o.oraB

conflict resolution ルーチンの開発

conflict resolution ルーチンを作成するには、競合が発生したときの SharePlex のアクションを指示する PL/SQL プロシージャを記述します。ビジネスルールは会社ごとに大きく異なるため、あらゆる状況に適用できる conflict resolution ルールと構文の標準セットを作成するのは不可能です。通常は、自分でルーチンを記述する必要があります。サイトやシステムの優先順位をプライマリルーティンやタイムスタンプをセカンダリルーティンにするなど、2 つ以上の手順を書き込むことは、良い実行例です。SharePlex は、ルーチンが成功するまで、または有効な手順がなくなるまでルーチンを順番に起動します。

SharePlex には、ルーチンの土台として使用できる以下のツールが用意されています。

重要!

  • この文書では、ガイドライン、事例、テンプレートを提供していますが、実際のルーチンとして使用することはできません。
  • トランスフォーメーションルーチンを作成する前に、そのルーチンをテストして、意図したとおりに機能すること、およびあるルーチンが別のルーチンに対して反作用しないことを確認します。
  • デフォルト設定では、SharePlex は非同期条件に対して停止しません。conflict resolution の失敗した志向が解決していない場合、データベースはより非同期となる場合があります。sp_ctrlshow log コマンドを使用して、イベントログを頻繁にチェックして非同期警告を監視します。show log およびその他の SharePlex コマンドの詳細は、『 SharePlex リファレンスガイド』 を参照してください。
  • conflict resolution ロジックは不定期に更新されます。これらの手順を補足または置き換える追加情報については、ご使用の SharePlex のバージョンのリリースノートおよび文書を参照してください。

SharePlex 汎用インターフェイスを使用してルーチンを記述する方法

SharePlex には、自分で記述する手続きルーチンとの間で情報をやり取りするための、generic conflict resolution PL/SQL パッケージが用意されています。作業を開始する前に、次のガイドラインを理解してください。

  • 同じ PL/SQL パッケージが generic conflict resolution とトランスフォーメーションの両方に使用されます(名前は sp_cr)。generic conflict resolution またはトランスフォーメーションの「どちらか一方」を使用するか、またはどちらも使用しません。変換されたテーブルは SharePlex で比較できず、conflict resolution は成功しません。両方を使用した場合、SharePlex はトランスフォーメーションルーチンのみを呼び出します。適切であれば、generic conflict resolution およびトランスフォーメーションを同じ設定の異なるテーブルに使用することができます。トランスフォーメーションの詳細については、「データのトランスフォーメーション」を参照してください。
  • conflict resolution を DDL の変更に使用することはできません。
  • トランスフォーメーションを行うために PL/SQL を介してアクセスされるテーブルは、SharePlex に対するオブジェクトの所有者から明示的に許可された権限を必要とします。
  • Conflict resolution は LONG または LOB 列への変更をサポートしていません。

注: 『SharePlex インストールガイド』の SharePlex conflict resolution デモンストレーションを実行した場合、デモンストレーションに使用されるデータベースにインストールされた od_employee_gen ルーチンを表示することで、サンプルの generic conflict resolution ルーチンを表示することができます。

プロシージャインターフェイス

このテンプレートに従ってプロシージャを作成します。

(table_info in outsplex.sp_cr.row_typ, col_values insplex.sp_cr.col_def_tabtyp)

ここで、

  • splex は、SharePlex スキーマです。
  • sp_cr は、PL/SQL レコードおよびテーブル構造を含むパッケージの名前です。
  • row_typ は、in 変数および out 変数を渡す PL/SQL レコードの名前です(「パッケージ定義」を参照してください)。
  • col_def_type は、列情報を格納する PL/SQL テーブルの名前です(「col_def_type テーブル」を参照してください)。

パッケージ定義

SharePlex は、SharePlex データベーススキーマの sp_cr という名前のパブリックパッケージに PL/SQL レコードおよびテーブル構造を定義します。このパッケージは、次のパラメータを使用します。

"CREATE or REPLACE PACKAGE %s.sp_cr AS 
        "TYPE row_typ IS RECORD  
        "(src_host VARCHAR2(32), 
        "src_ora_sid VARCHAR2(32), 
        "src_ora_time VARCHAR2(20), 
        "source_rowid VARCHAR2(20), 
        "target_rowid VARCHAR2(20), 
        "statement_type VARCHAR2(6), 
        "source_table VARCHAR2(78), 
        "target_table VARCHAR2(78), \n\t"
        "oracle_err NUMBER, 
        "status NUMBER, 
        "action NUMBER, 
        "reporting NUMBER 
        "); 
IN 変数

競合を引き起こす行操作のたびに、SharePlex はこのメタデータ情報をプロシージャに渡します。

変数 説明
src_host (操作が発生した)ソースシステムの名前。これには大文字と小文字の区別があり、たとえば SysA というようにソースシステムと同じ大文字/小文字を用いて渡されます。指定した post キューがターゲットシステムで使用中である場合、この変数は、たとえば postq1 というように post キュー の名前で構成されます。
src_ora_sid ソースデータベースの ORACLE_SID。これには大文字と小文字の区別があり、Windows レジストリまたは V$PARAMETER テーブルの oratab ファイルと同じ大文字/小文字を用いて渡されます。
src_ora_time ソース REDO ログ内の変更レコードのタイムスタンプ。
source_rowid ソース行の行識別子。これは、たとえば ‘123456’ というように一重引用符で囲まれたリテラルとして渡されます。
target_rowid ターゲットデータベース内の対応する行の行識別子。SharePlex は、ターゲットデータベースへのクエリによって行識別子を取得します。これは、たとえば ‘123456’ というように一重引用符で囲まれたリテラルとして渡されます。PRIMARY キーを使用しても行が見つからない場合、値は NULL です。
statement_type I、U または D のいずれかの文字。操作が INSERT 文、UPDATE 文、DELETE 文のいずれであるのかを示します。
source_table ソーステーブルの所有者および名前。owner.table 形式で記述します。この値には大文字と小文字の区別があり、データベースでテーブルが指定される方法に一致します。これは、たとえば "scott"."emp." というように二重引用符で囲まれて渡されます。
target_table ターゲットテーブルの所有者および名前。owner.table 形式で記述します。この値には大文字と小文字の区別があり、データベースでテーブルが指定される方法に一致します。これは、たとえば "scott"."emp." というように二重引用符で囲まれて渡されます。
oracle_err

プロシージャが競合解決とトランスフォーメーションのどちらに使用されるかに応じて異なります。

トランスフォーメーション:SharePlex はこの変数については 0 の値を渡します。この変数は、conflict resolution に対してのみ使用します。

競合解決: 競合を引き起こした Oracle エラー番号。

OUT 変数

これらの変数は、プロシージャが成功したか失敗したかに応じて、SharePlex の動作を指示します。

変数 説明
status

プロシージャが成功したかどうかを定義します。このパラメータについては、値を指定する必要があります。

  • 0 の値は実行に成功したことを意味します。プロシージャが競合解決とトランスフォーメーションのどちらに使用されるかに応じて、動作が異なります。

    トランスフォーメーション:Post は SQL を書き込みません。トランスフォーメーション が成功すると、SharePlex は Event Log にはいかなるエラーメッセージも書き込みません。post キューの次の複製操作を読み込んで処理を継続します。

  • 競合解決:0 の値は SharePlex に SQL 文の処理を進めるよう指示します。conflict resolution が成功すると、SharePlex は Event Log にはいかなるエラーメッセージも書き込みません。
  • 1 の値はプロシージャが成功しなかったことを示します。この場合、 SharePlex が行う動作は、 action 変数として指定する内容によって決まります。
  • トランスフォーメーションのみ)7 の値は実行に失敗したことを意味し、Post プロセスの停止を指示します。
action

SharePlex で実行するアクションを定義します。これは、プロシージャがトランスフォーメーションと競合解決のどちらに使用されるかに応じて異なります。

トランスフォーメーション:このパラメータについては 0 の値を指定する必要があります。この値は、SQL 文を post しないよう SharePlex に指示します。トランスフォーメーションルーチンは、トランスフォーメーションの結果をターゲットテーブルまたは別のテーブルのどちらかに post します。この動作の結果は、reporting 変数について指定する内容によって決まります。

競合解決:競合解決プロシージャが失敗した結果として実行するアクションを指定します。このパラメータについては、値を指定する必要があります。

  • 0 の値は SharePlex が SQL 文を post 「しない」よう指示します。この動作の結果は、reporting 変数について指定する内容によって決まります。
  • 1 の値は SharePlex の内部使用のために保持されます。この値は使用しないでください。
  • conflict resolution ファイルが存在する場合、SharePlex がファイルに一覧化した次の conflict resolution プロシージャを試行するよう指示します。
reporting

プロシージャの失敗をどのように SharePlex が報告するかを決定します。このパラメータについては、値を指定する必要があります。

  • 0 の値は、エラーを報告したり、失敗した SQL 文を SID_errlog.sql ログに書き込んだりしないよう SharePlex に指示します。
  • 1 と 2 の値は、SharePlex の内部での使用のために保持されます。これらの値は使用しないでください。
  • 3 の値は、失敗した SQL 文を SID_errlog.sql ログに書き込んで、エラーを Event Log に出力するよう SharePlex に指示します。

col_def_type テーブル

SharePlex は、複製した操作ごとに col_def_tabtyp PL/SQL テーブルを作成します。このテーブルには、列情報が格納されます。これは、プロシージャがトランスフォーメーションと競合解決のどちらに使用されるかに応じて異なります。

  • トランスフォーメーション:SharePlex は行操作ごとに、列情報を col_def_type に書き込みます。
  • 競合解決:競合を引き起こす各行操作に対し、SharePlex は列情報を col_def_tabtyp に書き込みます。

SharePlex が行を特定できない場合、すべてのフィールドが値を備えているわけではないにもかかわらず、SharePlex はルーチンにすべてのフィールドを渡します。

col_def_tabtyp テーブルに値を設定するためのデータ型を以下に示します。

type col_def_typ is record
	(column_name	user_tab_columns.column_name%type
	,datatype	user_tab_columns.datatype%type
	,is_key	boolean
	,is_changed	boolean
	,old_value	varchar2(32764)
	,new_value	varchar2(32764)
	,current_value	varchar2(32764)
	);
type col_def_tabtyp is table of col_def_typ
col_def_tabtyp の説明
説明
column_name たとえば emp_last_name というように、ソーステーブルから複製された列の名前をプロシージャに伝えます。この値には、大文字と小文字の区別はありません。
datatype たとえば VARCHAR2 というように、複製された列のデータのデータ型をプロシージャに伝えます。この値は常に大文字です。
is_key 列がキー列であるかどうかをプロシージャに伝えます。キー列である場合、SharePlex は TRUE の値を渡します。キー列の一部でなければ、SharePlex は FALSE の値を渡します。
is_changed

列の値が変更されたかどうかをプロシージャに伝えます。値が変更されている場合、SharePlex は TRUE の値を渡します。列が変更されていなければ、SharePlex は FALSE の値を渡します。

  • INSERT の場合、データベースには列が存在しないため、is_changed は非NULL の値に対してTRUEです。NULL の値が挿入されると、is_changed は FALSE になります。
  • UPDATE の場合、is_changed は非キー列に対して TRUEです。キー列の場合、is_changed は通常 FALSE です。ただし、SharePlex は、変更されたキー列の値を渡します。

    競合解決のみ:ターゲットシステムでキー値も変更された場合、SharePlex が正しい行を特定できず、競合解決が失敗することがあります。

  • DELETE の場合、SharePlex は DELETE 文のキーの値のみを複製するため、is_changed は常に FALSE です。
old_value

複製した列の古い値がソースシステムで変更される前にその値をプロシージャに伝えます。INSERT の前にターゲットデータベースに行が存在しなかったため、この列は INSERT に対して NULL です。

競合解決のみ:これは、SharePlex が UPDATE と DELETE のための同期チェックの一部としてソースおよびターゲット列を比較したプリイメージです。SharePlex によって渡された古い値がターゲット行から取得した current_value 値と一致しない場合、競合が存在します。

new_value 複製した列がソースシステムで変更されたときにその新しい値をプロシージャに伝えます。
current_value ターゲットテーブルの列の現在の値をプロシージャに伝えます。SharePlex がターゲット行を特定できない場合、値は NULL です。
操作タイプごとの col_def_tabtyp テーブルのエントリの例

次のテーブルは、操作のそれぞれのタイプについて起こり得る結果を示しています。

INSERT 操作
column_name is_changed old_value new_value current_value1 is_key
C1 TRUE NULL bind NULL FALSE
C2 TRUE NULL bind NULL TRUE
C3 FALSE NULL NULL NULL TRUE | FALSE

1 INSERT が失敗した場合、その原因は同じ PRIMARY キーを持つ行がすでにターゲットデータベースに存在することにあります。SharePlex は INSERT に現在の値を返しません。

UPDATE 操作
column_name is_changed old_value new_value current_value1、2 is_key
C1 TRUE bind bind NULL | target_value FALSE
C2 FALSE bind NULL NULL | target_value TRUE
C3 TRUE bind bind NULL | target_value TRUE

1(競合解決)UPDATE が失敗した場合、その原因は SharePlex が PRIMARY キーおよびプリイメージを使用して行を見つけられないことにあります。行が見つからない場合、SharePlex は、PRIMARY キーのみを使用して行を検索します。行が見つかった場合、SharePlex は、変更された列だけでなくキー列についても現在の値を返します。SharePlex が PRIMARY キーのみを使用して行を見つけることができない場合、SharePlexNULL を返します。

2(トランスフォーメーション)UPDATE の場合、トランスフォーメーションのためにプリイメージが異なっているので、PRIMARY キーとプリイメージを使用しても SharePlex は行を特定できません。別の方法として、PRIMARY キーのみを使用して行を検索します。行が見つかった場合、SharePlex は、変更された列だけでなくキー列についても現在の値を返します。PRIMARY キーのみを使用して行を特定できない場合、current_value は NULL です。

DELETE 操作
column_name is_changed old_value new_value current_value1 is_key
C1 FALSE bind NULL NULL TRUE

1 DELETE が失敗した場合、その原因は SharePlex が PRIMARY キーを使用して行を見つけられないことにあります。したがって、SharePlex は NULL を返します。

SharePlex の準備されたルーチンを使用する方法

SharePlex は、カスタムルーチンと組み合わせて使用する、次のオプションの準備されたルーチンを提供します。これらのオプションは基本および generic conflict resolution フォーマットで使用されます。次の準備されたプロシージャでは、列タイプに関する制限はありません。

!UpdateUsingKeyOnly prepared routine

!MostRecentRecord(column_name) prepared routine

!UpdateUsingKeyOnly prepared routine

SharePlex は、UPDATE 操作のために、準備された conflict resolution ルーチンを提供します。変更された行のキー値に単独で依存する競合解決機能を提供します。

通常、SharePlex が SQL 文を作成してデータを post するとき、WHERE 句は同期を保証するために変更された列のキーおよびプリイメージを使用します。!UpdateUsingKeyOnly ルーチンは、キーが一致しているにかかわらずプリイメージ値が一致しない場合であっても、SharePlex がデータを post するように指示します。

適切であれば、このルーチンは UPDATE に対する単独ルーチンとして使用できます。ただし、複数の同時 UPDATE の場合、システムあるいは時間優先権などの優先順位を割り当てるロジックが含まれないことを理解する必要があります。非同期エラーを回避するために、Quest は、カスタムルーチンが失敗した場合の最後のオプションとして !UpdateUsingKeyOnly に依存し、!UpdateUsingKeyOnly を他の特定のルーチンと一緒に使用することを推奨します。

重要: !UpdateUsingKeyOnly はルーチンのリストの最後のエントリである必要があるため、最終優先順位を割り当てます。

次の例で、UPDATE 実行中に owner.table1 に対する競合がある場合、SharePlex はまず 2 つのカスタムルーチンを呼び出し(優先順位に従って)、その後 !UpdateUsingKeyOnly ルーチンを呼び出します。

owner.table1 u owner.procedure_up_A
owner.table1 u owner.procedure_up_B
owner.table1 u !UpdateUsingKeyOnly

!UpdateUsingKeyOnly の名前は、大文字、小文字が区別されます。これらの指示に示されているとおり、文字の間にスペースを入れず正確に入力する必要があります。このルーチンと所有者名を、設定ファイルに一覧化してはいけません。「conflict_resolution.SID を使用したルーチンのリストの作成」を参照してください。

INSERT および DELETE の操作の場合、カスタムロジックを使用する必要があります。

!MostRecentRecord(column_name) prepared routine

SharePlex は、UPDATE および DELETE 操作のために、準備された conflict resolution ルーチンを提供します。SharePlex は、column_name の値に基づいて conflict resolution を提供します。

通常、SharePlex が SQL 文を作成してデータを post するとき、WHERE 句は同期を保証するために変更された列のキーおよびプリイメージを使用します。!MostRecentRecord ルーチンは SharePlex に、プリイメージの値が一致しない場合でもデータを Post するように指示します。このルーチンは、指定された column_name の比較に基づいて、現在の行を変更します。送信された column_name の値がターゲットの column_name の値より大きい場合、変更が適用されます。このルーチンは、時間ベースの複製の競合を解決するために使用できます。

conflict resolution ファイルに指定されたこのルーチンの例を次に示します。「conflict_resolution.SID を使用したルーチンのリストの作成」を参照してください。

owner.table1 u owner.procedure_up_A
owner.table1 u !UpdateUsingKeyOnly
owner.table1 u !MostRecentRecord(C2)

C2 はデータ型が TIMESTAMP の column_name です

conflict_resolution.SID を使用したルーチンのリストの作成

conflict resolution プロシージャを作成した後、conflict resolution ファイルを作成します。このファイルを使用して、どのプロシージャを、どのオブジェクトおよび操作タイプに、どの順序で使用するかを SharePlex に指示します。

conflict resolution ファイルの場所

SharePlex がインストールされたときに、空の conflict_resolution.SID ファイル(SID はターゲットインスタンスの ORACLE_SID)が SharePlex 変数データディレクトリの data サブディレクトリに配置されています。このファイルをターゲットシステム上で使用します。

このファイルが存在しない場合は、ASCII テキストエディタを用いて ASCII フォーマットで作成します。ファイル名は conflict_resolution.SID にする必要があります。SID はターゲットインスタンスの ORACLE_SID です。注:SID には、英大文字と小文字の区別があります。

重要! conflict_resolution.SID ファイルは、アクティブな設定ごとに 1 つだけです。

conflict resolution ファイルにエントリを作成する方法

次のテンプレートを使用して、プロシージャを 1 つまたは複数のオブジェクトおよび操作タイプにリンクします。

owner.object {i | u | d | iud} owner.procedure

ここで、

  • owner.object は、target オブジェクトの所有者と名前、またはワイルドカードエントリです(「構文規則」を参照してください)。
  • i| u | d は、指定したプロシージャで解決する競合を作成する操作のタイプです。任意の操作タイプまたはすべての操作タイプを指定できます(たとえば、idiud)。大文字と小文字のどちらも有効です。
  • owner.procedure は、指定したオブジェクトと操作タイプを処理する conflict resolution プロシージャの所有者と名前です。

構文規則

  • オブジェクト指定、操作タイプ指定、およびプロシージャ指定の間には、1 つ以上のスペースが必要です。
  • LIKE 演算子と SQL ワイルドカード(%)を使用して、検索文字列によって複数のオブジェクトを指定できます(例を参照)。
  • 1 文字のワイルドカードを表すには、アンダーライン(_)を使用できます。アンダーライン文字が含まれるテーブル名の場合(emp_sal など)、SharePlex は、バックスラッシュ(\)については、アンダーラインをワイルドカードではなくリテラルとして表すエスケープ文字として認識します(例:like:scott.%\_corp\_emp)。LIKE 演算子を使用しない場合は、オブジェクト名にアンダーラインが含まれていても、バックスラッシュのエスケープ文字は不要です。
  • conflict resolution ファイルに記述したプロシージャの順序に基づいて、使用する際の優先順位が決まります(降順)。テーブルに固有のプロシージャを記述した場合、SharePlex は、ワイルドカードで指定されたオブジェクト名を持つプロシージャよりも先にそのプロシージャを使用します。
  • コメント行は、ファイル内のどこにでも記述できます。コメント行は、ポンド記号(#)で開始します。

conflict resolution ファイルの例

scott.sal IUD scott.sal_cr
like:scott.%\_corp\_emp IUD scott.emp_cr1
like:scott.%\_corp\_emp IUD scott.emp_cr2
like:scott% IUD scott.emp_cr3
scott.cust U scott.sal_cr

動作

  • scott.sal_cr routine ルーチンが scott.sal テーブルに使用され、その後 scott.emp_cr1 プロシージャがそのテーブルに使用されます。
  • scott.emp_cr1 プロシージャが使用された後、scott.emp_cr2 プロシージャが検索基準などに一致するすべてのテーブルに使用されます。
  • scott.cust の場合、プロシージャが UPDATE のために呼び出され、他のルーチンがすべての操作に使用されます。

SharePlex の準備されたルーチンを conflict resolution ファイルに指定する方法

SharePlex の準備されたルーチンを複製設定内のすべてのテーブルに対して使用するには、所有者とオブジェクト名を指定する代わりに !DEFAULT パラメータを使用します。

カスタムルーチンは SharePlex の準備されたルーチンよりも優先されます。準備されたルーチンは、カスタムルーチンが失敗した場合のみ使用されます。実際、!DEFAULT 関連ルーチンがファイルに表示される順番とは関係ありません。

!DEFAULT パラメータは大文字、小文字が区別されます。すべて大文字で入力される必要があります。

次の例では、james.table1 に対してリストされているユーザー定義プロシージャが優先されますが、james.table1 を含むすべてのテーブルの UPDATE および DELETE には !UpdateUsingKeyOnly プロシージャが使用されます。

!DEFAULT U !UpdateUsingKeyOnly
!DEFAULT D !UpdateUsingKeyOnly
james.table1 U james.procedure_upd
james.table1 I james.procedure_ins
james.table1 D james.procedure_del

複製がアクティブのときに conflict resolution ファイルを変更する方法

conflict resolution ファイルは複製中にいつでも変更して、テーブルやプロシージャを追加したり削除したりできます。conflict resolution ファイルを変更した後、Post プロセスをいったん停止して再起動します。

解決された競合に関する情報のログへの記録

SharePlex の準備されたルーチンを使用している場合は、成功した conflict resolution 操作に関する情報をログに記録するように Post プロセスを設定できます。この機能はデフォルトで無効になっています。

Post は、情報を SHAREPLEX_CONF_LOG という名前のテーブルに記録します。このテーブルについて以下に説明します。

列定義 ログに記録される情報
CONFLICT_NO NUMBER NOT NULL 解決された競合の一意の識別子。この値は shareplex_conf_log_seq シーケンスから生成されます。
CONFLICT_TIME TIMESTAMP DEFAULT SYSTIMESTAMP conflict resolution のタイムスタンプ
SRC_HOST VARCHAR2(32) ソースシステムの名前
CURR_HOST VARCHAR2(32) ローカルホスト
TRUSTED_HOST VARCHAR2(32) 信頼されるホスト
SRC_ORA_SID VARCHAR2(32) ソースデータベースの Oracle SID
SOURCE_ROWID VARCHAR2(20) ソースシステム上の行の rowid
TARGET_ROWID VARCHAR2(20) ターゲットシステム上の行の rowid
CONFLICT_TABLE VARCHAR2(100) 競合に関係していたターゲットテーブルの名前
CONFLICT_TYPE VARCHAR2(1) 競合のタイプ。I(挿入)、U(更新)、または D(削除)のいずれか
CONFLICT_RESOLVED VARCHAR2(1) NOT NULL

競合が解決されたかどうかを示すインジケータ。

Y = はい。競合は解決されました。

N = いいえ。競合は解決されませんでした。解決されない競合は ID_errlog.sql ファイルに記録されます。ここで、ID はソースデータベース識別子です。

ORACLE_ERR VARCHAR2(10) 競合を引き起こした Oracle エラー
TIMESTAMP_COLUMN VARCHAR2(50) 最新のレコードを判定するために Post が比較したタイムスタンプを含む列の名前。
INCOMING_TIMESTAMP DATE ソースシステムで行が挿入、更新、または削除されたタイミングを示すタイムスタンプ
EXISTING_TIMESTAMP DATE ターゲットデータベース内の行の現在のタイムスタンプ。これは、SP_OPO_LOG_CONFLICT パラメータが 2(ターゲットデータベースにクエリしてこの値を取得することを Post に指示する値)に設定されている場合にのみ適用されます。
PRIMARY_KEYS VARCHAR2(4000) プライマリキー列の名前
MESSAGE VARCHAR2(400)

「競合に勝った」行を示すメッセージ。どの行が「競合に勝つ」かは、使用された conflict resolution ルーチンによって決まります。たとえば、!MostRecentRecord ルーチンが使用され、最新のレコードがソースレコードの場合、次のメッセージが返されます。

Incoming timestamp > existing timestamp.Incoming wins, overwrite existing.

ターゲットレコードが、ソースレコードではなく最新のレコードであった場合、次のメッセージが返されます。

Incoming timestamp < existing timestamp.Existing wins, discard incoming.

SQL_STATEMENT LONG conflict resolution の結果として実行された最終の SQL 文
CONFLICT_CHECKED VARCHAR2(1) 競合を確認されたかどうかを示します。デフォルトは N(No)です。競合を確認する担当者は、この値を Y に変更できます。
SEQNO NUMBER 競合の原因となった操作のレコードを含む REDO ログのシーケンス番号。
OFFSET NUMBER REDO ログ内のレコードのオフセット。
SCNSCN NUMBER 競合の原因となった操作を含むトランザクションの System Change Number。
USERID NUMBER ソースシステムで操作を実行したユーザー。
CONSTRAINT SHAREPLEX_CONF_LOG の制約の名前(conflict_no_pk)。
PRIMARY KEY   SHAREPLEX_CONF_LOG テーブルのプライマリキー列(CONFLICT_NO)

conflict resolution のロギングを有効にするには

  1. ターゲットシステムで sp_ctrl を実行します。
  2. 次のコマンドを発行します。

    sp_ctrl> set param SP_OPO_LOG_CONFLICT {1 | 2}

    • 11 に設定すると、SHAREPLEX_CONF_LOG テーブルに対する競合解決のロギングが有効になります。
    • 2 に設定するとロギングが有効になり、ターゲットデータベースにクエリしてターゲット行の現在のタイムスタンプを取得するように Post に指示します。注:2 に設定すると、クエリを実行するために Post のパフォーマンスに影響を及ぼすことがあります。
  3. Post を再起動します。
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating