Geek Sync | Planning a SQL Server to Azure Migration in 2021 - Brent Ozar

© Brent Ozar Unlimited®. All rights reserved. 1
Planning a SQL Server to
Azure Migration in 2021
99-05: dev, architect, DBA
05-08: DBA, VM, SAN admin
08-10: MCM, Quest Software
Since: consulting DBA
www.BrentOzar.com
Help@BrentOzar.com

Today’s session
You manage database servers for your company, and
they're thinking about migrating everything to Microsoft
Azure. You've searched the web for information and advice,
but everything you're finding is outdated.
You just want a list of things to review on your servers, an
overview of what won't work in the cloud, and how to pick
alternatives or workarounds.
In this one-hour session, we'll cover pure technical details,
zero marketing, and get you up to speed quickly.
Out of scope today
Software-as-a-service shops (one db per client)
Methods of moving data (log shipping, replication)
Other cloud vendors
Hybrid environments

Migration steps
1. Which Azure service should you migrate to?
2. How do you work around unavailable services?
3. How do you provision the right power?
4. How do you tune once you’re there?
1. Picking a target

“Easy” There’s not a wizard to do it for you, but there’s
good documentation, and if you follow it and do
the work, you’ll succeed.
“Doable” It’s possible, but not easy. A few things may not
work as advertised, or docs may be off. You may
also have to make compromises.
“Challenging” The brochure says it’s doable, but you won’t find
simple, straightforward documentation on how.
You’ll be blazing a new trail.
“Nah” I wouldn’t recommend this approach.
Why I emphasize documentation
The cloud is evolving rapidly.
There’s no reliable changelog.
There are no announcements of new deployments
(only of new feature, and the feature may be deployed
much earlier than the announcement.)
When the documentation isn’t right, you’ll need to
open a support case: takes time, money.

When do you want to jump in?
1. The feature is deployed
2. The feature is documented
3. People use the feature, test it, call support
4. The feature & documentation are updated to
reflect how it really works
5. The public writes best practices & checklists
Sometimes, businesses HAVE to jump in this early.

But you’re better off when the above is done…
Just be aware that you won’t find this yet
for new services & behaviors:

Which service to migrate to?
If you have… Azure SQL DB
Azure SQL DB
Hyperscale
Azure SQL DB
Managed Instance
Azure VM
1 app in 1
database
Easy Easy Easy Easy
1 app in groups
of databases
Challenging Nah Easy Easy
1 SQL Server Nah Nah Doable Easy
Groups of SQL
Servers
Nah Nah Doable Doable
Easy != guaranteed to work.
It’s easy IF you’re only using supported features.
• Inventory unusual features you’re using
• Find out if each is available in your target
• If not:
• Can you stop using that feature, or
• Can you work around it with a hack, or
• Do you need to pick another target?

How to inventory your features
Start with sp_Blitz @CheckServerInfo = 1:
https://BrentOzar.com/blitz/
Look for:
• Non-default server options
• Non-default database options
• Anything outside of a user database
• Every line in the output: did SQL Server come this way,
or did we add/change something?

Particularly problematic
1. Anything stored outside of user databases
(msdb, master, registry, trace flags, sp_configure)
2. Anything involving multiple databases at once
(distributed transactions, linked servers)

Example: Agent jobs
Data is stored in msdb, outside of user databases
Execution happens on a separate service (Agent)
Common uses:
• Database maintenance (backups, indexes, stats)
• Report scheduling
• Job scheduler for application code
(run SSIS, run app logic queries, send emails)
Is Agent available?
But before you rule out the left two, ask:
And the answer can be different for different jobs.
Azure SQL DB
Azure SQL DB
Hyperscale
Azure SQL DB
Managed Instance
Azure VM
SQL Agent jobs Nah Nah Kinda Yes

Common Agent uses
Short-term backups: no longer necessary
Long-term backups: still necessary, but can be
worked around with Azure SQL DB:
https://docs.microsoft.com/en-us/azure/azure-
sql/database/long-term-retention-overview
App code like running SSIS, making queries happen:
you’ll need a workaround
DBA monitoring scripts: consider Elastic Jobs
Remember, easy != guaranteed to work
Azure SQL DB
Hyperscale
Azure SQL DB
Managed Instance
Azure VM
1 app in 1
database
Easy Easy Easy Easy
It’s easy IF you’re only using supported features.
• Inventory unusual features you’re using
• Find out if each is available in your target
• If not:

So back to the problematic stuff:
The first one is easy to catch with sp_Blitz:

Common challenges
Agent jobs
Bulk insert from file
system
Change Data Capture
Collations (always CI AS)
CLR, XPs
Database mail
OLE Automation
OPENQUERY
Query Notifications
Replication publisher
Resource Governor
Service Broker
But these are way harder to catch
Because people may be doing it without the DBA
team being aware, like cross-database transactions.

Cross-database transaction
BEGIN TRAN
UPDATE StoreDB.dbo.Orders
SET Status = 'Shipped';
UPDATE InventoryDB.dbo.Products
SET QtyInStock = QtyInStock -1;
COMMIT
Cross-SERVER transaction
BEGIN TRAN
UPDATE StoreDB.dbo.Orders
SET Status = 'Shipped';
UPDATE Server2.InventoryDB.dbo.Products
SET QtyInStock = QtyInStock -1;
COMMIT

Catching this is really hard.
Applications have been doing this for years.
Doesn’t require special permissions.
Very common to see with 3rd
party apps that ship with
multiple databases, and you can’t edit their code.
Very common to see with linked server queries that
copy or move data between servers.
Transaction support
Azure SQL DB
Azure SQL DB
Hyperscale
Azure SQL DB
Managed Instance
Azure VM
Cross-db
queries
No No Yes Yes
Cross-db
transactions
No No Yes Yes
Cross-server
transactions
No No No Yes
Azure SQL DB has had cross-database query aka Elastic Query in preview for two years:
https://docs.microsoft.com/en-us/azure/azure-sql/database/elastic-query-overview
Managed Instances has cross-server transactions in preview, but only with other MIs:
https://docs.microsoft.com/en-us/azure/azure-sql/database/elastic-transactions-overview

2. Working around
unavailable services
To find Microsoft’s workarounds
Read the release notes & feature comparisons to hear
what the product team suggests.
Keep in mind they sing from the Microsoft songbook:
they won’t advise you not to use a feature, and they’ll
be tactful about really big problems.

What’s New in Azure SQL DB
sql/database/doc-changes-updates-release-
notes?tabs=single-database
Pay attention to features in preview, known issues:
Sometimes, there’s a workaround
But you have to even know that this issue exists: it’s
not like you get a warning when your distributed
transactions suddenly start failing.

Often, YOU are the workaround.
And this can seem overwhelming, especially as you
inventory everything you’re using – or you run out of
time to inventory it all.
That’s why a lot of folks lift & shift.
Azure SQL DB
Hyperscale
Azure SQL DB
Managed Instance
Azure VM
1 app in 1
database
Easy Easy Easy Easy
1 app in groups
of databases
Challenging Nah Easy Easy
1 SQL Server Nah Nah Doable Easy
Groups of SQL
Servers
Nah Nah Doable Doable
Often, companies skip
these 3 columns altogether
in their first cloud migration.

Lift & shift migration
Lift your databases from their current host
Shift them up into the cloud,
but in a very similar configuration: just VMs
Even “just VMs” is hard, because we still face the
CPU, memory, and storage configuration limitations
Later, you’ll migrate individual databases or apps
over to cloud-native designs like Azure SQL DB
3. Provisioning
horsepower

When you built your own servers…
CPU cores, speed
$ $$$$
Storage size, throughput
$ $$$$
Memory size, GB
$ $$$$
That’s not how the cloud works.
The dials are tied together:
• Each CPU core only gets so much memory
• Each CPU core only gets so much storage
throughput, too
• Server families have storage throughput limits
The more creative you’ve been in the past, the more
you’ll have challenges in the cloud.

Provisioning a new Azure SQL DB

Not configurable:
memory size, log space,
TempDB data files,
storage throughput

Azure storage throughput limits
Each disk has limits on throughput, IOPs.
To get more, stripe multiple disks together.
But also, each VM has limits on:
• Cached throughput, IOPs to shared storage
• Uncached throughput, IOPs to shared storage
• Local ephemeral throughput, IOPs
The VM limits are based on:
• The VM family
• The exact size of the VM
This often comes as a shock
When you build your own VM, you have control over it:
https://docs.microsoft.com/en-us/azure/virtual-
machines/disks-performance
When you use Azure SQL DB, you don’t: Microsoft
sets limits based on the server size you picked:
sql/database/resource-limits-logical-
server#resource-governance

“Perfect is the
enemy of good.”
Voltaire
Another version
“Give them the third-best to go on with.
The second best comes too late,
the best never comes.”
Robert Watson-Watt,
inventor of radar during WWII

4. Tuning once
you’re up there
Measuring wait stats
Traditional SQL Server in VMs Azure SQL DB (all flavors)
sys.dm_os_wait_stats sys.dm_db_wait_stats
Server-level, includes all databases Database-level, must be tracked for each
individual database
Resets on SQL Server startup Resets at any time, can’t tell when it was
restarted
Cumulative, 24/7 Cumulative/24/7
Needs monitoring software REALLY needs monitoring software

sp_BlitzFirst @SinceStartup = 1
Shows your cumulative wait types since startup,
excluding harmless idle/sleep waits.
Download: BrentOzar.com/go/download
Works in Azure SQL DB, too. Installs in any db.
Azure SQL DB adds new waits.
Say we’re loading a lot of data into a new table:
WRITELOG: writing to the transaction log
LOG_RATE_GOVERNOR: the storage could go
faster, but Azure’s limiting us.

We have 3 dials to fix it
Table design, indexes
$ $$$$
Azure size, spend,
configuration
$ $$$$
Query design
$ $$$$
Recap

Migration steps
1. Which Azure service should you migrate to?
In 2021, a lot of folks are still doing lift-and-shift.
2. How do you work around unavailable services?
Lift-and-shift kicks this can down the road.
3. How do you provision the right power?
Don’t overthink it: start similar to prod, monitor.
4. How do you tune once you’re there?
Monitor wait stats, adjust queries, indexes, HW.

Geek Sync | Planning a SQL Server to Azure Migration in 2021 - Brent Ozar

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Geek Sync | Planning a SQL Server to Azure Migration in 2021 - Brent Ozar

Similar to Geek Sync | Planning a SQL Server to Azure Migration in 2021 - Brent Ozar (20)

More from IDERA Software

More from IDERA Software (20)

Recently uploaded

Recently uploaded (20)

Geek Sync | Planning a SQL Server to Azure Migration in 2021 - Brent Ozar