Fala pessoal, beleza?
Tenho falado com vários DBA's sobre backup's e políticas de melhores práticas e quase 100% deles tem comentado sobre a dificuldade em cumprir as janelas definidas já que temos bancos cada dia mais enormes.
E percebi que quase todos eles não usam uma opção muito legal que se chama Block Change Tracking (ou BCT) para os mais chegados, que poderia ajudar bastante nessa tarefa.
Basicamente e muito resumidamente falando, mesmo quando você faz um backup incremental, o Oracle precisa percorrer todos os blocos dos seus datafiles - sejam eles novos ou não, para saber o que foi alterado desde o último backup e inserir esses blocos em seus backup pieces.
É ai que mora a beleza do BCT.
Se o BCT estiver ativo na sua produção ou em um StandBy físico, o Oracle vai registrar bitmaps que marcam as alterações nos datafiles entre os backups. Ele vai criar um índice (ou um arquivo de rastreamento como o próprio nome já diz) e vai registrar todos os blocos alterados ali.
O RMAN então usará este rastreamento para identificar esses blocos alterados na execução dos backups incrementais, salvando muito tempo nessa operação e evitando a necessidade de leitura de todos os blocos dos datafiles.
O mais bacana é que o uso do BCT não altera os comandos usados para realizar os backups incrementais. Além disso o BCT file não requer manutenção após a configuração inicial.
Outro ponto legal demais é que o DBA não precisa se preocupar com o gerenciamento desse arquivo. O Oracle gerencia automaticamente o espaço no BCT.
Aqui temos um ponto de atenção quanto a retenção, como destacado no exemplo dado no manual:
É importante considerar o limite de oito bitmaps na sua estratégia de backup incremental. Por exemplo, se você fizer um backup nível 0 seguido por sete backups incrementais diferenciais, o BCT file chegará a 8 bitmaps. O próximo backup irá descartar o bitmap mais antigo
Então, se você fizer um backup incremental de nível 1 cumulativo na próxima operação, o RMAN não poderá otimizar o backup, porque o bitmap correspondente ao backup nível 0 será substituído. Então ess eé um ponto de atenção.
Para criar um BCT é mega fácil:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '+BCT/BCTrk.F';
Abaixo eu deixo 3 pontos ue devem ser considerados antes de adotar o que eu falei acima:
1) Se você não passar onde o BCT deve ser criado, por default ele será inciado no DB_CREATE_FILE_DEST.
2) Eu sempre crio um DG exclusivo para o BCT. Devido a ele ter uma gravação intensa, ele pode afetar a performance do banco de dados caso você o coloque juntamente com a área de FRA, por exemplo. Ou no seu DG de Redos.
3) Infelizmente você só pode habilitar o BCT em um StandBy físico se você possuir a licença do Active Data Guard.
Claro, antes de sair habilitando quaquer coisa em seu banco de dados, por favor, teste muito bem e veja se é adequado a seu ambiente.
"Lembre-se que o que é bom para o meu ambiente pode não ser bom para o seu." - By Ricardo Portilho Proni
É ou não é show? Você acha que seu backup vai ser mais rápido com isso?
Backup and Recovery User's Guide
Grande abraço e espero que tenha ajudado.
Mario
BCT é uma excelente feature, mas tem que ter alguns cuidados pois possui muitos bugs (olhar note Block Change Tracking - Known Issues (Doc ID 2836206.1). Checar large_pool_size, pra bancos com muitas alterações precisa incluir 2 ou 3 parametros underscore especificos do bct. Apesar de ser online a execução, tivemos varios casos de queda da instancia (tanto para habilitar como para desabilitar) ...
ResponderExcluir