Oi Pessoal ,

Ótimo evento pra clientes DB2 z/OS em São Paulo .

Abcs

Segue abaixo dez  bons motivos para  se orientarem mais sobre o DB2 z/OS versão 10.

1  Até 20 % de redução em  CPU para as transações batch e online
2  Dez vezes mais usuários evitando problemas de memória
3  Mais concorrência para uso do catalog, utilitários e  SQL
4  Mais alterações  online para DDLs e utilitários
5  Improved security with more granularity
6  Uso de dados temporais e versionamento
7  Melhorias de portabilidade de SQL 
8  Melhorias de uso e performance para pureXML 
9  Novas features incluíndo Acesso Hash, colunas adicioanais para índices únicos e pular migração da V8 para V10 *
10  Melhorias de produtividade para DBAs , Systems , analistas e programadores

* Muito interessante este ponto do skip migration , Alguns clientes americanos foram para a V10 direto sem problemas,
 porém temos alguns fatos a considerar :

Indo para V9 é possível usar algo desta versão com mais calma e depois ir para a v10.
No caso de iniciar o processo de V8 para V9 e volar para a V8 , não é possível mudar o plano de ir para a V10 novamente

Abcs

Comemorando os 100 anos da IBM , muito vídeos estão sendo lançados no youtube , o legal é que você pode ver como está empresa ajudou

o mundo a crescer e se desenvolver com diversas idéias , não baseado em petróleo e exploração apenas na frase THINK !!

Segue o mais interessante lógico voltado ao nosso system 360 como nosso mainframe o System z era chamado em 1960 !!

Vale a pena ver como ele mudou o jeito das empresas crescerem e continuará mudando …

Abcs

http://www.ibm.com/ibm100/us/en/icons/system360/

Muito se pergunta sobre ajuste de SQL , muitos dizem criar índices ,  mas vocês sabiam que  muitos índices já usados poderiam ajudar , porém com predicados mal escritos  na cláusula WHERE , mesmo com o índice exisente na coluna , o optmizer vai preferir ler toda a tabela ou até mesmo varrer todo índice (chamado de index screening0 ou match cols =  0 no explain ) ao invés de ir direto no dado do índice , conhecido como matching predicates.

O capítulo 27 do Admin guide traz todo este assunto em detalhes e é vital para qualquer pessoa que vai desenvolver código SQL.

O Db2 trata os predicados como indexados , stage1 e stage 2 , sendo esta ordem os melhore e os piores de serem executados.

Basicamente temos que focar em usar operandos de  = , evitar ranges como <=  ou >=  para evitar isto podes se usar o between em colunas como índice para serem predicados indexáveis.

ex:  COL1 =  ?

Operandos , funções eliminam qualquer chance de usar o índice , mesmo que o mesmo exista para a coluna.

ex : CAST (COL1) = ?    , COL1 + 3  =  ? 

Operandos booleanos :

Quanto mais usar predicado booleano aquele que elimina a linha toda quando for falso é melhor :

Ex COL1 = ?  AND  COL2  =”?

Evite usar  OR  , como COL1   = ?  or COL 2 = ?  . neste caso pense  até no UNION ALL.(lembre que UNION apenas causa SORT)

São dicas básicas que ja ajudam muito neste mundo muito vasto de SQL tuning , em breve teremos mais.

Abcs

Há um bom tempo o pessoal me pede dicas de performance e as melhores práticas de desenvolvimento de aplicações para o DB2 , depois de ficar alocado em vários 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 estão no desenvovimento de programas e a falta de conhecimento do uso de índices , estrutura de tabelas e até mesmo noção de lógica , segue abaixo várias dicas que podem ajudar e muito no dia-dia. Espero que seja útil para vocês. Para o ínicio de qualque trabalho de análise de performance a utilização de uma ótima ferramenta de monitoração é 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 relatórios batchs quanto em monitoraçào real-time , em breve passarei dicas para usar o OMEGAMON.

Abcs

-Estrututa de design DB2

• Criar tablespace com opção MEMBER CLUSTER  e TRACKMOD NO  em ambiente DATASHARING para melhor inserções .
• Particionar tabelas com mais de 80 milhões de linhas para melhorar  inserções e execuções de utilitários
• Segmentar os tablespaces simples para melhorar  inserções e execuções de utilitários
• Garantir Reorganização e RUNSTATs constantes das tabelas
• Uso de PCTFREE e FREEPAGE para inserções e atualizações
• Uso de índices em chaves estrangeiras (Fks)
• Avaliar necessidade de grande número de tabelas Pais e Filhos antes de implementar Integridade Referencial

-Escrita de SQL

• Locks e concorrência :
• -Uso de SELECT com  cláusula WITH UR para forçar leitura suja  (Caso queira fazer leitura para atualização usar SELECT FOR UPDATE ),principalmente quando um programa contém alguma INSERT/DELETE/UPDATE , pois caso não exista a cláusula 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 após a operação de COMMIT.
• Tanto em processamento BATCHs como principalmente no Online  realizar o COMMIT o mais breve possível, no CICS execute o comando SYNCPOINT COMMIT.
• Use a mesma maneira de acesso  a tabela para todos os programas para melhorar concorrência.

Performance :

• Evitar uso de muitas tabelas em um comando JOIN , pode ser usado SUB QUERIES
• Avaliar uso dos índices durante um JOIN  usando SQL EXPLAIN
• Quebrar os joins em uma query e testar o resultado de cada SELECT COUNT(*) , o menor número 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 primárias.
• Garantir o RUNSTATs para melhor acesso dos índices
•  Evitar uso de cláusula DISTINCT  para retirar registros duplicados , a garantia de unicidade do valor pode ser feita através da
• Evitar uso de ORDER BY  ,caso necessário usar o comando em coluna com  índice
•  Evitar uso de SELECT MAX , caso necessário usar o comando em coluna com  índice

Índice ideal :

• Criar índices com colunas que garantam  um melhor acesso , quanto maior a cardinalide da coluna é  melhor.
• Colocar todas as colunas da cláusula WHERE no índice, quanto mais os predicados filtrarem o result set é melhor , de preferência no topo do índice.
• Coloque  aas colunas  no índice na sequência do ORDER BY  para evitar SORTs
• Forçar uso de INDEXONLY , acessando apenas as colunas do índice no SELECT
• Cuidado com alto número de índices em tabelas com grande quantidade de INSERTs , DELETES e UPDATES

 Lógica de programação :

• Evitar uso de COOLGEN para geração de códigos 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
• Não fazer DISPLAYS em programas CICS.
• Se possível entre com os dados ordenados para evitar fazer o SORT no DB2.
• Em loops guardar o dado anterior para não acessar o DB2  para buscar uma informação que já foi lida.

Um dos grandes assuntos no DB2 é o processo de locks , como um grade banco de dados o DB2 usa muito bem os locks para manter a integridade dos dados , o que é uma premissa básica de um SGBD. Por outro lado locks usam espaço cerca de 500 bytes por lock e também se mal configurados podem causam problemas de perforamance devido ao grande número de aplicações tentando acessar a mesma informação. Para evitar locks ou tentar minimiza-los o existem os isolation levels bastante conhecidos pelos programadores DB2 , como o CS , RR , RS e o último chamado de UR (Uncomitted Read) ou leitura suja. Sempre foi falado que leitura suja não faz locks na tabela e com isso você pode ler dados que não foram comitados ainda , gerando dados não corretos caso este dados por algum motivo não sofrerem commits. A maioiria que exeuta este tipo de SELECT ou no parametro do BIND chamado ISOLATION , já está ciente desta situação e sabe que não se importa em trazer este tipo de dados.

É preciso estar atento há alguns fatos importante antes de usar o UR em ambiente de produção e em sistemas mais críticos , o grande uso do UR é pra Queries rápidas principalmente em Teste ou mesmo nas tabelas do catálogo DB2. Para uso em produção temos que saber que a história de não fazer locks realmente não é verdade , quando é feito um select deste tipo é executado o lock MDEL ou mass delete , o mesmo não é conhecido , ele serve para evitar as deleções em massa enquanto você está lendo os dados , loco quando sua query com UR estiver rodando , um DELETE ALL terá que esperar seu processo finalizar.

Agora caso você realmente queria evitar locks , saiba que caso exista um INSERT , UPDATE ou DELETE em seu programa e seu pacote foi feito o BIND com ISOLATION UR , é preciso forçar a cláusula UR no SELECT , pois sem ela DB2 elevara o isolation de todo pacote para CS , fazendo com que suas cláusulas SELECTs sem usar WITH UR comecem a fazem lock de linha , tabela ou tablespace de acordo com a configuração.

Com isto seu programa que você jura que não faz locks , está segurando recursos e podendo causar timeouts e deadlocks com outros programas tentam acessar a mesma tabela.

Abcs

Agora em agosto teremos a volta do pessoal do lab de DB2 z/OS com novas palestras foco o DB2 z/OS versão 10 que será lançado oficialmente este ano ,sem contar novas instruções sobre o DB2 V9 e como um todo , sem contar sessões de paralela para nosso irmão IMS.

Não percam esta chance !

Segue abaixo a folder do envento. Dessa vez teremos sessões em SP e Brasília . Além de Buenos Aires para nosso hermanos.

Abcs

É fato que cada vez mais as empresas buscam por economizar o dinheiro gasto em TI , com isto através dos focos do Smart planet a IBM lançou uma nova máquina que é capaz de ser 10 vezes mais potente com a Z10 e ao mesmo tempo economizar energia , espaço e processamento , sem contar q grande capacidade de integração com outros sistemas distribuidos aonde você realmente pode executar todo seu workload em uma máquina incluindo os processamentos caríssimos de BI , SOA , BAO , etc Segue o link em português com mais informações …
E para aqueles que pensam que os investimentos em mainframe acabaram , neste projeto foram involvidas 5 mil pessoas a um custo de 1.5 bilhões de dólares.

http://w3.ibm.com/news/w3news/top_stories/2010/07/br_stg_zenterprise_lancamento.html
Abcs

Oi Pessoal , depois de dois meses de desaparecimento do blogueiro estou
de volta. Primeiro devido a minha pequeníssima férias e depois pela
mudança de área com o DB2. Não atuo mais como DB2 suporte para clientes
internacionais focando em suporte 24 x7 , agora estou de volta aos clientes
brasilerios auxiliando em todo tipo de projeto relacionado ao nosso DB2 z/OS
como Performance , migração , instalação , integração de dados , consultoria
e outra inúmeras atividades extremamente desafiadoras que sempre busquei , com isto a atualização de atuais e novos conceitos se tornam muito mais mandatórias , espero cada vez mais contribuir com vocês.

Falando de PERFORMANCE , parece chato mas existem inúmeros processos
que não focam em coisas como um processo criado de reorganização de tabelas
, retirada de estatísticas usando Real time statistics e funções interessantes
como COLGROUP e FREQVAL para melhor análise das colunas , sem contar
com um próximo contato com o time de desenvolvimento das aplicações ,
hoje em dia é comum usarmos fabricas de softwares para o desenvolvimento
e manutenção dos programas , com isto temos de estar sempre atentos
a qualidade desses programas se lembrando de coisas básicas como :

- Evitar SORTs através de cláusulas como DISTINCT , ORDER BY e GROUP BY sem necessidade (índices podem ajudar).
- Sempre tentar qualificar o result set com um ótimo conjunto de predicados e índices bem feitos (uso do EXPLAIN não dói !! )

- Evitar INSERT em UPDATES em índices devido a relocação e I/Os.
- Uso constante de monitores como OMEGAMON e DB2PM para avaliar e medir
as aplicações. É muito legal o quanto você aprende utilizando REPORTs como
de ACCOUNTING (focado em tempo de planos e packages ) , LOCKS ,
STATISTICS(uma visão do DB2 em Geral ) , BUFFER POOL , etc
Lógico que não podemos esquecer de checar se os traces estão ativos e logicamente checar o overhead que eles podem causar .

É isso aí não tenham medo de mudar o que está rodando , é possível deixar melhor , muito melhor !!

Abcs

A IBM anunciou está semana o lançamento da versão beta do DB2 10 para z/OS , logo esperamos que até o fim do ano ela deve ser lançada oficialmente. Podem esperar muitas novidades na parte de XML , Aplicações Web , corte de custos com CPU e Storage , utilização de memória , etc

Acessem este site e vejam tudo que existe até o momento , juntamente com depoimentos de experts da área.

http://www-01.ibm.com/software/data/db2/zos/db2-10/

Para aqueles que pensam que só chegara no Brasil muito tarde , se você está rodando versão 8 que foi a migração mais trabalhosa , migrar para 9 e 10 não será tão difícil e demorado assim.

Aguardemos …

Abcs