Conteneurs d'application

Dans une base de données Conteneur, vous pouvez créer un conteneur pour les données et les métadonnées d'application qui peuvent être partagées par les bases pluggables.

A propos des conteneurs d'application

Un conteneur d'application est un composant de base de données Conteneur facultatif créé par l'utilisateur qui stocke les données et les métadonnées pour un ou plusieurs back-ends d'application. Une base de données Conteneur inclut zéro ou plusieurs conteneurs d'application.

Dans un conteneur d'application, une application est l'ensemble nommé avec numéro de version des données et métadonnées communes stockées dans la racine de l'application. Dans ce contexte de conteneur d'application, le terme "application" signifie "définition d'application principale". Par exemple, l'application peut inclure des définitions de tables, de vues et de packages.

Par exemple, vous pouvez créer plusieurs bases pluggables liées aux ventes dans un conteneur d'application, ces bases partageant une application composée d'un ensemble de tables et de définitions de table communes. Vous pouvez stocker plusieurs bases pluggables liées aux ressources humaines dans un conteneur d'application distinct, avec leurs propres tables et définitions de table communes.

L'instruction CREATE PLUGGABLE DATABASE avec la clause AS APPLICATION CONTAINER crée la racine d'application du conteneur d'application et crée donc implicitement le conteneur d'application lui-même. Lorsque vous créez le conteneur d'application pour la première fois, il ne contient aucune base de données pluggable. Pour créer des bases pluggables d'application, vous devez vous connecter à la racine de l'application, puis exécuter l'instruction CREATE PLUGGABLE DATABASE.

Dans l'instruction CREATE PLUGGABLE DATABASE, vous devez indiquer un nom de conteneur (qui est identique au nom de la racine d'application), par exemple, saas_sales_ac. Le nom du conteneur d'application doit être unique au sein de la base de données Conteneur et dans la portée de toutes les bases de données Conteneur dont les instances sont atteintes via un processus d'écoute spécifique. Chaque conteneur d'application possède un service par défaut portant le même nom que le conteneur d'application.

Finalité des conteneurs d'application

D'une certaine manière, un conteneur d'application fonctionne comme une base de données Conteneur propre à l'application dans une base de données Conteneur. Un conteneur d'application, comme la base de données Conteneur elle-même, peut inclure plusieurs bases de données pluggables et permet à ces bases de données pluggables de partager des métadonnées et des données.

La racine d'application permet aux bases de données pluggables d'application de partager une application, ce qui signifie dans ce contexte un ensemble nommé et géré par version de métadonnées et de données communes. Une application classique installe des utilisateurs communs d'application, des objets communs liés aux métadonnées et des objets communs liés aux données.

Principaux avantages des conteneurs d'application

Les conteneurs d'application offrent plusieurs avantages par rapport au stockage de chaque application dans une base de données pluggable distincte.

Cas d'utilisation du conteneur d'applications : SaaS

Un déploiement SaaS peut utiliser plusieurs bases de données pluggables d'application, chacune pour un client distinct, qui partagent des métadonnées et des données.

Dans un environnement SaaS pur, la définition de l'application maître réside dans la racine de l'application, mais les données propres au client résident dans sa propre base de données pluggable d'application. Par exemple, sales_app est le modèle d'application dans la racine d'application. La base de données pluggable d'application nommée cust1_pdb contient les données de vente uniquement pour le client 1, tandis que la base de données pluggable d'application nommée cust2_pdb contient les données de vente uniquement pour le client 2. Les opérations de connexion, de déconnexion, de clonage et autres opérations au niveau des bases de données pluggables sont disponibles pour les bases de données pluggables client individuelles.

Figure 1 : Cas d'utilisation de SaaS

Description de l'image cncpt389.png

Une configuration SaaS pure offre les avantages suivants :

Cas d'utilisation des conteneurs d'application : Entrepôt de données logique

Un client peut utiliser plusieurs bases de données pluggables d'application pour résoudre les problèmes de souveraineté des données.

Dans un exemple de cas d'utilisation, une entreprise place les données propres à chaque trimestre financier dans une base de données pluggable distincte. Par exemple, le conteneur d'application nommé sales_ac inclut q1_2016_pdb, q2_2016_pdb, q3_2016_pdb et q4_2016_pdb. Vous définissez chaque transaction dans la base de données pluggable correspondant au trimestre associé. Pour générer un état qui agrège les performances sur une année, vous agrègez les quatre bases de données pluggables à l'aide de la clause CONTAINERS().

Les avantages de cette conception d'entrepôt logique sont les suivants :

Racine d'application

Un conteneur d'application a exactement un racine d'application, qui est le parent des bases de données pluggables d'application dans le conteneur.

La propriété d'être une racine d'application est établie au moment de la création et ne peut pas être modifiée. Le seul conteneur auquel appartient une racine d'application est la racine de base de données Conteneur. Une racine d'application ressemble à la racine de base de données Conteneur d'une certaine manière et à une base de données pluggable d'une autre manière :

Une racine d'application diffère de la racine de base de données Conteneur et de la base de données pluggable standard, car elle peut stocker des objets communs créés par l'utilisateur, appelés objets communs d'application. Les objets communs d'application sont accessibles aux bases de données pluggables d'application connectées à la racine d'application. Les objets communs d'application ne sont pas visibles par la racine de base de données Conteneur, les autres racines d'application ou les bases de données pluggables qui n'appartiennent pas à la racine d'application.

Exemple 3-1 Création d'une racine d'application

Dans cet exemple, vous connectez-vous à la racine de base de données Conteneur en tant qu'utilisateur commun d'administration c##system. Vous créez un conteneur d'application nommé saas_sales_ac, puis ouvrez la racine de l'application, qui porte le même nom que le conteneur.

-- 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;

Vous définissez le conteneur en cours sur saas_sales_ac, puis vérifiez qu'il s'agit de la racine d'application :

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

Pour le conteneur d'application, vous indiquez les deux paramètres suivants dans l'espace de noms USERENV de la fonction SYS_CONTEXT.

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

La valeur de SYS_CONTEXT('USERENV', 'IS_APPLICATION_ROOT') dans une racine d'application est la suivante :

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

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

La valeur de SYS_CONTEXT('USERENV', 'IS_APPLICATION_ROOT') correspond à la colonne APPLICATION_ROOT dans la vue V$PDBS.

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

APP
---
YES

Bases de données pluggable d'application

Une base de données pluggable d'application est une base de données pluggable qui réside dans un conteneur d'application. Chaque base de données pluggable d'une base de données Conteneur réside dans zéro ou un conteneur d'application.

Par exemple, le conteneur d'application saas_sales_ac peut prendre en charge plusieurs clients, chaque application client stockant ses données dans une base de données pluggable distincte. Les bases de données pluggables d'application cust1_sales_pdb et cust2_sales_pdb peuvent résider dans saas_sales_ac, auquel cas elles n'appartiennent à aucun autre conteneur d'application (bien qu'elles appartiennent nécessairement à la racine de la base de données Conteneur en tant que bases de données pluggables).

Créez une base de données pluggable d'application en exécutant CREATE PLUGGABLE DATABASE lorsque vous êtes connecté à la racine de l'application. Vous pouvez créer la base de données pluggable d'application à partir d'une base de données de départ, ou cloner une base de données pluggable ou connecter une base de données pluggable déconnectée. A l'instar d'une base de données pluggable connectée à la racine de base de données Conteneur, vous pouvez cloner, déconnecter ou supprimer une base de données pluggable d'application. Toutefois, une base de données pluggable d'application doit toujours appartenir à une racine d'application.

Valeur de départ de l'application

Une prédéfinition d'application est une base de données pluggable facultative créée par l'utilisateur dans un conteneur d'application. Un conteneur d'application a une valeur de départ d'application ou zéro.

Une prédéfinition d'application vous permet de créer rapidement des bases pluggables d'application. Il joue le même rôle dans le conteneur d'application que PDB$SEED dans la base de données Conteneur elle-même.

Le nom de départ de l'application est toujours application_container_name$SEED, où application_container_name est le nom du conteneur d'application. Par exemple, utilisez l'instruction CREATE PDB ... AS SEED pour créer saas_sales_ac$SEED dans le conteneur d'application saas_sales_ac.

Objets communs d'application

Un objet commun d'application est un objet commun créé au sein d'une application dans une racine d'application. Les objets communs sont liés aux données ou aux métadonnées.

Pour un objet commun lié aux données, les bases de données pluggables d'application partagent un seul ensemble de données. Par exemple, une application pour le conteneur d'application saas_sales_ac est nommée saas_sales_app, a la version 1.0 et inclut une table usa_zipcodes liée aux données. Dans ce cas, les lignes sont stockées une seule fois dans la table de la racine de l'application, mais sont visibles dans toutes les bases de données pluggables de l'application.

Pour un objet commun lié aux métadonnées, les bases de données pluggables d'application partagent uniquement les métadonnées, mais contiennent des ensembles de données différents. Par exemple, une table products liée aux métadonnées a la même définition dans chaque base de données pluggable d'application, mais les lignes elles-mêmes sont propres à la base de données pluggable. La base de données pluggable d'application nommée cust1pdb peut avoir une table products qui contient des liasses, tandis que la base de données pluggable d'application nommée cust2pdb peut avoir une table products qui contient des parties automatiques.

A propos de la communalité dans une base Conteneur

Un phénomène commun défini dans une base de données Conteneur ou une racine d'application est le même dans tous les conteneurs connectés à cette racine.

Principes de communalité

Dans une base de données Conteneur, un phénomène peut être courant dans le conteneur système (la base de données Conteneur elle-même) ou dans un conteneur d'application spécifique.

Par exemple, si vous créez un compte utilisateur commun alors que vous êtes connecté à CDB$ROOT, ce compte utilisateur est commun à toutes les bases de données pluggables et racines d'application de la base de données Conteneur. Toutefois, si vous créez un compte utilisateur commun d'application lorsque vous êtes connecté à une racine d'application, ce compte utilisateur n'est commun qu'aux bases de données pluggables de ce conteneur d'application.

Dans le contexte de CDB$ROOT ou d'une racine d'application, les principes de communalité sont les suivants :

Espaces de noms dans une base Conteneur

Dans une base de données Conteneur, l'espace de noms de chaque objet est inclus dans son conteneur.

Les principes suivants résument les règles de définition de portée :

Les principes précédents ont des implications pour les phénomènes locaux et communs.

Phénomènes locaux

Un phénomène local doit être nommé de manière unique dans un conteneur, mais pas dans tous les conteneurs de la base de données Conteneur. Les phénomènes locaux nommés de manière identique dans différents conteneurs sont distincts. Par exemple, l'utilisateur local sh dans une base de données pluggable n'est pas en conflit avec l'utilisateur local sh dans une autre base de données pluggable.

CDB$ROOT Phénomènes courants

Les phénomènes courants définis dans CDB$ROOT existent dans plusieurs conteneurs et doivent être uniques dans chacun de ces espaces de noms. Par exemple, la racine de base de données Conteneur inclut des utilisateurs communs prédéfinis tels que SYSTEM et SYS. Pour garantir la séparation des espaces de noms, Oracle AI Database empêche la création d'un utilisateur SYSTEM dans un autre conteneur.

Pour garantir la séparation des espaces de noms, le nom des phénomènes communs créés par l'utilisateur dans la racine de base de données Conteneur doit commencer par la valeur indiquée par le paramètre d'initialisation COMMON_USER_PREFIX. Le préfixe par défaut est c## ou C##. Les noms de tous les autres phénomènes créés par l'utilisateur ne doivent pas commencer par c## ou C##. Par exemple, vous ne pouvez pas créer un utilisateur local dans hrpdb nommé c##hr, ni créer un utilisateur commun dans la racine de base de données Conteneur nommé hr.

Application Phénomènes communs

Dans un conteneur d'application, les noms des phénomènes locaux et communs d'application ne doivent pas entrer en conflit.

Voir aussi : Guide de sécurité Oracle AI Database pour en savoir plus sur les utilisateurs et rôles communs

Création d'objets communs d'application

Pour créer des objets communs, connectez-vous à la racine d'une application, puis exécutez une instruction CREATE qui spécifie un attribut de partage.

Vous pouvez uniquement créer ou modifier des objets communs d'application dans le cadre d'une installation, d'une mise à niveau ou d'un patch d'application. Vous pouvez spécifier le partage de l'une des manières suivantes :

Le tableau suivant présente les types d'objet commun d'application et l'emplacement de stockage des données et des métadonnées.

Tableau 1 - Objets communs des applications

Type d'objet Valeur de partage Stockage des métadonnées Stockage des données
Lié aux données DATA Racine d'application Racine d'application
Données étendues liées EXTENDED DATA Racine d'application Racine d'application et base de données pluggable d'application
Lié aux métadonnées METADATA Racine d'application Base de données pluggable d'application

Voir aussi : Guide de sécurité Oracle AI Database pour apprendre à gérer les privilèges pour les objets communs

Objets communs d'application liés aux métadonnées

Un lien de métadonnées est un objet de dictionnaire qui prend en charge la référence aux métadonnées communes partagées par toutes les bases de données pluggables du conteneur d'application, ainsi que l'octroi de privilèges sur ces métadonnées.

La spécification de la valeur METADATA dans la clause SHARING ou le paramètre d'initialisation DEFAULT_SHARING indique un lien vers les métadonnées d'un objet, appelé objet commun lié aux métadonnées. Les métadonnées de l'objet sont stockées une seule fois dans la racine de l'application.

Les tables, les vues et les objets de code (tels que les procédures PL/SQL) peuvent partager des métadonnées. Dans ce contexte, les "métadonnées" incluent les définitions de colonne, les contraintes, les déclencheurs et le code. Par exemple, si sales_mlt est une table commune liée aux métadonnées, toutes les bases pluggables d'application accèdent à la même définition de cette table, qui est stockée dans la racine de l'application, au moyen d'un lien de métadonnées. Les lignes dans sales_mlt sont différentes dans chaque base de données pluggable d'application, mais les définitions de colonne sont identiques.

En général, la plupart des objets d'une application sont liés aux métadonnées. Par conséquent, vous ne devez gérer qu'une seule définition d'application maître. Cette approche centralise la gestion de l'application dans plusieurs bases de données pluggables d'application.

Exemple 3-2 Création d'un objet commun lié aux métadonnées

Dans cet exemple, l'utilisateur SYSTEM se connecte au conteneur d'application saas_sales_ac. SYSTEM installe une application nommée saas_sales_app à la version 1.0. Cette application crée un compte utilisateur commun nommé saas_sales_adm. Le schéma contient une table commune liée aux métadonnées nommée 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';

Vous pouvez utiliser l'instruction ALTER PLUGGABLE DATABASE APPLICATION ... SYNC pour synchroniser les bases de données pluggables d'application afin d'utiliser la même définition d'application maître. Ainsi, chaque base de données pluggable d'application dispose d'un lien de métadonnées vers la table commune saas_sales_adm.sales_mlt. Le code de niveau intermédiaire qui met à jour sales_mlt dans la base de données pluggable nommée cust1_pdb ajoute des lignes à cette table dans cust1_pdb, tandis que le code de niveau intermédiaire qui met à jour sales_mlt dans cust2_pdb ajoute des lignes à la copie de cette table dans cust2_pdb. Seules les métadonnées de table, qui sont stockées dans la racine de l'application, sont partagées. Remarque : Guide de sécurité Oracle AI Database pour en savoir plus sur le fonctionnement des privilèges objet communément accordés

Liens de métadonnées

Pour les objets communs d'application liés aux métadonnées, les métadonnées de l'objet sont stockées une seule fois dans la racine de l'application. Un lien de métadonnées est un objet de dictionnaire dont le type d'objet est identique aux métadonnées qu'il partage.

La description d'un lien de métadonnées est stockée dans le dictionnaire de données de la base de données pluggable dans laquelle il est créé. Un lien de métadonnées doit appartenir à un utilisateur commun d'application. Vous pouvez uniquement utiliser des liens de métadonnées pour partager les métadonnées des objets communs appartenant à leur créateur dans la racine de base de données Conteneur ou une racine d'application.

Contrairement à une liaison de données, une liaison de métadonnées dépend uniquement des données communes. Par exemple, si une application contient les tables locales dow_close_lt et nasdaq_close_lt dans la racine de l'application, un utilisateur commun ne peut pas créer de liens de métadonnées vers ces objets. Toutefois, une table commune d'application nommée sales_mlt peut être liée aux métadonnées.

Si un utilisateur commun privilégié modifie les métadonnées pour sales_mlt, par exemple, ajoute une colonne à la table, cette modification est propagée aux liens de métadonnées. Les utilisateurs de la base de données pluggable d'application ne peuvent pas modifier les métadonnées dans le lien de métadonnées. Par exemple, un administrateur de base de données qui gère la base de données pluggable d'application nommée cust1_pdb ne peut pas ajouter de colonne à sales_mlt dans cette base de données pluggable uniquement : ces modifications de métadonnées ne peuvent être effectuées que dans la racine d'application.

Objets communs d'application liés aux données

Un objet lié aux données est un objet dont les métadonnées et les données résident dans une racine d'application et sont accessibles à partir de toutes les bases de données pluggables d'application dans ce conteneur d'application.

La spécification de la valeur DATA dans la clause SHARING ou le paramètre d'initialisation DEFAULT_SHARING indique un lien vers un objet commun, appelé objet commun lié aux données. Les tables de dimensions d'un data warehouse sont souvent de bons candidats pour les tables communes liées aux données.

Un lien de données est un objet de dictionnaire qui fonctionne comme un synonyme. Par exemple, si countries est une table commune d'application, toutes les bases de données pluggables d'application accèdent à la même copie de cette table au moyen d'un lien de données. Si une ligne est ajoutée à cette table, elle est visible dans toutes les bases pluggables de l'application.

Un lien de données doit appartenir à un utilisateur commun d'application. Le lien hérite du type d'objet de l'objet vers lequel il pointe. La description d'une liaison de données est stockée dans le dictionnaire de la base de données pluggable dans laquelle elle est créée. Par exemple, si un conteneur d'application contient 10 bases de données pluggables d'application et que chaque base de données pluggable contient un lien vers la table commune d'application countries, les 10 bases de données pluggables contiennent toutes des définitions de dictionnaire pour ce lien.

Exemple 3-3 Création d'un objet lié aux données

Dans cet exemple, SYSTEM se connecte au conteneur d'application saas_sales_ac. SYSTEM met à niveau l'application nommée saas_sales_app de la version 1.0 vers 2.0. Cette mise à niveau d'application se connecte au conteneur en tant qu'utilisateur commun saas_sales_adm, crée une table liée aux données nommée countries_dlt, puis y insère des lignes.

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

Utilisez l'instruction ALTER PLUGGABLE DATABASE APPLICATION ... SYNC pour synchroniser les bases de données pluggables d'application avec la racine d'application. Ainsi, chaque base de données pluggable d'application synchronisée dispose d'un lien de données vers la table de liaison de données saas_sales_adm.countries_dlt.

Objets d'application liés aux données étendus

Un objet étendu lié aux données est un hybride d'un objet lié aux données et d'un objet lié aux métadonnées.

Dans un objet étendu lié aux données, les données stockées dans la racine d'application sont communes à toutes les bases de données pluggables d'application et toutes les bases de données pluggables peuvent accéder à ces données. Toutefois, chaque base de données pluggable d'application peut créer ses propres données propres propres tout en partageant les données communes dans la racine d'application. Par conséquent, les bases pluggables complètent les données communes avec leurs propres données.

Par exemple, une application de vente peut prendre en charge plusieurs bases de données pluggables d'application. Toutes les bases de données pluggables d'application ont besoin des codes postaux pour les Etats-Unis. Dans ce cas, vous pouvez créer une table de liaison de données étendue zipcodes_edt dans la racine d'application. La racine de l'application stocke les codes postaux américains afin que toutes les bases de données pluggables de l'application puissent y accéder. Toutefois, une base de données pluggable d'application exige les codes postaux pour les États-Unis et le Canada. Cette base de données pluggable d'application peut stocker les codes postaux pour le Canada dans l'objet lié aux données étendu de la base de données pluggable d'application au lieu de la racine de l'application.

Créez un objet étendu lié aux données en vous connectant à la racine de l'application et en indiquant le mot-clé SHARING=EXTENDED DATA dans l'instruction CREATE.

Exemple 3-4 Création d'un objet de données étendu

Dans cet exemple, SYSTEM se connecte au conteneur d'application saas_sales_ac, puis met à niveau l'application nommée saas_sales_app (créée dans l'Example 3-2) de la version 2.0 vers 3.0. Cette application se connecte au conteneur en tant qu'utilisateur commun saas_sales_adm, crée une table de liaison de données étendue nommée zipcodes_edt, puis y insère des lignes.

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

Utilisez l'instruction ALTER PLUGGABLE DATABASE APPLICATION ... SYNC pour synchroniser les bases de données pluggables d'application avec l'application. Ainsi, chaque base de données pluggable d'application synchronisée dispose d'un lien de données vers la table de liaison de données saas_sales_adm.zipcodes_edt. Les applications qui se connectent à ces bases de données pluggables peuvent voir les codes postaux qui ont été insérés dans zipcodes_edt lors de la mise à niveau de l'application, mais peuvent également insérer leurs propres codes postaux dans ce tableau.

Cartes de conteneurs

Une mappe de conteneur permet à une session connectée à la racine d'application d'émettre des instructions SQL qui sont acheminées vers la base de données pluggable appropriée, selon la valeur d'un prédicat utilisé dans l'instruction SQL.

Une table de mapping indique une colonne dans une table commune liée aux métadonnées et utilise des partitions pour associer différentes bases pluggables d'application à différentes valeurs de colonne. Ainsi, les mappings de conteneur permettent le partitionnement des données au niveau de la base de données pluggable lorsque les données ne sont pas partitionnées physiquement au niveau de la table.

Les composants clés de l'utilisation des mappings de conteneur sont les suivants :

Exemple 3-5 Créer une table liée aux métadonnées, une table de mapping et une carte de conteneur - Partie 1

Dans cet exemple, vous connectez-vous en tant qu'administrateur d'application à la racine de l'application. Supposons qu'un conteneur d'application comporte trois bases de données pluggables d'application : amer_pdb, euro_pdb et asia_pdb. Chaque base de données pluggable d'application stocke les noms de pays d'une région différente. Une table liée aux métadonnées nommée oe.countries_mlt comporte une colonne cname qui stocke le nom du pays. Pour cette stratégie de partitionnement, vous utilisez partition par liste pour créer un objet de correspondance nommé salesadm.pdb_map_tbl qui crée une partition pour chaque région. Le nom du pays détermine la région.

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

Remarque : bien que vous créiez des mappings de conteneur à l'aide de la syntaxe de partitionnement, la base de données n'utilise pas la fonctionnalité de partitionnement. La définition d'une correspondance de conteneurs ne nécessite pas Oracle Partitioning.

Dans le script précédent, l'instruction ALTER TABLE oe.countries_mlt ENABLE CONTAINERS_DEFAULT indique que les requêtes et les instructions LMD émises dans la racine de l'application doivent utiliser la clause CONTAINERS() par défaut pour l'objet de base de données.

Exemple 3-6 Synchronisation de l'application et ajout de données : Partie 2

Cet exemple reprend l'exemple précédent. Lorsque vous êtes connecté à la racine de l'application, vous basculez le conteneur en cours vers chaque base de données pluggable, synchronisez l'application saas_sales_app, puis ajoutez des données propres à la base de données pluggable à la table oe.countries_mlt.

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;

Exemple 3-7 Interroger la table liée aux métadonnées - Partie 3

Cet exemple reprend l'exemple précédent. Vous vous connectez à la racine d'application, puis interrogez oe.countries_mlt plusieurs fois, en indiquant différents pays dans la clause WHERE. La requête renvoie la valeur correcte de la colonne oe.countries_mlt.region.

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

Opérations inter-conteneurs

Une opération interconteneurs est une instruction LDD ou LMD qui affecte plusieurs conteneurs à la fois.

Seul un utilisateur commun connecté à la racine de base de données Conteneur ou à la racine d'application peut effectuer des opérations inter-conteneurs. Une opération de conteneur croisé peut affecter :

Parmi les exemples d'opérations LDD inter-conteneurs figurent l'octroi d'un privilège par l'utilisateur SYSTEM à un autre utilisateur commun et une instruction ALTER DATABASE . . . RECOVER qui s'applique à l'ensemble de la base de données Conteneur.

Lorsque vous êtes connecté à la racine de base de données Conteneur ou à une racine d'application, vous pouvez exécuter une instruction LMD unique pour modifier des tables ou des vues dans plusieurs bases de données pluggables du conteneur. La base de données infère les bases de données pluggables cible de la valeur de la colonne CON_ID indiquée dans l'instruction LMD. Si aucune valeur CON_ID n'est indiquée, la base de données utilise la propriété CONTAINERS_DEFAULT_TARGET indiquée par l'instruction ALTER PLUGGABLE DATABASE CONTAINERS DEFAULT TARGET.

Exemple 3-8 Mise à jour de plusieurs bases de données pluggables dans une instruction LMD unique

Dans cet exemple, votre objectif est de définir la colonne country_name sur la valeur USA dans la table sh.sales. Cette table existe dans deux bases de données pluggables distinctes, avec les ID de conteneur 7 et 8. Les deux bases pluggables se trouvent dans le conteneur d'application nommé saas_sales_ac. Vous pouvez vous connecter à la racine de l'application en tant qu'administrateur et effectuer la mise à jour comme suit :

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

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

Dans l'instruction UPDATE précédente, sal est un alias pour CONTAINERS(sh.sales).

Voir aussi : "Comptes utilisateur communs"