Ausführungspläne und -planoperatoren relationaler Datenbankmanagementsysteme

Abstract

Database Performance, Query Processing and Optimization Allgemeine Bestimmungen weise kritischen Bereichen wie etwa Sortierungen von umfangreichen Zwischenergebnissen. DBMS-übergreifende Werkzeuge zur Ausführungsplananalyse existieren dagegen kaum. Ausnahmen davon beschränken sich auf Werkzeuge wie Toad [2] oder Aqua Data Studio [3]. Diese können zwar DBMS-übergreifend Ausführungspläne verarbeiten, verwenden dazu allerdings je nach DBMS separate Speziallogik, sodass es sich intern ebenfalls um quasi eigene „Werkzeuge“ handelt.

KURZFASSUNG

Ausführungspläne sind ein Ergebnis der Anfrageoptimierung relationaler Datenbankoptimierer. Sie umfassen eine Menge von Ausführungsplanoperatoren und unterscheiden sich je nach Datenbankmanagementsystem auf verschiedene Weise. Dennoch repräsentieren sie auf abstrakter Ebene inhaltlich ähnliche Informationen, sodass es für grundlegende systemübergreifende Analysen oder auch Interoperabilitäten naheliegt einen einheitlichen Standard für Ausführungspläne zu definieren. Der vorliegende Beitrag dient dazu, die Grundlage für einen derartigen Standard zu bilden und stellt für die am Markt dominierenden Datenbankmanagementsysteme Oracle, MySQL, SQL-Server, PostgreSQL, DB2 (LUW und z/OS) ihre Ausführungspläne und -planoperatoren anhand verschiedener Kriterien vergleichend gegenüber.

Kategorien und Themenbeschreibung

1. EINLEITUNG

In der Praxis sind Ausführungspläne ein bewährtes Hilfsmittel beim Tuning von SQL-Anfragen in relationalen Datenbankmanagementsystemen (DBMS). Sie werden vom Optimierer berechnet und bewertet, sodass abschließend nur der (vermeintlich) effizienteste Plan zur Bearbeitung einer SQL-Anfrage benutzt wird. Jeder Ausführungsplan repräsentiert eine Menge von miteinander verknüpften Operatoren. Zusätzlich umfasst er in der Regel Informationen zu vom Optimierer für die Abarbeitung geschätzten Kosten hinsichtlich CPU-Last und I/O-Zugriffen. Auf Basis dieser Daten bewerten DBMS-spezifische Werkzeuge wie beispielsweise der für DB2 for z/OS im InfoSphere Optim Query Workload Tuner verfügbare Access Path Advisor [ 1 ] die Qualität von Zugriffspfaden und geben Hinweise zu möglicher

Sonstige

DB2 15.25% 22.65%

PostgreSQL

28.57% 24.52%

Oracle

MySQL

Abbildung 1: Top 5 der relationalen DBMS Je nach DBMS unterscheiden sich Ausführungspläne und darin befindliche Ausführungsplanoperatoren in verschiedenen Aspekten wie Umfang und Format. Inhaltlich wiederum sind sie sich jedoch recht ähnlich, sodass die Idee einer DBMS-übergreifenden Standardisierung von Ausführungsplänen naheliegt. Der vorliegende Beitrag evaluiert diesen Ansatz. Dazu vergleicht er die Ausführungspläne und Ausführungsplanoperatoren für die Top 5 der in [ 4 ] abhängig von ihrer Popularität gelisteten relationalen DBMS (siehe Abbildung 1) anhand unterschiedlicher Kriterien. Im Detail werden dabei Oracle 12c R1, MySQL 5.7 (First Release Candidate Version), Microsoft SQL-Server 2014, PostgreSQL 9.3 sowie die bedeutendsten DBMS der DB2-Familie DB2 LUW 10.5 und DB2 z/OS 11 einander gegenübergestellt.

Der weitere Beitrag gliedert sich wie folgt: Kapitel 2 gibt einen Überblick über die für den Vergleich der Ausführungspläne und Ausführungsplanoperatoren gewählten Kriterien. Darauf aufbauend vergleicht Kapitel 3 anschließend die Ausführungspläne der ausgewählten DBMS. Kapitel 4 befasst sich analog dazu mit den Ausführungsplanoperatoren. Abschließend fasst Kapitel 5 die Ergebnisse zusammen und gibt einen Ausblick auf weitere mögliche Forschungsarbeiten.

2. VERGLEICHSKRITERIEN

Ausführungspläne und –planoperatoren lassen sich anhand verschiedener, unterschiedlich DBMS-spezifischer Merkmale miteinander vergleichen. Der folgende Beitrag trennt dabei strikt zwischen allgemeinen Plan-Charakteristiken und Operator-spezifischen Aspekten. Diese sollen nun näher erläutert werden.

