Nach einem Server-Neustart beglückte mich heute der SQL Server mit einer Meldung, dass eine Datenbank “suspect” sei. “Was ist das denn???”, fragte ich mich.
Nach ein wenig Recherche fand ich heraus, wann eine Datenbank als suspect markiert wird:

If one or more database files are not available.
If the entire database is not available.
If one or more database files are corrupted.
If a database resource is being held by the operating system.

Quelle: SQL Server Books Online

Da ich weder die Datenbank umbenannt noch Dateien gelöscht hatte, konnte der Status nur bedeuten, dass die Datenbank korrupt ist.
Zur Lösung des Problems kamen folgende Kommandos zum Einsatz:

1) Setzen der Datenbank in exklusiven Modus für Admin-Tätigkeit

ALTER DATABASE myDatabase SET Single_User

2) Setzen der Datenbank in Wartungsmodus

ALTER DATABAS myDatabase SET Emergency

3) Überprüfen der Datenbank Teil 1

DBCC CheckDB ('myDatabase ')

Hier erhält man eine Meldung, mit welchem Modus die Datenbank repariert werden kann

4) Überprüfen der Datenbank Teil 2

DBCC CheckDB ('myDatabase', REPAIR_ALLOW_DATA_LOSS)

5) Zurücksetzen der Datenbank in shared-Modus

ALTER DATABASE myDatabase SET Multi_User

Das hat das Problem bei mit gelöst. Zum Glück gingen trotz REPAIR_ALLOW_DATA_LOSS keine Daten verloren.

If you missed the Storage node in the Object Explorer of your SSMS installation to manage your SQL Express fulltext catalogs, here is the solution!
Find below my new addin for both SSMS 2005 and SSMS 2008.

Once installed the addin, you’ll find a new context menu entry when you select a database:

A click on the menu entry opens the management dialog:

Find the setup and sourcecode on my CodePlex project http://www.codeplex.com/FulltextManager.

Nachdem die Merge-Replikation bei einem unserer Kunden monatelang problemlos lief, ist sie plötzlich ausgefallen. Ein Blick ins Merge-Protokoll zeigte, dass sie nach dem Initialisieren im Status “uploading data changes to the Publisher” stehen geblieben ist. Einige Minuten später folgte dann ein Timeout. Als dieses Problem zum ersten Mal aufgetreten ist, half nur eine komplette Neuinitialisierung des Snapshots mit anschließenden Rebuild. Doch leider ist nach einigen Wochen dasselbe Problem wieder aufgetreten.

Nach längerer Recherche im Internet fand ich einen interessanten Thread über dieses Thema. Anscheinend ist wohl eine SP der Replikation fehlerhaft, was unter bestimmten Umständen zu einer Endlosschleife führt. Dieser Fehler bis zur SQL Server Version 9.0.3282 (Kumulatives Update-Paket 9) aber leider noch nicht behoben.

Ein Workaround besteht momentan im im Setzen des “generation_leveling_threshold” auf den Wert 0. Hierfür muss auf dem Subscriber folgendes Statement ausgeführt werden:

UPDATE sysmergepublications SET [generation_leveling_threshold] = 0

Laut Dokumentation soll der Wert “generation_leveling_threshold” eigentlich über die SP sp_changemergepublication gesetzt werden. Doch das hat in unserem Fall leider keinen Erfolg gebracht. Das korrekte Statement für sp_changemergepublication würde lauten:

exec sp_changemergepublication @publication = 'My Publication', @property = 'generation_leveling_threshold', @value = '0'

Dieser Workaround hat in unserem Fall problemlos funktioniert und seid einigen Wochen läuft die Replikation wieder fehlerfrei. Ein großer Vorteil bei diesem Vorgehen ist, dass der Snapshot nicht neu erstellt werden muss und auch der Subscriber nicht erneut initialisiert werden muss. Nachdem man den Befehle ausgeführt hat läuft beim nächsten Abgleich alles wieder problemlos.