Kann die Entscheidung des Optimizers für einen SQL Ausführungsplan gar nicht mehr nachvollzogen werden, zum Beispiel wann Parallel verwendet wird und wann nicht, kann ein Trace viele Rätselraten ersparen.

Ablauf:

• Trace Event setzen
• SQL absetzen bzw. Ausführungsplan ermitteln lassen
• Trace Event zurücksetzen
• Trace File auf dem DB Server finden und analysieren

#set the event
ALTER SESSION SET events 'trace[SQL_Compiler.*] disk=highest';
 
#create a execution Plan
EXPLAIN plan FOR SELECT /*+ PARALLEL(4) */ COUNT(*) FROM gpi.big_tables;
 
#unset the event
ALTER SESSION SET events 'trace[SQL_Compiler.*] off';
 
# GET the tracefile location
 
SELECT VALUE AS full_trace_file_loc 
  FROM v$diag_info 
 WHERE  name = 'Default Trace File'
/

In Tracefile kann auch gut erkannt werden wie die System Statistiken, Workload und i/o calibrate, in die Berechnung einfließt.

Bei der Umstellung von einer 11.2.0.3 auf die 11.2.0.4 Version fiehl auf, das der Parallel Hint im Statement mit einer IOT (Index Organised Table) nicht mehr „funktioniert“, das immer ein besserer normaler Plan gefunden wurde.

Lösung: Eine expliziete Anfrage eines Full Tablescans auf die IOT erhöht die Kosten so, das nun der Parallel Pfad als optimal vom optimizer befunden und verwendet wird.

SELECT  /*+ PARALLEL (data 4) FULL(data) */ .... FROM bi.journalzeilen DATA WHERE ....;