Download - SQL Server アンチパターン MVPComCamp
SQL Server アンチパターン
SQLTO @elanlilac
Agenda
はじめに SQL Serverのトラブル 各種アンチパターン 失敗から学ぶ まとめ
はじめに
このセッションでは SQL Serverのことを扱います 重要なキーワードは緑字にします
自己紹介 大人の事情で本名と顔をだしていません Microsoft MVP for SQL Server 2011-
トラブル対応が主食のデータベースエンジニアです Twitter: elanlilac
Blog: http://elan.blog.so-net.ne.jp/
誰得情報を垂れ流しています
はじめに愚者は経験に学び、賢者は歴史に学ぶ(オットー・フォン・ビスマルク)
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
愚者だけが自分の経験から学ぶと信じている。私はむしろ、最初から自分の誤りを避けるため、他人の経験から学ぶのを好む
他人の踏んだ地雷については知っておいた方がいい
SQL Serverのトラブル
SQL Server の主なトラブル
データが壊れた
パフォーマンスが悪い
連携が止まる
内部エラー
でも実は「防ぎようもない」トラブルは少ない!
ケース 1:データベースが壊れる
データベースは壊れる時は壊れる HW不良や突然現れる 824/823エラー 適切な RAID設計で耐障害性を高め、バックアップを取って万が一に備える バックアップは重要なデータを保護するための究極の手段
壊れたら DBは別システムから作り直す設計
諦めて我慢する
ケース 1:データベースが壊れるシステム DBのバックアップを取っていない
DBファイルとバックアップファイルが同じ
RAIDにいる
バックアップを取っていない
作り直しは時間がかかる
頑張って再作成 諦める
データ /ディスクが飛んでしまいました
ログインが消えた
バックアップも一緒に壊れた
バックアップを取っていない!
バックアップ運用、物理設計の問題
ケース 2:パフォーマンスが悪い
パフォーマンス悪化は運用する人からすると最重要課題の 1つ オンラインレスポンスの悪化 バッチウィンドウ超過
パフォーマンス悪化の原因は様々あり特定が難しいが大きく分けると 3つ リソース不足 非効率なクエリプラン SQL Server内部の待ち などなど
ケース 2:パフォーマンスが悪い要件定義での無茶振り
プロジェクト炎上
バッチの目標時間とデータ量のバランスが悪
い
受入条件とビジネス要件の乖離
APの設計問題
構造上遅くなる処理の実装(カーソルなど)
必要以上にロックをかけている
開発は進み、受入テスト時問題発覚
ケース 2:パフォーマンスが悪い
実は原因を特定するのが大変。パフォーマンス問題は根深い。
運用フェーズでパフォーマンス問題発生
設定は全て規定の値
本番中にトレースを採取
本番運用中に分析処理を実行
テスト系構築のためオンライン中にフルバックアップ
テスト DBが同じインスタンスにいてリソース
消費
設定の問題 運用の問題
ケース 2:パフォーマンスが悪い
なにもしていない人はこれだけはやっておこう Tempdbのファイル分割
コア数または8の小さいほう、の数にする 同じ RAIDの上であっても設定するだけで効果がある(はず)
Max serer memory と メモリ内のページロック設定 メモリ上限の設定と仮想メモリをページアウトさせない設定
パフォーマンスログによるベースライン採取 何が起きたのかあとからわかるようにする 異常時と正常時の比較を可能にする
ケース 2:パフォーマンスが悪い
パフォーマンス問題が潜在化
運用フェーズでパフォーマンス問題発生
CPU コアと物理メモリのバラン
ス
ディスク容量だけではく、 I/O量の考慮
パフォーマンス問題への備えが
ない
APから見てどの処理が遅いか
わからない資料は取っていても足りない
サイジングの問題 パフォーマンス問題の追究不能
ケース 3:外部連携が止まった
外部連携の典型的なパターン SSISによるデータ取り込み、転送 リンクサーバによるデータ参照や更新 レプリケーションによるデータ配信
外部連携のはまりがちな罠 データ連係の大元(多くは基幹系)の配信が止まると配信先の業務がすべて止まる 一般にアーキテクチャが複雑なのでエラーがわかりづらい
現場ではいかんともしがたい
ケース 3:外部連携が止まった
Oracleリンクサーバなど
運用中の外部連携停止、復旧、原因追究へ
サポート対象外構成になってい
る連携先のシステムが触れない
連携先の担当が他社で共同作業ができない
構成の問題 政治的な問題
連携先が他社 DBなどではよくあるSQL Serverでも難しいものは多い
ログ採取、解析が難しい
連携先のシステムに関するスキルがない
スキルの問題
失敗から学ぶ
対処できるか考えてみよう 青い箱をあつめてみる 分類してみる そもそもなんで起きたのか考えてみる 明日自分が死なないようにする
失敗から学ぶ
バックアップ、物理設計の問題
要件定義での無茶振り
APの設計問題
設定の問題
運用の問題
構成の問題
政治的な問題
スキルの問題
サイジングの問題
パフォーマンス問題の追究不能
要件定義
設計実装
運用
組織 /人
設計や実装の問題が大きい。ただし再設計はつらい適切な設計、実装、テストを行うことでトラブルは防
げる
運用や人の問題は今からでも取り組める問題
要件定義に無理があると後工程にしわ寄せが来る
これからプロジェクトに取り組む人は設計とテストに力を入れるべ
き
動いているシステムに対しては変な運用を改善する
失敗から学ぶ
テストに潜むダメパターン 品質を高めるためには入念なテストが必須 テストにもダメパターンは潜んでいる
失敗から学ぶ
本番と全く違うデータ量、分布 資料採取がない ラッシュをかけ
る仕組みがないテストが本番前
1回だけ
クエリの動作がテストと本番で異なるためテストにならない
本番で問題が起きたときにテストとの比較ができない
ピーク性能の測定ができないため、繁忙期に問題が起こる
テストで問題が起きても対処ができない
余裕を持ったスケジュールで複数回のテストを本番さながらに実施する
失敗から学ぶ
その他今からでもできる対処策 問題点の改善する
すぐできることはすぐやってしまう(まずは 3 月だし予算取り) すぐに対処するのは難しいので次回更改時にそっと差し込む
過去にやってしまった失敗をまとめてみる 障害対応履歴などから追ってみるのはとても勉強になる 設計書を見て怪しい記述を押さえておく とにかくテストは念入りに!
大切なのは同じミスを繰り返さないこと
まとめ
世の中には様々なダメパターンが存在する 重要なことは他人、そして自分の犯した失敗から学ぶこと 今からでもできる対処はあるのであきらめない 同じ失敗は 2 度は繰り返さない
参考資料
バランスドシステム(メモリの搭載量について言及)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