heterogeneous copy using Transportable tablespace between different endian

[Former Member]

Hi

We are looking at migrating our HP-UX servers to a different endian servers (big --> little).

The ECC 6 Production system is currently 2.3TB. To migrate to the new servers we are considering using the Oracle transportable tablespaces. The note 1035051 gives a good step by step guide to the process but in the constraints: (constraint 6.) "Opaque types can be transported. However, when you convert endiannes they are not taken into account. In this case, only the application can make the correct decision".

The only application we are using on the databases is SAP.

What happens to the RAW and BLOB columns in tables like CDCLS?? Are there futher steps that need to be performed on the opaque types after the above conversion??

Thanks

Doug

[markus_doehr2 · Accepted solution]

I don´t have an answer to your question but I would recommend using the "SAP supported" approach by using R3load.

With table splitting and a good parallelism you can export about 1 TB in an hour (using fastloader) - if your storage subsystem is able to handle that; you get a "free reorganization" included and you can run export and import in parallel.

Any special reason why you can´t use that approach? Just curious..

Markus

[Former Member · Accepted solution]

Hi Markus

We are looking at the best & quickest way to migrate the database. The transportable tablespace option has merit as we can convert/migration the database as part of the heterogeneous copy process. No indexes need to be recreated/rebuilt afterwards.

Our concerns for R3load process is the creation of the secondary indexes after the R3load import. Does the fastloader improve this process?? I had a quick look around and can't find any detailed information on fastloader, just references to it. Do you know where we can find further information on fastloader?

At the moment, we see transportable tablespaces as possibly faster as the potential bottleneck is the copy process & with multiple LAN cards or SAN solutions we can remove this bottleneck. With R3load, we see the bottleneck as the creation of the indexes after the R3load import and this is harder to optimise (all though it would be good to have a reorganised database at the end).

We have not made up our mind to use transportable tablespaces yet as we evaluate the different mechanisms for Oracle heterogeneous copies. Your feedback is most welcome.

Regards

Doug

[markus_doehr2 · Accepted solution]

Our concerns for R3load process is the creation of the secondary indexes after the R3load import. Does the fastloader improve this process?? I had a quick look around and can't find any detailed information on fastloader, just references to it. Do you know where we can find further information on fastloader?

With "fastloader" I mean the option "-loadprocedure fast" for R3load. Index creation has to be done after the load, that´s right. I´m though not sure, if that is slower. A conversion of a tablespace to a different endinaness runs on one CPU only (one process) whereas the R3loads can run in parallel (and thus index creation runs too in parallel) AND export and import can run in parallel on the two machines.

Given the fact, that this is possible and that you can create your own sequence which tables to load when I could think of a procedure to run (e. g.) 16 R3loads in parallel, two of them import big tables (CDCLS/CDHDR, COSS etc.) and create secondary indices where the other 14 import smaller tables - just as example.

This requires more preparation work, for sure, to get the ideal sequence and ideal number of R3load but you can be sure at the end, that everything is as expected and you are using the supported way of a migration.

I would try it out, it´s not that much work to set up an export and an import of a copy of your to-be-migrated system.

Markus