SQL Server の AWE オプションについて軽くまとめてみたいと思います。
詳細については以下の記事がとても参考になります。
SQL Server のメモリ管理 – Part 3
■SQL Server の AWE の設定について
SQL Server で AWE の設定というと以下の二種類になるかと思います。
- アドレスウィンドウ化拡張 (awe enabled) による物理メモリマッピングの拡張
- メモリ内のページのロック (lock page in memory) を設定することによりページングの対象としない
AWE というとアドレスウィンドウ化拡張による使用できるメモリの拡張を指す場合がありますがメモリ内のページのロックに関しても AWE API が使用されています。
32 ビット環境の SQL Server でアドレスウィンドウ化拡張を有効にするためには、
- sp_configure で awe enabled を 1 にする
- ローカルセキュリティポリシーで SQL Server のサービスアカウントにメモリ内のページのロックの権限を付与する
の設定をする必要がります。
64 ビット環境の SQL Server ではアドレスウィンドウ化拡張をしなくても仮想メモリ空間のサイズが大きいので、大容量のメモリを使用することができます。
そのため、SQL Server での AWE メモリの有効化 には、
AWE は 64 ビット オペレーティング システムには不要であり、構成できません。
と記載されていますが、これは awe enabled が不要ということで、メモリ内のページのロックが使用できないということではありません。
64 ビット環境の SQL Server でもメモリ内のページのロックを使用することは可能です。
メモリ内のページのロックを使用することのメリットとしてワーキングセットのトリミングを防ぐことができるという点があります。
メモリ内のページのロックを設定されていない状態で SQL Server でメモリを確保するとワーキングセットとして確保がされます。
タスクマネージャーやパフォーマンスモニタでプロセスのワーキングセットを確認すると、ワーキングセットとして確保されていることが確認できます。 
ワーキングセットとして確保されているメモリに関してはトリミング (ページング) の対象となります。
この状態で他のプロセスによりメモリの確保要求があったとします。
ワーキングセットとして確保しているメモリはトリミングの対象となりますので、SQL Server はメモリを解放する必要があります。 
これがワーキングセットのトリミングと言われている現象になります。
64 ビット バージョンの SQL Server でのバッファー プール メモリのページングを削減する方法
SQL Server プロセスのワーキングセットのトリミング
ワーキングセットのトリミングが発生すると SQL Server は確保しているメモリを解放する必要がありますので、SQL Server のキャッシュされている内容が一部破棄されることになります。
そうするとキャッシュしているデータの量が減りますのでパフォーマンスに影響が出てきます。
他でメモリが必要になったので解放するという動作はメモリを複数のプロセスで効率よく使用するという観点では正しいのですが、キャッシュヒット率の低下ということになります。
このような現象を防ぐためにメモリ内のページのロックを付与することがあります。
先ほどのデータに Database pages の値を追加してみます。 
SQL Server のページは 8KB になりますのでデータのキャッシュとして、
1,998,000 ページ × 8KB = 約16GB
程度のメモリが確保されていることが確認できます。
この状態で 1GB のファイルをメモ帳で開いてみます。
今回のサーバーはメモリを 16GB 搭載していますので、物理メモリが足りていない状態になりますのでページ内のメモリのロックが付与されていない場合は、SQL Server はメモリを解放します。 
それでは、SQL Server のサービス起動アカウントに、ページ内のメモリのロックを付与してみます。
最初の状態がこちらになります。
ページ内のメモリのロックを付与している場合、AWE API によってメモリが確保されるため、ワーキングセットとしては確保されていない状態となります。
そのため、プロセスワーキングセットが先ほどと比較して大幅に減少しています。
AWE API を使用している場合、メモリの確保さている状態に関しては SQL Server のカウンタを使用する必要があります。
Database page に関しては、先ほどと似たような値を示していますね。 
それではこの状態で 1GB のファイルをメモ帳で開いてみたいと思います。
多少は解放されたようですが、キャッシュに関してはほぼ確保された状態のままとなっています。 
これが、64 ビットの環境で AWE API を使用することの利点になります。
本来は max server memory と組み合わせて使うことになるのが一般的だと思います。
メモリ内のページのロックに関しては 64ビット環境でも引き続き使用できますので、SQL Server と他のアプリを共存している場合などは max server memory と合わせて設定しておくとよいかもしれないですね。
マルチインスタンスの環境ではインスタンス間で意図的にワーキングセットのトリミングを発生させ、各インスタンスでメモリを使用するという考えもあるようなので、設定はケースバイケースになると思いますが。