Re: [oracle_br] Re: Delete de Milhões de linhas

[Luis Freitas lfreita...@yahoo.com [oracle_br]]

 Alessandro,
Por que você não está usando um "FORALL" no loop? Da forma como está, a 
operação de delete ainda vai deletar uma linha por vez.
Tente algo como o bloco abaixo. Não testei então pode ter erros de sintaxe.
Parece a mesma coisa, mas para o banco de dados é muito diferente. Se você 
remove uma linha de cada vez, ele irá atualizar o bloco e todos os indices para 
aquela linha, e de novo para a próxima linha, asssim por diante. Mas se roda o 
comando em "bulk" ele deve atualizar e fazer a manutenção dos indices em uma 
operação unica. 
Depois você experimenta aumentar esse 1 para ver se tem ganho.
Outra coisa, convém desabilitar constraints de foreign key, se houverem. O 
ideal seria desativar os indices (alter index ... unusable) e fazer um rebuild 
deles depois, mas como o sistema está no ar,  pode não ser viável.


declare cursor c1 is SELECT ROWID FROM OWNER.tableA  where cod_xxx in(select 
cod_xxx from OWNER.tableB aa join OWNER.tableC ar on(aa.cod_xxx = ar.cod_xxx) 
where trunc(COLUNM_DATA) < (select sysdate - TO_YMINTERVAL('01-00') from dual));
 type rows_del is table of rowid index by binary_integer;
dell rows_del;
row_commit pls_integer := 1;rowcount pls_integer := 0;
begin
open c1;loop     fetch c1 BULK COLLECT INTO dell limit row_commit;     exit 
when c1%NOTFOUND;      forall  indx IN 1 .. dell.COUNT loop       
delete from OWNER.tableA                 where rowid = dell(indx);   commit;end 
loop;
close c1;
end;/"
Atc,Luis
 On Thursday, July 16, 2015 6:26 PM, "jlchia...@yahoo.com.br [oracle_br]" 
 wrote:
   

     Nope, Angelo : ao alterar a cláusula de logging para NOLOGGING a ** única 
** Operação de DML capaz de não gerar redo log é o INSERT /*+ APPEND */ 
(cláusula de logging da tabela só serve pra issoessa  só serve para isso, right 
?), e pelo que entendi isso o Alexssandro já tentou e não atendeu...
 Alexssandro, seguinte : primeiro respondendo a sua pergunta original, o ponto 
é que o PL/SQL (e o SQL, também, em grande medida) foi programado para 
trabalhar em LOTES, ie : lê uma porção de linhas para a memória, processa-as, 
depois lê para a MESMA porção de memória antes usada o próximo punhado de 
linhas, processa, assim por diante É POR ISSO, INCLUSIVE, que vc pode fazer 
SELECT * FROM tabeladeumbilhãodelinhas SEM receber um erro de falta de memória 
mesmo num servidor modesto, okdoc ???  
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:5918938803188
 detalha isso, muito embora seja um conceito Básico, certo ??
  Muito bem : por causa dessa premissa, o PL/SQL  tem Limites  na 
memória que pode alocar, ele é programado pensando em LIMITAR o uso de RAM, até 
também  para que o RDBMS em si tenha mais RAM disponível, ele é Prioridade - a 
parte maior da memória RAM é sempre assim reservada para o RDBMS fazer seus 
muitos e múltiplos processos E poder criar seus caches... A sua resposta então 
é CLARA, se vc colocar vários milhares como o LIMIT numa cláusula de BULK 
COLLECT, o array resultante vai ser tão grande que MUITO PROVAVELMENTE vai 
estourar os limites do PL/SQL, independente de quanta RAM livre vc tem... 
Respondido ??

