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

1. Entwicklung
Effiziente Historisierung großer Tabellen
Tobias Stark, metafinanz GmbH
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.
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ängig
fig zu Problemen. Um auch in solchen mer anzupassen. Durch die Paralleli- von der Ladung immer nur für eine
Situationen akzeptable Verarbeitungs- sierung waren bei Tests mit kleineren Tabelle durchzuführen. Dabei traten
geschwindigkeiten 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ür
wie 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-Analyse
ner Basis-Datenbank wurde von einem Nach einer Urladung mit rund 520
Kunden 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 mehrere
dung hatte dabei zu jedem Datensatz Delta von bis zu 21 Millionen Daten- Analysen durchgeführt. Zum einen
die Gültigkeit bei neuen Datensätzen sätzen kam es jedoch bei mehreren erfolgte während der Historisierung
einzutragen beziehungsweise bei älte- Tabellen zu Performance-Problemen. einer Tabelle mit sechs Prozessen eine
ren 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ültig
von/gültig bis“-Attribute. Durch die-
ses Vorgehen lag die Anzahl der er-
warteten, anzupassenden Datensätze
bei Delta-Ladungen für einige Tabel-
len täglich im Millionen-Bereich. Um
diese Mengen in annehmbarer Zeit zu
verarbeiten, wurden mehrere Prozesse
parallel per DBMS_JOB gestartet. Ein
Master-Prozess sammelte die zu bear-
beitenden fachlichen Schlüssel in einer
temporären Tabelle und übergab diese
dann per Pipes an die parallel gestarte-
ten Jobs als Slave-Prozesse. Die Aufgabe
eines solchen Slave-Prozesses bestand
darin, zu jedem Datensatz des überge-
benen Schlüssels die Gültigkeit zu er-
mitteln und diese anschließend in die
Historisierungs-Attribute zu schreiben.
Dabei wurden die zu dem Schlüssel
vorhandenen Daten nebst ROWID per
Indexzugriff in eine PL/SQL-Tabelle
eingelesen. 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 Daten
per Einzelsatzverarbeitung anhand
der ROWID in die Tabelle geschrieben.
Neben der Gültigkeit waren für die
Identifizierung der geänderten Daten Abbildung 1: Ablauf ursprüngliche Historisierung
DOAG News Q3-2009 | 55

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 mehr
mit sechs Prozessen • Nutzung von BIND-Variablen statt notwendig.
Literalen
Zudem erfolgte ein Review des PL/ Bei der Ausführung der dynami- Aufgrund der Komplexität und um
SQL-Codes. Dabei wurde festgestellt, schen SQL-Anweisungen wurden nicht sämtliche Datensätze nochmals
dass bei den dynamischen SQL-Anwei- statt der vorher genutzten Literale verarbeiten zu müssen, hat man den
sungen 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 das
mit den beobachteten Latch-Waits, die dass der Zusammenbau der dynami- Anpassen der Daten per Parallel DML
ein Hinweis auf das häufige Parsen von schen SQL-Anweisungen nur noch implementiert wurde, kam in einer
SQL-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 Zwischenversion
ten 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 Millionen
zu 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 die
cke verstreut sind. Darauf weist auch den fachlichen Schlüssel. vorgenommenen Anpassungen jedoch
die Zahl der beobachteten „db file se- • Nutzung von BULK-Verarbeitung bereits signifikant verbessern, so dass
quential 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 per
dass eins der historischen Attribute BULK-Insert in eine Tabelle für die Einsatz von Parallel DML
als 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 Tabellen
beim 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 Parallel
einer Partition in eine andere. Zusätz- tenden Wechsel zwischen PL/SQL- DML implementiert. Für dessen Einsatz
lich war auch noch ein Index auf der und SQL-Engine minimieren. sind folgende Bedingungen zu beachten:
Verarbeitungsnummer der geänderten
Daten zu pflegen.
Identifizierte
Verbesserungsmöglichkeiten
Um das Performanceproblem in den
Griff zu bekommen, wurden die fol-
genden Verbesserungsmöglichkeiten
identifiziert:
• 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 Historisierung
56 | www.doag.org

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 159
Tabelle 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 = 0
Da die zu schreibenden Daten der his- AND tgt.rowid = src.v_rowid
) upd_view
torischen Attribute in einer tempo-
SET upd_view.dat_von = upd_view.new_dat_von
rären Tabelle vorliegen, kommt zum ,upd_view.dat_bis = upd_view.new_dat_bis
Update 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“-View
des Updates bei partitionierten Tabel-
len für 7,5 Millionen Datensätze auf 10
Minuten. 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#sthref2120
sind 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 Stark
lich 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