Automatizando IMPORT de Bases

Olá Pessoal!

No primeiro post que fiz em Abril/2010, comentei sobre a implementação de um processo "automatizado" de IMPORT de bases de dados. Porém, não detalhei o processo.

Então, para dividir o conhecimento com vocês, resolvi descrever em detalhes o processo.

A receita é simples. Basicamente, consiste das seguintes tarefas:

1. Bloquear a conta do usuário/esquema;
2. Desconectar sessões ativas/inativas do usuário;
3. Dropar o usuário;
4. Importar os dados.

Detalhando:

Lembrando que, o processo foi desenvolvido utilizando comandos do sistema operacional Windows e scripts para serem executados via SQLPLUS (DBA que é DBA utiliza SQLPLUS ... hehehe).

- Bloquear a conta do usuário a ser carregado E desconectar sessões ativas/inativas do usuário: neste script juntei as atividades de bloqueio da conta do usuário e montagem dinâmica dos KILL SESSIONs das sessões do usuário no BD. O usuário deve ser bloqueado de maneira a evitar novas conexões e suas sessões derrubadas para poder ser dropado. Segue abaixo, um modelo deste script. O script gera log de todas as operações executadas sobre o banco. Aliás, nunca devemos esquecer de gerar log de TUDO, absolutamente TUDO que é executado no BD - é uma boa prática, demonstra profissionalismo e ajuda na identificação de possíveis problemas - mesmo que seja em ambiente de homologação. Resumindo, proteja-se SEMPRE.

killsessionUSUARIO.SQL
SET ECHO OFF
SET HEADING OFF
SET FEEDBACK OFF
CONN sys/****@instancia as sysdba
SPOOL c:\cargas_automaticas\killsessionUSUARIO_2.sql

SELECT 'SPOOL c:\cargas_automaticas\killsessionUSUARIO_2.log' FROM DUAL;
SELECT 'ALTER USER USUARIO ACCOUNT LOCK;' FROM DUAL;
SELECT 'alter system kill session '||chr(39)||sid||','||serial#||chr(39)||';' FROM v$session WHERE username='USUARIO';
SELECT 'SPOOL OFF' FROM DUAL;

SPOOL OFF
SET HEADING ON
SET FEEDBACK ON
SET ECHO ON
@c:\cargas_automaticas\killsessionUSUARIO_2.sql
EXIT

- Dropar o usuário: realizada as operações do passo 1 e 2, as etapas seguintes são dropar o usuário e recriá-lo. Também juntei essas operações em um único script. Segue abaixo o modelo do script para estas tarefas.

recria_USUARIO.sql

SET ECHO on

spool c:\cargas_automaticas\recria_USUARIO.log
conn sys/****@instancia as sysdba
drop user USUARIO cascade;
create user USUARIO identified by senha
default tablespace TBS_USUARIO temporary tablespace TBS_TEMP account unlock;
alter user USUARIO quota unlimited on TBS_USUARIO;

grant create session, alter session, create cluster,
create sequence, create synonym, create table, create view, create indextype,
create procedure,create trigger,create type to USUARIO;

SPOOL off
SET ECHO off
EXIT

- Importar os dados para o usuário: concluída toda a preparação do usuário para receber o conteúdo do DUMP o próximo passo é executar a importação propriamente dita. Para executar as atividades automaticamente, desenvolvi um script que executa todos os passos acima citados concluindo com o comando IMPORT. Abaixo, o script final.

import_USUARIO.cmd

ECHO ********************************

ECHO * Importando INSTANCIA.USUARIO
ECHO ********************************
ECHO *
ECHO * Finalizando sessoes de USUARIO ... Aguarde ...
ECHO *
sqlplus /nolog @c:\cargas_automaticas\killsessionUSUARIO.sql
ECHO *
ECHO *
ECHO * Aguardando 10 minutos para que as conexões terminem antes de dropar o usuário
ECHO *
sleep 600
ECHO *
ECHO * Recriando usuario USUARIO ...
ECHO *
sqlplus /nolog @c:\cargas_automaticas\recria_USUARIO.sql
ECHO *
ECHO * Importando base de dados USUARIO ...
ECHO *
imp sys/****@instancia file=c:\cargas_automaticas\arquivo.dmp fromuser=usuario touser=usuario log=c:\cargas_automaticas\import_usuario.cmd recalculate_statistics=Y
ECHO *
ECHO ********************************

Para minimizar os riscos de alguma sessão conectada ao usuário e conseguir eliminar o usuário/esquema, implementei o comando SLEEP do WINDOWS para "congelar' a sessão do sistema operacional durante 10 minutos. Lembrando que, o aplicativo SLEEP.EXE é instalado com o pacote RESOURCE KIT do WINDOWS.

Até a próxima.

Melhorando a performance de IMPORT/EXPORT

Olá!

Um dos maiores problemas em ambientes de homologação que  necessitam de grandes volumes de cargas de bases de dados para desenvolvimento e testes de usuários (como no meu caso ...) é a dificuldade em obter performance no EXPORT/IMPORT dos dados de forma a disponibilizá-los o mais rápido possível para desenvolvedores e usuários. No decorrer dos anos, com a constante necessidade de carregar tais bases com aquele velho papo de "pra ontem", fui observando alguns ítens que melhoram a performance destas operações.

Vale lembrar que, se você não possue um hardware com uma configuração mínima aceitável, a utilização de determinados parâmetros de IMPORT/EXPORT não terá impactos sobre estas operações.

Abaixo, listei algumas dicas e espero que sejam úteis:

- IMPORT

1. Desabilite a importação de índices: se for possível, desabilite a importação de índices configurando o parâmetro INDEXES=N. Na maioria dos casos, desenvolvedores e usuários, estão interessados nos dados. Desta forma, se você tem uma boa ferramenta como o SQL Developer da Oracle, pode gerar um script que executa a criação dos índices após a carga. Enquanto isso, os dados podem ser acessados durante este processo agilizando a identificação de um problema;
2. Elimine a carga de grandes tabelas durante a importação: na maioria dos casos, bases de desenvolvimento/homologação não necessitam de todas as tabelas da aplicação. Neste caso, evite a carga de tabelas maiores desnecessárias durante o IMPORT. Como? Crie a estrutura de tais tabelas antes da carga e utilize o parâmetro IGNORE=N (lembrando que esta é valor padrão do parâmetro) no import. Isto fará com que o IMPORT gere erro IMP-00015: following statement failed because the object already exists e "saltará" a importação dessas tabelas. Dependendo do tamanho da tabela, o ganho de tempo pode ser significativo;
3. Crie processos de importações automáticas de bases em horários de baixo load do BD: normalmente, os desenvolvimentos/homologações de aplicações são feitos durante o horário normal de trabalho (8h às 18h), salvo em casos específicos onde exista uma necessidade urgente de homologação o que também é raro em qualquer empresa com bom planejamento e organização de seus processos. Uma boa prática é criar processos de carga, através de scripts e jobs do WINDOWS ou do próprio ORACLE para realizar automaticamente estes trabalhos. Obviamente, os jobs devem ser agendados para os horários de menor load do banco. Uma boa sugestão de horário é durante a madrugada, pois raramente se trabalha neste horário. A não ser que você seja um DBA ... hehehe ... brincadeira gente ... Se o fluxo de homologações e demanda por bases de dados é muito alto, vale a pena investir tempo na implementação de um processo com esta finalidade;
4. Aumente o tamanho dos arquivos de redolog e parâmetros de sort: por se tratar de uma operação com características de processos BATCH, o aumento de tamanho dos redologs e dos parâmetros de SORT (sort_area_size e sort_area_retained_size) podem dar um plus na performance do IMPORT. Já tive ganhos consideráveis utilizando o padrão 10 grupos de redologs com tamanho de 100Mb cada. Mas é claro, você tem que adequar a configuração de acordo com o seu BD. Para parâmetros de SORT, utilize valores maiores. Uma configuração razoável é 2Mb para os 2;
5. Evite operações de IMPORT/EXPORT no modo shared server: utilize SEMPRE conexões dedicadas para tais operações.

- EXPORT

Para estas operações, são poucas as dicas:

1. Utilize o parâmetro DIRECT=Y: isto faz com que o ORACLE ultrapasse a camada de processamento de comandos SQL. Isto reduz bastante o tempo do EXPORT;
2. Evite o parâmetro FEEDBACK: a configuração deste parâmetro, exige consumo de processamento da máquina para exibição dos resultados em tela.

Pessoal, essas são algumas dicas que achei interessante compartilhar com vocês. Espero que as utilizem em alguma eventual necessidade.

Até a próxima.