2.1 Ausführungspläne

Der Vergleich von Ausführungsplänen konzentriert sich auf externalisierte Ausführungspläne, wie sie vom Anwender über bereitgestellte DBMS-Mechanismen zur Performance-Analyse erstellt werden können. DBMS-intern vorgehaltene Pläne und die Kompilierprozesse von Anfragen, bei denen sie erstellt werden, sollen vernachlässigt werden. Einerseits sind sie als inhaltlich äquivalent anzusehen, andererseits sind ihre internen Speicherstrukturen im Allgemeinen nicht veröffentlicht. Für den Vergleich von Ausführungsplänen wurden im Rahmen des Beitrags folgende Kriterien ausgewählt.

Erzeugung bezieht sich auf den Mechanismus, mit dem durch den Anwender Zugriffpläne berechnet und externalisiert werden können. Dies sind spezielle Anfragen oder Kommandos. Speicherung ist die Art und Weise, wie und wo externalisierte Zugriffspläne DBMS-seitig persistiert werden. In der Regel handelt es sich dabei um tabellarische Speicherformen.

Ausgabeformate/Werkzeuge erfassen die Möglichkeit zur Ausgabe von Zugriffsplänen in unterschiedlichen Formaten. Dabei wird zwischen rein textueller, XML- und JSON-basierter, sowie visueller und anderweiter Ausgabe differenziert. Unterstützt ein DBMS ein Ausgabeformat, erfolgt zusätzlich die Angabe des dazu zu verwendenden, vom DBMS-Hersteller vorgesehenen Werkzeugs. Drittanbieterlösungen werden nicht berücksichtigt. Planumfang gibt Aufschluss über im Zugriffsplan verzeichnete generelle Verarbeitungsabläufe. Dahingehend wird verzeichnet, ob Index- und „Materialized Query Table (MQT)“-Pflegeprozesse sowie Prüfungen zur Erfüllung referentieller Integrität (RI) bei Datenmanipulationen im Zugriffplan berücksichtigt werden. Mit MQTs sind materialisierte Anfragetabellen gemeint, die je nach DBMS auch als materialisierte Sichten (MV) oder indexierte Sicht (IV) bezeichnet werden.

Aufwandsabschätzung/Bewertungsmaße bezieht sich auf Metriken, mit denen Aufwandsabschätzungen im Zugriffsplan ausgewiesen werden. Es wird unterschieden zwischen CPU-, I/O- und Gesamtaufwand. Sofern konkrete Bewertungsmaße des DBMS bekannt sind, wie etwa, dass CPU-Aufwand als Anzahl von Prozessorinstruktionen zu verstehen ist, werden diese mit erfasst.

2.2 Ausführungsplanoperatoren

Die Vergleichskriterien für die Ausführungsplanoperatoren gehen über einen reinen Vergleich hinaus. Während einerseits anhand verschiedener Aspekte eine generelle Gegenüberstellung von vorhandenen Operatordetails erfolgt, befasst sich ein überwiegender Teil der späteren Darstellung mit der Einordnung DBMSspezifischer Operatoren in ein abstrahiertes, allgemeingültiges Raster von Grundoperatoren. Dieses gliedert sich in Zugriffs-, Zwischenverarbeitungs-, Manipulations- sowie Rückgabeoperatoren. Sowohl die Operatordetails, als auch die zuvor genannten Operatorklassen werden nachfolgend näher beschrieben. Operatorendetails umfassen die Vergleichskriterien Rows (Anzahl an Ergebniszeilen), Bytes (durchschnittliche Größe einer

Ergebniszeile), Aufwand (in unterstützten Metriken), Projektionen (Liste der Spalten der Ergebniszeile) und Aliase (eindeutige Objektkennung). Es soll abgebildet werden, welche dieser Details allgemein für Ausführungsplanoperatoren abhängig vom DBMS einsehbar sind. Für den Aufwand wird dabei nochmals unterschieden in absoluten Aufwand des einzelnen Operators, kumulativen Aufwand aller im Plan vorangehenden Operatoren (einschließlich dem aktuellen) und einem Startup-Aufwand. Letzterer bezeichnet den kumulativen Aufwand, der notwendig ist, um den ersten „Treffer“ für einen Operator zu ermitteln.

Zugriffsoperatoren sind Operatoren, über die auf gespeicherte Daten zugegriffen wird. Die Daten können dabei sowohl physisch in Datenbankobjekten wie etwa Tabellen oder Indexen persistiert sein, oder als virtuelle beziehungsweise temporäre Zwischenergebnisse vorliegen. Ähnlich dazu erfolgt die Einteilung der Zugriffsoperatoren in tableAccess-, indexAccess-, generatedRowAccess- und remoteAccess-Operatoren. TableAccess und indexAccess bezeichnen jeweils den Tabellenzugriff und den Indexzugriff auf in den gleichnamigen Objekten vorgehaltenen Daten. Unter generatedRowAccess sind Zugriffe zu verstehen, die im eigentlichen Sinn keine Daten lesen, sondern Datenzeilen erst generieren, beispielsweise um definierte Literale oder spezielle Registerwerte wie etwa „USER“ zu verarbeiten. RemoteAccess repräsentiert Zugriffe, die Daten aus externen Quellen lesen. Bei diesen Quellen handelt es sich in der Regel um gleichartige DBMS-Instanzen auf entfernten Servern. Für weitere spezielle Zugriffsoperatoren, die sich nicht in eine der genannten Kategorien einteilen lassen, verbleibt die Gruppe otherAccess. Zwischenverarbeitungsoperatoren entsprechen Operatoren, die bereits gelesene Daten weiterverarbeiten. Dazu zählen Verbund(join), Mengen- (set), Sortier- (sort), Aggregations- (aggregate), Filter- (filter) und Bitmap-Operatoren (bitmap). Spezielle Zwischenverarbeitungsoperatoren, die sich nicht einordnen lassen, werden in einer separaten Kategorie otherIntermediate erfasst. Manipulationsoperatoren sind Operatoren, die geänderte Daten in physische oder auch temporäre Datenbankobjekte schreiben. Abhängig von in SQL standardisierten Manipulationsanfragen erfolgt die grundsätzliche Einteilung in die Operatoren insert, update, delete und merge. Zusätzlich werden auch remoteManipulation-Operatoren unterschieden, die analog dem bereits betrachteten remoteAccess eine Datenmanipulation auf einem fernen Server durchführen. Analog den vorangehenden Operatorklassen werden spezielle, nicht kategorisierbare Manipulationsoperatoren unter otherManipulation geführt.

Rückgabeoperatoren umfassen Operatoren, die die Wurzel eines (hierarchischen) Ausführungsplans bilden. Oftmals repräsentieren diese nochmals den Typ des SQL-Statements im Sinne einer Unterscheidung in SELECT, INSERT, UPDATE, DELETE und MERGE.

3. AUSFÜHRUNGSPLÄNE IN RDBMS

Ausführungspläne sind grundlegende Elemente in der (relationalen) Datenbanktheorie. Damit sind sie zwar allgemein DBMSübergreifend von Bedeutung, unterscheiden sich jedoch im Detail voneinander. So existiert beispielsweise für die im Beitrag gewählten Vergleichskriterien und den daran bewerteten Systemen kein Merkmal, in dem sich alle DBMS in ihren Ausführungsplänen gleichen. Abbildung 2 veranschaulicht die Ergebnisse des Vergleichs, auf die gegliedert nach System nun ausführlicher Bezug genommen wird.

Ausgabeformate/Werkzeuge

Planumfang

Aufwandsabschätzung /Bewertungsmaße

TEXT XML JSON andere grafisch

DBMS_XPLAN.

DISPLAY,

DBMS_XPLAN.

PLAN_TABLE DISPLAY_PLAN

Oracle

(12c R1)

MySQL (5.7)

Oracle [ 5, 6 ]: Ausführungspläne werden in Oracle über die SQLAnfrage EXPLAIN_PLAN erstellt und daraufhin innerhalb einer speziellen Tabelle mit der Bezeichnung PLAN_TABLE gespeichert. Jede Zeile dieser Tabelle enthält Informationen zu einem Planoperator und bildet deren Kombination im Ausführungsplan über die Spalten ID und PARENT_ID ab. Zusätzlich zur Möglichkeit, per SQL-Anfrage Ausführungspläne aus der PLAN_TABLE auszulesen, unterstützt Oracle die Planausgabeformate TEXT, XML und HTML. Diese können jeweils über die im Package DBMS_XPLAN enthaltenen Tabellenfunktionen DISPLAY und deren Erweiterung DISPLAY_PLAN erzeugt werden. Ebenfalls möglich in Oracle ist die grafische Ausgabe von Ausführungsplänen, entweder über das Werkzeug SQL-Developer oder den mächtigeren Enterprise Manager. Hinsichtlich des Planumfangs sind Ausführungspläne in Oracle sehr beschränkt. Weder Indexnoch MV-Prozesse noch RI-Prüfungen werden im Ausführungsplan als Operatoren ausgewiesen und sind damit nur in einem erhöhten Anfrageverarbeitungsaufwand ersichtlich. Aufwände allgemein weist Oracle in allen betrachteten Metriken CPU, I/O und als Gesamtaufwand aus. Während der CPU-Aufwand proportional zu den Maschineninstruktionen und der I/O-Aufwand zur Anzahl gelesener Datenblöcke ausgewiesen werden, existiert für die sich daraus berechneten Gesamtkosten keine Maßeinheit. MySQL [ 7 ]: Ausführungspläne werden in MySQL mittels SQLAnfrage EXPLAIN erstellt und direkt in Tabellenform ausgegeben. Eine explizite Speicherung der Pläne erfolgt nicht. Seit der Version 5.6 besteht auch die Möglichkeit, sich die Ausführungspläne in MySQL Workbench grafisch darstellen oder sie mit erweiterten Details im JSON-Format ausgeben zu lassen. Bei der Planerstellung wird in MySQL die Gültigkeit der Anfrage nicht überprüft, es können also Pläne für Anfragen erstellt werden, die unzulässig sind (beispielsweise kann beim Einfügen der Datentyp falsch sein). Auch bezüglich des Planumfangs zeigt sich MySQL eher rudimentär. Es gibt keine materialisierten Sichten und über Indexpflege oder das Überprüfen referentieller Integrität macht der Plan keinerlei Angaben. Bezüglich der Aufwandsabschätzung weist MySQL CPU-, I/O- und den Gesamtaufwand aus. Microsoft SQL-Server [ 7 ]: Im SQL-Server werden Pläne erst bei ihrer Ausgabe externalisiert. Ein Mechanismus zur reinen Erzeugung und spezielle Strukturen zur Speicherung sind damit nicht nötig und folglich nicht vorhanden. Zur Ausgabe von Ausführungsplänen existieren verschiedene SHOWPLAN SET-Optionen.

Sobald diese aktiviert sind, werden für nachfolgend ausgeführte SQL-Anfragen automatisch Pläne in den Formaten TEXT oder XML erstellt. Eine grafische Ausgabe bietet das Management Studio. Bezogen auf den Planumfang sind Informationen zu sämtlichen betrachteten Prozessen enthalten. Dies gilt analog für die Aufwandsabschätzung, für die CPU-, I/O- und Gesamtaufwand ausgewiesen werden. Maßeinheiten sind allerdings nicht bekannt. PostgreSQL [ 10 ]: Ausführungspläne werden in PostgreSQL mittels SQL-Anfrage EXPLAIN erstellt und ohne explizite Speicherung direkt ausgegeben. Soll der Plan dabei zusätzlich ausgeführt werden, muss dies mittels Schlüsselwort ANALYZE proklamiert werden. Über ein weiteres Schlüsselwort VERBOSE lassen sich besonders ausführliche Informationen abrufen. Auch das Format, in welchem der Plan ausgegeben werden soll, lässt sich mit entsprechendem Schlüsselwort (FORMAT {TEXT | XML | JSON | YAML}) angeben. Eine grafische Ausgabe bietet das Werkzeug pgAdmin. Zu beachten ist zudem, dass PostgreSQL die Gültigkeit der Anfrage beim Erstellen des Plans (ohne Schlüsselwort ANALYZE) nicht überprüft. Bezüglich des Planumfangs macht PostgreSQL keine Angaben über Indexpflege oder die Prüfung referentieller Integrität. Es existieren zwar materialisierte Sichten, diese können aber lediglich manuell über den Befehl REFRESH aktualisiert werden. Für die Aufwandsabschätzung liefert PostgreSQL nur „costs“, deren Einheit die Zeit darstellt, die für das Lesen eines 8KB-Blocks benötigt wird.

DB2 LUW [ 13 ]: Ausführungspläne werden in DB2 LUW über die SQL-Anfrage EXPLAIN erstellt und in einem Set von 20 Explain-Tabellen gespeichert. Für die Ausgabe der darin abgelegten Informationen besteht neben dem Auslesen per SQL-Anfrage nur die Möglichkeit der textuellen Darstellung mithilfe der mitgelieferten Werkzeuge db2exfmt und db2expln. Über das Data Studio und den Infosphere Optim Query Workload Tuner können Ausführungspläne grafisch ausgegeben werden. In ihrem Umfang berücksichtigen Pläne von DB2 LUW zwar die MQT-Pflege und RI-Prüfungen, die Pflege von Indexen jedoch wird nicht dargestellt. Hinsichtlich der Aufwandsabschätzung deckt DB2 LUW als einziges der betrachteten Systeme nicht nur alle Metriken ab, sondern liefert zu diesen auch konkrete Bewertungsmaße. CPUAufwand wird in CPU-Instruktionen, I/O-Aufwand in Datenseiten-I/Os und der Gesamtaufwand in Timerons angegeben. Da letztere eine IBM-interne Maßeinheit darstellen, entkräftet sich allerdings diese positive Sonderrolle wieder.

DB2 z/OS [ 16 ]: In der Erstellung und Speicherung von Ausführungsplänen ähnelt DB2 z/OS dem zuvor betrachteten DB2 LUW. Es wird ebenfalls die EXPLAIN-Anfrage und eine tabellarische Speicherung verwendet. Die Struktur der verwendeten Tabellen ist jedoch grundverschieden. Neben der Variante, DB2-Zugriffspläne direkt aus der tabellarischen Struktur auszulesen, ist lediglich die grafische Planausgabe über separate Werkzeuge wie Data Studio oder den Infosphere Optim Query Workload Tuner möglich. Der Umfang des Ausführungsplans in DB2 z/OS ist sehr beschränkt. Es werden keine der betrachteten Prozesse dargestellt. Die Aufwandsschätzung dagegen umfasst Angaben zu CPU-, I/O- und Gesamtaufwand. Erstere wird sowohl in CPU-Millisekunden als auch in sogenannten Service Units ausgewiesen.

4. PLANOPERATOREN IN RDBMS

Ähnlich zu den Ausführungsplänen setzt sich die Verschiedenheit der betrachteten DBMS auch in der Beschreibung ihrer in weiten Teilen gleichartig arbeitenden Planoperatoren fort. Diese werden in den folgenden Ausführungen gegenübergestellt. Abschnitt 4.1. vergleicht sie anhand der bereits beschriebenen Kriterien. Im anschließenden Abschnitt 4.2. wird eine Kategorisierung der einzelnen Operatoren nach ihrer Funktionalität beschrieben.

4.1 Operatordetails

Auf Basis der in Abschnitt 2.2 beschriebenen Vergleichskriterien ergibt sich für die Operatordetails der miteinander verglichenen DBMS die in Abbildung 3 gezeigte Matrix. Auf eine Darstellung der DBMS-spezifischen Bezeichnungen ist darin aus Kompaktheitsgründen verzichtet worden. Die in der Matrix ersichtlichen Auffälligkeiten sollen nun näher ausgeführt werden. Eine der wesentlichen Aussagen der Matrix ist, dass ein überwiegender Teil an zentralen Details existiert, die von nahezu allen DBMS für Ausführungsplanoperatoren ausgewiesen werden. Dies sind die Ergebniszeilenanzahl (Rows), der kumulative Aufwand, Projektionslisten und Aliase. Andere Details wie die Größe des Zwischenergebnisses (Bytes), der absolute oder der Startup-Aufwand hingegen stehen nur bei einzelnen DBMS zur Verfügung. Bei horizontaler Betrachtung fällt auf, dass kein DBMS alle Detailinformationen bereithält. Stattdessen schwankt der Detailumfang vom lediglich nicht ausgewiesenen Startup-Aufwand beim SQL-Server oder dem einzig fehlenden absoluten Aufwand bei PostgreSQL bis hin zum DB2 z/OS, das nur die zuvor als zentral betitelten Details mitführt.

4.2 Operatoren-Raster

Planoperatoren sind in den betrachteten DBMS verschieden granular ausgeprägt. Damit gemeint ist die Anzahl von Operatoren, die von knapp 60 im SQL-Server bis hin zu etwa halb so vielen Operatoren in PostgreSQL reicht. Trotzdem decken die einzelnen

DBMS, wie in Abbildung 4 auf Basis einer Matrix dargestellt, mit wenigen Ausnahmen die betrachteten Grundoperatoren funktional mit mindestens einem spezifischen Operator ab. Die weiteren Ausführungen nehmen detaillierter Bezug auf die Matrix. Dabei werden aus Umfangsgründen nur ausgewählte Besonderheiten behandelt, die einer zusätzlichen Erklärung bedürfen.

