DE4323947C2

DE4323947C2 - Verfahren zum Steuern von Datenbankabfragen in einem heterogenen, verteilten Datenbanksystem

Info

Publication number: DE4323947C2
Application number: DE4323947A
Authority: DE
Inventors: Weimin Du; Ravi Krishnamurthy; Ming-Chien Shan
Original assignee: Hewlett Packard Co
Current assignee: HP Inc
Priority date: 1992-08-20
Filing date: 1993-07-16
Publication date: 1998-01-29
Anticipated expiration: 2013-07-17
Also published as: GB2269921B; GB9313133D0; US5412806A; GB2269921A; DE4323947A1; JPH06195382A; GB9316517D0

Description

Die vorliegende Erfindung bezieht sich auf ein Verfahren zum Steuern von Datenbankabfragen in einem heterogenen, verteilten Datenbanksystem.

Der Ausdruck "verteiltes Datenbank-Managementsystem", wie er hier angewandt wird, bedeutet ein Computersystem für ein Datenbank-Managementsystem (im folgenden DBMS genannt), das mehrere Computerstandorte umfaßt, von denen jeder mit einer lokalen Datenbank versehen ist, die in einem Nachrichten netzwerk miteinander verbunden sind, in dem ein Anwender an jedem Standort auf Daten zugreifen kann, die an irgendeinem anderen Standort gespeichert sind.

Jeder Standort hat selbst ein DBMS: dieses hat seine eigenen Endgeräte und Anwender, seinen eigenen Speicher und seine eigene CPU, die seine eigene Datenbank und Datenbankverwalt ungsfunktionen (d. h. ein lokales DBMS) arbeiten läßt. Es hat ebenfalls seinen eigenen Datenübertragungsmanager, der die zusätzliche Verantwortung der Steuerung des Austausches von Meldungen mit anderen Standorten in dem gesamten verteilten Datenbanksystem trägt. Zusammengefaßt ist ein verteiltes Datenbank-Managementsystem ein System, in dem einzelne Daten banksysteme von verschiedenen Herstellern stammen können. Das Gesamtsystem wird in der Literatur oftmals als ein heterogenes verteiltes Datenbank-Managementsystem oder HDBMS bezeichnet. Ein HDBMS muß verschiedene Datenbanksysteme mit verschiedenen Datenbankmodellen, Sprachen und Diensten unterstützen.

Ein Beispiel für ein solches System ist in Fig. 1 gezeigt. Das Beispiel stellt ein einfaches verteiltes Banksystem mit zwei Standorten, z. B. einer in Portland, Oregon und einer in Washington, D.C., dar. Selbstverständlich umfassen echte verteilte Systeme normalerweise mehr als nur zwei Standorte. Nehmen wir an, daß Kontounterlagen für das Gebiet von Washington, D.C., in einer lokalen Datenbank an dem D.C.- Standort gespeichert sind, während Kontounterlagen für das Gebiet von Oregon in einer lokalen Datenbank am Standort Portland gespeichert sind. Nehmen wir ferner an, daß die beiden Standorte miteinander verbunden sind, um eine einzel ne "globale" oder verteilte Datenbank zu bilden. Das System verbindet Leistungsfähigkeit der Verarbeitung (die Daten werden nahe an dem Punkt gespeichert, an dem sie am häufig sten benutzt werden) mit erhöhter Zugänglichkeit (es ist möglich, auf ein Washington, D.C.-Konto von Portland, Oregon und umgekehrt über eine Datenübertragungsverbindung zuzu greifen).

Ein Überblick über die Zielsetzung eines verteilten Datenbanksystems

Ein Hauptziel der verteilten Datenbanksysteme ist es, das zu schaffen, was typischerweise Standorttransparenz genannt wird, und bedeutet: Anwender sollten nicht zu wissen brau chen, an welchem Standort irgendein gegebenes Stück Infor mation gespeichert ist, aber sie sollten fähig sein, sich so zu verhalten als ob die gesamte Datenbank an ihrem lokalen Standort gespeichert wäre. Eine Anfrage für einige entfernte Teile von Informationen sollte das System veranlassen, diese Daten automatisch, durch Nachschlagen in dem Systemkatalog zu finden. Der Systemkatalog ist ein Datenverzeichnis und kann selbst als eine Datenbank angesehen werden (eine Systemdatenbank im Gegensatz zu einer Endanwenderdatenbank). Der Inhalt des Kataloges kann als "Daten über Daten" ange sehen werden, d. h. als Beschreibungen von anderen Objekten im System im Gegensatz zu "rohe Daten". Im besonderen sind alle verschiedenen Schemata und Funktionen gespeichert. Der Katalog schließt Datenbanktabellen, Darstellungen, Indizes, Anwender, Anwendungspläne, Zugriffsprivilegien, etc. ein. Zum Beispiel benutzen Optimierer, das ist hier von beson derer Wichtigkeit, Kataloginformationen, um besondere Zugriffsstrategien auszuwählen.

In einem verteilten Datenbanksystem schließt der Systemka talog nicht nur die normalen Katalogdaten, wie oben bespro chen, ein, sondern auch alle notwendigen Steuerungsinforma tionen, um es dem System zu ermöglichen, die in diesem Ab schnitt erwähnte gewünschte Orts-, Aufspaltungs- und Wieder gabetransparenz zu schaffen. Die Vorteile einer solchen Transparenz sind, daß sie die Logik von Anwendungsprogrammen vereinfacht und sie erlaubt es, wenn die Anwendungsmuster wechseln, Daten von einem Standort an einen anderen ohne die Notwendigkeit irgendeiner Neuprogrammierung zu verschieben. Tatsächlich ist die Ortstransparenz nicht mehr als ein anderer Aspekt von physikalischer Datenunabhängigkeit (z. B. Unempfindlichkeit der Anwendungen gegenüber Wechseln in der Speicherstruktur und bei der Zugriffsstrategie), wie das hier angewandte Konzept in dem verteilten Modell.

Ein zweites Ziel des verteilten Datenbanksystemes ist es, Datenaufspaltung zu unterstützen. Ein System unterstützt Datenaufspaltung, wenn ein gegebenes logisches Objekt, z. B. eine komplette Kontodatei, zu Zwecken der physikalischen Speicherung in Teile (Fragmente) geteilt werden kann. Tat sächlich nehmen wir eine solche Unterstützung in unserem Bankbeispiel an, da wir Washington-Kontounterlagen in D.C. und Oregon-Kontounterlagen in Portland speichern. Die Fragmente in diesem Beispiel bestehen aus einer Einschrän kung der gesamten Kontendatei (Relation) nur auf solche Un terlagen, die das Ortsfeld entweder auf "Portland, Oregon" oder "Washington, D.C.", gesetzt haben. Alternativ könnten wir entscheiden, Girokontounterlagen in D.C. zu speichern, während Sparkontounterlagen in Portland gespeichert werden; die Fragmente waren wiederum Einschränkungen. Im allgemeinen könnte ein Fragment jede willkürliche Unterrelation sein, die aus der ursprünglichen Relation durch Einschränkungs operationen erhalten werden kann.

Ein System, das Datenaufspaltung unterstützt, sollte eben falls Aufspaltungstransparenz unterstützen; d. h., daß die Anwender in der Lage sein sollten, sich in allen Fällen so zu verhalten, als ob die Relationen überhaupt nicht aufge spaltet wären (Datenunabhängigkeit). Mit anderen Worten sollte den Anwendern eine Darstellung der Daten gezeigt werden, in der die Fragmente durch passende Verbindungs- und Vereinigungsoperationen miteinander verbunden sind.

Ein weiteres Ziel der verteilten Datenbanksysteme ist es, Datenvervielfältigung und entsprechend Vervielfältigungs transparenz zu unterstützen. Die grundsätzliche Idee hierbei ist es, daß ein gegebenes logische Objekt, z. B. eine ge gebene Kontounterlage, auf einer physikalischen Ebene durch viele verschiedene Kopien desselben gespeicherten Objektes an vielen verschiedenen Standorten dargestellt werden kann. Zum Beispiel könnte ein gegebener Kontodatensatz sowohl in der D.C. -Datenbank als auch in der Portland-Datenbank gespeichert werden. Ein Vorteil einer solchen Anordnung ist es, daß die Wiedergewinnungen an die nächstliegende Kopie geleitet werden kann. Der entsprechende Nachteil ist es, daß Aktualisierungen an alle Kopien weitergeleitet werden müs sen. Vervielfältigungstransparenz bedeutet, daß sich die Anwender nicht über die Vervielfältigungen bewußt sein brau chen, aber in der Lage sein sollten, sich so zu verhalten, als ob jedes logische Objekt durch ein einziges gespeicher tes Objekt dargestellt wird.

Orts-, Aufspaltungs- und Vervielfältigungstransparenz zu sammen bedingen, daß ein verteiltes System für den Anwender wie ein zentralisiertes System aussehen und sich so anfühlen sollte. Jedoch geht die Verwirklichung dieses Zieles nicht ohne Probleme vor sich, im besonderen besteht das Problem der Abfrage-Zugriffs-Optimierung.

Das grundsätzliche Problem

Das grundsätzliche Problem ist es, daß ein verteiltes Daten banksystem eine Ansammlung von Standorten oder Knoten in einem Netzwerk ist und daß Netzwerke, zumindest Netzwerke, die lange Distanzen überwinden, langsam sind. Lange Distan zen überwindende Netzwerke, die geographisch auseinander liegende Standorte verbinden, benutzen Telefonleitungen, auf denen die Datenübertragungsrate typischerweise 50 bis 100 kBit pro Sekunde oder weniger beträgt. Folglich ist es ein vorrangiges Ziel in verteilten Datenbanksystemen, die Anzahl und Größe der Meldungen zu minimieren. Dieses Ziel wirft auf der anderen Seite Probleme in untergeordneten Gebieten und hier im besonderen bei der Abfrageverarbeitung auf.

Das Problem der Abfrageverarbeitung, besonders in der HDBMS- Umgebung, konzentriert sich auf eine Optimierung, die die einzigste, wichtigste Überlegung bei einem Entwurf von ver teilten Systemen ist. Die Optimierung ist der Ablauf, der für eine gegebene Abfrage den optimalen Ausführungs- oder Anwendungsplan feststellt. Ein Optimierer ist eine Haupt unterkomponente des Systemes, die für die Erzeugung eines Anwendungsplanes verantwortlich ist (d. h., die Maschinen codebefehle als SQL-Anweisungen (structured query language = strukturierte Abfragesprache) auszuführen). In dem ver teilten System muß ein Anwendungsplan mehrere Datenbank systeme in einer vernetzten Umgebung mit entsprechenden Anforderungen, wie z. B. der erwähnten Geschwindigkeit der Datenübertragung, in Betracht ziehen. Deshalb ist die Optimierung für die wirksame Abfrageverarbeitung, besonders in der HDBMS-Umgebung, entscheidend. Um die Rolle der Optimierung und das durch die Erfindung gelöste Problem besser zu verstehen, folgt ein kurzer Überblick über die klassische DBMS-Struktur.

Ein Überblick über die klassische DBMS-Struktur

Vom Standpunkt des Anwenders aus gibt es typischerweise vier Komponenten für ein modernes DBMS, nämlich den Vorkompiler, den Verbinder, die Laufzeitüberwachung und einen Manager für gespeicherte Daten. Ein Vorkompiler ist ein Vorprozessor für Anwendungsprogramme, die eingebettete SQL-Anweisungen ent halten. Er sammelt diese Anweisungen in einem Datenbankan forderungsmodul (database reguest module = DBRN) und ersetzt diese Anweisung in dem Originalprogramm durch die Host sprache CALLs in eine Laufzeitüberwachung. Eine Verbinder komponente kompiliert eine oder mehrere zusammenhängende DBRNs, um einen Anwendungsplan (d. h., Maschinencodebefehle, um die SQL-Anweisung in diesen DBRMs auszuführen, ein schließlich Maschinencodeaufrufen an einen Manager für ge speicherte Daten) zu erzeugen. Eine Laufzeitüberwachung überwacht die SQL-Anwendungsprogramme während der Ausfüh rung. Wenn ein solches Programm einige Datenbankoperationen anfordert, geht die Steuerung zuerst an die Laufzeitüber wachung, entsprechend der durch den Vorkompiler eingesetzten CALLs, über. Die Laufzeitüberwachung übergibt die Steuerung dann an den Anwendungsplan und der Anwendungsplan seiner seits startet einen Manager für die gespeicherten Daten, um die gewünschte Funktion auszuführen. Ein Manager für ge speicherte Daten verwaltet die aktuelle Datenbank, speichert Datensätze und gewinnt Datensätze wieder, wie durch den An wendungsplan angefordert. Wenn notwendig, startet er andere Komponenten aus niedrigeren Schichten, um Detailebenen- Fuuktionen, wie z. B. Pufferung der Daten, Verriegelung, Sortieren und dergleichen, während der Ausführung seiner grundsätzlichen Aufgabe auszuführen.

Von einem internen Betriebsstandpunkt aus sind dieselben vier Komponenten in Betrieb, nämlich: bevor der Anwendungs quellcode durch seinen regulären Sprachübersetzer kompiliert werden kann, muß er durch einen Vorkompiler vorverarbeitet werden, um die SQL-Befehlsanweisungen herauszunehmen und die SQL-Befehlsanweisungen durch Aufrufzeilen an die Laufzeit überwachung zu ersetzen; dann wird das herausgenommene SQL, das in einem DBRM gesammelt wird, in einen Anwendungsplan kompiliert, der dann durch die Laufzeitüberwachung jedesmal angewendet wird, wenn sie auf eine CALL-Anweisung einer aus geführten Anwendung trifft. Trotzdem ist ein näherer Blick auf den Verbinderschritt notwendig, um das Problem der Opti mierung zu verstehen.

Wie bereits angedeutet, ist der Verbinder wirklich ein Da tenbankkompiler: er wandelt höhere Datenbankanforderungen, welche tatsächlich SQL-Anweisungen sind, in Maschinencode um. Jedoch ist der Verbinder tatsächlich ein optimier ender Kompiler: die Ausgabe des Verbinders ist nicht nur Maschinencode, sie ist optimierter Code. Die Eingabe in den Verbinder besteht aus einer oder mehrerer DBRMs. Die Ausgabe des Verbinders (d. h. der übersetzte Code, der ein Anwend ungsplan ist) wird im Systemkatalog gespeichert, indem er, wenn durch die Laufzeitüberwachung benötigt, gefunden werden kann.

