1. The DBA with his Head in the Clouds (or being an Azure SQL DBA)
Martin Cairney MVP, MCT, MCSE
SQL Saturday #468, Sydney
27th February 2016

2. Housekeeping Mobile Phones Evaluations Wifi Details
please set to “stun” during sessions
Evaluations
complete online to be in the draw for fantastic prizes
Wifi Details
Login: Password:
SESSIONS
EVENT
sessions/sessionevaluation.aspx
eventeval.aspx

3. Martin Cairney Microsoft Data Platform MVP Microsoft Certified Trainer
Organiser – SQL Saturday Melbourne (
@martin_cairney

4. Agenda Compare Azure SQL Database to SQL Server Being an Azure DBA
Creating Databases
Accessing Databases
Features
Scalability and Performance
Availability and DR
Being an Azure DBA
Compare: Limitations, Creating, Accessing, Configuring
Strategies: Scale up and down
Comparison of versions
Automate scaling – what to look for as triggers
Scale out – sharding
Elastic Scale – how it works
Elastic Scale – difficulties like cross DB queries from a DBA perspective
DBA Activities: What to monitor
How to manage and maintain ongoing
27/02/2016 |
The DBA with his head in the Clouds

5. Azure Service Management vs Resource Management
The Resource Manager deployment model provides the following benefits:
You can deploy, manage, and monitor all of the services for your solution as a group, rather than handling these services individually.
You can repeatedly deploy your application throughout the app lifecycle and have confidence your resources are deployed in a consistent state.
You can use declarative templates to define your deployment.
You can define the dependencies between resources so they are deployed in the correct order.
You can apply access control to all services in your resource group because Role-Based Access Control (RBAC) is natively integrated into the management platform.
You can apply tags to resources to logically organize all of the resources in your subscription.
The future direction is to use Resource Manager deployments, so learn the processes for this.
Azure Resource Manager is the tools/process we use to manage Resource groups.  They are a new concept in the Azure Preview portal. Think of them as “lifecycle boundaries,” because when resources share a resource group, their lifecycles (from create, to update, to delete) are managed as one.
Especially learn the scripting options – Azure CLI commands, Azure Resource Manager REST API and PowerShell using the AzureRM verb constructs
Or of course, use the Portal
5 |
27/02/2016 |
The DBA with his head in the Clouds

6. Creating Azure SQL Database or VM
Can I script a deployment in ARM using PowerShell?
Demo Azure PowerShell and changing to resource mode
Create a Storage Account? (needed) and a SQL DB instance and finally a database.
Go through the steps to create an Azure VM with SQL using the original marketplace. Mention that you would create a Storage Account first and the disks that you’d need (leave the default disk created with the VM as is but add additional “Data Disks” as required and use Storage Spaces to stripe them. Show D: drive but mention you need the D Series with SSDs to use it for tempdb as you don’t really get the performance gain otherwise. Note also that you shouldn’t use Geo-Replication on the storage account.
1) Create storage account named sqlsat ) In the Storage Account, create Container named demo – this effectively creates a disk space. 3) Create SQL Server 2014 Std on A2 from gallery (name : sqlsat382, cloud service: sqlsat382).
While creating, go to new portal and create a Azure SQL Database: (Name: Demo2 Use server: sqlsat446, Basic Tier, Demos resource group, ….. Show that you can name your server in new portal. But no in the old one
Go back and connect to the VM – bring up SSMS and connect locally and to cairney.database.windows.net using sqladmin as the login
6 |
27/02/2016 |
The DBA with his head in the Clouds

7. Azure SQL Database vs SQL Server
SQL Sever
Azure SQL Database
Full functionality of the installed version of SQL Server. Includes all components (SSIS, SSRS, SSAS etc.).
Underlying Windows Server requires configuring.
Disk layout needs careful planning to achive desired IOPS and throughput. DB sizes as for the installed Edition (Std or Ent).
HA and DR need to be planned.
Can use Windows Authentication or SQL Authentication.
SLAs need to be carefully defined based on the infrastructure deployment and the SQL Server configuration.
Database Engine only – does not even include SQL Agent.
Removes the need to configure the underlying platform as well as the SQL instance itself – these are done for you, including upgrades and patches.
Perfomance based on DTUs – a blend of disk and CPU performance.
Max DB Size depends on Tier. Largest is 1TB.
Redundant copies means built-in HA and DR.
SQL Authentication plus AD Authentication (utilizes Azure AD).
SLAs pre-defined for the database level.
Some high level differences to be aware of.
7 |
27/02/2016 |
The DBA with his head in the Clouds

8. Azure SQL Database vs SQL Server (Contd.)
Can change the listening port to obfuscate access to SQL Server. Update Windows Firewall to control external access.
Full T-SQL language available.
Scale by adding resources or multiple instances (Linked servers, distributed transactions etc)
Only listens on Port Restrict access by client IP Address with database-level firewall.
T-SQL restrictions in place.
Scale by using Sharding techniques or external tables.
Some high level differences to be aware of.
8 |
27/02/2016 |
The DBA with his head in the Clouds

9. Features of Azure SQL Database
Scalability
Predictable Performance
Guaranteed Uptime
Data Protection
Programmatic DBA-Like Functionality
Self-Managed
Azure SQL Database makes tier-1 capabilities easily accessible.
27/02/2016 |
The DBA with his head in the Clouds

10. Scalability Scalability Predictable Performance Guaranteed Uptime
Data Protection
Programmatic DBA-Like Functionality
Self-Managed
27/02/2016 |
The DBA with his head in the Clouds

11. Scalability Easy with SQL Server Instance
Add more memory
Add more CPUs
Get SSDs
Add Filegroups and Partitioning
Add more instances
Needs more planning with Azure SQL DB
Scale up and down by changing the Tier
Scale out by adding more database
Known as Sharding – implement with Elastic Scale
Azure SQL databases still have the concept of a server that they reside on – has a master database and logins etc.
Each server can host up to 150 databases (this may be extended for you if you contact Azure support). Each server also has a limit of 2000 DTU’s – so the higher Tiers may not be able to have as many databases. The specific tier also determines the max size of a database.
If you need more throughput, but within the bounds of a specific Tier then scale up (and back down again if the need is transient).
Azure DB Elastic Scale implements the infrastructure aspects of sharding and thus allows you to focus on the business logic of your application instead. Data is horizontally partitioned across multiple databases – gaining the throughput and performance of each Shard or Database. Elastic Scale is an API that contains the code to allow the application to add new shards as required to scale out the application
27/02/2016 |
The DBA with his head in the Clouds

12. Scaling Up & Down
Service Tier/Performance Level
MAX DB Size
Max Concurrent Requests
Max In-Memory OLTP Storage
Max Sessions
Basic
2 GB 30
N/A
300
Standard-S0
250 GB 60
600
Standard-S1 90
900
Standard-S2
120
1,200
Standard-S3*
200
2,400
Premium-P1
500 GB
1 GB
Premium-P2
400
4,800
Premium-P4
800
3 GB
9,600
Premium-P3/6
1,600
8 GB
19,200
Premium-P11
1 TB
10 GB
32,000
This chart shows the maximum database size per tier along with the user connection restrictions. Note that if you want to scale DOWN, your DB must be smaller than the max size for the Tier you want to scale down to.
We’ll have a look at Scaling out a bit later
27/02/2016 |
The DBA with his head in the Clouds

13. Predictable Performance
Scalability
Predictable Performance
Guaranteed Uptime
Data Protection
Programmatic DBA-Like Functionality
Self-Managed
27/02/2016 |
The DBA with his head in the Clouds

14. Performance Comparison
SQL Server
Defined by infrastructure constraints – physical or virtual; disks; memory; cpu etc
Resource Governor can refine further
Azure SQL Database
Basic, Standard & Premium versions
Elastic Pools – predictable pool with individual DB variation
Estimate using calculator :
Basic, Standard & Premium provide predictable performance measure in Database Throughput Units (DTUs).
You can run your database workload up to the max limits allowed for your selected service tier/performance level (i.e. resource consumption is at 100%). If your workload is hitting the limits in one of CPU/Data IO/Log IO limits, you will continue to receive the resources at the maximum allowed level, but you are likely to see increased latencies for your queries. If the slowdown becomes severe queries can start timing out. If you are hitting limits of maximum allowed concurrent user sessions/requests (worker threads), you will see error or
Monitor the database actively to ensure applications are running at the desired performance and optimize usage as needed.
Resource consumption data: For Basic, Standard, and Premium databases more granular resource consumption data is available through a new DMV called sys.dm_ db_ resource_stats in the user database. This DMV provides near real time resource consumption information at 15 second granularity for the previous hour of operation. The DTU percentage consumption for an interval is computed as the maximum percentage consumption of the CPU, IO & log dimensions.
Alerts: Set up 'Alerts' in the Azure Management Portal to notify you when the DTU consumption approaches certain high level. Database alerts can be setup in the Azure Management Portal for various performance metrics like DTU, CPU, IO, and Log.
For example, you can set up an alert on “DTU Percentage” if the average DTU percentage value exceeds 75% over the last 5 minutes.
Scheduled performance level upgrade/downgrade: If your application has specific scenarios that require more performance only at certain times of the day/week, you can use Azure Automation to upsize/downsize your database to a higher/lower performance level as a planned operation.
For example, upgrade the database to a higher performance level for the duration of a weekly batch/maintenance job and downsize it after the job completes. This kind of scheduling is also useful for any large resource-intensive operations like data loading, index rebuilding etc. Note that the Azure SQL Database billing model is based on hourly usage of a service tier/performance level. This flexibility allows you to plan for scheduled or planned upgrades more cost efficiently.
27/02/2016 |
The DBA with his head in the Clouds

15. Performance Levels – DTUs?
Service Tier/Performance Level
DTU
Benchmark Transaction Rate
Predictability
Basic 5
5.6 transactions per second
Good
Standard-S0 10
8.7 transactions per second
Better
Standard-S1 20
17 transactions per second
Standard-S2 50
46 transactions per second
Standard-S3
100
102 transactions per second
Premium-P1
125
127 transactions per second
Best
Premium-P2
250
263 transactions per second
Premium-P4
500
494 transactions per second
Premium-P6/3
1,000
1,108 transactions per second
Premium-P11
1,750
1,761 transactions per second
This chart shows the performance levels per tier.
DTUs provide a way to describe the relative capacity of a performance level of Basic, Standard, and Premium databases. DTUs are based on a blended measure of CPU, memory, reads, and writes. As DTUs increase, the power offered by the performance level increases. For example, a performance level with 5 DTUs has five times more power than a performance level with 1 DTU.
The transaction rate is measured by using a mix of database operations which occur most frequently in online transaction processing (OLTP) workloads.
Finally, the Predictability is an indication of performance predictability. The higher Tiers are more stringent in their response time requirements in the benchmark tests.
To work out what you need, use the calculator at
27/02/2016 |
The DBA with his head in the Clouds

16. Elastic Scale
From the Azure Portal, connect to the subscription. Make sure that the Azure SQL Database server at my382.database.windows.net is available. Login martin, Pwd m1Lng8v13
Demo of Elastic Scale. Open the project in Visual Studio and build and run it. Open Azure Preview Portal and show the current SQL Databases. Connect with SSMS and expand the DBs. Create some shards and show that the tables are empty using the query:
SELECT *
FROM dbo.Customers GO
FROM dbo.Orders
FROM dbo.Products
FROM dbo.Regions
Load some data rows and re run the query showing that the data is mapped to the correct shard.
16 |
27/02/2016 |
The DBA with his head in the Clouds

17. Elastic Scale
Optional to show the structure of the shard manager tables – show the query output instead
17 |
27/02/2016 |
The DBA with his head in the Clouds

18. Guaranteed Uptime Scalability Predictable Performance
Data Protection
Programmatic DBA-Like Functionality
Self-Managed
27/02/2016 |
The DBA with his head in the Clouds

19. Uptime Comparison SQL Server Azure SQL Database
What can you achieve with your own hardware and processes?
Azure SQL Database
Multiple replicas created by default
Automatically detects failures and fails-over
Quorum based commit ensures data consistency
99.99% availability
Azure SQL Database has 3 local synchronous replicas (zero data loss). The write is committed at the primary and at least one of the secondaries before it is acknowledged. The service will detect any single instance failure and ensure clients are served from one of the existing ones. The copies are also distributed across different servers and racks in the data centre to further protect data.
27/02/2016 |
The DBA with his head in the Clouds

20. Service Tier/Performance Level
Uptime SLAs
Service Tier/Performance Level
Uptime SLA
Basic
99.99%
Standard/S0
Standard/S1
Standard/S2
Standard/S3*
Premium/P1
Premium/P2
Premium/P3 and above
This chart shows the SLA is the same across all tiers – backed by the redundant local copies
27/02/2016 |
The DBA with his head in the Clouds

21. Data Protection Scalability Predictable Performance Guaranteed Uptime
Programmatic DBA-Like Functionality
Self-Managed
27/02/2016 |
The DBA with his head in the Clouds

22. Data Protection Comparison
SQL Server
Backups, Consistency Checks,
HA and DR implementations
Design to fit your RTO and RPO
Azure SQL Database
Automatic point-in-time restore available
Geo-Restore
Standard & Active Geo-Replication
Consistency Checks
Data Protection is achieved over a number of levels. All tiers offer point-in-time restores with the retention period varying per tier. ON top of this, they all offer Geo-Restore as well which allows you to recover if there is a large scale incident or outage in your local region.
For Standard and Premium, you can also async replicate to another region. You can see the secondary in the master DB but can’t connect until failover is completed. Normally service is degraded for about 1 hour before failover is enabled. If you don’t failover manually then within 24 hours the service will do the failover automatically (assuming the primary DC is still offline).
For Premium, Active Geo-Replication. This extends the service to up to 4 secondaries that are online and readable at all times … like a readable secondary in Always On. The can therefore be used for load balancing or to reduce latency for read operations by directing clients to closer databases. This can allow updates to be “frozen” e.g. before deploying an update allowing an easy fallback if issues arise.
The Geo-Replicated secondaries are also protected with 3 local copies like the primary.
27/02/2016 |
The DBA with his head in the Clouds

23. Data Protection by Default
Service Tier/Performance Level
Recovery
Disaster Recovery
Basic
Any point in last 7 days
Geo-Restore: restore to any Azure region
Standard/S0
Any point in last 14 days
Std Geo-Replication: offline secondary
Standard/S1
Standard/S2
Standard/S3
Premium/P1
Any point in last 35 days
Active Geo-Replication: up to 4 online secondaries
Premium/P2
Premium/P3 and above
Geo-Restore: Estimated Recovery Time < 12 hours, RPO < 1 hour
Std Geo-Replication: Estimated Recovery Time < 30 sec, RPO < 5 secs
Active Geo-Replication: Estimated Recovery Time < 30 sec, RPO < 5 secs
27/02/2016 |
The DBA with his head in the Clouds

24. Programmatic Access Scalability Predictable Performance
Guaranteed Uptime
Data Protection
Programmatic DBA-Like Functionality
Self-Managed
27/02/2016 |
The DBA with his head in the Clouds

25. Programmatic Functionality, Tools & Platforms
Interacting with Azure SQL Database
Manage using REST APIs, PowerShell, Azure Management Portal, SSMS
Support for .NET, Java, PHP, Ruby on Rails, Node.js
27/02/2016 |
The DBA with his head in the Clouds

26. Programmatic Access
Open Azure-PowerShell. Change the tier of the database by running Change Azure SQL DB Tier RM.ps1
Make sure the correct Certificate is installed on local machine. Show REST API with the following:
26 |
27/02/2016 |
The DBA with his head in the Clouds

27. Self-Managed Scalability Predictable Performance Guaranteed Uptime
Data Protection
Programmatic DBA-Like Functionality
Self-Managed
27/02/2016 |
The DBA with his head in the Clouds

28. Management SQL Server Azure SQL Database
Jobs for monitoring and management activities
Infrastructure management via patching
Physical rebuilds on system failures
Azure SQL Database
Automatic software patching
Replicas automatically moved as required to new machines provisioned “on the fly”
For a regular SQL Server instance, you have your normal administrative tasks. You also need to tale care of patching at the OS and Instance level – at least a monthly activity!! If a server dies, you may be covered for business continuity by HA and DR systems, but you have to physically rebuild a new instance to get the HA/DR configuration back up to full compliment.
All of these activities are taken care of for you on Azure SQL Database
27/02/2016 |
The DBA with his head in the Clouds

29. Azure DBA
29 |
27/02/2016 |
The DBA with his head in the Clouds

30. What to Consider? Performance Monitoring Query Tuning
Adjusting Performance for Usage Patterns
Sharding and Cross-Database Queries
Backups longer than in-built periods
30 |
27/02/2016 |
The DBA with his head in the Clouds

31. Performance Monitoring
Use the Azure Management Portal
Resource Utilisation
Query Performance Insight
Index Advisor
Use the DMVs – in the master and the application database
Master has more summary level data
Application database is more granular
Create Alerts on Performance Levels
Track over time to identify if scale up/down is needed
Extended Events
The old Azure Portal has a monitoring tab. This shows the performance metrics as a percentage of your database’s DTU. The data is sourced from some of the DMVs
31 |
27/02/2016 |
The DBA with his head in the Clouds

32. Query Tuning As you would do for SQL Server instance
Use the DMVs in the application database
Index Advisor
Query Store
Tune to lower resource usage where possible
Less CPU and IOPS means possibly lower Tier => lower cost
32 |
27/02/2016 |
The DBA with his head in the Clouds

33. Tune for Usage Patterns
Monitoring shows your DTU usage over time
Identify patterns in the trends
is it always low/high
Peaks at certain times (e.g. nightly index rebuilds)
Use the scaling options to increase/decrease Tier levels
Match to the required levels (4 times in a 24 hour period)
Schedule the Tier changes
REST API or PowerShell scripts
Just need to be aware of the tier change restriction: Change the Tier level (4 times in a 24 hour period)
33 |
27/02/2016 |
The DBA with his head in the Clouds

34. Monitoring Performance & Query Tuning
Connect to the OLD Portal. Connect to AdventureWorksLT in SSMS. Create some activity by running scripts 02_DBA and 03_DBA. Show the Portal with activity – change the metrics on display – add an alert for the DTU > 10% over 5 mins. Run the scripts 02_DBA and 03_DBA again a couple of times – show the Alert displayed on the portal and maybe also the once it arrives.
Show that query plans are just the same as normal. Talk through the script 04_Monitoring some aspects to identify queries to focus on – do they prompt you to scale up/down or in/out maybe?
34 |
27/02/2016 |
The DBA with his head in the Clouds

35. Backups Point-in-time retention periods set per Tier Concerns?
Restore to earlier dates?
Data retention for compliance?
Export option
Requires a Storage Account and Container
Available through REST API and PowerShell so can be scheduled
35 |
27/02/2016 |
The DBA with his head in the Clouds

36. The Future
Cloud-First Approach means functionality is fast-tracked into Azure SQL DB before it makes it to the boxed product.
Azure SQL DB already running the SQL 2016 engine!!!
Azure SQL DB functionality not yet in the boxed product (SQL 2014)
Row-level Security and Dynamic Data Masking
Temporal Tables
Query Store
Always Encrypted
36 |
27/02/2016 |
The DBA with his head in the Clouds

37. Questions?
Please make sure you visit our fantastic sponsors: