Migration Troubleshooting

What are the disk space requirements for migration?

The utility needs approximately 1.5-2 times the size of the source database of free, local disk space. So if you have a database with 10 GB of data, ensure that you have at least 15 GBs of disk space available on the server on which you are running the utility.

How long does it usually take to do the migration?

The time taken will be completely dependent on hard-disk and network speeds and the current load on source and target databases. On a fast disk and reasonably fast network, we have been able to migrate data at the rate of 15-18GB/hour with validation.

Can the migration be broken into multiple steps?

Yes, but it is recommended you run all of the steps that are required in every run. The migration internally is broken into multiple steps:

1. Export the data from Source database: Steps required are exportBlobs, writeEtls
2. Import the data to the target database: Steps required are createTargetSchema, runEtls
3. Validate the imported data: Steps required are validate

The validate step will generally be the most time consuming and may be excluded, though it is recommended that you always run it. If you exclude this step, check the missing_fk.log and truncated.log files for errors that may have occurred during migration.

Where are the migration logs stored?

All the logs files are stored in the workDir.

Why might the migration fail?

There are two reasons why data may not migrate completely from the source to the target database.

• Foreign Key Constraints: Some records in the source database may have constraints that point to records that have been deleted. The migration utility will not import these record. When it finds a record that has Foreign Key constraints that do not exist, a entry will be generated in missing_fk.log. In most migrations, the total number of records that have missing foriegn keys should be around 0.5-1% of the total number records in the database.
• Data truncation: It is possible that size of certain text/varchar/char columns in the target database may not be large enough to accommodate data from same columns in the source database. The migration utility checks the size of every text/varchar/char column before inserting the data into the target database. If the size of the text to be inserted exceeds the column limit, it will truncate the text to fit the column size. In addition, it will create an entry in the truncated.log log file for every record that has been truncated with the original and truncated text.

How do I know whether the migration succeeded?

At the end of the migration, a summary.html file is generated, that will give a quick summary of the migration. The file contains an entry for each table that is migrated. The entry will contain row counts, count of rows that differ (the delta), and a link to the log file that contains the diff between the source and target. Below is an example of the summary.html:

DB MIGRATION REPORT

Fri Jan 09 11:19:59 PST 2009

Summary