Ajuste o banco de dados DB2 no Windows em oito etapas simples

Diagnosticar e corrigir problemas de desempenho podem ser tarefas difíceis. Os problemas geralmente surgem quando menos se espera. Eles costumam crescer gradualmente e às vezes podem causar a indisponibilidade do aplicativo que está usando o banco de dados. É essencial, do ponto de vista do DBA, conhecer uma abordagem proativa para lidar com o desempenho antes mesmo que isso comece a prejudicar os negócios. Este artigo discute um processo analítico que ajudará os DBAs a chegar à raiz do problema em algumas etapas simples.

Sandeep Sethia, Staff Software Engineer, IBM

Sandeep SethiaSandeep Sethia trabalha como engenheiro de software da equipe do IBM India Software Lab. Ele passou a fazer parte da IBM em 2006 e atualmente trabalha com a equipe DB2 Performance.



Vaibhav Kulkarni, Advisory Software Engineer, IBM

Vaibhav KulkarniVaibhav Kulkarni é engenheiro de software consultor no India Software Labs da IBM. Sua especialidade é desempenho do DB2. Ele trabalha com a equipe DB2 Performance.



08/Out/2012

Visão geral

Para diagnosticar melhor os problemas de desempenho, este artigo discute um processo metódico para ajudar a determinar se o banco de dados está tendo problemas de desempenho e desenvolver ações corretivas. Quando o desempenho de um aplicativo do DB2® ou de e-business não está de acordo com as expectativas, toda a organização e seus resultados podem sair prejudicados.

O objetivo deste artigo é orientar DBAs na definição e diagnóstico de problemas de desempenho no DB2 no Windows®. O artigo abrange os seguintes tópicos:

  • Informações a serem coletadas usando ferramentas do Windows
  • Informações a serem coletadas usando ferramentas do DB2
  • Investigação e resolução de problemas

Suposições

Este artigo supõe que o leitor tem um conhecimento básico sobre bancos de dados, SQL e DB2 LUW. Conhecimento básico de ajuste de desempenho e de UNIX® serão de grande ajuda.


Problemas de desempenho e correlação com recursos do sistema

Os problemas de desempenho abrangem um grande grupo de cenários:

  • Consultas SQL com desempenho mais lento do que o esperado
  • Carga de trabalho ou tarefa em lote não é concluído no tempo esperado, ou uma queda gradual na taxa de transação ou rendimento em um certo período
  • Lentidão geral do sistema

Na maioria dos casos, os problemas de desempenho ocorrem devido à subutilização de recursos do sistema ou superutilização de recursos como CPU, E/S ou memória, o que frequentemente revela gargalos em um deles. Em um ambiente ajustado corretamente, os recursos do sistema são usados de maneira ótima, sem depender de um deles em excesso.

A primeira etapa para diagnosticar um problema de desempenho é identificar os gargalos dos recursos. O Windows fornece ferramentas para ajudar a identificar esses gargalos.

Gargalo de CPU

Se um ou mais CPUs do sistema mostrar frequentemente mais de 90% de utilização, isso geralmente significa que o sistema tem gargalos de CPU. O Gerenciador de Tarefas pode ajudar a descobrir se o sistema tem esse problema. Outras ferramentas, como perfmon.exe e Monitor de Recursos, mostram a utilização de CPU, o que também pode ajudar a identificar gargalos de CPU.

Gargalo de memória

Gargalos de memória não são muito comuns, principalmente porque heaps e parâmetros de bancos de dados são geralmente configurados com base na memória disponível. Mas, quando perfmon e o Monitor de Recursos indicam memória livre muito baixa, isso pode indicar gargalos. Às vezes, quando STMM é usado, a memória livre do sistema pode ser muito baixa, mas isso nem sempre significa que o sistema tem um gargalo.

Gargalo de rede

Utilização de rede muito alta, conforme indicado pelo Monitor de Recursos, pode indicar um gargalo de rede. O Monitor de Recursos mostra a utilização de rede em percentual usado, o que ajuda a identificar gargalos rapidamente. Quando o Monitor de Recursos mostra utilização de rede acima de 80%, geralmente há um gargalo.

Gargalo de E/S

Se um ou mais discos do sistema estão frequentemente ocupados mais de 90% do tempo, ou se a fila de disco tiver números altos constantemente, isso geralmente significa que o sistema tem gargalos de disco de E/S. Ferramentas do Windows como o Monitor de Recursos e perfmon podem ajudar a identificar esses gargalos. O Gerenciador de Tarefas mostra atividade de E/S, mas o Monitor de Recursos e perfmon mostram detalhes de E/S por disco. Eles também mostram a porcentagem de tempo ativo, o que ajuda a identificar se há um gargalo em um disco específico.

Há várias ferramentas do Windows para ajudar a determinar se o sistema tem um ou mais gargalos de recursos.


Etapa 1: Identificar gargalos usando ferramentas do Windows

Gerenciador de Tarefa

O Gerenciador de Tarefas é a maneira mais rápida de obter informações sobre o uso geral do sistema. Por exemplo, a Figura 2 é uma captura de tela da guia Processes do Gerenciador de Tarefas, com colunas contendo estatísticas de CPU, memória e E/S por processo (View > Select Columns). O Gerenciador de Tarefas dá um bom resumo da utilização de CPU, E/S, memória e rede. O Gerenciador de Tarefas também mostra detalhes dos processos, ajudando a descobrir quais deles estão consumindo mais CPU, quais estão fazendo mais E/S etc.

Se o Gerenciador de Tarefas mostrar constantemente que a utilização de CPU geral está acima de 90%. Isso é uma indicação de gargalo de CPU. O Gerenciador de Recursos também mostra atividade de CPUs individuais na guia Performance. Se a utilização de um dos CPUs estiver constantemente perto de 100%, isso também indica um gargalo de CPU. Isso geralmente significa que a carga de trabalho no banco de dados tem um único encadeamento e não pode aproveitar os CPUs disponíveis no sistema. A Figura 1 tem um exemplo da execução de um aplicativo com um único encadeamento. Embora apenas um CPU esteja ocupado e os outros não sejam utilizados, isso ainda é um gargalo.

O Gerenciador de Tarefas também mostra detalhes sobre o volume de dados lidos/gravados no disco por cada processo. Isso é útil, mas não mostra a porcentagem de utilização de discos individuais. Isso torna difícil determinar se o sistema está sofrendo um gargalo de E/S apenas a partir do Gerenciador de Tarefas.

Figura 1. Gerenciador de Tarefa— Exemplo de carga de trabalho com um único encadeamento
Gerenciador de Tarefa Exemplo de carga de trabalho com um único encadeamento
Figura 2. Gerenciador de Tarefas mostrando processos com máxima utilização de memória
Gerenciador de Tarefas mostrando processos com máxima utilização de memória

Monitor de Recursos

O Monitor de Recursos é outra ferramenta disponível no Windows 2008 e Windows 7. Ele fornece informações detalhadas sobre o uso de E/S, CPU, memória e rede. A ferramenta exibe informações em tempo real sobre todos os processos em execução no sistema e permite filtrar os dados com base nos requisitos do usuário. Isso pode ser feito com base em memória, CPU, disco e rede. A guia Overview mostra a atividade geral do sistema e contém uma captura instantânea dos gargalos do sistema. O uso de E/S e rede são mostrados em porcentagem de utilização em relação à largura da banda disponível. Isso ajuda a identificar se o sistema tem um gargalo de E/S ou de rede, o que é não possível descobrir através do Gerenciador de Tarefas. Além disso, o Monitor de Recursos mostra o tamanho da fila de cada disco, o que é útil ao determinar se o disco tem largura de banda suficiente para lidar com a demanda de E/S do sistema.

Figura 3. Monitor de Recursos
Monitor de Recursos
Figura 4. Atividade de disco do DB2 no Monitor de Recursos
Atividade de disco do DB2 no Monitor de Recursos

perfmon

Embora o Gerenciador de Tarefas e o Monitor de Recursos sejam boas ferramentas para conhecer a atividade do sistema, eles não podem ser usados para registrar atividades do sistema em um log para análise posterior. A ferramenta perfmon pode registrar a atividade do sistema em um arquivo de log. Isso proporciona flexibilidade a administradores e DBAs, que podem coletar dados do perfmon em vários momentos do dia e usá-los para análise posterior. A ferramenta perfmon, incluída com o Windows, é usada para capturar dados de desempenho e estatísticas sobre o uso de recursos. Entender como configurar e capturar um log de perfmon é essencial para muitos tipos de investigação de problemas. Observação para monitorar E/S: é necessário ativar os contadores de disco com o comando diskperf -y(-ye para conjuntos de faixas), seguido de uma reinicialização. Para executar perfmon e capturar as atividades em um arquivo log no Windows 2008 ou Windows 7:

  1. Execute perfmon em um prompt de comandos.
  2. Selecione Performance Monitor no quadro esquerdo.
  3. Clique com o botão direito e selecione New > Data Collector set. Crie um nome adequado e clique em Next.
  4. Informe o nome do diretório no qual os logs serão salvos.
  5. O conjunto Data Collector aparece no quadro esquerdo. Selecione Data Collector Set > User Defined no quadro esquerdo e selecione o nome escolhido na etapa 4. O status deve ser "stopped", pois queremos incluir o contador necessário antes que a coleta comece.
  6. Clique com o botão direito no conjunto Data collector definido e selecione New > Data Collector. Insira um nome e selecione Performance counter data collector e, em seguida, clique em Next. Selecione a frequência de amostra e inclua os contadores de desempenho. A ferramenta perfmon têm muitos contadores para monitorar vários parâmetros, mas os mais úteis são listados abaixo. Esse é um ponto de partida para coletar dados. Com base nos requisitos e na situação, os usuários podem coletar e monitorar contadores adicionais.
    Nome do recursoContadores de monitoramentoComentários
    ProcessadorIdle Time, Processor time, User timeRelatado em porcentagem em relação ao tempo total
    MemóriaAvailable Mbytes, Page Fault/sec, Pages/sec

    Available Mbytes — A memória livre disponível no sistema.

    Pages/sec é a taxa na qual as páginas são lidas ou gravadas em disco para resolver falhas de página sólidas. Esse contador é um indicador primário dos tipos de falhas que causam atrasos em todo o sistema.

    Page Fault/sec é o número médio de páginas com falha por segundo. O uso de Pages/sec e de Page Fault/sec indica a atividade de paginação do sistema.

    Disco lógico %Disk Time, Avg. Disk Bytes/Read, Avg. Disk Bytes/Write, Avg. Disk queue length, Avg. Disk sec/Read, Avg. Disk sec/Write Esses contadores indicam o nível de atividade dos discos e mostram o tempo médio de resposta de leitura/gravação.
    Interface de rede Bytes Received/sec, Bytes Sent/sec, Current bandwidth

    Current bandwidth é uma estimativa da largura de banda atual da interface de rede, em bits por segundo (BPS).

    Junto com os bytes recebidos e enviados, é fácil descobrir o nível de atividade da interface de rede em um dado momento.

  7. Após selecionar os contadores de desempenho, como mostra a figura abaixo, podemos coletar os dados para o intervalo de tempo necessário. Isso pode ser alterado usando a seção de propriedades do conjunto de coletores de dados escolhido. Os dados coletados pelos contadores escolhidos podem ser salvos em uma tabela ou planilha. O formato da saída pode ser especificado na seção de propriedades na guia File.
    Figura 5. Contadores de desempenho do perfmon
    Contadores de desempenho do perfmon
  8. Quando estiver pronto para a coleta de dados, inicie a carga de trabalho ou consulte e inicie imediatamente a coleta de dados clicando em Start no conjunto de coletores de dados escolhido.
  9. Após a conclusão da consulta ou carga de trabalho, pare a coleta de dados de monitoramento e analise os dados coletados.

Escolhendo a ferramenta de diagnóstico adequada

O perfmon é uma boa ferramenta para o monitoramento normal. Seus logs podem ser armazenados, o que torna mais fácil comparar a atividade quando o sistema estiver comportando-se como o esperado e quando o sistema tiver problemas de desempenho. Isso pode muitas vezes dar pistas valiosas sobre o problema em questão. No entanto, em alguns casos, uma rápida olhada nos dados do Gerenciador de Tarefas ou Monitor de Recursos pode ajudar a determinar o gargalo no sistema em tempo real. Quando o gargalo tiver sido identificado, é possível tomar medidas para removê-lo.


Etapa 2: Gargalos de E/S — Exame detalhado

Quando perfmon mostra o tempo de disco de um ou mais discos acima de 80%, ou quando o Monitor de Recursos mostra o tempo de atividade de um ou mais discos acima de 80%, são geralmente indicações de que o sistema tem um gargalo de E/S. No perfmon ou no Monitor de Recursos, descubra qual(is) disco(s) apresenta(m) utilização alta. Após identificar quais discos têm uso pesado, descubra o que está sendo colocado neles.

