Justin Manning MSFT PFE

Upgrade a clustered Microsoft SQL Server 2014 to SQL Server 2017 (step by step)

Justin Manning — Wed, 08 Aug 2018 11:20:18 GMT

Technical Details

This document will contain step by step guides on to follow to achieve the objectives listed below. The objective of this guide is to minimize downtime during the upgrade procedure and ensure a successful upgrade of Microsoft SQL Server.

Upgrade Microsoft SQL Server 2014 to SQL Server 2017

The objective of this step is to document the upgrade process of Microsoft SQL Server 2014 to SQL Server 2017, in a clustered environment. This will also include upgrading the server operating system from Windows Server 2012 R2 to Windows Server 2016. The existing SQL Configuration contains Transactional replication, which will remain unaffected during this upgrade process.

Impact to environment

To achieve a full upgrade of the operating system and the Microsoft SQL engine, a failover will be initiated during operating system upgrades, and a further failover during SQL upgrades. The Passive node in the cluster will be upgraded, allowing business to continue during this upgrade procedure.

Server Upgrade Procedure

The below steps will guide you through the process up upgrading Server OS in a clustered environment. Note: Failover times of cluster resources, will largely depend on the size of the database log files, and how the log is being maintained. A large amount of VLFs (Virtual log files) could impact database start up times. During a failover, any transactions that were not committed, would also need to rollback, impacting recovery objectives of a cluster failover.

Evict Node

Take note of the active node where SQL Server is running, we are going to start by upgrading the passive node first. The passive node will be evicted from the cluster, and the Windows Server 2016 software will be executed to initiate the upgrade. Once the upgrade has completed, we will add the node back to the cluster, move the SQL Server role to the newly upgraded node, evict the passive node and following the same process to upgrade the second node.

Perform Operating System Upgrade

Add Node

Once the operating system upgrade has completed, you will need to add the node back to the cluster.

This is achieved by logging onto the active node and adding the previously evicted node back to the cluster.

NOTE: Now that the upgraded node has been added to the cluster, we will need to fail the SQL resource over to the newly upgraded node, and begin upgrading the second, passive node.

Microsoft SQL Server 2017 Upgrade

Once the operating system in the cluster environment has been upgraded successfully, we are ready to perform a SQL Upgrade in a clustered environment. The upgrade will be performed against the passive node first, and then the active node. The SQL Installation wizard will manage the movement of the SQL resource in the cluster.

Upgrade Passive Node

Log onto the passive node and execute the Microsoft SQL Server 2017 setup file.

Select the option to Upgrade from a previous version of SQL Server

You will see this warning if your server is not connected to the windows update service. You may continue to the next step.

Upgrade Active Node

Now that the passive node has been upgraded, log onto the active node and execute the Microsoft SQL Server 2017 setup executable.

SQL Server Performance Testing with Database Experimentation Assistant

Justin Manning — Tue, 15 May 2018 18:26:03 GMT

Introduction

This quick post is to assist users in performing performance tests on various environments and generate analytics from the results. The Database Experimentation Assistant makes use of SQL Server Distributed Replay Controller and Clients.

Tool:

Database Experimentation Assistant (DEA)

Virtual Environment:

SQL Server 2017 CU6 (DEA has a known issue in replay if the SQL Instance target is below SQL Server 2017 CU 1)
- Instance Name: SQLEXP
Windows Server 2016
Distributed Replay Client (up to 8 clients in enterprise edition)
Distributed Replay Controller
Working Folder for trace files to be collected and replayed:
- C:\DEA
  - Source
  - Target

Configuration of DEA Populate the required fields Click Start to begin collection Note Completion Status Replay the workload against your database Make sure your SQL Server Distributed Replay Controller and Client are in a running state Confirm the distributed replay Controller is communicating with the client Click on All Replay to run the collected workload Create a new Replay Perform a restore of the database you would like to test the workload against. This is to ensure the database is in the original state before a workload was performed against it. Note: Replay is busy running via distributed controller Notice distributed replay controller status, sending work to clients Completed Run Click on Analysis Report to analyse workload Connect to the instance of SQL where you would like to do analysis Create a new Analysis Report Populate required fields. Supply the original workload collected, as well as the target workload, which was generated by the replay Notice databases being created for the analysis to be performed Reports Presented once analysis is completed

Azure Backups and Site Recovery – Encrypted SQL Backups

Justin Manning — Tue, 15 May 2018 18:03:55 GMT

Introduction

This document is intended to assist the user in configuring Azure Recovery Services for on premise backups of encrypted SQL Server Backups.

The goal of this document is to demonstrate the capability of backing up encrypted Database backups, where the encryption key stays in possession with the customer (onsite) and is not managed by any external service.

Configure Azure Recovery Services

Navigate to https://ms.portal.azure.com, sign in with your subscription details. This will be the account that will contain your Recovery Service.

Create a Resource Groups to manage your Azure Recovery Services Vault

This step will create a resource group, which we will contain the Azure Recovery Services vault at the end of this demo.

Click on Resource Groups

Add a resource group

Give your resource group a name and select the region you would like the resource group to belong

To, in this example, we called the resource group "azure-backup"

Click Create once configured

Once the resource group is created, select the resource group

Select Add in your resource group, to begin adding the Azure Recovery Service

Search for "Azure Recovery Service" and select the "Backup and Site Recovery (OMS)" option.

Click Create to create the Vault

Give your recovery services vault a name and select the resource group previously created. Once filled in, click create.

Once your Vault has been created, you will be presented with the overview blade of the Recovery Services Vault.

Configuring Azure Recovery Services Backups

This step will allow you to configure what you want to backup to the vault.

You will be presented with a blade to select the types of backups you want to do. For purposes of this documents, configure your backups as follows, and select "Prepare Infrastructure":

This will prompt you to download the recovery services agent, as well as the credentials to authenticate your on-premises infrastructure, with your vault

Follow Steps 1, but installing the Recovery Services Agent, and configure the agent to suit your environment. i.e. proxy setting if applicable.

Return to the azure portal, to download your credentials

Once the agent is installed, proceed to step 2

Save your credential file

Import this file via the Recovery Services Agent

Configure your Passphrase, this is your password to the vault, and needs to be kept safe and click Finish when done.

Registration successful

Configuring Backup Schedule

Once the Azure Recovery Services Agent has been installed and configured, the next step would be to configure and schedule your backups.

Add items you wish to backup.

In this example, we are going to add a folder location for the Encrypted SQL Server Backups we wish to back up.

Navigate to the folder location you wish to back up

Configure your schedule as necessary

Configure retention period

Configure initial backup options

Confirm and Finish

Confirm Success and Close

Backing up a SQL Server Database

This demo will illustrate the steps in backing up a database and having the Azure Recovery Service back the SQL Server backup file to Azure

Perform an encrypted backup to a disk location

Take note of the warning, to back up your certificate.

You can manually execute a backup from the Microsoft Azure Recovery Services agent, by selecting to "back up now". This will have the recovery services agent send the backup file to your azure vault for safe keeping.

Verify your machine is now listed in the vault as a backup item:

Performing a recovery

To restore your database backup, you will need to perform a recovery of the vault, which will allow you to select at which point in time, or schedule, you would like to recovery from. This will recover the entire directory structure of your recovery site, and you will be able to restore the database. This will be demonstrated in the next following steps.

Select Recover from the Microsoft Azure recovery Services agent

Select the point in time which you would like to recover.

You will notice that a volume is mounted as a disk you can browse though. This will allow you to click through the directory structure, to retrieve any files you wish to retrieve. These may be copied off the mounted volume and placed on a separate disk for future use.

An example of the mounted volume for recovery.

Once file retrieval is complete, unmount the disk

Setting up Central Management Server in SQL Server

Justin Manning — Fri, 20 May 2016 15:28:33 GMT

Hey SQL Fans, Today I thought I would write a quick post about Central Management Server for SQL Server. I have been to so many customers who are not making use of this amazng a free feature that ships with SQL Server. I always ask the resident DBA team at a customer, how they are managing their SQL instances and whether they are using CMS. Surprisingly, they have either never heard about it, or they have, but cannot find a use for it? I personally feel that CMS should be a part a foundation to your SQL Server Eco System. It makes the life of a DBA so much easier when it comes to your day to day administration, as well as additional free SQL Server features you would like to use, i.e. Policy Based Management, Management Data Warehouse, Multi-Server Queries and Multi Server Administration etc. Today, I would like to show you how to set this wondeful feature up, how to register your SQL instances within CMS, and set up your master and target SQL agents.

Configuring CMS

