[db tech showcase Tokyo 2018]　#dbts2018 #D24 『異種データベース間データ連携ウラ話～新しいデータベースを試すときに考えること。失敗事例やテストの重要性など～』

株式会社インサイトテクノロジー
宮地敬史 /吉野和樹
異種データベース間データ連携ウラ話
～新しいデータベースを試すときに考えること。
失敗事例やテストの重要性など～

自己紹介
 データベースエンジニア（一応、マルチDB）
 最近は、データベース間のデータ連携についての
案件に従事することが多くなっています
プライベートなことですが・・・
 犬ｘ２、猫ｘ４とにぎやかに過ごしています！

Agenda
1. データベース間データ連携の課題
2. 実際のところどうなの？
3. アプリケーションテストの効率化

1.データベース間データ連携の課題

用途
開発期間
運用

用途
 データベース移行
 常時レプリケーション
 同一DBのバージョンアップ
 異種DBへの鞍替え（使い勝手、保守費用、etc）
 分析用DBへのデータの集約
 参照系処理のオフロード
用途に応じて使用するデータベースを使い分けるケースが増えてきている

開発期間
短縮できるなら、短縮したい！
• 費用削減
• 新サービスの迅速な提供
 短縮可能なタスクは？
 データ連携/データ移行の仕組みづくり
 新環境でのアプリケーション（クエリ）の作成と
テスト
レプリケーションソフトを使えば短縮可能

 レプリケーションソフトを使ったデータ連携
 エージェントレス (LUW)
 ブラウザベースのGUIによる簡易設定・監視
 異種データベース間の高速データ転送・同期(マルチDB対応)
特徴
【Target】【Source】
SQL Server 2005/2008/2012/2014
MySQL 5.5/5.6
Sybase ASE 12.5/15/15.5/16
IMSIMS
PostgresSQL 9.4.2↑(Win) 9.4(Linux)
 主要対応環境
Oracle10g/11g/12c

 エージェントレス (LUW)
 ブラウザベースのGUIによる簡易設定・監視
 異種データベース間の高速データ転送・同期(マルチDB対応)
特徴
【Target】【Source】
SQL Server 2005/2008/2012/2014
MySQL 5.5/5.6
Sybase ASE 12.5/15/15.5/16
IMSIMS
PostgresSQL 9.4.2↑(Win) 9.4(Linux)
 主要対応環境
Oracle10g/11g/12c
ソースDBに（比較的）負荷をかけずに、
ニアリアルタイムでデータ連携が可能！

【デモ】
Amazon EC2Oracle Database
12c

 新環境でのアプリケーション（クエリ）の作成とテスト
 同一DB間の移行
 異種DBへの移行
 分析用データベースへのデータ集約
 参照系処理のオフロード
必要最低限なもののみ修正したい
作るしかない・・・
後程、詳しく説明します！

運用
 データベース移行
 常時レプリケーション
ワンタイムなので、あまり深く考慮しなくても問題ない
 連携対象テーブルのDROP
 連携対象テーブルの構成変更（カラム追加、削除等）
 データの洗い替え
 監視（正常に動作しているか/遅延が発生していないか）
 冗長構成（H/A、DR）
常時レプリケーションの場合、連携元で行われている処理を考慮しないと
うまくいかない

2.実際のところどうなの？

【ケース１】
データの連携でエラー発生①
キー値
I000001
キー値
I000001
i000001
Oracle Database MySQL
INSERT i000001 一意制約エラー
【原因】
MySQLのcollationが、utf8_general_ci
（文字評価時、大文字小文字の区別をしない）
の為、既存のI000001と同一キーと見なされた・・・
【対応】
・Collationをutf8_binに変更
・エラーとなったデータを手動で登録

