Menu de navegação

[DBA_LUCASParticipante]

Bom dia galera !

Estava importando uma base de dados(SCHEMA) ja havia 1 semana , ela tem +- 700G … porem no final falto espaço na tablespace , ai estou desconfiado que faltou alguns indices para ser criados , tem alguma forma de importar apenas os indices ?

obs: Meu backup foi feito via EXP normal ….

alguem pode me ajudar ?

[eversonpizaParticipante]

Oi Lucas,

Faz o import novamente com as opções show=y (para não importar nada de verdade) e indexfile=.

Ele vai criar um arquivo com todos os creates, vc vai ter que tratar ele para ver oq realmente quer, mas é um caminho.

Att.
Everson

[vieriParticipante]

vc tem acesso a base original desse export?

se tiver faz um consulta via dblink comparando indice que existe lá e não existe aqui.

700Gb é um tamanho mto grande para export.

Pq não fez por RMAN?

existe uma opção de resumable que é bom ser udada para imports grandes como esse.

[rmanParticipante]

@DBA_LUCAS

Se utilizar o Data Pump vai ganhar no mínimo 50% de desempenho.

[vieriParticipante]

Me prova que ganha 50% em cima de um import com direct, recordlenght,commit
e buffer ajustados?? 😛

Restore de base grande é com RMAN. #FATO

[vieriParticipante]

trecho de documentação da própria oracle.

Why is Data Pump slower on small jobs?
Oracle White Paper— Oracle Data Pump Quick Start
9
Data Pump was designed for big jobs with lots of data. Each Data Pump job has a master
table that has all the information about the job and is needed for restartability. The overhead
of creating this master table makes small jobs take longer, but the speed in processing large
amounts of data gives Data Pump a significant advantage in medium and larger jobs.

portando import’s pequenos fiquei com export/import.

medios e grande fique com RMAN.

Se não tiver como ser rman, por não conhecer.
bases médias e grandes use IMPDP.

[fabiogaleraParticipante]

DBA_LUCAS,

Compare os dois schemas:

SELECT count(*), object_type from dba_objects where owner ='SCHEMA_NAME' group by object_type;

Check se tem os mesmos números de objetos, etc.

Quanto aos indexes, basta executar:


imp user/senha file=dump log=log.log rows=N indexes=Y ignore=Y

[rmanParticipante]

@vieri

Recentemente implantei o Data Pump (10.2.0.4.0) como solução de dump. Consegui ótimos resultados. No total foram 8 servidores.

Pensando na exportação, dos 8 servidores apenas 1 não houve ganho de performance em termos de tempo de exportação, segue os dados:

Servidor -> exp -> expdp
A -> 02:18 -> 00:28
B -> 00:21 -> 00:09
C -> 00:20 -> 00:29
D -> 01:34 -> 00:09
E -> 03:15 -> 00:31
F -> 00:32 -> 00:18

Apenas o servidor D não ganhou performance, houve um acrescimo de 9 minutos…

Em relação ao espaço em disco, segue

Servidor -> exp -> expdp
A -> 86 GB -> 70 GB
B -> 19 GB -> 17 GB
C -> 12 GB -> 12 GB
D -> 17 GB -> 13 GB
E -> 34 GB -> 26 GB
F -> 13 GB -> 13 GB

Com exceção de 2 servidores, todos houveram economia de espaço, chegando ate 16 GB.

Esses são bancos em produção, resultado real.

Tenho dados de um imp e impdp realizado em um VM do Virtualbox

imp -> impdp

02:09 -> 01:18

[DBA_LUCASParticipante]

Muito obrigado a todos , irei testar e posto os resultados …. vlw

[vieriParticipante]

Legal Rman,
existe um motivo para em alguns casos ser superior e outros não.

Porque o DATAPUMP, possui uma estrutura mais complexa para iniciar seu job, ele preeenche algumas tabelas internas,prepara o paralelismo e ele foi criado para GRANDES processos. Ele já possui a leitura direct path como default que ela é mais rápida, enquanto no exp vc tem que setar. Ele também foi feito para trabalhar em ótimos servidores para poder usufruir de paralelismo de CPU e leitura em disco. Então por isso num servidor ficou bem melhor em outro não.

Já questão de espaço no DUMP, já é uma controvérsia, pois acho que ninguem guarda dump que não seja compactado né… ai o resultado no final da compactação deve ser bem parecido.. a diferença é que o datapump já deve compactar algo em tempo de processamento.

além dos resultados em minutos gostaria de ver o comando no expdp e exp e o imp e impdb, pois ambos tem vários parametros de ajuste de performance, que deve ser ajustado de acordo com recursos e janelas disponiveis. Então vai da experiencia do dba também prover um processo mais lento ou não. Acredito que um datapump bem parametrizado deve superar em muito um exp/imp default. Mas derrepente um exp/imp todo parametrizado pode superar um expdp/impdp pouco parametrizado.

