Undo Overview

Quando alguma transação modifica algum dado, ou insere algo novo, o Oracle copia o valor original, o valor antes da modificação. Essa cópia é chamada de undo data e serve para mais de um objetivo:

  • Para desfazer(undo) uma transação quando é executado um rollback. Isso também pode ser realizado como parte de uma operação de recovery.
  • Consistência de leitura. O Oracle, como qualquer outro banco relacional, aplica o ACID. O C é de consistency. Isso indica que os usuário terão consistência nas suas leituras. Um exemplo é uma consulta que demora vários minutos ou horas, e nesse meio tempo os dados acessados são modificado por outras sessões. O Oracle pode retornar os dados como eram no inicio da leitura por utilizar o undo. E também o isolamento, em que os dados ainda que não teve um COMMIT não serão vistos por outras sessões, mas sim, essas outras sessões verão os dados antigos.
  • Para realizar operações do Oracle chamado flashback, como o Oracle Flashback Query e o Flashback Table.

Então, ao fazer um SELECT, se o Oracle encontrar algum block que foi modificado desde que o SELECT começou, o Oracle vai buscar os dados antigos no UNDO e assim efeturar um rollback, para esta sessão ter acesso apenas aos dados antigos, como eles estavam no inicio do SELECT.

No UPDATE, será necessário um block de segmento de UNDO. Isso é necessário pois o valor anterior do que será atualizado com o UPDATE possa ser guardado, tanto para efetuar um rollback, como também para promover consistência e isolamento. Além disso, toda essa operação também irar gerar REDO, que é o log de alterações de todos os dados do banco. Alterações no UNDO também gera REDO! No REDO irá o rowid da linha e também os novos valores. Os novos valores também serão atualizados no buffer cache.

Já no INSERT é um pouco mais simples. Pois só teremos o ROWID no UNDO, se for necessário desfazer a alteração, é somente executar o DELETE com esse ROWID.

Já no DELETE, toda a linha é armazenada no UNDO, caso seja necessário executar um rollback, ou também um FLASHBACK. Um INSERT gera bem menos UNDO do que um DELETE!

Então, para efetuar um rollback de um UPDATE, outro UPDATE será executado nas mesmas linhas, utilizando os valores antigos que estão no UNDO. Já para executar um rollback de um DELETE, será executado um INSERT com a linha que se encontra no UNDO. E por último, para executar rollback de um INSERT, será feito um DELETE com o rowid que se encontra no UNDO.

Então, o rollback, nada mais é que outra instrução DML para reconstruir como os dados eram antes da transação. Por isso, muitas vezes o rollback demora o mesmo tempo que a transação levou para modificar os dados, ou até mais. É por isso também que o COMMIT é quase que instantâneo. Os dados já foram modificados no buffer cache. Os mesmos dados já se encontra no log buffer. Quando você executa o COMMIT é apenas o tempo do LGWR escrever o conteúdo do log buffer para o redo log. O DBWR não faz nada nesse ponto.

Undo data é salvo no undo tablespace. Só podemos ter um único tablespace ativo por instância, esse tablespace ativo será o que esta configurado no parâmetro UNDO_TABLESPACE. Mas esse undo tablespace pode ter mais de um datafile.

Uma transação utiliza um único segmento de undo, esse segmento pode aumentar de tamanho conforme a necessidade, por adicionar novos extents. O Oracle pode usar o mesmo segmento para mais de uma transação, mas de movo geral ele tenta não fazer isso.

Opcionalmente, podemos configurar o temporary undo, para armazenar o undo de temporary tables. Se não tiver configurado o temporary undo, o Oracle vai armazenar o undo das temporary tables junto com o undo de outros objetos, e assim, vai gerar redo das temporary tables sem necessidade.

Para ativar o temporary undo, é somente configurar o parâmetro TEMP_UNDO_ENABLED para TRUE. Assim o temporary undo, undo de temporary table, será armazenado no temporary tablespace, e dessa forma, esse temporary undo não irá gerar redo log, melhorando assim a retenção no undo tablespace, reduzindo o redo gerado e outro benefício é possibilitar executar um DML em tabelas temporárias em um active data guard. Mas lembre-se que talvez seja necessário aumentar o tamanho do temporary tablespace.

Para finalizar, devemos entender como o Oracle caracteriza diferente o UNDO. O undo pode ter o status de active, que é o undo de uma transação ainda não finalizada, que ainda não teve o COMMIT ou ROLLBACK. Pode ter o status de expired, em que o Oracle não tem mais obrigação de manter os dados por que a transação já finalizou, seja por COMMIT ou ROLLBACK. E temos mais um status que seria o de unexpired, onde a transação já finalizou, mas o Oracle ainda tenta manter esses dados para a consistência de leitura de um SELECT que esta demorando para finalizar.

Então, quando o Oracle caracteriza um undo como expired, ou inactive, esse espaço do undo tablespace fica livre para outra transação utilizar. Então tudo funciona de forma circular, o undo utilizado fica depois livre para outra transação. O UNDO active nunca pode ser sobrescrito! Então, o undo tablespace tem que ser bem dimensionado para não faltar espaço para as transações ativas. Se não tiver espaço livre o suficiente na undo tablespace, a transação pode encontrar uma falha e não conseguirá completar a execução do DML. O formato circular o UNDO é descrito na imagem abaixo, juntamente com a adição de novos extents conforme a transação precisa de mais espaço.

Nos próximos posts iremos ver em mais detalhes a respeito de UNDO.

Meu nome é Tércio Costa, sou formado em Ciências da Computação pela UFPB, tenho a certificação OCA 12c, Oracle SQL Expert e OCP PL/SQL, mantendo um blog reconhecido pela OTN(oraclepress.wordpress.com), no qual também publico artigos técnicos no portal OTN, no portal http://www.profissionaloracle.com.br/gpo e na revista SQL Magazine. Além de tudo isto sou um Oracle ACE por estar sempre contribuindo para a comunidade com um bom nível de expertise.

Marcado com: , , , ,
Publicado em Administração, Undo

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.

Esse Blog é reconhecido pela
Sou um
Certificações
Sou articulista

Clique para seguir este blog e receber notificações via email de novos posts.

Tércio Costa

Tércio Costa

Meu nome é Tércio Costa, sou formado em Ciências da Computação pela UFPB, tenho a certificação OCA 12c, Oracle SQL Expert e OCP PL/SQL, mantendo um blog reconhecido pela OTN(oraclepress.wordpress.com), no qual também publico artigos técnicos no portal OTN, no portal http://www.profissionaloracle.com.br/gpo e na revista SQL Magazine. Além de tudo isto sou um Oracle ACE por estar sempre contribuindo para a comunidade com um bom nível de expertise.

Links Pessoais

Serviços verificados

Visualizar Perfil Completo →

Total de Visualizações da Página
  • 161.530 Visualizações
%d blogueiros gostam disto: