ORACLE TO SYBASE ASE
MIGRATION GUIDE
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Introduction 2
Table of Contents
1 Introduction .................................................................................................................................................................................... 4 1.1 Intended Audience ...................................................................................................................................................................................... 4 1.2 What You Should Already Know ............................................................................................................................................................. 4 1.3 About Sybase ASE ...................................................................................................................................................................................... 4 1.4 Oracle systems targeted by this Guide .................................................................................................................................................... 4 1.5 Oracle products vs. Sybase products ....................................................................................................................................................... 4 1.6 Oracle / Sybase database versions covered ............................................................................................................................................ 5 1.7 Sybase ASE documents and references ................................................................................................................................................... 5
2 How to use this Migration Guide................................................................................................................................................ 6 2.1 Migration process outline ........................................................................................................................................................................... 6 2.2 Success factors .............................................................................................................................................................................................. 6 2.3 Not covered by this guide: Project aspects ............................................................................................................................................. 7 2.4 Not covered by this guide: Sybase ASE-specific tuning ...................................................................................................................... 7
3 Pre-migration complexity assessment ........................................................................................................................................ 8 3.1 Oracle checklist: datatypes ......................................................................................................................................................................... 8 3.2 Oracle checklist: category "Simple Conversion" ................................................................................................................................... 8 3.3 Oracle checklist: category "Partial Rewrite" ......................................................................................................................................... 12 3.4 Oracle checklist: category "Major Rewrite" .......................................................................................................................................... 15
4 Database Schema Migration ....................................................................................................................................................... 17 4.1 Obtaining the Oracle schema definition ............................................................................................................................................... 17
4.1.1 Using existing DDL scripts ................................................................................................................................................................ 17 4.1.2 Reverse-engineering the existing schema ........................................................................................................................................ 17
4.2 Using Sybase PowerDesigner for database schema migration ......................................................................................................... 18 4.2.1 PowerDesigner schema conversion steps ....................................................................................................................................... 18
4.3 Reverse-engineering the Oracle schema without Sybase PowerDesigner ...................................................................................... 18 4.4 Special cases in schema migration .......................................................................................................................................................... 18 4.5 Mapping the Oracle schema to Sybase ASE databases ...................................................................................................................... 19 4.6 Schema-related Oracle-Sybase terminology ......................................................................................................................................... 20 4.7 Mapping Oracle Datatypes to Sybase ASE .......................................................................................................................................... 21
4.7.1 Chained Oracle data rows .................................................................................................................................................................. 23 4.8 Search for Sybase ASE reserved words and keywords in Oracle ..................................................................................................... 23 4.9 Choosing a lock scheme for Sybase ASE tables .................................................................................................................................. 24 4.10 The Oracle DUAL Table ......................................................................................................................................................................... 24
5 Migrating server-level aspects .................................................................................................................................................... 25 5.1 Character set ............................................................................................................................................................................................... 25 5.2 Database server case sensitivity ('sort order') ....................................................................................................................................... 25 5.3 Server configuration parameters ............................................................................................................................................................. 26 5.4 Storage .......................................................................................................................................................................................................... 26 5.5 Migrating the User Logins ....................................................................................................................................................................... 26
5.5.1 User passwords ..................................................................................................................................................................................... 27 5.6 Permissions ................................................................................................................................................................................................. 27
6 Data Migration .............................................................................................................................................................................. 28 6.1 Unload Oracle data into ASCII files; load into ASE with "bcp" utility .......................................................................................... 29
6.1.1 Loading into ASE with "bcp" ............................................................................................................................................................ 29 6.1.2 Unloading from Oracle: FACT (3rd-party tool) ............................................................................................................................ 29 6.1.3 Unloading from Oracle: Roll-your-own PL/SQL utility to export Oracle data...................................................................... 30 6.1.4 Unloading from Oracle: use Oracle SQL Developer ................................................................................................................... 30
6.2 Use Sybase's Enterprise Connect Data Access (ECDA) Option for Oracle ................................................................................. 30 6.2.1 ECDA Example ................................................................................................................................................................................... 30
6.3 Use Sybase Replication Server Heterogeneous Edition (RSHE) for Oracle ................................................................................. 30 6.3.1 Minimal migration downtime with Replication ............................................................................................................................. 30 6.3.2 Initial materialization for the replication setup .............................................................................................................................. 31 6.3.3 Other considerations ........................................................................................................................................................................... 31
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Introduction 3
6.4 Use a 3rd-party ETL tool that supports both Oracle and Sybase ASE .......................................................................................... 32 6.5 Oracle datatypes requiring special attention for migration ................................................................................................................ 32
7 Migrating PL/SQL to Transact-SQL ....................................................................................................................................... 33 7.1 Locations of PL/SQL code ..................................................................................................................................................................... 33 7.2 3rd-party tools for PL/SQL migration to T-SQL ................................................................................................................................ 33
8 Transactions and Locking, Oracle vs. Sybase ......................................................................................................................... 35 8.1 Oracle MVCC vs. Sybase locking ........................................................................................................................................................... 35 8.2 Transaction-related migration issues ...................................................................................................................................................... 35 8.3 Using ASE implicit/chained transaction mode ................................................................................................................................... 36
8.3.1 Transactional DDL .............................................................................................................................................................................. 36 8.3.2 Transaction processing in stored procedures ................................................................................................................................. 36
8.4 Using ASE explicit/unchained transaction mode ............................................................................................................................... 36 8.5 Using ASE transactional concurrency enhancements ........................................................................................................................ 36 8.6 Other transactional aspects ...................................................................................................................................................................... 37
9 Miscellaneous migration aspects ................................................................................................................................................ 39 9.1 Cursors ......................................................................................................................................................................................................... 39 9.2 Sequences .................................................................................................................................................................................................... 39 9.3 Error/Exception handling ....................................................................................................................................................................... 41 9.4 Outer join limitations ................................................................................................................................................................................ 41 9.5 Migrating JDBC/ODBC/… Applications ........................................................................................................................................... 42
9.5.1 JDBC ...................................................................................................................................................................................................... 42 9.6 Oracle Forms .............................................................................................................................................................................................. 42
10 DBA Tasks Cross-Reference ..................................................................................................................................................... 43
11 Oracle-to-Sybase Migration Cross-Reference ......................................................................................................................... 47 11.1 Oracle-to-Sybase ASE migration: category "Simple Conversion" ................................................................................................... 47 11.2 Oracle-to-Sybase ASE migration: category "Partial Rewrite" ........................................................................................................... 56 11.3 Oracle-to-Sybase ASE migration: category "Major Rewrite" ........................................................................................................... 64
Revision history:
Rev.1.0: September 2011: initial version
Rev.1.1: November 2011: expanded the topic on case-sensitivity; various other additions
Rev.1.2: October 2012: many extensions to chapters 3 & 11; added example of sequence equivalent in ASE
Rev.1.3: December 2012: replaced PowerDesigner and ECDA examples by pointers to a separate document
© 2011-2012 Sybase, Inc.
Sybase, Transact-SQL, Adaptive Server Enterprise and Replication Server are registered trademarks of Sybase, Inc.
Other product or brand names may be (registered) trademarks of their respective owners.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Introduction 4
1 INTRODUCTION
This Migration Guide aims to provide guidance and assistance with the migration process from an Oracle database to
Sybase ASE (Adaptive Server Enterprise). By "migration" we mean the process of changing a client-server application
currently using the Oracle database as its RDBMS, such that it uses the Sybase ASE database instead.
This Migration Guide has as its primary focus to migrate functionality from Oracle to Sybase ASE. Performance-related
aspects of Sybase ASE are not covered (also see section 2.4).
1.1 Intended Audience
This Migration Guide is intended for anyone involved in migrating an Oracle database to Sybase Adaptive Server
Enterprise (ASE).
1.2 What You Should Already Know
The reader is expected to be familiar with relational database concepts, and with Oracle in particular. In addition,
introductory knowledge of the Sybase ASE RDBMS is required.
For a database migration to be successful, there should be a detailed understanding of the current Oracle-based system,
including its high- and low-level architecture, as well as the interaction between the client application and the Oracle
database.
1.3 About Sybase ASE
Sybase ASE is the database that powers Wall Street. ASE has been delivering rock-solid reliability and top-level
performance for the past 25 years. Sybase ASE has a lower total cost of ownership than Oracle, and delivers better
performance on the same hardware. Sybase ASE is ready to be the database in any application that runs on Oracle today.
1.4 Oracle systems targeted by this Guide
This Migration Guide can be used for migrations of any type of Oracle-based system. While it does not focus on a
specific type of application, workload or system design, the majority of Oracle-based migration candidate systems are
expected to be transactional systems.
This Migration Guide specifically does not aim at migrating SAP Business Suite installations currently running on
Oracle, to run on Sybase ASE instead. Since such migrations are covered by product and service offerings by SAP,
interested customers should contact SAP directly.
1.5 Oracle products vs. Sybase products
Both Oracle and Sybase provide a range of database-related products. The following list illustrates how the main high-
level Oracle products compared to Sybase products. While this list is deliberately kept brief, it provides some basic
guidance on how Oracle and Sybase can be aligned.
The focus of this Migration Guide is on migration from Oracle Database Server to Sybase ASE. These are usually
expected to be OLTP-oriented systems, though this is not required.
Oracle Sybase
Oracle Database Server Sybase ASE (Adaptive Server Enterprise)
Oracle OLAP and DW Sybase IQ
Oracle RAC Sybase ASE Cluster Edition
Oracle Times Ten Sybase ASE In-Memory Database
Oracle Streams Sybase Replication Server
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Introduction 5
1.6 Oracle / Sybase database versions covered
This document pertains to Oracle versions 9i, 10g and 11g.
The migration target is assumed to be Sybase ASE version 15.7 (or later). Migration to earlier ASE versions is not
recommended and not covered by this Migration Guide.
If not otherwise specified all references to "ASE" or "Adaptive Server" are considered references to "Sybase Adaptive
Server Enterprise".
1.7 Sybase ASE documents and references
For more detailed information about Sybase ASE , see http://www.sybase.com/ase for general documents and
whitepapers.
See http://www.sybase.com/support/techdocs/migration for resources specifically focused at (different types of)
migrations. These include the document you are currently reading, as well as “Migrating an Oracle Database to SAP Sybase
ASE with PowerDesigner and ECDA (A Step-By-Step Practical Guide)” .
For ASE documentation and product manuals, see http://infocenter.sybase.com . Specifically, the following ASE
documents are relevant:
Transact SQL User's Guide
Reference Manual
System Administration Guide
Utility Guide
Performance and Tuning Guide
In addition, Sybase provides technical training for ASE. For details on courses and availability, see
http://www.sybase.com/education.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
How to use this Migration Guide 6
2 HOW TO USE THIS MIGRATION GUIDE
The focus of this Migration Guide is on the database-specific technical aspects of an Oracle to Sybase database
migration project. In particular, it aims to help identify and assess the complexity of the migration when scoping out a
migration project, so as to avoid overlooking or underestimating potentially difficult aspects of the system to be
migrated. In addition, it helps establish a migration approach by providing and suggesting technical options for various
aspects of the migration process.
2.1 Migration process outline
This Migration Guide recommends a phased approach towards migrating from Oracle to Sybase ASE. The following
phases can be identified, in order of importance and priority:
1. Before starting the actual migration project, assess the complexity of the migration using the checklist in
chapter 3. This activity involves identifying specific Oracle features used in the current system which may not
have a direct Sybase equivalent.
It is strongly recommended to pay sufficient attention to this activity, as this helps to avoid
overlooking or underestimating the most difficult parts of a migration.
2. Migrating the database schema is the necessary first step of an actual migration (described in chapter 4).
This Migration Guide recommends using Sybase PowerDesigner to reverse-engineer the Oracle schema and
convert it to the Sybase ASE equivalent.
3. Migrating server-level aspects such as users (described in chapter 5).
4. Migrating the data itself (described in chapter 6). The approach chosen to perform the data migration is usually
driven by the maximum tolerable downtime allowed for the application.
It is recommended to consider using 3rd-party tools for extracting data from Oracle. If minimal application
downtime is crucial, consider Sybase Replication Server to reduce this downtime to minutes rather than hours.
5. Migrating Oracle PL/SQL code to Sybase Transact-SQL (also see chapter 7). This needs to be performed both
for SQL located in the database (i.e. stored procedures, triggers, SQL functions) as well as for SQL code in
client applications. This step tends to be the most complex part of a migration.
To assist with this migration step, chapter 11 contains cross-reference between Oracle features and their Sybase
ASE equivalent, in the three categories "Simple conversion possible", "Partial rewrite required" and "Major
rewrite required". This cross-reference is an extended version of the Oracle checklist in chapter 3.
6. Migration of vendor-specific infrastructural components, such as JDBC drivers (see section 9.5).
7. Convert the maintenance, administration and monitoring tasks. Since these aspects are highly specific for each
database brand, "migration" would be a misnomer.
Chapter 10 contains a cross-reference of some common DBA aspects. This is however not sufficient for
performing a migration, and specific DBA skills, both for Oracle and Sybase, will be required.
8. The primary focus of this Migration Guide is to help achieve functional equivalence of the Oracle system after
being migrated to Sybase ASE.
As a next step, Sybase ASE-specific optimization and tuning will likely be required in order to achieve desired
performance levels. Sybase ASE-specific tuning is not covered by this Migration Guide; see section 2.4.
2.2 Success factors
Database migrations can be complex, and costly migration failures need to be avoided. The following success factors
apply to any Oracle-to-Sybase database migration project:
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
How to use this Migration Guide 7
Domain knowledge of the business application(s), system and environment. It is essential to have a full and
complete understanding of all applications that access the Oracle database being migrated. This includes the
client applications that connect to the Oracle database directly, but also applications that indirectly access the
database, for example through an application server.
For all these applications, it needs to be understood which data the application accesses in the database, and
how it modifies such data. Any SQL code submitted to the database by the application must be identified, as
well as how such SQL code can be changed.
Availability of sufficient Oracle expertise to analyze all aspects of the database is an absolute requirement. A
key activity is to identify which specific Oracle features are used (as per the checklists in chapter 3), especially
those which do not have a direct Sybase equivalent.
Full access to all Oracle PL/SQL code being used, both in the database and in all client applications.
As a minimum, sufficient understanding of Sybase ASE in order to create a functionally working migrated
database system. At a later stage in the migration project, more specialized Sybase expertise will likely be
needed for Sybase ASE-specific performance tuning and optimization. Having such expertise available at an
early stage may be helpful.
A comprehensive testing process and production-like environment for validating the migration approach and
the affected software applications against the migrated Sybase database. For best results, it is highly
recommended to use a copy of production data (as close as possible) as well as hardware which is similar in size
to production.
2.3 Not covered by this guide: Project aspects
This Migration Guide does not prescribe or suggest how to organize a migration project in terms of preparation, setting
up testing procedures, validating the migrated components, etc. These aspects of a migration project are left to
requirements, standards, best practices and preferences of the organization undertaking the emigration effort.
Please note that the absence of specific recommendations for testing and validation of migrated components does not
mean that such activities should not be performed. On the contrary, these activities are essential, and it is recommended
to follow generally accepted best practices with respect to software testing and validation.
2.4 Not covered by this guide: Sybase ASE-specific tuning
The primary purpose of this Migration Guide is to assist in creating a functionally equivalent Sybase ASE-based system
compared with the original Oracle-based system. The purpose of this Migration Guide is not to provide guidance for
arriving at an optimally tuned Sybase ASE system; while Sybase ASE-specific tuning will likely be necessary as part of a
migration project, this Migration Guide deliberately makes no attempt to cover such tuning aspects.
Since ASE-specific tuning is considered to be mostly unrelated to any Oracle-specific aspects or considerations, the
reader is referred to the Sybase ASE documentation for background and recommendations about Sybase ASE tuning.,
specifically the System Administration Guide and the Performance and Tuning manuals.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Pre-migration complexity assessment 8
3 PRE-MIGRATION COMPLEXITY ASSESSMENT
For a database migration project, it is crucial to have an accurate assessment of the complexity of the migration ahead of
time. Here, "complexity" refers to how Oracle-specific features can be mapped to the feature set of Sybase ASE.
Before starting the actual migration effort, the current Oracle system should be closely inspected and a list should be
drawn up of all types of Oracle-specific features being used, and how many times these occur.
For each feature used, it should be determined in which of the following three categories it falls:
Simple conversion possible
An Oracle feature or statement can be mapped and converted directly to a (nearly) identical Sybase ASE
feature, requiring no syntax changes or only simple, local syntax changes only.
Examples: most datatype mappings (Oracle VARCHAR2 Sybase VARCHAR); simple SELECT statements
Partial rewrite required
An Oracle feature or statement can be mapped to a partly equivalent Sybase ASE feature, requiring potentially
significant syntax changes and possibly partial rewriting of algorithms.
Example: Oracle sequences Sybase ASE identity columns
Major rewrite required
An Oracle feature or statement has no directly equivalent Sybase ASE feature, requiring rewriting or
redesigning of algorithms or parts of applications.
Example: Oracle Flashback; Oracle row-level triggers.
Categorizing the Oracle features used by the system being migrated helps to identify the areas where most migration
complexity is likely to occur. Before deciding to start the migration project, there should be a clear view of the number
of occurrences of the features in the categories "Partial rewrite required" and "Major rewrite required" above, and of the
effort to migrate these, especially those in the Major rewrite required" category.
To assist with this complexity assessment, below are three checklists, corresponding to the categories above, listing a
range of Oracle features. Note that additional Oracle features may occur in your system that are not in these checklists;
these should be taken into account just as well.
The checklists below list the Oracle features only very briefly. Chapter 11 contains extended versions of these checklists
with the corresponding Sybase ASE equivalent for each Oracle feature.
3.1 Oracle checklist: datatypes
Verify the datatypes used in the current Oracle application; see section 4.7.
Also see:
section 4.7.1 for considerations that apply when migrating data rows whose length exceed an Oracle disk block;
section 6.5 for considerations that apply when migrating particular datatypes.
3.2 Oracle checklist: category "Simple Conversion"
#cases found Oracle checklist: category "Simple Conversion"
Connecting to an Oracle schema
The Oracle SQL*Plus “slash” character sends preceding PL/SQL text to the Oracle server.
Semicolon (as a statement delimiter in PL/SQL)
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Pre-migration complexity assessment 9
#cases found Oracle checklist: category "Simple Conversion"
The Oracle DUAL table
SET SAVEPOINT savepoint-name
Variable/Parameter declarations; naming syntax
Assign default value in variable declaration
Multiple variable declarations with a single DECLARE keyword
Declarations without DECLARE keyword in declaration section of stored procedures/functions
Variable assignment
Transferring table data into a variable
Constants
%TYPE denotes the datatype of a column in an existing table
Dynamic SQL (Execute-immediate)
Loops with LOOP/END LOOP
FOR loops
CURSOR loops
Oracle Outer join syntax
SET TRANSACTION READ WRITE
ALTER TABLE mytable TRUNCATE PARTITION partition_name
CREATE OR REPLACE PROCEDURE (or FUNCTION)
ALTER PROCEDURE (or FUNCTION)
CREATE PROCEDURE… IS…
Stored procedure execution with named parameters (param => value)
Stored procedure execution with positional parameters (:var)
Stored procedure execution
SQL Function declaration with DETERMINISTIC keyword
Execution of a SQL Function
DECLARE CURSOR cursor-name IS…
Oracle cursors
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Pre-migration complexity assessment 10
#cases found Oracle checklist: category "Simple Conversion"
Cursor Attribute %ISOPEN
Cursor Attributes %FOUND, %NOTFOUND
Cursor Attribute %ROWCOUNT
AFTER triggers (on statement level)
INSTEAD OF triggers (on views)
SQL%ROWCOUNT
BOOLEAN datatype (for PL/SQL variables only)
MERGE statement
Partitioned tables with composite partitioning
Performance-optimized native PL/SQL datatypes (for PL/SQL variables only) BINARY_INTEGER BINARY_DOUBLE BINARY_FLOAT
IF-THEN-ELSE
Multiple statements in an IF-THEN-ELSE branch
Conditional test based on EXISTS subquery
String concatenation operator: ||
userenv('sessionid')
MOD(X,Y)
CEIL()
TRUNC(number)
SUBSTR()
SUBSTR() function with two parameters
LENGTH()
CHR()
REPLACE()
TO_CHAR(expression)
TO_CHAR(expression, datepart)
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Pre-migration complexity assessment 11
#cases found Oracle checklist: category "Simple Conversion"
TO_CHAR(expression, format-string)
TO_NUMBER(expression)
Date/time functions and calculations
SYSDATE, SYSTIMESTAMP
TRUNC(date/time [,unit])
LAST_DAY()
NVL() function
Inconsistent use of upper/lowercase for identifiers (Oracle is case-insenstive for identifiers)
Identifiers that are Sybase ASE reserved words (see section 4.8)
INSTR() function with two parameters
Derived tables (also known as "inline views") without correlation name
ALTER TABLE … SPLIT PARTITION…
ALTER TABLE … MERGE PARTITIONS…
Quoted identifiers. Oracle allows using quoted identifiers by enclosing an identifier in double
quotes.
Oracle hints
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Pre-migration complexity assessment 12
3.3 Oracle checklist: category "Partial Rewrite"
For the Oracle features listed below, migration to partly equivalent Sybase ASE features is possible, although potentially
significant syntax changes and possibly partial rewriting of algorithms may be required.
#cases found Oracle checklist: category "Partial Rewrite"
Database links
External tables
Sequences
Table-valued User-defined SQL Functions
Pipelined Table Functions
Synonyms
Comments on database objects
Bitmap indexes
Temporary tables
IS TABLE OF, AS VARRAY(n)OF
Nested tables
Object tables
%ROWTYPE
Define a PL/SQL record type by enumerating the fields with IS RECORD OF or TYPE…IS
RECORD
Non-integer RETURN value in stored procedure
User-defined Packages
Overloaded stored procedures
PL/SQL Exception handling; defining exception handlers
SQLCODE, SQLERRM
RAISE_APPLICATION_ERROR
Column Encryption
LOB locators
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Pre-migration complexity assessment 13
#cases found Oracle checklist: category "Partial Rewrite"
Data compression
Retrieving data to the client in stored procedures using
DBMS_OUTPUT package
DBMS_*, UTL_* package calls (excl. DBMS_OUTPUT)
SDO_* package calls
SQL*Loader (sqlldr)
Materialized Views
Global variables (in a PL/SQL package)
INTERSECT construct
MINUS construct
Specific SQL clauses
AS OF AS OF TIMESTAMP CONNECT BY DIMENSION DIMENSION BY EXCLUDE GROUPING SETS INCLUDE MEASURES RETURN ALL ROWS RETURN UPDATED ROWS PARTITION BY REFERENCE SYSTIMESTAMP
CROSS CUBE FOR KEEP MAIN MODEL NAV NOCYCLE NOWAIT ON ONLY RULES SAMPLE SEED SKIP
IGNORE ITERATE NATURAL NULLS NULLS FIRST NULLS LAST ROLLUP SIBLINGS SINGLE REFERENCE LOCKED START WITH UNIQUE UNPIVOT WAIT
INITCAP( string-expression )
INSTR() function with three or four parameters
NVL2() function
DECODE() function
Primary key and foreign key with different datatypes, different precision/scale (for numeric
datatypes) or different length (for character datatypes)
Cluster (as created with CREATE CLUSTER)
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Pre-migration complexity assessment 14
#cases found Oracle checklist: category "Partial Rewrite"
SQL functions where the last statement is not RETURN
Derived tables (also known as "inline views") using "with" syntax
UNIONs in cursors
PRAGMA directives
Autonomous transactions
ON DELETE CASCADE constraints
XMLTYPE (XML data type)
XML functions extract(), existsnode(), xmlexists(), etc
ROWID
ROWNUM
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Pre-migration complexity assessment 15
3.4 Oracle checklist: category "Major Rewrite"
For the Oracle features listed below, no direct equivalent is available in Sybase ASE. Consequently, rewriting or
redesigning algorithms or parts of applications will be required.
#cases found Oracle checklist: category "Major Rewrite"
Oracle MVCC (Multi-Version Concurrency Control; "writers don‟t block readers, readers don't
block writers")
Relevant aspects:
Applications or queries relying on non-blocking MVCC
Long-running transactions
DDL in transactions
SET TRANSACTION READ ONLY
SQL*Plus autocommit/commit-on-exit
SQL*Plus
BEFORE triggers
Triggers on row level (BEFORE and AFTER)
Multiple triggers for a DML type on a table
REF CURSOR
Regular Expressions; functions REGEXP_LIKE(), REGEXP_SUBSTR(),
REGEXP_REPLACE(), REGEXP_INSTR()
Windowing queries (SELECT…OVER(…) …)
SQL function OUT/IN OUT parameters
Non-deterministic SQL Functions (functions whose result may be independent of the function
input parameters)
SQL Aggregate Functions
BFILE datatype
Oracle Streams; Oracle Data Guard
Oracle RAC for high-availability
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Pre-migration complexity assessment 16
#cases found Oracle checklist: category "Major Rewrite"
Oracle Flashback
Oracle Snapshot Standby
Oracle SQL Plan Management
AWR (Automatic Workload Repository)
Oracle Advanced Queuing
Packages for PL/SQL web access
OWA_CUSTOM, OWA_CX, OWA_OPT_LOCK, OWA_SEC, OWA_TEXT, OWA_UTIL
Oracle Forms
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Database Schema Migration 17
4 DATABASE SCHEMA MIGRATION
The first step in migrating an Oracle database to Sybase ASE is to migrate the database schema. Here, "database
schema" refers to the physical data model. In other words, to the definition of the database structure, specifically of the
tables, columns, indexes, views, datatypes, etc., typically expressed in SQL DDL (Data Definition Language), for
example as e.g. 'create table' statements.
There is some potential for terminology clash around the term "schema":
As a generic database concept, "schema" is the definition of the database structure as described above,
regardless of which database user owns the object(s).
In Oracle, a "schema" is an central concept. It is a collection of database objects (tables, views, stored
procedures, triggers, etc) owned by a particular user. A decision will need to be made as to how to map an
Oracle schema to an ASE schema; see section 4.5 for details.
In Sybase ASE, a "schema" is usually understood to refer to the generic concept of database schema.
NB: For completeness, ASE also has a command create schema authorization which creates a number of
tables and views plus associated permission settings as a transactional unit. This command is however rarely
used in ASE and it is not used or discussed further in this Migration Guide.
For clarity, this Migration Guide will use "Oracle schema" when referring to the Oracle-specific interpretation of
"schema". In all other cases, "schema" refers to the generic concept of "database schema" as above.
Please note: none of the methods describes in this chapter converts Oracle's PL/SQL code into Sybase's Transact-
SQL, which is needed when converting stored procedures, triggers and SQL functions. 3rd-party tools which such
capabilities exist; see section 7.2 for more information.
4.1 Obtaining the Oracle schema definition
When migrating the database schema from Oracle to ASE, we first need to obtain the Oracle schema, and then convert
this to a format and syntax that can be used in Sybase ASE.
In principle there are two methods to obtain the Oracle schema:
Use existing DDL scripts from which the Oracle schema was created in the past; typically, in well-organized
environments, such scripts are kept in a source code repository under version control.
Reverse-engineer the Oracle schema from the actual Oracle database.
4.1.1 Using existing DDL scripts
If not using a tool to reverse engineer and migrate the schema, then using existing DDL scripts would be the ideal
starting point, since no further work is required to obtain the Oracle schema. However, the question is whether it can be
guaranteed that such scripts are up-to-date and identical to the actual Oracle database. It is not uncommon to see that
changes to the database schema have been made without updating the DDL scripts in the repository. Clearly, basing
oneself on incorrect DDL scripts will cause problems later in the migration process.
When existing Oracle DDL scripts are available, the next step is to convert the datatypes to Sybase ASE. Section 4.7
describes the mapping from Oracle datatypes to Sybase ASE. In addition, some aspects of the Oracle schema require
special attention; see section 4.4.
4.1.2 Reverse-engineering the existing schema
The alternative to using existing scripts is to reverse-engineer the Oracle schema from the actual Oracle database. This is
more work, and may require special tools, but it has the advantage that the generated DDL is correct.
When existing scripts cannot be used or relied upon, this Migration Guide recommends using Sybase PowerDesigner for
reverse-engineering and migrating the database schema. Since PowerDesigner can reverse-engineer all tables, indexes,
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Database Schema Migration 18
etc, and automatically convert the Oracle datatypes into their ASE equivalent, this is the fastest and most efficient
schema migration method available.
Section 4.2 describes how to use PowerDesigner for this purpose.
Section 4.3 describes a possible approach to reverse-engineer the schema without PowerDesigner.
4.2 Using Sybase PowerDesigner for database schema migration
Sybase PowerDesigner is arguably the most advanced data modeling tool in the market. It is a stand-alone tool, running
on Windows. PowerDesigner supports over 30 database types, including Oracle and Sybase ASE.
For more information on PowerDesigner, see http://www.sybase.com/powerdesigner .
With PowerDesigner it is relatively straightforward to reverse-engineer most of the Oracle schema and convert it to
Sybase ASE. The central concept used by PowerDesigner is the PowerDesigner Physical Data Model (PDM). This is a
database-independent model which can be converted to the SQL DDL dialect of each supported database.
4.2.1 PowerDesigner schema conversion steps
For detailed, step-by-step instructions on how to use PowerDesigner to convert the database schema from Oracle to
Sybase ASE, see the document “Migrating an Oracle Database to SAP Sybase ASE with PowerDesigner and ECDA (A Step-By-
Step Practical Guide)” at http://www.sybase.com/support/techdocs/migration.
Once the schema is reverse-engineered, run the completed DDL script in Sybase ASE and check for any errors.
Note that some aspects of schema migration cannot be handled by PowerDesigner and will have to be handled
differently. These aspects are described in section 4.4.
4.3 Reverse-engineering the Oracle schema without Sybase PowerDesigner
Without using Sybase PowerDesigner, reverse-engineering the schema can be done in a number of ways:
Use the Oracle SQL*Plus DESC command on all database objects, and process the output so that they are
valid DDL statements. This is likely to require significant manual script coding.
Use the Oracle DBMS_METADATA package to extract DDL for the Oracle objects. This involves SQL
statements such as the following (for Oracle table 'MY_TABLE', in schema/user 'SALESAPP'). Note that
these are only examples, this is not a complete list of all statement required to perform full reverse-engineering:
SELECT DBMS_METADATA.GET_DDL('TABLE', 'MY_TABLE', 'SALESAPP') FROM DUAL;
SELECT DBMS_METADATA.GET_DEPENDENT_DDL('INDEX', 'MY_TABLE', 'SALESAPP') FROM
DUAL;
SELECT DBMS_METADATA.GET_GRANTED_DDL('OBJECT_GRANT', 'SALESAPP') FROM DUAL;
Use Oracle SQL Developer (a free Java-based tool, downloadable from oracle.com). This uses the
DBMS_METADATA package (see previous bullet).
Use TOAD (a low-cost tool, commonly used in many Oracle environments) to extract the object definitions,
and then manually convert the Oracle datatypes into their ASE equivalent. This could be cumbersome when
large numbers of tables are involved.
Once the Oracle schema has been reverse-engineered, the Oracle DDL needs to be converted to Sybase ASE syntax,
including conversion from the Oracle datatypes to Sybase ASE datatypes. Section 4.7 describes the mapping from
Oracle datatypes to Sybase ASE.
In addition, some aspects of the Oracle schema require special attention; see section 4.4.
4.4 Special cases in schema migration
The following schema aspects require special attention:
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Database Schema Migration 19
Oracle allows more columns per table than Sybase ASE (the limit depends on the ASE server's page size and
on the table's lock scheme). If the limit in Sybase ASE is exceeded, an error will be raised when trying to create
the table. If this occurs, either the ASE server's page size will need to be increased, or the table needs to be
split vertically into multiple tables and all queries referencing the table likely have to be modified accordingly
If the length of a column exceeds the maximum allowed length in Sybase ASE (the limit depends on the ASE
server's pagesize and on the table's lock scheme), such columns will have to be split into multiple columns and
placed in additional tables. All queries referencing the column likely have to be modified accordingly.
PowerDesigner converts the Oracle BFILE datatype to the Sybase ASE image datatype. Since BFILE is a
datatype used to store a locator (link) to an external binary file stored outside of the database, this is not
functionally equivalent so application changes may be required. If a different ASE datatype is required, for
example, to hold the name of an externally stored file, change it manually.
PowerDesigner 15.x cannot automatically convert the Oracle timestamp datatype to bigdatetime in
ASE, so this needs to be done manually. PowerDesigner 16.0 (release expected in August 2011) does not have
this limitation and will perform the conversion automatically.
PowerDesigner 15.x cannot reverse-engineer Oracle users or security details (permissions). PowerDesigner 16.0
(release expected in August 2011) does not have this limitation and is capable of handling these aspects.
Since the SQL reserved words are different between Oracle and Sybase ASE, before attempting a database
schema migration, all Oracle objects need to be checked against the Sybase ASE reserved words. Any Oracle
identifiers that are also Sybase ASE reserved words, need to be changed first. For a complete list of reserved
words in Sybase ASE, see “Adaptive Server Enterprise->Reference Manual: Building Blocks->Reserved Words”.
Also see section 4.8 for queries that can be used to search for the occurrence of keywords in the Oracle
database.
The mapping of Oracle user-defined datatypes to ASE can be difficult and may require extensive manual
intervention. The key to user-defined datatype migration is to fully understand the underlying base datatype.
Note that user-defined datatypes can be nested. For Oracle, user-defined datatypes is an add-on option to the
database and is not widely used.
4.5 Mapping the Oracle schema to Sybase ASE databases
Sybase ASE does not have an identical interpretation of the concept of "schema" as the "Oracle schema". When
migrating an Oracle schema to Sybase ASE, there are two basic options to map the Oracle schema to Sybase ASE.
For the sake of example, let's assume there are two Oracle users john and bill who own an Oracle schema, and each
schema has a table named salesdetails.
The options are:
Perhaps the most straightforward way to migrate, is to map each Oracle schema to a separate ASE database,
where each database is owned ('dbo') by the corresponding user. This would result in two ASE databases
named john_db and bill_db (different names may of course be chosen), owned by ASE logins john and
bill respectively; each database has table named salesdetails, owned by the dbo database user (the full
table name would be dbo.salesdetails).
However, this results in as many ASE databases as there are users owning an Oracle schema, of which there
might be many. While an ASE server can hold up to 32786 databases, it is highly impractical from a DBA
perspective to have more than 20-50 databases.
Map all Oracle schemas to a single ASE database with a multi-tenancy model. This means that the ASE
database user (which is linked to the ASE server login, which is the equivalent of an Oracle user) is used within
the database to identify each object's owner. This will result in a more manageable ASE system since there will
be less ASE databases.
In this case, the example would result in a single ASE database, let's say sales_db, in which ASE logins john
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Database Schema Migration 20
and bill have been added as database users. Under each user, a salesdetails table is created, which will
have the full name john.salesdetails and bill.salesdetails.
Either option is possible; technically ASE does not favor one over the other, but the multi-tenancy model fits best with
ASE's methods for backup and restore.
It should be noted that multi-tenancy models are sometimes incorrectly seen as security weaknesses since it would be
easier for user bill to access john's tables, since they are located in the same ASE database. This is however not justified:
if standard best practices around ASE security are followed, then security can be fully guaranteed.
One consideration around multi-tenancy databases is that a backup of a database contains the data from all users in that
database. If this is undesirable, for example because each user wants to have a backup copy of his own database, then
the first option above (separate ASE databases for each user) should be followed instead.
Lastly, it may also be the case that there is only one Oracle schema. In that case, there is no need to qualify the ASE
tables with the owner name since they will all be owned by the dbo user.
4.6 Schema-related Oracle-Sybase terminology
Following is the high-level terminology mapping of Oracle concepts to Sybase concepts. This table is not intended to be
used for direct migration purposes, but only as high-level terminology guidance.
Oracle Sybase ASE
Database Database Server
Schema Database and objects owned by the same user.
Tablespace Aspects of ASE database and/or database device and/or
segment
(system/sysaux tablespaceASE master database;
temporary tablespaceASE tempdb database;
user-defined tablespacedatabase device and/or segment)
Segment A database object that has space allocated (table, index,
materialized view)
Undo/rollback tablespace Transaction log
Online redo logs Transaction log
User User, Login (see section 5.5)
Role Role
Table Table
Temporary table Temporary table
View View
Materialized View No direct equivalent
Cluster No direct equivalent
Index Non-unique index
Index-organized table Table with clustered index
Column-level check constraint Column-level check constraint
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Database Schema Migration 21
Oracle Sybase ASE
Column default Column default
Unique key Unique key or identity property for a column
Primary key Primary key
Foreign key Foreign key
Constraints Constraints
Collections In PL/SQL, a collection is an ordered group of elements
of the same type, such as VARRAYs or nested tables.
PL/SQL Procedure Transact-SQL stored procedure
PL/SQL Function T-SQL user-defined SQL function (SQL UDF)
Triggers Triggers
Package No direct equivalent
Sequences Partly covered by the identity property for a column or
dedicated key value table
Snapshot No direct equivalent
Database links, External tables Proxy Tables and Remote Servers
Procedure Stored procedure
Synonym Similar functionality with views for table and view
synonyms. All other synonym references must be replaced
with fully qualified object strings (database.owner.object)
or proxy tables (for synonyms to remote objects).
4.7 Mapping Oracle Datatypes to Sybase ASE
The table below describes how Oracle datatypes can be mapped to Sybase ASE datatypes. In most cases the mapping of
datatypes is straightforward.
For the Oracle datatypes CHAR, VARCHAR2 and RAW, the ASE server page size determines whether or not the
mapping can take place; the technical background is that ASE requires a row, and therefore every column, to fit on an
ASE database page. By default, ASE uses a 2KB server page size, but 4KB, 8KB and 16KB are also possible.
The maximum allowed column length for a column for each ASE server page size depends on various factors such as
whether the column is fixed- or variable length and the ASE table's lock scheme. To display full details, run the
command dbcc serverlimits in ASE.
Oracle Description Sybase ASE Comments / When to use
NUMBER(x) Oracle NUMBER(x) datatypes
with 0 decimals can be converted
into an equivalent Sybase ASE
datatypes.
BIGINT length of NUMBER datatype > 10
INTEGER length of NUMBER datatype between
6 and 10 and data values <= 2 billion
SMALLINT length of NUMBER datatype is
between 4 and 5 and data values <=
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Database Schema Migration 22
Oracle Description Sybase ASE Comments / When to use
32767
TINYINT length of NUMBER datatype between
2 and 3 and data values <= 255
BIT length of NUMBER datatype = 1
NUMBER(x,y) alternatively to the mapping path
above, these Sybase ASE
datatypes can be used.
NUMERIC(x,y)
DECIMAL(x,y)
translates the Oracle NUMBER
datatype one-to-one.
MONEY
SMALLMONEY
MONEY and SMALLMONEY store
monetary data.; 4 digits of precision to
the right of the decimal point, and 16 /
6 digits to the left for MONEY /
SMALLMONEY respectively.
FLOAT maximum FLOAT precision in
Oracle is approx. 38
DOUBLE precision of actual values > 15
FLOAT precision of actual values <= 15
CHAR(x) maximum CHAR size in Oracle
is 2000 bytes
CHAR(x) if ASE page size is 4kb or greater; and if
ASE page size is 2kb and x <= 1958
TEXT if none of the above conditions apply
VARCHAR2(x) maximum VARCHAR2 size in
Oracle is 4000 bytes for columns
(for PL/SQL variables, the max.
size is 32767)
VARCHAR(x) if ASE page size is 8kb or greater; if
ASE page size is 4kb and x <= 3988; if
ASE page size is 2kb and x <= 1948
TEXT if none of the above conditions apply
DATE date/ time precision in Oracle is
up to one second.
DATETIME Sybase ASE‟s DATETIME has a
precision of 1/300th of a second.
TIMESTAMP
[WITH [LOCAL]
TIME ZONE]
precision of Oracle‟s
TIMESTAMP is 1/100000000th
of a second
BIGDATETIME Sybase ASE‟s BIGDATETIME has a
precision of 1 microsecond. ASE does
not support time zones.
ROWID a pseudo column in Oracle, does
not represent a true datatype
NUMERIC
IDENTITY
Also see ROWID on page 62
CLOB Oracle‟s max. storage capacity for
CLOB is 128TB
TEXT Sybase ASE can hold a max. of 2GB
per column; IQ can hold up to 2PB
NCLOB Oracle‟s max. storage capacity for
NCLOB is 128TB
UNITEXT Sybase ASE can hold a max. of 2GB
per column; IQ can hold up to 2PB
BLOB Oracle‟s max. storage capacity for
BLOB is 128TB
IMAGE Sybase ASE can hold a max. of 2GB
per column; IQ can hold up to 2PB
LONG Oracle‟s max. storage capacity for
LONG is 2GB
TEXT
RAW(x) the RAW datatype in Oracle has a
max precision of 2000 bytes
BINARY(x)
VARBINARY(x)
if ASE page size is 4kb or greater; and if
ASE page size is 2kb and x <= 1954
IMAGE if none of the above conditions apply
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Database Schema Migration 23
Oracle Description Sybase ASE Comments / When to use
LONG RAW Oracle‟s max. storage capacity for
LONG RAW is 2GB
IMAGE
CHAR(1) if this is a packed bit column
maintained by a PL/SQL
function set / unset / retrieve /
query on them.
BIT
BFILE BFILE stores a locator (link) to a
binary file outside of the database
no direct equivalent
4.7.1 Chained Oracle data rows
Oracle allows long data rows to exceed the size of a disk block. This is known as 'chained rows'. It is possible that such
chained data rows, if they exist in the Oracle database, are too long to be stored in Sybase ASE, which requires that a
data rows fits on a data page (which is 2KB, 4KB, 8KB or 16KB; use dbcc serverlimits to find the net max row
length allowed in ASE). Also, for tables with more than 255 columns, the rows will always be chained.
It is important to identify tables that have chained rows before starting the migration. To find how many chained rows
occur in a table, run this Oracle query:
SELECT owner, table_name, chain_cnt
FROM dba_tables WHERE chain_cnt > 0
If chained rows are found, the Oracle command ANALYZE TABLE table-name LIST CHAINED ROWS
INTO chained-row-table can be used to identify the actual chained rows. If chained rows are found, it may be needed to modify the data model to ensure that rows are short enough to fit on an ASE page.
4.8 Search for Sybase ASE reserved words and keywords in Oracle
Before you can migrate an Oracle schema or Oracle stored procedure, function or trigger, there needs to be a check for
reserved words (keywords) that are already identified as either problematic or non-migratable. Oracle allows SQL
keywords to be used as identifiers whereas this is not allowed in ASE. For example, the following is valid PL/SQL:
CREATE TABLE case (begin VARCHAR2(100), when INT)
The following query finds all object names within the Oracle database that are ASE keywords:
select owner, object_name, object_type
FROM sys.dba_objects
WHERE object_name = UPPER('<ASE-keyword>')
The following query scans any PL/SQL object within the Oracle database for certain keywords and returns the name
and owner of the object as well as the object type for objects containing ASE keywords. This query retrieves the exact
code and line number of the occurrence within a stored procedure, function or trigger. Note that this could potentially
return a lot of output since the 'line' column may be long. Also note that these keywords could be part of comments or
string constants, in which case they can be ignored:
SELECT owner, name, type, line, text
FROM sys.dba_source
WHERE instr(UPPER(text), UPPER('<ASE-keyword>')) > 0
The queries above should be run for all Sybase ASE reserved words and keywords. The most practical way of running
these queries for all ASE keywords is to insert the ASE keywords in an Oracle table, and then run the above queries as a
join with this table.
For a complete list of reserved words and keywords in Sybase ASE, see “Adaptive Server Enterprise->Reference Manual:
Building Blocks->Reserved Words”. Reserved words can also be displayed with the following ASE query (but check
completeness against the ASE documentation!):
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Database Schema Migration 24
SELECT name FROM master..spt_values WHERE type = 'W'
4.9 Choosing a lock scheme for Sybase ASE tables
ASE offers a choice of three lock schemes for each database table: allpages, datapages or datarows.
allpages is the oldest lock scheme, as well as the out-of-the-box ASE default. It is slightly more efficient for some
types of operations. The datapages, and especially datarows, lock schemes provide fundamentally better
concurrency characteristics. The concurrency benefits are likely to be relevant when migrating from Oracle to Sybase
ASE due to the difference in transaction handling (as described in chapter 8).
It is recommended to configure datapages or datarows as the default lock scheme in Sybase ASE. datapages is
more efficient, but datarows provides better concurrency (datarows locking is also known as row-level locking).
Changing between datarows and datapages for an existing table is instantaneous. In contrast, large tables with the
allpages lock scheme may require long downtimes to if their lock schemes need to be changed to datarows or
datapages since this requires a full conversion of the table and all its indexes.
4.10 The Oracle DUAL Table
In Oracle, a SELECT statement must always be executed against a table, even when retrieving system information, such
as the current date/time. For this purpose, Oracle created the DUAL table. Retrieving the system date via SQL looks
like this in Oracle:
SELECT sysdate FROM DUAL
Sybase ASE supports SELECT statements that do not have a FROM clause. The same query in Sybase ASE would look
like this:
SELECT getdate()
To avoid rewriting existing SELECTs that use the DUAL table, it is possible to create a table named DUAL in ASE, which must always contain one and only row:
create table DUAL (dummy_col char(1) unique check (dummy_col='X'))
insert DUAL values ('X')
go
If Sybase ASE is created case-sensitive (see section 5.2), you may need to create additional tables named dual, Dual, etc, depending on how disciplined the Oracle developers were in using a consistent spelling for the DUAL table. Alternatively, consider editing the Oracle PL/SQL source code to use only "DUAL", or to remove all references to DUAL completely.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Migrating server-level aspects 25
5 MIGRATING SERVER-LEVEL ASPECTS
The architecture of the database server, and the way it is configured and managed, are quite different between Oracle
and Sybase ASE. This chapter lists some migration aspects that require attention, but without claim for completeness.
The reader is urged to consult the Sybase documentation, specifically the "System Administration Guide", for full details.
5.1 Character set
When creating a new Sybase ASE server, the character set to be used by the ASE server must be chosen. It is
recommended to use the same character for ASE, as is being used for the Oracle database.
While the character set in ASE can be changed at a later point in time, it is strongly recommended to avoid this, and to
pick the right character set before migrating any Oracle aspects to ASE.
5.2 Database server case sensitivity ('sort order')
A difference between Oracle and Sybase ASE is that Oracle is not case-sensitive, whereas Sybase ASE is case-sensitive
by default. ASE can be configured to be case-insensitive, by installing a case-insensitive 'sort order'.
Moreover, there is also a difference in the scope of case-insensitivity between Oracle and ASE:
In a case-insensitive ASE server, case-insensitivity applies to both identifiers and to data comparisons; SQL
keywords are always case-insensitive in ASE.
In Oracle, case-insensitivity applies only to identifiers (table names, column names, etc), but, by default, not to
data comparisons; it is likely that existing Oracle systems use this default. Note that the above applies only to
unquoted identifiers; quoted identifiers are case-sensitive in Oracle, though these are not used often.
As a result, the following two queries will retrieve different data in a case-insensitive Oracle system, but retrieve the same
data in a case-insensitive Sybase ASE:
select * from Employees where Name = 'Johnson'
select * from Employees where Name = 'JOHNSON'
Also, existing Oracle SQL code refers to the table TEST in different ways - the following all refer to the same table.
Inconsistent use of upper- and lower-case spelling for identifiers is not uncommon to occur in practical Oracle systems:
select * from TEST
select * from Test
select * from test
When using a case-insensitive sort order for Sybase ASE, such SQL statements do not need to be changed. When using
the default case-sensitive ASE sort order, all references to a table must use the exact same upper/lowercase spelling, or
"table not found" errors will result.
Whether the ASE server should be case-sensitive or case-insensitive is a decision to be made. For ASE, there is no
overriding technical advantage to either option.
In practice, the decision probably depends on whether query results may be affected by using a case-insensitive ASE
server. If this is the case, then the default case-sensitive ASE configuration should be used, and any Oracle SQL
statements referring to identifiers in mixed-case spelling (i.e. TEST and Test) should be changed to use one consistent
spelling for the identifiers.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Migrating server-level aspects 26
5.3 Server configuration parameters
In Oracle, the configuration parameters for the server and database are stored in the initialization file (init.ora) or
server parameter file (spfile). These parameters cover a diverse set of resources, such as memory, processes, network,
disk, I/O, connections, files, character set, and so on.
It is unlikely that Oracle configuration parameters can be mapped directly to corresponding configuration parameters for
Sybase ASE. It may however be useful to be aware of Oracle-specific configuration settings since in some cases some
kind of Sybase ASE equivalent could be required.
The non-default values of the Oracle parameters can be obtained using one of the following options:
Convert the server parameter file (spfile) to an initialization parameter file as follows:
CREATE pfile FROM spfile
Query the database by executing the following statement:
SELECT name, value FROM sys.v$spparameter
WHERE isspecified = 'TRUE'
5.4 Storage
Most Oracle installations enlist the help of Oracle‟s Automated Storage Manager (ASM). Sybase ASE does not have the
equivalent of ASM. Storage must be managed through T-SQL commands, Sybase Control Center , or via Sybase Central
(the Sybase database admin GUI tool).
Generally speaking, Sybase ASE recommends the following high-level guidelines for storage:
For user databases, use raw devices or filesystem devices with directio=true. Never use filesystem devices with
dsync=false for user databases; filesystem devices with dsync=true can be used but carry a potentially
significant performance penalty
For temporary databases, filesystem devices with dsync=false are generally recommended.
For the underlying storage layer, RAID 0+1 or RAID 1+0 is recommended. Avoid RAID 5 for write-intensive
purposes such as the ASE transaction log, unless the storage solution provides a non-volatile write cache to
buffer the writes.
To achieve maximum disk I/O bandwidth, read- and write-intensive data should preferably be spread over as
many physical spindles as possible.
Many additional considerations with respect to storage configuration apply. Please refer to the Sybase ASE "System
Administration Guide" for details.
5.5 Migrating the User Logins
There are some differences in terminology between Oracle and Sybase ASE around the concept of a "user".
In Oracle, on instance level: a user is used for authentication, and can also be a schema owner (and thus own
database objects, and have permissions on database objects)
In Sybase ASE, on server level: a login is used for authentication, but does not own any objects or have
object access permission.
A special ASE login is sa - this is the 'super user' in Sybase ASE, comparable to the SYS account in Oracle.
This user has access permissions on all database objects and should be restricted to the DBA. For security
reasons, applications should never use the sa login to connect to the ASE server.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Migrating server-level aspects 27
In Sybase ASE, on database level: a user, which maps to a login, can own database objects and have
permissions on database objects.
When migrating from Oracle to Sybase ASE, the most likely scenario is to migrate all Oracle application users to an
identically named Sybase ASE login. For each ASE login, a corresponding database user (typically with the same name as
the login) is then created to allow that login to access an ASE user database. A login can be given access to multiple ASE
databases by creating a corresponding database user in each ASE database.
Alternatively, the guest database user can be created in each ASE user database. However, related security implications
should be carefully assessed first.
The resulting structure of ASE logins and database users depends on decisions about how an Oracle schema is migrated
to ASE (see section 4.5).
5.5.1 User passwords
Each Oracle user has a password. In ASE, a login has a password. If the Oracle user passwords are known, they can be
set identically in ASE; otherwise, new passwords must be set for the ASE logins. ASE login passwords cannot be set to
blanks.
5.6 Permissions
It is recommended to use PowerDesigner 16 to reverse-engineer the permissions for accessing (objects in) the Oracle
database. If PowerDesigner 16 cannot be used, the permissions will likely have to be converted manually to the Sybase
ASE equivalent.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Data Migration 28
6 DATA MIGRATION
This section describes the methods for migrating data from Oracle to Sybase ASE. It is assumed that the schema has
already been migrated.
The main complicating factor is that Oracle provides no tools to unload a table to a flat file in a format that can be read
by non-Oracle tools.
Data migration can be performed in a number of ways. Therefore, when choosing an approach, various factors need to
be considered, including:
- the complexity of the chosen solution
- the volume of data being migrated
- the available system downtime to perform the data migration during cutover
- the need to become familiar with new software or tools for the purpose of migrating the data
- additional software license costs
In essence, the following options are available for data migration:
Unload Oracle data into ASCII-formatted flat files, and load these files into ASE with the Sybase "bcp" utility. If Oracle data can be exported into an ASCII-formatted flat file, then ASE's high-speed loading tool "bcp" can load it into ASE. Since Oracle does not provide a way to achieve this, the user must either use a 3rd-party tool for this purpose, or create his own PL/SQL utility to essentially spool the data from the database into a flat file. Considerations: This option is often seen as attractive due to the transparency of the migration process: all
steps are clearly visible and can be individually developed and tested. Developing your own PL/SQL tool to
unload Oracle data is simple, but will perform slowly, thus making it unsuitable for anything but relatively small
data volumes. Using a 3rd-party tool adds software license costs.
Use Sybase's Enterprise Connect Data Access (ECDA) Option for Oracle.
ECDA is a connectivity product by Sybase that enables direct connections from an ASE database into an
Oracle database, making it possible to transfer Oracle data directly into ASE. ECDA hooks into the ASE
mechanism of "proxy tables".
Considerations: This option can be used when the data volume is such that the data can be transferred in the
available migration window. It is unlikely to be suitable for very large data volumes. An advantage is that
ECDA takes care of mapping Oracle datatypes to ASE datatypes, and that the migration can be fully
performed through SQL.
Using this option requires purchasing Sybase's ECDA product.
Use Sybase Replication Server Heterogeneous Edition (RSHE) for Oracle
Sybase Replication Server captures database transactions in Oracle and applies these to ASE, thus keeping the
ASE database continuously up-to-date. In addition, Replication Server can also initially copy the full contents
of the Oracle tables into ASE, in order to initialize the data replication ("materialization of the replication
system").
Considerations: Using transactional replication is the only data migration solution where activity on the Oracle
database can continue while the data migration is in progress. This means that the migration downtime, during
which applications are not available because they must switch from the Oracle database to the ASE database, is
independent of the data volume being migrated; this downtime could potentially be very short (e.g. minutes
rather than hours).
Using this option requires purchasing Sybase's Replication Server product, as well as learning how to use
Replication Server.
Letting Replication Server perform the initial data copy from Oracle to ASE may not be realistic for large data
volumes. In this case, the initial materialization of the replication system might be better performed with one of
the other options mentioned here.
Use a 3rd-party ETL tool that supports both Oracle and Sybase ASE.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Data Migration 29
Considerations: This option is most attractive if the ETL tool is already in use so that no additional software
needs to be purchased for the migration alone.
an be used when the data volume is such that the data can be transferred in the available migration window. It
can be used for very large data volumes, but a sizeable migration window may be required.
6.1 Unload Oracle data into ASCII files; load into ASE with "bcp" utility
ASE's high-speed data loading utility "bcp" is capable of loading almost any type of appropriately formatted ASCII data
file into ASE. However, since Oracle does not provide any tools to export Oracle data into an ASCII-formatted file, the
user must either use a 3rd-party tool for this purpose, or create his own PL/SQL utility to essentially spool the data from
the database into a flat file. FACT is an example of such a 3-rd party tool.
6.1.1 Loading into ASE with "bcp"
This is an example of loading data from an ASCII file into an ASE table (named mydb..mytable) with bcp:
bcp mydb..mytable in mytable.txt –Ulogin –Ppassword –Sserver –c
In practical situations, bcp should also specify which row- and column delimiters are used (bcp -r and -t options) since
the defaults (CR and tab) could also occur in the actual data file (which is ASCII, after all). When unloading data into flat
ASCII files, proper delimiters should be chosen.
Bcp-in performance is best when all indexes on the tables being loaded, are dropped first. Of course, , depending on the
size and number of indexes and the width of the base tables, recreating them afterwards could take a long time on large
tables, so this may not be realistic for all cases.
It is usually best to use a large network packet size with bcp (the –A option; also requires configuring the network packet
size on the ASE server).
For large tables, it may be advisable to use the bcp –b option to break the load into multiple database transactions. This
is typically combined with enabling the "trunc log on checkpt" database option in ASE to avoid the transaction log
filling up.
To load only part of a data file, or to load columns in a different order than in the file, a so-called "bcp format file" may
be used. For more information on format files, as well as on bcp in general, see the Utility Guide in the ASE
documentation set (http://tinyurl.com/6883kx4).
It is highly recommended to perform multiple bcp operations in parallel (one for each table being loaded). The optimal
number of concurrent bcp operations will be determined by the hardware capabilities. If there is only one (or few) large
tables that need to be loaded, these can still be loaded using in multiple BCP operations by adding partitioning the table
using round robin partitioning and specifying the start and last rows of the data file being loaded into a particular
partition number of the table.
Lastly, note that, on Unix/Linux, bcp can read from a "named pipe" (created with the "mkfifo" command). If the utility
that extracts the data into a file can write to a named pipe as well, then a lot of time can potentially be saved as follows:
1. Create a named pipe with the Unix/Linux "mkfifo" command
2. Extract the data from Oracle, writing it to the named pipe.
3. Without waiting for the data extraction to complete, start bcp to load the data from the same named pipe. Bcp
will read data from the named pipe once it is delivered by the extraction utility, and immediately insert it into
ASE.
Instead of first extracting the data and then loading it, the time to transfer the data is now reduced to the longer of
(extracting the data, loading the data). This can represent significant time gain.
For more information on bcp and named pipes, please refer to http://tinyurl.com/5urcfrt .
6.1.2 Unloading from Oracle: FACT (3rd-party tool)
FACT ("Fast Extract") is a 3rd-party high speed Oracle data export tool that allows ASCII flat file creation, also in
parallel mode. These files can be used as input for the Sybase ASE utility bcp.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Data Migration 30
For more information about FACT, see http://www.iri.com/products/FACT.
6.1.3 Unloading from Oracle: Roll-your-own PL/SQL utility to export Oracle data
If you want to unload data from Oracle tables into ASCII flat files using only Oracle features, you must create your own PL/SQL utility that essentially spools the data from the database into a flat file. This uses the DBMS_OUTPUT.put_line command in PL/SQL. Here's an example of exporting two columns of table emp using "~" as a column delimiter and CR as a row delimiter. The output from this PL/SQL code should be captured in a flat file: DECLARE CURSOR emp_cur IS SELECT ename, sal FROM emp;
BEGIN
FOR emp_rec IN emp_cur
LOOP
DBMS_OUTPUT.PUT_LINE (emp_rec.ename || '~' || TO_CHAR (emp_rec.sal) );
END LOOP;
END;
/
The downside is that this method is likely to be very slow, making it unsuitable for anything but relatively small data volumes. In addition, care must be taken to correctly format/convert each column datatype management.
6.1.4 Unloading from Oracle: use Oracle SQL Developer
Oracle SQL Developer is a free Java-based tool, downloadable from oracle.com. This can be used to create a logical export of the data, whereby a SQL INSERT statement is created for every row. The downside is that this method is likely to be relatively slow in exporting as well as importing the extracted data, since this is all done on a single-row basis. This may make it unsuitable for large data volumes.
6.2 Use Sybase's Enterprise Connect Data Access (ECDA) Option for Oracle
ECDA is a connectivity product by Sybase that acts as a gateway between Oracle and Sybase ASE. With ECDA, direct
connections can be made from an ASE database into an Oracle database, making it possible to transfer Oracle data
directly into ASE using only SQL.
The ECDA functionality is exposed as an ASE "proxy table", which maps to the actual Oracle table. By selecting from
the proxy table, data is retrieved from the Oracle table and can be inserted directly into an ASE table. Also, it is possible
to do things like joining Oracle tables (though their proxy table) with tables in Sybase ASE.
The main advantage of using ECDA is that takes care automatically of the datatype conversions from Oracle to Sybase
ASE when the data is retrieved. It also offers the flexibility and control of using the SQL language to access to proxy
tables.
ECDA involves starting a separate process outside the ASE server.
6.2.1 ECDA Example
For examples of how to use ECDA in an Oracle migration context, see the document “Migrating an Oracle Database to
SAP Sybase ASE with PowerDesigner and ECDA (A Step-By-Step Practical Guide)” at
http://www.sybase.com/support/techdocs/migration.
6.3 Use Sybase Replication Server Heterogeneous Edition (RSHE) for Oracle
Sybase Replication Server is often used by Sybase customers to facilitate migrations between databases. The main
attraction is that the required downtime for curring over from the "old" to the "new" database can in principle be very
short as far as the database side of things is concerned.
6.3.1 Minimal migration downtime with Replication
Replication Server captures database transactions in Oracle by reading the Oracle redo logs, and then applies these
transactions to ASE, thus keeping the ASE database continuously up-to-date. In addition, Replication Server can also
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Data Migration 31
initially copy the full contents of the Oracle tables into ASE, in order to initialize the data replication ("materialization of
the replication system"). When large tables are involved, a main decision to be made is whether this initial materialization
needs to be performed through Replication Server or through an external unload-and-load mechanism.
When using Replication Server for data migration, the objective is to reach a state where the ASE database is completely
in synch with the Oracle database, at which point the applications can switch from the Oracle database to the ASE
database (after the cutover, the replication setup can be removed). The system downtime needs to be only as long as this
application cutover takes, which would typically rather be minutes rather than hours.
It is essential to observe that replication is application-transparent: applications can keep working normally on the Oracle
database until the moment of cutover comes (obviously, the applications themselves likely require modifications to run
on an ASE database instead of Oracle, but that is outside the scope of this topic of data migration).
Other data migration solutions than transactional replication will require significantly more downtime. This is because
Replication Server provides a mechanism to incrementally upload data changes from Oracle to ASE allowing
applications continue to work normally. In contrast, most other migration methods essentially take a copy of an entire
table which usually requires applications to be shut down or in read-only mode since it can be very difficult to reconcile
any data changes to the copied afterwards. For those other migration methods, the required system downtime is
therefore roughly identical to the time required to copy the data out of Oracle and into Sybase.
6.3.2 Initial materialization for the replication setup
Replication Server can automatically copy the full contents of the Oracle tables into ASE, in order to initialize the data
replication ("materialization of the replication system"). However, for very large tables, this may take unacceptably long.
An alternative approach may therefore be to take an initial copy from these large tables through other means, like one of
the other options described in this section on data migration (for example, unload into an ASCII flat file and load into
ASE with bcp). With Replication Server, changes made to the table afterwards will be synch'd afterwards. The high-level
approach would be as follows:
1. Set up table replication for all Oracle tables to ASE tables, but do not auto-materialize the large tables.
Optionally, enable "autocorrection" for the large tables (depending on your understanding of the type of data
changes that may be made; see the Replication Server documentation for details).
2. Suspend the DSI connection by Replication Server to the ASE database. Any future changes to the Oracle
tables will be picked up by Replication Server and are accumulated in Replication Server's "stable queues". At a
later point, these changes will be applied to ASE.
3. For the large tables, take a copy and load this into ASE (using your preferred method).
4. Once the loading of the large tables into ASE is complete, resume the connection from Replication Server to
the ASE database. This will push out the changes that were accumulated in Replication Server's "stable
queues", and apply these to the ASE tables.
5. Once all accumulated changes are pushed out to ASE, the ASE database should be in the same state as the
Oracle database and the applications can switch over to complete the migration.
When the tables are not too large to perform automatic materialization, or when it is acceptable that such materialization
takes a long time (since the Oracle applications keep functioning normally anyway), then the above steps can be replaced
by simple setting up table replication from Oracle to ASE using automatic materialization.
6.3.3 Other considerations
Using this option requires purchasing Sybase's Replication Server Heterogeneous Edition (RSHE) for Oracle, as well as
learning how to use Replication Server. Letting Replication Server perform the initial data copy from Oracle to ASE
may not be realistic for large data volumes. In this case, the initial materialization of the replication system might be
better performed with one of the other options mentioned here.
Before using Sybase Replication Server to replicate out of an Oracle database, verify whether this complies with the
available Oracle licenses. If a full Oracle license is used, there should be no restrictions; if a more restricted Oracle
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Data Migration 32
license is used (like a run-time only license), this might legally prohibit use of Replication Server and additional Oracle
licensing might be needed. This is a matter outside the scope of Sybase, and should be addressed with Oracle.
Oracle GoldenGate can also provide transactional replication between Oracle and Sybase ASE. If the customer already
has this product available, in principle this can also be used as part of a migration, in similar ways as described above for
Sybase Replication Server.
6.4 Use a 3rd-party ETL tool that supports both Oracle and Sybase ASE
If an ETL tool is already in use which supports both Oracle and Sybase, it may be attractive to use it to perform the data
migration. Typically this would require system downtime for the duration of transferring the data from Oracle to Sybase,
unless the ETL tool is capable of sorting out any changes to the data that are made during the transfer process.
Please make sure that you adhere to any license restrictions and clear the use of this tool to move data from Oracle to
Sybase ASE with this vendor.
6.5 Oracle datatypes requiring special attention for migration
The following Oracle datatypes require special attention when migrating the data.
Oracle TIMESTAMP Sybase BIGDATETIME
Oracle‟s TIMESTAMP datatype has a granularity of 1/100000000th of a second. This exceeds the precision of
Sybase‟s BIGDATETIME datatype which has a granularity of 1 microsecond. When migrating data with bcp,
TIMESTAMP data may need to be edited to remove the last 3 digits to avoid bcp throwing an error.
Oracle BLOB/CLOB/NCLOB Sybase IMAGE/TEXT /UNITEXT
Oracle stores large binary objects in the BLOB datatype and large character objects in the CLOB datatype. Both
datatypes can store up to 128TB (4GB * database block size) of data, as of Oracle 11g. When migrating, data from
Oracle‟s BLOB datatype should be mapped to Sybase IMAGE datatype and CLOB to the TEXT datatype. The
maximum size for an individual column value of the IMAGE or TEXT datatype in Sybase ASE is 2GB. If the
actual Oracle data values are larger than this maximum, ASE is unable to store these values. In this case, Sybase IQ
might be a solution since it supports a maximum varying between 512TB to 2PB per column value.
Oracle BFILE
The Oracle BFILE datatype is used to store a locator (link) to an external binary file stored outside of the database.
Sybase ASE has no direct functional equivalent, so application changes may be required.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Migrating PL/SQL to Transact-SQL 33
7 MIGRATING PL/SQL TO TRANSACT-SQL
PL/SQL is Oracle's implementation of the SQL language. Transact-SQL (T-SQL) is Sybase ASE's SQL dialect.
Both SQL versions are mostly ANSI-92 entry-level compliant, but both vendors have implemented extensive non-
ANSI-compliant vendor-specific enhancements and extensions.
In many cases both dialects will still have equivalent functionality in their vendor-specific extensions, but syntax changes
or varying amounts of code changes may be required when migrating from PL/SQL to T-SQL. In cases where T-SQL
does not have a direct equivalent of a particular PL/SQL construct, larger amounts of code rewrite or even application
rewrite could be required.
While the incompatibilities between Oracle and Sybase are quite limited when it comes to schema migration and data
migration, there is much more potential for migration complexity between the two SQL dialect. Consequently, migrating
PL/SQL to T-SQL is probably the most involved part of any Oracle to Sybase migration, and will typically require
manual conversion/migration activity.
A key factor for a successful migration –or, for that matter, for avoiding a failed migration- is a realistic assessment of
the SQL-related complexities to be migrated before starting the migration project. Chapter 3 provides checklists for this
purpose.
To assist with the actual migration of PL/SQL to T-SQL, chapter 11 contains a cross-reference between Oracle features
and their Sybase ASE equivalents, in three categories of complexity. This cross-reference is an extended version of the
Oracle checklist in chapter 3 but provides more detail and provides specific suggestions on how to migrate a specific
Oracle feature to ASE.
7.1 Locations of PL/SQL code
PL/SQL code can be found in the following locations:
Stored procedures (in the database server)
Triggers (in the database server)
SQL functions (in the database server)
SQL queries (submitted to the database server by client applications, for example as anonymous PL/SQL blocks)
PL/SQL objects in the database server can be reverse-engineered, or, if present and up-to-date, repository scripts that were used to create these PL/SQL objects can be taken as a starting point. PL/SQL code located in client applications needs to be identified in a different way, for example source code inspection When it comes to using existing scripts or reverse-engineering the PL/SQL objects from the database server, the same considerations apply as with respect to the database schema; see the pros and cons discussed in section 4.1. Sybase PowerDesigner may also be used to reverse-engineer PL/SQL objects (see section 4.2); however PowerDesigner does not perform any conversion to T-SQL (for this, evaluate tools as in section 7.2 below). Since the majority of PL/SQL is typically located in stored procedures and triggers, "migrating PL/SQL" is often equated to "migrating stored procedures and triggers". While that definition is not formally correct (there are other places where PL/SQL occurs, as shown above), it does reflect the area where most migration issues are typically encountered.
7.2 3rd-party tools for PL/SQL migration to T-SQL
Tools for migrating from PL/SQL to T-SQL would be a welcome help when undertaking Oracle to ASE migrations.
However, it is unlikely that any automated tool will be capable of perfectly migrating all of the PL/SQL code in any real-
life Oracle system to ASE's T-SQL. Yet, it may well be possible that a substantial percentage can be handled by a tool,
but a certain amount of manual conversion/migration should be expected.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Migrating PL/SQL to Transact-SQL 34
SwisSQL and SQLWays (both 3rd-part tools) are among the few tools that provide assistance with automatic migration
of Oracle PL/SQL code to Sybase T-SQL. For more information, see www.swissql.com (SwisSQL) and
www.ispirer.com (SQLWays).
It should be noted that for both tools, support for ASE features in general, and new features in ASE 15.0 and later in
particular, appears to be limited. It is recommended to carefully evaluate these tools before using them for PL/SQL
migration.
Please note that the above neither constitutes an endorsement by SAP/Sybase of either SwisSQL or SQLWays, nor a
statement about the suitability of these tools for any specific project or purpose.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Transactions and Locking, Oracle vs. Sybase 35
8 TRANSACTIONS AND LOCKING, ORACLE VS. SYBASE
The topic of transaction handling, transaction isolation and locking is probably where the most profound differences
between Oracle and Sybase ASE occur. For this reason a separate chapter is dedicated to this topic.
8.1 Oracle MVCC vs. Sybase locking
The purpose of transactions in the database is to take the database from one consistent state to the next. Database
transactions, both in Oracle and Sybase ASE, guarantee all of the ANSI-defined ACID characteristics. ACID is an
acronym for:
Atomic: Either all of the modifications in the transaction are applied or none is applied.
Consistent: A transaction takes the database from one consistent state to the next, observing referential
integrity constraints.
Isolated: The effects of a user's transaction are not visible to other users until the transaction is committed.
Durable: Once the transaction is successfully committed, it is permanent.
Oracle's implementation of the "Isolation" aspect of transactions is different from Sybase ASE's. Oracle uses MVCC
(multi-version concurrency control) where an open transaction creates a new version of the data it is modifying, such
that other sessions reading the same data will read the unmodified version, and thus are not blocked ("writers don‟t
block readers and readers don't block writers"). In contrast, Sybase ASE maintains only a single version of the data, and
uses blocking locks to implement transaction isolation.
Oracle also uses locking in addition to MVCC, but Oracle's locking concept is rather different from ASE's.
8.2 Transaction-related migration issues
The different approaches towards transaction isolation by Oracle and Sybase ASE may bring up the following issues
when migrating from Oracle to ASE:
Oracle applications and queries may rely, knowingly or unknowingly, on Oracle MVCC's "writers don't block
readers and readers don't block writers" behavior. When migrating such queries unchanged to Sybase ASE,
concurrency problems (blocking) may result. In addition, since MVCC has the effect that the result of an
Oracle query is essentially defined at the moment then the query starts, different results could potentially be
returned.
Long-running transactions: these are fine, and indeed common, in Oracle where MVCC allows transactions to
remain open for longer times with fewer adverse effects (though naturally, this also has its limits; for example
writers still block writers). With Sybase ASE designed specifically for high-performance OLTP, transactions
should be kept as short as possible in ASE for best concurrency and performance. Long transactions in ASE
can quickly lead to issues around concurrency (blocking) and resource consumption which also affects
unrelated transactions by other users (transaction log full).
Oracle uses implicit transactions (also called "chained transactions"). This means a transaction is started
automatically whenever a SELECT, INSERT, UPDATE or DELETE statement is executed. By default Sybase
ASE uses explicit transactions ("unchained"), though it also supports the ANSI-compliant implicit/chained
mode as well. When migrating to ASE, it may be needed to run some transactions in chained mode which
could involve making changes to the way some transactions are handled, notably changing the transaction
mode at session or client level, or by adding explicit BEGIN TRANSACTION statements (which Oracle does
not support nor require).
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Transactions and Locking, Oracle vs. Sybase 36
For a successful migration to Sybase ASE, it is crucial to have a thorough understanding of the behavior of the Oracle
application on the above aspects, and of the assumptions behind the design of queries and transaction handling in the
Oracle application.
8.3 Using ASE implicit/chained transaction mode
The most straightforward migration option with respect to Oracle's implicit/chained transaction mode is to retain the
transactional structure of the Oracle application, and operate Sybase ASE in chained transaction mode.
In Sybase ASE, implicit/chained transaction mode can be achieved by:
Running the T-SQL command SET CHAINED ON before starting a transaction. This statement can also be
executed in an ASE login trigger.
Setting the OpenClient connection attribute CS_OPT_CHAINXACTS to true (default=false) in the client
application before connecting to the ASE server (With the isql utility, this attribute is set by specifying the -Y
command-line flag).
Since some operations in Sybase ASE may not work in chained mode, for example administration procedures such as
sp_configure, always enabling chained mode for all connections may not be practical (although ASE 15.7 allows
various system sp_* procedures to run in chained mode). It is recommended to only enable chained mode for those
connections or stored procedures that really require it. For connections by the DBA (typically, the 'sa' user), the
default unchained mode should always be used instead.
8.3.1 Transactional DDL
When running Sybase ASE in chained mode, it is possible that, with a straightforward migration from Oracle, DDL statements are executed inside a transaction. By default, this will cause an error in Sybase ASE. To allow DDL statements in a transaction in ASE, run: sp_dboption database_name,'ddl in tran', true . Note that this is not possible for some types of DDL.
In addition, Oracle issues an implicit COMMIT after each DDL statement. In ASE, an explicit COMMIT statement should be inserted after each DDL statement that runs in a transaction to avoid concurrency issues. Alternatively, chained mode should temporarily be turned off at session level when DDL is executed.
8.3.2 Transaction processing in stored procedures
If transaction processing is performed inside stored procedures, and the transaction mode (chained/unchained) matters,
Sybase ASE optionally allows enforcing that a stored procedure is executed only in chained or unchained mode (or
either mode). This can be achieved with sp_procxmode:
sp_procxmode proc_name, { 'chained' |'unchained' | 'anymode' }
8.4 Using ASE explicit/unchained transaction mode
If it appears that running ASE in implicit/chained transaction mode leads to too many concurrency issues, consider
using the default ASE explicit/unchained mode instead for all transaction or only for selected transactions.
When using unchained transaction mode, a BEGIN TRAN[SACTION] statement needs to be added to all transactions
that will run in unchained mode (this statement is not required in chained mode where transactions start implicitly). To
determine the best location to add BEGIN TRANSACTION requires detailed understanding of the transaction in
question. In general it is recommended to keep transaction in ASE as short as possible.
8.5 Using ASE transactional concurrency enhancements
Oracle's MVCC feature tends to be seen, especially by Oracle itself, as a vastly superior and irreplaceable transaction
handling model, compared with other database brands.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Transactions and Locking, Oracle vs. Sybase 37
In reality, much of the concurrency benefits of MVCC can be achieved in Sybase ASE by using ASE-specific features.
What is true is that concurrency issues caused by sub-optimal transaction/query design will be less immediately visible in
Oracle than in ASE; consequently, discipline in transaction programming is more important in Sybase ASE than in
Oracle since sloppy transaction handling backfires quicker in Sybase ASE than in Oracle.
When migrating from Oracle, it is recommended to consider the use of the following ASE features:
Choose the datapages or datarows lock scheme for database tables. These lock schemes provide better
concurrency than the default of allpages which is likely to be relevant when migrating from Oracle to ASE (also
see section 4.9). When using datarows locking, uncommitted inserts do not block readers; in addition, "pseudo-
column-level locking" behavior will automatically apply in certain scenarios (see the ASE Performance and Tuning
manual, volume "Locking and Concurrency Control" for details).
Consider using the readpast feature in queries. When reading data, this lets the query skip over locks that would
otherwise have blocked the read operation. For example:
select * from mytable readpast where mykey = 123
When using readpast, the data page (with datapages lock scheme) or data row (with datarows) being locked
and skipped over, will not be read. In many cases however, this may be acceptable because the nature or timing of
the query is such that the data being looked for is known not to be accessed by other users anyway. Or the skipped
data is known not to have any impact on the query result anyway.
Consider using the ANSI transaction isolation level 0 (ANSI READ UNCOMMITTED) in SELECT queries. While
reading, this lets the SELECT query read data that is currently locked, and potentially being updated, by another
user's transaction. On the default ANSI transaction isolation level 1 (READ COMMITTED), the SELECT query
would be blocked instead.
When using ANSI isolation level 0, it is important to be aware of the implications and potential downsides, such as
requirements for unique indexing, the risk of isolation level 0 select queries being aborted in certain scenarios (see
the see the ASE Performance & Tuning manual, volume "Locking and Concurrency Control" for details).
Also, since isolation level 0 does not provide true transaction isolation, there is the risk of reading data that is
currently being updated and which may be updated again, or rolled back, after being read. However, this may be
acceptable because the uncommitted data being read is known not to have any impact on the query result anyway.
When using transaction isolation level 0, it is strongly recommended not to set this as the default isolation level for a
session, but to add the clause AT ISOLATION READ UNCOMMITTED or AT ISOLATION 0 only to those SELECT
statements where isolation level 0 is required.
8.6 Other transactional aspects
Savepoints: Sybase ASE supports savepoints in the same way as Oracle though with slightly different syntax.
By default, Oracle operates on transaction isolation level 1 (READ COMMITTED), which is the same as Sybase
ASE. Oracle also supports transaction level 3 (SERIALIZABLE). Sybase ASE supports both isolation levels as well.
(Note that Oracle does not support isolation levels 0 and 2).
SQL*Plus commit behavior:
o Oracle's SQL*Plus always commits when exiting normally. Sybase's isql client does not commit when it
exits, and consequently the effect would be that any open transaction is rolled back – which is the opposite
of Oracle's SQL*Plus behavior.
o Oracle's SQL*Plus can be configured to autocommit after every statement with SET AUTOCOMMIT ON;
by default, this is disabled.
Sybase's isql client does not support autocommit; to achieve the same effect, explicit COMMIT
statements should be inserted.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Transactions and Locking, Oracle vs. Sybase 38
Oracle supports the syntax SET TRANSACTION READ ONLY, which makes the data read during the transaction transactional data read-only, thus achieving the almost the same effect as transaction isolation level 3 (SERIALIZABLE).
In Sybase ASE, this should be changed to using transaction isolation level 3 (SERIALIZABLE). This can be achieved with either of the following syntax:
o SET TRANSACTION ISOLATION LEVEL 3
o SELECT … AT ISOLATION LEVEL 3
Instead of ISOLATION LEVEL 3, ISOLATION LEVEL SERIALIZABLE can also be used.
Oracle also supports the syntax SET TRANSACTION READ WRITE; this can be removed when migrating to Sybase
ASE since it is the default transactional behavior.
Deadlocks: Oracle sometimes pictures other database brands that do not support MVCC, as a source of 'deadlocks',
perhaps aiming to use this somewhat scary-sounding terminology as an argument against their competitors.
Indeed, deadlocks are rare in an Oracle environment, although it should be noted (consult any computer science
textbook on concurrent computing) that the possibility of deadlocks can never be excluded in a multi-user
environment – which includes Oracle databases.
When following some elementary best practices, deadlocks typically do not occur at all, or very rarely at worst, in
Sybase ASE. The main guideline to avoid deadlocks is that when different transactions each access multiple tables,
they should always do so in the same order. In addition, using the ASE datarows lock scheme will help to reduce
the chance of deadlocks occurring. Finally, in the rare occasion that deadlocks do occur, it is recommended to
implement deadlock retry logic into the application where possible.
In summary, deadlocks need not be a major point of concern when migrating from Oracle to Sybase ASE.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Miscellaneous migration aspects 39
9 MISCELLANEOUS MIGRATION ASPECTS
9.1 Cursors
A main difference between Oracle and Sybase ASE is on how the systems handle query results. In Sybase ASE, result
sets are handles using „set processing‟, meaning that in a stored procedure result sets are typically stored in temporary
tables and then further refined, whereas Oracle is based on cursor processing navigating through result sets. The
underlying reason is that Oracle maintains the versioning of its transactions and guarantees data integrity through
cursors. By using insensitive cursors in Sybase ASE, the same effect for the cursor result set is closest Oracle‟s cursor
implementation.
Both Oracle and Sybase ASE support cursors, with some –mostly small- differences in syntax and semantics.
Oracle PL/SQL is implemented with an implicit cursor deallocation process. When you close an Oracle cursor, it gets
automatically deallocated. Sybase ASE requires an explicit deallocate cursor statement to do so.
"REF CURSOR" is an Oracle datatype. Parameters and variables can be created with this datatype (called "cursor
variables"). A cursor variable acts as a pointer to a result set, and can be associated with different queries at run-time and
passed around between stored procedures, functions etc. Thus a cursor variable can be opened in one stored procedure,
and the results fetched in another stored procedure, whereby the cursor variable is passed between both procedures.
Since ASE does not have the REF CURSOR concept, PL/SQL using REF CURSOR needs to be rewritten, for example
by rewriting all stored procedures involved, or by putting query results in (temporary) tables and let the different stored
procedures access these.
9.2 Sequences
Sybase ASE does not have a full equivalent of Oracle Sequences, but in most cases similar functionality can be achieved by using either an ASE identity column or a key counter table. A main criterium is whether the sequence values must be transactional (i.e. the sequence-generated value is rolled back when the enclosing transaction rolls back). If such transactionality is required, a key counter table must be used. If this is not required, then an identity column can be used.
Oracle code:
CREATE SEQUENCE test_seq
MINVALUE 1
STARTWITH 1
INCREMENTED by 1
CACHE 20;
INSERT INTO m_table VALUES (test_seq.nextval,…);
Equivalent Sybase ASE code with identity column:
-- this example uses an int as the sequence counter. Use numeric or bigint as needed.
CREATE PROCEDURE init_seq_nr (@seqtab varchar(30), @startwith int=1, @cache int=100)
AS
BEGIN
set nocount on
DECLARE @s varchar(100), @v int
if object_id('seqtab') is not null
begin
set @s = 'drop table seqtab'
exec (@s)
end
set @s = 'create table ' + @seqtab + '(seq int identity) with identity_gap = ' +
convert(varchar, @cache)
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Miscellaneous migration aspects 40
EXEC (@s)
if @startwith > 1
begin
select @v = convert(int, reserve_identity (@seqtab, @startwith - 1))
end
end
go
-- you can use either the output parameter or the return value,
-- though the return value can only be an 'int' datatype
-- NB: the values generated here are not transactional (they cannot be rolled back)
CREATE PROCEDURE get_seq_nr (@seqtab varchar(30), @incremented_by int, @v_out int output)
AS
BEGIN
set nocount on
DECLARE @s varchar(100), @v int
set @v = convert(int, reserve_identity (@seqtab, @incremented_by))
set @v_out = @v
return @v
end
go
-- Initialize the sequence table
EXEC init_seq_nr 'myseqtab', 1, 20
go
-- Now get the next sequence number
-- you can use either the output parameter or the return value,
-- though the return value can only be an 'int' datatype
-- NB: the values generated here are not transactional (they cannot be rolled back)
-- variant 1: use output parameter
DECLARE @p_out int
EXEC get_seq_nr 'myseqtab', 1, @p_out output
INSERT INTO my_table VALUES (@p_out,…)
go
-- variant 2: use return value
DECLARE @ret int
DECLARE @p_notused int
EXEC @ret = get_seq_nr 'myseqtab', 1, @p_notused
INSERT INTO my_table VALUES (@ret,…)
go
Equivalent Sybase ASE code with key counter table:
-- create table
CREATE TABLE my_seq (seq int)
go
-- initialize the sequence
INSERT INTO my_seq select 0
go
-- create stored procedure to increment and return the value
–- note that this can also be done with an OUTPUT parameter
CREATE PROCEDURE get_seq (@incr int)
AS
UPDATE my_seq SET seq = seq + @incr
SELECT @seq = seq FROM my_seq
RETURN @seq
go
-- execute the procedure to get the next sequence number
DECLARE @seq int
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Miscellaneous migration aspects 41
EXEC @seq = get_seq 1
INSERT INTO m_table VALUES (@seq,…)
go
Notes:
When using a step count > 1 in ORacle (= 'incremented by' > 1), the ASE configuration parameter 'identity
reservation size' must be set to the maximum block size (with sp_configure)
The Oracle sequence attributes 'cycle', 'minvalue', 'maxvalue' and 'noorder' are not easy to support in ASE. To
implement 'cycle', the identity counter can be set backwards with sp_chgattribute ..., 'identity_burn_max'.
Yet another approach is to replace the sequence functionality with a static Java function which is visible across all
processes (i.e. loaded by the system ClassLoader). This is not discussed further in this Guide.
9.3 Error/Exception handling
In Oracle, each SQL statement is automatically checked for errors before proceeding with the next statement. If an error
occurs, control immediately jumps to an exception handler if one exists. PL/SQL supports the creation of custom
exception handlers to deal with different types of errors. Sybase ASE passes the control from one SQL statement to
another without checking for errors. This means that in Sybase ASE, error checks must be performed after every SQL
statement.
The Oracle built-in procedure RAISE_APPLICATION_ERROR notifies the client of the server error condition and
returns immediately to the calling routine. Oracle places an implicit SAVEPOINT at the beginning of a procedure. The
built-in RAISE_APPLICATION_ERROR procedure rolls back to this SAVEPOINT or to the last committed
transaction within the procedure. Control is then returned to the calling routine.
Sybase ASE‟s equivalent to Oracle‟s RAISE_APPLICATION_ERROR is called RAISERROR. Unlike Oracle,
RAISERROR does not return the controls to the calling routine.
The first step in the conversion is to replace all RAISE_APPLICATION_ERROR calls with RAISERROR calls,
followed immediately with a RETURN statement to emulate the Oracle exception handling.
The second step is to handle the implicit SAVEPOINTs that Oracle creates at the beginning of each procedure. If the
transaction is within one procedure this is relatively simple. But if the code uses nested stored procedures this becomes
more complex and may require additional flow-control logic.
9.4 Outer join limitations
Sybase ASE does not allow another join relationship on a table that already has an outer join (see example #1 below). In
addition, for a query with an outer join and a qualification on a column from the inner table of the outer join, the results
may be different than expected (example #2). Ideally, the database design should be de-normalized to remove the need
for these relationships. It is generally recommended to use the ANSI outer join syntax in Sybase ASE rather than the T-
SQL style syntax (*=. =*).
Oracle Sybase ASE
Example #1: SELECT DISTINCT a.id, b.name, c.desc
FROM a, b, c
WHERE a.id = b.id (+)
and b.id2 = c.id2 (+) ( or b.id = c.id2 )
and a.code = 1
ORDER BY b.name
Example #1: SELECT a.id, b.name, c.desc
FROM a, b, c
WHERE a.id = b.id
and b.id2 *= c.id2
and a.code = 1
UNION
SELECT a.id, '', ''
FROM a
WHERE a.code = 1
and ( NOT EXISTS ( SELECT 'X'
FROM b
WHERE a.id = b.id ))
ORDER BY 2
Example #2: SELECT a.id, b.name
Example #2: SELECT a.id, b.name
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Miscellaneous migration aspects 42
Oracle Sybase ASE FROM a, b
WHERE a.id = b.id (+)
AND b.name LIKE 'Bill%'
FROM a, b
WHERE a.id *= b.id
AND b.name LIKE 'Bill%'
9.5 Migrating JDBC/ODBC/… Applications
The data and any SQL code that are stored in the database (e.g., stored procedures and triggers) are migrated with the
steps in Section 5. This section describes the following different types of client database applications that need to be
migrated from Oracle to Sybase ASE.
Embedded SQL application
ODBC client application
JDBC client application
Database-specific library application
C Applications
Oracle forms
In all cases, conversion of one type of application to any of the other types of applications is possible. For example,
instead of converting your Oracle Embedded SQL application to a Sybase Embedded SQL application, you can convert
your Oracle Embedded SQL application to a JDBC client application.
9.5.1 JDBC
Migrating JDBC connections from Oracle to Sybase requires understanding how Oracle manages JDBC drivers vs.
Sybase ASE. This will determine your approach on how to migrate JDBC.
Oracle provides the following JDBC drivers:
Thin driver: a pure Java driver used on the client-side, without an Oracle client installation. It can be used with
both applets and applications.
Oracle Call Interface (OCI) driver: used on the client-side with an Oracle client installation. It can be used only
with applications.
Oracle recommends the use of its Thin JDBC driver in all and any cases when connections are made through TCP/IP.
Sybase ASE provides its own JDBC driver, named jConnect.
9.6 Oracle Forms
Oracle Forms, a component of the Oracle Developer Suite, is Oracle's approach to design and build enterprise
applications quickly and efficiently. Oracle Forms-based applications can retrieve and manipulate data in Oracle
databases. Applications developed with Oracle Forms are unlikely to run well, or run at all, against Sybase ASE.
Sybase PowerBuilder is an enterprise development tool that allows you to build many types of applications and
components. It is one of a group of Sybase products that together provide the tools to develop client/server, multi-tier,
and Internet applications.
Oracle Forms applications can be rewritten using PowerBuilder. Most of the functionality provided by Oracle forms can
be also be created by using PowerBuilder with Sybase ASE.
Migration of Oracle Forms application to PowerBuilder application is not straightforward. The "form" is the basis of
user interface (UI) in Oracle Forms while the "datawindow" is the basis of UI in PowerBuilder. Both are graphical in
nature and are used to present data and accept user input. Both can contain elements graphical and non-graphical in
nature.
For more information on PowerBuilder, see http://www.sybase.com/powerbuilder .
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
DBA Tasks Cross-Reference 43
10 DBA TASKS CROSS-REFERENCE
This chapter seeks to provide some starting points with respect to mapping DBA tasks and concepts in Oracle to their
equivalent in ASE. However, the tools and methods used for database administration and monitoring are very different
as these are highly specific to each database brand. This makes it impossible to provide more than a loose mapping.
For a successful migration, availability of sufficient DBA skills will be important.
Description Oracle Sybase ASE
Home Directory $ORACLE_HOME $SYBASE
Default Database/Instance $ORACLE_SID $DSQUERY
Command-line tool for SQL SQL*Plus in $ORACLE_HOME/bin/sqlplus
isql in $SYBASE/OCS-15_x/bin/isql
Import/export data imp / exp command or impdp
/expdp command for data pump
located in $ORACLE_HOME/bin
Oracle imports and exports the data and the DDL definitions, plus all other objects like type definitions, indexes, procedure and views.
Data exported with exp can only be
imported with imp.
For data import and export:
bcp command located in $SYBASE/OCS-15_x/bin
For the definition import and export:
defncopy command in $SYBASE/OCS-15_x/bin
To reverse engineering the DDL to be recreated in another environment:
ddlgen command in $SYBASE/ASEP/bin
Loading data from external files SQL*Loader is Oracle‟s high-speed loader. It loads data into Oracle very fast, but it cannot unloading Oracle database data into files.
bcp command located in $SYBASE/OCS-15_x/bin
(bcp can also unload data into files)
Create a new database dbca command in $ORACLE_HOME/bin
Sybase Central or SQL command create database
Create new network connection netca command in $ORACLE_HOME/bin
dsedit in $SYBASE/OCS-15_x/bin
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
DBA Tasks Cross-Reference 44
Description Oracle Sybase ASE
Setup new Oracle Enterprise Manager (OEM) server
emca command in $ORACLE_HOME/bin
Sybase Central in combination with Sybase Control Center is equivalent to OEM.
Setup Sybase Central: installed automatically when Sybase ASE is installed. Installs as part of the client installation.
Setup Sybase Control Center: Install the software with the supplied Sybase Installer.
Load data into the database SQL*LOADER in $ORACLE_HOME/bin/sqlldr
bcp command located in $SYBASE/OCS-15_x/bin
using bcp in
Start database server Manual:
Start SQL*Plus as sysdba
SQL> STARTUP
Starts the instance, , mounts the database and opens the database.
Script:
dbstart command in $ORACLE_HOME/bin
Both commands are using the spfiles
located in $ORACLE_HOME/dbs in the following order:
1. spfile$ORACLE_SID.ora
2. spfile.ora
3. init$ORACLE_SID.ora
startserver command in $SYBASE/ASE-
15_x/install
startserver –f
RUN_$DSQUERY
The RUN_$DSQUERY file is the spfile equivalent.
Start backup server N/A startserver command in $SYBASE/ASE-
15_x/install
startserver –f
RUN_$DSQUERY_BS
The RUN_$DSQUERY_BS file contains the startup parameters.
Start monitor server emctl command in
$ORACLE_HOME/bin
emctl start dbconsole
startserver command in $SYBASE/ASE-
15_x/install
startserver –f
RUN_$DSQUERY_MS
The RUN_$DSQUERY_MS file contains the startup parameters.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
DBA Tasks Cross-Reference 45
Description Oracle Sybase ASE
Show running processes Unix: ps –aef | grep
$ORACLE_SID
Windows: pslist –d oracle
showserver command in $SYBASE/ASE-
15_x/install
Stop database server Login to SQL*Plus and execute:
SQL>shutdown
For normal shut down
SQL>shutdown immediate;
For immediate shut down
SQL>shutdown abort;
For emergency shut down
Login via isql and execute the command:
shutdown
go
Without parameters the server will wait for all transactions to finish. Adding „with nowait‟ will terminate all sessions and shut down the server immediately.
Stop backup server Oracle does not have a concept of a Backup Server.
Login via isql into the Sybase ASE database server and execute the command:
shutdown
Backup_Server_name
go
By default this waits for all current backups to finish. Adding „with nowait‟ will terminate all sessions and shut down the backup server immediately.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
DBA Tasks Cross-Reference 46
Description Oracle Sybase ASE
Database Backup Oracle has the following ways of
performing a database backup:
imp / exp commands: this can
import/export the entire database
(including all data), individual
schemas or a single table.
Data Pump: new import / export
feature since Oracle 10g. The basic
functionality is identical to the old
imp and exp commands, but
Data Pump is faster.
RMAN: The Oracle Recovery
Manager (RMAN), command-line
as well as Enterprise Manager-
based, is the Oracle-preferred
method of efficiently backing up
and restoring an Oracle database.
Various backup options exist,
some of which require the Oracle
database to be shut down first.
Sybase ASE always performs a hot
backup; this requires hardly any
configuration. This is the same
functionality as Oracle‟s Archive
Log backup, but no archive file
cleanup is necessary.
The command dump database
backs up an entire database (full
dump); dump transaction
only backs up the transaction log
since the previous dump
(incremental backup).
The command load database
restores a full backup; load
transaction loads an
incremental backup following loads
of earlier backups.
For these dump/load commands,
Backup Server must be running.
Information about system performance
Oracle dynamic performance views MDA tables
Information about schema Oracle static data dictionary views System tables (catalogs) and system
stored procedures (sp_*)
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 47
11 ORACLE-TO-SYBASE MIGRATION CROSS-REFERENCE
This chapter provides specific suggestions on how to migrate a Oracle feature to Sybase ASE. This cross-reference is an
extended version of the Oracle checklist in chapter 3. Much of this type of conversion can in principle be done using a
text editor with search-and-replace commands, or with tools like 'sed'.
11.1 Oracle-to-Sybase ASE migration: category "Simple Conversion"
Oracle Sybase ASE ("simple conversion")
Connecting to an Oracle schema CONNECT user_name/password
SET ROLE
Connecting to a Sybase database; also see section 4.5 USE database_name
The Oracle SQL*Plus “slash” character sends preceding PL/SQL text to the Oracle server. /
Equivalent to the ISQL go command at the end of a batch of SQL statements go
The semicolon is a statement delimiter in PL/SQL ;
No statement delimiters; remove Oracle delimiter semicolons
The Oracle DUAL table SELECT sysdate FROM DUAL
Should be removed completely from queries in Sybase ASE; but if it occurs many times in Oracle queries, it may also be created as a dummy table in ASE; see section 4.10
SET SAVEPOINT savepoint-name SAVE TRAN[SACTION] savepoint-name
Variable/Parameter declarations; naming syntax
DECLARE count NUMBER
In Sybase ASE, variable/parameter names must start with the character @. In ASE, the maximum length is 30 bytes; in Oracle, longer names are allowed. DECLARE @count INT
Assign default value in variable declaration DECLARE blood_type char(2) := 'O';
Explicitly assign value after variable declaration DECLARE @blood_type CHAR(2)
SET @blood_type = 'O'
Multiple variable declarations with a single DECLARE keyword DECLARE
V1 NUMBER(10,0);
V2 CHAR(20);
CURSOR mycursor IS
SELECT * FROM mytable;
When declaring multiple variables with one DECLARE keyword, the variables must be comma-separated ASE. Cursors must be declared separately with DECLARE…CURSOR
DECLARE
@v1 int,
@v2 char(20)
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 48
Oracle Sybase ASE ("simple conversion")
Declarations without DECLARE keyword in declaration section of stored procedures/functions CREATE PROCEDURE p
AS
V1 NUMBER(10,0);
V2 CHAR(20);
CURSOR mycursor IS
SELECT * FROM mytable;
BEGIN
…statements…
END;
DECLARE keyword is required in Sybase ASE. Cursors must be declared separately with DECLARE…CURSOR
CREATE PROCEDURE p
AS
BEGIN
DECLARE
@v1 int,
@v2 char(20)
DECLARE mycurs CURSOR AS
SELECT * FROM mytable
…statements…
END
go
Variable assignment myvar := expression;
SET @myvar = expression
SELECT @myvar = expression
Transferring table data into a variable SELECT my_col INTO my_variable
FROM my_table WHERE id = 123;
Directly select into the variable SELECT @my_variable = my_col FROM
my_table WHERE id = 123
Constants Redefine as variables and check scope of usage (local or global).
%TYPE denotes the datatype of a column in an existing table
DECLARE count my_table.id%TYPE
Explicitly declare the variable with the column's actual datatype
Dynamic SQL EXECUTE IMMEDIATE '…sql…';
Optional clauses: EXECUTE IMMEDIATE '…sql…' USING …;
EXECUTE IMMEDIATE '…sql…' INTO …;
EXECUTE IMMEDIATE '…sql…' BULK COLLECT
INTO …;
Use Sybase ASE execute-immediate SET @cmd = '…sql…'
EXECUTE (@cmd)
or: EXECUTE ('…sql…')
With the clauses USING (specifies parameters to the dynamic SQL), INTO (puts results into variables for single-row results), BULK COLLECT INTO (stores results into Oracle collections), the query should be rewritten to achieve the same effect in ASE.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 49
Oracle Sybase ASE ("simple conversion")
Loops with LOOP/END LOOP:
LOOP
…statements…;
EXIT [WHEN …condition…]; /*exit loop*/
…statements…;
/* back to top for next iteration: */
CONTINUE [WHEN …condition…];
…statements…;
END LOOP;
Convert to WHILE-loops. Oracle's EXIT and CONTINUE corresponds to ASE's BREAK and CONTINUE though ASE cannot have a condition associated with these statements. WHILE 1=1
BEGIN
…sql…
…conditional exit…
END
Or:
WHILE <condition>
BEGIN
…statements…
END
FOR loops
FOR i IN 1..5
LOOP
…statements…
END LOOP;
Convert to WHILE; use variables to implement FOR DECLARE @i int, @i_start int, @i_end
int
SET @i_start = 1, @i_end = 5
SET @i = @i_start
WHILE @i <= @i_end
BEGIN
…statements…
SELECT @i = @i + 1
END
CURSOR loops DECLARE CURSOR c IS …select-statement…;
LOOP myvariable IN c
…statements…
END LOOP;
Convert to an ASE cursor
GOTO statement and labels
IF var1 = -1 THEN
GOTO ErrorLabel;
END IF;
var2 := -1;
<<ErrorLabel>>
var2 := -99;
Change label syntax from <<labelname>> to
labelname:
IF @var1 = -1
GOTO ErrorLabel
SELECT @var2 = -1
ErrorLabel:
SELECT @var2 = -99
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 50
Oracle Sybase ASE ("simple conversion")
Oracle Outer join syntax
// right outer join
SELECT * FROM t1, t2
WHERE t1.col1 = t2.col2(+)
// left outer join
SELECT * FROM t1, t2
WHERE t1.col1(+) = t2.col2
Translates to Sybase ASE T-SQL outer join syntax or to ANSI outer join syntax (preferred). Some restrictions apply in Sybase, see section 9.4. SELECT * FROM t1, t2
WHERE t1.col1 =* t2.col2 (T-SQL
syntax)
SELECT * FROM t1 RIGHT [OUTER] JOIN t2
ON t1.col1 = t2.col2 (ANSI syntax)
SELECT * FROM t1, t2
WHERE t1.col1 *= t2.col2 (T-SQL
syntax)
SELECT * FROM t1 LEFT [OUTER] JOIN t2
ON t1.col1 = t2.col2 (ANSI syntax)
SET TRANSACTION READ WRITE Remove in Sybase ASE; see chapter 8
ALTER TABLE mytable TRUNCATE PARTITION partition_name
Replace by TRUNCATE TABLE mytable PARTITION partition_name
CREATE OR REPLACE PROCEDURE (or FUNCTION)
Replace by DROP PROCEDURE (or FUNCTION) followed by CREATE PROCEDURE (or FUNCTION)
ALTER PROCEDURE (or FUNCTION) Replace by DROP PROCEDURE (or FUNCTION) followed by CREATE PROCEDURE (or FUNCTION)
CREATE PROCEDURE… IS… Change to CREATE PROCEDURE… AS…
Stored procedure OUT/IN OUT parameters
CREATE PROCEDURE p
(a IN number, b OUT number, c IN OUT number)
IS …
Sybase ASE supports input and input+output parameters, but no output-only parameters. In addition, the output keyword must be specified when calling the procedure
CREATE PROCEDURE p
@a int, @b int output, @c int output
AS …
EXEC p @var1, @var2 output, @var3 output
Stored procedure execution with named parameters (param => value)
result := proc_name(param1 => my_var, param2
=> 123);
Convert to ASE syntax with named parameters:
EXEC @result = proc_name @param1 = @my_var,
@param2 = 123
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 51
Oracle Sybase ASE ("simple conversion")
Stored procedure execution with positional parameters (:var)
VAR a NUMBER;
VAR b NUMBER;
VAR c NUMBER;
EXEC proc_name (:a, :b, :c)
Convert to ASE syntax with named parameters:
declare @a int,
@b int,
@c int,
@return_status
EXEC @return_status = proc_name @a, @b, @c
Procedure execution In Oracle, the EXEC[UTE] keyword is not used
CREATE PROCEDURE p1
AS
BEGIN
…statements…
END;
CREATE PROCEDURE p2
AS
BEGIN
p1;
END;
In ASE, the EXEC[UTE] keyword is mandatory (except when the procedure is the first statement in the batch)
CREATE PROCEDURE p1
AS
BEGIN
…statements…
END
go
CREATE PROCEDURE p2
AS
BEGIN
EXECUTE p1
END
go
SQL Function declaration with DETERMINISTIC keyword CREATE FUNCTION f_func (p NUMBER)
RETURN NUMBER
DETERMINISTIC
IS…
In Sybase ASE, remove DETERMINISTIC
Execution of a SQL Function
select myfunc(123);
In Sybase ASE, the name of the executed SQL function must always be preceded by the owner's name select dbo.myfunc(123)
select jsmith.yourfunc(456)
DECLARE CURSOR cursor-name IS… Change to DECLARE cursor-name INSENSITIVE CURSOR AS… ASE's insensitive cursor is closest to Oracle's cursor implementation
Oracle cursors
Oracle cursors are automatically deallocated when closed. ASE cursors must be deallocated explicitly with DEALLOCATE CURSOR cursor-name. This should be added after every cursor CLOSE.
Cursor Attribute %ISOPEN
No equivalent in ASE, remove .
Cursor Attributes %FOUND, %NOTFOUND Convert to using @@sqlstatus
Cursor Attribute %ROWCOUNT Convert to using @@rowcount
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 52
Oracle Sybase ASE ("simple conversion")
AFTER triggers (on statement level) Similar to Sybase ASE table triggers
INSTEAD OF triggers (on views) Similar to Sybase ASE INSTEAD-OF triggers
SQL%ROWCOUNT
Indicates the number of rows affected by the most recently executed PL/SQL statement SELECT * FROM mytable WHERE id = 1234;
IF SQL%ROWCOUNT = 0 THEN
DBMS_OUTPUT.PUT_LINE('No rows
found.');
END IF;
Replace by @@rowcount DECLARE @rc INT, @err INT
SELECT * FROM mytable WHERE id = 1234
SELECT @rc = @@rowcount, @err = @@error
IF @rc = 0
print 'No rows found.'
BOOLEAN datatype (for PL/SQL variables only) Allowed values are TRUE, FALSE and NULL.
Convert to variables of type BIT (allows only 0 and 1; NULL = 0) or TINYINT NULL. Decide on a standard encoding like 0=false; 1=true. Instead of using the numeric literals 0 and 1 in tests and assignments, two variables named @true and @false could be defined (and set to 1 and 0), so as to use these names instead.
MERGE statement Migrate to ASE 15.7, which supports MERGE
Partitioned tables with composite partitioning
CREATE TABLE mytable
(...columns...)
PARTITION BY RANGE(ptn_key_col)
SUBPARTITION BY HASH(subptn_key_col)
[...]
ASE supports partitioned tables, but no composite
partitioning. Remove the SUBPARTITION clause.
Performance-optimized native PL/SQL datatypes (for PL/SQL variables only) BINARY_INTEGER BINARY_DOUBLE BINARY_FLOAT
Convert to INTEGER, DOUBLE, FLOAT datatypes
IF-THEN-ELSE
IF expression
THEN
statement;
ELSE
statement;
END IF;
In Sybase ASE, there is no THEN or END IF, so remove them IF expression
statement
ELSE
statement
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 53
Oracle Sybase ASE ("simple conversion")
Multiple statements in an IF-THEN-ELSE branch
IF expression
THEN
statement;
statement;
ELSE
statement;
statement;
END IF;
In Sybase ASE, there can be only a single statement expression in each branch; multiple statements must be grouped in a BEGIN- END block. IF expression
BEGIN
statement
statement
END
ELSE
BEGIN
statement
statement
END
Conditional test based on EXISTS subquery DECLARE
v_x NUMBER(10,0);
v_temp NUMBER(1, 0) := 0;
SELECT 1 INTO v_temp
FROM DUAL
WHERE EXISTS ( …subquery… );
IF v_temp = 1 THEN
v_x := -1;
Can be kept identical in ASE, but this can also be simplified greatly in ASE:
DECLARE @x int
SET @x = 0
IF EXISTS ( …subquery… )
SET @x = -1
END
String concatenation operator: || Sybase ASE supports + as the string concatenation operator; it also supports || though this is formally undocumented.
userenv('sessionid') Equivalent to session-specific global variable @@spid (since @@spid values are re-used, the sysprocesses.kpid value can also be used to create a better uniqueness)
MOD(X,Y) X % Y
CEIL() CEILING()
TRUNC(number) CONVERT(INT,..)
SUBSTR() SUBSTRING()
SUBSTR() function with two parameters SELECT substr('John', 2) returns 'ohn'
Rewrite with the length of the expression as the 3rd parameter SELECT substring ('John', 2, len('John'))
LENGTH() CHAR_LENGTH() or LEN() or DATALENGTH()
CHR() CHAR()
REPLACE() STR_REPLACE()
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 54
Oracle Sybase ASE ("simple conversion")
TO_CHAR(expression) CONVERT(VARCHAR(n), expression)
TO_CHAR(expression, datepart)
TO_CHAR(sysdate, 'dd')
Convert to use the ASE datepart() function
CONVERT(VARCHAR,datepart(dd,getdate()))
TO_CHAR(expression, format-string)
TO_CHAR(some-number, '999D99')
TO_CHAR(some-number, '999')
Implement the formatting explicitly with ASE functions
CONVERT(VARCHAR,ROUND(some-number,2))
CONVERT(VARCHAR,CONVERT(INT,some-
number))
TO_NUMBER(expression) CONVERT([BIG|SMALL|TINY]INT,
expression)
CONVERT(NUMERIC(n,m), expression)
Date/time functions and calculations SELECT add_months( xyz ,3 ) FROM dual
SELECT nr_days := DateEnd - DateStart
Rewrite with ASE date/time functions like DATEADD(), DATEDIFF(), DATEPART(),
DATENAME()
SELECT DATEADD(month, 3, xyz)
SELECT @nr_days = datediff(dd, DateStart,
DateEnd)
SYSDATE, SYSTIMESTAMP Replace by CURRENT_BIGDATETIME()
TRUNC(date/time [,unit]) Replace by CONVERT() with the date/time formatting styles
LAST_DAY()
Last day of a month function based on a date value; rewrite using ASE SQL functions
NVL() function
NVL(a,b)
Replace by ISNULL() function ISNULL(a,b)
Inconsistent use of upper/lowercase for identifiers (Oracle is case-insensitive for identifiers)
Either use a case-insensitive sort order in ASE, or use consistent upper/lowercase spelling for identifiers (see section 5.2)
Identifiers that are Sybase ASE reserved words (see section 4.8)
Change such identifiers so that they are not a reserved word.
INSTR() function with two parameters
SELECT INSTR('abcabc', 'ab')
Replace by charindex()
SELECT CHARINDEX('abcabc', 'ab')
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 55
Oracle Sybase ASE ("simple conversion")
Derived tables (also known as "inline views") without
correlation name
select a
from (select b as a, d as b from mytab)
where b > 0
ASE always requires a correlation name for a derived
table
select a
from (select b as a, d as b from mytab)
[as] somename
where b > 0
ALTER TABLE … SPLIT PARTITION…
ALTER TABLE … MERGE PARTITIONS…
Migrate to ASE 15.7 ESD#2 which supports these
statements.
Quoted identifiers. Oracle allows using quoted identifiers
by enclosing an identifier in double quotes. Quoted
identifiers are case-sensitive, unlike unquoted identifiers
which are case-insensitive.
CREATE TABLE "mytable" ("mycol" NUMBER);
Note that all-uppercase quoted identifiers do not need to
be quoted: "MYTABLE" (quoted) is identical to
MYTABLE (without quotes) in Oracle.
Sybase ASE also allows quoted identifiers delimited by
double quotes, but this is disabled by default. To use
quoted identifiers, the command set
quoted_identifiers on must be executed first. This
command affects only the session executing it.
Ignore quotes for all-uppercase quoted identifiers.
Oracle hints; indicated by a special comment directly following the SELECT:
SELECT /*+ INDEX (C) */
NAME
FROM CUSTOMERS C
WHERE ZIPCODE = 54321
Hint keywords:
ALL_ROWS APPEND CACHE CLUSTER FACT FIRST_ROWS FULL HASH INDEX INDEX_ASC INDEX_DESC INDEX_FFS INDEX_JOIN INDEX_SS LEADING MERGE MONITOR NO_EXPAND NO_FACT NO_INDEX REWRITE UNNEST USE_CONCAT
CURSOR_SHARING_EXACT DRIVING_SITE DYNAMIC_SAMPLING MODEL_MIN_ANALYSIS NATIVE_FULL_OUTER_JOIN NO_NATIVE_FULL_OUTER_JOIN NO_PARALLEL NO_PARALLEL_INDEX NO_PUSH_PRED NO_PUSH_SUBQ NO_PX_JOIN_FILTER NO_QUERY_TRANSFORMATION NO_RESULT_CACHE NO_REWRITE NO_STAR_TRANSFORMATION NO_UNNEST NO_USE_HASH NO_USE_MERGE NO_USE_NL NO_XML_QUERY_REWRITE NO_XMLINDEX_REWRITE STAR_TRANSFORMATION USE_NL_WITH_INDEX NOPARALLEL_INDEX
NOAPPEND NOCACHE NOPARALLEL NOREWRITE OPT_PARAM ORDERED PARALLEL PARALLEL_INDEX PQ_DISTRIBUTE PUSH_PRED PUSH_SUBQ PX_JOIN_FILTER QB_NAME RESULT_CACHE INDEX_COMBINE INDEX_SS_ASC INDEX_SS_DESC NO_INDEX_FFS NO_INDEX_SS NO_MERGE NO_MONITOR USE_HASH USE_MERGE USE_NL
Remove all Oracle hints
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 56
11.2 Oracle-to-Sybase ASE migration: category "Partial Rewrite"
For the Oracle features listed below, migration to partly equivalent Sybase ASE features is possible, although potentially
significant syntax changes and possibly partial rewriting of algorithms may be required.
Oracle Sybase ASE ("partial rewrite")
Database links
CREATE DATABASE LINK SALES.PROD
[ CONNECT TO CURRENT_USER ] using
'SALES';
SELECT * FROM salesdata@SALES;
Equivalent to ASE proxy tables, mapping to a remote
table
create proxy_table sales_proxy
at SALES.salesdb..salesdata
select * from your_proxy
External tables
create table my_external_tab
( ...columns...)
organization external
( default directory external_data_dir
access parameters
( records delimited by newline
fields terminated by ','
location ('...pathname...') )
Equivalent to ASE proxy tables, mapping to an O/S
file
create proxy_table my_external_tab
( ...columns...)
external file at '...pathname...'
column delimiter ','
Sequences
Generate unique numbers, for example for primary
keys
In some cases, this can be replaced by using ASE
identity columns. In other cases, the sequence
functionality must be emulated with a key counter
table and a stored procedure. See section 9.2.
Table-valued User-defined SQL Functions
ASE only supports scalar User-defined SQL
functions. Rewrite with temporary tables.
Pipelined Table Functions ( a special case of Table-
valued User-defined SQL Functions)
FUNCTION my_func
RETURN my_out_tab PIPELINED;
Rewrite with cursors or with an ASE proxy table
mapping to a stored procedure (though the
performance of Oracle Pipelined Table Functions can
probably not be achieved)
Synonyms For synonyms for tables or views, replace by an ASE
view; for table/view synonyms at dblinks, replace by
an ASE proxy table.
For synonyms for stored procedures or functions,
replace by a wrapper stored procedure/function; for
stored procedure synonyms at dblinks, replace by a
remote procedure call.
For other synonyms, application changes are required.
Comments on database objects
COMMENT ON TABLE mytab IS "This is my table";
No direct equivalent. An method for storing object comments in ASE is described in http://www.sybase.com/detail?id=607
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 57
Oracle Sybase ASE ("partial rewrite")
Bitmap indexes
CREATE BITMAP INDEX my_ix ON mytable(…)
ASE does not support bitmap indexes. Remove
BITMAP and create a regular index.
Sybase IQ supports bitmapped indexes.
Temporary tables
CREATE GLOBAL TEMPORARY TABLE temptab
[…] [ON COMMIT {PRESERVE|DELETE} ROWS]
Replace by ASE temporary tables whose names start
with the # character:
CREATE TABLE #temptab […]
SELECT * INTO #temptab FROM my_table
Note that there are differences in scope between an
Oracle temporary table and a Sybase #temporary
table: an Oracle temporary table is visible by all users
(though a user can only see his own data rows in the
table) whereas a Sybase #temp table is visible only to
the session that created it. In addition, an Oracle
temporary table is a permanent table that must be
dropped explicitly (only the data in the Oracle
temporary table is automatically deleted); a Sybase
#temp table is automatically dropped at the end of the
procedure or session that created it.
IS TABLE OF or AS VARRAY(n)OF
define a PL/SQL "table" (= non-database table, array).
Also known as a "collection" (various types of Oracle
collections exist).
Rewrite algorithm with a temporary table and use
FETCH or SELECT to process rows. Alternatively,
convert the table to a Java object with different data
elements, which can be stored in a table column.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 58
Oracle Sybase ASE ("partial rewrite")
Nested tables
Allow a column to be defined as a table, that can hold
N rows (=N column values)
Also known as a "collection" (various types of Oracle
collections exist).
CREATE TYPE address_t AS OBJECT (
street VARCHAR2(30),
city VARCHAR2(20),
state CHAR(2),
zip CHAR(10),
country CHAR(30));
CREATE TYPE address_tab IS TABLE OF
address_t;
CREATE TABLE customers (
custid NUMBER,
address address_tab )
NESTED TABLE address STORE AS
customer_addresses;
INSERT INTO customers VALUES (654,
address_tab(address_t('148 Oak Drive',
'Dallas', 'TX', '75240', 'USA'),
address_t('561 Virginia
Road', 'Concord', 'MA', '01742',
'USA')));
NB: customer_addresses is an object table as well as a nested table at the same time.
Change to use a separate table for the nested table in
the column, with a primary key-foreign key
relationship.
Object tables
CREATE TYPE person_type AS OBJECT (
name VARCHAR2(30), address
VARCHAR2(100));
CREATE TABLE person_obj_table OF
person_type;
Either replace with regular tables and columns, or use
a Java class to define a column as a complex datatype
containing different fields.
%ROWTYPE declares a PL/SQL record with the
same columns as a particular table
DECLARE cust customer%ROWTYPE
Declare each field as an individual variable and modify
all references accordingly. Alternatively, convert the
record to a Java object with different data elements,
which can be stored in a table column.
Define a PL/SQL record type by enumerating the
fields with IS RECORD OF or TYPE…IS RECORD
Declare each field as an individual variable and modify
all references accordingly. Alternatively, convert the
record to a Java object with is treated as an array.
Non-integer RETURN value in stored procedure Oracle stored procedures can return a scalar value of any datatype.
Sybase ASE stored procedures can only return an integer value. When a different datatypes is returned, rewrite by using an output parameter or rewrite with a SQL function
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 59
Oracle Sybase ASE ("partial rewrite")
User-defined Packages
Translate packages to the individual objects that the
package consists of (stored procedures, data types,
etc.)
Overloaded stored procedures
(multiple procedures with identical names but different
parameter datatypes or different number of parameters)
Translate to a single stored procedures or split into
separate stored procedures
PL/SQL Exception handling; defining exception
handlers
EXCEPTION WHEN ZERO_DIVIDE THEN
-- handles 'division by zero' error
[…]
EXCEPTION WHEN TOO_MANY_ROWS
-- handle case that > 1 row affected
[…]
EXCEPTION WHEN NO_DATA_FOUND
-- handle case that no rows affected
[…]
EXCEPTION WHEN DUP_VAL_ON_INDEX
-- handle case for duplicate index key
[…]
(etc… other conditions exist
Rewrite and perform checks on @@error and
@@rowcount after every SQL statement.
SQLCODE, SQLERRM
Indicates the error status and error message text of the most recently executed PL/SQL statement; used with the exception handling section EXCEPTION
WHEN OTHERS THEN
error_code := SQLCODE;
error_msg := substr(SQLERRM, 1, 200);
INSERT INTO
audit_table(err_no,err_msg)
VALUES (error_code, error_msg);
END;
Replace SQLCODE by @@error. ASE has no equivalent of SQLERRM
DECLARE @rc INT, @err INT
SELECT * FROM mytable WHERE id = 1234
SELECT @rc = @@rowcount, @err = @@error
IF @err = 0
BEGIN
INSERT INTO
audit_table(err_no,err_msg)
VALUES (@err, '');
END
RAISE_APPLICATION_ERROR
In stored procedures, this also rolls back until the
implicit savepoint at the start of the procedure (or after
the last committed transaction in the procedure)
Recode with Sybase ASE functions such as
RAISERROR or PRINT immediately followed by a
RETURN in stored procedures
Column Encryption Rewrite with ASE column encryption
LOB locators Migrate to ASE 15.7, which supports LOB Locators
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 60
Oracle Sybase ASE ("partial rewrite")
Data compression Migrate to ASE 15.7, which supports data
compression
Retrieving data to the client in stored procedures using
DBMS_OUTPUT package
DBMS_OUTPUT.PUT_LINE
Replace by direct SELECT or PRINT statements
DBMS_*, UTL_* package calls
(excl. DBMS_OUTPUT)
Recode with Sybase ASE features if possible,
otherwise remove
SDO_* package calls Spatial data features, remove/recode
SQL*Loader (sqlldr)
Oracle‟s high-speed data loader utility (only loading, no
unloading).
Rewrite using the Sybase bcp utility.
Materialized Views Migrate to ASE 15.7 ESD#2 which supports
materialized views (a.k.a. "precomputed result sets").
Global variables (in a PL/SQL package) Global variables are not supported; either pass all
variables around as parameters, or store such values in
a table and read/update that table as needed.
Alternatively, Java static classes can be used.
INTERSECT construct
SELECT a FROM tab1 WHERE b > 10
INTERSECT
SELECT c FROM tab2 WHERE d = 0
Rewrite as a join
SELECT tab1.a FROM tab1, tab2
WHERE tab1.a = tab2.c
AND tab1.b > 10 AND tab2.d = 0
MINUS construct
SELECT a,b,c FROM tab1 WHERE …
MINUS
SELECT d,e,f FROM tab2 WHERE …
Rewrite with NOT IN (single column) or NOT
EXISTS (multiple columns)
SELECT a,b,c FROM tab1
WHERE NOT EXISTS
(SELECT * from tab2
WHERE tab2.d = tab1.a
AND tab2.e = tab1.b
AND tab2.f = tab1.c)
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 61
Oracle Sybase ASE ("partial rewrite")
Specific SQL clauses
AS OF AS OF TIMESTAMP CONNECT BY DIMENSION DIMENSION BY EXCLUDE GROUPING SETS INCLUDE MEASURES RETURN ALL ROWS RETURN UPDATED ROWS PARTITION BY REFERENCE SYSTIMESTAMP
CROSS CUBE FOR KEEP MAIN MODEL NAV NOCYCLE NOWAIT ON ONLY RULES SAMPLE SEED SKIP
IGNORE ITERATE NATURAL NULLS NULLS FIRST NULLS LAST ROLLUP SIBLINGS SINGLE REFERENCE LOCKED START WITH UNIQUE UNPIVOT WAIT
Replace by corresponding Sybase ASE functionality, if
available. Otherwise, rewriting the SQL is required.
Capitalize first letter of all words in a string INITCAP( string-expression )
Rewrite with stored procedures or SQL functions
INSTR() function with three or four parameters
(3=start position, 4=nth occurrence)
SELECT INSTR('abcabc', 'ab', 2)
SELECT INSTR('abcabcabc', 'ab', 2, 2)
Create a SQL function to perform the advanced
searches.
Note that charindex() accepts a 3rd paramter in
ASE 15.7, but this cannot have a negative value (for
backward search) as is allowed in Oracle
NVL2() function
SELECT NVL2(salary,salary*2, 123) FROM…
Convert to a CASE expression
SELECT
CASE WHEN salary = NULL OR salary = ''
THEN 123
ELSE salary * 2 END
FROM…
DECODE() function
Used to evaluate with „if-else‟ type logic
SELECT
DECODE(T1.C1, 'ABC',
T1.C2,
T1.C3) as P_ID
FROM T1
Convert to a CASE expression
SELECT
case T1.C1
when 'ABC' then T2.C2 else T3.C3
end as P_ID
FROM T1
Primary key and foreign key with different datatypes,
different precision/scale (for numeric datatypes) or
different length (for character datatypes)
Unlike Oracle, ASE requires that a foreign key and
primary key have identical datatypes. Modify the
datatypes accordingly.
Cluster (as created with CREATE CLUSTER) Change the data model to use individual tables;
consider using views to avoid making changes to
existing SQL code
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 62
Oracle Sybase ASE ("partial rewrite")
VARCHAR2 variables longer than 16384 bytes
DECLARE msg VARCHAR2(32767)
(for columns, VARCHAR2 cannot be longer than 4000
bytes)
The maximum length of string variables is 16384
bytes; rewrite code, either using shorter ASE varchar
strings, or use ASSE LOB variables or LOB locators
in ASE 15.7
SQL functions where the last statement is not
RETURN
ASE requires that a SQL function has RETURN as its
last statement. This may require some re-coding of the
flow control.
Derived tables (also known as "inline views") using
"with" syntax
with x as (select b as a, d as b from mytab)
select a from x where b > 0
Rewrite with ASE derived table syntax
UNIONs in cursors A cursor with a UNION cannot be updatable in ASE;
such code may need to be rewritten.
PRAGMA directives Rewrite with ASE syntax/functionality.
Autonomous transactions
(AUTONOMOUS_TRANSACTION)
ASE does not support autonomous transactions;
rewrite with ASE transactional semantics.
ON DELETE CASCADE constraints Rewrite with ASE triggers
XMLTYPE (XML data type)
XML functions extract(), existsnode(), xmlexists(), etc
Rewrite with TEXT, IMAGE or VARCHAR
datatatypes and with ASE functions xmlextract(),
xmltable(), etc.
ROWID
An Oracle table always contains a ROWID column
with a unique identifier for each row, even if no
primary key was defined for the table. The ROWID can
be referenced in queries.
SELECT last_name, ROWID
INTO var_lname, var_rowid
FROM emp
WHERE empid = 98765
A similar effect can be achieved by add an identity
column to each table, and name the column
"ROWID".
There can be only one identity column per table. If
there is already an identity column for the primary
key, for example to replace an Oracle sequence, add a
virtual computed column named "ROWID", equal to
the identify column. This method can also be used
when existing Oracle code uses a different spelling,
like "rowid":
CREATE TABLE mytab
(ROWID NUMERIC IDENTITY, rowid AS
ROWID,
…other columns…)
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 63
Oracle Sybase ASE ("partial rewrite")
ROWNUM
For each row returned by a query, the ROWNUM
pseudocolumn returns a number indicating the order of
the row in the result set. This can be used in queries,
for example to select only a subset of the result set.
SELECT * FROM emp
WHERE state = 'CA'
AND ROWNUM > 9 AND ROWNUM < 21
ORDER BY last_name;
When the objective is to select the top N rows, this
can be achieved with select top N …from…
When more complex selections are done (e.g. only get
rows 10-20) , the an identity column (which should
probably be named "ROWNUM") can be added to
the result set with the identity() function, which
assigns a sequence number to every row in the result
set. This column can then be used in queries. Note
that this requires one extra query step:
SELECT *, ROWNUM=identity(int)
INTO #t FROM emp
WHERE state = 'CA'
ORDER BY last_name
SELECT <all columns except ROWNUM>
FROM #t
WHERE ROWNUM > 9 AND ROWNUM < 21
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 64
11.3 Oracle-to-Sybase ASE migration: category "Major Rewrite"
For the Oracle features listed below, no direct equivalent is available in Sybase ASE. Consequently, rewriting or
redesigning algorithms or parts of applications will be required.
Oracle Sybase ASE ("major rewrite")
Oracle MVCC (Multi-Version Concurrency Control;
"writers don‟t block readers, readers don't block
writers")
Relevant aspects:
Applications or queries relying on non-
blocking MVCC
Long-running transactions
DDL in transactions
SET TRANSACTION READ ONLY
SQL*Plus autocommit/commit-on-exit
No direct equivalent of MVCC. Some aspects may be
addressed by using DATAROWS locking, using the
READPAST option., or running SELECT queries at
isolation level 0 (READ UNCOMMITTED).
For other cases, the application may need to be
modified, for example by keeping transactions as short
as possible.
See section 8 for details.
SQL*Plus
The Sybase ASE counterpart for SQL*Plus is the
isql utility. SQL*Plus allows for more complex
configuration settings and SQL*Plus-specific (i.e.
non-PL/SQL) client-side commands inside
SQL*Plus. Existing SQL*Plus-based functionality
must be rewritten for ASE.
BEFORE triggers No direct equivalent. Some aspects of the
functionality (like domain integrity) may be covered by
rules or CHECK constraints at the table definition level;
however an Oracle BEFORE trigger can perform far
more complex processing than can be handled by
rules or constraints. If this functionality cannot be
implemented with Sybase ASE "after" triggers, the
application may need to be changed to apply the
functionality in a different way.
Triggers on row level (BEFORE and AFTER) No direct equivalent; some logic may be changed to
operate on the ASE pseudo-tables inserted and
deleted; otherwise, see BEFORE triggers above.
Multiple triggers for a DML type on a table No direct equivalent; if the functionality cannot be
consolidated in a single ASE trigger, the application
may need to be changed to apply the functionality in a
different way.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 65
Oracle Sybase ASE ("major rewrite")
REF CURSOR No direct equivalent. In ASE, REF CURSORs need
to be rewritten, for example by rewriting all stored
procedures involved, or by putting query results in
(temporary) tables and let the different stored
procedures access these. Also see section 9.1.
Regular Expressions; functions REGEXP_LIKE(),
REGEXP_SUBSTR(), REGEXP_REPLACE(),
REGEXP_INSTR()
No direct equivalent since ASEdoes not support
regular expressions.Rewrite with ASE SQL using
custom processing instead of RegEx
Windowing queries (SELECT…OVER(…) …)
SELECT name, salary,
NTILE(4) OVER (ORDER BY salary DESC)
AS quartile
FROM emp
WHERE dept_id = 123;
No equivalent in Sybase ASE. Rewrite with classic
ASE features, possibly requiring breaking up a query
in multiple steps. Alternatively. Use Sybase IQ which
does support windowing queries as well as many
analytic functions.
SQL function OUT/IN OUT parameters
Sybase ASE supports only input parameters for SQL functions. If output parameters are used, rewrite with stored procedures
Non-deterministic SQL Functions (functions whose
result may be independent of the function input
parameters)
This cannot be concluded from PL/SQL keywords
since Oracle supports only the keyword
DETERMINISTIC to indicate that a function is
deterministic. Non-determinism cannot be indicated
explicitly, but only from code inspection.
Sybase ASE supports only deterministic SQL
functions. DML, DDL, procedure calls, execute-
immediate, certain function calls and utility
commands are not allowed in a SQL function.
If these occur in an Oracle SQL Function, rewrite
with ASE stored procedures
SQL Aggregate Functions
CREATE FUNCTION f_aggr (p NUMBER)
RETURN NUMBER
AGGREGATE USING object-type;
No direct equivalent. Rewrite using available ASE
features.
BFILE datatype
A BFILE column stores a locator (link) to a binary file
outside of the database
No direct equivalent
Oracle Streams; Oracle Data Guard Use Sybase Replication Server.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 66
Oracle Sybase ASE ("major rewrite")
Oracle RAC for high-availability Use Sybase ASE Cluster Edition
Oracle Flashback No direct equivalent. Some aspects may be covered by
using the ASE "auditing" feature, by using ASE
"archive databases", and by using the until_time
option when loading a transaction log dump.
For other cases, old data values can be retained by
means of triggers.
Oracle flashback-related pseudocolumns
ORA_ROWSCN, VERSION_XID,
VERSION_STARTSCN, VERSION_ENDSCN,
VERSION_STARTTIME, VERSION_ENDTIME,
VERSION_OPERATION
See "Oracle Flashback" above
Oracle Snapshot Standby (combination of data
replication and Flashback)
No direct equivalent. Similar functionality can be
achieved with Replication Server.
Oracle SQL Plan Management
Stores and maintains query plans to support the query
optimizer to make better decisions: every time a query
gets executed, the query optimizer compares the
current query plan with the stored query plan and
chooses the better plan automatically.
(for DBA/tuning purposes, not affecting application
query syntax)
Some aspects are covered by abstract query plan
association ('abstract plan load') as well as by the
QPTune utility. However, ASE does not support
automatic evaluation of newly generated plans versus
captured past plans.
AWR (Automatic Workload Repository)
Stores every query with corresponding performance
indicators and metrics in a repository, allowing
identifying the top poorly performing queries
automatically (for which query plans managed by
Oracle SQL Plan Management will be used when the
query are being executed again)
(for DBA/tuning purposes, not affecting application
query syntax)
Query metrics are captured in ASE's
sysquerymetrics with the 'metrics capture'
feature, or through the MDA tables.
ASE does not support automatic actions based on
captured data
Oracle Advanced Queuing Similar concept as ASE's Real-Time Messaging
Service (RTMS), which allows direct interfacing from
SQL with message bus products like Tibco and MQ
Series.
Packages for PL/SQL web access
OWA_CUSTOM, OWA_CX, OWA_OPT_LOCK,
OWA_SEC, OWA_TEXT, OWA_UTIL
No equivalent. Custom implementation in ASE
required.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 67
Oracle Sybase ASE ("major rewrite")
Oracle Forms Rewrite with Sybase PowerBuilder. See section 9.2.
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.3
Oracle-to-Sybase Migration Cross-Reference 68
CONTACT INFORMATION For Europe, Middle East, or Africa inquiries: +(31) 34 658 2999 For Asia-Pacific inquiries: +852 2506 8900 (Hong Kong) For Latin America inquiries: +770 777 3131 (Atlanta, GA)
SYBASE, INC. WORLDWIDE HEADQUARTERS ONE SYBASE DRIVE DUBLIN, CA 94568-7902 USA Tel: 1 800 8 SYBASE www.sybase.com
Copyright © 2012 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase, and the Sybase logo are trademarks of Sybase, Inc. or its subsidiaries. All other trademarks are the property of their respective owners. ® indicates registration in the United States. Specifications are subject to change without notice.