This document discusses Microsoft SQL Server options in Azure. It begins by explaining the differences between Azure SQL and on-premises SQL Server, noting that Azure SQL is based on the latest SQL Server Enterprise version in a PaaS model and is not fully compatible with on-premises SQL Server. It then outlines the various options for SQL in Azure, including SQL Server on VMs, containers, and Azure SQL with DTU or vCore pricing/scaling models. The document provides details on features, pricing tiers, scaling, security, and other considerations for using SQL in Azure. It concludes that while migration may require adjustments, Azure SQL provides many advantages over on-premises SQL Server.

2. Azure SQL
more or/and less than SQL Server

3. Rafał Hryniewski
@r_hryniewski
fb.me/hryniewskinet
.NET Dev
Blogger
Speaker
Community leader
https://hryniewski.net
rafal@hryniewski.net

5. Azure SQL
more or/and less than SQL Server

6. IOPS - input/output operations per second
DTU – Database Transaction Unit
IaaS, PaaS, SaaS – Infrastructure/Platform/Software as a Service
Glossary

7. Database possibilities in Azure
And anything on VM or in a
container

8. Lets focus on MS SQL

9. MS SQL Options in Azure
 SQL Server on VM
 SQL Server on container
 Site-to-site VPN with any physical machine (or other hybrid solution)
 Azure SQL

11. Azure SQL
 Released in 2010
 Database in PaaS model
 Based on most recent, stable SQL Server Enterprise version
 Available in DTU or vCore based pricing and scaling
 Not fully compatible with SQL Server…
 …unless it’s Azure SQL Database Managed Instance, then it’s almost 100%
compatible.
 Lots of out of the box stuff

13. Various Azure SQL Options

14. Various Azure SQL Options

15. Resource
group
Server
Database

16. Resource group
Azure’s logical container
Azure SQL Server
•Connection data
•Admin credentials
Database
Data
Billing
Service tier
Billing
Configuration

17. Two pricing/scaling models

18. DTU Model
 DTU – Data Transaction Unit
 DTU – CPU, memory, I/O and transaction log I/O in one metric
 3 Tiers – Basic, Standard, Premium
 Simple, effortless model.

19. DTU Tiers comparison
Basic:
 99,99% Uptime SLA
 7 days backup retention
 5 ms read latency
 10 ms write latency
 Up to 2GB storage
 2.5 IOPS per DTU
Standard:
• 35 days backup retention
• Columnstore indexing support
from S3 tier
• Up to 1TB storage

20. Premium:
 2 ms read/write latency
 Columnstore indexing support
 In-memory OLTP support
 48 IOPS per DTU

21. vCore Model
 Recommended scaling model
 More control upon resources during scaling
 General Purpose, Business critical and Hyperscale (preview) service tiers
 You’ll be billed for – service tier + no. of vCores and memory + hardware
generation

22. vCore Model - Choices
 Service Tier
 Hardware generation
 vCores amount (memory is strictly bound to it)
 Storage amount

23. vCore Model – Service Tiers
General Purpose:
 Premium remote storage (like
VMs)
 500 IOPS per vCore (7000
max)
 1 replica
Business Critical:
 Local SSD Storage
 5000 IOPS per vCore (200 000
max)
 3 replicas, 1 read-scale replica
 Build in support for Availability
Zones
 In-memory OLTP support

24. vCore Model – Hardware Generation
Gen 4:
 Up to 24 cores
 Based on Intel E5-2673 v3
(Haswell) 2.4 GHz processor
 Based on physical processor
 7 GB memory per vCore
 SSD storage
Gen 5:
 Up to 80 cores
 Based on Intel E5-2673 v4
(Broadwell) 2.3 GHz Processor
 Based on logical processor
 5.1 GB memory per vCore
 eNVM SSD storage (faster)

25. Can I migrate DTU model to vCore?

27. DTU -> vCore
 In standard tier each 100 DTU requires 1 General Purpose vCore
 In premium tier each 125 DTU requires 1 Business Critical vCore

28. Cool stuff

29. Firewall

31. Firewall - rules
 Each rule is IP range whitelist
 Rules can be created only by
 Server level rules can be managed with T-SQL, CLI, Powershell or REST
 Databasel level rules can be managed only with T-SQL

32. Scaling vertically

33. Scaling up – DTU model

34. Scaling up – vCore model

35. Scaling Up
 Minimum downtime
 Sadly, no autoscaling
 Still, it’s effortless...
 ...and there are some workarounds that makes autoscale possible

36. Scalling horizontaly and replication

37. Georeplication

