CHAPTER  12

Windows Azure SQL Database for DBAs

By Herve Roggero

Microsoft entered the cloud-computing space a few years ago with the vision to provide organizations a set of services they could use to build applications faster, with reduced maintenance requirements and with as much transparent scalability and availability as possible. As part of this vision, Microsoft created Windows Azure SQL Database (or SQL Database for short), a relational database service for the cloud, which delivers configuration-free high availability and scalability at a reasonable cost.

Although you can easily install and configure a full instance of SQL Server on virtual machines in the cloud, SQL Database is one of the most interesting cloud technologies because it provides many features of SQL Server and high availability without the burden of complex configuration settings. Think of SQL Database as a subset of SQL Server for the most part; I will explore some key differences and explain how this technology works throughout this chapter to give you a solid foundation to understand and manage this platform.

Before diving into the details of this technology, I should set an expectation upfront: SQL Database is not SQL Server in the cloud. This is perhaps the number one misconception about this technology and the source of much confusion about what SQL Database should and should not do. Because SQL Database instances run on shared hardware and infrastructure, SQL Database is a “one size fits all” environment from a configuration standpoint. For example, everyone gets a database that is fully redundant with 99.95 percent monthly availability, and everyone gets roughly the same share of computing resources on any given server. Conversely, no one can modify the disk subsystem, modify memory allocation, or have direct access to the physical server on which SQL Database instances are running.

So if there are no configuration options to worry about and, as a result, no hardware and database-level tuning options, why are we even discussing this technology at all in this book? Because, as a DBA, you will inevitably be asked about the capabilities of SQL Database at some point, how this technology could be leveraged by your organization, what its strengths and weaknesses are, and even possibly how to support it as part of your daily responsibilities. And as you will see in this chapter, there is no shortage of opportunities for businesses to leverage SQL Database.

SQL Database Architecture

Let’s first take a look at the SQL Database underlying architecture and discuss some of its implications. As you will see, SQL Database was designed as a cloud database, and not simply as a database in the cloud.

Infrastructure

One of the primary drivers of this architecture is to favor availability and scalability rather than raw performance. When you connect to a SQL Database instance, you are in fact connecting through a layer of routers and proxies that will find the server on which your database is currently located. That’s right, your database can move around from server to server. There is no way for you to know on which server your database is located; Microsoft reserves the right to move SQL Database instances around based on current workload requirements and other factors.

When an application connects to a SQL Database instance, the connection request first goes through a layer of gateways that route the connection request to the correct underlying server holding your database, as shown in Figure 12-1. The gateway has additional responsibilities, including security and protocol parsing.

From a security standpoint, the gateway determines if the connection request comes from an approved Internet Protocol (IP) address. Indeed, SQL Database comes with its own built-in IP firewall. If the connection comes from a client IP address that’s not specifically authorized, the connection will be rejected. Also, if too many requests are coming in at the same time, the gateway might deny access to the database in an attempt to block Denial of Service (DoS) attacks.

If the connection is authorized, the gateway also parses the statement coming in to determine if a special command is coming through, such as CREATE DATABASE. Creating a new database is handled by another component within the SQL Database infrastructure because it impacts billing.

Once the connection is authorized and the T-SQL statements can be forwarded to the actual database, the proxy layer forwards the Tabular Data Stream (TDS) packets to the correct underlying SQL Server instance for processing.

You should also note that there is no physical master database available through SQL Database. Although you can connect to the master database and execute T-SQL statements, you actually are communicating with the proxy layer. As a result, the master database is read-only and removed from billing considerations. In fact, to create a new database, you must be connected to the master database; and to change firewall settings, you also need to be connected to the master database.

Figure 12-1. Simplified SQL Database infrastructure and replication topology.

Availability and Failover

You might have noticed in Figure 12-1 that three databases are depicted in the diagram. The SQL Database instance you are connecting to is called the primary instance. To ensure high availability, every SQL Database instance is replicated to two other instances (called secondary instances). Every operation performed on a SQL Database instance involves a two-phase commit; at least one of the secondary instances must be successfully committed before the operation completes, which by nature slows down write access. This is an example of high availability taking precedence over pure performance.

Another implication of this architecture is that failing over is very quick and virtually transparent. Because each SQL Database continuously updates two copies of the primary instance, failing over in case of severe failure of the primary server can be performed very quickly; one of the secondary instances becomes the new primary instance. The proxy layer can detect the failover and redirect all new connection requests to the newly upgraded primary database. As you can imagine, applications need to account for connection loss and perform connection retries whenever necessary; for this and many other reasons, database connection retry logic is now part of normal coding practices in the cloud.

