Automatisiertes Deployment von Datenbankobjekten im Data Warehouse: Ein Erfahrungsbericht Dr. Martin Jursch, WestLB AG Dr. Olaf Jessensky, OPITZ CONSULTING Gummersbach GmbH DOAG SIG Development Köln, 22. September 2011

Seite 2 Agenda Übersicht PCR NG Funktionsweise OC Schemaverwaltung Performanceoptimierung

Seite 3 Übersicht PCR NG Funktionsweise OC Schemaverwaltung Performanceoptimierung Agenda

Seite 4 FO-Systeme Übersicht PCR NG PCR NG WestLB Landschaft SUMMITPRIMEBASEBASEOSWERSTTUBIXSSLSAP FISAP BACDP PCR NG ALADIN BO-Systeme HGB DWH IFRS DWH General Ledger Eco. P&L RECONCILIATION

Seite 5 PCR NG Applikation PCR = Product Control Reporting (next generation) Abgleich von Daten aus den Handelssystemen, Abwicklungssystemen und Buchhaltungssystemen (National / International) Qualitätssicherung der Monthly P&L für Handelsprodukte Tägliche Aktualisierung der Buchhaltungsdaten Reporting für Analyse von Differenzen zwischen den vier Liefersystem-Typen Realtime Korrekturfunktionalität der Reports Erstellung von Buchungen für Korrekturbedarf in Buchungssystemen Datamart zur Analyse von Differenzen zwischen Daily- und Monthly-P&L Backend Oracle Datenbank Frontend für Reporting und Korrekturen MSAccess-Applikation Frontend für P&L Reporting Cognos

Seite 6 PCR NG Applikation Datenbank Objekte 900 Tabellen 1550 Indizes 340 Views 145 Packages 40 Prozeduren und Funktionen 640 Trigger 50 Java-Klassen 5 Materialized Views 90 Types 1 Advanced Queue 1,2 TB Gesamtgröße

Seite 7 PCR NG Infrastruktur STGODSRDSSTGODSRDSSTGODSRDSSVNSTGODSRDS Entwicklung (DEV) Es gibt die Datenbank-Instanzen Test und Produktion In einer Instanz gibt es mehrere Environments (DEV, BCK, …) Ein Environment besteht aus den Schemata RDS_NG_..., ODS_NG_... und STG_NG_... Die Applikation ist in verschiedene Module / Komponenten unterteilt Module / Komponenten bestehen aus Datenbank-Objekten Test (BCK) Produktion (QA) Simulation (BE) PRODUKTIONS Instanz TEST Instanz

Seite 8 PCR NG Deployment Anforderungen Alle Sourcen in SubVersion (zentrale Quelle) Einsatz von generischen nicht produkt-spezifischen Source-Formaten und Tools Deployment auf einen beliebigen Stand Deployment mit geringer Downtime Deployment flexibel neuen Datenbank- Objekten oder neuen Attributen anpassbar Flexible Festlegung von Datenbank Objekt Attributen wie Tablespace, Buffer Cache, Compression,… Tabellen mit sicherer Beibehaltung der Daten Grosse Tabellen mit einigen GB an Volumen Indizes und FKs auf großen Tabellen Tabellen, die dynamisch von der Applikation erweitert werden SQL-Typen für Tabellen und Packages Repositories Datenbank ObjekteAllgemein

Seite 9 PCR NG Deployment Cognos (Deployment über Cognos) Framework Manager ModelXML-Dateien Reports (Report Studio)XML-Dateien Reports (Query Studio)XML-Dateien VBA (Deployment über VBA-Deployment-Tool (Eigenentwicklung WestLB)) ModuleTXT-Dateien FormulareTXT-Dateien TabellenTXT-Dateien PropertiesTXT-Dateien Oracle (Deployment Framework OC Schemaverwaltung) TabellenSQL*Plus Scripte Typen SQL*Plus Scripte ViewsSQL-Dateien Packages, Prozeduren, FunktionenSQL-Dateien TriggerSQL-Dateien SequencesSQL*Plus Scripte GrantsSQL*Plus Scripte SynonymeSQL*Plus Scripte Java SourcenJava-Dateien RepositoriesSQL-Dateien

Seite 10 Funktionswei se OC Schemaverw altung Übersicht PCR NG Funktionsweise OC Schemaverwaltung Performanceoptimierung Agenda

Seite 11 Motivation Entwicklung Sourcecode/ Datenbankobjekte Test Produktion automatisiert manuell

Seite 12 Kategorien Kategorie 1 Datenbankobjekte die problemlos gelöscht und wieder neu angelegt werden können. z.B.: PL/SQL (Trigger, Functions, Procedures, Packages …), Views, …

Seite 13 Kategorien Kategorie 2 Datenbankobjekte die nicht einfach gelöscht werden dürfen. Löschen verbietet sich aus 2 Gründen: Datenerhalt z.B.: Tabellen, Types Performance z.B.: Indizes, Constraints

Seite 14 Kategorien Kategorie 2 Datenbankobjekte deren Eigenschaften von der Umgebung (Test, Produktion, …) abhängen: Grants (ods_ng_qa -> rds_ng_qa) Synonyme

Seite 15 Kategorien Kategorie 1 Skripte können normale „create or replace“-Skripte sein. Kategorie 2 Skripte benötigen eine Programmlogik, die diese z. B. mit den bestehenden Datenbankobjekten vergleicht und nur die tatsächlich nötigen Änderungen durchführt.

Seite 16 Architektur Kategorie 1 ODS_NG_QA (schemaowner) ant SQL*Plus pro Datenbankobjekt-Skript

Seite 17 Kategorie 1 Beispiel begin for cur_sql in ( select 'drop view ' || OBJECT_NAME text from user_objects where object_type = 'VIEW' and object_name like 'SPL%' ) loop execute immediate cur_sql.text; end loop; end; / Via SQL*Plus alle Views einer Komponente aus einem Schema entfernen.

Seite 18 Beispiel Kategorie 1 Hinweise: for-Konstrukt stammt von ant-contrib sqlplus ist ein ant-Makro Via ant alle View-Skripte ausführen.

Seite 19 Architektur Kategorie 2 ODS_NG_QA (schemaowner) DEPLOY_NG (deployment) ant SQL*Plus pro Tabellen-Datei-Skript Aufruf als User ODS_NG_QA der wiederum per Synonym auf das Package depl_module von DEPLOY_NG zugreift. Das Package läuft mit „authid current_user“. SQL*Plus pro Anweisung

Seite 20 Beispiel Kategorie spl_fact_trade_tab spfctr spl_fact_trade_tab guv_ifrs_kz varchar2(1) mandatory spl_fact_trade_tab cob date mandatory spl_fact_trade_tab cob cob bitmap LOCAL spl_fact_trade_tab spl_em_legalentity NOTHING spl_fact_trade_tab

Seite 21 Kategorie 2 create no_id (no_historization, spl_fact_trade_tab spfctr permanent Tabelle mit Spalte ID anlegen, wenn sie noch nicht existiert ID ist optional bei no_id, sonst not null No_historization, standard: PK-Constraint und Sequenz (spfctr_id_sq) werden erzeugt Standard: zusätzliche Felder cu, cmd, lu, lmd

Seite 22 Kategorie 2 spl_fact_trade_tab guv_ifrs_kz varchar2(1) mandatory "1" Spalte anlegen, wenn sie noch nicht existiert Datentyp prüfen  Verlängerung mit alter table  Sonstige Veränderungen  Neue Spalte anlegen  Daten kopieren (bei Fehler Abbruch)  Alte Spalte löschen  Neue Spalte umbenennen NOT NULL prüfen Default prüfen

Seite 23 Kategorie 2 create index / add foreign spl_fact_trade_tab cob cob bitmap LOCAL "" Index anlegen, wenn noch nicht vorhanden Index ersetzen, wenn Name, Bitmap/Eindeutigkeit oder Partition Range spl_fact_trade_tab spl_em_legalentity NOTHING "LEGALENTITY_ID " FK anlegen, wenn nicht vorhanden FK bezieht sich immer auf Spalte ID Delete Rule prüfen

Seite 24 Kategorie 2: Clear spl_fact_trade_tab Aufgabe: Alle sonstigen Tabellenbezogenen Datenbankobjekte löschen. Problem: Das Skript muss „wissen“ welche Datenbankobjekte existieren sollen und welche nicht. Lösung: Alle Skripte registrieren die Datenbankobjekte die sie erzeugen sollen in einer Tabelle. Nach Verarbeitung einer Komponente werden die Einträge wieder gelöscht.

Seite 25 Kategorie 2: Grants, select,update spl_fact_version_tab VBA,COG "with grant option" Problem: Die User, an die gegrantet wird, sind je nach Umgebung variabel. Lösung: Das Framework kennt die Umgebung: COG -> COG_NG_QA für Umgebung ODS SPL Erzeuge gleichnamige Synonyme für alle Objekte von ODS -> ODS_NG_QA, die gegranted wurden und die zur Komponente SPL gehören (deren Name mit SPL beginnt).

Seite 26 Reihenfolge pro Komponente und Schema Synonyme Pre-Skripte Pre-Skripte (Einmalausführung) Types Tabellen Java Package Header Functions, Procedures Views Type Bodies Package Bodies Trigger DML-Skripte Post-Skripte (Einmalausführung) Post-Skripte Grants [ synonyms] Kat. 2 [pre] [pre_once] [types,.tps]Kat. 2 [tables] Kat. 2 [java_sources] Kat. 1 [packages,.pks] Kat. 1 [functions], [procedures] Kat. 1 [views] Kat. 1 [types,.tpb] Kat. 1 [packages,.pkb] Kat. 1 [trigger] Kat. 1 [scripts_dml] Kat. 1 [post_once] [post] [grants] Kat. 2

Seite 27 SVN-Integration

Seite 28 Masterbuild-Konfiguration

Seite 29 Performanceo ptimierung Übersicht PCR NG Funktionsweise OC Schemaverwaltung Performanceoptimierung Agenda

Seite 30 Performanceproblematik Dauer eines kompletten Deployments ca. 1 Tag, Downtime bis zu 2 Tagen Anforderung: Daily P&L soll täglich erstellt werden können Performancekiller bei großen Tabellen  Erstellung und Validierung von Constraints  Erstellung und Rebuild von Indexen  Droppen von Spalten  Änderung des Spaltenformats Große Anzahl von Objekten  Jeweils neue Session  Vergleich mit Data Dictionary

Seite 31 Lösungsansätze Ein-Pass Verfahren für Tabellen Delta-Deployment Separate Ausführung von Langläufern per Job Parallelisierung von langlaufenden SQL‘s Paralleles Deployment mehrerer Komponenten

Seite 32 Ein-Pass vs. Zwei-Pass Verfahren Problem bei Foreign Key Constraints: Zieltabelle existiert noch gar nicht Lösung: Skripte werden 2 Mal ausgeführt  Einmal ohne FK Constraints  Zweiter Durchlauf mit FK Constraints Nachteile bei schon existenten großen Tabellen  Constraints werden beim 2. Durchlauf jedesmal neu erstellt/validiert  Performanceprobleme beim Deployment Lösung: Verhalten ist in Konfigurationsdatei umschaltbar

Seite 33 Delta-Deployment Problem: Menge der deployten Elemente erzeugt hohe Laufzeiten Lösung: Delta-Deployment mit Vorgabe eines Referenzdatums  Datum des Commits in SVN als Änderungsdatum der lokalen Datei  Es werden nur Dateien mit Änderungsdatum >= Referenzdatum deployt  Vorheriges Löschen der Kategorie 1 Objekte entfällt Ausnahmen bei aufeinander aufbauenden Objekten (z. B. Views) Optional: Komponente ohne Änderungen in SVN wird ignoriert

Seite 34 Auslagerung von langlaufenden SQL‘s Sonderbehandlung für erfahrungsgemäß imperformante Operationen  SQL‘s werden in einer Tabelle abgelegt (mit Build-Nr., Komponente, Tabellenname)  Zu bestimmten Zeitpunkten wird für bestimmte Arten von Statements ein Job gestartet  Bearbeitungsstatus und Fehler werden protokolliert  Mail-Benachrichtigung bei Abschluss Drop column: set unused + alter table drop unused columns Verhalten ist auf Tabellenebene DBJOB

Seite 35 Parallelisierung von SQL‘s Erstellen von Indizes  Create Index mit parallel 8  Alter index noparallel Setzen von Default-Werten  Alter session enable parallel dml  Update mit Parallel-Hint

Seite 36 Paralleles Deployment Parallelisierung des Deployments mit Parallel – Tag in Ant  Komponenten werden auf 2 Threads verteilt  Feste Reihenfolge innerhalb der Threads  Finaler Teil ohne Parallelisierung Ausführungszeit fast halbiert

Seite 37 Zusammenfassung Deployment einer definierten Version aller Datenbankobjekte aus Subversion Deployment beliebiger Versionsstände in beliebige Zielumgebungen Downtime für Monatsdelta in Produktion 2-3 Stunden Standard-Werkzeuge Ant und SQL*Plus Flexibel änderbar und konfigurierbar

Seite 38 Fragen & Antworten F A &

Seite 39 Kontaktdaten Dr. Martin Jursch WestLB AG Dr. Olaf Jessensky OPITZ CONSULTING Gummersbach GmbH Vielen Dank für Ihre Aufmerksamkeit!