Community Open Day 2012 SQL Serverの運用で気をつけたいこと

SQLTO

Microsoft SQL Server MVP

@elanlilac

• 本セッションではSQL Serverの運用に関するテーマを扱います

• SQL Serverをお使いになられた事がある方を対象としていますが、なるべく皆さんに合わせたいと思います

はじめに

• 運用について

• 設定

• データの保護

• オブジェクト管理

• パフォーマンスの管理

• まとめ

Agenda

• SQL Serverは決して「メンテナンスフリー」ではありません

• インストールしたまま何もしないで使い続けると困ったことになる・・・？ – 設定

– データ保護 – オブジェクト管理 – リソース管理 – パフォーマンス管理

• 運用、やっていますか？

• 運用が適切だと問題の未然防止と対応の迅速化が可能です

運用について

運用について

設計フェーズ

テストフェーズ

運用フェーズ

パラメータ、設定の考慮 バックアップの考慮

バックアップ実装の確認 パフォーマンスの確認

オブジェクトの管理 パフォーマンスの管理

• 細かく言うと、たくさん設定する項目があり、設定値がケースバイケースで決まるものもたくさんあります

• その中でも以下のものは設定を変更しても損はないと思います – Max server memory

– メモリ内のページロック権限付与

– Tempdbのファイル数

パラメータ、設定

• SQL Serverが使うバッファプールの最大値を指定する – 2012からメモリの区分けが若干変更された

–バッファプールにはデータキャッシュやプランキャッシュが置かれる

Max server memory

バッファプール

非バッファプール ユーザの仮想メモリ空間 32bit だと通常2GB 64bit(x64) だと8TB

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

・・・

• Max server memoryは既定値では上限無し – OSの物理メモリが不足するとページングが発生する

–ページングは深刻なパフォーマンス劣化に繋がる

• 最適な設定値を決めるのは難しいが、少なくともOSが物理メモリを数GB利用できるようにするのが望ましい

Max server memory

仮想メモリ

物理メモリ

ページファイル

物理メモリ不足によるページング

• SQL Serverが使っている物理メモリをページアウトさせない設定 – http://support.microsoft.com/kb/918483/

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

– http://support.microsoft.com/kb/970070/ja

• SQL Serverの起動アカウントに権限を付与する

• Standard Editionを使っている場合、SQL Server 2005 SP3 CU4 または SQL Server 2008 SP1 CU2以降のバージョンとTF845が必要。2008R2はRTMであればTF845を有効にすれば対応可能

メモリ内のページロック権限

メモリ内のページロック権限

• Tempdbの用途 – 一時テーブル

– テーブル変数

– カーソル

– ORDER BYによる並び替えに伴うワーク領域

– GROUP BYによる集計に伴うワーク領域

– HASH PLANによるワーク領域

– バージョンストア

• アプリケーションによっては多数のセッションがtempdbを使う

• Tempdbにボトルネックがある場合、多数のセッションが影響を受ける

Tempdbのファイル数

• Tempdbのパフォーマンスの最適化 – http://msdn.microsoft.com/ja-jp/library/ms175527.aspx

• ファイルパスを規定のシステムドライブから変更する

• ファイル数を目安としてCPUコア数と合わせる

• ファイルサイズを均等にする

• 最初からサイズを大きくし、なるべく自動拡張を起こさせない

