Connection Retry Algorithm (for TCP/IP Connections)
New: 14 April 2006
For a TCP/IP connection, if the client is running Microsoft Windows XP or later, when both partner names are in the cache, the data access provider adheres to a connection retry algorithm. This is true both for making the initial connection to the session and for reconnecting after losing an established connection. Once a connection has been opened, completing the pre-login and login steps takes additional time.
Note
The time spent in opening a connection can exceed the retry time because of external factors, such as slow DNS lookups, slow domain controller/Kerberos Key Distribution Center (KDC), time spent contacting SQL Server Browser, network congestion, and so forth. Such external factors can prevent a client from connecting to a mirrored database. Also, external factors can cause a connection to take longer to open than the allotted retry time. For information on bypassing DNS and SQL Server Browser for connection attempt to the initial partner, see Making the Initial Connection to a Database Mirroring Session.
If a connection attempt fails or the retry time expires before it succeeds, the data access provider tries the other partner. If a connection is not opened by this point, the provider alternately tries the initial and failover partner names, until a connection is opened or the login period times out. The default login time-out period is 15 seconds. We recommend that the login time-out period be at least 5 seconds. Specifying a smaller time-out period might prevent any of the connection attempts from succeeding.
The retry time is a percentage of the login period. The retry time for a connection attempt is larger in each successive round. In the first round, the retry time for each of the two attempts is 8 percent of the total login period. In each successive round, the retry algorithm increases the maximum retry time by the same amount. Thus, the retry times for the first eight connection attempts is as follows:
8%, 8%, 16%, 16%, 24%, 24%, 32%, 32%
The retry time is calculated using the following formula:
RetryTime**=PreviousRetryTime+(** 0.08 *LoginTimeout)
Where PreviousRetryTime is initially 0.
For example, if using the default login time-out period of 15 seconds, LoginTimeout = 15. In this case, the retry times allotted in the first three rounds are as follows:
| Round | RetryTime calculation | Retry time per attempt |
|---|---|---|
1 |
0 +(0.08 * 15) |
1.2 seconds |
2 |
1.2 +(0.08 * 15) |
2.4 seconds |
3 |
2.4 +(0.08 * 15) |
3.6 seconds |
4 |
3.6 +(0.08 * 15) |
4.8 seconds |
The following figure illustrates these retry times for successive connection attempts, each of which times out.
.gif "Maximum retry delays for 15 second login timeout")
For the default login time-out period, the maximum time allotted to the first three rounds of connection attempts is 14.4 seconds. If every attempt were to use all of its allotted time, only 0.6 seconds of time would remain before the login period times out. In that case, the fourth round would be curtailed, allowing only a final quick attempt to connect using the initial partner name. However, a connection attempt may fail in less than its allotted retry time, particularly in later rounds. For example, receiving a network error can cause an attempt to end before the retry time expires. If earlier attempts fail due to a network error, additional time would be available for the fourth round and, perhaps, additional rounds.
Another cause of a failed attempt is an inactive server instance, as occurs when a server instance is engaged in failing over its database. In this case, a retry delay is imposed to prevent clients from overloading the partners with a rapid succession of connection attempts.
Note
When both partner names are available, if the login time-out period is infinite, the client attempts to reconnect to the servers indefinitely, alternating between the initial partner name and the failover partner name.
Retry Delays During Failover
If a client attempts to connect to a partner that is failing over, the partner immediately responds that it is inactive. In this case, each round of connection attempts are much briefer than the allotted retry time. This means that many rounds of connection attempts could happen before the login period times out. To avoid overloading the partners with a rapid series of connection attempts during a failover, the data access provider adds a brief retry delay after each retry cycle. The length of a given retry delay is determined by the retry-delay algorithm. After the first round, the delay is 100 milliseconds. After each of the next three rounds, the retry delay doubles—to 200, 400, and 800. For all later rounds, the retry delay is 1 second until the connection attempt succeeds or times out.
Note
If the server instance is stopped, then the connection request fails immediately.
The following figure illustrates how the retry delay affects connection attempts during a manual failover, in which the partners switch their roles. The login time-out period is 15 seconds.
.gif "Retry-delay algorithm")
See Also
Concepts
Overview of Database Mirroring
Possible Failures During Database Mirroring
Making the Initial Connection to a Database Mirroring Session
Reconnecting to a Database Mirroring Session
Other Resources
Connecting to the SQL Server Database Engine