Server vs. Client Side Failover, and Load Balancing/Sharing * In terms of failover capability, what's the difference between Oracle client side transparent application failover (TAF) and using a network device (e.g. Level 7 switch) to transparently switch client connection to one of the servers? The fundamental difference lies in *where* the decision is made about which server to connect to. Using a network device in front of two application servers makes the device a single point of failure. It's irrelevant whether the device itself has built-in failover mechanism, through network teaming for instance; if that switch is burned in fire, no client can connect. But with Oracle TAF, it's the client, not the server, that decides which Oracle listener to connect to; if the first listener fails to respond, the client connects to a second one. There's no single point of failure. To completely eliminate single point of failure, connection decision has to be made on the client side. [A friend of mine reviewing this note adds that intelligent routing to the multiple servers in a sense also avoids single point of failure. The connection decision is made neither on the client nor server side, but in the middle.] * Do our web browsers and web servers have failover functionality similar to Oracle TAF? Yes, they do. Suppose you want client side connection decision for connecting to a web site supported by multiple web servers, and you want to avoid using a switch on the server side to redirect client requests to one of the web servers. You can simply use DNS to achieve this. On the DNS server, you can have multiple IP addresses for one hostname. Most, if not all, browsers try the IPs sequentially until one is found reachable. You can easily test this: shut down one of the web servers and see the client connecting to the other by viewing server access log. (Also see: http://groups.google.com/group/comp.dcom.modems.cable/msg/29c059463062d01b) * Does this behavior of DNS also offer client side load balancing? It offers load sharing, to use somebody's terminology. On p.259, "DNS and BIND" by P. Albitz and C. Liu 3rd ed., the section "Load Sharing Between Mirrored Servers" says "a modern name server rotates addresses for any domain name that has more than one A record". This means that if the hostname server.company.com has records 10.1.1.1, 10.1.1.2 and 10.1.1.3, then each time a client asks for IP of server.company.com, DNS server gives a different IP as the first one. Here's a test on my PC: C:\>nslookup www.google.com Server: ns3.mindspring.com Address: 207.69.188.187 Non-authoritative answer: Name: www.l.google.com Addresses: 64.233.161.104, 64.233.161.147, 64.233.161.99 Aliases: www.google.com C:\>nslookup www.google.com Server: ns3.mindspring.com Address: 207.69.188.187 Non-authoritative answer: Name: www.l.google.com Addresses: 64.233.161.99, 64.233.161.104, 64.233.161.147 Aliases: www.google.com You see the IPs are rotating in order. Because of this DNS behavior, user Tom may be accessing 64.233.161.104 for www.google.com, and user Scott may be connecting to 64.233.161.99. Due to client side DNS caching (displayed by "ipconfig /displaydns" and cleaned by "ipconfig /flushdns" on Windows), Tom and Scott will continue to use the IPs they got initially until timeout ("Time To Live" set by Google DNS admin). But the HTTP traffic load is distributed on three servers when more than one user is accessing the site. Even one single person can easily check this. Use a browser to connect to www.google.com and run netstat -an | find "64.233.161" in DOS, followed by ipconfig /flushdns. Repeat many times and you'll see your browser is connecting to all the IPs eventually. As "DNS and BIND" explains (p.260), this is called load sharing, not load balancing, because the DNS server blindly rotates the IPs with no knowledge of the actual load on the host the DNS client queries about. This is less intelligent than Oracle listener load balancing (called "connection load balancing" in Oracle documentation), where each listener knows what each of the other database server nodes' actual load[note] is through periodic service update by the database process PMON. Obviously an Oracle listener plays the role of a server for an Oracle client. So client side load balancing is not possible; only load sharing is. Not that we're picky about terminology, but there must be a way to differentiate the two cases in language. * Speaking of Oracle listener load balancing, what is its relationship with load_balance parameter in tnsnames.ora, which is purely on the client side? Load_balance in tnsnames.ora is a misnomer. To be picky about terminology again, this may as well be called load_sharing. It works almost exactly the same way as DNS load sharing does. The only difference is that DNS load sharing sends an IP round-robin to the client, while tnsnames.ora load_balance can be configured with either random connection or sequential trial depending on the load_balance setting. It's a little tricky to do this test. Here's my procedure: (1) Make sure my desktop database ORCL (10g on Windows) and my other database DEV (9i on Linux) have remote_listener not set or set to totally irrelevant values. (Remote_listener is one of the three database parameters that implement listener load balancing. Ref: Net Services Admin Guide) (2) In ORCL, temporarily alter system set service_names = ''; (3) Create a tnsnames.ora entry on my desktop: test = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521)) (ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT = 1521)) (LOAD_BALANCE = yes) (FAILOVER = yes) ) (CONNECT_DATA = (SERVICE_NAME = ) ) ) (4) Repeatedly run the following two lines in sqlplus connect /@test show parameter instance_name The result is that sometimes instance_name is that of ORCL, sometimes DEV. August 2005 _______________________ [note] That mouthful means that by default, Oracle listener balances client connections based on server node load. If you prefer load balancing based on number of client sessions instead, set prefer_least_loaded_node_=off in listener.ora, per Oracle notes 300903.1, 262298.1, 2496772.8.