SQLアンチパターンNight でのLT資料です。 13時間程度で終了すると思った3,500万件弱のデータ洗い替え作業が5日以上掛かった話 http://connpass.com/event/12430/ #sql_ap_night

1. SQLアンチパターンNight
ライトニングトーク
株式会社ヴァル研究所
板橋正之
2015/04/10

2. 自己紹介
■名前
板橋 正之
（いたばし まさゆき）
■所属
株式会社ヴァル研究所
JAWS-UG中央線
■仕事
自社広告配信サーバの開発、運用
■好きなRDBMS
Oracle Database
itabashi.masayuki

3. 今日はSQLアンチパターンNightということ
で
失敗談を持ってきました。

4. 今から5年ぐらい前の案件です。

5. 13時間程度で終了すると思った
3,500万件弱のデータ洗い替え作業が
5日以上掛かった
失敗談

6. 某システムの会員情報のID変更
案件

7. テーブルイメージ

8. 単純にUPDATE文の羅列で
古い会員コードを
一旦テンポラリコードに編集して
その後、新しい会員コードに振り直す。
やったこと

9. 会員コードは主キーの一部で
インデックスが設定されているので
更新時にはインデックス書き換えの
オーバーヘッドを減らすため
インデックスを解除した。
検討事項

10. 更新が多くなる分、UNDO表領域、REDOロ
グファイルを作成されることも予想される
ため、ディスクを節約したかった。
検討事項

11. • テスト環境でサンプルのテーブルを使ってインデックスあり、なしの時間を
計測して、処理時間を見積もりました。
•テーブルA：448,251件
•テーブルB：561,018件
• アーカイブREDOログによるディスク使用量もテーブルAが
1,062MB/556MB、テーブルBが1,821MB/607MBと計測しました。
• 上記の結果からインデックスなしの方が明らかに処理時間が短いことから、
インデックスなしで処理を行なう方がよいと判断しました。
処理時間見積り
操作内容 時間 合計
インデックスあり
テンポラリ会員コード更新 0:06:48
0:18:37
新会員コード更新 0:11:49
インデックスなし
インデックス無効&テンポラリ会員コード更新 0:01:09
0:09:23新会員コード更新 0:07:20
インデックス再作成 0:00:54
操作内容 時間 合計
インデックスあり
テンポラリ会員コード更新 0:09:24
0:33:28
新会員コード更新 0:24:04
インデックスなし
インデックス無効&テンポラリ会員コード更新 0:01:15
0:09:05新会員コード更新 0:06:48
インデックス再作成 0:01:02

12. • 更新対象データが34,971,205件
• 検証データが448,251件で10分弱
• 34,971,205÷448,251×10≒780分
＝13時間

13. 大間違い

14. サンプリングが少ない。

15. • 2テーブル程度のデータで信頼性のある
値がだせるのか？
• 見積もりを行なったテーブルは、比較的
データ件数が近い。

16. データ件数と処理時間の相関
関係を見出していない。

17. 本番サーバの方が性能いい？

18. （当時でも）
もう5年前のサーバだよ？

19. 思い込みと楽観視

20. まず、テンポラリ会員コードへの更新
テーブル データ件数 更新(秒) 更新(分) 1万件当たりの秒数
会員マスタ 69,322 3.063 0.1 0.4419
会員所属マスタ 61,543 14.047 0.2 2.2825
受付テーブル 159,330 26.454 0.4 1.6603
予約テーブル 159,330 16.313 0.3 1.0239
ヘッダーテーブル 159,330 13.125 0.2 0.8238
コーステーブル 159,330 73.75 1.2 4.6288
明細テーブルA 8,564,614 609.703 10.2 0.7119
明細テーブルB 454,350 23.204 0.4 0.5107
明細テーブルC 17,845,016 1721.546 28.7 0.9647
明細テーブルD 2,668,722 179.672 3.0 0.6733
明細テーブルE 1,193,156 249.61 4.2 2.0920
明細パラメータテーブル 159,329 46.453 0.8 2.9155
明細付加情報テーブル 360,250 33.515 0.6 0.9303
印刷集計管理テーブル 335,480 68.75 1.1 2.0493
印刷履歴テーブル 1,545,991 599.188 10.0 3.8757
ワークフロー履歴テーブル 910,836 188.672 3.1 2.0714
ワークフロー制御テーブル 1,285,598 826.844 13.8 6.4315
洗い替え開始
SQL> SET TRANSACTION READ WRITE;
SQL> UPDATE 会員マスタ
SQL> SET会員コード = ‘X’ || 会員コード;
SQL> COMMIT;
すでに更新秒数に
バラツキがっ！

21. 続いて新しい会員コードへの更新
洗い替え開始
SQL> SET TRANSACTION READ WRITE;
SQL> UPDATE 会員マスタ
SQL> SET 会員コード = ‘2157’
SQL> WHERE (会員コード = ‘X1356’);
SQL> UPDATE 会員マスタ
SQL> SET 会員コード = ‘3952’
SQL> WHERE (会員コード = ‘X65165’);
SQL> UPDATE 会員マスタ
SQL> SET 会員コード = ‘4510’
SQL> WHERE (会員コード = ‘X2157’);
SQL> ・・・
SQL> COMMIT;

22. 続いて新しい会員コードへの更新
洗い替え開始
SQL> SET TRANSACTION READ WRITE;
SQL> UPDATE 会員マスタ
SQL> SET 会員コード = ‘2157’
SQL> WHERE (会員コード = ‘X1356’);
SQL> UPDATE 会員マスタ
SQL> SET 会員コード = ‘3952’
SQL> WHERE (会員コード = ‘X65165’);
SQL> UPDATE 会員マスタ
SQL> SET 会員コード = ‘4510’
SQL> WHERE (会員コード = ‘X2157’);
SQL> ・・・
SQL> COMMIT;
テーブル データ件数 更新(分) 1万件当たりの秒数
会員マスタ 69,322 約7分 60.5868
会員所属マスタ 61,543 約10分 97.4928
受付テーブル 159,330 約64分 241.0092
予約テーブル 159,330 約140分 527.2077
ヘッダーテーブル 159,330 約60分 225.9461
コーステーブル 159,330 約65分 244.7750
明細テーブルA 8,564,614
明細テーブルB 454,350
明細テーブルC 17,845,016
明細テーブルD 2,668,722
明細テーブルE 1,193,156
明細パラメータテーブル 159,329 約96分 361.5161
明細付加情報テーブル 360,250 約900分 1498.9590
印刷集計管理テーブル 335,480 約70分 125.1938
印刷履歴テーブル 1,545,991
ワークフロー履歴テーブル 910,836
ワークフロー制御テーブル 1,285,598

23. • 金曜の夜にテンポラリ会員コードへの更新を
行って、土日で新会員コードへの洗い替えを
やっていて日曜日の23:00くらいにこんな感じ
でしたね。
• 直後にお詫びのメールを送って翌日朝一でお
詫びの電話しました。
• この時点で更新のオーバーヘッドより、更新
対象検索のオーバーヘッドが大きいと判断し
て、いくつかのサンプリングで確認した結果、
無効にしていたインデックスを有効にして更
新を行なうこととしました。

24. • 土日で終了しなかったので月曜日は当該年
度のデータのみを更新、この時点でインデッ
クスを復活。当然、この日はサービス停止。
テーブル データ件数 更新(分) 1万件当たりの秒数
会員マスタ 69,322 約7分 60.5868
会員所属マスタ 61,543 約10分 97.4928
受付テーブル 159,330 約64分 241.0092
予約テーブル 159,330 約140分 527.2077
ヘッダーテーブル 159,330 約60分 225.9461
コーステーブル 159,330 約65分 244.7750
明細テーブルA 854,569 20分46秒 14.5805
明細テーブルB 44,081 約90分 1225.0176
明細テーブルC 1,770,240 36分6秒 12.2356
明細テーブルD 360,356 約910分 1515.1683
明細テーブルE 162,150 約47分 173.9130
明細パラメータテーブル 159,329 約96分 361.5161
明細付加情報テーブル 360,250 約900分 1498.9590
印刷集計管理テーブル 335,480 約70分 125.1938
印刷履歴テーブル 124,474 約38分 183.1708
ワークフロー履歴テーブル 157,888 約92分 349.6149
ワークフロー制御テーブル 131,976 約48分 218.2215

25. テーブル データ件数 更新(分) 1万件当たりの秒数
会員マスタ 69,322 約7分 60.5868
会員所属マスタ 61,543 約10分 97.4928
受付テーブル 159,330 約64分 241.0092
予約テーブル 159,330 約140分 527.2077
ヘッダーテーブル 159,330 約60分 225.9461
コーステーブル 159,330 約65分 244.7750
明細テーブルA
854,569
7,710,045
20分46秒
3時間28分56秒
14.5805
16.2593
明細テーブルB
44,081
410,269
約90分
1時間39分14秒
1225.0176
145.1242
明細テーブルC
1,770,240
16,074,776
36分6秒
5時間22分29秒
12.2356
12.0368
明細テーブルD
360,356
2,308,366
約910分
1時間20分3秒
1515.1683
20.8069
明細テーブルE
162,150
1,031,006
約47分
1時間27分13秒
173.9130
50.7562
明細パラメータテーブル 159,329 約96分 361.5161
明細付加情報テーブル 360,250 約900分 1498.9590
印刷集計管理テーブル 335,480 約70分 125.1938
印刷履歴テーブル
124,474
1,421,517
約38分
26時間20分5秒
183.1708
666.9283
ワークフロー履歴テーブル
157,888
752,948
約92分
11時間20分43秒
349.6149
542.4412
ワークフロー制御テーブル
131,976
1,153,622
約48分
20時間10分21秒
218.2215
629.5043
残りも更新

26. 原因は？

27. エクステントの分断化？

28. インデックスの更新にはオーバーヘッドが
かかるという思い込み

29. ある件数を超えるとインデックス更新の
オーバーヘッドより全表検索のオーバー
ヘッドが大きくなる
全表検索＋データ更新 ＜ インデックス検索＋データ更新＋インデックス更新
全表検索＋データ更新 ＞ インデックス検索＋データ更新＋インデックス更新

30. インデックスの構造

31. 年次単位での参照が多いため
年月日、会員コードの順番で
複合インデックスが作られていた

32. • 余計なアクセスパスが多い
• 一部のテーブルは年月日と会員IDの順
番が逆でインデックスが生成されていて
おり、実際そちらの方がパフォーマンス
がよかった。
• 正確にいうとマルチテナントのシステム
だったので年月日の上にさらにコードが
あった。

33. UPDATE文1行1行流すんじゃなくて
変換テーブルとのJOINで更新するような
UPDATE文で更新する方法も
あったんじゃないかと。

34. （先にあげた原因を解決するのはもちろんとして）
今後の反省として

35. 自然キーもいいけど疑似キーもね

37. 最近だったらクラウド環境で
停止時間を最小限に

38. • 例えば別のインスタンスをスナップショット等
から作成して、そちらを更新後に差分を適用
するなど。
• 見積もりも本番と同じ環境でできるし。
• 昔と違ってDBのコピーを（お金はかかります
が）ポコポコ立てられる時代になったので。

39. 以上、
ご清聴ありがとうございました。