Oracle Database In-Memory Option Architektur und Funktionsweise

Transkript

1

2 Regionalgruppe Frankfurt Oracle Database In-Memory Option Architektur und Funktionsweise Frank Schneede Leitender Systemberater Oracle BU Database DOAG Rhein-Main-Treffen, Copyright 2014, Oracle and/or its affiliates. All rights reserved.

3 Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. 3

4 Agenda Konzepte Konfiguration Funktionsweise des Column Stores Zugriffe Fazit, Tipps, Informationen 4

5 Oracle Database In-Memory Ziele Hochperformante Real Time Analysen Hocheffizientes OLTP Keine Änderung von Applikationen Nutzung der aktuellen Mikroprozessor Architektur CPU Copyright 2014, Oracle and/or its affiliates. All rights reserved.

6 Result Cache Shared Pool oder Client Transparent für Anwendungen Flash Cache Data Buffer Erweiterung 2 nd level Cache Auch für Datafiles Database Buffer Default Cache Keep Cache Recycle Cache LRU-Algorithmus In-Memory Techniken der Datenbank Memory optimierende Techniken Compression Partitioning Parallelisierung OLAP Exadata X4 Hybrid Columnar Compression Smart Scan Storage Index Smart Flash Cache (Read/Write) Smart Flash Logging (Redo-Write) In-Memory Option 12c Row und Column In-Memory Formate auf der selben Tabelle Simultan und transaktionskonsistent Column: Analytics & Reporting Row : OLTP TimesTen IMDB TimesTen Application-Tier Database Cache TimesTen for Exalytics In-Memory Techniken der Middle-Tier Coherence Data Grid Object Cache / Data Grid für verteilte Anwendungen Copyright 2014, Oracle and/or its affiliates. All rights reserved.

7 Result Cache Shared Pool oder Client Transparent für Anwendungen Flash Cache Data Buffer Erweiterung 2 nd level Cache Auch für Datafiles Database Buffer Default Cache Keep Cache Recycle Cache LRU-Algorithmus In-Memory Techniken der Datenbank Memory optimierende Techniken Compression Partitioning Parallelisierung OLAP Exadata X4 Hybrid Columnar Compression Smart Scan Storage Index Smart Flash Cache (Read/Write) Smart Flash Logging (Redo-Write) In-Memory Option 12c Row und Column In-Memory Formate auf der selben Tabelle Simultan und transaktionskonsistent Column: Analytics & Reporting Row : OLTP TimesTen IMDB TimesTen Application-Tier Database Cache TimesTen for Exalytics In-Memory Techniken der Middle-Tier Coherence Data Grid Object Cache / Data Grid für verteilte Anwendungen Copyright 2014, Oracle and/or its affiliates. All rights reserved.

8 Beispiele für Caching Technologien in 11g Pre-Load von Tabellen und Indizes Full Table/Index Scans und Initialisierungsparameter (_small_table_threshold) SGA Bereiche: KEEP und RECYCLE Pool für Tabellen und Segmente DB_[KEEP RECYCLE]_CACHE_SIZE und Storage Parameter (KEEP, RECYCLE) Pinnen von PL/SQL Objekten wie Packages, Procedures etc. im Shared Pool Einsatz von dbms_shared_pool.keep Cachen von Resultaten Spezielle Hints, Initialisierungsparameter oder Objektdefinition 8

11 In-Memory Column Store Kurzbeschreibung Pure In-Memory Columnar SALES Reines In-Memory Format Komprimierte Bereiche mit unterschiedlichen Raten (2x bis 20x) Einschaltbar auf Objektebene Verfügbar auf allen Plattformen Voraussetzungen Datenbank Release Manuelle Aktivierung Gebunden an In-Memory Option 11

12 In-Memory Column Store Im Detail IMCU IMCU IMCU IMCU Jedes Objekt im Column Store besteht aus mehreren In- Memory Compression Units (IMCU) IMCU IMCU IMCU IMCU IMCU IMCU Jede IMCU enthält einen Teil der Spalteneinträge eines Objekts IMCUs können in der Größe variieren - abhängig vom Datentyp und der Komprimierungsrate 12

13 Prinzipielle Unterschiede zum traditionellen Buffer Cache Der Column Store ist statisch und folgt keinem LRU (Least Recently Used) Algorithmus Der Column Store ist ein reines Memory Format Der Column Store ist geeignet für einheitliche Zugriffe (alle Zeilen einer Tabelle) => typisch für analytische Abfragen Der Buffer Cache hingegen ist vorgesehen für nicht einheitliche Zugriffe (z.b. einige Zeilen einer Tabelle) => typisch für OLTP Der Column Store ist mit zusätzlichen neuen Optimizerzugriffen und Komprimierungsalgorithmen ausgestattet 13

14 Das duale Format in der Datenbank Memory SALES Row Format Memory SALES Column Format Beides - Row und Column In-Memory Formate - für die gleiche Tabelle Real Time Analysen nutzen das neue Column Format OLTP Applikationen nutzen das Row Format Erhalt der Transaktionskonsistenz 14

15 Buffer Cache versus In-Memory Column Store? SELECT column4 FROM mytable; RESULT Mit Buffer Cache Buffer Cache Mit Column Store IM Column Store X X X X X Row Format Column Format 15

16 Konfiguration in 2 Schritten 1. Memory Allokation in der SGA über neuen Initialisierungsparameter und danach Start der Datenbank 2. Auswahl der Objekte (Spalten, Tabellen, Materialized Views, Tablespace oder Partitionen) und Belegung mit den entsprechenden Eigenschaften Über CREATE oder ALTER Kommando u.u. überflüssige analytische Indizes löschen! => Nicht alle Objekte müssen im Column Store vorliegen! 16

17 Beispiel für In-Memory Column Store Konfiguration Setzen von INMEMORY_SIZE Parameter (mindestens 100 MB) Default ist 0 Gesamt SGA muss groß genug sein SGA_TARGET Statischer Pool Aufteilung in 64K und 1MB Pool Monitoring über V$INMEMORY_AREA Aufteilung der Pools und Befüllungsgrad SQL> sho sga Total System Global Area bytes Fixed Size bytes Variable Size bytes Database Buffers bytes Redo Buffers bytes In-Memory Area bytes 17

18 Festlegung der Objekte: Neue Schlüsselworte Ein- und Ausschalten einer gesamten Tabelle ALTER TABLE sales INMEMORY; Auf Spaltenebene ALTER TABLE sales INMEMORY NO INMEMORY(prod_id, cust_id)); Auf Partitionsebene CREATE TABLE customers PARTITION BY LIST (PARTITION p1 INMEMORY, (PARTITION p2 NO INMEMORY); Auf Tablespaceebene CREATE TABLESPACE tbs1 DATAFILE /home/oracle/ /tbs1.dbf' SIZE 1G ONLINE DEFAULT INMEMORY; 18

19 Verteilung von Tabellendaten über Speicherhierarchien Umsatzdaten DISK SSD Flash In Memory Juni 14 Juni 14 Mai 14 Mai 14 April 14 März 14 Februar 14 Januar 14 Dezember 13 November 13 Oktober 13 September 13 August 13 Juli13 Juni 13 April 13 März 13 Februar 13 Oktober 13 September 13 August 13 Juli13 Juni 13 April 13 März 13 Februar 13 Januar 14 Dezember 13 November 13 April 14 März 14 Februar 14 Oracle Database In-Memory Option - Architektur und Funktionsweise Copyright 2014, Oracle and/or its affiliates. All rights reserved. 19

20 Festlegung der Objekte mit Prioritätseinstellung Beeinflussung der Reihenfolge, wie Objekte in den Store geladen werden PRIORITY CRITICAL, HIGH, MEDIUM, LOW und NONE NONE bedeutet beim ersten Zugriff ALTER TABLE lineorder INMEMORY MEMCOMPRESS FOR QUERY LOW PRIORITY CRITICAL; 20

21 Wie funktioniert der Column Store? Wann wird im Column Store gespeichert? Nach dem ersten Zugriff oder gleich nach dem Hochfahren der Datenbank gemäß der Priority Einstellung Welche Daten werden gespeichert? Ausgewählte Daten werden im optimierten und komprimierten Spaltenformat (siehe MEMCOMPRESS) gespeichert. Wer erledigt diese Aufgaben? Ein oder mehrere Hintergrundprozesse (gemäß Parameter INMEMORY_MAX_POPULATE_SERVERS) wie z.b. ORA_W001_orcl Copyright 2014, Oracle and/or its affiliates. All rights reserved.

22 Festlegung der Objekte mit Komprimierungsstufe Komprimierungseinstellungen mit MEMCOMPRESS FOR DML QUERY [LOW HIGH] CAPACITY [LOW HIGH] CREATE TABLE ORDERS PARTITION BY RANGE (PARTITION p1 INMEMORY NO MEMCOMPRESS PARTITION p2 INMEMORY MEMCOMPRESS FOR DML, PARTITION p3 INMEMORY MEMCOMPRESS FOR QUERY, : PARTITION p200 INMEMORY MEMCOMPRESS FOR CAPACITY); 22

23 Monitoring des Column Stores SQL> SELECT v.segment_name name, v.bytes/1024/1024 orig_size_in_m, v.inmemory_size/1024/1024 in_mem_size_in_m, v.bytes/v.inmemory_size comp_ratio, v.inmemory_compression comp, v.bytes_not_populated not_populated, v.inmemory_priority prio FROM v$im_segments v ORDER by 4; NAME ORIG_SIZE_M IN_MEM_SIZE_M COMP_RATIO COMP NOT_POPULATED PRIO LINEORDER FOR QUERY LOW 0 CRITICAL PART FOR QUERY LOW 0 NONE CUSTOMER FOR QUERY LOW 0 NONE DATE_DIM FOR CAPACITY HIGH 0 NONE 23

24 Beispiele für verschiedene Komprimierungsstufen Tabelle LINEORDER MB - 11 Mio. Zeilen Tabelle CUSTOMER - 64 MB Zeilen Compression In Memory (MB) Ratio DML FOR QUERY LOW FOR QUERY HIGH CAPACITY LOW CAPACITY HIGH Compression In Memory (MB) Ratio DML FOR QUERY LOW FOR QUERY HIGH CAPACITY LOW CAPACITY HIGH

25 Komprimierungsstufen aus dem Handbuch 25

26 Weitere Hinweise Handhabung im RAC Umfeld Column Store kann auf jedem RAC Knoten existieren Die gleiche Tabelle kann in jedem Column Store existieren (Option DUPLICATE) Größere Tabellen, die nicht in den Column Store passen, können über die Knoten verteilt werden (Option DISTRIBUTE) Generelle Einschränkungen Objekte, die kleiner als 64 KB sind, werden nicht berücksichtigt. Kein SYSTEM und SYS Objekte Objekte wie IOTs, Cluster Tables, Global Temporary Tables und out-of-line LOBs Option DUPLICATE ist nur auf Engineered System verfügbar 26

27 Berechnung der Speicheranforderung SQL> DECLARE 2 l_blkcnt_cmp PLS_INTEGER; 3 l_blkcnt_uncmp PLS_INTEGER; 4 l_row_cmp PLS_INTEGER; 5 l_row_uncmp PLS_INTEGER; 6 l_cmp_ratio PLS_INTEGER; 7 l_comptype_str VARCHAR2(100); 8 BEGIN 9 dbms_compression.get_compression_ratio ( 10 scratchtbsname => 'TS_DATE', 11 ownname => 'SSB', 12 objname => 'LINEORDER', 13 subobjname => NULL, 14 comptype => dbms_compression.comp_inmemory_query_low, 15 blkcnt_cmp => l_blkcnt_cmp, 16 blkcnt_uncmp => l_blkcnt_uncmp, 17 row_cmp => l_row_cmp, 18 row_uncmp => l_row_uncmp, 19 cmp_ratio => l_cmp_ratio, 20 comptype_str => l_comptype_str); 21 dbms_output.put_line('compression ratio ist ' l_cmp_ratio); 22 END; 23 / compression ratio ist 2 SQL>@size.sql NAME ORIG_SIZE_M IN_MEM_SIZE_M COMP_RATIO COMP BYTES_NOT_POPULATED LINEORDER FOR QUERY LOW 0 1. Objekte identifizieren 2. Compression Advisor dbms_compression verwenden 3. Wendet angegebenen Komprimierungsstufe auf ein Daten Sample an 4. Gibt Compression Ratio aus 27

28 Oracle In-Memory Advisor - Ausblick Noch nicht verfügbar! Spezieller Advisor für In- Memory Abfragen Analysiert Datenbank Workload über AWR & ASH Liefert Objekte die von In- Memory Column Store profitieren würden 28

29 Zugriffe Was passiert beim Absetzen einer Abfrage mit Objekten im Column Store? Welche neuen Optimizerzugriffe gibt es? Was passiert im Fall von Mixed Workloads OLTP und Abfragen? Wie kann die Transaktionskonsistenz beibehalten werden? Wie kann man die Nutzung monitoren? Was passiert, wenn nicht alle Objekte Platz im Column Store finden? Wird die Abfrage trotzdem optimiert? 29

30 Einfacher Zugriff mit In-Memory Scans Memory SALES Column Format Min 1 Max 3 Min 4 Max 7 Min 8 Max 12 Min 13 Max 15 Beispiel: Abfrage auf eine Spaltenuntermenge mit Filterung (z.b. IN, =, > < ) Direkter Zugriff auf entsprechende Spalte Scannen von geringerem Datenvolumen Nutzen einer Art Spaltenindex (Min und Max Wert) => Pruning 30

31 Vector Register REGION Zusätzliche Performance durch Nutzung von SIMD Memory Beispiel: Finde alle Verkäufe (SALES) aus der Region CA Jede CPU Core durchsucht lokal die In-Memory Spalten CPU CA Scans nutzen dabei Single Instruction multiple Data Values (SIMD) Vektor Operationen Mehrere Werte aus Spalte REGION CA CA CA Vektor vergleich aller Werte In 1 Zyklus Hohe Scan Raten pro CPU Core => Milliarden von Zeilen pro Sekunde > 100x Faster 31

32 Monitoring von In-Memory Scans: Ausführungsplan Schlüsselwort INMEMORY FULL SQL> select * from table(dbms_xplan.display_cursor(format=>'basic')); PLAN_TABLE_OUTPUT EXPLAINED SQL STATEMENT: select count(*) from customers_mem where cust_gender='f' Plan hash value: Id Operation Name SELECT STATEMENT 1 SORT AGGREGATE 2 TABLE ACCESS INMEMORY FULL CUSTOMERS_MEM

33 Monitoring: INMEMORY Table Scan Neue Session Level Statistiken mit Präfix IM Zeigen, ob und wie der Column Store verwendet wird select display_name, value From v$mystat m, v$statname n Where m.statistic#=n.statistic# AND display_name IN ('IM scan CUs columns access'im scan segments minmax eligible, 'IM scan CUs pruned'); DISPLAY_NAME VALUE IM scan CUs columns accessed 46 IM scan CUs pruned 0 IM scan segments minmax eligible 23 33

34 DateKey Amount Date DateKey Memory Operationen: In-Memory Joins DATE_DIM LINEORDER Datekey is SELECT SUM(lo_extendedprice * lo_discount) FROM lineorder l, date_dim d WHERE l.lo_orderdate = d.d_datekey AND l.lo_discount BETWEEN 2 AND 3 AND d.d_date='december 24, 2013'; d.d_date='december 24, 2013' Sum In-Memory Joins mit schnellen Scans und speziellen Filtern 34

35 Monitoring In-Memory Joins Spezieller Filter: Bloom Filter Während eines Hash Joins: Erzeugung eines Bitvektors (Bloomfilter) basierend auf Join Bedingung Bitvektor dient als zusätzliches Prädikat für den Scan der zweiten Tabelle 35

36 In-Memory Aggregat Operationen Optimiert Aggregat und Join Operationen in einem typischen Star Schema Nutzt KEY VECTOR und VECTOR GROUP BY Operationen Beispiel SELECT p.category, p.subcategory, g.country, g.state, SUM(s.amount) FROM sales s, products p, geography g WHERE s.geog_id = g.geog_id AND s.prod_id = p.prod_id AND g.state ='CA' AND p.pname = 'Nike' GROUP BY category, subcategory, country, state 36

37 In-Memory Aggregat Operationen PRODUCTS In-Memory Akkumulator Sales 1.Phase - Scan der Dimension Tables - Key Vectors werden berechnet Nike GEOGRAPHY $ $$ $$$ $ - Key Vectors bilden multi dimensionales Array (In-Memory Akkumulator) - Temporäre Tabellen mit SELECT Liste 2.Phase CA Sales - Scan der Fact Table und Anwendung der Key Vectors und danach Befüllung des Akkumulators - Join Back auf die temporären Tabellen Oracle Database In-Memory Option - Architektur und Funktionsweise Copyright 2014, Oracle and/or its affiliates. All rights reserved. Frank Schneede, BU Database

38 DML und In-Memory Column Store Column Format JOURNAL Änderung im Buffer Cache löst automatisch Änderung im Column Store aus => Konsistenz Eintrag in IMCU wird als stale markiert und eine Kopie des neuen Werts wird im In-Memory Transaktions Journal gespeichert Aktualisierung der IMCU über einen Hintergrundprozess 38

39 Monitoring im Cloud Control 39

40 New In-Memory Central Screen in EM Object mapping in 12c Heatmap integriert In-Memory Area (GB) :4.00 In-Memory Area Used (GB) :

41 41

42 42

43 Neue In-Memory Einträge in CPU Wait Class 43

44 Neue In-Memory Einträge in CPU Wait Class 44

45 SQL Monitoring 45

46 Fazit Kostenintensive Abfragen, die aus Table Scans resultieren, identifizieren (Anwender, AWR, statspack, Advisor) Einige Beispiele für Abfragen, die vom In-Memory Column Store profitieren Scannen von vielen Zeilen und Anwendung von Filtern wie z.b. =, <, >, und IN etc. Abfragen einer Teilmenge von Spalten einer Tabelle (5 von 100 Spalten) Joins von kleinen Tabellen mit einer großen Tabelle, wobei die Filter viele Zeilen herausfiltern Abfragen die Operationen verwenden wie min, max und sum, group by, distinct and count(distinct()) Unbedingt auch weitere Tuning Techniken mitberücksichtigen Statistikmanagement, Plan Baseline, Result Cache etc.. 46

47 Informationen Handbücher Concepts Guide Administrator's Guide Performance Tuning Guide Oracle Database In-Memory An Oracle White Paper (Oktober 2014) In-Memory Blog von Maria Colgan 47

49 Virtual Technology Summit LIVE im Netz Systems / Middleware / Java / Database Melden Sie sich jetzt an. Virtual Technology Summit Mittwoch, 25. Februar :00 bis 13:30 LIVE im Netz Systems / Java / Middleware / Database Hands-on Learning mit Oracle und Experten aus der Community Copyright 2014, Oracle and/or its affiliates. All rights reserved.

53 Safe Harbor Statement The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. 53

54 54

55