SQL 2012 cluster taking a long time to fail over

We have a 2 server SQL 2012 cluster (Active/Passive).  When we first built this about 2+ years ago, the failover from one node to the other would only take around 20 to 30 seconds worst case.

Now it seems after 2 years of use and a whole bunch of sql updates/patches it's taking upwards of 6 minutes to fail over to the other node and during that time apps are not able to connect to sql at all.

I was wondering if anyone else has experienced something similar and found a solution to speed up the failover back into the 20 second range?  thanks
NIS_RULEAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Deepak ChauhanSQL Server DBACommented:
Which resource is taking to comes online,

Disk ?
SQL service?
NIS_RULEAuthor Commented:
SQL services is taking a long time to come online.  Disks get dismounted from the active and mounted on the passive node (now active) within a matter of a few seconds.  Then it sits there waiting for sql service for the instance to come online and sits there for 6+ minutes.  Nothing in the logs and nothing fails, the service eventually comes up, just takes a long long time.
Brian CroweDatabase AdministratorCommented:
One thing I have seen that causes delays is when the instances are different versions.  I can't remember the exact message but in the logs there were dozens or hundreds of references to scripts being updated during the failover.  Once we got both instances back on the same service pack version it resolved.

Hope this helps

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

NIS_RULEAuthor Commented:
Thanks Brian.  That may be the cause.  Do you know if there is a way to force the scripts to update without failing over the DB so the failover won't take so long?
Vitor MontalvãoMSSQL Senior EngineerCommented:
Check the SQL Server logs especially for the time that databases are taking for rollback and recover. This can mean that databases have a larger number of virtual log files so you should solve that by shrinking the transaction log files and set a constant growth value in chunks of 64MB at minimum.
Brian CroweDatabase AdministratorCommented:
The update of the scripts is necessary because there are version differences between the two instances.  My assumption is that it needs to do a compatibility check on each script to make sure it is still viable on the "new" version when failing over.  The only fix I know of is to get the two instances in sync at least to the service pack level.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft SQL Server

From novice to tech pro — start learning today.