Täglich 200 Millionen Inserts: Aufbau eines weltweiten Chip-Analyseportals mit Oracle 10g und Advanced PL/SQL Kariem Yehia Dialog Semiconductor GmbH.

Präsentation zum Thema: "Täglich 200 Millionen Inserts: Aufbau eines weltweiten Chip-Analyseportals mit Oracle 10g und Advanced PL/SQL Kariem Yehia Dialog Semiconductor GmbH."—  Präsentation transkript:

1 Täglich 200 Millionen Inserts: Aufbau eines weltweiten Chip-Analyseportals mit Oracle 10g und Advanced PL/SQL Kariem Yehia Dialog Semiconductor GmbH Jochen HInderberger Dialog Semiconductor GmbH Kirchheim / Teck

2 Agenda Kurze Information über Dialog Semiconductor
Die erste Datenbank: Eine Leidensgeschichte Anforderungen an das neue Portal Technische Implementierung: Der Umgang mit Massendaten und PL/SQL als Kern der Datenbank Neue Applikationen und Auswertungen Konsequenz: Performanceprobleme Die neue Datenbank: Eine Erfolgsstory

3 Informationen über Dialog Semiconductor
Expertenwissen in der Entwicklung von komplexen analogen und digitalen Schaltkreisen „Fabless“ Entwickler von Lieferant von Mixed-Signal IC-Lösungen Pionier in der Entwicklung von ASIC-Lösungen für Mobile Endgeräte Weltweite Niederlassungen, ca. 250 Mitarbeiter Führend in den Produktbereichen in Power Management und Audio-Codecs Über 400 Mio. Dialog-Chips in mobilen Endgeräten verbaut System-on-chip (SoC)-Lösungen für Industrieanwendungen Entwicklung 100% in CMOS Innovative Chip-Lösungen für Mobiltelefone der Generationen 2,5G, 3G, GPRS und CDMA Breites Kundenportfolio:

4 Wo fallen bei der Chip-Herstellung Daten an ?
Jeder Fertigungsschritt generiert unterschiedliche Datenvolumina Wichtigste Datenquellen: Qualitätsdaten aus Wafer Test/Final Test typ. 60kB / Chip d.h. 300MB / Charge (komprimiert) 6-7 GB Rohdaten pro Tag Datenbankgestützte Auswertungen unerlässlich! Foundry Wafer Test Assembly Burn-In Final Test Tape&Reel

5 Die erste Datenbank: Eine Leidensgeschichte
Erste Generation der Anwendung einer Produktionsdatenbank in 1999/2000 durch Consultant basieren auf vorverdichteten ASCII-Daten Akzeptanz gleich Null ! Ursachen: Ungeeignetes Tabellendesign, schwer verständlich für den Endnutzer schlechte Indizierung, typ. Abfragen ~ 45 min !! Zu viele WHERE-Bedingungen notwendig, „automatische“ Aggregation führt sonst zu Fehlinterpretationen Oracle Discoverer als Abfragewerkzeug Tiefergehende Informationen nötig für sinnvolle Analysen und Auswertungen Redesign der Datenbankanwendung unbedingt notwendig !

6 Anforderungen an das neue Portal: Projekt RDA
Ehrgeiziges Ziel: Speicherung aller Prüfdaten jedes Chips in der Produktions-Datenbank ! typ. 500 Messwerte pro Chip typ Chip-Tests pro Tag 200 Mio. Messwerte pro Tag Weshalb ? Qualität: Einfache Bearbeitung von Kundenrückfragen Analysemöglichkeiten Yield-Monitoring: Schwankungen in der Ausbeute können sofort analysiert werden Einfache Anbindung von 3rd-Party-Analyse-Software möglich Data Mining: Möglichkeit zur Anwendung von DM-Algorithmen zur automatisierten Analyse somit vorhanden

7 HTTP-Server Apache / Tomcat
Architektur Phase I Oracle 9i / Solaris 9 Tabellen PL/SQL Abstraktions schicht - Funktionen - Trigger - Prozeduren HTTP-Server Apache / Tomcat JDBC (Thin) Interne Rohdaten 10 Mio. Rd/day via - OCI

8 Wie finden die User zu Ihren Daten ?
Web-basiertes Reporting-System Keine Client-Installation beim End-User nötig Zugriffsteuerung für einzelne Reports & Aktionen möglich Durch Standardreporting zuverlässige und fehlerfreie Analysen incl. Hilfesystem für math. Berechnungsvorschriften Eigene Konfiguration: Typ. Darstellungsformen

9 Technische Implementierung
Entwicklung eines verbesserten Tabellendesigns Die erste Frage lautet immer: Welche Auswertungen werden benötigt ? Drill Down Web Reporting für einfachen Datenzugriff Prüfauftragsinformation Bin Definitionen Test Definitionen Statistische Daten Histogramm Daten Fail Pareto Daten Einzelmessergebnisse (Rohdaten) usw. Vorverdichtete Daten Rohdaten Einfache Auftragsdaten Zusätzliche Auftragsdaten Vorverdichtung der Daten zur Ladezeit mittels PL/SQL Trigger Intelligente Indizierung für gesteigerte Performance  Zeile 1-3 Aufgrund der sehr großen Datenmenge war es unumgänglich unser Webreporting mittels des Drill Down Prinzips leicht bedienbar zu machen. So ist es beispielsweise möglich sich Informationen über mehrere Produkte anzuschauen, danach ein Produkt auszuwählen, sich aus diesem Produkt ein Los (typisch: 25 Wafer, bis zu Chips) auszuwählen, statistische Kenngrößen zu vergleichen, spezielle Tests, Häufigkeitsverteilungen,... Anzuschauen – im Extremfakk bis zu den einzelnen Messergebnissen eines einzelnen Chips.  Also ein typisches Drill down Prinzip Und trotzdem sollten auch querschnittliche Analysen möglich sein, z.B. Monitoring eines speziellen Parameters über mehrere Wochen und somit über 100-tausende von Chips. Abbildung Daher haben wir uns für den Aufbau einer hirarchischen Tabellenstruktur entschieden, die mehrere Ebenen von vorverdichteten Daten enthält. Das Datenbank Layout habe wir also an die jeweiligen Anforderungen angepasst.  Zeile 4 So werden zum Beispiel direkt beim Laden der Testergebnisse eines Wafers dessen Einzelmessergebisse statistisch ausgewertet und die Ergebnisse in einer Statistiktabelle abgelegt, es werden für jeden Test Häufigkeitsverteilungen erstellt und diese in einer Histogrammtabelle abgelegt,... Alle diese Tabellen sind mit einer gemeinsamen und für jeden Testrun eindeutigen ID verknüpft, die wir aus einer Sequence selektieren. Die Vorverdichtung der Daten wird dabei in PL/SQL Triggern ausgeführt – dazu später mehr...  Zeile 5

10 Der Umgang mit Massendaten
Je tiefergreifender die Analyse, desto mehr Datensätze Rollierende Datenhaltung, je nach Aggregationsstufe Partitionierung der Daten und Nutzung von lokalen Indizes auf unterster Ebene (ca. 70% der Daten) Partitionierung mittels Zeitcodierung in der ID  einfach Zuordnung auch für den Menschen  deutliche Performancesteigerung bei selects UND beim löschen  Zeile 1 + Pyramide Die hirarchische Tabellenstruktur spiegelt auch die jeweils darin enthaltende Datenmenge wieder. Umso tiefer in die Daten eigestiegen wird, umso mehr Daten stehen für die Analyse zur Verfügung. Da nicht unendlich viel Platz zur Verfügung steht und für spätere Analysen auch vorverdichtete Daten ausreichend sind... Zeile 2 ...habe wir uns für eine rollierende Datenhaltung, je nach Aggregationsstufe entschieden. Während also allgemeine Losinformationen, wie z.B. die Ausbeute mehrere Jahre vorgehalten wird, werden Rohdaten, also die unverdichteten Einzeltestergebnisse nur 6 Wochen vorgehalten. Die Vorhaltezeiten der Schichten dazwischen, wurden an unsere typischen Auswertezyklen angepasst. Natürlich ist es auch nach Jahren noch möglich alle Messdaten von Kundenrückläufern wieder einzuladen, da die Rohdaten außerhalb der Datenbank seperat monatlich gesichert werden. Zeile 3+4+5 Um der großen Datenmenge auf der untersten Ebene Herr zu werden, nutzen wir die Möglichkeit der Partitionierung. Dazu versehen wir unsere eindeutige testrun ID mit einer Zeitinformation, also Jahr und Kalenderwoche. Mittels dieser ID teilen wir die Daten auf wöchentliche Partitionen auf. Dadurch konnten wir einen extremen Performancezuwachs verzeichnen. Besonders deutlich ist dies beim löschen alter Daten zu sehen Abbildung Um die Daten einer Woche mittels delete aus einer normalen Tabelle zu löschen waren ...h notwendig, mittels eines drop partition erhalten wir dasselbe Resultat in wenigen Sekunden.

11 Der Umgang mit Massendaten
Logging Probleme: Verringerte Datenbankperformance für die Anwender Großer Platzverbrauch Logging der untersten Ebene ist für uns nicht von Vorteil NO_LOGGING und /*+append*/ bei insert Delete von Massendaten mittels drop partition Welche typischen Probleme sind im Umgang mit Massendaten noch zu lösen? ... Natürlich: logging!  Zeile 1 Die inserts und deletes jeder einzelnen row werden geloggt. Dies führte uns zu folgenden Problemen Zeile 2+3+4 Die Datenbank benötigt vor allem einiges an I/O Performance für den logwriter, der Platzverbrauch nimmt drastisch zu – und das alles, ohne das wir dafür Vorteile haben. Denn zum Thema Sicherheit: die Rohdaten werden bei uns ja wie schon erwähnt seperat nochmals archiviert.  Zeile 5 + Abbildung Daher haben wir uns dafür entschieden, die Daten der untersten Ebene unter Verwendung mit nologging Tabelle und Tablespace und dem +append hint einzufügen. Dies führte zu einer deutlichen reduzierung des loggings, wie man an dem Beispiel mit den oracle demo Daten aus dem sh Schema in der Abbildung deutlich sehen kann. (Erklärung der Abbildung) Zeile 6 Das Problem des loggings beim delete haben wir bereits durch unsere partitionierte Tabellen gelöst, ein drop Partition erzeugt kein messbares logging  Das logging der restlichen 20% unserer Daten befindet sich in einem für uns akzeptablen Rahmen

12 PL/SQL Abstraktionsschicht
Notwendig für schnelles Online-Reporting t: ... x: A: t B: x C: D: --main function A B C D Vorteile von PL/SQL Code in der Datenbank Flexibel Wiederverwendbarer / verschachtelter Code Übersichtlich und gut wartbar Schnell durch effizientes Datenbank-caching  Zeile 1+2  Um das Design des Webreportings und dessen Wartung möglichst einfach zu halten und sich an der Stelle ausschließlich auf die Visualisierung der Daten und auf die Bedienbarkeit zu konzentrieren, wurde innerhalb unserer Reporting engine möglichst auf zusätzliche Vorberechnungen und Auswertungen der Daten verzichtet. Daher konzentriert sich unsere Auswertelogik in der Datenbank. Dies ist notwendig für ein schnelles online Reporting, dann jetzt werden nur noch die Anzahl der aufbereiteten Daten „geliefert“ und alle Joins und andere Vorverdichtungen durch Aggregationen schon vorher in der DB durchgeführt. Dies entlastet die CPU des Reporting Servers und verringert in großem Maße die I/O Last.  Zeile 3 Weitere Vorteile einer solchen Aufbereitungsschicht sind: Zeile Abbildung Ein hohes Maß an Flexibilität: Tür und Tor für alle nur erdenklichen Datenberechnungen und Verknüpfungen stehen offen. Wiederverwendbarkeit von Code. Der Funktionsansatz und strukturierte Programmierung kann voll umgesetzt werden. Dadurch wird der Code übersichtlicher und leichter wartbar. Und letztendlich ist die Abbarbeitung von PL/SQL in der Datenbank auch äußerst Effizient, da die Daten innerhalb der Datenbank bleiben und das Caching voll greift.

13 Pipelined Table Functions
Zusätzliche Vorteile von Pipelined Table Functions Wirken nach außen wie eine Tabelle Können im Vergleich zu Views Inputparameter verarbeiten höchste Flexibilität Liefern genau die aufbereiteten Daten zurück, die für das Reporting benötigt werden Live Demonstration und kurze Einführung in PTFs Zeile 1 Das höchste Maß an Flexibilität erhält man durch die Verwendung von Pipelined Table Funktions in der Aufbereitungsschicht für das Reporting. Zeile 2 PTFs wirken nacuh außen wie eine Tabelle, es können „ganz normale“ selects darauf ausgeführt werden Zeile 3 PTFs können aber im Vergleichzu views Inputparameter verarbeiten und ... Zeile 4 ...liefern daher genau die Daten zurück, die für das jeweilige Reporting benötigt werden. Zeile 5 Um die Mächtigkeit dieser PTFs und doch recht einfache Handhabung zu demonstrieren, möchte ich anhang einiger Beispiele eine kurze Einführung in PTFs geben...  Live Demo

