You can migrate your database across platform.So it is up to you which method you would like to choose as all are the best.
Step 1: Down load the zip files and install it under product/goldengate directory.
Step 2: Set the ORACLE_SID of the source database.
Step 4: Creates database user goldengate and grant appropriate privilages.
Step 5: Make sure that source database is in archive log mode.
Step 6: Enable supplemental log. You can enable it for database or for a specific table.
Step 7: Run ./ggsci from /u01/app/oracle/product/goldengate directory.
Step 9: Repeat Step 1-5, 7 and 8 for the TARGET database.
ERROR: Parameter file /u01/app/oracle/product/goldengate/dirprm/mgr.prm does not exist.
Step 8: REPEAT the above steps for TARGET database machine.
MAP: with GoldenGate we can have the target database structure entirely differ from that of the source in terms of table names as well as the column definitions of the tables.
We now start the initial data load task load 1 on the source. Since this is a one time task, we will initially see that the extract process is runningand after the data load is complete it will be stopped.
We do not have to manually start the Replicat process on the target as that is done when the Extract task is started on the source system.
Oracle GoldenGate supports data capture from an Oracle Database using ASM. This section applies to Oracle ASM 11g Release 2.
· Extract requires a connection into an ASM instance to be able to read the transaction logs. The connection has to go through the Oracle Database listener and because the ASM instance is only mounted (not open) an entry for the ASM instance must be added to the listener configuration file in order to let incoming connections go through. See the Oracle GoldenGate for Windows and Unix Administrator Guide as well as Oracle Support note 340277.1 for more details.
· The tnsnames.ora file(s) or LDAP directory must include entries to the ASM instance(s) in order for connect strings to resolve connection requests.
An ASM instance is not a regular database instance and does not support the concept of regular database users. As a result the user Oracle GoldenGate uses to connect to ASM is always an administrative user (SYSASM) which would enable startup and shutdown of the instance. The connection will not fail if the instance is down, but Oracle GoldenGate extract will not be able to start because any queries issued against the ASM instance will fail.
If you use Oracle GoldenGate to extract from an Oracle RAC database that uses ASM to store its logs, and your connection to ASM could be routed to any ASM instance in the cluster, then you may run into the situation that extract connects to an ASM instance that happens to be down. In that case extract will crash, although the database may still be running fine on other servers. This will cause the extract process to fall behind.
-attr "ACTION_SCRIPT=/mnt/acfs/oracle/grid/11gr2_gg_action.scr, CHECK_INTERVAL=30, START_DEPENDENCIES='hard(mvggatevip,ora.asm) pullup(mvggatevip)', STOP_DEPENDENCIES='hard(mvggatevip)'"
All other steps to configure Oracle GoldenGate with Oracle Clusterware remain the same, and all configurations discussed in the section Oracle GoldenGate with Oracle Clusterware will work.