locked
Exchange 2007 Cluster resources wont come online! RRS feed

  • Question

  • H all

    Rapidly working through this calamity this morning, but posting this in case anyine has any immediate ideas...apart from DB restore or ESEUTIL ;-)

    One of our ISCSI luns dropped off unepxectedly this morning, then re-appeared. It contained the Exchange logs. The Exchange logs are now once again available (no new ones though) but all the DB's that were on it are showing as "dismounted". In fact, when you try to mount them they refer to "missing at least 1 transaction file".  It then also pops up and says "The DB's are actually mounted but the correspinding cluster resource is unavailable".  In FAILOVER Cluster Management I can indeed see that the Cluster resources for these DB's is in a "failed" state.  I cant bring them back online.

    Any tips? Sounds like the cluster resource is corrupt. 

    Thursday, March 31, 2011 10:07 AM

Answers

  • Hi folks

    After the Storage Luns disappeared from our SCC Cluster(s), and then came back, the majority of affected Servers recovered nicely. 

    Unfortunately, 1 servers' Log lun (It has 4, only 1 had a major problem) appeared to develop a problem which resulted in the Check file becoming "out of sync".  My colleague and I ran eseutil /mh and detected that the 7 Databases which used that LUN, was waiting for a selection of log files. (The "requires Logs" field in the Eseutil /mh report).

    So, we determined what the log files were (about 20 per server) and performed a manual soft recovery using ESEUtil. I'd done this before years ago so it came back to me eventually. (We had to leave the "required logs" in the normal log location, and MOVED the older logs AND Check file into a sub-folder).

    Anyway, after replaying the logs, then moving them into the subfolder, allowing the Database to be overwritten and then manually mounting it, all was ok.  Did this for the other 6 Databases and we were back in business on this server. It was imperative that we performed a FULL backup at this stage as I'm pretty sure our previous Incr backups would have been invalid should we have needed to perform a subsequent Database restore.

    Thanks for the input though.

    • Marked as answer by Alan.Gim Thursday, April 7, 2011 1:45 AM
    Wednesday, April 6, 2011 1:59 PM

All replies

  • So, when you try to Online the resource, what is the error message you are getting?
    Gulab | MCTS-MCITP Messaging: 2010 | MCTS-MCITP Messaging: 2007 | MCC 2011 | Skype: Gulab.Mallah
    Thursday, March 31, 2011 11:17 AM
  • How’s the issue currently?

    Whether you are using CCR or SCC? If it’s CCR, have you found the missing log files on the passive node?


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Tuesday, April 5, 2011 9:07 AM
  • Check your cluster.log http://blogs.msdn.com/b/clustering/archive/2008/09/24/8962934.aspx
    Tuesday, April 5, 2011 9:11 AM
  • Hi folks

    After the Storage Luns disappeared from our SCC Cluster(s), and then came back, the majority of affected Servers recovered nicely. 

    Unfortunately, 1 servers' Log lun (It has 4, only 1 had a major problem) appeared to develop a problem which resulted in the Check file becoming "out of sync".  My colleague and I ran eseutil /mh and detected that the 7 Databases which used that LUN, was waiting for a selection of log files. (The "requires Logs" field in the Eseutil /mh report).

    So, we determined what the log files were (about 20 per server) and performed a manual soft recovery using ESEUtil. I'd done this before years ago so it came back to me eventually. (We had to leave the "required logs" in the normal log location, and MOVED the older logs AND Check file into a sub-folder).

    Anyway, after replaying the logs, then moving them into the subfolder, allowing the Database to be overwritten and then manually mounting it, all was ok.  Did this for the other 6 Databases and we were back in business on this server. It was imperative that we performed a FULL backup at this stage as I'm pretty sure our previous Incr backups would have been invalid should we have needed to perform a subsequent Database restore.

    Thanks for the input though.

    • Marked as answer by Alan.Gim Thursday, April 7, 2011 1:45 AM
    Wednesday, April 6, 2011 1:59 PM