Anwendungscontainer

Innerhalb einer CDB können Sie einen Container für Anwendungsdaten und Metadaten erstellen, die von PDBs gemeinsam genutzt werden können.

Informationen zu Anwendungscontainern

Ein Anwendungscontainer ist eine optionale, vom Benutzer erstellte CDB-Komponente, die Daten und Metadaten für ein oder mehrere Anwendungs-Backends speichert. Eine CDB enthält null oder mehr Anwendungscontainer.

In einem Anwendungscontainer ist eine Anwendung die benannte, versionierte Gruppe allgemeiner Daten und Metadaten, die in der Anwendungs-Root gespeichert sind. In diesem Zusammenhang eines Anwendungscontainers bedeutet der Begriff "Anwendung" "Master-Anwendungsdefinition". Die Anwendung kann beispielsweise Definitionen von Tabellen, Views und Packages enthalten.

Beispiel: Sie können mehrere vertriebsbezogene PDBs in einem Anwendungscontainer erstellen, wobei diese PDBs eine Anwendung gemeinsam verwenden, die aus einer Gruppe gemeinsamer Tabellen und Tabellendefinitionen besteht. Sie können mehrere HR-bezogene PDBs in einem separaten Anwendungscontainer mit ihren eigenen gemeinsamen Tabellen und Tabellendefinitionen speichern.

Die CREATE PLUGGABLE DATABASE-Anweisung mit der AS APPLICATION CONTAINER-Klausel erstellt das Anwendungs-Root des Anwendungscontainers und erstellt somit implizit den Anwendungscontainer selbst. Beim ersten Erstellen des Anwendungscontainers enthält er keine PDBs. Um Anwendungs-PDBs zu erstellen, müssen Sie eine Verbindung zur Anwendungs-Root herstellen und dann die Anweisung CREATE PLUGGABLE DATABASE ausführen.

In der CREATE PLUGGABLE DATABASE-Anweisung müssen Sie einen Containernamen (der mit dem Root-Namen der Anwendung identisch ist) angeben. Beispiel: saas_sales_ac. Der Name des Anwendungscontainers muss innerhalb der CDB und im Geltungsbereich aller CDBs eindeutig sein, deren Instanzen über einen bestimmten Listener erreicht werden. Jeder Anwendungscontainer verfügt über einen Standarddienst mit demselben Namen wie der Anwendungscontainer.

Zweck der Anwendungscontainer

In gewisser Weise fungiert ein Anwendungscontainer als anwendungsspezifische CDB innerhalb einer CDB. Ein Anwendungscontainer wie die CDB selbst kann mehrere PDBs umfassen und ermöglicht es diesen PDBs, Metadaten und Daten gemeinsam zu nutzen.

Mit der Anwendungs-Root können Anwendungs-PDBs eine Anwendung gemeinsam nutzen, was in diesem Kontext ein benanntes, versioniertes Set allgemeiner Metadaten und Daten bedeutet. Eine typische Anwendung installiert gemeinsame Benutzer der Anwendung, mit Metadaten verknüpfte gemeinsame Objekte und mit Daten verknüpfte gemeinsame Objekte.

Wichtige Vorteile von Anwendungscontainern

Anwendungscontainer bieten mehrere Vorteile gegenüber dem Speichern jeder Anwendung in einer separaten PDB.

Anwendungscontainer-Anwendungsfall: SaaS

Ein SaaS-Deployment kann mehrere Anwendungs-PDBs verwenden, die jeweils für einen separaten Kunden Metadaten und Daten gemeinsam verwenden.

In einer reinen SaaS-Umgebung befindet sich die Masteranwendungsdefinition in der Anwendungs-Root, die kundenspezifischen Daten befinden sich jedoch in der eigenen Anwendungs-PDB. Beispiel: sales_app ist das Anwendungsmodell im Anwendungs-Root. Die Anwendungs-PDB cust1_pdb enthält nur Umsatzdaten für Kunde 1, während die Anwendungs-PDB cust2_pdb nur Umsatzdaten für Kunde 2 enthält. Plug-in, Trennen, Klonen und andere Vorgänge auf PDB-Ebene sind für einzelne Kunden-PDBs verfügbar.

Abbildung 1: SaaS Anwendungsfall

Beschreibung der Abbildung cncpt389.png

Eine reine SaaS-Konfiguration bietet die folgenden Vorteile:

Anwendungscontainer – Anwendungsfall: Logisches Data Warehouse

Ein Kunde kann mehrere Anwendungs-PDBs verwenden, um Probleme mit der Datensouveränität zu lösen.

In einem Beispielanwendungsfall stellt ein Unternehmen spezifische Daten für jedes Geschäftsquartal in eine separate PDB. Beispiel: Der Anwendungscontainer sales_ac enthält q1_2016_pdb, q2_2016_pdb, q3_2016_pdb und q4_2016_pdb. Sie definieren jede Transaktion in der PDB, die dem zugehörigen Quartal entspricht. Um einen Bericht zu generieren, der die Performance über ein Jahr hinweg aggregiert, aggregieren Sie mit der Klausel CONTAINERS() über die vier PDBs hinweg.

Dieses logische Warehouse-Design bietet folgende Vorteile:

Anwendungs-Root

Ein Anwendungscontainer verfügt über genau eine Anwendungs-Root, die der übergeordneten Anwendungs-PDBs im Container entspricht.

Die Eigenschaft als Anwendungs-Root wird zum Zeitpunkt der Erstellung eingerichtet und kann nicht geändert werden. Der einzige Container, zu dem eine Anwendungs-Root gehört, ist die CDB-Root. Eine Anwendungs-Root ähnelt der CDB-Root auf verschiedene Weise und einer PDB auf andere Weise:

Eine Anwendungs-Root unterscheidet sich sowohl von der CDB-Root als auch von der Standard-PDB, da sie vom Benutzer erstellte gemeinsame Objekte speichern kann, die als allgemeine Anwendungsobjekte bezeichnet werden. Gemeinsame Objekte der Anwendung sind für die Anwendungs-PDBs zugänglich, die in die Anwendungs-Root integriert sind. Gemeinsame Objekte der Anwendung sind für die CDB-Root, andere Anwendungs-Roots oder PDBs, die nicht zur Anwendungs-Root gehören, nicht sichtbar.

Beispiel 3-1: Anwendungs-Root erstellen

In diesem Beispiel melden Sie sich als allgemeiner administrativer Benutzer c##system bei der CDB-Root an. Sie erstellen einen Anwendungscontainer mit dem Namen saas_sales_ac und öffnen dann die Anwendungs-Root, die denselben Namen wie der Container hat.

-- Create the application container called saas_sales_ac
CREATE PLUGGABLE DATABASE saas_sales_ac AS APPLICATION CONTAINER
  ADMIN USER saas_sales_ac_adm IDENTIFIED BY manager;

-- Open the application root
ALTER PLUGGABLE DATABASE saas_sales_ac OPEN;

Sie setzen den aktuellen Container auf saas_sales_ac, und prüfen dann, ob dieser Container die Anwendungs-Root ist:

-- Set the current container to saas_sales_ac
ALTER SESSION SET CONTAINER = saas_sales_ac;

COL NAME FORMAT a15
COL ROOT FORMAT a4
SELECT CON_ID, NAME, APPLICATION_ROOT AS ROOT,
       APPLICATION_PDB AS PDB,
FROM   V$CONTAINERS;

    CON_ID NAME            ROOT PDB
---------- --------------- ---- ---
         3 SAAS_SALES_AC   YES	NO

Für Anwendungscontainer geben Sie die folgenden beiden Parameter im USERENV-Namespace der Funktion SYS_CONTEXT an.

SYS_CONTEXT('USERENV', 'IS_APPLICATION_ROOT')
SYS_CONTEXT('USERENV', 'IS_APPLICATION_PDB')

Der Wert von SYS_CONTEXT('USERENV', 'IS_APPLICATION_ROOT') in einer Anwendungs-Root lautet wie folgt:

SQL> select sys_context('USERENV', 'IS_APPLICATION_ROOT') from dual;

SYS_CONTEXT('USERENV','IS_APPLICATION_ROOT')
--------------------------------------------------------------------------------
YES

Beachten Sie, dass der Wert von SYS_CONTEXT('USERENV', 'IS_APPLICATION_ROOT') mit der Spalte APPLICATION_ROOT in der Ansicht V$PDBS übereinstimmt.

SQL> select application_root from v$pdbs where con_id=sys_context('USERENV', 'CON_ID');

APP
---
YES

Anwendungs-PDBs

Eine Anwendungs-PDB ist eine PDB, die sich in einem Anwendungscontainer befindet. Jede PDB in einer CDB befindet sich entweder in null oder in einem Anwendungscontainer.

Beispiel: Der Anwendungscontainer saas_sales_ac unterstützt mehrere Kunden, wobei jede Kundenanwendung ihre Daten in einer separaten PDB speichert. Die Anwendungs-PDBs cust1_sales_pdb und cust2_sales_pdb befinden sich möglicherweise in saas_sales_ac. In diesem Fall gehören sie keinem anderen Anwendungscontainer an (obwohl sie als PDBs notwendigerweise auch zur CDB-Root gehören).

Erstellen Sie eine Anwendungs-PDB, indem Sie CREATE PLUGGABLE DATABASE ausführen, während Sie bei der Anwendungs-Root angemeldet sind. Sie können die Anwendungs-PDB entweder aus einem Seed erstellen, eine PDB klonen oder eine nicht integrierte PDB integrieren. Wie eine PDB, die an die CDB-Root angeschlossen ist, können Sie eine Anwendungs-PDB klonen, trennen oder löschen. Eine Anwendungs-PDB muss jedoch immer zu einer Anwendungs-Root gehören.

Anwendungs-Seed

Ein Anwendungs-Seed ist eine optionale, vom Benutzer erstellte PDB in einem Anwendungscontainer. Ein Anwendungscontainer hat entweder null oder einen Anwendungs-Seed.

Mit einem Anwendungs-Seed können Sie Anwendungs-PDBs schnell erstellen. Sie dient derselben Rolle im Anwendungscontainer wie PDB$SEED in der CDB selbst.

Der Seed-Name der Anwendung lautet immer application_container_name$SEED, wobei application_container_name der Name des Anwendungscontainers ist. Beispiel: Verwenden Sie die Anweisung CREATE PDB ... AS SEED, um saas_sales_ac$SEED im Anwendungscontainer saas_sales_ac zu erstellen.

Gemeinsame Anwendungsobjekte

Ein allgemeines Anwendungsobjekt ist ein allgemeines Objekt, das in einer Anwendung in einer Anwendungs-Root erstellt wird. Gemeinsame Objekte sind entweder mit Daten verknüpft oder mit Metadaten verknüpft.

Bei einem verknüpften gemeinsamen Objekt verwenden Anwendungs-PDBs ein einzelnes Datenset gemeinsam. Beispiel: Eine Anwendung für den Anwendungscontainer saas_sales_ac hat den Namen saas_sales_app, die Version 1.0 und eine datenverknüpfte Tabelle usa_zipcodes. In diesem Fall werden die Zeilen einmal in der Tabelle in der Anwendungs-Root gespeichert, sind jedoch in allen Anwendungs-PDBs sichtbar.

Bei einem gemeinsamen Metadatenobjekt verwenden Anwendungs-PDBs nur die Metadaten gemeinsam, enthalten jedoch verschiedene Datensets. Beispiel: Eine mit Metadaten verknüpfte Tabelle products hat in jeder Anwendungs-PDB dieselbe Definition, die Zeilen selbst sind jedoch für die PDB spezifisch. Die Anwendungs-PDB mit dem Namen cust1pdb enthält möglicherweise eine products-Tabelle, die Bücher enthält, während die Anwendungs-PDB mit dem Namen cust2pdb möglicherweise eine products-Tabelle enthält, die automatische Teile enthält.

Allgemeine Informationen in einer CDB

Ein häufiges Phänomen, das in einer CDB oder Anwendungs-Root definiert ist, ist in allen Containern, die an diese Root angeschlossen sind, dasselbe.

Grundsätze der Gemeinsamkeit

In einer CDB kann ein Phänomen im Systemcontainer (der CDB selbst) oder in einem bestimmten Anwendungscontainer häufig auftreten.

Beispiel: Wenn Sie einen allgemeinen Benutzeraccount erstellen, während Sie mit CDB$ROOT verbunden sind, gilt dieser Benutzeraccount für alle PDBs und Anwendungs-Roots in der CDB. Wenn Sie jedoch einen allgemeinen Benutzeraccount für die Anwendung erstellen, während Sie mit einer Anwendungs-Root verbunden sind, wird dieser Benutzeraccount nur für die PDBs in diesem Anwendungscontainer verwendet.

Im Kontext von CDB$ROOT oder einem Anwendungs-Root gelten folgende Grundsätze der Gemeinsamkeit:

Namespaces in einer CDB

In einer CDB wird der Namespace für jedes Objekt auf seinen Container begrenzt.

Die folgenden Grundsätze fassen die Geltungsbereichsregeln zusammen:

Die vorhergehenden Prinzipien haben Auswirkungen auf lokale und gemeinsame Phänomene.

Lokale Phänomene

Ein lokales Phänomen muss eindeutig innerhalb eines Containers benannt werden, jedoch nicht über alle Container in der CDB. Identisch genannte lokale Phänomene in verschiedenen Containern sind unterschiedlich. Beispiel: Der lokale Benutzer sh in einer PDB steht nicht im Konflikt mit dem lokalen Benutzer sh in einer anderen PDB.

CDB$ROOT Allgemeine Phänomene

Allgemeine Phänomene, die in CDB$ROOT definiert sind, sind in mehreren Containern vorhanden und müssen in jedem dieser Namespaces eindeutig sein. Beispiel: Die CDB-Root enthält vordefinierte gemeinsame Benutzer, wie SYSTEM und SYS. Um die Namespace-Trennung sicherzustellen, verhindert Oracle AI Database die Erstellung eines SYSTEM-Benutzers in einem anderen Container.

