Sabe quando você faz aquela trapalhada épica, dá um UPDATE na tabela sem WHERE e ainda estava tão confiante que mandou um COMMIT logo em seguida? Pois é. Acontece. E quando o usuário altera ou apaga um monte de registros que não deveria? A primeira reação é ligar pro DBA, pedir pra restaurar o último backup, rezar pro RMAN... Mas nem sempre precisa chegar a tanto.
Existe um caminho mais simples — em muitos casos, muito mais fácil: o Flashback Query.
Mesmo sendo um recurso já bastante conhecido, vale a pena relembrar. Com ele, o Oracle consegue reconstruir o estado anterior das linhas usando os dados armazenados no UNDO. Em outras palavras, ele “volta no tempo” aplicando as mudanças inversas registradas ali.
E o melhor: até onde sei, esse recurso vem habilitado por padrão e é coisa antiga, então dificilmente você vai ter complicações para utilizá-lo.
Vamos direto ao ponto. Abaixo estão duas queries para comparação:
Uma consulta normal, com os resultados atuais, e outra usando Flashback Query para pegar os dados de 30 minutos atrás.
Você pode testar isso no seu próprio banco criando uma tabela, inserindo alguns registros, anotando o horário em que removeu os dados e depois executando o SELECT com o intervalo anterior.
Exemplo do uso
--Normal query with current results
SELECT *
FROM PEDIDO
WHERE ID_PEDIDO = 3487;
--Flashback query retrieving results from 30 minutes ago
SELECT *
FROM PEDIDO AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '30' MINUTE)
WHERE ID_PEDIDO = 3487;
Ótimo. Agora quero recuperar os registros que eu apaguei. Também é fácil.
Fazendo um insert com base nos dados de 30 minutos atrás
INSERT INTO PEDIDO
SELECT *
FROM PEDIDO AS OF TIMESTAMP (SYSTIMESTAMP - INTERVAL '30' MINUTE)
WHERE ID_PEDIDO = 3487;
COMMIT;
É SÓ ISSO MESMO.
O artigo poderia acabar aqui. Caso você esteja um pouco mais curioso, pode continuar lendo o conteúdo abaixo. Você só vai conseguir seguir na parte abaixo se tiver privilégios de DBA.
Ver os parâmetros
Ah, legal. Agora quero saber qual o tempo de retenção (teórico) que eu tenho configurado:
SHOW PARAMETER undo_retention;
Ele vai te mostrar o valor em segundos. No meu caso está em 86.400 segundos, que significa 1.440 minutos ou 24 horas. É importante lembrar que esse valor é teorico. Por padrão, sempre que o banco precisar de espaço de undo, ele não vai respeitar o tempo de retenção informado, exceto se você tiver informado que ele deve garantir esse tempo. Para saber, vamos a seguinte query:
SELECT tablespace_name, retention FROM dba_tablespaces WHERE contents = 'UNDO';
✅ Se estiver GUARANTEE, o tempo de retenção é respeitado obrigatoriamente.
⚠️ Se estiver NOGUARANTEE, o Oracle pode sobrescrever os dados de undo antes do tempo, se precisar de espaço.
Garantir a retenção
Se quiser garantir que o Flashback Query funcione sempre até o limite configurado:
ALTER TABLESPACE undotbs1 RETENTION GUARANTEE;
Eu não recomendaria fazer isso, porque se ele precisar respeitar o tempo de retenção e precisar de espaço de undo ao mesmo tempo e não encontrar, o banco vai estourar erro.
Ajustar o tempo de retenção
Aqui neste exemplo estamos colocando um tempo de retenção de 3600 segundos, ou seja, 60 minutos.
ALTER SYSTEM SET undo_retention = 3600;
É isso, pessoal. Não recomendo mexer nesses parâmetros, mas recomendo aproveitar a possibilidade do flashback query sempre que tiver uma situação simples para resolver. O Flashback Query é rápido e prático, mas não substitui uma estratégia de backup e recovery completa. Ele é mais útil para ‘pequenos acidentes’.”
Top comments (0)