Hal Kaplan <> wrote: > => -----Original Message----- > => From: [EMAIL PROTECTED] > => [mailto:[EMAIL PROTECTED] On Behalf Of Stephen the Cook > => Sent: Monday, October 09, 2006 10:48 => To: 'ProFox Email List' > => Subject: RE: [NF] - SQL- Database Replication => => => Now Q about > having both primary and backup on the same rack? => I know that in > my last gig I had that set up and did a => logshipping through a > crappy VPN back to my business office. => Distance was only 10 > miles, but bulk transactions failed in => the every 15 min push > because data size didn't fully copy => over. So watch out on those > little aspects of covering your assets. => => Stephen Russell > > Uh, thanks for the Availability 101 course. It was a good refresher > since I haven't been involved with that level of availability since > 1981 when I was involved in clustering Univac mainframes. > > Back to "all your eggs in one basket:" I still don't get the point > or sagacity of putting the primary and backup in the same rack, let > alone the same location. Any type of catastrophe is going to wipe > everything out. Depending on site specifics, even some things that > are less than catastrophic can result in total loss. How do you > protect yourself when everything is in one place?
Well you still do the logshipping to another location to receive the transaction logs. You also have to take the nightly diff backups to a separate storage and the full as often as needed. In all my years of SQL admin I have found that when SQL server goes stupid, it's trying to use virtual ram for it's processes. Darn, you have to reboot the box. Happens every 90 days or so. When your clustered, you down the primary box and the cluster promotes the passive to active. Your data is intact and you didn't have to go through a restore process to bring it up to date, or to reset lots of potential connections to use the new data source. Using RAID 5 I have replace quite a few drives in the raid appliance, and in 95% of the time I was up without any problems. Only once did the local staff place the backup, diff, and tran files on the same RAID that was also C:\. You can point out the problems but sometimes they don't pay any attention, till it's to late. So 19 good and one bad in just about 10 years of SQL server data. Now some points on clustering that are missed. Every instance of SQL Server in the cluster runs as a SERVICE on the server. So if you have production as well as staging INSTANCES on the same cluster, you can take down the staging cluster if you see one environment taking resources that the other needs. In the past you had to kill the server, but clustering allows you to tackle the instance properly. I'll say that this point is missed on many people who work in a clustered environment and they over react in an emergency. Stephen Russell DBA / .Net Developer Memphis TN 38115 901.246-0159 "Our scientific power has outrun our spiritual power. We have guided missiles and misguided men." Dr. Martin Luther King Jr. http://spaces.msn.com/members/srussell/ -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.407 / Virus Database: 268.13.1/466 - Release Date: 10/7/2006 _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