Um die Namespace-Trennung sicherzustellen, muss der Name der vom Benutzer erstellten allgemeinen Phänomene in der CDB-Root mit dem durch den Initialisierungsparameter COMMON_USER_PREFIX angegebenen Wert beginnen. Das Standardpräfix ist c## oder C##. Die Namen aller anderen vom Benutzer erstellten Phänomene dürfen nicht mit c## oder C## beginnen. Beispiel: Sie können keinen lokalen Benutzer in hrpdb namens c##hr erstellen und auch keinen allgemeinen Benutzer in der CDB-Root namens hr erstellen.

Anwendung Allgemeine Phänomene

Innerhalb eines Anwendungscontainers dürfen Namen für lokale und anwendungsspezifische Phänomene nicht in Konflikt geraten.

Siehe auch: Oracle AI Database - Sicherheitshandbuch, um mehr über allgemeine Benutzer und Rollen zu erfahren

Gemeinsame Anwendungsobjekte erstellen

Um gemeinsame Objekte zu erstellen, melden Sie sich bei einer Anwendungs-Root an, und führen Sie dann eine CREATE-Anweisung aus, die ein gemeinsames Attribut angibt.

Allgemeine Anwendungsobjekte können nur im Rahmen einer Anwendungsinstallation, eines Upgrades oder eines Patches erstellt oder geändert werden. Sie können die gemeinsame Nutzung wie folgt festlegen:

In der folgenden Tabelle sind die Typen allgemeiner Anwendungsobjekte und der Speicherort der Daten und Metadaten aufgeführt.

Tabelle 1: Allgemeine Anwendungsobjekte

Objekttyp SHARING-Wert Metadatenspeicher Datenspeicherung
Datenverknüpfung DATA Anwendungs-Root Anwendungs-Root
Erweiterte Datenverknüpfung EXTENDED DATA Anwendungs-Root Anwendungs-Root und Anwendungs-PDB
Mit Metadaten verknüpft METADATA Anwendungs-Root Anwendungs-PDB

Siehe auch: Im Oracle AI Database - Sicherheitshandbuch erfahren Sie, wie Sie Berechtigungen für gemeinsame Objekte verwalten.

Gemeinsame Objekte für mit Metadaten verknüpfte Anwendungen

Ein Metadatenlink ist ein Dictionary-Objekt, das das Verweisen auf gemeinsame Metadaten, die von allen PDBs im Anwendungscontainer gemeinsam verwendet werden, und das Erteilen von Berechtigungen für diese unterstützt.

Wenn Sie den Wert METADATA entweder in der Klausel SHARING oder im Initialisierungsparameter DEFAULT_SHARING angeben, wird ein Link zu den Metadaten eines Objekts angegeben, der als allgemeines mit Metadaten verknüpftes Objekt bezeichnet wird. Die Metadaten für das Objekt werden einmal in der Anwendungs-Root gespeichert.

Tabellen, Views und Code-Objekte (wie PL/SQL-Prozeduren) können Metadaten gemeinsam verwenden. In diesem Kontext umfasst "Metadaten" Spaltendefinitionen, Constraints, Trigger und Code. Beispiel: Wenn sales_mlt eine mit Metadaten verknüpfte allgemeine Tabelle ist, greifen alle Anwendungs-PDBs über einen Metadatenlink auf die gleiche Definition dieser Tabelle zu, die in der Anwendungs-Root gespeichert ist. Die Zeilen in sales_mlt sind in jeder Anwendungs-PDB unterschiedlich, die Spaltendefinitionen sind jedoch identisch.

In der Regel sind die meisten Objekte in einer Anwendung mit Metadaten verknüpft. Daher müssen Sie nur eine Master-Anwendungsdefinition verwalten. Dieser Ansatz zentralisiert die Verwaltung der Anwendung in mehreren Anwendungs-PDBs.

Beispiel 3-2: Mit Metadaten verknüpftes gemeinsames Objekt erstellen

In diesem Beispiel meldet sich der Benutzer SYSTEM beim Anwendungscontainer saas_sales_ac an. SYSTEM installiert eine Anwendung namens saas_sales_app in Version 1.0. Diese Anwendung erstellt einen allgemeinen Benutzeraccount mit dem Namen saas_sales_adm. Das Schema enthält eine mit Metadaten verknüpfte allgemeine Tabelle namens sales_mlt.

-- Begin the install of saas_sales_app
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app BEGIN INSTALL '1.0';

-- Create the tablespace for the app
CREATE TABLESPACE saas_sales_tbs DATAFILE SIZE 100M AUTOEXTEND ON NEXT 10M MAXSIZE 200M;

-- Create the user account saas_sales_adm, which will own the app
CREATE USER saas_sales_adm IDENTIFIED BY ****** CONTAINER=ALL;

-- Grant necessary privileges to this user account
GRANT CREATE SESSION, DBA TO saas_sales_adm;

-- Makes the tablespace that you just created the default for saas_sales_adm
ALTER USER saas_sales_adm DEFAULT TABLESPACE saas_sales_tbs;

-- Now connect as the application owner
CONNECT saas_sales_adm/******@saas_sales_ac

-- Create a metadata-linked table
CREATE TABLE saas_sales_adm.sales_mlt SHARING=METADATA
(YEAR       NUMBER(4),
 REGION     VARCHAR2(10),
 QUARTER    VARCHAR2(4),
 REVENUE    NUMBER);

-- End the application installation
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app END INSTALL '1.0';

Mit der ALTER PLUGGABLE DATABASE APPLICATION ... SYNC-Anweisung können Sie die Anwendungs-PDBs synchronisieren, um dieselbe Masteranwendungsdefinition zu verwenden. Auf diese Weise verfügt jede Anwendungs-PDB über einen Metadatenlink zur gemeinsamen Tabelle saas_sales_adm.sales_mlt. Der Middle Tier-Code, der sales_mlt in der PDB mit dem Namen cust1_pdb aktualisiert, fügt dieser Tabelle in cust1_pdb Zeilen hinzu, während der Middle Tier-Code, der sales_mlt in cust2_pdb aktualisiert, der Kopie dieser Tabelle in cust2_pdb Zeilen hinzufügt. Nur die Tabellenmetadaten, die im Anwendungs-Root gespeichert sind, werden gemeinsam verwendet. Hinweis: Oracle AI Database Security Guide, um mehr darüber zu erfahren, wie häufig erteilte Objektberechtigungen funktionieren

Metadatenlinks

Bei gemeinsamen, mit Metadaten verknüpften Anwendungsobjekten werden die Metadaten für das Objekt einmal in der Anwendungs-Root gespeichert. Ein Metadatenlink ist ein Dictionary-Objekt, dessen Objekttyp mit den Metadaten identisch ist, die er gemeinsam verwendet.

Die Beschreibung eines Metadatenlinks wird im Data Dictionary der PDB gespeichert, in der er erstellt wird. Ein gemeinsamer Benutzer einer Anwendung muss Eigentümer eines Metadatenlinks sein. Sie können Metadatenlinks nur verwenden, um Metadaten gemeinsamer Objekte freizugeben, deren Eigentümer der Ersteller in der CDB-Root oder einer Anwendungs-Root ist.

Im Gegensatz zu einem Datenlink hängt ein Metadatenlink nur von gemeinsamen Daten ab. Beispiel: Wenn eine Anwendung die lokalen Tabellen dow_close_lt und nasdaq_close_lt im Anwendungs-Root enthält, kann ein allgemeiner Benutzer keine Metadatenlinks zu diesen Objekten erstellen. Eine gemeinsame Anwendungstabelle mit dem Namen sales_mlt kann jedoch mit Metadaten verknüpft sein.

Wenn ein berechtigter allgemeiner Benutzer die Metadaten für sales_mlt ändert, z.B. eine Spalte zur Tabelle hinzufügt, wird diese Änderung an die Metadatenlinks propagiert. Anwendungs-PDB-Benutzer dürfen die Metadaten im Metadaten-Link nicht ändern. Beispiel: Ein DBA, der die Anwendungs-PDB mit dem Namen cust1_pdb verwaltet, kann sales_mlt nur in dieser PDB eine Spalte hinzufügen: Solche Metadatenänderungen können nur in der Anwendungs-Root vorgenommen werden.

Gemeinsame Objekte für datengebundene Anwendungen

Ein mit Daten verknüpftes Objekt ist ein Objekt, dessen Metadaten und Daten in einer Anwendungs-Root gespeichert sind und von allen Anwendungs-PDBs in diesem Anwendungscontainer aus zugänglich sind.

Wenn Sie den Wert DATA entweder in der Klausel SHARING oder im Initialisierungsparameter DEFAULT_SHARING angeben, wird ein Link zu einem gemeinsamen Objekt angegeben, das als allgemeines datenverknüpftes Objekt bezeichnet wird. Dimensionstabellen in einem Data Warehouse eignen sich häufig für datenverknüpfte gemeinsame Tabellen.

Ein Datenlink ist ein Dictionary-Objekt, das ähnlich wie ein Synonym funktioniert. Beispiel: Wenn countries eine gemeinsame Anwendungstabelle ist, greifen alle Anwendungs-PDBs über einen Datenlink auf die gleiche Kopie dieser Tabelle zu. Wenn dieser Tabelle eine Zeile hinzugefügt wird, ist diese Zeile in allen Anwendungs-PDBs sichtbar.

Ein gemeinsamer Benutzer einer Anwendung muss Eigentümer eines Datenlinks sein. Der Link erbt den Objekttyp von dem Objekt, auf das er zeigt. Die Beschreibung eines Datenlinks wird im Dictionary der PDB gespeichert, in der er erstellt wird. Beispiel: Wenn ein Anwendungscontainer 10 Anwendungs-PDBs enthält und jede PDB einen Link zur gemeinsamen Tabelle der countries-Anwendung enthält, enthalten alle 10 PDBs Dictionary-Definitionen für diesen Link.

Beispiel 3-3: Datenverknüpftes Objekt erstellen

In diesem Beispiel stellt SYSTEM eine Verbindung zum Anwendungscontainer saas_sales_ac her. SYSTEM führt ein Upgrade der Anwendung saas_sales_app von Version 1.0 auf 2.0 durch. Dieses Anwendungsupgrade meldet sich als allgemeiner Benutzer saas_sales_adm beim Container an, erstellt eine datenverknüpfte Tabelle mit dem Namen countries_dlt und fügt dann Zeilen in den Container ein.

-- Begin an upgrade of the application
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app BEGIN UPGRADE '1.0' to '2.0';

-- Connect as application owner to application root
CONNECT saas_sales_adm/manager@saas_sales_ac

-- Create data-linked table named countries_dlt
CREATE TABLE countries_dlt SHARING=DATA
(country_id   NUMBER,
 country_name VARCHAR2(20));

-- Insert records into countries_dlt
INSERT INTO countries_dlt VALUES(1, 'USA');
INSERT INTO countries_dlt VALUES(44, 'UK');
INSERT INTO countries_dlt VALUES(86, 'China');
INSERT INTO countries_dlt VALUES(91, 'India');

-- End application upgrade
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app END UPGRADE TO '2.0';

Verwenden Sie die Anweisung ALTER PLUGGABLE DATABASE APPLICATION ... SYNC, um Anwendungs-PDBs mit der Anwendungs-Root zu synchronisieren. Auf diese Weise verfügt jede synchronisierte Anwendungs-PDB über einen Datenlink zur Data-Link-Tabelle saas_sales_adm.countries_dlt.

Erweiterte datenverbundene Anwendungsobjekte

Ein erweitertes datenverknüpftes Objekt ist eine Mischung aus einem datenverknüpften Objekt und einem mit Metadaten verknüpften Objekt.

In einem erweiterten datenverknüpften Objekt sind die in der Anwendungs-Root gespeicherten Daten allen Anwendungs-PDBs gemeinsam, und alle PDBs können auf diese Daten zugreifen. Jede Anwendungs-PDB kann jedoch eigene PDB-spezifische Daten erstellen, während die gemeinsamen Daten in der Anwendungs-Root freigegeben werden. Daher ergänzen die PDBs die gemeinsamen Daten mit ihren eigenen Daten.

Beispiel: Eine Sales-Anwendung unterstützt mehrere Anwendungs-PDBs. Alle Anwendungs-PDBs benötigen die Postleitzahlen für die Vereinigten Staaten. In diesem Fall können Sie eine erweiterte Data-Link-Tabelle zipcodes_edt im Anwendungs-Root erstellen. Im Anwendungsstammverzeichnis werden die Postleitzahlen der USA gespeichert, sodass alle Anwendungs-PDBs darauf zugreifen können. Für eine Anwendungs-PDB sind jedoch die Postleitzahlen für die USA und Kanada erforderlich. Diese Anwendungs-PDB kann die Postleitzahlen für Kanada im erweiterten datenverknüpften Objekt in der Anwendungs-PDB statt in der Anwendungs-Root speichern.

Erstellen Sie ein erweitertes Data-Linked-Objekt, indem Sie eine Verbindung zum Anwendungs-Root herstellen und das Schlüsselwort SHARING=EXTENDED DATA in der CREATE-Anweisung angeben.

Beispiel 3-4: Erweitertes Datenobjekt erstellen

In diesem Beispiel stellt SYSTEM eine Verbindung zum Anwendungscontainer saas_sales_ac her und aktualisiert dann die Anwendung saas_sales_app (erstellt in "Beispiel 3-2") von Version 2.0 auf 3.0. Diese Anwendung meldet sich als allgemeiner Benutzer saas_sales_adm beim Container an, erstellt eine erweiterte Data-Link-Tabelle namens zipcodes_edt und fügt dann Zeilen in den Container ein.

-- Begin an upgrade of the app
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app BEGIN UPGRADE '2.0' to '3.0';

-- Connect as app owner to app root
CONNECT saas_sales_adm/manager@saas_sales_ac

-- Create a common-data table named zipcodes_edt
CREATE TABLE zipcodes_edt SHARING=EXTENDED DATA
(code       VARCHAR2(5),
 country_id NUMBER,
 region     VARCHAR2(10));

-- Load rows into zipcodes_edt
INSERT INTO zipcodes_edt VALUES ('08820','1','East');
INSERT INTO zipcodes_edt VALUES ('10005','1','East');
INSERT INTO zipcodes_edt VALUES ('44332','1','North');
INSERT INTO zipcodes_edt VALUES ('94065','1','West');
INSERT INTO zipcodes_edt VALUES ('73301','1','South');
COMMIT;

-- End app upgrade
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app END UPGRADE TO '3.0';

Mit der ALTER PLUGGABLE DATABASE APPLICATION ... SYNC-Anweisung können Sie Anwendungs-PDBs mit der Anwendung synchronisieren. Auf diese Weise verfügt jede synchronisierte Anwendungs-PDB über einen Datenlink zur Data-Link-Tabelle saas_sales_adm.zipcodes_edt. Anwendungen, die eine Verbindung zu diesen PDBs herstellen, können die Postleitzahlen anzeigen, die während des Anwendungsupgrades in zipcodes_edt eingefügt wurden. Sie können jedoch auch eigene Postleitzahlen in diese Tabelle einfügen.

Containerzuordnungen

Mit einer Containerzuordnung kann eine mit der Anwendungs-Root verbundene Session SQL-Anweisungen absetzen, die je nach Wert eines in der SQL-Anweisung verwendeten Prädikats an die entsprechende PDB weitergeleitet werden.

Eine Zuordnungstabelle gibt eine Spalte in einer mit Metadaten verknüpften gemeinsamen Tabelle an und verwendet Partitionen, um verschiedene Anwendungs-PDBs mit verschiedenen Spaltenwerten zu verknüpfen. Auf diese Weise ermöglichen Container-Maps die Partitionierung von Daten auf PDB-Ebene, wenn die Daten nicht physisch auf Tabellenebene partitioniert sind.

Die wichtigsten Komponenten für die Verwendung von Container-Maps sind:

Beispiel 3-5: Metadaten-verknüpfte Tabelle, Map-Tabelle und Container-Map erstellen – Teil 1

In diesem Beispiel melden Sie sich als Anwendungsadministrator beim Anwendungs-Root an. Angenommen, ein Anwendungscontainer hat drei Anwendungs-PDBs: amer_pdb, euro_pdb und asia_pdb. Jede Anwendungs-PDB speichert Ländernamen für eine andere Region. Eine mit Metadaten verknüpfte Tabelle namens oe.countries_mlt enthält eine Spalte cname, in der der Name des Landes gespeichert wird. Bei dieser Partitionierungsstrategie erstellen Sie mithilfe von Partition nach Liste ein Zuordnungsobjekt mit dem Namen salesadm.pdb_map_tbl, das eine Partition für jede Region erstellt. Der Ländername bestimmt die Region.

ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app BEGIN INSTALL '1.0';

-- Create the metadata-linked table.
CREATE TABLE oe.countries_mlt SHARING=METADATA (
  region    VARCHAR2(30),
  cname     VARCHAR2(30));

-- Create the partitioned map table, which is list partitioned on the
-- cname column. The names of the partitions are the names of the
-- application PDBs.
CREATE TABLE salesadm.pdb_map_tbl (cname VARCHAR2(30) NOT NULL)
  PARTITION BY LIST (cname) (
    PARTITION amer_pdb VALUES ('US','MEXICO','CANADA'),
    PARTITION euro_pdb VALUES ('UK','FRANCE','GERMANY'),
    PARTITION asia_pdb VALUES ('INDIA','CHINA','JAPAN'));

-- Set the CONTAINER_MAP database property to the map object.
ALTER PLUGGABLE DATABASE SET CONTAINER_MAP='salesadm.pdb_map_tbl';

-- Enable the container map for the metadata-linked table to be queried.
ALTER TABLE oe.countries_mlt ENABLE CONTAINER_MAP;

-- Ensure that the table to be queried is enabled for the
-- CONTAINERS clause.
ALTER TABLE oe.countries_mlt ENABLE CONTAINERS_DEFAULT;

-- End the application installation.
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app END INSTALL '1.0';

Hinweis: Obwohl Sie Containerzuordnungen mit Partitionierungssyntax erstellen, verwendet die Datenbank keine Partitionierungsfunktionalität. Für das Definieren einer Containerzuordnung ist Oracle Partitioning nicht erforderlich.

Im vorherigen Skript gibt die ALTER TABLE oe.countries_mlt ENABLE CONTAINERS_DEFAULT-Anweisung an, dass Abfragen und DML-Anweisungen, die in der Anwendungs-Root abgesetzt wurden, standardmäßig die CONTAINERS()-Klausel für das Datenbankobjekt verwenden müssen.

Beispiel 3-6: Anwendung synchronisieren und Daten hinzufügen – Teil 2

Dieses Beispiel wird im vorherigen Beispiel fortgesetzt. Während Sie mit der Anwendungs-Root verbunden sind, wechseln Sie den aktuellen Container wiederum zu jeder PDB, synchronisieren die Anwendung saas_sales_app und fügen dann PDB-spezifische Daten zur Tabelle oe.countries_mlt hinzu.

ALTER SESSION SET CONTAINER=amer_pdb;
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC;
INSERT INTO oe.countries_mlt VALUES ('AMER','US');
INSERT INTO oe.countries_mlt VALUES ('AMER','MEXICO');
INSERT INTO oe.countries_mlt VALUES ('AMER','CANADA');
COMMIT;

ALTER SESSION SET CONTAINER=euro_pdb;
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC;
INSERT INTO oe.countries_mlt VALUES ('EURO','UK');
INSERT INTO oe.countries_mlt VALUES ('EURO','FRANCE');
INSERT INTO oe.countries_mlt VALUES ('EURO','GERMANY');
COMMIT;

ALTER SESSION SET CONTAINER=asia_pdb;
ALTER PLUGGABLE DATABASE APPLICATION saas_sales_app SYNC;
INSERT INTO oe.countries_mlt VALUES ('ASIA','INDIA');
INSERT INTO oe.countries_mlt VALUES ('ASIA','CHINA');
INSERT INTO oe.countries_mlt VALUES ('ASIA','JAPAN');
COMMIT;

Beispiel 3-7: Metadaten-verknüpfte Tabelle abfragen – Teil 3

Dieses Beispiel wird im vorherigen Beispiel fortgesetzt. Sie stellen eine Verbindung zum Anwendungs-Root her und fragen oe.countries_mlt dann mehrmals ab, indem Sie verschiedene Länder in der WHERE-Klausel angeben. Die Abfrage gibt den richtigen Wert aus der Spalte oe.countries_mlt.region zurück.

ALTER SESSION SET CONTAINER=saas_sales_ac;

SELECT region FROM oe.countries_mlt WHERE cname='MEXICO';

REGION
------
AMER

SELECT region FROM oe.countries_mlt WHERE cname='GERMANY';

REGION
------
EURO

SELECT region FROM oe.countries_mlt WHERE cname='JAPAN';

REGION
------
ASIA

Containerübergreifende Vorgänge

Ein Cross-Container-Vorgang ist eine DDL- oder DML-Anweisung, die sich auf mehrere Container gleichzeitig auswirkt.

Nur ein allgemeiner Benutzer, der mit der CDB-Root oder einem Anwendungs-Root verbunden ist, kann Container-übergreifende Vorgänge ausführen. Ein Cross-Container-Vorgang kann sich auf Folgendes auswirken:

Beispiele für Container-DDL-Vorgänge: Benutzer SYSTEM, der einem anderen allgemeinen Benutzer eine Berechtigung erteilt, und eine ALTER DATABASE . . . RECOVER-Anweisung, die für die gesamte CDB gilt.

Wenn Sie mit der CDB-Root oder einer Anwendungs-Root verbunden sind, können Sie eine einzelne DML-Anweisung ausführen, um Tabellen oder Views in mehreren PDBs im Container zu ändern. Die Datenbank leitet die Ziel-PDBs aus dem Wert der Spalte CON_ID ab, die in der DML-Anweisung angegeben ist. Wenn kein CON_ID angegeben ist, verwendet die Datenbank die Eigenschaft CONTAINERS_DEFAULT_TARGET, die von der ALTER PLUGGABLE DATABASE CONTAINERS DEFAULT TARGET-Anweisung angegeben wird.

Beispiel 3-8: Mehrere PDBs in einer einzelnen DML-Anweisung aktualisieren

In diesem Beispiel ist es Ihr Ziel, die Spalte country_name in der Tabelle sh.sales auf den Wert USA zu setzen. Diese Tabelle ist in zwei separaten PDBs mit den Container-IDs 7 und 8 vorhanden. Beide PDBs befinden sich im Anwendungscontainer saas_sales_ac. Sie können sich als Administrator bei der Anwendungs-Root anmelden und das Update wie folgt durchführen:

CONNECT sales_admin@saas_sales_ac
Password: *******

UPDATE CONTAINERS(sh.sales) sal
  SET sal.country_name = 'USA'
  WHERE sal.CON_ID IN (7,8);

In der vorherigen UPDATE-Anweisung ist sal ein Alias für CONTAINERS(sh.sales).

Siehe auch: "Allgemeine Benutzerkonten"