Menu de navegação

[GuiSalParticipante]

Pessoal, é possível remover o auto commit do oracle em alguma versão?
Preciso atualizar bancos antigos e o commit faz a tarefa se tornar muito mais demorada.
Exemplo:
Fazer o rollback funcionar quando eu altero a estrutura de uma tabela.

desde já agradeço

[rmanParticipante]

@GuiSal

Existe a possibilidade de alterar o comportamento do COMMIT, segue o artigo abaixo:

http://victor-dba.blogspot.com.br/2012/ … acoes.html

Mas não entendi muito bem o que você quer fazer. Alterar a estrutura de tabela é DDL e não DML, até onde eu sei, não se commita explicitamente uma DDL.

[Douglas Paiva de SousaParticipante]

Remover o commit quando se faz alguma transação do tipo DDL (create, alter, drop e etc) é impossivel, pois todas as vezes que esse tipo de operação acontece, implicitamente o Oracle precisa alterar suas tabelas internas e para isso precisa garantir a consistencia do dicionário de dados.

Transações do tipo DML (insert, update, delete, merge) o controle do commit é por conta do usuário, porém NÃO executar o commit durante um logo tempo pode se tornar um problema, pois a tablespace de UNDO vai precisar ter espaço para suportar todas as transações que não foram commitadas além de provocar uma certa sobrecarga no log_buffer.

Att,

[fsitjaParticipante]

Também acho que não ficou bem claro o que você quer fazer. Mas se sua aplicação está fazendo transações no mesmo schema que é o owner das tabelas, e portanto fazendo os DDLs na mesma sessão — disparando os commits implícitos, impossíveis de evitar — você herdou um problema de boas práticas de desenvolvimento no banco de dados.

Procedures, packages e demais programas que realizam transações deveriam estar num schema separado do schema dono das tabelas (via grants de select, insert, update, delete), e mais, esses programas devem ser chamados por outro(s) usuário(s) que não são owners de aplicação (apenas com grant execute).

[GuiSalParticipante]

Desculpa vou tentar ser mais claro.

Quando tenho comandos diferentes de insert, delete e update, o rollback não funciona e tenho que detectar o problema da atualização do banco de dados e depois restaurar o banco para realizar novamente a atualização levando muito tempo.

Por quê? hoje normalmente os commits são realizado no final de cada beta, então é rodado um script com uma serie de alterações e depois é realizado o commit, mas se alguma coisa deu errado o rollback só defazerá as alterações de insert, delete e update.

Gostaria que o rollback voltasse ao estado que o banco de dados estava no momento que abri transação. Quando rodo o script normalmente o
sitema está fora do ar.

Desde já agradeço as resposta.

[rmanParticipante]

@GuiSal

Realmente o ROLLBACK não irá desfazer nenhum comando DDL, apenas do DML.

Sugestão divida os comandos em 2 scripts, DDL primeiro depois DML, se tudo deu certo no DDL execute as DML.

Outro ponto a ser analisado, por que geralmente da erro nos scripts? Tente entender para poder evitar…

Por segurança, efetue o backup antes de iniciar a atualização. Esse procedimento é as vezes desprezado, e que pode evitar complicações.

[GuiSalParticipante]

Seria muito bom se tivesse essa opção.

[felipegParticipante]

Olá,

Partindo do princípio de conhecer a arquitetura do banco, não faria o mínimo sentido ter esta opção.

Basicamente um DDL é composto de:
BEGIN
COMMIT;
COMANDO DDL;
COMMIT;
EXCEPTION
WHEN OTHERS THEN
ROLLBACK;
RAISE;
END;

Por que o primeiro commit?
Basicamente, para dar um “OK” em qualquer transação que a própria sessão tenha deixado em aberto, imagine o seu DDL lockado por causa de um delete que você não commitou?
E também para garantir a integridade das informações até aquele ponto.

E o segundo commit?
Basicamente para salvar as alterações no dicionário de dados, afinal, você acaba de alterar a estrutura de um objeto que pode ser compartilhado por mais sessões, que podem inseriralterardeletar dados e quem podem, caso sua alteração não seja transparente, comprometer a integridade das informações.

O problema aqui não está no banco e sim na forma como estes scripts ou como a aplicação é tratada, na minha humilde opinião, o melhor caminho é separar as alterações (DMLDDL) sempre que possível.

A única maneira de você fazer isso dentro de uma mesma sessão é usando o Autonomous Transaction (que na verdade abre uma outra sessão), mas, novamente, não recomendo.

Atenciosamente,
Felipe.

[Autor]

Posts