Arquivo da tag: database

Oracle 11G IMPDP – TRANSFORM – Caso Compress

Olá PessoAll,

Não sei se todos conheciam isso, eu particularmente nunca tinha usado, resolvi compartilhar.

Eu precisava fazer um import de um owner que atualmente está em tablespace normal, e tem suas tabelas normais para que ele fosse importado em uma outra tablespace e já comprimido (COMPRESS).

Fiz o export normalmente, sem nenhum segredo. Na hora do import que seriam realizadas as mudanças.

No import, a primeira coisa é que eu precisava era colocar as tabelas e índices numa nova tablespace. Para isso, usei o REMAP_TABLESPACE, até aí sem nenhum segredo.

Porém, como faria para que as tabelas fossem criadas comprimidas?

O atributo de COMPRESS, geralmente usado nas tabelas não tinha como ser mudado na hora do import.

As alternativas eram:

1 – Importar assim mesmo e fazer um Redefinition depois.

2 – Fazer o import com METADATA_ONLY e mudar as tabelas para COMPRESS, só que desse jeito os índices vão junto e na hora do import com os dados (DATA_ONLY) vai demora muito mais, estoura UNDO etc.

3 – Gerar o script de criação das tabelas, uma por uma, e criar manualmente apenas a tabela na nova tablespace e com COMPRESS e só depois soltar o IMPDP.

 

Baseado nas possibilidades pensadas… A alternativa mais interessante e que resolvia era a 3, mas ia dar um trabalho enorme…. uma a uma, criar na mão…. muito trabalho!

Um dos dons (se bem usado) do ser humano é a “preguiça produtiva”, e usei deste dom… em vez de fazer assim, saí pesquisando.

Nas buscas, descobri então que o atributo de COMPRESS pode ser como default na tablespace… Aí sim… só criar a tablespace e informar a cláusula: “…default compress for oltp”, e toda tabela criada na tablespace que não informar nada sobre compressão, será assumida a compressão da tablespace! Aêêêê!!! Resolveu!  \o/

Só que não!

Fiz o import, e ao verificar as tabelas, todas estavam sem compressão! Mesmo a tablespace estando com o default COMPRESSION FOR OLTP.

Dica: Se você tem dúvida de como verifica isso na tabela, assim é possível: select table_name, compression, compress_for from dba_tables where owner='SEU_OWNER_AQUI'

Quebrou meu esquema!

Lá vem a preguiça voltando novamente e lá vou eu pesquisar novamente.

Gastei mais um tempo de pesquisa e descobri o porquê das tabelas não obedecerem ao default da tablespace, lembram quando falei lá em cima: “e toda tabela criada na tablespace que não informar nada sobre compressão”, pois é…. SE não informar nada! Só que quando o expdp é feito, o script gerado de criação da tabela vem com o atributo NOCOMPRESS, porque no banco de origem a tabela de fato não era comprimida, na hora do import a tabela era criada com o atributo original contido no script, NOCOMPRESS!

Voltamos então para a solução 3, gerando o script dos create table, mudando o script de cada uma das tabelas e criando todas as tabelas manualmente, com COMPRESS… mas minha preguiça produtiva é resistente e resiliente… pesquisei mais um pouco, para fazer de forma mais inteligente… e achei o tal atributo TRANSFORM do IMPDP!

Vamos lá… no IMPDP, com o TRANSFORM, você pode exatamente mudar atributos dos objetos a serem criados na hora do IMPDP, ficando diferente do que foi gerado no banco de origem.

Para o meu caso, eu precisava apenas remover o tal NOCOMPRESS do script de criação, e dizer para o banco que as tabelas deveriam ir para uma tablespace nova, isso é possível adicionando as seguintes clausulas, combinadas, no meu comando de IMPDP:

...transform=segment_attributes:n remap_tablespace=TBS_OLD:TBS_NEW_COMPRESS...

Desta forma, os atributos do segmento que estavam no banco antigo (e no script do IMPDP) não serão utilizados, fazendo com que o default da nova tablespace seja usado.

