Hoje foi um dia daqueles aqui na empresa, estou a alguns dias buscando uma solução para um problema de performance em um banco de dados de nosso RH, é aquela velha situação, usuário grita de um lado, o outro escuta e grita também e tudo começa a virar uma bola de neve, mesmo sem muitas vezes nenhum deles ter razão, ai só resta ao DBA acompanhar um a um, para checar e comprovar (mais uma vez) que o problema não é o sistema/banco e sim o procedimento que o usuário está executando… aff, faz parte da vida… ehehhehe
Mas tudo isso sempre tem o lado positivo, estive pesquisando algumas coisas sobre performance e achei algumas coisas interessantes, as quais vou listar abaixo, é bom para quem está iniciando na área de banco de dados, é a configuração bem básica para fazer um banco funcionar de acordo…. espero que aproveitem….
Oracle
O ORACLE funciona com 3 estruturas principais, como qualquer outro banco de dados, estas são MEMÓRIA, ARMAZENAMENTO E PROCESSAMENTO, estes 3 itens tem que trabalhar de forma alinhada para que o desempenho do banco de dados seja satisfatório, ou melhor, “Supere as expectativas dos usuários”, pois é isso que eles sempre querem… =]
O primeiro aspecto que vamos falar é da MEMÓRIA
O Oracle e outros bancos de dados necessitam de muita memória (dependendo da aplicação é claro) para funcionar, digamos que “quanto mais melhor”.
As áreas de memória do ORACLE são divididas basicamente em SGA e PGA, SGA é compartilhada e PGA é privada.
A imagem abaixo mostra de forma simplificada o funcionamento da memória no banco de dados:
A memória para o banco de dados é importante, pois é aonde transitam todos os dados entre o CLIENTE <-> SERVIDOR, cada requisição que o usuário faz é processada pelo banco de dados, é feita leitura de arquivos físicos muitas vezes e enviados para a memória, aonde são ordenados e enviados para o usuário finalmente….
O gerenciamento de memória tem sido aprimorado nas ultimas versões do ORACLE, hoje na versão 11g temos os parâmetros abaixo de forma simplificada para serem ajustados, após explico cada um deles…
Vejam que temos um parâmetro chamado MEMORY_TARGET, hoje basta ajustar esse parâmetro no ORACLE que ele faz o resto, ajustando os valores necessários para a SGA e PGA, além de todas as “subdivisões” dentro destas.
Também é possível utilizar parametrizações especificas para a SGA e PGA, muitas vezes aplicações solicitam isso, por exemplo o SAP, ele passa uma série de configurações para a PGA e SGA, além dos componentes que existem dentro destas, impossibilitando o uso de parâmetros mais gerais como o MEMORY_TARGET. Quando um parâmetro interno da memória é especificado e também temos o MEMORY_TARGET ativo, o que acontece é que este parâmetro passa a valer para ser o mínimo de memória utilizado para tal componente, imagine por exemplo, termos a configuração abaixo:
MEMORY_TARGET = 2GB
DB_CACHE_SIZE = 500MB
A partir deste momento, o banco vai dimensionar a PGA e SGA automaticamente, desde que o DB_CACHE_SIZE que está dentro da PGA tenha no mínimo 500MB.
Os parâmetros tem a ordem básica abaixo representada
- MEMORY_TARGET
- SGA_TARGET (SGA_MAX_SIZE)
- DB_CACHE_SIZE
- JAVA_POOL_SIZE
- LARGE_POOL_SIZE
- SHARED_POOL_SIZE
- LOG_BUFFER
- STREAMS_POOL_SIZE
- PGA_AGGREGATE_TARGET (_PGA_MAX_SIZE) (para funcionar tem que estar setado o parâmetro workarea_size_policy = auto)
- BITMAP_MERGE_AREA_SIZE
- CREATE_BITMAP_AREA_SIZE
- HASH_AREA_SIZE
- SORT_AREA_SIZE
- WORKAREA_SIZE_POLICY
O mais simples é sempre deixar o banco gerenciar tudo, ajustando o MEMORY_TARGET e o resto é com ele…. só ajustar outros parâmetros quando ver que o bixo tá pegando, se tiver algum problema de performance ou for expressamente recomendado pelo sistema que está rodando sobre este banco.
Estas views mostram a utilização detalhada de cada item dentro da memória total alocada pelo parâmetro MEMORY_TARGET
· V$MEMORY_DYNAMIC_COMPONENTS – Visualiza os dados da MEMORY_SIZE, mostrando como está a distribuição de memória automática do banco de dados
· V$MEMORY_RESIZE_OPS – Esta mostra as ultimas alterações que o banco de dados efetuou na alocação de memória.
· V$SGA_DYNAMIC_FREE_MEMORY – Memória livre para alocação
Também podemos ver mais a fundo como está o funcionamento da SGA na view
· SELECT * FROM V$SGA
Temos alguns outros SELECTS abaixo que nos ajudam a TUNAR a SGA e PGA com seus respectivos componentes…
- Este select mostra como está o uso dos buffers do banco, a coluna estd_physical_read_factor contém os valores que mudarão em percentual caso a memória (coluna size_for_estimate) seja ajustada.
- Entendemos que neste caso precisamos ajustar o parâmetro BUFFER_CACHE, porém se ele não estiver setado, o ORACLE está administrando ele automaticamente, talvez seja necessário aumentar a memória como um todo na SGA_TARGET ou MEMORY_TARGET.
SELECT size_for_estimate, buffers_for_estimate, estd_physical_read_factor, estd_physical_reads FROM V$DB_CACHE_ADVICE WHERE name = 'DEFAULT' AND block_size = (SELECT value FROM V$PARAMETER WHERE name = 'db_block_size') AND advice_status = 'ON'
- Ele mostra a situação, deve-se preocupar com o tamanho da SGA caso haja muitas entradas “multipass”
Select name, value from v$sysstat where name like ‘%workarea%’
- Na PGA podemos checar também os acertos de cache, a ORACLE recomenda que este valor esteja acima de 95%
Select to_char(round(value,4),’999.99’) || ‘%’ “PGA Hit Ratio” From sys.v_$pgastat Where name = ‘cache hit percentage’;