Gerenciar Catálogos com DBMS_CATALOG

O pacote DBMS_CATALOG fornece um conjunto abrangente de procedimentos, funções e tipos para gerenciar catálogos de banco de dados para o Oracle Autonomous AI Database.

O que é um Catálogo?

Um catálogo é definido como um conjunto de esquemas nomeados, cada um contendo um conjunto de objetos nomeados, como TABLES ou VIEWS. Todo banco de dados Oracle tem um único catálogo local – o dicionário de dados. Este catálogo está sempre presente e não pode ser removido. Mas há outros exemplos de catálogos, definidos fora do banco de dados.

O conjunto de objetos disponíveis por meio de um link de banco de dados
Um conjunto de objetos compartilhados disponíveis através do DBMS_SHARE (por exemplo, Delta Sharing);
Um conjunto de tabelas Iceberg gerenciadas por um Catálogo REST Iceberg;
Um conjunto de objetos definidos por um produto de terceiros, como Amazon Glue, Databricks Unity Catalog ou Snowflakes Polaris;
Um conjunto de objetos definido pelo Serviço Oracle OCI Data Catalog.
Um Catálogo também pode ser considerado como um "Domínio" ou "Produto de Dados", que é um conjunto de objetos agrupados para um propósito de negócios específico.

Para obter mais informações sobre a ferramenta de Catálogo do conjunto de ferramentas do Data Studio, consulte A Ferramenta de Catálogo.

Em um sistema operacional é possível acessar arquivos de dados externos montando um sistema de arquivos. Por analogia, você pode acessar dados externos em um Autonomous AI Database montando um catálogo usando o pacote DBMS_CATALOG.

O exemplo a seguir mostra como montar um Catálogo REST de Iceberg externo. Para usá-lo, você precisaria de três informações.

O ponto final do Iceberg REST Catalog;
Uma credencial (por exemplo, um token ao portador) usada para chamar este ponto final;
Uma credencial (por exemplo, um nome de usuário/senha) usada para acessar o bucket no qual os arquivos de dados do Iceberg são armazenados.

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;

O DBMS_CATALOG é usado para definir e tratar operações relacionadas ao catálogo.

Ele fornece um conjunto abrangente de procedimentos, funções e tipos para gerenciar catálogos no Oracle Autonomous Database. Ele suporta operações como montagem e desmontagem de catálogos, gerenciamento de propriedades de catálogo, tratamento de credenciais e trabalho com entidades de catálogo, como tabelas, esquemas e objetos. Este pacote é essencial para integrar fontes de dados externas e gerenciar metadados de maneira segura e eficiente.

Modelo de Segurança

O pacote DBMS_CATALOG opera no modelo AUTHID CURRENT_USER, o que significa que ele é executado com os privilégios do usuário atual. Você deve ter permissões apropriadas para executar operações como montagem de catálogos, atualização de propriedades ou gerenciamento de credenciais.

Observação

Poucos catálogos exigem que o Autonomous AI Database se conecte a recursos externos da Internet. Portanto, você deve adicionar os endereços externos relevantes às listas de controle de acesso do usuário do banco de dados associado. Por exemplo, ao habilitar o acesso a um catálogo do Iceberg do Databricks Unity no Azure, talvez seja necessário colocar dois endereços na lista branca: um para acessar as APIs REST do Iceberg e outro se o usuário precisar acessar os dados subjacentes.

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

Você deve ter o DWROLE para executar os métodos DBMS_CATALOG.

Execute o seguinte comando para conceder DWROLE ao usuário:

GRANT DWROLE TO MY_USER;

Tipos de Catálogo e Constantes

Esta seção fornece uma visão geral dos tipos de catálogo e constantes de chave definidos no pacote. Ele explica as diferentes categorias de catálogo usadas para organizar várias origens de catálogo e descreve as constantes essenciais para configurar e gerenciar propriedades e comportamentos de catálogo.

Tipos de Catálogo

O pacote especifica vários tipos de catálogo para classificar e tratar diferentes categorias de catálogos. Eles são:

CATALOG_TYPE_SHARE:
Representa um catálogo baseado em compartilhamento, que é projetado principalmente para compartilhar dados entre sistemas ou usuários. Por exemplo, um serviço de compartilhamento de dados como o Data Sharing do Data Studio usa catálogos baseados em compartilhamento para distribuir dados com segurança.
CATALOG_TYPE_DATA_CATALOG: Representa catálogos de dados externos, como AWS Glue ou OCI Data Catalog. Esses catálogos servem como repositórios centralizados para metadados sobre conjuntos de dados. Por exemplo, o AWS Glue Data Catalog descobre e gerencia automaticamente metadados de origens de dados em serviços da AWS como S3 e Redshift, permitindo integração e consulta de dados contínuas.
CATALOG_TYPE_DB_LINK: Representa uma categoria de catálogo criada com base em um link de banco de dados. Esse tipo de catálogo permite acessar e organizar metadados e objetos que residem em um banco de dados remoto ou externo, conectando-os por meio de um banco de dados estabelecido.
Consulte Carregar Dados de Bancos de Dados Oracle e Não Oracle usando Links de Banco de Dados para obter mais informações.
CATALOG_TYPE_VIRTUAL: Representa catálogos virtuais que fornecem uma abstração sobre origens de dados físicas. Os catálogos virtuais não armazenam dados, mas apresentam uma interface unificada para consultar fontes de dados diferentes - por exemplo, views virtuais criadas em uma plataforma de virtualização de dados.
CATALOG_TYPE_ICEBERG: Representa um catálogo Iceberg, que gerencia metadados para tabelas armazenadas no formato Iceberg do Apache. Iceberg é um formato de tabela projetado para enormes conjuntos de dados analíticos, suportando recursos como evolução do esquema e deslocamento no tempo.
Consulte Gerenciar Catálogos para obter mais informações.

Constantes

A seção a seguir destaca as constantes essenciais que definem as propriedades e configurações do catálogo. As constantes incluem:

TYPE_CATALOG e NS_CATALOG: Define o tipo de catálogo e o namespace como CATALOG.
DEFAULT_CATALOG: O nome do catálogo padrão definido como LOCAL.

Constantes de propriedades como PROP_IS_ENABLED, PROP_IS_SYNCHRONIZED, PROP_CACHE_ENABLED, PROP_CACHE_DURATION e outras para gerenciar o comportamento do catálogo e o armazenamento em cache de metadados.

Nome da Constante	Valor	Descrição
`PROP_IS_ENABLED`	`IS_ENABLED`	Esta propriedade determina se um catálogo está ativado para consulta e pesquisa no momento. Valores Válidos: SIM: O catálogo aparecerá na caixa de diálogo de pesquisa da UI do Data Studio e poderá ser usado em consultas SQL usando a sintaxe de link do banco de dados (por exemplo, selecione o nome de usuário em all_users@catalog). NÃO: O catálogo será listado na view `ALL_MOUNTED_CATALOGS`, mas não será incluído nas pesquisas da UI do Data Studio e não poderá ser usado na sintaxe de link de banco de dados.
`PROP_CACHE_ENABLED`	`CACHE_ENABLED`	Esta propriedade determina se os metadados de um esquema remoto devem ser armazenados em cache no banco de dados local para melhorar o desempenho. Valores Válidos SIM Os metadados serão armazenados em cache no primeiro acesso e permanecerão no cache por um período especificado por `PROP_CACHE_DURATION`. NÃO: Os metadados não serão armazenados em cache. Todas as tentativas de acessar objetos dentro do catálogo entrarão em contato, no momento da consulta, com a origem de metadados remota.
`PROP_CACHE_DURATION`	`CACHE_DURATION`	O número de segundos que os metadados devem ser mantidos no cache antes de se tornarem obsoletos. O valor padrão é 3600 segundos (uma hora). Observe que o usuário pode liberar o cache manualmente a qualquer momento chamando `DBMS_CATALOG.FLUSH_CATALOG_CACHE`. O usuário pode atualizar o cache a qualquer momento chamando `DBMS_CATALOG.PREFILL_CATALOG_CACHE`.
`PROP_CACHE_ASYNC`	`'CACHE_ASYNC'`	Este campo será exibido se o cache for preenchido usando jobs assíncronos. Valores Válidos YES: Os metadados serão armazenados em cache usando um job DBMS_SCHEDULER criado na primeira vez que um usuário solicitar os metadados. NÃO: Os metadados armazenarão em cache a sessão do banco de dados do usuário que solicitar os metadados.
`PROP_DEFAULT_SCHEMA`	`DEFAULT_SCHEMA`	O nome de um esquema remoto que será escolhido por padrão se o usuário executar uma consulta no formato: `select * from table@catalog` O esquema padrão desempenha a mesma função que o próprio esquema do usuário no banco de dados local.
`PROP_DCAT_TYPE`	`DATA_CATALOG_TYPE`	O tipo de um catálogo montado por `DBMS_CATALOG.MOUNT_DATA_CATALOG` Valores Válidos AWS_GLUE: O catálogo é definido no topo de um repositório remoto do AWS Glue. OCI_DCAT: O catálogo é definido em cima de uma instância do OCI Data Catalog. Observação Esta é uma propriedade somente leitura.
`PROP_CUSTOM`	`CUSTOM`	Uma propriedade personalizada é um par de nome/valor associado, pelo usuário, a um catálogo, esquema, tabela ou outro objeto dentro do catálogo. Há duas maneiras de especificar uma propriedade personalizada: Você pode definir uma única propriedade personalizada, por exemplo, "`MY_PROP`", especificando o nome da propriedade composta '`CUSTOM:MY_PROP`' com um valor de string arbitrário. `DBMS_CATALOG.UPDATE_CATALOG_PROPERTY( catalog_name => 'some_catalog', catalog_property => 'CUSTOM:MY_PROP', new_value => 'Property Value');` Você pode especificar um grupo de propriedades do cliente especificando o nome de propriedade simples 'CUSTOM' junto com um objeto JSON que contém pares de nome/valor. `DBMS_CATALOG.UPDATE_CATALOG_PROPERTY( catalog_name => 'some_catalog', catalog_property => 'CUSTOM', new_value => '{"Property1" : "Value 1", "Property2" : "Value 2", ...}');` Observação Os nomes de propriedades personalizadas fazem distinção entre maiúsculas e minúsculas, portanto, `CUSTOM:MY_PROP` é diferente de `CUSTOM:My_Prop`. Para remover uma propriedade personalizada, defina o valor como NULL. As propriedades personalizadas podem ser usadas como termos de pesquisa na IU do Data Studio. Por exemplo, você pode encontrar todas as tabelas com a propriedade MY_PROP especificando o parâmetro de condições em `DBMS_CATALOG.GET_TABLES`. `SELECT table_name FROM DBMS_CATALOG.GET_TABLES( catalog_name => 'some_catalog', conditions => '#MY_PROP');` Também é possível pesquisar valores específicos. `SELECT table_name FROM DBMS_CATALOG.GET_TABLES( catalog_name => 'some_catalog', conditions => '#MY_PROP="Property Value"');`
`PROP_METADATA`	`METADATA`	Os metadados personalizados são semelhantes às propriedades personalizadas, mas podem conter JSON de formato livre. Os metadados são armazenados com o objeto e podem ser recuperados, mas não são usados como um termo de pesquisa. Há duas maneiras de especificar metadados personalizados: Você pode definir todos os metadados, como JSON, usando o nome da propriedade 'METADATA'. `DBMS_CATALOG.UPDATE_CATALOG_PROPERTY( catalog_name => 'some_catalog', catalog_property => 'METADATA', new_value => '{"subObject":{"propName":"abc"}}');` Você pode atualizar um subcomponente dos metadados usando o nome da propriedade composta 'METADATA:path', em que o caminho é algum caminho JSON relativo. `DBMS_CATALOG.UPDATE_CATALOG_PROPERTY( catalog_name => 'some_catalog', catalog_property => 'METADATA:subObject.propName', new_value => 'xyz');`
`PROP_CONFIGURATION`	`CONFIGURATION`	A propriedade de configuração é usada para atualizar propriedades de configuração específicas para catálogos Iceberg. Ele funciona de maneira semelhante à propriedade CUSTOM. `BEGIN dbms_catalog.update_catalog_property( 'iceberg_cat', 'CONFIGURATION:IS_CASE_SENSITIVE', 'YES'); END; /`

Tipos de Dados

O pacote DBMS_CATALOG introduz vários tipos de dados personalizados para gerenciar informações relacionadas ao catálogo. Eles são:

credential_info e credential_info_map: São estruturas para armazenar e mapear informações de credenciais.
catalog_table e catalog_tables: São registros e tabelas para armazenar metadados de tabela detalhados (por exemplo, proprietário, nome, descrição, status).
catalog_schema e catalog_schemas: São registros e tabelas para metadados de esquema.
catalog_object e catalog_objects: São registros e tabelas para metadados de objeto em um catálogo.

Pacote DBMS_CATALOG
O pacote DBMS_CATALOG inclui uma ampla variedade de subprogramas para gerenciamento de catálogo, agrupados por funcionalidade.
Resumo do DBMS_CATALOG
Esta seção abrange os subprogramas DBMS_CATALOG fornecidos com o Autonomous AI Database.

Tópico principal: Referência de Pacote Fornecida pelo Autonomous AI Database

Documentação do Oracle Cloud Infrastructure

Gerenciar Catálogos com DBMS_CATALOG