Particionamento Híbrido no 26ai: passo a passo de implementação e lições aprendidas

Introdução

Hybrid Partitioned Tables (HPT) reúnem sob o mesmo nome lógico de tabela, partições internas, armazenadas em tablespaces, e partições externas, armazenadas, por exemplo, no OCI Object Storage.

A técnica é especialmente útil para implementar gestão de ciclo de vida: dados quentes (mais utilizados) continuam no banco, suportando DML e índices; dados frios (menos usados) passam a arquivos externos, reduzindo custo de armazenamento sem interromper consultas SQL.

Este artigo organiza a demonstração realizada no Oracle Autonomous AI Database – 26ai, usando uma tabela do esquema SSB (Star Schema Benchmark), em 10 etapas.

Será utilizado um procedimento seguro e rápido para criação de HPT, baseado em Exchange Partitions.

O objetivo não é apresentar um script para execução irrestrita em produção, mas explicar o propósito, conceitos e controles necessários em cada etapa.

A base conceitual é a documentação de Hybrid Partitioned Tables

Pré-Requisitos para esta demonstração

Permissões concedidas como ADMIN ao esquema desta demo:

GRANT EXECUTE ON DBMS_CLOUD TO ORA26;
GRANT READ, WRITE ON DIRECTORY DATA_PUMP_DIR TO ORA26;
GRANT DB_DEVELOPER_ROLE TO ORA26;

select c_region, count(1) linhas 
from ssb.CUSTOMER
group by c_region;

ASIA 6002311
MIDDLE EAST 6002115
AMERICA 6000975
EUROPE 5996846
AFRICA 5997753

create table ora26.CUSTOMER
parallel(degree 4)
as
select *
from ssb.CUSTOMER

ALTER SESSION FORCE PARALLEL DDL PARALLEL 8;

-- definindo criterio de particionamento com MODIFY PARTITION
ALTER TABLE CUSTOMER MODIFY
  PARTITION BY LIST (c_region)
  (
    PARTITION p_asia        VALUES ('ASIA'),
    PARTITION p_middle_east VALUES ('MIDDLE EAST'),
    PARTITION p_america     VALUES ('AMERICA'),
    PARTITION p_europe      VALUES ('EUROPE'),
    PARTITION p_africa      VALUES ('AFRICA') 
  )
  ONLINE
  UPDATE INDEXES;

ALTER SESSION DISABLE PARALLEL DDL;

Ponto de atenção:  Para habilitar e fazer uso de sessões paralelas no Autonomous, como o FORCE PARALLEL DDL acima, fique atento ao Database Service Names utilizado na conexão ao banco.

Agora temos uma tabela particionada por lista, chamada CUSTOMER, sob esquema ORA26. Nos próximos 10 itens serão abordados detalhes de implementação e conceitos:

1. Exportação de dados em Parquet e criação da tabela Hibrida (HPT)

Nesta primeira etapa, a partição com dados da região ASIA (partição `P_ASIA`) será exportada para o Object Storage em formato PARQUET. Podem ser gerados vários arquivos nesta exportação, e um prefixo pode ser definido. No exemplo abaixo, isolei os arquivos sob folder “../p1/“:

BEGIN
DBMS_CLOUD.EXPORT_DATA(
credential_name => 'OCI_CRED',
file_uri_list => 
'https://objectstorage.sa-saopaulo-1.oraclecloud.com/n/xxx/b/bucket/o/p1/',
format => JSON_OBJECT('type' VALUE 'parquet'),
query => q'[ SELECT * FROM CUSTOMER PARTITION (P_ASIA) ]'
);
END;

Pontos de atenção: Note que a credencial (pré requisito) é usada para fazer a ponte entre o banco de dados e serviços da OCI, como o object storage acima.

Certifique-se de que o formato para exportação (file extension) esteja coberto pela documentação:

• Autonomous: https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/export-data-format-text.html
• Non-Autonomous: https://docs.oracle.com/en/database/oracle/oracle-database/26/arpls/dbms_cloud.html#GUID-810BDD01-7EC2-4367-8D50-D371A1BB5C2D

A query definida acima fez uso da cláusula PARTITION <name>, mas poderia ter sido feito com filtro via cláusula WHERE:  WHERE c_region = 'ASIA'

Em outros cenários, a credencial ou o mecanismo de autenticação precisa ser definido conforme o padrão de segurança da organização. Não coloque chaves de Object Storage diretamente em código-fonte.

Referências para acesso do Object Storage via DBMS_CLOUD: How to Setup Object Storage Access using DBMS_CLOUD in Autonomous Database (Shared) with Example – KB99747

Com a exportação realizada é possível listar arquivos para evidenciar nome, tamanho e data da geração dos arquivos Parquet, através do comando LIST_OBJECTS:

SELECT *
FROM DBMS_CLOUD.LIST_OBJECTS(
'OCI_CRED',
'https://objectstorage.sa-saopaulo-1.oraclecloud.com/n/xxx/b/bucket/o/p1/')

Diante destes arquivos Parquet, vamos criar uma tabela externa (que possui exclusivamente esta fonte de dados da região ASIA):

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
table_name => 'CUSTOMER_EXT',
credential_name => 'OCI_CRED',
file_uri_list =>
'https://objectstorage.sa-saopaulo-1.oraclecloud.com/n/xxx/b/bucket/o/p1/*.parquet',
column_list => '"C_CUSTKEY" NUMBER NOT NULL ENABLE,
"C_NAME" VARCHAR2(25) COLLATE "USING_NLS_COMP",
"C_ADDRESS" VARCHAR2(25) COLLATE "USING_NLS_COMP",
"C_CITY" CHAR(10) COLLATE "USING_NLS_COMP",
"C_NATION" CHAR(15) COLLATE "USING_NLS_COMP",
"C_REGION" CHAR(12) COLLATE "USING_NLS_COMP",
"C_PHONE" CHAR(15) COLLATE "USING_NLS_COMP",
"C_MKTSEGMENT" CHAR(10) COLLATE "USING_NLS_COMP"',
format => JSON_OBJECT('type' VALUE 'parquet')
);
END;

Note que o column_list acima tem exatamente a mesma ordem, nomes e tipos da tabela que deu origem ao Parquet. Sempre se atente a esta equalização para evitar falha mais adiante, na etapa do comando Exchange. Para gerar este metadado:

select dbms_metadata.get_ddl('TABLE','CUSTOMER','ORA26')

Para validação da tabela externa gerada, podemos executar uma consulta ou verificar o plano de execução (explain plan):

Neste momento temos 2 tabelas: uma tabela já particionada chamada CUSTOMER, e uma tabela externa chamada CUSTOMER_EXT que aponta a arquivos Parquet exportados da própria partição P_ASIA de CUSTOMER.

Aqui usamos a funcionalidade de Exchange Partition:  vamos trocar o segmento em banco associado a partição P_ASIA com o segmento externo definido em Parquet.

Para isso, ajustamos o DDL da tabela CUSTOMER para permitir esta fonte externa de dados: isto a definirá como Hybrid Partition Table (HPT) neste momento:

ALTER TABLE CUSTOMER
ADD EXTERNAL PARTITION ATTRIBUTES
( TYPE ORACLE_BIGDATA
DEFAULT DIRECTORY "DATA_PUMP_DIR"
ACCESS PARAMETERS
( com.oracle.bigdata.credential.schema="ORA26"
com.oracle.bigdata.credential.name="OCI_CRED"
com.oracle.bigdata.fileformat=parquet
com.oracle.bigdata.trimspaces=notrim
)
)
;

Ponto de atenção:  a fonte destes atributos externos (EXTERNAL PARTITION ATTRIBUTES) provém do DDL da tabela externa CUSTOMER_EXT. Se houver atributos diferentes entre estas tabelas haverá erro no ato da execução do Exchange. Para extraí-lo:

select dbms_metadata.get_ddl('TABLE','CUSTOMER_EXT','ORA26')

Antes de executar o Exchange, este é o cenário:

Segmentos:

• CUSTOMER_EXT não aparece pois é uma tabela externa, sem segmentos em banco (não está em tablespace)

Partições:

• Todas partições (com segmentos internos em banco) são associadas a CUSTOMER

Tabela Externa e Híbrida ( já definida em DDL, mas sem nenhum dado externo ainda):

• Tabela definida como hybrid em CUSTOMER, e external table para CUSTOMER_EXT

Trocando segmentos usando comando Exchange Partition:

ALTER TABLE CUSTOMER
EXCHANGE PARTITION p_asia
WITH TABLE CUSTOMER_EXT
WITHOUT VALIDATION;

Note algo desta troca de segmentos: trata-se apenas de uma troca no dicionário de dados, então, o tempo de resposta é muito rápido.

A sua tabela oficial, CUSTOMER, passa a ter uma partição hibrida com dados neste momento, acessando o parquet gerado efetivamente.

A outra tabela, CUSTOMER_EXT, passa a ter o segmento original em banco, e poderá ser apagada em segurança após período de validações e acompanhamento. Mantenha CUSTOMER_EXT até concluir validação funcional, desempenho, recuperação e aprovação operacional. Só então avalie sua remoção, conforme a política de retenção e backup.

Ou seja, veja a segurança em implementar o HPT desta forma, e caso necessário, bastaria realizar outro Exchange (com mesmo comando acima), para voltar ao cenário original.

Ponto de atenção: `WITHOUT VALIDATION` é rápido, mas transfere para a operação a responsabilidade de garantir que todas as linhas pertencem à partição alvo provenientes do arquivo externo. O Oracle descreve o Partition Exchange Load como troca lógica de metadados, sem movimentação de dados, quando os pré-requisitos são atendidos.

Após executar o Exchange, este é o novo cenário:

Segmentos:

• CUSTOMER_EXT está listado pois tornou-se um segmento em banco

• Partição P_ASIA deixou de aparecer em CUSTOMER como segmento! Não é mais um segmento que consome espaço no banco

Partições:

• A partição P_ASIA aponta ao parquet, e por isso está como READ ONLY.

Tabela Externa e Hibrida:

• CUSTOMER_EXT não é mais externa!

2. Índices para as partições

As partições externas não podem ser indexadas. Por isso, a estratégia é marcar partições internas com `INDEXING ON` ou `OFF` e criar índices parciais, locais ou globais não únicos, que cobrem apenas a parte interna elegível.

Deste modo, consultas que atingem a parte quente podem usar índice; consultas que atingem a parte externa dependerão de pruning de partição, formato do arquivo e varredura externa. Não modele uma HPT como se fosse uma tabela integralmente indexável.

Ponto de atenção: Índices únicos e índices globais únicos não são suportados nesse desenho híbrido. Restrições oficiais de HPT: https://docs.oracle.com/en/database/oracle/oracle-database/26/vldbg/partition-concepts.html?embed=1 – procure “Restrictions on Hybrid Partitioned Tables“

Exemplo:

ALTER TABLE customer  MODIFY PARTITION p_africa INDEXING ON;     
ALTER TABLE customer  MODIFY PARTITION p_america INDEXING ON;
ALTER TABLE customer  MODIFY PARTITION p_middle_east INDEXING OFF; 
ALTER TABLE customer  MODIFY PARTITION p_europe INDEXING OFF; 

create index CUSTOMER_I01 
on CUSTOMER( c_region, c_mktsegment ) 
GLOBAL INDEXING PARTIAL PARALLEL(DEGREE 4);

create index CUSTOMER_I02 
on CUSTOMER( c_custkey, c_region ) 
LOCAL INDEXING PARTIAL PARALLEL(DEGREE 4);

Plano de acesso quando filtramos partição interna (segmento de banco):

Plano de acesso quando filtramos partição externa – ASIA (parquet):

3. Exportação de dados em DUMP e criação da tabela Hibrida (HPT)

Crie uma nova tabela chamada CUSTOMER2, e use o mesmo critério de particionamento:

ALTER TABLE CUSTOMER2 MODIFY
PARTITION BY LIST (c_region)
(
PARTITION p_asia VALUES ('ASIA'),
PARTITION p_middle_east VALUES ('MIDDLE EAST'),
PARTITION p_america VALUES ('AMERICA'),
PARTITION p_europe VALUES ('EUROPE'),
PARTITION p_africa VALUES ('AFRICA')
)
ONLINE
UPDATE INDEXES;

O procedimento é semelhante ao tópico 1, porém com alguns ajustes.

Na primeira etapa realizaremos a exportação de uma partição, para dados da região ASIA por exemplo, no formato DataPump:

BEGIN
DBMS_CLOUD.EXPORT_DATA(
credential_name => 'OCI_CRED',
file_uri_list =>
'https://objectstorage.sa-saopaulo-1.oraclecloud.com/n/xxx/b/bucket/o/p2/dp.dmp',
format => JSON_OBJECT('type' VALUE 'datapump'),
query => q'[ SELECT * FROM customer2 PARTITION (p_asia) ]');
END;

Em seguida, copio o dump gerado no bucket para um directory DATA_PUMP_DIR:

BEGIN
DBMS_CLOUD.GET_OBJECT(
credential_name => 'OCI_CRED',
object_uri => 
'https://objectstorage.sa-saopaulo-1.oraclecloud.com/n/xxx/b/bucket/o/p2/dp.dmp',
directory_name => 'DATA_PUMP_DIR');
END;

Ponto de atenção: um dump criado por `expdp` não é automaticamente legível como external table pelo driver `ORACLE_DATAPUMP`.

Ponto de atenção: o usuário de banco que está executando esta demonstração tem permissão de acesso neste DIRECTORY.

Por último, a external table será criada com tipo Datapump, apontando para este dumpfile gerado e salvo em DATA_PUMP_DIR:

BEGIN
DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
table_name => 'CUSTOMER2_DP',
file_uri_list => 'DATA_PUMP_DIR:dp.dmp',
column_list => q'[
"C_CUSTKEY" NUMBER NOT NULL ENABLE,
"C_NAME" VARCHAR2(25) COLLATE "USING_NLS_COMP",
"C_ADDRESS" VARCHAR2(25) COLLATE "USING_NLS_COMP",
"C_CITY" CHAR(10) COLLATE "USING_NLS_COMP",
"C_NATION" CHAR(15) COLLATE "USING_NLS_COMP",
"C_REGION" CHAR(12) COLLATE "USING_NLS_COMP",
"C_PHONE" CHAR(15) COLLATE "USING_NLS_COMP",
"C_MKTSEGMENT" CHAR(10) COLLATE "USING_NLS_COMP"
]',
format => JSON_OBJECT(
'type' VALUE 'datapump',
'rejectlimit' VALUE '0'
)
);
END;

Note que o column_list acima tem exatamente a mesma ordem, nomes e tipos da tabela que deu origem ao Dump. Sempre se atente a esta equalização para evitar falha mais adiante, na etapa do comando Exchange. Para gerar este metadado:

select dbms_metadata.get_ddl('TABLE','CUSTOMER2_DP','ORA26')

Neste momento temos 2 tabelas: uma tabela já particionada chamada CUSTOMER2, e uma tabela externa chamada CUSTOMER2_DP que aponta ao arquivo DUMP gerado da própria partição P_ASIA de CUSTOMER2.

Aqui usamos a funcionalidade de Exchange Partition:  vamos trocar o segmento em banco associado a partição P_ASIA com o segmento externo definido em DUMP. Para isso, ajustamos o DDL da tabela CUSTOMER2 para permitir esta fonte externa de dados: isto a definirá como Hybrid Partition Table (HPT) neste momento:

ALTER TABLE CUSTOMER2
ADD EXTERNAL PARTITION ATTRIBUTES
( TYPE ORACLE_DATAPUMP
DEFAULT DIRECTORY "DATA_PUMP_DIR"
ACCESS PARAMETERS
( NOLOGFILE
)
)

Para listar EXTERNAL PARTITION ATTRIBUTES usado no comando acima:

select dbms_metadata.get_ddl('TABLE','CUSTOMER2_DP','ORA26')

Ponto de atenção:  a fonte destes atributos externos provém do DDL da tabela CUSTOMER2_DP.  Note que é diferente daquele usado no cenário de testes com Parquet! Se houver atributos diferentes entre estas tabelas haverá erro no ato da execução do Exchange.

Evidências:

Trocando segmentos:

ALTER TABLE customer2
EXCHANGE PARTITION p_asia
WITH TABLE customer2_dp
WITHOUT VALIDATION;

Evidência após Exchange:

Após Exchange, tabela híbrida CUSTOMER2 deixou de ter um segmento em banco chamado P_ASIA, e a tabela externa CUSTOMER2_DP passou a ter o segmento com estes dados.

Quando listamos as partições, vemos que a tabela CUSTOMER2 tem o acesso a partição externa P_ASIA (Dump), em modo Read Only. As demais partições continuam como segmentos em banco, e por isso, são originalmente READ WRITE.

HPT: (cenário análogo ao teste com Parquet anterior)

Assim como no item anterior, uma nova execução do comando Exchange voltaria ao cenário original (pode ser feito rapidamente, visto ser uma mudança no dicionário de dados).

4. Tuning com Database In-Memory por partição

O Oracle AI Database In-Memory quando atribuído a uma tabela, ou partição, melhora significativamente o desempenho para análises em tempo real e consultas analíticas.

Para Autonomous AI Database, temos esta seguinte premissa técnica para uso do In-Memory:

Para informações sobre modalidades de licenciamento em Autonomous, segue artigo neste link.

Uma vez dentro deste cenário, podemos associar partições ao In Memory, tanto partições do banco (1) quanto partições externas (2):

• (1) Partições Internas, exemplo:

Plano de execução:

• (2) Partições Externas, exemplo:

Mesmo partições externas, como P_ASIA, podem ficar no in memory , porém a visão do dicionário de dados para evidência e resgate da configuração passa a ser: user_xternal_tab_partitions

Plano de execução:

5. Constraints e integridade lógica (PK, FK, Unique)

Lidar com dados externos ao banco, a exemplo de partições em Parquet e Dump usadas nos itens acima, possuem um ponto importante: os dados não estão sob gestão do Oracle Database quanto a sua integridade.

Assim, uma vez que não podemos definir a unicidade de determinada coluna, ou mesmo garantir que pais ou filhos para chaves estrangeiras estejam definidos, passamos a usar constraints com RELY DISABLE.

O comando abaixo demonstra o uso de `RELY DISABLE`, permitindo que o otimizador use a informação declarada sem tentar impô-la (para certas transformações, QUERY_REWRITE_INTEGRITY deve estar em TRUSTED ou STALE_TOLERATED).

alter table customer2
add constraint pk_customer2
primary key(c_custkey) RELY DISABLE ;

Referência:

As restrições de unicidade, chave primária e chave estrangeira são suportadas em tabelas externas somente no modo RELY DISABLE.

Ao criar essas restrições, é obrigatório especificar as palavras-chave RELY e DISABLE. Elas são declarativas e não são impostas pelo banco.

Isso exige uma mudança de governança: qualidade e unicidade devem ser comprovadas antes de externalizar, preferencialmente na staging interna ou no pipeline de dados.

O `RELY DISABLE` não protege contra duplicidades. Em resumo:

• DISABLE: a constraint fica desativada. O Oracle não valida novos INSERT/UPDATE contra ela.
•  RELY: informa ao otimizador que ele pode confiar que a regra é verdadeira ao montar planos de execução — mesmo a constraint estando desativada ou não validada.

Assim, tabelas HPT com partições apontando a dados externos terão chaves neste modo de definição.

6. Posso utilizar BLOB e CLOB em Hybrid Partition Tables ?

Não. HPT tem restrições para tipos CLOB/BLOB e LONG, portanto, não se deve projetar uma HPT como mecanismo de arquivamento de BLOB/CLOB.

Separe metadados relacionais — bons candidatos a HPT — do conteúdo binário (BLOB/CLOB). Para este tipo de dados, as opções ainda são otimizações com SecureFiles (deduplicação, compressão) ou arquitetura com External Tables.

Pontos de atenção: 

Parquet não permite CLOB/BLOB: type not supported for export in parquet format

Lista de restrições: verificar “Restrictions on Hybrid Partitioned Tables“

Sobre LOBs em SecureFiles:

• O armazenamento de LOBs com SecureFiles foi projetado para oferecer desempenho e escalabilidade significativamente superiores aos LOBs BasicFiles, além de igualar ou superar o desempenho de sistemas de arquivos de rede tradicionais.
• O SecureFiles LOB oferece três novos recursos: compressão, desduplicação e criptografia.

Para confirmação, cheque a coluna “securefile” na visão “USER_LOBS / DBA_LOBS”.

Para alterar seu CLOB/BLOB de BasicFiles para SecureFile, uma das maneiras é o uso da DBMS_REDEFINITION. Trata-se de uma package que provê recursos para reorganização online. Esta mudança ocorre na etapa da definição da Interim Table.

Para pequenos segmentos LOB, uma maneira simples é usar ALTER TABLE.. MODIFY LOB:

7. Validar a partição híbrida antes e depois do Exchange

Para validações de tabelas HPT, utilize `DBMS_CLOUD.VALIDATE_HYBRID_PART_TABLE`. Esta rotina produz uma operação de validação que deve ser acompanhada por uma análise de `USER_LOAD_OPERATIONS` e nas tabelas de log indicadas pela execução.

De modo complementar, valide a contagem por partição, chaves de negócio, amostras de dados, schema, plano de execução e permissões de leitura no bucket.

Ponto de atenção:  Transforme a validação em um requesito da implantação: só remova ou marque como fria a cópia interna depois que o arquivo externo, a definição da tabela e as consultas críticas forem aprovadas.

8. Data Lake Accelerator para varreduras externas

O Data Lake Accelerator (recurso do Autonomous AI Database/Lakehouse) otimiza o desempenho e a escalabilidade do processamento de dados externos.

Ele aloca automaticamente recursos adicionais de CPU para acelerar a varredura de dados externos provenientes de Object Stores, com base nas necessidades das consultas. Essa integração possibilita o uso eficiente de recursos, respostas mais rápidas às consultas e fácil escalabilidade para grandes volumes de dados.

A habilitação é feita na console OCI > Autonomous AI Database > Tool Configuration > Data Lake Accelerator

9. Estatísticas de Banco

No Autonomous AI Database, a coleta automática nativa normalmente mantém as estatísticas das partições internas atualizadas.

Mas vale atualizá-las quando você:

• adiciona/troca uma partição externa;
• altera arquivos no Object Storage que alimentam a partição externa;
• carrega ou altera significativamente partições internas;
• observa planos ruins ou cardinalidades estimadas incorretamente

Em tabelas particionadas, o otimizador precisa de estatísticas no nível das partições/subpartições e no nível global. Atualizar estatísticas da tabela inteira após carga ou troca é custoso e desnecessário quando a mudança é localizada.

Para `EXCHANGE PARTITION`, por exemplo, a estratégia recomendada é coletar estatísticas na tabela de carga antes da troca — com preferências, histogramas e estatísticas estendidas compatíveis quando necessário — e então atualizar as estatísticas globais da tabela alvo. Isso evita surpresa de plano após publicar uma grande partição.

Referência: Efficient Statistics Maintenance for Partitioned Tables: Incremental Statistics and Partition Exchange Data Loading

10. Lições aprendidas

1. Atualização da chave de particionamento exige planejamento. Se o critério de particionamento não for a PK e um `UPDATE` mover a linha para outra partição interna, habilite `ENABLE ROW MOVEMENT`. Isso evita erros neste cenário de atualizar dados numa partição interna. E reforçando: partições externas são somente leitura. 

No Autonomous Database você ainda pode contar com Automatic Partitioning.

2. No `EXCHANGE PARTITION`, equalize os atributos externos no ato de definição da HPT. Compare o DDL de origem e destino com `DBMS_METADATA.GET_DDL`; diferenças em `EXTERNAL PARTITION ATTRIBUTES` são causa frequente de falha.

3. Criação de tabelas externas para uso com Exchange Partition. Informe `column_list` em `DBMS_CLOUD.CREATE_EXTERNAL_TABLE` para evitar divergências de ordem, tipo, precisão, semântica de caracteres e collation.

4. Filtre diretamente a chave de partição. Predicados sobre a chave permitem partition pruning e reduzem I/O, bytes de rede e latência.

5. Partições externas não aceitam DML, índices, e constraints devem ter RELY DISABLE. Cargas, correção e enriquecimento devem acontecer antes, normalmente numa staging interna.

6. Dump gerado por DBMS_CLOUD.EXPORT_DATA(... type => 'datapump') é diferente de exportações genéricas com `expdp`: arquivos criados por expdp podem não ser lidos pelo driver de external tables.

7. Estatísticas por partição são essenciais. Sem `DBMS_STATS`, o otimizador pode estimar cardinalidade de forma incorreta e escolher planos ruins. Para cargas recorrentes, use estatísticas incrementais.

8. Escolha corretamente o service name no Autonomous: `TP` e `LOW` não usam paralelismo; `HIGH` e `MEDIUM` habilitam Parallel clause. Fonte: Database Service Names.

9. HPT não pode fazer uso de External Table Cache: este recurso é exclusivo de `External Tables`. Para este tipo de objeto, há um ponto importante sobre formatos aceitos em cache: You can create external table cache for partitioned and non-partitioned tables created on the following file types: Parquet, ORC, AVRO, Iceberg Tables.

Conclusão

O valor do particionamento híbrido não está em converter uma tabela em um arquivo externo; está em operar uma única tabela lógica com camadas de armazenamento adequadas ao ciclo de vida do dado.

A implementação segura combina `EXCHANGE PARTITION`, validações, testes de plano de execução e uma governança robusta do Object Storage.

Com isso, Parquet, Dumpfile, … , deixam de ser uma escolha de formato isolada e passam a integrar uma estratégia mensurável de desempenho, custo e espaço alocado.

Por fim, Hybrid Partitioned Tables (HPT) é eficaz como estratégia de custo e desempenho: dados quentes no banco; dados frios em armazenamento externo, em geral, preservando o acesso SQL pela mesma tabela lógica, porém DML sobre partições externas, índices únicos, disponibilidade do Object Storage, novos planos de execução e integridade declarativa exigem avaliação.

Segurança e permissões precisam ser planejadas: acesso a diretórios, Object Storage, credenciais e criptografia são parte da arquitetura, não detalhes da implantação.