Fachlicher Schwerpunkt dieses Freiberuflers

Spezialist für Oracle Database 11g/12c/18c/19c (Oracle ACE Director Alumni, 2011-2016), Oracle Database Performance Troubleshooting + Tuning7

verfügbar ab
01.10.2020
verfügbar zu
50 %
davon vor Ort
100 %
PLZ-Gebiet, Land

D5

D6

D7

Kontaktwunsch

Ich möchte bevorzugt für Projekte in diesen Einsatzorten kontaktiert werden.

Kommentar

Deutschland: Bevorzugt Bereich D6

Position

Kommentar

Mehrere Jahre Erfahrung im Bereich Consulting/Schulung/Entwicklung/Administration

Schwerpunkt: Oracle Database Performance Troubleshooting + Tuning, Proactive Database Design for Performance

Projekte

07/2020 - 07/2020

1 Monat

Oracle Datenbank 19c Performance Troubleshooting (Exadata)

Rolle
Oracle Datenbank Performance Troubleshooting Spezialist
Einsatzort
Berlin
Projektinhalte

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

Kenntnisse

Oracle Database Performance Troubleshooting

Produkte

Oracle Database

06/2020 - 06/2020

1 Monat

Oracle Datenbank Performance Troubleshooting

Rolle
Oracle Datenbank Performance Troubleshooting Spezialist
Einsatzort
Oberhaching bei München
Projektinhalte

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.

Kenntnisse

Oracle Database Performance Troubleshooting

Produkte

Oracle Database

05/2020 - 05/2020

1 Monat

Exadata Workshop

Rolle
Seminarleiter
Einsatzort
Merzig (Saar)
Projektinhalte

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.

Kenntnisse

Oracle Database

Produkte

Oracle Exadata Database Machine

05/2020 - 05/2020

1 Monat

Oracle Datenbank Performance Workshop

Rolle
Seminarleiter
Kunde
vedisys GmbH
Einsatzort
Griesheim, Hessen
Projektinhalte

Individual Workshop zu Oracle Datenbank Performance Themen, insbesondere Locking, Parallelisierung, Indizierung, Analysemöglichkeiten innerhalb der Datenbank

Kenntnisse

Oracle Database Performance Tuning

Produkte

Oracle Database

Projekthistorie

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 im Auftrag der Oracle University

 

Auswahl Kurzeinsätze:

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.

Zeitraum: Dezember 2017
Name des Projekts: Performance Troubleshooting Oracle 12c
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:

- Die Laufzeit eines PL/SQL-Anonymisierungsjobs beträgt über 24 Stunden und beeinträchtigt daher die Gesamtlaufzeit zur Erstellung eines Datenbank-Klons signifikant. Nach der Analyse welche Verarbeitungsschritte die Laufzeit bestimmen, wurden verschiedene Vorschläge gemacht, wie die Verarbeitungszeit reduziert werden kann. Das Grundproblem besteht darin, dass viele partitionierte Tabellen komprimiert sind und daher vor dem Update eine Dekompression pro Partition und nach dem Update wieder eine Kompression notwendig ist. Eine alternative Implementierung würde gleich eine wieder komprimierte Kopie der Daten (partitionsweise) erzeugen mittels CTAS und dabei Update und Kompression in einem Schritt erledigen und die Dekompression sparen. Als erste Verbesserung wurde die Parallelisierung des vorhandenen Jobs geändert (keine Parallelisierung mittels SQL Parallel Execution, sondern mittels DBMS_PARALLEL_EXECUTE Verarbeitung mehrerer Objekte gleichzeitig), was die Laufzeit auf unter 12 Stunden reduziert hat – eine größere Steigerung verhindert die I/O-Limitierung des Systems. Ob eine Reimplementierung eventuell unter Oracle 12.2 mit vereinfachtem Handling der Exchange Tables durchgeführt wird, muss noch entschieden werden.

Zeitraum: Dezember 2017
Name des Projekts: Performance Troubleshooting Oracle
Kunde: Deutsche Bahn, Frankfurt, Deutschland
Branche: Software
Kurzbeschreibung:
- Bei bestimmten Arten von Abfragen, die ansonsten performant funktionieren, kommt es immer wieder in unregelmäßigen Abständen zu sporadischen Langläufern, die dann aber teilweise geballt auftreten und das gesamte System beeinflussen können. Die Frage war, ob eine Ursache dafür festgestellt werden kann. Die nähere Analyse eines kürzlich aufgetretenen Falls zeigte, dass ein Grund dafür die unglückliche Zusammenkunft von mehreren Umständen sein kann: Abfrageausführungen mit Werten, die außerhalb des Gültigkeitsbereichs einiger Parameter liegen (zum Beispiel Datumswerte) und die Neuerstellung von Ausführungsplänen (zum Beispiel durch „Cardinality Feedback“ getriggert). Die Datenbank hat dann diese Ausführungspläne basierend auf den exotischen Werten auch für andere Werte weiter verwendet, die im normalen Bereich lagen, und daher extrem ungünstig und ineffizient aufgrund der dann zu verarbeitenden Datenmenge waren. Im Grunde also ein klassisches Problem des Bind Variable Peekings und Adaptive Cursor Sharing hat hier nicht weiter geholfen – die ineffizienten Pläne wurden weiter verwendet. Abhilfe wird hier nun erst mal mittels SQL Plan Baselines geschaffen, und die Anwendung soll in Zukunft so verändert werden, dass Werte außerhalb des Gültigkeitsbereichs erst gar nicht zur Ausführung kommen.

Zeitraum: November 2017
Name des Projekts: "Exadata für Anwendungsentwickler" Workshop
Kunde: Swisscom, Schweiz

Branche: Telekommunikation
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: November 2017
Name des Projekts: Performance Troubleshooting
Kunde: VWFS, Braunschweig
Branche: Bank
Kurzbeschreibung:

- Analyse einer Web-Frontend Applikation als Teil einer Standard-Software. Die interaktiven Abfragen laufen zum Teil minutenlang. Durch verbesserte Indizierung, Wechseln des Optimizer-Modes auf FIRST_ROWS_100 mittels Logon-Trigger und Separierung von Objekten mittels Einrichtung eines KEEP-Caches wird eine konstant schnelle Antwortzeit unter einer Sekunde erreicht, auch unter Last und bei gleichzeitiger Batch-Verarbeitung, die ansonsten die Objekte aus dem Cache verdrängt hat.

Zeitraum: Oktober 2017
Name des Projekts: Performance Troubleshooting (Exadata)
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:

- Unterstützung eines Proof Of Concept – Migration einer bestehenden Applikation von AIX auf Exadata. Die Applikation zeigt nach der Migration deutlich schlechtere Performance als auf dem Quellsystem. Ursache dafür ist die Kombination aus nur teilweise korrekt übertragenen Statistiken, Optimizer-Parameteränderungen, andere System Statistiken auf Exadata und die breite Anwendung von Hints in der migrierten Applikation. Nach Korrektur der System- und Objekt Statistiken sowie Parameter vergleichbare bzw. bessere Performance auf der Exadata-Umgebung als auf dem Quellsystem.

Zeitraum: Oktober 2017
Name des Projekts: Performance Troubleshooting
Kunde: State Street, Frankfurt
Branche: Bank
Kurzbeschreibung:

- Optimierung eines neuen 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: September 2017
Name des Projekts: Datenbank Review
Kunde: AXIT, Deutschland / Polen
Branche: Software
Kurzbeschreibung:

- Review einer bestehenden Cloud-Applikation mit Oracle-Datenbank als Backend. Konfiguration und Datenbank-Aktivität analysiert und Hinweise für Optimierung gegeben. Unter anderem wird relativ viel Zeit mit Parsing verbracht, was auch zu Latch Contention im Library Cache führt. Dafür sind verschiedene Gründe verantwortlich – die hohe Parse-Rate, lange Hard Parse-Zeiten, die Verwendung von VPD und das regelmäßige Ausführen von Monitoring-Abfragen auf internen Tabellen wie X$KSMSP, die in einem aktiven Produktionssystem eigentlich nicht verwendet werden sollten aufgrund der Latch-Problematik. Die Verwendung von VPD führt dazu, dass Child Cursor nicht geteilt werden können, was wiederum die Hard Parse-Rate erhöht und zu vielen Child Cursor Versionen führt. Außerdem gibt es noch bekannte Probleme mit der Verwendung von Bind Variablen, die auch zu vielen Versionen führen können.

Zeitraum: September 2017
Name des Projekts: Performance Analyse Applikation
Kunde: Interexa AG, Mainz, Deutschland
Branche: Software
Kurzbeschreibung:

- Eine Standard-Software für Banken zeigt in bestimmten Applikationsteilen sehr unterschiedliche Performance in unterschiedlichen Umgebungen. Eine genauere Analyse zeigt, dass die Applikation aufgrund der generischen Funktionalität sehr viele SQLs absetzt und zusätzlich diese SQLs teilweise unterschiedliche Aliasnamen verwenden, so dass eigentlich identische SQLs immer wieder neu optimiert werden müssen. Bei weiterer Analyse wird klar, dass es eben genau diese Hard Parse-Zeit ist, die sich in den Umgebungen unterscheidet, da diese Hard-Parse Zeit auch die Gesamtausführungszeit dominiert. Es handelt sich um Oracle 12c (12.1.0.2) mit adaptiven Features aktiviert, und die fraglichen Umgebungen unterscheiden sich in der Anzahl an SQL Plan Direktiven, die ausgewertet werden und zu vermehrtem Dynamic Sampling führen können, was wiederum die Optimierungszeit erhöht. Die Empfehlung ist, die adaptiven Features zu deaktivieren (idealerweise den von Oracle empfohlenen Patch installieren, der die 12.2 Einstellungen bezüglich der adaptiven Optimizer Features zurückportiert auf 12.1) und das Dynamic Sampling abzuschalten, was den Overhead während der Optimierungsphase zur Erstellung des Ausführungsplans minimiert.

Zeitraum: August 2017
Name des Projekts: Performance Troubleshooting Data Warehouse Oracle 12c
Kunde: Deutsche Bundesbank, Frankfurt
Branche: Bank
Kurzbeschreibung:

- Performance Analyse der Datenbank-Aktivitäten einer komplexen Java Spring Batch Applikation nach Upgrade auf Oracle 12c. Einige Operationen zeigen eine deutlich verlängerte bzw. auch stark schwankende Laufzeit in der Oracle 12c Umgebung. Es werden verschiedene Ursachen identifiziert: Die von Oracle selbst generierte Abfrage zur Pflege der Metadaten für inkrementelle Statistiken (Synopsis) verwendet einen ineffizienten Ausführungsplan in 12c und dauert daher sehr lange (30 Minuten für eine Applikationsoperation, die ansonsten nur einige Sekunden läuft). Nach Abschalten der inkrementellen Statistiken auf den betroffenen Tabellen ist die Laufzeit wieder im normalen Bereich. Die globalen Statistiken können Nachts auch nicht inkrementell gepflegt werden. Desweiteren kommt es bei einigen Abfragen, die Parallel Execution verwenden, zu extremen Concurency-Effekten, so dass die Parse-Phase aufgrund von Library Cache Contention über eine Stunde in Anspruch nehmen kann. Hier handelt es sich um einen Bug, kurzfristig kann hier aber einfach auf Parallel Execution verzichtet werden.

Zeitraum: August 2017
Name des Projekts: Performance Troubleshooting Data Warehouse Oracle 12c
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:

- Einzelne kritische Abfragen im Rahmen einer ETL Ladestrecke laufen seit kurzem von Zeit zu Zeit sehr lange – Stunden anstatt Minuten. Eine Analyse ergibt, dass die Abschätzungen des Optimizers sich schon seit längerem in einem Bereich befinden, in dem der Ausführungsplan sich signifikant verändern kann. Dazu kommen strukturelle Probleme in manchen der Abfragen – es werden komplexe NVL Bedingungen über mehrere Tabellen in Joins eingesetzt, die der Optimizer nicht gut abschätzen kann und die zusätzlich auch von den Adaptive Features von Oracle 12c bzw. mittels erweiterter Statistiken nicht korrigiert werden können. Für eine kurzfristige Lösung werden einige Hints empfohlen, die die Fehlabschätzungen korrigieren. Längerfristig sollte das SQL entsprechend umgeschrieben werden, um die komplexen NVL-Ausdrücke zu vermeiden.

Zeitraum: Juli 2017
Name des Projekts: Performance Troubleshooting DWH (Exadata)
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:

- Eine laut Kunde unveränderte DWH-Anwendung auf einer Exadata Plattform zeigt in der letzten Zeit verlängerte Laufzeiten, die dazu führen, dass kritische Berichte nicht mehr in der vereinbarten Zeit geliefert werden können. Eine Analyse zeigt zum Einen, dass es durchaus Änderungen am System gab, die auch dazu beitragen, die Last zu erhöhen und zum Anderen, dass schon in den guten Zeiten das System am Limit betrieben wurde, insbesondere die CPU-Benutzung auf den Compute Nodes ist in kritischen Zeiten schon am Limit gewesen, jetzt ist das System überlastet.
Durch Optimierung der Top Consumer SQLs wird die Last auf dem System mehr als halbiert, so dass die Laufzeiten wieder unter denen liegen, als es noch keine Probleme gab. Dem Kunden wird auch noch nahe gelegt, dass weitere Änderungen das System wieder in den instabilen Zustand bringen können und eine zukünftige Skalierbarkeit weitere Optimierungen benötigt.

Zeitraum: März-Juni 2017
Name des Projekts: Proof Of Concept Unterstützung AWS Cloud, Exadata, ODA
Kunde: FiCo Tonbeller, Bensheim, Deutschland
Branche: Software
Kurzbeschreibung:
- Test der FiCo Tonbeller Applikationen mit deutlich gesteigertem Datenvolumen als Vorbereitung für neue Kunden. Aufsetzen eines größeren Datenbank-Servers (64 CPUs, 256 GB RAM) in der AWS Cloud mit Red Hat 7, ASM und Oracle 12.1.0.2 sowie mehreren EC2 SSD Volumes. Datenbank Performance Analyse in unterschiedlichen Umgebungen (AWS Cloud, Exadata, Oracle Database Appliance (ODA)). Performance Optimierungen verschiedener Applikationsteile aufgrund der Analyseergebnisse.

Zeitraum: Mai 2017
Name des Projekts: "Exadata für Anwendungsentwickler" Workshop
Kunde: Deutsche Bahn, Frankfurt, Deutschland
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: Februar 2017
Name des Projekts: Performance Troubleshooting Oracle 12c
Kunde: FiCo Tonbeller, Bensheim, Deutschland
Branche: Software
Kurzbeschreibung:
- Ein bestimmter Applikationsteil führt einfache Batch INSERTs von mehreren Sessions parallel aus. Die INSERTs sind sehr langsam und verbringen fast ihre gesamte Datenbankzeit in Concurrency / Library Cache Contention. Eine Analyse ergibt, dass die Datenbank extrem viele Child Cursor für diese INSERTs generiert (mehr als 200000 im Test), so dass es bei fast jeder Ausführung zu einer neuen Optimierung und einem neuen Child Cursor kommt. Das INSERT-Statement hat viele Bind-Variablen und die Applikation baut direkt auf der OCI-API auf. Bei NULL-Werten wird ein entsprechendes Indikator-Feld auf OCI-Ebene gesetzt. Dies führt offensichtlich dazu, dass Oracle bei Unterschieden in dem Indikator-Feld einen neuen Cursor generiert, was bei der möglichen Anzahl an Permutationen über die hohe Anzahl Bind-Werte die große Menge an Child-Cursorn erklärt. Außerdem werden VARCHAR-Binds unterschiedlicher Länge verwendet, was zu einem ähnlichen Effekt führt (Bind Length Upgrade). Empfehlung entweder Event 10503 einzuführen, oder die Länge der Bind-Definitionen auf Applikationsseite zu vereinheitlichen, als auch das NULL-Handling für Zeichenketten über Leerstrings anstatt des Indikators durchzuführen

Zeitraum: Januar 2017

Name des Projekts: Performance Troubleshooting DWH Oracle 12c
Kunde: Ingenico, Hamburg
Branche: Marketing
Kurzbeschreibung:

- Allgemeine Analyse einer DWH Anwendung auf einer Oracle 12c Datenbank in einer AIX Power8-Umgebung mit EMC Storage. Es zeigt sich, dass sowohl die Single Thread Performance als auch die Skalierung mit SMT8 (zum Beispiel 4 Cores / 32 CPUs pro LPAR) zusammen mit Oracle nicht gut funktioniert. Die Single Thread Performance ist nur ca. 50% von aktuellen XEON Prozessoren, SMT skaliert über SMT2 hinaus nicht gut. Die typischen DWH-Abfragen verbringen sehr viel CPU-Zeit in COUNT(DISTINCT) Operationen, die in Oracle nicht sehr effizient implementiert sind. Unter anderem Empfehlung auf neue APPROX-Funktionen in 12c umzustellen, die wesentlich effizienter sind (Faktor 10 bei typischen Abfragen). Leider werden diese noch nicht von Oracle BI generisch unterstützt. In Oracle 12.2 können diese dann per Schalter aktiviert werden (Zum Beispiel COUNT(DISTINCT) wird automatisch in APPROX_COUNT_DISTINCT umgewandelt)

Zeitraum: Januar 2017
Name des Projekts: Performance Troubleshooting DWH (Exadata)
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:

