Database Reference
In-Depth Information
Fazit
• PerformanceTuningmitParametereinstellungenkannsehreffizientsein,
• diegewonnenenErkenntnissebeieinemProblemfallkannmanerfolgreichbeiden
anderen Problemfällen benutzen
2.3.2
Workaround mit einem FBI
Nach einem Release-Wechsel der Anwendung ist eine wichtige SQL-Anweisung nicht per-
formant geworden. Vor dem Release-Wechsel wurde ein Index Unique Scan im jeweili-
gen Ausführungsplan benutzt, nach dem Release-Wechsel lief diese SQL-Anweisung mit
einem Full Table Scan. Es wurde ziemlich schnell klar, was das verursachte. Man defi-
nierte versehentlich in der jeweiligen Tabelle eine Spalte mit nummerischen Werten als
VARCHAR2. In der SQL-Anweisung benutzte man aber eine Bind-Variable vom Typ
NUMBER. Einen Index für die jeweilige Spalte konnte Oracle in dieser Situation nicht
gebrauchen.
Die Entwickler schlugen sofort vor, den jeweiligen Datentyp in der Tabelle wieder auf
NUMBER zu ändern. Dieser Vorschlag war absolut richtig. Man konnte ihn leider erst 2
Wochen später umsetzen, da man die jeweilige Änderung zunächst vorbereiten musste.
Noch mehr Zeit kosteten die Formalitäten: eine Genehmigung für diese Aktion auf der
produktiven Datenbank. Diese 2 Wochen musste man irgendwie überleben.
Da die Workarounds gerade in solchen Fällen am besten einzusetzen sind, schlug ich
einen ganz einfachen vor. Man konnte dieses Performanz-Problem mit einem FBI (functi-
on based index) umgehen. Mit dem folgenden Test-Case kann man das jeweilige Problem
und dessen Lösung nachstellen. Zunächst wird eine kleine Tabelle mit einer Spalte C1 vom
Typ VARCHAR2 angelegt und mit den Daten gefüllt, danach wird ein UNIQUE Index für
diese Spalte erzeugt.
64/!FUHDWHWDEOHWFYDUFKDUFQXPEHUFQXPEHU
7DEOHFUHDWHG
64/!GHFODUH
LLQWHJHU
EHJLQ
IRULLQORRS
LQVHUWLQWRWYDOXHVLLL
HQGORRS
FRPPLW
HQG
3/64/SURFHGXUHVXFFHVVIXOO\FRPSOHWHG
64/!FUHDWHXQLTXHLQGH[LBWRQWF
,QGH[FUHDWHG
