Migration IBM AIX ==> SPARC Solaris with Data Guard

Can we migrate our database with Oracle Data Guard?

We are getting this question asked quite often during our workshops or via email. And if you are staying within the same operating system family (such as Red Hat 5.8 to OL 7) all is fine, and this is one of the best and most simple approaches to jump between servers. Even when you add a subsequent database upgrade all is very straight forward.

But what if you mix operating systems?

The Support Note for Heterogeneous Data Guard Configurations explains which combinations are allowed beginning with specific releases:

MOS Note: 413484.1
Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration

The most popular combinations are Windows to Linux or Intel Solaris to Linux beginning with Oracle 11.1. One combination often requested was IBM AIX to Oracle SPARC Solaris. And we did support this for a few weeks – a white paper got published – and taken away shortly after, removing the support as it turned out that the control file had 5 or 6 pieces which were highly OS dependent. There were rumors circling around you still could do it with a bit of manual extra work.

Migration Oracle on AIX to SPARC SOLARIS

Now (ok, since end of March 2015), surprise-surprise, there’s an official MOS Note available explaining on how to migrate away from IBM AIX to SPARC Solaris by using a Physical Standby Database beginning with Oracle

MOS Note: 1982638.1
One Time Migration Steps from IBM AIX Power to Solaris SPARC using Data Guard

It is based on the MOS Note:469493.1 (Step By Step Guide to create a Physical Standby Database using RMAN Backup/Restore).

But the support has been revoked afterwards as there were some issues. The migration from AIX to SPARC Solaris works officially in a supported way from Oracle Database, but may be doable with the below workaround to recreate controlfiles with Oracle Database as well.

The key action is to recreate the controlfile. To recreate a new primary control file, use the following procedure:

  1. On the open production, connect as SYSDBA, and issue “alter database backup controlfile to trace;”
  2. In the trace file for this session you will see two sets of DDLs to create a new backup control file. Use the set of DDLs that create the control file with the NORESETLOGS option (Set # 1)
  3. Shutdown the production database
    SQL> shutdown;
  4. Run the commands in the trace file starting with ‘startup NOMOUNT’, ‘CREATE CONTROLFILE REUSE .. NORESETLOGS ..’, ‘RECOVER DATABASE’, etc..

And how about Big to Little Endian platforms?

As the redo stream is highly OS dependent I don’t think that we’ll see combinations such as HP-UX to OL in the near future – just my feeling. But with the offering of Full Transportable Export/Import and the help of RMAN Incremental Backups (see this presentation in our Slides Download Center about it: ) we have very strong alternative in place.


Share this:

8 thoughts on “Migration IBM AIX ==> SPARC Solaris with Data Guard

  1. Hi,

    starting with MOS:413484.1 ,i see the Primary Bug that "locked " the cross migration from AIX to SOLARIS [in favor of GG 🙂 ] is disappeared.
    But now the MOS:1982638.1 cannot be displayed, some days ago yes (you know the reason?).
    Reading your "key action" i need bounce production DB ,for recreate CF, but if the system is mission critical with no possibility of downtime or near zero downtime.
    i know all other methodologies for migration , but prefer execute COMPLETE physical migration with DG (if possible with duplicate from active).

    I would like re-read the note mentioned above,I don’t understand (motivation) the action plan to recreate CF.

    Affirm the migration from SOLARIS to AIX not work, what are the reasons?

    thanks in advance.


  2. Thanks – see your point, verified it – and I alerted the PM and the Support Global Tech Lead in the US about it. I hope they’ll fix it asap.


  3. Configuring Oracle GoldenGate Integrated Capture by using downstream deployment option.

    Source Database: AIX – 64bit
    Target Database : OEL 6 , 64bit

    I am configuring redo shipment from AIX to OEL. and got following error in alert.

    This setup needs following configuratio at Source ( AIX)
    log_archive_config=’DG_CONFIG=(srcdb, msdb’);

    but i am getting following error:
    *** 2016-08-15 17:40:59.391
    Destination is specified with ASYNC=61440
    Redo shipping client performing standby login
    *** 2016-08-15 17:40:59.535 4645 krsu.c
    Logged on to standby successfully
    Client logon and security negotiation successful!
    Software version mismatch: found 200 wanted 2
    Archiving to destination msdb ASYNC bytes=10485760
    Allocate ASYNC I/O: Previous bytes=0 New bytes=10485760
    Log file opened [logno 6]
    Error 272 writing standby archive log file at host ‘msdb’
    *** 2016-08-15 17:40:59.589 4320 krsh.c
    LNS: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (272)
    *** 2016-08-15 17:40:59.590 4320 krsh.c
    LNS: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
    *** 2016-08-15 17:40:59.590 4320 krsh.c
    Error 272 for archive log file 6 to ‘msdb’
    *** 2016-08-15 17:40:59.592 2932 krsi.c
    krsi_dst_fail: dest:2 err:272 force:0 blast:1
    ORA-00272: error writing archive log
    Closing Redo Read Context
    Redo Push Server: Freeing ASYNC PGA buffer

  4. Umaruddi,

    sorry for the inconvenience. But please understand that I can’t solve such issues via the blog (and I’m neither an OGG expert). Please open an SR and clarify this with Oracle Support.


  5. Hi Mike,

    We are in-progress of migration from AIX to Sparc-M7, As part of UAT I didn’t find any reasons for concern and there were no signs of problems
    on DG replication after switch-over from AIX to SPARC-M7 with out re-creating controlfile. Since the domain is banking hope you can understand the pain
    area of getting outage. Please let me know whether we can handover the database without re-creating controlfile and what would be the possible complications if we doesn’t re-create controlfile.

    Awaiting for your response to propose final migration plan with higher management.

    Thanks &Regards
    Vasudeva Guduru

  6. Vasudeva,

    I think the official support will happen with Oracle 12.2 but I may be wrong. Technically it should work. If you need an official statement from Oracle please open an SR and ask Oracle Support. I can’t give you an official "Go" for a product area we don’t own unfortunately.


Leave a Reply

Your email address will not be published. Required fields are marked *

* Checkbox to comply with GDPR is required


I agree

This site uses Akismet to reduce spam. Learn how your comment data is processed.