SQL anto-pattern for MVP Community Camp 2014 in Japan

1. SQL Server アンチパターン
SQLTO @elanlilac

2. Agenda
 はじめに
 SQL Serverのトラブル
 各種アンチパターン
 失敗から学ぶ
 まとめ

3. はじめに
 このセッションではSQL Serverのことを扱います
 重要なキーワードは緑字にします
 自己紹介
 大人の事情で本名と顔をだしていません
 Microsoft MVP for SQL Server 2011-
 トラブル対応が主食のデータベースエンジニアです
 Twitter: elanlilac
 Blog: http://elan.blog.so-net.ne.jp/
 誰得情報を垂れ流しています

4. はじめに
愚者は経験に学び、賢者は歴史に学ぶ（オットー・フォン・ビスマルク）
Nur ein Idiot glaubt, aus den eigenen Erfahrungen zu lernen.Ich ziehe es vor, aus
den Erfahrungen anderer zu lernen, um von vorneherein eigene Fehler zu
vermeiden
愚者だけが自分の経験から学ぶと信じている。私はむしろ、最初から自分の誤りを避
けるため、他人の経験から学ぶのを好む
他人の踏んだ地雷については知っておいた方がいい

5. SQL Serverのトラブル
SQL Server の主なトラブル
データが
壊れた
パフォー
マンスが
悪い
連携が
止まる
内部
エラー
でも実は「防ぎようもない」トラブルは少ない！

6. ケース1：データベースが壊れる
 データベースは壊れる時は壊れる
 HW不良や突然現れる824/823エラー
 適切なRAID設計で耐障害性を高め、バックアップを取って万が一に備える
 バックアップは重要なデータを保護するための究極の手段

7. 壊れたらDBは
別システムから
作り直す設計
諦めて我慢する
ケース1：データベースが壊れる
システムDBの
バックアップを
取っていない
DBファイルと
バックアップ
ファイルが同じ
RAIDにいる
バックアップを
取っていない
作り直しは時間
がかかる
頑張って再作成 諦める
データ/ディスクが飛んでしまいました
ログインが消え
た
バックアップも
一緒に壊れた
バックアップを
取っていない！
バックアップ運用、物理設計の問題

8. ケース2：パフォーマンスが悪い
 パフォーマンス悪化は運用する人からすると最重要課題の1つ
 オンラインレスポンスの悪化
 バッチウィンドウ超過
 パフォーマンス悪化の原因は様々あり特定が難しいが大きく分けると3つ
 リソース不足
 非効率なクエリプラン
 SQL Server内部の待ち
 などなど

9. ケース2：パフォーマンスが悪い
要件定義での無茶振り
プロジェクト炎上
バッチの目標時
間とデータ量
のバランスが悪
い
受入条件とビジ
ネス要件の乖離
APの設計問題
構造上遅くなる
処理の実装
（カーソルな
ど）
必要以上にロッ
クをかけている
開発は進み、受入テスト時問題発覚

10. ケース2：パフォーマンスが悪い
実は原因を特定するのが大変。パフォーマンス問題は根深い。
運用フェーズでパフォーマンス問題発生
設定は全て規定
の値
本番中にトレー
スを採取
本番運用中に分
析処理を実行
テスト系構築の
ためオンライン
中にフルバック
アップ
テストDBが同じ
インスタンスに
いてリソース消
費
設定の問題 運用の問題

11. ケース2：パフォーマンスが悪い
 なにもしていない人はこれだけはやっておこう
 Tempdbのファイル分割
 コア数または８の小さいほう、の数にする
 同じRAIDの上であっても設定するだけで効果がある（はず）
 Max serer memory と メモリ内のページロック設定
 メモリ上限の設定と仮想メモリをページアウトさせない設定
 パフォーマンスログによるベースライン採取
 何が起きたのかあとからわかるようにする
 異常時と正常時の比較を可能にする

12. ケース2：パフォーマンスが悪い
パフォーマンス問題が潜在化
運用フェーズでパフォーマンス問題発生
CPUコアと物理
メモリのバラン
ス
ディスク容量だ
けではく、I/O
量の考慮
パフォーマンス
問題への備えが
ない
APから見てど
の処理が遅いか
わからない
資料は取ってい
ても足りない
サイジングの問題 パフォーマンス問題の追究不能

13. ケース3：外部連携が止まった
 外部連携の典型的なパターン
 SSISによるデータ取り込み、転送
 リンクサーバによるデータ参照や更新
 レプリケーションによるデータ配信
 外部連携のはまりがちな罠
 データ連係の大元（多くは基幹系）の配信が止まると配信先の業務がすべて止まる
 一般にアーキテクチャが複雑なのでエラーがわかりづらい

14. 現場ではいかんともしがたい
ケース3：外部連携が止まった
Oracleリンク
サーバなど
運用中の外部連携停止、復旧、原因追究へ
サポート対象外
構成になってい
る
連携先のシステ
ムが触れない
連携先の担当が
他社で共同作業
ができない
構成の問題 政治的な問題
連携先が他社DBなどではよくある
SQL Serverでも難しいものは多い
ログ採取、解析
が難しい
連携先のシステ
ムに関するスキ
ルがない
スキルの問題

15. 失敗から学ぶ
 対処できるか考えてみよう
 青い箱をあつめてみる
 分類してみる
 そもそもなんで起きたのか考えてみる
 明日自分が死なないようにする

16. 失敗から学ぶ
バックアップ、物理
設計の問題
要件定義での無茶振
り
APの設計問題
設定の問題
運用の問題
構成の問題
政治的な問題
スキルの問題
サイジングの問題
パフォーマンス問題
の追究不能
要件定義
設計
実装
運用
組織/人
設計や実装の問題が大き
い。
ただし再設計はつらい
適切な設計、実装、テスト
を行うことでトラブルは防
げる
運用や人の問題は今からで
も取り組める問題
要件定義に無理があると後工
程にしわ寄せが来る
これからプロ
ジェクトに取
り組む人は設
計とテストに
力を入れるべ
き
動いているシ
ステムに対し
ては変な運用
を改善する

17. 失敗から学ぶ
 テストに潜むダメパターン
 品質を高めるためには入念なテストが必須
 テストにもダメパターンは潜んでいる

18. 失敗から学ぶ
本番と全く違う
データ量、分布
資料採取がない
ラッシュをかけ
る仕組みがない
テストが本番前
１回だけ
クエリの動作が
テストと本番で
異なるためテス
トにならない
本番で問題が起
きたときにテス
トとの比較がで
きない
ピーク性能の測
定ができないた
め、繁忙期に問
題が起こる
テストで問題が
起きても対処が
できない
余裕を持ったスケジュールで複数回のテストを本番さながらに実施する

19. 失敗から学ぶ
 その他今からでもできる対処策
 問題点の改善する
 すぐできることはすぐやってしまう（まずは3月だし予算取り）
 すぐに対処するのは難しいので次回更改時にそっと差し込む
 過去にやってしまった失敗をまとめてみる
 障害対応履歴などから追ってみるのはとても勉強になる
 設計書を見て怪しい記述を押さえておく
 とにかくテストは念入りに！
大切なのは同じミスを繰り返さないこと

20. まとめ
 世の中には様々なダメパターンが存在する
 重要なことは他人、そして自分の犯した失敗から学ぶこと
 今からでもできる対処はあるのであきらめない
 同じ失敗は2度は繰り返さない

21. 参考資料
 バランスドシステム（メモリの搭載量について言及）
http://www.atmarkit.co.jp/ait/articles/1101/25/news127.html
 SQL Server最低限設定しておくもの
http://www.atmarkit.co.jp/ait/articles/1009/06/news093.html
 パフォーマンスログで何を取るか
http://support.microsoft.com/kb/298475/ja
 パフォーマンス向上
http://msdn.microsoft.com/ja-jp/library/ff647793.aspx