I recently presented a session on SQL Azure (you can download the slide deck here). During the session we talked a lot about some of the little things I have found by simply using SQL Azure. The need for a clustered index on every table was a surprise to me when I first found out about it, and it seemed surprising to everyone in the room as well. One person mentioned how it is a common practice to drop indexes before loading data to a table, for example, so they would need to rethink the steps involved in pushing data to the cloud.
I still think the biggest hurdle will be how Microsoft approaches the application of service packs and hotfixes to SQL Azure. One person at my session suggested that they would assume that Microsoft would have done thorough testing of the patch and also that with such limited features available right now that the testing would be able to be streamlined. I tended to agree but decided to point out something I found with their documentation:
So, they went out of their way to link to four DMVs that they DO NOT support, and the one DMV they do support in this category is not even a hyperlink? Why, exactly, would you hyperlink to things I cannot use? With such a huge usability FAIL, why is it that I would trust them to do thorough testing of any patch when they cannot even handle the usability of their documentation?
I want to love SQL Azure, I really do. I intend to find more and more ways to utilize it whenever possible. But when I see things like above it really makes me question how some of the plumbing is really being handled. I strongly believe that if you take care of the little things then you will inevitably also take care of the big things. And if you can’t do the little things right then you might as well “use the button”.
In the past four weeks I have come across a lot of issues with the documentation being borderline unusable. When I was trying to push data to the cloud a few weeks back I talked to Buck Woody (blog | twitter) about a handful of options to which he replied “Why don’t you just use Sync?”
“Well,” I replied, “because I don’t see that mentioned anywhere as an option. Don’t your departments talk to each other? Why is this option not in the documentation?”
I know this is really v1.0 of a product, and that things will get better in time. I truly hope that is the case and we are not going to be subject to having things half-done tossed over the fence at us to use. But the more time I spend with SQL Azure the less comfortable I am that they are taking care of the little things.
And I consider documentation to be more than just a little thing.
Isn’t it kinda funny that they bill you based on the database size – and the size DMVs are the ones you can’t access? I get a chuckle out of that.
oh, yeah, that is slick, huh? kinda like how they bill you for the data you will pipe and the only way to do a ‘backup’ is to pipe data up and down.
still, it is no different than any other utility company.
@Brent Ozar
sys.dm_db_partition_stats should be enough to evaluate the size seeing as the size you’re billed for is calculated from the number of active pages at any time. No concept of a data file or wasted space (except for internal fragmentation), only the number of pages matters.
@Thomas LaRock
I still don’t get how they could launch Azure without any backup options. Sure, you can synchronize, but what about consistency? And if their solution to scaling is sharding, consistency becomes an even bigger issue – a workaround would be to make snapshots, but we can’t do that either.
Their usual response to the traffic issue is to spin up a Windows Azure hosted script that retrieves and compresses the data before it’s downloaded, since internal Azure traffic is free. Still a crap “solution” though.
Keep the faith – v1 is always v1. There’s places to experiment and use this, and lots of places where it does not fit – but stay tuned, young man…
I have faith in you, Buck.
Linking to DMV docs here is for the purpose of highlighting what is NOT supported so you have a good understanding of what’s missing.
Why? Because one of the main issues with migrating to SQL Azure is that it supports a subset of features compared to SQL Server. So the screen-shot above is intended to help evaluate migration rather than standard dev help.
What I’m saying here is that you should’ve draw conclusions on availability of dev docs and patching/testing policy based on this screenshot. Cheers!
if a conscious decision was made to have those links included in order to show what is NOT supported, then that decision was wrong.
there is no way you can convince me that it makes sense to link to items you do NOT support, and then not link to something that you do support. that is the complete opposite behavior of anything i would describe as useful. i would rather think it was an oversight by someone as opposed to a strategic decision. if it was a decision then that person needs to be given the opportunity to participate in some usability seminars.
can you imagine if i showed my child pictures of four desserts they will NOT be eating after dinner? how silly would that be? and then, under my breath, i mention that we have some crackers for dessert but they have to climb up into the cupboard to get it themselves.
yeah, it’s like that. it makes no sense to have built the site in that manner. someone needs to think simpler, and from an end-user point of view when it comes to documentation.
Ugh, in my prev comment I meant to write “…you should not draw conclusions…”
The stuff that works is described in SQL Online Books, the regular dev docs that come with every edition of MSSQL. So I believe the intent is to say “everything you know about MSSQL works except these few things and I’ll give you a link to a detailed description of them there so you know exactly what I’m talking about”
BTW, I’m not commenting from a position of authority (I don’t know the folks who made those decisions and I don’t work there). I was trying to help based on everything I learned about SQL Azure so far.
I’m also not asserting that it’s a good design. I’m just pointing out that the structure of the docs was used to draw conclusions about quality of patch testing which seems to be unrelated.
It’s all the same company. If they don’t have good checks for usability or quality control in one area, why should i assume they will be any better in a different area?
imagine if a car company like Toyota suddenly started to put out cars of lesser quality because one area lost focus on quality control and usability…