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.
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.
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.
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.
A variável de registro DB2TCP_CLIENT_RCVTIMEOUT foi incluída na Versão 8.2.
A variável de desempenho DB2_LARGE_PAGE_MEM foi incluída na Versão 8.2.
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:
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. |
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.
A seguir são apresentadas as atualizações para a documentação dos parâmetros de configuraçã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:
O servidor aceita esquemas de autenticação SERVER criptografados e a criptografia de dados do usuário. A autenticação funciona exatamente da mesma forma que SERVER_ENCRYPT.
Os dados de usuário a seguir são criptografados ao utilizar esse tipo de autenticação:
O servidor aceita esquemas de autenticação SERVER criptografados e a criptografia de dados do usuário. Além disso, esse tipo de autenticação permite a compatibilidade com produtos anteriores que não suportam o tipo de autenticação DATA_ENCRYPT. Esses produtos têm permissão para se conectarem ao tipo de autenticação SERVER_ENCRYPT e sem criptografar dados do usuário. Os produtos que suportam o novo tipo de autenticação devem utilizá-lo. Esse tipo de autenticação é válido apenas no arquivo de configuração do gerenciador de banco de dados do servidor e não é válido quando utilizado no comando CATALOG DATABASE.
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.
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).
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.
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.
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.
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.
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).
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 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.
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.
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.
As informações de tabelas de explicação são capturadas em qualquer um dos seguintes casos:
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.
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.
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 ]