May 22, 2013 at 4:43 am
Comments posted to this topic are about the item Understanding HA
May 22, 2013 at 6:11 am
One aspect that is often overlooked in DR is the restarting of applications. Certainly application reinstallation is often thought of but sometimes what is missed is that there will be data that was not processed as one subsystem or other was offline. Pipelines are often overlooked. When you have the SQL Server instance reinstated and the application(s) up and running along with all the expected and required systems will all the part processed data complete?
Are you certain?
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 22, 2013 at 10:02 am
Gary Varga (5/22/2013)
One aspect that is often overlooked in DR is the restarting of applications. Certainly application reinstallation is often thought of but sometimes what is missed is that there will be data that was not processed as one subsystem or other was offline. Pipelines are often overlooked. When you have the SQL Server instance reinstated and the application(s) up and running along with all the expected and required systems will all the part processed data complete?Are you certain?
Great point. Re-startability is certainly something the good SSIS developers look at, but I'm sure there are all sorts of places (replication, data file xfers, linked servers, etc) that might have problems in some configurations.
May 22, 2013 at 10:57 am
MY worst DR story was from 15+ years ago. Had a server failure at about 5 pm at night before the backups occured. All data changes for that day were lost. My boss and I literially dumpster dived to retrive all the "Red Marked" paperwork that was entered that day.
May 22, 2013 at 12:08 pm
I'm always having issues with project managers asking for HA technologies and trying to pit mirroring vs clustering. My question is always what do you want to protect against?... "Well.. I dunno... I just want ha"
Aaaarrgggg
May 22, 2013 at 7:10 pm
My last company had a yearly requirement to do a "full" DR test. Luckily we had our own offsite DR location so we could do unofficial testing. We also replicated our drives and did our tape backups off the replicated drives. So we had to mount them up every Friday, but didn't attach the databases.
So I could get the databases attached and ready to go in about two hours. (Other non-DBA IT staff took about 4-6 hours off my checklist.)
As far as applications --the hardest one was actually MS's Great Plains to get going. We had to reset every test user's password by hand.
And luckily my managers understood the HA/DR difference. Our primary site were sets of two node clusters where we could do it.
The ability scale out, or spread load are a possibility with a few of these features.
My question is still how to scale out SQL. It never seemed that MS designed the system for multiple access to a DB. So while you can scale up the web servers or number of clients, you are restricted by the controlling instance. I admit I've been out of touch with mainline general production support as I have been supporting my companies SW product which doesn't do well with advanced SQL options.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
May 23, 2013 at 2:39 am
Bring out the Chaos Monkey!
http://thenextweb.com/insider/2013/03/03/how-your-business-could-learn-from-chaos-monkey/
I'm sure you all know about him, but I just love the name.
May 23, 2013 at 4:10 am
Great article, Chaos Monkey went opensource
May 23, 2013 at 5:52 am
ssimmons 2102 (5/22/2013)
MY worst DR story was from 15+ years ago. Had a server failure at about 5 pm at night before the backups occured. All data changes for that day were lost. My boss and I literially dumpster dived to retrive all the "Red Marked" paperwork that was entered that day.
Major mismatch between IT and manual processes. I bet it was only realised how obvious a gap there was with the ol' 20-20 hindsight.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 23, 2013 at 10:54 am
Jim P. (5/22/2013)
My question is still how to scale out SQL. It never seemed that MS designed the system for multiple access to a DB. So while you can scale up the web servers or number of clients, you are restricted by the controlling instance. I admit I've been out of touch with mainline general production support as I have been supporting my companies SW product which doesn't do well with advanced SQL options.
It has to do with architecture. SQL Server was never built to scale out, with a few exceptions. Distributed Partitioned Views can scale out, but not with redundancy. AlwaysOn is a start as well, though with a single write area.
Some of the Azure technologies are looking at scaling out, essentially by putting multiple databases to work for an application.
May 23, 2013 at 10:55 am
call.copse (5/23/2013)
Bring out the Chaos Monkey!http://thenextweb.com/insider/2013/03/03/how-your-business-could-learn-from-chaos-monkey/
I'm sure you all know about him, but I just love the name.
I wish more people would do this. Really it's more that management would agree to allow it.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply