1

DB2 Migration – Tips, Tricks, and Pitfalls
1.1 Overview
The following sections include tips and tricks for migrating fr...
ETL Phase and Methodology
o Processed on the mainframe/what flavor of
Tool/combination?
o Are SQL Processes used in ETL?
o...
Database Security – Design and Build of the security views. Possibly implementation of
LDAP
ETL – Migration of the ETL tha...
1.4 DB2 Database Migration Considerations
1.4.1 Physical Data Base Conversion
1.4.1.1 Table Conversion
The first thing to ...
@Fld = split( /s+/, $_, 100);
if (($Fld[1] eq "PRIMARY" ) && ($Fld[2] eq "INDEX" ))
{ print FOUT "$Fld[1] $Fld[2] Fld[4]n"...
this command and loop through getting DDL for each table and placing it in a text file where
it can be modified. Of course...
1.5 Historic Data Migration
1.5.1 Historic Data Migration Approaches
There are three basic approaches to migrating history...
For Both
Date - format „YYYY-mm-dd‟
Time w/timezone – format HH:MI:SS.S(F)Z
Timestamp w/timezone – format YYYY-MM-DDBHH:MI...
print FOUT ");nend loading;nlogoff;nnnnn";
}
}
close FILE; close FOUT;

Below is a figure that shows the text file input o...
Synchronization fits into the general project timeline right before you are ready to begin the
production version of the i...
executed using a tool such as an excel spreadsheet. The maintenance macros can be executed
either manually or within a scr...
that DB2 Archives are stored in a proprietary format so they cannot be directly restored to
Teradata.
There are three gene...
1.6.1.2 VARCHAR
VARCHARs are used heavily in DB2, especially in DB2 EEE. This is probably a result of
DB2 not having colum...
SQL that is generated by these tools shouldn‟t require conversion as it should be generating
ANSI compliant SQL. Note that...
1.6.6 Custom Applications
Custom Applications are by far the most difficult to migrate to Teradata. In the DB2 world
you w...
Upcoming SlideShare
Loading in...5
×

Db2 migration -_tips,_tricks,_and_pitfalls

