Lab2-SQL Database Migration and Maintenance

Windows Azure SQL Database Migration and Maintenance
Windows Azure SQL Database Migration

and Maintenance
Hands-on Lab
1 Microsoft Confidential - For Internal Use Only

Released:
Terms of Use
© 2014 Microsoft Corporation. All rights reserved.
Information in this document, including URL and other Internet Web site references, is subject to
change without notice. Unless otherwise noted, the companies, organizations, products, domain
names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no
association with any real company, organization, product, domain name, e-mail address, logo, person,
place, or event is intended or should be inferred. Complying with all applicable copyright laws is the
responsibility of the user. Without limiting the rights under copyright, no part of this document may be
reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means
(electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the
express written permission of Microsoft Corporation.
For more information, see Microsoft Copyright Permissions at http://www.microsoft.com/permission
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property
rights covering subject matter in this document. Except as expressly provided in any written license
agreement from Microsoft, the furnishing of this document does not give you any license to these
patents, trademarks, copyrights, or other intellectual property.
The Microsoft company name and Microsoft products mentioned herein may be either registered
trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The
names of actual companies and products mentioned herein may be the trademarks of their respective
owners.
This document reflects current views and assumptions as of the date of development and is subject
to change. Actual and future results and trends may differ materially from any forward-looking
statements. Microsoft assumes no responsibility for errors or omissions in the materials.
THIS DOCUMENT IS FOR INFORMATIONAL AND TRAINING PURPOSES ONLY AND IS PROVIDED "AS IS"
WITHOUT WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND
NON-INFRINGEMENT.
2 © 2014 Microsoft Corporation. All rights reserved.

Table of Contents
Overview .....................................................................................................................................4
Abstract ................................................................................................................................................................. 4
Prerequisites ......................................................................................................................................................... 4
Setup..................................................................................................................... Error! Bookmark not defined.
Using the Code Snippets ..................................................................................... Error! Bookmark not defined.
Exercises ......................................................................................................................................5
Lab 2: Migration and Maintenance .....................................................Error! Bookmark not defined.
Exercise 1 - Evaluating and Preparing our On-Premises Database ....................................................................... 6
Exercise 2 - Migration using the SQL Database Import/Export Service .............................................................. 15
Exercise 3 - Maintenance of SQL Databases ......................................................................................................... 26
Appendix...........................................................................................Error! Bookmark not defined.

Overview
Abstract
In this lab we’ll look at approaches for Migrating from an on-premises SQL Server database
into Windows Azure SQL Database. We’ll then look at the things you should be thinking about
in terms of maintaining your SQL Database databases.
Learning Objectives
In this hands-on lab, you will learn how to:
 Assess an on-premises database for compatibility problems prior to moving to SQL

Database
 Use both scripts and BACPAC approaches to transfer schema and data to SQL
Database
 Determine index fragmentation and rebuild indexes on a database wide basis
 Use the best practice approach for database backup
Estimated time to complete this lab: 60 minutes
Prerequisites
The following is required to complete this hands-on lab:
 Visual Studio Express 2012 for Web or higher

Or Visual Studio Express 2012 for Desktop or higher
http://www.microsoft.com/visualstudio/
 Windows Azure Tools for Microsoft Visual Studio 2.2
http://www.windowsazure.com/en-us/downloads/
 SQL Server Management Studio 2012 Express Edition or higher
http://www.microsoft.com/en-us/download/details.aspx?id=29062
 Access to a SQL Database account with a server created
 SQL Database Firewall enabled for machine running this lab
 A Windows Azure subscription
Sign up for a free trial http://aka.ms/WATK-FreeTrial
Note: This lab was designed to use Windows 8.1 operating system but should be compatible with other operating
environments.

Exercises
This hands-on lab includes the following exercises:
1. Evaluating and Preparing On Premises Databases
2. Migration using the Import/Export Service
3. Maintenance of SQL Database
Estimated time to complete this lab: 60 minutes.

Note: When you first start Visual Studio, you must select one of the predefined settings collections. Every predefined
collection is designed to match a particular development style and determines window layouts, editor behavior,
IntelliSense code snippets, and dialog box options. The procedures in this lab describe the actions necessary to
accomplish a given task in Visual Studio when using the General Development Settings collection. If you choose a
different settings collection for your development environment, there may be differences in these procedures that you
need to take into account.

Exercise 1 - Evaluating and Preparing our On-

Premises Database
In this exercise we will look at two broad approaches for assessing our database for migration
to SQL Database. We will start by loading the AdventureWorks 2012 database into our on-
premises SQL Server. We’ll then use the community supported SQL Database Migration
Wizard to analyze and asses the schema for issues with SQL Database. Actually resolving the
compatibility issues is beyond the scope of this lab, but, this exercise will show you how to
determine compatibility problems.
We’ll then load the schema and data for the Windows Azure SQL Database version of
adventure works locally and use the DACPAC migration method to move this to the cloud.
Note: We assume in this exercise that you have an ‘on-premises’ SQL Server 2012 machine to
work with. If you do not then we suggest setting up a Virtual Machine in Windows Azure for
the purposes of this lab by following this guide: http://www.windowsazure.com/en-
us/manage/windows/common-tasks/install-sql-server/
Task1 - Creating a local copy of AdventureWorks 2012

1. Download the AdventureWorks2012 Data file from
http://msftdbprodsamples.codeplex.com/releases/view/55330#DownloadId=165399
2. Move the file to your SQL Data directory
3. Open SQL Server Management Studio
4. Open a new query window and execute the following code
CREATE DATABASE AdventureWorks2012 ON (FILENAME = '{drive}:\{file

path}\AdventureWorks2012_Data.mdf') FOR ATTACH_REBUILD_LOG;
5. Refresh the list of databases and confirm that the AdventureWorks2012 database exists and
has tables in it.
Task 2: Running the SQL Database Migration Wizard

SQL Database Migration Wizard (SQLAzureMW) is designed to help you migrate your SQL
Server 2005 (or greater) databases to Windows Azure SQL Database. SQLAzureMW will analyze
your source database for compatibility issues and allow you to fully or partially migrate your
database schema and data to Azure SQL Database.
1. Download the SQL Database Migration Wizard from http://sqlazuremw.codeplex.com/.

Get the version that is appropriate for your installed version of SQL Server. If you have SQL
Server 2008 R2 then get the latest 3.9.x version. If you have SQL Server 2012 then get the
4.x version.
2. Extract the contents of the zip file to a working folder.
3. Run the extracted SQLAzureMW.exe application.
4. Select the Database option under the Analyse / Migrate heading.

5. Click the Next button

6. Enter the location and connection credentials to your database server. If you choose the
Database as Master DB then you will be able to choose the specific database to analyze
from a list in the next step.

7. Press the Connect button.

8. Select the AdventureWorks2012 database from the list
9. Click the Next button

10. Keep the default settings and click the Next button.

11. On the summary screen click the Next button and then press Yes to confirm starting.
12. The application will start scripting out the entire database determining schema compatibility
as it goes.
13. Look at the Results Summary tab. This will list all of the steps taken to generate the
database script.

Any issues that you need to deal with will be highlighted in red. For instance in our case with
the AdventureWorks2012 database, there are multiple XML Schema Collections. These are not
supported in SQL Database and so we`d need to change these before we can migrate. Brose
through the log to look at some of the other incompatibilities.
14. Click on the SQL Script tab to view the full resulting script. This also has any issues
highlighted in red, as well as any possible suggestions on how to resolve them.

15. Click the Save button if you wish to save the generated script and modify it.
The actual changes are outside the scope of this lab so we`ll just proceed to clean up.
16. In SQL Server Enterprise Manager, delete the AdventureWorks2012 database to clean up
before we continue.
Task 3: Creating a local copy of the AdventureWorks Azure SQL DB

In this task we will create a local copy of the Azure SQL Database specific version of the
AdventureWorks database. This version has already been modified to work with SQL Database. It
has all of the changes required to fix the errors highlighted in the SQL Database Migration Wizard
that we worked with earlier.
1. Download the AdventureWorks2012ForWindowsAzureSQLDatabase file from

http://msftdbprodsamples.codeplex.com/releases/view/37304
2. Extract out the zip file to a working folder.
3. Open a command prompt with Administrator privileges and navigate to the folder where
the zip file was extracted.
4. Navigate to the AdventureWorks folder
5. Type the following command:
CreateAdventureWorksForSQLAzure.cmd servername username password
For example if your SQL server is local, and you might use the following command:

CreateAdventureWorksForSQLAzure.cmd mylocalmachine SQLAdmin Password1
Note that to run this you will need to use a SQL Server login (not a windows account) to run this
script.
6. There is one minor issue with the current schema in this package. For some reason the
DatabaseLog table doesn’t have a clustered index (which is required for us to migrate to SQL
Azure). Open SQL Server Management Studio and connect to the database server.
7. Right click on the AdventureWorks2013 database in the Object Explorer window, and click
New Query.
8. Copy the following SQL Script into the new query window and click the Execute button. This
will drop the non-clustered index on the table, and recreate it.
ALTER TABLE [dbo].[DatabaseLog] DROP CONSTRAINT [PK_DatabaseLog_DatabaseLogID]

GO
ALTER TABLE [dbo].[DatabaseLog]

ADD CONSTRAINT [PK_DatabaseLog_DatabaseLogID]

PRIMARY KEY CLUSTERED ( [DatabaseLogID] ASC )

GO

Exercise 2 - Migration using the SQL Database

Import/Export Service
Instead of using the SQL Database Migration Wizard at this point, we’ll look at another mechanism
for migrating your local database to SQL Azure.
1. Before we export the local database we need to create a storage container in Azure
storage. Log in to your Azure management portal at http://manage.windowsazure.com/
2. Click on the Storage tab on the left hand side.
3. Select one of your storage accounts (create one if none yet exists). Make sure that you are
using a storage account in the same region as you wish to host your database. Click
anywhere on the line except the name to select it (clicking the name will open the
management window for it).
4. Click on the Manage Access Keys button at the bottom of the screen.
5. Record your Storage Account Name and Primary Access Key for later use (use Notepad or
something similar).

6. Close the window by clicking the tick button.

7. Click on the name of the storage account to open up the management screen for it.
8. Click on the Containers tab at the top
9. Click on the Add button at the bottom of the page.
10. Name the new container adventureworks-bacpac, and leave the access Private.

11. Click on the tick mark to continue and create the storage container.
12. Open SQL Server Management Studio and connect to your local database.
13. Browse to the AdventureWorks2012 database in the Object Explorer window.
14. Right click on the AdventureWorks2012 database and select Tasks, and then Export Data-
tier Application.
15. This will open the wizard to export the schema and data to a BACPAC file format. Click the
Next button

16. In the Export Settings page click on the Save to Windows Azure option

17. Click the Connect button. Enter the Storage Account Name and Primary Access Key that
we recorded from the Azure management portal earlier.
18. Press the Connect button.

19. Choose the adventureworks-bacpac storage container from the dropdown list, then click
the Next button

20. Confirm the details are correct, and click the Finish button. This will start the migration
process. If there are any issues with the schema (for instance if there are any tables
without clustered indexes) then it will inform you so that you can fix them.

21. Close the wizard when the upload is complete.

22. Open the Azure Management Portal again at http://manage.windowsazure.com/
23. Click on the New button in the bottom left.
24. Select the Data Services option, then the SQL Database option, then the Import option.

25. On the Import screen, click on the Browse button to find your bacpac url.
26. Browse to your storage account and find the AdventureWorks2012.bacpac file, and open it

27. Select the subscription, and server that you wish to create the database on. You can
optionally create a new database server at this step too.
28. Enter the administrator username and password for your Azure SQL Database server.

29. Click the tick button to import the database.

30. You can click on the animated active progress button in the bottom right of the screen to
get progress details of your import.
31. Then click on the Importing SQL database line to get more details
32. Eventually this should show a succeeded message.

33. You can now try connecting to your new SQL Azure database with SQL Server
Management Studio or similar application.

Exercise 3 - Maintenance of SQL Databases

Using our newly migrated database we’ll now examine some of the items that should make
up a maintenance plan on SQL Database. While Windows Azure SQL Database frees you from
almost all of the maintenance tasks typically required in an on-premises or even IaaS hosted
database, there are still some tasks that require regular execution. It’s also important to note
what we can’t use many of the approaches we`d use on-premises; this is because there is no
SQL Server agent in SQL Database so we can’t just go ahead and schedule tasks to run. Instead
we need to run any processes ourselves and implement our own schedule mechanism. In this
exercise we’ll cover maintaining our indexes and database statistics. In the final exercise we’ll
look at Backups.
Task 1 - Maintaining Indexes

Indexes provided a separate structure to the database table to lookup data values in a specific
set of columns. In both SQL Server and SQL Database data is stored in Pages. As records are
added there will be times when new Pages must be added to hold them. As records are
deleted and updated gaps can appear in database Pages. Over time indexes tend to become
more and more fragmented, and need to be cleaned up, much the same as files on our disks
need to be defragmented.
1. Open SQL Server Management Studio

2. Connect to your SQL Azure version of the AdventureWorks2012 database that you created
in the previous step.
Remember that when you connect via SQL Server Management Studio you may need to
specify the explicitly specify the <default> database in your connection settings to be able
to see all of the databases on that server.

3. Right click on your AdventureWorks2012 database and click New Query.
4. First of all, let’s see at how we can look at index fragmentation with the
sys.dm_db_index_physical_stats view. In the query window execute the following SQL
Statement:
SELECT name, avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats (
DB_ID() /* current database scope */
, OBJECT_ID('Person.Address') /* schema scoped table name */
, NULL
, NULL
, NULL) AS a
JOIN sys.indexes AS b
ON a.object_id = b.object_id AND a.index_id = b.index_id;
This shows all of the indexes and their fragmentation percentages for the Address table in the
Person schema scope. We have of course only just migrated this data up to SQL Database, so
the level of fragmentation will be very low, however over time this will change.
5. To actually defragment one of these indexes in on premise SQL Server we would use an
ALTER INDEX REORGANISE statement, however REORGANIZE isn’t supported in SQL
Database, so we need to REBUILD them instead. Execute the following SQL statement to
rebuild the primary key index on the table.

ALTER INDEX PK_Address_AddressID

ON Person.Address REBUILD WITH (STATISTICS_NORECOMPUTE = ON)
6. If you re-run the previous SQL query to view the index percentages you’ll notice that there
is now zero fragmentation for that index
7. If we want to see ALL indexes that are over a threshold of 25% fragmentation for the
current database we can use this statement:
SELECT s.name AS SchemaName,
o.name AS TableName,
i.name AS IndexName,
f.avg_fragmentation_in_percent AS Fragmentation
DB_ID()
, NULL
, NULL
, NULL
, NULL) AS f
JOIN sys.indexes AS i
ON f.object_id = i.object_id AND f.index_id = i.index_id
JOIN sys.objects AS o
ON i.object_id = o.object_id
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
WHERE f.avg_fragmentation_in_percent > 25
8. Now we will leverage these previous tasks to create a stored procedure which will iterate
through all of these indexes and rebuild each of them.
CREATE PROCEDURE DefragIndexes
AS
DECLARE @Schema VARCHAR(255)
DECLARE @Table VARCHAR(255)
DECLARE @Index VARCHAR(255)
DECLARE DefragItems CURSOR FOR

SELECT s.name AS SchemaName,
o.name AS TableName,
i.name AS IndexName

DB_ID()
, NULL
, NULL
, NULL
, NULL) AS f
JOIN sys.indexes AS i
ON f.object_id = i.object_id AND f.index_id = i.index_id
JOIN sys.objects AS o
ON i.object_id = o.object_id
JOIN sys.schemas AS s
ON o.schema_id = s.schema_id
WHERE f.avg_fragmentation_in_percent > 25
OPEN DefragItems
FETCH NEXT FROM DefragItems INTO @Schema, @Table, @Index
WHILE @@FETCH_STATUS = 0
BEGIN
PRINT 'Rebuild index ' + @Index + ' on ' + @Schema + '.' + @Table
EXECUTE ('ALTER INDEX '

+ @Index
+ ' ON '
+ @Schema + '.' + @Table
+ ' REBUILD WITH (STATISTICS_NORECOMPUTE = ON)')
FETCH NEXT FROM DefragItems INTO @Schema, @Table, @Index

END
CLOSE DefragItems
DEALLOCATE DefragItems
PRINT 'All fragmented indexes rebuilt'

;
9. And now execute this stored procedure.
EXEC DefragIndexes
This mechanism that we’ve built here is using a cursor to loop through all of the indexes and
execute a dynamic SQL statement for each. You could just as easily build a windows console
application which iterates through the list of indexes.
Whatever mechanism that you use, this should be scheduled to run on a regular basis to keep
your indices fine-tuned.
Task 2 - Backup
When we are working with SQL Azure databases we don’t have access to the usual backup
mechanisms that we`d use on premises.
The recommended backup strategy is to use a two stage process for capturing snapshot
backups. First create a copy of the database, and then export the copy to a BACPAC file.
Let’s start with the first step: copying the database.

1. Open SQL Server Management Studio and connect to the SQL Database server that has the
AdventureWorks2012 database.
2. Expand the databases in the Object Explorer window and find the master database.
3. Right click on the master database and select New Query.
4. Execute the following SQL command
CREATE DATABASE AdventureWorks2012_Backup AS COPY OF AdventureWorks2012
This will start the asynchronous process of copying the database. You can execute the
following SQL query to monitor the progress of the copy.
SELECT
D.name,
D.state_desc,
DC.replication_state,
DC.replication_state_desc,
DC.percent_complete,
DC.error_code,
DC.error_desc,
DC.error_severity,
DC.error_state
FROM sys.databases D
INNER JOIN sys.dm_database_copies DC
ON D.database_id = DC.database_id
5. To determine that the copy is complete the previous query should return zero results
indicating that there are no copies in progress.
6. Now we need to run a reverse of the BACPAC import process we saw earlier. We want to
do this using API calls so we’ll start with a sample application. Download the
Import/Export Service Community Sample Application from
http://code.msdn.microsoft.com/windowsazure/Windows -Azure-SQL-Database-5eb17fe2.
7. Unzip the archive and double click on the WASDImportExport.sln file to open it up with
Visual Studio.
8. Open and browse through the ImportExportHelper.cs file to see how it works.
The sample code is calling the RESTful web service end points for the import/export
service that are provided in Windows Azure. There are two main methods, Import and
Export, to perform the main tasks, plus a CheckRequestStatus method to query the
progress of a given task.
9. Open the Program.cs file.
10. At the start of the Main method there are several commented out lines showing the URLs
to the different Import/Export endpoints in each data center. Modify the
IEHelper.EndPointUri value to use the service in which your SQL Azure database resides.
11. Modify the IEHelper.ServerName property with your database server name.
12. Modify the IEHelper.StorageKey property with your storage account access key. This is
the same key which we used back in Exercise 2. Note that in the example below we have

prefixed the string with an @ symbol to avoid formatting issues with any embedded
escape characters.
13. Modify the IEHelper.DatabaseName property with your backup database name
(AdventuresWorks2012_backup).
14. Modify the IEHelper.UserName property with the administrator user name for your SQL
Database server.
15. Modify the IEHelper.Password property with the administrator password for your SQL
Database server.
16. Modify the exportBlobPath and replace the [storagename] part of the string with your
Azure storage account name
17. On the same line replace the /bacpac/ path section with your storage container name
18. Add a line of code to write out the export blob path:
Console.WriteLine("Exported to " + exportBlobPath);
19. We don’t need to import the BACPAC file again after we’ve exported it, so comment out all
of the remaining code except the Console.ReadKey() line.
20. Press F5 to run the application

You will note that we haven’t provided any mechanism for ‘automating’ the maintenance
tasks. One option for this would be to use a service running in an Azure Worker Role.
This service could be designed to poll on a regular basis to trigger the backup pr ocess, or
alternatively we could use the Windows Azure Scheduler (see
http://www.windowsazure.com/en-us/services/scheduler/) to trigger the backup.
Note that we need to run this as a background task running in a worker role, rather than just
using an HTTP call because large backups can take a very long time to run; we don’t want to
hit an HTTP timeout and die half way through.
Another place to watch for timeouts with Entity Framework; this has a 10 minute timeout
defined in the machine.config file in Windows Azure Cloud Service roles.

Lab2-SQL Database Migration and Maintenance

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lab2-SQL Database Migration and Maintenance

Uploaded by

Copyright:

Available Formats

Windows Azure SQL Database Migration and Maintenance

Windows Azure SQL Database Migration

1 Microsoft Confidential - For Internal Use Only

2 © 2014 Microsoft Corporation. All rights reserved.

Appendix...........................................................................................Error! Bookmark not defined.

3 Microsoft Confidential - For Internal Use Only

In this hands-on lab, you will learn how to:

 Assess an on-premises database for compatibility problems prior to moving to SQL

Estimated time to complete this lab: 60 minutes

 Visual Studio Express 2012 for Web or higher

4 © 2014 Microsoft Corporation. All rights reserved.

3. Maintenance of SQL Database

Estimated time to complete this lab: 60 minutes.

5 Microsoft Confidential - For Internal Use Only

Exercise 1 - Evaluating and Preparing our On-

Task1 - Creating a local copy of AdventureWorks 2012

CREATE DATABASE AdventureWorks2012 ON (FILENAME = '{drive}:\{file

Task 2: Running the SQL Database Migration Wizard

1. Download the SQL Database Migration Wizard from http://sqlazuremw.codeplex.com/.

4. Select the Database option under the Analyse / Migrate heading.

6 © 2014 Microsoft Corporation. All rights reserved.

5. Click the Next button

7 Microsoft Confidential - For Internal Use Only

7. Press the Connect button.

9. Click the Next button

8 © 2014 Microsoft Corporation. All rights reserved.

9 Microsoft Confidential - For Internal Use Only

10 © 2014 Microsoft Corporation. All rights reserved.

11 Microsoft Confidential - For Internal Use Only

Task 3: Creating a local copy of the AdventureWorks Azure SQL DB

1. Download the AdventureWorks2012ForWindowsAzureSQLDatabase file from

CreateAdventureWorksForSQLAzure.cmd servername username password

12 © 2014 Microsoft Corporation. All rights reserved.

CreateAdventureWorksForSQLAzure.cmd mylocalmachine SQLAdmin Password1

ALTER TABLE [dbo].[DatabaseLog] DROP CONSTRAINT [PK_DatabaseLog_DatabaseLogID]

ALTER TABLE [dbo].[DatabaseLog]

13 Microsoft Confidential - For Internal Use Only

PRIMARY KEY CLUSTERED ( [DatabaseLogID] ASC )

14 © 2014 Microsoft Corporation. All rights reserved.

Exercise 2 - Migration using the SQL Database

15 Microsoft Confidential - For Internal Use Only

6. Close the window by clicking the tick button.

8. Click on the Containers tab at the top

9. Click on the Add button at the bottom of the page.

16 © 2014 Microsoft Corporation. All rights reserved.

17 Microsoft Confidential - For Internal Use Only

18 © 2014 Microsoft Corporation. All rights reserved.

18. Press the Connect button.

19 Microsoft Confidential - For Internal Use Only

20 © 2014 Microsoft Corporation. All rights reserved.

21. Close the wizard when the upload is complete.

21 Microsoft Confidential - For Internal Use Only

22 © 2014 Microsoft Corporation. All rights reserved.

23 Microsoft Confidential - For Internal Use Only

29. Click the tick button to import the database.

32. Eventually this should show a succeeded message.

24 © 2014 Microsoft Corporation. All rights reserved.

25 Microsoft Confidential - For Internal Use Only

Exercise 3 - Maintenance of SQL Databases

Task 1 - Maintaining Indexes

1. Open SQL Server Management Studio

26 © 2014 Microsoft Corporation. All rights reserved.

3. Right click on your AdventureWorks2012 database and click New Query.

27 Microsoft Confidential - For Internal Use Only