- Eine auf Exadata portierte DWH Anwendung verbringt über 50% der Datenbank-Zeit in Library Cache Contention, was auch zu Abbrüchen / Deadlocks in der Datenbank/Anwendung führt, da gleichzeitige DML und DDL-Aktivitäten auf Library Cache-Ebene kollidieren (Library Cache lock / deadlock). Eine Analyse ergab, dass viele DML-Statements sehr lange Parse-Zeiten zeigten, hervorgerufen durch zwei Effekte: Zum Einen rekursive Dynamic Sampling Abfragen, die wesentlich länger als erwartet laufen und zum Anderen unnötiges Parsen in Parallel Slaves. Durch Abschalten der automatischen Erhöhung des Dynamic Sampling Levels bei Verwendung von Parallel Execution (Neues Feature in 11.2 eingeführt) und Reduktion der Verwendung von Parallel Execution wird deutlich mehr Zeit mit Ausführen von Statements anstatt Parsing verbracht. Deadlocks/Abbrüche treten nicht mehr auf.

Zeitraum: Januar 2017
Name des Projekts: Performance Troubleshooting Data Warehouse Oracle 12c
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:

- Eine unveränderte DWH-Anwendung wurde plötzlich signifikant langsamer, bis hin zu Abbrüchen in Ladestrecken, die nicht mehr in vertretbarer Zeit zu Ende kamen. Eine Analyse ergab, dass die automatische Speicherverwaltung von Oracle (MEMORY_TARGET) den Buffer Cache extrem verkleinert hat und dann in einen Fehlerzustand lief, der eine automatische Vergrößerung verhinderte. Durch Setzen entsprechender Untergrenzen für DB_CACHE_SIZE, SHARED_POOL_SIZE etc. wurde die vorherige Performance wieder hergestellt und gleichzeitig sichergestellt, dass das Problem in dieser Form in Zukunft nicht mehr auftreten sollte (Abklärung mit Oracle Support noch nicht abgeschlossen, beobachtetes Verhalten des automatischen Speichermanagements sieht wie ein Bug aus)

Zeitraum: November-Dezember 2016
Name des Projekts: Performance Optimierung Informatica / Oracle 12c
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Datenbank-Optimierung einer Informatica-basierten Data Warehouse Anwendung. Analyse von Bottlenecks und Vorschläge zur Verbesserung des Zusammenspiels von Informatica und Datenbank, zum Beispiel Sequenz-Optimierung und Ausführungsplan-Verbesserungen durch Bereitstellung von mehr Informationen für den Oracle Optimizer

Zeitraum: November 2016
Name des Projekts: Performance Optimierung (Exadata)
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Betreuung der Migration einer Inhouse-Anwendung auf Exadata. Performance-Analyse, Parameter-Optimierung der neuen Exadata-Umgebung, Erstellung einer individuellen Statistik-Generierungsprozedur zur besseren Ausnutzung der vorhandenen Ressourcen

Zeitraum: Oktober 2016
Name des Projekts: Performance Troubleshooting Upgrade Oracle 12c
Kunde: FiCo Tonbeller, Bensheim, Deutschland
Branche: Software
Kurzbeschreibung:
- Performanceanalyse einer Performance-Degradierung nach dem Upgrade auf Oracle12c. Identifizierung eines Oracle Optimizer Bugs bei der Kombination von Column Groups und CHAR-Datentypen. Vorschläge mit welchen Optimizer-Einstellungen die Anwendung optimal funktioniert (Kombination von vorherigen und neuen Features)

Zeitraum: September-Oktober 2016
Name des Projekts: Performance Troubleshooting Oracle 12c Migration
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Unterstützung bei der Migration einer Vendor-Applikation von Oracle 11.2 nach Oracle 12c, insbesondere im Bereich Performance und Stabilität, sowie Minimierung der Migrationslaufzeit. Dazu Analyse und Optimierung verschiedener Datenbank-Operationen, die im Rahmen der Migration ausgeführt werden

Zeitraum: September 2016
Name des Projekts: Feature Usage Troubleshooting
Kunde: ProLicense, Hamburg
Branche: Consulting
Kurzbeschreibung:
- Untersuchung eines fragwürdigen Feature Usage Trackings der Datenbank durch Identifikation, wie Oracle die Benutzung des Features feststellt. Entsprechende Vorschläge durch welche Maßnahmen und Konfigurationsänderungen diese Feature Usage nicht länger von Oracle angezeigt wird. Identifikation eines Oracle Bugs bezüglich Feature Usage Tracking in Oracle 12c.

Zeitraum: August 2016
Name des Projekts: Performance Troubleshooting (Exadata)
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Performance Analyse eines Data Warehouse Ladeprozesses, der von „Parallel Execution Skew“ (Ungleichverteilung der Arbeit auf parallele Prozesse) betroffen war. Lösung des Problems zur Verfügung gestellt und Laufzeit pro Ausführung von mehr als einer Stunde auf wenige Minuten reduziert

Zeitraum: Juni-August 2016
Name des Projekts: Performance Troubleshooting
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Untersuchung der Performance des „Incremental Statistics“ Features für partitionierte Tabellen unter Oracle 12c. Laufzeiten analysiert und entsprechende Bugs bei Oracle identifiziert. Weitere Bugs nach Einspielen von Fixes identifiziert, weiterhin Zusammenarbeit mit Oracle Support, um Fixes zu erhalten

Zeitraum: Juli 2016
Name des Projekts: Beratung
Kunde: State Street, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Beratung über Instrumentierung der Applikation und proaktive Identifizierung von Langläufern zur Überwachung von SLAs

Zeitraum: Juli 2016
Name des Projekts: Performance Troubleshooting Upgrade Oracle 12c
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Analyse einer Inhouse Applikation, die bei bestimmten Berichten nach dem Upgrade auf Oracle 12c mit Speicherproblemen abbricht. Auch Analyse der Performance mit Hinweisen, wie die Laufzeit verschiedenster Module / Applikationsteile verringert werden kann

Zeitraum: Juni-Juli 2016
Name des Projekts: Performance Troubleshooting Upgrade Oracle 12c
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Untersuchung von Laufzeit-Veränderungen in einem Data Warehouse bei Lade- und Transformationsvorgängen nach Oracle 12c Datenbank Upgrade. Analyse von Langläufern und Identifizierung von Datenbank-Parameter-Einstellungen, die so nicht beabsichtigt waren (12c spezifische Einstellungen)

Zeitraum: Juni 2016
Name des Projekts: Performance Troubleshooting Upgrade Oracle 12c
Kunde: MBB Bank, Stuttgart
Branche: Bank
Kurzbeschreibung:
- Analyse Laufzeit-Veränderungen bei Ladeprozessen einer Third-Party Applikation. Identifizierung von Einstellungen auf Objekt-Ebene (CACHE=Y), die die Verwendung von schnellerem asynchronem I/O („direct path reads“) verhindern. Hinweise, wie die Laufzeiten der Ladeprozesse darüber hinaus verringert werden können (höhere Parallelität und mehr Prozesse, da Datenbank nicht ausgelastet)

Zeitraum: Mai 2016
Name des Projekts: Vortragsreise Schweiz
Kunde: SOUG Schweiz
Branche: Oracle User Group
Kurzbeschreibung:
- Präsentationen beim „SOUG Training Day“ in Olten und Genf:
- Advanced Oracle Performance Troubleshooting
- Analyse und Troubleshooting Oracle Parallel Execution

Zeitraum: Mai 2016
Name des Projekts: Performance Troubleshooting Upgrade Oracle 12c
Kunde: FiCo Tonbeller, Bensheim, Deutschland
Branche: Software
Kurzbeschreibung:
- Analyse Performance einer Testumgebung für eine existierende Applikation nach Upgrade auf Oracle12c und Umzug auf neue Hardware. Das I/O Profil der neuen Umgebung unterschied sich deutlich von der alten, so dass Single Block Reads deutlich langsamer waren

Zeitraum: April 2016
Name des Projekts: Performance Troubleshooting Upgrade Oracle 12c
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Analyse Performance einer existierenden Applikation nach Upgrade auf Oracle12c und Umzug auf neue Hardware. In der neuen Umgebung wurden 10 mal per physische I/Os durchgeführt. Nach Korrektur der SGA- und PGA-Konfiguration wurde die Laufzeit um Faktor 6 reduziert, was dann auch zeigte, dass die I/O-Performance in der neuen Umgebung deutlich weniger konsistent ist wie in der alten. Desweiteren Hinweise gegeben, wie die Performance der Applikation weiter gesteigert werden kann durch Minimierung der Parse-Zeiten, indem SQL Cursor von häufig ausgeführten SQLs wiederverwendet werden (Array Binds anstatt variable IN-Listen).

Zeitraum: März 2016
Name des Projekts: „Advanced Oracle Troubleshooting“ Workshops, Moskau
Kunde: Öffentlich, Luxoft
Branche: Software
Kurzbeschreibung:
- Mehrere Durchführungen meines Tages-Seminars „Advanced Oracle Troubleshooting“ in Moskau, Russland

Zeitraum: Februar 2016
Name des Projekts: Performance Troubleshooting (Exadata)
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Analyse Performance eines Hadoop->Datenbank Ladeprozesses. Root-Cause Analyse und Vorschläge wie verursachte Library Cache Contention behoben werden kann

Zeitraum: Januar 2016
Name des Projekts: Beratung Datenbankmigration
Kunde: Rimaone GmbH, Neu-Isenburg
Branche: Software
Kurzbeschreibung:
- Unterstützung bei der Durchführung von Datenbank-Migrationen in neue virtualisierte Datenbank-Umgebungen

Zeitraum: Januar 2016
Name des Projekts: Performance Troubleshooting (Exadata)
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Analyse und Beratung generelle Strategie für Reporting Abfragen und Ablage der entsprechenden Meta-Daten für Partition Pruning

 

Zeitraum: Dezember 2015
Name des Projekts: Performance Troubleshooting
Kunde: State Street, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Beratung über kurzfristige und mittelfristige Überarbeitung der Index-Strategie einer Applikation zur Verbesserung und Stabilisierung der Performance

 

 

Zeitraum: Dezember 2015
Name des Projekts: Performance Troubleshooting
Kunde: Compello GmbH, Deutschland
Branche: Software
Kurzbeschreibung:
- Analyse Datenbankperformance einer langsamen Applikation. Fehlende Foreign Key Indizierung korrigiert

 

 

Zeitraum: November 2015
Name des Projekts: Applikation Troubleshooting
Kunde: Société Générale, Paris
Branche: Bank
Kurzbeschreibung:
- Analyse der Datenbank-Aktivitäten einer Applikation, die anscheinend hängt oder abstürzt. Überprüfung Datenbank-Konfiguration

 

 

Zeitraum: November 2015
Name des Projekts: Performance Troubleshooting
Kunde: CACEIS, Paris
Branche: Bank
Kurzbeschreibung:
- Performance Analyse und darauf basierende Vorschläge, wie die Performance einer Third-Party Anwendung verbessert werden kann. Durch Umsetzung der Vorschläge (Index Design) ist die Applikationsperformance deutlich verbessert (Sekunden anstelle von Minuten) und zur gleichen Zeit die DML-Performance verbessert als auch Speicherplatz gespart durch Entfernung von unnötigen Indizes

 

 

Zeitraum: Oktober/November 2015
Name des Projekts: Performance-Verbesserung einer neuen Anwendung (Exadata)
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Unterstützung von Performance Tests einer neuen Version einer kritischen Kern-Anwendung. Performance Analyse und entsprechende Vorschläge, wie die gewünschte Performance erreicht werden kann. Durch Umsetzung der Vorschläge ist die neue Version der Applikation jetzt schneller als die bereits mehrfach optimierte alte Version der Applikation

 

 

Zeitraum: Oktober 2015
Name des Projekts: Performance Analyse Hardware Migration
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Unterstützung Migration auf neue Hardware-Plattform. Analyse der Performance-Tests

 

 

Zeitraum: September 2015
Name des Projekts: Performance Troubleshooting
Kunde: Deutsche Bundesbank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Performance Analyse der Datenbank-Aktivitäten einer komplexen Java Spring Batch Applikation mit Hinweisen bezüglich Erhöhung der Verarbeitungsgeschwindigkeit, sowie Lösungen für „Object no longer exists“-Fehler

 

 

Zeitraum: August 2015
Name des Projekts: Performance Troubleshooting
Kunde: Ingenico, Hamburg
Branche: Software
Kurzbeschreibung:
- Analyse Datenbank-Aktivitäten bei kritischem Benchmark. Identifizierung Bottleneck auf Datenbank-Ebene und Behebung durch entsprechende Änderung. Durchsatz-Erhöhung auf Datenbank-Seite so dass Applikationsserver an Leistungsgrenze stoßen anstatt auf Datenbank zu warten

 

 

Zeitraum: August 2015
Name des Projekts: Performance Troubleshooting
Kunde: State Street, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Analyse der Datenbank-Aktivitäten einer Applikation mit entsprechenden Hinweisen, wie diese in Zukunft optimiert werden können. Auswertung AWR, ADDM, ASH und detaillierte Analyse auf Ausführungsplan-Ebene und Vorschläge zur Index-Optimierung

 

 

Zeitraum: Juli 2015
Name des Projekts: Performance Troubleshooting
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Analyse kritischer Abfragen, die auf bestimmten Umgebungen lange Laufzeiten verursachen. Bestimmung Root Cause und verlässliche Reduzierung der Laufzeit in diesen Umgebungen von mehreren Minuten auf zwei Sekunden

 

 

Zeitraum: Juli 2015
Name des Projekts: Performance Troubleshooting
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Analyse langer Parse Zeiten bestimmter Datenbank-Abfragen. Reduzierung der Parse-Laufzeit von 50 Minuten auf 20 Sekunden

 

 

Zeitraum: Juli 2015
Name des Projekts: Performance Troubleshooting Workshops
Kunde: State Street, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Performance Troubleshooting Basics Workshops. Training für Datenbank Entwickler und Support-Mitarbeiter

 

 

Zeitraum: Juni/Juli 2015
Name des Projekts: Performance Troubleshooting
Kunde: CACEIS, Paris
Branche: Bank
Kurzbeschreibung:
- Analyse hängender Datenbank-Prozesse, Identifikation eines Oracle Bugs, der bereits mehrere Monate nicht eingegrenzt werden konnte

 

 

Zeitraum: Juni 2015
Name des Projekts: Performance Troubleshooting
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Analyse Batch Verarbeitung auf TEMPORARY Tablespace Auslastung. Verringerung des TEMP-Bedarfs von 140GB auf 100MB, Verringerung Laufzeit von > 30 Minuten auf 30 Sekunden

 

 

Zeitraum: Juni 2015
Name des Projekts: Performance Troubleshooting (Exadata)
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Analyse Langläufer, Vorbereitung eines Service Requests für Oracle Support

 

 

Zeitraum: Juni 2015
Name des Projekts: Performance Troubleshooting
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Laufzeitverringerung kritischer Berichte von 60 Minuten auf 30 Sekunden

 

 

Zeitraum: Mai 2015
Name des Projekts: ETL Prozess Performance Analyse
Kunde: DekaBank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Performanceanalyse Batch Processing als Teil eines ETL Ladeprozesses

 

 

Zeitraum: Mai 2015
Name des Projekts: Ad-hoc Performance Troubleshooting (Exadata)
Kunde: Deutsche Bank, New York
Branche: Bank
Kurzbeschreibung:
- Laufzeitverringerung einer kritischen Batch-Komponente von 90 Minuten auf 30 Sekunden

 

 

Zeitraum: April 2015
Name des Projekts: Performance hands-on Workshop
Kunde: Moody’s Analytics, Frankreich
Branche: Software
Kurzbeschreibung:
- Hands on Performance Workshop zur Analyse wichtiger Abfragen. Als Ergebnis Performance um Faktor drei gesteigert

 


Zeitraum: April 2015
Name des Projekts: Performance Troubleshooting Workshop
Kunde: Deutsche Bank, Frankfurt
Branche: Bank, DBAs
Kurzbeschreibung:
- Performance Troubleshooting Workshop für das globale DBA team der Bank

 


Zeitraum: April 2015
Name des Projekts: DOAG Expertenseminar
Kunde: DOAG (Deutsche Oracle Anwender Gruppe) GmbH, Berlin
Branche: Schulung
Kurzbeschreibung:
- Seminar “Parallel Execution Masterclass”

 


Zeitraum: März 2015
Name des Projekts: Performance Analyse EDI software
Kunde: Compello GmbH, Deutschland
Branche: Software
Kurzbeschreibung:
- Analyse der Databank Aktivität. Vorschläge, die Performance der Applikation um ca. 80% zu steigern durch verbessertes Index-Design und die Verwendung von Bind Variablen

 


Zeitraum: Februar 2015
Name des Projekts: Performance Analyse SEPA Applikation
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Performance Analyse einer komplexen SEPA Verarbeitungsapplikation und deren Queue-Verarbeitung
- Vorschläge, wie die Instrumentierung der Applikation verbessert werden kann für eine einfachere Performance-Analyse

 


Zeitraum: Januar 2015
Name des Projekts: Internet Webinar “Oracle Exadata & In-Memory Real-World Performance”
Kunde: Redgate, Cambridge, England
Branche: Software
Kurzbeschreibung:
- Präsentation des öffentlichen Webinars „Oracle Exadata & In-Memory Real-World Performance“

 


Zeitraum: Oktober - Dezember 2014
Name des Projekts: Performance Analyse Risk Application
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Performance Analysis einer Risk Applikation und deren Batch-Verarbeitung
- Laufzeit von über 8 Stunden auf unter einer Stunde verbessert

 


Zeitraum: November 2014
Name des Projekts: Performance Analyse Data Warehouse Reporting (Exadata)
Kunde: Deutsche Bank, Frankfurt
Branche: Bank
Kurzbeschreibung:
- Performance Analyse von Reporting Abfragen in einer Data Warehouse Umgebung
- Antwortzeit von kritischen Abfragen von mehr als 5 Minuten auf unter 10 Sekunden verringert

 


Zeitraum: September 2014
Name des Projekts: Performance Workshop Parallel Execution
Kunde: Moody’s Analytics, Frankreich
Branche: Software
Kurzbeschreibung:
- Training für Entwickler und DBAs

 

 

Zeitraum:          Juli/August 2014

Name des Projekts: Performance Analyse ETL Data Warehouse

Kunde:             Deutsche Bank, Frankfurt

Branche:           Bank

Kurzbeschreibung:

- Analyse Performance eines ETL Prozesses

- Vorschläge zur Reduzierung der Laufzeit von über 56 Stunden auf unter 6 Stunden

 

 

Zeitraum:          Mai 2014

Name des Projekts: Performance Workshop

Kunde:             Dealis Fund Operations, Frankfurt

Branche:           Finanzen

Kurzbeschreibung:

- Schulung der DBAs im Bereich Performance Analyse, Cost Based Optimizer und Parallel Execution

 

 

Zeitraum:          Februar 2014

Name des Projekts: Analyse Auslastung und Performance Datenbank

Kunde:             Ortenau Kliniken, Offenburg

Branche:           Gesundheitswesen

Kurzbeschreibung:

- Analyse Auslastung und Performance Datenbank bei Betrieb eines Krankenhausinformationssystems

- Vorschläge zur Optimierung durch Reduzierung des verwendeten Speichers um ein Vielfaches

- Vorschläge zur Optimierung der Performance durch Vermeidung permanenten Parsens der SQLs

 

 

Zeitraum:          Oktober/November 2013

Name des Projekts: Oracle Performance Tuning (Exadata)

Kunde:             Deutsche Bank, Frankfurt

Branche:           Bank

Kurzbeschreibung:

- Analyse Performance Ladevorgänge Data Warehouse

-  Reduzierung Laufzeit auf unter 20 Prozent der ursprünglichen Zeit durch Verwendung effizienterer Ausführungspläne aufgrund optimierter Statistikerstellung

 

 

Zeitraum:          August 2013 

Name des Projekts: Oracle Performance Tuning (Exadata)

Kunde:             Deutsche Bank, Frankfurt

Branche:           Bank

Kurzbeschreibung:

- Analyse Performance Erstellen von Stars in Star Schema

- Reduzierung Laufzeit von mehreren Stunden auf wenige Minuten durch Umschreiben von Abfragen zur Vermeidung von „Parallel Execution Skew“

 

 

Zeitraum:          Mai 2013 

Name des Projekts: Internet Webinar “Analyzing and Troubleshooting Oracle Parallel Execution”

Kunde:             Redgate, Cambridge, England

Branche:           Software

Kurzbeschreibung:

- Präsentation öffentliches Webinar „Analyzing and Troubleshooting Oracle Parallel Execution“

 

 

Zeitraum:          Dezember 2012

Name des Projekts: Vortrag CBO Days

Kunde:             Trivadis, Schweiz

Branche:           Software

Kurzbeschreibung:

- Vortrag im Rahmen der Trivadis CBO Days 2012 „Understanding Parallel Execution“

 

 

Zeitraum:          November 2012

Name des Projekts: Oracle Technology Network Artikel “Understanding Parallel Execution”

Kunde:             Oracle, USA

Branche:           Software

Kurzbeschreibung:

- Autor zweiteiliger Artikelserie „Understanding Parallel Execution“, veröffentlicht auf „Oracle Technology Network“

 

 

Zeitraum:          August 2012

Name des Projekts: Internet Webinar “Cost Based Optimizer Advanced”

Kunde:             Redgate, Cambridge, England

Branche:           Software

Kurzbeschreibung:

- Präsentation öffentliches Webinar „Cost Based Optimizer Advanced“

 

 

Zeitraum:          April 2012

Name des Projekts: Internet Webinar “Cost Based Optimizer Basics”

Kunde:             Redgate, Cambridge, England

Branche:           Software

Kurzbeschreibung:

- Präsentation öffentliches Webinar „Cost Based Optimizer Basics“ (Mehr als 20000 Views auf Youtube.com)

 

 

Zeitraum:          März bis Mai 2012

Name des Projekts: Oracle Performance Optimierung

Kunde:             MAQUET Rastatt

Branche:           Medizintechnik

Kurzbeschreibung:

- Optimierung Oracle Performance für interne Reporting Komponente

- Laufzeiten von mehreren Minuten auf wenige Sekunden optimiert durch Verwendung effizienterer Ausführungspläne

 

 

Zeitraum:          Februar und März 2012

Name des Projekts: Benchmark Optimierung

Kunde:             Fusion I/O

Branche:           Storage

Kurzbeschreibung:

- Optimierung Oracle Performance für TPC Benchmark

 

 

Zeitraum:          September 2011 

Name des Projekts: Oracle Performance Tuning

Kunde:             Kühne + Nagel, Hamburg

Branche:           Logistik

Kurzbeschreibung:

- Analyse Oracle Performance Logistik Data Warehouse

- Vorschläge zur Performance-Steigerung inklusive Umsetzung

- Verringerung der Verarbeitungszeit um mehrere Stunden

 

 

Zeitraum:          August 2011

Name des Projekts: “Advanced Oracle Performance Troubleshooting” Seminar

Kunde:             Banking Schweiz

Branche:           Software

Kurzbeschreibung:

- Durchführung Seminar „Advanced Oracle Performance Troubleshooting”

 

 

Zeitraum:          April 2011

Name des Projekts: Oracle University Celebrity Seminar

Kunde:             Oracle University Schweiz

Branche:           Education

Kurzbeschreibung:

- Durchführung Celebrity Seminar „Advanced Oracle Performance Troubleshooting”

 

 

Zeitraum:          November 2010

Name des Projekts: Analyse Datenbank Performance

Kunde:             Telekom

Branche:           Telekommunikation

Kurzbeschreibung:

- Analyse Auslastung und Performance der Datenbank-Komponente eines komplexen Orchestrierungs-Frameworks (BPEL)

 

Zeitraum:          Mai und September 2010

Name des Projekts: Optimierung Data Warehouse

Kunde:             DekaBank Frankfurt

Branche:           Bank

Kurzbeschreibung:

- Analyse Ladevorgänge im Bereich DWH

- Einführung von Datenkompression zusammen mit Umsortierung der Daten beim Laden zur Optimierung der Kompressionsrate

- Platzeinsparungen im Bereich mehrerer GB

- Performancesteigerung Abfragen durch physisches Clustering der Daten

 

 

01/2007 - 03/2010: Deutsche Bank AG, Frankfurt
Operational Risk Management: Reporting
Operational Risk IT Oracle Competence Centre


Operational Risk Management: Reporting
- Entwicklung eines Data Warehouse für Operational Risk Management.
  Integration diverser Datenquellen, Mapping und Homogenisierung der Daten auf
  einheitliches Datenmodell und Referenzdaten

Besondere Anforderungen:
- Reporting-Frontend über Cognos, Berücksichtigung spezifischer Eigenschaften
  von Cognos
- Restatement der kompletten Daten in monatlichem Zyklus in Anpassung an die
  veränderten Referenzdaten (keine "Slowly Changing Dimensions"). Daher musste
  ein Modell gefunden werden, das ein regelmäßiges transparentes Neuladen der
  Daten möglichst effizient umsetzt

Operational Risk IT Oracle Competence Centre
- Zentraler Ansprechpartner bezüglich Oracle Architektur und Performance-Probleme

Verantwortungsbereich/Aufgaben:

Operational Risk Management: Reporting
- Einrichtung CVS-Repository
- Einrichtung Entwickler-Datenbank 10gR2 unter Windows
- Entwurf, Entwicklung und Pflege der Kernmodule des Backend-Prozesses in PL/SQL-
  Packages zum Laden und Transformieren der Daten
- Entwurf und Entwicklung eines geeigneten Partitionierungskonzept für
  transparentes Neuladen des kompletten Datenbestandes
- Performance-Optimierung des Transformations- und Ladevorgangs: Exchange
  Partition
- Performance-Optimierung Reporting

Operational Risk IT Oracle Competence Centre
- Performance-Tuning diverser zeitkritischer Batch- und Reporting-Prozesse
  einer täglichen Massendaten-Verarbeitung (~ 20 Millionen Transaktionen und
  weitere Zusatzdaten mit mehreren Millionen Zeilen)
- Implementierung einer geeigneten Instrumentierung und Protokollierung zur
  einfachen Analyse der zu tunenden Prozessschritte
