Verwalten von Datenbanken (SQL Server Compact)

Die interne Struktur einer Datenbank von Microsoft SQL Server Compact 3.5 (SQL Server Compact 3.5) kann im Laufe der Zeit fragmentiert werden, wobei unnötig Speicherplatz belegt wird. Bei einer sehr starken Fragmentierung kann die Leistung darunter leiden. Sie können die Fragmentierung vermeiden, indem Sie die folgenden Features zur Verwaltung der SQL Server Compact 3.5-Datenbank verwenden.

Weitere Informationen zum Verwenden der in diesem Thema beschriebenen Methoden und Eigenschaften finden Sie unter System.Data.SqlServerCe.

Komprimieren

Mithilfe der Compact-Methode (der CompactDatabase-Methode in der systemeigenen Programmierung) können Sie Speicherplatz in der Datenbankdatei freigeben. Die Methode kann auch zum Ändern von Datenbankeinstellungen verwendet werden, z. B. von Kennwörtern und Gebietsschema-ID (LCIDs - Locale IDs).

SQL Server Compact 3.5-Datenbankdateien werden in logische Einheiten mit einer Größe von 4 KB unterteilt, die als Seiten bezeichnet werden. Da eine Datenbank ständig geändert wird, kommt es vor, dass einige Seiten nicht verwendeten Speicherplatz enthalten bzw. einige Seiten nicht verwendet werden. Nicht verwendete Seiten werden eventuell durch den AutoShrink-Mechanismus freigegeben. Weitere Informationen finden Sie im Abschnitt "Automatische Verkleinerung" weiter unten in diesem Thema.

Leerer Speicherplatz in Seiten kann nur über die Compact-Methode freigegeben werden. Bei der Compact-Methode werden Zeilen aus der Quelldatenbank gelesen und in die Zieldatenbank geschrieben, wobei die Zieldatenbank nur ein Mindestmaß an ungenutztem Speicherplatz enthält.

Beim Komprimieren einer Datenbank geschieht Folgendes:

• Eine neue Datenbank und neue Indizes werden erstellt.

• Tabellenseiten werden neu strukturiert, sodass sie sich in benachbarten Datenbankseiten befinden. Die Speicherplatzzuweisung wird durch die verminderte Tabellenfragmentierung innerhalb der Datenbank verbessert.

• Nicht verwendeter Speicherplatz durch Löschungen von Objekten und Datensätzen wird durch Umschreiben aller Datenbankdaten auf neue Datenseiten zurückgewonnen. Werden Objekte oder Datensätze aus der Datenbank gelöscht, wird der zuvor belegte Speicherplatz als verfügbar für Ergänzungen der Datenbank gekennzeichnet. Sofern eine Datenseite nicht vollständig gelöscht wird, bleibt die Seite weiterhin teilweise gefüllt. Die Größe der Datenbank nimmt erst mit dem Löschen der verbleibenden Daten von der Seite oder dem Komprimieren der Datenbank ab. Bei Datenbanken, die häufig durch Hinzufügen, Löschen und Aktualisieren von Objekten und Datensätzen geändert werden, wird häufiges Komprimieren empfohlen.

• Inkrementierende Identitätsspalten werden zurückgesetzt, sodass der nächste zugewiesene Wert um ein Inkrement über dem höchsten Wert der verbleibenden Datensätze liegt. Wenn beispielsweise alle Datensätze in der Datenbank gelöscht wurden, wird beim Komprimieren der Datenbank der Wert der Identitätsspalte des nächsten Datensatzes auf den Ausgangswert zurückgesetzt. Wenn der höchste verbleibende Identitätswert in der Datenbank 50 ist und das Inkrement 5 beträgt, wird beim Komprimieren der Datenbank der Wert des nächsten Datensatzes auf 55 festgelegt. Dies trifft selbst dann zu, wenn Datensätze mit Werten über 50 zuvor hinzugefügt, doch vor dem Komprimieren gelöscht wurden. Angenommen, das Inkrement ist negativ, beispielsweise –5, und der Mindestwert beträgt 15. Durch Komprimieren der Datenbank wird der Wert des nächsten Datensatzes auf 10 festgelegt.

  Hinweis

  Dieses Verhalten tritt auf, wenn Sie die ursprüngliche Version von Visual Studio 2008 verwenden. In Visual Studio 2008 SP1 werden die Identitätsinformationen durch das Komprimieren einer Datenbank nicht geändert.

