Início / dba / Perguntas / 28591
Accepted
Roy
Asked: 2012-11-14 00:36:31 +0800 CST

Quão alto posso definir a retenção de desfazer no Oracle 11gR2

  • 772

É viável definir uma retenção de desfazer muito alta, para permitir consultas de flashback várias semanas atrás no tempo?

Naturalmente, espaço suficiente deve estar disponível nos tablespaces de undo para conter a quantidade de dados de undo necessários. Existem outras limitações das quais devo estar ciente?

O que acontece se não houver espaço suficiente para desfazer disponível? A produção será afetada de alguma forma, ou é apenas uma questão de flashback e reversão sendo limitada (instantâneo muito antigo etc).

Atualizar:

Com uma geração de desfazer típica de pouco menos de 1 GB por dia por instância e até 64 GB de espaço de desfazer por instância, parece viável executar com uma meta de retenção de desfazer de 30 dias. Não?

oracle oracle-11g-r2

2 respostas

  1. Muito alto é um termo relativo que depende da perspectiva. Você pode significar 1 hora, 1 mês, 1 ano, etc. Supondo que você queira dizer algo entre um minuto e um mês, a resposta dependerá de quanto desfazer está sendo produzido e quanto armazenamento você tem disponível. Não vi nada superior a duas semanas.

    O Oracle gerencia automaticamente o espaço de desfazer e diminuirá dinamicamente a retenção abaixo da configuração de retenção de desfazer se as restrições de espaço exigirem. A ressalva a isso é quando o tablespace undo tem retenção garantida.

    O Oracle Database Administrator's Guide cobre todas essas informações em uma página . Aqui estão alguns trechos:

    O Oracle Database ajusta automaticamente o período de retenção de undo com base no tamanho do tablespace de undo e na atividade do sistema. Opcionalmente, você pode especificar um período mínimo de retenção de desfazer (em segundos) definindo o UNDO_RETENTIONparâmetro de inicialização. O impacto exato desse parâmetro na retenção de desfazer é o seguinte:

    • O UNDO_RETENTIONparâmetro é ignorado para um tablespace de undo de tamanho fixo. O banco de dados sempre ajusta o período de retenção de desfazer para obter a melhor retenção possível, com base na atividade do sistema e no tamanho do espaço de tabela de desfazer. Consulte "Ajuste automático da retenção de desfazer" para obter mais informações.

    • Para um tablespace de undo com a AUTOEXTENDopção habilitada, o banco de dados tenta honrar o período mínimo de retenção especificado por UNDO_RETENTION. Quando há pouco espaço, em vez de sobrescrever informações de desfazer não expiradas, o tablespace se estende automaticamente. Se a MAXSIZEcláusula for especificada para um tablespace de undo de extensão automática, quando o tamanho máximo for atingido, o banco de dados poderá começar a sobrescrever informações de undo não expiradas. O tablespace UNDOTBS1 que é criado automaticamente pelo DBCA é autoextensível.

    ...

    Para garantir o sucesso de consultas de execução longa ou operações Oracle Flashback, você pode habilitar a garantia de retenção. Se a garantia de retenção estiver ativada, a retenção mínima de desfazer especificada será garantida; o banco de dados nunca sobrescreve dados de undo não expirados, mesmo que isso signifique que as transações falham devido à falta de espaço no tablespace de undo. Se a garantia de retenção não estiver habilitada, o banco de dados pode sobrescrever undo não expirado quando o espaço estiver baixo, diminuindo assim a retenção de undo para o sistema. Esta opção está desativada por padrão.

    • 3
  2. Best Answer

    Embora eu não tenha tentado, eu tenderia a suspeitar que você terá problemas quando UNDO_RETENTIONexceder o período de tempo que o Oracle mantém seu SCN para mapeamento de carimbo de data/hora. Se não me falha a memória, isso é aproximadamente 1 semana (bem, se não me falha a memória, foi 1 semana nos dias de 10g e não tenho conhecimento de nada que teria mudado isso em 11.2). Eu tenderia a suspeitar que a Oracle usaria esse mapeamento para determinar quais UNDOsegmentos são antigos o suficiente para serem limpos e que você começaria a encontrar problemas se excedesse esse limite.

    No meu sistema 11.2, por exemplo, posso converter 7 dias atrás para um SCN e depois voltar para um registro de data e hora, mas não 8 dias atrás

      1* select scn_to_timestamp( timestamp_to_scn( systimestamp - 7) ) from dual
SQL> /

SCN_TO_TIMESTAMP(TIMESTAMP_TO_SCN(SYSTIMESTAMP-7))
---------------------------------------------------------------------------
06-NOV-12 01.06.47.000000000 PM

SQL> ed
Wrote file afiedt.buf

  1* select scn_to_timestamp( timestamp_to_scn( systimestamp - 8) ) from dual
SQL> /
select scn_to_timestamp( timestamp_to_scn( systimestamp - 8) ) from dual
                         *
ERROR at line 1:
ORA-08180: no snapshot found based on specified time
ORA-06512: at "SYS.TIMESTAMP_TO_SCN", line 1

    Eu tenderia a suspeitar em meu sistema, portanto, que se eu tentasse reter 8 dias UNDOdaquele Oracle geralmente teria um problema de conformidade. Levaria uma semana para verificar de uma forma ou de outra, mas se eu tivesse que apostar, tenderia a apostar que tentar segurar mais de uma semana UNDOfalharia.

    Mesmo que você pudesse segurar UNDOtanto tempo, formular a consulta de flashback seria um grande desafio, já que você não poderia especificar um carimbo de data/hora. Você poderia potencialmente manter seu próprio mapeamento (mais de longo prazo) entre SCN e carimbo de data/hora escrevendo um trabalho automatizado que capturaria ambos a cada poucos segundos e os manteria por semanas ou meses seguidos e depois especificaria AS OF SCNem suas consultas de flashback. Eu tenderia a esperar que o mais velho UNDOfosse embora, mas pode funcionar.

    • 3

relate perguntas