Das Dokument behandelt die Herausforderungen und Möglichkeiten der Datenbankkonsolidierung für Oracle-Datenbanken, wobei verschiedene Ansätze wie Schemakonsolidierung, Server-Konsolidierung und Virtualisierung erläutert werden. Es wird betont, dass die Multitenant-Option der Enterprise Edition eine flexible Lösung bietet, um mehrere pluggable databases effizient zu verwalten. Zudem werden Aspekte wie Hardware-Anforderungen und Lizenzoptimierung angesprochen, um die richtige Konsolidierungsstrategie zu entwickeln.

1. Datenbankkonsolidierung
Multitenant oder nicht?
Dierk Lenz
DOAG 2014 Konferenz

2. Herrmann & Lenz Services GmbH
Herrmann & Lenz Solutions GmbH
• Erfolgreich seit 1996 am Markt
• Firmensitz: Burscheid (bei Leverkusen)
• Beratung, Schulung und Betrieb/Fernwartung rund um das
Thema Oracle Datenbanken
• Schwerpunktthemen: Hochverfügbarkeit, Tuning, Migrationen
und Troubleshooting
• Herrmann & Lenz Solutions GmbH
– Produkt: Monitoring Module
– Stand auf Ebene 2
2

3. Herausforderungen für den Oracle-Betrieb
• Versionen
Upgrade auf 12c?
• Editionen und Optionen
EE+Multitenant? SE/SE1?
• Virtualisierung
VMware? OVM?
3

4. Konsolidierung für Alle?
• Konsolidierung in aller Munde
• Wichtige Frage:
Kann und soll ich alle Datenbanken
konsolidieren?
4

5. Was heißt Konsolidierung?
• Zusammenfassen mehrerer Dienste auf einem
System bzw. einer Plattform
• Für Oracle Datenbanken (auch ohne 12c)
mehrere Möglichkeiten:
– Schemakonsolidierung
– Server-Konsolidierung
– Virtualisierung
5

6. Schemakonsolidierung
6

7. Server-Konsolidierung
7

8. Virtualisierung
8

9. 9
Schemakonsolidierung
• Public Objekte
disjunkt?
•Nur
gemeinsam
administrier-bar
Server-Konsolidierung
•Administration
einzelner
Instanzen
•Overhead
(Prozesse,
Speicher)
• „Großer“
Server
erforderlich:
EE?
Virtualisierung
• Eigene VM pro
Instanz
• Flexible
Zuordnung zu
Hosts
•Mehr
Overhead
• Vorsicht!
Lizenzregeln!

10. Oracles Lösung: Multitenant Option
10

11. Multitenant Option
• Enterprise Edition Option – nicht möglich mit SE/SE1
• Pluggable DBs logisch voneinander unabhängig
(keine Überschneidung bei Public Objekten möglich)
• Keine vollständige Konfigurationsfreiheit
(z.B.: Datenbankzeichensatz durch Container-DB
bestimmt)
• Interessante zusätzliche Features: z.B. Snapshot
Cloning von Pluggable DBs
11

12. Kompliziert?
• Ebenfalls möglich: Einsatz von
– RAC / RAC One Node
– Advanced Compression
– usw.
12

13. Weiterer Aspekt: Hardware
• Beispiel: Oracle Database Appliance
– Geschlossenes System
– Ausgelegt auf flexible Nutzung von EE Lizenzen
– Festlegung auf
• OVM
• Oracle Linux
• EE, RAC
• Mitgeliefertes IO-Subsystem
13

14. Mehr Hardware-Aspekte
• CPUs und Kerne an Edition anpassen –
Tendenz:
– EE: möglichst viel Leistung pro Kern
– SE/SE1: möglichst viele Kerne pro Sockel
• Generell für Konsolidierung:
– Leistungsfähiges IO-Subsystem!
– Viel Hauptspeicher!
14

15. Virtualisierung
• Marktstandard VMware
• Nicht akzeptiert als Möglichkeit für Hardware
Partitioning
• Alternativen:
– Eigenes vCenter für Oracle Datenbanken
– OVM
15

16. Welche Edition ist die Richtige?
• Diverse Aspekte:
– Technische Anforderungen
• Direkt: Anwendung nutzt EE-Features
• Indirekt: DB-Größe x TB Parallele RMAN Channels
– Lizenzkostenoptimierung
16

17. Strategie
• Unterteilung der vorhandenen Systeme
– High End (High Performance / High Availability)
– Nicht High End, aber EE Features notwendig
– Keine EE Features notwendig
17

18. High End Systeme
• In den meisten Fällen keine Konsolidierung
• Ausnahme: High End Hardware (z.B. Exadata)
• Oft mit RAC, Partitioning usw.
18

19. Konsolidierung von EE Systemen
• Multitenant Option!
– EE Lizenzen so oder so notwendig
– Multitenant unterstützt die Strategie
Maximale Leistung pro Kern
– Ggfs. Lizenzkostenersparnis durch „mehr Instanzen auf
einem System“
– besonders vielversprechend bei vielen gleichartigen
DBs: Minimierung der Konflikte z.B. bei Zeichensätzen
19

20. SE/SE1 Systeme
• Ressourcen pro Instanz i.a. nicht besonders
hoch
• Virtualisierung oft angebracht
20

21. Verifikation der Strategie
• Tests erforderlich
• Insbesondere Lasttests
• Kalkulation verfügbarer Ressourcen
– z.B. für wie viele Instanzen reicht die gemeinsame
IO-Anbindung? (Bedenke: Sicherungen!)
• Gültigkeit der Lizenzen!
21

22. Monitoring!
• Komplexität wächst durch Konsolidierung
• Monitoring auf allen Ebenen notwendig
22

23. Vielen Dank für Ihre Aufmerksamkeit!
23

24. Fragen & Kontakt
E-Mail: dierk.lenz@hl-services.de
Web: http://www.hl-services.de
Blog: http://blog.hl-services.de
Twitter: @ora1578
Ausstellung Stand 212: Ebene 2 (gelb)
24