Skip to Main Content
  • Questions
  • database migration from AIX to Linux

Breadcrumb

Question and Answer

Connor McDonald

Thanks for the question, KRISHNA.

Asked: February 26, 2016 - 11:47 am UTC

Last updated: November 07, 2017 - 1:25 pm UTC

Version: 11.2.0.4

Viewed 10K+ times! This question is

You Asked

Hello Tom,

We are planning to migrate database from AIX to Linux.

Because of different endian we can't built the standby,here my request was Production databases have 30-40TB of data.
Some tables have 1-5 TB of only data what was the best way to sync with Prod for big tables for what was Best approach suggested.

Hope transportable tablespace not works in my environment because i can't hold the read only for some hours to convert. One table 5tb with out partition its have huge transactions.below stats only for 10hours

TABLE_OWNER TABLE_NAME INSERTS UPDATES DELETES TIMESTAMP
------------------------------ ------------------------------ ---------- ---------- ---------- -------------------
XXXXXX XXXXXXXXX 7171060560 1 475448516 26-02-2016 11:22:28

and Connor said...

Check out the cross platform migration on MOS 2005729.1. It uses transportable tablespace *but* the read-only time is nearly eliminated. The basic process is:

- backup datafiles (source system stays online)
- convert datafiles (source system stays online)
- take incremental backups (source system stays online)
- convert incremental backups (source system stays online)
- apply incrementals to target (source system stays online)

and then there is a final cutover stage, where you take an incremental backup with the source system in read-only. With block change tracking activated, this is extremely fast.

I used this for a similar migration (aix 11.2 => linux 11.2). The outage window for cutover was small (about 60-90mins). In my case, that was then followed by a larger outage to move from 11.2 to 12.1.

Ultimately the note is more of a guide - you'll end up customizing it to suit your needs, and run some additional scripts to cater for missing parts, but the process does indeed work well.

If you need *zero* downtime...then you'd be heading into GoldenGate territory, and that's a large undertaking in its own right.

Rating

  (2 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Other options to be considered

Jose Laurindo Chiappa, February 29, 2016 - 8:08 pm UTC

Besides this, if allowed/applicable in this case (this must be checked in Oracle Support, different notes register the different options, and things like 32/64 bit architecture and bugs could apply), other options for almost-zero downtime could be Logical Dataguard (see note "Data Guard Support for Heterogeneous Primary and Logical Standbys in Same Data Guard Configuration" (Doc ID 1085687.1)), Heterogeneous Physical Dataguard (see note "Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration" (Doc ID 413484.1)).
With just a little of downtime/read-only time, another option could be Transportable Databases, see http://www.oracle.com/technetwork/database/features/availability/maa-wp-10gr2-platformmigrationtdb-131164.pdf

regards,

J. laurindo Chiappa
Connor McDonald
February 29, 2016 - 11:50 pm UTC

Thanks for your input

Very Useful

Shubham, November 07, 2017 - 11:18 am UTC

Hi Tom,

I have gone through the doc id given by you, kindly let me know the doc/steps for migrating database from 11.2.0.4 running on AIX to 12.1.0.2 on RHEL 7.


Thanks
Connor McDonald
November 07, 2017 - 1:25 pm UTC

Your review asked the same question as the original question. My answer is the same as well...



Check out the cross platform migration on MOS 2005729.1. It uses transportable tablespace *but* the read-only time is nearly eliminated. The basic process is:

- backup datafiles (source system stays online)
- convert datafiles (source system stays online)
- take incremental backups (source system stays online)
- convert incremental backups (source system stays online)
- apply incrementals to target (source system stays online)

and then there is a final cutover stage, where you take an incremental backup with the source system in read-only. With block change tracking activated, this is extremely fast.

I used this for a similar migration (aix 11.2 => linux 11.2). The outage window for cutover was small (about 60-90mins). In my case, that was then followed by a larger outage to move from 11.2 to 12.1.

Ultimately the note is more of a guide - you'll end up customizing it to suit your needs, and run some additional scripts to cater for missing parts, but the process does indeed work well.

If you need *zero* downtime...then you'd be heading into GoldenGate territory, and that's a large undertaking in its own right.