You won't be able to use AWE with Windows 2003 Standard. You need Enterprise, see Large memory support is available in Windows Server 2003 and in Windows 2000:
PAE is the added ability of the IA32
processor to address more than 4 GB of
physical memory. The following
operating systems can use PAE to take
advantage of physical memory beyond 4
GB:
* Microsoft Windows 2000 Advanced Server
* Microsoft Windows 2000 Datacenter Server
* Microsoft Windows Server 2003, Enterprise Edition
* Microsoft Windows Server 2003, Datacenter Edition
To enable PAE, use the /PAE switch in
the Boot.ini file.
The working set you see is 7MB, not 7GB. That is a normal working set for a process, since working set don't measure the amount of memory allocated to a process, but only the working set which is always much much smaller:
Shows the current number of bytes in
the working set of this process. The
working set is the set of memory pages
touched recently by the threads in the
process. If free memory in the
computer is above a certain threshold,
pages are left in the working set of a
process even if they are not in use.
When free memory falls below a certain
threshold, pages are trimmed from
working sets. If they are needed, they
are then soft-faulted back into the
working set before they leave main
memory.
You need to look at Process\Virtual Bytes instead:
Shows the current size, in bytes, of
the virtual address space that the
process is using. Use of virtual
address space does not necessarily
imply corresponding use of either disk
or main memory pages. Virtual space is
finite, and by using too much, the
process can limit its ability to load
libraries.
The SQL Server memory is 3GB, which is all it can allocate on Windows Standard with /3GB switch.
So you'll need to purchase a Enterprise Windows license, or simply move to an 64 bit OS and 64 bit SQL deployment (which is really the only sane option).
Best Answer
You should really tune for PERFORMANCE, not for magic numbers.
Zero paging file (swap) utilization is a nice goal if you can attain it, but if you have sufficient RAM for all of SQL server's needs and you are not experiencing a performance problem you probably don't need to "tune" anything. Having some data sitting in the paging file which is never going to be asked for doesn't hurt performance.
If you want to concentrate on numbers though I would concentrate more on
Memory\Available Bytes(make sure there's always a healthy amount available, where "healthy" is defined by your use case) andMemory\Pages/sec(which should be zero or close to it, indicating that what's sitting in swap is not being actively recalled to RAM).Remember that modern operating systems will often evict data that has never been requested from RAM, placing it in the paging file (swap space) preemptively while the system is idle so that there is more RAM available and the system doesn't have to take the performance hit of shuffling stuff to disk if it needs that RAM when it's actually busy.
As an example, consider these stats from one of my (unix) DB servers:
(because there's a program on this server with a memory leak that is mostly swapped out)
So at this time I take no tuning actions (though I do kill and restart the program with the memory leak when swap utilization hits 50%).