Automatisierte Datenmigration mit dynamischen SQL

Transkript

1 Automatisierte Datenmigration mit dynamischen SQL Rolf Wesp Consultant Düsseldorf, 27. Oktober 2009 Baden Basel Bern Brugg Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien

2 Agenda Projektumgebung Migrationsverfahren MigrDataDictionary Daten sind immer im Spiel. Migrationsprozess Nutzen / Mehrwert 2

3 Projektumgebung (1/4) Projekt: Migration der Dimensionsbezüge aller Fakten in einem 2-stufigen DataWarehouse Kunde: internationaler Hersteller von Telko- Netzelementen und Management-Systemen Datenbank: Oracle Enterprise Edition Sprache: PL/SQL 3

4 Projektumgebung (2/4) Anlass Reorganisation der Zuordnung von Netzelementen zu regionalen DataWarehouse-Servern Reduzierung der Anzahl Server in den Regionen internes, nicht anzutastendes Verfahren generiert neue IDs für alle Netzelemente, schreibt eine Mappingtabelle zwischen alten und neuen IDs alte IDs in den Fakten sind durch neue zu ersetzen 4

5 Projektumgebung (3/4) Regionales DataWarehouse Element Management System Netzelement GID 1 GID 2 GID 3 GID 4 GID 5 GID 6 GID 7 Regionales DataWarehouse NEW_ID OLD_ID Element Management System Netzelement GID 1 GID 2 GID 11 GID 12 GID 13 GID 14 GID 7 5

6 Projektumgebung (4/4) Problem / Herausforderung Datensätze in ca Faktentabellen im laufenden Betrieb migrieren Analyse der Tabellen und des Mengengerüsts Tabellen sind nicht partitioniert, die meisten davon halten < Sätze / Tabelle partitionierte Tabellen, Partitionen, davon nicht belegt 11 Mrd. Datensätze in partitionierten Tabellen 6

7 Migrationsverfahren (1/8) Migration in drei Varianten Update der Fakten für nicht partitionierte Tabellen mit Anzahl Zeilen < einstellbarem Schwellwert Truncate und Insert für große, nicht partitionierte Tabellen Aufbau einer Hilfstabelle mit der Struktur der Faktentabelle Einlesen der Fakten, dabei Austausch der alten Dimensionswerte durch die neuen Truncate der Faktentabelle, Insert aus der Hilfstabelle Exchange Partition für partitionierte Tabellen, je Partition: Aufbau der Hilfstabelle und Einlesen der Fakten wie bei Truncate und Insert Austausch der Partition gegen die Hilfstabelle 7

8 Migrationsverfahren (2/8) Variante Update ID_MAP (index organized table) NEW_ID ID_1 OLD_ID Faktentabelle (klein, nicht partitioniert) Update <Faktentabelle> f set (f.<id_col1> [, f.<id_col2>, ]) = (select m1.new_id [,m2.new_id, ] from ID_MAP m1 [,ID_MAP m2, ] ) where where f.<id_col1> = m1.old_id [ and f.<id_col2> = m2.old_id and ] exists (select 1 from ID_MAP where old_id = f.<id_col1>) [ and exists (select 1 from ID_MAP where old_id = f.<id_col2>) and ] Meas_1 ID_2 Meas_2 Meas_

9 Migrationsverfahren (3/8) Variante Truncate und Insert (1/2) ID_MAP (index organized table) Create table <Hilfstabelle> as NEW_ID OLD_ID select m1.new_id, f.<meas_col1> [, f.<meas_col2>, ] from <Faktentabelle> f, ID_MAP m where f.<id_col1> = m1.old_id UNION ALL - - nicht gefunden select f.<id_col1>, f.<meas_col1> [, f.<meas_col2>, ] from < Faktentabelle> f Faktentabelle (groß, nicht partitioniert) where not exists (select 1 from ID_MAP ID_1 Meas_1 Meas_2 Meas_3 where old_id = f.<id_col1> Hilfstabelle (mit der Struktur der Faktentabelle) ID_1 Meas_1 Meas_2 Meas_

10 Migrationsverfahren (4/8) Variante Truncate und Insert (2/2) Faktentabelle (groß, nicht partitioniert) ID_1 Meas_1 Meas_2 Meas_ Hilfstabelle (mit der Struktur der Faktentabelle) ID_1 Meas_1 Meas_2 Meas_ Truncate table <Faktentabelle> Insert into <Faktentabelle> select * from <Hilfstabelle> Drop table <Hilfstabelle> 10

11 Migrationsverfahren (5/8) Variante Exchange Partition (1/2) Part. 1 Create table <Hilfstabelle> as ID_MAP (index organized table) select m1.new_id, f.<meas_col1> [, f.<meas_col2>, ] NEW_ID OLD_ID from <Faktentabelle> partition <Partitionsname> f, ID_MAP m where f.<id_col1> = m1.old_id UNION ALL - - nicht gefunden select f.<id_col1>, f.<meas_col1> [, f.<meas_col2>, ] from < Faktentabelle> partition <Partitionsname> f Faktentabelle (partitioniert) where not exists (select 1 from ID_MAP ID_1 Meas_1 Meas_2 Meas_3 where old_id = f.<id_col1> Alter 34table <Hilfstabelle> add constraint <constraint clause> Part create 22 index <index clause> on <Hilfstabelle> Hilfstabelle (mit der Struktur, allen Constraints und Indizes der Faktentabelle) ID_1 Meas_1 Meas_2 Meas_

12 Migrationsverfahren (6/8) Variante Exchange Partition (2/2) Part. 1 Faktentabelle (partitioniert) ID_1 Meas_1 Meas_2 Meas_ Part alter table <Faktentabelle> exchange partition <Partitionsname> with table <Hilfstabelle> Drop table <Hilfstabelle> Hilfstabelle (mit der Struktur, allen Constraints und Indizes der Faktentabelle) ID_1 Meas_1 Meas_2 Meas_

13 Migrationsverfahren (7/8) Optionen und Besonderheiten disable (drop index) / enable validate (using index) PK- und FK-Constraints Drop / create index (für nicht-pk-indizes) Partitioned indexes (local, global) Nologging Insert /*+ Append */ Parallel (Degree n) Exchange partition erfordert absolut identische Strukturen von Faktentabelle und Hilfstabelle (Datentyp, Länge, Nullable, PK, FK, Indizes) 13

14 Migrationsverfahren (8/8) Grundsätzliches zum Verfahren DDL- und DML-Kommandos zur Laufzeit generiert, mit dynamischen SQL (execute immediate) ausgeführt Zur Generierung erforderliche Informationen stehen in speziellem MigrDataDictonary, zeitlich unabhängig von der Migration aufgebaut Separater Tablespace für erzeugte DB-Objekte Dediziertes Schema für die Ausführung, Rechte auf SYS-Objekte und zu migrierende Tabellen Parameter für Bestimmung der Zielobjekte Ausführungsoptionen Ablaufsteuerung 14

15 MigrDataDictionary Auswerten der Steuertabelle mit Zuordnungen: DataMart Schema. Tablename[%] Columnname Für 1 oder mehrere DataMarts: Lesen des Oracle DataDictionary Kennzeichnen der zu migrierenden Spalten durch Abgleich mit den Vorgaben aus der Steuertabelle Begin migrate_gid.set_param ('MODULENAME', 'QM'); migrate_gid.set_param ('MODULENAME', 'HR'); migrate_gid.load_dict; End; / 15

16 Migrationsprozess (1/3) Für jede zu migrierende Tabellen (-Partitionen): Akualisierung der Anzahl Sätze (last_analyzed älter als Parameter) nicht partitioniert Variante Update oder Truncate und Insert partitioniert Variante Exchange Partition Auswertung der Steuerungs-Parameter Vergleich der Anzahlen Sätze vor und nach der Migration Migrationsprotokoll Synchrone Protokollierung der generierten Statements, ggf. der Fehlermeldungen Kennzeichnung der migrierten Tabellen (-Partitionen) im Erfolgs- und Fehlerfall 16

17 Migrationsprozess (2/3) Zeitfenster einstellbar Verzögerter Beginn Definiertes Ende Unterbrechung Automatisch im Fehlerfall Durch Verlassen des Zeitfensters Abbruch durch Verkleinern des Zeitfensters Jederzeitiges Wiederaufsetzen möglich Simulation möglich (nur Protokollierung, keine Ausführung) Rücksetzbar 17

18 Migrationsprozess (3/3) 6 obligatorische, 4 optionale (mit Defaults) Parameter steuern den Migrationsprozess Migration unterschiedlicher DataMarts mit unterschiedlichen Parametern in unabhängigen Sessions möglich Begin migrate_gid.set_param ('BEGINNDATE', sysdate); migrate_gid.set_param ('ENDDATE', sysdate + 0.5); migrate_gid.set_param ('LASTANALYZED', sysdate - 3); migrate_gid.set_param ('MODUS', 'FORWARD'); migrate_gid.set_param ('DISABLE_PK', TRUE); migrate_gid.set_param ('REBUILD_INDEX', TRUE); migrate_gid.process_migration ('HR'); End; / 18

19 Nutzen / Mehrwert Strukturierte Planung und Steuerung, sichere Durchführung, vollständige Überwachung von Datenmigrationen Deutliche Performancesteigerung durch Anwendung der adäquaten Migrationsvariante partitioniert Rows Zu migr. Spalten Update [Sek.] Truncate Insert [Sek.] Exchange Partition [Sek.] nein nein nein 2 Mio ja 2 Mio ja 2 Mio ausgeführt auf Windows Notebook, 600 MB SGA 19

20 Vielen Dank!? Baden Basel Bern Brugg Lausanne Zürich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg München Stuttgart Wien