Datenbankanwendungen stellen hohe Anforderungen an das zugrundeliegende Datenbanksystem. Neben einer hohen Verfügbarkeit wird im wesentlichen eine hohe Leistung, d.h. geringe Antwortzeiten, hoher Durchsatz von OLTP-Transaktionen, gefordert. Ferner soll der Zeitbedarf für Administrationsaufgaben wie Backup und Recovery so gering wie möglich sein. Die Erfüllung dieser Anforderungen erweist sich bei sehr großen Datenbanken insbesondere dann als problematisch, wenn die Datenbanken einzelne sehr große Tabellen mit Millionen Einträgen pro Tabelle enthalten. In der Praxis existieren Datenbanken, wo eine einzelne Tabelle Milliarden Zeilen enthält. Solche große Datenbanktabellen begrenzen sowohl bei reinen Lesezugriffen als auch bei Änderungs- und Verknüpfungsoperationen (Join) die Leistung des gesamten Systems. Zusätzlich erhöhen sie den Aufwand für administrative Aufgaben, wodurch die Verfügbarkeit der Daten wesentlich eingeschränkt wird. Die Schwierigkeiten beim Umgang mit sehr großen Datenbanken realisieren also nicht primär aus der Datenbankgesamtgröße, sondern aus dem Vorhandensein einzelner sehr großer Tabellen.
Der Trend zu immer größeren Datenbanken, im hohen Gigabyte- bzw. im Terabytebereich, macht es erforderlich, die Optimierung von Anfragen durch geeignete Techniken zu unterstützen. Ein Ansatz ist im massiven Einsatz von Hardware, insbesondere bei Ausnutzung von Parallelisierungstechniken für die Zugriffe auf Externspeichermedien, zu sehen. Aus Datenbanksicht lassen sich Leistungssteigerungen durch Ausnutzen von Anwendungswissen und vor allem durch einen geeigneten physischen Datenbankentwurf erzielen. Das Wissen über die Anwendung kann etwa in Form von Hinweisen zur Ausführungsstrategie oder durch redundantes Halten von Zwischenergebnissen (materialisierte Sichten) einfließen. Beide Techniken sind statisch und können die Effizienz von Anfragen drastisch steigern. Dagegen erfordern Änderungen der zugrundeliegenden Datenmenge oder der Struktur der Daten ein Umschreiben von Anfragen bzw. ein aufwendiges Neuberechnen der materialisierten Sichten. Materialisierte Sichten erhöhen zudem drastisch den Speicherplatzbedarf. Sowohl materialisierte Sichten als auch die Technik der Hinweise können nur spezielle Anwendungen bedienen. Eine bedeutendere Rolle bei der Anfrageoptimierung kommt dem physischen Datenbankentwurf zu, da Änderungen an diesem keine Auswirkungen auf die Anwendungen haben.
Bei stark wachsenden Datenmengen und typischerweise sehr hohen Anforderungen hinsichtlich Verfügbarkeit und Leistung ist es trotz solcher Techniken schwierig, ein zufriedenstellendes Antwortzeitverhalten zu erhalten. Die Ursache ist darin begründet, dass Anfragen eine so große Datenmenge involvieren, dass herkömmliche Indextechniken und Techniken zur Verteilung von Tabellen über verschiedene physische Speichergeräte allein nicht ausreichend sind. Der Einsatz geeigneter Zugriffsstrukturen, Sekundärindexe, Bitmapindexe etc., kann eine Lösung nähebringen, ist jedoch aufwendig und erfordert zusätzlichen Speicherplatz. Für einige Tabellen sind die Indexdaten bereits um ein Vielfaches größer als die eigentliche Daten. Zudem gestaltet sich die Pflege von Zugriffspfaden sehr aufwendig. Ein interessanter und wissenschaftlich bisher wenig beachteter Ansatzpunkt zur Steigerung des Leistungsverhaltens von Anfragen im Zusammenhang mit der Datenverteilung ist nicht die Verteilung von Tabellen, sondern das Aufteilen, die Partitionierung, insbesondere von großen Tabellen.
Ursprünglich wurden Datenbankdateien partitioniert, wenn sie für eine Festplatte zu groß waren oder die Zugriffsgeschwindigkeit einer einzelnen Platte zu gering war. Das Konzept der Partitionierung wurde in wissenschaftlichen Arbeiten zu verteilten und parallelen Datenbanken auf Datenbanktabellen übertragen und weitergeführt. Besonders sinnvoll ist dieses Vorgehen zum einen, wenn bedingt durch die große Datenmenge bei Anwendungen wie Data Warehousing, wo die Kenntnis über ein spezifisches Benutzerverhalten vorliegt, der Datenzugriff sich auf einen Ausschnitt der Gesamtdatenmenge beschränkt. Dieser Ausschnitt ist i.a. jedoch so groß, dass optimale Ausführungsstrategien einen Tablescan beinhalten, Zugriffspfade also nicht effizient benutzt werden können. Durch eine Partitionierung muss nicht die gesamte Tabelle zur Beantwortung der Anfrage herangezogen werden, es genügen die relevanten Partitionen. Zum anderen ist es mit Hilfe der Partitionierung möglich, bestimmte Anwendungen, wie z.B. die Archivierung, gezielt zu unterstutzen. Der entscheidende Vorteil der Partitionierung besteht also darin, dass aufgrund der Aufteilung einer Tabellen auf mehrere Partitionen Anfragen durch eine Reduzierung des zu durchsuchenden Datenrahmes potentiell profitieren können. Eine Anfrage kann aufgrund der Selektion auf einige wenige Partitionen eingeschränkt werden, oder, wenn dies nicht oder nur begrenzt möglich ist, kann auf den einzelnen Partitionen die Anfrage parallel ausgeführt werden.
Unter einer Partitionierung versteht man eine horizontale, vollständige und transparente Aufteilung einer Datenbanktabelle in disjunkte Teiltabellen (Partitionen). Die einzelnen Partitionen werden dann gezielt physischen Speicherbereichen der Datenbank etwa Table Spaces zugeordnet.
Die horizontale Aufteilung bedeutet, dass die einzelnen Tupel selbst nicht zerlegt werden. Die Vollständigkeit besagt, dass bei der Partitionierung keine Tupel unberücksichtigt bleiben, d.h., jedes Tupel der ursprünglichen Tabelle liegt in einer der Partitionen. Durch die Disjunktheit wird sichergestellt, dass sich die einzelnen Partitionen nicht überlappen. Kein Tupel der Ausgangstabelle kann somit in zwei oder mehr Partitionen liegen. Die Forderung nach Disjunktheit dient dazu, Redundanz und damit verbundenen Probleme zu vermeiden. Da sowohl Vollständigkeit als auch Disjunktheit gefordert werden, gilt, dass jedes Tupel der ursprünglichen Tabelle jeweils in genau einer Partition liegt.. Die Partitionierung kann somit als Funktion aufgefasst werden, die jedem Tupel eine Partition zuordnet.
Bei einer Partitionierung sind grundsätzlich zwei Verfahren möglich, wertebasierte und nicht wertebasierte Verfahren.
Bei einem nicht wertebasierten Partitionierungsverfahren wird die Partition eines Tupels mit Hilfe eines Fremdkriteriums festgelegt, z.B. einer Zufallszahl oder der Reihenfolge des Einfügens eines Tupels. Nicht wertebasierte Partitionierungsverfahren haben den Nachteil, dass die Zuordnung eines Tupel zu einer Partition in der Regel weder wiederholbar noch im Nachhinein nachvollziehbar ist. Die Verwendung solcher Verfahren zielt im Wesentlichen auf eine parallele Anfrageverarbeitung ab.
Dagegen werden in der Praxis größtenteils wertebasierte Partitionierungsverfahren verwandt. Diese berechnen die Partition aus einem oder mehreren Attributwerten des Tupels. Das hat den Vorteil, dass die Zuordnung auch im Nachhinein nachvollziehbar bleibt und somit bei der Anfrageoptimierung berücksichtigt werden kann, da für das DBMS der Speicherort eines Tupel ansprechbar wird.
Man unterscheidet im wesentlichen drei Arten der Partitionierung. Es handelt sich dabei um die Round-Robin-Partitionierung, die Hash-Partitionierung und die intervallweise Partitionierung oder Bereichspartitionierung.
Ein mögliches Partitionierungskriterium für diese Auftragstabelle lautet z.B.: Die Auftragstabelle soll quartalweise nach dem Auftragsdatum partitioniert werden. Dies wird im folgenden (siehe Tabelle 2) veranschaulicht. Die entstandenen Partitionen wurden mit P1, P2, P3 und P4 bezeichnet.
Aus dem Partitionierungskriterium lassen sich die Partitionierungsattribut ermitteln. Letzteres sind diejenigen Attribute, die für eine dem Partitionierungskriterium entsprechende Aufteilung der Tabelle relevant sind. Das Attribut AUFTRAGSDATUM stellt für das obige Beispiel das einzige Partitionierungsattribut dar. Eine sogenannte Partitionierungsfunktion gibt letztendlich an, wie die Tupel konkret auf die einzelnen Partitionen verteilt werden sollen. Aus dem obigen Partitionierungskriterium ergibt sich beispielweise folgende Partitionierungsfunktion f.
Partitionen P1, P2, ,P3, P4 und P5 repräsentieren
dabei jeweils den Bezeichner und den physischen Speicherungsort, bei dem es
sich i. d. R. um einen Tablespace handelt. Bei der
Partition P5 handelt es sich um die Restpartition, die alle übrigen Tupel enthält.
Verzichtet man bei der Definition der Partitionierungsfunktion auf eine solche
Restpartition, muss wegen der geforderten Vollständigkeit sichergestellt sein,
dass jedes Tupel einer Partition zugeordnet werden kann.
Verschiedene Tabellen einer Datenbank können nach verschiedenen Partitionierungskriterium partitioniert werden. Werden zwei Tabellen jedoch nach dem gleichen Partitionierungskriterium partitioniert, spricht man von einer Gleichpartitionierung. Bezogen auf die intervallweise Partitionierung bedeutet dies, dass bei der Partitionierung beider Tabellen die gleiche Aufteilung des Wertebereichs zugrunde gelegt wird. Dies setzt u.a. voraus, dass die Partitionierungsattribute beider Tabellen im Datentyp übereinstimmen.
Wertebasierte Partitionierungsverfahren können nach verschiedenen Strategien vorgenommen werden. Allgemein lassen sich nach der Anzahl der Dimensionen zwei grundsätzliche Partitionierungsstrategien unterscheiden, eindimensional und mehrdimensional.
Eine eindimensionale Partitionierung kann sowohl auf einem als auch auf mehreren Partitionierungsattributen erfolgen. Bei einer einattributtigen Partitionierung wird der Wertebereich des Partitionierungsattributes in fortlaufende Intervalle geteilt. Im Fall einer eindimensionale, mehrattributigen Partitionierungsstrategie wird eine mehrattributige Partitionierung mittels einer eindimensionalen Partitionierung simuliert, d.h. die mehreren Attribute werden zu einem Partitionierungsattribut konkateniert. Dadurch wird der mehrdimensionale Raum letztlich nur eindimensional partitioniert. Dies kann z.B. erzielt werden, wenn die Aufteilung des Wertebereiches nicht für jedes Partitionierungsattribut separat erfolgt, sondern in Abhängigkeit voneinander.
Eindimensionale Partitionierungen sind einfacher zu definieren und zu warten als mehrdimensionale.
Zu einer mehrdimensionalen Partitionierung führt auch die Vorgehensweise, die durch eine Partitionierung bezüglich eines Attributs entstandenen Partitionen bezüglich eines anderen Attributs zu partitionieren. Dabei können entweder alle oder aber nur einige der Partitionen partitioniert werden. Beide Fälle werden anhand des folgenden Beispiels illustriert.
Bei diesem Beispiel zugrunde gelegte Tabelle besitzt die Attribute A und B mit den Wertebereichen dom(A) = {1,2,3,4,5,6} bzw. dom(B)= {1,2,3,4,5,6,7,8,9}. In einem ersten Schritt wurde die Tabelle intervallweise bezüglich A partitioniert. Diese Partitionierung erfolgt so, dass alle Tupel mit einem A-Wert größer als drei in einer und alle Tupel mit einem A-Wert kleiner oder gleich drei in einer anderen Partition lagen. In einem zweiten Schritt wurden nur eine intervallweise Partitionierung bezüglich B durchgeführt. Der Wertebereich von B wurde hierzu in die drei Intervalle {1,2,3}, {4,5,6} und {7,8,9} zerlegt. Bei der Durchführung des zweiten Schritts wurden zwei Fälle unterschieden:
Während die Reihenfolge der Schritte im ersten Fall unerheblich war, ist sie im zweiten Fall entscheidend. Im zweiten Fall ist darüber hinaus auch wesentlich, auf welche der im ersten Schritt erhaltenen Partitionen der zweite Schritt angewendet werden soll. Die Verwaltung der Partitionierungsinformationen ist für den zweiten Fall damit erwartungsgemäß aufwendiger als für den ersten Fall. Dafür bietet ein Vorgehen entsprechend des zweiten Falls aber mehr Freiheitsgrade beim Entwurf des Partitionierungsschemas, die Partitionierung kann zielgerechter erfolgen.
Der wesentliche Vorteil einer mehrdimensionalen Partitionierung liegt darin, dass aufgrund der Partitionierung bezüglich mehrerer Attribute alle Anfragen, die wenigstens eines der Partitionierungsattribute in der Selektion enthalten, von dieser Partitionierung profitieren können. Nachteilig hingegen ist die aus den Freiheitsgraden bei der Definition einer solchen Partitionierung resultierende Komplexität. Eine mehrdimensionale Partitionierung spannt aus multidimensionaler Sichtweise einen Datenraum auf, bei dem mit zunehmender Anzahl der Partitionierungsattribute die Besetzung der einzelnen Partitionen stark nachlässt. Dadurch wird es wahrscheinlich, dass eine Vielzahl von Partitionen so wenig Tupel enthält, dass der Aufwand für die Verwaltung zu teuer ist. Abhilfe hierfür schafft eine partielle mehrdimensionale Partitionierung. Hier steigt jedoch der Verwaltungsaufwand drastisch an.
Mit dem Einsatz der Tabellenpartitionierung ergeben sich auch neue Anforderungen für Zugriffspfade. Dass die Partitionierung auch auf Zugriffspfade ausgedehnt werden muss, ist aufgrund der Nutzung von Parallelität gegeben. Die Vorgehensweise zur Partitionierung von Zugriffspfaden weicht von derjenigen zur Partitionierung von Tabellen ab, da ein Index eine komplexe Struktur ist und nicht wie eine einfache Tupelmenge ohne weiteres in kleinere Einheiten zerlegt werden kann. Stattdessen erfolgt der Aufbau kleinerer separater Teilzugriffspfade.
Wird für jede Tabellenpartition ein separater Index aufgebaut, der alle Tupel referenziert, die diese Partition umfasst, so handelt es sich um einen lokalen Index. Es ist aber auch möglich, dass Indexpartitionen unterschiedlich von den Tabellenpartitionen sein können, d.h., zwischen Indexpartitionen und Tabellenpartitionen existiert eine n:m-Beziehung. Diese Indizes werden als global bezeichnet. Lokal partitionierte Indizes haben den Vorteil, dass die Indexpartitionen aufgrund der eindeutigen Zuordnung zu einer Tabellenpartition identische Partitionierungskriterien aufweisen, wodurch beim Erstellen oder Löschen einer Tabellenpartition automatisch die Indexpartition angelegt bzw. gelöscht werden kann.
Die Definition von Zugriffsstrukturen und deren Partitionierung kann nicht unabhängig von derjenigen der zugrundeliegenden Tabellen erfolgen. Zugriffspfade werden ebenso wie Tabellen gemäß den Werten eines Partitionierungsattributes bzw. mehrerer über eine Hash- oder Bereichsfunktion partitioniert. Die entscheidenden Größen für die Partitionierung von Zugriffspfaden sind die Partitionierungsattribute und der Partitionierungsgrad jeweils im Zusammenhang mit der dem Zugriffspfad zugrundeliegenden partitionierten Tabelle. Das Partitionierungsattribut bestimmt letztlich wie bei der Tabellenpartitionierung, ob eine Datenreduzierung auf dem Zugriffspfad für eine Anfrage möglich ist. Der Partitionierungsgrad, der die Partitionierung zwischen Tabelle und Zugriffspfad charakterisiert, bestimmt die Effizienz. Beide Aspekte beeinflussen die Anfragebearbeitung bezüglich Datenreduzierung und Parallelität unterschiedlich. Eine wesentliche Rolle dabei spielen der Indexschlüssel, das Partitionierungsattribut des Index, das Partitionierungsattribut der Tabelle und die Partitionierungsfunktion bzw. Intervalle.
Der Partitionierungsentwurf beschreibt, wie ein logisches Datenbankschema in ein geeignetes Partitionierungsschema umgesetzt werden kann. Auf Grundlage dieses Partitionierungsschemas können dann konkrete Datenbanken des entsprechenden Datenbanktyps partitioniert werden.
Neben der Auswahl der zu partitionierenden Tabellen müssen beim Partitionierungsentwurf Entscheidungen über die Anzahl der Partitionen, die Verteilung der Tupel oder über die Aufteilung des Wertebereichs der Partitionierungsattribute getroffen werden. Diese Entscheidungen haben dann letztlich einen entscheidenden Einfluss auf die Größe der Leistungsveränderungen gegenüber dem nicht partitionierten Fall. Welches Partitionierungsschema für ein gegebenes Datenbankschema am besten ist, hängt wesentlich vom Zugriffsverhalten auf die Datenbank und somit von den Anwendungen ab. Neben dem Datenbankschema müssen beim Partitionierungsentwurf zusätzlich Anwendungserfordernisse berücksichtigt werden.
Das Festlegen einer geeigneten Partitionierungsstrategie für nur eine einzelne Tabelle ist an sich schon eine komplexe Aufgabe und ist von ähnlichen Anforderungen gekennzeichnet, wie bei der Entscheidung über das Anlegen von Zugriffspfaden. Der Entwurf eines Partitionierungsschemas, das i.a. mehrere Tabellen umfasst, stellt wesentlich komplexere Anforderungen im Vergleich zur Betrachtung einer einzigen Tabelle. Die Schwierigkeit besteht statt dessen darin, mehrere Tabellen, die zueinander in Beziehung stehen, sinnvoll zu partitionieren. Eine tabellenübergreifende Partitionierung ist unerlässlich, da Anfragen häufig Verbundoperationen zwischen Tabellen enthalten. Eine auf jeweils eine Tabelle beschränkte Partitionierung kann bei Anfragen, die die Beziehung zwischen den Tabellen berücksichtigen, dazu führen, dass keine Verbesserungen sondern eine Verschlechterung in der Leistung eintritt. Für die Vorgehensweise beim Entwurf des Partitionierungsschemas gibt es verschiedene Möglichkeiten:
Dieser Vorgang kann beliebig wiederholt werden. Theoretisch kann solange weiter propagiert werden, bis alle Tabellen des Datenbankschemas partitioniert sind.
Das beliebige Wiederholen dieses Propagierungsschrittes ist dann nicht sinnvoll, wenn Tabellen betrachtet werden müssen, die eine Partitionierung aufgrund ihrer Größe bzw. ihres primären Zugriffs nicht rechtfertigen. Die Idee dieser Vorgehensweise besteht im wesentlichen darin, zunächst die aus Anwendungssicht wichtigste Tabelle möglichst gut zu partitionieren. Anschließend wird die hier getroffene Partitionierungsstrategie auf die abhängigen Tabellen übertragen. Welche der Tabellen als die wichtigste Tabelle angesehen wird, hängt vom jeweiligen Verfahren ab. Zum Beispiel könnte die größte Tabelle, also die Tabelle, die die meisten Daten enthält, als die wichtigste Tabelle angesehen werden.
Beginne mit der größten Tabelle
Je nachdem, zu welcher Zeit man die Größen der Tabellen vergleicht, kann man verschiedene Ergebnisse erhalten. Die Eigenschaft, die Tabelle mit dem größten Datenvolumen zu sein, ist somit nicht zeitinvariant. Dies zeigt ein grundlegendes Problem der Strategie, beim Entwurf des Partitionierungsschemas mit der größten Tabelle zu beginnen und sich ausgehen von dieser zu den kleineren Tabellen durchzuarbeiten. Nicht immer steht beim Entwurf des Partitionierungschemas bereits fest, welche Tabelle sich zur Tabelle mit dem größten Datenvolumen entwickeln wird.
Eine entsprechende Strategie beim Entwurf des Partitionierungsschemas wäre, zunächst mit dem Finden einer geeigneten Partitionierung der Bewegungsdatentabellen zu beginnen und sich dann zu den Stammdatentabellen durchzuarbeiten. Die Idee dieses Vorgehens besteht darin, dass es sehr wichtig ist, eine geeignete Partitionierung der Bewegungsdatentabellen vorzunehmen, da mit ihnen am intensivsten gearbeitet wird.
Da die Bewegungsdatentabellen in der Regel auch diejenigen Tabellen sind, die die größten Datenvolumina enthalten, führt diese Strategie oft zum gleichen Vorgehen wie die Strategie, beim Entwurf des Partitionierungsschemas mit der größten Tabelle zu beginnen und sich dann zu den kleineren Tabellen durchzuarbeiten.
Als problematisch erweist sich bei den vorgestellten Verfahren aber der Umstand, dass sich die Partitionierungsidee meist nicht von einer größten Tabelle bzw. Bewegungsdatentabelle auf eine kleinere Tabelle bzw. Stammdatentabelle im Sinne der Gleichpartitionierung übertragen lässt. Dies ist insbesondere dann der Fall, wenn die größere der beiden Tabellen nach einem Attribut partitioniert wird, zu dem es in der kleineren Tabelle keine Entsprechung gibt.
Es ist empfehlenswert, beim Entwurf des Partitionierungsschemas die Beziehungen zwischen den Tabellen von Anfang an zu berücksichtigen. Beziehungen zwischen Tabellen werden i.a. durch tabellenübergreifende Integritätsbedingungen ausgedruckt. Eine Möglichkeit, Beziehungen zwischen Tabellen zu berücksichtigen, besteht somit darin, tabellenübergreifende Integritätsbedingungen beim Entwurf des Partitionierungsschemas auszunutzen. Dabei kann es sich beispielsweise um Fremdschlüsselbeziehung, d.h. um hierarchische Beziehung, handeln.
Tabellenübergreifende Integritätsbedingungen können aber auch in anderen Zusammenhängen zwischen Attributen verschiedener Tabellen zum Ausdruck kommen. Zwischen welchen Attributen Zusammenhänge bestehen, hängt vom konkreten Datenbankschema ab. Sehr oft sind Abhängigkeiten aber zwischen Zeitattributen verschiedener Tabellen anzutreffen. Doch auch zwischen Statusattributen verschiedener Tabellen bestehen oftmals Zusammenhänge, die beim Entwurf des Partitionierungsschemas ausgenutzt werden können. Als Statusattribute gelten hierbei zeitvariante Attribute, die den momentanen Zustand eines Tupels beschreiben. Typischerweise ändert sich dieser Zustand und somit der Wert des Statusattributes im Laufe der Zeit.
Die Partitionierung stellt insbesondere bei sehr großen Datenbanken eine Möglichkeit dar, die Anforderungen Performance, Verfügbarkeit und Administrierbarkeit zu unterstützen.
Eine andere Möglichkeit, die Performance zu verbessern, besteht darin, eine Anfrage gegen eine große Tabelle in mehrere Anfragen gegen jeweils eine Partition zu zerlegen. Diese Anfragen können dann gleichzeitig also parallel, ausgeführt werden. Man spricht in diesem Fall von Intra-Query-Parallelität. Paralleles Lesen ist aber nur dann leistungssteigernd, wenn die Partitionen auf verschiedene physische Plattenlaufwerke verteilt sind. Ist dies nicht der Fall, kann eine parallele Ausführung aufgrund der vielen Positionierungsbewegungen des Speichergerätes sogar leistungshemmend sein. Für das Parallelisieren von Anfragen ist der Optimierer verantwortlich.
Nicht jeder Anfragetyp kann von einer gegebenen Partitionierung profitieren. Eine notwendige aber nicht hinreichende Bedingung dafür, beispielweise einzelne Partitionen bei der Anfragebearbeitung ausblenden zu können, besteht darin, dass das Selektionsprädikat der Anfrage die Partitionierungsattribute enthält. Dies zeigt, dass die Partitionierung auf die Anfragen abgestimmt werden sollte.
Neben einer Verbesserung der Performance erlaubt die Partitionierung auch eine Verbesserung der Administrierbarkeit. Beispielsweise können administrative Aufgaben wie Backup und Reorganisation, die bisher den Stillstand der gesamten Datenbank oder das vollständige Sperren einer Tabelle erzwangen, lokal auf einzelnen Partitionen ausgeführt werden, oder alte, bereits gesicherte Daten müssen nicht wiederholt gesichert werden. Währenddessen können Anfragen, die nicht auf die betroffenen Partitionen zugreifen, ungestört abgearbeitet werden.
Aufgrund der Möglichkeiten, administrative Aufgaben partitionsbezogen ausführen zu können, verbessert sich zugleich die Verfügbarkeit der Datenbank. Lange Transaktionen bzw. Operationen wie z.B. Ladeoperationen oder große Löschoperationen in einem können bei entsprechendem Partitionierungsschema auf einzelne Partitionen ausgeführt werden. Die Folge ist, dass nur wenige Partitionen von eventuellen Datenbanksperren betroffen sind und Operationen, die diese Partitionen nicht benötigen, weiterhin verfügbar sind. Die Verfügbarkeit der einzelnen Partitionen steigt somit an.
Den Vorteilen der Partitionierung stehen aber auch Nachteile gegenüber. So besteht zum Beispiel die Notwendigkeit, ein Partitionierugsschema zu entwerfen. Der Entwurf eines geeigneten Partitionierungsschemas stellt eine sehr komplexe Modellierungsaufgabe dar, die nicht unterschätzt werden darf. Wie bereits geschildert, kann das Partitionierungsschema nicht allein aus dem Datenbankschema abgeleitet werden, stattdessen ist es notwendig, die Anwendungen zu berücksichtigen. Letzteres setzt wiederum sehr detaillierte Anwendungskenntnisse voraus. Da sich das Zugriffsverhalten auf die Datenbank ändern kann, ist es u.U. notwendig, das Partitionierungsschema anzupassen. Dies stellt erneut eine sehr komplexe Modellierungsaufgabe dar, die in absehbarer Zeit nicht automatisch werden kann. Auf der physischen Ebene bedeutet eine Änderung der Partitionierung ferner, dass i.d.R. eine Vielzahl von Daten umkopiert werden müssen. Der Aufwand einer Anpassung des Partitionierungsschemas ist also beträchtlich.
Damit der Optimierer die Partitionierung bei der Anfragebearbeitung nutzen kann, müssen ihm geeignete Partitionierungsinformationen in Form von Metadaten zur Verfügung stehen. Unter anderem müssen im Datenbankkatalog neben den Daten über die einzelnen Tabellen zusätzlich partitionsbezogene Daten verzeichnet sein. Dazu zählen die Partitionierungsattribute ebenso wie die Partitionierungsgrenzen (Intervalle) und die Informationen über die Zuordnung zwischen Partitionen und physischen Speicherbereichen (Tablespace) sowie partitionsbezogene Statistiken. Aus diesen Beschreibungsinformationen zur Partitionierung muss jederzeit ableitbar sein, welche Tupel welcher Partition angehören und welche Partition welchem Tablespace zugeordnet ist. Durch die Partitionierung wird der Umfang der Metadaten somit merklich erhöht, was eine Zunahme des allgemeinen Verwaltungsaufwands nach sich zieht. Bei einem geeigneten Partitionierungsschema ist der durch die Partitionierung entstehende Mehraufwand im Vergleich zum erwarteten Nutzen aber so gering, dass i.d.R. dennoch lohnenswert ist, eine Partitionierung vorzunehmen.
Es werden eine Indexpartition sequenziell gelesen und die Tupel in Sortierreihenfolge verarbeitet. Bei diesem Verfahren können mehrere partitionierte Indexe parallel gelesen werden. Aufgrund der Sortierreihenfolge eines Indexes kann auch ohne Partitionsausschluss bei einer Bereichsanfrage das erste und letzte Tupel des angefragten Bereichs einfach bestimmt werden.
Kann aufgrund des Selektionsprädikates ein Partitionsausschluss durchgeführt werden und ist kein passender Index da oder die Selektivität der Anfrage bezüglich der betrachteten Partition ist schlecht, dann bietet es sich an, eine oder mehrere Partitionen sequenziell zu lesen und die erhaltenen Tupel anhand des Selektionsprädikates zu filtern. Diese Methode gehört zu den Hauptverbesserungen durch Tabellenpartitionierung, da die Indexnutzung nicht immer sinnvoll ist und auf diese Weise dennoch die zu betrachtende Datenmenge verkleinert wird, insbesondere bei vielen Partitionen.
Die Entscheidung, welche Strategie zur Ausführung der Anfrage herangezogen wird, wird vom Optimierer getroffen. Sowohl Index- als auch Tabellenpartitionierung führen zu Leistungsverbesserungen bei der Bearbeitung von Anfragen. Ein Zusammenspiel beider kann diese Effekte noch verstärken.
Wichtig für einen effizienten Einsatz der Partitionierung ist, dass die Anwendung durch bestimmte Anfragemuster geprägt sind. Auf diese Anfragemuster sollte die Partitionierung abgestimmt sein. Werden beliebige Anfragen, die keinem Muster folgen, ausgeführt, können Anfragen leistungsmäßig nicht von einer Partiionierung profitieren; aus Administrationssicht können sich dennoch Vorteile ergeben. Eine Partitionierung kann sowohl für entscheidungsunterstützende Informationssysteme als auch administrativ-betriebswirtschaftliche Anwendungen sinnvoll sein.
CREATE TABLE ...
PARTITION BY RANGE ( Attribut )
(PARTITION Partition1
VALUES LESS THAN Wert1 TABLESPACE Space1,
(PARTITION Partition2
VALUES LESS THAN Wert2 TABLESPACE Space2,
...);
Die VALUES-Klausel ordnet den Tupel der Tabelle anhand des Partitionierungsattributs eine entsprechende Partition zu: gilt für ein Tupel Attribut Wert1 , so kommt es in Partition1, bei Wert1 < Attribut < Wert2 in Partition2 usw.
Die Untersuchungen haben gezeigt, dass die existierende DBMS noch Defizite in bezug auf Partitionierungskonzepte haben. Aber nicht nur die Praxis hat hier noch Nachholbedarf, auch von Seiten der Wissenschaft gibt es noch Klärungsbedarf etwa für verfeinerte und angepasste Algorithmen zur Optimierung, für die Leistungsvorhersage und für eine bessere Administrationsunterstützung. Entsprechende Forschungsarbeiten sind am laufen.