INF: Optimizar o desempenho do Microsoft SQL Server

Traduções de Artigos Traduções de Artigos
Artigo: 110352 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Nesta página

Sumário

Para optimizar o desempenho do Microsoft SQL Server mais eficaz, tem de identificar as áreas que irão produzir o maior aumenta de desempenho sobre a maior variedade de situações e concentrar-se análise estas áreas. Caso contrário, poderá gastar significativo tempo e esforço tópicos poderão não ter melhoramentos dimensionáveis.

Na maior parte dos casos, as seguintes informações não corrige os problemas de desempenho radicais de concorrência multi-utilizador. Este é um tópico separado e complexo que é descrito no documento "Maximizar da base de dados de consistência e concorrência," que pode ser encontrada no SQL Server versão 4.2 x "Reference para programadores de C," E de apêndice e também nos outros artigos da base de dados de conhecimento. Não é na documentação da versão 6.0, mas podem ser encontrado no CD da MSDN (Microsoft Developer Network) sob esse título.

Em vez de um debate teórico, este artigo foca principalmente áreas que demonstraram anos de experiência pela equipa de suporte da Microsoft SQL Server seja prático valor situações do mundo real.

Experiência mostra que a maior no desempenho do SQL Server pode ser vantagem as áreas de estrutura da consulta, estrutura de índice, estrutura de base de dados lógico e concepção de aplicações gerais. Por outro lado, os problemas de desempenho maiores são normalmente provocados por deficiencies nestas áreas mesmo. Se se estiver preocupado com o desempenho, deve concentrar estas áreas em primeiro lugar, porque melhoramentos de desempenho muito grande, muitas vezes, podem ser obtidos com um investimento relativamente pequeno de tempo.

Enquanto outro desempenho de nível do sistema problemas, tais como memória, memórias intermédias da cache, hardware e por aí em diante, certamente são candidatos para estudo, experiência mostra que o aumento de desempenho destas áreas frequentemente incremental. SQL Server gere recursos de hardware disponíveis automaticamente, na maior parte dos casos, reduzindo a necessidade (e assim, a vantagem) de optimização da extensa mão de nível do sistema.

Microsoft SQL Server 6.0 fornece novas oportunidades para plataforma camada melhoramentos de desempenho, com grandes quantidades de memória, multi-processamento simétrico, paralela dados análise, melhoramentos de optimização e repartição do disco. No entanto, tão grande que estes melhoramentos, são finita no âmbito. O computador mais rápido pode ser bogged para baixo com consultas ineficaz ou uma aplicação mal concebida. Assim, mesmo com o aumento de desempenho adicionais que permite o SQL Server 6.0, é extremamente importante para optimizar a base de dados, índice, consulta e concepção de aplicações.

A maior parte 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 as consultas são enviadas, e assim que bloqueios são obtidos e libertados. Embora alguns optimização seja possível do lado do servidor, com êxito resolução de problemas de desempenho normalmente dependerá confirmar que a função dominante o cliente é reproduzido no problema e analisar o comportamento da aplicação cliente.

Mais Informação

Seguem-se algumas sugestões que, com base em detectar, ter produziu ganhos de desempenho significativos:

Normalizar estrutura de base de dados lógica

Normalização razoável da estrutura de base de dados lógico produz melhor desempenho. Um número maior de tabelas estreitos é característica de uma base de dados normalizada. Um número inferior de largura de tabelas é característica de uma base de dados não normalizado. Uma base de dados altamente normalizado associada regularmente complexas associações relacionais, podem hurt desempenho. No entanto, o optimizador do SQL Server é muito eficiente em seleccionar associações rápidas e eficazes, desde que eficaz índices estão disponíveis.

Os benefícios de normalização incluem:
  • Acelera a criação de ordenação e o índice, uma vez que tabelas são mais estreitos.
  • Permite mais índices agrupados, uma vez que existem mais tabelas.
  • Índices tendem a ser mais estreita e mais compacta.
  • Menos índices por tabela, ajudando UPDATE desempenho.
  • Menos NULL e dados menos redundantes, aumentar compactness de base de dados.
  • Reduz o impacto de concorrência de diagnóstico do DBCC, uma vez que os bloqueios tabela necessário afectará menos dados.
Com o SQL Server, frequentemente normalização razoável ajuda-o em vez de desempenho hurts. Como normalização aumenta, por isso, execute o número e a complexidade de associações necessário para obter dados. Como um incompleto princípio, a Microsoft sugere executar sobre o processo de normalização, a menos que este faz com que várias consultas para que as associações de quatro pontas ou superior.

Se a estrutura de base de dados lógico já está fixa e total redefinição não é possível, poderá ser possível selectivamente normalizar uma tabela grande se análise mostra um congestionamento nesta tabela. Se acesso a base de dados é efectuado através de procedimentos armazenados, esta alteração de esquema foi efectuada sem afectar as aplicações. Caso contrário, poderá ser possível ocultar a alteração ao criar uma vista semelhante a uma única tabela.

Utilizar estrutura eficiente de índice

Ao contrário de muitos sistemas não relacionais, índices relacionais não são considerados parte da estrutura de base de dados lógico. Os índices podem ser ignorados, adicionados e alterados sem afectar a estrutura de esquema ou aplicação de base de dados de qualquer forma diferente de desempenho. Estrutura de índice eficiente é extrema em alcançar o bom desempenho do SQL Server. Hesite por estas razões, deverá não em experimentar diferentes índices.

O Optimizador de forma fiável escolhe o índice mais eficaz na maioria dos casos. A estratégia de estruturação índice global deve ser fornecem uma boa selecção de índices para o optimizador e confiar que tomar a decisão para a direita. Isto reduz o tempo de análise e proporciona bom desempenho através de uma grande variedade de situações.

Seguem-se recomendações de estrutura do índice:
  • Examine a cláusula WHERE das consultas SQL, porque este é o objectivo principal o optimizador.

    Cada coluna listada na cláusula WHERE é um candidato possível para um índice. Se tiver demasiadas consultas para examinar, escolha um conjunto representativo ou apenas aqueles lentas. Se a ferramenta de desenvolvimento de forma transparente gerar código SQL, isto é mais difícil. Muitas destas ferramentas permitem o registo da sintaxe de SQL gerado para um ficheiro ou ecrã para fins de depuração. Convém saber do fornecedor da ferramenta, se tal funcionalidade está disponível.
  • Utilize índices estreitos.

    Índices estreitos são muitas vezes mais eficaz de índices de várias colunas, compostos. Índices estreitos têm mais linhas por página e menos níveis de índice, aumentando o desempenho.

    O optimizador pode rapidamente e eficaz analisar centenas ou mesmo milhares de índice e associação possibilidades. Ter um maior número de índices estreitos fornece o optimizador com mais possibilidades de escolha, que normalmente ajuda-o desempenho. A existência de menos índices de várias colunas, largas permite o optimizador com menos possibilidades à escolha, que poderá hurt desempenho.

    Recomenda-se muitas vezes, não adoptar uma estratégia de realçando uma consulta totalmente coberta. É verdade que se todas as colunas a cláusula SELECT estão cobertas por um índice não agrupado, o optimizador pode reconhecer este e fornece muito bom desempenho. No entanto, este frequentemente resulta em índices demasiado grande e depende demasiado a possibilidade de que o optimizador utilizará esta estratégia. Normalmente, deve utilizar mais vários índices estreitos que muitas vezes, fornecem um melhor desempenho um intervalo maior de consultas.

    Não deve ter mais índices não são necessários para alcançar um desempenho de leitura adequado devido a sobrecarga envolvida na actualizar os índices. No entanto, ainda mais operações orientados para actualização necessitam de ler muito mais do que escrever. Hesite por este motivo, não em tentar um novo índice se pensa irá ajudar; é possível sempre colocar mais tarde.
  • Utilize índices em cluster.

    Uso adequado do cluster índices tremendously pode aumentar o desempenho. Operações mesmo UPDATE e DELETE são frequentemente aceleradas por índices agrupados, uma vez que estas operações requerem muito leitura. É permitido um único índice agrupado por tabela, por isso, utilize wisely este índice. Consultas que devolvam várias linhas ou consultas que envolvem um intervalo de valores, são bons candidatos para aceleração por um índice agrupado.

    Exemplos:
          SELECT * FROM PHONEBOOK
          WHERE LASTNAME='SMITH'
    
          -or-
    
          SELECT * FROM MEMBERTABLE
          WHERE  MEMBER_NO > 5000
           AND MEMBER_NO < 6000
    
    						
    Pelo contrário, as colunas Apelido ou MEMBER_NO mencionadas provavelmente não são bons candidatos para um índice não agrupado se este tipo de consulta comum. Tente utilizar índices não agrupados em colunas em que algumas linhas são devolvidas.
  • Verificar exclusividade de coluna.

    Isto ajuda a decidir que a coluna é um candidato para nenhum índice, índice não agrupado ou um índice agrupado.

    Segue-se uma consulta de exemplo para verificar exclusividade de coluna:
          SELECT COUNT (DISTINCT COLNAME)
          FROM TABLENAME
    
    						
    Isto devolve o número de valores exclusivos na coluna. Comparar com o número total de linhas na tabela. Numa tabela 10.000 linhas, 5.000 valores exclusivos faria a coluna um bom candidato para um índice não agrupado. Na mesma tabela, 20 valores exclusivos seriam adequar um índice agrupado. Não devem ser indexados em todos os três valores exclusivos. Estes são apenas exemplos, não regras de disco rígidos e rápidas. Lembre-se colocar os índices as colunas individuais nas cláusulas WHERE das consultas.
  • Examine a distribuição de dados em colunas indexadas.

    Muitas vezes uma consulta de execução longa ocorre porque uma coluna com valores únicos alguns é indexada, ou um JOIN nessa coluna é efectuada. Este é um problema com os dados e própria consulta fundamental e normalmente não pode ser resolvido sem que identifica esta situação. Por exemplo, um directório de telefone físico, ordenado por ordem alfabética no último nome irá não acelerar procurar uma pessoa se todas as pessoas na cidade são o nome "Silva" ou "Silva". Em conjunto com a consulta acima, que fornece um único valor de exclusividade de coluna, pode utilizar uma consulta de GROUP BY para ver a distribuição de dados de valores da chave indexados. Isto fornece uma imagem de resolução superior dos dados e uma melhor perspectiva de como o optimizador visualiza os dados.

    Segue-se um exemplo de consulta para examinar a distribuição de dados de valores chaves indexadas, assumindo uma chave de duas colunas COL1, COL2:
          SELECT COL1, COL2, COUNT(*)
          FROM TABLENAME
          GROUP BY COL1, COL2
    
    						
    Isto irá devolver uma linha para cada valor da chave, com uma contagem de instâncias de cada valor. Para reduzir o número de linhas devolvidas, poderá ser útil excluir alguns com uma cláusula HAVING. Por exemplo, a cláusula
          HAVING COUNT(*) > 1
    
    						
    irá excluir todas as linhas que têm uma chave exclusiva.

    O número de linhas devolvidas numa consulta também é um factor importante na selecção de índice. O optimizador considera um índice não agrupado para custos, pelo menos, uma página E/s por linha devolvida. Esta velocidade rapidamente torna mais eficiente para verificar se a tabela inteira. Esta é outra razão para restringir o tamanho do conjunto de resultados ou para localizar o resultado de grandes dimensões com um índice agrupado.
Utilização de índice com bom desempenho e o inverso não equivale sempre. Se utilizar sempre um índice produzido o melhor desempenho, tarefa o optimizador seria muito simples - utilizar sempre qualquer índice disponível. Na realidade, escolha incorrecta de obtenção indexada pode resultar num desempenho muito incorrecto. Assim tarefa o optimizador consiste em seleccionar indexada obtenção onde irá ajudar o desempenho e evitar obtenção indexada onde ele irá hurt desempenho.

Utilizar a estrutura da consulta eficiente

Alguns tipos de consultas são inerentemente consome muitos recursos. Isto está relacionado com a base de dados fundamental e índice problemas comuns para a maior parte dos sistemas de gestão da base de dados relacionais (RDBMSs), não se tratarem especificamente para o SQL Server. Não são ineficaz, porque o optimizador irá implementa as consultas da forma mais eficaz possível. No entanto, são consome muitos recursos e à natureza orientados para conjunto SQL poderá torná-los aparecer ineficaz. Não grau de análise de optimização pode eliminar o custo de recurso inerentes destes construções. São intrinsecamente dispendiosas quando comparado com uma consulta mais simples. Apesar do SQL Server irá utilizar o plano de acesso mais ideal, isto é limitado pelo que é fundamentalmente possível.

Por exemplo:
  • Conjuntos de resultados de grandes dimensões
  • IN, NOT IN, e ou consultas
  • Cláusulas WHERE altamente não exclusivas
  • ! = Operadores de comparação (não igual)
  • Determinadas funções de coluna, tais como soma
  • Conversões de dados ou expressões na cláusula WHERE
  • Variáveis locais na cláusula WHERE
  • Vistas complexas com GROUP BY
Vários factores poderão obrigam a utilização de algumas destas construções de consulta. O impacto de estas irão ser lessened se o optimizador pode restringir o conjunto antes de aplicar recursos intensiva parte da consulta de resultados. Seguem-se alguns exemplos.

Que consome muitos recursos:
   SELECT SUM(SALARY) FROM TABLE
				

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

Que consome muitos recursos:
   SELECT * FROM TABLE WHERE
   LNAME=@VAR
				

Menos recursos intensiva:
   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 lida e somada. Partindo do princípio que existe um índice na coluna ZIP, o optimizador provavelmente vai utilizar isto para inicialmente restringir o conjunto antes de aplicar a soma dos resultados. Este processo pode ser muito mais rápido.

No segundo exemplo, a variável local não é resolvida quando executar. No entanto, o optimizador não é possível adiar a escolha do plano de acesso quando executar; tem de escolher durante a compilação. Ainda durante a compilação, quando é criado o plano de acesso, o valor de @ VAR não é conhecido e consequentemente não pode ser utilizado como entrada para selecção de índice.

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

Em alguns casos é melhor utilizar um grupo de consultas simples utilização de tabelas temporárias para armazenar os resultados intermédios que para utilizar uma única consulta muito complexa.

São dispendiosos no RDBMSs a maior parte dos conjuntos de resultados de grandes dimensões. Deve tentar não devolver um conjunto para o cliente para selecção de dados final efectuando uma procura de resultados grande. É muito mais eficiente para restringir o tamanho do conjunto de resultados, permitindo que o sistema de base de dados para executar a função para o qual foi concebido. Isto também reduz a E/s de rede e faz com que a aplicação mais amenable para implementação em ligações de comunicação remota lenta. Também melhora o desempenho relacionados com a concorrência como a aplicação pode ser dimensionado para cima a mais utilizadores.

Utilizar eficiente concepção de aplicações

A função que desempenha concepção de aplicações no desempenho do SQL Server não pode ser overstated. Em vez de imagem o servidor a função dominante, é mais preciso para o cliente de imagens como uma entidade de controlo e o servidor como um puppet do cliente. SQL Server é totalmente em comandos do cliente sobre o tipo de consultas, quando estes são submetidos e como os resultados são processados. Tem um efeito principal no tipo e duração de bloqueios, quantidade de carga de E/s e CPU no servidor, por sua vez e, por isso, se desempenho é bom ou mau.

Por este motivo, é importante tomar as decisões correctas durante a fase de concepção de aplicação. No entanto, mesmo se enfrentar um problema de desempenho utilizando uma chave na mão de fabricantes aplicação onde as alterações à aplicação cliente parecerem impossíveis, isto não altera os factores fundamentais que afectam o desempenho - nomeadamente que o cliente desempenha uma função dominante e muitos problemas de desempenho não pode ser resolvido sem efectuar alterações de cliente.

Com uma aplicação bem concebida, SQL Server é capaz de suportar milhares de utilizadores em simultâneo. Com uma aplicação mal concebida, mesmo a mais poderosa plataforma de servidor pode bog para baixo com apenas alguns utilizadores.

Utilizar as seguintes sugestões para concepção de aplicações cliente fornecerá o bom desempenho do SQL Server:
  • Utilize conjuntos de resultados pequeno. Obter resultados desnecessariamente grandes define (por exemplo, milhares de linhas) para navegar no cliente adiciona a carga de E/s da CPU e da rede, faz com que a aplicação menor capacidade de utilização remota e pode limitar a escalabilidade multi-utilizador. É aconselhável a aplicação para pedir ao utilizador entrada suficiente para que as consultas sejam submetidos qual gerar conjuntos de resultados modesto de estrutura.

    Técnicas de estrutura de aplicação que facilitam esta incluem limitar a utilização de caracteres universais quando criar consultas, mandating determinados campos de entrada e proibindo improvised consultas.
  • Utiliza dbcancel() correctamente nas aplicações de biblioteca de base de dados. Todas as aplicações devem permitir o cancelamento de uma consulta em curso. Nenhuma aplicação deverá forçar o utilizador para reiniciar o computador cliente para cancelar uma consulta. Não seguir este princípio pode resultar em problemas de desempenho não podem ser resolvidos. Quando dbcancel() é utilizado, deve ser exercido cuidado correcto relativamente ao nível de transacção. Para obter informações adicionais, consulte o seguinte artigo na base de dados de conhecimento da Microsoft:
    117143: INF: quando e como utilizar dbcancel() ou sqlcancel()
    Os mesmos problemas se aplica a aplicações de ODBC, se a chamada de sqlcancel() ODBC é utilizada.
  • Processa sempre todos os resultados para conclusão. Não criar uma aplicação ou utilizar uma aplicação chave na mão de fabricantes que pára de processar linhas de resultados sem cancelar a consulta. Se o fizer, normalmente resultará bloqueio e lento desempenho.
  • Implemente sempre um tempo limite de consulta. Não permita que as consultas para ser executada indefinidamente. Torne a biblioteca de base de dados apropriada ou chamadas de ODBC para definir um tempo limite de consulta. Na biblioteca de base de dados, isto é feito com a chamada dbsettime() e de ODBC com SQLSetStmtOption().
  • Não utilize uma ferramenta de desenvolvimento de aplicações que não permite explícito controlo sobre as instruções SQL enviadas para o servidor. Não utilize uma ferramenta de forma transparente gera instruções de SQL com base nos objectos de nível superiores, a menos que fornece funcionalidades cruciais tal como cancelamento de consulta, tempo limite de consulta e controlo total de transacções. Muitas vezes não é possível para manter o bom desempenho ou para resolver um problema de desempenho se a aplicação tudo isoladamente gera "SQL transparente", uma vez que este não permite explícito controlo transaccional e bloquear problemas que são críticas para a imagem de desempenho.
  • Não intermix suporte de decisões e processamento de consultas (OLTP) de transacções online.
  • Não criar uma aplicação ou utilizar uma aplicação chave na mão de fabricantes que força o utilizador para reiniciar o computador cliente para cancelar uma consulta. Isto pode causar uma variedade de problemas de desempenho que são difíceis de resolver devido a possíveis ligações isoladas. Para mais informações, consulte o seguinte artigo na base de dados de conhecimento da Microsoft:
    137983: como resolver problemas de ligações isoladas no SQL Server

Técnicas para analisar o desempenho lento

Poderá ser tempting para resolver um problema de desempenho exclusivamente pelo optimização do desempenho do servidor de nível do sistema. Por exemplo, a quantidade de memória, o tipo de sistema de ficheiros, o número e tipo de processadores e assim sucessivamente. A experiência de suporte da Microsoft SQL Server demonstraram que a maior parte dos problemas de desempenho não podem ser resolvidos desta forma. Devem ser endereçadas ao analisar a aplicação, as consultas a aplicação é submeter para a base de dados e como estas consultas interagem com o esquema de base de dados.

Em primeiro lugar, isole a consulta ou consultas que são lentas. Muitas vezes parece que toda uma aplicação é lenta, quando apenas algumas das consultas SQL são lentas. Normalmente, não é possível resolver um problema de desempenho sem analisar o problema e isolar as consultas lentas. Se tiver uma ferramenta de desenvolvimento que forma transparente gera SQL, utilize qualquer modo de depuração desta ferramenta de diagnóstico disponível ou para capturar o SQL gerado. Em muitos casos rastreio funcionalidades estão disponíveis mas poderão não ser openly documentados. Contacte o suporte técnico para a aplicação determinar se existe uma funcionalidade de rastreio para monitorizar as instruções de SQL geradas pela aplicação.

Para ferramentas de desenvolvimento de aplicações utilizá-la incorporado, isto é muito mais fácil - o SQL é openly visível.

Se a aplicação de desenvolvimento ferramenta ou o utilizador final não fornecer uma funcionalidade de rastreio, existem várias alternativas:
  • Utilizar o sinalizador de rastreio 4032 acordo com para as instruções apresentadas no SQL Server 4.2 x "Troubleshooting Guide" e o SQL Server 6.0 "Transact SQL Reference". Isto permitirá a captura das instruções SQL enviadas para o servidor no registo de erros SQL.
  • Monitorizar as consultas através de um analisador de rede, tais como Microsoft Network Monitor, que faz parte do Systems Management Server.
  • Para aplicações de ODBC, utilize o programa de administrador de ODBC para seleccionar o rastreio de chamadas de ODBC. Consulte a documentação de ODBC para obter mais detalhes.
  • Utilize um utilitário lado do cliente de outros fabricantes que intercepta o SQL com as camadas de biblioteca de base de dados ou ODBC. Um exemplo é o inspector de SQL da azul Lagoon Software.
  • Utilize a ferramenta de análise SQLEye fornecida como um exemplo no CD do Microsoft TechNet. NOTA: SQLEye não é suportada pelo suporte técnico da Microsoft.
Depois da consulta lenta isolada, efectue o seguinte:
  • Executar a consulta lenta suspeita de isolamento, utilizando uma ferramenta de consulta como ISQL e verifique se está lenta. Recomenda-se frequentemente a executar a consulta no computador servidor próprio utilizar ISQL e pipes locais e redireccione a saída para um ficheiro. Isto ajuda a eliminar complicating factores, tais como rede e E/s de ecrã e memória intermédia de resultado aplicação.
  • Utilize SET E/S STATISTICS ON para examinar a E/s consumidos pela consulta. Tenha em atenção o número de página lógica E/s. Objectivo o Optimizador é minimizar a contagem de E/s. Formam um registo da contagem de E/s lógico. Isto constitui um plano base com as quais medir o melhoramento. Muitas vezes é mais eficazes a focar exclusivamente a saída de E/S STATISTICS e fazer experiências com consulta diferentes e indexar tipos que para utilizar SET SHOWPLAN ON. Interpretar e aplicar eficazmente a saída de SHOWPLAN podem requerer algumas estudar e podem consumir tempo que pode ser uma forma mais eficaz gasto em testes empírica. Se o problema de desempenho não for resolvido por estas recomendações simples, pode utilizar SHOWPLAN mais exaustivamente investigar comportamento de optimização.
  • Se a consulta envolver uma vista ou procedimento armazenado, extraia a consulta a partir da vista ou procedimento armazenado e executá-lo separadamente. Isto permite que o plano de acesso alterar como experimentar diferentes índices. Também ajuda a localizar o problema à consulta, versus o modo como o optimizador processa vistas ou procedimentos armazenados. Se o problema não está na consulta próprio mas apenas quando a consulta é executada como parte de uma vista ou procedimento armazenado, executar a consulta por si só irá ajudá-determinar este procedimento.
  • Esteja atento a possíveis accionadores nas tabelas de envolvidos forma transparente podem gerar E/s como o accionador é executado. Deve remover quaisquer accionadores envolvidos na consulta lenta. Isto ajuda a determinar se o problema for na consulta propriamente dito ou no accionador ou vista e por este motivo, ajuda a direcciona o foco.
  • Examine os índices das tabelas utilizadas pela consulta lenta. Utilize as técnicas listadas anteriormente para determinar se estes são bons índices e alterá-los, se necessário. Como um esforço primeiro, tente indexar cada coluna a cláusula WHERE. Problemas de desempenho, muitas vezes, são provocados pela simplesmente não ter uma coluna numa cláusula WHERE indexada ou por não ter um índice útil nessa coluna.
  • Utilizar as consultas anteriormente mencionadas, 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 inspecção da consulta, tabela, índices e dados mostrará imediatamente a causa do problema. Por exemplo, problemas de desempenho são frequentemente causados por ter um índice numa chave com apenas três ou quatro valores únicos, ou efectuar um JOIN tal uma coluna ou devolver um número excessivo de linhas para o cliente.
  • Com base neste estudo, efectue as alterações necessárias à aplicação, consulta ou índices. Executar a consulta novamente depois de efectuar a alteração e observe a qualquer alteração na contagem de E/s.
  • Depois de anotar melhoramento, execute a aplicação principal para ver se o desempenho global é melhor.
Verifique se o programa de comportamento de E/s ou ligados à CPU. Muitas vezes é útil para determinar se uma consulta é E/s ou CPU dependente. Isto ajuda a concentrar os esforços de melhoramento congestionamento true. Por exemplo, se uma consulta for dependente da CPU, adicionar mais memória para o SQL Server provavelmente não vai melhorar o desempenho, uma vez que mais memória melhora apenas a cache de taxa de acertos, que neste caso, já é Alta.

A examinar o comportamento de E/s vs. ligados à CPU consulta:
  • Utilize Monitor de desempenho do Windows NT para monitorização E/s versus actividade de CPU. Ver todas as ocorrências do contador de "% tempo de disco" do disco lógico objecto. Ver também a "% total de tempo do processador" contador do sistema objecto. Para ver informações de desempenho disco válido, tem anteriormente activou a definição do Windows NT DISKPERF emitindo "diskperf -Y" de uma linha de comandos e, em seguida, reiniciar o sistema. Consulte a documentação do Windows NT para obter mais detalhes.
  • Enquanto executa a consulta, se o gráfico da CPU é consistentemente elevado (por exemplo, maior do que 70 por cento) e o valor de "% tempo de disco" é consistentemente baixo, isto indica um estado ligados à CPU.
  • Enquanto executa a consulta, se o gráfico da CPU é consistentemente baixo (por exemplo, inferior a 50 por cento) e "% tempo de disco" é consistentemente elevado, isto indica que um E/s dependente estado.
  • Compare o gráfico da CPU com as informações STATISTICS E/S.

Conclusão

SQL Server é capaz de muito alto desempenho em grandes bases de dados. Isto acontece especialmente com o SQL Server 6.0. Para obter este potencial de desempenho, tem de utilizar base de dados eficaz, índice, consulta e concepção de aplicações. Estas áreas são os melhores candidatos para obter melhoramentos de desempenho significativos. Tente efectuar cada consulta tão eficiente quanto possível, para que quando dimensiona a aplicação a mais utilizadores, a carga de vários utilizadores colectiva supportable. Estudo de comportamento da aplicação de cliente, as consultas submetidos pela aplicação e experimentação com índices utilizando as directrizes neste documento são fortemente encorajados. Uma abordagem metódico na análise de problemas de desempenho frequentemente produzirá melhoramento significativo relativamente pouco investimento tempo.

Propriedades

Artigo: 110352 - Última revisão: 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 revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática? erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 110352
Exclusão de Responsabilidade para Conteúdo sem Suporte na KB
Este artigo foi escrito sobre produtos para os quais a Microsoft já não fornece suporte. Por conseguinte, este artigo é oferecido "tal como está" e deixará de ser actualizado.

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