Minerando o Cache de Pacotes para Encontrar SQL com Problemas no DB2 para Linux, UNIX e Windows

Em ambientes de bancos de dados OLTP e DSS, DBAs podem usar informações armazenadas no cache de pacotes para encontrar instruções SQL problemáticas antes ou depois de elas afetarem o desempenho. Embora haja muitas ferramentas de terceiros para identificar e analisar SQL problemática, os DBAs podem executar algumas consultas simples para localizar esse código sem precisar usá-las. Este artigo mostra como minerar dados do cache de pacotes usando algumas dessas consultas.

Ember Crooks, Application Engineering Architect, Rosetta

Ember                 Crooks photoEmber Crooks escreve um blog sobre o DB2, que pode ser acessado em http://db2commerce.com. Ela trabalha na Rosetta, uma agência interativa, com foco em consultoria, criada para transformar o marketing para o mundo conectado. Ember é DBA do DB2 há 11 anos e detém algumas certificações do DB2, como: IBM Certified Database Administrator para DB2 10.1 para Linux, UNIX e Windows e IBM Certified Advanced Database Administrator para DB2 9.7 para Linux, UNIX e Windows. Foi finalista da competição DB2Night Show's DB2' Got Talent 2012 e foi palestrante convidada na DB2Night Show.



14/Dez/2012

O que é o cache de pacotes?

DB2® para Linux®, UNIX® e Windows® usa muitas áreas de memória diferentes para armazenar informações críticas em cache. Essas áreas são ferramentas muito eficientes para controlar o desempenho do banco de dados. O cache de pacotes é uma delas. É aqui que o DB2 armazena consultas estáticas e dinâmicas, planos de acesso e informações sobre a execução dessas consultas. O ajuste do cache de pacotes é uma parte importante do ajuste de desempenho do DB2. No entanto, se tudo que você faz com o cache de pacotes é garantir que as taxas de acertos deles estão boas, você não está aproveitando o verdadeiro potencial dessa importante área de memória.

Que informações contém o cache de pacotes?

Assim como em uma mina de ouro, o cache de pacotes pode parecer um buraco negro, com uma montanha de informações por trás, entre as quais estão as pepitas de ouro que lhe trarão riqueza (em termos de desempenho de banco de dados). Isso porque há diversas informações interessantes disponíveis nessa área. Algumas das informações mais interessantes:

  • Instruções de consulta — texto completo das consultas dinâmicas executadas em relação ao banco de dados, com marcadores de parâmetro caso tenham sido usados
  • Número de execuções — o número de vezes em que uma consulta em particular foi executada
  • Tempo de execução — o tempo total gasto em todas as execuções de uma consulta em particular
  • Tempo de espera de bloqueio — o tempo total que uma consulta em particular passou esperando por bloqueios
  • Tempo de classificação — o tempo total que uma consulta em particular passou organizando e ordenando dados
  • Linhas lidas — o número total de linhas que uma consulta em particular examinou
  • Linhas retornadas — o número total de linhas que uma consulta retornou nos conjuntos de resultados
  • Tempo de CPU — o tempo de CPU total consumido por uma consulta em particular
  • Tempo de execução — o tempo total que uma consulta em particular passou executando

Todas as informações no cache de pacotes são cumulativas desde a última vez em que uma consulta em particular foi colocada nele.

Que informações NÃO estão disponíveis no cache de pacotes?

Embora o cache de pacotes contenha muitas informações úteis, ele não substitui um monitor de eventos de instruções SQL. O cache de pacotes não pode informar isto:

  • Quando uma consulta em particular foi executada
  • Alguns detalhes sobre SQL estática (especialmente ao usar GET SNAPSHOT, ou se não estiver no DB2 9.7 ou posterior)
  • Valores específicos usados na execução de uma instrução quando ela usa marcadores de parâmetro
  • Valores literais usados durante a execução (se STMT_CONC for usado)

Por quanto tempo as informações ficam no cache de pacotes?

O DB2 move instruções individuais para dentro e para fora do cache de pacotes para manter as instruções com execução mais frequente na memória. Por isso, uma instrução pode ficar por um tempo no cache de pacotes até ser sobrescrita.

É possível usar a instrução a seguir para limpar o conteúdo do cache de pacotes a qualquer momento:

  FLUSH PACKAGE CACHE DYNAMIC

É importante observar que a execução dessa instrução pode afetar o desempenho de um sistema em execução, pois fará com que os planos de acesso de toda a SQL dinâmica sejam regenerados.

A desativação de um banco de dados também faz com que o cache de pacotes seja esvaziado. Isso inclui a desativação explícita e automática do banco de dados, operações de parada/início de instância do DB2 e reinicializações do servidor. No entanto, a reconfiguração de comutadores de monitor não limpa o cache de pacotes nem zera os contadores de instruções no cache.

Não se pode confiar que as estatísticas do cache de pacotes incluam tudo desde a última reinicialização ou limpeza específica, especialmente com caches de pacotes pequenos.

Encontrando SQL problemática no cache de pacotes

O que é SQL problemática?

Minha experiência mostra que SQL problemática é uma importante causa de problemas de desempenho do banco de dados. Já vi problemas de indisponibilidade causados por isso, especialmente durante períodos de pico. Usarei aqui uma definição ampla de "SQL Problemática" — neste caso, é qualquer SQL que cause lentidão ou degradação no desempenho. Com essa definição ampla, podemos colocar a SQL em algumas categorias. As principais categorias são:

  • Linhas lidas — Um número alto de linhas lidas (especialmente se o número de linhas selecionadas for pequeno) pode indicar que estão ocorrendo varreduras de tabela.
  • Tempo de execução — Basicamente, as consultas que demoram mais para executar têm maior probabilidade de ser um problema do que aquelas com tempos de execução menores, somando todas as execuções.
  • Tempo de CPU — A redução dos ciclos de CPU necessários para processar uma consulta pode ser uma importante melhoria, especialmente quando o sistema é limitado pela CPU.
  • Tempo de Classificação — O tempo de classificação pode aumentar o tempo de execução de consultas, especialmente em bancos de dados OLTP.

Em cada uma dessas situações, o número de vezes que uma instrução SQL é executada deve ser levada em consideração. É possível passar uma hora reduzindo uma consulta de 30 segundos para 20 segundos, mas, se ela for executada apenas uma vez por hora, é melhor ocupar o tempo reduzindo em 100 milissegundos uma consulta executada 200 vezes por minuto.

Prefiro dar mais atenção às categorias para as quais posso fazer algo. Eu geralmente trabalho com um aplicativo fornecido, no qual não posso alterar o SQL que é executado em relação aos meus bancos de dados. Mas eu posso incluir ou remover índices, o que me deixa predisposta a olhar para colunas lidas e eficiência de leitura.

Acessando informações no cache de pacotes

Há alguns métodos que podem ser usados para acessar as informações encontradas no cache de pacotes. Esses métodos são resumidos na Tabela 1.

Tablela 1. Métodos usados para acessar as informações armazenadas no cache de pacotes
MétodoTipoInformações básicasInformações estendidasSQL estáticoVersãoAtivado pela coleção
GET SNAPSHOT FOR DYNAMIC SQLArquivo SimplesSimNãoNãoTodasDFT_MON_STMT, comutador de monitor STATEMENT
SNAPSHOT_DYN_SQLSQL/Função de TabelaSimNãoNão8.2 e posterioresDFT_MON_STMT
SQLCACHE_SNAPSHOTSQL/Função de TabelaSimNãoNão8.2 e posterioresDFT_MON_STMT
SNAP_GET_DYN_SQLSQL/Função de TabelaSimNãoNão8.2 e posterioresDFT_MON_STMT
SNAP_GET_DYN_SQL_V91SQL/Função de TabelaSimNãoNão9.1 e posterioresDFT_MON_STMT
SNAP_GET_DYN_SQL_V95SQL/Função de TabelaSimNãoNão9.5 e posterioresDFT_MON_STMT
SNAPDYN_SQLSQL/Visualização AdministrativeSimNãoNão9.5 e posterioresDFT_MON_STMT
LONG_RUNNING_SQLSQL/Visualização AdministrativeParcialNãoNão9.7 e posterioresDFT_MON_STMT
QUERY_PREP_COSTSQL/Visualização AdministrativeParcialNãoNão9.7 e posterioresDFT_MON_STMT
TOP_DYNAMIC_SQLSQL/Visualização AdministrativeParcialNãoNão9.7 e posterioresDFT_MON_STMT
MON_PKG_CACHE_SUMMARYSQL/Visualização AdministrativeSimNãoSim9.7, Fix Pack 1 e posterioresMON_ACT_METRICS, COLLECT ACTIVITY METRICS na carga de trabalho
MON_GET_PKG_CACHE_STMTSQL/Função de TabelaSimSimSim9.7MON_ACT_METRICS, COLLECT ACTIVITY METRICS na carga de trabalho
MON_GET_PKG_CACHE_STMT_DETAILSSQL/Função de Tabela/XMLSimSimSim9.7, Fix Pack 1 e posterioresMON_ACT_METRICS, COLLECT ACTIVITY METRICS na carga de trabalho
Nota: DFT_MON_STMT é um parâmetro de configuração do gerenciador de banco de dados, enquanto MON_ACTMETRICS é um parâmetro de configuração do banco de dados.

A maneira tradicional de acessar informações armazenadas no cache de pacotes é usar um comando GET SNAPSHOT como este:

 GET SNAPSHOT FOR DYNAMIC SQL ON [DBAlias]

No qual: DBAlias é o alias do banco de dados cujas informações de cache de pacotes devem ser coletadas.

Quando esse comando é executado, a saída produzida é semelhante a isto:

Lista 1. Saída de captura instantânea
      Dynamic SQL Snapshot Result

 Database name                      = SAMPLE

 Database path                      = /db_data/db2inst1/NODE0000/SQL00002/

 Number of executions               = 80
 Number of compilations             = 1
 Worst preparation time (ms)        = 12
 Best preparation time (ms)         = 12
 Internal rows deleted              = 0
 Internal rows inserted             = 0
 Rows read                          = 80
 Internal rows updated              = 0
 Rows written                       = 0
 Statement sorts                    = 0
 Statement sort overflows           = 0
 Total sort time                    = 0
 Buffer pool data logical reads     = 80
 Buffer pool data physical reads    = 0
 Buffer pool temporary data logical reads   = 0
 Buffer pool temporary data physical reads  = 0
 Buffer pool index logical reads    = 240
 Buffer pool index physical reads   = 0
 Buffer pool temporary index logical reads  = 0
 Buffer pool temporary index physical reads = 0
 Buffer pool xda logical reads      = 0
 Buffer pool xda physical reads     = 0
 Buffer pool temporary xda logical reads    = 0
 Buffer pool temporary xda physical reads   = 0
 Total execution time (sec.microsec)= 0.019997
 Total user cpu time (sec.microsec) = 0.010496
 Total system cpu time (sec.microsec)= 0.000000
 Total statistic fabrication time (milliseconds) = 0
 Total synchronous runstats time  (milliseconds) = 0
 Statement text                     = SELECT T1.PARTNUMBER, T1.FIELD5, T1.URL, 
T1.CATENTRY_ID, T1.BASEITEM_ID, T1.FIELD4, T1.OID, T1.ONAUCTION, T1.MFNAME, 
T1.ONSPECIAL, T1.BUYABLE, T1.FIELD2, T1.MFPARTNUMBER, T1.MEMBER_ID, T1.FIELD1, T1.STATE, 
T1.FIELD3, T1.ITEMSPC_ID, T1.LASTUPDATE, T1.MARKFORDELETE, T1.STARTDATE, T1.ENDDATE, 
T1.AVAILABILITYDATE, T1.LASTORDERDATE, T1.ENDOFSERVICEDATE, T1.DISCONTINUEDATE, 
T1.OPTCOUNTER, T1.CATENTTYPE_ID FROM CATENTRY  T1 WHERE T1.CATENTTYPE_ID = 'ItemBean'
 AND T1.CATENTRY_ID = ?
...

As informações mais importantes necessárias estão aqui, bem fáceis de ler. O problema é que aqui são apresentadas apenas informações para uma única consulta. É provável que você obtenha informações de milhares de consultas em uma única captura instantânea de SQL dinâmica feita em um sistema de produção. Um arquivo simples é muito mais difícil de analisar para descobrir informações sobre as instruções de SQL problemática. Além disso, por existir desde o começo do DB2, esse comando retorna apenas informações que estavam disponíveis em versões anteriores — Informações sobre bloqueios, número de linhas selecionadas e vários outros dados não estão disponíveis com esse comando.

Meu método preferido de acessar informações sobre cache de pacotes é consultar a função de tabela MON_GET_PKG_CACHE_STMT. Escolho esse método pode ser mais leve e ter menor impacto no banco de dados sendo monitorado, em relação aos outros métodos disponíveis. Ele também retorna informações em formato que pode ser acessado por SQL. É possível até usar a função MON_GET_PKG_CACHE_STMT para obter informações sobre instruções de SQL estática, caso você queira. Mas lembre-se que essa função está disponível apenas no DB2 9.7 e posterior.

Usando a função MON_GET_PKG_CACHE_STMT, eu construi algumas consultas mestre que uso com frequência para examinar as métricas de desempenho mais importantes e para classificá-las em relação a todas as outras consultas dinâmicas que estão atualmente no cache de pacotes. Essas consultas são as seguintes:

Lista 2. Consulta mestre nº 1 usando MON_GET_PKG_CACHE_STMT
WITH SUM_TAB (SUM_RR, SUM_CPU, SUM_EXEC, SUM_SORT, SUM_NUM_EXEC) AS (
        SELECT  FLOAT(SUM(ROWS_READ)),
                FLOAT(SUM(TOTAL_CPU_TIME)),
                FLOAT(SUM(STMT_EXEC_TIME)),
                FLOAT(SUM(TOTAL_SECTION_SORT_TIME)),
                FLOAT(SUM(NUM_EXECUTIONS))
            FROM TABLE(MON_GET_PKG_CACHE_STMT ( 'D', NULL, NULL, -2)) AS T
        )
SELECT
        SUBSTR(STMT_TEXT,1,10) as STATEMENT,
        ROWS_READ,
        DECIMAL(100*(FLOAT(ROWS_READ)/SUM_TAB.SUM_RR),5,2) AS PCT_TOT_RR,
        TOTAL_CPU_TIME,
        DECIMAL(100*(FLOAT(TOTAL_CPU_TIME)/SUM_TAB.SUM_CPU),5,2) AS PCT_TOT_CPU,
        STMT_EXEC_TIME,
        DECIMAL(100*(FLOAT(STMT_EXEC_TIME)/SUM_TAB.SUM_EXEC),5,2) AS PCT_TOT_EXEC
    FROM TABLE(MON_GET_PKG_CACHE_STMT ( 'D', NULL, NULL, -2)) AS T, SUM_TAB
    ORDER BY ROWS_READ DESC FETCH FIRST 5 ROWS ONLY WITH UR;
Lista 3. Consulta mestre nº 2 usando MON_GET_PKG_CACHE_STMT
WITH SUM_TAB (SUM_RR, SUM_CPU, SUM_EXEC, SUM_SORT, SUM_NUM_EXEC) AS (
        SELECT  FLOAT(SUM(ROWS_READ)),
                FLOAT(SUM(TOTAL_CPU_TIME)),
                FLOAT(SUM(STMT_EXEC_TIME)),
                FLOAT(SUM(TOTAL_SECTION_SORT_TIME)),
                FLOAT(SUM(NUM_EXECUTIONS))
            FROM TABLE(MON_GET_PKG_CACHE_STMT ( 'D', NULL, NULL, -2)) AS T)
SELECT
        SUBSTR(stmt_text,1,10) as STATEMENT,
        TOTAL_SECTION_SORT_TIME,
        DECIMAL(100*(FLOAT(TOTAL_SECTION_SORT_TIME)/SUM_TAB.SUM_SORT),5,2) AS PCT_TOT_SRT,
        NUM_EXECUTIONS,
        DECIMAL(100*(FLOAT(NUM_EXECUTIONS)/SUM_TAB.SUM_NUM_EXEC),5,2) AS PCT_TOT_EXEC,
        DECIMAL(FLOAT(STMT_EXEC_TIME)/FLOAT(NUM_EXECUTIONS),5,2) AS AVG_EXEC_TIME
    FROM TABLE(MON_GET_PKG_CACHE_STMT ( 'D', NULL, NULL, -2)) AS T, SUM_TAB
    ORDER BY ROWS_READ DESC FETCH FIRST 5 ROWS ONLY WITH UR;

Quando a primeira dessas consultas é executada, a seguinte saída é produzida:

Lista 4. Saída da consulta mestre nº 1
STATEMENT  ROWS_READ  PCT_TOT_RR TOTAL_CPU_TIME  PCT_TOT_CPU STMT_EXEC_TIME  PCT_TOT_EXEC
---------- ---------- ---------- --------------- ----------- --------------- ------------
select * f      91195      90.94         1013901        8.87            6699        14.33
SELECT SCS       4064       4.05          456660        3.99             450         0.96
SELECT T1.        537       0.53           75457        0.66              81         0.17
SELECT T1.        530       0.52          241887        2.11             104         0.22
UPDATE SCH        504       0.50           42339        0.37              55         0.11

  5 record(s) selected.

Quando a segunda dessas consultas é executada, a seguinte saída é produzida:

Lista 5. Saída da consulta mestre nº 2
STATEMENT  TOTAL_SECTION_SORT_TIME PCT_TOT_SRT  NUM_EXECUTIONS  PCT_TOT_EXEC AVG_EXEC_TIME
---------- ----------------------- ------------ --------------- ------------ -------------
select * f                       0         0.00              13         0.22        515.30
SELECT SCS                      58        92.06             463         7.88          0.97
SELECT T1.                       0         0.00             537         9.14          0.15
SELECT T1.                       0         0.00             265         4.51          0.39
UPDATE SCH                       0         0.00             504         8.58          0.10

  5 record(s) selected.

Neste exemplo, podemos ver que é uma consulta executada apenas 13 vezes, mas que toma 90% das linhas lidas. Dependendo do número de vezes que essa consulta é executada, pode ser melhor criar um índice que possa melhorar o desempenho. Outra consulta é executada 463 vezes e usa cerca de 4% das linhas lidas — ela também é uma boa candidata para mais investigações.

Uma das coisas que gosto em relação a essas duas consultas mestre é que posso alterar a cláusula ORDER BY para procurar consultas problemáticas em várias categorias. No exemplo anterior, eu uso linhas lidas, mas também posso ver que a segunda consulta usa 3,99% dos ciclos totais de CPU sendo consumidos pelas consultas e 92% do tempo de classificação. Se eu estivesse procurando especificamente consultas que consomem tempo de CPU, ordenaria a classificação dos resultados por TOTAL_CPU_TIME. Se estivesse procurando por consultas que consomem tempo de classificação, ordenaria os resultados por TOTAL_SECTION_SORT_TIME.

Para facilitar a leitura, essas consultas retornam apenas os primeiros caracteres de cada instrução SQL, mas é possível remover a função SUBSTR() para obter a sintaxe completa.

Se a sua preocupação for apenas uma área de desempenho, é possível fazer uma consulta mais focada. Uma das minhas favoritas tem o foco em linhas lidas e na eficiência de leitura de índice, consulta por consulta. Essa consulta é a seguinte:

Lista 6. Consulta com foco em linhas lidas usando MON_GET_PKG_CACHE_STMT
WITH SUM_TAB (SUM_RR) AS (
        SELECT FLOAT(SUM(ROWS_READ))
        FROM TABLE(MON_GET_PKG_CACHE_STMT ( 'D', NULL, NULL, -2)) AS T)
SELECT
        SUBSTR(STMT_TEXT,1,20) AS STATEMENT,
        ROWS_READ,
        DECIMAL(100*(FLOAT(ROWS_READ)/SUM_TAB.SUM_RR),5,2) AS PCT_TOT_RR,
        ROWS_RETURNED,
        CASE
            WHEN ROWS_RETURNED > 0 THEN
                DECIMAL(FLOAT(ROWS_READ)/FLOAT(ROWS_RETURNED),10,2)
            ELSE -1
        END AS READ_EFFICIENCY,
        NUM_EXECUTIONS
    FROM TABLE(MON_GET_PKG_CACHE_STMT ( 'D', NULL, NULL, -2)) AS T, SUM_TAB
    ORDER BY ROWS_READ DESC FETCH FIRST 5 ROWS ONLY WITH UR;

E, quando executada, essa consulta produz uma saída semelhante a esta:

Lista 7. Resultados da consulta
STATEMENT            ROWS_READ  PCT_TOT_RR ROWS_RETURNED  READ_EFFICIENCY NUM_EXECUTIONS
-------------------- ---------- ---------- -------------- --------------- ---------------
select * from schsta     105240      91.20             15         7016.00              15
SELECT SCSINSTREFNUM       4510       3.90            295           15.28             514
SELECT T1.SCCHOST, T        597       0.51            597            1.00             597
SELECT T1.STATE, T1.        590       0.51            295            2.00             295
UPDATE SCHSTATUS  SE        560       0.48              0           -1.00             560

  5 record(s) selected.

Usando essa saída, podemos olhar a Eficiência de Leitura de cada consulta, o que nos diz se nosso banco de dados está bem indexado para essa consulta em particular. Isso, por sua vez, ajuda-nos a identificar consultas na qual a inclusão de um índice pode melhorar o desempenho. Para consultas OLTP, eu considero uma consulta com 10 de Eficiência de Leitura como sendo um problema em potencial. Lembre-se que o número de execuções deve ser levado em consideração — a ação vale o custo em termos do seu tempo e do tempo que o DB2 gasta para manter índices? Se a resposta for sim, então crie os índices apropriados.

Se tempo de CPU for motivo de preocupação, a consulta a seguir funciona bem:

Lista 8. Consulta com foco em ciclos de CPU usando MON_GET_PKG_CACHE_STMT
WITH SUM_TAB (SUM_CPU) AS (
        SELECT FLOAT(SUM(TOTAL_CPU_TIME))
        FROM TABLE(MON_GET_PKG_CACHE_STMT ( 'D', NULL, NULL, -2)) AS T)
SELECT
        SUBSTR(STMT_TEXT,1,20) AS STATEMENT,
        TOTAL_CPU_TIME,
        DECIMAL(100*(FLOAT(TOTAL_CPU_TIME)/SUM_TAB.SUM_CPU),5,2) AS PCT_TOT_CPU,
        DECIMAL(FLOAT(TOTAL_CPU_TIME)/FLOAT(NUM_EXECUTIONS),10,2) AS AVG_CPU_TIME_PER_EXE,
        NUM_EXECUTIONS
    FROM TABLE(MON_GET_PKG_CACHE_STMT ( 'D', NULL, NULL, -2)) AS T, SUM_TAB
    ORDER BY TOTAL_CPU_TIME DESC FETCH FIRST 5 ROWS ONLY WITH UR;

Quando essa consulta é executada, os resultados produzidos são semelhantes a isto:

Lista 9. Resultados da consulta
STATEMENT            TOTAL_CPU_TIME  PCT_TOT_CPU AVG_CPU_TIME_PER_EXE NUM_EXECUTIONS
-------------------- --------------- ----------- -------------------- ---------------
SELECT ORDERS.ORDERS        10073382       25.80            100733.82             100
(((SELECT T2.STATE,          4289268       10.98              2331.12            1840
SELECT T1.LASTNAME,          2977586        7.62              1586.35            1877
SELECT T1.SALT, T1.P         2863354        7.33              1315.87            2176
select  q1."EDPORDER         1916547        4.91               261.18            7338

  5 record(s) selected.

Nesse exemplo, algumas consultas problemáticas em potencial agora aparecem em nosso conjunto de dados — consultas que não surgiram quando estávamos examinando consultas ordenadas por linhas lidas. É interessante olhar não apenas para o tempo de CPU total de todas as execuções, mas também o tempo de CPU médio por execução.

O que fazer com SQL problemática

Há algumas ações que podemos fazer para melhorar o desempenho de SQL problemática. Minha abordagem favorita é executar Explain e, em seguida, Index/Design Advisor em uma consulta problemática, para encontrar índices que possam ser úteis. (A indexação é uma arte separada, fora do escopo deste artigo.) Eu também converso com desenvolvedores sobre consultas problemáticas — às vezes fazendo recomendações de sintaxe específicas, ou às vezes discutindo como a frequência de execução de uma consulta em particular pode ser reduzida através de armazenamento em cache no nível de aplicativo ou outras técnicas.

Com que frequência deve-se realizar uma análise?

A frequência de exame dos dados no cache de pacotes depende de muitos fatores. Se você tiver o espaço necessário recomendo gravar as principais consultas problemáticas em tabelas de históricos periodicamente. Para bancos de dados OLTP, o ideal é a cada hora. Isso permite voltar e examinar períodos de tempo em particular com base em problemas de desempenho relatados ou picos nos indicadores de problemas de desempenho.

Um dos meus artigos favoritos do developerWorks nos últimos anos, Monitoring in DB2 9.7, Part 1: Emulating data reset with the new DB2 9.7 monitoring table functions, estabelece uma metodologia geral para emular a funcionalidade "reconfigurar comutadores do monitor". A mesma metodologia pode ser usada com a função MON_GET_PKG_CACHE_STMT para aproveitar os benefícios do esvaziamento do cache de pacotes sem o prejuízo no desempenho causado pela limpeza desse cache. Levando essa metodologia mais adiante, é possível gravar dados em uma tabela de históricos que inclua apenas informações do cache de pacotes de um período de tempo específico. Isso é especialmente útil para investigar problemas de desempenho após sua ocorrência, ou para realizar uma análise detalhada de um período de tempo problemático em particular.

Mesmo que você não rastreie esses dados, deve, no mínimo, examinar as informações armazenadas no cache de pacotes ao menos uma vez por trimestre e antes de períodos de pico. Ao trabalhar com um banco de dados OLTP, o foco das consultas pode mudar quando recursos diferentes forem usados, ou quando consultas diferentes se tornarem mais comuns — promoções diferentes podem conduzir o tráfego de usuários em direções diferentes. Se você estiver trabalhando com data warehouses e decision support systems (DSS), pode haver tipos diferentes de consultas executadas em diferentes momentos do ano, ou consultas que acompanham as mudanças de usuários.


O grande POR QUE

As consultas apresentadas aqui podem oferecer um bom ponto de partida para minerar dados valiosos no cache de pacotes. Ainda assim, a mineração do cache de pacotes pode ser trabalhosa. Portanto, como alguém deve analisar os dados do cache de pacotes e justificar o tempo gasto com isso? As respostas são simples — para melhorar o desempenho e para evitar aqueles problemas de indisponibilidade que nos tiram o sono. Em geral, se você ficar de olho no cache de pacotes e agir corretamente, é possível reduzir o hardware necessário para o banco de dados e aumentar o desempenho ao mesmo tempo.

Recursos

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=851511
ArticleTitle=Minerando o Cache de Pacotes para Encontrar SQL com Problemas no DB2 para Linux, UNIX e Windows
publish-date=12142012