Chat now with support
Chat with Support

SharePlex 8.6.6 - インストール・ガイド

このガイドについて このガイドで使用されている表記規則 SharePlex の概要 SharePlex プリインストールチェックリスト Oracle クラスタでの SharePlex のセットアップ Amazon Cloud での SharePlex のセットアップ SharePlex のダウンロード UNIX のインストールとセットアップ Windows のインストールとセットアップ セキュリティグループへの SharePlex ユーザーの割り当て SharePlex 基本デモンストレーション 上級用 SharePlex デモンストレーション インストール上の問題の解決 SharePlex のアンインストール SharePlex ユーティリティ 付録 A:高度なインストーラオプション 付録 B:root としての SharePlex のインストール 付録 C:SharePlex でインストールされるアイテム

デモ 2:分割レプリケーションのデモンストレーション

上級用 SharePlex デモンストレーション > デモ 2:分割レプリケーションのデモンストレーション

このデモンストレーションでは、「選択的な行のレプリケーション」と「選択的な列のレプリケーション」とも呼ばれている、「水平分割レプリケーション」と「垂直分割レプリケーション」の組み合わせを説明します。従業員名や部署などの選択した情報を配信する一方で個人情報や給与などのその他のデータを別のオブジェクトにデータセットとして分離しないで保護するために、垂直分割レプリケーションを使用することができます。さまざまなデータセグメントを別々のターゲットシステムへ配信するために、水平分割レプリケーションを使用することができます(たとえば、営業担当者と顧客のデータをそれに責任を持つ個々のストアへ配信)。分割レプリケーションの詳細は、『SharePlex 管理者ガイド』の第 5 章を参照してください。

  1. SharePlex デモンストレーションオブジェクトがインストールされていることを確認します。「デモンストレーションオブジェクトのインストール」を参照してください。
  2. ソース」システムの od_employee から、すべての行を削除します(TRUNCATE はしません)。od.config 設定が前のデモから引き続きアクティブな場合は、od_salary テーブルのカスケード削除の制約が od_employee の削除の結果としてアクティベートされます。SharePlex により、すべての削除が複製され、両方のターゲットテーブルからすべての行が削除されます。od.config 設定がアクティブでない場合は、ソースおよびターゲットの od_employee および od_salary テーブルからすべての行が削除されます。

  3. 水平分割レプリケーション」を実装するには、「カラムコンディション」を作成します。これは、ソースの od_employee テーブルから一定の行のみ、この例では Sales 部門の行のみを複製するように SharePlex に指示する条件構文です。カラムコンディションを作成するには、ソースシステムで SQL*Plus を実行して、SHAREPLEX_PARTITION テーブルへ次のように挿入します。変数は、SHAREPLEX_PARTITION の所有者名、ターゲットシステム名、ターゲットデータベースの ORACLE_SID で置き換えます。

    SQL> insert into owner.shareplex_partition (partition_scheme, description, route, target_table_name, ordering, col_conditions) values (‘sales_partition’, ‘Replicate only sales employees’, ‘targetsystem@o.target_SID’, ‘OD_EMPLOYEE’, 1, ‘EMP_DEPT_NO=1’);
     
    SQL> COMMIT;
  4. 「垂直」分割レプリケーションを実装するには、「ソース」システムに od.partition という名前の新しい設定を作成します。

    sp_ctrl(sysA)> create config od.partition
  5. 以下のテンプレート 2 に従って、設定を作成します。垂直分割レプリケーションは、ソースオブジェクトの後にかっこ内に現れる「カラムパーティション」を使用して、設定ファイル内に指定します。このデモンストレーションの場合、od_employee 内の EMP_DOB および EMP_TIMESTAMP 列を除くすべての列を複製するように SharePlex に指示するカラムコンディションを指定します。

    設定行は、Enter キーを押さないかぎり次の行に折り返すことができます。

    カラムパーティションのほかに、!sales_partition コンポーネントで指定されるように、通常のルーティングマップの代わりに「パーティションスキーマ」を一覧表示していることに注意してください。パーティションスキーマは、1 つ以上のカラムコンディションの論理的な「コンテナ」です。通常、ビジネスルールに基づいてそれぞれのパーティションスキーマを設計しますが、このデモンストレーションでは、「sales_partition」という名前のパーティションスキーマだけが使用されます。

    ! target_host@o.target_SID」の行も必要なことにお気付きでしょうか。構文では、ターゲットシステム名とターゲットデータベース ORACLE_SID を使用します。SharePlex は、設定ファイル内のターゲットシステム名および ORACLE_SID を参照できなければならないため、この行が必要になります。通常、この要件を満たす、ターゲットシステムに複製される他の非分割テーブルに対する設定エントリが存在していますが、この場合は 1 つしか存在していません。

    テンプレート 2:デモンストレーション設定「od.partition」

    datasource:o.source_SID    
    owner.od_employee (emp_no, emp_first_name, emp_last_name, emp_dept_no) owner.od_employee !sales_partition !target_host@o.target_SID
  6. ソースシステム上で設定をアクティベートします。

    sp_ctrl(sysA)> activate config od.partition
  7. od_add_emps を実行して、「ソース」システムの od_employee テーブルにデータを投入します。IN パラメータには、複製された後に表示のために行を選択するので、小さな値を使用します。
  8. ターゲットの od_employee テーブルからすべての行を選択します。EMP_DEPT_NO 列の値は、すべての行で「1」です。この列の値が「1」以外の行は複製されませんでした。

デモ 3:トランスフォーメーションのデモンストレーション

上級用 SharePlex デモンストレーション > デモ 3:トランスフォーメーションのデモンストレーション

SharePlex には、ターゲットデータベースに SQL 操作を適用する代わりに、Post プロセスが PL/SQL トランスフォーメーションプロシージャ(ルーチン)を呼び出す機能があります。これにより、複製されたデータを最初に操作できます。

たとえば、ソースおよびターゲットテーブルが構造的に異なる場合(人物の姓と名がソーステーブルでは 1 つの列にあるのにターゲットテーブルでは別々の列にあるなど)、変換のためのプロシージャを作成できます。データ型、測定単位、キャラクタセットの変換など、他のビジネス要件に対してトランスフォーメーションを使用することもできます。また、I/O オーバーヘッドを減らすために、データベーストリガーの代わりにトランスフォーメーションルーチンを使用することも可能です。

テーブルにトランスフォーメーションを指定すると、Post は複製されたデータに何も実行せずに、データを作成されたプロシージャに渡すだけです。データが変形された後のデータの行き先をこれで制御できるようになります。ターゲットテーブルに post したり、別の場所へ post したりができます。開発者は、ルーチンの作成時に、ターゲットデータベースへデータを post するか別の場所へ切り替えるか、またはその両方のために、必要な SQL 操作をプロシージャ内に含める責任があります。

このデモンストレーションでは、od_employee および od_salary という 2 つの別々のソーステーブルから複製されたデータを、od_sales_emp_data という名前のターゲットテーブルへ結び付ける、トランスフォーメーションプロシージャが用意されています。

  1. SharePlex デモンストレーションオブジェクトがインストールされていることを確認します。「デモンストレーションオブジェクトのインストール」を参照してください。
  2. 前のデモンストレーションを実行している場合は、139 ページの「ora_cleansp の実行」にある手順に従って、両方のシステムで ora_cleansp(Windows システムでは OraCleanSp)を実行します。これで、前のデモンストレーションからのキューが削除され、前の設定がディアクティベートされます。

    ora_cleansp を実行する前に、SharePlex をシャットダウンする必要があります。シャットダウンするには、sp_ctrl 内の shutdown コマンドを使用します。

  3. ソースおよびターゲットの od_employee テーブルから、すべての行を削除します(TRUNCATE はしません)。このテーブルには、従属する od_salary テーブルからのすべての行を削除するカスケード DELETE の制約があります。od_department テーブルからどのような行も削除しないでください。これは検索テーブルです。
  4. ターゲットシステムでデモンストレーションユーザーに sp_cr パッケージを実行する特権を与えます。このパッケージは、SharePlex が最初にインストールされたときに SharePlex スキーマ内にインストールされました。

    SQL> grant execute on sp_cr to user_name

  5. ターゲットシステムで SharePlex デモンストレーションオブジェクトを所有するユーザーとして SQL*Plus にログインし、SharePlex 製品ディレクトリの util サブディレクトリから transform.sql スクリプトを実行します。これで、od_transform_employee_insert および od_transform_employee_update デモンストレーショントランスフォーメーションルーチンがインストールされます。このプロシージャのためのスキーマと表領域、および SharePlex Oracle ユーザーの名前を要求するプロンプトが表示されます。
  6. SQL 操作の post の代わりにトランスフォーメーションルーチンを呼び出すように SharePlex に指示するには、transformation.SID ファイル(SID はターゲットデータベースの ORACLE_SID)を使用します。Post によりこのファイルがチェックされ、呼び出す必要があるトランスフォーメーションプロシージャの有無が判断されます。このファイルは、SharePlex 変数データディレクトリの data サブディレクトリ内に、SharePlex と共にインストールされます。vi テキストエディタ(UNIX および Linux)またはワードパッド(Windows)のどちらかで、ターゲットシステム上でこのファイルを開きます。

  7. 以下のテンプレート 3 に従って、ターゲットテーブルと所有者を使用し、ファイル内にエントリを作成します。少なくとも 2、3 個のスペースか 1 個のタブで、各列を区切ります。owner 変数は、正しい所有者名に置き換えます。

    テンプレート 3:デモンストレーションの transformation.SID ファイル

    owner.od_employee I owner.od_transform_employee_insert
    owner.od_employee U owner.od_transform_employee_update
    owner.od_salary I owner.od_transform_employee_insert
    owner.od_salary U owner.od_transform_employee_update
  8. ターゲットシステムで、パラメータを有効にします。

    SP_OPO_XFORM_EXCLUDE_ROWID

    sp_ctrl(sysB)> set param SP_OPO_XFORM_EXCLUDE_ROWID 1
  9. 以下のテンプレート 4 に従って、ソースシステムに、od_salary および od_employee テーブルを複製する od.transform という名前の設定を作成します。

    sp_ctrl(sysA)> create config od.transform

    テンプレート 4:デモンストレーション設定「od.transform」

    datasource:o.source_SID
    owner.od_salary owner.od_salary target_host@o.target_SID
    owner.od_employee owner.od_employee target_host@o.target_SID
  10. 設定をアクティベートします。

    sp_ctrl(sysA)> activate config od.transform
  11. od_add_emps プロシージャを使用して、「ソース」システム上の od_employee および od_salary テーブルにデータを投入します。値が 10 の IN パラメータを使用して 50 の新規従業員を od_sales_emp_data テーブル内に作成します。
  12. SQL*Plus で、「ターゲット」システム上の od_sales_emp_data からすべての行を選択し、変換されたデータを表示します。トランスフォーメーションが原因で、次のような相違点が観察されます。

    • EMPLOYEE_NAME 列には、従業員の姓と名が含まれます。これをソースの、姓と名が別々の列にある od_employee テーブルと比較します。
    • DEPARTMENT 列には部門名が含まれます。これをソースの、EMP_DEPT_NO 列に数字が含まれる od_employee テーブルと比較します。トランスフォーメーションプロシージャが od_department テーブルを参照することにより、複製された部門番号が部門名に変換されました。
    • SALARY 列には、OD_SALARY テーブルからの給与が含まれます。
  13. [オプション] UPDATE に対応してトランスフォーメーションがどのように動作するかを調べるために、od_employee テーブルを手動で更新できます。od_transform_employee_update プロシージャで、トランスフォーメーションが作成されます。このデモンストレーションをさらに進めるために、DELETE 用のトランスフォーメーションプロシージャを作成できます。

デモ 4:generic conflict resolution のデモンストレーション

上級用 SharePlex デモンストレーション > デモ 4:generic conflict resolution のデモンストレーション

Conflict resolution は、ピアトゥピアレプリケーションで採用されています。これは、通常は異なるシステムにあるレプリカのデータベース内の同じデータを複数のユーザーが並行して操作する環境での複製のシナリオです。さらに SharePlex は、すべてのデータベースの同期を保つために、変更部分を複製します。ピアトゥピアレプリケーションには、本稼動中のサーバからセカンダリシステムへ報告の目的でデータを複製するような一方向のレプリケーションには見られない、難しい問題があります。

このような設定では、セカンダリシステムのデータベースに対して DML または DDL アクティビティがあるはずはありません。ただしピアトゥピアレプリケーションでは、すべてのデータベースがアクセスされ、変更されます。対応する(または「影の」)テーブル内の同じレコードが同時に、またはほぼ同時に別々のシステムで変更される場合は、競合が発生する可能性があり、conflict resolution が必要です。

Conflict resolution は PL/SQL プロシージャ(conflict resolution ルーチン)に依存しており、このプロシージャで、変更(挿入、更新、削除)が必要な行がすでに別のユーザーに変更されていたときに何をすべきかが SharePlex Post プロセスに指示されます。たとえば、特定のソースシステムまたは最新のタイムスタンプに優先権を与えたり、特定のユーザーに優先権を与えたりすることを SharePlex に指示できます。ピアトゥピアレプリケーションの実際の本稼動用の展開では、会社のビジネスルールと複製環境に基づいて、カスタムの conflict resolution ルーチンを開発します。

 

このデモンストレーションについて

Generic conflict resolution により、PL/SQL プロシージャを使用して複数のテーブルの競合を解決できるようになります。次の競合解決の方針がデモンストレーションで示されます。

  • タイムスタンプの優先順位 – このデモンストレーションは、UPDATE に基づいています。競合がある場合は常に、最後に更新された行が優先されます。
  • ソースシステムの優先順位 - 次の手順で、競合発生時に優先される「信頼される」ソースとして、1 つのシステムを定義します。このデモンストレーションは、INSERT を基盤に置いています。信頼されるソースが発信源のすべての INSERT が、「セカンダリ」システムとして参照されるその他のシステムからの INSERT に優先します。

デモンストレーションのプロシージャ内には、DELETE に対する競合解決のロジックはありません。その代わり、SharePlex は失敗した DELETE 文を SID_errlog.sql ログに書き込み、エラーを Event Log へ報告します。さらに、この文についての情報が source.exc_table テーブルへ書き込まれます。このデモンストレーションを拡張するには、会社のビジネスルールに適合するように DELETE の競合解決ロジックを追加できます。

警告! このデモンストレーションの目的は、ピアトゥピアレプリケーションと conflict resolution の概念を紹介することです。ピアトゥピアレプリケーションを確立する基盤としてこのデモンストレーションを使用しないでください。また、提示された conflict resolution ルーチンを自分のものとして使用しないでください。ピアトゥピアレプリケーションは、すべてのビジネスアプリケーションと必ずしも互換性があるとは限りません。この複製では、使用するデータ、アプリケーション、ビジネスルールについてと、どのようにして競合が発生するかについての完全な理解が必要です。環境に適合する場合は、非常に複雑になる可能性があるカスタムの conflict resolution プロシージャの作成も含めて、注意深い実行が必要です。ピアトゥピアレプリケーションの展開を考慮する前に、『SharePlex 管理者ガイド』内のこのレプリケーション方針の確立についてお読みください。

 

デモンストレーションの準備

  1. SharePlex デモンストレーションオブジェクトがインストールされていることを確認します。「デモンストレーションオブジェクトのインストール」を参照してください。
  2. 両システムの SharePlex をシャットダウンします。

    sp_ctrl(sysA)> shutdown
     
    sp_ctrl(sysB)> shutdown
  3. 139 ページの「ora_cleansp の実行」にある手順に従って、両方のシステムで ora_cleansp(Windows システムでは OraCleanSp)を実行します。これで、前のデモンストレーションからのキューが削除され、前の設定がディアクティベートされます。
  4. 両方のシステム上の od_employee テーブルから、すべての行を削除します。od_department テーブルからどのような行も削除しないでください。これは、conflict resolution プロシージャ用の検索テーブルです。
  5. 両方のシステムでデモンストレーションユーザーに sp_cr パッケージを実行する特権を与えます。このパッケージは、SharePlex が最初にインストールされたときに SharePlex スキーマ内にインストールされました。

    SQL> grant execute on sp_cr to user_name
  6. SharePlex デモンストレーションオブジェクトを所有するユーザーとして SQL*Plus にログインし、SharePlex 製品ディレクトリの util サブディレクトリから p2p.sql スクリプトを実行します。これで、od_employee_gen デモンストレーション conflict resolution ルーチンがインストールされます。このプロシージャのためのスキーマと表領域、および SharePlex Oracle ユーザーの名前を要求するプロンプトが表示されます。さらに、競合が発生したときに優先される「信頼される」ソースマシンとなる、マシンの名前の入力が求められます。どのシステムを使用するかは問題でありません。

 

conflict resolution の設定

  1. 競合があるときに conflict resolution ルーチンを呼び出すように SharePlex に指示するには、conflict_resolution.SID ファイル(SID はローカルデータベースの ORACLE_SID)を使用します。Post によりこのファイルがチェックされ、呼び出す必要がある conflict resolution プロシージャの有無が判断されます。このファイルは、各システムの SharePlex 変数データディレクトリの data サブディレクトリ内に、SharePlex と共にインストールされます。vi テキストエディタ(UNIX および Linux)またはワードパッド(Windows)のどちらかで、このファイルを開きます。
  2. 両方のシステムの conflict_resolution.SID ファイル内に、od_employee テーブル、そのテーブルの正しい所有者、od_employee_gen プロシージャを使用して、以下のテンプレート 5 に示すようにエントリを作成します。2、3 個のスペースか 1 個のタブで、各列を区切ります。

    テンプレート 5:デモンストレーション用の conflict_resolution.SID ファイル

    owner.od_employee IUD owner.od_employee_gen
  3. 両方のシステムで、Shareplex と sp_ctrl を起動します。
  4. 以下のテンプレート 6 を参照して、「信頼されるソース」システムの od_employee テーブルをセカンダリシステムの od_employee テーブルへ複製する設定の od.cr_trusted_src を、そのソースシステムに作成します。

    sp_ctrl(sysA)> create config od.cr_trusted_src

    テンプレート 6:デモンストレーション設定「od.cr_trusted_src」

    owner.od_employee owner.od_employee secondary_host@o.secondary_SID
  5. 以下のテンプレート 7 を参考にして、上記設定と反対方向の od.cr_secondary という名前の別の設定を「セカンダリ」システム上に作成します。この設定で、セカンダリシステムの od_employee テーブルが、信頼されるソースシステムの od_employee テーブルへ複製されます。datasource には、セカンダリデータベースの ORACLE_SID を使用します。trusted_source_host には、信頼されるソースシステムの名前を使用します。trusted_source_SID には、信頼されるデータベースの ORACLE_SID を使用します。

    テンプレート 7:デモンストレーション設定「od.cr_secondary」

    datasource:o.secondary_SID
    owner.od_employee owner.od_employee trusted_source_host@o.trusted_source_SID
  6. 両方の設定をアクティベートします。

    sp_ctrl(sysA)> activate config od.cr_trusted_src

    sp_ctrl(sysB)> activate config od.cr_secondary

 

