Database buffer cache

A estrutura de memória compartilhada chamada database buffer cache contém cópias dos blocos de dados que são lidos do disco pelos processos servidores. Os buffers são compartilhados por todos os usuários conectados a uma instância ORACLE.

O tamanho dos blocos de dados é determinado pelo parâmetro DB_BLOCK_SIZE, especificado no momento da sua criação e não pode ser alterado a menos que o banco seja novamente recriado.

O número de blocos lógicos em memória é determinado pelo parâmetro DB_BLOCK_BUFFERS. Esses dois parâmetros configuram o tamanho do database buffer cache.

Ele é organizado em duas listas: a dirty list e a least recently used list (LRU). A dirty list é uma lista que contém os blocos alterados que ainda não foram escritos em disco.

A LRU é uma lista que contém blocos do ORACLE que foram alterados pelos comandos dos usuários mas ainda não foram gravados em disco. Contém ainda blocos livres e blocos em uso.

Assim, quando um processo servidor precisa ler um bloco de dados do disco para a memória, ele:

1. Pesquisa nas listas LRU e dirty list pelo bloco de dados desejado.

2. Caso esse bloco de dados não seja localizado, o processo servidor pesquisa a lista LRU em busca de um bloco livre.

3. Em seguida, o processo servidor move os blocos alterados encontrados na lista LRU para a dirty list, ou seja, movimenta-os para a lista de blocos alterados ainda não gravados nos arquivos de dados, de acordo com a localização de cada um deles, durante o processo de pesquisa de um bloco livre.

4. Finalmente, o processo servidor efetua uma cópia do bloco de dados do disco para um bloco livre.

5. Esse procedimento termina quando o processo servidor localiza um bloco livre ou se um número específico de blocos forem pesquisados sem encontrar um único bloco livre.

Se nenhum bloco foi encontrado, o ORACLE deve gravar os blocos alterados da dirty list para os arquivos em disco, para liberar espaço em memória para os novos blocos de dados que precisam ser manipulados pelos comandos dos usuários.

Operação envolvendo o comando SELECT.

Para uma operação que envolve o comando SELECT é preciso que os blocos de dados que contêm as linhas a serem retornadas, de acordo com o critério de pesquisa, estejam em memória, no database buffer cache.

São executados os seguintes passos:

1. A lista LRU é pesquisada para que os blocos de dados necessários sejam encontrados.
2. Caso não se encontrem em memória, o processo do servidor executa as leituras físicas necessárias e traz os blocos para a memória.
3. Em seguida são feitas leituras lógicas em memória.

Nenhuma tabela ocupa menos de dois blocos de dados. Portanto, quando uma certa informação armazenada em uma tabela é requerida na memória, pelo menos dois blocos de dados são necessários: um bloco de cabeçalho e outro bloco com os dados.

Segmentos de rollback.

Um segmento de rollback é uma porção de um banco de dados que registra as ações das transações dos usuários nos dados para que possam ser desfeitas sob certas circunstâncias; é um objeto usado para gravar os dados alterados pelos processos dos usuários. Cada banco de dados deve possuir pelo menos um deles.

Um segmento de rollback é usado para permitir a consistência da leitura, recuperar um comando quando ocorre o dead-lock, recuperar uma transação até uma certa marca identificada por um SAVEPOINT, recuperar uma transação terminada por uma falha de processo de um usuário e desfazer todas as transações pendentes durante a recuperação de uma instância.

Cada transação deve ser assinalada a um segmento de rollback. Isso pode ser feito automaticamente baseado em alguns critérios que o ORACLE possui, como pode ser feito manualmente pelos usuários através do comando:

SQL> ALTER SYSTEM USE ROLLBACK SEGMENT rbs_<numero>;

Onde:

RBS_<numero> Nome do segmento de rollback.

Operação envolvendo o comando UPDATE.

Todas as operações de atualização de dados em um banco de dados envolvem os segmentos de rollback para permitir a consistência da leitura, a recuperação das informações e permitir que uma transação ou um comando sejam desconsiderados ou desfeitos.

São executados os seguintes passos:

1. Os blocos de dados da tabela a ser alterada, com as linhas que sofrerão as alterações, são trazidos para a memória.
2. Os blocos de um segmento de rollback são alocados na mesma estrutura database buffer cache. Nesse momento, o ORACLE aloca automaticamente um segmento de rollback disponível ou algum especificado pelo comando ALTER SYSTEM USE ROLLBACK SEGMENT.
3. São feitos locks exclusivos nas linhas modificadas.
4. Os dados antigos são gravados em um bloco do segmento de rollback acionado anteriormente. Nele são armazenados também a identificação da transação do usuário que executou o comando UPDATE, o endereço da coluna com a especificação do bloco de dados acionado, a identificação do arquivo físico e o número da linha e da coluna a serem alteradas em seguida.
5. As alterações são aplicadas nas linhas da tabela em cada um dos blocos de dados que as armazenam.

Caso o mesmo usuário que tenha executado um comando UPDATE pesquisar a tabela atualizada, ele enxergará sua alteração. Os outros usuários não a enxergarão, isto é, lerão apenas o valor antigo armazenado no segmento de rollback. Dessa forma mantém-se a consistência de leitura. Naturalmente, quando o usuário que executou o comando UPDATE efetivar as alterações com o comando COMMIT, todos os outros usuários passarão a enxergar as alterações feitas, exceto se algum outro estiver executando uma operação em andamento com o comando SELECT.

Consistência de leitura.

Durante todo o processamento de um comando SQL, o ORACLE mantém uma consistência dos dados de uma tabela de acordo com o momento em que o comando for inicializado.

Para o comando SELECT, o ORACLE marca o momento da sua execução como o instante a partir do qual a consistência de leitura é mantida.

A partir deste momento, quaisquer alterações feitas em uma tabela por outros usuários não são enxergadas pelo usuário que emitiu o comando SELECT, até que os outros usuários que atualizaram a tabela terminem suas transações, com os comandos COMMIT ou ROLLBACK.

Todas as alterações feitas são mantidas em segmentos de rollback alocados pelo ORACLE ou pelos próprios usuários. Para quem estiver lendo a tabela o ORACLE lê os valores antigos no segmento de rollback apropriado, e não nos blocos de dados alterados.

A seguir apresentamos o funcionamento desse mecanismo:

10 h 00 min SQL> UPDATE EMP ...;

Às dez horas o usuário A executa o comando UPDATE mas não efetiva a alterações.

10 h 01 min SQL> SELECT ... FROM emp;

Às dez horas e um minuto o usuário B pesquisa a tabela EMP. Ele não enxerga as alterações feitas pelo usuário A. Do segmento de rollback que registrou a alteração do usuário A é trazido o valor antigo às alterações, ocorrendo a consistência da leitura.

10 h 02 min SQL> COMMIT;

Às dez horas e dois minutos o usuário A efetiva sua transação. Como não existe nenhum processo de leitura em andamento e não foi utilizado comando SET TRANSACTION READ ONLY, os segmentos de rollback alocados são liberados.

10 h 03 min SQL> SELECT ... FROM emp;

Finalmente, às dez horas e três minutos o usuário B passa a enxergar as alterações feitas na tabela EMP pelo comando UPDATE do usuário A, pois a transação foi terminada e efetivada com o comando COMMIT.

Processo DBWR.

O processo Database Writer (DBWR) gerencia o database buffer cache para que os processos dos usuários sempre localizem blocos livres para o processamento de seus comandos.

Ele escreve todos os buffers alterados para os arquivos de dados, usando o algoritmo LRU para manter os blocos mais utilizados em memória.

O DBWR adia ao máximo a escrita dos blocos alterados para a otimização do I/O em disco, que é uma das principais causas para a queda da performance de um banco de dados.

O processo DBWR escreve os blocos alterados para o disco quando:

1. A dirty list ultrapassar um certo limite. Essa lista é usada no database buffer cache e contém os buffers alterados.
2. Um processo pesquisar um número específico de buffers na LRU sem encontrar um bloco livre.
3. Ocorrer o time-out, ou seja, quando um certo tempo limite for ultrapassado. Esse tempo limite geralmente é de três segundos.
4. Ocorrer um checkpoint.

Configuração multi-threaded

O ORACLE pode ser configurado em três diferentes formas para variar o número dos processos de usuários que podem estar conectados em cada processo do servidor.

Dedicated Server Um processo servidor dedicado manuseia as requisições emitidas por um único usuário.

Esse processo servidor é criado quando ocorre a conexão de um usuário com o ORACLE.

Multi-Threaded Server A configuração Multi-Threaded Server do ORACLE permite que diversos processos de usuários conectados a uma instância possam compartilhar um conjunto de processos servidores disponíveis.

Esses processos servidores são fornecidos pelo ORACLE quando o usuário requisita um comando.

Combined User/Server Process Nesta configuração os códigos de uma aplicação e do ORACLE são combinados em uma única tarefa.

Essa configuração é disponível em alguns sistemas operacionais, como o VMS.

Com a utilização apropriada dessas configurações, podemos eventualmente melhorar o desempenho do banco de dados. Por isso, nessa sessão discutiremos a arquitetura multi-threaded, suas vantagens e a configuração do ambiente.