O datapump é melhor sim, mas dai dizer que o exp imp está aposentado eu acho que ainda é cedo… vejo muita gente usando e ele é bastante usual. O ideal é dominar (dominar mesmo, conhecer TODOS parametros) de uma das duas ferramentas, e obviamente ser BOM em RMAN.

se alguem tiver mais resultados de tempo seria legal.

vou tentar fazer alguns.

[rmanParticipante]

@vieri

Segue os scripts utilizados para a coletas de métricas:

Exemplo de uso do timer:

$ ./timer ./expdpFull


timer

#!/bin/bash
TIMER_INICIO=date +%s
$1
TIMER_TERMINO=date +%s

TIMER_DATA_HORA_ARQUIVO=date -d @$TIMER_INICIO +%Y%m%d_%H%M%S
TIMER_LOG=timer$TIMER_DATA_HORA_ARQUIVO.log

if [ date "+%:z" = '-02:00' ]; then # horario de verao
TIMER_TZ=7200 #GMT+2
else
TIMER_TZ=10800 #GMT+3
fi

TIMER_TOTAL=expr $TIMER_TERMINO - $TIMER_INICIO + $TIMER_TZ
TIMER_TOTAL=date -d @$TIMER_TOTAL +%H:%M:%S

TIMER_DATA_HORA_LOG=date -d @$TIMER_INICIO +"%d-%m-%Y %H:%M:%S"

echo Paramêtro: $1 > $TIMER_LOG
echo Inicio: $TIMER_DATA_HORA_LOG >> $TIMER_LOG
echo Termino: date -d @$TIMER_TERMINO +"%d-%m-%Y %H:%M:%S" >> $TIMER_LOG
echo Total: $TIMER_TOTAL >> $TIMER_LOG

expFull

#!/bin/bash
DATA_HORA=date +%Y%m%d_%H%M%S
exp system/senha file=full$DATA_HORA.dmp log=full$DATA_HORA.log full=y buffer=64000
statistics=none feedback=2000

expdpFull

#!/bin/bash
DATA_HORA=date +%Y%m%d_%H%M%S
expdp datapump/senha job_name=expdpFull$DATA_HORA dumpfile=full${DATA_HORA}_%U.dmp
logfile=full$DATA_HORA.expdp.log directory=DATAPUMP full=Y compression=METADATA_ONLY
filesize=4G flashback_time="TO_TIMESTAMP(TO_CHAR(SYSDATE, 'YYYY-MM-DD
HH24:MI:SS'), 'YYYY-MM-DD HH24:MI:SS')"

impSchemas

#!/bin/bash
imp userid=system/senha file=full21hrs300811.dmp log=full21hrs300811.imp.log
fromuser=vetorh,vetorh_simula touser=vetorh,vetorh_simula feedback=2000 statistics=none
buffer=128000


impdpSchemas

#!/bin/bash
read -p 'DATA_HORA: (YYYYMMDD_HHMMSS) ' DATA_HORA
impdp datapump/senha job_name=impdpFull${DATA_HORA} dumpfile=rh_full1_${DATA_HORA}_
%U.dp.dmp logfile=rh_full1_${DATA_HORA}.impdp.log directory=DATAPUMP
schemas=VETORH,VETORH_SIMULA
remap_schema=VETORH:VETORH_BKP,VETORH_SIMULA:VETORH_SIMULA_BKP
remap_tablespace=VETORH_DAD:DATA,VETORH_IDX:INDEX


Se você tiver parâmetros que melhorem a performance do exp/imp ou do expdp/impdp, for favor poste 😆

[Rodrigo AlmeidaParticipante]

Bom,

Sobre a dúvida inicial, faça a comparação entre os índices que falta pelo SELECT que o FabioGalera passou. Ao saber, quais os índices que faltam, gera um INDEXFILE com o comando de IMP para pegar a DDL dos índices que falta e executar novamente.

Ex:

imp system/manager file=arquivo.dmp indexfile=ddlidx.sql

E pronto!

Sobre EXP Convencional e Data Pump, bom, Data Pump é uma API que pode trabalhar diretamente com as funções principais do Oracle, oferece muito mais recursos e performance. Mas ambos tem prós e contras.

Abraços,

[vieriParticipante]

exp:

incluiria direct=y compress=n recordlenght=65536 ( 8 * db_block_size)

imp:

incluiria commit=y recordlenght=65536 ( 8 * db_block_size)

datapump ainda estou estudando….

só faltou vc postar o resultado agora!! 😀

[Rodrigo AlmeidaParticipante]

hehehehe…. coloca:

recordlenght=65535

Pq o EXPORT vai realizar um TRUNC de 1 BYTE para o tamanho do registro, assim teremos os 64K por linha.

Abraços,

[rmanParticipante]

@vieri

Quando tiver um tempinho, realizarei o teste… Aguarde que em breve postarei o resultado.

[Autor]

Posts