Hardware

You might wonder what the physical servers are made of, how much memory is available, and so on. At the time of this writing, each server is configured with 32 GB of RAM, 8 cores, and 12 disks. The server configuration is the same for all servers running SQL Database and even Windows Azure, making it easy for Microsoft to swap resources when needed.

As mentioned previously, this infrastructure is a shared environment, so you are effectively sharing the available resources on each machine with many other customers. Because your SQL Database instances are running on commodity hardware in a shared infrastructure, scaling applications up (by adding resources to the server) is not possible anymore. However, SQL Database is designed for scaling out with a feature called Federations. A federation is a set of SQL Database instances that work together to distribute data horizontally over multiple servers, similar to a shared-nothing configuration in which each resource has its own set of CPU, memory and disk subsystem. I will review federations in more detail later in this chapter.

Differences with SQL Server

You now know that SQL Server is the underpinning technology of SQL Database. However, this doesn’t mean SQL Database offers all of the features of SQL Server. Let’s review the major differences between the two platforms.

Database Components

SQL Database offers a limited subset of the components that make up a typical SQL Server installation. For example, SQL Server Integration Services is not included with SQL Database. However, you can connect to SQL Database using a locally installed copy of SQL Server Integration Services. So for the most part, although many of the components provided by SQL Server are not available in the cloud with SQL Database, you can use the ones installed on a local SQL Server installation and connect to a SQL Database instance in the cloud.

Table 12-1 shows a summary of the components supported in SQL Database. Partially Supported means that some or most of the features of the component can be used with SQL Database. Not Included means that there is no Windows Azure equivalent. Included means that there is a Windows Azure equivalent but the component itself can use SQL Database if needed. Replaced means that the component itself is not supported at all but Windows Azure offers an equivalent.

Windows Azure includes its own version of Reporting Services. The Windows Azure SQL Reporting service allows companies to deploy and manage reports in the cloud with high availability and scalability automatically configured. So you can either use a local SQL Server Reporting Service to connect to a SQL Database remotely or use the one provided as part of Windows Azure. However, if you use the Reporting service in Windows Azure, certain limitations apply. For example, the only data source supported from Windows Azure SQL Reporting is SQL Database.

Replication is not supported with SQL Database. However, another feature called Windows Azure SQL Data Sync offers a way to transfer data between two or more SQL Database instances and even between a SQL Server database and a SQL Database instance. Data changes can be propagated both ways.

Management Platform

With SQL Server, you depend on SQL Server Management Studio (SSMS) to manage your databases. However, SQL Database comes with online tools to manage cloud databases. At the time of this writing, the Windows Azure Management Portal is used to provision databases and manage both Windows Azure SQL Reporting and Windows Azure SQL Data Sync. Because they are both part of the Windows Azure Management Portal, you do not need to log in again.

The SQL Database Management Portal (SDMP) is a bit different. Because it was built as a separate portal entirely, you do need to log in again even if you are already logged in to the Windows Azure Management Portal. There are links available from the Windows Azure Management Portal to access the database portal. The various portals and high-level security requirements are shown in Figure 12-2.

Figure 12-2. Windows Azure portals.

Table 12-2 presents a quick summary of the functions provided by each portal. Certain functions do not have a user interface yet, such as managing users and object-level security. For the time being, the functions that cannot be performed in the SQL Database Management Portal need to be performed in SSMS.

You can also use SSMS to manage your SQL Database instances. As long as you adhere to the supported T-SQL syntax and use version 2008 R2 SP1 or higher, you can perform all the functions offered by the SQL Database Management Portal. You can check the SQL Database T-SQL reference on MSDN at http://msdn.microsoft.com/en-us/library/windowsazure/ee336281.aspx.

For example, to create a 5-GB SQL Database instance in SSMS, you would execute the following statement while connected to the master database:

Security

When it comes to security, SQL Database provides only a few features, but they’re important ones. However, at this time, SQL Database does not support certificates for encryption at rest. Although the lack of encryption of data at rest has been identified as a notable gap in the platform, this gap is currently unavoidable because you would need to give Microsoft all the keys necessary to decrypt the data.

Even when considering the limitation about encryption, SQL Database remains a very secure database and offers advanced security mechanisms, as listed in Table 12-3.

Other Important Information

