Oracle-DB: Active Session History: into the deep
- 1. Active Session History: into the deep November 2018Peter Ramm, OSP Dresden
- 2. Gründung: März 1991 Muttergesellschaft: OTTO Group Standorte: Dresden, Hamburg, Burgkunstadt, Taipeh, Bangkok Mitarbeiterzahl: Ca. 250 Geschäftsführer: Dr. Stefan Borsutzky, Norbert Gödicke, Jens Gruhl Otto Group Solution Provider Dresden GmbH www.osp.de
- 3. zur Person Peter Ramm Teamleiter strategisch-technische Beratung bei OSP Dresden > 20 Jahre Historie in IT-Projekten Schwerpunkte: • Entwicklung von OLTP-Systemen auf Basis von Oracle- Datenbanken • Architektur-Beratung bis Trouble-Shooting • Performance-Optimierung bestehender Systeme Mail: Peter.Ramm@ottogroup.com Tel.: 0351 49723 150
- 4. Active Session History • Eingeführt mit Oracle 10g, stark erweitert in 11g, noch etwas in 12c • Historisierung der Daten aller aktiven Sessions der DB aus V$Session ++ • Ablage je Sekunde in SGA-Memory, Abfrage per View V$Active_Session_History • Persistierung jeder 10. Sekunde im Zyklus der AWR-Snapshots in AWR-Tabelle, Abfrage per View DBA_Hist_Active_Sess_History • Auf dieser Datenbasis lassen sich sehr exakt Betriebszustände der DB auch noch nach langer Zeit rekonstruieren Nutzung erfordert Enterprise Edition + Lizensierung der Option ‚Diagnostics Pack‘
- 5. Active Session History: Was wird aufgezeichnet? Wesentliche Attribut der ASH für konkrete Auswertung Vollständige Liste der in ASH gesampelten Attribute: für Oracle 12.1 SESSION_ID, SESSION_SERIAL# Session identifier USER_ID Oracle user identifier; maps to V$SESSION.USER# SQL_Id, SQL_CHILD_NUMBER SQL identifier of the SQL statement that the session was executing SQL_PLAN_HASH_VALUE Numerical representation of the SQL plan for the cursor SQL_PLAN_LINE_ID SQL plan line ID SQL_PLAN_OPERATION Plan operation name SQL_PLAN_OPTIONS Plan operation options SQL_EXEC_ID SQL execution identifier PLSQL_ENTRY_OBJECT_ID Object ID of the top-most PL/SQL subprogram on the stack; PLSQL_OBJECT_ID Object ID of the currently executing PL/SQL subprogram EVENT the event for which the session was waiting for. P1TEXT, P1, P2.. Additional wait parameter BLOCKING_SESSION Session identifier of the blocking session. CURRENT_OBJ# Object ID of the object that the session is referencing. XID Transaction ID that the session was working on at the time of sampling. SERVICE_HASH TNS-Service PROGRAM Name of the operating system program MODULE, ACTION Attributes set by the DBMS_APPLICATION_INFO.SET_MODULE MACHINE Client's operating system machine name PGA_ALLOCATED Amount of PGA memory (in bytes) consumed by this session TEMP_SPACE_ALLOCATED Amount of TEMP space allocated
- 6. Active Session History: Wie lange wird aufbewahrt? ASH- Sampling gv$Active_Session_History Zyklus: 1 Sekunde Verfügbar entspr. SGA i.d.R. einige Stunden AWR- Snapshot DBA_Hist_Active_Sess_History Zyklus: 10 Sekunden Verfügbar entspr. AWR- Retention, Default 7 Tage Anpassung der Aufgewahrungszeit der AWR-Daten inkl. ASH: DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings( retention => 44640, -- Minuten (= 31 Tage). interval => 15); -- Minuten Die Default-Vorhaltedauer der AWR-Daten von 7 Tagen ist regelmäßig zu knapp
- 7. Werkzeuge für Analyse auf ASH-Daten: 1. Enterprise Manager Cloud Control (ab 12c) • Menüpunkt ‚Performance‘ / ‚ASH-Analyse‘ • Erfordert Nachinstallation von PL/SQL-Packages im Schema DBSNMP
- 8. Werkzeuge für Analyse auf ASH-Daten: 1. Enterprise Manager Cloud Control (ab 12c)
- 9. Werkzeuge für Analyse auf ASH-Daten: 2. Panorama: freies Analyse-Tool Weitere Doku + Download: https://rammpeter.github.io https://hub.docker.com/r/rammpeter/panorama https://rammpeter.blogspot.com/ Freies verfügbares Tool für Performance- Analyse von Oracle-DB Basiert wahlweise auf : • AWR und ASH mit EE und Diagnostics Pack • Eigenem Sampling ohne Diagnostics Pack, damit auch für SE bzw. XE einsetzbar • „Leichte“ Machbarkeit der Analysen mittels GUI-Workflow, auch für „Laien“ • Senken der Hemmschwelle, Problemen tatsächlich auf den Grund zu gehen • Identifikation der konkrete Ursachen für unzureichend Applikations-Performance • Folgend einige Beispiele für ASH-Analyse unter Nutzung von Panorama
- 10. Herausforderung bei der Analyse per ASH Äußerst hilfreich für Prozess-Analyse ist das Taggen von DB-Sessions mit fachlichen Kontextinformationen zum Prozess am Beginn einer Transaktion. Setzen der Kontext-Info durch Ausführung der PL/SQL-Funktion: DBMS_Application_Info.Set_Module(<Module>, <Action>) • Module, Action: Strings mit jeweils max. 64 Zeichen Standard-Anfrage: Prozess XY lief gestern Nacht 3 x so lange wie üblich! Warum? Die Applikation arbeitet mit Java JEE-Application-Server und Session-Pooling: • Für jede Transaktion wird erneut willkürlich eine DB-Session aus dem Pool geholt • Mit Rücksicht auf den OLTP-Charakter des Systems sind Transaktionen sehr kurz • Ein Prozess skaliert parallel und nutzt dabei eine variable Anzahl von DB-Sessions Wie soll man hier die Spuren in der Active Session History dem Prozess zuordnen? • werden mit in die ASH gesampelt und erlauben die Zuordnung zum Prozess
- 11. Ermittlung Ursachen kritischer Prozess-Laufzeiten Workflow bis auf die Zeile des Execution-Plans Standard-Anfrage: Prozess XY lief gestern Nacht 3x so lange wie üblich! Warum? • Panorama: Menü „Session-Waits“ / „Historisch“ • Auswahl Zeitraum, Gruppierung nach „Module“ • Kontext-Menü in Tabelle, „Zeige Top 10 in Zeitleiste“ für Kurven der aktiven Sessions je Module • Drill-Down weiter z.B. über ‚SQL-ID‘, Identifikation der Top-SQLs des Modules • Klick auf SQL-ID, weiter zu Button „Execution Plan“ • Spalte „DB time“ des Execution-Plan zeigt Schwerpunkt-Operationen des SQL Panorama kombiniert dabei das sekündliche und 10-sekündliche ASH-Sampling So lange vorhanden, wird die feinere sekündliche Information verwendet
- 12. Analyse von „Blocking Lock“-Situationen Rückwirkende Ermittlung des root cause Eine Session-Analyse zeigt verbreitet „row lock contention“ mit komplexer Abhängigkeit. Was ist der Auslöser? • Panorama: Menü „DBA Allgemein“ / „DB-Locks“ / „Blocking Locks historisch“ • Auswahl Betrachtungs-Zeitraum, Tabelle zeigt Root-Blocker + geblockte Sessions • Tabelle ist sortiert nach „Total Wait (Sec.)“ aller vom Blocker geblockten Session • „Direct blocked“ und „Total blocked“ verlinken auf Kaskade geblockter Sessions • „Blocking SID“ verlinkt auf ASH-Historie des Root-Blockers • „Blocking Object“ der geblockten Session verlinkt auf RowID und Primary Key-Wert des gelockten Records (sofern es um Row-Lock geht) Weitere Informationen zur Analyse von Blocking-Locks sind zu finden in diesem Blog-Post
- 13. Überlauf des Temp-Tablespace Rückwirkende Ermittlung der größten Verbraucher Alert-log der zeigt „ORA-1652: unable to extend temp segment“. Welche DB-Session verbrauchte die TEMP-Ressourcen zu diesem Zeitpunkt wirklich? • Panorama: Menü „Schema / Storage“ / „Temp usage“ / „Historisch“ • Auswahl Betrachtungs-Zeitraum, Gruppierung auf „Minute“ • Minute der maximalen TEMP-Auslastung ermitteln“: – Nach Spalte „ Max. TEMP allocated MB“ sortieren oder – Über Kontext-Menü auf Spalte „Max. TEMP allocated MB“ diese in Diagramm einblenden • Link auf „Session / Sn.“ zerlegt die Instanz-Zeile nach DB-Sessions • Über Spalte „Total time waited“ link in „Session-Waits historisch“ nach Instanzen Unschärfe: nicht aktive Sessions mit TEMP sind nicht berücksichtigt siehe auch: Blog-Post • Sortierung nach „Max. Temp“ zeigt die Großverbraucher zu diesem Zeitpunkt • Execution-Plan des SQL zeigt konkrete Zeile im Plan mit Temp-Nutzung
- 14. ASH erlaubt vollständiges Scannen der DB-Historie nach Mustern, die z.B. auf problematische Implementierung hinweisen. • 1.10. TABLE ACCESS BY ROWID komplett ersetzbar durch INDEX SCAN (SGA) Für kleinere Tabellen mit wenig Spalten und exzessivem Zugriff ist es Wert, den Indexzugriff und nachfolgenden Tabellenzugriff per TABLE ACCESS BY ROWID zu ersetzen durch einen Index mit allen relevanten Spalten. • 2.5.1 Suboptimaler Zugriff auf Indizes mit nur teilweiser Nutzung des Index INDEX RANGE SCAN mit einer hohen Anzahl von Treffern und restriktiver Filter nach dem TABLE ACCESS BY ROWID führt zu unnötiger Last • 2.5.2 Exzessives Filtern nach TABLE ACCESS BY ROWID auf Grund unscharfem Kriterium im Index-Zugriff (aktuelle SGA) Nutzung von Index-Attributen als Filter statt als Access-Kriterium mit gleichzeitig signifikanter Last. Mögliche Ursachen: - Falscher Datentyp der Bindevariable - Nutzung von Funktionen auf der falschen Seite beim Zugriff auf Spalten des Index Panorama: Menü „Spez.. Erweiterungen“ / „Rasterfahndung“ Einige exemplarische Abfragen unter Nutzung ASH: Active Session History als Basis für systematische Rasterfahndung nach Performance-Antipattern
- 15. Ich danke für Ihre Aufmerksamkeit. p.s.: Viele weitere Funktionen von Panorama lassen sich auch auf dem Wege der Neugier erkunden. Es finden nur lesende Zugriffe auf die DB statt. Das maximale Risiko besteht in der Last durch lesende SQLs.