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.
I have moved many databases to Azure via different methods but I recently came across a new way. Well technically it’s not new, I should say, newly found. The migration was done via the command line which is not exactly ground breaking but it’s nice to have another option.
The idea behind this is simple. Create the bacpac via command line using sqlpackage.exe with the action as export then do an import action into Azure.
I was doing some normal activities on one of my Azure SQL Databases, I went to make a cup of tea and returned to the following message:
The statement has been terminated. Msg 40544, Level 17, State 12, Line 15 The database ‘TestDB’ has reached its size quota. Partition or delete data, drop indexes, or consult the documentation for possible resolutions.
Yes, I like to blog, maybe slightly more on Azure than SQL Server. I enjoy it and it probably explains why I do about 70 posts a year. I am happy for every single reader even though my numbers are not elite I see growth and this is what motivates me to write during those late nights.
Naturally the cost of Azure SQL Database directly relates to what tier and performance level you are using. Starting from the least expensive basic database to the more premium ones I thought it would be worthwhile capturing the costs (GBP) across all tiers.
If you know about DBCC CHECKDB then most likely you will know about DBCC CHECKTABLE. Quite simply this command performs primitive system-catalog consistency checks, per-table consistency checks on the single table specified, and cross-table consistency checks on indexed views that reference the specified table. (Page 899 Microsoft SQL Server Internals 2012, Chapter 14, Page 899, Paul Randal)
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.