INF: Otimizando o desempenho do Microsoft SQL Server

Traduções deste artigo Traduções deste artigo
ID do artigo: 110352 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Para otimizar o desempenho do Microsoft SQL Server com mais eficiência, você deve identificar as áreas que irão produzir os aumentos de desempenho maiores sobre a maior variedade de situações e se concentrar a análise nessas áreas. Caso contrário, você pode fazer significativo tempo e esforço sobre tópicos que não pode produzir aprimoramentos dimensionável.

Para maior parte, as informações a seguir não abordam os problemas de desempenho lematização de simultaneidade multiusuário. Isso é um tópico complexo, separado que é coberto no documento "Maximização Database consistência e simultaneidade," que pode ser encontrado no SQL Server versão 4.2 x "Referência do programador de C," Apêndice E e também em outros artigos da Base de dados de Conhecimento. Ele não está na documentação versão 6.0, mas pode ser encontrado no CD do MSDN (Microsoft Developer Network) nesse título.

Em vez de uma abordagem teórica, este artigo se concentra principalmente em áreas que anos de experiência pela equipe de suporte do Microsoft SQL Server mostrou para ser de valor prático em situações do mundo real.

A experiência mostra que o maior benefício no desempenho do SQL Server pode ser obtido com as áreas gerais de design de banco de dados lógico, design de índice, design da consulta e design de aplicativo. Por outro lado, os maiores problemas de desempenho são geralmente causados por deficiências nessas áreas mesmo. Se você estiver preocupado com o desempenho, você deve concentrar nessas áreas em primeiro lugar, como melhorias de desempenho muito grande com freqüência podem ser obtidas com um investimento de tempo relativamente pequeno.

Enquanto os problemas de desempenho outro nível de sistema, como memória, buffers de cache, hardware e assim por diante, certamente são candidatos para estudo, a experiência mostra que o ganho de desempenho dessas áreas costuma incremental. SQL Server gerencia recursos de hardware disponíveis automaticamente, na maior parte, reduzindo a necessidade (e portanto, o benefício) de ajuste amplo nível de sistema disponível.

Microsoft SQL Server 6.0 oferece novas oportunidades para a camada de plataforma melhorias de desempenho, com grandes quantidades de memória, multiprocessamento simétrico, verificação de dados paralelas, otimizador aprimoramentos e distribuição de disco. No entanto, tão grande como essas melhorias estão, eles são finito no escopo. O computador mais rápido pode ser bogged para baixo com um aplicativo mal projetado ou consultas ineficientes. Portanto, mesmo com o aumento de desempenho adicional que permite a SQL Server 6.0, é extremamente importante otimizar o banco de dados, índice, consulta e design de aplicativo.

A maioria dos problemas de desempenho não podem ser resolvidos com êxito com apenas um foco do lado do servidor. O servidor é essencialmente um "puppet" do cliente, que controla quais consultas são enviadas, e assim que bloqueios são obtidos e liberados. Embora seja possível no lado do servidor algum ajuste, resolução bem-sucedida de problemas de desempenho geralmente dependerá confirmando que a função dominante o cliente desempenha no problema e analisar o comportamento do aplicativo cliente.

Mais Informações

A seguir estão algumas sugestões que, de acordo com a experiência, ter gerou ganhos de desempenho significativos:

Normalizar o design de banco de dados lógico

Normalização razoável do design de banco de dados lógico gera melhor desempenho. Um número maior de tabelas estreitas é característica de um banco de dados normalizado. Um número menor de tabelas grande é característica de um banco de dados desordenado. Um banco de dados altamente normalizado está rotineiramente associado com associações relacionais complexas, que podem afetar o desempenho. No entanto, o otimizador do SQL Server é muito eficiente no selecionando associações rápidas, eficientes, desde que eficaz índices estão disponíveis.

Os benefícios de normalização incluem:
  • Acelera a criação de índice de classificação e, como tabelas são mais estreitas.
  • Permite que mais índices de cluster, porque há mais tabelas.
  • Índices tendem a ser mais estreita e mais compacta.
  • Menos índices por tabela, ajudando o desempenho de UPDATE.
  • Menos nulos e os dados menos redundantes, aumentando compactness de banco de dados.
  • Reduz o impacto de simultaneidade de diagnósticos DBCC, pois os bloqueios necessários tabela afetarão menos dados.
Com o SQL Server, geralmente normalização razoável Ajuda em vez de desempenho hurts. À medida que aumenta a normalização, então, fazer o número e a complexidade do necessário para recuperar dados de associações. Como prática de regra aproximada, a Microsoft sugere executar sobre o processo de normalização, a menos que isso faz com que várias consultas com associações de quatro vias ou maiores.

Se o design de banco de dados lógico já é fixo e total reformulação não é viável, que talvez seja possível normalizar seletivamente uma tabela grande se análise mostrar um afunilamento nesta tabela. Se o acesso ao banco de dados é realizado através de procedimentos armazenados, essa alteração de esquema foi ocorrerá sem afetar os aplicativos. Caso contrário, talvez seja possível ocultar a alteração criando um modo de exibição semelhante a uma única tabela.

Use o design de índice eficiente

Ao contrário de muitos sistemas não-relacionais, índices relacionais não são considerados parte o design de banco de dados lógico. Índices podem ser ignorados, adicionados e alterados sem afetar o design de esquema ou aplicativo de banco de dados de forma alguma diferente de desempenho. Design de índice eficiente é fundamental na obtenção de bom desempenho do SQL Server. Por esses motivos, você deve não hesite em experimentar diferentes índices.

O otimizador escolhe confiável o índice mais eficiente na maioria dos casos. A estratégia de design geral do índice deve ser fornecem uma boa seleção de índices para o otimizador e confiar nele tomar a decisão certa. Isso reduz o tempo de análise e proporciona bom desempenho em uma grande variedade de situações.

Estas são recomendações de design de índice:
  • Examine a cláusula WHERE de suas consultas SQL, porque este é o principal foco o otimizador.

    Cada coluna na cláusula WHERE é um candidato possível para um índice. Se você tiver muitas consultas para examinar, selecione um conjunto representativo, ou apenas os lentos. Se sua ferramenta de desenvolvimento de forma transparente gerar código SQL, isso é mais difícil. Muitas dessas ferramentas permitem o log da sintaxe SQL gerada para um arquivo ou a tela para fins de depuração. Talvez queira saber do fornecedor da ferramenta, se um recurso estiver disponível.
  • Use índices estreitos.

    Índices estreitas são geralmente mais eficiente do que os índices de várias colunas, compostos. Índices estreitas têm mais linhas por página e menos níveis de índice, aumentando o desempenho.

    O otimizador pode rapidamente e com eficiência analisar centenas ou até mesmo milhares, de possibilidades de índice e associação. Ter um número maior de índices estreitas fornece o otimizador com mais possibilidades para escolha, que geralmente ajuda a desempenho. Ter menos índices de várias colunas, largura fornece o otimizador com menos possibilidades para escolha, que pode afetar o desempenho.

    Geralmente é melhor não adotar uma estratégia de enfatizar uma consulta totalmente coberta. É verdade que se todas as colunas na sua cláusula SELECT são cobertas por um índice não agrupado, o otimizador pode reconhecer isso e fornecer um desempenho muito bom. No entanto, isso geralmente resulta em índices excessivamente grande e depende muito a possibilidade de que o otimizador usará essa estratégia. Normalmente, você deve usar mais vários índices estreitas que geralmente fornecem um melhor desempenho em um intervalo maior de consultas.

    Você não deve ter mais índices que são necessários para alcançar um desempenho de leitura adequado devido à sobrecarga envolvida na atualização esses índices. No entanto, até mesmo maioria das operações orientado a atualização exigir leitura muito mais que escrever. Portanto, não hesite tentar um novo índice se você acha que ajudará; você sempre pode soltá-lo mais tarde.
  • Utilize índices em cluster.

    Uso apropriado dos índices em cluster pode aumentar bastante o desempenho. Operações mesmo UPDATE e DELETE são freqüentemente aceleradas por índices em cluster, porque essas operações requerem muito leitura. É permitido um único índice em cluster por tabela, então, utilizar este índice com sabedoria. Consultas que retornam várias linhas ou consultas que envolvem um intervalo de valores, são bons candidatos à aceleração por um índice de cluster.

    Exemplos:
          SELECT * FROM PHONEBOOK
          WHERE LASTNAME='SMITH'
    
          -or-
    
          SELECT * FROM MEMBERTABLE
          WHERE  MEMBER_NO > 5000
           AND MEMBER_NO < 6000
    
    						
    Por outro lado, as colunas Sobrenome ou MEMBER_NO mencionadas acima provavelmente não são boas candidatas para um índice não agrupado se este tipo de consulta comum. Tente usar índices não clusterizados nas colunas onde algumas linhas são retornadas.
  • Examine a exclusividade de coluna.

    Isso ajuda a decidir qual coluna é um candidato para um índice de cluster, o índice não agrupado ou nenhum índice.

    A seguir está uma consulta de exemplo para examinar a exclusividade de coluna:
          SELECT COUNT (DISTINCT COLNAME)
          FROM TABLENAME
    
    						
    Isso retorna o número de valores exclusivos na coluna. Compare isso para o número total de linhas na tabela. Em uma tabela linha de 10.000, valores exclusivos 5.000 seriam tornar a coluna um bom candidato para um índice não agrupado. Na mesma tabela, valores exclusivos 20 poderiam atender melhor a um índice de cluster. Não devem ser indexados em todos os três valores exclusivos. Estes são exemplos apenas, não as regras de disco rígidos e rápidas. Lembre-se de colocar os índices em colunas individuais listadas nas cláusulas WHERE das consultas.
  • Examine a distribuição dos dados em colunas indexadas.

    Com freqüência uma consulta de execução demorada ocorre porque uma coluna com alguns valores exclusivos é indexada, ou um JOIN em como uma coluna é executada. Isso é um problema fundamental com os dados e a própria consulta e geralmente não pode ser resolvido sem identificação nessa situação. Por exemplo, um diretório físico do telefone classificado em ordem alfabética no último nome irá acelerar não pesquisar uma pessoa se todas as pessoas na cidade são chamadas apenas "Smith" ou "Jorge". Juntamente com a consulta acima, que fornece uma única figura para que a coluna exclusividade, você pode usar uma consulta GROUP BY para ver a distribuição de dados dos valores de chaves indexados. Isso fornece uma imagem de resolução maior dos dados e uma perspectiva melhor para como o otimizador exibe os dados.

    A seguir está uma consulta de exemplo para examinar a distribuição dos dados de valores chaves indexados, supondo que uma chave de duas colunas em COL1, COL2:
          SELECT COL1, COL2, COUNT(*)
          FROM TABLENAME
          GROUP BY COL1, COL2
    
    						
    Isso irá retornar uma linha para cada valor de chave, com uma contagem de instâncias de cada valor. Para reduzir o número de linhas retornado, ele pode ser útil excluir alguns com uma cláusula HAVING. Por exemplo, a cláusula
          HAVING COUNT(*) > 1
    
    						
    excluirá todas as linhas que possuem uma chave exclusiva.

    O número de linhas retornadas em uma consulta também é um fator importante na seleção de índice. O otimizador considera um índice não agrupado pelo menos uma E/s de página por linha retornada de custo. Com essa taxa, rapidamente torna mais eficiente para examinar a tabela inteira. Este é outro motivo para restringir o tamanho do conjunto de resultados ou para localizar o resultado grande com um índice de cluster.
Equiparar não sempre os uso do índice com bom desempenho e vice-versa. Se usar um índice sempre produzido o melhor desempenho, trabalho do otimizador seria muito simples - sempre use qualquer índice disponível. Na verdade, escolha incorreta de recuperação indexada pode resultar em desempenho muito ruim. Portanto, tarefa do otimizador é selecionar indexada recuperação onde ele será ajudam a desempenho e evitar recuperação indexada onde ele irá atingir o desempenho.

Use o design da consulta eficiente

Alguns tipos de consultas são inerentemente recurso intensivo. Isso está relacionado ao banco de dados fundamental e índice problemas comuns para a maioria dos sistemas de gerenciamento banco de dados relacional (RDBMSs), não especificamente para SQL Server. Eles não são ineficientes, porque o otimizador implementará as consultas da maneira mais eficiente possível. No entanto, são uso de recursos, e a natureza orientada a conjunto do SQL pode torná-los aparecer ineficiente. Não grau de inteligência de otimização pode eliminar o custo de recurso inerente dessas construções. Eles são intrinsecamente caros quando comparado a uma consulta mais simples. Embora SQL Server irá usar o plano mais otimizado de acesso, isso é limitado por que é fundamentalmente possível.

Por exemplo:
  • Conjuntos de resultados grande
  • IN, não IN e/ou consultas
  • Cláusulas WHERE altamente não-exclusivos
  • ! = Operadores de comparação (não igual)
  • Determinadas funções de coluna, como soma
  • Conversões de dados ou expressões na cláusula WHERE
  • Variáveis locais na cláusula WHERE
  • Modos de exibição complexos com GROUP BY
Vários fatores podem exigir o uso de alguns essas construções de consulta. O impacto desses irá ser diminuído se o otimizador pode restringir o conjunto antes de aplicar a parte de recurso intensivo da consulta de resultados. A seguir estão alguns exemplos.

Uso intensivo de recursos:
   SELECT SUM(SALARY) FROM TABLE
				

Menos recursos intensivos:
   SELECT SUM(SALARY) FROM TABLE WHERE
   ZIP='98052'
				

Uso intensivo de recursos:
   SELECT * FROM TABLE WHERE
   LNAME=@VAR
				

Menos recursos intensivos:
   SELECT * FROM TABLE
   WHERE LNAME=@VAR AND ZIP='98052'
				

No primeiro exemplo, a operação de soma não pode ser acelerada com um índice. Cada linha deve ser lido e somada. Supondo que haja um índice na coluna ZIP, o otimizador provavelmente usará para restringir o conjunto antes de aplicar a soma de resultados inicialmente. Isso pode ser muito mais rápido.

No segundo exemplo, a variável local não for resolvida até o tempo de execução. No entanto, o otimizador não pode adiar a opção de plano de acesso até o tempo de execução; ele deve escolher em tempo de compilação. Ainda em tempo de compilação, quando o plano de acesso é criado, o valor de @ VAR não é conhecido e conseqüentemente não pode ser usado como entrada a seleção de índice.

A técnica ilustrada para melhoria envolve restringir o conjunto com uma cláusula e de resultados. Como uma técnica alternativa, use um procedimento armazenado e passar o valor de @ VAR como um parâmetro para o procedimento armazenado.

Em alguns casos é melhor usar um grupo de consultas simples usando tabelas temporárias para armazenar os resultados intermediários que usar uma única consulta muito complexa.

Conjuntos de resultados grande são caros na maioria dos RDBMSs. Você deve tentar não retornar um resultado grande definido para o cliente para seleção de dados final por navegação. É muito mais eficiente para restringir o tamanho do conjunto de resultados, permitindo que o sistema de banco de dados para executar a função para o qual foi criada. Isso também reduz a E/s de rede e torna o aplicativo mais aberta para a implantação em links de comunicação remota lentos. Ele também melhora o desempenho relacionados à simultaneidade como o aplicativo é dimensionado para cima para mais usuários.

Use o design de aplicativo eficiente

A função que o design de aplicativo exerce no desempenho do SQL Server não pode ser exagerada. Em vez de imagem o servidor na função dominante, é mais precisa para o cliente de imagem como uma entidade de controle e o servidor como um puppet do cliente. SQL Server está totalmente sob o comando do cliente sobre o tipo de consultas, quando eles são enviados e como os resultados são processados. Isso por sua vez tem um efeito principal sobre o tipo e a duração de bloqueios, quantidade de carga de E/s e CPU no servidor, e, portanto, se desempenho é boa ou ruim.

Por esse motivo, é importante tomar as decisões corretas na fase de design de aplicativo. No entanto, mesmo se você enfrentar um problema de desempenho usando um aplicativo fechado onde parecem impossíveis alterações para o aplicativo cliente, isso não altera os fatores fundamentais que afetam o desempenho - não saber que o cliente desempenha uma função dominante e muitos problemas de desempenho pode ser resolvido sem fazer alterações de cliente.

Com um aplicativo bem projetado, o SQL Server é capaz de oferecer suporte a milhares de usuários simultâneos. Com um aplicativo mal criado, mesmo a mais poderosa plataforma de servidor pode sobrecarrega com apenas alguns usuários.

Usando as seguintes sugestões para design de aplicativo cliente irá fornecer bom desempenho do SQL Server:
  • Use conjuntos de resultados pequeno. Recuperar resultado desnecessariamente grande define (por exemplo, milhares de linhas) para navegar no cliente adiciona CPU e rede carga de E/s, torna o aplicativo menos capaz de utilização remota e pode limitar o desempenho multiusuário. É melhor para o aplicativo para solicitar ao usuário entrada suficiente para que sejam de consultas enviadas que gerar conjuntos de resultados modestos de design.

    Técnicas de design de aplicativo que facilitam isso incluem limitando o uso de curingas quando criar consultas, obrigar o uso de certos campos de entrada e proibindo improvised consultas.
  • Use dbcancel() corretamente em aplicativos de biblioteca de banco de dados. Todos os aplicativos devem permitir cancelamento de uma consulta em andamento. Nenhum aplicativo deve forçar o usuário reinicie o computador cliente para cancelar uma consulta. Não seguir esse princípio pode levar a problemas de desempenho que não podem ser resolvidos. Quando dbcancel() é usado, cuidado apropriado deve ser exerceu em relação ao nível de transação. Para obter informações adicionais, consulte o seguinte artigo na Base de dados de Conhecimento da Microsoft:
    117143: INF: quando e como usar dbcancel() ou sqlcancel()
    Os mesmos problemas se aplica a ODBC aplicativos, se a chamada de sqlcancel() ODBC for usada.
  • Sempre processa todos os resultados para conclusão. Não criar um aplicativo ou usar um aplicativo fechado que interrompe o processamento linhas de resultado sem cancelar a consulta. Isso geralmente será levar a desempenho lento e bloqueio.
  • Sempre implemente um tempo limite da consulta. Não permita consultas a serem executadas indefinidamente. Tornar a biblioteca de banco de dados apropriada ou chamadas ODBC para definir um tempo limite da consulta. Na biblioteca de banco de dados, isso é feito com a chamada dbsettime() e no ODBC com SQLSetStmtOption().
  • Não use uma ferramenta de desenvolvimento de aplicativo que não permite o controle explícito sobre as instruções SQL enviadas para o servidor. Não use uma ferramenta que gera transparente instruções SQL com base em objetos de nível superiores, a menos que ele fornece recursos essenciais, como consulta cancelamento, tempo limite da consulta e transacional de controle total. Geralmente não é possível para manter o bom desempenho ou para resolver um problema de desempenho se o aplicativo por si só gera "transparente SQL", porque isso não permite controle explícito sobre transacional e bloquear problemas que são críticos para a imagem de desempenho.
  • Não combinar transações on-line processando consultas (OLTP) e suporte à decisão.
  • Não criar um aplicativo ou usar um aplicativo fechado que força o usuário reinicie o computador cliente para cancelar uma consulta. Isso pode causar uma variedade de problemas de desempenho que são difíceis de resolver devido a possíveis conexões órfãos. Para obter mais informações, consulte o seguinte artigo na Base de dados de Conhecimento da Microsoft:
    137983: como solucionar problemas de órfão conexões no SQL Server

Técnicas para analisar o desempenho lento

Pode ser tentador para resolver um problema de desempenho exclusivamente pelo ajuste de desempenho do servidor de nível do sistema. Por exemplo, a quantidade de memória, o tipo de sistema de arquivos, o número e tipo de processadores e assim por diante. A experiência de suporte do Microsoft SQL Server mostra que a maioria dos problemas de desempenho não podem ser resolvidos dessa maneira. Eles deverão ser endereçados analisando o aplicativo, as consultas que o aplicativo está enviando para o banco de dados, e como essas consultas interagem com o esquema de banco de dados.

Primeiro, isole a consulta ou consultas que são lentas. Muitas vezes parece que um aplicativo inteiro é lento, quando apenas algumas das consultas SQL são lentas. Geralmente não é possível resolver um problema de desempenho sem dividindo o problema e isolar as consultas lentas. Se você tiver uma ferramenta de desenvolvimento que gera transparente SQL, use qualquer diagnóstico disponível ou o modo de depuração dessa ferramenta para capturar o SQL gerado. Em muitos casos recursos de rastreamento estão disponíveis, mas eles podem não ser abertamente documentados. Procure o suporte técnico para o seu aplicativo determinar se existe um recurso de rastreamento para monitorar as instruções SQL geradas pelo aplicativo.

Para ferramentas de desenvolvimento de aplicativo que usam SQL incorporado, isso é muito mais fácil - o SQL é abertamente visível.

Se seu aplicativo de usuário final ou ferramenta de desenvolvimento não fornecer um recurso de rastreamento, há várias alternativas:
  • Usar o sinalizador do rastreamento 4032 de acordo com as instruções no SQL Server 4.2 x "Troubleshooting Guide" e o SQL Server 6.0 "Referência Transact-SQL". Isso permitirá que captura das instruções SQL enviadas para o servidor no log de erro de SQL.
  • Monitorar as consultas por meio de um analisador de rede, como Microsoft Network Monitor, que é parte do Systems Management Server.
  • Para aplicativos de ODBC, use o programa Administrador ODBC para selecionar o rastreamento de chamadas ODBC. Consulte a documentação do ODBC para obter mais detalhes.
  • Use um utilitário do cliente de terceiros que intercepta o SQL em camadas a biblioteca do banco de dados ou ODBC. Um exemplo disso é SQL Inspector da Software Lagoon azul.
  • Use a ferramenta de análise SQLEye fornecida como um exemplo no CD do Microsoft TechNet. Observação: Não há suporte para SQLEye pelo suporte técnico da Microsoft.
Depois que a consulta lenta for isolada, faça o seguinte:
  • Executar a consulta lenta suspeita isoladamente, usando uma ferramenta de consulta, como ISQL e verifique se está lenta. Geralmente é melhor executar a consulta no próprio computador servidor usando ISQL e pipes locais e redirecione a saída para um arquivo. Isso ajuda a eliminar complicação fatores, como rede e E/s de tela e buffer de resultado do aplicativo.
  • Use SET STATISTICS E/S para examinar a E/s consumidos pela consulta. Observe a contagem de E/s de página lógica. Objetivo do otimizador é minimizar a contagem de E/s. Tornar um registro da contagem de E/s lógico. Isso forma uma linha de base contra a qual medir melhoria. Geralmente é mais eficaz para se concentrar exclusivamente na saída STATISTICS E/S e experimentar diferente consulta e índice tipos que usar SET SHOWPLAN ON. Interpretar e aplicar efetivamente a saída do SHOWPLAN podem exigir algumas estudar e podem consumir o tempo que pode ser gasto com mais eficiência em testes empíricas. Se o problema de desempenho não é fixo por essas recomendações simples, você poderá usar SHOWPLAN para investigar mais minuciosamente otimizador comportamento.
  • Se a consulta envolver um modo de exibição ou procedimento armazenado, extrair o modo de exibição ou procedimento armazenado a consulta e executá-lo separadamente. Isso permite que o plano de acesso Alterar como você experimentar diferentes índices. Ele também ajuda a localizar o problema para a consulta, versus como o otimizador manipula os modos de exibição ou procedimentos armazenados. Se o problema não estiver na consulta propriamente dita, mas somente quando a consulta é executada como parte de um modo de exibição ou procedimento armazenado, executar a consulta por si só ajudará a determinar isso.
  • Esteja ciente dos possíveis disparadores nas tabelas envolvidas que transparente podem gerar E/s conforme o disparador é executado. Você deve remover os disparadores envolvidos em uma consulta lenta. Isso ajuda a determinar se o problema está na consulta propriamente dito ou no disparador ou modo de exibição e, portanto, ajuda a direcionar o foco.
  • Examine os índices de tabelas usados pela consulta lenta. Use as técnicas listadas anteriormente para determinar se eles estão boas índices e, altere-as se necessário. Como um esforço primeiro, tente indexação cada coluna na sua cláusula WHERE. Problemas de desempenho geralmente são causados por simplesmente não ter uma coluna na cláusula WHERE indexada ou por não ter um índice úteis sobre como uma coluna.
  • Usando consultas mencionadas anteriormente, examine a exclusividade de dados e a distribuição para cada coluna mencionado na cláusula WHERE e especialmente para cada coluna indexada. Em muitos casos simples inspeção da consulta, tabela, índices e dados mostrará imediatamente a causa do problema. Por exemplo, problemas de desempenho são geralmente causados por ter um índice em uma chave com apenas três ou quatro valores exclusivos, ou executando um JOIN em uma coluna ou retornar um número excessivo de linhas para o cliente.
  • Com base neste estudo, faça as alterações necessárias ao aplicativo, consulta ou índices. Executar a consulta novamente após a alteração e observar qualquer alteração na contagem de E/s.
  • Depois de observar o aperfeiçoamento, execute o aplicativo principal para ver se o desempenho geral é melhor.
Verifique o programa para o comportamento ligados a CPU ou E/s. Geralmente é útil determinar se uma consulta é vinculada à CPU ou E/s. Isso ajuda a concentrar seus esforços de melhoria no gargalo true. Por exemplo, se uma consulta estiver vinculada à CPU, adicionando que mais memória para o SQL Server provavelmente não irá melhorar o desempenho, porque mais memória melhora o cache somente taxa de acertos, que nesse caso, já está alta.

Como examinar o comportamento de E/s versus vinculados à CPU consulta:
  • Use o Monitor de desempenho do Windows NT para inspeção E/s versus atividade da CPU. Observe todas as instâncias do contador de "% tempo de disco" do LogicalDisk objeto. Também observe o "total de % tempo do processador" contador do sistema objeto. Para ver informações de desempenho de disco válido, você deve ter anteriormente ativado a configuração do Windows NT DISKPERF emitindo "diskperf -Y" de um prompt de comando e, em seguida, reinicializar o sistema. Consulte a documentação do Windows NT para obter mais detalhes.
  • Ao executar a consulta, se o gráfico de CPU é consistentemente alto (por exemplo, maior a 70 por cento) e o valor de "% tempo de disco" é consistentemente baixo, isso indica um estado vinculados à CPU.
  • Ao executar a consulta, se o gráfico de CPU é consistentemente baixo (por exemplo, menor que 50 por cento) e "% tempo de disco" é consistentemente alto, isso indica que uma E/s vinculado estado.
  • Compare o gráfico de CPU com as informações de E/S STATISTICS.

Conclusão

SQL Server é capaz de desempenho muito alto em grandes bancos de dados. Isso é especialmente o caso com o SQL Server 6.0. Para obter esse potencial de desempenho, você deve usar banco de dados eficiente, índice, consulta e design de aplicativo. Essas áreas estão os melhores candidatos para obtenção de melhoria de desempenho significativos. Tente fazer cada consulta tão eficiente quanto possível, para que, quando seu aplicativo se adapta a mais usuários, a carga de multiusuário coletiva com suporte. Estudo do comportamento do aplicativo cliente, as consultas enviadas pelo aplicativo e experimentação com índices usando as diretrizes neste documento são altamente incentivados. Uma abordagem metódica na análise de problemas de desempenho geralmente produzirá melhoria significativa para relativamente pouco investimento de tempo.

Propriedades

ID do artigo: 110352 - Última revisão: terça-feira, 22 de fevereiro de 2005 - Revisão: 3.1
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Palavras-chave: 
kbmt kbinfo kbother KB110352 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 110352
Aviso de Isenção de Responsabilidade sobre Conteúdo do KB Aposentado
Este artigo trata de produtos para os quais a Microsoft não mais oferece suporte. Por esta razão, este artigo é oferecido "como está" e não será mais atualizado.

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com