IBM iSeries AS/400 SQL Performance
1. Introdução
Recentemente o gestor do site compute-rs.com fez alguns testes no site de um cliente no desempenho do SQL com grandes volumes de dados. Os resultados foram bastante interessantes que ele resumiu abaixo.
2. Application Descrição
O cliente é uma empresa financeira que armazena grandes volumes de dados para uma aplicação de Basileia, que prevê um mês por mês situação dos contratos. Os dados são utilizados para alguns relatórios padrão e também para consultas OLAP padrão não solicitada especialmente por usuários de controle de crédito
O aplicativo atualiza 7 diferentes arquivos físicos que são reunidos em uma associação chamada LF BASUNICO1L que tem um comprimento de registro total de 1789 caracteres. As chaves principais deste arquivo é o período de processamento (AAAAMM) eo número do contrato
3. Ambiente de Teste
Os testes foram feitos em um ambiente de teste onde os arquivos contidos os dados de cerca de 6 meses. O número total de registros para a junção LF foram de aproximadamente 11 milhões e os do período utilizado para o teste foram cerca de 2 milhões de pessoas.
O primeiro conjunto de testes foram feitos para testar os tempos necessários para copiar todos os registros de um período a partir da junção de arquivo lógico para um arquivo físico com o layout do mesmo registro. O registro foi escrito, usando três diferentes abordagens como segue:
Um simples CopyFile (CPYF), que inclui uma selecção como INCREL (* SE PERÍODO * EQ 200806)
A tradicional (arquivo orientado) programa Cobol (TSTFIL1), que usou um START para posicionar o ponteiro do arquivo para o primeiro registro do período e, em seguida, entrou em um loop de leitura e de gravação para gravar o arquivo de saída todos os registros do período solicitado .
Um programa COBOL com SQL embutido (TSTSQL1), que escreveu os registros de saída com um simples SQL Inserção dos registros selecionados.
Um programa COBOL com SQL embutido (TSTSQL3), que criou o arquivo de saída como uma tabela MQT SQL. Um segundo conjunto de teste foi utilizado em vez de testar o tempo necessário para ler alguns campos dos arquivos, usando diferentes abordagens como segue:
Tradicional arquivo programa Cobol orientado (TSTFIL5), que realizaram um START para posicionar o cursor e, em seguida, efetuou operações de leitura seqüencial de todos os registros do período selecionado. Cobol programa com SQL incorporado (TSTSQL5), que incluiu um cursor SQL para ler todas as linhas do período selecionado. Eu decidi realizar os testes em diferentes condições seguintes:
- Em um ambiente sem índices adicionais (ou seja, apenas os caminhos de acesso dos arquivos)
- Em um ambiente que poderia usar os índices também SQL adicionais
- Em um ambiente que é utilizado um modo SQL lógica em vez de juntar o original arquivo lógico
- Os resultados são descritos nos seguintes pontos
4. Testes com base apenas na junção de arquivo lógico
O teste feito no ambiente original para copiar cerca de 2 milhões de registros sem índices SQL foram os seguintes:
- O CPYF levou 19 minutos e 35 segundos
- O arquivo tradicional orientada programa Cobol levou 9 minutos e 20 segundos
- O programa COBOL com SQL embutido levou 28 minutos
5. Testes feitos após a criação de índices SQL
Eu verifiquei o arquivo de índice conselheiro QSYS2/SYSIXADV após os testes iniciais e percebi que houve um recorde, sugerindo a criação de um índice no campo período. Eu criei tanto índice de um vetor e um índice de raiz e, em seguida, começou o novo conjunto de testes. Os resultados foram os seguintes:
- O CPYF durou 7 minutos e 52 segundo
- O arquivo tradicional orientada programa Cobol levou 7 minutos e 7 segundos
-O programa COBOL com SQL embutido levou 13 minutos e 20 secons
- Houve um claro benefício, especialmente para o programa COBOL com SQL embutido. Por loooking o log, eu notei que tinha escolhido o otimizador a usar o índice do vetor que durante a execução.
É interessante que se você usar os comandos WRKOBJ ou DSPFD ou DSPDBR, os índices aparecem como arquivos lógicos com um atributo especial tipo SQL que tem o índice de valor.
Também é interessante que o espaço utilizado para os índices é muito menos do que aquilo que é necessário para um arquivo lógico. Na minha um ambiente de teste da PF, as principais utilizadas cerca de 500 megabytes, um LF utilizados cerca de 257 Mega bytes, o índice de base usada ocupava cerca de 175 Mega bytes eo índice radix apenas 22 Mega bytes.
6. Teste da criação do arquivo com MQT como uma tabela de consulta (materializado)
Tentei criar o arquivo de destino usando um programa COBOL com SQL embutido que produziu a tabela de saída como uma MQT vez do INSERT anterior e achei que o tempo estava muito bom
O programa teve apenas 57 segundos para produzir os resultados.
7. Teste de leitura
Eu comparei o tempo gasto pelos dois programas para leitura de todos os registros de um período selecionado para resumir um progr total O primeiroam Cobol tradicional era um arquivo de programa orientado, enquanto o segundo foi um Cobol SQL que inclui um cursor SQL para ler todos os registros selecionados.
O primeiro programa teve 13 minutos e 17 segundos para ser concluído, enquanto o segundo teve a primeira execução em apenas 7 minutos e 14 segundos para concluir e muito menos nos seguintes queridos.
8, Usando Views SQL em vez de arquivos lógicos
Eu tentei usar um equivalente exibição SQL para o arquivo lógico e repetir os testes acima, usando o modo SQL. Os resultados não foram significativamente diferentes daqueles com base no arquivo lógico, porém eu descobri que uma visão necessária muito menos espaço do que um equivalente LF.
As opiniões SQL aparecer novamente para o sistema como arquivos especiais lógica com o tipo SQL atributo que contém o valor VIEW. O espaço ocupado pela exibição de arquivos lógicos é muito inferior ao exigido por um arquivo lógico. No meu ambiente de teste um equivalente para juntar um arquivo lógico de cerca de 405 Mega bytes. necessários menos de 1 Mega Byte.
9. Conclusões
Os testes descritos acima parecem demonstrar que se segue:
A opção mais rápida para extrair os dados foi o programa COBOL com um SQL incorporado para criar uma tabela MQT.
O arquivo tradicional orientada programa Cobol foi mais rápido que o programa Cobol correspondentes incorporados que incluía uma declaração SQL INSERT. O tempo de execução do programa SQL Cobol foi significativamente afectada pela criação do índice do vetor SQL.
O arquivo tradicional orientada Cobol programa que lê todos os registros de um período selecionado, usando as operações de leitura e START NEXT foi mais lento do que o programa Cobol que ler os registros com um cursor SQL.
Os resultados concordam com alguns pontos de um Redbook IBM iSeries IBM eServer Modernizando Application Data Access - uma pedra angular roteiro (redbooks.ibm.com/abstracts/sg246393.html? Open). onde está escrito que:
As operações de inserção de SQL são mais lentas do que escrever Cobol declaração porque as operações de SQL incluem validações mais do que escrever em um oprrations PF DDS SQL não lê mais rápido do que as operações HLL. A principal razão é que um cursor de leitura, uma tabela do SQL não tem os dados extra de limpeza de código como uma leitura PF DDS. Usando modos de exibição SQL em vez de arquivos lógicos deve permitir uma redução significativa da ocupação do espaço. A conclusão final é que uma utilização sensata do SQL pode trazer melhorias significativas no desempenho de aplicações.