SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Archive for the ‘SQL Server’ Category

データ平準化の再構成時のファイルアクセス状況について

3 comments

さらに続きの投稿で。

データファイルを追加した際にファイルの再構成ではファイルの平準化はされませんでした。
この時の各ファイルの読み取り / 書き込みの状態を確認してみたいと思います。

データベースのファイルのアクセス状況を確認したい場合には、[sys.dm_io_virtual_file_stats] または、[fn_virtualfilestats]を使用します。
ここから情報を取得することでファイルのアクセス状況を取得することができます。
今回は、以下のクエリを実行して情報を取得してみました。

SELECT
    DB_NAME(database_id) AS [database_name],
    FILE_NAME(file_id) AS [file_name],
    num_of_bytes_read,
    num_of_bytes_written
FROM
    sys.dm_io_virtual_file_stats(DB_ID(N’TEST’), NULL)

image

それでは、インデックスの再構成を実行し、その後情報を再取得してみたいと思います。
image

再構成実行後、実行前の情報の差を出すことで、どのファイルに対してアクセスがされたかを確認することができます。

database_name file_name num_of_bytes_read num_of_bytes_written
TEST TEST 0 19,578,880
TEST TEST_log 0 55,043,072
TEST TEST2 0 0

num_of_bytes_written が [TEST] [TEST_log] にだけ発生しているのが確認できます。
インデックスの再構成は再構築とことなり、新規にデータを再構築するのではなく、既存のエクステント内でデータを再構成しますので、このような動きとなります。

それではこの状態から再構築をしてファイルのアクセスを確認したいと思います。
image

database_name file_name num_of_bytes_read num_of_bytes_written
TEST TEST 0 13,508,608
TEST TEST_log 0 25,758,720
TEST TEST2 0 8,151,040

 

再構築をした場合は、[TEST2] にも書き込みがされていることが確認できます。

データ平準化の動作は、ファイルのアクセス状況を取得することで確認することもできますので、簡単にではありますがまとめてみました。

Written by Masayuki.Ozawa

12月 2nd, 2010 at 10:58 pm

Posted in SQL Server

Tagged with

追加したデータファイルからデータを移動する方法

3 comments

先ほど投稿した内容の続きになります。

データファイルを追加してデータを平準化すると各ファイルの使用状況は以下のようになります。
image

何かの理由で、追加したデータファイルを削除する必要が発生し、削除をしようとすると以下のメッセージが表示され削除をすることができません。
image

DataFile ‘TEST2’ の削除に失敗しました。  (Microsoft.SqlServer.Smo)
Transact-SQL ステートメントまたはバッチの実行中に例外が発生しました。 (Microsoft.SqlServer.ConnectionInfo)
ファイル ‘TEST2’ は空ではないので、削除できません。 (Microsoft SQL Server、エラー: 5042)

メッセージに表示されているように、すでにデータが格納されているファイルは空ではありませんので削除をすることができません。

データを空にするためには、[EMPTYFILE] を指定してファイルを圧縮する必要があります。
SQL で実行する場合は以下のクエリを実行します。

USE [TEST]
GO
DBCC SHRINKFILE (N’TEST’ , EMPTYFILE)
GO

SSMS で圧縮をする場合は、ファイル単位の圧縮で [データを同じファイル グループの他のファイルに移行してファイルを空にする] を選択してファイルの圧縮を行います。
image

いずれかの操作をすることで対象のファイルから別のファイルにデータを移行することが可能です。

実行前の各ファイルの使用状況は以下のようになっています。
image

実行後は以下のようになります。
image
image

EMPTYFILE を指定してデータベースの圧縮をすると以下のような結果が表示されます。
image

UsedPages は 0 となっていますが、SHOW FILESTATS の結果では 1 エクステントが使われています。
# 管理用のページが残っているからだからだと思いますが。

この状態でデータを追加してみます。
image

EMPTYFILE により圧縮をしたファイルにはデータが格納されていません。

以下は BOL に記載されている内容です。

指定したファイルから、同じファイル グループ内の他のファイルにすべてのデータを移動します。データベース エンジンではデータを空のファイルに配置できなくなったので、ファイルを削除するには、ALTER DATABASE ステートメントを使用します。

圧縮により空にしたファイルにはデータの配置ができなくなりますので、データを追加しても使用されなくなります。
# ページヘッダ と sys.database_files を確認してみたのですが違いがいまいちわかりませんでした…。

空にしたファイルは削除することが可能となります。
image

SSMS から見るとファイルが削除されているのですが、[sys.database_files] を確認すると実はファイルが削除されていません。
image
削除しただけでは、[OFFLINE] の状態でエントリとしては残った状態となっています。

SSMS のファイルの表示は [state] が [0] (ONLINE) または [2] (RECOVERING) のファイルが表示されるようになっています。
# 実際には sys.database_files ではなく、sys.master_files から取得しています。

そのため、SSMS では表示はされないがエントリとしては残った状態となります。

エントリが残った状態で同じ名前 (TEST2) でファイルを追加してみます。

データベース ‘TEST’ のAlterに失敗しました。  (Microsoft.SqlServer.Smo)

Transact-SQL ステートメントまたはバッチの実行中に例外が発生しました。 (Microsoft.SqlServer.ConnectionInfo)

次回の BACKUP LOG 操作が終了するまで、ファイル ‘F:DataTEST2.ndf’ を再利用できません。
次回の BACKUP LOG 操作が終了するまで、ファイル ‘TEST2’ を再利用できません。 (Microsoft SQL Server、エラー: 1833)

メッセージに表示されている通りなのですが、トランザクションログのバックアップをしないとエントリが削除されないためエラーが発生しています。
エントリが存在している状態では、[is_name_reserved] が [1] となっています。
image

BOL には以下のように記載されています。

1 = 削除されたファイル名を再使用できます。新しいファイル名に対して名前 (name または physical_name) を再使用するには、ログのバックアップを実行する必要があります。

0 = ファイル名は再使用できません。

[is_name_reserved] が [1] の状態について明記がされていますね。

それではトランザクションログのバックアップを取って再度確認をしてみたいと思います。
image

トランザクションログのバックアップを取得することでファイルのエントリが削除されていることが確認できます。

ファイルの削除をする際にはトランザクションログのバックアップをして [sys.database_files] または、[sys.master_files] からエントリが削除されるところまでを確認しておいた方が良いかもしれないですね。

Written by Masayuki.Ozawa

12月 2nd, 2010 at 10:26 pm

Posted in SQL Server

Tagged with

ファイルグループにファイル追加後のデータ平準化

one comment

Twitter でご質問をいただきましたので軽くまとめて見たいと思います。

SQL Server のファイルグループは一つ以上のデータファイルで構成がされます。
image

ファイルグループはデータファイルの集合を管理する論理単位のため、SQL Server 上にデータとして情報が存在するだけですが、データファイルは実際のファイルになりますので、ディスク上にファイルが存在することになります。
image

データベースのデータはファイルグループと関連付けますので、データも絵に含めると以下のような形になります。
image

 

テーブルの件数が増加し、ディスクのサイズが枯渇 / ディスク負荷低減のため、ファイルグループに新規にデータファイル (ndf) を追加することがあります。
image

テーブルはファイルグループに関連づいていますので、そのファイルグループにデータファイルが追加されれば、使用できる領域が増えることになり、ディスクサイズの枯渇に関しては対応ができます。

ディスク負荷低減についてはどのようになるかを考えてみます。
ディスク追加後の各ファイルのデータの充填状況は以下のようになっています。
# 赤が使用領域となります。
image

追加したデータファイルにはデータは格納されていませんので、読み取りは今まで存在したデータファイルに、書き込みは新規に追加したデータファイルに集中することになります。
# 読み取りはデータが格納されているファイル / 書き込みは空きページの多いファイルに対して行われますので。

通常、同一のファイルグループにデータファイルを追加する場合は別のディスクにしますので、データの充填率は以下のようになっているとディスク I/O が分散されることになります。
image

データファイル追加後は上記の図のようにデータファイル内のデータは各ファイルに平準化して格納されていません。
平準化をするためにはデータ領域を再構築してデータを均等に配置する必要があります。

それでは、各状態を SQL Server で実際に確認をしてみたいと思います。

■初期状態

今回は [TEST] というデータベースを作成しています。
image

このデータベースですが単一のデータファイルで構成されています。
テスト用のテーブルを作成して、データを入れてありますので現在のファイルの使用状況を確認してみたいと思います。
ファイルの使用状況を確認するためには [DBCC SHOWFILESTATS] を使用します。
この DBCC コマンドを実行することで、現在のデータベースのファイル使用状況を取得することができます。
image

ファイルの使用状況はエクステントで表示されます。
[TEST.mdf] は [1,600] エクステント (1,600 × 64 KB = 102,400 KB = 100 MB) 割り当てられ、そのうち [339] エクステント (339 × 64 KB = 21,696 KB = 21 MB)  が使用されていることが確認できます。

■ファイル追加後のデータ充填状況

それではファイルグループにデータファイルを追加して、データの充填状況を確認してみたいと思います。
# ドライブ構成の関係で既存のファイルと同じドライブに格納してしまっています…。
image

今回は [TEST2.ndf] というファイルを追加しています。

それではデータファイル追加後の使用状況を取得してデータの充填状況を確認してみたいと思います。
image

新規に吹ファイルが追加 (Fileid = 3) され、UsedExtents が [1] (管理用ページを作成する必要があるため) となっています。
データファイルを追加後はこのような状態となります。
image

 

■データを平準化する

データを平準化するためにはどうすればいいかというと、データ領域の再構築を行います。
# ヒープの場合は別の機会に考えて見たいと思います…。
再構築はインデックスの再構築をすれば実施できますので、インデックスの [REBUILD] を行います。

インデックスの再構築では、エクステントも含めてデータを再配置し直しますので、データが各ファイルに均等に再配置されます。

インデックスの再構成 (REORGANIZE) では、エクステントの再割り当てはせずに既に存在しているエクステント内でページの並び替えを行いますのでデータは平準化されません。

それでは、実際に確認をしてみたいと思います。

まずはインデックスを再構成してみます。
# GUID をキーにしてテスト用のデータを生成しているので断片化が著しいです…。
image

再構成後のデータ充填率を取得すると各ファイルにデータが分散していないことが確認できます。
image

それでは、再構成 (REORGANIZE) ではなく 再構築 (REBUILD) を行ってみます。
image

完全に平準化 (199 ページずつ) とはいきませんでしたが今まで UsedExtents が 1 となっていた TEST2.ndf のエクステントが利用されていることが確認できます。
image

データファイルの追加後にデータ領域を再構築することで、既に格納されているデータについて使用するファイルを平準化することができます。

 

■ファイルサイズの差によるデータファイルの使用状況

データファイルのサイズを変更して、

  • TEST.mdf : 100 MB
  • TEST2.ndf : 1 MB

にしてみました。
# 自動拡張は有効です。
image

この状態でデータを挿入するとどうなるか試してみます。
image

TEST2.ndf は 1 MB のサイズに変更しましたので 16 × 64 KB = 1,024 MB と割り当てていたサイズはすべて使用されていますが、自動拡張はせずに残りのデータは TEST.mdf に格納がされています。
データ格納時は空きページを考慮してデータを格納していきますので空きがある TEST.mdf が使用されたことになります。

これは極端な例ですので、

  • TEST.mdf : 100 MB
  • TEST2.ndf : 20 MB

として、
image

両方のファイルで分散させたデータが格納できる状態にしてデータを挿入してみます。
image

この場合は両ファイルに十分な空き領域がありますので、両方のファイルが均等と言っていいレベルで使用されています。

 

使用されるファイルは空き領域 (ページ) が考慮されて使われますので、均等にデータを書き込んだ結果片一方の空きページに余裕が無くなってしまうと思ったようにディスク利用が分散されない可能性があります。

使用領域を増やすのではなく、ディスクのアクセス効率を向上するためにファイルを追加した場合は追加後に各ファイルでデータを平準化するかを考慮し、作業 / 確認をした方がよいかもしれないですね。

Written by Masayuki.Ozawa

12月 2nd, 2010 at 6:38 pm

Posted in SQL Server

Tagged with

Tech・Ed Europe 2010 の Denali が関連するセッション

leave a comment

Tech・Ed Europe 2010 のセッション資料が Tech・Ed Online で公開されています。
Tech・Ed Online

Denali リリース後に開催された (といっても本当に直ぐ後ですが) Tech・Ed となり、Denali に関連するセッションがいくつかあったようです。

気づいた範囲になりますが Denali が含まれるセッションをまとめてみました。
# 一文は入っているだけのセッションもありますが。

BIN204:Offering PowerPivot as a Service – Best Practices from Microsoft IT
BIN206:A-to-Z of Master Data Services in Microsoft SQL Server 2008 R2
BIN308:Finally: Data Lineage in Business Intelligence Projects with SQL Server Metadata Toolkit 2008
BIN310:Analysis with Microsoft PowerPivot
DAT222:Microsoft SQL Server Code Name "Denali" Overview
DAT303:SQL Server “Denali” High Availability:The next generation high availability solution
DAT342:SQL Server Performance Series – Part 3 – Query and Index Tuning
# DAT340~342 は Perfomance Series になっており Denali ではありませんがおすすめのセッションです。

DAT222 / DAT303 は Denali とセッション名についているようにフォーカスして情報が公開されています。
# DAT222 は PPTX の提供がないので動画を途中までしか見て入れませんが。

Tech・Ed Europe 2010 のセッション資料のダウンロード先やセッション一覧は以下の URL にテキストベースにはなりますが、簡単にまとめたファイルを作ってみましたので、興味のある方はご利用いただければと思います。
Tech Ed 2010 Europe

Written by Masayuki.Ozawa

12月 1st, 2010 at 11:07 pm

Posted in SQL Server,セミナー

Tagged with ,

あらためて SQL Server と /3GB スイッチ

leave a comment

最近は 64 ビット (x64) の OS を使う機会の方が多いと思いますが、あらためて 32 ビット (x86) の SQL Server のメモリチューニングについてまとめていきたいと思います。

今回は

  • Windows Server 2008 Datacenter Edition x86 SP2
  • SQL Server 2008 R2 Enterprise Evaluation x86
  • SQL Server Code Name ‘Denali’ Enterprise Evaluation x86
  • 4 CPU
  • 6GB Memory

の環境を使用しています。

■仮想アドレス空間の確認

32 ビット の SQL Server の場合、ユーザーモードの仮想アドレス空間 (VAS : Virtual Address Space) の最大サイズは通常 [2GB] となります。
image
SQL Server のユーザーモードの VAS ですが、SQL を実行して確認をするためには二種類の方法があります。

  1. DBCC MEMORYSTATUS を実行
  2. sys.dm_os_memory_nodes を参照

この 2 種類の方法で VAS の状態を確認することが可能です。

DBCC MEMORY STATUS については技術情報が提供されています。
DBCC MEMORYSTATUS コマンドを使用して SQL Server 2005 のメモリ使用量を監視する方法

sys.dm_os_memory_nodes に関しては BOL に情報が記載されています。
sys.dm_os_memory_nodes (Transact-SQL)

これらを使用することで SQL Server の VAS の情報を確認することができます。

DBCC MEMORYSTATUS  を実行するとこのような情報が取得できます。

Memory Manager                           KB
—————————————- ———–
VM Reserved                              1114756
VM Committed                             1048580
AWE Allocated                            0
Large Pages Allocated                    0
Emergency Memory                         1024
Emergency Memory In Use                  16
Target Committed                         1048576
Current Committed                        1048576
Pages Allocated                          1019480
Pages Reserved                           0
Pages Free                               2672
Pages In Use                             105968
Page Alloc Potential                     890176
NUMA Growth Phase                        2
Last OOM Factor                          0
Last OS Error                            0

sys.dm_os_memory_nodes ではこのような情報が取得できます。

memory_node_id virtual_address_space_reserved_kb virtual_address_space_committed_kb
————– ——————————— ———————————-
0              1114692                           1048568                           
32             0                                 12                                

locked_page_allocations_kb pages_kb             shared_memory_reserved_kb
————————– ——————– ————————-
0                          1019480              0                        
0                          1019480              0                        

shared_memory_committed_kb cpu_affinity_mask    online_scheduler_mask
————————– ——————– ———————
0                          15                   15                   
0                          15                   15                   

processor_group foreign_committed_kb
————— ——————–
0               0
0               0

どちらのコマンドを実行しても VAS の情報を確認可能です。
DBCC MEMORYSTATUS で取得できる情報は、[sys.dm_os_memory_nodes] [sys.dm_os_memory_clerks] [sys.dm_os_memory_objects] [sys.dm_os_memory_cache_counters] [sys.dm_os_memory_pools] から取得することも可能です。

これらの情報を取得することで、[reserved][committed] の2 種類を確認することができます。
[reserved] (予約) は仮想メモリの領域を予約しているが実際には物理メモリを割り当てていない状態、 [committed] (確定) は物理メモリを割り当てている状態になります。

■max server memory の設定

SQL Server では [max server memory] を設定することでメモリの上限を設定することができますが、この設定をすることで、[reserved] とするサイズの上限を制限することが可能です。

今回は 32 ビット版の SQL Server を使用しているのですが、1.6GB 程度 VAS が確保できています。
# 大量のデータを検索して SQL Server のメモリを使用させた状態です。
image

この情報は以下のクエリを実行して取得しています。

SELECT
    [virtual_address_space_reserved_kb] / 1024 AS [VAS Reserved (MB)],
    [virtual_address_space_committed_kb] / 1024 AS [VAS Committed (MB)]
FROM
    [sys].[dm_os_memory_nodes]
WHERE
    [memory_node_id] = 0

初期設定の状態なので max server memory は [2147483647] が設定されているので、使用できる上限まで SQL Server はメモリを確保します。

それでは、max server memory を [1024] に設定して VAS の状態を確認してみたいと思います。
image

max server memory を設定することで、[Committed] のサイズが変更されていることが確認できます。
今回は設定変更後はサービスを再起動していないため、[Reserved] に関しては 1024 MB 以上の値となっています。
このことから max server memory は [Reserved] ではなく [Committed] 状態のメモリのサイズを制御していることが確認できます。

サービスの再起動をして、Reserved を解放し再度メモリの割り当てを確認してみます。

起動直後の VAS の状態は以下のようになっています。
SQL Server は通常の設定では max server memory を設定しても、起動直後は最小限のメモリのみ [Reserved] [Committed] で確保を行います。
image

サービスを再起動すると最小限の [Reserved] [Committed] から開始されますので、[Reserved] の確保も抑えられた状態となります。
# [Committed] が [1024 MB] で上限となるので、[Reserved] の確保も抑えらえた状態となります。
image

 

■/3GB スイッチによる VAS 上限の変更

今回の環境ではメモリを 6GB 割り当てているのですが、32 ビット OS の制限でユーザーモードの VAS の上限は 2GB となっています。
以下は SQL Server のメモリ割り当て (Memory ManagerTotal Server Memory (KB)) とサーバーの空きメモリ (MemoryAvailable MBytes) の関係をグラフ化したものになります。

image

サーバーの空きメモリはあるのですが、SQL Server で使用しているメモリについては VAS の上限に達してから頭打ちになっているのが確認できます。

この状態が 32 ビット版の SQL Server の通常設定時の限界となります。
空きメモリがあるにも関わらず、32 ビット OS の制限でメモリを最大限使用できない状態となっています。

32 ビット OS では [/3GB] オプションを設定することで、ユーザーモードのVAS の上限値を 2GB → 3GB に変更することが可能となります。
# [/3GB スイッチ] [4GB チューニング] と呼ばれる設定になります。

Windows Server 2003 向けなりますが以下の技術情報が公開されています。
/userva スイッチと /3GB スイッチを使用してユーザー モード領域を 2 ~ 3 GB の間でチューニングする方法
4 GB RAM チューニング機能と物理アドレス拡張のスイッチの説明

Windows Server 2008 以降は boot.ini ではなく、BCD が使用されていますので bcdedit を使用して設定を行う必要があります。

[/3GB] スイッチは、[increaseuserva 3072] で設定することが可能です。

bcdedit /set {current} increaseuserva 3072

上記コマンドをコマンドプロンプトで実行することでユーザーモードの VAS を3GB まで使用することが可能となります。
# 代わりにカーネルモードが 1GB に制限されますが。
image

設定を削除する場合は以下のコマンドを実行します。

bcdedit /deletevalue {current} increaseuserva

 

設定をしたら一度サーバーを再起動して、SQL Server のメモリの使用状況を確認してみます。
image
image

 

設定をすることで設定前と比較して 1GB 程メモリの割り当てが増えていることが確認できます。

この設定をすることで 2GB 以上のメモリを使用することが可能となりますが、サーバーの空きメモリはまだ残っておりメモリを最大限活用できていない状態となっています。

これ以上のメモリを使用するためには AWE (Address Windowing Extensions) を有効にする必要があります。
AWE については次の投稿でまとめたいと思います。

Written by Masayuki.Ozawa

11月 28th, 2010 at 7:55 pm

Posted in SQL Server

Tagged with ,

SSMS で大量の結果を返すクエリを実行する際の注意点

leave a comment

AWE と PAE のテストをしようと思って、大量のデータを作成して SSMS (SQL Server Management Studio) で SELECT 文を実行してキャッシュに載せる検証をしていました。

SELECT 文を実行してみたところ以下のようなエラーが。
image

C ドライブの空き容量を確認したところ、[0 バイト] との表示が…。
image

C ドライブに tempdb を格納しているのですが、今回はソートをしていないのでサイズも増えていないのですよね。
image

ディレクトリのサイズを確認していたら、SSMS を実行しているユーザーの TEMP ディレクトリのサイズが肥大化していました。
image

Temp ディレクトリに一つ大きなファイルが作成されていました。
image

Process Explorer で確認をすると SSMS がつかんでいるファイルのようでした。
image

このファイルですが、大量のデータを返すクエリを実行していたクエリウィンドウを閉じたところ削除がされました。
今まであまり意識していなかったのですが、SSMS で [グリッド形式] で結果を表示するようにすると一時ファイルが作成されるようですね。
10 件程度の結果を返す軽いクエリでもファイルが作成されていました。
image
image

[テキスト形式] で結果を返すようにするとファイルは作成されませんでした。
image

 

急に C ドライブの容量が減ってびっくりしたのですが、SSMS が一時ファイルを作っていることが分かったので勉強になりました。

Written by Masayuki.Ozawa

11月 27th, 2010 at 10:41 pm

Posted in SQL Server

Tagged with

Denali の HADR のフェールオーバーについて

leave a comment

Denali の HADR の構築はできましたので、今回はフェールオーバーについてまとめてみたいと思います。

■HADR 用のクラスターグループについて

HADR は WSFC が必須の構成となります。
HADR を構築するとクラスターグループとして Availability Group として設定したグループ名が作成されます。
image

このクラスターグループにはリソースが一つ含まれています。
image
このリソースですが、[SQL Server Availability Group] というリソースで作成されています。
image

リソースの所有者が [Primary] として設定されているサーバーになるようですね。

このグループですが、WSFC の管理コンソールからはグループを移動させることはできないようになっているようです。
image

 

■SSMS で Primary サーバーを切り替え

WSFC のグループは WSFC の管理コンソールからは切り替えることができません。
Primary サーバーを切り替える (フェールオーバーさせる) 場合は、SSMS から操作をする必要があります。

Primary サーバーの切り替えですが、現在 [Primary] サーバーとなっているサーバーの接続からは変更することができません。

  • DENALI-01 : Primary
  • DENALI-02 : Secondary

となっている場合、DELALI-01 の接続では、サーバーの切り替えをするためのメニューは表示されません。
image
image

DENALI-02 に接続し、Secondary で右クリックをするとメニューが少し変わります。
image
image

SSMS で Secondary のサーバーに接続をして、Secondary のサーバーを右クリックすると [Force Failover] が表示されます。
[Force Failover] を使用することで Primary と Secondary を切り替えることができます。

CTP1 の Release Notes には以下の記載があります。

The SQL Server Code-Named “Denali” CTP1 release of "HADR" is a preview and does not support the following features:

  • Synchronous data movement (synchronous-commit availability mode).

  • Manual failover and automatic failover.

    The only supported form is forced failover, which allows data loss and suspends the secondary databases.

  • Log compression.

  • Automatic page repair.

  • The ALTER AVAILABILITY GROUP Transact-SQL statement does not support changing the configuration of the availability group such as changing read-only access to an availability replica, adding or removing an availability database, and adding or removing a secondary availability replica. For information about what this Transact-SQL statement supports, see ALTER AVAILABILITY GROUP (Transact-SQL) in Books Online.

 

現状は マニュアル / 自動フェールオーバーは実装されていないようです。
そのため、Primary / Secondary を切り替えるためには強制フェールオーバーをする必要があります。
# Primary のサービスを停止しても Secondary には切り替わりません。

それでは、[Force Failover] を実行して Primary と Secondary を切り替えてみたいと思います。
DEHALI-02 に接続し、[HADR Group] → [Availability Replicas] を展開して、[DENALI-02] を右クリックし、[Force Failover] をクリックします。
# Secondary の接続でないと [Force Failover] が表示されません。

image

[OK] をクリックして、フェールオーバーを実施します。
image

image

H
ADR の強制フェールオーバーは以上で完了です。

強制フェールオーバー前は以下の状態となっていました。
image

[DENALI-01]
image

[DENALI-02]
image

 

強制フェールオーバーを実施すると以下の状態となります。
image
強制フェールオーバー前は [Primary] であった、[DENALI-01] が [Secondary] になっているのが確認できます。
強制フェールオーバーを実施した影響だと思うのですが、[Synchronization State] が [Synchronized] から [Not Synchronizing] に変わっています。

データベースの状態も [Online] から [Suspended] に変わっています。

[DENALI-01]
image

[DENALI-02]
image

