DOAG SIG Database, Köln, 18. Juni 2009DOAG SIG Database ... · DOAG SIG Database, Köln, 18.06.2009. DOAG SIG Database, Köln, 18. Juni 2009 3 Agenda

DOAG SIG Database, Köln, 18. Juni 2009 1DOAG SIG Database, Köln, 9. Juni 2009 1

<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


Agenda

Exadata Motivation und EinführungSmart I/O ÜberblickSmart Scan FunktionsweiseExadata Komponenten im RDBMSExadata Komponenten im Storage ServerSteuerung und Überwachung


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


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


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


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


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


• 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


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


Beispiel "Non well balanced"

FC-Switch1 FC-Switch2

HB

A1

HB

A2


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


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


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


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.


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


Verschiedene Lösungsansätze


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"


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


• 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


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,…)


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


Liefert Spitzendurchsatz von 14 GB/s !


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


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


HP Oracle Database ServerHP Oracle Database ServerHP Oracle Database ServerHP Oracle Database Server


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




HP OracleHP OracleHP OracleHP Oracle ExadataExadataExadataExadata Storage ServerStorage ServerStorage ServerStorage Server1

2

8

1

2

3

14




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!


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

…


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


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



Agenda



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)


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.


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


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


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



Agenda



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


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


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


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


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!


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


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)


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


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


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


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


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:



• 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 |


| PX BLOCK ITERATOR | | 10M|

| TABLE ACCESS STORAGE FULL| TEST | 10M|

-----------------------------------------------------



• Full scanselect /*+ FULL(test) parallel(test, 8) */ count(*) from test;

• Smart Scan eingeschaltetalter session set cell_offload_processing=true;

• Execution Plan-----------------------------------------------------


-----------------------------------------------------






| 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



• Full scan mit Filterselect /*+ FULL(test) parallel(test, 8) */ count(*) from test

where a=1;


• Execution Plan----------------------------------------------------


----------------------------------------------------






| 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



• Full scan mit Filter und Spaltenprojektionselect /*+ FULL(test) parallel(test, 8) */ count(a) from test

where a=1;


• Execution Plan----------------------------------------------------


----------------------------------------------------






| PX BLOCK ITERATOR | | 10 |

| TABLE ACCESS STORAGE FULL| TEST | 10 |

----------------------------------------------------


---------------------------------------------------

6 - storage("A"=1)

filter("A"=1)

0

5000

10000

no

SmartScan

Smart Scan Smart Scan

+ Filter

Smart Scan

+ Filter +

Proj


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


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


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!



Agenda



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


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


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)


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


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


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


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


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


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"



Agenda



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


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


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


cellsrv

/etc

/ora

cle/

cell

/net

wo

rk-c

on

fig


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


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


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


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


cellsrv

/etc

/ora

cle/

cell

/net

wo

rk-c

on

fig


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


ms – Management ServerVerwaltete Objekte

• CELL

• CELLDISK

• GRIDDISK

• LUN

• PHYSICALDISK

• IORMPLAN

• METRICDEFINITION

• ALERTDEFINITION

• METRICCURRENT

• METRICHISTORY

• ALERTHISTORY

• THRESHOLD

• KEY


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


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!


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]#


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


cellsrv

/etc

/ora

cle/

cell

/net

wo

rk-c

on

fig


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)


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>


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


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)


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


cellsrv

/etc

/ora

cle/

cell

/net

wo

rk-c

on

fig


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


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)



Agenda



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


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


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>


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


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


Fragen & Antworten




Unused slides


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


Explain PlanBeispiel: full table scan – Kein Exadata

---------------------------------------------------------------------------------

| Id | Operation | Name |

---------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | |

|* 1 | HASH JOIN | |


|* 3 | TABLE ACCESS FULL | SALES |



---------------------------------------------------------------------------------


---------------------------------------------------

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)


Explain PlanBeispiel: full table scan – Exadata

---------------------------------------------------------------------------------


---------------------------------------------------------------------------------


| * 1 | HASH JOIN | |

| * 2 | HASH JOIN | |

| * 3 | TABLE ACCESS STORAGE FULL | SALES |



---------------------------------------------------------------------------------


---------------------------------------------------

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)


Explain PlanBeispiel: btree index fast full scan – Kein Exadata

---------------------------------------------------------------------------------


---------------------------------------------------------------------------------


| 1 | SORT AGGREGATE | |

|* 2 | INDEX FAST FULL SCAN | INDEX1 |

---------------------------------------------------------------------------------


---------------------------------------------------

2 - filter("P1"=10)


Explain PlanBeispiel: btree index fast full scan – Exadata

---------------------------------------------------------------------------------


---------------------------------------------------------------------------------



|* 2 | INDEX STORAGE FAST FULL SCAN | INDEX1 |

---------------------------------------------------------------------------------


---------------------------------------------------

2 - storage("P1"=10)

filter("P1"=10)


Explain PlanBeispiel: bitmap index fast full scan – Kein Exadata

---------------------------------------------------------------------------------


---------------------------------------------------------------------------------



| 2 | BITMAP CONVERSION COUNT | |

|* 3 | BITMAP INDEX FAST FULL SCAN | INDEX2 |

---------------------------------------------------------------------------------


---------------------------------------------------

3 - filter("P1"=10)


Explain PlanBeispiel: bitmap index fast full scan – Exadata

---------------------------------------------------------------------------------


---------------------------------------------------------------------------------



| 2 | BITMAP CONVERSION COUNT | |

|* 3 | BITMAP INDEX STORAGE FAST FULL SCAN | INDEX2 |

---------------------------------------------------------------------------------


---------------------------------------------------

3 - storage("P1"=10)

filter("P1"=10)


Explain PlanBeispiel: bloom filter – Kein Exadata

---------------------------------------------------------------------------------


---------------------------------------------------------------------------------



| 2 | PX COORDINATOR | |

| 3 | PX SEND QC (RANDOM) | :TQ10002 |



| 6 | JOIN FILTER CREATE | :BF0000 |

| 7 | PX RECEIVE | |

| 8 | PX SEND HASH | :TQ10000 |

| 9 | PX BLOCK ITERATOR | |

| 10 | TABLE ACCESS FULL | EMPLOYEE |


| 12 | PX SEND HASH | :TQ10001 |

| 13 | JOIN FILTER USE | :BF0000 |


|* 15 | TABLE ACCESS FULL | DEPT |

---------------------------------------------------------------------------------


---------------------------------------------------

5 - access("E"."DEPT_ID"="D"."DEPT_ID")

15 - filter(SYS_OP_BLOOM_FILTER(:BF0000,"D"."DEPT_ID"))


Explain PlanBeispiel: bloom filter – Exadata

---------------------------------------------------------------------------------


---------------------------------------------------------------------------------







| 6 | JOIN FILTER CREATE | :BF0000 |


| 8 | PX SEND HASH | :TQ10000 |


| 10 | TABLE ACCESS STORAGE FULL | EMPLOYEE |


| 12 | PX SEND HASH | :TQ10001 |

| 13 | JOIN FILTER USE | :BF0000 |


|* 15 | TABLE ACCESS STORAGE FULL | DEPT |

---------------------------------------------------------------------------------


---------------------------------------------------

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"))


Explain PlanBeispiel: keine Prädikate – Exadata

---------------------------------------------------------------------------------


---------------------------------------------------------------------------------







| 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



• $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>

.....



• $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]#



• $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



[root@cell1 config]#

Documents

DOAG SIG Database, Köln, 18. Juni 2009DOAG SIG Database ... · DOAG SIG Database, Köln, 18.06.2009. DOAG SIG Database, Köln, 18. Juni 2009 3 Agenda