This presentation will give you an overview of each of the DB2 coreengine data movement utilities: Load, Import, Export (with db2look),db2move, ADMIN_COPY_SCHEMA, ADMIN_MOVE_TABLE,db2relocatedb, restore from backup and split mirror.These will be compared to each other so that you can get a goodidea of when to use and not to use each of these. To help round outthe discussion, a comparison to the Oracle database core enginedata movement utilities will be made to these DB2 utilities.

1

Here are the 5 presentation sections.1. Summarize the entire set of utilities to give a high level comparison of

why each is used.2. Explore the cross platform basic table movement utilities that get data

in and out of your database.3. Explore the two stored procedures that move table data around.4. Discuss the very useful tool that can move an entire database or parts

of a database.5. A quick look at the remaining utilities that can move an entire

database.

2

The following is a high level summary and comparison of all the coreengine utilities in this presentation.We refer to these as “core engine” utilities because they come with DB2.So, this would exclude other tooling like the High Performance Unload, theIBM Data Movement tool, the Migration Toolkit and so on.This also excludes third party tools.

3

Here are the first half of the core engine utilities in this presentation.Notice all of these are cross platform capable, mainly because theysupport the IXF file option. IXF files can be created on z/OS or i-seriesand then used on Windows or UNIX interchangeably, so they areextremely flexible and useful for any DB2 to DB2 data feeds or databasemigrations between platforms.

4

Here are the second half of the utilities in this presentation.Some folks may not refer to the stored procedures listed here as DB2“utilities” per se, but we will call them that for purposes of this materialbecause they move data and are part of the core engine capabilities.The final three utilities can move an entire database, but db2relocatedbcan do more than that as we will see later.

5

First, let’s look at Load, Import, Export (with db2look) and db2move. Note that all of these are cross platform utilities.

6

Many folks think of the Load utility as the “fast loader” vis-à-vis the Importutility and that is true, but you will see that it has more purpose than justthat.One of the main take home points here too is that the Oracle SQL*Loaderhas two main modes, Direct Path and Conventional Path. Direct Path isthe mode that compares best with the DB2 Load utility because it is theOracle “fast loader” utility.Many Oracle DBAs do not even use the Direct Path mode withSQL*Loader or do not know this mode exists. They might simply say theyuse the SQL*Loader (SQLLDR) utility. But the modes in this utility are keyto either how fast or how flexible it is, so we need to be clear on this ifdiscussing it with Oracle DBAs, especially in comparison to DB2 Load orImport.

7

The Conventional Path mode of Oracle SQL*Loader is the default if amode is not specified. It is by far the most widely used mode by mostOracle DBAs. Do not fall into the trap of comparing this mode with theDB2 Load utility; it compares better with the DB2 Import utility.Many Oracle DBAs learning DB2 will use the Conventional Path mode ofthe SQL*Loader utility with all of its flexibility and ease of use and thenwhen they start to learn DB2 reach for the Load utility first because of itsname. This however can cause unfair comparisons to occur.

8

For DB2 DBAs, the items on this slide are the main reasons why Load isused rather than Import.The Load utility requires a bit more knowledge of DB2 to use than theImport utility because it can place a table in pending modes and becauseit can require you to run SET INTEGRITY commands, and so on. Again, ifOracle DBAs are using the Conventional Path mode of the SQL*Loader,then point them to the Import utility, not the Load utility.The above is not an exhaustive list of the pros and cons of each, butrather represent the most commonly used reasons for choosing one vs.the other.

9

The items on this slide are reasons why many DB2 DBAs use the Importutility rather than Load.Again, the above is not an exhaustive list of the pros and cons of each,but rather represent the most commonly used reasons for choosing onevs. the other.

10

The DB2 Load or Import utility is run via a command or API. TheSQL*Loader is done that way also, but it has the extra step of usuallyspecifying a control file where the commands are kept separate from thecommand file that calls it. These examples compare the DB2 Loadcommand syntax with the Oracle SQL*Loader control file.One thing to note is that in DB2, you can take most Load commands andturn them into Import commands by just changing the “Load” to “Import” inthe command file. If the command file has not used features that areexceptions between the two utilities, the command will work.The same goes for Oracle SQL*Loader. You can call the command with aDIRECT=true or DIRECT=false to change modes, so unless you are usinga specific feature that one or the other mode does not support, the controlfile commands will work in either mode.

11

Here are the basic similarities between DB2 Load and Oracle SQL*Loaderin Direct Path mode.DB2 monitoring of the Load progress is a little more friendly and DB2 loadallows both a dump file as well as an exception table but otherwise, thebasic usage of the two database utilities are similar.

12

Here are differentiators between DB2 and Oracle. As you can see, theDB2 Load utility is much more flexible and powerful than OracleSQL*Loader in Direct Path mode.Again, don’t let Oracle DBAs compare SQL*Loader Conventional Pathmode capabilities to DB2 Load, these are apples and oranges.Conventional Path mode is not their “fast loader” utility, so for example ifyou were loading a data warehouse table of 1 million rows, you would notwant to use Conventional Path mode as it would be slow. But, as you cansee, using Direct Path mode has more restrictions than if you were doingthe same thing in DB2 with Load.

13

To get data out of a DB2 database with a native utility, use Export. To getDDL out, use db2look. You will see later however that in Oracle it is onlyone utility for doing both of these things.Oracle Export is proprietary in output format. In contrast, DB2 Export canbe to delimited or spreadsheet output formats that are non proprietary.Also DB2 Export can be done to an IXF file that is also non proprietary,but most database vendors do not use it, so it is mainly used by IBM withDB2.Oracle Import only works with Oracle Export files. DB2 Import howeversimply reads ASCII, delimited or spreadsheet files that any other tool canread. The IXF files it can read are also industry standard.You will see later that the Oracle Export of schema DDL is comparable tothe db2look utility. db2look is the DB2 reengineering utility that canrecreate anything in a DB2 database including database statistics, orstored procedure DDL, grants or even registry variables.

14

Export, Import and Load only process one file at a time. If you want to domass exports and imports and loads, you must use db2move.Again, you will see later that one utility does all of this in Oracle.Since Export / Import is a one table at a time set of utilities, the db2moveutility sits on top of those and gives you the ability to mass move manytables at a time. Usually this means the entire database or by schema,table space or owner.Note: db2move can also move other objects in a schema besides tables.

15

Oracle has two kinds of Export and Imports, the older or “original” utilitiesand the newer Data Pump versions of these utilities. Oracle hasdeprecated the original versions of these utilities in 10g, but support themfor the time being.We are covering the Oracle Data Pump version of Export here becauseData Pump can run the original Export or Import scripts in a compatiblemode anyway and it of course can run the newer Data Pump scripts aswellNote: the Data Pump Export does the same thing as three DB2 utilities:Export, db2look and db2move.

16

Next we will learn about the two stored procedures that move data aroundin DB2.ADMIN_COPY_SCHEMA copies objects and data between schemas inthe same database without using OS files.ADMIN_MOVE_TABLE moves tables, indexes and lobs to different tablespaces. It also can redefine tables to look different like for example makea normal table become and MDC. It can do this all without taking a DMLoutage and keep everything online.

17

This stored procedure is nice if you don’t want to use OS files to copy dataor objects from one schema to another within the same database whichmakes it faster and use less resources.Notice that you can change table spaces for table data if you want to whilecopying the tables. But, if you only want to move a table to a new tablespace, use the next stored procedure instead because it can do thisonline.

18

None of these Oracle options stack up to the DB2 stored procedureADMIN_COPY_SCHEMA stored procedure because they all require OSfile usage.Using the Export / Import method (either original or Data Pump) is themost common way Oracle DBAs do this task by the way.DBMS_METADATA package is useful for getting DDL only in a text fileformat.The RMAN method shown here is a long shot, but could work for datacopy if properly set up in your database. However, few DBA will use thismethod because it is difficult to guarantee keeping every table spacespecifically used by only one schema owner.

19

Using this relatively new SYSPROC.ADMIN_MOVE_TABLE storedprocedure, you can move tables by using an online or offline move. Usean online table move instead of an offline table move if you valueavailability more than cost, space, move performance, and transactionoverhead. Offline will do this action very fast however.This is a very powerful stored procedure that is used for two mainreasons:1) To move the data, indexes and LOBs to different table spaces2) To restructure the table so that it looks differentFor that second point, notice that you can made a regular table into anMDC table, or a range or database partitioned table.Also on that second point notice that you can redefine the columns of atable to perform an online table alter.This stored procedure can run online and keep all the data fully read/writeavailable during the move.Even though the initialization stage does a cursory check of this, it is agood idea for you to ensure there is sufficient disk space to accommodatethe copies of the table and indexes, the staging table, and the additionallog entries.

20

SYSPROC.ADMIN_MOVE_TABLE stored procedure uses a control tableby the same name. It resides in SYSTOOLS schema.When you call the ADMIN_MOVE_TABLE procedure, a shadow copy ofthe source table is created in the INIT phase. During the COPY phase,changes to the source table (updates, insertions, or deletions) arecaptured using triggers and placed in a staging table.After the COPY phase is completed, the changes captured in the stagingtable are replayed to the shadow copy in the REPLAY phase.Following that in the SWAP phase, the stored procedure briefly takes thesource table offline and assigns the source table name and index namesto the shadow copy and its indexes.The shadow table is then brought online, replacing the source table.By default, the source table is dropped, but you can use the KEEP optionto retain it under a different name.This stored procedure has many more options not discussed here and is avery rich DB2 tool that can be customized to a great degree.

21

There are two main methods when invokingSYSPROC.ADMIN_MOVE_TABLE. The first is the simplest way that letsthe procedure create the target table for you and performs the entire tablemove, all phases, in one execution of the script with little set up.For instance, if you had a table definition that is quite large (many KB),and all you want to do is modify the table spaces for the table, you can doso without having to determine the entire CREATE TABLE statementneeded to recreate the source table. All you need to do is to supply thedata table space, index table space, and LOB table space parameters.If the source table has a unique index, this will speed up the move andkeep locking to a minimum.You can specify NO_TARGET_LOCKSIZE_TABLE as an option to preventa LOCKSIZE TABLE on the target table during the COPY AND SWAPphases if you don’t have a unique index on the source table. This is notreally much of a problem or needs much consideration except for verylarge tables with high DML activity during the move.

22

SYSPROC.ADMIN_MOVE_TABLE also has a more robust and flexiblemethod that allows the user to use a pre-create target table in situationswhere using an automatically created one will not suffice.It further also allows you to control each stage of the move process withindividual calls to it, giving even more control, from the initialization stageto the copy, replay and swap stages.Tip: With this stored procedure, you can essentially perform an ALTERTABLE ALTER COLUMN command without requiring a reorg afterwardsand keeping the data in read/write mode the entire time.

23

Oracle basically does not have an “online” table move capability. So, ifyou want to move a table to a different table space, it will be taken offlineand you cannot perform DML against it until your move is finished. Itdoesn’t matter which of these techniques shown here you use; they allhave this outage.The ALTER TABLE … MOVE command is probably the easiest to use. Italso essentially performs a reorg of the moved table for you. But, itinvalidates the indexes which cannot be used after the move is done. Theindexes need to be manually handled with either a drop and recreate orrebuild using an ALTER INDEX… REBUILD command.The Data Pump Export / Import technique is used quite commonly too, butthis of course requires you to delete the table after the Export in order toImport it later and of course you have to rebuild the indexes again as wellas resolve dependency issues. And of course there is the outage youtake while performing these things.CREATE TABLE AS SELECT technique is essentially copying the table,not moving it and it would have to have a different name in order to workand then a manual drop and switch would have to be done along with alldependency issues resolved.All in all, none of these Oracle options are as elegant as the DB2 storedprocedure: ADMIN_MOVE_TABLE.

