Oracle Exadata Life Cycle & Services

Best Practices im Exadata Life Cycle

Ein Whitepaper der avato consulting ag

update

Seite 2/69

update

© 2014 avato consulting ag

Autoren:Ronny EgnerLutz FröhlichTorsten LoofStefan PanekFrank Schneede (Oracle Deutschland)

avato consulting agSiemensstr. 24-26, 63755 Alzenau/GermanyTelefon: +49 6023 967490www.avato-consulting.com

Seite 3/69

update

Inhalt1 Exadata Projekte an jeder Ecke – Zeit für ein erstes Fazit . . . . . . . . . . . . . . . . . 5

2 System Design und Projektplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Analyse und Dokumentation der existierenden Systemlandschaft. . . . . . . . . . . . 6 2.2 Workshop mit Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Proof of Concept (PoC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 Modellauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5 Vorbereitung Data Centre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.6 Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.7 Detailkonfiguration mittels des Exadata Deployment Assistant . . . . . . . . . . . . . 10 2.8 Hochverfügbarkeit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.9 Backup/Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 InstallationundMigration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 3.1 Planung des Installationsprozesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 Installation der Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.3 Installation des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4 Datenbank-/Anwendungsmigration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.1 Migration über Export/Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4.2 Migration über Transportable Tablespace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4.3 Migration mit Golden Gate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.5 Fallback Scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6 Backup/Recovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 ExadataOperations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 4.1 Integration in die Support-Organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.1 Horizontale versus vertikale Support-Organisation . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1.2 Oracle DBA oder Oracle DMA (Oracle Database Machine Administrator)? . . . . . . 24

4.2 Oracle Service- & Support-Angebote. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.2.1 Oracle Premier Support & Platinum Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.2 Oracle ASR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.2.3 Weitere Oracle ACS Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Unterstützung von Oracle Partnern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.4 Exadata Patch Management: Mysterium oder planbarer Service?. . . . . . . . . . . 30 4.4.1 Was wird wann wodurch gepatcht?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.4.2 Bundle Patch, PSU, CPU, QDPE und QFSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.4.3 Zeitaufwand für den Patch-Vorgang. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Seite 4/69

update 4.4.4 Patch-Zyklen in der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.5 Empfehlungen für die erfolgreiche Patch-Installation . . . . . . . . . . . . . . . . . . . . . . . 39

5 Management-&SupportTools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40 5.1 Provsioning/Rapid Provsioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.1.1 Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1.2 Rapid Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.2 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.3 Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.4 Patching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6 OptimierungimLifeCycle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 6.1 Cell Offloading/Smart Scanning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.1.1 Storage Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.1.2 Column Projection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1.3 Predicate Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.2 HCC (Hybrid Columnar Compression) Architecture . . . . . . . . . . . . . . . . . . . . . . . 51 6.3 Verschlüsselung/Entschlüsselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.4 Virtual Columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.5 Parallelisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 6.6 I/O Ressource Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 6.7 Flash Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7 Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

8 Appendix – Exadata Deployment Assistant Step by Step . . . . . . . . . . . . . . . .57

9 Referenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69

Seite 5/69

update

1 Exadata Projekte an jeder Ecke – Zeit für ein erstes Fazit

Ob als Basis für große und transaktionsreiche OLTP, als Data Warehouse, oder auch als Konsolidierungsplatt-form – immer häufiger wird Exadata als ein zentraler Baustein der IT-Infrastruktur eingesetzt und viele Exada-ta Projekte wurden bereits abgeschlossen. Im Vordergrund der Plattformentwicklung standen Skalierbarkeit, High Performance-Datenbanken und Massendatenverarbeitung, um das System sowohl für das Data-warehousing als auch für OLTP-Anwendungen einsetzen zu können. Oracle positioniert Exadata zudem als eine ausgezeichnete Möglichkeit, Datenbankkonsolidierung auf einer einfach zu implementierenden Platt-form voranzutreiben.

Aus Oracle Sicht handelt es sich bei den Systemen um Engineered Systems. Mit der Exadata Database Machi-ne wird eine vollständige Engineered IT-Infrastruktur geliefert. Die Oracle Database Machine besticht nicht nur durch hervorragende Performance. Sie ist unter anderem dafür ausgelegt, das Deployment und den Be-trieb von Oracle Datenbanken deutlich zu optimieren. Sie ist sozusagen ein „Allround-Talent“ und eine Lösung für sehr unterschiedliche Herausforderungen.

Es ist an der Zeit, ein erstes Fazit aus Projekt- und Betriebssicht zu ziehen. Was sind die Voraussetzungen da-für, dass Anwendungen die Plattform bestmöglich nutzen? Wie wird Exadata optimal in bestehende Betrieb-sumgebungen eingepasst?

Des Weiteren werden folgende Fragen beantwortet: Welche Tätigkeiten fallen an und wie sehen hier Best Practice-Ansätze aus? Wo übernimmt Oracle Aufgaben und Verantwortung im Life Cycle? An welchen Stellen sind hingegen Kunden und Oracle Partner gefragt? In welchen Bereichen erfordert eine Optimierung von Services ein Umdenken in der IT-Organisation, um den größtmöglichen Nutzen herbeizuführen? Natürlich gibt es Standardvorgehensweisen – aber an welchen Stellen kann und sollte man von diesen abweichen?

In diesem Dokument wird der gesamte Life Cycle einer Oracle Exadata Database Machine anhand der wesent-lichen Phasen betrachtet. Dieses Whitepaper stellt dementsprechend Erfahrungen bei der Einführung, Imple-mentierung, Betrieb und Optimierung von Oracle Exadata Systemen vor. Darüber hinaus weist das Whitepa-per auf unterschiedliche Einsatzszenarien hin und behandelt Themen, die aufgrund der eingesetzten Technologien besondere Herausforderungen darstellen.

Seite 6/69

update

2 System Design und Projektplanung

Delivered „Ready to run“ – so heißt es in den Beschreibungen zu Exadata von Seiten Oracles. Die Systeme werden getestet angeliefert und anschließend über Skripte durch Oracle ACS (Advanced Customer Support) installiert und konfiguriert. Die Basiskonfiguration stammt von Oracle Engineering. Alle individuellen Para-meter werden über Sheets oder den Exadata Deployment Assistant eingestellt. Beim Ausfüllen der Parame-ter-Sheets erhält der Kunde Unterstützung von Oracle ACS. Im nächsten Schritt führt Oracle ACS alle erforder-lichen Skripte automatisch aus und den Post-Check durch.

Oracle wirbt damit, dass dieses Verfahren eine optimale Konfiguration für Anwendungen mit der idealen Mischung aus High Performance, hoher Verfügbarkeit sowie außergewöhnlicher Skalierbarkeit sicherstellt. Weiterhin unterstützt Oracle aktiv beim Design durch Beratung vor Ort. Diese Unterstützung kann bis hin zu einem Proof of Concept gehen.

Da hier eine völlig neue IT-Infrastruktur eingeführt wird, ergeben sich kundenseitig dennoch zahlreiche Auf-gaben, damit ein optimales Ergebnis erzielt wird.

2.1 AnalyseundDokumentationderexistierendenSystemlandschaftZu Beginn eines jeden Projekts, welches sich mit der Einführung einer neuen IT-Infrastruktur auseinander setzt, steht eine umfangreiche Anforderungsanalyse. Ein möglicher Ansatz besteht darin, die Ist-Architektur aufzunehmen und diese für einen gemeinsamen Workshop mit Oracle vorzubereiten. Dabei sind folgende Kennzahlen zu berücksichtigen:

• Prozessor Anforderungen• Oracle Databanken Server Memory und SGA Planung• Netzwerk Planung• Disk Input/Output Operation • Storage Kapazitätsplanung, inklusive Wachstum• Berücksichtigung der ASM Redundanz• Desaster Recovery Planung• Fast Recovery Area Größe und Planung• Anzahl und Größe der Datenbanken• Transaktionscharakteristik• Benutzeranzahl• Aktuelle Engpässe (Basis können AWR Reports sein)

In den meisten Fällen existieren Monitoring- oder Kapazitätsplanungswerkzeuge, welche die Bereitstellung dieser Kennzahlen zu vereinfachen.

Seite 7/69

update

2.2 Workshop mit OracleNach Abschluss der Ist-Aufnahme und einer ausreichenden Capacity-Planung, die das Wachstum in den nächsten Jahren berücksichtigt, wird ein Workshop mit Oracle vereinbart. Im Workshop werden die Kennzah-len validiert, geprüft und gegebenenfalls vervollständigt. Oracle kann viele Fragen aus Erfahrungen mit ver-gleichbaren Exadata Kundenprojekten beantworten. Abschließend wird eine Entscheidungsvorlage ausgear-beitet. Zum einen dient diese als Grundlage für wirtschaftliche Berechnungen (TCO/ROI Betrachtungen) und zum anderen als Basis für einen möglichen Proof of Concept.

2.3 Proof of Concept (PoC) Ein Proof of Concept (PoC) ist bei der Entscheidung für eine neue IT-Infrastruktur kaum zu umgehen, denn durch ihn wird das Risiko wesentlich minimiert. Wird die erhoffte Performance tatsächlich erreicht? Wie läuft ein PoC für ein Exadata Projekt ab und was ist hier speziell zu beachten?

Im Vorfeld werden die Ziele des Proof of Concept definiert. Dabei können Laufzeiten von Load Prozessen oder Batch Jobs und das Antwortzeitverhalten einer OLTP Anwendung eine Rolle spielen. Die Durchführung des Tests wird entweder in einem Testcenter oder auf einer bereitgestellten Maschine vorgenommen. Zentrale Punkte für den PoC sind neben den oben angesprochenen Performance-Tests vor allem auch Komprimie-rungs-Features sowie eine mögliche Migration der Anwendung auf Oracle 11.2. Die Installationen basieren immer auf dem neusten Release. Derzeit ist es möglich, neben 11.2 auch 12.1 als DB Version zu verwenden. Beim Storage Server besteht die Wahl zwischen den Versionen 11.2.3.3 und 12.1.1.1.

Oracle stellt die notwendige Exadata Infrastruktur und unterstützt beispielsweise beim Aufbau der Daten-bank und der Anwendungsumgebung. Erst wenn alle Voraussetzungen und Anforderungen seitens des Kun-den erfüllt sind, werden ausführliche Testreihen durchgeführt. Die Ergebnisse liefern die Grundlage für die Soll-Architektur.

Seite 8/69

update

2.5 Vorbereitung Data Centre Neben der Planung des Exadata Modells (oder der Exadata Modelle) muss eine gründliche Planung im Data Centre vorgenommen werden. Ein Oracle Support Mitarbeiter unterstützt hierbei vor Ort. Es werden der Zugang zum Data Centre, Stromversorgung, Klimatisierung und weitere Parameter geprüft.

2.4 ModellauswahlDer nächste Schritt ist die Zielkonfiguration. Wie bereits erwähnt, sind eine belastbare Capacity-Planung und die Berücksichtigung möglicher Reserven notwendig. Wird beispielsweise im Storage der Exadata zu knapp kalkuliert, könnte dies bedeuten, dass bereits nach kurzer Zeit Engpässe entstehen. Oder, falls die Flash Reco-very Area zu klein kalkuliert wurde, das Backup-Konzept muss überarbeitet werden. Erfahrungen zeigen, dass eine Reserve von mindestens 25 % eingeplant werden sollte.

Soll-Architektur (Zahlen der aktuellen X4-Modellserie):

Rechnersystem Eighth Rack Quarter Rack Half Rack Full Rack

Anzahl Compute Nodes 2 2 4 8

Anzahl Processor Cores 24 48 96 192

Total Memory in GB 1024 1024 2048 4096

Anzahl Storage Server 3 3 7 14

Anzahl Disks 18 36 84 168

Kapazität mit High Perfor-

mance Disks in TB

21 43 100 200

Kapazität mit High Capaci-

ty Disks in TB

72 144 336 672

InfiniBand Switches 2 2 3 3

Seite 9/69

update

2.6 Detailed DesignZum Abschluss der Konfiguration sollten folgende Bereiche genauer betrachtet werden:

Netzwerk:• Domain-Name, IP-Adresse des Nameservers und Networktime Servers;• Management Netzwerk Adressen;• Client Netzwerkadressen und Client Gateway Netzwerkadressen;• Zusätzliche Netzwerkadressen für das Bonding;• Sämtliche Vorbereitungen in Absprache mit der Netzwerkgruppe innerhalb des Unternehmen (um bei-

spielsweise die doppelte Vergabe von Adressen zu vermeiden);

Storage/ASM:• Es gibt zwei Arten von Festplatten:

* High Performance mit 1,2 TB Bruttokapazität;* High Capacity mit 4 TB Bruttokapazität;

(Hinweis: In einem Exadata System können keine unterschiedlichen Disk-Typen verbaut werden. Ein „Misch-

betrieb“ mit 1,2 TB und 4 TB Disks innerhalb eines Systems ist nicht möglich. Erweiterungen mit anderen

Disks können genutzt werden.)

* Flashcache Storage: Neben den Festplatten stehen zusätzlich mehr als 44 TB für die Performance-Optimierung zur Verfügung. Daher sind Engpässe im I/O Bereich fast ausgeschlossen.

• Empfehlung: High Capacity Platten mit 4 TB Kapazität; Die Gesamtkapazität vergrößert sich dadurch enorm, auch wenn I/O Performance einbüßt wird. Hier ein Vergleich der Bruttokapazität 1,2 TB versus 4 TB Disk (Wichtig zu beachten ist, dass nach der ASM Konfi-guration nur noch knapp 50% des Brutto-Speicherplatzes zur Verfügung stehen.):

• Oracle ASM: Exadata nutzt zur Storage-Verwaltung Oracle ASM. Daher sollte man abwägen, ob man bei den Diskgruppen mit „Normal“ oder „High Redundancy“ arbeitet. Dies hat ebenfalls Auswirkung auf die Gesamtkapazität des Storage.

Rechnersystem Quarter Rack Half Rack Full Rack

High Performance Disks in TB 43 100 200

High Capacity Disks in TB 144 336 672

Seite 10/69

update

2.7 DetailkonfigurationmittelsExadataDeploymentAssistantDie Detailkonfiguration wird in Zusammenarbeit mit dem Hersteller vorgenommen. Dazu nutzt Oracle den „Exadata Deployment Assistant“. Dieses Tool bietet eine menügesteuerte Step by Step-Konfiguration des Ge-samtsystems. In der Regel wird nach jedem Konfigurationsschritt eine Zusammenfassung mit der Möglichkeit zur Korrektur angezeigt.

Im Wesentlichen werden im Konfigurationsprozess Angaben erwartet, wie sie auch für Standard Oracle Da-tenbanken bei der Installation und Konfiguration erforderlich sind. An einigen Stellen sind jedoch Exada-ta-spezifische Angaben erforderlich. Viele Parameter können zwar nach der Installation noch angepasst wer-den, aber meist nur mit erheblichem Aufwand.

Details zum Assistant und ein Step by Step-Beispiel finden Sie in Kapitel „8 Appendix - Exadata Deployment Assistant Step by Step“.

• Disk Groups:* Die Namen der Disk Groups können frei gewählt werden – der Standard bei Oracle ACS ist „+DATA“

für Nutzdaten und „+RECO“ für Archive und Backup-Daten.* Verteilung der Gesamtkapazität auf die Disk Groups: Die Verteilung muss berechnet werden – meis-

tens wird die Gesamtkapazität im Verhältnis 40% DATA Disk Group und 60% RECO Disk Group rea-lisiert. Zu beachten ist beispielsweise, ob ein Backup auf Disk geschrieben wird und welche Wachs-tumsraten zu erwarten sind.

Datenbank-Server/Betriebssystem:• Zwei mögliche Betriebssystemvarianten:

* Oracle Enterprise Linux x86_64;* Oracle Solaris 11 x86_64;

(Hinweis: Bei einem Exadata System X3-8 kann kein Solaris x86 installiert werden)

• Der überwiegende Anteil an Installationen wurde auf Basis von Oracle Enterprise Linux vorgenommen. Allerdings gibt es mittlerweile vereinzelt auch Exadata Systeme auf Basis Solaris x86. Die Entscheidung ist unter anderem abhängig davon, welches Know-how im Bereich Betriebssystem innerhalb des Unterneh-mens vorhanden ist.

• Empfehlung: Oracle Enterprise Linux;

Zusätzlich sollte erwähnt werden, dass man mit Exadata ein Oracle ACS „Consulting Package“ von 20 Perso-nentagen erhält. Es empfiehlt sich, diese Ressource aktiv in die Planung einzubeziehen.

Seite 11/69

update

2.8 HochverfügbarkeitNeben einer sorgsamen Planung der Systemkonfiguration spielt im Rahmen einer Exadata Planung für viele Kunden das Thema Desaster Recovery eine wichtige Rolle. Lösungsansätze, wie der Aufbau von Stretched Clusters, sind allerdings mit einer Exadata Architektur nicht realisierbar. Exadata integriert als ein ViS (Vertical integrated System) sowohl alle Hardware- als auch Software-Komponenten in einem Rack. Daher besteht die einzige Desaster Recovery Lösung darin, ein zweites Exadata System in einem entfernten Data Centre aufzu-bauen und Data Guard einzusetzen. Mit dieser Lösung erreicht man das Maximum an Sicherheit in Form einer Maximum Availability Architecture MAA. Weitere Informationen zu diesem Thema finden Sie hier: Deploying Oracle Maximum Availability Architecture with Exadata Database Machine [2]. Dieses zweite System ist von doppeltem Nutzen, denn es kann zusätzlich für die Entwicklungs- und Testdatenbanken oder als Repor-ting-System genutzt werden – sofern Active Data Guard zum Einsatz kommt. Informationen zum Aufbau einer x86 Cloud finden Sie hier: Database as a Service [3].

Eine kostengünstigere Lösung bietet Standard x86-Hardware auf der Basis Oracle Enterprise Linux und als Storage-Lösung entweder ein SUN ZFS Storage oder ein Pillar Axiom Storage-System. Diese Konfiguration kann ebenfalls mit Data Guard als Desaster Recovery Lösung genutzt werden. Dabei muss beachtet werden, dass spezielle Features von Exadata, wie Smart Scan, Storage Index, Flash Cache und auch IORM, nicht vor-handen sind. Somit scheidet diese Lösung für Performance-kritische Implementationen aus.

2.9 Backup/RestoreDie Implementierung eines Backup-Verfahrens gehört nicht zum „Installation Package“ von Oracle ACS. Der Kunde muss daher frühzeitig ein eigenes Konzept entwickeln. Grundsätzlich unterscheidet sich das Backup von Exadata nicht vom Backup anderer Oracle Datenbanken. Auch im Exadata Umfeld kommt meist RMAN (RMAN Skripte) zum Einsatz. Auf ein paar Besonderheiten sollte man jedoch achten:

• Die Compute Nodes müssen in die Backup-Strategie und die Verfahren einbezogen werden.• Bei der Nutzung einer existierenden Tape Infrastruktur muss ein Media Server zur Anbindung von Fibre

Channel eingesetzt werden. Alternativ kann man auf InfiniBand Fibre Channel Gateways zurückgreifen.• Ist geplant, das System über Snapshot zu sichern und HCC zu verwenden, müssen ZFS oder Pillar Axiom

Storage-System eingesetzt werden.

Weitere Details zu diesem Thema finden Sie in Kapitel „3.6 Backup/Recovery“.

Seite 12/69

update

3 InstallationundMigration

Bei der Installation von Exadata Systemen kommen viele Fragen auf. Es sind Aspekte der vertikal integrierten Technologie und der neuen Features zu betrachten:

• Smart Scan• Storage Index• Flash Cache• Hybrid Columnar Compression• I/O Resource Manager

Die Installation teilt sich in verschiedene Phasen auf, die in diesem Kapitel beschrieben werden.

3.1 PlanungdesInstallationsprozessesDer Installationsprozess besteht aus zwei Bereichen:

1. Abstimmung/OEDA: Existierende Standards im Unternehmen werden erneut abgestimmt und die Konfi-guration wird mit Hilfe des Oracle Exadata Deployment Assistant (OEDA) vorbereitet. Der Output des OEDA ist ein wesentlicher Faktor für die Qualität der Installation.

2. Installation: Die Installation wird durch Oracle ACS durchgeführt. Dies ist ein automatisierter Prozess, der per Skript gesteuert wird.

3.2 InstallationderHardwareDie Lieferung der Systeme erfolgt durch eine Spedition. Im ersten Schritt werden die Systeme an ihren vorge-sehenen Platz im Data Centre gebracht und aufgebaut. Die Inbetriebnahme geschieht allerdings erst nach einigen Tagen, da sich das System „akklimatisieren“ muss. Anschließend wird das System seitens Oracle in Betrieb genommen und Oracle ACS kann mit dem Setup be-ginnen.

3.3 InstallationdesSystemsDie Installation von Exadata ist Oracle ACS vorbehalten und läuft wie folgt ab:

• Fertigstellung des Konfigurationsassistenten;• Datentransfer zum DBM Konfigurator & Generierung der Parameterdateien;• Upload der Dateien zum Exadata System;• Start des CheckIP Skripts zur Prüfung der Netzwerkkonfiguration & erster Boot;• Start des Onecommand Skripts;

Seite 13/69

update

Zum Installationsprozess ist weiterhin Folgendes anzumerken:

• Datenbank-Software Installation * Oracle ACS installiert auf dem Exadata System die zu dem Zeitpunkt aktuelle Software („aktuell“ in

Bezug auf Grid Infrastruktur und RDBMS Software).* Der Software-Stand kann der MOS Note 888828.1 entnommen werden. Diese MOS Note ist neben

dem Oracle Information Center (Doc ID 1306791.2) ein guter Einstiegspunkt für sämtliche Informa-tionen zum Thema Exadata.

* Des Weiteren sollte der Kunde zwecks Vereinheitlichung seine vorhandenen OFA (Oracle Optimal Flexible Architecture) Standards auf die Exadata Installation übertragen.

• Abnahme der Systeme* Oracle ACS schließt die Installation mit einem Exachk Performance Test ab und übergibt das System

an den Kunden. Es empfiehlt sich, den Exachk Performance Test nach Konfigurationsänderungen zu wiederholen (Oracle Exadata Database Machine exachk or HealthCheck Doc ID 1070954.1).

* Ein Cluster-Abnahmetest wurde bei den von avato begleiteten Installationen nicht von Oracle durchgeführt. Im Zuge der Qualitätssicherung sind umfangreiche Cluster-Tests absolut empfehlens-wert. So stellt man beispielsweise sicher, dass kein Single Point of Failure vorhanden ist und der Cluster vollständig funktioniert.

• Dokumentation* Die von Oracle übergebene Systemdokumentation sollte um betriebsspezifische und kundenspezi-

fische Informationen ergänzt werden.

Seite 14/69

update

3.4 Datenbank-/AnwendungsmigrationNach Abschluss der Installation wird das Exadata System konfiguriert und ist betriebsbereit. Im nächsten Schritt wird die Datenbank auf das System migriert.

Die folgende Übersicht stellt die wesentlichen Methoden und ihre Randbedingungen für eine Migration vor:

Anforderungen Methoden

Export /

Import

Datapump

Export /

Import

Transportable

Tablespaces

Data Guard

physical

Standby

Data Guard

Logical

Standby

Streams GoldenGate

Oracle Version ab 10g ab 9i ab 9i ab 9i unabhängig

OracleEdition Standard

Edition

Standard

Edition

Standard

Edition

Enterprise

Edition

Enterprise

Edition

Enterprise

Edition

unabhängig

Downtime hoch hoch mittel gering gering gering gering

Systembelastung (Quelle) hoch hoch gering gering gering mittel mittel

Installations&Konfigura-

tionsaufwand

(Datenbankparameter,

Skriptparameter)

mittel mittel gering gering mittel hoch hoch

Komplexität gering gering mittel mittel hoch hoch hoch

Invasives Verfahren

(EingriffinApplikation

notwendig)

nein nein nein nein nein ggf. ggf.

ManuellerEntwicklungs-

aufwand

gering gering hoch gering mittel hoch hoch

AufwandFallback

Szenario*

gering gering mittel gering gering mittel mittel

AbhängigkeitzuPlattform

/ Prozessor Architektur

nein nein nein ja** nein nein

Datenreorganisation ja ja nein nein / ja ja

Anpassung von Storage

Features / Parameter

ja ja nein ja ja

Datentyp Unterstützung sehr gut sehr gut sehr gut sehr gut gut gut gut

ZusätzlicheLizenzen nein nein nein ggf. EE ggf. EE ggf. EE ja

* Fallbackszenario, welches über den Zeitpunkt der Migration (z. B. 1 Woche) hinausgeht** MOS Artice ID: 413484.1

Seite 15/69

update

Das Thema Migration kann aufgrund der hohen Individualität in diesem Whitepaper nicht im kompletten Umfang erörtert werden. In der Tabelle wurde beispielsweise die Migration von einem Fremdsystem nicht berücksichtigt. In der Praxis haben sich folgende zentrale Aspekte der Migration herauskristallisiert:

• Handling von Downtimes;• Migration auf eine x86-Architektur;• Release (Exadata basiert immer auf dem aktuellen Release);

Unsere Erfahrung hat gezeigt, dass in über 90% der durchgeführten Migrationen das Datenbank Utility „Data Pump“ zum Einsatz kommt, obgleich hier eine lange Downtime benötigt wird. Um die Downtime zu minimie-ren und gleichzeitig einen Wechsel auf eine x86-Infrastruktur zu vollziehen, hat sich in das Export/Import Verfahren bewährt.

Weitere Empfehlungen in Bezug auf die Migration:

• Ausarbeitung detaillierter Checklisten nach dem Step by Step-Verfahren;• Einbeziehung der Fachabteilung während der Migration;• Mehrfaches Testen des Migrationsverfahrens & “Generalprobe”;

Im Folgenden soll auf einige Migrationsverfahren näher eingegangen werden.

3.4.1 MigrationüberExport/ImportIn der Praxis hat sich ein Verfahren etabliert, bei dem sowohl die Downtime minimiert als auch der Wechsel auf x86 vollzogen werden kann.

Export/Import (bzw. seit Oracle 10g Data Pump) ist der “Allrounder” für die Migration von Datenmengen bis ca. 1 TB. Größere Datenmengen sollten, wenn möglich, mittels Transportable Tablespace migriert werden.

Der Vorteil des Export/Import Verfahrens liegt darin, dass es bis zu Version 8 benutzt werden kann. Außerdem ist es unabhängig von dem bisherigen Betriebssystem der Datenbank. Darüber hinaus bietet es die Möglich-keit, nur bestimmte Daten zu ex- bzw. importieren und beim Import gewisse Änderungen an den Daten vor-zunehmen (zum Beispiel eine Komprimierung der Daten).Nachteilig ist die vergleichsweise geringe Geschwindigkeit. Insbesondere der notwendige Neuaufbau der In-dices und Constraints kann ohne entsprechendes Tuning länger dauern als der folgende Import.In der Praxis haben sich folgende Möglichkeiten bewährt, um den Exportvorgang zu beschleunigen:

Seite 16/69

update

• Nutzung der PARALLEL Degree Parameters:Durch eine Aufteilung der zu exportierenden Tabellen auf mehrere Worker Processes wird in der Praxis eine annähernd lineare Steigerung der Exportgeschwindigkeit erreicht. Diese Geschwindigkeitssteige-rung ist jedoch nur bis zur physikalischen Maximallesegeschwindigkeit des Storage bzw. der maximalen Schreibgeschwindigkeit des Storage möglich.

• Trennung des Export Files von den Data Files:Es empfiehlt sich, den zu schreibenden Export von den zu lesenden Data Files zu trennen, sodass beide beteiligten Storages nicht wiederholt zwischen lesendem und schreibendem Zugriff wechseln müssen. Auf diese Weise wird ein sequentieller Lese- bzw. Schreibvorgang erreicht.

• Ablegen der Export Files auf dem Exadata System:Für einen zügigen Import ist es ratsam, das Dump File bereits auf dem Exadata System abzulegen, sodass dieser Import auf dem Exadata System nicht durch die mit 1 Gbit/s begrenzte Geschwindigkeit ausge-bremst wird. Alternativ kann das Dump File auf einem Storage abgelegt werden, der durch ein Hochge-schwindigkeitsnetzwerk angebunden ist (zum Beispiel via InfiniBand oder 10 Gigabit Ethernet).

• Komprimierter Export:Ist die für den Export notwendige Zeit trotz Parallelisierung und Trennung der Dateien zu hoch, sollte der Export komprimiert ausgeführt werden. Dies erfordert die Advanced Compression Lizenz oder eine ge-sonderte Vereinbarung mit Oracle, dieses Feature für die Migration nutzen zu können. Ist beides nicht gegeben, kann der Quell-Server mit einer hohen Anzahl möglichst schneller Netzwerkverbindungen aus-gestattet und die vom Export erzeugten Dump Files auf diese Server verteilt werden.

Erfahrungsgemäß sind die meisten Performance-Probleme beim Export von Tabellen mit großen LOBs zu er-warten. Dies liegt vor allem daran, dass LOBs sequentiell exportiert werden – selbst wenn ein entsprechender PARALLEL Degree beim Export angegeben wurde. Der Export der Tabelle mit dem/den LOBs dauert länger als der Export aller anderen Daten und Metadaten. Das sorgt für Verzögerungen. Daher sollte man alle Daten und Metadaten ohne Tabellen mit LOBs exportieren und parallel jeweils einen einzelnen Export pro Tabelle mit LOBs starten. Der Export der Non-LOB-Tabellen kann nach Beendigung bereits in die neue Datenbank impor-tiert und die Constraints/Indices aufgebaut werden.

Die Separierung der Daten in „wichtig“ und „unwichtig“ trägt ebenfalls dazu bei, Zeit zu sparen. Wichtige Da-ten sind in diesem Fall solche, ohne die die Anwendung nicht funktionieren kann. Unwichtige Daten sind beispielsweise Archivdaten, deren Migration weniger zeitkritisch ist.Die Skalierung des Importvorgangs sollte über mehrere Knoten vorher getestet werden. Es lässt sich nicht immer eine Leistungssteigerung erzielen.

Seite 17/69

update

Unter den bereits erwähnten Voraussetzungen sind die Tabellen relativ schnell importiert – die Erzeugung der Indices und Constraints dauert hingegen wesentlich länger.

Die Praxis empfiehlt, die Constraints und Indices nicht mit Data Pump, sondern manuell zu erzeugen.

Dieser Schritt erlaubt einen maximalen Parallelisierungsgrad.

Vorsicht ist geboten, wenn die Tabellen vor dem Import durch den DBA erzeugt werden und viele Partitionen enthalten. Diese Kombination sorgt für lange Importzeiten aufgrund zusätzlicher Checks, die Data Pump beim Import bereits existierender Tabellen durchführen muss. Für jede zu importierende Partition bzw. Subpartiti-on werden ca. zehn Sekunden zur Prüfung benötigt. Dies ist nur bei einer kleinen Anzahl von Partitionen vertretbar.

3.4.2 MigrationüberTransportableTablespaceWenn Datenvolumen oder Zeit nicht ausreicht, bietet sich ein anderes Verfahren an: Transportable Tablespa-ce. Weiterführende Information bietet die MOS Note 1389592.1 „Reduce Transportable Tablespace Downti-me using Cross Platform Incremental Backups“.

Bei diesem Verfahren werden die Data Files mit den Daten kopiert. Anders als Export/Import hat dieses Ver-fahren den Nachteil, dass alle Daten in einem oder mehreren Tablespace(s) migriert werden, ohne die Mög-lichkeit, Daten von der Migration auszuschließen. Der Vorteil liegt in der höheren Geschwindigkeit, da bei-spielsweise die Zeit für den Neuaufbau der Indices und Constraints wegfällt.

Transportable Tablespaces unterliegen allerdings Einschränkungen - beispielsweise folgenden:

• Die Datenbankversion der Zieldatenbank darf nicht „aktueller“ als die der Quelldatenbank sein.• Die Quelldatenbank muss mindestens die Version 10g Release 2 sein.• Sofern sich die Plattformen von Quelle und Ziel unterscheiden, müssen die Data Files vor dem Import mit

dem RMAN konvertiert werden.• Bestimmte Objekttypen, wie zum Beispiel Indices, die auf benutzerdefinierten Funktionen basieren, wer-

den nicht unterstützt und müssen vor dem Transport gelöscht und anschließend neu angelegt werden.• Die Daten in dem oder den Tabelspace(s) müssen „self-contained“ sein, d. h. alle Objekte des Schemas

müssen durch die zu migrierenden Tablespaces erfasst werden.

Seite 18/69

update

Trotz der aufgeführten Einschränkungen eignet sich dieses Verfahren gut zur schnellen Migration großer Da-tenbanken. Der Ablauf der Migration ist wie folgt:

1. Auf der Quelle:a. Betreffende Tablespace(s) auf READ ONLY setzen;b. Export mit dem Parameter „TRANSPORTABLE=y“ und der Angabe des Tablespace;c. Kopieren der Data Files auf das Ziel;d. Nach Abschluss des Kopiervorgangs die Tablespaces auf READ-WRITE setzen;

2. Auf dem Ziel:a. Sofern notwendig: Konvertieren der Data Files mit dem RMAN (und Ablegen im ASM);b. Import der Daten mittels Data Pump;c. Anlegen vorher gelöschter, inkompatibler Objekte;

Die längste Zeit benötigt das Kopieren der Data Files. Diese Zeit lässt sich jedoch unabhängig von deren Größe auf wenige Minuten reduzieren. Dazu werden die Data Files im laufenden Betrieb als RMAN Image Copy ge-sichert. Eine Image Copy ist eine 1:1 Kopie der Data Files, welche unmittelbar durch die Datenbank genutzt werden kann. In die Image Copy können die Änderungen durch den RMAN inkrementell und damit sehr schnell übertragen werden. Speichert man diese Kopie via NFS auf dem Zielsystem, so wird die Dauer des Kopiervorgangs auf ein Minimum reduziert. Der beschriebene Ablauf muss allerdings um ein weiteres inkre-mentelles Backup nach der Aktivierung des READ-ONLY Status des Tablespace ergänzt werden.

Die Zeit zum Konvertieren der Data Files lässt sich mit der Version 11g Release 2 der Datenbank nicht reduzie-ren. Doch da die zu lesenden Daten bereits lokal oder auf einem breitbandig angebunden Storage liegen (In-finiBand oder 10 GE – jedoch nicht Gigabit Ethernet), ist die Konvertierung auf der Exadata Plattform dank Parallelisierung sehr schnell.

Mit diesem Verfahren haben die Autoren eine 20 TB Datenbank innerhalb von fünf Stunden migriert. Eine vergleichbare Geschwindigkeit ist mit Export/Import kaum erreichbar.

Seite 19/69

update

3.4.3 MigrationmitGoldenGateAls dritte Methode zur Migration kann Golden Gate genutzt werden. Golden Gate ist eine Replikationstech-nologie von Oracle, die Migrationen unabhängig vom Datenvolumen fast ohne Downtime ermöglicht. Bei dieser Technik werden die Daten von der Quelle zum Ziel kontinuierlich repliziert. Sofern die Tabelle noch nicht vorhanden ist, wird diese kopiert und nach Abschluss annähernd synchron repliziert. Golden Gate ist zudem in der Lage, Replikation nicht nur zwischen verschiedenen Oracle Versionen, sondern auch zwischen verschiedenen Datenbanksystemen (etwa MS SQL → Oracle oder Oracle → MySQL oder MS SQL → DB2) vor-zunehmen. Aufgrund dieser Features lässt sich eine Migration nach anfänglicher Synchronisation mit minima-ler Downtime realisieren – unabhängig von der Größe der Datenbank. Nachteilig ist allerdings, dass die Einar-beitung in Golden Gate zeitaufwändig und für die Nutzung eine entsprechende Lizenz erforderlich ist.

Weitere Informationen zu Golden Gate im Exadata Umfeld finden Sie hier: Oracle GoldenGate on Oracle Exa-data Database Machine [4].

3.5 Fallback Scenario Selbst die beste Vorbereitung ist keine Garantie dafür, dass am Ende keine Fehler auftreten. Daher sollte man im Vorfeld ein Fallback Scenario ausarbeiten.

Wird auf der Produktionsdatenbank bereits mit Oracle Flashback Technologie gearbeitet, so könnte man zu Beginn der Migration einen sogenannten Restore Point setzen und im Fehlerfall auf diesen zurück „recovern“. Ein anderes Verfahren könnte darin bestehen, eine Standby Datenbank mit dem ursprünglichen Stand zu ak-tivieren.

3.6 Backup/RecoveryDas Backup von Exadata unterscheidet sich nicht von dem Backup einer Oracle RAC Datenbank. Der Unter-schied liegt vielmehr in der Lokation des Backups. Es gibt folgende Möglichkeiten:

• Innerhalb des Exadata Racks* In der Fast Recovery Area;* In einer ASM Disk Group (Non-Fast Recovery Area);

• Außerhalb des Exadata Racks* In einer ASM Disk Group;* Auf einem NFS Mount Point;* Direkt von der Datenbank auf Tape;* Vom Disk Backup auf ein Tape;

Seite 20/69

update

Neben den oben genannten Randbedingungen und abhängig von den spezifischen RPO/RTO Anforderungen des Kunden kann ein Backup-Konzept erstellt und implementiert werden.

Für ein effektives Backup gibt es zwei Szenarien:

Szenario 1:• DB mit physical Standby;• Backups werden von der Primary in Form einer Image Copy gezogen → sehr schnelle Wiederherstellung

durch Switch des Data File im Fehlerfall;• Die Standby läuft NICHT auf dem Exadata Storage sondern auf der ZBA (ZFS Backup Appliance) – das ist

ebenso mit HCC möglich. Backups sind Snapshots der Standby DB. Diese können genutzt werden* um UAT- und DEV-DBs zu erzeugen;* zum Backup der Datenbank auf Band;

• Nachteil: Es ist eine ZBA erforderlich;• Vorteil: Sehr kleine RTO und der Aufbau von Testdatenbanken ist sehr schnell; Die einzelne Test-DB benö-

tigt kaum Platz, da Snapshots genutzt werden;

Szenario 2:• DB mit physical Standby;• Reine Backups der Standby DB auf Band mit dem RMAN;• Nachteil: Bietet eine nicht so große RTO (hängt sehr stark von der DB-Größe und der Geschwindigkeit des

Netzwerkes und der Bandlaufwerke ab). Zudem ist der Aufbau von Testdatenbanken wesentlich langsa-mer und braucht entsprechend viel Platz (2 DBs = doppelter Platz, 3 DBs = dreifacher Platz usw.);

Weitere Informationen finden Sie hier: Backup and Recovery Performance and Best Practices for Exadata Cell and the Oracle Exadata Database Machine [5] und Backup and Recovery Performance and Best Practices using Oracle Sun ZFS Storage Appliance and Oracle Exadata Database Machine [6].

Seite 21/69

update

4 ExadataOperations

Exadata ist ein Vertical Integrated System – mit integriertem Storage und einer Koppelung der Komponenten über InfiniBand. Damit stellen sich in vielen Bereichen neue Herausforderungen an das Operations. Dies gilt besonders für den Hardware Support, aber auch für die Organisation der Operations Teams. Zudem kommen Fragen bezüglich Support-Aufwände und Service-Angebote des Herstellers auf.Oracle wirbt für die Plattform mit dem Argument, dass die Support-Aufwände deutlich geringer ausfallen. Das liegt laut Hersteller nicht nur an der Standardisierung von Datenbanken, sondern vor allem daran, dass die Aufwände in den Bereichen Storage, OS, Hardware und Netzwerk sinken. Im Folgenden soll diese Aussage von Oracle genauer untersucht werden.

4.1 IntegrationindieSupport-OrganisationIn der Regel kennt die klassische Operations-/Support-Organisation vier bis fünf “Bereiche”, die über Anwen-dungen hinweg spezialisiert horizontal den Support durchführen: Netzwerk, Storage, Betriebssystem, Daten-bank (Backup) und Application. Erfahrungswerte haben gezeigt, dass man sich gut an den von Oracle angege-benen Werten orientieren kann: 60% der Tätigkeiten entfallen auf die Datenbank, 20% auf die Administration der Storage Zellen und ca. 20% auf die Linux Administration sowie andere Komponenten (wie InfiniBand und Netzwerk).

Mit Ausnahme des Application Supports integriert Exadata alle Ebenen mit speziellen Technologien in einem System und erfordert damit eine umfangreiche Koordination und ein intensives Zusammenarbeiten unter-schiedlicher Support-Einheiten. Auf den ersten Blick wirkt es für einige Support-Bereiche erschwerend, dass neben neuer Technologie im Grunde auch der Einsatz des Oracle Enterprise Managers CC erforderlich ist. Neben der Unterstützung durch Oracle und/oder Oracle Partner bieten sich zwei Ansätze für den Support bei der Einführung von Exadata:

• Oracle DMA Team (Database Machine Administrator)Statt zu der klassischen horizontalen Support-Organisation geht man in Teilbereichen zu einer vertikalen Struktur über. Dabei werden Aufgabengebiete auf das DBA Team übertragen und dieses Team wird zu einem Oracle DMA Team erweitert. Neben den Standardthemen beschäftigt sich das Oracle DMA Team zukünftig auch mit dem Storage (ASM), Betriebssystem sowie InfiniBand-Netzwerk.

• Tool-Einführung und Skill-AufbauIn der klassischen horizontalen Support-Struktur wird teamübergreifend der Enterprise Manager Cloud Control eingeführt. Zudem findet in allen Teams der Aufbau des entsprechenden Know-hows zum System und zum Tool statt.

Seite 22/69

update

4.1.1 HorizontaleversusvertikaleSupport-OrganisationWie bereits beschrieben, erfordert die Einführung von Exadata ein klares Betriebskonzept. Welche Services werden von Oracle und/oder Oracle Partnern bezogen? Wie stellt sich die eigene Organisation auf? Ganz wesentliche Punkte neben den Spezifika eines Vertical integrated Systems sind der genutzte Software Stack sowie das Management- und Monitoring Tool.

Spezifika integrierter Systeme:

• Es entstehen für den Betrieb Anforderungen, die auf Basis der aktuellen Struktur und der eingesetzten Dienstleister unter Umständen nicht gelöst werden können. Dazu gehören beispielsweise:

* Setup und Installation: Wird weitgehend von Oracle und/oder Oracle Partnern geleistet (WeitereInformationen finden Sie in Kapitel „3 Installation und Migration“);

* Hardware Support (Storage, InfiniBand), ASR (Auto Service Request): Wird weitgehend von Oraclegeleistet (in Einzelfällen auch von Oracle Partnern);

* Anforderungen an Tools und Prozesse aufgrund der speziellen Hardware (z. B. Disk Replacement,InfiniBand);

Software Stack: DMS & OS

• Mit Exadata werden Oracle Technologien genutzt, die in dieser Form eventuell bisher nicht zum Einsatz kamen. Eine Support-Organisation muss daher umfangreiches Know-how und ausreichend praktische Er-fahrung in den Bereichen Oracle Clusterware, ASM, RAC und Data Guard mitbringen. Da bei fast allen Installationen OEL genutzt wird, ist es von Vorteil, wenn sich der Support mit OEL auskennt. Zudem sind für die Fehleranalyse auch Erfahrungen mit InfiniBand hilfreich (lesen und interpretieren von Protokollda-teien).

Management Tool:

• Der Enterprise Manager Cloud Control ist das zentrale Tool für Management und Monitoring der Platt-form. Falls dieser bisher nicht genutzt wurde, sollte er spätestens mit Exadata Einzug finden.

In welchen Bereichen ergeben sich wesentliche Veränderungen für eine Support-Organisation und welche Modelle lassen sich hieraus ableiten? Im Grunde steht dem etablierten horizontalen Modell (mit klarer Tren-nung zwischen Application, Database, System und Storage) ein zweites Modell gegenüber: Eine vertikale Sup-port-Struktur, bei der die Bereiche Database, System und Storage in einem DMA-Team (Database Machine Administrator) zusammengefasst werden.

Seite 23/69

update

Die folgende Tabelle beschreibt die wesentlichen Unterschiede sowie die Vor- und Nachteile beider Modelle:

Horizontale Support-Struktur Vertikale Support-Struktur

Support-Organisation Database Administration (DBA)

System Administration (SA)

Storage Administration

Neue Support-Gruppe für Appliance:

ODM Team

Abstimmungsaufwände im

Appliance Support

Hoch: Viele Tätigkeiten erfordern Beteiligung

mehrerer Gruppen. Unterschiedliche Teams

haben Schnittstellen zum Oracle Support.

Gering: Ein Team kann (fast) alle Tätigkei-

ten abdecken und es besteht nur eine

Schnittstelle zu Oracle.

Management Tools Vielzahl von Tools oder zentraler Tool-Einsatz

(SA Team nutzt Oracle EM)

Vollständiges Management der Systeme

über eine Konsole (inkl. Storage)

Team Skill SA Team muss Know-how aufbauen zu:

* Grid, ASM

* Oracle Enterprise Linux

* Basis Datenbank

* InfiniBand

* Oracle Storage

Primäres Know-how ist die Datenbank-

technologie. Außer OEL ist das erforderli-

che Know-how in der Regel vorhanden.

Patching Mehrere Teams sind gemeinsam involviert. Statt mehrerer Teams (DBA/SA/Storage)

gibt es nur ein Team (Einführung eines

Vier-Augen-Prinzips).

Fehlerdiagnose Teamübergreifende Diagnose Fehlerdiagnose teamintern (in > 90% der

Fälle)

Database Provisioning Teamübergreifende Tätigkeit Komplett über EM

Seite 24/69

update

4.1.2 OracleDBAoderOracleDMA?Entscheidet man sich für die vertikale Support-Struktur, wird eine neue Rolle eingeführt: Der DBA (Database Administrator) wird zum DMA (Database Machine Administrator). Welches Know-how und welche Erfahrun-gen sind für den Betrieb zwingend erforderlich?

• Oracle Enterprise Linux (zusätzlich ggf. Oracle Solaris x86)• Datenbankerfahrung mit der aktuellen Version 11.2 und/oder 12c• RAC, eventuell Data Guard• Enterprise Manager Cloud Control 12c • Backup Software

Welches “Exadata Spezialwissen” muss vorhanden sein?

• Exadata Architektur• Spezielle Exadata Software Features (Weitere Informationen in Kapitel „6 Optimierung im Life Cycle“)• InfiniBand, Storage Cells, Flashdisks, KVM Switches, etc.

Um ein Exadata System zu administrieren, sollte sich das Know-how in etwa wie folgt zusammensetzen: 60% DBA, 20% Systemadministration und 20% Exadata. Ein DBA mit RAC, Clusterware (und eventuell Data Guard) Know-how hat sehr gute Voraussetzungen.

4.2 OracleService-&Support-AngeboteDie Oracle Angebote unterscheiden sich je nach Phase im Life Cycle und unterstützender Organisation.

Design Oracle Pre-Sales berät in der Planungsphase und beim Design (Weitere Informationen in Kapitel „2

System Design und Projektplanung“)

Installation Oracle ACS installiert die Systeme (Weitere Informationen in Kapitel „3 Installation und Migration“)

Migration Oracle Partner/Oracle Consulting

Operations/Support Oracle hat standardmäßig zwei Support-Angebote:

* Premier Support

* Platinum Services

Diese lassen sich durch weitere Oracle ACS Angebote erweitern:

* Oracle Exadata Start-up Pack

* Oracle Solution Support Center

* Oracle Advanced Monitoring and Resolution

* Zusätzliche Services

Seite 25/69

update

4.2.1 OraclePremierSupport&PlatinumSupportOracle bietet im Standard für die Unterstützung von Operations-Teams den Premier Support sowie den Plati-num Support. Das wichtigste Element ist der 24/7 Hardware und Software Support.Was unterscheidet den Premium und Platinum Support und für wen/welches Anwendungsszenario lohnt sich der kostenfreie Platinum Support? Welche Voraussetzungen müssen für den Platinum Service erfüllt sein?

Quelle: Oracle

Mit folgenden Leistungen und Vorteilen bewirbt Oracle den kostenfreien Platinum Service (Quelle: Oracle):• Fault Monitoring

* 24/7 Fault monitoring;* Event filtering and qualification;* Reporting on event management; * A single global knowledge base, tool set and client portal;

• Respond and Restore* 24/7 Response Times:

- 5 min fault notification - 15 min restoration or escalation to development - 30 min joint debugging

* Escalation process and hotline with dedicated escalation managers; Expert support staff available24/7;

• Update and Patch* Assess and analyze: Produce quarterly patch plan;* Plan and deploy: Proactively plan and deploy recommended patches every quarter across all

systems and software components;

Seite 26/69

update

Wann ist der Platinum Service hilfreich und für welche Szenarien kommt der Service weniger in Betracht? Um dies zu entscheiden, sollte genau betrachtet werden, was der Service leistet und was er voraussetzt. Hier steht der Patch Service im Vordergrund. Um einen solchen Service anzubieten, benötigt Oracle zum einen direkten Zugriff auf die Systeme über das Oracle Advanced Support Gateway. Zum anderen muss Oracle da-rauf achten, Systeme kundenseitig auf einem einheitlichen Patch-Level zu halten. Zudem können im Rahmen eines solchen Service keine individuellen Maintenance-Fenster vereinbart werden. Betrachtet man nun die drei potentiellen Einsatzszenarien für Exadata, so ergeben sich folgende Unterschiede in Bezug auf den Plati-num Service:

• KonsolidierungsplattformDas Wesen jeder Konsolidierung und damit auch jeder Konsolidierungsplattform besteht aus einem ho-hen Standardisierungsgrad – kombiniert mit einem strikt geregelten Verfahren für Wartung und Patching. In einem solchen Umfeld kann der Oracle Platinum Service durchaus sinnvoll sein.

• OLTP, DatawarehouseAnwendungen mit hohem Transaktionsvolumen sowie Datawarehouses sind in aller Regel komplexe Um-gebungen mit individuellen Wartungsvereinbarungen und Anwendungslandschaften. Hier sind im Allge-meinen aufwändige Testverfahren und Abstimmungen für Wartungen/Changes erforderlich. Diese Auf-wände stehen einem hochstandardisierten Service meist entgegen.

Charakteristika und Voraussetzungen:

• Hardware Oracle Advanced Support GatewayRecomm. 8 Cores, 48 GB RAM, 6 * 300 GB Disk, Firewall Port freigeschaltet

• Zertifizierte KonfigurationExadata X2, X3 und X4 mit aktuellem Patch-Stand (OS, DB, Exadata SW)(Weitere Informationen finden Sie hier: Certified Platinum Configurations [7])

• Anzahl DB Homes und Datenbanken für Patching/Resolution:Maximal 4 Datenbanken, 2 DB Homes für Eighth, Quarter, Half Rack sowie maximal 8 Datenbanken, 2 DB Homes für Full Rack

Weitere Informationen zum Premium/Platinum Service finden Sie hier: Oracle Platinum Services Support Policies [8] oder Oracle Website - Overview Platinum Services [9].

Seite 27/69

update

4.2.2 Oracle ASROracle ASR ist ein wesentlicher Bestandteil eines umfassenden Support-Konzeptes von Oracle ACS. ASR ist die Komponente, die Hardware-seitige Events eines proaktiven Monitorings zusammenfasst und an Oracle ACS weiterleitet. Dort findet die Analyse statt und von Oracle ACS wird der Oracle Field Support gesteuert. Nach Angaben von Oracle werden dadurch eine größtmögliche Verfügbarkeit sowie ein minimiertes Risiko sicher-gestellt.

Quelle: Oracle

Der Oracle ASR Manager sollte auf einem dedizierten Server unter Linux oder Solaris betrieben werden. Ne-ben Servern (CPU, Memory, System Boards, Stromversorgung sowie Lüfter) und Storage (Disk Controller, Dis-ks, Flash Karten und Flash Module) werden auch Netzwerkkomponenten (InfiniBand Module, Switches) über-wacht.

Weitere Details zur Installation und Konfiguration finden Sie hier: Oracle Auto Service Request Exadata Data-base Machine Quick Installation Guide [10].

Seite 28/69

update

4.2.3 Weitere Oracle ACS ServicesOracle Advanced Customer Support Services bietet Kunden ein gestaffeltes Set an Services, die sich nicht nur auf die Services während der Installation beschränken. Zudem lassen sie sich mit anderen Oracle Services kombinieren. Das Angebot des Herstellers erstreckt sich auch auf die Phase nach der Übergabe an das Ope-rations und umfasst Optimierungen, Monitoring und Support.

Nach Oracle Angaben werden die kostenpflichtigen, proaktiven Services von einem dedizierten Support Team erbracht. Dabei stellt Oracle sicher, dass Incidents sofort erkannt, unmittelbar vom Team aufgegriffen und mit Unterstützung der umfangreichen, Oracle-eigenen Knowledge Base schnellstmöglich gelöst werden. Wie be-reits erwähnt lässt sich der Premium/Platinum Support um Service Sets erweitern (beispielsweise “Oracle Exadata Start-up Pack“, “Oracle Solution Support Center” und “Oracle Advanced Monitoring and Resoluti-on”). Ergänzend bietet Oracle Consulting auch projektbezogene Services – wie zum Beispiel Oracle Migration Factory und Implementation Services.

Quelle: Oracle

4.2.3.1 OracleExadataStart-upPackOracle Exadata Start-up Pack ist ein Bündel von Services, die Oracle Advanced Customer Support Services gemeinsam mit Oracle Consulting anbietet. Ziel ist es, neben der Installation vor allem den Deployment-Pro-zess effektiv und schnell zu gestalten und eine hohe Qualität der installierten Systeme sicherzustellen.

Wesentliche Services:

• Advisory ServiceAssessments und Beratung auf der Basis von Best Practice-Lösungen im gesamten Deployment-Prozess;

• Installation and ConfigurationStandardisierte Systeminstallation und -konfiguration aller Komponenten;

Seite 29/69

update

• Production ReadinessTechnische Reviews und Anleitung durch Advanced Support Engineers, um Systeme optimal für die Pro-duktion vorzubereiten;

• Quarterly Patch ServiceProaktiver, vierteljährlicher Patch Service für ein Jahr (im Oracle Platinum Service bereits enthalten);

4.2.3.2 OracleSolutionSupportCenterEin Technischer Account Manager und ein Team „Advanced Support Engineers“ arbeiten entweder onsite oder remote eng mit dem Kunden und bieten damit einen 24/7 Support. Dieses dedizierte Team ist in die IT-Umgebung vor Ort eingearbeitet, kennt die Business-Anforderungen, wichtige Projekte, zentrale Technolo-gien sowie Betriebsanforderungen und -prozesse.

Wesentliche Services:• Kritische Fragen werden sofort an das Team über eine 24/7 Hotline weitergeleitet.• Das Team arbeitet eng mit Oracle Support und Produkt Development zusammen und kann auf diese Wei-

se Problemlösungen wesentlich beschleunigen und Wiederherstellungszeiten deutlich reduzieren. • Der Kunde erhält regelmäßig Feedback und Input zu Patch-Stand, Konfiguration und Performance-Fragen.

4.2.3.3 OracleAdvancedMonitoringandResolutionOracle Advanced Monitoring and Resolution Services bietet ein umfangreiches, integriertes Monitoring über die gesamte Umgebung und den IT-Stack – von der Applikation und der Datenbank bis hin zu Server, Storage und Netzwerkkomponenten. Oracle bietet hier proaktives Monitoring und liefert dem Kunden Lösungsansät-ze für Performance-Probleme.

Wesentliche Services:• Oracle verspricht, dass Incidents automatisch auf Basis einer über Jahrzehnte gewachsenen Knowledge

Base erkannt werden.• Nach Angaben von Oracle setzen Advanced Support Engineers spezielle Diagnose-Tools ein, um Störun-

gen schneller beheben und Root Causes innerhalb kurzer Zeit analysieren zu können. • Es werden regelmäßige Reviews der Umgebungen, einschließlich des Patch-Stands und der Konfiguration,

durchgeführt.

4.2.3.4 AdditionalServicesHierbei handelt es sich um individuelle Services für Installation und Konfiguration für Oracle Exadata und für Oracle Exadata Storage Expansion Rack.

Seite 30/69

update

4.3 Unterstützung von Oracle PartnernWelche Leistungen bringen Oracle Partner, und wie können sie im Life Cycle unterstützen?

Design Beratung und Unterstützung:

• PoC in der Planungsphase

• Design von Hochverfügbarkeit

• Integration in Backup-Infrastruktur

Installation Die Installation wird von Oracle ACS durchgeführt. Wie bereits beschrieben, sollten zur Instal-

lation wesentliche Standards und Namenskonventionen des Kunden berücksichtigt werden.

Hier ist die Unterstützung von Oracle ACS durch Berater, die die Umgebungen und die Stan-

dards des Kunden genau kennen, von Vorteil.

Migration Unterstützung durch Oracle Partner:

• Exadata wird immer mit dem neuesten Release-Stand installiert.

• Exadata ist ein x86-basiertes System.

• Exadata bietet viele Features, die es in dieser Form auf anderen Plattformen

nicht gibt. Auch wenn viele Anwendungen aufgrund leistungsstarker Hardware

performanter laufen, so zeigt die Erfahrung, dass durch einige Anpassungen und

Optimierungen der Performance-Gewinn deutlich höher ausfallen kann.

Weitere Informationen finden Sie in Kapitel „6 Optimierung im Life Cycle“.

Operations/Support • Exadata ist ein integriertes System. Für viele Kunden stellt sich die Frage, ob Ex-

adata in den Standard-Support integriert werden oder ob auf Angebote spezia-

lisierter Partner zurückgegriffen werden soll. Weitere Informationen finden Sie

in Kapitel „4 Exadata Operations“.

• Patch Management

Informationen hierzu finden Sie im folgenden Kapitel.

4.4 ExadataPatchManagement:MysteriumoderplanbarerService?Der folgende Abschnitt beschreibt das Exadata Patch Management und gibt einen Einblick in die wichtigsten Funktionen und Abhängigkeiten.

Eine stets aktuelle Übersicht über die verfügbaren Patches für Exadata inklusive eventuell kritischer Bugs findet sich bei MOS (My Oracle Support – ehemals „Metalink“) in der Note ID 888828.1, deren 14-tägige Lektüre dem Exadata DBA empfohlen wird.

Seite 31/69

update

4.4.1 Waswirdwannwodurchgepatcht?Zum besseren Verständnis des Patch Managements sollte man sich einen Überblick darüber verschaffen, welche Komponenten von Exadata wodurch und in welchen Abständen gepatcht werden. Dies ist in der fol-genden Tabelle aufgelistet:

Komponente Patch durch Patch-Zyklus Hängt ab von

Exadata PDU Separater Patch Bei Bedarf (bisher 1 Patch

in 3 Jahren)

-

Infiniband Switches Separater Patch Bei Bedarf (bisher 2 Patches

in 3 Jahren

-

Ethernet Switches Separater Patch Bei Bedarf (bisher kein

Patch

-

Exacheck Separater Patch Bei Bedarf (1-2x im Jahr) -

Exadata Cell Node

Exadata Compute Node

Cell Patch Ca. alle 3 Monate erscheint

eine neue Version der Cell

Software

-

Oracle Grid Infrastruktur Bundle Patch Alle 3 Monate zusammen

mit der Cell Software

Cell Patch

Oracle Datenbank Bundle Patch Alle 3 Monate zusammen

mit der Cell Software

Cell Patch und Grid

Infrastruktur

Wie zu sehen ist, werden die Stromversorgung und die Ethernet bzw. InfiniBand Switches relativ selten und nur bei Bedarf gepatcht. Dies erfolgt, sofern notwendig, im Rahmen einer neuen Cell Version.

Der Exacheck erscheint in regelmäßigen Abständen und sollte immer vor der Installation eines Patches auf Exadata gestartet und geprüft werden, um bekannte Probleme vor dem Patch zu beseitigen.

Der Patch der Exadata Cell und Compute Nodes erfolgt mittels der Cell Patches. Diese erscheinen im Rahmen der QDPE (Quarterly Database Patch for Exadata) etwa alle drei Monate und aktualisieren Folgendes auf den Cell und Compute Nodes:

• Das Betriebssystem inklusive der Packages;• Die Firmware aller Komponenten (z. B. BIOS, Firmware der HBAs, Firmware der Festplatten, etc.);• Einstellungen am/im Betriebssystem;

Seite 32/69

update

Die Installation des Cell Patch auf den Cell und Compute Nodes sollte regelmäßig und immer gleichzeitig auf den Cell und Compute Nodes erfolgen. Mindestens einmal im Jahr sollte eine aktuelle Version der Cell Soft-ware installiert werden, damit Updates auf neue Versionen ohne Zwischenschritte möglich sind.

Ein Mischbetrieb aus unterschiedlichen Cell Versionen während eines Rolling Upgrades ist möglich, sollte je-doch denkbar kurz gehalten werden. Dies hat den Hintergrund, dass Features durch neue Cell Versionen eventuell erst nach vollständiger Durchführung des Patch genutzt werden können.

Die nächste Komponente im Software Stack ist die Grid Infrastruktur, welche die Grundlage für alle weiteren Services bildet. Die Grid Infrastruktur (GI) wird mittels sogenannter Bundle Patches aktualisiert. Die Bundle Patches sind kummulativ (d. h. es reicht die Installation des aktuellen Bundle Patch, um parallel die Fehlerbe-hebungen aller vorgehender Patches zu installieren). Sie erscheinen ca. alle drei Monate zusammen mit einer neuen Version der Software für die Cell und Compute Nodes. Für die Installation der Bundle Patches wird eine Mindestversion auf den Cell und den Compute Nodes vorausgesetzt, sodass eine regelmäßige Aktualisierung sinnvoll ist. Die mindestens benötigte Version reicht aus Erfahrung mindestens ein Jahr zurück, sodass Cell Versionen mit einem Alter von einem Jahr als Voraussetzung für die Installation des Bundle Patch ausreichen. Sollen die Patches allerdings „rolling“ eingespielt werden, dürfen die Versionen nicht so weit zurückreichen wie bei Non-Rolling Installationen.

Die Datenbank arbeitet unmittelbar auf die Grid Infrastruktur aufbauend. Sie wird analog der Grid Infrastruk-tur mit den quartalsweise erscheinenden Bundle Patches gepatcht.

Zum Patchen der einzelnen Komponenten kommen unterschiedliche Tools zum Einsatz. Diese sind in der fol-genden Tabelle aufgelistet:

Komponente Software Tool

Cell Node Cell Patch patchmgr

Compute Node Cell Patch dbnodeuopgrade.sh (siehe MOS Note

1473002.1) bzw. YUM in älteren Versi-

onen

Grid Infrastruktur Datenbank Bundle Patch OPatch

Grid Infrastruktur Datenbank Minor oder Major Release (z. B.

11.2.0.2 → 11.2.0.3 oder 11.2 →

12.1)

Switch und PDU Separate Patches ILOM

Seite 33/69

update

4.4.2 Bundle Patch, PSU, CPU, QDPE und QFSDPIm Laufe der Zeit hat Oracle eine Vielzahl von Begriffen entwickelt, die die Patches beschreiben (unter Ande-rem „Bundle Patch“, „PSU“, „CPU“, „QDPE“ und „QFSDP“). Die folgende Tabelle ordnet und systematisiert die Begriffe:

Patch-Typ Für System Für Komponente Erscheinungsintervall Bemerkung

CPU Non-Exadata Grid Infrastruktur Datenbank Ca. alle 3 Monate -

PSU Non-Exadata Grid Infrastruktur Datenbank Ca. alle 3 Monate Enthält die CPU

Bundle Patch (BP) Exadata Grid Infrastruktur Datenbank Ca. alle 3 Monate Enthält die PSU (und damit

implizit die CPU)

Quarterly Databa-

se Patch for

Exadata (QDPE)

Exadata Cell Nodes

Compute Nodes

Grid Infrastruktur

Ca. alle 3 Monate Enthält die aktuelle Version

der Cell Software (für die

Cell und Compute Nodes)

sowie den aktuellen Bundle

Patch (inkl. PSU und CPU)

Quarterly Full Stack

Download Patch

(QFSDP)

Exadata (PSU und Switches, sofern

notwendig)

Cell Nodes

Compute Nodes

Grid Infrastruktur Datenbank

Ca. alle 3 Monate Enthält nicht nur Patches,

sondern die komplette

Software (inkl. Installation

Binaries)

Wie man sieht, stammen die Begriffe PSU und CPU aus der Non-Exadata Welt und beschreiben Patches für sicherheitsrelevante Probleme (CPU) oder sicherheits- und betriebskritische Probleme (PSU).

Die oben diskutierten PSUs fließen – ergänzt um Fehlerbereinigungen für Exadata-spezifische Themen – in die Bundle Patches ein, mit denen die Grid Infrastruktur und die Datenbank gepatcht wird. Diese wiederum sind Bestandteil der quartalsweise erscheinenden Quarterly Database Patches for Exadata (QDPE).

Für den Fall einer kompletten Neuinstallation stellt Oracle mit dem Quarterly Full Stack Download Patch (QFS-DP) eine Möglichkeit zur Verfügung, das System inklusive aller bisher erschienenen Updates zu installieren. So kann vermieden werden, dass der Basisinstallation ein sehr aufwändiger Patch-Zyklus folgt.

In der zuvor erwähnten MOS Note 888828.1 finden sich Hinweise auf zwischenzeitlich entdeckte, kritische Bugs und deren Workarounds – bzw. Patches, die unter Umständen eine außerplanmäßige Patch-Installation benötigen.

Seite 34/69

update

4.4.3 ZeitaufwandfürdenPatch-VorgangDer für das Patchen des Systems notwendige Zeitaufwand wird durch folgende zwei Kernaspekte bestimmt:

1. Soll die Installation „Rolling“ oder „Non-Rolling“ erfolgen?2. Ist ein Upgrade der Grid Infrastruktur und/oder der Datenbank gewünscht (z. B. von Version 11.2.0.2 →

11.2.0.3 oder 11.2 → 12.1)?

Die Frage nach den Upgrades stellt sich bei Minor Upgrades nur etwa einmal in 18 bis 24 Monaten (wie z. B. von 11.2.0.2 → 11.2.0.3) bzw. bei Major Upgrades etwa einmal in drei Jahren (11 → 12). Auch hierbei ist ein Vorgehen nahezu ohne Downtime möglich. Dies erfordert allerdings sehr erfahrende DBAs und eine intensi-ve Vorbereitungsphase.

Der in der Praxis weitaus häufigere Fall ist die Installation planmäßiger Updates, die etwa alle drei Monate stattfinden können – wenn man dem Patch-Zyklus von Oracle folgt. Diese Updates sind fast immer sowohl Rolling als auch Non-Rolling installierbar.

Die folgende Tabelle gibt Richtwerte für die zu erwartende Installationsdauer an (abhängig vom gewählten Verfahren), inkludiert jedoch keinen Puffer zum Finden und Beheben etwaiger Probleme:

Non-Rolling (Full Downtime)

Komponente Aufwand in Stunden Abhängig von Bemerkung

Cell Node 4 Stunden für alle Cell Nodes - Cell Nodes werden Non-

Rolling parallel gepatcht;

Compute Nodes 4 Stunden für alle Compute Nodes Patch der Cell Nodes Paralleles Patchen möglich;

Danach Parallelisierung durch

den DBA notwendig;

Grid Infrastruktur auf dem

jeweiligen Compute Node

4 Stunden für alle Compute Nodes Patch der Cell und

Compute Nodes

Paralleles Patchen möglich;

Danach Parallelisierung durch

den DBA notwendig;

Datenbank auf dem

jeweiligen Compute Node

IN-PLACE

2 Stunden für alle Compute Nodes Patch der Cell und

Compute Nodes sowie

der Grid Infrastruktur

Paralleles Patchen möglich;

Danach Parallelisierung durch

den DBA notwendig;

Seite 35/69

update

Datenbank auf dem

jeweiligen Compute Node

OUT-OF-PLACE

Keine Zeit während des Patch

benötigt, da der Patch komplett

vorbereitet werden kann;

Anschließend Zeit für das Entfer-

nen alter Binaries notwendig;

- Nach dem Patch Zeit für das

Entfernen alter Binaries

notwendig;

Datenbank

(Data Dictionary)

30 Minuten pro Datenbank für das

Einspielen geänderter Objekte plus

Zeit zur Rekompilation (hängt von

der Anzahl der Objekte ab)

Patch der Cell und

Compute Nodes sowie

der Grid Infrastruktur

und Datenbank-Binari-

es

Rolling (Minimale bis keine Downtime)

Komponente Aufwand in Stunden Abhängig von Bemerkung

Cell Node

Je nach Redundanz der Disk Group

zwischen 0-24 Stunden

- -

4 Stunden pro Cell Node - Wenn Platz vorhanden ist, kann

ggf. mehr als eine Cell Node

gleichzeitig entfernt werden und

so die Anzahl der Patch-Zyklen

verringert werden.

Compute Nodes 4 Stunden pro Compute Node Kann parallel zum Patch

der Cell Nodes erfolgen

Paralleles Patchen möglich;

Danach Parallelisierung durch

den DBA notwendig;

Grid Infrastruktur

auf dem jeweiligen

Compute Node

2 Stunden pro Compute Node Patch der Cell und

Compute Nodes

Paralleles Patchen möglich;

Danach Parallelisierung durch

den DBA notwendig:

Datenbank auf dem

jeweiligen Compute

Node IN-PLACE

1 Stunde für alle Compute Nodes Patch der Cell und

Compute Nodes sowie

der Grid Infrastruktur

Paralleles Patchen möglich;

Danach Parallelisierung durch

den DBA notwendig;

Datenbank auf dem

jeweiligen Compute

Node OUT-OF-PLA-

CE

Keine Zeit während des Patch benötigt,

da der Patch komplett vorbereitet

werden kann;

Anschließend Zeit für das Entfernen

alter Binaries notwendig;

- Nach dem Patch Zeit für das

Entfernen alter Binaries

notwendig;

Datenbank (Data

Dictionary)

30 Minuten pro Datenbank für das

Einspielen geänderter Objekte plus

Zeit zur Rekompilation (hängt von der

Anzahl der Objekte ab)

Patch der Cell und

Compute Nodes sowie

der Grid Infrastruktur

und Datenbank-Binaries

-

Seite 36/69

update

4.4.3.1 RollingPatch-InstallationBei der Rolling Patch-Installation werden immer nur einzelne Komponenten zum Update abgeschaltet und nach erfolgter Installation wieder aktiviert. Im Normallfall ist das Gesamtsystem verfügbar – wenn auch mit verminderter Leistungsfähigkeit – und kann durch die Anwender/Applikationen genutzt werden. Damit eine Installation Rolling erfolgen kann, müssen bestimmte Patches erfolgreich installiert worden sein. Die Details variieren von Version zu Version und werden immer der jeweiligen Dokumentation entnommen.Das „Rolling“ Verfahren kann für annähernd alle Patch-Aktivitäten der Komponenten genutzt werden:

• Cell Nodes• Compute Nodes• Grid Infrastruktur• Datenbank

Die einzige Ausnahme sind notwendige Code-Anpassungen durch geänderte, interne Datenbank-Packages, die eine Rekompilation bestimmter Datenbankobjekte erfordern.

Bei einem Rolling Patch wird die längste Zeit durch das (eventuell) notwendige Rebalance im ASM vor dem Patch und durch das Entfernen eines Cell Nodes aus dem ASM in Anspruch genommen. Ein Patch-Vorgang kann zwei bis vier Stunden dauern.

Bei NORMAL Redundancy sind die Daten doppelt auf verschiedenen Cell Nodes vorhanden. Wird nun eine Cell Node ohne vorheriges „sauberes“ Entfernen aus dem ASM (bei dem die Daten auf den Cell Node Festplat-ten auf alle verbleibenden Cell Nodes verteilt werden) abgeschaltet, so sind bestimmte Daten nur noch ein-mal vorhanden. Fällt nun während des Patch-Vorgangs eine weitere Festplatte aus einer Cell Node aus, so entsteht in jedem Fall Datenverlust. Aus diesem Grund wird empfohlen, bei Disk Groups mit NORMAL Redun-anz die Cell Node vor Beginn aus dem ASM zu droppen und das Rebalance (die Verteilung der Daten der zu patchenden Cell Node auf die verbleibenden Cell Nodes) vollständig abzuwarten. Dies kann – je nach Umfang der gespeicherten Daten und Größe der einzelnen Festplatte – zwischen sechs und zwölf Stunden (High Speed Festplatten) bzw. sechs und 24 Stunden (High Capacity Festplatten) dauern (PRO Cell Node). Die Installation des Patch auf der einzelnen/mehreren Cell Node/-s dauert ca. vier Stunden.

Seite 37/69

update

Anders sieht es hingegen bei Disk Groups mit HIGH Redundanz aus. Hier sind nach dem Abschalten einer Cell Node noch zwei Kopien der Daten vorhanden, sodass ein Ausfall einer Festplatte auf einer der verbleibenden Cell Nodes nicht zum Verlust der Disk Group führt.

Der Patch der einzelnen Compute Nodes ist unabhängig vom Modell und der Anzahl der Datenbanken. Er dauert zwischen zwei und vier Stunden. Voraussetzung ist, dass die auf dem Knoten laufenden Komponenten (wie Instanz oder Applikation) auf einem anderen als dem zu patchenden Knoten verfügbar sind. Der Patch des Compute Node kann, um Zeit zu sparen, parallel zu dem bereits laufenden Patch der Cell Node(s) erfol-gen.

Unmittelbar nach dem Update des Compute Node sollte der Patch von Grid Infrastruktur und Datenbank-Bi-naries erfolgen. Erst im Anschluss sollte der Compute Node dem Cluster wieder hinzugefügt und mit dem nächsten Compute Node fortgefahren werden.

Die Datenbank-Binaries können wahlweise In-Place oder Out-of-Place gepatcht werden. In-Place meint, dass die vorhandenen Binaries gepatcht werden. Out-of-Place bedeutet, dass vorab parallel neue Binaries instal-liert werden, die anschließend gepatcht werden. Anschließend wird die Datenbankinstanz mit den neuen Bi-naries gestartet.

Der Vorteil bei Out-of-Place liegt in der Zeitersparnis – insbesondere wenn statt „Rolling“ mit einer komplet-ten Downtime gepatcht wird. Das liegt daran, dass die Datenbank-Binaries im Vorfeld vorbereitet werden können und der Vorgang schneller abläuft. Allerdings ist der Gesamtzeitaufwand größer, da in der Vorarbeit die neuen Binaries ausgerollt und nach dem Patch die alten Binaries wieder entfernt werden müssen.

4.4.3.2 Non-RollingPatch-InstallationDieses Verfahren eignet sich insbesondere, wenn über eine Standby oder replizierte Datenbank (z. B. mittels Data Guard oder Golden Gate) die weitere Verfügbarkeit der Datenbank sichergestellt ist und das Zeitfenster für die Installation der Patches so kurz wie möglich sein soll. Steht keine Standby Datenbank zur Verfügung, so ist das Non-Rolling-Verfahren dennoch das Verfahren mit der kürzesten Zeit für die Installation – aber auch das Verfahren mit der längsten Downtime.

Seite 38/69

update

4.4.4 Patch-ZykleninderPraxisAus der Erfahrung heraus ist die nicht hinterfragte Installation aller verfügbaren Patches genauso unvorteil-haft wie gar keine Installation von Patches.

Die folgende Tabelle zeigt einen in der Praxis bewährten Patch-Zyklus bei dem einmal jährlich die Cell und Compute Nodes und etwa alle sechs bis zwölf Monate die Grid Infrastruktur und Datenbank gepatcht werden.

Patch-Zyklus Geplante Maintenance

6-12 Monate Grid Infrastruktur/Database

12 Monate Cell und Compute Nodes

2-4 Jahre Grid Infrastruktur/Datenbank Major Release (11.2.0.2 → 11.2.0.3 oder 11.2 → 12.1)

Die Patch-Häufigkeit der Datenbank und Grid Infrastruktur hängt hierbei maßgeblich von zwei Komponenten ab:1. Stabilität der Datenbank und Verfügbarkeit etwaig benötigter One-Offs2. Bekannte Sicherheitslücken

Ist die auf der Datenbank laufende Anwendung stabil (d. h. es treten keine Datenkorruptionen und -verluste, ungeplante Abstürze oder falsche Ergebnisse auf), kann ein Patch-Zyklus von zwölf Monaten ausreichend sein. Sind allerdings schwerwiegende, die Anwendung einschränkende Probleme in aktuellen Bundle Patches gelöst und Backports in Form von One-Offs nicht verfügbar, so sollte ein kürzerer Patch-Zyklus gewählt wer-den.

Bei der Nutzung des Platinum Service gelten ebenfalls kürzere Patch-Zyklen. Hier ist auf die Konformität mit den empfohlenen Versionen laut MOS Note 888828.1 zu achten, da andernfalls der Premium Support erlö-schen kann.

Das gleiche Vorgehen gilt für bekannte Sicherheitslücken. Diese sollten je nach Schwere und Kritikalität beur-teilt und entsprechend ihrer Wichtigkeit durch die Installation aktueller Bundle Patches geschlossen werden.Ein Upgrade der Datenbankversion ist jeweils nach zwei bis vier Jahren notwendig – spätestens jedoch, wenn der Support ausgelaufen oder die aktuell eingesetzte Version mehr als eine Version hinter der derzeitig aktu-ellen Version hinterherhängt.

Beispiel: Derzeit ist die Version 11.2.0.4 aktuell. Die Version 11.2.0.3 und 11.2.0.4 erhalten im Rahmen des Supports von Oracle Updates. Die Version 11.2.0.2 liegt mehr als eine Version zurück und erhält keine Up-dates mehr. Kunden mit 11.2.0.2 sollten also daher entweder auf 11.2.0.3 oder (besser) auf 11.2.0.4 upgra-den.

Seite 39/69

update

4.4.5 EmpfehlungenfürdieerfolgreichePatch-InstallationDer folgende Abschnitt listet in stichpunktartiger Form Tipps für eine erfolgreiche Patch-Installation auf – ohne Anspruch auf Vollständigkeit:

• Generelle Empfehlungen* Einsatz des Exacheck Tools (MOS Note: 1070954.1)

- Verwendung der aktuellen Version - Warnings und Alerts des Tools vor dem Patchen beheben

* Einsatz von OPlan (Installationsschritte besser verstehen)* Dokumentation und MOS Notes vorab intensiv durcharbeiten* Möglichst Standby oder Testsystem vor Primary oder Produktion patchen

• Exadata Storage Server* Keine unsupporteten Changes vornehmen* Keine zusätzliche Software installieren

• Grid Infrastructure* Software Release sollte mindestens „gleich“ wie (besser: höher als) Database sein, so dass GI >= DB

Release

• Database Software* Empfehlung: Out-of Place patchen* Installation von One-Offs als “Online Patch”* Management der Last mittels Services

Seite 40/69

update

5 Management-&SupportTools

Neben den bekannten Oracle Werkzeugen ist der Enterprise Manager Cloud Control das wichtigste Werkzeug zum Management und Monitoring der Plattform (unabhängig davon, ob Einzelsysteme/Vielzahl von Syste-men/OLTP System/DWH/Konsolidierungsplattform). Daneben gibt es einige neue Tools, die ausschließlich im Umfeld von Exadata eingesetzt werden. Hierzu zählen:

• Auto Service Request (ASR)SRs werden für HW Defekte automatisch generiert und an Oracle gesendet. Hierzu gehören: CPU, Disk Controller und Disks, Flash Karten und Module, InfiniBand, Karten, Memory, System Boards, Stromversorgung sowie Lüfter;

• Command Line Interface (CLI)Zur lokalen Steuerung der Exadata Storage Server;

• Distributed Command Line Interface (DCLI)Zur gleichzeitigen Ausführung auf mehreren Cell Nodes;

• Integrated Lights Out Manager (ILOM)Zur remote Überwachung und Steuerung der Hardware;

In der folgenden Tabelle finden Sie einen Überblick zu Aufgaben und Standard-Tools.

Provisioning Configuration Monitoring Patching Backup

Database EM EM EM EM EM/RMAN

Grid EM EM EM EM/RMAN

ASM EM EM EM n/a

Compute Node EM EM OC z. B. TSM

Storage Cell EM EM CL n/a

InfiniBand Switch EM EM CL n/a

Seite 41/69

update

5.1 Provsioning/Rapid Provsioning

5.1.1 ProvisioningFür das Provisioning neuer Datenbanken ist der Oracle Enterprise Manager zu empfehlen. Das Verfahren un-terscheidet sich nicht von anderen RAC Datenbanken. Folgende Modelle werden unterschieden und durch den Enterprise Manager unterstützt: Database Machine, Database Instance und Database Schema.

Vor- und Nachteile dieser Modelle:

Database Machine

(Dedizierte VM/IaaS)

Database Instance

(Dedizierte DB/DBaaS)

Database Schema

(Dediziertes Schema/SaaS)

Implementierung/

Onboarding

Einfach Einfach Aufwändig (Standardisie-

rung, Versionen)

Wartung Komplex Einfach Komplex

Isolation Hoch Mittel Gering

Grad der Konsolidierung Gering Mittel Hoch

ROI Gering (Server-Ebene) Hoch (Server, OS) Sehr hoch (Server, OS,

Datenbank)

Insbesondere da, wo Exadata als Konsolidierungsplattform eingesetzt werden soll, sind die Features des Enterprise Managers für das Rapid Provisioning gefragt (bis hin zum Self-Provisioning).

5.1.2 Rapid ProvisioningStandard Provisioning, wie heute noch in vielen Unternehmen praktiziert, weist eine Reihe von Nachteilen auf. Zeitraubende Prozesse, die über verschiedene Abteilungen etabliert sind, müssen koordiniert werden, wodurch das Transition Management aufwändig wird. Dies macht den Gesamtprozess einschließlich Life Cyc-le Management personalaufwändig und teuer. Rapid Provisioning auf der Exadata Plattform bietet zahlreiche Vorteile:

• Benötigte Ressourcen stehen bereit (im Rahmen der Quotas);• Provisioning in wenigen Stunden;• Automatisierter Prozess, der kaum manuelle Ressourcen benötigt;• Hohes Maß an Standardisierung;

Seite 42/69

update

Die technische Umsetzung des Provisioning kann mit den Methoden RMAN Clone und Snap Clone erfolgen.

DBaaS Snap Clone:• Provisioning großer Datenbanken in wenigen Minuten;• Derzeit unterstützt: NAS Netapp, ZFS (EMC, HDS geplant);• Features

* Storage Technology;* „Use and throw“-Datenbanken (UAT, Zeitreisen), kurzlebige Datenbanken;* Voll integriert in 12c CC Life Cycle Management;

• Vorteile* Spart Speicherplatz, da nur der Platz für die Deltas benötigt wird (copy-on-write Snapshot), wenige

Megabyte für eine 1 TB DB;* Da das Snapshot nur aus Zeigern besteht, müssen lediglich die Zeiger ersetzt werden. Cloning 1 TB

DB in wenigen Minuten;

DBaaS RMAN Clone:• Provisioning via RMAN Clone;• Derzeit unterstützt: Alle Plattformen und Storage-Typen;• Features

* Oracle Technology;* Datenbanken mit längerem Lebenszyklus;* Voll integriert in 12c CC Life Cycle Management;

• Vorteile* Storage-neutral;* Passt in die existierende Infrastruktur;

Seite 43/69

update

Self-Service Provisioning mit dem EM 12c:

• Out-of-the-box Konsole, kann angepasst werden, API

• Provisioning: PaaS, DBaaS

• Clone-Methoden: RMAN Clone (copy-on-write), Snap Clone, Schema Export

• Integriert: Monitoring, Backup, Patching

• Self Service-Benutzer bekommt einen Service-Katalog präsentiert

• Ist in den kompletten CC Life Cycle eingebunden

• Self Service-Benutzer können

* Datenbanken starten und stoppen;

* Backup- und Restore-Operationen durchführen;

* wichtige Metriken überwachen;

* den Retirement-Prozess anstoßen;

Seite 44/69

update

5.2 KonfigurationDetails finden Sie in Kapitel „3 Installation und Migration“ sowie „8 Appendix - Exadata Deployment Assistant Step by Step“.

5.3 MonitoringDas Exadata System stellt als „Engineered System“ besondere Anforderungen an das Monitoring. Die Verfüg-barkeit kann nur garantiert werden, wenn alle Hardware- und Software-Komponenten in das Monitoring einbezogen werden. Nur im Oracle Enterprise Manager können alle Komponenten als Target definiert und mit Metriken versehen werden. Das Einbinden erfolgt mit Hilfe eines definierten Discovery-Prozesses. Weitere Informationen finden Sie hier: Oracle Enterprise Manager 12c: Oracle Exadata Discovery Cookbook [11].

Bevor der Discovery-Prozess beginnen kann, sollte eine Überprüfung erfolgen. Dafür stellt Oracle im Web nach Anmeldung folgendes Skript zur Verfügung: $ORACLE_HOME/perl/bin/perl exadataDiscoveryPreCheck.pl.

Ist der Agent installiert, kann der Discovery-Prozess über die Konsole des Enterprise Manager beginnen. Dies

erfolgt über die Menüpunkte „Add Targets“ und „Add Targets Manually“.

Seite 45/69

update

Jetzt können für die Kom-

ponenten die einzelnen

Metriken definiert und

die Schwellwerte für das

Monitoring gesetzt wer-

den. Zum Abschluss er-

folgt die Aufnahme der

Software-Komponenten

wie Cluster, Cluster-Da-

tenbank, Listener und

ASM. Dieser Vorgang ist

identisch zum normalen

Target Discovery für

Oracle Real Application

Clusters.

Über offene Schnittstel-

len können SNMP-Traps

zu anderen Monito-

ring-Systemen geschickt

werden.

Nachdem die Hosts als

Target aufgenommen

wurden, wird das „Oracle

Enterprise Manager Se-

tup Automation Kit for

Exadata“ installiert. An-

schließend erfolgt ein ge-

führter Discovery-Prozess

über die Konsole des

Enterprise Manager. Am

Ende des Prozesses sind

alle Targets im Enterprise

Manager verfügbar.

Seite 46/69

update

5.4 PatchingObwohl das Patchen einzelner Software-Komponenten über den Enterprise Manager möglich ist, zeigt die praktische Erfahrung, dass die Steuerung über die Kommandozeile mehr Transparenz und Sicherheit bietet. Das liegt nicht zuletzt an den Abhängigkeiten der einzelnen Komponenten und Versionen untereinander so-wie der zur Verfügung gestellten Utilites.

Weitere Informationen finden Sie in Kapitel „4.4 Exadata Patch Management: Mysterium oder planbarer Ser-vice?“.

6 OptimierungimLifeCycle

Exadata verfügt über zahlreiche Features, die die extreme Performance begründen. Zu diesen Technologien gehören vor allem der Intelligente Storage, PCI Flash Cache sowie die (E)HCC ((Exadata) Hybrid Columnar Compression). Viele dieser Features werden nach der Migration auf Exadata automatisch benutzt. Andere benötigen eine Anpassung der Applikation auf die Plattform als solche.

Direkt nutzbar sind folgende Features:• (Teilweise) Cell Offloading und damit Features wie zum Beispiel:

* Column Projection* Predicate Filtering* Storage Indices

• Flash Cache

Optimierungen bzw. Anpassungen an der Applikation zur vollen Nutzung der Möglichkeiten der Plattform erfordern die folgenden Features:• Cell Offloading

* Storage Indices* Predicate Filtering

• Parallelisierung• Hybrid Columnar Compression (HCC)• Flash Cache

Seite 47/69

update

Einige der Features wurden doppelt aufgezählt. Dies liegt daran, dass diese ohne Optimierungen per Default aktiv sind, aber ihr Potential nicht voll ausschöpfen können.

Ein Beispiel für notwendige Optimierungen ist zum Beispiel der Flash Cache: Dieser ist per Default aktiv und versucht häufig benutzte Daten im schnellen Flash Speicher zu cachen und dient quasi als Erweiterung des Database Buffer Cache. Durch Setzen spezieller Attribute an den Tabellen kann man das Cachen von Objekten im Flash Cache gezielt steuern, um so die Performance zu optimieren.

Bei dem Cell Offloading und insbesondere bei der effizienten Nutzung von Storage Indices hingegen sind An-passungen der Applikation notwendig. Exadata ist allein durch die Storage Indices und das Cell Offloading bereits in der Lage, einen sehr schnellen Datenzugriff zu gewährleisten. Daher sollte geprüft werden, wie sich die Ausführungspläne der Statements verändern, wenn man die zum schnellen Datenzugriff notwendigen Indices der Non-Exadata Systeme entfernt. Ähnlich verhält es sich mit der Parallelisierung, die wesentlich zur Performance-Steigerung beiträgt.

Die Key Features von Exadata sollen im folgenden Abschnitt kurz vorgestellt und erklärt werden.

6.1 CellOffloading/SmartScanningUnter dem Begriff Cell Offloading oder auch Smart Scanning werden eine Menge von Technologien subsum-miert. Smart Scanning bezieht sich dabei mehr auf die Optimierung von SQL Statements durch Exadata, wäh-rend Cell Offloading eher ein generischer Begriff ist. All diese Technologien haben jedoch den Zweck, die Ar-beit von der Datenbank weg und hin zum Storage (der Zelle) zu verlagern. So soll bereits auf dem Storage die Anzahl der in Betracht kommenden Datensätze minimiert werden. Das Ziel ist, möglichst wenige Datensätze und Spalten zur Weiterverarbeitung zur Datenbank zu übertragen und/oder notwendige Arbeitsschritte gleich durch die Cell Node erledigen zu lassen.

Unter dem Oberbegriff Cell Offloading werden folgende Technologien zusammengefasst:• Column Projection• Predicate Filtering• Storage Indices• Bloom Filter• Function Offloading• Kompression/Dekompression• Ver-/Entschlüsselung• Virtual Columns

Seite 48/69

update

6.1.1 Storage Index

Das folgende Beispiel soll dies kurz anhand eines Selects auf eine große Tabelle ohne Indices zeigen:

Storage Index ausgeschaltet

SQL> ALTER SYSTEM SET „_KCFIS_STORAGEIDX_DISABLED“=TRUE;

System altered.

Elapsed: 00:00:00:20

SQL> SELECT COUNT(SPALTE1) FROM GROSSE_TABELLE WHERE SPALTE1=0;

COUNT(SPALTE1)

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

2

Elapsed: 00:00:10:00

Der Storage Index dient der Vermeidung

überflüssiger I/Os. Er befindet sich im

Memory einer jeden Zelle, wird automa-

tisch gepflegt, ist transparent für die Da-

tenbank und funktioniert bei kompri-

mierten und nicht komprimierten

Tabellen. Da die Storage Indices nur im

Arbeitsspeicher gehalten werden, müs-

sen sie bei jedem Restart einer Zelle neu

aufgebaut werden.

Storage Indices können die zur Ausfüh-

rung der Abfrage benötigten IOs we-

sentlich reduzieren, da nur die Blöcke

gelesen werden müssen, die die anfragten Werte enthalten. In Verbindung mit Column Projection und Prodicate

Filtering wird anschließend das zu lesende und zum Compute Node zu übertragende Datenvolumen weiter re-

duziert. Hierdurch minimiert sich die Arbeit auf den Cell Nodes und auf dem Compute Node (wo die Datenbank

läuft) erheblich. Durch diese Strategie können zum Beispiel FULL TABLE SCANs, die auf Non-Exadata Systemen

sehr lange Zeit laufen, auch ohne Indices sehr schnell Ergebnisse liefern.

Quelle: Oracle

Seite 49/69

update

Exadata benötigt ca. 10 Sekunden um das Ergebnis zu liefern – trotz aktiviertem Predicate Offloading und Column Projection (siehe unten). Ohne diese beiden Features würde die benötigte Zeit noch um ein Vielfa-ches größer sein, da alle Daten und Spalten von der Zelle zur Datenbank übertragen werden müssten.

Um die Auswirkung von Storage Indices zu zeigen, werden diese nun wieder aktiviert:

SQL> ALTER SYSTEM SET „_KCFIS_STORAGEIDX_DISABLED“=FALSE;

System altered.

Elapsed: 00:00:00:15

SQL> SELECT COUNT(SPALTE1) FROM GROSSE_TABELLE WHERE SPALTE1=0;

COUNT(SPALTE1)

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

2

Elapsed: 00:00:00:05

Durch die Nutzung von Storage Indices hat sich die Verarbeitungszeit für das Select-Statement von zehn Se-kunden auf fünf Millisekunden reduziert – ohne einen klassischen Index anzulegen.

6.1.2 ColumnProjectionBei der Column Projection werden zur Datenbank nur die Spalten zurückgeliefert, die auch wirklich durch die Abfrage oder die Join-Bedingung angefragt werden. Das Ergebnis: Die Ausführungszeit der Abfrage wird um mehr als 50% reduziert. Beispiel: Es werden lediglich fünf Spalten einer Tabelle mit 100 Spalten abgefragt. In Folge reduziert sich das übertragene Datenvolumen auf ca. fünf Prozent.

Um dies zu demonstrieren, erstellen wir eine Tabelle mit ca. 250 Millionen Zeilen und fragen diese ab:

SQL> alter session set cell_offload_processing=FALSE;

Session altered.

Elapsed: 00:00:00:01

SQL> COUNT(SPALTE1) FROM GROSSE_TABELLE

COUNT(SPALTE1)

--------

250000000

Elapsed: 00:00:38:03

Seite 50/69

update

SQL> alter session set cell_offload_processing=TRUE;

Session altered.

Elapsed: 00:00:00:01

SQL> COUNT(SPALTE1) FROM GROSSE_TABELLE

COUNT(SPALTE1)

--------

250000000

Elapsed: 00:00:22:55

Das Beispiel zeigt, dass sich durch die Nutzung von Column Projection bereits erhebliche Geschwindigkeits-vorteile ergeben, da weniger Daten zwischen Compute Nodes und Cell Nodes übertragen werden müssen.

6.1.3 Predicate FilteringBei der Technologie des Predicate Filtering werden zum Compute Node und damit zur Datenbank nur die Zeilen zurückgegeben, die auch der Abfrage entsprechen. Hierdurch wird die Datenmenge, die durch die Da-tenbank bearbeitet und zur Datenbank übertragen werden muss, deutlich reduziert. Bei Non-Exadata Syste-men werden stets alle Zeilen übertragen und anschließend durch die Datenbank gefiltert. Dieser Schritt er-folgt bei Exadata zum großen Teil bereits auf den Zellen.

SQL> alter system set “_kcfis_storageidx_disabled”=true;

Session altered.

SQL> COUNT(SPALTE1) FROM GROSSE_TABELLE WHERE SPALTE1=0;

COUNT(SPALTE1)

--------

250000000

Elapsed: 00:00:04:48

Diese Abfrage zeigt, wie effizient Exadata Abfragen durch Predicate Filtering bearbeiten kann. Um sicherzuge-hen, dass die Storage Indices sich nicht positiv auswirken, wurden diese vorher abgeschaltet. Die resultieren-de Laufzeit ist einzig das Ergebnis von Column Projection und Predicate Filering.

Seite 51/69

update

6.2 HCC (Hybrid Columnar Compression) ArchitectureDie Hybrid Columnar Compression (HCC) war ursprünglich unter dem Namen EHCC den Exadata Systemen vorbehalten und beschreibt eine spaltenweise Komprimierung der Daten. Durch die Wahl der spalten- statt zeilenweisen Kompression erreicht Exadata Kompressionsfaktoren von 1:5 bis ca. 1:15.

HCC eignet sich allerdings nur für statische Daten, da Änderungen an HCC-komprimierten Daten die betref-fenden Zeilen wieder entkomprimieren. Außerdem müssen die Daten für die Kompression mittels HCC „Di-rect Path“ geladen werden (also via „Create Table as Select“, „INSERT /*APPEND */“, dem SQL Loader oder Ähnlichem).

Aufgrund der Architektur von Exadata werden die Daten auf den Compute Nodes komprimiert – können aber auf den Cell Nodes entkomprimiert werden. So wird die Rechenlast von den Compute Nodes zu den Cell No-des verschoben. Für reines Filering müssen die Daten nicht entkomprimiert werden. Nur bei Rückgabe zur Datenbank in Form eines Rowsets ist dies notwendig.

Zu beachten ist, dass HCC nur auf Exadata, ZFS-Appliances und Pillarstore-Systemen von Oracle unterstützt wird.

Komprimiert man mehrere

„gleichartige“ Records, er-

gibt sich ein besserer Kom-

pressionsfaktor als bei zei-

lenweiser Vorgehensweise

(ein ständiger Wechsel von

Text und Zahl lässt sich nicht

gut komprimieren). Außer-

dem findet die Komprimie-

rung bei HCC in größeren

Einheiten als einem Block

(8-32 KB) statt. Auch hier-

durch wird die Komprimie-

rungsrate erhöht.

Quelle: Oracle

Seite 52/69

update

Bei HCC werden die zu kompri-

mierenden Daten in soge-

nannte Compression Units zu

je 1 MB unterteilt und an-

schließend spaltenweise kom-

primiert.

Quelle: Oracle

Wie bereits beschrieben, gibt es verschiedene Kompressionsverfahren bei der HCC, welche in der folgenden Tabelle aufgeführt sind. Je nach gewähltem Kompressionslevel kommen unterschiedliche Kompressionsver-fahren zum Einsatz. In der Praxis wird häufig mit ARCHIVE LOW bzw. QUERY HIGH der beste Kompromiss aus Kompressionsrate und Geschwindigkeit gefunden. Dies ist jedoch abhängig von den Daten. Häufig sind Abfra-gen auf komprimierte Daten sogar schneller als solche auf unkomprimierte Daten. ARCHIVE HIGH wird hinge-gen nur eingesetzt, wenn Daten möglichst lange aufbewahrt werden, da die Kompression der Daten viel Zeit in Anspruch nimmt.

Type Format Exp. ratio

QUERY LOW LZO 4x

QUERY HIGH ZLIB (gzip) 6x

ARCHIVE LOW ZLIB (gzip) 7x

ARCHIVE HIGH BZIP2 15x

Seite 53/69

update

Exec dbms_compression.get_compression_ratio:

Compression Advisor self-check validation successful.

select count(*) on both

Uncompressed and EHCC Compressed format = 1000001 rows

Blocks, Compressed=4329

Blocks, Uncompressed=17980

Rows, Compressed=231

Rows, Uncompressed=55

Compression Ratio=4.1

Compression Type=“Compress For Query Low“

Über den Compression Advisor kann man die erwarteten Kompressionsfaktoren schätzen lassen:

6.3 Verschlüsselung/EntschlüsselungVerschlüsselung und Entschlüsselung funktionieren ähnlich der HCC, bei der die Verschlüsselung auf den Compute Nodes und die Entschlüsselung meist auf den Cell Nodes erfolgt. Die eingesetzten CPUs können die Ver- und Entschlüsselung direkt durch die Hardware erledigen.

6.4 Virtual ColumnsVirtuelle Spalten sind ein neues Feature der Oracle 11g. Bei virtuellen Spalten wird der Inhalt aus Spalten anderer Tabellen berechnet. So ist es zum Beispiel möglich eine virtuelle Spalte “Brutto” anzulegen, deren Werte sich durch die Multiplikation der Werte der „Netto“-Spalte mit den Prozentsätzen der “Prozent-satz”-Spalte ergeben. Dies spart redundante Informationen und Speicherplatz – allerdings müssen die Werte bei jeder Abfrage erneut berechnet werden. Dies erledigen die Cell Nodes, sodass die Compute Nodes nicht unnötig belastet werden.

6.5 Parallelisierung Durch die hohe Anzahl an Festplatten, Cell Nodes und Compute Nodes zahlt sich ein Exadata System beson-ders aus, wenn die Aufgaben über möglichst viele Knoten verteilt und parallel ausgeführt werden. Diese Tat-sache sollte bei der Optimierung im Life Cycle beachtet werden, um die Plattform optimal nutzen zu können.

Da die Parallelisierung einer vorhandenen Umgebung sehr aufwändig ist, bietet Oracle Hilfe in Form des Fea-tures “Auto DOP”. Bei Auto DOP wählt Oracle selbständig die optimale Anzahl von parallel auszuführenden Prozessen. Das Feature wird durch Setzen von “PARALLEL_DEGREE_POLICY=AUTO” aktiviert und steuert fort-an • die Anzahl der parallel arbeitenden Prozesse;• die Auslastung der Ressourcen (CPU und IO) bis zu einem definierbaren Maximum;• die Vermeidung von Überlast;

Seite 54/69

update

6.6 I/ORessourceManagerDer I/O Ressource Manager bietet die Möglichkeit, basierend auf verschiedenen Kriterien das I/O zwischen mehreren auf einer Exadata Plattform laufenden Datenbanken zu verteilen. Zwar war diese Verteilung mit CPU-Ressourcen in der Vergangenheit bereits möglich, doch für I/O stellt dies ein Novum und Alleinstellungs-merkmal für Exadata dar. Die zur Verfügung stehende I/O-Bandbereite kann fair verteilt, garantiert oder limi-tiert werden (ähnlich wie man es vom CPU-Ressource Manager kennt), um beispielsweise bei einer Konsoli-dierung vereinbarte SLAs halten zu können.

6.7 Flash CacheWährend Festplatten große Datenmengen bei geringem I/O Durchsatz aufnehmen, gilt für Flash-Karten ge-nau das Gegenteil: Sie speichern im Verhältnis zur Gesamtkapazität nur geringe Datenmengen bei sehr ho-hem I/O Durchsatz (derzeit 3,2 TB pro Cell!), der zudem nicht durch Controller limitiert wird. Hier setzt Exada-ta an, um den Datenzugriff zu beschleunigen:

• Automatisches Cachen der Daten in Flash;• Nutzung von PCI-Karten, um den Flaschenhals „Disk-Controller“ zu umgehen;• Der wesentliche Teil der Daten verbleibt auf den Festplatten;• Je nach Modell und Ausbaustufe bis zu 44,8 TB Flash Cache (im FullRack) – ausreichend für die meisten

Datenbanken;

Der Flash Cache von Exadata kann in zwei Modi betrieben werden: Write Through oder Write Back. Der De-fault Write Through beschleunigt die Leseoperationen. Schreiboperationen gehen jedoch nach wie vor direkt auf die Festplatte und können eventuell einen Flaschenhals darstellen. Hier hilft der „Write Back“ Modus, bei dem auch Schreibzugriffe im Flash Cache gepufft werden.

Seite 55/69

update

WriteThrough Write Back

Der bisher bekannte Write-Through Modus ist der Default. Der Cache ist nicht persistent. Random Reads wer-den beschleunigt.

Neu: mit Exadata SW 11.2.3.2 wurde der Write-Back Modus eingeführt. Der Cache ist nun persistent und Ran-dom Writes werden beschleunigt. Dies führt zur Vermeidung von free buffer waits im AWR.

Inwiefern die Anwendung von der Nutzung von „Write Back“ Flash Cache profitiert, muss für jede Anwendung individuell getestet werden. Hier gibt es keine Empfehlungen, da jede Anwendung individuell arbeitet. An-wendungen mit sehr vielen kleinen I/Os profitieren tendenziell stärker als Anwendungen mit großen, sequen-tiellen I/Os. Als erster Anhaltspunkt dient der AWR.

Die Umstellung zwischen diesen beiden Konzepten kann online erfolgen und erfordert ein Löschen und die Neuanlage des vorhandenen Flash Cache in der Cell Node.

Seite 56/69

update

Bei der Nutzung des Default Write Through kann man für bestimmte Tabellen festlegen, dass diese im Flash Cache gehalten werden. Hierfür gibt es an den Tabellen das Attribut „CELL_FLASH_CACHE“. Zur Auswahl ste-hen folgende Optionen:

• NONE: Dieses Objekt niemals cachen;• DEFAULT: Der Automatische Cache Mechanismus (dies ist auch gleichzeitig der Default);• KEEP: Das Objekt soll bevorzugt im Cache gehalten werden, sodass ein sehr schneller Zugriff möglich ist.

Alternativ kann der Speicher des Flash Cache als Disk Group im ASM für die Ablage von Data Files aller Art genutzt werden – dies wird jedoch in der Praxis nicht genutzt.

7 Conclusion

Um den Bogen zu schließen, werden die einleitenden Fragestellungen betrachtet. Inwiefern wurden Antwor-ten und Lösungen gefunden?

Wie fällt nun das erste Fazit aus Projekt- und Betriebssicht aus? Die Einführung von Exadata ist aus Projekt-sicht durchaus vergleichbar mit anderen Einführungsprojekten großer Systeme. Oracle und Oracle Partner geben in allen Bereichen ausreichende Hilfestellung und die wesentlichen Schritte sind standardisiert. Ein wesentlicher Vorteil ergibt sich aus der Zeitersparnis. Die Systeme sind aufgrund der strukturierten Vorge-hensweise extrem schnell aufgebaut und einsatzbereit. Zudem profitieren fast alle Anwendungen bereits in der Standardkonfiguration von den Features des Systems. Custom Configurations können auch hier noch enorme Vorteile bringen, sind aber nicht immer zwingend erforderlich, sodass Exadata in den meisten Fällen sehr schnell produktiv genutzt werden kann.

Der Kunde benötigt während der Projektphase keine eigene Exadata-Expertise sofern die wesentlichen Kon-zepte und Vorgaben von Oracle Berücksichtigung finden.

Was sind die Voraussetzungen dafür, dass Anwendungen die Plattform bestmöglich nutzen? Hier verhält es sich genau so wie in zahlreichen anderen Projekten, in denen Datenbanken auf eine neue leistungsfähigere Infrastruktur migriert werden. Im Grunde profitiert fast jede Anwendung bereits ohne Anpassung von der neuen Plattform Out-of-the-Box. Dennoch zeigt sich vielfach, dass sich der Aufwand für weitere Optimierun-gen sehr lohnt. Eine Optimierung unter Einbeziehung der Exadata-spezifischen Features sowie Ressourcen bringt in vielen Fällen enorme Verbesserungen vor allem in Bezug auf Performance.

Seite 57/69

update

Wie sieht es denn aus Betriebssicht aus? Wie wird Exadata optimal in bestehende Betriebsumgebungen ein-gepasst und in welchen Bereichen ist ein Umdenken in der IT-Organisation erforderlich? Auch hier lässt sich sagen, dass Oracle und Oracle Partner in Exadata-spezifischen Bereichen eine vollständige Palette von Ser-vices (vom Hardware-Support bis zum vollständigen Betrieb der Plattform) bietet. Kunden, die mehrere Sys-teme betreiben und hier über einen eigenen Support nachdenken, sollten ebenfalls einen vertikal strukturier-ten Plattformsupport in Betracht ziehen.

8 Appendix – Exadata Deployment Assistant Step by Step

Der Oracle Exadata Deployment Assistant Version 2 ist bei MOS als Patch 1725684 für Linux, Windows und Solaris im Download zugänglich. Der Deployment Assistant ist Teil des OneCommand Utility und ist Java-ba-siert.

Nach dem Start:

Führung durch den OEDA

(Oracle Exadata Deploy-

ment Assistant) am Bei-

spiel einer Konfiguration

für die X3-8 Hardware;

Seite 58/69

update

Vereinbarung von Customer Details

Hardware-Auswahl

In der ersten Maske abgefragte

Informationen:

• Name-Präfix: Daraus wer-

den alle Komponentenna-

men abgeleitet;

• NTP-Server/DNS: NTP-

Server sollten auf dem

gleichen Hierarchielevel

stehen (dürfen nicht zu

weit auseinanderliegen)

NTP/DNS-Einträge lassen sich

nach der Installation noch än-

dern.

Alle verfügbaren Hardware-Ty-

pen werden als Auswahlliste

angeboten – auch der Su-

perCluster.

Wichtig ist hier die Entschei-

dung, ob HP- oder HC-Storage

ausgewählt wird.

• HP (High Performance –

Less Capacity);

• HC (High Capacity – Less

Performance);

(Hier: Exadata X3-8)

Seite 59/69

update

Festlegung der Netzwerke

Übersicht zu Netzwerken

Netzwerkdefinition

• Admin Netz;

• Client;

• InfiniBand Interconnect

(für RAC und Zugriff auf

Storage Cells);

• Optional: Netzwerk für

Backup;

Exadata trennt die Netzwerke

für Client und Interconnect –

wie bei herkömmlichen RAC

bekannt. Zusätzlich wird das

Admin Netz und optional ein

Backup Netz konfiguriert.

Details zu den jeweiligen Netz-

werken:

• Name;

• Subnet Mask;

• Gateway;

• Physik des Netzwerks

(Kupfer/Optisch);

Die Netzmaske sollte groß ge-

nug ausgelegt sein, falls in

dem InfiniBand Netz Applika-

tions-Server (ggf. Exalogic)

und/oder NFS Storage einge-

bunden werden sollen.

Seite 60/69

update

Admin-Netzwerk

Details zum Exadata-spezifi-

schen Admin-Netzwerk:

Aus der ersten IP Adresse und

der bereits definierten Subnetz

Maske wird die Pool-Größe so-

wie die höchste IP Adresse be-

rechnet/angezeigt.

Hier kann definiert werden, ob

in diesem Netz das Default Gate-

way der Datenbank-Server liegt

(in diesem Fall nicht) und ob der

Datenbank-Server Admin-Name

den physikalischen Host-Namen

definiert (wie hier eingegeben).

In diesem Netzbereich sind auch

die ILOMs der jeweiligen Server

integriert.

Client-Netzwerk

Das Client-Netzwerk ist das

Netzwerk, in dem typischerwei-

se die Applikations-Server ste-

hen.

Aus der ersten IP Adresse und

der definierten Subnetz Maske

wird die Pool-Größe sowie die

höchste IP Adresse berechnet/

angezeigt.

Hier kann definiert werden ob in

diesem Netz das Default Gate-

way der Datenbank-Server liegt

und ob der Datenbank-Server

Name den physikalischen

Host-Namen definiert (wie hier

eingegeben).

Seite 61/69

update

InfiniBand-Netz

Aus der ersten IP Adresse und

der oben definierten Subnetz

Maske wird die Pool-Größe so-

wie die höchste IP Adresse be-

rechnet/angezeigt.

Das Infiniband-Netz hat kein De-

fault Gateway.

Die Netzmaske sollte groß genug

ausgelegt sein, falls in diesem

Netz Applikations-Server (ggf.

Exalogic) und/oder NFS Storage

eingebunden werden sollen.

Backup-Netz

Hier werden definiert:

• Backup-Netz (sofern zuvor

angegeben);

• Weiteres Netzwerk für den

Data Guard Netzwerk Traf-

fic (falls ein DR System ein-

gesetzt wird);

Seite 62/69

update

Auswahl Betriebssystem

Zusammenfassung

Zusammenfassung mit Option

für letzte manuelle Änderungen:

Oracle empfiehlt, bei der Konfi-

guration zusammenhängende IP

Adressbereiche zu nutzen. Aus

den jeweiligen Adressbereichen

werden mit fortlaufenden IP Ad-

ressen die Host-Namen konfigu-

riert.

Falls kein zusammenhängender

IP Adressbereich zur Verfügung

steht, können hier die Hosts mit

abweichenden IP Adressen be-

legt werden.

Auswahl Betriebssystem:

• Linux und Solaris stehen

zur Auswahl (in der Regel

wird Linux genutzt);

Seite 63/69

update

Definition ClusterAuf einer Exadata Maschine

können mehrere RACs konfigu-

riert werden.

• Auf bis zu vier 2-Kno-

ten-Cluster können bis zu

acht Database Nodes ein-

gerichtet werden;

• Cell Nodes werden eben-

falls entsprechend zuge-

ordnet. Dies kann später

nur mit hohem Aufwand

geändert werden.

Auf einer X3-2 Full Rack (acht

Compute Nodes und 14 Cell No-

des) könnten vier RACs mit je

zwei Datenbank-Servern gebil-

det werden.

Auf einer X3-2 Half Rack (vier

Compute Nodes und sieben Cell

Nodes) könnten zwei RACs mit je

zwei Datenbank-Servern gebil-

det werden.

Dies wird in diesem Abschnitt

festgelegt.

Seite 64/69

update

Übersicht Cluster-Definition

Cluster-Definition

Ebenfalls festgelegt werden

• ORACLE_HOME für Grid In-

frastructure und Daten-

bank sowie die Soft-

ware-Version;

• Datenbankname und De-

fault Blockgröße der Daten-

bank;

• Unter dem Punkt „Client

Network“ ist eine Pool-Grö-

ße von sieben zu sehen:

* Zwei Datenbank-Server

* Zwei VIP Adressen

* Drei SCAN Adressen

• Definition von Rollense-

parierung (wie RAC) zwi-

schen Datenbank und

Grid-Infrastruktur;

• Disk Group-Details;

• Verteilung 80% zu 20%

(wenn kein Backup as

Copy);

• Firmenspezifische Instal-

lations-Standards seitens

der Oracle Software be-

rücksichtigen;

DBFS Disk Group:

• Informationen zum Data-

base File System: The

Oracle Database File Sys-

tem (DBFS) [12]

Seite 65/69

update

Review Cluster-Definition

Definition Monitoring Cell Nodes

Dies ist die Übersicht und letz-

te Möglichkeit Änderungen

vorzunehmen.

Die Cell Nodes können für

E-Mail und SNMP Alarmierung

konfiguriert werden.

E-Mail und/oder SNMP Server

Details werden hier angege-

ben.

Seite 66/69

update

Definition OCM

Wie jede Datenbank kann auch

Exadata mit dem OCM konfigu-

riert werden.

Dies ermöglicht beispielsweise

den Download von Updates

über MOS sowie den Eintrag der

Konfiguration bei MOS, sodass

Oracle im Supportfall die Konfi-

guration sofort kennt.

(ggf. auch über Proxy Server)

Konfiguration ASRASR dient der automatischen Öffnung eines Service Request bei Oracle im Fall fehlerhafter Hardware.Der Auto Service Request (ASR) Process benötigt einen soge-nannten ASR Manager. Dies ist eine Software, die im Kunden-netzwerk steht und als „Vermitt-ler“ zwischen Exadata und Orac-le Support fungiert. Der ASR Manager nimmt SNMP Traps vom Exadata System entgegen und leitet sie per HTTPS an Orac-le Support weiter (falls ge-wünscht über einen Proxy Ser-ver).Benötigt werden zudem der Name des lokalen Kunden-ansprechpartners sowie seine E-Mail Adresse und sein Ac-count-Name bei MOS.

Seite 67/69

update

Konfiguration von Grid/Cloud Control

Kommentare und Hinweise für ACS Techniker

Cloud Control sollte bereits

verfügbar sein (oder kann

nachträglich installiert wer-

den). Angegeben wird das

ORACLE_BASE des zu installie-

renden Agenten sowie

Host-Name und Upload Port

des OMS.

Dies sind Hinweise an Oracle

für den ACS Techniker.

Seite 68/69

update

XML-File

XML-File wird generiert.

Seite 69/69

update9 Referenzen

1. Deploying Oracle Maximum Availability Architecture with Exadata Database Machine

http://www.oracle.com/au/products/database/exadata-maa-131903.pdf

2. Database as a Service

http://www.avato-consulting.com/Dokumente/WhitePaper-DE-pdf/avatoWhitepaperDatabase_Service.pdf

3. Oracle GoldenGate on Oracle Exadata Database Machine

http://www.oracle.com/technetwork/database/features/availability/maa-wp-gg-oracledbm-128760.pdf

4. Backup and Recovery Performance and Best Practices for Exadata Cell and the Oracle Exadata Database Machine

http://www.oracle.com/technetwork/database/features/availability/maa-tech-wp-sundbm-backup-

11202-183503.pdf

5. Backup and Recovery Performance and Best Practices using Oracle Sun ZFS Storage Appliance and Oracle Exadata

Database Machine

http://www.oracle.com/technetwork/database/features/availability/maa-wp-dbm-zfs-backup-1593252.pdf

6. Certified Platinum Configurations

http://www.oracle.com/us/support/library/certified-platinum-configs-1652888.pdf

7. Oracle Platinum Services Support Policies

http://www.oracle.com/us/support/library/platinum-services-policies-1652886.pdf

8. Oracle Website - Overview Platinum Services

http://www.oracle.com/us/support/premier/engineered-systems-solutions/platinum-services/overview/index.

html

9. Oracle Auto Service Request Exadata Database Machine Quick Installation Guide

http://docs.oracle.com/cd/E37710_01/doc.41/e23333.pdf

10. Oracle Enterprise Manager 12c: Oracle Exadata Discovery Cookbook

http://www.oracle.com/technetwork/oem/exa-mgmt/em12c-exadata-discovery-cookbook-1662643.pdf

11. The Oracle Database File System (DBFS)

http://ronnyegner.wordpress.com/2009/10/08/the-oracle-database-file-system-dbfs/