強制フェールオーバーを実施した場合は、自動で [Online] にはならないため手動で HADR による同期を再開する必要があります。

 

同期を再開するためには、[Secondary] に接続をして [Resume Data Movement] を実行する必要があります。
image

[OK] をクリックして、HADR によるデータ同期を再開します。
image

Resume をすることでデータ同期が再開されます。
image

image

 

自動フェールオーバーや自動ページ修復が実装されるとミラーリングと変わらない利用が出来そうなので期待大ですね。

次の CTP で検証できるようになっているとうれしいですね~。

Written by Masayuki.Ozawa

11月 20th, 2010 at 9:54 pm

Posted in SQL Server

Tagged with ,

Denali で HADR 環境を構築

leave a comment

Denali では高可用性の構成として、

  • レプリケーション
    トランザクションログをディストリビュータに配信し、その内容をサブスクライバに適用することでデータの同期を行います。
    image
    # ディストリビュータはパブリッシャと兼用する場合が多いかもしれないですね。
  • ログ配布
    トランザクションログのバックアップを共有ディレクトリに取得し、配布先で取得されたログバックアップをリストアすることでデータの同期を行います。
    image
  • ミラーリング
    プリンシパル / ミラー間でミラーリング用のエンドポイント (接続点) を介してデータの同期を行います。
    ウイットネスサーバーを用意することで障害発生時にプリンシパルとミラーを切り替えることが可能です。
    image
  • クラスタリング
    共有ディスクにデータベースを配置し、SQL Server のサービスはどちらかのノードで実行する構成になります。
    データベースは共有ディスク一か所なのでデータの同期は行われません。
    image

 

のほかに、HADR (high-availability and disaster recovery) という構成が追加されています。
"HADR" Overview (SQL Server)
SQL Server Code-Named "Denali" CTP1 Release Notes の[3.7 High Availability and Disaster Recovery ("HADR")] にも情報が記載されています。

HADR は共有ディスクを使用しないで SQL Server の高可用性環境を作成できる構成になります。
image

特徴としてはプライマリとセカンダリのサーバーだけで同期をとることができ、サーバー間のデータ同期にはミラーリングと同様にエンドポイントが使用されている点になります。
パッと見はレプリケーションと変わらなそうですが、HADR はデータベース全体を同期の対象とすることが可能です。
# レプリケーションは同期をとるテーブルを選択する必要があったはずです。
レプリケーションは SQL Server Agent は使用してデータの同期が行われますが HADR では SQL Server Agent は不要です。
また、セカンダリデータベースは常に読み取りデータベースとして使用することができるように設定が可能です。

クライアントからの接続はミラーリングと同じような設定ができるようなのですがここはまだ検証ができていません。
"HADR" Overview (SQL Server) に[Client Connections] にこのあたりの記載がされています。
Connecting Clients to a Database Mirroring Session (SQL Server) へのリンクがあるので、ミラーリングと同じように Server / Failover_Partner を使用して自動的なフェールオーバーはできそうなのですが。

CTP1 では

This CTP supports only a single, asynchronous secondary replica.

となっているため、シングルのセカンダリ環境となります。
# GUI 上は複数サーバー設定できそうなのですが、具体的に何サーバー設定できるかが記載されているドキュメントが見つかっていないのですよね…。

HADR はクラスタリングの技術が使用されているため、WSFC が必須となります。
image
HADR で必要となる要件に関してはこちらの技術情報に記載がされています。
"HADR" Prerequisites and Restrictions
前提となるデータベースの設定条件に関してもこちらの技術情報に記載がされています。

ただし、SQL Server のインスタンスに関してはクラスタインスタンスとする必要はなくローカルインスタンス間でデータの同期を行うことが可能です。

この HADR の構築方法をまとめてみたいと思います。

今回の環境は前回の投稿で作成したクラスタ環境に、ローカルの既定のインスタンスを作成した環境で実施しています。
また、SQL Server のサービスアカウントはドメインユーザーを指定しています。

両サーバーでローカルアカウントを使用して、ミラーアカウントを作成、エンドポイントで証明書を使用する等を行えばドメインユーザーでなくてもデータ連携ができるかもしれませんが今回は簡単な構築の検証のためドメインユーザーを使用しています。
# WSFC なのでドメイン参加は必須ですのでドメインユーザーを使用するのはそれほど敷居が高くないと思います。

 

■HADR の有効化

 

最初の作業として HADR を使用するインスタンスで、HADR を有効化する必要があります。
HADR の有効化は [SQL Server Configuration Manager] から行います。

image

 

Configuration Manager で対象のインスタンスの SQL Server サービスのプロパティを開くと、[SQL HADR] というタブが表示されます。
このタブの [Enable SQL HADR service] を有効にすることで、対象のインスタンスで HADR を使用することが可能になります。
image
[Enable SQL HADR service] を両サーバーのインスタンスで有効にして、サービスを再起動します。
image

 

TCP/IP 接続の有効化

Denali CTP1 の初期状態では、[Shared Memory] のみが有効になった状態になっています。
image
HADR では TCP/IP でインスタンス間を接続する必要がありますので、TCP/IP を有効にしておきます。
# データの同期はエンドポイントを介して行われますが HADR 設定時に TCP/IP でインスタンスに接続ができる必要があります。
image
image
設定を有効にするため、SQL Server のサービスを再起動します。

 

■ファイアウォールの設定

 

HADR はインスタンス間の接続と、エンドポイントの接続ができる必要がありますので、必要となるポートを許可するファイアウォールのルールを設定します。

今回は既定のインスタンスを使用していますので、インスタンス間の接続は [TCP 1433] が必要になります。
エンドポイントでは既定ではミラーリングと同じ [TCP 5022] が使用されますので、この 2 種類のポートを許可するルールを作成します。

netsh advfirewall firewall add rule name="HADR" dir=in protocol=TCP localport=1433,5022 action=allow

 

■HADR の設定

HADR の設定は SQL Server Management Studio (SSMS) から実施します。
image

今回は、HADR_TEST というデータベースを使用て HADR を設定してみたいと思います。
# 復旧モデルは [完全] に設定しておく必要があります。
image