Aí seguem meus comments sobre a sua situação : em PRIMEIRO LUGAR, absolutamente 
Não Tem Como vc fazer uma manipulação de largo volume de dados, como é essa que 
vc pretende, SEM IMPACTO NO AMBIENTE, ok ?? Se, como vc citou para outro 
colega, essa é a sua meta, DESISTA Já, não vai rolar... O que Pode ser feito é 
escolher um caminho de menos impacto, mas que VAI haver Impacto, isso é Líquido 
e certo  Adicionalmente, vc quer Máxima performance/eficiência na 
manipulação : sorry, mas a única maneira de vc obter isso é direcionando TODOS, 
ou QUASE TODOS (ou ao menos a Esmagadora maioria dos recursos do RDBMS) para 
essa manipulação, sim ??? Não tem mágica, se vc quer que uma tarefa longa 
demore menos, dê MAIS RECURSOS do ambiente para essa tarefa... Isso se faz 
PRINCIPALMENTE evitando Concorrência, para que os recursos fiquem 
livres/disponíveis pra tarefa longa, sim ??? Portanto, se vc quer ter Máxima 
Eficiência/Performance, vc VAI TER QUE TER ** ALGUM ** DOWNTIME para os 
usuários, impedindo-os de gastar recursos do banco para que vc os possa usar 
pra tarefa longa, sim sim ??? Vc até pode agendar essa tarefa longa de 
manipulação de dados pra um fim de semana ou uma noite, para tentar interferir 
o menos possível, mas que VAI ter alguma intereferência/indisponibilidade (num 
horário pré-agendado, que seja) isso vai...

==> Com esses esclarecimentos acima, aí podemos discutir métodos Primeiro 
Ponto, vc REALMENTE TESTOU a chance de se fazer a Remoção dos dados sem DML, 
sem delete, ie : INSERT /*+ APPEND */ INTO tabeladecópia (SELECT * FROM 
tabelaoriginal WHERE filtrodosdadosaanter); COMMIT; TRUNCATE TABLE 
tabelaoriginal; INSERT /*+ APPEND */ INTO tabelaoriginal (SELECT * FROM 
tabeladecopia); ??? De modo geral, essa seria a opção mais Eficiente... Só 
mesmo CASO ela seja inviável e/ou não d

Re: [oracle_br] Re: Delete de Milhões de linhas

[jlchia...@yahoo.com.br [oracle_br]]

Nope, Angelo : ao alterar a cláusula de logging para NOLOGGING a ** única ** 
Operação de DML capaz de não gerar redo log é o INSERT /*+ APPEND */ (cláusula 
de logging da tabela só serve pra issoessa  só serve para isso, right ?), e 
pelo que entendi isso o Alexssandro já tentou e não atendeu...
 Alexssandro, seguinte : primeiro respondendo a sua pergunta original, o ponto 
é que o PL/SQL (e o SQL, também, em grande medida) foi programado para 
trabalhar em LOTES, ie : lê uma porção de linhas para a memória, processa-as, 
depois lê para a MESMA porção de memória antes usada o próximo punhado de 
linhas, processa, assim por diante É POR ISSO, INCLUSIVE, que vc pode fazer 
SELECT * FROM tabeladeumbilhãodelinhas SEM receber um erro de falta de memória 
mesmo num servidor modesto, okdoc ???  
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:5918938803188
 detalha isso, muito embora seja um conceito Básico, certo ??
  Muito bem : por causa dessa premissa, o PL/SQL  tem Limites  na 
memória que pode alocar, ele é programado pensando em LIMITAR o uso de RAM, até 
também  para que o RDBMS em si tenha mais RAM disponível, ele é Prioridade - a 
parte maior da memória RAM é sempre assim reservada para o RDBMS fazer seus 
muitos e múltiplos processos E poder criar seus caches... A sua resposta então 
é CLARA, se vc colocar vários milhares como o LIMIT numa cláusula de BULK 
COLLECT, o array resultante vai ser tão grande que MUITO PROVAVELMENTE vai 
estourar os limites do PL/SQL, independente de quanta RAM livre vc tem... 
Respondido ??

Aí seguem meus comments sobre a sua situação : em PRIMEIRO LUGAR, absolutamente 
Não Tem Como vc fazer uma manipulação de largo volume de dados, como é essa que 
vc pretende, SEM IMPACTO NO AMBIENTE, ok ?? Se, como vc citou para outro 
colega, essa é a sua meta, DESISTA Já, não vai rolar... O que Pode ser feito é 
escolher um caminho de menos impacto, mas que VAI haver Impacto, isso é Líquido 
e certo  Adicionalmente, vc quer Máxima performance/eficiência na 
manipulação : sorry, mas a única maneira de vc obter isso é direcionando TODOS, 
ou QUASE TODOS (ou ao menos a Esmagadora maioria dos recursos do RDBMS) para 
essa manipulação, sim ??? Não tem mágica, se vc quer que uma tarefa longa 
demore menos, dê MAIS RECURSOS do ambiente para essa tarefa... Isso se faz 
PRINCIPALMENTE evitando Concorrência, para que os recursos fiquem 
livres/disponíveis pra tarefa longa, sim ??? Portanto, se vc quer ter Máxima 
Eficiência/Performance, vc VAI TER QUE TER ** ALGUM ** DOWNTIME para os 
usuários, impedindo-os de gastar recursos do banco para que vc os possa usar 
pra tarefa longa, sim sim ??? Vc até pode agendar essa tarefa longa de 
manipulação de dados pra um fim de semana ou uma noite, para tentar interferir 
o menos possível, mas que VAI ter alguma intereferência/indisponibilidade (num 
horário pré-agendado, que seja) isso vai...

==> Com esses esclarecimentos acima, aí podemos discutir métodos Primeiro 
Ponto, vc REALMENTE TESTOU a chance de se fazer a Remoção dos dados sem DML, 
sem delete, ie : INSERT /*+ APPEND */ INTO tabeladecópia (SELECT * FROM 
tabelaoriginal WHERE filtrodosdadosaanter); COMMIT; TRUNCATE TABLE 
tabelaoriginal; INSERT /*+ APPEND */ INTO tabelaoriginal (SELECT * FROM 
tabeladecopia); ??? De modo geral, essa seria a opção mais Eficiente... Só 
mesmo CASO ela seja inviável e/ou não dê a melhor performance nos seus testes, 
seja por que motivo for, aí SIM vc avalia as outras...
 O segundo ponto é : para que vc aloque para a tarefa longa os recursos que vc 
conservou impondo alguma Indisponibilidade pros usuários, vc TEM que a quebrar 
em unidades paralelas, ie, vc TEM que implementar algum paralelismo... 
Paralelismo = múltiplas sessões fazendo I/O em diferentes pedaços da tabela 
grande E armazenando as linhas lidas em posições diferentes de RAM OK ?? 
Fosse Enterpise Edition vc teria o Parallel SQL, mas como não é vc VAI TER QUE 
implementar algum tipo de paralelismo de pobre, ie : vc vai abrir múltiplas 
sessões, cada uma lendo e deletando (com BULK, LIMIT 1000, blablabla) pedaços 
diferentes da tabela, separando os pedaços por ROWID... 
https://asktom.oracle.com/pls/asktom/f?p=100:11:P11_QUESTION_ID:10498431232211
 tem um exemplinho genérico...
 
 E claro, não tem a ver com performance mas PLEASE, nunca, jamais, em tempo 
algum meta um EXCEPTION WHEN OTHERS que não registre ** claramente ** qual erro 
deu, sob pena de vc passar batido por erros graves e dificultar DE MONTÃO o 
debug, sim ???
 
 []s
 
   Chiappa

Re: [oracle_br] Re: Delete de Milhões de linhas

[jlchia...@yahoo.com.br [oracle_br]]

Nope, Angelo : ao alterar a cláusula de logging para NOLOGGING a ** única ** 
Operação de DML capaz de não gerar redo log é o INSERT /*+ APPEND */ (cláusula 
de logging da tabela só serve pra issoessa  só serve para isso, right ?), e 
pelo que entendi isso o Alexssandro já tentou e não atendeu...
 Alexssandro, seguinte : primeiro respondendo a sua pergunta original, o ponto 
é que o PL/SQL (e o SQL, também, em grande medida) foi programado para 
trabalhar em LOTES, ie : lê uma porção de linhas para a memória, processa-as, 
depois lê para a MESMA porção de memória antes usada o próximo punhado de 
linhas, processa, assim por diante É POR ISSO, INCLUSIVE, que vc pode fazer 
SELECT * FROM tabeladeumbilhãodelinhas SEM receber um erro de falta de memória 
mesmo num servidor modesto, okdoc ???  
https://asktom.oracle.com/pls/apex/f?p=100:11:0P11_QUESTION_ID:5918938803188
 detalha isso, muito embora seja um conceito Básico, certo ??
  Muito bem : por causa dessa premissa, o PL/SQL  tem Limites  na 
memória que pode alocar, ele é programado pensando em LIMITAR o uso de RAM, até 
também  para que o RDBMS em si tenha mais RAM disponível, ele é Prioridade - a 
parte maior da memória RAM é sempre assim reservada para o RDBMS fazer seus 
muitos e múltiplos processos E poder criar seus caches... A sua resposta então 
é CLARA, se vc colocar vários milhares como o LIMIT numa cláusula de BULK 
COLLECT, o array resultante vai ser tão grande que MUITO PROVAVELMENTE vai 
estourar os limites do PL/SQL, independente de quanta RAM livre vc tem... 
Respondido ??

Aí seguem meus comments sobre a sua situação : em PRIMEIRO LUGAR, absolutamente 
Não Tem Como vc fazer uma manipulação de largo volume de dados, como é essa que 
vc pretende, SEM IMPACTO NO AMBIENTE, ok ?? Se, como vc citou para outro 
colega, essa é a sua meta, DESISTA Já, não vai rolar... O que Pode ser feito é 
escolher um caminho de menos impacto, mas que VAI haver Impacto, isso é Líquido 
e certo  Adicionalmente, vc quer Máxima performance/eficiência na 
manipulação : sorry, mas a única maneira de vc obter isso é direcionando TODOS, 
ou QUASE TODOS (ou ao menos a Esmagadora maioria dos recursos do RDBMS) para 
essa manipulação, sim ??? Não tem mágica, se vc quer que uma tarefa longa 
demore menos, dê MAIS RECURSOS do ambiente para essa tarefa... Isso se faz 
PRINCIPALMENTE evitando Concorrência, para que os recursos fiquem 
livres/disponíveis pra tarefa longa, sim ??? Portanto, se vc quer ter Máxima 
Eficiência/Performance, vc VAI TER QUE TER ** ALGUM ** DOWNTIME para os 
usuários, impedindo-os de gastar recursos do banco para que vc os possa usar 
pra tarefa longa, sim sim ??? Vc até pode agendar essa tarefa longa de 
manipulação de dados pra um fim de semana ou uma noite, para tentar interferir 
o menos possível, mas que VAI ter alguma intereferência/indisponibilidade (num 
horário pré-agendado, que seja) isso vai...

==> Com esses esclarecimentos acima, aí podemos discutir métodos Primeiro 
Ponto, vc REALMENTE TESTOU a chance de se fazer a Remoção dos dados sem DML, 
sem delete, ie : INSERT /*+ APPEND */ INTO tabeladecópia (SELECT * FROM 
tabelaoriginal WHERE filtrodosdadosaanter); COMMIT; TRUNCATE TABLE 
tabelaoriginal; INSERT /*+ APPEND */ INTO tabelaoriginal (SELECT * FROM 
tabeladecopia); ??? De modo geral, essa seria a opção mais Eficiente... Só 
mesmo CASO ela seja inviável e/ou não dê a melhor performance nos seus testes, 
seja por que motivo for, aí SIM vc avalia as outras...
 O segundo ponto é : para que vc aloque para a tarefa longa os recursos que vc 
conservou impondo alguma Indisponibilidade pros usuários, vc TEM que a quebrar 
em unidades paralelas, ie, vc TEM que implementar algum paralelismo... 
Paralelismo = múltiplas sessões fazendo I/O em diferentes pedaços da tabela 
grande E armazenando as linhas lidas em posições diferentes de RAM OK ?? 
Fosse Enterpise Edition vc teria o Parallel SQL, mas como não é vc VAI TER QUE 
implementar algum tipo de paralelismo de pobre, ie : vc vai abrir múltiplas 
sessões, cada uma lendo e deletando (com BULK, LIMIT 1000, blablabla) pedaços 
diferentes da tabela, separando os pedaços por ROWID... 
https://asktom.oracle.com/pls/asktom/f?p=100:11:P11_QUESTION_ID:10498431232211
 tem um exemplinho genérico...
 
 E claro, não tem a ver com performance mas PLEASE, nunca, jamais, em tempo 
algum meta um EXCEPTION WHEN OTHERS que não registre ** claramente ** qual erro 
deu, sob pena de vc passar batido por erros graves e dificultar DE MONTÃO o 
debug, sim ???
 
 []s
 
   Chiappa

Re: [oracle_br] Re: Delete de Milhões de linhas

[alexssandro0...@yahoo.com.br [oracle_br]]

Olá André!! O ambiente é 24x7. Para realizar manutenção é bem complicado. 

Re: [oracle_br] Re: Delete de Milhões de linhas

[Andre Santos andre.psantos...@gmail.com [oracle_br]]

Alex

O ambiente é 24x7 ? Ou há janela para manutenções de madrugada?

[ ]

André


Em 16 de julho de 2015 15:21, angelo angelolis...@gmail.com [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Alexsandro
>
> O que poderia fazer tambem é alterar essas tabelas para NOLOGGING
> para nao produzir redo quando excluir que isso vai atravancar a
> maquina eu acho
>
>
>
>
> 2015-07-16 15:00 GMT-03:00 alexssandro0...@yahoo.com.br [oracle_br] <
> oracle_br@yahoogrupos.com.br>:
>
>>
>>
>> Sérgio, estou fazendo um expdp para fazer o backup dos dados do mês mais
>>  antigo que tenho.
>> Depois de realizar o backup tenho que deletar estes dados do banco.
>>
>> Com um expdp/impdp, vou ter que fazer diversos passos e terá dowtime.
>>
>> Eu preciso é deletar apenas os dados que estão no backup sem nenhuma
>> indisponibilidade e sem impacto no ambiente.
>>
>>
>  
>

Re: [oracle_br] Re: Delete de Milhões de linhas

[angelo angelolis...@gmail.com [oracle_br]]

Alexsandro

O que poderia fazer tambem é alterar essas tabelas para NOLOGGING
para nao produzir redo quando excluir que isso vai atravancar a maquina
eu acho




2015-07-16 15:00 GMT-03:00 alexssandro0...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br>:

>
>
> Sérgio, estou fazendo um expdp para fazer o backup dos dados do mês mais
>  antigo que tenho.
> Depois de realizar o backup tenho que deletar estes dados do banco.
>
> Com um expdp/impdp, vou ter que fazer diversos passos e terá dowtime.
>
> Eu preciso é deletar apenas os dados que estão no backup sem nenhuma
> indisponibilidade e sem impacto no ambiente.
>
>  
>

[oracle_br] Re: Delete de Milhões de linhas

[alexssandro0...@yahoo.com.br [oracle_br]]

Sérgio, estou fazendo um expdp para fazer o backup dos dados do mês mais  
antigo que tenho. Depois de realizar o backup tenho que deletar estes dados do 
banco.
 

 Com um expdp/impdp, vou ter que fazer diversos passos e terá dowtime.
 

 Eu preciso é deletar apenas os dados que estão no backup sem nenhuma 
indisponibilidade e sem impacto no ambiente. 

Re: [oracle_br] Delete de Milhões de linhas

[Sérgio Luiz Rodrigues Chaves sergio.cha...@elumini.com.br [oracle_br]]

Alexssandro,




Verifique a opção de exportar a tabela e importa-la novamente com a clausula 
"WHERE".




Veja em 
www.dba-oracle.com/t_impdp_where_clause_query.htm.


http://dbaforums.org/oracle/index.php?showtopic=23416




Att.




Sérgio.


import (impdp) with where clause Tips
import (impdp) with where clause Tips
Leia mais...









De: oracle_br@yahoogrupos.com.br  em nome de 
alexssandro0...@yahoo.com.br [oracle_br] 
Enviado: quinta-feira, 16 de julho de 2015 13:23
Para: oracle_br@yahoogrupos.com.br
Assunto: Re: [oracle_br] Delete de Milhões de linhas






Ops...


Pessoal, esqueci de colocar aqui a versão do Oracle.
11.0.2.0.4 Standard Edition.


Desta forma minhas opções são limitadas.
Sem particionamento etc..

[oracle_br] Re: Replicação no Oracle(Oracle Streams)

[jlchia...@yahoo.com.br [oracle_br]]

Blz ? Então, eu tenho uma predileção especial pelo standby físico via archived 
redo log (seja automatizado pelo DATAGUARD, o que Prefiro sempre, seja manual 
se estiver trabalhando com um ambiente sem o DG) como solução de replicação de 
banco todo Justamente por causa do fato de que o bd origem ele transmite e o 
destino recebe basicamente apenas os poucos bytes que precisam ser alterados 
fisicamente nos blocos, então pra ele é ABSOLUTA e TOTALMENTE irrelevante qual 
datatype as tabelas presentes nos blocos possuem, qual o tamanho delas, quem 
está fazendo o DML, nadica de nada A bem da verdade para o mecanismo de 
replicação via archived redo logs até mesmo coisas como quantidade/lista de 
tabelas presentes se torna Irrelevante, já que ele trabalha com o Físico... SE 
realmente replicação TOTAL de um database é o que vc quer/precisa, penso que 
ele vai ser mesmo a Melhor solução...  
 A única situação em que Realmente o standby físico não atende é se vc quiser 
usar o database-destino da replicação para Consultas (digamos, como uma fonte 
de relatórios, para aliviar a pressão no servidor origem produção) e não 
tem/não pode licenciar o Active dataguard - nesse caso, SE for viável 
estabelecer-se um conjunto de schemas finito a serem replicadas, antes de ir 
pras soluções pagas, vc pode tentar Avaliar a possibilidade de usar Basic 
Replication, no 11g ela é feita via snapshots/views materializadas e já Suporta 
LOBs, cfrme 
http://www.orafaq.com/wiki/Advanced_Replication_FAQ#What_is_the_difference_between_BASIC_and_ADVANCED_replication.3F
 e a Documentação indicam... 
 
 E se mesmo isso não atender, aí quando for validar as soluções pagas, ainda no 
caso de ser possível se estabelecer um conjunto finito de tabelas a replicar, 
não deixe de considerar o Goldengate com replicação de logs, 
http://gavinsoorma.com/2014/05/goldengate-change-data-capture-and-replication-of-blob-and-clob-data/
 traz um pequeno exemplo...
 
  []s
  
Chiappa

Re: [oracle_br] Delete de Milhões de linhas

[alexssandro0...@yahoo.com.br [oracle_br]]

Ops... 

 Pessoal, esqueci de colocar aqui a versão do Oracle.
 11.0.2.0.4 Standard Edition.
 

 Desta forma minhas opções são limitadas.
 Sem particionamento etc..

Re: [oracle_br] Delete de Milhões de linhas

[Andre Santos andre.psantos...@gmail.com [oracle_br]]

Alex

Você não pode particionar essa tabela pela coluna de data (ano/mês)?
Se puder, o processo ficará muito mais simples e leve com truncate (ou
drop) de partições.

[ ]

André


Em 16 de julho de 2015 10:52, alexssandro0...@yahoo.com.br [oracle_br] <
oracle_br@yahoogrupos.com.br> escreveu:

>
>
> Olá pessoal!!
>
>
> Pessoal, tenho que deletar  aproximadamente 300 milhões de linhas de estão
> em 10 tabelas.
>
>
> Isso é para uma rotina que iremos implantar aqui que é de fazer o backup
> dos dados antigos de auditoria e remover os dados do banco, de forma
> mensal.
>
>
> Inicialmente eu fiz um insert a partir de select, porém este processo é
> muito demorado e tem indisponibilidade de ambiente.
>
>
> Então resolvi aparar os dados com um bulk delete, conforme abaixo:
>
>
> "declare
>
>
>  cursor c1 is SELECT ROWID FROM OWNER.tableA  where cod_xxx in(select
> cod_xxx from OWNER.tableB aa join OWNER.tableC ar on(aa.cod_xxx =
> ar.cod_xxx) where trunc(COLUNM_DATA) < (select sysdate -
> TO_YMINTERVAL('01-00') from dual));
>
>
>  type rows_del is table of rowid index by binary_integer;
>
>
> dell rows_del;
>
> row_commit pls_integer := 1;
>
> rowcount pls_integer := 0;
>
>
> begin
>
> open c1;
>
>  fetch c1 BULK COLLECT INTO dell limit 20;
>
>   for vqtd IN 1 .. dell.count loop
>
>
>  begin
>
>delete from OWNER.tableA where rowid = dell(vqtd) and rownum <
> row_commit;
>
>
>
> exception when others then
>
> continue;
>
> exit when c1%notfound;
>
>  end;
>
>   rowcount := rowcount + sql%rowcount;
>
>
>
>   if sql%rowcount = 0 then
>
>  commit;
>
>  exit;
>
>   end if;
>
> commit;
>
> end loop;
>
> close c1;
>
> end;
>
> /"
>
>
> Desta forma gostaria de saber se está é a melhor forma de fazer este
> delete, e qual o impacto do limit do bulk delete ser de 20 registros.
>
>
> Sendo que o ambiente aqui tem 250GB de memória total e o Oracle está
> utilizando 150GB
>
>
> OBS: meu gestor quer que o delete seja feito em no máximo 2 madrugadas.
>
>
>
>  
>

[oracle_br] Delete de Milhões de linhas

[alexssandro0...@yahoo.com.br [oracle_br]]

Olá pessoal!!
 

 Pessoal, tenho que deletar  aproximadamente 300 milhões de linhas de estão em 
10 tabelas.
 

 Isso é para uma rotina que iremos implantar aqui que é de fazer o backup dos 
dados antigos de auditoria e remover os dados do banco, de forma mensal. 
 

 Inicialmente eu fiz um insert a partir de select, porém este processo é muito 
demorado e tem indisponibilidade de ambiente.
 

 Então resolvi aparar os dados com um bulk delete, conforme abaixo:
 

 "declare
 

  cursor c1 is SELECT ROWID FROM OWNER.tableA  where cod_xxx in(select cod_xxx 
from OWNER.tableB aa join OWNER.tableC ar on(aa.cod_xxx = ar.cod_xxx) where 
trunc(COLUNM_DATA) < (select sysdate - TO_YMINTERVAL('01-00') from dual));
 

  type rows_del is table of rowid index by binary_integer;
 

 dell rows_del;
 row_commit pls_integer := 1;
 rowcount pls_integer := 0;
 

 begin
 open c1;
  fetch c1 BULK COLLECT INTO dell limit 20;
   for vqtd IN 1 .. dell.count loop
 

  begin
delete from OWNER.tableA where rowid = dell(vqtd) and rownum < 
row_commit;
  
 exception when others then 
 continue;
 exit when c1%notfound;
  end;
   rowcount := rowcount + sql%rowcount;
  
   if sql%rowcount = 0 then
  commit;
  exit;
   end if; 
 commit;
 end loop;
 close c1;
 end;
 /"
 

 Desta forma gostaria de saber se está é a melhor forma de fazer este delete, e 
qual o impacto do limit do bulk delete ser de 20 registros.
 

 Sendo que o ambiente aqui tem 250GB de memória total e o Oracle está 
utilizando 150GB
 

 OBS: meu gestor quer que o delete seja feito em no máximo 2 madrugadas.  
  

[oracle_br] Re: Replicação no Oracle(Oracle Streams)

[alexssandro0...@yahoo.com.br [oracle_br]]

Obrigado Chiappa pelas tuas dicas, irei configurar aqui um ambiente ambiente de 
teste com ORACLE MANUAL STANDBY. Pois o strems não comporta lob, e nosso 
ambiente aqui utiliza bastante este tipo de dado.  

 Caso o mesmo não supra a nossa necessidade, o jeito é partir para as 
ferramentas pagas.