Administração: Desempenho

Novas Variáveis de Ambiente do Sistema (Linux)

As variáveis de ambiente do sistema DB2_MAPPED_BASE e DB2DBMSADDR foram incluídas no FixPak 8.

O uso dessas variáveis de registro é recomendado apenas para usuários avançados.

DB2_MAPPED_BASE

Nome da Variável
DB2_MAPPED_BASE
Valores
Endereço virtual 0 OU (hex) no intervalo de endereço de 31 bits e 32 bits OU NULO (não definido)
Sistemas Operacionais
Linux em x86 e Linux em zSeries (31 bits)
Descrição
A variável de registro DB2_MAPPED_BASE pode ser utilizada para aumentar a quantidade de espaço do endereço virtual contíguo disponível para um processo do DB2 UDB (Universal Database) relocalizando o endereço de conexão das bibliotecas compartilhadas para o processo específico. O espaço do endereço virtual contíguo é importante para maximizar a quantidade de memória compartilhada do banco de dados disponível para o DB2 UDB. Essa variável é efetiva apenas em distribuições que incluem o arquivo mapped_base no diretório de identificação do processo no sistema de arquivos proc.

O DB2 UDB tentará relocalizar as bibliotecas compartilhadas para o endereço virtual 0x20000000 se essa variável não estiver definida.

A variável de registro também poderá ser definida para qualquer endereço virtual (em hex) no intervalo do espaço de endereço de 31 e 32 bits se o novo endereço colocar as bibliotecas compartilhadas mais baixo no espaço de endereço.

Nota:
O endereço incorreto pode causar problemas graves com o DB2 UDB, variando da incapacidade de iniciar o DB2 UDB até a incapacidade de se conectar ao banco de dados. Um endereço incorreto é aquele que colide com uma área na memória que já está em uso ou está pré-destinada a ser utilizada para algo mais. Para endereçar este problema, redefina a variável DB2_MAPPED_BASE para NULL utilizando o comando a seguir:
db2set DB2_MAPPED_BASE=

A mensagem a seguir pode aparecer várias vezes no arquivo db2diag.log porque essa alteração é requerida uma vez por nó lógico:

ADM0506I  DB2 has automatically updated the "mapped_base"
kernel parameter from "0x40000000(hex) 1073741824(dec)" to
the recommended value "0x20000000(hex) 536870912(dec)".

Essa mensagem aparecerá apenas se a definição da variável de registro for bem-sucedida e incluirá o endereço no qual as bibliotecas compartilhadas estão relocalizadas.

DB2DBMSADDR

Nome da Variável
DB2DBMSADDR
Valores
Endereços virtuais no intervalo de 0x09000000 a 0xB0000000 em incrementos de 0x10000
Sistemas Operacionais
Linux em x86 e Linux em zSeries (31 bits)
Descrição
Especifica o endereço de memória compartilhada do banco de dados padrão no formato hexadecimal.
Nota:
Um endereço incorreto pode causar problemas graves com o DB2 UDB, variando da incapacidade de iniciar o DB2 UDB até a incapacidade de se conectar ao banco de dados. Um exemplo de um endereço incorreto é aquele que colide com uma área na memória que já está em uso ou está pré-destinada a ser utilizada para algo mais. Para endereçar este problema, redefina a variável DB2DBMSADDR para NULL utilizando o comando a seguir:
db2set DB2DBMSADDR=

Essa variável pode ser definida junto com DB2_MAPPED_BASE ou sozinha para ajustar o layout do espaço de endereço dos processos do DB2 UDB. Essa variável altera a localização da memória compartilhada da instância de sua localização atual no endereço virtual 0x10000000 para o novo valor fornecido.

Nova Variável de Registro de Comunicação

A variável de registro DB2TCP_CLIENT_RCVTIMEOUT foi incluída na Versão 8.2.

Tabela 11. Variáveis de Comunicações
Nome da Variável Sistemas Operacionais Valores
Descrição
DB2TCP_CLIENT_RCVTIMEOUT Todos

Padrão=0 (não definido)

Valores: 0 a 32767 segundos

Especifica o número de segundos que um cliente aguarda dados em um recebimento de TCP/IP.

Não existe nenhum tempo limite se a variável de registro não estiver definida ou estiver definida como 0. Se o recebimento de TCP/IP for retornado com dados antes da expiração do valor de tempo limite, o aplicativo prosseguirá normalmente. Se o valor de tempo limite expirar antes do retorno dos dados, a conexão será fechada.

Nota:
Esta variável de registro é aplicável ao DB2 Client e ao lado do cliente do DB2 Gateway apenas. Ela não é aplicável ao DB2 Server.

Nova Variável de Desempenho

A variável de desempenho DB2_LARGE_PAGE_MEM foi incluída na Versão 8.2.

Tabela 12. Variáveis de Desempenho
Nome da Variável Sistemas Operacionais Valores
Descrição
DB2_LARGE_PAGE_MEM

AIX 5.x de 64 bits apenas

Linux

Default=NULL

Utilize * para indicar que todas as regiões de memória aplicáveis devem utilizar a memória de páginas grandes ou uma lista separada por vírgulas de regiões de memória específicas que devem utilizar memória de páginas grandes. As regiões disponíveis variam por sistema operacional. No AIX 5.x de 64 bits, as regiões a seguir podem ser especificadas: DB, DBMS ou PRIVATE. No Linux, a região a seguir pode ser especificada: DB.

A memória de páginas grandes é suportada apenas para o DB2 UDB (Universal Database) para AIX 5L, Edição de 64 bits e DB2 UDB para Linux.

A variável de registro DB2_LARGE_PAGE_MEM é utilizada para ativar o suporte a páginas grandes quando em execução no AIX 5.x ou em qualquer arquitetura Linux com o suporte kernel apropriado. Essa variável de registro desaprova a variável de registro DB2_LGPAGE_BP , que pode ser utilizada apenas para ativar a memória de páginas grandes para a região de memória compartilhada do banco de dados. Isso pode, agora, ser ativado definindo DB2_LARGE_PAGE_MEM=DB. Qualquer documentação que menciona a ativação de páginas grandes com a variável de registro DB2_LGPAGE_BP pode ser tratada como sinônimo da definição DB2_LARGE_PAGE_MEM=DB.

O uso de páginas grandes é destinado principalmente a fornecer aperfeiçoamentos de desempenho para aplicativos de cálculo de alto desempenho. Os aplicativos de acesso intenso à memória que utilizam grandes quantidades de memória virtual podem obter aperfeiçoamentos de desempenho utilizando páginas grandes. Para permitir que o DB2 UDB utilize páginas grandes, primeiro é necessário configurar o sistema operacional para utilizar páginas grandes.

Ativar páginas privadas grandes aumentará o uso de memória do DB2 UDB significativamente, pois cada agente do DB2 UDB consumirá pelo menos 1 página grande (16 MB) de memória física. Para permitir páginas grandes para a memória privada do agente no DB2 UDB para AIX de 64 bits (a definição DB2_LARGE_PAGE_MEM=PRIVATE), as condições a seguir devem ser atendidas, além da configuração de páginas grandes no sistema operacional:

  • O proprietário da instância deve possuir os recursos CAP_BYPASS_RAC_VMM e CAP_PROPOGATE.
  • O kernel deve suportar interfaces que permitem que um processo modifique seu tamanho de página no tempo de execução. .

No DB2 UDB para AIX de 64 bits, a ativação dessa variável reduz o tamanho do segmento de memória compartilhada voltando a memória do banco de dados para o requisito mínimo. O padrão é criar um segmento de 64 GB: consulte o parâmetro de configuração do banco de dados (database_memory) do tamanho da memória compartilhada do banco de dados para obter detalhes adicionais. Isto evita a retenção de mais memória compartilhada em RAM do que provavelmente será utilizada.

Definindo esta variável, a capacidade para aumentar dinamicamente a configuração de memória compartilhada do banco de dados geral (por exemplo, para aumentar o tamanho de conjuntos de buffers) será limitada.

No Linux, há um requisito adicional para a disponibilidade da biblioteca libcap.so. Esta biblioteca deve ser instalada para que esta opção funcione. Se esta opção estiver ativada e a biblioteca não estiver no sistema, o DB2 UDB desativará as páginas grandes do kernel e continuará funcionando como anteriormente.

No Linux, para verificar se as páginas grandes do kernel estão disponíveis, emita o comando a seguir:

      cat /proc/meminfo

Se elas estiverem disponíveis, devem aparecer três linhas (com números diferentes, dependendo da quantidade de memória configurada em sua máquina):

      HugePages_Total:   200
      HugePages_Free:    200
      Hugepagesize:    16384 KB

Se estas linhas não aparecerem, ou se HugePages_Total for 0, será requerida a configuração do sistema operacional ou do kernel.

Variáveis do Compilador SQL

A atualização a seguir aplica-se ao tópico "SQL compiler variables" no Apêndice A "DB2 Registry and Environment Variables" do Administration Guide: Performance:

Quando uma ou ambas as variáveis de compilador do DB2 DB2_MINIMIZE_LISTPREFETCH e DB2_INLIST_TO_NLJN, estiverem definidas para ON, elas permanecerão ativas mesmo se REOPT(ONCE) for especificado.

Atualizações de Parâmetros de Configuração

A seguir são apresentadas as atualizações para a documentação dos parâmetros de configuração:

Autenticação - Tipo de Autenticação

O parâmetro de configuração do gerenciador de banco de dados do tipo de autenticação (autenticação) também aceita os valores a seguir:

util_impact_lim - Política de Impacto da Instância

A partir do DB2 Universal Database Versão 8.2, o valor padrão do parâmetro de configuração do gerenciador de banco de dados da Política de Impacto da Instância (util_impact_lim) é alterado de 100 para 10.

sysadm_group, sysmaint_group, sysctrl_group, sysmon_group

Os parâmetros de configuração do gerenciador de banco de dados a seguir podem aceitar nomes de grupos de 30 bytes (ou menos) em todas as plataformas:

A tabela no tópico "Resumo dos parâmetros de configuração do gerenciador de banco de dados" contém tipos de dados incorretos para esses parâmetros de configuração do gerenciador de banco de dados. O valor correto em todos os casos é char(30).

estore_seg_sz - Tamanho do Segmento de Memória de Armazenamento Estendido

O tamanho máximo para o parâmetro de configuração do Banco de dados de tamanho do segmento de memória de armazenamento estendido (estore_seg_size) em plataformas baseadas no Windows é 16 777 216.

hadr_timeout - Valor de Tempo Limite de HADR

O limite superior correto do parâmetro de configuração do banco de dados de valor do tempo limite de HADR (hadr_timeout) é 4 294 967 295.

locklist - Armazenamento Máximo para a Lista de Travas

A documentação para o parâmetro de configuração do banco de dados de Armazenamento máximo para locklist (locklist) afirma que o valor máximo para servidores Windows de 64 e de 32 bits que atendem apenas clientes locais é 60 000. Este valor é incorreto e deve ser 524 288.

num_db_backups - Número de Backups de Banco de Dados

O intervalo de valores para o parâmetro de configuração de banco de dados Número de backups de banco de dados (num_db_backups) é incorreto. O intervalo correto é de 0 - 32 767.

Arquivo de Parâmetro de Configuração de Banco de Dados SQLDBCONF

Depois de migrar para o DB2 UDB (Universal Database) Versão 8.2 da Versão 8.1, o DB2 UDB utiliza um novo arquivo de parâmetro de configuração de banco de dados de 16 KB denominado SQLDBCONF. (Na Versão 8.1, o arquivo de parâmetro de configuração de banco de dados era apenas 4 KB e era denominado SQLDBCON).

Alteração no Valor Padrão DB2_HASH_JOIN

A partir da Versão 8.1, a variável de registro DB2_HASH_JOIN é definida para ON por padrão.

A variável hash-join deve ser utilizada, mas ela precisa ser ajustada para obter o melhor desempenho.

O desempenho de hash-join será o melhor se você puder evitar loops de hash e estouro para o disco. Para ajustar o desempenho de hash-join, faça a estimativa da quantidade máxima de memória disponível para o parâmetro sheapthres e, em seguida, ajuste o parâmetro sortheap. Aumente seu valor até evitar tantos loops de hash e estouros de disco quanto for possível, mas não atinja o limite especificado pelo parâmetro sheapthres.

Para obter informações adicionais, consulte o tópico "Join methods" no manual Administration Guide: Performance.

A Variável de Registro DB2NTNOCACHE É Reprovada

A funcionalidade obtida anteriormente através de DB2NTNOCACHE pode ser obtida no nível do espaço de tabelas, especificando a cláusula NO FILE SYSTEM CACHING na instrução CREATE TABLESPACE ou ALTER TABLESPACE. Consulte o SQL Reference para obter detalhes sobre o uso. A variável de registro DB2NTNOCACHE será removida em um release futuro.

Tabelas de Explicação e Organização de Informações de Explicação

As tabelas de explicação podem ser comuns a mais de um usuário. No entanto, as tabelas de explicação podem ser definidas para um usuário e os aliases podem ser definidos para cada usuário adicional, utilizando o mesmo nome para apontar para as tabelas definidas. Como alternativa, as tabelas de explicação podem ser definidas no esquema SYSTOOLS. O recurso de Explicação assumirá o esquema SYSTOOLS como padrão se não forem encontradas outras tabelas de explicação ou aliases no ID de sessão do usuário para SQL dinâmico, ou no ID de autorização de instrução para SQL estático. Cada usuário que compartilha as tabelas de explicação comuns deve ter permissão de inserção nestas tabelas. A permissão de leitura para as tabelas de explicação comuns também deve ser limitada, geralmente para usuários que analisam as informações de explicação.

Diretrizes para Captura de Informações do Explain

Os dados de explicação serão capturados se você solicitá-los durante a compilação de uma instrução SQL. Considere como você espera utilizar as informações capturadas quando solicitar dados de explicação.

Capturando Informações nas Tabelas de Explicação

Códigos de Retorno Adicionais da API db2CfgGet, Parâmetro collate_info

O parâmetro de informações de intercalação pode ser exibido apenas utilizando a API db2CfgGet. Ele não pode ser exibido através do Command Line Processor ou do Centro de Controle.

Tipo de Configuração
Banco de Dados Sample
Tipo de Parâmetro
Informativo

Este parâmetro fornece 260 bytes de informações de intercalação do banco de dados. Os primeiros 256 bytes especificam a seqüência de intercalação do banco de dados, na qual o byte "n" contém o peso de classificação do ponto de código cuja representação decimal subjacente é "n" na página de códigos do banco de dados.

Os últimos 4 bytes contêm informações internas sobre o tipo de seqüência de intercalação. Os últimos 4 bytes de collate_info são um inteiro. O inteiro é sensível à ordem endian da plataforma. Os valores possíveis são:

Se você utilizar estas informações de tipo internas, será necessário considerar a reversão de bytes ao recuperar informações para um banco de dados em uma plataforma diferente.

Você pode especificar a seqüência de intercalação no momento da criação do banco de dados.

Definição Automática do Tamanho Padrão de Pré-Busca e Padrões de Atualização

A partir do DB2 UDB (Universal Database) Versão 8.2, você pode utilizar o tamanho da pré-busca AUTOMÁTICA para um espaço de tabelas. O DB2 UDB atualiza automaticamente o tamanho da pré-busca quando o número de contêineres é alterado para o espaço de tabelas.

A sintaxe da variável de registro DB2_PARALLEL_IO é expandida para reconhecer contêineres com diferentes características de paralelismo de E/S. Através da sintaxe expandida, os contêineres para diferentes espaços de tabela podem ter diferentes características de paralelismo de E/S. A característica de paralelismo de E/S de cada espaço de tabelas será utilizada quando um tamanho de pré-busca AUTOMATIC for especificado para o espaço de tabelas. Se a variável de registro DB2_PARALLEL_IO estiver ativada, mas a sintaxe expandida que identifica as características de paralelismo de E/S específicas para os espaços de tabela não for utilizada, será assumido um nível de paralelismo padrão. O nível padrão é RAID 5 (6+1).

As informações do tamanho da pré-busca utilizadas pelo otimizador são atualizadas apenas quando uma instrução ALTER TABLESPACE que altera o tamanho da pré-busca de um espaço de tabelas ou altera o número de contêineres (utilizando ADD/DROP/BEGIN NEW STRIPE SET/ADD TO NEW STRIPE SET) é emitida. Se as definições de registro de número de discos físicos por contêiner forem alteradas, uma instrução ALTER TABLESPACE <nome do espaço de tabelas> PREFETCHSIZE AUTOMATIC deve ser emitida para atualizar as informações do otimizador (a não ser que uma instrução ALTER TABLESPACE que atualize as informações do otimizador já esteja emitida).

Se um espaço de tabelas for redirecionado ou restaurado para utilizar um número diferente de contêineres, atualize as informações do otimizador emitindo uma instrução ALTER TABLESPACE <nome de espaço de tabelas> PREFETCHSIZE AUTOMATIC. Caso existam múltiplos conjuntos de faixa dentro de um espaço de tabelas, o número de contêineres máximo entre os conjuntos de faixa será utilizado para calcular o tamanho de pré-busca.Se o tamanho da pré-busca calculado exceder o tamanho máximo (32.767 páginas), o maior múltiplo do número de contêineres que seja menor que o máximo será utilizado como o tamanho da pré-busca.

Em um ambiente do DB2 UDB Enterprise Server Edition, se um espaço de tabelas utilizar um tamanho de pré-busca AUTOMÁTICA, o tamanho da pré-busca poderá ser diferente em diferentes partições de um banco de dados. Essa situação ocorre porque diferentes partições de banco de dados podem ter números diferentes de contêineres utilizados para calcular o tamanho da pré-busca. Para gerar o plano de consulta de acesso, o otimizador utiliza o tamanho de pré-busca a partir da primeira partição em um grupo de partição de banco de dados.

[ Início da Página |Página Anterior | Próxima Página | Índice ]