I am an IT Professional from the UK with interests in MS technology especially SQL Server and Azure. During 2015 I was mentored by Paul Randal from SQLskills.
I have written articles for SQL Server Central, TechNet, gathered data for SQLskills Waits and Latches Library. I have also helped the SQL Server product team with testing SQL Server vNext adaptive query processing feature. I am also a member of Microsoft’s Azure Advisors and SQL Advisors Group.
My aim is to help you in your day to day work or to reinforce specific areas that I am interested in, so I try to keep things short and simple.
Copyright © All rights reserved. You are free to use any of the content here for personal use but need permission to use it anywhere else on the internet.
I have decided to do a 4-part series on Cloud “Fear Busting” scenarios. Why? Over the past few years working with the cloud (Azure) I have come across 4 main “fears” or “concerns” that stand out in my mind that people have highlighted when adopting cloud technology for their database tier. Each “fear” with form a blog post where I am hoping that after reading each post you will be “less” fearful. More specifically I will be looking at these topic areas:
- I have security fears for SQL Database.
- Performance Issues that I faced – Learn from my mistakes.
- There is no going back – can I get the data back?
- I’m a DBA – Will I lose control?
Series Link Here.
When you have setup a Failover Group in Azure for your SQL Databases connecting to the R/W (Read / Write) endpoint via SSMS (SQL Server Management Studio) is pretty simple, if you remember one little thing, which will be the discussion point for this blog post.
So I had a corruption issue and I was thinking about running repair but I wanted to know what would potentially get deleted.
Things go wrong in IT, it is no different with the cloud. When I say cloud I am thinking quite specific such as the underlying infrastructure that a company like Microsoft looks after for their Azure platform.
I have written about Azure SQL Database LEVEL firewall rules before during my blog series, more specifically the security blog post. If you can’t remember the section on firewalls then I will bring the following diagram to your attention.
Let’s work through some code to do an encrypted backup. This feature is available to you if you are using SQL Server 2014 onwards but I decided to use SQL Server 2017.
To encrypt during backup, you must specify an encryption algorithm, and an “encryptor” to secure the encryption key. I have decided to use the following options:
- Encryption Algorithm: AES 256
- Encryptor: A certificate
If you remember last month I wrote about DBCC CHECKDB and Azure SQL Database, more specifically whose responsibility (Microsoft’s) it is and ponderings on how it is actually done. (https://blobeater.blog/2017/09/04/dbcc-checkdb-azure-sql-database/)
Here is a quick Extended Events script I knocked up where I wanted to track Tempdb file size changes for both the data and log file. I wanted to know who caused the tempdb growth, when it was done, what the T-SQL was and what sizes were involved. Not exactly complicated but hopefully useful.
You have the ability to actually pause SQL Server, if you are in SQL Server Management Studio (SSMS), you might have noticed it as the below image.
Have you ever wanted SQL Server Management Studio (SSMS) 17 to have a dark theme? Seeing the below image (visual experience color theme options) really got me excited.
Apparently there is a new tool from Microsoft where you can discover, track, and remediate potential database vulnerabilities. This tool is available for both on-premises SQL Server and Azure SQL Database. I actually cannot find the download for the on-premises version so I decided to give it a go in Azure SQL Database.