Oracle to DB2 Version 9.1 for z/OS migration demystified!

Oracle to DB2 Version 9.1 for z/OS migration demystified! The most pragmatic resolutions, workarounds, and tips Skill Level: Intermediate Gunjan Verma ([email protected]) Technology Lead Infosys Technologies Ltd Neeraj Kakar ([email protected]) Project Manager Infosys Technologies Ltd

31 Mar 2011 This article is written for application developers and DBAs who wish to port their applications from Oracle® 10g to DB2® Version 9.1 for z/OS. Learn about specific issues that may arise and how to how to handle them.

Introduction Some of the many reasons which drive organizations to migrate their applications or products onto a different RDBMS are related to costs, scalability, compliance, performance, strategic, and others. Whatever your reasons may be, if you are in for a database migration from Oracle 10g to DB2 Version 9.1 for z/OS, this article will provide you some of the most pragmatic, easy to implement resolutions, workarounds, and tips that can save your migration effort by at least 25%, as well as a majority of your consultant costs. The migration issues mentioned in this paper are specific to DB2 Version 9.1 for z/OS. Many of them are resolved in DB2 10 for z/OS. For more information about DB2 10 for z/OS, please refer to the IBM information center.

Oracle to DB2 Version 9.1 for z/OS migration demystified! © Copyright IBM Corporation 2011

Trademarks Page 1 of 16

developerWorks®

ibm.com/developerWorks

Database migration activity is done to ensure that the same application layer is able to talk to a different RDBMS. It typically involves application layer porting, and database objects migration. This is a critical activity in any project and requires a comprehensive analysis as the two RDBMS are inherently different and things might not work on the fly. Another point to consider is whether you want to continue using the existing environment or plan to abandon it once the application is ported to the new RDBMS. You might want to maintain two environments in order to have the flexibility to choose the RDBMS. In this case there is an overhead of maintaining two environments and ensuring that they remain in sync. This article is a result of experience gained from a specific case of migration from Oracle 10g to DB2 z/OS 9.1 database. There are multiple tools available, including the Migration Toolkit (MTK) from IBM that can help in the migration process. However the output of these tools is not 100% accurate, and there is a lot of manual intervention required to make the output DB2 ready. This article will help you when you must modify tool-generated output to make it work on DB2. The article gives the specific issues that come up for each type of objects along with their resolution. This article will help product and application developers, as well as DBAs who want to port their applications from Oracle 10g to DB2 Version 9.1 for z/OS database. The target audience should have a basic knowledge of PL/SQL to be able to use the document effectively. The scope of this article is troubleshooting of database-specific technical issues faced in a migration activity. Functional issues are out of scope for this article.

Focus areas for any database migration Database migration is a comprehensive activity as the volume of changes required might be huge. All database objects and any piece of application code that talks to the database might require a change. The key focus areas for a database migration activity are: • Architectural difference between the two RDBMS: The two RDBMS might have a different architecture, and might use a different object hierarchy. • Embedded SQL coded in the application code: Embedded SQL queries might be placed in the application code for database interaction. All the raw SQL statements need to be analyzed to see whether they work on both databases, or if changes are needed. • Database objects: Database objects like tables, views, stored procedures, triggers, or user-defined-functions might have to be partially or completely changed based on the syntax followed in the target database. • Keyword differences between two databases: Some functions might be




developerWorks®

available in both the databases but with a different name. All such differences need to be taken care of. • Data type differences: There might be considerable differences in the data types between the two RDBMS.

Issues, resolutions, and tips The following section looks at some of the specific issues that were faced, resolutions to them, and tips to help you with Oracle 10g to DB2 9.1 migration. Architectural comparison between Oracle 10g and DB2 Version 9.1 for z/OS In Oracle 10g, there is a database instance which contains multiple table spaces. Each table space stores one or multiple tables. Usually tables are grouped in a table space based on their function relation and access pattern. In DB2 Version 9.1 for z/OS, there is a DB2 subsystem on the top of the hierarchy that contains multiple storage groups. A storage group is a set of volumes on a physical storage device, DASD (direct access storage devices) on the mainframe. A storage group contains database(s), and a database contains table spaces. Each table space contains one or more tables based on the type of table space. In DB2 9.1, for every BLOB/CLOB column in a table, an LOB table space, an auxiliary table, and an index must be created. If the CURRENT RULES register is set to value DB2, all these objects will have to be created explicitly for every BLOB/CLOB column. If the CURRENT RULES register is set to value STD, DB2 takes care of creating all these objects implicitly for every BLOB/CLOB column. The value of the CURRENT RULES register can be set using the following command: SET CURRENT RULES = 'STD'. This command should be used before running the table creation script for the subsystem. Creating users In Oracle 10g, users are created at database level. In DB2, users are created at operating system level. This means that if two DB2 9.1 subsystems are created on the same OS, then the same user ID used in both subsystems will have the same password. Another limitation of DB2 Version 9.1 for z/OS is that user names cannot be greater than 8 characters.

DDL conversion issues Data Definition Language (DDL) statements are used to define database schema. This section will deal with conversion issues that come up with DDL statements, like table and index creation statements.



developerWorks®


Table creation Oracle 10g implicitly creates unique indexes for primary and unique keys, but in DB2 Version 9.1 for z/OS, explicit indexes need to be created for primary and unique keys of the table if the names of table space and database are specified using the IN clause of the CREATE TABLE statement. However if the table is implicitly created without mentioning a table space and database name, the primary key and unique key indexes get created implicitly. Data types The following table gives a brief overview of Oracle 10g data types and their DB2 z/OS 9.1 equivalents. This mapping can be used while converting table creation scripts from Oracle 10g to DB2 z/OS 9.1. This is also useful to find appropriate data types for temporary variables while porting stored procedures and triggers. Table 1. Data types Oracle 10g data types

DB2 z/OS 9.1 data types

VARCHAR2(n) nVARCHAR(255…Max)

Data type of primary key columns, foreign key columns, and columns used on indexes




developerWorks®

In DB2 z/OS 9.1, columns participating in creation of primary key, foreign key or indexes cannot have a data type of DECFLOAT. If in Oracle 10g, such columns are declared to be of data type NUMBER (38), then corresponding data type in DB2 is DECFLOAT (34). You need to be careful and ensure that primary key, foreign key or index columns are declared as DECIMAL (31) or BIGINT in DB2. Unique indexes When a UNIQUE index is created on a column in Oracle 10g, it ensures that the NOT NULL values entered in that column are unique. If the column is NULLABLE, any number of NULLs can be inserted in that column. The uniqueness is ensured on the NOT NULL values. But, in DB2 z/OS if a UNIQUE index is created on a column, then only one NULL value can be inserted into it. In order to emulate the Oracle 10g behavior, UNIQUE WHERE NOT NULL index needs to be created in DB2, for example: CREATE UNIQUE WHERE NOT NULL INDEX IX_TEST ON TEST(COL1).

DML conversion issues Data Definition Language (DDL) statements help in managing data in the database. This section deals with specific issues that come up during conversion of DML statements like SELECT. Type-casting Oracle 10g supports implicit type-casting, but DB2 Version 9.1 for z/OS does not. For example, in Oracle, a string '1' can be compared with a numeric 1, but in DB2, explicit type-casting needs to be done. Although implicit type-casting is supported by Oracle, as a good programming practice, it should be avoided. Similar columns in different tables should be declared with same data types, so that the implicit type-casting facility of Oracle is not used. If implicit type-casting has already been used in application code or database objects, then while migrating to DB2, you should move to explicit type-casting. Table 2 shows an example of type-casting. Table 2. Type-casting Original query

Modified query

SELECT * FROM TEST WHERE COL1 = 1

SELECT * FROM TEST WHERE COL1 = ‘1’

Assumption: COL1 of TEST is of type CHAR(20). Here the original query is comparing a string to a number but in the modified query, explicit type-casting has been done.



developerWorks®


Index bypassing during type-casting: A word of caution here is that indexes will be bypassed when an indexed column is type-cast. If you assume that there is an index on COL1 in the above example, if COL1 is type-cast instead of the RHS, then the index will be bypassed and the query will perform a full table scan. Conclusion: Type-casting can be done, but with caution. If the index is being bypassed, then the RHS of the comparison should be type-cast. ANSI joins Oracle 10g supports non ANSI syntax for JOINS but DB2 Version 9.1 for z/OS does not. For example, the following join works in Oracle but not in DB2: SELECT A, B FROM TEST1, TEST2 WHERE A.TEST1 = B.TEST2(+). In DB2, the above JOIN needs to be converted into an ANSI JOIN by using: SELECT A, B FROM TEST1 LEFT OUTER JOIN TEST2 ON A.TEST1 = B.TEST2. It is good coding practice to follow ANSI standards. In case of a migration activity, all queries should be converted so that they follow ANSI format. Addressing Oracle non-available functions in DB2 Certain Oracle 10g functions like CHAR, CONCAT, TRIM, and ROUND are either not available in DB2 Version 9.1 for z/OS directly, or use a different set of arguments. UDFs can be coded for all such functions in DB2 so that they exactly replicate the Oracle functionality. All these UDFs can be placed into a single schema like a MIG schema, and the SQL function path can be set in such a way that this migration schema is searched first for UDF calls. The SQL function path can be set as: SET PATH MIG, SYSTEM PATH, USER. Keyword differences There are certain functions or keywords which are available in both Oracle 10g and DB2 Version 9.1 for z/OS, but with different names. See Table 3 for an example of name comparisons: Table 3. Comparable names in Oracle 10g and DB2 for z/OS 9.1 Name in Oracle 10g

Name in DB2 z/OS 9.1

NVL

COALESCE

DECODE

CASE

SYSDATE

CURRENT TIMESTAMP

Such keywords or functions might be used in raw queries coded in the application code. If the same application code must cater to both Oracle and DB2 databases, then you will have to use IF-ELSE blocks coded for all such instances where the




developerWorks®

Oracle-specific keyword or function name is supplied in the IF part, and DB2 specific keyword or function name is supplied in the ELSE part. This type of code is error-prone and less maintainable because there is a high possibility of a developer updating the Oracle part and missing the DB2 part or vice-versa. An alternative approach that you can follow is to have a utility class, as in the case of Java. This utility class can have functions for all such keywords or functions. For example, a utility class function called NVL would return NVL if the database connection is with Oracle, and COALESCE if the DB connection is with DB2. If you name this utility class as MigrationClass, then all instances of NVL in the application will have to be replaced with MigrationClass.NVL. If you have the following query in the application: SELECT NVL(COL1,1) from TEST, then the NVL function needs to be coded in the migration class as:

MigrationClass.Nvl(string COL1,int number) { If (oracle server) { Return “NVL(COL1,1)”; } Else If (db2 server) { Return “COLESCE(COL1,1)”; } }

The query would be changed to: SELECT MigrationClass.NVL(COL1,1) from TEST. At runtime, the final query generated for Oracle would be: SELECT NVL(COL1,1) from TEST. For DB2, the query generated would be: SELECT COALESCE (COL1,1) from TEST. ROWNUM The equivalent for ROWNUM in DB2 z/OS 9.1 is FETCH FIRST N ROWS ONLY. So if an Oracle 10g query uses ROWNUM < 10 in WHERE clause, the DB2 z/OS 9.1 equivalent would be FETCH FIRST 9 ROWS ONLY. What if the query says ROWNUM = 100? There is no direct equivalent for this in DB2. You could use the SUBTRACT operator in DB2, as shown in Table 4, although this is just one of many possible ways to achieve the same result. Table 4. SUBTRACT operator Oracle 10g query


DB2 z/OS 9.1 equivalent


developerWorks®


SELECT * FROM TEST WHERE ROWNUM = 10 SELECT * FROM TEST FETCH FIRST 10 ROWS ONLY SUBTRACT SELECT * FROM TEST FETCH FIRST 9 ROWS ONLY

NULL and empty strings Oracle treats empty strings and NULL as the same, but DB2 treats them differently. Whatever is entered as empty string in Oracle gets stored as NULL internally in the database. The following shows an example of a TEST table created in Oracle and DB2:

CREATE INSERT INSERT INSERT INSERT INSERT

TABLE TEST (ID INT, NAME CHAR(20) INTO TEST VALUES (1, NULL) INTO TEST VALUES (2, ‘’) INTO TEST VALUES (3, NULL) INTO TEST VALUES (4, NULL) INTO TEST VALUES (5, ‘’)

Now look at Table 5 to see the behavior of various SELECT commands in Oracle 10g and DB2 z/OS 9.1: Table 5. Select commands in Oracle and DB2 z/OS 9.1 Query

Oracle result

DB2 result

SELECT ID FROM TEST WHERE NAME IS NULL

1,2,3,4,5

1,3,4

SELECT ID FROM TEST WHERE NAME = ‘’

No Result as all the values got stored as NULL

2,5

SELECT ID FROM TEST WHERE NAME IS NOT NULL

No Result as all the values got stored as NULL

2,5

It is evident from the examples in Table 5 that an empty string comparison in Oracle 10g is redundant and does not fetch anything. In order to fetch the same results in DB2 Version 9.1 for z/OS on a NULL comparison, the first query needs to be re-coded in DB2 as: SELECT ID FROM TEST WHERE NAME IS NULL or NAME =’’.

DCL conversion issues This section deals with specific issues that come up during conversion of Data Control Language (DCL) statements like GRANT and REVOKE. GRANT/REVOKE syntax




developerWorks®

GRANT and REVOKE statement syntax is different for sequences, procedures and functions in Oracle 10g and DB2 z/OS 9.1. In DB2, the type of object needs to be mentioned on the GRANT or REVOKE statement. For example:

GRANT SELECT ON SEQUENCE TESTID TO USER1 GRANT EXECUTE ON PROCEDURE SP_TEST TO USER1 GRANT EXECUUTE on FUNCTION FN_TEST TO USER1

PL/SQL specific issues There are many syntax differences pertaining to PL/SQL objects like Procedures, functions, and triggers in Oracle and DB2. This section deals with these syntax differences and conversion issues. AFTER triggers In DB2 z/OS 9.1, AFTER triggers have some limitations, for example: • Multiple BEGIN-END blocks not allowed • Exception block not allowed • DECLARE statement is not allowed inside a trigger body • IF-ELSE not allowed The following two options are used to port AFTER triggers from Oracle 10g to DB2 z/OS 9.1: • Move the trigger logic to application layer and get away from the trigger. • Move the trigger logic to a stored procedure and call the stored procedure from the trigger. See Table 6 for an illustration of how this works. Table 6. Oracle and DB2 z/OS AFTER trigger Oracle trigger

DB2 z/OS 9.1 trigger

CREATE OR REPLACE TRIGGER TR_EMPLOYEE AFTER INSERT ON EMPLOYEE REFERENCING NEW AS NEW FOR EACH ROW DECLARE MANAGERID INTEGER; MANAGERTYPE CHAR(1); BEGIN MANAGERID := :NEW.MANAGER; MANAGERTYPE := :NEW.MANAGERTYPE;

DROP TRIGGER TR_EMPLOYEE! CREATE TRIGGER TR_EMPLOYEE AFTER INSERT ON EMPLOYEE REFERENCING NEW AS NEW FOR EACH ROW MODE DB2SQL BEGIN ATOMIC CALL SP_TR_EMPLOYEE(NEW.MANAGER,NEW.MANAGERTYPE); END! DROP PROCEDURE



developerWorks®

IF(MANAGERTYPE = 'O') THEN SP_UPDATE(MANAGERID); ELSE SP_INSERT(MANAGERID); END IF; END; /


SP_TR_EMPLOYEE! CREATE PROCEDURE SP_TR_EMPLOYEE(IN NEW_MANAGER INTEGER, IN NEW_MANAGERTYPE CHAR(1)) BEGIN IF NEW_MANAGERTYPE = 'O' THEN CALL SP_UPDATE(NEW_MANAGER); ELSE CALL SP_INSERT(NEW_MANAGER); END IF; END!

BEFORE trigger conversion In DB2 z/OS 9.1, BEFORE triggers have the following limitations: • Multiple BEGIN-END blocks not allowed • Exception block not allowed • DECLARE statement not allowed inside Trigger body • IF-ELSE not allowed • DML statements not allowed In most instances, before triggers are used to set values of transition variables. In this case, one of the options is to try and recode the BEFORE trigger so that it follows DB2 standards, as shown in Table 7: Table 7. Oracle and DB2 z/OS BEFORE trigger Original Oracle trigger

DB2 z/OS 9.1 trigger

CREATE OR REPLACE TRIGGER ORAEMP BEFORE INSERT ON EMPLOYEE FOR EACH ROW DECLARE EMPID NUMBER; BEGIN IF (:NEW.EMPLOYEEID IS NULL) THEN SELECT SEQEMPVALID.NEXTVAL INTO EMPID FROM DUAL ; :NEW.EMPLOYEEID := EMPID ; END IF; END; /

CREATE TRIGGER ORAEMP NO CASCADE BEFORE INSERT ON EMPLOYEE REFERENCING NEW AS NEW FOR EACH ROW MODE DB2SQL BEGIN ATOMIC SET (NEW.EMPLOYEEID) = (CASE WHEN NEW.EMPLOYEEID IS NULL THEN NEXT VALUE FOR SEQEMPVALID ELSE NEW.EMPLOYEEID END); END!

Here DECLARE and IF ELSE statements are present in trigger.

Here DECLARE statements have been removed. IF ELSE has been replaced with CASE.

Another option is to convert a BEFORE trigger to an AFTER trigger, as long as it does not affect the functionality. The third option is to move trigger logic to application layer and get from the trigger. BEFORE triggers and not NULL constraint precedence In Oracle 10g, if there is a BEFORE INSERT TRIGGER and a NOT NULL constraint on a table, then the BEFORE TRIGGER is executed first, and then the constraint




developerWorks®

check is performed. For example, if a before trigger supplies value to a NOT NULL column, then the BEFORE trigger is executed first and a value is supplied to the column so that the NOT NULL constraint isn't violated. In DB2 Version 9.1 for z/OS, on the other hand, the NOT NULL constraint is evaluated before the BEFORE trigger. So in the example above, the NOT NULL constraint would get violated, and the INSERT statement would error out. A workaround to this is to supply a default value to the NOT NULL column whose value comes from a BEFORE INSERT TRIGGER, so that the constraint is not violated. User-defined functions (UDFS) In DB2 Version 9.1 for z/OS, a UDF can have a single RETURN statement, which causes a challenge when an Oracle UDF needs to be ported to DB2. The options available are: • Modify the UDF so that it has a single statement, as shown in Table 8. Table 8. Modify UDF Oracle function

DB2 z/OS 9.1 function

CREATE OR REPLACE FUNCTION FN_TEST( ID IN INTEGER) RETURN INTEGER AS RET_VAL INTEGER; BEGIN IF ID = 1 RET_VAL := 1 ELSE RET_VAL := 2 END IF; RETURN RET_VAL; END FN_TEST; /

CREATE FUNCTION FN_TEST (ID IN INTEGER) RETURNS INTEGER LANGUAGE SQL RETURN (CASE WHEN (ID = 1) THEN 1 ELSE 2 END)!

• Convert the UDF to a stored procedure. A point to note here is that if this approach is followed, the calls to the original UDF will have to be modified so that they now execute the stored procedure, and supply an extra OUT parameter. For example, if you have the following UDF definition in Oracle 10g: CREATE OR REPLACE FUNCTION FN_TEST( ID IN INTEGER) RETURN INTEGER, then in DB2 Version 9.1 for z/OS, if the previous UDF is converted to a stored procedure, the definition gets modified as: DROP PROCEDURE FN_TEST; CREATE PROCEDURE FN_TEST( IN ID INTEGER, OUT RETURN_VAR INTEGER). The calls to the UDF will have to be modified accordingly. • Create the UDF as an external UDF in languages like JAVA or C++. Which option to choose from the previous three, depends on the requirement. If the UDF is performance-critical, then creating it as an external UDF in DB2 would make it slow. The first option that you should try is to create it as an SQL UDF in DB2 by modifying the code. The second option is to convert the UDF to a stored procedure. Creating an external UDF should be used as a last resort.



developerWorks®


Synonyms for stored procedures and functions Unlike Oracle 10g, in DB2 Version 9.1 for z/OS it is not possible to create synonyms of stored procedures or functions. Take an example of an Oracle scenario. A stored procedure SP_TEST is created in schema MAIN, and its synonym SP_TEST is created in schema TARGET. Since synonyms cannot be created for procedures and functions in DB2 Version 9.1 for z/OS, in order to replicate the Oracle 10g behavior, a copy of SP_TEST needs to be created in schema TARGET. While creating the copy, there are two options. You can take the code of SP_TEST and create it in schema TARGET. All references to objects of schema MAIN in the code will need to be prefixed with schema name MAIN. See Table 9 for an example. Table 9. Create SP_TEST in schema TARGET Main schema

Target schema

CREATE PROCEDURE SP_TEST(ID INTEGER) LANGUAGE SQL BEGIN DECLARE EMPID INTEGER; SET EMPID = 2; INSERT INTO TEST (EMPID) VALUES(EMPID); END!

CREATE PROCEDURE SP_TEST(ID INTEGER) LANGUAGE SQL BEGIN DECLARE EMPID INTEGER; SET EMPID = 2; INSERT INTO MAIN.TEST (EMPID) VALUES(EMPID); END!

You can create SP_TEST in schema TARGET with a single line CALL statement to SP_TEST of schema MAIN. See Table 10 for an example. Table 10. Create SP_TEST in schema TARGET with CALL statement Main schema

Target schema

CREATE PROCEDURE SP_TEST(ID INTEGER) CREATE PROCEDURE SP_TEST(ID INTEGER) LANGUAGE SQL BEGIN DECLARE EMPID LANGUAGE SQL BEGIN CALL INTEGER; SET EMPID = 2; INSERT INTO TEST MAIN.SP_TEST(ID); END! (EMPID) VALUES(EMPID); END!

Oracle collections DB2 z/OS 9.1 does not support collections like Oracle 10g does. Instead, a DB2 Global Temporary Table (GTT) can be used to implement the concept of Oracle collections. Oracle packages Packages can be used in Oracle 10g to group a set of procedures or functions. DB2 z/OS 9.1 does not support this concept of packages. While porting an Oracle package to DB2, all package objects need to be created as standalone objects. Global variables of the package will have to be handled using GTTs.

Transaction control specific issues Oracle to DB2 Version 9.1 for z/OS migration demystified! © Copyright IBM Corporation 2011



developerWorks®

Transaction Control (TCL) statements help in grouping statements into logical transactions so that they can be committed or rolled back. This section deals with conversion issues for TCL statements like COMMIT and ROLLBACK. COMMIT In Oracle 10g, COMMIT does not close the cursors, but in DB2 z/OS 9.1, COMMIT closes all open cursors. In order to keep the cursor open after commit, they should be declared as WITH HOLD cursors in DB2. ROLLBACK In Oracle 10g, ROLLBACK does not close the cursors, but in DB2 z/OS 9.1, ROLLBACK closes all open cursors. One approach is to use SAVEPOINTS, and use a ROLLBACK to the SAVEPOINT and keep the OPEN CURSOR statement before the SAVEPOINT in order to keep the cursor open on the ROLLBACK. Another approach is to explicitly open the cursor again after ROLLBACK and skip the cursor pointer till the record read at the time of ROLLBACK. Note that using a ROLLBACK within a cursor is not a good programming practice and should be avoided. Isolation levels Table 11 shows the mapping between isolation levels and their value in Oracle 10g and DB z/OS 9.1. Table 11. Isolation level mapping Oracle 10g

DB2 z/OS 9.1

Value

Read uncommitted

Dirty read/uncommitted read

1

Read committed

Cursor stability

2

Repeatable read

Read stability

4

Serializable

Repeatable read

8

Other issues This section deals with some miscellaneous conversion issues. Enable or disable triggers and constraints While in Oracle 10g, triggers and constraints can be enabled and disabled, it is not possible in DB2 z/OS 9.1. To achieve the same functionality in DB2, the trigger needs to be dropped at the point where a DISABLE is issued in Oracle, and CREATED at the point where ENABLE is issued in Oracle. Oracle to DB2 Version 9.1 for z/OS migration demystified! © Copyright IBM Corporation 2011


developerWorks®


@ Syntax in Oracle You can use @ syntax in Oracle 10g to invoke other SQL files from a main SQL file. In DB2 z/OS 9.1, one SQL file cannot be invoked from another SQL file. In order to replicate this functionality, the main SQL file needs to be converted into a shell script. The shell script will then have commands to invoke SQL files from it, as shown in Table 12. Table 12. Shell script Oracle SQL file - main.sql

DB2 shell file - main.sh

@"./Table/CreateTable.sql" @"./Sequence/CreateSequence.sql"

db2 connect to DBDEV user master using test db2 -td! -vf"./Table/CreateTable.sql" db2 -td! -vf"./ Sequence/CreateSequence.sql "

The first statement in the shell file would be a database connection statement. After that, individual SQL files can be invoked using db2–td syntax of DB2.

Conclusion This article describes specific issues that were faced during an Oracle 10g to DB2 z/OS 9.1 migration, and workarounds are shown to help you circumvent these issues. The best workaround for you would vary on a case to case basis. References have been given for a detailed description of specific DB2 features mentioned in the paper.




developerWorks®

Resources Learn • Learn about the IBM Migration Toolkit to refine and customize a migration. • Learn about DB2 Version 9.1 for z/OS at the IBM information center. • Learn about DB2 10 for z/OS at the IBM information center. • Learn about ANSI. • Learn about Disable triggers in DB2 Universal Database. • Learn more about Information Management at the developerWorks Information Management zone. Find technical documentation, how-to articles, education, downloads, product information, and more. • Stay current with developerWorks technical events and webcasts. • Follow developerWorks on Twitter. Get products and technologies • Build your next development project with IBM trial software, available for download directly from developerWorks. Discuss • Check out the developerWorks blogs and get involved in the developerWorks community.

About the authors Gunjan Verma Gunjan is a Technology Lead with eight years of experience advising financial services companies in defining and driving their database strategy. Most recently, she has led the adoption of DB2 for a leading banking product. She can be reached at [email protected] or [email protected].

Neeraj Kakar



developerWorks®


Neeraj Kakar is a Project Manager with Infosys Technologies with expertise in Database Migration Projects. He is an also an active blogger and on the Editorial Panel of ‘Security’ Defense Journal. He can be reached at [email protected] or [email protected].



Oracle to DB2 Version 9.1 for z/OS migration demystified!

Oracle to DB2 Version 9.1 for z/OS migration demystified!

Suggest Documents

DB2 UDB for Oracle DBA's - Shinguz.ch

Java Platform Migration Guide Version 1.3 to 5.0 - Oracle

Revenue Performance Management Demystified for UK ... - Oracle

Truth Demystified: Extended Version

PHP for zOS - Confex

Oracle to Postgres Migration - PGCon

Application Migration Tool for WebSphere Version Migration

Helsana Group Replaces DB2 with Oracle Database

Siebel Database Upgrade Guide for DB2 for z/OS - Oracle ...

Oracle to DB2 Conversion Guide: Compatibility Made Easy

Tech Note: Oracle BAM – Migration Procedures Supported Version ...

GoldenGate for DB2 to Teradata

DB2 LUW for the Oracle DBA - GSE Belux

Oracle Waveset to Oracle Identity Manager Migration Guidelines ...

Porting to DB2 Universal Database Version 8.1 from Sybase

ORACLE SQL DEVELOPER MIGRATION

Oracle - MySQL Migration - Percona

ORACLE SQL DEVELOPER MIGRATION

Using Transparent Gateway for IBM DB2 and DRDA (Best ... - Oracle

Oracle to MySQL Migration - Documentation - Ispirer

Applications Unlimited Migration to Oracle Cloud

DB2 Optimization Techniques for SAP Database Migration and ...

Oracle GoldenGate for DB2 z/OS Installation and Setup Guide

Oracle Systems Migration Services for IBM Environments