Ähnlich der Stored Outlines dienen SQL Plan Baselines der Planstabilizierung bei verschiedenen Datenbankänderungen, wie z.B.

-         neue Optimizer Version,

-         Änderungen von Metadaten,

-         Änderungen von Optimizer Environment

-         ...

Im Unterschied zu Stored Outlines handelt es sich bei SQL Plan Baselines um akzeptierte Execution Pläne aus der Historie von gespeicherten Execution Plänen. Sehr oft versteht man unter SQL Plan Baselines diese Historie selbst.

Wie die Stored Outlines werden SQL Plan Baselines in erster Linie als proaktive Maßnahme betrachtet.

SQL Plan Baselines sollen künftig Stored Outlines ersetzen. Für SQL Plan Baselines braucht man eine Tuning Pack (TP) Lizenz.

Konzept von SQL Plan Baselines

-     Quelle: SQL-Area (v$sql) oder SQL-Set (s. DBMS_SQLTUNE). Execution Pläne aus AWR kann man über ein SQL-Set holen 

-     Eine SQL Plan Baseline ist ein Execution Plan aus der Historie der gespeicherten Pläne mit dem Status ACCEPTED=’YES’. Nur solche  Baselines können angewendet werden

-     Zu einem SQL können mehrere SQL Plan Baselines existieren. Es wird aber immer eine Baseline angewendet – die beste. Die beste Baseline ist ein Execution Plan mit den geringsten Optimizer Kosten ODER mit dem Status FIXED=’YES’.  Diesen Status kann man mauell setzen

-     Wofür braucht man mehrere akzeptierte Pläne für einen SQL? Das ist eine Absicherung gegen Änderungen von Metadaten (z.B. das Löschen von Indexes), die dazu führen können, dass der beste Execution Plan nicht mehr anzuwenden ist

-     Benutzung von SQL Plan Baselines aktiviert man mit OPTIMIZER_USE_SQL_PLAN_BASELINES = TRUE (Default !), deaktiviert mit OPTIMIZER_USE_SQL_PLAN_BASELINES = FALSE

-     Man kann einen Execution Plan deaktivieren, indem man den Status ENABLED auf ‘NO’ setzt

-     Automatisches und manuelles Generieren von gespeicherten Execution Plänen ist möglich

-     Automatische Generierung:
- nur aus dem SQL-Area
- Aktivierung durch OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES = TRUE, Deaktivierung durch OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES = FALSE (Default)
- damit ein SQL in der Historie von gespeicherten Execution Plänen landet, muss er mindestens zweimal ausgeführt werden
- der erste gespeicherte Execution Plan für ein SQL bekommt den Status ACCEPTED = ‘YES’, weitere – ACCEPTED = ‘NO’. Um den Status ACCEPTED=’YES’ zu bekommen müssen sie noch “evolved” werden
- bei “Evolving” wird ein (oder mehrere) Execution Plan mit dem Status ACCEPTED = ‘NO’ ausgeführt und  seine Runtime Statistiken werden mit den Runtime Statistiken vom akzeptierten Plan verglichen. Sind sie besser, so bekommt der SQL Plan den Status ACCEPTED=’YES’. Mehr dazu findet man in der Beschreibung von DBMS_SPM

-     Manuelle Generierung:
- für einzelne Execution Pläne aus dem SQL-Area und aus dem SQL-Set
- ist durch Aufrufe von jeweilihen Prozeduren von DBMS_SPM realisiert
- alle manuell  generierten Baselines bekommen den Status ACCEPTED=’YES’
- für eine vorhandene manuell generierte Baseline werden weitere Execution Pläne automatisch in der Historie von gespeicherten Plänen angelegt

-     SQL Plan Baselines werden im Tablespace SYSAUX abgespeichert. Defaultmäßig sind dafür 10% in diesem Tablespace vorgesehen. Man kann dieses Quota im Rahmen von 1 bis 50% varieren.

-     Nicht genutzte SQL Plan Baselines werden in einiger Zeit aus der Historie der gespeicherten Pläne verdrängt. Defaultmäßig in 53 Wochen. Man kann diese Zeit anders konfigurieren – von 5 bis 523 Wochen

-     Zum Export / Import von SQL Plan Baselines s. das Package DBMS_SPM 

Vergleich:  Stored Outlines und SQL Plan Baselines

alter {system|session} set optimizer_ capture_sql_plan_baselines={true|false}

Kriterium: identische Outline Signaturen (dbms_outln_edit.generate_signature) 

SQL Plan Baselines in TuTool

In dem Tool ist manuelle Generierung und Bearbeitung von Baselines für einzelne Execution Pläne realisiert.

Data Dictionary Views

-         DBA_SQL_PLAN_BASELINES

Packages

-         DBMS_SPM