( ハイブリット型データベース環境 ) プロトタイプ検証結果第二版有限会社ツインズ Twinz Co., Ltd 年 7 月 3 日 /15

Size: px

Start display at page:

Download "( ハイブリット型データベース環境 ) プロトタイプ検証結果第二版有限会社ツインズ Twinz Co., Ltd 年 7 月 3 日 /15"

ひできつくとの
4 years ago
Views:

1 ( ハイブリット型データベース環境 ) プロトタイプ検証結果第二版有限会社ツインズ Twinz Co., Ltd 年 7 月 3 日 /15

1.HDB@ONE( ハイブリット型データベース環境 ) について HDB@ONE は異なるプラットフォーム上の異なるデータベースをレプリケーションをとることにより

2 ハイブリット型データベース環境 ) について HDB@ONE は異なるプラットフォーム上の異なるデータベースをレプリケーションをとることによりあたかも単一のデータベースのように扱うことを可能にした新しいデータベースアーキテクチャーの名称です参考 URL: /15

3 2. プロトタイプテスト環境基幹系 DB z/os (zpdt ) V1.11 DB2 V9.1 情報系 DB OpenSUSE V11.4(64bit) Oracle 11.2 ミドルソフト Oracle GoldenGate V11.1 Oracle Transparent Gateway for DRDA V11.1 又は IBM Q-Replication V9.7(MQ)+Federation server V9.7 Oracle Transparent Gateway for DRDA V プロトタイプテストの目的上記構成のデータベース環境の構築の可否更新処理を行ったときの問題点の有無レプリケーション対象テーブル間でデータ不整合は発生しないか更新アプリケーションは異常終了しないか上記構成を実現する上での最適なミドルソフトの判定日本語対応 (DBCS 半角カタカナ ) についてその他構成の構成の可否 Linux Oracle から z/os DB2 へのレプリケーション等 /15

4 4. テスト構成 z/os z/os Synchronized Replication DB2 SID:DB9G Oracle SID:orcl Oracle SID:orcl2 OpenSUSE OpenSUSE Asynchronized Replication 1 台の OpenSUSE に zpdt を導入して z/os を立ち上げ Linux 上の Oracle と TCP/IP 経由で接続を行う同期レプリケーションには "Oracle Transparent Gateway for DRDA( 略称 :OTG)" を使用する非同期レプリケーションには "Oracle GoldenGate V11.1 ( 略称 :GGS) または "IBM Q-Replication V9.7+Federation server V9.7( 略称 :Q-REP) を使用する文字コードは以下を設定 DB2:EBCDIC(1047 非日本語対応 ) Oracle:UNICODE(AL32UTF8) /15

5 5. レプリケーション構成手順 DB2 から Oracle への非同期レプリケーション構成 GGS での構成 GGS の構成はデータ分散構成を採用 Q-REP での構成 z/os z/os Linux Linux QREP Capture1 QREP Apply1 Oracle DB2 MQ z/os TCP/IP MQ Linux QREP Capture2 QREP Apply2 Oracle /15

6 Oracle から DB2 への同期レプリケーション構成 Oracle テーブルに更新が入った時に同様の更新を DB2 に実施するためのデータベーストリガーをテーブル毎に作成する Local DB Trigger DRDA Remote DB INSERT UPDATE DELETE 上記トリガーがレプリケーションによる更新で起動されてしまうと 2 重更新が行われレプリケーションがエラーになってしまうためこれを抑止する Apply program Local DB Trigger DRDA Remote DB /15

7 6. テスト結果上記構成のデータベース環境の構築の可否非同期レプリケーションについては GGS Q-REP 共に構成可能で問題なく稼働しました同期レプリケーションについてはサンプル ( 付録 1) のようなデータベーストリガーを作成して対応可能でした更新処理を行ったときの問題点の有無レプリケーション対象テーブル間でデータ不整合は発生しないかまた更新アプリケーションは異常終了しないか同一レコードに対する頻繁な更新で問題が発生しましたがパラメータの設定により回避しました ( 付録 2) 同期レプリケーションにおいて同じ主キーを持つレコードを頻繁に削除追加を行うとレコードの不整合が発生してアプリケーションが異常終了しますパラメータの調整により対応を行いましたが解決できませんでした ( 付録 3) 上記構成を実現する上での最適なミドルソフトの判定 GGS Q-REP 共に最終的なテストをまで行い機能的には十分に対応できる製品と判定致しました同期レプリケーションについては OTG のみのテストでしたが機能的には問題と考えます但し日本語対応での問題が判明しています ( 後述 ) 日本語対応 (DBCS 半角カタカナ ) について Oracle GoldenGate について /15

8 DBCS 文字のコード変換は行わない仕様になっているため異なる CCSID データのレプリケーションでは問題が発生します但し NCHAR GRAPHIC 等の属性は認識しているのでレプリケーション自体は実施できます DB2 の CCSID が EBCDIC( カタカナ系 ) の場合 GGS プログラムから英小文字を含む SQL が発行されるとエラーになります英大文字を使用するなどの対応が必要です Q-Replication について DBCS 文字の変換をサポートしています DB2 の CCSID が EBCDIC( カタカナ系 ) の場合でも問題なく稼働します Oracle Transparent Gateway についてトリガー内で Oracle NVARCHAR 属性と DB2 GRAPHIC 比較するとメッセージ ORA-02070: データベース xxxxxx はこのコンテキストでは SYS_OP_C2C をサポートしませんが表示されエラーになります因みにトリガー外 (sqlplus) から実効してもエラーにはなりませんでしたその他構成の構成の可否 Linux Oracle から z/os DB2 へのレプリケーション等 GGS では Oracle から DB2 のレプリケーションが可能ということなので検証しましたが DB2 へのデータアプライでエラーになってしまいました /15

9 7. 結論基本的な機能については検証した範囲で問題はありませんでした日本語対応の部分で既存製品は未対応の部分が多く開発元に対応の予定や情報提供等を確認する必要があると思われます現在は DB2 にしても Oracle にてもデータ共有が全盛ですが顧客側から見た場合複数のデータベースを保持することによる運用等の煩雑性から考えても今後のテーマになってくる技術と考えますまたクラウドコンピューティングという観点からもこの様な技術は大きな要素となると思われます体系づけた製品 ( 技術コンサルティング ) として確立する価値は大きいと考えます今後は実際のアプリケーションでの機能テスト負荷テストを行いたいと考えておりますのでご協力頂けるお客様をご紹介頂ければと考えております /15

10 ( 付録 1) 同期レプリケーショントリガーサンプル CREATE OR REPLACE TRIGGER DSN8910.REPLICATE_DEPT AFTER INSERT OR UPDATE OR DELETE ON DSN8910. DEPT REFERENCING OLD AS OLD_DEPT NEW AS NEW_DEPT FOR EACH ROW BEGIN IF SYS_CONTEXT('USERENV', 'SESSION_USER') = 'GGSUSER' THEN return; END IF; IF (UPDATING) THEN UPDATE DSN8910.DEPT@DALLAS9 SET DEPTNO = :NEW_DEPT.DEPTNO, レプリケーションユーザーを 'GGUSER' としてアプライでの更新についてはリモート DB の更新は実施しない DEPTNAME = :NEW_DEPT.DEPTNAME, MGRNO = :NEW_DEPT.MGRNO, ADMRDEPT = :NEW_DEPT.ADMRDEPT, LOCATION = :NEW_DEPT.LOCATION WHERE DEPTNO = :OLD_DEPT.DEPTNO AND DEPTNAME = :OLD_DEPT.DEPTNAME AND MGRNO = :OLD_DEPT.MGRNO AND ADMRDEPT = :OLD_DEPT.ADMRDEPT AND LOCATION = :OLD_DEPT.LOCATION; END IF; IF (DELETING) THEN DELETE FROM DSN8910.DEPT@DALLAS9 WHERE DEPTNO = :OLD_DEPT.DEPTNO AND DEPTNAME = :OLD_DEPT.DEPTNAME AND MGRNO = :OLD_DEPT.MGRNO AND ADMRDEPT = :OLD_DEPT.ADMRDEPT AND LOCATION = :OLD_DEPT.LOCATION; END IF; /15

11 IF( SQL%ROWCOUNT = 0 ) THEN RAISE no_data_found; 更新削除でデータの不整合がある場合にはエラーを返します END IF; IF (INSERTING) THEN INSERT INTO DSN8910.DEPT@DALLAS9 VALUES(:NEW_DEPT.DEPTNO,:NEW_DEPT.DEPTNAME,:NEW_DEPT.MGRNO,:NEW_DEPT.ADMRDEPT,:NEW_ DEPT.LOCATION); END IF; exception WHEN NO_DATA_FOUND THEN RAISE_APPLICATION_ERROR(num=> , msg=>'data SYNC ERROR OCCURED AT DELETING OR UPDATING'); when DUP_VAL_ON_INDEX then RAISE_APPLICATION_ERROR(num=> , msg=>'data SYNC ERROR OCCURED AT INSERTING'); END; /15

12 ( 付録 2) 更新アプリケーションでの問題点ローカル側のレコードを更新した場合リモート側に同期レプリケーションされ非同期レプリケーションによりローカル側に同じ更新が戻ってきます非同期レプリケーション製品は主キー ( ユニークキー ) によって更新を反映させるので既にローカル側がレプリケーション時とは異なる値に更新されていても無条件にレプリケーションを行ってしまいます Q-REP GGS ともに基本的に同様の動きとなりますレプリケーションされた後は一時的にローカル DB とリモート DB のレコードの内容が不一致が発生するのでそのタイミングで更新を行うとレコードの不整合でアプリケーションでエラーが発生します但しエラーになった後にローカル DB とリモート DB 間でのデータの不整合は発生しませんでした非同期レプリケーション主キー :111 更新フィールド : 003 主キー :111 更新フィールド : 001 主キー :111 更新フィールド : 002 REDO 主キー :111 更新フィールド : 002 主キー :111 更新フィールド : 主キー :111 更新フィールド : 003 Local DB Trigger Remote DB 1 主キー :111 更新フィールド : 001 Application Update 主キー :111 更新フィールド : 002 主キー :111 更新フィールド : /15

13 ( 回避策 ) GGS ではアプライを行う前に BEFORE ログと現状のレコードの内容が一致しているかを検証するパラメータがあり不一致の場合はアプライを行わないと設定ができますこの設定によりアプリケーションのエラーを回避することができました * 参考 MAP DSN8910.DEPT, TARGET dsn8910.dept & REPERROR (21000, IGNORE), & SQLEXEC ( ID lookup, ON UPDATE, & QUERY " select count(*) conflict from dsn8910.dept & where DEPTNO = :ODEPTNO & AND DEPTNAME = :ODEPTNAME & AND MGRNO = :OMGRNO & AND ADMRDEPT = :OADMRDEPT & AND LOCATION = :OLOCATION ", & PARAMS ( ODEPTNO = BEFORE.DEPTNO, ODEPTNAME = BEFORE.DEPTNAME, & OMGRNO = BEFORE.MGRNO, OMGRNO = BEFORE.MGRNO, & OADMRDEPT = BEFORE.ADMRDEPT, OLOCATION = BEFORE.LOCATION), & BEFOREFILTER ), & FILTER (lookup.conflict = 1, ON UPDATE, RAISEERROR 21000); Q-REP ではサブスケリプションのパラメータの設定をを BEFORE_VALUES=Y および CONFLICT_RULE=A に設定することによりアプリケーションのエラーを回避できました /15

14 ( 付録 3) 更新処理 ( 同一レコードの削除追加 ) での問題点付録 2 と同様に同一主キーを持つレコードの削除と追加を繰り返すとアプリケーションの追加処理で既にレコードが存在するため ( 主キーの重複 ) に異常終了しました非同期レプリケーション主キー :111 の削除主キー :111 の追加 REDO 主キー :111 の追加主キー :111 の削除 3 2 主キー :111 の削除 Local DB Trigger Remote DB 1 主キー :111 の削除 Application 主キー :111 の追加主キー :111 の削除主キー :111 の追加これはアプリケーションの削除と追加の間に非同期レプリケーションからの追加が反映されてしまいアプリケーションからの追加が既に同一主キーのレコードが存在するためにエラーになりましたこのエラーは現状では回避不可能と考えます但しエラーになった後にローカル DB とリモート DB 間でのデータの不整合は発生しませんでした /15

15 * z/os zpdt DB2 IBM は International Business Machines Corporation の商標です *OpenSUSE は Novell, Inc. の商標です *Oracle は Oracle Corporation の商標です本テスト結果については製造元の確認を得ていません自社環境に適用を検討する場合は各製品の製造元にご確認下さい弊社にご相談頂ければ対応させて頂きます弊社連絡先 : info@twinz.co.jp Tel: 有限会社ツインズ担当 : 斎藤 /15

日本オラクル株式会社

日本オラクル株式会社 FISC 6 Oracle Database 10g ~ ~ : 2005 7 26 : 2005 7 31 : 1.0 2004 4 (* ) FISC ) (* ) FISC 6 (* FISC 6 ) FISC 6 Oracle g Database 10 (FISC) http://www.fisc.or.jp FISC http://www.fisc.or.jp/info/info/050307-1.htm

( ハイブリット型データベース環境 ) プロトタイプ検証結果 第二版 有限会社ツインズ Twinz Co., Ltd 年 7 月 3 日 /15

( ハイブリット型データベース環境 ) プロトタイプ検証結果第二版有限会社ツインズ Twinz Co., Ltd 年 7 月 3 日 /15