My photo
Auckland, New Zealand
Smurf sized geeky person with a penchant for IT, gaming, music and books. Half of industrial duo 'the craze jones'. Loves data, learning new things, teaching new things and being enthusiastic.

Friday, 18 September 2009

Building Applications on SQL Azure

These are my notes from Jeremy Boyd's presentation at TechEd NZ '09. These notes are pointers for finding out additional information and as such do not give full details of any particular areas of SQL Azure.

  • Initial services coming with SQL Azure - RDBMS, Data Sync, Data Hub
  • Down the road they will add more services such as Reporting Services and Analysis Services
  • Databases limited to 10GB each
  • SQL Azure is not SQL Data Services - they are two different things. SQL Data Services no longer exists and the tasks it was achieving are now part of Windows Azure.
  • SQL Azure has a familiar SQL relational model
  • Virtual DB server
  • Auto HA and fault tolerance
  • Friction-free scaling
  • Self provisioning
  • Provisioning model: Create an account, add a server, add a database, connect & play OR you can create via SSMS
  • All standard T-SQL language minus a lot of DBA stuff
  • When connecting ignore the error message - it's irrelevant and doesn't stop you connecting.
  • All tables MUST have a clustered index on SQL Azure
  • Can target SQL Azure either remotely from on-premise application, from an application on Windows Azure (fastest option), or alternatively use SQL Azure for storage.
  • V1 of SQL Azure does not support partitioning, so use sharding. Sharding is where you use several databases to store portions of the data. Same schema used across all databases.
  • SQL Azure is currently in CTP1 with CTP2 due soon with better tooling
  • Free to use until launch date sometime in November 2009 - so get playing
  • Check it out at
The following items are missing:
  • CLR
  • DB File Placement
  • DB Mirroring
  • Distributed queries
  • Distributed transactions
  • Filegroup management
  • Full text search
  • Global temp tables
  • Spatial data & indexes
  • SQL Server config options
  • SQL Server service broker
  • System tables
  • Trace flags and quite a few other items
  • Check MSDN for command by command break down of what is and isn't supported.
Migrating an existing DB to SQL Azure
  • ANSI_NULLS not supported
  • PAD_INDEX not supported
  • Can't specify row locks
  • Can't specify filegroup reference or partitioning
  • Codeplex project which copes with this and updates your script: SQL Azure Migration Wizard
  • Check all tables have clustered index before migrating (codeplex tool will do this)
  • Should be able to migrate DB without too many hassles
On-premise scenario
  • Data is located outside the firewall from where the app runs
  • In NZ we need to be espcially vigilant about handling latency
  • Expect poor latency when using the on-premise scenario and factor caching into the design of your application
  • Favour chunky calls rather than chatty calls
  • When caching, don't hold on to the data so long that it becomes stale, use query notifications - if data changes, update cache
Better option
  • Build an app - deploy to Windows Azure with SQL Azure as the backend
  • This gives you a lower latency, however, as good programming practice, you should still factor caching into the design of your app
  • SQL Azure - great data sync point
  • High Availability
  • Scaleable
  • Sync framework = Project Huron
  • Mobile device access can make good use of synchronization
  • Project Huron - only available server side at the moment, client side bits coming soon
Database size 10GB
  • Includes: Primary replica data, objects and indexes
  • Does NOT include: Logs, masterdb, system tables, server catalogues, additional replicas
More info
  • More info on up coming project additions:
  • To sign up for the CTP:

No comments: