1. Migrating SQL Server Quickly and Efficiently

2. Please Support Our Sponsors
SQL Saturday is made possible with the generous support of these sponsors. You can support them by opting-in and visiting them in the sponsor area.

3. Don’t forget to silence your phone

4. Introduction Originally from Kamloops BC 10 years of IT experience
6 as a SQL Server DBA
Contractor for last 3 years
Worked with SQL Server 2000 through 2014
Experience with other RDBMS such as Oracle, MySQL
MCSA: SQL Server 2012
Soon to be a Edmonton Resident

5. How did this presentation come about?
Various projects requiring some form of database migration
Projects included
Hardware refresh
SQL Upgrade
Storage refresh
Failover cluster with 8 SQL instances
Approximately 200 databases total
Lots of different applications including
Jobs/SSIS
SSRS Reports/Tableau/Excel
Services, Web Apps, desktop client
Outage windows usually 15 minutes but 1 hour could be arranged

6. Agenda Analysis Planning Execution What is changing What is the impact
Instance
Database
Application
Execution

7. Analyzing the Impact

8. What is Being Migrated? Application Upgrades SQL Server Upgrades
Windows Upgrade
Server Refresh
SAN Refresh
What kinds of migrations might we have to do:
- Application Upgrade
- Single Database
- SQL Server Upgrade
- Server Refresh
- OS Upgrade

9. Migration Scenario Migrating from 2008R2 to 2014
It’s a two node cluster
Over 200 databases
Move everything in one window
Outage window is one hour

10. What is the Impact What databases need to be migrated Instance Objects
What applications are affected?
Connection string changes
Look at what is further up the stack with our migration
Need to clearly determine what is in scope for the migration
Might use this as an opportunity to clean up
Are all logins still needed?
Are all the databases still needed?
Why move something that isn’t actually needed
Ultimate goal is to minimize impact on the end users
Keep IT in good graces with the business
Get an understanding of which databases are being moved
Easy to determine the databases we need to move
What instance level objects are needed to support the database
Logins
Jobs
Linked Servers

11. What Tools So We Have? What tools can we use to identify the impact?
Profiler/Extended Events
Login Auditing
Set for “both failed and successful logins”
Auditing Tools
System Documentation
Application Testing
What tools do we have available to use
Use profiler or extended events to capture application activity
Requires some effort to review traces
Login auditing
Set SQL Server to log both failed and successful login attempts
You can then mine the logs
Are the application requirements already documented
Everyone keeps their documentation up to date right?
Application testing
Migrate the applications – do they work, if not what is missing
Document what was moved for each application

12. Creating a Plan There is no magic
A successful migration will be dependent on
How complete of a plan you have
How well you test the plan

13. Instance Setup Install and Configure the new instance
Create instance objects
Jobs
SSIS Packages
Maintenance plans
Linked Servers
How to migrate
SSIS
Scripts (T-SQL, PowerShell)
Demo
Start with your standard build out process
You should be familiar with how a SQL instance is installed in your environment
Scripted Installation/configuration – for a standard build
Best practices are well documented
Next start configuring Instance Objects
If not upgrading the version of SQL Server, you could restore the Master/MSDB databases
Manually script out objects and deploy
Logins/Linked Servers/Maintenance Can usually be setup beforehand
Jobs can be created before but leave disabled
Demo
PowerShell Script Object (SQL01)
Exec sp_help_revlogin (SQL02)
SSIS Migration (SQL03)

