Todo time de implantação conhece a cena: chega o dump de um cliente novo e nasce um chamado para o DBA. Criar o PDB, montar as tablespaces, conferir o charset, rodar o impdp, criar o usuário de conexão, devolver a string. Cada import atravessa dois times e anda na velocidade da fila do plantão.
Vivemos exatamente esse cenário com um cliente nosso, uma empresa de tecnologia cujo time de implantação recebe dumps Oracle de clientes com frequência. A resposta foi construir o AutoDump: uma aplicação web que executa o caminho inteiro do import de Data Pump, do download do arquivo ao usuário pronto para conectar, sem nenhuma linha de comando. Neste artigo mostro a ferramenta por dentro e o raciocínio por trás de cada escolha.
Um painel, todos os PDBs
O AutoDump conversa com um Oracle 19c multitenant e trata cada import como um ciclo de vida: o PDB nasce pela aplicação (ou entra na lista um PDB que já existe), recebe o import, ganha usuário de conexão e fica visível no painel com status, schemas importados e ações de gerenciamento. A auditoria recente e o histórico de imports moram na mesma tela: quem fez o quê, e quando, sem caçar log em servidor.
Os dumps moram no Azure? O download é direto
No fluxo manual, o dump chegava por portal, era baixado na máquina de alguém, descompactado e subido para o servidor. O AutoDump corta esses saltos: os containers do Azure Blob Storage são cadastrados na própria tela, com a URL e o SAS do jeito que o portal gera, e o download roda no servidor, direto para o diretório de dumps. Pacotes .zip, .gz, .rar e .7z são descompactados automaticamente.
Dois cuidados de segurança fazem parte do desenho: o SAS precisa apenas das permissões de leitura e listagem, e fica gravado no banco da aplicação, em arquivo 0600 do usuário oracle. Depois de salvo, ele nunca volta para a tela; a interface mostra só o apelido do container e a validade, com renovação em um clique.
Modo Mágico: nome do PDB, dump e mais nada
O modo Mágico é a razão de a ferramenta existir. Quem opera informa o nome do novo PDB (ou escolhe um existente), aponta o dump no servidor, no Azure ou envia da própria máquina, e clica em importar. A aplicação baixa o arquivo, cria o PDB, analisa o dump com impdp SQLFILE, recria as tablespaces encontradas, inclusive as temporárias, e dispara o import.
Cada execução vira uma linha de etapas na tela: Download, PDB, Análise, Tablespaces e Import, com o passo atual sempre visível e a opção de abortar. Os processos rodam no servidor, então fechar o navegador não interrompe nada; o time acompanha de qualquer janela. Um import roda por vez, protegendo o servidor da concorrência, e os demais entram em fila. E cada ação, do login ao cadastro de container, cai na auditoria.
No fim, usuário e TNS prontos
Terminado o import, falta o que costuma gerar mais um chamado: o acesso. O AutoDump fecha o ciclo na mesma tela, com usuários de conexão por PDB em três perfis de acesso (Completo, Somente leitura e DBA) e o bloco do tnsnames.ora pronto para copiar, com host, porta e service name do PDB.
O painel passa a mostrar o PDB com o schema importado e o usuário criado. Daqui em diante o ambiente se sustenta sozinho: quem implantou conecta a aplicação sem depender de ninguém.
Modo Avançado: controle fino para quem é do ramo
Nem todo import é redondo. Para os casos com remapeamento, filtros ou dump sets grandes, o modo Avançado abre um assistente de seis passos: upload do log, criação do PDB, análise e tablespaces, importação, usuário de conexão e conexão final.
O primeiro passo aceita o log do expdp, opcional: a aplicação extrai schemas, tablespaces, tamanhos e parâmetros e pré-preenche o resto do caminho. Sem o log, a análise do próprio dump, via impdp SQLFILE, descobre schemas e tablespaces lendo só metadados, sem importar nada. Durante a análise, o log do impdp aparece ao vivo na tela.
O resultado mostra o character set do dump (com o id), a origem, os schemas descobertos, as tablespaces por schema e as temporárias referenciadas pela cláusula TEMPORARY TABLESPACE do DDL, um detalhe que costuma derrubar import de quem recria tablespace só pelo nome.
Na importação, o operador escolhe os schemas e tem à mão o que o impdp oferece: REMAP_SCHEMA, REMAP_TABLESPACE, PARALLEL, TABLE_EXISTS_ACTION (SKIP por padrão) e parâmetros extras livres, um por linha, como TRANSFORM=DISABLE_ARCHIVE_LOGGING:Y. É o mesmo motor do modo Mágico, com as alavancas expostas.
O que muda para o time
| Etapa | No fluxo manual | Com o AutoDump |
|---|---|---|
| Chegada do dump | Download no desktop, descompactação e upload para o servidor | Direto do container do Azure para o servidor, já descompactado |
| PDB e tablespaces | Criados à mão, adivinhando estruturas pelo log | Criados pela aplicação a partir da análise do dump |
| Import | impdp no terminal, acompanhado por tail no log | Disparado na tela, com etapas, fila e log ao vivo |
| Acesso | Script SQL de usuário e tnsnames montado à mão | Perfis prontos e tnsnames.ora gerado |
| Rastreabilidade | Histórico espalhado em chamados e terminal | Auditoria de cada ação na própria tela |
O efeito prático é a mudança de dono: o import de dump deixou de ser tarefa de DBA e virou rotina do próprio time de implantação, self-service do início ao fim. O DBA entra onde agrega de verdade: no desenho, nas exceções e na evolução da ferramenta.
Automação sob medida é consultoria, não produto de prateleira
O AutoDump não saiu de um catálogo. Nasceu dentro da rotina de um time específico, com as dores dele: dumps no Azure, ambiente 19c multitenant, gente experiente em implantação e sem tempo para virar operador de banco. É por isso que a ferramenta acerta: cada tela espelha um passo que antes era chamado, e cada decisão de segurança, do SAS fora da tela aos perfis de acesso, veio de conversa com quem opera.
Esse é o mesmo raciocínio das nossas frentes de projetos e sustentação: entender o fluxo, automatizar o repetitivo e deixar o especialista onde ele faz diferença.
Perguntas frequentes
O que é o AutoDump?
É uma aplicação web construída pela Furushima para automatizar o import de dumps do Oracle Data Pump em ambiente 19c multitenant: ela cria o PDB, recria as tablespaces a partir da análise do dump, executa o impdp e entrega usuário de conexão e TNS prontos.
De onde a aplicação busca os dumps?
Do próprio servidor, de upload feito pela tela ou de containers do Azure Blob Storage cadastrados com SAS de leitura e listagem. Pacotes .zip, .gz, .rar e .7z são descompactados automaticamente, e o SAS fica guardado no servidor, sem nunca voltar para a tela.
Preciso dominar o Data Pump para usar?
Não. No modo Mágico basta dar o nome do PDB e escolher o dump: análise, tablespaces e import acontecem sozinhos. Quem é do ramo pode usar o modo Avançado, com REMAP_SCHEMA, REMAP_TABLESPACE, PARALLEL, TABLE_EXISTS_ACTION e parâmetros extras do impdp.
A Furushima constrói automações assim para outros cenários?
Sim. O AutoDump nasceu dentro de um projeto de consultoria, desenhado para o fluxo daquele time. Construímos automações sob medida para rotinas de banco de dados, cloud e operação, sempre com auditoria e segurança de acesso no desenho.
O AutoDump virou rotina no time que o encomendou, e o resumo dessa história está na nossa página de cases. Se a sua operação também tem uma rotina repetitiva esperando automação, conheça a frente de projetos e arquitetura de banco de dados e a consultoria de cloud, ou fale direto com um especialista: você descreve o fluxo e sai da conversa com um caminho honesto.