Oracle-DB: Systematische Rasterfahndung nach Performance-Antipattern
- 1. Systematische Rasterfahndung nach Performance-Antipattern November 2018Peter Ramm, OSP Dresden
- 2. Seite 2 Gründung: März 1991 Muttergesellschaft: OTTO Group Standorte: Dresden, Hamburg, Burgkunstadt, Bangkok, Taipeh Mitarbeiterzahl: Ca. 220 Geschäftsführer: Dr. Stefan Borsutzky, Alexander Hauser Otto Group Solution Provider Dresden GmbH www.osp.de
- 3. Seite 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
- 4. Varianten der Performance-Optimierung Seite 4 Ereignis-getrieben • Aufwand zur Optimierung dann, wenn produktive Notwendigkeit der Verbesserung • Hoher Effekt der einzelnen Maßnahmen • Potential zur Optimierung wird nur punktuell genutzt • Evtl. unnötig hohe Kosten für Hardware- Ressourcen und Lizenzen • Geringere Kosten für Performance- Optimierung Vorbeugend • Permanente Optimierung des produktiven Systems • Sukzessive geringerer Effekt der einzelnen Maßnahmen • Potential zur Optimierung wird weitgehend genutzt • Effektive Nutzung der Hardware-Ressourcen, optimale Lizenzkosten • Zunehmend höhere Aufwände für weitere Performance-Optimierung
- 5. Systematische Rasterfahndung mit Panorama Seite 5 Lösungsansatz • Formulierung der Problem-Identifikation als SQL-Statement • Nutzung des Dictionaries, der dynamischen SGA-Views sowie der AWR-Historiendaten der DB • Knapp 100 unterschiedliche bewertete Aspekte, von Potential in Datenstrukturen und Indizierung bis zu suboptimalen SQL-Statements • Limitierung: Adressiert nur die Themen, mit denen ich persönlich in Projekten konfrontiert wurde Motivation • Erkennung und Bewertung aller weiteren Vorkommen einer einmal analysierten Problemstellung im System, gewichtet nach Relevanz / Potential • Möglichst einfache Umsetzbarkeit der Lösungsvorschläge ohne Eingriff in die Architektur und Design • Fixen erkannter leicht lösbarer Problemstellungen systemweit statt step by step nach Eskalation • Komfortable Einbettung in weiteren Analyse-Workflow
- 6. Folgeschritte der Analyse Seite 6 Panorama bietet Funktionen sowohl für die unmittelbare Selektion der Lösungsvorschläge als auch für die Umfeldbetrachtung zur individuellen Bewertung der Relevanz • Die Rasterfahndungs-Selektionen sind kein automatisierter ToDo-Listen-Generator • Zwingend notwendig ist die fachkundige Bewertung der Vorschläge sowie die Erkennung und der Ausschluss von ermittelten Vorschlägen ohne konkrete Relevanz einer Umsetzung • Für die einfache Bewertung der Vorschläge sind SQL-IDs und DB-Objekte verlinkt und erlauben u.a. : - Detaillierte Struktur-Info zu angemerkten DB-Objekten - Verwendung von DB-Objekten in SQL-Statememts aus aktueller SGA und AWR-Historie - Analyse der Ausführungspläne der genannten SQLs - Analyse der Active-Session-History und Historie der SQLs - Diverseste weitere Aspekte
- 7. Anwendung der Suchen: Tool-basiert • In meinem Analyse-Tool „Panorama“ sind die Rasterfahndungs-Funktionen zu finden im Menü „Spez. Erweiterungen“ / „Rasterfahndung“ • Panorama ist frei verfügbar unter: https://rammpeter.github.io/panorama.html
- 8. Zugriff auf die komplette Liste der SQLs Seite 8 Des weiteren findet sich die komplette Liste der auch in Panorama verfügbaren Selektionen unter: https://rammpeter.github.io/oracle_performance_tuning.html.
- 9. Beispiel „Potential in DB-Strukturen“ Punkt 1.2.2. Seite 9 Identifikation eventuell unnötiger Indizes Identifikation von Indizes mit nur einem oder wenigen Schlüssel-Werten im Index • Für Indizes mit nur einem oder wenigen Schlüsseln kann die Sinnfrage gestellt werden. Ausnahme: Index auch mit nur einem Schlüssel kann sinnvoll sein zur Differenzierung zwischen NULL und NOT NULL. • Indizes mit nur einem Schlüssel und keinen NULLs in indizierten Feldern können i.d.R. entfernt werden. • Bei Nutzung des Index zur Absicherung von Foreign Keys kann oftmals trotzdem auf den Index verzichtet werden: - der resultierende FullTableScan auf der referenzierenden Tabelle bei eventuellem Delete auf der referenzierten Tabelle kann billigend in Kauf genommen werden kann. - Gleiches gilt für Lock-Propagierung über ForeignKey-Constraint. Wenn die referenzierte Tabelle nur wenige Records enthält und selten bis nie DML-Operationen darauf stattfinden, dann stellt das Fehlen eines den shared Lock abfangenden Index kein Problem dar
- 10. Beispiel „Potential in DB-Strukturen“ Punkt 1.1.3. Seite 10 Sicherstellen optimaler Storage-Parameter für Index Empfehlungen für Index-Komprimierung, Test auf Leaf-Blocks • Index-Kompression (COMPRESS) bringt sinnvolle Ergebnisse durch Reduktion der physischen Größe für OLTP-Indizes mit geringer Selektivität. • Bei geringer Selektivität der Indizes ist Reduzierung der Größe durch Komprimierung um 1/4 bis 1/3 möglich. • Bei komprimiertem Index sollte die Anzahl Leaf-Blocks per Key sinken, im Optimum passen alle Referenzen auf Datenblöcke eines Keys in nur einen Leaf Block.
- 11. Beispiel „Potential in DB-Strukturen“ Punkt 1.2.3. Seite 11 Identifikation eventuell unnötiger Indizes Identifikation von Indizes mit doppelt indizierten Spalten • Mehrfach indizierte Spalten bringen nur Nutzen im Such-Zugriff, wenn weitere Felder die Selektivität des Index verfeinern. • Die Indizierung einer Spalte, die bereits durch einen mehrspaltigen Index indiziert ist, ist oftmals überflüssig, z.B. zur Absicherung von Foreign Keys. • Alternativ kann mehrfache Indizierung der selben Spalte in verschiedenen Composite-Indizes jedoch der Optimierung von Join-Beziehungen dienen bzw. der vollständigen Abdeckung eines Zugriffs ohne Table-Access
- 12. Beispiel „Potential in DB-Strukturen“ Punkt 1.2.4. Seite 12 Identifikation eventuell unnötiger Indizes Erkennung nicht genutzter Indizes durch System-Monitoring • Die DB protokolliert die Nutzung (Zugriff) von Indizes die vorab durch 'ALTER INDEX ... MONITORING USAGE' deklariert wurden. • Das Ergebnis der Nutzungsprotokollierung ist je Schema in Tabelle v$Object_Usage einsehbar. • Schemaübergreifend ist die Nutzung mit diese Selektion sichtbar. • Achtung: Auch die Ausführung von GATHER_INDEX_STATS zählt als Nutzung, selbst wenn der Index nie durch andere Selects genutzt wurde.
- 13. Beispiel „Potential in DB-Strukturen“ Punkt 1.2.8. Seite 13 Identifikation eventuell unnötiger Indizes Indizes auf partitionierten Tabellen mit selben Spalten wie Partition-Keys • Wenn ein Index auf einer partitionierten Tabelle die selben Spalten indiziert wie die Partition-Keys und die Partitionierung selbst selektiv genug ist durch Partition Pruning, dann kann der Index möglicherweise entfernt werden.
- 14. Beispiel „SQLs mit suboptimalem Plan“ Punkt 2.2.8. Seite 14 Eventuelle Probleme mit parallel query Statements mit geplanter paralleler Execution forced to serial • PX COORDINATOR FORCED SERIAL im Execution-Plan zeigt, dass der Optimizer parallele Ausführung annimmt, dann aber Hinderungsgründe für parallele Ausführung feststellt (z.B. stored functions ohne PARALLEL_ENABLE). • Die Operationen unter der Zeile des Ausführungsplans werden in der Realität nicht parallel ausgeführt auch wenn der Optimizer sie für parallele Ausführung markiert hat!
- 15. Beispiel „SQLs mit suboptimalem Plan“ Punkt 2.6. Seite 15 Identifikation von Statements mit wechselndem Ausführungsplan aus Historie • Mit dieser Selektion lassen sich aus den AWR-Daten Wechsel der Ausführungspläne unveränderter SQL‘s ermitteln. • Betrachtet wird dabei die aufgezeichnete Historie ausgeführter Statements
- 16. Beispiel „Potential in DB-Strukturen“ Punkt 1.11. Seite 16 Möglicherweise aufwändiger TABLE ACCESS BY INDEX ROWID mit zusätzlichen Filterbedingungen nach dem Zugriff auf die Tabelle • Wenn in einem SQL eine Tabelle zusätzliche Filterbedingungen hat die nicht vom Index abgedeckt werden dann kann überlegt werden, den Index um diese Filterbedingungen zu erweitern. • Dies sichert dass der teuerere TABLE ACCESS BY ROWID nur ausgeführt wird, wenn die Zeile allen Filterbedingungen entspricht, die durch den Index geprüft werden. • Diese Abfrage betrachtet die aktuelle SGA.
- 17. Einbinden eigener Abfragen Seite 17 Panorama erlaubt die Einbindung eigener parametrisierbarer Abfragen zusätzlich zu den vorhandenen • Damit wird auch aus dem Ergebnis eigener Abfragen sofort weiterverlinkt zu SQLs und DB-Objekten • Angabe der Abfrage in JSON-Notation, Bindevariablen per „?“ + Deklaration der Parameter • Alternativ Ablage der eigenen Abfragen als File auf Server-Seite, nähere Details unter diesem Link
- 18. Panorama greift nur rein lesend auf Ihre Datenbank zu und benötigt keine eigenen PL/SQL-Objekte. Sie können die Funktionen also ohne Risiko testen und verstehen. Probieren sie es gern aus. Beschreibung inkl. Download-Link: http://rammpeter.github.io/panorama.html Blog zum Thema: https://rammpeter.wordpress.com/category/panorama-news-and-hints Letztes Wort
- 19. Vielen Dank für Ihr Interesse Otto Group Solution Provider (OSP) Dresden GmbH Freiberger Str. 35 | 01067 Dresden T +49 (0)351 49723 0 | F +49 (0)351 49723 119 osp.de