1. 10 razões para a versão 10 !
Filed under Uncategorized by Marcos Caurim on 25-04-2011
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
No Comments
Read More
Centenário !
Filed under Uncategorized by Marcos Caurim on 18-02-2011

2. 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/
No Comments
Read More
Perigos dos predicados
Filed under Uncategorized by Marcos Caurim on 07-12-2010

3. 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

4. No Comments
Read More
Aplicação ruim !! Problema no DB2 ?
Filed under 1 by Marcos Caurim on 06-09-2010
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

5. 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

6.  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.
(3) Comments
Read More
Leitura suja ??
Filed under 1 by Marcos Caurim on 24-08-2010
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
No Comments

7. Read More
Pessoal do lab está de volta
Filed under 1 by Marcos Caurim on 23-07-2010
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

9. No Comments
Read More
IBM lança Zentrerprise o novo conceito de mainframe
Filed under 1 by Marcos Caurim on 23-07-2010
É 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
No Comments
Read More
Novos rumos …
Filed under 1 by Marcos Caurim on 16-04-2010

10. 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 DISTINC T , 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 !! )

11. - 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
(1) Comment
Read More
É 10 !! Ele vem ai … DB2 10 para Mainframes
Filed under 1 by Marcos Caurim on 12-02-2010
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