• Wenn Werte für den Gebietsschemabezeichner oder das Kennwort in der Verbindungszeichenfolge der Zieldatenbank angegeben werden, werden diese Werte beim Erstellen der Zieldatenbank verwendet.

Vor dem Komprimieren einer Datenbank sollten Sie sicherstellen, dass die folgenden Bedingungen erfüllt werden:

• Die Datenbank muss geschlossen werden.
• Die Zieldatenbank darf beim Aufrufen der Compact-Methode nicht vorhanden sein. Es tritt ein Fehler auf, wenn die von DestConnection angegebene Datenbank bzw. eine andere Datei unter diesem Dateinamen bereits vorhanden ist.
• Sowohl für die Originalversion als auch die komprimierte Version der Datenbank muss ausreichend Speicherplatz vorhanden sein, zusätzlich zu möglichen zwischengespeicherten Daten und Daten in der temporären Datenbank.

Automatische Verkleinerung

Zur Komprimierung einer Datenbank erstellen Sie eine neue Datenbank und kopieren dann alle Objekte aus der Quelldatenbank in die neue Datenbank. In der Regel wird die Komprimierung nicht automatisch initiiert. Die automatische Anpassung der Größe einer Datenbankdatei wird als AutoShrink bezeichnet. Bei dieser Technik werden kaum Prozessorzeit und Speicherplatz verwendet, sodass sie sich besonders für tragbare Geräte und mobile Datenbankprodukte eignet. Bei der Autoshrink-Technik werden Seiten innerhalb einer Datei so verschoben, dass alle leeren oder nicht zugewiesenen Seiten zusammenhängend am Ende der Datei angeordnet werden. Die leeren Seiten werden dann abgeschnitten. Abgeschnittene Seiten können anschließend vom Datenbankdateisystem verwendet werden. Durch die Rückgabe der abgeschnittenen Seiten an das Datenbankdateisystem wird der Speicherplatz des Dateisystems vergrößert.

Verwenden Sie die AutoShrink Threshold-Eigenschaft für Verbindungszeichenfolgen, um Autoshrink für verwalteten Code festzulegen. Verwenden Sie für systemeigenen Code die DBPROP_SSCE_AUTO_SHRINK_THRESHOLD-Eigenschaft. Die Eigenschaft gibt den Prozentsatz des freien Speicherplatzes in der Datei vor dem Start von Autoshrink an.

Überprüfen

SQL Server Compact 3.5-Datenbankdateien werden in logische Einheiten mit einer Größe von 4 KB unterteilt, die als Seiten bezeichnet werden. Beim Schreiben einer Seite in die Datenbankdatei berechnet und speichert SQL Server Compact 3.5 eine Prüfsumme für diese Seite. Wird die Seite geändert oder beschädigt, nachdem sie in die Datei geschrieben wurde, besteht keine Übereinstimmung mit der erwarteten Prüfsumme mehr. Wenn SQL Server Compact 3.5 diese Seite liest, wird der systemeigene Fehler SSCE_M_DATABASECORRUPTED (25017) zurückgegeben.

Durch Aufrufen der Verify-Methode der SqlCeEngine-Klasse werden die Prüfsummen aller Seiten in der Datenbankdatei erneut berechnet und überprüft, ob die Prüfsummen mit den erwarteten Werten übereinstimmen. Gibt diese Methode den Wert true zurück, wurde die Datenbankdatei nicht beschädigt. Gibt diese Methode den Wert false zurück, wurde die Datenbankdatei beschädigt. Von der Anwendung sollte dann die Repair-Methode aufgerufen werden.

Reparieren

Im Falle der Beschädigung einer Datenbankdatei können Sie versuchen, diese mithilfe der Repair(System.String,System.Data.SqlServerCe.RepairOption)-Methode des SqlCeEngine-Objekts oder der Repair-Methode vom systemeigenen Programmieren des Engine-Objekts (SQL Server Compact) wiederherzustellen. Bei der Repair-Methode wird die Datenbank gescannt, und die Prüfsummen der Seiten werden berechnet. Wenn eine Prüfsumme nicht mit der Prüfsumme übereinstimmt, die zuvor berechnet wurde, als diese Seite in die Datenbank geschrieben wurde, gilt diese Seite als beschädigt. Wird die Repair-Methode mit dem Wert RepairOption.DeleteCorruptedRows aufgerufen, werden alle beschädigten Seiten verworfen. Dies kann zu einem erheblichen Datenverlust führen, falls die beschädigte Seite Datenbankschemas enthält. Daten, die mithilfe der Repair-Methode wiederhergestellt werden, sollten jedoch keine Schäden aufweisen. Wird die Repair-Methode mit dem Wert RepairOption.RecoverCorruptedRows aufgerufen, wird von der Datenbank der Versuch unternommen, Daten aus beschädigten Seiten zu lesen. Dabei werden möglicherweise mehr Daten wiederhergestellt. Bei der Verwendung dieser Option kann jedoch nicht sichergestellt werden, dass die wiederhergestellten Daten keine Schäden an der Logik aufweisen.

Automatisches Leeren

Wenn Änderungen in einer Datenbank aufgrund von Transaktionen stattfinden, werden diese Änderungen bis zum Commit oder dem Abbruch der Transaktion im Pufferpool aufbewahrt. Bei einem Abbruch einer Transaktion werden die Änderungen verworfen. Bei einem Commit der Transaktion werden die Änderungen für andere Benutzer und Transaktionen sichtbar, werden jedoch möglicherweise nicht sofort in die Datenbank geschrieben. Bei einem unerwarteten Programmende, wie z. B. dem Zurücksetzen des Geräts, werden die Transaktionen verworfen, für die ein Commit ausgeführt wurde, deren Änderungen jedoch nicht in die Datenbank geschrieben wurden.

Transaktionen werden immer in der Reihenfolge in die Datenbank geschrieben, in der das Commit für sie ausgeführt wird. Obwohl möglicherweise einige Transaktionen verloren gehen, ist die Datenbank immer konsistent. Angenommen, in einer Anwendung wurde ein Commit für Transaktion A und anschließend für Transaktion B ausgeführt. Wenn die Anwendung abstürzt oder das Gerät zurückgesetzt wird, befindet sich die Datenbank in einem der drei folgenden Zustände:

• Nicht geändert
• Geändert durch Transaktion A
• Geändert durch Transaktion A und B

Wenn Transaktionen in der Reihenfolge ihres Commits in die Datenbank geschrieben werden, steigt die Leistung, da die Anzahl von Schreibvorgängen der Datenbankdatei sinkt. Die verbesserte Leistung wird vor allem bei einer Vielzahl kleiner Transaktionen offensichtlich, deren Commit über kurze Zeit ausgeführt wird. In diesem Fall werden alle Transaktionen gleichzeitig in die Datenbankdatei geschrieben, anstatt einen separaten Schreibvorgang für jede Transaktion auszulösen.

Ausstehende Änderungen im Pufferpool werden in Zeitintervallen, die von der Flush Interval-Eigenschaft der Verbindungszeichenfolge in ADO.NET (DPROP_SSCE_FLUSH_INTERVAL-Eigenschaft in OLE DB) angegeben werden, in die Datenbank geschrieben oder geleert. Diese Eigenschaften legen die maximale Anzahl von Sekunden fest, bevor Transaktionen, für die ein Commit ausgeführt wird, auf Datenträger geschrieben werden.

Sichern/Wiederherstellen/Löschen

Da es sich bei SQL Server Compact 3.5 um ein dateibasiertes Datenbanksystem handelt, können Sie viele gängige Datenbankaufgaben, wie das Sichern, Wiederherstellen und Löschen einer Datenbank, mithilfe der Dateisystem-APIs ausführen.

• Zum Sichern einer Datenbank schließen Sie alle Verbindungen zur Datenbank, und kopieren Sie dann die SDF-Datei.
• Zum Wiederherstellen einer Datenbank kopieren Sie die SDF-Datei wieder zurück an den regulären Speicherort. Diese Vorgänge können selbst dann ausgeführt werden, wenn die Datenbank zu Replikationszwecken eingerichtet wurde.
• Zum Löschen einer Datenbank löschen Sie die SDF-Datenbankdatei.

Siehe auch

Andere Ressourcen

CompactDatabase-Methode (SQL Server Compact)
Repair-Methode (SQL Server Compact)

Hilfe und Informationen

Informationsquellen (SQL Server Compact 3.5 Service Pack 1)