I am passionate about using Microsoft Technology to maximise business benefit. Specializing in the Data Platform – SQL server, Azure SQL DB, Azure SQL DW, elastic pools, managed instances etc.
As a great leader once said “We all need people who will give us feedback. That’s how we improve”. So any questions/ feedback – please Get In Touch
Copyright © in accordance with the Copyright, Designs and Patents Act 1988. All rights reserved. You are free to use any of the content here for personal use but need permission to use it anywhere or by any means (electronic, mechanical, photocopying, recording or otherwise).
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.
The following post shows my preferred way to automate / schedule some code against my Azure SQL Database. No it is not PowerShell or Azure Runbooks but it is definitely my favourite way.
If you read official Microsoft documentation about naming conventions for your SQL elastic pools, it is hard to find any guidelines on the subject. You are probably thinking it is not that big of a deal. I thought the same until I tried to execute some TSQL to move a database into an elastic pool.
Forget about Adaptive Query Processing for a minute, what other feature have I been waiting for? SELECT INTO a specific filegroup, not the default filegroup! I have needed this feature many times in the past. Let’s take a look at it using the WideWorldImportersDW database.
Now that I have your attention with a powerful title how about some context? It is quite common to get this error message when trying to connect to your Azure SQL Database which obviously resides on a “logical” SQL Server.
Hello all – I am excited to announce that I will be doing a Stairway series on Azure SQL Database hosted over at SQLServerCentral.com.
You may (or may not) have a requirement to setup a linked server to Azure SQL Database from a locally installed SQL Server. One reason could be to pull down some reports from an Azure SQL Database to a local file share. Whatever your reason is hopefully you will find this blog post useful because I ran into some complications on the way.
So what is the default isolation level for Azure SQL Database? I ran the following code to check it out.
I was creating some demo non-clustered indexes in one of my Azure SQL Databases and received the following warning when I executed this code:
I do not always use the Azure portal to make database changes or to check for certain information. I use it a lot of for blogging purposes but for some tasks I rather just run code via SSMS – SQL Server Management Studio.
Last year I wrote about Azure SQL Database extended events (https://blobeater.blog/2017/02/06/using-extended-events-in-azure/) and gave an example where I was capturing deadlocks via the ring buffer. Ever since then I wanted to do a follow-up post but using Azure storage as the target for my XEL files.
This is more complicated than using the ring buffer as the target and requires a couple of things:
- Azure storage account where you create a dedicated container for the files.
- SAS key.
- Database master key.
- Database scoped credential.