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

Definity is in February next year Definity is in February next year. If you get value out of today, check out Dfinity. http://difinity.co.nz/

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 http://www.sqlsaturday.com/571/ sessions/sessionevaluation.aspx http://www.sqlsaturday.com/571/ eventeval.aspx

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

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

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?

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 99.999% 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?

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?

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?

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

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?

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?

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?

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?

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?

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?

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?

http://difinity.co.nz/

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