Menu de navegação

[PetersonParticipante]

Bom dia amigos,

Preciso deletar uns 30 milhões de registros em uma tabela. É possível usar a cláusula NOLOGGING com essa função?

tipo

DELETE tabela NOLOGGING
WHERE TO_DATE(coluna_string) < SYSDATE - 90;

[burgaParticipante]

Oi Peterson,
Não sei se dá pra fazer delete com nologging…

Dê uma olhada aqui em outra alternativa:
https://profissionaloracle.com.br/blogs/portilho/2008/10/20/delete-lento-no-oracle/

[VitorLeandroParticipante]

Fala Peterson, quanto tempo!

Cara, a única forma que conheço é o CREATE TABLE x NOLOGGING AS SELECT . Esse gera o mínimo de redo. Os Hints tipo DELETE /*+ NOLOGGING */ FROM não funcionam em bancos em ARCHIVELOG MODE. Já pesquisei em tudo e qualquer lugar, não funcionam mesmo. As únicas operações NOLOGGING (que não geram redo) são utilizando o método APPEND (DIRECT PATH) e algumas outras operações, mesmo assim, com o banco em modo NOARCHIVELOG.

Esse montande de 30 milhoes é quantos % da tabela?

[PetersonParticipante]

Fala Vitor, tá sumido amigo!

Galera, fiz conforme sugerido. criei uma tabela temporária com o CREATE TABLE AS SELECT, dropei a tabela principal e renomeei a que criei.

Legal… Liberei espaço na Tablespace…

mas agora acontece o seguinte. A tablespace tem 65GB, mostra que ela está usando apenas 11, mas quando vou dar um resize nela, dá o erro
[b]
Failed to commit: ORA-03297: file contains used data beyond requested RESIZE value
[/b]

Alguém já passou por isso?

[VitorLeandroParticipante]

Opa, já passei por isso algumas vezes… Acontece é que quando você dropa uma tabela ela deverá ir para a recycledbin. A não ser que você faça um drop table purge, impossibilitando assim o flashback.

Tente limpar os ítens dropados que estão em recyclobin (purge dba_recyclebin) que limpa tudo.

Se mesmo assim não funcionar, quer dizer que você precisa alterar a marca dágua de objetos que cresceram, encolheram mas não “liberaram espaço para outros”..

Cada caso é um caso, e a solução depende do seu ambiente.

Segue um link do Legatti explicando as formas:

http://eduardolegatti.blogspot.com/2008 … space.html

Eu prefiro agendar um horário que o sistema pode ficar indisponível ou muito lento, fazer um coalesce na tablespace, alter table move e rebuild dos índices.
Apartir do 10G existem as features de compact ou shirink, mas eu pessoalmente prefiro ver acontecer.

[PetersonParticipante]

Vitor,

O purge dba_recyclebin eu já havia tentado, mas sem sucesso.
Acho que o jeito vai ser criar outra tablespace, fazer um move das tabelas e dropar o tablespace atual… osso!

[PetersonParticipante]

Vitor, não resolveu meu problema, mas não posso deixar de registrar… o link que vc mandou tem um conteúdo muito bom!!!

Bom, no feriado faço o move das tabelas para outra tablespace, depois posto aqui o resultado.

Obrigado a todos!

[CleitonHanzenParticipante]

Opá…

Te pergunto:
Você quer fazer resize da tablespace para liberar espaço para outras tablespaces? (devido a falta de espaço em disco?)

Essa tabela que vocë dropou vai crescer novamente a este tamanho tão grande?

Perguntas que eu me faria caso estivesse nessa situação, se a tabela for pra crescer novamente, não faria nem um nem outro (nem resize da tablespace, nem move das tabelas).

O máximo que faria era recriar a tabela com o init = ao tamanho usado por ela até antes do delete, digo isso, por que se ela crescer exponencialmente de novo, o “trabalho” que o Oracle vai ter pra extender os datafiles e a tabela será bastante grande, não compensando essa manutenção… 😉

[PetersonParticipante]

Cleiton,

Sua observação é boa. A situação é a seguinte: Estou com sérias restrições de espaço em disco. As áreas de disco estão longe de serem bem definidas, então acontece que tenho a área de backups e a de banco em uma mesma área de disco. Isso está consumindo muito esforço para administrar de tal forma que não falte espaço nem para backups nem para o banco.
Essa tabela é uma tabela que nunca havia sofrido expurgo e vi potencial de liberar 40GB expurgando esse dados dela… Já comprei novos discos para resolver definitivamente o problema, mas como são discos para storage, demoram a chegar. Enquanto eles não chegam, pretendo liberar espaço nessa tablespace e depois dividir em áreas de armazenamento como a regra manda.
Liberando esse espaço de 40GB ainda deixo cerca de 50% de margem de crescimento para a tabela, o que acredito ser suficiente até o upgrade da storage.

Obrigado pela ajuda!

[CleitonHanzenParticipante]

Entendido e assino em baixo…..nessas horas DBA tem que virar “mágico” pra conseguir resolver esses imbróglios….rsrsrsrs

[PetersonParticipante]

Exatamente Cleiton, nesse caso, tenho q tirar uns 50 Gigas da minha cartola

😮

[PetersonParticipante]

Bom dia amigos,

Só para finalizar o assunto. Criei uma nova tablespace com 20G, movi todos os segmentos da tablespace antiga para ela, fiz rebuild nos índices, apontando-os para essa nova tablespace e a defini com default tablespace do usuário. Pronto! Posso excluir a tablespace antiga!

Obrigado a todos!

[gaussParticipante]

Como ficaram as triggers e constraints quando você dropou a tabela original e renomeou a nova para o nome antigo?

[PetersonParticipante]

Não tinha triggers nesta tabela, mas as constraints permaneceram. A única coisa que tive de fazer foi recriar a chave primária da tabela. As constraints do tipo check todas seguiram com a nova tabela.

[Autor]

Posts