A partir da versão 10.2B, o Progress OpenEdge disponibiliza uma nova área de buffer, chamada de Alternate Buffer Pool. Para essa área de buffer é possível direcionar uma Storage Area tipo I ou II, ou mesmo qualquer objeto dentro de uma Storage Area tipo II, otimizando o I/O sobre essa área/objeto, sem detrimento sobre as demais áreas/objetos. Essa área é determinada pelo parâmetro –B2 com a mesma métrica do parâmetro –B.
Essa área de buffer alternativo não afeta o espaço utilizado pelo buffer primário do banco (-B), porém, a soma das duas áreas de buffer não podem ultrapassar os limites de buffer pool do Progress ou do sistema operacional. Ou seja, essa nova área não aumentará o limite de buffers (o que para ambientes 64 bits é puramente teórico), mas permitirá administrá-lo melhor.
Partindo do princípio que um ambiente grande o suficiente para demandar melhor gerenciamento da área de buffer, já estará em ambiente 64 bits com limitações teóricas de buffers (8 TBytes) ou de hardware (limite da memória física), qual o ganho de se utilizar essa nova área?
Para entender isso é necessário conhecer como o Progress OpenEdge trabalha com os buffers de dados. Como geralmente é impossível alocar todo o banco de dados em buffers, o OpenEdge utiliza-se de algorítmos para alocar blocos em memória e substituí-los por outros blocos quando necessários.
Conforme os blocos do banco de dados forem lidos, eles são alocados em blocos de buffers que contém o mesmo tamanho. Essa alocação é coordenada por várias tabelas que definem o bloco de leitura, o bloco que sofreu alteração, o bloco que sofreu alteração mas foi desfeito, o bloco que está em fila de APW, entre outras. O que interessa nesse momento é a tabela dos blocos com utilização mais antiga, chamada de LRU (Least Recente Used). Essa tabela ordena qual bloco de buffer deverá ser utilizado para receber um bloco lido do banco de dados.
Quando o banco é iniciado o buffer pool está vazio (exceto pelo disaster-recovery) e qualquer bloco poderá ser alocado. Conforme o banco for utilizado, a LRU ficará com a lista de blocos ainda não utilizados, os blocos que foram utilizados apenas para leitura e os blocos que sofreram alteração. Conforme as transações são gravadas em disco, os blocos que sofreram alterações recebem o status de leitura, e deixam de ser considerados blocos que sofreram alteração. Quando todos os blocos do buffer foram utilizados, o OpenEdge passará a usar os blocos que possuem o status de leitura que estão a mais tempo sem utilização. Esse processo elimina da memória o buffer de um bloco que já estava lá. Se todos os blocos do buffer estão com o status de alteração, o OpenEdge congela o banco para liberar um buffer para ser utilizado, processo esse conhecido por Eviction. O eviction é lento e deve ser evitado.
É normal para qualquer banco de dados existirem tabelas mais acessadas e outras com utilização pontual. Para tabelas mais acessadas, deseja-se que elas permaneçam mais tempo no buffer, sem ser escolhida pela tabela LRU.
O principal ganho do Alternate Buffer Pool é manter em memória as tabelas mais utilizadas, mesmo que alguma outra query leia muitas informações de qualquer outra parte do banco cujo acesso é caracterizado como pontual. Da mesma forma, leitura de grande quantidade de registros de uma tabela regularmente utilizada não causará o eviction de buffers em alteração em rotinas de fechamento, por exemplo.
Existem algumas restrições para a utilização do Alternate Buffer Pool:
- Apenas é possível indicar que uma área utilizará o buffer pool alternativo quando o banco está fora do ar;
- O before-image não poderá ser alocado no buffer pool alternativo;
- Apenas tabelas e índices alocados em Storage Area tipo II poderão ser direcionados para o buffer pool alternativo. Para objetos em Storage Area tipo I, toda a área deverá ser direcionada;
- Leituras de clients que utilizam buffers privados (-Bp) são alocados no buffer pool primário.
Assinar feeds (RSS)