#21
Vamos conhecer um pouco mais sobre o Cache de Buffer de Dados.
O Cache de Buffer de Dados é o local de trabalho do Oracle, é nessa área que ele executa as SQLs. A função dessa área é otimizar e melhorar o desempenho das instruções DML. O maior gargalo de um banco de dados é o I/O dos arquivos em disco.
Mas antes de explicar como funciona o Cache de Buffer de Banco de dados, vamos entender rápidamente o que é bloco, desta forma você não fica perdido, os arquivos de dados que contém os registros que são as linhas da tabela, indices e outros objetos de dados são formatados em blocos de tamanho fixo, o DBA pode definir um tamanho para esses blocos ou deixar de forma automática. A quantidade de linhas por bloco é indefinida, pois, as linhas possuem comprimento variável, o comprimento desta linha dependerá do número de colunas e os tipos de informações definidos para a tabela. De acordo com tamanho das linhas, pode haver várias linhas por bloco ou uma linha pode se estender por vários blocos. Como o Cache de Buffer de Banco de Dados trabalha na memória os Buffers são formatados e dimensionados de forma que cada buffer armazene um bloco.
O Cache de Buffer de Dados funciona da seguinte forma, essa area é acessada toda vez que uma instrução DML é executada, por exemplo, quando um usuário realiza uma consulta SELECT de uma determinada tabela no banco de dados, primeiro é verificado se o bloco de dados está na memória, senão, é realizado a consulta nos blocos de dados que possuem as linhas de interesse e as gravam no Cache de Buffer do Banco Dados, e depois as linhas de interesse são transferidas para a PGA da sessão do usuário para posterior processamento. Mas esses blocos continuam gravados no Cache de Buffer do Banco de Dados, desta forma, se a execução de uma outra instrução precisar do mesmo bloco de dados, a informação será retirada diretamente do cache em memória, sem precisar acessar o disco novamente, desta forma a consulta fica bem mais rápida. Esse Bloco de dados fica gravado no Cache de Buffer do Banco de Dados, até o cache ser solicitado para armazenar um outro bloco de dados.
Teoricamente, todos os blocos que contém dados acessados com uma maior frequência estarão gravados no Cache de Buffer do Banco de Dados, diminuindo assim a necessidade de I/O de disco.
Vamos imaginar que um usuário realize três instruções DML, primeiro o usuário realiza um SELECT na tabela, depois realiza a alteração de um resuldado com um UPDATE + COMMIT, depois realiza a mesma consulta via SELECT. Agora vamos acompanhar como foi a execução interna do banco de dados, no Primeio SELECT foi realizado a consulta no disco, os dados foram armazenados no Cache de Buffer do Banco de Dados e transferidos para o PGA para processamento, após isso foi executado uma nova instrução de UPDATE, desta vez os dados foram consultados e alterados diretamente no cache, depois é executado o mesmo SELECT e as informações são extraídas diretamente do cache, observando essa situação, houve três instruções e o disco foi lido apenas uma vez, com isso a taxa de acesso ao cache foi de 66%, e de I/O foi de 34% e quanto menor a taxa de acesso de I/O melhor o desempenho do banco de dados.
Agora você questiona, mas os dados alterados não são gravados no disco? E a resposta é, são e não são. O que quero dizer é que os dados são gravados em disco, mas não em tempo-real, os dados alterados permanecem em Cache até que um processo em segundo plano realiza a gravação nos arquivos de dados, esse processo de segundo plano é chamado de Database Writer, e vamos conhecer ele melhor depois. Não existe uma correlação de tempo entre a frequência de atualizações de um buffer e quando ele tem que ser gravado de volta nos arquivos de dados, cada processo o de Cache e o Database Writer trabalham de formas independentes, e podemos declarar que o Database Writer é meio preguiçoso, pois, ele só entra em ação quando é preciso liberar Buffers para a entrada de novos blocos ou quando um Buffer sujo está parado por muito tempo e sem atividade, desta forma o processo de I/O é menor aumentando assim o desempenho.
A definição correta do tamanho do Cache de Buffer do Banco de Dados é muito importante para melhorar o desempenho. O tamanho do Cache não pode ser nem muito grande ou muito pequeno. O tamanho do Cache deve ser dimensionado de forma que armazene todos os blocos que são frequentemente acessados, indiferentes se estão sujos ou limpos, se um cache for muito pequeno, o acesso ao disco será maior e o Database Writer irá trabalhar mais na gravação dos dados. Se o Cache for muito grande, o problema não é tão drástico, mas, pode gerar problemas, as desvantagens de cache muito grande é que blocos raramente acessados ficaram armazenados no Cache sem motivo e a inicialização de uma instância fica mais lenta.
Após a versão 9i ficou possível redimensionar o cache do buffer do banco de dados após o startup sem reiniciar o banco de dados.
Um Cache de Buffer de Banco de Dados quando é usado possui dois estados que tem os nomes de, Buffer Limpo e Buffer Sujo.
- Buffer Limpo, um Buffer é considerado limpo, quando um bloco for iniciamente copiado para ele, nesse momento a imagem do bloco em disco será a mesma do bloco no Buffer.
- Buffer Sujo, um Buffer é considerado sujo quando ele armazena um bloco onde a imagem que esta no cache é diferente da imagem que esta no bloco em disco. Quando o bloco do Buffer sujo é gravado no bloco em disco tornando as duas imagens iguais o Bloco sujo se torna limpo novamente.
Mesmo após ser gravado em disco o bloco continua no Cache de Buffer do Banco de Dados e é possível que fique um bom tempo sem ser sobrescrito por outro bloco.
Se tiverem dúvidas realizem um INSERT nos comentários e depois dê um COMMIT que depois respondo.
Abraço e bons estudos.
Comentários
Postar um comentário