Download slidedeck - Mindy Curnutt

SQL Server
Disaster
and
Click
to edit
MasterRecovery
title style
High Availability Options
Click to edit Master subtitle style
2
Objectives
 To Explain Disaster Recovery (DR)
 To Explain High Availability (HA)
 To Explain the different Microsoft Tools
available for DR and HA
3
Disaster Recovery
 What is it?
– Well documented steps, tried and tested,
which expedite the restoration of the
production database after a disaster strikes.
 What kind of Disasters?
– Server Hardware Failure
– Site Disaster (hurricane, flood, earthquake…)
– Malicious or accidental alteration or deletion
of data
4
DR Design Considerations
 How critical is the data to your core
business?
– Loss of Data (reenter)
– Loss of Access to Data
• System unavailable
• Lost data unavailable
 Budget
 Often ignored until too late!!
5
Disaster Recovery Options
 Database Backups
 Log Shipping
 Transactional Replication
 Synchronous Mirroring
6
Backups
 Type of Backups
– Full
– Differential
– Transaction Log
 Databases to Backup
– System Databases
– User Databases
Full Backups
7
 Nightly
 Not to the same disk as the SQL Data or
Logs
– Performance
– Safety
 3 days readily available (onsite)
 Weekly copy offsite for 12 weeks
 Monthly copy offsite for months 4-12
8
Differential Backup
 Differential Backup
– All changes since last Full Backup
9
Transaction Log Backup
 All changes since one of the following
– The last Full Backup OR
– The last Differential Backup OR
– The last Transaction Log Backup
 The act of completing a transaction log
backup “clears out” the transaction log
and prevents it from growing excessively
large
Restore from Backup Example
10
12am
6am
7am
8am
9am
10am
11am
12pm
1pm
2pm
3pm
4pm
5pm
6pm
Full Differential Transaction
Backup Backup Log Backup
30GB
40MB
200MB
200MB
200MB
200MB
200MB
1GB
200MB
200MB
200MB
8MB
Stops Table Accidentally
Dropped at 3:06pm
Take a Final MANUAL Transaction
Log Backup -- “The Tail of the Log”
Full
Backup
Diff
Backup
Tran
Logs
Specify Restore to 3:04pm! 
Database Backups
11
 Closely Monitor
 Document Restoration
 Regularly Rehearse Restoring
 Revise Procedures when major changes to
database
– Upgrade
– Change of Backup Freq/Type
12
Log Shipping
 Automates backup and restore of
transaction logs to another server.
 Second server is “in synch” with the first
 Creates a WARM STANDBY
13
Benefits of Log Shipping
 Doesn’t require expensive hardware
– Can use a lower end server
– Standby server can perform other duties
 Easy to setup & maintain (wizards)
 Very reliable
 All versions of SQL 2005 except Express
 Manual failover is typically 15 minutes or
less (if documented & practiced)
14
Downside to Log Shipping
 Failover is not automatic
 Some data can be lost
 Requires 2 SQL Licenses
 Must manually keep logins & jobs in synch
with periodic updates
Example Scenario
15
 Organization uses SQL Server 24/7
 In case of disaster, system should be back
up within 30 minutes
 Extra hardware available to have a “warm
standby”
Example Solution
16
 Production Database in Full Recovery
Mode
 Full Backup at 11pm Daily
 Differential at 11am Daily
 Transaction Log every 15 minutes daily
 Warm backup database setup on extra
server in separate location (via WAN)
 Log shipping
17
Example Solution
 Document and Practice
– Rename the Windows Server
– Rename the SQL Server
– Reassign the IP Address
 Solves these issues:
– Hardware Failure
– Site Disaster
 What about Malicious or Accidental Data
update/deletion?!
18
Transactional Replication
 Involves a Publisher and a Subscriber
 Automates the transactional “synching” of
the subscriber database with the publisher
 Creates a HOT STANDBY (subscriber)
 Subscriber can be used for reporting
 Subscriber database can differ from
publisher
19
Transactional Replication
 Available in SQL 2005 Standard and
Enterprise Editions Only, not Workgroup or
Express
 Publisher, Distributor and Subscriber are
