Microsoft Assessment and Planning (MAP) is a powerful tool to inventorize, assess and report your IT asset inventory. The new version, MAP 5.5 has new features that automates discovery of heterogeneous database instances for migration to SQL Server. The tool provides network inventory reporting for MySQL, Oracle and Sybase instances in your environment. Once you discover those instance, you can use SSMA to migrate.

Learn more about MAP Toolkit here and request for MAP Toolking 5.5 Beta participation from here.

The next version of the Microsoft Assessment and Planning (MAP) Toolkit—version 5.5— is now available for free download.

·         Download MAP 5.5

Simplify planning for migration to the latest Microsoft products and technologies with the Microsoft Assessment and Planning (MAP) Toolkit 5.5. This multifaceted tool is now even better—with assessment for easier migration to the Windows Azure platform, heterogeneous database discovery (of MySQL, Oracle and Sybase instances) for SQL Server migration projects, Windows Internet Explorer migration assessment, and much more—MAP 5.5 includes new features to help you streamline planning for your next migration project.

MAP works with the Microsoft Deployment Toolkit and Security Compliance Manager to help you plan, securely deploy, and manage new Microsoft technologies—easier, faster, and at less cost. Learn more.

Next steps:

·         Download MAP 5.5

·         Learn more about the MAP Toolkit.

·         View the MAP 5.5 demo.

·         Send your questions or comments to the MAP Team.

Get the latest tips from Microsoft Solution Accelerators—in 140 characters or less! Follow on Twitter: @MSSolutionAccel.

By Bill Ramos, Advaiya

[Updated 2/6/2012 Han Wong - Microsoft SQL Server Migration Assistant (SSMA) for MySQL v5.2.  The information provided below is still valid for SSMA for MySQL v5.2.  Users should download the lastest SSMA for MySQL]

In this blog, I’m going to walk you through the process of converting the MySQL Sakila-DB sample database to SQL Server 2008 R2 Express using the SQL Server Migration Assistant for MySQL v1.0 [Updated:  Please obtain the lastest SSMA for MySQL] (SSMA). The Sakila-DB database has tables, views, stored procedures, functions and triggers that make the conversion interesting. The sample is based on the Inno-DB example, but does have one MyISAM table. SSMA also allows you to migrate your MySQL databases to SQL Azure, but we’ll save that topic for another post.

Downloading SQL Server 2008 R2 Express and SSMA

The easiest way to download SQL Server 2008 R2 Express, SQL Server Management Studio and SSMA is through the Microsoft Web Platform Installer (WPI). Once you’ve downloaded WPI, you can select from a variety of tools and products that can get you up and running using IIS, PHP, and SQL Server in no time.

I’ll focus on the minimum set of tools you need to get SQL Server 2008 R2 Express and SSMA up and running. once you launch WPI, click on the Products tab at the top tool and then select Database in the navigation page. In the image above, I’ve already installed the tools, but for the new install, you’ll click on the Add buttons to the right of the circled products to get you up and running. If you are running your application under PHP, you might also want to select one of the two PHP drivers for SQL Server as well. Once you’ve selected your tools, just click on the install button to start the process.

Downloading the MySQL ODBC Driver

WPI is not without flaws. SSMA requires the “MySQL OSBC Driver 5.1 or above” download to connect to your MySQL instance that comes from the MySQL downloads site. Once at the Download Connector/ODBC page, your need to download either the x32 or x64 version of the driver based on the machine architecture for the system you are running the SSMA client. Just follow the installation instructions from the installer. The default installation settings will be good enough to get you going.

Other Helpful Downloads for SSMA and this Blog

You’ll also want to download the “Guide to Migrating from MySQL to SQL Server 2008” white paper, though this blog and others to follow will keep you on track.

If you don’t already have the Sakila-DB database for MySQL installed, the link to the download and instructions for installing it can be found at the blog post titled “Learn MySQL With Sakila sample Mysql Database”

Using SSMA for MySQL

SQL Server Migration Assistant (SSMA) 2008 for MySQL lets you quickly convert MySQL database schemas to SQL Server 2008, SQL Server 2008 R2 or SQL Azure schemas, upload the resulting schemas the target instance and migrate the data using a single tool.

Licensing SSMA

SSMA is a free tool, but does require you to associate a Microsoft Live ID for identification purposes. You must download a registration key. To help you with the registration process, a License Key Required dialog box opens the first time that you start the SSMA program. Use the following instructions to download a license key and associate the key with SSMA.

To license SSMA

1. Click Start, point to All Programs, point to Microsoft SQL Server Migration Assistant 2008 for MySQL, and then select Microsoft SQL Server Migration Assistant 2008 for MySQL.

2. In the License Management dialog box, click the license registration page link.

3. On the Sign In Web page, enter your Windows Live ID user name and password, and click Sign In.

   A Windows Live ID is a Hotmail e-mail address, MSN e-mail address, or Microsoft Passport account. If you do not have one of these accounts, you will have to create a new account. To create a new account, click the Sign up now button.

4. On the SQL Server Migration Assistant for MySQL License Registration Web page, fill in at least the required fields, which are marked with a red asterisk, and then click Finish.

5. In the File Download dialog box, click Save.

6. In the Save As dialog box, locate the folder that is shown in the License Management dialog box, and then click Save.

   The default location is C:\Documents and Settings\user name\Application Data\Microsoft SQL Server Migration Assistant\m2ss.

7. In the License Management dialog box, click Refresh License.

SSMA for MySQL User Interface

After SSMA is installed and licensed, you can use SSMA to migrate MySQL databases to SQL Server 2008 or SQL Azure. It helps to become familiar with the SSMA user interface before you start. The following diagram shows the user interface for SSMA, including the metadata explorers, metadata, toolbars, output pane, and error list pane:

S

Basic Steps for Migration of MySQL to SQL Server

To start a migration, you’ll need to perform the following high level steps:

1. Create a new project.

2. Connect to a MySQL database.

3. After a successful connection, MySQL schemas will appear in MySQL Metadata Explorer. Right-click objects in MySQL Metadata Explorer to perform tasks such as create reports that assess conversions to SQL Server 2008 R2 Express. You can also perform these tasks by using the toolbars and menus.

You’ll then connect to your instance of SQL Server 2008 R2 Express. After a successful connection, a hierarchy of your existing databases will appear in SQL Server Metadata Explorer. After you convert MySQL schemas to SQL Server schemas, select those converted schemas in SQL Server Metadata Explorer, and then synchronize the schemas with SQL Server.

After you synchronize converted schemas with SQL Server 2008 R2 Express, you can return to MySQL Metadata Explorer and migrate data from MySQL schemas into target database.

Let’s walk through the specifics.

Create a MySQL Migration Project

To get started, you’ll create your new project using the File | New Project command.

You’ll enter in your project name and then confirm that you are migrating to SQL Server. The Migrate To dropdown also allows you to choose SQL Azure, but that’s for another post. Once you make your selection, you are locked into the target backend.

Connect to a MySQL Database

To Connect to your MySQL instance, you’ll issue the File | Connect to MySQL command or click on the tool bar button that launches the following dialog:

If you forgot to to install the MySQL ODBC driver mentioned at the beginning of this blog, simply go to the download site, install the driver, and then issue the Connect to MySQL command.

Create Report of Potential Conversion Issues

Once you are connected, you’ll see the MySQL instance in the MySQL Metadata Explorer. You’ll want to expand the Databases node along with the Sakila database node and then check the box next to Sakila. This selects the database you want to migrate. Next, right click on the Sakila database and select the Create Report command or press the Create Report command on the toolbar as shown below.

Here is an example of the Assessment Report for the Sakila database.

The Assessment Report window contains three panes:

• The left pane contains the hierarchy of objects that are included in the assessment report. You can browse the hierarchy, and select objects and categories of objects to view conversion statistics and code.

• The content of the right pane depends on the item that is selected in the left pane.

  If a group of objects is selected, such as schema, the right pane contains a Conversion statistics pane and Objects by Categories pane. The Conversion Statistics pane shows the conversion statistics for the selected objects. The Objects by Categories pane shows the conversion statistics for the object or categories of objects.

  If a function, procedure, table or view is selected, the right pane contains statistics, source code, and target code.

  • The top area shows the overall statistics for the object. You might have to expand Statistics to view this information.

  • The Source area shows the source code of the object that is selected in the left pane. The highlighted areas show problematic source code.

  • The Target area shows the converted code. Red text shows problematic code and error messages.

• The bottom pane shows conversion messages, grouped by message number. You can click Errors, Warnings, or Info to view categories of messages, and then expand a group of messages. Click an individual message to select the object in the left pane and display the details in the right pane.

In future blog posts, we’ll work through the specific problems that are in this report. For now, we’ll ignore the problematic objects for the schema and data migration steps. For now, close the report and then uncheck Functions, Procedures and Views nodes to take them out of the conversion. Then uncheck the tables with errors as shown below.

Go ahead and click on the Create Reports command to verify that there are no errors.

Connect to SQL Server

It’s time to connect SSMA to your SQL Server 2008 R2 Express instance. For the Server name, you’ll need the server name and instance for the target server. Since we are using the WPI installation of SQL Server 2008 R2 Express, you’ll enter in the server name as .\SQLEXPRESS.

You can select an existing database to migrate to using the Database control. You can also type in the name of a new database. In this case, use Sakila as shown below.

Once you click connect, SSMA prompts you if you want to create the database. Choose Yes to create the new database. When connecting to SQL Server Express instances, you’ll receive the following warning indicating that you won’t be able to use the server-side data migration engine. This engine is used for larger migration projects.

You can Continue from this dialog to start the actual migration process.

Convert Schema

Now that you’ve connected to the target SQL Server instance, SSMA enables the Convert Schema command. Click the Convert Schema command. Once the conversion is finished, you should see the SQL Server Metadata Explorer populated with the tables listed in bold as shown below.

Synchronize with Database

To write the tables to the target, select the dbo node in the SQL Server Metadata Explorer and then issue the Tools | Synchronize with Database command. SSMA displays the Synchronize with Database dialog as shown below. In this example, the Tables node was manually expanded to show that no tables are actually on the database at this time.

When you click OK, SSMA issues the CREATE TABLE statements to create the objects on the SQL Server target. There are some errors in this example because many of the tables selected have foreign key relationships to some of the tables that we excluded earlier. These errors can be ignored for now.

Migrate Data

The last step is to migrate the data into the tables. To complete the migration, select the Tables node within the MySQL Metadata Explorer for the Sakila database. Then issue the Tools | Migrate Data command or press the command on the toolbar. The Data Migration process requires you to connect to the MySQL database and to the SQL Server database again. SSMA then proceeds with the data migration process and displays the Data Migration Reports as shown below.

Using SQL Server Management Studio

The migrated tables are now ready on the target SQL Server instance. To see the results, launch SQL Server Management Studio (SSMS) and connect using the server name as .\SQLEXPRESS. Expand out the Databases node to see the Sakila database. Expand the out the Sakila database tables and then right click on the actor table and issue the Select Top 1000 Rows command to view the data as shown below.

