Jump to content

Recommended Posts

Posted

Does anyone have any guidance on what settings should be implemented in SQL 2008 R2 Full to run a SIMS Database? I have a server ready with Server 2008 R2 and 16GB RAM and I just need to install SQL. Are there any tweaks I should be doing to enable it to use both Processors (2 quad cores) and as much RAM as it needs? I have bought 2 x Processor licence so am covered for 2 processors.

 

Any pointers would be greatly appreciated.

Posted
I've been saying to install Capita's SQL Express then put the 2008 disc in the upgrade the edition then do a new install and install SQL Management studio. Once SQL management studio installed, enable AWE. Not recommending R2 yet. I've yet to hear of a good reason to install it.
Posted
Are there any tweaks I should be doing to enable it to use both Processors (2 quad cores) and as much RAM as it needs? I have bought 2 x Processor licence so am covered for 2 processors.

 

Dont think you need to do anything with processor or ram in sql.

Posted

SQL should use all the memory and cores by default anyway, most of the optimisation comes from designing the IO subsystems.

 

As for tweaking SQL itself, you should start with adding additional tempdb files of a reasonable but equal size, one for each core assigned to SQL. You should also ensure that the database file growth options are set correctly. I've seen SIMS databases set to 1MB growth which has terrible overhead and causes horrific OS level fragmentation. I'd recommend you set the database to a fixed size with room to spare, set a reasonable growth size (depends on your database size) and use windows defrag while sql is disabled to ensure the database files are contiguous before going live.

 

- Chris

Posted

Growth rate of about an eighth of the maximum you'd want i think is reasonable. My initial is 140MB with growth at 125MB. It doesn't often go crazy, but when it does it's easy to shrink it down again. This was with a nearing 4GB mdf file. I worked it out a while ago, based on best practise, and it seems to be okay.

 

If we're talking best practise now, you could look up the threads regarding the type of raid to use for each db, and where to put them, i.e. separate data partitions with temp db separate etc. but there's no point reiterating all that here.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...