Re: Can SQLNET client contain multiple IPs for a single SID??

From: Kevin Brand <kevin.brandx_at_tel.gte.com>
Date: Wed, 10 Feb 1999 12:46:10 -0600
Message-ID: <79skbm$op0$1@news.gte.com>

Best solution:
Have the same SID on each system. This simplifies the entire failover process, and is fully supported under OPS configurations.

A Kludge:
The problem arises because your clients are coded ( via tnsnames entries ) to hit a particular instance on a particular machine. As far as I know, you can't seamlessly interrogate more than one IP/SID pair from the client in a two-tier client/server environment. Maybe there's a way to jump through some hoops at the Oracle client side to have him detect failover and switch the tnsnames entries.

If your on UNIX as a server, and have access to MKS or other UNIX tools on your Windows client, something like this might work ( if you client is UNIX, no-worries):

#
# crude little script to fix this client's lack of connectivity after a failover event

#
#  Assuming your host names on each of your servers are unique, and further
#  assuming that host A is named alpha and host B is named beta, the
#  following will detect failover, and patch it for clients dependant on

alpha

#
#
#
#  This client must be trusted on both servers via .rhosts or other method

HOSTA_NAME=`rsh alpha -n hostname`

# If alpha is down, the above rsh call will return "beta" ( IP takeover has occured )
if [ "$HOSTA_NAME" != "alpha" ];then

    if [ ! -f /temp/alpha_down ];then

        cp /orant/network/admin/alpha_down_tns.txt /orant/network/admin/tnsnames.ora

        echo "\n" > /temp/alpha_down
    else

        echo "Alpha still down: No action"     fi
else

    if [ -f /temp/alpha_down ];then

        rm -f /temp/alpha_down
        cp /orant/network/admin/alpha_up_tns.txt
/orant/network/admin/tnsnames.ora
        echo "Alpha is online: swap back to original connect info"
    else
        echo "Everything normal for server: alpha"

    fi
fi

exit 0
# END SCRIPT
--

Now, you'd have to maintain two tnsnames.ora files on each client, one with proper entries for a normal cluster state, and one for a particular host-down scenario.

This script would run at intervals on a client dependant on server "alpha". A similar script could be written to run on clients dependant on server "beta", or using this as a guideline, you could write a single script to handle all cases and run it everywhere.

You could even run the big script on the server that serves out the tnsnames.ora files in order to make the "swap" client site wide.

This is not the only solution, but provides a method for you to survive a failover should you not be able to change the SID so that they are consistent across your OPS configuration.

Good Luck,

-Kevin

remove the x for an email reply
Dicky wrote in message <01bdac1b$80d59f60$01011fb4_at_steve>...
>Hi everybody, who can tell me the way that a SQLNET client entry
>(tnsnames.ora) can contain more than one IP for a single SID for redundant.
> My OPS system is built on two machines which concurrently sharing files on
>a set of external harddisks. Each machine has its own SID, for instance,
>SID1 and SID2, respectively. And both of them have capable of taking over
>each other's IP when either of one go down. Based on the above design,
>end-users using SQLNET client are divided into two group -- Group A
>connects to the first machine (SID1) and Group B connects to the second
>machine (SID2). Everything goes fine except in the case of IP takeover
>between machines happens. If the first machine go down, the second machine
>takes over the first machine's IP, and then tries to provide same services
>as the first machine. Group A users even can "tnsping" their SQLNET alisa
>for the first machine, but can't connect to the database anyway because the
>SID in the tnsname file doesn't match the SID on the second machine. What
>can i do??
>
>Thanks in advance!
>
>Dicky
>
Received on Wed Feb 10 1999 - 12:46:10 CST