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; Espero, nesse artigo, ter ajudado na compreensão do processo de backup gerenciado pelo usuário. Bons tunings, e até a próxima. |
Últimos Artigos
- Serviços de Upgrade e Migração
- Recuperação de datafiles e tablespaces
- Oracle Real Application Cluster(RAC)
- Oracle Data Guard
- Monitorando Tablespace Temporária
- Monitorando o progresso do RMAN
- Monitorando a utilização da tablespace de UNDO
- Linux
- Habilitando Archived Logs
- Cursores abertos por uma determinada sessão
Backup Gerenciado pelo Usuário
|