Anyway, in this blog post I want to cover a technology for copying databases across SQL Managed Instances that saved my posterior recently. Well, it didn’t really save it, but it sure made my life easier. We have a client who uses Azure SQL Managed Instance for both their production and test environments. I think this is awesome.

As a quick background, Azure SQL Managed Instance is a full SQL Server instance served up as a PaaS service. Unlike Azure SQL Database where you are only working at the database level, Managed Instance gives you near 100% instance compatibility level capabilities with the latest version of SQL Server Enterprise Edition SQL Server database engine. SQL Managed Instance provides the lift and shift capabilities of on-premises databases with minimal database changes.

So, back to our customer. They essentially lifted and shifted their on-premises databases to Azure SQL Managed Instance and have been using it successfully for nearly two years. Again, this is awesome.

Last week they came to us and asked about reporting with Managed Instance. They were looking at data marts and data warehouses, but we needed more information. It turns out they have some people that just want the ability to query the databases, and potentially hook up Excel to these databases for data analysis.

The caveat is that the people I was talking to didn’t want to give the other group direct access to the production environment. Toootally get that. Yeah, like 100% get it. So, what are the options?

After some discussion we decided to give the group wanting to run reports access to the test Managed Instance environment. We’ll just refresh the test environment data with the production environment data on a schedule. For them, refreshing data nightly is OK for now.

So, the question then becomes, how do you get data, or copy a database, from one SQL Managed Instance to another SQL Managed Instance? There are two ways, and I’ll discuss both here.

PowerShell cmdlets

Microsoft released some Powershell cmdlets that make copying data across SQL Managed Instances simple.

There are essentially 3 cmdlets:

• Copy-AzSqlInstanceDatabase – Starts an online copy operation.
• Get-AzSqlInstanceDatabaseCopyOperation – Returns copy operation details.
• Complete-AzSqlInstanceDatabaseCopy – Completes the copy operation.

The Copy-AzSqlInstancesDatabase cmdlet starts an online copy operation of a database across managed instances using Always On availability group technology. Copy-AzSqlInstanceDatabase (Az.Sql) | Microsoft Learn

The Get-AzSqlInstanceDatabaseCopyOperation cmdlet returns database copy operation details. You can call this cmdlet in a loop so you can track the status of the copy. Get-AzSqlInstanceDatabaseCopyOperation (Az.Sql) | Microsoft Learn

The Complete-AzSqlInstanceDAtabaseCopy cmdlet completes the copy operation of the database and makes it available for read/write workloads. Complete-AzSqlInstanceDatabaseCopy (Az.Sql) | Microsoft Learn

You don’t have to call the Get-AzSqlInstanceDatabaseCopyOperation cmdlet as you could just call the Copy and Complete, but it is HIGHLY recommended you call it so you know when to call the complete.

The way this works is you start by calling the Copy-AzSqlInstancesDatabase cmdlet. This starts an online copy operation of one or more databases. Once the copy option starts, data is being seeded from the source to the target. During the process, you can call the Get-AzSqlInstanceDatabaseCopyOperation cmdlet to check the copy operation status, either in-progress or completed.

Once the copy operation has completed, the status will be copy ready for completion. Within the next 24 hours the user can complete the database copy operation by calling the Get-AzSqlInstanceDatabaseCopyOperation cmdlet. Note that until the Get-AzSqlInstanceDatabaseCopyOperation cmdlet is called, all the changes from the source are being replicated to the target database.

When Get-AzSqlInstanceDatabaseCopyOperation is called, the link between the source and target databases is broken, the target database becomes online and ready.

A very simple example would be something like this:

Source code

$dbname = "db1"
$sourceMI = "sqlmi1"
$targetMI = "sqlmi2"
$sourceRG = "rg1"
$targetMI = "rg2"
 
Copy-AzSqlInstanceDatabase `
    -DatabaseName $dbName `
    -InstanceName $sourceMi `
    -ResourceGroupName $sourceRg `
    -TargetInstanceName $targetMi `
    -TargetResourceGroupName $targetRg 
 
While(true$)
{
 
    Start-Sleep -Seconds 10
    $operation = Get-AzSqlInstanceDatabaseCopyOperation `
    -DatabaseName $dbname `
    -InstanceName $sourceMI `
    -ResourceGroupName $sourceRG `
    -TargetInstanceName $targetMI `
    -TargetResourceGroupName $targetRG
 
    try
    {
        $copysucceeded = $true
        Write-Host "Status of copy for " $dbname " is " $operation.State
        if (!($operation.State -eq "Succeeded")) {$copysucceeded = $false;}
    }
    catch { $copysucceeded = $false; Write-Host "Didn't work" }
 
    if ($copysucceeded)
    {
        Write-Host "Copy completed"
        break
    }
    else { Write-Host "Still copying..." }
 
}
 
Complete-AzSqlInstanceDatabaseCopy `
    -DatabaseName $dbName `
    -InstanceName $sourceMI `
    -ResourceGroupName $sourceRG `
    -TargetInstanceName $targetMI `
    -TargetResourceGroupName $targetRG

There is a GREAT example here: Using and automating Azure SQL Managed Instance database copy and database move operations with Azure PowerShell (microsoft.com)

The example copies multiple databases, but if you are needing to copy only one, you can tweak it.

Oh, by the way, you can also do the copy via the Azure portal.

Backup / Restore

The other option is backup and restore, meaning, back up to Azure blob storage then restore from there. Since Managed Instance provides access to the SQL Agent, a job is created on both managed instances; one to back up, and one to restore.

This option gets a bit tricky because in the scenario for our client, and I would think in most environments, you want to restore the database in the target managed instance with the same name, and have the backup file the same as well, just to make it easy.

The backup job is simple: back up the database to Azure, ensuring the backup file name is always the same name. The restore job is just as simple: delete the database and then restore the database with the same name.

However, the issue in this scenario is that when you back up to the same file name, it will error because the file already exists. When we tested we thought, “no problem, we’ll just use PowerShell (Remove-AzureStorageBlob) to remove the file as the first step in the job, then the second step in the job will be to back up the database!”

Unfortunately, Managed Instance does not support PowerShell job steps. Sigh. So, we have an on-premises job (or it can even be a Windows Task Scheduler job) that runs the delete. At this point it is just a timing thing. Since the client only wants to back up and restore a single database, we run the backup job at 1 a.m., for example. Then 30 minutes later we run the restore, then another 30 minutes later, we run the delete blob job.

For this solution you’ll need to create a storage account in Azure, then create a CREDENTIAL in SQL Server on both Managed Instances:

Source code

CREATE CREDENTIAL [https://mystorageaccount.blob.core.windows.net/mycontainer]
WITH IDENTITY N'SHARED ACCESS SIGNATURE',
SECRET = N'<storageaccountkey>'

Once that is created, simply back up the database.

Source code

BACKUP DATABASE [MyDB] TO URL = N'https://mystorageaccount.blob.core.windows.net/mycontainer/MyDB.bak'
	WITH BLOCKSIZE = 65535, COPY_ONLY, NOFORMAT, NOINIT, 
	NAME = N'MyDB-Full Database Backup', NOSKIP, NOREWIND, NOUNLOAD, STATS = 10

Or, if you are using Ola Hallengren’s solution (which we are a major fan of):

Source code

EXECUTE [dbo].[DatabaseBackup]
@Databases = 'SentryOne',
@URL = 'https://mystorageaccount.blob.core.windows.net/mycontainer',
@Credential = 'https://mystorageaccount.blob.core.windows.net/mycontainer',
@BackupType = 'FULL',
@Verify = 'N',
@CheckSum = 'Y',
@LogToTable = 'Y',
@Compress = 'Y',
@CopyOnly = 'Y'

Then restore onto the other Managed Instance:

Source code

RESTORE DATABASE [MyDB] FROM URL = N'https://mystorageaccount.blob.core.windows.net/mycontainer/MyDB.bak'

Yeah, a bit cumbersome, but it works and runs, and solves the client’s problem.

Which?

As in all things SQL, it depends. For our client, the simple backup and restore was the solution. They were OK with data being up to 24 hours old for their reporting in this scenario.

If using the PowerShell cmdlets, the target database is unavailable for connections until you issue the Complete cmdlet. But it lets you copy multiple databases, not just one.

It really just comes down to what you are attempting to do. Honestly, for the customer, we could have easily used the PowerShell cmdlets to copy the database each night (deleting the database on the target Managed Instance before starting the copy) and that would eliminate the need to delete the file from blob storage.

So if you looking for ways of copying databases across SQL Managed Instances, you have several options.

The post Copying Databases Across SQL Managed Instances appeared first on SQL Solutions Group.

We’re two weeks into 2024 and I’m sitting here staring at my carousel M&M dispenser (it used to be full) of dark chocolate peanut M&Ms. Some people collect hats, stamps, or Lego sets. I collect M&M dispensers. I probably have 50 of them (and the dark chocolate peanut M&M is the ONLY way to go, btw), and I’m wondering what 2024 will bring.

And yes, that is a mic propped up on a mini Starbucks cup because my laptop mic sounds like crap. So I hooked that thing up, but it lacks a stand, so I’ll be ordering one of those.

Anyway, back to 2024.

I don’t want to turn this blog into a “look back at 2023” or “what could have been” post. I want to look forward. I mean, it’s 2024 and, barely two weeks in, a lot has happened. Microsoft has already released CU 11 for SQL Server 2022. Pete Carroll and Bill Belichick (two GREAT NFL coaches) were let go, and Nick Saban retired (a phenomenal college coach), all in the span of 24 hours.

Plus, for the past few days my laptop has been popping up messages that my Norton antivirus software has expired (and others), and I am not even running it. Looks like I’ll be paving my laptop this weekend. Ugh, welcome to 2024.

But honestly, I’m looking forward to 2024. From many perspectives, I think we are going to see great advancements, including in technology, that on one hand will make our lives easier, but also make our decisions a bit harder. My dad died last July, a week before his 90th birthday, and for the few months following, my bothers and I helped Mom clean and organize a lot of my dad’s things.

He had a lot of tools. A lot. It took us days just to go through his tools. I brought some back home with me. My dad had a really nice snow blower, because where he lived it snowed quite a bit, and he used it to clear the pathways of not only his house, but his neighbors’. He enjoyed bundling up and firing up his trusty mega snowblower 9000 (no, it’s not really called that), making mounds and piles of snow by clearing the sidewalks and walkways of his neighbors.

Where I live, it doesn’t snow that much, so I’m torn. I’d love for it to snow enough to justify firing up the snow blower, but I also DON’T want it to snow that much. When it does snow (like it did the other night), I’m looking at my inherited snow blower and snow shovels and wondering what the best tool for the job would be. My neighbors would probably get a kick out of seeing me fire that thing up for only a 1/8 of an inch of snow, which, if I just waited a couple of hours, would be gone anyway. *Sigh*

So, here I sit, two weeks into 2024, pushing the button on my carousel M&M dispenser waiting for it to drop out those precious dark chocolate peanut M&M’s, thinking about the upcoming projects and the technology available to me.

Do I use SSIS or Azure Data Factory? Would a particular client benefit from a distributed availability group? Why isn’t Query Store enabled at this other client? What about AI (have you seen the movies M3GAN and Moonfall?. Um, no.) I’m kidding a bit, because I just read a great blog post by Daniel Janik on how to use AI to generate test data in SQL Server.

Anyway, make 2024 a great one. Help others, be kind, play with awesome technology, and eat a bunch of dark chocolate peanut M&Ms (preferably out of a carousel dispenser).

The post The Right Tool for the Right Job appeared first on SQL Solutions Group.

Several of our clients have looked at a range of different solutions, such as copying “old” data to a different report or read-only server and hooking up a Linked Server through which to query the older data when needed. Another option is creating a “history” table in the same database and moving the older data to that table.

In both cases, this doesn’t solve the disk space issue, and it is still a costly storage solution. With the first scenario, I’m sure we have all been a little frustrated at the performance of Linked Servers at one time or another. In all cases, we had a requirements-gathering session with each client to determine several items, including:

• Does the archive data need to be queried, and if so, how often?
• How much data needs to be archived?
• Does referential integrity need to be kept between current and archive data?
• Is cloud storage an option?

There are other questions that we could ask, but these are the most critical because it establishes a baseline and determines the technology we can work with. In some cases, cloud storage is not an option, so we needed to stick with an on-premises solution. Where cloud storage was an option, that opened things up and we were able to look at and utilize some great technologies.

Now, where cloud storage wasn’t an option, there were still some things that we could look at that are strong, viable options, thus the topic of this blog. With SQL Server 2016, Microsoft added the ability to use PolyBase to query other SQL Server instances. This is a game changer, as PolyBase is very powerful. We at SSG set out to determine which is faster and more efficient, PolyBase or Linked Servers, when querying one SQL Server instance from another SQL Server instance.

Honestly, what we found was very surprising. Extremely surprising. Granted, all our tests were performed using SQL Server 2019 and SQL Server 2022, but even then, what we found was quite shocking.

I could walk through everything here, which would make for an extremely long blog, so I did a webinar on this exact topic with a lot of demos, discussion, and insights, and you can view it here. Let us know what you think as we always like to hear from you.

The post PolyBase vs Linked Servers  appeared first on SQL Solutions Group.

To be fair, I titled this blog “Automating Azure with Elastic Jobs”, but Elastic Jobs isn’t part of Azure Automation, so please don’t get confused. The goal with this is to demonstrate how to automate some Azure database DBA tasks.

What are Elastic Jobs?

Like my two previous blog posts and their respective topics, this blog isn’t a deep dive into Elastic Jobs. This isn’t an “Intro to Elastic Jobs” blog post. That is at least one or more blogs itself, and the purpose of this blog isn’t to dive deep into Elastic Jobs. Additionally, Elastic Jobs is in Preview, which means things may change.

Elastic Jobs allows you to run T-SQL scripts across multiple databases, in parallel. Yeah, totally cool. So for us at SSG, we have multiple clients that have their database environment in Azure, and they came to us asking how to do index maintenance. Well, HERE YA GO!

As I stated in my previous two blogs, those solutions work just as well. I’ve given you some options, and one solution might fit your environment better than the others. In fact, we have several clients using Runbooks or Azure Functions.

The way Elastic Jobs works is that you create jobs that are executed against one or more Azure SQL databases, and those jobs run T-SQL queries to perform the defined tasks. As part of setting up the Elastic Job, you define a set of target databases against which the job or jobs will be executed. Additionally, you can define schedules for those jobs. Pretty sweet.

So, with that foundation, let’s build an Elastic Job to optimize indexes.

Getting Started

Before we get started, I should mention there is a REALLY sweet demo of this on Microsoft Learn here. So why am I covering it in this blog? Simple. The example on Microsoft Learn creates EVERYTHNG needed for the demo. And I mean EVERYTHING, including databases, resource groups, the whole 9 yards. It is a great way to get started with Elastic Jobs if you are new to it. I ran the demo just to get familiar with it. So if you want to just learn about Elastic Jobs, stop reading, click the link above, and enjoy.

However, in my scenario, I already had the databases, resource groups, and some of the other objects, so I needed to tweak the demo to fit my needs. Essentially, this tells the script “hey, I already have some of these things, so don’t do x and y”.

To get started, we need a few things:

1. A couple of Azure SQL databases
2. Ola Hallengren’s index optimize script
3. An Azure Elastic Job Agent
4. The Az PowerShell module

Create the Databases

For this blog, I simply created two new General Purpose databases, based off of the Sample database.

Run the Scripts

With the databases created, the next step is to add the appropriate components to the database to do the index optimization. We at SSG are huge fans of Ola Hallengren and his Maintenance Solution, and you can get his awesome scripts here.

The IndexOptimize.sql script will run in Azure, but you will also need to download the CommandLog.sql and CommandExecute.sql files as well. Run all three of those in the database you just created. Start with the CommandExecute.sql, then the CommmandLog.sql, then the IndexOptimize.sql.

Create the Elastic Job Agent

With everything prepared, the next step is to create the Elastic Job agent. In the Azure Portal, create a new resource, and in the search box type “elastic job” in the search bar and select elastic job agent.

Click Create.

It is pretty straight forward; give the agent a name and select the same subscription in which you created the sample databases, then click Review + Create.

PowerShell

If you read the Microsoft Learn doc I linked to above, it shows how to create the appropriate objects using PowerShell. There is a similar tutorial which does everything in T-SQL. This blog will use PowerShell, but you can do the same thing in T-SQL.

For what I needed, I copied everything from the doc into PowerShell, then started hacking. I cut what I didn’t need, modified some things, and tested and tested until it worked the way I wanted it. The code below represents the final results.

This code assumes you already have a resource group, Azure SQL Server, and some other things. It does create the JobDatabase database, which I am OK with, but other than that, it just creates all the Elastic Job stuff. As an FYI, the job database is the database the job agent uses to store job related data, job definitions, etc. It is recommended that this database be a clean, empty database, at an S1 service level or higher. Thus, my code below creates a brand-new database for this.

In this example, I create a group, which by default adds all the databases on the server, but then I tell it to EXCLUDE the jobs database. You can see that I have lines of code which are commented out that add the two sample databases. I could not get those two lines of code to work for the life of me, and I’ll attribute that to the fact that this is in preview. The only way I could get it to work was to create the group but exclude the jobs database.

At the very end, the code creates a job, then creates a schedule for that job. The job creation specifies the T-SQL to run, which is the index optimize stored procedure. There is also commented code at the end which will start a new execution of the job if you would like, otherwise it will kick off at the scheduled time.

NOTE: As noted earlier, you will need the Az PowerShell module. An important note here is that the very first line imports the Az module, so if you haven’t previously installed this PowerShell module, you will need to do so by executing Install-Module Az.

Source code

Import-Module Az
Connect-AzAccount -Subscription '<your azure subscriptionid>' -Tenant '<the Tenant ID>'
 
$resourceGroupName = "<your existing resource group name>"
$adminLogin = "<your Azure SQL Server login>"
$adminPassword = "< your Azure SQL Server password>"
$adminPasswordSecure = ConvertTo-SecureString -String $AdminPassword -AsPlainText -Force
$adminCred = New-Object -TypeName "System.Management.Automation.PSCredential" -ArgumentList $adminLogin, $adminPasswordSecure
$agentServer = "<your Azure SQL Server>"
$ejagentName = "<Your Elastic Job Agent name>"
 
# create the job database
Write-Output "Creating a blank database to be used as the Job Database..."
$jobDatabaseName = "JobDatabase"
$jobDatabase = New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $agentServer -DatabaseName $jobDatabaseName -RequestedServiceObjectiveName "S1"
$jobDatabase
 
Write-Output "Getting databases..."
$db1 = Get-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $agentServer -DatabaseName "database1"
$db1
$db2 = Get-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $agentServer -DatabaseName "database2"
$db2
 
 
Write-Output "Creating job agent..."
$agentName = $ejagentName
$jobAgent = $jobDatabase | New-AzSqlElasticJobAgent -Name $agentName
$jobAgent
 
# in the master database (target server) create the master user login, master user, and job user login
Write-Output "Creating logins and users..."
$params = @{
  'database' = 'master'
  'serverInstance' =  $agentServer + '.database.windows.net'
  'username' = $adminLogin
  'password' = $adminPassword
  'outputSqlErrors' = $true
  'query' = 'CREATE LOGIN masteruser WITH PASSWORD=''<provide a password>'''
}
Invoke-SqlCmd @params
 
$params.query = "CREATE USER masteruser FROM LOGIN masteruser"
Invoke-SqlCmd @params
$params.query = 'CREATE LOGIN jobuser WITH PASSWORD=''<provide a password>'''
Invoke-SqlCmd @params
 
# for each target database
# create the jobuser from jobuser login and check permission for script execution
$targetDatabases = @( $db1.DatabaseName, $Db2.DatabaseName )
$createJobUserScript =  "CREATE USER jobuser FROM LOGIN jobuser"
$addrolememberScript = "EXEC sp_addrolemember 'db_owner', 'jobuser';"
 
$targetDatabases | % {
  $params.database = $_
  $params.query = $createJobUserScript
  Invoke-SqlCmd @params
  $params.query = $addrolememberScript
  Invoke-SqlCmd @params
 
}
 
# create job credential in Job database for master user
Write-Output "Creating job credentials..."
$loginPasswordSecure = (ConvertTo-SecureString -String '<enter a password>' -AsPlainText -Force)
 
$masterCred = New-Object -TypeName "System.Management.Automation.PSCredential" -ArgumentList "masteruser", $loginPasswordSecure
$masterCred = $jobAgent | New-AzSqlElasticJobCredential -Name "masteruser" -Credential $masterCred
 
$jobCred = New-Object -TypeName "System.Management.Automation.PSCredential" -ArgumentList "jobuser", $loginPasswordSecure
$jobCred = $jobAgent | New-AzSqlElasticJobCredential -Name "jobuser" -Credential $jobCred
 
 
Write-Output "Creating test target groups..."
# create ServerGroup target group
$serverGroup = $jobAgent | New-AzSqlElasticJobTargetGroup -Name 'ServerGroup'
$serverGroup | Add-AzSqlElasticJobTarget -ServerName $agentServer -RefreshCredentialName $masterCred.CredentialName
$serverGroup | Add-AzSqlElasticJobTarget -ServerName $agentServer -DatabaseName $jobDatabase.DatabaseName -Exclude
#$serverGroup | Add-AzSqlElasticJobTarget -ServerName $agentServer -DatabaseName $db1.DatabaseName -RefreshCredentialName $masterCred.CredentialName
#$serverGroup | Add-AzSqlElasticJobTarget -ServerName $agentServer -DatabaseName $db2.DatabaseName -RefreshCredentialName $masterCred.CredentialName
 
 
Write-Output "Creating a new job..."
$jobName = "IndexOptimize"
$job = $jobAgent | New-AzSqlElasticJob -Name $jobName -RunOnce
$job
 
Write-Output "Creating job steps..."
$sqlText1 = "EXECUTE [dbo].[IndexOptimize] @Databases = 'USER_DATABASES', @UpdateStatistics = 'ALL', @LogToTable = 'Y'"
 
$job | Add-AzSqlElasticJobStep -Name "Index Optimize User Databases" -TargetGroupName $serverGroup.TargetGroupName -CredentialName $jobCred.CredentialName -CommandText $sqlText1
 
 
Write-Output "Scheduling the job..."
$job | Set-AzSqlElasticJob -IntervalType Day -IntervalCount 1 -StartTime ('11/23/2022 20:00:00') -Enable
#$job | Set-AzSqlElasticJob -IntervalType Hour -IntervalCount 1 -StartTime ('11/17/2022 10:00:00') -Enable   #set to  hour for testing
 
#Write-Output "Start a new execution of the job..."
#$jobExecution = $job | Start-AzSqlElasticJob
#$jobExecution

And there you have it, you have successfully created an Azure Elastic Job to automate your index optimization.

Selecting the Elastic Job agent in the portal, on the Overview page you will see the last 100 job executions:

Selecting the Jobs page will list all the jobs associated with the Elastic Job agent.

Pros and Cons

Having worked with this for a while, there were some things that I want to highlight in terms of what I liked and some areas that could be better.

I’ll start with the Cons. I’m not a PowerShell guru so it took me a while to get the PowerShell exactly right. A part of that struggle could be, again, that this is in preview and so everything isn’t completely “baked”. Additionally, the UI isn’t the best but I know Microsoft is working on that and should have a better UI experience once released.

In the “pros” category, I like the fact that there is no timeout issue that you have with Runbooks and Azure Functions. That is awesome. I also love that you can create a group, add and remove databases from it, and done. Run your stuff against one or more databases. BAM! Lastly, you can do all of this in either PowerShell or T-SQL. Slick.

Reading the last couple blogs posts was probably an eye sore, as there were a ton of steps to get Azure automation created, etc. For Elastic Jobs, a couple of clicks, done. Again, the hard part was getting the PowerShell correct.

Summary

This blog post just scratches the surface of what Elastic Jobs can do, but we often see companies not doing index maintenance in Azure because either they don’t know how to do it or it is too difficult. Hopefully this will help get people going.

Hey, if you need help with any of this, ping me! I’m happy to help!

The post Index Maintenance: Automating Azure with Elastic Jobs appeared first on SQL Solutions Group.

What are Azure Functions?

Just as I did in my last blog post, let me begin by stating that this isn’t a deep dive into Azure Functions. We could do a whole series of posts just on Azure Functions itself, but for the purposes of this blog, I’ll do a brief introduction and summary simply to lay the appropriate foundation for this blog.

Azure Functions is an Azure serverless solution that provides compute on demand. The goal with Azure Functions is to provide a platform the enables you to write less code and deploy that code without maintaining a lot of infrastructure, all while supporting the demand needs. In other words, you write and deploy the code, Azure takes care of everything else. As incoming requests increase, Azure Functions automatically scales to meet the demand, and then as requests decrease, so do the resources.

Azure Functions offers different hosting plans, so you will want to become familiar with those if you are planning on using this service. There are three hosting plans:

• Consumption – Instances of Azure Functions are dynamically added and removed based on the number of incoming requests/events.
• Premium – A dynamic scale hosting option that provides additional benefits for your functions.
• Dedicated (App Service) – Defines a set of dedicated resources for an app to run.

You can read more about the different hosting options here.

There are wide number of different scenarios in which to use Azure Functions, including processing data in real time, analyzing IoT data, building serverless workflows, and the topic which will be covering today, running scheduled tasks.

Obviously, there is much more to azure Function, but this should be enough to get us started, so with this foundation, let’s build an Azure Function to optimize indexes.

Getting Started

To get started, there are several things we need:

1. An Azure SQL database
2. Scripts to do the index optimize
3. Visual Studio

For Visual Studio, you will need the Azure Development components to get the Azure Function tools. Run the Visual Studio installer if needed and select the Azure Development component.

Create the Database

I discussed this process in the previous blog, but in case you didn’t read that one, I’ll walk through this again. For this demo, I simply created a new General Purpose database, based off of the Sample database. For the purposes of this blog, no other configuration is needed.

Run the Scripts

With the database selected, the next step is to add the appropriate components to the database to do the index optimization. We at SSG are a huge fan of Ola Hallengren and his Maintenance Solution, and you can get his awesome scripts here.

The IndexOptimize.sql script will run in Azure, but you will also need to download the CommandLog.sql file as well. Run both of those in the database you created.

Create the Azure Function App

With everything prepared, the next step is to create the Azure Function App. In the Azure Portal, type “Function App” in the search bar and select Function App.

Click + Create.

There are a few things you will need select and fill out on most of the tabs, so we’ll walk through those.

Basics

In the Basics tab of the Create Function App, select the Subscription and Resource group, then provide an account name and region.

Additionally, you will need to indicate what you are publishing (in this case, some code), the runtime stack (I’m using .NET), the .NET version, and the region in which you want to create this Function App.

Lastly, select the operating system (due to my selections, only Windows is supported), and then select the plan type.

Hosting

Select the Hosting tab, and either select an existing storage account or create a new one.

Networking

On the Networking tab, select Off for Enable public access. Since this is running within Azure and you aren’t accessing from outside of Azure, there is no need to enable public access.

Monitoring

On the monitoring tab, select to either enable or disable Application Insights. Application Insights provides performance monitoring for your application by collecting metrics and telemetry data and storing those in a blob storage account. You can then view this information as a way to see how your application is doing. The more you work with Azure Functions (and Azure in general), it might be worth enabling this. As you are testing, you could probably leave it off.

Deployment

Unless you are doing any type of source control for your code with GitHub, leave the continuous deployment disabled. As you start doing more with Azure Functions, you might consider turning this on and doing more with source control and continuous deployment.

Don’t worry about anything on the other tabs. Click Review + Create to create the Function App. At this point you have the basis to start automating, and we’ll do that with Visual Studio.

Create the Azure Function

The next step is to create the function to run the index maintenance. Fire up Visual Studio and create a new project. Search for Azure Functions and select the Azure Functions project type, then click Next.

Give your project a name, and then click Next.

This next step is an important one, as you are asked to select what type of Azure Function application you want to create. As you can see in the following image, there are a lot of different types. Since we want to run our index maintenance on a schedule, select the Timer Trigger.

You are probably asking how the timer or schedule is defined. In the following screenshot you can see a schedule to the right with some funky format. Don’t worry, I’ll get to that shortly, so for now just click Create.

The project will be created and a default function will be added, as shown in the following screenshot.

For clarity, delete Function1 from the project, then right click the project and select Add -> New Azure Function. In the Add New Item dialog select Azure Function and name it AzureMaintFunction. Click Add.

For the type, select Timer trigger, leave the schedule format as is (I’ll get to that shortly) and click Add.

Now we have a project and function with a meaningful name. 😊

OK, since the function is accessing a SQL database, the next step is to add the appropriate dependencies. Click on the Project menu, then select Manage NuGet packages. In the NuGet Package Manager, select nuget.org as the Package source, then search for system.data and select the System.Data.SqlClient package and click install.

Once it is installed, add System.Data and System.Data.SqlClient references to the type of the Function.

Finally, it is time to add some code to your function. Copy and paste the following code into the Run method of the function, below the log.Info line.

There are a few values you will need to replace in the code. Replace <server> with the actual name of your Azure SQL Database server, replace <user> with the username, then replace <pwd> with the password.

Source code

USING (VAR conn = NEW SqlConnection("Server=tcp:<server>.database.windows.net,1433;Initial Catalog=database4;Persist Security Info=False;User ID=<user>;Password=<pwd>;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=3600;"))
 
{
 
try
 
{
 
SqlCommand cmd = NEW SqlCommand();
 
cmd.CommandText = "IndexOptimize";
 
cmd.PARAMETERS.ADD("@Databases", SqlDbType.NVARCHAR);
 
cmd.PARAMETERS["@Databases"].VALUE = "USER_DATABASES";
 
cmd.PARAMETERS.ADD("@UpdateStatistics", SqlDbType.NVARCHAR);
 
cmd.PARAMETERS["@UpdateStatistics"].VALUE = "ALL";
 
cmd.PARAMETERS.ADD("@LogToTable", SqlDbType.NVARCHAR);
 
cmd.PARAMETERS["@LogToTable"].VALUE = "Y";
 
cmd.CommandType = CommandType.StoredProcedure;
 
cmd.CONNECTION = conn;
 
conn.OPEN();
 
cmd.ExecuteNonQuery();
 
}
 
catch (EXCEPTION ex)
 
{
 
LOG.Info(ex.Message);
 
}
 
}

Before moving on, I’ll explain what this code does. First, this defines a connection to the Azure SQL Database. A critical piece of the connection string is the Connection Timeout. This is critical to remember, as it is standard .NET stuff. As I explained in the previous blog post, if the IndexOptimize stored procedure does NOT complete before the timeout period is reached, it will time out and roll back the item it is currently working on.

Unlike PowerShell, the SQLConnection has a default timeout, so even if you omit the Connection Timeout parameter, it will still timeout after the default time. So for Azure Functions, you will need to know roughly how long the index optimize will take and set the timeout appropriately.

The rest of the code defines the parameters being passed to the IndexOptimize stored procedure, then opens the connection and executes the query.

OK, let’s discuss the timer trigger. Azure Functions timer trigger uses the NCronTab library which is super similar to the CRON expressions. The difference is that the NCronTab library uses an additional sixth field at the beginning for a time precision in seconds.

Thus, the format looks like this:

{second} {minute} {hour} {day} {month} {year}

You can read more about Azure Function timer triggers here, and NCrontab for .NET here.

So, the default timer essentially has the function firing 12 times an hour, or at second 0 of every 5^th minute of every hour each day. Not what we want.

For simplicity, I just want my function to fire every day at 10pm, Monday through Saturday (day 0 is Sunday). So, I change the timer as follows:

Thus, it will automatically fire Monday through Saturday at 10pm.

Deploy the Function

The next step is to Deploy the function. First, build the project to ensure it compiles, then right click the Project and select Publish.

In the Publish dialog, select Azure.

If prompted to sign in, do so.

Lastly, select the subscription if not already populated, then in the Function Apps area, select the Function App you created earlier, then click Finish.

The Function will be published and after a few minutes you will be informed that the publish has, hopefully, been successful.

You can tell the history of the events, or runs, of the functions by looking in the Azure portal at your Azure Function and looking at the Monitor.

And there you have it, you have successfully created an Azure Function to automate your SQL index maintenance.

Pros and Cons

Having worked with this for a while, there are some things that I want to highlight in terms of what I liked and some areas that could be better.

In the “pros” category, I like that you can do this right in Visual Studio (or even VSCode), and the Azure Functions template make it super easy to use and work with Azure Functions. Sweet. It was also pretty easy to publish the function. Very sweet.

I haven’t tested it yet but since it is standard .NET I’m hoping you can “obfuscate” critical variables, such as username and passwords by putting them in an app.config.

For the downsides, just like Azure Automation and Runbooks, it is “per database”, meaning, even though the query says “User Databases” (if you are familiar with Ola’s scripts), it is ONLY going to run the index optimize against the database specified in the parameter. That is just a limitation of Azure, not the Runbook. Thus, if you want to optimize indexes against multiple databases, you need multiple Functions or modify the one function to connect to multiple databases. This can get kinda messy.

CRON Expressions. Ugh. Once you work with them a bit it gets easier, but I had to do a lot of reading just to get started with them.

Summary

This blog post just touches the surface of what Azure Functions can do, but we often see companies not doing index maintenance in Azure because either they don’t know how to do it or it is too difficult. Hopefully this will help get people going.

In the next two blog posts I’ll show how to do the same thing using Azure Elastic Jobs.

The post How To: Running SQL Jobs with Azure Functions appeared first on SQL Solutions Group.

Follow-up blog posts will discuss doing the same thing using Azure Functions and Azure Elastic Jobs.

What is Azure Automation?

Let me begin by stating that this isn’t a deep dive into Azure Automation, simply because we could do a whole blog series just on that. Let us know if you’d like to see that!. This will provide a quick intro and summary of what Azure Automation is to lay the appropriate foundation for this blog.

In its simplest terms, Azure Automation is a cloud-based automation service that allows you to orchestrate and automate processes across your Azure and non-Azure environments. Azure Automation allows you to use several methods for accomplishing this, including Powershell and Python to provide the process automation capabilities.

Process Automation is a key tenet of Azure Automation, and provides the ability to automate many of the repetitive tasks or processes in Azure. The key to enabling Process Automation is contained within an operating environment within Azure Automation called Runbooks.

Runbooks

A Runbook is the component within Azure Automation which enables the automation of repetitive and time-consuming tasks in Azure. In their initial incarnation, Runbooks were simply Powershell workflows that contained the automation logic you wished to implement.

Since then, Runbooks have been expanded to include and support both Python and graphical type Runbooks. For the purposes of this blog, we will create and use a Powershell Runbook. Azure Automation executes the Runbook based on the logic defined within the Runbook, which constitutes a single execution instance of the Runbook.

So, with this foundation, let’s build a Runbook to optimize indexes.

Getting Started

To get started, we need:

1. An Azure SQL database
2. Scripts to do the index optimize
3. An Azure Automation Account (and Runbook)

Create the Database

For this blog, I simply created a new General Purpose database, based off of the Sample database. For the purposes of this blog, no other configuration is needed. 

Run the Scripts

With the database selected, the next step is to add the appropriate components to the database for index optimization. We at SSG are huge fans of Ola Hallengren and his Maintenance Solution. Get his awesome scripts here.

The IndexOptimize.sql script will run in Azure, but you will also need to download the CommandLog.sql file as well (run this one first). Run both of those in the database you created.

Create the Azure Automation Account

With everything prepared, the next step is to create the Azure Automation account. In the Azure Portal, type “automation” in the search bar and select Automation Accounts.

Click + Create.

In the Basics tab of the Create an Automation Account, select the Subscription and Resource group. Then provide an account name and region. 

Don’t worry about anything on the other tabs. Click Review + Create to create the Automation Account. At this point you have the basis to start automating. We’ll do that next by creating a Runbook.

Create the Runbook

The next step is to create the Runbook. In the Navigation pane, scroll down to the Process Automation section and select Runbooks.

You’ll see a list of default Runbooks, but create a new one by clicking on the + Create a runbook button.

In the Create a runbook page, provide a name for the Runbook (I used IndexOptimize for this example). Then select PowerShell for the Runbook type, and select the Runtime version of 7.1.

Click Create.

You’ll see a blank canvas with which to enter your PowerShell code.

In the right pane, enter the following PowerShell code (I’ll walk through it shortly):

$SQLServerName = Get-AutomationVariable -Name "sqlserver"

$database = Get-AutomationVariable -Name "database"

$username = Get-AutomationVariable -Name "username"

$password = Get-AutomationVariable -Name "password"

Invoke-Sqlcmd -ServerInstance $SQLServerName -Database $database -Username $username -Password $password -Query "EXECUTE [dbo].[IndexOptimize] @Databases = 'USER_DATABASES', @UpdateStatistics = 'ALL', @LogToTable = 'Y'" -QueryTimeout 65535 -ConnectionTimeout 60 -Verbose

Click Save.

We haven’t yet published at this point, which you will do once you have tested it. But before you do that, you need to configure some variables. So, go back to your Automation Account and in the navigation pane scroll down to the Shared Resources section. Select the Variables page.

Click on the Add a variable button and add the four variables used in the code above (and as listed in the image below). Specify the appropriate values for each. In this example, for simplicity’s sake, we are just using SQL Authentication.

Now it’s time to test. Go back and select your Index Optimize Runbook, then click the Edit button. Before we test it, I’ll explain what the code is doing. The first four lines grab the values from the variables in order to connect to the Azure server and database.

The next line simply calls the PowerShell Invoke-Sqlcmd cmdlet, passing it the parameters from the first four lines, as well as a query to execute. In this case, it’s Ola’s IndexOptimize stored procedure installed earlier. In this example we are simply passing some default values to the stored procedure. If you want to know what values you should be passing in your environment, feel free to reach out to us at in**@***************up.com 😊).

Now, the key to all of this is the -QueryTimeout parameter. The Runbook is essentially executing a query just like you normally would in Powershell or any other application that connects to a database.

Note: In this example, I have specified a timeout value. If you look at the Powershell documentation for the Invoke-Sqlcmd cmdlet, omitting the parameter means that the query will not timeout.

That last part is important because if you specify a timeout period and the IndexOptimize stored procedure does NOT complete before the timeout period is reached, it will time out and roll back the item it is currently working on. So, either omit the timeout parameter or know how long the job will run.

It is now time to test it. Click on the Test pane button. 

Click the Start button to run the code. 

The job will be queued and then run. Because I included the -Verbose parameter, when the job finished my test window looks like this:

You can also validate that it ran by connecting to the database and querying the CommandLog table.

Now that it has successfully run, you need to publish it. Edit the Runbook, then click Publish.

Let’s put a schedule on it. Go back to your Azure Automation account. Scroll down again to the Shared Resources section, and select the Schedules page.

Click on + Add a schedule, then in the New Schedule blade configure the schedule however you would like, including recurrence and frequency.

Next, click Create, then go back to your Runbook and in the Resources section select Schedules:

Click on + Add a schedule, then select the option to link a schedule to your runbook.

From there, select the schedule you created earlier, then click OK.

And there you have it: you have successfully created an Azure Automation and Runbook to automate your index optimization.

Pros and Cons of Azure Automation and Runbooks

Having worked with this for a while, there were some things that I want to highlight in terms of what I liked and some areas that could be better.

In the “pros” category, it was super easy to get started and going with it. I had it running in only a few hours, and that was not knowing anything about it when I began this journey a few months ago. I love the flexibility of being able to use PowerShell, Python, or a graphical interface to build the Runbook. Awesome.

I also love that I can obfuscate critical values with variables and schedule the Runbook. Sweet. And I can test the Runbook with a UI in the portal prior to publishing and scheduling. Even sweeter.

For the downsides, it is “per database.” Meaning that even though the query says “User Databases” (if you are familiar with Ola’s scripts), it is ONLY going to run the index optimize against the database specified in the parameter. That is just a limitation of Azure, not the Runbook. Thus, if you want to optimize indexes against multiple databases, you need multiple Runbooks. Or, modify the one Runbook to connect to multiple databases. This can get kinda messy.

You also need to play with the -Timeout parameter, or not include it at all.

Summary

This blog post just touches the surface of what Azure Automation and Runbooks can do. We often see companies not doing index maintenance in Azure because either they don’t know how to do it or it is too difficult. Hopefully this will help get people going.

In the next post in this series, I’ll show how to do the same thing using Azure Functions.

The post How To: Azure Automation and Runbooks appeared first on SQL Solutions Group.

This is an introduction to an upcoming series of posts dedicated to supporting you and addressing the different ways to not only do index maintenance, but also generally how to run SQL jobs in Azure. I’ll use the topic of index maintenance in Azure as the example.

A large trend we have been seeing lately is companies and organizations calling us to help improve and troubleshoot their Azure SQL Database performance and related issues. We always begin with a deep analysis, looking at queries, indexes, and configuration settings as part of a top-down, wholistic analysis.

Nine times out of 10, we find that one of the main things that is missing is traditional index maintenance. I believe this is due in large part to a misunderstanding of what Azure actually provides. It could be because the Azure portal has a section for each Azure SQL Database called Intelligent Performance. It provides Performance Recommendations as well as automatic tuning, and has likely led some to believe that Azure automatically does some level of index maintenance (i.e., updating statistics, rebuilding indexes, etc.).

While Azure does do a lot of things for you, maintaining indexes and statistics is not one of them. That is still up to you. The problem is that Microsoft does not currently make doing this easy. But we’re here to help!

Over the next few blog posts I’ll be covering three main ways to run SQL jobs in Azure:

• Azure Automation and Runbooks
• Azure Functions
• Azure Elastic Jobs

In each blog post, I’ll discuss the pros and cons of each, provide an example of how to set up and configure them, and what to expect in each each.

While there are certainly other ways to run SQL jobs in Azure, the aforementioned three are the primary “go-to” options. Join me for this exploration of Azure SQL!

The post Run SQL Jobs in Azure: A Prologue appeared first on SQL Solutions Group.

If you are still running SQL Server 2012, you don’t have much time until Microsoft no longer supports it. Microsoft provides mainstream support for a product for five years, during which time they add features and enhancements (along with bug fixes and security patches) to the product. After that, you typically get another five years of extended support. During this period, Microsoft only provides bug fixes and security patches. With SQL Server 2012, mainstream support ended four years ago (July 2017), and extended support ends July 2022.

This post, the first in a series covering several aspects of migration, isn’t about what you should migrate to, but, as the title suggests, why you should consider it. We’ll also address upgrade too, because the decision you need to make is: do you migrate (different platform), or upgrade (different version), or both?

There are many different reasons we would give as to why migrate SQL Server (or upgrade), but this post will only list a few and focus on the top reasons we see or have discussed with our clients. These are in no particular order.

End of Support

Depending on who you are, this is either a big deal, or it isn’t. The old adage “if it ain’t broke, don’t fix it” is still very alive and well in some places. For others, EOS is certainly a big deal because, after extended support ends, you won’t see any more bug fixes or security patches. With all the hacking and data stealing lately, we highly recommend you don’t run anything that you haven’t properly secured. Your cyber defenses are down and that makes you extremely vulnerable to threats and cyberattacks.

Cost

One of the reasons we hear occasionally for not migrating or upgrading is the cost. In our view, however, you can’t afford not to upgrade/migrate. We find, in many cases, it is more costly to maintain existing, aging environments than it is to upgrade or migrate.

Performance

Unless you are running super archaic hardware, did you know that you can get tremendous performance boosts and improvements just by upgrading to SQL Server 2016 or later? Microsoft made significant tremendous improvements and enhancements to SQL Server 2016 and later versions. These improvements help SQL Server take advantage of recent hardware architecture changes. If you don’t believe me, here is a video I did when I was at Microsoft with the one and only Bob Ward, along with Bob Dorr, which explain the how and why.

New Features/Functionality

The “upgrade for the new features” reason is one you have heard a gazillion times, so I won’t spend too much time on this. But, it should be part of your considerations. Simply put, SQL Server 2016 introduced the Query Store, and that alone is worth upgrading for the ability to find query bottlenecks and performance differences caused by query plan changes. There’s a reason it is Azure SQL Database enables bit by default <wink>. And you can’t (or shouldn’t) ignore many of the security and other performance features from post-2012 versions. A quick internet search will show you all the goodness you’re missing.

Cloud Benefits

I’ll wrap up with a word on the cloud, and this is one that we wish more companies and individuals would grok. With SQL Server 2012 coming to EOS, one of the targets you should consider is a cloud platform. Yes, I did say this isn’t a “what to migrate to” post, so let me explain why you should consider a cloud platform. There are many benefits, and I believe the biggest reasons include, but are not limited to, the opportunity to reduce on-premises infrastructure complexity, increase security, and reduce costs. More and more companies are moving to the cloud to reduce the cost of data management, and the security measures implemented by most cloud vendors are outstanding.

Conclusion

We could easily discuss many more items to consider around the topic of why migrate SQL Server. The goal is to touch on the top few and help you get the thought process started. And as always, we are here to help, even if only to discuss some of these reasons in more glorious detail.

The post SQL Migration Steps: #1 Why Migrate SQL Server? appeared first on SQL Solutions Group.

With this, you can route connections specified as read-only to a secondary replica configured as a secondary role. Not too long ago, you had to configure read-only routing using T-SQL or PowerShell. Anyone that has done read-only routing using T-SQL knows that it can be a bit tricky to get it right. However, it wasn’t too long ago that Microsoft added the capability to configure read-only routing to the Availability Group Properties dialog.

If you’ve been following us lately and reading our recent blog posts, you know that Randy and I recently took it upon ourselves to only use Azure Data Studio whenever possible. Unfortunately, ADS doesn’t have an option for working with Always On availability groups. There also isn’t a decent extension out there that does … yet. Hehe. Anyway, for this exercise we turned to the trusty SQL Server Management Studio.

Configuring Read-Only Routing

Configuring read-only routing using the UI is quite easy. It simply requires two steps:

• For each readable secondary replica that you want to support read-only routing, specify a read-only routing URL.
• For each replica in the AG that you want to support read-only routing when it is the primary replica, specify a read-only routing list.

In this example, we have two nodes, we’ll call them SQL01 and SQL02. When SQL01 is the primary, we want SQL Server to route all read-only connections to the secondary replica. If the secondary replica isn’t available, send the connections to the primary. To do that, we select the appropriate replicas, in order, from the Available replicas box and move them over to the Read-only routing list.

Thus, we select SQL01 in the top box. Then in the Available Replicas box, we first select SQL02 and add that to the routing list, followed by SQL01. In this way, SQL Server routes all read-only connections to the secondary replica, SQL02. If SQL02 isn’t available, the connections go to SQL01.

We repeat the process for SQL02, but in reverse. In the Available Replicas box, we first select SQL01 and add that to the routing list, followed by SQL02. In this way, SQL Server routes all read-only connections to the secondary replica, SQL01. If SQL01 isn’t available, the connections go to SQL02.

What I like about this is that when you first open the dialog and select the Read-only routing page, the Routing URL values are already filled in for you. You just need to specify the list. Sweet. After you configure everything, it should look something like the following.

You don’t need to add both nodes to the routing list. You can only list the secondary replica in the routing list, but it is nice to have a fallback if the secondary replica isn’t available.

One Final Note: T-SQL

If you haven’t done this with T-SQL, there’s a nifty option here. Once you have configured read-only routing, before you click OK, script the actions to a new query window so you can see what the T-SQL looks like:

USE [master]
 GO
 ALTER AVAILABILITY GROUP [SQLAG01]
 MODIFY REPLICA ON N'SQL01' WITH (PRIMARY_ROLE(READ_ONLY_ROUTING_LIST = (N'SQL02',N'SQL01')))
 GO
 USE [master]
 GO
 ALTER AVAILABILITY GROUP [SQLAG01]
 MODIFY REPLICA ON N'SQL02' WITH (PRIMARY_ROLE(READ_ONLY_ROUTING_LIST = (N'SQL01',N'SQL02')))
 GO

The post How To: Configure Read-Only Routing for Availability Groups appeared first on SQL Solutions Group.

As of this writing, the latest version of SSMS is 18.8. ADS has been included with the SSMS install since version 18.7. What annoyed me is that it didn’t give me the option to install it; Microsoft forced it on me. Meaning, if I wanted the latest SSMS, I’ll also get ADS if I want it or not.

This bothered me for a couple of reasons. First, why is Microsoft forcing ADS on me? That just does not seem right. Second, the last time I used ADS, which was, admittedly, quite some time ago, it was super light on the functionality I need as a DBA. So, after I stewed a bit, I thought I needed to “back the bus up” and think about this a little more — approach ADS from a different angle. I realized I didn’t know enough about ADS to know if it is a tool I can use every day in my role as a DBA.

Some Background

It isn’t a secret that, up until a few years ago, SSMS was getting long in the tooth. Meaning, Microsoft updated it only when they updated SQL Server. As such, you had to wait until the next release of SQL Server to get any updates to SSMS. And even then, it was still looking its age.

That changed not long ago when Microsoft decided to decouple the SSMS install from the SQL Server install, allowing regular updates for and bug fixes for SSMS. The UI hasn’t changed but at least it’s getting some regular love. However, the winds of change also dictated that we needed something newer and more effective to support both on-premises and the cloud, and across platforms. SSMS is Windows only, and with SQL Server now supporting Linux, it was time for some changes.

The answer was Azure Data Studio (initially released in 2018 and known as SQL Operations Studio), a cross-platform tool that, as the Microsoft documentation states, is “for data professionals using on-premises and cloud platforms” that works on Windows, macOS, and Linux. I could not agree more with the cross-platform support, as this is definitely needed. But, I keep getting caught up on the “for database professionals” part.

Here’s the thing: If Microsoft is going to force ADS on me, it needs to provide a decent level of DBA coverage in terms of features and functionality, comparable to SSMS. I’m a database professional, and the last time I used ADS, it was missing a lot of the UI features and functionality for managing database environments. Is that still the case? Can I manage availability groups (AGs) or dig into the Query Store? Can I even mouse click on the databases node and select “new database”?

I’ll be honest though. The truth is I’ve had ADS installed for a LONG time, and I keep it up to date (just like SSMS, it has monthly updates). But, I rarely use it. So why do I have it installed? I don’t know…probably because somewhere deep in my psyche I want to believe and just haven’t made the leap.

The Challenge

Thus, my quest of recent has been to do a deep analysis of both tools and determine if I am underselling ADS; and, can I be more efficient as a DBA using it? Or, are these for two completely different audiences?

I had questions, and I needed answers. Part of the research included talking to one of the PMs on the tooling team and getting some insight. And now the time has come to step up, dig in, and do my due diligence.

As Randy mentioned in his latest blog post, we’re going to take the leap and use Azure Data Studio exclusively (or as exclusively as possible) for the next 30 days. In fact, as you read this, we’ll have already started. I’ll report on my experience in a free webinar on March 17. Sign up for the webinar and learn what Randy and I learned over the 30 days. Randy and I are also going to blog about our experiences, so stay tuned for those as well.

With the luck of the Irish, all will go well! Join me on the 17^th and find out who wins this battle.

The post SQL Server Management Studio vs. Azure Data Studio appeared first on SQL Solutions Group.