If you’ve been working with the Azure SQL Database portal, you know that you have a query window. Within the query window you can run queries against your server. You’ll get back results, timing, everything you need to observe behavior within the system. What’s that? You never heard of this? Let’s figure it out real quick. Here’s my portal to my Azure SQL Databases:
Yes, all sorts of things you can do from here, but we’re focused on the bottom of the screen at the Manage button. Clicking this button will open up the Management portal window, part of which you can see below:
Pretty prominent in the upper left corner, you can see the New Query button. I’m sure you’ll be shocked to find that clicking on that gives you another window in the portal as shown below. Worth noting though is the listing under My Work on the left side of the screen. These are more or less windows that you can switch between, without losing your work. It’s almost like tabs in SSMS. You can open multiple queries as you see. I have two unnamed queries I’m playing with and a file, TraceCaptureDef.1.sql, which will generate all sorts of fun errors if I try to run it on Azure. But the main point is, don’t feel like you have to open multiple tabs in your browser, you have a lot of control right there in the Management Portal.
I have a query there ready to go. A few more points about that query. Note that you do have some color coding, showing key words highlighted in blue. I typed this query and formatted in Management Studio before pasting it into the query window here, but that formatting went away to a degree. Something to keep in mind. Also note, that you don’t have properties about this query that you can set. If you want to see statitistc io or time, which you can, you’ll have to set them manually using T-SQL code. But once set, you can get messages showing how long the query ran and what sort of resources were used as you see here:
You can also choose to look at an Estimated execution plan by clicking the appropriate button, or toggle the inclusion of an Actual Execution plan by again, clicking the button at the top of the window. Here’s what you get for an Actual plan within Azure SQL Database:
I’ve posted in the past about some of the details that you can access when looking at execution plans within Azure SQL Databases. I’ll be posting some more on the Management Portal, execution plans, and query tuning in Azure. Â Worth mentioning, if you look at my posts from several month ago, how they’re displaying icons in the plans has already changed. This is a seriously moving target.
Before I go, compare that execution plan with the same one from SSMS:
A couple of things to point out. Obviously, it’s different. But the real point here is that these are identical, empty, databases. The structures are 100% the same. The queries are 100% the same. But the Azure SQL Database plan includes a scan where there’s a seek in SSMS. More fun little indications that the optimizer that exists in Azure is not the same as in the base product (and yes, I’ve got the latest SP and CU installed). Something to keep in mind when you start writing queries against your Azure SQL Database instance.
This is from Feodor Georgiev:
Grant, I am afraid that there is a slight bug in the “Usage overview” bar graph – I have never seen this one move. No matter how much of the database is used, it does not show anything else besides ‘Usage data not available’.
Usage data aside, I personally have a problem with execution plans, especially when it comes to their predictability.
In other words, as a DBA I work very hard so I can have predictable performance of my systems at all times (when I expect a seek – I get a seek, when I expect a scan – I get a scan – not more not less).
A while back I fiddled a bit with SQL Azure, and I managed to find out what the names of the physical machines are of the SQL Servers – at least the physical machines involved with my databases. Here is a blog post I did on the topic: http://sqlconcept.com/2012/11/23/fiddling-with-sql-azure/
What bothers me the most is the fact that these machines are not only for my use, they are shared in a random manner with other databases which may or may not have scans, seeks or any random amount of performance issues.
In this sense Azure reminds me of those russian communal apartments of the 19th century which Dostoevsky describes so vividly (there is always someone drunk, someone asleep, someone overexcited making noise and so on).
I’ve got a review of Herve Roggero’s chapter in Pro SQL Server 2012 Practices coming out next week. He introduces SQL Databases. His argument is that performance is sacrificed for scalability and uptime. That it’s intentional. I see and understand both points of view.
Just curious, Grant. But how can you get an execution plan “down” from the cloud? Is it only available through the SET SHOWPLAN commands? Thanks, -Kev
Hey Kevin,
Hang on, hang on. I’m working on that blog post now. Should be up next week.
@Kevin: There should not be a problem to get the execution plans. We can connect via SSMS to an Azure database and we can view the plans in Management Studio.
In this article Grant is refering to the web UI of Azure, but there are more robust features in SSMS when it comes to exploring Azure.
[…] Execution Plans on Azure SQL Database Portal - Grant Fritchey (Blog|Twitter) […]
[…] Blog: Execution Plans on Azure SQL Database Portal by @GFritchey (posted Jan. 14) […]
[…] my previous post showing how to get to execution plans in the Database Management Portal, I showed that it’s pretty easy to put a query in a query […]
[…] Saturday events (first one is SQL Saturday #177, Silicon Valley). If you scroll to the bottom of this previous post, I mentioned that there were clearly differences in the optimizer because queries against empty […]