RE: Question for Dataguard users

  • From: "Storey, Robert (DCSO)" <RStorey@xxxxxxxxxxxxxxxxxx>
  • To: "Amaral, Rui" <Rui.Amaral@xxxxxxxxxxxxxxxx>, oracle-l-freelists <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 27 Jul 2011 13:44:54 -0500



One of the issues I have is that our application reads a config file to see 
what service to connect to.   There's no way to ask the users to make that 
change in the config.  This might do that.


From: Amaral, Rui [mailto:Rui.Amaral@xxxxxxxxxxxxxxxx] 
Sent: Wednesday, July 27, 2011 1:11 PM
To: Storey, Robert (DCSO); oracle-l-freelists
Subject: RE: Question for Dataguard users


One setup that worked for me when I played with it (we decided to eventually go 
with a network based switch method for other reasons [like jdbc can't parse 
those sorts of connections strings]) was something like this:
















With load_balance=off the connect attempts to access he db via the first entry 
and makes 20 attempts with a 15 second delay between attempts then tries the 
next entry in sequential order.  Worked fine with the standard oci client but 
your mileage may vary on your environment.



From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Storey, Robert (DCSO)
Sent: Wednesday, July 27, 2011 1:43 PM
To: oracle-l-freelists
Subject: Question for Dataguard users


Okay, have a question for the dataguard users.  Probably more for the non-RAC 
folks than anything.


My setup is a primary and a single physical standby.


In the event of a switchover, all user connections are broken and the switch 
occurs.  Then users have to reconnect.


But, I'm looking for the best way to structure the TNSNAMES file.  I'm probably 
over thinking this, but, there has to be a way to create both entries for both 
servers in the file, but only have them use the production one.  Something 
tickles my brain from way back that it will run the TNS list in order looking 
for a connection.


Just curious how others have set up their files.



NOTICE: Confidential message which may be privileged. Unauthorized 
use/disclosure prohibited. If received in error, please go to 
for instructions.
AVIS : Message confidentiel dont le contenu peut être privilégié. 
Utilisation/divulgation interdites sans permission. Si reçu par erreur, prière 
d'aller au pour des instructions.

Other related posts: