Cluster Installation SQL

Question

HI SME
I have installed the SQL 2005 failover cluster and  SAP cluster installation both are working fine.
But whenever i am moving the SQL group from node 1 to node 2 and vice versa the Databse in the studio show recovery mode.
and application is not able to connect unless the the recovery is completed.
Note : ALL the groups in the cluster are moving perfectly without any issue . Only that DB
Database :  share Drive (SAN)
Regards
Haroon

Answer 1

Dear Haroon.
This could be due to an issue with the cluster and its resources to come online, however I am more prone to think that this is a purely SQL Server issue. So, in order to discern it, I recommend you to perform a very simple test:
Take your SQL Server offline and bring it back online in the same node; how long does it take to recover the database? It should take the same amount of time as a failover; if it takes less time to recover on the same node, then you probably have a cluster issue.
Otherwise, I think that this is just the normal behaviour of SQL Server, but there is something that you should learn about the transaction log in order to really take advantage of its strong points, and do not suffer the possible drawbacks:
Writes to the SQL database (i.e. inserts, updates and deletes) are written first to the transaction log. Once a transaction (whether it is an explicit transaction starting with a BEGIN TRAN or an implicit transaction of a single statement) is written in the log, the user is told that the write was complete, even though it is not yet in the database. The lazy writer and checkpoint processes "follow along behind" and flush those writes (stored as "dirty pages" in memory) to the database.
A log backup writes everything (since the last log backup) to a backup file. It does not affect in any way the writing of transactions to the database.
The key here is that a transaction must be marked as "complete" in some way. This can either be an explicit COMMIT or ROLLBACK statement or something implicit like a GO statement or your connection's IMPLICIT_TRANSACTIONS setting.
If a transaction is not completed in some way and/or has not been written to the database when the service/database is stopped, the SQL Server has to recover the database when the service restarts. This entails reading through the log file, rolling back transactions that have not been committed ("unwriting" them from the database) or rolling forward transactions that have been committed in the log but had not been written into the database.
Far and away the most common reason for long recovery times is uncommitted transactions that have to be rolled back.
A good clue that this is the cause is the usage of the log file after a log backup is taken. If there is still a lot of used space in the log file after taking a log backup it means there is at least one open transaction that started a fair while ago. Common causes for this are: having your users' IMPLICIT_TRANSACTIONS set ON instead of the default OFF (especially if they leave their connections open), applications that allow transactions to be held open (again, especially when a user walks away from their machine in the middle of a session), large data loads, index rebuilds, etc. The first two scenarios need to be investigated and addressed if possible.
And now, let me ask you: How often do you backup your transaction logs? Maybe not very often, and so you have a lot of transactions that need to be rolled back/forward during the recovery of your database. To be more precise, if you are not backing up the transaction log on a regular basis, SQL Server will need to process all VLF's in the transaction log. So, it is generally recommended to setup a job that backs up the transaction log at least every hour (possibly every 15 minutes). With that done, your recovery time should be much faster. Otherwise, monitor the size of the transaction log backups and check if there are any open transactions as explained in SAP note 421644.
Cheers!!
-Jesú