cancel
Showing results for 
Search instead for 
Did you mean: 

EV 8.0SP2 - Directory Database issue

GauravAditya
Level 5
Hello All,

I have a serious issue here that I seek your help in.

Scenario: -
EV 8.0SP2 on Windows 2008 x64 SP1 (Clustered on 2 physical servers).
SQL 2005 on Windows 2003 on Hyper-V and Clustered

Unable to connect to VAC as it returns an error that the Directory Service or Database is unavailable.
Check the Services, All Running
Checked the SQL Databases: - EV Directory and EV Monitoring Database in SUSPECT Mode. This was caused by an automated failover causing the databases be in this mode.

Issue: -
We do not have any backup of the SQL databases.
There are users with Archives and are not able to access their archives (obvious)

Is there any way we can come out of this situation? You immediate support will be highly appreciated.
1 ACCEPTED SOLUTION

Accepted Solutions

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified
Hello GauravAditya

Sounds like a supoprt call to me.
Not having a backup of SQL is not very smart, but you probably know yourself also ;)

I am not a DBA, but could you not repair the database or something?
I am sure you can repair the databases.

The below link has a command that MIGHT help:

http://blogs.microsoft.co.il/blogs/dbaces/archive/2008/12/28/how-to-repair-sql-server-2005-suspect-database.aspx

It is not mine, nor do I take any responsability for this.

I advise you to call Symantec support, hopefully they can help.
Good luck.
Regards. Gertjan

View solution in original post

3 REPLIES 3

GertjanA
Moderator
Moderator
Partner    VIP    Accredited Certified
Hello GauravAditya

Sounds like a supoprt call to me.
Not having a backup of SQL is not very smart, but you probably know yourself also ;)

I am not a DBA, but could you not repair the database or something?
I am sure you can repair the databases.

The below link has a command that MIGHT help:

http://blogs.microsoft.co.il/blogs/dbaces/archive/2008/12/28/how-to-repair-sql-server-2005-suspect-database.aspx

It is not mine, nor do I take any responsability for this.

I advise you to call Symantec support, hopefully they can help.
Good luck.
Regards. Gertjan

Liam_Finn1
Level 6
Employee Accredited Certified
Have a read of this

At times a database appears to be marked as "suspect" in the Enterprise Manager. SQL Server marks a database as suspect with it can't access the database. What happens at a low level is that SQL Server sets one of the bits in the status field in the sysdatabasestable.

In general, this problem has no trivial solution. A simpler case occurs when the file that hosts the database is renamed from the command prompt or Windows Explorer. In this case, you just have to restore the original file name and then manually restore the bit in the status field with this command:

update sysdatabases
set status = status & ~256
where name = 'MySuspectDatabase'
Keep in mind that the command above can be successful only after enabling writing to system tables.

When the error isn't so trivial, you should check the error log to determine whether a restore operation is possible. However, when the data in the transaction log has been damaged, the restore procedure can hardly succeed. In this case the best solution is to restore the database from a recent backup. When this isn't possible, you should bring SQL Server in the so-called emergency mode. This state is entered by setting a bit in the status field in the sysdatabases table. The docs in the Books On Line report that you must OR the field contents with the value 32768, but the correct value is -32768. Thus, this is the command you need:

update sysdatabases
set status = status | -32768
where name = 'MioSuspectDatabase'
After this command you must stop and restart the SQL Server service. The Emergency Mode prevents SQL Server from restoring the suspect database, which now appears to be available. If the database is now accessible, you should be able to read data using standard techniques, such as a bulkcopy command or SELECT INTO commands.


You need to call support on this.

And Yes it was silly not to have a backup of SQL but if your transation los are in good order maybe this can be rescued

Below is the link to the actual site where this was posted
http://www.devx.com/vb2themax/Tip/18624


GauravAditya
Level 5

The Steps provided in this link did resolve the issue: -
http://blogs.microsoft.co.il/blogs/dbaces/archive/...

I was now able to connect to the Directory database and once the databases were up, we took a full backup of the databases.

Thanks for all the help extended...