14. User Databases How can we prepare before hand?
Use HA/DR technologies in SQL Server
Mirroring
Log Shipping
Availability Groups
Script your own process
Backup/Restore
Detach/Copy/Attach
This could be the most time consuming
IE if we had to restore a 2 TB database
Do the restoration before hand
Use Mirroring or Log shipping to keep up to date
Determine if we need to run a post-script
Have the script prepared before hand
Setup and Cutover can be automated
PowerShell, T-SQL
Executed via jobs
Prep any post deploy Scripts
Include script for enabling jobs
Options for keeping copies in sync
Mirroring (Demo)
Pros: Simpler cutover, Built in , synchronous
Cons: Full Recovery required, Depreciated technology, only 1 destination
Log Shipping (Demo)
Pros: Multiple-Destinations, Built In, relatively straight forward cutover
Cons: Multi-Step Cutover, Built in version may conflict with existing maintenance plans, delay with replication (asynchronous with delay)
Availability Groups
Pros: Simpler cutover, Multiple Destinations, No disruption to DR
Cons: Potentially messy with clustering, Upgrade Process may take some planning
Rolling Upgrade:
Distributed Availability Groups
Backup/Restore (Demo)
Can script out custom backup restore process
Pros: Don’t necessarily need Full Recovery, your in control of your process, leverage existing backup strategies
Cons: requires planning and development efforts

15. Mirroring Simple switch over
ALTER DATABASE <DB> SET PARTNER FAILOVER;
Synchronous commit ensures databases are in sync
Requires Full Recovery Mode
Deprecated Technology
Only one destination
Built into SQL Server (2005+)
Demo

16. Log Shipping More moving pieces
Switch over more complicated then mirroring
Backup and Restore tail log
Requires Full Recovery mode
Multiple Destinations
Built into SQL Server
Demo

17. Backup and Restore Potentially slower process
Databases can be simply recovery
Can restore full ahead of time
Then use a differential to catch up
Greater control with custom scripts

18. AlwaysOn Availability Groups
Similar to mirroring
Simple switchover
Synchronous replication
Requires Full Recovery mode
Enterprise Feature
Require Windows Clustering
With listener applications will follow
SQL Server 2016
Distributed Availability Groups
Basic Availability Groups

19. Applications How can we control the application changes
Client Configuration
Connection string changes
SQL Server Alias
System DSN
Central Configuration
DNS CNAME
Re-Use DNS/IP Changes
Centrally stored app configuration? (CIFS Share)
AlwaysOn Availability Group Listener
Connection String management can be a pain
Client configuration options – has to be set on all client machines/servers
Connection string changes: problem if there are a lot of apps to update
SQL Server Alias – handy but may not work for all drivers. (Demo)
System DSN – Application has to be configured (Demo)
Options can be centrally managed either by GPO or PowerShell.
Not Ideal as refresh time might be slow
Centralized Configuration
Configure applications to use Cname (Demo) -
Doesn’t Recognize Named instances
1433 Trick
Unsure about other drivers
Re-use DNS Name/IP Address (Demo)
May break integrated authentication
WSFC, recreate Client Access Point
End Point (Demo)
Before the migration, slowly reconfigure applications to better manage connection string

20. Execute the migration

21. Preparation Use T-SQL/PowerShell scripts where ever you can
Document the steps
Create a checklist for each instance
Practice the migration
In Dev\Test walk through the migration several times
Find out how long you need
Refine the process
Test the applications
Was anything missed in the analysis?
Are there any surprises
This is where we put the plan together
Script in three stages
Preparation
Cutover
Post-Migration/Validation
Create a checklist
Specifically follow the check list
Ensure you don’t miss a step
Have someone walk through the documented process
Checklists will keep you honest
Practice
Walk through several times
Time each walk through, strive to decrease execution time
Perform full application testing
Regression testing
Get app support/developers to test – who ever knows the app best
Validate nothing is missed

22. Execution Get your outage window right
Ensure support staff are on hand
Outage Window
Based on your practice time
Leave extra time in case complications arise
Set a point of no return
Business requirements might dictate the window
All hands on deck
Just incase we missed something, we can act quickly and roll forward
Well executed migration will not only make DBA’s look good but IT in general

23. Conclusion Reminder our end goal is to reduce business impact
Best migration won’t be noticed by end users
Ill prepared migration will be noticed a lot more then a successful one
Analyze what is being impacted
Understand what is changing
Know what you need to move and where
Plan
How can we cutover quickly
How can we reduce any application impact
Execute
Practice Practice Practice
Execute what you can via scripts
Document and process
Follow a checklist

24. Questions?