H um bom tempo o pessoal me pede dicas de performance e as melhores prticas de desenvolvimento de aplicaes para o DB2 , depois de ficar alocado

em vrios projetos deste tipo aonde todos dizem o DB2 est lento , o gargalo o banco de dados e outras coisas , posso afirmar que 98,75% dos problemas esto no desenvovimento de programas e a falta de conhecimento do uso de ndices , estrutura de tabelas e at mesmo noo de lgica , segue abaixo vrias dicas que podem ajudar e muito no diadia. Espero que seja til para vocs. Para o nicio de qualque trabalho de anlise de performance a utilizao de uma tima ferramenta de monitorao recomendada, temos a melhor conhecida como OMEGAMON da IBM que existe para z/OS , DB2 , CICS , IMS e outras . Muitos clientes j tem OMEGAMON instalado mas usam muito pouco seu potencial , tanto em relatrios batchs quanto em monitorao real-time , em breve passarei dicas para usar o OMEGAMON. Abcs -Estrututa de design DB2
y y y y y y y

Criar tablespace com opo MEMBER CLUSTER e TRACKMOD NO em ambiente DATASHARING para melhor inseres . Particionar tabelas com mais de 80 milhes de linhas para melhorar inseres e execues de utilitrios Segmentar os tablespaces simples para melhorar inseres e execues de utilitrios Garantir Reorganizao e RUNSTATs constantes das tabelas Uso de PCTFREE e FREEPAGE para inseres e atualizaes Uso de ndices em chaves estrangeiras (Fks) Avaliar necessidade de grande nmero de tabelas Pais e Filhos antes de implementar Integridade Referencial

-Escrita de SQL
y y

y y y y

Locks e concorrncia : -Uso de SELECT com clusula WITH UR para forar leitura suja (Caso queira fazer leitura para atualizao usar SELECT FOR UPDATE ),principalmente quando um programa contm alguma INSERT/DELETE/UPDATE , pois caso no exista a clusula UR o DB2 ir elevar o isolation para CS. Caso tenha que usar SELECT com isolation CS , fazer o BIND do package con CURRENTDATA(NO) para evitar locks. Usar SELECT FOR UPDATE se realmente atualizar o dado depois no mesmo programa. Usar SELECT WITH HOLD , se realmente desejar segura o ponteiro no result set aps a operao de COMMIT. Tanto em processamento BATCHs como principalmente no Online realizar o COMMIT o mais breve possvel, no CICS execute o comando SYNCPOINT COMMIT. Use a mesma maneira de acesso a tabela para todos os programas para melhorar concorrncia.

Performance :
y y

Evitar uso de muitas tabelas em um comando JOIN , pode ser usado SUB QUERIES Avaliar uso dos ndices durante um JOIN usando SQL EXPLAIN

y y y y y y

Quebrar os joins em uma query e testar o resultado de cada SELECT COUNT(*) , o menor nmero de linhas com o melhor filtro ser o melhor acesso. Quanto melhor garantir a unicidade do dado a ser lido seria melhor , garantido acesso via chaves primrias. Garantir o RUNSTATs para melhor acesso dos ndices Evitar uso de clusula DISTINCT para retirar registros duplicados , a garantia de unicidade do valor pode ser feita atravs da Evitar uso de ORDER BY ,caso necessrio usar o comando em coluna com ndice Evitar uso de SELECT MAX , caso necessrio usar o comando em coluna com ndice

ndice ideal :
y y y y y

Criar ndices com colunas que garantam um melhor acesso , quanto maior a cardinalide da coluna melhor. Colocar todas as colunas da clusula WHERE no ndice, quanto mais os predicados filtrarem o result set melhor , de preferncia no topo do ndice. Coloque aas colunas no ndice na sequncia do ORDER BY para evitar SORTs Forar uso de INDEXONLY , acessando apenas as colunas do ndice no SELECT Cuidado com alto nmero de ndices em tabelas com grande quantidade de INSERTs , DELETES e UPDATES

Lgica de programao :
y y y y y

Evitar uso de COOLGEN para gerao de cdigos indesejados como DISTINCT , FOR UPDATE , ORDER BY , SELECT MAX , CURSOR WITH HOLD , Usar campo SQLCA para tratar erro do DB2 e gerar mensagem com programas , SQL statement , reason code , Sqlcode , etc No fazer DISPLAYS em programas CICS. Se possvel entre com os dados ordenados para evitar fazer o SORT no DB2. Em loops guardar o dado anterior para no acessar o DB2 para buscar uma informao que j foi lida.