Recomendações para carga de dados
- Sempre que possível, trabalhe com RAW devices, o I/O fica bem mais rápido , porém no linux para isso é necessário ter kernel >2.6
- Uma alternativa ao RAW device é trabalhar com DIRECT_IO.
- Se estiver em ambiente HP-UX e esteja utilizando RAW devices, tenha certeza de ter a variavel KAIOON=1, caso contrário o KAIO não será utilizado.
- Se estiver trabalhando com a versão 11.50 xC6 ou superior, de preferência para o EXTERNAL TABLES, se sua versão for inferior vá para o HPL para fazer a carga, Ambos são as ferramentas de cargas de dados mais rápidas existentes.
Normalmente faço alguns shells para converter um dbimport para HPL / EXTERNAL TABLES.
Se não for possivel "converter" todo o dbimport para HPL tente com as tabelas maiores, removendo estas tabelas do script do dbimport , assim você pelo menos irá ganhar tempo nelas. - Ao utilizar o dbimport, confira no script [banco].sql :
- Está criando indices clusterizados, se sim, remova a opção CLUSTER
Avalie se esta sugestão é valida para todos os casos, pode ocorrer casos em que seja melhor manter a opção. - No final existe a execução do update statistics, remova do script e faça a atualização de estatisticas depois seguindo o padrão que você já trabalha.
Pessoalmente acho ineficiente os comandos de UPDATE STATISTICS gerado pelo "dbexport" . Digo ineficiente porque por experiência, comigo, muitas vezes foi mais rápido gerar através dos comandos que eu já trabalhava.
Observação: Lembre que apartir da versão 11.10 as estatistics de indice são criadas automaticamente no CREATE INDEX. - Remova todas as criações de indices, salve em outro arquivo SQL para executar após a carga do dbimport
- Está criando indices clusterizados, se sim, remova a opção CLUSTER
- Reconfigure o Informix:
- Aloque o máximo de memória possivel da maquina, temporariamente, apenas para o processo de importação (cuidado para não utilizar o SWAP).
- 50%/50% de buffers e shared memory
- Defina LRU_MAX_DIRTY/MIN = 90/1 , assim o checkpoint será mais longo, porém mais eficiente.
Mas faça isso apenas se não estiver utilizado o AUTO_LRU_TUNNING - Se estiver utilizando chunks em file system (cooked file), defina pelo menos 2 AIO vps para cada chunk. se estiver utilizando raw devices (KAIO), 4 AIO vps no total está de bom tamanho.
Mas faça isso apenas se não estiver utilizado o AUTO_IOVPS - Se estiver utilizando file system com journaling (ext3, ext4, raiser, jfs, hfs, etc), estude a possibilidade de refazer e trabalhar em um que não utilize journaling (ext2).
- Aumente seu PHYSBUFF e LOGBUFF para um valor mais alto, pelo menos 1024 (1MB)
- Defina o MAX_PDQPRIORITY =100
DS_TOTAL_MEMORY = <valor do SHMVIRTSIZE>
DS_MAX_SCANS = <qtde de discos fisicos utilizado> - Utilizar conexão de shared memory: NETTYPE ipcshm
Caso tenha problema com este tipo de conexão, configure uma TCP pelo loopback da maquina.
- Para a criação dos indices posterior ao dbimport/HPL execute o comando set PDQPRIORITY 100 no mesmo script dos indices ou defina a variável de ambiente: export PDQPRIORITY=100
- Defina LTAPEDEV e TAPEDEV para /dev/null para não gerar backup desnecessário da carga
- Tenha certeza de que o banco não esta com log ativo durante a carga e criação dos indices
Para remover o log utilizar algum dos dois comandos:
$ ontape -s -L 0 -N <banco> $ ondblog nolog <banco>
- Se possível não deixe que os arquivos do dbimport estejam no mesmo disco (fisico) que os chunks do banco, para não concorrer no I/O.
Se seu servidor tiver bastante memória, reserve uma parte para um file system do tipo TMPFS e copie seus UNLs para ele, assim o acesso será muito rápido.
Se não tiver outro disco, não tiver memória de sobra para utilizar o TMPFS e o ambiente de rede tiver boa performance, coloque os arquivos de carga em outra maquina, mapeie o acesso utilizando NFS ou SAMBA/CIFS e inicie a carga.
Em certos casos isto pode não ser tão performático porque a tranferencia da rede consome CPU pelo daemon do NFS,SAMBA/CIFS. No fim pode ser que ele mais atrapalhe do que ajude. - Tenha certeza de que possui dbspaces temporários criados e configurados no onconfig: DBSPACETEMP.
Eles farão diferença na criação dos indices.
Para garantir a boa performance, faça com que a soma do tamanho de todos os dbspaces temporários seja superior que o tamanho do maior indice a ser criado. - Se utilizado conexão TCP ou IPC PIPE, configure a váriavel FET_BUF_SIZE para um valor alto na mesma sessão que irá executar o comando de carga.
- 460 leituras
Tags:
Comentar