Como determinar configurações de configuração adequadas do SQL Server

Este artigo descreve as seguintes definições de configuração e considerações para seu uso:

• Máscara de afinidade
• Leve pool
• Max Async E/S
• Max Worker Threads
• Memória
• Aumento de prioridade
• Definir o tamanho do conjunto de trabalho

SQL Server pode obter um nível muito alto de desempenho com relativamente pouco configuração ajuste. Você pode obter altos níveis de desempenho usando o aplicativo boa e design de banco de dados e não pelo ajuste abrangente de configuração. Consulte a seção "Referências" deste artigo para obter informações sobre como solucionar diversos problemas de desempenho do SQL Server.

Ao resolver um problema de desempenho, o grau de melhoria está disponível a partir da configuração de ajuste é normalmente modesto a menos que você não tem atualmente o sistema configurado corretamente. No SQL Server versão 7.0 e posterior, o SQL Server usa a configuração automática de ajuste e é extremamente raro que as configurações (especialmente configurações avançadas) precisam quaisquer alterações. Geralmente, não faça uma configuração do SQL Server alterar sem motivo esmagadora e não sem cuidado metódica testes para verificar a necessidade de alteração de configuração. Você deve estabelecer uma linha de base antes de alterar a configuração para que você pode medir o benefício após a alteração.

Se você não tiver o SQL Server configurado corretamente, algumas configurações talvez de-stabilize o servidor ou podem tornar o SQL Server funcionam incorretamente. Anos de experiência de suporte com muitos ambientes diferentes indicam que as configurações não padrão podem ter resultados que variam de neutra para altamente negativo.

Se você fazer uma configuração alterar, você deve executar desempenho metódico rigoroso testes antes e após a alteração para avaliar o grau de melhoria.

Com base em cenários reais de suporte, SQL Server versão 7.0 e posterior pode atingir um nível extremamente alto de desempenho sem qualquer ajuste de configuração manual.

No SQL Server versão 7.0 e posterior, não faça quaisquer alterações de configuração para conexões de usuário, bloqueios e abrir objetos porque, por padrão, o SQL Server ajusta dinamicamente essas configurações.

Máscara de afinidade

A configuração de máscara de afinidade se refere como firmemente um thread está acoplado a uma determinada CPU. Por padrão, o Microsoft Windows NT e Microsoft Windows 2000 usam "soft" afinidade, que tenta reprogramar um thread na CPU onde ele última executado. No entanto, se não for possível, um thread pode executar em uma CPU diferente.

Ajuda prática real, se você alterar a configuração de máscara de afinidade do padrão ele apenas raramente a desempenho e freqüentemente degradará desempenho.

Máscara de afinidade restringe o SQL Server a um subconjunto de CPUs disponíveis e permite que outros concorrente serviços melhor CPU acesso. Na maioria dos casos, você não precisa isso porque o SQL Server é executado com prioridade normal. O Agendador de thread do Windows NT ou Windows 2000 ajusta dinamicamente prioridades do thread de todos os threads para certificar-se de que eles têm uma chance razoável CPUs disponíveis em todos os concorrentes.

Não ajustar a máscara de afinidade, exceto em condições muito incomuns. Se você escolher ajustar a máscara de afinidade, execute testes metódica rigorosos antes e após a alteração para verificar a necessidade de e o grau de melhoria.

Lightweight pooling

Por padrão, o SQL Server usa um thread por SPID ativa ou processo de usuário. Esses threads trabalhar em uma configuração em pool para manter o número de segmentos gerenciável. A configuração avançada opção "lightweight pooling" (que às vezes é referida como "Modo Fiber") usa fibra"Windows NT" suporte para manipular essencialmente vários contextos de execução com um único segmento.

Com base na experiência de produção real, você não precisa usar Fiber modo, exceto em circunstâncias muito raras. Pooling de leve é mesmo potencialmente útil apenas se todas as seguintes condições forem atendidas. Você deve determinar se é realmente útil por meio de testes controlada cuidadoso.

• Grandes servidores com vários processadores estão em uso.
• Todos os servidores estão sendo executados ou próximo capacidade máxima.
• Muita alternância de contexto ocorre (maior do que 20.000 por segundo).

Para procurar a alternância de contexto, use o Monitor de desempenho, selecione os threads de contador, selecione o objeto comutadores de contexto/s " e selecione para capturar todas as instâncias do SQL Server. Não há suporte para o SQL Mail no SQL Server 2000 ou no SQL Server 2005 se você executar o servidor no modo fibra. Não há suporte para o SQL Mail no SQL Server 2000 64 bits. Para obter mais informações, consulte o tópico "Diferenças entre versões de 32 bits e 64 bits" nos manuais online do SQL Server 2000 (64-bit Edition). Para obter informações adicionais, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento:

Max Async E/S

SQL Server 7.0: A configuração de configuração de E/S assíncrona máxima está disponível no SQL Server 7.0. Talvez seja adequado alterar essa configuração se você tiver um sistema RAID rápido e uma maneira de medir o benefício. Não altere essa configuração, a menos que você tenha uma linha de base pela qual avaliar o resultado. Monitorar a atividade do disco e procurar por quaisquer problemas de enfileiramento de disco. Para obter informações adicionais, consulte os seguintes manuais online do SQL Server tópicos:

• "opção de E/S assíncrona max"
• "Monitorando a atividade de disco"
• "Identificando afunilamentos"

SQL Server 2000 e posterior: no SQL Server 2000 e posterior, você não pode alterar a configuração de E/S assíncrona máxima. SQL Server 2000 e posterior ajusta automaticamente essa configuração.

Max Worker Threads

Por padrão, a configuração de threads de trabalho máximo é 255 no SQL Server 2000. Portanto, para 255 operador segmentos podem ser criados. Use a configuração padrão de 255 na maioria dos casos. Isso não significa que você só pode estabelecer conexões de usuário 255. Um sistema pode ter milhares de conexões de usuário (que essencialmente são multiplexadas para baixo para 255 threads de trabalho) e em geral, os usuários não geralmente percebem quaisquer atrasos. No caso, somente 255 consultas podem executar simultaneamente, mas isso é multiplexado para baixo para o número de CPUs disponíveis, portanto, a natureza simultânea somente é percebida, independentemente do número de segmentos de trabalho configurados.

Observação Por padrão, a configuração de threads de trabalho máximo é 0 no SQL Server 2005 e no SQL Server 2008.

Se você configurar um número de segmentos de trabalho para um valor maior que o padrão é quase sempre contraproducente e diminui o desempenho devido a sobrecarga de agendamento e recurso. Apenas aumente essa configuração em circunstâncias muito incomuns e quando testes rigorosos metódica demonstra que é útil fazer isso.

Memória

Consulte o MANUAIS online tópico "Otimizando Server Performance usando memória configuração Opções" para obter informações sobre como configurar a memória.

Para obter mais informações sobre como configurar a memória para servidores em cluster do SQL, consulte "Considerações de uso" no SQL Server Books Online tópico, "Criando um cluster de failover".

Para obter informações adicionais, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento:

Aumento de prioridade

Por padrão, a configuração de aumento de prioridade é 0, que faz com que o SQL Server para executar em uma prioridade normal se você executa o SQL Server em um computador uniprocessador ou em um computador (SMP) multiprocessador simétrico. Se você definir o aumento de prioridade para 1, o processo do SQL Server é executado em uma prioridade alta. Essa configuração não faz do processo do SQL Server execução na prioridade mais alta do sistema operacional.

Com base na experiência real suporte, você não precisa usar o aumento de prioridade para o bom desempenho. Se você usar aumento de prioridade, pode interferir com servidor suave funcionando em algumas condições e você não deve usá-lo, exceto em circunstâncias muito incomuns. Por exemplo, atendimento pode usar aumento de prioridade quando eles investigar um problema de desempenho.

Importante Não use o aumento de prioridade para servidores em cluster que estão executando o SQL Server 7.0 e posterior.

Definir o tamanho do conjunto de trabalho

Não altere a definir o tamanho do conjunto de trabalho da configuração padrão. Com o padrão de 0, o Gerenciador de memória virtual do Windows NT ou Windows 2000 pode determinar o tamanho do conjunto de trabalho do SQL Server. Quando você instala o SQL Server, instalação instrui automaticamente Windows NT ou Windows 2000 para otimizar o desempenho para aplicativos de rede. Portanto, o Gerenciador de memória virtual do Windows NT ou Windows 2000 fará muito pouco conjunto de trabalho aparando, que só minimamente interfere com o conjunto de trabalho de instâncias do SQL Server.

Alterar essa configuração não fornece qualquer benefício de desempenho normalmente. Com base em casos de suporte real, a alteração das normalmente essa configuração faz com que mais danos do que boa.

Se você alterar Definir tamanho do conjunto de trabalho, ele também pode ser uma causa das mensagens de erro do SQL Server 844 ou 845. Consulte a seção "Referências" deste artigo para obter mais informações sobre causas comuns de mensagens de erro 844 e 845.

Para obter informações adicionais, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento: