Estruturas de Memória Oracle

A arquitetura de um banco de dados Oracle costuma ser considerada uma espécie de “caixa-preta”, difícil de conhecer, compreender e manipular. Seus múltiplos componentes – estruturas de memória, processos background, processos de usuário – têm uma funcionalidade integrada e complexa, cujo entendimento, embora fundamental para a boa administração do banco Oracle, muitas vezes não é amplamente dominado.

Especialmente naquilo que se refere às estruturas de memória, de que trataremos neste artigo, a automatização paulatina da configuração, apesar de todas as vantagens que evidentemente traz para o trabalho do DBA na maior parte dos casos, acabou colaborando para torná-la ainda menos acessível e, por isso, pouco dominada.

Nenhum banco de dados, por mais e melhores recursos de auto-ajuste que possua, pode prescindir do trabalho efetivo do DBA e do seu conhecimento subjetivo a respeito do banco em si, de suas estruturas e de sua importância para o negócio da empresa. Sob esta perspectiva, uma boa configuração das estruturas de memória do banco de dados Oracle, ajustada às necessidades específicas de cada caso – resultante, portanto, de um processo continuado e proativo de tuning – terá como consequência maiores ganhos de performance, um desempenho mais otimizado e o melhor atendimento de sua finalidade negocial.

A finalidade deste artigo, então, é abrir um pouco a “caixa-preta” da arquitetura, para que os administradores de bancos de dados Oracle possam enxergar as estruturas de memória que a compõe, compreender a sua funcionalidade e utilizá-las do modo mais favorável ao seu trabalho, sem abrir mão dos recursos automáticos de configuração, mas buscando, ao invés, favorecê-los.

Comecemos, pois, com a descrição das estruturas de memória que compõe o banco de dados Oracle.

Descrevendo a memória

Costuma-se definir uma Oracle instance (instância Oracle) como um conjunto formado por área de memória e processos background (processos alocados no servidor com funções específicas). Deixando de lado os processos e sabendo que a instância Oracle é que dispara o processo de inicialização do banco de dados, temos como consequência lógica que a área de memória a ser utilizada é alocada já nesta fase.

Mas isto que chamamos área de memória, genericamente, na verdade é um conjunto formado por estruturas maiores (divididos, ainda, em subestruturas com funcionalidades específicas – algumas diretamente configuráveis, outros não), que são:

• SGA (system global area): conjunto de estruturas de memória compartilhada, ou seja, cujo conteúdo é compartilhado por todos os processos vinculados à instância Oracle (processos background e processos server, ligados às sessões dos usuários conectados ao banco de dados);

• PGA (program global area): área de memória privativa de um processo (seja ele background ou server), cujo conteúdo não é compartilhado com outros processos ou entre as sessões dos usuários. Muito embora a PGA seja individualizada, sua configuração se dá pelo total disponibilizado e alocado para a instância;

• UGA (user global area): memória associada especificamente às sessões dos usuários;

• áreas de código (software code areas): áreas de armazenamento do código (potencialmente) em execução pelo banco Oracle.

Das estruturas mencionadas, aquelas diretamente configuráveis pelo DBA (e que afetam mais intensamente a performance do banco de dados) são a SGA e a PGA. Sendo assim, configuram o nosso foco de interesse principal e, por isso, vamos descrevê-las mais detalhadamente.

Mas, antes de falar das estruturas que compõe a área de memória alocada para o banco de dados Oracle, precisamos compreender como se faz a sua configuração. Coexistem, na versão 11g Release 2, três grandes métodos para isso. Vamos, inicialmente, descrever estes métodos, com suas diferenças e vantagens.

Métodos de configuração de memória

Ao configurar a área de memória para o banco de dados Oracle, o que o DBA está fazendo, efetivamente, é definir a forma de gerenciamento de memória que pretende utilizar para o banco que está administrando.

O primeiro – e mais antigo – método de gerenciamento de memória é o manual. Na documentação Oracle, será chamado manual memory management. E é chamado manual porque, ao optar por ele, o DBA precisará definir manualmente o tamanho de cada um dos componentes da SGA e o tamanho da PGA. Ou seja, o gerenciamento manual envolve a configuração manual de cada parâmetro relacionado com as estruturas de memória já mencionadas.

Além de ser um método mais trabalhoso para o DBA (pois o ajuste mais preciso dos parâmetros requer o trabalho de acompanhamento da performance do banco de dados em uso, uma tarefa intensiva de tuning de memória), o método manual tem a desvantagem de limitar a própria eficácia. Pois, na medida em que o banco de dados é acessado pelos usuários e tem suas informações lidas e manipuladas, podem ocorrer variações nas necessidades de alocação de memória, conforme o perfil de acesso em cada momento. É uma tarefa impossível, para qualquer DBA, acompanhar toda a flutuação de requisições de memória do banco de dados no decorrer de um dia de trabalho. Menos ainda conseguirá fazer o ajuste necessário de cada parâmetro configurado em resposta a essas mesmas requisições.

Apesar dessas desvantagens, o método manual persistiu no banco de dados Oracle como o único método disponível até a versão 8i. A partir da versão 9i, com a introdução de parâmetros dinâmicos de configuração, a parametrização da memória tornou-se, ao menos parcialmente, dinâmica e começou a caminhar para a automatização.

Com o Oracle 10g, foi criado o método de alocação automática da memória compartilhada, o ASMM (automatic shared memory management). Por este método, o DBA continuava parametrizando individual e manualmente a PGA, mas, na configuração da SGA – memória compartilhada – podia optar por definir um valor total, que serviria como referência para limitar a alocação da SGA. Nesse caso, cada componente da SGA alocaria o que fosse necessário para sua utilização, no limite daquele total e respeitando a alocação já realizada pelos demais componentes, de modo dinâmico e automático. Ou seja: se as necessidades de determinado componente da SGA aumentassem, no decorrer da utilização do banco de dados, os processos de monitoração calculariam essa necessidade e determinariam a alocação de mais memória para esse componente, realizando seu aumento de tamanho de acordo com o cálculo realizado.

Além de poupar ao DBA o trabalho de monitorar o banco de dados para definir manualmente o tamanho de cada componente individual da SGA, o ASMM tem a vantagem de dar cobertura às necessidades dinâmicas de alocação de memória, alocando ou desalocando memória de cada componente da SGA na medida em que as sessões dos usuários demandarem a utilização (com maior ou menor intensidade) desses mesmos componentes.

Por fim, o Oracle 11g introduziu o método AMM – automatic memory management. Por este método, não apenas a SGA passa a ter sua configuração automatizada, mas também a PGA. A tarefa do DBA será definir um valor de referência para toda a memória. Uma vez que a instância esteja iniciada e este total de memória parametrizado este já alocado, o próprio banco de dados Oracle, através de processos background e da monitoração das sessões ativas conectadas, calculará automática e periodicamente a melhor forma de distribuir este total entre a PGA e cada componente da SGA. Portanto, conforme muda o perfil de acesso ao banco de dados, a memória é alocada ou desalocada entre os componentes, de forma dinâmica e automática, favorecendo uns e desfavorecendo outros, com a finalidade de obter a melhor performance possível na utilização do banco Oracle.

O AMM, como método, é mais abrangente que o ASMM, pelo fato de englobar a PGA, fazendo uma automatização completa da alocação de memória Oracle.

No entanto, é preciso deixar aqui um alerta: seja qual for o método escolhido pelo DBA, por mais automático e dinâmico que seja, não o eximirá de monitorar a performance do banco de dados. Pois a memória não é o único fator crítico no processo de tuning. O DBA precisará sempre verificar se não estão ocorrendo interferências de fatores externos, redutores de performance, na alocação de memória. E se o próprio método por ele escolhido é, de fato, o mais adequado para o caso concreto do banco de dados que ele está administrando.

Uma dica que pode ser muito útil quando o DBA opta por um método automático de gerenciamento de memória – ASMM ou AMM – é a configuração manual de valores mínimos de alocação para cada componente da SGA. Isso impede que determinado componente, em dado momento pouco requisitado, seja reduzido a um tamanho muito pequeno e, tornando-se depois mais requisitado, precise fazer uma alocação maior de memória para chegar ao tamanho que atende às necessidades das sessões dos usuários. Pois essa alocação mais frequente e de tamanho maior gera um custo em termos de performance. Nesse caso, ainda que o tamanho de cada componente esteja adequado, o custo para chegar a esse tamanho, no processo de alocação de memória, faz com que a performance do banco de dados se reduza, impedindo que atenda a contento às requisições dos usuários a ele conectados. Ao final do artigo, voltaremos a detalhar melhor esta combinação de técnicas.

SGA – a área compartilhada

A SGA (system global area, anteriormente também conhecida como shared global area), juntamente com os processos background, é a área de memória que compõe a instância Oracle. É a área de leitura e escrita de informações. Toda informação armazenada no banco de dados Oracle, enquanto informação lida ou manipulada de alguma forma, está sendo acessada na SGA.

Por isso, é característico da SGA que seja uma área de memória compartilhada. A SGA é uma área de memória comum a todos os processos server (processos que servem às conexões dos usuários, enviando suas requisições e recebendo do banco de dados as respostas a essas requisições), que podem acessá-la sem restrições para a leitura e a escrita dos dados.

Em que momento a SGA é alocada? Como cada instância possui a sua própria SGA e a área de memória não tem existência autônoma em relação à instância, a alocação da memória configurada para a SGA ocorre no startup da instância. Como consequência lógica, quando a instância é derrubada (shutdown), a SGA não pode permanecer alocada, pois está vinculada à arquitetura da instância.

Por uma questão de eficiência, a SGA é alocada em unidades de tamanho uniforme, denominadas grânulos (granules). Seu tamanho é determinado pelo espaço total de memória alocado para a SGA e também é dependente de plataforma. Como regra geral aplicável à maioria das plataformas, conforme a documentação Oracle para a versão 11g Release 2, pode-se afirmar, a respeito do granule: seu tamanho será de 4 Mb, quando o tamanho total da SGA for menor ou igual a 1 Gb (caso raríssimo na prática); quando a SGA total for maior do que 1 Gb, o granule size será 16 Mb. Pode-se verificar o tamanho do grânulo através de consulta direta à view V$SGAINFO, conforme se pode ver pela figura abaixo.

Figura 1. Consultando o tamanho do grânulo através da view V$SGAINFO.

A figura também ilustra o tamanho do grânulo – 64 Mb – que não atende, neste caso, à regra geral anteriormente enunciada. Isso se deve à especificidade de plataforma: trata-se de um Linux 64-bit, com um total de memória alocado para a SGA superior a 1 Gb. Neste caso, o tamanho do grânulo será de 64 Mb, ao invés de 16 Mb, como seria para a generalidade das plataformas. Outro exemplo de plataforma que não atende à regra geral é o Windows 32-bit (hoje cada vez menos em uso), cujo granule size é de 8 Mb para uma área total de SGA maior do que 1 Gb.

Na consulta à view V$SGAINFO também se pode verificar que a SGA não é um bloco único de memória, mas um conjunto formado por diversos componentes (conforme já foi dito anteriormente), cada qual alocando um espaço determinado e cuja soma pode ser limitada pela área total de memória destinada à SGA, sempre que o método escolhido pelo DBA para o gerenciamento de memória for automático (ASMM ou AMM).

Neste artigo, queremos discutir sobre o funcionamento de dois componentes principais da SGA: o database buffer cache e a shared pool.

Uma área para os dados – database buffer cache

A finalidade do database buffer cache (ou, simplesmente, buffer cache) é armazenar cópias dos blocos de dados lidos a partir dos datafiles e compartilhá-las entre os usuários conectados ao banco Oracle. O database buffer cache é subdividido em buffers, cada qual com o tamanho de um bloco de dados[1] (data block). Existe, portanto, uma correspondência direta entre o tamanho de cada buffer no cache e o tamanho de cada bloco de dados, que é a unidade mínima de leitura e escrita do banco de dados Oracle.

O database buffer cache armazena tanto os blocos de dados que estão sendo lidos (e, possivelmente, alterados) correntemente, como os blocos recentemente utilizados. Esse é um mecanismo-chave da base de dados Oracle, no que se refere ao I/O, e o motivo disso é que, guardando as cópias dos blocos de dados, o database buffer cache permite que as sessões dos usuários façam acesso a eles diretamente na área de memória, evitando a necessidade de acessar o conteúdo dos data blocks em disco, nos data files e, por isso, reduzindo o I/O físico.

Quando uma transação altera (por meio de um comando DML – insert, update, delete, merge) as informações constantes do banco de dados Oracle, não o faz diretamente sobre os data blocks, mas sobre a sua cópia residente no database buffer cache. Se o bloco de dados ao qual a transação faz referência não se encontra copiado no buffer cache, essa cópia é então realizada e a transação altera sempre e somente o conteúdo da área de memória, para que todas as operações de leitura e escrita subsequentes sejam realizadas sem geração de I/O físico. Uma vez executada a transação, quando esta for finalizada pela operação de commit, a gravação dos dados alterados, uma vez mais, não será realizada sobre os data files, mas sobre os redo log files, e apenas serão gravados os metadados, de tal forma que o I/O, embora mais frequente, não será grande. Os dados efetivamente alterados serão gravados aos poucos, pelo processo background DBWn, de modo que a performance geral da base de dados não será comprometida, seja pela grande quantidade de pequenas transações concorrentes escrevendo suas alterações, seja pela quantidade significativa de dados gravados por transações maiores.

Em todo este mecanismo que descrevemos, fundamental para a boa performance da base de dados Oracle, um requisito básico a considerar é que o database buffer cache tenha um tamanho adequado, ajustado em relação à quantidade de dados efetivamente acessada pelas transações. A partir disso, um percentual absolutamente majoritário desses dados poderá ser lido exclusivamente a partir da área de memória, reduzindo o I/O físico apenas às informações que, por serem de acesso mais eventual ou menos recente, deverão ser buscadas nos blocos de dados físicos dos data files.

Mas o tamanho do database buffer cache não deve ser calculado apenas em função dos data blocks cuja imagem será copiada para eles. Também é preciso levar em conta que, com certa frequência, essas imagens precisarão ser substituídas por outras, na medida em que algumas informações deixam de ser utilizadas e outras passam a ser acessadas, pela dinâmica própria das aplicações que usam o banco de dados Oracle. E que novas imagens dos blocos de dados precisarão ser copiadas sem que, necessariamente, essa substituição ocorra. Por isso, é necessário que o database buffer cache tenha também espaço livre – buffers livres – para essas novas imagens que virão. Havendo esse espaço livre, não haverá excesso de I/O com liberação desnecessária de buffers ocupados para dar lugar a novo conteúdo.

Quando os buffers do cache de dados precisam ser liberados constantemente (para que novas imagens de dados possam ser carregadas), o desempenho do banco de dados torna-se sofrível, pelo excessivo I/O gerado.

Por isso, uma configuração bem ajustada do database buffer cache é importantíssima para um bom desempenho do banco de dados Oracle. E é importante salientar que não estamos levando em conta o método de gerenciamento de memória utilizado na configuração do banco, se automático (AMM ou ASMM) ou manual. No primeiro caso, o ajuste do database buffer cache dependerá de uma configuração indireta, ou seja, do total de memória disponibilizado; no segundo caso, esse mesmo ajuste dependerá de uma parametrização direta. Seja como for, para que o banco possa contar com um bom desempenho de leitura e escrita de dados, será fundamental que o database buffer cache tenha área suficiente para poder garantir que a maior parte dos acessos aos dados realizados no banco Oracle seja realizado exclusivamente em memória e sem que haja demanda de I/O para a liberação de espaço.

Uma área para os comandos – shared pool

Mas nem só de dados vive o banco Oracle. Se não houver um cache específico para comandos e metadados – e bem configurado – não se pode esperar um boa performance. Esse cache é a shared pool, assim chamada por ser uma área de memória dividida em vários subcomponentes, dos quais os mais importantes são para o nosso propósito são: library cache (onde se localizam as shared SQL areas) e data dictionary cache. A área de memória destinada para a shared pool como um todo é dividida automaticamente entre esses (e os demais) subcomponentes.

Antes de falarmos especificamente do mecanismo da shared pool e dos subcomponentes mencionados, precisamos dizer que, por trás da execução de um comando em um banco de dados Oracle, há um conjunto bastante complexo de operações. Uma dessas operações, a chamada fase de parse, é a que envolve o maior custo operacional: o comando a ser executado passa por uma verificação sintática, que determina se a sintaxe utiliza está correta ou não; depois, passa por uma análise semântica, o que equivale a verificar se o comando sintaticamente correto faz sentido para o banco de dados, podendo, então, ser Basta dizer queexecutado; em seguida, são analisados os objetos mencionados no comando, suas dependências, relações, privilégios, usuário executante; por fim, os diversos caminhos de execução possíveis do comando são montados, analisados e comparados em termos de custo, até que seja escolhido o plano de execução com o caminho de acesso aos dados que representa o menor custo.

Se a fase de parse precisasse ser refeita a cada vez que o mesmo comando é executado no banco de dados, o custo para cada execução de sintaxes idênticas seria muito alto. Então, a Oracle imaginou criar uma estrutura de memória destinada a armazenar o resultado da fase de parse, de tal modo que pudesse ser reaproveitada a cada vez que o mesmo comando fosse novamente executado por uma sessão de usuário conectada ao banco de dados.

Com essa finalidade geral, surgiu a library cache. Dentro da library cache, estão as shared SQL areas (áreas SQL compartilhadas), que armazenam a árvore de parse do comando e o seu plano de execução. Sempre que o mesmo comando (de idêntica sintaxe) for executado de novo, a sua árvore de parse e o seu plano de execução podem ser reaproveitados, desde que ainda se encontrem na área SQL compartilhada.

Pode ocorrer que o resultado do parse de um comando e seu plano de execução não sejam encontrados na library cache, sob algumas condições: se já faz um certo tempo que o comando não é executado e sua execução anterior pode ter sido removida da shared pool para dar lugar à parse tree e ao plano de execução de um comando mais recente; ou se a execução mais recente do comando não obedece rigorosamente à mesma sintaxe (para que um comando seja considerado idêntico a outro, não pode haver diferença de sintaxe entre eles, nem mesmo por um espaço em branco ou por uma letra maiúscula ou minúscula).

Mas, se o reaproveitamento ocorrer, pelo fato da shared SQL area correspondente conter a árvore de parse e o plano de execução do comando em questão, o tempo de execução do mesmo comando será significativa e sensivelmente menor. Isso pode ser facilmente testado com uma sintaxe simples de consulta (SELECT) através, por exemplo, do prompt de comando do SQL*Plus. Simplesmente execute o mesmo comando duas vezes e você verá que a segunda execução será mais rápida que a primeira. Isso se deve não apenas ao fato da imagem dos dados consultados já se encontrarem no database buffer cache; também ocorre porque a fase de parse e o plano de execução do comando já estarem armazenados na área SQL compartilhada, quando da segunda vez em que o comando é executado, e não precisarem ser refeitos.

O que o library cache faz para os comandos mais executados (e mais recentemente executados) no banco de dados Oracle, o data dictionary cache realiza, de modo análogo, para os objetos mais acessados do dicionário de dados. O data dictionary cache também é conhecido como row cache, porque não armazena buffers, mas dados. Assim como o library cache, seu objetivo é reduzir o custo e aumentar a performance de execução dos comandos, porém através do armazenamento em memória das definições mais acessadas do dicionário de dados, reduzindo o I/O relacionado ao acesso às informações do mesmo em disco.

Nos bancos de dados que servem a aplicações com perfil mais próximo do OLTP (online transaction processing), a shared pool tem um papel mais relevante. Por isso, em ambientes online, a configuração da shared pool assume uma importância maior e deve estar na lista de prioridades do DBA. São válidas, neste caso, as observações que já fizemos sobre a configuração do database buffer cache: é preciso ter em mente, na estimativa da área de memória a ser alocada para o banco de dados, qual o percentual desse total que precisará ser utilizado pela shared pool, como garantia de redução de I/O sobre o dicionário de dados e para ter certeza, no que depende da ação do DBA, do máximo reaproveitamento dos comandos em execução.

PGA – a área de trabalho

Ao contrário da SGA, que é uma área de memória compartilhada entre todos os processos e sessões de usuário, a PGA – program global area – é uma área de memória vinculada a processos (process specific) e, portanto, não compartilhada. Seu conteúdo é privativo dos processos que o geram e requerem a sua alocação em memória, não podendo ser visualizados pelos demais processos e sessões conectados ao banco Oracle.

No que se refere aos processos server, o conteúdo da PGA por eles alocada se divide em áreas específicas, das quais duas são de nosso interesse imediato: as SQL work areas (áreas de trabalho SQL), que se destinam a armazenar dados que devem ser ordenados (operações de sort) e também possuem espaço reservado para operações de hash e bitmap merge (das quais não vamos nos ocupar neste artigo); e a private SQL area (área SQL privada)[2], que se destina ao armazenamento de informações específicas do processamento de comandos da sessão (por exemplo, o conteúdo das bind variables e os cursors utilizados na sessão serão armazenados nesta área).

O ponto crítico para o DBA, na configuração da PGA automática ou manual, é saber levar em consideração o perfil das operações de ordenação (sort) de dados. Através da parametrização, o DBA define a área total de memória destinada à PGA. Cada processo, porém, alocará o número de work areas necessário para a realização de sua operação. Sabendo como se comporta a ordenação de dados no banco por ele administrado – se envolvem maior ou menor quantidade de dados, se são mais frequentes ou mais esporádicas – o DBA poderá definir a necessidade de uma área maior ou menor para a PGA (configurando-a através de parâmetro específico nas configurações manual e ASMM, ou calculando o percentual que lhe deve ser destinado dentro da área total de memória Oracle, pelo método AMM).

Algumas dicas práticas para o DBA

Depois de haver exposto as questões teóricas que envolvem a configuração da memória destinada ao uso do banco de dados Oracle, penso que é importante colocar, como conclusão deste artigo, também o enfoque prático, para que o leitor saiba como utilizar os conceitos até aqui desenvolvidos.

Um aspecto prático fundamental são os próprios parâmetros de configuração. Conforme o método de gerenciamento de memória escolhido pelo DBA, os parâmetros podem ser diferentes.

Se o método de gerenciamento escolhido for o manual, a PGA e cada um dos subcomponentes da SGA devem ser configurados individualmente, isto é, existe um parâmetro para cada estrutura de memória e seus subcomponentes. Assim:

• PGA: parâmetro pga_aggregate_target

• database buffer cache: parâmetro db_cache_size[3] (indiretamente, o parâmetro db_block_size interfere na configuração do database buffer cache, pois cada buffer terá o tamanho de um bloco de dados)

• shared pool: parâmetro shared_pool_size (o DBA não parametriza diretamente os subcomponentes da shared pool, cujo tamanho é calculado internamente pelo banco de dados)

• large pool: parâmetro large_pool_size

• redo log buffer: parâmetro log_buffer (se o valor default calculado pelo banco de dados for suficiente, o DBA não deve configurá-lo explicitamente)

• java pool: parâmetro java_pool_size

• streams pool: parâmetro streams_pool_size

Além dos parâmetros individuais, há ainda dois gerais: sga_target e sga_max_target. Estes parâmetros, utilizados em conjunto com o método manual, estabelecem o limite máximo de memória que a SGA como um todo pode alocar, permitindo que os parâmetros individuais possam ser alterados dinamicamente (ao menos, aqueles que tiverem esta característica). Também o tamanho da PGA pode ser alterado dinamicamente (isto é, sem necessidade de reiniciar o banco de dados).

Como já dissemos anteriormente, a grande desvantagem do método manual é a fixação dos tamanhos das estruturas de memória, tamanhos estes que só podem ser alterados também de forma manual. E nem sempre os tamanhos fixados pelo DBA poderão satisfazer às necessidades dinâmicas de utilização de memória que se apresentam no uso de um banco de dados ao longo do tempo.

Portanto, o uso do método manual vai exigir do DBA maior esforço de tuning de banco de dados. A monitoração da performance do banco será necessariamente mais intensa e isso não evitará que as ações do DBA para a melhoria de performance sejam mais reativas do que proativas.

Os métodos de gerenciamento automático de memória reduzem significativamente a quantidade de parâmetros a serem configurados pelo DBA.

Pelo ASMM (gerenciamento da memória compartilhada – SGA), o DBA deve apenas configurar os parâmetros sga_target e sga_max_target. O primeiro define o tamanho total da SGA efetivamente em uso e o segundo define o tamanho máximo que a SGA poderá atingir. Como este método não contempla a PGA, esta deve ser manualmente configurada através do parâmetro pga_aggregate_target.

No método AMM (gerenciamento de toda a memória alocada para o banco de dados – SGA e PGA), os parâmetros a serem configurados pelo DBA são: memory_target e memory_max_target. Analogamente aos parâmetros do método ASMM, o primeiro define a soma de SGA e PGA efetivamente em uso e o segundo define a soma de SGA e PGA máxima que a memória alocada para o banco Oracle poderá atingir.

Pode-se discutir, nos métodos automáticos, qual a utilidade de definir um tamanho máximo que já estará pré-alocado (no ASMM, o sga_max_size; no AMM, o memory_max_target) e um tamanho menor que estará sendo efetivamente utilizado (no ASMM, o sga_target; no AMM, o sga_max_size). Penso que isso pode ter sua utilidade enquanto o DBA ainda estiver testando a real necessidade de memória do banco Oracle que administra. Pois o limite máximo permite o aumento ou a redução dinâmicos do tamanho efetivamente em uso. Depois que o DBA tiver concluído seus testes e definido qual o tamanho ideal da estrutura de memória para o seu banco de dados, não me parece que seja prático ou útil que haja qualquer diferença entre os parâmetros de limite máximo e de tamanho em uso. Para utilizar os métodos automáticos, basta configurar seus parâmetros com valores maiores do que zero. Estes métodos não são excludentes. Se os parâmetros de ambos (ASMM e AMM) estiverem configurados com valores maiores do que zero, o banco Oracle utilizará suas diretrizes em conjunto. Além disso, também é possível utilizar os parâmetros de configuração manual juntamente com os métodos automáticos. Veja-se, por exemplo, a seguinte configuração (foram selecionados apenas os parâmetros relevantes):

Figura 2. Exemplo de configuração do método automático com valores mínimos manualmente definidos.

Neste banco de dados Oracle 11g Release 2, que utiliza o método ASMM, a área total de memória compartilhada alocada (sga_max_size) é de 32 Gb. A área de memória compartilhada efetivamente em uso (sga_target) é, igualmente, de 32 Gb. A PGA alocada (pga_aggregate_target) é de 16 Gb. Portanto, considerando a alocação efetiva total da PGA, o banco Oracle assim configurado utiliza um total de 48 Gb. Dos 32 Gb destinados à memória compartilhada (SGA), o DBA estabeleceu alguns valores mínimos para algumas estruturas, através dos parâmetros de configuração manual. Assim, o database buffer cache (db_cache_size) nunca alocará menos do que 1 Gb; a shared pool (shared_pool_size) nunca poderá ficar menor do que 512 Mb; e o java pool (java_pool_size) não será reduzido a um tamanho menor do que 256 Mb. No entanto, para além desses valores mínimos, estas estruturas poderão ser aumentadas ou reduzidas automaticamente, conforme as necessidades calculadas pelo banco de dados Oracle, com base em suas estatísticas de acesso, a qualquer momento e para qualquer tamanho, obedecendo às seguintes regras:

• sua soma não deve ultrapassar o máximo permitido para a alocação da SGA;

• nenhum componente pode ser zerado;

• nenhum componente pode ser reduzido para menos do que o seu valor mínimo configurado explicitamente pelo DBA;

• se algum componente não foi mencionado explicitamente na configuração do DBA, seu limite mínimo será aquele internamente definido pelo banco Oracle e o tamanho desse componente nunca poderá ser menor do que esse valor.

A questão que se apresenta é: com que objetivo o DBA interfere no gerenciamento automático de memória, utilizando parâmetros de configuração manual e estabelecendo limites mínimos de alocação? A resposta para esta pergunta está na palavra overhead. Se o objetivo do gerenciamento automático de memória é uma melhor resposta do banco de dados em termos de performance, pelo ajuste dinâmico da configuração de memória às necessidades que se apresentam e se modificam a cada momento, com a utilização do banco, esse ajuste dinâmico tem um custo. Ele precisa alocar memória com frequência, aumentando ou diminuindo as estruturas, de modo a favorecer umas e desfavorecer outras, conforme sejam mais ou menos importantes para as operações executadas. Ora, isso tem um custo, que pode ser tanto mais elevado quanto maior seja a diferença de tamanho que uma estrutura pode requerer de um momento para outro. E, como consequência, um método que veio para ajudar na melhor utilização da memória, poderá acabar prejudicando a performance das operações. Por isso, se o DBA puder determinar tamanhos mínimos, ao menos para as estruturas mais importantes dentro da realidade de seu banco Oracle, esse esforço de alocação frequente – que chamamos overhead – será minimizado. E o aumento ou redução dos componentes de memória, quando ocorrer, terá menor (ou não terá) impacto negativo na performance das operações executadas pelo usuário.

Por fim, ainda que não possamos nos alongar neste aspecto e tenhamos de nos contentar com uma pequena menção, de passagem, ao terminar este artigo precisamos ainda mencionar que todas as características de ajuste automático de memória introduzidas nas versões recentes do banco de dados Oracle continuam exigindo a atuação do DBA. O DBA deve monitorar o consumo de recursos e a alocação de memória do banco. Seu acompanhamento e intervenção periódica não são dispensáveis. As ferramentas disponíveis – tanto os relatórios que se pode gerar através do STATSPACK quanto os gráficos, relatórios e diagnósticos que podem ser obtidos através do OEM (Oracle Enterprise Manager) – atuam como excelentes facilitadores, que fornecem uma excelente visão de conjunto e um ótimo detalhamento do estado do banco e de seu consumo de recursos, mas não são substitutos do DBA. Ao fim e ao cabo, a decisão final sobre as ações a serem executadas na busca da configuração de memória mais adequada e responsiva será sempre do DBA.

[1] Para as finalidades deste artigo, vamos nos referir unicamente ao tamanho de bloco de dados default, configurado na criação do banco de dados por meio do parâmetro db_block_size. Não serão consideradas as possibilidades de configuração de outros tamanhos não default de blocos de dados.

[2] Não confundir com a shared SQL area, que, como vimos, faz parte do subcomponente library cache da shared pool (SGA).

[3] Para as finalidades deste artigo, estamos desconsiderando a configuração de caches adicionais (tanto aqueles que suportam tablespaces com diferentes tamanhos de data block quando aqueles que se destinam a armazenar dados de objetos com acesso diferenciado em relação à média do banco de dados). No primeiro caso, em linhas gerais, a configuração seria feita através dos parâmetros db_nK_cache_size. No segundo caso, por meio dos parâmetros db_keep_cache_size e db_recycle_cache_size. Também estamos desconsiderando a possibilidade de utilização de memória flash, possível a partir do Oracle 11g, e que merece um artigo em separado para o seu estudo.