一些关于vip的文档：

1.
each node will have not only its own statically assigned IP address, but also a virtual IP address that is assigned to the node. The listener on each node will actually be listening on the virtual IP (VIP), and client connections are meant to come in on the VIP.

2.

Why a Virtual IP?
So, why must we use a virtual IP address in a RAC environment in Oracle Database 10g? We touched on the reasoning briefly in earlier chapters, but we will go into more detail here. The simple answer to this question is 'TCP timeouts.' So, now that we have answered this question, we can move on, right? No? Okay, let's discuss this a bit more.

TCP Timeouts
TCP timeouts, believe it or not, play a huge piece in the perceived availability of applications. When a node in a RAC environment goes down, or in any high-availability environment with multiple addresses to attempt, there is no way for the client to know this. If a client is connecting using a TNS alias, or a service that allows connection to multiple nodes, the client may unknowingly try its first connection attempt to the node that is down. This in and of itself is not a problem, as there are supposed to be multiple addresses in the list. As such, when the client fails to get a response from the first address in the list, the next address will be tried, until the connection succeeds. The problem lies with the time that it takes to go to the next address in the list. How long does the client wait to determine that the host it is trying to reach is not accessible? The time can range anywhere from a few seconds to a few minutes, and in some environments this is simply unacceptable. If a node goes down for several hours, days, or weeks, the database may still be humming along just fine, with x number of nodes still accessing the database. However, some clients may always be trapped into making the initial connection attempt to the down node, and therefore be stuck in front of a (seemingly) interminable hourglass while the connection is timing out, prior to being rerouted to the next address in the list.

Reigning in TCP Timeouts at the OS Unfortunately, this time is something that is generally outside of the control of Oracle. In addition, it varies from client to client, and operating system to operating system. It is controlled by the operating system timeout values on the client side, so making modifications to all clients can be cumbersome since there may be many clients and many variations to configuration changes that need to be made. Further, changing the timeout values may also result in adverse consequences on other applications that the clients are running, if other applications rely on a higher TCP timeout value for whatever reason.

To make matters worse, the behavior may not be consistent. If client-side load balancing is enabled, it is quite possible that some connections will succeed immediately on their first attempt, because they just happened to randomly connect to a node that is available. At other times, however, the connection time increases, because the client randomly and unwittingly picks the down node for its first connection attempt. The result of this is confusion and frustration at the client side, even though from the database perspective, everything is functioning as it should.

Giving the HA DBA Control Over TCP Timeouts Enter the virtual IP address, or VIP. By using a virtual IP address, Oracle eliminates the problem with TCP timeouts on the initial connection, without the need to make any changes to a single client machine. This is done by enforcing client connections to first come in on the virtual IP address for all connections. When all nodes are functioning properly, each VIP is running on its assigned node, and connections are directed to the appropriate listener and service. When the unthinkable happens, and a node fails (gasp!), CRS will kick in, and the VIP for that node will actually be brought online on one of the remaining nodes of the cluster, where it can respond to a ping and also to connection attempts. It is important to note that this VIP will not now be accepting connections to the database. However, since the IP address is available, it will be able to respond to a connection attempt immediately. The response given to the client would normally be in the form of an ORA-12541, advising that there is no listener available. This is because the node where the VIP now resides has its own listener, but it is listening on its own VIP-not the VIP of any other nodes. The client, receiving the message back that there is no listener, will then be able to immediately retry, using the next IP in the ADDRESS_LIST, rather than waiting up to two minutes for the timeout we would normally expect. Thus, a connect-time failover has still occurred, but the connection attempt succeeds within a matter of a few seconds. The actual ORA error is masked, so that the client never sees it.

3.

3k to shimu:

document.body.clientWidth-230) this.width=document.body.clientWidth-230 }" border="0" />