Exadata ein Blick hinter die Kulissen

Transkript

1 DOAG SIG Database, Köln, Juni

2 <Insert Picture Here> Exadata ein Blick hinter die Kulissen Frank Schneede, Senior System Berater BU Database Technologies, Oracle Deutschland GmbH DOAG SIG Database, Köln,

3 Agenda Exadata Motivation und Einführung Smart I/O Überblick Smart Scan Funktionsweise Exadata Komponenten im RDBMS Exadata Komponenten im Storage Server Steuerung und Überwachung <Insert Picture Here> DOAG SIG Database, Köln, 18. Juni

4 DWH Wachstum Dreifaches Volumen in zwei Jahren! Size of the Largest Data Warehouses 1000 Terabytes of Data Actual Projected Source: Winter TopTen Survey, Winter Corporation, Waltham MA, DOAG SIG Database, Köln, 18. Juni

5 Data Warehouse Ansätze Intelligenz Nutzung von Smart Database Software, um HW Ressourcen zu minimieren Ausgeklügelte Techniken: Partitionierung, MOLAP, Bitmap Indexing, Join indexing, Materialized Views, Result Caches Stärke - Nutzung von extrem schneller HW, um Brute Force Scans zu verarbeiten HW bestimmt Performance DOAG SIG Database, Köln, 18. Juni

6 Data Warehouse Workloads Planbarer User Workload Optimierbar durch intelligente Software- Lösungen Database Grid Adhoc Auswertungen großer Datenmengen Full Table Scans Joins großer Datenmengen Optimierung nur eingeschränkt möglich! DOAG SIG Database, Köln, 18. Juni

7 Bottlenecks bei großen Auswertungen Database Grid I/O-Bedarf von mehreren Gigabytes/sec zu hunderten von Platten Bottlenecks in Architektur: LAN Switches können Last großer Join- Operationen nicht verkraften Server Knoten benötigen hohe Anzahl SAN Adapter Kosten Switches und Komplexität SAN steigen dramatisch Große Storage Arrays können Bandbreite für hunderte Platten nicht bereitstellen Bottleneck Fibre Channel Loops zu Platten Folge: schlechte Performance bei Auswertungen großer Datenmengen DOAG SIG Database, Köln, 18. Juni

8 Einfluß der I/O Bandbreite Business Queries wenn 10 TB gelesen werden muss I/O Bandbreite 1 GB/sec 3 Queries / Tag Frag bloß nicht! 10 TB 10 GB/sec 3 Queries / Stunde Fragen möglich 100 GB/sec 35 Queries / Stunde Alles fragen DOAG SIG Database, Köln, 18. Juni

9 Herausforderung Performance Engpaß I/O-Bandbreite & Interconnect DWH Implementierungen sind oft beschränkt durch die I/O-Bandbreite Zu wenig Host Bus Adapter Inperformante SAN Infrastruktur Zu wenig Platten Weg zu den Platten häufig Faktor 10x bis 100x zu klein Leitungen zwischen den Servern nicht leistungsfähig genug DOAG SIG Database, Köln, 18. Juni

10 HW Komponenten / Sizing Werte Durchsatz Performance (DWH) Komponente Theorie (Bit/s) maximal Byte/s CPU MB/s Fibre Channel 2Gbit/s 140 Mbytes/s Fibre Channel 4Gbit/s 260 Mbytes/s GigE NIC 1Gbit/s 95 Mbytes/s 10GigE NIC 10Gbit/s 900 Mbytes/s Infiniband 20Gbit/s 1900 Mbytes/s DOAG SIG Database, Köln, 18. Juni

11 Beispiel "Non well balanced" Großer SMP Server 32 CPUs Max IO Durchsatz: 3,2 GB/sec 6 x 2 Gb HBA HBA1 HBA2 Max IO Durchsatz: 840 MB/sec 25% Nutzung des Potentials FC-Switch1 FC-Switch2 Storage System 20 phys. Platten a 146 GB Max IO Durchsatz: 280 MB/sec 8,75% Nutzung des Potentials DOAG SIG Database, Köln, 18. Juni

12 Was ist ein balanciertes System? IO Balanced System Ziel: CPU, Memory, Netzwerk und I/O auszubalanzieren CPU Interconnect Memory Referenz Konfiguration IO Throughput Memory Interconnect Minimum: 100 MB/sec per Core Minimum: 4 GB / Core Ideal: 8 GB / Core Empfohlen: 10G Ethernet (10GBit/sec.), noch besser Infiniband (20 GBit/sec.) DOAG SIG Database, Köln, 18. Juni

13 HBA1 Das ist ein balanciertes System HBA2 IC-Switch1 HBA1 HBA2 FC-Switch1 IC-Switch2 HBA1 HBA2 HBA1 HBA2 FC-Switch2 Performanter Interconnect 10GEthernet oder Infiniband Je Port MB/sec. Die schwächste Komponente bestimmt den Durchsatz Jeder Server hat 4 CPUs Alle vier Server erzeugen dann 4 * 150 MB/s * 4 = 2400 MB/s Relevante Komponenten: CPUs: Anzahl und Speed Jeder Server hat 2 x 4 Git HBAs Alle 8 HBAs HBAs (Host können Bus Adapter): Anzahl und Speed 8 * 300MB/s = 2400 MB/s Switch: Anzahl und Speed Controller: Anzahl und Speed Jeder Switch muß 1200 MB/s Disk: Anzahl und Speed garantieren für einen Gesamtsystem Durchsatz von 2400 MB/s 8 Disk Arrays a 16 Platten Pro Disk Array 300 MB/sec. 8 * 300MB/s = 2400 MB/s Disk Array 1 Disk Array 2 Disk Array 3 Disk Array 4 Disk Array 5 Disk Array 6 Disk Array 7 Disk Array 8 DOAG SIG Database, Köln, 18. Juni

14 Verschiedene Lösungsansätze Custom Reference Configurations Optimized Warehouse HP Oracle Database Machine +Komplette Flexibilität +Jede Plattform / SAN +Passt in jede IT Strategie - Aufwendig umzusetzen - Fehleranfälligkeit - Evtl. schlechte Umsetzung + Best-Practice Dokumentation + Beschreibung einer optimalen Umsetzung - Hoher Umsetzungsaufwand + Skalierbare Systeme vorkonfiguriert und "ready to run" + Mit bestimmten Partnern abgestimmt - Vorbestimmte Komponenten + Beste Performance + Voll konfiguriert und installiert + Optimale Preis-Leistung - Exakt vorgegebene Komponenten DOAG SIG Database, Köln, 18. Juni

15 Engpaß I/O-Bandbreite: Lösungsansatz 1. Mehr Kanäle Parallele Architektur 2. Dickere Kanäle 5x schneller (20Gbit anstatt 4Gbit) 3. Transport weniger Daten Reduktion am Plattenspeicher "SMART SCAN" DOAG SIG Database, Köln, 18. Juni

16 Der Oracle Ansatz DB Grid (RAC) InfiniBand Storage Grid (Exadata) Bewährte Oracle RAC-Technologie im Database Grid Nutzung ASM für Performance und Ausfallsicherheit High-Speed Netzwerk der neuesten Technologie Grid-Architektur im Storage aus High- Performance Industrie-Standard- Komponenten Skalierbarkeit (Bandbreite, Datenvolumen) bei gleichzeitiger Ausfallsicherheit Performance und Kostenvorteile im DWH Einfachheit einer DWH-Appliance nahtlos in die Datenbank integriert DOAG SIG Database, Köln, 18. Juni

17 HP Oracle Exadata Storage Server Optimierter Plattenspeicher für Oracle Datenbanken Extreme I/O und SQL Performance 1 GB/sec. Durchsatz pro Exadata Cell Hardware von HP 2 Quad-Core Intel Xeon, 2.66 GHz 12 x 450GB 15K RPM SAS 2 InfiniBand 4X DDR Ports Software von Oracle Exadata Software auf den Cell Boards Smart Scan I/O Ressource Management DOAG SIG Database, Köln, 18. Juni

18 InfiniBand Netzwerk High Performance, Low Latency Netzwerk 20 GBit/s bi-direktionale Bandbreite (d.h. 2GB/s in jede Richtung) Latenz ~150 Nanosekunden Simples Management Infiniband: für Interconnect & I/O Storage Network, 5x Performance (4GBit FC) RAC Interconnect, 20x Performance (1GBit/sec.) Zero-copy Zero-loss Datagram Protocol (ZDP RDSv3) Bestes verfügbares Protokoll Kleiner CPU Overhead Internet Protocol over InfiniBand (IPoIB) Erlaubt die Nutzung sämtlicher Protokolle (tcp/ip, udp, http, ssh, ) DOAG SIG Database, Köln, 18. Juni

19 HP Oracle Database Machine Database Server Grid 8 Server, bestehend aus: 1x HP DL 360-G5 mit 2 Intel Quad-Core Prozessoren, 32 GB RAM Dual-Port Infinibad Host Channel Adapter (HCA) Oracle Enterprise Linux Oracle Database 11g Enterprise Edition mit Real Application Clusters und Partitionierung 4 Infiniband Switches Pro Switch 24 ports Exadata Storage Server Grid 14 Server, bestehend aus: 1x HP DL180-G5 mit 2 Intel Quad-Core Prozessoren, 8GB RAM 12 x 450GB SAS or 1TB SATA Platten Dual-port Infiniband Host Channel Adapter (HCA) Oracle Enterprise Linux Oracle Exadata Storage Server Software Liefert Spitzendurchsatz von 14 GB/s! DOAG SIG Database, Köln, 18. Juni

20 It s simple! Komplett vorkonfigurierte, funktionsfähige und performante Plattform Alle Server richtig konfiguriert und verbunden Alle Komponenten abgestimmt, Infiniband, RDS, Adressen Alle Software installiert (CRS, RAC, DB, Exadata) Default Datenbank erstellt Installation ist Bestandteil der HP Oracle Database Machine HP Installation Services vor Ort Oracle ACS Services vor Ort DOAG SIG Database, Köln, 18. Juni

21 HP Oracle Database Machine: System Architektur HP Oracle Exadata Storage Server 1 HP Oracle Database Server Compute Intensive Processing Data Intensive Processing HP Oracle Exadata Storage Server 1 2 HP Oracle Database Server Compute Intensive Processing Data Intensive Processing HP Oracle Exadata Storage Server 2 Data Intensive Processing 3 HP Oracle Database Server 8 Compute Intensive Processing HP Oracle Exadata Storage Server Data Intensive Processing 14 Clustered Datenbank Server Infiniband Netzwerk Massiv Paralleles I/O-Storage DOAG SIG Database, Köln, 18. Juni

22 Verbesserung I/O-Bandbreite Smart Scan Technologie Exadata Speicher nutzen Oracle Smart Scan Technologie Reduktion der Spalten Reduktion der Zeilen Reduktion durch Join Filter Reduktion des Datenvolumens ist sehr groß Üblicherweise 10-fache Reduktion Vollständige Transparenz...aber dazu später mehr im Detail! DOAG SIG Database, Köln, 18. Juni

23 Skalierbarkeit im parallelen Storage Grid Zusammenfassung von Exadata Zellen in einem parallelen Storage Grid Skalierbarkeit Skaliert bis zu hunderten von Exadata Zellen Automatische Datenverteilung zwischen Zellen durch ASM Transparente Umverteilung bei Hinzufügen bzw. Entfernen von Zellen Datendurchsatz skaliert linear mit der Kapazität Verfügbarkeit Spiegelung der Daten über Zellen Transparente Toleranz gegenüber Platten- bzw. Zellenfehler Einfachheit Arbeitet transparent Keine Anpassung der Anwendung 4 GB/sec 8 GB/sec 16 GB/sec Exadata Bandbreite skaliert linear zur Kapazität! DOAG SIG Database, Köln, 18. Juni

24 Exadata Storage Grid I/O Resource Management Datenbank A Datenbank B Datenbank C..... Verwaltung shared storage? Balance DB-User / Storage schwierig Maßnahme: Isolierung von Hardware Storage Switch/Network Exadata I/O Resource Management Gruppen/Klassen Intra-DB Gruppen/Klassen Inter-DB Priorisierung Definition SLAs DOAG SIG Database, Köln, 18. Juni

25 Exadata verändert die Datenbank Welt Exadata vereint Stärke und Intelligenz: "brawny + brainy" Extreme HW Performance ermöglicht neue Wege Hervorragende Skalierbarkeit Nutzung von Standard HW Zukunftssicherheit: Nutzung neuester Technologien Nahtlose Integration in existierende IT-Infrastrukturen DOAG SIG Database, Köln, 18. Juni

26 Agenda Exadata Motivation und Einführung Smart I/O Überblick Smart Scan Funktionsweise Exadata Komponenten im RDBMS Exadata Komponenten im Storage Server Steuerung und Überwachung <Insert Picture Here> DOAG SIG Database, Köln, 18. Juni

27 Ausgangssituation Well-balanced Hardware Keine Bottlenecks in der Architektur Einsatz von ASM Oracle Exadata Storage Server als zentrale Komponente der Speicherarchitektur: Block I/O : I/O zum lesen/schreiben von Datenbankblöcken Smart I/O : Filter, Auswertung von Prädikaten auf dem Storage Server Schreiben von Blöcken auf dem Storage Server (z. B. Formatieren des Blockes auf dem Storage Server und herausschreiben auf Platte) DOAG SIG Database, Köln, 18. Juni

28 Smart IO was versteht man darunter? Smart I/O ist mehr als nur Block I/O! Block I/O : der gesamte Inhalt der gelesenen Blöcke wird zur Verarbeitung ans RDBMS gesendet Smart I/O : Ein Teil der Operationen (die datenintensiven Teile) wird an den Speicherort der Daten verlagert, den Exadata Storage Server Ergebnisse die vom Speicher zurückgeliefert werden, können durch das RDBMS weiterverarbeitet werden, z. B. Bildung von Summen etc. DOAG SIG Database, Köln, 18. Juni

29 Smart IO steigert die Performance! Reduzierung Netzwerktraffic Datenfilterung durch Smart I/O Operationen, die auf die Speicherzellen ausgelagert werden Reduzierung CPU-Last auf den Datenbankknoten Parallele Abarbeitung ( horizontal ) : Gleichzeitige Bearbeitung der Smart I/O Requests durch alle Exadata Zellen Gleichzeitige Bearbeitung der Smart I/O Requests eines Datenbankprozesses durch mehrere Threads auf einer Exadata Zelle Parallele Abarbeitung ( vertikal ) : Die Exadata Zelle führt weiter Berechnungen aus, während der Datenbankknoten bereits gelieferte Ergebnisse verarbeiten kann DOAG SIG Database, Köln, 18. Juni

30 Smart IO Wie funktioniert das? Smart I/O wird nur durch die Kommunikation von Datenbankknoten und Exadata Zellen ermöglicht Datenbankknoten kann für verschiedene Anwendungsfälle Smart I/O nutzen und wählt zwischen Smart I/O und Block I/O Datenbankknoten fordert Smart I/O an Exadata liefert Smart I/O DOAG SIG Database, Köln, 18. Juni

31 Wo kann das RDBMS Smart I/O nutzen? Smart I/O wird genutzt für: Smart scan Predicate evaluation Auswahl relevanter Zeilen Column selection Auswahl relevanter Spalten Join filtering join Verarbeitung mit Bloom Filter Smart file creation Offload der Blockformatierung Smart file restore for RMAN Offload der Blockformatierung Smart incremental backup Verwendung nur der relevanten Blöcke für das Backup DOAG SIG Database, Köln, 18. Juni

32 Agenda Exadata Motivation und Einführung Smart I/O Überblick Smart Scan Funktionsweise Exadata Komponenten im RDBMS Exadata Komponenten im Storage Server Steuerung und Überwachung <Insert Picture Here> DOAG SIG Database, Köln, 18. Juni

33 Smart Scan im Beispiel Exadata-Zellen nutzen die Smart Scan Technologie, um die Datenmenge zu reduzieren, die der Datenbankserver anfordert Auslagerung der Auswertung von Prädikaten Liefert nur relevante Zeilen/Spalten zurück Join Filter Incremental Backup Filter Anlegen von Files Reduzierung des Datenvolumens ist sehr effektiv Üblicherweise 10-fache Reduzierung Vollständige Transparenz Selbst bei Zellen- oder Plattenausfall während der Abfrage Beispiel: Ein Unternehmen sucht die Kunden, die mehr als 200 für ein Telefonat ausgegeben haben Die Informationen über diese Premiumkunden belegen 2MB in einer 1TB großen Tabelle DOAG SIG Database, Köln, 18. Juni

34 Herkömmliche Abfrage ohne Exadata ❶ SELECT customer_name FROM orders WHERE amount > 200; ❷ Table Extents identifiziert ❸ I/O Abfragen ❻ Ergebnis wird an den Client gesendet ❺ DB Rechner selektiert aus 1 TB Daten die entsprechenden 1000 Kunden Namen ❹ I/O Ausführung: 1 TB Daten wird an den Server geschickt Mit traditionellem Disksystem kann die Intelligenz der Datenbank nur auf dem Server genutzt werden Ein Großteil der gelesenen Daten wird von der Datenbank nicht genutzt Die nicht genutzten Daten verbrauchen Ressourcen und beeinträchtigen so die Performance anderer Abfragen DOAG SIG Database, Köln, 18. Juni

35 Exadata Smart Scan Abfrage ❶ SELECT customer_name FROM orders WHERE amount > 200; ❻ Ergebnis wird gesendet Nur die relevanten Spalte customer_name und benötigten Zeilen where amount > 200 werden zurückgeliefert ❷ Smart Scan ausgewählt und an Zellen geschickt ❸ Smart Scan selektiert Zeilen und Spalten aus der TB Tabelle gemäß Query ❺ Zusammenfassung aller Ergebnisse der Zellen ❹ Ergebnis (2MB) wird an die Datenbank gesendet CPU-Last für die Auswertung der Prädikate wird ausgelagert Auslagerung des Datenscans setzt CPU-Ressourcen auf dem Host frei und vermeidet einen Großteil des unproduktiven Kommunikationsaufwandes DOAG SIG Database, Köln, 18. Juni

36 Smart Scan Funktionsweise Exadata Zelle erhält Prädikate und Block-Ids zur Auswertung und liefert gefilterte Ergebnisse Exadata Zelle kennt die Blockstruktur und kann so die Zeilen auswerten: Auswertung Prädikate Auswahl Spalten Join Filter mit Bloom-Filter Komprimierung (ausblenden ungenutzter Blöcke) Smart Scan arbeitet auf komprimierten und unkomprimierten Blöcken Ergebnis wird komprimiert geliefert DOAG SIG Database, Köln, 18. Juni

37 Smart Scan Voraussetzungen I Anlegen der Disk Groups mit den folgenden Attributen: CREATE diskgroup datafile normal redundancy disk 'o/ ; ; ; :46342/ datafile0' name DATAFILE_0000, 'o/ ; ; ; :46342/ datafile1' name DATAFILE_0001, attribute 'compatible.asm' = ' ', 'compatible.rdbms' = ' ', 'cell.smart_scan_capable' = 'true' Das Attribut cell.smart_scan_enable gilt für alle Smart I/O Operationen! DOAG SIG Database, Köln, 18. Juni

38 Smart Scan Voraussetzungen II Init.ora Parameter cell_offload_processing=true gesetzt Alle Datenbankdateien eines Tablespace liegen auf Exadata Storage (bei Database Machine automatisch der Fall) Besonderheiten für partitionierte Tabellen: Partition liegt in TS, der Datenbankdateien auf non-exadata Storage -> kein Offloading für den Scan dieser Partition Andere Partitionen, deren TS komplett auf Exadata Storage liegt -> Offloading möglich DOAG SIG Database, Köln, 18. Juni

39 Smart Scan Was wird verlagert? Vollständige Queries mit Auswertung Prädikate Auswahl Spalten Join Filter mit Bloom-Filter Komprimierung (ausblenden ungenutzter Blöcke) Sub- und Inline-Queries Kein Offload für Query-Fragmente, aber Möglicher Offload für jeden Scan innerhalb eines Ausführungsplans Analyse: Wo ist Offload möglich und wo nicht? Verwendung von Explain Plan! (Beispiele später) DOAG SIG Database, Köln, 18. Juni

40 Smart Scan Ablauf Optimizer bewertet Smart Scan derzeit nicht Offloading wird zur Laufzeit entschieden: Verwendung Table Scan oder Index Fast Full Scan ohne Berücksichtigung Exadata Direct Read möglich? Abhängig von unterschiedlichen Heuristiken (Tabellengröße, Dirty Buffers, Daten im Cache, ) Verhalten wie ohne Exadata! Benutzung Smart Scan Wenn der betroffene Storage (für die zu scannenden Partitionen) auf Exadata liegt DOAG SIG Database, Köln, 18. Juni

41 Smart Scan Verwendung direct reads Direct reads sind bekannt aus der Datenbank und nicht Exadataspezifisch Direct reads transportieren die Daten direkt in die PGA, nicht in die SGA (buffer cache) Direct reads sind sinnvoll, wenn die Cachegröße im Vergleich zur Datenmenge, die gelesen werden muss, sehr klein ist. Bei kleinem Cache altern die Blöcke bei großen Leseoperationen möglicherweise schnell aus und verursachen auf diese Weise OLTP-ähnliche Last. Exadata in DWH Umgebungen bedingt das Lesen großer Datenmengen, daher werden direct reads präferiert DOAG SIG Database, Köln, 18. Juni

42 Smart Scan Analyse mit Explain Plan Smart Scan kann analysiert werden durch das Kommando Explain Plan: Offload FTS : TABLE ACCESS STORAGE FULL anstelle TABLE ACCESS FULL ohne Offload Offload btree-index FFS: INDEX STORAGE FAST FULL SCAN anstelle INDEX FAST FULL SCAN ohne Offload Offload Bitmap-Index FFS: BITMAP INDEX STORAGE FAST FULL SCAN anstelle BITMAP INDEX FAST FULL SCAN ohne Offload Offload von Prädikaten: STORAGE Clause in der Prädikatsanzeige unterhalb des Ausführungsbaumes DOAG SIG Database, Köln, 18. Juni

43 Smart Scan Analyse mit Explain Plan Steuerung mit init.ora Parameter cell_offload_plan_display: AUTO Explain Plan zeigt Offload an, wenn wenigstens eine Partition der Tabelle auf Exadata Storage liegt ALWAYS Explain Plan zeigt unabhängig vom Speicherort Offload an. NEVER Explain Plan zeigt keinen Offload an (für interne Zwecke) Verwendung von Explain Plan zur Analyse des Offloads ist möglich, auch wenn kein Exadata Storage eingesetzt wird DOAG SIG Database, Köln, 18. Juni

44 Step-by-step Exadata case-study (1) Tabelle auf Exadata Storage Größe 10 GB Anzahl der Zeilen: 10 Mio Tabellendetails: Name Type A NUMBER(38) C CHAR(255) D CHAR(255) E CHAR(255) F CHAR(255) DOAG SIG Database, Köln, 18. Juni

45 Step-by-step Exadata case-study (2) Full scan select /*+ FULL(test) parallel(test, 8) */ count(*) from test; Smart Scan ausgeschaltet alter session set cell_offload_processing=false; Execution Plan Operation Name Rows SELECT STATEMENT 1 SORT AGGREGATE 1 PX COORDINATOR PX SEND QC (RANDOM) :TQ SORT AGGREGATE 1 PX BLOCK ITERATOR 10M TABLE ACCESS STORAGE FULL TEST 10M DOAG SIG Database, Köln, 18. Juni

46 Step-by-step Exadata case-study (3) Full scan select /*+ FULL(test) parallel(test, 8) */ count(*) from test; Smart Scan eingeschaltet alter session set cell_offload_processing=true; Execution Plan Operation Name Rows SELECT STATEMENT 1 SORT AGGREGATE 1 PX COORDINATOR PX SEND QC (RANDOM) :TQ SORT AGGREGATE 1 PX BLOCK ITERATOR 10M TABLE ACCESS STORAGE FULL TEST 10M Smart Scan nutzt impliziten Filter auf einer Spalte bevor die Daten zum RDBMS transferiert werden 0 no SmartScan Smart Scan DOAG SIG Database, Köln, 18. Juni

47 Step-by-step Exadata case-study (4) Full scan mit Filter select /*+ FULL(test) parallel(test, 8) */ count(*) from test where a=1; Smart Scan eingeschaltet alter session set cell_offload_processing=true; Execution Plan Operation Name Rows SELECT STATEMENT 1 SORT AGGREGATE 1 PX COORDINATOR PX SEND QC (RANDOM) :TQ SORT AGGREGATE 1 PX BLOCK ITERATOR 10 TABLE ACCESS STORAGE FULL TEST Predicate Information (identified by operation id): storage("a"=1) filter("a"=1) no SmartScan Smart Scan Smart Scan + Filter DOAG SIG Database, Köln, 18. Juni

48 Step-by-step Exadata case-study (5) Full scan mit Filter und Spaltenprojektion select /*+ FULL(test) parallel(test, 8) */ count(a) from test where a=1; Smart Scan eingeschaltet alter session set cell_offload_processing=true; Execution Plan Operation Name Rows SELECT STATEMENT 1 SORT AGGREGATE 1 PX COORDINATOR PX SEND QC (RANDOM) :TQ SORT AGGREGATE 1 PX BLOCK ITERATOR 10 TABLE ACCESS STORAGE FULL TEST Predicate Information (identified by operation id): storage("a"=1) filter("a"=1) 0 no SmartScan Smart Scan Smart Scan + Filter Smart Scan + Filter + Proj DOAG SIG Database, Köln, 18. Juni

49 Smart Scan Analyse Erweiterungen v$sql IO_DISK_BYTES gesamter I/O auf physischen Platten IO_INTERCONNECT_BYTES I/O über Interconnect IO_CELL_OFFLOAD_ELIGIBLE_BYTES I/O mit Offload Beispiel: SQL> SELECT sql_text, IO_CELL_OFFLOAD_ELIGIBLE_BYTES/ CELL_OFFLOAD_ELIGIBLE_MB, IO_INTERCONNECT_BYTES/ IO_INTERCONNECT_MB, IO_DISK_BYTES/ IO_DISK_MB FROM V$SQL WHERE SQL_TEXT LIKE 'select%sales%'; SQL_TEXT CELL_OFFLOAD_ELIGIBLE_MB IO_INTERCONNECT_MB IO_DISK_MB select sum(numords) from sales where custid between and DOAG SIG Database, Köln, 18. Juni

50 Smart Scan Analyse Erweiterungen v$sysstat Beispiel: SQL> SELECT name, value / (1024*1024) MB FROM V$SYSSTAT WHERE name='physical IO disk bytes' OR name='cell physical IO interconnect bytes' OR name='cell physical IO bytes eligible for predicate offload' OR name='cell physical IO bytes saved during optimized file creation' OR name='cell physical IO bytes saved during optimized rman file restore'; NAME MB physical IO disk bytes cell physical IO interconnect bytes cell physical IO bytes saved during optimized file creation 0 cell physical IO bytes eligible for predicate offload cell physical IO bytes saved during optimized RMAN file restore 0 Effizienz der Zelle berechnet sich nach folgender Formel: (cell physical IO interconnect bytes (physical IO disk bytes - cell physical IO bytes eligible for predicate offload)) cell physical IO bytes eligible for predicate offload DOAG SIG Database, Köln, 18. Juni

51 Smart Scan Was geht nicht? Aggregationen (z. B. sum, avg, ) werden zur Zeit auf dem Datenbankknoten berechnet Kein Offload für Index Range Scans, nur für Fast Full Scans Range Scans benötigen die Rückgabemenge sortiert das kollidiert mit dem Ansatz der Parallelität Exadata bietet massive Parallelität. Index Range Scans können den Vorteil der massiven Parallelität nicht nutzen Kein Offload bei Verschlüsselung (TDE, TSE) Kein Offload bei Spatial-Operationen Kein Offload bei Abfrage von LONG/LOB Columns Kein Offload bei Zugriff auf OLAP Materialized Views beim Aufbau/Aktualisierung dieser MAVs kann jedoch Offload jedoch große Vorteile bringen! DOAG SIG Database, Köln, 18. Juni

52 Agenda Exadata Motivation und Einführung Smart I/O Überblick Smart Scan Funktionsweise Exadata Komponenten im RDBMS Exadata Komponenten im Storage Server Steuerung und Überwachung <Insert Picture Here> DOAG SIG Database, Köln, 18. Juni

53 RDBMS - Erweiterung I/O Stack Database Server RDBMS/ASM instance SGA dskm IO Client IO Layer ASM layer libcell diskmon /etc/oracle/cell/network-config Cells cellip.ora Local IP cellinit.ora DOAG SIG Database, Köln, 18. Juni

54 Exadata im RDBMS Erweiterung der I/O-Funktionalität Bisher: I/O Layer und ASM zur Durchführung von Block I/O Jetzt zusätzliche Bibliothek libcell: Unterstützung Block I/O und Smart I/O Erweiterte Funktionen, z. B. Netzwerküberwachung, File Staleness Unterstützung ASM Discovery Erweiterung I/O Requests um Metadaten (z. B. Client ID, Session information,...) für IORM und Statistiken Fencing Informationen für jedes offene Device DOAG SIG Database, Köln, 18. Juni

55 Exadata im RDBMS Erweiterung der I/O-Funktionalität spezielle Funktionen Unterstützung Exadata Sicherheitsfeatures Open Security ASM-scoped Security Database-scoped Security Fehlerbehandlung bei Zellenausfall Eingebunden in Diagnosefunktionalitäten Übertragung Netzwerk- und Zellenstatus Benutzt bekannte Systemaufrufe (RAC Interconnect: skgxp) DOAG SIG Database, Köln, 18. Juni

56 RDBMS Disk Monitoring Database Server RDBMS/ASM instance SGA dskm IO Client IO Layer ASM layer libcell diskmon /etc/oracle/cell/network-config Cells cellip.ora Local IP cellinit.ora DOAG SIG Database, Köln, 18. Juni

57 Exadata im RDBMS Erweiterung der I/O-Funktionalität DISKMON Disk Monitoring: diskmon Master Diskmonitor (Knotenweit) Wird mit CRS gestartet Kommunikation zwischen Zelle und Datenbankknoten Kommunikation zwischen diskmon-prozessen mittels CSSD und skgxp dskm Slave Diskmonitor (Instanzweit) normaler Oracle Background Prozeß Kommunikation mit Master Diskmonitor DOAG SIG Database, Köln, 18. Juni

58 Exadata im RDBMS DISKMON - Funktionalität Das Zusammenspiel von (Master-) diskmon und (Slave-) dskm ermöglicht folgende Funktionalitäten: Überwachung Exadata Zellen und Netzwerk (Heartbeat) Übermittlung Zellen-/Netzwerkstatus an ASM/RDBMS-Prozesse Cluster-weite Übersicht von Exadata Zellen mit DISKMONs Empfang von fencing Requests aus dem CRS und Weitergabe an Exadata Zellen Empfang von intradatabase IORM Plänen aus RDBMS und Verteilung an die Exadata Zellen DOAG SIG Database, Köln, 18. Juni

59 ASM-Unterstützung für Exadata ASM unterstützt Exadata: Discovery und Zugriff auf Exadata Disks Unterstützung von neuen Attributen für Diskgroups auf Exadata Storage (smart_scan_capable) Umsetzung logische/physische Speicherung Unterstützung I/O Fencing für I/O Operationen auf Exadata Verbesserung von Algorithmen für NORMAL Redundancy DOAG SIG Database, Köln, 18. Juni

60 RDBMS - Konfigurationsdateien Database Server RDBMS/ASM instance SGA dskm IO Client IO Layer ASM layer libcell diskmon /etc/oracle/cell/network-config Cells cellip.ora Local IP cellinit.ora DOAG SIG Database, Köln, 18. Juni

61 Exadata im RDBMS Konfigurationsdateien cellinit.ora Konfiguration Netzwerk-Interface auf Datenbankknoten Wird durch RDBMS, ASM und Überwachungs-Tools verwendet ipaddress1= /24 cellip.ora Liste aller verfügbaren Exadata Zellen Identisch auf allen Knoten im ASM Cluster Dynamisches Hinzufügen möglich cell=" " cell=" " cell=" " DOAG SIG Database, Köln, 18. Juni

62 Agenda Exadata Motivation und Einführung Smart I/O Überblick Smart Scan Funktionsweise Exadata Komponenten im RDBMS Exadata Komponenten im Storage Server Steuerung und Überwachung <Insert Picture Here> DOAG SIG Database, Köln, 18. Juni

63 Exadata Storage Server Überblick Exadata Storage Server Database Server Meta data Data Meta data Data Meta data Data RDBMS/ASM instance SGA dskm cellsrv ms rs cellcli adrci ADR IO Client IO Layer ASM layer libcell diskmon /etc/oracle/cell/network-config Cells cellip.ora Local IP cellinit.ora Infiniband Fabric DOAG SIG Database, Köln, 18. Juni

64 Exadata Prozesse im Storage Server Zentrale Komponente: cellsrv Zusätzliche Prozesse: ms Management Server rs Restart Server Administration / Diagnose: cellcli Command Line Interface dcli Distributed Command Line Interface adrci Automatic Diagnostic Repository CI OEM Plugin DOAG SIG Database, Köln, 18. Juni

65 cellsrv Exadata Storage Server Database Server Meta data Data Meta data Data Meta data Data RDBMS/ASM instance SGA dskm cellsrv ms rs cellcli adrci ADR IO Client IO Layer ASM layer libcell diskmon /etc/oracle/cell/network-config Cells cellip.ora Local IP cellinit.ora Infiniband Fabric DOAG SIG Database, Köln, 18. Juni

66 cellsrv Funktionalität Multi-Threaded Server Background Tasks User Tasks Discovery von Disks Diagnosefunktionen und Trace-/Incident-Aufzeichnung Unterstützung Exadata Security Key auf Zelle abgelegt Access-List aller Datenbank-/ASM-Cluster Zugriffsprüfung für alle Requests aus RDBMS/ASM DOAG SIG Database, Köln, 18. Juni

67 cellsrv Block I/O und Smart I/O Block I/O Berücksichtigung IORM HARD Checks bei Writes zum Schutz vor Datenkorruption Kommunikation mit libcell Smart I/O Ermittlung ASM-Extents auf RDBMS-Seite Metadaten (Prädikate, Ausdrücke) Lesen von ASM-Extents (Allocation Unit = 4MB) Scheduling 1MB Lesoperationen Filterung/Projektion der Teilergebnisse Rückgabe der gefilterten Daten an RDBMS DOAG SIG Database, Köln, 18. Juni

68 cellsrv I/O Fencing Vermeidung von Datenkorruption durch dead writes von toten Prozesse toten Knoten toten Datenbanken toten Cluster cellsrv kennt aufrufenden Prozeß Benachrichtigung von Master Diskmon durch CSS bzw. RDBMS (ASM) und Weitergabe an cellsrv cellsrv wartet auf Beendigung I/O cellsrv beendet alle open-requests der toten Entität Benachrichtigung Master Diskmon Benachrichtigung von CSS, RDBMS oder ASM durch Master Diskmon DOAG SIG Database, Köln, 18. Juni

69 ms Management Server Exadata Storage Server Database Server Meta data Data Meta data Data Meta data Data RDBMS/ASM instance SGA dskm cellsrv ms rs cellcli adrci ADR IO Client IO Layer ASM layer libcell diskmon /etc/oracle/cell/network-config Cells cellip.ora Local IP cellinit.ora Infiniband Fabric DOAG SIG Database, Köln, 18. Juni

70 ms Management Server Funktionalität OC4J Anwendung Web-Service für Administration der Exadata Zelle Ausführung von Monitoring Threads im Hintergrund Im Detail: Alert-Log, Senden SNMP- oder -Nachrichten Sammlung von Zellen- und IORM-Metriken Überwachung Hardware Historisierung von Metriken und Bereinigung (Metriken und ADR) SMTP Benachrichtigung DOAG SIG Database, Köln, 18. Juni

71 ms Management Server Verwaltete Objekte CELL CELLDISK GRIDDISK LUN PHYSICALDISK IORMPLAN METRICDEFINITION ALERTDEFINITION METRICCURRENT METRICHISTORY ALERTHISTORY THRESHOLD KEY DOAG SIG Database, Köln, 18. Juni

72 ms Management Server Objektattribute Jedes verwaltete Objekt hat Attribute Beschreibung mittels describe CellCLI> describe griddisk name modifiable availableto modifiable celldisk comment modifiable creationtime errorcount id offset size modifiable status DOAG SIG Database, Köln, 18. Juni

73 ms Management Server Persistenz $OSSCONF/cell_disk_config.xml Konfiguration aller Objekte (außer Metriken und Alerts) $OSSCONF/cellinit.ora Konfiguration für cellsrv und rs $OSSCONF/alerts.xml Sammlung Alerts $OSSCONF/metrics*.xml Stündliche Sammlung Metriken Files nicht manuell modifizieren! DOAG SIG Database, Köln, 18. Juni

74 ms Management Server Logging OC4J Logging (Umleitung stdout, stderr), bevor eigentliches Log geschrieben wird in: $LOG_HOME/ms.lst $LOG_HOME/ms.err Directory $ADR_BASE/diag/asm/cell/<hostname>/trace/ Protokolldateien ms-odl.trc und ms-odl.log Meldungen oberhalb eingestellter Tracelevel Maximale Größe 5MB Maximale Anzahl 10 Files ~]# cd $ADR_BASE/diag/asm/cell/cell1/trace trace]# ls -lrt ms*.* -rw-r--r-- 1 root root Jun 14 08:00 ms-odl.trc -rw-r--r-- 1 root root Jun 14 08:00 ms-odl.log [root@cell1 trace]# DOAG SIG Database, Köln, 18. Juni

75 rs Restart Server Exadata Storage Server Database Server Meta data Data Meta data Data Meta data Data RDBMS/ASM instance SGA dskm cellsrv ms rs cellcli adrci ADR IO Client IO Layer ASM layer libcell diskmon /etc/oracle/cell/network-config Cells cellip.ora Local IP cellinit.ora Infiniband Fabric DOAG SIG Database, Köln, 18. Juni

76 rs Restart Server Funktionalität Eigentlich zwei Prozesse core rs backup rs (Erhöhung Ausfallsicherheit, überwacht core rs) Im Detail: Wird durch CLI angesteuert (alter cell startup services rs) Führt CLI Kommandos aus: startup/shutdown cellsrv, ms Überwacht Management Server (ms und cellsrv) Heartbeat Automatischer Neustart im Fehlerfall / ausbleibender Heartbeat Erstellen Incidents Überprüfung Status über CLI (list cell detail) DOAG SIG Database, Köln, 18. Juni

77 rs Restart Server Funktionalität trace]# cellcli list CellCLI: Release Production on Sun Jun 14 08:45:46 PDT 2009 Copyright (c) 2007, 2008, Oracle. All rights reserved. Cell Efficiency Ratio: 4,910.1 CellCLI> list cell detail name: cell1 bmcconfigured: FALSE bmctype: absent cellversion: OSS_ _LINUX_ cpucount: 1 fancount: 1/1 fanstatus: normal id: "PA5360ABFSPUMD... metrichistorydays: 7 offloadefficiency: 4,910.1 powercount: 1/1 powerstatus: normal status: online temperaturereading: 0.0 temperaturestatus: normal uptime: 0 days, 1:24 cellsrvstatus: running msstatus: running rsstatus: running CellCLI> DOAG SIG Database, Köln, 18. Juni

78 rs Restart Server Zusammenspiel der Komponenten ~]# ps -efa grep oracle root :40? 00:00:00 /opt/oracle/cell/cellsrv/bin/cellrssrm -ms 1 -cellsrv 1 root :40? 00:00:01 /opt/oracle/cell/cellsrv/bin/cellrsomt -ms 1 -cellsrv 1 root :40? 00:00:00 /opt/oracle/cell/cellsrv/bin/cellrsmmt -ms 1 -cellsrv 1 root :40? 00:00:00 /opt/oracle/cell/cellsrv/bin/cellrsbmt -ms 1 -cellsrv 1 root :40? 00:00:00 /opt/oracle/cell/cellsrv/bin/cellrsbkm -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsms.state - cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsos.state -debug 0 root :40? 00:00:30 /usr/java/jdk1.5.0_12//bin/java -Xms256m -Xmx512m - Djava.library.path=/opt/oracle/cell/cellsrv/lib -Ddisable.checkForUpdate=true -jar /opt/oracle/cell/oc4j/ms/j2ee/home/oc4j.jar -out /opt/oracle/cell/cellsrv/deploy/log/ms.lst -err /opt/oracle/cell/cellsrv/deploy/log/ms.err root :40? 00:01:51 /opt/oracle/cell/cellsrv/bin/cellsrv root :40? 00:00:00 /opt/oracle/cell/cellsrv/bin/cellrssmt -rs_conf /opt/oracle/cell/cellsrv/deploy/config/cellinit.ora -ms_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsms.state - cellsrv_conf /opt/oracle/cell/cellsrv/deploy/config/cellrsos.state -debug 0 root :51 pts/0 00:00:00 grep oracle [root@cell1 ~]# cellrssrm Server main (core rs) cellrsbkm Backup main Monitoring Prozesse: cellrssmt Server Monitoring Prozess cellrsbmt Backup Monitoring Prozess cellrsomt oss (alter Name von cellsrv) Monitoring Prozess cellrsmmt ms Monitoring Prozess DOAG SIG Database, Köln, 18. Juni

79 rs Restart Server Logging Directory $ADR_BASE/diag/asm/cell/<hostname>/trace/ Gemeinsames alert.log für cellsrv und rs Weitere Traces: cellrsomt - rstrc_<core-rs-pid>_4.trc (aus cellsrv) cellrsmmt - rstrc_<core-rs-pid>_5.trc (aus ms) DOAG SIG Database, Köln, 18. Juni

80 cellcli Command Line Interface Exadata Storage Server Database Server Meta data Data Meta data Data Meta data Data RDBMS/ASM instance SGA dskm cellsrv ms rs cellcli adrci ADR IO Client IO Layer ASM layer libcell diskmon /etc/oracle/cell/network-config Cells cellip.ora Local IP cellinit.ora Infiniband Fabric DOAG SIG Database, Köln, 18. Juni

81 cellcli Command Line Interface Steuerung Exadata JAVA Client Programm zur Steuerung Exadata Zelle Anweisungen für ms, rs, ORION Funktionalitäten von SQL*plus: start, spool, Kommandos help, describe, set, spool, start: interpretiert von CellCLI alter cell startup/shutdown services steuert rs calibrate steuert ORION Alle anderen Kommandos steuert ms Optionen -e Ansteuerung cellcli direkt aus der Shell heraus -n Unterdrückung Prompt DOAG SIG Database, Köln, 18. Juni

82 cellcli Command Line Interface Logging Directory $LOG_HOME (/opt/oracle/cell/cellsrv/deploy/log) Log-File cellcli.lst Maximale Größe 500K Automatische Umbenennen (Ergänzung numerisches Suffix) DOAG SIG Database, Köln, 18. Juni

83 Agenda Exadata Motivation und Einführung Smart I/O Überblick Smart Scan Funktionsweise Exadata Komponenten im RDBMS Exadata Komponenten im Storage Server Steuerung und Überwachung <Insert Picture Here> DOAG SIG Database, Köln, 18. Juni

84 Exadata Monitoring - RDBMS Nutzung von v$-views v$cell und gv$cell Identifizierung der Exadata Zelle v$backup_datafile Analyse Effizienz Smart I/O bei RMAN Backup v$cell_request_totals Anzahl von cell requests v$sysstat and v$sql Effizienz Smart Scan Statistiken für Anlegen TS und RMAN v$cell_state, v$cell_thread_history Verwendet von Oracle Customer Support DOAG SIG Database, Köln, 18. Juni

85 Exadata Monitoring - RDBMS Analyse Wait-Events SELECT w.event, c.cell_path, d.name, w.p3 FROM V$SESSION_WAIT w, V$EVENT_NAME e, V$ASM_DISK d, V$CELL c WHERE e.name LIKE 'cell%' AND e.wait_class_id = w.wait_class_id AND w.p1 = c.cell_hashval AND w.p2 = d.hash_value; Wait Event cell single block physical read cell multiblock physical read cell smart table scan cell smart index scan cell smart file creation cell smart incremental backup cell smart restore from backup cell statistics gather Description Same as db file sequential read for a cell Same as db file scattered read for a cell DB waiting for table scans to complete DB waiting for index or IOT fast full scans waiting for file creation completion waiting for incremental backup completion waiting for file initialization completion for restore DOAG SIG Database, Köln, 18. Juni

86 Exadata Monitoring Storage Server cellcli Nutzung cellcli log]# cellcli CellCLI: Release Production on Sun Jun 14 09:51:12 PDT 2009 Copyright (c) 2007, 2008, Oracle. All rights reserved. Cell Efficiency Ratio: 4,910.1 CellCLI> list alerthistory Nutzung adrci [root@cell1 log]# adrci ADRCI: Release Production on Sun Jun 14 10:02: Copyright (c) 1982, 2007, Oracle. All rights reserved. ADR base = "/opt/oracle/cell/log" adrci> show problem ADR Home = /opt/oracle/cell/log/diag/asm/cell/cell1: ************************************************************************* PROBLEM_ID PROBLEM_KEY LAST_INCIDENT LASTINC_TIME ORA :23: :00 1 RS :20: :00 2 rows fetched adrci> DOAG SIG Database, Köln, 18. Juni

87 Exadata Monitoring Storage Server Log-Verzeichnisse Directory $ADR_BASE/diag/asm/cell/<hostname>/trace/ Alert Log für cellsrv, rs ms Directory $LOG_HOME (/opt/oracle/cell/cellsrv/deploy/log) Eigentlich nur Prozessinformation cellsrv cellcli DOAG SIG Database, Köln, 18. Juni

88 Exadata Monitoring OEM Plugin Analyse Konfiguration Exadata Cells Celldisks Griddisks LUNs Disks IORM Konfiguration Alerts Exadata Alerts OEM-generierte Alerts basierend auf Schwellwerten (Thresholds) Performance-Monitoring DOAG SIG Database, Köln, 18. Juni

89 Fragen & Antworten DOAG SIG Database, Köln, 18. Juni

90 DOAG SIG Database, Köln, Juni

91 DOAG SIG Database, Köln, Juni

92 Unused slides DOAG SIG Database, Köln, 18. Juni

93 Oracle Exadata Analystenmeinung...major advantages in storage bandwidth and system efficiency......oracle tools...successfully integrate the intelligence in Exadata storage with the existing performance capabilities of Oracle. Significantly, the Exadata storage server provides a much higher ratio of bandwidth to storage capacity than is economically available in enterprise class storage arrays....the benefit from these operations would yield factors of 10, 100 or more... In the opinion of WinterCorp, Oracle data warehouse users can expect to see dramatic gains from the Oracle Exadata product family, combined with benefits in integration, storage management, economy and modular scalability. In addition, many customers will be attracted by the advantages in space, power and cooling offered by these products. Therefore, WinterCorp recommends that Oracle data warehouse users consider the Oracle Exadata Storage Server whenever they evaluate how to better address service level objectives, whether for the current or new data warehouse requirements. Source: Measuring the Performance of the Oracle Exadata Storage Server, Winter Corporation, Waltham MA, 2009 DOAG SIG Database, Köln, 18. Juni

94 Explain Plan Beispiel: full table scan Kein Exadata Id Operation Name SELECT STATEMENT * 1 HASH JOIN * 2 HASH JOIN * 3 TABLE ACCESS FULL SALES * 4 TABLE ACCESS FULL SALES * 5 TABLE ACCESS FULL SALES Predicate Information (identified by operation id): access("t"."cust_id"="t2"."cust_id" AND "T1"."PROD_ID"="T2"."PROD_ID" AND "T1"."CUST_ID"="T2"."CUST_ID") 2 - access("t"."prod_id"="t1"."prod_id") 3 - filter("t1"."prod_id"<200 AND "T1"."AMOUNT_SOLD"*"T1"."QUANTITY_SOLD">10000 AND "T1"."PROD_ID"<>45) 4 - filter("t"."prod_id"<200 AND "T"."PROD_ID"<>45) 5 - filter("t2"."prod_id"<200 AND "T2"."PROD_ID"<>45) DOAG SIG Database, Köln, 18. Juni

95 Explain Plan Beispiel: full table scan Exadata Id Operation Name SELECT STATEMENT * 1 HASH JOIN * 2 HASH JOIN * 3 TABLE ACCESS STORAGE FULL SALES * 4 TABLE ACCESS STORAGE FULL SALES * 5 TABLE ACCESS STORAGE FULL SALES Predicate Information (identified by operation id): access("t"."cust_id"="t2"."cust_id" AND "T1"."PROD_ID"="T2"."PROD_ID" AND "T1"."CUST_ID"="T2"."CUST_ID") 2 - access("t"."prod_id"="t1"."prod_id") 3 - storage("t1"."prod_id"<200 AND "T1"."AMOUNT_SOLD"*"T1"."QUANTITY_SOLD">10000 AND "T1"."PROD_ID"<>45) filter("t1"."prod_id"<200 AND "T1"."AMOUNT_SOLD"*"T1"."QUANTITY_SOLD">10000 AND "T1"."PROD_ID"<>45) 4 - storage("t"."prod_id"<200 AND "T"."PROD_ID"<>45) filter("t"."prod_id"<200 AND "T"."PROD_ID"<>45) 5 - storage("t2"."prod_id"<200 AND "T2"."PROD_ID"<>45) filter("t2"."prod_id"<200 AND "T2"."PROD_ID"<>45) DOAG SIG Database, Köln, 18. Juni

96 Explain Plan Beispiel: btree index fast full scan Kein Exadata Id Operation Name SELECT STATEMENT 1 SORT AGGREGATE * 2 INDEX FAST FULL SCAN INDEX Predicate Information (identified by operation id): filter("p1"=10) DOAG SIG Database, Köln, 18. Juni

97 Explain Plan Beispiel: btree index fast full scan Exadata Id Operation Name SELECT STATEMENT 1 SORT AGGREGATE * 2 INDEX STORAGE FAST FULL SCAN INDEX Predicate Information (identified by operation id): storage("p1"=10) filter("p1"=10) DOAG SIG Database, Köln, 18. Juni

98 Explain Plan Beispiel: bitmap index fast full scan Kein Exadata Id Operation Name SELECT STATEMENT 1 SORT AGGREGATE 2 BITMAP CONVERSION COUNT * 3 BITMAP INDEX FAST FULL SCAN INDEX Predicate Information (identified by operation id): filter("p1"=10) DOAG SIG Database, Köln, 18. Juni

99 Explain Plan Beispiel: bitmap index fast full scan Exadata Id Operation Name SELECT STATEMENT 1 SORT AGGREGATE 2 BITMAP CONVERSION COUNT * 3 BITMAP INDEX STORAGE FAST FULL SCAN INDEX Predicate Information (identified by operation id): storage("p1"=10) filter("p1"=10) DOAG SIG Database, Köln, 18. Juni

100 Explain Plan Beispiel: bloom filter Kein Exadata Id Operation Name SELECT STATEMENT 1 SORT AGGREGATE 2 PX COORDINATOR 3 PX SEND QC (RANDOM) :TQ SORT AGGREGATE * 5 HASH JOIN 6 JOIN FILTER CREATE :BF PX RECEIVE 8 PX SEND HASH :TQ PX BLOCK ITERATOR 10 TABLE ACCESS FULL EMPLOYEE 11 PX RECEIVE 12 PX SEND HASH :TQ JOIN FILTER USE :BF PX BLOCK ITERATOR * 15 TABLE ACCESS FULL DEPT Predicate Information (identified by operation id): access("e"."dept_id"="d"."dept_id") 15 - filter(sys_op_bloom_filter(:bf0000,"d"."dept_id")) DOAG SIG Database, Köln, 18. Juni

101 Explain Plan Beispiel: bloom filter Exadata Id Operation Name SELECT STATEMENT 1 SORT AGGREGATE 2 PX COORDINATOR 3 PX SEND QC (RANDOM) :TQ SORT AGGREGATE * 5 HASH JOIN 6 JOIN FILTER CREATE :BF PX RECEIVE 8 PX SEND HASH :TQ PX BLOCK ITERATOR 10 TABLE ACCESS STORAGE FULL EMPLOYEE 11 PX RECEIVE 12 PX SEND HASH :TQ JOIN FILTER USE :BF PX BLOCK ITERATOR * 15 TABLE ACCESS STORAGE FULL DEPT Predicate Information (identified by operation id): access("e"."dept_id"="d"."dept_id") 15 - storage(sys_op_bloom_filter(:bf0000,"d"."dept_id")) filter(sys_op_bloom_filter(:bf0000,"d"."dept_id")) DOAG SIG Database, Köln, 18. Juni

102 Explain Plan Beispiel: keine Prädikate Exadata Id Operation Name SELECT STATEMENT 1 SORT AGGREGATE 2 PX COORDINATOR 3 PX SEND QC (RANDOM) :TQ SORT AGGREGATE 5 PX BLOCK ITERATOR 6 TABLE ACCESS STORAGE FULL LINEITEM Was sieht man an diesem Plan? Verwendung Smart I/O anstelle von Block I/O -> Ausnutzung der parallelen Ausführung auf allen Exadata Zellen. Some column projection may be occurring depending on the query. Abhängig vom Füllgrad der Datenbankblöcke wird ungenutzter Speicherplatz durch Smart Scan ignoriert DOAG SIG Database, Köln, 18. Juni

103 ms Management Server Persistenz $OSSCONF/cell_disk_config.xml Konfiguration der Objekte (außer Alerts und Metriken) im XML-Format File wird automatisch mit jedem Kommando gepflegt Auswertung bei Startup bzw. Reinstantiierung oder Äbnderungen (z. B. Zellenname, IORM Plan) Anlegen Backup (cell_disk_config.xml_ ) zur Vermeidung von Korruption Nicht manuell modifizieren! [root@cell1 config]# cat $OSSCONF/cell_disk_config.xml <?xml version="1.0" encoding="utf-8"?> <Targets> <Target TYPE="oracle.ossmgmt.ms.core.MSCell" NAME="cell1"> <Attribute NAME="interconnect1" VALUE="eth0"></Attribute> <Attribute NAME="metricHistoryDays" VALUE="7"></Attribute> <Attribute NAME="bmcConfigured" VALUE="FALSE"></Attribute> <Attribute NAME="OEHistory" VALUE=" "></Attribute> <Attribute NAME="iormBoost" VALUE="0.0"></Attribute> <Attribute NAME="offloadEfficiency" VALUE=" "></Attribute> <Attribute NAME="name" VALUE="cell1"></Attribute> </Target> <Target TYPE="oracle.ossmgmt.ms.core.MSIDBPlan" NAME="cell1_IORMPLAN"> <Attribute NAME="status" VALUE="active"></Attribute>... DOAG SIG Database, Köln, 18. Juni

104 ms Management Server Persistenz $OSSCONF/cellinit.ora Konfiguration für cellsrv und rs ms aktualisiert ipaddressn und TRACELEVEL config]# cat $OSSCONF/cellinit.ora #CELL Initialization Parameters #Mon Mar 09 16:01:52 PDT 2009 HTTP_PORT=8888 _cell_disable_ant_check_reid=true SSL_PORT=23943 _cell_num_1mb_buffers=100 RMI_PORT=23791 _reconnect_to_cell_freq_in_sec=4 _skgxp_udp_use_tcb_client=true _skgxp_gen_ant_off_rpc_timeout_in_sec=300 ipaddress1= /24 DEPLOYED=TRUE _reconnect_to_cell_attempts=4 JMS_PORT=9127 BMC_SNMP_PORT=162 _skgxp_udp_use_tcb=false config]# DOAG SIG Database, Köln, 18. Juni