SQL Server Management Studio that is part of the WPI is a free rich Windows client tool from Microsoft that offers a rich development and management experience like  SQLyog and MONyog.

BIO

Bill Ramos is the SQL Server Work Stream Manager for Advaiya. During his 15 years at Microsoft as a program manager, he has been on teams that have shipped the following products: Project Houston, SQL Server 2008 R2, SQL Server 2008, SQL Server 2005, SQL Server 2000, SQL Server 7.0, SQL Server 6.5, Ashton-Tate/Microsoft SQL Server for OS2 (at Ashton-Tate), Excel 2003, Access 2003, Access XP, Access 2000. You can find his personal blog at http://blogs.msdn.com/billramo and on Twitter at http://twitter.com/billramo.

One of the first decisions you need to make when migrating to SQL Server is to decide whether to migrate to a schema or to a database. There may be different concept of schema between your source database product and SQL Server. Unlike Oracle, for example, schema in SQL Server is not necessarily linked to a specific user or a login. SQL Server can also contain multiple databases. For more information about user schema concept in SQL Server, visit http://msdn.microsoft.com/en-us/library/ms190387.aspx

Using SSMA, you have the option to migrate a schema to a SQL Server database or migrate to a schema in a specified SQL server database.

• Migrate schema to a separate SQL Server Database

This is the default conversion approach in SSMA and is the preferred approach when there are few references between source database schemas. The converted schema will be assigned to "dbo" schema in SQL Server - the default database owner in SQL Server.

• Migrate schema to a SQL Server Database.

You can modify the project setting to map the source schema to a schema with the same name in an existing SQL Server database. You should consider to use this approach if your source schemas are deeply linked with each other (such as the case where you have many foreign key relationship to another table in a different schema). SQL Server does not allow constraint relationship to another table in a different database. You may implement a workaround using database triggers for one-off scenario.

To specify the conversion option, go to SSMA project setting > conversion > general:

Under default schema mapping, you can select whether to map "Schema to Database" or "Schema to Schema".

SSMA provides a project setting that allow you to customize how the conversion is done. This post describes the project setting options available for you as well as scenarios where you want to customize the setting.

SSMA project setting options are categorized into the following:

• Project Information:  provides project name and location where the project file is saved.

• General : provides more granular setting for the following:
  • Conversion: settings for schema conversion

There are many options for schema conversion, to simplify the selection, you can select "setting mode" that include predefined selection of the project setting. SSMA comes with three setting mode: default, optimistic and full. Optimistic mode contains the setting which leverages  native SQL Server syntax as much as possible but there is a chance that in some cases those syntax may not give the same results in SQL Server.  For example, in Optimistic mode, Oracle's substr() function is converted to SQL Server's substring() function. However, there are situation where substring() gives a different result:

• Oracle: SELECT substr('SQL Server', 5) FROM dual; -- returns 'Server')

SQL Server: SELECT substring('SQL Server', 5); -- returns error 'The substring function requires 3 argument'

• Oracle: SELECT substr('SQL Server',-6,3) FROM dual; -- return 'Ser'

SQL Server: SELECT substring('SQL Server',-6,3); -- return ''

If you select full mode, the substring is converted to SSMA's custom emulation function to give closer result to Oracle's function. Default mode selects the common option for most migration projects.

• Migration: settings for migrating data, including option to select whether migration is done through the client machine where SSMA is installed or through server side data migration engine" where data flows directly from source to target SQL Server. Other setting options include:

• Batch size : Batch size that is used during data migration. A transaction is logged after each batch.The default value is 1000.
• Break on error : Stops all data migration if any migration error occurs.

• Break on table error : Stops data migration of the current table if a data migration error occurs. SSMA will continue with the next table.

• Check constraints: Specifies whether SSMA should check constraints when it inserts data into SQL Server tables.

• Fire triggers: Specifies whether SSMA should fire insertion triggers when it inserts data into SQL Server tables.

• Keep identity : Specifies whether SSMA will preserve identity values when it inserts data into SQL Server. If this value is false, SQL Server will assign identity values.

• Keep nulls : Specifies whether SSMA will preserve null values in the source data when it inserts data into SQL Server, regardless of the default values that are specified in SQL Server.

• Table lock : Specifies whether SSMA will lock tables when it inserts data into the table during data migration. If the value is false, SSMA will use row locks.

• Loading system objects: setting to specify what Oracle object to be automatically loaded when connecting to Oracle.

Converting system objects consumes system resources and takes time. To improve performance, SSMA selects only the most frequently used system objects, as shown in the following list:

• SYS.DBMS_OUTPUT

• SYS.DBMS_PIPE
• SYS.DBMS_UTILITY

• SYS.STANDARD

• SYS.UTL_FILE

• SYS.DBMS_LOB

• SYS.DBMS_SQL
• SYS.DBMS_SESSION

If your Oracle objects refer to additional system objects, you should select those objects. If you do not select the system objects that are referenced by your Oracle database objects, SSMA will report conversion errors. If you receive conversion errors caused by missing system objects, select the missing objects in this dialog box. You can then repeat the conversion as necessary.

• Synchronization :  customize how SSMA loads and refreshes database objects, such as tables and stored procedures, into SQL Server.
• GUI: configures how data appears on the Data tab and if to include data reports with assessment reports
• Type Mapping: customizes how SSMA converts Oracle data types into SQL Server data types. SSMA provides flexibility for mapping data types. You can set different mapping for data type from table column, local variable, and/or argument.

[Updated 2/7/2012 Selina Jia - Microsoft SQL Server Migration Assistant (SSMA) for MySQL v5.2.  The information provided below is still valid for SSMA for MySQL v5.2.  Users should download the lastest SSMA for MySQL]