Eine Hauptunterkomponente des Verbinders ist ein Optimierer. Seine Funktion ist es, für jede verarbeitete SQL-Anweisung eine effiziente Zugriffsstrategie auszuwählen, um die An weisung auszuführen. Es sei daran erinnert, daß Datenmani pulationsanweisungen in SQL, wie z. B. SELECT, nur angeben, welche Daten der Anwender will, nicht wie diese Daten zu erhalten sind. Der Zugriffsweg, um an diese Daten zu ge langen, wird durch den Optimierer ausgewählt. Programme sind folglich unabhängig von solchen Zugangswegen, wobei dies aus Gründen der Datenunabhängigkeit wünschenswert ist. Als ein Beispiel wird die folgende, einfache SELECT-SQL-Anweisung betrachtet:

Sogar in diesem sehr einfachen Fall gibt es mindestens zwei Wege zur Durchführung der gewünschten Wiedergewinnung:

1) durch Durchführung einer physikalischen Folgeabtastung der Tabelle ALEX, bis der Datensatz für 17AUG92 gefunden ist; oder
2) wenn es einen Index auf die ALEX#-Spalte dieser Tabelle gibt, dann durch Anwendung des Indizes und folglich durch direkten Zugriff auf den Datensatz 17AUG92.

Der Optimierer wird auswählen, welche dieser Strategien er griffen wird. Etwas allgemeiner gilt, daß der Optimierer bei irgendeiner gegebenen, bestimmten, zu optimierenden SQL-An weisung seine Strategieentscheidung auf der Basis von Erwägungen, wie z. B.:

- auf welche Tabellen in der Anfrage Bezug genommen wird,
- wie groß diese Tabellen sind,
- welche Indizes existieren,
- wie selektiv diese Indizes sind,
- wie die Daten physikalisch auf der/den Platte(n) gruppiert sind,
- die Form der WHERE-Anweisung in der Abfrage,

usw., treffen wird. Der Optimierer wird dann einen Maschinencode abhängig von der Wahl der Strategie erzeugen. Wenn, z. B. der Optimierer entscheidet, einen existierenden Index, z. B. X, zu verwenden, dann werden Maschinencode befehle in der Anwendung sein, die sich eindeutig auf X be ziehen. Die resultierende Strategie wird oft als Auf wandsmodellierung bezeichnet.

Der Punkt ist, daß es im wesentlichen viele mögliche Strategien zur Verarbeitung einer gegebenen Abfrage geben wird. Zum Beispiel könnte eine Abfrage nach einer Verbindung einer Relation R(a), die am Standort PDX gespeichert ist, und einer Relation R(b), die an einem Standort DC gespei chert ist, dadurch ausgeführt werden, daß R(a) nach DC, R(b) nach PDX oder beide R(a) und R(b) zu einem dritten Standort, LA verschoben werden. Mit anderen Worten könnte es sechs plausible Abfrage-Bearbeitungsstrategien (abhängig von einem bestimmten Satz Annahmen) geben, bei denen die Ant wortzeit irgendwo zwischen einigen Sekunden und einigen Ta gen liegen könnte. Entsprechend wird jede Verarbeitungsstra tegie einen damit verbundenden Aufwand haben. Das Ziel der Optimierung ist dann die Auswahl der Strategie des gering sten Aufwandes.

Eine Optimierung der Abfrageverarbeitung bleibt eine der Hürden für effektive verteilte heterogene Datenbank-Manage mentsysteme (HDBMSs). Immer öfter wird ein verteiltes Daten banksystem in seiner Beschaffenheit eher hetereogen als homogen sein. Mit anderen Worten heißt das, daß jeder Stand ort innerhalb des verteilten Systems seine eigene besondere Art eines Datenbank-Managementsystems haben kann. Wichtig ist, daß der Zugriff auf interne System-Managementdaten bezüglich der Abfrage-Zugriff-Optimierung auf einer lokalen Ebene streng eingeschränkt oder gänzlich unverfügbar sein kann. Dennoch muß eine Endanwenderanwendung, die Daten aus dieser verteilten Umgebung abfragt, in der Lage sein, seine Datenzugriffsstrategien zu optimieren, damit die Datenbankabfrageoperationen über das Netzwerk nicht unan nehmbar langsam werden.

In einem heterogenen DBMS muß der Ausführungsraum erweitert sein, um globale Abfragen über alle seine einzelnen DBMSs zu handhaben. Dies kann einfach durch neue Verbindungsverfahren gemacht werden, die sich über diese DBMSs erstrecken. Des halb können der Ausführungsraum und die Suchstrategien von der Art, wie sie in den existierenden, kommerziellen DBMSs angewendet werden, in einem heterogenen DBMS nur angewendet werden, wenn ein Aufwandsmodell für alle Kategorien von DBMSs in dem heterogenen DBMS zugänglich gemacht wird. Solche Aufwandsmodelle werden bis jetzt durch existierende Systeme nicht geschaffen. Der Haken an dem Problems ist es, ein Aufwandsmodell für jede der DBMSs zu erhalten. Dies schließt die Kalibrierung eines gegebenen, relationalen DBMS und die Ableitung der Aufwandskoeffizienten aus den Auf wandsformeln ein.

In Wirklichkeit läuft es darauf hinaus, daß verteilte Datenbanksysteme schließlich eine hervorragende Zusammen arbeit und Kompromisse unter den Außenstandorten bei der Wahl und der Anwendung eines bekannten Datenbankmanagement systems, das einen solchen operativen Rahmen erfüllt, er fordern. Folglich sind heterogene oder "offene" verteilte Datenbanksysteme, obwohl sehr wünschenswert, typischerweise unpraktisch. Es ist deshalb offensichtlich, daß bestimmte große zusammengeschlossene Computerumgebungen einen hohen Aufwand bezüglich der Systemintegration und in vielen Fällen bezüglich der gänzlichen Umrüstung mit sich bringen.

Entsprechend bleibt ein Bedürfnis an einem heterogenen Abfrage-Optimierungsverfahren, das die traditionelle Opti mierungsstrategie, die allgemein in einem kommerziellen DBMS angewendet wird, erweitert, um die Ausführung von Abfragen sowohl über ein bekanntes DBMS als auch über ein fremdes DBMS in einem heterogenen verteilten Datenbank-Management system zu erlauben.

Aus der EP 0456491 A2 ist bereits ein Managementsystem für eine verteilte Datenbank bekannt. Zur Optimierung des Daten bankzugriffes werden hier die Datenbankwiedergewinnungs zeiten gemessen und gespeichert.

Ausgehend von diesem Stand der Technik liegt der vor liegenden Erfindung die Aufgabe zugrunde, ein effektiv arbeitendes Verfahren zum Steuern von Datenbankabfragen in einem heterogenen, verteilten Datenbanksystem zu schaffen.

Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 gelöst.

Ein Vorteil der Erfindung ist es, daß Datenbankabfragen in verschiedenen Datenbanken mit geringstem Wissen über die physikalische Leistungsfähigkeit oder die funktionalen Modelle für jeden der Datenbankmanager optimiert werden.

Die Erfindung schafft ein Verfahren für ein heterogenes Datenbank-Management system, das ein Abfrage-Optimierungsverfahren verwendet, das eine Optimierung von Datenbankabfragen an verschiedene Datenbanken in einer nahtlosen Art und Weise in DBMSs eines bekannten und/oder fremden Anbieters durchführen kann, die demselben Standard, wie z. B. der Schaffung einer gewöhn lichen relationalen Datenbankstatistik entsprechen. Der Opt imierer kann Datenbankabfragen in verschiedenen Datenbanken ohne Wissen der Leistungsmodelle oder funktionalen Modelle über jeden der Datenbankmanager, die benötigt werden, um optimale Abfragezugriffsstrategien in allen Datenbanken innerhalb des verteilten Netzwerkes zu berechnen, optimieren. Die Erfindung verwendet eine kalibrierende Datenbank, die synthetisch erzeugt wird, um den Vorgang der Ableitung der Aufwandsmodellkoeffizienten im wesentlichen frei von unvorhersehbaren Problemen zu machen. Das bestimmte Aufwandsmodell, das von der Erfindung verwendet wird, macht seine Abschätzungen aufgrund der Anwendung logischer Charakteristika des Abfrageverhaltens und nicht aufgrund physikalischer Aspekte der Abfrageeinrichtungen. Insbe sondere wird der Aufwand einer Abfrage auf der Grundlage der logischen Charakteristika des DBMS, der Relationen und der Abfrage selbst abgeschätzt; der Aufwand von umfangreichen Abfragen wird durch Anwendung einfacher Abfragen abge schätzt.

Die kalibrierende Datenbank wird bei einer Reihe von Be zugspunkten zum Kalibrieren der Koeffizienten der Aufwands formel für irgendein gegebenes relationales DBMS benutzt, ohne Notwendigkeit von Daten des Aufwandsmodells für den lokalen Datenbankabfragezugriff, der streng beschränkt oder gänzlich unverfügbar sein kann. Die resultierenden kali brierenden Aufwandsmodelle werden in einem HDBMS-System katalog für die Entwicklung und Verwaltung nachfolgender Zugriffsstrategien gespeichert.

Die synthetische kalibrierende Datenbank ist derart ausge legt, daß bei einer gegebenen Testabfrage die resultierende Ausführung vorhersehbar ist; d. h., daß der Optimierer die vorausgesagten Zugriffs- und Verbindungsverfahren auswählen wird. Das System kann nicht benutzt werden, um die Konstan ten (z. B. Anzahl der aufgetretenen Eingaben/Ausgaben) des herkömmlichen Aufwandsmodells zu messen. Ferner werden der Aufbau der Datenbank, die Formulierung der Abfragen und das Durchführen der Beobachtungen als ein Anwender-"black-box"- DBMS Verfahren ausgeführt; d. h., daß der Kalibrierungs vorgang nichts über die Verhaltenscharakteristika oder die Aufwandsmodelle eines gegebenen teilnehmenden DBMS zu wissen braucht. Um die Koeffizienten der Aufwandsformeln abzu leiten, ist es deshalb unerläßlich, daß die Abfragen und die Datenbank derart konfiguriert sind, daß die sich ergebende Ausführung vorhersehbar ist; d. h., daß der Optimierer die vorausgesagten Zugriffs- und Verbindungsmethoden aussuchen wird. Auch wenn die Ausführung vorhersehbar ist, muß sie frei von den oben genannten Störungen sein, weil sonst die Feststellung der Ursache des beobachteten Effekts nicht möglich ist. Wenn z. B. alle Tupel mit einem bestimmten Wert eines Attributs gerade auf einer einzelnen Seite sind, dann könnte der beobachtete Wert mißverständlich sein.

Entsprechend liegt ein Vorteil der Erfindung darin, wie oben erwähnt, eine Datenbank und einen Satz Abfragen, die frei von diesen Störungen sind, derart zu erzeugen, daß an schließend die Koeffizienten der Aufwandsformeln exakt abge leitet werden können. Dazu beruht das Datenzugriffaufwandsmodell, das aus dem Kalibrierungs vorgang, der die synthetische Datenbank verwendet, hervor geht, in einem anderen Aspekt der Erfindung derart auf den logischen Informationen der Datenbank, daß die Aufwands koeffizienten als Funktionen dargestellt werden und daß die diesen Koeffizienten zugeordneten Werte, eine Zusammen setzung des Aufwandes bzw. der Kosten der CPU-Benutzung und den Eingabe/Ausgabe-Anforderungen sind.

Ein bevorzugtes Ausführungsbeispiel der Erfindung wird nach folgend unter Bezugnahme auf die bei liegenden Zeichnungen näher erläutert, wobei eine Fallstudie zur Implementierung der Erfindung eingeschlossen ist. Es zeigen:

Fig. 1 ein einfaches Multidatenbankanlagennetzwerk aus zwei oder mehreren Maschinen, die durch digitale Zweiwegdatenübertragungskanäle verbunden sind;

Fig. 2 den Ablauf des Aufbaus einer synthetischen Daten bank und die Anwendung der synthetischen Datenbank auf jeden der teilnehmenden Datenbankmanger in je der Datenbankanlage in dem heterogenen verteilten Datenbanknetzwerk;

Fig. 3 den Ablauf der eigentlichen Kalibrierung der teil nehmenden DBMSs in dem Netzwerk als eine genauere Darstellung von Fig. 2;

Fig. 4 eine Tabelle, die die tatsächlich vorhandenen Ab fragen, die zur Kalibrierung angewendet werden, auflistet;

Fig. 5 eine genauere Darstellung von Fig. 3, wobei der Ablauf des eigentlichen Erhaltens der Aufwands modellkoeffizienten einen zusätzlichen Optimier ungsschritt und die darauffolgende Speicherung der Aufwandsmodelldaten in einem systemweiten Katalog zur zukünftigen Anwendung durch Anwendungspläne umfaßt;

Fig. 6 eine Beschreibung der Aufwands- und Verbindungsfor meln, die in der Fallstudie, die eine Ausführung der Erfindung in einer Testumgebung ist, angewendet wird;

Fig. 7 eine Tabelle der Werte für die sechs wichtigsten Attribute der vierten Relation (R₄) in dem Kalibrierungsmodell, das in der Fallstudie, die die Erfindung ausführt, angewendet wird;

Fig. 8 eine Definiton des i-ten Tupel in R_n und der Werte der entsprechenden Attribute, die in dem ver wendeten Kalibrierungsmodell der Fallstudie, die die Erfindung ausführt, angewendet werden;

Fig. 9 eine Tabelle der Kalibrierungsrelationen, die in dem verwendeten Kalibrierungsmodell der Fallstudie, die die Erfindung ausführt, angewendet werden;

Fig. 10 eine Tabelle der SQL-Testabfragen, die in dem ak tuellen Kalibrierungsablauf der Fallstudie, die die Erfindung ausführt, benutzt werden;

Fig. 11 eine Tabelle der Werte der Aufwandsformelkoef fizienten, die für Allbase, DB2 und Informix RDBMS- Systeme der Fallstudie, die die Erfindung ausführt, angewendet werden;

Fig. 12 eine komplette Liste aller SQL Testverbindungsab fragen, die in der Fallstudie, die die Erfindung ausführt, verwendet werden;

Fig. 13 ein Graph der abgelaufenen Zeit der Testabfragen, die auf den DB2 RDBMS den spezifizierten Beziehun gen und ihren Testverbindungen ablaufen, die in der Fallstudie, die die Erfindung ausführt, verwendet werden;

Fig. 14 eine graphische Analyse des Vergleiches zwischen dem vorbestimmten Wert und den beobachteten Werten für die Verbindungsabfragen nach Typ 3.1, die in der Fallstudie verwendet werden; und

Fig. 15 und 16 zwei graphische Analysen, die den Vergleich zwi schen dem vorhergesagten und dem beobachteten Auf wand der Testabfragen gegen das DB2 RDBMS dar stellt, das in der Fallstudie verwendet wird, die die Erfindung ausführt.

Ein verteiltes Computerdatenbanknetzwerk 10, vergleiche Fig. 1, hat ein Anfordererdatenbankanlagensystem 11 und ein oder mehrere Datenbankanlagensystem(e) 12. Die Konfiguration stellt z. B. ein einfaches verteiltes Banksystem mit zwei Standorten, einen in Portland, Oregon und einen in Washington, D.C., dar. Bei der Erfindung funktioniert sowohl ein Netzwerk, das nur ein lokales Gebiet umfaßt, als auch ein Netzwerk, das weit auseinanderliegende Gebiete verbin det; zum Zweck dieser Beschreibung nehmen wir an, daß das verteilte Netzwerk eine weit verbreitete Übertragungsein richtung mit Anlagen in verschiedenen Städten ist.

Abfragezugriffe in diesem mit einem Netzwerk verteilt ange ordneten Datenbanksystem machen Gebrauch von einem An fordereranlagensystem 11 mit dessen Datenbankmanger 13, des sen eigenen Suchdatenbanken 14, und ein oder mehrere andere Anlagensysteme 12 und senden ein Suchergebnis an einen An forderercomputer 16. Hochgeschwindigkeitsübertragungsein richtungen zwischen den Anlagen können durch verschiedene Einrichtungen 18 ausgeführt werden, die von einem Standard- Ethernet-Netzwerk für den örtlichen Bereich mit 10 Megabit pro Sekunde bis zu einer Langstreckendatenübertragungs einrichtung, die Daten über große Entfernungen mit Raten von 50 bis 100 Kilobit pro Sekunde übertragen, reichen. Das System 10 wird als heterogen angesehen, wenn die einzelnen lokalen Datenbanken durch getrennte und verschiedene Unter systeme, die Datenbankmanger 13, 13A, etc. genannt werden, deren einzige verbindende Einrichtung eine standardmäßige strukturierte Abfragesprache (SQL = structured query language) ist, verwaltet werden. Das beabsichtigte Ergebnis ist es, daß die Informationsdatenbank, obwohl sie auf viele Anlagensysteme, die vielleicht geographisch verstreut sind, verteilt ist, als ein nahtloses großes System erscheint. Die Anlage verbindet und getrennte Komponenten sind deshalb transparent.

Die vorliegende Erfindung erlaubt es diesem heterogenen ver teilten Datenbanksystem 10, eine unbeschränkte Anzahl von Datenbankabfragen von einer unbeschränkten Zahl teilnehmend er Computer 17 anzunehmen, wobei die Abfragen an die Gesamt datenbank, wie sie durch die Architektur verteilt ist, ge richtet werden. Überdies schafft die vorliegende Erfindung die Möglichkeit, Daten in einem Multianlagen-, Multidaten banknetzwerk unabhängig von der Art oder von bestimmten Nuancen des individuellen Datenbankmanagementuntersystems 13, 13A, etc. zu speichern, zu erhalten und zu modifizieren. Das im Folgenden detailliert beschriebene System ist eine erheb liche Verbesserung gegenüber dem Stand der Technik, weil zum ersten Mal Datenbankmanager von einer Vielzahl von Herstel lern miteinander kombiniert werden können, um ein nahtloses großes Datenbankmanagementnetzwerk mit annehmbarem, wenn nicht exzellentem, Verhalten bezogen auf den Aufwand der Abfragezugriffe über diese sich unterscheidenden Datenbank managementsysteme zu bilden.

Systemüberblick

Der Ablauf der Kalibrierung, vergleiche Fig. 2, erfordert zuerst den Aufbau einer synthetischen Datenbank 20, die verwendet wird, um Abfrageverfahren für alle Datenbankmana ger 13, 13A, etc. innerhalb des in Fig. 1 dargestellten Systems 10 zu kalibrieren. Die synthetische Datenbank kann auf irgendeiner Maschine aufgebaut sein und wird einmal an gewendet, um die Aufwandsmodelle, die mit dem Zugriff auf Daten durch jeden der Datenbankmanager verbunden sind, herzuleiten. Die Datenbank 20, auch als eine kalibrierende Datenbank bezeichnet, kann für zukünftige Anwendung, sollte z. B. ein neues DBMS zu dem Netzwerk hinzugefügt werden, ge speichert werden. Die Datenbank 20 befindet sich auf jedem Anlagensystem 12, vergleiche Fig. 1, und eine Kalibrierung 24 wird gegen die Datenbank durch jeden lokalen Datenbank manger 13, 13A, etc., vergleiche Fig. 1, unter Verwendung von Abfragen in der standardmäßig strukturierten Abfrage sprache durchgeführt. Die Verfahrensergebnisse der Kalibrierung werden für zukünftige Anwendung durch Anwend ungsprogramme, die Datenzugriff auf irgendeine der teil nehmenden Datenbankanlagen benötigen, behalten.

Die synthetische Datenbank

Eine synthetische Datenbank 30, vergleiche Fig. 3, wird aufgebaut, um die Koeffizienten der Aufwandsformel für die relationalen DBMSs 13, 13A, etc., vergleiche Fig. 1, zu kalibrieren. Wie oben beschrieben, wird diese synthetische Datenbank durch jedes der teilnehmenden DBMSs aufgebaut und abgefragt. Dieser Ablauf ist in seiner Natur iterativ und richtet der Reihe nach eine Reihe von Abfragen an jedes DBMS gegen die synthetisch hergestellte Datenbank, die zeitweise die normale Datenbank zu Kalibrierungszwecken ersetzt. Metrische Aufwandswerte (z. B. die abgelaufene Zeit) der Ab fragen werden beobachtet, um die Koeffizienten herzuleiten.

Die synthetische Datenbank wird geschaffen, indem es einer ganzen Zahl "n", R_n erlaubt wird, eine Relation von sieben Spalten mit 2ⁿ Tupels zu sein. Die sieben Spalten haben die folgenden Attribute:
C₁: eine ganze Zahl [0,n], indiziert und gruppiert;
C₂: eine ganze Zahl [0,2ⁿ-1], indiziert, defacto gruppiert aber nicht für die DBMS als solche spezifiziert;
C₃: eine ganze Zahl [0,n], indiziert ungruppiert;
C₄: eine ganze Zahl [0,n], kein Index;
C₅: eine ganze Zahl [0,2ⁿ-1], indiziert ungruppiert;
C₆: eine ganze Zahl [0,2ⁿ-1], kein Index; und
C₇: eine lange Buchstabenkette, um der Größe der Tupelan forderung zu entsprechen.

Der Wert des siebten Attributs ist ein Ausfüllfeld und kann auf irgend einen Wert gesetzt werden und wird deshalb der Einfachheit halber beim Rest der Beschreibung ausgelassen.

Der Multispaltenschlüssel der Relation ist (C₁, C₂). Diese Relation ist auf diesem Schlüssel in ansteigender Rei henfolge indiziert, wobei C₁ der Hauptschlüssel und C₂ der untergeordnete Schlüssel ist. Dieser Index ist derart gruppiert, daß die Werte des Hauptschlüssels gruppiert sind. Die Werte des untergeordneten Schlüssels (d. h. C₂) sind ebenfalls gruppiert. Tatsächlich sind die Werte in C₂ einmalig und haben 2ⁿ Werte in dem Wertebereich [0,2ⁿ-1] und deshalb können diese Werte ebenfalls in ansteigender Reihenfolge sein. Deshalb kann die Spalte C₂ als eine Folge nummer für die Reihen angesehen werden. Dieser C₂-Wert wird als Zeilenindex bezeichnet. Der Bedarf an dem Multispalten schlüssel und Index ist derart, daß die Tupels auf der Plat tenseite basierend auf C₂ angeordnet werden und daß das System darüber informiert wird, daß C₁ einen gruppierten Index hat (siehe auch die weiter unten geschilderte Fall studie).

Anwendung der synthetischen Datenbank

Wiederum bezugnehmend auf Fig. 3 (nachdem eine Datenbank entsprechend der obigen Beschreibung erzeugt wurde), wird die Datenbank nachfolgend in jedem der teilnehmenden DBMSs 13, 13A, etc. in Fig. 1, Bezugszeichen 32, als ein vorüber gehender Ersatz der regulären Datenbanken 14 aufgestellt.

Eine Testfolge von Abfragen 33 wird gegen die synthetische Datenbank in jedem DBMS 13, 13A, etc. in Fig. 1 durchge führt. Die erhaltenen Verhaltensdaten (z. B. abgelaufene Zeit) 34 werden in einem systemweiten Katalog 36 gespeich ert. Bei dem bevorzugten Ausführungsbeispiel ist die Kali brierung derart eingestellt, daß meistens einzelne Tabellen abfragen verwendet werden. Dies erfolgt nicht nur, weil die Verbindungsabfragen zeitaufwendig sind und deshalb zu lange dauern, um das System zu kalibrieren, sondern auch weil der Aufwand der meisten Verbindungsabfragen durch Verwendung des Aufwandes der Einzeltabellenabfragen abgeschätzt werden kann.

Es gibt 16 Relationen, die bei diesen Kalibrierungen benutzt werden (siehe die Fallstudie). Jeder Typ der Relation wird mit zwei Größen von Tupels dargestellt und die kleinere Tup lebeziehung wird vervielfältigt. Diese Vervielfältigung wird benötigt, da die Verbindungsabfragen zwei identische Rela tionen benötigen. Die tatsächlichen Abfragen, die in der Ka librierung benutzt werden, sind in Fig. 4 gegeben, wobei R_n eine Tabelle der Kardinalswerte 2_n ist und c eine Konstante, die die Selektivität festlegt, ist. Für jeden Typ der Ab frage gegenüber R_n wird ein Satz Abfragen mit der Selekti vität 2^-i (wobei i = 1, 2, . . ., n) aufgebaut und betrachtet.

Für jede Abfrage 40, vergleiche Fig. 5 Bezugszeichen 42, wird die abgelaufene Zeit in dem DBMS aufgezeichnet. Die abgelaufene Zeit wird durch Abzug der Startzeitmarke (wann die Abfrage empfangen wurde) von der Endzeitmarke (wann die Ergebnisse abgeschickt wurden) berechnet. In allen DBMSs werden die Abfragen aufgestellt, nachdem alle Puffer ent leert wurden, um eine Verzerrung aufgrund der Pufferung aus zuschließen. Jede Abfrage wird dreißigmal ausgegeben und die durchschnittliche Ablaufzeit wird berechnet. Der relative Fehler zwischen den tatsächlichen Daten und den - Durch schnittswerten liegt innerhalb von 5% bei einem Vertrauens koeffizienten von 95%. Folglich ist die Wiederholbarkeit der Beobachtung gesichert. Aus diesen Daten in 42 können die Koeffizienten für die Aufwandsformeln hergeleitet werden. Eine Anpassung nach dem Algorithmus des kleinsten quadrat ischen Fehlers wird angewendet, um irgendwelche Fehler zu minimieren und die Koeffizienten zu bestimmen (vgl. Schritt 44).

Die resultierenden Aufwandsdaten 34 aus Fig. 3 werden dann zu dem Systemkatalog als ein Teil des Aufwandsmodells hin zugefügt. Das Aufwandsmodell schließt Datenzugriffsaufwand informationen über die Übertragungszeit zwischen den Daten bankanlagen über ein Übertragungsnetzwerk ebenso ein wie Aufwandsdaten, die die Operationen der CPUs und der Ein gabe/Ausgabestrukturen der Datenbankanlagen betreffen. Das Aufwandsmodell ist so strukturiert, daß entsprechend der logischen Ausführung der Datenbankanfragen und der Bestim mung des Aufwands einer gegebenen Abfrage basierend auf logischen Charakteristika der DBMS, an die eine Abfrage gerichtet ist, Relationen zwischen den gespeicherten Daten in-der relationalen Datenbank und der Struktur der Abfrage abgefragt werden. Der Aufwand einer umfangreichen Abfrage wird durch einen Satz einfacher Abfragen bestimmt. Alle nachfolgenden Multidatenbankanfragen können sich nun auf die Aufwandsinformationen des netzwerkweitem Systemkataloges, die durch den Kalibrierungsprozeß hergeleitet wurden, um optimierte Abfragen und akzeptable, wenn nicht excellente, Leistung zu sichern, verlassen.

Eine Ausführung von Multidatenbankabfragen wird durch Definition eines Raumes für Ausführungen einer Datenbank abfrage, die z. B. eine Fernverbindung über die einbezogenen Datenbank-Managementsysteme einschließt, ausgeführt. Eine Abfragezugriffsstrategie, die eine Relation, die ein Tupel variabler Größe einschließt, und eine Anzahl von Selektions- und Projektionssätzen einbezieht, wird aufgebaut. Ein log isches Aufwandsmodell, wie es als nächstes beschrieben wird, wird benutzt, um den Aufwand der Strategie als eine lineare Funktion der Größe der Tupel und als lineare Funktionen der Selektions- und Projektionssätzen abzuschätzen.

Das logische Aufwandsmodell

Innerhalb der HDBMS Umgebung werden DBMSs typischerweise als übereinstimmend bezeichnet, wenn sie in Entwurf und Struktur vergleichbar sind und eine mehr oder weniger standardmäßige Abfragefunktionalität haben, d. h. eine standardmäßige strukturierte Abfragesprache (SQL) benutzen; und bekannte Aufwandsmodellmaßstäbe wie, z. B. Zugriffstatistiken, ver wenden. Die Brauchbarkeit der synthetischen Datenbank und des entsprechenden Kalibrationsvorganges wird durch die Existenz eines Aufwandsmodelles, das auf das gesamte Netz werk von übereinstimmenden verteilten Datenbank-Management systemen und nicht nur auf eine spezielle DBMS angewandt wird, gewichtet. Das Systemsubjekt dieser Erfindung benutzt ein neuartiges logisches Aufwandsmodell derart, daß die Ab schätzung einer gegebenen Abfrage sich auf logische Charak teristika des Abfrageverhaltens und nicht auf physikalische Aspekte der Abfrageeinrichtung stützt.

Das logische Aufwandsmodell sieht den Aufwand auf der Grund lage der logischen Ausführung der Abfrage. Es gibt zwei Aus wirkungen. Erstens wird der Aufwand einer gegebenen Abfrage basierend auf logischen Charakteristika der DBMS, den Rela tionen und der Abfrage selbst abgeschätzt. Zweitens wird der Aufwand komplexer Abfragen (z. B. verschachtelte Schleifen verbindungen) durch Anwendung einfacher Abfragen (z. B. Ein zeltabellenabfragen), wie vorhergehend in der synthetischen Datenbankstruktur beschrieben, abgeschätzt.

Dieses Aufwandsmodell konzentriert sich darauf, den Aufwand an Auswahl- und Verbindungsoperationen (siehe Fallstudie) abzuschätzen. Formal wird bei zwei gegebenen Relationen r₁ und r₂ mit N₁ und N₂ Tupels der Aufwand der folgenden zwei Operationen abgeschätzt:

- eine Auswahloperation auf r₁ mit der Selektivität S; und
- eine Verbindungsoperation auf r₁ und r₂ mit der Se lektivität J.

Diese Operationen stützen sich auf die folgenden Annahmen:

- Die Größe der Tupels wird als fest angenommen.
- Es gibt genau eine Auswahl/Verbindungsbedingung bei der Operation.
- Das gesamte Tupel wird auf die Antwort projiziert.
- Alle Attribute sind ganze Zahlen.

Folglich kann die sich ergebende Aufwandsformel als eine Summe der folgenden drei unabhängigen Komponenten angesehen werden:
Komponente₀: Initialisierungsaufwand
Komponente₁: Aufwand zum Finden der entsprechen den Tupels
Komponente₂: Aufwand, um die ausgewählten Tupels zu verarbeiten.

Komponente₀ ist der Aufwand zur Verarbeitung der Abfrage und zum Beginn der Suche. Dies ist die Komponente, die abhängig von dem DBMS ist, aber unabhängig von der Relation oder der Abfrage. Im Fall einer Folgeabtastung besteht Komponente₁ aus einer sperrenden Anforderung, der "get-next" Operation, aus amortisierten Eingabe/Ausgabeaufwendungen und aus all den anderen Anforderungen, die bei er Suche pro Tupel auf tauchen. Die feste Größe der Tupel sichert, daß die Anzahl der Seiten, auf die zugegriffen wird, direkt proportional der Anzahl der Tupels ist. Folglich ist der Aufwand pro Tupel eine Konstante.

In allen Fällen einer Indexabtastung ist Komponente₁ der anfängliche Indexnachschlageaufwand. In allen Fällen einer Indexabtastung wird angenommen, daß Komponente₁ unabhängig von der Relation ist. Dies ist nicht wahr, wenn die Zahl der Ebenen in dem Indexbaum von der Größe der Relation abhängig ist. Aber es ist aufgrund der vielen Verzweigungen eines typischen B-Baumes oder jedes anderen Indizierungsmechanis mus nicht wahrscheinlich, daß sich diese Zahl bedeutend unterscheidet.

Komponente₂ ist der Aufwand zur Verarbeitung jedes der aus gewählten Tupels. Dieser Komponentenaufwand ist aufgrund der Selektions- und Projektionsannahmen, die oben gemacht wur den, wahrscheinlich ebenfalls eine Konstante.

Die Verbindungsformeln sind Ableitungen aus den verschach telten Schleifen- und geordneten Mischabläufen. Sie sind aus Sektionsaufwandsformeln mit bestimmten Einstellungen, um Operationen (z. B. Sortieren und Mischen) und bestimmten Pro blemen, die bei Verbindungsoperationen auftreten (z. B. Puf ferungseffekt) , zusammengesetzt. Zum Beispiel wird der Auf wand zum Zugriff auf eine Relation in der innersten Schleife auf dieselbe Art und Weise modelliert wie der Zugriff auf eine Relation in der äußersten Schleife. Dies ist nicht der Fall, wenn die innersten Relationen gepuffert sind, um die Eingabe/Ausgabe zu verhindern. Wenn eine Folgeabtastung in der innersten Schleife der Verbindung benutzt wird, kann der Eingabe/Ausgabeaufwand aufgrund der Pufferung nur einmal (für kleine Tabellen) auftreten, während das Nachschlagen in der Tabelle für jeden Tupel in der äußersten Schleife durchgeführt wird. Um dies handzuhaben, wird die Komponente₁ in zwei Teile in den Formeln für Folgeabtastung aufgeteilt. Diese zwei Teile stellen den Eingabe/Ausgabe- und den CPU-Aufwand der "get-next"-Operation dar.

Damit das logische Aufwandsmodell effektiv ist, muß beachtet werden, daß bei Veränderung der Größe der Tupels, die Kon stanten beeinflußt werden. Besonders der CPU-Aufwand zur Verarbeitung jedes Tupels der Relation zusammen mit dem amortisierten Eingabe/Ausgabe-Aufwand beim Holen jedes Tupels der Relation wird beeinflußt werden und wahrschein lich linear mit der Größe der Tupel ansteigen, unabhängig davon, ob das Tupel ausgewählt ist oder nicht. Alle anderen oben beschriebenen Konstanten sind Komponentenaufwendungen für ausgewählte Tupels und es ist deshalb nicht wahrschein lich, daß die beeinflußt werden. Trotzdem werden diese Kon stanten durch die Anzahl der Selektions- und Projektions sätze beeinflußt.

Die Neuartigkeit dieses Aspektes der Erfindung ist die Neu definition von typischen DBMS Aufwandsmodellkonstanten als Funktionen mit den folgenden Überlegungen:

- der Aufwand für das anfängliche Nachschlagen des Indizes ist eine lineare Funktion der Größe der Tupels in der Relation; und
- der Aufwand zur Verarbeitung eines Ergebnistupels bei Folgeabtastungen und die Verarbeitung jedes Tupels, das durch einen Index ausgewählt wurde, einschließlich des Eingabe/Ausgabeaufwands, um das Tupel zu holen, wenn notwendig, sind lineare Funk tionen der Anzahl der Auswahls- und Projektions sätze.

Nachdem diese Werte nicht länger konstant sind, werden sie als Koeffizienten bezeichnet. Die jeweiligen Koeffizienten erfassen die Verarbeitungs-, Indizierungs- und Seitenadres sierungs-Charakteristika jedes Datentyps (siehe Fallstudie).

Die fundamentale Grundlage für dieses logische Aufwandsmo dell ist es, daß der Aufwand aufgrund der Berechnung der Ko sten auf einer "pro-Tupel-Grundlage" in der logischen Verar beitung der Abfrage berechnet werden kann. Die Koeffizienten sind alle zusammengesetzte Aufwendungen, die die CPU-, Eingabe/Ausgabe- und jeden anderen Faktor, der interessant werden könnte, wie z. B. der Aufwand für eine Verbindung, einschließt. In diesem Sinn sind die Aufwandsformeln logisch gegenüber den Aufwandsformeln, die in typischen, kommerziel len DBMSs verwendet werden, die die Aufwendungen basierend auf physikalischen Parametern unter der Verwendung von Konstanten abschätzen. Außerdem sind die obigen Formeln typischen, kommerziellen Formeln trotzdem ähnlich mit drei bedeutenden Unterschieden:

- Bei den bekannten Formeln wird angenommen, daß die Koeffizienten Konstanten sind. In diesem Fall werden sie als Funktionen betrachtet.
- Der Wert, der diesen Koeffizienten zugeordnet wird, ist eine zusammengesetzte Aufwendung von CPU- und Eingabe/Ausgabe-Aufwendungen, wobei diese Aufwen dungen in den meisten kommerziellen DBMSs getrennt berechnet werden.
- Der Wert, der den Koeffizienten zugeordnet wird, kann ebenso andere systemabhängige Faktoren, wie z. B. Hardwaregeschwindigkeits-, Betriebssystem- und DBMS-Konfigurationsfaktoren, widerspiegeln.

Für Fachleute sollte es offensichtlich sein, daß die be schriebene Erfindung in ihrem bevorzugten Ausführungsbei spiel sofort erweitert werden kann, um eine Vielzahl von Überlegungen, die den Kalibrierungsvorgang verbessern kön nen, einzuschließen. Diese Überlegungen schließen ein, sind aber nicht beschränkt auf:

- Vergrößerung des Effektes der Pufferung von ungrup pierten Indizes;
- Extrapolierung für nicht-standardmäßige DBMSs;
- Ableitung von Defakto-Gruppierungen von den Daten, um die Aufwendung für weniger gruppierte Daten zu interpolieren; und
- Erfassen, wann eine Indexabtastung zu einer Folge abtastung für einen ungruppierten Index innerhalb des Zusammenhangs des Zugriffsverfahrens, das in verschachtelten Schleifen benutzt wird, umgeschalt et wird.

Eine Fallstudie eines Ausführungsbeispieles der Erfindung

Dies ist eine Fallstudie, die als Testunterlage verwendet wird, um die Machbarkeit der Erfindung zu beweisen. In die ser Fallstudie wird angenommen, daß alle teilnehmenden DBMSs in einem HDBMS relational sind. Der Einfachheit halber wird angenommen, daß alle Daten schematisch und darstellungsmäßig kompatibel sind; d. h., es gibt kein Integrationsproblem. In diesem Sinne schafft das HDBMS eine Stelle zur Abfrage aller teilnehmenden DBMSs und schafft eine Datenbanktransparenz (d. h. der Anwender braucht nicht zu wissen, wo Daten abge legt sind und wie die Abfragen aufgespaltet werden). Darum leitet das HDBMS die Verantwortung zum Aufspalten und Aus führen der Abfrage an die teilnehmenden DBMSs weiter. Dies ist die Motivation für einen Abfrageoptimierer für HDBMSs. Ohne Einschränkung der Allgemeingültigkeit sei angenommen, daß die Abfrage eine verbundene Verhältnisabfrage bzw. eine verbundene relationale Abfrage ist.

Ein kurzer Überblick über den bekannten Optimierer

Die Optimierung von Verhältnisabfragen kann abstrakt wie folgt beschrieben werden:
Bei einer gegebenen Abfrage Q, einem Ausführungsraum E und einer Aufwandsfunktion C, die über 1 definiert ist, finde eine Ausführung e in E_Q, die einen minimalen Auf wand darstellt, wobei ein Subet von E ist, das Q be rechnet, wobei Q ausgedrückt wird als

Jede Lösung zu dem obigen Problem kann durch Auswahl:

1. eines Ausführungsmodells und damit eines Aus führungsraumes;
2. eines Aufwandsmodells; und
3. einer Suchstrategie

charakterisiert werden.

Das Ausführungsmodell kodiert die Entscheidungen, die das Anweisen der Verbindungen, der Verbindungsverfahren, der Zugriffsverfahren, der Materialisierungsstrategie, etc. be treffen. Das Aufwandsmodell berechnet den Ausführungsauf wand. Die Suchstrategie wird angewendet, um den Suchraum aufzuzählen, während der minimale Aufwand für die Ausführun gen ausfindig gemacht wird. Diese drei Auswahlmöglichkeiten sind nicht unabhängig; die Wahl eines kann die anderen beeinflussen. Wenn zum Beispiel ein lineares Aufwandsmodell angewendet wird, dann kann die Suchstrategie einen quadrat ischen Raum aufzählen bzw. bezeichnen; auf der anderen Seite wird ein exponentieller Raum aufgezählt bzw. bezeichnet, wenn ein allgemeines Aufwandsmodell benutzt wird, wie im Fall von kommerziellen Datenbank-Managementsystemen. Diese Fallstudie hängt weder von dem Ausführungsraum (außer für die unten erwähnte Beugung) noch von der verwendeten Suchstrategie ab. Es ist trotzdem davon abhängig, wie das Aufwandsmodell in dem Optimierungsalgorithmus angewendet wird. Darum werden die folgenden Annahmen getroffen:

- Der Ausführungsraum kann abstrakt als ein Satz aller Verbindungsreihenfolgen (d. h. aller Permutationen einer Relation) modelliert werden, in denen jede Relation mit Zugriffs/Verbindungsverfahren und anderen solchen Beu gungen der Ausführung versehen ist. Diese und andere Beugungen des bekannten Ausführungsraumes werden unten formalisiert.
- Die vollständige Suche wird als die Suchstrategie über dem Ausführungsraum angenommen, die in vielen kommerziellen Optimierern weit verbreitet angewendet wurde. Dieser Raum der Ausführungen wird durch Aufzählen der Permutationen und durch Wahl einer optimalen Ammotation der Verbindungs- und Zugriffsverfahren für jede Permutation basierend auf dem Aufwandsmodell durchsucht. Die Ausführung mit dem minimalen Aufwand ist die Permutation mit dem geringsten Aufwand.

Das traditionelle Aufwandsmodell benutzt die Beschreibung der Relationen, z. B. der Kardinalität und der Selektivität, um den Aufwand zu berechnen. Es ist zu beachten, daß die Operanden für diese Operationen, wie z. B. Auswahl und Ver bindung, Zwischenrelationen sein können, deren Beschreibung berechnet werden muß. Ein solcher Beschreiber kodiert alle Informationen über die Relation, die für die Aufwands funktionen benötigt werden.

Der Satz aller Beschreiber der Relationen sei D und I sei der Satz von Aufwandswerten bezeichnet durch ganze Zahlen. Aufzwei Funktionen für jede Operation, σ wie z. B. Ver binden, Aussuchen, Projizieren etc., werde besonders ge achtet. Diese Funktion für eine binäre Operation σ sind:

COSTσ : D X D → I and DESCσ : D X D → D

Die COSTσ-Funktion berechnet den Aufwand zum Anwenden der binären Operation σ auf zwei Relationen und DESCσ ergibt einen Beschreiber für die sich ergebende Relation. Diese Funktionen für die monadischen Operatoren sind ähnlich de finiert. Diese Fallstudie bezieht sich hauptsächlich auf die COST-Funktion und verwendet die bekannte Definition für die DESC-Funktion. Diese enthält Informationen, wie z. B. die Kardinalität der Relation, die Anzahl der verschiedenen Wer te für jede Spalte, die Anzahl der Seiten, Indexinformatio nen, etc.

Ausführungsmodell für HDBMSs

