Oracle Database 12c Multitenant + ODA Michael Reick Technischer Account Manager Oracle Deutschland B.V. & Co. KG Oracle Confidential Internal/Restricted/Highly Restricted
Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle s products remains at the sole discretion of Oracle. Oracle Confidential Internal/Restricted/Highly Restricted 3
Multitenant Summary ODA
Oracle Multitenant Idee und Architektur
Private Cloud Datenbank Architekturen Mit Oracle Database 11g Virtuelle Maschinen Dedizierte Datenbanken Schema Konsolidierung Gemeinsame Server Gemeinsamer Server und OS Zunehmende Konsolidierung Gemeinsamer Server, OS und Datenbank
Private Cloud Datenbank Architekturen Mit Oracle Database 12c Virtuelle Maschinen Dedizierte Datenbanken Multitenant Datenbank Gemeinsame Server Gemeinsamer Server und OS Zunehmende Konsolidierung Gemeinsamer Server, OS und Datenbank
Oracle Datenbank Architektur Benötigt Hauptspeicher, Prozesse und Datenbank Dateien System-Ressourcen
Die neue Multitenant Architektur System-Ressourcen Hauptspeicher und Prozesse werden nur noch auf Ebene des multitenant containers benötigt
Die neue Multitenant Architektur Hauptspeicher und Prozesse werden nur noch auf Ebene des multitenant containers benötigt System-Ressourcen
Multitenant Architektur Komponenten einer Multitenant Container Database (CDB) Nutzbar auch mit genau einer PDB (1:1) keine Option erforderlich PDBs Pluggable Databases (PDBs) Root (= statische Bestandteile) CDB
Multitenant Architektur Die Multitenant Architektur unterstützt derzeit bis zu 252 PDBs Database Link Eine PDB verhält sich identisch zu einer non- CDB Ein DB-Client kann nicht erkennen, ob er an einer PDB oder einer non-cdb angemeldet ist.
Multitenant Architekture Dynamische Anteile PDBs teilen sich SGA und Hintergrundprozesse Vordergrundprozesse (DB Sessions) sehen nur die PDB an der sie angemeldet sind
GB Multitenant Skalierbarkeit Jeweils nur kleiner Speicherzuwachs beim Hinzufügen weiterer PDBs 3 MEMORY MEMORY MEMORY 2,5 2 1,5 1 0,5 0 CRM HCM HCM ERP ERP ERP BI BI DW Pluggable Database Pluggable Pluggable Database Database
Nutzungsmöglichkeiten von Oracle Multitenant
Manage Many as One mit Multitenant Gemeinsames DB-Backup; Recovery auf Pluggable Database Ebene Ein Backup Point-in-time Recovery auf Pluggable Database - Ebene
Manage Many as One mit Multitenant Eine Standby Datenbank deckt alle Pluggable Databases ab
Multitenant für vereinfachtes Patching Änderungen nur einmal anwenden, alle Pluggable Databases sind aktualisiert Upgrade in-place
Multitenant für Upgrades Flexibilität beim Patchen und & Upgraden von Datenbanken
Verbesserte Agilität bei Änderungen der DB-Last Cluster-Erweiterung für flexible Konsolidierungsmodelle Services Single SGA pro CDB Instanz CDB Instance 1 CDB Instance 2 Node1 Node2 Multitenant Container Database (CDB)
Verbesserte Agilität bei Änderungen der DB-Last Cluster-Erweiterung für flexible Konsolidierungsmodelle Services Single SGA pro CDB Instanz CDB Instance 1 CDB Instance 3 CDB Instance 2 Node1 Node3 Node2 Multitenant Container Database (CDB)
Multitenant für schnelles Ausrollen von DBs Pluggable Datenbanken können schnell aus seed DB erzeugt werden
Multitenant für schnelles Ausrollen von DBs PDBs können innerhalb der gleichen CDB geklont werden PDBs können aus remote CDBs geklont werden
Vorteile der Multitenant Architektur Weniger Kosten, Mehr Agilität, Einfache Einführung Self-contained PDB für jede Anwendung Applikationen laufen unverändert Schnelles Ausrollen (über Clones) Portabilität (durch Plug/Unplug ) Gemeinsame Nutzung von RAM und Prozessen Mehr Applikationen pro Server Gemeinsame Verwaltung auf CDB-Ebene Manage many as one (Upgrade, HA, Backup) Granulare Kontrolle wo angemessen
1. Multitenant für Test und Entwicklung Schnelle, flexible Kopien und Snapshots von Pluggable Databases
2. Konsolidierung von vereinzelten Anwendungen Teilt den Overhead von Speicher und Prozessen System-Ressourcen
Vorteile von Flexibilität und Portabilität Eine PDB kann SLAs durchwandern je mehr mission critical sie wird GOLD RAC, Data Guard, Tägliche inkr. Backups SILBER Data Guard, Tägliche inkr. Backups BRONZE Wöchentliche Full Backups
Self-Service Database as a Service (DBaaS) Auswählen von Größe und Service Level GOLD RAC, Data Guard, Tägl. Incrementals SILBER Data Guard Tägl. Incrementals BRONZE Wöchentl. Full Backups
Self-Service Database as a Service (DBaaS) Auswählen von Größe und Service Level GOLD RAC, Data Guard, Tägl. Incrementals SILBER Data Guard Tägl. Incrementals BRONZE Wöchentl. Full Backups
Multitenant. Ideal für SaaS. Mandantenfähig durch die Datenbank, nicht die Anwendung Dadurch funktionieren Alle Sicherheitsmerkmale (Verschlüsselung, Datenmaskierung ) Alle Auswertungswerkzeuge genau wie für die DB eines einzelnen Kunden Nachrüsten von alten, eigentlich nicht mandantenfähigen Anwendungen wird möglich
Besonderheiten und Eigenschaften von Oracle Multitenant
Dateien in der CDB Namespaces Jede PDB hat einen eigenen Satz Tablespaces, inkl. SYSTEM und SYSAUX PDBs teilen sich UNDO, REDO und control files, (s)pfile Als Default hat die CDB einen einzelnen TEMP Tablespace, PDBs können aber ihren eigenen anlegen
Benutzer (DB User) Lokale Nutzer ( local user ) entsprechen selbst erstellen Nutzern in einer non-cdb sind nur in einer PDB definiert können eine PDB administrieren Ein common user ist im root definiert und wird in jeder PDB repräsentiert Ein common user kann sich an jede PDB anmelden, in der er Create Session -Privileg hat und kann diese auch administrieren Oracle-eigene Systemobjekte gehören common users
Unplug / Plug Einfach aus der alten CDB ausklinken
Unplug / Plug und in die neue CDB einklinken Verschieben zwischen CDBs erfordert lediglich das Verschieben der Metadaten der PDB Upgrades und Patching werden dadurch einfacher Eine ausgeklinkte PDB beinhaltet Infos zu lineage, opatch, encryption keys etc.
Unplug / Plug Beispiel Unplug alter pluggable database HCM unplug into '/u01/app/oracle/oradata/ /hcm.xml' Plug create pluggable database My_PDB using '/u01/app/oracle/oradata/ /hcm.xml'
Ressourcenverwaltung für Pluggable Databases
Verwalten von geteilten Ressourcen Resource Management in einer Multitenant Umgebung Hohe Priorität Niedrige Priorität Mittlere Priorität
Verteilen von Ressourcen zwischen PDBs Grundsätzlich: PDBs konkurrieren um gemeinsame Ressourcen Mit dem Resource Manager stellt man daher pro PDB ein: CPU Exadata I/O Sessions Anzahl der Parallel Execution Servers Konfigurierte Policies regeln, wie Ressourcen benutzt werden: über eine Default Konfiguration die auch bei Hinzufügen/Entfernen von PDBs funktioniert über harte Limits ( you get what you pay for )
Verteilen von Ressourcen zwischen PDBs Das zugrundelegende Standardmodell basiert auf folgenden Annahmen: Eine Anzahl Shares wird jeder PDB zugewiesen (Default: 1 Share pro PDB) Die Summe der Shares ist beliebig Die Summe der Shares entspricht der Gesamtleistung Zusätzlich: Ein optionales Cap (d.h. ein maximales Nutzungslimit) kann jeder PDB zugewiesen werden (Default: Kein Cap, d.h. max 100%)
Zuteilen von CPU-Leistung Ein CDB Resource Plan nutzt Shares zur Verteilung von CPU-Leistung für PDBs 2 Shares 1 Share 1 Share Pluggable Database Shares Garantierte CPU-Leistung Maximale CPU-Leistung HCM 2 2/4 = 50% 100% CRM 1 1/4 = 25% 100% ERP 1 1/4 = 25% 100%
Erstellung einer Pluggable Database
Anlegen einer CDB Am besten mit dbca
Klonen einer PDB Beispiel Lokal create pluggable database HCMBI from HCM Remote (über DB Link) create pluggable database HCMBI from HCM@us.acme.db1
Erzeugen einer Pluggable Database durch Upgrade / Migration
Upgrade auf Multitenant Schritt 1: Upgrade der alten Datenbank in-place Upgrade in Place
Upgrade auf Multitenant Schritt 2: Aktualisierte Datenbanken einklinken
Upgrade auf Multitenant Schritt 3: Applikationen an Multitenant-Betrieb anpassen
Upgrading to Multitenant Schritt 3: Applikationen an Multitenant-Betrieb anpassen Keine Applikationsänderungen nötig
Migration über Replikation 1 Neue PDB from Seed erzeugen 2 Inhalte replizieren z.b. über Oracle GoldenGate oder Data Pump Neu in 12c: Mit Full Transportable Export / Import können Transportable Tablespaces mit expdp und impdp Kommandos genutzt werden. (Backported auch für 11.2.0.3.) Mehr dazu im Whitepaper: http://www.oracle.com/technetwork/database/enterprise-edition/full-transportable-wp-12c-1973971.pdf
Fazit
Warum eine neue Architektur? Wer braucht eigentlich PDBs? Unser Fazit: Oracle Multitenant hilft allen, die Kosten sparen wollen durch vereinfachtes Management ( many as one ) bessere Konsolidierungsmöglichkeiten Mehr Innovation und weniger Instandhaltung in der IT wollen Nach standardisierten, aber dennoch flexiblen Architekturen suchen (z.b. durch Plug/Unplug )
Reduce Requirements with Oracle Multitenant... save more than 1/3 of memory without any negative impact, even with better sort and buffer-hitrate...... more than the double amount of DBs on a single server...
Multitenant Summary ODA
Wachsendes Geschäft kritische Services und Daten Hochverfügbarkeitslösungen sind wünschenswert Teuer und Komplex Spezielles Wissen nötig Risiko von Fehlern
Oracle Database Appliance X4-2 Vision Einfach: Wizard gesteuerter Einsatz, Patching und Support Geringeres Einsatz Risiko Zuverlässig: Komplette HA Platform für Datenbanken und Applikationen in a box Geringeres Performance Risiko Erschwinglich: Capacity-on-Demand Lizensierung Geringeres Betriebs Risiko
Zeit Kosten Einfach zu Installieren, Managen und Warten Installations Expertise Optimierungs Expertise Netzwerk Administration Einsparung Storage Administration System Administration Oracle Appliance Manager Selbst Zusammen gebaut
Schnelles zur Verfügung stellen eines Datenbank Clusters Einfach zu installieren
Oracle Appliance Manager Einfach zu Managen und zu Warten
Oracle Database Appliance X4-2 Vision Einfach: Wizard gesteuerter Einsatz, Patching und Support Geringeres Einsatz Risiko Zuverlässig: Komplette HA Platform für Datenbanken und Applikationen in a box Geringeres Performance Risiko Erschwinglich: Capacity-on-Demand Lizensierung Geringeres Betriebs Risiko
Eingebaute Zuverlässigkeit Hardware Zwei dual-socket Oracle Linux Server Redundanter 10GbE Interconnect und externes Netzwerk Doppelt- oder Dreifach gespiegelte Storage Redundanz Redundante hot-swappable Netzteile, Kühler und Lüfter Software Oracle Database 11g Enterprise Edition - Real Application Clusters - RAC One Node - Single Instance Oracle Grid Infrastructure - Automatic Storage Management - Oracle Clusterware Oracle Linux und Oracle VM Oracle Appliance Manager
Oracle Database Appliance X4-2 Basis Konfiguration Zwei Server, jeder enthält 24 CPU cores 256 GB memory 600 GB mirrored boot disks Redundant 10GbE interconnect External 10GBase-T networking and optional 10GbE SFP+ Storage Shelf 24 disks 800 GB SSD 18 TB HDD
ODA X4-2 Storage Expansion Shelf Zero-Admin/Online Storage Expansion Doppelte Storage Kapazität verfügbar Additional 18 TB HDD, 36 TB total Additional 800GB SSD, 1.6TB total keine Administration Automatische Integration nach dem verkabeln Daten werden automisch auf der Erweiterung distributiert Online zu erweitern Hot-plug Storage Erweiterungseinheit Kein Datenbank Ausfall
Beste Verfügbarkeit in dieser Klasse Active Active Beste Verfügbarkeit Oracle Database 11g Enterprise Edition Oracle Real Application Clusters Mutual failover und load balancing Active Passive Bessere Verfügbarkeit Oracle Database 11g Enterprise Edition Oracle Real Application Clusters One Node kann mutual failover Single Instance Gute Verfügbarkeit Oracle Database 11g Enterprise Edition
Applikations Support durch Virtualisierung Nutzung der vollen ODA Kapazität ungeachtet von der Datenbank Lizensierung Effizientes teilen der Platform mit einer oder mehr Anwendungen Capacity-on-demand Lizensierung für Datenbank und Anwendungen Workload Isolation zwischen Datenbank und Anwendung Vergrössern/-kleinern von Datenbank und Anwendungs Kapazität
Oracle Database Appliance Virtualisierte Platform Ermöglich Lösungen In-a-Box Node 1 Application Domain Application Domain Application Domain Database Domain Node 2 Application Domain Application Domain Application Domain Database Domain DB s und Anwendungen laufen in einer Box Oracle VM partitioniert jeden Server und ermöglicht unterschiedliche Workloads VLan Netzwerke bringen zusätzliche Sicherheit in die VMs VM HA und automatisch restart Vergrössern/-kleinern von Datenbank und Anwendungs Kapazität
Oracle Database Appliance X4-2 Vision Einfach: Wizard gesteuerter Einsatz, Patching und Support Geringeres Einsatz Risiko Zuverlässig: Komplette HA Platform für Datenbanken und Applikationen in a box Geringeres Performance Risiko Erschwinglich: Capacity-on-Demand Lizensierung Geringeres Betriebs Risiko
Eingebaute Skalierbarkeit
Capacity On Demand Licensing Option 1: Selbst Zusammen gebaut Lizensierung von 48 Cores für Erwartetes Wachstum Option 2: Kauf der Database Appliance Lizensierung von Bedarf mit signifikanter Einsparung 48 Cores 32 Cores 24 Cores 16 Cores 12 Cores OR Kapazität bei Bedarf ergänzen 8 Cores 4 Cores Jahr 1 Jahr 2 Jahr 3 Jahr 1 Jahr 2 Jahr 3 Kauf der vollen Kapazität zu Beginn Kauf von Capacity-on-Demand
Oracle Database Engineered Systems Continuum Engineered für Extreme Simplicity Half Rack Full Rack Eighth Rack Quarter Rack Engineered for Extreme Performance Oracle Database Appliance
In-Memory Europa Launch am 17.06.2014 in Frankfurt http://eventreg.oracle.com/profile/web/index.cfm?pkwebid=0x82157e2f9&source=ev-ie1
Oracle Confidential Internal/Restricted/Highly Restricted 91