Memories of DR testing

Question

Memories of DR testing

MVDBA (Mike Vessey)

SSC-Insane

Points: 21797
More actions
August 19, 2019 at 12:00 am

#3669254

Comments posted to this topic are about the item Memories of DR testing
MVDBA

Viewing 3 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply

jfogel SSCarpal Tunnel Points: 4155 More actions · Answer 1

I was fortunate during DR testing due to how we planned the fail-over. As in most cases, you have the controlled method and then there is the be happy you have anything method. We used Log Shipping for this with a 15 minute schedule for the file copy process. Depending on what happened and when, it was thought we would lose no more than the last 30 minutes from any given database (factoring in the potential size of the files to copy, network saturation, etc.). The databases related to SSRS were backed up, copied and restored to the DR server(s) daily. I'm the only DBA here, so I documented every step related to fail-over to the point that all anyone would need to do is copy and paste the commands in the event I was not around anymore or otherwise not available. All the hardware and software was an exact twin in DR as well, so there wouldn't be resource shortages.

Log Shipping went a long way in avoiding things described in the article since the database was already there. It also helps that were have only two homegrown databases as the other are behind commercial apps. The two homegrown DBs are meat an potato in that there are no MOTs or other "exotic" objects. Just a few triggers nobody ever remembers exist. Log shipping also proved valuable if someone made an oops. I didn't have to restore anything to grab one row someone messed up. As long as they told me in time before the next log restore.

Then, we virtualized everything. Log Shipping gave way to SAN replication and fail-over controlled via SRM. We tested that for real when we moved data centers. We first moved out DR equipment to the production Equinix facility and prepared it to be the main site. Then we failed over to it from our Tampa production site. It all worked as planned. One piece of advise I'd give concerning a DR site is to not prefix the names of systems with "DR". Now, all the systems, vCenter, etc. have DR at the front of the name. "Yes, I'm sure that is production" is something I've had say more than once.

Cheers

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 2

Really good article that covered a whole lot. The high point is how managers want everything but don't want to pay anything. I also believe that capital expenditures shouldn't be named "CapEx"... it should be "BBS" (Beg, Borrow, and Steal) because of the high point I mentioned. 😀

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)