Menu de navegação

[msantinoParticipante]

Pessoal, to encontrando um problema muito estranho e curioso e queria um help de vocês, pois ja pesquisei pra caramba e não consigo chegar a uma conclusão.

Eu tenho 2 instâncias no mesmo servidor e as duas estão apresentando o mesmo problema:
Durante o EXPDP, seja ele FULL ou SCHEMA, apresenta o erro ORA-08103: object no longer exists no alert.log e o JOB simplesmente não prossegue, congela, mas tanto seu status (usando o ATTACH) quanto na view DBA_DATAPUMP_JOBS mostra eternamente como EXECUTING.

Pesquisando o erro relacionado a EXPDP, já vi gente falando de bug (não confirmado) e de pessoas dizendo que pode ser problema no datafile, com bloco corrompido ou coisa do tipo, e portanto o DATAPUMP não consegue acessar o objeto. Só que se o DATAFILE tivesse corrompido eu estava tendo problemas com o banco e não ocorre absolutamente nada.

Se os JOBs não forem interrompidos manualmente ficam em execução eternamente, por dias. Quando descobri o problema tinham 5 JOBs congelados, um deles há 5 dias e os demais que iniciaram nos dias seguintes apresentaram o mesmo problema.

Alguém tem uma luz?

Seguem informações do ambiente:
Servidor
– Red Hat 6 – x64
– 32 processadores
– 128GB RAM

Banco
– Oracle 11g (11.2.0.3) – x64
– SGA: 40gb (as 2 instâncias são iguais)

Valeu pessoal, abs!

[gazioliParticipante]

Fala cara blz?

tenta executar essa query para ver onde ele esta parando, talvez de para saber qual objeto ele esta parado:

SELECT SID,
SERIAL#,
START_TIME,
round(((SOFAR / TOTALWORK) * 100),2)||’%’ as “% Realizado”,
trunc(elapsed_seconds/86400)|| ‘:’|| to_char(to_date(mod(elapsed_seconds,86400), ‘SSSSS’), ‘HH24:MI:SS’) “Decorrido”,
trunc(time_remaining/86400)|| ‘:’|| to_char(to_date(mod(time_remaining,86400), ‘SSSSS’), ‘HH24:MI:SS’) restante,
MESSAGE
FROM V$SESSION_LONGOPS
where TIME_REMAINING > 0
ORDER BY TIME_REMAINING;

tem essa outra query que mostra os waits, veja o que esta fazendo:

SELECT W.SID,
W.EVENT,
W.SECONDS_IN_WAIT as “TIME_WAITED”,
SQL.SQL_TEXT,
sql.SQL_FULLTEXT
FROM V$SESSION_WAIT W, V$SESSION S, V$PROCESS P, V$SQLAREA SQL
WHERE W.SID = S.SID
AND S.PADDR = P.ADDR
AND SQL.ADDRESS = S.SQL_ADDRESS
AND SQL.HASH_VALUE = S.SQL_HASH_VALUE
AND W.WAIT_CLASS != ‘Idle’
ORDER BY W.SECONDS_IN_WAIT, W.SID;

Abs,

---

Gazioli

[msantinoParticipante]

gazioli, valeu pela resposta. Só consegui testar hoje, e o comportamento é exatamente o mesmo:

O DUMP começa a executar, ele faz o levantamento de todos os objetos, começa a exportar os dados e ai trava. Fica no mesmo status eternamente.

Por exemplo, pelo client do expdp, esse é o status que fica:

Export> status

Job: SYS_EXPORT_FULL_01
Operation: EXPORT
Mode: FULL
State: EXECUTING
Bytes Processed: 17,690,383,176
Percent Done: 99
Current Parallelism: 10
Job Error Count: 0
Dump File: /u03/backup/dump/prod1/expdp_prod1_2012-08-27_144917_%u.dmp
Dump File: /u03/backup/dump/prod1/expdp_prod1_2012-08-27_144917_01.dmp
bytes written: 1,967,927,296
Dump File: /u03/backup/dump/prod1/expdp_prod1_2012-08-27_144917_02.dmp
bytes written: 1,960,329,216
Dump File: /u03/backup/dump/prod1/expdp_prod1_2012-08-27_144917_03.dmp
bytes written: 1,918,627,840
Dump File: /u03/backup/dump/prod1/expdp_prod1_2012-08-27_144917_04.dmp
bytes written: 1,946,865,664
Dump File: /u03/backup/dump/prod1/expdp_prod1_2012-08-27_144917_05.dmp
bytes written: 2,185,584,640
Dump File: /u03/backup/dump/prod1/expdp_prod1_2012-08-27_144917_06.dmp
bytes written: 1,945,800,704
Dump File: /u03/backup/dump/prod1/expdp_prod1_2012-08-27_144917_07.dmp
bytes written: 2,165,612,544
Dump File: /u03/backup/dump/prod1/expdp_prod1_2012-08-27_144917_08.dmp
bytes written: 1,892,950,016
Dump File: /u03/backup/dump/prod1/expdp_prod1_2012-08-27_144917_09.dmp
bytes written: 1,866,018,816
Dump File: /u03/backup/dump/prod1/expdp_prod1_2012-08-27_144917_10.dmp
bytes written: 4,096

Worker 1 Status:
Process Name: DW00
State: EXECUTING
Object Schema: RAFAELMW
Object Type: DATABASE_EXPORT/SCHEMA/PROCACT_SCHEMA
Completed Objects: 720
Worker Parallelism: 1

Worker 2 Status:
Process Name: DW01
State: WORK WAITING

Worker 3 Status:
Process Name: DW02
State: WORK WAITING

Worker 4 Status:
Process Name: DW03
State: EXECUTING
Object Schema: ORDDATA
Object Name: ORDDCM_CT_PRED_OPRD
Object Type: DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
Completed Objects: 2,760
Total Objects: 540,473
Worker Parallelism: 1

Worker 5 Status:
Process Name: DW04
State: WORK WAITING

Worker 6 Status:
Process Name: DW05
State: WORK WAITING

Worker 7 Status:
Process Name: DW06
State: WORK WAITING

Worker 8 Status:
Process Name: DW07
State: WORK WAITING

Worker 9 Status:
Process Name: DW08
State: EXECUTING
Object Schema: SYSMAN
Object Name: MGMT_TASK_QTABLE
Object Type: DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
Completed Objects: 2,716
Total Objects: 540,473
Worker Parallelism: 1

Worker 10 Status:
Process Name: DW09
State: WORK WAITING

Coloquei em anexo o resultado da query, porque ficou mal formatado quando colei aqui. Ele não passa de 58,95% de progresso e nos WAITS, ele só aumenta o tempo, não sai mais disso…

Obs: Esse DUMP está sendo feito com parallel=10 mas eu já experimentei tirar o parallel e ficou exatamente o mesmo comportamento.

Segue o comando executado:

expdp datapump/******** FULL=Y directory=DUMP dumpfile=expdp_prod1_2012-08-27_144917_%U.dmp logfile=expdp_prod1_2012-08-27_144917.log PARALLEL=10 exclude=SCHEMA:"in('SYSTEM','SYSAUX','OUTLN','ANONYMOUS','OLAPSYS','MDDATA','MGMT_VIEW','SCOTT','DATAPUMP')",STATISTICS METRICS=y

Já experimentei tirar também o EXCLUDE, deixar ele limpinho, somente o dump full e nada!

[msantinoParticipante]

Anexando o arquivo…

Attachments:

• query_result.zip

[gazioliParticipante]

Opa! achei que tivesse esquecido de responder rs…

cara pelos waits enviado (2 query) se o SID for correspondente aos workers do expdp, vc esta com problema de Lock na Library.

olha só:

SID event time_waited SQL_TEXT
2300 library cache lock 3553 SELECT /+rule/ SYS_XMLGEN(V
1741 library cache lock 1741 SELECT /+all_rows/ SYS_XMLGEN(VALUE(K

use essa query abaixo para ver o que esta em lock library e o SID. (executar com SYS):

select distinct ses.ksusenum sid,
ses.ksuseser serial#,
ses.ksuudlna username,
ses.ksuseunm machine,
ob.kglnaown obj_owner,
ob.kglnaobj obj_name,
pn.kglpncnt pin_cnt,
pn.kglpnmod pin_mode,
pn.kglpnreq pin_req,
w.state,
w.event,
w.wait_Time,
w.seconds_in_Wait
from x$kglpn pn, x$kglob ob, x$ksuse ses, v$session_wait w
where pn.kglpnhdl in (select kglpnhdl from x$kglpn where kglpnreq > 0)
and ob.kglhdadr = pn.kglpnhdl
and pn.kglpnuse = ses.addr
and w.sid = ses.indx
order by seconds_in_wait desc;

---

Gazioli – OCA 11g

[msantinoParticipante]

gazioli,

Essa query não retornou nada (executei como sys).

O percentual continua até agora o mesmo e os WAITs também, só que com tempos maiores.

[gazioliParticipante]

Estranho não ter voltado nada. Aqueles 2 SID são do seu EXPDP mesmo né? pelas waits pra mim seu problema é Lock. Tem umas queries que mostram os blocks locks chegou a ver se volta algo? outra coisa, não ficou nada de outros exports?

select * from sys.DBA_DATAPUMP_JOBS t; veja se não tem nada ai que esteja talvez entrando em lock com seu expdp.

flw!

[msantinoParticipante]

gazioli,

Já havia verificado, sempre é a primeira coisa que vejo, se não há outros JOBs pendentes. Zeradinho!

Sobre os locks, acho improvável a menos que o próprio JOB esteja se lockando, porque o sistema é utilizado apenas em horário comercial e ontem à noite por volta das 23h iniciei um novo job. Acompanhei ele e em menos de 1h depois ele já estava travado em 67,94%.
Agora 10h depois de iniciado continua no mesmo patamar.

Rodei todos os tipos de queries que tenho pra identificar locks e não pega nada! Nadinha!

A única coisa que vejo em execução é com a segunda query que você me mandou, que pega o DATAPUMP com wait de “latch: shared pool”.

To anexando o screen do spotlight com os parâmetros atuais da instância. Veja que a Shared Pool tá grande pra caramba e mesmo assim, não está totalmente utilizada.

Attachments:

• spotlight.JPG

[gazioliParticipante]

De fato sua instancia esta com SGA/PGA muito boa para um banco nessa dimensão. Bom vamos ver se mais alguém tem alguma opinião para ajudar. Tentou o Suporte da Oracle?

[Bruno SouzaParticipante]

Bom dia Pessoal,

Estou com esse mesmo problema.

No meu caso começou a acontecer quando atualizei o Oracle.
Antes eu usava o Oracle 10.2.0.4 e atualizei para o Oracle 11.2.0.3
Quando rodo o expdp de um schema, ele também congela. Mas um dia fui fazer um teste e deixei ele para ver o que acontecia. Então vi que ele chega a fazer o expdp, porém leva cerca de 8 horas para fazer, e estou falando de uma base de 60 GB.
Quando ainda estava com a versão 10.2.0.4 ele demorava cerca de 20 minutos para fazer.
Alguém que se deparou com esse problema conseguiu resolver?

Desde já agradeço.
Desculpa se estou desrespeitando alguma regra do fórum, pois sou novo aqui!!!

abs,

[Autor]

Posts