In this blog post, I will describe how to setup your trial SQL Azure account for your migration project, create a “free” database on SQL Azure and walkthrough differences in the process of using SSMA to migrate the tables from the MySQL Sakila sample database to SQL Azure. For a walkthrough of how to migrate a MySQL database to SQL Server, please refer to the post “MySQL to SQL Server Migration: How to use SSMA”. This blog assumes that you have a local version of the MySQL Sakila-DB sample database already installed and that you have  SQL Server Migration Assistant for MySQL v1.0 [Updated:  Please obtain the lastest SSMA for MySQL] (SSMA) installed and configured using the instructions provided in the “MySQL to SQL Server Migration: How to use SSMA” blog post.

Getting Started with SQL Azure

If you don’t have a SQL Azure account, you can get a free trial special at http://www.microsoft.com/windowsazure/offers/ through June 30th, 2011. The trial includes a 1GB Web Edition database. Click on the Activate button to get your account up and running. You’ll log in with your Windows Live ID and then complete a four step wizard. Once you are done, the wizard will take you to the Windows Azure Platform portal. If you miss this trail, stay tuned for additional trial offers for SQL Azure.

The next step is to create a new SQL Azure Server by clicking on the “Create a new SQL Azure Server” option in the Getting Started page. You will be prompted for your subscription name that you created in the wizard, the region where your SQL Azure server should be hosted, the Administrator Login information, and the firewall rules. You will need to configure the firewall rules to specify the IPv4 address for the computer where you will be running SSMA.

Click on the Add button to add your firewall rule. Give it a name and then specify a start and end range. The dialog will display your current IPv4 address so that you can enter it in for your start and end range.

Once you are done with the firewall rules, you can then click on your subscription name in the Azure portal to display the fully qualified server name that was just created for you. It will look something like this: x4ju9mtuoi.database.windows.net. You are going to use this server name for your SSMA project.

Using the Azure Portal to Create a Database

SSMA can create a database as part of the project, but for this blog post I’m going to walk through the process of creating the database using the portal and then use the SSMA feature to place the resulting database in a schema within the database. Within the Azure portal, with the subscription selected, you will click in the Create Database command to start the process.

Enter in the name of the database and then keep the other options as the defaults for your free trial account. If you have already paid for a SQL Azure account, you can use the Web edition to go up to 5 GB or switch to the Business edition to up the size limit between 10GB and 50GB. Once created, you will want to click on the Connection Strings – View button to display the connection string information you will use for your SSMA project shown below. The password value shows just a placeholder value.

You are now ready to setup your SSMA project.

Using SSMA to Migrate a MySQL Database to SQL Azure

Once you start SSMA, you will click on the New Project command shown in the image below, enter in the name of the project, and select the SQL Azure option for the Migration To control.

You will then follow the same processes described in the “MySQL to SQL Server Migration: How to use SSMA” blog post that I will outline below.

1. Click on the Connect to MySQL toolbar command to complete the MySQL connection information.
2. Expand out the Databases node to expand the Sakila database and check the Tables folder as shown below.
   
   
3. Click on the Create Report command in the toolbar button. You can ignore the errors. For information about the specific errors with converting the Sakila database, please refer to the blog post “MySQL to SQL Server Migration: Method for Correcting Schema Issues”. Close the report window.
4. Click on the Connect to SQL Azure button to complete the connection to your target SQL Azure database. Use the first part of the server name and the user name for the administrator as shown below. If you need to change the server name suffix to match your server location, click on the Tools | Project Settings command, click on the General button in the lower left of the dialog and then click on the SQL Azure option in the tree above. From there you can change the suffix value.
   
   
5. Expand out the Databases node to see the name of the database created in the SQL Azure portal. You will see a Schemas folder under the database name that will be the target for the Sakila database as shown below.
   
   
6. With the Tables node selected in the MySQL Metadata Explorer, click on the Convert Schema command to create schema named Sakila containing the Sakila tables within the SSMA project as shown below.
   
   
    
7. Right click on the Sakila schema above and choose the Synchronize with Database command to write the schema changes to your SQL Azure database and then click OK to confirm the synchronization of all objects. This process creates a SQL Server schema object within your database named Sakila and then all the object from your MySQL database go into that schema.
8. Select the Tables node for the Sakila database in the MySQL Metadata Explorer and then issue the Migrate Data command from the toolbar. Complete the connection dialog to your MySQL database and the connection dialog to the SQL Azure database to start the data transfer. Assuming all goes well, you can dismiss the Data Migration Report as shown below.
   
   

At this point, you now have all of the tables and their data loaded into your SQL Azure database contained in a schema named Sakila.

Validating the Results with the SQL Azure Database Manager

To verify the transfer of the data, you can use the Manage command from the Azure Portal and shown below. Just select the database and press the Manage command.

This will launch the SQL Azure Database Manager program in a new browser window with the Server, Database, and Login information prepopulated in the connection dialog. If you have other SQL Azure databases you want to connect to without having to go to the portal, you can always connect via the URL - https://manage-ch1.sql.azure.com/.

Once connected, you can expand the Tables node and select a table like sakila.film to view the structure of the table. You can click on the Data command in the toolbar to view and edit the table’s data as shown below.

The SQL Azure Database Manager will also allow you to write an test queries against your database by Database command and then selecting the New Query button in the ribbon.  To learn more about this tool, check out the MSDN topic – Getting Started with The Database Manager for SQL Azure.

Additional SQL Azure Resources

To learn more about SQL Azure, see the following resources.

• Microsoft SQL Azure Database Page
• SQL Azure MSDN Blog

