CHAPTER 4 Data Migration and Backup Strategies When companies talk about their research into or experiences with the Azure technology—specifically the SQL side of Azure—two of their most frequent concerns (aside from security) are migrating local databases and data into the cloud, and backup strategies. Until Azure came around, databases were housed locally (and they still are): they’re contained within the walls of the company or in a data center. Moving to the Azure platform and SQL Azure means moving all or a portion of your data into the cloud and storing it there. Chapter 3 talked at length about security concerns, considerations, and best practices for storing your precious data in the cloud. Moving data into the cloud is a decision that you shouldn’t and can’t take lightly. But after you make the decision to utilize SQL Azure, the question becomes, how do you get your data into the cloud? As nice as it would be if moving your local database into SQL Azure was seamless, it isn’t as cut-and-dried as you may think. You do have several viable options available; but you must consider things beyond just moving the data, such as costs from data transfers. After your data is in the cloud, further questions arise regarding the backup strategies that are common with local databases. In SQL Azure, gone are the concepts of backup devices and backing up and restoring databases. As shocking as this may sound, remember that Microsoft is managing the hardware behind the scenes. For now, there are no such things as drives, devices, and so on. In this chapter we will discuss the different migration tools, strategies, and concepts for moving your database and data into the cloud. You’ll see examples illustrating how these tools are used. We’ll finish the chapter off by spending a page or two on backup strategies and tools that help provide SQL Database backup capabilities. Migrating Databases and Data to SQL Azure So you want to move one or more of your applications and its databases to the cloud. It’s a noble idea. More than likely, you’re in the same category as countless others who are looking into moving applications into the cloud: you don’t want to start from scratch. You’d rather migrate an existing application to the cloud, but you aren’t sure about the steps necessary to do so, or the technologies available to help in the process. This section discusses three tools from Microsoft that come as part of SQL Server: • The Import/Export Service • The Generate and Publish Scripts Wizard • The bcp utility In addition to these three tools, we will also briefly mention a free utility found on CodePlex called the SQL Azure Migration Wizard, which provides a wizard-driven interface to walk you through migrating your database and data to SQL Azure. The examples in this chapter use SQL Server 2012, which is available from Microsoft’s MSDN site. These examples also work with SQL Server 2008, although some the screens may be a bit different. 67 CHAPTER 4 ■ DATA MIGRATION AND BACKUP STRATEGIES The database you use in these examples is AWMini, which is a mini version of the AdventureWorks database. This database can be downloaded from the APress site for this book. The Import/Export Service In 2012 Microsoft released some great functionality for migrating an on-premises database to SQL Azure in the form of the Import/Export service. To understand what this service is and how it works, you first need to know about the Data-Tier Application Framework, more commonly known as DAC Fx. Data-Tier Application Framework DAC Fx was introduced in SQL Server 2008 R2 as part of the Application and Multi-Server Management services, a way to manage your database environments efficiently and proactively. It was designed with scale in mind to provide an effective way to manage the deployment of the database schema between environments, such as from Development to Test, and Test to Production. DAC Fx is a set of tools, APIs, and services designed to improve the development, deployment and management of SQL Server database schemas. In most environments, the DBA creates and maintains sets of T-SQL scripts that create or alter database objects, such as tables and stored procedures. The issue is that in many instances the DBAs need to maintain multiple sets of scripts; one for the initial creation and another for updates and modifications that update the database from one version to another. Add on top of that multiple versions of those scripts, and you have the makings of a complex maintenance scenario. This is where DAC Fx comes in. Instead of building and maintaining sets of T-SQL scripts, SQL Server 2008 R2 introduced the concept of a BACPAC. A DAC, or Data-Tier Application, is an entity that contains all of the database objects used by an application. Its purpose is to provide a single unit for creating, deploying, and managing objects instead of managing each object individually. When a DAC is ready to be deployed, it is built into a DAC package, or DACPAC. This package is a file that contains the DAC definition, and is simply a zip file containing multiple XML files. However, these DACPACs only contain schema, not data. This is where the new version of the DAC Fx comes in. Version 2.0 now supports data as well as schema, dumping your table data right alongside your schema in a new file format called .bacpac. Using the DAC Fx, you can now extract a BACPAC from an existing database and deploy it to a different SQL Server environment, including, wait for it . SQL Azure. Now, it should be noted that SQL Server 2012 comes with the DAC Fx version 2.0 and the ability to export to a BACPAC. The next two sections are going to walk you through creating and deploying BACPACs using SQL Server 2012. You will see how the Import/Export service is used in the Windows Azure Management Portal to import and export to and from a SQL Azure database. Deploying to SQL Azure via a BACPAC using SQL Server 2012 For all those who have not upgraded to SQL Server 2012 the next session will address that, but for now, this section will use SQL Server 2012. First you’ll see how to deploy an on-premises database directly to SQL Azure, and then how to use the built-in import and export features to migrate using BACPACs from SQL Server 2012. Keep in mind that all of the examples in this section assume that your database is Azure-ready, meaning that your on-premises SQL Server database is ready to be migrated to SQL Azure. For example, if you were to download the full AdventureWorks database, such as the SQL Server 2008 R2 version, and then try to walk through the examples in this section, the examples in this section will fail due to objects that aren’t supported in Windows Azure SQL Database (such as native encryption and Full Text Search). The section “Generate and Publish Scripts Wizard” in this chapter explains how to make your database Azure-ready by taking an on-premise database and applying the appropriate modifications and changes. More importantly, it also explains why those changes need to be made. 68 CHAPTER 4 ■ DATA MIGRATION AND BACKUP STRATEGIES The database that these samples use is a database called AWMini, which is a mini version of the AdventureWorks database. This database can be downloaded from the Apress download page for this book. This database is installed Azure-ready so that you can walk though these examples. Download the AWMini.zip file from the APress site for this book and extract the .sql file. Open the .sql file in SQL Server Management Studio (for SQL Server 2012) and connect to your local SQL instance. Run the .sql file, which will create the AWMini database. Once the script has completed, refresh your database list and you’ll see the new AWMini database in your list of databases. Deploying Directly To SQL Azure SQL Server 2012 has made it extremely easy to migrate an on-premises database to SQL Azure. Prior to SQL Server 2012, the options for migration required many steps, were somewhat painful, and didn’t really fit the DAC picture, simply because DACPACs didn’t migrate data. This all changed with SQL Server 2012 and DAC Fx 2.0. Deploying directly to SQL Azure is as simple as a three-step wizard. If it’s not already open, open SQL Server Management Studio for SQL Server 2012. In Object Explorer, expand the Databases node for your server and right-click the AWMini database. From the context menu, select Tasks ➤ Deploy Database to SQL Azure, which will start the database deployment wizard (see Figure 4-1). Figure 4-1. The Deploy Database to SQL Azure menu option In the Deploy Database wizard, click Next on the Introduction page. On the Deployment Settings page of the wizard, you need to specify the connection information for the target SQL Azure server to which the database will be migrated. Click the Connect button, which will bring up the familiar Connect to Server dialog. Enter the SQL Azure server name (in the format server.windows.database.net), along with the username and password for the SQL Azure server, and then click Connect. Next, enter a name for the database (see Figure 4-2). As the wizard states, this is a NEW database, not the name of an existing one.