EntwicklungEffiziente Historisierung großer TabellenTobias Stark, metafinanz GmbHBei der nachträglichen Historisierung von...
Entwicklung                                                •	   Anpassung der Partitionierung              •	   Einsatz vo...
Entwicklung                              GETS                                           MISSES                            ...
Nächste SlideShare
Wird geladen in …5
×

Effiziente Historisierung großer Tabellen

1.602 Aufrufe

Veröffentlicht am

[14.08.2009] Bei der nachträglichen Historisierung von Daten in großen Tabellen ist es von Anfang an wichtig, auf die Performance zu achten. Je mehr Datensätze anzupassen sind, desto entscheidender wird die Wahl der technischen Vorgehensweise.

Veröffentlicht in: Business
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.602
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
10
Aktionen
Geteilt
0
Downloads
11
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Effiziente Historisierung großer Tabellen

  1. 1. EntwicklungEffiziente Historisierung großer TabellenTobias Stark, metafinanz GmbHBei der nachträglichen Historisierung von Daten in großen Tabellen ist es von Anfang an wichtig, auf die Performance zuachten. Je mehr Datensätze anzupassen sind, desto entscheidender wird die Wahl der technischen Vorgehensweise.Gerade DML-Operationen wie Updates durch Folgesysteme auch noch weitere nicht zu groß wurde, fiel die Entschei-führen bei großen Datenmengen häu- Attribute wie eine Verarbeitungsnum- dung, die Historisierung unabhängigfig zu Problemen. Um auch in solchen mer anzupassen. Durch die Paralleli- von der Ladung immer nur für eineSituationen akzeptable Verarbeitungs- sierung waren bei Tests mit kleineren Tabelle durchzuführen. Dabei tratengeschwindigkeiten zu erreichen, stellt Datenmengen in der Entwicklungs- jedoch trotz der Parallelisierung Lauf-die Oracle Datenbank Möglichkeiten umgebung gute Ergebnisse zu erzielen. zeiten von mehr als acht Stunden fürwie PL/SQL-Tabellen, BULK-Verarbei- Aufgrund der Testergebnisse kam diese eine Tabelle auf.tung und Parallel DML zur Verfügung. Lösung in der Produktionsumgebung Zur Historisierung von Daten in ei- zum Einsatz. Problem-Analysener Basis-Datenbank wurde von einem Nach einer Urladung mit rund 520Kunden des Autors eine Lösung in PL/ Millionen Datensätzen in der Produk- Um die Ursache für die Performance-SQL entwickelt. Diese PL/SQL-Anwen- tivumgebung und einem täglichen Probleme zu finden, wurden mehreredung hatte dabei zu jedem Datensatz Delta von bis zu 21 Millionen Daten- Analysen durchgeführt. Zum einendie Gültigkeit bei neuen Datensätzen sätzen kam es jedoch bei mehreren erfolgte während der Historisierungeinzutragen beziehungsweise bei älte- Tabellen zu Performance-Problemen. einer Tabelle mit sechs Prozessen eineren Datensätzen zu aktualisieren, und Damit die Belastung des Datenbank- Auswertung der auftretenden Wait-zwar nach Art einer „Slowly Changing Servers durch die parallelen Prozesse Events (siehe Tabelle 1).Dimension (SCD) Typ 2“ in „gültigvon/gültig bis“-Attribute. Durch die-ses Vorgehen lag die Anzahl der er-warteten, anzupassenden Datensätzebei Delta-Ladungen für einige Tabel-len täglich im Millionen-Bereich. Umdiese Mengen in annehmbarer Zeit zuverarbeiten, wurden mehrere Prozesseparallel per DBMS_JOB gestartet. EinMaster-Prozess sammelte die zu bear-beitenden fachlichen Schlüssel in einertemporären Tabelle und übergab diesedann per Pipes an die parallel gestarte-ten Jobs als Slave-Prozesse. Die Aufgabeeines solchen Slave-Prozesses bestanddarin, zu jedem Datensatz des überge-benen Schlüssels die Gültigkeit zu er-mitteln und diese anschließend in dieHistorisierungs-Attribute zu schreiben. Dabei wurden die zu dem Schlüsselvorhandenen Daten nebst ROWID perIndexzugriff in eine PL/SQL-Tabelleeingelesen. Danach erfolgte die Er-mittlung der „gültig von/gültig bis“-Daten in der PL/SQL-Tabelle im Spei-cher. Zum Schluss wurden die Datenper Einzelsatzverarbeitung anhandder ROWID in die Tabelle geschrieben.Neben der Gültigkeit waren für dieIdentifizierung der geänderten Daten Abbildung 1: Ablauf ursprüngliche Historisierung DOAG News Q3-2009 |  55
  2. 2. Entwicklung • Anpassung der Partitionierung • Einsatz von Parallel DML Wait-Event Waits gesamt Das historische Attribut wurde aus Durch den Einsatz von Parallel DML db file sequential read 5.637.171 latch: shared pool 463.396 den Kriterien für die Partitionierung beim Anpassen der Daten in den Ta- latch: library cache 9.303 herausgenommen und die Tabellen bellen war es möglich, die Histori- latch: row cache objects 3.679 neu partitioniert. Dadurch war ein sierung direkt im Anschluss an das latch: library cache lock 73 Verschieben von Datensätzen zwi- Laden der Deltadaten durchzufüh- schen Partitionen nicht mehr not- ren. So war keine asynchrone, seri-Tabelle 1: Wait-Events bei Historisierung wendig. elle Verarbeitung der Tabellen mehrmit sechs Prozessen • Nutzung von BIND-Variablen statt notwendig. LiteralenZudem erfolgte ein Review des PL/ Bei der Ausführung der dynami- Aufgrund der Komplexität und umSQL-Codes. Dabei wurde festgestellt, schen SQL-Anweisungen wurden nicht sämtliche Datensätze nochmalsdass bei den dynamischen SQL-Anwei- statt der vorher genutzten Literale verarbeiten zu müssen, hat man densungen Literale wie die ROWID zum die Daten per BIND-Variablen über- Kernbestandteil zur Ermittlung der His-Einsatz kamen. Dies deckte sich auch geben. Darüber hinaus ergab sich, torisierung nicht geändert. Bevor dasmit den beobachteten Latch-Waits, die dass der Zusammenbau der dynami- Anpassen der Daten per Parallel DMLein Hinweis auf das häufige Parsen von schen SQL-Anweisungen nur noch implementiert wurde, kam in einerSQL-Anweisungen sind. einmal zu Anfang der Verarbeitung Zwischenversion ein Update per BULK Auch beim Layout der Tabellen tra- durchgeführt werden musste. Die zum Einsatz. Diese Zwischenversionten einige problematische Punkte auf. Ermittlung bei jedem zu bearbeiten- erwies sich auch für nicht partitionier-Durch das Lesen anhand des fachli- den Datensatz konnte dadurch ent- te Tabellen als erfolgreich. Bei partitio-chen Schlüssels kommt es gerade bei fallen und die CPU-Belastung sank. nierten Tabellen jedoch war die Lauf-großen Tabellen beim Index-Zugriff • Vermeidung von Index-Zugriffen zeit für den Update von 5,4 Millionenzu längeren Laufzeiten, insbesondere Das Sammeln der zu bearbeitenden Datensätzen mit 9,5 Stunden weiter-dann, wenn die zu lesenden Datensätze Datensätze in einer temporären Ta- hin zu hoch. Die Statistiken der obenüber unterschiedliche Datenbankblö- belle vermied den Indexzugriff über genannten Latches ließ sich durch diecke verstreut sind. Darauf weist auch den fachlichen Schlüssel. vorgenommenen Anpassungen jedochdie Zahl der beobachteten „db file se- • Nutzung von BULK-Verarbeitung bereits signifikant verbessern, so dassquential read“ hin. Die zu schreibenden Historisie- eine Entlastung der Ressourcen fest- Neben dem Zugriff beim Lesen über rungsdaten werden in PL/SQL-Ta- stellbar war (siehe Tabelle 2).den Index gab es die Problematik, bellen zwischengespeichert und perdass eins der historischen Attribute BULK-Insert in eine Tabelle für die Einsatz von Parallel DMLals Kriterium für die Partitionierung anschließende Nutzung mittels Pa-zum Einsatz kam. Dadurch entstand rallel DML geschrieben. Durch die Um auch für partitionierte Tabellenbeim Schreiben der Daten zusätzlich BULK-Verarbeitung lassen sich die eine Verbesserung der Laufzeiten zu er-ein Verschieben von Datensätzen von bei Einzelsatzverarbeitung auftre- reichen, wurde die Nutzung von Paralleleiner Partition in eine andere. Zusätz- tenden Wechsel zwischen PL/SQL- DML implementiert. Für dessen Einsatzlich war auch noch ein Index auf der und SQL-Engine minimieren. sind folgende Bedingungen zu beachten:Verarbeitungsnummer der geändertenDaten zu pflegen.IdentifizierteVerbesserungsmöglichkeitenUm das Performanceproblem in denGriff zu bekommen, wurden die fol-genden Verbesserungsmöglichkeitenidentifiziert:• Entfernung des Index auf der Verarbei- tungsnummer. Da sich der Index für die lesenden DWH-Systeme als nicht hilfreich er- wiesen hatte, wurde er entfernt. Da- durch war eine Pflege dieses Index bei der Historisierung nicht mehr notwendig. Abbildung 2: Ablauf angepasste Historisierung56  | www.doag.org
  3. 3. Entwicklung GETS MISSES SLEEPS Version alt neu alt neu alt neu shared pool 2.100.566.433 29.658.667 131.602.673 1.066.005 2.740.417 715 library cache 1.604.674.472 23.173.192 19.110.037 968.176 82.488 577 library cache lock 403.277.029 8.458.705 907.972 631.276 358 157 row cache objects 6.387.481.148 46.192.372 210.970.588 398.618 17.167 159Tabelle 2: Mess-Ergebnisse• Parallel DML muss in der Session aktiv sein: UPDATE /*+ PARALLEL(upd_view,10) */ ALTER SESSION ENABLE PARAL- (SELECT /*+ PARALLEL(tgt,10) LEL DML; PARALLEL(src,10)• Erfolgt die Verarbeitung mittels ei- */ nes „updatable join“-Views, ist ein src.dat_von AS new_dat_von Primary-Key auf einer der Tabellen ,src.dat_bis AS new_dat_bis erforderlich. ,:p_verarbeitungs_id AS new_verarb_id ,tgt.dat_von AS dat_von• Weitere Voraussetzungen für den ,tgt.dat_bis AS dat_bis Einsatz von Parallel DML sind im ,tgt.id AS id Oracle Data Warehousing Guide zu FROM tab_ziel tgt finden. ,tab_hist_daten src WHERE 0 = 0Da die zu schreibenden Daten der his- AND tgt.rowid = src.v_rowid ) upd_viewtorischen Attribute in einer tempo- SET upd_view.dat_von = upd_view.new_dat_vonrären Tabelle vorliegen, kommt zum ,upd_view.dat_bis = upd_view.new_dat_bisUpdate ein„updatable join“-View zur ,upd_view.vearbeitungs_id = upd_view.new_ver-Anwendung (siehe Listung). arb_id Durch den Einsatz von Parallel DML ;sank die Laufzeit zur Durchführung Listing: SQL-Anweisung für Parallel DML mit einem „updatable join“-Viewdes Updates bei partitionierten Tabel-len für 7,5 Millionen Datensätze auf 10Minuten. denen man mit Inserts arbeitet, sind Weitere Informationen aufgrund der in den meisten Fällen Fazit besseren Laufzeit vorzuziehen. Doch Parallel DML im Oracle Data durch die von Oracle in der Enterpri- Warehousing Guide:Derzeit findet in dieser Form täglich se Edition zur Verfügung gestellten http://download.oracle.com/docs/cd/bei fast 100 Tabellen erfolgreich eine Möglichkeiten wie PL/SQL-Tabellen, B19306_01/server.102/b14223/Historisierung statt. Normalerweise BULK-Verarbeitung und Parallel DML usingpe.htm#sthref2120sind Updates von vielen Datensät- lassen sich auch große Tabellen per Kontakt:zen auf großen Tabellen wenn mög- Update mit annehmbaren Laufzeiten Tobias Starklich zu vermeiden. Lösungen, bei bearbeiten. tobias.stark@metafinanz.de Ko ste ww DBora von Oracle-Datenbankadministration nlo se rD w. ve nt einfach, schnell und sicher ow nlo ar a. ad de Tri Mit DBora vereinfacht sich die tägliche Datenbankadministration spürbar. al-V er Dafür wurden viele wichtige Werkzeuge in die Anwendung integriert. sio n • Wartung der Instanz • SQL-Plan Base-Lines • Backup • Storage Management • Tablespaces • SQL-Analyse • Sessions • ReDoLog-Dateien • Reverse Engineering • Auditing • Undo/Rollback-Segmente • Flashback • Memory Management • Resource-Management • Datenbankdokumentation • Statistics Management • Security • und vieles mehr Und das Beste zum Schluss: Sie gehen kein Risiko ein. Testen Sie DBora 30 Tage lang kostenlos und überzeugen Sie sich. DOAG News Q3-2009 |  57

×