SSMA automates conversion of most statement. There are a few features and syntax which SSMA is unable to migrate. In such situation, SSMA issues a migration error and for each error, SSMA provides estimated manual conversion time. I often asked how do we come up with the time.

Those manual estimation time was calculated based on the actual average time it takes by our developer team to fix the issue (exclude testing time). The manual estimation is intended to help you further quantify the complexity of the issue to help planning the database migration.

However, you should be aware of the assumption and limitation of the manual conversion time estimate:

1. The estimated manual conversion time was calculated based on the time it takes to resolve the issue using a specific approach. Often, there are more than one approach to resolve the issue. The actual hours to complete the migration and resolving the issue depends on the approach taken. For example when encountering Oracle User Defined Type (UDT), SSMA raised an error and the estimate was calculated based on the assumption that the UDT is converted to SQL Server TVP (as described in this article). However, you could also develop custom CLR type and convert the TVP to the CLR type -- in which case the actual conversion time will be vastly different.
2. Every migration error is assumed to be independent and the total estimated manual conversion time sums the estimate from individual errors. This may not be the case. You may have the same errors across multiple objects, in which once you resolve one error, you could copy and paste the solution to another object which would reduce the resolution time. Another example, you may have one underlying issue manifested in multiple errors. Consider the example in the screenshot above where SSMA is not able to convert INTERVAL data type. This results in the error for the function return type (line 6 on original Oracle source code) and expression to calculate the value (line 10 on the original Oracle source code). The two issues are dependent each other and the return type depends on converted expression.

In addition, the manual estimate hours depends on the skills of resources performing the migration. In order to resolve the issue, you will need to understand the original Oracle source and understand how best to redesign the statement in SQL Server. Thus, you need resource with knowledge of both Oracle and SQL Server. If you do not have resource with knowledge in both technologies, then you need to have separate resources (Oracle DBA and SQL Server developer) collaborating to resolve the issue. In this case, you need to factor the number of resources to your project planning.

I often find customers use the estimated manual conversion time as a comparative number to rank complexity between one schema/database to another.

The manual conversion time can still be useful for rough order of magnitude (ROM) estimation, but for more accurate project costing and time estimate, it is best to have the actual person(s) performing the migration to review the error list carefully, consider the consider the design approach and skill level, then refine the estimate accordingly.

Automating Database Migration to SQL Server 2012

The new version of SSMA - SSMA 5.2 provides the following major enhancements:

• Support conversion of Oracle %ROWTYPE parameters with NULL default
• Support conversion of Sybase’s Rollback Trigger
• Better user credential security to support Microsoft Access Linked Tables

Download SQL Server Migration Assistant (SSMA) v.5.2

Launch the download of the SSMA for Oracle.

Launch the download of the SSMA for Sybase.

Launch the download of the SSMA for MySQL.

Launch the download of the SSMA for Access.

SSMA simplifies database migration process from Oracle/Sybase/MySQL and Microsoft Access to SQL Server and SQL Azure. SSMA automates all aspects of migration including migration assessment analysis, schema and SQL statement conversion, data migration as well as migration testing to reduce cost and reduce risk of your database migration project. 

The new version of SSMA - SSMA 5.3 provides the following major enhancements:

• Support of Migration to MS SQL Server 2014.
• Improved conversion mechanism when migrating to Azure.
• New features in the Migration GUI.
• No requirement to get a License key to start using SSMA.

Download SQL Server Migration Assistant (SSMA) v.5.3 :

Launch the download of the SSMA for Oracle.

Launch the download of the SSMA for Sybase.

Launch the download of the SSMA for MySQL.

Launch the download of the SSMA for Access.

The SSMA product team is available to answer your questions and provide limited technical support. Contact the team at ssmahelp@microsoft.com

SSMA simplifies database migration process from Oracle/Sybase/MySQL and Microsoft Access to SQL Server and SQL Azure. SSMA automates all aspects of migration including migration assessment analysis, schema and SQL statement conversion, data migration as well as migration testing to reduce cost and reduce risk of your database migration project. 

The new version of  SSMA, Version  6.0 provides the following major enhancements:

• Materialized View support for Oracle

• Memory Optimized tables for Oracle
• Improved Azure SQL DB code conversion
• Extension pack functionality moved to schema to support Azure SQL DB
• Performance improvements tested for databases with over 10k objects
• UI improvements for dealing with large number of objects
• Highlighting of “well known” LOB schemas (so they can be ignored in conversion)
• Conversion speed improvements
• Show object counts in UI
• Report size reduction by more than 25%
• Improved error messages for unparsed constructs.

 Download SQL Server Migration Assistant (SSMA) v.6.0

SSMA for Access:  http://www.microsoft.com/en-us/download/details.aspx?id=43690

SSMA for MySQL: http://www.microsoft.com/en-us/download/details.aspx?id=43688

SSMA for Oracle:  http://www.microsoft.com/en-us/download/details.aspx?id=43689

SSMA for Sybase: http://www.microsoft.com/en-us/download/details.aspx?id=43691

On the closing note , Yes ! We've heard several of your valuable feedbacks / inputs. Thank you... and we're rolling out with the SSMA for DB2 very soon. Watch out this space for more information.

The SSMA product team is available to answer your questions and provide technical support related to SSMA. Contact the team at ssmahelp@microsoft.com

The %ROWTYPE attribute in Oracle defines the particular record type of a row in a table.   A common usage of %ROWTYPE attribute is to have variables declared as ROWTYPE of a table to transfer data in and out of a procedure or function.  An IN ROWTYPE parameter of a function or procedure can be set with a default value.  Often, the IN ROWTYPE parameter is defaulted to NULL.  For example,

PROCEDURE proc_foo_rowtype( 
 row_a employees%ROWTYPE DEFAULT NULL ) 
 IS 
BEGIN 
 DBMS_OUTPUT.PUT_LINE('ID = ' || NVL(TO_CHAR(row_a.employeeID), 'NULL')); 
 DBMS_OUTPUT.PUT_LINE('NAME = ' || NVL(TO_CHAR(row_a.firstName), 'NULL')); 
END proc_foo_rowtype; 
 

PROCEDURE dbo.PROC_FOO_ROWTYPE 
 @row_a$EMPLOYEEID float(53) = NULL, 
 @row_a$FIRSTNAME nvarchar(max) = NULL 
AS 
BEGIN 
 PRINT 'ID = ' + isnull(CAST(@row_a$EMPLOYEEID AS varchar(max)), 'NULL') 
 PRINT 'NAME = ' + isnull(CAST(@row_a$FIRSTNAME AS varchar(max)), 'NULL') 
END 

Now, let’s have a little fun by having a ROWTYPE parameter in a nested procedure.  Here’s an example:

PROCEDURE PROC_FOO_OUTER 
IS 
empRow employees%ROWTYPE; 

 procedure proc_foo_inner( 
 row_a IN employees%ROWTYPE default null) 
 IS 
 
 BEGIN 
 DBMS_OUTPUT.PUT_LINE(‘First name = ' || NVL(TO_CHAR(row_a.FirstName), 'NULL')); 
 DBMS_OUTPUT.PUT_LINE(‘Last Name = ' || NVL(TO_CHAR(row_a.LastName), 'NULL')); 
 END proc_foo_inner; 

BEGIN 
 empRow.LastName := 'Smith'; 
 empRow.FirstName := 'John'; 
 proc_foo_inner(); 
 proc_foo_inner(empRow); 

END PROC_FOO_OUTER;                          

This example is quite straightforward.    Let’s assume there is an employee table with FirstName and LastName columns of nvarchar2(20) and nvarchar2(40) respectively.   The executing this procedure in Oracle would the following result:

 Now, let’s convert this procedure to SQL Server 2012 using SSMA for Oracle.  We will set the following settings in SSMA as such

• ·         local modules conversion is set to Inline
• ·         convert record as a list of separated variables set to Yes

The first setting is to convert the inner procedure into nested block Begin..End.  The second setting will create separate variables for FirstName and LastName.

Below is the result of the conversion.  There are two nested blocks corresponding to the respective inner procedures.  Each nested block contains its own variables for LastName and FirstName.   For the block representing proc_foo_inner(), the two variables are set to NULL.  For the block representing proc_foo_inner(empRow), the variables are set to the proper empRow values.

PROCEDURE dbo.PROC_FOO_OUTER 
AS 
 BEGIN 
 
 DECLARE 
 @empRow$LASTNAME nvarchar(40), 
 @empRow$FIRSTNAME nvarchar(20), 
 
 
 SET @empRow$LASTNAME = 'Smith' 
 SET @empRow$FIRSTNAME = 'John' 
 

 BEGIN /* proc_foo_inner() */ 
  DECLARE 
  @proc_foo_inner$row_a$LASTNAME nvarchar(max) 
 
  DECLARE 
   @proc_foo_inner$row_a$FIRSTNAME nvarchar(max) 
 
   SET @proc_foo_inner$row_a$LASTNAME = NULL 
   SET @proc_foo_inner$row_a$FIRSTNAME = NULL 
 
   BEGIN 
    PRINT 'Last name = ' + isnull(CAST(@proc_foo_inner$row_a$FIRSTNAME AS varchar(max)), 'NULL') 
    PRINT 'First Name = ' + isnull(CAST(@proc_foo_inner$row_a$LASTNAME AS varchar(max)), 'NULL') 
   END 
 END 
 

BEGIN /* proc_foo_inner(empRow) */ 
 DECLARE 
 @proc_foo_inner$row_a$LASTNAME$2 nvarchar(max) 
 
 DECLARE 
 @proc_foo_inner$row_a$FIRSTNAME$2 nvarchar(max) 

 
  SET @proc_foo_inner$row_a$LASTNAME$2 = @empRow$LASTNAME 
  SET @proc_foo_inner$row_a$FIRSTNAME$2 = @empRow$FIRSTNAME 
 
  BEGIN 
   PRINT 'Last name = ' + isnull(CAST(@proc_foo_inner$row_a$FIRSTNAME$2 AS varchar(max)), 'NULL') 
   PRINT 'First Name = ' + isnull(CAST(@proc_foo_inner$row_a$LASTNAME$2 AS varchar(max)), 'NULL') 
  END 
 END 
END 

Unfortunately we never had Sybase ASA on our plans for SSMA. The plan is still intact and we still support migration from Sybase ASE 11.9 onwards with the latest version of SSMA for Sybase http://www.microsoft.com/en-us/download/details.aspx?id=28765

 Even if we can’t use SSMA we still have a way to migrate in case only schema and data needs to be migrated (which is mostly the case). You can use a Linked Server to great advantage. The syntax between Sybase and MS SQL Server don’t differ much as they share the same DNA. Below are the providers that you can use to setup a linked server from SQL Server to Sybase ASA and then use queries to pull data and insert into the local database.  I am providing some information below to give you pointers for the same.   

a)      Have to install the required provider/driver on the SQL Server machine.

 Sybase ASA can be connected in following ways

 OLE DB Providers

 You need an OLE DB provider for each type of data source you wish to access. Each provider is a dynamic-link library. There are two OLE DB providers you can use to access Sybase IQ:  Sybase ASA OLE DB provider The Adaptive Server Anywhere OLE DB provider provides access to Sybase IQ as an OLE DB data source without the need for ODBC components. The short name for this provider is ASAProv. 

When the ASAProv provider is installed, it registers itself. This registration process includes making registry entries in the COM section of the registry, so that ADO can locate the DLL when the ASAProv provider is called. If you change the location of your DLL, you must reregister it. 

If you use the Adaptive Server Anywhere OLE DB provider, ODBC is not required in your deployment. 

ODBC Driver

Microsoft OLE DB provider for ODBC Microsoft provides an OLE DB provider with a short name of MSDASQL.

The MSDASQL provider makes ODBC data sources appear as OLE DB data sources. It requires the Sybase IQ ODBC driver.

 b)      Create a Linked Server and then query the same.

 This link species the steps and some common errors while setting the Sybase ASA Linked Server

 Steps :  http://sql-articles.com/articles/dba/creating-linked-server-to-sybase-from-sql-server/  (These are for ASE but are the same for ASA except that you have to choose a different provider/driver)

 Connection Issues : http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/fe29f12d-67b0-40a8-a41b-1767853a0185

Angshuman Nayak 

SSMA simplifies database migration process from Oracle/Sybase/MySQL and Microsoft Access to SQL Server and SQL Azure. SSMA automates all aspects of migration including migration assessment analysis, schema and SQL statement conversion, data migration as well as migration testing to reduce cost and reduce risk of your database migration project. 

The new version of SSMA – SSMA 5.3 provides the following major enhancements:

• Support of Migration to MS SQL Server 2014.
• Improved conversion mechanism when migrating to Azure.
• New features in the Migration GUI.
• No requirement to get a License key to start using SSMA.

Download SQL Server Migration Assistant (SSMA) v.5.3 :

Launch the download of the SSMA for Oracle.

Launch the download of the SSMA for Sybase.

Launch the download of the SSMA for MySQL.

Launch the download of the SSMA for Access.

The SSMA product team is available to answer your questions and provide limited technical support. Contact the team at ssmahelp@microsoft.com

SSMA simplifies database migration process from Oracle/Sybase/MySQL and Microsoft Access to SQL Server and SQL Azure. SSMA automates all aspects of migration including migration assessment analysis, schema and SQL statement conversion, data migration as well as migration testing to reduce cost and reduce risk of your database migration project. 

The new version of  SSMA, Version  6.0 provides the following major enhancements:

• Materialized View support for Oracle

• Memory Optimized tables for Oracle
• Improved Azure SQL DB code conversion
• Extension pack functionality moved to schema to support Azure SQL DB
• Performance improvements tested for databases with over 10k objects
• UI improvements for dealing with large number of objects
• Highlighting of “well known” LOB schemas (so they can be ignored in conversion)
• Conversion speed improvements
• Show object counts in UI
• Report size reduction by more than 25%
• Improved error messages for unparsed constructs.

 Download SQL Server Migration Assistant (SSMA) v.6.0

SSMA for Access:  http://www.microsoft.com/en-us/download/details.aspx?id=43690

SSMA for MySQL: http://www.microsoft.com/en-us/download/details.aspx?id=43688

SSMA for Oracle:  http://www.microsoft.com/en-us/download/details.aspx?id=43689

SSMA for Sybase: http://www.microsoft.com/en-us/download/details.aspx?id=43691

On the closing note , Yes ! We’ve heard several of your valuable feedbacks / inputs. Thank you… and we’re rolling out with the SSMA for DB2 very soon. Watch out this space for more information.

The SSMA product team is available to answer your questions and provide technical support related to SSMA. Contact the team at ssmahelp@microsoft.com

We are happy to announce the release of the most anticipated DB2 for SSMA. You can download the same from the link : http://www.microsoft.com/en-us/download/details.aspx?id=45296

We look forward to hear back from your end on the feedback related to the utility.

Microsoft has released an update to SSMA 6.0 for Oracle, DB2, Sybase ASE, MySQL and Access. SSMA simplifies the database migration process by automating all aspects of migration including migration assessment analysis, schema conversion, SQL statement conversion and data migration. SSMA also includes migration testing to reduce the cost and risk of database migrations.

Version 6.01 of SSMA includes the following enhancements:

• SSMA for Oracle.
• Added support for clustered indexes.
• Fixed performance with querying Oracle schema. 
• Fixed issues when setting up a connection to Azure from the console.
• SSMA for DB2.
• Fixed support for DB2 v9 zOS.
• Added support for more standard functions.
• Fixed issues when setting up a connection to Azure from the console.
• SSMA for MySQL.
• Updated driver support now includes newer versions of the ODBC driver greater than v5.1.
• SSMA for Access.
• Fixed handing of fields with a GUID datatype and a default function.
• Fixed issues importing records into an Azure SQL Database.
• New command in the menu to view the SSMA log file.
• This provides an easy way to get to the log file to help diagnose any issues that come up when using SSMA.

 Download SQL Server Migration Assistant (SSMA) v6.0.1

• SSMA 6.0.1 for Access:    http://www.microsoft.com/en-us/download/details.aspx?id=51214
• SSMA 6.0.1 for DB2:        http://www.microsoft.com/en-us/download/details.aspx?id=51216
• SSMA 6.0.1 for MySql:     http://www.microsoft.com/en-us/download/details.aspx?id=51218
• SSMA 6.0.1 for Oracle:    http://www.microsoft.com/en-us/download/details.aspx?id=51217
• SSMA 6.0.1 for Sybase:   http://www.microsoft.com/en-us/download/details.aspx?id=51215

For help and support using SSMA, please visit https://aka.ms/ssmahelp.

Microsoft has released a preview release of SQL Server Migration Assistant (SSMA) that supports migrating databases from Oracle, Sybase ASE, DB2, MySQL and Access to SQL Server 2016 Release Candidate 0. In this release, the following features have been added:

SSMA 6.1 Preview, all platforms:

• Support for SQL Server 2016 Release Candidate 0
• Support for running SSMA on Windows 10

SSMA 6.1 Preview for Oracle now supports Row Level Security including the following:

• Support loading of security policies from the Oracle Virtual Private Database (VPD)
• The Oracle VPD is represented in the SSMA UI with policy objects underneath
• The associated VPD attributes and predicate function are represented in the SSMA UI
• Support loading of security policies from SQL Server 2016
• SQL Server Security policies are represented in the SSMA UI and organized in categories
• The SQL Server Security policies associated attributes are represented in the SSMA UI
• Support for conversion of Oracle security policies to SQL Server security policies

SSMA 6.1 Preview for Oracle now supports In-Memory Tables and Column Store including the following:

• Support loading of in-memory tables shown in UI with ‘M’ icon
• Support conversion to selected SQL Server mapping:
  • Row-store table with Non-clustered Columnstore Index
  • In-memory OLTP tables
  • Clustered Columnstore Index-organized table
  • Row-store table without Columnstore Indexes

To download the SSMA 6.1 Preview release see the following links:

• Sybase ASE: http://www.microsoft.com/en-us/download/details.aspx?id=51472
• Oracle: https://www.microsoft.com/en-us/download/details.aspx?id=51471
• Access: http://www.microsoft.com/en-us/download/details.aspx?id=51473
• MySql: http://www.microsoft.com/en-us/download/details.aspx?id=51470
• DB2: http://www.microsoft.com/en-us/download/details.aspx?id=51469

Microsoft has released SQL Server Migration Assistant (SSMA) 7.0 which now supports migrating to SQL Server 2016 and has expanded support for Azure SQL Database.

All platforms:

• Support for SQL Server 2016
• Extended support for Azure SQL Database
• Support for running SSMA on Windows 10
• Fixed “save project” and “open project” commands for SSMA Console
• Fixed “securepassword” command for SSMA Console
• Fixed counting of objects for initial loading
• Removed installer check for .Net 2.0

Oracle

• Add conversion for in-memory tables and column store indexes to leverage In-Memory OLTP for SQL Server 2016 and In-Memory Columnstore for SQL Server 2016 and Azure SQL Database
• Added conversion of Oracle flashback archive tables to leverage SQL Server Temporal tables in SQL Server 2016 and Azure SQL Database
• Added conversion of Oracle VPD Policy converting to leverage Row Level Security in SQL Server 2016 and Azure SQL Database
• Decreased time of initial loading for Oracle
• Improved parser and resolver
• Updated Extension Pack dependency from .Net 3.5 to .Net 4.0

Db2

• Added conversion of DB2 in-memory tables and column store indexes to leverage In-memory OLTP for SQL Server 2016 and In-Memory Columnstore for SQL Server 2016 and Azure SQL Database
• Added conversion of DB2 access controls to leverage SQL Server Row Level Security for SQL Server 2016 and Azure SQL Database
• Added conversion of DB2 system-versioned tables to leverage SQL Server Temporal tables for SQL Server 2016 and Azure SQL Database
• Improved DB2 parser and resolver
• Removed unnecessary *.dll from Db2 installer

MySQL

• Improved parser and resolver
• Updated Extension Pack dependency from .Net 3.5 to .Net 4.0
• Fixed default BigInt typemapping for MySQL
• Fixed MsSql objects loading

MS Access

• Fixed tables data loading for UI tabs for Access
• Added support for disabling the loading of linked tables

Sybase ASE

• Updated Extension Pack dependency from .Net 3.5 to .Net 4.0

To download the SSMA 7.0 release see the following links:

• SSMA for MS Access
• SSMA for DB2
• SSMA for MySQL
• SSMA for Oracle
• SSMA for Sybase ASE

SQL vNext CTP1 on Windows and Linux is now a supported target platform for migration. This feature is in technical preview and will allow schema and data movement to the target SQL server.
Review the announcement here.

Overview

Microsoft SQL Server Migration Assistant (SSMA) v7.3  for Oracle, MySQL, SAP ASE (formerly SAP Sybase ASE), DB2 and Access lets users convert database schema to Microsoft SQL Server schema, upload the schema, and migrate data to the target SQL Server (see below for supported versions).

What is new in v7.3?

• Improved quality and conversion metric with targeted fixes based on customer feedback.
• SSMA extensibility framework exposed via
  • Export functionality to a SQL Server Data Tools (SSDT) project
    • You can now export schema scripts from SSMA as an SSDT project and use that to make additional schema changes and deploy your database.
      
  • Libraries that can be consumed by SSMA for performing custom conversions
    • You can now construct code that can handle custom syntax conversions and conversions that weren’t previously handled by SSMA
      • Instructions on how to construct a custom converter can be found here.
      • Sample project for conversion can be downloaded here.

Downloads

• SSMA for Access
• SSMA for DB2
• SSMA for MySQL
• SSMA for Oracle
• SSMA for SAP ASE (formerly SAP Sybase ASE)

Resources

• SQL Server Migration Assistant: How to assess and migrate database(s) from non Microsoft data platforms to SQL Server
• Extending SQL Server Migration Assistant’s conversion capabilities

NOTE: Please visit https://blogs.msdn.microsoft.com/datamigration/  for latest post on tools that support upgrades and migrations.