Information Lifecycle Management in der Praxis Christoph Voglmaier / Willi Segatz

Transkript

1 Information Lifecycle Management in der Praxis Christoph Voglmaier / Willi Segatz

2 AGENDA Vorstellung von FJH ILM, was ist das? Historische Tabellen Batchverarbeitung und Grobselektion Umsetzung clustering factor Messergebnisse Archivkonzept ILM-basierte Datenmodellierung Resumee Fragen und Antworten Seite 2

3 FJH AG Wer sind wir: führender Anbieter von Software und Beratung für Versicherungen und andere Finanzdienstleister Kunden sind die Hälfte aller deutschen Lebensversicherer sowie namhafte Kranken- und Sachversicherer Wo sind wir: Weltweit ist unsere Software für 26 Länder auf fünf Kontinenten im Einsatz, darunter die USA und Australien ebenso wie viele osteuropäische Länder. Was machen wir: Standardsoftware für die vier Bereiche Bestandsverwaltung, Prozess- und Dokumentenmanagement, Point of Service und Unternehmenssteuerung sowie maßgeschneiderte Individuallösungen Kernprodukt im Segment Bestandsverwaltung ist die FJA Life Factory, mit der Versicherungsprodukte entwickelt, vertrieben und verwaltet werden können. Seite 3

4 Ausgangspunkt Problem Nächtlicher Fortschreibungsbatch Performance Datenmengen (Kunden mit über 1 Terabyte) Aufgabe: Datenmengen drastisch reduzieren Performance deutlich steigern Seite 4

5 Konzept: Information Lifecycle Management LESS ACTIVE Historical ACTIVE Seite 5

6 ILM Seite 6

7 Gründe für f r die Batchprobleme Statspack Analyse: Performance Bei großen Datenmengen ist System I/O-bound Durch Wachsen der Indizes und Tabellen steigt der I/O Grobselektion macht in innerer Schleife einen Fulltablescan auf eine große historische Tabelle Datenmengen Historische Tabellen benötigen einen großen Teil der Speicherplatzes Seite 7

8 Konzept der historischen Tabellen Tabellen mit Historien-Information, bei denen jede Änderung in einem neuen Datensatz gespeichert wird Bearbidabg = 9999 ist stets der aktuelle Satz Bearbidabg < 9999 verweist auf Bearbid des nächsten Satz Bearbid Bearbidabg ID Col1 Ablaufleistung Col3 Col4 Col , Update , INSERT , Seite 8

9 Quelle: Oracle Doku: : server.920/a96524/c03block.htm BEARBIDABG=9999 BEARBIDABG=9999 BEARBIDABG=0105 BEARBIDABG=9999 BEARBIDABG=0106 BEARBIDABG=9999 BEARBIDABG=0103 BEARBIDABG=9999 BEARBIDABG=0104 BEARBIDABG=9999 BEARBIDABG=0101 BEARBIDABG=9999 BEARBIDABG=0102 Seite 9

10 Füllung der Blöcke Seite 10

11 Select der Grobselektion select L.LVID from LVSTAND L,LV,JURLV where (((L.BEARBIDABG=9999 and LV.LVBEGT<=TO_DATE(:b0))and (((FORTBIS<=TO_DATE(:b0) or FORTBIS is null) or (INKASSOBIS<TO_DATE(:b0) or INKASSOBIS is null )) or L.BEARBIDREAKT<>0)) and (((((((((:b3=0 and ((coalesce (LENGTH(:b4),0)=0 or (Coalesce (LENGTH(:b5),0)<>0 and L.LVID between :b4 and :b5)) or L.LVID=:b4)) or (:b3<>0 and TO_NUMBER(L.LVID) between TO_NUMBER(:b4) and TO_NUMBER(:b5))) and ((LV.BEARBIDABG=9999 and L.LVID=LV.LVID) and LV.MANDANTID=:b12)) and (coalesce (LENGTH(:b13),0)=0 or TO_NUMBER(L.LVID) in (select INTERNID from MAPPINGINTEXT where EXTERNID like :b13))) and (coalesce (length(:b15),0)=0 or LV.PDID in (:b15,:b17,:b18,:b19,:b20,:b21,:b22,:b23,:b24,:b25,:b26,:b27,:b28,:b29,:b30,:b31,:b 32,:b33,:b34,:b35,:b36,:b37,:b38,:b39,:b40,:b41,:b42,:b43,:b44,:b45,:b46,:b47))) and (JURLV.LVID=L.LVID and JURLV.KZBEARBSTOP<>1)) and (:b48=0 or LV.LVSTATUS=:b48)) and LV.LVID=L.LVID) and LV.BEARBIDABG=9999)) Seite 11

