Muito obrigado pelas respostas. Esse script é utilizado para fazer a criação/alteração de colunas e popular elas com os seus defaults. Como podemos somos uma desenvolvedora de sistemas, as tabelas podem ter os seus mais variados tamanhos, desde algumas linhas linhas até milhares de linhas. Posto isso, o script em si tem basicamente 3 áreas: - criação da coluna na tabela com o seu tipo de dados e tamanho; - caso tenha default, popula a coluna com o valor default; - se a coluna não permitir null, faz o alter table necessário.
Essa mínima parte que passei, fica na segunda seção (popula coluna) onde basicamente é criado um cursor para ler toda a tabela e ir fazendo o update da coluna com o seu valor default. Para isso é usado bulk collect, com commit a cada 50.000 registros. Esse fechamento e abertura de cursor é feito a cada 2 milhões de registros. Como a aplicação desses scripts é feita pelos clientes, não podemos ficar mexendo na área de UNDO. A minha missão agora está sendo otimizar esse script visando o uso da criação de coluna otimizado para Oracle 11g e posteriores, e melhorando o quê for possível para o uso no Oracle 10g e anteriores (sim, ainda temos ao menos um cliente usando Oracle 9). Eu imaginei que não haveria necessidade desse fechamento e reabertura do cursor, salvo em situações aonde a área de undo seja pequena para a quantidade de linhas a serem processadas. Agora, como eu poderia evitar o estouro da undo no caso de estar atualizando milhares de linhas? O BULK COLLECT com o COMMIT não iria evitar esse estouro? Abraço, Roberto Em 6 de fevereiro de 2017 19:53, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > Bem, não sabemos se tem execução multi-usuário nessa parada, mas sim, é > verdade que no RDBMS Oracle a consistência de dados é feita com o SCN exato > do instante em que o SQL começou : então se o tal cursor C_TABLE foi aberto > e começou a processar em 06/02/2017 às 10h:15m:25s digamos, EVIDENTEMENTE > ele vai enxergar os dados e os vai processar EXATAMENTE COMO ESTAVAM em > 06/02/2017 às 10h:15m:25s : isso é uma das maiores e Melhores > características do RDBMS Oracle, se as em 06/02/2017 às 10h:15m:26s foram > deletados dados e a transação foi comitado, AINDA ASSIM o cursor VAI > enxergar os dados como estavam em 06/02/2017 às 10h:15m:25s - isso é > Inestimável para por exemplo extratos do tipo bancário, onde vc TEM que > enxergar os dados precisamente como estavam quando o SQL começou, > Independente das outras operações que eventualmente estejam sendo feitas.... > E sim, tecnicamente falando se um cursor for fechado e reaberto > EVIDENTEMENTE a query a ele associada vai ser re-executada, portanto VAI > ganhar um novo SCN, que será o SCN da re-abertura, sim, e portanto VAI > passar a "enxergar" os dados como estavam no novo SCN.... > PORÉM, nem de longe isso faz sentido, pois há ENORMES chances de > simplesmente essa rotina jogar a INTEGRIDADE DE DADOS lógica pela janela : > digamos que nesse intervalo o mesmo registro que foi lido e inserido sofreu > um DELETE e COMMIT, com a reabertura simplesmente o registro não vai > aparecer pro CURSOR e portanto o INSERT vai estar "inválido"... E coisas do > tipo : então a rotina que vai usar uma técnica do tipo TEM que estar > preparada para fazer validações do tipo : como isso não é simples nem fácil > de fazer, via de regra a recomendação é que realmente se o objetivo é se > fazer uma DATA INGESTION, ie, a fonte de dados deve ser constantemente > consultada para recebermos registros a INSERIR ou ATUALIZAR, o correto é vc > ter a informação de DATA e HORA em que o registro chegou, deixar o cursor > processar até o fim e vc ter a rotina de carga sendo executada em > intervalos curtos, e NÂO a mesma instância de execução ficar constantemente > resetando a query... > E sim também, um efeito colateral de vc re-setar SCN fechando e reabrindo > o Cursor é que UNDO RECORDS de SCNs anteriores são liberados/remarcados > como não usados, sim : mas novamente, não faz sentido se arriscar à > inconsistência de dados com isso, hoje em dia com os recursos modernos (não > apenas o gerenciamento automático de UNDO mas a Possibilidade de ** > múltiplas ** tablespace de UNDO, o conceito de UNDO_RETENTION que é por > TEMPO, etc) ficou impróprio imho.... > > []s > > Chiappa > >
