doag sig database, köln, 18. juni 2009doag sig database ... · doag sig database, köln,...
TRANSCRIPT
<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, 18.06.2009
DOAG SIG Database, Köln, 18. Juni 2009 3
<Insert Picture Here>
Agenda
Exadata Motivation und EinführungSmart I/O ÜberblickSmart Scan FunktionsweiseExadata Komponenten im RDBMSExadata Komponenten im Storage ServerSteuerung und Überwachung
DOAG SIG Database, Köln, 18. Juni 2009 4
DWH WachstumDreifaches Volumen in zwei Jahren!
Source: Winter TopTen Survey, Winter Corporation, Waltham MA, 2008.
200
400
600
800
1000
1998 2000 2002 2004 2006 2008 2010 2012
Actual
Projected
Ter
abyt
es o
f Dat
a
Size of the Largest Data Warehouses
DOAG SIG Database, Köln, 18. Juni 2009 5
Data Warehouse Ansätze
• Intelligenz – Nutzung von Smart Database Software, um HWRessourcen zu minimieren�Ausgeklügelte Techniken: Partitionierung,
MOLAP, Bitmap Indexing, Join indexing, Materialized Views, Result Caches
• Stärke - Nutzung von extrem schnellerHW, um Brute Force Scans zu verarbeiten�HW bestimmt Performance
DOAG SIG Database, Köln, 18. Juni 2009 6
Data Warehouse Workloads
• Planbarer User Workload�Optimierbar durch intelligente Software-
Lösungen
• Adhoc Auswertungen großer Datenmengen�Full Table Scans
�Joins großer Datenmengen
�Optimierung nur eingeschränkt möglich!
Database Grid
SAN Switch
LAN Switch
DOAG SIG Database, Köln, 18. Juni 2009 7
Bottlenecks bei großen Auswertungen
• 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 SANsteigen 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
Database Grid
SAN Switch
LAN Switch
DOAG SIG Database, Köln, 18. Juni 2009 8
Einfluß der I/O Bandbreite
• Business Queries wenn 10 TB gelesen werden muss
1 GB/sec 3 Queries / Tag
10 GB/sec3 Queries / Stunde
100 GB/sec35 Queries / Stunde
Frag bloß nicht!
Fragen möglich
Alles fragen
I/O Bandbreite
10 TB
DOAG SIG Database, Köln, 18. Juni 2009 9
• 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
Herausforderung PerformanceEngpaß I/O-Bandbreite & Interconnect
DOAG SIG Database, Köln, 18. Juni 2009 10
Durchsatz Performance (DWH)
Komponente Theorie (Bit/s) maximal Byte/s
CPU 100-200 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
HW Komponenten / Sizing Werte
DOAG SIG Database, Köln, 18. Juni 2009 11
Beispiel "Non well balanced"
FC-Switch1 FC-Switch2
HB
A1
HB
A2
FC-Switch1 FC-Switch2
GroßerSMP Server32 CPUs
6 x 2 Gb HBA
Storage System20 phys. Plattena 146 GB
Max IO Durchsatz: 3,2 GB/sec
Max IO Durchsatz: 840 MB/sec25% Nutzung des Potentials
Max IO Durchsatz: 280 MB/sec8,75% Nutzung des Potentials
DOAG SIG Database, Köln, 18. Juni 2009 12
Was ist ein balanciertes System ?
Referenz Konfiguration
IO Throughput Minimum: 100 MB/sec per Core
Memory Minimum: 4 GB / Core
Ideal: 8 GB / Core
Interconnect Empfohlen: 10G Ethernet (10GBit/sec.), noch besser Infiniband (20 GBit/sec.)
Ziel: CPU, Memory, Netzwerkund I/O auszubalanzieren
IO
InterconnectCPU
Memory
Balanced System
DOAG SIG Database, Köln, 18. Juni 2009 13
Die schwächste Komponente bestimmt den Durchsatz
Relevante Komponenten:• CPUs: Anzahl und Speed • HBAs (Host Bus Adapter):
Anzahl und Speed• Switch: Anzahl und Speed• Controller: Anzahl und Speed• Disk: Anzahl und Speed
FC-Switch1 FC-Switch2
DiskArray 1
DiskArray 2
DiskArray 3
DiskArray 4
DiskArray 5
DiskArray 6
DiskArray 7
DiskArray 8
HB
A1
HB
A2
HB
A1
HB
A2
HB
A1
HB
A2
HB
A1
HB
A2
Jeder Server hat 4 CPUs Alle vier Server erzeugen dann 4 * 150 MB/s * 4 = 2400 MB/s
Jeder Server hat 2 x 4 Git HBAsAlle 8 HBAs können
8 * 300MB/s = 2400 MB/s
Jeder Switch muß 1200 MB/s garantieren für einen Gesamtsystem Durchsatz von 2400 MB/s
8 Disk Arrays a 16 PlattenPro Disk Array 300 MB/sec.
8 * 300MB/s = 2400 MB/s
Das ist ein balanciertes SystemIC-Switch1 IC-Switch2
Performanter Interconnect10GEthernet oder InfinibandJe Port 900 – 1900 MB/sec.
DOAG SIG Database, Köln, 18. Juni 2009 14
CustomCustom
+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
ReferenceConfigurations
ReferenceConfigurations
Optimized WarehouseOptimized Warehouse
+ 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
HP Oracle Database Machine
HP Oracle Database Machine
Verschiedene Lösungsansätze
DOAG SIG Database, Köln, 18. Juni 2009 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 2009 16
Der Oracle AnsatzDB 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 2009 17
• Optimierter Plattenspeicher für Oracle Datenbanken
• Extreme I/O und SQL Performance1 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
HP Oracle Exadata Storage Server
DOAG SIG Database, Köln, 18. Juni 2009 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 2009 19
Database Server Grid8 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
Exadata Storage Server Grid14 Server,14 Server,14 Server,14 Server, bestehend ausbestehend ausbestehend ausbestehend 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
44 InfinibandInfiniband SwitchesSwitchesPro Switch 24 portsPro Switch 24 ports
HP Oracle Database Machine
Liefert Spitzendurchsatz von 14 GB/s !
DOAG SIG Database, Köln, 18. Juni 2009 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 2009 21
HP Oracle Database Machine:System Architektur
InfinibandInfinibandInfinibandInfinibandNetzwerkNetzwerkNetzwerkNetzwerk
Massiv ParallelesMassiv ParallelesMassiv ParallelesMassiv ParallelesI/OI/OI/OI/O----StorageStorageStorageStorage
ClusteredClusteredClusteredClusteredDatenbankDatenbankDatenbankDatenbank ServerServerServerServer
…
Compute Intensive Processing
HP Oracle Database ServerHP Oracle Database ServerHP Oracle Database ServerHP Oracle Database Server
Compute Intensive Processing
HP Oracle Database ServerHP Oracle Database ServerHP Oracle Database ServerHP Oracle Database Server
Compute Intensive Processing
HP Oracle Database ServerHP Oracle Database ServerHP Oracle Database ServerHP Oracle Database Server …
Data Intensive Processing
HP OracleHP OracleHP OracleHP Oracle ExadataExadataExadataExadata Storage ServerStorage ServerStorage ServerStorage Server
Data Intensive Processing
HP OracleHP OracleHP OracleHP Oracle ExadataExadataExadataExadata Storage ServerStorage ServerStorage ServerStorage Server
Data Intensive Processing
HP OracleHP OracleHP OracleHP Oracle ExadataExadataExadataExadata Storage ServerStorage ServerStorage ServerStorage Server1
2
8
1
2
3
14
Data Intensive Processing
HP OracleHP OracleHP OracleHP Oracle ExadataExadataExadataExadata Storage ServerStorage ServerStorage ServerStorage Server
DOAG SIG Database, Köln, 18. Juni 2009 22
Verbesserung I/O-BandbreiteSmart 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 2009 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
Exadata Bandbreite skaliert linear zur Kapazität!
4 GB/sec
8 GB/sec
16 GB/sec
…
DOAG SIG Database, Köln, 18. Juni 2009 24
Exadata Storage GridI/O Resource Management
• Verwaltung shared storage?� Balance DB-User / Storage schwierig
� Maßnahme: Isolierung von Hardware
StorageSwitch/Network
.
DatenbankA
.
DatenbankB
DatenbankC
. . .
• Exadata I/O Resource Management� Gruppen/Klassen Intra-DB� Gruppen/Klassen Inter-DB� Priorisierung� Definition SLAs
DOAG SIG Database, Köln, 18. Juni 2009 25
Exadata verändert die Datenbank Welt
• Exadata vereint Stärke undIntelligenz: "brawny + brainy"
• Extreme HW Performanceermöglicht neue Wege
• Hervorragende Skalierbarkeit
• Nutzung von Standard HW
• Zukunftssicherheit: Nutzung neuester Technologien
• Nahtlose Integration inexistierende IT-Infrastrukturen
DOAG SIG Database, Köln, 18. Juni 2009 26
<Insert Picture Here>
Agenda
Exadata Motivation und EinführungSmart I/O ÜberblickSmart Scan FunktionsweiseExadata Komponenten im RDBMSExadata Komponenten im Storage ServerSteuerung und Überwachung
DOAG SIG Database, Köln, 18. Juni 2009 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 2009 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 vonSummen etc.
DOAG SIG Database, Köln, 18. Juni 2009 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 2009 30
Smart IO – Wie funktioniert das?
• Smart I/O wird nur durch die Kommunikation vonDatenbankknoten und Exadata Zellen ermöglicht
• Datenbankknoten kann für verschiedene Anwendungsfälle Smart I/O nutzen und wählt zwischenSmart I/O und Block I/O
• Datenbankknoten fordert Smart I/O an
• Exadata liefert Smart I/O
DOAG SIG Database, Köln, 18. Juni 2009 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 2009 32
<Insert Picture Here>
Agenda
Exadata Motivation und EinführungSmart I/O ÜberblickSmart Scan FunktionsweiseExadata Komponenten im RDBMSExadata Komponenten im Storage ServerSteuerung und Überwachung
DOAG SIG Database, Köln, 18. Juni 2009 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 2009 34
Herkömmliche Abfrage ohne Exadata
• Mit traditionellem Disksystem kann dieIntelligenz der Datenbank nur auf dem Servergenutzt werden
• Ein Großteil der gelesenen Daten wird von der Datenbank nicht genutzt
• Die nicht genutzten Daten verbrauchen Ressourcenund beeinträchtigen so die Performance anderer Abfragen����
I/O Ausführung:1 TB Daten wird an
den Server geschickt
����
DB Rechner selektiert aus 1 TB Daten die
entsprechenden 1000Kunden Namen
����
Ergebnis wird an den Client gesendet
����
SELECT
customer_name
FROM orders
WHERE amount >
200;
����
Table Extents
identifiziert
����
I/O Abfragen
DOAG SIG Database, Köln, 18. Juni 2009 35
Exadata Smart Scan Abfrage
• Nur die relevanten Spaltecustomer_nameund benötigten Zeilenwhere amount > 200werden zurückgeliefert
• CPU-Last für dieAuswertung der Prädikate wird ausgelagert
• Auslagerung des Datenscans setzt CPU-Ressourcen aufdem Host frei und vermeidet einen Großteil desunproduktiven Kommunikationsaufwandes
����
Ergebnis (2MB) wirdan die Datenbank
gesendet
����
Smart Scanausgewählt und an
Zellen geschickt
����
SELECT
customer_name
FROM orders
WHERE amount >
200;
����
Zusammen-fassung aller Ergebnisse der Zellen
����
Ergebnis wird gesendet
����
Smart Scanselektiert Zeilenund Spalten aus der TB Tabelle gemäß Query
DOAG SIG Database, Köln, 18. Juni 2009 36
Smart ScanFunktionsweise
• Exadata Zelle erhält Prädikate und Block-Ids zur Auswertung und liefert gefilterte Ergebnisse
• Exadata Zelle kennt die Blockstruktur und kann so dieZeilen auswerten:�Auswertung Prädikate
�Auswahl Spalten
�Join Filter mit Bloom-Filter
�Komprimierung (ausblenden ungenutzter Blöcke)
• Smart Scan arbeitet auf komprimierten undunkomprimierten Blöcken�Ergebnis wird komprimiert geliefert
DOAG SIG Database, Köln, 18. Juni 2009 37
Smart ScanVoraussetzungen I
• Anlegen der Disk Groups mit den folgenden Attributen:
CREATE diskgroup datafile normal redundancy disk
'o/140.87.2.120;140.87.2.120;140.87.2.120;140.87.2.120:46342/
datafile0' name DATAFILE_0000,
'o/140.87.2.120;140.87.2.120;140.87.2.120;140.87.2.120:46342/
datafile1' name DATAFILE_0001,
attribute 'compatible.asm' = '11.1.0.7',
'compatible.rdbms' = '11.1.0.7',
'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 2009 38
Smart ScanVoraussetzungen II
• Init.ora Parameter cell_offload_processing=true gesetzt
• Alle Datenbankdateien eines Tablespace liegen aufExadata Storage (bei Database Machine automatisch derFall)
• 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 2009 39
Smart ScanWas 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 2009 40
Smart ScanAblauf
• 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 2009 41
Smart ScanVerwendung direct reads
• Direct reads sind bekannt aus der Datenbank und nicht Exadata-spezifisch
• 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-ähnlicheLast.
• Exadata in DWH Umgebungen bedingt das Lesen großer Datenmengen, daher werden direct reads präferiert
DOAG SIG Database, Köln, 18. Juni 2009 42
Smart ScanAnalyse mit Explain Plan
• Smart Scan kann analysiert werden durch dasKommando 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” ohneOffload
� Offload von Prädikaten: “STORAGE” Clause in der Prädikatsanzeige unterhalb des Ausführungsbaumes
DOAG SIG Database, Köln, 18. Juni 2009 43
Smart ScanAnalyse 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 2009 44
Step-by-step Exadata case-study (1)
Name Type
----------------- ----------------------------
A NUMBER(38)
C CHAR(255)
D CHAR(255)
E CHAR(255)
F CHAR(255)
• Tabelle auf Exadata Storage
• Größe 10 GB
• Anzahl der Zeilen: 10 Mio
• Tabellendetails:
DOAG SIG Database, Köln, 18. Juni 2009 45
Step-by-step Exadata case-study (2)
• Full scanselect /*+ FULL(test) parallel(test, 8) */ count(*) from test;
• Smart Scan ausgeschaltetalter session set cell_offload_processing=false;
• Execution Plan-----------------------------------------------------
| Operation | Name | Rows |
-----------------------------------------------------
| SELECT STATEMENT | | 1 |
| SORT AGGREGATE | | 1 |
| PX COORDINATOR | | |
| PX SEND QC (RANDOM) | :TQ10000 | 1 |
| SORT AGGREGATE | | 1 |
| PX BLOCK ITERATOR | | 10M|
| TABLE ACCESS STORAGE FULL| TEST | 10M|
-----------------------------------------------------
DOAG SIG Database, Köln, 18. Juni 2009 46
Step-by-step Exadata case-study (3)
• Full scanselect /*+ FULL(test) parallel(test, 8) */ count(*) from test;
• Smart Scan eingeschaltetalter session set cell_offload_processing=true;
• Execution Plan-----------------------------------------------------
| Operation | Name | Rows |
-----------------------------------------------------
| SELECT STATEMENT | | 1 |
| SORT AGGREGATE | | 1 |
| PX COORDINATOR | | |
| PX SEND QC (RANDOM) | :TQ10000 | 1 |
| SORT AGGREGATE | | 1 |
| PX BLOCK ITERATOR | | 10M|
| TABLE ACCESS STORAGE FULL| TEST | 10M|
-----------------------------------------------------0
5000
10000
no
SmartScan
Smart Scan• Smart Scan nutzt impliziten Filter auf einer Spalte bevor die Daten zum RDBMS transferiert werden
DOAG SIG Database, Köln, 18. Juni 2009 47
Step-by-step Exadata case-study (4)
• Full scan mit Filterselect /*+ FULL(test) parallel(test, 8) */ count(*) from test
where a=1;
• Smart Scan eingeschaltetalter session set cell_offload_processing=true;
• Execution Plan----------------------------------------------------
| Operation | Name | Rows |
----------------------------------------------------
| SELECT STATEMENT | | 1 |
| SORT AGGREGATE | | 1 |
| PX COORDINATOR | | |
| PX SEND QC (RANDOM) | :TQ10000 | 1 |
| SORT AGGREGATE | | 1 |
| PX BLOCK ITERATOR | | 10 |
| TABLE ACCESS STORAGE FULL| TEST | 10 |
----------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
6 - storage("A"=1)
filter("A"=1)
0
5000
10000
no
SmartScan
Smart Scan Smart Scan
+ Filter
DOAG SIG Database, Köln, 18. Juni 2009 48
Step-by-step Exadata case-study (5)
• Full scan mit Filter und Spaltenprojektionselect /*+ FULL(test) parallel(test, 8) */ count(a) from test
where a=1;
• Smart Scan eingeschaltetalter session set cell_offload_processing=true;
• Execution Plan----------------------------------------------------
| Operation | Name | Rows |
----------------------------------------------------
| SELECT STATEMENT | | 1 |
| SORT AGGREGATE | | 1 |
| PX COORDINATOR | | |
| PX SEND QC (RANDOM) | :TQ10000 | 1 |
| SORT AGGREGATE | | 1 |
| PX BLOCK ITERATOR | | 10 |
| TABLE ACCESS STORAGE FULL| TEST | 10 |
----------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
6 - storage("A"=1)
filter("A"=1)
0
5000
10000
no
SmartScan
Smart Scan Smart Scan
+ Filter
Smart Scan
+ Filter +
Proj
DOAG SIG Database, Köln, 18. Juni 2009 49
Smart Scan AnalyseErweiterungen 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/1048576 CELL_OFFLOAD_ELIGIBLE_MB,
IO_INTERCONNECT_BYTES/1048576 IO_INTERCONNECT_MB,
IO_DISK_BYTES/1048576 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 64898.7 19.1 64898.7
custid between 1000000 and 2000000
DOAG SIG Database, Köln, 18. Juni 2009 50
Smart Scan AnalyseErweiterungen 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 230636.95
cell physical IO interconnect bytes 54897.61
cell physical IO bytes saved during optimized file creation 0
cell physical IO bytes eligible for predicate offload 205140.65
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 2009 51
Smart ScanWas 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 2009 52
<Insert Picture Here>
Agenda
Exadata Motivation und EinführungSmart I/O ÜberblickSmart Scan FunktionsweiseExadata Komponenten im RDBMSExadata Komponenten im Storage ServerSteuerung und Überwachung
DOAG SIG Database, Köln, 18. Juni 2009 53
RDBMS - Erweiterung I/O Stack
Database Server
RDBMS/ASM instance
dskm
diskmon
SGA
cellinit.ora
cellip.ora
Local IP
Cells
libcell
IO Client
IO Layer
ASM layer
/etc
/ora
cle/
cell
/net
wo
rk-c
on
fig
DOAG SIG Database, Köln, 18. Juni 2009 54
Exadata im RDBMSErweiterung 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 2009 55
Exadata im RDBMSErweiterung 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 2009 56
RDBMS – Disk Monitoring
Database Server
RDBMS/ASM instance
dskm
diskmon
SGA
cellinit.ora
cellip.ora
Local IP
Cells
libcell
IO Client
IO Layer
ASM layer
/etc
/ora
cle/
cell
/net
wo
rk-c
on
fig
DOAG SIG Database, Köln, 18. Juni 2009 57
Exadata im RDBMSErweiterung 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 2009 58
Exadata im RDBMSDISKMON - Funktionalität
Das Zusammenspiel von (Master-) diskmon und (Slave-) dskmermö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 anExadata Zellen
• Empfang von intradatabase IORM Plänen aus RDBMS und Verteilungan die Exadata Zellen
DOAG SIG Database, Köln, 18. Juni 2009 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 aufExadata 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 2009 60
RDBMS - Konfigurationsdateien
Database Server
RDBMS/ASM instance
dskm
diskmon
SGA
cellinit.ora
cellip.ora
Local IP
Cells
libcell
IO Client
IO Layer
ASM layer
/etc
/ora
cle/
cell
/net
wo
rk-c
on
fig
DOAG SIG Database, Köln, 18. Juni 2009 61
Exadata im RDBMSKonfigurationsdateien
• cellinit.ora�Konfiguration Netzwerk-Interface auf Datenbankknoten
�Wird durch RDBMS, ASM und Überwachungs-Tools verwendet
• cellip.ora
�Liste aller verfügbaren Exadata Zellen
� Identisch auf allen Knoten im ASM Cluster
�Dynamisches Hinzufügen möglich
ipaddress1=192.168.50.23/24
cell="192.168.50.29"
cell="192.168.50.30"
cell="192.168.50.31"
DOAG SIG Database, Köln, 18. Juni 2009 62
<Insert Picture Here>
Agenda
Exadata Motivation und EinführungSmart I/O ÜberblickSmart Scan FunktionsweiseExadata Komponenten im RDBMSExadata Komponenten im Storage ServerSteuerung und Überwachung
DOAG SIG Database, Köln, 18. Juni 2009 63
Database Server
RDBMS/ASM instance
dskm
diskmon
SGA
Infiniband Fabric
cellinit.ora
cellip.ora
Local IP
Cells
rs
mscellcli
ADR
adrci
Data
Meta data
Data
Meta data
Data
Meta data
libcell
IO Client
IO Layer
ASM layer
Exadata Storage Server
cellsrv
/etc
/ora
cle/
cell
/net
wo
rk-c
on
fig
Exadata Storage Server – Überblick
DOAG SIG Database, Köln, 18. Juni 2009 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 2009 65
cellsrv
Database Server
RDBMS/ASM instance
dskm
diskmon
SGA
Infiniband Fabric
cellinit.ora
cellip.ora
Local IP
Cells
rs
mscellcli
ADR
adrci
Data
Meta data
Data
Meta data
Data
Meta data
libcell
IO Client
IO Layer
ASM layer
Exadata Storage Server
cellsrv
/etc
/ora
cle/
cell
/net
wo
rk-c
on
fig
DOAG SIG Database, Köln, 18. Juni 2009 66
cellsrvFunktionalitä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 2009 67
cellsrvBlock 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 2009 68
cellsrvI/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 2009 69
ms – Management Server
Database Server
RDBMS/ASM instance
dskm
diskmon
SGA
Infiniband Fabric
cellinit.ora
cellip.ora
Local IP
Cells
rs
mscellcli
ADR
adrci
Data
Meta data
Data
Meta data
Data
Meta data
libcell
IO Client
IO Layer
ASM layer
Exadata Storage Server
cellsrv
/etc
/ora
cle/
cell
/net
wo
rk-c
on
fig
DOAG SIG Database, Köln, 18. Juni 2009 70
ms – Management ServerFunktionalitä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 Email-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 2009 71
ms – Management ServerVerwaltete Objekte
• CELL
• CELLDISK
• GRIDDISK
• LUN
• PHYSICALDISK
• IORMPLAN
• METRICDEFINITION
• ALERTDEFINITION
• METRICCURRENT
• METRICHISTORY
• ALERTHISTORY
• THRESHOLD
• KEY
DOAG SIG Database, Köln, 18. Juni 2009 72
ms – Management ServerObjektattribute
• 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 2009 73
ms – Management ServerPersistenz
• $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 2009 74
ms – Management ServerLogging
• OC4J Logging (Umleitung stdout, stderr), bevor eigentliches Loggeschrieben 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[root@cell1 ~]# cd $ADR_BASE/diag/asm/cell/cell1/trace
[root@cell1 trace]# ls -lrt ms*.*
-rw-r--r-- 1 root root 239239 Jun 14 08:00 ms-odl.trc
-rw-r--r-- 1 root root 239239 Jun 14 08:00 ms-odl.log
[root@cell1 trace]#
DOAG SIG Database, Köln, 18. Juni 2009 75
rs – Restart Server
Database Server
RDBMS/ASM instance
dskm
diskmon
SGA
Infiniband Fabric
cellinit.ora
cellip.ora
Local IP
Cells
rs
mscellcli
ADR
adrci
Data
Meta data
Data
Meta data
Data
Meta data
libcell
IO Client
IO Layer
ASM layer
Exadata Storage Server
cellsrv
/etc
/ora
cle/
cell
/net
wo
rk-c
on
fig
DOAG SIG Database, Köln, 18. Juni 2009 76
rs – Restart ServerFunktionalitä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 2009 77
rs – Restart ServerFunktionalität[root@cell1 trace]# cellcli
list CellCLI: Release 11.1.3.0.0 - 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_11.1.0.7.0_LINUX_080919.03
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 2009 78
rs – Restart ServerZusammenspiel der Komponenten
[root@cell1 ~]# ps -efa |grep oracle
root 1977 1 0 10:40 ? 00:00:00 /opt/oracle/cell/cellsrv/bin/cellrssrm -ms 1 -cellsrv 1
root 1985 1977 0 10:40 ? 00:00:01 /opt/oracle/cell/cellsrv/bin/cellrsomt -ms 1 -cellsrv 1
root 1986 1977 0 10:40 ? 00:00:00 /opt/oracle/cell/cellsrv/bin/cellrsmmt -ms 1 -cellsrv 1
root 1988 1977 0 10:40 ? 00:00:00 /opt/oracle/cell/cellsrv/bin/cellrsbmt -ms 1 -cellsrv 1
root 1998 1988 0 10: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 1999 1986 4 10: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 2000 1985 15 10:40 ? 00:01:51 /opt/oracle/cell/cellsrv/bin/cellsrv 100 5000 9 5042
root 2003 1998 0 10: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 2999 2794 0 10: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 2009 79
rs – Restart ServerLogging
• 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 2009 80
cellcli – Command Line Interface
Database Server
RDBMS/ASM instance
dskm
diskmon
SGA
Infiniband Fabric
cellinit.ora
cellip.ora
Local IP
Cells
rs
mscellcli
ADR
adrci
Data
Meta data
Data
Meta data
Data
Meta data
libcell
IO Client
IO Layer
ASM layer
Exadata Storage Server
cellsrv
/etc
/ora
cle/
cell
/net
wo
rk-c
on
fig
DOAG SIG Database, Köln, 18. Juni 2009 81
cellcli – Command Line InterfaceSteuerung 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 2009 82
cellcli – Command Line InterfaceLogging
• 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 2009 83
<Insert Picture Here>
Agenda
Exadata Motivation und EinführungSmart I/O ÜberblickSmart Scan FunktionsweiseExadata Komponenten im RDBMSExadata Komponenten im Storage ServerSteuerung und Überwachung
DOAG SIG Database, Köln, 18. Juni 2009 84
Exadata Monitoring - RDBMSNutzung 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 2009 85
Exadata Monitoring - RDBMSAnalyse Wait-Events
SELECT w.event, c.cell_path, d.name, w.p3FROM V$SESSION_WAIT w, V$EVENT_NAME e,
V$ASM_DISK d, V$CELL c
WHERE e.name LIKE 'cell%' ANDe.wait_class_id = w.wait_class_id ANDw.p1 = c.cell_hashval AND w.p2 = d.hash_value;
Wait Event Description
cell single block physical read Same as db file sequential read for a cell
cell multiblock physical read Same as db file scattered read for a cell
cell smart table scan DB waiting for table scans to complete
cell smart index scan DB waiting for index or IOT fast full scans
cell smart file creation waiting for file creation completion
cell smart incremental backup waiting for incremental backup completion
cell smart restore from backup waiting for file initialization completion for restore
cell statistics gather
DOAG SIG Database, Köln, 18. Juni 2009 86
Exadata Monitoring – Storage Servercellcli
• Nutzung cellcli
• Nutzung adrci
[root@cell1 log]# cellcli
CellCLI: Release 11.1.3.0.0 - 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
[root@cell1 log]# adrci
ADRCI: Release 11.1.0.7.0 - Production on Sun Jun 14 10:02:26 2009
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
-------------------- ----------------------------------------------------------- -------------------- ----------------------------------------
2 ORA 600 65
2009-03-10 08:23:49.646164 -07:00
1 RS 7445 58 2009-03-10 08:20:31.081830 -07:00
2 rows fetched
adrci>
DOAG SIG Database, Köln, 18. Juni 2009 87
Exadata Monitoring – Storage ServerLog-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 2009 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 2009 93
Oracle ExadataAnalystenmeinung
• ...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.
• ...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.
Source: Measuring the Performance of the Oracle Exadata Storage Server, Winter Corporation, Waltham MA, 2009
DOAG SIG Database, Köln, 18. Juni 2009 94
Explain PlanBeispiel: full table scan – Kein Exadata
---------------------------------------------------------------------------------
| Id | Operation | Name |
---------------------------------------------------------------------------------
| 0 | 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):
---------------------------------------------------
1 - 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 2009 95
Explain PlanBeispiel: full table scan – Exadata
---------------------------------------------------------------------------------
| Id | Operation | Name |
---------------------------------------------------------------------------------
| 0 | 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):
---------------------------------------------------
1 - 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 2009 96
Explain PlanBeispiel: btree index fast full scan – Kein Exadata
---------------------------------------------------------------------------------
| Id | Operation | Name |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | SORT AGGREGATE | |
|* 2 | INDEX FAST FULL SCAN | INDEX1 |
---------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("P1"=10)
DOAG SIG Database, Köln, 18. Juni 2009 97
Explain PlanBeispiel: btree index fast full scan – Exadata
---------------------------------------------------------------------------------
| Id | Operation | Name |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | SORT AGGREGATE | |
|* 2 | INDEX STORAGE FAST FULL SCAN | INDEX1 |
---------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - storage("P1"=10)
filter("P1"=10)
DOAG SIG Database, Köln, 18. Juni 2009 98
Explain PlanBeispiel: bitmap index fast full scan – Kein Exadata
---------------------------------------------------------------------------------
| Id | Operation | Name |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | SORT AGGREGATE | |
| 2 | BITMAP CONVERSION COUNT | |
|* 3 | BITMAP INDEX FAST FULL SCAN | INDEX2 |
---------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - filter("P1"=10)
DOAG SIG Database, Köln, 18. Juni 2009 99
Explain PlanBeispiel: bitmap index fast full scan – Exadata
---------------------------------------------------------------------------------
| Id | Operation | Name |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | SORT AGGREGATE | |
| 2 | BITMAP CONVERSION COUNT | |
|* 3 | BITMAP INDEX STORAGE FAST FULL SCAN | INDEX2 |
---------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - storage("P1"=10)
filter("P1"=10)
DOAG SIG Database, Köln, 18. Juni 2009 100
Explain PlanBeispiel: bloom filter – Kein Exadata
---------------------------------------------------------------------------------
| Id | Operation | Name |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | SORT AGGREGATE | |
| 2 | PX COORDINATOR | |
| 3 | PX SEND QC (RANDOM) | :TQ10002 |
| 4 | SORT AGGREGATE | |
|* 5 | HASH JOIN | |
| 6 | JOIN FILTER CREATE | :BF0000 |
| 7 | PX RECEIVE | |
| 8 | PX SEND HASH | :TQ10000 |
| 9 | PX BLOCK ITERATOR | |
| 10 | TABLE ACCESS FULL | EMPLOYEE |
| 11 | PX RECEIVE | |
| 12 | PX SEND HASH | :TQ10001 |
| 13 | JOIN FILTER USE | :BF0000 |
| 14 | PX BLOCK ITERATOR | |
|* 15 | TABLE ACCESS FULL | DEPT |
---------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
5 - access("E"."DEPT_ID"="D"."DEPT_ID")
15 - filter(SYS_OP_BLOOM_FILTER(:BF0000,"D"."DEPT_ID"))
DOAG SIG Database, Köln, 18. Juni 2009 101
Explain PlanBeispiel: bloom filter – Exadata
---------------------------------------------------------------------------------
| Id | Operation | Name |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | SORT AGGREGATE | |
| 2 | PX COORDINATOR | |
| 3 | PX SEND QC (RANDOM) | :TQ10002 |
| 4 | SORT AGGREGATE | |
|* 5 | HASH JOIN | |
| 6 | JOIN FILTER CREATE | :BF0000 |
| 7 | PX RECEIVE | |
| 8 | PX SEND HASH | :TQ10000 |
| 9 | PX BLOCK ITERATOR | |
| 10 | TABLE ACCESS STORAGE FULL | EMPLOYEE |
| 11 | PX RECEIVE | |
| 12 | PX SEND HASH | :TQ10001 |
| 13 | JOIN FILTER USE | :BF0000 |
| 14 | PX BLOCK ITERATOR | |
|* 15 | TABLE ACCESS STORAGE FULL | DEPT |
---------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
5 - 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 2009 102
Explain PlanBeispiel: keine Prädikate – Exadata
---------------------------------------------------------------------------------
| Id | Operation | Name |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | SORT AGGREGATE | |
| 2 | PX COORDINATOR | |
| 3 | PX SEND QC (RANDOM) | :TQ10000 |
| 4 | 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 2009 103
ms – Management ServerPersistenz
• $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="4910.136962890625 "></Attribute>
<Attribute NAME="iormBoost" VALUE="0.0"></Attribute>
<Attribute NAME="offloadEfficiency" VALUE="4910.136962890625"></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 2009 104
ms – Management ServerPersistenz
• $OSSCONF/cellinit.ora� Konfiguration für cellsrv und rs
� ms aktualisiert ipaddressN und TRACELEVEL
[root@cell1 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=192.168.88.101/24
DEPLOYED=TRUE
_reconnect_to_cell_attempts=4
JMS_PORT=9127
BMC_SNMP_PORT=162
_skgxp_udp_use_tcb=false
[root@cell1 config]#
DOAG SIG Database, Köln, 18. Juni 2009 105
ms – Management ServerPersistenz
• $OSSCONF/alerts.xml� Sammlung aller Alerts
� Bereinigung nach N Tagen, festgelegt in MetricHistoryDays(Zellenattribut)
• $OSSCONF/metrics*.xml
� Stündliche Sammlung aller Metriken
� Bereinigung nach N Tagen, festgelegt in MetricHistoryDays(Zellenattribut)
� Anzeige durch list metrichistory
� File Name: metrics_yymmdd_hh24.xml[root@cell1 config]# ls -lrt metric*.xml
-rw-r--r-- 1 root celladmin 522650 Jun 13 11:00 metrics_090613_11.xml
-rw-r--r-- 1 root celladmin 983484 Jun 13 12:00 metrics_090613_12.xml
-rw-r--r-- 1 root celladmin 700134 Jun 14 08:00 metrics_090614_08.xml
[root@cell1 config]#