It’s good to be proactive and one way is to setup alerts and it is no different when using Azure SQL Database. I like creating alerts for my Azure SQL Databases and I encourage you to do the same.
TSQL Tuesday time hosted by Ewald (https://sqlonice.com/tsql-tuesday-96-folks-who-have-made-a-difference/) and quite simply one man has morphed me into who I am today – Paul Randal. Over two years ago I was a one of many that had the chance to be mentored by him. It lasted just under one year and the effects were huge for me.
I worked on testing interleaved execution with Microsoft back in January, I didn’t do much, just tested the functionality against some in-house code we had. (If you need a detailed primer on the subject, please see https://blogs.msdn.microsoft.com/sqlserverstorageengine/2017/04/19/introducing-interleaved-execution-for-multi-statement-table-valued-functions/)
Let’s start off with a quick overview of SQL Server versions and compatibility levels.
- 100 = SQL Server 2008 and Azure SQL Database
- 110 = SQL Server 2012 and Azure SQL Database
- 120 = SQL Server 2014 and Azure SQL Database
- 130 = SQL Server 2016 and Azure SQL Database
- 140 = SQL Server 2017 and Azure SQL Database
So with SQL Server 2017 now available to the public what level is a newly created Azure SQL Database set at?
What? Is probably the most common reply out there and if it is then that is how I felt when I read the message early Thursday morning.
My ultimate goal in my professional life was to work for Microsoft, you can read about my failed attempt here https://blobeater.blog/2016/09/29/my-application-to-microsoft/ but since then I decided to put a lot of my energy into work outside of my day to day job.
I used to be on the fence regarding whether or not Automatic Tuning should be on as the default when creating Azure SQL Databases. A part of me never liked the idea of Azure creating/dropping indexes or forcing plans without my prior approval but then again if it happens to do the right thing at the right time then it’s a pleasurable experience.
With Halloween around the corner what better topic to discuss than phantom reads. A phantom read occurs when rows have been inserted after a read operation and becomes visible in a follow-up read operation within the same transaction.
I love the query store, it is powerful (can be dangerous) , easy to use and packed full of information. I use it frequently across my local SQL Servers and Azure SQL Database.
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.