Cymulate anunciou integração tecnológica com a Tenable
Utilização de Global Temporary Table em Db2 z/OS – Por Roy Boxwell – Arquiteto Senior
Aprenda, através de exemplos, porque CGTT (CREATEd Global Temporary Tables) possivelmente são melhores que DGTT (DECLAREd Global Temporary Tables) e como usá-las para acelerar a performance.
Quando as Global Temporary Tables foram introduzidas (DB2 V5.1) era tudo muito claro! Você usava DDL normal para fazer CREATE de uma Global Temporary Table no catalogo DB2, sendo que cada processo tem sua própria cópia. Existiam restrições como UPDATE, DELETE único, e valores DEFAULT. ROLLBACK / COMMIT e reutilização de dados não eram tão simples, mas tudo meio que funcionava.
Global – mas não como você conhece!
Então veio junto a novíssima Global Temporary Table (DB2 V6.1) que, só para deixar claro, eram prefixadas com DECLARE para que fosse 100% óbvio que não tinha nada a ver com a “outra” tabela temporária… Eu te digo, se algum dia eu encontrasse o desenvolvedor que inventou esses nomes num beco escuro…. Mas estou divagando… Então com esta nova versão DECLARE subitamente você “poderia” fazer UPDATE e DELETE e junto veio uma cláusula ON COMMIT para tornar mais simples manipular dados com COMMIT – Uau!
Global Temporary Table em DB2 12 – Tudo novo e melhorado
Com DB2 12, a lista completa de coisas que você pode fazer com CREATE GLOBAL TEMPORARY TABLE (de agora em diante simplesmente CGTT) ao invés de DECLARE GLOBAL TEMPORARY TABLE (de agora em diante simplesmente DGTT) é:
Por que CGTT?
Então, olhando para a lista acima você deve imaginar – “Porque alguém usaria CGTTs?
Bem o motivo é a “Performance!”
DGTTs podem fazer todos os truques porém CGTTs são muito velozes!
Ter crença é ok porém testes trazem confiança!
Escrevi alguns pequenos programas em COBOL que faziam a mesma coisa: um usando DGTT e outro usando CGTT. Tudo o que os programas faziam, era chamar uma SECTION 1000 vezes que fazia DECLARE de uma tabela (ou não, obviamente!) e então chamava outra SECTION que inseria 10 linhas e abriam o cursor para então buscar essa linhas de volta com um ORDER BY. Eu escolhi esse teste porque a maioria das utilizações de DGTT/CGTT é de baixo volume porém alta taxa de chamadas (pense em STORED PROCEDURES aqui!). Então eu queria ver que tipo de sobrecarga 1000 DGTTs causaria.
Sem EDMPOOL aqui!
Monitorar não é fácil pois o uso de DGTT não está no EDMPOOL, então eu fiz do jeito antigo, fazendo testes quando estava sozinho na máquina, cinco vezes para cada um. Eu fiquei um pouco chocado com os resultados:
Então eu mudei o DGTT para ser também NOT LOGGED
Não é muito melhor! Mas lembre-se, eu não fiz nenhum processamento de DELETE ou UPDATE, então os dados da sua performance deve ser melhor que os meus.
Impressionante !
Agora a razão para todo esse I/O e CPU é:
todas as operações internas que o DB2 precisa fazer para o DGTT, lembre-se que o CGTT *já* foi declarado e existe no catálogo. Não é o caso do DGTT, naturalmente. Isso pode, como já visto, adicionar muita sobrecarga.
Agora, a boa e velha Regra do Dedão ainda é verdadeira:
Um CGTT é ótimo para fazer zero atualizações e acessos sequenciais!
Melhoria DB2 10
Quando um cursor é declarado com o atributo RETURN TO CLIENT, este cursor fica disponível para o cliente chamador de origem. Isso é ótimo, pois o cursor é “invisível” para todos os procedimentos intermediários.
Morte por DGTT
O problema no passado era a troca do conjunto de resultados finais do stored procedure. Tinha que ser lido e colocado em outro DGTT e então esse tratamento era repetido por todo o caminho de volta da cadeia de chamada. Agora, se você tiver um “cursor final”, você pode simplesmente declara-lo como RETURN TO CLIENT- Isso economiza toneladas de CPU e tempo!
Última dica!
Lembre-se, se você usar cursores STATIC SCROLLABLE, então eles *devem* usar DGTTs em segundo plano para funcionar!
Mais trabalho ainda…
Então um colega que revisa todas as minhas newsletters, um trabalho danado, mas que alguém tem que fazer, me pergunta:
“Fico pensando em como seriam os números se você declarasse o GTT só uma vez, e daí INSERTED/SELECTED/DELETED várias linhas 1000 vezes? Porque é assim que eu venho usando…”
Então eu alterei os programas para só fazerem DECLARE uma vez, inseri 1000 linhas, selecionei as 1000 linhas e então fiz um DELETE em massa dos dados.
Muito próximos, em termos de performance, mas ainda assim a CGTT é mais rápida – Hora de verificar o seu uso dessas tabelas temporárias!