Homogeneous System Copy.

[Former Member]

Hello. I'm have one question(or two in one), can we do Homogeneous System Copy from

Sparc Solaris 10 on Oracle 10.2.0.4 to

Intel Solaris 10 on Oracle 10.2.0.2 x86_64 (10.2.0.4 not yet available for this release) ....

Thanks for time.

P.S. 2 restrictions are not cleare for me, aboutBig Endian / Little Endian , and as i know the DB releases must be same for Oracle Specific Copys ....

Regards.

Edited by: Sergo Beradze on Dec 3, 2008 2:07 PM

[markus_doehr2]

That copy is not homogeneous but heterogeneous.

Solaris on SPARC is a BigEndian platform whereas Solaris on x86_64 is LittleEndian (for an explanation what this is all about read http://en.wikipedia.org/wiki/Endianness).

You have to use the R3load method to export the database on the source system and import it into the target system (http://service.sap.com/systemcopy).

Markus

[Former Member]

Hello Markus, Thanks for reply. Yes i know i can do heterogeneous system copy, and do it before on other OS-es and systems, and i know for R3load export i need many time (on this system we have the 420 GB database), but we not have this time (the system are production and uses 24 hour ..... ) We only can do offline backup and use Oracle Specific copy ...

So there is no way, very sorry ....

Maybe you have any possible suggestions?

Also about 10.2.0.4 and 10.2.0.2 is so important for example for heterogeneous ?

Thanks again ...

[markus_doehr2]

We only can do offline backup and use Oracle Specific copy ...

You can´t do that since it will not work, that´s the reason why you have to use the R3load copy method.

Maybe you have any possible suggestions?

You could use the "transportable tablespace" feature of the database but I doubt, that this will be much faster.

How big is that database? Did you check the table splitting feature of R3load?

Also about 10.2.0.4 and 10.2.0.2 is so important for example for heterogeneous ?

If you use R3load it´s not.

Markus

[Former Member]

Database are 420 Gb, and + 2GB every day,

Did you check the table splitting feature of R3load?

No, i do not read about this .... Will try to check now ...

Are this will be much faster?

Thanks for help ...

P.S. the system are ABAP+JAVA .... I do before only on abap,

does it add the time to?

Edited by: Sergo Beradze on Dec 3, 2008 3:40 PM

[markus_doehr2]

>

Did you check the table splitting feature of R3load?

> No, i do not read about this .... Will try to check now ...

Note 952514 - Using the table splitting feature

> Are this will be much faster?

Yes.

You can even start export and import in parallel. It should be possible to migrate the whole system in under 10 hours.

> P.S. the system are ABAP+JAVA .... I do before only on abap,

> does it add the time to?

A bit - since the Java schema need to be exported too - but this will not be significant.

Markus

[Former Member]

Thanks again, i will update this thread letter ...

P.S. hmm i'm think it's no our situation ...

Table splitting can be used for ABAP systems with SAP kernel 6.40 or above.

We have ABAP+JAVA ......

Regards.

Edited by: Sergo Beradze on Dec 3, 2008 4:33 PM

[markus_doehr2]

> P.S. hmm i'm think it's no our situation ...

> Table splitting can be used for ABAP systems with SAP kernel 6.40 or above.

> We have ABAP+JAVA ......

That remark in that note means that you can't split Java tables with that feature, only ABAP tables.

Markus

[Former Member]

Ok, thanks.