Menu de navegação

[mpvargasParticipante]

Caros Amigos,
Existe algum parâmetro para agilizar o processo do impdp?
Estou fazendo testes para migração, mas a importação está demorando muito… minha base tem 80Gb
Obrigado

[Ricardo Portilho ProniParticipante]

No banco onde o impdp está sendo importado, crie arquivos de REDO, de 2 GBs, e uns 10 grupos.
Deixe o banco em NOARCHIVELOG até terminar a importação.
Deixe a PGA grande, e a SGA pequena, durante a importação.
Se só isso não ajudar, faça a importação sem os índices, e crie eles manualmente depois.

[mpvargasParticipante]

OK
Muito Obrigado.

[juliano_sfParticipante]

Se possível, deixe o arquivo do DUMP em outro disco físico na mesma máquina, pois aí ele não terá concorrencia para ler o dump e escrever no banco

att,

Juliano

[Anônimo]

nao esquece… coloque tambem o parallel=2 ou 3 ou mais, de acordo com o nro de processadores.

t+

[josenizParticipante]

Não tem sentido algum em criar 10 grupos de REDO de tamanhos monstruosos num banco em NOARCHIVELOG mode.

[Ricardo Portilho ProniParticipante]

O impacto de ter-se REDOs insuficientes para dar “uma volta” antes do DBWR gravar todos, é o mesmo em ARCHIVELOG ou em NOARCHIVELOG.
Por exemplo, se vc tiver 3 grupos de REDO de 50MB, sua gravação estará limitada a 150MB, aí o banco tem que esperar até o DBWR grvar os blocos sujos nos datafiles, para então voltar a usar o primeiro REDO.
Isto irá acontecer tanto em ARCHIVELOG quanto em NOARHIVELOG.

[josenizParticipante]

Há uma imensa confusão aqui entre os seguintes componentes (e processos): redo log buffer, redo log, archived log, DBWR, LGWR e UNDO.
Você transferiu a responsabilidade dos segmentos de UNDO para os redo logs?

O DBWR não é responsável pela gravação dos redo log files (contidos em seus redo log groups). O DBWR a cada 3 segundos avalia a fila de
checkpoints (dirty list) e grava os dirty blocks (blocos no buffer de dados que sofreram alterações) nos datafiles.
O LGWR é responsável pela transferência (gravação) dos redo log buffers (area contida na SGA) para os redo logs (redo log files/redo log groups).
O ARCn é responsável pela gravação dos archived logs (se e somente se o banco estiver em ARCHIVELOG mode), entra em ação no chaveamento dos redo log groups (mais jamais espera o preenchimento de todos os redo groups).
Os segmentos de UNDO devem ser suficientes para comportarem uma transação (parece que você confundiu eles com os redo logs). Eles armazenam uma “imagem” (valor inicial) de todos os registros que sofreram mudanças durante uma transação, em caso de rollback os valores dos registros são recuperados dos segmentos de UNDO. O archived logs (e redo logs) são usados apenas no processo de recovery do banco de dados (quer seja ele automatico ou manual).

Não existe “espera” até que todos os grupos de redo sejam preenchidos, as “esperas” de REDO ocorrem:
– na transferência dos redo log buffers para os redo logs;
– no switch (chaveamento) entre redo groups;
– no arquivamento dos redo logs (geração de um archived log), que ocorre no switch log.

Os redo log buffers (area contida na SGA) são gravados nos redo logs pelo LGWR quando um dos seguintes fatos ocorrer primeiro (uma questão clássica de certificação):
– um commit (aqui esta a razão de aplicações com commit excessivo terem baixa performance);
– a cada 3 segundos;
– atingir 1/3 de ocupação (1/3 de log_buffer definido no init.ora ou no spfile);
– sempre antes do DBWR gravar os dirty blocks contidos na dirty list.

Se o banco estiver em archivedlog mode quanto maior for o redo log maior será o seu tempo de arquivamento, desse fato podemos concluir o número de redo groups deverá ser incrementado, assim evitaremos a contenção de redo pelo LGWR (e não pelo DBWR).

Na prática o switch entre redo logs deve estar entre 15 ou 30 minutos… algo impossível de se atingir quando se tem um banco mixado (OLTP, DW e batch em algum momentos).

Para visualizar a independência (e frequência dos) dos archived logs dos redo logs, e a ocorrência de um log arquivado após o switch de redo log
analise as ocorrências no alert.log, a view v$log e a v$archived_log.

[Ricardo Portilho ProniParticipante]

Devo ter me espressado mal.

Não me referi a UNDO, estava me referindo a quando os REDOs grandes são necessários para uma grande gravação de dados, ou ocorerá o erro “Thread cannot allocate new log, sequence ; Checkpoint not complete”.
Este erro ocorre porque uma volta foi dada nos REDOs, e o primeiro ainda está ACTIVE.
Este erro significa um congelamento temporário das gravações.

Aqui uma disussão boa do T. Kyte a respeito.

http://asktom.oracle.com/pls/asktom/f?p … 9012348056

Para testar se isso é verdade, use REDOs pequenos, faça uma grande gravação (imp de centenas de MB) e veja qual foi o tempo.
Depois aumente os REDOs, e veja o tempo novamente.

[josenizParticipante]

Agora ficou claro, não discordo de você que a importação de um grande volume de dados irá sobrecarregar os REDO logs, apenas não concordo que sempre a solução será aumentar o tamanho do redo log. Aumentar o
redo log com certeza irá “aliviar” o problema (na maioria das vezes irá revolver), mas em outras situações o problema tambem poderá ser:
– disco lentos
– redos e tablespaces de dados sobre o mesmo disco;
– redos (ou grupos de redo) sobre o mesmo disco.
– um processo DBWR para um OS sem I/O assincrono pode ser insuficiente
– intervalo de checkpoint com um valor muito alto
– timeout de checkpoint mal dimensionado

A referência citada por você é muito boa, o Ask Tom sempre tem bons materiais.

[Autor]

Posts