3. The environment
• OLTP/ DW?
• Availability? 24x7?
• Data loss and SLA?
• Local/hosted?
• SQL Server version and edition?
• Storage?
• Number of databases?
• Sizes of databases?
• Volume of transactions?
• Volume of reports?
• Backup strategy?
• Etc…
4. Problems?
• Performance issues
• Locks/blocks/deadlocks
• Application timeouts
• Backups failing
• Data updates VS reports
• Fragmented indexes
• Previous Database corruption
• Restore took too long
• Application bugs causing logical
corruption
• Long downtime on maintenance
10. Backups strategy for DR
• How long is the restore?
• Where are the backup files?
• What’s the affordable downtime?
• How much data loss is acceptable?
11. Log Shipping
• Replica of the entire database
• Synchronized to X minutes ago
• Backup and restore the t-logs
• Secondary can be:
– Read-only
– In recovery mode
12. Log Shipping - Pros
• Verification of production backups
• Lag to protect from accidental changes
(ex: protection during monthly/weekly
releases)
• Any change in DB is replicated
automatically, including DDL
• Multiple secondaries are allowed
• Read-Only replica
– Good for reporting
– Data can be read at standby server when DB is not
restoring
– CHECKDB, Fragmentation checks on secondary
13. Log Shipping - Cons
• X minutes data loss
• No automatic failover (can be automated)
• No easy failback (Log Shipping needs to be
recreated)
• DB Corruption may be replicated
• Database level replication, not instance
• T-log backup files can be large if there is a high
volume of transactions
• Database needs to be in FULL recovery model
• Same SQL Server version for read-only replica
• Users will be disconnected on DB restore
– Automatically
– Not automatically
• No particular indexes can be created for the
reports
14. Database Mirroring
• Replica of the entire database
• Synchronization
– Synchronized (High Safety)
• With or without a witness
– A-synchronized (High Performance)
15. Database Mirroring - Pros
• Real-time or close-to-real-time replica
• Any change in DB is replicated
automatically, including DDL
• Can implement Database Snapshots on
replica for reporting
• Corruption not being replicated
– SQL 2008+ page corresponding to a corruption is
retrieved from the replica/mirror and repaired,
transparently
• Easy failover and failback
• Automatic failover with a witness
– Faster failover than Clustering
• Reference to secondary instance in
connection strings
16. Database Mirroring - Cons
• Secondary cannot be used for reporting
– Can use Database Snapshot
• Sensitive to network bandwidth
– And volume of transactions
• A-synchronous mode - only in ENT Edition
• Witness - only in ENT Edition
• Deprecated in future releases
• Replication on the database level, not
instance
• Only one mirror allowed per database
• A bit more complicated if instances not in the
same network or Domain
17. Database Snapshot
• Static read-only copy of the
database
• Snapshot file grows when pages
modified
• On same instance as the original
database
18. Database Snapshot - Pros
• Great for reporting
– Non real-time data
• Great for DR
– Non real-time data
• Can be created on a mirrored replica
• Corruption will be kept if at page-level
• Created in less than a second
• Read –only operations such as DBCC or
index fragmentation
• Can be backed up
19. Database Snapshot - Cons
• Non real-time data
• Requires maintenance
– Multiple snapshots
– Add and remove
• Databases cannot be dropped if there is a
snapshot
• Snapshot cannot be dropped if there are
users
• No particular indexes can be created for
the reports
20. Replication
• Object-level replication
– Row level
– Column level
• Three types
– Snapshot
– Merge
– Transactional
• With updatable subscribers
• Peer-to-peer
• Transaction being replicated
21. Replication - Pros
• Partial replication
– Saving space and time
– Security
• Possibly different schema and different
indexes on secondary
• Great for reporting, users not disconnected
• Corruption not transferred
• Can configure a lag, protecting from
accidental data changes
• Secondary database can be backed up
22. Replication - Cons
• Management and troubleshooting
complexity
• All replicated tables require a Primary Key
• Database level replication, not instance
• More physical hardware required with
heavy IO throughput
• Some latency, possible data loss
23. Cluster
• Instance-level HA/DR
• High Availability with local cluster
• Plus Disaster Recovery with Geo-
Cluster
• 2 or N+1 nodes, M instances
• One instance can failover to different
nodes
• SQL Server has one virtual name
24. Cluster - Pros
• Failover transparent to applications
• Automatic failover on hardware or
OS failures
• Fast failover (only service restart)
• Easy upgrades and patches
• Can add nodes seamlessly
• Manual failover (ex: performance
reasons)
25. Cluster - Cons
• No protection from disk failure
• Only 2-node cluster for Standard
Edition
• More maintenance than a stand-
alone
• More expensive than a stand-alone
• There is no replica of the database
for reporting
26. Always
OnAvailability
Groups
• A mix of Failover clustering and
Database Mirroring
• Does not require shared storage
• Instances are not clustered
resources
• Database level replication
• Group of databases failing over
together
• Read-only or non-readable replicas
• Automatic failover
• Different sync modes
• Different failover rules
• Built-in Load balancing
27.
28. Other solutions – not SQL Server,
not Azure
• VM replication
• SAN or storage replication
• 3-rd party tools
• Etc….
29. Architecture design – so far
Be creative….
Node A Node B
Instance A
Node N
Instance B
Passive
Instance C
Cluster
31. Other solutions – for Azure VMs
• Service healing for cloud services and
Failure recovery detection for the Virtual
Machines
– keep VM available even when there are problems
– VM proactively moved to new nodes
– VM may restart
– IP address of the VM does not change
• Azure Site Recovery
– Hyper-V replication
• Geo Redundant Storage (GRS) for
Windows Azure
– Locally or zone redundant
– Three copies of your data
– http://blogs.msdn.com/b/windowsazurestorage/archive/2011/09/15/in
troducing-geo-replication-for-windows-azure-storage.aspx