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.
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 188.8.131.52:
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 184.108.40.206, but may be doable with the below workaround to recreate controlfiles with Oracle Database 220.127.116.11 as well.
The key action is to recreate the controlfile. To recreate a new primary control file, use the following procedure:
- On the open production, connect as SYSDBA, and issue “alter database backup controlfile to trace;”
- 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)
- Shutdown the production database
- 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.
Good stuff! Does it work other way around? Solaris -> AIX?
No – only AIX==>SPARC.
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.
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.
Configuring Oracle GoldenGate Integrated Capture by using downstream deployment option.
Source Database: AIX – 18.104.22.168 64bit
Target Database : OEL 6 , 22.214.171.124 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_Dest_2=’SERVICE=msdb ASYNC OPTIONAL NOREGISTER VALID_FOR=(ONLINE_LOGFILE,PRIMAY_ROLE) DB_UNIQUE_NAME=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
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.
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.
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.
Does this work between Intel Solaris to Linux beginning with Oracle 11.1?
I can’t see it in the support matrix.
please see here:
Rows 13 and 20 work together since 126.96.36.199 (i.e. Intel Solaris x86-64 with Linux x86-64),
Does this approach work for Solaris –> to AIX ? If not what would be the reason.?
I really don’t know – you need to check with Oracle Support please.