Database Reference
In-Depth Information
Zweck gibt es bei Oracle eine nicht dokumentierte Funktion DBMS_UTILITY.SQLID_
TO_SQLHASH, deren Beschreibung man im Header von DBMS_UTILITY finden kann.
Da eine Ziffer im 32-er System 5 Bits belegt, werden 64 Bits (8 Bytes) mit 13 Zeichen
dargestellt. Machen Sie ein Describe der View V$SQL in SQL*Plus und stellen Sie fest, dass
Oracle in der Tat einen Typ von VARCHAR2(13) für die SQL_ID benutzt.
Jetzt wissen wir genügend, um die Frage bezüglich der Eindeutigkeit der SQL Id be-
antworten zu können. Also ist die SQL Id eindeutig? Können 2 verschiedene SQL-Texte
mit derselben SQL Id existieren? Ich weiß, es ist für Sie immer noch nicht so einfach, diese
simple Frage zu beantworten. Einerseits verstehen Sie, dass es nicht möglich ist, einen be-
liebigen SQL-Text mit einem Hashwert von 8 Bytes eindeutig zu kodieren. Andererseits
scheint es aus Ihrer Erfahrung so zu sein, dass die SQL Id doch eindeutig ist, weil Ihnen
bisher nichts Gegenteiliges in der Praxis begegnet ist. Das bedeutet aber nur, dass die Kol-
lisionsfestigkeit des eingesetzten Hash-Algorithmus ziemlich hoch ist.
Eine interessante Recherche ist in [10] präsentiert. Dort hat man versucht, mit den zu-
fällig generierten Kommentaren auf Kollisionen zu kommen. Erstaunlicherweise ist es gar
nicht so kompliziert. Beispielsweise haben diese 2 SQL-Anweisungen dieselbe SQL Id:
select owner, index_name from dba_indexes where rownum<=9 --BaERRzEYqyYphBAvEbIrbYYDKkemLaib;
select owner, table_name from dba_tables where rownum<=10 --XhiidvehudXqDpCMZokNkScXlQiIUkUq;
Wenn Sie mal interessehalber prüfen, wie Oracle mit solchen SQL-Anweisungen umgeht,
werden Sie feststellen, dass Oracle die jeweiligen Cursor in den verschiedenen Cursor-
Listen verwaltet (mehr Informationen über Cursor-Listen finden Sie im Abschn. 8). Für
diesen Test können Sie die beiden SQL-Anweisungen ausführen und danach nach den
jeweiligen Cursorn in der View V$SQL suchen. Dort finden Sie 2 Cursor mit SQL_ID =
'ayr58apvbz37z' und mit CHILD_NUMBER = 0.
Wir bleiben aber auf der praktischen Schiene und werden im weiteren Text davon aus-
gehen, dass die SQL Id und der Hashwert des SQL-Textes eindeutig sind.
Für die Berechnung der SQL Id und des Hashwertes brauchen wir eine Funktion, die
den 16-Bytes-MD5-Hashwert kalkuliert. Im oberen Text ist die Funktion DBMS_UTILI-
TY.GET_SQL_HASH erwähnt, die unter anderem den MD5-Hashwert berechnet. Diese
Funktion würde für unsere Spielzwecke vollkommen ausreichen. Sie benötigt zwar den
SQL-Text nicht in CLOB- sondern in VARCHAR2-Format, aber für unsere kleinen Bei-
spiele stellt das kein Problem dar. Für „echte“ SQL's kann man z. B. die Funktion DBMS_
CRYPTO.HASH gebrauchen. Sie hat 2 Parameter: SQL-Text in CLOB-Format und Typ
(der Typ von 2 entspricht dem MD5-Algorithmus).
Ein Algorithmus für die SQL Id und für den Hashwert findet man in [11]. In [12] wur-
de dieser Algorithmus ziemlich unverändert übernommen und in PL/SQL programmiert.
Hier ist dieser Algorithmus in einer etwas verständlicheren Form dargestellt. Dafür ist die
Umwandlung in das 32-er System als separate Funktion conv_to_base32 implementiert.
