Professional Documents
Culture Documents
MIGRATION GUIDE
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.1
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 .............................................................................................................................................................................................. 7
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 ...................................................................................... 19
4.4 Special cases in schema migration .......................................................................................................................................................... 19
4.5 Mapping the Oracle schema to Sybase ASE databases ...................................................................................................................... 20
4.6 Schema-related Oracle-Sybase terminology ......................................................................................................................................... 21
4.7 Mapping Oracle Datatypes to Sybase ASE .......................................................................................................................................... 22
4.7.1 Chained Oracle data rows .................................................................................................................................................................. 23
4.8 Search for Sybase ASE reserved words and keywords in Oracle ..................................................................................................... 24
4.9 Choosing a lock scheme for Sybase ASE tables .................................................................................................................................. 24
4.10 The Oracle DUAL Table ......................................................................................................................................................................... 24
5 Migrating server-level aspects .................................................................................................................................................... 26
5.1 Character set ............................................................................................................................................................................................... 26
5.2 Database server case sensitivity ('sort order') ....................................................................................................................................... 26
5.3 Server configuration parameters ............................................................................................................................................................. 27
5.4 Storage.......................................................................................................................................................................................................... 27
5.5 Migrating the User Logins ....................................................................................................................................................................... 27
5.5.1 User passwords ..................................................................................................................................................................................... 28
5.6 Permissions ................................................................................................................................................................................................. 28
6 Data Migration .............................................................................................................................................................................. 29
6.1 Unload Oracle data into ASCII files; load into ASE with "bcp" utility .......................................................................................... 30
6.1.1 Loading into ASE with "bcp" ............................................................................................................................................................ 30
6.1.2 Unloading from Oracle: FACT (3rd-party tool) ............................................................................................................................ 30
6.1.3 Unloading from Oracle: Roll-your-own PL/SQL utility to export Oracle data...................................................................... 31
6.1.4 Unloading from Oracle: use Oracle SQL Developer ................................................................................................................... 31
6.2 Use Sybase's Enterprise Connect Data Access (ECDA) Option for Oracle ................................................................................. 31
6.2.1 ECDA Example ................................................................................................................................................................................... 31
6.3 Use Sybase Replication Server Heterogeneous Edition (RSHE) for Oracle ................................................................................. 32
6.3.1 Minimal migration downtime with Replication ............................................................................................................................. 32
6.3.2 Initial materialization for the replication setup .............................................................................................................................. 32
6.3.3 Other considerations ........................................................................................................................................................................... 33
Introduction 2
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.1
6.4 Use a 3rd-party ETL tool that supports both Oracle and Sybase ASE .......................................................................................... 33
6.5 Oracle datatypes requiring special attention for migration ................................................................................................................ 33
7 Migrating PL/SQL to Transact-SQL ....................................................................................................................................... 35
7.1 Locations of PL/SQL code ..................................................................................................................................................................... 35
7.2 SwisSQL assistance for PL/SQL migration to T-SQL .................................................................................................................. 35
8 Transactions and Locking, Oracle vs. Sybase ......................................................................................................................... 37
8.1 Oracle MVCC vs. Sybase locking ........................................................................................................................................................... 37
8.2 Transaction-related migration issues ...................................................................................................................................................... 37
8.3 Using ASE implicit/chained transaction mode ................................................................................................................................... 38
8.3.1 Transactional DDL .............................................................................................................................................................................. 38
8.3.2 Transaction processing in stored procedures ................................................................................................................................. 38
8.4 Using ASE explicit/unchained transaction mode ............................................................................................................................... 38
8.5 Using ASE transactional concurrency enhancements ........................................................................................................................ 38
8.6 Other transactional aspects ...................................................................................................................................................................... 39
9 Miscellaneous migration aspects................................................................................................................................................ 41
9.1 Cursors ......................................................................................................................................................................................................... 41
9.2 Sequences .................................................................................................................................................................................................... 41
9.3 Error/Exception handling ....................................................................................................................................................................... 42
9.4 Outer join limitations ................................................................................................................................................................................ 42
9.5 Migrating JDBC/ODBC/ Applications ........................................................................................................................................... 43
9.5.1 JDBC ...................................................................................................................................................................................................... 43
9.6 Oracle Forms .............................................................................................................................................................................................. 43
10 DBA Tasks Cross-Reference ..................................................................................................................................................... 44
11 Oracle-to-Sybase Migration Cross-Reference ......................................................................................................................... 48
11.1 Oracle-to-Sybase ASE migration: category "Simple Conversion" ................................................................................................... 48
11.2 Oracle-to-Sybase ASE migration: category "Partial Rewrite" ........................................................................................................... 56
11.3 Oracle-to-Sybase ASE migration: category "Major Rewrite" ........................................................................................................... 63
Revision history:
Rev.1.0: September 2011: initial version
Rev.1.1: November 2011: expanded the topic on case-sensitivity; various other additions
Introduction 3
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.1
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).
Introduction 4
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.1
In addition, Sybase provides technical training for ASE. For details on courses and availability, see
http://www.sybase.com/education.
Introduction 5
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.1
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.
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.
It is recommended to evaluate the use of SwisSQL (a 3rd-party product; see section 7.2) to assist with PL/SQL
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.
The Oracle slash is contained at the end of some of the procedures examined.
Variable assignment
Constants
FOR loops
CURSOR loops
CREATE PROCEDURE IS
Oracle cursors
SQL%ROWCOUNT
MERGE statement
BINARY_INTEGER
BINARY_DOUBLE
BINARY_FLOAT
IF-THEN-ELSE
userenv('sessionid')
MOD(X,Y)
CEIL()
TRUNC(number)
SUBSTR()
LENGTH()
CHR()
TO_CHAR(expression)
TO_CHAR(expression, datepart)
TO_CHAR(expression, format-string)
TO_NUMBER(expression)
SYSDATE, SYSTIMESTAMP
TRUNC(date/time [,unit])
LAST_DAY()
NVL() function
Identifiers that are Sybase ASE reserved words (see section 4.8)
Oracle hints
Database links
External tables
Sequences
Synonyms
Bitmap indexes
Temporary tables
Nested tables
Object tables
%ROWTYPE
Define a PL/SQL record type by enumerating the fields with IS RECORD OF or TYPEIS
RECORD
User-defined Packages
SQLCODE, SQLERRM
RAISE_APPLICATION_ERROR
Column Encryption
LOB locators
Data compression
SQL*Loader (sqlldr)
INTERSECT construct
MINUS construct
INITCAP( string-expression )
NVL2() function
DECODE() function
Primary key and foreign key with different datatypes, different precision/scale (for numeric
datatypes) or different length (for character datatypes)
UNIONs in cursors
PRAGMA directives
XMLTYPE
XML functions extract(), existsnode(), xmlexists(), etc
ROWID
ROWNUM
Oracle MVCC (Multi-Version Concurrency Control; "writers dont 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
Materialized Views
REF CURSOR
Non-deterministic SQL Functions (functions whose result may be independent of the function
input parameters)
BFILE datatype
Oracle Flashback
Oracle Forms
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. A different tool, named
SwisSQL, has such capabilities; see elsewhere in this Migration Guide for more information.
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.
Now that the schema has been extracted from Oracle into a PDM, change the target DBMS to Sybase ASE:
1. Choose Database>Change Current DBMS
2. Select a target DBMS as Sybase AS Enterprise 15.0 from the dropdown list box.
Now generate the Sybase ASE-compatible DDL from the PowerDesigner PDM; this will automatically convert the
datatypes to the Sybase ASE's datatypes:
1. Choose Database>Generate Database to open the Database Generation dialog box
2. Type a destination directory and a filename for the script file in the Directory and File Name boxes.
3. Select the Script generation radio button.
4. The output window shows the progress of the generation process, and indicates the syntax for running the
script. At the end of script generation, a Result box appears. It lists the file path of the generated script file.
Click Edit to open the script in a text editor or Close to close the Result box.
5. Check all warnings and errors, if needed make changes and generate the script again
Some aspects of schema migration cannot be handled by PowerDesigner and will have to be handled manually. These
are described in section 4.4.
Finally, run the completed DDL script in Sybase ASE and check for any errors.
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.
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.
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.
View View
Materialized View No direct equivalent
Cluster No direct equivalent
Index Non-unique index
Constraints Constraints
PL/SQL Procedure Transact-SQL stored procedure
PL/SQL Function T-SQL user-defined SQL function (SQL UDF)
ROWID a pseudo column in Oracle, does NUMERIC Also see ROWID on page 62
not represent a true datatype IDENTITY
CLOB Oracles max. storage capacity for TEXT Sybase ASE can hold a max. of 2GB
CLOB is 128TB per column; IQ can hold up to 2PB
NCLOB Oracles max. storage capacity for UNITEXT Sybase ASE can hold a max. of 2GB
NCLOB is 128TB per column; IQ can hold up to 2PB
BLOB Oracles max. storage capacity for IMAGE Sybase ASE can hold a max. of 2GB
BLOB is 128TB per column; IQ can hold up to 2PB
LONG Oracles max. storage capacity for TEXT
LONG is 2GB
RAW(x) the RAW datatype in Oracle has a BINARY(x) if ASE page size is 4kb or greater; and if
max precision of 2000 bytes ASE page size is 2kb and x <= 1954
VARBINARY(x)
IMAGE if none of the above conditions apply
LONG RAW Oracles max. storage capacity for IMAGE
LONG RAW is 2GB
CHAR(1) if this is a packed bit column BIT
maintained by a PL/SQL
function set / unset / retrieve /
query on them.
BFILE BFILE stores a locator (link) to a no direct equivalent
binary file outside of the database
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 we already identified as either problematic or non-migratable.
The following code will scan any object within the Oracle database for certain keywords and returns the name and
owner of the object as well as the object type:
SELECT owner, name, type
FROM dba_source WHERE instr(UPPER(text), UPPER('<keyword>')) > 0
Sometimes it is important to retrieve the exact code and line number of the occurrence within a stored procedure,
function or trigger. Note that this query could potentially return a lot of data:
SELECT owner, name, type, line, text
FROM dba_source WHERE instr(UPPER(text), UPPER('<keyword>')) > 0
The queries above should be run for all Sybase ASE reserved words and keywords. For a complete list of reserved words
in Sybase ASE, see Adaptive Server Enterprise->Reference Manual: Building Blocks->Reserved Words.
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:
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.
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.
5.4 Storage
Most Oracle installations enlist the help of Oracles 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.
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.
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.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.
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
Data Migration 29
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.1
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.
Data Migration 30
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.1
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:
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.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.
Data Migration 31
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.1
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.
Data Migration 32
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.1
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.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.
Data Migration 33
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.1
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.
Data Migration 34
ORACLE TO SYBASE ASE MIGRATION GUIDE Rev.1.1
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 a tool like SwisSQL, see 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.
SwisSQL (a 3rd-part tool) is one of the few tools that provides assistance with automatic migration of Oracle PL/SQL
code to Sybase T-SQL. For more information, see http://www.swissql.com/products/oracle-to-sybase .
This Migration Guide recommends evaluating SwisSQL for the purpose of PL/SQL migration.
According to www.swissql.com, the following aspects are supported:
Procedures, Functions, Views and Packages from PL/SQL to Transact-SQL. Supports both Named and
Anonymous PL/SQL blocks.
Variables, Cursors defined in Package Specification and Package Body.
Procedure calls made inside another procedure.
PL/SQL built-in and user-defined Datatypes To Transact SQL.
PL/SQL built-in Functions into corresponding Transact SQL Procedures.
Built-in packages like DBMS_OUTPUT & DBMS_SQL.
Cursor Declaration, OPEN, FETCH and CLOSE Statements, Cursor Variables and Implicit Cursors.
REF Cursor variables into Transact-SQL.
%ROWCOUNT, %FOUND, %NOTFOUND and %ISOPEN cursor attributes.
Sequence Objects.
PL/SQL Label.
Scalar and Record Anchor variables.
User Defined Exceptions.
PL/SQL IN OUT parameters.
Native Dynamic SQL Statements(NDS).
Collection type.
Transaction features - COMMIT, ROLLBACK and SAVEPOINT.
Conditional and control statements.
A mechanism to configure datatype mapping to be used during migration through a configuration file.
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 dont
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.
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).
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.
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.
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.
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).
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
"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 some cases ( startwith 1 incremented by
1, not sharing the sequence values between tables) this can be replaced with minimal changes by using an ASE
identity column.
In other cases the sequence functionality must be emulated with a key counter table and a stored procedure:
Oracle code:
CREATE SEQUENCE test_seq
MINVALUE 1
STARTWITH 1
INCREMENTED by 1
CACHE 20;
go
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.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.
Import/export data imp / exp command or impdp For data import and export:
/expdp command for data pump
bcp command located in
located in $ORACLE_HOME/bin
$SYBASE/OCS-15_0/bin
Oracle imports and exports the data
For the definition import and
and the DDL definitions, plus all other
export:
objects like type definitions, indexes,
procedure and views. defncopy command in
$SYBASE/OCS-15_0/bin
Data exported with exp can only be
imported with imp. To reverse engineering the DDL to
be recreated in another
environment:
ddlgen command in
$SYBASE/ASEP/bin
Setup new Oracle Enterprise emca command in Sybase Central in combination with
Manager (OEM) server $ORACLE_HOME/bin 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.
Stop database server Login to SQL*Plus and execute: Login via isql and execute the
command:
SQL>shutdown
shutdown
For normal shut down
go
SQL>shutdown immediate;
Without parameters the server will
For immediate shut down wait for all transactions to finish.
Adding with nowait will terminate
SQL>shutdown abort; all sessions and shut down the
For emergency shut down server immediately.
Stop backup server Oracle does not have a concept of a Login via isql into the Sybase ASE
Backup Server. 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 has the following ways of Sybase ASE always performs a hot
Database Backup
performing a database backup: backup; this requires hardly any
configuration. This is the same
imp / exp commands: this can
functionality as Oracles Archive
import/export the entire database
Log backup, but no archive file
(including all data), individual
cleanup is necessary.
schemas or a single table.
The command dump database
Data Pump: new import / export backs up an entire database (full
feature since Oracle 10g. The basic dump); dump transaction
functionality is identical to the old only backs up the transaction log
imp and exp commands, but since the previous dump
Data Pump is faster. (incremental backup).
RMAN: The Oracle Recovery The command load database
Manager (RMAN), command-line restores a full backup; load
as well as Enterprise Manager- transaction loads an
based, is the Oracle-preferred incremental backup following loads
method of efficiently backing up of earlier backups.
and restoring an Oracle database.
Various backup options exist, For these dump/load commands,
some of which require the Oracle Backup Server must be running.
database to be shut down first.
Oracle static data dictionary views System tables (catalogs) and system
Information about schema
stored procedures (sp_*)
Connecting to an Oracle schema Connecting to a Sybase database; also see section 4.5
The Oracle slash is contained at the end of some of Equivalent to the ISQL go command at the end of a
the procedures examined. 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 Should be removed completely from queries in Sybase
ASE; but if it occurs many times in Oracle queries, it
SELECT sysdate FROM DUAL may also be created as a dummy table in ASE; see
section 4.10
Variable/Parameter declarations; naming syntax 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 NUMBER
DECLARE @count INT
Assign default value in variable declaration Explicitly assign value after variable declaration
Declarations with a single DECLARE keyword When declaring multiple variables with one
DECLARE keyword, the variables must be comma-
DECLARE separated ASE. Cursors must be declared separately
V1 NUMBER(10,0); with DECLARECURSOR
V2 CHAR(20);
DECLARE
CURSOR mycursor IS
@v1 int,
SELECT * FROM mytable;
@v2 char(20)
Declarations without DECLARE keyword in declaration DECLARE keyword is required in Sybase ASE.
section of stored procedures/functions Cursors must be declared separately with
DECLARECURSOR
CREATE PROCEDURE p
AS CREATE PROCEDURE p
V1 NUMBER(10,0); AS
V2 CHAR(20); BEGIN
CURSOR mycursor IS DECLARE
SELECT * FROM mytable; @v1 int,
BEGIN @v2 char(20)
statements
END; DECLARE mycurs CURSOR AS
SELECT * FROM mytable
statements
END
go
Variable assignment
SET @myvar = expression
myvar := expression; SELECT @myvar = expression
Transferring table data into a variable Directly select into the variable
%TYPE denotes the datatype of a column in an existing Explicitly declare the variable with the column's actual
table datatype
Or:
WHILE <condition>
BEGIN
statements
END
LOOP myvariable IN c
statements
END LOOP;
Oracle Outer join syntax 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.
// right outer join SELECT * FROM t1, t2
SELECT * FROM t1, t2 WHERE t1.col1 =* t2.col2 (T-SQL
WHERE t1.col1 = t2.col2(+) syntax)
Stored procedure OUT/IN OUT parameters Sybase ASE supports input and input+output
parameters, but no output-only parameters. In
addition, the output keyword must be specified when
CREATE PROCEDURE p calling the procedure
(a IN number, b OUT number, c IN OUT number)
IS
CREATE PROCEDURE p
@a int, @b int output, @c int output
AS
Stored procedure execution with named parameters Convert to ASE syntax with named parameters:
(param => value)
EXEC @result = proc_name @param1 = @my_var,
result := proc_name(param1 => my_var, param2 @param2 = 123
=> 123);
Stored procedure execution with positional parameters Convert to ASE syntax with named parameters:
(:var)
declare @a int,
VAR a NUMBER; @b int,
VAR b NUMBER; @c int,
VAR c NUMBER; @return_status
EXEC proc_name (:a, :b, :c) EXEC @return_status = proc_name @a, @b, @c
Execution of a SQL Function In Sybase ASE, the name of the executed SQL function
must always be preceded by the owner's name
select myfunc(123);
select dbo.myfunc(123)
select jsmith.yourfunc(456)
BOOLEAN datatype (for PL/SQL variables only) Convert to variables of type BIT (allows only 0 and 1;
NULL = 0) or TINYINT NULL. Decide on a
Allowed values are TRUE, FALSE and NULL. 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.
Partitioned tables with composite partitioning ASE supports partitioned tables, but no composite
partitioning. Remove the SUBPARTITION clause.
CREATE TABLE mytable
(...columns...)
PARTITION BY RANGE(ptn_key_col)
SUBPARTITION BY HASH(subptn_key_col)
[...]
Performance-optimized native PL/SQL datatypes (for Convert to INTEGER, DOUBLE, FLOAT datatypes
PL/SQL variables only)
BINARY_INTEGER
BINARY_DOUBLE
BINARY_FLOAT
Multiple statements in an IF-THEN-ELSE branch In Sybase ASE, there can be only a single statement
expression in each branch; multiple statements must
IF expression be grouped in a BEGIN- END block.
THEN
statement; IF expression
statement; BEGIN
ELSE statement
statement; statement
statement; END
END IF; ELSE
BEGIN
statement
statement
END
Conditional test based on EXISTS subquery Can be kept identical in ASE, but this can also be
simplified greatly in ASE:
DECLARE
v_x NUMBER(10,0); DECLARE @x int
v_temp NUMBER(1, 0) := 0; SET @x = 0
IF EXISTS ( subquery )
SELECT 1 INTO v_temp SET @x = -1
FROM DUAL END
WHERE EXISTS ( subquery );
IF v_temp = 1 THEN
v_x := -1;
MOD(X,Y) X % Y
CEIL() CEILING()
TRUNC(number) CONVERT(INT,..)
SUBSTR() SUBSTRING()
SUBSTR() function with two parameters Rewrite with the length of the expression as the 3rd
parameter
CHR() CHAR()
TO_NUMBER(expression) CONVERT([BIG|SMALL|TINY]INT,
expression)
CONVERT(NUMERIC(n,m), expression)
Date/time functions and calculations Rewrite with ASE date/time functions like
DATEADD(), DATEDIFF(), DATEPART(),
DATENAME()
Inconsistent use of upper/lowercase for identifiers Either use a case-insensitive sort order in ASE, or use
(Oracle is case-insensitive for identifiers) consistent upper/lowercase spelling for identifiers (see
section 5.2)
Identifiers that are Sybase ASE reserved words (see Change such identifiers so that they are not a reserved
section 4.8) word.
Derived tables (also known as "inline views") without ASE always requires a correlation name for a derived
correlation name table
select a select a
from (select b as a, d as b from mytab) from (select b as a, d as b from mytab)
where b > 0 [as] somename
where b > 0
ALTER TABLE SPLIT PARTITION ASE supports partitioned tables, but does not yet
ALTER TABLE MERGE PARTITIONS support split/merge partition. Remove these
statements.
Oracle hints; indicated by a special comment directly Remove all Oracle hints
following the SELECT:
Hint keywords:
ALL_ROWS CURSOR_SHARING_EXACT NOAPPEND
APPEND DRIVING_SITE NOCACHE
CACHE DYNAMIC_SAMPLING NOPARALLEL
CLUSTER MODEL_MIN_ANALYSIS NOREWRITE
FACT NATIVE_FULL_OUTER_JOIN OPT_PARAM
FIRST_ROWS NO_NATIVE_FULL_OUTER_JOIN ORDERED
FULL NO_PARALLEL PARALLEL
HASH NO_PARALLEL_INDEX PARALLEL_INDEX
INDEX NO_PUSH_PRED PQ_DISTRIBUTE
INDEX_ASC NO_PUSH_SUBQ PUSH_PRED
INDEX_DESC NO_PX_JOIN_FILTER PUSH_SUBQ
INDEX_FFS NO_QUERY_TRANSFORMATION PX_JOIN_FILTER
INDEX_JOIN NO_RESULT_CACHE QB_NAME
INDEX_SS NO_REWRITE RESULT_CACHE
LEADING NO_STAR_TRANSFORMATION INDEX_COMBINE
MERGE NO_UNNEST INDEX_SS_ASC
MONITOR NO_USE_HASH INDEX_SS_DESC
NO_EXPAND NO_USE_MERGE NO_INDEX_FFS
NO_FACT NO_USE_NL NO_INDEX_SS
NO_INDEX NO_XML_QUERY_REWRITE NO_MERGE
REWRITE NO_XMLINDEX_REWRITE NO_MONITOR
UNNEST STAR_TRANSFORMATION USE_HASH
USE_CONCAT USE_NL_WITH_INDEX USE_MERGE
NOPARALLEL_INDEX USE_NL
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- Rewrite with cursors or with an ASE proxy table
valued User-defined SQL Functions) mapping to a stored procedure (though the
performance of Oracle Pipelined Table Functions can
probably not be achieved)
Nested tables Change to use a separate table for the nested table in
Allow a column to be defined as a table, that can hold the column, with a primary key-foreign key
N rows (=N column values) relationship.
Object tables Either replace with regular tables and columns, or use
a Java class to define a column as a complex datatype
CREATE TYPE person_type AS OBJECT ( containing different fields.
name VARCHAR2(30), address
VARCHAR2(100));
%ROWTYPE declares a PL/SQL record with the Declare each field as an individual variable and modify
same columns as a particular table all references accordingly. Alternatively, convert the
record to a Java object with different data elements,
DECLARE cust customer%ROWTYPE which can be stored in a table column.
Define a PL/SQL record type by enumerating the Declare each field as an individual variable and modify
fields with IS RECORD OF or TYPEIS RECORD all references accordingly. Alternatively, convert the
record to a Java object with is treated as an array.
Non-integer RETURN value in stored procedure Sybase ASE stored procedures can only return an
integer value.
Oracle stored procedures can return a scalar value of When a different datatypes is returned, rewrite by
any datatype. using an output parameter or rewrite with a SQL
function
PL/SQL Exception handling; defining exception Rewrite and perform checks on @@error and
handlers @@rowcount after every SQL statement.
DBMS_OUTPUT.PUT_LINE PRINT
Retrieving data to the client in stored procedures using Replace by direct SELECT statement in the stored
DBMS_OUTPUT package procedure
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.
SELECT a FROM tab1 WHERE b > 10 SELECT tab1.a FROM tab1, tab2
INTERSECT WHERE tab1.a = tab2.c
SELECT c FROM tab2 WHERE d = 0 AND tab1.b > 10 AND tab2.d = 0
Capitalize first letter of all words in a string Rewrite with stored procedures or SQL functions
INITCAP( string-expression )
INSTR() function with three or four parameters Create a SQL function to perform the advanced
(3=start position, 4=nth occurrence) searches.
Note that charindex() accepts a 3rd paramter in
SELECT INSTR('abcabc', 'ab', 2) ASE 15.7, but this cannot have a negative value (for
SELECT INSTR('abcabcabc', 'ab', 2, 2)
backward search) as is allowed in Oracle
SELECT SELECT
DECODE(T1.C1, 'ABC', case T1.C1
T1.C2, when 'ABC' then T2.C2 else T3.C3
T1.C3) as P_ID end as P_ID
FROM T1 FROM T1
Primary key and foreign key with different datatypes, Unlike Oracle, ASE requires that a foreign key and
different precision/scale (for numeric datatypes) or primary key have identical datatypes. Modify the
different length (for character datatypes) 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
VARCHAR2 variables longer than 16384 bytes The maximum length of string variables is 16384
bytes; rewrite code using longer string variables with
LOB variables or LOB locators in ASE 15.7
DECLARE msg VARCHAR2(32767)
(for columns, VARCHAR2 cannot be longer than 4000
bytes)
SQL functions where the last statement is not ASE requires that a SQL function has RETURN as its
RETURN last statement. This may require some re-coding of the
flow control.
Derived tables (also known as "inline views") using Rewrite with ASE derived table syntax
"with" syntax
Oracle MVCC (Multi-Version Concurrency Control; No direct equivalent of MVCC. Some aspects may be
"writers dont block readers, readers don't block addressed by using DATAROWS locking, using the
writers") READPAST option., or running SELECT queries at
Relevant aspects: isolation level 0 (READ UNCOMMITTED).
For other cases, the application may need to be
Applications or queries relying on non-
modified, for example by keeping transactions as short
blocking MVCC
as possible.
Long-running transactions See section 8 for details.
DDL in transactions
SET TRANSACTION READ ONLY
SQL*Plus autocommit/commit-on-exit
Triggers on row level (BEFORE and AFTER) No direct equivalent; 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.
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 Sybase ASE supports only deterministic SQL
result may be independent of the function input functions. DML, DDL, procedure calls, execute-
parameters) 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
Oracle SQL Plan Management Some aspects are covered by abstract query plan
association ('abstract plan load') as well as by the
Stores and maintains query plans to support the query
QPTune utility. However, ASE does not support
optimizer to make better decisions: every time a query
automatic evaluation of newly generated plans versus
gets executed, the query optimizer compares the
captured past plans.
current query plan with the stored query plan and
chooses the better plan automatically.
(for DBA/tuning purposes, not affecting application
query syntax)
CONTACT INFORMATION
SYBASE, INC.
WORLDWIDE HEADQUARTERS
ONE SYBASE DRIVE
DUBLIN, CA 94568-7902 USA
Tel: 1 800 8 SYBASE
www.sybase.com
Copyright 2011 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.