Migrating Non-Oracle Databases to

Oracle
 Craig Silveira
Principal Sales Consultant
North American Strategic Accounts

Craig.silveira@oracle.com
212 508 7801
Customers who migrated
y UBS PaineWebber – looking to move off Sybase
altogether due to concerns about company. POC
showed our capabilities and they are now migrating
other applications.
y Bank of America Credit Risk – looking to perform
consolidation and replatforming of db systems.
POC showed 2X perf gain with no special tuning
and on smaller hardware.
y Bank of America Trade Flow Management – wanted
to move off Sybase due to strategic direction.
Performed migration themselves. Performance
better. Now migrating more apps
y MetLife – consolidated a DB2 MF and Sybase db
into Oracle. Went live and experiencing better than
ever expected performance.
Database Architecture Comparison

Database
Instance System Server Master
Tablespace Database
Tablespace Database
Tablespace Database
Tablespace Database
RDBMS Implementation Similarities
y Similar Schema Objects (tables, views)
y Similar Data types
y Referential Integrity
y Check Constraints / Rules
y Transaction Support
y Triggers and Stored Sub Programs
y SQL Access to System Catalogs
Oracle Migration Workbench
Oracle Migration Workbench
y Wizard-driven tool
y Migrates from:
– MS SQL Server 6.5 and 7.0, 2000
– Informix Dynamic Server 7.3, 9.1,9.2,9.3,9.4
– Sybase Adaptive Server 11, 12
– MS Access 2.0, 95, 97
– MySQL on NT and Linux
– IBM UDB v6, 7.1 , 7.2 and DB2/400
y Supports database (schema & data)
y Supports triggers & stored procedures
Features
y Visual representation of the source database
and its Oracle equivalent
y Migration analysis
– Summary report
– Contextual log messages
Features
y Multiple databases are consolidated into one
database
y Automatically resolve conflicts
– Table name collisions
– Oracle reserved words
Features
y Data migration
– Default mappings to CLOBs/BLOBs
– Single table data migration
– Offline data loading
y SQL*Loader
y BCP
Schema Conversion
Sql Server Oracle
TEXT(n) LONG or CLOB
IMAGE(n) LONG RAW, BLOB or BFILE
BINARY(n) RAW(n)
VARBINARY(n) VARCHAR2(n)
DATETIME DATE
SMALLDATETIME DATE(With Check Constraint)
MONEY NUMBER(19,4)
SMALLMONEY NUMBER(10,4)
TIMESTAMP NUMBER
SYSNAME VARCHAR(30) NOT NULL
Features
y Parser
– Single-object parse
– Parse options
– Color-coded editor
– Temporary tables
 Conversion Architecture

ODBC Connection Oracle

Oracle Workbench
Repository

Schema
Sql Data Oracle
Server

Flat File Oracle

Source DB
Utilities Data SQL*Loader
Migration Process

y Capture
– Load the Source Model
– Create the Oracle Model
y Customize
– Modify objects to produce the desired content and
structure of your new Oracle database
y Migrate
– Migrate to the Oracle database
Capture
y Load the Source Model
– ODBC/JDBC driver used to extract schema
information
– Schema information loaded into the Workbench
Repository
– No data transferred
y Create the Oracle Model
– Data type mappings
– Parser
Customize
y Source Model customization
– Modify data type mappings
– Delete objects
– Edit text (stored procedures, triggers & views)
– Edit parse options
Customize
y Oracle Model customization
– Delete/rename objects
– Edit creation options
y Tablespaces
y Users
y Tables and indexes
– Edit text (stored procedures, triggers & views)
Migrate
y Creation of the users and their tables
y Data migration
– Through the Migration Workbench
y JDBC/ODBC
– Offline data loading
y BCP/SQL*Loader
y Creation of remaining schema objects
Database Migration
y Database Migration has the following
activities
– Schema & Data Conversion
– Application Procedure Conversion
– Handling special cases which require manual
intervention
Technical Database Migration Issues
y Data Access - Differences
– SQL Differences
– MS and Oracle have some differences in SQL
syntax.
– Client side will need re-coding if an issue
y Client-Side Applications
– Most MS Applications use ODBC so limited
changes should be required unless
passthrough has been used.
Technical Database Migration Issues
y Utilities - Differences
– Bulk Loading
y Sql Server uses BCP which serves as both a
bulk loader and a restoration tool. An API can be
called from C programs
y Oracle has SQL*Loader serving as bulk loader.
- Use Import/Export for data
backup/restoration.
- For bulk loading from a C program, use array
feature of precompilers or OCI.
- SQL*Loader API in Oracle8i and Array
Interface.
 Stored Procedure Migration

y Issues
y Manual Tasks
Sub Programs Migration Issues
y Temporary Tables
y T-SQL Issues
– Resultsets from Stored Sub Programs
– Dynamic T-SQL
– Error Handling
y SQL Issues
– DDL/DML
– Datetime Data type required to millisecond
– Sybase specific functions
 Stored Sub Program Migration Issues

y Temporary Tables
– Sql Server uses temporary tables for:
y Query simplification and Result accumulation
– Oracle does not need temporary tables in most
cases
y The Oracle optimizer can deal with complex
queries, so a re-write can avoid a temporary
table.
y Oracle8i provides support for temporary tables
Stored Sub Program Migration Issues

y Resultsets from stored sub programs

– Sql Server automatically puts resultsets in
stream
y Returns stream of data and Multiple resultsets
are possible
– Oracle provides cursor variables
y Client receives cv which is a handle to server-
side memory resident cursor
y Can pass cv to other clients or servers
Stored Sub Program Migration Issues
y Dynamic T-SQL
– Dynamic PL/SQL is supported by Oracle
– T-SQL Dynamic SQL calls converted to
PL/SQL Dynamic SQL calls
 Stored Sub Program Migration Issues
y Error handling:
– propagates errors back to client via global variable:
y All errors are passed back to the client
y @@Error needs to be checked regularly
– Oracle has exception handling in PL/SQL to deal with
errors automatically:
y SQL statements are embedded in a PL/SQL block with
optional EXCEPTION section
y Use EXCEPTION to trap exactly the error conditions you
wish within Throw/Catch exception model
y Only un-handled exceptions propagate to higher levels
Stored Sub Programs Migration
Issues
y SQL Issues
– DDL/DML
– Datetime Datatype required to millisecond
– MS Sybase-specific functions
Stored Sub Program Migration Issues
y DDL Statements
– Not allowed in PL/SQL
– Removed and converted by the workbench
– Run outside of PL/SQL stored sub program
Stored Sub Program Migration Issues
y DML Statements
– Update / Delete from
y Resolved by Workbench
– Select List Subqueries
y Partly resolved by Workbench
y Recode on complex cases
Stored Sub Program Migration Issues
y Datetime Data type required to millisecond
– Is it really required?
– Can be simulated by date columns together
with a number column and a sequence
– A trigger could fill the milliseconds field with the
sequence values
Stored Sub Program Migration Issues
y Specific Functions
– Functions such as reverse, case, and more can
partly be converted to their counterparts in
Oracle
– Other functions could be coded in PL/SQL,
Java (8i) or via C Callouts
 Reference Material
y Online Help
– Additional reference material in the Appendix
y Oracle Technology Network
– http://technet.oracle.com/tech/migration/workbench
– Reference Guides and FAQ
– Quick Tour and Online Demo
y Migration Workbench Helpdesk
– infomwb_ww@oracle.com
 Converting MAC

AGENDA

y Database conversion
y Stored Procedure conversion
– Phase I
– Phase II
– Phase III
– Phase IV
y Perl conversion
 PHASE I - Using conversion utility

Stored Procedure conversion

103 total stored procedures

y 16 stored procedures were modified by tool to not include

creation of temporary table. The Oracle ddl syntax was moved
to another file.
y 9 stored procedures/functions needed manual conversion
– 2 stored procedures need to have the Sybase source modified
because of a SELECT FOR READ ONLY statement or a
UPDATE FROM statement
– 9 stored procedures were looked over due to the fact that Oracle
currently does not support milliseconds
PHASE II - Compilation

y Errors encountered during this phase include:

– object does not exist: if a stored procedure references a

table or stored procedure that doesn’t exist, then you
get this error
y resolve by making sure you create the referenced
object
– In MAC, a Sybase function, PATINDEX is used which
doesn’t exist in Oracle
y resolved by creating a function with the same name
that uses Oracle built in functions to achieve same
results
y only affected one stored procedure
PHASE II - Compilation

y Errors encountered during this phase include:

– In MAC, a Sybase function, RAND is used which

doesn’t exist in Oracle
y resolved by replacing with Oracle package,
DBMS_RANDOM. This package has functions
that perform same operations as RAND
y only affected one stored procedure
 PHASE III - making changes due to Perl
requirements

y 56 stored procedures/functions needed to be

