11-25-2010 05:23 AM
While i'm waiting on a call back from Symantec Tech could anyone advise me on the following please ? Running EV for Exchange 7.5 SP6
We had the following alert this morning.
Alert: Database could not recover
Source: MSSQLSERVER
Path: EVSQLSERVER
Last modified by: System
Last modified time: 25/11/2010 06:18:17
Alert description: An error occurred during recovery, preventing the database 'EnterpriseVaultAudit' (database ID 11) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.
I logged on to the server and EnterpriseVaultAudit has been listed as Suspect in SQL Manager. I checked the Event log and found the following.
Event ID 824
SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:7157248; actual 0:0). It occurred during a read of page (1:7157248) in database ID 11 at offset 0x00000da6c00000 in file 'E:\SQL Databases\VaultDeva3.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
That was followed by
Event ID 3414
An error occurred during recovery, preventing the database 'EnterpriseVaultAudit' (database ID 11) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
I checked the Event log on the EV Server (seperate to SQL Server) and found the this just before the two events above were logged.
Event ID
The connection 'Provider=SQLOLEDB;Server=SQLSERVER;Database=EnterpriseVaultDirectory;Trusted_Connection=yes' was lost and the system is waiting to reconnect (Thread Id: 8272)
For more information, see Help and Support Center at http://evevent.symantec.com/rosetta/showevent.asp
Any ideas ? I was pretty sure we didnt even have auditing enabled ! Is anything else stored inside that database ?
Thanks for any help..
Solved! Go to Solution.
11-26-2010 12:50 AM
If you re-installed EV due to the crash, and did not enable auditing, the database would probably not have been updated after that. As for the size, it is big, but that is what you get with auditing.
Do you require auditing? If not, I'd leave it off.
As noted, it looks like a SQL issue, and you should also engage Microsoft.
Regards.
11-25-2010 05:33 AM
The Audit database purely stores auditing events, so you won't have lost anything if you weren't actively monitoring EV activities.
The database issue is an SQL server problem and not directly an EV issue so you may need to speak to Microsoft about it if you are unable to resolve the problem via searching online
11-25-2010 05:40 AM
I've just checked the Folder on the SQLSERVER that stores the mdf files. As you can see from the screenshot the VaultDeva3.mdf hasnt been updated since the 25th of August. We lost our EV Server to a hardware fault the day before that and I'm worried now that hasnt been updated since the day we lost it ! Could that be related to the problems above ?
11-25-2010 07:54 AM
You should try checking the properties of the database in the SQL management tools to see if that is the mdf file that is associated with the EnterpriseVaultAudit database. It may well be related, but it could simply be that the lack of update is because the database was marked as suspect on that date
11-25-2010 08:04 AM
Don't be fooled by the Date Modified, that will only change when SQL Server auto grows the database, simply deleting or insert records in and out of the database will not change the modified date.
However i'd be more concerned as to why its almost 100GB
11-26-2010 12:50 AM
If you re-installed EV due to the crash, and did not enable auditing, the database would probably not have been updated after that. As for the size, it is big, but that is what you get with auditing.
Do you require auditing? If not, I'd leave it off.
As noted, it looks like a SQL issue, and you should also engage Microsoft.
Regards.
11-26-2010 02:30 AM
We dont require auditing anymore and defintiley didnt re-enable after the crash so I think we will just detach the database and do away with it.
Thanks for all the help.