RE: DataGuard Failover and Thin Clients

  • From: "Vishal Gupta" <vishal@xxxxxxxxxxxxxxx>
  • To: <ag@xxxxxxxxxxxx>, <ian@xxxxxxxxxxxxxxxxx>
  • Date: Sun, 31 Jan 2010 14:51:24 -0000

One thing to note though, JDBC/Oracle thin client does not TAF
(Transparent Appication Failover). Its supported only on oci driver. 

jdbc:oracle:oci:@....


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Alex Gorbachev
Sent: 22 January 2010 04:35
To: ian@xxxxxxxxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: DataGuard Failover and Thin Clients

Ian,

You cold just use the whole connection descriptor on thin JDBC driver  
if that's what you need.
like this - ""jdbc:oracle:thin:@" +
               "(DESCRIPTION=(FAILOVER=ON)(LOAD_BALANCE=ON)\n" +
               "(ADDRESS=(PROTOCOL=TCP)(HOST=lh1-vip)(PORT=1521))\n" +
               "(ADDRESS=(PROTOCOL=TCP)(HOST=lh2-vip)(PORT=1521))\n" +
               "(CONNECT_DATA=(SERVICE_NAME=s10gr2)))";"

This is a RAC example but you would do something similar for Data  
Guard (potentially with different LOAD_BALANCE setting.

Alex

On 14/01/2010, at 1:11 PM, MacGregor, Ian A. wrote:

> For thick clients the tnsnames.ora file includes two or more hosts  
> for a given service_name,  I believe clients treat this as an  
> ordered list and try each one until a connection is established.    
> Thin clients  do not use tnsnames.  One suggestion is to use  
> LDAP.but I'm not sure how universal that is nor exactly how to set  
> it up.
>
> Another thought is to have the machines switch names and ip  
> addresses right after a switchover.  These machines have four NIC's  
> each.  Oracle would be a service on one of them.   This type of  
> thing is often done via clusterware.  Can Oracle's clusterware do  
> this?  This is not a RAC environment, but a physical standby one.
>
> I realize there are going to be consequences of doing this, any  
> which are unsurmountable.   I'm not in favor of this.  It seems over- 
> engineered,  but that may be due to ignorance.
>
>
> Ian MacGregor
> SLAC National Accelerator Laboratory
> ian@xxxxxxxxxxxxxxxxxxx
> //www.freelists.org/webpage/oracle-l
>
>

--
//www.freelists.org/webpage/oracle-l


--
//www.freelists.org/webpage/oracle-l


Other related posts: