Oracle Datenbank 12c In-Memory Cache Option Architektur, Einführung, Highlights und POC Erfahrungen. DOAG Webinar 10. März 2017

Transkript

1 Oracle Datenbank 12c In-Memory Cache Option Architektur, Einführung, Highlights und POC Erfahrungen DOAG Webinar 10. März 2017

2 Ing Christian Pfundtner OCA, OCP, OCE, OCM, ACE Oracle Datenbank Spezialist seit 1993 Über 23 Jahre Erfahrung im Oracle Datenbank High End Consulting und Troubleshooting 20 Jahre Erfahrung als Oracle Datenbank Trainer im High End Bereich

3 Wer ist DB Masters? Gegründet Dez 2010, 2016 über 1.6 Mio Euro Umsatz 8 Mitarbeiter, davon 6 Techniker, fünf OCMs Oracle Spezialisierungen im Bereich Oracle 11g Datenbank, Oracle 11g Real Application Cluster und Oracle 11g Performance Tuning Wir unterstützen Sie von der Applikation/Datenbank bis hinunter zur Infrastruktur/Storage und haben damit einen ganzheitlichen Ansatz zum Thema Performance.

4 Auszug aus der Kundenliste

5 Themenübersicht Architektur Oracle In-Memory Cache Option Einführung und Umsetzung von In-Memory Cache Option Real World Beispiele und Ergebnisse Vergleich SAP HANA versus Oracle In-Memory Database Cache Option

6 Architektur Oracle In-Memory Cache Option Voraussetzungen für sinnvolle In-Memory Cache Nutzung SGA Bereich für In-Memory Cache Wo ist In-Memory besonders schnell Oracle 12c Release 2 In Memory Neuheiten Zusammenspiel mit anderen Optionen und Strukturen

7 Voraussetzungen für die In-Memory Cache Nutzung Hauptspeicher Noch mehr Hauptspeicher Noch viel mehr Hauptspeicher (aktuelle Server können mehrere TB Hauptspeicher enthalten) Wir haben aber auch bei einem POC auf einem Server mit 16GB Memory gezeigt, dass das ausreichen kann, sofern die benötigten Tabellen ins Memory passen. Größenordnung: 25-50% der Segment Size der Tabellen/Partitionen die man im In-Memory Cache haben möchte Und im Falle von Virtualisierung: es muss die HW Virtualisierung der CPU eingeschaltet sein (bei Intel VT-x, VT-d)

8 SGA Bereich für In-Memory Cache In der SGA wird ein zusätzlicher Bereich der In-Memory Column Store bereitgestellt Sobald auf den Tabellen definiert ist, dass sie In-Memory nutzen sollen, landen diese auch im Column Store Innerhalb des Column Stores gibt es 1MB große Column Units in denen die Daten abgelegt werden. Verwaltungsstruktur (Transaktionsbereich) umfasst ca. 15% des Column Stores

9 Wie ist der Column Store aufgebaut Jede Column Unit gehört zu einer bestimmten Tabelle (eine Tabelle belegt mehrere/viele Column Units) und enthält die Daten von aufeinanderfolgenden Daten (Rows) Die Daten werden aber nicht zeilenweise (Row) sondern spaltenweise (Column) abgelegt dabei werden diese nach der Spalte sortiert und pro CU und Spalte gibt es einen MAX und MIN Information à hilft bei Queries, CUs auszulassen, die keine relevanten Daten enthalten.

10 DML und Column Store DML muss die Daten in beiden Bereichen (Row, Column) pflegen. Im Row Bereich ändert sich nichts Für den Column Bereich wird etwas geschummelt Während des DMLs werden die entsprechenden Daten im Column Store auf Stale gesetzt. Die Änderungsinformation wird im TX Journal zwischengespeichert Bei Queries im Column Store erkennt der Optimizer den Zustand Stale und greift entsprechend auf das TX Journal und/oder den Buffer Cache zu Besonders heiße Tabellen sind daher nicht optimal

11 Neue Hintergrundprozesse für In-Memory IMCO SMCO Wnnn In Memory Coordinator Prozess Neu Space Management Coordinator Prozess verteilt die Arbeit auf die Wnnn Auch für Flashback Data Archive, Temporal History, Worker Prozesses In Memory Populate Server Prozesses befüllen / aktualisieren den Column Store

12 Was ist im Column Store besonders schnell? Zugriffe auf einige (wenige) Spalten von sehr großen Tabellen Vor allem mit SUM, AVG, und GROUP BY Mit Einschränkungen mit =, >, < und IN Data Warehouse Abfrage (FACT, DIMENSION Tabellen) Dort wo in Queries Full Table Scan, Full Index Scan, Fast Full Index Scan und Index Range Scan über große Ranges vorkommen. Wo wird es generell schneller: Dort wo man unnötige Indexes eliminieren kann!

13 In-Memory Column Store versus andere Strukturen Die Frage ist: Was kann mir der In-Memory Column Store ersparen und womit kooperiert er sehr gut? Struktur Zusammenarbeit PK, UK, FK IDX Werden für die relationale Verarbeitung benötigt, sind dem Column Store soweit egal. belassen IDX für Query Kann man in den meisten Fällen löschen (= DML wird schneller), der Column Store ist meist schneller weg Bitmap Index Hier gilt das gleiche wie für IDX für Query weg MView Partitioning RAC MView + Column Store = geniale Performance Man kann den Detailgrad im MView sogar erhöhen und die Performance passt immer noch (Beispiel: Tagesdaten statt Monatsdaten, dadurch sind auch detailliertere Analysen performant möglich!) Speziell, wenn damit aktuelle von nicht aktuellen Daten separiert werden können, spart Column Store eine Menge Platz à Ideale Kombination Voller RAC Support es benötigt nur einen entsprechend schnellen Interconnect (>= 10GBit), sonst wird In-Memory im RAC ausgebremst. optimal optimal Vorsicht

14 Oracle 12c Release 2 In Memory Neuheiten Faster Joins Join Groups Expressions JSON Support Heat Map Integration Active Data Guard support Oracle Hardware Integration

15 Faster Join In der Query kommt nur STORES.TYPE = ' OUTLET' sowie der Join selbst vor, das kann Oracle entsprechend umsetzen...

16 Join Groups Durch Join Groups werden die Metadaten der Join Spalte(n) in der gleichen Struktur abgelegt. Die Daten in den IMCUs werden entsprechend abgelegt. Reduziert den Decompress- Aufwand beim Datascan Schnelleres Finden der Daten (HASHING) beim Join CREATE INMEMORY JOIN GROUP vehicles_sales_jg (VEHICLES (NAME),SALES (NAME))

17 In-Memory Expressions Expressions wurden für normale Tabellen schon in Oracle 12cR1 eingeführt. In 12cR2 funktioniert das jetzt auch für In-Memory CREATE TABLE SALES (... NETTO_PREIS NUMNER, STEUER NUMNER,... BRUTTO_PREIS AS (NETTO_PREIS * STEUER)); SELECT... FROM SALES WHERE BRUTTO_PREIS = 1200;

18 JSON JSON ist jetzt Teil der In-Memory Funktionalität. Dadurch sollen JSON Queries bis zu 60 mal schneller werden.

19 In-Memory und Heat Map Tabelle SALES ist Interval partitioniert (monatlich) Für In-Memory steht nicht genug Speicher zur Verfügung um mehr als 2-3 Monate Online zu halten. Die Frage ist nur: welche? HEAT_MAP = ON Automatisch durch Oracle: INMEMORY_ADO_ENABLED = TRUE Manuell durch ILM Policy: alter table sales ilm add policy no inmemory after 31 days of no access of creation of no modification;

20 Offload In-Memory to Active Data Guard In-Memory kann nun auf der Active Data Guard Instanz laufen Redo (DML & DDL) wurde um In-Memory Infos erweitert Syntax: INMEMORY DISTRIBUTE FOR SERVICE

21 In-Memory und Hardware Exadata In-Memory in Flash SPARC In-Memory IMCUs können im Storage Flash gespeichert werden, dadurch keine Populierungszeiten nach einem Restart der Instanzen. In-Memory in Silicion Schnellere Joins In Hardware Decompress

22 Was ist der Vorteil von In-Memory gegenüber anderen Lösungen? (Marketingeinschaltung?!) In Memory einschalten, Tabellen In-Memory aktivieren, fertig Applikationsanpassungen: keine (außer drop Index) Funktionseinschränkungen: keine, alle Features sind unterstützt Migrationsaufwand: keiner Änderungen Backup/Recovery: keine Nein, das ist kein Marketing! Wir haben POCs teilweise in wenigen Stunden abgeschlossen!

23 Einführung und Umsetzung von In-Memory Cache Option In-Memory Konfigurieren Tabellen, MViews auf In-Memory umstellen In-Memory Option mögliches Feintuning Wo kann man nachsehen (Session, Instance Ebene) Execution Plan mit In-Memory Verarbeitung

24 In-Memory Konfigurieren Es ist wirklich einfach: alter system set compatible= scope=spfile; alter system set INMEMORY_SIZE=200G scope=spfile; shutdown immediate; startup;

25 In-Memory Konfigurieren (12cR1) Es gibt aber auch einige weitere Parameter Parameter INMEMORY_SIZE INMEMORY_FORCE INMEMORY_MAX_POPULATE_ SERVERS INMEMORY_QUERY Zweck Größe des Column Stores + TX Journals DEFAULT OFF deaktivieren von INMEMORY Anzahl der Hintergrundprozesse, die den Column Store befüllen/aktualisieren. Default = CORE / 2 ENABLE DISABLE (Sess + Instance) INMEMORY_TRICKLE_REPOPULA TE_SERVERS_PERCENT wie viel Prozent der POPULATE SERVERS dürfen für aktualisieren genutzt werden. INMEMORY_CLAUSE_DEFAULT Default = keine INMEMORY NOINMEMORY NO MEMCOMPRESS MEMCOMPRESS FOR { DML QUERY [ HIGH LOW ] CAPACITY [ LOW HIGH ] PRIORITY { LOW MEDIUM HIGH CRITICAL NONE } RAC only: DISTRIBUTE [ AUTO BY ROWID RANGE BY PARTITION BY SUBPARTITION ] NO DUPLICATE DUPLICATE ALL OPTIMIZER_INMEMORY_AWARE TRUE FALSE

26 Tabellen, MViews auf In-Memory umstellen Neues Objekt (Tabelle, MView): create table new(x number) INMEMORY; Bestehendes Objekt ändern: alter table new INMEMORY; Mit allen Optionen aus INMEMORY_CLAUSE_DEFAULT Compression (Deduplizierung ab wo braucht man die Compression Option?) Priority wie wichtig ist das Objekt, wie schnell soll es nach einem Restart der Instanz geladen werden (CRITICAL = sofort nach open) Distribute (RAC) - wie sollen die Daten in den Column Stores verteilt werden Duplicate (RAC) nur in eine Instanz, in zwei oder in alle.

27 Tabellen, MViews auf In-Memory umstellen und Memory sparen Durch Angabe, welche Spalten nicht in den Column Store sollen create table emp (first_name varchar2(16), last_name varchar2(16), CV varchar2(4000), ) INMEMORY NO INMEMORY (CV); Bei partitionierten Tabellen INMEMORY pro Partition einstellbar MEMCOMPRESS Einstellung anpassen

28 In Memory Compress Der Platzverbrauch hängt natürlich davon ab, wie viele distinct values es gibt und welche Datentypen es sind. Beispiel eines SAP POCs Objekt DISK FOR QUERY LOW FOR QUERY HIGH Remark RSRWBSTORE 17.3 GB 14.4GB 14.2GB 4 Spalten + BLOB /BIC/ECOPA_01 6.9G 1.7G 1.2G Viele Spalten, meist Number, Row ca. 300 Bytes /BIC/EEG_BCO_12 1.8G 0.97G 0.65G Viele Spalten, meist Number, Row ca. 160 Bytes

29 Wo kann man nachsehen? In Memory V$ Views V$VIEW V$IM_SEGMENTS V$IM_SEGMENTS_DETAIL V$IM_USER_SEGMENTS V$IM_COLUMN_LEVEL V$IM_HEADER V$IM_COL_CU V$IM_SMU_HEAD V$IM_SMU_CHUNK V$IM_TBS_EXT_MAP V$IM_SEG_EXT_MAP Inhalt Informationen über die Segmente im Column Store inkl. den INMEMORY Storage Einstellungen Etwas mehr Detailinfo zu V$IM_SEGMENTS Wie V$IM_SEGMENTS, aber nur für die eigenen Tabellen Infos im Falle einer Abweichung der Spalteneinstellung von der des Segments Detailinfos zu den IMCUs (welches Segment, wie viele Datensätze, wie viel Platz, ) Detailinfos zu jeder Spalte im IMCU (Platzbedarf, MinVal, MaxVal, ) TX Journal Header für jede IMCU TX Journal Detail für jede IMCU Welche Datenblöcke werden in welcher IMCU angelegt Interne Informationen zu den IMCU inkl. NUMA (CPU Memory Zuordnung)

30 Wo kann man nachsehen? DBA_TABLES V$SESSTAT / V$MYSTAT in Memory Storage Infos select sn.name, ss.value from v$mystat ss, v$statname sn where ss.statistic#=sn.statistic# and sn.name like 'IM%' /* oder 'IM scan%' */; V$SYSSTAT V$SEGMENT_STATISTICS select owner, object_name, subobject_name, statistic_name, value from v$segment_statistics where statistic_name like 'IM%' and (owner, object_name, nvl(subobject_name,' ')) in (select owner, segment_name, nvl(partition_name,' ') from v$im_segments);

31 Hilfreiche Queries für In-Memory (1) In-Memory Definitionen auf Tabellen select table_name, inmemory, inmemory_distribute, inmemory_compression, inmemory_priority, inmemory_distribute, inmemory_duplicate from dba_tables where inmemory='enabled'; Segmente aktuell schon im Column Store select * from v$im_segments; select segment_name, partition_name, POPULATE_STATUS, inmemory_size, bytes, bytes_not_populated from v$im_segments;

32 Hilfreiche Queries für In-Memory (2) Welche von den In-Memory definierten Tabellen sind schon In- Memory? select t.owner, table_name, t.inmemory, t.inmemory_distribute, t.inmemory_compression, t.inmemory_priority, t.inmemory_duplicate, i.populate_status, i.inmemory_size, i.bytes as bytes_on_disk, trunc(100/i.bytes*i.inmemory_size,2) as compress_pct from dba_tables t, v$im_segments i where table_name=segment_name(+) and t.inmemory='enabled'; Größe auf Disk versus In-Memory Column Store select owner, segment_name, partition_name, bytes/1024/1024/1024 GB_DISK, inmemory_size/1024/1024/1024 GB_INMEMORY, 100/bytes*inmemory_size as COMP_PCT from v$im_segments;

33 DBMS_COMPRESSION. GET_COMPRESSION_RATIO PROCEDURE GET_COMPRESSION_RATIO Argument Name Type In/Out Default? SCRATCHTBSNAME VARCHAR2 IN OWNNAME VARCHAR2 IN OBJNAME VARCHAR2 IN SUBOBJNAME VARCHAR2 IN COMPTYPE NUMBER IN BLKCNT_CMP BINARY_INTEGER OUT BLKCNT_UNCMP BINARY_INTEGER OUT ROW_CMP BINARY_INTEGER OUT ROW_UNCMP BINARY_INTEGER OUT CMP_RATIO NUMBER OUT COMPTYPE_STR VARCHAR2 OUT SUBSET_NUMROWS NUMBER IN DEFAULT OBJTYPE BINARY_INTEGER IN DEFAULT

34 DBMS_COMPRESSION. GET_COMPRESSION_RATIO Beispielaufruf set serverout on declare blk_cmp binary_integer; blk_uncmp binary_integer; row_cmp binary_integer; row_uncmp binary_integer; cmp_ratio number; comptype varchar2(80); begin dbms_compression.get_compression_ratio('psapebi','sapebi','rsrwbstore',null, DBMS_COMPRESSION.COMP_INMEMORY_NOCOMPRESS,blk_cmp, blk_uncmp, row_cmp, row_uncmp, cmp_ratio, comptype, ,1); DBMS_OUTPUT.PUT_LINE('Block Cnt NONCOMP =' blk_uncmp); DBMS_OUTPUT.PUT_LINE('Block Cnt COMP =' blk_cmp); DBMS_OUTPUT.PUT_LINE('Row Cnt NONCOMP =' row_uncmp); DBMS_OUTPUT.PUT_LINE('Row Cnt COMP =' row_cmp); DBMS_OUTPUT.PUT_LINE('COMP Ratio =' cmp_ratio); DBMS_OUTPUT.PUT_LINE('COMP Type =' comptype); end; /

35 Execution Pläne mit In-Memory Join ist bei In-Memory immer ein HASH Join Zugriff auf In-Memory mittels TABLE ACCESS INMEMORY FULL JOIN FILER CREATE & USE = BLOOM Filer Support für partitionierte Tabellen

36 Execution Plan In-Memory und normale Tabellen Hier ein FTS auf eine normale Tabelle Indexzugriffe sind natürlich auch möglich

37 Real World Beispiele und Ergebnisse Beispiele, wo In-Memory gut oder nicht so gut abschneidet Real World Data Warehouse Applikation Ergebnisse Tests mit SAP HR und SAP BI

38 Beispiele wo In-Memory sehr gut abschneidet Wenn im Execution Plan folgendes zu finden ist: Full Table Scan auf Tabellen > 1M select count(*) from (select /*+ FULL(s) */ * from SAPEBI."/BIC/EEG_BCO_12" s ); -- Disk: 11G, In-Memory: 3.8G, ca. 60 Mio Records -- nur Buffer Cache: ca. 3 Sekunden mit In-Memory: 660ms, das ist ein Faktor 5 In-Memory ist nicht nur schneller, sondern benötigt in diesem Beispiel nur 1/3 des Hauptspeichers im Vergleich zu Buffer Cache, zusätzlich kann man sich Indexes sparen! Fast Full Index Scan auf Index bzw. Full Index Scan auf Index > 1M, sofern zusätzlich auf die Tabelle zugegriffen wird Große Index Range Scans oder Index Skip Scans > 1M, sofern zusätzlich auf die Tabelle zugegriffen wird Klassische Data Warehouse Query (FACT, DIMENSION, GROUP BYs) Aggregationen auf einzelne Spalten select /*+ FULL(s) */ sum(key_eg_bco_12p), sum(key_eg_bco_127) from SAPEBI."/BIC/EEG_BCO_12" s; -- nur Buffer Cache: ca. 7 Sekunden mit In-Memory: 70ms, das ist ein Faktor 100!

39 Beispiele wo In-Memory nicht so gut abschneidet Sehr komplexe Queries, bei denen viele Daten auf Grund von WHERE aussortiert werden, In-Memory aber alle IMCUs lesen muss Siehe SAP BI, wo eine Query mit In-Memory langsamer war als ohne. Queries, die viele Spalten verarbeiten/ausgeben Queries, die aktuell im (Milli)sekundenbereich laufen

40 Beispiele wo In-Memory nicht verwendet wird Queries mit PK, UK = Queries, die komplett über Index abgebildet werden können

41 Real World Data Warehouse Applikation Ergebnisse POC auf einem Rechner mit 16GB Memory! DWH Query eines Kunden select PMATCH_MODEL_NAME, sum(price), avg(price), max(price), min(price) from offer_fact_client1 f, date_dim d, product_dim p where f.extract_date_fk = d.dimension_key and f.product_dim_fk = p.dimension_key and d.day between ' ' and ' ' and p.pmatch_model_brand_name = 'IBM' group by PMATCH_MODEL_NAME order by PMATCH_MODEL_NAME; Buffer Cache 1GB: 80 Sekunden ## Alle Tabelle+Idx brauchen >3GB auf Disk InMemory 1GB: 0.33 Sekunden ## Es passt alles in 1GB im Memory Faktor: Aber ein unfairer Vergleich, da Buffer Cache zu klein war. Weitere Ergebnisse Durchschnittliche Queries wurden (alles im Memory) um geringe Faktoren schneller, aber Refresh um Faktoren schneller da keine BITMAP IDX und viel weniger Indexes Jede Abfrage ist schnell, nicht nur die für die getuned wurde Column Store oft deutlich kleiner als vorher vermutet

42 POC Tests mit SAP HR SAP HR Der SAP Applikation Server holt sich meist nur Einzelrows von der Datenbank (Query Laufzeit <1ms) Bei den getesteten Verarbeitungen (Laufzeit im Bereich von 5-15 Minuten) war die Datenbank im Schnitt deutlich unter 5% der Verarbeitung à selbst wenn man hier einen Faktor 10 bekommen würde, sind das nur wenige % der Laufzeit Solange die Verarbeitung außerhalb der Datenbank die Zeit verbraucht, kann In-Memory nicht helfen (und auch kein SAP HANA).

43 POC Test mit SAP BI Wir haben 3 TOP Queries vom Kunden eingehend getestet Bei einer Query hat In-Memory deutlich geholfen Marketing würde sagen: von 2746 Sekunden auf 100 Sekunden Query gleich nach Start der Instanz (20GB BC) versus In-Memory Kunde würde sagen: von ca Sekunden auf ca 100 Sekunden Query wenn die Datenbank warmgelaufen ist (20GB BC) versus In-Memory Wir sagen: von ca. 380 Sekunden auf ca. 100 Sekunden Daten komplett im Buffer Cache (256GB BC) versus In-Memory Bei den beiden anderen Queries war das Ergebnis Faktor 0,5 und Faktor 2 (bei 256BC versus In-Memory, mit zu kleinem Buffer Cache immer noch zweistellige Faktoren!) Aber: wir konnten die Bitmap Indexes ohne Performanceunterschied droppen, das hat ohne In-Memory zu Faktor >50 längeren Laufzeiten geführt.

44 Test mit SAP BI, aber selbst geschrieben Queries select count(*) from SAPEBI."RSRWBSTORE"; Fast Full Scan auf PK select count(distinct CLUSTR) from SAPEBI."RSRWBSTORE"; Full Table Scan select count(*) from (select WORKBOOKID, count(*), count(distinct OBJVERS) from SAPEBI."RSRWBSTORE" group by WORKBOOKID); Fast Full Scan auf PK select count(*) from (select WORKBOOKID, count(*), count(distinct OBJVERS) from SAPEBI."RSRWBSTORE" where WORKBOOKID like 'A%' group by WORKBOOKID); Index Range Scan auf PK select count(*) from (select WORKBOOKID, count(*), count(distinct OBJVERS) from SAPEBI."RSRWBSTORE" where WORKBOOKID like '%A' group by WORKBOOKID); Fast Full Scan auf PK select count(*) from (select WORKBOOKID, count(distinct CLUSTR) from SAPEBI."RSRWBSTORE" where WORKBOOKID like '%A%' group by WORKBOOKID); Full Table Scan

45 Test mit SAP BI, aber selbst geschrieben Queries Ergebnisse Query BC zu klein BC groß genug In-Memory Index behalten Q1: count(*) 200ms, FFS ident ident 62ms Q2: count(distinct CLUSTR) >40sek, FTS ca 3 Sek 31ms, InMemory FTS 31ms Q3: WORKBOOKID, count(*) 650ms, FFS+group ident ident 470ms Q4: WORKBOOKID like 'A%' 125ms, IRS+group ident ident 62ms Q5: WORKBOOKID like '%A' 560ms, FFS+group ident ident 787ms Q6: WORKBOOKID like '%A%' >40Sek, FTS+group ca 3 Sek 110ms, InMemory FTS 100ms In-Memory Index gedropped

46 Vergleich SAP HANA versus Oracle In-Memory Database Cache Option Was sagen Oracle und SAP über die jeweilige Lösung des Mitbewerbers? Zertifizierung für Oracle In-Memory für SAP HANA

47 Was sagen Oracle und SAP über die jeweilige Lösung des Mitbewerbers? Oracle: In-Memory Versus SAP HANA SAP: In-Memory versus SAP HANA the FACTs Beides finden Sie in einem Artikel auf unserer Homepage

48 Was sagen Oracle und SAP über die jeweilige Lösung des Mitbewerbers? Ein Auszug Business Need Oracle In-Memory Oracle zu SAP HANA SAPs Facts (=Antwort) DB Masters und Kundenfeedback Transparent für die Applikation 100% alle Applikationen laufen sofort ohne Code zu ändern. Muss auf HANA angepasst werden (teilweise neu schreiben!) Viele 3rd Party Apps und BI Tools laufen gegen HANA. Feedback von HANA Kunden: massive Anpassungen, viel SAP Teile laufen (noch immer) nicht. Keine spezielle Hardware nötig Läuft auf jeder Hardware Braucht speziell zertifizierte - sehr teure - Hardware Wir supporten Intel X86, Power, Vmware (aber nur speziell zertifizierte Lösungen!) Es gibt einige Performance Features die Oracle HW voraussetzen, aber sonst sind wir Oracles Meinung Anforderungen an DBA, Developer Keine neuen APIs, lediglich einige wenige Einstellungen für DBAs Um HANA optimal zu nutzen muss man viel neues lernen und umsetzen HANA kann man schnell lernen es ist ja eine ANSI standard Datenbank. Kundenfeedback: Viel Aufwand (und noch viele BUGs) Hohe Verfügbarkeit Die Oracle Datenbank ist sehr stabil und RAC, Data Guard,.. sind verfügbar Kein HA, restart dauert sehr lange, kein transparentes ausfallen von Knoten möglich, HANA kann HA (System Replikation, Storage Replikation, ) aber kein Wort zu Restart dauert sehr lange Kundenfeedback: SAP HANA ist (noch) nicht stabil und HA ist im Vergleich zu Oracle aufwändig und kompliziert.

49 Zertifizierung für Oracle In-Memory für SAP SAP lässt sich oft sehr viel Zeit um neue Technologien zu zertifizieren (siehe Exadata, ) im Moment gibt es von SAP eine SAP on Oracle Database 12c Roadmap, in der steht, dass mit SAP 7.XX der Support für Oracle kommen wird kein Wort zu In-Memory in diesem Zusammenhang. Es gibt von Seiten der Oracle SAP Kunden eine Petition an SAP, dass die Oracle In-Memory Option möglichst schnell zertifiziert wird. Bei Interesse diese Petition zu unterschreiben, bitte mit Oracle Österreich Kontakt aufnehmen.

50 Zusammenfassung (1) In Memory ist SUPER Implementierung ist in wenigen Minuten erledigt Queries teilweise um hohe Faktoren schneller SAP BI Queries bis zu Faktor 14 Unsere Test Queries bis zu Faktor 1300 DWH Queries bis zu Faktoren >50 Richtiges Indexing ist kein Thema mehr Durch droppen von queryonly Indexes das DML (oder ETL) schneller macht Durch droppenvon Bitmap Indexes beim Datenladen nicht mehr stören Gerade wenn wirklich Enduser selbst Query absetzen können, kommt das Ergebnis in einer sinnvollen Zeit zurück!

51 Zusammenfassung (2) In Memory bringt wenig / nichts Bei OLTP, wenn die Queries (fast) alle in wenigen ms fertig sind Queries mit PK = Value Queries mit wenigen Rows Ergebnis über PK/UK/FK Index Bei schon optimierten DWH Strukturen, wenn In-Memory nicht vernünftig filtern kann (keine IMCUs auslassen kann) Einige SAP BI Queries im Bereich von Faktor 0.5 (doppelt so lange) bis 2 Wenn die Zeit außerhalb der Datenbank liegen bleibt (siehe SAP HR)

52 Zusammenfassung (3) Unsere Meinung zu In-Memory Mann darf nicht Äpfel mit Birnen vergleichen! Wenn man die Daten vom aktuellen System (dass eine zu kleinen Buffer Cache hat) mit einem neuen System mit In-Memory vergleicht, kann In-Memory nur gewinnen. Damit man sieht ob und wie viel In-Memory bringt, muss man es mit den Laufzeiten bei ausreichend großem Buffer Cache vergleichen Es kommt auf die Anwendung an OLTP wenig sinnvoll, möglicherweise punktuell einsetzbar große Tabellen mit vielen Indexes um die Indexes zu eliminieren DWH/DSS Hier hilft In-Memory wirklich, oft wird es schneller, aber falls nicht, ist man das Indexing Thema los! Wir empfehlen eine POC bevor man auf In-Memory umsteigt.

53 DB Masters Event 2017 am 14. März 2017 in Wien Anmeldung via Vorträge: Oracle s selfmanagingdatabase Versprechen Oracle High Performance Datenbank Implementierung EU Datenschutzgrundverordnung für DBAs und Entwickler Row Pattern Matching Datenanalyse auf neuem Level Oracle System Statistics und I/O Calibration Oracle Ressource Manager ein massiv unterschätztes Feature ADRCI, Log- und Tracefile Management Oracle 12cR2 und pnfs Teaser:

54 Q & A