Infra Beginners Day Session 1-1

1. SQL Server
これだけはやっておこう
SQLTO
@elanlilac
2013/8/31

2. Agenda
 はじめに
 10分くらいで振り返るSQL Server とデータベース
 SQL Server ありがちな勘違い
 勘違いしたままだと……？
 最近のデータベースに求められること
 最低これだけはやっておこう
 余裕があればこれもやろう
 まとめ
 最後に（おまけ）

3. はじめに
 このセッションではSQL Serverのことを扱います
 本日のハッシュタグ #WinIBDay
 SQL Serverをこれから使う or 使っているけどよくわかっていない、
なんて人をターゲットにしています
 ガッチリ使っている人は真新しいことはないかもしれません
 重要なキーワードは緑字にします
 話している人の自己紹介
 SQL Serverを使ってだいたい6年くらい。DBトータルでは10年以上
 Microsoft MVP for SQL Server 2011/7～
 SQLTOメンバー
 トラブル対応、パフォーマンス問題の解決、運用課題の解決、各種設計が普段の主業務

4. 10分くらいで振り返るデータベースと
SQL Server
 Microsoft社製のWindows OSで動くRDBMS（リレーショナルデータベース）
 ライバルはXXXやYYYやZZZ（多分）
 日経コンピュータの顧客満足度でオープン系DB 第1位獲得
 SQLという言語を使ってデータの操作を実施
 多数のリクエストを、タイムリーに、整合性を保って、処理する機能を持つ
 データあるところには（基本的に）データベースあり
 様々な社会インフラ、サービス、基幹業務に使われている

5. 10分くらいで振り返るデータベースと
SQL Server
 インスタンス（インストール単位）に複数のデータベースがぶら下がる
 データベースはデータファイルとログファイルから成り立つ
 SQL文を実行すると必要に応じてデータをデータファイルからメモリに読む
 適当なタイミングで更新したデータをデータファイルへ書き込む
 更新した記録は確実にログファイルへ書き込む
 SQL文はクエリオプティマイザが最適化をして実行される
 データの一貫性を保つためにロック機構を利用する

6. 10分くらいで振り返るデータベースと
SQL Server
メモリ
（バッファキャッシュ）
データ
SQL文
クエリオ
プティマ
イザ
ログ
実行計画
もし更新済みデータがデータファ
イルへ書き戻せる前にSQL Server
が死んでもログファイルの内容か
らロールフォワードして戻すこと
ができる（ログ先行書き込み）

7. SQL Serer ありがちな勘違い
全自動 設計不要
チューニング
不要 or 不可
Oracleより
簡単
設定項目を意
識する必要が
ある
設計すると安
全に、効率的
に利用可能
チューニング
要素は多々あ
る
内部構造は
複雑

8. 勘違いしたままだと……？
パフォーマン
スの急激な悪
化
ディスク障害
時にデータが
失われる
バックアップ
からデータを
戻せない
何か障害が起
きても何もわ
からない
運用上の問題が稼働後に判明する可能性があります。
どうにかならないでしょうか

9. 最近のデータベースに求められること
（私見）
 データの保護
 安定したパフォーマンス
 動作の詳細を追える仕組み
かつてはACID属性を始めとしたデータ保護が中心だったように思いますが、昨今で
はパフォーマンスと問題解決に向けた仕組みが必要になっています。

10. 最低これだけはやっておこう
 バックアップを取ろう
 サーバのメモリは潤沢に
 メモリ関連の設定
 パフォーマンスログの取得
 トレースフラグの利用

11. 最低これだけはやっておこう
 バックアップを取ろう
 バックアップは基本中の基本。データが飛んだら一大事
 バックアップの取り方を誤っていて涙を流すケースは意外に多い
 メンテナンスプランを使うとそれほど難しくない
 バッドノウハウ
 バックアップ対象とバックアップ先が同じドライブ
 対象のディスクが死ぬとデータもバックアップも消えます
 SQL Serverのサービスを停止してファイルをバックアップしている
 システムデータベースのバックアップを取っていない

