We all want high performing applications and when you are in the cloud that is no different, if anything it is even more important. With this post I will discuss some areas where I have been “stung” by so you can learn from my mistakes when using Azure SQL Database. Then I will dedicate a section on what tools you can use to help with your performance tuning exercises.
So here we go, the first installment of my cloud blog series. From my experience this concern is a common one, especially when relating it to the database layer. Data “leaks” via security breaches have been getting some real negative press lately, what tools and techniques do you have to protect your Azure SQL Databases? The answer is – A LOT across different components and that is what I will cover in this blog post.
A quick elementary post which is my entry to this months’ T-SQL Tuesday entry hosted by a good friend SQLDoubleG http://www.sqldoubleg.com/2017/07/03/tsql2sday-92-lessons-learned-the-hard-way/.
We are here to talk about mistakes we used to make. There is one mistake that I am going to discuss and is something that I used to do 10 years ago, obviously I do not do this anymore.
I am an IT Professional from the UK with a huge interest in MS technology especially SQL Server and Azure. During 2015 I was mentored by Paul Randal – Data Platform (SQL Server) MVP 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.
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.
Sometimes I will reinforce basic concepts via a quick SQL Server video clip – https://blobeater.blog/sqlserver-video-library/
Arun Sirpal – BlobEater
p.s. I am no longer afraid to mention that I like Sheep.
I have actually lost Paulie in the garden.
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 was VERY excited when I read the following tweet (below) from Bob Ward regarding SQL Server Diagnostics capability. What is it you are asking? It is an extension to SQL Server Management Studio (SSMS) where it gives you the ability to Upload / Analyse dump files created by SQL Server.
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:
Hopefully you will join me.
A really quick one today, something that made me think for a minute and I thought it might make others think too. So you have enabled TDE – Transparent Data Encryption (you can see these previous posts here: https://blobeater.blog/?s=tde&submit=Search) on your SQL Server database and in the back of your mind you know TempDB gets encrypted too.
I have a SQL Server that is constantly producing “dump” files (with a MDMP File type), these are named SQLDumpxxxx (xxx = numerical value). They are located in the following directory: C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Log\ – sound familiar?
Have a look at this screen shot – it’s messy!
Thanks to Grant for hosting this month’s T-SQL Tuesday found (http://www.scarydba.com/2017/06/06/t-sql-tuesday-091-databases-devops/) where it is a chance to share our DevOps stories. I am not going into specifics of databases but I am going to write about it more generally.
Following on from my previous blog post I mentioned that I had to find a solution to the “unable to call into C compiler” message. This meant that the specific SQL Server database in question (that contained in-memory tables) went into recovery pending mode, meaning that recovery needed to run but something was preventing it from even starting.