databases, not servers.
 Don’t have to be on separate servers, but
usually the Publisher and Subscriber are –
otherwise this is NOT a DR solution.
20
Transactional Replication
• Maintains source
DBs
• Makes Data avail
for Replication
Publisher
Distributor
• Stores metadata,
history and data
changes
• Forwards changes
to Subscriber
• Receives data
changes
• Holds copy of data
Subscriber
21
Benefits of Tran Replication
 Database is available
 Near real time data
 Read-write activity is supported
 Very reliable
 Manual failover is typically 15 minutes or
less (if documented & practiced)
22
Downside to Tran Replication
 More complicated to configure than Log
Shipping or Backup/Restore
 Some maintenance involved for changing
schemas in the database
 Failover is not automatic
 Must manually keep logins & jobs in synch
with periodic updates
 Requires 2 SQL Licenses
23
Synchronous Mirroring
 Involves a Principle, a Mirror and a
Witness
 Automates the transactional “synching” of
the principle server with the Mirror
 Failover is automatic and very fast
 Witness helps to decide when to failover
 Creates a HOT STANDBY (mirror)
24
Synchronous Mirroring
 Must have Enterprise Edition to do
snapshots (reporting) from Mirrored
database
 Requires 3 instances of SQL Server to
enable automatic failover
 Software connection methodology must
support Mirroring Auto Failover
(.Net 2.0 “Failover Partner” Property)
 Can do manual failover with just 2
instances
Synchronous Mirroring
How it works
Application
Witness
Mirror is always
redoing – it
remains current
Commit
Principal
Mirror
1
5
2
SQL Server
2
Log
>2
Data
SQL Server
4
3
Log
>3
Data
26
Benefits of Synchronous Mirroring
 Near real time data
 Very reliable
 Automatic Failover is possible
 Manual Failover is also an option
 Can use snapshots for offloading close to
real time reporting
 Multiple snapshots can be generated from
one database
Downside to Mirroring
27
 Snapshots provide read-only access to the
data
 Snapshots create an overhead on the
server that can negatively impact
performance
 Most applications on the market have not
been written to take advantage of auto
failover with mirroring
High Availability
28
 Keep the database as available as possible
– Upgrades/Service Packs to OS/SQL Instance
– Server Reboots
 Non Disk or Database related failure ONLY
– Motherboard
– CPU
– RAM
 Not meant for recovering from a Database
Disaster.
Failover Clustering
29
 Hot Standby – Automatic failover
 Transparent to the Application
 Instance Failover – entire instance works
as a unit
 Single copy of instance databases
 Standby is not available for reporting,
queries, etc.
– May support other instances
30
Failover Clustering
 See handout 2
31
What Failover Clustering is NOT
 Clustering is not a mechanism to scale
 Doesn’t protect your server against site
outage
 Doesn’t protect your disk subsystem
– You use RAID for this!
 Doesn’t protect against database
corruption
 Doesn’t protect against logical corruption
32
What Failover Clustering is NOT
 Doesn’t protect against user error
 Clustering is not a method to load-balance
Still a single point of failure – The Database!
Handy References with Screenshots
33

Setting up Log Shipping
http://www.mssqltips.com/tip.asp?tip=1158

Setting up Transactional Replication
http://www.mssqlcity.com/Articles/Replic/SetupTR/Setup
TR.htm

Setting up Mirroring
http://bradmarsh.wordpress.com/2008/07/09/completeguide-to-sql-2005-mirroring-using-the-gui/

Setting up Windows & SQL Clustering
http://www.sql-serverperformance.com/articles/clustering/cluster_server_2003
_p1.aspx
34
SQL Server Consulting Services
 Performance – Basic Assessment
 Performance – Full Assessment
 Maintenance Plan Review
 Hardware Selection
 Architectural Design
 Environment Upgrade
35
Question and Answer Time
Contact Info
Mindy Curnutt
Senior Database Architect
TMW Systems, Inc.
216.831.6606 x 2819
214.923.7419
[email protected]
Ron Kost
Sr. System Analyst
TMW Systems, Inc.
216.831.6606 x 2224
[email protected]
For more information:
Visit the TMW booth in the Vendor Hall