Oracle Database 12c Multitenant + ODA

Transkript

1

2 Oracle Database 12c Multitenant + ODA Michael Reick Technischer Account Manager Oracle Deutschland B.V. & Co. KG Oracle Confidential Internal/Restricted/Highly Restricted

3 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

4 Multitenant Summary ODA

5 Oracle Multitenant Idee und Architektur

6 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

7 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

8 Oracle Datenbank Architektur Benötigt Hauptspeicher, Prozesse und Datenbank Dateien System-Ressourcen

9 Die neue Multitenant Architektur System-Ressourcen Hauptspeicher und Prozesse werden nur noch auf Ebene des multitenant containers benötigt

10 Die neue Multitenant Architektur Hauptspeicher und Prozesse werden nur noch auf Ebene des multitenant containers benötigt System-Ressourcen

11 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

12 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.

13 Multitenant Architekture Dynamische Anteile PDBs teilen sich SGA und Hintergrundprozesse Vordergrundprozesse (DB Sessions) sehen nur die PDB an der sie angemeldet sind

14 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

15 Nutzungsmöglichkeiten von Oracle Multitenant

16 Manage Many as One mit Multitenant Gemeinsames DB-Backup; Recovery auf Pluggable Database Ebene Ein Backup Point-in-time Recovery auf Pluggable Database - Ebene

17 Manage Many as One mit Multitenant Eine Standby Datenbank deckt alle Pluggable Databases ab

18 Multitenant für vereinfachtes Patching Änderungen nur einmal anwenden, alle Pluggable Databases sind aktualisiert Upgrade in-place

19 Multitenant für Upgrades Flexibilität beim Patchen und & Upgraden von Datenbanken

20 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)

21 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)

22 Multitenant für schnelles Ausrollen von DBs Pluggable Datenbanken können schnell aus seed DB erzeugt werden

23 Multitenant für schnelles Ausrollen von DBs PDBs können innerhalb der gleichen CDB geklont werden PDBs können aus remote CDBs geklont werden

24 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

25 1. Multitenant für Test und Entwicklung Schnelle, flexible Kopien und Snapshots von Pluggable Databases

26 2. Konsolidierung von vereinzelten Anwendungen Teilt den Overhead von Speicher und Prozessen System-Ressourcen

27 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

28 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

29 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

30 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

31 Besonderheiten und Eigenschaften von Oracle Multitenant

32 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

33 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

34 Unplug / Plug Einfach aus der alten CDB ausklinken

35 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.

36 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'

37 Ressourcenverwaltung für Pluggable Databases

38 Verwalten von geteilten Ressourcen Resource Management in einer Multitenant Umgebung Hohe Priorität Niedrige Priorität Mittlere Priorität

39 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 )

40 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%)

41 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%

42 Erstellung einer Pluggable Database

43 Anlegen einer CDB Am besten mit dbca

44 Klonen einer PDB Beispiel Lokal create pluggable database HCMBI from HCM Remote (über DB Link) create pluggable database HCMBI from

45 Erzeugen einer Pluggable Database durch Upgrade / Migration

46 Upgrade auf Multitenant Schritt 1: Upgrade der alten Datenbank in-place Upgrade in Place

47 Upgrade auf Multitenant Schritt 2: Aktualisierte Datenbanken einklinken

48 Upgrade auf Multitenant Schritt 3: Applikationen an Multitenant-Betrieb anpassen

49 Upgrading to Multitenant Schritt 3: Applikationen an Multitenant-Betrieb anpassen Keine Applikationsänderungen nötig

50 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 ) Mehr dazu im Whitepaper:

51 Fazit

52 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 )

53 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...

54 Multitenant Summary ODA

55 Wachsendes Geschäft kritische Services und Daten Hochverfügbarkeitslösungen sind wünschenswert Teuer und Komplex Spezielles Wissen nötig Risiko von Fehlern

56 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

57 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

58 Schnelles zur Verfügung stellen eines Datenbank Clusters Einfach zu installieren

59 Oracle Appliance Manager Einfach zu Managen und zu Warten

61 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

62 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

63 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

64 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

65 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

66 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

68 Eingebaute Skalierbarkeit

69 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

70 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

71 In-Memory Europa Launch am in Frankfurt

72 Oracle Confidential Internal/Restricted/Highly Restricted 91

73