Oracle Multitenant

Oracle Multitenant
Verwaltung von Pluggable Databases –
Handling und Besonderheiten
Ralf Lange
Oracle Deutschland B.V. & Co KG
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”
Common Users und Privilegien
Authorisierung wird genauso geprüft wie vor 12.1
 Einem “common user” können Privilegien lokal für eine PDB (oder
“root”) zugewiesen werden und daher in jedem Container
unterschiedlich sein
 Alternativ können einem “common user” System Privilegien auch
allgemein (“commonly”) zugewiesen werden – der Grant gilt dann im
root und jeder PDB (ggf. auch in zukünftigen)
 Es können “common roles” erstellt werden
 Eine “common role” kann einem “common user” allgemein
(“commonly”) zugewiesen werden
 Autorisierung erfolgt ausschließlich mit den Rechten die der User in
dem Container hat, im dem er das SQL ausführen will
Sicherheitsaspekte bei Multitenant
Einige zusätzliche Überlegungen…
 Der CDB-Admin ist sehr mächtig und hat eine zentrale Rolle
– Er „sieht alles“ und „darf alles“ in allen PDBs – auch in importierten
– Vorsicht daher beim „plug“ einer PDB in eine neue CDB mit
anderem Admin / anderen Sicherheitseinstellungen
 Verschlüsselung genutzt?
– Master Key wird im Keystore auf CDB-Ebene verwaltet…
– …muss bei Unplug/Plug entsprechend exportiert/importiert werden
Nutzung einer PDB als User
 Grundsätzlich: Anmeldung an einer PDB nur über entspr. Service
 Connect OHNE Service meint implizit immer die CDB!
 Innerhalb einer Session möglich: ‘alter session set container=…’
 Daraus folgt:
– Skripte etc. anpassen!
– Achtung besonders bei Administrationstätigkeiten:
“Connect / as sysdba” gilt ebenfalls für CDB und nicht für eine PDB
 Mitgeliefertes Skript “catcon.pl” (in …/rdbms/admin ) bietet
“Wrapper”-Funktionalität zur Ausführung von Skripten gegen PDBs
– …auch für mehrere PDBs (“Batchbetrieb”)
– ggf. auch parallel
– Mehr dazu: https://blogs.oracle.com/dbacommunity_deutsch/entry/12c_pluggable_database_sql_skripte
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'
Demo: Umgang mit Pluggable Databases
Trigger für CDBs / PDBs
Sinnvoll für Automatisierung / Batchbetrieb
 Beim Start einer CDB alle darin enthaltenen PDBs automatisch starten:
– → „AFTER STARTUP“ Trigger in der CDB anlegen mit
EXECUTE IMMEDIATE 'ALTER PLUGGABLE DATABASE ALL OPEN';
 “AFTER CLONE on pluggable database” Trigger in der PDB zündet
in “frischem Klon”:
– Z.B. zum Tabellen anlegen / Stammdaten erzeugen/laden…
– Wird nach Ausführung gelöscht!
 “AFTER UNPLUG on pluggable database” Trigger in der PDB:
– Z.B. für “Aufräumarbeiten”
– Wird nach Ausführung gelöscht!
“pro PDB” vs “pro CDB”
Feingranulare Kontrolle wo angemessen –
trotz gemeinsamer CDB-Operationen
Pro CDB
Pro PDB
Eine Oracle Software Version
RMAN point-in-time recovery
Data Guard
“Ad hoc” RMAN Backups
Geplante RMAN Backups
Möglichkeit für “…flush shared_pool”
Einige Eigenschaften/Parameter,
z.B. einheitl. Character Set
Parameter für die gilt
Redo und Undo
IsPDB_Modifiable = 'TRUE'
Ressourcenverwaltung
für Pluggable Databases
Verwalten von geteilten Ressourcen
Resource Management in einer Multitenant Umgebung
Niedrige Priorität
Mittlere Priorität
Hohe 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%