Both Oracle and SQL Server offer several ways to support disaster recovery scenarios. One of the simplest ways to handle DR in the SQL Server world is to use SQL Server log shipping. Oracle doesn't offer log shipping as a part of the core product, but it's possible to set up log shipping in Oracle.
As a DBA, you're responsible for identifying necessary updates to keep your SQL Servers healthy. Your business may have some mandates about the frequency of patches, but even if they don't, you have a duty to look out for Cumulative Updates, Service Packs, and out of band hotfixes that can prevent downtime and prevent performance problems. It's your task to test and apply them as needed.
Will a long running open transaction block you from changing to synchronous mode and failing over to your SQL Server database mirror? Join Kendra to test performing a planned failover from an asynchronous database mirror.
http://youtu.be/5rAr2Gns1mU
I'm a fan of SQL Server's transaction log shipping. It works in Standard Edition, it's relatively simple to set up, and you can even make your log shipping secondary readable using STANDBY mode.
I've worked with some pretty cool, complex log shipping environments over the years. In one case, we had multiple log shipping secondaries and a load balancer involved to support a full fledged reporting application. It worked pretty well-- with a lot of careful scripting and support.
If you're using AGs, don't apply these patches:
SQL 2012 SP2 CU3
SQL 2012 SP2 CU4
SQL 2014 CU5
SQL Server 2012 introduced AlwaysOn Availability Groups, a way to achieve high availability, disaster recovery, and scale-out reads. SQL 2014 brought some improvements around higher uptime and more scale-out, and all signs point to continued improvements in the next version of SQL Server, too. (I love it when Microsoft brings out features like this and continues to invest in them over time.)
Let's say you're a DBA managing a 2TB database. You use SQL Server transaction log shipping to keep a standby copy of the database nice and warm in case of emergency. Lots of data can change in your log shipping primary database: sometimes it's index maintenance, sometimes it's a code release, sometimes it's just natural data processing.
Amazon Relational Database Service (RDS) now supports multi-availability-zone SQL Servers. This means you can have a primary database in one data center, and a secondary replica in another data center.
When your primary server goes down, OR when the entire AZ goes down, you can fail over to the secondary with zero data loss and keep right on going. When the primary comes back online, you can fail right back, again with no data loss.
SQL Server DBAs are slow to adopt Windows Server 2012 and Server 2012 R2. I frequently find teams planning new implementations of SQL Server 2012 on Windows Server 2008 R2.
There seem to be two main reasons for this:
In theory, you can add indexes online with SQL Server Enterprise Edition.
In theory, with AlwaysOn Availability Groups, you can add and drop indexes on the primary replica whenever you want.
Time for a thought exercise.
You've got a database application that has bursty and unpredictable loads. Out of nowhere, you'll suddenly get socked with a large amount of SELECT queries. Due to the way the app is written, you can't cache the query results - the queries keep changing, and the business wants data from within the last couple of minutes.
The latest version of sp_Blitz® alerts you if you haven't been using the WITH CHECKSUM parameter on your backups. This parameter tells SQL Server to check the checksums on each page and alert if there's corruption. But what about corrupt backups? Books Online says: NO_CHECKSUM - Explicitly disables the generation of backup checksums (and the validation…
Back in 2009 (wow, seems like only yesterday!), I wrote about designing a recovery strategy for Stack Overflow. Back then, I wrote: With these answers in mind, Stack Overflow’s decisions not to do transaction log backups, offsite log shipping, database mirroring, and so on make good business sense. Us geeks in the crowd may not like it,…
Imagine this: you have a database, and it’s on a SQL Server instance, which is on a server. That server may be physical or it may be virtualized. The database, or the instance, or the server, has a high availability solution implemented. It might be failover clustering; it might be synchronous mirroring; it might be VMware HA.
Our live webcast topic this week was Q&A - you could bring any HA/DR questions, and we could avoid your answers. Just kidding. Here's the webcast - we apologize for the audio, WebEx is still getting their act together. It cleans up after the first couple of minutes.
https://www.youtube.com/watch?v=G1URY5M09ic
You’d love to know how to make your SQL Servers more highly available, but you’re just not sure what “clustering” is all about. We can help! In this 30 minute video Kendra Little shows you how failover clusters make your SQL Servers easier to manage. She uses diagrams and drawings to teach you the strengths and weaknesses of failover clusters and shows why clustering is becoming even more critical for high availability and disaster recovery.
Business is booming; the sales team is bringing in more business and the software developers are successfully scaling out at the web server tier. There are signs of pressure on the database tier and you realize that it's time to scale out. You're using SQL Server 2012, you need to improve performance, and the first thought that comes to mind is the new hotness: SQL Server AlwaysOn Availability Groups.
In our recent webcast on HA & DR basics for DBAs, we got a bunch of questions that couldn't be answered fast enough. Here you go:
I've been working with and talking about SQL Server Log Shipping a lot lately!
I've gotten a lot of great questions about log shipping, so I've put together an FAQ.
I served with High Availability. I knew High Availability. High Availability was a friend of mine. VMware HA, you're no High Availability.
See, for us database administrators, high availability means protection when:
