[AccessD] Needs analysis

Jim,

 >   If you look at the chart about half way down, it covers 64 bit OS's as well.
 >
 >   For conventional memory, it says that SQL can go to 8 terabytes on x64 architecture, but makes 
note that under Windows Server 2003, the limitation is 512GB and under Windows Server 2003 with 
Service Pack 1, the limitation is 1 terabyte.

As it happens, 64 gigs is all I can afford since the motherboards I will use provides 8 memory 
sockets per CPU socket, and the 4 gig memory dimms are affordable but the 8 gigs are not.

At the end of the day, moving from 16 gigs total and a single 4 core CPU to 64 gigs total and dual 8 
core CPUs will nicely provide my "every three year upgrade".  The past upgrades have been from 
single core to dual core and then to quad core, and from 4 gigs (X32) to 8 gigs to 16 gigs (X64). 
Moving to X64 and more memory was a tremendous boost, and I expect that to be the case here as well.

I really do need to do the performance analysis thing, I just haven't gotten around to it.  The 
downside to being a sole  proprietor is "not enough time for everything".

John W. Colby
www.ColbyConsulting.com


Jim Dettman wrote:
> John,
> 
> <<All I see discussed there is AWE.>>
> 
>   If you look at the chart about half way down, it covers 64 bit OS's as
> well.
> 
>   For conventional memory, it says that SQL can go to 8 terabytes on x64
> architecture, but makes note that under Windows Server 2003, the limitation
> is 512GB and under Windows Server 2003 with Service Pack 1, the limitation
> is 1 terabyte.
> 
>   The 64GB limit only applies to 32bit OS's and AWE must be used.  Otherwise
> your stuck at 2, 3, or 4GB depending on how your configured.
> 
>   Since your running 64 bit, the more physical memory you have, the better
> off you'll be because it will all get used.
> 
>   Also note it recommends under the 64 bit column adding the lock pages
> priv, so SQL sever can keep it's pages in physical memory rather then
> letting the OS swap them out.
> 
>   Last, at the end of the third yellow note, there is a link for How To:
> Tune a database, which leads to a page discussing the database tuning
> advisor.  Here's the main link for that tool:
> http://msdn.microsoft.com/en-us/library/ms173494.aspx
> 
>   That might be too simplistic a tool for what your working with and it
> focuses more on the DB structure then the hardware, but at the very least
> it's a place to start.
> 
> FWIW,
> Jim.