Gestisci cataloghi con DBMS_CATALOG

Il pacchetto DBMS_CATALOG fornisce un set completo di procedure, funzioni e tipi per la gestione dei cataloghi di database per Oracle Autonomous AI Database.

Descrizione di un catalogo

Un catalogo è definito come una raccolta di schemi denominati, ciascuno dei quali contiene una raccolta di oggetti denominati, ad esempio TABLES o VIEWS. Ogni database Oracle dispone di un unico catalogo locale: il dizionario dati. Questo catalogo è sempre presente e non può essere rimosso. Ma ci sono altri esempi di cataloghi, definiti al di fuori del database.
  • Set di oggetti disponibile tramite un database link
  • Un insieme di oggetti condivisi disponibili tramite DBMS_SHARE (ad es. Delta Sharing);
  • Un insieme di tavoli Iceberg gestiti da un catalogo REST di Iceberg;
  • Un insieme di oggetti definiti da un prodotto di terze parti, come Amazon Glue, Databricks Unity Catalog o Snowflakes Polaris;
  • Set di oggetti definito dal servizio Oracle OCI Data Catalog.
  • Un catalogo può essere considerato anche come un "dominio" o "prodotto dati", ovvero un set di oggetti raggruppati per uno scopo aziendale specifico.

Per ulteriori informazioni sullo strumento Catalogo della suite di strumenti Data Studio, fare riferimento a The Catalog Tool.

In un sistema operativo è possibile accedere a file di dati esterni attivando un file system. Per analogia, puoi accedere AI dati esterni in un Autonomous AI Database eseguendo il MOUNT di un catalogo utilizzando il pacchetto DBMS_CATALOG.

L'esempio seguente mostra come installare un catalogo REST Iceberg esterno. Per usarlo, avresti bisogno di tre informazioni.

  • l'endpoint del catalogo REST di Iceberg;
  • Credenziale (ad esempio un token bearer) utilizzata per chiamare questo endpoint;
  • Credenziale (ad esempio un nome utente/password) utilizzata per accedere al bucket in cui sono memorizzati i file di dati Iceberg.
BEGIN
  -- Create a credential capable of accessing an external Iceberg REST catalog
  dbms_cloud.create_credential('ICEBERG_CATALOG_CRED', ...);

  -- Create a credential capable of accessing the bucket where the 
  -- Iceberg data files are stored.
  dbms_cloud.create_credential('ICEBERG_STORAGE_CRED', ...); 

  -- Mount the iceberg catalog
  dbms_catalog.mount_iceberg(
    catalog_name             => 'ICEBERG_CAT',
    endpoint                 => 'https://...',
    catalog_credential       => 'ICEBERG_CATALOG_CRED',
    data_storage_credential  => 'ICEBERG_STORAGE_CRED',
    catalog_type             => 'ICEBERG_UNITY');
END;
/

-- List tables in the iceberg catalog
SELECT owner, table_name 
FROM all_tables@iceberg_cat;

-- Read data from an iceberg table
SELECT *
FROM a_schema.a_table@iceberg_cat;

DBMS_CATALOG viene utilizzato per definire e gestire le operazioni correlate al catalogo.

Fornisce un set completo di procedure, funzioni e tipi per la gestione dei cataloghi all'interno di Oracle Autonomous Database. Supporta operazioni quali il MOUNT e il NO MOUNT dei cataloghi, la gestione delle proprietà del catalogo, la gestione delle credenziali e l'utilizzo di entità del catalogo come tabelle, schemi e oggetti. Questo pacchetto è essenziale per l'integrazione di fonti di dati esterne e la gestione dei metadati in modo sicuro ed efficiente.

Modello di sicurezza

Il package DBMS_CATALOG opera nel modello AUTHID CURRENT_USER, ovvero viene eseguito con i privilegi dell'utente corrente. È necessario disporre delle autorizzazioni appropriate per eseguire operazioni quali il MOUNT dei cataloghi, l'aggiornamento delle proprietà o la gestione delle credenziali.
Nota

Pochi cataloghi richiedono Autonomous AI Database per connettersi a risorse Internet esterne. È pertanto necessario aggiungere gli indirizzi esterni pertinenti alle liste di controllo dell'accesso per l'utente del database associato. Ad esempio, quando si abilita l'accesso a un catalogo Databricks Unity Iceberg su Azure, potrebbe essere necessario inserire nella lista di inclusione due indirizzi: uno per l'accesso alle API REST di Iceberg e un altro se l'utente richiede l'accesso ai dati sottostanti.
BEGIN
  dbms_network_acl_admin.append_host_ace(
    host => '*.azuredatabricks.net',
    lower_port => 443,
    upper_port => 443,
    ace => xs$ace_type(
      privilege_list => xs$name_list('http', 'http_proxy'),
      principal_name => 'DBUSER',
      principal_type => xs_acl.ptype_db));

  dbms_network_acl_admin.append_host_ace(
    host => '*.blob.core.windows.net',
    ace => xs$ace_type(
      privilege_list => xs$name_list('http', 'http_proxy'),
      principal_name =>  'DBUSER',
      principal_type => xs_acl.ptype_db));
END;
/

Per eseguire i metodi DBMS_CATALOG è necessario disporre di DWROLE.

Eseguire il comando seguente per concedere DWROLE all'utente:
GRANT DWROLE TO MY_USER;

Tipi di catalogo e costanti

Questa sezione fornisce una panoramica dei tipi di catalogo e delle costanti chiave definite nel pacchetto. Spiega le diverse categorie di catalogo utilizzate per organizzare varie origini del catalogo e delinea costanti essenziali per la configurazione e la gestione delle proprietà e dei comportamenti del catalogo.

Tipi di catalogo

Il pacchetto specifica più tipi di catalogo per classificare e gestire diverse categorie di cataloghi. Di seguito sono riportati i campi.
  • CATALOG_TYPE_SHARE:

    Rappresenta un catalogo basato su condivisione, progettato principalmente per la condivisione di dati tra sistemi o utenti. Ad esempio, un servizio di condivisione dati come Data Sharing di Data Studio utilizza cataloghi basati su condivisione per distribuire i dati in modo sicuro.

  • CATALOG_TYPE_DATA_CATALOG: rappresenta data catalog esterni come AWS Glue o OCI Data Catalog. Questi cataloghi fungono da repository centralizzati per i metadati sui set di dati. Ad esempio, AWS Glue Data Catalog rileva e gestisce automaticamente i metadati delle origini dati tra i servizi AWS come S3 e Redshift, consentendo una perfetta integrazione dei dati e l'esecuzione di query.
  • CATALOG_TYPE_DB_LINK: rappresenta una categoria di catalogo creata da un database link. Questo tipo di catalogo consente di accedere e organizzare metadati e oggetti che risiedono in un database remoto o esterno, connettendoli tramite un database stabilito.

    Per ulteriori informazioni, vedere Caricare i dati dai database Oracle e non Oracle utilizzando i database link.

  • CATALOG_TYPE_VIRTUAL: rappresenta i cataloghi virtuali che forniscono un'astrazione sulle origini dati fisiche. I cataloghi virtuali non memorizzano i dati stessi, ma presentano un'interfaccia unificata per eseguire query su origini dati diverse, ad esempio viste virtuali create in una piattaforma di virtualizzazione dei dati.
  • CATALOG_TYPE_ICEBERG: rappresenta un catalogo Iceberg, che gestisce i metadati per le tabelle memorizzate nel formato Apache Iceberg. Iceberg è un formato da tavolo progettato per enormi set di dati analitici, che supporta funzionalità come l'evoluzione dello schema e il viaggio nel tempo.

    Per ulteriori informazioni, vedere Gestisci cataloghi.

Costanti

La sezione seguente evidenzia le costanti essenziali che definiscono le proprietà e le impostazioni del catalogo. Le costanti includono:
  • TYPE_CATALOG e NS_CATALOG: definisce il tipo di catalogo e lo spazio di nomi come CATALOG.
  • DEFAULT_CATALOG: nome catalogo predefinito impostato su LOCAL.
  • Costanti di proprietà quali PROP_IS_ENABLED, PROP_IS_SYNCHRONIZED, PROP_CACHE_ENABLED, PROP_CACHE_DURATION e altre per la gestione del comportamento del catalogo e dell'inserimento dei metadati nella cache.

    Nome costante Value Descrizione
    PROP_IS_ENABLED IS_ENABLED

    Questa proprietà determina se un catalogo è attualmente abilitato per query e ricerche.

    Valori validi:
    • : il catalogo verrà visualizzato nella finestra di dialogo di ricerca dell'interfaccia utente di Data Studio e può essere utilizzato nelle query SQL utilizzando la sintassi del database link (ad esempio, selezionare il nome utente da all_users@catalog).

    • NO: il catalogo verrà elencato nella vista ALL_MOUNTED_CATALOGS, ma non sarà incluso nelle ricerche dell'interfaccia utente di Data Studio e non potrà essere utilizzato nella sintassi del database link.

    PROP_CACHE_ENABLED CACHE_ENABLED

    Questa proprietà determina se i metadati di uno schema remoto devono essere inseriti nella cache nel database locale per migliorare le prestazioni.

    Valori validi

    • I metadati verranno inseriti nella cache al primo accesso e rimarranno nella cache per un periodo specificato da PROP_CACHE_DURATION.
    • NO:

      I metadati non verranno inseriti nella cache. Tutti i tentativi di accesso agli oggetti all'interno del catalogo raggiungeranno, al momento della query, l'origine dei metadati remoti.

    PROP_CACHE_DURATION CACHE_DURATION

    Il numero di secondi durante i quali i metadati devono essere conservati nella cache prima che diventino obsoleti. Il valore predefinito è di 3600 secondi (un'ora).

    Si noti che l'utente può svuotare la cache manualmente in qualsiasi momento chiamando DBMS_CATALOG.FLUSH_CATALOG_CACHE.

    L'utente può aggiornare la cache in qualsiasi momento chiamando DBMS_CATALOG.PREFILL_CATALOG_CACHE.

    PROP_CACHE_ASYNC 'CACHE_ASYNC'

    Questo campo viene visualizzato se la cache viene popolata mediante job asincroni.

    Valori validi

    • :

      I metadati verranno inseriti nella cache utilizzando un job DBMS_SCHEDULER creato la prima volta che un utente richiede i metadati.

    • NO:

      I metadati inseriranno nella cache l'utente nella sessione del database dell'utente che richiede i metadati.

    PROP_DEFAULT_SCHEMA DEFAULT_SCHEMA
    Nome di uno schema remoto che verrà scelto per impostazione predefinita se l'utente esegue una query del modulo:
    select * from table@catalog
    Lo schema predefinito svolge lo stesso ruolo dello schema dell'utente nel database locale.
    PROP_DCAT_TYPE DATA_CATALOG_TYPE

    Tipo di catalogo attivato da DBMS_CATALOG.MOUNT_DATA_CATALOG

    Valori validi

    • AWS_GLUE: il catalogo è definito sopra un repository AWS Glue remoto.
    • OCI_DCAT: il catalogo viene definito sopra un'istanza di OCI Data Catalog.
    Nota

    Questa è una proprietà di sola lettura.
    PROP_CUSTOM CUSTOM

    Una proprietà personalizzata è una coppia nome/valore associata dall'utente con un catalogo, uno schema, una tabella o un altro oggetto all'interno del catalogo.

    Esistono due modi per specificare una proprietà personalizzata:
    • È possibile impostare una singola proprietà personalizzata, ad esempio "MY_PROP", specificando il nome della proprietà composta 'CUSTOM:MY_PROP' insieme a un valore stringa arbitrario.
      DBMS_CATALOG.UPDATE_CATALOG_PROPERTY(
         catalog_name     => 'some_catalog',
         catalog_property => 'CUSTOM:MY_PROP',
         new_value        => 'Property Value');
      
    • È possibile specificare un gruppo di proprietà del cliente specificando il nome semplice della proprietà 'CUSTOM' insieme a un oggetto JSON che contiene coppie nome-valore.
      DBMS_CATALOG.UPDATE_CATALOG_PROPERTY(
         catalog_name     => 'some_catalog',
         catalog_property => 'CUSTOM',
         new_value        => '{"Property1" : "Value 1",
                               "Property2" : "Value 2",
                               ...}');
      
      Nota

      I nomi delle proprietà personalizzate fanno distinzione tra maiuscole e minuscole, pertanto CUSTOM:MY_PROP è distinto da CUSTOM:My_Prop.

      Per rimuovere una proprietà personalizzata, impostare il valore su NULL.

      Le proprietà personalizzate possono essere utilizzate come termini di ricerca nell'interfaccia utente di Data Studio. Ad esempio, è possibile trovare tutte le tabelle con la proprietà MY_PROP specificando il parametro condizioni in DBMS_CATALOG.GET_TABLES.
      SELECT table_name
      FROM DBMS_CATALOG.GET_TABLES(
             catalog_name => 'some_catalog',
             conditions => '#MY_PROP');
      

      È inoltre possibile cercare valori specifici.

      SELECT table_name
      FROM DBMS_CATALOG.GET_TABLES(
             catalog_name => 'some_catalog',
             conditions => '#MY_PROP="Property Value"');
      
    PROP_METADATA METADATA

    I metadati personalizzati sono simili alle proprietà personalizzate, ma possono contenere JSON in formato libero. I metadati vengono memorizzati con l'oggetto e possono essere recuperati, ma non vengono utilizzati come termine di ricerca.

    Esistono due modi per specificare i metadati personalizzati:
    • È possibile impostare l'intero metadati, come JSON, utilizzando il nome della proprietà 'METADATA'.
      DBMS_CATALOG.UPDATE_CATALOG_PROPERTY(
         catalog_name     => 'some_catalog',
         catalog_property => 'METADATA',
         new_value        => '{"subObject":{"propName":"abc"}}');
      
    • È possibile aggiornare un sottocomponente dei metadati utilizzando il nome della proprietà composta 'METADATA:path', dove il percorso è un percorso JSON relativo.
      DBMS_CATALOG.UPDATE_CATALOG_PROPERTY(
         catalog_name     => 'some_catalog',
         catalog_property => 'METADATA:subObject.propName',
         new_value        => 'xyz');
      
    PROP_CONFIGURATION CONFIGURATION

    La proprietà di configurazione viene utilizzata per aggiornare proprietà di configurazione specifiche per i cataloghi Iceberg. Funziona in modo simile alla proprietà CUSTOM.

    BEGIN
      dbms_catalog.update_catalog_property(
        'iceberg_cat', 
        'CONFIGURATION:IS_CASE_SENSITIVE', 
        'YES');
    END;
    /
    

Tipi di dati

Il pacchetto DBMS_CATALOG introduce diversi tipi di dati personalizzati per gestire le informazioni relative al catalogo. Di seguito sono riportati i campi.
  • credential_info e credential_info_map: strutture per memorizzare e mappare le informazioni sulle credenziali.
  • catalog_table e catalog_tables: si tratta di record e tabelle per la memorizzazione dei metadati dettagliati della tabella (ad esempio, proprietario, nome, descrizione, stato).
  • catalog_schema e catalog_schemas: record e tabelle per i metadati dello schema.
  • catalog_object e catalog_objects: record e tabelle per i metadati degli oggetti all'interno di un catalogo.