24

This utility can change the underlying metadata of a database in order tomake structural changes to the database you wouldn’t otherwise be ableto change. So, you can use it to make small or big changes to yourdatabase.

25

db2relocatedb utilizes the power and speed of the operating system filecopy as a way to clone a database physically which provides a very quickway to do this that is much faster than a logical backup and restore.Here we show how to completely move a database from one location toanother and then rename that database and also rename the instance thatit belongs to.So, basically, you can clone a database as fast as you can copy files andmove it anywhere as long as it is in the same operating system family.

26

Oracle can also clone a database with a file copy technique using thesteps shown here. Notice that there are a few more steps to run than inDB2 and that you have to use multiple tools to accomplish this :• Package DBMS_TDB• RMAN CONVERT DATABASE command• DBNEWID utility

27

This is an example of a DB2 container rename approach. First you makethe operation on the OS, then afterwards with the utility. The table spacethis is being done to has to be quiesced by way; you cannot perform anydb2relocatedb operations online.Oracle uses the ALTER statements shown above to do the same thing forrenaming files.Note: db2relocatedb does have one restriction: it requires the copy ormove of the data files be to the same operating system family using thesame endianness. You could not for example, copy from AIX to Linux onIntel, nor from HP-UX to Windows. But a copy of AIX to HPU-UX orSolaris would work just fine.

28

These are the two other methods to clone a database in DB2.

29

The backup and restore discussion is a rich one and DB2 has many waysto backup and restore (or recover) a database. This slide is simplyshowing you the fact that you can backup a database and restore it to anew location. Because you can take a table space backup and restore acomplete database by individual table space restores, this means you cando this at a table space at a time if you want to.Also, note that if your restore location doesn’t have mount points or diskfiles that are the same as the backup location, then you will need toperform this restore with a redirect, which simply means you have to tellthe restore where the new file locations should be. DB2 can help youeasily build this redirect script so you don’t have to code dozens of lines oftable space container location names by hand.

30

First, notice that Oracle has many more steps required to restore to adatabase. Oracle has 11 key steps while DB2 uses 5.Also, note that in Oracle steps #2, #4 and #11, there are more sub-tasksto do.The restore steps shown above are a bit out of order because Oracledoes them differently than DB2. The actual DB2 restore steps use thefollowing order:1. RESTORE DB… FROM… REDIRECT WITHOUT PROMPTING2. SET TABLE SPACE… (for each table space container that you are

redirecting)3. RESTORE DB… CONTINUE..4. ROLLFORWARD…

31

Disk mirroring is the process of writing data to two separate hard disks atthe same time. One copy of the data is called a mirror of the other.“Splitting a mirror” is the process of separating those two copies.One drawback to the split mirror method is the cost of implementation.Also, this is an all database or nothing proposition.The SET WRITE SUSPEND command essentially puts all table spacesinto a special write suspend state. No writes will be done during this state,this includes log files. The database remains in a normal workingcondition otherwise and for example, reads can be done without anyaffect.The SET WRITE RESUME simply takes the table spaces and logs out ofthis suspended state.The mirrored database is in a write suspend until the DB2INITDBcommand is run against it to allow it to be used, and as show above, it canbe initialized in three different modes.

32

Burt Vialpando is an IBM Executive IT Specialist and has been anIBM employee since 1998, with professional database experiencesince 1984.Burt is currently working for the IBM DB2 migration team performingpre-sales Oracle to DB2 migration support. He holds numerousDB2, Oracle, and other certifications, currently serves on the IBM ITCertification Board and is an IBM Plateau Level I Inventor.

33