Deutschland: Für längerfristige Einsätze vor Ort bevorzugt Bereich D6, Remote und kurzfristige Einsätze: beliebiger Einsatzort
Öffentliches Expertenseminar mit folgendem
Inhalt:
In diesem Seminar werden die wichtigsten Themen
bezüglich Indizierung mit B*Tree und Bitmap Indizes in der Oracle-Datenbank
behandelt ? Text / XML / JSON / Domain-Indizes werden zwar je nach verfügbarer
Zeit erwähnt und beschrieben, aber es wird nicht ausführlich darauf eingegangen
? der Schwerpunkt liegt eindeutig auf den B*Tree / Bitmap Indizes:
- Grundlagen: Wie ist ein B*Tree-Index aufgebaut, wie ein Bitmap-Index und welche Konsequenzen ergeben sich daraus? Wie verändert sich ein Index bei DML-Operationen und was ergibt sich daraus?
- Index Access, Filter und Clustering von Daten: Welche Operationen sind beim Index-Zugriff wann wie kostspielig? Warum wird der sogenannte Clustering Factor von Indizes häufig von der Datenbank falsch berechnet und was kann man dagegen machen? Warum kann ein Full Table Scan deutlich effizienter als ein Zugriff per Index sein? Indizes und der Optimizer - was wird bei der Kostenberechnung berücksichtigt, was nicht? OPTIMIZER_INDEX_COST_ADJ / OPTIMIZER_INDEX_CACHING, System Statistiken etc.
- Index Design: Auf was ist beim Design von Indizes zu achten? Was ist für die Reihenfolge von mehreren Ausdrücken in einem Index relevant? Wann ist ein Bitmap-Index sinnvoll? Was sind Function Based Indizes? Was sind virtuelle Spalten? Wie hängen diese Features zusammen und wann verwendet man welches dieser Features?
- Index Options: Invisible / Unusable / Virtual / Partial-Indizes. Primary Key / Unique / Deferred Constraints und Indizes.
- Index Compression: Wie funktioniert dieses Feature und was bringt es? Welche Auswirkungen gibt es? Unterschied zwischen Basic und Advanced Low / High Compression
- Indizes und DML: Was sind die Auswirkungen von Indizes bei DML-Operationen auf einer Tabelle? Typische Szenarien bei gleichzeitiger Veränderung von Tabellen und welche Maßnahmen hier helfen können - was sind die potentiellen Auswirkungen dieser Maßnahmen?
- Index Monitoring: Wie kann ich eine bestehende Applikation bezüglich der Indizierung überwachen und auf was ist dabei zu achten?
- Foreign Keys und Indizes: Wann sollten Foreign Keys indiziert sein, wann ist es nicht notwendig?
- Index Rebuild: Wann ist es sinnvoll, einen Index aktiv zu reorganisieren? Welche Möglichkeiten gibt es dafür und wie unterscheiden sie sich?Nach dem Installieren des Release Update 17 von 19c (RU 19.17) ist die gesamte Datenbank Performance sehr schlecht ? maßgeblich aufgrund sehr langsamen Transfer von Blöcken zwischen den RAC Instanzen ? anstatt durchschnittlich 400 µs pro übertragenem Block steigt dies auf fast 20.000 µs (!) an.
Eine Analyse zeigt, dass die LMS Hintergrund-Prozesse, die in RAC für die Übermittlung der Blöcke zuständig sind, fast permanent auf CPU Zeit verbringen, was vor der Installation des RUs nicht der Fall war. Ein CPU Profiling zeigt an, dass die Prozesse die gesamte Zeit beim Suchen im ?gcs resource table? verbringen, was darauf hinweist, dass etwas mit der Verwaltung dieser Tabelle im Speicher (Effiziente Aufteilung in ?Hash Buckets?) nicht stimmt ? es gab in der Vergangenheit schon ähnliche Bugs in dem Bereich. Nach Rücksprache mit Oracle Support und Einspielen entsprechender Bug Fixes ist das Problem gelöst.In diesem Seminar werden die wichtigsten Themen bezüglich Indizierung mit B*Tree und Bitmap Indizes in der Oracle Datenbank behandelt:
- Grundlagen: Wie ist ein B*Tree Index aufgebaut, wie ein Bitmap Index und welche Konsequenzen ergeben sich daraus? Wie verändert sich ein Index bei DML Operationen und was ergibt sich daraus?
- Index Access, Filter und Clustering von Daten: Welche Operationen sind beim Index-Zugriff wann wie kostspielig? Warum wird der sogenannte Clustering Factor von Indizes häufig falsch berechnet von der Datenbank und was kann man dagegen machen? Warum kann ein Full Table Scan deutlich effizienter als ein Zugriff per Index sein? Indizes und der Optimizer ? was wird bei der Kostenberechnung berücksichtigt, was nicht? OPTIMIZER_INDEX_COST_ADJ / OPTIMIZER_INDEX_CACHING, System Statistiken etc.
- Index Design: Auf was ist beim Design von Indizes zu achten? Was ist für die Reihenfolge von mehreren Ausdrücken in einem Index relevant? Wann ist ein Bitmap Index sinnvoll?
- Index Compression: Wie funktioniert dieses Feature und was bringt es? Welche Auswirkungen gibt es? Unterschied zwischen Basic und Advanced Low / High CompressionUnterstützung
beim Testen unterschiedlicher Partitionierungsstrategien im Data Warehouse
Umfeld, korrektes Aufsetzen der Testumgebung / Daten / Statistiken. Auswertung
der Ausführungspläne / Performance / Vergleich zwischen alter und neuer Strategie
Vortrag
?Kostenlos! Die am wenigsten benutzten Performance Features der Oracle
Datenbank? auf den IT Tagen 2022
Einführung
in die systematische Analyse und Verbesserung von Oracle Datenbank Performance.
Kennenlernen und Üben verschiedener Werkzeuge wie SQL Trace, Rowsource
Statistiken, AWR / ADDM / Statspack, SQL Monitoring, korrektes Lesen und
Verstehen von Ausführungsplänen etc.
Unterstützung
bei der Vorbereitung und Durchführung der Migration einer bestehenden Logistik
Software von Oracle 11.2.0.4 auf Oracle 19c.
Nach dem Installieren des Release Update 15 von 19c (RU 19.15) gibt es Laufzeitprobleme mit Tableau Berichten ? Ausführungspläne verwenden Indizes und Nested Loop Joins obwohl diese Indizes als ?INVISIBLE? markiert sind, was zu sehr langen Laufzeiten führt.
Eine Analyse ergibt, dass Auslöser der Probleme sehr schlechte Abschätzungen auf bestimmten, kleinen Dimensionstabellen sind. Diese werden vom Optimizer so abgeschätzt, dass die angewendeten Filter keine Daten zurückliefern, was grob falsch ist. Der Grund für die falsche Abschätzung ist das ?Dynamic Sampling? Feature der Datenbank und der Zustand dieser kleinen Tabellen, die viel mehr Platz allokieren als sie eigentlich müssten / sollten, was dazu führt, dass das ?Dynamic Sampling? nicht gut funktioniert (das Sampling greift nur auf leere Blöcke zu, wenn man Pech hat, da das Segment so viele leere Blöcke beinhaltet) und daher die Abschätzungen so negativ beeinflusst.
Die ?INVISIBLE? Indizes kommen nur daher zum Zuge, da bestimmte Views den Hint ?USE_INVISIBLE_INDEXES? beinhalten ? aber auch ohne Verwendung dieser Indizes sind die Ausführungspläne aufgrund der schlechten Abschätzungen ineffizient.
Eine Reorganisation der betroffenen Tabellen löst das Problem ? Hinweise werden noch zur Verfügung gestellt, wie das Problem in Zukunft vermieden werden könnte, indem die Tabellen auf eine andere Art und Weise gepflegt werden (Vermeiden der Kombination aus Updates auf komprimierten Daten, Deletes und Insert APPEND).Vortrag ?Kostenlos!
Die am wenigsten benutzten Performance Features der Oracle Datenbank? auf der
DOAG Konferenz 2022
Eine Bank möchte eine Inhouse Lösung zur Archivierung von Applikationsdaten entwerfen, die die Daten in einer Oracle Datenbank auf Exadata mit ZFS Storage speichert. Es soll den Applikationen ein generisches Datenbank-Interface zur Verfügung gestellt werden, das die Archivierung von Oracle Tabellen revisionssicher ermöglicht. Dazu werden verschiedene Oracle Datenbank Features wie ?Immutable Tables? und ?Database Vault? evaluiert.
Ausführliche Beschreibung. Demonstration und Diskussion der Oracle Exadata Database Machine in Form eines individuellen Workshops ? Aufbau, Features (Storage Cells, Smart Scans, Flash Cache, Persistent Memory, RoCE, Hybrid Columnar Compression etc.), wann profitiert man von den speziellen Exadata Features, detaillierter technischer Hintergrund, wie die diese Features funktionieren und wie deren Einsatz analysiert und gemessen werden kann.
Öffentliches Expertenseminar mit folgendem Inhalt:
In diesem Workshop Oracle Database Performance: Hands-on lernen wir anhand verschiedener praktischer Beispiele unterschiedliche Techniken kennen, mit denen Performance in der Datenbank im Detail analysiert werden kann. Es geht dabei um die Antwort auf die Frage, womit die Zeit in der Datenbank verbracht wird und wie dies gemessen werden kann.
Die Teilnehmer führen die Schritte unter Anleitung des Seminarleiters in ihrer eigenen oder einer vorbereiteten Datenbank durch und bekommen dadurch praktische Erfahrung, wie die jeweiligen Techniken funktionieren und was es bei der Anwendung zu beachten gilt.
Eine hauseigene Applikation soll auf Exadata migriert werden. Auf der Exadata Umgebung laufen jedoch einfache Updates und Inserts deutlich langsamer als auf den nicht-Exadata Umgebungen. Eine genauere Analyse ergibt, dass hier ?Flashback Database Archive (FBDA)? zum Einsatz kommt und die Verzögerungen hauptsächlich durch die rekursiven Aktivitäten von FBDA verursacht werden. Die Symptome, validiert durch einen SQL Trace, entsprechenden denen im Bug "Bug 31201192 - Hang with 'fbar timer'<='enq: tx - contention' (Doc ID 31201192.8)" beschriebenen. Dem Kunden wird nahegelegt, den verfügbaren Patch als ?Backport? für die eingesetzte Version von Oracle 19c bei Oracle Support zu beantragen.
Desweiteren laufen auf der Exadata bestimmte Import-Prozesse, bei denen aus Applikationssicht nur einfache Batch-Inserts durchgeführt werden, auf der Exadata sehr langsam. Eine Analyse zeigt, dass die Datenbank sich damit beschäftigt, tausende von Child Cursorn für diese Inserts zu erzeugen / zu verwalten. Das Grundproblem besteht in der Verwendung von falschen Datentypen beim Binden von Bind-Variablen von Applikationsseite. Nach Korrektur der Datentypen laufen die Inserts um Faktor 1000 schneller und die Anzahl der Child Cursor reduziert sich auf wenige einzelne.
Workshop ?Datenbank Performance für Entwickler? ? Beschreibung:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um effektiver mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt, eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
- Instrumentierung
- Trace / Row Source Statistics / Active Session History / Real Time SQL Monitoring
- Grundlagen Optimizer, Histogramme, Statistiken (inkl. New Features 12c)
- (serielle) Ausführungspläne richtig lesen
- Indizierung
- Clustering / Speicherformen inkl. New Features 12c: Attribute Clustering / Zonemaps, Heap, Index Organized Tables, Cluster
- Hints
- Bind Variablen / Literale und ungleichmäßige Datenverteilung
- Datenbank Links / Transaktionen / Locks
Umstellung der internen Speichermethode von XML-Daten. Oracle verwendet eigentlich seit Version 11.2 intern die Speichermethode ?Binary XML? für XMLType Daten. Eine Software eines Drittherstellers verwendete jedoch explizit noch die Speichermethode ?CLOB?, was deutlich mehr Platz in der Datenbank belegt. Nach Abklärung mit dem Hersteller wurde ein Migrationskonzept mit automatisierter Umstellung von über 5.000 bestehenden Tabellen erstellt und auch umgesetzt, so dass innerhalb weniger Minuten diese Tabellen auf ?Binary XML? Speichermethode umgestellt wurden ? dazu wurde mittels Create Table As Select (CTAS) eine temporäre Kopie der jeweiligen Tabelle angelegt und die alte Tabelle entsprechend entfernt / ersetzt, automatisiert per Skript. Als Absicherung für den Fall, dass die Migration nicht erfolgreich ist oder nachfolgend Probleme in der Applikation auftreten, wurde die Original-Datenbank (Oracle 19c CDB/PDB Architektur) als PDB-Kopie erhalten.
Vortrag ?Oracle Database 21c New Performance Features? auf der Sangam 21 / All Indian Oracle User Group (AIOUG) 2022 Konferenz
Abfragen in einem Data Warehouse verhalten sich unterschiedlich, je nachdem, wie auf die Partitionen der Daten zugegriffen wird. Bei Verwendung einer einzigen Partition sind die grundsätzlichen Abschätzungen des Optimizers so weit schlüssig, bei Zugriff auf mehrere Partitionen sind die Abschätzungen sehr schlecht. Es stellt sich heraus, dass durch die Verwendung von inkrementellen Statistiken ein Bug entsteht, der die Spaltenstatistiken des Partitionsschlüssels auf globaler Ebene verfälscht, so dass je nach Datenmenge pro Partition völlig falsche Annahmen seitens des Optimizers getroffen werden. Es werden verschiedene Lösungsmaßnahmen besprochen (unter anderem Verhinderung der Erzeugung eines Histogramms) und ein generischer Testcase für Oracle Support vorbereitet, um den Bug nachstellen zu können.
Abfragen, die versuchen, auf bestimmte Partitionen dynamisch einzuschränken per Unterabfrage erreichen nur inkonsistentes Partition Pruning. Da der Kunde bereits auf Oracle 19c ist, wird dieses Problem mittels ?SQL Macros? adressiert, was erlaubt, den Partitionsschlüssel als Literal anzugeben und trotzdem dynamisch zu bestimmen.
Darüber hinaus gibt es noch Probleme mit bestimmten Transformationen seitens des Optimizers (?Group By Placement?), die zu schlechten Abschätzungen und als Folge zu ineffizienten Ausführungsplänen führen. Dies kann durch eine Parametereinstellung verhindert werden.Öffentliches Expertenseminar mit folgendem Inhalt:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um effektiver mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
Vorträge im Rahmen der trivadis Performance Days 2021: ?Oracle Datenbank 21c New Performance Features? und ?Oracle Datenbank Indexing Myths?
Verschiedene mittels Tableau erzeugte Berichte schwanken stark in der Laufzeit. Es gilt zu ermitteln, ob die Schwankungen maßgeblich durch unterschiedliches Verhalten in der Datenbank verursacht werden oder es andere Gründe außerhalb der Datenbank gibt, wie zum Beispiel Netzwerk oder auch auf Applikationsebene (Tableau Reporting Plattform).
Eine Analyse ergibt, dass die Datenbank zwar teilweise an den unterschiedlichen Laufzeiten beteiligt ist, dies aber nur aufgrund unterschiedlicher Auslastung, aber nicht aufgrund unterschiedlicher Ausführungspläne oder anderer Gründe. Maßgeblich werden die Schwankungen durch die Reporting Plattform verursacht, die sehr stark unterschiedlich lange benötigt, um die bereits von der Datenbank zur Verfügung gestellten Daten abzuholen.Workshop ?Datenbank Performance für Entwickler? ? Beschreibung:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um effektiver mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt, eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
Der Export von historischen Daten ist bei einer Standardsoftware sehr langsam, da SQLs pro Datensatz ausgeführt werden, und pro Ausführung mehrere Sekunden an Laufzeit entstehen. Unter MySQL ist die Ausführung nochmal deutlich langsamer als unter Oracle. Eine detaillierte Analyse zeigt, dass die Datenbanken aufgrund der Art und Weise, wie das SQL geschrieben ist, nicht in der Lage sind, die Historie nur für die in Frage kommenden Datensätze zu ermitteln, sondern jeweils die komplette Datenmenge mehrfach pro SQL-Ausführung verarbeiten.
Durch Umformulierung der SQLs (mittels Verwendung von LATERAL Views) wird sowohl Oracle als auch MySQL in die Lage versetzt, die Historie nur für die relevanten Datensätze zu ermitteln, was einer Performance-Steigerung von Faktor 1000 entspricht, da jetzt nur noch wenige Millisekunden für eine einzelne Ausführung benötigt werden, anstatt mehrerer Sekunden.Individual Workshop „Datenbank Performance für Entwickler“ – inklusive Analyse von individuellen Problemfällen und Vorschlägen, wie diese verbessert werden können. Dazu noch Vorschläge, wie die Diagnosemöglichkeit von Applikationsseite verbessert werden kann, durch zum Beispiel selektives Aktivieren von SQL Trace und automatisiertes Einsammeln erweiterter Informationen bezüglich Ausführungsplänen.
Design und Umsetzung einer automatisierten Anonymisierung und Übertragung der Produktionsdatenbank in Testumgebungen. Die zu maskierenden Felder und die dafür verwendeten Regeln sind konfigurierbar über Metadaten, als auch die resultierende Datenmenge (zum Beispiel nur 10% des Originaldatenbestandes). Die Maskierung erfolgt performanceoptimiert über entsprechend automatisch mittels Metadaten generierte CTAS (Create Table As Select) Operationen, da die Laufzeiten durch die massive Verwendung von XML in der Datenbank eine wichtige Rolle spielen. Durch entsprechende Optimierung der CTAS Operationen kann die Laufzeit um Faktor 20 bis 40 erhöht werden und damit das Gesamtvolumen an zu maskierenden Daten in unter 24 Stunden verarbeitet werden trotz der komplexen Maskierungsregeln auf XML-Dokument Ebene. Für Bugs, die nach dem Oracle 19c Upgrade eine Verarbeitung aufgrund von PGA Speicherleaks und exzessiver TEMP Allokation unmöglich machten, wurde noch eine iterative Verarbeitung in Teilstücken implementiert, um die Probleme zu umgehen.
In einer operativen Datenbank werden bestimmte Berichte erstellt, die eigentlich in einer Data Warehouse Umgebung erstellt werden sollen, derzeit aber nicht erstellt werden können.
Daher sind die Daten in der operativen Datenbank nicht für diese Art von Abfragen optimiert, was Schema Design, Partitionierung und Indizierung angeht.
Aufgrund der nur vorübergehenden Natur (die Berichte sollen dann in absehbarer Zukunft im Data Warehouse erstellt werden) sollen auch keine größeren Anpassungen / Änderungen an der operativen Datenbank durchgeführt werden.
Als Problem stellt sich der Zugriff auf eine größere Tabelle mit Milliarden von Zeilen dar. Durch eine entsprechende Indizierung kann der Tabellenzugriff komplett vermieden werden, was die Laufzeit der relevanten Berichte entsprechend verbessert und Langläufer im Stunden-Bereich verhindert.
Für einen bestimmten Bericht wurde die Generierung der Informationen von einem iterativen Schleifenansatz mit potenziell sehr vielen Wiederholungen auf ein einzelnes SQL umgestellt, das die Daten zuverlässig innerhalb weniger Minuten generiert, was für die Nachtverarbeitung völlig ausreichend ist. Der Schleifenansatz war im Gegensatz dazu schlecht vorhersehbar, was die Gesamtlaufzeit angeht und deutlich langsamer (im Stundenbereich)
Öffentliches Expertenseminar mit folgendem Inhalt:
- Wie lese ich einen Ausführungsplan richtig? Gibt es besondere Regeln für parallele Ausführungspläne? Und falls ja, wie sehen diese aus?
- Wie führt Oracle so einen Ausführungsplan zur Laufzeit aus?
- Was machen diese ganzen Operationen, die mit PX anfangen, in einem parallelen Ausführungsplan? Was sagen mir die zusätzlichen Spalten, die es nur in einem parallelen Ausführungsplan gibt?
- Wie funktioniert diese automatische parallele Ausführung von SQL Statements zur Laufzeit? Was wird parallelisiert, und wie wird die Arbeit automatisch aufgeteilt? Was kann dabei schiefgehen? Falls etwas schiefgeht, kann ich es beeinflussen, und falls ja, wie?
- Warum sind manchmal parallele Ausführungen nicht viel schneller als serielle, oder sogar langsamer, und warum verbrauchen parallele Ausführungen teilweise so viel mehr PGA-Speicher und/oder TEMP-Speicherplatz wie vergleichbare serielle Ausführungen?
- Wie kann ich eine SQL Statement-Ausführung analysieren, um zu verstehen, warum sie länger braucht als erwartet? Wie setze ich die Diagnostics- und Tuning-Pack License Features optimal in diesem Zusammenhang ein?
- Wie kann ich speziell parallele SQL-Ausführungen analysieren, um zu verstehen, ob Parallel Execution hier überhaupt effizient eingesetzt wird? Warum sind die für serielle Ausführungen bekannten Analyse-Methoden dafür größtenteils ungeeignet?
- Wie kann ich parallele Ausführungen schon beim physischen Datenbank-Design schneller machen?
- Welche neuen Parallel Execution Features sind in Oracle 12c dazugekommen?
Der Workshop vermittelt ausführliche Antworten zu diesen Fragen. Darüber hinaus bietet es Ihnen zu einem großen Teil exklusives Wissen, das von mir selbst erarbeitet wurde. Dieses Wissen werden Sie woanders - auch nicht in den offiziellen Unterlagen und Schulungen von Oracle - finden.
Ein Kunde überprüft die Angabe der "Feature Usage" in DBA_FEATURE_USAGE_STATISTICS als Vorbereitung für einen License Audit seitens Oracle. Obwohl der Kunde nur über eine "Standard Edition" Lizenz verfügt und sich an keine aktive und absichtliche Nutzung von Enterprise Edition Features erinnern kann, werden dort sowohl "Real Application Security" als auch "Adaptive Plans" als benutztes Feature angezeigt - welche beide als "Enterprise Edition" Features seitens Oracle geführt werden.
Eine detaillierte Analyse ergibt, dass beide Features bereits bei der Standard-Installation einer 12.2.0.1 Standard Edition als "in use" angezeigt werden, da Oracle entsprechende Objekte bereits in der "Template"-Datenbank mitliefert, die eine Nutzung von "Real Application Security" anzeigen, und auch fälschlicherweise den Parameter "OPTIMIZER_APAPTIVE_PLANS" auf "TRUE" setzt, obwohl dieses Feature in der "Standard Edition" überhaupt nicht zur Verfügung steht.
Insofern sollte der Kunde bezüglich eines Audits seitens Oracle hier auf der sicheren Seite sein.
Verschiedene Abfragen verlängern sich signifikant in der Laufzeit nach dem Upgrade von 18c auf 19c und dem Hochsetzen des Parameters OPTIMIZER_FEATURES_ENABLE von „11.2.0.4“ auf „19.1.0“. Detaillierte Analyse der unterschiedlichen Abfragen mit Vorschlägen, wie funktionierende Workarounds aussehen können. Weitere Probleme unterschiedlichster Natur treten auf, von Planregressionen bis hin zu ORA-Fehlermeldungen beim Parsen sowie falschen Ergebnissen. Unterstützung bei der Zusammenarbeit mit Oracle Support mittels Vorbereitung entsprechender generischer Test Cases. Entwicklung entsprechender Workarounds für die genannten Probleme.
Nach einem Upgrade von Oracle 12.1 auf 19c gibt es mehrere Performance Probleme sowie Abbrüche in der Verarbeitung aufgrund von unzureichendem PGA Speicher. 19c benötigt signifikant mehr PGA Speicher pro Prozess und die Applikation erzeugt über mehrere Knoten von Application Servern mehrere Connection Pools, was zu einer hohen Grundlast an Prozessen führt. Desweiteren kommt seit der Version 18c einer neuer Speicherbereich zum Einsatz - die sogenannte „MGA" – ein Zwitter aus privaten und geteiltem Speicher, da „Shared Memory“ bei Bedarf dynamisch allokiert und zwischen mehreren Prozessen geteilt wird. Diese zusätzliche Speicherkomponente macht insbesondere unter Solaris Probleme, da zur Laufzeit immer wieder Allokationsfehler und damit Abbrüche auftreten können.
Das MGA-Problem kann mittels einiger interner Parameter umgangen werden, um die neue Speicherallokation in dem MGA Bereich zu verhindern.
Durch die erhöhte PGA Allokation unter 19c ist auch eine Anpassung der Parameter PGA_AGGREGATE_TARGET und PGA_AGGREGATE_LIMIT angezeigt,dadieInstanzeffektivmehr PGA benötigt als per PGA_AGGREGATE_TARGET zugewiesen. Die Performance Probleme sind nach entsprechender PGA Parameteranpassung und Erhöhung des physisch zur Verfügung stehenden Speichers auf Host Ebene weitgehend gelöst – eine Übersicht der Top SQLs, die Potential für effizientere Ausführung haben, wurde zusätzlich geliefert sowie noch einige andere Fragen bezüglich Indizierung, Konfiguration Maintenance Windows, „Killed Sessions“ etc. beantwortet.
Vortrag „Oracle Database Performance Tuning: Back To Basics” in auf der DOAG Konferenz 2020 sowie den IT Tagen 2020
Eine hoch frequent aufgerufene Schnittstellen-Funktion arbeitet mindestens 12 Sekunden pro Aufruf – häufig auch länger, was zu einer Warteschlange für die zu verarbeitenden Aufrufe führt. Teilweise müssen solche Aufrufe dann über 20 Minuten in der Warteschlange verbringen, was dann wiederum zu Timeouts in den aufrufenden Systemen führt. Durchschnittlich müssen Anfragen ca. 3 Minuten in der Warteschlange verbringen.
Eine Analyse zeigt, dass ein signifikanter Teil der Verarbeitungszeit in der Datenbank verbracht wird und dort vor allem ein SQL für die Laufzeit maßgeblich verantwortlich ist. Das SQL verwendet einen MINUS Operator, um ein Delta an einzufügenden Daten zu ermitteln. Da in der Zieltabelle Millionen von Datensätzen für diese Operation identifiziert werden und der MINUS Operator eine eindeutige Sortierung dieser Datenmenge benötigt, wird die Laufzeit für diese Sortieroperation maßgeblich über die zu sortierende Datenmenge bestimmt und kann daher nicht ohne weiteres optimiert werden. Leider akzeptiert die Datenbank nicht die automatische Umwandlung der MINUS SET Operation in einen Join (SET_TO_JOIN Transformation), was es erlaubt hätte, ohne Änderung des SQLs diese Umformulierung zu erreichen. Da das SQL aus einem PL/SQL Paket in der Datenbank stammt, ist eine semantisch äquivalente Umformulierung des SQLs von MINUS nach NOT EXISTS technisch möglich, ohne an anderem Quellcode der Applikation Änderungen vornehmen zu müssen. Daher wird dieser Weg eingeschlagen, nachdem mittels entsprechender Tests sichergestellt ist, dass das umformulierte SQL die gleichen Ergebnisse liefert. Da die andere Menge des MINUS Operators in den allermeisten Fällen sehr klein ist, kann der Optimizer aufgrund der Umwandlung des MINUS in einen Join effizientere Zugriffswege verwenden und vor allem die aufwändige Sortierung der großen Datenmenge vermeiden. Das umformulierte SQL benötigt nur noch ca. 3 bis 5 Sekunden zur Ausführung - nach Erzeugung eines geeigneten Index sinkt die Verarbeitungszeit auf Sekundenbruchteile.
Die durchschnittliche Wartezeit von Anfragen nach dieser Änderung sinkt von über 3 Minuten auf 2 Sekunden – Timeouts treten somit keine mehr auf und die allgemeine Verarbeitungsgeschwindigkeit steigt signifikant an.
Performance Analyse der Datenbank-Aktivitäten einer komplexen Auswertungslogik implementiert in PL/SQL nach Upgrade auf Oracle 19c. Einige Abfragen haben sich seit der letzten Analyse im Januar verändert, so dass die vorherig vorgeschlagenen Indizes angepasst werden müssen. Durch Anpassung und Ergänzung geeigneter Indizes kann die Verarbeitungszeit von über 30 Minuten auch für die größten Auswertungen auf unter 10 Minuten reduziert werden, so dass jetzt alle Auswertungen erfolgreich zu Ende laufen und nicht länger als die Timeout-Grenze von 30 Minuten benötigen.
Workshop „Den kostenbasierten Optimizer verstehen“ – grundlegende Prinzipien der Entscheidungsfindung des Optimizers, was kann schief gehen und wie stelle ich das fest, welche Möglichkeiten der Beeinflussung gibt es. Wie liest man Ausführungspläne richtig, wie generiert man Laufzeitprofile von SQL-Ausführungen und wertet diese aus. Wichtige Hinweise, auf was man bei der Statistikgenerierung für den Optimizer achten sollte. Clustering von Daten richtig verstehen und welche Möglichkeiten der Beeinflussung gibt es.
Öffentliches Expertenseminar für die DOAG (Deutsche Anwender Oracle Gruppe) am 28. und 29.9. mit folgendem Inhalt:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um bestmöglichst mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
Individual Workshop über relevante neue Features der Oracle Datenbank aus Sicht von Datenbank-Entwicklern / Applikationen, die in den neuesten Versionen hinzugefügt wurden
Nach dem Upgrade von Oracle 12.2.0.1 nach 19c (19.6) einer Data Warehouse Datenbank war die Performance signifikant schlechter. In Testumgebungen ist der Effekt zuvor so nicht aufgetreten. Es handelt sich um eine zwei Knoten RAC Datenbank als PDB auf Exadata (X7-2). Eine Analyse ergab folgende Punkte:
- Verschiedene RAC spezifische Bugs, die zu Hängern im Bereich der Cluster Waits („gc“) geführt haben, bei denen SQL-Ausführungen zum Beispiel unendlich auf „gc current request“ gewartet haben. Als initialer Workaround wurde das „read-mostly“ RAC feature deaktiviert und nach Verfügbarkeit und Installation entsprechender One-Off Patches, die leider nicht Teil des eingesetzten RUs waren, traten die Hänger nicht mehr auf
- Ein anderer RAC spezifischer Bug, der zu regelmäßigen Crashes der Instanzen geführt hat, wurde auch durch Installation eines entsprechenden One-Off Patches behoben
- SmartScans funktionierten seit der Installation des Cell Firmware Upgrades nicht mehr, da alle Zellen im Database Level Quarantine Mode agierten aufgrund von drei Crashes innerhalb von drei Stunden. Die verursachende SQL-Operation wurde identifiziert und mittels der Analyse des Cell crash Trace Files wurde klar, dass das Problem mit dem Cell Columnar Flash Cache zusammenhängt. Als initialer Workaround wurde dieses Feature deaktiviert, was es erlaubt hat, die Database Level Quarantine zu entfernen ohne dass es zu weiteren Crashs auf Zellenebene kam. Oracle hatte den Bug in der Zwischenzeit auch identifiziert und in einer neueren Version der Firmware behoben, die dann auch installiert wurde.
- Inkrementelle Statistiken funktionierten nicht mehr nach dem 19c Upgrade, da 19c die von 12.2 generierten Synopsen nicht verarbeiten kann, weil ein PL/SQL Fehler in internen Paketen auftritt, was dazu führt, dass effektiv die globalen Statistiken immer neu berechnet wurden anstatt inkrementelle Statistiken zu verwenden. Bisher steht als Workaround nur zur Verfügung, die Synopsen komplett neu zu berechnen, was keine empfehlenswerte Operation bei einem Multi-Terabyte Data Warehouse ist
- Allgemein ist die Performance des RACs in Produktion maßgeblich beeinflusst von einer signifikanten Zunahme an Cluster bezogenen Warteereignissen, insbesondere beträgt die durchschnittliche Wartezeit 50 mal länger in Produktion (40 ms im Vergleich zu 800 μs) als in Testumgebungen bei vergleichbarer Arbeitslast. Die Root Cause Analyse für dieses unterschiedliche Verhalten ist noch ausstehend zum Zeitpunkt des Schreibens
- Unabhängig vom Upgrade zeigten einige Tabellen sehr merkwürdiges Verhalten in Bezug auf SmartScan Performance und Platzbedarf, was zu sehr schlechter Performance führt – mehr als 60 Sekunden für einen trivialen, parallelen SELECT COUNT(*) einer 20 GB Partition, der Millionen logische I/Os zusätzlich generiert und dadurch den CPU Verbrauch auf den Compute Nodes nach oben treibt, sowie einen signifikant erhöhten Platzbedarf – anstatt 20 GB benötigt eine 1:1 Kopie der gleichen Daten mit gleicher Hybrid Columnar Compression (HCC) Kompressionsstufe nur ca. 400 MB, was 50mal weniger ist. Auch die SmartScan Performance auf dieser Kopie lag im erwarteten Bereich unter einer Sekunde. Block dumps zeigten leere HCC Compression Units und Chained Rows. Die derzeit verwendete Kombination aus HCC und Updates scheint die Daten in einem sehr ungünstigen Zustand zu hinterlassen, was Kompression, Chained Rows und Platzbedarf angeht
Eine Applikation zur Berechnung der optimalen Fahrtrouten von Paketauslieferungen zeigt immer wieder „Hänger“, bei denen minutenlang Jobs und Abfragen in der Datenbank hängen bleiben, was signifikante Auswirkung auf die gesamte Applikation hat, da die zeitnahe Neuberechnung der Routeninformation gewährleistet sein muss. Dieses Verhalten ist seit einer Datenbereinigungsaktion zu beobachten, bei der Daten aus der Datenbank gelöscht wurden und von der man sich positive Effekte auf die Performance und den Platzbedarf versprochen hat. Die Analyse ergibt, dass es sich um Sperrungen auf der Ebene des sogenannten „Library Caches“ der Oracle Datenbank handelt – der Cache, der vor allem dazu dient, alle verwendeten Objekte und deren Abhängigkeiten untereinander zu verwalten. Dazu muss man wissen, dass DDL Operationen exklusive Sperrungen auf Library Cache Ebene verursachen, als auch das Neuerstellen von Ausführungsplänen. Die erwähnte Applikation verwendet zum Teil partitionierte Tabellen – wobei es sich um eine fragwürdige Verwendung davon handelt, da pro Tag fast 600 neue Partitionen erzeugt werden. Das führt auch dazu, dass tagsüber während hoher Aktivität auf dem System es zu ALTER TABLE DDLs kommt, die neue Partitionen anlegen und somit vorhandene SQLs im Shared Pool invalidieren. Damit kommt es regelmäßig zu „Parse-Stürmen“, bei denen SQLs von vielen Sessions gleichzeitig ausgeführt werden, für diese SQLs aber erst wieder neue Ausführungspläne aufgrund der Invalidierung erzeugt werden müssen. In der Vergangenheit ist dies genauso geschehen, allerdings hat das Neuerstellen der Ausführungspläne nicht außergewöhnlich viel Zeit in Anspruch genommen, so dass die Auswirkung insgesamt vertretbar war. Seit der erwähnten Datenbereinigungsaktion verhielt sich der Optimizer aber anders, was dazu führte, dass die Erstellung des Ausführungsplans von SQLs, die die partitionierten Tabellen verwenden, extrem lange dauern kann – bis zu mehreren Minuten – und in dieser Zeit andere Sessions, die entweder auch das gleiche SQL versuchen auszuführen oder zu parsen, oder andere Sessions, die einen exklusiven Lock auf „Library Cache“ Ebene auf bestimmte Objekte benötigen, so lange warten müssen, bis für dieses SQL ein Ausführungsplan erstellt wurde. Dies führte zu teilweise extremen Wartesituationen. Ursache für die Verhaltensänderung war ein Feature der Datenbank, bei Einsatz von Parallel Execution beim Erstellen eines Ausführungsplans „Dynamic Sampling“ einzusetzen. Dieses „Dynamic Sampling“ kann bei partitionierten Tabellen eine IN Liste der zu samplenden Partitions-IDs bei Erzeugung der rekursiven Abfrage zur Ermittlung von Selektivitäten verwenden – bei höheren Sampling-Leveln kann es hier bis 512 Partitionen aufzählen. Die Verhaltensänderung bestand darin, dass der Sampling Level sich von Level 7 auf Level 8 erhöht hat, da die Tabelle insgesamt ca. 65 Millionen Blöcke hat und dies genau die Grenze darstellt, um von Level 7 auf Level 8 bei der automatischen Anpassung des Leves zu gehen. Daher wurden seitdem eben 512 Partitionen aufgelistet anstatt wie bisher nur 256. Dies wiederum hatte zur Folge, dass der Optimizer in einen Bug gelaufen ist beim Erstellen des Ausführungsplans für die rekursive „Dynamic Sampling“ Abfrage (durch Verlängerung der IN Liste), was dann für die minutenlange Verzögerung bei der Erstellung des Ausführungsplans des eigentlich betroffenen SQLs verantwortlich war. Als Workaround wurde eine Kombination aus SQL Plan Baseline und SQL Patch für die SQLs eingeführt, die von dem Problem maßgeblich betroffen waren bzw. die die meiste Auswirkung auf das System hatten, indem sie andere SQLs blockierten. Die Aufgabe der SQL Plan Baseline war die Fixierung des derzeitigen Ausführungsplans, während die Aufgabe des SQL Patches die Deaktivierung von „Dynamic Sampling“ war. Damit trat der beschriebene Effekt für diese SQLs nicht mehr auf. Die generelle, datenbankweite Abschaltung des Features, das die automatische Erhöhung des „Dynamic Sampling“ Levels bewirkt, wurde evaluiert und wird eventuell eingesetzt, sollte sich das Verhalten auch noch auf andere SQLs auswirken, die mit den bereits etablierten Mitteln nicht behandelt werden können – zum Beispiel SQL Texte, die Literale bzw. variabel lange IN Listen verwenden. Dazu wurde auch evaluiert, in welchem Maße sich die Verwendung von „Dynamic Sampling“ überhaupt derzeit positiv auf die Ausführungspläne auswirkt, um das mögliche Risiko bei Abschalten des Features besser einschätzen zu können.
Ausführliche Beschreibung. Demonstration und Diskussion der Oracle Exadata Database Machine in Form eines individuellen Workshops – Aufbau, Features (Storage Cells, Smart Scans, Flash Cache, Persistent Memory, RoCE, Hybrid Columnar Compression etc.), wann profitiert man von den speziellen Exadata Features, Analyse des Istzustands und Bewertung in Bezug auf Nutzungsmöglichkeiten / mögliche Vorteile eines Umstiegs auf Exadata sowie mögliche notwendige Anpassungen der derzeitig etablierten Prozesse (Backup, High Availability etc.) als auch Migrationsstrategien.
Individual Workshop zu Oracle Datenbank Performance Themen, insbesondere Locking, Parallelisierung, Indizierung, Analysemöglichkeiten innerhalb der Datenbank
Seit 2010:
- Regelmäßige Kurzeinsätze im Bereich Oracle Datenbank Performance Troubleshooting + Tuning
- Öffentliche Seminare + Webinare
- Regelmäßige Veröffentlichungen, unter anderem Co-Autor [Titel und ISBN auf Anfrage]
- Schulungen / Workshops in Zusammenarbeit der DOAG und im Auftrag der Oracle University
Auswahl Kurzeinsätze:
Zeitraum: März 2024
Name des Projekts:
Oracle
Datenbank 19c Migration Exadata nach Amazon RDS
Lokation:
Frankfurt
am Main / remote
Branche: Bank
Kurzbeschreibung:
Eine auf
Exadata hin optimierte, bestehende Applikation soll auf Amazon RDS migriert
werden. Dort zeigen sich bei ersten Tests signifikant längere Laufzeiten. Eine
Analyse der Datenbankaktivitäten zeigt an, dass bestimmte Abfragen Full Table
Scans auf großen Tabellen durchführen und durch die hohe Anzahl an
gleichzeitiger Ausführung eine Überlastung der CPUs auf dem Datenbankserver
verursacht wird. Verschiedene Ansätze und Lösungsstrategien wurden erarbeitet
und werden jetzt in weiteren Tests untersucht.
Zeitraum: August 2023 - März 2024
Name des Projekts: Unterstützung Oracle Upgrades, Sicherheit und Performance
Lokation: Münster, Deutschland / remote
Branche: Kommunalverwaltung
Kurzbeschreibung:
Eine selbst verwaltete Datenbank Infrastruktur bestehend aus über 40 Oracle Datenbanken unter Windows soll mittels automatischer Upgrades auf den aktuellen Release Update Stand von Oracle 19c gebracht werden ? je nach Sicherheitseinschätzung der von Oracle im Rahmen der ?Critical Patch Updates? gemeldeten Schwachstellen. Dazu soll evaluiert werden, ob das neue ?Autoupgrade? Tool von Oracle für eine Teilautomatisierung dieser Aufgabe eingesetzt werden kann. Darüber hinaus sollen eventuell auftretende Performance-Probleme analysiert und behoben werden.
Zeitraum: Januar 2024
Name des Projekts:
Oracle Datenbank 19c Performance Troubleshooting
Lokation: Frankfurt am Main
Branche: Bank
Kurzbeschreibung:
Sporadisch
auftretende ?Hänger? in Form von sehr langen Antwortzeiten in einer Oracle 19c
Datenbank führen zu ebenso sporadischen Ausfällen einer kritischen Inhouse
Applikation. Die Analyse ergibt extrem lange Wartezeiten auf verschiedene
Ereignisse, insbesondere ist I/O betroffen, sowohl beim Lesen von Blöcken als
auch beim Schreiben durch den Logwriter oder DB Writer. Eine Fehlkonfiguration
im Bereich des Netzwerks erklärt den hardwareseitigen Fehler, der zu den
sporadischen Hängern im Storage Bereich führt. Darüber hinaus zeigt sich, dass
verschiedene Datenbanken / Datenbank-Instanzen auf dem gleichen Host ausgeführt
werden ? eine davon (nicht die direkt betroffene) ist seitens der Connection
Pools der Applikation fragwürdig konfiguriert. Es werden tausende Verbindungen
zur Datenbank aufgebaut und teilweise sind dadurch auch tausende Sessions
gleichzeitig aktiv, je nach Lastprofil der Applikation. Nach Schwenk des
Servers in ein anderes Rechenzentrum treten die Probleme im Bereich des
Storages nicht mehr auf ? die Lastspitzen sind aber weiterhin problematisch.
Eine Detailanalyse der Aktivitäten, die zu den Lastspitzen führen und
Vorschläge, wie diese optimiert werden können, runden die initiale Analyse ab.
Zeitraum: Dezember 2023
Name des Projekts: Vortrag "Gutes Index Design - eine praktische Anleitung" auf der IT Tage 2023 Konferenz
Lokation: Frankfurt am Main
Branche: Konferenzen
Kurzbeschreibung:
Vortrag "Gutes Index Design - eine praktische Anleitung" auf der IT Tage 2023 Konferenz
Zeitraum: Dezember 2023
Name des Projekts:
Migration Oracle 19c Data Warehouse von AIX nach Linux
Lokation: Frankfurt am Main
Branche: Bank
Kurzbeschreibung:
Unterstützung
bei der Planung einer Migration von AIX nach Linux für ein Data Warehouse auf
Oracle 19c. Detaillierte Ausarbeitung der Zielkonfiguration und der Tests auf
der neuen Plattform.
Zeitraum: November 2023
Name des Projekts: Vortrag "Gutes Index Design - eine praktische Anleitung" auf der DOAG 2023 Konferenz
Lokation: Nürnberg
Branche: Konferenzen
Kurzbeschreibung:
Vortrag "Gutes Index Design - eine praktische Anleitung" auf der DOAG 2023 Konferenz
Zeitraum: Oktober 2023
Name des Projekts: Oracle Datenbank Workshop "Den kostenbasierten Optimizer verstehen"
Lokation: Frankfurt am Main
Branche: Bank
Kurzbeschreibung:
Workshop
?Den kostenbasierten Optimizer verstehen? ? grundlegende Prinzipien der
Entscheidungsfindung des Optimizers, was kann schief gehen und wie stelle ich
das fest, welche Möglichkeiten der Beeinflussung gibt es. Wie liest man
Ausführungspläne richtig, wie generiert man Laufzeitprofile von SQL-Ausführungen
und wertet diese aus. Wichtige Hinweise, auf was man bei der
Statistikgenerierung für den Optimizer achten sollte. Clustering von Daten
richtig verstehen und welche Möglichkeiten der Beeinflussung gibt es.
Zeitraum: September 2023
Name des Projekts: DOAG Expertenseminar ?Oracle Datenbank Indexing?
Lokation: DOAG
(Deutsche Oracle Anwender Gruppe) GmbH, Berlin
Branche: User
Group / Communities
Kurzbeschreibung:
Öffentliches Expertenseminar mit folgendem
Inhalt:
In diesem Seminar werden die wichtigsten Themen
bezüglich Indizierung mit B*Tree und Bitmap Indizes in der Oracle-Datenbank
behandelt ? Text / XML / JSON / Domain-Indizes werden zwar je nach verfügbarer
Zeit erwähnt und beschrieben, aber es wird nicht ausführlich darauf eingegangen
? der Schwerpunkt liegt eindeutig auf den B*Tree / Bitmap Indizes:
- Grundlagen: Wie ist ein B*Tree-Index aufgebaut, wie ein Bitmap-Index und welche Konsequenzen ergeben sich daraus? Wie verändert sich ein Index bei DML-Operationen und was ergibt sich daraus?
- Index Access, Filter und Clustering von Daten: Welche Operationen sind beim Index-Zugriff wann wie kostspielig? Warum wird der sogenannte Clustering Factor von Indizes häufig von der Datenbank falsch berechnet und was kann man dagegen machen? Warum kann ein Full Table Scan deutlich effizienter als ein Zugriff per Index sein? Indizes und der Optimizer - was wird bei der Kostenberechnung berücksichtigt, was nicht? OPTIMIZER_INDEX_COST_ADJ / OPTIMIZER_INDEX_CACHING, System Statistiken etc.
- Index Design: Auf was ist beim Design von Indizes zu achten? Was ist für die Reihenfolge von mehreren Ausdrücken in einem Index relevant? Wann ist ein Bitmap-Index sinnvoll? Was sind Function Based Indizes? Was sind virtuelle Spalten? Wie hängen diese Features zusammen und wann verwendet man welches dieser Features?
- Index Options: Invisible / Unusable / Virtual / Partial-Indizes. Primary Key / Unique / Deferred Constraints und Indizes.
- Index Compression: Wie funktioniert dieses Feature und was bringt es? Welche Auswirkungen gibt es? Unterschied zwischen Basic und Advanced Low / High Compression
- Indizes und DML: Was sind die Auswirkungen von Indizes bei DML-Operationen auf einer Tabelle? Typische Szenarien bei gleichzeitiger Veränderung von Tabellen und welche Maßnahmen hier helfen können - was sind die potentiellen Auswirkungen dieser Maßnahmen?
- Index Monitoring: Wie kann ich eine bestehende Applikation bezüglich der Indizierung überwachen und auf was ist dabei zu achten?
- Foreign Keys und Indizes: Wann sollten Foreign Keys indiziert sein, wann ist es nicht notwendig?
- Index Rebuild: Wann ist es sinnvoll, einen Index aktiv zu reorganisieren? Welche Möglichkeiten gibt es dafür und wie unterscheiden sie sich?Zeitraum: Juli 2023
Name des Projekts: Oracle Community Yatra Tour (OCYatra) 2023 Indien
Lokation:
AIOUG (All Indian Oracle User Group), Indien
Branche: User Communities
Kurzbeschreibung:
Als Teil
der Vortragenden auf der Oracle Community Yatra Tour (OCYatra) 2023 haben wir
sechs Städte (Chennai, Bangalore, Mumbai, Pune, Delhi, Hyderabad) in zwölf
Tagen besucht und in jeder Stadt einen Konferenztag mit jeweils bis zu 400
Teilnehmern gestaltet. Ich habe pro Konferenztag drei Vorträge gehalten:
Oracle 12c to 23c New Performance Features, Advanced Indexing und Advanced
Oracle Troubleshooting
Zeitraum: Juni 2023
Name des Projekts: Unterstützung Upgrade 11.2 nach 19cKurzbeschreibung:
Eine
komplexe, weitgehend datenbankbasierte Applikation (große Mengen an PL/SQL
Code) muss von Oracle Datenbank Version 11.2 auf 19c migriert werden.
Unterstützung in unterschiedlichen Bereichen ? detaillierte Beschreibung von
Verhaltensänderungen in 19c (zum Beispiel beim Einsatz von DBMS_JOB) als auch
Performance-Analyse bei Regressionen.
Zeitraum: Mai 2023
Name des Projekts:
Erweiterung
/ Anpassung Anonymisierung ECommerce Applikation
Lokation: Düsseldorf / Remote
Branche: Fashion /
Versandhandel
Kurzbeschreibung:
Eine
bereits vor zwei Jahren entwickelte Lösung zur performanten Anonymisierung von
relationalen und unstrukturierten XML-Massendaten wurde gemäß Kundenwunsch
angepasst und nochmals optimiert hinsichtlich Performance, da sich das
Verhalten mit aktuellen Oracle Versionen (19c) im Vergleich zu früheren Versionen
hinsichtlich Parallelisierung verändert hatte.
Zeitraum: April 2023
Name des Projekts: Oracle Datenbank 19c Performance Troubleshooting (Exadata)
Lokation: Frankfurt am Main / Remote
Branche: Finanzen
Kurzbeschreibung:
Nur mit
einer ganz bestimmten Kombination von Features tritt ein Langläufer Phänomen
beim Sammeln von Statistiken auf ? dazu gehören HCC Kompression, Parallelität,
Approximate NDV Statistikmodus, Offloading / Smart Scan, virtueller Spalte mit
CPU-intensiver Berechnung (zum Beispiel STANDARD_HASH) und ein bestimmter
Zustand der Zieltabelle nach DDL / Exchange Partition. Dann verlängert sich die
Zeit für die Statistikerstellung signifikant um mehrere Faktoren ? im Grunde
bringt die Parallelisierung in so einem Fall keine Zeitreduktion, da beliebig
viel CPU-Zeit verbraucht wird und die Dauer entspricht dann einer seriellen
Verarbeitung. Als erstes wurde ein Workaround entwickelt (ein CAST des
originären Ausdrucks auf den gewünschten Datentyp verhindert das Problem), als
zweites wurde an einem reproduzierbaren Testcase für den Oracle Support
gearbeitet.
Zeitraum: März 2023
Name des Projekts: Oracle Datenbank 19c Performance Troubleshooting (Exadata)
Lokation: Berlin / Remote
Branche: Versandhandel
Kurzbeschreibung:
Nach dem Installieren des Release Update 17 von 19c (RU 19.17) ist die gesamte Datenbank Performance sehr schlecht ? maßgeblich aufgrund sehr langsamen Transfer von Blöcken zwischen den RAC Instanzen ? anstatt durchschnittlich 400 µs pro übertragenem Block steigt dies auf fast 20.000 µs (!) an.
Eine Analyse zeigt, dass
die LMS Hintergrund-Prozesse, die in RAC für die Übermittlung der Blöcke
zuständig sind, fast permanent auf CPU Zeit verbringen, was vor der
Installation des RUs nicht der Fall war. Ein CPU Profiling zeigt an, dass die
Prozesse die gesamte Zeit beim Suchen im ?gcs resource table? verbringen, was
darauf hinweist, dass etwas mit der Verwaltung dieser Tabelle im Speicher
(Effiziente Aufteilung in ?Hash Buckets?) nicht stimmt ? es gab in der
Vergangenheit schon ähnliche Bugs in dem Bereich. Nach Rücksprache mit Oracle
Support und Einspielen entsprechender Bug Fixes ist das Problem gelöst.
Zeitraum: Februar 2023
Name des Projekts:
Individual Workshop ?Oracle Database Indexing?
Lokation: Saarbrücken
Branche: Software
Kurzbeschreibung:
In diesem Seminar werden die wichtigsten Themen bezüglich Indizierung mit B*Tree und Bitmap Indizes in der Oracle Datenbank behandelt:
- Grundlagen: Wie ist ein B*Tree Index aufgebaut, wie ein Bitmap Index und welche Konsequenzen ergeben sich daraus? Wie verändert sich ein Index bei DML Operationen und was ergibt sich daraus?
- Index Access, Filter und Clustering von Daten: Welche Operationen sind beim Index-Zugriff wann wie kostspielig? Warum wird der sogenannte Clustering Factor von Indizes häufig falsch berechnet von der Datenbank und was kann man dagegen machen? Warum kann ein Full Table Scan deutlich effizienter als ein Zugriff per Index sein? Indizes und der Optimizer ? was wird bei der Kostenberechnung berücksichtigt, was nicht? OPTIMIZER_INDEX_COST_ADJ / OPTIMIZER_INDEX_CACHING, System Statistiken etc.
- Index Design: Auf was ist beim Design von Indizes zu achten? Was ist für die Reihenfolge von mehreren Ausdrücken in einem Index relevant? Wann ist ein Bitmap Index sinnvoll?
- Index Compression: Wie
funktioniert dieses Feature und was bringt es? Welche Auswirkungen gibt es?
Unterschied zwischen Basic und Advanced Low / High Compression
Zeitraum: Januar 2023
Name des Projekts: Datawarehouse
Performance Beratung
Lokation: Wiesbaden
Branche: Versicherung / Software
Kurzbeschreibung:
Optimierung
hochkomplexer SQLs als Teil der Beladungsstrecken einer neuen Data Warehouse
Umgebung. Diese verwendet eine doppelt temporale Speicherung der Daten
(technische und fachliche Gültigkeiten), was die Komplexität und auch die zu
verarbeitenden Datenmengen entsprechend erhöht. Die Überwachung dieser SQLs
funktioniert mit Oracle Bordmitteln nicht richtig, da die SQLs zu lange laufen
(mehrere Stunden) und die Ausführungspläne so komplex sind (teilweise mehr als
1000 Operationen), dass das eingebaute Real-Time SQL Monitoring der Datenbank
nur unvollständige Berichte generiert. Die Implementierung einer
automatisierten, eigenen Logik, bei der zum Einen die unvollständigen Berichte
regelmäßig in einer Tabelle abgespeichert werden und zum Anderen diese Menge an
unvollständigen Berichten dann wieder zu einem einzelnen, vollständigen Bericht
zusammengesetzt werden, erlaubt eine effiziente Analyse dieser mittels der
Parallelverarbeitungsoption ausgeführten SQLs und eine entsprechende
Optimierung. Eine Reduktion der Laufzeiten um 50% oder mehr dieser komplexen
SQLs konnte damit erreicht werden.
Zeitraum: Dezember 2022
Name des Projekts:
Individual Workshop ?Database Performance: Hands On?
Lokation: Saarbrücken
Branche: Software
Kurzbeschreibung:
Vortrag Einführung
in die systematische Analyse und Verbesserung von Oracle Datenbank Performance.
Kennenlernen und Üben verschiedener Werkzeuge wie SQL Trace, Rowsource
Statistiken, AWR / ADDM / Statspack, SQL Monitoring, korrektes Lesen und
Verstehen von Ausführungsplänen etc.
Zeitraum: Dezember 2022
Name des Projekts: Vortrag auf der IT Tage 2022 Konferenz
Lokation: Frankfurt
Branche: Konferenzen
Kurzbeschreibung:
Vortrag ?Kostenlos! Die am wenigsten benutzten Performance Features der Oracle Datenbank? auf den IT Tagen 2022
Zeitraum: November 2022 - Januar 2023
Name des Projekts:
Individual Workshop Oracle Datenbank Performance
Lokation: Frankfurt
Branche: Finanzen
Kurzbeschreibung:
Unterstützung
beim Testen unterschiedlicher Partitionierungsstrategien im Data Warehouse
Umfeld, korrektes Aufsetzen der Testumgebung / Daten / Statistiken. Auswertung
der Ausführungspläne / Performance / Vergleich zwischen alter und neuer Strategie
Zeitraum: Oktober 2022
Name des Projekts:
Oracle Datenbank 19c Performance Troubleshooting (Exadata)
Lokation: Berlin / Remote
Branche:
Versandhandel
Kurzbeschreibung:
Nach dem Installieren des Release Update 15 von 19c (RU 19.15) gibt es Laufzeitprobleme mit Tableau Berichten ? Ausführungspläne verwenden Indizes und Nested Loop Joins obwohl diese Indizes als ?INVISIBLE? markiert sind, was zu sehr langen Laufzeiten führt.
Eine Analyse ergibt, dass Auslöser der Probleme sehr schlechte Abschätzungen auf bestimmten, kleinen Dimensionstabellen sind. Diese werden vom Optimizer so abgeschätzt, dass die angewendeten Filter keine Daten zurückliefern, was grob falsch ist. Der Grund für die falsche Abschätzung ist das ?Dynamic Sampling? Feature der Datenbank und der Zustand dieser kleinen Tabellen, die viel mehr Platz allokieren als sie eigentlich müssten / sollten, was dazu führt, dass das ?Dynamic Sampling? nicht gut funktioniert (das Sampling greift nur auf leere Blöcke zu, wenn man Pech hat, da das Segment so viele leere Blöcke beinhaltet) und daher die Abschätzungen so negativ beeinflusst.
Die ?INVISIBLE? Indizes kommen nur daher zum Zuge, da bestimmte Views den Hint ?USE_INVISIBLE_INDEXES? beinhalten ? aber auch ohne Verwendung dieser Indizes sind die Ausführungspläne aufgrund der schlechten Abschätzungen ineffizient.
Eine Reorganisation der
betroffenen Tabellen löst das Problem ? Hinweise werden noch zur Verfügung
gestellt, wie das Problem in Zukunft vermieden werden könnte, indem die
Tabellen auf eine andere Art und Weise gepflegt werden (Vermeiden der
Kombination aus Updates auf komprimierten Daten, Deletes und Insert APPEND).
Zeitraum: Oktober - Dezember 2022
Name des Projekts: Unterstützung
Migration Oracle Datenbank
Lokation: Frankenthal / Polen / Remote
Branche: Logistik, Software
Kurzbeschreibung:
Unterstützung
bei der Vorbereitung und Durchführung der Migration einer bestehenden Logistik
Software von Oracle 11.2.0.4 auf Oracle 19c.
Zeitraum: September 2022
Name des Projekts:
Vortrag
auf der DOAG 2022 Konferenz
Lokation: Nürnberg
Branche:
Konferenzen
Kurzbeschreibung:
Vortrag ?Kostenlos!
Die am wenigsten benutzten Performance Features der Oracle Datenbank? auf der
DOAG Konferenz 2022
Zeitraum: Juni bis September 2022
Name des Projekts: Beratung Entwicklung Archivierungslösung Exadata
Lokation: Frankfurt am Main / remote
Branche: Finanzen / IT
Kurzbeschreibung:
Eine Bank möchte eine Inhouse Lösung zur Archivierung von Applikationsdaten entwerfen, die die Daten in einer Oracle Datenbank auf Exadata mit ZFS Storage speichert. Es soll den Applikationen ein generisches Datenbank-Interface zur Verfügung gestellt werden, das die Archivierung von Oracle Tabellen revisionssicher ermöglicht. Dazu werden verschiedene Oracle Datenbank Features wie ?Immutable Tables? und ?Database Vault? evaluiert.
Zeitraum: Juni 2022
Name des Projekts: Exadata Workshop
Lokation: Oberhausen / remote
Branche: Software
Kurzbeschreibung:
Ausführliche Beschreibung. Demonstration und Diskussion der Oracle Exadata Database Machine in Form eines individuellen Workshops ? Aufbau, Features (Storage Cells, Smart Scans, Flash Cache, Persistent Memory, RoCE, Hybrid Columnar Compression etc.), wann profitiert man von den speziellen Exadata Features, detaillierter technischer Hintergrund, wie die diese Features funktionieren und wie deren Einsatz analysiert und gemessen werden kann.
Zeitraum: Mai 2022
Name des Projekts: DOAG Expertenseminar ?Database Performance: Hands On?
Lokation: Berlin
Branche: User Group / Schulung
Kurzbeschreibung:
Öffentliches Expertenseminar mit folgendem Inhalt:
In diesem Workshop Oracle Database Performance: Hands-on lernen wir anhand verschiedener praktischer Beispiele unterschiedliche Techniken kennen, mit denen Performance in der Datenbank im Detail analysiert werden kann. Es geht dabei um die Antwort auf die Frage, womit die Zeit in der Datenbank verbracht wird und wie dies gemessen werden kann.
Die Teilnehmer führen die Schritte unter Anleitung des Seminarleiters in ihrer eigenen oder einer vorbereiteten Datenbank durch und bekommen dadurch praktische Erfahrung, wie die jeweiligen Techniken funktionieren und was es bei der Anwendung zu beachten gilt.
Zeitraum: Februar ? April 2022
Name des Projekts: Performance Optimierung Oracle 19c (Exadata)
Lokation: Frankfurt / Remote
Branche: Bank
Kurzbeschreibung:
Eine hauseigene Applikation soll auf Exadata migriert werden. Auf der Exadata Umgebung laufen jedoch einfache Updates und Inserts deutlich langsamer als auf den nicht-Exadata Umgebungen. Eine genauere Analyse ergibt, dass hier ?Flashback Database Archive (FBDA)? zum Einsatz kommt und die Verzögerungen hauptsächlich durch die rekursiven Aktivitäten von FBDA verursacht werden. Die Symptome, validiert durch einen SQL Trace, entsprechenden denen im Bug "Bug 31201192 - Hang with 'fbar timer'<='enq: tx - contention' (Doc ID 31201192.8)" beschriebenen. Dem Kunden wird nahegelegt, den verfügbaren Patch als ?Backport? für die eingesetzte Version von Oracle 19c bei Oracle Support zu beantragen.
Desweiteren laufen auf der Exadata bestimmte Import-Prozesse, bei denen aus Applikationssicht nur einfache Batch-Inserts durchgeführt werden, auf der Exadata sehr langsam. Eine Analyse zeigt, dass die Datenbank sich damit beschäftigt, tausende von Child Cursorn für diese Inserts zu erzeugen / zu verwalten. Das Grundproblem besteht in der Verwendung von falschen Datentypen beim Binden von Bind-Variablen von Applikationsseite. Nach Korrektur der Datentypen laufen die Inserts um Faktor 1000 schneller und die Anzahl der Child Cursor reduziert sich auf wenige einzelne.
Zeitraum: März 2022
Name des Projekts: Performance Optimierung Oracle 19c
Lokation: Frankfurt / Remote
Branche: Bank
Kurzbeschreibung:
Umstellung der internen Speichermethode von XML-Daten. Oracle verwendet eigentlich seit Version 11.2 intern die Speichermethode ?Binary XML? für XMLType Daten. Eine Software eines Drittherstellers verwendete jedoch explizit noch die Speichermethode ?CLOB?, was deutlich mehr Platz in der Datenbank belegt. Nach Abklärung mit dem Hersteller wurde ein Migrationskonzept mit automatisierter Umstellung von über 5.000 bestehenden Tabellen erstellt und auch umgesetzt, so dass innerhalb weniger Minuten diese Tabellen auf ?Binary XML? Speichermethode umgestellt wurden ? dazu wurde mittels Create Table As Select (CTAS) eine temporäre Kopie der jeweiligen Tabelle angelegt und die alte Tabelle entsprechend entfernt / ersetzt, automatisiert per Skript. Als Absicherung für den Fall, dass die Migration nicht erfolgreich ist oder nachfolgend Probleme in der Applikation auftreten, wurde die Original-Datenbank (Oracle 19c CDB/PDB Architektur) als PDB-Kopie erhalten.
Zeitraum: März 2022
Name des Projekts: Individual Workshop ?Datenbank Performance für Entwickler?
Lokation: Monheim (Schwaben), Deutschland
Branche: Bank
Kurzbeschreibung:
Workshop ?Datenbank Performance für Entwickler? ? Beschreibung:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um effektiver mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt, eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
- Instrumentierung
- Trace / Row Source Statistics / Active Session History / Real Time SQL Monitoring
- Grundlagen Optimizer, Histogramme, Statistiken (inkl. New Features 12c)
- (serielle) Ausführungspläne richtig lesen
- Indizierung
- Clustering / Speicherformen inkl. New Features 12c: Attribute Clustering / Zonemaps, Heap, Index Organized Tables, Cluster
- Hints
- Bind Variablen / Literale und ungleichmäßige Datenverteilung
- Datenbank Links / Transaktionen / Locks
Zeitraum: Dezember 2021 / Februar 2022
Name des Projekts: Vortrag auf der All Indian Oracle User Group AIOUG Konferenz 2021 / 2022
Lokation: Remote
Branche: Konferenzen
Kurzbeschreibung:
Vortrag ?Oracle Database 21c New Performance Features? auf der Sangam 21 / All Indian Oracle User Group (AIOUG) 2022 Konferenz
Zeitraum: November - Dezember 2021
Name des Projekts: Performance Optimierung Oracle
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
Abfragen in einem Data Warehouse verhalten sich unterschiedlich, je nachdem, wie auf die Partitionen der Daten zugegriffen wird. Bei Verwendung einer einzigen Partition sind die grundsätzlichen Abschätzungen des Optimizers so weit schlüssig, bei Zugriff auf mehrere Partitionen sind die Abschätzungen sehr schlecht. Es stellt sich heraus, dass durch die Verwendung von inkrementellen Statistiken ein Bug entsteht, der die Spaltenstatistiken des Partitionsschlüssels auf globaler Ebene verfälscht, so dass je nach Datenmenge pro Partition völlig falsche Annahmen seitens des Optimizers getroffen werden. Es werden verschiedene Lösungsmaßnahmen besprochen (unter anderem Verhinderung der Erzeugung eines Histogramms) und ein generischer Testcase für Oracle Support vorbereitet, um den Bug nachstellen zu können.
Abfragen, die versuchen, auf bestimmte Partitionen dynamisch einzuschränken per Unterabfrage erreichen nur inkonsistentes Partition Pruning. Da der Kunde bereits auf Oracle 19c ist, wird dieses Problem mittels ?SQL Macros? adressiert, was erlaubt, den Partitionsschlüssel als Literal anzugeben und trotzdem dynamisch zu bestimmen.
Darüber hinaus gibt es noch Probleme mit bestimmten Transformationen seitens des Optimizers (?Group By Placement?), die zu schlechten Abschätzungen und als Folge zu ineffizienten Ausführungsplänen führen. Dies kann durch eine Parametereinstellung verhindert werden.
Zeitraum: November - Dezember 2021
Name des Projekts: Vortrag auf DOAG 2021 und IT Tage 2021 Konferenzen
Lokation: Nürnberg / Frankfurt / Remote
Branche: Konferenzen
Kurzbeschreibung:
Vortrag ?Oracle Database 21c New Performance Features? in auf der DOAG Konferenz 2021 sowie den IT Tagen 2021
Zeitraum: Oktober 2021
Name des Projekts: Vorträge trivadis Performance Days
Lokation: Zürich, Schweiz
Branche: Software
Kurzbeschreibung:
Vorträge im Rahmen der trivadis Performance Days 2021: ?Oracle Datenbank 21c New Performance Features? und ?Oracle Datenbank Indexing Myths?
Zeitraum: Oktober 2021
Name des Projekts: DOAG Expertenseminar ?Datenbank-Performance für Entwickler?
Lokation: Berlin / Remote
Branche: User Group / Schulung
Kurzbeschreibung:
Öffentliches Expertenseminar mit folgendem Inhalt:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um effektiver mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
- Instrumentierung
- Trace / Row Source Statistics / Active Session History / Real Time SQL Monitoring
- Grundlagen Optimizer, Histogramme, Statistiken (inkl. New Features 12c)
- (serielle) Ausführungspläne richtig lesen
- Indizierung
- Clustering / Speicherformen inkl. New Features 12c: Attribute Clustering / Zonemaps, Heap, Index Organized Tables, Cluster
- Hints
- Bind Variablen / Literale und ungleichmäßige Datenverteilung
Zeitraum: September bis Oktober 2021
Name des Projekts: Oracle Datenbank 19c Performance Troubleshooting (Exadata)
Lokation: Berlin / Remote
Branche: Versandhandel
Kurzbeschreibung:
Verschiedene mittels Tableau erzeugte Berichte schwanken stark in der Laufzeit. Es gilt zu ermitteln, ob die Schwankungen maßgeblich durch unterschiedliches Verhalten in der Datenbank verursacht werden oder es andere Gründe außerhalb der Datenbank gibt, wie zum Beispiel Netzwerk oder auch auf Applikationsebene (Tableau Reporting Plattform).
Eine Analyse ergibt, dass die Datenbank zwar teilweise an den unterschiedlichen Laufzeiten beteiligt ist, dies aber nur aufgrund unterschiedlicher Auslastung, aber nicht aufgrund unterschiedlicher Ausführungspläne oder anderer Gründe. Maßgeblich werden die Schwankungen durch die Reporting Plattform verursacht, die sehr stark unterschiedlich lange benötigt, um die bereits von der Datenbank zur Verfügung gestellten Daten abzuholen.
Zeitraum: September 2021
Name des Projekts: Workshop ?Datenbank Performance für Entwickler?
Lokation: Wiesbaden / Remote
Branche: Versicherung / Software
Kurzbeschreibung:
Workshop ?Datenbank Performance für Entwickler? ? Beschreibung:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um effektiver mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt, eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
- Instrumentierung
- Trace / Row Source Statistics / Active Session History / Real Time SQL Monitoring
- Grundlagen Optimizer, Histogramme, Statistiken (inkl. New Features 12c)
- (serielle) Ausführungspläne richtig lesen
- Indizierung
- Clustering / Speicherformen inkl. New Features 12c: Attribute Clustering / Zonemaps, Heap, Index Organized Tables, Cluster
- Hints
- Bind Variablen / Literale und ungleichmäßige Datenverteilung
Zeitraum: August 2021
Name des Projekts: Oracle / MySQL Datenbank Performance Troubleshooting
Lokation: Mainz / Remote
Branche: Software / Banking
Kurzbeschreibung:
Der Export von historischen Daten ist bei einer Standardsoftware sehr langsam, da SQLs pro Datensatz ausgeführt werden, und pro Ausführung mehrere Sekunden an Laufzeit entstehen. Unter MySQL ist die Ausführung nochmal deutlich langsamer als unter Oracle. Eine detaillierte Analyse zeigt, dass die Datenbanken aufgrund der Art und Weise, wie das SQL geschrieben ist, nicht in der Lage sind, die Historie nur für die in Frage kommenden Datensätze zu ermitteln, sondern jeweils die komplette Datenmenge mehrfach pro SQL-Ausführung verarbeiten.
Durch Umformulierung der SQLs (mittels Verwendung von LATERAL Views) wird sowohl Oracle als auch MySQL in die Lage versetzt, die Historie nur für die relevanten Datensätze zu ermitteln, was einer Performance-Steigerung von Faktor 1000 entspricht, da jetzt nur noch wenige Millisekunden für eine einzelne Ausführung benötigt werden, anstatt mehrerer Sekunden.
Zeitraum: August 2021
Name des Projekts: Oracle Datenbank Performance Troubleshooting
Lokation: Oberhaching / Remote
Branche: Software / Logistik
Kurzbeschreibung:
Eine Software verwendet weitgehend noch den Rule Based Optimizer (RBO), der allerdings bei einigen Abfragen schlechte Ausführungspläne produziert. Bei Verwendung des Cost Based Optimizers (CBO) gibt einige wenige SQLs, die wiederum deutlich langsamer sind als bei Verwendung des RBOs. Diese wurden detailliert analysiert und Vorschläge unterbreitet, wie sie ähnlich effizient wie mit dem RBO gestaltet werden können. Es stellte sich heraus, dass die Verwendung von außergewöhnlichen Konstrukten (skalare Unterabfrage in der ORDER BY Klausel) dazu führte, dass der CBO bestimmte Transformationen zur effizienten Umsetzung von OR Klauseln nicht anwendete. Die betroffenen Statements werden jetzt mit einer früheren CBO-Version (OPTIMIZER_FEATURES_ENABLE Hint) betrieben, die das Problem nicht hat und somit trotz Verwendung von skalarer Unterabfrage in der ORDER BY Klausel und OR-Klauseln einen effizienten Ausführungsplan generiert.
Zeitraum: Januar - Juli 2021
Name des Projekts: Anonymisierung ECommerce Applikation
Lokation: Düsseldorf / Remote
Branche: Fashion, Versandhandel
Kurzbeschreibung:
Design und Umsetzung einer automatisierten Anonymisierung und Übertragung der Produktionsdatenbank in Testumgebungen. Die zu maskierenden Felder und die dafür verwendeten Regeln sind konfigurierbar über Metadaten, als auch die resultierende Datenmenge (zum Beispiel nur 10% des Originaldatenbestandes). Die Maskierung erfolgt performanceoptimiert über entsprechend automatisch mittels Metadaten generierte CTAS (Create Table As Select) Operationen, da die Laufzeiten durch die massive Verwendung von XML in der Datenbank eine wichtige Rolle spielen.
Durch entsprechende Optimierung der CTAS Operationen kann die Laufzeit um Faktor 20 bis 40 erhöht werden und damit das Gesamtvolumen an zu maskierenden Daten in unter 24 Stunden verarbeitet werden trotz der komplexen Maskierungsregeln auf XML-Dokument Ebene. Für Bugs, die nach dem Oracle 19c Upgrade eine Verarbeitung aufgrund von PGA Speicherleaks und exzessiver TEMP Allokation unmöglich machten, wurde noch eine iterative Verarbeitung in Teilstücken implementiert, um die Probleme zu umgehen.
Zeitraum: Juli 2021
Name des Projekts: Individual Workshop ?Datenbank Performance für Entwickler?
Lokation: Karlsruhe
Branche: Logistik Software
Kurzbeschreibung:
Individual Workshop ?Datenbank Performance für Entwickler? ? inklusive Analyse von individuellen Problemfällen und Vorschlägen, wie diese verbessert werden können. Dazu noch Vorschläge, wie die Diagnosemöglichkeit von Applikationsseite verbessert werden kann, durch zum Beispiel selektives Aktivieren von SQL Trace und automatisiertes Einsammeln erweiterter Informationen bezüglich Ausführungsplänen.
Zeitraum: Juni 2021
Name des Projekts: DOAG Expertenseminar ?Parallel Execution Masterclass?
Lokation: DOAG (Deutsche Oracle Anwender Gruppe) GmbH, Berlin / remote
Branche: User Group / Schulung
Kurzbeschreibung:
Öffentliches Expertenseminar mit folgendem Inhalt:
- Wie lese ich einen Ausführungsplan richtig? Gibt es besondere Regeln für parallele Ausführungspläne? Und falls ja, wie sehen diese aus?
- Wie führt Oracle so einen Ausführungsplan zur Laufzeit aus?
- Was machen diese ganzen Operationen, die mit PX anfangen, in einem parallelen Ausführungsplan? Was sagen mir die zusätzlichen Spalten, die es nur in einem parallelen Ausführungsplan gibt?
- Wie funktioniert diese automatische parallele Ausführung von SQL Statements zur Laufzeit? Was wird parallelisiert, und wie wird die Arbeit automatisch aufgeteilt? Was kann dabei schiefgehen? Falls etwas schiefgeht, kann ich es beeinflussen, und falls ja, wie?
- Warum sind manchmal parallele Ausführungen nicht viel schneller als serielle, oder sogar langsamer, und warum verbrauchen parallele Ausführungen teilweise so viel mehr PGA-Speicher und/oder TEMP-Speicherplatz wie vergleichbare serielle Ausführungen?
- Wie kann ich eine SQL Statement-Ausführung analysieren, um zu verstehen, warum sie länger braucht als erwartet? Wie setze ich die Diagnostics- und Tuning-Pack License Features optimal in diesem Zusammenhang ein?
- Wie kann ich speziell parallele SQL-Ausführungen analysieren, um zu verstehen, ob Parallel Execution hier überhaupt effizient eingesetzt wird? Warum sind die für serielle Ausführungen bekannten Analyse-Methoden dafür größtenteils ungeeignet?
- Wie kann ich parallele Ausführungen schon beim physischen Datenbank-Design schneller machen?
- Welche neuen Parallel Execution Features sind in Oracle 12c dazugekommen?
Der Workshop vermittelt ausführliche Antworten zu diesen Fragen. Darüber hinaus bietet es Ihnen zu einem großen Teil exklusives Wissen, das von mir selbst erarbeitet wurde. Dieses Wissen werden Sie woanders - auch nicht in den offiziellen Unterlagen und Schulungen von Oracle - finden.
Zeitraum: Juni 2021
Name des Projekts: Oracle Datenbank Performance Troubleshooting
Lokation: Oberhaching / Remote
Branche: Software / Logistik
Kurzbeschreibung:
In einer operativen Datenbank werden bestimmte Berichte erstellt, die eigentlich in einer Data Warehouse Umgebung erstellt werden sollen, derzeit aber nicht erstellt werden können.
Daher sind die Daten in der operativen Datenbank nicht für diese Art von Abfragen optimiert, was Schema Design, Partitionierung und Indizierung angeht.
Aufgrund der nur vorübergehenden Natur (die Berichte sollen dann in absehbarer Zukunft im Data Warehouse erstellt werden) sollen auch keine größeren Anpassungen / Änderungen an der operativen Datenbank durchgeführt werden.
Als Problem stellt sich der Zugriff auf eine größere Tabelle mit Milliarden von Zeilen dar. Durch eine entsprechende Indizierung kann der Tabellenzugriff komplett vermieden werden, was die Laufzeit der relevanten Berichte entsprechend verbessert und Langläufer im Stunden-Bereich verhindert.
Für einen bestimmten Bericht wurde die Generierung der Informationen von einem iterativen Schleifenansatz mit potenziell sehr vielen Wiederholungen auf ein einzelnes SQL umgestellt, das die Daten zuverlässig innerhalb weniger Minuten generiert, was für die Nachtverarbeitung völlig ausreichend ist. Der Schleifenansatz war im Gegensatz dazu schlecht vorhersehbar, was die Gesamtlaufzeit angeht und deutlich langsamer (im Stundenbereich)
Zeitraum: Mai 2021
Name des Projekts: Detailanalyse Feature Usage Standard Edition Lizenz
Lokation: Hamburg / Staufen / Remote
Branche: Lizenzberatung / Labortechnik
Kurzbeschreibung:
Ein Kunde überprüft die Angabe der "Feature Usage" in DBA_FEATURE_USAGE_STATISTICS als Vorbereitung für einen License Audit seitens Oracle. Obwohl der Kunde nur über eine "Standard Edition" Lizenz verfügt und sich an keine aktive und absichtliche Nutzung von Enterprise Edition Features erinnern kann, werden dort sowohl "Real Application Security" als auch "Adaptive Plans" als benutztes Feature angezeigt - welche beide als "Enterprise Edition" Features seitens Oracle geführt werden.
Eine detaillierte Analyse ergibt, dass beide Features bereits bei der Standard-Installation einer 12.2.0.1 Standard Edition als "in use" angezeigt werden, da Oracle entsprechende Objekte in der "Template"-Datenbank mitliefert, die eine Nutzung von "Real Application Security" anzeigen, und auch fälschlicherweise den Parameter "OPTIMIZER_APAPTIVE_PLANS" auf "TRUE" setzt, obwohl dieses Feature in der "Standard Edition" überhaupt nicht zur Verfügung steht.
Insofern sollte der Kunde bezüglich eines Audits seitens Oracle hier auf der sicheren Seite sein.
Zeitraum: Januar - April 2021
Name des Projekts: Data Warehouse Upgrade 19c Troubleshooting (Exadata)
Lokation: Frankfurt am Main / Remote
Branche: Bank
Kurzbeschreibung:
Verschiedene Abfragen verlängern sich signifikant in der Laufzeit nach dem Upgrade von 18c auf 19c und dem Hochsetzen des Parameters OPTIMIZER_FEATURES_ENABLE von ?11.2.0.4? auf ?19.1.0?. Detaillierte Analyse der unterschiedlichen Abfragen mit Vorschlägen, wie funktionierende Workarounds aussehen können. Weitere Probleme unterschiedlichster Natur treten auf, von Planregressionen bis hin zu ORA-Fehlermeldungen beim Parsen sowie falschen Ergebnissen. Unterstützung bei der Zusammenarbeit mit Oracle Support mittels Vorbereitung entsprechender generischer Test Cases. Entwicklung entsprechender Workarounds für die genannten Probleme.
Zeitraum: Februar - März 2021
Name des Projekts: Analyse Performance / Speicherbedarf nach Oracle 19c Upgrade
Lokation: Frankfurt am Main / Remote
Branche: Bank
Kurzbeschreibung:
Nach einem Upgrade von Oracle 12.1 auf 19c gibt es mehrere Performance Probleme sowie Abbrüche in der Verarbeitung aufgrund von unzureichendem PGA Speicher. 19c benötigt signifikant mehr PGA Speicher pro Prozess und die Applikation erzeugt über mehrere Knoten von Application Servern mehrere Connection Pools, was zu einer hohen Grundlast an Prozessen führt. Desweiteren kommt seit der Version 18c einer neuer Speicherbereich zum Einsatz - die sogenannte ?MGA" ? ein Zwitter aus privaten und geteiltem Speicher, da ?Shared Memory? bei Bedarf dynamisch allokiert und zwischen mehreren Prozessen geteilt wird. Diese zusätzliche Speicherkomponente macht insbesondere unter Solaris Probleme, da zur Laufzeit immer wieder Allokationsfehler und damit Abbrüche auftreten können.
Das MGA-Problem kann mittels einiger interner Parameter umgangen werden, um die neue Speicherallokation in dem MGA Bereich zu verhindern.
Durch die erhöhte PGA Allokation unter 19c ist auch eine Anpassung der Parameter PGA_AGGREGATE_TARGET und PGA_AGGREGATE_LIMIT angezeigt, da die Instanz effektiv mehr PGA benötigt als per PGA_AGGREGATE_TARGET zugewiesen.
Die Performance Probleme sind nach entsprechender PGA Parameteranpassung und Erhöhung des physisch zur Verfügung stehenden Speichers auf Host Ebene weitgehend gelöst ? eine Übersicht der Top SQLs, die Potential für effizientere Ausführung haben, wurde zusätzlich geliefert sowie noch einige andere Fragen bezüglich Indizierung, Konfiguration Maintenance Windows, ?Killed Sessions? etc. beantwortet.
Zeitraum: November - Dezember 2020
Name des Projekts: Vortrag auf DOAG 2020 und IT Tage 2020 Konferenzen
Lokation: Nürnberg / Frankfurt / Remote
Branche: Konferenzen
Kurzbeschreibung:
Vortrag ?Oracle Database Performance Tuning: Back To Basics? in auf der DOAG Konferenz 2020 sowie den IT Tagen 2020
Zeitraum: November 2020
Name des Projekts: Oracle Datenbank Performance Troubleshooting
Lokation: Oberhaching / Remote
Branche: Software / Logistik
Kurzbeschreibung:
Eine hoch frequent aufgerufene Schnittstellen-Funktion arbeitet mindestens 12 Sekunden pro Aufruf ? häufig auch länger, was zu einer Warteschlange für die zu verarbeitenden Aufrufe führt. Teilweise müssen solche Aufrufe dann über 20 Minuten in der Warteschlange verbringen, was dann wiederum zu Timeouts in den aufrufenden Systemen führt. Durchschnittlich müssen Anfragen ca. 3 Minuten in der Warteschlange verbringen.
Eine Analyse zeigt, dass ein signifikanter Teil der Verarbeitungszeit in der Datenbank verbracht wird und dort vor allem ein SQL für die Laufzeit maßgeblich verantwortlich ist. Das SQL verwendet einen MINUS Operator, um ein Delta an einzufügenden Daten zu ermitteln. Da in der Zieltabelle Millionen von Datensätzen für diese Operation identifiziert werden und der MINUS Operator eine eindeutige Sortierung dieser Datenmenge benötigt, wird die Laufzeit für diese Sortieroperation maßgeblich über die zu sortierende Datenmenge bestimmt und kann daher nicht ohne weiteres optimiert werden. Leider akzeptiert die Datenbank nicht die automatische Umwandlung der MINUS SET Operation in einen Join (SET_TO_JOIN Transformation), was es erlaubt hätte, ohne Änderung des SQLs diese Umformulierung zu erreichen. Da das SQL aus einem PL/SQL Paket in der Datenbank stammt, ist eine semantisch äquivalente Umformulierung des SQLs von MINUS nach NOT EXISTS technisch möglich, ohne an anderem Quellcode der Applikation Änderungen vornehmen zu müssen. Daher wird dieser Weg eingeschlagen, nachdem mittels entsprechender Tests sichergestellt ist, dass das umformulierte SQL die gleichen Ergebnisse liefert. Da die andere Menge des MINUS Operators in den allermeisten Fällen sehr klein ist, kann der Optimizer aufgrund der Umwandlung des MINUS in einen Join effizientere Zugriffswege verwenden und vor allem die aufwändige Sortierung der großen Datenmenge vermeiden. Das umformulierte SQL benötigt nur noch ca. 3 bis 5 Sekunden zur Ausführung - nach Erzeugung eines geeigneten Index sinkt die Verarbeitungszeit auf Sekundenbruchteile.
Die durchschnittliche Wartezeit von Anfragen nach dieser Änderung sinkt von über 3 Minuten auf 2 Sekunden ? Timeouts treten somit keine mehr auf und die allgemeine Verarbeitungsgeschwindigkeit steigt signifikant an.
Zeitraum: Oktober 2020
Name des Projekts: Performance Analyse Applikation Upgrade Oracle 19c
Lokation: Stuttgart
Kurzbeschreibung:
Performance Analyse der Datenbank-Aktivitäten einer komplexen Auswertungslogik implementiert in PL/SQL nach Upgrade auf Oracle 19c. Einige Abfragen haben sich seit der letzten Analyse im Januar verändert, so dass die vorherig vorgeschlagenen Indizes angepasst werden müssen. Durch Anpassung und Ergänzung geeigneter Indizes kann die Verarbeitungszeit von über 30 Minuten auch für die größten Auswertungen auf unter 10 Minuten reduziert werden, so dass jetzt alle Auswertungen erfolgreich zu Ende laufen und nicht länger als die Timeout-Grenze von 30 Minuten benötigen.
Zeitraum: Oktober 2020
Name des Projekts: Optimizer Workshop
Lokation: Merzig / Remote
Kurzbeschreibung:
Workshop ?Den kostenbasierten Optimizer verstehen? ? grundlegende Prinzipien der Entscheidungsfindung des Optimizers, was kann schief gehen und wie stelle ich das fest, welche Möglichkeiten der Beeinflussung gibt es. Wie liest man Ausführungspläne richtig, wie generiert man Laufzeitprofile von SQL-Ausführungen und wertet diese aus. Wichtige Hinweise, auf was man bei der Statistikgenerierung für den Optimizer achten sollte. Clustering von Daten richtig verstehen und welche Möglichkeiten der Beeinflussung gibt es.
Zeitraum: September 2020
Name des Projekts: DOAG Expertenseminar ?Datenbank-Performance für Entwickler?
Lokation: DOAG (Deutsche Oracle Anwender Gruppe) GmbH, Berlin / remote
Branche: User Group / Schulung
Kurzbeschreibung:
Öffentliches Expertenseminar mit folgendem Inhalt:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um bestmöglichst mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
Instrumentierung
Trace / Row Source Statistics / Active Session History / Real Time SQL Monitoring
Grundlagen Optimizer, Histogramme, Statistiken (inkl. New Features 12c)
(serielle) Ausführungspläne richtig lesen
Indizierung
Clustering / Speicherformen inkl. New Features 12c: Attribute Clustering / Zonemaps, Heap, Index Organized Tables, Cluster
Hints
Bind Variablen / Literale und ungleichmäßige Datenverteilung
Zeitraum: August 2020
Name des Projekts: Oracle Database Workshop ?12c/18c/19c New Features?
Lokation: Frankfurt am Main / Remote
Branche: Bank
Kurzbeschreibung:
Individual Workshop über relevante neue Features der Oracle Datenbank aus Sicht von Datenbank-Entwicklern / Applikationen, die in den neuesten Versionen hinzugefügt wurden
Zeitraum: Juli 2020
Name des Projekts: Oracle Datenbank 19c Performance Troubleshooting (Exadata)
Lokation: Berlin / remote
Branche: Versandhandel
Kurzbeschreibung:
Nach dem Upgrade von Oracle 12.2.0.1 nach 19c (19.6) einer Data Warehouse Datenbank war die Performance signifikant schlechter. In Testumgebungen ist der Effekt zuvor so nicht aufgetreten. Es handelt sich um eine zwei Knoten RAC Datenbank als PDB auf Exadata (X7-2). Eine Analyse ergab folgende Punkte:
- Verschiedene RAC spezifische Bugs, die zu Hängern im Bereich der Cluster Waits (?gc?) geführt haben, bei denen SQL-Ausführungen zum Beispiel unendlich auf ?gc current request? gewartet haben. Als initialer Workaround wurde das ?read-mostly? RAC feature deaktiviert und nach Verfügbarkeit und Installation entsprechender One-Off Patches, die leider nicht Teil des eingesetzten RUs waren, traten die Hänger nicht mehr auf
- Ein anderer RAC spezifischer Bug, der zu regelmäßigen Crashes der Instanzen geführt hat, wurde auch durch Installation eines entsprechenden One-Off Patches behoben
- SmartScans funktionierten seit der Installation des Cell Firmware Upgrades nicht mehr, da alle Zellen im Database Level Quarantine Mode agierten aufgrund von drei Crashes innerhalb von drei Stunden. Die verursachende SQL-Operation wurde identifiziert und mittels der Analyse des Cell crash Trace Files wurde klar, dass das Problem mit dem Cell Columnar Flash Cache zusammenhängt. Als initialer Workaround wurde dieses Feature deaktiviert, was es erlaubt hat, die Database Level Quarantine zu entfernen ohne dass es zu weiteren Crashs auf Zellenebene kam. Oracle hatte den Bug in der Zwischenzeit auch identifiziert und in einer neueren Version der Firmware behoben, die dann auch installiert wurde.
- Inkrementelle Statistiken funktionierten nicht mehr nach dem 19c Upgrade, da 19c die von 12.2 generierten Synopsen nicht verarbeiten kann, weil ein PL/SQL Fehler in internen Paketen auftritt, was dazu führt, dass effektiv die globalen Statistiken immer neu berechnet wurden anstatt inkrementelle Statistiken zu verwenden. Bisher steht als Workaround nur zur Verfügung, die Synopsen komplett neu zu berechnen, was keine empfehlenswerte Operation bei einem Multi-Terabyte Data Warehouse ist
- Allgemein ist die Performance des RACs in Produktion maßgeblich beeinflusst von einer signifikanten Zunahme an Cluster bezogenen Warteereignissen, insbesondere beträgt die durchschnittliche Wartezeit 50 mal länger in Produktion (40 ms im Vergleich zu 800 ?s) als in Testumgebungen bei vergleichbarer Arbeitslast. Die Root Cause Analyse für dieses unterschiedliche Verhalten ist noch ausstehend zum Zeitpunkt des Schreibens
- Unabhängig vom Upgrade zeigten einige Tabellen sehr merkwürdiges Verhalten in Bezug auf SmartScan Performance und Platzbedarf, was zu sehr schlechter Performance führt ? mehr als 60 Sekunden für einen trivialen, parallelen SELECT COUNT(*) einer 20 GB Partition, der Millionen logische I/Os zusätzlich generiert und dadurch den CPU Verbrauch auf den Compute Nodes nach oben treibt, sowie einen signifikant erhöhten Platzbedarf ? anstatt 20 GB benötigt eine 1:1 Kopie der gleichen Daten mit gleicher Hybrid Columnar Compression (HCC) Kompressionsstufe nur ca. 400 MB, was 50mal weniger ist. Auch die SmartScan Performance auf dieser Kopie lag im erwarteten Bereich unter einer Sekunde. Block dumps zeigten leere HCC Compression Units und Chained Rows. Die derzeit verwendete Kombination aus HCC und Updates scheint die Daten in einem sehr ungünstigen Zustand zu hinterlassen, was Kompression, Chained Rows und Platzbedarf angeht
Zeitraum: Juni 2020
Name des Projekts: Oracle Datenbank Performance Troubleshooting
Lokation: Oberhaching / Remote
Branche: Software / Logistik
Kurzbeschreibung:
Eine Applikation zur Berechnung der optimalen Fahrtrouten von Paketauslieferungen zeigt immer wieder ?Hänger?, bei denen minutenlang Jobs und Abfragen in der Datenbank hängen bleiben, was signifikante Auswirkung auf die gesamte Applikation hat, da die zeitnahe Neuberechnung der Routeninformation gewährleistet sein muss. Dieses Verhalten ist seit einer Datenbereinigungsaktion zu beobachten, bei der Daten aus der Datenbank gelöscht wurden und von der man sich positive Effekte auf die Performance und den Platzbedarf versprochen hat. Die Analyse ergibt, dass es sich um Sperrungen auf der Ebene des sogenannten ?Library Caches? der Oracle Datenbank handelt ? der Cache, der vor allem dazu dient, alle verwendeten Objekte und deren Abhängigkeiten untereinander zu verwalten. Dazu muss man wissen, dass DDL Operationen exklusive Sperrungen auf Library Cache Ebene verursachen, als auch das Neuerstellen von Ausführungsplänen. Die erwähnte Applikation verwendet zum Teil partitionierte Tabellen ? wobei es sich um eine fragwürdige Verwendung davon handelt, da pro Tag fast 600 neue Partitionen erzeugt werden. Das führt auch dazu, dass tagsüber während hoher Aktivität auf dem System es zu ALTER TABLE DDLs kommt, die neue Partitionen anlegen und somit vorhandene SQLs im "Shared Pool" invalidieren. Damit kommt es regelmäßig zu ?Parse-Stürmen?, bei denen SQLs von vielen Sessions gleichzeitig ausgeführt werden, für diese SQLs aber erst wieder neue Ausführungspläne aufgrund der Invalidierung erzeugt werden müssen. In der Vergangenheit ist dies genauso geschehen, allerdings hat das Neuerstellen der Ausführungspläne nicht außergewöhnlich viel Zeit in Anspruch genommen, so dass die Auswirkung insgesamt vertretbar war. Seit der erwähnten Datenbereinigungsaktion verhielt sich der Optimizer aber anders, was dazu führte, dass die Erstellung des Ausführungsplans von SQLs, die die partitionierten Tabellen verwenden, extrem lange dauern kann ? bis zu mehreren Minuten ? und in dieser Zeit andere Sessions, die entweder auch das gleiche SQL versuchen auszuführen oder zu parsen, oder andere Sessions, die einen exklusiven Lock auf ?Library Cache? Ebene auf bestimmte Objekte benötigen, so lange warten müssen, bis für dieses SQL ein Ausführungsplan erstellt wurde. Dies führte zu teilweise extremen Wartesituationen. Ursache für die Verhaltensänderung war ein Feature der Datenbank, bei Einsatz von Parallel Execution beim Erstellen eines Ausführungsplans ?Dynamic Sampling? einzusetzen. Dieses ?Dynamic Sampling? kann bei partitionierten Tabellen eine IN Liste der zu samplenden Partitions-IDs bei Erzeugung der rekursiven Abfrage zur Ermittlung von Selektivitäten verwenden ? bei höheren Sampling-Leveln kann es hier bis 512 Partitionen aufzählen. Die Verhaltensänderung bestand darin, dass der Sampling Level sich von Level 7 auf Level 8 erhöht hat, da die Tabelle insgesamt ca. 65 Millionen Blöcke hat und dies genau die Grenze darstellt, um von Level 7 auf Level 8 bei der automatischen Anpassung des Leves zu gehen. Daher wurden seitdem eben 512 Partitionen aufgelistet anstatt wie bisher nur 256. Dies wiederum hatte zur Folge, dass der Optimizer in einen Bug gelaufen ist beim Erstellen des Ausführungsplans für die rekursive ?Dynamic Sampling? Abfrage (durch Verlängerung der IN Liste), was dann für die minutenlange Verzögerung bei der Erstellung des Ausführungsplans des eigentlich betroffenen SQLs verantwortlich war. Als Workaround wurde eine Kombination aus SQL Plan Baseline und SQL Patch für die SQLs eingeführt, die von dem Problem maßgeblich betroffen waren bzw. die die meiste Auswirkung auf das System hatten, indem sie andere SQLs blockierten. Die Aufgabe der SQL Plan Baseline war die Fixierung des derzeitigen Ausführungsplans, während die Aufgabe des SQL Patches die Deaktivierung von ?Dynamic Sampling? war. Damit trat der beschriebene Effekt für diese SQLs nicht mehr auf. Die generelle, datenbankweite Abschaltung des Features, das die automatische Erhöhung des ?Dynamic Sampling? Levels bewirkt, wurde evaluiert und wird eventuell eingesetzt, sollte sich das Verhalten auch noch auf andere SQLs auswirken, die mit den bereits etablierten Mitteln nicht behandelt werden können ? zum Beispiel SQL Texte, die Literale bzw. variabel lange IN Listen verwenden. Dazu wurde auch evaluiert, in welchem Maße sich die Verwendung von ?Dynamic Sampling? überhaupt derzeit positiv auf die Ausführungspläne auswirkt, um das mögliche Risiko bei Abschalten des Features besser einschätzen zu können.
Zeitraum: Mai 2020
Name des Projekts: Oracle Datenbank Performance Workshop
Lokation: Darmstadt / Remote
Branche: Software
Kurzbeschreibung:
Individual Workshop zu Oracle Datenbank Performance Themen, insbesondere Locking, Parallelisierung, Indizierung, Analysemöglichkeiten innerhalb der Datenbank
Zeitraum: Mai 2020
Name des Projekts: Exadata Workshop
Lokation: Merzig / remote
Branche: Pharma
Kurzbeschreibung:
Ausführliche Beschreibung. Demonstration und Diskussion der Oracle Exadata Database Machine in Form eines individuellen Workshops ? Aufbau, Features (Storage Cells, Smart Scans, Flash Cache, Persistent Memory, RoCE, Hybrid Columnar Compression etc.), wann profitiert man von den speziellen Exadata Features, Analyse des Istzustands und Bewertung in Bezug auf Nutzungsmöglichkeiten / mögliche Vorteile eines Umstiegs auf Exadata sowie mögliche notwendige Anpassungen der derzeitig etablierten Prozesse (Backup, High Availability etc.) als auch Migrationsstrategien.
Zeitraum: April 2020
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Frankfurt am Main / remote
Branche: Bank
Kurzbeschreibung:
Eine Applikation (Batch Verarbeitung) wird in Produktion immer langsamer ? nach Migration auf ein neues System vor einiger Zeit waren es noch wenige Stunden, aktuell sind es für einen Verarbeitungslauf über 12 Stunden.
Eine detaillierte Analyse zeigt, dass die Applikation zwei ungünstige Ansätze kombiniert: Die häufige Ausführung von Einzel-SQLs und dabei die Verwendung von Literalen anstatt Platzhaltern / Bind Variablen. Da noch die Version 12.1.0.2 ohne deaktivierte adaptive Optimizer Features zum Einsatz kommt, werden bei der Erstellung von Ausführungsplänen sehr viele SQL Plan Directives angewendet, die zu sehr viel rekursiven Dynamic Statistics / Sampling Abfragen führen. Im Endergebnis verbringt die Datenbank mehr als 95% der Datenbankzeit mit Parse / Erstellung von Ausführungsplänen, und weniger als 5% der Datenbankzeit mit der eigentlichen SQL-Ausführung.
Als mögliche Abhilfe bietet sich die Einstellung CURSOR_SHARING=FORCE an, um die Literale automatisch von der Datenbank durch Bind Variablen ersetzen zu lassen und damit das permanente Neuerstellen von Ausführungsplänen zu unterbinden. Nachdem Bugs bei der Parametrisierung überwunden wurden (Parametereinstellung für CURSOR_SHARING=FORCE auf CDB-Ebene wird nicht auf PDB-Ebene angewendet) sinkt die Laufzeit von über 12 Stunden auf 12 Minuten (!) bei Einsatz von CURSOR_SHARING=FORCE.
Zeitraum: April 2020
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Frankfurt am Main / remote
Branche: Bank
Kurzbeschreibung:
Der Umzug einer bestehenden Datenbank auf neue Hardware bedingt durch einen Wechsel des Betriebssystems von RHEL 6 nach RHEL 7 zeigt deutlich schlechtere Laufzeiten als in der bisherigen Umgebung, obwohl laut Provider gleiche Ressourcen zur Verfügung stehen in Hinblick auf CPU, Speicher und Storage. Da es sich auf dem neuen System um eine Binärkopie der Datenbank mit identischer Parametrisierung handelt, kann man Einflüsse durch Unterschiede im Bereich der Parametrisierung, physischen Speicherung der Daten und Statistiken ausschließen. Ein detaillierter Vergleich von Verarbeitungen auf Ausführungsplanebene zwischen den beiden Umgebungen alt und neu zeigt, dass bei gleicher zu verarbeitender Datenmenge und identischem Ausführungsplan ein signifikanter Unterschied im I/O Bereich besteht ? das neue System ist nachweislich deutlich langsamer bei den I/O Operationen, die von der Datenbank ausgeführt werden.
Eine genauere Untersuchung der Konfiguration auf Betriebssystem-Ebene zeigt, dass das neue System ?vxfs? (Symantec Veritas Filesystem) für die Datenbank-Filesysteme verwendet, im Gegensatz zum alten System, das ?ext4? verwendet. Eine detaillierte Auswertung mittels ?iostat? zeigt eine durchgängige Auslastung nahe 100% der entsprechenden Devices.
Ein testweiser Einsatz des von Symantec empfohlenen ?ODM? (Oracle Disk Manager) Moduls zeigt noch schlechtere I/O Performance. Um ?vxfs? als Problemverursacher auszuschließen, wird empfohlen ebenfalls ?ext4? in der neuen Umgebung als Filesystem einzusetzen.
Nach Umstellung in der neuen Umgebung auf ?ext4? ist die Performance der Testläufe vergleichbar, in Teilen sogar besser als in der alten Umgebung ? die Verwendung von ?vxfs? hat sich in dieser Umgebung also nachweislich negativ auf die I/O Performance der Datenbank ausgewirkt.
Zeitraum: März 2020
Name des Projekts: Performance Workshop Oracle 12.2
Lokation: Merzig / remote
Branche: Pharma
Kurzbeschreibung:
Online Workshop zur Klärung verschiedener Performance relevanter Fragen, wie zum Beispiel das Handling einer sehr volatilen Tabelle, die über Tag signifikant den Inhalt ändert, insbesondere die Datenverteilung verschiedener Status-Indikatoren, die am Ende des Tages alle im Status ?verarbeitet? sind, aber tagsüber sich in verschiedenen Phasen der Datenverteilung befinden. Wie und wann sollen die Statistiken idealerweise erzeugt werden, um dem Oracle Optimizer zu ermöglichen, gute Abschätzungen für die kritischen Abfragen auf solchen Tabellen zu machen und damit effiziente Ausführungspläne zu erzeugen. Weitere Fragen zum Umgehen mit SQL Plan Baselines und SQL Profiles ? gibt es im Detail Unterschiede, insbesondere bei der Verwendung von Virtual Private Database (VPD) / Row Level Security (RLS) / Fine Grained Access Control (FGAC). Unterschiede beim Erzeugen von Statistiken bei der Behandlung von laut Statistik nicht existenten Werten ? Bucket Size von Histogrammen und Estimate_Percent / Verwendung des mit Oracle 11g eingeführten ?Approximate NDV? Algorithmus können hier große Unterschiede erzeugen, da die neuen Top Frequency Histogramme solche Fälle anders handhaben bezüglich der Abschätzungen des Optimizers.
Zeitraum: Juni 2019 - März 2020
Name des Projekts: Datawarehouse Performance Beratung
Lokation: Wiesbaden
Branche: Versicherung / Software
Kurzbeschreibung:
Die neue Generation eines DWHs verwendet eine doppelt temporale Speicherung der Daten (technische und fachliche Gültigkeiten). Durch diese hohe Komplexität ergeben sich große Herausforderungen, die Daten in angemessener Zeit zu verarbeiten, da die Umsetzung der Anforderungen zur temporären Vervielfachung der Datenmenge führt, sowie relativ komplexes SQL erfordert, das ungünstig für eine relationale Datenbank zu verarbeiten ist. Erster Schritt der Analyse besteht darin, die Verarbeitung auf SQL-Ebene im Detail zu analysieren, um aufzuzeigen, welche Verarbeitungsschritte besonders kostspielig sind und welche Laufzeiten überhaupt realistisch auf der gegebenen Hardware möglich sind bzw. welche Hardwareausstattung notwendig sein könnte, um die gewünschte Verarbeitungsgeschwindigkeit zu erreichen.
Zeitraum: Januar 2020
Name des Projekts: Performance Analyse Applikation Upgrade Oracle 12cR2
Lokation: Stuttgart
Branche: Bank
Kurzbeschreibung:
Performance Analyse der Datenbank-Aktivitäten einer komplexen Auswertungslogik implementiert in PL/SQL nach Upgrade auf Oracle 12cR2. Der Code ist über die Zeit gewachsen, nicht für die jetzt zu verarbeitende Datenmenge entworfen und verwendet komplexes ?Row by Row? Processing in PL/SQL mit rekursiven Abfragen, die teilweise pro Zeile ausgeführt werden und ist daher nur sehr begrenzt skalierbar. Außerdem leiden die Ausführungspläne einiger rekursiver Abfragen an den bekannten Problemen verursacht durch ?Bind Variable Peeking? und dadurch Verwendung ungünstiger Ausführungspläne. Durch Erzeugung einiger geeigneter Indizes und Verwendung entsprechender Hints kann die Verarbeitungszeit von über 30 Minuten auch für die größten Auswertungen auf unter 10 Minuten reduziert werden, so dass jetzt alle Auswertungen erfolgreich zu Ende laufen und nicht länger als die Timeout-Grenze von 30 Minuten benötigen.
Zeitraum: November - Dezember 2019
Name des Projekts: Vortrag auf DOAG 2019 und IT Tage 2019 Konferenzen
Lokation: Nürnberg / Frankfurt
Branche: Konferenzen
Kurzbeschreibung:
Vortrag ?Oracle Database Indexing Best Practices? in Nürnberg auf der DOAG Konferenz 2018 sowie den IT Tagen 2018 in Frankfurt
Zeitraum: November - Dezember 2019
Name des Projekts: Datawarehouse Performance Beratung
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
Berichtserstellungen in einem DWH benötigen mehrere Minuten Laufzeit. Verwendet wird ein Snowflake Schema. Als Hardware kommt eine virtualisierte AIX-Umgebung zum Einsatz. Auffällig ist die sehr hohe CPU-Zeit, die in Hash Joins verbracht wird und relativ langsamer I/O, insbesondere beim Zugriff auf TEMP. Die allgemeine Konfiguration der Datenbank ist optimierbar ? sowohl SGA, aber auch PGA sind zu klein konfiguriert ? desweiteren stehen nur geringe CPU-Kapazitäten garantiert zur Verfügung, daher arbeitet das System häufig CPU gebunden. Es wird kein Concurrent I/O eingesetzt, was zu hoher Kernel-Zeit auf O/S Seite und vor allem geringen I/O Durchsätzen führt. Eine Umstellung auf Concurrent I/O erhöht den I/O Durchsatz um den Faktor 6 bis 10 ? die Auswirkungen des Verlusts des Filesystem Caches muss beobachtet und die SGA entsprechend angepasst werden. Die SMT-Fähigkeiten und die geringere Single-Thread Performance wird durch moderate Parallelausführung versucht auszugleichen. Berichte werden mit einem Teil der Maßnahmen in ca. 30 Sekunden ausgeführt.
Zeitraum: September 2019
Name des Projekts: Performance Troubleshooting Oracle 12c (Exadata)
Lokation: Frankfurt
Branche: Software
Kurzbeschreibung:
Berichte über ?Tableau? laufen sehr lange (bis zu fünf Minuten pro Abfrage), obwohl eigens dafür Materialized Views aufbereitet werden. Ziel ist eigentlich, Berichte innerhalb weniger Sekunden erzeugen zu können.
Eine Analyse ergibt, dass das Problem im Zusammenspiel der Aktualisierung der Materialized Views mit den speziellen Eigenschaften der Exadata liegt ? die Aktualisierung dauert sehr lange (bis zu zwei Stunden und alle zwei Stunden findet eine erneute Aktualisierung statt), und diese findet auf konventionellem Weg (Full Refresh ?Atomic?), so dass zuerst per DELETE alle Zeilen aus dem Materialized View entfernt und dann per konventionellem INSERT wieder geschrieben werden. In dieser Zeit kann der Smart Scan der Exadata die gelesenen Blöcke nur an die Compute Nodes zurückliefern, da für alle Zeilen Informationen aus dem Undo-Bereich der Datenbank gelesen werden müssen.
Ein Test der neuen ?Out-Of-Place? Refresh Option ergibt weiterhin Laufzeitprobleme durch unerwartete Transformationen der dem Materialized View zugrunde liegenden Abfrage und Fehler aufgrund von Restriktionen der Option (unter anderem werden keine LOB-Spalten unterstützt).
Daher wird die Idee mittels einer Proof-Of-Concept Implementierung aufgezeigt, eine eigene Umsetzung eines funktionierenden und performanten ?Out-Of-Place? Refreshs zu realisieren, bei der ein sinnvoller Ausführungsplan beim Full Refresh zum Einsatz kommt und außerdem LOB-Spalten unterstützt werden.
Die generische Implementierung basiert darauf, eine zweite, ?dummy?-partitionierte Tabelle strukturgleich zu der Basistabelle des Materialized Views anzulegen, diese basierend auf der Materialized View Abfrage zu befüllen und abschließend per Exchange Partition Operation mit der Basistabelle auszutauschen.
Dies funktioniert in ersten Tests sehr gut ? die Aktualisierung dauert nur 10 Minuten anstatt über eine Stunde - inklusive Erneuerung der Statistiken - und die Berichte sind in dieser Zeit weiterhin schnell innerhalb weniger Sekunden erzeugt, da die Smart Scans auf der Basistabelle des Materialized Views wie gewünscht funktionieren.
Zeitraum: August 2019
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
Eine DWH-Anwendung ermittelt derzeit die globalen Statistiken auf für die eingesetzte Hardware großen, partitionierten Tabellen (mehrere Terabyte) nur für indizierte Spalten (FOR ALL INDEXED COLUMNS), was aufgrund der fehlenden Spaltenstatistiken für die Mehrzahl der Spalten zu signifikanten Fehlabschätzungen des Optimizers beim Erstellen von Ausführungsplänen führen kann. Eine testweise Umstellung auf ?FOR ALL COLUMNS SIZE AUTO? führt zu extrem langen Laufzeiten. Eine genauere Analyse zeigt auf, dass die Datenbank ein fragwürdiges Verhalten beim Erstellen von Histogrammen an den Tag legt ? im Spezialfall von Spalten, die nur eine Ausprägung und fast nur NULL-Werte haben, wird eine unnötige, separate Abfrage über die gesamte Tabelle ausgeführt, um das Histogramm zu ermitteln. Dies ist in mehrerer Hinsicht unnötig, da erstens auf einer solchen Spalte kein Histogramm erzeugt werden sollte, da es keinen Mehrwert an Information bietet und zweitens die Hauptabfrage zur Ermittlung der Statistiken seit Oracle12c bereits alle benötigten Informationen einsammelt, die separate Abfrage also nicht notwendig ist. Da es sich um Oracle 12.1 handelt, wird derzeit die Option, inkrementelle Statistiken für die Ermittlung der globalen Statistiken zu verwenden, aufgrund der vielen Bugs dieses Features nicht in Betracht gezogen. Durch Setzen passender METHOD_OPT-Präferenzen mittels DBMS_STATS.SET_TABLE_PREFS zum Verhindern der unnötigen Histogrammerstellung der betroffenen Spalten (eine Ausprägung, überwiegend NULLs) kann die Laufzeit der globalen Statistiken auf ein vertretbares Maß reduziert werden. Bei Oracle ist ein Bug in Bearbeitung bezüglich des fragwürdigen Verhaltens, das auch noch in der aktuellsten Version (19c) reproduziert werden kann.
Zeitraum: Juli 2019
Name des Projekts: Workshop ?Den kostenbasierten Optimizer verstehen?
Lokation: Ulm
Branche: Software / Healthcare
Kurzbeschreibung:
Durchführung meines mehrtägigen Workshops ?Den kostenbasierten Optimizer verstehen? mit individueller Anpassung auf Kundenwünsche und -fragen.
Zeitraum: Juli 2019
Name des Projekts: Workshop ?Exadata für Anwendungsentwickler?
Lokation: Stuttgart
Branche: Bank
Kurzbeschreibung:
Durchführung meines mehrtägigen Workshops ?Exadata für Anwendungsentwickler?.
Zeitraum: Mai 2019
Name des Projekts: Datenbank Performance Review
Lokation: Breslau, Polen
Branche: Software
Kurzbeschreibung:
Review einer bestehenden Cloud-Applikation mit Oracle-Datenbank als Backend. Nach Migration zu einem neuen Storage mit Verschlüsselung wird langsameres I/O beobachtet. Detailanalyse des I/Os auf Betriebssystem Ebene mittels iostat, Kernel Stack Profiling und ?blktrace?, um andere Seiteneffekte auszuschließen. Überprüfung der verwendeten Parameter zur Statistikerstellung in der Datenbank und Empfehlungen für Verbesserungen, unter anderem Data Dictionary Statistiken regelmäßig zu aktualisieren. Top SQLs im Detail analysiert mit Vorschlägen, wie CPU und I/O durch optimierte Indizierung eingespart werden kann. Analyse mittels Active Session History, welche Appliationsteile am meisten CPU auf der Datenbank verbrauchen, um Einsparungspotentiale in Bezug auf Lizenzen einschätzen zu können. Weiteres Optimierungspotential aufgezeigt, unter anderem Abschalten des Space Advisor Tasks.
Zeitraum: April 2019
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
Eine Batchverarbeitung zur Maskierung von Daten nach dem Klonen von Produktionsdaten in andere Umgebungen läuft fast 24 Stunden. Ein Großteil der Verarbeitungszeit wird damit verbracht, Partitionen von Tabellen vor dem eigentlichen Maskieren zu dekomprimieren, da die Tabellen mit BASIC Compression komprimiert sind, und nach dem Update wieder zu komprimieren / Indizes neu zu erstellen etc.
Es wird nach Wegen gesucht, wie die Maskierung beschleunigt werden kann. Es werden hier zwei Ansätze verfolgt: Erstens wird die aktuelle Implementierung signifikant beschleunigt, da über 60% der Verarbeitungszeit mit zwei Tabellen verbracht wird, und diese haben mehr als 254 Spalten. Obwohl eigentlich mit Oracle 12c die Komprimierung von Tabellen mit mehr 254 Spalten mittels Basic/Advanced Compression möglich sein soll, ist dies aufgrund eines Bugs in der Version 12.1.0.2 mit aktuellen PSUs nur noch unter bestimmten Umständen möglich. Daher sind diese Tabellen derzeit effektiv nicht komprimiert und die aufwändigen Vor- und Nachverarbeitungsschritte können eingespart werden. Somit kann die Laufzeit um ca. 12 Stunden reduziert werden. Zweitens wird eine alternative Implementierung der Maskierung eingeführt, die die Maskierung per CTAS Operation durchführt. Mittels dieser Implementierung wird die Tabellenkopie gleich komprimiert angelegt und der Dekomprimierungs- und Updateschritt kann eingespart werden. Sobald auf eine neuere Version von Oracle aktualisiert wird, die die Komprimierung der breiten Tabellen erlaubt (ab 12.2 wieder möglich), kommt dann diese neue Implementierung zum Einsatz, die ca. 40% - 50% der derzeitigen Laufzeit einsparen können sollte.
Zeitraum: Februar - März 2019
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
Eine batchorientierte Massendaten-Verarbeitung in einer Produktionsumgebung zeigt stark schwankende, aber auch trendweise steigende Laufzeiten. In einer weiteren Umgebung mit praktisch identischem Datenbestand, identischer Hardware-Konfiguration bezüglich CPU und RAM, aber nominell langsameren Storage werden bessere Laufzeiten erreicht. Eine Analyse zeigt, dass die CPU-Performance auf der Produktionsumgebung um bis zu zehn Prozent schwankt und vor allem die Performance des Log Writers einen signifikanten Flaschenhals darstellt (da die Datenbank im FORCE LOGGING-Modus betrieben wird und viele Direct Path-Operationen wie INSERT APPEND und CREATE TABLE AS SELECT verwendet werden) ? insbesondere ist der Schreibdurchsatz des Log Writers deutlich schlechter in Produktion als in der Vergleichsumgebung. Eine genauere Analyse zeigt, dass für den Log Writer nur eine LUN verwendet wird, die auch noch in ein anderes Rechenzentrum gespiegelt ist und daher unter längeren Latenzen leidet. Nach Umkonfiguration und Verwendung mehrerer LUNs für den Log Writer ist ein deutlich höherer Schreibdurchsatz des Log Writers und eine signifikante Laufzeitverbesserung für einige der Batchläufe messbar. Darüber hinaus wurden verschiedene Ineffizienzen bei der Verarbeitung durch die Applikation herausgearbeitet und entsprechende Verbesserungsvorschläge mit dem Hersteller diskutiert (Effizientere Ausführungspläne, weniger gegenseitiges Sperren etc.)
Zeitraum: Januar - März 2019
Name des Projekts: Performance Analyse ECommerce Applikation
Lokation: Düsseldorf
Branche: Fashion, Versandhandel
Kurzbeschreibung:
Umfassende Analyse der Infrastruktur, AIX Datenbankserver, Storage (NetApp), Netzwerk und Applikation. Allein durch korrekte Konfiguration und sinnvolle Nutzung der vorhandenen Ressourcen konnte die Anzahl der physischen I/O Anfragen auf Datenbankebene um 90% und die Datenbank-Zeit um 70% reduziert werden. Die Laufzeit einer kritischen Nachtverarbeitung reduzierte sich dadurch von 9 auf unter 6 Stunden. Die Analyse konnte auch Engpässe sowohl im CPU-Bereich des Datenbank-Servers als auch bei der Konfiguration der Datenbank im Bereich von AIX Concurrent I/O aufzeigen. Weitere Analysen auf Applikationsebene folgen ? im Bereich Indizierung, insbesondere von XML, Caching von LOBs, Transaktionsrate und Optimierung von SQLs.
Zeitraum: Dezember 2018
Name des Projekts: Vortrag auf DOAG 2018 und IT Tage 2018 Konferenzen
Lokation: Nürnberg / Frankfurt
Branche: Konferenzen
Kurzbeschreibung:
- Vortrag ?Oracle Optimizer System Statistiken Update 2018? in Nürnberg auf der DOAG Konferenz 2018 sowie den IT Tagen 2018 in Frankfurt
Zeitraum: Oktober - November 2018
Name des Projekts: Performance Analyse Applikation Upgrade Oracle 12cR2
Lokation: Stuttgart
Branche: Bank
Kurzbeschreibung:
- Performance Analyse der Datenbank-Aktivitäten einer komplexen Java Spring Batch Applikation nach Upgrade auf Oracle 12cR2, Verwendung des aktuellen Optimizers (OPTIMIZER_FEATURES_ENABLE = 12.2.0.1) und Abschalten von SQL Plan Baselines (stammen noch vom Upgrade auf Oracle 11.2). Ein Langläufer wird durch die Art und Weise, wie Statistiken während einer BatchVerarbeitung erzeugt werden, verursacht. Dabei verhält sich Oracle fragwürdig, da das Fehlen / Erzeugen von globalen Statistiken bestimmte Mengenabschätzungen (Aggregationsschritt GROUP BY) beeinflusst, obwohl hier ganz klar ansonsten auf Einzel-Partitionsebene gearbeitet wird und diese Statistiken auf Partitionsebene relevant sein sollten. Durch Anpassung der Statistikerzeugung auf globaler Ebene kann der Langläufer vermieden werden.
- Weitere Überprüfung und allgemeine Beratung bezüglich der neu aufgesetzten 12cR2 Umgebungen
Zeitraum: Oktober 2018
Name des Projekts: Data Warehouse Upgrade 18c Troubleshooting (Exadata)
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
- Performancetests einer komplexen Data Warehouse Applikation nach Upgrade auf 18c auf Exadata. Es werden verschiedene Regressionen beobachtet. Diese beruhen auf unterschiedlichen Effekten:
- Parallele Ausführungen von Pipelined Table Functions unter der Verwendung von Object Views und abgeleiteten Objekttypen führt zu extremer Latch Contention unter 18c => neuer Bug, der von Oracle gefixt wurde.
- Langlaufende Statistik-Erzeugung als Teil der ETL Verarbeitung. Offensichtlich wird die ?STALENESS? von Objekten seit Oracle 12.2 / 18c anders gehandhabt als in 12.1 und früher. Durch die Verwendung des internen Pakets DBMS_STATS_INTERNAL und dessen Funktion IS_STALE als Teil der entsprechenden Views werden in 18c Objekte als STALE markiert / angezeigt, die in vorherigen Versionen nicht als STALE auftauchen (FLAGS werden unterschiedlich interpretiert). Dies betrifft vor allem auch ältere Partitionen / Tabellen, die schon seit sehr langer Zeit nicht mehr verändert wurden. Dies wird gerade mit Oracle Support abgeklärt und die passende Vorgehensweise besprochen.
Zeitraum: September 2018
Name des Projekts: Data Warehouse ETL Performance Troubleshooting (Exadata)
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
- Ein kritischer Transformationsschritt innerhalb einer Data Warehouse Applikation benötigt nach einer strukturellen Änderung mehr als eine Stunde, teilweise mehrere Stunden. Eine Analyse ergibt, dass der Ausführungsplan durch Fehlabschätzungen ineffizient ist. Außerdem treten hier verschiedene Bugs der Oracle-Software zu Tage. Zum Einen führt der Einsatz von Dynamic Sampling auf Statement-Ebene zu komplett falschen Mengenabschätzungen, zum Anderen tritt je nach Strukturierung des Statements mittels NO_MERGE-Hints ?Invalid Number?-Fehler auf, die mit der Evaluierung von PL/SQL-Funktionen zusammenhängen. Durch gezielten Einsatz von Dynamic Sampling auf Tabellenebene zur Verbesserung der Mengenabschätzungen, Restrukturierung mittels geeigneter NO_MERGE-Hints und Optimierung der Datenverteilung bei Parallelverarbeitung kann die Laufzeit auf 90 Sekunden verringert werden.
Zeitraum: August 2018
Name des Projekts: "Exadata für Anwendungsentwickler" Workshop
Lokation: Wien, Österreich
Branche: Software
Kurzbeschreibung:
- Schulung der Datenbank-Entwickler bezüglich der speziellen und für Anwendungsentwickler relevanten Eigenschaften der Oracle Exadata Database Machine: Offloading / Smart Scan Einführung und Vertiefung / Details, Flash Cache, Hybrid Columnar Compression. Analyse des Aktivitätsprofils der Applikationen in Bezug auf inwieweit von Exadata Features profitiert werden kann bzw. wo die Anwendung diesbezüglich angepasst werden sollte.
Zeitraum: Juli 2018
Name des Projekts: Application Architectural Review
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
- Unterstützung beim Review einer bestehenden Applikation zur Entscheidungsfindung bezüglich einer möglichen Weiterentwicklung und erweiterten Verwendungszwecks
Zeitraum: Juli 2018
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
- Die Laufzeit für Testläufe in einer Testumgebung dauern signifikant länger als vergleichbare Läufen in Produktion bei ähnlicher Datenmenge und -verteilung. Auch wenn längere Laufzeiten aufgrund unterschiedlicher Hardware erwartet werden, sind die Unterschiede deutlich größer als erwartet. Bei näherer Betrachtung sind mehrere Unterschiede in der Konfiguration der Testumgebung festzustellen:
- Der Buffer Cache wurde von Oracle aufgrund der Verwendung von MEMORY_TARGET (Sparc Solaris) und keinerlei Festlegung von Untergrenzen sehr klein konfiguriert, desweiteren steht noch mehr Speicher zur Verfügung
- Die ZFS ARC Konfiguration ist fraglich (Cache Größe fix auf 10 GB begrenzt)
- Die Parallelisierungsoptionen in der Applikation verwenden nur die Hälfte an Ressourcen verglichen mit Produktion, obwohl ausreichend Kapazität vorhanden ist
Empfehlung, diese fraglichen Konfigurationen anzupassen, also SGA vergrößern, Buffer Cache Untergrenze festlegen, ZFS ARC Cache-Einstellungen korrigieren und Parallelisierung nach oben anpassen
Zeitraum: Juni 2018
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Vilnius, Litauen
Branche: Bank
Kurzbeschreibung:
- Die Performance einer gekauften Software ist nicht adäquat bei der vom Kunden angedachten Datenmenge. Auf einer Testumgebung laufen einige Abfragen, auf die Endbenutzer warten müssen, für mehrere Minuten. Durch die Optimierung der Indizierung reduziert sich die Laufzeit dieser Abfragen auf zwei bis acht Sekunden, allerdings werden diese teilweise mehrfach ausgeführt, bis die Anzeige für den Endbenutzer aktualisiert ist. Weitere Optimierungen sind nur durch Applikationsänderungen und Umschreiben der SQLs möglich. Entsprechend detailliertes Feedback an Vendor mit konkreten Änderungsvorschlägen wurde erstellt.
Zeitraum: Juni 2018
Name des Projekts: Vortrag DOAG 2018 Exa & Middleware Days Konferenz
Lokation: DOAG Frankfurt
Branche: Anwendergruppe
Kurzbeschreibung:
- Vortrag ?Exadata & InMemory Real World Performance? in Frankfurt auf den DOAG 2018 Exa & Middleware Days.
Zeitraum: Mai 2018
Name des Projekts: Performance Troubleshooting Oracle 12c
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Performance-Probleme und Abbrüche durch nicht ausreichenden TEMP-Space einer selbstentwickelten Applikationserweiterung können leicht auf das fehlende Statistik-Management zurückgeführt werden. Tabellen werden dynamisch erzeugt und per Batch befüllt ? allerdings werden die Statistiken nur im ersten Schritt von Oracle 12c automatisch erzeugt, aber in weiteren Schritten mehr Daten hinzugefügt, ohne dass die Statistiken aktualisiert werden. Dies führt dazu, dass die im ersten Schritt erzeugten Statistiken nicht mehr repräsentativ für die Daten sind. Durch Aktualisierung der Statistiken zum richtigen Zeitpunkt sinkt die Laufzeit wieder auf wenige Sekunden und es gibt keine Abbrüche mehr.
Zeitraum: April 2018
Name des Projekts: "Oracle Entwickler Training" Workshop (Exadata)
Kunde: myToys.de, Berlin
Branche: Versandhandel
Kurzbeschreibung:
- Schulung der Datenbank-Entwickler bezüglich verschiedener Themen: Schulung der Datenbank-Entwickler bezüglich verschiedener Themen: Parallel Execution Skew, Exadata Besonderheiten, Optimizer und Partitionen, Statistiken.
Zeitraum: April 2018
Name des Projekts: Performance Troubleshooting
Kunde: State Street, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Optimierung eines weiteren Applikations-Workflows. Durch Anlage / Veränderung passender Indizes kann die Antwortzeit einer GUI für typische Benutzeraktivitäten von sehr langsam (mehr als 20 Sekunden, teilweise mehr als eine Minute) auf gut benutzbar (ein bis drei Sekunden) verbessert werden.
Zeitraum: Januar-März 2018
Name des Projekts: Performance Troubleshooting Oracle 12c (Exadata)
Kunde: d-fine, Frankfurt
Branche: Software
Kurzbeschreibung:
- Eine neu entwickelte Applikation zeigte für verschiedene Applikationsteile unerwartet schlechte Laufzeiten für Abfragen. Eine Analyse zeigte verschiedene Problemfelder auf:
- Das Statistikmanagement war unklar, unterschiedliche Jobs, die zum Teil auch noch überlappend liefen. Diese Jobs kamen aber nie zu Ende, da durch einen Bug mit Inkrementellen Statistiken eine rekursive Abfrage auf Metadaten nicht zu Ende lief, daher waren auf vielen Tabellen Statistiken veraltet
- Fragwürdiges Partitionierungskonzept. Zu viele und zu kleine bzw. zu unterschiedlich große Partitionen. Diese Partitionen waren auch noch mit HCC komprimiert. Dadurch wurde kein Smart Scan aktiviert, zusätzlich war der konventionelle Scan durch die Komprimierung sehr langsam. Desweiteren merkwürdiges Verhalten mit extremen Overhead bei Full Scans durch die hohe Anzahl an Partitionen
- Schlechte Mengenabschätzungen des Optimizers verursacht durch temporales Design und entsprechender komplexer Filterprädikate
- Zeitweise Sperrungen auf Library Cache Level durch Mischung von häufigem DDL und DML
- Stark schwankende Smart Scan Performance durch temporäre Überlast auf dem Exadata Host.
Für jedes Problemfeld wurden Lösungen / Verbesserungen vorgeschlagen und diskutiert. Das Statistikmanagement wurde aufgeräumt und Inkrementelle Statistiken deaktiviert, eine alternatives Partitionskonzept besprochen, das auch das Library Cache Lock-Problem lösen sollte und für komplexe Ausdrücke, die nicht durch erweiterte Statistiken abgedeckt werden können wurde die Verwendung von Dynamic Sampling vorgeschlagen. Die DBAs / System Administratoren konnten mit Hilfe der zur Verfügung gestellten Analyseergebnisse auch die Ursache für die temporäre Überlastung des Exadata Host Systems identifizieren.
Zeitraum: Februar 2018
Name des Projekts: "Oracle Entwickler Training" Workshop (Exadata)
Kunde: myToys.de, Berlin
Branche: Versandhandel
Kurzbeschreibung:
- Schulung der Datenbank-Entwickler bezüglich verschiedener Themen: Oracle Optimizer-Grundlagen, Parallelverarbeitung, Verständnis für Ausführungspläne, Besonderheiten von parallelen Ausführungsplänen, Laufzeit-Analyse von SQL-Ausführungen.
Zeitraum: Januar 2018
Name des Projekts: Performance Troubleshooting Oracle 12c
Kunde: VWFS, Braunschweig
Branche: Bank
Kurzbeschreibung:
- Eine Standardsoftware führte parallelisierte und batchbasierte Berechnungen deutlich langsamer durch als erwartet. Abgesehen von einigen kritischen Abfragen, für die recht einfach ein wesentlich effizienter Ausführungsplan gefunden werden konnte, war der Hauptdiskussionspunkt die I/O Performance, die von der Datenbank während der Berechnungen gemeldet wurde, die verglichen mit anderen Datenbanken, die den gleichen Storage verwenden und I/O Kalibrierungsergebnissen fragwürdig niedrig waren.
Durch Verwendung selbst entwickelter I/O Benchmark Skripte, die es erlauben, spezifische I/O-Muster auf der Datenbank zu erzeugen (single / multi-block synchronous / asynchronous), konnte gezeigt werden, dass bei Verwendung von Shared Server-Verbindungen die Datenbank asynchrones I/O nicht zum Einsatz bringt ? was dazu führt, dass bei dem von der Applikationsarchitektur vorgegebenen Parallelisierungsgrad die verfügbare IOPS-Rate nicht ausgenutzt wurde. Die Entscheidung, Shared anstatt Dedicated Server zu verwenden wurde in der Vergangenheit getroffen, als ein anderer Applikationsteil unter langsamem Verbindungsaufbau bei Verwendung von Dedicated Servern litt.
Bei Verwendung von Dedicated Servern verwendeten die Prozesse der Batchverarbeitung asynchrones I/O und Abfragelaufzeiten konnten dadurch um mehrere Faktoren reduziert werden, zum Beispiel von über 25 Minuten auf unter 5 Minuten.
Mehrere Jahre Erfahrung im Bereich Consulting/Schulung/Entwicklung/Administration
Schwerpunkt: Oracle Database Performance Troubleshooting + Tuning, Proactive Database Design for Performance
Deutschland: Für längerfristige Einsätze vor Ort bevorzugt Bereich D6, Remote und kurzfristige Einsätze: beliebiger Einsatzort
Öffentliches Expertenseminar mit folgendem
Inhalt:
In diesem Seminar werden die wichtigsten Themen
bezüglich Indizierung mit B*Tree und Bitmap Indizes in der Oracle-Datenbank
behandelt ? Text / XML / JSON / Domain-Indizes werden zwar je nach verfügbarer
Zeit erwähnt und beschrieben, aber es wird nicht ausführlich darauf eingegangen
? der Schwerpunkt liegt eindeutig auf den B*Tree / Bitmap Indizes:
- Grundlagen: Wie ist ein B*Tree-Index aufgebaut, wie ein Bitmap-Index und welche Konsequenzen ergeben sich daraus? Wie verändert sich ein Index bei DML-Operationen und was ergibt sich daraus?
- Index Access, Filter und Clustering von Daten: Welche Operationen sind beim Index-Zugriff wann wie kostspielig? Warum wird der sogenannte Clustering Factor von Indizes häufig von der Datenbank falsch berechnet und was kann man dagegen machen? Warum kann ein Full Table Scan deutlich effizienter als ein Zugriff per Index sein? Indizes und der Optimizer - was wird bei der Kostenberechnung berücksichtigt, was nicht? OPTIMIZER_INDEX_COST_ADJ / OPTIMIZER_INDEX_CACHING, System Statistiken etc.
- Index Design: Auf was ist beim Design von Indizes zu achten? Was ist für die Reihenfolge von mehreren Ausdrücken in einem Index relevant? Wann ist ein Bitmap-Index sinnvoll? Was sind Function Based Indizes? Was sind virtuelle Spalten? Wie hängen diese Features zusammen und wann verwendet man welches dieser Features?
- Index Options: Invisible / Unusable / Virtual / Partial-Indizes. Primary Key / Unique / Deferred Constraints und Indizes.
- Index Compression: Wie funktioniert dieses Feature und was bringt es? Welche Auswirkungen gibt es? Unterschied zwischen Basic und Advanced Low / High Compression
- Indizes und DML: Was sind die Auswirkungen von Indizes bei DML-Operationen auf einer Tabelle? Typische Szenarien bei gleichzeitiger Veränderung von Tabellen und welche Maßnahmen hier helfen können - was sind die potentiellen Auswirkungen dieser Maßnahmen?
- Index Monitoring: Wie kann ich eine bestehende Applikation bezüglich der Indizierung überwachen und auf was ist dabei zu achten?
- Foreign Keys und Indizes: Wann sollten Foreign Keys indiziert sein, wann ist es nicht notwendig?
- Index Rebuild: Wann ist es sinnvoll, einen Index aktiv zu reorganisieren? Welche Möglichkeiten gibt es dafür und wie unterscheiden sie sich?Nach dem Installieren des Release Update 17 von 19c (RU 19.17) ist die gesamte Datenbank Performance sehr schlecht ? maßgeblich aufgrund sehr langsamen Transfer von Blöcken zwischen den RAC Instanzen ? anstatt durchschnittlich 400 µs pro übertragenem Block steigt dies auf fast 20.000 µs (!) an.
Eine Analyse zeigt, dass die LMS Hintergrund-Prozesse, die in RAC für die Übermittlung der Blöcke zuständig sind, fast permanent auf CPU Zeit verbringen, was vor der Installation des RUs nicht der Fall war. Ein CPU Profiling zeigt an, dass die Prozesse die gesamte Zeit beim Suchen im ?gcs resource table? verbringen, was darauf hinweist, dass etwas mit der Verwaltung dieser Tabelle im Speicher (Effiziente Aufteilung in ?Hash Buckets?) nicht stimmt ? es gab in der Vergangenheit schon ähnliche Bugs in dem Bereich. Nach Rücksprache mit Oracle Support und Einspielen entsprechender Bug Fixes ist das Problem gelöst.In diesem Seminar werden die wichtigsten Themen bezüglich Indizierung mit B*Tree und Bitmap Indizes in der Oracle Datenbank behandelt:
- Grundlagen: Wie ist ein B*Tree Index aufgebaut, wie ein Bitmap Index und welche Konsequenzen ergeben sich daraus? Wie verändert sich ein Index bei DML Operationen und was ergibt sich daraus?
- Index Access, Filter und Clustering von Daten: Welche Operationen sind beim Index-Zugriff wann wie kostspielig? Warum wird der sogenannte Clustering Factor von Indizes häufig falsch berechnet von der Datenbank und was kann man dagegen machen? Warum kann ein Full Table Scan deutlich effizienter als ein Zugriff per Index sein? Indizes und der Optimizer ? was wird bei der Kostenberechnung berücksichtigt, was nicht? OPTIMIZER_INDEX_COST_ADJ / OPTIMIZER_INDEX_CACHING, System Statistiken etc.
- Index Design: Auf was ist beim Design von Indizes zu achten? Was ist für die Reihenfolge von mehreren Ausdrücken in einem Index relevant? Wann ist ein Bitmap Index sinnvoll?
- Index Compression: Wie funktioniert dieses Feature und was bringt es? Welche Auswirkungen gibt es? Unterschied zwischen Basic und Advanced Low / High CompressionUnterstützung
beim Testen unterschiedlicher Partitionierungsstrategien im Data Warehouse
Umfeld, korrektes Aufsetzen der Testumgebung / Daten / Statistiken. Auswertung
der Ausführungspläne / Performance / Vergleich zwischen alter und neuer Strategie
Vortrag
?Kostenlos! Die am wenigsten benutzten Performance Features der Oracle
Datenbank? auf den IT Tagen 2022
Einführung
in die systematische Analyse und Verbesserung von Oracle Datenbank Performance.
Kennenlernen und Üben verschiedener Werkzeuge wie SQL Trace, Rowsource
Statistiken, AWR / ADDM / Statspack, SQL Monitoring, korrektes Lesen und
Verstehen von Ausführungsplänen etc.
Unterstützung
bei der Vorbereitung und Durchführung der Migration einer bestehenden Logistik
Software von Oracle 11.2.0.4 auf Oracle 19c.
Nach dem Installieren des Release Update 15 von 19c (RU 19.15) gibt es Laufzeitprobleme mit Tableau Berichten ? Ausführungspläne verwenden Indizes und Nested Loop Joins obwohl diese Indizes als ?INVISIBLE? markiert sind, was zu sehr langen Laufzeiten führt.
Eine Analyse ergibt, dass Auslöser der Probleme sehr schlechte Abschätzungen auf bestimmten, kleinen Dimensionstabellen sind. Diese werden vom Optimizer so abgeschätzt, dass die angewendeten Filter keine Daten zurückliefern, was grob falsch ist. Der Grund für die falsche Abschätzung ist das ?Dynamic Sampling? Feature der Datenbank und der Zustand dieser kleinen Tabellen, die viel mehr Platz allokieren als sie eigentlich müssten / sollten, was dazu führt, dass das ?Dynamic Sampling? nicht gut funktioniert (das Sampling greift nur auf leere Blöcke zu, wenn man Pech hat, da das Segment so viele leere Blöcke beinhaltet) und daher die Abschätzungen so negativ beeinflusst.
Die ?INVISIBLE? Indizes kommen nur daher zum Zuge, da bestimmte Views den Hint ?USE_INVISIBLE_INDEXES? beinhalten ? aber auch ohne Verwendung dieser Indizes sind die Ausführungspläne aufgrund der schlechten Abschätzungen ineffizient.
Eine Reorganisation der betroffenen Tabellen löst das Problem ? Hinweise werden noch zur Verfügung gestellt, wie das Problem in Zukunft vermieden werden könnte, indem die Tabellen auf eine andere Art und Weise gepflegt werden (Vermeiden der Kombination aus Updates auf komprimierten Daten, Deletes und Insert APPEND).Vortrag ?Kostenlos!
Die am wenigsten benutzten Performance Features der Oracle Datenbank? auf der
DOAG Konferenz 2022
Eine Bank möchte eine Inhouse Lösung zur Archivierung von Applikationsdaten entwerfen, die die Daten in einer Oracle Datenbank auf Exadata mit ZFS Storage speichert. Es soll den Applikationen ein generisches Datenbank-Interface zur Verfügung gestellt werden, das die Archivierung von Oracle Tabellen revisionssicher ermöglicht. Dazu werden verschiedene Oracle Datenbank Features wie ?Immutable Tables? und ?Database Vault? evaluiert.
Ausführliche Beschreibung. Demonstration und Diskussion der Oracle Exadata Database Machine in Form eines individuellen Workshops ? Aufbau, Features (Storage Cells, Smart Scans, Flash Cache, Persistent Memory, RoCE, Hybrid Columnar Compression etc.), wann profitiert man von den speziellen Exadata Features, detaillierter technischer Hintergrund, wie die diese Features funktionieren und wie deren Einsatz analysiert und gemessen werden kann.
Öffentliches Expertenseminar mit folgendem Inhalt:
In diesem Workshop Oracle Database Performance: Hands-on lernen wir anhand verschiedener praktischer Beispiele unterschiedliche Techniken kennen, mit denen Performance in der Datenbank im Detail analysiert werden kann. Es geht dabei um die Antwort auf die Frage, womit die Zeit in der Datenbank verbracht wird und wie dies gemessen werden kann.
Die Teilnehmer führen die Schritte unter Anleitung des Seminarleiters in ihrer eigenen oder einer vorbereiteten Datenbank durch und bekommen dadurch praktische Erfahrung, wie die jeweiligen Techniken funktionieren und was es bei der Anwendung zu beachten gilt.
Eine hauseigene Applikation soll auf Exadata migriert werden. Auf der Exadata Umgebung laufen jedoch einfache Updates und Inserts deutlich langsamer als auf den nicht-Exadata Umgebungen. Eine genauere Analyse ergibt, dass hier ?Flashback Database Archive (FBDA)? zum Einsatz kommt und die Verzögerungen hauptsächlich durch die rekursiven Aktivitäten von FBDA verursacht werden. Die Symptome, validiert durch einen SQL Trace, entsprechenden denen im Bug "Bug 31201192 - Hang with 'fbar timer'<='enq: tx - contention' (Doc ID 31201192.8)" beschriebenen. Dem Kunden wird nahegelegt, den verfügbaren Patch als ?Backport? für die eingesetzte Version von Oracle 19c bei Oracle Support zu beantragen.
Desweiteren laufen auf der Exadata bestimmte Import-Prozesse, bei denen aus Applikationssicht nur einfache Batch-Inserts durchgeführt werden, auf der Exadata sehr langsam. Eine Analyse zeigt, dass die Datenbank sich damit beschäftigt, tausende von Child Cursorn für diese Inserts zu erzeugen / zu verwalten. Das Grundproblem besteht in der Verwendung von falschen Datentypen beim Binden von Bind-Variablen von Applikationsseite. Nach Korrektur der Datentypen laufen die Inserts um Faktor 1000 schneller und die Anzahl der Child Cursor reduziert sich auf wenige einzelne.
Workshop ?Datenbank Performance für Entwickler? ? Beschreibung:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um effektiver mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt, eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
- Instrumentierung
- Trace / Row Source Statistics / Active Session History / Real Time SQL Monitoring
- Grundlagen Optimizer, Histogramme, Statistiken (inkl. New Features 12c)
- (serielle) Ausführungspläne richtig lesen
- Indizierung
- Clustering / Speicherformen inkl. New Features 12c: Attribute Clustering / Zonemaps, Heap, Index Organized Tables, Cluster
- Hints
- Bind Variablen / Literale und ungleichmäßige Datenverteilung
- Datenbank Links / Transaktionen / Locks
Umstellung der internen Speichermethode von XML-Daten. Oracle verwendet eigentlich seit Version 11.2 intern die Speichermethode ?Binary XML? für XMLType Daten. Eine Software eines Drittherstellers verwendete jedoch explizit noch die Speichermethode ?CLOB?, was deutlich mehr Platz in der Datenbank belegt. Nach Abklärung mit dem Hersteller wurde ein Migrationskonzept mit automatisierter Umstellung von über 5.000 bestehenden Tabellen erstellt und auch umgesetzt, so dass innerhalb weniger Minuten diese Tabellen auf ?Binary XML? Speichermethode umgestellt wurden ? dazu wurde mittels Create Table As Select (CTAS) eine temporäre Kopie der jeweiligen Tabelle angelegt und die alte Tabelle entsprechend entfernt / ersetzt, automatisiert per Skript. Als Absicherung für den Fall, dass die Migration nicht erfolgreich ist oder nachfolgend Probleme in der Applikation auftreten, wurde die Original-Datenbank (Oracle 19c CDB/PDB Architektur) als PDB-Kopie erhalten.
Vortrag ?Oracle Database 21c New Performance Features? auf der Sangam 21 / All Indian Oracle User Group (AIOUG) 2022 Konferenz
Abfragen in einem Data Warehouse verhalten sich unterschiedlich, je nachdem, wie auf die Partitionen der Daten zugegriffen wird. Bei Verwendung einer einzigen Partition sind die grundsätzlichen Abschätzungen des Optimizers so weit schlüssig, bei Zugriff auf mehrere Partitionen sind die Abschätzungen sehr schlecht. Es stellt sich heraus, dass durch die Verwendung von inkrementellen Statistiken ein Bug entsteht, der die Spaltenstatistiken des Partitionsschlüssels auf globaler Ebene verfälscht, so dass je nach Datenmenge pro Partition völlig falsche Annahmen seitens des Optimizers getroffen werden. Es werden verschiedene Lösungsmaßnahmen besprochen (unter anderem Verhinderung der Erzeugung eines Histogramms) und ein generischer Testcase für Oracle Support vorbereitet, um den Bug nachstellen zu können.
Abfragen, die versuchen, auf bestimmte Partitionen dynamisch einzuschränken per Unterabfrage erreichen nur inkonsistentes Partition Pruning. Da der Kunde bereits auf Oracle 19c ist, wird dieses Problem mittels ?SQL Macros? adressiert, was erlaubt, den Partitionsschlüssel als Literal anzugeben und trotzdem dynamisch zu bestimmen.
Darüber hinaus gibt es noch Probleme mit bestimmten Transformationen seitens des Optimizers (?Group By Placement?), die zu schlechten Abschätzungen und als Folge zu ineffizienten Ausführungsplänen führen. Dies kann durch eine Parametereinstellung verhindert werden.Öffentliches Expertenseminar mit folgendem Inhalt:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um effektiver mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
Vorträge im Rahmen der trivadis Performance Days 2021: ?Oracle Datenbank 21c New Performance Features? und ?Oracle Datenbank Indexing Myths?
Verschiedene mittels Tableau erzeugte Berichte schwanken stark in der Laufzeit. Es gilt zu ermitteln, ob die Schwankungen maßgeblich durch unterschiedliches Verhalten in der Datenbank verursacht werden oder es andere Gründe außerhalb der Datenbank gibt, wie zum Beispiel Netzwerk oder auch auf Applikationsebene (Tableau Reporting Plattform).
Eine Analyse ergibt, dass die Datenbank zwar teilweise an den unterschiedlichen Laufzeiten beteiligt ist, dies aber nur aufgrund unterschiedlicher Auslastung, aber nicht aufgrund unterschiedlicher Ausführungspläne oder anderer Gründe. Maßgeblich werden die Schwankungen durch die Reporting Plattform verursacht, die sehr stark unterschiedlich lange benötigt, um die bereits von der Datenbank zur Verfügung gestellten Daten abzuholen.Workshop ?Datenbank Performance für Entwickler? ? Beschreibung:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um effektiver mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt, eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
Der Export von historischen Daten ist bei einer Standardsoftware sehr langsam, da SQLs pro Datensatz ausgeführt werden, und pro Ausführung mehrere Sekunden an Laufzeit entstehen. Unter MySQL ist die Ausführung nochmal deutlich langsamer als unter Oracle. Eine detaillierte Analyse zeigt, dass die Datenbanken aufgrund der Art und Weise, wie das SQL geschrieben ist, nicht in der Lage sind, die Historie nur für die in Frage kommenden Datensätze zu ermitteln, sondern jeweils die komplette Datenmenge mehrfach pro SQL-Ausführung verarbeiten.
Durch Umformulierung der SQLs (mittels Verwendung von LATERAL Views) wird sowohl Oracle als auch MySQL in die Lage versetzt, die Historie nur für die relevanten Datensätze zu ermitteln, was einer Performance-Steigerung von Faktor 1000 entspricht, da jetzt nur noch wenige Millisekunden für eine einzelne Ausführung benötigt werden, anstatt mehrerer Sekunden.Individual Workshop „Datenbank Performance für Entwickler“ – inklusive Analyse von individuellen Problemfällen und Vorschlägen, wie diese verbessert werden können. Dazu noch Vorschläge, wie die Diagnosemöglichkeit von Applikationsseite verbessert werden kann, durch zum Beispiel selektives Aktivieren von SQL Trace und automatisiertes Einsammeln erweiterter Informationen bezüglich Ausführungsplänen.
Design und Umsetzung einer automatisierten Anonymisierung und Übertragung der Produktionsdatenbank in Testumgebungen. Die zu maskierenden Felder und die dafür verwendeten Regeln sind konfigurierbar über Metadaten, als auch die resultierende Datenmenge (zum Beispiel nur 10% des Originaldatenbestandes). Die Maskierung erfolgt performanceoptimiert über entsprechend automatisch mittels Metadaten generierte CTAS (Create Table As Select) Operationen, da die Laufzeiten durch die massive Verwendung von XML in der Datenbank eine wichtige Rolle spielen. Durch entsprechende Optimierung der CTAS Operationen kann die Laufzeit um Faktor 20 bis 40 erhöht werden und damit das Gesamtvolumen an zu maskierenden Daten in unter 24 Stunden verarbeitet werden trotz der komplexen Maskierungsregeln auf XML-Dokument Ebene. Für Bugs, die nach dem Oracle 19c Upgrade eine Verarbeitung aufgrund von PGA Speicherleaks und exzessiver TEMP Allokation unmöglich machten, wurde noch eine iterative Verarbeitung in Teilstücken implementiert, um die Probleme zu umgehen.
In einer operativen Datenbank werden bestimmte Berichte erstellt, die eigentlich in einer Data Warehouse Umgebung erstellt werden sollen, derzeit aber nicht erstellt werden können.
Daher sind die Daten in der operativen Datenbank nicht für diese Art von Abfragen optimiert, was Schema Design, Partitionierung und Indizierung angeht.
Aufgrund der nur vorübergehenden Natur (die Berichte sollen dann in absehbarer Zukunft im Data Warehouse erstellt werden) sollen auch keine größeren Anpassungen / Änderungen an der operativen Datenbank durchgeführt werden.
Als Problem stellt sich der Zugriff auf eine größere Tabelle mit Milliarden von Zeilen dar. Durch eine entsprechende Indizierung kann der Tabellenzugriff komplett vermieden werden, was die Laufzeit der relevanten Berichte entsprechend verbessert und Langläufer im Stunden-Bereich verhindert.
Für einen bestimmten Bericht wurde die Generierung der Informationen von einem iterativen Schleifenansatz mit potenziell sehr vielen Wiederholungen auf ein einzelnes SQL umgestellt, das die Daten zuverlässig innerhalb weniger Minuten generiert, was für die Nachtverarbeitung völlig ausreichend ist. Der Schleifenansatz war im Gegensatz dazu schlecht vorhersehbar, was die Gesamtlaufzeit angeht und deutlich langsamer (im Stundenbereich)
Öffentliches Expertenseminar mit folgendem Inhalt:
- Wie lese ich einen Ausführungsplan richtig? Gibt es besondere Regeln für parallele Ausführungspläne? Und falls ja, wie sehen diese aus?
- Wie führt Oracle so einen Ausführungsplan zur Laufzeit aus?
- Was machen diese ganzen Operationen, die mit PX anfangen, in einem parallelen Ausführungsplan? Was sagen mir die zusätzlichen Spalten, die es nur in einem parallelen Ausführungsplan gibt?
- Wie funktioniert diese automatische parallele Ausführung von SQL Statements zur Laufzeit? Was wird parallelisiert, und wie wird die Arbeit automatisch aufgeteilt? Was kann dabei schiefgehen? Falls etwas schiefgeht, kann ich es beeinflussen, und falls ja, wie?
- Warum sind manchmal parallele Ausführungen nicht viel schneller als serielle, oder sogar langsamer, und warum verbrauchen parallele Ausführungen teilweise so viel mehr PGA-Speicher und/oder TEMP-Speicherplatz wie vergleichbare serielle Ausführungen?
- Wie kann ich eine SQL Statement-Ausführung analysieren, um zu verstehen, warum sie länger braucht als erwartet? Wie setze ich die Diagnostics- und Tuning-Pack License Features optimal in diesem Zusammenhang ein?
- Wie kann ich speziell parallele SQL-Ausführungen analysieren, um zu verstehen, ob Parallel Execution hier überhaupt effizient eingesetzt wird? Warum sind die für serielle Ausführungen bekannten Analyse-Methoden dafür größtenteils ungeeignet?
- Wie kann ich parallele Ausführungen schon beim physischen Datenbank-Design schneller machen?
- Welche neuen Parallel Execution Features sind in Oracle 12c dazugekommen?
Der Workshop vermittelt ausführliche Antworten zu diesen Fragen. Darüber hinaus bietet es Ihnen zu einem großen Teil exklusives Wissen, das von mir selbst erarbeitet wurde. Dieses Wissen werden Sie woanders - auch nicht in den offiziellen Unterlagen und Schulungen von Oracle - finden.
Ein Kunde überprüft die Angabe der "Feature Usage" in DBA_FEATURE_USAGE_STATISTICS als Vorbereitung für einen License Audit seitens Oracle. Obwohl der Kunde nur über eine "Standard Edition" Lizenz verfügt und sich an keine aktive und absichtliche Nutzung von Enterprise Edition Features erinnern kann, werden dort sowohl "Real Application Security" als auch "Adaptive Plans" als benutztes Feature angezeigt - welche beide als "Enterprise Edition" Features seitens Oracle geführt werden.
Eine detaillierte Analyse ergibt, dass beide Features bereits bei der Standard-Installation einer 12.2.0.1 Standard Edition als "in use" angezeigt werden, da Oracle entsprechende Objekte bereits in der "Template"-Datenbank mitliefert, die eine Nutzung von "Real Application Security" anzeigen, und auch fälschlicherweise den Parameter "OPTIMIZER_APAPTIVE_PLANS" auf "TRUE" setzt, obwohl dieses Feature in der "Standard Edition" überhaupt nicht zur Verfügung steht.
Insofern sollte der Kunde bezüglich eines Audits seitens Oracle hier auf der sicheren Seite sein.
Verschiedene Abfragen verlängern sich signifikant in der Laufzeit nach dem Upgrade von 18c auf 19c und dem Hochsetzen des Parameters OPTIMIZER_FEATURES_ENABLE von „11.2.0.4“ auf „19.1.0“. Detaillierte Analyse der unterschiedlichen Abfragen mit Vorschlägen, wie funktionierende Workarounds aussehen können. Weitere Probleme unterschiedlichster Natur treten auf, von Planregressionen bis hin zu ORA-Fehlermeldungen beim Parsen sowie falschen Ergebnissen. Unterstützung bei der Zusammenarbeit mit Oracle Support mittels Vorbereitung entsprechender generischer Test Cases. Entwicklung entsprechender Workarounds für die genannten Probleme.
Nach einem Upgrade von Oracle 12.1 auf 19c gibt es mehrere Performance Probleme sowie Abbrüche in der Verarbeitung aufgrund von unzureichendem PGA Speicher. 19c benötigt signifikant mehr PGA Speicher pro Prozess und die Applikation erzeugt über mehrere Knoten von Application Servern mehrere Connection Pools, was zu einer hohen Grundlast an Prozessen führt. Desweiteren kommt seit der Version 18c einer neuer Speicherbereich zum Einsatz - die sogenannte „MGA" – ein Zwitter aus privaten und geteiltem Speicher, da „Shared Memory“ bei Bedarf dynamisch allokiert und zwischen mehreren Prozessen geteilt wird. Diese zusätzliche Speicherkomponente macht insbesondere unter Solaris Probleme, da zur Laufzeit immer wieder Allokationsfehler und damit Abbrüche auftreten können.
Das MGA-Problem kann mittels einiger interner Parameter umgangen werden, um die neue Speicherallokation in dem MGA Bereich zu verhindern.
Durch die erhöhte PGA Allokation unter 19c ist auch eine Anpassung der Parameter PGA_AGGREGATE_TARGET und PGA_AGGREGATE_LIMIT angezeigt,dadieInstanzeffektivmehr PGA benötigt als per PGA_AGGREGATE_TARGET zugewiesen. Die Performance Probleme sind nach entsprechender PGA Parameteranpassung und Erhöhung des physisch zur Verfügung stehenden Speichers auf Host Ebene weitgehend gelöst – eine Übersicht der Top SQLs, die Potential für effizientere Ausführung haben, wurde zusätzlich geliefert sowie noch einige andere Fragen bezüglich Indizierung, Konfiguration Maintenance Windows, „Killed Sessions“ etc. beantwortet.
Vortrag „Oracle Database Performance Tuning: Back To Basics” in auf der DOAG Konferenz 2020 sowie den IT Tagen 2020
Eine hoch frequent aufgerufene Schnittstellen-Funktion arbeitet mindestens 12 Sekunden pro Aufruf – häufig auch länger, was zu einer Warteschlange für die zu verarbeitenden Aufrufe führt. Teilweise müssen solche Aufrufe dann über 20 Minuten in der Warteschlange verbringen, was dann wiederum zu Timeouts in den aufrufenden Systemen führt. Durchschnittlich müssen Anfragen ca. 3 Minuten in der Warteschlange verbringen.
Eine Analyse zeigt, dass ein signifikanter Teil der Verarbeitungszeit in der Datenbank verbracht wird und dort vor allem ein SQL für die Laufzeit maßgeblich verantwortlich ist. Das SQL verwendet einen MINUS Operator, um ein Delta an einzufügenden Daten zu ermitteln. Da in der Zieltabelle Millionen von Datensätzen für diese Operation identifiziert werden und der MINUS Operator eine eindeutige Sortierung dieser Datenmenge benötigt, wird die Laufzeit für diese Sortieroperation maßgeblich über die zu sortierende Datenmenge bestimmt und kann daher nicht ohne weiteres optimiert werden. Leider akzeptiert die Datenbank nicht die automatische Umwandlung der MINUS SET Operation in einen Join (SET_TO_JOIN Transformation), was es erlaubt hätte, ohne Änderung des SQLs diese Umformulierung zu erreichen. Da das SQL aus einem PL/SQL Paket in der Datenbank stammt, ist eine semantisch äquivalente Umformulierung des SQLs von MINUS nach NOT EXISTS technisch möglich, ohne an anderem Quellcode der Applikation Änderungen vornehmen zu müssen. Daher wird dieser Weg eingeschlagen, nachdem mittels entsprechender Tests sichergestellt ist, dass das umformulierte SQL die gleichen Ergebnisse liefert. Da die andere Menge des MINUS Operators in den allermeisten Fällen sehr klein ist, kann der Optimizer aufgrund der Umwandlung des MINUS in einen Join effizientere Zugriffswege verwenden und vor allem die aufwändige Sortierung der großen Datenmenge vermeiden. Das umformulierte SQL benötigt nur noch ca. 3 bis 5 Sekunden zur Ausführung - nach Erzeugung eines geeigneten Index sinkt die Verarbeitungszeit auf Sekundenbruchteile.
Die durchschnittliche Wartezeit von Anfragen nach dieser Änderung sinkt von über 3 Minuten auf 2 Sekunden – Timeouts treten somit keine mehr auf und die allgemeine Verarbeitungsgeschwindigkeit steigt signifikant an.
Performance Analyse der Datenbank-Aktivitäten einer komplexen Auswertungslogik implementiert in PL/SQL nach Upgrade auf Oracle 19c. Einige Abfragen haben sich seit der letzten Analyse im Januar verändert, so dass die vorherig vorgeschlagenen Indizes angepasst werden müssen. Durch Anpassung und Ergänzung geeigneter Indizes kann die Verarbeitungszeit von über 30 Minuten auch für die größten Auswertungen auf unter 10 Minuten reduziert werden, so dass jetzt alle Auswertungen erfolgreich zu Ende laufen und nicht länger als die Timeout-Grenze von 30 Minuten benötigen.
Workshop „Den kostenbasierten Optimizer verstehen“ – grundlegende Prinzipien der Entscheidungsfindung des Optimizers, was kann schief gehen und wie stelle ich das fest, welche Möglichkeiten der Beeinflussung gibt es. Wie liest man Ausführungspläne richtig, wie generiert man Laufzeitprofile von SQL-Ausführungen und wertet diese aus. Wichtige Hinweise, auf was man bei der Statistikgenerierung für den Optimizer achten sollte. Clustering von Daten richtig verstehen und welche Möglichkeiten der Beeinflussung gibt es.
Öffentliches Expertenseminar für die DOAG (Deutsche Anwender Oracle Gruppe) am 28. und 29.9. mit folgendem Inhalt:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um bestmöglichst mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
Individual Workshop über relevante neue Features der Oracle Datenbank aus Sicht von Datenbank-Entwicklern / Applikationen, die in den neuesten Versionen hinzugefügt wurden
Nach dem Upgrade von Oracle 12.2.0.1 nach 19c (19.6) einer Data Warehouse Datenbank war die Performance signifikant schlechter. In Testumgebungen ist der Effekt zuvor so nicht aufgetreten. Es handelt sich um eine zwei Knoten RAC Datenbank als PDB auf Exadata (X7-2). Eine Analyse ergab folgende Punkte:
- Verschiedene RAC spezifische Bugs, die zu Hängern im Bereich der Cluster Waits („gc“) geführt haben, bei denen SQL-Ausführungen zum Beispiel unendlich auf „gc current request“ gewartet haben. Als initialer Workaround wurde das „read-mostly“ RAC feature deaktiviert und nach Verfügbarkeit und Installation entsprechender One-Off Patches, die leider nicht Teil des eingesetzten RUs waren, traten die Hänger nicht mehr auf
- Ein anderer RAC spezifischer Bug, der zu regelmäßigen Crashes der Instanzen geführt hat, wurde auch durch Installation eines entsprechenden One-Off Patches behoben
- SmartScans funktionierten seit der Installation des Cell Firmware Upgrades nicht mehr, da alle Zellen im Database Level Quarantine Mode agierten aufgrund von drei Crashes innerhalb von drei Stunden. Die verursachende SQL-Operation wurde identifiziert und mittels der Analyse des Cell crash Trace Files wurde klar, dass das Problem mit dem Cell Columnar Flash Cache zusammenhängt. Als initialer Workaround wurde dieses Feature deaktiviert, was es erlaubt hat, die Database Level Quarantine zu entfernen ohne dass es zu weiteren Crashs auf Zellenebene kam. Oracle hatte den Bug in der Zwischenzeit auch identifiziert und in einer neueren Version der Firmware behoben, die dann auch installiert wurde.
- Inkrementelle Statistiken funktionierten nicht mehr nach dem 19c Upgrade, da 19c die von 12.2 generierten Synopsen nicht verarbeiten kann, weil ein PL/SQL Fehler in internen Paketen auftritt, was dazu führt, dass effektiv die globalen Statistiken immer neu berechnet wurden anstatt inkrementelle Statistiken zu verwenden. Bisher steht als Workaround nur zur Verfügung, die Synopsen komplett neu zu berechnen, was keine empfehlenswerte Operation bei einem Multi-Terabyte Data Warehouse ist
- Allgemein ist die Performance des RACs in Produktion maßgeblich beeinflusst von einer signifikanten Zunahme an Cluster bezogenen Warteereignissen, insbesondere beträgt die durchschnittliche Wartezeit 50 mal länger in Produktion (40 ms im Vergleich zu 800 μs) als in Testumgebungen bei vergleichbarer Arbeitslast. Die Root Cause Analyse für dieses unterschiedliche Verhalten ist noch ausstehend zum Zeitpunkt des Schreibens
- Unabhängig vom Upgrade zeigten einige Tabellen sehr merkwürdiges Verhalten in Bezug auf SmartScan Performance und Platzbedarf, was zu sehr schlechter Performance führt – mehr als 60 Sekunden für einen trivialen, parallelen SELECT COUNT(*) einer 20 GB Partition, der Millionen logische I/Os zusätzlich generiert und dadurch den CPU Verbrauch auf den Compute Nodes nach oben treibt, sowie einen signifikant erhöhten Platzbedarf – anstatt 20 GB benötigt eine 1:1 Kopie der gleichen Daten mit gleicher Hybrid Columnar Compression (HCC) Kompressionsstufe nur ca. 400 MB, was 50mal weniger ist. Auch die SmartScan Performance auf dieser Kopie lag im erwarteten Bereich unter einer Sekunde. Block dumps zeigten leere HCC Compression Units und Chained Rows. Die derzeit verwendete Kombination aus HCC und Updates scheint die Daten in einem sehr ungünstigen Zustand zu hinterlassen, was Kompression, Chained Rows und Platzbedarf angeht
Eine Applikation zur Berechnung der optimalen Fahrtrouten von Paketauslieferungen zeigt immer wieder „Hänger“, bei denen minutenlang Jobs und Abfragen in der Datenbank hängen bleiben, was signifikante Auswirkung auf die gesamte Applikation hat, da die zeitnahe Neuberechnung der Routeninformation gewährleistet sein muss. Dieses Verhalten ist seit einer Datenbereinigungsaktion zu beobachten, bei der Daten aus der Datenbank gelöscht wurden und von der man sich positive Effekte auf die Performance und den Platzbedarf versprochen hat. Die Analyse ergibt, dass es sich um Sperrungen auf der Ebene des sogenannten „Library Caches“ der Oracle Datenbank handelt – der Cache, der vor allem dazu dient, alle verwendeten Objekte und deren Abhängigkeiten untereinander zu verwalten. Dazu muss man wissen, dass DDL Operationen exklusive Sperrungen auf Library Cache Ebene verursachen, als auch das Neuerstellen von Ausführungsplänen. Die erwähnte Applikation verwendet zum Teil partitionierte Tabellen – wobei es sich um eine fragwürdige Verwendung davon handelt, da pro Tag fast 600 neue Partitionen erzeugt werden. Das führt auch dazu, dass tagsüber während hoher Aktivität auf dem System es zu ALTER TABLE DDLs kommt, die neue Partitionen anlegen und somit vorhandene SQLs im Shared Pool invalidieren. Damit kommt es regelmäßig zu „Parse-Stürmen“, bei denen SQLs von vielen Sessions gleichzeitig ausgeführt werden, für diese SQLs aber erst wieder neue Ausführungspläne aufgrund der Invalidierung erzeugt werden müssen. In der Vergangenheit ist dies genauso geschehen, allerdings hat das Neuerstellen der Ausführungspläne nicht außergewöhnlich viel Zeit in Anspruch genommen, so dass die Auswirkung insgesamt vertretbar war. Seit der erwähnten Datenbereinigungsaktion verhielt sich der Optimizer aber anders, was dazu führte, dass die Erstellung des Ausführungsplans von SQLs, die die partitionierten Tabellen verwenden, extrem lange dauern kann – bis zu mehreren Minuten – und in dieser Zeit andere Sessions, die entweder auch das gleiche SQL versuchen auszuführen oder zu parsen, oder andere Sessions, die einen exklusiven Lock auf „Library Cache“ Ebene auf bestimmte Objekte benötigen, so lange warten müssen, bis für dieses SQL ein Ausführungsplan erstellt wurde. Dies führte zu teilweise extremen Wartesituationen. Ursache für die Verhaltensänderung war ein Feature der Datenbank, bei Einsatz von Parallel Execution beim Erstellen eines Ausführungsplans „Dynamic Sampling“ einzusetzen. Dieses „Dynamic Sampling“ kann bei partitionierten Tabellen eine IN Liste der zu samplenden Partitions-IDs bei Erzeugung der rekursiven Abfrage zur Ermittlung von Selektivitäten verwenden – bei höheren Sampling-Leveln kann es hier bis 512 Partitionen aufzählen. Die Verhaltensänderung bestand darin, dass der Sampling Level sich von Level 7 auf Level 8 erhöht hat, da die Tabelle insgesamt ca. 65 Millionen Blöcke hat und dies genau die Grenze darstellt, um von Level 7 auf Level 8 bei der automatischen Anpassung des Leves zu gehen. Daher wurden seitdem eben 512 Partitionen aufgelistet anstatt wie bisher nur 256. Dies wiederum hatte zur Folge, dass der Optimizer in einen Bug gelaufen ist beim Erstellen des Ausführungsplans für die rekursive „Dynamic Sampling“ Abfrage (durch Verlängerung der IN Liste), was dann für die minutenlange Verzögerung bei der Erstellung des Ausführungsplans des eigentlich betroffenen SQLs verantwortlich war. Als Workaround wurde eine Kombination aus SQL Plan Baseline und SQL Patch für die SQLs eingeführt, die von dem Problem maßgeblich betroffen waren bzw. die die meiste Auswirkung auf das System hatten, indem sie andere SQLs blockierten. Die Aufgabe der SQL Plan Baseline war die Fixierung des derzeitigen Ausführungsplans, während die Aufgabe des SQL Patches die Deaktivierung von „Dynamic Sampling“ war. Damit trat der beschriebene Effekt für diese SQLs nicht mehr auf. Die generelle, datenbankweite Abschaltung des Features, das die automatische Erhöhung des „Dynamic Sampling“ Levels bewirkt, wurde evaluiert und wird eventuell eingesetzt, sollte sich das Verhalten auch noch auf andere SQLs auswirken, die mit den bereits etablierten Mitteln nicht behandelt werden können – zum Beispiel SQL Texte, die Literale bzw. variabel lange IN Listen verwenden. Dazu wurde auch evaluiert, in welchem Maße sich die Verwendung von „Dynamic Sampling“ überhaupt derzeit positiv auf die Ausführungspläne auswirkt, um das mögliche Risiko bei Abschalten des Features besser einschätzen zu können.
Ausführliche Beschreibung. Demonstration und Diskussion der Oracle Exadata Database Machine in Form eines individuellen Workshops – Aufbau, Features (Storage Cells, Smart Scans, Flash Cache, Persistent Memory, RoCE, Hybrid Columnar Compression etc.), wann profitiert man von den speziellen Exadata Features, Analyse des Istzustands und Bewertung in Bezug auf Nutzungsmöglichkeiten / mögliche Vorteile eines Umstiegs auf Exadata sowie mögliche notwendige Anpassungen der derzeitig etablierten Prozesse (Backup, High Availability etc.) als auch Migrationsstrategien.
Individual Workshop zu Oracle Datenbank Performance Themen, insbesondere Locking, Parallelisierung, Indizierung, Analysemöglichkeiten innerhalb der Datenbank
Seit 2010:
- Regelmäßige Kurzeinsätze im Bereich Oracle Datenbank Performance Troubleshooting + Tuning
- Öffentliche Seminare + Webinare
- Regelmäßige Veröffentlichungen, unter anderem Co-Autor [Titel und ISBN auf Anfrage]
- Schulungen / Workshops in Zusammenarbeit der DOAG und im Auftrag der Oracle University
Auswahl Kurzeinsätze:
Zeitraum: März 2024
Name des Projekts:
Oracle
Datenbank 19c Migration Exadata nach Amazon RDS
Lokation:
Frankfurt
am Main / remote
Branche: Bank
Kurzbeschreibung:
Eine auf
Exadata hin optimierte, bestehende Applikation soll auf Amazon RDS migriert
werden. Dort zeigen sich bei ersten Tests signifikant längere Laufzeiten. Eine
Analyse der Datenbankaktivitäten zeigt an, dass bestimmte Abfragen Full Table
Scans auf großen Tabellen durchführen und durch die hohe Anzahl an
gleichzeitiger Ausführung eine Überlastung der CPUs auf dem Datenbankserver
verursacht wird. Verschiedene Ansätze und Lösungsstrategien wurden erarbeitet
und werden jetzt in weiteren Tests untersucht.
Zeitraum: August 2023 - März 2024
Name des Projekts: Unterstützung Oracle Upgrades, Sicherheit und Performance
Lokation: Münster, Deutschland / remote
Branche: Kommunalverwaltung
Kurzbeschreibung:
Eine selbst verwaltete Datenbank Infrastruktur bestehend aus über 40 Oracle Datenbanken unter Windows soll mittels automatischer Upgrades auf den aktuellen Release Update Stand von Oracle 19c gebracht werden ? je nach Sicherheitseinschätzung der von Oracle im Rahmen der ?Critical Patch Updates? gemeldeten Schwachstellen. Dazu soll evaluiert werden, ob das neue ?Autoupgrade? Tool von Oracle für eine Teilautomatisierung dieser Aufgabe eingesetzt werden kann. Darüber hinaus sollen eventuell auftretende Performance-Probleme analysiert und behoben werden.
Zeitraum: Januar 2024
Name des Projekts:
Oracle Datenbank 19c Performance Troubleshooting
Lokation: Frankfurt am Main
Branche: Bank
Kurzbeschreibung:
Sporadisch
auftretende ?Hänger? in Form von sehr langen Antwortzeiten in einer Oracle 19c
Datenbank führen zu ebenso sporadischen Ausfällen einer kritischen Inhouse
Applikation. Die Analyse ergibt extrem lange Wartezeiten auf verschiedene
Ereignisse, insbesondere ist I/O betroffen, sowohl beim Lesen von Blöcken als
auch beim Schreiben durch den Logwriter oder DB Writer. Eine Fehlkonfiguration
im Bereich des Netzwerks erklärt den hardwareseitigen Fehler, der zu den
sporadischen Hängern im Storage Bereich führt. Darüber hinaus zeigt sich, dass
verschiedene Datenbanken / Datenbank-Instanzen auf dem gleichen Host ausgeführt
werden ? eine davon (nicht die direkt betroffene) ist seitens der Connection
Pools der Applikation fragwürdig konfiguriert. Es werden tausende Verbindungen
zur Datenbank aufgebaut und teilweise sind dadurch auch tausende Sessions
gleichzeitig aktiv, je nach Lastprofil der Applikation. Nach Schwenk des
Servers in ein anderes Rechenzentrum treten die Probleme im Bereich des
Storages nicht mehr auf ? die Lastspitzen sind aber weiterhin problematisch.
Eine Detailanalyse der Aktivitäten, die zu den Lastspitzen führen und
Vorschläge, wie diese optimiert werden können, runden die initiale Analyse ab.
Zeitraum: Dezember 2023
Name des Projekts: Vortrag "Gutes Index Design - eine praktische Anleitung" auf der IT Tage 2023 Konferenz
Lokation: Frankfurt am Main
Branche: Konferenzen
Kurzbeschreibung:
Vortrag "Gutes Index Design - eine praktische Anleitung" auf der IT Tage 2023 Konferenz
Zeitraum: Dezember 2023
Name des Projekts:
Migration Oracle 19c Data Warehouse von AIX nach Linux
Lokation: Frankfurt am Main
Branche: Bank
Kurzbeschreibung:
Unterstützung
bei der Planung einer Migration von AIX nach Linux für ein Data Warehouse auf
Oracle 19c. Detaillierte Ausarbeitung der Zielkonfiguration und der Tests auf
der neuen Plattform.
Zeitraum: November 2023
Name des Projekts: Vortrag "Gutes Index Design - eine praktische Anleitung" auf der DOAG 2023 Konferenz
Lokation: Nürnberg
Branche: Konferenzen
Kurzbeschreibung:
Vortrag "Gutes Index Design - eine praktische Anleitung" auf der DOAG 2023 Konferenz
Zeitraum: Oktober 2023
Name des Projekts: Oracle Datenbank Workshop "Den kostenbasierten Optimizer verstehen"
Lokation: Frankfurt am Main
Branche: Bank
Kurzbeschreibung:
Workshop
?Den kostenbasierten Optimizer verstehen? ? grundlegende Prinzipien der
Entscheidungsfindung des Optimizers, was kann schief gehen und wie stelle ich
das fest, welche Möglichkeiten der Beeinflussung gibt es. Wie liest man
Ausführungspläne richtig, wie generiert man Laufzeitprofile von SQL-Ausführungen
und wertet diese aus. Wichtige Hinweise, auf was man bei der
Statistikgenerierung für den Optimizer achten sollte. Clustering von Daten
richtig verstehen und welche Möglichkeiten der Beeinflussung gibt es.
Zeitraum: September 2023
Name des Projekts: DOAG Expertenseminar ?Oracle Datenbank Indexing?
Lokation: DOAG
(Deutsche Oracle Anwender Gruppe) GmbH, Berlin
Branche: User
Group / Communities
Kurzbeschreibung:
Öffentliches Expertenseminar mit folgendem
Inhalt:
In diesem Seminar werden die wichtigsten Themen
bezüglich Indizierung mit B*Tree und Bitmap Indizes in der Oracle-Datenbank
behandelt ? Text / XML / JSON / Domain-Indizes werden zwar je nach verfügbarer
Zeit erwähnt und beschrieben, aber es wird nicht ausführlich darauf eingegangen
? der Schwerpunkt liegt eindeutig auf den B*Tree / Bitmap Indizes:
- Grundlagen: Wie ist ein B*Tree-Index aufgebaut, wie ein Bitmap-Index und welche Konsequenzen ergeben sich daraus? Wie verändert sich ein Index bei DML-Operationen und was ergibt sich daraus?
- Index Access, Filter und Clustering von Daten: Welche Operationen sind beim Index-Zugriff wann wie kostspielig? Warum wird der sogenannte Clustering Factor von Indizes häufig von der Datenbank falsch berechnet und was kann man dagegen machen? Warum kann ein Full Table Scan deutlich effizienter als ein Zugriff per Index sein? Indizes und der Optimizer - was wird bei der Kostenberechnung berücksichtigt, was nicht? OPTIMIZER_INDEX_COST_ADJ / OPTIMIZER_INDEX_CACHING, System Statistiken etc.
- Index Design: Auf was ist beim Design von Indizes zu achten? Was ist für die Reihenfolge von mehreren Ausdrücken in einem Index relevant? Wann ist ein Bitmap-Index sinnvoll? Was sind Function Based Indizes? Was sind virtuelle Spalten? Wie hängen diese Features zusammen und wann verwendet man welches dieser Features?
- Index Options: Invisible / Unusable / Virtual / Partial-Indizes. Primary Key / Unique / Deferred Constraints und Indizes.
- Index Compression: Wie funktioniert dieses Feature und was bringt es? Welche Auswirkungen gibt es? Unterschied zwischen Basic und Advanced Low / High Compression
- Indizes und DML: Was sind die Auswirkungen von Indizes bei DML-Operationen auf einer Tabelle? Typische Szenarien bei gleichzeitiger Veränderung von Tabellen und welche Maßnahmen hier helfen können - was sind die potentiellen Auswirkungen dieser Maßnahmen?
- Index Monitoring: Wie kann ich eine bestehende Applikation bezüglich der Indizierung überwachen und auf was ist dabei zu achten?
- Foreign Keys und Indizes: Wann sollten Foreign Keys indiziert sein, wann ist es nicht notwendig?
- Index Rebuild: Wann ist es sinnvoll, einen Index aktiv zu reorganisieren? Welche Möglichkeiten gibt es dafür und wie unterscheiden sie sich?Zeitraum: Juli 2023
Name des Projekts: Oracle Community Yatra Tour (OCYatra) 2023 Indien
Lokation:
AIOUG (All Indian Oracle User Group), Indien
Branche: User Communities
Kurzbeschreibung:
Als Teil
der Vortragenden auf der Oracle Community Yatra Tour (OCYatra) 2023 haben wir
sechs Städte (Chennai, Bangalore, Mumbai, Pune, Delhi, Hyderabad) in zwölf
Tagen besucht und in jeder Stadt einen Konferenztag mit jeweils bis zu 400
Teilnehmern gestaltet. Ich habe pro Konferenztag drei Vorträge gehalten:
Oracle 12c to 23c New Performance Features, Advanced Indexing und Advanced
Oracle Troubleshooting
Zeitraum: Juni 2023
Name des Projekts: Unterstützung Upgrade 11.2 nach 19cKurzbeschreibung:
Eine
komplexe, weitgehend datenbankbasierte Applikation (große Mengen an PL/SQL
Code) muss von Oracle Datenbank Version 11.2 auf 19c migriert werden.
Unterstützung in unterschiedlichen Bereichen ? detaillierte Beschreibung von
Verhaltensänderungen in 19c (zum Beispiel beim Einsatz von DBMS_JOB) als auch
Performance-Analyse bei Regressionen.
Zeitraum: Mai 2023
Name des Projekts:
Erweiterung
/ Anpassung Anonymisierung ECommerce Applikation
Lokation: Düsseldorf / Remote
Branche: Fashion /
Versandhandel
Kurzbeschreibung:
Eine
bereits vor zwei Jahren entwickelte Lösung zur performanten Anonymisierung von
relationalen und unstrukturierten XML-Massendaten wurde gemäß Kundenwunsch
angepasst und nochmals optimiert hinsichtlich Performance, da sich das
Verhalten mit aktuellen Oracle Versionen (19c) im Vergleich zu früheren Versionen
hinsichtlich Parallelisierung verändert hatte.
Zeitraum: April 2023
Name des Projekts: Oracle Datenbank 19c Performance Troubleshooting (Exadata)
Lokation: Frankfurt am Main / Remote
Branche: Finanzen
Kurzbeschreibung:
Nur mit
einer ganz bestimmten Kombination von Features tritt ein Langläufer Phänomen
beim Sammeln von Statistiken auf ? dazu gehören HCC Kompression, Parallelität,
Approximate NDV Statistikmodus, Offloading / Smart Scan, virtueller Spalte mit
CPU-intensiver Berechnung (zum Beispiel STANDARD_HASH) und ein bestimmter
Zustand der Zieltabelle nach DDL / Exchange Partition. Dann verlängert sich die
Zeit für die Statistikerstellung signifikant um mehrere Faktoren ? im Grunde
bringt die Parallelisierung in so einem Fall keine Zeitreduktion, da beliebig
viel CPU-Zeit verbraucht wird und die Dauer entspricht dann einer seriellen
Verarbeitung. Als erstes wurde ein Workaround entwickelt (ein CAST des
originären Ausdrucks auf den gewünschten Datentyp verhindert das Problem), als
zweites wurde an einem reproduzierbaren Testcase für den Oracle Support
gearbeitet.
Zeitraum: März 2023
Name des Projekts: Oracle Datenbank 19c Performance Troubleshooting (Exadata)
Lokation: Berlin / Remote
Branche: Versandhandel
Kurzbeschreibung:
Nach dem Installieren des Release Update 17 von 19c (RU 19.17) ist die gesamte Datenbank Performance sehr schlecht ? maßgeblich aufgrund sehr langsamen Transfer von Blöcken zwischen den RAC Instanzen ? anstatt durchschnittlich 400 µs pro übertragenem Block steigt dies auf fast 20.000 µs (!) an.
Eine Analyse zeigt, dass
die LMS Hintergrund-Prozesse, die in RAC für die Übermittlung der Blöcke
zuständig sind, fast permanent auf CPU Zeit verbringen, was vor der
Installation des RUs nicht der Fall war. Ein CPU Profiling zeigt an, dass die
Prozesse die gesamte Zeit beim Suchen im ?gcs resource table? verbringen, was
darauf hinweist, dass etwas mit der Verwaltung dieser Tabelle im Speicher
(Effiziente Aufteilung in ?Hash Buckets?) nicht stimmt ? es gab in der
Vergangenheit schon ähnliche Bugs in dem Bereich. Nach Rücksprache mit Oracle
Support und Einspielen entsprechender Bug Fixes ist das Problem gelöst.
Zeitraum: Februar 2023
Name des Projekts:
Individual Workshop ?Oracle Database Indexing?
Lokation: Saarbrücken
Branche: Software
Kurzbeschreibung:
In diesem Seminar werden die wichtigsten Themen bezüglich Indizierung mit B*Tree und Bitmap Indizes in der Oracle Datenbank behandelt:
- Grundlagen: Wie ist ein B*Tree Index aufgebaut, wie ein Bitmap Index und welche Konsequenzen ergeben sich daraus? Wie verändert sich ein Index bei DML Operationen und was ergibt sich daraus?
- Index Access, Filter und Clustering von Daten: Welche Operationen sind beim Index-Zugriff wann wie kostspielig? Warum wird der sogenannte Clustering Factor von Indizes häufig falsch berechnet von der Datenbank und was kann man dagegen machen? Warum kann ein Full Table Scan deutlich effizienter als ein Zugriff per Index sein? Indizes und der Optimizer ? was wird bei der Kostenberechnung berücksichtigt, was nicht? OPTIMIZER_INDEX_COST_ADJ / OPTIMIZER_INDEX_CACHING, System Statistiken etc.
- Index Design: Auf was ist beim Design von Indizes zu achten? Was ist für die Reihenfolge von mehreren Ausdrücken in einem Index relevant? Wann ist ein Bitmap Index sinnvoll?
- Index Compression: Wie
funktioniert dieses Feature und was bringt es? Welche Auswirkungen gibt es?
Unterschied zwischen Basic und Advanced Low / High Compression
Zeitraum: Januar 2023
Name des Projekts: Datawarehouse
Performance Beratung
Lokation: Wiesbaden
Branche: Versicherung / Software
Kurzbeschreibung:
Optimierung
hochkomplexer SQLs als Teil der Beladungsstrecken einer neuen Data Warehouse
Umgebung. Diese verwendet eine doppelt temporale Speicherung der Daten
(technische und fachliche Gültigkeiten), was die Komplexität und auch die zu
verarbeitenden Datenmengen entsprechend erhöht. Die Überwachung dieser SQLs
funktioniert mit Oracle Bordmitteln nicht richtig, da die SQLs zu lange laufen
(mehrere Stunden) und die Ausführungspläne so komplex sind (teilweise mehr als
1000 Operationen), dass das eingebaute Real-Time SQL Monitoring der Datenbank
nur unvollständige Berichte generiert. Die Implementierung einer
automatisierten, eigenen Logik, bei der zum Einen die unvollständigen Berichte
regelmäßig in einer Tabelle abgespeichert werden und zum Anderen diese Menge an
unvollständigen Berichten dann wieder zu einem einzelnen, vollständigen Bericht
zusammengesetzt werden, erlaubt eine effiziente Analyse dieser mittels der
Parallelverarbeitungsoption ausgeführten SQLs und eine entsprechende
Optimierung. Eine Reduktion der Laufzeiten um 50% oder mehr dieser komplexen
SQLs konnte damit erreicht werden.
Zeitraum: Dezember 2022
Name des Projekts:
Individual Workshop ?Database Performance: Hands On?
Lokation: Saarbrücken
Branche: Software
Kurzbeschreibung:
Vortrag Einführung
in die systematische Analyse und Verbesserung von Oracle Datenbank Performance.
Kennenlernen und Üben verschiedener Werkzeuge wie SQL Trace, Rowsource
Statistiken, AWR / ADDM / Statspack, SQL Monitoring, korrektes Lesen und
Verstehen von Ausführungsplänen etc.
Zeitraum: Dezember 2022
Name des Projekts: Vortrag auf der IT Tage 2022 Konferenz
Lokation: Frankfurt
Branche: Konferenzen
Kurzbeschreibung:
Vortrag ?Kostenlos! Die am wenigsten benutzten Performance Features der Oracle Datenbank? auf den IT Tagen 2022
Zeitraum: November 2022 - Januar 2023
Name des Projekts:
Individual Workshop Oracle Datenbank Performance
Lokation: Frankfurt
Branche: Finanzen
Kurzbeschreibung:
Unterstützung
beim Testen unterschiedlicher Partitionierungsstrategien im Data Warehouse
Umfeld, korrektes Aufsetzen der Testumgebung / Daten / Statistiken. Auswertung
der Ausführungspläne / Performance / Vergleich zwischen alter und neuer Strategie
Zeitraum: Oktober 2022
Name des Projekts:
Oracle Datenbank 19c Performance Troubleshooting (Exadata)
Lokation: Berlin / Remote
Branche:
Versandhandel
Kurzbeschreibung:
Nach dem Installieren des Release Update 15 von 19c (RU 19.15) gibt es Laufzeitprobleme mit Tableau Berichten ? Ausführungspläne verwenden Indizes und Nested Loop Joins obwohl diese Indizes als ?INVISIBLE? markiert sind, was zu sehr langen Laufzeiten führt.
Eine Analyse ergibt, dass Auslöser der Probleme sehr schlechte Abschätzungen auf bestimmten, kleinen Dimensionstabellen sind. Diese werden vom Optimizer so abgeschätzt, dass die angewendeten Filter keine Daten zurückliefern, was grob falsch ist. Der Grund für die falsche Abschätzung ist das ?Dynamic Sampling? Feature der Datenbank und der Zustand dieser kleinen Tabellen, die viel mehr Platz allokieren als sie eigentlich müssten / sollten, was dazu führt, dass das ?Dynamic Sampling? nicht gut funktioniert (das Sampling greift nur auf leere Blöcke zu, wenn man Pech hat, da das Segment so viele leere Blöcke beinhaltet) und daher die Abschätzungen so negativ beeinflusst.
Die ?INVISIBLE? Indizes kommen nur daher zum Zuge, da bestimmte Views den Hint ?USE_INVISIBLE_INDEXES? beinhalten ? aber auch ohne Verwendung dieser Indizes sind die Ausführungspläne aufgrund der schlechten Abschätzungen ineffizient.
Eine Reorganisation der
betroffenen Tabellen löst das Problem ? Hinweise werden noch zur Verfügung
gestellt, wie das Problem in Zukunft vermieden werden könnte, indem die
Tabellen auf eine andere Art und Weise gepflegt werden (Vermeiden der
Kombination aus Updates auf komprimierten Daten, Deletes und Insert APPEND).
Zeitraum: Oktober - Dezember 2022
Name des Projekts: Unterstützung
Migration Oracle Datenbank
Lokation: Frankenthal / Polen / Remote
Branche: Logistik, Software
Kurzbeschreibung:
Unterstützung
bei der Vorbereitung und Durchführung der Migration einer bestehenden Logistik
Software von Oracle 11.2.0.4 auf Oracle 19c.
Zeitraum: September 2022
Name des Projekts:
Vortrag
auf der DOAG 2022 Konferenz
Lokation: Nürnberg
Branche:
Konferenzen
Kurzbeschreibung:
Vortrag ?Kostenlos!
Die am wenigsten benutzten Performance Features der Oracle Datenbank? auf der
DOAG Konferenz 2022
Zeitraum: Juni bis September 2022
Name des Projekts: Beratung Entwicklung Archivierungslösung Exadata
Lokation: Frankfurt am Main / remote
Branche: Finanzen / IT
Kurzbeschreibung:
Eine Bank möchte eine Inhouse Lösung zur Archivierung von Applikationsdaten entwerfen, die die Daten in einer Oracle Datenbank auf Exadata mit ZFS Storage speichert. Es soll den Applikationen ein generisches Datenbank-Interface zur Verfügung gestellt werden, das die Archivierung von Oracle Tabellen revisionssicher ermöglicht. Dazu werden verschiedene Oracle Datenbank Features wie ?Immutable Tables? und ?Database Vault? evaluiert.
Zeitraum: Juni 2022
Name des Projekts: Exadata Workshop
Lokation: Oberhausen / remote
Branche: Software
Kurzbeschreibung:
Ausführliche Beschreibung. Demonstration und Diskussion der Oracle Exadata Database Machine in Form eines individuellen Workshops ? Aufbau, Features (Storage Cells, Smart Scans, Flash Cache, Persistent Memory, RoCE, Hybrid Columnar Compression etc.), wann profitiert man von den speziellen Exadata Features, detaillierter technischer Hintergrund, wie die diese Features funktionieren und wie deren Einsatz analysiert und gemessen werden kann.
Zeitraum: Mai 2022
Name des Projekts: DOAG Expertenseminar ?Database Performance: Hands On?
Lokation: Berlin
Branche: User Group / Schulung
Kurzbeschreibung:
Öffentliches Expertenseminar mit folgendem Inhalt:
In diesem Workshop Oracle Database Performance: Hands-on lernen wir anhand verschiedener praktischer Beispiele unterschiedliche Techniken kennen, mit denen Performance in der Datenbank im Detail analysiert werden kann. Es geht dabei um die Antwort auf die Frage, womit die Zeit in der Datenbank verbracht wird und wie dies gemessen werden kann.
Die Teilnehmer führen die Schritte unter Anleitung des Seminarleiters in ihrer eigenen oder einer vorbereiteten Datenbank durch und bekommen dadurch praktische Erfahrung, wie die jeweiligen Techniken funktionieren und was es bei der Anwendung zu beachten gilt.
Zeitraum: Februar ? April 2022
Name des Projekts: Performance Optimierung Oracle 19c (Exadata)
Lokation: Frankfurt / Remote
Branche: Bank
Kurzbeschreibung:
Eine hauseigene Applikation soll auf Exadata migriert werden. Auf der Exadata Umgebung laufen jedoch einfache Updates und Inserts deutlich langsamer als auf den nicht-Exadata Umgebungen. Eine genauere Analyse ergibt, dass hier ?Flashback Database Archive (FBDA)? zum Einsatz kommt und die Verzögerungen hauptsächlich durch die rekursiven Aktivitäten von FBDA verursacht werden. Die Symptome, validiert durch einen SQL Trace, entsprechenden denen im Bug "Bug 31201192 - Hang with 'fbar timer'<='enq: tx - contention' (Doc ID 31201192.8)" beschriebenen. Dem Kunden wird nahegelegt, den verfügbaren Patch als ?Backport? für die eingesetzte Version von Oracle 19c bei Oracle Support zu beantragen.
Desweiteren laufen auf der Exadata bestimmte Import-Prozesse, bei denen aus Applikationssicht nur einfache Batch-Inserts durchgeführt werden, auf der Exadata sehr langsam. Eine Analyse zeigt, dass die Datenbank sich damit beschäftigt, tausende von Child Cursorn für diese Inserts zu erzeugen / zu verwalten. Das Grundproblem besteht in der Verwendung von falschen Datentypen beim Binden von Bind-Variablen von Applikationsseite. Nach Korrektur der Datentypen laufen die Inserts um Faktor 1000 schneller und die Anzahl der Child Cursor reduziert sich auf wenige einzelne.
Zeitraum: März 2022
Name des Projekts: Performance Optimierung Oracle 19c
Lokation: Frankfurt / Remote
Branche: Bank
Kurzbeschreibung:
Umstellung der internen Speichermethode von XML-Daten. Oracle verwendet eigentlich seit Version 11.2 intern die Speichermethode ?Binary XML? für XMLType Daten. Eine Software eines Drittherstellers verwendete jedoch explizit noch die Speichermethode ?CLOB?, was deutlich mehr Platz in der Datenbank belegt. Nach Abklärung mit dem Hersteller wurde ein Migrationskonzept mit automatisierter Umstellung von über 5.000 bestehenden Tabellen erstellt und auch umgesetzt, so dass innerhalb weniger Minuten diese Tabellen auf ?Binary XML? Speichermethode umgestellt wurden ? dazu wurde mittels Create Table As Select (CTAS) eine temporäre Kopie der jeweiligen Tabelle angelegt und die alte Tabelle entsprechend entfernt / ersetzt, automatisiert per Skript. Als Absicherung für den Fall, dass die Migration nicht erfolgreich ist oder nachfolgend Probleme in der Applikation auftreten, wurde die Original-Datenbank (Oracle 19c CDB/PDB Architektur) als PDB-Kopie erhalten.
Zeitraum: März 2022
Name des Projekts: Individual Workshop ?Datenbank Performance für Entwickler?
Lokation: Monheim (Schwaben), Deutschland
Branche: Bank
Kurzbeschreibung:
Workshop ?Datenbank Performance für Entwickler? ? Beschreibung:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um effektiver mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt, eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
- Instrumentierung
- Trace / Row Source Statistics / Active Session History / Real Time SQL Monitoring
- Grundlagen Optimizer, Histogramme, Statistiken (inkl. New Features 12c)
- (serielle) Ausführungspläne richtig lesen
- Indizierung
- Clustering / Speicherformen inkl. New Features 12c: Attribute Clustering / Zonemaps, Heap, Index Organized Tables, Cluster
- Hints
- Bind Variablen / Literale und ungleichmäßige Datenverteilung
- Datenbank Links / Transaktionen / Locks
Zeitraum: Dezember 2021 / Februar 2022
Name des Projekts: Vortrag auf der All Indian Oracle User Group AIOUG Konferenz 2021 / 2022
Lokation: Remote
Branche: Konferenzen
Kurzbeschreibung:
Vortrag ?Oracle Database 21c New Performance Features? auf der Sangam 21 / All Indian Oracle User Group (AIOUG) 2022 Konferenz
Zeitraum: November - Dezember 2021
Name des Projekts: Performance Optimierung Oracle
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
Abfragen in einem Data Warehouse verhalten sich unterschiedlich, je nachdem, wie auf die Partitionen der Daten zugegriffen wird. Bei Verwendung einer einzigen Partition sind die grundsätzlichen Abschätzungen des Optimizers so weit schlüssig, bei Zugriff auf mehrere Partitionen sind die Abschätzungen sehr schlecht. Es stellt sich heraus, dass durch die Verwendung von inkrementellen Statistiken ein Bug entsteht, der die Spaltenstatistiken des Partitionsschlüssels auf globaler Ebene verfälscht, so dass je nach Datenmenge pro Partition völlig falsche Annahmen seitens des Optimizers getroffen werden. Es werden verschiedene Lösungsmaßnahmen besprochen (unter anderem Verhinderung der Erzeugung eines Histogramms) und ein generischer Testcase für Oracle Support vorbereitet, um den Bug nachstellen zu können.
Abfragen, die versuchen, auf bestimmte Partitionen dynamisch einzuschränken per Unterabfrage erreichen nur inkonsistentes Partition Pruning. Da der Kunde bereits auf Oracle 19c ist, wird dieses Problem mittels ?SQL Macros? adressiert, was erlaubt, den Partitionsschlüssel als Literal anzugeben und trotzdem dynamisch zu bestimmen.
Darüber hinaus gibt es noch Probleme mit bestimmten Transformationen seitens des Optimizers (?Group By Placement?), die zu schlechten Abschätzungen und als Folge zu ineffizienten Ausführungsplänen führen. Dies kann durch eine Parametereinstellung verhindert werden.
Zeitraum: November - Dezember 2021
Name des Projekts: Vortrag auf DOAG 2021 und IT Tage 2021 Konferenzen
Lokation: Nürnberg / Frankfurt / Remote
Branche: Konferenzen
Kurzbeschreibung:
Vortrag ?Oracle Database 21c New Performance Features? in auf der DOAG Konferenz 2021 sowie den IT Tagen 2021
Zeitraum: Oktober 2021
Name des Projekts: Vorträge trivadis Performance Days
Lokation: Zürich, Schweiz
Branche: Software
Kurzbeschreibung:
Vorträge im Rahmen der trivadis Performance Days 2021: ?Oracle Datenbank 21c New Performance Features? und ?Oracle Datenbank Indexing Myths?
Zeitraum: Oktober 2021
Name des Projekts: DOAG Expertenseminar ?Datenbank-Performance für Entwickler?
Lokation: Berlin / Remote
Branche: User Group / Schulung
Kurzbeschreibung:
Öffentliches Expertenseminar mit folgendem Inhalt:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um effektiver mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
- Instrumentierung
- Trace / Row Source Statistics / Active Session History / Real Time SQL Monitoring
- Grundlagen Optimizer, Histogramme, Statistiken (inkl. New Features 12c)
- (serielle) Ausführungspläne richtig lesen
- Indizierung
- Clustering / Speicherformen inkl. New Features 12c: Attribute Clustering / Zonemaps, Heap, Index Organized Tables, Cluster
- Hints
- Bind Variablen / Literale und ungleichmäßige Datenverteilung
Zeitraum: September bis Oktober 2021
Name des Projekts: Oracle Datenbank 19c Performance Troubleshooting (Exadata)
Lokation: Berlin / Remote
Branche: Versandhandel
Kurzbeschreibung:
Verschiedene mittels Tableau erzeugte Berichte schwanken stark in der Laufzeit. Es gilt zu ermitteln, ob die Schwankungen maßgeblich durch unterschiedliches Verhalten in der Datenbank verursacht werden oder es andere Gründe außerhalb der Datenbank gibt, wie zum Beispiel Netzwerk oder auch auf Applikationsebene (Tableau Reporting Plattform).
Eine Analyse ergibt, dass die Datenbank zwar teilweise an den unterschiedlichen Laufzeiten beteiligt ist, dies aber nur aufgrund unterschiedlicher Auslastung, aber nicht aufgrund unterschiedlicher Ausführungspläne oder anderer Gründe. Maßgeblich werden die Schwankungen durch die Reporting Plattform verursacht, die sehr stark unterschiedlich lange benötigt, um die bereits von der Datenbank zur Verfügung gestellten Daten abzuholen.
Zeitraum: September 2021
Name des Projekts: Workshop ?Datenbank Performance für Entwickler?
Lokation: Wiesbaden / Remote
Branche: Versicherung / Software
Kurzbeschreibung:
Workshop ?Datenbank Performance für Entwickler? ? Beschreibung:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um effektiver mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt, eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
- Instrumentierung
- Trace / Row Source Statistics / Active Session History / Real Time SQL Monitoring
- Grundlagen Optimizer, Histogramme, Statistiken (inkl. New Features 12c)
- (serielle) Ausführungspläne richtig lesen
- Indizierung
- Clustering / Speicherformen inkl. New Features 12c: Attribute Clustering / Zonemaps, Heap, Index Organized Tables, Cluster
- Hints
- Bind Variablen / Literale und ungleichmäßige Datenverteilung
Zeitraum: August 2021
Name des Projekts: Oracle / MySQL Datenbank Performance Troubleshooting
Lokation: Mainz / Remote
Branche: Software / Banking
Kurzbeschreibung:
Der Export von historischen Daten ist bei einer Standardsoftware sehr langsam, da SQLs pro Datensatz ausgeführt werden, und pro Ausführung mehrere Sekunden an Laufzeit entstehen. Unter MySQL ist die Ausführung nochmal deutlich langsamer als unter Oracle. Eine detaillierte Analyse zeigt, dass die Datenbanken aufgrund der Art und Weise, wie das SQL geschrieben ist, nicht in der Lage sind, die Historie nur für die in Frage kommenden Datensätze zu ermitteln, sondern jeweils die komplette Datenmenge mehrfach pro SQL-Ausführung verarbeiten.
Durch Umformulierung der SQLs (mittels Verwendung von LATERAL Views) wird sowohl Oracle als auch MySQL in die Lage versetzt, die Historie nur für die relevanten Datensätze zu ermitteln, was einer Performance-Steigerung von Faktor 1000 entspricht, da jetzt nur noch wenige Millisekunden für eine einzelne Ausführung benötigt werden, anstatt mehrerer Sekunden.
Zeitraum: August 2021
Name des Projekts: Oracle Datenbank Performance Troubleshooting
Lokation: Oberhaching / Remote
Branche: Software / Logistik
Kurzbeschreibung:
Eine Software verwendet weitgehend noch den Rule Based Optimizer (RBO), der allerdings bei einigen Abfragen schlechte Ausführungspläne produziert. Bei Verwendung des Cost Based Optimizers (CBO) gibt einige wenige SQLs, die wiederum deutlich langsamer sind als bei Verwendung des RBOs. Diese wurden detailliert analysiert und Vorschläge unterbreitet, wie sie ähnlich effizient wie mit dem RBO gestaltet werden können. Es stellte sich heraus, dass die Verwendung von außergewöhnlichen Konstrukten (skalare Unterabfrage in der ORDER BY Klausel) dazu führte, dass der CBO bestimmte Transformationen zur effizienten Umsetzung von OR Klauseln nicht anwendete. Die betroffenen Statements werden jetzt mit einer früheren CBO-Version (OPTIMIZER_FEATURES_ENABLE Hint) betrieben, die das Problem nicht hat und somit trotz Verwendung von skalarer Unterabfrage in der ORDER BY Klausel und OR-Klauseln einen effizienten Ausführungsplan generiert.
Zeitraum: Januar - Juli 2021
Name des Projekts: Anonymisierung ECommerce Applikation
Lokation: Düsseldorf / Remote
Branche: Fashion, Versandhandel
Kurzbeschreibung:
Design und Umsetzung einer automatisierten Anonymisierung und Übertragung der Produktionsdatenbank in Testumgebungen. Die zu maskierenden Felder und die dafür verwendeten Regeln sind konfigurierbar über Metadaten, als auch die resultierende Datenmenge (zum Beispiel nur 10% des Originaldatenbestandes). Die Maskierung erfolgt performanceoptimiert über entsprechend automatisch mittels Metadaten generierte CTAS (Create Table As Select) Operationen, da die Laufzeiten durch die massive Verwendung von XML in der Datenbank eine wichtige Rolle spielen.
Durch entsprechende Optimierung der CTAS Operationen kann die Laufzeit um Faktor 20 bis 40 erhöht werden und damit das Gesamtvolumen an zu maskierenden Daten in unter 24 Stunden verarbeitet werden trotz der komplexen Maskierungsregeln auf XML-Dokument Ebene. Für Bugs, die nach dem Oracle 19c Upgrade eine Verarbeitung aufgrund von PGA Speicherleaks und exzessiver TEMP Allokation unmöglich machten, wurde noch eine iterative Verarbeitung in Teilstücken implementiert, um die Probleme zu umgehen.
Zeitraum: Juli 2021
Name des Projekts: Individual Workshop ?Datenbank Performance für Entwickler?
Lokation: Karlsruhe
Branche: Logistik Software
Kurzbeschreibung:
Individual Workshop ?Datenbank Performance für Entwickler? ? inklusive Analyse von individuellen Problemfällen und Vorschlägen, wie diese verbessert werden können. Dazu noch Vorschläge, wie die Diagnosemöglichkeit von Applikationsseite verbessert werden kann, durch zum Beispiel selektives Aktivieren von SQL Trace und automatisiertes Einsammeln erweiterter Informationen bezüglich Ausführungsplänen.
Zeitraum: Juni 2021
Name des Projekts: DOAG Expertenseminar ?Parallel Execution Masterclass?
Lokation: DOAG (Deutsche Oracle Anwender Gruppe) GmbH, Berlin / remote
Branche: User Group / Schulung
Kurzbeschreibung:
Öffentliches Expertenseminar mit folgendem Inhalt:
- Wie lese ich einen Ausführungsplan richtig? Gibt es besondere Regeln für parallele Ausführungspläne? Und falls ja, wie sehen diese aus?
- Wie führt Oracle so einen Ausführungsplan zur Laufzeit aus?
- Was machen diese ganzen Operationen, die mit PX anfangen, in einem parallelen Ausführungsplan? Was sagen mir die zusätzlichen Spalten, die es nur in einem parallelen Ausführungsplan gibt?
- Wie funktioniert diese automatische parallele Ausführung von SQL Statements zur Laufzeit? Was wird parallelisiert, und wie wird die Arbeit automatisch aufgeteilt? Was kann dabei schiefgehen? Falls etwas schiefgeht, kann ich es beeinflussen, und falls ja, wie?
- Warum sind manchmal parallele Ausführungen nicht viel schneller als serielle, oder sogar langsamer, und warum verbrauchen parallele Ausführungen teilweise so viel mehr PGA-Speicher und/oder TEMP-Speicherplatz wie vergleichbare serielle Ausführungen?
- Wie kann ich eine SQL Statement-Ausführung analysieren, um zu verstehen, warum sie länger braucht als erwartet? Wie setze ich die Diagnostics- und Tuning-Pack License Features optimal in diesem Zusammenhang ein?
- Wie kann ich speziell parallele SQL-Ausführungen analysieren, um zu verstehen, ob Parallel Execution hier überhaupt effizient eingesetzt wird? Warum sind die für serielle Ausführungen bekannten Analyse-Methoden dafür größtenteils ungeeignet?
- Wie kann ich parallele Ausführungen schon beim physischen Datenbank-Design schneller machen?
- Welche neuen Parallel Execution Features sind in Oracle 12c dazugekommen?
Der Workshop vermittelt ausführliche Antworten zu diesen Fragen. Darüber hinaus bietet es Ihnen zu einem großen Teil exklusives Wissen, das von mir selbst erarbeitet wurde. Dieses Wissen werden Sie woanders - auch nicht in den offiziellen Unterlagen und Schulungen von Oracle - finden.
Zeitraum: Juni 2021
Name des Projekts: Oracle Datenbank Performance Troubleshooting
Lokation: Oberhaching / Remote
Branche: Software / Logistik
Kurzbeschreibung:
In einer operativen Datenbank werden bestimmte Berichte erstellt, die eigentlich in einer Data Warehouse Umgebung erstellt werden sollen, derzeit aber nicht erstellt werden können.
Daher sind die Daten in der operativen Datenbank nicht für diese Art von Abfragen optimiert, was Schema Design, Partitionierung und Indizierung angeht.
Aufgrund der nur vorübergehenden Natur (die Berichte sollen dann in absehbarer Zukunft im Data Warehouse erstellt werden) sollen auch keine größeren Anpassungen / Änderungen an der operativen Datenbank durchgeführt werden.
Als Problem stellt sich der Zugriff auf eine größere Tabelle mit Milliarden von Zeilen dar. Durch eine entsprechende Indizierung kann der Tabellenzugriff komplett vermieden werden, was die Laufzeit der relevanten Berichte entsprechend verbessert und Langläufer im Stunden-Bereich verhindert.
Für einen bestimmten Bericht wurde die Generierung der Informationen von einem iterativen Schleifenansatz mit potenziell sehr vielen Wiederholungen auf ein einzelnes SQL umgestellt, das die Daten zuverlässig innerhalb weniger Minuten generiert, was für die Nachtverarbeitung völlig ausreichend ist. Der Schleifenansatz war im Gegensatz dazu schlecht vorhersehbar, was die Gesamtlaufzeit angeht und deutlich langsamer (im Stundenbereich)
Zeitraum: Mai 2021
Name des Projekts: Detailanalyse Feature Usage Standard Edition Lizenz
Lokation: Hamburg / Staufen / Remote
Branche: Lizenzberatung / Labortechnik
Kurzbeschreibung:
Ein Kunde überprüft die Angabe der "Feature Usage" in DBA_FEATURE_USAGE_STATISTICS als Vorbereitung für einen License Audit seitens Oracle. Obwohl der Kunde nur über eine "Standard Edition" Lizenz verfügt und sich an keine aktive und absichtliche Nutzung von Enterprise Edition Features erinnern kann, werden dort sowohl "Real Application Security" als auch "Adaptive Plans" als benutztes Feature angezeigt - welche beide als "Enterprise Edition" Features seitens Oracle geführt werden.
Eine detaillierte Analyse ergibt, dass beide Features bereits bei der Standard-Installation einer 12.2.0.1 Standard Edition als "in use" angezeigt werden, da Oracle entsprechende Objekte in der "Template"-Datenbank mitliefert, die eine Nutzung von "Real Application Security" anzeigen, und auch fälschlicherweise den Parameter "OPTIMIZER_APAPTIVE_PLANS" auf "TRUE" setzt, obwohl dieses Feature in der "Standard Edition" überhaupt nicht zur Verfügung steht.
Insofern sollte der Kunde bezüglich eines Audits seitens Oracle hier auf der sicheren Seite sein.
Zeitraum: Januar - April 2021
Name des Projekts: Data Warehouse Upgrade 19c Troubleshooting (Exadata)
Lokation: Frankfurt am Main / Remote
Branche: Bank
Kurzbeschreibung:
Verschiedene Abfragen verlängern sich signifikant in der Laufzeit nach dem Upgrade von 18c auf 19c und dem Hochsetzen des Parameters OPTIMIZER_FEATURES_ENABLE von ?11.2.0.4? auf ?19.1.0?. Detaillierte Analyse der unterschiedlichen Abfragen mit Vorschlägen, wie funktionierende Workarounds aussehen können. Weitere Probleme unterschiedlichster Natur treten auf, von Planregressionen bis hin zu ORA-Fehlermeldungen beim Parsen sowie falschen Ergebnissen. Unterstützung bei der Zusammenarbeit mit Oracle Support mittels Vorbereitung entsprechender generischer Test Cases. Entwicklung entsprechender Workarounds für die genannten Probleme.
Zeitraum: Februar - März 2021
Name des Projekts: Analyse Performance / Speicherbedarf nach Oracle 19c Upgrade
Lokation: Frankfurt am Main / Remote
Branche: Bank
Kurzbeschreibung:
Nach einem Upgrade von Oracle 12.1 auf 19c gibt es mehrere Performance Probleme sowie Abbrüche in der Verarbeitung aufgrund von unzureichendem PGA Speicher. 19c benötigt signifikant mehr PGA Speicher pro Prozess und die Applikation erzeugt über mehrere Knoten von Application Servern mehrere Connection Pools, was zu einer hohen Grundlast an Prozessen führt. Desweiteren kommt seit der Version 18c einer neuer Speicherbereich zum Einsatz - die sogenannte ?MGA" ? ein Zwitter aus privaten und geteiltem Speicher, da ?Shared Memory? bei Bedarf dynamisch allokiert und zwischen mehreren Prozessen geteilt wird. Diese zusätzliche Speicherkomponente macht insbesondere unter Solaris Probleme, da zur Laufzeit immer wieder Allokationsfehler und damit Abbrüche auftreten können.
Das MGA-Problem kann mittels einiger interner Parameter umgangen werden, um die neue Speicherallokation in dem MGA Bereich zu verhindern.
Durch die erhöhte PGA Allokation unter 19c ist auch eine Anpassung der Parameter PGA_AGGREGATE_TARGET und PGA_AGGREGATE_LIMIT angezeigt, da die Instanz effektiv mehr PGA benötigt als per PGA_AGGREGATE_TARGET zugewiesen.
Die Performance Probleme sind nach entsprechender PGA Parameteranpassung und Erhöhung des physisch zur Verfügung stehenden Speichers auf Host Ebene weitgehend gelöst ? eine Übersicht der Top SQLs, die Potential für effizientere Ausführung haben, wurde zusätzlich geliefert sowie noch einige andere Fragen bezüglich Indizierung, Konfiguration Maintenance Windows, ?Killed Sessions? etc. beantwortet.
Zeitraum: November - Dezember 2020
Name des Projekts: Vortrag auf DOAG 2020 und IT Tage 2020 Konferenzen
Lokation: Nürnberg / Frankfurt / Remote
Branche: Konferenzen
Kurzbeschreibung:
Vortrag ?Oracle Database Performance Tuning: Back To Basics? in auf der DOAG Konferenz 2020 sowie den IT Tagen 2020
Zeitraum: November 2020
Name des Projekts: Oracle Datenbank Performance Troubleshooting
Lokation: Oberhaching / Remote
Branche: Software / Logistik
Kurzbeschreibung:
Eine hoch frequent aufgerufene Schnittstellen-Funktion arbeitet mindestens 12 Sekunden pro Aufruf ? häufig auch länger, was zu einer Warteschlange für die zu verarbeitenden Aufrufe führt. Teilweise müssen solche Aufrufe dann über 20 Minuten in der Warteschlange verbringen, was dann wiederum zu Timeouts in den aufrufenden Systemen führt. Durchschnittlich müssen Anfragen ca. 3 Minuten in der Warteschlange verbringen.
Eine Analyse zeigt, dass ein signifikanter Teil der Verarbeitungszeit in der Datenbank verbracht wird und dort vor allem ein SQL für die Laufzeit maßgeblich verantwortlich ist. Das SQL verwendet einen MINUS Operator, um ein Delta an einzufügenden Daten zu ermitteln. Da in der Zieltabelle Millionen von Datensätzen für diese Operation identifiziert werden und der MINUS Operator eine eindeutige Sortierung dieser Datenmenge benötigt, wird die Laufzeit für diese Sortieroperation maßgeblich über die zu sortierende Datenmenge bestimmt und kann daher nicht ohne weiteres optimiert werden. Leider akzeptiert die Datenbank nicht die automatische Umwandlung der MINUS SET Operation in einen Join (SET_TO_JOIN Transformation), was es erlaubt hätte, ohne Änderung des SQLs diese Umformulierung zu erreichen. Da das SQL aus einem PL/SQL Paket in der Datenbank stammt, ist eine semantisch äquivalente Umformulierung des SQLs von MINUS nach NOT EXISTS technisch möglich, ohne an anderem Quellcode der Applikation Änderungen vornehmen zu müssen. Daher wird dieser Weg eingeschlagen, nachdem mittels entsprechender Tests sichergestellt ist, dass das umformulierte SQL die gleichen Ergebnisse liefert. Da die andere Menge des MINUS Operators in den allermeisten Fällen sehr klein ist, kann der Optimizer aufgrund der Umwandlung des MINUS in einen Join effizientere Zugriffswege verwenden und vor allem die aufwändige Sortierung der großen Datenmenge vermeiden. Das umformulierte SQL benötigt nur noch ca. 3 bis 5 Sekunden zur Ausführung - nach Erzeugung eines geeigneten Index sinkt die Verarbeitungszeit auf Sekundenbruchteile.
Die durchschnittliche Wartezeit von Anfragen nach dieser Änderung sinkt von über 3 Minuten auf 2 Sekunden ? Timeouts treten somit keine mehr auf und die allgemeine Verarbeitungsgeschwindigkeit steigt signifikant an.
Zeitraum: Oktober 2020
Name des Projekts: Performance Analyse Applikation Upgrade Oracle 19c
Lokation: Stuttgart
Kurzbeschreibung:
Performance Analyse der Datenbank-Aktivitäten einer komplexen Auswertungslogik implementiert in PL/SQL nach Upgrade auf Oracle 19c. Einige Abfragen haben sich seit der letzten Analyse im Januar verändert, so dass die vorherig vorgeschlagenen Indizes angepasst werden müssen. Durch Anpassung und Ergänzung geeigneter Indizes kann die Verarbeitungszeit von über 30 Minuten auch für die größten Auswertungen auf unter 10 Minuten reduziert werden, so dass jetzt alle Auswertungen erfolgreich zu Ende laufen und nicht länger als die Timeout-Grenze von 30 Minuten benötigen.
Zeitraum: Oktober 2020
Name des Projekts: Optimizer Workshop
Lokation: Merzig / Remote
Kurzbeschreibung:
Workshop ?Den kostenbasierten Optimizer verstehen? ? grundlegende Prinzipien der Entscheidungsfindung des Optimizers, was kann schief gehen und wie stelle ich das fest, welche Möglichkeiten der Beeinflussung gibt es. Wie liest man Ausführungspläne richtig, wie generiert man Laufzeitprofile von SQL-Ausführungen und wertet diese aus. Wichtige Hinweise, auf was man bei der Statistikgenerierung für den Optimizer achten sollte. Clustering von Daten richtig verstehen und welche Möglichkeiten der Beeinflussung gibt es.
Zeitraum: September 2020
Name des Projekts: DOAG Expertenseminar ?Datenbank-Performance für Entwickler?
Lokation: DOAG (Deutsche Oracle Anwender Gruppe) GmbH, Berlin / remote
Branche: User Group / Schulung
Kurzbeschreibung:
Öffentliches Expertenseminar mit folgendem Inhalt:
Wie holt man die maximale Performance aus der Datenbank? Was kann ich als Entwickler tun, um bestmöglichst mit der Oracle Datenbank zusammenarbeiten zu können? Wir fangen bei der Instrumentierung an, wie sich Performance in der Datenbank überhaupt auf einfache Art und Weise sichtbar und überprüfbar macht, schauen uns anhand von Fallbeispielen, die an realen Fällen aus der Praxis angelehnt sind, wie der Optimizer funktioniert bzw. nicht funktioniert, wie man Ausführungspläne richtig liest und worauf es bei der Erstellung von Statistiken ankommt. Wir beschäftigen uns mit "guten" und "bösen" Hints und wie diese bei der Erstellung von komplexen SQLs hilfreich sein können. Wir schauen uns an, was man bei der Verwendung von Bind-Variablen bzw. statischem SQL in PL/SQL beachten sollte und wie die optimale Mischung aus Literalen und Bind-Variablen aussehen kann. Und natürlich ist eine gute Indizierung und was es dabei zu beachten gibt eines der Hauptthemen. In diesem Zusammenhang schauen wir uns auch an, was Clustering bedeutet, welche Möglichkeiten neuere Oracle-Versionen hier bieten sowie die unterschiedlichen Speicherformen (Heap, Index Organized, Cluster).
Kursinhalte:
Instrumentierung
Trace / Row Source Statistics / Active Session History / Real Time SQL Monitoring
Grundlagen Optimizer, Histogramme, Statistiken (inkl. New Features 12c)
(serielle) Ausführungspläne richtig lesen
Indizierung
Clustering / Speicherformen inkl. New Features 12c: Attribute Clustering / Zonemaps, Heap, Index Organized Tables, Cluster
Hints
Bind Variablen / Literale und ungleichmäßige Datenverteilung
Zeitraum: August 2020
Name des Projekts: Oracle Database Workshop ?12c/18c/19c New Features?
Lokation: Frankfurt am Main / Remote
Branche: Bank
Kurzbeschreibung:
Individual Workshop über relevante neue Features der Oracle Datenbank aus Sicht von Datenbank-Entwicklern / Applikationen, die in den neuesten Versionen hinzugefügt wurden
Zeitraum: Juli 2020
Name des Projekts: Oracle Datenbank 19c Performance Troubleshooting (Exadata)
Lokation: Berlin / remote
Branche: Versandhandel
Kurzbeschreibung:
Nach dem Upgrade von Oracle 12.2.0.1 nach 19c (19.6) einer Data Warehouse Datenbank war die Performance signifikant schlechter. In Testumgebungen ist der Effekt zuvor so nicht aufgetreten. Es handelt sich um eine zwei Knoten RAC Datenbank als PDB auf Exadata (X7-2). Eine Analyse ergab folgende Punkte:
- Verschiedene RAC spezifische Bugs, die zu Hängern im Bereich der Cluster Waits (?gc?) geführt haben, bei denen SQL-Ausführungen zum Beispiel unendlich auf ?gc current request? gewartet haben. Als initialer Workaround wurde das ?read-mostly? RAC feature deaktiviert und nach Verfügbarkeit und Installation entsprechender One-Off Patches, die leider nicht Teil des eingesetzten RUs waren, traten die Hänger nicht mehr auf
- Ein anderer RAC spezifischer Bug, der zu regelmäßigen Crashes der Instanzen geführt hat, wurde auch durch Installation eines entsprechenden One-Off Patches behoben
- SmartScans funktionierten seit der Installation des Cell Firmware Upgrades nicht mehr, da alle Zellen im Database Level Quarantine Mode agierten aufgrund von drei Crashes innerhalb von drei Stunden. Die verursachende SQL-Operation wurde identifiziert und mittels der Analyse des Cell crash Trace Files wurde klar, dass das Problem mit dem Cell Columnar Flash Cache zusammenhängt. Als initialer Workaround wurde dieses Feature deaktiviert, was es erlaubt hat, die Database Level Quarantine zu entfernen ohne dass es zu weiteren Crashs auf Zellenebene kam. Oracle hatte den Bug in der Zwischenzeit auch identifiziert und in einer neueren Version der Firmware behoben, die dann auch installiert wurde.
- Inkrementelle Statistiken funktionierten nicht mehr nach dem 19c Upgrade, da 19c die von 12.2 generierten Synopsen nicht verarbeiten kann, weil ein PL/SQL Fehler in internen Paketen auftritt, was dazu führt, dass effektiv die globalen Statistiken immer neu berechnet wurden anstatt inkrementelle Statistiken zu verwenden. Bisher steht als Workaround nur zur Verfügung, die Synopsen komplett neu zu berechnen, was keine empfehlenswerte Operation bei einem Multi-Terabyte Data Warehouse ist
- Allgemein ist die Performance des RACs in Produktion maßgeblich beeinflusst von einer signifikanten Zunahme an Cluster bezogenen Warteereignissen, insbesondere beträgt die durchschnittliche Wartezeit 50 mal länger in Produktion (40 ms im Vergleich zu 800 ?s) als in Testumgebungen bei vergleichbarer Arbeitslast. Die Root Cause Analyse für dieses unterschiedliche Verhalten ist noch ausstehend zum Zeitpunkt des Schreibens
- Unabhängig vom Upgrade zeigten einige Tabellen sehr merkwürdiges Verhalten in Bezug auf SmartScan Performance und Platzbedarf, was zu sehr schlechter Performance führt ? mehr als 60 Sekunden für einen trivialen, parallelen SELECT COUNT(*) einer 20 GB Partition, der Millionen logische I/Os zusätzlich generiert und dadurch den CPU Verbrauch auf den Compute Nodes nach oben treibt, sowie einen signifikant erhöhten Platzbedarf ? anstatt 20 GB benötigt eine 1:1 Kopie der gleichen Daten mit gleicher Hybrid Columnar Compression (HCC) Kompressionsstufe nur ca. 400 MB, was 50mal weniger ist. Auch die SmartScan Performance auf dieser Kopie lag im erwarteten Bereich unter einer Sekunde. Block dumps zeigten leere HCC Compression Units und Chained Rows. Die derzeit verwendete Kombination aus HCC und Updates scheint die Daten in einem sehr ungünstigen Zustand zu hinterlassen, was Kompression, Chained Rows und Platzbedarf angeht
Zeitraum: Juni 2020
Name des Projekts: Oracle Datenbank Performance Troubleshooting
Lokation: Oberhaching / Remote
Branche: Software / Logistik
Kurzbeschreibung:
Eine Applikation zur Berechnung der optimalen Fahrtrouten von Paketauslieferungen zeigt immer wieder ?Hänger?, bei denen minutenlang Jobs und Abfragen in der Datenbank hängen bleiben, was signifikante Auswirkung auf die gesamte Applikation hat, da die zeitnahe Neuberechnung der Routeninformation gewährleistet sein muss. Dieses Verhalten ist seit einer Datenbereinigungsaktion zu beobachten, bei der Daten aus der Datenbank gelöscht wurden und von der man sich positive Effekte auf die Performance und den Platzbedarf versprochen hat. Die Analyse ergibt, dass es sich um Sperrungen auf der Ebene des sogenannten ?Library Caches? der Oracle Datenbank handelt ? der Cache, der vor allem dazu dient, alle verwendeten Objekte und deren Abhängigkeiten untereinander zu verwalten. Dazu muss man wissen, dass DDL Operationen exklusive Sperrungen auf Library Cache Ebene verursachen, als auch das Neuerstellen von Ausführungsplänen. Die erwähnte Applikation verwendet zum Teil partitionierte Tabellen ? wobei es sich um eine fragwürdige Verwendung davon handelt, da pro Tag fast 600 neue Partitionen erzeugt werden. Das führt auch dazu, dass tagsüber während hoher Aktivität auf dem System es zu ALTER TABLE DDLs kommt, die neue Partitionen anlegen und somit vorhandene SQLs im "Shared Pool" invalidieren. Damit kommt es regelmäßig zu ?Parse-Stürmen?, bei denen SQLs von vielen Sessions gleichzeitig ausgeführt werden, für diese SQLs aber erst wieder neue Ausführungspläne aufgrund der Invalidierung erzeugt werden müssen. In der Vergangenheit ist dies genauso geschehen, allerdings hat das Neuerstellen der Ausführungspläne nicht außergewöhnlich viel Zeit in Anspruch genommen, so dass die Auswirkung insgesamt vertretbar war. Seit der erwähnten Datenbereinigungsaktion verhielt sich der Optimizer aber anders, was dazu führte, dass die Erstellung des Ausführungsplans von SQLs, die die partitionierten Tabellen verwenden, extrem lange dauern kann ? bis zu mehreren Minuten ? und in dieser Zeit andere Sessions, die entweder auch das gleiche SQL versuchen auszuführen oder zu parsen, oder andere Sessions, die einen exklusiven Lock auf ?Library Cache? Ebene auf bestimmte Objekte benötigen, so lange warten müssen, bis für dieses SQL ein Ausführungsplan erstellt wurde. Dies führte zu teilweise extremen Wartesituationen. Ursache für die Verhaltensänderung war ein Feature der Datenbank, bei Einsatz von Parallel Execution beim Erstellen eines Ausführungsplans ?Dynamic Sampling? einzusetzen. Dieses ?Dynamic Sampling? kann bei partitionierten Tabellen eine IN Liste der zu samplenden Partitions-IDs bei Erzeugung der rekursiven Abfrage zur Ermittlung von Selektivitäten verwenden ? bei höheren Sampling-Leveln kann es hier bis 512 Partitionen aufzählen. Die Verhaltensänderung bestand darin, dass der Sampling Level sich von Level 7 auf Level 8 erhöht hat, da die Tabelle insgesamt ca. 65 Millionen Blöcke hat und dies genau die Grenze darstellt, um von Level 7 auf Level 8 bei der automatischen Anpassung des Leves zu gehen. Daher wurden seitdem eben 512 Partitionen aufgelistet anstatt wie bisher nur 256. Dies wiederum hatte zur Folge, dass der Optimizer in einen Bug gelaufen ist beim Erstellen des Ausführungsplans für die rekursive ?Dynamic Sampling? Abfrage (durch Verlängerung der IN Liste), was dann für die minutenlange Verzögerung bei der Erstellung des Ausführungsplans des eigentlich betroffenen SQLs verantwortlich war. Als Workaround wurde eine Kombination aus SQL Plan Baseline und SQL Patch für die SQLs eingeführt, die von dem Problem maßgeblich betroffen waren bzw. die die meiste Auswirkung auf das System hatten, indem sie andere SQLs blockierten. Die Aufgabe der SQL Plan Baseline war die Fixierung des derzeitigen Ausführungsplans, während die Aufgabe des SQL Patches die Deaktivierung von ?Dynamic Sampling? war. Damit trat der beschriebene Effekt für diese SQLs nicht mehr auf. Die generelle, datenbankweite Abschaltung des Features, das die automatische Erhöhung des ?Dynamic Sampling? Levels bewirkt, wurde evaluiert und wird eventuell eingesetzt, sollte sich das Verhalten auch noch auf andere SQLs auswirken, die mit den bereits etablierten Mitteln nicht behandelt werden können ? zum Beispiel SQL Texte, die Literale bzw. variabel lange IN Listen verwenden. Dazu wurde auch evaluiert, in welchem Maße sich die Verwendung von ?Dynamic Sampling? überhaupt derzeit positiv auf die Ausführungspläne auswirkt, um das mögliche Risiko bei Abschalten des Features besser einschätzen zu können.
Zeitraum: Mai 2020
Name des Projekts: Oracle Datenbank Performance Workshop
Lokation: Darmstadt / Remote
Branche: Software
Kurzbeschreibung:
Individual Workshop zu Oracle Datenbank Performance Themen, insbesondere Locking, Parallelisierung, Indizierung, Analysemöglichkeiten innerhalb der Datenbank
Zeitraum: Mai 2020
Name des Projekts: Exadata Workshop
Lokation: Merzig / remote
Branche: Pharma
Kurzbeschreibung:
Ausführliche Beschreibung. Demonstration und Diskussion der Oracle Exadata Database Machine in Form eines individuellen Workshops ? Aufbau, Features (Storage Cells, Smart Scans, Flash Cache, Persistent Memory, RoCE, Hybrid Columnar Compression etc.), wann profitiert man von den speziellen Exadata Features, Analyse des Istzustands und Bewertung in Bezug auf Nutzungsmöglichkeiten / mögliche Vorteile eines Umstiegs auf Exadata sowie mögliche notwendige Anpassungen der derzeitig etablierten Prozesse (Backup, High Availability etc.) als auch Migrationsstrategien.
Zeitraum: April 2020
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Frankfurt am Main / remote
Branche: Bank
Kurzbeschreibung:
Eine Applikation (Batch Verarbeitung) wird in Produktion immer langsamer ? nach Migration auf ein neues System vor einiger Zeit waren es noch wenige Stunden, aktuell sind es für einen Verarbeitungslauf über 12 Stunden.
Eine detaillierte Analyse zeigt, dass die Applikation zwei ungünstige Ansätze kombiniert: Die häufige Ausführung von Einzel-SQLs und dabei die Verwendung von Literalen anstatt Platzhaltern / Bind Variablen. Da noch die Version 12.1.0.2 ohne deaktivierte adaptive Optimizer Features zum Einsatz kommt, werden bei der Erstellung von Ausführungsplänen sehr viele SQL Plan Directives angewendet, die zu sehr viel rekursiven Dynamic Statistics / Sampling Abfragen führen. Im Endergebnis verbringt die Datenbank mehr als 95% der Datenbankzeit mit Parse / Erstellung von Ausführungsplänen, und weniger als 5% der Datenbankzeit mit der eigentlichen SQL-Ausführung.
Als mögliche Abhilfe bietet sich die Einstellung CURSOR_SHARING=FORCE an, um die Literale automatisch von der Datenbank durch Bind Variablen ersetzen zu lassen und damit das permanente Neuerstellen von Ausführungsplänen zu unterbinden. Nachdem Bugs bei der Parametrisierung überwunden wurden (Parametereinstellung für CURSOR_SHARING=FORCE auf CDB-Ebene wird nicht auf PDB-Ebene angewendet) sinkt die Laufzeit von über 12 Stunden auf 12 Minuten (!) bei Einsatz von CURSOR_SHARING=FORCE.
Zeitraum: April 2020
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Frankfurt am Main / remote
Branche: Bank
Kurzbeschreibung:
Der Umzug einer bestehenden Datenbank auf neue Hardware bedingt durch einen Wechsel des Betriebssystems von RHEL 6 nach RHEL 7 zeigt deutlich schlechtere Laufzeiten als in der bisherigen Umgebung, obwohl laut Provider gleiche Ressourcen zur Verfügung stehen in Hinblick auf CPU, Speicher und Storage. Da es sich auf dem neuen System um eine Binärkopie der Datenbank mit identischer Parametrisierung handelt, kann man Einflüsse durch Unterschiede im Bereich der Parametrisierung, physischen Speicherung der Daten und Statistiken ausschließen. Ein detaillierter Vergleich von Verarbeitungen auf Ausführungsplanebene zwischen den beiden Umgebungen alt und neu zeigt, dass bei gleicher zu verarbeitender Datenmenge und identischem Ausführungsplan ein signifikanter Unterschied im I/O Bereich besteht ? das neue System ist nachweislich deutlich langsamer bei den I/O Operationen, die von der Datenbank ausgeführt werden.
Eine genauere Untersuchung der Konfiguration auf Betriebssystem-Ebene zeigt, dass das neue System ?vxfs? (Symantec Veritas Filesystem) für die Datenbank-Filesysteme verwendet, im Gegensatz zum alten System, das ?ext4? verwendet. Eine detaillierte Auswertung mittels ?iostat? zeigt eine durchgängige Auslastung nahe 100% der entsprechenden Devices.
Ein testweiser Einsatz des von Symantec empfohlenen ?ODM? (Oracle Disk Manager) Moduls zeigt noch schlechtere I/O Performance. Um ?vxfs? als Problemverursacher auszuschließen, wird empfohlen ebenfalls ?ext4? in der neuen Umgebung als Filesystem einzusetzen.
Nach Umstellung in der neuen Umgebung auf ?ext4? ist die Performance der Testläufe vergleichbar, in Teilen sogar besser als in der alten Umgebung ? die Verwendung von ?vxfs? hat sich in dieser Umgebung also nachweislich negativ auf die I/O Performance der Datenbank ausgewirkt.
Zeitraum: März 2020
Name des Projekts: Performance Workshop Oracle 12.2
Lokation: Merzig / remote
Branche: Pharma
Kurzbeschreibung:
Online Workshop zur Klärung verschiedener Performance relevanter Fragen, wie zum Beispiel das Handling einer sehr volatilen Tabelle, die über Tag signifikant den Inhalt ändert, insbesondere die Datenverteilung verschiedener Status-Indikatoren, die am Ende des Tages alle im Status ?verarbeitet? sind, aber tagsüber sich in verschiedenen Phasen der Datenverteilung befinden. Wie und wann sollen die Statistiken idealerweise erzeugt werden, um dem Oracle Optimizer zu ermöglichen, gute Abschätzungen für die kritischen Abfragen auf solchen Tabellen zu machen und damit effiziente Ausführungspläne zu erzeugen. Weitere Fragen zum Umgehen mit SQL Plan Baselines und SQL Profiles ? gibt es im Detail Unterschiede, insbesondere bei der Verwendung von Virtual Private Database (VPD) / Row Level Security (RLS) / Fine Grained Access Control (FGAC). Unterschiede beim Erzeugen von Statistiken bei der Behandlung von laut Statistik nicht existenten Werten ? Bucket Size von Histogrammen und Estimate_Percent / Verwendung des mit Oracle 11g eingeführten ?Approximate NDV? Algorithmus können hier große Unterschiede erzeugen, da die neuen Top Frequency Histogramme solche Fälle anders handhaben bezüglich der Abschätzungen des Optimizers.
Zeitraum: Juni 2019 - März 2020
Name des Projekts: Datawarehouse Performance Beratung
Lokation: Wiesbaden
Branche: Versicherung / Software
Kurzbeschreibung:
Die neue Generation eines DWHs verwendet eine doppelt temporale Speicherung der Daten (technische und fachliche Gültigkeiten). Durch diese hohe Komplexität ergeben sich große Herausforderungen, die Daten in angemessener Zeit zu verarbeiten, da die Umsetzung der Anforderungen zur temporären Vervielfachung der Datenmenge führt, sowie relativ komplexes SQL erfordert, das ungünstig für eine relationale Datenbank zu verarbeiten ist. Erster Schritt der Analyse besteht darin, die Verarbeitung auf SQL-Ebene im Detail zu analysieren, um aufzuzeigen, welche Verarbeitungsschritte besonders kostspielig sind und welche Laufzeiten überhaupt realistisch auf der gegebenen Hardware möglich sind bzw. welche Hardwareausstattung notwendig sein könnte, um die gewünschte Verarbeitungsgeschwindigkeit zu erreichen.
Zeitraum: Januar 2020
Name des Projekts: Performance Analyse Applikation Upgrade Oracle 12cR2
Lokation: Stuttgart
Branche: Bank
Kurzbeschreibung:
Performance Analyse der Datenbank-Aktivitäten einer komplexen Auswertungslogik implementiert in PL/SQL nach Upgrade auf Oracle 12cR2. Der Code ist über die Zeit gewachsen, nicht für die jetzt zu verarbeitende Datenmenge entworfen und verwendet komplexes ?Row by Row? Processing in PL/SQL mit rekursiven Abfragen, die teilweise pro Zeile ausgeführt werden und ist daher nur sehr begrenzt skalierbar. Außerdem leiden die Ausführungspläne einiger rekursiver Abfragen an den bekannten Problemen verursacht durch ?Bind Variable Peeking? und dadurch Verwendung ungünstiger Ausführungspläne. Durch Erzeugung einiger geeigneter Indizes und Verwendung entsprechender Hints kann die Verarbeitungszeit von über 30 Minuten auch für die größten Auswertungen auf unter 10 Minuten reduziert werden, so dass jetzt alle Auswertungen erfolgreich zu Ende laufen und nicht länger als die Timeout-Grenze von 30 Minuten benötigen.
Zeitraum: November - Dezember 2019
Name des Projekts: Vortrag auf DOAG 2019 und IT Tage 2019 Konferenzen
Lokation: Nürnberg / Frankfurt
Branche: Konferenzen
Kurzbeschreibung:
Vortrag ?Oracle Database Indexing Best Practices? in Nürnberg auf der DOAG Konferenz 2018 sowie den IT Tagen 2018 in Frankfurt
Zeitraum: November - Dezember 2019
Name des Projekts: Datawarehouse Performance Beratung
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
Berichtserstellungen in einem DWH benötigen mehrere Minuten Laufzeit. Verwendet wird ein Snowflake Schema. Als Hardware kommt eine virtualisierte AIX-Umgebung zum Einsatz. Auffällig ist die sehr hohe CPU-Zeit, die in Hash Joins verbracht wird und relativ langsamer I/O, insbesondere beim Zugriff auf TEMP. Die allgemeine Konfiguration der Datenbank ist optimierbar ? sowohl SGA, aber auch PGA sind zu klein konfiguriert ? desweiteren stehen nur geringe CPU-Kapazitäten garantiert zur Verfügung, daher arbeitet das System häufig CPU gebunden. Es wird kein Concurrent I/O eingesetzt, was zu hoher Kernel-Zeit auf O/S Seite und vor allem geringen I/O Durchsätzen führt. Eine Umstellung auf Concurrent I/O erhöht den I/O Durchsatz um den Faktor 6 bis 10 ? die Auswirkungen des Verlusts des Filesystem Caches muss beobachtet und die SGA entsprechend angepasst werden. Die SMT-Fähigkeiten und die geringere Single-Thread Performance wird durch moderate Parallelausführung versucht auszugleichen. Berichte werden mit einem Teil der Maßnahmen in ca. 30 Sekunden ausgeführt.
Zeitraum: September 2019
Name des Projekts: Performance Troubleshooting Oracle 12c (Exadata)
Lokation: Frankfurt
Branche: Software
Kurzbeschreibung:
Berichte über ?Tableau? laufen sehr lange (bis zu fünf Minuten pro Abfrage), obwohl eigens dafür Materialized Views aufbereitet werden. Ziel ist eigentlich, Berichte innerhalb weniger Sekunden erzeugen zu können.
Eine Analyse ergibt, dass das Problem im Zusammenspiel der Aktualisierung der Materialized Views mit den speziellen Eigenschaften der Exadata liegt ? die Aktualisierung dauert sehr lange (bis zu zwei Stunden und alle zwei Stunden findet eine erneute Aktualisierung statt), und diese findet auf konventionellem Weg (Full Refresh ?Atomic?), so dass zuerst per DELETE alle Zeilen aus dem Materialized View entfernt und dann per konventionellem INSERT wieder geschrieben werden. In dieser Zeit kann der Smart Scan der Exadata die gelesenen Blöcke nur an die Compute Nodes zurückliefern, da für alle Zeilen Informationen aus dem Undo-Bereich der Datenbank gelesen werden müssen.
Ein Test der neuen ?Out-Of-Place? Refresh Option ergibt weiterhin Laufzeitprobleme durch unerwartete Transformationen der dem Materialized View zugrunde liegenden Abfrage und Fehler aufgrund von Restriktionen der Option (unter anderem werden keine LOB-Spalten unterstützt).
Daher wird die Idee mittels einer Proof-Of-Concept Implementierung aufgezeigt, eine eigene Umsetzung eines funktionierenden und performanten ?Out-Of-Place? Refreshs zu realisieren, bei der ein sinnvoller Ausführungsplan beim Full Refresh zum Einsatz kommt und außerdem LOB-Spalten unterstützt werden.
Die generische Implementierung basiert darauf, eine zweite, ?dummy?-partitionierte Tabelle strukturgleich zu der Basistabelle des Materialized Views anzulegen, diese basierend auf der Materialized View Abfrage zu befüllen und abschließend per Exchange Partition Operation mit der Basistabelle auszutauschen.
Dies funktioniert in ersten Tests sehr gut ? die Aktualisierung dauert nur 10 Minuten anstatt über eine Stunde - inklusive Erneuerung der Statistiken - und die Berichte sind in dieser Zeit weiterhin schnell innerhalb weniger Sekunden erzeugt, da die Smart Scans auf der Basistabelle des Materialized Views wie gewünscht funktionieren.
Zeitraum: August 2019
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
Eine DWH-Anwendung ermittelt derzeit die globalen Statistiken auf für die eingesetzte Hardware großen, partitionierten Tabellen (mehrere Terabyte) nur für indizierte Spalten (FOR ALL INDEXED COLUMNS), was aufgrund der fehlenden Spaltenstatistiken für die Mehrzahl der Spalten zu signifikanten Fehlabschätzungen des Optimizers beim Erstellen von Ausführungsplänen führen kann. Eine testweise Umstellung auf ?FOR ALL COLUMNS SIZE AUTO? führt zu extrem langen Laufzeiten. Eine genauere Analyse zeigt auf, dass die Datenbank ein fragwürdiges Verhalten beim Erstellen von Histogrammen an den Tag legt ? im Spezialfall von Spalten, die nur eine Ausprägung und fast nur NULL-Werte haben, wird eine unnötige, separate Abfrage über die gesamte Tabelle ausgeführt, um das Histogramm zu ermitteln. Dies ist in mehrerer Hinsicht unnötig, da erstens auf einer solchen Spalte kein Histogramm erzeugt werden sollte, da es keinen Mehrwert an Information bietet und zweitens die Hauptabfrage zur Ermittlung der Statistiken seit Oracle12c bereits alle benötigten Informationen einsammelt, die separate Abfrage also nicht notwendig ist. Da es sich um Oracle 12.1 handelt, wird derzeit die Option, inkrementelle Statistiken für die Ermittlung der globalen Statistiken zu verwenden, aufgrund der vielen Bugs dieses Features nicht in Betracht gezogen. Durch Setzen passender METHOD_OPT-Präferenzen mittels DBMS_STATS.SET_TABLE_PREFS zum Verhindern der unnötigen Histogrammerstellung der betroffenen Spalten (eine Ausprägung, überwiegend NULLs) kann die Laufzeit der globalen Statistiken auf ein vertretbares Maß reduziert werden. Bei Oracle ist ein Bug in Bearbeitung bezüglich des fragwürdigen Verhaltens, das auch noch in der aktuellsten Version (19c) reproduziert werden kann.
Zeitraum: Juli 2019
Name des Projekts: Workshop ?Den kostenbasierten Optimizer verstehen?
Lokation: Ulm
Branche: Software / Healthcare
Kurzbeschreibung:
Durchführung meines mehrtägigen Workshops ?Den kostenbasierten Optimizer verstehen? mit individueller Anpassung auf Kundenwünsche und -fragen.
Zeitraum: Juli 2019
Name des Projekts: Workshop ?Exadata für Anwendungsentwickler?
Lokation: Stuttgart
Branche: Bank
Kurzbeschreibung:
Durchführung meines mehrtägigen Workshops ?Exadata für Anwendungsentwickler?.
Zeitraum: Mai 2019
Name des Projekts: Datenbank Performance Review
Lokation: Breslau, Polen
Branche: Software
Kurzbeschreibung:
Review einer bestehenden Cloud-Applikation mit Oracle-Datenbank als Backend. Nach Migration zu einem neuen Storage mit Verschlüsselung wird langsameres I/O beobachtet. Detailanalyse des I/Os auf Betriebssystem Ebene mittels iostat, Kernel Stack Profiling und ?blktrace?, um andere Seiteneffekte auszuschließen. Überprüfung der verwendeten Parameter zur Statistikerstellung in der Datenbank und Empfehlungen für Verbesserungen, unter anderem Data Dictionary Statistiken regelmäßig zu aktualisieren. Top SQLs im Detail analysiert mit Vorschlägen, wie CPU und I/O durch optimierte Indizierung eingespart werden kann. Analyse mittels Active Session History, welche Appliationsteile am meisten CPU auf der Datenbank verbrauchen, um Einsparungspotentiale in Bezug auf Lizenzen einschätzen zu können. Weiteres Optimierungspotential aufgezeigt, unter anderem Abschalten des Space Advisor Tasks.
Zeitraum: April 2019
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
Eine Batchverarbeitung zur Maskierung von Daten nach dem Klonen von Produktionsdaten in andere Umgebungen läuft fast 24 Stunden. Ein Großteil der Verarbeitungszeit wird damit verbracht, Partitionen von Tabellen vor dem eigentlichen Maskieren zu dekomprimieren, da die Tabellen mit BASIC Compression komprimiert sind, und nach dem Update wieder zu komprimieren / Indizes neu zu erstellen etc.
Es wird nach Wegen gesucht, wie die Maskierung beschleunigt werden kann. Es werden hier zwei Ansätze verfolgt: Erstens wird die aktuelle Implementierung signifikant beschleunigt, da über 60% der Verarbeitungszeit mit zwei Tabellen verbracht wird, und diese haben mehr als 254 Spalten. Obwohl eigentlich mit Oracle 12c die Komprimierung von Tabellen mit mehr 254 Spalten mittels Basic/Advanced Compression möglich sein soll, ist dies aufgrund eines Bugs in der Version 12.1.0.2 mit aktuellen PSUs nur noch unter bestimmten Umständen möglich. Daher sind diese Tabellen derzeit effektiv nicht komprimiert und die aufwändigen Vor- und Nachverarbeitungsschritte können eingespart werden. Somit kann die Laufzeit um ca. 12 Stunden reduziert werden. Zweitens wird eine alternative Implementierung der Maskierung eingeführt, die die Maskierung per CTAS Operation durchführt. Mittels dieser Implementierung wird die Tabellenkopie gleich komprimiert angelegt und der Dekomprimierungs- und Updateschritt kann eingespart werden. Sobald auf eine neuere Version von Oracle aktualisiert wird, die die Komprimierung der breiten Tabellen erlaubt (ab 12.2 wieder möglich), kommt dann diese neue Implementierung zum Einsatz, die ca. 40% - 50% der derzeitigen Laufzeit einsparen können sollte.
Zeitraum: Februar - März 2019
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
Eine batchorientierte Massendaten-Verarbeitung in einer Produktionsumgebung zeigt stark schwankende, aber auch trendweise steigende Laufzeiten. In einer weiteren Umgebung mit praktisch identischem Datenbestand, identischer Hardware-Konfiguration bezüglich CPU und RAM, aber nominell langsameren Storage werden bessere Laufzeiten erreicht. Eine Analyse zeigt, dass die CPU-Performance auf der Produktionsumgebung um bis zu zehn Prozent schwankt und vor allem die Performance des Log Writers einen signifikanten Flaschenhals darstellt (da die Datenbank im FORCE LOGGING-Modus betrieben wird und viele Direct Path-Operationen wie INSERT APPEND und CREATE TABLE AS SELECT verwendet werden) ? insbesondere ist der Schreibdurchsatz des Log Writers deutlich schlechter in Produktion als in der Vergleichsumgebung. Eine genauere Analyse zeigt, dass für den Log Writer nur eine LUN verwendet wird, die auch noch in ein anderes Rechenzentrum gespiegelt ist und daher unter längeren Latenzen leidet. Nach Umkonfiguration und Verwendung mehrerer LUNs für den Log Writer ist ein deutlich höherer Schreibdurchsatz des Log Writers und eine signifikante Laufzeitverbesserung für einige der Batchläufe messbar. Darüber hinaus wurden verschiedene Ineffizienzen bei der Verarbeitung durch die Applikation herausgearbeitet und entsprechende Verbesserungsvorschläge mit dem Hersteller diskutiert (Effizientere Ausführungspläne, weniger gegenseitiges Sperren etc.)
Zeitraum: Januar - März 2019
Name des Projekts: Performance Analyse ECommerce Applikation
Lokation: Düsseldorf
Branche: Fashion, Versandhandel
Kurzbeschreibung:
Umfassende Analyse der Infrastruktur, AIX Datenbankserver, Storage (NetApp), Netzwerk und Applikation. Allein durch korrekte Konfiguration und sinnvolle Nutzung der vorhandenen Ressourcen konnte die Anzahl der physischen I/O Anfragen auf Datenbankebene um 90% und die Datenbank-Zeit um 70% reduziert werden. Die Laufzeit einer kritischen Nachtverarbeitung reduzierte sich dadurch von 9 auf unter 6 Stunden. Die Analyse konnte auch Engpässe sowohl im CPU-Bereich des Datenbank-Servers als auch bei der Konfiguration der Datenbank im Bereich von AIX Concurrent I/O aufzeigen. Weitere Analysen auf Applikationsebene folgen ? im Bereich Indizierung, insbesondere von XML, Caching von LOBs, Transaktionsrate und Optimierung von SQLs.
Zeitraum: Dezember 2018
Name des Projekts: Vortrag auf DOAG 2018 und IT Tage 2018 Konferenzen
Lokation: Nürnberg / Frankfurt
Branche: Konferenzen
Kurzbeschreibung:
- Vortrag ?Oracle Optimizer System Statistiken Update 2018? in Nürnberg auf der DOAG Konferenz 2018 sowie den IT Tagen 2018 in Frankfurt
Zeitraum: Oktober - November 2018
Name des Projekts: Performance Analyse Applikation Upgrade Oracle 12cR2
Lokation: Stuttgart
Branche: Bank
Kurzbeschreibung:
- Performance Analyse der Datenbank-Aktivitäten einer komplexen Java Spring Batch Applikation nach Upgrade auf Oracle 12cR2, Verwendung des aktuellen Optimizers (OPTIMIZER_FEATURES_ENABLE = 12.2.0.1) und Abschalten von SQL Plan Baselines (stammen noch vom Upgrade auf Oracle 11.2). Ein Langläufer wird durch die Art und Weise, wie Statistiken während einer BatchVerarbeitung erzeugt werden, verursacht. Dabei verhält sich Oracle fragwürdig, da das Fehlen / Erzeugen von globalen Statistiken bestimmte Mengenabschätzungen (Aggregationsschritt GROUP BY) beeinflusst, obwohl hier ganz klar ansonsten auf Einzel-Partitionsebene gearbeitet wird und diese Statistiken auf Partitionsebene relevant sein sollten. Durch Anpassung der Statistikerzeugung auf globaler Ebene kann der Langläufer vermieden werden.
- Weitere Überprüfung und allgemeine Beratung bezüglich der neu aufgesetzten 12cR2 Umgebungen
Zeitraum: Oktober 2018
Name des Projekts: Data Warehouse Upgrade 18c Troubleshooting (Exadata)
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
- Performancetests einer komplexen Data Warehouse Applikation nach Upgrade auf 18c auf Exadata. Es werden verschiedene Regressionen beobachtet. Diese beruhen auf unterschiedlichen Effekten:
- Parallele Ausführungen von Pipelined Table Functions unter der Verwendung von Object Views und abgeleiteten Objekttypen führt zu extremer Latch Contention unter 18c => neuer Bug, der von Oracle gefixt wurde.
- Langlaufende Statistik-Erzeugung als Teil der ETL Verarbeitung. Offensichtlich wird die ?STALENESS? von Objekten seit Oracle 12.2 / 18c anders gehandhabt als in 12.1 und früher. Durch die Verwendung des internen Pakets DBMS_STATS_INTERNAL und dessen Funktion IS_STALE als Teil der entsprechenden Views werden in 18c Objekte als STALE markiert / angezeigt, die in vorherigen Versionen nicht als STALE auftauchen (FLAGS werden unterschiedlich interpretiert). Dies betrifft vor allem auch ältere Partitionen / Tabellen, die schon seit sehr langer Zeit nicht mehr verändert wurden. Dies wird gerade mit Oracle Support abgeklärt und die passende Vorgehensweise besprochen.
Zeitraum: September 2018
Name des Projekts: Data Warehouse ETL Performance Troubleshooting (Exadata)
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
- Ein kritischer Transformationsschritt innerhalb einer Data Warehouse Applikation benötigt nach einer strukturellen Änderung mehr als eine Stunde, teilweise mehrere Stunden. Eine Analyse ergibt, dass der Ausführungsplan durch Fehlabschätzungen ineffizient ist. Außerdem treten hier verschiedene Bugs der Oracle-Software zu Tage. Zum Einen führt der Einsatz von Dynamic Sampling auf Statement-Ebene zu komplett falschen Mengenabschätzungen, zum Anderen tritt je nach Strukturierung des Statements mittels NO_MERGE-Hints ?Invalid Number?-Fehler auf, die mit der Evaluierung von PL/SQL-Funktionen zusammenhängen. Durch gezielten Einsatz von Dynamic Sampling auf Tabellenebene zur Verbesserung der Mengenabschätzungen, Restrukturierung mittels geeigneter NO_MERGE-Hints und Optimierung der Datenverteilung bei Parallelverarbeitung kann die Laufzeit auf 90 Sekunden verringert werden.
Zeitraum: August 2018
Name des Projekts: "Exadata für Anwendungsentwickler" Workshop
Lokation: Wien, Österreich
Branche: Software
Kurzbeschreibung:
- Schulung der Datenbank-Entwickler bezüglich der speziellen und für Anwendungsentwickler relevanten Eigenschaften der Oracle Exadata Database Machine: Offloading / Smart Scan Einführung und Vertiefung / Details, Flash Cache, Hybrid Columnar Compression. Analyse des Aktivitätsprofils der Applikationen in Bezug auf inwieweit von Exadata Features profitiert werden kann bzw. wo die Anwendung diesbezüglich angepasst werden sollte.
Zeitraum: Juli 2018
Name des Projekts: Application Architectural Review
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
- Unterstützung beim Review einer bestehenden Applikation zur Entscheidungsfindung bezüglich einer möglichen Weiterentwicklung und erweiterten Verwendungszwecks
Zeitraum: Juli 2018
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Frankfurt
Branche: Bank
Kurzbeschreibung:
- Die Laufzeit für Testläufe in einer Testumgebung dauern signifikant länger als vergleichbare Läufen in Produktion bei ähnlicher Datenmenge und -verteilung. Auch wenn längere Laufzeiten aufgrund unterschiedlicher Hardware erwartet werden, sind die Unterschiede deutlich größer als erwartet. Bei näherer Betrachtung sind mehrere Unterschiede in der Konfiguration der Testumgebung festzustellen:
- Der Buffer Cache wurde von Oracle aufgrund der Verwendung von MEMORY_TARGET (Sparc Solaris) und keinerlei Festlegung von Untergrenzen sehr klein konfiguriert, desweiteren steht noch mehr Speicher zur Verfügung
- Die ZFS ARC Konfiguration ist fraglich (Cache Größe fix auf 10 GB begrenzt)
- Die Parallelisierungsoptionen in der Applikation verwenden nur die Hälfte an Ressourcen verglichen mit Produktion, obwohl ausreichend Kapazität vorhanden ist
Empfehlung, diese fraglichen Konfigurationen anzupassen, also SGA vergrößern, Buffer Cache Untergrenze festlegen, ZFS ARC Cache-Einstellungen korrigieren und Parallelisierung nach oben anpassen
Zeitraum: Juni 2018
Name des Projekts: Performance Troubleshooting Oracle 12c
Lokation: Vilnius, Litauen
Branche: Bank
Kurzbeschreibung:
- Die Performance einer gekauften Software ist nicht adäquat bei der vom Kunden angedachten Datenmenge. Auf einer Testumgebung laufen einige Abfragen, auf die Endbenutzer warten müssen, für mehrere Minuten. Durch die Optimierung der Indizierung reduziert sich die Laufzeit dieser Abfragen auf zwei bis acht Sekunden, allerdings werden diese teilweise mehrfach ausgeführt, bis die Anzeige für den Endbenutzer aktualisiert ist. Weitere Optimierungen sind nur durch Applikationsänderungen und Umschreiben der SQLs möglich. Entsprechend detailliertes Feedback an Vendor mit konkreten Änderungsvorschlägen wurde erstellt.
Zeitraum: Juni 2018
Name des Projekts: Vortrag DOAG 2018 Exa & Middleware Days Konferenz
Lokation: DOAG Frankfurt
Branche: Anwendergruppe
Kurzbeschreibung:
- Vortrag ?Exadata & InMemory Real World Performance? in Frankfurt auf den DOAG 2018 Exa & Middleware Days.
Zeitraum: Mai 2018
Name des Projekts: Performance Troubleshooting Oracle 12c
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Performance-Probleme und Abbrüche durch nicht ausreichenden TEMP-Space einer selbstentwickelten Applikationserweiterung können leicht auf das fehlende Statistik-Management zurückgeführt werden. Tabellen werden dynamisch erzeugt und per Batch befüllt ? allerdings werden die Statistiken nur im ersten Schritt von Oracle 12c automatisch erzeugt, aber in weiteren Schritten mehr Daten hinzugefügt, ohne dass die Statistiken aktualisiert werden. Dies führt dazu, dass die im ersten Schritt erzeugten Statistiken nicht mehr repräsentativ für die Daten sind. Durch Aktualisierung der Statistiken zum richtigen Zeitpunkt sinkt die Laufzeit wieder auf wenige Sekunden und es gibt keine Abbrüche mehr.
Zeitraum: April 2018
Name des Projekts: "Oracle Entwickler Training" Workshop (Exadata)
Kunde: myToys.de, Berlin
Branche: Versandhandel
Kurzbeschreibung:
- Schulung der Datenbank-Entwickler bezüglich verschiedener Themen: Schulung der Datenbank-Entwickler bezüglich verschiedener Themen: Parallel Execution Skew, Exadata Besonderheiten, Optimizer und Partitionen, Statistiken.
Zeitraum: April 2018
Name des Projekts: Performance Troubleshooting
Kunde: State Street, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Optimierung eines weiteren Applikations-Workflows. Durch Anlage / Veränderung passender Indizes kann die Antwortzeit einer GUI für typische Benutzeraktivitäten von sehr langsam (mehr als 20 Sekunden, teilweise mehr als eine Minute) auf gut benutzbar (ein bis drei Sekunden) verbessert werden.
Zeitraum: Januar-März 2018
Name des Projekts: Performance Troubleshooting Oracle 12c (Exadata)
Kunde: d-fine, Frankfurt
Branche: Software
Kurzbeschreibung:
- Eine neu entwickelte Applikation zeigte für verschiedene Applikationsteile unerwartet schlechte Laufzeiten für Abfragen. Eine Analyse zeigte verschiedene Problemfelder auf:
- Das Statistikmanagement war unklar, unterschiedliche Jobs, die zum Teil auch noch überlappend liefen. Diese Jobs kamen aber nie zu Ende, da durch einen Bug mit Inkrementellen Statistiken eine rekursive Abfrage auf Metadaten nicht zu Ende lief, daher waren auf vielen Tabellen Statistiken veraltet
- Fragwürdiges Partitionierungskonzept. Zu viele und zu kleine bzw. zu unterschiedlich große Partitionen. Diese Partitionen waren auch noch mit HCC komprimiert. Dadurch wurde kein Smart Scan aktiviert, zusätzlich war der konventionelle Scan durch die Komprimierung sehr langsam. Desweiteren merkwürdiges Verhalten mit extremen Overhead bei Full Scans durch die hohe Anzahl an Partitionen
- Schlechte Mengenabschätzungen des Optimizers verursacht durch temporales Design und entsprechender komplexer Filterprädikate
- Zeitweise Sperrungen auf Library Cache Level durch Mischung von häufigem DDL und DML
- Stark schwankende Smart Scan Performance durch temporäre Überlast auf dem Exadata Host.
Für jedes Problemfeld wurden Lösungen / Verbesserungen vorgeschlagen und diskutiert. Das Statistikmanagement wurde aufgeräumt und Inkrementelle Statistiken deaktiviert, eine alternatives Partitionskonzept besprochen, das auch das Library Cache Lock-Problem lösen sollte und für komplexe Ausdrücke, die nicht durch erweiterte Statistiken abgedeckt werden können wurde die Verwendung von Dynamic Sampling vorgeschlagen. Die DBAs / System Administratoren konnten mit Hilfe der zur Verfügung gestellten Analyseergebnisse auch die Ursache für die temporäre Überlastung des Exadata Host Systems identifizieren.
Zeitraum: Februar 2018
Name des Projekts: "Oracle Entwickler Training" Workshop (Exadata)
Kunde: myToys.de, Berlin
Branche: Versandhandel
Kurzbeschreibung:
- Schulung der Datenbank-Entwickler bezüglich verschiedener Themen: Oracle Optimizer-Grundlagen, Parallelverarbeitung, Verständnis für Ausführungspläne, Besonderheiten von parallelen Ausführungsplänen, Laufzeit-Analyse von SQL-Ausführungen.
Zeitraum: Januar 2018
Name des Projekts: Performance Troubleshooting Oracle 12c
Kunde: VWFS, Braunschweig
Branche: Bank
Kurzbeschreibung:
- Eine Standardsoftware führte parallelisierte und batchbasierte Berechnungen deutlich langsamer durch als erwartet. Abgesehen von einigen kritischen Abfragen, für die recht einfach ein wesentlich effizienter Ausführungsplan gefunden werden konnte, war der Hauptdiskussionspunkt die I/O Performance, die von der Datenbank während der Berechnungen gemeldet wurde, die verglichen mit anderen Datenbanken, die den gleichen Storage verwenden und I/O Kalibrierungsergebnissen fragwürdig niedrig waren.
Durch Verwendung selbst entwickelter I/O Benchmark Skripte, die es erlauben, spezifische I/O-Muster auf der Datenbank zu erzeugen (single / multi-block synchronous / asynchronous), konnte gezeigt werden, dass bei Verwendung von Shared Server-Verbindungen die Datenbank asynchrones I/O nicht zum Einsatz bringt ? was dazu führt, dass bei dem von der Applikationsarchitektur vorgegebenen Parallelisierungsgrad die verfügbare IOPS-Rate nicht ausgenutzt wurde. Die Entscheidung, Shared anstatt Dedicated Server zu verwenden wurde in der Vergangenheit getroffen, als ein anderer Applikationsteil unter langsamem Verbindungsaufbau bei Verwendung von Dedicated Servern litt.
Bei Verwendung von Dedicated Servern verwendeten die Prozesse der Batchverarbeitung asynchrones I/O und Abfragelaufzeiten konnten dadurch um mehrere Faktoren reduziert werden, zum Beispiel von über 25 Minuten auf unter 5 Minuten.
Mehrere Jahre Erfahrung im Bereich Consulting/Schulung/Entwicklung/Administration
Schwerpunkt: Oracle Database Performance Troubleshooting + Tuning, Proactive Database Design for Performance
Direktester geht's nicht! Ganz einfach Freelancer finden und direkt Kontakt aufnehmen.
"Der Consultant unterstützte uns durch seine hervorragende Expertise und seinen enormen Arbeitseinsatz in einem sehr großen, zentralen Data Warehouse Projekt für den Bereich Risiko Controlling, Regulatorisches Reporting und Credit Risk Management. Mit seiner Arbeit in verschiedenen Bereichen (vor allem Oracle Performance Optimierung und Partitionierung, siehe Projektbeschreibung) deckte er ein breites Spektrum der von uns in diesem Projekt gestellten Aufgaben sehr kompetent ab. Die Mitarbeit des Consultants im Projekt zeichnete sich im Besonderen dadurch aus, dass er es verstand, technisch und inhaltlich komplexe Aufgabenstellungen unter hohem Zeitdruck über einen längeren Zeitraum hinweg erfolgreich zu bewältigen. Durch sein großes Engagement und durch seine professionelle Herangehensweise hat er vor allem im Bereich des Performance-Tunings maßgebliche Impulse eingebracht, ohne die das Projekt nicht die positive Entwicklung genommen hätte. Darüber hinaus war er auch durch seine Hilfsbereitschaft und seine offene, auf Menschen zugehende Art für das gesamte Team ein Gewinn. Wir möchten uns sehr für die Unterstützung durch den Consultant bedanken und begleiten ihn mit besten Wünschen für seine Zukunft."
— Projekt dbArtos - Aligned Credit Risk Reporting, 07/05 - dato
Referenz durch Projektleiter, gr. dt. Finanzinstitut, vom 26.10.06
"Der Consultant hat uns von Januar 2005 bis Juni 2005 als Oracle DBA im Bereich 'Oracle RUN (Datenbankbetrieb)' unterstützt. Zu seinen Aufgaben gehörte vor allem die Sicherstellung des Betriebs von mehreren hundert Oracle-Datenbanken (SAP und non-SAP) durch Bearbeiten und Lösen der gemeldeten Störungen, Probleme und Anfragen innerhalb unseres Oracle DBA-Teams. Er hat sich sehr schnell in die bestehenden Betriebsabläufe integriert und stand uns von Anfang an mit seinem Expertenwissen und außerordentlich hohem Engagement zur Seite. Der Consultant war ein beliebtes und allseits geschätztes Mitglied unseres Oracle DBA-Teams, sowohl aufgrund seiner freundlichen und umgänglichen persönlichen Art, als auch seinem fachlichen Wissen. Dank seiner sehr guten Englischkenntnisse verlief auch die Kooperation mit unseren ungarischen und polnischen Kollegen hervorragend.
Wir bedauern sehr, daß der Consultant ab Juli ein neues Projekt begleiten wird, an einer Fortführung der Zusammenarbeit hätten wir großes Interesse gehabt. Sollte sich die Gelegenheit ergeben, werden wir sehr gerne wieder auf ihn zur Unterstützung unseres Teams zurückgreifen."— Projekt Oracle DBA, 01/05 - 06/05
Referenz durch Teamleiter der Lufthansa Systems Infratec GmbH, vom 13.06.05
"Der Consultant hat uns auch 2003 bei der Weiterentwicklung und Pflege im Projekt dbIRS unterstützt. Ich bin seit Januar 2003 als Projektleiter für das Projekt verantwortlich. Einer der Schwerpunkte der Weiterentwicklung war eine deutliche Steigerung der Performance der gesamten dbIRS-Applikation. Der Consultant hat hierzu wesentlich beigetragen, insbesondere der kritische Bereich des AdHoc-Reportings aufgrund des gestiegenen Datenvolumens und des komplexen Berechtigungs- und Abfragesystems wurde nochmals signifkant in der Geschwindigkeit gesteigert. Wir danken dem Consultant für sein weiterhin hohes Engagement und die auch auf zwischenmenschlicher Basis harmonische Zusammenarbeit und wünschen ihm in Zukunft alles Gute."
— Projekt dbIRS - Incident Reporting System
Referenz durch Projektleiter Deutsche Bank AG vom 07.11.03
"The Consultant was working in Opera Application Framework project since 01.01.2003 as database administrator, designer and developer. The project has been kicked off mid of 2002 and is under my responsibility since beginning 2003. The Consultant's responsibilities include but not limited to articipation in design and implementation of Application Framework Components. Major work has been done on backend integration of several existing components, separation and unification of common static data, design, coding and support of static data change management processes and procedures. A set of complex packages and procedures has been developed using PL/SQL in Oracle 8i/9i environment. While working on different project tasks, the Consultant has proven to be very knowledgeable, experienced organised and extremely reliable partner. His effort estimates and opinion on specific technical issues has been always valued by his peers and management. During the project work the Consultant expressed himself as good team member. He always used the chance to assist his colleagues and to coach the junior staff. He possesses very good communication skills, directly liasing with clients and assisting them in their daily business. He speaks English fluently, and has always succeeded working in challenging, geographically distributed and cross-cultural project environment. It's worth mentioning that he carefully observes and follows any new developments in the broad area of his interests, participates in formal training courses and spends his spare time on self-training. Using this opportunity I want to express our gratefulness to the Consultant for the excellent work, highest commitment, and wish him much success in his future engagements. I am looking forward to new opportunities for working with him."
— Projekt Opera Application Framework from 01/03 - to date
Referenz durch Project Manager, Deutsche Bank AG in Frankfurt from 07.11.03
"Der Consultant hat uns seit Januar 2003 im Projekt 'Operational Risk Reporting Framework' unterstützt, das ich leite. Dabei handelt es sich um die Entwicklung eines anwendungsübergreifenden Operational Risk MIS (Management Information System) mit Data Warehouse Architektur. Zu den Aufgaben des Consultant gehörten insbesondere:
- Design des Datenmodells in Data Warehouse Architektur mit Staging/Transformation/Refinery/Packaging Area
- Analyse und Implementierung der benötigten ETL-Prozesse (Extraction, Transformation, Load)
- Aufsetzen eines OLAP-Reporting: Zusammenarbeit mit dbCube-Team in London, Definition und Umsetzung der benötigten Kennzahlen und Dimension für OLAP-Würfelgenerierung in Hyperion Essbase und Microsoft Analysis Services
- Datenbankseitige Implementierung eines Approval-Workflows einer MIS-Reporting Hierarchie inklusive Verwaltung eingegebener Report-Kommentare der Bereichsverantwortlichen
Der Consultant hat mit seinem hohen Engagement und durch seine ergebnis-orientierte Herangehensweise wesentlich zum bisherigen positiven Projektverlauf beigetragen. Durch die internationale Zusammenhang des Projekt-Teams ist die Verkehrssprache Englisch, in der die schriftliche und mündliche Kommunikation geführt wird. Wir bedanken uns für die Unterstützung des Consultant und wünschen ihm alles Gute für die Zukunft."— Projekt Operational Risk Reporting Framework von 01/03 - dato
Referenz durch Projektleiter, Deutsche Bank AG vom 13.11.03
"Der Consultant unterstützt die Deutsche Bank im Bereich Operational Risk Technology / Projekt dbIRS (Incident Reporting System). Bei dem Projekt geht es um die Entwicklung eines webbasierten Werkzeugs zur Erfassung und Auswertung von Ereignissen und den damit verbundenen Verlusten, die sich aufgrund des Operativen Risikos der Bank ergeben. Das Werkzeug ist Teil des Meldewesens der Bank und erhält eine besondere Relevanz durch den neuen Basel Accord (Basel II). Ich leitete vom Januar 2002 bis Januar 2003 die Entwicklung der Version 4.0 von dbIRS, die durch wesentliche funktionale und technische Erweiterungen im Zuge von Basel II gekennzeichnet ist. Nach der Fertigstellung dieser Version ist der Consultant auch durch den neuen Projektleiter um eine Verlängerung seiner Unterstützung gebeten worden. Aufgrund der guten Erfahrungen in der Vergangenheit ist der Consultant nun in weitere Initiativen im Bereich Operational Risk Technology eingebunden:
- Operational Risk Common Data Framework: Vereinheitlichung und zentrale Wartung der von verschiendenen Systemen genutzten statischen Daten, incl. Change Management ('Mapping' der anwendungsspezifischen Bewegungsdaten bei Änderungen der gemeinsamen Daten)
- Operational Risk Reporting Framework: anwendungsübergreifendes Reporting, Entwicklung der Grundlagen eines einheitlichen Operational Risk MIS (Management Information System) mit Data Warehouse Architecture
- ORX Gate: Schnittstelle für das Melden von IRS-Ereignisdaten in verschiedene weitere Systeme
Die Organisation des Bereiches und unserer Projekte bringt es mit sich, dass der Consultant den täglichen Austausch mit Kollegen im Europäischen und Asiatischen Ausland pflegt. Verkehrssprache ist Englisch. Wir kennen und schätzen den Consultant als Spezialisten mit exzellentem Know-how im Bereich Relationaler Datenbank Management Systeme, insb. Oracle, und als äußerst engagierten Mitarbeiter im Team. Während sämtlicher Phasen des Projektes hat der Consultant wesentlich zum Gelingen beigetragen, durch die aktive Mitgestaltung wesentlicher Teile der Architektur, seine ergebnisorientierte Herangehensweise bei der Entwicklung und durch die meisterhafte Bewältigung des Performance-Tunings von Dynamischen Abfragen. Der Consultant ist in unserem Bereich die anerkannte Autorität in allen Belangen des Einsatzes von Oracle Datenbanken. Er hat sich durch seine stets qualitativ hochwertige Arbeit und durch seine konstruktive Art die Anerkennung und Sympathie aller Projektbeteiligten erworben. Wir setzen die Arbeit mit ihm gerne fort, und ich persönlich werde jederzeit gerne wieder mit ihm zusammenarbeiten."— Projekt dbIRS (Incident Reporting System), seit 01/01
Referenz durch Projektleiter Deutsche Bank AG, Frankfurt vom 24.04.03
"Diese Zwischen-Referenz wird erstellt, da der verantwortliche Projektleiter innerhalb der Abteilung neue Aufgaben übernommen hat. Der Consultant befindet sich noch in diesem Projekt und ist auch vom neuen Projektleiter um eine Vertragsverlängerung gebeten worden. Der Consultant zeichnet sich durch profundes Wissen und außergewöhnliches Engagement in diesem Projekt aus. Das neue Release des entwickelten Systems trägt wesentliche neue Aspekte, die grösstenteils in der Datenbank abgehandelt werden. Der Consultant hat diese nicht nur exzellent umgesetzt, sondern hat darüber hinaus während der Designphase zahlreiche Ideen eingebracht bzw. während der Implementierung selbstständig auf Schwachstellen und Fehlerpotentiale hingewiesen und beseitigt. In einem Wort, er denkt mit. Durch sein hohes Engagement während der Migrationsphase hat der Consultant zu einem termingerechten Start des neuen Releases wesentlich beigetragen. Der Consultant ist vollständig in das internationale Entwicklungsteam integriert, d.h. ein Austausch mit Kollegen und Kunden in London und Übersee ist an der Tagesordnung. Die Zusammenarbeit verlief bisher auch auf zwischenmenschlicher Ebene absolut harmonisch. Der Consultant hat sich weit über den IT-Kollegenkreis durch seine professionelle und menschliche Art grosse Wertschätzung erworben. Wir möchten uns für die bisherige Unterstützung bedanken und werden versuchen, den Consultant auch weiterhin an unser Haus zu binden. Trotzdem können wir Ihn aufgrund unserer Erfahrungen nur weiterempfehlen, da wir mit seiner Arbeit überaus zufrieden sind."
— Projekt Oracle DBA im Bereich Operational Risk - seit Januar 2001
Referenz durch Teammanager/Projektleiter Deutsche Bank AG vom 14.03.02