Couple of newbie questions

My company is moving to SQL Server soon, and I'm certainly excited about it. Currently we are using a FoxPro based solution which is slow and unreliable.

I'm working on the configuration and have a few questions. We are planning on going with a SQL Server 2000 Standard Edition running on Windows 2000 Server. Some of what Microsoft has said on the web site is very vague concerning the licensing and other maximums.

What is the max memory that you can use with SQL Standard on a Windows 2000 Server (not Advanced)?
If you have more memory in the server than SQL Standard will support, is that OK? For example, can you say, if SQL Standard maxes out at 2 GB, put in 3 GB, and let the OS have the rest? Our database will probably be around 2 GB to start.
Do you need seperate CALs on Windows 2000, or does it work like other apps like Exchange, where you only need the CAL's for the application (or in this case, the Processor licences).
For a 3 processor server, does anyone think that for about 60-70 users that I should go with a CAL or Processor license model?
Should I spring for the 2MB cache on the processor? Planning on a 3 way 700 Mhz Xeon.

Thanks in advance.According to Books Online:

1. What is the max memory that you can use with SQL Standard on a Windows 2000 Server (not Advanced)?

2GB is the maximum that SQL Std can use.

2. If you have more memory in the server than SQL Standard will support, is that OK? For example, can you say, if SQL Standard maxes out at 2 GB, put in 3 GB, and let the OS have the rest? Our database will probably be around 2 GB to start.

If the OS can see the additional RAM, this should be ok. I cannot think how much memory that Win2k std can use.

3. Do you need seperate CALs on Windows 2000, or does it work like other apps like Exchange, where you only need the CAL's for the application (or in this case, the Processor licences).

If you go with per processor licensing of SQL Server, that is all you need.

4. For a 3 processor server, does anyone think that for about 60-70 users that I should go with a CAL or Processor license model?

I found SQL2k Std per processor licensing at ~4500 multiplied by 3 you would be at ~$13,500

I found SQL2k Std 10 client for $2000. If you purchased 7 of these (70 user), you would be at ~$14,000

Right now, the price is about the same. You need to weigh the options, and look toward the future.

What happens if the 3 processor server needs 5 more processors? What happens if you add 40 more users? How will this impact your licenses (and cost)?

5. Should I spring for the 2MB cache on the processor? Planning on a 3 way 700 Mhz Xeon.

I don't know. What is the price difference between 2MB, 1MB, and 'normal' Xeons? We have an 8 way 700 with 2MB cache and things perform quite well. I am sure that we paid a premium for the 2MB chips...I do not know what performance would be like if we had lesser Xeons. Maybe someone else can help out here with some suggestions.

________________
Keith|||2. If you have more memory in the server than SQL Standard will support, is that OK? For example, can you say, if SQL Standard maxes out at 2GB, put in 3 GB, and let the OS have the rest? Our database will probably be around 2 GB to start.

Win2k and NT Standard see 4GIG max which is the memory space directly addressable by a a 32bit operating system.

The 2 gig limit for SQL Server comes from the fact that the NT architecture has a 2gig per process memory limit.

5. Should I spring for the 2MB cache on the processor? Planning on a 3 way 700 Mhz Xeon.

It's hard to say. All of our SQL Servers now have 2MB processor caches. We had one Dell 4-way server with 512K (standard) caches that severely under-performed and was replaced by a Compaq server. But the Compaq server was much more carefully specified so direct comparisons are tough. I know this. I've read of people with performance problems when CPU utilization is at 100% on all 4 processors. On our Compaq servers, when all four processors are at 100%, people can still work. It's a little slower, but almost goes unnoticed except by those that cause the performance spike (period end processes, some custom reports). On the Dell, if all 4 where at 100% no one moved. It would stop everyone in their tracks. Compaq's processor multi-processor architecture probably has something to do with it, but I bet the 2MB cache in each processor has something to do with it also.

If the cost is not unreasonable go for the 2mb cache. We choose slower processors with 2MB cache over a faster processor with 512k or 1mb and haven't looked back.|||Thanks for the repsonse. It will be a few thousand more to upgrade from the 1 MB to 2 MB cache, so it may be difficult to get that passed through our budget.

Out of curiosity, how many users are you guys dealing with? I'll be around 50 concurrent to start, while not expecting that number to go up to more than 75 any time soon (a few years off).|||We have about 60 users hitting the system full time.

Keep in mind, it is not so much the user count, but the way the application and database were created that really affects performance.

________________
Keith|||I don't even know exactly right now. Probably right around 35-60 depending on the time of day. But really it's not the number of users, but the work you expect the server to perform for those users.

Our primary server runs an accounting and distribution package that is heavily optimized for SQL Server and WAN environments relying on Triggers, and stored procedures, and temp tables for reports. (And not measly select * from thistable stored procedures, these are real ones that do real work.) This application works the server. 1MB may be just fine. At the time we specified the hardware we had the choice of 1mb cache and 650Mhz processors or 2mb Cache and 450mhz processors to fit in our price range. We went with the 450mhz processors and 2mb cache. 20

Make sure your application isn't just a fancy data store. We way equipped some hardware we have right now for a mission critical clustered solution. Quad processor Active/Active Compaq machines with 4gig each running SQL Enterprise and NT Enterprise, and we get the app installed on a test machine and I find it was ported from Oracle and AS/400 and is mostly flat files stored in the database. No stored procedures, no referential integrity, hardly even any indexes. The groupresponsible for getting the hardware obviously didn't do their researchfirst. Such a database will hardly be taxing the CPU's and is more likely to have blocking issues than performance issues. I can't wait until we go live...