- Instanz-Tuning und DML-Statement Tuning: Parallelisierung, Ausführungspläne,
  Statistiken

Betriebssysteme:
- AIX 5
- Sun Solaris
- Windows XP
Datenbanken:
- Oracle 10gR2 (10.2), Oracle 9iR2 (9.2.0.8)
Programmiersprachen/Tools:
- SQL*Plus
- SQLTools++
- TOAD 9
- PL/SQL Developer 7
- CVS Versionsverwaltungssystem


07/2005 - 12/2006: Deutsche Bank AG, Frankfurt
Credit Risk Reporting: Projekt dbArtos - Aligned Credit Risk Reporting

- Entwicklung eines Data Warehouse für das Risiko Controlling, regulatorisches Reporting
  und Credit Risk Management.
  Sehr große Datenmengen (Gesamtgröße der Datenbank über 2TB) müssen in möglichst
  kurzer Zeit (< 24h) geladen und transformiert werden, um dann in Form eines Star Schemas
  für Reporting und Delivery zur Verfügung zu stehen.

Besondere Anforderungen:
- Kein klassisches Data Warehouse, keine monatsbezogenen Datenhaltung,
  sondern komplexes, monatsübergreifendes Versionskonzept. Dies bedeutet, dass
  bei jedem Ladevorgang eine neue Version der Daten erzeugt wird, alte Versionen
  sind weiterhin verfügbar und können jederzeit abgerufen werden. Um die gespeicherte
  Datenmenge so klein wie möglich zu halten, unterscheidet sich die physikalische
  Datenhaltung von der logischen Sicht (Daten in komprimierter Form gespeichert,
  ein neuer Datensatz wird nur dann physikalisch gespeichert, wenn er sich tatsächlich
  ändert). Implementierung der komprimierten Datenspeicherung bei der Verarbeitung
  einer so großen Datenmenge war eines der Hauptaugenmerke. Das komplexe Versionierungskonzept
  bietet sogar Branching für "What If"-Analysen.

- Performante Delta-Detection der geladenen Daten ermöglicht Delta-Processing in
  Berechnungsmodulen (bei Datenkorrektur-Lieferungen müssen nur die geänderten Daten
  neu berechnet werden)
- Performante, Meta-Daten gesteuerte Schnittstelle zu "Calculation Engines" in SAS
  (lesender und schreibender Zugriff)
- Ladevorgänge und Transformation komplett über Meta-Daten (XML) konfigurierbar
  und von Fachbereich selbständig pflegbar
- Backend-Prozesse für Meta-Daten Management, Laden und Transformation komplett
  selbst entwickelt, bis hin zur Prozeß-Steuerung (Java-Frontend J2EE) und
  Unix-Prozeßsteuerung
- Reporting-Frontend über MicroStrategy, Zugriff auf Daten über View-Layer, der
  Zugriff für Reporting-System auf komplexe Datenhaltung (Versionierung) vereinfacht,
  Optimierungen für Star Transformation (z.B. Einführung von Rely Constraints)

Verantwortungsbereich/Aufgaben:
- Einrichtung CVS-Repository
- Einrichtung Entwickler-Datenbank 10gR2 unter Linux
- Auswahl geeigneter Tools für PL/SQL-Entwicklung (PL/SQL Developer, Schnittstellen-Plugin
  für PL/SQL-Developer zu CVS Repository: SVC2CVS-Proxy)
- Entwicklung eines standardisierten, automatisierten und auditkonformen Auslieferungsprozesses
  (Code-Delivery und Strukturanpassungen in Datenbank, über Meta-Daten gesteuert)
- Entwurf, Entwicklung und Pflege der Kernmodule des Backend-Prozesses in PL/SQL-Packages
  zum Laden und Transformieren der Daten
- Entwurf und Entwicklung eines geeigneten Partitionierungskonzept (besondere
  Anforderungen aufgrund Versionierung der Daten): Range und Range-List Partitionierung,
  Entwicklung der benötigten zentralen Backend-PL/SQL Packages und Erweiterung/Anpassung der
  bestehenden zentralen ETL-Module für Partitionierung
- Performance-Optimierung des Transformations- und Ladevorgangs (komplexes Versionierungskonzept):
  Parallel DML, Exchange Partition
- Performance-Optimierung Delta-Detection (Parallel Query/DML, Parallel
  Processing PL/SQL Functions)
- Performance-Optimierung Reporting (Zugriff auf komplexe Datenhaltung über View-Layer):
  Dynamisches Partition Pruning vs. explizitem Partition Pruning, Optimierung View Layer,
  Optimierungen Star Transformation (Rely Constraints)

Betriebssysteme:
- Linux
- AIX 5.3
- Sun Solaris
- Windows NT/2000/2003
Datenbanken:
- Oracle 10gR2 (10.2)
Programmiersprachen/Tools:
- PL/SQL Developer 6 und 7
- TOAD 8.6
- SAS 8 und 9
- CVS Versionsverwaltungssystem


01/2005 - 06/2005:
- Oracle DBA bei Lufthansa Systems Infratec, Kelsterbach:
  3rd Level Support, Betreuung/Administration mehrerer hundert Oracle-Datenbanken
  im SAP und non-SAP-Bereich, Datenbanken verschiedener Größe von 50GB bis 1,5TB

Betreuung mehrerer hundert Datenbanken, insbes.
- Administration
- Troubleshooting
- Incident Management
- Performancetuning
- Release- und Patch management
- Change Management
- Capacity Management
- Backup/Restore mittels BR-Tools, RMAN und Veritas Netbackup
- Hotline
- RAC

- Wochenendeinsätze
- Rufbereitschaft
- ITIL Prozeßstrukturen

Betriebssysteme:
- HP-UX
- AIX 4.3, 5L
- Sun Solaris
- Linux
- Windows NT/2000/2003
Datenbanken:
- Oracle 8i
- Oracle 9iR2 (9.2), auch RAC und Standby/Data Guard
Programmiersprachen/Tools:
- Oracle SQL*Plus
- RMAN
- Veritas Netbackup
- BRBackup/Archive/Restore, SAPDBA
- TOAD
- Tora
- CVS Versionsverwaltungssystem
- Peregrine Service Center PSC 5


01/2003 - 12/2004:
- Zusätzlich in folgende Projekte als Oracle Designer und DBA involviert:
- Operational Risk Common Data Framework: Vereinheitlichung und zentrale Wartung

der von verschiedenen Systemen genutzten statischen Daten, incl. Change

Management ("Mapping" der anwendungsspezifischen Bewegungsdaten bei Änderungen

der gemeinsamen Daten)


  - Design und Implementierung der benötigten relationalen Datenbank-Strukturen
  - Schnittstellen-Design und -Implementierung der verschiedenen beteiligten

 Operational Risk Systeme:

 dbNexus (Strukturverwaltungswerkzeug, Datenbereitstellung mittels

 EJB-Interface auf XML-Basis, Umwandlung der bereitgestellten Daten mittels

 XSLT in SQL-Befehle zum Schreiben der Daten in Staging Area),

 Opera Common Database (relationale Datenbank),

 Operational Risk Applikationen:

 dbIRS - Incident Reporting System,

 dbSAT - Bottom Up Self Assessment Tool,

 dbRiskmap - Top Down Self Assessment Tool,

 Reporting Framework - Operational Risk MIS

 Update-Handler, der die betroffenen Bewegungsdaten in den

 Applikationsdatenbanken entsprechend anpasst, PL/SQL-Prozeduren

  - Vergleich von momentanen Daten mit Inhalt der Staging Area =>

 Erstellung eines Delta-Reports

  - Generierung eines Impact-Reports basierend auf Delta-Report: Bereitstellung

 aller betroffenen Bewegungsdaten der verschiedenen Applikationen mittels

 Distributed Queries

  - Mapping der betroffenen Bewegungsdaten  - Generierung eines Validation-Reports der Mapping-Daten  - Update-Handler der individuellen Applikationen zum Laden der geänderten

 Struktur-Daten und Anpassung der betroffenen Bewegungsdaten in den

 jeweiligen Applikationsdatenbanken


- Operational Risk Reporting Framework: anwendungsübergreifendes Reporting,