1,792

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,792
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
92
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Db2 migration -_tips,_tricks,_and_pitfalls

  1. 1. 1 DB2 Migration – Tips, Tricks, and Pitfalls 1.1 Overview The following sections include tips and tricks for migrating from DB2 environments to Teradata. The concepts put forth here were derived (and in some cases updated) from two web casts that are available on Teradata University. They are: Migrating Your DB2 Database to Your Teradata Database Webcast (about 74 minutes long) Migrating your DB2 Applications to your Teradata Data Warehouse Webcast (about 61 minutes long) If you wish to view these web casts in their entirety, log on to Teradata University and search for “DB2”. These courses will appear in the search results. You can then choose to enroll and take the courses. 1.2 Key Information The following is a list of information that is important to gather in advance of planning your DB2 to Teradata Migration. Production Job Schedule – It is important to understand what each production job you need to convert is. You should understand the types of jobs (autoloader, optiload, cube build, etc), from what platform they run, and what tools are employed if any. Concurrency/Dependency of Load Jobs (How many at once and to what tables in what tablespaces). Load / Batch Windows, SLAs, and procedures if SLAs are missed. What Scheduler and Version Control software is being used and on what platform? What kind of connectivity is available for Teradata to the Source (e.g. Channel Connect – ESCON, etc.) Is there any use of native CLI? Reverse engineered Erwin Models from all warehouses Are there any application / Non-DBMS (or coexisting processes on same node) node analysis, End User Access What processes are being performed on these nodes, ETL, reporting? Representative sample of applications and queries from user community. What user tools / applications are running against which systems? What access methods (ODBC, JDBC, SQLJ, SPUFI, QMF, QMF Windows, mainframe, etc…) are used? What is the level of ad-hoc usage vs. canned queries, What are these queries/reports written in? (COBOL, Java, Power Builder, Visual Basic, Cognos, etc.) Is there and Data Replication (DPROP/DPROPR) Which tables, when, what sort of process?
  2. 2. ETL Phase and Methodology o Processed on the mainframe/what flavor of Tool/combination? o Are SQL Processes used in ETL? o Is there INSERT, UPDATE, DELETE, UPSERT logic? o Are Temp Tables? o Does old data roll off, when or how often, how much? Unix/Windows/ETL What is the Refresh Methodology currently o Monthly? o Daily? o Continual? o Triggers, MQSeries? o RI?  Across all of history or just insert new data? Relative Table sizing in rows and gigabytes Partition key analysis for DB2 – What tables belong to what tablespaces which existing on which node groups? 1.3 Migration Overview A DB2 Migration consists of three distinct functions: Establishing the Teradata Data Warehouse Infrastructure Migrating the existing DB2 Environment to the new Teradata Environment Establishing a production environment 1.3.1 Establishing the Teradata Data Warehouse Infrastructure This phase establishes the hardware and software environment that will support the new warehouse environment. This includes Teradata and non-Teradata environments for development, test, QA, and production. Major activities include: Prepare data center Establish Teradata environment Establish BAR environment Establish network connectivity Establish ETL server(s) and cloning of old environment Establish BI server(s) and cloning of old environment 1.3.2 Migrating the existing DB2 Environment to the new Teradata Environment This involves migrating all the data, processes and applications associated with the DB2 Environment to Teradata. Major areas of focus include: Physical Database – Design and Build of the physical database with modifications made to take into consideration the differences between DB2 and Teradata
  3. 3. Database Security – Design and Build of the security views. Possibly implementation of LDAP ETL – Migration of the ETL that will maintain the data. Additionally, all supporting process and scheduling will migrate Post Load Processes – Migration of processes that are performed after the load is complete. For example: post load reports Historical Data Migration – The migration and validation of the historical data that is in the current DB2 system Reinstatement of Archive data – It is normal process to archive data to tape. This activity sets up the process to allow retrieval of the DB2 archive data on to the new EDW. User Table Migration – Migrate the tables and possibly the data created by users BI Migration – Migrate the BI applications to Teradata Regression / Benchmark Test Suite – Establish a set of scripts that will be utilized to determine the impact of upgrades or changes in the new environment Continuity of Business (COB) – Design and build the COB solution for the new warehouse Backup, Archive and Recovery (BAR) – Design and build the BAR solution for the new warehouse Testing – Define the test and execute the different levels of testing: o Unit Test o Integration Test o System Test o User Validation Test o User Parallel Testing Production Install – Establishing the new EDW into the production environment Decommission – Decommission the existing DB2 system and infrastructure 1.3.3 Establishing a production environment This involves establishing the processes and procedures that will be used to maintain the new Teradata environment and assisting the end users in the migration. Major areas of focus include: Establish operational processes and procedures User Change Management – Defines and Builds the infrastructure that will be used to communicate to the end user of the EDW. This activity may also include establishing a help desk
  4. 4. 1.4 DB2 Database Migration Considerations 1.4.1 Physical Data Base Conversion 1.4.1.1 Table Conversion The first thing to do when converting the physical database is to collect an inventory of DB2 DDL and Indexes. There are three basic methods of converting DB2 DDL to Teradata DDL. 1.4.1.2 Using a Script to Convert DB2 DDL This is the best approach if there are a large number of tables to convert. There is a set of Perl scripts that have been developed as part of the DB2 to Teradata Migration tool set that are discussed later is this offer guide. These scripts will read the DB2 catalog and create DDL. Please refer to that section for more detail on this option. Note that in some cases these scripts may need to be modified slightly to work for your particular client. If this is the case, and if you do not have anyone on your team who is comfortable modifying Perl scripts you may want to choose one of the other options listed below for migrating tables. 1.4.1.3 Table Conversion Using Erwin To use this method the steps are as follows: Reverse Engineer the DB2 database(s) into an Erwin Model. Then in Erwin: Make the target database Teradata. This will change the data types for you Go to the Tasks menu and forward engineer to generate the schema. Do a Preview or Report, outline all, and Ctl-C (copy) to copy the text Open up a text editor, Paste Remove objects that are not to be ported Removechange primary index names If there are many tables, consider doing the above using scripting language Do object renames as necessary Insert a logon statement before CREATE TABLE statement Using the text file and Bteq, create the objects When using this method you may want to use a scripting language for certain modification tasks, especially when dealing with a large number of tables. Below is an example of a Perl script that removes index names (assuming that is what you wanted to do) from the DDL. #!/usr/bin/perl $FINPUT = "./before.txt" ; $FOUTPUT = "./after.txt" ; $FINPUT = $ARGV[0] if ($ARGV[0]) ; $FOUTPUT = $ARGV[1] if ($ARGV[1]) ; open(FILE, $FINPUT) || do { warn "Can't open $FINPUT: $!n"; return; }; open(FOUT, ">$FOUTPUT") || do { warn "Can't create $FOUT: $!n"; return; }; while (<FILE>) { a
  5. 5. @Fld = split( /s+/, $_, 100); if (($Fld[1] eq "PRIMARY" ) && ($Fld[2] eq "INDEX" )) { print FOUT "$Fld[1] $Fld[2] Fld[4]n"; } elsif (($Fld[1] eq "UNIQUE" ) && ($Fld[2] eq "PRIMARY" )) {print FOUT "$Fld[1] $Fld[2] $Fld[3] $Fld[5]n";} elsif (($Fld[0] eq "CREATE" ) && ($Fld[1] eq "INDEX" )) {print FOUT "$Fld[0] $Fld[1] $Fld[3]n";} elsif (($Fld[0] eq "CREATE" ) && ($Fld[1] eq "UNIQUE" )) {print FOUT "$Fld[0] $Fld[1] $Fld[2] $Fld[4]n";} elsif ($Fld[1] eq "INDEX" ) {print FOUT "$Fld[1] $Fld[3]n";} else {print FOUT $_; } } close FILE; close FOUT; Here is the before and after picture of the DDL that was modified by this scripts Before CREATE TABLE accts ( CUST_ID FORMAT '-(10)9', After CREATE TABLE accts ( INTEGER NOT NULL CUST_ID FORMAT '-(10)9', INTEGER NOT NULL ACCT_TYPE CHAR(2) NOT NULL, ACCT_TYPE CHAR(2) NOT NULL, ACCT_NBR CHAR(16) NOT NULL, ACCT_NBR CHAR(16) NOT NULL, ACCT_START_DATE FORMAT 'YYYYMMDD', ACCT_END_DATE 'YYYYMMDD' DATE NOT NULL ACCT_START_DATE FORMAT 'YYYYMMDD', DATE FORMAT ) ACCT_END_DATE 'YYYYMMDD' DATE FORMAT ) PRIMARY INDEX XIE1accts ( PRIMARY INDEX ( CUST_ID, CUST_ID, ACCT_TYPE ACCT_TYPE ) ; DATE NOT NULL ) ; 1.4.1.4 DB2LOOK Command The third method that can be employed is using the DB2LOOK command. This command is similar to the SHOWTABLE command in Teradata. IBM uses this command in order to move objects from a production database to a test database but it can be used to extract DDL as well. One caveat is that it is not always installed in all environments so you should check with the DB2 administrator to determine if it has been on your system. If not it is a relatively simple process to get it installed (similar to running a dip script). Once available you can run
  6. 6. this command and loop through getting DDL for each table and placing it in a text file where it can be modified. Of course you can either do this manually or you can use the scripting language of your choice to make the modifications, as mentioned above. 1.4.1.5 Index Conversion For the indexes, you should focus on the primary index selection first. Secondary indexes in DB2 are not necessarily comparable to Teradata Secondary Indexes so it is usually best to select a primary index and the select secondary indexes based solely on Teradata criteria. 1.4.1.6 View Conversion Erwin can be used to reverse engineer the views out of db2 as long as they are fairly simple and straight forward. It does not, however, excel at converting more complex views. It does not do well with the following: Converting views that contain multiple joins Converting all of the DB2 functions to proper Teradata functions Converting view that contain derived tables For these more complex views it would be best to build a conversion tool of your own using your favorite scripting language or to do them manually. Even when using a scripting language you may need to make some manual adjustments to some views in order to get them to perform adequately. 1.4.1.7 UDFs and UDTs These are being encountered more and more in conversions. They will require special attention because while Teradata supports UDFs the languages and features are different. Converting may not always be the answer. Each of these should be taken on a case by case basis. Consider the following alternatives. Port UDFs to Macros or Stored Procedures Port UDTs to data containers in Stored Procedures Consider if UDF/UDT logic can be replaced by a Teradata function thereby eliminating the need for it. 1.4.1.8 Stored Procedures Stored procedures have been out on IBM for a few years now. On IBM platforms they can be written in Java, C, or any other platform supported language, as well as in SPL (Stored Procedure Language). Terdata internal stored procedures must be written in ANSI Standard SPL. External Stored Procedures may be written in C. This is one of those conversion categories that you must grind out manually. One tip is to look for alternative ways of accomplishing the same task. For example many Stored Procedures make use of sequential looping. There may be a way to accomplish the same thing in a different way using a parallel process in Teradata.
  7. 7. 1.5 Historic Data Migration 1.5.1 Historic Data Migration Approaches There are three basic approaches to migrating history. They are outlined below. 1.5.1.1 Unload DB2 / Load Teradata via Script There are a set of Perl scripts that are a part of the DB2 to Teradata Migration toolkit that will read the DB2 catalog and produce DB2 Unloads and corresponding FASTLOAD or MULTILOAD scripts. These scripts run on UNIX and at this time will operate only against DB2 EEE or other UNIX flavor of DB2. There is also a tool that generates MULTILOAD scripts for the OS390 version of DB2. For more information on this option, refer to the section on tools with in this guide. 1.5.1.2 Use an Existing ETL Tool. If there is an ETL tool such as Informatica, Ab Initio, etc. available, this may provide a viable method for moving history from DB2 to Teradata. 1.5.1.3 Manual Unload / Load This is the least desirable option as it is the most labor intensive. It may, however be necessary because the options above are not suitable or because the data must be physically moved from one site to another. If this is the method that is chosen, the first step is to create the exports. There are a number of methods to do this. You should use the one that is most familiar to you and keep the following in mind: Sorting by any column is not desirable Export numeric data types as displayable, sign preceding Export dates as “YYYYMMDD” Try to export fixed length rows, adding blanks to fill out char strings (OS390) If VARCHAR exports are necessary, you need a 2 byte binary length preceding the VARCHAR All data must be in the host format of the EXPORT requestor, if OS390 then EBCDIC (except for 2 byte lengths, which must be gig endian, little endian) When creating ASCII flat files from a DB2 EEE environment the records can be fixed or delimited either can be handled by Teradata. Here are some guidelines. If Delimited Choose a delimiter – Standard Pip “|” or other Do not use a cancellation delimiter as they are different in DB2 than in Teradata. A delimiter followed by a delimiter (e.g. ||) indicates a null value There should be no delimiter at the end of a line If Fixed Determine the null indicator that you will use
  8. 8. For Both Date - format „YYYY-mm-dd‟ Time w/timezone – format HH:MI:SS.S(F)Z Timestamp w/timezone – format YYYY-MM-DDBHH:MI:SS.S(F)Z Once you have created the extracts you must create FASTLOAD scripts. The following Perl script will take text version of the DDL from Erwin and create a Fastload script. #!/usr/bin/perl $FINPUT = "./before.txt" ; $FOUTPUT = "./after.txt" ; $FINPUT = $ARGV[0] if ($ARGV[0]) ; $FOUTPUT = $ARGV[1] if ($ARGV[1]) ; open(FILE, $FINPUT) || do { warn "Can't open $FINPUT: $!n"; return; }; open(FOUT, ">$FOUTPUT") || do { warn "Can't create $FOUT: $!n"; return; }; while (<FILE>) { @Fld = split( /s+/, $_, 100); if (($Fld[0] eq "CREATE" ) && ($Fld[1] eq "TABLE" )) { print FOUT "sessions 2;nerrlimit 25;nlogontdpid/username,password;n"; print FOUT "set record unformatted;ndefinen"; $TNAME = $Fld[2]; @NAMES = (); $I=0; while (<FILE>) { @Fld = split( /s+/, $_, 100); if ($Fld[0] eq ")") {last;} $NAMES[$I] = $Fld[1]; if ($I++ > 0) {print FOUT ",";} if ($Fld[2] eq "INTEGER") {print FOUT "$Fld[1] ($Fld[2])n";} elsif ($Fld[2] eq "SMALLINT") {print FOUT "$Fld[1] ($Fld[2])n";} elsif ($Fld[2] eq "BYTEINT") {print FOUT "$Fld[1] ($Fld[2])n";} elsif ($Fld[2] eq "DATE") {print FOUT "$Fld[1] ($Fld[2] FORMAT 'YYYYMMDD')n";} elsif (substr($Fld[2],0,4) eq "CHAR") {print FOUT "$Fld[1] ($Fld[2])n";} # and then other datatypes } print FOUT "file=insert.input;n"; print FOUT "begin loading $TNAME errorfiles $TNAME.err1, $TNAME.err2;n"; print FOUT "INSERT INTO $TNAME (n"; for ($j=0; $j<$I; $j++) { .................................................................................................. if ($j > 0) {print FOUT ",";} print FOUT ":$NAMES[$j]n"; }
  9. 9. print FOUT ");nend loading;nlogoff;nnnnn"; } } close FILE; close FOUT; Below is a figure that shows the text file input of the create table statement on the left and the resulting FASTLOAD script on the right. Input CREATE TABLE accts ( Output sessions 2; CUST_ID INTEGER NOT NULL FORMAT '(10)9', errlimit 25; ACCT_TYPE CHAR(2) NOT NULL, set record unformatted; ACCT_NBR CHAR(16) NOT NULL, ACCT_STRT_DATE DATE NOT NULL FORMAT 'YYYYMMDD', ACCT_END_DATE DATE FORMAT 'YYYYMMDD' ) define CUST_ID (INTEGER) ,ACCT_TYPE (CHAR(2)) ,ACCT_NBR (CHAR(16)) ,ACCT_STRT_DATE (DATE FORMAT 'YYYYMMDD') ,ACCT_END_DATE (DATE FORMAT 'YYYYMMDD') PRIMARY INDEX XIE1accts ( CUST_ID, ACCT_TYPE ) ; logontdpid/username,password; file=insert.input; begin loading accts errorfiles accts.err1, accts.err2; INSERT INTO accts ( :CUST_ID ,:ACCT_TYPE ,:ACCT_NBR ,:ACCT_START_DATE ,:ACCT_END_DATE ); end loading; logoff; 1.5.2 Historic Data Migration Synchronization There are two kinds of synchronization that you will encounter. Batch load synchronization This type of synchronization assumes that the load process adds rows to a table on each cycle and that the rows of data are stamped with a date or id, the migration will move the tables from a point in time. Synchronization of updated tables These are tables that are not loaded by adding rows, but rather by updating current rows or by doing a full refresh. With this type of table, the synchronization can approached in two different ways. The best approach is to move the tables at the very end of the migration process, after the last run on the legacy system and before the first run of the new system. In cases where this is not possible it might be necessary to build a custom solution to achieve synchronization. A custom solution might be to move the tables over and then on the legacy system perform a delta process to send a synchronization file.
  10. 10. Synchronization fits into the general project timeline right before you are ready to begin the production version of the incremental loads. Basically your synchronization strategy is attempting to take any kind of gap there may be between the DB2 system and the Teradata system and fill it. For example you may have loaded all historical data as of the end of last month (for all tables). Three weeks have passed and you need to load the three weeks of data that have been added/updated in the DB2 System to the Teradata system. The basic steps for synchronization are as follows: 1.5.2.1 Step 1 Record the period id(s) for each table that you are loading. This is anything that can identify a block of data that you are loading (e.g. timestamp, batch id, etc.) 1.5.2.2 Step 2 Migrate the data. This is the initial history migration. You may choose to do this in batches of periods (e.g. 1 month of data at a time), to make each load smaller and more manageable. 1.5.2.3 Step 3 From recorded period(s) on, load additional periods into temporary tables. It may be important to do this on a regular basis if the time from the initial history load to the time of production turnover is protracted for some reason. 1.5.2.4 Step 4 Validate the data migrated to the temporary tables. 1.5.2.5 Step 5 Insert data from temporary tables into base production tables and delete temporaries. This should be completed right before cutover to production. It should be noted that for tables that require updates or delta loads you will have to develop your own custom solution to ensure that updates are applied properly in the synchronization process. For tables that are totally refreshed each time they are loaded, you should plan to just do those at the end of the migration process using a flat file as input. 1.5.3 Process Control and Tracking For large migrations with hundreds or thousands of tables keeping track of which ones have been loaded and with which periods is a complex task. As part of the DB2 To Teradata Migration Tools package a tracking database and a set of macros for both updating the database and reporting on the progress have been developed. The reporting macros can be
  11. 11. executed using a tool such as an excel spreadsheet. The maintenance macros can be executed either manually or within a script depending on process that you are using for loading and verifying data. This automated approach to tracking is detailed later in the section of this document that is dedicated to conversion tools. 1.5.4 Testing Testing will differ from site to site based on requirements however here are a few guidelines for testing a history migration that can be considered as components of your overall test plan. A field by field compare of all of the history may be cumbersome but could be performed on random samples of rows from each table to ensure that the data appears to have loaded successfully Perform a check of the catalog to ensure that all physical structures have been created Accessibility check – ensure that the roles, profiles, permissions, rights, etc allow for the appropriate update/access of the data. A field by field compare of incremental loads may be appropriate depending on the size of the loads. Again if they are large you could reduce the compare to a sample of the rows. 1.5.5 User Tables User tables typically fall outside of normal maintenance activities. In most cases you will have to do some digging to find out when they are loaded, who loads, them how they get loaded, etc. These tables are typically small in size but can be great in number so you will need an approach for migrating them. There are two basic ways to deal with them. Use the self service approach. In other words give the users some sort of GUI tool (preferably freeware or trial version software of some kind that allows them to migrate their tables on their own schedule (of course with an appropriate mandatory cut over date).An advantage of this option is that users may decide that they don‟t need certain tables thereby reducing the total number of tables migrated. Note that this option is probably only good for smaller tables Move all the tables using one of the methods described earlier for migrating tables. Note that this will require some level of coordination with the general user population as to when it will be performed and that after that given date that changes made on the DB2 system will not be moved forward. This most likely will have to be a general rather than a specific communication as it in most cases will be difficult to discover who owns which tables. 1.5.6 Archived Data Migration One area that is often overlooked in migrations and in scoping migrations is the effort required to migrate archived data from the DB2 environment. Archived data is typically required for accounting, regulatory, legal, etc. reasons. These reasons mandate that the data may need to be restored at some point. You will need to understand the both the extent of the archives that need to be migrated as well as the intended service level that is expected for a restore in order to make a decision as to how to handle this type of data. It should be noted
  12. 12. that DB2 Archives are stored in a proprietary format so they cannot be directly restored to Teradata. There are three general options from which to choose when dealing with archived data. They are as follows: Restore  Extract  Load Archive on Teradata  Clean up The steps for this option are to restore the archives on DB2, Extract the data From DB2, load the data to Teradata, archive the data on Teradata, and, finally delete the data from Teradata. This is the most involved in terms of effort to get the data moved to Teradata and then archive the data in that format. This approach will allow for the quickest turnaround time for a restore process. Restore  Extract The steps for this option are to restore the archives on DB2, then unload them and the associated DDL to text files. When a restore is needed the files would need to be loaded table by table (most likely using FASTLOAD) The number of tables needed to restore will directly affect the amount of time needed. Do nothing now If for some reason there will continue to be a DB2 system on site (e.g. for applications that are not being migrated), you may chose to not migrate the history. The restore system could simply be the remaining DB2 system. This of course would have to be acceptable to the client and you would have to carefully explore the steps required to restore and retrieve the data. At a minimum these would need to be documented as part of your engagement. This would also have to meet any SLAs for restore that the customer had in place. 1.6 DB2 Application Migration Considerations 1.6.1 Data Type Considerations 1.6.1.1 Decimal 19 and Above Prior to Teradata 12, Decimal 19 and above is not supported by Teradata but is by DB2. If dealing with a Teradata system that has not been upgraded to Teradata 12, the following may apply. When considering conversion options one should determine the purpose for which the field is used. In this example we will use currency. Decimal (19,4) will store a value that represents over 999 trillion dollars. In most scenarios, there should be no need to store a value greater than 99 Trillion dollars which can be accomplished in Teradata using a Decimal (18,4). You should determine the max value on each column within the DB2 system and see if it will fit into a Decimal 18 on Teradata. It would also be a good idea to check with subject matter experts at the client site to determine if there is a reason to believe that a value of greater than 100 million would ever need to be stored in one of these columns. If not than the preferred method would be to convert this columns to a smaller decimal field. If the evidence shows that values greater than 100 million may be required than you must use either a Float or Char (as required) data type to store the values.
  13. 13. 1.6.1.2 VARCHAR VARCHARs are used heavily in DB2, especially in DB2 EEE. This is probably a result of DB2 not having column level compression until release 8. In Teradata, there is a 2 byte overhead that is used for VARCHARs. Depending on the situation it may be more advantageous to use CHAR data types with Multi-Value Compression (which cannot be used on a VARCHAR in Teradata) as this may save more space than straight conversion from to VARCHARs. 1.6.1.3 SHORT FLOAT This is a data type that was used in DB2 because it was believed that it would save space. These should be converted to the FLOAT data type within Teradata 1.6.1.4 BOOLEAN This data type is not that common but could be used by procedural logic in downstream processing. When converting this data type, use the BYTEINT data type in Teradata. 1.6.1.5 The Dumb Tilde (character delimiter) DB2 exports and imports will use this in their processing. The default is a quote character. In most cases you will need to strip those out when you find them. There are a few methods that are can be used. Use the SED command from Unix Use the Substring functionality in SQL Use an ETL Tool to strip them out 1.6.1.6 BIGINT For Releases of Teradata that do not support 64 bit integer data types (those prior to TD12), use the DECIMAL data type to convert DB2 BIGINT data types. In some cases you may find that 3rd party tools have not yet incorporated support for Teradata‟s 64 bit integer data type. In that case you would also use a Decimal field in its place. 1.6.2 Industry Standard Interfaces / Protocols ODBC, OLEDB, ADO, RDO, and JDBC are all supported by Teradata. You may run into something called SQLJ (which is for Java pre-processing), this is not supported by Teradata unless the C++ pre-processor can be used. It is interesting to note that the Native DB2 CLI can be mapped for the most part directly to ODBC 1 for 1 as the two are very similar. This makes ODBC a good choice when converting DB2 CLI rather than converting to native Teradata CLI 1.6.3 GUI Tools GUI tools can be broken down into few different categories. The first category is tools that are procedural in nature. This category includes tools like PowerBuilder, MS Access, Visual Basic, Visual C, Excel, etc. These tools typically use ODBC JDBC interfaces. When doing your initial assessment these should be considered as being moderately complex.
  14. 14. SQL that is generated by these tools shouldn‟t require conversion as it should be generating ANSI compliant SQL. Note that an SQL that part of one of these applications and is not directly generated by the tool may contain DB2 specific extensions and would require conversion in order work with Teradata. The second category of applications is SQL Submitters. An example of this type of tool in the Teradata world is SQL Assistant (Queryman). In the DB2 world you may run into QMF or some home grown query tool (e.g. John‟s Query Tool). If you want or need to run QMF against Teradata there is TSAPI which can be used to run QMF against Teradata as DB2 but because the SQL may contain DB2 specific, syntax you will probably end up converting the SQL anyway. Therefore it is probably best to convert all SQL from any DB2 SQL Submitter and migrate it to SQL Assistant. Then you should perform testing and parallel testing to assure the same results are being generated. The third category of GUI tools is GUI Application Writers. This category includes tools such as Cognos, Microstrategy, Hummingbird, Crystal Reports, etc. These tools build some kind of metadata layer or pseudo dictionary within the tool. They use these to understand the data types which were in DB2, how to access tables, and what join criteria to use. These tools typically have both ODBC support and CLI support for different database vendors. Because most implementations make use of the ODBC interface these are amount the easiest applications to convert. Typically you rebuild the metadata layer to point to Teradata structures and all of the queries should work. The proof is in the testing and environments with lots of standard query‟s / reports and lots of users will require diligent management of the testing process. 1.6.4 GUI Three/N Tier Architectures GUI Three/N Tier Architectures include tools like Cognos build cubes on a middle tier server and then records are accessed from these middle tier servers. These servers can be either small windows servers or mid range to large Unix servers. The migration of these cubes to Teradata is relatively easy except if they are using some sort of “pass through” functionality. With this type of functionality these tools send requests to the database to drill into the underlying data that was used to build the cube. This SQL may need to be converted for two reasons. The first is if it uses any DB2 specific extensions (as previously mentioned in this document). The second is to ensure that it is optimized for Teradata. In some, DB2 implementations the SQL may be optimized to take advantage of DB2 indexing. Because the indexing scheme will be different on Teradata, this SQL may need to be re-optimized for Teradata. 1.6.5 Web Enabled Applications Web enabled applications are those that allow for access to the application through a browser. The idea behind these applications was to relieve the desktop of the need to have client software resident on it. These applications require multiple tiers and web services to talk with the DBMS and usually use Java technology and JDBC. One thing to watch out for when migrating these applications is performance. In some cases large buffer pools may be used in conjunction with a succession of small result sets. This may not work well in a Teradata environment and may need to be re-engineered to make better use of the database engine. Other than that these types of applications make use of standard interfaces and are relatively easy to migrate. Again rigorous testing is the key to success.
  15. 15. 1.6.6 Custom Applications Custom Applications are by far the most difficult to migrate to Teradata. In the DB2 world you will find many applications that are written in Cobol, C, PL/1, etc. Converting these programs to work with Teradata may require and entire re-write. Often this is difficult because these applications were written long ago and the documentation is poor or does not exist. In some cases you will have to convert these applications which will involve re-writing (in total or in part) them and/or at least qualifying and recompiling them. Before re-writing 1000s of lines of code consider the following alternatives. Is the functionality required in the new warehouse environment or can the application be retired? Can the functionality be replicated using a standard piece of software or some standard functionality within a tool? For example you may encounter a complex scheduling application that can be replaced with an off the shelf solution. Can the program functionality be separated from the database access by creating a separate database interface (still requires changes to the program but may avoid a total rewrite which is helpful in poor documentation scenarios)? . 1.6.7 Downstream Data Feeds and Exports It is very common for databases to feed downstream, applications, data marts, ODSs, etc. These are performed in a couple of different ways. First they may be built in a Cobol, C, C++, etc. Interface. Second they may be exported from DB2 using a command line processor. Most of these should be converted to FAST EXPORT. And most will be relatively easy to convert. Some things to consider when converting command line exports are as follows: When using UNIX you will need a disk landing area or pipe as you cannot go directly to tape. You will need to pay attention to character, column, and file delimiters used in DB2. As of TTU 8.1 there is no delimiter function so if delimiters are required in the output you will have add them in yourself. This can be done with an OUTMOD if you so desire. You will need to understand whether the character set is ASCII or EBCIDIC

×