Arquivo de Outubro, 2012

Fala moçada tudo bem ?
Hoje a dica é sobre uma ferramenta “mao-na-roda” que nos ajuda muito quando precisamos migrar uma carga de dados de um schema para outro (tanto faz no mesmo banco ou outro banco de dados oracle) sem gerar um arquivo de dump.

Este é o caso do tradicional utilitario  IMP/EXP que muitos DBA utilizam no dia a dia para atulizar bases de testes e migrar dados. Nele, sempre apos o EXP teremos um arquivo de dump que sera usado na futura importacao. Agora imagine a seguinte situação: Voce esta migrando um banco de dados e o arquivo de dump gerado tera uma quantidade de GB que o sistema operacional não tem disponivel, e voce nao tem nenhum outro terminal para gerar este arrquivo, e agora hein?

Ai que entra nosso amigo DATAPUMP com a feature usando database link. A idéia aqui é realizar a exportacao e importacao dos dados sem gerar o arquivo de dump, aplicando diretamente no schema alvo. E como fazemos isso ? Mãos a obra

Entrada no TNSNAMES dentro do banco de dados alvo B apontando para o banco de dados de origem A:

bancoA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = ip_bancoA)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = orcl)
)
)

No banco de dados alvo B,  criar um diretorio que será usado pelo datapump:

CREATE DIRECTORY dump AS ‘/standby/dump/’;

GRANT read, write ON DIRECTORY dump TO PUBLIC;

OBS:o diretorio “/standy/dump” deverá ser trocado por um válido dentro do file system.

No banco de dados alvo B, vamos garantir que o novo usuario tenha o privilegio para criar um database link:

GRANT CREATE DATABASE LINK TO NEW_USER;

No banco de dados alvo B, logar pelo SQLPLUS no usuario NEW_USER, e criar database link:

CREATE DATABASE LINK migracao CONNECT TO teste IDENTIFIED BY teste USING ‘bancoA’;

Obs: bancoA é a entrada dentro do tnsnames

No servidor de banco de dados que recebe o import (banco de dados alvo B)

impdp NEW_USER/NEW_USER network_link=migracao directory=dump logfile=imp_NEW_USER.txt remap_schema=TESTE:NEW_USER

Pronto, neste momento os objetos do schema TESTE no banco de dados de origem A estao sendo copiados para o banco de dados alvo B dentro do schema NEW_USER sem gerar nenhum arquivo de dump dentro do file system. Com isso, ganhamos tempo nmigracao.

Uma caracteristica bem legal do datapump é que se voce fechar o Putty ou SSH o processo de importacao continuará em background.

Um otima leitura também é o artigo no meu amigo Bruno Murassaki, onde ele como sempre traz todos detalhes do datapump abordando de maneira muito didatica o processo de remapeamento de objetos e tablespaces usando datampump.

http://profissionaloracle.com.br/blogs/brunomurassaki/2009/04/06/datapump-remapeando-schemas/

Então é isso, espero que tenha ajudado com mais essa dica e que nas proximas migracoes voce economize tempo usando o datapump.

Um abraco.

Olá pessoal, tudo bom ?

Hoje vou postar uma situação que aconteceu durante um atendimento a um cliente durante uma restauração do backup RMAN, isso mesmo, não basta ter backup, o que vale mesmo é um restore válido como dizia meu amigo Bruno Murassaki.

Logo após a resutaração, banco de dados quase pronto para ser liberado para o cliente fui verificar o alert.log como parte da rotina. E para minha surpresa, várias entradas apontando para possiveis problemas de archivamento.

Errors in file /oracle/app/oracle/diag/rdbms/target/trace/target_arc2_7645.trc;
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 939 change 83047523485 time 09/12/2012 22:33:54
ORA-00312: online log 15 thread 1: ‘+DATA/target/onlinelog/group_15.278.793109619’
ARC2: All Archive destinations made inactive due to error 354
ARC2: Clossing local archive destination LOG_ARCHIVE_DEST1: ‘/oracle/app/oracle/product/11gR2/dbs/arch1_451_793109613.dbf”  (error 354)  (target)
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance test1 – Archival Error

A partir do alert.log, temos que o o grupo de redo log 15 estava marcado como corrompido. Proximo passo foi verificar o status do grupo de redo log 15 na v$log, e lá encontramos o grupo como INACTIVE e também nao tinha sido realizado o ARCHIVE dele.

GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC STATUS
———- ———- ———- ———- ———- ———- — ————–
5          1      44342   26214400        512          1 NO  CURRENT
6          1      44343   26214400        512          1 YES INACTIVE
7          1      44344   26214400        512          1 YES INACTIVE
8          1      44345   26214400        512          1 YES INACTIVE
9          1      44346   26214400        512          1 YES INACTIVE
10          1      44347   26214400        512          1 YES INACTIVE
11          1      44348   26214400        512          1 YES INACTIVE
12          1      44349   26214400        512          1 YES INACTIVE
13          1      44339   26214400        512          1 YES INACTIVE
14          1      44340   26214400        512          1 YES INACTIVE
        15          1      44341   26214400        512          1 NO  INACTIVE      

Resolução:

SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 15;
Database altered.
Neste mesmo momento no alert.log aparecia
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 15
WARNING! CLEARING REDO LOG WHICH HAS NOT BEEN ARCHIVED. BACKUPS TAKEN
    BEFORE 09/12/2012 22:33:58 (CHANGE 83047525487) CANNOT BE USED FOR RECOVERY.
Clearing online log 15 of thread 1 sequence number 451
Completed: ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 15

Com isso,  banco de dados funcinando normalmente e sem entradas no alert.log.
É importante lembrar também que assim como mostrado no alert.log, os backups realizados antes da alteração 83047525487  nao poderão ser usados para RECOVERY, ou seja, é muito importante que um backup FULL seja realizado imediatante após esta operação.
Um grande abraço e até lá !