SQL Server を稼動していると、物理メモリが満杯になるまでメモリを消費して
いきます。しかし、以下の KB に書いてある通り、これは正常な動作です。
[INF] SQL Server のメモリ使用量
http://support.microsoft.com/?id=321363
Available Bytes が 4 MB～10 MBになるように動作するということは、マシンに
搭載された物理メモリ以上はメモリを消費しないという意味です。
つまり、SQL Server は「できる限りページングが発生しないよう」にメモリを消費
していきます。
また、
メモリ使用量の多くはデータバッファキャッシュ
であることも忘れてはなりません。
例えば、SELECT * FROM xxx を実行したときに
xxx テーブルのサイズが 500 MB だったとすると、
データバッファキャッシュで 500 MB 消費し、
SQL Server のメモリ使用量も 500 MB 増加します。
また、一度確保したメモリ領域は、他のアプリケーションからメモリ要求が
あるまで解放されません。例えば、DBCC DROPCLEANBUFFERS コマンド
を実行してデータバッファキャッシュを解放したとしても内部的には、
Free Pages へ変換されるだけなので、SQL Server のメモリ使用量が解放
されるわけではありません。Free Pages? に変換する理由は、メモリの解放/
再取得のオーバーヘッドを軽減するためです。
Free Pages の動作についてはこちらも参考になります。
機能説明ビデオ: セッション「メモリの自動チューニング」
http://www.microsoft.com/japan/sql/techinfo/video/tuning.asp
というわけで、SQL Server のメモリ使用量が物理メモリが満杯になるまで
増え続けていても、多くの領域は、データバッファキャッシュや Free Pages
として利用されているので、メモリを解放する必要はありません。
では、
絶対に SQL Server のメモリを解放する必要はないか？
と聞かれると、そのマシンが SQL Server のみを動作させている専用サーバー
なら Yes です。
しかし、IIS（ASP/ASP.NET）や VB/VB.NET アプリなどを同じマシンで実行
させる場合は、注意が必要です。
少し上に「SQL Server が確保したメモリ領域は、他のアプリからメモリ要求
があると解放される」と説明しましたが、これはページングが発生しないように、
SQL Server がメモリを解放するという意味ではありません。
多くのアプリはページファイル (pagefile.sys) を使ってでも動作しようとするので、
メモリの解放がどこまで行なわれるかは、予測できません。
また、以下のように解放されないメモリ領域が存在することも覚えておく
必要があります。
・接続用のメモリ（Connection Memory）
・ロック用のメモリ（Lock Memory）
・使用中のデータバッファキャッシュ
・そのほか使用中のもの
したがって、SQL Server と同じマシン上で IIS（ASP/ASP.NET）や VB/VB.NET
アプリを動作させる場合は、ページングが発生しないように、SQL Server の
最大メモリ使用量（max server memory）を低く設定した方がパフォーマンスが
向上する場合もあります。
もちろん、低くした分だけデータバッファキャッシュへ割り当てられるメモリ量が
減ってしまうので、それとのトレードオフになります。
<参考資料>
・Books Online
? ［SQL Server のアーキテクチャ］
?? +［リレーショナルデータベースエンジンのアーキテクチャ］
??? +［メモリ アーキテクチャ］
???? +［Windows NT および Windows 2000 でのメモリの動的管理］
・PASSJ Conference 2004「Expert-03 パフォーマンスチューニング」
? http://www.sqlpassj.org/conf2004/dl.aspx#session
・DBマガジン 2004年4月号「SQL Serverトラの穴－第3回 メモリ監視のコツ」