14 HTTP-Server Apache / Tomcat
Architektur Phase II Oracle 9i / Solaris 9 Tabellen Partitionen Tabellen PL/SQL Abstraktions schicht - Funktionen - Trigger - Prozeduren HTTP-Server Apache / Tomcat JDBC (Thin) Clients Interne Rohdaten 200 Mio. Rd/day via - OCI Zuliefererdaten Rd/day via - Perl DBI

15 Import der Produktionsdaten
Einsatz unterschiedlicher Technologien OCI (Oracle Call Interface): Wird lt. Oracle auch innerhalb der Datenbank verwendet Anbindung der STDF-Datenquellen für Bulk-Inserts (bis zu Records / Sekunde erzielbar) Perl-DBI: Ladeskripte für untergeordnete Datenquellen Sehr leistungsfähiges Interface Mehr als Records / Sekunde erzielbar Unterstützt ‚prepare‘ von subsequent-SQL-Statements Sehr kurze Enwicklungszeiten durch Nutzung von OpenSource-Werkzeugen (Eclipse zusammen mit E-P-I-C-Plugin)

16 Wachstumsphasen der Produktions-Datenbank
Integration der Tape- und Reel Daten neue Generation der Datenbank-Anwendung: Integration der Final-Test Daten neue Generation der Datenbank-Anwendung: Integration der Wafer-Test Daten erste Generation der Datenbank-Anwendung: geringes Datenvolumen, dennoch lange Antwortzeiten Konsolidierungs-phase: Automatische Lösch-Jobs komplett in Betrieb, quasi „Wartungsfrei“ (derz. 2.8 Mrd Sätze)

17 Neue Applikationen und Auswertungen Konsequenz: Performanceprobleme
Gründe für Performanceprobleme Up-Time des Filesystems: Performance & Stabilitätsrisiko z.T. Gesamtausfall des Filesystems und der Datenbank Kumulierung der Ladejobs, Verschiebung von Folgejobs Anschaffung eines NAS-Systems statt herkömmlichen RAID-Systems Backup: Nutzung der Snapshot-Technologie des NAS Steigende Zahl an Applikationen Data Engineering Methoden Final Test Data Merging Wafer Map Reconstruction

18 Neue Applikationen und Auswertungen Konsequenz: Performanceprobleme
Abhilfe: Tuning-Workshop mit externem Berater Analyse der Vorgänge Analyse der typischen Vorgänge Laden der Rohdaten PL/SQL-Code in Triggern Auswertungen über Web-Reporting mit Hilfe von statspack Ermittlung des Ressourcen bedarfs Ressourcenbedaf für jedes SQL bzw. PL/SQL Statement ermitteln Ggf. Sofortmaßnahmen einleiten evt. Einleitung von Sofortmass-nahmen: z.B. Log/Redo-Buffer-Größe oder Statistiken Fazit: CPU als Engpaß identifiziert Definition einer skalierbaren, zukunftssicheren Server-Hardware Migration auf Oracle 10g R2 : auf neuer Server Hardware

19 Architektur Phase III Oracle10 g R2 / Solaris 10 Oracle 9i / Solaris 9
Tabellen PL/SQL Abstraktions schicht - Funktionen - Trigger - Prozeduren HTTP-Server Apache / Tomcat JDBC (Thin) Partitionen Clients autom. Feedback-Reports an Kunden & Zulieferer Interne Rohdaten 200 Mio. Rd/day via - OCI Zuliefererdaten Rd/day via - Perl DBI

20 Die neue Datenbank: Eine Erfolgsstory
Testsystem Unbedingt einzuplanen Die ganze Wahrheit: „harmlose “ Oracle-Patches im Produktiv-System Analysezeiten signifikant gesenkt Analysemöglichkeiten: Design-Bug vor Volumenproduktion gefunden Entlastung des DBA als „Query-Builder“ Akzeptanz Erfolgsrezept: Benennung eines „Champions“, für Anforderungen/Methodik Datenbank nun primäre Datenquelle Durch Standardreporting zuverlässige und fehlerfreie Analysen bereitgestellt

21 Fragen ? Vielen Dank für Ihre Aufmerksamkeit !