Migrating Applications to Microsoft SQL Azure is a great talk on, well, migrating different databases to the service.  Cihan, one of the PM’s on our team, does a great job of covering some of the restrictions that we have in the service.  My favorite part is the live demo of migrating a MySQL database from Amazon’s RDS to SQL Azure :-)

What’s New in Microsoft SQL Azure is good talk by Patric, the GPM on our team, covering many of the new features that we either recently released, spatial, as well as some new upcoming features like project Houston.

Microsoft SQL Azure Development Best Practices is a good lap around some of the key things to keep in mind when developing apps for SQL Azure.

Enjoy!

--Jeff--

The meta-point here isn’t necessarily that NoSQL doesn’t have it place.  I believe it does for certain cases.  However, I don’t believe it to be the silver bullet that many appears to think it is.  In short, before considering to move to such systems you really should understand, in a very crisp way, why you have a performance problem and how such a system could really help you in this manner.  It seems to me that many are latching on to these things without fully appreciating what they already have.

Just my 2 cents

--Jeff--

SQL Azure sessions for MIX 2010 

The second purpose here is to really go over some usability things that we’ve added to the service recently (mostly in our last service update but it continues in our upcoming one).  The first is that you now have the ability to easily change the SKU for any databases you previously created.  This was a pretty big piece of feedback we heard from you and ended up being holiday project of mine. 

As you know you can easily determine the number of db’s you have of a particular SKU using a query like the following in your master database.

select * from sys.database_usage where time = '2010-03-13’

So, let’s say that you presently have a Web SKU database and you would likely to switch to a Business SKU database.  You can now easily do this using the following syntax:

alter database <database_name> modify (MAXSIZE=10GB)

Pretty simple right?  Hopefully you think it is.

The team is beginning to look at opening other alter capabilities that make sense.  Some of the ones high on our list, and I’d like to hear feedback on this, include:

DB Rename, Read-Only DB access, DBO access only mode, etc. 

Again, can’t stress enough of this.  We love to hear feedback on the features we take on, the priorities and pain points you have with the service.  As always, please feel free to drop me feedback here or even better here for others to comment on.

--Jeff--

During PDC09 we spent a bunch of time handing a survey for folks to fill out to give feedback to the team.  I would really encourage you to fill this out.  If there’s a data type that you’d like to see supported, feature enabled, enhancement, etc please try some time to fill this out.

Thanks in advance from the SQL Azure team!

My, "SQL Azure: Under the hood" talk is available for viewing now here.  During the talk, I referred to GopalK's earlier under the hood talk in mine so I've attached a link to this here for those that are interested.

You can also find some of the other talks for SQL Azure here as well:

Development Best Practices and Patterns for Using Microsoft SQL Azure Databases 

SQL Azure Database: Present and Future

Scaling out Web Applications with Microsoft SQL Azure Databases

The Future of Database Development with SQL Azure

Hope you find them interesting

--Jeff--

Additionally, and this is a shamelss plug, but I'll be giving an under the hood talk tomorrow here at PDC.  The talk is, "SQL Azure: Under the hood" and it's taking place in 403B. 

Hope to see you there or in the booth! 

--Jeff--

The short answer is yes but the truth is almost always more complicated than simple answers like this.  Frankly, while we could increase the size here it’s important to think about what raising that limit means.  It means that if we experience a failover event (hard drive dies, node reboots, you get the picture) that it may take longer to get your database up and going on another node as data may need to be caught up from other nodes on the network.  This translates into reduced availability for you in the long run and this something we try really hard to avoid.

Secondly, what about the I/O?  If your databases are getting that large then might it not be more advantageous to shard?  We’ve observed that in many workloads it does.  Granted, this may not make sense in all cases but it does in many so in a sense there is a bit of tension between the need for larger individual user db’s and enhanced support for things like sharding.

Finally, as I allude to here it would be good to hear the community’s thoughts on larger instances versus enhanced support for sharding.  We’re still debating a bit internally on which of these to tackle and in what order so this is your chance to help influence this.

--Jeff--