4Dados Consultoria & Suporte

Oracle Partner Network

Backup Gerenciado pelo Usuário

Neste artigo abordaremos os backups gerenciados pelo usuário.

Os processos de backup e recovery gerenciados pelo usuário não utilizam o RMAN. São utilizados comandos do próprio sistema operacional para realizar o backup e o recover.

Existem dois tipos de backup gerenciados pelo usuário, os realizados com o banco de dados ABERTO e o FECHADO.

Referimos ABERTO quando o database terá seu backup realizado com o banco em funcionamento normal, ou seja, com os usuário acessando os dados normalmente. Obrigatoriamente precisa estar em ARCHIVE LOG.

 

O FECHADO ocorre quando o database precisa sofrer SHUTDOWN para ser realizado.

Em ambos, é necessário que tenhamos conhecimento da estrutura dos arquivos, de quais são eles, e onde estão localizados.

Algumas visões que podem nos auxiliar nessa descoberta:

Como estamos admitindo que nosso ambiente não tem downtime (24/7), ou seja, eu não posso fazer shutdown da base de dados, faremos o backup com o banco de dados ABERTO.

O primeiro requesito para efetuar um backup open, é que o banco esteja no modo ARCHIVED LOG. O artigo publicado anteriormente mostra como realizar o procedimento de start dos archives.

Os comandos para o backup open, se restringem aos seguintes:

Lembre-se que, no Linux/Unix, o commando de cópia é o “cp” e não o COPY, então, a sintaxe de cópia ficaria um pouco diferente:

No nosso exemplo, os comandos ficariam da seguinte forma:

Não é aconselhado colocar todas as tablespaces em BEGIN BACKUP, faça o processo de forma individual.

Depois de feito o processo de cópia em todas as tablespaces(incluindo SYSTEM e UNDO), emita o comando:

O comando acima irá fazer o switch dos redologse efetuará o arquivamento dos mesmos.

Pronto, você já tem a cópia de todos os seus datafiles.

Agora vamos imaginar a pior situação possível: TODOS OS SEUS DATAFILES SE PERDERAM, o disco onde eles estavam apresentou problemas, você trocou o disco e particionou da mesma forma que estava anteriormente com os mesmos paths.

Não esqueça que estamos nos referindo apenas aos DATAFILES, para a recuperação. Os CONTROLFILES estavam multiplexados em discos diferentes e seu ARCHIVE estava em um disco diferente do que apresentou o problema. Os REDOLOGS, infelizmente, estavam no mesmo disco dos DATAFILES, portanto, também foram para o espaço.

Mas nem tudo está perdido.

Para fazer a recuperação, proceda da seguinte forma:

01. Restaure todos os DATAFILES copiados no processo de BEGIN/END BACKUP para o disco novo utilizando comandos do S.O. Valide os paths dos arquivos. Colocar os mesmos irá diminuir sua dor de cabeça com operações de rename.

02. Inicie o banco em modo MOUNT

03. Agora você precisa descobrir até onde pode efetuar seu recover, para isso você utilizará a consulta:

A consulta acima faz um select na tabela de V$LOG e retorna informação refente ao redolog que ainda não foi arquivado “NO”. Significa dizer que VOCÊ PODE RECUPERAR ATÉ O FIRST_CHANGE# IMEDIATAMENTE ANTERIOR. Perceba que também poderei recuperar até um momento anterior ao timestamp 14/02/2006 às 13:19:39.

04. Execute o commando de recuperação do banco até o momento imediatamente anterior ao crash do disco:

Serão processados todos os arquivos de log até o CHANGE 1545222. Em seguida você receberá uma mensagem semelhante:

O CHANGE# 1545223 NÃO FOI ARQUIVADO, ele ainda estava em REDOLOG, e como não estava multiplexado nós o perdemos.

05. Abra o banco com RESETLOGS

E, finalmente, você conseguiu recuperar seu banco de dados até um instante muito próximo do crash.

No nosso exemplo mostramos como fazer a recuperação através do CHANGE#, mas você também pode fazer a recuperação utilizando a data/hora. Em alguns casos, fica difícil você identificar qual o CHANGE da transação que atualizou os registros, mas com certeza será fácil identificar a data/hora, nesses casos utilize:

Como boas práticas, tenha sempre em mente:

01. Tenha no mínimo DOIS CONTROLFILES em devices diferentes;
02. Tenha no mínimo DOIS MEMBROS EM CADA GRUPO DE REDOLOG, em devices diferentes;
03. Coloque seus ARCHIVED LOGS em devices diferentes dos datafiles.

Espero, nesse artigo, ter ajudado na compreensão do processo de backup gerenciado pelo usuário.

Bons tunings, e até a próxima.