Database Reference
In-Depth Information
Abb. 15.1
Zusammenführung der Cursor bei ECS
Wenn der neue Ausführungsplan mit dem bestehenden identisch ist, hat Oracle theore-
tisch die folgenden 2 Möglichkeiten:
• entwedergenausowieimerstenFallzuhandelnoder
• diebeidenCursorzusammenzuführen.IndiesemFallwirdeinneuerCursorangelegt,
die Selektivitätsgrenzen des alten und des neuen Cursors werden zusammengeführt
(dabei können diese Grenzen geändert werden) und diesem neuen Cursor zugeordnet.
Der alte Cursor wird dann nicht mehr für die künftigen Parse Calls benutzt (die Spalte
IS_SHAREABLE der View V$SQL nimmt in diesem Fall den Wert 'N' an).
Oracle hat die zweite Möglichkeit realisiert. Wenn die Selektivitätsgrenzen sich nicht zu-
sammenführen lassen, werden sie separat dem neuen Cursor zugeordnet. So entstehen
die Range Ids in der View V$SQL_CS_SELECTIVITY. Die Selektivitätsgrenzen werden
durchnummeriert, und die jeweiligen Nummern werden in der Spalte RANGE_ID ab-
gespeichert. In unserem Beispiel mit 2 Cursorn entstehen lediglich 2 Range Ids: 0 und 1.
Wenn die jeweiligen Cursor weiter zusammengeführt werden, können größere Range Ids
entstehen. Die Zusammenführung der Cursor bei ECS ist in Abb.
15.1
dargestellt.
Zu dem ACS-Verfahren habe ich noch 2 Skripte vorbereitet: test_case_adaptive_cur-
sor_sharing.sql und test_case_adaptive_cursor_sharing_cs.sql. Diese Skripte demonstrie-
ren, wie das ACS-Verfahren für eine SQL-Anweisung mit einem Prädikat funktioniert.
Mit dem ersten Skript kann man die folgenden Stufen bzw. Einzelheiten dieses Verfahrens
nachvollziehen:
• Prüfung,dassderjeweiligeCursor„bindsensitive“ist,
• MonitoringderKardinalitäten,
• BerechnungderSelektivitätsgrenzen,
• ZusammenführungderCursorbzw.derSelektivitätsgrenzen.
Die im Skript vorhandenen Parametereinstellungen kann man ändern und die Wirkung
dieser Änderungen nachvollziehen.