So far, I outlined some key differences between SQL Server and SQL Database. There are a few additional things you need to know while we are on this topic.

Database Sizes

SQL Database instances come in specific sizes that map to either the Web Edition or the Business Edition. For the time being, there is no functional difference between the editions; only the database sizes available under each edition vary, as enumerated in Table 12-4.

Database Version

If you check the version of a database, you will see that SQL Database is running as SQL Server 2012; however, if you check the compatibility mode of a database, you will soon realize that the database instance itself is running in SQL 2008 backward-compatibility mode. This means that while SQL Database is running on the SQL Server 2012 platform, it cannot use the new features of SQL Server 2012 at the moment. Nevertheless, a few programmability features specific to SQL Server 2012 are available in SQL Database, such as new date and time related functions (like DATEFROMPARTS, EOMONTH), new logical functions (IIF and CHOOSE), and a few more.

Support for T-SQL

Although the vast majority of T-SQL operations are supported by SQL Database, there are a few notable exceptions and many limitations. Generally speaking, system views that can provide information from other customers located on the same server are not available, and neither are the statements that depend on hardware knowledge (such as the location of files) or features that are not available (such as the use of certificates and encryption). Because the list of these limitations is likely to change rapidly and is somewhat large, you should look on MSDN for the latest information about which statements are supported, partially supported, or not supported. Check out http://msdn.microsoft.com/en-us/library/windowsazure/ee336253 for the list of unsupported T-SQL statements.

Backup and Restore

There are no backup and restore commands in the traditional sense in SQL Database. However, there are multiple ways to recover from the accidental loss of data that usually follows erroneous operations on a database, such as an accidental truncate operation. These options are shown in Table 12-5. Note that the Export/Import functionality does not offer transactional consistency unless the operation is performed on a copy of the original primary SQL Database instance.

Federations

As mentioned previously, SQL Database instances run on commodity hardware with virtually no hardware or environment configuration options. This makes a SQL Database instance a poor choice for applications and systems that have very demanding workloads and need a scale-up environment. However, you can scale with SQL Database, using a feature unavailable on SQL Server called Federations.

You can use federations with SQL Database to partition one or more tables across multiple databases, and developers can use federations to access the data in a somewhat transparent manner through code. Because SQL Database instances can be created programmatically without any hardware configuration or environment settings, adding new SQL Database instances to a federation is simple and requires very little administration. The simplicity of SQL Database becomes its strength when it comes to scalability.

Key Terms

Before we go any further, let’s review the terms related to the SQL Database Federations feature. A SQL Database instance is called a root database when one or more federations have been created in it. Because many federations can be created in a root database, a few system views were added so that you can easily find out how many federations were created.

A federation is created by specifying a distribution name and contains one or more federation members. The distribution name is a typed identifier used by SQL Database to determine which type of field a table can be federated on. You specify which field a table will be federated on by linking it to the federation distribution name. (See “T-SQL Changes for Federations” later in this chapter for further details.) The field in the federated table used to partition the data is called the federated column. The distribution name and the federated column must be of the same type.

A federation member is a SQL Database instance that contains a slice of data for the federated tables it contains, based on its allocated range. If a federation member is responsible for holding records from 1 to 100 on the distribution name called CustomerID, all the tables in that federation member that are federated on CustomerID can store only values in that range. Records that fall outside of that range are stored in other federation members. Note, however, that a federation member can contain more than federated tables; it can also contain stored procedures, views, and most database objects supported by SQL Database.

A federated member can also contain reference tables. Reference tables are tables that are not federated and are used to store the same data on all the federated members for referential integrity and performance. However, reference tables are not synchronized, meaning that once they are created in the federated members, changing records in a reference table in one federation member does not automatically change the reference tables in other federation members.

Figure 12-3 represents a sample federation called FederationCust with two federation members split at CustomerID = 1000. In this example, the Customers table contains the first 999 customers in the first federation member and the remaining records in the second federation member. The Countries table is used as a reference table and contains the same records.

Figure 12-3. Sample federation in SQL Database.

T-SQL Changes for Federations

Because Federations are a fully supported feature of SQL Database, certain T-SQL commands were created and others modified to manage them. Table 12-6 provides a summary of the most important statements and views used with federations.

Federation Example