Ein Ausführungsplan für eine Abfrage kann als ein Plan für ein zentralisiertes System angesehen werden, in dem einige der Verbindungen sich über die DBMSs erstrecken. Diese Verbindungen kann man als abwechselnde Verbindungsverfahren ansehen. Hierin enthalten ist die Formaldefinition eines Planes für ein bekanntes DBMS, das durch Zulassung der neuen Verbindungsmethoden erweitert wurde.

Ein Plan für eine Anfrage kennzeichnet in den meisten kom merziellen DBMSs die Reihenfolge der Verbindungen, das Ver bindungsverfahren, das für jede Verbindung angewendet wird, und den Zugriffsplan für jedes Argument der Verbindung. Zu sätzlich werden die gewöhnlichen Informationen, die benötigt werden, um die durchkommenden Seiteninformationen (ebenfalls bekannt als die Verbindungsinformationen) zu kennzeichnen, vorgegeben.

Formal wird ein Plan für eine gegebene Verbindungsabfrage durch Anwendung einer normalen Form, genannt Chomsky Normal Form oder CNF, ausgedrückt. Ein CNF-Programm ist ein Daten aufzeichnungsprogramm, in dem alle Vorschriften höchstens zwei Prädikate im Rumpf der Vorschrift haben. Es wird eine Verbindungsabfrage auf k Relationen angenommen. Dies kann als eine Vorschrift im Datenaufzeichnungsprogramm mit k Prädikaten im Rumpf angesehen werden. Ein entsprechendes CNF-Programm kann durch Verwendung von k-1 Vorschriften, von denen jede genau zwei Prädikate im Rumpf hat, definiert werden. Dies ist durch das folgende Beispiel erläutert.

p(X,Y) ← r₁(X,X₃), r₂(X₁,X₂), r₃(X₂, X₃), r₄(X₃,Y)

hat das folgende äquivalente CNF-Programm:

p(X,Y) ← r₁₃(X,X₃), r₄(X₃,Y)
r₁₃(X,X₃) ← r₁₂(X,X₂), r₃(X₂,X₃)
r₁₂(X,X₂) ← r₁(X,X₁), r₂(X₁,X₂)

In dem obigen CNF Programm ist die zusätzliche Beschränkung gegeben, daß die Ausführung von links nach rechts im Rumpf der Vorschrift erfolgt. Ein Ergebnis ist es, daß die Sei teninformationen, die durch die Bindung durchgehen, von r₁₃ bis r₄ in der ersten Vorschrift sind. Ferner ist zu beach ten, daß das CNF Programm die Reihenfolge der Verbindungen der Relationen komplett kennzeichnet. Deshalb werden r₁ und r₂ vor der Verbindung mit r₃ verbunden. Es ist zu beachten, daß das obige CNF Programm alle Typen von weit verzweigten Verbindungsbäumen darstellen kann; im Gegensatz dazu erlau ben die meisten kommerziellen DBMSs nur linksseitig tiefe Verbindungsbäume.

Der Einfachheit halber wird in dieser Fallstudie für alle CNF Programme vorausgesetzt, linksseitig tief zu sein (d. h. nur das erste Prädikat im Rumpf kann ein hergeleitetes Prädikat sein), und folglich werden andere CNF-Programme von der Überlegung ausgelassen.

Für jede Verbindung in dem CNF Programm wird ein Verbin dungsverfahren zugeordnet; ein Verbindungsverfahren ist dem Rumpf jeder Vorschrift beigeordnet. Zwei Verbindungsmethoden werden angenommen: verschachtelte Schleife (nested loop = NL) und geordnete Mischung (ordered merge = OM), wie z. B. Mischsortierung oder Durcheinandermischung. Ferner wird je des Prädikat mit einer Anmerkung über ein Zugriffsverfahren versehen; d. h., höchstens zwei Zugangsverfahren pro Vor schrift (es ist zu beachten, daß in einigen Fällen, wie z. B. der äußeren Schleife (einer verschachtelten Schleifenver bindung), die von einer anderen Verbindung umgeleitet wird, die Vermerkung einer Zugriffsmethode keinen Sinn macht). Die folgenden vier Zugriffsverfahren werden in dieser Fallstudie berücksichtigt:

- Folgeabtastung (sequential scan = SS): Zugriff und Test aller Tupels in der Relation;
- ausschließliche Indexabtastung (index-only scan = IO): nur Zugriffs- und Testindex;
- gruppierte Indexabtastung (clustered index scan = CI): Zugriff und Test gruppierter Indizes, um die in Frage kommenden Tupels zu finden und auf die Datenseite zuzu greifen, um den Tupel zu erhalten; und
- ungruppierte Indexabtastung (unclustered index scan = UI): dasselbe wie bei CI, aber für ungruppierte Indizes.

Diese Liste der Verfahren spiegelt die Beobachtungen in vie len kommerziellen DBMSs wieder, wie z. B. die Unterscheidung zwischen lediglich der Zugriffsindexseite und dem Zugriff auf beides, die Index- und die Datenseiten. Ein Zugriff auf gruppierte und ungruppierte Indexseiten wird nicht unterschieden.

Obwohl alle Zugriffsverfahren mit allen Verbindungsverfahren angewendet werden können, machen einige Verbindungen keinen Sinn. Jedoch vermeidet der Optimierer diese Fälle durch Zuordnung eines sehr großen Aufwands. Es ist zu beachten, daß die Liste der Verbindungsverfahren und Zugriffsverfahren leicht erweitert werden kann und die Aufwandsformeln in ähnlicher Art und Weise spezifiziert werden können.

Wie bereits erwähnt, wird die Liste der Verbindungsverfahren durch ein neues Verfahren, genannt Fernverbindung, das eine Verbindung über zwei DBMSs ausführen kann, erweitert. Dies kann durch Übertragung der Daten direkt an das andere DBMS oder an das HDBMS, das sie dann dem anderen DBMS zuordnet, um die Verbindung zu berechnen, erreicht werden. Offen sichtlich gibt es eine Vielzahl von Variationen, um diese Fernverbindung zu erreichen. Der Einfachheit halber wird in dieser Fallstudie vorausgesetzt, daß einige solcher Fern verbindungen ausgewählt sind. Jeder solchen Fernverbindung wird eine Aufwandsfunktion zugeordnet und der Aufwand für die gesamte Ausführung wird in bekannter Art und Weise be rechnet. Wenn auch die spezifische Auswahl für die Fernver bindungen und das Aufwendungsmodell, das zur Abschätzung des Aufwandes der Fernverbindung benutzt wird, wichtig sind für einen HDBMS Optimierer, so wird dies im Zusammenhang mit dieser Fallstudie weggelassen.

Zusammenfassend gilt, daß der Optimierer einen großen Raum für Ausführungen sucht und den minimalen Aufwendungsausfüh rungsplan findet. Während Ausführungsraum und Suchstrategie größtenteils unverändert bleiben, ist nur das Aufwendungs modell für jede Kategorie von DBMSs relevant, um den Opti mierer für HDBMSs zu beschreiben. Im besonderen konzentriert sich diese Fallstudie auf das Aufwendungsmodell für Auswahl- und Verbindungsoperationen im Zusammenhang mit einem ein zelnen DBMS, das Verbindungen über DMBSs anwendet, die auf der Grundlage des Fernverbindungsaufwendungsmodelles berech net werden können. Die Aufwendungsmodelle für firmeneigene und übereinstimmende DBMS werden als nächstes erläutert.

Aufwendungsmodell für firmeneigene DBMSs

Das Aufwendungsmodell für eine Abfrage über viele firmen eigene DBMSs muß mit dem Ausführungsmodell, das in der DBMS selbst angewendet wird vergleichbar sein. Dies erfordert, daß das Aufwendungsmodell die internen Details des teil nehmenden DBMS kennt. Bei einem firmeneigenen DBMS ist dies möglich. Für diese Fallstudie wird das Aufwendungsmodell auf einer sehr hohen Ebene umrissen. Die Absicht ist es, die Anwendung von physikalischen Parametern, wie z. B. Vorab rufung, Pufferung, Seitengröße, Anzahl der Anweisungen, um eine Seite zu sperren und viele andere solcher ausführungs abhängigen Charakteristika, zu betrachten.

Typischerweise schätzt das Aufwendungsmodell die Aufwendun gen bezüglich der Zeit ab; im besonderen die minimale ver gangene Zeit, die auftreten kann. Diese abgeschätzte Zeit sagt normalerweise nicht irgendwelche "Gerät belegt" Bedin gungen voraus, die in der Realität die verstrichene Zeit er höhen würden. Diese Vorstellung von Zeit wird als Maßstab der Aufwendungen verwendet. Dies ist üblicherweise gerecht fertigt auf der Grundlage, daß die Minimierung dieser ver strichenen Zeit den Effekt hat, die gesamte Arbeit zu minimieren und damit den Datendurchlauf zu maximieren.

In HDBMSs kann die verstrichene Zeit durch Abschätzung von drei Komponenten abgeschätzt werden:

- die CPU Zeit, die in beiden, den teilnehmenden DBMSs und dem HDBMS aufgetreten ist;
- die Eingabe/Ausgabezeit, die sowohl in den teilnehmenden DBMSs als auch in dem HDBMS aufgetreten sind; und
- die Übertragungszeit zwischen dem HDBMS und den teil nehmenden DBMSs.

Bekannte zentralisierte DBMSs schließen nur die CPU- und Eingabe/Ausgabezeit in ihre Abschätzung ein. Diese Fall studie benutzt eine ähnliche Abschätzung für beide dieser Komponenten. Jedem der zugelassenen Verbindungsverfahren und der zugelassenen Zugriffsverfahren wird eine Aufwandsformel zugeordnet.

Die CPU Abschätzung schließt die benötigte Zeit ein, um die notwendige Verriegelung durchzuführen, um auf die Tupels entweder der Reihe nach oder durch Anwendung eines Indizes zuzugreifen, um die Tupels abzurufen, um die notwendigen Vergleiche anzustellen, um die notwendigen Projektionen durchzuführen, etc. Die Aufwendungsformeln basieren auf der Abschätzung der erwarteten Weglänge dieser Operationen und auf den spezifischen Parametern der Relationen, wie z. B. der Anzahl der Tupels, etc. Offensichtlich ändern sich diese Parameter stetig mit den Verbesserungen in der Hardware und der Software. Bei einem firmeneigenen System können diese Änderungen mit den neuen Versionen synchronisiert werden.

Die Eingabe/Ausgabezeit wird durch Verwendung der Geräte charakteristika, Seitengröße, Vorabruffähigkeiten und der CPU Weglänge, die benötigt wird, um die Eingabe/Ausgabe zu initiieren und durchzuführen, abgestimmt.

Die benötigte Zeit für die Durchführung der notwendige Über tragung, kann auf Grundlage der abgeschickten Datenmenge, der Paketgröße, des Übertragungsprotokolls, der benötigten CPU Weglänge, um die Übertragung zu indizieren und durchzu führen, etc. abgeschätzt werden. Es wird angenommen, daß die physikalischen Charakteristika des Übertragungsuntersystemes dem HDBMS bekannt sind und daß genaue Aufwandsmodelle durch Anwendung dieser Parameter entwickelt werden können.

Zusammenfassend gilt für diese Fallstudie, daß das Aufwands modell für eine firmeneigene DBMS ein Modell ist, das komplette Kenntnis der Interna des teilnehmenden DBMS hat.

Aufwandsmodell für übereinstimmende DBMSs

Ein übereinstimmendes DBMS ist ein relationales DBMS mit mehr oder weniger vorhandener standardmäßiger Abfrage funktionalität. Als erstes muß ein Aufwandsmodell entworfen werden, das den Aufwand für eine gegebene Abfrage derart abschätzt, daß das Modell auf den logischen Charakteristika der Abfrage basiert. Um dies zu tun, muß ein Aufwendungsmodell zur Abschätzung des Aufwandes eines gegebenen Plans für eine Abfrage umrissen werden. Dann muß der Vorgang, durch den die Konstanten des Aufwandsmodelles abgeschätzt werden, als auch die experimentelle Überprüfung dieses Vorganges beschrieben werden. Zuletzt wird eine dynamische Modulation dieser Konstanten aufgezeigt, um jegliche Diskrepanz zu meistern.

Logisches Aufwandsmodell

Das logische Aufwandsmodell sieht die Kosten bzw. den Aufwand auf der Basis der logischen Ausführung der Abfrage. Es gibt zwei Bedeutungen. Bei der ersten wird der Aufwand einer gegebenen Abfrage basierend auf den logischen Charakteristika des DBMS, auf den Relationen und auf der Abfrage abgeschätzt. Bei der zweiten wird der Aufwand von umfangreichen Abfragen (z. B. verschachtelte Schleifenverbindungen) durch Anwendung einfacher Abfragen (z. B. Einzeltabellenabfragen) abgeschätzt.

Aufwandsformeln

Um der Kürze willen konzentriert sich diese Fallstudie auf den Teil des Aufwandsmodelles, der den Aufwand für Auswahl und Verbindungsoperationen abschätzt. Formal sind zwei Re lationen r₁ und r₂ mit N₁ und N₂ Tupels gegeben und der Auf wand der folgenden zwei Operationen wird abgeschätzt:

- eine Auswahloperation auf r₁ mit einer Selektivität S₁; und
- eine Verbindungsoperation auf r₁ mit einer Selektivität J₁₂.

Bezugnehmend auf Fig. 6 sind die Formeln für diese zwei Ope rationen durch die folgenden Annahmen, die alle im Folgenden beschrieben werden, gegeben:

- die Größe der Tupel wird als fest angenommen
- es gibt genau eine Auswahl/Verbindungsbedingung auf einer Relation;
- das gesamte Tupel wird in die Antwort projiziert; und
- alle Attribute sind ganze Zahlen.

Die Auswahlaufwandsformeln können als eine Summe der folgen den drei unabhängigen Komponenten angesehen werden:

- COMP0: Initialisierungsaufwand
- COMP1: Aufwand, um die zutreffenden Tupels zu finden; und
- COMP2: Aufwand, um die ausgewählten Tupels zu verar beiten.

Die COMP0-Komponente ist der Aufwand der Verarbeitung der Abfrage und des Startens der Abtastung. Dies ist die Kompo nente, die abhängig von dem DBMS, aber unabhängig von der Relation oder der Abfrage, ist.

Im Fall einer Folgeabtastung besteht die COMP1-Komponente aus einer Sperrungsanforderung, der Ausführung der "get next"-Operation, einem amortisierten Eingabe/Ausgabeaufwand und den anderen Anforderungen, die pro Tupel der Abtastung auftreten. Es wird darauf hingewiesen, daß die feste Größe der Tupel sicherstellt, daß die Anzahl der Seiten, auf die zugegriffen wird, direkt proportional der Anzahl der Tupel ist. Deshalb ist der Aufwand pro Tupel konstant. In dem Fall einer Indexabtastung ist COMP1 der Aufwand, um den anfäng lichen Index nachzusehen. Es wird darauf hingewiesen, daß in allen drei Fällen von Indexabtastung angenommen wird, daß COMP1 unabhängig von der Relation ist. Dies ist offensicht lich nicht wahr, wenn die Anzahl der Ebenen im Indexbaum abhängig ist von der Größe der Relation. Aber es ist nicht wahrscheinlich, daß diese Anzahl große Unterschiede auf weist, aufgrund der hohen Verzweigungen eines typischen B-Baumes oder irgendeines anderen Indizierungsmechanismus.

Die COMP2-Komponente ist der Aufwand zur Verarbeitung jedes der ausgewählten Tupels. Dieser Komponentenaufwand ist wahr scheinlich ebenfalls konstant, aufgrund der früher gemachten Selektions- und Projektionsannahmen.

Bezugnehmend auf Fig. 6 sind die Verbindungsformeln eine Ableitung aus den verschachtelten Schleifen- und geordneten Mischungsalgorithmen. Es wird darauf hingewiesen, daß sie aus Selektionsaufwandsformeln mit bestimmten Einstellungen zum Handhaben von Operationen (z. B. Sortieren und Vermi schen) und von Problemen (z. B. Pufferungseffekt), die besonders bei Verbindungsoperationen auftreten, bestehen.

Zum Beispiel ist der Aufwand zum Zugreifen auf eine Relation in der innersten Schleife in derselben Art und Weise model liert, wie der Aufwand zum Zugreifen auf eine Relation in der äußersten Schleife. Dies ist nicht der Fall, wenn die innersten Relationen gepuffert sind, um die Eingabe/Ausgabe zu vermeiden. Es stellte sich heraus, daß diese Einheit lichkeit recht akzeptabel für Indexabtastungen ist. Wird eine Folgeabtastung in der inneren Schleife der Verbindung benutzt, dann kann der Eingabe/Ausgabeaufwand aufgrund der Pufferung nur einmal (für kleine Tabellen) auftreten, wohin gegen das Nachschauen in der Tabelle einmal für jedes Tupel in der äußeren Schleife gemacht wird. Um dies handzuhaben, wird COMP1 in den Formeln für Folgeabtastungen in zwei Teile aufgeteilt. Diese zwei Teile stellen die Eingabe/Ausgabe- und CPU Aufwendungen einer "get next" Operation dar.

Nun werden die oben gemachten Annahmen erweitert. Wird die Größe des Tupels variiert, dann werden die Konstanten beein flußt. Insbesondere wird nur erwartet, daß die Konstante CS1_SS (=CS1_SS ^io + CS1_SS ^cpu) beeinflußt wird und daß es wahr scheinlich ist, daß sie linear mit der Größe des Tupels wächst. Alle anderen Konstanten sind Komponentenaufwände für ausgewählte Tupels und folglich ist es nicht wahrscheinlich, daß diese beeinflußt werden. Diese Konstanten (d. h. CS2_XX′s) werden aber durch die Anzahl der Selektions- und Projek tionseintragungen beeinflußt. Um diese zu berücksichtigen, werden die obigen Konstanten zu Funktionen mit den folgenden Definitionen umdefiniert:

- CS1_SS ist eine lineare Funktion der Größe der Tupel in der Relation.
- CS2_XX′s sind lineare Funktionen der Anzahl der Selek tions- und Projektionseintragungen.

Nachdem diese keine Konstante mehr sind, werden sie als Koeffizienten bezeichnet.

Unter der Annahme, daß die Überprüfung durch den ersten Fehler beendet wird, ist die erwartete Anzahl der überprüf ten Auswahlbedingungen auf 1,5 begrenzt, unabhängig von der Anzahl der Auswahlbedingungen. In Fachkreisen wurde diese diskutiert und anerkannt. Weiter zeigen Experimente, daß der Aufwand zur Überprüfung der Auswahlbedingungen und der Projektionsattribute vernachlässigbar ist gegenüber anderen Aufwänden, z. B. Eingabe/Ausgabe.

Als nächstes wird die Annahme, daß alle Attribute ganze Zah len sind, durch die Forderung eines Satzes von Aufwands formeln für jeden Datentyp in dem DBMS erweitert. Die ent sprechenden Koeffizienten erfassen die Verarbeitung, die Indizierung und die Seitenaddressierungs-Charakteristika dieses Datentypes. Nachdem dies orthogonal zum Rest der Diskussion ist, bezieht sich der Rest der Fallstudie nur auf einen Datentyp.

Die fundamentale Grundlage für das obige Aufwandsmodell ist es, daß der Aufwand basierend auf einer sorgfältigen Bear beitung der Aufwände auf einer pro-Tupel-Grundlage in der logischen Verarbeitung der Abfrage berechnet werden kann. Tatsächlich sind die Koeffizienten CS0_XX, CS1_XX und CS2_XX alle zusammengesetzte Aufwendungen einschließlich des CPU-, des Eingabe/Ausgabe- und jedes anderen Faktors, der von Interesse sein könnte, wie z. B. der Aufwand der Verbindung. In diesem Sinne sind die Aufwandsformeln logisch gegenüber den Aufwandsformeln, die in den meisten kommerziellen DBMSs benutzt werden, die basierend auf physikalischen Parametern abschätzen. Die obigen Formeln sind strukturell sehr ähnlich zu denen, die im Stand der Technik benutzt werden. Jedoch gibt es drei Hauptunterschiede:

1. Bei den bekannten Formeln nach dem Stand der Tech nik wird angenommen, daß die Koeffizienten Konstanten sind. Hier werden sie als Funktionen betrachtet.
2. Der Wert, der mit diesen Koeffizienten verbunden wird, ist ein zusammengesetzter Aufwand für die CPU-, die Eingabe/Ausgabe- und die anderen Über legungen, wohingegen beim Stand der Technik diese Kosten bei der Berechnung typischerweise getrennt werden.
3. Der Wert, der diesen Koeffizienten zugeordnet wird, spiegelt ebenfalls andere systemabhängige Faktoren, wie z. B. Hardwaregeschwindigkeit, Betriebssystem und DBMS Konfiguration, wieder.

Die obige Grundlage zur Berechnung des Aufwandes ist offen sichtlich eine Annäherung an die weiter verbreiteten For meln, die durch kommerzielle DBMSs benutzt werden. Aber die wichtige Frage ist, ob diese Annäherungen signifikant genug sind, um die Entscheidung des Optimierers zu beeinflussen. Diese Fallstudie zeigt, daß das obige Aufwandsmodell das Verhalten der Ausführung ausreichend modellieren wird.

Kalibrierende Datenbank und Vorgang

Das Ziel der kalibrierenden Datenbank ist es, sie zu be nutzen, um die Koeffizienten in den Aufwandsformeln für jedes gegebene relationale DBMS zu kalibrieren. Der Ansatz ist es, eine synthetische Datenbank aufzubauen und sie abzufragen. Metrische Werte des Aufwandes (z. B. verstrichene Zeit) für die Abfragen werden beobachtet, um die Koef fizienten abzuleiten. Es wird darauf hingewiesen, daß in dem System keine Haken angenommen werden und das System folglich nicht mit Instrumenten versehen werden kann, um die Kon stanten (z. B. Anzahl der durchgeführten Eingaben/Ausgaben) des bekannten Aufwandsmodelles zu messen. Ferner sind der Aufbau der Datenbank, die die Abfrage stellt, und die Be obachtungen als eine Anwender nach "black box"-DBMS durchzu führen. Dies wirft die folgenden zwei Hauptvorhersagungs probleme auf:

1. Das Problem vorauszusagen, wie das System eine ge gebene Abfrage ausführen wird (z. B. Anwendung von Index- oder Folgeabtastung, Anwendung von ver schachtelten Schleifen oder Mischsortierung).
2. Das Problem des Ausschließens des Effektes der Da tenplazierung, Pagination und anderer Speicheraus führungsfaktoren, die die Beobachtungen potentiell stören können und folglich zu einem unvorhersehba ren Verhalten führen.

Um die Koeffizienten aus den Aufwandsformeln abzuleiten, ist es zwingend, daß die Abfrage und die Datenbank derart auf gebaut sind, daß die resultierende Ausführung voraussehbar ist; d. h. der Optimierer wird die vorausgesagten Zugriffs- und Verbindungsverfahren wählen. Auch wenn die Ausführung vorhersehbar ist, sollte sie frei von den oben genannten Störungen sein oder die Feststellung des Grundes für den beobachteten Effekt ist ansonsten nicht möglich. Wenn z. B. alle Tupels mit einem bestimmten Wert für ein Attribut zufällig auf einer einzelnen Seite sind, dann kann der beob achtete Wert irreführend sein.

Der nächste Schritt ist es dann, eine Datenbank und einen Satz von Abfragen zu schaffen, die frei von den obigen beiden Problemen sind und zeigen, daß die Koeffizienten der Aufwandsformeln abgeleitet werden können.

Kalibrierende Datenbank

Für jede Ganzzahl n sei R_n eine Relation von sieben Spalten, die 2ⁿ Tupels enthalten. Die sieben Attribute haben die fol genden Charakteristika:
C₁ eine ganze Zahl [0,n], indiziert, gruppiert
C₂ eine ganze Zahl [0,2ⁿ-1], indiziert, defacto gruppiert aber nicht als solche im DBMS spezifiziert
C₃ eine ganze Zahl [0,n], indiziert, ungruppiert
C₄ eine ganze Zahl [0,n], kein Index
C₅ eine ganze Zahl [0,2ⁿ-1], indiziert, ungruppiert
C₆ eine ganze Zahl [0,2ⁿ-1], kein Index
C₇ eine lange Buchstabenkette, um die Größe der Tupelan forderungen zu erfüllen

Die Werte in diesen Attributen sind in Fig. 8 gegeben. Selbst wenn die Relation ein Satz ist und als solcher unge ordnet ist, kann man sie dem Konzept nach als Matrix be trachten. Folglich ist das i-te Tupel in R_n definiert, ver gleiche Fig. 8.

Der Wert für das siebte Attribut (C₇) ist ein Ausfüllfeld und kann auf irgendeinen Wert gesetzt werden und wird des halb aus Gründen der Annehmlichkeit im Rest der Diskussion ausgelassen. In Fig. 7 ist die Relation R₄ tabularisch dar gestellt.

Der Multispaltenschlüssel für die Relation ist (C₁, C₂). Diese Relation ist auf diesem Schlüssel in ansteigender Rei henfolge indiziert, wobei C₁ der Hauptschlüssel und C₂ der untergeordnete Schlüssel ist. Dieser Index ist gruppiert in dem Sinne, daß die Werte des Hauptschlüssels (d. h. C₁) grup piert sind. Im allgemeinen müssen die Werte von C₂ nicht gruppiert sein. Wie es aus dem Aufbau der Relation klar her vorgeht, sind die Werte des untergeordneten Schlüssels (d. h. C₂) ebenfalls gruppiert. Tatsächlich sind die Werte in C₂ einzigartig und haben 2ⁿ Werte in dem Wertebereich [0,2ⁿ-1] und deshalb können diese Werte ebenfalls in aufsteigender Reihenfolge sein. Man kann also sinngemäß diese Spalte, C₂, als eine Folgezahl für die Reihen ansehen. Dieser C₂ Wert wird als der Reihenindex bezeichnet. Die Notwendigkeit für Multispaltenschlüssel und Index ist die, daß die Tupels auf den Plattenseiten basierend auf C₂ geordnet sind und daß das System informiert wird, daß C₁ einen gruppierten Index hat. Dies könnte durch Einführen der Tupels in dieser Reihenfolge erreicht werden, solange die Indexerzeugung im DBMS stabil ist, wobei die meisten DBMSs diese Anforderung erfüllen. Tatsächlich wurde dies bei der Kalibration von Systemen in dieser Fallstudie angewendet.

Es wird darauf hingewiesen, daß die Datenbank durch einen Vorgang erzeugt werden kann, der die obigen Formeln ab schätzt. Deshalb ist es möglich, eine eine Million Tupel um fassende Datenbank in wenigen Minuten zu erzeugen. Im Gegen satz dazu benötigt die Generation der Datenbank bei Anwend ung bekannter Techniken nach dem Stand der Technik erheblich mehr Zeit.

Ein Überblick über die Datenbankeigenschaften

Vor der Beschreibung der Daten folgen einige Definitionen. SEQ(n,i) (in ähnlicher Weise SIQ(n,i)) sei eine ausgesuchte Abfrage auf R_n, die ein Gleichheits- (respektive Ungleich heits-) Prädikat mit der Kardinalität des Ausgabeergebnisses von 2ⁱ für i<n anwendet. Solch eine Anfrage wird in der fol genden Diskussion benutzt.

Die Werte in C₁ sind in ansteigender Reihenfolge mit einem gruppierten Index. f[i] gibt die Anzahl der Tupels an, in denen der Wert i in C₁ auftaucht. mf[i] sei als der i-te häufigst auftretender Wert in C₁ definiert. Die Verteilung der Werte zeigt ein normales Muster derart, daß der mf[i]- Wert in 1/2ⁱ der Anzahl der Tupels auftaucht. Die obigen Formeln für C₁[n,i] haben dieses Muster codiert, aus dem wir den folgenden Hilfssatz herleiten können.

Hilfssatz 1

Für irgendeine Relation R_n und irgendeine Selektivität s_i = 1/2ⁱ, i ε [1,n], existiert ein Gleichheitsprädikat in C₁, dessen Selektivität s_i ist.

Corrollary 1

Es existieren Anfragen SEQ(n,i) und SEQ(n+1,i) auf den Relationen R_n und R_n+1 für i = 1, 2, . . . , n.

Die obigen Beobachtungen schaffen eine Garantie, daß Abfra gen vorhanden sind, die

- eine variierende Anzahl von Tupels aussuchen, die ein Gleichheitsprädikat auf dieselbe Relation an wenden; und
- dieselbe Anzahl von Tupels auswählen, die ein Gleichheitsprädikat von vielen Relationen mit ver schiedenen Größen anwenden.

Für diese Abfragen, die C1 benutzen, kann die folgende For derung mit berechtigter Sicherheit dargelegt werden.

Forderung 1

Eine Ausführung irgendeiner SEQ(*,*)-Abfrage von C1 resultiert in der Anwendung der gruppierten Indexab tastung.

Wie oben erwähnt wird die Vorhersehbarkeit des Aufwandes der Ausführung einer Abfrage SEQ(n,i) auf C₁ von den CPU- und der Eingabe/Ausgabekomponenten abhängen. Der CPU Aufwand steigt monoton mit der Größe des Ergebnisses. Aufgrund der obigen Forderung nimmt der Eingabe/Ausgabeaufwand ebenfalls monoton zu, bis auf die maximale Anzahl der Seiten zuge griffen wurde. Folglich ist die Anzahl der Eingaben/Ausgaben eine nicht fallende Funktion von der Größe des Ergebnisses. Diese Klasse von Funktionen wird als gesättige, monoton steigende Funktion bezeichnet.

Hilfssatz 2

Für irgendeine Speicherausführung und benutzte Seiten größe wird die Anzahl der Seiten, auf die durch eine SEQ(n,i) Abfrage, die C₁ verwendet, zugegriffen wird, durch eine gesättigte, monoton steigende Funktion von i gegeben.

Es ist darauf zu achten, daß die Kalibrierung für die Ko stenformeln in dem gesättigten Gebiet zu einer inkorrekten Kalibrierung führen. Jedoch ist zu beobachten, daß im schlimmsten Fall auf fast die Hälfte der Anzahl der Seiten nicht zugegriffen werden wird. Deshalb kann durch die Ver wendung großer Relationen das Problem der Sättigung ver mieden werden. Folglich werden die unvorhersehbaren Probleme für irgendeine Abfrage auf C₁ vermieden.

Es wird darauf hingewiesen, daß die Werte in C₁ funktional durch die Werte in C₂ festgestellt werden. Tatsächlich sind die Werte von C₂ aufgrund der aufsteigenden Reihenfolge der Indizierung des Schlüssels in aufsteigender Reihenfolge. Diese Beobachtung und die Tatsache, daß der Index gruppiert ist führen zu dem folgenden Hilfssatz.

Hilfssatz 3

Jede Speicherausführung dieser Relation wird die Rei henfolge der Tupels unter den Seiten der Relation beibe halten.

Diese Beobachtung schafft eine Handhabe bezüglich der Paginierung der Daten. Dies kann benutzt werden, um darzu legen, daß die C₃- und C₄-Werte einheitlich über alle Seiten verteilt sind.

Die folgenden zwei Beobachtungen sind hier der Vollständig keit halber dargestellt.

Hilfssatz 4

Für jegliche Relation R_n und jegliche Selektivität S_i = 1/2ⁱ, i ε [1,n) existiert ein Ungleichheitsprädikat auf C₂, dessen Selektivität s_i ist.

Corrollary 2

Es existieren Abfragen SIQ(n,i) und SIQ(n+i,i) auf die Relationen R_n und R_n+1 für i = 1, 2, 3, . . . , n.

Die Werte in C₁ werden mit verschiedenen Reihen von C₃ ver tauscht. Deshalb gilt die Häufigkeitsverteilung f[i] eben falls für C₃ und C₄. Diese Rückverteilung wird aufgrund der Beobachtung durchgeführt, daß die Hälfte der Anzahl von Tupels einen Reihenindex in der binären Darstellung der Form *0 (d. h. das letzte Bit ist 0) hat, ein Viertel der Anzahl von Tupels hat einen Reihenindex in binärer Darstellung mit der Form *01, etc. Deshalb kann die Verteilung wie folgt vorgenommen werden:

- alle binären Reihenindizes, die die Form *0 haben, haben den Wert mf(1)
- alle binären Reihenindizes, die die Form *01 haben, ha ben den Wert mf[2]
- alle binären Reihenindizes, die die Form *011 haben, ha ben den Wert mf[3)
- usw.

Deshalb ist jeglicher Wert in [0,n) einheitlich in den Rei hen für C₃ und C₄ verteilt. Dies führt zu dem folgenden Hilfssatz.

Hilfssatz 5

Für jegliche Speicherausführung, jegliche benutzte Seitengröße und einen gegebenen Wert i in [0,n] sind die Tupels, die den Werte i für C₃und C₄ enthalten, gleichmäßig über alle Seiten verteilt.

Durch Anwendung dieses Hilfssatzes wird die folgende Be obachtung gemacht, die ein Vorhersageproblem bei der An wendung von C₃ und C₄ überwindet.

Hilfsatz 6

Für jegliche Speicherausführung und benutzte Seitengröße wird die Anzahl der Seiten, auf die durch eine SEQ(n,i) Abfrage mit C₃ oder C₄ zugegriffen wird, durch eine gesättigte, monoton steigende Funktion aus 1 gegeben.

Wiederum ist die Sättigung kein Problem, da der ungruppierte Index meistens in Gebieten eingesetzt wird, in denen die Selektivität gering ist. Wird die Kalibrierung auf dieses Gebiet beschränkt, dann wird die Eingabe/Ausgabe monoton steigen. Mit einem CPU Aufwand, der monoton steigt, wird das Vorhersagungsproblem vermieden.

Um das Gebiet festzulegen, wenn der Index benutzt wird, wer den die folgenden Beobachtungen gemacht.

Forderung 2

Die Ausführung von jeglicher SEQ(*,*)-Abfrage auf C₃ wird eine Verwendung der Indexabtastung zur Folge haben, wenn die Selektivität gering ist; ist die Selektivität aber hoch, dann kann das System eine Folgeabtastung ver wenden.

Forderung 3

Die Ausführung von jeglicher SEQ(*,*)-Abfrage auf C₄ wird eine Anwendung der Folgeabtastung zur Folge haben.

Da bekannt ist, daß C₃ und C₄ identisch sind, kann die Re gion der Selektivitäten, wenn ein Index benutzt wird, fest gestellt werden und zur Kalibrierung des Systems verwendet werden. Folglich werden die Unvorhersehbarkeitsprobleme für Abfragen auf C₃ und C₄ vermieden.

C₅ und C₆ sind ebenfalls Permutationen von C₂ und werden zur Anwendung mit Ungleichheitsabfragen angewendet. Das Vorher sehbarkeitsproblem für eine solche Abfrage schließt die An zahl der Seiten, auf die durch eine Auswahl mit einem Un gleichheitsprädikat der Form C₅ < i zugegriffen wird, ein. Diese Werte müssen in einer solchen Art und Weise verteilt werden, daß die Anzahl der Seiten, auf die zugegriffen wird, zunehmen, wenn die Selektivität erhöht wird. Dies wird er reicht durch Verteilung der Werte mit den folgenden Eigen schaften.

Hilfssatz 7

Für jegliches i ε [0,n) wird ein Satz von Werten [0,2ⁱ-1] gleichmäßig in C₅ und C₆ verteilt.

Dies führt zu einer Anforderung einer SIQ(n,i) Abfrage, um auf eine Sequenz von Reihen derart zuzugreifen, daß sich aufeinanderfolgende Reihenindizes um eine Konstante unter scheiden. Es wird eine Abfrage C₅ < 8 angenommen. Dies führt zu einem Zugriff auf die Reihen (0, 2, 4, 6, 8, 10, 12 und 14) in R₄ mit der Eigenschaft, daß sich aufeinanderfolgende reihen um 2 unterscheide. Es wird darauf hingewiesen, daß die Bedingung die Form C₅ < 2ⁱ hat. Durch Anwendung dieser Beobachtung können wir den folgenden Hilfssatz formulieren.

Hilfssatz 8

Für jegliche Speicherausführung und verwendete Seiten größe wird die Anzahl der Seiten, auf die durch eine SIQ(n,i) Abfrage, unter Verwendung von C₅ oder C₆, zuge griffen wird, durch eine gesättigte, monoton steigende Funktion von i gegeben.

Wiederum kann durch die Verwendung der Argumente, die ähn lich denen sind, die für C₃ und C₄ verwendet wurden, fest gestellt werden, daß Vorhersehungsprobleme vermieden werden. Die obige Beobachtung für die Relation R_n ist besonders wichtig, da eine solche Schlußfolgerung nicht gezogen werden kann, wenn die Relation wahrscheinlichkeitsmäßig erzeugt wurde, wie es in dieser Fallstudie der Fall war.

Zusammenfassend gilt, daß die Abfragen, die gegenüber ir gendeinem der Attribute in der Relation gestellt werden, ein vorhersehbares Verhalten haben.

Kalibrierungsverfahren

Der nächste Schritt ist es, die Koeffizienten aus der be trachteten Ausführung dieser Abfragen abzuleiten.

Forderung 4

Der Aufwand der Ausführung von Abfragen SEQ(n,i) und SEQ(n+1,i) sind außer für die COMP1-Komponente des Auf wandes aufgrund der Tatsache, daß sie auf Relationen mit verschiedenen Größen zugreifen, identisch.

Aus dieser Beobachtung wird das folgende Experiment aufge baut:

- Abschätzung von SEQ(n,i) und SEQ(n+1,i) unter Verwendung eines Gleichheitsprädikates auf C₄ und Beobachtung des Aufwandes.
- Wissend, daß das System eine Folgeabtastung auswählen wird, Aufgelösung nach dem Koeffizienten CS1_SS.

Anstatt der Verwendung von ein oder zwei Datenpunkten müssen viele Werte angewendet werden, um einen Wert für die Koeffizienten derart zu erhalten, daß der Fehler minimiert wird. Diese Betrachtung wird im Folgenden diskutiert.

Forderung 5

Der Aufwand der Ausführung der Abfragen SEQ(n,i) und SEQ(n, i+1) sind außer für die COMP2-Komponente des Auf wandes, aufgrund der Tatsache, daß sie verschiedene Anzahlen von Tupels auswählen, identisch.

Aus dieser Betrachtung ist das folgende Experiment aufge baut:

- Schätze SEQ(n,i) und SEQ(n+1,i) unter Verwendung eines Gleichheitsprädikates auf C₄ ab und betrachte den Auf wand.
- Wissend, daß das System eine Folgeabtastung auswählen wird, Auflösen für den Koeffizienten CS2_SS.

Mit ähnlichen Experimenten mit C₁ und C₃ können die Koef fizienten CS2_ci und CS2_ui für gruppierte Indizes bzw. für ungruppierte Indizes berechnet werden. Wie vorher beim Projizieren des Wertes von C₁ mit der Selektion für C₁ kann der Koeffizient CS2_io durch Anwendung eines ähnlichen obigen Verfahrens berechnet werden.

Aufgrund des Wissens, daß CS1_SS und CS2_SS für die Aufwands formel für Folgeabtastung stehen, kann CS0_SS aus dem ent sprechend beobachteten Aufwand für SEQ(*,*) berechnet werden.

Die Gabelung von CS1_SS in CS1_SSio und CS1_SSCPU wird durch doppeltes Abtasten einer Tabelle während derselben Abfrage auf die Art und Weise getan, wie es durch die folgende SQL Abfrage spezifiziert ist:

select t1.C6 from R_n t1, R_n t2
where t1.C6 = t2.C6 & t1.C6 < C

Es wird darauf hingewiesen, daß die Berechnung von CS1_io, CS1_ci und CS2_ui ein Problem darstellt. Da erwartet wird, daß diese Werte verglichen mit anderen Komponenten klein sind, ist eine sorgfältige Bearbeitung mit einem annehmbaren Grad von Genauigkeit schwierig. Deshalb wird die Annahme ge troffen, daß diese Koeffizienten denselben Wert haben wie CS2_ci. Der Hauptaufwand des anfänglichen Nachschauens im Indexbaum ist der amortisierte Eingabe/Ausgabeaufwand des Holens der Indexseite. Nachdem der Indexbaum normalerweise gruppiert ist, sollte dieser Aufwand ähnlich dem Abrufen der Datenseite aus einem gruppierten Index, d. h. CS2_ci sein. Die Bestätigung durch Allbase, DB2 und Informix bestätigten diesen Standpunkt.

Folglich können die Koeffizienten in den Aufwandsformeln für eine Auswahl durch Anwendung einer Reihe von Beobachtungen von Abfragen berechnet werden.

Es ist zu beachten, daß ähnliche Experimente unter Verwen dung von C₂, C₅ und C₆ gemacht werden können, um die Koef fizienten für die Ungleichheitsauswahloperation zu berech nen.

Als nächstes wird das Verfahren, um den Aufwand zum Anordnen einer Relation festzustellen, umrissen. Dies wird in den Aufwandsformeln für die geordnete Vermischung benötigt. Dies erfolgt durch Verbindung von zwei R_n′s, auf die Art und Wei se, wie sie durch die folgende SQL-Abfrage definiert wird:

select t1.C4 from Rn1 t1 Rn2 t2
where t1.C4 = t2.C4 & t1.C6 + t2.c6 < c

Es wird darauf hingewiesen, daß die erste Bedingung als Verbindungsbedingung bevorzugt ist und daß C₄ keinen Index hat. Deshalb wird der geordnete Mischungsalgorithmus verwendet, um die Verbindung zu berechnen. Die Ausgabe kann durch die entsprechende Wahl der Konstanten variiert werden. Durch Anwendung der Beobachtung auf Abfragen auf eine Relation mit variabler Größe der Ausgabe kann die Konstante CJ2_mg abgeleitet werden. Ferner kann dieselbe Abfrage für drei oder vier Werte von n berechnet werden und der Aufwand zum Sortieren der Relation kann aus dem Wissen des Aufwandes für Abfolgeabtastung abgeleitet werden.

Durch Verwendung der Aufwandsformel für Auswahl und Ordnen können wir den Aufwand von Verbindungen ohne Vorhersehbar keitsprobleme berechnen.

Theorem

Die Koeffizienten der Aufwandsformeln werden ohne die unvorhersehbaren Probleme berechnet.

Es wird darauf hingewiesen, daß die Machbarkeit dieses An satzes auf folgenden zwei Annahmen beruht:

- Einige Relationen können in den teilnehmenden DBMS ge speichert werden, entweder als ein Multidatenbankan wender des Systems, oder, wenn solche Privilegien für den Multidatenbankanwender nicht verfügbar sind, dann durch besondere Anfrage an den Datenbankverwalter. Diese Relationen werden zeitlich für die Kalibrierung benutzt und werden nach der Kalibrierung nicht weiter gebraucht.
- Das beobachtete Verhalten der Abfragen ist wiederholbar in dem Sinne, daß der Effekt von anderen gleichzeitigen Abläufen die Betrachtungen nicht stört.

Praktische Kalibrierungen

Durch Verwendung der oben beschriebenen Technik, um die Koeffizienten der Aufwandsformeln zu berechnen, können die drei kommerziellen DBMSs, Allbase, DB2 und Informix kali briert werden, d. h. die Koeffizienten der Aufwandsformeln berechnet werden. Die Experimente sind derart aufgebaut, daß meistens Einzeltabellenabfragen angewendet werden. Das er folgt nicht nur, weil die Verbindungsabfragen sehr zeit aufwendig sind und es deshalb lange dauert, um das System zu kalibrieren, sondern weil auch die Kosten der meisten Ver bindungsabfragen durch Anwendung der Kosten von Einzel tabellenabfragen abgeschätzt werden können. Zur Bestätigung wurden verschiedene Arten von Verbindungsabfragen in dieser Fallstudie durchgeführt und der abgeschätzte Aufwand wurde mit dem tatsächlich beobachteten Aufwand verglichen. Das Ergebnis deutete darauf hin, daß die Koeffizienten bis zu einem Umfang abgeschätzt werden können, daß die folgende Ab schätzung der Verbindungsabfragen innerhalb von 20% der tat sächlichen Betrachtungen lagen. Dies sind die in der Fall studie gestellten Abfragen und die kalibrierten Koeffizienten.

Die kalibrierten Systeme waren ein Allbase-DBMS (Version HP 36217-02A. 07.00.17), das auf einer HP/835-RISC-Workstation lief, ein DB2-DBMS (Version V2.2), das auf einem IBM-3090- Mainframe lief, und ein Informix-DBMS (Version 4.00.UE2), das auf einer HP/850-RISC-Workstation lief. Die Kalibrie rungen wurden während der Nacht durchgeführt, 06996 00070 552 001000280000000200012000285910688500040 0002004323947 00004 06877während der die DB2 vergleichsweise gering belastet war, wohingegen die Allbase und Informix keinen anderen Mitstreiter hatten. Die DB2- und Informix-DBMSs waren für eine Produktionsanwendung geplant und wurden aufgebaut, um ihren Anwendungen zu entsprechen. Aus diesem Grund und ebenso aus Respekt vor der Autonomie dieser Installation wurden die Systemparameter nicht geändert.

Es gibt 16 Relationen, vergleiche Fig. 9, die mit diesen Ka librierungen verwendet wurden. Jeder Typ der Relation wurde mit zwei Größen von Tupels dargestellt und die kleinere Tupelrelation wurde verdoppelt. Diese Verdoppelung erfolgt, da die Verbindungsabfragen zwei identische Relationen er fordern. Relationen vom Typ R₁₀, R₁₃, R₁₅ und R₁₇ wurden bei der Kalibrierung von Allbase und Informix verwendet, wohin gehend die Relationen von Typ R₁₃, R₁₅, R₁₇ und R₂₀ bei der Kalibrierung von DB2 verwendet wurden. Diese Wahl ist abhän gig vom verfügbaren Plattenraum. Der Kalibrierungsablauf ist identisch.

Die tatsächlichen Abfragen, vgl. Fig. 10, die bei der Kalibrierung benutzt wurden, sind gegeben, wobei R_n eine Tabelle der Kardinalität 2ⁿ und c eine Konstante ist, die die Selektivität festlegt. Für jeden Typ von Abfrage gege nüber R_n wurde ein Satz von Abfragen mit einer Selektivität 2^-i (i = 1, 2, . . . , n) aufgebaut und betrachtet.

Für jede Abfrage wurde die verstrichene Zeit in dem DBMS aufgezeichnet. Für DB2 wird die verstrichene Zeit als ver strichene Zeit nach Klasse 2 definiert. Für Allbase und Informix wird die verstrichene Zeit durch Abziehen des Startzeitzeigers (wann die Anfrage erhalten wird) von dem Endzeitzeiger (wann das Ergebnis abgeschickt wurde) be rechnet. In allen DBMSs wurden die Abfragen nach Leerung aller Puffer gestellt, um eine Störung aufgrund von Puf ferung auszuschließen. Jede Abfrage wird dreißigmal ausge führt und die durchschnittliche verstrichene Zeit wird be rechnet. Außer bei einigen wenigen Fällen war der relative Fehler zwischen den tatsächlichen Daten und einem durch schnittlichen Wert innerhalb von 5% mit einem Vertrauens koeffizienten von 95%. Folglich war die Wiederholbarkeit der Beobachtung gesichert.

Aus diesen Beobachtungen können die Koeffizienten für die Aufwandsformeln für Allbase, DB2, und Informix abgeleitet werden. Eine Anpassung nach dem Algorithmus des kleinsten Fehlerquadrates wurde angewendet, um den Fehler zu minimieren und die Koeffizienten, die in Fig. 11 dargestellt sind, abzuschätzen. Fig. 13 zeigt die verstrichene Zeit für Abfragen nach dem Typ 3.1, der auf DB2 für die Relationen R₁₃ und R₁₇ läuft, zusammen mit der abgeschätzten Zeit durch die Aufwandsformel, die abhängig ist von der Größe der Relation. Dies bestätigt zwei Tatsachen:

1. Die DB2-Zugriffe auf die Abfragen, die nur den Index be nutzen, sind nicht empfindlich gegenüber der Größe der Relation;
2. Die Abschätzung, die für CS1_io verwendet wurde, beein trächtigt die Genauigkeit nicht.

Wie erkannt werden kann, ist der Fehler recht klein und dies war für alle Tests, die die obigen Abfragen benutzten, so.

Um den Effekt von mehreren Auswahl- und Projektionssätzen zu untersuchen, wurden die zwölf Grundabfragen auf DB2 verän dert. Die neuen Abfragen haben bis zu fünf Prädikate und gaben bis zu fünf Attribute zurück. Es folgend zwei Bei spielabfragen.

select C1, C2, C3, C4, C5 from R_n where C5 < c select C5 from Rn
where C5 < c & C1 <=0 & C2 <=0 & C3 <=0 & C4 <=0

Es ist darauf zu achten, daß in der zweiten Abfrage die <= Prädikate für alle Tupels erfüllt sind. Dies garantiert, daß sie nur nach solchen Tupels überprüft werden, die dem ersten (originalen) Prädikat nachfolgen.

Das Ergebnis der Experimente zeigt, daß in allen Fällen die Unterschiede im Bereich von 10% liegen. Es scheint sich an zubieten, daß der Aufwand zum Projizieren zusätzlicher Spal ten vernachlässigbar ist, wenn das Tupel einmal im Speicher ist. Der Aufwand, die Prädikate zu überprüfen, ist ver glichen mit anderen Verarbeitungsaufwänden (z. B. Ein gabe/Ausgabe dazu) ebenfalls minimal.

Die obigen Aufwandsformeln wurden durch Verwendung der 36 Typen von Verbindungsabfragen, die in Fig. 12 gezeigt sind, ebenfalls bestätigt. Abfragen vom Typ 1.1 bis 2.9 geben 2²ⁱ Tupels zurück, abhängig von der Konstante c, wobei i=0,1, . . . , n ist. In dieser Bestätigung wurden Verbindungen von Selektivität 2^2k für k<(n-4) getestet. Abfragen vom Typ 3.1 bis 4.9 gaben 2ⁱ Tupels abhängig von c, wobei i<=min(n,m) ist, zurück. Verbindungen von Selektivität 2^k für k<min(n,m)^-4 wurden getestet. In beiden Fällen wurde der beobachtete Wert mit dem abgeschätzten Wert verglichen.

Fig. 14 zeigt den Vergleich zwischen den abgeschätzten Wer ten mit den beobachteten Werten für die Typ 3.1 Verbindungs abfrage, die auf DB2 läuft, unter Verwendung von Paaren der Relationen R13¹ R13², R17¹ R17² und R13 R17. (wobei eine Verbindung darstellt). Es ist anzumerken, daß in diesem Fall die DB2 verschachtelte Schleifen als das Verbindungs verfahren und ein Zugriffsverfahren, das nur den Index be nutzt, wählt. Deshalb sollte in allen drei Fällen der Auf wand unabhängig von der Kardinalität der zwei Relationen sein. Dies wird beobachtet durch Verweisen auf den Graph der in Fig. 14 gezeigt ist, in dem der maximale Fehler etwa 10% beträgt. Dies bestätigt wiederum das Aufwandsmodell und die Abschätzungen.

In Fig. 15 und Fig. 16 sind die Verbindungen, die Mischsor tierung mit R17¹ R17² bzw. R13 R17 auf DB2 dar. Es ist zu beachten, daß der abgeschätzte Aufwand wiederum innerhalb eines 10%-igen Fehlers liegt.

Das Ergebnis dieser Bestätigung beweist, daß in mehr als 80% der Fälle die beobachteten Werte innerhalb eines Fehlerban des von 20% von den abgeschätzten Werten lagen. Ferner trug in allen anderen Fällen das folgende Phänomen zu der Mehr heit der Fehler bei. Alle diese Fälle traten auf, als das System ungruppierte Indizes in der inneren Schleife der verschachtelten Schleifenverbindung benutzte. Wenn der Auf wand CS_ui als einzelne Abfrage berechnet wird, unterschätzte die mögliche Pufferung von Seiten den Aufwand dieses Zu griffs auf die innere Schleife der Verbindung, wo sie sich mit bewirbt für Puffer in der äußeren Schleife. Folglich war die Abschätzung immer niedriger. Dies ist ein Punkt für zu künftige Verbesserungen.

Claims

1. Verfahren zum Steuern von Datenbankabfragen in einem heterogenen, verteilten Datenbanksystem, mit
einer ersten Datenbankanlage, die ein erstes relatio nales Datenbank-Managementsystem (DBMS) und eine zugehörige Datenbank umfaßt; und
einer zweiten Datenbankanlage, die ein zweites rela tionales Datenbank-Managementsystem (DBMS) und eine zugehörige Datenbank umfaßt;
wobei sich die ersten und zweiten relationalen Daten bank-Managementsysteme voneinander unterscheiden, aber mindestens in einer vorbestimmten strukturierten Ab fragesprache übereinstimmen; gekennzeichnet durch folgende Schritte:

- Aufbauen einer Modelldatenbank, in der alle Reihen, Spalten und Strukturen bekannt sind und gesteuert wer den;
- Durchführen einer Reihe von Zugriffstests auf die Mo delldatenbank unter Verwendung der vorbestimmten strukturierten Abfragesprache jedes teilnehmenden Datenbank-Managementsystemes;
- Ableitung von Zugriffsaufwandsdaten für jedes teilneh mende Datenbank-Managementsystem entsprechend der Zu griffstests;
- Speichern der Zugriffsaufwandsdaten als ein Aufwands modell in einem Daten-Wörterbuch/Katalog;
- Ermitteln eines optimalen Anwendungsplanes für nach folgende verteilte Datenbankabfragen, gestützt auf das Aufwandsmodell, das in dem Daten-Wörterbuch/Katalog gespeichert ist, und
- Ausführen von folgenden Abfragen, um Daten von den verteilten Datenbanken entsprechend des optimalen An wendungsplanes zurückzuerhalten.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß der Modelldatenbankaufbau die folgenden Schritte aufweist:

- Erstellen einer synthetischen Datenbank als Modell datenbank, wobei für eine ganze Zahl "n" R_n eine Relation von sieben Spalten, die 2ⁿ Tupels enthält, ist, und jede der sieben Spalten, (Cn, wobei n = [1 . . 7]) die folgenden Attribute hat:
- C₁: eine ganze Zahl [0,n], indiziert und gruppiert;
- C₂: eine ganze Zahl [0,2ⁿ-1], indiziert, defacto gruppiert, aber nicht für die DBMS als solche spezifiziert;
- C₃: eine ganze Zahl [0,n], indiziert und ungruppiert;
- C₄: eine ganze Zahl [0,n] ohne Index;
- C₅: eine ganze Zahl [0,2ⁿ-1], indiziert und ungruppiert;
- C₆: eine ganze Zahl [0,2ⁿ-1] ohne Index; und
- C₇: eine lange Buchstabenkette, um der Größe der Tupelanforderung zu entsprechen;
- Setzen des Wertes des siebten Attributs als ein Ausfüllfeld; und
- Setzen eines Multispaltenschlüssels für die Relation auf C₁, C₂ derart, daß die Relation auf diesem Schlüssel in aufsteigender Reihenfolge, mit C₁ als der Hauptschlüssel und C₂ als der untergeordnete Schlüssel, indiziert ist.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeich net, daß die Reihe von Zugriffstests folgende Schritte umfaßt:

- Anwenden von einem Minimum von zwölf individuellen Ab fragen auf jedes teilnehmende Datenbank-Management system (DBMS); und
- Aufstellen jeder Abfrage mindestens dreißig mal, um eine statistisch signifikante Abtastung abzuleiten.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch ge kennzeichnet, daß der Schritt des Ableitens von Zugriffsaufwandsdaten das Anwenden einer Anpassung nach dem Algorithmus des kleinsten quadratischen Fehlers umfaßt, um die Fehler zu verringern und die Aufwandskoeffizienten abzuschätzen.

5. Verfahren nach einem der Ansprüche 1 bis 4, gekenn zeichnet durch folgende Schritte:

- Strukturieren des Aufwandsmodelles entsprechend einer logischen Ausführung der Datenbankabfragen; und
- Abschätzen des Aufwandes einer gegebenen Abfrage basierend auf logischen Charakteristika jedes teil nehmenden Datenbank-Managementsystems (DBMS), auf logischen Relationen zwischen den in den Datenbanken gespeicherten Daten und auf einer logischen Struktur der Abfrage.

6. Verfahren nach Anspruch 5, gekennzeichnet durch Abschätzen des Aufwandes einer umfangreichen Abfrage durch Verwendung eines Satzes von einfachen Abfragen.

7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß das Aufwandsmodell ein logisches Aufwandsmodell ist.

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß das logische Aufwandsmodell logische Aufwandsformeln zum Optimieren der Abfrage in jeder Datenbank in dem System und Zugriffsaufwandsdaten mit Aufwandskoeffizien ten zur Verwendung in den logischen Aufwandsformeln zum Kalibrieren des Aufwandsmodells aufweist.