DEV Community: Valter Zanchetti Filho

Reativar automations específicas após update da aplicação no Oracle APEX

Valter Zanchetti Filho — Mon, 20 Oct 2025 01:05:30 +0000

Uma coisa que as vezes é um pouco irritante é o fato de que o APEX desativa todas as automations depois que a aplicação é sobrescrita por uma nova versão.

Eu costumo automatizar boa parte do pipeline de geração e aplicação de release de objetos de bancos de dados e apps em outros servidores e percebi que, por padrão, as automations são sempre desativadas após o update do app.

Para contornar esse problema, fiz o script abaixo, que é rodado após o update bem sucedido de cada aplicação. Você pode modificar para as suas necessidades colocando cada uma das automations que você tem interesse em reativar. Você também pode modificar o script a seu critério.

SET SERVEROUTPUT ON

BEGIN
    apex_util.set_workspace('YOUR_WORKSPACE_NAME');

    apex_session.create_session(
        p_app_id   => 117,     --App ID 
        p_page_id  => 1,       --Any Page in the App
        p_username => 'VALTER'  );  -- Any valid APEX User

    --Enable specific automation
    apex_automation.enable(
        p_application_id  => 117, --App Id
        p_static_id       => 'emitir-espelho-retorno-nf' ); -- Static id

     --Destroying the session
    apex_session.delete_session;
END;
/

Você também pode fazer um loop simples para rodar em todas as suas automations ou criar alguma outra lógica se baseando no select dessa view:

SELECT * FROM APEX_APPL_AUTOMATION

Fontes:

https://docs.oracle.com/en/database/oracle/apex/24.1/aeapi/APEX_AUTOMATION_ENABLE-Procedure.html

Recuperando dados no Oracle (sem envolver o DBA) com FlashBack Query

Valter Zanchetti Filho — Tue, 14 Oct 2025 15:14:51 +0000

Sabe quando você faz aquela trapalhada épica, dá um UPDATE na tabela sem WHERE e ainda estava tão confiante que mandou um COMMIT logo em seguida? Pois é. Acontece. E quando o usuário altera ou apaga um monte de registros que não deveria? A primeira reação é ligar pro DBA, pedir pra restaurar o último backup, rezar pro RMAN... Mas nem sempre precisa chegar a tanto.

Existe um caminho mais simples — em muitos casos, muito mais fácil: o Flashback Query.

Mesmo sendo um recurso já bastante conhecido, vale a pena relembrar. Com ele, o Oracle consegue reconstruir o estado anterior das linhas usando os dados armazenados no UNDO. Em outras palavras, ele “volta no tempo” aplicando as mudanças inversas registradas ali.

E o melhor: até onde sei, esse recurso vem habilitado por padrão e é coisa antiga, então dificilmente você vai ter complicações para utilizá-lo.

Vamos direto ao ponto. Abaixo estão duas queries para comparação:

Uma consulta normal, com os resultados atuais, e outra usando Flashback Query para pegar os dados de 30 minutos atrás.

Você pode testar isso no seu próprio banco criando uma tabela, inserindo alguns registros, anotando o horário em que removeu os dados e depois executando o SELECT com o intervalo anterior.

Exemplo do uso

--Normal query with current results
SELECT *
FROM PEDIDO
WHERE ID_PEDIDO = 3487;

--Flashback query retrieving results from 30 minutes ago
SELECT *
FROM PEDIDO AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '30' MINUTE)
WHERE ID_PEDIDO = 3487;

Ótimo. Agora quero recuperar os registros que eu apaguei. Também é fácil.

Fazendo um insert com base nos dados de 30 minutos atrás

INSERT INTO PEDIDO
SELECT *
FROM PEDIDO AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '30' MINUTE)
WHERE ID_PEDIDO = 3487;
COMMIT;

É SÓ ISSO MESMO.

O artigo poderia acabar aqui. Caso você esteja um pouco mais curioso, pode continuar lendo o conteúdo abaixo. Você só vai conseguir seguir na parte abaixo se tiver privilégios de DBA.

Ver os parâmetros

Ah, legal. Agora quero saber qual o tempo de retenção (teórico) que eu tenho configurado:

SHOW PARAMETER undo_retention;

Ele vai te mostrar o valor em segundos. No meu caso está em 86.400 segundos, que significa 1.440 minutos ou 24 horas. É importante lembrar que esse valor é teorico. Por padrão, sempre que o banco precisar de espaço de undo, ele não vai respeitar o tempo de retenção informado, exceto se você tiver informado que ele deve garantir esse tempo. Para saber, vamos a seguinte query:

SELECT tablespace_name, retention FROM dba_tablespaces WHERE contents = 'UNDO';

✅ Se estiver GUARANTEE, o tempo de retenção é respeitado obrigatoriamente.

⚠️ Se estiver NOGUARANTEE, o Oracle pode sobrescrever os dados de undo antes do tempo, se precisar de espaço.

Garantir a retenção

Se quiser garantir que o Flashback Query funcione sempre até o limite configurado:

ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;

Eu não recomendaria fazer isso, porque se ele precisar respeitar o tempo de retenção e precisar de espaço de undo ao mesmo tempo e não encontrar, o banco vai estourar erro.

Ajustar o tempo de retenção

Aqui neste exemplo estamos colocando um tempo de retenção de 3600 segundos, ou seja, 60 minutos.

ALTER SYSTEM SET undo_retention = 3600;

É isso, pessoal. Não recomendo mexer nesses parâmetros, mas recomendo aproveitar a possibilidade do flashback query sempre que tiver uma situação simples para resolver. O Flashback Query é rápido e prático, mas não substitui uma estratégia de backup e recovery completa. Ele é mais útil para ‘pequenos acidentes’.”

Referências:

https://oracle-base.com/articles/10g/flashback-query-10g

Algo entre o VARCHAR2 e o CLOB: VARCHAR2 com esteróides [MAX_STRING_SIZE]

Valter Zanchetti Filho — Sun, 12 Oct 2025 13:52:50 +0000

Há aproximadamente 5 anos, quando estava desenvolvendo um módulo de CRM, precisei implementar um campo em que o vendedor pudesse descrever toda a conversa que teve com o cliente.

Inicialmente, fui no caminho óbvio e criei uma coluna VARCHAR2(4000). Depois de algum tempo utilizando, por incrível que pareça, uma das vendedoras começou a reclamar que este limite era muito pequeno para o nível de detalhe que ela queria colocar dessa conversa. Pediu para aumentar o limite.

No Oracle, temos a limitação de 4000 caracteres no VARCHAR2 e normalmente teríamos como upgrade o caminho mais óbvio, mudar para CLOB. Isso envolveria mexer na tela já criada e alterar algumas coisas a nível de sessão e integração. Mudar para CLOB implica na forma em que o banco de dados armazena os esses registros e também na forma em que várias aplicações acessam essas colunas. Decidi pesquisar um pouco e logo me deparei com uma solução que já existe desde o Oracle 12C. Um simples parâmetro chamado MAX_STRING_SIZE;

Se este parâmetro for alterado de STANDARD para EXTENDED você conseguirá trabalhar com um VARCHAR2(32000), para ser mais preciso, VARCHAR2(32767), o que não te dá a mesma capacidade que um CLOB, mas já é um ótimo upgrade do VARCHAR2(4000). É perfeito para os casos em que precisamos de um meio termo.

Antes de qualquer coisa, recomendo ler esse conteúdo da Oracle para saber se essa será uma boa escolha.

Para saber se seu banco já está com o esse parâmetro basta rodar o comando abaixo se tiver permissão na v$parameter:

SELECT name, value 
FROM v$parameter 
WHERE name = 'max_string_size';

Aqui vou explicar apenas como alterar na Autonomous Database para exemplificar, mas no link acima você consegue ver como rodar em CDB Padrão, PDB, etc.

Logado com ADMIN, execute:

 BEGIN
     DBMS_MAX_STRING_SIZE.MODIFY_MAX_STRING_SIZE('EXTENDED');
   END;

Pronto, resolvido. Daqui pra frente é só alegria.

Vale a pena alertar que:

A alteração é irreversível (uma vez EXTENDED, não volta para STANDARD sem recriar o banco).
Pode afetar compatibilidade com clientes antigos (SQL Developer, drivers JDBC etc.).
Pode afetar backups ou replicações se houver sistemas legados.

Nunca tinha pensado em fazer um post sobre isso antes porque pensava que esse parâmetro já era algo bem difundido, mas vi que várias pessoas com quem tenho conversado neste último ano, inclusive DBAs ainda não conheciam, então achei relevante publicar.

Comente aqui. Você já tinha ouvido falar? Já tinha usado? Achou útil?

Referências:

https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/MAX_STRING_SIZE.html

https://docs.oracle.com/en-us/iaas/autonomous-database-serverless/doc/dbms-max-string-size.html

Passando valores com vírgulas entre páginas usando o Link Builder no Oracle APEX

Valter Zanchetti Filho — Sun, 03 Aug 2025 13:56:53 +0000

No primeiro ano de carreira, um problema que me rendeu um pouco de dor de cabeça foi o fato de que eu precisava passar vários valores de itens de uma página para outra através de um link. Isso sempre havia funcionado de forma bem consistente, até que certo dia começou se comportar de forma estranha numa página específica. A única diferença entre essa página e as páginas que funcionavam era o fato de que essa página estava passando valores com vírgula. Comecei a pesquisar e vi várias opções que na época pareciam um pouco complexas. Continuei a pesquisa até encontrar algo fácil. Vamos direto ao resultado para salvar o seu tempo.

O problema:

Exemplo:

Tenho essa content row abaixo (que poderia ser também uma linha de um Interactive Report, Grid ou qualquer outro compontente).

Veja que o título dela contem palavras separadas com vírgula. O mesmo ocorre na barra de progresso, que também tem um valor com vírgula.

No botão de ações tenho um link criar uma nova linha baseada nesta. Esse link leva para a página de cadastro com os campos pré-preenchidos baseados no conteúdo da atual linha. O que seria normal fazermos neste caso é exatamente o que está no screenshot abaixo, informando o destino e o valor correspondente:

Porém, se fizermos assim, quando clicarmos no link gerado pelo LINK BUILDER termos um dos seguintes comportamentos:

Erro ao renderizar a página porque um dos itens está retornando um valor inválido
A página vai renderizar mas os valores estarão sendo passados para os campos errados, de forma embaralhada.
A página vai renderizar mas os valores que tinham vírgula irão perder o conteúdo após a vírgula.

A solução:

O caminho mais rápido e prático para fazer isso é utilizar a contrabarra (\) antes e depois do item que estamos passando através do link builder, assim como mostrado no exemplo abaixo:

Isso acontece porque quando passamos os valores dos itens através do link builder, o APEX irá separar eles por vírgula para passar para a próxima página. É por isso que ele se perde quando passamos um valor com vírgula.

A “\” serve justamente como se fosse colocar o valor entre aspas no Link Builder, mostrando que a vírgula faz parte da expressão.

É, fácil assim. Pode testar que vai funcionar e a dor de cabeça vai acabar.

Depois de testar, lembre de comentar aqui embaixo a sua experiência.

Oracle APEX: Transcrevendo audio em texto sem uso de REST direto no navegador em 5 minutos

Valter Zanchetti Filho — Sun, 03 Aug 2025 02:08:34 +0000

Sempre que faço uma pesquisa devido a alguma necessidade específica, costumo explorar o Google e o Github , fazendo o download de aplicações que outros devs publicam para tentar aprender novas técnicas. Despretensiosamente, buscando formas de fazer drag and drop num interactive grid, me deparo com um teste de transcrição de audio para texto do Paulo Kunzel neste link. Aproveitei que já tinha instalado o app e decidi testar.

Aqui vai meu parecer: Achei o funcionamento dessa abordagem fantástico pelo fato de ser tão rápido e rodar diretamente no navegador e sem necessidade de contratação de qualquer plano de empresa externa, chamada REST ou AI para processar essa transcrição. Pedi para o ChatGPT explicar sobre o funcionamento disso e aqui vai a resposta:

“O reconhecimento de voz no navegador usando SpeechRecognition funciona de forma nativa, sem a necessidade de enviar manualmente o áudio para um servidor. No entanto, o áudio é processado na nuvem — normalmente pelos servidores do Google — de forma automática e transparente. O navegador capta o som do microfone, envia para os servidores de reconhecimento de fala e retorna o texto convertido via eventos JavaScript, tudo isso sem exigir chamadas manuais a APIs ou bibliotecas externas.”

Explorando um pouco a aplicação fiz alguns pequenos ajustes para aceitar audios mais longos e decidi compartilhar a técnica, que é bem simples, por aqui.

Criar um botão com um nome e static id de sua preferência. Este botão deve ter ação definida como dynamic action. Neste caso vamos chamar o botão de DITAR e vamos colocar o static-id como st_ditar
Criar um campo de texto onde o texto ditado será transcrito em tempo real. Neste caso o campo será o P31_TEXTO_RAPIDO.
Cadastrar o código abaixo no Execute when Page Loads da sua página, trocando os nomes e static ids por outros de sua preferência:

let recognition = new window.SpeechRecognition();

recognition.grammars = new window.SpeechGrammarList(); recognition.continuous = true; 
recognition.lang = 'pt-BR'; 
recognition.interimResults = true; 
recognition.maxAlternatives = 1; 

/* recognition.addEventListener('speechend', () =>{ recognition.stop(); }); */

document.querySelector('#st_ditar').addEventListener('mousedown', () =>{ recognition.start(); });
document.querySelector('#st_ditar').addEventListener('mouseup', () =>{ recognition.stop(); });

recognition.addEventListener('error', (event) => { console.error('Erro no reconhecimento do texto: ', event.error); });

recognition.onresult = function (event) { console.log('-----------------------------'); 

let last = event.results.length - 1; 
let texto = event.results[last][0].transcript; 

apex.item('P31_TEXTO_RAPIDO').setValue(texto);

Explicação rápida:

Este código ativa o reconhecimento de voz no navegador usando a API SpeechRecognition. Ao clicar e segurar o botão com id="st_ditar", o reconhecimento começa (mousedown), e ao soltar (mouseup), ele é encerrado. O áudio capturado é enviado automaticamente para os servidores de reconhecimento de fala do navegador (Google ou Microsoft, dependendo do navegador), que retornam o texto. O resultado final é atribuído ao item P31_TEXTO_RAPIDO do Oracle APEX. A configuração define o idioma como português do Brasil (pt-BR), ativa resultados parciais (interimResults) e limita as alternativas de texto a uma (maxAlternatives = 1). Erros são tratados e exibidos no console com console.error.

Quanto aos dois parâmetros:

`interimResults`

true :

O reconhecimento retorna resultados parciais enquanto a fala ainda está acontecendo. Isso é útil para mostrar texto "ao vivo", em tempo real.
false:

O navegador só retorna o texto final, após detectar uma pausa na fala. Isso reduz a quantidade de eventos disparados, mas não mostra nada durante a fala.

`maxAlternatives`

1:

Retorna apenas a melhor interpretação da fala.
>1 (ex: 3):

Retorna várias alternativas para a mesma fala, ordenadas por confiança. Isso pode ser útil se você quiser deixar o usuário escolher entre diferentes opções ou fazer validações com maior tolerância.

No meu exemplo a tela ficou assim:

Em 5 minutos você consegue replicar isso na sua aplicação. Tente e depois comente aqui o que achou disso.

Começando com CI/CD no Oracle Database/APEX usando SQLcl

Valter Zanchetti Filho — Mon, 28 Jul 2025 02:51:09 +0000

Depois de muito ler, tentar compreender, testar e apanhar da ferramenta, consegui fazer funcionar um processo simples de CI/CD entre desenvolvimento e produção. Consigo gerar releases da base de desenvolvimento que podem ser aplicados da mesma forma em outras bases de produção. Neste artigo, pretendo mostrar um pouco da minha abordagem.

Antes de iniciar, vamos alinhar as expectativas:

A. Nem tudo é perfeito

Se você espera um script perfeito, que vai fazer absolutamente tudo por você, já pode deixar essa expectativa de lado. SQLcl não é perfeito nem tão bem documentado. Você ainda vai precisar fazer alguns ajustes manuais.

Percebo que em cada versão existe um bug diferente, mas sempre é possível contornar de alguma forma;

B. Objetos java são ignorados

Objetos JAVA no banco de dados são esquecidos pela ferramenta. Você vai precisar encontrar uma forma de contornar isso, caso utilize.

C. Atenção se as duas bases rodam no mesmo PDB

Se você tem as bases de produção e desenvolvimento no mesmo PDB, sugiro fazer o CI/CD do APEX/ORDS num projeto separado, porque tem algumas particularidades que podem te trazer problemas.

D. Essa abordagem sugere que você está gerando os artefatos pela primeira vez

Estamos considerando aqui neste artigo que você está gerando os artefatos pela primeira vez para rodar numa base limpa. Se quiser rodar numa base que já está com os objetos atualizados, vai precisar rodar um comando para que elas se entendam. Vou dar a dica deste comando no final do artigo.

Requisitos:

Para seguir o passo a passo desse artigo você vai precisar de Oracle Database, é claro. Além disso, para replicar o tutorial você precisará de:

Windows (pode utilizar Linux, mas vai precisar adaptar alguns comandos/abordagens)
SQLcl (neste artigo utilizei a versão 25.2.1.195)
Java (neste artigo jdk-21.0.8)
Oracle Instant Client (neste caso 23.8)
GIT (qualquer versão recente. Precisa ser instalado, não vale o portátil.)

Depois de tudo isso instalado, vamos iniciar abrindo o CMD no windows e setar algumas variáveis manualmente para não ter risco de ele se perder. Abaixo temos apenas um exemplo, mas você vai precisar definer os paths conforme a sua instalação. Recomendo digitar linha por linha para ter certeza que o Windows entendeu o que foi passado. Abaixo, o meu exemplo:

rem O Comando CHCP 650001 vai fazer com que o seu CMD trate melhor caracteres como acentos, entre outros.
chcp 65001 
rem Se houver estouro de memória pode setar manualmente a memória do Java.
rem set JAVA_TOOL_OPTIONS=-Xms512m -Xmx6G 
rem Aqui iremos definir o diretório do seu Java Home, assim teremos certeza que ele irá buscar no local correto.
set "JAVA_HOME=C:\Oracle\jdk-21.0.8"
rem Vamos também definir o diretório do seu SQLcl
set "SQLCL_HOME=C:\Oracle\sqlcl-25.2.1.195.1751\sqlcl"
rem Caso necessário, temos aqui também o caminho do instant client
rem SET INSTANT_CLIENT_HOME=C:\Util\instantclient\instantclient_23_4 
rem Com este comando, incluímos tudo isso junto com o PATH padrão.
set PATH=%SQLCL_HOME%\bin;%JAVA_HOME%\bin;%INSTANT_CLIENT_HOME%;%PATH%
rem Se quiser, pode chamar diretamente os dados do DB via TNSADMIN. O comando abaixo so se torna necessário se você fizer questão de usar o TNSADMIN
set TNS_ADMIN=C:\Oracle\instantclient_23_4\network\admin

Você configurou o ambiente para iniciar os próximos passos. Não feche esta janela pois nela foram passados todos os parâmetros que precisamos. O nome do meu projeto exemplo será PMT.

Pode deixar o CMD minimizado e criar uma pasta vazia para o seu projeto. No meu caso, a pasta será:

C:\Oracle\projetos\PMT. No CMD vamos navegar até a pasta criada

cd C:\Oracle\projetos\PMT

É importante garantir que você está na pasta certa. Agora podemos conectar o SQLcl:

CONECTANDO NO SQLCL

Para conectar no SQLcl, você tem mais de uma opção. Escolha apenas uma delas

Conectar diretamente sem passar inicialmente a conexão com o banco, deixando para passar os dados da conexão após abrir o SQLcl.

sql -thin /nolog

conn PMT/pass@dbpessoal

Conexão passando o caminho diretamente

sql -thin PMT/pass@//databasehostnameorip:1521/servicename

Conexão via TNSNAMES.

sql -thin PMT/pass@dbpessoal

PREPARANDO SEU PRIMEIRO RELEASE

Depois de conectado no banco de dados via SQLcl, já na pasta do seu projeto, você vai precisar iniciar e definir algumas configurações do projeto. Isso só precisará ser feito uma única vez.

project init -name PMT -schemas PMT

Configurando o projeto

Assim que o projeto é iniciado, você pode simplesmente ignorar configurações adicionais ou personalizar de acordo com a sua preferência. Para verificar as configurações disponíveis, pode usar o comando abaixo.

project config -list -verbose

Abaixo, vou listar os comandos de minha preferência, que podem ser utilizados como exemplo ou não. Para entender o que cada um dos comandos faz, você pode rodar o comando acima, que está tudo bem explicado.

project config set -name export.format.enable -value false -verbose 
project config set -name export.setTransform.emitSchema -value false -verbose
project config set -name export.apex.expComments -value true -verbose 
project config set -name export.apex.expOriginalIds -value true -verbose 
project config set -name export.apex.expSavedReports -value true -verbose 
project config set -name export.apex.expPubReports -value true -verbose

Essa configurações ficam gravadas num arquivo dentro da pasta .dbtools.

Configurando filtros

Dentro da mesma pasta .dbtools, existe um subpasta de nome filters com um único arquivo project.filters. Se abrir o arquivo, verá outras configurações adicionais, como por exemplo, opções de ignorar objetos no projeto, exportar somente aplicações APEX específicas. Neste caso, não iremos fazer nenhuma mudança no arquivo. Vamos direto aos comandos GIT. De qualquer forma, recomendo que você analise os objetos APEX, ORDS e grants.

Considerando que você já tem o GIT instalado, iremos criar o main branch através deste comando. Como você ainda está dentro do SQLcl, teremos que adicionar um ! na frente dos comandos git. Isso vale para qualquer outro comando de sistema operacional dentro do SQLcl.

--com este comando você irá criar seu branch inicial e se posicionar nele. É importante colocar mesmo aqui que vem depois dos dois traços: -- nesse primeiro comando:
!git init --initial-branch=main

--com este comando iremos adicionar os arquivos no git
!git add .

--após adicionar precisamos fazer o commit e podemos cadastrar uma mensagem para identificar esse commit.
!git commit -m "Inicialização do projeto"

Agora vamos fazer nosso primeiro release, chamaremos de 1.0.

--esse comando vai criar o branch e nos colocar dentro dele
!git checkout -b release-1.0

Estamos dentro do branch 1.0, então é hora de exportar nosso banco de de dados. Para isso iremos rodar os comandos abaixo. Não deixe seus desenvolvedores fazerem modificações na sua base enquanto o export não termina.

-- Você pode escolher o número de threads utilizadas. Neste caso, escolhi 5 threads, que é o padrão.
project export -threads 5 -verbose

--adiciona e faz o commit no git.
!git add .
!git commit -m "release-1.0"

Apenas para conhecimento, todos os objetos exportados ficam na pasta /scr.

Depois disso, colocaremos o projeto em stage, que irá comparar o export atual com os branches anteriores. Abaixo, a lista de comandos.

--a primeira coisa a fazer é rodar o project stage, que irá compar os objetos exportados na versão atual com as versões anteriores.
project stage

--se você quiser adicionar uma lista de comandos dml, deve acrescentar com este comando, nessa etapa.
--project stage add-custom -file-name dml_file_name

--caso queira verificar se está tudo certo com o projeto pode rodar o project verify, mas não é obrigatório.
--project verify -verbose 

--vamos informar a versão do release
project release -version 1.0 -verbose
--com o comando abaixo, iremos gerar o artefato. Um .zip com toda a instrução de deploy e todos os objetos, já listados na ordem em que devem ser executados.
project gen-artifact -version 1.0 -verbose

--adicionamos e commitamos.
!git add . 
!git commit -m "Commit Version 1.0"

--depois de resultado de sucesso em todas as etapas acima precisamos voltar para o branch main e fazer um merge com o release atual.
!git checkout main 
!git merge release-1.0

Nesta etapa você concluiu a geração do seu primeiro release e está pronto para aplica-lo em outras bases.

FAZENDO O DEPLOY DO SEU PRIMEIRO RELEASE NA BASE DE DESTINO

Depois que o seu release estiver pronto, você verá que o objeto .zip estará na sua pasta artifacts, dentro da pasta principal do seu projeto. Agora iremos repetir alguns comandos e acessar a base de destino. Lembrando que estamos considerando uma base de destino limpa, onde os objetos ainda não existem. Se a outra base já contiver os objetos isso não vai funcionar, precisa rodar primeiro um outro comando para isso, que será abordado no final desse artigo.

Caso ainda esteja com o cmd aberto, basta rodar o comando quit para sair do SQLcl e reconectar na base que irá receber os objetos. Caso tenha fechado o cmd, basta rodar novamente os comandos de setar as variáveis de ambiente, voltar para a pasta do projeto e iniciar o SQLcl (dessa vez você irá conectar na base de destino, aquela que vai receber os objetos. Isso é muito importante.)

project deploy -file artifact/PMT-1.0.zip -verbose

Como escolhemos o modo verbose ele irá mostrar cada objeto que está sendo incluído no banco de dados de destino, até você receber a mensagem de sucesso. Além dos seus objetos, ele vai criar 3 tabelas na sua base de destino: DATABASECHANGELOG, DATABASECHANGELOG_ACTIONS e DATABASECHANGELOGLOCK, que são as tabelas de controle do liquibase.

PREPARANDO SEUS PRÓXIMOS RELEASES

Considerando que você já gerou seu primeiro release e agora precisa gerar outros, recomendo fazer um backup da pasta do projeto. Não tente usar o comando de compactar do windows, pq ele desconsidera tudo o que tem relação com o git naquela pasta. Você pode copiar a pasta ou gerar um .zip com o 7Zip.

Vamos ao trabalho. O primeiro passo é voltar para o SQLcl, na pasta do projeto e conectar na base de origem novamente. Para isso vamos executar:

--exportando o projeto novamente
project export -verbose
--criando novo branch
!git checkout -b release-1.1
!git add . 
!git commit -m "Novos arquivos exportados da base de desenvolvimento na ver. 1.1"
-- colocando em stage para comparar nosso branch atual com o main
project stage -verbose
--criando o release
project release -version 1.1 -verbose
--gerando o novo artefato
project gen-artifact -version 1.1 -verbose
!git add . 
!git commit -m "Commit dos novos arquivos da versão 1.1"
--fazendo o checkout e voltando para o main branch
!git checkout main
--fazendo o merge do último release na main
!git merge release-1.1

Tudo pronto. Você verá agora mais um artefato .zip incrementado com todos os objetos do release anterior + os objetos do release atual. Na hora de aplicar, ele irá confirmar no liquibase que todos os objetos do release anterior foram aplicados e logo irá começar a aplicar as mudanças do release atual. Caso você já tenha certeza que os anteriores estão aplicados com sucesso, pode descompactar o artefato e remover as referências dos releases anteriores do xml main.changelog que fica em /releases.

Após modificado precisará recompactar o arquivo com as alterações para poder fazer o deploy.

OUTRAS CONSIDERAÇÕES

A. Caso você esteja querendo iniciar quando sua base de dados de destino já contém os objetos:

Neste caso você irá criar os objetos normalmente, porém, antes de fazer o deploy do primeiro release na base de destino, precisará rodar o comando abaixo [na base de destino]:

liquibase changelog-sync -chf dist/releases/main.changelog.xml

Esse comando irá criar as tabelas do liquibase na sua base de destino e marcar os objetos como já aplicados. A partir daqui os próximos releases irão funcionar, visto que ele entenderá que o primeiro já foi aplicado.

B. Se estiver tentando aplicar tudo isso no mesmo PDB, porém em schemas diferentes:

Faça com que o ORDS e APEX sejam um processo a parte, porque ele pode acabar tentando substituir o que já existe. Para isso em .dbtools/filters marque para não exportar APEX nem ORDS, você pode fazer isso depois de forma separada.

OBSERVAÇÕES FINAIS:

Algumas observações pessoais sobre este processo:

Cada artefato de release novo carrega todos os releases antigos junto com ele. Ele sempre vai se comportar assim, porém, na hora de aplicar, para tudo funcionar você não deve mais por a mão na base de destino, principalmente no que diz respeito a criação de objetos e alterações de tabelas. Todo o processo deve ser feito somente através da ferramenta.
No windows, percebi que as permissões ficam bem vinculadas com o usuário, então se você tem um servidor TS e mais de uma pessoa vai mexer, recomendo criar um usuário devops.
As vezes a tela congela e você precisa apenas apertar ENTER para continuar. Em alguns casos a tela congela e não tem enter que resolva, só esperar. É normal.
Recomendo gerar os releases com certa frequência, não deixar acumular muitas mudanças para gerar o release. Digo isso, pois facilita bastante na hora de investigar o artefato em busca de erros.
Teste por sua conta e risco. Recomendo fazer backups do banco de dados antes de fazer os deploys.
Se tiver interesse em ver o tutorial adaptado para linux, basta comentar aqui, porque já comecei a trabalhar nisso.

Bugs que eu percebi em algumas versões do SQLcl

25.2.1 - Percebo que a versão ainda tem problemas para lidar com chaves primários tipo IDENTIFIED BY. Precisei trocar várias tabelas do banco de dados para o modelo normal (sequence + trigger) para não apresentar erro. Ainda tenho problema para o liquibase reconhecer objetos que foram dropados ou renomeados. Também pode apresentar problemas para conectar via TNSNAMES.

24.1 - As sequences já existentes são geradas toda vez e isso traz conflito.

Referências:

https://rafal.hashnode.dev/part-51-oracle-sqlcl-project-the-only-cicd-tool-for-apex-you-will-ever-need

https://pretius.com/blog/oracle-sqlcl-project-command

Desconsiderando maiúsculas, minúsculas e acentos com collations no Oracle

Valter Zanchetti Filho — Thu, 24 Jul 2025 16:32:35 +0000

Às vezes, precisamos fazer comparações no Oracle nas quais queremos desconsiderar se o texto está em maiúsculas, minúsculas ou se contém acentos. Para isso, existe uma solução chamada COLLATE, que pode ser utilizada a nível de tabela, sessão ou diretamente na query. Neste artigo, trataremos das collations aplicadas a nível de query.

Exemplo prático:

Você precisa consultar uma pessoa na base de dados chamada José, porém, no banco de dados ela está registrada como Jose — ou vice-versa. Nesse caso, a comparação padrão seria:

SELECT * FROM DUAL WHERE 'JOSÉ' = 'JOSE';

Resultado: nenhuma linha selecionada

Isso acontece porque, no padrão do banco de dados Oracle, 'JOSÉ' não é igual a 'JOSE'. No entanto, se utilizarmos uma collation específica, o Oracle poderá desconsiderar os acentos no momento da comparação.

Veja este exemplo:

SELECT * FROM DUAL WHERE 'JOSÉ' COLLATE BINARY_AI = 'JOSE'; 
SELECT * FROM DUAL WHERE 'JOSÉ' COLLATE BINARY_AI = 'Jose';

Se executarmos essas queries, obteremos uma linha de resultado para cada uma. Por quê?

Quando utilizamos o COLLATE BINARY_CI ou BINARY_AI, estamos informando ao banco que ele deve considerar os textos da seguinte forma:

_CI (Case Insensitive): Ignora diferenças entre maiúsculas e minúsculas, mas considera acentos.
_AI (Accent Insensitive): Ignora acentos, maiúsculas e minúsculas.

Simples e prático!

Você também pode definir uma collation a nível de tabela ou até mesmo de coluna, permitindo que todas as queries feitas sobre esse dado ignorem automaticamente as diferenças de acentuação e CASE.

Fontes:

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/nlspg/linguistic-sorting-and-matching.html#GUID-68633595-DC95-4393-A6B8-146AD05F5FDF

https://binovarghese.com/notes/2022/10/column-level-collation-and-case-insensitive-database-in-oracle/

Rastreando as modificações DDL: Criando logs para modificações do seu schema Oracle

Valter Zanchetti Filho — Sun, 20 Jul 2025 21:42:37 +0000

Algumas vezes aqui no trabalho, dois desenvolvedores resolveram alterar a mesma package quase ao mesmo tempo. Um deles estava alterando desde o início da tarde e foi compilando no decorrer dessa mesma tarde. O outro abriu o corpo da package para alterar durante a manhã, fez umas alterações no final do dia e compilou à noite. Não existia processo de CI/CD e obviamente um deles perdeu as modificações que tinha feito. Adivinha quem foi o desenvolvedor que perdeu as alterações? Eu.

Para não passar mais por isso, uma abordagem simples que resolvemos adotar foi a criação de uma trigger que audita todas as modificações feitas no schema do banco e grava numa tabela. Assim, temos bastante controle de alteração e autonomia, sem precisar depender do DBA para restaurar versões anteriores. Outra vantagem, foi o fato de que fica bem fácil de ver quem fez as alterações nos objetos e nos traz uma forma fácil de acompanhar cada alteração no código ou estrutura do schema.

Esse método descrito abaixo foi testado na versão 19c do Oracle Database Standard Edition e os comendos devem ser executados com o próprio OWNER do SCHEMA que você quer auditar.


  CREATE TABLE DDL_LOG
       ("DDL_LOG_ID" NUMBER, 
        "DDL_OPERATION" VARCHAR2(30 BYTE), 
        "OBJECT_TYPE" VARCHAR2(30 BYTE), 
        "OBJECT_NAME" VARCHAR2(128 BYTE), 
        "APP_USER_NAME" VARCHAR2(30 BYTE), 
        "EVENT_TIMESTAMP" TIMESTAMP (6) DEFAULT CURRENT_TIMESTAMP, 
        "DDL_SQL_TEXT" CLOB, 
        "DDL_SQL_TEXT_2" CLOB,
        "CLIENT_IP_ADDRESS" VARCHAR2(150 BYTE), 
        "OBJECT_OWNER" VARCHAR2(30 BYTE), 
        "DB_USER_NAME" VARCHAR2(30 BYTE), 
        "OS_USER_NAME" VARCHAR2(50 BYTE), 
        "CLIENT_HOST_NAME" VARCHAR2(50 BYTE), 
        "NOTES" VARCHAR2(4000 BYTE), 
         CONSTRAINT "DDL_LOG_PK" PRIMARY KEY ("DDL_LOG_ID") ) ;
/

CREATE SEQUENCE SEQ_DDL_LOG_ID
   START WITH 1
   INCREMENT BY 1
   NOCACHE
   NOCYCLE;
/

--Se este trecho não rodar quando for inserir via navegador, pode passar via EXECUTE IMMEDIATE, já que não tem como colocar DEFINE OFF no APEX
  CREATE OR REPLACE EDITIONABLE TRIGGER TRG_DDL_LOG_SEQ
BEFORE INSERT ON DDL_LOG FOR EACH ROW 
BEGIN
  BEGIN
    IF INSERTING AND :NEW.DDL_LOG_ID IS NULL THEN
      SELECT SEQ_DDL_LOG_ID.NEXTVAL INTO :NEW.DDL_LOG_ID FROM SYS.DUAL;
    END IF;
  END COLUMN_SEQUENCES;
END;
/
ALTER TRIGGER TRG_DDL_LOG_SEQ ENABLE;
/

Agora você deve criar o trigger que irá fazer a auditoria. Lembre-se de utilizar o OWNER do SCHEMA que você pretende auditar.

create or replace TRIGGER ddl_audit_trigger AFTER
CREATE OR ALTER OR DROP ON SCHEMA

DECLARE
  v_sql_text  CLOB;
  v_text_item ora_name_list_t;

BEGIN

--TRATA A FORMA QUE O DDL SERÁ SALVO NO BLOB
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform, 'SQLTERMINATOR', TRUE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform, 'PRETTY', TRUE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform, 'SEGMENT_ATTRIBUTES', FALSE);
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform, 'STORAGE', FALSE);      
DBMS_METADATA.set_transform_param (DBMS_METADATA.session_transform, 'EMIT_SCHEMA', FALSE);



-- Captura o SQL executado (DDL real)
  v_sql_text := NULL;
  FOR i IN 1 .. ora_sql_txt(v_text_item) LOOP
    v_sql_text := v_sql_text || v_text_item(i);
  END LOOP;


-- Desconsidera as mudanças feitas nos próprios objetos relacionados a auditoria
        IF ora_dict_obj_name IN ('DDL_LOG', 'DDL_AUDIT_TRIGGER') THEN 
            NULL;
            RETURN;

        ELSE

            INSERT INTO ddl_log (ddl_operation,                     
                                 object_type,
                                 object_name,
                                 app_user_name,          
                                 ddl_sql_text,
                                 ddl_sql_text_2,
                                 client_ip_address,
                                 db_user_name,
                                 object_owner,              
                                 os_user_name,
                                 client_host_name
                                )    
            VALUES              (ora_sysevent,
                                 REPLACE(ora_dict_obj_type, ' ', '_'),
                                 ora_dict_obj_name,
                                 NVL(V('APP_USER') ,SYS_CONTEXT('USERENV','CURRENT_USER')),
                                 dbms_metadata.get_ddl(REPLACE(UPPER(ora_dict_obj_type), ' ', '_'), UPPER(ora_dict_obj_name)),
                                 v_sql_text,
                                SYS_CONTEXT('USERENV', 'IP_ADDRESS'),   
                                ora_login_user,
                                ora_dict_obj_owner, 
                                SYS_CONTEXT('USERENV', 'OS_USER'),  
                                SYS_CONTEXT('USERENV', 'HOST')             
            );
        END IF;
EXCEPTION WHEN OTHERS THEN
      NULL; --Não disparar erro, apenas ignorar. Criar rotina de log de erro.
      RETURN;
END;
/

Agora cada vez que modificar tabela ou outros objetos, o comando será salvo na tabela DDL_LOG, conforme demonstrado abaixo.

Existem outras soluções para isso, porém, essa foi a solução mais prática que encontrei sem depender do DBA. Se tiver sugestões de melhoria, fique a vontade para comentar.

Alturas Iguais em Regiões Lado a Lado no Oracle APEX: A Solução Simples com u-flex

Valter Zanchetti Filho — Wed, 09 Jul 2025 16:45:24 +0000

Você já se deparou com regiões lado a lado no Oracle APEX que têm alturas diferentes? Esse desnível visual pode deixar sua aplicação com um aspecto desalinhado e pouco profissional — especialmente quando temos várias regiões exibidas em conjunto.

Passei por isso algumas vezes e, por ser algo aparentemente simples, fui perguntar para colegas mais experientes. A resposta foi quase sempre a mesma: "tem que usar um misto de JavaScript e CSS, não dá só com CSS puro". Isso me incomodou, porque parecia uma solução complicada para um problema pequeno. Pesquisando um pouco mais, descobri o que o que precisava ser feito e vou compartilhar como fazer neste post.

Quando criamos duas regiões lado a lado com conteúdos de tamanhos verticais diferentes, o resultado pode ser como este:

Veja que existe uma diferença de tamanho entre um e outro, destacado com as setas vermelhas A diferença de altura pode causar uma quebra de harmonia visual na interface. Dependendo do layout da página, isso pode comprometer a experiência do usuário.

A solução é mais simples do que parece, e você pode aplicá-la sem precisar inspecionar elementos e inventar gambiarras.

Basta usar duas classes do Universal Theme:

Na propriedade "Column CSS Classes" da região: adicione u-flex
Na propriedade "CSS Classes" da região (Appearance): adicione u-flex-grow-1

Essas classes utilizam o poder do Flexbox para garantir que as regiões cresçam proporcionalmente e se ajustem à mesma altura, mesmo com conteúdos diferentes. Deixei esse screenshot aqui para mostrar onde foram aplicadas.

Isso garante que as regiões cresçam igualmente, mantendo a altura simétrica mesmo com conteúdos de tamanhos diferentes.

Exemplo:

Com u-flex e u-flex-grow-1 (abaixo): altura uniforme e layout mais equilibrado.

Experimente esse pequeno ajuste e veja a diferença que faz na apresentação da sua aplicação Oracle APEX!

Fonte:

https://apex.oracle.com/pls/apex/r/apex_pm/ut/layout-modifiers`

Adicionando um certificado cliente em uma wallet Oracle

Valter Zanchetti Filho — Tue, 24 Jun 2025 16:56:17 +0000

Alguns bancos brasileiros como Santander e Itaú exigem um certificado digital de cliente na hora de chamar suas APIs REST. Fazer isso diretamente via Oracle isso é um pouco irritante, visto que exige a criação de uma wallet específica para poder chamar esses serviços via MAKE_REST_REQUEST. Por isso, muita gente desiste e acabar fazendo as chamadas através de aplicações intermediárias. Neste artigo vamos abordar como fazer essas conexões REST diretamente via banco de dados com o MAKE_REST_REQUEST do APEX.

Para criar a wallet você precisa ter um Oracle Client versão full instalado, já que precisaremos do orapki. Não adianta ter o Instant Client. Ele também vem incluso nas versões do Oracle Database. Na minha opinião, não vale a pena baixar e instalar o cliente full ou banco de dados completo quando queremos apenas utilizar o OraPKI, mas isso fica a seu critério.

Você consegue saber um pouco mais sobre como usar o orapki sem precisar baixar o Full Cliente neste meu artigo aqui:

Creating and Configuring Wallets with OraPKI (Without Needing the Full Oracle Client)

A partir daqui você já precisa ter acesso ao orapki.

A primeira coisa que você precisa fazer, caso ainda não tenha uma wallet é criar uma. Para criar pode rodar o comando abaixo, substituindo a pasta por uma pasta de sua escolha:

orapki wallet create -wallet "C:\Users\valter\Downloads\adu" -pwd 123456xx

Após executar este comando você irá ver que ele gerou a wallet no seu sistema operacional, conforme demonstrado abaixo.

Depois disso, você vai começar importando o certificado do cliente com o comando abaixo. Primeiro o diretório onde fica a carteira e depois o difetório onde fica o .pfx do certificado do cliente e a senha do certificado de cliente:

orapki wallet import_pkcs12 -wallet "C:\Users\valter\Downloads\adu" -pwd 123456xx -pkcs12file "C:\Users\valter\OneDrive\Desktop\certificado_a_importar\user_cert.pfx" -pkcs12pwd 123456

Após executar você deverá receber essa mensagem de sucesso:

orapki command import_pkcs12 executed successfully.

Normalmente, você também precisará adicionar os certificados dos servidores do serviço no qual você quer conectar na parte dos certificados confiáveis da wallet

orapki wallet add -wallet "C:\Users\valter\Downloads\adu" -trusted_cert -cert "G:\Meu Drive\Aplicativos\OraPKI\certs\ICP-BR\AC_VALID_RFB_v5.crt" -pwd 123456xx

Você consegue verificar agora todo o conteúdo da sua wallet com este compando:

orapki wallet display -wallet "C:\Users\valter\Downloads\adu" -pwd 123456xx

Deverá mostrar os certificados de cliente e os certificados confiáveis como na tela abaixo:

Agora você precisa fazer o upload dessa wallet para algum diretório acessível pelo seu banco de dados. No meu exemplo, 'file:/opt/oracle/wallets/adu/'. Em alguns testes precisei colocar uma / no final e em outros não foi necessário. Testei em duas bases diferentes. Comece tentando sem a / no final do nome da wallet, deve funcionar.

Devemos adicionar os privilégios para os owners solicitados com SYS ou ADMIN. Segue abaixo o comando utilizado para atribuir os privilégios. Lembre de substituir YOUR_OWNER pelo nome do seu owner e APEX_230200 para a versão do seu banco

BEGIN

-- APEX
 DBMS_NETWORK_ACL_ADMIN.APPEND_WALLET_ACE(       
  wallet_path => 'file:/opt/oracle/wallets/adu/',
  ace     => xs$ace_type(
           privilege_list => xs$name_list('use_client_certificates', 'use_passwords'),
           principal_name => 'APEX_230200',
           principal_type => xs_acl.ptype_db
          )

 );

-- OWNER
DBMS_NETWORK_ACL_ADMIN.APPEND_WALLET_ACE(       
  wallet_path => 'file:/opt/oracle/wallets/adu/',
  ace     => xs$ace_type(
           privilege_list => xs$name_list('use_client_certificates', 'use_passwords'),
           principal_name => 'YOUR_OWNER',
           principal_type => xs_acl.ptype_db
          )
 );

end;

Daqui pra frente é sua apontar a wallet na hora de chamar o serviço via MAKE_REST_REQUEST.

Criação e configuração de wallets com OraPKI (sem precisar do Oracle Client Full)

Valter Zanchetti Filho — Tue, 24 Jun 2025 16:45:21 +0000

Já faz algum tempo que tenho precisado lidar com wallets no banco de dados sem ter acesso ao SSH. Por isso, para utilizar o mkstore ou orapki localmente, tinha duas opções mais comuns: baixar uma versão do banco de dados e instalar numa VM ou na máquina local ou então baixar e instalar um full client, que para mim, não estava sendo necessário para nenhuma outra atividade além dessa. Eu queria encontrar uma forma mais prática e acessível, em que eu pudesse colocar o orapki no meu Google Drive e utilizar do PC do trabalho, do pc de casa e do laptop.

Depois de alguma pesquisa na web, encontrei esses dois artigos que explicam como utilizar os arquivos .jar do SQLcl para rodar o orapki sem precisar baixar e instalar o client full.

https://ogobrecht.com/posts/2020-07-29-how-to-use-mkstore-and-orapki-with-oracle-instant-client/

https://andriydmytrenko.wordpress.com/2013/07/01/using-the-secure-external-password-store-with-instant-client/

Vamos seguir esses passos.

Baixar o SQLcl (a ferramenta mais leve da Oracle que encontrei que possui os .jar do orapki).
Descompactar em alguma pasta da sua preferência
Criar um arquivo orapki.bat, que deve ter o conteúdo abaixo.

@echo off
rem inspiration: https://andriydmytrenko.wordpress.com/2013/07/01/using-the-secure-external-password-store-with-instant-client/

setlocal

rem get the command line arguments
set args=
:loop
  if !%1==! goto :done
  set args=%args% %1
  shift
  goto :loop
:done

rem set classpath for orapki - align this to your local SQLcl installation
set sqlcl="G:\Meu Drive\Aplicativos\SQLcl\25.1.0.101.2353\lib"
set classpath=%sqlcl%\oraclepki.jar
set classpath=%classpath%;%sqlcl%\osdt_core.jar
set classpath=%classpath%;%sqlcl%\osdt_cert.jar

rem simulate orapki command
java -classpath %classpath% oracle.security.pki.textui.OraclePKITextUI %args%

endlocal

Substitua a linha set sqlcl="G:\Meu Drive\Aplicativos\SQLcl\25.1.0.101.2353\lib" pelo diretório onde está seu SQLcl.

Pronto! Pode usar o orapki agora sem ter que baixar e instalar o client completo.

Nota: Se quiser user no MacOS ou Linux, pode fazer os arquivos assim:

mkstore:

#!/bin/bash
# set classpath for mkstore - align this to your local SQLcl installation
SQLCL=$(dirname $(which sql))/../lib
CLASSPATH=${SQLCL}/oraclepki.jar:${SQLCL}/osdt_core.jar:${SQLCL}/osdt_cert.jar
# simulate mkstore command
java -classpath ${CLASSPATH} oracle.security.pki.OracleSecretStoreTextUI  "$@"

orapki:

#!/bin/bash
# set classpath for orapki - align this to your local SQLcl installation
SQLCL=$(dirname $(which sql))/../lib
CLASSPATH=${SQLCL}/oraclepki.jar:${SQLCL}/osdt_core.jar:${SQLCL}/osdt_cert.jar
# simulate orapki command
java -cl

Acessando uma instância Oracle Autonomous Database na OCI utilizando o PLSQL Developer

Valter Zanchetti Filho — Tue, 24 Jun 2025 16:23:09 +0000

Geralmente quem utiliza o PLSQL Developer já está na estrada Oracle há bastante tempo. Estamos acostumados a configurar os TNSNAMES para acessar nossas bases de dados On Premise até com uma das mãos atadas, porém, quando nos deparamos pela primeira vez com a Autonomous Database, vemos que o caminho para conectar é um pouco diferente. Este tópico vai abordar a forma mais prática de fazer login na sua Autonomous Database com o PLSQL Developer. Para isso, você deve acessar a instância na OCI.

No console da OCI, no menu Autonomous Database, você deve clicar na database que você tem interesse em se conectar.

Clicar em database connections

Você deve baixar a sua wallet da instância em download wallet. Irá trazer sua wallet em .zip

A partir daqui temos três opções:

Opção A - Você extrai o ZIP numa pasta separada e manda o PLSQL Developer ler nessa pasta.

A mais prática de todas. Você cria uma pasta com o nome que você quiser [exemplo: my_plsql_wallet]. Dentro dela, cria outra pasta chamada network. Dentro de network cria uma pasta chamada admin.

No exemplo, ficaria assim: C:\my_plsql_wallet\network\admin. Coloque o conteúdo extraido da wallet na pasta admin. Dentro da pasta admin deve ver os arquivos abaixo.

Aponte o caminho aponte o caminho da pasta mãe no PLSQL Developer. [Exemplo: C:\my_plsql_wallet]

Opção B - Você extrai e adiciona as entradas no TNSNAMES e SQLNET.ORA [Caso queira manter as conexões que você já possui e tenha apenas uma conexão ativa na Autonomous Database]

Neste caso, você vai procurar na sua máquina o seu arquivo TNSNAMES (supondo que você já tenha um Oracle Client instalado) e adicionar as entradas que estão dentro do TNS_NAMES da wallet.

No arquivo SQLNET.ORA, você vai adicionar a seguinte entrada:

WALLET_LOCATION = (SOURCE = (METHOD = file) (METHOD_DATA = (DIRECTORY="?/network/admin"))) SSL_SERVER_DN_MATCH=yes

Opção C - Você extrai, adiciona as entradas e modifica o TNSNAMES indicando o caminho da wallet. [A mais trabalhosa e útil se você quer trabalhar com mais de uma instância na Autonomous Database]

Lembre de fazer um backup antes de qualquer coisa. Primeiro você irá limpar do SQLNET.ORA tudo o que tiver relação com wallet. Você vai extrair a wallet numa pasta com o nome que você quiser [exemplo: my_plsql_wallet].

Você vai adicionar a entrada no seu TNSNAMES, e modificar a parte que se refere a wallet, modificando a parte de apontamento de wallet em security como no exemplo abaixo:

dbtest_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=adb.sa-saopaulo-1.oraclecloud.com))(connect_data=(service_name=exampleservice_high.adb.oraclecloud.com))(SECURITY =(MY_WALLET_DIRECTORY = C:\my_plsql_wallet)(SSL_VERSION = 1.2)(SSL_CLIENT_AUTHENTICATION = FALSE))))

IMPORTANTE: A partir do Oracle 23ai, o MY_WALLET_DIRECTORY foi substituído por WALLET_LOCATION.

Referências:

https://blog.bar-solutions.com/?p=954

https://forums.oracle.com/ords/apexds/post/one-client-needing-multiple-wallets-and-or-multiple-sqlnet-6227

https://docs.oracle.com/en/database/oracle/oracle-database/23/netrf/local-naming-parameters-in-tns-ora-file.html#GUID-E48103F6-8B8B-457C-9374-695C7CCAD816