Let’s review a simple scenario in which I am creating a federation called FederationCust that will hold two tables: Customers and Countries. My Customers table is being federated because it will contain many records and will be the cause of performance and scalabilities issues in my SQL Database instance as my database grows. My Customers table will contain a CustomerID field as a unique identifier, which is being used as the key to federate the table. The Countries table doesn’t need to be federated; however, I want to include that table as a reference table in my federation for data integrity. The following steps show how I create the federation, as depicted in Figure 12-4:

1. I create a federation called FederationCust using the CREATE FEDERATION statement, specifying a distribution name called CustomerID. This creates an empty database. I switch context to that database by using the USE FEDERATION statement and create my two tables: Countries and Customers. However, when I create my Customers table, I specify this table will be federated on its ID field (the federated column) using the CREATE TABLE … FEDERATED ON statement. Because my federation has only one member database at the moment, all the records will be stored in this database.
2. At some point in the future, I realize that my federation is growing and I want to store my Customers table on two member databases (also referred to as federation members, or simply members) for increased application performance. So I decide to split the federation with the ALTER FEDERATION … SPLIT command, specifying that the CustomerID distribution name will be split at 1000. In the background, SQL Database creates two new member databases and copies the customer records from the original member database so that the first new member will contain all the records with an ID less than 1000, and the second new member with an ID of 1000 or greater. Because the Countries table is not federated, it will be copied in its entirety. If other objects were created in the original member, such as stored procedures, they would be copied too.
3. Once the copy operation is completed, the original member will be dropped and only two members will remain. The SPLIT operation can be performed online with limited performance impact, and the databases will be transactionally consistent at the end of the operation. I can further split my federation over time as needed to scale my database.

Figure 12-4. Steps to create a SQL Database federation.

Limitations

SQL Database Federations are becoming more popular because they answer an important scalability need in cloud computing. However, certain limitations apply that developers and database administrators should know about. Some of these limitations might be lifted over time, so I encourage you to verify whether the following limitations still apply:

• Data types The timestamp and rowversion data types are not supported in federation members.
• Identity The identity column is not supported in federation members.
• Merge It is not currently possible to merge federation members at this time. This feature is planned but not yet available.
• Fan-out support From a development standpoint, it is not possible to issue requests across federation members in a single call. Developers are responsible for issuing requests and processing the results of the client side.
• Database copy The database copy operation is currently not supported against a root database or a federated member.
• Isolated schema changes Changes to the schema of a federation member stay within that federation member.
• User interface For the time being, the only interface that supports managing SQL Database Federations is the SQL Database Management Portal.
• Other Other limitations apply, such as indexed views not being supported, additional limitations on the federated columns, and more. Check MSDN for a complete list of limitations: http://msdn.microsoft.com/en-us/library/windowsazure/hh597469.

Troubleshooting Performance Issues

If you are experiencing performance issues with SQL Database, the first thing to do is follow traditional database-tuning techniques, such as evaluating your indexes, tuning T-SQL statements, limiting the use of triggers, and minimizing database roundtrips and the volume of data being returned to the consumers.

Unfortunately, as mentioned previously, SQL Database does not support the use of SQL Trace. That’s because the system stored procedures used by SQL Trace are not accessible on a SQL Database instance. The good news is that you do have access to certain Dynamic Management Views (DMVs). You also have access to execution plans either through SSMS or through the SQL Database Management Portal.

DMVs Available

DMVs are invaluable system views provided by SQL Server and SQL Database to troubleshoot the inner workings of the database engine. SQL Database offers a subset of the DMVs available under SQL Server because of security reasons. The following DMVs are available in SQL Database:

• sys.dm_exec_connections Returns the list of connections established in a SQL Database instance.
• sys.dm_exec_query_plan Returns the XML execution plan of a SQL query or a batch.
• sys.dm_exec_query_stats Returns aggregate performance information for cached query plans.
• sys.dm_exec_requests Returns information about the statements being executed by a SQL Database instance.
• sys.dm_exec_sessions Returns the current session opened, along with performance information about that session. However, it doesn’t return last-login information, such as the last_successful_logon column.
• sys.dm_exec_sql_text Returns the text of a SQL batch.
• sys.dm_exec_text_query_plan Returns the execution plan in text format for a SQL query or batch.

Execution Plans

Execution plans are another powerful tool you can use to understand and troubleshoot performance issues. You can also view execution plans with the SQL Database Management Portal (SDMP). However, the portal provides a somewhat different experience than SSMS does in a few different areas.

