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

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

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

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

 

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

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

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

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

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

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

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

■初期状態

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

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

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

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

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

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

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

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

 

■データを平準化する

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

として、

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

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

 

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

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

最近は 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] となります。

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 のメモリを使用させた状態です。

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

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 の状態を確認してみたいと思います。

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

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

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

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

 

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

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

サーバーの空きメモリはあるのですが、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 に制限されますが。

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

bcdedit /deletevalue {current} increaseuserva

 

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

 

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

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

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