Oracle [ 5, 6 ]: Ausführungsplanoperatoren in Oracle charakterisieren sich durch eine Operation und zugehörige Optionen. Während erstere eine allgemeine Beschreibung zum Operator liefert, beschreiben zweite den konkreten Zweck eines Operators näher. Beispielsweise kann für eine SORT-Operation anhand ihrer Option unterschieden werden, ob es sich um eine reine Sortierung (ORDER BY) oder einen Aggregationsoperator (AGGREGATE) handelt. Allgemein fällt zu den Planoperatoren auf, dass in Oracle viele OLAP-Operatoren wie etwa CUBESCAN oder PIVOT ausgewiesen werden, die sich keinem der Grundoperatoren zuordnen lassen und damit jeweils als otherIntermediate kategorisiert wurden. Besonders ist auch die Tatsache, dass zwar ein REMOTEZugriffsoperator, jedoch kein entsprechender Manipulationsoperator existiert. Ein solcher wird jedoch nicht benötigt, da Oracle ändernde Ausführungspläne stets von der DBMS-Instanz ausgehend erstellt, auf der die Manipulation stattfindet, und gleichzeitige Manipulationen auf mehreren Servern nicht möglich sind. MySQL [ 7 ]: MySQL unterstützt lediglich "Left-deep-linear" Pläne, in denen jedes zugegriffene Objekt direkt mit dem gesamten bisherigen Vorergebnis verknüpft wird. Dies wirkt sich auch auf die tabellarische Planstruktur aus, die mit wenigen Ausnahmen wie etwa UNION RESULT je involvierter Tabelle genau eine Zeile enthält. Operatoren werden darin nicht immer explizit verzeichnet, was ihre Kategorisierung sehr erschwert. Die Art des Datenzugriffs ergibt sich im Wesentlichen aus der „type“-Spalte, welche in der MySQL-Dokumentation mit „join type“ näher beschrieben wird. Als eigentlicher Verbund-Operator existiert nur der „nested loop“-Join. Welche Art der Zwischenverarbeitung zum Einsatz kommt, muss den Spalten „Extra“ und „select_type“ entnommen werden. Manipulationsoperatoren werden in Plänen erst seit Version 5.6.3 und dort unter „select_type“ ausgewiesen. Microsoft SQL-Server [ 8, 9 ]: Im SQL-Server kennzeichnen sich Ausführungsplanoperatoren durch einen logischen und einen physischen Operator. Für die abgebildete Matrix sind letztere relevant, da, wie ihr Name bereits suggeriert, sie diejenigen sind, die Aufschluss über die tatsächliche physische Abarbeitung von Anfragen geben. Charakteristisch für den SQL-Server sind die verschiedenen Spool-Operatoren Table, Index, Row Count und Window Spool. All diesen ist gemein, dass sie Zwischenergebnisse in der sogenannten tempDB materialisieren („aufspulen“) und diese im Anschluss wiederum nach bestimmten Werten durchsuchen. Die Spool-Operatoren sind daher sowohl den Manipulations- als auch den Zugriffsoperatoren zugeordnet worden. Einzig der Row Count Spool wurde als otherIntermediate-Operator klassifiziert, da sein Spulen ausschließlich für Existenzprüfungen genutzt wird und er dabei die Anzahl von Zwischenergebniszeilen zählt. SQLServer besitzt als einziges der betrachteten DBMS dedizierte remoteManipulation-Operatoren, die zur Abarbeitung einer Manipulation bezogen auf ein Objekt in einer fernen Quelle verwendet werden. Zuletzt sollen als Besonderheit die Operatoren Collapse und Split erwähnt werden. Diese treten nur im Zusammenhang mit UPDATE-Operatoren auf und wurden daher ebenfalls in deren Gruppe eingeordnet. Funktional dienen sie dazu, das sogenannte Halloween Problem zu lösen, welches beim Update von aus einem Index gelesenen Daten aufkommen kann [ 10 ]. W T H D F A C B T F

B S F E C O T B E FS SC SC TE T C R B SC TC

CH SE S S

U C A H CAN ,AN ,AN ,CH , ,S B AN N ,

, T E E R G E T D R E U L

, , , XA IX N AN D D O , R U P M C N IP G M IQ ,E S P

T E U R R X E EBA EAM ,P

L , , T Q , TE IN M S

E P R

T , (9 Po .3 s ) tg r e S Q

L S M e q a

t S e ca ira n l i z e , bd cS ito Fu iln an n cn k o

n V S S C a c u T l a b E u n q s se , eu ca S r n c y , a n in re sa Jo M H L N o e po ts g h e e Jo , d i n , A H g H p a ta a p s end tSeh ,e sh

A g g O r p e , S o r t L F im il

t it re

, M In a se te tr r , i a il z e p d a t e e l e t e d S F b c u lin an cn k o it n o

n taM lnO cSa cSa I( B In In In Ind luC Ind luC

n it d d d irae cyS ,Inn ,Inn x|ed apm xSep xSee cxSe xSee trsee cxSe trsee il an ed ed eH o e a e d a d ze , x x ap lo ,k ,n ,k ,n

) se ra ge cS ito Fu ir te n a c se -_ -e no n n

n

S s C can ttan -no cSan eRm euQ eR Se Ind eR cS Ind eRm

m an e m ke xe o , x o teo ,ry te t t o ,

e e S g G d g H A A S H o re ro o a a gg gg tr a r w te s e s ,t ga u A , h re re a h U t W gA g - m M in ,e -gpA ,gg i a ga a uq -n -rge ,te te tch e , ve ft r (5 M .)7 SyQ

L I L O E C N ] A T E

C | N H E so ilf U tr -e isn

g f b fo sU li e ,y r i so U rg gn tr isn uo in g p d - e

x Lo eN iJo M m H

n rge tca sah spo tse ,

e h d , L o g R o w S c a n M n C

a o tca ito cn h n a , t H -e a s h S o r t T F po lit e r , B i t m a p D T D In D Ind luC e a e le lb le ed lee e s te e te x te x te , , re

d eM Tb eM Ind luC a

e s rg le rg x t e e e , re

d U R In eR eD eR p em se d

