quinta-feira, 1 de setembro de 2022

Você sabe o que é o Block Change Tracking?

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?

Mais informações aqui:

Backup and Recovery User's Guide

2 Day DBA

Grande abraço e espero que tenha ajudado.

Mario




Um comentário:

  1. 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

Isso te ajudou? Comente...

Postagem em destaque

[ORACLE] Batch change EDITIONABLE property.

Hello everyone. Hope you're doing well! Today, I have a simple case.   A test database had many database objects with the EDITIONABLE pr...