Data Pump Export – Nos Bastidores da Grande Peça de Dados

Data Pump Export – Nos Bastidores da Grande Peça de Dados

Imagine um teatro majestoso, com cortinas vermelhas e holofotes brilhantes. O palco está pronto, e os atores, ansiosos para entrar em cena. Bem-vindo à nossa produção estrelada pelo Oracle Data Pump!

O Palco e os Atores

Hoje o banco de dados Oracle é nosso palco. Aqui, os dados desempenham seus papéis, e o Data Pump é o diretor. Os atores principais são:

• expdp: Nosso protagonista. Ele entra em cena para exportar dados e metadados, como um ator habilidoso que interpreta vários papéis.
• impdp: O coadjuvante confiável. Ele assume a responsabilidade de importar dados, trazendo-os à vida no novo ambiente.

Atores Coadjuvantes:

• Data Pump API: O maestro nos bastidores. Ele coordena tudo, desde a automação até as personalizações.
• Metadata API: O figurinista meticuloso. Ele lida com os detalhes dos metadados.

Nossa história começa com a exportação. O público (ou seja, a plateia) aguarda ansiosamente. O Data Pump entra em ação, empacotando os dados como atores ensaiando suas falas. Ele cria um conjunto de arquivos de despejo, como um roteiro bem escrito.

A importação é o clímax. Os atores secundários entram em cena, carregando os dados para o novo cenário. O público aplaude, e o Data Pump sorri, sabendo que sua performance foi impecável.

Está em cartaz hoje neste artigo o modo “Full Mode”. Acomode-se em sua poltrona e aprecie o espetáculo.

Conectado com o usuário SYS, estou verificando os diretórios do meu banco, mas a atuação deste ator deve se resumir somente a isso. O usuário SYS não deve ser usado nas cenas de exportação do Data Pump; não é uma boa prática executar este procedimento com o usuário SYS. 

SELECT DIRECTORY_NAME, DIRECTORY_PATH FROM DBA_DIRECTORIES;

Com esta linda tabela, percebemos duas colunas: a primeira descreve os DIRECTORY_NAME e a segunda, DIRECTORY_PATH, ou seja, o caminho de todos os diretórios do meu banco. O curioso aqui é que o Oracle já tem um diretório específico, que é o DATA_PUMP_DIR. Outra curiosidade é sobre o caminho, que possui esses caracteres e números enormes; isso acontece porque meu ambiente é multitenant.

Neste caso específico, para contribuir e tornar mais didático, vamos criar um novo diretório com o nome de “my_dir”. Para criar este diretório, o caminho precisa existir. Portanto, no nível do sistema operacional, crio o diretório com o comando: mkdir /home/oracle/dumps.

mkdir /home/oracle/dumps

A imagem acima confirma que tudo correu conforme o planejado, e a imagem abaixo só reforça isso quando repetimos a consulta.

SELECT DIRECTORY_NAME, DIRECTORY_PATH FROM DBA_DIRECTORIES;

Agora, com tudo confirmadíssimo, voltamos para o banco usando o usuário SYS dentro do meu PDB.

CREATE DIRECTORY my_dir AS '/home/oracle/dumps';

Acima, visualizamos que retornamos ao banco e estamos conectados com o usuário SYS dentro do PDB. Na sequência, aproveito para criar o diretório “my_dir”. Até me empolguei e dei privilégio aos usuários SYSTEM e DBAOCM; ambos agora têm permissão para ler e escrever no diretório “my_dir”. Este passo é fundamental, pois sem essas permissões, o usuário não consegue gerar o Data Pump.

Vamos aproveitar este momento para explicar os bastidores do espetacular Oracle. Imagine um teatro prestes a estrear uma grande peça. As cortinas se abrem, e os atores entram em cena. Mas, antes que as luzes brilhem, há algo nos bastidores: a Master Table.

A Master Table é como o roteiro da peça. Ela registra cada cena, ator e cenário. Quando o Data Pump entra em ação, a Master Table acompanha o progresso, anotando cada movimento dos dados. Se algo der errado, ela permanece nos bastidores, pronta para ajudar na depuração.

Se algo der errado durante a exportação, a Master Table permanece nos bastidores, garantindo que a operação seja atômica. Ou seja, ela garante que a exportação aconteça por completo ou não aconteça de forma alguma.

Na grande produção do Oracle Data Pump, a Master Table é o segredo para a atomicidade. Ela assegura que nossos dados se movam com precisão, como atores seguindo o roteiro à risca.

Mais um detalhe precisa ser levado em conta neste momento: o usuário SYS, com toda a sua imponência e poder, precisa ser retirado de cena. Isso mesmo, o SYS não é o usuário correto para gerar o Data Pump!

Tendo todos sido relembrados, podemos prosseguir. Vamos para o nosso ‘export’ com o comando: Este comando é o coração de todo este espetáculo; é com base nele que tudo acontecerá, por isso vou detalhar ao máximo possível.

system/senha@orclpdb

FULL=Y

DIRECTORY=my_dir

LOGFILE=log_full.log

DUMPFILE=dump_1_full.dmp

JOB_NAME=my_first_job

• `[expdp]` será realizado pelo usuário ‘system’ dentro do PDB orclpdb.
• `[FULL]` será exportado em sua totalidade.
• `[DIRECTORY]` toda esta exportação será destinada ao diretório ‘my_dir’.
• `[LOGFILE]` recebeu o nome de ‘log_full.log’ e é aqui que registrará informações sobre o processo de exportação, como o status, erros e outras informações úteis relacionadas à exportação.
• `[DUMPFILE]` o parâmetro definiu o nome do arquivo como ‘dump_1_full.dmp’, e é ele que conterá os dados exportados do banco de dados.
• `[JOB_NAME]` esta exportação gerará um arquivo que receberá o nome de ‘my_first_job’.

Respeitado público, todo este espetáculo acontece fora do banco. Abram-se as cortinas!

expdp system/senha@orclpdb FULL=Y DIRECTORY=my_dir LOGFILE=log_full.log DUMPFILE=dump_1_full.dmp JOB_NAME=my_first_job

Que lindo! No palco, estamos presenciando o espetáculo: a exportação do job ‘my_first_job’ conforme especificado no comando/script.

Convido cada um a olhar o que está acontecendo nos bastidores enquanto a exportação do Data Pump acontece. Tão belo quanto o que aparece nos palcos é o bastidor deste espetáculo. Vamos espiar o que está acontecendo por trás das cortinas.

ps aux  grep dw

A imagem acima demonstra os bastidores do espetáculo. Foi possível capturar esta imagem porque a exportação estava em execução no exato momento.

Com este comando, podemos ver que está executando um processo ‘ora_dw00_orcl’, que é o nosso work.

Na sequência, visualizamos nossa Tabela Master trabalhando duro para o espetáculo acontecer lá no palco, quando visualizamos o arquivo ‘ora_dm00_orcl’ em execução.

ps aux  grep dm

Com a exportação em andamento, ainda fora do banco, a nível de sistema operacional.

top

Três letrinhas que dizem muito: com o comando “top”, podemos visualizar quem está consumindo CPU. Sem surpresa alguma, vemos o ‘ora_dw00_orcl’ papando vorazmente os recursos do meu laboratório. Todo este esforço para mostrar que tudo está acontecendo conforme o roteiro.

Aqui cabe uma observação: reparem que existem 2 arquivos à esquerda da tela, ‘dump_1_full.dmp’ e o ‘log_full.log’; estes são os arquivos gerados com esta exportação. Reparem nas imagens anteriores que eles não estavam lá.

Ainda nos bastidores, com a exportação em andamento, ao olhar para o lado, podemos consultar a tabela.

SELECT OWNER_NAME, JOB_NAME, OPERATION, JOB_MODE, STATE FROM DBA_DATAPUMP_JOBS

Ainda nos bastidores, com tudo acontecendo lá no palco, entramos no banco como usuário SYS diretamente no PDB. Ao executar o “SELECT OWNER_NAME, JOB_NAME, OPERATION, JOB_MODE, STATE FROM DBA_DATAPUMP_JOBS;”, visualizamos na coluna:

• OWNER_NAME o dono da tabela,
• JOB_NAME visualizamos o nome do arquivo,  
• OPERATION aponta o tipo da operação,
• STATE aponta que a exportação está a todo vapor.

Com estes dados em mãos, vamos descrever a tabela.

desc system.MY_FIRST_JOB;

Assim, mais uma forma de visualizarmos o status do show, com este ‘DESC’. A imagem acima demonstra apenas uma pequena parte desta descrição, que é bem numerosa na vida real. Tanto é que, na sequência, com um ‘select’ simples, contamos o número de linhas desta descrição.

SELECT COUNT(*) FROM SYSTEM.MY_FIRST_JOB;

Este SELECT simples demonstra que temos 3429 linhas nesta tabela MY_FIRST_JOB, que pertence ao usuário SYSTEM. Caso não tenha reparado na sintaxe do comando para a geração do DATA PUMP, esta é a Tabela Master que recebe os dados durante a exportação. Quando o espetáculo acabar, vamos repetir este comando e confirmar que ela só existe durante a exportação, deixando de existir ao final da mesma.

Fim do espetáculo

Fecham-se as cortinas ao som de aplausos.

Vamos confirmar os comandos passados e visualizar o status do banco após a exportação do Data Pump, começando.

ps aux  grep dw / ps aux  grep dm

A imagem acima demonstra dois comandos e reparem que agora na lista não visualizamos a execução dos arquivos ‘ora_dw00_orcl’ e ‘ora_dm00_orcl’, como demonstrado durante a exportação.

SELECT OWNER_NAME, JOB_NAME, OPERATION, JOB_MODE, STATE FROM DBA_DATAPUMP_JOBS 

vazio

O mesmo SELECT simples que aplicamos anteriormente aqui retorna uma tabela vazia.

desc system.MY_FIRST_JOB; 

does not exist

Como em uma transição de cena para outra, a Tabela Master ‘MY_FIRST_JOB’ simplesmente sumiu, desapareceu, e olha que esta era uma tabela extensa com muitas linhas.

SELECT COUNT(*) FROM SYSTEM.MY_FIRST_JOB; 

does not exist

Aqui não é novidade recebermos este erro, afinal de contas, como contar as linhas de uma tabela que acabamos de ver que não existe mais…

No palco do Oracle Data Pump, cada comando e configuração desempenha um papel crucial na exportação e importação de dados. Enquanto os atores principais, expdp e impdp, brilham, os bastidores são guiados pela Master Table, garantindo a precisão e a atomicidade do processo. Mesmo o poderoso usuário SYS deve ser retirado de cena, deixando espaço para os protagonistas corretos.

Portanto, enquanto as cortinas se fecham e o silêncio toma o lugar dos aplausos, somos deixados com a certeza de que, por trás de cada exportação e importação, há um intrincado balé de comandos, scripts e configurações, todos trabalhando em harmonia para garantir o sucesso do espetáculo de dados. E assim, com os bastidores agora em silêncio, aguardamos ansiosamente pela próxima performance do Oracle Data Pump.

Que o show continue!