Do que se trata o artigo:
O artigo aborda os conceitos e funcionalidades das estruturas de memória lógicas do Oracle responsáveis pelo gerenciamento do banco de dado. Serão informadas as principais áreas que constituem estas estruturas, além de descrever suas funcionalidades e os relacionamentos entre elas.
Em que situação o tema útil:
O tema torna-se útil para se obter uma visão ampla do funcionamento e arquitetura do ambiente de banco de dados Oracle. Para administradores de banco de dados é essencial a compreensão destas estruturas de memória lógicas para se aplicar técnicas de otimização e realizar uma boa administração do banco.
As estruturas de memória lógicas do Oracle
As estruturas de memória lógicas do Oracle são responsáveis pelo gerenciamento do banco de dados. Elas consistem de três componentes principais: A System Global Area (SGA), a Área de código de Software e a Program Global Area (PGA). A SGA é uma área de memória utilizada para armazenar as informações do banco de dados que são compartilhadas pelos processos. A PGA é uma região da memória que contem dados e controla informações para um único processo de servidor ou um único processo de segundo plano. Enquanto que a Área de Código de Software é uma área que armazena o código do programa Oracle utilizado para executar o banco de dados.
Em um ambiente de banco de dados Oracle, um dos elementos principais da arquitetura sãs as estruturas de memória lógicas, responsáveis pelo gerenciamento do banco de dados. Sempre que um banco é iniciado, o Oracle aloca uma área de memória chamada System Global Area (SGA) e inicia um ou mais processos, visando gerenciar os dados do banco de dados de forma eficiente e administrar as solicitações de um ou vários usuários do banco.
A combinação da SGA e destes processos é chamada de instância do banco de dados. Deste modo, com o objetivo de adquirir conhecimento sobre o funcionamento e a arquitetura do ambiente de banco de dados Oracle, neste artigo analisaremos os componentes fundamentais destas estruturas.
O conhecimento das estruturas de memória lógicas do Oracle é essencial para se obter uma compreensão ampla da arquitetura do banco de dados Oracle. As estruturas de memória do Oracle são responsáveis por armazenar diversos objetos de uma instância de banco de dados, tais como: o próprio código executável, informações de sessões, processos individuais associados ao banco de dados, informações compartilhadas entre processos, instruções SQL de usuários e de dicionário de dados.
As estruturas de memórias lógicas do Oracle consistem de três componentes principais: A System Global Area (SGA), a Área de código de Software e a Program Global Area (PGA). Para apresentar uma visão geral das estruturas de memórias lógicas do Oracle, veja o esquema da Figura 1. A seguir, abordaremos estas estruturas.
Oracle Instance (Instância Oracle)
Uma Instância Oracle consiste da estrutura de memória chamada de SGA (System Global Area) e dos processos em segundo plano (background processes) utilizados para gerenciar o banco de dados.
No momento em que um banco de dados é inicializado, o Oracle realiza a leitura do arquivo de parâmetros de inicialização ou a leitura de um arquivo de parâmetros do servidor, que são arquivos que contêm uma lista de parâmetros de configuração para essa instância e banco de dados. Por conseguinte, a área de SGA é alocada e os processos de background são inicializados. Esta combinação da SGA e os processos do Oracle é chamada de instância Oracle.
Após a inicialização de uma instância, o Oracle associa a instância com o banco de dados especificado, tornando o banco de dados acessível aos usuários autorizados.
É importante ressaltar, que várias instâncias podem ser executadas simultaneamente no mesmo computador, sendo que cada uma utiliza seu próprio banco de dados físico.
System Global Area (Área Global de Sistema)
A System Global Area ou SGA é um grupo de estruturas de memória compartilhadas, utilizadas para armazenar informações do banco de dados que são divididas pelos processos e usuários da instância do banco, contendo dados e informações para o controle da instancia do Oracle.
Em casos em que diversos usuários estão conectados simultaneamente à mesma instância, os dados na SGA da instância são compartilhados entre os usuários.
No processo de inicialização de uma instância Oracle, a memória é alocada para a SGA com base nos valores definidos no arquivo de parâmetros de inicialização ou codificados no software Oracle. Quando uma instância é inicializada, a memória é alocada pelo Oracle, e ao ser finalizada, a memória é liberada.
Por ser uma área de memória em modo de leitura e gravação, todos os processos de segundo plano e processos servidores do banco de dados executados em nome dos usuários, terão permissão para ler ou gravar blocos de dados contidos dentro da SGA da instância.
O Oracle permite, por ser uma memória dinâmica, que o tamanho da SGA seja ajustado em tempo de execução, sem a necessidade de baixar o ambiente.
A memória na SGA é alocada em unidades de grânulos, onde um grânulo pode ter 4MB ou 16 MB. Se a SGA for menor ou igual a 128MB, o grânulo terá 4MB, do contrário, terá 16 MB.
A quantidade total de memória alocada para a SGA é definida pelo parâmetro SGA_MAX_SIZE. Se o parâmetro SGA_MAX_SIZE, especificado no arquivo de parâmetros de inicialização, apresentar um valor menor do que a soma de todos os valores especificados dos demais componentes da SGA, no momento da inicialização, a configuração no arquivo de parâmetros de inicialização será ignorado.
Para visualizar o tamanho atual da SGA, utilize o comando SHOW SGA. Nas seções subsequentes iremos discutir as áreas que constituem a SGA.
Database Buffer Cache (Cache de Buffer de Banco de Dados)
O Database Buffer Cache é uma área de memória da SGA utilizada para armazenar os blocos de dados do disco recentemente utilizados, isto é, blocos que foram alterados ou adicionados a partir de uma instrução DML. O grupo de buffers de uma instância é chamado de Database Buffer Cache.
Saiba mais sobre Database Buffer Cache
Os blocos de dados, preservados no Buffer Cache, podem adquirir três tipos de estados: Buffers sujos (Dirty Buffers), Buffers livres (Free Buffers) ou Buffers fixados (Pinned Buffers). Buffers sujos contêm blocos de dados alterados ou acrescentados, devido a uma instrução DML, que ainda não foram submetidos à commit. Esse buffer não pode ser reutilizado até que estes blocos de dados sejam gravados com êxito no disco. Buffers livres são buffers que não possuem dados armazenados ou que guardam blocos de dados que são idênticos aos blocos correspondentes no disco. Áreas de buffers livres podem ser substituídas por outra operação de leitura do disco a qualquer momento. Buffers presos são buffers que estão em uso por declarações DML ou são explicitamente salvos para uso futuro e, portanto, não podem ser reutilizados.
No momento em que uma consulta é processada, é realizada uma varredura no buffer cache por blocos que sejam necessários. Se o bloco não for localizado em memória, será efetuada uma leitura física do bloco no arquivo de dados e enviada uma cópia dos blocos necessários para o Buffer Cache. Esta é uma das principais funções do buffer cache: manter os blocos de dados mais solicitados recentemente em memória, evitando desta forma releituras físicas de um mesmo bloco de dados.
Os buffers cache são organizados através de dois algoritmos de lista: a lista de gravação (write list) e a lista dos menos usados recentemente, ou LRU (Least Recently Used). A lista de escrever (Write List) mantém os buffers sujos, que contêm os dados que foram modificados, mas que ainda não foram gravados permanentemente no disco. Enquanto que para alocar novos blocos de dados no buffer cache, o Oracle utiliza o algoritmo LRU, que remove os blocos de dados mais antigos da área de buffer e insere os novos blocos de dados solicitados.
O tamanho de cada bloco no Database Buffer Cache é idêntico ao tamanho de um bloco do Oracle, que é especificado pelo parâmetro DB_BLOCK_SIZE.
Para visualizar o tamanho atual do Cache de Buffer, utilize o comando SHOW PARAMETER DB_CASH_SIZE ou SHOW SGA.
A partir do Oracle 9i, é possível adicionar dois caches auxiliares que alocam memória independente dos outros caches na SGA: o Pool de Buffers KEEP e o Pool de Buffers RECYCLE. Ambos funcionam como o cache principal.
Shared Pool (Pool Compartilhado)
É uma área de memória constituída por dois subcaches principais: o cache de biblioteca (Library Cache), utilizado para armazenar os comandos SQL e PL/SQL executados recentemente no banco de dados; e o cache de dicionário de dados (Data Dictionary Cache), que armazena um subconjunto de colunas das tabelas do dicionário de dados após serem lidos no buffer cache.
Estes comandos SQL podem ser solicitados por processos do usuário ou, no caso de stored procedures, lidos do dicionário de dados. O shared pool é dimensionado pelo parâmetro de inicialização SHARED_POOL_SIZE.
Para visualizar o tamanho atual da Shared Pool, utilize o comando SHOW PARAMETER SHARED_POOL_SIZE.
Buffer de Redo Log (Cache de buffer de redo log)
O buffer de redo log é utilizado para armazenar em memória as alterações mais recentes realizadas no banco de dados pelos processos servidores e pelos processos em segundo plano, pois em caso de uma falha na instância, o Oracle poderá retroceder os dados para o seu estado original (Rollback).
No momento em que uma instrução DML atualiza uma determinada tabela, imagens de redo são criadas e armazenados no buffer de redo log.
O buffer de redo log registra o bloco que foi alterado, o local da alteração e o novo valor em uma entrada de redo nos arquivos de redo log, pois, se necessário, serão utilizados para a recuperação do banco de dados. Além das alterações efetuadas por uma transação serem intercaladas com alterações realizadas por outras transações.
Por sua vez, os registros de redo são armazenados em uma forma circular no redo log buffer, sendo reutilizados depois que o redo log buffer é preenchido. Estes são gravados em um dos arquivos de redo log pelo processo de segundo plano LGWR (Log Writer) nas seguintes situações: sempre que uma transação for confirmada, a cada três segundos, ou quando o redo log buffer atingir o tamanho de 1MB.
Um de seus principais objetivos é permitir refazer uma determinada transação que possa ter sofrido alguma falha e assim proteger o banco de dados de alguma falha da instância.
Seu tamanho em bytes é definido pelo parâmetro LOG_BUFFER. Para visualizar o tamanho atual do Redo Log, utilize o comando SHOW PARAMETER LOG_BUFFER ou SHOW SGA.
Large Pool
A large pool é uma área opcional da SGA que disponibiliza grandes blocos de memória em diversas situações que surgem durante as operações de uma instância de banco de dados Oracle, tais como: transações que envolvem mais de um banco de dados, buffers de mensagem para processos que executam consultas paralelas e operações de backup e restauração. Um aplicativo que comumente utiliza esta área é a ferramenta de backup do Oracle chamada RMAN.
O parâmetro de inicialização LARGE_POOL_SIZE controla o tamanho do large pool.
Java Pool
O Java Pool é uma seção da SGA utilizada para armazenar o código e dados Java. Bem semelhante como a área Shared Pool lida com as instruções SQL e PL/SQL.
Você pode identificar a quantidade de memória utilizada pelo Java Pool acessando a view de desempenho dinâmica: V$SGASTAT. Suas linhas incluem o campo pool, name e bytes. Especificamente, a coluna name informa a quantidade de memória de Java Pool utilizada, enquanto o campo bytes informa a quantidade de memória total da estrutura em questão.
O parâmetro de inicialização JAVA_POOL_SIZE controla o tamanho do Java Pool.
Streams Pool
O Streams Pool é um recurso utilizado para manter estruturas de dados e controle do recurso Oracle Streams, permitindo o gerenciamento e compartilhamento de dados e eventos em um ambiente distribuído.
Esta área de memória armazena mensagens enfileiradas na memória, fornecendo memória para capturar e aplicar processos em um banco de dados.
Se o tamanho especificado para a área Streams Pool for maior do que zero, qualquer memória da SGA usada por Streams é alocada para a memória de Streams Pool. Se o valor especificado for zero, ou não for especificada, a memória usada por Streams é alocada na Shared Pool, podendo utilizar até 10% da área Shared Pool.
O tamanho da Streams Pool, em bytes, é dimensionado pelo parâmetro de inicialização STREAMS_POOL_SIZE.
Processos em Segundo Plano (Background Processes)
Os processos em segundo plano (background processes) de uma instância executam funções comuns que são necessárias para atender as solicitações de serviço de usuários simultâneos, sem comprometer a integridade e o desempenho do sistema.
Um processo em segundo plano é um bloco de código executável projetado para executar uma tarefa específica. Eles consolidam funções que, de outra forma, seriam tratadas por diversos programas Oracle executados para cada usuário.
Quando uma instância Oracle inicia, vários processos em segundo plano também iniciam. Eles executam tarefas de I/O e monitoram outros processos Oracle para oferecer maior paralelismo, o que aumenta o desempenho e a confiabilidade.
Dependendo da configuração, uma instância Oracle pode incluir vários processos em segundo plano, no entanto, cada instância inclui cinco processos de segundo plano fundamentais. São eles: DBWn, LGWR, SMON, PMON e CKPT. Para ter uma visão geral dos processos em segundo plano do Oracle, veja o esquema da Figura 2.
Em ambientes Linux ou Unix, cada processo do Oracle possui um número único e os processos do sistema operacional trabalham de forma apartada. No Windows, é utilizado um único processo de sistema operacional, denominado Oracle.exe, para a instância inteira, no qual os processos do Oracle são executados como threads separados dentro desse processo. A seguir, abordaremos detalhadamente os processos de segundo plano.
DBWn (Database Writer)
O processo Database Writer é responsável por gravar os blocos de dados novos ou alterados do buffer cache do banco de dados nos arquivos de dados físicos (Data Files). Os data files, por sua vez, são arquivos físicos do sistema operacional que armazenam os dados do banco de dados propriamente ditos.
A gravação dos blocos de dados nos arquivos de dados é realizada de forma assíncrona e periódica. Tal evento ocorre nas seguintes condições: 1) quando um processo servidor realiza a leitura de um novo bloco para a memória e não existe espaço disponível no momento, ou ele está ocioso por alguns segundos; 2) quando o Oracle efetua um checkpoint do banco de dados ou da tablespace.
O DBWn é um processo servidor cuja principal função é gerenciar o database buffer cache disponibilizando buffers quando solicitados e removendo os blocos de dados alterados da memória que ainda não foram salvos permanentemente. Isso tudo é feito em um esforço para reduzir a quantidade de leituras físicas e gravações em discos.
O processo DBWn utiliza o algoritmo LRU para descartar os blocos de dados menos utilizados recentemente do Cache de Buffer.
Em um ambiente Linux, para identificar se o processo DBWn está rodando, utilize o comando:
[oracle@ XXXX ~]$ ps aux |grep dbw
oracle 19570 0.0 0.0 62356 776 pts/0 S+ 12:44 0:00 grep dbwLGWR (Log Writer)
O processo LGWR é responsável por gerenciar o buffer de redo log, gravando as alterações registradas do buffer de redo log nos arquivos de redo log físicos (Redo log Files). Os redo log files armazenam as mudanças efetuadas no banco de dados para possibilitar a recuperação dos dados em caso de falhas.
Este processo é continuamente executado na instância Oracle com as seguintes condições: 1) quando uma transação recebe o commit (confirmação); 2) quando o buffer do redo log atingir 1 MB de espaço; 3) a cada três segundos, ou antes do processo DBWn escrever do buffer no data file.
O buffer de redo log é um buffer circular, logo, quando o LGWR grava entradas redo para um arquivo de redo log, os processos de servidor podem copiar novas entradas sobre as entradas no buffer de log redo que foram gravados no disco. Normalmente, o processo LGWR grava de forma otimizada os dados, garantindo assim que haverá espaço disponível no buffer para novas entradas, mesmo quando o acesso ao log redo estiver com uma carga alta.
É importante ressaltar que antes do processo DBWn escrever um bloco de dados do cash de buffer modificado no arquivo de dados, todos os registros de redo associados contendo alterações no redo buffer devem ser gravados no redo log files primeiramente.
Quando um usuário emite uma instrução COMMIT, o processo de servidor insere um registro de commit, junto com o SCN, no buffer de redo log.
Por conseguinte, o LGWR insere um registro de confirmação no buffer de redo log e escreve-o para o disco imediatamente, juntamente com as entradas de redo. Após esta etapa, o servidor Oracle pode garantir que as alterações não serão perdidas mesmo que haja uma falha de instância.
Sempre que uma transação é submetida à commit, o servidor Oracle atribui um SCN (System Change Number, número de alteração do sistema) à transação. Ele é aproveitado pelo servidor Oracle para fornecer consistência de leitura quando os dados forem recuperados dos arquivos de dados.
Os arquivos de redo log são arquivos físicos do sistema operacional que armazenam todas as alterações importantes realizadas no banco de dados para possibilitar a recuperação dos dados em caso de falhas na instância. Cada banco de dados deve conter ao menos dois arquivos de redo log, pois o Oracle utiliza-os de forma circular.
Em um ambiente Linux, para identificar se o processo LGWR está rodando, utilize o seguinte comando:
[oracle@ XXXX ~]$ ps aux |grep lgwr
oracle 18477 0.0 0.0 62356 780 pts/0 S+ 12:31 0:00 grep lgwrSMON (System Monitor)
O processo System Monitor verifica a consistência no banco de dados, localizando e validando o arquivo de controle no momento em que o banco é montado e, se necessário, inicia a recuperação do banco de dados quando ele é aberto. Além desta funcionalidade, o SMON é responsável por unir espaços livres nos tablespaces regularmente se eles forem gerenciados pelo dicionário.
Os arquivos de controle (Control Files) são arquivos físicos do sistema operacional responsáveis por armazenar informações necessárias para manter e verificar a integridade do banco de dados. Um banco de dados Oracle deve possuir no mínimo um arquivo de controle.
O SMON é o processo utilizado em circunstâncias como uma queda ou falha de sistema, executando a recuperação de falhas aplicando as entradas dos arquivos de redo log aos arquivos de dados. A sua principal função é abrir a conexão entre a instância e o banco de dados, além de realizar funções de monitoramento e organização.
É importante ressaltar que ao ocorrer uma falha na instância Oracle as informações contidas na área SGA que não foram gravadas em disco serão perdidas. Após a perda da instância, o processo de segundo plano SMON recupera automaticamente a instância quando o banco é reaberto.
O processo SMON deverá sempre ser mantido em execução para uma instância, caso contrário, a instância será encerrada.
Quando for necessária a recuperação de uma instância, o Oracle realizará as seguintes etapas através do SMON:
1. Executar rollforward para recuperar os dados que não foram registrados nos arquivos de dados, entretanto, que foram gravados no redo log online. Durante esse processo, o SMON lê os arquivos de redo log e aplica as alterações registradas nos blocos de dados;
2. Abrir o banco de dados para permitir que os usuários estabeleçam logon;
3. Submeter à rollback as transações não submetidas à commit.
Em um ambiente Linux, para identificar se o processo SMON está rodando, utilize o seguinte comando:
[oracle@ XXXX ~]$ ps aux |grep smon
oracle 18306 0.0 0.0 62360 780 pts/0 S+ 12:29 0:00 grep smonPMON (Process Monitor)
O Process Monitor ou PMON é um processo em segundo plano criado no momento em que a instância do banco de dados é inicializada. Ele disponibiliza recursos se um dos processos do Oracle falhar. Por exemplo, se uma conexão de usuário cair, um processo do Oracle falhar ou ocorrer uma falha de hardware, o processo PMON aplica o rollback de transações que estavam em andamento, remove os bloqueios nas linhas afetadas da tabela e remove o processo desconectado da lista de processos ativos.
O PMON normalmente é executado a cada três segundos para efetuar atividades de limpeza. Se PMON não está sendo executado, a instância do banco de dados será encerrada.
Em um ambiente Linux, para identificar se o processo PMON está rodando, utilize o seguinte comando:
[oracle@XXXX ~]$ ps aux |grep pmon
oracle 17011 0.0 0.0 60292 696 pts/0 D+ 12:14 0:00 grep pmonCKPT (Checkpoint Process)
O Checkpoint process é responsável pela atualização do cabeçalho das informações de status do banco de dados nos arquivos de controle (Control Files) e nos arquivos de dados (Data Files) para refletir o último SCN (System Change Number).
Sempre que as alterações efetuadas no cache de buffer estão registradas no banco de dados de forma permanente, o processo CKPT informa ao processo DBWn o momento de gravar os dados em disco, auxiliando assim, a reduzir a quantidade de tempo necessária para uma possível recuperação da instância.
O CKPT efetua periodicamente uma verificação (checkpoint) para se certificar de que todas as informações modificadas na memória estão armazenadas fisicamente no disco, sendo realizada nas seguintes condições:
· Quando ocorre um Log Switch. Um Log Switch (troca de log) acontece quando o Oracle troca de um redo log para outro. Enquanto isso, o servidor permanece gravando novas transações em outro grupo de log;
· Durante um intervalo de tempo (definido no parâmetro LOG_CHECKPOINT_TIMEOUT do arquivo de parâmetros);
· Quando acontece um shutdown;
· O DBA força um checkpoint;
· Quando a Tablespace é passada para Offline.
O processo de Checkpoint é habilitado através do parâmetro CHECKPOINT_PROCESS.
Em um ambiente Linux, para identificar se o processo CKPT está rodando, utilize o seguinte comando:
[oracle@ XXXX ~]$ ps aux |grep ckpt
oracle 18680 0.0 0.0 62360 780 pts/0 S+ 12:33 0:00 grep ckptProgram Global Area (Área Global de Programa)
A Área Global do Programa ou PGA é uma área de memória que contêm dados e controla informações para cada processo de servidor ou processo de segundo plano (Background Processes).
A PGA é uma memória não compartilhada (Non-Shared Memory) criada e alocada quando um novo processo é inicializado no servidor, contendo uma área de memória para cada usuário ativo na instância. Dentro da PGA existem três estruturas: uma contendo um espaço para a pilha (para armazenar as variáveis e matrizes), outra contendo dados sobre a sessão do usuário e uma terceira com as informações dos cursores usados.
Para especificar a quantidade máxima de memória disponível à área de PGA, é utilizado o parâmetro de inicialização PGA_AGGREGATE_TARGET.
Software Code Area (Área de Código de Software)
A Área de Código de Software é o espaço responsável por armazenar o código do programa Oracle (o código utilizado para executar o banco de dados) que está sendo utilizado pela instância. Normalmente é localizada em uma área exclusiva ou protegida, podendo ser compartilhada entre várias instâncias Oracle.
Esta área de software geralmente possui dimensão estática, sendo possível alterar seu tamanho apenas quando o software é atualizado ou reinstalado.
Conclusão
As estruturas de memória lógicas do Oracle foram apresentadas neste artigo visando ilustrar conceitos importantes sobre a arquitetura deste SGBD, sem entrar em detalhes sobre a administração do banco de dados.
O conhecimento destas estruturas é de grande importância para a compreensão das técnicas de otimização e funcionamento de um banco de dados Oracle. Sendo estas áreas de memória ajustadas de acordo com a necessidade do ambiente por meio do administrador. O DBA deve conhecer a arquitetura, isto é, como o Oracle “trabalha”, para conter dispor de para gerenciar o banco.
Links
Oracle Database 10g: O Manual do
DBA.
http://migre.me/6aECB
Oracle Database 11g: Concepts
http://download.oracle.com/docs/cd/B28359_01/server.111/b28318.pdf
Oracle Database 11g: Administrator's Guide
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310.pdf
Oracle Database 11g: 2 Day DBA
http://download.oracle.com/docs/cd/B28359_01/server.111/b28301.pdf
