Dictionnaire de données et vues dynamiques des performances

L'ensemble central de tables et de vues de référence en lecture seule de chaque base de données Oracle est appelé collectivement dictionnaire de données. Les vues de performances dynamiques sont des vues spéciales qui sont continuellement mises à jour lorsqu'une base de données est ouverte et en cours d'utilisation.

Présentation du dictionnaire de données

Une partie importante d'une base de données Oracle est son dictionnaire de données, qui est un ensemble de tables en lecture seule qui fournit des métadonnées administratives sur la base de données.

Finalité du dictionnaire de données

Le dictionnaire de données contient des métadonnées décrivant le contenu de la base.

Par exemple, le dictionnaire de données contient les informations suivantes :

Gestion des données

Le dictionnaire de données est un élément central de la gestion des données pour chaque base de données Oracle.

Par exemple, la base de données effectue les actions suivantes :

Oracle AI Database stockant les données du dictionnaire de données dans des tables, tout comme les autres données, les utilisateurs peuvent interroger les données avec SQL. Par exemple, les utilisateurs peuvent exécuter des instructions SELECT pour déterminer leurs privilèges, quelles tables existent dans leur schéma, quelles colonnes figurent dans ces tables, si des index sont créés sur ces colonnes, etc.

Voir aussi :

Séparation du dictionnaire de données dans une base Conteneur

Dans une base Conteneur, les métadonnées du dictionnaire de données sont réparties entre la racine de la base Conteneur et les bases pluggables. Du point de vue de l'utilisateur et de l'application, le dictionnaire de données de chaque conteneur d'une base de données Conteneur est distinct.

Dans une base de données Conteneur nouvellement créée qui ne contient pas encore de données utilisateur, le dictionnaire de données de la racine de la base de données Conteneur contient uniquement des métadonnées système. Par exemple, la table TAB$ contient des lignes qui décrivent uniquement les tables fournies par Oracle, par exemple, TRIGGER$ et SERVICE$. Le graphique suivant représente trois tables sous-jacentes du dictionnaire de données, les barres rouges indiquant les lignes décrivant le système.

Figure 1 : Métadonnées du dictionnaire de données dans la racine de base de données Conteneur

Description de l'illustration cncpt_vm_363.png

Supposons que vous créez une base de données pluggable, puis que vous créez un schéma hr contenant les tables employees et departments dans cette base de données pluggable. Le dictionnaire de données de la base pluggable contient certaines lignes qui décrivent les entités fournies par Oracle et d'autres qui décrivent les entités créées par l'utilisateur. Par exemple, la table TAB$ du dictionnaire de base de données pluggable contient une ligne de métadonnées pour la table employees et une ligne pour la table departments.

Figure 2 : Architecture du dictionnaire de données dans une base Conteneur

Description de l'illustration cncpt_vm_361.png

Le graphique précédent montre que le dictionnaire de données de la base de données pluggable contient des points de repère vers le dictionnaire de données dans la racine de la base de données Conteneur. En interne, les objets fournis par Oracle, tels que les définitions de table de dictionnaire de données et les packages PL/SQL, sont représentés une seule fois dans la racine de base de données Conteneur. Cette architecture atteint deux objectifs principaux au sein de la base de données Conteneur :

Composants du dictionnaire de données

Le dictionnaire de données se compose de tables et de vues de base.

Ces objets sont définis comme suit :

En général, les vues du dictionnaire de données sont regroupées en ensembles. Dans de nombreux cas, un ensemble se compose de trois vues contenant des informations similaires et distinguées les unes des autres par leurs préfixes, comme indiqué dans le tableau suivant. En interrogeant les vues appropriées, vous ne pouvez accéder qu'aux informations qui vous concernent.

Tableau 1 - Jeux de vues du dictionnaire de données

préfixe Accès utilisateur Sommaire Remarques
DBA_ administrateurs de base de données, Tous les articles Certaines vues DBA_ contiennent des colonnes supplémentaires contenant des informations utiles à l'administrateur.
ALL_ Tous les utilisateurs Objets pour lesquels l'utilisateur dispose de privilèges Inclut les objets appartenant à l'utilisateur. Ces vues obéissent à l'ensemble actuel de rôles activés.
USER_ Tous les utilisateurs Objets appartenant à l'utilisateur Les vues avec le préfixe USER_ excluent généralement la colonne OWNER. Cette colonne est impliquée dans les vues USER_ pour être l'utilisateur qui émet la requête.

Tous les ensembles de vues n'ont pas trois membres. Par exemple, le dictionnaire de données contient une vue DBA_LOCK mais pas de vue ALL_LOCK.

La vue DICTIONARY fournie par le système contient les noms et les descriptions abrégées de toutes les vues du dictionnaire de données. La requête suivante de cette vue inclut un exemple de sortie partiel :

SQL> SELECT * FROM DICTIONARY
  2  ORDER BY TABLE_NAME;

TABLE_NAME                     COMMENTS
------------------------------ ----------------------------------------
ALL_ALL_TABLES                 Description of all object and relational
                               tables accessible to the user

ALL_APPLY                      Details about each apply process that
                               dequeues from the queue visible to the
                               current user
.
.
.

Voir aussi :

Objets de données de conteneur dans une base Conteneur

Un objet de données de conteneur est une table ou une vue contenant des données appartenant à plusieurs conteneurs ou à l'ensemble de la base de données Conteneur.

Les privilèges sur les données de conteneur prennent en charge une exigence générale selon laquelle plusieurs bases de données pluggables résident dans une seule base de données Conteneur, mais avec des exigences d'administration locale différentes. Par exemple, si les administrateurs de base de données d'application ne veulent pas administrer localement, ils peuvent accorder des privilèges de données de conteneur sur les vues appropriées aux utilisateurs communs. Dans ce cas, l'administrateur de base de données Conteneur peut accéder aux données de ces bases de données pluggables. En revanche, les administrateurs de base de données pluggable qui ne veulent pas que l'administrateur de base de données Conteneur accède à leurs données n'accordent pas de privilèges sur les données de conteneur.

Les vues fournies par Oracle dont le nom commence par V$ et CDB_ sont des exemples d'objets de données de conteneur. Tous les objets de données de conteneur ont une colonne CON_ID. Le tableau suivant indique la signification des valeurs de cette colonne.

Table 2 - Valeurs d'ID conteneur

ID de conteneur Lignes relatives à
0 Base de données Conteneur entière
1 CDB$ROOT
2 PDB$SEED
Tous les autres ID Bases pluggables, racines d'application ou sources d'application créées par l'utilisateur

Dans une base de données Conteneur, une vue CDB_ correspondante existe pour chaque vue DBA_. Le propriétaire d'une vue CDB_ est le propriétaire de la vue DBA_ correspondante. Le graphique suivant illustre la relation entre les différentes catégories de vues du dictionnaire :

Figure 3 : Vues du dictionnaire dans une base de données Conteneur

Description de l'illustration cncpt_vm_366.png

Lorsque le conteneur en cours est une base de données pluggable, un utilisateur peut visualiser les informations du dictionnaire de données pour la base de données pluggable en cours uniquement. Toutefois, lorsque le conteneur en cours est la racine de base de données Conteneur, un utilisateur commun peut interroger les vues CDB_ pour voir les métadonnées de la racine de base de données Conteneur et des bases de données pluggables pour lesquelles cet utilisateur est privilégié. Remarque : lorsque vous interrogez la racine de base de données Conteneur, les vues CDB_ et V$ convertissent implicitement les données en jeu de caractères AL32UTF8. Si un jeu de caractères a besoin de plus d'octets pour représenter un caractère lors de sa conversion en AL32UTF8, et si la largeur de la colonne de vue ne peut pas prendre en charge les données d'une base de données pluggable spécifique, la troncature des données est possible.

Le tableau suivant décrit les requêtes des vues CDB_. Chaque ligne décrit une action qui se produit après l'action de la ligne précédente.

Tableau 3 Interrogation des vues CDB_

Opération Description 
SQL> CONNECT SYSTEM
 Enter password: ********
 Connected.

L'utilisateur SYSTEM, commun à tous les conteneurs de la base de données Conteneur, se connecte à la racine de la base de données Conteneur (reportez-vous à "Comptes utilisateur communs").

 
SQL> SELECT COUNT(*) FROM CDB_USERS
  WHERE CON_ID=1;

  COUNT(*)
 --------
 38
 SYSTEM interroge CDB_USERS pour obtenir le nombre d'utilisateurs communs dans la racine de base de données Conteneur. La sortie indique que 38 utilisateurs communs existent dans la racine de base de données Conteneur. 
SQL> SELECT COUNT(DISTINCT(CON_ID))
  FROM CDB_USERS;

  COUNT(DISTINCT(CON_ID))
 -----------------------
 4
 SYSTEM interroge CDB_USERS pour déterminer le nombre de conteneurs distincts dans la base de données Conteneur. 
SQL> CONNECT SYSTEM@hrdb
 Enter password: ********
 Connected.
 L'utilisateur SYSTEM se connecte désormais à la base de données pluggable nommée hrpdb. 
SQL> SELECT COUNT(*) FROM CDB_USERS;

  COUNT(*)
 ----------
 48
 SYSTEM interroge CDB_USERS. La sortie indique que 48 utilisateurs communs et locaux existent dans le conteneur en cours, qui est hrpdb. 
SQL> SELECT COUNT(*) FROM DBA_USERS;

  COUNT(*)
 ----------
 48
 SYSTEM interroge DBA_USERS. La sortie est la même que celle de l'interrogation précédente. Comme SYSTEM n'est pas connecté à la racine de base de données Conteneur, la vue DBA_USERS affiche la même sortie que CDB_USERS. Comme DBA_USERS affiche uniquement les utilisateurs dans le conteneur en cours, il en affiche 48.

Vues avec le préfixe DBA_

Les vues avec le préfixe DBA_ affichent toutes les informations pertinentes dans la base de données entière. Les vues DBA_ sont uniquement destinées aux administrateurs.

L'exemple de requête suivant affiche des informations sur tous les objets de la base de données :

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE
FROM   DBA_OBJECTS
ORDER BY OWNER, OBJECT_NAME;

Voir aussi : Guide de l'administrateur Oracle AI Database pour plus d'informations sur les privilèges d'administration

Vues avec le préfixe ALL_

Les vues avec le préfixe ALL_ font référence à la perspective globale de la base de données de l'utilisateur.

Ces vues renvoient des informations sur les objets de schéma auxquels l'utilisateur a accès par le biais d'autorisations publiques ou explicites de privilèges et de rôles, en plus des objets de schéma appartenant à l'utilisateur.

Par exemple, la requête suivante renvoie des informations sur tous les objets auxquels vous avez accès :

SELECT OWNER, OBJECT_NAME, OBJECT_TYPE
FROM   ALL_OBJECTS
ORDER BY OWNER, OBJECT_NAME;

Etant donné que les vues ALL_ obéissent à l'ensemble actuel de rôles activés, les résultats des requêtes dépendent des rôles activés, comme indiqué dans l'exemple suivant :

SQL> SET ROLE ALL;

Role set.

SQL> SELECT COUNT(*) FROM ALL_OBJECTS;

COUNT(*)
----------
68295

SQL> SET ROLE NONE;

Role set.

SQL> SELECT COUNT(*) FROM ALL_OBJECTS;

COUNT(*)
----------
53771

Les développeurs d'application doivent être conscients de l'effet des rôles lors de l'utilisation des vues ALL_ dans une procédure stockée, où les rôles ne sont pas activés par défaut.

Vues avec le préfixe USER_

Les vues les plus susceptibles d'intéresser les utilisateurs de base de données standard sont celles avec le préfixe USER_.

Ces vues :

Par exemple, l'interrogation suivante renvoie tous les objets contenus dans votre schéma :

SELECT OBJECT_NAME, OBJECT_TYPE
FROM   USER_OBJECTS
ORDER BY OBJECT_NAME;

La table DUAL

DUAL est une petite table du dictionnaire de données qu'Oracle AI Database et les programmes écrits par l'utilisateur peuvent référencer pour garantir un résultat connu.

