[db tech showcase Tokyo 2018]　#dbts2018 #E37 『Attunity Replicateが変えた Oracle Database移行、常時Multi Databaseレプリケーションソリューション』

Copyright © 2018 ITOCHU Techno-Solutions Corporation
Attunity Replicateが変えた
Oracle Database移行、
常時Multi Databaseレプリケーションソリューション
2018年09月21日
伊藤忠テクノソリューションズ株式会社
西日本統括本部
西日本開発部
山田秀秋

アジェンダ
1. 自己紹介
2. CTCのAttunity Replicate案件事例（西日本）
3. Attunity Replicateとの比較
4. Attunity Replicateを使う上での注意点
5. システム移行の注意点
6. CTCの会社説明
7. CTCの直近の取り組みについて
Page 2

1. 自己紹介（山田秀秋）
• 関西でインフラ構築から開発技術者を経て、大規模SI案件のアーキテクトとし
て従事
• 開発案件、インフラ案件、監視運用案件などに従事
• プライベートクラウド基盤の更改やミッションクリティカルDatabaseの移行
プロジェクトに携わる
• パフォーマンス・チューニングを得意とする
• Oracle Exadataの立ち上げ・移行を含め５件実施
• 今年4月より、東京で単身赴任
Page 3

2. CTCのAttunity Replicate案件事例
Page 4

2.1 Attunity Replicate 事例[流通業]
Page 5
• 対象システム：基幹システム
– システム停止時間を最大８時間以上とれない
– DB容量 210GB 570テーブル
• 課題
– サービス停止を伴うデータ移行が３時間以内であること
（データ移行後のデータ検証、アプリ検証は除く）
– 移行元システムに変更をできるだけかけないこと
– 移行元システムにあまり負荷をかけないこと
– 旧システムと新システムの間のネットワーク回線が100Mbps
– 比較的安価であること
– Oracle Database Standard Editionどうしの連携が可能なこと
– 移行元DBと移行先DBのバージョンが異なる
IncrementalCDC
Oracle 10g R2 Std. Oracle 11g Std.

項番課題対策
1 サービス停止を伴うデータ移行が３時間以内
であること
（データ移行後のデータ検証、アプリ検証は
除く）
Attunity Replicateが一旦同期すると、最終差分更新分のみ
止めれば移行可能
最終差分更新は数分で完了し、データ移行以外の作業を含め
てPM10:00-AM5:00のサービス停止で移行完了
2 移行元システムに変更をできるだけかけない
こと
Attunity Replicateはエージェントレス
3 移行元システムにあまり負荷をかけないこと Attunity Replicateは連携元への負荷が比較的少ない
4 旧システムと新システムの間のネットワーク
回線が100Mbps
初期転送は、Export/Importを使用
5 比較的安価であること 6ヶ月のタームライセンスを使用
6 Oracle Database Standard Editionどうしの
連携が可能なこと
Attunity ReplicateはOracle Standard Editionに対応
7 移行元DBと移行先DBのバージョンが異なって
も可能な事
Attunity ReplicateはDBのバージョンが異なっても連携可能
(移行元DBのバージョンが古く、マイナーバージョンアップ
は必要でした)
2.1 Attunity Replicate 事例[流通業]
Page 6

2.2 移行本番のスケジュール
事前データ移行
で4時間
日中更新データの大半は
常時連携
データ検証に30分
当日データ移行で
40分
事後データ移行で
5時間
Page 7

2.3 Attunity Replicate データ移行事例[賃貸業]
Page 8
• 対象システム：基幹システムのExadata X2からExadata X7へのリプレース
– システム停止時間を最大12時間以上とれない。
– DB容量 7.7TB 3620テーブル
• 課題
– サービス停止を伴うデータ移行が5時間以内であること
（データ移行後のデータ検証、アプリ検証は除く）
– 移行元システムに変更をできるだけかけないこと
– 初期転送のサービス停止が不可能
– DBのマイナーバージョンアップを伴う(11.2.0.3から11.2.0.4)
IncrementalCDC
Oracle Exadata X2
Oracle 11g Ent. 11.2.0.3
Oracle Exadata X7 EF

項番課題対策
1 サービス停止を伴うデータ移行が５時間以内
であること
（データ移行後のデータ検証、アプリ検証は
除く）
Attunity Replicateが一旦同期すると、最終差分更新分のみ
止めれば移行可能
最終差分更新は数分で最終差分更新は数分で完了し、データ
移行以外の作業を含めて10:00-19:00のサービス停止で移
行完了
2 移行元システムに変更をできるだけかけない
こと
Attunity Replicateはエージェントレス
3 移行元システムにあまり負荷をかけないこと Attunity Replicateは連携元への負荷が比較的少ない
4 初期転送のサービス停止が不可能 Attunity Replicateで移行したテーブルは全テーブルHash値
チェックし、値が異なったテーブルは、当日Export/Import
で移行
夜間更新が無いテーブル、昼間更新が無いテーブル、履歴系
の更新が無いテーブル、当日移行のテーブルにタスクを分割
し、FullLoadを実施
5 DBのマイナーバージョンアップを伴う
(11.2.0.3から11.2.0.4)
Attunity ReplicateはDBのバージョンが異なっても連携可能
2.4 Attunity Replicate 事例[賃貸業]
Page 9

2.6 ORA_HASH関数を用いたデータ検証
商品CD 商品名売価作成日数量
AAA リンゴ 100 2015/6/10 12:30:00 132
BBB バナナ 200 2015/6/9 10:00:00 240
CCC ブドウ 300 2014/10/9 13:00:00 100
商品CD 商品名売価作成日数量
AAA リンゴ 100 2015/6/10 12:30:00 132
BBB バナナ 200 2015/6/9 10:00:00 239
CCC ブドウ 300 2014/10/9 13:00:00 100
列ごとに全行に対するHASH値の合計値を取得し、新旧で比較する
141946349736979312
141946349736979312
25249150827144
24289785377762
OK！ NG!
旧DB環境
新DB環境
Page 10
Export/Importに移
行手段を切り替え

2.7 Attunity Replicate データ連携事例 [賃貸業]
Page 11
• 対象システム：基幹システムーCRMシステム連携
– マルチデータベース連携
– 数千万レコード／テーブルの連携
– 対象テーブル 50
• 課題
– テーブルの物理レコード削除あり
– 短納期
– マルチデータベース連携
– 連携元DBへの影響を最小限に
– 対象システム間のNWが200Mbpsしかない
– 個人情報などの機密情報を含むカラムは、連携せず、暗号化カラムのみを連携
• 対策案：Attunityのでリアルタイム同期
IncrementalCDC
Oracle Exadata X7 EF
Oracle 12c Std. 12.1.0.1
MySQL 5.7
Private Cloud A
Private Cloud B

項番課題対策
1 テーブルの物理レコード削除あり Attunity Replicateでは物理削除に対応
2 短納期 Attunity ReplicateはエージェントレスでAttunity
Replicateはインストール、設定が簡単
3 マルチデータベース連携 Attunity ReplicateでOracle DatabaseおよびMySQL
Databaseへ連携可能
4 連携元DBへの影響を最小限 Attunity Replicateは連携元への負荷が比較的少ない
5 対象システム間のNWが200Mbpsしかない OSで帯域を絞った
6 個人情報などの機密情報を含むカラムは、連
携せず、暗号化カラムのみを連携
Attunity Replicateは連携対象カラムを取捨選択可能
2.8 Attunity Replicate データ連携事例 [賃貸業]
Page 12

3. Attunity Replicateと他の方式との比較
Page 13

3.1 Attunity Replicate有効ケース ETLツールとの比較
Page 14
ETL・EAIツール自作ツール Attunity Replicate
連携スピード △ △ ○
連携元への負荷 △ △ ○
レコード物理削除への対応 ✕ ✕ ○
送信元データのJOINや
テーブルをまたがる絞込 ○ ○ ✕
導入スピード △ ✕ ○
マルチデータベース ○ △ ○

3.2 Attunity Replicate有効ケース移行ツールとの比較
Page 15
Exp/Imp
ツール
自作
ツール
DataGuard
GoldenGate
B社レプリケー
ションツール
Attunity
Replicate
連携スピード △ △ ○ ○ ○
連携元へのモ
ジュール要否 ○ △ △ ✕ ○
連携元への負荷 △ △ ○ △ ○
導入スピード △ ✕ ✕ △ ○
マルチDB対応 ✕ △ ✕ ✕ ○
サービス停止時間 ✕ ✕ ○ ○ ○
製品価格 ○ △ ✕ △ ✕⇒▲

4. Attunity Replicate を使う上での注意点
• FullLoadは、トランザクションの無い静止点が必要
• ロジカルレプリケーションなので、連携元、連携先のDBの仕様に準ずる
– MySQLのページサイズ
– 文字コードは一旦Unicodeに内部変換される
– 各連携モジュールは、別の実装となっている
• 文字化けは起こるものと思え
• Export/Importは敵ではなくお友達
• 主キーが無いテーブルは差分同期が苦手
• LOBデータは苦手
• 圧縮テーブルはテクニックが必要
• バージョンは最新を使え
• アナライズはタイミングが難しい
• 実行計画は変わるものと思え
– SPMやチューニングアドバイザで対処
• ログマイナーを使う場合は要注意
– 連携元のリソースは重要
• Insight Technologyの協力は重要
Page 16

4.1 SPMとは
• SPMとは、SQL Plan Managementの略で、SQLの実行計画を記録してそれを
評価
した後に本番環境に適用することができる機能のことです。
• 簡単に言うと、実行計画がかわった時に、パフォーマンスがよくなるかを確
認して、よくなるものだけを適用することができるという機能です。
• 統計情報取得後、突然パフォーマンスが劣化した、などという話はよく聞きま
す。
• これは、統計情報の取得により、実行計画が改悪されてしまったことに
起因しています。１度でもこのような経験をしてしまうと、次に統計情報を取
得することを敬遠したり、取得自体をやめたりしてしまいます。
つまり、統計情報を取得する作業は、環境によっては非常にリスクの高い作業
といえます。

4.2 チューニングアドバイザによるプロファイルの適用とSPMによるチュー
ニングの違い
操作による成果物
• チューニングアドバイザによるプロファイル
– SQL Profile
• SPMによるチューニング
– SQL Plan Baseline
他環境へのProfile移植
• チューニングアドバイザによるプロファイル
– 可能
• SPMによるSQL Plan Baseline
– 可能

SPMが有効なパターン
• バインド変数が使われており、SQLIDが変わらない
• 統計情報が取得されている
• 直接アプリケーションを修正することが難しい
• より良い実行計画のパターンを他の環境や以前取得した実行計画が存在する。
SPMが無効なパターン
• リテラル変数が使われており、SQLIDが変わる（Cursor Sharingである程度自動補完できる）
• アプリケーションが頻繁に更新、あるいは動的に作られておりSQLそのものがよく変わる。
• より良い実行計画がどうすればよいかわからない。
4.3 SPMが有効なパターンと無効なパターン

4.4 SPMによるチューニングパターン
1. 過去に同じマシン、別の時間により良い実行計画で動いた実績があり、その際
のSQLID,SQL_PlanHash値、現在のPlanHash値がEnterpriseManager上で
確認可能（カーソル上に残っている）。単純には、実行計画がころころ変わっ
てしまい、よい実行計画で固定したい。
2. 別環境でより早く動く環境があり、実行計画が確認でき、本番環境で、ヒント
文をつけて実行計画を似せて実行可能（SQL自体を書き換えては駄目）

5. システム移行の注意点
• アプリケーション検証には時間、環境が必要
– データセットアップはお客様？
– アプリの検証は、検証して終わりではない
• データ移行≠システム移行
– データに差異がないから移行完了ではない
– 移行システムの先のシステムに影響あり
• 移行リハーサル／移行本番では、お客様とのコミュニケーションが重要
– お客様もシステムのすべてを理解しているわけではない
• このデータは昼間／夜間更新はないから・・・
• アプリは変更してないから・・・
• 文字化けするような変なデータは無いから・・・
– コミュニケーションツールは重要
• Box
– Boxnoteでリアルタイムに障害対応状況を相互更新
– リアルタイムに進捗共有
• Zoom
– リアルタイムに顔を見ながら相互確認
– 東京CTC、大阪CTC、東京インサイトでリアルタイム中継しながら移行を実施
Page 21

6. CTCの会社紹介
Page 22

6.1 会社概要
Page 23
2018年4月1日現在
ITOCHU Techno-Solutions Corporation
〒100-6080 東京都千代田区霞が関3-2-5 霞が関ビル
TEL：03-6203-5000（代）
URL：http://www.ctc-g.co.jp/
代表取締役社長菊地哲
1972年（昭和47年）4月1日
1979年（昭和54年）7月11日
21,763百万円
単体：4,309名
CTCグループ： 8,546名
コンピュータ・ネットワークシステムの販売・保守、ソフトウェア受託開発、情報処理サービス、
科学・工学系情報サービス、サポート、その他
会社名
英文社名
本社所在地
代表者
創立
設立
資本金
社員数
事業内容
（略称 CTC）

7 CTCの直近の取り組みについて
Page 24

7.1 CTCが考えるあるべきITの姿
Page 25

7.2 CTCの得意なSI
Page 26
• システム移行
– 豊富な実績
– フレームワーク化した移行メソッド
– 定型化したテンプレート・ルールブック
• DBチューニング
– Exadataのチューニングもバッチリ
– Exadata X7 EFは爆速ですが、実行計画が変わると全く返ってこない
– パラレルクエリーは諸刃の剣
– I/Oキャリブレーションは必須
– SPMやチューニングアドバイザ、統計情報の移行は使い倒し
– MySQLもチューニングできます
• 開発
– 普通の開発もできます（私は開発部）
– アプリのスペシャリストもいます
– OO、アジャイルもできます
– 超高速開発OutsystemsもSIできます

[db tech showcase Tokyo 2018] #dbts2018 #E37 『Attunity Replicateが変えた Oracle Database移行、常時Multi Databaseレプリケーションソリューション』

More Related Content

What's hot

Similar to [db tech showcase Tokyo 2018] #dbts2018 #E37 『Attunity Replicateが変えた Oracle Database移行、常時Multi Databaseレプリケーションソリューション』

More from Insight Technology, Inc.