

 Amazon Redshift unterstützt UDFs ab Patch 198 nicht mehr die Erstellung von neuem Python. Das bestehende Python UDFs wird bis zum 30. Juni 2026 weiterhin funktionieren. Weitere Informationen finden Sie im [Blog-Posting](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

# Bereinigen von Tabellen
<a name="t_Reclaiming_storage_space202"></a>

Amazon Redshift kann im Hintergrund automatisch eine VACUUM DELETE-Operation für Tabellen sortieren und ausführen. Um Tabellen nach einem Laden oder einer Reihe von inkrementellen Updates zu bereinigen, können Sie auch den [VACUUM](r_VACUUM_command.md)-Befehl ausführen (entweder gegen die gesamte Datenbank oder gegen einzelne Tabellen).

**Anmerkung**  
Nur Benutzer mit den erforderlichen Tabellenberechtigungen können eine Tabelle effektiv bereinigen. Wenn VACUUM ohne die notwendigen Tabellenberechtigungen ausgeführt, wird die Operation zwar erfolgreich abgeschlossen, hat jedoch keine Wirkung. Eine Liste der gültigen Tabellenberechtigungen zum effektiven Ausführen von VACUUM finden Sie unter [VACUUM](r_VACUUM_command.md).  
Aus diesem Grund empfehlen wir, das Vacuuming einzelner Tabellen bei Bedarf durchzuführen. Wir empfehlen ebenfalls diesen Ansatz, da das Vacuuming der gesamten Datenbank ein teurer Vorgang sein kann.

## Automatische Tabellensortierung
<a name="automatic-table-sort"></a>

Amazon Redshift sortiert automatisch die Daten im Hintergrund, um die Tabellendaten in der Reihenfolge ihres Sortierschlüssels zu sortieren. Amazon Redshift verfolgt Ihre Scan-Abfragen, um festzustellen, welche Abschnitte der Tabelle von der Sortierung profitieren. Amazon Redshift verfolgt auch Scananfragen von Clustern zur Parallelitätsskalierung. Bei Multi-Cluster-Architekturen, die Amazon Redshift Data Sharing verwenden, verfolgt Amazon Redshift auch Scananfragen, die von Verbrauchern clusters/workgroups in Ihrem Datennetz stammen, auch clusters/workgroups über verschiedene Regionen hinweg. Die Scan-Statistiken aus dem Hauptcluster, den Clustern zur Parallelitätsskalierung und den Consumer-Clustern werden aggregiert, um zu bestimmen, welche Abschnitte der Tabelle von der Sortierung profitieren.

Abhängig von der Auslastung des Systems leitet Amazon Redshift die Sortierung automatisch ein. Diese automatische Sortierung erübrigt die Ausführung des Befehls VACUUM, um die Daten in der Reihenfolge der Sortierkriterien zu halten. Wenn Sie Daten vollständig nach dem Sortkey sortiert benötigen, z. B. nach einer großen Datenmenge, können Sie den Befehl VACUUM trotzdem manuell ausführen. Um festzustellen, ob Ihre Tabelle von der Ausführung von VACUUM SORT profitieren wird, überwachen Sie die Spalte `vacuum_sort_benefit` in [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md). 

Amazon Redshift verfolgt Scan-Abfragen, die den Sortierschlüssel für jede Tabelle verwenden. Amazon Redshift schätzt den maximalen Prozentsatz der Verbesserung beim Scannen und Filtern von Daten für die Tabelle (wenn die Tabelle vollständig sortiert war). Diese Schätzung ist in der Spalte `vacuum_sort_benefit` in [SVV\$1TABLE\$1INFO](r_SVV_TABLE_INFO.md) sichtbar. Sie können diese Spalte zusammen mit der Spalte `unsorted` verwenden, um festzulegen, wann Abfragen davon profitieren können, VACUUM SORT manuell für eine Tabelle auszuführen. Die Spalte `unsorted` spiegelt die physische Sortierreihenfolge einer Tabelle wider. Die Spalte `vacuum_sort_benefit` gibt die Auswirkung der Sortierung einer Tabelle durch manuelles Ausführen von VACUUM SORT an.

Nehmen Sie beispielsweise die folgende Abfrage:

```
select "table", unsorted,vacuum_sort_benefit from svv_table_info order by 1;
```

```
 table | unsorted | vacuum_sort_benefit 
-------+----------+---------------------
 sales |    85.71 |                5.00
 event |    45.24 |               67.00
```

Obwohl die Tabelle "sales" \$186 % physisch unsortiert ist, hat dies nur einen Einfluss 5 % auf die Abfrageleistung. Dies kann entweder daran liegen, dass nur ein kleiner Teil der Tabelle von Abfragen angesprochen wird oder dass nur sehr wenige Abfragen auf die Tabelle zugegriffen haben. Die Tabelle "event" ist \$145 % physisch unsortiert. Aber die Änderung der Abfrageleistung von 67 % zeigt auf, dass entweder ein größerer Teil der Tabelle von Abfragen abgerufen wurde oder dass die Anzahl der auf die Tabelle zugreifenden Abfragen groß war. Die Tabelle "event" kann potentiell von der Ausführung von VACUUM SORT profitieren.

## Automatisches Aufrufen von VACUUM DELETE
<a name="automatic-table-delete"></a>

Wenn Sie einen Löschvorgang ausführen, werden die Zeilen zum Löschen markiert, jedoch nicht entfernt. Amazon Redshift führt automatisch einen VACUUM DELETE-Vorgang im Hintergrund aus, der auf der Anzahl der gelöschten Zeilen in Datenbanktabellen basiert. Amazon Redshift legt für VACUUM DELETE eine zeitplangesteuerte Ausführung so fest, dass diese Ausführung in Zeiten fällt, in denen der Workload gering ist, und hält die Ausführung bei hoher Auslastung an. 

**Topics**
+ [

## Automatische Tabellensortierung
](#automatic-table-sort)
+ [

## Automatisches Aufrufen von VACUUM DELETE
](#automatic-table-delete)
+ [

## Häufigkeit von Bereinigungen (VACUUM)
](#vacuum-frequency)
+ [

## Sortierphase und Zusammenführungsphase
](#vacuum-stages)
+ [

## Schwellenwert für die Bereinigung
](#vacuum-sort-threshold)
+ [

## Arten von Bereinigungen
](#vacuum-types)
+ [

# Minimieren von Bereinigungszeiten
](vacuum-managing-vacuum-times.md)

## Häufigkeit von Bereinigungen (VACUUM)
<a name="vacuum-frequency"></a>

Sie sollten Bereinigungen so häufig wie notwendig ausführen, um eine konsistente Abfrageleistung aufrechtzuerhalten. Bei der Festlegung der Häufigkeit, mit der Sie den Befehl VACUUM ausführen, sollten Sie folgende Faktoren berücksichtigen:
+ Führen Sie VACUUM während Zeiten aus, in denen Sie für den Cluster nur minimale Aktivität erwarten, beispielsweise abends oder während festgelegter Zeitfenster für die Datenbankadministration. 
+ Führen Sie VACUUM-Befehle außerhalb von Wartungsfenstern aus. Weitere Informationen finden Sie unter [Zeitplanung um Wartungsfenster](https://docs.aws.amazon.com/redshift/latest/dg/c_best-practices-avoid-maintenance.html).
+ Eine große, nicht sortierte Region führt zu längeren Bereinigungszeiten. Wenn Sie die Bereinigung verzögern, dauert sie länger, da mehr Daten neu organisiert werden müssen. 
+ VACUUM ist ein I/O intensiver Vorgang. Je länger es dauert, bis Ihr Vacuum abgeschlossen ist, desto mehr Auswirkungen hat es auf gleichzeitige Abfragen und andere Datenbankoperationen, die auf Ihrem Cluster ausgeführt werden. 
+ VACUUM benötigt für Tabellen, die eine überlappende Sortierung verwenden, länger. Um zu beurteilen, ob überlappende Tabellen neu sortiert werden müssen, fragen Sie die Ansicht [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) ab.

## Sortierphase und Zusammenführungsphase
<a name="vacuum-stages"></a>

Amazon Redshift führt Bereinigungsoperationen in zwei Phasen aus. Zunächst werden die Zeilen in der nicht sortierten Region sortiert. Anschließend werden die neu sortierten Zeilen am Ende der Tabelle mit den vorhandenen Zeilen zusammengeführt, wenn notwendig. Beim Bereinigen einer großen Tabelle wird die Bereinigungsoperation in einer Reihe von Schritten ausgeführt, die aus inkrementellen Sortierungen gefolgt von Zusammenführungen bestehen. Wenn die Operation fehlschlägt oder Amazon Redshift während der Bereinigung offline geht, befindet sich die teilweise bereinigte Tabelle oder Datenbank in einem konsistenten Zustand. Sie müssen jedoch die Bereinigungsoperation manuell neu starten. Inkrementelle Sortierungen gehen verloren. Die zusammengeführten Zeilen, für die vor dem Fehler ein Commit ausgeführt wurde, müssen jedoch nicht erneut bereinigt werden. Wenn die nicht sortierte Region groß ist, kann erhebliche Zeit verloren gehen. Weitere Informationen zu den Sortierungs- und Zusammenführungsphasen finden Sie unter [Reduzieren der Zahl der zusammengeführten Zeilen](vacuum-managing-vacuum-times.md#vacuum-managing-volume-of-unmerged-rows).

Benutzer können auf Tabellen zugreifen, während sie bereinigt werden. Sie können Abfragen und Schreiboperationen ausführen, während eine Tabelle bereinigt wird. Wenn jedoch DML und eine Bereinigung gleichzeitig ausgeführt werden, dauern beide Vorgänge möglicherweise länger. Wenn Sie während einer Bereinigung UPDATE- und DELETE-Anweisungen ausführen, wird die Systemleistung möglicherweise reduziert. Inkrementelle Zusammenführungen blockieren gleichzeitig ausgeführte UPDATE- und DELETE-Operationen. UPDATE- und DELETE-Operationen wiederum blockieren inkrementelle Zusammenführungen für die betroffenen Tabellen. DDL-Operationen wie ALTER TABLE werden blockiert, bis die Bereinigungsoperation für die Tabelle abgeschlossen ist.

**Anmerkung**  
Verschiedene Modifikatoren für VACUUM steuern die Funktionsweise. Sie können sie verwenden, um die Bereinigung an den aktuellen Bedarf anzupassen. Beispielsweise verkürzt die Verwendung von VACUUM RECLUSTER die Bereinigung, indem keine vollständige Verschmelzung durchgeführt wird. Weitere Informationen finden Sie unter [VACUUM](r_VACUUM_command.md).

## Schwellenwert für die Bereinigung
<a name="vacuum-sort-threshold"></a>

Standardmäßig überspringt VACUUM die Sortierungsphase für alle Tabellen, in denen mehr als 95 Prozent der Tabellenzeilen bereits sortiert sind. Das Überspringen der Sortierungsphase kann die Leistung von VACUUM deutlich verbessern. Um den Standardschwellenwert für die Sortierung für eine einzelne Tabelle zu ändern, verwenden Sie den Tabellennamen und den Parameter TO *threshold* PERCENT, wenn Sie den Befehl VACUUM ausführen. 

## Arten von Bereinigungen
<a name="vacuum-types"></a>

Weitere Informationen zu den verschiedenen Arten von Bereinigungstypen finden Sie unter [VACUUM](r_VACUUM_command.md).

# Minimieren von Bereinigungszeiten
<a name="vacuum-managing-vacuum-times"></a>

 Amazon Redshift sortiert im Hintergrund automatisch die Daten und führt VACUUM DELETE aus. Dadurch entfällt die Notwendigkeit, den Befehl VACUUM auszuführen. Bereinigungsvorgänge können zeitaufwendig sein. Abhängig von der Art Ihrer Daten werden die folgenden Verfahren empfohlen, um die Bereinigungszeiten zu minimieren.

**Topics**
+ [

## Entscheidung über eine Neuindizierung
](#r_vacuum-decide-whether-to-reindex)
+ [

## Reduzieren der Größe der nicht sortierten Region
](#r_vacuum_diskspacereqs)
+ [

## Reduzieren der Zahl der zusammengeführten Zeilen
](#vacuum-managing-volume-of-unmerged-rows)
+ [

## Laden Ihrer Daten in Sortierschlüsselreihenfolge
](#vacuum-load-in-sort-key-order)
+ [

## Verwenden von Zeitreihentabellen zur Reduzierung gespeicherter Daten
](#vacuum-time-series-tables)

## Entscheidung über eine Neuindizierung
<a name="r_vacuum-decide-whether-to-reindex"></a>

Häufig können Sie die Abfrageleistung deutlich verbessern, indem Sie einen überlappenden Sortierstil verwenden. Mit der Zeit verschlechtert sich die Leistung jedoch möglicherweise, wenn die Verteilung der Werte in den Sortierschlüsselspalten geändert wird. 

Wenn Sie eine leere, überlappende Tabelle mittels COPY oder CREATE TABLE AS laden, erstellt Amazon Redshift den überlappenden Index automatisch. Wenn Sie eine überlappende Tabelle mittels INSERT laden, müssen Sie im Anschluss VACUUM REINDEX ausführen, um den überlappenden Index zu initialisieren. 

Während Sie Zeilen mit neuen Sortierschlüsselwerten hinzufügen, kann sich die Leistung verschlechtern, wenn die Verteilung der Werte in den Sortierschlüsselspalten geändert wird. Wenn Ihre neuen Zeilen primär innerhalb des Bereichs der vorhandenen Sortierschlüsselwerte liegen, müssen Sie keine Neuindizierung ausführen. Führen Sie VACUUM SORT ONLY oder VACUUM FULL aus, um die Sortierreihenfolge wiederherzustellen. 

Das Abfragemodul kann die Sortierreihenfolge verwenden, um effizient festzulegen, welche Datenblöcke gescannt werden müssen, um eine Abfrage zu verarbeiten. Im Fall einer überlappenden Sortierung analysiert Amazon Redshift die Sortierschlüsselspaltenwerte, um die optimale Sortierreihenfolge zu ermitteln. Wenn aufgrund hinzugefügter Zeilen die Verteilung der Schlüsselwerte geändert oder verschoben wird, ist die Sortierstrategie nicht mehr optimal und der Vorteil, den die Sortierung für die Leistung hat, nimmt ab. Um die Sortierschlüsselverteilung neu zu analysieren, können Sie eine VACUUM REINDEX-Operation ausführen. Die Neuindizierungsoperation ist zeitaufwändig. Um festzustellen, ob eine Tabelle von einer Neuindizierung profitiert, führen Sie eine Abfrage für die Ansicht [SVV\$1INTERLEAVED\$1COLUMNS](r_SVV_INTERLEAVED_COLUMNS.md) aus. 

Beispielsweise zeigt die folgende Abfrage Details für Tabellen an, die überlappende Sortierschlüssel verwenden.

```
select tbl as tbl_id, stv_tbl_perm.name as table_name, 
col, interleaved_skew, last_reindex
from svv_interleaved_columns, stv_tbl_perm
where svv_interleaved_columns.tbl = stv_tbl_perm.id
and interleaved_skew is not null;


 tbl_id | table_name | col | interleaved_skew | last_reindex
--------+------------+-----+------------------+--------------------
 100048 | customer   |   0 |             3.65 | 2015-04-22 22:05:45
 100068 | lineorder  |   1 |             2.65 | 2015-04-22 22:05:45
 100072 | part       |   0 |             1.65 | 2015-04-22 22:05:45
 100077 | supplier   |   1 |             1.00 | 2015-04-22 22:05:45
(4 rows)
```

Der Wert für `interleaved_skew` ist ein Verhältnis, das die Menge der Verschiebung angibt. Ein Wert von 1 bedeutet, dass es keine Verschiebung gegeben hat. Wenn die Verschiebung größer als 1,4 ist, verbessert eine VACUUM REINDEX -Operation in der Regel die Leistung, es sei denn, die Verschiebung ist ein Merkmal des zugrundeliegenden Satzes. 

Sie können den Datumswert in `last_reindex` verwenden, um festzustellen, wie viel Zeit seit der letzten Neuindizierung verstrichen ist. 

## Reduzieren der Größe der nicht sortierten Region
<a name="r_vacuum_diskspacereqs"></a>

Die nicht sortierte Region nimmt an Größe zu, wenn Sie große Mengen neuer Daten in Tabellen laden, die bereits Daten enthalten, oder wenn Sie Tabellen nicht als Teil der routinemäßigen Wartungsoperationen bereinigen. Um lange Ausführungszeiten von Bereinigungsoperationen zu vermeiden, verwenden Sie die folgenden Verfahren:
+ Führen Sie Bereinigungsoperationen regelmäßig aus. 

  Wenn Sie Ihre Tabellen in kleinen Inkrementen laden (beispielsweise täglichen Updates, die einen kleinen Prozentsatz der gesamten Zeilenzahl in der Tabelle darstellen), hilft die regelmäßige Ausführung von VACUUM, eine schnelle Ausführung der einzelnen Bereinigungsoperationen sicherzustellen.
+ Führen Sie den größten Ladevorgang zuerst aus.

  Wenn Sie eine neue Tabelle mit mehreren COPY-Operationen laden müssen, führen Sie den größten Ladevorgang zuerst aus. Wenn Sie einen Ladevorgang zum ersten Mal in eine neue oder verkürzte Tabelle ausführen, werden alle Daten direkt in die sortierte Region geladen, sodass keine Bereinigung erforderlich ist.
+ Verkürzen Sie eine Tabelle, statt alle Zeilen zu löschen. 

  Durch das Löschen von Zeilen aus einer Tabelle wird der Platz nicht zurückgewonnen, den die Zeilen vor der Ausführung der Bereinigungsoperation belegt haben. Durch das Verkürzen einer Tabelle werden jedoch die Tabelle geleert und der Festplattenplatz zurückgewonnen; daher ist keine Bereinigung erforderlich. Alternativ können Sie die Tabelle entfernen und neu erstellen. 
+ Verkürzen oder entfernen Sie Testtabellen. 

  Wenn Sie zu Testzwecken eine kleine Zahl von Zeilen in eine Tabelle laden, sollten Sie die Zeilen nach Abschluss des Vorgangs nicht löschen. Verkürzen Sie stattdessen die Tabelle und laden Sie diese Zeilen als Teil der anschließenden Produktionsladeoperation neu. 
+ Führen Sie eine Deep Copy-Operation aus. 

  Wenn eine Tabelle mit einer zusammengesetzten Sortierschlüsseltabelle einen großen, nicht sortierten Bereich besitzt, ist eine Deep Copy-Operation sehr viel schneller als eine Bereinigung. Eine Deep-Kopie erstellt eine Tabelle neu und füllt diese, indem sie einen Bulk-Insert verwendet, der die Tabelle automatisch neu sortiert. Wenn eine Tabelle einen großen, nicht sortierten Bereich besitzt, ist eine Deep Copy-Operation sehr viel schneller als eine Bereinigung. Der Kompromiss besteht darin, dass Sie während einer Deep Copy-Operation anders als bei einer Bereinigung nicht gleichzeitig Aktualisierungen ausführen können. Weitere Informationen finden Sie unter [Bewährte Methoden für die Gestaltung von Abfragen mit Amazon Redshift](c_designing-queries-best-practices.md). 

## Reduzieren der Zahl der zusammengeführten Zeilen
<a name="vacuum-managing-volume-of-unmerged-rows"></a>

Wenn eine Bereinigungsoperation neue Zeilen mit der sortierten Region einer Tabelle zusammenführen muss, nimmt der für die Bereinigung benötigte Zeitraum zu, wenn die Tabelle größer wird. Sie können die Leistung der Bereinigung verbessern, indem Sie die Zahl der Zeilen reduzieren, die zusammengeführt werden müssen. 

Vor einer Bereinigung besteht eine Tabelle aus einer sortierten Region zu Beginn der Tabelle, gefolgt von einer nicht sortierten Region, deren Größe jedes Mal zunimmt, wenn Zeilen hinzugefügt oder aktualisiert werden. Wenn ein Satz von Zeilen durch eine COPY-Operation hinzugefügt wird, wird der neue Satz von Zeilen anhand des Sortierschlüssels sortiert, wenn er der nicht sortierten Region am Ende der Tabelle hinzugefügt wird. Die neuen Zeilen werden innerhalb des eigenen Satzes, jedoch nicht innerhalb der nicht sortierten Region sortiert. 

Im folgenden Diagramm wird die nicht sortierte Region nach zwei aufeinanderfolgenden COPY-Operationen gezeigt. Der Sortierschlüssel ist CUSTID. Aus Gründen der Einfachheit zeigt dieses Beispiel einen zusammengesetzten Sortierschlüssel. Für überlappende Sortierschlüssel gelten jedoch dieselben Grundsätze, abgesehen davon, dass die Auswirkungen der nicht sortierten Region bei überlappenden Tabellen größer sind. 

![\[Eine unsortierte Tabelle mit Datensätzen aus zwei COPY-Operationen.\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/images/vacuum-unsorted-region.png)


Eine Bereinigung stellt die Sortierreihenfolge der Tabelle in zwei Phasen wieder her:

1. Die nicht sortierte Region wird zu einer neu sortierten Region sortiert. 

   Die erste Phase ist vergleichsweise kostengünstig, da nur die nicht sortierte Region neu geschrieben wird. Wenn der Bereich der Sortierschlüsselwerte der neu sortierten Region größer als der vorhandene Bereich ist, müssen nur die neuen Zeilen neu geschrieben werden und die Bereinigung ist abgeschlossen. Wenn die sortierte Region beispielsweise ID-Werte von 1 bis 500 enthält und nachfolgende COPY-Operationen Schlüsselwerte hinzufügen, die größer als 500 sind, dann muss nur die nicht sortierte Region neu geschrieben werden. 

1. Führen Sie die neu sortierte Region mit der zuvor sortierten Region zusammen. 

   Wenn die Schlüssel in der neu sortierten Region mit den Schlüsseln in der sortierten Region überlappen, muss VACUUM die Zeilen zusammenführen. Beginnend mit dem Anfang der neu sortierten Region (beim niedrigsten Sortierschlüssel) schreibt die Bereinigungsoperation die zusammengeführten Zeilen aus der zuvor sortierten Region und der neu sortierten Region in einen neuen Satz von Blöcken. 

Der Umfang, mit dem der neue Sortierschlüsselbereich mit den vorhandenen Sortierschlüsseln überlappt, legt den Umfang fest, in dem die zuvor sortierte Region neu geschrieben werden muss. Wenn die nicht sortierten Schlüssel über den vorhandenen Sortierbereich verstreut sind, muss eine Bereinigungsoperation möglicherweise vorhandene Teile der Tabelle neu schreiben. 

Im folgenden Diagramm wird gezeigt, wie eine Bereinigungsoperation Zeilen sortierten und zusammenführen würde, die einer Tabelle mit CUSTID als Sortierschlüssel hinzugefügt wurden. Da jede Kopieroperation einen neuen Satz von Zeilen mit Schlüsselwerten hinzufügt, die die vorhandenen Schlüssel überlappen, muss beinahe die gesamte Tabelle neu geschrieben werden. Das Diagramm zeigt einen einzelnen Sortierungs- und Zusammenführungsvorgang. In der Praxis bestehen große Bereinigungen jedoch aus einer Reihe inkrementeller Sortierungs- und Zusammenführungsvorgänge. 

![\[Eine VACUUM-Operation in der Beispieltabelle in zwei Schritten. Zuerst werden die neuen Zeilen sortiert. Anschließend werden sie mit den vorhandenen Zeilen zusammengeführt.\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/images/vacuum-unsorted-region-sort-merge.png)


Wenn der Bereich von Sortierschlüsseln in einem Satz neuer Zeilen mit dem Bereich vorhandener Schlüssel überlappt, nehmen die Kosten der Zusammenführungsphase entsprechend der Tabellengröße zu, während die Tabelle an Größe zunimmt. Die Kosten der Sortierphase entsprechen jedoch weiter der Größe der nicht sortierten Region. In diesem Fall sind die Kosten der Zusammenführungsphase größer als die Kosten der Sortierphase, wie das folgende Diagramm zeigt.

![\[Diagramm, das zeigt, dass die Zusammenführungsphase teurer wird, wenn sich die Sortierschlüssel neuer Zeilen mit vorhandenen Zeilen überschneiden.\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/images/vacuum-example-merge-region-grows.png)


Um den Anteil einer Tabelle zu ermitteln, der neu zusammengeführt wurde, führen Sie eine Abfrage für SVV\$1VACUUM\$1SUMMARY aus, nachdem die Bereinigungsoperation abgeschlossen ist. Die folgende Abfrage zeigt die Auswirkungen von sechs aufeinanderfolgenden Bereinigungsoperationen, während CUSTSALES mit der Zeit an Größe zunahm.

```
select * from svv_vacuum_summary
where table_name = 'custsales';


 table_name | xid  | sort_      | merge_     | elapsed_   | row_  | sortedrow_ | block_  | max_merge_
            |      | partitions | increments | time       | delta | delta      | delta   | partitions
 -----------+------+------------+------------+------------+-------+------------+---------+---------------
  custsales | 7072 |          3 |          2 |  143918314 |     0 |   88297472 |   1524  |      47
  custsales | 7122 |          3 |          3 |  164157882 |     0 |   88297472 |    772  |      47
  custsales | 7212 |          3 |          4 |  187433171 |     0 |   88297472 |    767  |      47
  custsales | 7289 |          3 |          4 |  255482945 |     0 |   88297472 |    770  |      47
  custsales | 7420 |          3 |          5 |  316583833 |     0 |   88297472 |    769  |      47
  custsales | 9007 |          3 |          6 |  306685472 |     0 |   88297472 |    772  |      47
 (6 rows)
```

Die Spalte merge\$1increments zeigt die Menge der Daten an, die für die einzelnen Bereinigungsoperationen zusammengeführt wurden. Wenn die Zahl der Zusammenführungsinkremente über aufeinanderfolgende Bereinigungen entsprechend dem Wachstum der Tabellengröße zunimmt, ist das ein Anzeichen dafür, dass jede Bereinigungsoperation eine zunehmende Zahl von Zeilen in der Tabelle neu zusammenführt, da die vorhandenen und neu sortierten Regionen überlappen. 

## Laden Ihrer Daten in Sortierschlüsselreihenfolge
<a name="vacuum-load-in-sort-key-order"></a>

Wenn Sie Ihre Daten in der Reihenfolge des Sortierschlüssels mithilfe eines COPY-Befehls laden, können Sie die Notwendigkeit einer Bereinigung verringern oder die Bereinigung sogar ganz überflüssig machen. 

COPY fügt automatisch der sortierten Region der Tabelle neue Zeilen hinzu, wenn alle folgenden Bedingungen zutreffen:
+ Die Tabelle verwendet einen zusammengesetzten Sortierschlüssel mit nur einer Sortierspalte. 
+ Die Sortierspalte ist NOT NULL. 
+ Die Tabelle ist zu 100 Prozent sortiert oder leer. 
+ Alle neuen Zeilen liegen in der Sortierreihenfolge höher als die vorhandenen Zeilen, einschließlich Zeilen, die zum Löschen markiert sind. In diesem Beispiel verwendet Amazon Redshift die ersten acht Bytes des Sortierschlüssels, um die Sortierreihenfolge festzulegen.
+  Der Befehl COPY löst bestimmte Ladeoptimierungen nicht aus. Beim Laden großer Datenmengen optimiert Amazon Redshift möglicherweise die Leistung, indem neue sortierte Partitionen erstellt werden, anstatt Zeilen zum sortierten Bereich der Tabelle hinzuzufügen. 

Angenommen, Sie verfügen beispielsweise über eine Tabelle, die Kundenveranstaltungen mittels einer Kunden-ID und eines Zeitpunkts aufzeichnet. Wenn Sie die Tabelle nach der Kunden-ID sortieren, überlappt der Sortierschlüsselbereich der neuen, durch inkrementelle Ladevorgänge hinzugefügten Zeilen wahrscheinlich den vorhandenen Bereich, wie im vorherigen Beispiel gezeigt. Dies führt zu einer kostspieligen Bereinigungsoperation. 

Wenn Sie den Sortierschlüssel auf eine Zeitstempelspalte festlegen, werden die neuen Zeilen in Sortierreihenfolge am Ende der Tabelle angefügt, wie im folgenden Diagramm dargestellt. Dies reduziert die Notwendigkeit einer Bereinigung oder macht diese sogar überflüssig.

![\[Eine Tabelle, die eine Zeitstempelspalte als Sortierschlüssel verwendet, wodurch neue Datensätze abgerufen werden, die nicht sortiert werden müssen.\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/images/vacuum-unsorted-region-date-sort.png)


## Verwenden von Zeitreihentabellen zur Reduzierung gespeicherter Daten
<a name="vacuum-time-series-tables"></a>

Wenn Sie Daten für einen rollierenden Zeitraum warten, verwenden Sie eine Reihe von Tabellen wie im folgenden Diagramm gezeigt.

![\[Fünf Tabellen mit Daten aus fünf Quartalen. Die älteste Tabelle wird gelöscht, um einen gleitenden Zeitraum von einem Jahr beizubehalten.\]](http://docs.aws.amazon.com/de_de/redshift/latest/dg/images/vacuum-example-unsorted-region-copy-time-series.png)


Erstellen Sie jedes Mal, wenn Sie einen Satz von Daten hinzufügen, eine neue Tabelle. Löschen Sie anschließend die älteste Tabelle in der Reihe. Sie erzielen einen doppelten Vorteil: 
+ Sie vermeiden den zusätzlichen Aufwand für das Löschen von Zeilen, da die DROP TABLE-Operation sehr viel effizienter als eine DELETE-Massenoperation ist.
+ Wenn die Tabellen nach Zeitstempel sortiert sind, wird keine Bereinigung benötigt. Wenn jede Tabelle die Daten für einen Monat enthält, muss eine Bereinigung höchstens die Daten eines Monats neu schreiben, auch wenn die Tabellen nicht nach Zeitstempel sortiert sind.

Sie können eine UNION ALL-Ansicht erstellen, die von Berichtsabfragen verwendet wird, die Tatsache verbirgt, dass die Dateien in mehreren Tabellen gespeichert sind. Wenn eine Abfrage nach dem Sortierschlüssel filtert, kann der Abfrageplaner effizient alle nicht verwendeten Tabellen überspringen. Eine UNION ALL-Ansicht kann für andere Arten von Abfragen weniger effizient sein. Daher sollten Sie die Abfrageleistung im Zusammenhang mit allen Abfragen bewerten, die die Tabellen verwenden.