• Tempdbのファイル数を増やすことで管理領域での競合が低下する (PAGEPATCHでの待ちが軽減する）

Tempdbのファイル数

• バックアップ取っていますか？

• バックアップをおろそかにしているといざというときに困ります。困ったときに誰も助けられない状態になります

データの保護

• バックアップの取り方 – バックアップソフトウェアによる設定

– SQL Serverにはメンテナンスプランがある

データの保護

バックアップの種類 対象 概要

完全 データ データベース全体のバックアップ

差分 データ 完全バックアップに対する更新されたデータのバックアップ

トランザクションログ トランザクションログ 完全バックアップ以降の更新ログのバックアップ

• バックアップ対象とバックアップ先が同じドライブ – HDD破損の場合ドライブごとお釈迦になるケースがほとんど

– 実データとバックアップが同時に壊れる

– バックアップが無くなる・・・

• SQL Serverのサービス停止によるオフラインバックアップ – MSはサービス停止によるオフラインバックアップは非推奨

– デタッチしたファイルのバックアップはOK！

– http://support.microsoft.com/kb/949060/ja

データの保護

• DBCC CHECKDBを使ってデータの正常性を確認していない – DBCC CHECKDBはDBの物理構造を確認してくれる

– バックアップコマンドは必ずしも破損に気づいてくれない

– 壊れたデータをバックアップし続けると・・・

– リストアのときに破損に気づいてもとき既に遅し

• リストアの手順を確認していない – リストアの手順を確認していないバックアップは有事の際に使えますか？

– リストアポイントが不明瞭、必要なバックアップが足りない（ログやシステムDB）

• 複数のDB間でのデータ整合性を考慮していない – APによっては複数DBにまたがる処理をしているケースがある

– そのときのリカバリ方法、大丈夫ですか？

データの保護

• 統計情報の更新 – SQL Serverは統計情報を元にクエリの実行プランを作る – 規定では自動で更新されるが、変更量が一定ラインを超えたときに更新される – 統計情報と実際のデータ分布が違うことはクエリが遅くなる原因の1つ – 大規模なデータの入れ替えやtruncate後は更新を検討する – フルスキャンでの更新は時間がかかるが、正確に状態を把握できる

オブジェクト

クエリ

統計情報

クエリオプティマイザ

データ

アクセス方法が決まる

データ分散など

• インデックスメンテナンス – 更新処理はインデックスの断片化を引き起こす

– インデックスの断片化はスキャン処理の性能に影響がある

– ReorganizeとRebuildの2つのメンテナンス方法がある

– 30%を超える断片化にはRebuildが有効

オブジェクト

方式 イメージ

ALTER INDEX REBUILD 作り直し

ALTER INDEX REORGANIZE 並び替え

• メンテナンスプランについて – メンテナンスプランはデータベース管理のための便利機能

– 基本的な管理タスクをウィザード形式で定義できる

– 手動作成することで柔軟な設定も可能

– SQL Server Agentが必要

メンテナンスプラン

• パフォーマンス劣化はDBAにとって頭の痛い問題（だと思います）

• パフォーマンスに関する情報は既定動作では採取されない – 採取設定をしていない場合は1度の問題発生では分析ができない

– あらかじめ情報を採取しておくべき

• 「遅い」現象と「いつもの」状態を比べる必要がある – 「いつもの」情報はベースラインと呼ばれ、定常的に採取すべき情報

– パフォーマンス問題は遅いときの情報だけで絶対値評価することは難しい

パフォーマンスの管理

• パフォーマンスカウンタ – サーバやインスタンスの状態を全体的に把握するのに便利

• DMV – 様々な観点で内部情報を採取出来る

– ロック情報や待機情報など、SQL Server内部の状態を知ることが出来る

• Profiler/トレース – SQL Server内で発生しているイベントを記録することが出来る

パフォーマンスの管理

• 採取タイミングとリソース – 負荷の小さいものは常時取っておく方がよい

– 出力負荷、サイズがシステムに対して大きく、ログ管理負荷が高まる場合は要検討

– トレースなどは可能であれば開発機などで再現させて取る方がよい

パフォーマンスの管理

採取タイミング ログの大きさ 負荷

パフォーマンスカウンタ 常時

DMV 可能であれば常時

トレース 現象狙い撃ち

• トレースの問題点 – 重い – 重い – とにかく重い – 死ぬほど重い – 一般的に本番環境では仕掛けられない程重い

• SQL Server 2012 の新機能 – 拡張イベントという内部状態を確認する方法が2008から存在した – 2012では拡張イベントの強化とGUIによる制御が可能となった

• 拡張イベントの利点 – トレースに比べて、軽くなっている（と言われている）ことが最も大きい

パフォーマンスの管理

• 運用設計

• 運用体制の明確化、手順の標準化

• セキュリティ管理

• ライフサイクル管理

• ログファイル管理

• 警告と通知

• ・・・

その他のトピック

• よくある運用に関するトピック

• フェーズごとに実施できる運用への考慮

• 比較的簡単にできる設定項目の紹介

• 運用中に採取できる、採取した方がよい項目

まとめ

皆さんが知らないことがあったら是非やってみてください！

• SQLTOが8/4に勉強会をやります

– たぶん、会場はSGT！

– おそらく、豪華な講師陣！

– きっと、他では聞けない濃い内容！

– SQLTO代表が北から来る（かもしれない）！

CM