Windows Vista
Windows 7
Windows Azure
Windows Server
Windows Phone
Windows Azure

Introduction to SQL Azure : Migrating schema and data

6/13/2011 5:29:12 PM
- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
The ability to create new database objects is good, but for a number of applications we'll need to migrate an existing database. For an on-premise SQL Server, to move a database, we'd commonly use a backup and restore, or detach and reattach neither of those options are available to us in SQL Azure. However, many of the other options we might use, such as DAC Packs or SSIS, are available to us in Azure. An overview of how to migrate applications and data to SQL Azure can be found at http://msdn.microsoft.com/en-us/library/ee730904.aspx.

Manually scripting objects and data

Before any scripts are manually created, there are a few scripting options we need to change to ensure our objects are created correctly on SQL Azure. In SSMS, the settings we need to change can be found at Tools | Options | SQL Server Object Explorer | Scripting. The first setting we need to change is, setting the Script for database engine type option to the SQL Azure Database option, as seen in the following screenshot. Changing this setting will change some other settings and disable others.

By default, dependent objects will not be scripted. This may need to be set to "True" depending on the needs and database schema. Likewise, triggers and indices will not be scripted by default. If these are necessary, we need to enable these settings too.

For complete control over the migration process, we can create scripts for specific objects and data by using SSMS, then running these scripts into our SQL Azure database. For large databases, this can be a time-consuming process. Using this method will script foreign keys, so it may be necessary to create tables in a particular order, or tweak the scripts to run table first, and then defaults and foreign keys.

A related option is to use the Generate Script Wizard (GSW). To use the GSW, right-click on the database name and choose Tasks | Generate Scripts. The table scripts are not created in a relational manner, so we need to ensure we run the scripts in the proper order. The output is a .sql file, which we can execute against a database instance.

SQL Azure Migration Wizard

The SQL Azure Migration Wizard is a community project that can be used to migrate objects and data from SQL Server 2005/2008 databases. The project can be found at http://sqlazuremw.codeplex.com/. Because there may be incompatibilities between the older SQL Server versions and SQL Azure, it is recommended that a test migration be performed into a local SQL Server 2008 (or higher) database, and then migrated into SQL Azure.

The SQL Azure Migration Wizard allows us to migrate an entire database, or to select specific objects to migrate, as seen in the next screenshot. The output is T-SQL scripts that can be executed in SQL Azure to make the necessary changes.

We have a great deal of control over the migration settings, including migrating only tables, only data, or tables and data by changing the Script Table / Data setting. It's a good idea to fully review these setting before generating the SQL scripts.

SQL Server Integration Services (SSIS)

We can migrate tables and data using the SQL Server Import and Export Wizard, or create an SSIS package from scratch. SSIS packages do not execute on SQL Azure, they can only create connections to SQL Azure database and perform the functions as programmed. If we plan on using SSIS, we will need an on-premise SQL Server instance to host the packages.

SQL Server Import and Export Wizard

The SQL Server Import and Export Wizard (http://msdn.microsoft.com/en-us/library/ms140052.aspx) can be used to migrate tables and data between an on-premises SQL Server and SQL Azure. At the end of the wizard, we have the option of saving the package created by the wizard so that we can use it again. To launch the wizard, right-click on a database in an on-premise instance and choose Tasks | Export Data (at the time of writing, the Import wizard cannot be launched by clicking on a SQL Azure database, so we have to export from our on-premise instance).

We can choose to migrate all the data in one or more tables, or write a query to migrate a limited data set from a single table, as seen in the next screenshot:

We can also set options to create tables, enable identity insert, and more, by choosing the Edit Mappings button from the Select Source Tables and Views screen. These are important options to consider if we want to save the package produced by the wizard.

Although views can be selected, the view definition is not migrated. The view is treated as a table in the source database, and a table will be created in the target database with the same name as the view, containing the data in the view at the time the package was run. View definitions should be migrated with some other technique to ensure they are migrated correctly.

At the end of the wizard, we can choose to save the SSIS package as well as execute it. Be careful while saving the package, as everything we asked the package to do will be saved, and some of the settings we chose may be a good idea for a first time (such as creating tables) but not a subsequent run (as the tables exist, they cannot be created and the package will fail).

Creating packages from scratch

We can create SSIS packages to migrate database objects and data to SQL Azure. SSIS uses an ODBC connection to connect to SQL Azure, and just as with Access 2010, we need to make sure the SQL Server Native Client 10.0 driver is installed. Besides the driver requirement, creating an SSIS package in Business Intelligence Development Studio (BIDS) is the same as working with other SQL Server versions.

When running on a schedule, SSIS packages are not suitable for migrating database objects. SSIS is good for migrating data, and may be an alternative to the data synchronization services mentioned above.

DAC Packs

One more option we have is the data-tier application package (DAC Pack). DAC Packs can be used to migrate database schemas from one server instance to another. DAC Packs can be created either in SSMS or with custom .NET code. The SSMS option is easier, but is a manual process. An overview of using DAC Packs can be found at http://msdn.microsoft.com/en-us/library/ee210546.aspx.

We can extract DAC Packs from SQL Server 2000 or higher, but we can deploy DAC Packs only on SQL Azure and SQL Server 2008 R2 or higher a version.

A DAC Pack is created in SSMS by right-clicking on a database name, then choosing Tasks | Extract data-tier application. By following through the wizard, we can create a DAC Pack. The output of the Extract wizard is a file stored on our local machine. A .dacpac file is actually just a ZIP file containing several XML files that describe our database's structure.

To deploy the DAC Pack, we need to connect to the database instance in SSMS 2008 R2, right-click on the instance name, and choose Deploy Data-tier Application.

One of the major downsides to a DAC Pack is that not all object types are supported. We also don't get to choose what is included in our DAC Pack; SQL Server assumes we want everything to be included. This means we need to be careful with what we're doing or we might migrate some half-baked features into production, or migrate views or stored procedures that reference a non-available database.

DAC Packs do not migrate data. So after we deploy a DAC Pack, we would need to use SSIS to migrate the data.

If we want to use custom .NET code, the MSDN documentation for the DAC Pack namespace can be found at http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.dac.aspx.


For migrating large amounts of data to SQL Azure, the command line BCP.exe utility can be utilized. BCP works the same with SQL Azure as any other version of SQL Server. Documentation for the BCP.exe utility can be found at http://msdn.microsoft.com/en-us/library/ms162802(SQL.105).aspx.
Other -----------------
- Introduction to SQL Azure
- Overview of SQL Azure
- Microsoft Azure : Designing our Sample Application
- Microsoft Azure : Setting Up for Development
- SOA with .NET and Windows Azure : Service Performance Optimization Techniques
- Service-Oriented Presentation Layers with .NET : A Simple Service-Oriented User Interface
- Service-Oriented Presentation Layers with .NET : Design Patterns for Presentation Logic
- Service-Oriented Presentation Layers with .NET : Windows Presentation Foundation and the Prism Library
- Working with Windows Azure Platform AppFabric Service Bus (part 2) - Defining a REST-Based Service Bus Contract & Creating the Service Bus Message Buffer
- Working with Windows Azure Platform AppFabric Service Bus (part 1) - Setting up the AppFabric Service Bus
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
Windows Vista
Windows 7
Windows Azure
Windows Server