In diesem Dokument beschreibt Daniele Massimi die ersten vier produktiven Jahre einer virtualisierten Exadata-Plattform, welche für die Konsolidierung von Oracle-Datenbanken eingerichtet wurde. Es werden verschiedene Herausforderungen in den Bereichen System, Storage, Netzwerk und Datenbank architektonisch behandelt sowie die Implementierung und Optimierungen der Plattform dokumentiert. Zudem wird auf die Erfahrungen mit Patch-Management, Automatisierung und die Koordination von Upgrades eingegangen.

1. Virtualized Exadata
…die ersten 4 «produktiven» Jahren
Daniele Massimi
Principal Consultant
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 1

2. Who Am I
Daniele Massimi, appliedtec gmbh (CH, Bern)
Consultant daniele.massimi@appliedtec.ch
 Oracle DBA seit ~20 Jahre (Exadata > 7 Jahre)
 Infrastruktur-Architekturen und Implementationen (Cloud und On-Premise), Backup &
Recovery, Upgrades and Migration , High Availability, Virtualisierung, Automation, Exadata
Implementationen
 Engineered Systems (Exadata, ODA, ZDLRA)
 Oracle Certifications
 Oracle Certified Master (11g und 12c)
 Oracle Certified Professional (8i – 12c)
 Oracle Certified Expert (RAC)
 Oracle Implementation Specialist (Exadata, OVM)
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 2

3. Agenda
 Projektbeschreibung
 Ziel Plattform
 System Herausforderungen
 Storage Herausforderungen
 Netzwerk Herausforderungen
 Datenbank Herausforderungen
 Patching und Upgrades Herausforderungen
 Deployments / Provisioning / Automation
 Capacity Management
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 3

4. Projektvorgaben
 Realisierung einer Konsolidierungs-Plattform für Oracle Datenbanken
 Ablösung der bestehende AIX Umgebung
 Lizenz Optimierung
 Bedienung von zwei Netz-Zonen (Intranet und DMZ)
 Isolation von Produktion zu Vor-Produktion Umgebungen
 Dedizierte Kunden-Umgebungen
 DBaaS (optional)
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 4

5. Definierte Zielplattform
 Lösung des Kunden → virtualized Exadata
 Wieso ? → Eigenschaften
 Virtualized Exadata kann als Konsolidierungs-Plattform eingesetzt werden
 Virtualized Exadata bietet Isolierung mittels VMs
 Virtualized Exadata bietet Lizenz-Optimierung mit «Trusted Partition»
 Virtualized Exadata hat die gleiche Funktionalität wie mit «Bare Metal»
 Exadata kann erweitert werden (z.B. mit Elastic Configuration)
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 5

6. Plattform und Ausbaustufen
 Initial Konfiguration → 2 X5 Quarter Rack
 Erweiterung der Cell Disks von 4Tb auf 8Tb
 Erweiterung von X6 Compute Nodes
 Je 2 Nodes per Exadata Rack
 Erweiterung von X7 Compute Nodes
 2 Nodes an einem Standort
 Erweiterung von 2 X7 Storage Server
 Ersatz von 5 X8 Storage Server
 Ausbau lokale Disks von 4 auf 8 600Gb
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 6

7. System Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 7
 Filesysteme haben begrenzte Kapazität
 Logfile Management nicht mehr trivial
 Applikatorische Ablagen (z.B. Staging Area für Data Load oder Extracts)
 → Lösung: NFS Shares
 Anzahl der NFS Mounts kann nicht vernachlässigt werden
 Interne Security Anforderungen benötigen zusätzliche Software
 spezifische RPMs sind notwendig
 non Standard RPMs verursachen Zusatzaufwand beim Patching
 → Lösung: Inventory führen der RPMs (Linux 6 auf Linux 7 Problematik !)

8. System Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 8
 Erhöhung der Lokalen virtual Disks (/ (root), /u01)
 lokale Disks in den physikalischen Server sind endlich
 → Sparsam damit umgehen !
 Grid Home bei Upgrades
 Neue oder zusätliche Oracle Homes
 Ausbau lokale Disks
 Von 4 auf 8 600Gb → 1.6Tb auf 3.8 Tb vergrösserung des /EXAVMIMAGES
 Achtung !!! → Disks werden automatisch ins RAID aufgenommen
 Synchronisation startet automatisch → resync dauert ca. 18h 
 VMs haben in der Zwischenzeit Performance Engpass !!! → I/O Waits !

9. System Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 9
 Erhöhung der vCPUs
 Supportetes Feature der Virtualized Exadata
 Default Setting maxvcpus auf das Maximum
 Ziel → dynamische Allozierung bei Bedarf
 Problematisch wenn sämtliche CPU Core eines Sockets belegt sind
 Steal time is the percentage of time a virtual CPU waits for a real CPU while
the hypervisor is servicing another virtual processor. (Quelle: IBM)
 → Somit nur bedingt “dynamisch”
 Wenn vCPU de-provisioniert wird, werden sämtliche vCPU dealloziert →VM hat zu
