2014/05/06

Smith Yang

Agenda
1. MS SQL Server HA
Introduction
2. AlwaysOn
3. Replication
4. Log-Shipping
5. Q & A
2014/05/06
2
Microsoft SQL Server HA
Introduction to High Availability
High availability technologies help ensure the
continuation of service provision in the event of an
outage
High availability plans should include:
Hardware
Windows operating system
SQL Server instance
Individual databases
2014/05/06
3
Planning for High Availability with SQL
Server 2012
Key considerations
Service level agreements
Cost
Resource utilization
Choosing a SQL Server high availability solution
Unit of failover
Relative cost
Automatic failover
Automatic client redirection
Maximum number of replicas
Readable replicas
SQL Server edition
Options for High Availability in SQL 2012
Log Shipping Database Mirroring
Witness
Failover Cluster Instance
Passive Active
Availability Group
Windows Cluster Windows Cluster
Primary
replica
Active Secondary
replica
2014/05/06
4
Considerations for SQL Server HA and DR
7
http://msdn.microsoft.com/en-us/library/hh781257.aspx
SQL Cluster vs. AlwaysOn
8
Shared Disk Array
Windows 2008 R2 Failover Cluster
SQL Server
(Active Node)
SQL Virtual
Name
SQL Cluster SQL AlwaysOn
2014/05/06
5
SQL Cluster vs. AlwaysOn
9
SQL Cluster SQL AlwaysOn
Uses WSFC cluster Yes Yes
Protection level Instance Database
Storage type Shared Non-shared
Readable secondary No Yes
DR Site Replication Yes (need hardware
solution)
Yes
Database file One copy Multiple copies
Page Auto Repair No Yes
SQL Cluster Network + Shared Storage (Risks and Urgent Cases)
SQL AlwaysOn Network (More stable and reliable)
Microsoft SQL Server HA
2014/05/06
6
SQL AlwaysOn
Virtual IP/Name
Introducing SQL 2012 AlwaysOn
SQL Server 2
(Replica)
SQL Server 1
(Primary DB)
Local Storage Local Storage
Windows 2008 R2 Failover Cluster
SQL Server 2
(Primary DB)
Application Servers
Introducing SQL 2012 AlwaysOn
2014/05/06
7
Legacy Architecture Change to AlwaysOn
Components of an AlwaysOn
Configuration
1. Windows Failover Cluster and Quorum Mode
A prerequisite. Each availability replica must reside on a different node of the same
WSFC cluster.
A separate WSFC resource group for every availability group
Unlike Traditional FCI, no shared storage
Unlike Traditional FCI, SQL Service is not part of resource group. Started on both
nodes
The WSFC cluster monitors this resource group to evaluate the health of the
primary replica
In contrast to database mirroring, there is no witness role in AlwaysOn Availability
Groups.
Careful : The quorum for AlwaysOn Availability Groups is based on all nodes in the
WSFC cluster regardless of whether a given cluster node hosts any availability
replicas. Quorum Mode of choice is Node plus File Share Majority.
2014/05/06
8
Components of an AlwaysOn
Configuration
2. Availability Group Listener
a virtual network name (VNN) to which clients can connect in order to access a database
in a primary or secondary replica of an AlwaysOn availability group. Only TCP protocol is
supported by an AG Listener.
consists of a Domain Name System (DNS) listener name, listener port designation
(Default 1433), and one or more IP addresses (if in multi-subnet config)
Listener is a resource in a cluster with an Associated VNN, VIP and AG dependency
If the primary replica goes offline on one instance of SQL Server, and a new primary
replica comes online on another instance of SQL Server, the availability group listener
enables clients to connect to the new primary replica.
If read-only routing is configured for one or more readable secondary replicas, read-intent
client connections to the primary replica are redirected to a readable secondary replica
Components of an AlwaysOn
Configuration
3. Database Mirroring TCP End-Points
used to communicate between the primary and the secondary replicas of the
availability group
If a second NIC is installed on the primary replica and secondary replica of an
availability group, that availability group can be configured to replicate mirrored
changes over the private network, isolating the availability group traffic.
Scenario
Configure endpoints to listen on private nic and Port 5022 (Default)
:CONNECT SQLNODE1
CREATE ENDPOINT [Hadr_endpoint] AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (192.168.1.20)) FOR DATA_MIRRORING (ROLE = ALL, ENCRYPTION =
REQUIRED ALGORITHM AES);
GO
:CONNECT SQLNODE2
CREATE ENDPOINT [Hadr_endpoint] AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (192.1681.21)) FOR DATA_MIRRORING (ROLE = ALL, ENCRYPTION =
REQUIRED ALGORITHM AES);
GO
Create availability group to connect to private NICs
:CONNECT SQLNODE1
CREATE AVAILABILITY GROUP [AG]
WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
FOR DATABASE [AGDB]
REPLICA ON N'SQLNODE1' WITH (ENDPOINT_URL = N'TCP://192.168.1.20:5022', FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE =
SYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO)),
N'SQLNODE2' WITH (ENDPOINT_URL = N'TCP://192.168.1.21:5022', FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
BACKUP_PRIORITY = 50, SECONDARY_ROLE(ALLOW_CONNECTIONS = NO));
SQLNODE1
Public = 172.16.0.20
Private = 192.168.1.20
SQLNODE2
Public = 172.16.0.21
Private = 192.168.1.21
2014/05/06
9
4. Commit Modes
Synchronous Commit Mode
For HA within same site
Before committing transactions, Primary replica waits for a
synchronous-commit secondary replica to acknowledge that it
has finished hardening the log
Comes at the cost of increased transaction latency.
Ensures that once a given secondary database is synchronized
with the primary database, committed transactions are fully
protected
Asynchronous Commit Mode
Usually used for DR Purposes
The primary replica commits transactions without waiting for
acknowledgement that an asynchronous-commit secondary
replica has hardened the log
Minimizes transaction latency but can allow data loss
Components of an AlwaysOn Configuration
Components of an AlwaysOn
Configuration
5. Availability Replicas (instances on which mirror DBs will reside)
Up to 5 replicas including Primary
Up to 3 Synchronous Commit Mode replicas including Primary
6. Failover Modes
Automatic Mode (with 2 Synchronous replicas Only) occurs automatically
on loss of primary replica
Planned Manual Failover (without Data Loss) for administrative
purposes. Supported when Primary and secondary are in synchronous
commit and in Synchronized State
Forced Failover (with possible Data Loss). Secondary replica not in
Synchronized state and not failover ready. Recommended strictly for
Disaster recovery. Only form supported by Asynchronous commit
7. Backup Preference Options
Prefer Secondary - Will backup on secondary with highest priority. If no secondary's
are available, it will backup on primary.
Secondary Only - Will backup on secondary with highest priority. If no secondary's are
available, no backups will occur.
Primary - Backups will occur on the primary only, whichever instance that happens to
be at the time of the backup.
Any Replica - Looks just at the backup priority and backups on the replica with the
highest priority.
2014/05/06
10
SQL 2012 AlwaysOn Architecture Example
19
HA (High Availability) Taiwan Site DR (Disaster Recovery) Europe Site
Data are synchronized replicate Data are asynchronized replicate
DB2 DB1
DB3 DB4
1. Join to the same Domain: TESTDOM
2. Enable Windows Cluster Services
Cluster Vote Modification
Taiwan Site Europe Site
1 1 1 1
Total Vote =4 Major Vote = 3
Total Vote =3 Major Vote = 2 , Europe doesnt vote (in case of network issue)
2014/05/06
11
Backup on Secondary nodes
21
SQL 2012 AlwaysOn Read-Only Routing
SQL Server 3
(Secondary)
SQL AlwaysOn
Virtual IP/Name
SQL Server 2
(Secondary)
SQL Server 1
(Primary)
Windows 2008 R2 Failover Cluster
Read-only
Routing Table
Read-only users
Possible to reroute Read-Intent Connections from Primary to replica
A client must use an application intent of read-only in the connection string when connecting to the availability group
istener.
Server=tcp:AGListener,1433;Database=AdventureWorks;IntegratedSecurity=SSPI;ApplicationIntent=ReadOnly
2014/05/06
12
AlwaysOnAvailability Group Installation Steps
High Level Overview
1. Create Cluster Nodes, each with local Storage for database Files and ensure latest OS
Patches have been Applied
2. Install Failover Clustering Windows Feature on both Nodes
3. Run Cluster Validation Wizard for nodes in question to assess suitability for cluster (Note
ignore Storage warnings it expects Shared Storage)
4. Create WSFC Cluster and Configure Quorum Settings (Node + FileShare Majority)
5. Install a standalone instance of SQL server on each node (default preferable)
6. Choose the same location for Database Files on each node
7. Install Latest SQL Server SP and cumulative updates
8. Enable AlwaysOnHADR - on each node, go into SQL Server. Configuration Manager,
Services, SQL Server Service, and on the AlwaysOntab, check the box for Enable HADR.
Click OK, and restart the SQL Server instance. Please note only do this once OS cluster has
been installed
9. Migrate your Databases to the Primary Instance in AG Cluster. Assuming Database pre-
requisites followed, the following steps can then be implemented to create the AlwaysOn
Group via either the SSMS Wizard, TSQL or Powershell
Add the instances you want the mirror replicas to be hosted on (must be nodes in the
WSFC Cluster)
Configure Commit Mode (Synchronous or Asynchronous Mode)
Configure Failover Mode
Configure Mirror Replica to allow reads or not
Configure Backup peferences
Configure Listener for Application connectivity
During AlwaysOn SSMS Wizard Configuration
1. SQL Service Account of each replica instance is added a login on each replica instance
2. Data Mirroring End-Point is Created on Each replica instance and configured with the
necessary IP Address and Port Number for communications between Nodes
3. Data Mirroring End-Point is started
4. Connect Permissions on the End-Point is granted to the SQL Service Accounts added in
Step 1
5. The AlwaysOnHealth Extended Event Session is started on both nodes this is configured
on SQL installation but disabled by default useful as it records some critical events related
to AlwaysOnand can help with trouble-shooting
6. The Databases being added to the AG are backed up (full and log backups) and restored to
the replica instance
7. Availability Group is created on Primary Instance specifying the following :
1. Databases for inclusion in the AG
2. End-Points created above
3. the Failover Mode (Automatic or Manual)
4. Commit Mode (Synch or Asynch)
5. Backup Preference and Priority (used if there are multiple secondaries)
6. Accessibility of Mirror replicas (Read-Only or norecovery)
8. The AG needs to be made available on the Secondary Replica
9. Databases on replica instance are added into the AlwaysOnGroup
10. Listener Added with DNS Name and Ip Address Specified
2014/05/06
13
Monitoring AlwaysOn Health
SSMS Dashboard
SSMS AlwaysOn Dashboard Healthy State
SSMS AlwaysOn Dashboard 1 Node Not Synchronizing
Monitoring AlwaysOn Health - TSQL
To Check AG Health
SELECT ag.name AS ag_name, ar.replica_server_nameAS ag_replica_server, dr_state.database_idas database_id,
is_ag_replica_local = CASE WHEN ar_state.is_local = 1 THEN N'LOCAL' ELSE 'REMOTE' END ,
ag_replica_role= CASE WHEN ar_state.role_descIS NULL THEN N'DISCONNECTED' ELSE ar_state.role_descEND ,
ar_state.connected_state_desc, ar.availability_mode_desc, dr_state.synchronization_state_desc
FROM (( sys.availability_groupsAS agJOIN sys.availability_replicas AS ar ON ag.group_id= ar.group_id)
JOIN sys.dm_hadr_availability_replica_statesAS ar_stateON ar.replica_id= ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_statesdr_stateon
ag.group_id= dr_state.group_idand dr_state.replica_id= ar_state.replica_id;
To Check how far behind is Secondary
SELECT ag.name AS ag_name, ar.replica_server_nameAS ag_replica_server, dr_state.database_idas database_id,
is_ag_replica_local = CASE
WHEN ar_state.is_local = 1 THEN N'LOCAL'
ELSE 'REMOTE'
END ,
ag_replica_role= CASE
WHEN ar_state.role_descIS NULL THEN N'DISCONNECTED'
ELSE ar_state.role_desc
END,
dr_state.last_hardened_lsn, dr_state.last_hardened_time, datediff(s,last_hardened_time,
getdate()) as 'seconds behind primary'
FROM (( sys.availability_groupsAS agJOIN sys.availability_replicas AS ar ON ag.group_id= ar.group_id)
JOIN sys.dm_hadr_availability_replica_statesAS ar_stateON ar.replica_id= ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_statesdr_stateon ag.group_id= dr_state.group_idand dr_state.replica_id= ar_state.replica_id;
2014/05/06
14
Monitoring AlwaysOn Health - TSQL
Monitoring Redo Queue Size on Secondary - Run against secondary
SELECT ag.name AS ag_name, ar.replica_server_nameAS ag_replica_server, dr_state.database_idas database_id,
dr_state.redo_queue_size, is_ag_replica_local = CASE
WHEN ar_state.is_local = 1 THEN N'LOCAL'
ELSE 'REMOTE'
END ,
ag_replica_role= CASE
WHEN ar_state.role_descIS NULL THEN N'DISCONNECTED'
ELSE ar_state.role_desc
END
FROM (( sys.availability_groupsAS agJOIN sys.availability_replicas AS ar ON ag.group_id= ar.group_id)
JOIN sys.dm_hadr_availability_replica_statesAS ar_stateON ar.replica_id= ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_statesdr_stateon ag.group_id= dr_state.group_idand
dr_state.replica_id= ar_state.replica_id;
AlwaysOn Wait Types
Many new Wait Types in SQL 2012 relating to AlwaysOn Most begin with HADR_
Full List here : http://msdn.microsoft.com/en-us/library/ms179984.aspx. Some examples below
Analysing Total Waits by Category since last SQL Restart
WITHWaits AS
(SELECTwait_type, wait_time_ms / 1000. ASwait_time_s,
100. * wait_time_ms / SUM(wait_time_ms) OVER() ASpct,
ROW_NUMBER() OVER(ORDERBYwait_time_ms DESC) ASrn
FROMsys.dm_os_wait_stats WITH(NOLOCK)
WHEREwait_type NOTIN(N'CLR_SEMAPHORE',N'LAZYWRITER_SLEEP',N'RESOURCE_QUEUE',
N'SLEEP_TASK',N'SLEEP_SYSTEMTASK',N'SQLTRACE_BUFFER_FLUSH',N'WAITFOR',
N'LOGMGR_QUEUE',N'CHECKPOINT_QUEUE', N'REQUEST_FOR_DEADLOCK_SEARCH',
N'XE_TIMER_EVENT',N'BROKER_TO_FLUSH',N'BROKER_TASK_STOP',N'CLR_MANUAL_EVENT',
N'CLR_AUTO_EVENT',N'DISPATCHER_QUEUE_SEMAPHORE', N'FT_IFTS_SCHEDULER_IDLE_WAIT',
N'XE_DISPATCHER_WAIT', N'XE_DISPATCHER_JOIN', N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
N'ONDEMAND_TASK_QUEUE', N'BROKER_EVENTHANDLER', N'SLEEP_BPOOL_FLUSH',
N'DIRTY_PAGE_POLL', N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
N'SP_SERVER_DIAGNOSTICS_SLEEP'))
SELECTW1.wait_type,
CAST(W1.wait_time_s ASDECIMAL(12, 2)) ASwait_time_s,
CAST(W1.pct ASDECIMAL(12, 2)) ASpct,
CAST(SUM(W2.pct) ASDECIMAL(12, 2)) ASrunning_pct
FROMWaits ASW1
INNERJOINWaits ASW2
ONW2.rn <=W1.rn
GROUPBYW1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVINGSUM(W2.pct) - W1.pct <99OPTION(RECOMPILE); --percentage threshold
HADR_WORK_QUEUE
AlwaysOn Availability Groups background worker thread waiting for new work to be assigned. This is an expected wait when there
are ready workers waiting for new work, which is the normal state.
HADR_LOGCAPTURE_WAIT
Waiting for log records to become available. Can occur either when waiting for new log records to be generated by connections or
for I/O completion when reading log not in the cache. This is an expected wait if the log scan is caught up to the end of log or is
reading from disk.
2014/05/06
15
Monitoring AlwaysOn Transaction Latency
from Synchronous Mirroring
Option 1 PerfMon
Two performance counters on the primary replica to check
1. SQL Server:Database Replica --> Transaction Delay
an accumulation of the delay of all the current transaction delay in millisecond
2. SQL Server:Database Replica --> Mirrored Write Transactions/sec
the value of transactions which indeed caused data transfer with AlwaysOn
Option 2 TSQL
select wait_type, waiting_tasks_count, wait_time_ms, wait_time_ms/waiting_tasks_count as'time_per_wait'
from sys.dm_os_wait_stats where waiting_tasks_count >0
and wait_type = 'HADR_SYNC_COMMIT
Be aware that the counter in sys.dm_os_wait_stats is accumulated since the startup of the server. Means it is covering workload
peaks as well as time period of rather low workload. Whereas with Performance Monitor one can focus on certain time periods and
workload periods.
AlwaysOn Alerting Options
Option 1 : SQL Server Alerting
Monitoring for Event IDs and sending email alerts direct to the DBA
if these events arise
http://www.mssqltips.com/sqlservertip/2973/configuring-alerts-for-
sql-server-alwayson-availability-groups/
Option 2 : Quest Foglight (3-Party Tool)
Monitoring for AlwaysOn and sending email alerts when there is a
mirroring issue
2014/05/06
16
Monitoring AlwaysOn with Quest Foglight
Dashboard Similar to SSMS but with Alerting Capabilities
Synchronizing Status for SQL AlwaysOn
32
Make sure your database status is:
Sync mode Synchronized
Async modeSynchronizing
2014/05/06
17
AlwaysOn Manual Failover
from Failover Cluster Administrator
AlwaysOn Manual Failover from SSMS
2014/05/06
18
Failover to Async Node May Cause Data Loss
1,2,3,4,5 1,2,3,4,5 1,2,3,4,5 1,2,3,4
Primary
Secondary Secondary Secondary
Sync Sync Async
1,2,3,4,5 1,2,3,4,5 1,2,3,4,5
1,2,3,4
Secondary (suspend) Secondary (suspend)
Primary
Secondary (suspend)
Failover to Async node
1. Data Loss
2. All Secondary DB will suspend
and need to be manually resumed
AlwaysOn
Cross-site
Failover
DEMO
2014/05/06
19
Useful AlwaysOn Links
Availability Group Checklist (Brilliant reference)
http://i.brentozar.com/sql-server-2012-alwayson-availability-groups-setup-
checklist.pdf
Configure AG to use Dedicated Network
http://blogs.msdn.com/b/alwaysonpro/archive/2013/11/01/configuring-a-dedicated-
network-for-replicating-changes-from-primary-to-secondary-replica.aspx
Understanding Logging and Recovery (Paul Randal)
http://technet.microsoft.com/en-us/magazine/2009.02.logging.aspx
AG Listeners, Client Connectivity and Application Failover
http://technet.microsoft.com/en-us/library/hh213417.aspx
Prerequisites, Restrictions, and Recommendations for AlwaysOnAvailability Groups
http://technet.microsoft.com/en-us/library/ff878487
Readable Secondary Replicas
http://technet.microsoft.com/en-us/library/ff878253.aspx#CapacityPlanning
Redirecting AS Processing at Read replicas
http://technet.microsoft.com/en-us/library/hh967523.aspx#bkmk_ssasAODB
AlwaysOnThread Usage
http://technet.microsoft.com/en-us/library/ff878487.aspx#ThreadUsage
SAP on SQL Server (Great AlwaysOnarticles for Monitoring)
http://blogs.msdn.com/b/saponsqlserver/default.aspx?PageIndex=3
SQL AlwaysOn Team Blog
38
http://blogs.msdn.com/b/sqlalwayson/
2014/05/06
20
Microsoft SQL Server HA
Why Use Replication?
Replication enables users to access copies of an
existing database
Replication provides:
Load balancing
Improved availability
Reduced network traffic
Offline processing
2014/05/06
21
Replication Terminology
Publishing metaphor:
Publisher
Article
Publication
Subscriber
Subscription
Distributor
Node
Push and pull subscriptions
Latency and autonomy
Replication Agents
Replication agents:
Snapshot Agent
Distribution Agent
Log Reader Agent
Merge Agent
Push replication
Merge /
distribution
agent on
distributor
Pull replication
Merge /
distribution
agent on
subscribers
2014/05/06
22
Type of Replication
Snapshot replication
Send all of the data, point-in-time copy of the database
Transactional replication
Changes made to articles are capture from the transaction
logs and propagated to the distributors
Transactional publication with updateable
subscriptions
The publisher streams transactions to subscribers after they
receive an initial snapshot of the published data
Merge replication
Like a combination of transactional and snapshot replication.
Changes are sent as a batch
43
Scenarios for Transactional Replication
Recommended for:
Frequently changing data at one location
Copies of data need to be up to date
Individual changes needed at subscribers
Order update
09:30 AM
Order tracking
application
Order update
08:30 AM
2014/05/06
23
Scenarios for Peer-to-Peer Transactional
Replication
Recommended for:
Subsets frequently changing data
Changes at any node need replicating to all nodes
Copies need to be up to date
San Francisco orders
New York orders
Troubleshooting Replication
Common types of problems:
Data not available at subscribers
Data mismatch between publisher and subscribers
Performance-related issues
Security-related issues
2014/05/06
24
Choosing SQL Replication Options
47
Aspect Snapshot Transactional Peer to Peer Merge
Transactional No Yes Yes No
Complexity Low Medium High Medium
Subscribers can
update
No
Limited
options
Partitioned
data
Yes
Conflict
Detection
No No Yes Yes
Conflict
Resolution
No No Yes Yes
Performance Medium High High Low
Restrictions for Replication with AlwaysOn
http://msdn.microsoft.com/zh-tw/library/hh403414.aspx
2014/05/06
25
Subscriber AG (Manually synchronize)
Publisher AG (Auto Synchronize)
SQL 2012 Replication with AlwaysOn AG
CITLABDB1 CITLABDB2
Publisher
Distributor
CITLABDB3 CITLABDB4
Subscriber
(primary) (secondary)
(primary) (secondary)
CITLABDB5
Remote\Distributor
Publisher with AlwaysOn
How to configure the publisher
The idea
Basic procedure
1. Configure a remote distributor
2. Prepare for Repl all instances
that might become the
publisher in an AG
3. Create an AG
Add the published DB
Add the AlwaysOn replicas:
primary and secondaries
Create a VNN/Listener
4. Run sp_redirect_publisher
set @redirected_publisher =
VNN/Listener
2014/05/06
26
Publication Initialization Settings
Publication Properties \Subscription Options\Allow initialization from
backup files -> Set True
T-SQL scripts
EXEC sp_changepublication@publication = 'MyPublication', @property =
'allow_initialize_from_backup', @value = 'true';
Redirect the Publisher to AG Listener
:connect ALWAYSON-SRV8\distributor
USE distribution;
GO
EXEC sys.sp_redirect_publisher
@origListenerinal_publisher = CITLABDB1',
@publisher_db = 'DB_Publisher',
@redirected_publisher = TWO-AG1';
GO
2014/05/06
27
After AG Failover Verify the Results
Subscriber with AlwaysOn
How to resume distribution agent
after failover of subscriber AG?
1. Get LSN of last transaction
received by Subscriber
Secondary
Select transaction_timestamp
from Msreplication_subscriptions
2. Cleanup old subscription from
new subscription DB
Sp_subscription_cleanup
3. Create new subscription
@sync_type = initialize from
LSN
@subscriptionlsn = LSN
2014/05/06
28
Manual Process after AG Failover
Step 1
:connect Remote\distributor
--stop distribution agent, hes retrying at this point SQL Server Agent\Job
Step 2
SELECT transaction_timestamp, *
FROM DB_Subscriber.dbo.MSreplication_subscriptions;
Manual Process after AG Failover
Step 3
--Cleanup old subscription from new subscription DB
EXEC sp_subscription_cleanup @publisher = CITLABDB1',
@publisher_db = 'DB_Publisher';
Step 4
2014/05/06
29
AlwaysOn and Replication Complexities
Systems Databases (particularly Distribution and MSDB) cannot be included in
Availability Group.
If AG Database is a Replication Publisher Database, extra setup steps
http://technet.microsoft.com/en-us/library/hh710046.aspx
After failover to a secondary replica, Replication Monitor is unable to adjust the
name of the publishing instance of SQL Server and will continue to display
replication information under the name of the original primary instance of SQL
Server. After failover, a tracer token cannot be entered by using the Replication
Monitor, however a tracer token entered on the new publisher by using Transact-
SQL, is visible in Replication Monitor.
Failover of a Subscriber Database Manual
http://technet.microsoft.com/en-us/library/hh882436.aspx
Log Reader Agent Modifications with AlwaysOn in place Be aware
http://technet.microsoft.com/en-us/library/hh403414.aspx
Microsoft SQL Server HA
2014/05/06
30
Why Use Log Shipping ?
Mature and reliable technology
Widely deployed
No automation of failover supplied
Core process
Backup transaction log
Copy logs to another server
Restore transaction log on second server
Secondary
server
Log Shipping Server Roles and Topology
Server and database Description
Primary server
and database
Serves as the production server
Secondary server
and database
Keeps a current copy of the
primary database
Optional monitor server Tracks all of the details of log shipping
Primary
server
Back up
transaction
log files
Restore
transaction
log files
Monito
rserver
2014/05/06
31
Log Shipping Requirements
SQL Server 2012/2014 must be installed on all server
instances
Databases must have the same logical design and collation
setting
Databases must use the full or bulk-logged
recovery model
The SQL Server Agent should be configured to
start up automatically
Sysadmin privileges are required on each server instance
The primary database must be the same as the principal
database if used with database mirroring
Backup and Restore Directory Requirements
The SQL Server service account and proxy account must have
read/write permissions to the backup directory
Proxy account of the copy job must have read permissions to
the backup directory and write access to the copy directory
The SQL Server service account on the secondary server and
the proxy account of the restore job must have read/write
access to the copy directory
User access to the secondary server for
reporting purposes
Frequency of log shipping schedules should be set
Size of the transaction logs
Storage location and network reliability
2014/05/06
32
Configuring Log Shipping
sp_add_log_shipping_primary_database
@database = N'AdventureWorks2008'
,@backup_directory = N'c:\lsbackup'
,@backup_share = N'\\NY-SQL-01\lsbackup'
,@backup_job_name = N'LSBackup_AdventureWorks2008'
Configure log shipping in either:
SQL Server Management Studio
Transact-SQL
Configurations and SQL Agent Jobs
2014/05/06
33
Switching Server Roles
BACKUP LOG AdventureWorks TO AWLogBackup
WITH NORECOVERY
RESTORE LOG AdventureWorks FROM AWLogBackup
WITH RECOVERY
Copy transaction log backups
1
Restore primary database on secondary server 3
Back up primary database with NORECOVERY
2
Disable log shipping jobs
4
Configure log shipping on new primary server
5
AlwaysOn with Log Shipping Example
http://blogs.msdn.com/b/saponsqlserver/archive/2013/01/24/alwayson-part10-
alwayson-and-logshipping.aspx
Using a combination of AlwaysOn and Log-Shipping. Supply DR site with
Log-Shipping
2014/05/06
34
Thank you
Q & A

!!