Information stores down

[chipirours]

Hi,

My problem is solved (i hope) but it can't figure out what happened.

The tree information stores of one of my storage group went down.
All other storage groups were ok. The Information store service was ok too. Neither restarting it nor rebooting the server did anything.

The tree database were consistent (eseutil /g) their shutdown state was clean (eseutil /mh). I also check the logs files (esuutil /ml) and they were ok too.

I was running out of time, so i moved the *.log and *.chk files to a safe place and try to mount my db again. It worked.

My questions :

It was a long time since the last time i had such a problem, so i'm wondering if removing the logs was a good idea : i'm pretty sure there will be no data loss. am i right ?

Any clue about the cause of this problem ? There is plenty of space either for the logs and for the dbs... I suspect a connectivity loss (the storages are iscsi connected LUNs).

Any idea ?

Thanks in advance (and many apologies for my english).

O.

 

[baddos]

Make sure you check the Event log on the server. There are many reason why an information store could dismount.

 

[58sniper]

Baddos is correct - the event logs should show why they dismounted. If the databases were in a clean shutdown state, then moving older logs shouldn't be a problem. They DO, however, preclude you from doing a point in time recovery.

Was the volume out of space?

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[chipirours]

Thank you for your help.

My boss told me there was nothing in the logs so i save and delete them, before my test.
Trying to understand what happened, i restored and read them.

There was a warning... and all became clear : the maximum number of log generations was about to be attained. The logs needed to be deleted and the stores restarted so that those logs could be numbered from zero again.

 

[58sniper]

Sounds like you're not doing Exchange aware backups. Doing backups with a solution that's Exchange aware will automatically flush the transaction log files daily.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[chipirours]

Hi,

We use an Exchange aware backup software(Backbone's Netvault with ad hoc plugin) but for what i've understood the logs aren't numbered from zero after each daily flush...

O.

 

[baddos]

Contact your backup vendor and make sure your agent is configured properly. If it is not managing the logs properly I would assume it isn't getting a good backup.

 

[chipirours]

Don't need to put the blame on the backup software (or its configuration), imho : as far as i understand this issue is from design in Exchange 2003 :

http://technet.microsoft.com/en-us/library/bb266925(EXCHG.80).aspx

We use those logs for the incremental backups we do each night. Provinding the backup went fine, the logs are deleted at the end of the job. Thats the regular way. (By the way, even if I wanted it, i couldn't afford to keep 1,048,560 x 5 Mo for each storage group ;-)

My mistake : i didn't take care of the warnings that occured before the problem.