12. 最低これだけはやっておこう
 サーバのメモリは潤沢に
 SQL Serverはメモリが大量にある方が嬉しい
 メモリが足りないと深刻なパフォーマンスダウンを起こす
 必ずOSとSQL Serverは64bit版を選ぶ！できればEnterprise Edition
ディスク
メモリ
（メモリアクセス）＞（ディスクアクセス）
メモリが足りないとディスクI/O増加
パフォーマンス悪化

13. 最低これだけはやっておこう
 メモリ関連の設定
 max server memory
 SQL Serverが使う大半を占める部分（バッファプール）の最大値を指定するパラメータ
 これをセットしないとOSのメモリが足りなくなってページングが多発など深刻な状態に
 規定値は「可能な限り最大とる」
 http://technet.microsoft.com/ja-jp/library/ms178067.aspx
バッファプール
非バッファプール
8KBで管理
データキャッシュ
プランキャッシュ
・・・
Max
server
memory

14. 最低これだけはやっておこう
 パフォーマンスログの取得
 規定動作ではパフォーマンスの状態は通常はほとんど何も分からない
 クリティカルなシステムでは「通常時から」「幅広く」情報を取っている
 最低限パフォーマンスカウンタは取りましょう
 Win+R → perfmon → データコレクタセット → ユーザ定義 → 新規作成
→ データコレクタセット → 手動作成 → パフォーマンスカウンタ → 追加
 推奨はSQL関係は全部＋CPU＋Memory+Disk＋Networkを15～30秒間隔くらいで

15. 最低これだけはやっておこう
 トレースフラグの利用
 SQL Serverにはログ強化や動作変更のためのスイッチであるトレースフラグがある
 規定では取れない情報が取れるようになる
 欲しい情報に合わせて設定する必要がある
 http://technet.microsoft.com/ja-jp/library/ms188396.aspx
 デッドロックの1211や1204は設定しないとデッドロック対応が困難に
 トレースフラグは非公開のものもたくさんあるが、サポートからの指示または自
己責任にて利用する必要がある

16. 余裕があればこれもやろう
 TEMPDBのファイル分割
 定期的（できれば週次）でパフォーマンスデータの確認
 障害発生時のノウハウを共有化
 定期的なバックアップのリストア
 DB整合性の確認
 DMVによる情報採取

17. 余裕があればこれもやろう
 TEMPDBのファイル分割
 TEMPDBとはソートやカーソルなどを使うときの一時待避領域
 規定のままだと小さいサイズでファイルが1つ
 Min(CPU数,8) 個のファイル数にする
 ついでにファイルサイズは大きめに取っておく
 ファイル数を増やすと、SQL Server内の管理領域待ちが減る
http://msdn.microsoft.com/ja-jp/library/ms175527.aspx

18. 余裕があればこれもやろう
 DMVによる情報採取
 DMV=Dynamic Management Viewの略
 SQL Serverの内部に関する情報をクエリを実行することで採取可能
 以下はインデックスの断片化を調べるクエリ

19. まとめ
 SQL Serverは入れっぱなしではうまく動かないことがあります
 バックアップを取りましょう
 各種ログを取りましょう
 メモリの使い方がキモなのでケアしましょう
 APな人も是非DBのことを考えてみてください

20. 最後に（おまけ）
 DBエンジニアとしてスキルアップするにはMCITPなどの取得が手っ取り早いです
 実際手を動かすのがもっとも学びが多いです
 世の中にはSQL Serve 2014の話が出回り始めています
 データベースエンジンの最新技術を追うなら・・・
 AlwaysOn 可用性グループ（2012の可用性向上ソリューション）
 Hekaton（2014のインメモリデータベース）
 列ストアインデックス（2012のDWHで効果的な機能）
 ご清聴ありがとうございました。是非懇親会でお話しましょう