Pular para o conteúdo

Gerenciamento de UNDO em Banco de Dados Oracle: Tudo que Você Precisa Saber

Gerenciamento de UNDO

Bom dia meus caros, tudo bem com vocês?

Hoje irei explanar sobre um assunto muito importante em administração de Bando de Dados Oracle: Gerenciamento de UNDO. Vamos lá?

#Gerenciando Segmentos de Undo#

*Visão Geral

  • Sempre que um dado é alterado, o Oracle armazena num segmento de undo (ou rollback) a imagem antiga deste dado.
  • Os segmentos de Undo são utilizados para rollback de transações, consultas consistentes e operações de flashback.
  • As alterações em dados de usuários (DML) utilizam-se dos segmentos de undo normais.
  • As alterações em estruturas (DDL) utlizam o segmento de rollback existente na tablespace SYSTEM.
  • Se o gerenciamento automático de Undo (UNDO_MANAGEMENT=AUTO) estiver sendo usado, o Oracle cria e gerencia os segmentos de undo automaticamente.
  • Se o gerenciamento for manual, os segmentos precisam ser criados e gerenciados pelo DBA (comandos CREATE ROLLBACK SEGMENT).
  • Um segmento de Undo pode ser compartilhado por várias transações ao mesmo tempo.
  • Uma transação estará sempre restrita a um único segmento de undo.
  • O cabeçalho de um segmento de Undo contém informações sobre as transações ativas naquele segmento.

#Utilidades dos Segmentos de Undo#

*Rollback de Transação

  • Quando uma sessão executa um ROLLBACK, o Oracle regrava todas as imagens de dados alterados pela transação e salvas no segmento de undo de volta para seus locais originais.
  • Se uma sessão termina de maneira anormal, o Oracle faz o ROLLBACK automaticamente.
  • Se a instância falhar enquanto transações estão em curso, os dados dos segmentos de Undo também serão usadas na recuperação da instância, para efetuar o ROLLBACK destas transações.

*Flashback

  • A partir do Oracle 9i foram introduzidos recursos para consultas de dados como eram no passado (por exemplo, para ver os dados de uma tabela como eram há uma hora atrás). Este tipo de consulta é chamado de Flashback Query.

*Consistência de Leitura

  • Se uma sessão consulta um dado que está sendo alterado por uma transação ativa (não submetida a COMMIT), o Oracle utiliza os dados do segmento de undo para mostrar o valor anterior à alteração.
  • Uma consulta sempre verá todos os dados de seu resultado consistentemente ao momento inicial da leitura.
  • Se isto não for possível (por falta de espaço suficiente de Undo por exemplo), a consulta recebe uma mensagem de erro.

#Parâmetros de Inicialização relacionados com Undo#

*UNDO_MANAGEMENT

  • Determina se o gerenciamento de undo será automático ou manual.

    AUTO:
    utiliza tablespace de undo, com segmentos de undo gerenciados pelo Oracle.
    MANUAL: utiliza segmentos de rollback criados pelo DBA numa tablespace comum.

*UNDO_TABLESPACE

  • Nome da tablespace de undo ativa no banco de dados.

*UNDO_RETENTION

  • Tempo de retenção de dados nos segmentos de Undo após o término da transação. Auxilia em leituras consistentes e consultas flashback.

*UNDO_SUPPRESS_ERROS

  • Se este parâmetro for FALSE e o gerenciamento de undo for automático, os comandos de gerenciamento de segmentos de rollback manual receberão erros.
    Para evitar estes erros, define-se este parâmetro como TRUE. (Obsoleto no Oracle 10g).

#Retenção dos dados de Undo#

*Definição

  • Os dados de Undo devem obrigatoriamente ser mantidos até o final da transação. Ao final de uma transação, seus dados em Undo podem ser liberados. Se estes dados estiverem sendo usados por leitura consistentes ou flashback, e forem apagados por outra transação que precisou de espaço, a consulta recebe erro.
  • Para minimizar esta possibilidade, foi introduzido o parâmetro UNDO_RETENTION na versão 9i.
  • Com o UNDO_RETENTION, é possível determinar o tempo (em segundos) após o final da transação que o Oracle tentará manter os dados em Undo.

*Valores

  • No Oracle 9i, se UNDO_RETENTION=0, o recurso está desligado.
  • No Oracle 10g, o Oracle gerencia automaticamente o UNDO_RETENTION, tentando manter os dados o máximo de tempo possível em Undo.
  • Se a tablespace de Undo for autoextensível, UNDO_RETENTION indica a retenção mínima.
  • Se a tablespace de Undo for de tamanho fixo, UNDO_RETENTION só será considerado pelo Oracle se houver retenção garantida.

*Garantia de Retenção

  • No Oracle 9i, o UNDO_RETENTION só será respeitado se houver espaço suficiente na tablespace de Undo.
  • Uma transação procura espaço em Undo livre ou com dados já expirados.
  • Se não encontrar, pode “roubar” o espaço mesmo que o tempo de retenção não tenha terminado.
  • No Oracle 10g, é possível determinar a garantia de retenção: Retenção Sem Garantia: padrão, funcionamento igual ao Oracle 9i.
  • Retenção Garantida: se a transação não encontrar espaço com dados já expirados, ela recebe erro.
  • A garantia de retenção é definida pelos seguintes comandos:

CREATE TABLESPACE nome [RETENTION GUARANTEE|NOGUARANTEE];

ALTER TABLESPACE nome [RETENTION GUARANTEE|NOGUARANTEE];

ALTER TABLESPACE UNDOTBS1 RETENTION GUARANTEE;

#Informações Sobre Segmentos de Undo/Rollback#

  • Para obter informações sobre todos os segmentos de rollback no banco de dados, consulte a view

DBA_ROLLBACK_SEGS.

#Problemas mais Comuns com Undo#

Espaço Insuficiente Para Transações

  • A transação recebe erro por não haver espaço suficiente no segmento de undo.

Causas Possíveis

  • Se o gerenciamento for automático, a tablespace de Undo pode não ser grande o suficiente, ou ainda podem existir sessões consumindo muito espaço de undo anormalmente. Verifique as transações
    consumindo muito undo e considere aumentar a tablespace.
  • Se o gerenciamento for manual, além das causa acima ainda é possível que os segmentos de rollback criados sejam pequenos demais ou não estejam sendo limpos de maneira adequada. Verifique as configurações de segmentos de rollback (quantidades e tamanhos), e considere utilizar o gerenciamento automático.

Erro de Consistência na Leitura

  • Uma consulta recebe erro “snapshot too old” (ORA-01555) porque estava consultando dados em segmentos de undo (leitura consistente), e estes dados foram apagados por uma transação que precisou de espaço.
    Causas Possíveis
  • Segmentos de undo/rollback muito pequenos. Aumente os segmentos.
  • Consultas muito longas. Ajuste as consultas.
  • Verifique a possibilidade de ajustar o UNDO_RETENTION e RETENTION GUARANTEE.

Obrigado pela leitura e Bons estudos!

Quão útil foi este post ?

Clique em uma estrela para classificar o post

nota média 5 / 5. Contagem de votos: 4

Sem votos ! Seja o primeiro a classificar !

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

plugins premium WordPress