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 had a strange issue recently when trying to login to the Azure Portal. Quite simply I would enter my login details and ended up with this message – Bad Request – Request Too Long, HTTP Error 400. The Size of the request headers is too long.
Thank you to everyone that took the time to write and contribute, I enjoyed reading about how you conquered your challenges, here is a round-up in no particular order.
Today I found out that it is now possible to enable the setting optimize for ad-hoc workloads at the database level when using Azure SQL Database. Traditionally this was always set at the server level for locally based SQL Servers.
Azure SQL Analytics is currently in preview mode, still it is very impressive. The goal of this feature is to visualize important SQL performance metrics for your Azure SQL Database. There are a couple of things you need to do first.
- Setup a Log Analytics workspace.
- Enable diagnostics for your SQL Databases and/or elastic pools.
Please see the prerequisites section within this document – YOU MUST do this else you will not be able to use this feature. https://docs.microsoft.com/en-us/azure/log-analytics/log-analytics-azure-sql#prerequisites
Once setup it should take approximately 15 minutes to start capturing and rendering back some data. Don’t be surprised if it does take a little longer as was the case for myself.
Welcome to the January 2018 edition of T-SQL Tuesday and I am your host BlobEater (Arun Sirpal).
If you do not know what T-SQL Tuesday is then a quick recap. T-SQL Tuesday is a monthly blog initiative hosted by a different blogger each month. This was founded by Adam Machanic (blog|@AdamMachanic) and is a great way of encouraging people to write. With that being said let’s move on to the topic which will be a challenging one.
I wanted to break out my comfort levels and do something different from Azure SQL Database or straight SQL Server. I really did try something new and created a Chat Bot using Azure’s Bot Service. Warning: I am a DBA by day (and night) so this is a fun post where I am trying out different areas of Azure so I apologise if you find this too basic – its Christmas lets have some fun!
It is split across two parts. First you have to create a knowledge base which I did via the QnA Maker tool. Then secondly you use this knowledge base and link it to your Azure Bot Service.
DBCC CHECKDB has the ability to perform parallel checking of objects. However, it absolutely depends on the edition of SQL Server, it only happens when using enterprise edition.
Let’s see this in action. I propose the following tests for this blog post:
- Test on a SQL Server Enterprise Edition.
- Test on a non-enterprise edition of SQL Server.
I could not read my error log on one of my local SQL Servers, when I executed the following code:
I received the below:
Msg 22004, Level 16, State 1, Line 2 Failed to open loopback connection. Please see event log for more information. Msg 22004, Level 16, State 1, Line 2 Error log location not found.
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.