Estruturas de Memória – Parte 2


O CACHE DE BUFFER DO BANCO DE DADOS

     O cache de buffer do banco de dados é a área de trabalho do Oracle para execução de SQL. Ao atualizar os dados, as sessões dos usuários não atualizam diretamente no disco. Os blocos que contém os dados de interesse são primeiramente copiados no cache de buffer do banco de dados. As alterações (como inserção de novas linhas e exclusão ou modificação de linhas existentes)  são aplicadas a essas cópias dos blocos de dados no cache de buffer do banco de dados. Os blocos permanecerão no cache por algum tempo, até que o buffer que eles estão ocupando seja requisitado para armazenar outro bloco em cache.

     Durante uma consulta, os dados também utilizam o cache. A sessão calcula quais blocos contêm as linhas de interesse e as copia no cache de buffer do banco de dados.  As linhas relevantes são então transferidas para a PGA da sessão para processamento posterior. E, novamente, os blocos permanecem no cache de buffer do banco de dados por algum tempo subseqüente.

     Tome nota do termo bloco. Os arquivos de dados são formatados em blocos de tamanho fixo. As linhas da tabela e outros objetos de dados, como chaves de índice, são armazenados nesses blocos. O cache de buffer do banco de dados é formatado em buffers de memória, cada um dimensionado para armazenar um bloco. Ao contrário dos blocos, as linhas são de comprimento variável. O comprimento de uma linha dependerá do número de colunas definido pela tabela, se as colunas contiverem realmente alguma informação, e se contiverem, que tipo de informação. Dependendo do tamanho dos blocos (que é definido pelo DBA) e do tamanho de linhas (que depende do projeto e do uso da tabela), pode haver várias linhas por bloco ou uma linha pode se estender por vários blocos.

     Teoricamente, todos os blocos que contêm dados acessados com freqüência estarão no cache de buffer do banco de dados, minimizando a necessidade de I/O de disco. Como uma utilização típica do cache de buffer do banco de dados, considere um usuário final recuperando um registro de funcionário e atualizando-o, com estas instruções:


SELECT last_name, salary, job_id FROM employees WHERE employee_id=100;

UPDATE employees SET salary=salary * 1.1 WHERE employee_id=100;

COMMIT;

     O processo de usuário pediu o número do funcionário e construiu a instrução SELECT. A instrução SELECT recupera alguns detalhes a serem enviados ao processo de usuário, onde eles serão formatados para exibição. Para executar essa instrução, o processo de servidor da sessão lerá o bloco de dados que contém a linha relevante em um arquivo de dados de um buffer. O processo de usuário iniciará então um diálogo na tela para solicitar alguma alteração a ser feita e verificada. Depois, a instrução UPDATE e a instrução COMMIT serão construídas e enviadas para o processo de servidor para execução. Desde que não tenha sido transcorrido um período de tempo excessivo, o bloco com a linha ainda estará disponível no cache quando a instrução UPDATE for executada. Neste exemplo, a taxa de acesso ao cache de buffer será de 50%: dois acessos a um bloco no cache, mas somente uma leitura do bloco no disco. Um cache de buffer do banco de dados bem ajustado pode resultar em uma taxa de acesso ao cache superior a 90%.

     Um buffer que armazena um bloco, cuja imagem no cache não é a mesma no disco, é referenciado como um buffer sujo. Um buffer será limpo quando um bloco for inicialmente copiado para ele: nesse ponto, a imagem do bloco no buffer será igual à do bloco no disco. O buffer se tornará sujo quando o bloco que estiver nele for atualizado. Eventualmente, os buffers sujos devem ser gravados de volta no arquivo de dados, quando o buffer ficará limpo novamente. Mesmo depois de gravado no disco, o bloco permanece na memória. É possível que o buffer fique um tempo sem ser sobrescrito por outro bloco.

     Observe que não há correlação entre a freqüência de atualizações de um buffer (ou o número de instruções COMMIT) e quando ele tem de ser gravado de volta nos arquivos de dados. A gravação nos arquivos é feita pelo processo em segundo plano database writer.

     O tamanho do cache de buffer do banco de dados é crucial para o desempenho. O cache deve ser dimensionado adequadamente para armazenar todos os blocos freqüentemente acessados (sejam eles limpos ou sujos), mas não tão grande que possa armazenar blocos raramente necessários. Um cache subdimensionado resultará em uma atividade em disco excessiva, à medida que os blocos freqüentemente acessados são lidos continuamente no disco, usados e sobrescritos por outros blocos e, em seguida, lidos no disco de novo. Um cache superdimensionado não é tão ruim (desde que ele não seja tão grande que o sistema operacional tenha de fazer swap de páginas de memória virtual com a memória real), mas pode causar problemas. Por exemplo, a inicialização de uma instância fica mais lenta se ela envolve a formatação de um cache de buffer do banco de dados muito grande.

     O cache de buffer do banco de dados é alocado na hora da inicialização da instância. Antes da versão 9i do banco de dados, não era possível redimensionar o cache de buffer do banco de dados após o startup sem reiniciar a instância do banco de dados, mas, da versão 9i em diante, ele pode ser redimensionado a qualquer hora. Esse redimensionamento pode ser manual ou (da versão 10g em diante) automático de acordo com a carga de trabalho, se o mecanismo automático tiver sido ativado.

Anúncios

2 comentários em “Estruturas de Memória – Parte 2

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s