Since this forum may be used for advertising, here goes:

For the past couple of months I have been involved in the development of a hybrid method for the migration of HUGE Oracle databases between machines/platforms. The tool is now developed sufficiently that we are able to tackle migrations of huge databases in a 24 hour timeframe.

The last successes:

1. Customer in Vienna: Oracle/SAP installation, with 2 TB database: 10 hours
2. Customer in Pretoria: Oracle warehouse, with 8 TB database: 15 hours
3. Customer in Pretoria: Oracle/SAP installation, with 2.2 TB database: 9 hours

For the Pretoria based customers, we did some extra optimization, and it paid off quite well! Development is always being done, and we believe we can achieve even better than this, but funding is a problem. :(

Additional achievement of the migration is that we can migrate from an older version of Oracle (8 or less) to the latest, or do complete reorganizations. Even if this is not required, we do deliver a "clean" database, no gaps in the layout, BLOBs reorganized, and with all statistics completely rebuilt!

So, although we have not done a Baan installation yet, we are always willing to try! Anybody interested? Just contact me.

Can you give some details?

Which Oracle versions are supported?
Can you go from data dictionary managed to datafile manged?
What are the space requirements during migration?
Principle method used?

We have several large customers migrating (400-1000 users) and a short migration period would be indeed of interest.

Regards

Markus

Oracle versions:
Source: from 7.3.4 up
Target: preferably 9.2.0.x (although 10i is theoretically supported, we have had no oportunity to test it with a big database yet!)
Dictionary managed VS Local managed:
Yes. During the creation of the database on the target machine, you (the customer) can tell us what you want/need. Any reorganization to the database is open for discussion.

Another often requested change is to move from rollback to undo. This we do standard, since undo management is the better choice.
Space requirements:
Basically you would need enough storage for an additional 3 copies of the database, plus some extra for temporary space.
Let me explain our normal procedure:

The customer provides us with an exact copy of the production environment (platform, O/S, database & application), which we use as the source (thus, we do not touch production!) during the testing phase of the migration project. This obviously needs the same storage capacity as the production server.
This environment is migrated to a new machine, which we call the staging server. This is not the new production machine, but a replica of it! Apart from the disk space needed to contain the database, we will need extra space on this server for the sanity checks.
The new production server is populated from the staging server, and will obviously also need the disk space for it.


The reason for the staging environment is simple. We do, as an assurance to the customer, three basic sanity checks on the database before handing it over to the customer for the User Acceptance Tests, namely:

Object compare - check whether all objects from source have been migrated (includes tables, indexes, views, procedures, users and schema's)
Row count compare - count both the source and target again to ensure all rows are migrated
Byte compare - compare the source and target databases on a byte-for-byte level (This is, as far as I know, unique in the market)

Normally, a UAT takes several hours to complete. To speed up the process, we implement the staging server to parallelize the UAT and the last sanity check. Most customers are willing to accept the database without the byte compare being complete, as long as all the objects and rows are checked. This third sanity check, the byte compare, is therefore not included in the migration time.

A normal migration project is done in four stages:

Technical migration - this is the first actual migration between the copy and the staging, and is mainly used to check whether there are any "funnies" in the database. Time of migration is not important for this stage. The database is copied to the new production machine, but normally not used for UAT's, only for performance testing.
MOCK 1 - the first step-by-step run-through of the migration, with a full-blown UAT. This stage is considered a success when all testing is successful, including the result of the byte compare.
MOCK 2 - the second step-by-step migration, this time including the customers pre-migration work (such as batch jobs and backups). The statistics built during this migration run are stored and used as the basis for the final migration. Again success is declared as for MOCK 1
Final migration - obvious. This is the first time we touch the old production server. Since the migration project plan is built on the MOCK's, and the copy-server is normally smaller (in CPU power) than the old production server, this run is somewhat shorter than the MOCK's.

As for your last question, the principle method used, the following: we call the migration a hybrid method, since we are using several methods in parallel, which are determined during the technical migration. Therefore, the primary method can differ from one customer to another! (Obviously, you want more info, which I'm not giving at this stage! ;) That's the secret part of the toolkit!)

Just wanted to update the statistics achieved with the current version of HOME (Hybrid Oracle Migration Engine :)): Completed a 8.15 terabyte SAP migration from Oracle 9.2.0.6 on HP-UX to Oracle 10.2.0.2 on AIX with a total downtime of 38 hours! ;)

See slide 12 of the attached presentation for the highlights of the achieved results thus far.

HI Nico,

is this in the end a service you offer or a product for sale with support, documentation etc?

Regards

markus

Hi Markus

At the moment it is more a service with the product. I am trying to find the time to package the tool (i.e. build a nice front-end for it and writing the documentation) and then it will be a normal licensed product. For now, I can teach techies how to use it, and provide the license keys per project...

Licensing is done based on the project duration (months), and linked to the machine ID and Oracle SID on the staging server.