First of all, the symbols provided in the graphical representation are different and not as granular. For example, the symbol for Index Seek operations looks different on the portal than it does in SSMS. (See Table 12-7 for a few symbols displayed in SDMP.).Also, the same symbol is provided in the portal for Clustered Index Seek and Non-Clustered Index Seek operations. Although some symbols might not be as granular in the portal as in SSMS, their descriptions are granular enough.

Similarly to SSMS, you can zoom in and out of execution plans in SDMP and you can view batched execution plans. SDMP also gives you quick search options and different views without having to re-execute the T-SQL statement. For example, you can search expensive operations by clicking on the CPU icon, which automatically finds the most expensive CPU operations in the batch and highlights them, as shown in Figure 12-5.

Figure 12-5. Execution plan in SDMP sorted by the CPU cost

Performance Dashboard

The SQL Database Management Portal also provides a handy performance dashboard showing current activity and detailed performance information in a secondary screen. When you first log in to the portal, you will see a summary of the database you logged in to. To view a summary of the performance dashboard, click on Query Performance on the top of the screen. You will see a screen similar to Figure 12-6. This screen shows you a list of queries with performance metrics, including resource consumption per second. For example, the statement SELECT * FROM EnzoUsers consumed 2 physical reads per second and had a duration of 11 millisecond (ms) per second on average. These metrics are obtained by using the sys.dm_exec_query_stats table and provide an average burn rate per second, which is displayed on the screen. Although this might sound a bit complicated, this screen is designed to list in decreasing order the statements that are the most active and consuming the most resources at any point in time.

Figure 12-6. Query Performance summary dashboard.

Clicking on a specific query opens another screen, shown in Figure 12-7, which provides execution details, including most of the statistics provided by sys.dm_exec_query_stats. This screen shows you resource consumption and query plan information, such as when the query plan was cached, the plan handle, and more. You can also look at the execution plan directly from this screen if you click on Query Plan.

Figure 12-7. Query Performance detailed view.

Related Services

Windows Azure SQL Database comes with a few related services, including Windows Azure SQL Reporting, Windows Azure SQL Data Sync, and the Export/Import feature. As mentioned previously, Windows Azure SQL Reporting has its own management portal, while the other features are accessible through the Windows Azure Management Portal.

Windows Azure SQL Reporting

Windows Azure includes a cloud service you can use to deploy reports with minimal effort and allow these reports to be run from traditional Windows applications, from web applications, or directly from a browser by giving users the URL of the report.

Working with Windows Azure SQL Reporting (or SQL Reporting) is much simpler than working in an on-premises Reporting Service environment because there are no configuration settings to worry about, other than user and application access control. As with any other service provided in the cloud, SQL Reporting is designed to scale to demand and automatically handle the back-end configuration settings necessary to provide a highly scalable service.

SQL Reporting is currently a fully supported service; however, there are a few limitations you should know about. First and foremost, SQL Reporting can connect only to SQL Database instances. This means that at the time of this writing you cannot use SQL Reporting with internal data sources or other cloud data sources, such as Azure Tables. Another important limitation is related to user management; you need to create and manage each user individually in the management portal created specifically for SQL Reporting. Also, custom assemblies are not supported; indeed, you do not have access to the servers running this service, so your reports cannot use custom extensions. Other limitations do apply, so make sure to check MSDN for a complete list.

From the Windows Azure Management Portal, you can access the SQL Reporting portal directly by selecting Reporting from the left bar as shown in Figure 12-8. A menu showing available options appears and provides access to user-management screens, reports created in Visual Studio 2008 Reporting Services, execution logs, and usage statistics. Reports are accessed using HTTPS, so the data shown on the report is encrypted over the network for stronger security. Note that at this time a separate administrator account needs to be created to manage the reports in the SQL Reporting portal.

Figure 12-8. Windows Azure SQL Reporting management portal.

Windows Azure SQL Data Sync

Because many companies need to synchronize data between on-premises databases and SQL Database, or even between SQL Database instances, Windows Azure provides a data-synchronization service called Windows Azure SQL Data Sync (SQL Data Sync, for short). This service offers schedule-based, data-synchronization capabilities between multiple databases and is designed with high resiliency in mind.

When working with SQL Data Sync, you first create a Sync Group, in which multiple on-premises and cloud databases are added. On-premises SQL Server databases are optional in any given Sync Group; however, a Sync Group must have at least one SQL Database instance that serves as the hub. Because the SQL Data Sync functions as a hub-and-spoke architecture, the hub serves as the central database against which all data changes from individual member databases are copied to, and then successful changes are copied back to the relevant member databases. Each Sync Group defines its own conflict-resolution strategy: either the hub wins or the client wins. (The client is another term used to refer to a member database.) Normally, you choose the hub database based on its location compared to the other databases in a manner that minimizes data-transfer cost and optimizes performance.

