BACKUP BI

[Rodrigo AlmeidaParticipante]

Vieri,

Belezinha cara! Trabalhei com BI 2 anos também, eu tinha DW de 12TB que dava trabalho para a galera, porém, antes de mais nada, pelo que tu está passando muitas coisas devem ser revistas, por exemplo:

1) Um BI mesmo, (Falando de Data WareHouse), geralmente é NOARCHIVELOG, pois é uma base apenas de consulta, e feito backup somente no final de semana que tem janela para isso, pois se perder algo, o prórpio processo de ETL pode recuperar os dados perdidos e a instância volta ao normal, pois é só alimentar as tabelas de FATO e suas dimensões, mesmo porque não é normalizado.

A estrategia de backup para o DW era muito influênciado pelo que a empresa fornecia, exemplo, se cair na sexta, nós tinhamos os arquivos de carga de 2 semanas atrás e aplica a carga, e fazia o backup FULL COLD no Domingo. Sem muita frescura.

2) Tive a experiência de ter na mão tb um Data Smart de 2Tb que esse sim estava ARCHIVELOG, porém, antes de qualquer coisa, devemos analisar o que a infra-estrutura da empresa nos oferece, exemplo:

2.1) Unidades de FITA ou Storage para backup?
2.2) Qual a tecnologia que tenho a disposição? DLT, LTO, DDS, Disco e etc…
2.3) Quais os produtos para realizar essa tarefas de backup? Exemplo, Netbackup, Tivoli, ArcServer e etc…
2.4) Possui BCV, Mirror ou algum outro tipo de espelhamento no server?
2.5) Quais as janelas para backup?
2.6) Quais os horários que as cargas são realizadas?
2.7) Qual é o tempo de Dowtime que posso ter no meu DM ou DW?
2. 8) Minha infra de rede? Eu possuo uma rede de backup única para tal tarefa, ou vou precisar competir com os usuários?

Sobre o RMAN como solução!

O RMAN se estiver com uma versão Enterprise no banco pode lhe oferecer diversas outras vantagens sobre os outros produtos, como:

1 – Pode realizar o backup utilizando por natureza o algoritmo NULL COMPRESSION, não copia os EMPTY BLOCK, isso pode diminuir o tamanho do seu backup.

2 – Pode se utilizar a opção BACKUP AS COMPRESSED, isso pode demorar um pouco a mais para realizar o backup e consequentemente consumir mais CPU, por isso é importante ter as respostas das perguntas de cima para poder utilziar.

3 – O RMAN pode alocar para você no mesmo script canais de comunicação para backup em DISCO e FITA, ou seja, pode ser utilizar realizar o backup do banco para DISCO e mandar os archives para FITA para ganhar espaço.

4 – Caso não tenha disponibilidade e a taxa de carga é muito alto, o RMAN permite realizar o backup com um determinado periodo de tempo, ou seja, tu pode falar que tem somente 6 horas de janela em um determinado horario, e caso não seja feito ele aborta o backup.

4.1 – Com essa opção ele pode abortar o seu backup, ou tu ainda pode utilizar a opção BACKUP DURATION 06:00 MINIMIZE TIME PARTIAL DATABASE, e tu que foi feito de backup, ser reaproveitado!

5 – Tem a opção de janela de backup como acima, e utilizar a opção MINIMIZE LOAD, ou seja, seu banco de dados pode etar com alta taxa de carga e mesmo precisando de backup, o RMAN irá realizar com poucos recursos disponíveis. Porém, nesse modo o backup demora muito mais!

6 – A vantagem básica do RMAN, com ARCHIVELOG, tu pode trabalhar com até 4 níveis de backup incrementais, ou seja, dependendo da sua estratégia, se torna fácil a sua recuperação!

7 – O RMAN lhe permite realizar limitado por backup piece, ou seja, se eu quiser em algum momento realizar todo o meu backup para FITA, e minha fita é limitado em 400GB, posso mandar de 400GB em 400GB. E olha que bom, se tenho uma infra de rede específica para backup e trabalhar com as opções acima, tem grande chance de seu um SUCESSO!

8 – O RMAN trabalha com catálogo, não preciso falar nada. =D

9 – Com o RMAN tu tem a opção de fornecer consistência e garantia de restauração do seu backup, ou seja, pode utilizar o VALIDATE CHEC LOGICAL DATABASE e RESTORE DATABASE PREVIEW!!! Nem comento!

10 – Pode utilizar BMR! Ou Seja, Block Media Recover, imagina uma tabela de fato de 300GB com um bloco de dados corrompido, mesmo que seja particionada e afete somente uma partição, imagina o trabalho que será recuperar isso e não impactar a aplicação, enquanto tu pode utilizar somente o comando BLOCKRECOVER CORRUPTION LIST.

11 – E tem mais umas dezenas de coisas que ele pode lhe oferecer, é que já estou puxando muito o saco do RMAN e logo logo os caras vão me chamar para ser vendedor do produto! hehehehe.

Agora, outro ponto importante.

Eu disse sobre conhecer sua infra-estrutura e um pouco do RMAN, porém quais as estratégias de backup se será realizado, como:

1) Se precisar recuperar o banco inteiro, leva quanto tempo?
2) Se perder uma tabela, como posso recuperar ela?
3) Se tenha alguma corrupção lógica, o que podemos fazer?
4) Meu backup é 100% restaurável?
5) Vou precisar de backup lógico?
6) E as procedures, packages e functions, o que faço?

Sobre aplicar isso tecnicamente!

O Ideal é todo fim de semana é tem um BACKUP FULL CONSISTENTE, ou seja, ALTER SYSTEM ARCHIVE LOG CURRENT e depois BACKUP INCREMENTEL LEVEL 0 DATABASE INCLUDE CURRENT CONTROLFILE.

Configar os banco para os parâmertos default do RMAN.

Mesclar backup Nível 0, 1 e 2 durante a semana.

Veja a quantidade de espaço que você tem disponível para os archives, talves você possa habilitar mais uma área de ARCHIVES e a cada 1 hora manda eles para FITA por segurança.

E tem mais dezenas de coisas Vieri, leva isso em consideração e conforme vai surgindo as dúvidas, vai postando…

Abraços,
Rodrigo Almeida