Re: Porting database across hardware platforms
Date: Wed, 10 Jul 2002 18:58:40 -0400
Message-ID: <e1epiu4vdks09tgtcosb7amqt5m1uctsjs_at_4ax.com>
On 10 Jul 2002 15:35:08 -0700, rs_arwar_at_hotmail.com (Rauf Sarwar) wrote:
>"JohnO" <john.d.osborne_at_hp.com> wrote in message news:<6NWW8.5$Yq6.269354_at_news.cpqcorp.net>...
>> Yes, it seemed like export and import of the database would be the simplest
>> and safest solution. What about data marshalling issues, such as the
>> "endian" of numerics? Does exporting on one platform create a generic data
>> structure that can be imported on a completely different HW platform
>> correctly?
The oracle internal datatypes I've worked with don't have endian issues. You may run into issues with various LOBs, but you would likely have them with remote access anyway.
I believe the export format consists of a table definition followed by raw rows. All reports I have seen indicate that exports are portable across O/Ss. There can be issues with import/export across releases of Oracle. The issue below could qualify as release differences.
I generally do three exports.
- no data, no constraints, no statistics (Table Definitions)
- data, no constraints, no statistics (Data Load)
- no data, constraints, calculate statistics. (Constraints)
Load the imports in the order given to avoid the overhead of row by row constraint checks and index insertion. If you have analyze privileges you can ignore the stats and run them after the load is completed.
Depending on the data you could also look at spooling selects to create files for SQL*Loader. I often use SQL*Loader to load files created by other systems.
-- BillReceived on Thu Jul 11 2002 - 00:58:40 CEST
>> "Sybrand Bakker" <postbus_at_sybrandb.demon.nl> wrote in message
>> news:tdmmiukkrctftfv5upd6vhsntmqngojpc1_at_4ax.com...
>> > On Tue, 09 Jul 2002 19:59:29 GMT, "JohnO" <john.d.osborne_at_hp.com>
>> > wrote:
>> >
>> > >I need to develop a method of porting multiple Oracle databases from one
>> > >hardware platform to another, minimizing development work and rework
> >
>> > Your 'tools' are called 'exp' and 'imp'
>I came across a document a while back about errors relating to "little >endian" to "big endian" byte order when doing a VLDB migration from >one platform to another on Oracle Metalink http://metalink.oracle.com. > >I think it had to deal with using a 32 bit migration utility VS 64 bit >migration utility. If you Export using a 32 bit migration utility then >you *have* to use 32 bit migration utility to do the Import even >though the target database is on 64 bit version. I think that was the >resolution but in any case, search for the document on >Metalink..(Sorry no DocID) which I believe describes in detail all the >supported migration tracks between different Oracle versions i.e. 32 >Bit --> 64 Bit etc. > >HTH >//Rauf Sarwar