Contêineres de table space do DB2 estão sendo colocados nos discos?

db2 list tablespace containers for <tbsid>

Repita o comando para todos os espaços de tabela no banco de dados.

Ou arquivos de log do DB2 estão sendo colocados nos discos com uso pesado?

db2 get db cfg for <dbname>

Procure o parâmetro de configuração do banco de dados newlogpath.

Ou esses discos contêm arquivos de utilitários, como destino de backup ou arquivos de carregamento? Veja os comandos de backup/carregamento executados. A solução varia dependendo do que os discos com uso pesado contêm.

Gargalo de disco em contêineres de table space

Se os discos com uso pesado estiverem designados para contêineres de table space, descubra quais são os objetos no table space. Se o table space corresponder a um table space de dados, descubra quais foram as tabelas criadas nesse table space.

db2 select tabname from syscat.tables where tbspaceid = <hot tablespace id>

A partir da função de tabela MON_GET_TABLE, descubra qual é a tabela mais ativa. A consulta a seguir mostra as tabelas com o maior número de linhas lidas.

Lista 1. Tabelas mais ativas em um table space
db2 "select varchar(tabschema,20) as tabschema, varchar(tabname,20) as tabname,
     table_scans, sum(rows_read) as total_rows_read, 
     sum(rows_inserted) as total_rows_inserted, 
     sum(rows_updated) as total_rows_updated, 
     sum(rows_deleted) as total_rows_deleted 
FROM TABLE(MON_GET_TABLE('','',-2)) AS t 
WHERE TBSP_ID = hot tablespace id
GROUP BY tabschema, tabname 
ORDER BY total_rows_read DESC"

OBSERVAÇÃO: A função MON_GET_TABLE fornece várias informações úteis. Ela controla o número de varreduras na tabela. Se o número de varreduras for alto, isso pode significar que a tabela não têm índices apropriados, ou que as consultas não estão usando os índices existentes na tabela.

Após identificar as tabelas muito ativas, é fácil descobrir as instruções SQL executadas na tabela usando a função de tabela MON_GET_PKG_CACHE_STMT.

Lista 2. Descobrindo as consultas em uma dada tabela
db2 "select section_type, executable_id, package_name,num_executions,
char(stmt_text, 100) 
from table (MON_GET_PKG_CACHE_STMT ( 'D', NULL, NULL, -2)) as T
where stmt_text like '%hot table name%' "

Dessa maneira, é fácil descobrir as instruções SQL que causam grande número de leituras/gravações em tabelas muito ativas. Use o Design Advisor para descobrir se as instruções SQL estão usando índices apropriados na tabela. Se a tabela têm índices apropriados mas eles não são usados, verifique se as estatísticas na tabela estão atualizadas. Estatísticas incorretas ou desatualizadas podem fazer com que o otimizador escolha um plano de acesso que não é o ideal.

Gargalo de disco em um table space temporário

Se os discos de uso pesado estão designados para um table space temporário, isso é uma indicação de muita atividade de classificação no banco de dados. Altos níveis de atividade de E/S em um table space temporário tende a estar associado a consultas grandes, conjuntos de resultados grandes ou muita classificação. Nesse caso, determine se há muitas classificações vazando para o disco. MON_GET_PKG_CACHE_STMT pode informar quais instruções SQL estão causando estouro de classificação.

Lista 3. Consultas com alta atividade de classificação
db2 "select section_type, package_name,num_executions, total_sorts, sort_overflows,
char(stmt_text, 100) 
from table (MON_GET_PKG_CACHE_STMT ( 'D', NULL, NULL, -2)) as T
where sort_overflows > 1 
order by sort_overflows desc"

Se houver muitos estouros de classificação, verifique se os parâmetros de configuração SORTHEAP ou SHEAPTHRES estão em valores muito baixos. Se a configuração dos parâmetros relacionados à classificação estiver correta, determine se é possível evitar grandes classificações pela criação de índices. Use Design Advisor para consultas com muita classificação e veja se a classificação pode ser evitada ou reduzida pela criação de índices adicionais.

Gargalo de disco em logs de transações

O desempenho de logs de transação é muito sensível em um ambiente OLTP. A função de tabela MON_GET_TRANSACTION_LOG mostra a atividade detalhada nos logs de transações.

Lista 4. Atividade dos logs de transações
db2 "select log_reads, log_read_time, log_write, log_write_time, num_log_buffer_full,
num_log_data_found_in_buffer 
from table(MON_GET_TRANSACTION_LOG(-1)) as T "

num_log_buffer_full mostra o número de vezes que o buffer do log esteve cheio e teve que ser transferido para o disco para novos logs serem gravados no buffer. Se esse número estiver aumentando com o tempo, o buffer de log é pequeno para a carga de trabalho do banco de dados. O aumento do valor do parâmetro de banco de dados LOGBUFSZ ajuda a melhorar o desempenho de log e reduzir a E/S nos discos de log de transações.

num_log_data_found_in_buffer mostra o número de vezes que um agente lê dados de log do buffer. É melhor ler dados de log do buffer do que ler do disco, pois esse último é mais lento. Use esse elemento em conjunto com num_log_read_io element para determinar se o parâmetro de configuração do banco de dados LOGBUFSZ precisa ser aumentado ainda mais.


Etapa 3: Gargalos de CPU — exame detalhado

Se perfmon ou o Monitor de Recursos mostrar que o uso de um ou mais CPUs está acima de 90%, isso geralmente indica que o sistema tem gargalos de CPU. Assim como nos gargalos de E/S, a primeira etapa é identificar as operações do banco de dados que consomem muito CPU. Há algumas operações de banco de dados que sabidamente consomem muito CPU:

  • Compilação de instruções
  • Utilitários como LOAD, BACKUP, runstats etc.
  • Alta atividade de classificação

Para descobrir se muito CPU está sendo gasto em compilação de consultas, consulte a função de tabela MON_GET_WORKLOAD.

Lista 5. Tempo de CPU gasto em atividades diferentes
db2 "select varchar(workload_name,30) as workload_name,
sum(total_cpu_time),sum(total_compile_proc_time),
sum(act_rqsts_total), sum(total_compilations),
sum(total_act_time), sum(pkg_cache_inserts), 
sum(pkg_cache_lookups) 
from TABLE(MON_GET_WORKLOAD('',-2)) as T
group by workload_name"

Se compile_proc_time for maior que 5-10% de total_cpu_time e pkg_cache_inserts/pkg_cache_lookups for maior que 4-5%, o banco de dados está gastando tempo demais em compilação de instruções. Isso pode acontecer por causa das consultas estarem sendo compiladas repetidamente, ou talvez o cache de pacotes seja pequeno demais e as consultas tenham que ser despejadas para abrir espaço para outras. Se o aplicativo usa sequências literais em vez de marcadores de parâmetros, as instruções SQL são compiladas repetidamente. No DB2 9.7 e 10.1, o DB2 fornece o parâmetro de configuração de banco de dados STMT_CONC (concentrador de instruções). Quando ativado, o concentrador de instruções modifica as instruções dinâmicas para permitir maior compartilhamento de entradas do cache de pacotes, reduzindo a compilação de instruções.

Para descobrir se algum utilitário está causando alto uso de CPU, consulte a função de tabela MON_GET_WORKLOAD. As métricas retornadas representam o acúmulo de todas as métricas para solicitações enviadas por conexões mapeadas para o objeto de carga de trabalho identificado. As métricas são roladas em uma carga de trabalho em limites da unidade de trabalho e periodicamente durante a execução de solicitações. Os valores informados por essa função de tabela refletem o estado atual do sistema no momento da rolagem mais recente. As métricas estão estritamente aumentando de valor. Para determinar o tempo gasto em utilitários como LOAD e reorg em um intervalo de tempo, use MON_GET_WORKLOAD para consultar a métrica no início e fim do intervalo e calcular a diferença.

Lista 6. Tempo de CPU gasto em utilitários LOAD e runstat
db2 "select varchar(workload_name,30) as workload_name,
sum(total_loads), sum(total_load_proc_time),
sum(total_runstats), sum(total_runstats_proc_time)
from TABLE(MON_GET_WORKLOAD('',-2)) as T 
group by workload_name"

Utilitários como LOAD são projetados para aproveitar os recursos disponíveis para maximizar o desempenho. Se eles estiverem tomando mais CPU do que o estimado, é possível configurar o parâmetro de configuração de banco de dados util_impact_limit para regular esses programas. Outra operação de banco de dados que consome muito CPU é sort. Como dito na seção de gargalo de E/S, descubra quais são as consultas que realizam a maioria das atividades de classificação e use o Design Advisor para descobrir se as classificações podem ser evitadas pela criação de índices adicionais.


Etapa 4: Gargalos de memória

Gargalos de memória não são muito comuns, principalmente porque heaps e parâmetros de bancos de dados podem ser configurados com base na memória disponível. A maioria dos heaps do DB2 é automática, com valores determinados com base na memória disponível. STMM faz um bom trabalho utilizando a memória disponível e alocando memória para heaps que mais precisam. Mas, ao não usar STMM, pode haver alguns casos em que, se a memória estiver excessivamente comprometida (ou seja, foi alocado mais do que o disponível), isso pode resultar em alta atividade de paginação. Se perfmon ou o Monitor de Recursos mostrarem muita atividade de paginação, é geralmente porque a memória de diferentes heaps foi alocada sobre a memória atual. Em tais casos, é melhor ativar o STMM e deixar que o DB2 ajuste a memória para conjuntos de buffer, heaps de classificação e outros heaps.


Etapa 5: Gargalo de rede

Os gargalos de rede surgem geralmente quando são deslocados grandes volumes de dados (como conjuntos de resultados muito grandes, carga de cliente etc.), ou quando aplicativos manipulam LOBs em arquitetura cliente/servidor. A visão administrativa MON_DB_SUMMARY dá uma boa indicação do tempo gasto esperando por diferentes recursos. O campo NETWORK_WAIT_TIME_PERCENT mostra o tempo, em porcentagem, gasto esperando por uma resposta de rede. Geralmente o tempo gasto esperando pela rede deve ser menor que 1%. Se for mais de alguns pontos percentuais e perfmon e o Monitor de Recursos mostrarem uso pesado da largura de banda da rede, o sistema pode estar com gargalos. Nesses casos, o aplicativo pode mover parte de sua lógica para o servidor, na forma de procedimento armazenado ou UDFs. No caso de LOAD de cliente, a quebra do LOAD em partes menores e sua execução em momentos separados (em vez de carregar de uma vez) reduz o tráfego de rede.


Etapa 6: Problemas de bloqueio

Se o sistema ainda não tem gargalos de recursos e o desempenho ainda está ruim, pode ser devido a problemas de bloqueio. O campo LOCK_WAIT_TIME_ PERCENT na visualização administrativa MON_DB_SUMMARY oferece uma visão geral de alto nível do tempo gasto em esperas de bloqueio no nível do banco de dados. Para ter visualizações detalhadas das cargas de trabalho que gastaram tempo em esperas de bloqueio, consulte a função de tabela de monitoramento MON_GET_WORKLOAD.

Lista 7. Tempo gasto em esperas de bloqueio
db2 "SELECT varchar(workload_name,30) as workload_name,
sum(lock_wait_time) as total_lock_wait_time,
sum(lock_waits) as total_lock_waits,
sum(lock_timeouts) as total_lock_timeouts, 
sum(lock_escals) as total_lock_escals 
FROM TABLE(MON_GET_WORKLOAD('',-2)) AS t
GROUP BY workload_name 
ORDER BY total_lock_wait_time DESC"

Etapa 7: Ajustando a atividade de limpeza de página

Além de examinar os gargalos de recursos do sistema e os problemas de bloqueio, há algumas outras coisas importantes a se observar em um ambiente de banco de dados. A limpeza de página e a pré-busca são duas atividades importantes que devem ser ajustadas adequadamente para o desempenho ideal. Em alguns casos, quando a limpeza de página não está ajustada adequadamente, isso pode causar gargalo de E/S. A tabela de monitoramento MON_GET_BUFFERPOOL fornece métricas para descobrir a limpeza de página e atividade de pré-busca.

Lista 8. Atividade de limpeza de página
db2 "WITH BPMETRICS AS (
SELECT bp_name,
pool_data_writes, pool_async_data_writes, 
pool_index_writes, pool_async_index_writes,
pool_no_victim_buffer, pool_lsn_gap_clns,
pool_drty_pg_steal_clns, pool_drty_pg_thrsh_clns
FROM TABLE(MON_GET_BUFFERPOOL('',-2)) AS METRICS)
SELECT
   VARCHAR(bp_name,20) AS bp_name,
   pool_data_writes, pool_async_data_writes,
  CASE WHEN pool_data_writes > 0
  THEN DEC((FLOAT(pool_async_data_writes) / FLOAT(pool_data_writes)) * 100,5,2)
    ELSE NULL
    END AS PAGE_CLN_RATIO,
     pool_index_writes, pool_async_index_writes,
  CASE WHEN pool_index_writes > 0
  THEN DEC((FLOAT(pool_async_index_writes) / FLOAT(pool_index_writes)) * 100,5,2)
    ELSE NULL
    END AS IND_CLN_RATIO,
      pool_no_victim_buffer, pool_lsn_gap_clns,
      pool_drty_pg_steal_clns, pool_drty_pg_thrsh_clns
    FROM BPMETRICS"

A taxa de limpeza de página de Data e Index na consulta acima deve ser próxima de 100%. Se os valores forem menores que 90%, a limpeza de página não consegue acompanhar o crescimento de páginas sujas no sistema.

dirty_page_steal_clns mostra as deturpações de página suja. O ideal é que isso seja zero. Se for mais que uma fração do número de leituras lógicas, é preciso limpar mais. Diminua CHG_PGS_THRESHOLD e certifique-se de que há limpadores de E/S suficientes disponíveis.

pool_no_victim_buffer mostra o número de vezes que um agente não conseguiu encontrar uma página livre na lista de páginas livres. Se esse número for maior que apenas alguns pontos percentuais do número de leituras lógicas, é mau sinal. Diminua CHG_PGS_THRESHOLD e certifique-se de que há limpadores de E/S suficientes disponíveis.


Etapa 8: Ajustando a atividade de pré-busca

Assim como a limpeza de página, é necessário ajustar também a atividade de pré-busca. Em um ambiente OLTP real, a pré-busca pode não ser útil. Mas em um tipo de carga de trabalho DSS, a pré-busca tem um papel importante. O ideal é que os IO_SERVERS (pré-buscadores) façam toda a leitura, que tem natureza assíncrona. A consulta a seguir mostra a porcentagem das leituras de E/S feitas por IO_SERVERS.

Lista 9. Atividade de pré-busca
db2 "WITH BPMETRICS AS (
    SELECT bp_name,
      pool_data_p_reads, pool_async_data_reads,
      pool_temp_data_p_reads,
      pool_index_p_reads, pool_async_index_reads
    FROM TABLE(MON_GET_BUFFERPOOL('',-2)) AS METRICS)
    SELECT
      VARCHAR(bp_name,20) AS bp_name,
      pool_data_p_reads, pool_async_data_reads,
    CASE WHEN pool_data_p_reads > 0
    THEN DEC((FLOAT(pool_async_data_reads) / FLOAT(pool_data_p_reads + 
                POOL_TEMP_DATA_P_READS)) * 100,5,2)
    ELSE NULL
    END AS PREFETCH_RATIO,
      pool_index_p_reads, pool_async_index_reads,
    CASE WHEN pool_index_p_reads > 0
    THEN DEC((FLOAT(pool_async_index_reads) / FLOAT(pool_index_p_reads)) * 100,5,2)
    ELSE NULL
    END AS PREFETCH_IDX_RATIO
FROM BPMETRICS"

Um valor acima de 90% é bom para PREFETCH_RATIO.


Resumo

As etapas acima não abordam todos os possíveis problemas de desempenho que podem ocorrer, mas sim concentram-se em usar princípios e estratégias de solução de problemas de desempenho. Seguir essas etapas irá definitivamente ajudá-lo a entender melhor o problema e, por fim, resolvê-lo.

Recursos

Aprender

Obter produtos e tecnologias

  • Crie seu próximo projeto de desenvolvimento com o software de teste IBM, disponível para download diretamente no developerWorks.
  • Agora é possível usar o DB2 gratuitamente. Faça o download do O DB2 Express-C, uma versão gratuita do DB2 Express Edition para a comunidade que oferece os mesmos recursos de dados centrais que o DB2 Express Edition e fornece uma base sólida para desenvolver e implementar aplicativos.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management
ArticleID=839060
ArticleTitle=Ajuste o banco de dados DB2 no Windows em oito etapas simples
publish-date=10082012