Microsoft Windows Azure offers several choices for data stora class="r2 fiji-r2">
Resources For IT Professionals
Microsoft Windows Azure offers several choices for data stora class="r2 fiji-r2">
SQL Database is a relational data storage service in the cloud. Some of the benefits of this offering are the ability to use a familiar relational development model that includes most of the standard SQL Server language (T-SQL), tools and utilities. Of course, working with well-understood relational structures in the cloud, such as tables, views and stored procedures also results in increased developer productivity when working in this new platform type. Other benefits include a reduced need for physical database administration tasks to server setup, maintenance and security as well as built-in support for reliability, high availability and scalability.
The article will not cover Windows Azure Storage or make a comparison between the two storage modes here. You can read Windows Azure Table Storage -- Not Your Father's Database to get more information about these storage options. It is important to note that Windows Azure tables are NOT relational tables. Another way to think about the two storage offerings is that Windows Azure includes Microsoft’s NoSQL cloud solutions and SQL Azure is the RDMS-cloud offering. The focus of this article is on understanding the capabilities included in SQL Database.
This article will explain differences between SQL Server and SQL Database. You need to understand these differences in detail so that
you can appropriately leverage your current knowledge of SQL Server as you work
on projects that use SQL Database as a data source.
If you are new to cloud computing you’ll want to do some background reading on Windows Azure before reading this article. A good place to start is the MSDN Developer Cloud Center.
To start working with SQL Database, you’ll first need to set up
an account. If you are a MSDN subscriber, then you can use up to three SQL Databases
(maximum size 1 GB each) for up to 16 months (details) at as a developer sandbox. You may prefer to sign up for a regular SQL Database
account (storage and data transfer fees apply) at
http://www.microsoft.com/windowsazure/offers. Yet another option is to get a trial 30-day account (no credit card required) at
http://windowsazurepass.com/, and use signup code -
DPEWR02. For the detail steps, see
Acquire and Activate a Trial or Subscription: A Step-by-Step Guide.
After you’ve signed up for your SQL Database account, the
simplest way to initially access it is via the
Windows Azure Platform Management Portal. You must first sign in with the Windows Live ID that you’ve associated to your Windows Azure account. After you sign in, you can create your server installation and get started
developing your application. The number of servers and/or databases you are allowed to create will be dependent on the type of account you’ve signed up for.
An example of the Windows Azure Platform Management Portal is shown in Figure 1. Here you can see a server and its associated databases. You’ll note that there is also a tab on this portal for managing the Firewall Settings for this particular SQL Database installation.
Figure 1 Summary Information for a SQL Database Server
As you initially create your SQL Database server installation,
it will be assigned a random string for the server name. You’ll generally also
set the administrator username, password, geographic server location and
firewall rules at the time of server creation. You can select the physical (data
center) location for your SQL Database installation at the time of server creation.
You will be presented with a list ofmanaging the Firewall Settings for this particular SQL
Database installation.
How to Create a SQL Database Server.
By default there is no client access to your newly-created server, so you’ll first have to create SQL Database firewall rules for all client IPs. SQL
Azure uses port 1433, so make sure that that port is open for your client
application as well. When connecting to SQL Database you’ll use the username@servername format for your username. SQL Database only supports SQL
Authentication; Windows authentication is not supported. Multiple Active
Result Set (MARS) connections are supported.
Open connections will ‘time out’ after 30 minutes of inactivity. Also connections can be dropped for long-running queries or transactions or excessive resource usage. Development best practices in your applications around connections are to open, use and
then close those connections manually, to include retry connection logic for dropped connections and to avoid caching connections because of these behaviors. Another best practice is to encrypt your connection string to prevent man-in-the-middle attacks. For
best practices and code samples for SQL Database connections
(including a suggested library which includes patterned connection retry logic),
see SQL Database Connection Management.
You will be connected to the master database by if you don’t specify a database name in the connection string. In SQL Database the T-SQL
statement USE is not supported for changing databases, so you will generally specify the database you want to connect to in the connection string (assuming you want to connect to a database other than master). Figure 2 below, shows an example
of an ADO.NET connection:
Figure 2 Format for SQL Database connection string
After you’ve successfully created and connected to your SQL Azure server, then you’ll usually want to create one or more databases. Although you can create databases using the
Windows Azure Platform Management Portal, you may prefer to do so using some of the other tools, such as SQL Server Management Studio 2008 R2 (SSMS). By default, you can create up to 149 databases for each SQL Database server
installation, if you need more databases than that; you must call the Azure
business desk to have this limit increased.
When creating a database you must select the maximum size. The current options for sizing (and billing) are Web or Business Edition. Web Edition, the default, supports databases of 1 or 5 GB total. Business Edition supports databases of up to 50 GB, sized in increments of 10 GB – in other words, 10, 20, 30, 40 and 50 GB. Currently, both editions are feature-equivalent.
You set the size limit for your database when you create it by using the MAXSIZE keyword. You can change the size limit or the edition (Web or Business) after the initial creation using the ALTER DATABASE statement. If you reach your size or capacity limit for the edition you’ve selected, then you will see the error code 40544. The database size measurement does NOT include the master database, or any database logs. For more detail about sizing and pricing, see Pricing Overview. Although you set a maximum size, you are billed based on actual storage used.
It’s important to realize that when you are creating a new database on SQL Database, you are actually creating three replicas of that database. This is done to ensure high availability. These replicas are completely transparent to you. Currently, these replicas are in the same data center. The new database appears as a single unit for your purposes. Failover is transparent and part of the service you are paying for is a SLA of 99.9% uptime.
After you’ve created a database, you can test connectivity via the portal by clicking the ‘Test Connectivity’ button for the selected database. For this test to succeed you must enable the ‘Allow Microsoft Services to Connect to this Server’ option on the Firewall Rules tab of the Windows Azure Platform Management Portal.
After you’ve set up your account, created your server, created at least one database and set a firewall rule so that you can connect to the database (from your development computer), then you can start developing your application using this data source.
Unlike using Windows Azure Storage, there is nothing to install in your development environment. If you are using Visual Studio 2010, you can just get started – no additional SDKs, tools or anything else are needed.
Although many developers will choose to use a Windows Azure front-end with a SQL Database back-end, this configuration is NOT required. You can
use ANY front-end client with a supported connection library such as ADO.NET or
ODBC. This could include, for example, an application written in Java or PHP.
For more information, see
Development: How-to Topics. Connecting to SQL Database via OLE DB is currently not supported.
If you are using Visual Studio 2010 to develop your application, then you can take advantage of the included ability to view or create many types of objects in your selected SQL Database installation
directly from the Visual Studio Server Explorer View. These objects are Tables,
Views, Stored Procedures, Functions or Synonyms. You can also see the data
associated with these objects using this viewer. For many developers using
Visual Studio 2010 as their primary tool to view and manage SQL Database data will
be sufficient. The Server Explorer View window is shown in Figure 3. Both a
local installation of a database and a cloud-based instance are shown. You’ll
note that the tree nodes differ slightly in the two views. For example there is
no Assemblies node in the cloud installation because custom assemblies are not
supported in SQL Database.
Figure 3 Viewing Data Connections in Visual Studio
Using the Entity Framework with SQL Database is supported. Also you may choose to use Data-Tier
application packages (or DACPACs) in Visual Studio. You can create, import and /
or modify DACPACS for SQL Database schemas in VS2010.
Another developer tool that can now use to create applications which use SQL Database as a data source is
Visual Studio Light Switch. This is a light-weight developer environment, based on the idea of ‘data and screens’ created for those who are tasked with part-time coding, most especially those who
create ‘departmental applications. Shown below (Figure 4) is connecting to a SQL Database data source
using the Light Switch IDE.
If you are wish to use SQL Database as a data source for
Business Intelligence projects, then you’ll use Visual Studio Business Intelligence Development Studio 2008 (the R2 version needed to connect to SQL Azure). In addition, Microsoft has begun a limited (invite-only) customer beta of Windows Azure
SQL Repwho
create ‘departmental applications. Shown below (Figure 4) is connecting to a SQL Database data source
using the Light Switch IDE.
Juneau’ and is expected to go into public beta later this year.
Another tool you may want to use to work with SQL Database is SQL Server Management Studio 2008 R2
(SSMS). Using SSMS, you actually have access to a fuller set of operations for SQL Database
databases using SSMS than in Visual Studio 2010. You may use both tools,
depending on which operation you are trying to complete. An example of an operation
available in SSMS (and not in Visual Studio 2010) is creating a new database
using a T-SQL script. Another example is the ability to easily performance index
operations (create, maintain, delete and so on). An example is shown in Figure 5
below.
Although working with SQL Databases in SSMS 2008 R2 is quite similar to
working with an on-premises SQL Server instance, tasks and functionality are NOT
identical. This is due mostly due to product differences. For example, you may
remember that in SQL Database the USE statement to CHANGE databases is NOT
supported. A common way to do this when working in SSMS it is to right click an
open query window, then click ‘Connection’>’Change connection’ on the
context-sensitive menu and then to enter the next database connection
information in the ‘Connect to Database Engine’ dialog box that pops up.
Generally when working in SSMS, if an option isn’t supported in SQL Database either, you simply can’t see it such as folders in the Explorer
tree not present; context-sensitive menu-options not available when connected to
a SQL Database instance, or you are presented with an error when you try to execute
a command this isn’t supported in this version of SQL Server. You’ll also note
that many of the features available with GUI interfaces for SQL Server with SSMS
are exposed only via T-SQL script windows for SQL Database. These include common
features, such as CREATE DATABASE, CREATE LOGIN, CREATE TABLE, CREATE USER, etc…
One tool that SQL Server DBAs often ‘miss’ in SQL Database is SQL Server Agent.
This functionality is NOT supported. However, there are 3rd party tools as well as community projects, such as
SQL Database Agent which provide examples of using alternate technologies to create ‘SQL-Agent-like’ functionality for SQL Database.
Figure 5 Using SQL Server Management Studio 2008 R2 to Manage SQL Database
As mentioned in the discussion of Visual Studio 2010 support, newly released in SQL Server 2008 R2 is a data-tier application or DAC. DAC pacs are objects that combine SQL Server or SQL Database schemas and objects
into a single entity.
You can use either Visual Studio 2010 (to build) or SQL Server 2008 R2 SSMS (to extract) to create a DAC from an existing database. If you wish to use Visual Studio 2010 to work with a DAC, then you’d start by selecting the SQL Server Data-Tier Application
project type in Visual Studio 2010. Then, on the Solution Explorer, right-click your project name and click ‘Import Data Tier Application’. A wizard opens to guide you through the import process. If you are using SSMS, start by right-clicking on the database
you want to use in the Object Explorer, click Tasks, and then click ‘Extract Data-tier Application’ to create the DAC. The generated DAC is a compressed file that contains multiple T-SQL and XML files. You can work with the contents by right-clicking the .dacpac
file and then clicking Unpack. SQL Database supports
deleting, deploying, extracting, and registering DAC pacs, but does not support upgrading them. Figure 6 below, shows the template in Visual Studio 2010 for working with DACPACs
Figure 6 The ‘SQL Server Data-tier Application’ template in Visual Studio 2010 (for DACPACs)
Microsoft has released a CTP version of enhanced DACPACs, called BACPACs, that support import/export of schema AND data (via BCP). Another name for this set of functionality is Database Import and Export for SQL Database.
Another tool you can use to connect to SQL Database is the
Silverlight-based Web tool called Management Portal for SQL Azure shown in Figure 7 below. It’s intended as a zero-install client to manage SQL Database installations. To access this
tool
navigate to the Windows Azure Platform Management Portal, then click the 'Database' node in the tree view on the left pane. You will next click on the database that you wish to work with and then click on the ‘Manage’
button on the ribbon. This will open the login box for the web client. After you enter the login credentials, then a new web page will open which will allow you to work with that databases’ Tables, Views, Queries an (via BCP). Another name for this set of functionality is
Database Import and Export for SQL Database.
Another tool you can use to connect to SQL Database is the
Silverlight-based Web tool called Management Portal for SQL Azure shown in Figure 7 below. It’s intended as a zero-install client to manage SQL Database installations. To access this
tool
navigate to the 
Figure 7 Using the Silverlight Web Portal to manage a SQL Azure Database
Of course, because the portal is built on Silverlight, you can view, monitor and manage the exposed aspects of SQL Database with any browser using the web management tool. Shown below in Figure 8 is the portal running on a MacOS with Google Chrome.
Figure 8 Using the Silverlight Web Portal to manage a SQL Azure Database on a Mac with Google Chrome
Still another tool you can use to connect to a SQL Database
database is SQLCMD. Even though SQLCMD is supported, the OSQL command-line tool is not supported by SQL Database.
So now you’ve connected to your SQL Database installation and
have created a new, empty database. So what exactly can you do with SQL Database?
Specifically you may be wondering what are the limits on creating objects? And
after those objects have been created, how do you populate those objects with
data? As mentioned at the beginning of this article, SQL Database provides
relational cloud data storage, but it does have some subtle feature differences
to an on premise SQL Server installation. Starting with object creation, let’s
look at some of the key differences between the two.
You can create the most commonly used objects in your SQL Azure database using familiar methods. The most commonly used relational objects (which include tables, views, stored procedures, indices, and functions) are all available. There are some differences
around object creation. SQL Database tables MUST contain a clustered index.
Non-clustered indices CAN be subsequently created on selected tables. You CAN
create spatial indices; you can NOT create XML indices. Heap tables are NOT
supported. CLR types of Geo-spatial only types (such as Geography and Geometry)
ARE supported. Also Support for the HierachyID data type IS included. Other CLR
types are NOT supported. View creation MUST be the first statement in a batch.
Also view (or stored procedure) creation with encryption is NOT supported.
Functions CAN be scalar, inline or multi-statement table-valued functions, but
can NOT be any type of CLR function.
There is a complete reference of partially supported T-SQL statements for SQL Database on MSDN.
Before you get started creating your objects, remember that you will connect to the master database if you do not specify a different one in your connection string. In SQL Database, the USE (database) statement is not supported for changing databases, so if you need to connect to a database other than the master database, then you must explicitly specify that database in your connection string.
If you plan to create SQL Database objects using an existing,
on-premises database as your source data and structures, then you can simply use
SSMS to script an appropriate DDL to create those objects on SQL Database. Use the
Generate Scripts Wizard and set the ‘Script for the database engine type’ option to ‘for SQL Database’.
An even easier way to generate a script is to use the SQL Azure Migration Wizard available as a download from CodePlex. With this handy tool you can generate a script to create the objects and can also load the data via bulk copy using bcp.exe.
You could also design a SQL Server Integration Services (SSIS) package to extract and run a DML or DDL script. If you are using SSIS, you’d most commonly design a package that extracts the DDL from the source database, scripts that DDL for SQL Database and
then executes that script on one or
more SQL Database installations. You might also choose to load the associated data
as part of this package’s execution path. For more information, see
SQL Server Integraiton Services
on MSDN.
SQL Data Sync enables creating and scheduling regular synchronizations between SQL Database and either
SQL Server or other SQL Databases. You can see this service in
action in
a Channel 9 video. Currently SQL Data Sync services works via Synchronization Groups (HUB and MEMBER servers) and
then via scheduled synchronization at the level of individual tables in the databases selected for synchronization. For even more about Data Sync, listen in to
geekSpeak: Data Sync in SQL Database with Ike Ellis.
What if your source database is larger than the maximum size for the SQL Database installation? This could be greater than the absolute
maximum of 50 GB for the Business Edition or some smaller limit based on the
other program options.
Currently, customers must partition (or shard) their data manually if their database size exceeds the program limits. Microsoft has announced that it will be providing a federation (or auto-partitioning utility) for SQL Database around
November 2011. For more information, see
SQL Database Federations: Building Scalable, Elastic, and Multi-tenant Database Solutions. To support federations, new T-SQL syntax will be introduced. From the blog post referenced above, Figure 9, below, shows a conceptual representation of that new syntax.
Figure 9 SQL Database Federation (conceptual syntax)
It’s important to note that T-SQL table partitioning is NOT supported in SQL Database. There is also a free utility called
Enzo SQL Shard that you can use for partitioning your data source.
You’ll want to take note of some other differences between SQL Server and SQL Database regarding data loading and data access. Added recently
is the ability to copy a SQL Database via the Database copy command. The
syntax for a cross-server copy is as follows:
CREATE DATABASE DB2A AS COPY OF Server1.DB1A
The T-SQL INSERT statement IS supported (with the exceptions of updating with views or providing a locking hint inside of an INSERT statement). Related further to data migration is that T-SQL DROP DATABASE and other DDL commands have additional limits when
executed against a SQL Database
installation. Also the T-SQL RESTORE and ATTACH DATABASE commands are not
supported. Finally, the T-SQL statement EXECUTE AS (login) is not supported.
If you are migrating from a data source other than SQL Server, there are also some free tools and wizards available to make the job easier. Specifically there is an Access to SQL Database Migration wizard and a
MySQL to SQL Database Migration wizard. Both work similarly to the SQL Database
Migration wizard in that they allow you to map the source schema to a
destination schema, then create the appropriate DDL, then they allow you to
configure and to execute the data transfer via bcp. A screen from the MySQL to
SQL Database Migration wizard is shown in Figure 10 below.
Here are links for some of these tools:
Figure 10 Migration from MySQL to SQL Database wizard screen
For even more information about migration, you may want to listen in to a recently recorded a 90 minute webcast with more details (and demos!) for Migration scenarios to SQL Database.
Now let’s take a look at common programming concerns when working with cloud data.
First you’ll want to consider where to set up your development environment. If you are an MSDN subscriber and can work with a database under 1 GB, then it may well make sense to develop using only a cloud installation (sandbox). In this way there will be
no issue with migration from local to cloud. Using a regular (i.e. not MSDN subscriber) SQL Database account you
could develop directly against your cloud instance (most probably a using a
cloud-located copy of your production database). Of course developing directly
from the cloud is not practical for all situations.
If you choose to work with an on-premises SQL Server database as your development data source, then you must develop a mechanism for synchronizing your local installation with the cloud installation. You could do that using any of the methods discussed earlier, and tools like Data Sync Services and Sync Framework are being developed with this scenario in mind.
As long as you use only the supported features, the method for having your application switch from an on-premise SQL Server installation to a SQL Database is simple – you need only to change the connection string
in your application.
Regardless of whether you set up your development installation locally or in the cloud, you’ll need to understand some programmability differences between SQL Server and SQL Database. The article has
covered the T-SQL and connection string differences. In addition all tables must
have a clustered index at minimum (heap tables are not supported). As previously
mentioned, the USE statement for changing databases isn’t supported. This also
means that there is no support for distributed (cross-database) transactions or
queries, and linked servers are not supported.
Other options not available when working with a SQL Azure database include:
- Full-text indexing
- CLR custom types (however the built-in Geometry and Geography CLR types are supported)
- RowGUIDs (use the unique identifier type with the NEWID function instead)
- XML column indices
- Filestream datatype
- Sparse columns
Default collation is always used for the database. To make collation adjustments, set the column-level collation to the desired value using the T-SQL COLLATE statement. And finally, you cannot currently use SQL Profiler or the Database Tuning Wizard on your SQL Database.
Some important tools that you CAN use with SQL Database for
tuning and monitoring are the following:
- SSMS Query Optimizer to view estimated or actual query execution plan details and client statistics
- Select Dynamic Management views to monitor health and status
- Entity Framework to connect to SQL Database after the initial model and mapping
files have been created by connecting to a local copy of your SQL Database
database.
Depending of what type of application you are developing, you may be using SSAS, SSRS, SSIS or Power Pivot. You CAN also use any of these products as CONSUMERS of SQL Database data. Simply connect to your SQL
Azure server and selected database using the methods already described in this
article.
Another developer consideration is in understanding the behavior of transactions. As mentioned, only local (within the same database) transactions are supported. Also it is important to understand that the only transaction isolation level available for a
database hosted on SQL Database is READ
COMMITTED SNAPSHOT. Using this isolation level, readers get the latest
consistent version of data that was available when the statement STARTED. SQL
Azure does not detect update conflicts. This is also called an optimistic
concurrency model, because lost updates, non-repeatable reads and phantoms can
occur. Of course, dirty reads cannot occur.
Yet another method of accessing SQL Database data
programmatically is via OData, currently in CTP, you can try out exposing SQL Database data via an OData interface by configuring this at the
CTP portal. For more information, see
Introduction OData. Shown in Figure 11 below is one of the (CTP) configuration screens for exposing SQL Database data as OData.
Figure 11 SQL OData (CTP) configuration
Generally, the SQL Database administrator role
is logical installation management. Physical management is handled
by the platform. From a practical standpoint this means there are no physical
servers to buy, install, patch, maintain or secure. There is no ability to
physically place files, logs, tempdb and so on in specific physical locations.
Because of this, there is no support for the T-SQL commands USE <database>,
FILEGROUP, BACKUP, RESTORE or SNAPSHOT.
There is no support for the SQL Agent on SQL Database. Also,
there is no ability (or need) to configure replication, log shipping, database
mirroring or clustering. If you need to maintain a local, synchronized copy of
SQL Database schemas and data, then you can use any of the tools discussed earlier
for data migration and synchronization – they work both ways. You can also use
the DATABASE COPY command. Other than keeping data synchronized, what are some
other tasks that administrators may need to perform on a SQL Database installation?
Most commonly, there will still be a need to perform logical administration. This includes tasks related to security and performance management. Of note is that in SQL Database only there are two new database roles
in the master database which are intended for security management. These roles
are dbmanager (similar to SQL Server’s dbcreator role) and loginmanager (similar to SQL Server’s securityadmin role). Also certain common usernames are not permitted. These include ‘sa’, ‘admin’, ‘administrator’, ‘root’ and ‘guest’. Finally
passwords must meet complexity requirements. For more information, see Inside SQL Database and
Managing Databases and Logins in SQL Database.
Additionally, you may be involved in monitoring for capacity usage and associated costs. To help you with these tasks, SQL Database provides a
public
Status History dashboard that shows current service status and recent history (an example of history is shown in Figure 12).
Figure 12 SQL Database Status History
There is a new set of error codes that both administrators and developers should be aware of when working with SQL Azure. These are shown in Figure 13 below. The article, How-to: Decode Reason Codes in SQL Database, shows how to programmatically decode error messages.
Figure 13 SQL Database error codes
SQL Database provides a high security bar by default. It forces
SSL encryption with all permitted (via firewall rules) client connections.
Server-level logins and database-level users and roles are also secured. There
are no server-level roles in SQL Database. Encrypting the connection string is a
best practice. Also, you may wish to use Windows Azure certificates for
additional security. For more detail, see SQL Database Connection Security. For
more information on SQL Database security, see Overview of Security in SQL Database.
In the area of performance, SQL Database includes features such
as automatically killing long running transactions and idle connections that
have been idle for 30 minutes or longer. Although you cannot use SQL Profiler or trace flags for performance
tuning, you can use SQL Query Optimizer to view query execution plans and client
statistics. A sample query to SQL Database with Query Optimizer output is shown in
Figure 14 below. For more information, see Troubleshoot and Optimize Queries with SQL Database. You can also perform statistics management and index tuning
using the standard T-SQL methods. For more information, see SQL Database Performance and Elasticity Guide.
Figure 15 SQL Database query with execution plan output shown
There is a select list of dynamic management views (covering database, execution or transaction information) available for database administration as well. These include sys.dm_exec_connections, _requests, _sessions, _tran_database_transactions, _active_transactions, and _partition_stats.
There are also some
new system views such as sys.database_usage and sys.bandwidth_usage. These show the number, type and size of the databases and the bandwidth usage for each database so that administrators can understand SQL Azure billing. For a sample
of how you can use T-SQL to calculate estimated cost of service, see SQL Database Billing Numbers Directly From Transaction-SQL.
Here is yet another MVP’s view of how to calculate billing based on using these views. A sample is shown in Figure 16. In this view, quantity is listed in KB. You can monitor
space used via this command:
SELECT SUM(reserved_page_count) * 8192 FROM sys.dm_db_partition_stats
Figure 16 Bandwidth Usage in SQL Query
Further around SQL Database performance monitoring, Microsoft
has released an installable tool called
CSS SQL Database Diagnostics, which will help you to better understand performance. It produces reports on ‘longest running queries’, ‘max CPU usage’
and ‘max IO usage’. Shown in Figure 17 below is a sample report screen for the first metric.
Figure 17 Top 10 CPU consuming queries for a SQL Database
workload
For the SQL Database August 2011 release enhancements, see
What's New in SQL Database.
Microsoft has announced that is it is working to implement database backup and restore, including point-in-time restore for SQL Azure databases. This is a much-requested feature for DBAs and Microsoft has said that they are prioritizing the implementation of this feature set due to demand.
To learn more about SQL Database, you can download the
Windows Azure Training Kit. This includes SQL Database hands-on 0x0/__key/communityserver-wikis-components-files/00-00-00-00-05/3250.CPUConsuming.png" style="border-width:0px;border-style:solid;" />
Figure 17 Top 10 CPU consuming queries for a SQL Database
workload
For the SQL Database August 2011 release enhancements, see
What's New in SQL Database.
Microsoft has announced that is it is working to implement database backup and restore, including point-in-time restore for SQL Azure databases. This is a much-requested feature for DBAs and Microsoft has said that they are prioritizing the implementation of this feature set due to demand.
To learn more alearning,
whitepapers, videos and more. There is also
a project on Codeplex which includes downloadable code, sample videos and more. Also you will want to read the
Windows Azure/SQL Database Team Blog, and check out
windowsazure.com for learning materials.
If you want to continue to preview upcoming features for SQL Azure, then you’ll want to visit
SQL Database Labs. Show below in Figure 19, is a list our current CTP programs. As of this writing, those programs include – OData, Data Sync and Import/Export. SQL Database Federations has been
announced, but is not open to invited customers.
Figure 19 SQL Database CTP programs
A final area you may want to check out is the Windows Azure Data Market. This is a place for you to make data sets that you choose to host on SQL Database publicly available. This can be at no cost or for a fee. Access is via Windows Live ID. You can connect via existing clients, such as the latest version of the Power Pivot add-in for Excel, or programmatically. In any case, this is a place for you to ‘advertise’ (and sell) access to data you’ve chosen to host on SQL Database.
The author of the original information contained in this article is Lynn Langit.