SQL ServerこれだけはやっておこうSQLTO

@elanlilac

2013/8/31

Agenda

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

はじめに

このセッションでは SQL Server のことを扱います 本日のハッシュタグ　 #WinIBDay

SQL Server をこれから使う or 使っているけどよくわかっていない、なんて人をターゲットにしています

ガッチリ使っている人は真新しいことはないかもしれません 重要なキーワードは緑字にします 話している人の自己紹介

SQL Server を使ってだいたい 6 年くらい。 DB トータルでは 10 年以上 Microsoft MVP for SQL Server 2011/7 ～ SQLTO メンバー トラブル対応、パフォーマンス問題の解決、運用課題の解決、各種設計が普段の主業務

10 分くらいで振り返るデータベースとSQL Server

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

10 分くらいで振り返るデータベースとSQL Server

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

10 分くらいで振り返るデータベースとSQL Server

メモリ（バッファキャッシュ）

データ

SQL 文クエリオプティマ

イザ

ログ

実行計画

もし更新済みデータがデータファイルへ書き戻せる前に SQL Serverが死んでもログファイルの内容から

ロールフォワードして戻すことができる（ログ先行書き込み）

SQL Serer ありがちな勘違い

全自動 設計不要チューニング

不要 or 不可

Oracle より簡単

設定項目を意識する必要が

ある

設計すると安全に、効率的

に利用可能

チューニング要素は多々あ

る内部構造は

複雑

勘違いしたままだと……？

パフォーマンスの急激な悪

化

ディスク障害時にデータが

失われる

バックアップからデータを

戻せない

何か障害が起きても何もわ

からない

運用上の問題が稼働後に判明する可能性があります。どうにかならないでしょうか

最近のデータベースに求められること（私見） データの保護 安定したパフォーマンス 動作の詳細を追える仕組み

かつては ACID属性を始めとしたデータ保護が中心だったように思いますが、昨今ではパフォーマンスと問題解決に向けた仕組みが必要になっています。

最低これだけはやっておこう

バックアップを取ろう サーバのメモリは潤沢に メモリ関連の設定 パフォーマンスログの取得 トレースフラグの利用

最低これだけはやっておこう

バックアップを取ろう バックアップは基本中の基本。データが飛んだら一大事 バックアップの取り方を誤っていて涙を流すケースは意外に多い メンテナンスプランを使うとそれほど難しくない

バッドノウハウ バックアップ対象とバックアップ先が同じドライブ

対象のディスクが死ぬとデータもバックアップも消えます

SQL Server のサービスを停止してファイルをバックアップしている システムデータベースのバックアップを取っていない

最低これだけはやっておこう

サーバのメモリは潤沢に SQL Server はメモリが大量にある方が嬉しい メモリが足りないと深刻なパフォーマンスダウンを起こす 必ず OS と SQL Server は 64bit版を選ぶ！できれば Enterprise Edition

ディスク

メモリ（メモリアクセス）＞（ディスクアクセス）

メモリが足りないとディスク I/O増加

パフォーマンス悪化

最低これだけはやっておこう

メモリ関連の設定 max server memory

SQL Server が使う大半を占める部分（バッファプール）の最大値を指定するパラメータ これをセットしないと OS のメモリが足りなくなってページングが多発など深刻な状態に 規定値は「可能な限り最大とる」 http://technet.microsoft.com/ja-jp/library/ms178067.aspx

バッファプール

非バッファプール

8KB で管理データキャッシュプランキャッシュ

・・・

Max server

memory

最低これだけはやっておこう

パフォーマンスログの取得 規定動作ではパフォーマンスの状態は通常はほとんど何も分からない クリティカルなシステムでは「通常時から」「幅広く」情報を取っている 最低限パフォーマンスカウンタは取りましょう Win+R 　→　 perfmon 　→　データコレクタセット → ユーザ定義 → 新規作成

　→ データコレクタセット → 手動作成 → パフォーマンスカウンタ → 追加 推奨は SQL関係は全部＋ CPU＋Memory+Disk＋ Network を 15 ～ 30秒間隔くら

いで

最低これだけはやっておこう

トレースフラグの利用 SQL Server にはログ強化や動作変更のためのスイッチであるトレースフラグがある 規定では取れない情報が取れるようになる 欲しい情報に合わせて設定する必要がある http://technet.microsoft.com/ja-jp/library/ms188396.aspx

デッドロックの 1211 や 1204 は設定しないとデッドロック対応が困難に

トレースフラグは非公開のものもたくさんあるが、サポートからの指示または自己責任にて利用する必要がある

余裕があればこれもやろう

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

余裕があればこれもやろう

TEMPDB のファイル分割 TEMPDB とはソートやカーソルなどを使うときの一時待避領域 規定のままだと小さいサイズでファイルが 1 つ Min(CPU 数 ,8) 個のファイル数にする ついでにファイルサイズは大きめに取っておく ファイル数を増やすと、 SQL Server 内の管理領域待ちが減る

http://msdn.microsoft.com/ja-jp/library/ms175527.aspx

余裕があればこれもやろう

DMV による情報採取 DMV=Dynamic Management View の略 SQL Server の内部に関する情報をクエリを実行することで採取可能 以下はインデックスの断片化を調べるクエリ

まとめ

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

最後に（おまけ）

DB エンジニアとしてスキルアップするには MCITP などの取得が手っ取り早いです

実際手を動かすのがもっとも学びが多いです 世の中には SQL Serve 2014 の話が出回り始めています データベースエンジンの最新技術を追うなら・・・

AlwaysOn 可用性グループ（ 2012 の可用性向上ソリューション） Hekaton （ 2014 のインメモリデータベース） 列ストアインデックス（ 2012 の DWH で効果的な機能）

ご清聴ありがとうございました。是非懇親会でお話しましょう