m le m dow Spo Isn uB Isn O In In Ind luC taB tem isU EPR ISEN

n d d Spoo il,oW ,traTe il,aTbd ,traTeb liIendn xSepo Isxeen Isxeen trseed scahhH rryapo gn ,LECA ,TR l n eb le l o r r - l e xe l, t t ,

, , p ab lip p d p o nd luC U T S U In U C I

d e d ll e s tad le ,t ta x ta ap x te e e e s r , , e e , d

P D A T E E L E T E

L N JO M JO AH JO CU OO SE IN ER IN S IN B SP TED , G , H , E

E U M T IN N C N I IO T A O I N N ER IT N NO SU , O C , SE N TA

C , E - IEV IPV ER PA (C P IN FO CO AN W O EC R O RA IL R N D

T O T S ,TU IEV IITO IRD IITO ITT PDU ECN -EUQ other N | N N N ER A T IV E | TO PX TAO ,TE ,YB ,LA Intermediate P S A ,

N O D R

R ,T ,) | , ,d caeh cked ge ]n -cno -pu e g r d s [w w U re fo ch aR R F F C iito ehd ith reh isn co r e n OW ISTR ILTE UO

R N , ,T

Z w i s c h e n v e r a r b e i t u n g s o p e r a t o r e n M a n i p u l a t i o n s o p e r a t o r e n (1 O 1R le )

A B L

E M R O -E T E S O R T H N C A A O S T N H IO C , S N TA O , E R T B I T M A P ST IN A S T E E R M T E N T M S U E TA PD N T T -E TEA M S D E TA LE indexAccess generatedRow Access remoteAccess otherAccess join set sort aggregate filter bitmap insert update delete merge remote Manipulation other Manipulation t O g R ro p ab cü e e

e k n ra - M PostgreSQL [ 11 ]: Ausführungspläne in PostgreSQL sind gut strukturiert und bieten zu jedem Operator die für ihn entscheidenden Informationen, sei es der verwendete Schlüssel beim Sortieren oder welcher Index auf welcher Tabelle bei einem Indexscan zum Tragen kam. Für die Sortierung wird zudem angegeben, welche Sortiermethode benutzt wurde (quicksort bei genügend Hauptspeicherplatz, ansonsten external sort). Bei Unterabfragen wird der Plan zusätzlich unterteilt (sub plan, init plan). Soll auf Daten einer anderen (PostgreSQL-) Datenbank zugegriffen werden, so kommt das zusätzliche Modul dblink zum Tragen. Dieses leitet die entsprechende Anfrage einfach an die Zieldatenbank weiter, sodass aus dem Anfrageplan nicht ersichtlich wird, ob es sich um lesenden oder schreibenden Zugriff handelt. Auf einen expliziten Ausgabeoperator wurde in PostgreSQL verzichtet. DB2 LUW [ 14 ]: Analog den zuvor betrachteten DBMS zeigen sich auch für die Planoperatoren von DB2 LUW verschiedene Besonderheiten. Mit XISCAN, XSCAN und XANDOR existieren spezielle Operatoren zur Verarbeitung von XML-Dokumenten. Für den Zugriff auf Objekte in fernen Quellen verfügt DB2 LUW über die Operatoren RFD (nicht relationale Quelle) und SHIP (relationale Quelle). Operatoren zur Manipulationen von Daten in fernen Quellen existieren nicht. Diese Prozesse werden im Ausführungsplan gänzlich vernachlässigt. Die Operatoren UNIQUE (einfach) und MGSTREAM (mehrfach) dienen zur Duplikateleminierung. Da sie dabei aber weder Sortier- noch Aggregationsfunktionalität leisten, wurden sie als otherIntermediate eingeordnet. Dort finden sich auch die Operatoren CMPEXP und PIPE, die lediglich für Debugging-Zecke von Bedeutung sind.

DB2 z/OS [ 15 ]: Obwohl DB2 z/OS und DB2 LUW gemeinsam zur DB2-Familie gehören, unterscheiden sich deren Ausführungsplanoperatoren nicht unerheblich voneinander. Lediglich etwa ein Drittel der DB2 LUW Operatoren findet sich namentlich und funktional annähernd identisch auch in DB2 z/OS wieder. Besonders für DB2 z/OS Planoperatoren sind vor allem die insgesamt 5 verschiedenen Join-Operatoren, die vielfältigen Indexzugriffsoperatoren und das Fehlen von Remote-, Aggregations- und Filteroperatoren. Remote-Operatoren sind nicht notwendig, da DB2 z/OS ferne Anfragen nur dann unterstützt, wenn diese ausschließlich Objekte einer DBMS-Instanz (Subsystem) referenzieren. Föderierte Anfragen sind nicht möglich. Aggregationen werden in DB2 z/OS entweder unmittelbar beim Zugriff oder über Materialisierung der Zwischenergebnisse in Form von temporären Workfiles (WKFILE) und anschließenden aggregierenden WorkfileScans (WFSCAN) realisiert. Ein dedizierter Aggregationsoperator ist damit ebenfalls nicht nötig. Filteroperatoren existieren nicht, weil sämtliche Filterungen direkt in die vorausgehenden Zugriffsoperatoren eingebettet sind. 5. ZUSAMMENFASSUNG UND AUSBLICK Der Beitrag verglich die Ausführungspläne und –planoperatoren der populärsten relationalen DBMS. Es konnte gezeigt werden, dass der grundlegende Aufbau von Ausführungsplänen sowie den dazu verwendeten Operatoren zu weiten Teilen systemübergreifend sehr ähnlich sind. Auf abstrakterer Ebene ist es sogar möglich, Grundoperatoren zu definieren, die von jedem DBMS in Abhängigkeit seines Funktionsumfangs gleichermaßen unterstützt werden. Der vorliegende Beitrag schlägt diesbezüglich eine Menge von Grundoperatoren und eine passende Kategorisierung der existierenden DBMS-spezifischen Operatoren vor. Darauf basierend ließe sich zukünftig ein Standardformat für Pläne definieren, mit dem die Entwicklung von Werkzeugen zur abstrakten DBMSunabhängigen Ausführungsplananalyse möglich wäre. Zusätzlich könnte es auch genutzt werden, um föderierte Pläne zwischen unterschiedlichen relationalen DBMS zu berechnen, die über bislang vorhandene abstrakte Remote-Operatoren hinausgehen.

References

6. LITERATUR

[1] International Business Machines Corporation. Solution Brief - IBM InfoSphere Optim Query Workload Tuner , 2014 . ftp://ftp.boulder.ibm.com/common/ssi/ecm/en/ims14099usen/IMS14 099USEN.PDF

[2] Dell Software Inc . Toad World, 2015 . https://www.toadworld.com

[3] AquaFold. Aqua Data Studio - SQL Queries & Analysis Tool , 2015 . http://www.aquafold.com/aquadatastudio/query_analysis_tool.html

[4] DB-Engines. DB-Engines Ranking von Relational DBMS , 2015 http://db-engines.com/de/ranking/relational+dbms

[5] Oracle Corporation . Oracle Database 12c Release 1 ( 12 .1) - Database SQL Tuning Guide , 2014 . https://docs.oracle.com/database/121/TGSQL.pdf

[6] Oracle Corporation . Oracle Database 12c Release 1 ( 12 .1) - PL /SQL Packages and Types Reference , 2013 . https://docs.oracle.com/database/121/ARPLS.pdf

[7] Oracle Corporation . MySQL 5 .7 Reference Manual , 2015 . http://downloads.mysql.com/docs/refman-5.7 -en .a4.pdf

[8] Microsoft Corporation. SQL Server 2014 - Transact-SQL Reference (Database Engine) , 2015 . https://msdn.microsoft.com/de-de/library/bb510741.aspx

[9] Microsoft Corporation. SQL Server 2014 - Showplan Logical and Physical Operators Reference, 2015 . https://technet.microsoft.com/de-de/library/ms191158.aspx

[10] PostgreSQL Global Development Group . PostgreSQL 9 .3.6 Documentation - EXPLAIN , 2015 . http://www.postgresql. org/docs/9 .3/static/sql-explain.html

[11] EnterpriseDB. Explaining EXPLAIN , 2008 . https://wiki.postgresql.org/images/4/45/Explaining_EXPLAIN.pdf

[12] F. Amorim . Complete Showplan Operators, Simple Talk Publishing, 2014 . https://www.simple-talk.com/simplepod/Complete_Showplan_ Operators_ Fabiano_Amorim (without video) . pdf

[13] International Business Machines Corporation . DB2 10 . 5 for Linux , UNIX and Windows - Troubleshooting and Tuning Database Performance , 2015 . http://public.dhe.ibm.com/ps/products/db2/info/vr105/pdf/en_US/ DB2PerfTuneTroubleshoot-db2d3e1051.pdf

[14] International Business Machines Corporation. Knowledge Center - DB2 10 . 5 for Linux, UNIX and Windows - Explain operators, 2014 . http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/ com.ibm.db2.luw.admin.explain.doc/doc/r0052023.html

[15] International Business Machines Corporation . Knowledge Center - Nodes for DB2 for z/OS, 2014 . https://www-304.ibm.com/support/knowledgecenter/SS7LB8_4.1.0/ com.ibm.datatools.visualexplain.data.doc/topics/znodes.html

[16] International Business Machines Corporation . DB2 11 for z/OS - SQL Reference , 2014 . http://publib.boulder.ibm.com/epubs/pdf/dsnsqn05.pdf