Entwicklung der Grundlagen eines einheitlichen Operational Risk MIS (Management

Information System) mit Data Warehouse Architecture und OLAP Analyse

  - Design und Implementierung der benötigten Datenbank-Strukturen in

 Data Warehouse Architecture (Star/Snowflake Schema)

  - Aufteilung der Reporting Datenbank in Staging Area,

 Transformation/Refinery/Packaging/Delivery Area

  - Analyse und Implementierung der benötigten ETL (Extraction, Transformation

 and Load)-Prozesse

  - Analyse und Implementierung von Materialized Views für Query-Optimierung

 bei hochverdichteter Aggregierung (Oracle Query Rewrite)

  - Auswahl der benötigten Partitionierungsmethoden (historische Daten)  - Analyse der benötigten Measures/Calculated Measures und Dimensions für

 OLAP-Würfelgenerierung

  - Datenaufbereitung einerseits für klassische MIS-Reports

 (High-Level-Reports mit hoch aggregierten Daten und vielen Grafiken mittels

 Actuate eReporting Suite) und andererseits für OLAP-Analyse (Hyperion Essbase

 und Microsoft Analysis Services)

  - Implementierung eines Approval-Workflows einer MIS-Reporthierarchie

 inkl. Verwaltung eingegebener Report-Kommentare der Bereichsverantwortlichen


  - Betriebssysteme: Windows NT/2000, Linux, Sun Solaris
  - Datenbanken: Oracle 9iR2
  - Programmiersprachen/Tools: Java J2SE 1.3/1.4, Java J2EE 1.3, Application

 Server BEA Weblogic, Enterprise Java Beans, XML/XSLT-Transformation,

 Oracle SQL*Plus, TOAD, SQLNavigator, Tora, Oracle XSQL, Oracle Designer,

 ErWin, Oracle Warehouse Builder, Hyperion Essbase MOLAP,

 Microsoft OLAP Analysis Services, Alphablox OLAP Client



01/2001 - 12/2004:
- dbIRS-Projekt bei der Deutschen Bank, Frankfurt, Oracle-Administration,

 Design, Wartung, Weiterentwicklung und Neuentwicklung einer

 webbasierten Intranet-Applikation

  - Oracle 8i (8.1.6, 8.1.7) und 9i (9iR2) unter IBM RS6000 AIX 4.3/Linux/NT,

 Oracle 9iR2 (9.2) unter Sun Solaris 9/RAC-Konfiguration im 2-Node Cluster

 mit Veritas Cluster Software, Oracle 10g unter Linux

 SQL*Plus, TOAD, SQLNavigator, TOra, Oracle Designer, Apache 1.3.9 mit JServ,

 Java Application Server JBOSS 2.4.x und BEA Weblogic v7 / v8,

 J2SE 1.3/1.4, J2EE 1.3, Java Servlets, Java Server Pages, Java Applets,

 Enterprise Java Beans, Eclipse, Ant BuildTool, CVS Versionsverwaltungssystem

  - Administration der vorhandenen Datenbanken (Produktion, Test, Integration,

 Entwicklungsdatenbanken)

  - Zusammenarbeit mit Java-Entwicklern, Aufbau der benötigten Datenbankstrukturen

 (Historisierung, Objekttabellen, Typdefinitionen, High-Performance Treestructures)

  - Implementierung besonderer Anforderungen

 (partielles Backup, keine Sicherung bestimmter Daten, automatisches Löschen

 bestimmter Daten in einem definierbaren Zeitraum)

  - Performanceoptimierung der bestehenden Anwendungen  - Definition und Implementierung von automatisierten Schnittstellen

 zu Subsystemen (SQL*Loader / PL/SQL usw.), Pflege/Weiterentwicklung bereits

 bestehender Schnittstellen

  - Administration/Überwachung der Produktionsmaschinen  - Aufbau eines Java-basierten Reporting-Systems  - Entwicklung eines generischen adhoc-Reporting-Frameworks,

 Design und Implementierung des Backend-Bereichs

 (Umsetzung Objektmodell => SQL-Abfrage auf relationale Tabellen)

  - Migration verschiedener Datenbanken in ein einheitliches, zukünftiges System

 Hierzu Zusammenarbeit mit DBA in London

  - Aufbau eines neuen Autorisierungskonzepts basierend auf Views

 und FGAC (Fine Grained Access Control) für höchstmöglichen

 Schutz vor unautorisiertem Zugriff auf Daten

  - Erweiterung und Neuaufbau der benötigten Replikationstrukturen  - Administration des verwendeten Versionsverwaltungssystems CVS

 (Concurrent Versions System)

  - Durchführung des Change Managements / Packagings bei Deployment

 von Datenbankänderungen mit Produktions-DBA-Team



seit 1996: Mehrjährige Erfahrung in Oracle DBA-Tätigkeiten
- seit 1996: Aufbau und Administration von über 80 Kunden-Datenbanken,
  Oracle 7 (7.0-7.3), Oracle 8.0, Oracle 8.1 (8i) und Oracle 9i (R1 und R2) auf HP-UX, AIX, SUN Solaris, Linux und NT
  Installation und Einrichtung der Kunden-Datenbanken, Erarbeitung entsprechender
  Basis-Skripts zur automatischen Erstellung der individuell erarbeiteten
  Datenbank-Struktur (keine Oracle-Standarddatenbank)
  1997: Erstellung von UNIX-Skripts zur Automatisierung der Datenbankwartung und
  Sicherung
- 1998: Installation und Konfiguration von Oracle Tools, wie z.B.
  Enterprise Manager (auch Version 2.x), Oracle WebDB (auch Portal 3.0),
  Oracle Discoverer (auch 3i)
- 2000: Aufbau von Hochverfügbarkeitslösungen (Oracle-Standby-Datenbank)
  unter HP-UX und Windows NT


seit 1993: Mehrjährige Erfahrung im Bereich C/C++-Entwicklung
- 1993-1995: Erstellung einer eigenen Faxlösung mit ISDN- und Analogübertragung
  Realisierung mittels Microsoft C, CAS-API und IKernel (ISDN-Highlevel-API)
  FaxServer für DOS, Druckertreiber für MS-Windows und MS-Windows 95
  Windows-FrontEnd in VB (Visual Basic 3.0/4.0)
- 1994: Erstellung eines hardwarenahen NLMs unter Novell 3.x zur DCF77-
  Signalverarbeitung (Empfang der atomgenauen Uhrzeit, Abgleich Server-
  Uhrzeit) mittels WATCOM C/C++
  1996, 1999: Aktualisierung des Moduls für Novell 4.x, 5.x
- 1995: Zusatzentwicklungen an 4GLs: hardwarenahe Programmierung
  (serielle Schnittstelle) zur Ansteuerung KV-Karten-Leser (Microsoft C)
- 1996: Erstellung eines ODBC 1.x-Treibers (mittels ODBC SDK)
  zur Implementierung eines applikationsbezogenen Berechtigungskonzept
  (über das datenbankbezogene Berechtigungskonzept hinaus),
  Zonen-/Rollenkonzept des Produkts KISSMED
  ODBC-Treiber setzt auf existierenden ODBC-Treiber auf und setzt
  Berechtigungskonzept bei Aufruf entsprechender Funktionen um
  1997: Aktualisierung auf ODBC 2.x-Standard, 32Bit
- 1996: Erstellung eines Text-Präprozessors zur konfigurierbaren Ersetzung von
  proprietären Datenbankbefehlen (Ersetzung konfigurierbar mittels Textdatei)
  als DLL unter Windows mittels Microsoft Visual C++
- 1997: Erstellung von Diensten unter Windows NT zur Kommunikation mit
  Kommunikationsservern, Sockets-Programmierung (Microsoft Visual Studio)
- 1997: Erstellung eines Prototyps zur Online-Erfassung von patientenbezogenen
  Vitaldaten am Krankenbett auf PalmOS (z.B. Palm Pilot) mittels PalmOS SDK/
  CodeWarrior Crosscompiler
- 1998: Integration von SmartCard-Reader und proprietärer Cherry-Tastatur-API
  in KV-Karten-Lesebibliothek (siehe 1995)
- 1998: Erstellung von Kommunikationsclients unter UNIX (HP-UX C Compiler,
  GNU C Compiler) für STC DataGate (u.a. Ansteuerung serielle Schnittstelle zur
  Kommunikation mit Siemens HIMED-Anlage)
- 2000: Erstellung von ActiveX-Komponenten unter Windows 9x/NT
  mittels Microsoft Visual C++ (ATL) zur Erweiterung eines eingesetzten
  ActiveX-Controls (ActiveShapes von M&M Software)


seit 1992: Mehrjährige Erfahrung im Schulungsbereich
- Oracle DBA Admin-Schulung
- SQL (Oracle, Allgemein)
- Administration Unix (HP-UX)
- C
- Microsoft Visual C++
- Centura Produkte (SQLWindows, SQLBase)


seit 1994: Mehrjährige Erfahrung im Produktentwicklungsbereich
(Produkt KISSMED => Krankenhausinformationssystem) mit 4GL-Sprachen (Centura)
Oracle-Datenbanken und UNIX-Systemen (HP-UX, SUN Solaris)
Rolle im Projekt:
- Auswahl der Entwicklungswerkzeuge, Datenbanken
- Grundlagenentwicklung, Erarbeiten der Basismechanismen und -bibliotheken


