Verwaltung des Datenbankspeicherplatzes

Studiennotizen zur Datenbankspeicherplatzverwaltung

Die Grundeinheit der Datenspeicherung in SQL Server ist Seite. Festplatten-E/A-Vorgänge werden auf Seitenebene ausgeführt.

Die kleinste Einheit, die SQL Server Daten lesen oder schreiben kann, ist die Seite in Einheiten von 8 KB.

Der Anfang jeder Seite ist ein 96-B-Header, der zum Speichern von Systeminformationen über die Seite verwendet wird. Enthält die Seitennummer, den Seitentyp, den verfügbaren Platz auf der Seite und die Zuordnungseinheits-ID des Objekts, dem die Seite gehört

. Auf unterschiedlichen Seitentypen werden unterschiedliche Datentypen gespeichert.

Auf einer normalen Datenseite werden die Datenzeilen der Reihe nach direkt nach dem Seitenkopf platziert. Am Ende der Seite befindet sich eine Zeilenoffsettabelle, die einen Eintrag für jede Zeile auf der Seite enthält.

Jeder Eintrag zeichnet den Abstand zwischen dem ersten Byte der entsprechenden Zeile und dem oberen Rand der Seite auf. Die Einträge in der Zeilenoffsettabelle sind in umgekehrter Reihenfolge wie die Zeilen auf der Seite.

----Fügen Sie hier die Notiz von Song Dashen ein------- --

Mit Ausnahme des vom Seitenkopf eingenommenen Platzes und des von der Zeilenoffsetmatrix eingenommenen Platzes wird der verbleibende Platz in der Mitte für Datenzeilen verwendet. Es gibt auch andere Informationen in einer Datenzeile, die zur Darstellung der Datenzeile verwendet werden. Die spezifische Struktur ist wie folgt: Statusbit A 1 Byte, Statusbit B 1 Byte, Datentyplänge mit fester Länge, 2-Byte, Datentyp mit fester Länge, spezifische Zahl Anzahl der Datenbyte-Spalten fester Länge 2 Bytes NULL-Bitmap-Spaltennummer/8 Bytes Anzahl der Spalten variabler Länge Offsetmatrix von 2-Byte-Spalten variabler Länge Anzahl der Spalten variabler Länge * 2 Bytes Spalten variabler Länge Die spezifischen Daten variabler Länge Bytes der Daten belegen mindestens 1+1+2+2+1=7

-------- --- --------------------------------------------

Um die angegebene Seite auszugeben, können Sie Folgendes verwenden: DBCC PAGE(, , , )

Db_id kann aus dem Ergebnis von sp_helpdb abgerufen werden.

File_id kann aus den Ergebnissen von sp_helpfile abgerufen werden.

Format_id ist das von Ihnen angegebene Ausgabeformat.

Bevor Sie DBCC PAGE ausführen, müssen Sie außerdem das Trace-Flag 3604 aktivieren

In SQL Server können Zeilen nicht seitenübergreifend sein und zur selben Zeile gehören Alle Felddaten müssen auf derselben Seite platziert werden. Die maximale Datengröße einer Seite beträgt 8.060 B (8 KB).

Daher darf die maximale Gesamtlänge einer Zeile, die aus Feldern des allgemeinen Datentyps besteht, 8 KB nicht überschreiten.

Diese Einschränkung gilt jedoch nicht für Daten in Feldern des Datentyps „Text/Bild“.

Die Daten dieser Feldtypen werden separat auf der LOB-Seite (LargeObject) gespeichert.

In Versionen ab SQL Server 2005 werden Datentypen wie varchar(max), nvarchar(max) und varbinary(max) bereitgestellt.

Wenn die Gesamtlänge der Zeilen, die Felder dieser Art von Daten enthalten, 8 KB nicht überschreitet, werden die Daten weiterhin zusammen auf der normalen Datenseite gespeichert.

Wenn die Gesamtlänge 8 KB überschreitet, trennt SQL Server die Daten dieser Felder und speichert sie separat auf einer Seite namens Row-Overflow.

Extent ist eine Sammlung von 8 physisch zusammenhängenden Seiten, die zur effektiven Seitenverwaltung verwendet werden. Alle Seiten werden in Extents gespeichert.

• Ein einheitlicher Bereich, der einem einzelnen Objekt gehört. Alle 8 Seiten in der Zone können nur von einem Objekt verwendet werden.

• Gemischter Bereich, gemeinsam genutzt von bis zu 8 Objekten. Jede der 8 Seiten in der Zone kann einem anderen Objekt gehören. Eine Seite kann aber immer nur zu einem Objekt gehören.

Seiten werden normalerweise einer neuen Tabelle oder einem neuen Index aus dem gemischten Umfang zugewiesen. Wenn die Tabelle oder der Index auf 8 Seiten anwächst, wird für nachfolgende Zuweisungen der einheitliche Umfang verwendet.

DBCC SHOWFILESTATS

Dieser Befehl kann die Bereichszuordnungsinformationen direkt von Systemzuordnungsseiten wie GAM und SGAM lesen und direkt berechnen, wie viele Dateien vorhanden sind in der Datenbank wurde zugewiesen.

sp_spaceused (+ updateusage wird korrekt sein)

DBCC SHOWCONTIG (mit Vorsicht verwenden, sys.dm_db_index_physical_stats kann nach SQL Server 2005 verwendet werden)

sys.dm_db_partition_stats

Sie können die Größe des Datenbankspeicherplatzes auf Seitenebene analysieren und überprüfen.

Protokolldateien sind nicht nach Seite/Abschnitt organisiert.

Die Datenbank-Engine unterteilt jede physische Protokolldatei intern in mehrere virtuelle Protokolleinheiten. Die virtuelle Protokolleinheit hat keine feste Größe,

und die Anzahl der in einer physischen Protokolldatei enthaltenen virtuellen Protokolleinheiten ist nicht festgelegt.

Jedes Mal, wenn die Protokolldatei automatisch wächst, wird mindestens eine virtuelle Protokolleinheit hinzugefügt.

Wenn eine Protokolldatei mehrere kleine automatische Zuwächse erfahren hat, ist die Anzahl der darin enthaltenen virtuellen Protokolleinheiten viel größer als die einer normalen Protokolldatei.

Diese Situation beeinträchtigt die Effizienz der Protokolldateiverwaltung und führt sogar dazu, dass die Datenbank viel Zeit in Anspruch nimmt.

Das Transaktionsprotokoll ist eine Wrapper-Datei. Wenn eine Datenbank erstellt wird, beginnen die logischen Protokolldateien am Anfang der physischen Protokolldateien.

Neue Protokolldatensätze werden am Ende des logischen Protokolls hinzugefügt und dann zum Ende des physischen Protokolls hin erweitert.

Wenn das Ende des logischen Protokolls das Ende der physischen Protokolldatei erreicht, springt der neue Protokolldatensatz an den Anfang der physischen Protokolldatei und schreibt rückwärts weiter.

DBCC SQLPERF (LOGSPACE) kann die Verwendung von Protokolldateien überprüfen.

Die Tempdb-Systemdatenbank ist eine globale Ressource, die allen Benutzern zur Verfügung steht, die mit einer Instanz von SQL Server verbunden sind. In SQL Server2005 wird sie zum Speichern der folgenden Elemente verwendet:

Benutzerobjekt

• Benutzerdefinierte Tabellen und Indizes.

• Systemtabellen und Indizes.

• Globale temporäre Tabellen und Indizes.

• Lokale temporäre Tabellen und Indizes.

• Tabellenvariable.

• Tabelle, die in Tabellenwertfunktionen zurückgegeben wird.

Interne Objekte

• Arbeitstisch für Cursor- oder Spool-Operationen und temporäre Speicherung großer Objekte (LOB).

• Arbeitsdatei für Hash-Join- oder Hash-Aggregationsvorgänge.

• Zwischensortierergebnisse für Vorgänge wie das Erstellen oder Neuerstellen eines Index (wenn SORT_IN_TEMPDB angegeben ist),

oder Zwischensortierergebnisse für bestimmte GROUP BY-, ORDER BY- oder UNION-Abfragen.

Jedes interne Objekt verwendet mindestens 9 Seiten: eine IAM-Seite, eine 8-seitige Erweiterung.

Versionsspeicher

• Wird durch datenverändernde Transaktionen in einer Datenbank mithilfe der Snapshot-Isolationsstufe oder der Zeilenversion der festgeschriebenen Isolationsstufe (Zeilenversionierung basiert) generiert.

• Zeilenversionen, die durch Datenänderungstransaktionen für Funktionen wie Online-Indexoperationen, mehrere aktive Ergebnismengen (MARS) und AFTER-Trigger generiert werden.

Ein Hauptmerkmal der Tempdb-Speicherplatznutzung besteht darin, dass nur einige Objekte vorhanden sind, z. B. vom Benutzer erstellte temporäre Tabellen, Tabellenvariablen usw.

Sie kann sys.allocation_units und Verwaltungsansichten wie sys.partitions verwenden.

Die Speicherplatznutzung von tempdb kann nicht mit sp_spaceused verfolgt werden. (Ungenau)

sys.dm_db_file_space_usage Diese Ansicht kann die Speichernutzungsverteilung von tempdb in mehreren Hauptkategorien widerspiegeln.

Handelt es sich um ein Benutzerobjekt (user_object_reserved_page_count), ein Systemobjekt (internal_object_reserved_page_count)

oder einen Versionsspeicher (version_store_reserved_page_count).

Das Obige ist der Inhalt der Datenbankspeicherplatzverwaltung. Weitere verwandte Artikel finden Sie auf der chinesischen PHP-Website (www.php.cn)!