By Eder

Este artigo é um guia passo a passo para fazer um tuning no Red Hat Enterprise Linux em plataformas x86 e x86-64 que estejam rodando Oracle 9i (32/64 bits) e Oracle 10g (32/64 bits) todos standalones e também RAC. Este artigo cobre Red Hat Enterprise Linux Advanced Server 3, 4 e 2.1.

Geral

Quando nos voltamos às grandes bases de dados a plataforma de arquitetura híbrida x86-64 é extremamente recomendada em relação à plataforma x86. As plataformas 64-bit podem alcançar mais do que 4GB de memória sem workarounds. Com plataformas de 32-bits há diversas soluções de workaround para as bases de dados que usam lotes da memória, por exemplo, referem-se à Using Very Large Memory (VLM). Caso você não saiba qual plataforma está usando, basta executar o seguinte comando:
dmidecode
Ou
/proc/cpuinfo

Se executar o comando:
uname -a

ele pode lhe dar informações não reais tendo em vista que o Kernel do Linux 32-bits pode funcionar em plataformas x86-64. Mas se este comando exibir x86_64, então você está rodando um Kernel de Linux 64-bit em uma plataforma x86-64.

Arquitetura de 32-bits

O RHEL 3/4 com kernel smp pode ser usado em sistemas com de até 16GB de RAM. O kernel hugemem é requerido a fim de usar toda a memória do sistemas que tem mais de 16GB de RAM e até 64GB. Entretanto, é recomendado o kernel hugemem sempre que um sistema estiver usando 8GB ou superior.
Com a arquitetura x86 a memória compreendida entre 16MB e 896MB da memória física é conhecida como “low memory” (ZONE_NORMAL) que o qual é permanentemente mapeado dentro do kernel. Muitos recursos do kernel precisam residir dentro da zona low memory. De fato, muitas operações do kernel podem apenas localizar-se nesta zona. Isso significa que a área low memory é a maior zona de performance crítica. Por exemplo, se você estiver executando aplicações/programas de recursos intensivos e/ou muita memória física, então a low memory pode tornar-se pequena quando mais estruturas do kernel precisem ser alocadas nesta área inanição de low memory acontece quando LowFree no /proc/meminfo torna-se muito baixo acompanhado por um ponto repentino na atividade de paginação. Para liberar memória na zona low memory, o kernel pula agressivamente buffers entre as zonas low memory e high memory que se torna visível como paginação (não confunda isso com a paginação na partição swap). Se o kernel for incapaz de liberar bastante memória na zona de low memory, então o kernel pode “pendurar” o sistema.

Atividade de paginação pode ser monitorado usando o comando vmstat ou usando o comando sar (option ‘-B’) que vem com o RPM sysstat. Uma vez que o Linux tenta utilizar toda a zona de low memory, uma LowFree pequena no /proc/meminfo não significa necessariamente que o sistema está com pouca memória. Entretanto, quando o sistema começar à mostrar o incremento de atividade de paginação quando o LowFree estiver abaixo de 50MB, então o kernel hugemem deve ser instalado. A estabilidade que você ganha usando o kernel hugemem compensa por todo o impacto do desempenho resultando da divisão da memória 4GB-4GB kernel/usuário dividida neste kernel(um sistema x86 do clássico 32 racham o espaço de endereço disponível de 4 GB em 3GB de espaço de memória virtual para processos do usuário e um espaço de 1 GB para o kernel). Para ver alguns alocamentos na zona low memory, consultar a /proc/meminfo e ao slabtop (1) para mais informação. Note que Huge Pages liberariam memória na zona baixa da memória desde que o sistema nçao tenha bookdeeping (contabilidade) a fazer para essa parte da memória virtual.

Se você instalar o RHEL ¾ kernel hugemem assegure que qualquer driver que estiver usando (por exemplo, drivers multipath) são certificados com o kernel hugemem.

No RHEL 2.1, o kernel smp é capaz de manipular até 4GB de RAM. O kernel kernel-enterprise precisa ser usado para sistemas com mais de 4GB de RAM até 16GB.

In RHEL 2.1, the smp kernel is capable of handling up to 4GB of RAM. The kernel-enterprise kernel should be used for systems with more than 4GB of RAM up to 16GB.

Arquitetura 64-bit

Esta é a arquitetura que seria usada sempre que possível. Se você puder usar a plataforma x86-64, assegure que todos os drivers que você precisa são suportados no x86-64. Futuramente, assegure que todas aplicações são suportadas no x86-64.

Bom, agora que já falamos um pouco sobre SO, vamos agora abordar assuntos de Oracle, propriamente dito…

Quando falamos em Tunning de Oracle Database, os primeiros alvos que visualizamos são: CPU e memória. Certamente esses dois são os mais visados pois tudo que existe no SO ou mesmo no Banco de Dados Oracle, utiliza os recursos de CPU e memória mas têm outros alvos muito importantes também que merecem um pouco da nossa atenção….

Vamos falar, à princípio, de alguns pontos cruciais do Banco de Dados e abordá-los, por enquanto sem muito aprofundamento.

Latch

O que é um Latch? Latch é uma proteção dos buffers de memória semelhante aos locks das linhas das tabelas. Existe numerosos tipos de Latches para todos os diferentes tipos de buffer de área de memória, por exemplo, no Oracle 9.2, existem 239 Latches enquanto que no Oracle 10.2 existem 382 Latches.

Não é possível fazer tunning em Latches. Problemas com Latches são indicações de que outros problemas estão ocorrendo e pode auxiliar-nos à nos concentrar no verdadeiro problema deperformance que pode estar acontecendo.

Latches missed, spins e sleeps

O que é um Latch missed? Quando um latch é requisitado e a sessão de um buffer requisitado é fechado ou travado por outro processo, então, um latch livre é gerado. Entretanto, a segunda requisição para um latch, que o qual já foi retido por outro processo, irá esperar o requerido latch tornar-se livre para uso. O lock da linha de uma tabela simplesmente espera a liberação da linha tentando constantemente um lock na mesma. Ao contrário, um latch missed irá gerar um dos dois tipos de ação:

1) Coloca o latch em immediate mode que fará com que o processo fique requisitando um latch para tomar uma ação alternativa;

2) Coloca o latch requisitado em willing-to-wait mode e isso faz com que ele fique tentando repetidamente e spin (gira).

Quando o latch gira um determinado número de vezes, ele passa à sleep (dormir ) por um período de tempo. Spinning latches pode consumir uma grande quantidade de tempo de CPU. Quando ocorre um latch spin, ele repetidamente requisita um latch e isso pode afetar drasticamente se muitos latches spins estão ocorrendo ao mesmo tempo. Mas vamos nos aprofundar um pouco mais nesse tópico lá na frente pois precisamos de algumas outras informações.

Wait Event Interface

O que é um Bottleneck?

Bottleneck é literalemente uma pequena parte do hardware ou software que tem um processamento muito grande e está sendo afunilado através de uma área específica, ou seja, é quando está ocorrendo um processamento demasiado em uma área específica em relação à outra área.

O que pode causar um bottleneck? Certamente as causas são variadas mas, na maioria das vezes, a causa provém de códigos SQL mal escritos ou um Banco de Dados mal modelado. Raramente é problema de hardware mas quando ocorre, geralemente é uma estrutura de disco inapropriada para os redo logs e archive log.

Para detectar um potencial bottleneck, usaremos o Oracle Database Wait Event Interface que nada mais é do que views de performance dinâmica que contêm todos os tipos de estatísticas que nos permitem encontrar um bottleneck em potencial além de permitir fazer um drilldown em várias áreas de atividades no Banco de Dados. Essas views podem fornecer aos DBA’s que estão fazendo tuning, um respaldo muito grande até para identificar onde um determinado SQL pode ser alterado para melhorar a performance. Vale lembrar que esse método é REATIVO e não PROATIVO pois primeiro detectamos o problemas para depois resolvê-lo.

drilldown.gif

A figura acima mostra algumas ferramentas que podem ser usadas para fazer drilldown em wait events.


8 Responses to “Otimização e Tuning para Oracle em Red Hat”


  1. janeiro 18, 2012 às 3:06 pm

    Muito bom Eder, fica um gosto de ‘quero mais’..

  2. setembro 18, 2011 às 9:04 pm

    Good info. I reached on your website by accident, so thanks.

  3. 3 Marcio L. Cavalcante
    fevereiro 2, 2011 às 6:28 pm

    Boa tarde, estou criando um banco usando o assitente de criação (dbca) em um servidor com OS Red Hat 5 64 bits e 24GB de memoria RAM e na hora de alocar memoria a ferramenta mostra os 24GB de memoria porem na parte de distribuição SGA e PGA a 70% esta dando não mais que 4GB de RAM,
    poderia me uma dica que como solucionar o problema ?

  4. 4 Clovis Nery
    abril 26, 2008 às 2:48 pm

    Muito bom este artigo. Voce teria outras informacoes de otimizacao de banco de dados oracle??

    Agradeço.

  5. 5 Eder
    janeiro 22, 2008 às 4:09 pm

    Elaine Silva,

    Já está sendo atualizado todos os dias, aqui mesmo n site!!
    Qualquer dúvida é só falar!!

    Eder

  6. 6 Elaine Silva
    janeiro 18, 2008 às 5:36 pm

    Deve ser muito bom o artigo
    onde posso encontrá-lo???


Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s




dezembro 2016
S T Q Q S S D
« nov    
 1234
567891011
12131415161718
19202122232425
262728293031  

Estatísticas de Visitas

  • 129,751 visitas

%d blogueiros gostam disto: