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 oracle_br@yahoogrupos.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: oracle_br@yahoogrupos.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] >