Utiliser des tables en nuage pour stocker les informations de journalisation et de diagnostic

Vous pouvez créer des tables en nuage où les données de table résident dans le stockage en nuage géré par Oracle et où les données de table ne consomment pas le stockage de base de données.

À propos des tables en nuage

Vous pouvez créer des tables en nuage comme alternative complémentaire aux tables de la base de données.

Toutes les données de la table Cloud sont stockées dans le service de stockage d'objets géré par Oracle. Le stockage d'objets géré par Oracle est un stockage externe, en dehors de la base de données, que la base de données Autonomous AI Database crée et gère.

Vous pouvez utiliser Cloud Tables pour stocker des données de journalisation d'application, des informations de diagnostic ou d'autres données rarement utilisées. Dans certaines applications existantes qui ne s'exécutent pas sur Autonomous AI Database, vous pouvez stocker ce type d'informations dans des fichiers d'un système de fichiers local (par exemple, à l'aide des API UTL_FILE). De tels mécanismes de journalisation et les fichiers associés peuvent être très utiles lorsque vous devez diagnostiquer et résoudre les erreurs d'application. Toutefois, le stockage des informations dans les tables de base de données peut utiliser de grandes quantités de stockage de base de données pour les données rarement utilisées. À l'aide des tables en nuage, les données persistantes sont enregistrées dans le service de stockage d'objets géré par Oracle, sans consommer le stockage de base de données.

Note

Le paramètre CLOUD_TABLE_COMMIT_THRESHOLD s'applique à toutes les tables en nuage et peut être défini par n'importe quel utilisateur doté du privilège ALTER SESSION. Par conséquent, les tables Cloud ne conviennent pas aux données critiques pour la sécurité lorsque les modifications validées doivent être durables et immédiatement visibles par les lecteurs simultanés. Pour cette raison, Cloud Tables peut ne pas être approprié pour des cas d'utilisation tels que les tables de journal de vérification.

Restrictions SELECT et DML pour les tables en nuage

Les tables en nuage fonctionnent comme les tables de base de données ordinaires avec certaines restrictions. Vous pouvez utiliser les instructions SELECT et DML (Langage de manipulation de données), avec les exceptions suivantes :

  • Les énoncés MERGE ne sont pas pris en charge.
  • Les colonnes LOB sont limitées à 10 Mo de données.
  • Le contrôle des accès simultanés LMD est différent. Par conséquent :
    • LOCK TABLE ne peut pas empêcher les opérations LMD concurrentes comme pour une table de base de données.
    • INSERT n'acquiert pas de verrou sur la table et INSERT n'est donc jamais bloqué par des opérations LMD concurrentes.
    • Les opérations UPDATE et DELETE font l'acquisition d'un verrou exclusif sur une table en nuage. Par conséquent, les transactions UPDATE ou DELETE bloquent les opérations UPDATE ou DELETE concurrentes sur une table en nuage.
  • Seules les contraintes NOT NULL sont appliquées.
  • La LMD est autorisée dans une base de données autonome d'intelligence artificielle en lecture et en écriture comme pour toute autre table. Les tables en nuage autorisent également les opérations LMD dans un clone actualisable.

Les tables en nuage ne prennent pas en charge les éléments suivants :

  • Index
  • Colonnes visibles
  • Colonnes virtuelles
  • Déclencheurs LMD
  • Plus de 996 colonnes
  • Colonnes de données de type bolean

Opérations de gestion du cycle de vie et tables en nuage

Les données de table en nuage sont stockées dans le service de stockage d'objets géré par Oracle. Cela signifie que certaines opérations sur la base de données d'IA autonome traitent les tables en nuage différemment des tables dans la base de données, comme suit :

  • Les données de la table Cloud sont exclues de la sauvegarde et de la récupération d'une instance de base de données Autonomous AI Database (les données ne sont pas sauvegardées et vous ne pouvez pas restaurer les données de la table Cloud).

  • Les données de table en nuage sont protégées par le service de stockage d'objets géré par Oracle.

  • Les opérations de gestion du cycle de vie qui ont une incidence sur l'état d'une instance de base de données d'intelligence artificielle autonome n'ont pas d'incidence sur les données stockées dans les tables en nuage.

Le nom des tables en nuage dans le stockage d'objets est défini de manière unique pour chaque instance de base de données d'IA autonome, en fonction de son OCID. Cela signifie que toute opération qui modifie ou introduit un nouvel OCID pour une base de données existante a une incidence sur les tables en nuage. L'illustration suivante présente l'incidence des opérations de cycle de vie sur les données de table en nuage.

Opération de cycle de vie Disponibilité des données de la table en nuage
Clonage de la base de données de la même région La table en nuage est clonée sans données de table en nuage
Clone de base de données inter-régions La table en nuage est clonée sans données de table en nuage
Base de secours Autonomous Data Guard de même région (locale) Les données de la table Cloud et de la table Cloud sont accessibles
Base de données de secours Autonomous Data Guard inter-région La table Cloud est disponible sur la base de secours, sans les données de la table Cloud
Même région (locale) pair de récupération après sinistre basée sur des sauvegardes Les données de la table Cloud et de la table Cloud sont accessibles
Pair de récupération après sinistre basée sur des sauvegardes inter-régions Cloud Table est disponible sur la base de secours, sans données Cloud Table
Opérations de gestion du cycle de vie ayant une incidence sur le numéro SCN/horodatage d'une instance de base de données autonome d'IA, notamment :
  • Sauvegarde à long terme
  • Restaurer la base de données (point dans le temps de restauration)
  • Copier à partir d'une sauvegarde

La table en nuage continuera d'être mise à jour et l'ancien état des données de la table en nuage ne sera pas conservé ou restauré. Cela signifie que seules les données courantes de la table Cloud sont disponibles.

Les opérations de gestion du cycle de vie, notamment :
  • Gérer l'affectation de ressources
  • déplacer
  • Réduire
  • Renommer
  • Mode : Lecture seule/lecture-écriture
  • Modifier le type de charge de travail : de l'entrepôt avec lac de données au traitement des transactions, par exemple
Aucune incidence sur les tables en nuage ou les données de table en nuage

Mise en mémoire tampon avec des tables en nuage

Par défaut, les modifications LMD apportées aux tables Cloud sont exportées vers le stockage d'objets lorsque l'opération LMD est validée. Toutefois, cela peut ne pas fonctionner correctement lorsque les instructions LMD sont structurées en petites transactions fréquemment validées. Pour améliorer les performances dans ce scénario, définissez le paramètre CLOUD_TABLE_COMMIT_THRESHOLD pour activer la mise en mémoire tampon des modifications LMD de la table Cloud dans une session.

Lorsque le paramètre CLOUD_TABLE_COMMIT_THRESHOLD est réglé à une valeur différente de zéro, le système traite la valeur comme un seuil de nombre de modifications et les modifications de la table Cloud sont mises en mémoire tampon jusqu'à ce que le nombre de modifications atteigne le seuil spécifié. Lorsque le seuil est atteint, les modifications en mémoire tampon sont exportées vers le stockage d'objets. Les modifications en mémoire tampon sont également exportées lorsque la session se termine normalement, même si CLOUD_TABLE_COMMIT_THRESHOLD n'a pas été atteint. Avant l'exportation des modifications en mémoire tampon, les sessions concurrentes ne voient pas les modifications. Dans de rares cas impliquant une expiration inattendue du processus, les modifications en mémoire tampon ne peuvent jamais être exportées et les modifications ne sont pas durables (c'est-à-dire que les modifications en mémoire tampon ne sont pas exportées vers le magasin d'objets).

Pour plus d'informations, voir CLOUD_TABLE_COMMIT_THRESHOLD.

Créer des tables en nuage

Affiche les étapes de création d'une table en nuage sur une base de données d'IA autonome.

Pour créer une table en nuage :

  1. Exécutez la procédure CREATE_CLOUD_TABLE.

    Exemple :

    BEGIN
      DBMS_CLOUD.CREATE_CLOUD_TABLE(
       table_name  => 'CLOUD_TABLE_TEST',
       column_list => 'I INTEGER, STR1 VARCHAR2(32)' );
    END;
    /

    Pour plus d'informations, voir ProcédureCREATE_CLOUD_TABLE.

  2. Insérez des données dans la table Cloud.
    INSERT INTO cloud_table_test VALUES (1, 'xyz');

    Vous pouvez utiliser le paramètre d'initialisation CLOUD_TABLE_COMMIT_THRESHOLD pour activer la mise en mémoire tampon pour les tables en nuage. Pour plus d'informations, voir CLOUD_TABLE_COMMIT_THRESHOLD.

  3. Sélectionnez des données dans une table Cloud.
    SELECT * FROM cloud_table_test;
    I          STR1
    ---------- --------------------------------
    1          xyz                            

Utilisez DROP TABLE lorsque vous voulez supprimer une table en nuage.

Exemple :

DROP TABLE CLOUD_TABLE_TEST;

Les tables Cloud ne prennent pas en charge la corbeille.

Voir Notes sur la table en nuage pour plus d'informations.

Notes de table en nuage

Fournit des notes sur l'utilisation des tables en nuage.

Voici les notes relatives à l'utilisation des tables en nuage :

  • Vous pouvez accorder des privilèges SELECT, INSERT et UPDATE pour une table en nuage. Aucun autre privilège ne peut être accordé à une table en nuage.

    Pour plus d'informations, voir Configuration du privilège et de l'autorisation de rôle.

  • Les contraintes de la table en nuage sont limitées aux contraintes en mode RELY DISABLE NOVALIDATE, ce qui signifie que la contrainte n'est pas appliquée. La seule exception à cette règle concerne les contraintes NOT NULL.

    Les tables en nuage prennent en charge tous les modes de contrainte NOT NULL, y compris le mode par défaut (ENABLE VALIDATE). Les contraintes PRIMARY KEY, UNIQUE, FOREIGN KEY et NOT NULL sont prises en charge; les contraintes CHECK ne sont pas prises en charge.

    Vous pouvez déclarer des contraintes en ligne dans le cadre de COLUMN_LIST.

    Exemple :

    BEGIN
      DBMS_CLOUD.CREATE_CLOUD_TABLE(
            table_name  => 'CLOUD_TAB_WITH_CONSTRAINTS',
            column_list => 'PK INTEGER,
                DATE_ID INT REFERENCES DATE_DIM(DATE_ID) RELY DISABLE NOVALIDATE,
                VAL NUMBER NOT NULL,
                CONSTRAINT CLOUD_TAB_PK PRIMARY KEY(PK) RELY DISABLE NOVALIDATE');
    END;
    /

    Voir Notes sur la table en nuage pour connaître les limites supplémentaires de la table en nuage.

  • L'ensemble DBMS_CLOUD est un ensemble de droits de l'appelant. La procédure DBMS_CLOUD.CREATE_CLOUD_TABLE vous permet uniquement de créer une table dans le schéma de l'appelant.

    Pour plus d'informations, voir Clause relative aux droits et aux droits du demandeur.

  • Le paramètre column_list dans un appel de procédure DBMS_CLOUD.CREATE_CLOUD_TABLE peut inclure la clause DEFAULT, qui fonctionne comme la clause DEFAULT dans CREATE TABLE. Pour plus d'informations, voir CREATE TABLE.

    Exemple :

    BEGIN
      DBMS_CLOUD.CREATE_CLOUD_TABLE(
       table_name  => 'CLOUD_TABLE_TEST_DEFAULT',
       column_list => 'I INTEGER, STR2 VARCHAR2(32) DEFAULT ''ABC''');
    END;
    /

    Vous pouvez ensuite insérer des valeurs par défaut. Exemple :

    INSERT INTO cloud_table_test_default (i) VALUES (1); 
    1 row created. 
    INSERT INTO cloud_table_test_default VALUES (2, default);
    1 row created.
    INSERT INTO cloud_table_test_default VALUES (3, null);
    1 row created.
    INSERT INTO cloud_table_test_default VALUES (4, 'xyz');
    1 row created.
    COMMIT;
    Commit complete.
    SELECT * FROM cloud_table_test_default ORDER BY i;
    
    I STR2 
    - ---- 
    1 ABC  
    2 ABC  
    3 null 
    4 xyz
  • Vous pouvez utiliser le paramètre d'initialisation CLOUD_TABLE_COMMIT_THRESHOLD pour activer la mise en mémoire tampon pour les tables en nuage. Pour plus d'informations, voir CLOUD_TABLE_COMMIT_THRESHOLD.