Database Reference
In-Depth Information
diese Signatur als Suchkriterium benutzen. Falls wir nichts finden, können wir absolut
sicher sein, dass unsere SQL-Anweisung im AWR (oder im Statspack-Repository) nicht
vorhanden ist. Wenn wir eine SQL-Anweisung finden, deren Literalen aber sich von unse-
ren unterscheiden, so ist es in den meisten Fällen auch ausreichend (z. B. wenn wir prüfen
wollen, mit welchem Ausführungsplan eine SQL-Anweisung vor einiger Zeit gelaufen ist).
Selbstverständlich können wir die Signaturen auch direkt einsetzen, um zu prüfen, ob
ein SQL Profile oder eine SQL Plan Baseline für eine SQL-Anweisung angewendet werden
kann. Diese Prüfung können wir machen, ohne die SQL-Anweisung (oder das Kommando
Explain Plan für diese SQL-Anweisung) auszuführen. Vorausgesetzt, dass
• die relevanten Parametereinstellungen sich nicht verändert haben, z. B.
cursor
_
sha
-
ring
,
sqltune
_
category
oder
optimizer
_
use
_
sql
_
plan
_
baselines
,
• dierelevantenDatenbankstrukturenunverändertbleiben(z. B.Indices).
Für diese Prüfung muss man lediglich die jeweilige Signatur berechnen und sie mit der
Signatur aus der View DBA_SQL_PROFILES oder aus der View DBA_SQL_PLAN_BA-
SELINES vergleichen.
Es gibt mindestens noch eine wichtige Anwendung von den Signaturen. Bei Systemen
mit intensivem Parsing kann eine Katastrophe auftreten, wenn jemand, aus Versehen oder
aus Unwissenheit über die Folgen, viele SQL-Anweisungen mit Literalen startet. In solchen
Fällen ist es wichtig zu ermitteln, wer, und mit welchen SQL-Anweisungen, diese Katastro-
phe verursacht hat. In den älteren Versionen von Oracle habe ich dafür SQL-Anweisungen
aus der SQL-Area analysiert, die einmal ausgeführt wurden. Da dieses Kriterium nur un-
gefähr die SQL-Anweisungen mit Literalen trifft, musste man die Liste der einmal ausge-
führten SQL-Anweisungen genau überprüfen. Solche Listen sind normalerweise ziemlich
lang, aus diesem Grund war die Analyse immer etwas mühsam. Sicherlich kann man auch
andere Kriterien für eine solche Suche wählen, z. B. nach SQL-Anweisungen mit demsel-
ben Textanfang (die ersten 50-70 Zeichen) suchen, das macht aber die Analyse nicht ein-
facher, sondern eher komplizierter. Nach der Einführung der Signaturen konnte man diese
Analyse wesentlich intelligenter gestalten. Es ist klar, dass die Exact Matching Signature
ungleich der FORCE_MATCHING SIGNATURE für SQL-Anweisungen mit Literalen ist.
Somit kommt man ganz gezielt an SQL-Anweisungen mit Konstanten. Dieser Ansatz ist
in dem Skript top_sql_with_literals102.sql realisiert. Das Verfahren funktioniert sehr gut
für das SQL, leider aber nicht für das PL/SQL, weil die Signaturen von anonymen PL/SQL-
Blöcken gleich 0 sind. Aus diesem Grund ist die folgende Vorgehensweise im Fall eines
akuten Problems zu empfehlen:
• zunächstdasSkripttop_sql_with_literals102.sqlausführen,
• findetmaneinenVerursacherinderAusgabe(wasindenmeistenFällenauchpassiert),
braucht man normalerweise nicht weiter zu untersuchen,
• findetmankeinenVerursacher,istessinnvoll,zusätzlichSQL-Anweisungenzuana-
lysieren, die einmal ausgeführt wurden.
