They are watching me and my Azure SQL Database and recently I noticed a low impact performance recommendation was made. Naturally I became very interested. Within your database (when in the portal) under operations you may notice something similar to the below:
Setting up AD authentication with Azure SQL Database sounds simple, it is assuming you plan carefully. I did run into issues but once rectified it felt great using AD authentication in Azure rather than just SQL logins.
This month’s T-SQL Tuesday entry hosted by Koen Verbeeck (http://sqlkover.com/t-sql-tuesday-89-invitation-the-times-they-are-a-changing/), a blog post about how we feel about the ever changing times within our technology space. Personally I love this new era of cloud computing and do not feel threatened in anyway.
A very quick post for today, I was navigating my way through the Azure portal within my SQL databases section and came across an edition that I had never seen before and I became very intrigued. It is called Premium RS (currently in preview mode) meaning we now have four tiers to select from – basic, standard, premium and premium RS.
If you ever need to move a copy of a SQL database in Azure across servers then here is a quick easy way.
I had a need to setup transactional replication from my SQL Server to SQL Database (Azure) where I only needed a selection of tables that I wanted to off-load to Azure. For this post I will be going through the setup, post checks with T-SQL / replication monitor, checking the incoming commands with Azure’s query performance insight tool and finally hooking it up to Power BI.
Over the past 6 months I have been trying to push myself to use extended events (XEvents) over SQL trace, once you get past the learning curve it’s probably the way to go. If you are operating in the Azure space then you have no choice. Extended events are what you will need to use if you want to collect information against SQL database. There are some subtle differences on how you write the T-SQL between SQL database (Azure) and your locally installed SQL Servers.
This is a new feature where you can issue TSQL commands via a TSQL editor straight from the Azure portal, why this is great is because sometimes you do not want to keep switching between your SSMS (SQL Server Management Studio) connection and the Azure portal to issue basic commands and that assumes that you have the right version of tools installed and correct ports opened locally.
This is in public preview and you can do the following:
To access the editor do the following: Go to your SQL database select the Tools button and then select the Query editor button.
Here you will see the Query editor option.
You will need to login, I have only SQL authentication setup but if you use Active Directory then you have the choice to use the other options.
]
If you fail you will obviously be told.
You want to see a blue authentication image!
Now let’s issue a query – instead of switching over to my local SSMS connection. How about some database level wait stats? I really need to look into the IO_completion wait type!
Then if you really want you can save your query (which saves it to your local machine as a SQL file):
Saved locally as per below.
Or you can open a SQL file locally (Open query option) and let that be imported into your Azure portal session, for example you could have the waits stats script pre-written and just open it up whenever you like.
It will not create a new window, it basically overwrites the contents of the current open query window, I can work with that.
Sometimes when in a testing mode I do like to clear cache within my SQL database (Azure). Nowadays a lot of my test databases are Azure based so how I clear cache is different to how I would do it with an older “earthed” SQL Server.
Looking at my locally installed SQL Server.
SELECT @@VERSION
Getting some basic information about the cache for a specific database.
SELECT st.dbid, cp.objtype, cp.size_in_bytes FROM sys.dm_exec_cached_plans AS cp CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st WHERE dbid = 12 OPTION (RECOMPILE);
Normally I would run:
-- Database_ID DBCC FLUSHPROCINDB (12);
I have cleared it out.
So, lets go to the Azure world.
SELECT @@VERSION
Again, get some basic information for my database ID.
SELECT st.dbid, cp.objtype, cp.size_in_bytes FROM sys.dm_exec_cached_plans AS cp CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st WHERE dbid = 6 OPTION (RECOMPILE);
-- Database_ID DBCC FLUSHPROCINDB (6);
Just does not happen: Msg 15247, Level 16, State 14, Line 9
User does not have permission to perform this action – I am not sure what permission I need? I am logging in as a server admin.
So I used the following instead.
ALTER DATABASE SCOPED CONFIGURATION CLEAR PROCEDURE_CACHE ;
I look at locking resources within Azure as a safety mechanism where it can protect users from accidental deletion, it can get quite confusing within the portal if for example you have close to 100 databases.
There are 2 types of lock resources in Azure.
For this blog post I create a delete lock on one of my SQL Databases. Under the settings of your SQL database you will see the LOCKS option.
You will then want to click ADD.
That’s it – let’s put it to a test
Message from the portal:
The lock named NoDel was unable to be added or edited for the following reasons: {“jqXHR”:{“readyState”:4,”responseText”:”{\”error\”:{\”code\”:\”AuthorizationFailed\”,\”message\”:\”The client does not have authorization to perform action ‘Microsoft.Authorization/locks/write’ over scope
Well, that is not what I want! You must be Owner or User Access Administrator.
Once you have addressed the permission issues just click OK.
Now we can re-try the delete.
You know how the saying goes – An ounce of prevention is worth a pound of cure.