When configuring a Sync Group with on-premises SQL Server databases, you must install and configure a client agent that will manage data synchronization on the database servers. Once the client agent has been installed and properly configured, you will see it added to the Sync Group in the Windows Azure Management Portal.

Synchronization errors are clearly visible; an operation log file can be viewed from the portal directly by clicking the Log Viewer button. You can also force synchronization to take place at any time. Figure 12-9 shows a failed synchronization.

Figure 12-9. Windows Azure SQL Data Sync management portal.

SQL Data Sync also has a few limitations worth noting. Perhaps the most important limitation of this feature is that the data is not copied with transactional consistency. Also, keep in mind that to synchronize two databases, a full synchronization must first be completed. Depending on the location of the database and the amount of data being synchronized, the first sync operation could take some time. Finally, certain properties cannot be changed after the Sync Group has been created; for example, you cannot change the hub once the Sync Group has been created.

Import/Export Feature

SQL Database also comes with an interesting feature called Import/Export. It is designed to export a database schema and data in a single blob that can be later imported into a SQL Server instance or another SQL Database instance. This feature creates a logical backup file called a data-tier application (DAC) file. When the file is created on a local disk, it has a .bacpac extension, so it is also referred to as a BACPAC file. You can use the BACPAC file to copy databases from the cloud to your on-premises SQL Server databases, and back. Because the BACPAC file contains objects specific to the release of the database being backed up, you might experience errors when importing a BACPAC file on a version of SQL Server prior to SQL Server 2012.

When you are exporting a SQL Database instance to a BACPAC, you are essentially creating a blob device in a Windows Azure Storage Account you own. Figure 12-10 shows you the information you need to provide when exporting a database. In addition to providing the database credentials, you need to provide the path of the blob that will be created and the access key needed to access your storage account. The blob path contains the storage account and the blob name (mystorageaccount and blobbackup001, respectively, in my example).

Figure 12-10. Exporting a database using the Import/Export feature.

If you want to create another database in the cloud with this blob, you need to create an empty SQL Database instance and run the Import Wizard from the Windows Azure Management Portal. If you want to create a database on a local SQL Server instance, you first need to download the blob to a local machine and then use SQL Server Management Studio to import this file into a newly create database.

Cost of SQL Database

The SQL Database service can cost you just a few dollars a month to hundreds or even thousands of dollars, depending on your needs. Generally speaking, you pay for what you use; the more database space you need and the more network traffic you generate, the more you will pay. The total cost for using SQL Database is made up of a flat rate that varies based on the amount of data stored and the outbound network traffic generated in a given month.

At the time of this writing, a 1-GB SQL Database instance costs $9.99 per month, plus 12 cents for each GB of outbound bandwidth consumed. The minimum amount you can pay for a SQL Database is $4.99 per month if you consume only 100 MB of storage in a 1-GB database instance. A 150-GB SQL Database instance costs $225.78 per month, excluding the bandwidth cost. As you can probably guess, the price per GB goes down with a larger database, as you can see in Figure 12-11.

Figure 12-11. Monthly cost of a SQL Database instance per GB of storage in US dollars.

In the case of a federated environment, you might need multiple database instances; each federated database instance incurs its own cost. So if you have 25 federated members of 1 GB each and a root database of 100 MB, you would pay about $254.75 (25 * $9.99 + $4.99) plus the combined outbound bandwidth generated by all your databases.

Conclusion

This chapter introduced you to the basics of the Windows Azure SQL Database platform offered on the Microsoft cloud. I provided you with an overview of the underlying architecture of this platform so that you can better understand the inner workings of this technology. I also provided an overview of the major differences between SQL Server and SQL Database, gave you a quick introduction of the various management portals available online, and gave you a quick tour of the various services provided by the Azure platform that leverage SQL Database.

SQL Database is designed to serve the needs of a wide variety of projects, from smaller applications to very large systems, by leveraging the recent federation features built to deliver a shared-nothing architecture and support larger workloads in a distributed fashion. With its simple configuration and provisioning model, SQL Database is poised to become a very popular database platform over time.

Because this technology is continuously evolving, I encourage you to learn more about it and other Azure-related services online on the Microsoft website, where you can find additional information on the topics covered in this chapter and more.