seit 1997: Mehrjährige Erfahrung mit Kommunikationsservern (DataGate) und
Kommunikationsprotokollen (HL7, xDT usw.)
- seit 1997: Aufbau der notwendigen Konfigurationen bei Einsatz von
  Kommunikationsservern im Krankenhausbereich
  Installation und Konfiguration von STC DataGate unter HP-UX und Windows NT
  Erstellung von individuellen DataGate-Konfigurationen für Ankopplung
  verschiedenster Subsysteme (Labor, Küche, Telefonanlage usw.)


1999: Erstellung von plattformunabhängigen, mehrsprachigen Oracle-DBA-Werkzeugen
mittels Java (JDK 1.1.7, 1.2.1/Swing/JDBC) zur Automatisierung und
Vereinfachung administrativer Aufgaben durch grafische Oberfläche


2000: Evaluation der Software AG Produkte Bolero (4GL) und Tamino (XML/SQL-Datenbank)
für die Vereinheitlichung der Dokumentation auf Basis von XML
- Erstellung und Verwaltung der Dokumentation in nur einem Quellformat
  modularisierbar wie dazugehörige Applikationsfunktionalität, d.h.
  eine Funktionalität auch nur einmal dokumentiert, egal wie oft verwendet
- Automatische Erzeugung der vugung der verschiedenen Zielformate (PDF, HTML, Windows-
Online-Hilfe usw.) mittels XSL-Stylesheets

Referenzen

Projekt dbArtos - Aligned Credit Risk Reporting, 07/05 - dato
Referenz durch Projektleiter, gr. dt. Finanzinstitut, vom 26.10.06

"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 Oracle DBA, 01/05 - 06/05
Referenz durch Teamleiter der Lufthansa Systems Infratec GmbH, vom 13.06.05

"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 dbIRS - Incident Reporting System
Referenz durch Projektleiter Deutsche Bank AG vom 07.11.03

"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 Opera Application Framework from 01/03 - to date
Referenz durch Project Manager, Deutsche Bank AG in Frankfurt from 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 Operational Risk Reporting Framework von 01/03 - dato
Referenz durch Projektleiter, Deutsche Bank AG vom 13.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 dbIRS (Incident Reporting System), seit 01/01
Referenz durch Projektleiter Deutsche Bank AG, Frankfurt vom 24.04.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 Oracle DBA im Bereich Operational Risk - seit Januar 2001
Referenz durch Teammanager/Projektleiter Deutsche Bank AG vom 14.03.02

"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."

Branchen

- Banken, Versicherungen
- Industrie (Logistik, Grund- und Stadtentwicklung)
- Gesundheitswesen, Medizin
- ...

Kompetenzen

Programmiersprachen
Basic
Visual Basic (Version 3 bis 6)
C
Visual C/C++ (V1.52 (16bit) bis Visual Studio Version 6), Borland C++ (Version 3 bis 5)
C++
Visual C/C++ (V1.52 (16bit) bis Visual Studio Version 6), Borland C++ (Version 3 bis 5)
CodeWarrior
Version 2 bis 4 (auf PC), auch als Crosscompiler (PalmOS SDK)
CORBA IDL
in Zusammenhang mit EJB/Java/Oracle 8i
Delphi
Version 2 und 3
Gupta, Centura
SQLWindows, SQLWindows 32, CTD, auch TOM, CDK usw.
Java
JDK 1.1.x, 1.2.x, 1.3, 1.4, Beans, EJB, Swing/JDBC, SQLJ, JSP
JavaScript
JDK 1.1.x, 1.2.x, 1.3, 1.4, Beans, EJB, Swing/JDBC, SQLJ, JSP
Lisp
STC DataGate-Programmierung (MONK basierend auf LISP)
Makrosprachen
VBA, WordBasic
Pascal
Turbo Pascal, Borland Pascal, später Delphi
PL/SQL
Oracle 7 und 8, 8i, 9i, WebDB und Portal 3.0 (PSP PL/SQL Server Pages)
SAL
SQLWindows und SQLWindows/32 (CTD)
Scriptsprachen
awk (Unix)
Shell
Bourne shell, Bourne again shell (bash) Posix-Shell (HP-UX), Korn Shell, awk-Programmierung

Betriebssysteme
HPUX
10.20, 11
MS-DOS
Novell
3.x, 4.x, 5.x
PalmOS
Erfahrung mit PalmOS SDK
SUN OS, Solaris
2.5, 2.6, 7, 8
Unix
AIX, Linux, SCO
Windows
3.x,95,98,NT,2000, XP

Datenbanken
Access
Adabas
Version 7 und 11
BDE
Version 5.x (Delphi)
Gupta, Centura
SQLBase 5, 6, 7, 7.5
JDBC
Lotus Notes
MS SQL Server
4.2, 6.5, 7, 2000 & Analysis Services (MS OLAP)
ODBC
Oracle
7.0-7.3, 8.0, 8i, 9i, 9iR2, 10g, 10gR2
Oracle Database
Oracle Database Performance Troubleshooting
Oracle Database Performance Tuning
Oracle Exadata Database Machine
SQL
Oracle SQL, Microsoft SQL

Sprachkenntnisse
Deutsch
Muttersprache
Englisch
verhandlungssicher

Hardware
HP
HP 9000-Server (A, D, K, L und R-Klasse)
IBM RS6000
F50, P43
PC
Mehrprozessor High-End-Systeme mit Hardware-Cache-Controller
SUN
Enterprise 3000, 4000, 3500, 4500

Datenkommunikation
Novell
Router
RPC
SMTP
SNMP
TCP/IP
Winsock

Produkte / Standards / Erfahrungen
- Mehrjährige Erfahrung in Oracle DBA-Tätigkeiten, Performance Tuning, Troubleshooting, Datenbank-Architektur und -Design

- Erstellung von UNIX-Skripts zur Automatisierung der Datenbankwartung,
Sicherung, vor Einsatz des Oracle Enterprise Backup-Utilities

- Mehrjährige Erfahrung im Bereich C/C++-Entwicklung (Zusatzentwicklungen an
4GLs, z.B. hardwarenahe Programmierung (serielle Schnittstelle), Sockets-
Programmierung, Erstellung von Diensten unter Windows NT, Erstellung von
ActiveX-Komponenten unter Windows 9x/NT, Erstellung von Services unter UNIX
Erstellung eines hardwarenahen NLMs (DCF77-Signalverarbeitung) unter
Novell 3.x,4.x,5.x, Erstellung eines eigenen ODBC 1.x/2.x-kompatiblen Treibers)

- Microsoft OLAP (SQL Server 2000 & Microsoft Analysis Services), ETL-Prozeß,
Überführung der OLTP-Daten in Data Warehouse, Implementierung Star-Schema,
Definition und Implementierung der benötigten Dimensionen, Kennzahlen und
berechnete Kennzahlen, Definition der OLAP-Würfel

- Erstellung von plattformunabhängigen, mehrsprachigen DBA-Werkzeugen
mittels Java (Swing/JDBC)

- Mehrjährige Erfahrung im Schulungsbereich (Oracle DBA, SQL, Microsoft Visual C++,
Centura Produkte)

- Mehrjährige Erfahrung im Produktentwicklungsbereich (Produkt KISSMED
=> Krankenhausinformationssystem) mit 4GL-Sprachen,
Oracle-Datenbanken und UNIX-Systemen (HP-UX, SUN Solaris)

- Mehrjährige Erfahrung mit Kommunikationsservern z.B. DataGate, CloverLeaf
und Kommunikationsprotokollen (HL7, xDT usw.)

- Erfahrung mit Software AG Produkten (Bolero, Tamino (XML/SQL-Datenbank))


Bemerkungen

Mitglied des OakTable Networks, einer informellen Vereinigung von
Oracle-Spezialisten (Oracle "Scientists") weltweit. 100 Mitglieder weltweit,
nur zwei Mitglieder in Deutschland

Auszeichnungen: Oracle ACE Director

- einer von 110 weltweit
- einer von 40 Oracle ACE Directors weltweit im Bereich "Datenbank Performance"
- einer von vier in Deutschland

Oracle Certified Professional (OCP) DBA 8i:

- Introduction to Oracle: SQL and PL/SQL
- Oracle 8i: Architecture and Administration
- Oracle 8i: Backup and Recovery
- Oracle 8i: Network Administration
- Oracle 8i: Performance Tuning

bereits durchgeführt und bestanden
und damit Zertifikation abgeschlossen.

Oracle Certified Professional (OCP) DBA 9i:

- Oracle 9i: New Features for Administrators

bereits durchgeführt und bestanden
und damit Zertifikation abgeschlossen.

Oracle Certified Professional (OCP) DBA 10g:

- Oracle 10g: New Features for Administrators

bereits durchgeführt und bestanden
und damit Zertifikation abgeschlossen.


Ausbildungshistorie

- Studium der Informatik an der TU Karlsruhe

- Oracle Certified Professional 10g DBA
- Oracle Certified Professional 9i DBA
- Oracle Certified Professional 8i DBA

- Microsoft Certified Professional
- Novell Professional Developer