38. Georeplication
 Creates readable replicas (secondaries)
 Manual failover
 Less than 1 minute downtime
 Each transaction is replicated to secondary after commiting to primary (Always
On)

39. Georeplication

40. Failover groups
 Defines two listeners read-only and read-write
 Automatic or manual failover
 Need to set grace period for data loss starting from 1 hour

42. Failover groups

43. Replication and read-scale out
 Basically read-only replicas for load balancing read-only database traffic
 Available in Premium (DTU) or Business Critical (vCore) Service Tiers
 All it takes is use of ApplicationIntent in Connection String ie:
Server=tcp:<serverName>.database.windows.net;D
atabase=<db>;ApplicationIntent=ReadOnly;User
ID=<login>;Password=<password>;

45. Recovering database

46. Auto backup and point-in-time recovery
 Automated backup with 7-35 days retention
 Stored in included Read-access geo-redundant storage (RA-GRS)
 It’s included in price!

47. Auto backup and point-in-time recovery
 Can be used to restore database from ANY point in time in retention period (on
the same server)
 Can be used to restore deleted db on same server
 Can be used to restore db to other geographic region (in same subscription)
 If server will be deleted – it won’t be possible to perform recovery

48. Up to ten years with long term backup retention

49. Long Term Backup Retention
 Backup retention up to 10 years
 Restoring DB is possible from
PowerShell or Azure CLI
 Read-access geo-redundant
storage
 Not available for Managed
Instaces (yet)
 Storage of your own choosing

50. Monitoring

51. Monitoring
 Fully integrated with Azure Monitor
 Easy access from portal
 With some other integrations can be used to develop some kind of autoscale

52. Automatic Performance Tuning

54. Automatic Performance Tuning
 3 independently toggled options – CREATE INDEX, DROP INDEX and FORCE
LAST GOOD PLAN
 When turned off – you can implement recomendations manually
 Gets smarter with time

55. Advanced data security

56. Data discovery and classification

57. Vulnerability Assesment

58. Threat detection

59. Advanced data security
 Set of monitoring and mitigation tools integrated with Azure Security Center
 Can detect some of most common vulnerabilities early and give some guidelines
for fixing them
 Gets smarter over time
 Can be used to monitor environments 24/7 and notify you when something
suspicious happen

60. Do we need a DBA?

62. A little bonus – you can integrate with...
 Logic Apps
 Data factory
 Stream Analytics
 Power BI
 Azure Search
 And more!

63. So... It’s better than SQL Server?

65. Most of the times eveything just works

66. Unless we try to do cross database query

67. Well, cross database queries are possible
but not so simple anymore
1. Read my blog post about this here :
https://hryniewski.net/2018/01/25/querying-external-databases-in-azure-sql/
2. Create master key
3. Create database scoped credential
4. Create external data source
5. Create external table
6. Query some shit

68. Many features related to master database

69. Many features regarding master database
 If it touches server level – it’s probably not available
 If it touches OS level – it’s probably not available
 If it touches filesystem - yep, it’s probably not available
 Databases in Azure SQL are separate, highly isolated beings – that’s why

70. So, forget about...
 Always On Availability Group (but you have other stuff for that)
 BACKUP command (but you have automated backups)
 Database mail (you can try using logic app)
 Server level triggers (yuck)
 Other than primary file group
 Service broker (there are better services for that)
 Profiler (it’s obsolete anyway)
 Windows authentication

72. You may also need to remodel your db if
you’re using some not supported syntax

73. So beware if you’re using
 LOGINS (you’ll ned to switch to USERS)
 CLR (entirelly not supported)
 USE statement
 Events, query notifications etc.
 In-memory OLTP (available only in higher service tiers)
 Column store indexes (available only in higher service tiers)

74. Gotchas
CREATE DATABASE – Creates S0 database (can be expensive if used for
development)

75. Gotchas
If you’re migrating from SQL Server 2005 or lower – be aware that 100 is the
minimum compatibility level that’s supported

76. Gotchas
Workloads that made physical server slightly warmed up can use 100% of your
resources easily and freeze your application for a long time.

77. Is migration of SQL Server to PaaS hard?

78. Migration 101

79. Migration 101 (very, very short version)
 Download Data Migration Assistant from the title
 Use VNET with VPN or Express Route to OnPrem
 Set up your network ruless to allow for traffic
 Perform compatibility assesment
 Create and configure Azure Database Migration Service
 Create and configure migration project
 Run
 Go home.

81. Questions?

82. It’s not better. It’s not worse. It’s different.
Grab a beer, try it when you sober up.
@r_hryniewskifb.me/hryniewskinet