E a preguiça vence novamente!! Tabelas criadas com COMPRESS FOR OLTP e import rolando.

Espero que seja útil para vocês.

Podemos usar isso, por exemplo, nos refresh de bases que fazemos com EXPDP/IMPDP, devemos economizar uma área razoável nas bases de desenvolvimento e homologação com esse método.

É uma ideia!

As notas que encontrei nas pesquisas foram:

Internet:

http://www.dba-oracle.com/t_impdp_transform_segment_attributes.htm

https://docs.oracle.com/cd/E11882_01/server.112/e22490/dp_import.htm#SUTIL939

Metalink:

How To Import The Non-Compressed Tables Into A Compressed Tablespace And Obtain Compress Target Tables? (Doc ID 2174751.1)

E….. só para constar, vi que no 12c, tem muito mais atributos que poderão ser usados com o TRANSFORM, como pode exemplo, não precisar ter default da tablespace, no próprio comando de IMPDP poderemos substituir o valor dos parâmetros, por exemplo, trocar o NOCOMPRESS por COMPRESS FOR OLTP, vejam mais detalhes aqui:

https://docs.oracle.com/database/121/SUTIL/GUID-64FB67BD-EB67-4F50-A4D2-5D34518E6BDB.htm#SUTIL939

 

É isso gente.

Espero ter ajudado!

 

Abraços!

Utilizando Compartilhamento Windows no Linux

Fala PessoAll,

Bom, hoje tivemos mais um desafio bem interessante.

Recebemos um dump de um determinado cliente, o arquivo de dump (X.dmp) veio com 260Gb em um único arquivo. Infelizmente, na máquina Linux onde a base está instalada não tinha nenhum disco com esta quantidade de espaço livre. E agora pra importar esse dump??

Vasculhamos nossos servidores e achamos um servidor com mais de 260Gb livre, dando sopa! Que beleza, problema resolvido!

Idéia 1: Descompactamos os 260Gb neste servidor e a partir dele fazemos o import na máquina destino, tudo certo! NÃO! Este servidor roda Oracle 10G e o servidor de destino roda Oracle 9i, não funciona! Que falta de sorte!

Idéia 2: Descompactamos neste servidor e através da rede, criamos um mapeamento da máquina onde será importado, para esta máquina que tem espaço sobrando e tudo certo! Ok? NÃO de novo. O servidor que tem esse espaço é um Windows 2003 Server, e a máquina onde a base está rodando e o dump teria que ser importada, estava rodando Linux… Red Hat Enterprise.

Mas… porque não? Será que não tem como fazer? Pesquisando na internet achei alguns sites que explicavam como fazer e aí decidi testar. E, para alegrar ainda mais minha sexta-feira, funcionou beleza! Como se fosse uma pasta na máquina Linux.

Segue o passo a passo:


Inicialmente deve-se verificar os compartilhamentos disponíveis na máquina destino
[oracle@oracle9i oracle]$ smbclient -L 192.168.0.13 -U oracle
Password:
Sharename Type Comment
--------- ---- -------
IPC$ IPC IPC remoto
D$ Disk Recurso compartilhado padrão
RV Disk
SQLLDR Disk
ADMIN$ Disk Administração remota
C$ Disk Recurso compartilhado padrão

Em seguida deve-se conectar como SU
[oracle@oracle9i oracle]$ su -
Password:

Depois deve ser criada a pasta que irá exibir os dados do compartilhamento
[root@oracle9i root]# mkdir /mnt/Dump

Depois deve ser executado o commando que efetivamente vai criar o link
[root@oracle9i root]# mount -t smbfs -o username=oracle,password=oracle01 //192.168.0.13/SQLLDR /mnt/Dump

Depois disso já podemos listar o conteúdo da pasta, que já será exibido o conteúdo do mapeamento em questão
[root@oracle9i root]# ls /mnt/Dump
IN

É isso!

Espero que seja útil também pra vocês!

Grande abraço.

Atc.
Gerson Júnior
gerson.vasconcelos@gmail.com