February 12, 2008 at 1:45 pm
I will be installing SQL Server 2005 enterprise edition for the first time and was looking for some hints...
unfortuntely, I don't know alot about what kind of applications they will be using the databases for.. but I do know that I have 400GB to allocate. My manager suggested a seperate volume for the SQL Server Binaries.. not sure why... ANY OPINIONS ON THAT???
This is what he suggested
C:\ OS
D:\SQL Server application install
E:\datafiles
F:\Logfile
e:tempdb
any hints, suggestions, opinions, things to watch out for... ???????
I was thinking more along the lines of
c:\OS and application installs (sql server etc..)
E:\datafiles and TempDB
F:\Logsfiles
February 12, 2008 at 2:27 pm
It would be better to put tempdb in a separate drive. Then there wont be much Disk IO issues. Other than that, your idea seems pretty good.
-Roy
February 12, 2008 at 10:40 pm
It won't make much of a difference if the underlying volumes are not separate drives and/or separate RAID arrays. Your logical partitioning scheme with the added change from the previous reply make sense, but only if the underlying hardware is properly configured.
February 13, 2008 at 9:05 am
Let your tempdb on RAID 0 or RAID 10. And the other files on RAID 5 or RAID 10. Then make sure that yuo give sufficient memory for SQL Server and have the server benchmark analyzed.
Cheers,
Sugeshkumar Rajendran
SQL Server MVP
http://sugeshkr.blogspot.com
February 13, 2008 at 9:22 am
Create as many tempdb data files as there are processors. Create them equally sized so that they take up pretty much the entire tempdb drive - perhaps with a couple of GBs to spare.
No autogrowth!
Tempdb autogrowth can kill your application. The equal sizing requirement helps the algorithm responsible for splitting the I/O load among the data files work properly.
In my setups I put my tempdb log file in the separate log drive.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
February 13, 2008 at 9:27 am
Also:
Add a separate drive for index filegroups. I/O throughput can benefit when non-clustered index operations are separated from the rest.
In my workplace, we also keep separate drives for full and transaction-log backups.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
February 14, 2008 at 3:42 am
I would make it like this:
C: = Windows, SQL Server
D: = SQL server datafiles
E: = SQL server logfiles
F: = SQL server backups (both database and log backups)
In this way, you can "survive" if either one of the disks fail.
February 14, 2008 at 5:30 am
lsm (2/14/2008)
I would make it like this:F: = SQL server backups (both database and log backups)
In this way, you can "survive" if either one of the disks fail.
I can agree with everything else except for the F Drive. It would be better to have the back ups written to a different server in the network. Also keep a warm stand by for any eventuality that could happen.
-Roy
February 14, 2008 at 6:51 am
That's because I left a couple of details out 🙂
For backups we use:
F drive + seperate location on SAN + tape.
But it depends on the level of availability you are aiming for.
February 14, 2008 at 7:17 am
Still the same risk is there. What if the SAN goes down? Thats why I prefer to have the Back up on a seperate server that is not connected to the same SAN.
-Roy
February 14, 2008 at 12:17 pm
Thanks everyone for the replies. I ended up:
5 GB E:\SQL Server install
220 GB F:\Datafiles
100 GB G:\Logfiles
75 GB H:\SQL Server Tempdb
I don't have the SQL Server 2005 media yet.. so I'll be poking around on the web for install docs and hints.. any suggestions?
February 15, 2008 at 9:08 am
Marios Philippopoulos (2/13/2008)
Create as many tempdb data files as there are processors. Create them equally sized so that they take up pretty much the entire tempdb drive - perhaps with a couple of GBs to spare.
I'm interested why you would have as many tempdb data files as processors? What benifit would this give?
February 15, 2008 at 9:35 am
SQL Server can use separate threads to access each data file, thus giving you better performance.
March 15, 2008 at 6:22 am
ok. Here we go again. they got my Servers built yesterday and here I am on a saturday doing the installs 🙂
I ran SQL SERVER 2005 Standard Edition Setup on my Windows 2003 Enterprise Server with SP2
it ran through and installed Client tools, BOL and such.. but did not install an actual Instance. I never got the Advanced button to choose which components to install. What did I do wrong????????
I need to install a Named Instance on Both Server.. one will be DEV one Production. help?
March 15, 2008 at 7:49 am
The screen after you enter your license information contains the advanced button. See attachment.
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply