1. Are You High? Can You Recover?
Rob Douglas
Client Services Manager
SQL Services Ltd
Before we start, here’s some messages from our sponsors…..

2. Definity is in February next year
Definity is in February next year. If you get value out of today, check out Dfinity.

3. HouseKeeping SESSIONS EVENT Mobile Phones
please set to “stun” during sessions
Submit your tickets for raffles by 3:30pm/
Evaluations
complete online to be in the draw for fantastic prizes
Wifi Details
Login: Password:
SESSIONS
EVENT
sessions/sessionevaluation.aspx
eventeval.aspx

4. Thank You
This FREE SQL Saturday is brought to you courtesy of these sponsors, speakers and volunteers who staff this event

5. Are You High? Can You Recover?
Rob Douglas
Client Services Manager
SQL Services Ltd
First let’s talk about what I’m not going to talk about.
Any virtual level solutions are not going to be covered in this talk.
Also any system state backups or snapshotting technology.
fancy SAN level replication
any third party applications.
We’re also not going to talk specifically about cloud technologies

6. The Christchurch Earthquakes
Citywide destruction.
Power loss nearly everywhere.
Internet and cell networks down
Physical Access to servers restricted or denied.
Loss of Life
Loss of jobs, buildings and business.
Limited preparation for the scale of disaster.
The reason that I am going through this is because I want to present the scale of the disaster, and make you aware of the impact that it has not just on your infrastructure, but also on the things that underpin your infrastructure. That includes the people who are charged with keeping your business up and running.
Are you High? Can you Recover?

7. High Availability\Disaster Recovery
Recovery Time Objective(RTO)
Recovery Point Objective(RPO)
What Disaster? (Documentation)
of the servers, or sites we audit, probably half don’t have a defined RTO and RPO, probably more than that – maybe 70% where there has never been a DBA.
Don’t put yourself in an awkward position. Let’s say the data is recovered in 30 minutes. Is that good or bad
Let me illustrate that for you. What’s the difference between 95% uptime and % uptime? No prizes for saying 4.999%. Over the course of a year 95% uptime allows for your server to be offline for over 18 days. Five nines allows only 5 minutes of downtime. In a year!
It’s so important that the numbers are agreed on and documented, because that is what you can then work to. And that is what you will be held accountable to when you miss. That same documentation should include a few other things.
What Disaster are we talking about?
Who decides when to invoke DR or HA?
Who is responsible for which piece of the Availability puzzle? And who is their backup?
Are you High? Can you Recover?

8. What Are The Options? Native SQL solutions: Clustering
Synchronous Mirroring
Replication
Asynchronous Mirroring
Availability Groups
Log Shipping
Not talking about:
SAN Replication
VM level
Cloud
3rd Party Products
Are you High? Can you Recover?

9. High Availability Native SQL solutions: Clustering*
Synchronous Mirroring*
Replication*
Asynchronous Mirroring
Availability Groups*
Log Shipping
What these three technologies have in common is that upon failover they can failover automatically, and they can failover without losing data.
Are you High? Can you Recover?

10. Disaster Recovery Native SQL solutions: Clustering
Synchronous Mirroring
Replication*
Asynchronous Mirroring*
Availability Groups*
Log Shipping*
Are you High? Can you Recover?

11. Backups Take regular backups Test your backups Is this HA\DR?
What to backup?
intrinsically baked into the engine
the MINIMUM that you should be implementing as part of your recovery strategy.
You know what a backup plan is that hasn’t had the backups tested? A prayer. It’s a theory that you are covered
blog post by Anthony Bartolo about a DBA who thought he had his backups under control
Pick a date you think you can restore to – and go and walk through the steps to do so.
So you’ve got a backup of your big production database?
Have you backed up
the system databases?
the logins
SQL Agent jobs
Linked servers documented,
SSIS packages?
trace flags?
Your as-built documentation should be of sufficient depth that it could be handed to a competent DBA and they could rebuild the server from it to a functional state. Many of the pieces of that puzzle sit outside your production database, so have a look at the other things you are backing up and make sure it gives you all the tools you need to rebuild the server exactly as it is now.
Are you High? Can you Recover?

12. Log Shipping
Log Shipping is the automating of a backup restore process.
Can log ship to multiple targets.
Including the same server the original database is on.
Can restore a database to a readable state.
No Automated Failover.
an incredible amount of versatility.
multiple targets
put in a load delay.
Why would you do that?
There’s an important gotcha though.  Firstly log shipping relies on your recovery chain being intact.  If someone takes a single log backup that isn’t available to the secondary then logshipping is going to break.  Remember that log shipping is just the process of going through a regular restore.  If you lose a log backup out of your regular recovery chain then you can’t restore further.  Of course, personally I’d prefer find out some rogue 3rd party application is taking random log backups by log shipping falling over than in a live disaster situation.  Setting up log shipping has actually revealed exactly this issue on more than one client site I’ve dealt with.
Are you High? Can you Recover?

13. Clustering 2(or more) sets of hardware Single set of disks
Standard Edition allows for an Active-Passive Cluster
the active directory level – a cluster name, some IP addresses and a handful of permissions. 
there is a single set of data
have a virtual instance name. 
touch on multi-datacenter clusters.
Patching
Are you High? Can you Recover?

14. Mirroring Redo every insert,update and delete on another server.
High Safety – Synchronous
High Performance – Asynchronous
Synchronous allows for automated failover(requires witness)
Increases Availability.
Only failover one db at a time. No automatic failover.
Asynchronous requires Enterprise licensing.
set up at the database level.  
redo-ing every insert, update or delete that happens on the principal server on another server. 
having two copies of the data which are pretty close
a witness server. 
So does your backup check to see if the database is online before it kicks off, or does it just fail?
Enterprise version….you can also have Asynchronous mirroring. 
  So….it seems like this is worse right? 
report off the mirrored databases. 
– Mirroring is deprecated. 
Reporting – You can create a snapshot of the mirror database and report off that.
Are you High? Can you Recover?

15. Always On Availability Groups
Mirroring on steroids(with some clustering thrown in).
Requires Windows Cluster
Multiple Replicas
2012 – 4 Secondaries.
2014 – 8 Secondaries
Replicas can be readable.
multiple databases for same application
Multiple replicas
Readable replicas
Multi datacenter
Multi continental
Allows azure replica
Are you High? Can you Recover?

16. Replication Can be both HA or DR, or both, or neither.
Highly customizable
Schema compatibility(change table on one location – boom)
More of a business case thing. Why do you need it.
Only HA\DR which allows different indexing options.
Firstly it doesn’t give you complete protection of a database.
Second objection – data loss is possible and you don’t know what you lose in a crash
Thirdly – There is no automated failover
replication is complicated and doesn’t report errors well. That’s true….but if you set up an Availability group from scratch you have to configure a cluster, you have to set up active directory permissions, you need to play with IP addresses and look at error logs in three different places. That can get pretty complicated too. Complicated is not an objection to HA\DR…you know what is? RTO and RPO, and if you can configure replication to meet your RTO and RPO requirements I’m happy for you to call it high availability or disaster recovery.
Are you High? Can you Recover?

17. So Which HA\DR Strategy is Best?
It depends.
Choose or combine the strategy that is right for you and your environment.
Scope your requirements
Implement an appropriate solution
Document the solution
Test it works
Are you High? Can you Recover?

19. Thank You
This FREE SQL Saturday is brought to you courtesy of these sponsors, speakers and volunteers who staff this event