Click on View -> Registered Servers. You will be presented with a view of your local instances and registered servers: Right click on Central Management Servers -> Register Central Management Server You will be presented with a window to enter a Database Server that will act as the Central Management Server. If you have a dedicated DBA server, this woul d be ideal Once this information has been saved, you will see a CMS server registered You can now create groups under your CMS to manage different areas of your SQL Eco system. Below, I have included an example of how you could group your SQL instances, based on how you manage your environment: NOTE: When creating your various SQL groups, think of the multi-server queries you would run against these groups. A multi-server query is a query you can run against a group of servers. The query will return results from each server registered in a specific group. Well done :-) you have now created a CMS for your SQL environment. This is a great foundation for your SQL environment within your organization. CMS will allow you to run queries across SQL group. CMS will help you find information a lot quicker, as well as help with maintenance queries etc, eg. running DMV queries against CMS groups to find backup information, index usage, query execution information etc. Next, I would like to show you how to configure the SQL Agent of your CMS for Multi-Server SQL Server Administration. I hope you guys enjoyed this quick post on CMS and that you start making the relevant changes within your SQL eco system. Cheers

SQL Server In-Memory

Justin Manning — Thu, 05 May 2016 12:41:55 GMT

Hi to all of you SQL Server fans, There has been a lot of interest from customers moving to SQL Server 2014, specifically around the use of SQL Server in-memory optimizations as well as identifying possible candidates that could benefit from this technology. I thought I would write a quick post to cover the implementation of SQL Server in-memory at a very high level, by discussing different DURABILITY modes available to you. First off, let's make use of AdventureWorks 2014 as our test database. There are a few steps we need to follow first, in order for SQL to make use of the in-memory capabilities: Firstly, we need to enable the filestream feature on the SQL Engine [caption id="attachment_35" align="alignnone" width="879"] SQL Server Configuration Manager[/caption] On the properties page, enable FILESTREAM via the FILESTREAM TAB: [caption id="attachment_37" align="alignnone" width="251"] Enable FILESTREAM[/caption] Now that the SQL Engine has been configured correctly, lets enable a Memory Optimized Filegroup in the AdventureWorks2014 database. There are two ways to do this, via the SSMS GUI on Database properties:

Enable the Filegroup in MEMORY OPTIMIZED DATA section of your FILEGROUPS tab:

Or via T-SQL Script:

USE [master] GO ALTER DATABASE [AdventureWorks2014] ADD FILEGROUP [AdventureWorksInMemoryData] CONTAINS MEMORY_OPTIMIZED_DATA GO

Now that that the filegroup has been configured, you are now able to create tables in memory: In-Memory tables can be created with one of two durability options, namely:

SCHEMA AND DATA
- These tables have logging enabled via the sql server transaction log and data is stored in the filestream filegroup.
- In the event of SQL server being restarted, data is played back into the table on start-up
SCHEMA ONLY
- These tables do not persist the data to the filestream filegroup.
- If the SQL Engine is rebooted, the data is lost
- This option is popular for staging type of scenarios of data.

Tables can only be created via T-SQL script: SCHEMA AND DATA:

CREATE TABLE [dbo].[TestInMemoryTableSCHEMA_AND_DATA] ( [ID] [int] IDENTITY(1,1) NOT NULL, [DATAVALUE] [varchar](20) COLLATE Latin1_General_CI_AS NULL,

PRIMARY KEY NONCLUSTERED ( [ID] ASC ) )WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_AND_DATA )

or the SCHEMA ONLY option:

CREATE TABLE [dbo].[TestInMemoryTableSCHEMA_ONLY] ( [ID] [int] IDENTITY(1,1) NOT NULL, [DATAVALUE] [varchar](20) COLLATE Latin1_General_CI_AS NULL,

PRIMARY KEY NONCLUSTERED ( [ID] ASC ) )WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_ONLY )

Now that the tables have been created, you can read and write to them just like any other table in the database. Try the different options and see what works best for you and see what performance improvements you notice with your reads and writes. NOTE: With SQL Server 2014, you cannot change the definition of a memory optimized table once it has been created, you will need to drop and recreate the table in order to change the durability option. For more info on this refer to https://msdn.microsoft.com/en-us/library/dn269114(v=sql.120).aspx There are also a few limitations to this technology, which you can read more about over at https://msdn.microsoft.com/en-us/library/dn133186(v=sql.120).aspx Well, I hope this quick and high level post has helped you understand what is involved in making use of this SQL Server technology. In my next few posts I will be diving deeper into the topic and helping you identify which databases tables or stored procedures would benefit from this technology as well as indexing (refered to as hash and buckets) these tables by making Please post comments or questions below in order for my blog posts to suit your needs.