Oracle to MS SQL Migration Price Prediction

Question

We want to calculate approximate man-month for migrating from Oracle 11g to MS SQL 2012. I have read the steps of migration. Are there any white papers about migration issues, difficulties. We are also using Hibernate in ORM layer. How can we predict migration
cost according to table size or relation count, HQL or native SQL query number or other criteria? 

Answer 1

Hi ozgurba,
According to your description, you could download and use the free tool
Microsoft SQL Server Migration Assistant v6.0 for Oracle(SSMA) to migrate Oracle database to SQL Server 2012. About migration issues using SSMA, please pay attention to the points below. For more information about migration issues, please download and check
this
white paper.
1.The account that is used to connect to the Oracle database must have at least CONNECT permissions. This enables SSMA to obtain metadata from schemas owned by the connecting user. To obtain metadata for objects in other schemas and then convert objects
in those schemas, the account must have the following permissions: CREATE ANY PROCEDURE, EXECUTE ANY PROCEDURE, SELECT ANY TABLE, SELECT ANY SEQUENCE, CREATE ANY TYPE, CREATE ANY TRIGGER, SELECT ANY DICTIONARY.
2.The account that is used to connect to SQL Server requires different permissions depending on the actions that the account performs as the following:
To convert Oracle objects to Transact-SQL syntax, to update metadata from SQL Server, or to save converted syntax to scripts, the account must have permission to log on to the instance of SQL Server.
To load database objects into SQL Server, the account must be a member of the sysadmin server role. This is required to install CLR assemblies.
To migrate data to SQL Server, the account must be a member of the sysadmin server role. This is required to run the SQL Server Agent data migration packages.
To run the code that is generated by SSMA, the account must have Execute permissions for all user-defined functions in the ssma_oracle schema of the target database. These functions provide equivalent functionality of Oracle system functions, and are used
by converted objects.
If the account that is used to connect to SQL Server is to perform all migration tasks, the account must be a member of the sysadmin server role.
If the engine being used is Server Side Data Migration Engine, then, before you can migrate data, you must install the SSMA for Oracle Extension Pack and the Oracle providers on the computer that is running SSMA. The SQL Server Agent service must also be
running. And when SQL Express edition is used as the target database, only client side data migration is allowed and server side data migration is not supported.
3.Not all Oracle database objects have direct equivalents in SQL Server. In many cases, SSMA creates additional objects to provide the proper emulation. For example, an Oracle view could be converted to an SQL Server view. But the only exception is the materialized
view, which becomes an ordinary table.
4.Oracle DML triggers are converted to SQL Server triggers, but because the trigger functionality is different, the number of triggers and their types can be changed. Most common Oracle trigger is a row-level trigger (FOR EACH ROW). SQL Server supports only
statement-level triggers. In a row-level trigger, Oracle uses an :OLD alias to refer to column values that existed before the statement executes. SQL Server uses two pseudotables, inserted and deleted. If you are converting tables with UPDATE triggers, we
recommend setting the Generate ROWID column option to Yes or Add ROWID column for tables with triggers in the SSMA project settings. To emulate row-level triggers, SSMA processes each row in a cursor loop.
5.Some Oracle object categories, such as packages, do not have direct SQL Server equivalents. SSMA converts each packaged procedure or function into separate target subroutines and applies rules for stand-alone procedures or functions.
6.Unlike Oracle, Microsoft SQL Server 2012 supports neither records nor collections. When you migrate from Oracle to SQL Server 2012, therefore, you must apply substantial transformations to the PL/SQL code.
7.SQL Server 2012 does not support autonomous transactions. The only way to isolate a Transact-SQL block from a transaction context is to open a new connection. To convert a procedure, function, or trigger with an AUTONOMOUS_TRANSACTION flag, you split it
into two objects. The first object is a stored procedure containing the body of the converted object. The second object is a wrapper that opens a new connection where it invokes the first object.
In addition, regarding migration price prediction, please ask for the help from relevant department of your company, since this forum is related to the technical support for SQL Server.
Regards,
Michelle Li