SQL Server 2000: Datenbankname (Lädt\Fehlerverdächtig)

[Markus Doll 10]

Guten Morgen zusammen,

 

ich habe ein kleines Problem.

 

Unsere sog. Sharepointadministratorin hat gestern ohne vorher eine Datensicherung o.ä. zu machen (wozu braucht man sowas auch) an der Sharepointdatenbank rumgespielt, mit dem Ergebnis dass sie plötzlich "weg" war, einfach so, ohne das sie sie bewußt gelöscht hätte. Die DB wird im SQL Server Manager nicht mehr angezeigt und auch die Datendateien sind weg. Als SQL Server kommt noch ein SQL Server 2000 zum Einsatz. Jetzt habe ich per DPM versucht eine Datensicherung des SQL Servers von Vorgestern wiederherzustellen, was von DPM Seite auch erfolgreich war. Wenn ich jetzt in den SQL Manager schaue sehe ich zwar die Datenbanken aber sie sind "grau" und dahinter steht "(Lädt\Fehlerverdächtig)". Wenn ich mit dem SQL Management Studio 2005 Express den DB Server Connecte, steht hinter der Datenbank (Wird wiederhergestellt...).

 

Da ich die DB Wiederherstellung gestern Abend bereits angeschmissen habe und das System die ganze Nacht Zeit hatte, die DB "Wiederherzustellen" kann ich mir nicht ganz vorstellen, dass es eine Frage der Zeit ist, bis sich das Thema von selbst erledigt, oder?

 

Lasse ich die Datendateien "separat" wiederherstellen und binde sie dann per Manager wieder ein, kann ich zwar drauf zugreifen, aber sie sind Schreibgeschützt. Dieser Schreibschutz lässt sich auch nicht entfernen.

 

Kann mir dazu jemand eine kleine Hilfestellung geben?!

 

Vielen Dank & Gruß,

Markus Doll

[Cybquest 36]

Ich hab sowas "damals" auch schon mal gehabt. Da hat mir folgender Tip (den ich irgendwo im Internetz gefunden hab) geholfen:

 

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 sysdatabases table.

 

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.

[Markus Doll 10]

Hallo Cybquest,

 

danke für Deinen Hinweis.

 

Ich habe das Problem lösen können und den Fehler gefunden.

 

Das Problem war, das der DPM zwar die Datenbanken wiederhergestellt, leider aber die Sicherheitseinstellungen nicht übernommen hatte und der SQL Serverdienst, der unter einem eigenen Domänenuser läuft somit keinen Zugriff auf die Datendatei hatte. Aus welchen Gründen auch immer war für das "DATA" Verzeichnis die Rechtevererbung ausgeschaltet...

 

Danke für den Tipp und ein schönes Wochenende.

 

Gruß,

Markus Doll