Physische Verteilung der Daten im CO-PA
Bei größeren Datenmengen dauern Zugriffe auf die Objektebene (z.B. beim Neuaufbau von Verdichtungsebenen) unter Umständen sehr lange. Da die Standard-Installation des SAP-Systems nicht für die Handhabung großer Datenmengen im CO-PA optimiert ist, besteht gegebenenfalls ein erhebliches Tuning-Potential bei der physischen Verteilung der Daten auf die zur Verfügung stehenden Festplatten.
Die folgenden Informationen sind in jedem Fall bei Einsatz der Releases 2.1 bis 3.0B relevant. Ab Release 3.0C stehen anwendungsunabhängige Verdichtungsebenen zur Verfügung, so daß der Zugriff auf Objekttabelle und Objektebene aus Dialog-Anwendungen heraus die Ausnahme darstellen sollte.
Beim Neuaufbau von Verdichtungsebenen oder bei Betrieb der Recherche im zu Release 2.2 kompatiblen Modus (mit berichtsspezifischen Verdichtungsdaten) wird weiterhin auf Objekttabelle und Objektebene zugegriffen.
Systeme im I/O-bound Zustand
Um die Komplexität einer Standard-Installation nicht zu erhöhen werden die Tabellen CE3xxxx und CE4xxxx eines Ergebnisbereiches xxxx stets im Tablespace PSAPBTABD angelegt. Die zugehörigen Indexe befinden sich im Tablespace PSAPBTABI.
Beim Lesen größerer Datenmengen aus der Objektebene erfolgen viele Zugriffe auf immer wieder gleiche Festplatten. Diese Festplatten befinden sich dann regelmäßig am Rande ihrer Leistungsfähigkeit und stellen daher den begrenzenden Faktor für die Gesamtleistung des Lesevorgangs dar. Die beteiligten Prozessoren befinden sich währenddessen weitgehend im Zustand "idle" oder "wait".
Liegt diese Situation vor, so sagt man, daß sich das System in einem I/O-bound Zustand befindet. Durch Verteilung der Daten auf mehrere Festplatten kann die Gesamtleistung des Systems deutlich erhöht werden.
Eine einfache I/O-verbessernde Maßnahme
Bei Lesevorgängen aus der Objektebene erreicht man in Standard-Installationen typische Leseleistungen von ca. 200.000 Objektebenensätzen pro Stunde. Diese Leseleistung ist weitgehend unabhängig von der eingesetzten Hardware.
Stehen stattdessen vier Tablespaces zur Verfügung (etwa PSAPCE4D, PSAPCE4I, PSAPCE3D und PSAPCE3I), die auf (mindestens) vier verschiedenen Festplatten abgelegt sind, so kann man die Daten der Ergebnisrechnung wie folgt verteilen:
Es ist sinnvoll, die Umparametrisierung mit Hilfe des Datenbank-Utilities (Transaktion SE14) durchzuführen, solange noch keine Daten in die Ergebnisrechnung verbucht wurden. Andernfalls müssen bereits vorhandene Daten vor der Umstellung aufwendig gesichert und anschließend restauriert werden.
Diese mit verhältnismäßig geringem Aufwand realisierbare "kleine Lösung" führt in der Regel zu einer Steigerung der typischen Leseleistung aus der Objektebene auf ca. 500.000 Sätze pro Stunde.
Mehr I/O-Verteilung
Trotz der Leistungssteigerung durch die oben beschriebene einfache Verteilung der Daten werden sich Systeme mit starken Prozessoren in der Regel immer noch in einem I/O-bound Zustand befinden. Weitere Maßnahmen zur Verteilung der anfallenden I/O-Last sind dann sinnvoll.
Wir betrachten hier ausschließlich Striping auf Hardware-Ebene, das in der Regel vom Datenbanksystem transparent unterstützt wird.
Striping von Datafiles
Auf Betriebssystemebene werden Dateien angelegt, die (in kleinen Stückchen) auf möglichst viele Platten verteilt abgelegt werden. Die Idee dabei ist, daß das zufällige Lesen in einer solchen Datei durch die Verteilung beschleunigt wird, weil Kopfpositionierzeiten eingespart oder parallelisiert werden können. Da diese Datei sozusagen in Streifen auf den verschiedenen Platten liegt, spricht man dabei von Striping. Die beteiligten Platten bezeichnet man als Stripeset.
Die auf mehrere Platten verteile Datei wird nun als Datafile beim Anlegen eines Tablespaces verwendet. Das Datenbanksystem sieht den Tablespace dann als eine konsekutive Folge von Blöcken, die für die EXTENTS einer Tabelle verwendet werden. Das Betriebssystem sorgt nun dafür, daß zufällige Lesezugriffe mit hoher Wahrscheinlichkeit auf verschiedene Platten abgebildet werden. Die ‘Streifenbreite’ sollte der Größe der Datenbankblöcke (in der Regel 8 kB) entsprechen.
Striping für Tabellen der Ergebnisrechnung
Die Zugriffe auf die Daten der Ergebnisrechnung, legen es nahe, besonders die Tabellen CE3xxxx und CE4xxxx (und auch deren Indexe) auf stark verteilten Tablespaces abzulegen, damit konsekutive Lesezugriffe in der Recherche möglichst auf verschiedene physische Platten gelenkt werden (und somit quasi-parallelisierbar sind).
Siehe auch
Physische Struktur der Daten im CO-PASie sollten die vier Tablespaces PSAPCE4D, PSAPCE4I, PSAPCE3D und PSAPE3I gleichmäßig über alle zur Verfügung stehenden Platten ‘stripen’, um eine möglichst breite I/O-Verteilung zu erzielen.
Flankierende Maßnahmen
Neben dem Striping sollte noch darauf geachtet werden, daß die physischen Blöcke innerhalb der Tablespaces optimal ausgenützt werden (z.B. bei ORACLE PCTFREE=1 und PCTUSED=99). Außerdem sollten sich die Tabellen jeweils über möglichst wenige Extents erstrecken. Das erfordert eine gewissenhafte Volumenanalyse des erwarteten Datenaufkommens.
Sicherheitsaspekte
Bei Verwendung von Stripesets muß eine besonders gewissenhafte Datensicherung betrieben werden. Bedenken Sie bitte, daß bei Ausfall einer einzigen Platte, auf der ein Teil eines Stripesets abgelegt ist, in der Regel das gesamte Stripeset unbrauchbar wird und aus einer Datensicherung und darauf aufsetzenden Archiv-Logs restauriert werden muß.
Besonders bei Verwendung der oben beschriebenen "ad-hoc-Lösung" (alle Tablespaces über alle Platten stripen) kann dies aufwendig werden.
Die technische Umsetzung der oben gegebenen Empfehlungen wird je nach verwendetem Datenbank- und Betriebssystem variieren.