【ケース１】
データの連携でエラー発生①
キー値
I000001
キー値
I000001
i000001
Oracle Database MySQL
INSERT i000001 一意制約エラー
【原因】
MySQLのcollationが、utf8_general_ci
（文字評価時、大文字小文字の区別をしない）
の為、既存のI000001と同一キーと見なされた・・・
【対応】
・Collationをutf8_binに変更
データベースの照合順序は、大文字小文字を区別
できるものを選択しましょう。

【ケース２】
データの連携でエラー発生②
キー値
I000001
キー値
I000001
I000001△△
Oracle Database SQLServer
INSERT I000001△△ 一意制約エラー
【原因】
ANSI/ISO SQL-92 specification準拠による仕様。
※末尾の半角スペースがある文字列と無い文字列は同一
の文字列として扱われる
※SQLServerだけでなく、MySQLも同様の動作
【対応】
・キー値を変換するように同期設定変更
※△は半角スペース

【ケース２】
データの連携でエラー発生②
キー値
I000001
キー値
I000001
I000001△△
INSERT I000001△△ 一意制約エラー
【原因】
ANSI/ISO SQL-92 specification準拠による仕様。
※末尾の半角スペースがある文字列と無い文字列は同一
の文字列として扱われる
※SQLServerだけでなく、MySQLも同様の動作
【対応】
・キー値を変換するように同期設定変更
※△は半角スペース
事前にどのようなキー値が入力されうるか、要確認
必要に応じて、キー値の変換を入れる
または
Oracle,PostgreSQL等、末尾半角スペースの有無を
評価可能なデータベースを選択する

【ケース３】
ターゲット側のリソース不足により、遅延発生
INSERT
UPDATE
DELETE
※数万件の更新データ更新の反映に通常時の
5倍かかった

【ケース３】
ターゲット側のリソース不足により、遅延発生
【対応】
・データベースサーバのCPU増強
INSERT
UPDATE
DELETE
※数万件の更新データ更新の反映に通常時の
5倍かかった【原因】
データベースサーバのCPU使用率が100%となっていた

【ケース４】
同期先で発行したクエリが終わらない・・・
【対応】
・SQLServerの設定変更
（READ_COMMITTED_SNAPSHOT=ON）
※数十万件の更新データ
(PKのないテーブル）
【原因】
ロックエスカレーションにより、テーブル全体がロック
されてしまった為
UPDATE
DELETE
テーブルA テーブルA
テーブルAへの参照クエリが
いつまでたっても返ってこない
更新中・・・

【ケース５】
データ洗い替え処理でエラー発生
Oracle Database Oracle Database 【対応】
・連携対象から該当テーブルを外した
【原因】
DROPは連携させない設定にしていた為、INSERTのみ
が連携され、ターゲット側に残っていた以前のデータと
バッティング
DROP
CREATE
INSERT
一意制約エラー※DROP→CREATE後、
数十万件インサート

【ケース５】
データ洗い替え処理でエラー発生
Oracle Database Oracle Database 【対応】
・連携対象から該当テーブルを外した
【原因】
DROPは連携させない設定にしていた為、INSERTのみ
が連携され、ターゲット側に残っていた以前のデータと
バッティング
DROP
CREATE
INSERT
一意制約エラー※DROP→CREATE後、
数十万件インサート
TRUNCATEやDROPについて、どのように連携させるのか、
事前に決めておく必要がある。
※DROPやTRUNCATE処理の有無も要確認

拠点C
拠点B
拠点A
AAA
BBB
CCC
AAA
BBB
CCC
TRUNCATE
AAA
BBB
CCC
テーブルA
テーブルA
テーブルA
AAA A
BBB A
CCC A
AAA B
BBB B
CCC B
AAA C
BBB C
CCC C
テーブルA
拠点Bのデータだけ削除したいが、
テーブル全体がTruncateされてしまう
例えば・・・

拠点C
拠点B
拠点A
AAA
BBB
CCC
AAA
BBB
CCC
TRUNCATE
AAA
BBB
CCC
テーブルA
テーブルA
テーブルA
拠点Bのデータだけ削除可能
対応策
AAA
BBB
CCC
テーブルA_A
AAA
BBB
CCC
テーブルA_B
AAA
BBB
CCC
テーブルA_C
テーブルA ※VIEW
AAA A
BBB A
CCC A
AAA B
BBB B
CCC B
AAA C
BBB C
CCC C

【ケース６】
リリース後、クエリエラー/処理性能の劣化
Oracle Database
10g
Oracle Database
11g
ログイン画面からログインしようとして、
タイムアウトエラーでログインできない
【対応】
・（Oracleのバグだったので）隠しパラメータを設定
【原因】
バージョンアップにより、実行計画が変わった結果、
タイムアウト時間内にクエリが終了しなかった
【根本原因】
時間がなかったため、テストしていない処理が沢山あった

【ケース６】
リリース後、クエリエラー/処理性能の劣化
Oracle Database
10g
Oracle Database
11g
ログイン画面からログインしようとして、
タイムアウトエラーでログインできない
【対応】
・（Oracleのバグだったので）隠しパラメータを設定
【原因】
バージョンアップにより、実行計画が変わった結果、
タイムアウト時間内にクエリが終了しなかった
【根本原因】
時間がなかったため、テストしていない処理が沢山あった
リリース日に焦るより、事前にしっかりとテストをしましょう！
※できれば、現行システムで発行しているSQL全部※

3.アプリケーションテストの効率化

アプリケーションのSQLの
移行について

DB移行
● テーブルやスキーマの移行
● データ移行

アプリケーションで使用している
DBを移行するとなったら...
NEW
OLD

アプリケーションサーバーの
ＳＱＬの移行の課題
● どんなSQLが実行できないか
● どんなSQLの性能が劣化するのか

そこでたまに挙がるのが
Oracle
Real Application Testing
(RAT)

RATとは
OracleからOracleへ移行する際に使用する
Oracleのオプション

RATだと
● 移行元環境で普段使用しているSQLを取得
● 移行先環境で実行
● 実行できないSQL、
性能が劣化したSQL がわかる

RATだと
● 移行元DBのSQL取得に負荷がかかる
● Oracle to Oracle のみ
● 導入が簡単ではない
● GUI連携が弱い

RATだと
● 全てのSQLをテストユーザーで実施
● SQLの処理順序を考慮していない

Insight Technology的に何かできないか

情報漏洩を防ぐための
リアルタイムデータアクセスモニタリングツール

PISO の特徴
● DBへのアクセスログをリアルタイム取得
● DBパフォーマンスの負荷なし
● マルチDB対応

RATの気になるところ
● 移行元DBのSQL取得に負荷がかかる
● Oracle to Oracleのみ

Database Testing Option
（DTO）

DTOが目指すところ
● 本番環境のSQLを網羅的に取得
● 異種DBでもSQLを実行
● 実行できないSQLはどれか
● 遅くなったSQLはどれか
● SQLを書き換えて移行先環境で即実行

メリット
● 低負荷で本番環境のSQLを網羅的に取得
● マルチDBで使用可能
● 簡単GUI操作
● 本番環境と同名ユーザーでSQL実行

移行元環境
Oracle 9i
移行先環境
PostgreSQL 10
SQLの数
24,689

DTO画面サンプル①
実行できなかったSQL一覧

DTO画面サンプル②
SQL修正、テスト画面

留意点
● 実行計画は取得していない
● 一部バインド変数が取得できない

今後の展望
● まずはOracle to PostgreSQL対応

ちょっと使ってみたい
っていう人を探しています

[db tech showcase Tokyo 2018] #dbts2018 #D24 『異種データベース間データ連携ウラ話 ～ 新しいデータベースを試すときに考えること。失敗事例やテストの重要性など ～』

More Related Content

What's hot

Similar to [db tech showcase Tokyo 2018] #dbts2018 #D24 『異種データベース間データ連携ウラ話 ～ 新しいデータベースを試すときに考えること。失敗事例やテストの重要性など ～』

More from Insight Technology, Inc.