Opa, boa tarde! Segue um bloco de exemplo. CREATE TABLE teste_update (ID NUMBER, texto CHAR(1))/SELECT * FROM teste_update/SQL> desc teste_update;Name Type Nullable Default Comments ----- ------- -------- ------- -------- ID NUMBER Y TEXTO CHAR(1) Y SQL>
DECLARE CURSOR C IS SELECT ROWID rrowid FROM teste_update; -- se tiver um filtro de data vc pode rodar em parallel TYPE T_C IS TABLE OF C%ROWTYPE; C_Array T_C; BEGIN dbms_application_info.set_action('Abrindo cursor'); OPEN C; -- LOOP dbms_application_info.set_action('Qtd C '||C%ROWCOUNT); FETCH C BULK COLLECT INTO C_array LIMIT 10000; FORALL i IN 1..C_array.count UPDATE teste_update SET texto = '.' WHERE rowid = C_Array(i).rrowid; COMMIT; EXIT WHEN C%NOTFOUND; END LOOP; COMMIT; CLOSE C; EXCEPTION WHEN OTHERS THEN ROLLBACK; RAISE; END;/-- vc pode criar uma procedure com parametro de entrada no bloco acima e depois usar esse bloco abaixo para atualizar em parallel DECLARE L_date DATE := DATE '2013-03-14'; L_date_f DATE := DATE '2013-03-15'; BEGIN -- FOR i IN REVERSE 0..(L_date_f-L_date)-1 LOOP -- dbms_application_info.set_module('BKLOG', TO_CHAR(L_date + i, 'rrrr-mm-dd')); -- BEGIN -- NULL; -- END; -- END LOOP; --END; Espero que ajude. Abs, Em Terça-feira, 17 de Outubro de 2017 14:48, "Ricardo Sá ricardo....@terra.com.br [oracle_br]" <oracle_br@yahoogrupos.com.br> escreveu: Chiappa, De fato foi o que aconteceu, inicialmente o bloco PL/SQL rodou tranquilo, a cada 100.000 linhas, porém aos poucos foi ficando lento, aí eu cancelei.E fiz exatamente o procedimento que você informou neste, ou seja, dropei todos os índices, desabilitei as triggers, em um base StandBy em um DG que mantenho.Estabeleci uma área de UNDO de 256GB de disco e RETENÇÃO de 6 Horas.O processo rodou em 2 horas, em um servidor com recursos inferior ao de produção ( 2 Nodes rodando em storage VNX bem configurado pelo pessoal da DELL-EMC).Depois a recriação dos índices demorou 1 hora rodando com parallel 10, totalizando todo o processo aprox.. 3 horas.Irei rodar este processo em uma janela bem folgada no amb produção , e acredito que irá cair para quase a metade do tempo. De qq forma, muito obrigado pela abordagem. Att.:Ricardo De: oracle_br@yahoogrupos.com.br [mailto:oracle_br@yahoogrupos.com.br] Enviada em: terça-feira, 17 de outubro de 2017 13:55 Para: oracle_br@yahoogrupos.com.br Assunto: Re: RES: [oracle_br] AJUDA - UPDATE MONSTRO TABELA DE 11,5 MILHOES DE LINHAS Ricardo, eu ** discordo ** dessa Abordagem : se o objetivo é máxima Performance o correto e Recomendado é vc ter uma área de ROLLBACK o mais larga Possível e fazer num comando só.... INCLUSIVE, eu imagino que vc Saiba que : a. cada COMMIT *** implica *** em espera por I/O, já que força um sync write b. vc está jogando PELA JANELA a integridade dos dados, pois se vc tinha que processar x linhas, processou menos que isso e deu um COMMIT, se as próximas linhas falharem vc acabou com uma tabela MEio processada e Meio não processada, comofaz ?? c. vc está jogando PELA JANELA o conceito de Transação, que demanda que *** TODOS *** os comandos/operações Tem que ser reversíveis : ora , no mesmo exemplo de cima se vc comitou algumas vezes no LOOP e depois disso houve falha (ou o usuário quer Desfazer a transação) o ROLLBACK SIMPLESMENTE NÃO VAI FUNCIONAR, o que tá comitado comitou, comofaz?? ==> NADA do que eu disse é novidade, há 15 anos o Tom Kyte já falava isso, vide https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:4951966319022 ..... PENSE NESSAS CONSEQUÊNCIAS antes de sair usando essa 'técnica', sim sim ??? imho os procedimentos Performáticos e Seguros de se fazer seriam : 1. Paralelismo : já que é EE vc ** necessariamente ** TEM aí na mão a chance de rodar o DML em parallel-mode e/ou de ler os registros que quer alterar em Parallel... O degree de parallelismo vai depender muito do teu hardware, vc tem que levantar qual tua capacidade em termos de CPU e I/O... ou 2. se a Maioria das linhas vão ser Updateadas, vc faz um INSERT */ APPEND */ num outra tabela , alterando o valor que quer alterar : isso vai diminuir MONSTRUOSAMENTE o tanto de redo log gerado (não vai zerar mas vai Diminuir Enormemente!!) e é mais rápido que UPDATE, veja https://asktom.oracle.com/pls/apex/asktom.search?tag=how-to-update-millions-or-records-in-a-table-200211#6417104879869 para um Exemplo ===> E NECESSARIAMENTE um DML largo é SIM uma Manutenção da tabela, então TEM que ser feita num período de menor carga no sistema, e PREFERENCIALMENTE, com os índices E constraints desabilitados, os quais vc Reconstruiria em parallel depois e com NOVALIDATE nas constraint se possível... []s Chiappa OBS : se por qualquer Motivo não puder fazer Parallel SQL ao menos valide a opção de BULK COLLECT serial.... #yiv5203058549 #yiv5203058549 -- #yiv5203058549ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv5203058549 #yiv5203058549ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv5203058549 #yiv5203058549ygrp-mkp #yiv5203058549hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv5203058549 #yiv5203058549ygrp-mkp #yiv5203058549ads {margin-bottom:10px;}#yiv5203058549 #yiv5203058549ygrp-mkp .yiv5203058549ad {padding:0 0;}#yiv5203058549 #yiv5203058549ygrp-mkp .yiv5203058549ad p {margin:0;}#yiv5203058549 #yiv5203058549ygrp-mkp .yiv5203058549ad a {color:#0000ff;text-decoration:none;}#yiv5203058549 #yiv5203058549ygrp-sponsor #yiv5203058549ygrp-lc {font-family:Arial;}#yiv5203058549 #yiv5203058549ygrp-sponsor #yiv5203058549ygrp-lc #yiv5203058549hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv5203058549 #yiv5203058549ygrp-sponsor #yiv5203058549ygrp-lc .yiv5203058549ad {margin-bottom:10px;padding:0 0;}#yiv5203058549 #yiv5203058549actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv5203058549 #yiv5203058549activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv5203058549 #yiv5203058549activity span {font-weight:700;}#yiv5203058549 #yiv5203058549activity span:first-child {text-transform:uppercase;}#yiv5203058549 #yiv5203058549activity span a {color:#5085b6;text-decoration:none;}#yiv5203058549 #yiv5203058549activity span span {color:#ff7900;}#yiv5203058549 #yiv5203058549activity span .yiv5203058549underline {text-decoration:underline;}#yiv5203058549 .yiv5203058549attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv5203058549 .yiv5203058549attach div a {text-decoration:none;}#yiv5203058549 .yiv5203058549attach img {border:none;padding-right:5px;}#yiv5203058549 .yiv5203058549attach label {display:block;margin-bottom:5px;}#yiv5203058549 .yiv5203058549attach label a {text-decoration:none;}#yiv5203058549 blockquote {margin:0 0 0 4px;}#yiv5203058549 .yiv5203058549bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv5203058549 .yiv5203058549bold a {text-decoration:none;}#yiv5203058549 dd.yiv5203058549last p a {font-family:Verdana;font-weight:700;}#yiv5203058549 dd.yiv5203058549last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv5203058549 dd.yiv5203058549last p span.yiv5203058549yshortcuts {margin-right:0;}#yiv5203058549 div.yiv5203058549attach-table div div a {text-decoration:none;}#yiv5203058549 div.yiv5203058549attach-table {width:400px;}#yiv5203058549 div.yiv5203058549file-title a, #yiv5203058549 div.yiv5203058549file-title a:active, #yiv5203058549 div.yiv5203058549file-title a:hover, #yiv5203058549 div.yiv5203058549file-title a:visited {text-decoration:none;}#yiv5203058549 div.yiv5203058549photo-title a, #yiv5203058549 div.yiv5203058549photo-title a:active, #yiv5203058549 div.yiv5203058549photo-title a:hover, #yiv5203058549 div.yiv5203058549photo-title a:visited {text-decoration:none;}#yiv5203058549 div#yiv5203058549ygrp-mlmsg #yiv5203058549ygrp-msg p a span.yiv5203058549yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv5203058549 .yiv5203058549green {color:#628c2a;}#yiv5203058549 .yiv5203058549MsoNormal {margin:0 0 0 0;}#yiv5203058549 o {font-size:0;}#yiv5203058549 #yiv5203058549photos div {float:left;width:72px;}#yiv5203058549 #yiv5203058549photos div div {border:1px solid #666666;min-height:62px;overflow:hidden;width:62px;}#yiv5203058549 #yiv5203058549photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv5203058549 #yiv5203058549reco-category {font-size:77%;}#yiv5203058549 #yiv5203058549reco-desc {font-size:77%;}#yiv5203058549 .yiv5203058549replbq {margin:4px;}#yiv5203058549 #yiv5203058549ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv5203058549 #yiv5203058549ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv5203058549 #yiv5203058549ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv5203058549 #yiv5203058549ygrp-mlmsg select, #yiv5203058549 input, #yiv5203058549 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv5203058549 #yiv5203058549ygrp-mlmsg pre, #yiv5203058549 code {font:115% monospace;}#yiv5203058549 #yiv5203058549ygrp-mlmsg * {line-height:1.22em;}#yiv5203058549 #yiv5203058549ygrp-mlmsg #yiv5203058549logo {padding-bottom:10px;}#yiv5203058549 #yiv5203058549ygrp-msg p a {font-family:Verdana;}#yiv5203058549 #yiv5203058549ygrp-msg p#yiv5203058549attach-count span {color:#1E66AE;font-weight:700;}#yiv5203058549 #yiv5203058549ygrp-reco #yiv5203058549reco-head {color:#ff7900;font-weight:700;}#yiv5203058549 #yiv5203058549ygrp-reco {margin-bottom:20px;padding:0px;}#yiv5203058549 #yiv5203058549ygrp-sponsor #yiv5203058549ov li a {font-size:130%;text-decoration:none;}#yiv5203058549 #yiv5203058549ygrp-sponsor #yiv5203058549ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv5203058549 #yiv5203058549ygrp-sponsor #yiv5203058549ov ul {margin:0;padding:0 0 0 8px;}#yiv5203058549 #yiv5203058549ygrp-text {font-family:Georgia;}#yiv5203058549 #yiv5203058549ygrp-text p {margin:0 0 1em 0;}#yiv5203058549 #yiv5203058549ygrp-text tt {font-size:120%;}#yiv5203058549 #yiv5203058549ygrp-vital ul li:last-child {border-right:none !important;}#yiv5203058549