La table double est utile lorsqu'une valeur ne doit être renvoyée qu'une seule fois, par exemple, la date et l'heure actuelles. Tous les utilisateurs de base de données ont accès à DUAL.

La table DUAL comporte une colonne nommée DUMMY et une ligne contenant la valeur X. L'exemple suivant interroge DUAL pour effectuer une opération arithmétique :

SQL> SELECT ((3*4)+5)/3 FROM DUAL;

((3*4)+5)/3
-----------
 5.66666667

Voir aussi : Référence du langage SQL d'Oracle AI Database pour plus d'informations sur la table DUAL

Fonctionnement du dictionnaire de données

Le compte utilisateur Oracle AI Database SYS possède toutes les tables de base et les vues accessibles par l'utilisateur du dictionnaire de données.

Pendant le fonctionnement de la base de données, Oracle AI Database lit le dictionnaire de données pour s'assurer que les objets de schéma existent et que les utilisateurs y ont un accès approprié. Oracle AI Database met à jour le dictionnaire de données en permanence pour refléter les modifications apportées aux structures de base de données, aux audits, aux autorisations et aux données.

Par exemple, si l'utilisateur hr crée une table nommée interns, la base de données ajoute de nouvelles lignes au dictionnaire de données qui reflètent la nouvelle table, les nouvelles colonnes, le nouveau segment, les nouveaux extents et les privilèges dont dispose hr sur la table. Ces nouvelles informations sont visibles la prochaine fois que les vues du dictionnaire sont interrogées.

Les données des tables de base du dictionnaire de données sont nécessaires au fonctionnement d'Oracle AI Database. Seul Oracle AI Database doit écrire ou modifier les informations du dictionnaire de données. Aucun utilisateur Oracle AI Database ne doit jamais modifier les lignes ou objets du schéma figurant dans le schéma SYS, car cette activité peut compromettre l'intégrité des données. L'administrateur responsable de la sécurité doit contrôler strictement ce compte central.

Avertissement : la modification ou la manipulation des données dans les tables du dictionnaire de données peut avoir un impact permanent et préjudiciable sur le fonctionnement de la base de données.

Métadonnées et liens de données

La base de données Conteneur utilise un mécanisme de liaison interne pour séparer les informations du dictionnaire de données.

Plus précisément, Oracle AI Database utilise les pointeurs gérés automatiquement suivants :

Oracle AI Database crée et gère automatiquement les métadonnées et les liens de données vers CDB$ROOT. Les utilisateurs ne peuvent pas ajouter, modifier ou supprimer ces liens.

Voir aussi :

Synonymes publics pour les vues du dictionnaire de données

Oracle AI Database crée des synonymes publics pour de nombreuses vues de dictionnaire de données afin que les utilisateurs puissent y accéder facilement.

L'administrateur de la sécurité peut également créer des synonymes publics supplémentaires pour les objets de schéma utilisés à l'échelle du système. Oracle recommande de ne pas utiliser le même nom pour un objet de schéma privé et un synonyme public.

Voir aussi : "Présentation des synonymes"

Cache du dictionnaire de données

La plupart des informations du dictionnaire de données se trouvent dans le cache du dictionnaire de données car la base de données a constamment besoin de ces informations pour valider l'accès utilisateur et vérifier l'état des objets de schéma.

Les caches contiennent généralement les informations d'analyse. Les colonnes COMMENTS décrivant les tables et leurs colonnes ne sont pas mises en mémoire cache dans le cache du dictionnaire, mais peuvent être mises en mémoire cache dans le cache de tampons de base de données.

Voir aussi : "Cache du dictionnaire de données"

Autres programmes et dictionnaire de données

D'autres produits Oracle AI Database peuvent référencer des vues existantes et créer des tables ou des vues supplémentaires du dictionnaire de données.

Oracle recommande aux développeurs d'applications qui écrivent des programmes faisant référence au dictionnaire de données d'utiliser les synonymes publics plutôt que les tables sous-jacentes. Les synonymes sont moins susceptibles de changer entre les versions.

Stockage du dictionnaire de données

Le dictionnaire de données qui stocke les métadonnées de la base Conteneur dans son ensemble est stocké uniquement dans les tablespaces système.

Le dictionnaire de données qui stocke les métadonnées d'une base de données pluggable spécifique est stocké dans les tablespaces autonomes dédiés à cette base. Les tablespaces de base de données pluggable contiennent à la fois les données et les métadonnées d'un back-end d'application. Par conséquent, chaque ensemble de tables du dictionnaire de données est stocké dans son propre ensemble dédié de tablespaces.

Voir aussi : "Tablespace SYSTEM" pour plus d'informations sur le tablespace SYSTEM

Présentation des vues dynamiques des performances

Tout au long de son fonctionnement, Oracle AI Database gère un ensemble de tables virtuelles qui enregistrent l'activité en cours de la base de données.

Ces vues sont dynamiques car elles sont continuellement mises à jour pendant qu'une base de données est ouverte et en cours d'utilisation. Les vues sont parfois appelées vues V$ car leur nom commence par V$.

Les vues dynamiques des performances contiennent des informations telles que les suivantes :

Les vues dynamiques des performances ont les principales utilisations suivantes :

Contenu des vues dynamiques des performances

Les vues dynamiques des performances sont appelées vues fixes car elles ne peuvent pas être modifiées ou enlevées par un administrateur de base de données. Toutefois, les administrateurs de base de données peuvent interroger et créer des vues sur les tables et accorder l'accès à ces vues à d'autres utilisateurs.

SYS est propriétaire des tables de performances dynamiques dont le nom commence par V_$. Des vues sont créées sur ces tables, puis des synonymes publics avec le préfixe V$. Par exemple, la vue V$DATAFILE contient des informations sur les fichiers de données. La vue V$FIXED_TABLE contient des informations sur toutes les vues et tables de performances dynamiques.

Pour presque toutes les vues V$, une vue GV$ correspondante existe. Dans Oracle Real Application Clusters (Oracle RAC), l'interrogation d'une vue GV$ extrait les informations de la vue V$ de toutes les instances de base de données qualifiées.

Lorsque vous utilisez DBCA (Database Configuration Assistant) pour créer une base de données, Oracle crée automatiquement le dictionnaire de données. Oracle AI Database exécute automatiquement le script catalog.sql, qui contient les définitions des vues et des synonymes publics pour les vues dynamiques des performances. Vous devez exécuter catalog.sql pour créer ces vues et synonymes.

Voir aussi :

Stockage des vues dynamiques des performances

Les vues dynamiques des performances sont basées sur des tables virtuelles créées à partir de structures mémoire de base de données.

Les vues ne sont pas des tables conventionnelles stockées dans la base de données. La cohérence en lecture n'est pas garantie pour les vues car les données sont mises à jour dynamiquement.

Les vues dynamiques des performances n'étant pas des tables vraies, les données dépendent de l'état de la base de données et de l'instance de base de données. Par exemple, vous pouvez interroger V$INSTANCE et V$BGPROCESS lorsque la base de données est démarrée mais pas montée. Toutefois, vous ne pouvez pas interroger V$DATAFILE tant que la base de données n'a pas été montée.

Voir aussi : "Cohérence et simultanéité des données"

Métadonnées d'objet de base de données

Le package DBMS_METADATA et la fonction DBMS_DEVELOPER.GET_METADATA fournissent des interfaces permettant d'extraire des définitions complètes des objets de base de données.

A l'aide du package DBMS_METADATA, les définitions peuvent être exprimées au format XML ou en langage DDL SQL. Oracle AI Database fournit deux styles d'interface : une interface flexible et sophistiquée pour le contrôle par programmation et une interface simplifiée pour les requêtes ad hoc.

A l'aide de la fonction DBMS_DEVELOPER.GET_METADATA, les métadonnées d'objet sont renvoyées en tant que document JSON.

Voir aussi : Référence des types et packages PL/SQL d'Oracle AI Database pour plus d'informations sur DBMS_METADATA. Référence des types et packages PL/SQL Oracle AI Database pour plus d'informations sur DBMS_DEVELOPER.GET_METADATA.