Step Five: Verification and Maintenance

After the data has been migrated, you need to verify the data through extensive testing. In most cases, not everything will be perfect on the first pass, and you will need to reload data. Oracle’s DCT helps you keep track of the process by logging the migration of data for every column. DCT uses the Schema Reference to track these changes. The Schema Reference stores the following information regarding each field that is being mapped:

•  Field—Description of field

•  Table\View—Name of table or view

•  Owner—Owner of table or view

•  Database—Database name on which a field resides

•  Host—Hostname

•  Last Update—Date of last modification or data update

•  Create Date—Date of Table/View creation

•  Status—Is the Table/View available?

•  Column_Name—The Oracle column name for the field

•  Data Type—The Oracle datatype of the field

With this structure, your migration effort does not become a nightmare, as many do, because you can keep track of all the mappings from the old system to Oracle and of the changes to this translation process.

Aside from accurate record-keeping, the DCT offers more glamorous options like the Impact Analyzer which can point to cascade effects that may occur when you change a simple data element or mapping in the migration. This is useful because, in most migrations, the mapping and design process can be invalidated by an inadvertent change to one field, especially if that field is a foreign key for many tables (see Figure 7.17).

Figure 7.17.  Changing one field of source data can invalidate much of a migration unless it is anticipated.

Migrating a Front-End Using DCT and Oracle*Forms 4.5

The DCT offering by Oracle also can fit in with automatic form generation using Oracle’s Oracle*Forms 4.5. The catch is that these forms cannot be generated from your original forms written with tools, such as CICS. But Oracle*Forms can generate simple block-mode or GUI forms based on table and column definitions.

For most complex systems, this is not useful, because forms can contain a great deal of flow-of-control logic for the users and also may communicate with many different tables, given the functions performed on the form. In most cases, this forces you to redesign or, at least, redeploy the existing forms on the new front-end.

Oracle’s form generation utility is useful for less complex systems and for the generation of maintenance screens that map to either one table alone or one table driving a multi-row display of another table. Sometimes these quick forms that are easy to generate can help greatly in the testing and the verification of the new Oracle system in parallel with the old system, so they should not be discounted.

Oracle DCT—Is It Worth It?

Guess what, the answer to the question is “Yes.” The reason might not be the one Oracle would want you to believe. The DCT alone is not a cure-all and requires the participation of many database and programming experts. What the DCT does give you, which is invaluable, is a methodology for system migration.

Many glamorous corporations will simply sell methodology tools and documentation for huge amounts of money. What you are buying in these cases is a philosophy from an expert and a way to implement that philosophy. In this case, you would be looking for methodologies to migrate/downsize a software application. Step-by-step procedures, and software to keep track of those procedures, can also be purchased from a methodology vendor.

Other companies sell conversion tools. They have no interest in methodology but only sell a tool. An example of this would be a tool to convert Sybase ISQL to Oracle PL/SQL. These companies are not concerned with the overall approach to migration, but sell products to complete a set of specific tasks.