Tabellenpartitionierung durchführen

In einem Multi-Host-System ist jeder Index-Server für maximale Performance in der Regel einem eigenen Rechner zugeordnet. SAP HANA unterstützt die folgenden Möglichkeiten, Daten auf die Hosts zu verteilen:

• Eine partitionierte Tabelle teilt Daten in mehrere Blöcke (Partitionen) auf, und diese Partitionen können auf verschiedenen Index-Servern gespeichert werden.

• Verschiedene Tabellen können unterschiedlichen Index-Servern zugeordnet werden.

• Eine Tabelle kann auf mehrere Index-Server repliziert werden, um die Abfrage- und Join-Performance zu verbessern.

Wenn Sie neue Tabellen oder Partitionen anlegen, werden diese vom System auf die verfügbaren Hosts verteilt. Standardmäßig wird eine "round-robin"-Verteilungsmethode verwendet, aber Tabellen können auch mithilfe der Tabellenplatzierungsregeln oder durch die Angabe einer Host- und Portnummer mit der SQL-Anweisung CREATE TABLE in der location-Klausel positioniert werden. Dies gibt dem Entwickler die vollständige Kontrolle über die Positionierung einzelner Tabellen.

Bestimmte Anwendungen können vordefinierte Tabellenverteilungsregeln haben. In einigen Fällen sind Konfigurationsdateien und Dokumentation in SAP-Hinweisen verfügbar, um Sie bei der Einrichtung der erforderlichen Partitionierungs- und Tabellenplatzierungsregeln zu unterstützen.

Die Partitionierungsfunktion der SAP-HANA-Datenbank teilt Spaltenspeichertabellen horizontal in disjunktive Untertabellen oder Partitionen auf. Auf diese Weise können große Tabellen in kleinere, überschaubarere Teile zerlegt werden.

Die Partitionierung ist nur für Tabellen verfügbar, die sich im Spaltenspeicher befinden. Der Zeilenspeicher unterstützt keine Partitionierung.

Die Tabellenpartitionierung ist für die Anwendung so transparent, dass Anwendungen mit allen Partitionierungsstrategien ordnungsgemäß funktionieren. Dennoch kann die Partitionierung Auswirkungen auf die Performance haben, sodass sie sowohl positiv als auch negativ für den Endbenutzer und die Systemlast ausschlaggebend sein kann. Um das Risiko von Performance-Regressionen zu minimieren, ist es wichtig, eine gute Partitionierungsstrategie zu implementieren.

Die Partitionierung ist für SQL-Abfragen und DML-Anweisungen (Data Manipulation Language) transparent. Folgende zusätzliche Datendefinitionsanweisungen (DDL) für die Partitionierung stehen zur Verfügung:

• Delta-Merge-Operation für bestimmte Partitionen durchführen
• Tabellenpartitionen anlegen
• Tabellen neu partitionieren
• Partitionen in einer Tabelle zusammenführen
• Partitionen hinzufügen oder löschen
• Partitionen auf andere Hosts verschieben

Wenn eine Tabelle partitioniert wird, erfolgt die Aufteilung so, dass jede Partition eine andere Menge von Zeilen der Tabelle enthält. Es stehen mehrere Alternativen zur Verfügung, um festzulegen, wie die Zeilen den Partitionen einer Tabelle zugeordnet werden, z.B. Hash-Partitionierung, Round-Robin-Partitionierung oder Partitionierung nach Range.

In der Abbildung „Beispiele für Tabellenpartitionierung" wird die Tabelle HA201_DEMO_TABLE mit drei Partitionen angelegt. Die einstufige Partitionierungsspezifikation ist HASH in der Spalte Hay.

Im obigen Beispiel wird eine neue Tabelle angelegt, die beim Anlegen partitioniert wird. In der Praxis wird es auch vorkommen, dass Sie eine oder mehrere partitionierte Tabellen zusammenführen oder eine vorhandene Tabelle partitionieren müssen. Die Anwendungsfälle können sein, dass sich die Tabelle dem Limit von 2 Milliarden Datensätzen nähert, oder die Query-Performance ist nicht optimal. Mit den genannten SQL-Anweisungen können Sie partitionierte Tabellen zusammenführen oder vorhandene Tabellen in der SAP-HANA-Datenbank partitionieren.

Bei Überschreitung von Schwellenwerten findet keine automatische Repartitionierung statt. Stattdessen wird dies bei der nächsten Ausführung des Rückverteilungsprozesses vorgeschlagen.

Die für die Partitionierung eingegebenen Werte müssen mit der physischen Landschaft konsistent sein, insbesondere mit der Anzahl der verfügbaren Serverknoten.

Wenn eine Repartitionierung erforderlich ist, werden Tabellen nur repartitioniert, indem die Anzahl der vorhandenen (initialen) Partitionen verdoppelt wird. Dies geschieht aus Performancegründen. Die maximale Anzahl von Partitionen (erste Ebene), die von diesem Prozess erreicht wird, wird durch den Parameter global.ini > [table_placement] > max_partitions definiert (Standard: 12).

Standardmäßig legt das System nicht mehr Partitionen als die Anzahl der verfügbaren Hosts (oder genauer: mögliche Speicherorte) an. Wenn INITIAL_PARTITIONS beispielsweise auf 3 gesetzt ist, die verteilte SAP-HANA-Datenbank jedoch fünf mögliche Speicherorte hat, findet keine Repartitionierung von drei bis sechs Partitionen statt. Eine Tabelle kann mehr als eine Partition pro Host haben, wenn der Parameter global.ini > [table_placement] > max_partitions_limited_by_locations auf false gesetzt ist (Standard: true). Diese Regel wird ignoriert, wenn eine höhere Anzahl von Partitionen der ersten Ebene für Partitionsgruppen mit mehr als 2 Milliarden Datensätzen erforderlich ist (global.ini > [table_placement] > max_rows_per_partition, Standard = 2.000.000.000).

Wenn eine Tabelle auf mehrere Partitionen verteilt ist, zeigt sie den Host an, der jede dieser Partitionen speichert. Vorhandene Partitionen können auf verschiedene Hosts verschoben werden, indem ein bestimmter Umverteilungsplan generiert wird. Sie können die Tabellenverteilung auch ausgleichen, nachdem Sie dem System neue Hosts hinzugefügt haben. Prüfen, optimieren, komprimieren, defrag, laden der Tabelle, Delta-Merge und Auswerten der Repartitionierung von Tabellen, die auch nicht auf andere Hosts partitioniert sind.

Um einen optimalen Partitionierungsplan zu erstellen, sollten Sie versuchen, die Best Practices für die Tabellenpartitionierung in der Abbildung „Best-Practices-Tabellenpartitionierung" zu befolgen.

• Halten Sie die Anzahl der partitionierten Tabellen niedrig

  Partitionieren Sie Tabellen nur, wenn Sie einen klaren Vorteil ohne signifikante Regressionen sehen.

• Halten Sie die Anzahl der Partitionen pro Tabelle niedrig

  Eine unnötig hohe Anzahl von Partitionen führt zu einem Overhead, da einige Abfragen möglicherweise auf alle Partitionen zugreifen müssen, um die Daten zu finden:

  • Da eine große Anzahl von Netzwerkkanälen geöffnet wird, besteht das Risiko, dass das System die maximale Kanalbegrenzung (SAP-Hinweis 2222200) erreicht und netzwerkbezogene Abbrüche auslöst.

  • Bestimmte Operationen wie die Ermittlung von Spaltenstatistiken (SAP-Hinweis 2114710) müssen für jede Partition einzeln ausgeführt werden.

  Beachten Sie daher die folgenden allgemeinen Regeln, bevor Sie eine bestimmte Anzahl von Partitionen definieren:

  • Wenn Sie Tabellen aufgrund der Grenze von 2 Milliarden partitionieren, ist es in der Regel akzeptabel, wenn einzelne Partitionen bis zu 1,5 Milliarden Datensätze enthalten (weniger, wenn Sie ein signifikantes zukünftiges Wachstum erwarten).

  • Wenn Sie nach Datum partitionieren, sollten Sie keine granularen Bereiche (z.B. Tage oder Wochen) verwenden, die zu einer großen Anzahl von Partitionen führen.

  • Wenn Sie eine RANGE-Partition für Spalten mit Daten verwenden, die nicht gleichmäßig verteilt sind (z.B. eine Nummernkreisspalte mit mehreren verschiedenen Nummernkreisen), sollten Sie die tatsächliche Werteverteilung prüfen und die Bereichsgrenzen entsprechend definieren.

• Halten Sie die Anzahl der Schlüsselspalten niedrig

  So wenige Partitionsschlüsselspalten wie möglich. Es ist aus folgenden Gründen sinnvoll, die Anzahl der Partitionsschlüsselspalten auf ein Minimum zu beschränken:

  • Partitions-Pruning von Hash-Partitionen kann nur verwendet werden, wenn alle zugrunde liegenden Partitionierungsspalten in der WHERE-Klausel mit "=" oder "IN" angegeben sind.

  • Das Ermitteln des Partitions-Pruning kann sehr zeitaufwändig sein, wenn viele Partitionsschlüssel beteiligt sind.

    Weitere Informationen finden Sie im SAP-Hinweis 2000002 "Was sind typische Ansätze zur Optimierung teurer SQL-Anweisungen?" und "Ausführungszeit höher als erwartet, negative Auswirkungen durch vorhandene Partitionierung".

  Bei der Hash-Partitionierung ist es oft sinnvoll, nur die selektivste Primärschlüsselspalte als Partitionsschlüsselspalte zu verwenden.

• Behalten Sie für SAP Suite on HANA alle Partitionen auf demselben Host.

  In Scale-Out-Umgebungen von SAP Suite on HANA ist es vorteilhaft, alle Partitionen einer Tabelle auf demselben Host zu halten. Ab SPS08 kann dies mit einer entsprechenden Tabellenplatzierungskonfiguration erreicht werden.

  Als Fallback-Option können Sie eine Dummy-Partitionierung der ersten Ebene (z.B. auf MANDT) verwenden und die eigentliche Partitionierung auf der zweiten Ebene durchführen. In diesem Fall befinden sich alle Partitionen auf demselben Host.

• Repartitionierungsregeln

  Wählen Sie bei der Repartitionierung die neue Anzahl der Partitionen als Vielfaches oder Teiler der aktuellen Anzahl von Partitionen.

  Wenn eine Tabelle bereits partitioniert ist, ist es am effizientesten, eine neue Anzahl von Partitionen zu wählen, bei der es sich um ein Vielfaches von Faktor 2 oder einen Teiler der aktuellen Anzahl von Partitionen handelt (z.B. 4 -> 8 oder 6 -> 3 Partitionen). Nur in diesem Fall kann die Repartitionierung parallel auf verschiedenen Partitionsgruppen und Hosts erfolgen ("paralleler Split/Merge").

• Eindeutige Einschränkungen vermeiden

  Versuchen Sie beim Anlegen von Partitionen, das Anlegen zusätzlicher eindeutiger Integritätsregeln zu vermeiden. Vermeiden Sie die Partitionierung von Tabellen mit zusätzlichen Unique-Constraints (z.B. einem Unique-Sekundärindex), da die Eindeutigkeitsprüfungen einen erheblichen Overhead verursachen.

  Notiz

  SAP-Hinweis 2000002 gibt Einblick in die SAP-HANA-SQL-Optimierung und beschreibt Symptome, die durch eine unzureichende Partitionierung verursacht werden können.

Die Systemansicht M_CS_PARTITIONS stellt Partitionsinformationen von Spaltentabellen bereit.

1
select * from "M_CS_PARTITIONS" where "TABLE_NAME" = 'sap.hana.democontent.epm.data::PO.Item';

Die Ausgabe zeigt die Anzahl der Partitionen an. Im Beispiel der Abbildung „SQL-Editor: Partitionierte Tabelleninformationen anzeigen" gibt es drei Partitionen.

Die M_CS_TABLES Systemsicht stellt Laufzeitdaten für Spaltentabellen oder Partitionen von Spaltentabellen bereit.

1
select * from "M_CS_PARTITIONS" where "TABLE_NAME" = 'sap.hana.democontent.epm.data::PO.Item';

Die Ausgabe zeigt, auf welchem Host sich die Partition befindet und wie viel Speicher von der Tabelle verbraucht wird.

Die Systemsicht M_EFFECTIVE_TABLE_PLACEMENT enthält Informationen zum Platzierungsort der Tabelle. Diese Sicht enthält auch Informationen zu den Partitionierungsschwellenwerten. Sie können die gültigen Lokationen gemäß der Konfiguration, die tatsächlichen Werte für jeden Partitionierungsparameter und in den entsprechenden _MATCH-Spalten den Grund (Abgleichsregel) für diese anzeigen.

Die Tabelleninformationen sind auch im SAP HANA Cockpit verfügbar. Suchen Sie in der Anwendung Aktuelle Tabellenverteilung anzeigen nach der gewünschten Tabelle, und wählen Sie sie aus. Wählen Sie im Dialogfenster die Option Laufzeitdaten anzeigen. Auf dem Bild Laufzeitdaten wird standardmäßig die Tabellendefinition angezeigt. Wählen Sie die Drucktaste Partitionen, um eine Übersicht darüber zu erhalten, wie die Tabelle partitioniert ist und wo sich die Partitionen befinden. Das Partitionsintervall wird ebenfalls angezeigt.

Um die Konsistenz für partitionierte Tabellen sicherzustellen, führen Sie bei Bedarf Prüfungen aus und reparieren Sie Anweisungen.

Sie können allgemeine und Datenkonsistenzprüfungen für partitionierte Tabellen aufrufen, um z.B. zu prüfen, ob die Partitionsspezifikation, die Metadaten und die Topologie korrekt sind.