jwcolby
jwcolby at colbyconsulting.com
Sun Jun 20 12:35:57 CDT 2010
Jim, It's not one database it is dozens of databases, the smallest of which is 20 to 30 gigabits. I have a 2 gig volume that is the database storage, another 2 gigs which are online backups, another 2 gigs which are order storage (spreadsheets and raw text files going in / out of the database), a raid one which is the boot drive and a raid 0 which is the temp database. Oh, and the one gig offline backup for rotation (soon to be 2 gigs). I have lost the occasional drive, and with a dedicated raid controller you just replace the drive and the controller starts to rebuild the raid. Raid 6 allows you to lose two drives and still rebuild. Raid 5 causes you to lose the shooting match if you lose 2 drives. I have massive amounts of stuff here, and it does not belong to me. I cannot afford to be cavalier about the system. In the 5+ years I have been doing this stuff I have never had a single instant where the data was not available - and by that I really mean where I could not just move the entire thing to another system if necessary. I build my own systems and I have had times where one of my two servers at a time was being upgraded, new motherboard and so forth but if push came to shove I could always just swap the raid array to the other machine and be back up in a matter of an hour or so. I credit that reliability to RAID. All of that said, I am actively evaluating using SSDs for two specific databases which are kind of the center of the universe. It will probably be raid 0 in order to get gigantic read speed, and I will just have to make sure that I have a backup available at all times. > And I would agree Mark's point; your off in the wild blue yonder. I think you'd find better answers at SQL central or another SQL specific forum rather then the here. I actually posted this thread to AccessD by mistake. My intention was to post to the SQL Server group, which I did when I realized that I had posted to AccessD. OTOH I have posted about the "database from hell" in the past and some here might find it interesting how that has morphed into an entire business. I am looking at building out a new "latest gen" server to host this business. It appears that I am going to have a budget of around $6,000. That wouldn't touch a Dell or HP but since I build my own it is "just barely" enough to do what I am looking to do. For that I am hoping to get: 1) A dual socket server grade motherboard: http://www.newegg.com/Product/Product.aspx?Item=N82E16813131643 2) 32 gigs or perhaps even 64 gigs of registered, ECC ram. http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=2010170541+1052129233+1052323986&QksAutoSuggestion=&ShowDeactivatedMark=False&Configurator=&Subcategory=541&description=&Ntk=&CFG=&SpeTabStoreType=&srchInDesc= 3) (two) 8 core AMD chips (though Newegg is out of stock ATM.) http://www.newegg.com/Product/Product.aspx?Item=N82E16819105266 4) a 4U rackmount case with space for 20 hard drives http://www.newegg.com/Product/Product.aspx?Item=N82E16811219021&cm_re=4u_rackmount_case-_-11-219-021-_-Product 5) an 850 watt supply http://www.newegg.com/Product/Product.aspx?Item=N82E16817139011 I will then move my existing raid controller and drives in. I have Windows 2008 x64 and SQL Server 2008 which I will use for this. I have to make a decision whether to "only" get 32 gigs of RAM and use the remaining money for SSDs or go with 64 gigs or RAM and get SSDs later. SSDs have not dropped in price as I would have expected, however they have become more mainstream, and I can only hope that they are approaching the knee of the price curve and will start to head downwards. In any case, I expect to see a significant boost in all around capability from the new system. John W. Colby www.ColbyConsulting.com Jim Dettman wrote: > Why bother to use RAID at all? Since this is mostly a read only situation, > I would not worry too much about loosing a drive because you can just > reload. > > I mean ask yourself, when's the last time you lost a drive? And how long > would it take you to recover? > > And I would agree Mark's point; your off in the wild blue yonder. I think > you'd find better answers at SQL central or another SQL specific forum > rather then the here. > > Jim.