Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Datenbankkonsolidierung

857 Aufrufe

Veröffentlicht am

Oracle Datenbankkonsolidierung

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

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

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

×