February 15, 2008 at 1:54 pm
I've been tasked with setting up a new SQL Server 2005 instance that will be used to consolidate some small applications that have recently been purchased in addition to misc applications on the network. Unfortunatley I've never done anything like that so what I'm looking for is a couple of recommendations on what to look for. I think the plan is to get a new server. I know the Data and log files need to be setup on different disc. I think the plan is to use the standard edition which limits the use to only 4 processors(Quad core I guess).
I was wondering if the 64 bit edition would be beneficial? I'd also like to set up a clustered environment. I'm not really sure as to how many databases will reside on the new server. I'm trying to ensure that I do this right since it
s mhy first time?
thanks in advance
-WM
February 15, 2008 at 4:18 pm
Wow you have a lot to discuss here.. 🙂 First (this is all just my crooked opinion hehehe) make sure IF you are getting a new server this is where you want to get the most you can and as you know make sure you have TONS of memory and Plenty of space to work with. The CPUs will be a very important place too. The reason i was mentioning these are when you consolidate and migrate you are hoping its something you are not doing on a regular basis especially hardware wise so go top shelf if possible. Depending on how heavy/intense your servers is used 4 Procs will be fine (but will they handle the future of your environment maybe/maybe not just always keep that in mind)... As for the 32 vs 64 bit thing. It more so it depends on how you are going to use the server ...Datawarehouse or data mining, or intense heavy reporting server... yea 64 the way to go.
You get the benefits of more and much more 🙂 But if you are not going into that kind...doesn't appear too..then 32 should be plenty.
The clustering (64 bit supports many more clusters then 32)is a full on monster alone if you are considering clustering the machines.. try your best to get identical machines from applications all the way down to who put on the last resistor (you know what i mean 🙂 ) It will make your life much easier in the end.
I know my lil rant is just that and i have left out plenty in hopes that others will give there $.02 and the likes.
Good luck and if you get a chance..post some specs of the systems you are considering helps everyone to give you better advice as well.
D
DHeath
February 18, 2008 at 10:48 am
Thanks
I have a lot to look at... I'll keep this updated on whatever we decide. I think for sure I want the 64 bit version of SQL. I want to get a 4 proc machine with as much memory as I can get them to buy.
Thanks again
-WM
February 18, 2008 at 11:05 am
its always nice to have the fastes, meanest, mightiest machines available for SQL Server, but there is quite a bit, you need to learn about what the user requirements are; sample what is the expected growth of the database for the next 5 years, where is the company going, what is the projected funds available for the expansion. clustering is not just technical, but is also monetary. can the company afford it. technical you need to be well verse on TCP/IP, Hardware (SANS) and the like you need to understand what a node is, as well as what other failover options are available, are the servers(clusters) going to active/pasive or active/active, did you know there is a virtual server you need to create? evaluate the requirements a little more closely then what you have describe here in this site. Let me know if I can help you.
"We never plan to Fail, We just fail to plan":)
February 19, 2008 at 3:07 am
Lots of good advice already given... The 4-processor limit in Standard Edition refers to processor sockets on the motherboard, not to processor cores. Standard edition will run legally on a 4-socket MB each running 4-core processors.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
February 19, 2008 at 6:39 am
While everyone elses reponses are right on the money (32 bit vs. 64 bit, CPU Cores, etc) you can also gather performance data on existing databases in order to get a feel for their current work load. The Context Switch, Processor Queue Length and % Disk Time counters in PerfMon can tell you what is going on behind the scenes for your current systems. Then, ideally, you'd want a dev or POC system that will mimic your new consolidated production environment. From here you can consolidate your databases and rerun the same PerfMon counters to compare against your baseline.
Doug
February 19, 2008 at 8:25 am
Thanks again for the comments. Unfortunately I think the majority of the applications will be new so I'm not going to be able to get the performance counter information.
On another note instead of the clustering option I was thinking about doing some sort of log shipping instead. I have to do some more reserach on that topic before I can speak intelligently about it. Any advice on that??
Again just to clarify I can get the Standard edition of SQL 2005 64 which has a four processor limit. This version will allow me to access more ram than the 3 GB max.
February 19, 2008 at 8:34 am
william,
To confirm, SQL Server 2005 Standard x64 SP2 can use up to 128 GB memory. It can be used on servers with up to 4 procesor sockets, each socket can have a quad-core processor.
You should consider SP2 CU1 as the minimum build level. SP2 fixed a lot of things but introduced some serious new bugs that were fixed in CU1. For a new build I would go direct to CU5, as that has less bugs than CU1. CU6 is due out anyday.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
February 19, 2008 at 1:40 pm
William,
Log shipping vs clustering LOL you sure can pick some topics... both have setback and both have positives. I think its gonna be in YOUR best interest to step back and see which will benefit you the best. From the sounds of it you are the shot caller in this game 🙂 (Many of us only wish we were in your spot for that)...Anyways, even with all the advice in the world at some point you are going to have to look at where either will place you and go with it. Sounds like you have a good machine (add more memory if you can...) and before you know it you might be doing log shipping on a clustered environment... hehehe
D
DHeath
February 19, 2008 at 1:53 pm
William all I can say is the sky is the limit. I've actually implemented a 2 node cluster with log shipping, replication and mirroring. It all depends on the purpose and need. As an example, within our primary data center we used clustering for our ecommerce server. Then, asynchronous mirroring between the primary datacenter in Denver and the DR data center in San Fran (there was very high latency with log shipping). Since you can only have one partner in a mirror session (to San Fran) I used log shipping to a "primary" failover server within the Denver data center in case of a sever hardware/SAN failure on the ecommerce server. Finally, I implemented transactional replication between the Denver data center and a remote office sever that housed ETL, Warehouse and Reporting Services in order to maximize BI data for executives.
Doug
February 19, 2008 at 2:00 pm
Well it's a new job so I'm trying to make the right decision. Don’t want to mess up right out of the gate. :w00t: But I guess I'm going to have to jump in at some point. There are just a lot of options. I've always been in situations where the setup was always there and I had to get the best performance out of what I had. This is completely different...
I do plan to do a lot more research I was just looking for opinions on either setup.
Thanks again
-WM
February 19, 2008 at 3:10 pm
you should only consider x64, there's little point in using 32 bit apps with all the memory issues and limitations. x64 std sql takes the memory limit of the o/s so std w2k3 gives you 32gb not 128. don't get carried away with procs and cores - there's an overhead which can be very heavy in x64 ( cores = threads = workers = lots of memory before you do anything )
getting a server right is not easy if you don't know what you're going to be running.
[font="Comic Sans MS"]The GrumpyOldDBA[/font]
www.grumpyolddba.co.uk
http://sqlblogcasts.com/blogs/grumpyolddba/
February 21, 2008 at 3:56 am
unless there is some reason not to, application compatibility, etc, go 64bit. In the long run it'll be beneficial.
if you have a 2nd site available to you use a MNS cluster with at least 1 node on the remote site, you can cut costs by using a File Share Witness (http://technet.microsoft.com/en-us/library/bb124922(EXCHG.80).aspx). Although you really need a SAN for this, you could get away with using iSCSI.
Get Fast disks
Get lots of RAM
February 21, 2008 at 4:39 am
It's not like you're going to be running webcams, video cards, games or odd scanners on your server, so go 64 bit 🙂
When you use mirroring just keep in mind what your new software supports. Does it support auto failure? Does it use more than one DB on the server? (If db A failed over but not B then you'd have some inconsistencies). I envy you but at the same time I can see why you're worried about getting it right. Just keep in mind that should you get it wrong first up make sure that you're intimately aware of all of the SQL Server DBs so that you can take a nice long weekend to reconfigure it all in a month's time if necessary 🙂
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply