Datenbankkonsolidierung

473 Aufrufe

Veröffentlicht am

Oracle Datenbankkonsolidierung

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
473
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
14
Aktionen
Geteilt
0
Downloads
5
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Datenbankkonsolidierung

  1. 1. Datenbankkonsolidierung Multitenant oder nicht? Dierk Lenz DOAG 2014 Konferenz
  2. 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. 3. Herausforderungen für den Oracle-Betrieb • Versionen Upgrade auf 12c? • Editionen und Optionen EE+Multitenant? SE/SE1? • Virtualisierung VMware? OVM? 3
  4. 4. Konsolidierung für Alle? • Konsolidierung in aller Munde • Wichtige Frage: Kann und soll ich alle Datenbanken konsolidieren? 4
  5. 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. 6. Schemakonsolidierung 6
  7. 7. Server-Konsolidierung 7
  8. 8. Virtualisierung 8
  9. 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. 10. Oracles Lösung: Multitenant Option 10
  11. 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. 12. Kompliziert? • Ebenfalls möglich: Einsatz von – RAC / RAC One Node – Advanced Compression – usw. 12
  13. 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. 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. 15. Virtualisierung • Marktstandard VMware • Nicht akzeptiert als Möglichkeit für Hardware Partitioning • Alternativen: – Eigenes vCenter für Oracle Datenbanken – OVM 15
  16. 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. 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. 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. 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. 20. SE/SE1 Systeme • Ressourcen pro Instanz i.a. nicht besonders hoch • Virtualisierung oft angebracht 20
  21. 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. 22. Monitoring! • Komplexität wächst durch Konsolidierung • Monitoring auf allen Ebenen notwendig 22
  23. 23. Vielen Dank für Ihre Aufmerksamkeit! 23
  24. 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

×