REORGANIZE TABLE [ Eigentümer.]Tabellenname
[ { PRIMARY KEY
| FOREIGN KEY Fremdschlüsselname
| INDEX Indexname } ]

Reorganisieren Sie die Tabelle gemäß den nachstehend angegebenen Werten:

Die Tabellenfragmentierung kann die Performance beeinträchtigen. Mit dieser Anweisung können Sie die Zeilen in einer Tabelle defragmentieren oder Indizes komprimieren, die aufgrund von DELETE-Anweisungen klein geworden sind. Sie kann auch die Gesamtanzahl der Seiten reduzieren, die benutzt werden, um die Tabelle und ihre Indizes zu speichern, sowie eventuell die Ebenen in einem Indexbaum verringern. Sie führt allerdings nicht zu einer Verringerung der Gesamtgröße der Datenbankdatei. Es wird empfohlen, dass Sie die Systemprozeduren sa_table_fragmentation und sa_index_density verwenden, um Tabellen auszuwählen, für die sich eine Verarbeitung lohnt.

Wenn weder ein Index noch ein Schlüssel angegeben sind, werden Zeilen in der Tabelle beim Neuorganisieren defragmentiert, indem Gruppen von Zeilen gelöscht und wieder eingefügt werden. Für jede Gruppe wird eine Exklusivsperre erworben. Nachdem die Gruppe verarbeitet wurde, wird die Sperre freigegeben und erneut erworben (ggf. nach Wartezeit), sodass andere Verbindungen Gelegenheit erhalten, auf die Tabelle zuzugreifen. Checkpoints werden unterbrochen, während eine Gruppe verarbeitet wird. Wenn eine Gruppe fertig gestellt ist, kann ein Checkpoint auftreten. Die Zeilen werden in der Primärschlüssel-Reihenfolge abgearbeitet. Wenn die Tabelle keinen Primärschlüssel hat, tritt ein Fehler auf. Die verarbeiteten Zeilen werden am Ende der Tabelle wieder eingefügt, sodass die Zeilen am Ende des Verfahrens in Clustern nach Primärschlüssel vorliegen. Beachten Sie, dass der erforderliche Aufwand der gleiche ist, unabhängig vom ursprünglichen Grad der Zeilenfragmentierung.

Wenn ein Index oder ein Schlüssel angegeben wird, verarbeitet das System den angegebenen Index. Für die Dauer des Vorgangs gilt eine Exklusivsperre für die Tabelle, und Checkpoints werden unterbrochen. Versuche, über andere Verbindungen auf die Tabelle zuzugreifen, werden blockiert oder schlagen fehl, je nach Einstellung der Blockierungsoption. Durch vorbereitendes Lesen der Indexseiten vor dem Setzen der exklusiven Sperre wird die Dauer der Sperre minimiert.

Da die Neuorganisation viele Seiten ändern kann, wird das Checkpoint-Log unter Umständen sehr groß. Dies kann zu einem Anwachsen der Datenbankdatei führen. Dieses Anwachsen ist allerdings nur temporär, da das Checkpoint-Log beim Herunterfahren gelöscht und die Datei dabei gekürzt wird.

Diese Anweisung wird im Transaktionslog nicht protokolliert.

Diese Anweisung kann nicht ausgeführt werden, wenn mit der WITH HOLD-Klausel geöffnete Cursor vorhanden sind, die entweder Anweisungs- oder Transaktions-Snapshots verwenden. Siehe Snapshot-Isolation.

Während des Ausführens dieser Anweisung können Sie Meldungen zum Verarbeitungsfortschritt anfordern. Siehe progress_messages-Option.

Sie können auch mithilfe der Verbindungseigenschaft "Progress" feststellen, wie viel von der Anweisung ausgeführt wurde. Siehe Progress-Verbindungseigenschaft.

Vor dem Start der Neuorganisation wird versucht, mit einem Checkpoint die Anzahl der freien Seiten zu maximieren. Außerdem wird beim Ausführen der REORGANIZE TABLE-Anweisung eine implizierte Festschreibung bei ca. jeder 100. Zeile durchgeführt. Daher finden bei der Neuorganisation einer großen Tabelle vielfache Festschreibungen statt.

Die folgende Anweisung organisiert den Primärschlüsselindex für die Tabelle 'Employees' neu:

REORGANIZE TABLE Employees
PRIMARY KEY;

Die folgende Anweisung organisiert die Tabellenseiten der Tabelle 'Employees' neu:

REORGANIZE TABLE Employees;

Die folgende Anweisung organisiert den Index 'IX_product_name' der Tabelle 'Products' neu:

REORGANIZE TABLE Products 
   INDEX IX_product_name;

Die folgende Anweisung organisiert den Fremdschlüssel 'FK_DepartmentID_DepartmentID' für die Tabelle 'Employees' neu:

REORGANIZE TABLE Employees 
   FOREIGN KEY FK_DepartmentID_DepartmentID;