最初の作業としては [Availability Group]  を作成します。
HADR はこのグループに属しているデータベースの冗長化を行います。

  1. [Management] から、[Availability Groups] を右クリックして、[New Availability Group] をクリックします。
    image
  2. [Next] をクリックします。
    image
  3. Availability Group の名称を入力して、[Next] をクリックします。
    image
  4. HADR で冗長化を行うデータベースを選択する画面が表示されるのですが、データベースを作成した直後の状態だと以下のように対象のデータベースとして選択することができません。
    image
    [Show user databases not meeting requirements.] を有効にすると理由が表示されます。
    image
    HADR を構成するためには、バックアップを取得しておく必要があります。
    一度もバックアップを取得したことがないデータベースは HADR の対象とすることができません。

    バックアップを取得していると HADR の対象とすることができます。
    対象のデータベースを選択して、[Next] をクリックします。
    image

  5. HADR に含める SQL Server のインスタンスを設定します。
    デフォルトでは、HADR を設定しようとしたインスタンスが Primary に設定されています。
    image
    [Add] をクリックしてインスタンスの追加を行います。
    インスタンスの接続ダイアログが表示されますので HADR に含めるインスタンスに接続を行います。
    image
  6. インスタンスに接続をすると HADR の対象として追加がされます。
    image
    初期の状態では、[Read Mode in Secondary Role] は [Disallow Connections] となっています。
    今回は、Secondary は読み取り専用として使用したいため、[Allow All Connections] に設定を行います。
    image
    この設定ですが以下の技術情報の [Read-only Access Behavior] に記載があります。
    Read-Only Access to Secondary Availability Replicas
    READ_CONNECTIONS_ONLY と ALL_CONNECTIONS の違いはこれから勉強しないといけないなと思っています…。
  7. [Endpoints] に関しては自動で作成がされます。
    [Next] をクリックして次の画面に遷移します。
    image
  8. [Finish] をクリックして、Availability Group を作成します。
    [Script] をクリックすることで、Availability Group の設定を行うためのスクリプトを作成することも可能です。
    image
  9. [Start Data Synchronization] をクリックして Secondaly サーバーとデータの初期同期を行います。
    image
  10. データの初期同期ですが、バックアップ / リストアを使用して行われます。
    image
    バックアップ/リストアは共有ディレクトリ経由で行われますので、共有ディレクトリを作成する必要があります。
    今回は、[Share] という [Everyone:フルコントロール] の共有を作成しています。
    image
    注意点としては、Secondary のサーバーにデータベースが存在しているとバックアップ / リストアが実施できない点になります。
    Secondary 側にデータベースが存在していると以下のようなエラーになります。
    image
    正常に同期が完了すると以下の画面になります。
    image
  11. [Close] をクリックして完了します。
    image

以上で HADR の設定は完了です。
今回は SSMS で GUI を使って実行しましたが、クエリベースで実行する場合は以下の技術情報が参考になります。
Example: Setting Up an Availability Group Using Windows Authentication (Transact-SQL)

[Availability Groups] の下に設定が追加されていることが確認できます。
image
設定ついては [Object Explorer Details] からも確認をすることができます。
image
image

HADR の設定は特に難しい箇所はなく設定が出来ると思います。
現状は非同期の更新となっていますが、技術情報で以下のように記載されているように、かなり短い間隔で同期はされているように思えます。

Asynchronous-commit mode enables the primary replica to run with minimum transaction latency

 

細かな使い方に関しては別の投稿でまとめていきたいと思います。

Written by Masayuki.Ozawa

11月 13th, 2010 at 10:33 pm

Posted in SQL Server

Tagged with ,

Denali で 2 ノードクラスターを構築

leave a comment

Denali で 2 ノードクラスターを構築する手順をまとめてみたいと思います。

WSFC は構築をしてあり、MSDTC のリソースは作成済みです。
image

■1 ノード目のインストール

事前準備は終わっていますのでセットアップを起動してクラスターのインストールを行います。
Denali のクラスターのインストールは一台ずつ実施をします。
まずは最初のノードのインストールから。

  1. セットアップを起動すると .NET Framework 3.5 のインストールを確認されますので、[OK] をクリックしてインストールを行います。
    # .NET Framework 4.0 も合わせてインストールがされるようです。
    image
  2. [Installation] から [New SQL Server failover Cluster installation] をクリックします。
    image
  3. [OK] をクリックします。
    image
  4. [Next] をクリックします。
    CTP1 では、Enterprise Evaluation を使用してクラスターを構築します。
    image
  5. [I accept the license terms.] を有効にして、[Next] をクリックします。
    image
  6. [Install] をクリックします。
    image
  7. セットアップルールの検証が開始されます。問題が無ければ [Next] をクリックします。
    以下の画面では、[Microsoft Cluster Serivce (MSCS) Cluste rverification warnings] が発生しています。
    この警告ですが、WSFC のクラスタの検証レポートで警告が発生していたために発生しています。
    image
    image

    私がインストールする場合、インストール時にログオンしているドメインアカウントには最低限の権限 (Domain Users) しか与えていないので、コンピューターアカウントの作成に関してのチェックで警告となります。
    image
    インストール時にログオンしているユーザーにはコンピューターアカウント作成のための権限は委任していませんが、初期状態の 10 台までの作成で対応ができますので、警告は無視ししています。

    クラスターの検証レポートが以下の状態であれば、SQL Server のインストール検証では警告は発生しません。
    image

    また、SQL Server で使用するディスクに関してもインストーラーを実行するノードに移動をしておきます。
    image
    [使用可能記憶域] に属している状態ではインストールには使えませんので注意が必要です。
    image
    インストーラーを実行しているノードで使用可能な共有ディスクがない場合はエラーになります。
    image
    image

  8. インストールする機能を選択し、[Next] をクリックします。
    今回は、SQL Server のデータベースエンジン関連に必要な最低限の機能をインストールしています。
    image
  9. インスタンスの情報を入力して、[Next] をクリックします。
    今回は名前付きインスタンスを使用しています。
    image
  10. [Next] をクリックします。
    image
  11. SQL Server クラスターのグループ名を設定し、[Next] をクリックします。
    グループ名はコンボボックスになっているのでグループ名を変更することが可能です。
    image
    共有ディスクが [使用可能記憶域] に属している場合は、[Next] をクリックすることができませんので一度ほかのグループに移動をしておく必要があります。
    image
  12. チェックボックスで使用するディスクを選択し、[Next] をクリックします。
    image
  13. ネットワークを設定して [Next] をクリックします。
    今回は、DHCP のままでインストールをしてみたいと思います。
    image
  14. クラスターで使用するセキュリティ設定を選択して、[Next] をクリックします。
    今回は、[User service SIDs] を選択しています。
    image
  15. サービスアカウントと照合順序を設定して、[Next] をクリックします。
    image
    image
  16. セキュリティ設定、データディレクトリ、FILESTREAM の設定をして、[Next] をクリックします。
    image
    image
    image
  17. エラー報告をして [Next] をクリックします。
    image
  18. [Next] をクリックします。
    image
  19. [Install] をクリックしてインストールを開始します。
    image
    image
  20. [Close] をクリックしてインストールを完了します。
    image

