Preparação do exame 919 de System Administration Certification for Informix 11.70, Parte 4: Ajuste de desempenho

Ajuste o banco de dados IBM Informix® e seus diferentes subsistemas para um desempenho ideal. Após uma visão geral, continue com exemplos sobre como considerar o servidor de banco de dados e seus subsistemas. Saiba mais sobre elementos importantes de otimização de banco de dados, incluindo pontos de verificação, recuperação, criação física de log, criação lógica de log, E/S assíncronas, parâmetros da rede, recursos de disco, recursos de VP de CPU, PDQ, gerenciador de concessão de memória, encadeamentos de varreduras, criação de índice, manutenção de estatísticas e autoajuste. Use este tutorial, o quarto de uma série de oito, para ajudar a prepará-lo para a Parte 4 do exame 919 do Informix 11.70.

Jay B Peterson, Staff Software Engineer, I.B.M.

Photo of Jay PetersonJay Peterson é analista de suporte técnico de primeira linha. Ele trabalha no suporte ao Informix desde 1998 e é especializado em problemas relacionados a desempenho. Jay é autor de muitos artigos técnicos sobre produtos Informix.



Frank Arias, Advanced Support Engineer, I.B.M.

Photo of Frank AriasFrank Arias trabalha na IBM como engenheiro de suporte avançado no Informix Down System Diagnostics.



22/Mar/2012

Antes de iniciar

Saiba o que esperar desse tutorial e como tirar o máximo proveito dele.

Sobre esta série

Está pensando em obter uma certificação em System Administration for Informix versão 11.70 (Exame 919)? Se estiver, você está no lugar certo. Esta série de tutoriais de preparação para a certificação de Informix abrange todos os tópicos que você deverá entender antes de ler a primeira pergunta do exame. Mesmo se não estiver procurando certificação imediata, estes tutoriais são uma ótima fonte para começar a aprender sobre o que há de novo no Informix 11.70.

Sobre este tutorial

Este tutorial apresenta e descreve os subsistemas no Informix 11.70, com ênfase em mudanças recentes. Nesse tutorial, você aprenderá sobre o seguinte para otimizar seu servidor Informix.

  • Pontos de verificação
  • Recuperação
  • Criação de log físico
  • Criação de log lógico
  • VP E/S Assíncrona
  • Parâmetros de rede
  • Recursos de disco
  • Recursos de VP de CPU
  • PDQ e Memory Grant Manager
  • Encadeamentos de varredura
  • Criação de índice
  • Manutenção de estatísticas
  • Autoajuste do servidor

Este tutorial é o quarto em uma série de oito tutoriais para ajudá-lo a se preparar para o System Administration for Informix V11.70 Certification (Exame 919). O material neste tutorial abrange primeiramente os objetivos na Seção 4 do teste, que é titulado seção Ajuste de desempenho.

Se ainda não fez isso, considere fazer o download e instalar uma cópia do IBM Informix 11.70. Instalar o Informix o ajudará a entender muitos dos conceitos que são testados no exame de certificação System Administration for IBM Informix V11.70.

Objetivos

Após concluir este tutorial, você deve poder:

  • Entenda as considerações de recurso do sistema operacional
  • Use os recursos do Informix para otimizar o desempenho

Pré-requisitos

Para entender o material apresentado neste tutorial, você deve estar familiarizado com o seguinte:

  • O ambiente Informix (arquivo de configuração e parâmetros, instalação e administração)
  • Comandos de servidor de banco de dados (onstat, onmode, oncheck, dbschema)
  • Conceitos e terminologia do Informix (dbspaces, chunks, log físico, log lógico, pontos de verificação e assim por diante)

Conclua essas etapas para se preparar para este tutorial:

  1. Faça o download e instale uma cópia do IBM Informix 11.70.
  2. Crie uma instância do servidor.
  3. Crie o banco de dados stores_demo usando o comando %dbaccessdemo7 -log -nots

Você deve poder usar sua instância e o banco de dados stores_demo como o ponto de partida para testar os conceitos apresentados neste tutorial.


Ajustando o Desempenho no Informix

Visão Geral do Ajuste de Desempenho

O ajuste de desempenho é um processo elaborado. Para abordar o ajuste de desempenho, lembre-se de que coisas aparentemente não relacionadas poderiam afetar uma às outras. Ao ajustar para o desempenho melhorado, certifique-se de documentar as mudanças e o desempenho de execuções de amostra, para que possa sempre voltar se precisar voltar algo que teve um impacto negativo no desempenho.

Como Iniciar

Um dos grandes problemas no ajuste de desempenho é que há tantos subsistemas que é difícil saber que algo precisa de ajuste. A experiência e a experimentação anteriores são úteis para desenvolver uma intuição do que está operando idealmente e do que pode precisar de um pouco de ajuste. Experimente mais para ver se sua intuição prevê mudanças que melhoram o desempenho em seu servidor.


Sistemas Operacionais Afetados com Recursos de Sistema Operacional

O desempenho do seu aplicativo do servidor de banco de dados depende dos seguintes fatores principais:

  • Recursos de hardware
  • Configuração do sistema operacional
  • Configuração de rede e tráfego
  • Gerenciamento de memória

Você deve considerar estes fatores quando tentar identificar problemas de desempenho ou fizer ajustes em seu sistema.

Recursos de Hardware

Os componentes de hardware incluem o seguinte.

  • CPU
  • Subsistemas de E/S de disco
  • Memória física

Configuração do Sistema Operacional

O servidor de banco de dados depende do sistema operacional para fornecer o acesso de nível baixo para dispositivos, para planejamento de processo, para comunicação interprocessual e oferecer outros serviços vitais.

A configuração de seu sistema operacional tem um impacto direto em quão bem o servidor de banco de dados é executado. O kernel do sistema operacional usa uma quantia significativa de memória física que o servidor de banco de dados ou outros aplicativos não podem usar. Além disso, você deve reservar recursos adequados de kernel para o servidor de banco de dados.

Além de ajustar o kernel, há limites flexíveis em vários recursos, como tamanho de pilha, número de descritores de arquivos e assim por diante. Eles podem ser examinados e ajustados usando o comando ulimit . O comando ulimit não é abordado neste tutorial.

O diretório temp é um repositório comum para muitos aplicativos comuns (como vi, ed ou o kernel). Temp pode precisar de ajuste de acordo, dependendo das necessidades dos usuários e aplicativos em execução no sistema operacional.

Gargalos de Disco e E/S de Controlador

O servidor de banco de dados pode precisar executar operações de E/S em mais de um objeto (como uma tabela e um arquivo de log lógico) localizado no mesmo disco. A contenção entre os processos ocupados com demandas altas de E/S podem diminuí-los. É importante monitorar o uso de disco. Em tal cenário, é possível ver ganhos de balanceamento ao fazer balanceamento de carga (movendo as tabelas para outro disco).

Configuração de Rede e Tráfego

Os aplicativos que dependem de uma rede para comunicação com o servidor de banco de dados e os sistemas que contam com a replicação de dados para manter a alta disponibilidade estão sujeitos a restrições de desempenho dessa rede. As transferências de dados sobre uma rede normalmente são mais lentas que as transferências de dados de um disco. Os atrasos de rede podem ter um impacto significativo no desempenho do servidor de banco de dados e outros programas de aplicativos que são executados no computador host.

Gerenciamento de Memória

O sistema operacional precisa ter uma página na memória para fazer qualquer operação nessa página. Se o sistema operacional precisar alocar memória para uso por um processo, primeiro ele tentará acessar qualquer páginas não utilizada na memória que ele puder encontrar. Mas, se não existir nenhuma página, o sistema de gerenciamento de memória então terá de escolher páginas que outros processos ainda estejam usando. O sistema operacional tenta determinar as páginas que menos parecem ser necessárias na curta execução que podem ser substituídas pelas novas páginas. Este processo de localizar tais páginas que podem ser substituídas é chamado de varredura de página. Uma varredura de página aumenta a utilização da CPU.

A maioria dos sistemas de gerenciamento de memória usa um algoritmo menos utilizado recentemente para determinar quais páginas podem ser substituídas na memória. Uma vez identificadas, essas páginas são copiadas fora do disco. A memória é então liberada para uso por outros processos. Quando uma página é gravada no disco, é gravada em uma área específica chamada espaço de troca ouárea de troca, onde está disponível para leitura de volta na memória. Este espaço é normalmente um disco dedicado ou uma partição de disco. O processo é chamado paginação. A paginação usa recursos de E/S e ciclos de CPU para fazer seu trabalho.

Em algum ponto, as imagens da página foram paginadas devem ser copiadas novamente para uso pelos processos que precisam delas. E então o ciclo se inicia novamente com páginas mais velhas (páginas que não foram usadas relativamente recentemente). Se houver paginação de um lado para outro, o sistema operacional poderá alcançar um ponto em que o kernel está quase totalmente ocupado com a cópia de páginas dentro e fora. Este estado é chamado de thrashing. Se o sistema estiver fazendo thrashing, todo o trabalho útil é interrompido.

Para evitar thrashing, alguns algoritmos de gerenciamento de memória do sistema operacional, na verdade, são escalados grosseiramente em um certo limite. Em vez de procurar páginas mais antigas, ele descarrega para a área de troca todas as páginas (para o espaço de troca no disco) para um determinado processo. Este processo é chamado de troca.

Cada processo descarregado para a área de troca fora da memória deve, por fim, ser descarregado de volta. A E/S de disco para o dispositivo de troca aumenta drasticamente o tempo necessário para alternar entre os processos, pois cada comutador de contexto deve ler (na memória) todas as páginas envolvidas com o processo. O desempenho é limitado pela velocidade na qual essas páginas podem ser transferidas. Um sistema que está trocando é severamente sobrecarregado e o rendimento é prejudicado.

Muitos sistemas operacionais possuem comandos que fornecem informações sobre paginação e atividade de troca. Os relatórios de estatísticas importantes incluem o seguinte:

  • Número de páginas paginadas ou descarregadas para a área de troca para fora da memória
  • Número de varreduras de página (este é um indicador antecipado de que a utilização de memória está se tornando um gargalo)
  • Número de páginas paginadas na memória (este número é geralmente não tão confiável quanto um indicador de um problema como a paginação, pois a paginação inclui o carregamento de processos e o carregamento de páginas paginadas quando os processos ativos terminam e a memória é liberada)

Configurando o Servidor

Esta seção enfatiza os aprimoramentos recentes da configuração do servidor que afetam individualmente o desempenho e não são abordados posteriormente em tópicos mais amplos.

VPCLASS

Como o Informix é escalável, ele pode ser ajustado para acomodar grandes instâncias. O parâmetro principal para processadores virtuais (VPs) é o VPCLASS .

O parâmetro VPCLASS substituiu os seguintes parâmetros descontinuados:

  • NUMCPUVPS
  • SINGLE_CPU_VP
  • AFF_SPROC
  • AFF_NPROCS
  • NOAGE
  • NUMAIOVPS

Sintaxe de VPCLASS

Lista 1 mostra a sintaxe do VPCLASS .

Lista 1. Sintaxe de VPCLASS
nome de classe de VPCLASS, opções

O classname na guia VPCLASS fornece o nome da classe do processador virtual que está configurando. O nome não faz distinção entre maiúsculas e minúsculas.

É possível definir novas classes de processador virtual para rotinas definidas pelo usuário ou módulos DataBlade® ou é possível definir valores para uma classe de processador virtual. Os nomes de classe em Tablela 1 são predefinidos.

Tablela 1. Nomes de Classe VPCLASS Predefinidos
admlioshmadt
mscsoccpu ntk
strjvpopttli
kioaiopioencrypt

A variável classname é necessária. Diferente da maioria dos parâmetros de configuração, VPCLASS tem vários campos de opção que podem aparecer em qualquer ordem, separados por vírgulas. Não é possível usar nenhum espaço em branco nos campos. O VPCLASS tem os seguintes parâmetros secundários opcionais:

  • num=num_VPs
  • max=max_VPs
  • aff=affinity
  • noage
  • noyield

Cada processador virtual é instanciado como um processo de sistema operacional. Portanto, é possível usar o VPCLASS para dedicar uma classe de atividades a um processo oninit. Para obter mais informações, consulte Recursos.

Configurando para Diversas CPUs

Como mencionado, o Informix é escalável e pode ser configurado para acomodar e aproveitar diversas máquinas de CPU. O número de VPs de CPU pode ser representado, como mostrado em Lista 2.

Lista 2. Configurando para 3 VPs de CPU
VPCLASS  cpu,num=3

VPs Java

A opção de JVP do parâmetro de configuração VPCLASS configura o número de processadores virtuais Java. Este parâmetro é necessário ao usar o driver JDBC do IBM Informix. No UNIX, você deve definir diversos processadores virtuais Java para executar rotinas Java definidas pelo usuário em paralelo.

VPs de Rede

Para classes de VP tli, shm, str e soc, você deve configurar o parâmetro de configuração NETTYPE de VP_class para NET.

Por exemplo, é possível configurar o parâmetro VPCLASS como mostrado em Lista 3.

Lista 3. Parâmetros VPCLASS para Usar NET
VPCLASS  shm,num=1
VPCLASS  tli,num=1

O parâmetro NETTYPE deve ser configurado como mostrado em Lista 4.

Lista 4. Parâmetros NETTYPE com NET
NETTYPE  ipcshm,1,100,NET
NETTYPE  tlitcp,1,100,NET

Configurando Parâmetros de Memória Compartilhada

Alocações de memória compartilhada com o servidor de banco de dados do Informix dependem de vários parâmetros de configuração, como mostrado em Tablela 2.

Tablela 2. Parâmetros de Memória Compartilhada
ParâmetroDescrição
EXTSHMADDEspecifica o tamanho de um segmento de extensão incluído
SHMADDEspecifica o incremento de memória que é incluído quando o servidor de banco de dados solicita mais memória
SHMBASEEspecifica o endereço de base de memória compartilhada e é dependente do computador. O valor depende da plataforma e se o processador é de 32 ou 64 bits. Para obter informações sobre que valor SHMBASE usar, consulte as observações do computador.
SHMTOTALEspecifica a quantia máxima de memória que o servidor de banco de dados tem permissão de usar
SHMVIRTSIZEEspecifica o tamanho da primeira parte da memória que o servidor de banco de dados anexa
BUFFERPOOLConfigura a cache da página de memória compartilhada. Número de buffers por (tamanho de página) conjunto, tamanho de página e parâmetros de LRU

Considere cuidadosamente os parâmetros de configuração de memória compartilhada. As principais considerações de desempenho são o armazenamento em cache máximo da página (BUFFERPOOL) e a alocação de memória virtual adequada (SHMVIRTSIZE). Se a memória virtual inicial for inadequada para processamento de longo prazo, a adição dinâmica de segmentos virtuais (SHMADD) pode criar números excessivos de segmentos virtuais durante o processamento, o que pode afetar adversamente o desempenho.

DIRECT_IO

O parâmetro DIRECT_IO possibilita E/S direta e E/S simultânea para aprimoramentos de desempenho com chunks definidos usando arquivos processados. E/S usando arquivos processados é geralmente mais lenta que dispositivos brutos devido a uma camada extra de E/S e buffer usados para leitura e gravação nos arquivos processados. O Informix não tem controle sobre este subsistema de sistema operacional. Certas plataformas de sistema operacional, no entanto, suportam E/S direta, o que desvia a camada de E/S e o buffer para chunks de arquivos processados. O desempenho para arquivos processados pode se aproximar do desempenho dos dispositivos brutos usados para chunks dbspace.

A E/S direta pode ser usada somente para chunks regulares dbspace. Não é usado para dbspaces temporários. O sistema de arquivos e o sistema operacional devem suportar a E/S direta para o tamanho da página. A E/S direta não é suportada com dispositivos brutos. A E/S assíncrona do kernel (KAIO) é o método preferencial de E/S para chunks que são posicionados em dispositivos brutos.

E/S simultânea, atualmente suportada no AIX®, inclui o recurso simultâneo sobre a E/S direta. A E/S simultânea permite diversas leituras simultâneas e gravações em um arquivo. O aprimoramento de desempenho é mais notável com E/S a chunks únicos divididos em diversos discos.

Para determinar se o Informix está usando E/S direta ou simultânea para um chunk, monitore a quinta posição dos campos sinalizadores de onstat -d, como mostra a Tablela 3.

Tablela 3. Configuração de DIRECT_IO
Configuração de DIRECT_IOEfeitoSinalizador onstat -d
0E/S direta desligada-
1E/S direta ligadaD
2E/S direta e simultânea emC

Em alguns sistemas operacionais que permitem E/S direta, as implementações usam KAIO. Se a E/S direta estiver ativada, o servidor de banco de dados tenta fazer o trabalho com KAIO. O número de processadores virtuais AIO pode ser reduzido se KAIO estiver ativado. Isto presume que KAIO esteja ligado (KAIOOFF não está configurado no ambiente).

O Windows não suporta ONCONFIG . DIRECT_IO pois a E/S direta está ativada por padrão na plataforma Windows.

SQLTRACE

É possível configurar o parâmetro de configuração SQLTRACE em uma variedade de formas para coletar os dados de desempenho para consultas individuais. Use SQLTRACE para definir o escopo do rastreio. As configurações padrão no arquivo de configuração são mostradas em Lista 5.

Lista 5. Configurações Padrão
SQLTRACE level=low,ntraces=1000,size=2,mode=global

Os dados de rastreio são armazenados em tabelas sysmaster e visíveis com onstat -g his . Por exemplo, é possível visualizar estimativas do custo de plano de consulta, número de linhas retornadas e dados do perfil. Também é possível ativar e desativar sqltracing usando as funções task() e admin() do banco de dados sysadmin.

O rastreio de SQL é particularmente útil para estudar consultas individuais executadas em aplicativos que executam muitas consultas.

BATCHEDREAD_TABLE

O Informix, às vezes, executa varreduras leves em grandes tabelas de dados, lendo muitas páginas de uma vez e efetuando bypass do buffer pool. É possível ativar varreduras leves para tabelas compactadas, tabelas com linhas que são maiores que uma página e tabelas com quaisquer dados, incluindo os tipos VARCHAR, LVARCHAR e NVARCHAR ao ativar BATCHEDREAD_TABLE no arquivo de configuração. Este parâmetro é automaticamente ativado.

As varreduras leves efetuam bypass do buffer pool e fornecem uma melhoria de desempenho para algumas consultas. Monitore a atividade de varredura leve usando o comando onstat -g scn .

BATCHEDREAD_INDEX

Configure BATCHEDREAD_INDEX para direcionar o servidor a buscar um conjunto de chaves de um buffer de índice quando apropriado, assim aumentando leituras de buffer.


Otimizando Desempenho de Comunicação

Ajustando uma Conexão do Servidor Nomeada

Como um administrador de banco de dados, você deseja ajustar os parâmetros de rede para otimizar o desempenho de comunicações para as várias conexões do servidor. As conexões são feitas para o servidor ou alias e eles são ajustados independentemente. Os parâmetros de configuração do servidor DBSERVERNAME e DBSERVERALIASES respondem a uma linha no arquivo sqlhosts. O protocolo (segundo arquivo) para essa linha mapeia a conexão com uma entrada NETTYPE correspondendo aos protocolos. Configure as entradas NETTYPE para sintonizar. A definição NETTYPE é mostrada em Lista 6.

Lista 6. Definição NETTYPE
NETTYPE protocol,poll_threads,conn_per_thread,VP_class

A configuração NETTYPE designa a classe do processador virtual (VP_class) na qual os encadeamentos de pesquisas farão seu trabalho. Os encadeamentos de pesquisas processam solicitações de conexão recebias e as passam aos encadeamentos de listener, que aceitam a conexão do cliente e iniciam um encadeamento sqlexec. Os encadeamentos de pesquisas podem executar sequencialmente ou em processadores virtuais (VPs) da CPU ou em VPs NET (de rede). Eles geralmente são executados com mais eficiência em VPs de CPU para máquinas de única CPU. Em um computador de multiprocessador com um grande número de clientes remotos, no entanto, sua execução em um VP NET pode obter um melhor rendimento.

É possível sintonizar poll_threads e conn_per_thread para o tamanho do carregamento de conexão esperado do servidor de banco de dados. Um encadeamento de pesquisas é geralmente suficiente para sistemas menores. Para sistemas que podem ter 200 ou mais usuários de rede simultâneos, um melhor desempenho pode ser resultado da inclusão de mais encadeamentos de pesquisas. Com alto carregamento de usuário, talvez seja necessário experimentar determinar a configuração ideal dos encadeamentos de pesquisas (independentemente se sequencial ou em execução em VPs NET).

Observe que há um processador virtual de rede criado para cada encadeamento de pesquisas. O NETTYPE em Lista 7 configura 3 encadeamentos de pesquisas em 3 processadores virtuais soc para um total de 600 conexões do usuário.

Lista 7. Exemplo de Definição de VP NET
NETTYPE soctcp,3,200,NET

O servidor de banco de dados pode incluir recursos para conexões de rede adicionais conforme necessário. Lista 7 não limita as conexões do soquete para 600. Entretanto, no caso de conexões de memória compartilhada, o número configurado é um limite rígido.

Quando NETTYPE não está configurado, o padrão é executar o encadeamento de pesquisas para o protocolo usado para o servidor DBSERVERNAME sequencialmente (VP da CPU) e o DBSERVERALIASES nos processadores virtuais de rede com spawn para o tipo de protocolo designado. Como um encadeamento de pesquisas é executado em um processador virtual, o Informix faz spawn de processadores virtuais de rede adicionais se houver mais encadeamentos de pesquisas configurados que os processadores virtuais de CPU.

Se esperar um grande número de conexões e seu sistema operacional suportar uma pesquisa rápida, ative FASTPOLL para pesquisa rápida de sua rede e desempenho de conexão ideal, conforme mostrado em Lista 8.

Lista 8. Comando FASTPOLL
FASTPOLL  1

Alocando Encadeamentos de Listener Adicionais

Os encadeamentos de listener autenticam usuários, estabelecem conexões com o servidor de banco de dados e iniciam encadeamentos sqlexec. É possível incluir encadeamentos de listener se sentir que o servidor não está lidando com as solicitações de conexão satisfatoriamente. Um encadeamento de listener é dedicado à porta na qual é executado. Será necessário um parâmetro DBSERVERALIASES adicional para especificar um dbservername para cada porta adicional e uma linha correspondente no arquivo sqlhosts com o protocolo correto e uma porta exclusiva.

Incluindo outra Placa de Interface de Rede

Pode haver uma situação em que uma placa de interface de rede para o computador host não possa manipular o rendimento de conexão desejado. Ou pode haver uma necessidade de conectar o servidor de banco de dados a mais de uma rede. Nesses casos, é possível incluir uma placa de interface de rede.

Para suportar diversas placas de interface de rede, você deve designar cada placa a um único nome do host ou endereço de rede. Após incluir uma placa de rede, inclua um encadeamento de listener adicional para executar nessa placa. O servidor de banco de dados usará a entrada do nome do host no arquivo sqlhosts para determinar qual placa usar.

Buffers de Rede

O servidor de banco de dados tenta otimizar o uso de memória da conexão. O cliente solicita alocação imediata do buffer de memória de rede a partir do conjunto de memórias e quando os buffers estão liberados, eles permanecem em um conjunto. Isto evita realocação desnecessária. Este buffer pool livre está disponível para vários protocolos, incluindo SOCTCP, IPCSTR e TLITCP. Há um mecanismo para retornar buffers do conjunto livre ao conjunto de memórias global para evitar alocação desnecessária de memória quando o uso estiver inativo. O servidor calcula um limite de buffer livre e quando esse número é excedido, os buffers são retornados ao conjunto global.

O servidor de banco de dados usa a fórmula em Lista 9 para calcular o limite para buffers livres no buffer pool da rede.

Lista 9. Fórmula para Limite de Buffers Livres
limite de buffers de rede livres = 100 + (0,7 * número_de_conexões)

O valor number_connections deve ser o terceiro campo do NETTYPE .

O servidor de banco de dados soma o número calculado para os vários protocolos que usam o buffer pool livre. Essa soma é comparada ao número de buffers no conjunto. Se o número do buffer no conjunto livre for maior que os limites somados, os buffers serão retornados ao conjunto global.

O dimensionamento de buffers de rede para acomodar uma típica solicitação pode melhorar a utilização de CPU eliminando a necessidade de dividir uma solicitação em diversas mensagens. Continue com cuidado, no entanto, pois o servidor de banco de dados aloca dinamicamente buffers de rede dos tamanhos indicados para todas as conexões ativas. Se um tamanho for configurado muito grande, uma grande quantia de memória poderá ser consumida.

O administrador de banco de dados pode controlar o tamanho de cada buffer usando um dos métodos a seguir, que são explicados em detalhes.

  • IFX_NETBUF_SIZE , que é a variável de ambiente, e a opção b (tamanho do buffer do cliente) no arquivo sqlhosts ou registro
  • IFX_NETBUF_PVTPOOL_SIZE

Variável de Ambiente IFX_NETBUF_SIZE

A variável de ambiente IFX_NETBUF_SIZE especifica o tamanho de cada buffer de rede no buffer pool de rede comum e o buffer pool de rede privada. O tamanho do buffer padrão é 4KB.

O modo IFX_NETBUF_SIZE para configurar um tamanho de buffer maior reduz a quantia de sobrecarga necessária para receber cada pacote. Se souber que os clientes enviam pacotes maiores que 4KB, configure IFX_NETBUF_SIZE como o tamanho do pacote médio. Os clientes podem enviar grandes pacotes durante qualquer uma das seguintes situações:

  • Carregamentos de tabela
  • Tamanho de linha maior que 4KB
  • Enviando objetos grandes e simples

O b opção para sqlhosts corresponde a IFX_NETBUF_SIZE . O valor para a opção sqlhosts deve corresponder tipicamente ao valor para IFX_NETBUF_SIZE.

Variável de Ambiente IFX_NETBUF_PVTPOOL_SIZE

O servidor de banco de dados fornece um buffer pool de rede privada para cada sessão que usa conexões de rede SOTCP, IPCSTR ou TLITCP. Os buffers nesses conjuntos são alocados dos conjuntos mencionados anteriormente: o conjunto global e o conjunto livre.

Em um ambiente no qual muitas conexões e sessões estão constantemente ativas, esses buffers de rede privada fornecem as seguintes vantagens:

  • Menos contenção para o buffer pool de rede comum
  • Os recursos de CPU podem ser convertidos, pois não é necessário alocar e desalocar buffers de rede do e para o buffer pool de rede comum para cada transferência de rede. Esses buffers estarão estaticamente disponíveis.

O tamanho do conjunto de rede privada para cada sessão é especificado pelo IFX_NETBUF_PVTPOOL_SIZE . O tamanho padrão é de 1 buffer.

Comandos Onstat para monitorar e Sintonizar o Uso de Buffer da Rede

Use as opções onstat em Tablela 4 para monitorar o uso de buffer de rede.

Tablela 4. Monitorando Buffers de Rede com onstat
OpçãoCampo de saídaDescrição do campo
onstat -g ntuq-pvtNúmero atual e número mais alto de buffers que são livres no conjunto privado para esta sessão
onstat -g ntmq-exceedsNúmero de vezes que o limite do buffer livre foi excedido

A opção onstat -g ntu exibe o formato para o campo de saída q-pvt, como mostrado em Lista 10.

Lista 10. Campo de Saída q-pvt
número atual/número mais alto

Se o número de buffers livres (valor no campo q-pvt) for consistentemente 0, é possível executar uma das ações a seguir:

  • Use a variável de ambiente IFX_NETBUF_SIZE para aumentar o tamanho de cada buffer
  • Use a variável de ambiente IFX_NETBUF_PVTPOOL_SIZE para aumentar o número de buffers

O campo q-exceeds indica o número de vezes que o limite para o buffer pool livre de rede compartilhada foi excedido. Quando este limite é excedido, o servidor de banco de dados retorna aos buffers de rede não utilizados (acima deste limite) para o conjunto de memórias global. O ideal é que este valor sempre seja 0 ou um número menor. Este é um indicador de que o servidor não está alocando ou desalocando buffers de rede.

É possível usar o comando onstat em Lista 11 para ver o tamanho do buffer de rede.

Lista 11. Comando Onstat para Tamanho de Buffer de Rede
onstat  -g  afr  global  |  grep  net

O campo de tamanho na saída mostra o tamanho de buffer de rede em bytes.


Atualizando Estatísticas

O servidor Informix usa um otimizador baseado em custo. Quando o otimizador determina o plano de consulta, ele designa um custo a cada plano possível e depois escolhe o plano com o menor custo. Alguns dos fatores que o otimizador usa para determinar o custo de cada plano de consulta incluem o seguinte:

  • O número de solicitações de E/S associadas a cada acesso de sistema de arquivos
  • O trabalho da CPU necessário para determinar quais linhas atendem o predicado de consulta
  • Os recursos que são necessários para classificar ou agrupar os dados
  • A quantia de memória (especificada pelos parâmetros DS_TOTAL_MEMORY e DS_MAX_QUERIES ) disponíveis para a consulta

Para calcular o custo de cada possível plano de consulta, o otimizador faz o seguinte:

  • Usa um conjunto de estatísticas que descreve a natureza e as características físicas dos dados de tabela e índices
  • Examina os filtros de consulta
  • Examina os índices que poderiam ser usados no plano
  • Analisa o custo de mover dados para executar uniões local ou remotamente para consultas distribuídas

A instrução UPDATE STATISTICS atualiza estatísticas nos catálogos do sistema. O otimizador usa essas estatísticas para determinar o plano de consulta de menor custo. Vários tipos de dados estatísticos são coletados e em várias resoluções, dependendo da precisão das estatísticas necessárias e das restrições de tempo para coleta dos dados.

Para garantir que o otimizador selecione um plano de consulta que melhor reflete o estado atual de suas tabelas, execute UPDATE STATISTICS em intervalos regulares quando as estatísticas não são geradas automaticamente para tabelas que são dinâmicas (em outras palavras, os dados estão sendo alterados).

Tablela 5 resume quando executar diferentes instruções UPDATE STATISTICS. Se tiver muitas tabelas, é possível gravar um script para gerar essas instruções UPDATE STATISTICS.

Tablela 5. Diretrizes para Execução de UPDATE STATISTICS
Instrução de estatísticasDestinoUse
UPDATE STATISTICS LOW DROP DISTRIBUTIONSÍndices, eliminar distribuições
  • Número de linhas alterado significativamente
  • Após a migração da versão anterior do servidor de banco de dados
UPDATE STATISTICS LOWÍndices
  • Para todas as colunas que não são a coluna líder de qualquer índice
  • (Todas as colunas no índice de várias colunas) Para consultas que possuem um índice de várias colunas definidas em colunas de junção ou coluna de filtro
UPDATE STATISTICS MEDIUM DISTRIBUTIONS ONLYDistribuições de dados
  • Consultas que têm colunas de junção não indexadas ou colunas de filtro
UPDATE STATISTICS HIGHDistribuições de dados e índices
  • Tabela ou coluna líder em um índice para consultas que indexaram colunas de junção ou colunas de filtro
  • (Primeiro coluna diferente no índice de várias colunas) Para consultas que têm um índice de várias colunas definido nas colunas de junção ou colunas de filtro
  • Consultas que têm muitas tabelas pequenas (adequadas em uma extensão)

Manutenção Melhorada de Estatísticas

Em versões anteriores, estatísticas de atualização eram executadas manualmente com instruções SQL. A instrução executada foi concluída em sua totalidade. Agora o Informix tem mecanismos integrados para evitar que o servidor faça cálculos de distribuição desnecessários quando os dados não foram alterados significativamente. Além disso, algumas instruções de estatísticas de atualização agora são executadas com instruções DDL. Estatísticas de atualização também podem ser totalmente automatizadas, ativando por trás dos cenários usando o planejador.

Os administradores normalmente executam estatísticas de atualização de acordo com as diretrizes em um intervalo definido. As distribuições de dados geralmente são recalculadas quando os dados não foram alterados de forma adequada. Agora é possível configurar o servidor para calcular distribuições durante uma instrução UPDATE STATISTICS padrão somente após uma mudança de limite nos dados de tabela. Também é possível ter distribuições recalculadas em uma base de fragmento para que apenas o subconjunto dos fragmentos de tabela que atenderam aos critérios de mudança de limite teriam distribuições atualizadas.

O parâmetro de configuração STATCHANGE configura a porcentagem das estatísticas antigas que acionam o recálculo da distribuição. O parâmetro de configuração AUTO_STAT_MODE ativa o uso em todo o servidor de STATCHANGE para controlar as estatísticas de atualização. A configuração na Lista 12 ativa STATCHANGE e configura o nível para 12 por cento.

Lista 12. Configuração STATCHANGE
AUTO_STAT_MODE  1
STATCHANGE  12

Quando o modo automático está ativado, as instruções UPDATE STATISTICS usam o valor STATCHANGE para identificar tabela, índice ou distribuições de fragmento cujas estatísticas estão ausentes ou antigas e atualizam apenas essas. AUTO_STAT_MODE pode ser alterado dinamicamente com o comando onmode.

É possível usar a instrução sql SET ENVIRONMENT para configurar AUTO_STAT_MODE e STATCHANGE no nível da sessão. As configurações da sessão substituem o valor de configuração. Para uma granularidade ainda mais fina, configure STATCHANGE nas instruções CREATE TABLE ou ALTER TABLE na cláusula de opção das novas estatísticas. Elas substituem todas as outras configurações.

Estatísticas de atualização seletivas em fragmentos de tabela são realizadas com outra opção nas instruções CREATE TABLE e ALTER TABLE. As tabelas STATLEVEL , o atributo, é acompanhado por qualquer uma das seguintes opções:

AUTO
Ative estatísticas de nível de fragmento e determinação automática se um fragmento dever ter suas estatísticas atualizadas. Este modo está disponível para fragmentação pela expressão, lista ou intervalo. Uma tabela teria de ter mais de um milhão de linhas. AUTO é o padrão.
FRAGMENT
Ativa estatísticas de nível de fragmento
TABLE:
Designa que as estatísticas serão coletadas em uma base de tabela

A instrução UPDATE STATISTICS em si possui uma opção AUTO ou FORCE. A opção AUTO força as estatísticas de atualização a usarem o valor STATCHANGE de controle para decidir quais estatísticas atualizar. A opção FORCE diz às estatísticas de atualização que usem o modo clássico de atualização de todas as estatísticas.

As estatísticas de atualização agora são executadas automaticamente com certas instruções DDL, incluindo o seguinte:

  • ALTER FRAGMENT ATTACH
  • ALTER FRAGMENT DETACH
  • ALTER TABLE ADD CONSTRAINT
  • ALTER TABLE MODIFY
  • CREATE INDEX

Com ou sem a palavra-chave ONLINE , CREATE INDEX gera as seguintes estatísticas automaticamente:

  • Estatísticas de nível de índice, equivalente às estatísticas reunidas na operação UPDATE STATISTICS em modo LOW, para todos os tipos de índices, incluindo b-tree, interface de índice virtual e índices funcionais
  • Estatísticas de distribuição de coluna, equivalente à distribuição gerada na operação UPDATE STATISTICS em modo MEDIUM, para uma coluna indexada líder não opaca de um índice B-tree ordinário

Especificando SAMPLING SIZE

Agora você tem a opção de controlar o tamanho de amostra usado para UPDATE STATISTICS LOW em índices b-tree de grandes tabelas. Ative a amostra com USTLOW_SAMPLE configurado no arquivo de configuração ou com a instrução ENVIRONMENT. O comando padrão de baixas estatísticas toca cada página folha do índice em sequência. Isto consome muito tempo. Os índices com 100.000 páginas folha ou mais terão amostras quando USTLOW_SAMPLE for configurado como 1. As economias em tempo podem ser substanciais, mas o otimizador de consulta terá menos dados com os quais trabalhar.

Assim como muitos desses parâmetros, é possível usar o comando onmode para alterar USTLOW_SAMPLE enquanto o mecanismo está on-line.

As palavras-chave SAMPLING SIZE são usadas com UPDATE STATISTICS MEDIUM para especificar o número mínimo de linhas para amostra ao calcular estatísticas de distribuição de coluna. O número de linhas de amostra será o maior de um dos dois valores a seguir:

  • O valor especificado
  • O número de linhas necessárias para preencher a porcentagem de linhas em cada bin e para também preencher o nível de confiança

A porcentagem padrão de linha em cada bin será de 2,5% e a confiança mínima será de 0,80. Por exemplo, a instrução em Lista 13 calcula estatísticas para três colunas da tabela do cliente. As informações sobre indexação não serão atualizadas. Pelo menos 300 linhas terão amostra, mas o tamanho real da amostra pode ser maior que 300. Entretanto, se mais linhas forem necessárias para fornecer o nível de confiança 0,80 padrão, mais linhas terão amostra para uma distribuição de amostra que usa 60 categorias de equivalência. A porcentagem média dos valores de amostra em cada bin será de 3%.

Lista 13. Uso de Amostra de SAMPLING SIZE
UPDATE STATISTICS MEDIUM FOR TABLE customer (address1, city, state)
SAMPLING  SIZE  300  RESOLUTION  3  DISTRIBUTIONS  ONLY;

O servidor Informix sempre registra no catálogo do sistema o tamanho de amostra real (como uma porcentagem do número total de linhas na tabela) quando UPDATE STATISTICS MEDIUM é executado.

Usando estatísticas de atualização completamente automatizadas (AUS)

As estatísticas de atualização são completamente automatizadas agora. O servidor coleta dados no uso de tabela, muito como se vê na saída onstat -g ppf (perfil da partição). O servidor usa esses dados para determinar se as distribuições de dados precisam de atualização. Comandos específicos de estatísticas de atualização são criados com base nesses dados e executados, de acordo com um planejamento predefinido.

As estatísticas de atualização automática são implementadas usando três tarefas no banco de dados sysadmin bem como procedimentos armazenados, acionadores e outras estruturas de banco de dados de suporte. A seguir, as tarefas definidas nas linhas da tabela ph_task:

mon_table_profile
Coleta os dados do perfil por partição ou fragmento e armazena os dados na tabela mon_table_profile.
Avaliação de estatísticas de atualização automática
Determina quais tabelas e estatísticas de dados da coluna precisam ser atualizadas e armazena as instruções de estatísticas de atualização resultantes na tabela aus_command.
Atualização de estatísticas de atualização automática
Executa comandos de estatísticas de atualização pendentes localizados na tabela aus_command

O usuário tem a opção de modificar os planejamentos de execução de tarefa padrão atualizando campos da linha da tarefa diretamente usando SQL ou executando a OpenAdmin Tool (OAT).

Ativando e desativando estatísticas de atualização automática

Talvez queira continuar com seu próprio planejamento de comandos de estatísticas de atualização em vez de contar com estatísticas de atualização automática. A seguir estão algumas formas de evitar que o servidor de banco de dados atualize estatísticas automaticamente.

Desative a avaliação de AUS e tarefas de atualização AUS
Este é o método recomendado para desativar estatísticas de atualização automática ou qualquer outra tarefa. É a forma mais específica de encerrar o AUS. Atualize o campo tk_enable da tabela ph_task para as tarefas, configurando o valor para f. É possível depois ativar as tarefas configurando os valores para t. Este campo serve como um comutador liga/desliga para o Planejador de Tarefas. Este método é específico à tarefa determinada.
As tarefas do planejador podem parar e iniciar os encadeamentos enquanto o mecanismo está on-line
Isto executa a tarefa de função (parada do planejador)
Evita a criação do banco de dados sysadmin
O banco de dados sysadmin é criado por padrão quando a instância é inicializada ou com upgrade de uma versão anterior do Informix. Para evitar que o banco de dados seja criado, crie (como usuário Informix) um arquivo chamado stop (o arquivo de parada) em $INFORMIXDIR/etc/sysadmin. O banco de dados sysadmin será criado posteriormente se remover o arquivo de parada e executar oninit para deixar o mecanismo on-line.

O IBM Informix recomenda evitar que o banco de dados sysadmin seja criado. As tarefas de banco de dados são usadas para uma variedade de propósitos além do AUS.

Evite a criação de encadeamentos que suportam funções sysadmin
Os encadeamentos dbScheduler e dbWorker gerenciam as tarefas do banco de dados sysadmin. É possível evitar que esses encadeamentos sejam formados criando um arquivo de parada e reciclando a instância.

Assim como evita a criação de banco de dados sysadmin, isto pode afetar adversamente outras tarefas essenciais.

Ajustando Estatísticas de Atualização Automática

A tabela ph_threshold do banco de dados sysadmin contém parâmetros para configurar as políticas de expiração de estatísticas de atualização (critérios para determinar quando as estatísticas precisam de atualização) e a prioridade de PDQ usada para as estatísticas de atualização automática. Entre as configurações estão AUS_CHANGE. Isto é análogo a STATCHANGE, que por si só não tem efeito no controle de estatísticas de atualização executadas por meio do planejador.


Usando Índices

Usando Instruções CREATE e DROP INDEX ONLINE

Os índices agora podem ser criados e eliminados em um método não exclusivo. Use as instruções CREATE INDEX ONLINE e DROP INDEX ONLINE para criar e eliminar índices em um ambiente on-line ou dinâmico. O banco de dados e suas tabelas associadas não serão bloqueados exclusivamente, o que significa que estarão disponíveis para atualizações ou leituras.

Não é necessário posicionar um bloqueio restrito na tabela durante a criação de índice se um índice for criado com a palavra-chave ONLINE. Leituras e atualizações podem ocorrer na tabela. A criação de um índice não terá de aguardar até que um bloqueio restrito possa ser posicionado na tabela.

Se um índice for criado com a palavra-chave ONLINE, o servidor de banco de dados faz log da operação com um sinalizador específico. As operações de restauração e recuperação agora verificarão aquele sinalizador e podem recriar o índice.

As vantagens de criar índices usando a instrução CREATE INDEX ONLINE são como a seguir:

  • Um índice pode ser imediatamente criado sem um bloqueio posicionado sobre a tabela
  • As atualizações podem ocorrer em uma tabela enquanto o índice está sendo criado
  • O otimizador pode atualizar estatísticas em tabelas desbloqueadas, permitindo mais planos de consulta ideais

Índices anexados podem ser criados usando CREATE INDEX ONLINE, mas ONLINE se aplica apenas quando a leitura suja é o nível de isolamento de transação. A criação do índice posiciona um bloqueio restrito na tabela e aguarda que todos os outros processos simultâneos que estão varrendo a tabela finalizem o uso de partições de índice antes que crie o índice anexado. Se a tabela estiver sendo lida ou atualizada, a instrução CREATE INDEX ONLINE aguarda o bloqueio restrito.

Se LOCK MODE não estiver configurado como WAIT, a criação do índice anexado falharia, pois não aguardará que outros usuários a finalizem. Observe que o mecanismo posiciona um bloqueio após a criação do índice por um curto tempo enquanto atualiza as informações do catálogo do sistema.

Lista 14 fornece um uso de exemplo de CREATE INDEX com a sintaxe ONLINE.

Lista 14. Amostra de CREATE INDEX com a Sintaxe ONLINE
CREATE  INDEX  i1  ON  tab1(c1)  ONLINE=3

ONLIDX_MAXMEM

O parâmetro de configuração ONLIDX_MAXMEM é usado para limitar a quantia de memória alocada a um conjunto de log de pré-imagem ou a um conjunto de log do atualizador. Esses conjuntos são criados na memória compartilhada quando um índice é criado com a palavra-chave ONLINE. Isto pode ser útil se planejar concluir outras operações em uma coluna da tabela enquanto um índice está sendo criado (usando a sintaxe ONLINE) nessa coluna.

O intervalo de valores de ONLIDX_MAXMEM é de 16KB a 4.294.967.295KB. O tamanho padrão no onconfig.std é 5120KB.

O parâmetro de configuração ONLIDX_MAXMEM pode ser modificado dinamicamente com o comando onmode -wf ou substituído pelo onmode -wm especificado.

DROP INDEX ONLINE

O parâmetro DROP INDEX ONLINE permite eliminar um índice sem a necessidade de um bloqueio restrito. Os índices podem ser eliminados (usando a palavra-chave ONLINE) mesmo quando a leitura suja é o nível de isolamento de transação.

As vantagens de eliminar índices usando a instrução DROP INDEX ONLINE estão a seguir:

  • Um índice ineficiente pode ser eliminado sem perturbar consultas em andamento, mesmo consultas que usem esse determinado índice
  • O otimizador de consulta será notificado para não usar o índice para novas operações SELECT em tabelas

A execução de uma instrução DROP INDEX ONLINE não ocorre até após uma atualização de tabela ser concluída. Após emitir a instrução DROP INDEX ONLINE , nenhuma nova operação pode fazer referência ao índice, mas operações simultâneas podem usar o índice até que as operações sejam concluídas. O servidor de banco de dados aguarda para eliminar o índice até que todos os usuários atuais tenham concluído o acesso ao índice.

Lista 15 contém um uso de exemplo de DROP INDEX com a sintaxe ONLINE.

Lista 15. Amostra de DROP INDEX com a sintaxe ONLINE
DROP  INDEX  i1  ONLINE

Índice Self-join

Um índice self-join é uma junção na qual uma tabela é unida a si mesma. Um índice self-join pode ajudar o desempenho nas circunstâncias a seguir:

  • Uma consulta que envolve a chave principal ou a mais importante coluna (geralmente a primeira) de um índice possui muitas duplicatas
  • O custo ou número de linhas para examinar com uma chave principal é julgada como mais alta que o custo de considerar linhas retornadas por colunas de chave não principal

A forma de conceitualizar como isso funciona é pensar na consulta que está sendo dividida em uma união de muitas subconsultas. Cada subconsulta é o conjunto de resultados da coluna de chave principal não restritiva. O otimizador pode então considerar essas colunas e usá-las para considerar colunas de chave não principal mais restritivas.

Criando um Índice Self-join

Para produzir uma autojunção, use aliases de modo que a mesma tabela seja listada duas vezes no from , como mostra a Lista 16.

Lista 16. Sintaxe de Amostra para Gerar uma Autojunção
SELECT  a1.customer_num
FROM  customer  a1,  customer  b1
WHERE  a1.customer_num  =  b1.customer_num  AND
...  Additional  logic  here

Observe o uso de dois aliases que fazem referência à mesma tabela.

Planos de Consulta de Autojunção e Saída sqexplain

Uma autojunção pode ser determinada em um plano de consulta muito simples com a saída de explicação configurada, como mostrado em Lista 17.

Lista 17. Exemplo de saída de explicação configurada mostrando uma autojunção
Index  Self  Join  Keys  (customer_num  lname  )
  Lower bound: informix.a.customer_num >= 00702 AND 
  (informix.a.lname >= 'Aaron ' )
  Upper bound: informix.a.customer_num <= 12345 AND
  (informix.a.lname <= 'Croyle' )

Observe que as chaves envolvidas nas colunas envolvidas no índice self-join serão mostradas.

Diretivas do Otimizador de Autojunção

A seguir, duas diretivas do otimizador podem ser usadas para direcionar o otimizador a usar a funcionalidade de autojunção:

  • A diretiva INDEX_SJ força um caminho de autoassociação de índice usando o índice especificado ou escolhendo o índice menos custoso em uma lista de índices, mesmo que as estatísticas de distribuição de dados não estejam disponíveis para as colunas de chave do índice líder.
  • A diretiva AVOID_INDEX_SJ evita um caminho de autojunção para um índice especificado ou para uma lista de índices.

Usando o parâmetro de indexação NO_SORT e a variável de ambiente NO_SORTINDEX

NO_SORT é uma nova seção para criação de índices que podem ajudar o desempenho em cenários especializados (como tabelas de cluster estático). Com NO_SORT, é possível usar uma função retornando uma chave espacial numérica para criar uma tabela em cluster estático de acordo com um índice funcional de árvore B. Quando um índice de árvore R é criado na tabela em cluster resultante, o método de acesso secundário da árvore R não precisa classificar os dados. Ele criará um índice de baixo para cima, pois a tabela já está classificada de acordo com os mesmos critérios que a criação de baixo para cima da árvore R usaria. O índice funcional de árvore B faz a classificação.

Para criar um índice de árvore R usando o parâmetro de indexação NO_SORT, conclua as etapas a seguir.

  1. Verifique a documentação do módulo DataBlade para uma função que, dado um objeto do tipo de dados que está sendo indexado, retorna uma chave espacial.
  2. Crie um índice de árvore B funcional em cluster na tabela usando esta função, como mostrado em Lista 18.
    Lista 18. Crie um índice de árvore B funcional em cluster na tabela usando a função DataBlade
    CREATE CLUSTER INDEX btree_functional_index ON table1 (SpatialKey(col1));

    btree_functional_index é o nome do índice de árvore B funcional em cluster. table1 é o nome da tabela. SpatialKey é a função. col1 é o nome da coluna que contém os dados espaciais.

  3. Crie um índice de árvore R na coluna em chave espacial usando a sintaxe NO_SORT="YES", como mostra a Lista 19.
    Lista 19. Crie um índice de árvore R na coluna em chave espacial usando a sintaxe NO_SORT="YES"
    CREATE  INDEX rtree_index  ON  table1  (col1 op1)
    USING  RTREE  (NO_SORT  =  'YES');

    rtree_index é o nome do índice de árvore R.op1 é o nome da classe operadora associada ao tipo de dados da coluna col1.

  4. Elimine o índice de árvore B agora exterior, como mostrado em Lista 20.
    Lista 20. Elimine o índice de árvore B agora exterior
    DROP  INDEX  btree_functional_index;

A variável de ambiente NOSORTINDEX

Se a variável de ambiente NOSORTINDEX estiver configurada no ambiente, o comportamento padrão da criação de um índice de árvore R será equivalente à configuração NO_SORT="YES".

Índice Forest of trees (FOT)

Desempenho melhorado em procuras de índice é possível usando o novo esquema de indexação da floresta de árvores (FOT), que foi introduzido no Informix 11.70. Um único índice de árvore B grande é substituído por um número de índices de árvore B menores. O índice FOT é criado ao fazer hashing de uma ou mais colunas no índice. Consultas fazem hash no valor e são direcionadas ao índice correto no índice FOT. Os níveis superiores de um índice são as páginas mais frequentemente acessadas. O índice FOT reduz a contenção ao reduzir acesso frequente das páginas principais do índice.

Para criar um índice FOT, inclua a cláusula HASH ON na instrução CREATE INDEX, como mostrado nos exemplos em Lista 21.

Lista 21. Exemplos de criação de um índice FOT
 CREATE INDEX idx1 ON tab1(c1) HASH ON (c1) WITH 100 BUCKETS;
CREATE INDEX idx2 ON tab2(c1, c2, c3) HASH ON (c1, c2) WITH 10 BUCKETS;

Ajustando Limpeza de Índice

O parâmetro de configuração BTSCANNER foi introduzido no Informix 10.00. A nova função foi recentemente incluída na forma de uma limpeza de índice linear adaptativo (modo alice, Informix 11.10) e compactação de árvore B (Informix Dynamic Server 11.50).

A varredura ativada com o modo alice (bancos de dados logados somente) mantém um bitmap para cada partição de índice que mostra as chaves de índice marcadas para limpeza. A varredura para limpar itens marcados para exclusão exclui partes do índice em que nenhuma exclusão deve ser feita. Usar o modo alice fornece uma melhoria de desempenho marcada sobre o método mais antigo de varredura de intervalo. O modo alice não é usado para tabelas com diversos índices anexos, em que uma varredura de folha deve ser usada.

A compactação de árvore B é projetada para manter um tamanho de índice de árvore B a um nível que favorece procuras eficientes. A configuração de compactação configura limites para mesclar parcialmente páginas de índice preenchidas.

Lista 22 mostra os valores onconfig.std para BTSCANNER.

Lista 22. Exemplos de BTSCANNER
BTSCANNER num=1, threshold=5000, rangesize=-1, alice=6, compression=default

O servidor inicia encadeamentos num e põe o índice em uma lista de favoritos para limpar quando atingir o número limite de itens a excluir. O rangesize é o tamanho em KB que um fragmento de índice deve exceder antes de o índice ser limpo com varredura de interval. É recomendado que este valor seja configurado como -1 (desligado) para o Informix 11.10 e superior para que o modo alice seja usado onde apropriado. O parâmetro alice configura o tamanho de bitmap inicial. Configure-o como 6 ou 7 para sistemas de tamanho pequeno ou médio e configure com valores maiores para sistemas que se espera que sejam grandes. A compressão é configurada para padrão (médio), baixo, médio ou alto, dependendo do comportamento do processo que se espera no sistema.

Sua configuração desejada para compactação pode ser alterada conforme um índice cresce ou é reduzido. A API administrativa (banco de dados sysadmin) possui uma função integrada para alterar a configuração, como mostrado em Lista 23.

Lista 23. Alterando a Configuração de Compactação
EXECUTE FUNCTION task("set index compression","1048611","high");

A compactação para índice com número de peça 1048611 é configurada como alto neste exemplo.


Melhorando o Desempenho com Consulta Paralela ao Banco de Dados e Memory Grant Manager

Entendendo a PDQ

A consulta paralela ao banco de dados (PDQ) pode melhorar o desempenho drasticamente. Ela permite que o servidor de banco de dados distribua o trabalho para uma consulta. Por exemplo, se um índice precisar ser criado em uma tabela grande, o trabalho pode ser distribuído entre diversos encadeamentos e processos.

Alocando e Limitando Recursos de PDQ

A PDQ inclui a funcionalidade para gerenciamento de recursos. Quando o servidor de banco de dados usa PDQ para executar uma consulta em paralelo, uma carga pesada pode ser posicionada no sistema operacional. Os seguintes recursos podem ser sintonizados:

  • Memória
  • VPs de CPU
  • E/S de disco (a tabelas fragmentadas e espaço de tabela temporário)
  • Encadeamentos de varredura

Ao configurar o servidor de banco de dados, você deve considerar como o uso de PDQ afeta outros usuários. Por exemplo, se uma consulta que está executando está tomando todos os recursos da CPU, o servidor de banco de dados pode não ser tão responsivo a outra consulta que geralmente é executada muito rapidamente. Deve-se tomar cuidado para que consultas essenciais não PDQ ainda possam executar com desempenho aceitável.

É possível usar os seguintes métodos para controlar como o servidor de banco de dados usa os recursos:

  • Limite a prioridade das consultas paralelas ao banco de dados
  • Ajuste a quantia de memória do Memory Grant Manager
  • Limite o número de encadeamentos de varredura
  • Limite o número de consultas simultâneas

PDQPRIORITY

A variável de ambiente PDQPRIORITY determina o grau de recursos de paralelismo. A variável é usada em conjunto com MAX_PDQPRIOIRTY como um fator de escala em como o servidor de banco de dados aloca recursos, como mostrado em Lista 24.

Lista 24. Configurando a Variável de Ambiente PDQPRIORITY
setenv--PDQPRIORITY--+-HIGH--------------------------------+
                     +-LOW---------------------------------+
                     +-OFF---------------------------------+
                     '-resources--+------------------------+
                                  |     (1)                |
                                  '-------------high_value-'

Tablela 6 mostra as configurações PDQPRIORITY.

Tablela 6. Configurações PDQPRIORITY
ConfiguraçãoDescrição
AltoQuando o servidor de banco de dados aloca recursos entre todos os usuários, ele dá tantos recursos quanto possível à consulta.
Baixo ou 1Os valores dos dados são buscados de tabelas fragmentadas em paralelo.
OFFO processamento de PDQ é desligado.
recursosUm número inteiro entre 0 e 100; configura a porcentagem dos recursos de PDQ solicitados pelo usuário realmente alocados à consulta.
Valor alto opcionalO valor de número inteiro opcional que solicita a porcentagem máxima da memória. Quando você especifica este valor após o valor dos recursos, solicita também um intervalo de memória expresso como uma porcentagem.

Quanto mais recursos um servidor de banco de dados dedica a uma consulta, normalmente, mais rápido o servidor pode concluir a consulta. A contenção para esses recursos pode resultar, no entanto, se outras consultas estiverem tentando acessar esses mesmos recursos. Isto pode resultar em desempenho degradado.

A instrução SQL SET PDQPRIORITY pode ser usada para ajustar a prioridade manualmente para uma determinada sessão.

Limitando a Prioridade Usando MAX_PDQPRIORITY

MAX_PDQPRIORITY é o parâmetro ONCONFIG que limita os recursos de PDQ que o servidor de banco de dados pode alocar a qualquer consulta DSS. MAX_PDQPRIORITY é usado como uma porcentagem com relação a PDQPRIORITY para a qual qualquer cliente em particular solicita. Por exemplo, suponha que um usuário esteja com pressa para obter seus dados e configure sua PDQPRIORITY como 100. Entretanto, o DBA percebe que certas funções em lote devem ser executadas ao mesmo tempo, toda a noite, e ele configura MAX_PDQPRIORITY como 50. Cinquenta por cento de 100 é 50, então a porcentagem máxima dos recursos PDQPRIORITY que o usuário realmente pode obter é 50.

É possível usar onmode -D para alterar o valor de MAX_PDQPRIORITY enquanto o servidor de banco de dados está on-line.

Em um sistema com consultas OLTP e DSS, um ato de balanceamento deve ser mantido. Se configurar uma MAX_PDQPRIORITY muito alta, as consultas OLTP sofrerão. Se configurar o valor muito baixo, as consultas DSS não serão executadas idealmente. Um DBA deve, portanto, tomar cuidado ao ajustar esta variável.

É possível configurar MAX_PDQPRIORITY como um dos valores descritos em Tablela 7.

Tablela 7. Configurações MAX_PDQPRIORITY
ConfiguraçãoDescrição
0Desliga a PDQ. As consultas DSS não usam paralelismo.
1Busca dados de tabelas fragmentadas em paralelo (varreduras paralelas), mas não usa outra forma de paralelismo.
100Usa todos os recursos disponíveis para processamento de consultas em paralelo.
Qualquer númeroUm número inteiro entre 0 e 100; configura a porcentagem dos recursos de PDQ solicitados pelo usuário realmente alocados à consulta.

Ajustando Recursos de Memória com o Memory Grant Manager

O parâmetro ONCONFIG DS_TOTAL_MEMORY especifica a quantia de memória disponível para consultas de PDQ. A quantia é especificada em KB e é alocada da parte virtual da memória compartilhada da instância do Informix. DS_TOTAL_MEMORY deve ser configurado como grande o bastante para permitir que um chunk dimensionável de trabalho seja carregado na memória de uma só vez. A seguir, instruções para levar em conta quando configurar DS_TOTAL_MEMORY:

  • A memória total no computador (não a exceda)
  • Sobrecarga, como o buffer pool
  • Outros processos no computador. Os benefícios reduzidos de desempenho e a real degradação do desempenho podem resultar se a paginação ou troca resultar de uma configuração muito alta.

SHMTOTAL especifica toda a memória para o servidor de banco de dados (total do residente, virtual e partes de mensagem da memória). SHMVIRTSIZE especifica o tamanho inicial da parte virtual da memória compartilhada.

Alocar memória virtual adicional para consultas PDQ pode acionar a adição dinâmica de um ou mais segmentos de memória compartilhada virtual. Alguns sistemas operacionais passam por sobrecarga de desempenho para cada segmento adicional incluído na memória compartilhada. Evite esta ocorrência de desempenho ajustando SHMVIRTSIZE e SHMTOTAL apropriadamente como a seguir para que o número mínimo de segmentos seja alocado:

  • Para aplicativos OLTP, uma recomendação básica é configurar DS_TOTAL_MEMORY para entre 20 e 50 por cento do valor de SHMTOTAL em kilobytes.
  • Se o servidor de banco de dados for usado para consultas DSS exclusivamente, configure DS_TOTAL_MEMORY para entre 90 e 100 por cento do SHMTOTAL.
  • Para sistemas que usam ambos os tipos de consultas, uma recomendação básica é configurar set DS_TOTAL_MEMORY para entre 50 e 80 por cento do SHMTOTAL.

É possível configurar DS_TOTAL_MEMORY dinamicamente com o onmode -M especificado.

Observe que o valor permitido para DS_TOTAL_MEMORY é dependente da plataforma. O valor para sistemas de 32 bits deve ser um número inteiro não assinado entre 128 * DS_MAX_QUERIES e 1.048.576. Em sistemas de 64 bits, o limite é geralmente mais alto e varia com o sistema operacional. Em plataformas HP 9000, por exemplo, o valor máximo é 4.294.967.296.

Limite o número de encadeamentos de varredura

O parâmetro ONCONFIG deDS_MAX_SCANS limita o número de encadeamentos de varredura de PDQ que podem ser executados simultaneamente. Se este parâmetro for configurado muito alto, o servidor de banco de dados terá muitos encadeamentos de varreduras de diversas consultas de suporte à decisão em execução simultaneamente. Isto causará contenção de recursos. A fila consultas prontas em onstat -g mgm cresce.

A fórmula em Lista 25 pode ser usada para calcular o número de varreduras alocadas a uma consulta.

Lista 25. Calculando o número de encadeamentos de varreduras alocados a uma consulta
scan_threads = min (-nfrags-, (DS_MAX_SCANS * -pdqpriority- 
/ 100 * MAX_PDQPRIORITY / 100) )

-nfrags- é o número de fragmentos na tabela com o maior número de fragmentos. -pdqpriority- é a configuração para essa determinada consulta.

É possível configurar o número máximo de encadeamentos de varredura dinamicamente com o onmode -S da coluna. Este valor deve ser um número inteiro não assinado entre 10 e 1.048.576.

Suponha que uma tabela grande contenha 50 fragmentos. Se DS_MAX_SCANS não for configurado, não haverá limite no número de varreduras simultâneas permitidas. Cinquenta varreduras serão alocadas pelo servidor de banco de dados. O mecanismo tentaria executar todos os 50 encadeamentos de varredura para ler esta tabela. Se este relatório pode ser executado por qualquer usuário, o que acontece se 50 pessoas tentarem executar esse relatório simultaneamente? Sem ser verificado, o mecanismo alocaria 50 encadeamentos para cada um em execução desse relatório. Dois mil e quinhentos encadeamentos teriam spawn realizado. Inclua sobrecarga para outros relatórios e outras consultas DSS e haverá um potencial para maiores problemas de contenção. O uso ponderado de DS_MAX_SCANS evita este problema.

A natureza de balanceamento do ajuste do desempenho do banco de dados é ilustrada neste aspecto do ajuste de PDQ. Para reduzir o tempo que os encadeamentos de varreduras para uma grande consulta estarão na fila consultas prontas, reduza o número de encadeamentos de varreduras alocados. Entretanto, se o número de encadeamento de varreduras para uma consulta for menor que o número de fragmentos, a consulta demora mais uma vez que está em andamento.

Limitando o número de consultas de PDQ simultâneas

DS_MAX_QUERIES é o parâmetro ONCONFIG que especifica o número máximo de consultas PDQ que podem ser executadas simultaneamente. O Memory Grant Manager (MGM) reserva memória para uma consulta baseado na fórmula em Lista 26. A fórmula também é como o servidor de banco de dados decide quanto de memória alocar para uma consulta.

Lista 26. Reservando memória para uma consulta
memory_reserved = DS_TOTAL_MEMORY * (PDQ-priority/100) * (MAX_PDQPRIORITY/100)

O comando onmode -Q pode ser usado para configurar DS_MAX_QUERIES dinamicamente.

Usando o Memory Grant Manager

A opção onstat -g mgm imprime as informações de recurso do Memory Grant Manager (MGM). É possível usar a opção onstat -g mgm para monitorar como o MGM coordena uso de memória e encadeamentos de varreduras. Lista 27 mostra saída de amostra.

Lista 27. Saída de amostra onstat -g mgm
IBM Informix Dynamic Server Version 11.50.FC9 -- On-Line -- Up 00:00:24 -- 250944 Kbytes

Memory Grant Manager (MGM)
--------------------------

MAX_PDQPRIORITY:  100
DS_MAX_QUERIES:    4
DS_MAX_SCANS:      1048576
DS_NONPDQ_QUERY_MEM: 128 KB
DS_TOTAL_MEMORY:   512 KB

Queries:   Active     Ready   Maximum
                0         0         4

Memory:     Total      Free   Quantum
(KB)          512       512       128

Scans:      Total      Free   Quantum
           1048576   1048576         1

Load Control:    (Memory)      (Scans)  (Priority)  (Max Queries)   (Reinit)
                   Gate 1       Gate 2      Gate 3         Gate 4     Gate 5
(Queue Length)          0            0           0              0          0

Active Queries:  None

Ready Queries:  None

Free Resource        Average #        Minimum #
--------------    ---------------     ---------
Memory              47.8 +- 2.7            32
Scans             1048575.3 +- 0.0          1048574

Queries              Average #        Maximum #    Total #
--------------    ---------------     ---------    -------
Active               1.0 +- 0.1             2       3371
Ready                0.0 +- 0.0             0          0

Resource/Lock Cycle Prevention count: 0

O MGM usa uma série de portas, como mostrado em Tablela 8, para se certificar de que uma consulta PDQ tem recursos suficientes para executar corretamente.

Tablela 8. Descrições de Porta
Número de portaDescrição
1Há memória suficiente disponível?
2Você excedeu DS_MAX_SCANS?
3Esta porta é uma fila para todas as consultas com a mesma prioridade.
4Você excedeu DS_MAX_QUERIES?
5Verifique se não está alterando dinamicamente os recursos antes de permitir que a consulta seja executada.

O Quantum

As consultas PDQ memória alocada em unidades chamadas de quanta. O número de quanta disponível a uma consulta é determinado pela porcentagem de recursos PDQ disponíveis para essa consulta. A saída onstat -g mgm exibe o tamanho de um quantum. O tamanho de um quantum é calculado como mostrado em Lista 28.

Lista 28. Calculando o Quantum
memory quantum = DS_TOTAL_MEMORY/DS_MAX_QUERIES

Como um exemplo, voltar à mesma saída de amostra de Lista 27, Lista 29 mostra como conectar nos números.

Lista 29. Exemplo de Cálculo de Quantum
memory quantum = 512/4

A execução de amostra gera um quantum de 128.000 bytes.

Como a matemática mostra, quanto mais consultas você permite, menor o quantum será.


Maximizando Pontos de Verificação

O Informix Dynamic Server faz todo esse trabalho na memória compartilhada. O servidor mantém as páginas na memória compartilhada contanto que possa evitar E/S desnecessária. Por exemplo, as linhas inseridas em uma página de dados em transações separadas podem ser feitas sem ler a página do disco, modificando e gravando de volta ao disco para cada transação. Em algum ponto, no entanto, o servidor de banco de dados deve gravar essa página de volta no disco. Pode ser necessário espaço para outras páginas.

Reter páginas modificadas na memória cria considerações de recuperação. Se o servidor de banco de dados ficar off-line inesperadamente, pode deixar páginas modificadas na memória e não gravadas no disco. Durante os processos de recuperação, o servidor precisa trazer os dados a um ponto de consistência antes que possa começar um novo processamento. Este é o processo de recuperação rápida, que é alcançado em duas etapas:

Recuperação física
A recuperação física está retornando todas as pré-imagens de páginas de volta ao disco. Uma pré-imagem é a imagem de uma página antes de ser modificada.
Recuperação lógica
A recuperação lógica é a ação de executar rollforward de todas as transações do último ponto de verificação. Todas as transações que foram confirmadas serão reproduzidas completamente. Mas qualquer transação que não foi confirmada será retrocedida.

Ponto de Verificação

Um ponto de verificação cria um ponto de sincronização entre o disco e a memória compartilhada. Após a sincronização, o servidor de banco de dados tem um ponto de consistência conhecido. Durante um ponto de verificação, todos os buffers no buffer pool mais os buffers de log lógicos são alinhados no disco para que fiquem armazenados em estado estável.

Quando um ponto de verificação ocorre, um registro de ponto de verificação é registrado no log lógico. Ele também é registrado nas páginas reservadas. Durante a recuperação, o registro de ponto de verificação de páginas reservadas é usado para encontrar o último ponto de consistência de dados e é o ponto de partida para recuperação rápida.

Entendendo Pontos de Verificação em Versões Anteriores

Antes do V11, as seguintes situações acionariam um ponto de verificação:

  • Eventos administrativos, como o mecanismo sendo encerrado, um chunk ou dbspaces sendo incluídos
  • O log físico 75% cheio
  • Um ponto de verificação que já está no espaço de log lógico: se o log lógico mais antigo (o próximo a ser gravado) contiver o último ponto de verificação, o Informix terá de gravar um novo ponto de verificação para que o log possa estar disponível para reutilização
  • ONCONFIG .CKPTINTVL

Todos os quatro acionadores permanecem no V11, mas o intervalo entre pontos de verificação pode ser modificado por novos recursos.

O Informix precisa de um ponto de verificação para recuperação, pois é um ponto conhecido de consistência. Os pontos de verificação são indiretamente afetados por parâmetros de configuração LOGSIZE e LOGFILES . Quando um arquivo de log lógico é examinado para ver se pode ser liberado (e gravado), é verificado se possui o último ponto de verificação. Antes que possa ser liberado, o servidor de banco de dados deve gravar um novo registro de ponto de verificação no arquivo atual de log lógico. A frequência deste acontecimento poderia causar o aumento da frequência dos pontos de verificação. Isto não é normalmente um fator significativo no V11.

Se o log físico for muito grande, um intervalo do ponto de verificação pode levar a um aumento no tempo necessário na recuperação rápida. Isto pode ser vital em caso de uma paralisação do mecanismo em uma situação em que a disponibilidade do banco de dados é importante. Nessa situação, usar uma combinação de CKPTINTVL e um log físico de tamanho moderado é recomendado.

Se CKPTINTVL expirar e não tiverem ocorrido atualizações (nada logado fisicamente e nenhum evento novo), um ponto de verificação não ocorrerá. Quando há poucas atualizações de página ou mudanças no sistema, é comum ter um CKPTINTVL mais longo.

Dependendo dos parâmetros como o tamanho do buffer de log físico, o tamanho do buffer pool e quantos buffers sujos existem, um ponto de verificação pode levar algum tempo para finalizar. Antes do V11, os pontos de verificação bloqueavam frequentemente qualquer encadeamento para não obter uma seção crítica de código, que é o código que deve ser feito todo em uma unidade, como gravar uma página. Algumas vezes, isso tinha o efeito de fazer os aplicativos de usuário aguardarem nos pontos de verificação. Os administradores de banco de dados geralmente gastavam uma grande parte do tempo ajustando parâmetros do banco de dados para minimizar o bloqueio. Isto se tornou um esforço em manter o número de buffers sujos baixo para minimizar o número limpo durante um ponto de verificação. A configuração usada para ajustar pontos de verificação era como a seguir:

  • LRU_MIN_DIRTY e LRU_MAX_DIRTY era usado para ajustar o número de buffers sujos no buffer pool.
  • CHKPTINTVL configura o intervalo entre pontos de verificação.

Entretanto, minimizar o número de páginas sujas no buffer pool também significava reduzir os efeitos benéficos do armazenamento em cache.

Introduzido no Informix V9, os pontos de verificação difusos tinham o objetivo de reduzir gravações de disco durante um ponto de verificação. Eles foram descontinuados e substituídos por novos parâmetros de configuração no Informix V11.

Aprendendo sobre novos parâmetros de configuração que afetam pontos de verificação

Três novos parâmetros de configuração que afetam os pontos de verificação foram introduzidos no Informix V11. Este tutorial descreve em mais detalhes em uma seção posterior que está focada em ajuste automático.

Para o ajuste de ponto de verificação, você tem a opção de reter os pontos de verificação oferecidos em versões anteriores ou usar os novos recursos. Os novos parâmetros de recursos são como a seguir:

  • AUTO_CKPTS modifica a frequência do ponto de verificação para evitar bloqueio devido a falta de recursos.
  • AUTO_LRU_TUNING aumenta LRU_MIN_DIRTY e LRU_MAX_DIRTY para evitar gravações de primeiro plano.
  • RTO_SERVER_RESTART configura o intervalo do ponto de verificação para alcançar um tempo de recuperação rápida configurado. CHKPTINTVL é ignorado quando RTO_SERVER_RESTART está ativado.

Usando Pontos de Verificação de Não Bloqueio

O algoritmo de ponto de verificação foi remarcado para o Informix V11. O novo algoritmo é quase de não bloqueio. O servidor de banco de dados V11 permite que encadeamentos que teriam sido bloqueados em mecanismos anteriores funcionem durante um ponto de verificação.

Ajuste de LRU para Pontos de Verificação de Não Bloqueio

Antes do V11, os administradores de banco de dados comumente ajustavam a limpeza de LRU agressivamente para que os LRUs fossem constantemente drenados. Como consequência, os pontos de verificação terminavam mais rapidamente, pois havia menos trabalho a se fazer. Consequentemente, o tempo total que outros encadeamentos tinham de esperar até o ponto de verificação terminar era minimizado.

Não é mais necessário sintonizar a limpeza de LRU tão agressivamente. Como as transações não são bloqueadas durante os pontos de verificação, é possível manter normalmente valores LRU_MIN_DIRTY e LRU_MAX_DIRTY que são muito mais altos que eram praticamente nos mecanismos antes do V11. O número de buffers sujos processados durante um ponto de verificação é muito mais alto e os pontos de verificação geralmente são muito mais longos. Entretanto, ele possui a vantagem de ganhos de desempenho devido a menos limpeza de LRU e mais armazenamento em cache de páginas sujas.

Locais em que um ponto de verificação fará um processamento de bloco temporariamente

Certos aspectos do processamento de ponto de verificação não mudaram com o advento dos pontos de verificação de não bloqueio. Durante o processamento de ponto de verificação, as transações continuam a gravar diante de imagens no log físico e nos registros de transação nos logs lógicos. O mecanismo deve gravar pelo menos um ponto de verificação no período dos log lógicos. As seguintes circunstâncias acionam pontos de verificação que podem se tornar bloqueados se os recursos do log se tornarem muito baixos durante o ponto de verificação:

  • Log físico 75% cheio
  • O ponto de verificação é necessário pois os logs lógicos estão quase expandidos

Configurando o Mecanismo para Pontos de Verificação de Não Bloqueio

A fim de evitar situações em que os pontos de verificação bloqueiam processamento de transações, conclua as seguintes etapas:

  • Ative o recurso de ponto de verificação automático. Os pontos de verificação ocorrerão com mais frequência. Isto evitará que o bloqueio ocorra devido à falta de recursos.
  • Aumente o tamanho do log físico ou lógico. O servidor posicionará uma mensagem no log on-line para sugerir que recurso aumentar e que tamanho o recurso deverá ser.

Considerações Adicionais para Gerenciar Pontos de Verificação

ONDBSPACEDOWN é um parâmetro de configuração que dita como o servidor manipulará um dbspace regular não espelhado que está ficando inativo devido a um erro de E/S. Dependendo da configuração, o mecanismo poderia ser interrompido durante um ponto de verificação. Os dbspaces temporários não são afetados por ONDBSPACEDOWN.

Uma mensagem é lida no log on-line quando um ponto de verificação é concluído. Esta mensagem também especifica quanto tempo um ponto de verificação levou para ser concluído. Antes do V11, isto também era uma especificação ad hoc sobre quanto tempo os usuários foram bloqueados de seções críticas. Os DBAs poderiam usar estas informações para ajudar a sintonizar seus pontos de verificação. É possível ler estas mensagens usando onstat -m.

Uma nova opção onstat (-g ckp) permite controlar o histórico do ponto de verificação para os 20 pontos de verificação anteriores. A opção onstat dá duração de ponto de verificação. Ela também apresenta o acionador que causou o ponto de verificação, que deve ser útil para configuração.


Aprendendo sobre Compactação de Tabela e Desfragmentação

O uso ineficiente de espaço em disco pode degradar o desempenho. Se o espaço for fracamente usado (exclusões podem liberar muito espaço de linha), a E/S aumentará para uma determinada recuperação de conjunto de dados. Quando páginas de tabela são distribuídas em muitas extensões, mais tempo de busca é necessário para encontrar os dados. É possível recompactar e diminuir independentemente da compactação. A recompactação consolida espaço livre e a redução retorna espaço livre ao dbspace, que encurta as extensões tanto quanto possível. A recompactação pode ser executada enquanto o mecanismo estiver off-line.

A desfragmentação resolve o segundo problema relocalizando e mesclando extensões onde for possível.

A compactação da tabela e a desfragmentação são executadas por meio da API administrativa. A seguir, alguns exemplos de comandos de API de administração:

Lista 30. Comando de API de Recompactação
EXECUTE FUNCTION task("table repack", "table_name", 
"database_name", "owner_name");
Lista 31. Comando de API de Diminuição
EXECUTE FUNCTION admin("table shrink",
"table_name", "database_name", "owner_name");
Lista 32. Comando de API de Desfragmentação
EXECUTE FUNCTION task("defragment", "database_name:owner_name.table_name");

É possível administrar essas operações usando a Open-Admin Tool (OAT) e elas podem ser planejadas.


Fazendo Melhorias de Desempenho Adicionais

Introduzindo Novas Opções de Fragmentação

Antes do Informix 11.70, a fragmentação era feita por round robin e expressão. No Informix 11.70, dois novos esquemas de fragmentação estão disponíveis: intervalo e lista. A estratégia de intervalo fornece um mecanismo para permitir fragmentos em valores que ainda não são conhecidos. A estratégia de lista permite fragmento de usuário em valores discretos.

Paralelismo Melhorado durante Backup e Restauração

Esta seção descreve novas abordagens de paralelismo durante o backup e a restauração.

Backup de Sistema Completo Paralelo de OnBar usando BAR_MAX_BACKUP

Antes do V11, backups de sistema completos eram de encadeamento único. Um registro de data e hora de ponto de verificação de um único archive era feito para todos os dbspaces e os pontos de verificação eram arquivados serialmente. Um backup do sistema completo e paralelo pode ser feito no V11 ao configurar apropriadamente BAR_MAX_BACKUP, como mostra a Tablela 9.

Tablela 9. Configurando BAR_MAX_BACKUP
Configuração de BAR_MAX_BACKUPDescrição
UnsetQuatro processos paralelos criados
0Permite que o mecanismo decida. O mecanismo aloca o menor número de espaços de armazenamento ou quantos podem ser acomodados na memória compartilhada.
1Archive serial (encadeamento único) e restauração
#Número de início de processos de backup

Um ponto de verificação é executado para todos os dbspaces logo antes do backup de rootdbs. O dbspace raiz é arquivado primeiro sem paralelismo. Até este ponto, é o mesmo comportamento que as versões anteriores.

Começando pelo V11, o backup de dbspaces restantes é executado em uma nova ordem. Esta ordem é a mesma que a usada para backups de sistema não completos. Um encadeamento de processador de imagem anterior (arcbackup2) é iniciado para cada dbspace. Isto permite que mais encadeamentos sejam executados em paralelo. Conforme cada backup de dbspace é concluído, o encadeamento arcbackup2 correspondente existe, resultando em menos encadeamentos arcbackup2 tomando recursos como processos de backup.

A nova ordem de backup de dbspace é baseada na contagem de páginas usadas no horário de início do backup. Dbspaces para terem backup realizado são ordenados pelo número de páginas usadas nos dbspaces em ordem decrescente. Isto garante melhor paralelismo. Isto entra em vigor independentemente de como o BAR_MAX_BACKUP está configurado ou quantas páginas devem ser arquivadas.

Criando VPs Definidas pelo Usuário

Classes especiais de processadores virtuais podem ser criadas para executar rotinas definidas pelo usuário ou executar o trabalho para um módulo DataBlade. Rotinas definidas pelo usuário normalmente são gravadas para suportar tipos de dados definidos pelo usuário. Se não desejar uma rotina definida pelo usuário para ser executada na classe da CPU, que é o padrão, é possível designá-la a uma classe definida pelo usuário de processadores virtuais (VPs). Outro nome para processadores virtuais definidos pelo usuário é processadores virtuais de extensão.

Determinando o número de processadores virtuais definidos pelo usuário necessários

Se seu UDR puder fazer seu trabalho em paralelo, você deve configurar processadores virtuais definidos pelo usuário suficientes para manipular as diversas tarefas que o UDR faz. O servidor de banco de dados suportará tantos VPs definidos pelo usuário quanto o sistema operacional permitir.

Usando Processadores Virtuais Definidos pelo Usuário

Classes definidas pelo usuário de processadores virtuais podem proteger o servidor de banco de dados de rotinas definidas pelo usuário de comportamento impróprio. Uma rotina definida pelo usuário de comportamento impróprio tem pelo menos uma das seguintes características:

  • Ele não concede controle a outros encadeamentos
  • Ele faz chamadas de sistema operacional de bloqueio
  • Ele modifica o estado global da VP

Designar qualquer rotina definida pelo usuário de comportamento impróprio a uma classe definida pelo usuário de processador virtual protege o servidor de banco de dados contra execução insegura, o que aprimora a confiabilidade do servidor. Os VPs definidos pelo usuário removem as seguintes restrições de programação na classe da VP da CPU:

  • A necessidade de conceder o processador regularmente. Como somente um encadeamento executando o UDR está em execução no processador virtual da extensão, não há necessidade de conceder.
  • A necessidade de eliminar chamadas de E/S de bloqueio.

UDRs executando processadores virtuais definidos pelo usuário não são necessários para conceder o processador. Eles podem emitir chamadas de sistema de arquivos que bloqueiam o processamento adicional pelo processador até que a E/S seja concluída. O impacto em outros encadeamentos em execução é reduzido quando esses UDRs estiverem em execução no processador virtual definido pelo usuário, em vez de VPs da CPU.

Especificando um Processador Virtual Definido pelo Usuário

A opção VPCLASS é usada para definir uma nova classe de VP. O nome de classe corresponde à CLASS definida no UDR.

Designando um UDR a uma classe de processador virtual definida pelo usuário

A instrução CREATE FUNCTION registra uma rotina definida pelo usuário. O nome da função é definido, junto com o tipo de retorno e o nome da classe em que a função é executada.

Como um exemplo, em Lista 33, a rotina definida pelo usuário AllLowerCase é definida. Ela especifica que o tipo de parâmetro dado é um caractere e define que o tipo de retorno é um BOOLEAN. Observe que o nome de classe também é especificado. Isto significa que as chamadas para esta rotina são executadas na classe de VP definida pelo usuário chamada ALC.

Lista 33. SQL de Amostra para Criar um UDR
CREATE  FUNCTION  AllLowerCase(char)
RETURNS  boolean
WITH  (CLASS  =  ALC  )
EXTERNAL  NAME  '/usr/lib/objects/udrs.so'
LANGUAGE  C

O arquivo ONCONFIG deve incluir um parâmetro VPCLASS que define a classe ALC. Se não, chamadas para a função AllLowerCase falharão.


Entendendo o Autoajuste do Informix

O Informix é ajustado automaticamente em várias áreas.

Pontos de Verificação Automáticos

O parâmetro ONCONFIG de AUTO_CKPTS permite o uso de pontos de verificação automáticos e é ativado por padrão. O servidor de banco de dados ajusta automaticamente a frequência do ponto de verificação para evitar bloqueio de transação. Lembre-se de que no começo deste tutorial os pontos de verificação acionados por uso físico e lógico podem bloquear o processamento. Com pontos de verificação automáticos em vigor, o servidor monitora o consumo de log físico e lógico, junto com informações sobre o desempenho passado do ponto de verificação. O servidor aciona pontos de verificação com mais frequência para evitar bloqueio de transação. O Informix incluiu as duas tabelas a seguir no banco de dados sysmaster para manter os dados de ponto de verificação.

  • A tabela syscheckpoint mantém um histórico nos últimos 20 pontos de verificação.
  • A tabela sysckptinfo controla a atividade do ponto de verificação.

Como o servidor de banco de dados não bloqueia transações durante o processamento de ponto de verificação, a limpeza de LRU deve ser moderada. Se o servidor não puder concluir o processamento de ponto de verificação antes de o log físico ser consumido (o que causa bloqueio de transação) e se não puder aumentar o tamanho do log físico, é possível configurar o servidor para uma limpeza de LRU mais agressiva.

O aumento na limpeza de LRU impacta o desempenho da transação, mas deve reduzir o bloqueio de transação. Se não configurar o servidor para uma limpeza mais agressiva, o servidor automaticamente ajustará a limpeza de LRU para que seja mais agressiva apenas quando o servidor não puder encontrar um buffer baixa prioridade para substituição de página.

É possível desativar o ajuste de ponto de verificação automático executando onmode -wf AUTO_CKPTS=0 ou configurando o parâmetro de configuração AUTO_CKPTS como 0.

O Ajuste Automático de LRU

As configurações de LRU para limpeza de cada buffer pool com pontos de verificação de intervalo não são essenciais para o desempenho de pontos de verificação no V11. As configurações de LRU são necessárias somente para manutenção de páginas limpas suficientes para substituição de página, o que torna a limpeza de LRU menos agressiva.

Começando no V11, o servidor de banco de dados ajusta automaticamente a limpeza de LRU sempre que uma substituição de página ocorre. O novo parâmetro de configuração para isto é AUTO_LRU_TUNING. O parâmetro de configuração AUTO_LRU_TUNING especifica se uma limpeza de LRU automática está ativada ou desativada quando o servidor iniciar.

Se AUTO_LRU_TUNING estiver ativado, após um ponto de verificação, se uma gravação de primeiro plano de substituição de página ocorreu durante o intervalo do ponto de verificação anterior, o servidor de banco de dados diminuirá as configurações de LRU em 5%. O servidor continua a diminuir a limpeza de LRU em cada ponto de verificação subsequente até que as gravações de primeiro plano de substituição de página parem ou o LRU_MAX_DIRTY para um determinado buffer pool esteja abaixo de 10%. Por exemplo, se uma gravação de primeiro plano de substituição de página ocorrer e as configurações de LRU para um buffer pool forem 80 e 90, o servidor de banco de dados ajustará esses 5% para 76 e 85,5.

A limpeza de LRU é ajustada mais agressivamente sempre que uma falha de página substitui uma página nova (buffers de alta prioridade) e buffers de prioridade não alta estão na fila de LRU modificada. Os ajustes de LRU automáticos apenas tornam a limpeza de LRU mais agressiva; eles não diminuem a limpeza de LRU.

Se a limpeza de LRU estiver reconfigurada para os valores contidos no arquivo ONCONFIG no qual o servidor de banco de dados é iniciado.

A limpeza de LRU automática afeta todos os buffer pools e ajusta os valores LRU_MIN_DIRTY e LRU_MAX_DIRTY no BUFFERPOOL .

O AUTO_LRU_TUNING é ativado por padrão no arquivo de configuração. É possível ativar dinamicamente ou desativar o ajuste de LRU automático usando onmode -wm ou onmode -wf.

Política do Objetivo do Tempo de Recuperação (RTO)

O Informix V11 introduz o parâmetro de configuração RTO_SERVER_RESTART, que configura o número de segundos em que o servidor de banco de dados tentará finalizar a recuperação e voltar para o modo on-line ou quiescente. Este parâmetro é útil quando o servidor precisa voltar on-line em um determinado tempo após um travamento. A estimativa manual do tempo de recuperação é difícil, porque o usuário não sabe o total de E/S necessário para recuperação.

A recuperação começa com a leitura de imagens anteriores da página de dados do log físico no buffer pool. Os logs lógicos então são usados para executar rollforward de transações confirmadas e retroceder transações não confirmadas. Para preencher o objetivo de tempo de recuperação, o Informix deve gerenciar a quantia de E/S que ocorrerá durante a recuperação.

Quando RTO_SERVER_RESTART é configurado, o servidor mantém as informações atuais no espaço de log físico e lógico usado uma vez que o ponto de verificação anterior mais a velocidade de E/S disponível para acessar esses logs durante a recuperação rápida. O tempo para reinicializar o servidor também é conhecido. Usando esses números, o servidor determina o intervalo do ponto de verificação necessário para manter a política de reinicialização.

RTO_SERVER_RESTART precisa ser ativado enquanto o mecanismo está on-line para que as páginas possam ser marcadas para serem preenchidas no buffer pool na recuperação rápida. Somente após a reciclagem o benefício será realizado.

Quando RTO_SERVER_RESTART está ativado, o servidor de banco de dados faz o seguinte:

  • Garante que os pontos de verificação automáticos não sejam executados fora dos recursos essenciais (como espaço de log) e bloqueio ao acionar mais pontos de verificação frequentes
  • Ignora o parâmetro de configuração CKPTINTVL e configura um intervalo do ponto de verificação calculado
  • Ajusta automaticamente o número de processadores virtuais AIO e encadeamentos de limpador
  • Ajusta automaticamente a limpeza de LRU para acomodar o número aumentado de pontos de verificação

Observe que os processadores virtuais AIO, limpadores e limpeza de LRU são automaticamente ajustados quando RTO_SERVER_RESTART está ativado, independentemente se AUTO_AIOVPS ou AUTO_LRU_TUNING está ativado.

A seguir, as desvantagens de ativar o RTO_SERVER_RESTART:

  • Armazenar páginas para recuperação lógica aumenta a atividade de log físico, que pode impactar o desempenho da transação
  • Frequência de ponto de verificação aumentada, embora o tamanho do log físico possa ser aumentado para aliviá-la

No mínimo, o espaço de log total precisa apenas ser grande o suficiente para conter todas as transações para dois ciclos de ponto de verificação. Na situação em que o RTO_SERVER_RESTART é ativado e o servidor possui tamanho do buffer pool combinado de menos que 4GB, o espaço de log total recomendado é de 110% dos tamanhos dos buffer pools combinados.

Dois novos parâmetros ONCONFIG , RAS_PLOG_SPEED e RAS_LLOG_SPEED, armazenam a taxa em que o log físico e lógico podem ser recuperados durante a recuperação rápida e são usados para calcular o intervalo do ponto de verificação para política de RTO. RAS_PLOG_SPEED é configurado inicialmente quando o log físico é inicializado. RAS_LLOG_SPEED é inicializado a 1/8 do RAS_PLOG_SPEED.

Toda vez que uma recuperação rápida ocorre, esses valores são atualizados para refletir o que a velocidade de recuperação real é. As unidades são páginas por segundo.

A IBM incluiu RAS_PLOG_SPEED e RAS_LLOG_SPEED no arquivo ONCONFIG para permitir que DBAs que integraram o Informix a seus aplicativos forneçam valores pré-calculados de modo que não seja necessário o ajuste para obter um desempenho ideal. Os DBAs não devem precisar alterar esses valores a menos que orientados pelo Suporte Técnico IBM.

Por padrão, RTO_SERVER_RESTART é desativado. Os intervalos de valores permitidos para configurar este parâmetro de configuração são como a seguir:

  • Se RTO_SERVER_RESTART estiver desativado, o intervalo de valor é 0.
  • Se RTO_SERVER_RESTART estiver ativado, o intervalo de valor é de 60 a 1.800 páginas por segundo.

É possível mudar o parâmetro de configuração RTO_SERVER_RESTART modificando o arquivo de configuração manualmente ou usando onmode -wf RTO_SERVER_RESTART. O novo valor de configuração do RTO_SERVER_RESTART entra em vigor quando o servidor de banco de dados for interrompido e reiniciado.

Com o Informix V11, pontos de verificação difusos foram descontinuados. Como resultado, o novo algoritmo de ponto de verificação requer mais atividade do log físico. Os aplicativos configurados para o Informix V7 devem observar pouca ou nenhuma mudança na taxa de atividade de criação física de log. Os aplicativos executados no V9 podem passar por um aumento na criação física de log. Ativar o RTO_SERVER_RESTART também causa um aumento na atividade da criação física de log.

Um log físico grande não impactará o desempenho. Um tamanho de log físico típico de 1GB a 4GB é suficiente normalmente.

Adição Dinâmica de Processadores Virtuais da CPU

Este é um novo recurso no Informix 11.70. O servidor de banco de dados em uma máquina de multiprocessador inclui automaticamente VPs de CPU se SINGLE_CPU_VP for configurado como 0 e a tarefa auto_tune_cpu_vps na tabela ph_task do banco de dados sysadmin estiver ativada. O servidor inclui até metade do número de processadores físicos em um máximo de (configurado mais automático) oito. Se precisar de mais de oito VPs de CPU, eles terão que ser configurados. A adição é feita na inicialização e uma mensagem em relação à adição de VP de CPU é impressa no on-line.log, como mostrado em Lista 34.

Lista 34. Mensagem sobre a Adição de VP de CPU Dinâmico
15:45:27  Dynamically added 3 cpu VPs

Ajuste Automático de VP AIO

Começando com o IBM Informix V11, é possível usar o parâmetro de configuração AUTO_AIOVPS para ativar o ajuste automático do número de VPs AIO e os encadeamentos do limpador quando o servidor detecta que esses VPs AIO não estão acompanhando a carga de trabalho de E/S.

O AUTO_AIOVPS é ativado por padrão no arquivo de configuração. É possível ativar ou desativar dinamicamente o aumento automático de VPs AIO e encadeamentos de limpador usando onmode -wm ou onmode -wf.


Conclusão

Este tutorial introduziu alguns dos novos recursos de desempenho no Informix. O tutorial fez o seguinte:

  • Introduziu algumas considerações de operação que precisam ser levadas em conta ao configurar seu sistema operacional para obter o máximo do Informix.
  • Discutiu o arquivo ONCONFIG , com alguma atenção à sua configuração para uso ideal dos recursos do sistema operacional.
  • Explicou pontos de verificação de não bloqueio, que podem fornecer um boost de desempenho significativo.
  • Considerou estatísticas de atualização, incluindo manutenção de estatísticas, que guiarão o otimizador a escolher o plano de consulta mais rápido.
  • Discutiu alguns aprimoramentos de desempenho e recursos de índices, incluindo autojunção e NO_SORTINDEX.
  • Apresentou recursos de autoajuste do servidor de banco de dados.

Agora, você deve estar mais bem preparado para a Parte 4 do exame 919 System Administration Certification para o Informix v11.70.

Continue com sua educação com as outras partes da série de certificação.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management
ArticleID=806363
ArticleTitle=Preparação do exame 919 de System Administration Certification for Informix 11.70, Parte 4: Ajuste de desempenho
publish-date=03222012