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 10000 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 := 10000;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]"
<oracle_br@yahoogrupos.com.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:0::::P11_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 #yiv7649620478 #yiv7649620478 -- #yiv7649620478ygrp-mkp {border:1px
solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv7649620478
#yiv7649620478ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv7649620478
#yiv7649620478ygrp-mkp #yiv7649620478hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv7649620478 #yiv7649620478ygrp-mkp #yiv7649620478ads
{margin-bottom:10px;}#yiv7649620478 #yiv7649620478ygrp-mkp .yiv7649620478ad
{padding:0 0;}#yiv7649620478 #yiv7649620478ygrp-mkp .yiv7649620478ad p
{margin:0;}#yiv7649620478 #yiv7649620478ygrp-mkp .yiv7649620478ad a
{color:#0000ff;text-decoration:none;}#yiv7649620478 #yiv7649620478ygrp-sponsor
#yiv7649620478ygrp-lc {font-family:Arial;}#yiv7649620478
#yiv7649620478ygrp-sponsor #yiv7649620478ygrp-lc #yiv7649620478hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv7649620478
#yiv7649620478ygrp-sponsor #yiv7649620478ygrp-lc .yiv7649620478ad
{margin-bottom:10px;padding:0 0;}#yiv7649620478 #yiv7649620478actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv7649620478
#yiv7649620478activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv7649620478
#yiv7649620478activity span {font-weight:700;}#yiv7649620478
#yiv7649620478activity span:first-child
{text-transform:uppercase;}#yiv7649620478 #yiv7649620478activity span a
{color:#5085b6;text-decoration:none;}#yiv7649620478 #yiv7649620478activity span
span {color:#ff7900;}#yiv7649620478 #yiv7649620478activity span
.yiv7649620478underline {text-decoration:underline;}#yiv7649620478
.yiv7649620478attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv7649620478 .yiv7649620478attach div a
{text-decoration:none;}#yiv7649620478 .yiv7649620478attach img
{border:none;padding-right:5px;}#yiv7649620478 .yiv7649620478attach label
{display:block;margin-bottom:5px;}#yiv7649620478 .yiv7649620478attach label a
{text-decoration:none;}#yiv7649620478 blockquote {margin:0 0 0
4px;}#yiv7649620478 .yiv7649620478bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv7649620478
.yiv7649620478bold a {text-decoration:none;}#yiv7649620478 dd.yiv7649620478last
p a {font-family:Verdana;font-weight:700;}#yiv7649620478 dd.yiv7649620478last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv7649620478
dd.yiv7649620478last p span.yiv7649620478yshortcuts
{margin-right:0;}#yiv7649620478 div.yiv7649620478attach-table div div a
{text-decoration:none;}#yiv7649620478 div.yiv7649620478attach-table
{width:400px;}#yiv7649620478 div.yiv7649620478file-title a, #yiv7649620478
div.yiv7649620478file-title a:active, #yiv7649620478
div.yiv7649620478file-title a:hover, #yiv7649620478 div.yiv7649620478file-title
a:visited {text-decoration:none;}#yiv7649620478 div.yiv7649620478photo-title a,
#yiv7649620478 div.yiv7649620478photo-title a:active, #yiv7649620478
div.yiv7649620478photo-title a:hover, #yiv7649620478
div.yiv7649620478photo-title a:visited {text-decoration:none;}#yiv7649620478
div#yiv7649620478ygrp-mlmsg #yiv7649620478ygrp-msg p a
span.yiv7649620478yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv7649620478
.yiv7649620478green {color:#628c2a;}#yiv7649620478 .yiv7649620478MsoNormal
{margin:0 0 0 0;}#yiv7649620478 o {font-size:0;}#yiv7649620478
#yiv7649620478photos div {float:left;width:72px;}#yiv7649620478
#yiv7649620478photos div div {border:1px solid
#666666;height:62px;overflow:hidden;width:62px;}#yiv7649620478
#yiv7649620478photos div label
{color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv7649620478
#yiv7649620478reco-category {font-size:77%;}#yiv7649620478
#yiv7649620478reco-desc {font-size:77%;}#yiv7649620478 .yiv7649620478replbq
{margin:4px;}#yiv7649620478 #yiv7649620478ygrp-actbar div a:first-child
{margin-right:2px;padding-right:5px;}#yiv7649620478 #yiv7649620478ygrp-mlmsg
{font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv7649620478
#yiv7649620478ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv7649620478
#yiv7649620478ygrp-mlmsg select, #yiv7649620478 input, #yiv7649620478 textarea
{font:99% Arial, Helvetica, clean, sans-serif;}#yiv7649620478
#yiv7649620478ygrp-mlmsg pre, #yiv7649620478 code {font:115%
monospace;}#yiv7649620478 #yiv7649620478ygrp-mlmsg *
{line-height:1.22em;}#yiv7649620478 #yiv7649620478ygrp-mlmsg #yiv7649620478logo
{padding-bottom:10px;}#yiv7649620478 #yiv7649620478ygrp-msg p a
{font-family:Verdana;}#yiv7649620478 #yiv7649620478ygrp-msg
p#yiv7649620478attach-count span {color:#1E66AE;font-weight:700;}#yiv7649620478
#yiv7649620478ygrp-reco #yiv7649620478reco-head
{color:#ff7900;font-weight:700;}#yiv7649620478 #yiv7649620478ygrp-reco
{margin-bottom:20px;padding:0px;}#yiv7649620478 #yiv7649620478ygrp-sponsor
#yiv7649620478ov li a {font-size:130%;text-decoration:none;}#yiv7649620478
#yiv7649620478ygrp-sponsor #yiv7649620478ov li
{font-size:77%;list-style-type:square;padding:6px 0;}#yiv7649620478
#yiv7649620478ygrp-sponsor #yiv7649620478ov ul {margin:0;padding:0 0 0
8px;}#yiv7649620478 #yiv7649620478ygrp-text
{font-family:Georgia;}#yiv7649620478 #yiv7649620478ygrp-text p {margin:0 0 1em
0;}#yiv7649620478 #yiv7649620478ygrp-text tt {font-size:120%;}#yiv7649620478
#yiv7649620478ygrp-vital ul li:last-child {border-right:none
!important;}#yiv7649620478
