Menu de navegação

[ramasineParticipante]

Galera,

Tenho o delete abaixo, rodando a mais de 3 horas pra apagar somente 200.000 linhas…

DELETE /*+ INDEX_FFS(A) */ FROM est_pun_ped_uni_07 a WHERE a.
cam_ano_ini_cam = 2009

É um DW.. Oracle 10.2.0.3
A tabela está com as estatísticas atualizadas e o delete está indo por índice, ainda forcei o uso do mesmo! Mesmo assim está demorando além do normal, outros já foram feitos em menos de 10 min!!!
Esta tabela não está particionada..ainda!!
To com UNDO de 11 Gb..!

DELETE /*+ INDEX_FFS(A) */ FROM est_pun_ped_uni_07 a WHERE a.
cam_ano_ini_cam = 2009

No trace achei a linha abaixo esquisita…

Rows Row Source Operation
——- —————————————————
1 TABLE ACCESS FULL FILE$ (cr=4 pr=0 pw=0 time=79 us)

Alguem tem uma luz?

Abs

Marcelo

[ramasineParticipante]

O delete completo é esse:

delete FROM est_pun_ped_uni_07
where EST_PUN_PED_UNI_07.CAM_ANO_INI_CAM=2009
and EST_PUN_PED_UNI_07.EJV_NUM_VER=0;

[ramasineParticipante]

O tempo que o cara tá levando pra apagar as linhas:

17:11:11 sql’@’bpodwh > @sess

Last Cal LAST_CALL_ET Idle OSUSER SIDSER USERNAME MODULE EVENT

---

09.08.12 17652 4:54:12 imtare ‘132,58657’ IMTARE SQL*Plus db file sequential read

[Rodrigo AlmeidaParticipante]

Marcelo,

Tem quantos índices na tabela?

Existe algum Lock Shared Exclusive de alguma sessão nessa tabela?

Abraços,

[ramasineParticipante]

Fala Rodrigo,

Tenho 4 índices na tabela!
Não há locks “exclusive” !

[David SiqueiraParticipante]

E ai marcelão?..bele?
Cara tira um explain PLAN desse delete, essa linha do Trace de TABLE FULL não é legal, pode ser que ele nem esteja usando esse seu indice, ou talvez ele não seja o mais indicado e mais eficiente para o processo, posta pra gente o plano de execução ( explain plan).

Abraço

[ramasineParticipante]

Ta aí!

Plan
DELETE STATEMENT ALL_ROWSCost: 1 253 Bytes: 5 488 184 Cardinality: 211 084
2 DELETE EST.EST_PUN_PED_UNI_07
1 INDEX RANGE SCAN INDEX EST.EPP_I Cost: 1 253 Bytes: 5 488 184 Cardinality: 211 084

[David SiqueiraParticipante]

Marcelão, tem triggers amarradas a essa tabela parceiro?

Estão Habilitadas?

Abraço

[ramasineParticipante]

Gande David..antes de mais nada..valeu a ajuda!!

Não cara, não tem nenhuma trigger ligada a esta tabela!

[David SiqueiraParticipante]

Não sei se é seu caso Marcelão, e nem sei se tu pode fazer isso, mais já pensou em deixar essa tabela em NOLOGGING e mandar os DELETES? Pode ser que tu ganhe uma performance ai, alguem passou por isso no Forum, mais não to achando o Post pra te mandar, mais veja se você tem essa opção, só que você tem que atentar porque se teu Banco estiver em Archive quando tu colocar em NOLOGGING não gerara mais archives e consequantemente o que estiver nessa tabela e na tablespace onde ela esta não podera ser recuperado via archives.

Abraço.

[David SiqueiraParticipante]

Marcelão achei algo interessante:

http://glufke.net/oracle/viewtopic.php?t=4278

Veja se te ajuda!!!

Abração!!!

[ramasineParticipante]

Valeu David!
Já tinha lido esse conteúdo antes, nas minhas buscas..rss

O delete acabou agora..vai entrar pro GUINESS…
O pessoal da aplicação vai lançar outros..e aí ficarei de olho!!

[David SiqueiraParticipante]

Veja se consegue deixar um Trace habilitado nesse Delete Marcelão, assim ao final poderemos ter um status melhor de onde esse malandro ai ta parando…depois usaremos o TKPROF e da pra analisar melhor.

Abração!!!!

[Rodrigo AlmeidaParticipante]

Marcelo,

Pelo que tu passo, não tem muita coisa de errado com o delete e sim como está se comportando o banco de dados.

Nos seus primeiros post, ele estava lendo a FILE$ (que é do dicionário Oracle) e sua session wait está com db file sequencial read, ou seja, o seu DELETE estava trabalhando diretamente em disco e fazendo a sua tarefa.

O que pode estar acontecendo é que no momento sua base de dados possa estar com excesso de carga, veja como está o I/O da base e CPU/memória/I.O do servidor.

Outras grandes transações que estão ocorrendo na base também podem impactar o seu DELETE!

Nos próximos DELETES, fique de olho na V$SESSION_WAIT, I/O, e a carga de CPU/memória do servidor, monitore isso. E também se for possível habilitar o trace!

Como a tabela tem 4 índices, então ela está fazendo 5 atividades para cada delete executado, ou seja, 1 tabela + 4 índice, resumindo se o delete irá contemplar 210.000, faz x5, 1.050.000 I/Os na base que pode fazer seu delete pendurar na performance.

Se desabilitar o NOLLOGGING, se for necessário recuperar esses dados ficará bem díficil, então se for produção, não faça isso! A não ser que tenha certeza absoluta que pode mandar os dados para o saco!

Abraços,

[vieriParticipante]

perfeito Rodrigo.

Tu parece aquele programa da discovery channel.

“Caçadores de mito”.

também imagino que o problema seja do servidor mesmo !

rodar o comando
sar 1 10
na hora que tiver executando o delete.

[Autor]

Posts