Don't forget to add a firewall rule for your location! If necessary, now would be a good time log in to the SQL Azure portal ( ) to create a database, add a database user and get the connection settings.
All tables must have a clustered index in SQL Azure, so we should review that list to make sure the recommended index makes sense.Īt this point, we can save the SQL Script, but this script does not migrate the data, which we need to do. One additional action SAMW performed was to add a clustered index to any table without one. It's not important for the demos I need to do. That's not too bad, and for our migration, we'll just delete this trigger. IF NOT EXISTS (SELECT * FROM sys.triggers WHERE parent_class_desc = 'DATABASE' AND name = N'ddlDatabaseTriggerLog') ~ DatabaseDdlTrigger - EVENTDATA is not supported in current version of SQL Azure This incompatibility is also noted in the SQL Script, so it's up to us if we create this trigger or not. The only red flag in this analysis is that EVENTDATA is not currently supported in SQL Azure, so our database DDL trigger will probably not function correctly. Once the analysis is done, we can review the results and check the resulting SQL Script. The analysis took less than a minute for this database.
#COPY ADVENTUREWORKS DATABASE AZURE SQL UPDATE#
The progress bar and results will update as the analysis is performed. One final confirmation and we're ready to go. We can use the Back button to make any changes we need to. The Script Wizard Summary page gives us a confirmation of all the options we've chosen. It's a good idea to look these over manually to make sure all the features we need will be scripted as we want. The Advanced button opens a properties panel where we can set additional settings for the script generation. We have the option of selecting specific objects, but in this case we want to migrate them all. Here we'll choose AdventureWorksDW, the database we wish to analyze. Leaving Master DB selected allows us to choose from a list of databases on the next screen. We're prompted for our database connection information. For now, we're going to analyze our database to see if this is possible. Depending on the results, it's a judgment call on whether to continue with the migration.Īfter starting SAMW, we have a number of actions we can perform. However, there are a lot of features in SQL Server 2008 not supported by SQL Azure see for the list of what is and what is not supported.īefore we do any migration, SAMW can analyze our database, scripts or profiler trace and report back on known unsupported features. Most tables and views should migrate fine, as will most basic stored procedures.
#COPY ADVENTUREWORKS DATABASE AZURE SQL ZIP#
SAMW comes packaged as a zip file-no installation is necessary, but you should read the documentation on Codeplex to understand configuration options and how it looks for features not supported by SQL Azure.
You can get the SQL Azure Migration Wizard (SAMW) from. I have that installed on a local SQL Server 2008 instance (with SQL Server 2008 R2 client bits installed), so we'll migrate from my local instance to our SQL Azure using the SQL Azure Migration Wizard.
For my reporting demos, I prefer to use the DW edition, which is the data warehousing sample. This is a rather puny edition, with all of 32 orders in the database and lacking in some referential integrity. AdventureWorks is the latest of Microsoft's sample databases, and for the basis for a great number of sample applications (including our own Epic AdventureWorks demo.ĪdventureWorks comes in several editions, and the only edition which has a direct Azure migration path is the LT edition ( ).
0 kommentar(er)