これで 1 ノード目のインストールは完了です。

 

■2 ノード目のインストール

 

続いて 2 ノード目のインストールを行います。

  1. 2 ノード目でセットアップを実行します。
  2. [OK] をクリックします。
    image
  3. [Installation] から、[Add node to a SQL Server failover cluster] をクリックします。
    image
  4. [OK] をクリックします。
    image
  5. [Next] をクリックします。
    image
  6. [I accept the license terms.] を有効にして、[Next] をクリックします。
    image
  7. [Install] をクリックします。
    image
  8. [Next] をクリックします。
    image
  9. ノードを追加するインスタンスを選択して、[Next] をクリックします。
    image
  10. [Next] をクリックします。
    image
  11. サービスアカウントのパスワードを入力して、[Next] をクリックします。
    image
  12. [Next] をクリックします。
    image
  13. [Next] をクリックします。
    image
  14. [Install] をクリックして、インストールを開始します。
    image
    image
  15. [Close] をクリックしてインストールを完了します。
    image

以上でクラスターのインストールは完了です。

image

クラスターインスタンスのインストールは今までのバージョンと変わらないですね。

Denali では高可用性構成として [HADR] という構成があります。

この構成に関しては次の投稿でまとめてみたいと思います。

Written by Masayuki.Ozawa

11月 13th, 2010 at 1:39 pm

Posted in SQL Server

Tagged with ,

SQL Live Monitor と PAL Tool を使用したモニタリングとレポーティング

leave a comment

今日は、CodePlex で提供されている [SQL Live Monitor] と [Performance Analysis of Logs (PAL) Tool] を使用した、SQL Server のモニタリングとレポーティングについてまとめてみたいと思います。

■SQL Live Monitor

SQL Live Monitor を使用すると、SQL Server の現状の稼働状況を確認することができます。
image
[SQL Server] の欄に情報を取得する SQL Server 名 (既定のインスタンスの場合はサーバー名、名前付きインスタンスの場合はサーバー名インスタンス名) を入力して、[Start] をクリックすることで情報が取得できます。

パフォーマンスチューニングをするにあたって、いくつかの項目は手動で情報を取得する必要がありますが現状の状態を把握するのにはとても便利なツールだと思います。
データキャッシュ / プロシージャキャッシュのメモリ使用状況は Page Life Expectancy といった定番の情報をリアルタイムに見やすく確認することが可能です。
Cache Hit Ratio 系は SQL Server のサービスが最後に起動してからの情報なのであまり参考にならない可能性がありますが…。
矢印でデータの流れがわかるようになっており、[>->->] であれば、左の項目から右の項目に、[<-<-<-] であれば右の項目から左の項目に対してデータが流れていることになります。

たとえば、[Checkpoints/Sec] ですが、チェックポイントが発生するとダーティーページがデータファイルに対してフラッシュされます。
そのため、[SQL Memory] から [Disk Storage] に対してデータが流れることになります。この矢印の方向を理解しておくと SQL Server のデータの流れが分かるかと思います。

 

情報はパフォーマンスモニタから取得されており、以下のような項目を取得し、画面に表示を行っています。

DiskIdleTime = LogicalDisk% Idle Time
AvgDiskReadSec = LogicalDiskAvg. Disk sec/Read
AvgDiskWriteSec = LogicalDiskAvg. Disk sec/Write
AvgDiskQueueLength = LogicalDiskAvg. Disk Queue Length
DiskReadBytesSec = LogicalDiskDisk Read Bytes/sec
DiskWriteBytesSec = LogicalDiskDisk Write Bytes/sec

TransactionsSec = DatabasesTransactions/sec
LogFlushes = DatabasesLog Flushes/sec
TempDBSize = DatabasesData File(s) Size (KB)tempdb
TempDBLogSize = DatabasesLog File(s) Size (KB)tempdb
TempLogSpaceUsed = DatabasesLog File(s) Used Size (KB)tempdb

CPUPercent = Processor% Processor Time

CompilesSec = SQL StatisticsSQL Compilations/sec
RecompilesSec = SQL StatisticsSQL Re-Compilations/sec
BatchesSec = SQL StatisticsBatch Requests/sec

TargetMemory = Memory ManagerTarget Server Memory (KB)
TotalMemory = Memory ManagerTotal Server Memory (KB)
ConnectionMemory = Memory ManagerConnection Memory (KB)
MemGrantsPending = Memory ManagerMemory Grants Pending

BufferCacheSize = Buffer ManagerDatabase pages
BufferCacheHitRatio = Buffer ManagerBuffer cache hit ratio
UserPageLookups = Buffer ManagerPage lookups/sec
PageLife = Buffer ManagerPage life expectancy
LazyWrites = Buffer ManagerLazy writes/sec
ReadAheads = Buffer ManagerReadahead pages/sec
Checkpoints = Buffer ManagerCheckpoint pages/sec
DiskReads = Buffer ManagerPage reads/sec
DiskWrites = Buffer ManagerPage writes/sec
StolePages = Buffer ManagerStolen pages

LocksPerSecond = LocksLock Requests/sec
LockWaits = LocksLock Waits/sec_Total
AvgLockWaitTime = LocksAverage Wait Time (ms)_Total

UserConnections = General StatisticsUser Connections
LoginsSec = General StatisticsLogins/sec
TempObjectCreate = General StatisticsTemp Tables Creation Rate
TempObjectDestroy = General StatisticsTemp Tables For Destruction
TempActiveTables = General StatisticsActive Temp Tables

ProcedureCacheSize = Plan CacheCache PagesSQL Plans
ProcedureCacheHitRatio = Plan CacheCache Hit RatioSQL Plans

MemPagesSec = MemoryPages/sec
FreePTEs = MemoryFree System Page Table Entries
PagedPool = MemoryPool Paged Bytes
NonPagedPool = MemoryPool Nonpaged Bytes
AvailableSystemRam = MemoryAvailable MBytes

ProcQueueLength = SystemProcessor Queue Length

WorkTables = Access MethodsWorktables Created/sec
WorkFiles = Access MethodsWorkfiles Created/sec
FullScans = Access MethodsFull Scans/sec

msdtc = Exec StatisticsDistributed QueryExecs in progress

手動でパフォーマンス監視をしたいときはこの項目をベースに必要となる項目を追加していくと楽かもしれないですね。

 

Live Monitor でリンクになっている箇所は情報をブレークダウンすることができます。

[User Connections]
image

[Total]
image

[Locks / sec]
image

[Avg Waits]
image

[Latch Stats]
image

[Current Memory]
image

[Plan Cache]
image

[Expensive Queries]
image

[Detailed TempDB Views]
image

 

SQL Live Monitor は現在の使用状況を確認するだけでなく、ログを取得する機能を持っています。
[Option] ボタンを押すことで、ログ取得の設定をすることが可能です。
image

デフォルトではログ取得は有効になっていないのですが、
[Log Data for offline analysis (CSV)]
[Log Blocked Process Details (CSV)]
[Log Data for PAL Analysis]
を有効にすることで、ログを取得することが可能になります。ログですが、SQL Live Monitor を実行したフォルダに取得されます。
# Blocked Process はうまく取得できなかったのですが…。

 

[PAL Analysis] は PAL Tool で解析をするための取得データになり、このデータはパフォーマンスモニタを使用して取得されています。
設定を有効にすると、[mscounters] というユーザー定義のデータコレクタ セットが作成され、このコレクタ セットで PAL Tool で解析するためのパフォーマンス情報が取得されます。
image

この PAL Tool 用のデータですが以下の情報が取得されています。

Network Interface(*)Bytes Total/sec
Network Interface(*)Current Bandwidth
Network Interface(*)Output Queue Length

SystemProcessor Queue Length

Processor(*)% Processor Time
Processor(*)% Privileged Time
Processor(_Total)% Processor Time
Processor(_Total)% Privileged Time
Processor(*)% Interrupt Time

PhysicalDisk(*)% Idle Time
PhysicalDisk(*)Avg. Disk sec/Read
PhysicalDisk(*)Avg. Disk sec/Write

LogicalDisk(*)% Idle Time
LogicalDisk(*)Avg. Disk sec/Read
LogicalDisk(*)Avg. Disk sec/Write
LogicalDisk(C:)Free Megabytes
LogicalDisk(*)Disk Transfers/sec

MemoryFree System Page Table Entries
MemoryPool Nonpaged Bytes
MemoryPool Paged Bytes
MemoryAvailable MBytes
MemoryPages/sec

SystemContext Switches/sec

Process(*)Private Bytes
Process(*)Handle Count
Process(*)Thread Count
Process(*)% Processor Time
Process(*)Virtual Bytes
Process(*)Working Set

MemorySystem Cache Resident Bytes
MemoryPages Input/sec

Paging File(*)% Usage
Paging File(*)% Usage Peak

Process(sqlservr)% Privileged Time
Process(sqlservr)% Processor Time
Process(*)IO Data Operations/sec
Process(*)IO Other Operations/sec

SQL StatisticsBatch Requests/sec

Access MethodsForwarded Records/sec
Access MethodsFreeSpace Scans/sec
Access MethodsFull Scans/sec
Access MethodsIndex Searches/sec
Access MethodsPage Splits/sec
Access MethodsScan Point Revalidations/sec
Access MethodsWorkfiles Created/sec
Access MethodsWorktables Created/sec

Buffer ManagerBuffer cache hit ratio
Buffer ManagerLazy writes/sec
Buffer ManagerCheckpoint pages/sec
Buffer ManagerFree pages
Buffer ManagerPage life expectancy
Buffer ManagerPage lookups/sec
Buffer ManagerPage reads/sec
Buffer ManagerPage writes/sec

General StatisticsLogins/sec
General StatisticsLogouts/sec
General StatisticsUser Connections

LatchesLatch Waits/sec
LatchesTotal Latch Wait Time (ms)

Memory ManagerMemory Grants Pending
Memory ManagerTarget Server Memory (KB)
Memory ManagerTarget Server Memory(KB)
Memory ManagerTotal Server Memory (KB)
Memory ManagerTotal Server Memory(
KB)

SQL StatisticsSQL Compilations/sec
SQL StatisticsSQL Re-Compilations/sec

Locks(_Total)Lock Requests/sec
Locks(_Total)Lock Waits/sec
Locks(_Total)Lock Wait Time (ms)
Locks(_Total)Lock Timeouts (timeout > 0)/sec
Locks(_Total)Number of Deadlocks/sec

このログを使用して PAL Tool でレポートを作成することが可能となります。

 

■Performance Analysis of Logs (PAL) Tool

 

PAL Tool はパフォーマンスモニタで取得した情報を解析しレポートを作成することができるツールになります。
# PowerShell 2.0 と .NET Framework 3.5 の Chart Control が必要になります。
Live Monitor では、PAL Tool の [Microsoft SQL Server 2005/2008] のテンプレートに合わせた情報を取得していますので、取得したデータをすぐに PAL Tool にかけてレポートを作成することが可能です。

こちらが PAL Tool を起動した画面になります。
image

レポートの作り方は簡単で、[Counter Log] から Live Monitor で取得したパフォーマンスモニタのログデータを選択し、
image

[Threshold File] から、[SQL Server 2005/2008] をテンプレートとして設定をし、
image

[Execute] から [Finish] をクリックすることでレポートを作成することが可能です。
image

そうすると裏で PowerShell が実行されレポートが作成されます。
image

PAL Tool の実行が完了するとこのようなレポートが生成されます。
# デフォルトだと PAL Tool を実行したユーザーの [ドキュメントPAL Reports] に出力されます。
image

CPU の使用率の警告やメモリの空きの警告など基本的な情報を出力してくれるほかに SQL Server 固有のレポートが生成されます。
たとえば、Page Life Expectancy は 300 以上を推移しているのが良好な状態というのが定番になっていますが、そのレポートに関しても作成がされています。
# 300 を超えていない場合は赤くなって警告のレポートが作成されます。
image

こちらは CPU の使用率のグラフになるのですが、80%~100% は注意が必要な範囲 (Critical) なので赤くなっているのが確認できます。
以下のグラフでは瞬間的に Clitical の領域に達していることが確認できます。

image

ただし、別のグラフ (Processor の Queue) では Warning / Critical には達していませんので瞬間的な CPU の負荷であって、CPU のスペックの限界までは達していない (処理能力には余裕がある) 状態であると考察することができます。
image

Live Monitor で取得したデータを基に SQL Server の状態と、サーバーの基本的な状態をレポートとして確認をできますので、複数のグラフを見比べサーバーの状態を確認することが可能となります。

パフォーマンス チューニングではベースラインとして現状を確認することが重要になりますので、これらのツールを組み合わせると一からベースライン情報の取得を考えなくてもよいので楽になるかと思います。

グラフをどう読み解いていくかが難しいところではあるのですが、最初の一歩としては Warning / Critical となっている箇所を注視して、他のグラフと重ね合わせていくとよいのかな~と。

Written by Masayuki.Ozawa

11月 12th, 2010 at 12:15 am

Posted in SQL Server