wenig Ressource und ein reboot wird i.d.R erfolgen
 → Service wird unterbrochen
top - 18:34:15 up 10 days, 3:36, 1 user, load average: 1.38, 1.46, 1.46
Tasks: 484 total, 4 running, 480 sleeping, 0 stopped, 0 zombie
Cpu0 : 1.0%us, 1.4%sy, 0.0%ni, 97.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.7%us, 0.7%sy, 0.0%ni, 98.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.3%st
Cpu2 : 0.7%us, 2.7%sy, 0.0%ni, 96.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.3%st
Cpu3 : 1.7%us, 1.4%sy, 0.3%ni, 96.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu4 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si,100.0%st
Cpu5 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si,100.0%st
Cpu6 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si,100.0%st
Cpu7 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si,100.0%st
Mem: 123304248k total, 20590912k used, 102713336k free, 616668k buffers
Swap: 16777212k total, 0k used, 16777212k free, 6786116k cached

10. System Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 10
 Erweiterung von 2 Database Server
 Re-Imaging
 switch_to_ovm.sh ausführen
 Neue VMs via OEDA deployen
 Problem mit Einbindung in OEM, da dazumal “Elastic Configuration” noch
nicht vorhanden
 → databasemachine.xml musste manuell “angepasst” werden

11. Storage Cells Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 11
 Erhöhung der Diskkapazität von 4Tb auf 8Tb (rolling)
 Storage Cells offline setzen
 Disk Austausch
 Re-Imaging der Storage Cells
 Neu erstellen der Celldisks und Griddisks
 Rebalancing der ASM Diskgruppen starten
 Erweiterung um 2 X7 Storage Cells
 Erstellen der Celldisks und Griddisks
 cellip.ora ergänzen
 Rebalancing der ASM Diskgruppen starten

12. Storage Cells Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 12
 Ersatz bestehenden Cells mit 5 X8 Storage Cells (online)
 Erstellen der Celldisks und Griddisks
 cellip.ora ergänzen
 Addieren der neuen Disks und löschen alten Disks
 Rebalancing abwarten
 → durch adäquate Rebalance Power keine Performanceeinbusse
 Kein IORM im Einsatz
 regelmässige Überprüfunden finden statt
 IORM Konfiguration für Flashcache in Zukunft vorstellbar

13. Storage Cells Herausforderung
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 13
 Grundsätzlich keine Probleme und sehr stabil
 Nach Erweiterung neue X7 Storage Cells → Performance Probleme
 DBs mit hohen «log file sync wait»
 Analyse ergibt hohe Antwortzeiten auf Flash Log
 Auslöser MOS 1500257.1
 Obschon Flash Logs unabhängig von Writeback FlashCacheMode ist
resp. immer das schnellere Schreiben zwischen Flash und Disk
für das I/O Acknowledge gilt → Performance Probleme !
 → Lösung: Restart der CELLSRV Services der betroffenen Cells

14. Netzwerk - Projektanforderungen
 Kunde betreibt zwei von einander getrennte Netz-Zonen (Intranet und DMZ)
 Netzwerke sind nicht geroutet
• Mandantenfähigkeit
• Security Anforderungen
 Problematik der Exadata DB-Server
• begrenzte Anzahl von Netzwerk Interface Ports
 Lösung → VLAN Tagging
Ethernet Ports
Public Network
Optical Ports
Public Network
Mgmt Ports
Infiniband Ports
Ethernet Ports
Admin Network
Ethernet Ports
Backup/DG Network
X5 Server
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 14

15. Netzwerk Herausforderung
 VLAN Tagging
 Netzwerk Switches müssen mit Port Trunking konfiguriert
werden
 VLANs und Bridges müssen auf den physikalischen Knoten
erstellt werden
 VLANs müssen den VMs bekannt gemacht werden (vm.cfg)
 VM Interfaces müssen konfiguriert werden (udev Rules)
 → jedes zusätzliches VLAN an VM bedingt ein reboot 
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 15

16. Datenbank Architekturen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 16
 Alle DBs mit Multitenant Option (12.1.0.2)
 Folgende Standards wurden festgelegt:
 Single DB
 RAC One Node DB
 RAC One Node DB mit Data Guard

17. Datenbank Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 17
 Einführung Multitenancy →Konsolidierungs-Anforderungen erfüllen
 Character Set Problematik (12.1.0.2)
 Verfügbarkeitsklassen Problematik
 DB-Architektur Problematik (z.B. Data Guard)
 Daten Schutzklassen Problematik
 → Hohe Fragmentierung = reduzierte Konsolidierungs-Dichte !
 CDB Dichte → Abhängig von RTO und RPO
 Produktion CDBs = max. 15 PDBs, DGs Konfigurationen = 1 PDB
 Andere CDBs = max. 50 PDBs

18. Datenbank Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 18
 Probleme mit der Persistenz der «PDB modifiable» Parameter !!!
 Startup Trigger musste implementiert werden um Verlässlichkeit herbei zu führen
 Definierter Standard: zusätzliche Oracle Homes wenn spezielle One-Off
Patches installiert werden müssen
 Sobald One-Off im BP enthalten ist, wird dieser wieder entfernt (lokale Disks
Problematik !)
 VLAN spezifische Oracle Net Zugriffe auf PDB Ebene
 Konfiguration via listener_networks Parameter
 PDBs werden von restlichen VLANs isoliert
 Komplexe Konfiguration !!! → neue Lösung mittels SDN sind in Arbeit !

19. Datenbank Herausforderungen
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 19
 Ressource Management
 Over-Provisioning Problematik
 gerechte Ressourcen Nutzung
 Aktuell kein DBRM im Einsatz (12.1.0.2)
 Neue Datenbanken → ab Q1/2020 19c
 Datenbank Services wurden kategorisiert (S, M, L)
 CPU_COUNT auf PDB Ebene
 Overprovisioning Ansatz
 SGA_TARGET auf PDB Ebene

20. Patching und Upgrade Pfade
 Initial Exadata Image Konfiguration → 12.1.2.1.3
 Patching 12.1.2.1.3 → 12.1.3.x → 12.2.1.1.x → 19.2.5.0.0 (aktuelle eingesetzte
Version)
 Initial Infiniband Version → 2.1.x
 Verschiedene Patches bis auf 2.2.13 (aktuell eingesetzte Version)
 Initial Grid Infrastructure Version → 12.1.0.2
 Upgrades 12.1.0.2 → 12.2.0.1 → 19.3.0.0.0 (aktuell eingesetzte Version)
 Datenbanken Versionen
 11.2.0.4, 12.1.0.2, 12.2.0.1, 19.3.0.0.0
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 20

21. Patching und Upgrade Herausforderungen
 Haupt-Problematik → Wartungsfenster !
 Initial Konzept sah kein «online Patching» vor (Keine 7x24h Applikationen)
 ASM Storage nur mit «normal Redundancy» → Online Patching nicht empfohlen !
 Stark Konsolidierte Plattformen bedingen auch hohen Koordinationsaufwand beim
Patching
 Wo möglich wurden «online» Verfahren angewendet (IB, OS, GI, RDBMS)
 → zukünftige Ausrichtung: online Patching !
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 21

22. Patching und Upgrade Herausforderungen
 Virtualized Exdata → Upgrade Grid Infrastructure und RDBMS ab 18c nur mit
OEDACLI supported
 MOS → 18c: 2369422.1, 19c: 2542082.1
 OEDACLI übernimmt folgende Tasks:
 Discovery der aktuellen Virtualized Exadata Umgebung ☺
 Hinzufügen von Virtual Disks → Dom0 und DomU (für GI und RDBMS)
 Provisionieren (Copy, Installation, Relink, etc.) von GI und RDBMS Software
 Upgrade und Downgrade von Grid Infrastructure Stack (inkl. cluvfy Checks)
 → nach 5 OEDACLI Updates, funktionierte das Cluster Upgrade nicht !
 → In Abstimmung mit Oracle ACS, wurde 12.2er Upgrade Methode angewendet
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 22

23. Deployments / Provisioning / Automation
 Exadata VMs Deployment
 gemäss Oracle Best Practices → via OEDA resp. install.sh
 Oracle Databases
 Erstellung automatisiert via scripts (inkl. OEM, CMDB, Backup)
 Ansible Automation → in Arbeit !
 Grid Infrastructure und RDBMS Patching Optimization
 PoC mit Fleet Patching & Provisioning Utility und Ansible initiert
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 23

24. Capacity Management
 Capacity Management wird via OEM überwacht
 vCPU, Memory und Storage (Cells und ASM)
 Memory Huge Page Allokation für DB ca. 50-60% → je nach Anzahl der DBs auf der VMs
 CPU Erhöhung Problematik → bereits erwähnt
 Storage Erhöhung online bei Bedarf (griddisk → ASM)
 Gilt auch für Reduzierung
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 24

25. Know How
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 25
 Von Single Server DBA zu Exadata DBA !
 System Administrator
 Netzwerk Administrator
 Storage Administrator
 Cluster Administrator
 RAC Administrator
 Multitenant Option
 Die Bandbreite der Technologien und der möglichen Probleme erhöhen sich
exponentiell !!!
 → Definition und Implementation von Standards unumgänglich !

26. Fazit
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 26
 Gute Implementation für Isolation von Umgebungen
 Mit Trusted Partition hat man ein Instrument für Lizenz Optimierung
 Management Tools für das VM Management «noch» nicht vorhanden
 Mehrere Technologien = mehr Know-How wird benötigt
 Komplexität steigt exponentiell (Management, Networking, Patching,
etc.)
 Aufbau Knowledge über die verschiedene Technologien zwingend
notwendig !!!

27. Fragen ???
27.11.2019Virtualized Exadata - … die ersten 4 “produktiven” Jahren – Daniele Massimi 27