Migrating SQL Server Quickly and Efficiently

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.

Don’t forget to silence your phone

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 Email: Ian.A.Chamberland@gmail.com Soon to be a Edmonton Resident

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

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

Analyzing the Impact

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

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

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

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

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

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)

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: https://msdn.microsoft.com/en-CA/library/dn178483.aspx 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

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

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

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

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

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

Execute the migration

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

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

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

Questions? Email: Ian.A.Chamberland@gmail.com