Oracle Migration Workbench for MS SQL Server and Sybase Adaptive Server Reference Guide Release 1.2.5.0.0 for Windows Z26179-01 |
|
This chapter includes the following sections:
The schema contains the definitions of the tables, views, indexes, users, constraints, stored procedures, triggers, and other database-specific objects. Most relational databases work with similar objects.
The schema migration topics discussed here include the following:
There are many similarities between schema objects in Oracle, MS SQL Server, and Sybase Adaptive Server (Sybase). However, some schema objects differ between these databases, as shown in the following table:
Reserved words differ between Oracle, MS SQL Server, and Sybase. Many Oracle reserved words are valid object or column names in MS SQL Server and Sybase. For example, DATE is a reserved word in Oracle, but it is not a reserved word in MS SQL Server and Sybase. Therefore, no column is allowed to have the name DATE in Oracle, but a column can be named DATE in MS SQL Server or Sybase. Use of reserved words as schema object names makes it impossible to use the same names across databases.
You should choose a schema object name that is unique by case and by at least one other characteristic, and ensure that your object name is not a reserved word from either database.
For a list of reserved words in Oracle, see the Oracle8i SQL Reference, Release 2 (8.1.6) (Part Number A76989-01).
This section discusses the many table design issues that you need to consider when converting MS SQL Server or Sybase databases to Oracle. These issues are discussed under the following headings:
This section outlines conversion considerations for the following data types:
The date/time precision in MS SQL Server and Sybase is 1/300th of a second; in Oracle, the precision is one second. All three databases store point-in-time values for DATE and TIME data types. In MS SQL Server and Sybase, the DATETIME data type stores date and time values that are accurate to 1/300th of a second. Oracle uses the DATE data type and stores date and time values that are accurate to one second.
For applications that require finer date/time precision than seconds, the table design must include an INTEGER column with each DATE column. Oracle needs this additional column to store the value of the sequence along with the DATE value, in order to store the sub-second information.
As an alternative, if an MS SQL Server or Sybase application uses the DATETIME column to provide unique IDs instead of point-in-time values, replace the DATETIME column with a SEQUENCE in the Oracle schema definition.
In the following examples, the original design does not allow the DATETIME precision to exceed seconds in the Oracle table. This example assumes that the DATETIME column is used to provide unique IDs. If millisecond precision is not required, the table design outlined in the following example will suffice:
Original Table Design
MS SQL Server/Sybase:
CREATE TABLE example_table (datetime_column datetime not null, text_column text null, varchar_column varchar(10) null)
Oracle:
CREATE TABLE example_table (datetime_column date not null, text_column long null, varchar_column varchar2(10) null)
The following design allows the value of the sequence to be inserted into the integer_column. This allows you to order the rows in the table beyond the allowed precision of one second for DATE data type fields in Oracle. If you include this column in the MS SQL Server or Sybase table, you can keep the same table design for the Oracle database.
Revised Table Design
MS SQL Server/Sybase:
CREATE TABLE example_table (datetime_column datetime not null, integer_column int null, text_column text null, varchar_column varchar(10) null)
Oracle:
CREATE TABLE example_table (datetime_column date not null, integer_column number null, text_column long null, varchar_column varchar2(10) null)
For the MS SQL Server or Sybase database, the value in the integer_column is always NULL. For Oracle, the value for the field integer_column is updated with the next value of the sequence.
Create the sequence by issuing the following command:
CREATE SEQUENCE datetime_seq
Values generated for this sequence start at 1 and are incremented by 1.
Many applications do not use DATETIME values as UNIQUE IDs, but still require the date/time precision to be higher than seconds (for example, the timestamp of a scientific application may have to be expressed in milliseconds, microseconds, nanoseconds, etc.). The precision of the MS SQL Server and Sybase DATETIME data type is 1/300th of a second; the precision of the Oracle DATE data type is 1 second.
The MS SQL Server and Sybase DATETIME data type can be converted to a higher precision in Oracle using one of the following methods:
SQL> SELECT hsecs FROM v$timer;
The physical and logical storage methods for IMAGE and TEXT data differ from Oracle to MS SQL Server and Sybase. In MS SQL Server and Sybase, a pointer to the IMAGE or TEXT data is stored with the rows in the table while the IMAGE or TEXT data is stored separately. This arrangement allows multiple columns of IMAGE or TEXT data per table. In Oracle, IMAGE data may be stored in a BLOB type field and TEXT data may be stored in a CLOB type field. Oracle allows multiple BLOB and CLOB columns per table. BLOBS and CLOBS may or may not be stored in the row depending on their size.
If the MS SQL Server and Sybase TEXT column is such that the data never exceeds 4000 bytes, convert the column to an Oracle VARCHAR2 data type column instead of a CLOB column. An Oracle table can define multiple VARCHAR2 columns. This size of TEXT data is suitable for most applications.
This MS SQL Server and Sybase T-SQL-specific enhancement to SQL allows users to define and name their own data types to supplement the system data types. A user-defined data type can be used as the data type for any column in the database. Defaults and rules (check constraints) can be bound to these user-defined data types, which are applied automatically to the individual columns of these user-defined data types.
While migrating to Oracle PL/SQL, you must determine the base data type for each user-defined data type, to find the equivalent PL/SQL data type. Note that user-defined data types make the data definition language code and procedural SQL code less portable across different database servers.
You can define a primary key for a table in MS SQL Server or Sybase. Primary keys can be defined in a CREATE TABLE statement or an ALTER TABLE statement.
Oracle provides declarative referential integrity. A primary key can be defined as part of a CREATE TABLE or an ALTER TABLE statement. Oracle internally creates a unique index to enforce the integrity.
You can define a foreign key for a table in MS SQL Server or Sybase. Foreign keys can be defined in a CREATE TABLE statement or an ALTER TABLE statement.
Oracle provides declarative referential integrity. A CREATE TABLE or ALTER TABLE statement can add foreign keys to the table definition. Please refer to Oracle8i Concepts, Release 2 (8.1.6) (Part Number A76965-01), for details of the functionality that is possible for referential integrity constraints.
You can define a unique key for a table in MS SQL Server or Sybase. Unique keys can be defined in a CREATE TABLE statement or an ALTER TABLE statement.
Oracle defines unique keys as part of CREATE TABLE or ALTER TABLE statements. Oracle internally creates unique indexes to enforce these constraints.
Unique keys map one-to-one from MS SQL Server and Sybase to Oracle.
Check constraints can be defined in a CREATE TABLE statement or an ALTER TABLE statement in MS SQL Server or Sybase. Multiple check constraints can be defined on a table. A table-level check constraint can reference any column in the constrained table. A column can have only one check constraint. A column-level check constraint can reference only the constrained column. These check constraints support complex regular expressions.
Oracle defines check constraints as part of the CREATE TABLE or ALTER TABLE statements. A check constraint is defined at the TABLE level and not at the COLUMN level. Therefore, it can reference any column in the table. Oracle, however, does not support complex regular expressions.
create rule phone_rule as @phone_number like "([0-9][0-9][0-9])[0-9][0-9][0-9]-[0-9][0-9][0-9][0-9]"
This rule will pass all the phone numbers that resemble the following:
(650)506-7000
This rule will fail all the phone numbers that resemble the following:
650-506-7000
650-GET-HELP
There are a few ways to implement this INTEGRITY constraint in Oracle:
Table-level check constraints from MS SQL Server and Sybase databases map one-to-one with Oracle check constraints. You can implement the column-level check constraints from the MS SQL Server or Sybase database to Oracle table-level check constraints. While converting the regular expressions, convert all simple regular expressions to check constraints in Oracle. MS SQL Server and Sybase check constraints with complex regular expressions can be either reworked as check constraints including a combination of simple regular expressions, or you can write Oracle database triggers to achieve the same functionality.
This chapter provides detailed descriptions of the differences in data types used by MS SQL Server, Sybase, and Oracle databases. Specifically, this chapter contains the following information:
TEXT and IMAGE data types in MS SQL Server and Sybase follow the rules listed below:
Recommendations
In addition to the data types listed in Table 2-2, users can define their own data types in MS SQL Server and Sybase databases. These user-defined data types translate to the base data types that are provided by the server. They do not allow users to store additional types of data, but can be useful in implementing standard data types for an entire application.
Data types can easily be mapped from MS SQL Server and Sybase to Oracle with the equivalent data types listed in the above table. The Migration Workbench converts user-defined data types to their base type. You can defined how the base type is mapped to an Oracle type in the Data Type Mappings page in the Options dialog.
This section provides a detailed description of the conceptual differences in data storage for the MS SQL Server, Sybase, and Oracle databases.
Specifically, it contains the following information:
Recommendations:
The conceptual differences in the storage structures do not affect the conversion process directly. However, the physical storage structures need to be in place before conversion of the database begins.
Oracle, MS SQL Server, and Sybase all have a way to control the physical placement of a database object. In MS SQL Server and Sybase, you use the ON SEGMENT clause and in Oracle you use the TABLESPACE clause.
An attempt should be made to preserve as much of the storage information as possible when converting from MS SQL Server or Sybase to Oracle. The decisions that were made when defining the storage of the database objects for MS SQL Server or Sybase should also apply for Oracle. Especially important are initial object sizes and physical object placement.
This section compares the following MS SQL Server, Sybase, and Oracle schema objects:
Each schema object is compared in separate tables based on create, alter, drop, grant, revoke, and truncate where applicable. Most tables are divided into the following four sections:
Each table is followed by a recommendations section that contains important information about conversion implications.
This section contains the following tables for the schema object Alias:
Recommendations:
A user account can be created for each alias set up on MS SQL Server or Sybase. The same privileges as the base user ID can be granted to this account.
Recommendations:
Oracle does not have aliases. The MS SQL Server and Sybase alias dropping information is provided for reference.
This section contains the following tables for the schema object Database:
Recommendations:
Because of the conceptual differences between the two databases, the best approach is to create the database manually in Oracle. Sizing and backup methods chosen for MS SQL Server and Sybase often apply nearly as well for Oracle. Care should be taken to ensure that sizing and backup information learned by using MS SQL Server or Sybase is passed on to the Oracle database.
MS SQL Server and Sybase applications that use two or more databases on the same server usually translate to one Oracle database with several tablespaces and a different user for each tablespace.
In most cases, the MS SQL Server or Sybase application should be converted so that one server in MS SQL Server or Sybase is converted to one Oracle database instance.
The ability to backup/restore individual databases in MS SQL Server or Sybase is provided by creating one Oracle tablespace for each MS SQL Server or Sybase database. Then DBAs can perform the same backup/restore by tablespace on Oracle that they could by database in MS SQL Server or Sybase.
The ability of MS SQL Server and Sybase to keep logical sets of tables together in databases is accomplished in Oracle by creating tablespaces.
The use of tablespaces in Oracle can provide all the same benefits of multiple databases per server in MS SQL Server and Sybase. However, if there are several completely unrelated databases in the same server in MS SQL Server or Sybase, it may make sense to split them into completely different database instances in Oracle.
Recommendations:
Oracle functionality exceeds that of MS SQL Server and Sybase. There should be no conversion implications.
Recommendations:
Oracle does not have a command to drop a database because there will only be one database per instance. The process for removing an Oracle database is the same as the process for removing an MS SQL Server or Sybase server. The CREATE DATABASE command destroys an existing database if it has the same name as the database being created.
If a database is considered equivalent to a tablespace in Oracle, the DROP TABLESPACE command in Oracle is equivalent to the DROP DATABASE command in MS SQL Server or Sybase.
This section contains the following tables for the schema object Database Link:
Recommendations:
An MS SQL Server or Sybase server can support one or more databases, and all these databases can be accessed from one another by fully qualifying the object names. In many applications there is a layer that translates the object names to the actual object names with complete reference (along with the server_name, database_name, owner_name). Database links should be created for all the different servers in the Oracle application environment so that the layer mentioned would simply return the object name for Oracle installations.
The MS SQL Server or Sybase system catalogs hold information about the servers known to the local server. These tables can be read and corresponding database links can be created.
In Oracle, database links are used in distributed database environments. A two-phase commit operation is frequently needed in distributed database environments. MS SQL Server and Sybase only have a programmatic two-phase commit, which is very complex and impractical to use. Because of Oracle's straightforward transparent two-phase commit, distributed database applications are more practical in an Oracle environment.
Oracle allows links to other heterogeneous databases via Oracle Gateway technology.
Recommendations:
This command has no effect on the conversion process. Table 2-10 is provided for reference only.
This section contains the following tables for the Data and Hash Cluster schema object:
Recommendations:
Clusters improve the performance of certain queries, but they can negatively affect the performance of the INSERT and UPDATE operations and other queries.
Use clusters to store the relatively static tables that need to be joined frequently by using a specific key.
Table clusters and hash clusters should be examined as a possible performance improvement, but are not necessary in a conversion from MS SQL Server or Sybase to Oracle.
Use hashing to reduce I/O when locating rows with an equality condition.
Recommendations:
Table clusters and hash clusters should be examined as a possible performance improvement, but are not necessary in a conversion from MS SQL Server or Sybase to Oracle.
Recommendations:
Table clusters and hash clusters should be examined as a possible performance improvement, but are not necessary in a conversion from MS SQL Server or Sybase to Oracle.
This section contains the following tables for the schema object Defaults:
Recommendations:
The implementation of defaults in MS SQL Server, Sybase, and Oracle is conceptually very similar.
Defaults in MS SQL Server and Sybase can use built-in functions. These functions have to be parsed and replaced by equivalent Oracle functions. If the equivalent function is not available, you may want to make the column as NULL allowed and update it with the default value from within a trigger.
Recommendations:
Replace DROP DEFAULT statements with ALTER TABLE statements.
This section contains the following tables for the schema object Index:
Recommendations:
Index names in MS SQL Server and Sybase are only required to be unique for each table. In Oracle they must be unique for each user, regardless of the table the index is on. Change the non-unique index names when moving them to Oracle.
Clustered indexes should be replaced by primary keys in Oracle.
UNIQUE non-clustered indexes translate to UNIQUE column constraints.
Oracle never ignores rows being inserted or updated. It either performs the INSERT or UPDATE or gives an error. If MS SQL Server or Sybase indexes were created with IGNORE_DUP_KEY or IGNORE_DUP_ROW, a note should be made that the application needs to change to handle the error.
ALLOW_DUP_ROW functionality is supported in Oracle provided no other constraints are violated.
Recommendations:
This command has no effect on the conversion process. The information is provided for reference only.
Recommendations:
If applications drop multiple indexes with one DROP INDEX command, they need to be converted into multiple DROP INDEX commands in Oracle.
This section contains the following tables for the schema object Privilege:
Recommendations:
In MS SQL Server and Sybase, both grants and revokes are recorded in the system catalogues. When a user attempts an operation against the object, MS SQL Server and Sybase check to see if the user was granted authorization either directly (e.g., "GRANT SELECT ON X TO mary", to public, or via group.
They also check to see if the user was explicitly revoked access from the object at the user, public, or group level. If a permission is revoked, the REVOKE overrides all GRANTs issued. For example, the following statements are executed in MS SQL Server or Sybase:
GRANT SELECT ON X TO public; REVOKE SELECT ON X FROM bob;
When user "bob" attempts to select on object "X" in the database, MS SQL Server or Sybase sees if bob, public, or the group of which Bob is currently a member, has select on the object (they do) and it is not true that bob, public, or the group of which Bob is currently a member has been revoked select (Bob has). Bob cannot access object X but everyone else can.
Oracle does not allow this kind of granting and revoking because it results in an unmanageable tangle of grants and revokes. Oracle enforces the idea that if a privilege is granted to public, then everyone has the privilege, without exceptions. If it is not accessible to everyone, then it should not be granted to public.
While converting the privileges from MS SQL Server or Sybase to Oracle, all the anti-grants should be resolved before creating the DDL for Oracle. All the privileges should be additive privileges.
Recommendations:
While converting the privileges from MS SQL Server or Sybase to Oracle, all the anti-grants should be resolved before creating the DDL for Oracle.
All the privileges should be additive privileges.
This section contains the following tables for the schema object Profile:
Recommendations:
Although profiles are not required in converting from MS SQL Server or Sybase to Oracle, they should be investigated and used wherever possible to aid the DBA in controlling system use.
Recommendations:
Although profiles are not required in converting from MS SQL Server and Sybase to Oracle, they should be investigated and used wherever possible to aid the DBA in controlling system use.
Recommendations:
Although profiles are not required in converting from MS SQL Server and Sybase to Oracle, they should be investigated and used wherever possible to aid the DBA in controlling system use.
This section contains the following tables for the schema object Role:
Recommendations:
Oracle roles and MS SQL Server or Sybase groups/roles can all be granted privileges. This concept is similar in MS SQL Server, Sybase, and Oracle because it is used mainly to give a set of privileges to a set of users.
In MS SQL Server and Sybase, you make all the users members of one group and grant a set of privileges to the group. In Oracle, you create a role with a set of privileges and then grant this role to a number of users.
To replicate the functionality of groups, create a role for each MS SQL Server or Sybase group and the privileges granted to each group are granted to the corresponding role. The roles are then assigned to each user. Each Oracle user would be assigned to the following two roles only:
CONNECT and the user's corresponding MS SQL Server or Sybase group.
If the MS SQL Server or Sybase application uses groups to grant the privileges and the privileges are required to create views and stored procedures, you must grant the privileges in the Oracle application to individual users as well as to roles. This is necessary because Oracle does not allow the user to build objects that refer to the objects which the user was given access to through roles.
Since many roles can be assigned to a person, it may be advisable to investigate the richer functionality of Oracle roles to see if more logical groupings of privileges are possible. Furthermore, since roles may be assigned other roles, you may find it more convenient to create a hierarchy of roles suitable for each application.
Recommendations:
Oracle roles and MS SQL Server or Sybase groups can both be granted privileges. Each MS SQL Server or Sybase user can only belong to one group, but each Oracle user can have many roles. This concept is similar in MS SQL Server, Sybase, and Oracle databases because it is used mainly to give a set of privileges to a set of users. In MS SQL Server and Sybase, you make all the users members of one group and give a set of privileges to the group. In Oracle, you create a role with a set of privileges and then grant this role to a group of users.
To replicate the functionality of groups, create a role for each MS SQL Server or Sybase group and the privileges granted to each group are granted to the corresponding role. The roles are then assigned to each user. Each Oracle user would be assigned the following two roles only: CONNECT and the user's corresponding MS SQL Server or Sybase group.
In Oracle, the SET ROLE command can be used to switch between roles.
If the MS SQL Server or Sybase application uses groups to grant the privileges and the privileges are required to create views and stored procedures, you must grant the privileges in the Oracle application to individual users as well as to roles.
Recommendations:
Oracle functionality directly matches or exceeds that of MS SQL Server and Sybase. There should be no conversion implications.
This section contains the following tables for the schema object Rule:
Recommendations:
Oracle allows check constraints in tables for simple business rules. Triggers may be used for more complex rules.
The LIKE clause in MS SQL Server and Sybase rules can accept wildcard characters and ranges of values while the Oracle LIKE clause accepts only wildcard characters. If the rule has ranges of values (it uses regular expressions), it can be translated using a combination of SUBSTR and TRANSLATE in an Oracle check constraint.
MS SQL Server and Sybase integrity constraints can be implemented as check constraints in Oracle. See the Tables section for information about check in table constraints.
The column reference in the MS SQL Server or Sybase rule definition is not a column name. A rule is bound to the database column. The @var_name should be parsed out and replaced by this column name if you convert the RULEs to check constraint.
Recommendations:
Sequences are very useful and are very efficient. You should replace the equivalent code in MS SQL Server or Sybase that generates unique IDs with references to sequences.
This sections contains the following tables for the schema object Sequence:
Recommendations:
ALTER SEQUENCE does not allow you to set the next value a sequence will generate. To set the next value of a sequence, either change the increment, select the next value, and change the increment back, or drop and recreate the sequence.
Recommendations:
This command does not affect database conversion. The information is provided for reference only.
This section contains the following table for the schema object Snapshot:
Recommendations:
While converting a distributed database application from MS SQL Server or Sybase to Oracle, you should look for situations requiring constant availability of remote information and handle them using table snapshots. Refer to Oracle8i Replication Management API Reference, Release 2 (8.1.6) (Part Number: A76958-01) for more information about the DBMS_REPCAT package.
This section contains the following tables for the schema object Synonym:
Recommendations:
This command does not affect database conversion. The information is provided for reference only.
Oracle uses synonyms to build location transparency for objects in distributed database applications.
Recommendations:
This command does not affect database conversion. The information is provided for reference only.
This section contains the following tables for the schema object Tables:
Recommendations:
The conceptual definition of tables is the same in MS SQL Server, Sybase, and Oracle.
Reserved Words
Be aware that table names and column names in MS SQL Server and Sybase can be reserved words in Oracle.
Defaults
Convert MS SQL Server and Sybase defaults to be created as part of the table creation in Oracle.
NULL/Not NULL
CREATE TABLE should always specify the NULL/NOT NULL constraint as the default is the opposite in MS SQL Server, Sybase, and Oracle.
Row-Migration
Row migration occurs when a row is updated and increases in size until it no longer fits in the block at which time it must be moved to another block. Migration may also occur when rows grow in size and PCTFREE is not set correctly.
Row-Chaining
Row-chaining can occur when one row exceeds the size of one data block and has to be stored as a chain of data blocks. This affects all types of operations on this table. Oracle users can set the block size for their database to avoid such situations.
If MS SQL Server or Sybase tables have large record sizes, it may be necessary to increase the block size in Oracle to avoid row chaining problems.
Unique Keys
Define unique keys for columns defined in MS SQL Server and Sybase as unique non-clustered index.
Storage
The storage specifications for index must be added manually.
Data Types
MS SQL Server and Sybase data types should be translated to equivalent Oracle data types. See the Data Types section of this chapter for a table of equivalent data types.
Recommendations:
Oracle functionality exceeds that of MS SQL Server and Sybase. There should be no conversion implications.
Recommendations:
Convert MS SQL Server and Sybase applications that drop multiple tables with one DROP TABLE command into multiple DROP TABLE commands in Oracle.
Recommendations:
Oracle functionality directly matches or exceeds that of MS SQL Server and Sybase. There should be no conversion implications.
This section contains the following tables for the schema object Tablespace:
Recommendations:
Tablespaces have some features in common with MS SQL Server and Sybase "databases" and some features in common with MS SQL Server and Sybase "segments".
As part of the conversion process, the structure of the Oracle database must be determined. It should be based on how databases and devices are used in MS SQL Server and Sybase.
Tablespaces and Databases
Oracle tablespaces and MS SQL Server and Sybase databases are similar in the following respects:
Tablespaces and Segments
Oracle tablespaces and MS SQL Server and Sybase segments both provide the control over the physical location of the database objects.
However, Oracle provides features that MS SQL Server and Sybase do not, such as default storage information and usage quotas.
This section contains the following tables for the schema object User:
Recommendations:
MS SQL Server, Sybase, and Oracle treat the individual users in a very similar way, and the conversion is straightforward.
The user SA in MS SQL Server and Sybase is roughly equivalent to the user SYSTEM in Oracle. The user who is the DBO in MS SQL Server or Sybase can be converted to have DBA privileges in Oracle.
Recommendations:
There should be no conversion implications.
Recommendations:
Oracle functionality is similar to that of MS SQL Server and Sybase. There should be no conversion implications.
This section contains the following tables for the schema object View:
Recommendations:
View text may include some MS SQL Server and Sybase-specific SQL constructs which must be converted manually. Also, the MS SQL Server and Sybase views that use GROUP BY and aggregates need one or more view equivalents to get the same results in Oracle.
Also see the INSERT, SELECT, UPDATE, and DELETE statements in the Data Manipulation Language section of this chapter for more information in this regard.
Recommendations:
ALTER VIEW has no effect on database conversion. This information is provided for reference only.
Recommendations:
MS SQL Server and Sybase applications that drop multiple views with one DROP VIEW command must have those commands converted to multiple
DROP VIEW commands in Oracle.
This section uses tables to compare the syntax and description of Data Manipulation Language (DML) elements in the MS SQL Server, Sybase, and Oracle databases. Each table is followed by a recommendations section based on the information in the tables. The following topics are presented in this section:
The statement illustrated in the following table connects a user to a database.
Recommendations:
This concept of connecting to a database is conceptually different in the MS SQL Server, Sybase, and Oracle databases. An MS SQL Server or Sybase user can log on to the server and switch to another database residing on the server, provided the user has privileges to access that database. An Oracle Server controls only one database, so here the concept of a user switching databases on a server does not exist. Instead, in Oracle a user executes the SET ROLE command to change roles or re-issues a CONNECT command using a different user_name.
The statement in the following table retrieves rows from one or more tables or views.
MS SQL Server and Sybase support SELECT statements that do not have a FROM clause. This can be seen in the following example
SELECT getdate()
Oracle does not support SELECTs without FROM clauses. However, Oracle provides the DUAL table which always contains one row. Use the DUAL table to convert constructs such as the one above.
Translate the above query to:
SELECT sysdate FROM dual;
The MS SQL Server and Sybase SELECT INTO statement can insert rows into a table. This construct, which is part SELECT and part INSERT, is not supported by ANSI. Replace these statements with INSERT...SELECT statements in Oracle.
If the MS SQL Server or Sybase construct is similar to the following:
SELECT col1, col2, col3 INTO target_table FROM source_table WHERE where_clause
you should convert it to the following for Oracle:
INSERT into target_table SELECT col1, col2, col3 FROM source_table WHERE where_clause
In MS SQL Server and Sybase, a SELECT statement may appear anywhere that a column specification appears. Oracle does not support this non-ANSI extension to ANSI SQL. Change the subquery in the SELECT list either by using a DECODE statement or by dividing the query into two different queries.
Use the following SALES table as a basis for the examples below:
Year
Qty
Amount
1993
1
1.3
1993
2
1.4
1993
3
3
1993
4
2.3
If you want to select the year, q1 amount, q2 amount, q3 amount, and q4 as a row, MS SQL Server and Sybase accept the following query:
SELECT distinct year, q1 = (SELECT amt FROM sales WHERE qtr=1 AND year = s.year), q2 = (SELECT amt FROM sales WHERE qtr=2 AND year = s.year), q3 = (SELECT amt FROM sales WHERE qtr=3 AND year = s.year), q4 = (SELECT amt FROM sales WHERE qtr=4 AND year = s.year) FROM sales s
In this example, replace the SELECT statements with DECODE so that the query functions as normal. The DECODE function is much faster than MS SQL Server and Sybase subqueries. Translate the above query to the following for Oracle:
SELECT year, DECODE( qtr, 1, amt, 0 ) q1, DECODE( qtr, 2, amt, 0 ) q2, DECODE( qtr, 3, amt, 0 ) q3, DECODE( qtr, 4, amt, 0 ) q4 FROM sales s;
If you cannot convert your query using the above method, create views and base the query on the views rather than on the original tables.
For example, consider the following query in MS SQL Server and Sybase:
SELECT name, sumlength = (SELECT sum(length) FROM syscolumns WHERE id = t.id), count_indexes = (SELECT count(*) FROM sysindexes WHERE id = t.id) FROM sysobjects t
This query returns the sum of the lengths of the columns of a table and the number of indexes on that table. This is best handled in Oracle by using some views.
Convert this to the following in Oracle:
CREATE view V1 ( sumlength, oid ) as SELECT sum(length), id FROM syscolumns GROUP BY id CREATE view V2 ( count_indexes, oid ) AS SELECT count(*), id FROM sysindexes GROUP BY id SELECT name, sumlength, count_indexes FROM sysobjects t, v1, v2 WHERE t.id = v1.oid AND t.id = v2.oid
MS SQL Server and Sybase also allow a SELECT statement in the WHERE clause. For example, consider the following statement from MS SQL Server or Sybase:
SELECT empname, deptname FROM emp, dept WHERE emp.empno = 100 AND(SELECT security_code FROM employee_security WHERE empno = emp.empno) = (SELECT security_code FROM security_master WHERE sec_level = dept.sec_level)
Convert this to the ANSI-standard statement below for Oracle:
SELECT empname, deptname FROM emp, dept WHERE emp.empno = 100 AND EXISTS (SELECT security_code FROM employee_security es WHERE es.empno = emp.empno AND es.security_code = (SELECT security_code FROM security_master WHERE sec_level = dept.sec_level));
Convert column aliases from the following MS SQL Server or Sybase syntax:
SELECT employees=col1 FROM tab1
to the following Oracle syntax:
SELECT col1 employees FROM tab1
Remove table aliases (also known as correlation names) unless they are used everywhere.
Replace the COMPUTE clause with another SELECT. Attach the two sets of results using the UNION clause.
Convert the outer JOIN syntax from the MS SQL Server or Sybase syntax to the Oracle syntax.
In addition to these, there are many implications due to the differences in the implementation of the special clauses such as GROUP BY, functions, joins. These are discussed later in this chapter.
The statements illustrated in the following table add one or more rows to the table or view.
Recommendations:
INSERT statements in MS SQL Server and Sybase must be changed to include an INTO clause if it is not specified in the original statement.
The values supplied in the VALUES clause in either database may contain functions. The MS SQL Server-specific functions must be replaced with the equivalent Oracle constructs.
Convert inserts that are inserting into multi-table views in MS SQL Server and Sybase to insert directly into the underlying tables in Oracle.
The statement illustrated in the following table updates the data in a table or the data in a table referenced by a view.
Recommendations:
There are two ways to convert UPDATE statements with FROM clauses as indicated below.
Use the subquery in the SET clause if columns are being updated to values coming from a different table.
Convert the following in MS SQL Server or Sybase:
update titles SET pub_id = publishers.pub_id FROM titles, publishers WHERE titles.title LIKE 'C%' AND publishers.pub_name = 'new age'
to the following in Oracle:
UPDATE titles SET pub_id = ( SELECT a.pub_id FROM publishers a WHERE publishers.pub_name = 'new age' ) WHERE titles.title like 'C%'
Use the subquery in the WHERE clause for all other UPDATE...FROM statements.
Convert the following in MS SQL Server or Sybase:
UPDATE shipping_parts SET qty = 0 FROM shipping_parts sp, suppliers s WHERE sp.supplier_num = s.supplier_num AND s.location = "USA"
to the following in Oracle:
UPDATE shipping_parts SET qty = 0 WHERE supplier_num IN ( SELECT supplier_num FROM suppliers WHERE location = 'USA')
The statement illustrated in the following table removes rows from tables and rows from tables referenced in views.
Remove the second FROM clause from the DELETE statements.
Convert the following MS SQL Server or Sybase query:
DELETE FROM sales FROM sales, titles WHERE sales.title_id = titles.title_id AND titles.type = 'business'
to the following in Oracle:
DELETE FROM sales WHERE title_id in ( SELECT title_id FROM titles WHERE type = 'business' )
Remove the second FROM even if the WHERE contains a multi-column JOIN.
Convert the following MS SQL Server or Sybase query:
DELETE FROM sales FROM sales, table_x WHERE sales.a = table_x.a AND sales.b = table_x.b AND table_x.c = 'd'
to the following in Oracle:
DELETE FROM sales WHERE ( a, b ) in ( SELECT a, b FROM table_x WHERE c = 'd' )
The following table compares the operators used in the MS SQL Server, Sybase, and Oracle databases. Comparison operators are used in WHERE clauses and COLUMN check constraints/rules to compare values
Recommendations:
1. Convert all !< and !> to >= and <=
Convert the following in MS SQL Server or Sybase:
WHERE col1 !< 100
to this for Oracle:
WHERE col1 >= 100
2. Convert like comparisons which use [ ] and [^]
SELECT title FROM titles WHERE title like "[A-F]%"
Method 1 - Eliminating use of [ ]:
Use this method with the SUBSTR () function if possible.
SELECT title from titles where substr (titles,1,1) in ('A', 'B', 'C', 'D', 'E', 'F')
Method 2 - Eliminating use of [ ]:
The second method uses the % construct.
SELECT title FROM titles WHERE (title like 'A%' OR title like 'B%' OR title like 'C%' OR title like 'D%' OR title like 'E%' OR title like 'F%')
3. Change NULL constructs:
The following table shows that in Oracle, NULL is never equal to NULL. Change the all = NULL constructs to IS NULL to retain the same functionality.
If you have the following in MS SQL Server or Sybase:
WHERE col1 = NULL
Convert it as follows for Oracle:
WHERE col1 IS NULL
Operator | Same in All Three Databases | MS SQL Server/Sybase Only | Oracle Only |
---|---|---|---|
Add |
+ |
|
|
Subtract |
- |
|
|
Multiply |
* |
|
|
Divide |
/ |
|
|
Modulo |
v |
% |
mod(x, y) |
Recommendations:
Replace any Modulo functions in MS SQL Server or Sybase with the mod() function in Oracle.
Operator | Same in All Three Databases | MS SQL Server/Sybase Only | Oracle Only |
---|---|---|---|
Concatenate |
s |
+ |
|| |
Identify Literal |
'this is a string' |
"this is also a string" |
|
Recommendations:
Replace all addition of strings with the || construct.
Replace all double quotes string identifiers with single quote identifiers.
In MS SQL Server and Sybase, an empty string ('') is interpreted as a single space in INSERT or assignment statements on VARCHAR data. In concatenating VARCHAR, CHAR, or TEXT data, the empty string is interpreted as a single space. The empty string is never evaluated as NULL. You must bear this in mind when converting the application.
Operator | Same in All Three Databases | MS SQL Server/Sybase Only | Oracle Only |
---|---|---|---|
bit and |
|
& |
|
bit or |
|
| |
|
bit exclusive or |
|
^ |
|
bit not |
|
~ |
|
Recommendations:
Oracle enables you to write your own procedures to perform bitwise operations.
If you have the following MS SQL Server or Sybase construct:
X | Y :(Bitwise OR)
You could write a procedure called dbms_bits.or (x,y) and convert the above construct to the following in Oracle:
dbms_bits.or(x,y)
Recommendations:
Oracle adds the ability to define functions. With this feature you can create Oracle functions that match the name and function of MS SQL Server and Sybase functions.
Recommendations:
The above table lists all the MS SQL Server and Sybase date manipulation functions. It does not list all the Oracle date functions. There are many more Oracle date manipulation functions that you can use.
It is recommended that you convert most date manipulation functions to "+" or "-" in Oracle.
Oracle adds the ability to define functions. With this feature you can create Oracle functions that match the name and functionality of all MS SQL Server and Sybase functions. This is a useful feature, where users can call a PL/SQL function from a SQL statement's SELECT LIST, WHERE clause, ORDER BY clause, and HAVING clause. With the parallel query option, Oracle executes the PL/SQL function in parallel with the SQL statement. Hence, users create parallel logic.
Recommendations:
The above table lists all the MS SQL Server and Sybase number manipulation functions. It does not list all the Oracle mathematical functions. There are many more Oracle number manipulation functions that you can use.
Oracle adds the ability to define functions. With this feature you can create Oracle functions that match the name and functionality of all MS SQL Server and Sybase functions. This is the most flexible approach. Users can write their own functions and execute them seamlessly from a SQL statement.
Oracle functions listed in the table work in SQL as well as PL/SQL.
Locking serves as a control mechanism for concurrency. Locking is a necessity in a multi-user environment because more than one user at a time may be working with the same data.
Recommendations:
In MS SQL Server and Sybase, SELECT statements obtain shared locks on pages/rows. This prevents other statements from obtaining an exclusive lock on those pages/rows. All statements that update the data need an exclusive lock. This means that the SELECT statement in MS SQL Server or Sybase blocks the UPDATE statements as long as the transaction that includes the SELECT statement does not commit or rollback. This also means that two transactions are physically serialized whenever one transaction selects the data and the other transaction wants to change the data first and then select the data again. In Oracle, however, SELECT statements do not block UPDATE statements, since the rollback segments are used to store the changed data before it is updated in the actual tables. Also, the reader of the data is never blocked in Oracle. This allows Oracle transactions to be executed simultaneously.
If MS SQL Server or Sybase logical transactions are automatically translated to Oracle logical transactions, the transactions explained above that execute properly in MS SQL Server and Sybase as they are serialized will cause a deadlock in Oracle. These transactions should be identified and serialized to avoid the deadlock. These transactions are serialized in MS SQL Server and Sybase as INSERT, UPDATE, and DELETE statements block other statements.
Recommendations:
No changes are required to take advantage of the row-level locking feature of Oracle.
Recommendations:
Transactions are not implicit in MS SQL Server and Sybase. Therefore, applications expect that every statement they issue is automatically committed it is executed.
Oracle transactions are always implicit, which means that individual statements are not committed automatically. When converting an MS SQL Server or Sybase application to an Oracle application, care needs to be taken to determine what constitutes a transaction in that application. In general, a COMMIT work statement needs to be issued after every "batch" of statements, single statement, or stored procedure call to replicate the behavior of MS SQL Server or Sybase for the application.
In MS SQL Server and Sybase, transactions may also be explicitly begun by a client application by issuing a BEGIN TRAN statement during the conversion process.
|
![]() Copyright © 2000 Oracle Corporation. All Rights Reserved. |
|