SQL Server Data Protection and High Availability Anil Desai.
-
date post
19-Dec-2015 -
Category
Documents
-
view
230 -
download
1
Transcript of SQL Server Data Protection and High Availability Anil Desai.
SQL Server Data Protection and High Availability
Anil Desai
Speaker Information
• Anil Desai– Independent consultant (Austin, TX)– Author of several SQL Server books– Instructor, “Implementing and Managing SQL
Server 2005” (Keystone Learning)– Info: http://AnilDesai.net or [email protected]
Overview and Agenda
• Overview of Data Protection and HA
• Backup and Recovery
• Log-Shipping
• Database Mirroring
• Database Snapshots
• Clustering Overview
Data Protection and HA Goals
• Minimize data loss
• Minimize costs
• Minimize performance overhead
• Simplify implementation and administration
• Allow fast fail-over
• Implementing transparency for end-users
Implementing Backups
• Features– Minimal performance hit– Flexible options
• Purposes– Protecting against user error– Protecting against hardware failures– Disaster Recovery, Security, Archival– Regulatory Compliance
Planning for Backups
• Backup plan should be based on recovery requirements
• Factors:– Type of data / workload– Acceptable downtime– Acceptable data loss– Performance requirements– Administration overhead (manageability)
Database Recovery Models
• Balances performance vs. recoverability
• Recovery Model Options:– Full
• All transactions are logged
– Simple• Does not allow for point-in-time recovery• Automatic log truncation
– Bulk-Logged• Bulk operations are not logged
Backup Types
• Full Backups
• Differential Backups
• Transaction Log Backups
• Other Types:– Copy-Only Backups– Partial Backups– File Backups
Restore / Recovery Process
• Restore order: 1. Full backup
2. Latest differential (if any)
3. Chain of transaction log backups• NO RECOVERY / WITH RECOVERY
Restore / Recovery Example
Restore vs. Recovery
• Restore– Copies data from backup media– Applies committed and uncommitted
transactions (“roll forward”)– Uses NORECOVERY clause (DB = offline)
• Recovery– Rolls backup uncommitted transactions (“undo”)
– Brings database online
Database Restore Options
• Full database restore– Point-in-Time recovery / STOPAT Marker
• File restore
• Page-level restore
• Partial / Piece-meal restore (Ent. Ed.)– Restore read-write filegroups (PARTIAL)– Bring database online– Restore read-only filegroups
Backup and Recovery Commands
• Transact-SQL– BACKUP DATABASE– RESTORE DATABASE / RESTORE LOG
• Database Maintenance Plan Wizard
• Copy Database Wizard
• Attach / Detach databases
Backup and Recovery Notes
• Backup history is stored in msdb
• Can use media sets and families
• Security: May need to recreate logins, certificates, etc.
• Can backup to UNC shares
Log Shipping
• Maintains a “warm” standby server– Update interval can be configured– Requires Full or bulk-logged recovery model
• Relies on backup/recovery operations
• No special hardware requirements
• Can have multiple secondary databases
• Roles: – Primary, Secondary, Monitor
Log Shipping Details
• Continuous restore of transaction logs
• Process:– Transaction log backup is created on the
primary server– File is copied to the secondary server
• Log is restored on the secondary server – NORECOVERY (database remains offline)– STANDBY (database is read-only)
Implementing Log Shipping
Log Shipping Tool
• Setup from SQL Server Mgmt. Studio:– Prepare the Primary Database– Implement a Monitoring Server– Initialize the Secondary Database– Copy Files– Security Settings / Proxy Accounts– Can schedule the frequency of backup and recovery
operations– Create all required jobs
Managing Log Shipping
• Avoid manual backups (except copy-only)
• Log-Shipping information (msdb database)– Primary Server (backup details)– Secondary Server (copy and restore details)– Monitor Server (info about both)
• Transaction Log Shipping Report (SSMS)
Performing a Fail-Over
• Steps for failing-over:– Disable all log shipping jobs– Primary Database: Backup and copy transaction log
files (if possible)– Restore transaction log backups on the secondary
server with NORECOVERY• Use RECOVERY for last restore
– Re-establish log-shipping (optional)
• Swapping primary and secondary roles– Can be performed by enabling/disabling jobs
Understanding Database Mirroring
• Maintains a “hot” standby database– Synchronization is managed automatically– Transactions are sent from a Principal to a Mirror
database instance
• Can perform quick fail-over– Can be automatic or manual– Clients are automatically redirected
• Works at the database level– Multiple mirrored pairs per server are possible
Database Server Roles
• Principal Database– Active, Read/Write database– Requires the full recovery model
• Mirror Database– Must be on a separate SQL Server instance– Set in “Restoring” state– Can use snapshots to allow read-only access
• Witness (optional)– Used for establishing a quorum during automatic
failover– Not recommended for High-Protection mode
Database Mirroring Support
• SQL Server 2005 Standard and Enterprise Ed.– Witness can be SQL Server 2005 Workgroup or
Express Editions– For production, should use SP1 or later
• For SQL Server 2005 RTM:– Must enable Trace flag 1400 – -T1400 startup parameter– SQL Server Configuration Manager Advanced
Startup Parameters
Database Mirroring Modes
• Asynchronous (High Performance)– Principal transactions commit without waiting for
mirror– Some transactions may be lost
• Synchronous– Transactions must be committed at mirror– Ensures no data loss– High Protection
• No Witness server / manual fail-over– High Availability
• Uses a Witness server; automatic fail-over
Implementing Database Mirroring
• Database Mirror Pairs are independent– Each set requires own ports– Can use different modes– One server can serve as principal, mirror, and
witness for different mirroring pairs• Steps:
– Back up the Principle database– Restore the database on the Mirror instance with
NORECOVERY– Configure Mirroring endpoints and security– Enable Mirroring
Implementing Database Mirroring
• Configure Database Mirroring Security Wizard– Can include Witness Server– Configures Mirroring Endpoints– Service Accounts
• SQL Server Management Studio– Allows starting, stopping, and fail-over
operations
Database Mirroring Commands
• ALTER DATABASE can be used to administer database mirroring
• Setting the Mirroring Mode:– Asynchronous (High Performance):
• SET SAFETY OFF
– Synchronous• High Availability: SET SAFETY FULL• High Protection: Use SET WITNESS
• Pausing: SET PARTNER SUSPEND/RESUME• Cause fail-over: FAILOVER
Forcing a Fail-Over
• Should be used in emergencies– Use when mirror is out-of-date– May cause data loss– If Witness is available, it must be able to
contact the mirror server
• ALTER DATABASE … SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
Monitoring Database Mirroring
• SQL Server Management Studio– Database Mirroring Monitor
• System Views / Stored Procedures– Sys.Database_Mirroring – Sys.Database_Mirroring_Endpoints– Sys.DM_DB_Mirroring_Connections– Sp_DbmMonitorResults
• Other options:– SQL Server Agent Alerts– Windows Event Logs– Windows System Monitor
Database Snapshots
• Snapshots:– Creates a point-in-time view of a database– Multiple snapshots can be created– Quick to create / Requires minimal disk space– Snapshots are read-only– Databases can be reverted to a snapshot– Stored on same instance as database
• Can be accessed like a “regular” database
Understanding Snapshots
• Available in the Enterprise Edition• Supports all recovery models• Typical Uses
– Reporting– Point-in-Time Views / Historical Views– Protecting against user error– Testing
• Should not be used as a backup or high-availability solution
• Can be created on a database mirror
Snapshot Architecture
• Initial snapshot creation– Generates an NTFS Sparse File– File is initially empty
• Snapshot maintenance– Monitors for changes to data pages– Uses copy-on-write method– Snapshot files will grow based on frequency
of data modification
Creating Database Snapshots
• Creating a new snapshot:CREATE DATABASE ON
(NAME = LogicalName, FILENAME = PhysicalFilePath)
AS SNAPSHOT OF SourceDatabase
• Recommendations:– Use a consistent naming scheme– Treat snapshots like read-only databases
Managing Snapshots
• Dropping snapshots– Deletes sparse files– DROP DATABASE SnapshotName
• Reverting to a snapshot– Restores a database to the time of the snapshot
– Snapshot and primary database will go offline– RESTORE DATABASE DatabaseName FROM DATABASE_SNAPSHOT = SnapshotName
Monitoring Snapshots
• SQL Server Management Studio– Databases Database Snapshots
• System Databases– Sys.Databases– Sys.Database_Files– Sys.Master_Files
• Viewing File Details– Windows Explorer / DIR command
• File size vs. “Size on Disk”– fn_VirtualFileStats
Clustering Overview
• SQL Server Fail-Over Clusters: – Provides automatic fail-over– Multiple nodes that work as a logical unit– Uses a shared-disk configuration
• Does not protect against disk failures
• Requirements– Enterprise Ed. and specialized hardware– Distance limitations
• More difficult to implement and administer
Data Protection and HA Summary
• Backup and Restore– Standard data protection
• Log-Shipping– Harder to implement, but more flexible– Manual fail-over
• Database Mirroring– Easy to implement and manage– Automatic fail-over
• Clustering– Custom hardware requirements
For More Information
• Resources from Anil Desai– Web Site (http://AnilDesai.net)– E-Mail: [email protected] – Keystone Learning Course: “Microsoft
SQL Server 2005: Implementation and Maintenance (Exam 70-431)”
– The Rational Guide to Managing Microsoft Virtual Server 2005
– The Rational Guide to Scripting Microsoft Virtual Server 2005