Das Automatic Workload Repository (AWR) gehört meiner Meinung nach zu den großartigsten Errungenschaften der jüngeren (oder auch nicht mehr ganz so jüngeren) Oracle-Geschichte, da es eine Historie von Abfragen und ihrer Performance bereitstellt. Allerdings ist diese Historie nicht vollständig, da sie auf Sampling basiert - es kann also vorkommen, dass interessante Queries nicht erfasst werden. Um dieses Problem zu lösen, wurde in 11g die Routine dbms_workload_repository.add_colored_sql eingeführt, die es ermöglicht Abfragen "einzufärben", was nichts anderes bedeutet, als dass ihre Protokollierung erzwungen wird - ein knappes Beispiel zum Thema findet man bei Marcin Przepiorowski.
Allerdings scheint es, dass diese Möglichkeit in der Praxis nicht allzu intensiv genutzt wird, denn in einem Thread im OTN-Forum wurde jetzt ein offenbar bisher nicht allgemein bekanntes Limit angesprochen: man kann nur 100 Queries kolorieren, ehe man den Fehler "ORA-13534: Current SQL count(100) reached maximum allowed (100)" erreicht. Jonathan Lewis hat via SQL Trace beobachtet, dass hier offenbar ein hart kodiertes "selects count(*) from the wrm$_colored_sql" im Spiel ist, das bei einem Ergebnis größer 100 zum Abbruch führt. Andererseits ist das Feature auch alles andere als gut dokumentiert - und in der Folge nicht allgemein bekannt.
Man könnte sich doch einfach periodisch Snapshots vom AWR ziehen und somit das Limit umgehen :)
AntwortenLöschenHallo Thomas,
AntwortenLöschenda war ich vermutlich etwas undeutlich in meiner Beschreibung: das Problem, zu dem die Kolorierung die Lösung sein kann, ist, dass eine Query im AWR gar nicht erst erscheint. Mit Hilfe von dbms_workload_repository.add_colored_sql kann man eine sql_id angeben, zu der dann eine lückenlose Protokollierung erfolgt.
blödes session limit...
AntwortenLöschenDas hab ich schon verstanden - wenn ein Statetment explizit koloriert ist, wird es auch im AWR auftauchen - bis man dort an die Beschränkung trifft.
Hier bin ich davon ausgegangen, dass man dort einträge auch explizit entfernen kann.
Vor dem Löschen würde ich dann eben den genannten Snapshot der AWR Tabelle ziehen und die dann in eine eigene AWR-Archiv Tabelle mergen.
das könnte ein wenig sperrig werden, fürchte ich ... - insbesondere bei der Bestimmung der kolorierten SQL-Einträge, die man entfernen könnte/müsste, um dem Limit zu entgehen. Vielleicht wäre es einfacher, AWR komplett nachzubauen (zumindest hinsichtlich der SQL-Zugriffe und -Pläne) - also v$sql-, v$sql_plan-Änderungen zu erfassen, beschränkt auf einzelne SQL_IDs. Aber wenn ich darüber nachdenke, kommt mir das Limit 100 gar nicht mehr so restriktiv vor...
AntwortenLöschen