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のファイル分割

コア数または８の小さいほう、の数にする 同じ RAIDの上であっても設定するだけで効果がある（はず）

Max serer memory と メモリ内のページロック設定 メモリ上限の設定と仮想メモリをページアウトさせない設定

パフォーマンスログによるベースライン採取 何が起きたのかあとからわかるようにする 異常時と正常時の比較を可能にする

ケース 2：パフォーマンスが悪い

パフォーマンス問題が潜在化

運用フェーズでパフォーマンス問題発生

CPU コアと物理メモリのバラン

ス

ディスク容量だけではく、 I/O量の考慮

パフォーマンス問題への備えが

ない

APから見てどの処理が遅いか

わからない資料は取っていても足りない

サイジングの問題 パフォーマンス問題の追究不能

ケース 3：外部連携が止まった

外部連携の典型的なパターン SSISによるデータ取り込み、転送 リンクサーバによるデータ参照や更新 レプリケーションによるデータ配信

外部連携のはまりがちな罠 データ連係の大元（多くは基幹系）の配信が止まると配信先の業務がすべて止まる 一般にアーキテクチャが複雑なのでエラーがわかりづらい

現場ではいかんともしがたい

ケース 3：外部連携が止まった

Oracleリンクサーバなど

運用中の外部連携停止、復旧、原因追究へ

サポート対象外構成になってい

る連携先のシステムが触れない

連携先の担当が他社で共同作業ができない

構成の問題 政治的な問題

連携先が他社 DBなどではよくあるSQL Serverでも難しいものは多い

ログ採取、解析が難しい

連携先のシステムに関するスキルがない

スキルの問題

失敗から学ぶ

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

失敗から学ぶ

バックアップ、物理設計の問題

要件定義での無茶振り

APの設計問題

設定の問題

運用の問題

構成の問題

政治的な問題

スキルの問題

サイジングの問題

パフォーマンス問題の追究不能

要件定義

設計実装

運用

組織 /人

設計や実装の問題が大きい。ただし再設計はつらい適切な設計、実装、テストを行うことでトラブルは防

げる

運用や人の問題は今からでも取り組める問題

要件定義に無理があると後工程にしわ寄せが来る

これからプロジェクトに取り組む人は設計とテストに力を入れるべ

き

動いているシステムに対しては変な運用を改善する

失敗から学ぶ

テストに潜むダメパターン 品質を高めるためには入念なテストが必須 テストにもダメパターンは潜んでいる

失敗から学ぶ

本番と全く違うデータ量、分布 資料採取がない ラッシュをかけ

る仕組みがないテストが本番前

１回だけ

クエリの動作がテストと本番で異なるためテストにならない

本番で問題が起きたときにテストとの比較ができない

ピーク性能の測定ができないため、繁忙期に問題が起こる

テストで問題が起きても対処ができない

余裕を持ったスケジュールで複数回のテストを本番さながらに実施する

失敗から学ぶ

その他今からでもできる対処策 問題点の改善する

すぐできることはすぐやってしまう（まずは 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