Bom dia
Fiz os teste conforme sua dica e nao vi nada de anormal, entao removi o banco
de dados via assistente de configuracao , criei uma nova instancia isto no
windows 2008 interprise , fiz o impdp para esta instancia nao deu nenhum erro
na importacao, logo que terminou rodei um expdp e o problema continua, agora
estou tentando rodar o exp e vamos ver se termina, mais desde ja agradeco a
todos, e vamos esperar resposta da oracle.
Outra coisa a 15 dias q abri o chamado na oracle e sem solucao achei q a
oracle era mais rapida na solucao dos problemas ou pelo menos nas respostas,
mais esta deixando a desejar.
att
From: José Laurindo
Sent: Tuesday, December 27, 2011 4:58 PM
To: oracle_br@yahoogrupos.com.br
Subject: Re: [oracle_br]expdp
Colega, não é impossível mas é **** muito muito *** difícil vc ter um
"congelamento" puro e simples - em 99,99% das ocasiões, o que ocorre é que a
sessão atendendo ao job de export está fazendo algum processo longo : uma
possibilidade comum é que o ambiente não é ótimo e deixa/deixou usuários
criarem objetos na tablespace SYSTEM, que agora estão interferindo... Outro é
má-performance das tabelas/views do dicionário de dados, talvez por migração
incompleta do banco (típico, banco que tinha a tablespace SYSTEM DMT e após
upgrade continuou DMT, não foi para LMT)...
Vc pode fazer o seguinte, enquanto aguarda o retorno do Suporte :
=> primeiro, vamos tentar provar que não há nada extra rodando no banco, E que
consultas ao dicionários estão OK :
a) consulte a v$datapump_job, a V$SESSION_LONGOPS com um WHERE TIME_REMAINING >
0 , a V$SESSTAT, a V$SQL e a V$SESSION pra ver se vc não tem jobs anteriores
pendurados / incompletos, ou se vc recebe report de alguma ação longa, QUAIS
SQLs estão sendo executados, etc... Já vi muitos casos em que sessões
anteriores de expdp não terminaram/ficaram penduradas no banco, aí conflitam
com as novas....
b) tire um Statspack (ou AWR/ASH, o que vc tiver disponível na sua versão e no
seu ambiente), outro 15 minutos depois , e veja lá o que vc vê de diferença
c) rode várias vezes, com alguns minutos de intervalo, um script que ligue as
sessões aos waits, pra ver pelo que as sessões estão esperando - no final eu
mostro um que eu uso no sqlplus
d) faça consultas com SELECT * FROM nomedaview, às principais views (ie,
DBA_SOURCE, DBA_OBJECTS, DBA_EXTENTS, DBA_SEGMENTS, etc) : vc deverá ver um
fluxo constante de informações no seu programa-cliente, Qualquer demora ,
qualquer situação aonde o banco fique 'pensando' pode indicar issues, que podem
ir de falta de estatísticas nas tabelas internas até fragmentação ou bugs
=> uma vez vc tendo feito isso e NADA resultou, em não havendo nenhum job de
datapump ativo, execute alguns menores e/ou só de checagem pra ver se dá
diferença ou não ... Poderiam ser algo tipo :
1) export de teste , não gerando dados mas consultando as views/tabelas
internas :
expdp user/senha COMPRESSION=NONE CONTENT=METADA_ONLY
DIRECTORY=diretoriaserusado DUMPFILE=nomedodumpfile ENCRYPTION=NONE FULL=Y
LOGFILE=nomedoarquivodelog STATUS=20 EXCLUDE=STATISTICS
com o exemplo acima vc vai ver na tela coisas do tipo :
....
Job: SYS_EXPORT_FULL_01
Operação: EXPORT
Modo: FULL
Estado: EXECUTING
Bytes Processados: 0
Paralelismo Atual: 1
Contagem de Erros do Job: 1
Arquivo de Dump: C:\ADMIN\O10GR2\DPDUMP\DUMP_FULL_METADATA_ONLY_10GR2.DMP
bytes gravados: 4.096
Worker 1 Status:
Estado: EXECUTING
Esquema de Objeto: WK_TEST
Nome do Objeto: WK$DOC_RELEVANCE_V
Tipo de Objeto: DATABASE_EXPORT/SCHEMA/VIEW/VIEW
Objetos Concluídos: 564
Total de Objetos: 564
Paralelismo do Worker: 1
Processando o tipo de objeto
DATABASE_EXPORT/SCHEMA/VIEW/GRANT/OWNER_GRANT/OBJECT_GRANT
....
Worker 1 Status:
Estado: WORK WAITING
....
C:\Users\jchiappa>
se vc ver ele parar na tela, vc sabe que é esse acesso que está demorado... E
consultando a v$session vc vai ver a cada passo o que ele está fazendo... Um
job de export do tipo *** TEM *** que acabar em relativamente poucos minutos,
se demorar demais vc Fatalmente tem problemas no seu dicionário, e/ou no I/O,
alguma coisa está irregular ...
2) em não dando problema o teste acima, aí é usar a mesma sintaxe (só tirando a
especificação de matadata only) mas especificando só um SCHEMA e excluindo
índices/estatísticas, depois adicionando mais outro e mais outro, até
reproduzir a issue ...
[]s
Chiappa
=> script-exemplo (acionável via sql*plus apenas) para relacionar sessions e
waits :
SET PAGES 999
column sid_serial format A10
column seq# format 99999
column event format a29 heading "Wait Event" trunc
column state format a15 heading "Wait State" trunc
column secs format 9999999 heading "Waited so|far (sec)"
column wt format 9999999 heading "Waited|Seconds"
column P1TEXT format a38
column P2TEXT format a38
column P3TEXT format a38
prompt
prompt Sessões esperando por sql*net message estão aguardando
prompt por resposta do usuário.
prompt Sessões com wait_time <> 0 => consomem CPU
prompt
prompt Atenção à Coluna State, se ela for :
prompt Waiting => ignore Waited Secs, Waited So Far=tempo até agora
prompt Wait.Short Time => menos q um tick de CPU, ignorar
prompt Wait. Know Time => Waited Secs=tempo total esperado, ignore Wait So Far
prompt
prompt Colunas que podem ser Especificadas como Condição, na Ordem:
prompt
prompt => tabela session_wait, prefixar com A. , colunas : SID/SEQ#, WAIT_TIME
,
prompt EVENT, SECONDS_IN_WAIT, STATE,
prompt
prompt => tabela sess_io, prefixar com B. , colunas : BLOCK_GETS,
prompt CONSISTENT_GETS, PHYSICAL_READS, BLOCK_CHANGES, CONSISTENT_CHANGES,
prompt PnTEXT, Pn (com n 1 a 3)
prompt
prompt => tabela v$session, prefixar com C. , usar nome da coluna na v$session
prompt
accept v_cond_wait DEFAULT 'a.event is not null' prompt "Condições a Aplicar
(opcional):"
accept sid_list DEFAULT a.sid prompt "Lista de SIDs (opcional):"
accept v_orderby DEFAULT 'a.sid, a.wait_time, a.event' prompt "Order by:"
SELECT c.sid || ',' || c.serial# SID_SERIAL, a.seq#, a.wait_time wt , a.event,
a.seconds_in_wait secs, a.state,
b.block_gets, b.consistent_gets, b.physical_reads, b.block_changes,
b.consistent_changes,
a.P1TEXT, a.P1,
a.P2TEXT, a.P2,
a.P3TEXT, a.P3,
c.LOGON_TIME,
c.LAST_CALL_ET,
c.ROW_WAIT_OBJ#,
c.ROW_WAIT_FILE#,
c.ROW_WAIT_BLOCK#,
c.ROW_WAIT_ROW#,
c.LOCKWAIT,
c.CLIENT_IDENTIFIER,
c.MODULE,
c.PROGRAM,
c.USERNAME,
c.OSUSER,
c.CLIENT_INFO
FROM v$session_wait a, v$sess_io b, v$session c
WHERE a.sid = b.sid
AND c.sid = b.sid
AND a.sid in (&sid_list)
AND &v_cond_wait
ORDER BY &v_orderby;
undefine v_cond_wait
undefine sid_list
undefine v_orderby
--- Em mailto:oracle_br%40yahoogrupos.com.br, "Francisco Assis - T.I. -
Globoaves - Cascavel/PR" <chico@...> escreveu
>
> Fiz teste com paralelismo e sem o paralelismo, e nao vai, ele chega a criar
> os dumps no directorio , vc analisa via em e diz que esta em 99% concluido
> mais pode deixar dias e ele nao termina , sendo que com o 10g ele levava 4
> horas, estou esperando a oracle vai me da uma solucao em 3 dias , bom assim
> esta no chamado
>
>
> From: Eliandro Jakubski
> Sent: Tuesday, December 27, 2011 2:54 PM
> To: mailto:oracle_br%40yahoogrupos.com.br
> Subject: Re: [oracle_br]expdp
>
>
> Vc. utiliza paralelismo para realizar o dump?
> Vc. utiliza compressão para realizar o dump?
>
>
>
>
>
>
> De:
> "Francisco Assis - T.I. - Globoaves - Cascavel/PR"
> <mailto:chico%40globoaves.com.br>
> Para:
> <mailto:oracle_br%40yahoogrupos.com.br>
> Data:
> 27/12/2011 14:48
> Assunto:
> Re: [oracle_br]expdp
>
>
>
>
> Ola , Nao tem restricao, tambem nao consigo com o usuario sys....
>
> From: Eliandro Jakubski
> Sent: Tuesday, December 27, 2011 2:34 PM
> To: mailto:oracle_br%40yahoogrupos.com.br
> Subject: Re: [oracle_br]expdp
>
> Pergunta inocente: Vc. já verificou se o usuário "oracle" não apresenta
> alguma restrição (limite) de tamanho máximo de arquivo no SO?
>
> ulimit -a ...
>
> De:
> "Francisco Assis - T.I. - Globoaves - Cascavel/PR"
> <mailto:chico%40globoaves.com.br>
> Para:
> <mailto:oracle_br%40yahoogrupos.com.br>
> Data:
> 27/12/2011 14:19
> Assunto:
> Re: [oracle_br]expdp
>
> Boa tarde
>
> Pessoal a dias estou tentando fazer um expdo em minha base , mais ate este
>
> momento nao consigo, ja postei aqui o meu problema ,me deram algumas
> sugestoes nao progrediu, minha base de dados e de 420GB, oracle 11g ultimo
>
> release.
> Nao estou conseguindo nem no OS windows 2008 e nem com o Solaris 10, o
> mesmo comeca mais chega em algum momento , alguns no momento de exporta as
>
> procedures ele congela e nao vai para frente , se ranco as procedures
> congela nas funcoes e assim por diante.
> Ja abri um chamado na oracle e a mesma pediu para fazermos alguns testes
> mais sem solucao , estou aguardando a resposta da oracle, tenho outros
> banco pequenos nas mesmas plataformas de tamanho de 5gb e os mesmos
> finalizam sem problemas.
> Estou colocando meu problema e tentando compartilhar com alguns de vcs ,
> de repente alguem passou por isto ou tem o uma base deste tamanho com o
> 11g e isto nao acontece, gostaria de saber.
>
> att
>
> Chico
>
> [As partes desta mensagem que não continham texto foram removidas]
>
> OBSERVAÇÃO:
> A ITAIPU esclarece que, por força de seu Estatuto, a presente
> mensagem não implica a assunção de obrigações em seu nome.
>
> [As partes desta mensagem que não continham texto foram removidas]
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
>
>
> OBSERVAÇÃO:
> A ITAIPU esclarece que, por força de seu Estatuto, a presente
> mensagem não implica a assunção de obrigações em seu nome.
>
> [As partes desta mensagem que não continham texto foram removidas]
>
>
>
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
[As partes desta mensagem que não continham texto foram removidas]