12 Executionplan: : Grobselektion vor Partitioning Operation PHV/Object Name Rows Bytes IO-Cst Pstart Pstop Pid SELECT STATEMENT FILTER NESTED LOOPS NESTED LOOPS TABLE ACCESS FULL LV 3K 131K 462 INDEX RANGE SCAN LVSTANDIDX TABLE ACCESS BY INDEX ROWID JURLV INDEX UNIQUE SCAN SYS_C TABLE ACCESS BY INDEX ROWID MAPPINGINTEXT INDEX RANGE SCAN MAPPINGINTEXTIDX Seite 12

13 Statement Grobselektion select L.LVID from LVSTAND L,LV,JURLV where (((L.BEARBIDABG=9999 and LV.LVBEGT<=TO_DATE(:b0) )and (((FORTBIS<=TO_DATE(:b0) or FORTBIS is null) or (INKASSOBIS<TO_DATE(:b0) or INKASSOBIS is null )) or L.BEARBIDREAKT<>0)) and (((((((((:b3=0 and ((coalesce (LENGTH(:b4),0)=0 or ( Coalesce (LENGTH(:b5),0)<>0 and L.LVID between :b4 and :b5)) or L.LVID=:b4)) or (:b3<>0 and TO_NUMBER(L.LVID) between TO_NUMBER(:b4) and TO_NUMBER(:b5))) and ((LV.BEARBIDABG=9999 and L.LVID=LV.LVID) and LV.MANDANTID=:b12)) and (coalesce (LENGTH(:b13),0)=0 or TO_NUMBER(L.LVID) in (select INTERNID from MAPPINGINTEXT where EXTERNID like :b13))) and (coalesce (length(:b15),0)=0 or LV.PDID in (:b15,:b17,:b18,:b19,:b20,:b21,:b22,:b23,:b24,:b25,:b26,:b27,:b28,:b29, :b30,:b31,:b32,:b33,:b34,:b35,:b36,:b37,:b38,:b39,:b40,:b41,:b42,:b43,:b44,:b45,:b46,:b47))) and (JURLV.LVID=L.LVID and JURLV.KZBEARBSTOP<>1)) and (:b48=0 or LV.LVSTATUS=:b48)) and LV.LVID=L.LVID) and LV.BEARBIDABG=9999)) % Snap Statement Total Per Execute Total Buffer Gets: 2,531,432 2,531, Disk Reads: 178, , >*8k= MB ~ 13,6 GB Rows processed: 354, ,294.0 CPU Time(s/ms): 9 9,453.1 Elapsed Time(s/ms): 1,578,211 1,578,210,702.0 Sorts: 0.0 Parse Calls: Invalidations: 0 Version count: 1 Sharable Mem(K): 50 Executions: 1 Seite 13

14 Kompression Oracle Blockweise für f r Tabellen Seite 14

15 Erster Versuch: Partitionierung nach BEARBIDABG=9999 Partitioniert nach BEARBIDABG: Bis zu 30% langsamer Grund: Row Movement: Update auf BEARBIDABG=9999->102 Vergleich partitioniert unpartitioniert ,00 Unpartitioniert ,00 Partitioniert 8.000, , , ,00 Verträge pro M inute 0,00 Dez 07 Jan 08 Feb 08 Mrz 08 Apr 08 Datum Mai 08 Jun 08 Jul 08 Aug 08 Sep 08 Okt 08 Nov 08 Dez 08 Bearbid Bearbidabg LVID Col1 Col2 (Ablaufleistung) Col3 (Ablaufdatum) Col4 Col , Update , , Seite 15

16 Umsetzung: Insert Update Tausch Bearbid Bearbidabg LVID Col1 Col2 Col3 Col4 SQL Statement , Update , Insert Bearbid Bearbidabg LVID Col1 Col2 Col3 Col4 SQL Statement , , Update , Insert Vorteil: Kein Update auf Partition Key -> kein Row Movement, schneller Blöcke bleiben besser mit Daten von BEARBIDABG=9999 gefüllt -> weniger I/O Nachteil: Der Primary Key muss geändert werden, da erst der insert und dann der update erfolgen kann (bearbid ist nach insert gleich, wird durch update geändert). Seite 16

17 Partitionierung: Zusätzliche Spalte Problem: Partitionierung nur nach BEABIDABG=9999, keine zeitliche Abhängigkeit Lösung: Zusätzliche Spalte mit Jahr-Anteil des Systemdatums -> default to_char(sysdate, YYYY ) BEABIDABG=9999 -> d_sysdate=9999, dadurch 1 dimensionale Partitonierung möglich Kompression bei Version kleiner 11 möglich (geht nicht bei Subpartitions) Bearbid Bearbidabg LVID Col1 Col2 Col3 Col4 d_sysdate , , Probleme: Kein Partition Pruning möglich. (where bearbidabg=9999 und nicht d_sysdate=9999) Für neue eingefügte Datensätze muss Programmlogik geändert werden, da d_sysdate über defaultvalue gefüllt wird -> bei neuen Datensätzen d_sysdate=2007 und nicht 9999 Seite 17

18 Quelle: Oracle Doku: : server.920/a96524/c03block.htm BEARBIDABG=0106 BEARBIDABG=0104 BEARBIDABG=0105 BEARBIDABG=0102 BEARBIDABG=0103 BEARBIDABG=9999 BEARBIDABG=0101 BEARBIDABG=9999 BEARBIDABG=9999 BEARBIDABG=9999 BEARBIDABG=9999 BEARBIDABG=9999 BEARBIDABG=9999 Seite 18

19 Messergebnisse: Executionplan Grobselektion nach Partitioning Operation PHV/Object Name Rows Bytes IO-Cst Pstart Pstop Pid SELECT STATEMENT FILTER TABLE ACCESS BY GLOBAL INDEX ROWID LV ROW ROW L 2 NESTED LOOPS NESTED LOOPS INDEX FAST FULL SCAN LVSTANDIDX TABLE ACCESS BY INDEX ROWID JURLV INDEX UNIQUE SCAN SYS_C INDEX RANGE SCAN LVIDX TABLE ACCESS BY INDEX ROWID MAPPINGINTEXT INDEX RANGE SCAN MAPPINGINTEXTIDX Statement Total Per Execute Total Buffer Gets: 2,673,529 2,673, Disk Reads: 22,324 22, <-174 MB (vorher 13,7 GB)~97% besser Rows processed: 354, ,294.0 CPU Time(s/ms): 5 5,468.8 Elapsed Time(s/ms): 24,050 24,049,742.8 Sorts: 0.0 Parse Calls: Invalidations: 0 Version count: 1 Sharable Mem(K): 44 Executions: 1 Seite 19

20 Partition Pruning auch bei Indizes Where Bedingung im select ist BEARBIDABG=9999 Tabelle partitioniert nach sysdate Executionplan: Operation PHV/Object Name Rows Bytes IO-Cst Pstart Pstop Pid INDEX FAST FULL SCAN LVSTANDIDX INDEX RANGE SCAN LVIDX Grund: Index nach BEARBIDABG partitioniert CREATE INDEX LVSTANDIDX1 ON LVSTAND (BEARBIDABG, LVID,.) GLOBAL PARTITION BY RANGE (BEARBIDABG) ( PARTITION P_MIN VALUES LESS THAN (9999), PARTITION P_9999 VALUES LESS THAN (10000), PARTITION P_MAX VALUES LESS THAN (MAXVALUE) ) Jedoch auch Index Range Scan bei nicht partitionierten Index. Warum????? Seite 20

21 Quelle: Christian Antognini Senior Consultant Trivadis München 12 September 2006 Seite 21

22 Quelle: Christian Antognini Senior Consultant Trivadis München 12 September 2006 Seite 22

23 Messergebnisse Messergebnisse Seite 23

24 Unsere EMC² 8*2,5 Platten 146 GB, 8 GB Memory, 4 DUAL Core AMD Opteron 8000 Series, HP Proliant DL585 G2 ~ ,00 Seite 24

25 Batchperformance Oracle Produkttyp1 Seite 25

26 Batchperformance Oracle Produkttyp2 Performance über langen Zeitraum (5 Jahre Fortschreibung bei Verträge) relativ bezogen auf die verwendete Hardware - hoch (7000 Verträge/Minute) Größte Performancekiller sind unpartitionierte Tabellen Seite 26

27 Über 60% I/O von den unpartitionierten Tabellen - 41% KTOBWG und BEARBNW CPU Elapsd Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value , , Module: AbfBatchEngine_Windows_NT.exe select BEARBNW.LVID,BEARBNW.BEARBID,BEARBNW.SCHRITTID,BEARBNW 111, , Module: AbfBatchEngine_Windows_NT.exe select KTOBWG.BEARBID,KTOBWG.LVID,KTOBWG.KTOBEWID,KTOBWG.VTID 53,541 21, Module: AbfBatchEngine_Windows_NT.exe insert into sbbz (lvid,bearbid,wirkbeginn,vtid,feinbeginn,sbid,s 50, , Module: AbfBatchEngine_Windows_NT.exe insert into ktobwg (bearbid,lvid,ktobewid,vtid,vbid,ktobewtypid, 43,733 21, Module: AbfBatchEngine_Windows_NT.exe insert into sntnw (lvid,bearbid,sntid,sntnwid,bearbdat,wirkdat,b 37,102 21, Module: AbfBatchEngine_Windows_NT.exe insert into sbuebzu (lvid,bearbid,wirkbeginn,feinbeginn,vtid,sbi 36,996 21, Module: AbfBatchEngine_Windows_NT.exe insert into sbuebverw (lvid,bearbid,wirkbeginn,feinbeginn,vtid,s Seite 27

28 Vergleich komprimiert unkomprimiert VOR Insert/Update Tausch Seite 28

29 Vergleich komprimiert unkomprimiert NACH Insert/Update Tausch Seite 29

30 Bearbnw ohne Partitioning Snap Statement Total Per Execute Total Buffer Gets: 124, Disk Reads: 22, Rows processed: 15, CPU Time(s/ms): 2.1 Elapsed Time(s/ms): 5,143, ,163.3 Sorts: 0.0 Parse Calls: 0.0 Invalidations: 0 Version count: 1 Sharable Mem(K): 22 Executions: 15,578 select BEARBNW.LVID,BEARBNW.BEARBID,BEARBNW.SCHRITTID,BEARBNW.BEARBEITERID,BEARBNW.BEARBDAT,BEARBNW.WIRKBEGINN,BEARBNW.FEINBEGINN,BEARBNW.WIRKENDE,BEARBNW.FEINENDE,BEARBNW.BEARBIDSTO,BEARBNW.BEARBDATSTO,BEARBNW.JOBID,BEARBNW.BUCHPER,BEARBNW.REFBUCHPER,BEARBNW.BEARBGRDID,BEARBNW.MELDEDAT,BEARBNW.WTERM,BEARBNW.BEARBZEIT from bearbnw where LVID=:b0 order by BEARBID desc Operation PHV/Object Name Rows Bytes IO-Cst CPU Pstart Pstop Pid SELECT STATEMENT TABLE ACCESS BY INDEX ROWID BEARBNW INDEX RANGE SCAN BEARBNWIDX1 1 3 SORT AGGREGATE 1 10 FIRST ROW INDEX RANGE SCAN (MIN/MAX) BEARBNWIDX1 250K Seite 30

31 Bearbnw mit Partitioning PARTITION BY HASH (LVID) partitions 8 Snap Statement Total Per Execute Total Buffer Gets: 279, Disk Reads: 109, Rows processed: 752, CPU Time(s/ms): 11.7 Elapsed Time(s/ms): 5,602, ,706.1 Sorts: 17, Parse Calls: 9.0 Invalidations: 0 Version count: 1 Sharable Mem(K): 20 Executions: 17,307 select BEARBNW.LVID,BEARBNW.BEARBID,BEARBNW.SCHRITTID,BEARBNW.BEARBEITERID,BEARBNW.BEARBDAT,BEARBNW.WIRKBEGINN,BEARBNW.FEINBEGINN,BEARBNW.WIRKENDE,BEARBNW.FEINENDE,BEARBNW.BEARBIDSTO,BEARBNW.BEARBDATSTO,BEARBNW.JOBID,BEARBNW.BUCHPER,BEARBNW.REFBUCHPER,BEARBNW.BEARBGRDID,BEARBNW.MELDEDAT,BEARBNW.WTERM,BEARBNW.BEARBZEIT from bearbnw where LVID=:b0 order by BEARBID desc Operation PHV/Object Name Rows Bytes IO-Cst CPU Pstart Pstop Pid SELECT STATEMENT SORT ORDER BY 21 2K 10 PARTITION HASH SINGLE KEY KEY 2 TABLE ACCESS BY LOCAL INDEX ROWID BEARBNW 21 2K 7 KEY KEY 2 INDEX RANGE SCAN BEARBNWIDX KEY KEY Seite 31

32 SKUEBZU eindimensionales Partitioning und lokaler Index % Snap Statement Total Per Execute Total Buffer Gets: 2,167, Disk Reads: 48, Rows processed: 1,594, CPU Time(s/ms): 39.1 Elapsed Time(s/ms): 59,745, ,636.4 Sorts: 0.0 Parse Calls: 9.0 Invalidations: 0 Version count: 1 Sharable Mem(K): 23 Executions: 354,286 select SKUEBZU.LVID,SKUEBZU.VTID,SKUEBZU.ZUTSYS,SKUEBZU.UEBVERWSYS,SKUEBZU.BEARBDATSTO,SKUEBZU.ANZIR,SKUEBZU.ANZIDIR,SKUEBZU.ANZIRFB,SKUEBZU.RISDIR,SKUEBZU.RISRFB,SKUEBZU.GRDIR,SKUEBZU.GRRFB,SKUEBZU.ZIDIR,SKUEBZU.ZIRFB,SKUEBZU.BEARBID,SKUEBZU.BEARBIDABG,SKUEBZU.WIRKDAT,SKUEBZU.FEINDAT,SKUEBZU.BEARBDAT,SKUEBZU.BUCHPER,SKUEBZU.PDID,SKUEBZU.TFID,SKUEBZU.SEX,SKUEBZU.KZEINMALBTRG,SKUEBZU.KZKOLL,SKUEBZU.WAEHRUNGID,SKUEBZU.MANDANTID,SKUEBZU.KONSORTID,SKUEBZU.ZUSTAND,SKUEBZU.VARIANTEID,SKUEBZU.ANZIRFBBED,SKUEBZU.ANZIDIRBED,SKUEBZU.REFIZIDIR,SKUEBZU.REFIZIRFB from skuebzu where (LVID=:b0 and BEARBIDABG=9999) Operation PHV/Object Name Rows Bytes IO-Cst CPU Pstart Pstop Pid SELECT STATEMENT TABLE ACCESS BY GLOBAL INDEX ROWID SKUEBZU INDEX RANGE SCAN SKUEBZUIDX Seite 32

33 SKUEBZU zweidimensionales Partitioning und globaler unpartitionierter Index % Snap Statement Total Per Execute Total Buffer Gets: 2,167, Disk Reads: 231, Rows processed: 1,594, CPU Time(s/ms): 39.1 Elapsed Time(s/ms): 76,649, ,348.1 Sorts: 0.0 Parse Calls: 9.0 Invalidations: 0 Version count: 1 Sharable Mem(K): 23 Executions: 354,288 select SKUEBZU.LVID,SKUEBZU.VTID,SKUEBZU.ZUTSYS,SKUEBZU.UEBVERWSYS,SKUEBZU.BEARBDATSTO,SKUEBZU.ANZIR,SKUEBZU.ANZIDIR,SKUEBZU.ANZIRFB,SKUEBZU.RISDIR,SKUEBZU.RISRFB,SKUEBZU.GRDIR,SKUEBZU.GRRFB,SKUEBZU.ZIDIR,SKUEBZU.ZIRFB,SKUEBZU.BEARBID,SKUEBZU.BEARBIDABG,SKUEBZU.WIRKDAT,SKUEBZU.FEINDAT,SKUEBZU.BEARBDAT,SKUEBZU.BUCHPER,SKUEBZU.PDID,SKUEBZU.TFID,SKUEBZU.SEX,SKUEBZU.KZEINMALBTRG,SKUEBZU.KZKOLL,SKUEBZU.WAEHRUNGID,SKUEBZU.MANDANTID,SKUEBZU.KONSORTID,SKUEBZU.ZUSTAND,SKUEBZU.VARIANTEID,SKUEBZU.ANZIRFBBED,SKUEBZU.ANZIDIRBED,SKUEBZU.REFIZIDIR,SKUEBZU.REFIZIRFB from skuebzu where (LVID=:b0 and BEARBIDABG=9999) Operation PHV/Object Name Rows Bytes IO-Cst CPU Pstart Pstop Pid INSERT STATEMENT TABLE ACCESS BY GLOBAL INDEX ROWID SKUEBZU ROW ROW L 1 INDEX RANGE SCAN SKUEBZUIDX Seite 33

34 SKUEBZU eindimensionales Partitioning und globaler partitionierter Index % Snap Statement Total Per Execute Total Buffer Gets: 9,845, Disk Reads: 13, Rows processed: 1,086, CPU Time(s/ms): 79.3 Elapsed Time(s/ms): 6,713,602 28,440.4 Sorts: 0.0 Parse Calls: 9.0 Invalidations: 5 Version count: 1 Sharable Mem(K): 47 Executions: 236,059 select SKUEBZU.LVID,SKUEBZU.VTID,SKUEBZU.ZUTSYS,SKUEBZU.UEBVERWSYS,SKUEBZU.BEARBDATSTO,SKUEBZU.ANZIR,SKUEBZU.ANZIDIR,SKUEBZU.ANZIRFB,SKUEBZU.RISDIR,SKUEBZU.RISRFB,SKUEBZU.GRDIR,SKUEBZU.GRRFB,SKUEBZU.ZIDIR,SKUEBZU.ZIRFB,SKUEBZU.BEARBID,SKUEBZU.BEARBIDABG,SKUEBZU.WIRKDAT,SKUEBZU.FEINDAT,SKUEBZU.BEARBDAT,SKUEBZU.BUCHPER,SKUEBZU.PDID,SKUEBZU.TFID,SKUEBZU.SEX,SKUEBZU.KZEINMALBTRG,SKUEBZU.KZKOLL,SKUEBZU.WAEHRUNGID,SKUEBZU.MANDANTID,SKUEBZU.KONSORTID,SKUEBZU.ZUSTAND,SKUEBZU.VARIANTEID,SKUEBZU.ANZIRFBBED,SKUEBZU.ANZIDIRBED,SKUEBZU.REFIZIDIR,SKUEBZU.REFIZIRFB from skuebzu where (LVID=:b0 and BEARBIDABG=9999) Operation PHV/Object Name Rows Bytes IO-Cst CPU Pstart Pstop Pid INSERT STATEMENT PARTITION RANGE SINGLE KEY KEY 1 TABLE ACCESS BY GLOBAL INDEX ROWID SKUEBZU ROW ROW L 2 INDEX RANGE SCAN SKUEBZUIDX1 1 3 KEY KEY Seite 34

35 Seite 35 Kompression Kompression 84,99 3, , , , Tab9 52,85 6, , , , Tab8 89,22 5, , , , Tab7 87,36 10, , , , Tab6 86,10 7, , , , Tab5 86,09 10, , , , Tab4 89,78 16, , , , Tab3 93,17 7, , , , Tab2 92,94 9, , , , Tab1 84,45 8 6, , , Tab9 88,30 8 8, , , Tab8 88,67 8 8, , , Tab7 85,97 8 7, , , Tab6 85,09 8 6, , , Tab5 84,61 8 6, , , Tab4 88,06 8 8, , , Tab3 92, , , , Tab2 92, , , , Tab1 % besser % besse re Kompr essio n als 8K Bloc ksiz e (k) Kompr essio nsfak tor Anzahl Zeilen Rowle ngth kompr. Tabelle ngröße komprim iert (MB) Anzahl Blöcke kompri miert Rowlen gth unkomp rimier t Tabellen größe unkompri miert (MB) Anzahl Blöcke unkomp rimier t Tabelle

36 Gründe für f überh berhöhte Kompressionsraten PCT-Free = 0 für komprimierte Blöcke in Version 9 Testdaten!!!! Entstehen durch Multiplizierung gleicher Verträge Wenige Verträge (hier 12) wurden auf aufgepumpt -> hohe Redundanz -> überhöhte Kompression Daher -> Nehmen Sie Testdaten unter die Lupe!!!! Jedoch: Bei historischen Tabellen erwarten wir hohe Kompressionsraten da sich zwei Zeilen nur in wenigen (meist drei) Spalten unterscheiden, erste Messungen bestätigen das Seite 36

37 Archivkonzept Zugriff mittels Union All Views Zugriff mittels Union all Views 1. Beim Archiv muss nur einmal der Tabellentablespace gesichert werden (Zusätzlich Kompression möglich) 2. Archiv kann für mehrere Applikationen benutzt werden (nur 1 Lizenz) 3. Updateskripte können gegen Archiv und Produktion laufen da gleiche Tabellennamen (TS vorher auf RW) 1. Exchange Partition 2. TTS Transport Daten für ein Jahr in einem Tablespace mit Datum der Erstellung (TS_2004) Seite 37

38 Grundsätzliche Problematik Performance oft Funktion von DB-Größe (Nutzdaten) und Alter Datenbankadministrator weiß oft nicht, welche Daten wann gelöscht oder auf Read-Only gesetzt werden können Wissen über Löschzeitpunkte von Daten haben Rechtsabteilung (gesetzliche Aufbewahrungsfristen) oder Fachabteilungen (Anforderungen) -> bereits vor der Applikationserstellung sollte feststehen, was später wann gelöscht werden darf Problem: Datenmodellierung unabhängig von der Zeit Seite 38

39 Mögliche Abhilfe: ILM-basierte Datenmodellierung Zeitachse Entität: Telefongespräch Löschzeitpunkt (Fachbereich, gesetzliche Vorschriften) Geburtstag Archivierungsdatum -> Rente (keine Änderungen der Daten mehr) Löschzeitpunkt bzw. Archivierungsdatum kann aus dem Geburtstag abgeleitet werden >Daten unterliegen einem Alterungsprozeß Wird beim Erstellen des Datensatzes geschrieben Kann als Partitionkey dienen Seite 39

40 Mögliche Abhilfe: ILM-basierte Datenmodellierung Löschen der Daten ist erst nach Verdichtung und erreichen des Verfallsdatums möglich Entität: Quartalsumsatz = verdichtete Tabelle Jahr Quartal Umsatz Birthday Number Number Decimal Date Entität2: Col1 Col2 Col3 Birthday Verdichtet Entität1: Datatyp1 Datatyp2 Datatyp3 Date Boolean Col1 Col2 Col3 Col4 Birthday Verdichtet Datatyp1 Datatyp2 Datatyp3 Datatyp4 Date Boolean Seite 40

41 Resumee: : ILM ILM ist mehr als nur Partitioning und Kompression -> es gibt keinen init.ora Parameter information_lifecycle_management=on Möglicherweise müssen Ihre Applikation angepasst werden Unter Umständen müssen zusätzlich die Prozesse geändert werden -> ILM-integrated-ER Modellierung Vorteile Erhebliche Performancesteigerungen bei vorhandenen Applikationen möglich (bei 2 Jahre alten Beständen haben wir weit über 200% gemessen und noch Potential) Laufzeiten, die nicht mehr vom Alter der Daten abhängig sind Kleinere handlichere Produktivsysteme durch Auslagern von Altdaten Kostenersparnis durch Verwendung günstigerer Hardware (Platten und Rechner) Oracle bietet mit Kompression, Partitioning und dem ILM-Assistant die technischen Möglichkeiten um ILM implementieren zu können Seite 41

42 Seite 42