Performance Feedback Optionen in 12c aktivieren und deaktivieren

Christian Antognini erläutert in seinem Blog, welche Schwierigkeiten sich in 12c ergeben, wenn man das "Performance Feedback" aktivieren oder deaktivieren möchte. Zur Erinnerung: das Performance Feedback ist ein adaptives Feature und dient zur automatischen Prüfung, ob ein initial gewählter Parallelisierungsgrad tatsächlich vorteilhaft ist. Relativ harmlos ist bei der Konfoiguration noch der Faktor, dass sich der zugehörige Parameter in 12.1 OPTIMIZER_ADAPTIVE_FEATURES nennt, während er in 12.2 (bzw. auch in 12.1, wenn man den passenden Patch installiert hat) auf den Namen OPTIMIZER_ADAPTIVE_STATISTICS hört. Daneben muss in beiden Versionen zusätzlich noch der Parameter PARALLEL_DEGREE_POLICY auf true gesetzt werden, um das Performance Feedback zu aktivieren. Weniger schön ist, dass die Reihenfolge der Setzung der Parameter eine Rolle spielt - und darüber hinaus der interne Parameter _OPTIMIZER_PERFORMANCE_FEEDBACK. Die Nacherzählung der Effekte der Reihenfolge spare ich mir an dieser Stelle.

Änderungen an v$diag_alert_ext in 12.2

Vor kurzem hat Markus Flechtner in seinem Blog auf einige Änderungen hingewiesen, die sich in 12.2 für die View v$diag_alert_ext ergeben haben, mit der man die Inhalte aus alert.log und weiteren Log-Dateien via SQL abfragen kann. Was sich leider anscheinend nicht geändert hat, ist, dass dieser Zugriff weiterhin deutlich langsamer erfolgt als der über die X$-View X$DBGALERTEXT. Dafür ist v$diag_alert_ext aber in 12.2 offiziell dokumentiert, was ihre Verwendung an Stelle des X$-Objekts interessanter macht. Wichtiger ist wahrscheinlich noch, dass v$diag_alert_ext inzwischen sinnvolle Werte in der Spalte con_id enthält und dass die View in einer PDB jeweils nur die Einträge des entsprechenden Containers anzeigt. Und für mich ist noch interessanter, dass die ergänzende View V$DIAG_TRACE_FILE einen SQL-Zugriff auf Trace-Dateien ermöglicht. In Summe sieht es danach aus, dass diese Teile der Infrastruktur inzwischen eine recht hohe Stabilität gewonnen haben - in 11.2.0.3 konnte der Zugriff auf die View noch zu recht harten ORA-07445-Fehlern führen und war daher nicht unbedingt ratsam.

impdp mit metadata_only content führt zu gelockten Statistiken

Der Titel sagt eigentlich schon alles, was ich hier ausführen wollte: Frank Pachot weist darauf hin, dass ein auf Metadaten beschränkter Import automatisch die Statistiken lockt, um dafür zu sorgen, dass sie nicht vom nächsten Statistikerfassungslauf mit relativ uninteressanten 0-rows-Einträgen überschrieben werden. Auf diese Weise kann man mit einem metadata_only Import recht gut die Ausführungspläne des CBO vom Quellsystem nachvollziehen. Was den Herrn Pachot dabei ebenso irritiert wie mich ist, dass dieses Verhalten seit 10.2 gilt - und es ihm erst jetzt aufgefallen ist; und mir dann noch etwas später...