COD2012 T2/T3 : 実機で試す SQL Server の現状取得ハンズオンマニュアル

実機で試す SQL Server の現状取得
- ハンズオンマニュアル -

SQLTO 小澤真之

2012/06/09


目次

1. はじめに .................................................................................................................... 2
1-1. ハンズオンについて ................................................................................................... 2
1-2. ハンズオン環境 ....................................................................................................... 2
2. ハンズオン 1 : データ / プランキャッシュの使用状況の確認 .......................................................... 3
2-1. ハンズオンの概要 .................................................................................................... 3
2-2. ハンズオンを終えると ................................................................................................. 3
2-3. ハンズオンの想定時間 ............................................................................................... 3
2-4. 演習内容 ............................................................................................................ 4
2-5. ハンズオン 1 のまとめ .............................................................................................. 13
3. ハンズオン 2 : インデックスの使用状況の確認 ........................................................................ 14
3-1. ハンズオンの概要 ................................................................................................... 14
3-2. ハンズオンを終えると ................................................................................................ 14
3-3. ハンズオンの想定時間 .............................................................................................. 14
3-4. 演習内容 ........................................................................................................... 15
3-5. ハンズオン 2 のまとめ .............................................................................................. 21
4. ハンズオン 3 : パフォーマンスモニターのログ取得 ...................................................................... 22
4-1. ハンズオンの概要 ................................................................................................... 22
4-2. ハンズオンを終えると ................................................................................................ 22
4-3. ハンズオンの想定時間 .............................................................................................. 22
4-4. 演習内容 ........................................................................................................... 23
4-5. ハンズオン 3 のまとめ .............................................................................................. 31

Community Open Day 2012 1


1. はじめに

1-1. ハンズオンについて

本ハンズオンでは SQL Server 2012 を使用した以下の 3 種類の演習を用意しています。
 ハンズオン 1 : メモリの使用状況の確認

 ハンズオン 2 : インデックスの使用状況の確認

 ハンズオン 3 : パフォーマンスモニターのログの取得

ハンズオン 3 は時間が余った方向けの演習としております。
ハンズオン 1 / 2 の終了を目標として演習の実施をお願いいたします。

操作方法について不明な点がありましたらお気軽にお声掛けください。
内容について確認したいことがありましたら最後に質疑応答の時間を用意しておりますのでそちらでご質問ください。
なお、セッション終了後、個別にご質問いただいても問題ございません。

1-2. ハンズオン環境

本ハンズオンでは以下の環境を使用しています。
 Hyper-V 上のゲスト OS

 OS : Windows Server 2008 R2 SP1 Enterprise Edition (評価版)

 SQL Server : SQL Server 2012 Enterprise Evaluation Edition (評価版)

本演習はエディションに依存する機能ではなく基本的なクエリを使用しておりますので、無償の SQL Server 2012 Express Edition でも

実施していただくことが可能です。

なお、本演習で使用しているクエリは SQL Server 2012 だけでなく SQL Server 2008 R2 でも動作を確認していますので最新の

SQL Server でなくても利用することができます。

ゲスト OS のログオンには以下のアカウント / パスワードを使用してください。
 アカウント : Administrator

 パスワード : password (すべて小文字でパスワード)

Ctrl + Alt + Delete はメニューの [操作] → [Ctrl + Alt + Delete] または、[Ctrl] + [Alt] + [End] を押して下さい。

ハンズオンで使用するクエリに関してはデスクトップの [ハンズオン用クエリ] フォルダにテキストで保存してあります。
クエリがうまく実行できない場合などはこのフォルダ内のテキストをご利用ください。



2. ハンズオン 1 : データ / プランキャッシュの使用状況の確認

2-1. ハンズオンの概要

このハンズオンでは SQL Server に格納されているデータをキャッシュするメモリ領域の中でデータキャッシュ (Database
Cache) と、データを取得するために実行した SQL 文をキャッシュするメモリ領域であるプランキャッシュ (Plan
Cache) がどの程度のメモリを使用しているのかを確認します。

2-2. ハンズオンを終えると

SQL Server の以下の状態を確認できるようになります。
 データベース単位でキャッシュのサイズを取得できる

 クエリの分類ごとにキャッシュのサイズを取得できる

2-3. ハンズオンの想定時間

15 分



2-4. 演習内容

1. [スタート] → [すべてのプログラム] → [Microsoft SQL Server 2012] → [Microsoft SQL Server
Management Studio] (以降、SSMS) を実行します。
2. [認証] は [Windows 認証] を選択した状態で、[接続] をクリックします。

Tips
ローカルサーバーに接続をする場合、サーバー名に . (ドット) を入力して接続して接続することもできます。

この場合は SSMS を起動しているサーバーの既定のインスタンスに接続されます。

名前付きインスタンスに接続をする場合は .<インスタンス名> で接続することができます。

3.
をクリックします。

4.
クエリエディタが開いたら、以下のクエリを入力してをクリックして、データベースを作成します。

CREATE DATABASE [COD2012]

ALTER DATABASE [COD2012] SET RECOVERY SIMPLE

データベースが作成されると左ペインのオブジェクトエクスプローラーの [データベース] の下に [COD2012] が
作成されます。



Tips
CREATE DATABASE でファイルの場所を指定しない場合にはインストール時に指定した既定のデータ / ログファイル

のディレクトリが使用されます。

サイズ等の設定は [model] データベースが使用されます。

正常に実行されているがデータベースが表示されない場合はを選択した状態でをクリッ

クして最新の状態に更新します。
※ 以降の操作で正常に実行しても表示されない場合は同様の操作をして最新の状態に更新してください。
5.
クエリエディタに以下のクエリを入力してをクリックして、テーブルを作成します。

※ 以降の操作でクエリを入力する場合、前の操作で入力していたクエリは削除して問題ありません。

をクリックして新しいクエリエディタを開いて実行しても問題ありません。

※ SSMS の操作方法が分かる方はデザイナを使用してテーブルを作成しても問題ありません。
USE COD2012

GO

CREATE TABLE dbo.Ex01

(

Col1 int NOT NULL IDENTITY (1, 1),

Col2 uniqueidentifier NULL,

Col3 uniqueidentifier NULL,

Col4 char(4100) NULL

) ON [PRIMARY]

GO

ALTER TABLE dbo.Ex01 ADD CONSTRAINT

PK_Ex01 PRIMARY KEY CLUSTERED

(Col1)

GO

Tips
クエリをそれぞれのステートメント単位で実行して確認をしたい場合には、実行したいステートメントを選択した状態で実行する
とクエリエディタ内の一部分のみを実行することができます。



テーブルが作成されると左ペインのオブジェクトエクスプローラーの [COD2012] の [テーブル] の下に [Ex01]
が作成されます。

6.
クエリエディタに以下のクエリを入力してをクリックして、テーブルにデータを挿入します。

このクエリを実行することで、400MB 程度、データベースのデータ領域が使用されます。
実行には 2 分ほどかかりますので、クエリを実行し [メッセージ] にエラーが表示されてないことを確認したら次の
操作に移ってください。
USE COD2012

SET NOCOUNT ON

GO

INSERT INTO Ex01 (Col2, Col3, Col4)

VALUES (NEWID(), NEWID(), NEWID())

GO 50000

Tips
SET NOCOUNT ON を実行することで INSERT を実行した際の [(1 行処理されました)] のメッセージが表示さ

れなくなり、処理時間を多少短縮することができます。

GO の後に実行回数を記述することでバッチ (GO までの複数のステートメント) を繰り返し実行することができます。

7. [スタート] → [ファイル名を指定して実行] に [perfmon] と入力し、[OK] をクリックして、パフォーマンスモニ
ターを起動します。
※ スタートに [ファイル名を指定して実行] が表示されていない場合は、[すべてのプログラム] → [アクセサリ]
または [Win キー] + [R] で [ファイル名を指定して実行] を起動します。



8.
[モニターツール] → [パフォーマンスモニター] を選択して、をクリックします。

9. [使用可能なカウンター] から [SQL Server:Memory Manager] を選択し、そのカウンターに含まれる
 Database Cache Memory (KB)

 Free memory (KB)

 Total Server Memory (KB)

を [追加 >>] をクリックして追加し、[OK] をクリックします。

Tips
SQL Server のパフォーマンスモニターに関する値は SSMS で [sys.dm_os_performance_counters] を

参照することでも取得できます。

10.
の [▼] をクリックしてグラフの種類を [レポート] に変更します。

11. SQL Server のメモリの使用状況がレポート形式で表示されます。

各カウンターの内容は以下のようになっています。
カウンター名説明

Database Cache Memory (KB) サーバーがデータベースキャッシュに現在使用しているメモリの量。

Free memory (KB) 現在未使用のメモリの量



Total Server Memory (KB) サーバーが現在使用している動的メモリの総容量

Tips
INSERT した結果はデータベースのデータファイルだけでなくメモリ上にも格納されます。
そのため、前の操作で実行された INSERT のデータが Database Cache Memory に格納されています。

パフォーマンスモニターの [Database Cache Memory (KB)] を確認することで SQL Server のインスタン
スでどの程度データのキャッシュにメモリを使用しているかを確認することができます。
ただし、この情報ではデータベース単位でメモリの使用状況を確認することはできません。
次の演習では SSMS を使用してデータベース単位でデータのキャッシュに使用しているメモリを確認してみます。
12.
SSMS を開き、クエリエディタに以下のクエリを入力してをクリックして、データベース単位でデータのキ

ャッシュに使用しているメモリを確認してみます。
SELECT

DB_NAME(database_id)

, COUNT(*) * 8

FROM

sys.dm_os_buffer_descriptors

WHERE

DB_NAME(database_id) IS NOT NULL

GROUP BY

database_id

ORDER BY

1

Tips
sys.dm_os_buffer_descriptors はデータのキャッシュをページ単位で確認することができます。

SQL Server では 1 ページを 8KB で管理しているため、ページ数 (COUNT) × 8 をすることで、KB の

サイズに変換しています。

クエリを実行すると以下のような結果が取得できます。
これがデータベース単位でデータのキャッシュ状態を取得したものになります。



すべてのデータベースのキャッシュサイズを合計したものがパフォーマンスモニタで確認した [Database Cache
Memory (KB)] と近い値になっていることが確認できます。
SQL Server に複数のデータベースを作成している場合はこの演習のクエリを使用することでどのデータベースの
データが多くキャッシュされているかを確認することができます。
SQL Server のキャッシュで多くの比率を占めるものとして、データのキャッシュの他にクエリ (SQL) のキャッシュ
があります。
次の演習ではクエリのキャッシュ状況を確認します。
13.
SSMS を開きクエリエディタに以下のクエリを入力してをクリックしてクエリのキャッシュを増加させます。

このクエリを実行することで、1,400MB 程度、クエリのキャッシュ領域が使用されます。
実行には 2 分ほどかかりますので、クエリを実行し [メッセージ] タブにエラーが表示されてないことを確認したら次
の操作に移ってください。
USE COD2012

SET NOCOUNT ON

GO

DECLARE @sql nvarchar(max)

DECLARE @i int = 3000

DECLARE @cd int

WHILE (@i <= 3900)

BEGIN

SET @cd = 65

WHILE (@cd <= 90)

BEGIN

SET @sql = N'DECLARE @tmp nvarchar(max);'

SET @sql += N'SELECT @tmp = N''' + REPLICATE(NCHAR(@cd), @i) + N''''

SET @sql += N' FROM sys.objects'

EXEC (@sql)

SET @cd += 1



END

SET @i += 1

END

Tips
このクエリを実行すると文字列連結による生成された大量のアドホッククエリ (パラメーター化されていない再利

用される可能性の低いクエリ) が実行されます。

実行結果を変数に代入することでクエリエディタの結果ウィンドウに出力がされないようにしています。

どのようなアドホッククエリが実行されているかを確認したい場合は [EXEC (@sql)] の前に [PRINT @sql]

を追加して実行してみてください。メッセージのタブに @sql の内容が出力されます。

他にも、デバッグ実行で変数の内容を確認することもできます。

15.

16. [使用可能なカウンター] から [SQL Server:Plan Cache] を選択し、そのカウンターに含まれる
 Cache Object Counts → <すべてのインスタンス>

 Cache Pages → <すべてのインスタンス>

を [追加 >>] をクリックして追加し、[OK] をクリックします。



17.
の [▼] をクリックしてグラフの種類を [レポート] に変更します。

18. SQL Server のメモリの使用状況がレポート形式で表示されます。

各カウンターの内容は以下のようになっています。

Cache Object Counts キャッシュ内のキャッシュオブジェクト数

Cache Pages キャッシュオブジェクトが使用している 8 KB 単位のページ数

_Total 合計

Bound Trees ビュー、制約、デフォルトの代数化ツールにより使用されている領域

Extended Stored Procedures 拡張ストアドプロシージャにより使用されている領域

Object Plans ストアドプロシージャ、関数、トリガーにより使用されている領域

SQL Plans アドホック、自動パラメータ化、プリペアードのプランにより使用されている領域

Temporary Tables & Table Variables 一時テーブル、テーブル変数により使用されている領域

Tips
Plan Cache の Cache Pages は 8KB ページのページ数で表されるためメモリの使用サイズを算出する場合は 8KB を

かけて値を求めます。

例) Cache Pages = 200 の場合 : 200 × 8KB = 1,600 KB メモリを使用している。

なお、SQL Server に関するパフォーマンスモニターの値は SSMS から [sys.dm_os_memory_cache_counters]

を参照することで取得することもできます。

パフォーマンスモニターの [SQL Sever:Plan Cache] ではひとつのカウンターで複数の種類を含んでいます。



例えば、SQL Plans にはアドホッククエリ (文字列連結により単純に生成したクエリ)、プリペアードクエリ (パラメ
ーターを使用したクエリ) の両方のプランが含まれているため、どちらが含まれているのかが判断できません。
※ 一般的にはアドホッククエリではなくプリペアードクエリを使用することでキャッシュのヒット率が向上します。
アドホッククエリ : SELECT * FROM sys.objects WHERE name = ’AAAAA’
プリペアードクエリ : SELECT * FROM sys.objects WHERE name = @param1

SSMS を使用してさらに詳細な種類単位でクエリのキャッシュに使用しているメモリを確認してみます。
19.
SSMS を開き、クエリエディタに以下のクエリを入力してをクリックして、種類単位でクエリのキャッシュ

に使用しているメモリを確認してみます。
SELECT

cacheobjtype

, objtype

, SUM(size_in_bytes)

FROM

sys.dm_exec_cached_plans

GROUP BY

cacheobjtype

, objtype

クエリを実行すると以下のような結果が取得できます。
これが種類単位でクエリのキャッシュ状態を取得したものになります。

パフォーマンスモニタでは SQL Plans の内容がアドホック (Adhoc) かプリペアード (Prepared) なのかはわ
かりませんでしたが、クエリを実行することでどちらの種類のクエリが使用しているメモリが多いのか確認することがで
きます。先ほど、大量のアドホッククエリを実行したので [Compiled Plan] の [Adhoc] が高い値を示してい
ることが確認できます。
アドホッククエリは再利用される可能性が低く条件が違うだけの類似のクエリのプランが多数キャッシュされている可
能性があります。プリペアードクエリを多くすることで類似クエリを一つのプランで処理できるようになりメモリの有効活
用ができます。



2-5. ハンズオン 1 のまとめ

このハンズオンでは SQL Server のデータ / クエリで使用されているメモリの使用量を確認しました。
パフォーマンスモニターでは取得が出来ない詳細なメモリの情報 (データベース別 / クエリの種類別) に関しては動的管
理ビュー (DMV) を使用して取得することができます。

SQL Server のメモリの使用状況を確認する場合、
 SQL Server でメモリを～ MB 使用している

という状態を確認するのではなく
 SQL Server のデータのキャッシュで～ MB メモリを使用している

 SQL Server のクエリのキャッシュで～ MB メモリを使用している

 データのキャッシュの中で～データベースが～ MB メモリを使用している

 クエリのキャッシュではストアドプロシージャが～ MB / アドホッククエリが～ MB / プリペアードクエリが～ MB メモリを使用している

という情報が重要になってきます。
本ハンズオンの演習内容を使用することで一段階踏み込んだ情報を取得できるようになります。

今回は解説をしませんでしたが SQL Server では以下のカウンターでメモリの状態を調査するために有益な情報を取
得することができますので興味のある方がいらっしゃいましたらこれらのカウンターについて調べてみると勉強になると思いま
す。

SQLServer:Buffer ManagerPage life expectancy バッファープール内でページが参照されなくても保持される秒数。

SQLServer:Buffer ManagerBuffer cache hit ratio ディスクから読み取らずに、バッファープール内で見つかったページのパーセンテージ。

SQLServer:Plan CacheCache Hit Ratio キャッシュのヒット数と参照回数の比率

以上でハンズオン 1 の演習は終了です。



3. ハンズオン 2 : インデックスの使用状況の確認


このハンズオンでは SQL Server でデータを検索する際に使用されるインデックス (索引) の使用状況を取得し、イン
デックスの代表的な操作である Scan / Seek のどちらが多く使用されているか、インデックス自体の使用状況の確認を
します。


SQL Server の以下の状態を確認できるようになります。
 テーブル操作の傾向を確認できる

 インデックス操作の傾向を確認できる
 インデックスの使用状況を確認できる

 追加が必要なインデックスを判断するための情報を確認できる


15 分



3-4. 演習内容

3.

4.
クエリエディタが開いたら、以下のクエリを入力してをクリックして、非クラスター化インデックスを作成し

ます。
USE COD2012

GO

CREATE NONCLUSTERED INDEX [NCI_Ex01_Col2] ON

[dbo].[Ex01]

(

[Col2] ASC

)

インデックスが作成されると左ペインのオブジェクトエクスプローラーの [dbo.Ex01] の [インデックス] の下に
[NCI_Ex01_Col2] が作成されます。

5.
クエリエディタに以下のクエリを入力してをクリックして、インデックスの使用状況を確認します。

※ このクエリは次の操作でも使用しますので実行したらクエリを消さずに残しておいてください。
USE COD2012

GO

SELECT

OBJECT_NAME(si.object_id)

, si.name

, si.index_id

, si.type_desc

, ius.user_seeks

, ius.user_scans

, ius.last_user_seek



, ius.last_user_scan

FROM

sys.indexes AS si

LEFT JOIN

sys.dm_db_index_usage_stats ius

ON

ius.object_id = si.object_id

AND

ius.index_id = si.index_id

WHERE

si.object_id = OBJECT_ID(N'dbo.Ex01')

クエリを実行することで各インデックスについて Scan / Seek 操作が行われた回数を確認することができます。
これらの情報は SQL Server が最後に起動してからの累計値となっているため SQL Server のサービスが再
起動されるとリセットされますので、使用状況を確認する場合はサービスの再起動が行われる前に情報を取得す
る必要があります。

Tips
[sys.dm_db_index_usage_stats] には一度でも使用されたインデックスの情報が格納されています。

そのため、SQL Server が起動してから一度も使用されていないインデックスについてはこの DMV (動的管理ビュ

ー) の情報だけでは取得できません。

一度も使用されていないインデックスを含めて確認をする場合にはシステムテーブルの [sys.indexes] をベーステ

ーブルとして、[sys.dm_db_index_usage_stats] と JOIN をするという対応が必要になります。

6.
クエリエディタに以下のクエリを入力してをクリックして、インデックスを使用したクエリを実行します。

SELECT COUNT(*) FROM Ex01

SELECT COUNT(*) FROM Ex01 WITH(INDEX=0)

SELECT COUNT(*) FROM Ex01 WHERE Col2 = NEWID()

実行が終了したら先程の操作で実行したインデックスの使用状況を取得するためのクエリを実行して、各操作が
記録されているか確認をします。



それぞれの行を個別に実行し、想定されている操作の実行回数があがっているか確認してみてください。

Tips
最初のクエリを実行することで非クラスター化インデックス (indexid = 2) の Scan が行われるので、非クラ

スター化インデックスの [user_scans] がカウントアップします。

(非クラスター化インデックスが設定されているテーブルに対しての件数取得は非クラスター化インデックスの

Scan 操作が行われる傾向が強いです)

2 番目のクエリも同様に件数の取得を行っていますが、インデックスヒントを使用してインデックスを使用しないよ
うにしています。この場合はクラスター化インデックスの Scan 操作となるためクラスター化インデックスの

[user_scans] がカウントアップします。

最後のクエリでは WHERE 句に非クラスター化インデックスが使われる条件を指定しています。この場合は、

非クラスター化インデックスを使用した Seek 操作が行われる傾向が強いため、非クラスター化インデックスの

[user_seeks] がカウントアップします。

インデックスは検索効率を高めるために有効な設定ですが、テーブルにデータを挿入 / 更新を行った際にインデッ
クスに対してのデータの変更が発生するためインデックスを設定しすぎると更新系の処理に影響が出てきます。
次の演習ではテーブルの更新の頻度を確認してみます。
7.
クエリエディタに以下のクエリを入力してをクリックして、テーブルの更新頻度を確認します。

※ このクエリは次の操作でも使用しますので実行したらクエリを消さずに残しておいてください。
USE COD2012

GO

SELECT

OBJECT_NAME(si.object_id)

, si.name

, si.index_id

, ios.leaf_insert_count

, ios.leaf_delete_count

, ios.leaf_ghost_count



, ios.leaf_update_count

FROM

sys.indexes AS si

LEFT JOIN

sys.dm_db_index_operational_stats(DB_ID(), NULL, NULL, NULL) ios

ON

ios.object_id = si.object_id

AND

ios.index_id = si.index_id

WHERE

si.object_id = OBJECT_ID(N'dbo.Ex01')

各インデックスについて INSERT / DELETE / UPDATE が行われた回数が取得できます。

Tips
[sys.dm_db_index_operational_stats] には一度でも操作されたインデックスの情報が格納されています。

そのため、先ほど使用した [sys.dm_db_index_usage_stats] と同様に SQL Server が起動してから操作が行

われていないインデックスについては情報を取得することができないため同様の対応が必要となります。

8.
クエリエディタに以下のクエリを入力してをクリックして、データを更新するクエリを実行します。

USE COD2012

GO

INSERT INTO Ex01 (Col2, Col3) VALUES (NEWID(), NEWID())

DELETE FROM Ex01 WHERE Col1 = (SELECT TOP 1 Col1 FROM Ex01)

UPDATE Ex01 SET Col2 = NEWID() WHERE Col1 = (SELECT TOP 1 Col1 FROM Ex01)

UPDATE Ex01 SET Col3 = NEWID() WHERE Col1 = (SELECT TOP 1 Col1 FROM Ex01)

実行が終了したら先程の操作で実行したテーブルの更新頻度を取得するためのクエリを実行して、各操作が記
録されているか確認をします。
それぞれの行を個別に実行し、想定されている操作の実行回数があがっているか確認してみてください。



Tips
最初のクエリを実行することでデータの挿入が行われます。

データの挿入が行われた場合、クラスター化インデックスと非クラスター化インデックスにデータを挿入する必要があり

ますので両インデックスの INSERT (leaf_insert_count) がカウントされます。不要なインデックスが設定されて

いると INSERT 時に挿入する必要のあるインデックスの数が増えるため更新のコストが高くなります。

2 番目のクエリはデータの削除を行っています。

データの削除が行われた場合、クラスター化インデックスと非クラスター化インデックスから対象となるデータを削除す

る必要がありますので両インデックスの DELETE がカウントされます。SQL Server ではデータの削除を行った場

合、データが即時にディスク上から削除されるのではなくゴーストレコード (Ghost Record) としてマークされ、バッ

クグラウンドのタスク (Ghost Cleanup Task) でデータの最終的な削除が行われます。そのため、DMV では

[leaf_ghost_count] としてカウントされています。

3 番目のクエリでは Col2 に対して更新を行っています。Col2 は非クラスター化インデックスでも使用している列

なので、クラスター化インデックスと非クラスター化インデックスに対して更新が行われます。

ただし、クラスター化インデックスでは UPDATE (leaf_update_count) がカウントされますが、非クラスター化イ

ンデックスでは更新は [DELETE して INSERT された行] として認識されますので UPDATE ではなく
DELETE (leaf_delete_count) / INSERT (leaf_insert_count) の両方がカウントされています。

最後のクエリでは Col3 に対して更新を行っています。Col3 はクラスター化インデックスにのみ含まれている列です
ので、クラスター化インデックスの操作のみカウントされ非クラスター化インデックスの操作にはカウントされません。

インデックスを設定すると更新される対象が多くなりますが、頻繁に検索が行われる列に対してインデックスを設定
することで検索の効率が大幅に向上します。
次の演習では、インデックスが設定されていない列に対して検索が行われているかを確認してみます。
9.
クエリエディタに以下のクエリを入力してをクリックして、インデックスが設定されていない列に対してのク

エリを実行します。



USE COD2012

GO

SELECT * FROM Ex01 WHERE Col3 = NEWID()

DECLARE @tmp int

SELECT @tmp = Col1 FROM Ex01 WHERE Col3 > NEWID()

インデックスが設定されていない列に対して検索がされた場合、不足しているインデックスを管理している DMV
(sys.dm_db_missing_index_details) に情報が記録されます。
以下のクエリを実行して、インデックスが設定されていない列に対して検索が行われたかを確認します。

USE COD2012

GO

SELECT

*

FROM

sys.dm_db_missing_index_details

Tips
Col3 はインデックスが設定されていない列になります。インデックスが設定されていない列に対して検索が行われると欠落したイン

デックスの情報を格納している DMV に情報が格納されます。

検索の条件や取得する列によって格納される情報が変わりますので、追加で設定を行うかの判断の参考として取得した情報を

使用することができます。




このハンズオンではインデックス / テーブルの操作状況について確認をしました。
データの件数が多いテーブル (クラスター化インデックス) に非クラスター化インデックスを設定することで検索の効率が向
上しますが、更新の頻度が多いテーブルだった場合には、更新される対象が多くなり更新のコストが上がる可能性があり
ます。
本ハンズオンのインデックスの操作状況を確認することで
 更新頻度の高いテーブルの判断

 更新頻度の高いテーブルに不要なインデックスが設定されていないか

という判断の取り掛かりとなる情報を取得することが可能となります。
また、インデックスが設定されていない列に対しての検索が行われた場合、欠落したインデックスの DMV に情報が格納さ
れるためインデックスの追加が必要な列の判断材料とすることができます。

なお、SQL Server にはインデックスチューニングを補助するためにデータベースエンジンチューニングアドバイザー
(DTA) というツールが提供されています。インデックスチューニングをする際に便利なツールですのでインデックスチューニン
グについて興味のある方がいらっしゃいましたらこちらのツールについても調べてみるとよいと思います。
※ 現状、不具合で SQL Server 2012 より追加された照合順序である SC (SC : Supplementary
Characters) を使用しているとこのツールを実行するとエラーとなり起動することができないので注意してください。
どのようなエラーになるか気になった方はハンズオン環境で DTA を起動してみてください。
現状の回避策としては、SC の照合順序を使用しないでインストールをする必要があります。
(ハンズオン環境は SQL Server 2012 で追加された SC の照合順序を使用するようにしてインストールしてあり
ます。)




4. ハンズオン 3 : パフォーマンスモニターのログ取得


このハンズオンではパフォーマンスモニターを使用したログの取得を行います。
パフォーマンスモニターではリアルタイムの状況だけでなく、特定の期間の状態をログとして取得することが可能です。
SQL Server 2008 以降の Enterprise Edition では、パフォーマンスデータコレクションというパフォーマンスの状態
をログとして取得する機能を使用することができますが、パフォーマンスモニターは OS 標準の機能ですので SQL
Server のエディションに依存せずに使用することができます。
(Windows 7 のようなクライアント OS でもパフォーマンスモニターを使用することができます。)


パフォーマンスモニターの情報をログとして CSV ファイルに出力することができます。


10 分
※ 本ハンズオンはオプションとなります。時間が余った場合に実施してください。



4-4. 演習内容


Tips
今回は SQL Server を実行している端末上でログを取得していますが、ログの取得は取得している端末に負荷がかか

ります。そのため実際の運用環境では、ログ収集用の端末を準備してログを取得することが推奨されます。

また、ログの取得を行うと、取得している端末 (パフォーマンスモニターを実行している端末) だけでなく、取得されている

端末 (パフォーマンスモニターの取得対象となる情報を出力している端末 : 今回は SQL Server が実行されている
端末) に負荷がかかることを認識しておく必要があります。

2. [データコレクターセット] → [ユーザー定義] を右クリックして、[新規作成] → [データコレクターセット] を
クリックします。

3. [手動で作成する (詳細)] を選択して、[次へ] をクリックします。

4. [データログを作成する] の [パフォーマンスカウンター] を選択して、[次へ] をクリックします。



5.  [追加] をクリックして、以下のカウンターを追加します。

 SQLServer:Memory Manager

追加をしたらサンプルの期間を [1 秒] に変更して、[次へ] をクリックします。

Tips
サンプルの間隔はデータを取得する間隔となります。

デフォルトのサンプルの間隔は [15 秒] となっているため、一時間データを取得するとした場合は、[240] 行のデータ

が取得されることになります。細かな状態の遷移を取得したい場合は、15 秒間隔では不足していることがあります。

間隔を短くした場合は詳細な繊維のデータが取得できますがデータ取得のための負荷、ログのファイルサイズが増加しま

すので用途のデータの特性を考慮して間隔を設定します。

（日中の業務時間帯 (9:00～18:00) の 1 分間隔のデータがあれば問題ないというケースもあります）

6. [次へ] をクリックします。



7. [このデータコレクターセットをすぐに開始する] を選択して、[完了] をクリックします。

8. [ユーザー定義] を選択して、作成したデータコレクターセットが [実行中] になっていることを確認します。

11.



12.
クエリエディタが開いたら、以下のクエリを入力してをクリックしてデータの読み込みを行います。

USE COD2012

GO

DBCC DROPCLEANBUFFERS

WAITFOR DELAY '00:00:05'

SELECT COUNT(*) FROM Ex01 WITH (INDEX=0)


DBCC DROPCLEANBUFFERS


SELECT COUNT(*) FROM Ex01 WITH (INDEX=0)

13. クエリの実行が終了したら、パフォーマンスモニターを開いて、[ユーザー定義] から作成したデータコレクターセッ
トを選択し右クリックして、[停止] をクリックし、ログの取得を停止します。

14.

15. [ログファイル] を選択して[追加] をクリックし、取得したログファイル (.blg) を選択します。
デフォルトでは [C:PerfLogsAdmin] の下の作成したデータコレクターセット名のディレクトリに取得されて
います。
選択が終了したら [OK] をクリックします。



Tips
パフォーマンスモニターは複数のログファイルを追加することも可能ですので、長期にわたってデータを取る場合は時間単位

/ 日単位等でログが取得できるように計画をするとファイルの転送や加工が楽になります。

また、取り込んだログから特定の時間のみを抽出するということも可能です。

16.
をクリックして、カウンターから以下のカウンターをを追加して、[OK] をクリックします。

 Database Cache Memory (KB)

 Free Memory (KB)

 Total Server Memory (KB)

17. ログに取得されているデータが表示されます。
ハイライトしたいカウンターがある場合はカウンターを選択して [Ctrl + H] を押すと選択したカウンターがハイライ



ト(黒の太線) 表示されます。再度 [Ctrl + H] を押すとハイライトが解除されます。

Tips
このグラフは SQL Server のデータで使用しているメモリ (Database Cache Memory) と空きになっているメモリ

(Free Memory) と SQL Server に割り当てられているメモリ (Total Server Memory) の関係を表したものになり

ます。

DBCC DROPCLEANBUFFERS を実行するとデータで使用しているメモリを空きメモリとします。そのため、このコマンドを

実行したタイミングで Free Memory が上昇し Database Cache Memory が減少します。

空きメモリとしたメモリは SQL Server 上では確保したメモリから解放は行っていないため、SQL Server で確保している

メモリ (Total Server Memory) には変化がないことが確認できます。

18. グラフが表示されている領域を右クリックして、[データの保存] をクリックして表示しているログをファイルに保存しま
す。



今回は [CSV] 形式で任意のファイル名、場所に保存を行います。

19. 保存したファイルをメモ帳で開き内容を確認します。

20. テキスト形式のファイルを使用することで Excel などでグラフ化することが可能です。



Tips
Excel にデータを読み込む場合、CSV をインポートする他に、TSV 形式でエクスポートをしたテキストをコピー & ペースト

で Excel に貼り付けることもできます。

タブ区切りのデータを貼り付けた場合、タブで区切っている各データが各セルに対応して貼り付けされます。




このハンズオンではパフォーマンスモニターをログとして取得しました。
パフォーマンスモニターは OS の標準機能ですので、インストールされている SQL Server のエディションに依存しないで
状態のログを取得することができます。
パフォーマンスモニターのツール以外でも加工ができるように CSV / TSV 形式でエクスポートすることができますので取得
したログをレポートの作成等に使用することができます。
パフォーマンスモニターは OS 標準の機能ですので使用している SQL Server のエディションに影響せずに使用すること
ができます。SQL Server 2008 以降の Enterprise Edition を使用していて、パフォーマンスデータコレクションの
設定が有効になっていない場合などにもすぐに状態をログとして取得することができますので、現状を取得し調査するため
の有効なツールとして利用することが可能です。



COD2012 T2/T3 : 実機で試す SQL Server の現状取得ハンズオンマニュアル

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to COD2012 T2/T3 : 実機で試す SQL Server の現状取得ハンズオンマニュアル

Similar to COD2012 T2/T3 : 実機で試す SQL Server の現状取得ハンズオンマニュアル (20)

More from Masayuki Ozawa

More from Masayuki Ozawa (18)