Como disse uma certa vez o Portilho, em um curso na Nerv, backup é o que garante seu salário.

Pensando nisso, achei legal fazer um post sobre como garantir seu emprego, quero dizer, como garantir a recuperabilidade do seu Banco, através da mudança de configurações do banco de dados, de verificações do banco e do backup, bem como de testes de restore / recover.

 A -CONFIGURAÇÕES BÁSICAS DO BANCO

Abaixo, duas características básicas de um banco que devem ser configuradas:

 1 – Archivelog

2 – Force logging

Com estas duas características configuradas no seu banco de dados, garanta que haja backups periódicos do seu banco. Por exemplo, é usual que – dependendo do volume de transações do banco, e de seu tamanho, os backups de archive sejam feitos várias vezes ao dia, e diariamente, backup full e / ou backups incrementais.

B – VERIFICAÇÕES PERIÓDICAS

1 – Validate do banco de dados

2 – Validate dos backups

3 – Testes de restore periódicos

E, se o banco for pequeno:

4 – Dumps periódicos dos principais schemas.

*** EXPLICANDO EM DETALHES ***

1- Banco em Archivelog

O banco em modo archive força que todos os redo logs tenham uma cópia off line de seu conteúdo antes de serem sobrescritos. Isto garante a recuperabilidade do banco, além de permitir que backups full sejam feitos “a quente”, ou seja, com o banco ativo.

O modo archive log pode abalar um pouco o desempenho do sistema, mas esta perda de performance é mínima perto da possibilidade de você perder seu emprego, quero dizer, de você perder seus dados em caso de problemas.

Como colocar o banco em archivelog:

 create pfile from spfile;
 shutdown immediate;
 startup mount
 alter database archivelog;
 alter database open;

2 – Banco em Force Logging

Uma maneira de acelerar certas operações do banco de dados é usar a opção nologging, ou seja, gravar as alterações no banco sem gerar gravações nos redos e, consequentemente, nos archives. Porém, fazendo isto a transação se torna irrecuperável.

Para evitar o uso indiscrinado desta opção, especialmente em bancos OLTP, recomendo fortemente que seja alterada a opção force logging para “YES” no seu banco de dados. Assim, mesmo que um desenvolvedor mais espertinho acrescente esta cláusula em algum script, ela será ignorada.

Como colocar o banco em force logging:

ALTER DATABASE FORCE LOGGING;

(Interessante: banco em force logging é pre-requisito para Oracle Streams e Data Guard. )

3 – Validação do banco de dados (backup validate)

A fim de detectar blocos corrompidos no banco de dados, ou perda de arquivos, é importante que o DBA faça periodicamente a validação do banco de dados – especialmente em casos de bancos grandes.

Esta é uma ação preventiva, já que só é possível saber que um bloco está corrompido durante sua leitura ou escrita.

Você pode vasculhar o banco de dados a procura de blocos corrompidos fisicamente, ou com corrupção lógica.

Como verificar, via RMAN, se há blocos corrompidos fisicamente no banco de dados:

RMAN> BACKUP VALIDATE DATABASE;

Como verificar, via RMAN, se há blocos corrupção física e lógica no banco de dados:

RMAN> BACKUP VALIDATE CHECK LOGICAL DATABASE;

Como validar os archivelogs?

RMAN> backup validate archivelog all;

4 – Validação do backup (restore validate)

Outra atividade importante de ser feita, e simples, é a validação do backup. É uma operação feita pelo RMAN onde é verificada a existência do arquivo de backup, se está legível e não tem corrupções.

É a atividade mais próxima de um restore “de verdade”, com a vantagem de não necessitar de espaço em disco para tal.

Como fazer o restore validate de um banco de dados, via RMAN:

RMAN> restore database validate;

Como fazer o restore validate dos archives, via RMAN:

RMAN> restore archivelog all validate;

5 – Testes de restore periódicos

Testar o procedimento de restore é importante para, além de você “treinar” o procedimento (ficando mais confiante para encarar um eventual desastre), testar efetivamente se fitas, backupsets, link de rede, etc, também estão dentro do esperado.

A minha dica é, caso não exista um ambiente de testes de restore, utilize bancos de desenvolvimento como área de teste! Por exemplo, se os desenvolvedores solicitarem a atualização desse ambiente, ao invés de fazer um novo backup da produção, utilize o backup diário já feito para este fim.

O importante é, mesmo que a frequência não seja tão alta, faça um teste real de restore do ambiente.

Como fazer restore/recover via RMAN (Exemplo bem simples)?

RMAN > run 
{
 allocate channel dev1 device type DISK;
 RESTORE DATABASE;
 RECOVER DATABASE;
 RELEASE CHANNEL ch1;
 }

6 – Dumps periódicos dos princiais schemas

Podemos dizer que dump, em banco de dados Oracle, é um tipo de backup lógico do banco, contendo os dados e os metadados de objetos lógicos do banco.

Quando o banco é pequeno, é interessante fazermos dumps periódicos de determinados schemas, a fim de facilitar eventuais restores de apenas objetos específicos.

Como fazer um dump de um schema

a)   Crie um diretório dentro do Oracle, apontando para um diretório físico criado dentro do servidor:

 create directory bkp as '/home/oracle/bkp';

b)   Através do utilitário Data Pump Export, no shell, crie o dump do schema dentro do diretório criado previamente:

expdp \'/ as sysdba \' schemas=hr dumpfile=hr_bkp.dmp directory=bkp;

Bem, com isso, encerro por aqui o este post!

Abçs!!!