This discussion is archived
1 2 Previous Next 15 Replies Latest reply: Oct 29, 2012 12:19 PM by Pinela RSS

cascading standby - heartbeat failed

Pinela Journeyer
Currently Being Moderated
Hello guys,

the situation is this.
we had 3 servers in a DG configuration:
- 1 primary (PRODSB2 server A)
- 2 physical standbys for DB on server A ( PRODSB on server B and PROD2012 on server C)
- these were using the Broker without problems
- all have an instance_name and db_name = PROD
- the db_unique_name parameter has the PRODSB2, PRODSB and PROD2012 values

DBs are 11.2.0.3 on RHEL 6 64bits

now we wanted to add a cascading standby (from PROD2012 server C, to PRODSBPSY server D).
a cold backup was made from PRODSB (server B) and the backup restored on server D. the db_unique_name was changed from PRODSB to PRODSBPSY.
the orapw file was copied from the server B.
I can tnsping and sqlplus @ as sysdba from server C to server D.

on server C (to be setup as a cascading standby), the following commands where run:
alter system set log_archive_dest_3='service="PRODSBPSY", LGWR ASYNC NOAFFIRM delay=0 OPTIONAL compression=enable max_failure=0 max_connections=1 reopen=300 db_unique_name="PRODSBPSY" net_timeout=30  valid_for=(standby_logfiles,standby_role)' scope=both;
alter system set log_archive_dest_state_3=enable scope=both;

alter system set fal_client=prodsbpsy scope=memory;
alter system set fal_server=prod2012 scope=memory;
and I get the following errors (if trying to add the new server to the standby or not).
 FAL[server]: DGID from FAL client not in Data Guard configuration

 DGMGRL>  add database prodsbpsy as connect identifier is PRODSBPSY;
Error: ORA-12154: TNS:could not resolve the connect identifier specified

PING[ARC2]: Heartbeat failed to connect to standby 'PRODSBPSY'. Error is 16047.
Sat Oct 27 22:36:04 2012
PING[ARC2]: Heartbeat failed to connect to standby 'PRODSBPSY'. Error is 16047.
so to bypass the "not in dataguard configuration" error, I try adding the standby to the DG config, but get the tns error.
but again, I can tnsping the server, and can sqlplus as sysdba through the listener (so, using the password).
the tnsnames entry on server C to the instance on server D is:
-bash-4.1$ tnsping prodsbpsy
TNS Ping Utility for Linux: Version 11.2.0.3.0 - Production on 28-OCT-2012 19:07:46
Copyright (c) 1997, 2011, Oracle.  All rights reserved.
Used parameter files:
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = psyco)(PORT = 1600)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = PRODSBPSY.domain.com) (INSTANCE_NAME=PROD)))
OK (50 msec)
-bash-4.1$
the service_names on the instance PRODSBPSY is
service_names                        string      PRODSBPSY.domain.com
well, I hope that I explained the problem correctly
googling all I find are:
- references to the orapw file (it was copied and the password is the same).
- references to the db_unique_name that is different in the DB than in the log_archive_dest_N parameter (it is the same).

hope someone can help me.

thanks in advance everyone.

br,
jpinela.
  • 1. Re: cascading standby - heartbeat failed
    mseberg Guru
    Currently Being Moderated
    Hello;

    Can you post the INIT's for both Standby's and the Primary?

    fal_client is obsolete in Oracle 11.2 but that is not your issue.

    Still worth a look :

    FAL_SERVER And FAL_CLIENT Settings For Cascaded Standby [ID 358767.1]

    ORA-12154

    Until you can do the following:

    sqlplus sys/password@Standby as sysdba (from the primary system)

    and

    sqlplus sys/password@primary as sysdba (from the standby system)

    You will not be able to ship redo. You have an error in your tnsnames and listener configuration.

    Most likely your tnsname is missing an entry or has an incorrect entry.

    Also see

    ORA-01031 ORA-12154 ORA-12514 in Standby or Dataguard Environment [ID 1271362.1]

    ORA-16047

    ORA-16047 is a mismatch between destination setting and standby. Yes, make sure they are the same case too. LOG_ARCHIVE_CONFIG if set can cause this too.


    Best Regards

    mseberg
  • 2. Re: cascading standby - heartbeat failed
    saurabh Pro
    Currently Being Moderated
    there are few things that you should look out for

    1. FAL_CLIENT and FAL_SERVER parameter is set properly on your server D. It wil be as follow

    fal_client=prodsbpsy
    fal_server=prod2012

    2. Have you coppied the password file to the server D.

    3. HAve you made the tns entery properly on both the server B and D.

    4. Have you made the entery in the listener file of both the server.
  • 3. Re: cascading standby - heartbeat failed
    Pinela Journeyer
    Currently Being Moderated
    mseberg,

    thank you for the help.

    I'll post the init's asap.
    meanwhile, yes, LOG_ARCHIVE_CONFIG is set on server C (PROD2012) but not on server D. this because the broker is being used between A,B and C.
    Does the broker need to be turned off in either of these? If so is a bounce on the primary necessary?

    >
    ORA-16047

    ORA-16047 is a mismatch between destination setting and standby.
    >
    which parameter do you mean?

    thank you.
    br,
    pinela.
  • 4. Re: cascading standby - heartbeat failed
    Pinela Journeyer
    Currently Being Moderated
    saurabh thank you,

    1 - yes
    2 - yes
    3 - this in on C. does it have to be on D as well?
    PRODSBPSY =
    (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = psyco)(PORT = 1600))
    (CONNECT_DATA =
    (SERVER = DEDICATED)
    (SERVICE_NAME = PRODSBPSY.domain.com)
    (INSTANCE_NAME=PROD)
    )
    )

    this in on D
    PRODSBPSY =
    (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = psyco)(PORT = 1600))
    (CONNECT_DATA =
    (SERVER = DEDICATED)
    (SID = PROD)
    )
    )
    4 -
    listener.ora on D
    SID_LIST_LISTENER_PROD =
    (SID_LIST =
    (SID_DESC =
    (GLOBAL_DBNAME = PROD.domain.COM)
    (ORACLE_HOME = /opt/app/oracle/product/11.2.0/db_1)
    (SID_NAME = PROD)
    )
    )
    do I need to change the lisetner on C?

    thank you.
    br,
    pinela
  • 5. Re: cascading standby - heartbeat failed
    saurabh Pro
    Currently Being Moderated
    can you give the output of instance_name on both the server c and D.
  • 6. Re: cascading standby - heartbeat failed
    Pinela Journeyer
    Currently Being Moderated
    saurabh,

    sure.

    instance_name PROD

    br,
    jpinela
  • 7. Re: cascading standby - heartbeat failed
    Pinela Journeyer
    Currently Being Moderated
    mseberg,

    when you say
    >
    Until you can do the following:
    sqlplus sys/password@Standby as sysdba (from the primary system)
    and
    sqlplus sys/password@primary as sysdba (from the standby system)
    You will not be able to ship redo. You have an error in your tnsnames and listener configuration.
    Most likely your tnsname is missing an entry or has an incorrect entry.
    Also see
    ORA-01031 ORA-12154 ORA-12514 in Standby or Dataguard Environment [ID 1271362.1]
    >
    "primary" do you mean from the cascading standby? or the actual primary?
    because I can do sqlplus sys/pass@standby from the cascading standby's server (cascading server C, PROD2012 and standby D PRODSBPSY).

    thank you
    br,
    jpinela.
  • 8. Re: cascading standby - heartbeat failed
    teits Pro
    Currently Being Moderated
    I'll post the init's asap.
    meanwhile, yes, LOG_ARCHIVE_CONFIG is set on server C (PROD2012) but not on server D. this because the broker is being used between A,B and C.
    Does the broker need to be turned off in either of these? If so is a bounce on the primary necessary?
    i like to believe not setting LOG_ARCHIVE_CONFIG parameter properly is the issue. set LOG_ARCHIVE_CONFIG on both server C and D.
    entry should look like this:
    LOG_ARCHIVE_CONFIG='DG_CONFIG=(PRODSB2,PROD2012,PRODSBPSY)'

    See doc note: "LOG_ARCHIVE_CONFIG enables or disables the sending of redo logs to remote destinations and the *receipt of remote redo logs*, and specifies the unique database
    names (DB_UNIQUE_NAME) for each database in the Data Guard configuration."

    You dont need to bounce the primary database.

    Does the broker need to be turned off in either of these? this depends on you, I will not turn the broker OFF. why should you? just configure the cascade without broker.
    broker does not support cascaded destinations

    Also make sure you can do:
    sqlplus sys/pass@PROD2012_tns from server D
    sqlplus sys/pass@PRODSBPSY_tns from server C 
    Tobi
    HTH

    Edited by: teits on Oct 29, 2012 10:04 AM
  • 9. Re: cascading standby - heartbeat failed
    saurabh Pro
    Currently Being Moderated
    going through your tns you can just make an entery of your primary prod2012 in the tns file of server D.
    and make an entery of

    fal_client=prodsbpy
    fal_server-prod2012
    on server D.

    and try again
  • 10. Re: cascading standby - heartbeat failed
    Pinela Journeyer
    Currently Being Moderated
    hum, ok.
    very well. I'll change the DG_CONFIG.
    >
    Does the broker need to be turned off in either of these? this depends on you, I will not turn the broker OFF. why should you? just configure the cascade without broker.
    broker does not support cascaded destinations
    >
    yes, the documentaion often mentions that cascading is not supported. By "not supported" I understood that the broker could not be used. My mistake.

    I'll try it.
    thank you,

    br,
    pinela.
  • 11. Re: cascading standby - heartbeat failed
    Pinela Journeyer
    Currently Being Moderated
    saurabh,

    the tns on D is created (alias PROD2012), and the fal values I believe are too. But I will check.
    thank you.

    I will test the parameter later. I'll report back with the status.

    br,
    jpinela

    Edited by: Pinela on Oct 29, 2012 10:35 AM
  • 12. Re: cascading standby - heartbeat failed
    Pinela Journeyer
    Currently Being Moderated
    teits,

    thanks.
    the parameter did the trick.

    and this is still going on:
    I'm still getting the error while trying to add the standby to the broker configuration.
    DGMGRL> add database prodsbpsy as connect identifier is PRODSBPSY;
    Error: ORA-12154: TNS:could not resolve the connect identifier specified
    
    Failed.
    DGMGRL>
    any idea why this persists?

    br,
    pinela.

    Edited by: Pinela on Oct 29, 2012 4:57 PM
  • 13. Re: cascading standby - heartbeat failed
    mseberg Guru
    Currently Being Moderated
    Hello

    Would expect this :
    add database prodsbpsy as connect identifier is prodsbpsy;
     
    To be more like this :
    add database 'prodsbpsy' as
    connect identifier is 'prodsbpsy'
    maintained as physical;
    Best Regards

    mseberg
  • 14. Re: cascading standby - heartbeat failed
    teits Pro
    Currently Being Moderated
    I'm still getting the error while trying to add the standby to the broker configuration.
    DGMGRL> add database prodsbpsy as connect identifier is PRODSBPSY;
    Error: ORA-12154: TNS:could not resolve the connect identifier specified
    
    Failed.
    DGMGRL>
    any idea why this persists?
    Is PRODSBPSY cascaded destinations? i will not add it to broker if it a cascade destination.

    paste tnsnames.ora if you can --ora-12154 is related to tns.
    from the primary DB(the owner of broker configuration), perform tnsping test to PRODSBPSY.

    let see the error in drc<sid>.log

    Tobi
1 2 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points