競合の作成

od_add_emps プロシージャを使用して、信頼されるソースシステムの od_employee テーブルへ最初にデータを投入します。SharePlex により、このような変更がセカンダリシステムの od_employee テーブルへ複製され、2 つのテーブルが同期します。これで、競合状態を作成できるようになります。

ソースシステムの優先順位をデモンストレーションで示すには

このデモンストレーションでは、信頼されるソースから発信された INSERT は、その他のシステムからの INSERT に優先することを示します。

  1. 両方のシステム」で、Post プロセスを停止します。
  2. セカンダリ」システムの od_employee に行を挿入しますが、COMMIT を発行しません。
  3. 「信頼される」ソースで同じ行を挿入しますが、COMMIT を発行しません。
  4. 「セカンダリ」システムで、COMMIT を発行します。
  5. 「信頼されるソース」で、COMMIT を発行します。これで、競合が発生します。
  6. 両方のシステム」で、Post プロセスを再起動します。

 

タイムスタンプの優先順位をデモンストレーションで示すには

このデモンストレーションでは、競合がある場合は常に、最後に更新された行が優先されます。

  1. 「両方のシステム」で、Post プロセスを停止します。
  2. 行を検出するために Primary Key、EMP_NO を使用して、それぞれのシステムで EMP_TIMESTAMP 列を異なる値に更新します。
  3. 他のシステムへ複製するために、「各システム」でデータを待ちます。sp_ctrl から qstatus コマンドを発行すると、キュー内のメッセージが表示されます。COMMIT が送信されるまで、メッセージカウントがそこに留まります。

    sp_ctrl(sysA)> qstatus
     
    sp_ctrl(sysB)> qstatus
  4. 両方のシステムで同時に COMMIT を発行します。
  5. 両方のシステム」で、Post プロセスを起動します。
  6. 両方のテーブルで更新された行を選択して、結果を調べます。

 

Conflict Resolution デモンストレーションの結果の表示

exc_table という名前のテーブルが、インストールスクリプトを実行したときに指定したスキーマ内にインストールされました。このテーブルには次の列があり、競合に関する情報が提供されます。

  • EXC_NO

    この列は、競合の例外数です。

  • EXC_TYPE

    この列は SQL 文のタイプを示し、INSERT、UPDATE または DELETE です。

  • EXC_TARGET_TABLE

    この列は、競合が発生したテーブルです。

  • EXC_FIXED

    この列で、conflict resolution ルーチンの結果が説明されます。YES で、ルーチンが成功したことを示します。NO で、ルーチンは失敗し、該当の行は正しい値に手動で変更する必要があることを示します。

  • EXC_INFO

    この列で、conflict resolution ルーチンで検出されたものを説明します。

  • EXC_TIMESTAMP

    この列で、このマシンで競合が発生した時刻を示します。

 

これで、上級 SharePlex デモンストレーションを終了します。

インストール上の問題の解決

インストール上の問題の解決
コンテンツ

 

この章では、SharePlex のインストール、またはインストール後の SharePlex の最初の実行で発生する可能性がある一般的な問題を検討します。

このバージョンの『リリースノート』を検討しましたか?

このマニュアル内のインストール手順に優先したり補ったりする特殊な手順が示されていることがあります。また、インストール中または後に気になったこのバージョンでの既知の問題がある可能性があります。インストールを開始する前に、SharePlex のインストール予定のバージョンに対応する『リリースノート』をお読みください。

 

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating