Zur Verbesserung von Statistikdaten in relativen Datenbanksystemen werden seit einigen Jahren Verfahren fu¨r das Finden von Korrelationen zwischen zwei oder mehr Spalten entwickelt. Dieses Wissen u¨ber Korrelationen ist notwendig, weil der Optimizer des Datenbankmanagementsystems (DBMS) bei der Anfrageplanerstellung sonst von Unabha¨ngigkeit der Daten ausgeht, was wiederum zu groben Fehlern bei der Kostenscha¨tzung und somit zu schlechten Ausfu¨hrungspla¨nen fu¨hren kann. Die entsprechenden Verfahren gliedern sich grob in proaktive und reaktive Verfahren: Erstere liefern ein gutes Gesamtbild u¨ber sa¨mtliche vorhandenen Daten, mu¨ssen dazu allerdings selbst regelma¨ßig auf die Daten zugreifen und beno¨tigen somit Kapazita¨t des DBMS. Letztere u¨berwachen und analysieren hingegen die Anfrageergebnisse und liefern daher nur Korrelationsannahmen fu¨r bereits abgefragte Daten, was einerseits das bisherige Nutzerinteresse sehr gut widerspiegelt, andererseits aber bei A¨ nderungen des Workloads versagen kann. Dafu¨r wird einzig bei der U¨ berwachung der Anfragen DBMS-Kapazita¨t beno¨tigt, es erfolgt kein eigensta¨ndiger Zugriff auf die Daten. Im Zuge dieser Arbeit werden beide Ansa¨tze miteinander verbunden, um ihre jeweiligen Vorteile auszunutzen. Dazu werden die sich ergebenden Herausforderungen, wie sich widersprechende Korrelationsannahmen, aufgezeigt und als Lo¨sungsansatz u. a. der zusa¨tzliche Einsatz von reaktiv erstellten Statistiken vorgeschlagen.
1.
Die Verwaltung großer Datenmengen beno¨tigt zunehmend leistungsfa¨higere Algorithmen, da die Verbesserung der Technik (Hardware) nicht mit dem immer ho¨heren Datenaufkommen heutiger Zeit mithalten kann. Bspw. werden wissenschaftliche Messergebnisse aufgrund besserer Messtechnik immer genauer und umfangreicher, sodass Wissenschaftler sie detaillierter, aber auch umfassender analysieren wollen und mu¨ssen, oder Online-Shops speichern sa¨mtliche ihrer Verkaufsdaten und werten sie aus, um dem Benutzer passend zu seinen Interessen zeitnah und individuell neue Angebote machen zu ko¨nnen.
Zur Verwaltung dieser wie auch anderer Daten sind (im Datenbankbereich) insbesondere schlaue Optimizer gefragt, weil sie fu¨r die Erstellung der Anfragepla¨ne (und somit fu¨r die Ausfu¨hrungszeit einer jeden Anfrage) verantwortlich sind. Damit sie in ihrer Wahl nicht vo¨llig daneben greifen, gibt es Statistiken, anhand derer sie eine ungefa¨hre Vorstellung bekommen, wie die vorhandene Datenlandschaft aussieht. Hierbei ist insbesondere die zu erwartende Tupelanzahl von Interesse, da sie in hohem Maße die Ausfu¨hrungszeit einer Anfrage beeinflusst. Je besser die Statistiken die Verteilung der Daten wiedergeben (und je aktueller sie sind), desto besser ist der resultierende Ausfu¨hrungsplan. Sind die Daten unkorreliert (was leider sehr unwahrscheinlich ist), genu¨gt es, pro zu betrachtender Spalte die Verteilung der Werte innerhalb dieser Spalte zu speichern. Treten in diesem Fall spa¨ter in den Anfragen Kombinationen der Spalten auf, ergibt sich die zu erwartende Tupelanzahl mithilfe einfacher statistischer Weisheiten (durch Multiplikation der Einzelwahrscheinlichkeiten).
Leider versagen diese ab einem bestimmten Korrelationsgrad (also bei korrelierten Daten), und zwar in dem Sinne, dass die vom Optimizer berechneten Scha¨tzwerte zu stark von der Wirklichkeit abweichen, was wiederum zu schlechten Ausfu¨hrungszeiten fu¨hrt. Diese ließen sich u.U. durch die Wahl eines anderen Plans, welcher unter Beru¨cksichtigung der Korrelation vom Optimizer erstellt wurde, verringern oder sogar vermeiden.
Zur Veranschaulichung betrachten wir eine Tabelle, welche u. a. die Spalten A und B besitzt, und eine Anfrage, welche Teile eben dieser Spalten ausgeben soll. Desweiteren liege auf Spalte B ein Index, den wir mit IB bezeichnen wollen, und es existiere ein zusammengesetzter Index IA,B fu¨r beide Spalten. Beide Indizes seien im DBMS mithilfe von Ba¨umen (bspw. B∗-Ba¨ume) implementiert, sodass wir auch (etwas informell) von flachen“ oder hohen“ Indizes spre” ” chen ko¨nnen.
Sind beide Spalten unkorreliert, so lohnt sich in der Regel
die Abfrage u¨ber IA,B. Bei einer starken Korrelation
beider Spalten dagegen ko¨nnte die alleinige Verwendung von
IB vorteilhaft sein, und zwar wenn die Werte aus Spalte A
i.d.R. durch die Werte aus Spalte B bestimmt werden (ein
typisches Beispiel, welches auch in CORDS [
Das Wissen u¨ber Korrelationen fa¨llt aber natu¨rlich nicht vom Himmel, es hat seinen Preis. Jeder Datenba¨nkler hofft, dass seine Daten unkorreliert sind, weil sein DBMS dann weniger Metadaten (also Daten u¨ber die Daten) speichern und verwalten muss, sondern auf die bereits erwa¨hnten statistischen Weisheiten zuru¨ckgreifen kann. Sind die Daten dagegen (stark) korreliert, la¨sst sich die Erkenntnis daru¨ber nicht so einfach wie die Unabha¨ngigkeit mit (anderen) statistischen Weisheiten verbinden und somit abarbeiten“. ”
Nicht jede (eher kaum eine) Korrelation stellt eine (schwache) funktionale Abha¨ngigkeit dar, wie es im Beispiel der Fall war, wo wir einfach sagen konnten Aus der Marke folgt ” die Firma (bis auf wenige Ausnahmen)“. Oft lieba¨ugeln bestimmte Werte der einen Spalte mit bestimmten Werten anderer Spalten, ohne sich jedoch in irgendeiner Weise auf diese Kombinationen zu beschra¨nken. (In Stuttgart gibt es sicherlich eine Menge Porsches, aber die gibt es woanders auch.) Außerdem a¨ndern sie mo¨glicherweise mit der Zeit ihre Vorlieben (das Stuttgarter Porschewerk ko¨nnte bspw. nach China umziehen) oder schaffen letztere vo¨llig ab (wer braucht schon einen Porsche? Oder u¨berhaupt ein Auto?).
Deswegen werden fu¨r korrelierte Daten zusa¨tzliche Statistiken beno¨tigt, welche nicht nur die Werteverteilung einer, sondern die Werteverteilung mehrerer Spalten wiedergeben. Diese zusa¨tzlichen Statistiken mu¨ssen natu¨rlich irgendwo abgespeichert und, was noch viel schlimmer ist, gewartet werden. Somit ergeben sich zusa¨tzlicher Speicherbedarf und zusa¨tzlicher Aufwand, also viel zu viel von dem, was keiner so richtig will.
Da sich ein bisschen statistische Korrelation im Grunde u¨berall findet, gilt es, die Korrelationen ausfindig zu machen, welche unsere statistischen Weisheiten alt aussehen lassen und dazu fu¨hren, dass das Anfrageergebnis erst nach einer gefu¨hlten halben Ewigkeit ausgeben wird. Ob letzteres u¨berhaupt passiert, ha¨ngt natu¨rlich auch vom Anfrageverhalten auf die Datenbank ab. Wenn die Benutzer sich in ihren (meist mithilfe von Anwendungsprogrammen abgesetzten) SQL-Anfragen in der WHERE-Klausel jeweils auf eine Spalte beschra¨nken und auf jedwede Verbu¨nde (Joins) verzichten, dann ist die Welt in Ordnung. Leider lassen sich Benutzer nur ungern so stark einschra¨nken.
Daher gibt es zwei grundsa¨tzliche Mo¨glichkeiten: Entweder schauen wir dem Benutzer auf die Finger und suchen in den von ihm abgefragten Daten nach Korrelationen (das entspricht einer reaktiven Vorgehensweise), oder wir suchen uns selbst“ ein paar Daten der Datenbank ”aus“, ”die wir untersuchen wollen (und gehen somit proaktiv vor). Beide Vorgehensweisen haben ihre Vor- und Nachteile. Wa¨hrend im reaktiven Fall keine Daten speziell zur Korrelationsfindung angefasst“ werden mu¨ssen, hier aber alle Daten, die bis zu”einer bestimmten Anfrage nie abgefragt wurden, als unkorreliert gelten, mu¨ssen wir fu¨r die proaktive Methode (also nur zum Feststellen, ob Korrelation vorherrscht) extra Daten lesen, sind aber fu¨r (fast) alle Eventualita¨ten gewappnet.
Interessanterweise kann es vorkommen, dass beide Methoden fu¨r ein und dieselbe Spaltenkombination unterschiedliche Ergebnisse liefern (der Einfachheit halber beschra¨nken wir uns hierbei auf die mo¨glichen Ergebnisse korre” liert“ oder unabha¨ngig“). Fu¨r den Fall, dass die reaktive ” Methode eine Spaltenkombination gar nicht betrachtet hat, sollte das klar sein. Aber nehmen wir an, dass die Kombination von beiden Methoden analysiert wurde. Da fu¨r die Analyse ho¨chstwahrscheinlich jeweils unterschiedliche Tupel (Wertekombinationen) verwendet wurden, ko¨nnen sich natu¨rlich auch die Schlu¨sse unterscheiden. Hier stellt sich nun die Frage, welches Ergebnis ”besser“ ist. Dafu¨r gibt es keine allgemeine Antwort, gehen wir aber von einer moderaten A¨ nderung des Anfrageverhaltens aus, ist sicherlich das reaktive Ergebnis“ kurzfristig entscheidender, wa¨hrend das ”proaktive Ergebnis“ in die la¨ngerfristige Planung der Sta” tistikerstellung mit aufgenommen werden sollte. 2.
Wie in der Einleitung bereits angedeutet, ko¨nnen
Korrelationen einem Datenbanknutzer den Tag vermiesen. Um dies
zu verhindern, wurden einige Methoden vorgeschlagen,
welche sich auf verschiedene Art und Weise dieser Problematik
annehmen (z. B. [
Proaktiv zu handeln bedeutet, etwas auf Verdacht“ zu ” tun. Impfungen sind dafu¨r ein gutes Beispiel – mithilfe einer Impfung ist der Ko¨rper in der Lage, Krankheitserreger zu beka¨mpfen, aber in vielen Fa¨llen ist unklar, ob er diese Fa¨higkeit jemals beno¨tigen wird. Da Impfungen auch mit Nebenwirkungen verbunden sein ko¨nnen, muss jeder fu¨r sich entscheiden, ob und wogegen er sich impfen la¨sst.
Auch Datenbanken ko¨nnen geimpft“ werden, allerdings ” handelt es sich bei langen Anfrageausfu¨hrungszeiten (die wir ja beka¨mpfen wollen) eher um Symptome (wie Bauchschmerzen oder eine laufende Nase), die natu¨rlich unterschiedliche Ursachen haben ko¨nnen. Eine davon bilden ganz 1Da die Verfahren direkt in die Anfrageplanerstellung eingreifen und dabei auf ihr Wissen u¨ber Korrelationen aufbauen, muss, fu¨r ein korrektes Anfrageergebnis, dieses Wissen aktuell und vollsta¨ndig sein. klar Korrelationen zwischen den Daten, wobei natu¨rlich erst ein gewisses Maß an Korrelation u¨berhaupt als ”krankhaft“ anzusehen ist. (Es beno¨tigt ja auch eine gewisse Menge an Bakterien, damit eine Krankheit mit ihren Symptomen ausbricht.) Der grobe Impfvorgang“ gegen“ Korrelationen um” ” fasst zwei Schritte: 1. Es werden Vermutungen aufgestellt, welche Spaltenkombinationen fu¨r spa¨tere Anfragen eine Rolle spielen ko¨nnten. 2. Es wird kontrolliert, ob diese Kombinationen von Korrelation betroffen sind oder nicht.
Entscheidend dabei ist, dass die Daten bzw. ein Teil der Daten gelesen (und analysiert) werden, und zwar ohne damit konkrete Anfragen zu bedienen, sondern rein zur Ausfu¨hrung des Verfahrens bzw. der Impfung“ (in diesem Fall ” gegen“ Korrelation, wobei die Korrelation natu¨rlich nicht ” beseitigt wird, schließlich ko¨nnen wir schlecht den Datenbestand a¨ndern, sondern die Datenbank lernt, damit umzugehen). Das Lesen und Analysieren kostet natu¨rlich Zeit, womit klar wird, dass auch diese Impfung“ Nebenwirkungen“ ” ” mit sich bringt.
Eine konkrete Umsetzung haben Ilyas et al., aufbauend
auf BHUNT [
Es geht folgendermaßen vor: Im ersten Impfschritt“ sucht
”
es mithilfe des Katalogs oder mittels Stichproben nach
Schlu¨ssel-Fremdschlu¨ssel-Beziehungen und fu¨hrt somit eine Art
Ru¨ckabbildung von Datenbank zu Datenmodell durch (engl.
reverse engineering“) [
Zudem gibt es zusa¨tzliche Reduktionsregeln (engl. ”pruning rules“) fu¨r das Finden der Beziehungen und fu¨r die Auswahl der zu betrachtenden Spaltenkombinationen. Schließlich kann die Spaltenanzahl sehr hoch sein, was die Anzahl an mo¨glichen Kombinationen gegebenenfalls ins Unermessliche steigert.
Im zweiten ”Impfschritt“ wird fu¨r jede Spaltenkombination eine Stichprobe entnommen und darauf aufbauend eine Kontingenztabelle erstellt. Letztere dient dann wiederum als Grundlage fu¨r einen Chi-Quadrat-Test, der als Ergebnis eine Zahl χ2 ≥ 0 liefert. Gilt χ2 = 0, so sind die Spalten vollsta¨ndig unabha¨ngig. Da dieser Fall aber in der Praxis kaum auftritt, muss χ2 einen gewissen Schwellwert u¨berschreiten, damit die entsprechende Spaltenkombination als korreliert angesehen wird. Zum Schluss wird eine Art Rangliste der Spaltenkombinationen mit den ho¨chsten χ2-Werten erstellt und fu¨r die obersten n Kombinationen werden zusa¨tzliche Statistikdaten angelegt. Die Zahl n ist dabei u. a. durch die Gro¨ße des Speicherplatzes (fu¨r Statistikdaten) begrenzt. 2Die Begrenzung wird damit begru¨ndet, dass auf diese Weise das beste Aufwand-Nutzen-Verha¨ltnis entsteht. Das Verfahren selbst ist nicht auf Spaltenpaare beschra¨nkt. 2.2
Wa¨hrend wir im vorherigen Abschnitt Vermutungen aufgestellt und auf Verdacht gehandelt haben, um den Datenbankbenutzer glu¨cklich zu machen, gehen wir jetzt davon aus, dass den Benutzer auch weiterhin das interessieren wird, wofu¨r er sich bis jetzt interessiert hat.
Wir ziehen also aus der Vergangenheit Ru¨ckschlu¨sse fu¨r die Zukunft, und zwar indem wir den Benutzer bei seinem Tun beobachten und darauf reagieren (daher auch die Bezeichnung ”reaktiv“). Dabei achten wir nicht allein auf die gestellten SQL-Anfragen, sondern u¨berwachen viel mehr die von der Datenbank zuru¨ckgegebenen Anfrageergebnisse. Diese verraten uns na¨mlich alles (jeweils 100-prozentig aktuell!) u¨ber den Teil der vorhandenen Datenlandschaft, den der Benutzer bis jetzt interessant fand.
Auf diese Weise ko¨nnen bspw. Statistiken erzeugt werden
[
In [
Wa¨hrend in [
In [
Zur Verdeutlichung wollen wir die Tabelle aller Firmenwagen eines großen, internationalen IT-Unternehmens betrachten, in welcher zu jedem Wagen u. a. seine Farbe und die Personal- sowie die Abteilungsnummer desjenigen Mitarbeiters verzeichnet ist, der den Wagen hauptsa¨chlich nutzt. Diverse dieser Mitarbeiter wiederum gehen in einem Dresdener mittelsta¨ndischen Unternehmen ein und aus, welches nur rote KFZ auf seinem Parkplatz zula¨sst (aus Kapazita¨tsgru¨nden wurde eine solche, vielleicht etwas seltsam anmutende Regelung eingefu¨hrt). Da die Mitarbeiter sich dieser Regelung bei der Wahl ihres Wagens bewusst waren, fahren sie alle ein rotes Auto. Zudem sitzen sie alle in derselben Abteilung.
Allerdings ist das internationale Unternehmen wirklich sehr groß und besitzt viele Firmenwagen sowie unza¨hlige Abteilungen, sodass diese roten Autos in der Gesamtheit der Tabelle nicht auffallen. In diesem Sinne wu¨rde das proaktive Verfahren CORDS also (eher) keinen Zusammenhang zwischen der Abteilungsnummer des den Wagen benutzenden Mitarbeiters und der Farbe des Autos erkennen.
Werden aber ha¨ufig genau diese Mitarbeiter mit der Farbe ihres Wagens abgefragt, z. B. weil sich diese kuriose Regelung des mittelsta¨ndischen Unternehmens herumspricht, es keiner so recht glauben will und deswegen die Datenbank konsultiert, so ko¨nnte ein reaktives Verfahren feststellen, dass beide Spalten korreliert sind. Diese Feststellung tritt insbesondere dann auf, wenn sonst wenig Anfragen an beide betroffenen Spalten gestellt werden, was durchaus mo¨glich ist, weil sonst die Farbe des Wagens eine eher untergeordnete Rolle spielt.
Insbesondere der letztgenannte Umstand macht deutlich, dass es nicht sinnvoll ist, Statistikdaten fu¨r die Gesamtheit beider Spalten zu erstellen und zu warten. Aber die Tatsache, dass bestimmte Spezialfa¨lle fu¨r den Benutzer besonders interessant sein ko¨nnten, die mo¨glicherweise eben gerade mit Korrelation einhergehen, spricht wiederum fu¨r eine Art ”Hinweis“ an den Optimizer. 4.
Da CORDS wie auch das Verfahren aus [
Zudem wollen wir davon ausgehen, dass das proaktive Verfahren in einem gedrosselten Modus ausgefu¨hrt wird und somit sukzessive seine Rangliste befu¨llt. (Zusa¨tzliche Wartungszeitra¨ume, bei denen das Verfahren ungedrosselt laufen kann, beschleunigen die Arbeit und bilden somit einen scho¨nen Zusatz, aber da heutzutage viele Datenbanken quasi dauerhaft laufen mu¨ssen, wollen wir sie nicht voraussetzen.) Das reaktive Verfahren dagegen wird zu bestimmten Zeitpunkten gestartet, um die sich bis dahin angesammelten Beobachtungen zu analysieren, und gibt nach beendeter Analyse seine Rangliste bekannt. Da es als Grundlage nur die Daten aus dem Query-Feedback-Warehouse beno¨tigt, kann es vo¨llig entkoppelt von der eigentlichen Datenbank laufen.
Ist die reaktive Rangliste bekannt, kann diese mit der (bis dahin angefertigten) proaktiven Rangliste verglichen werden. Tritt eine Spaltenkombination in beiden Ranglisten auf, so bedeutet das, dass diese Korrelation fu¨r die bisherigen Anfragen eine Rolle gespielt hat und nicht nur auf Einzelfa¨lle beschra¨nkt ist, sondern auch mittels Analyse einer repra¨sentativen Stichprobe an Wertepaaren gefunden wurde.
Unter diesen Umsta¨nden lassen wir mittels einer Stichprobe Statistikdaten fu¨r die betreffende Spaltenkorrelation erstellen. Dabei wa¨hlen wir die Stichprobe des proaktiven Verfahrens, solange diese ein gewisses Alter nicht u¨berschritten hat. Ist sie zu alt, wird eine neue Stichprobe entnommen.4
Interessanter wird es, wenn nur eines der Verfahren auf Korrelation tippt, wa¨hrend das andere Verfahren die entsprechende Spaltenkombination nicht in seiner Rangliste entha¨lt. Die Ursache dafu¨r liegt entweder darin, dass letzteres Verfahren die Kombination noch nicht analysiert hat (beim reaktiven Verfahren heißt das, dass sie nicht oder zu selten in den Anfragen vorkam), oder bei seiner Analyse zu dem Ergebnis ”nicht korreliert“ gekommen ist.
Diese Unterscheidung wollen wir insbesondere in dem Fall
vornehmen, wenn einzig das reaktive Verfahren die
Korrelation ”entdeckt“ hat. Unter der Annahme, dass weitere,
¨ahnliche Anfragen folgen werden, beno¨tigt der Optimizer
schnell Statistiken fu¨r den abgefragten Bereich. Diese
sollen zuna¨chst reaktiv mithilfe der Query-Feedback-Records
aus der Query-Feedback-Warehouse erstellt werden (unter
Verwendung von bspw. [
Wir u¨berpru¨fen nun, ob das proaktive Verfahren das Spaltenpaar schon bearbeitet hat. Dies sollte anhand der Abarbeitungsreihenfolge der infrage kommenden Spaltenpaare erkennbar sein.
Ist dem so, hat das proaktive Verfahren das entsprechende Paar als ”unkorreliert“ eingestuft und wir bleiben bei den reaktiv erstellten Statistiken, die auch nur reaktiv aktualisiert werden. Veralten sie spa¨ter zu stark aufgrund fehlender Anfragen (und somit fehlendem Nutzerinteresse), ko¨nnen sie gelo¨scht werden.
Ist dem nicht so, geben wir die entsprechende
Kombination an das proaktive Verfahren weiter mit dem Auftrag,
diese zu untersuchen.5 Beim na¨chsten Vergleich der
Ranglisten muss es fu¨r das betrachtete Spaltenpaar eine konkrete
Antwort geben. Entscheidet sich das proaktive Verfahren fu¨r
”korreliert“ und befindet sich das Spaltenpaar auch wieder
4Falls die betroffenen Spalten einen Za¨hler besitzen, der bei
A¨ nderungsoperationen hochgeza¨hlt wird (vgl. z. B. [
Wenn jedoch nur das proaktive Verfahren eine bestimmte Korrelation erkennt, dann ist diese Erkenntnis zuna¨chst fu¨r die Benutzer unerheblich. Sei es, weil der Nutzer diese Spaltenkombination noch gar nicht abgefragt hat, oder weil er bis jetzt nur den Teil der Daten beno¨tigt hat, der scheinbar unkorreliert ist. In diesem Fall markieren wir nur im Datenbankkatolog (wo die Statistiken abgespeichert werden) die beiden Spalten als korreliert und geben dem Optimizer somit ein Zeichen, dass hier hohe Scha¨tzfehler mo¨glich sind und er deswegen robuste Pla¨ne zu wa¨hlen hat. Dabei bedeutet ”robust“, dass der gewa¨hlte Plan fu¨r die errechneten Scha¨tzwerte mo¨glicherweise nicht ganz optimal ist, dafu¨r aber bei sta¨rker abweichenden ”wahren Werten“ immer noch akzeptable Ergebnisse liefert. Zudem ko¨nnen wir ohne wirklichen Einsatz des reaktiven Verfahrens die Anzahl der Anfragen za¨hlen, die auf diese Spalten zugreifen und bei denen sich der Optimizer stark verscha¨tzt hat. U¨ bersteigt der Za¨hler einen Schwellwert, werden mithilfe einer neuen Stichprobe (vollsta¨ndige, also insb. mit Werteverteilung) Statistikdaten erstellt und im Katalog abgelegt.
Der Vollsta¨ndigkeit halber wollen wir hier noch den Fall erwa¨hnen, dass eine Spaltenkombination weder in der einen, noch in der anderen Rangliste vorkommt. Es sollte klar sein, dass diese Kombination als ”unkorreliert“ angesehen und somit fu¨r die Statistikerstellung nicht weiter betrachtet wird. 5.
Die hier vorgestellte Vorgehensweise zur Verbesserung der
Korrelationsfindung mittels Einsatz zweier unterschiedlicher
Verfahren muss weiter vertieft und insbesondere praktisch
umgesetzt und getestet werden. Vor allem muss ein
passendes Datenmodell fu¨r die reaktive Erstellung von
Spaltenpaarstatistiken gefunden werden. Das vorgeschlagene
Verfahren ISOMER [
Eine weitere, noch nicht vo¨llig ausgearbeitete Herausforderung bildet die Tatsache, dass das proaktive Verfahren im gedrosselten Modus la¨uft und erst sukzessive seine Rangliste erstellt. Das bedeutet, dass wir eigentlich nur Zwischenergebnisse dieser Rangliste mit der reaktiv erstellten Rangliste vergleichen. Dies kann zu unerwu¨nschten Effekten fu¨hren, z. B. ko¨nnten beide Ranglisten vo¨llig unterschiedliche Spaltenkombinationen enthalten, was einfach der Tatsache geschuldet ist, dass beide Verfahren unterschiedliche Spaltenkombinationen untersucht haben. Um solche Misssta¨nde zu vermeiden, muss die proaktive Abarbeitungsreihenfolge der Spaltenpaare u¨berdacht werden. In CORDS wird bspw. als Reduktionsregel vorgeschlagen, nur Spaltenpaare zu betrachten, die im Anfrageworkload vorkommen (dazu mu¨ssen von CORDS nur die Anfragen, aber nicht deren Ergebnisse betrachtet werden). Wu¨rde sich dann aber der Workload dahingehend a¨ndern, dass vo¨llig neue Spalten oder Tabellen abgefragt werden, ha¨tten wir dasselbe Problem wie bei einem rein reaktiven Verfahren. Deswegen muss hier eine Zwischenlo¨sung gefunden werden, die Spaltenkombinationen aus Anfragen bevorzugt ”behandelt“, sich aber nicht darauf beschra¨nkt.
Außerdem muss u¨berlegt werden, wann wir Statistikdaten, die auf Stichproben beruhen, wieder lo¨schen ko¨nnen. Im reaktiven Fall fiel die Entscheidung leicht aus, weil fehlender Zugriff auf die Daten auch ein fehlendes Nutzerinteresse widerspiegelt und auf diese Weise auch keine Aktualisierung mehr stattfindet, sodass die Metadaten irgendwann unbrauchbar werden.
Basieren die Statistiken dagegen auf Stichproben, mu¨ssen sie von Zeit zu Zeit aktualisiert werden. Passiert diese Aktualisierung ohne zusa¨tzliche U¨ berpru¨fung auf Korrelation (welche ja aufgrund gea¨nderten Datenbestands nachlassen ko¨nnte), mu¨ssen mit der Zeit immer mehr zusa¨tzliche Statistikdaten u¨ber Spaltenpaare gespeichert und gewartet werden. Der fu¨r Statistikdaten zur Verfu¨gung stehende Speicherplatz im Katalog kann so an seine Grenzen treten, außerdem kostet die Wartung wiederum Kapazita¨t des DBMS. Hier mu¨ssen sinnvolle Entscheidungen u¨ber die Wartung und ddeans.”Aufra¨umen“ nicht mehr beno¨tigter Daten getroffen wer