Pular para o conteúdo principal

LGWR ( Log Writer ) - Estruturas de Memória no Oracle


#31
O LGWR grava os dados do Buffer de Log nos arquivos de Redo Log no disco. Esse tipo de gravação também é muito conhecido como, fazer flush do buffer de log.

Para entender a função do LGWR e como o Buffer de Log é criado, vamos reelembrar um post anterior, o post é sobre Cache de Buffer do Banco de Dados.

O Cache de Buffer do Banco de Dados é o local na  memória onde é armazenado os blocos dos arquivos de dados e ele mantém dois tipos de Buffer, o Limpo e o Sujo. Quando um Buffer está sujo, isso quer dizer que ele executou uma das 3 instruções, Insert, Update ou Delete, antes do Buffer atualizar esse vetor de alteração no bloco dentro do Cache, ele grava esse vetor de alteração no Buffer de Log e é desta forma que o Buffer de Log é gerado.

Em um post anterior, também é informado porque um Buffer de Log é importante. Para resumir, o Buffer de Log é o responsável por manter a integridade dos dados em caso de falha no banco de dados, pois, é a partir do Buffer de Log que é registrado os dados nos arquivos de Redo Log.

Para registrar os vetores de alteração nos arquivos de redo log é utilizado o processo LGWR. O LGWR gera um fluxo de gravação de conteudo no disco quase em tempo real. Quando uma sessão executa uma instrução COMMIT, o LGWR grava as informações em tempo real, para isso a sessão que enviou o COMMIT é suspensa enquanto o LGWR grava o buffer no disco, somente então é que o commit é confirmado e a transação se torna, portanto, irreversível e a sessão é liberada para continuar a trabalhar.

O Buffer de Log é uma estrutura da memória de uso global, isso quer dizer, que todas as sessões de usuário registram os vetores de alteração de forma intercalada, e quando o LGWR grava no disco, ele pode estar gravando ao mesmo tempo um grupo de vetores de alteração de diversas sessões de usuários.

É impossível executar comandos DML mais rápido do que o LGWR pode gravar os vetores de alteração no disco, e é por isso que o LGWR é considerado um dos principais gargalos na arquitetura Oracle.

Existem três circunstâncias que obriga o LGWR realizar a gravação em disco.

- COMMIT
- Buffer de Log com um terço completo
- DBW estiver para gravar buffers sujos

Primeiro, ao executar um COMMIT, o processo do servidor insere um registro de commit no buffer de log e suspende a sessão do usuário que realizou o commit enquanto o LGWR realiza o flush do buffer de log no disco, quando a gravação estiver concluída, uma confirmação de commit retorna para a sessão para que o processo possa continuar trabalhando normalmente, isso garante que nenhuma transação será perdida, pois cada vetor de alteração para uma transação estará disponível no Redo Log no disco.

Segundo, quando o Buffer de Log estiver com um terço completo, o LGWR fará um flush do buffer para o disco, se o espaço de memória do Buffer de Log for pequeno, o que é recomendado, a trigger que verifica o tamanho do Buffer de Log irá forçar o LGWR a fazer o flush do buffer no disco quase em tempo real. Como um Buffer de Log pode ter um terço preenchido em uma fração de segundo, o LGWR irá gerar um fluxo de gravação contínuo dos vetores de alteração para o disco quase em tempo real, então quando uma instrução COMMIT for executada é possível que não haja quase nada para gravar, portanto, um COMMIT pode ser concluído quase que instantaneamente.

Terceiro, quando o DBW estiver para gravar buffers sujos, mas, antes do DBW gravar os buffers sujos nos arquivos de dados, ele força o LGWR a executar o flush dos buffer de log para os arquivos de redo log online. Isso é realizado para garantir que sempre será possível reverter uma gravação que não sofreu commit. Ao executar uma instruções DML (Insert, Update, Delete) também é gerado dados de Undo, mas para frente iremos entender o que são, mas esses dados de Undo também geram vetores de alteração, como eles estarão nos arquivos de Redo Log antes dos arquivos de dados serem atualizados, os dados de Undo necessários para reverter uma transação, podem ser reconstruídos, se necessário.

Você se lembra que no post sobre DBW é mencionado que o DBW tem um limite de três segundos de intervalo para gravar os buffers sujos no disco, então, esse limite é aplicado obrigatoriamente ao LGWR, pois sempre antes de um DBW gravar os dados ele sinaliza para o LGWR realizar essa gravação antes, podemos então considerar que o intervalo de três segundos também pode ser uma circunstância que obriga o LGWR a realizar uma gravação em disco.

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

Postagens mais visitadas deste blog

Conhecendo a arquitetura do Banco de Dados Oracle

#15 Vamos focar mais no ambiente de banco de dados mais comum, que é uma instância em um computador, abrindo um banco de dados armazenado em discos locais. Sempre que for mensionado instância, esta se referindo ao banco de dados em funcionamento. Um banco Oracle é composto por duas estruturas, uma lógica e uma física. A estrutura lógica é chamada de instância e composta por estruturas de memória e processos, a sua existência é temporária na memória RAM e CPU e fica ativa enquanto o banco Oracle estiver ligado, se desligar o banco Oracle toda a informação ou vestígios de sua existência será apagado da memória, ao ligar o banco Oracle a instância é carregada novamente na memória. Os processos que compõem a instância trabalham em segundo plano e fica ativo o tempo todo enquanto a instância estiver ativa. A estrutura física é onde fica armazenado as informações, e uma vez criado, ele existe até que o DBA deliberadamente decida exclui-lo. Quando um banco Oracle é iniciado, na me...

O Cache de Buffer do Banco de dados - Estruturas de Memória no Oracle

#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ár...

Shared Pool - Estruturas de Memória no Oracle

#23 O Shared Pool é considerada umas das estruturas de memórias mais complexas da SGA, ela é dividida em dezenas de subestruturas e todas são gerenciadas internamente pelo Oracle. Mas nesse momento vamos citar apenas os 4 principais componentes desta estrutura, as demais serão analizadas posteriormente. Quando uma aplicação executa uma DML, vários processos internos no Oracle são realizados até o retorno do resultado para o usuário. E esses 4 componentes tem participação direta na execução da DML e com isso gerando um bom desempenho do banco de dados. Os 4 principais componentes são: - O Cache de Biblioteca - O Cache de Dicionário de Dados - A Área PL/SQL - O Cache de Resultados de Funções PL/SQL e Consultas SQL Agora, vamos conhecer um pouco mais de cada um. - O Cache de Biblioteca (library cache) Todas instruções DML enviadas pela aplicação devem ser analizadas pelo Oracle. Quem realiza essa análise é o parse, o parse converte o código escrito pelos progra...