modified to exclude references to REF
CURSORS
– change was to comment out code and remove
declarations
y same 56 stored procedures were modified to
include a INSERT INTO
GLOBAL_RESULTSET table
– resulted in addition of a loop with the insert
statement
NOTE: OraPerl does not support REF CURSORS at this time. If this
was C/C++, VB or PB, this step would not be necessary
 PHASE IV - Execution/runtime testing

Errors encountered during runtime:

y The columns usr_uunm_i, usr_uunm_chng_i and

usr_grp_mmbrp_i are defined as CHAR in Sybase.
– When migrated to Oracle, they were created as CHARs
in Oracle.
– This caused problems because of the difference
between Oracle CHAR and Sybase CHAR.
y During the conversion process, it would have been
easy to change the CHAR column definition to
VARCHAR2
y We resolved by changing the column definition
afterwards with our ALTER TABLE statement.
PHASE IV - Execution/runtime testing

Errors encountered during runtime:

y Return codes in Sybase differ from those in
Oracle
– When no data is returned from a query, Sybase
returns a 0. Oracle returns a 100.
y resolution was easy, when we found where
this happened, we just added an IF statement
that changed the code from 100 to 0.
y Only affected 3 stored procedures
y Sybase and Oracle handle queries that
assign values to a variable using a SELECT
statement differently
 PHASE IV - Execution/runtime testing

Errors encountered during runtime:

– In Sybase, if more than one record is returned, it
assigns the last value to the variable
– In Oracle, you get an error
y To resolve, you need to know what is trying to be
accomplished
- In one case, the SELECT was only trying to see
if a record existed. In this case, Oracle can just
append an additional condition : WHERE
rownum =1
- In another case, Sybase was actually looking for
the last value returned. In this case, we
replaced the query with a cursor that retrieved all
of the records then pulled out the appropriate
data
y only affect two stored procedures
Perl conversion

y Perl needed to be modified in the following ways:

– add subroutine to set Oracle environment to user_subs.pl

y ORACLE_HOME
y ORACLE_USERID
y TWO_TASK
y NLS_DATE_FORMAT
– use (Oracle) DBI;
– change way stored procedure/function is called:
y SybPerl : $sql = exec proc_name();
y OraPerl: $sql = “begin
proc_name();
end;”
Perl conversion

y Perl needed to be modified in the following ways

cont :

– change way stored procedure/function is called:

y SybPerl : $sql = exec proc_name();
y OraPerl: $sql = “ declare x number;
begin
x := proc_name();
end;”
Perl conversion

y Perl needed to be modified in the following ways

cont :

– OraPerl and SybPerl retrieve data from stored procedures

very differently
– Oracle generally uses REF CURSORS to return result sets
to a calling application
– OraPerl currently does not have proven REF CURSOR
support

Therefore, a workaround was employed.

Perl conversion

y Perl needed to be modified in the following ways cont :

The workaround is as follows:

– Stored procedures that return results sets were modified to insert
the results into temporary table
– The calling perl script was then modified to select the data from
the temporary table and display the data in the browser

– Functions returned a status. This was checked just to see if the

operation was successful or not. We took this status and
inserted into another temporary table that was queried to see if
the function executed successfully or not
Perl conversion

y 37 total perl scripts

ONLY 28 needed to be modified
y 20 were modified to include &set_oracle_env
y 17 were modified to include correct oracle syntax for
executing a stored procedure or function
y 20 were modified to include the ‘insert into
global_status’ table
y 7 were modified to have select from global_resultset
table
Presentation Map

Purpose of Pilot
Application X Pilot - Oracle
Application X Pilot - IBM
Application Y Pilot - Oracle
Application Y Pilot - IBM
Application Y Pilot - Benchmark Results
 Application X Overview

y Application X is a front-office system for trading

in fixed-income securities
– Since Application X is a large and complex
application, it was not possible to migrate it in its
entirety within the limited scope of this project
– A subset of stored procedures and tables was
targeted for conversion/migration
y Focus was the set of stored procedures which
creates a repo ticket in Application X
y The migration effort included
– 95 tables, their associated indexes, rules, and
defaults
– 89 stored procedures and 5 triggers
– 1 Open Server Registered Procedure call
 Application X - Migration Effort by
Oracle
y Oracle uses a proprietary migration toolkit which:
– Reads the Sybase database system tables to extract
schema information
– The extracted schema information is stored in a
series of flat files
– These flat files are loaded in an Oracle staging
database
– A set of scripts is run against the staging database to
generate the DDL to recreate the tables in Oracle
– A set of scripts is generated to bcp data out of
Sybase
– An additional set of scripts is generated to load the
data into Oracle using Oracle’s SQL*Loader utility
– The tool is capable of extracting rules,
defaults, and constraints but not views;
views require manual conversion
Application X - Migration Effort by
Oracle
y Oracle’s toolkit converts almost all datatypes with the
exception of:
– MONEY is converted to NUMBER
– Oracle’s date format is DD-MON-YY
y Can display different date formats using
TO_DATE() or TO_CHAR()
y Can configure the default date display format in
the init.ora file via the nls_date_format =
“MM/DD/YYYY” parameter
– Sybase’s DATETIME and SMALLDATETIME include
milliseconds, Oracle’s DATE datatype does not
y Oracle8i will apparently store up to nanoseconds
y If milliseconds are needed currently, another
column must be manually added to the table and
“mask” when loading data via SQL*Loader
 Items Requiring Resolution During
Migration

y Oracle stored procedures only allow

“select … into”
– All “select” statements are converted to
referential cursors
Items Requiring Resolution During
Migration
y Rules and Defaults
– Oracle does not support rules, and instead follows
the ANSI standard for Declarative Constraints
y Rules are converted to declarative constraints
y Defaults are converted to declarative defaults
– An interesting case came up that Oracle was able to
handle seamlessly...
y Several rules in the Application X application
were created and subsequently renamed
y Thus, the object names in Application
X..sysobjects differed from the text stored in
Application X..syscomments
y Since Oracle converts rules to constraints, the
conversion tool parses out the “variable operator
constant” expression in syscomments and
ignores the rule name
Items Requiring Resolution During
Migration
y Rules and Defaults, cont’d
– An interesting case came up that Oracle was able to
handle seamlessly…, cont’d
y Since the conversion tool ignored the rule name,
it was able to generate the constraint correctly
– One Application X table actually had values that
violated rules!
y Oracle’s converted constraints successfully
rejected those rows when attempting to load the
data from a bcp file
Items Requiring Resolution During
Migration
y Indexes
– Oracle requires each Index name be unique
y Several indexes in Application X had the same
name
y Oracle’s toolkit converts the index names to
tablename_indexname
– Oracle does not have a concept of a “clustered
index”
y Clustered indexes are created as standard Oracle
B-Tree indexes
y T-SQL functions - manual
– Oracle does not support Sybase’s system
functions
y Need to be written as Oracle functions…
y For example, suser_name() can be
converted to “select from
Items Requiring Resolution During
Migration
y Set rowcount n
– Oracle does not support the Sybase “set rowcount n”
command
y Cursors are set up to loop through n iterations
y Temporary tables - manual
– Oracle does not have temporary tables, as per
Sybase
y Oracle8i is supposed to introduce temporary
tables
– To resolve this, the migration tool created permanent
tables with a column for session id
y Each user inserts their rows with a unique
identifying session id to prevent each other from
writing and reading others rows
y The Session Id was retrieved from the system
catalog table V$SESSION
Items Requiring Resolution During
Migration
y Identity Columns
– Oracle’s analogous feature to identity columns is
“Sequence”
y CREATE SEQUENCE empseq INCREMENT BY
1
– The sequence value can be retrieved retrieved via
SQL
y SELECT empseq.currval FROM EMPLOYEE;
y Character Length Mismatch - manual
– A variable defined as VARCHAR2(15) and inserted
to a column defined as CHAR(10) generates an error
– Column definition needed to be expanded to
CHAR(15)
y ALTER TABLE tab_name MODIFY (col
VARCHAR2(15));
Application X Migration

y Oracle’s effort can be broken down as follows:

– 4 people for one week migrating the database and all
stored procedures including Sybase T-SQL
conversion to Oracle PL/SQL and error handling
– 1 person for two weeks correcting syntax and
debugging the converted stored procedures
– 2 people for one day to demo the migrated
application and ensure that final results were as
expected
Improving the Application

If we were not to do a straight conversion:

y Leverage PL/SQL more: package specs,
record/object-types, Java business logic
y Introduce asynchronous processing (AQ)
y Move Perl to Servlet/JSP/XML architecture
and separate out presentation layer
y Look at LDAP, PKI, single sign-on, other
directory-related technologies
Improving the Process

y TQM: Maintain conversion metrics, project

plans, and other documentation to help
others at PaineWebber leverage the MAC
conversion experience
y Open-source: Set-up a common Web-site
for other application developers and
system/database administrators to access
and improve conversion code/scripts