Forum Stats

  • 3,851,385 Users
  • 2,263,969 Discussions


gg ip address

Annamalai A
Annamalai A Member Posts: 640
edited Dec 1, 2010 9:11PM in GoldenGate
Dear Friends,

Can any one please help me on the below query,

My database running on RAC environment with 2 node , That 2 nodes having two seperate ip address (.51 and .52) , which ip address we need to give in the RMTHOST paramaeter, if in case the particular ip address node failed how gg switch over to 2nd node which is having ip address .52? please guide me on this



  • user11986736
    user11986736 Member Posts: 9 Blue Ribbon

    Not sure what your actual source and target configurations are! Is your source a two node RAC and the target also another two node RAC ? On the source side it is advisable to deploy GG software on shared disk so that you could start the manager/ER processes from any of the RAC nodes without any hassles.

    Do give more details about target setup so that we can try and help answer this query.

  • Annamalai A
    Annamalai A Member Posts: 640
    hi Satish,

    Thanks for your response, My source is Non- RAC environment, Target is the RAC environment with two nodes(.51 and .52), then which ip address i can give in the pump process parameter rmthost?

  • user11986736
    user11986736 Member Posts: 9 Blue Ribbon

    Here is what you need to do:-

    1. Install Golden Gate software on shared disks in target RAC environment.
    2. Point extract/datapump RMTHOST to either .51 or .52 - say you selected .51
    3. Start manager and replicat process from RAC node .51
    4. In case RAC node .51 goes down and is inaccesible, RAC node .52 is up
    a) Stop extract on source (non-RAC)
    b) Change RMTHOST to RAC node .52
    c) Restart extract on source (non-RAC)
    d) Start manager and replicat on RAC node .52 (trail and checkpoint files are accessible as they are on shared disk). Am assuming that RAC node .51 is completely down and manager/replicat processes do not exist.
    5. In case RAC node .52 goes down - replicate will continue to function as extract is sending trail file to RAC node .51

  • -joe
    -joe Member Posts: 226
    Hi Jath.

    Satish's suggestions are very good but I suggest one minor addition and that's to use a virtual IP address. The OGG processes and the VIP will float together on failover. Generally you'll need failover software to failover the process and VIP. Here's a helpful paper I've used a few times when setting this up using Oracle Clusterware:

    So as far as OGG is concerned, the shared disk is a must (or one that can fail over) so that the checkpoint information and trail data pick up where they left off, but RMTHOST will use the VIP. If the connection to A dies then the retry will get routed to B once the VIP and OGG processes fail over. It may also be helpful to use the mgr.prm parameter AUTORESTART to help automate the reconnect interval. But these all things are mentioned in the above doc.

    Good luck,
This discussion has been closed.