Quando ativar a variável de registro DB2_FORCE_FCM_BP, haverá alguns segmentos de memória compartilhada disponíveis para outros usuários, especificamente para conjuntos de buffers de |banco de dados. Portanto, a ativação da variável de registro DB2_FORCE_FCM_BP reduz o tamanho máximo de conjuntos de buffers do banco de dados. Observe que, devido ao grande número de segmentos de memória compartilhada disponíveis em um ambiente de 64 bits, esta redução no |número de segmentos de memória compartilhada deve ser um problema apenas em ambientes de |32 bits.
| | |Quando uma tabela é criada pela primeira vez, as estatísticas do catálogo do sistema são configuradas como -1 para indicar que a tabela não possui estatísticas. Até que as estatísticas sejam reunidas, o DB2 UDB utiliza valores padrão para compilação e otimização de instruções SQL. | A atualização de estatísticas de tabela ou de índice falhará se os novos valores estiverem inconsistentes com os valores padrão. Portanto, execute o comando runstats em uma tabela ou índice antes de atualizar manualmente estatísticas para qualquer um deles.
| | |A mensagem de erro SQL SQL1169N possui um novo código de razão 5 para indicar que uma coluna de uma tabela de explicação é muito pequena.
|O texto a seguir é uma atualização para o Administration |Guide: Performance, Chapter 6. Understanding the SQL compiler.
|A consolidação MDC pode ser utilizada se um índice RID fizer parte de um plano de otimização, independentemente da presença de uma cláusula WHERE na instrução DELETE. |Por isso, ao listar as condições que devem ser atendidas para permitir a consolidação |e a utilização de uma maneira mais eficiente para excluir linhas, a condição que "um índice RID não foi escolhido pelo otimizador para localizar as linhas a serem excluídas, |a menos que não exista nenhuma cláusula WHERE na instrução DELETE " deve ser removida.
|Além disso, você pode informar se a consolidação MDC está em vigor porque a saída db2expln mostra a frase "Exclusão de Célula". | Observe que db2exfmt não mostra estas informações.
|O texto a seguir é uma atualização para o Apêndice A. |Registro e Variáveis de Ambiente do DB2:
|A descrição de DB2_MDC_ROLLOUT deve ser alterada para que a condição que |"um índice RID não foi escolhido pelo otimizador para localizar as linhas |a serem excluídas, a menos que não exista nenhuma WHERE na instrução DELETE" deve ser removida da lista.
| | |Se você atualizar os valores de parâmetros de configuração newlogpath, mirrorpath ou overflowlogpath em um ambiente do DB2 UDB Enterprise Server Edition, |o número do nó será anexado ao nome do caminho, independentemente |do número de nós do sistema. Isto se aplica a sistemas de partição única e |multipartição em um ambiente do DB2 UDB Enterprise Server Edition.
| | |O valor padrão para DB2_COLLECT_TS_REC_INFO é ON. No DB2 UDB V 8.1 FixPak 7, o valor padrão para a variável de registro DB2_COLLECT_TS_REC_INFO |foi alterado para ON. A documentação atual especifica |incorretamente o padrão para esta variável como OFF.
Uma instância de Governor consiste de um utilitário front-end e de um ou mais daemons. Cada instância do Governor que você iniciar será específica para uma instância do gerenciador de banco de dados. Por padrão, quando você inicia o Governor, um administrador daemon é iniciado em cada partição do banco de dados particionado. Porém, você pode especificar que um daemon seja iniciado em uma partição única que você queira monitorar.
Cada daemon Governor coleta informação sobre os aplicativos que estão em execução no banco de dados. O daemon do governor verifica, então, estas informações nas regras especificadas no arquivo de configuração do governor para este banco de dados.
Ao considerar a reorganização da tabela local (ao invés da reorganização da tabela clássica), saiba que reorganização da tabela local requer mais espaço em registro.
Pelo fato de a reorganização da tabela local registrar suas atividades, por isso a recuperação é possível após uma deficiência inesperada, ela requer mais espaço em registro do que a reorganização clássica.
É possível que uma reorganização local solicite um espaço em registro, muitas vezes, igual ao tamanho da tabela reorganizada. A quantidade de espaços solicitados depende do número de filas que são movidas e do número e tamanho dos índices da tabela.
Recomendação: Escolha reorganização de tabela local para operações 24x7 com o mínimo de janelas de manutenção.
A reorganização de tabela on-line de uma tabela DMS permite a iniciação da operação de backup on-line de um espaço de tabelas no qual a tabela reside enquanto ocorre a reorganização. Onde provavelmente pode haver bloqueios pendentes da operação de reorganização durante a fase de truncamento.
Consulte as descrições de sintaxe REORG TABLE para obter informações detalhadas sobre a execução desses métodos de reorganização de tabela.
Em AIX(R) 5L 64 bits, a variável de registro DB2_LARGE_PAGE_MEM suporta agora a palavra-chave FCM.
Por padrão, no AIX(R) 5L(TM) 64 bits, a memória FCM está no conjunto de memória DBMS. Porém, quando a variável de registro DB2_FORCE_FCM_BP estiver ativada, a memória FCM está em seu próprio conjunto de memória. No AIX 5L(TM) 64 bits, DB2_LARGE_PAGE_MEM suporta a especificação do conjunto de memória DBMS. Quando a memória FCM estiver no conjunto de memória DBMS e o suporte a página grande estiver ativado para aquele conjunto de memória, a memória FCM estará nas páginas grandes. Quando a memória FCM estiver em um de seus próprios conjunto de memória, a palavra-chave FCM deve ser incluída ao valor da variável de registro DB2_LARGE_PAGE_MEM para ativar páginas grandes para memória FCM.
Iniciando com o DB2 UDB(TM) (Universal Database) Versão 8.2.2 (equivalente à Versão 8.1 FixPak 9), o arquivo de configuração especificado pela variável de registro DB2_RESOURCE_POLICY aceita um elemento SCHEDULING_POLICY. O elemento SCHEDULING_POLICY pode ser utilizado em algumas plataformas para selecionar:
As variáveis de registro DB2PRIORITIES e DB2NTPRICLASS podem ser utilizadas separadamente para controlar a política de planejamento do sistema operacional e definir as prioridades do agente DB2.
No entanto, a especificação de um elemento SCHEDULING_POLICY no arquivo de configuração da política de recursos fornece um local único para especificar a política de planejamento e as prioridades do agente associadas.
A seleção da política de planejamento AIX SCHED_FIFO2 com um impulso de prioridade para os processos de gravador e leitora de registros do db2:
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>SCHED_FIFO2</POLICY_TYPE>
<PRIORITY_VALUE>60</PRIORITY_VALUE>
<EDU_PRIORITY>
<EDU_NAME>db2loggr</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
<EDU_PRIORITY>
<EDU_NAME>db2loggw</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>A substituição para DB2NTPRICLASS=H no Windows.
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>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 0x10000000, 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.
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 "0x10000000(hex) 268435456(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 0x20000000 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 (authentication) 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 processador de linha de comando 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 AUTOMATIC 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 AUTOMATIC, 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 ]