Groups | Blog | Home
all groups > sql server clustering > january 2005 >

sql server clustering : switch time for sql cluster



Pranay Pandya
1/5/2005 11:06:40 AM
Yes for us it has never been more than i would say 15 seconds.
Detlef Spillner
1/5/2005 12:44:45 PM
Hello,
I need a value for switching time sql-on-node-1 to sql-on-node-2 (best
win2003 cluster, slq 2000). microsoft says 2 - 30 seconds. Is this a real
value?

Thanks

Geoff N. Hiten
1/5/2005 3:31:39 PM
It depends. If you have a very large 32-bit memory system (16GB+) it can
take longer to initialize memory and bring the server up. Worst case for me
with a 32GB server was about 4-6 minutes, but that was after a crash under
full load that took a lot time for the databases to complete their recovery.
A more normal-sized system typically can switch in under 30 seconds.

--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com

I support the Professional Association for SQL Server
www.sqlpass.org

[quoted text, click to view]

Mike Epprecht (SQL MVP)
1/6/2005 12:25:42 AM
Hi

What also depends is how fast the node can dismount it's drives (assuming it
is not a hard server crash). Stuff like Veritas Volume Manager adds
overhead. It can add up to 10 seconds.

A clean, Microsoft only solution, will fail over in around 4-8 seconds up to
the time TempDb is online.

Regards
--------------------------------
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland

IM: mike@epprecht.net

MVP Program: http://www.microsoft.com/mvp

Blog: http://www.msmvps.com/epprecht/

[quoted text, click to view]

Greg D. Moore (Strider)
1/8/2005 5:33:21 AM

[quoted text, click to view]

For use it's 1-2 minutes I think. Most of that time appears to be the
drives going off-line on the one and coming back on-line on the other.

Our one experience in a "for-real" (which ironically was about a week before
I was planning on a "practice" one) by the time my guy on pager duty got
on-line to respond to the failed web-pages, it had fully switched over and
things were back to normal.

It's pretty fast assuming your disks aren't the reason.


[quoted text, click to view]

D. Spillner
1/15/2005 5:09:27 PM
[quoted text, click to view]

Many Thanks for the fast answer.
The problem is solved: after the swap, every application needs a reconnect to the sql server. this is inacceptable for the customer. this meens, the customer will use a cold standby solution.

Greg D. Moore (Strider)
1/16/2005 11:43:23 PM

[quoted text, click to view]
to the sql server. this is inacceptable for the customer. this meens, the
customer will use a cold standby solution.

Umm, not sure how a cold standby solution solves this problem. If anything
it would appear to make it worse.


[quoted text, click to view]

Geoff N. Hiten
1/17/2005 9:20:11 AM
Sounds like a software vendor is making excuses for bad implementation. SQL
client apps should have built-in reconnect logic. Any competent database
programmer who is aware of recommended programming practices should know
this.

--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com

I support the Professional Association for SQL Server
www.sqlpass.org

[quoted text, click to view]
to the sql server. this is inacceptable for the customer. this meens, the
customer will use a cold standby solution.
[quoted text, click to view]

AddThis Social Bookmark Button