Como solucionar problemas de desempenho das consultas ad-Hoc no SQL Server

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

Neste artigo

Sumário

Este artigo descreve como solucionar o desempenho lento de muitas consultas ad-hoc simultâneas no Microsoft SQL Server. Se você não tiver determinado a origem precisa de seu problema, consulte o seguinte artigo na Base de dados de Conhecimento da Microsoft antes de continuar:
224587Como solucionar problemas de desempenho do aplicativo com o SQL Server

Este artigo presume que você usou 224587 KB para restringir o escopo do problema e que você tenha capturado um log do desempenho do sistema Windows NT e rastreamento de SQL Profiler que detalhes as colunas específicas de contadores, eventos e dados.

Características de problemas de desempenho

O problema de desempenho tem as seguintes características:
  • Consultas ad-hoc curto que normalmente têm uma duração muito curta resultar em desempenho geral lento do sistema quando um alto número de usuários simultâneos executar as consultas.
  • Muito alto ou 100 porcentagem uso da CPU.
  • Nenhum bloqueio associado durante os períodos de desempenho lento.

    Você pode procurar rapidamente por bloqueio verificando a coluna BLK a saída de sp_who procedimento armazenado do sistema. Se a coluna BLK não for zero para um número de processo do sistema identificações (SPIDs), existe está bloqueando.
  • Em algumas situações, estresse de memória do servidor e você pode receber erros semelhantes aos seguintes erros:
    Erro: 701, gravidade: 17, estado: 1
    Não há memória do sistema insuficiente para executar essa consulta.
    - ou -
    Msg 8645, nível 17, estado 1, linha 1, procedimento
    Tempo limite excedido ao aguardar recursos de memória executar a consulta. Execute a consulta novamente.

Melhorias na consulta compilações

Devido a aprimoramentos na arquitetura do sistema iniciando no SQL Server 7.0, especificamente o otimizador de consulta, você pode perceber uma diferença no uso de recursos de sistema por aplicativos em comparação comparados versões anteriores do SQL Server. Especificamente, o SQL Server 7.0 pode mostrar um aumento no uso de CPU ou memória, mas versões anteriores do SQL Server normalmente são disco E/S vinculado. Essas alterações podem ser rastreadas para dois fatores:
  • Junções de hash e mesclar
  • Tempo de compilação de consulta
Versões anteriores do SQL Server dependiam completamente iterações de loop aninhadas para realizar associações. Associações de loop aninhadas inerentemente use E/S de disco. Iniciando com o SQL Server 7.0, foram introduzidas junções de hash e mesclagem. Junções de hash e mesclagem fazer muito mais de memória de processamento de associações de loop aninhadas. O resultado lógico de isso é que CPU e uso de memória é maior quando essas técnicas de associação são usadas. Para obter mais informações sobre junções de hash e mesclar, consulte os tópicos "Noções básicas sobre relações de hash" e "Noções básicas sobre relações de mesclagem" nos manuais online do SQL Server 7.0.

Tempo de compilação de consulta é afetado porque o otimizador de consulta tem mais opções e informações disponíveis que em versões anteriores do SQL Server, incluindo novas técnicas de associação hash e mesclar, algoritmos de pesquisa aprimorado e estatísticas de coluna. Essa informação adicional permite que o otimizador de consulta para selecionar o método mais eficiente para recuperar dados de consulta. No entanto, a análise e consideração dessas novas técnicas e informações requer tempo de processamento. Essa maior utilização da CPU pode resultar em tempo de compilação consulta mais longas do que em versões anteriores do SQL Server.

Para a maioria das consultas, esse aumento no tempo de compilação é compensado por uma redução no tempo de execução. O efeito geral é que a consulta é executada mais rapidamente do que em versões anteriores do SQL Server. No entanto, ocorre uma exceção, com consultas de OLTP tipo muito pequenas e simples, que têm tempos de execução muito baixos. Para essas consultas, o processo de geração de um plano de consulta pode ter uma despesa igual ou maior que a execução da consulta. Como resultado, a consulta pode realizar um pouco mais lento do que em versões anteriores do SQL Server. Devido à diferença normalmente em milissegundos, esses efeitos são notados não para uma determinada consulta se ela é executada individualmente. No entanto, você pode perceber que o sistema geral da CPU é maior do que em versões anteriores do SQL Server se grande número de consultas ad hoc é executado simultaneamente por um alto número de usuários.

Desenvolver consultas parametrizadas

SQL Server 7.0 utiliza várias técnicas de novas, como cache de consultas ad hoc e parametrização automática. No entanto, as consultas que SQL Server 7.0 automaticamente parameterizes são limitados. Use os seguintes métodos para garantir que os planos de consulta são parametrizados e podem ser reutilizados com mais eficiência:
  • marcadores de parâmetro O OLE DB e ODBC APIs permitem parâmetros seja especificado com um ponto de interrogação quando os usuários enviem consultas. Isso pode ser muito útil em qualquer aplicativo, especialmente para aplicativos de camada intermediária que têm módulos de geração de consulta onde usar procedimentos armazenados não está disponível. O plano de consulta que é gerado para consultas que tenham marcadores de parâmetro pode ser reutilizado por quaisquer clientes que executar a mesma consulta, mesmo se forem especificados os valores de parâmetros diferentes. Para obter mais informações, consulte o tópico "Parâmetro marcadores" no SQL Server 7.0 Books Online.
  • sp_executesql O procedimento sp_executesql armazenado é chamado pelo provedor do OLE DB ou ODBC driver quando marcadores de parâmetro são usados em um aplicativo. No entanto, ele também pode ser chamado diretamente pelo aplicativo ou em outro procedimento armazenado para parametrizar consultas ad-hoc explicitamente. Isso pode ser muito útil em aplicativos ou arquivos em lotes em que a instrução EXECUTE é usada para executar instruções SQL dinâmicas. Ao contrário sp_executesql , instrução EXECUTE não permite a parametrização. Isso limita a possibilidade de reutilização do plano de consulta. Para obter mais informações, consulte o "sp_executesql (T-SQL)" e "Usando sp_executesql" tópicos no SQL Server 7.0 Books Online.
  • procedimentos armazenados Procedimentos armazenados tem muitos benefícios, incluindo a capacidade de parametrizar consultas e reutilizar planos de execução. Para obter mais informações, consulte os tópicos "Stored Procedures" e "Programming Stored Procedures" no SQL Server 7.0 Books Online.

Exibir os dados do desempenho do sistema

Use o log de desempenho do sistema para determinar quais recursos do sistema estão causando o gargalo. O log de desempenho do sistema pode lhe dar uma idéia geral do sistema e ajudar a se concentrar sua atenção quando você visualiza os dados do SQL Profiler. Revise os dados do desempenho do sistema desde o momento quando o desempenho foi bom por meio do tempo que desempenho reduzido. Determine o contador foi afetado pela primeira vez e, em seguida, determinar qual dos seguintes problemas é mais relevante para sua situação:
  • Objeto: processo
    Contador: processador
    Instância: SQL Server
  • Objeto: processador
    Contador: % tempo do processador
    Instância: Verificar cada instância do processador
  • Objeto: SQL Server: Buffer Manager
    Contador: Livres buffers
  • Objeto: SQL Server: Buffer Manager
    Contador: Roubado contagem de páginas
  • Objeto: SQL Server: memória Manager
    Contador: Memória concede pendente
  • Objeto: SQL Server: SQL estatísticas
    Contador: SQL compilações/s
Se o uso de CPU, compilações de SQL/s e buffers livre contadores são alta, concessões de memória pendentes e contagem de páginas roubadas contadores são baixas, isso indica que a CPU é o gargalo. Concentre-se em como efetivamente parametrizar e reutilizar planos de consulta para evitar o custo de geração de plano de consulta e consulte a seção "Agrupar o rastreamento SQL Profiler por classe de evento" deste artigo. Se os buffers livre e os contadores compilações de SQL/s são baixas e os contadores de contagem de páginas roubadas e concessões de memória pendentes são altos, SQL Server é restrita a memória. Se concentrar em Localizar consultas onde junções de hash são usadas e podem ser alteradas para efetuar loop associações e consulte "Group o SQL Profiler rastrear por duração" seção deste artigo. Para obter mais informações sobre esses contadores, use o nome do contador para pesquisar o SQL Server 7.0 Books Online.

Exibir os dados do SQL Profiler

Quando você está resolvendo problemas de desempenho, é extremamente útil para exibir dados do SQL Profiler. Você não tem que examinar todos os dados que você capturados; seja seletivo. SQL Profiler ajuda você a exibir efetivamente os dados capturados. Na guia Propriedades (no menu arquivo , clique em Propriedades ), SQL Profiler permite limitar os dados que são exibidos por remover colunas de dados ou eventos, agrupamento ou classificação por colunas de dados e aplicação de filtros. Você pode pesquisar o rastreamento inteiro ou apenas uma coluna específica para valores específicos (no menu Editar , clique em Localizar ). Você também pode salvar os dados do SQL Profiler em uma tabela do SQL Server (no menu arquivo , aponte para Salvar como e clique em Tabela de rastreamento ), e em seguida, executar consultas SQL em relação a ele.

Observação Certifique-se que você filtrar somente um arquivo de rastreamento salvos. Se você seguir essas etapas em um rastreamento ativo, risco de perda de dados que foi capturados desde que o rastreamento começou. Salvar um rastreamento ativo em um arquivo ou de tabela primeiro (no menu arquivo , clique em Salvar como ) e em seguida, abra-o (no menu arquivo , clique em Abrir ) antes de continuar. Quando você trabalha com um arquivo de rastreamento salvos, a filtragem não permanentemente remove os dados; os dados é somente ocultos, não excluído. Você pode adicionar e remover colunas de dados para ajudar o foco e eventos suas pesquisas.

Você também deve se concentrar em áreas onde você receberá o benefício mais. Os fatores a seguir podem ajudar a aumentar o desempenho do aplicativo, mas não necessariamente o mesmo grau. Antes de implementar as alterações, determine a eficiência as alterações podem ser dependendo os seguintes fatores:
  • Freqüência a consulta é executada
  • Quanto melhora a consulta pode ser melhorada
Por exemplo, reduzindo o tempo execução de uma única consulta de 1,5 segundo para segundos 1.2 pode não ser útil se a consulta não é executada com freqüência durante o dia. No entanto, se a consulta é executada com muita freqüência por um alto número de usuários simultâneos, a melhoria de desempenho pode ser muito eficiente. Por outro lado, o aprimorar uma única consulta de 6 minutos para 3 segundos não pode produzir um aumento considerável no desempenho geral se ele é usado raramente. Use o agrupamento e filtragem técnicas no SQL Profiler e seu conhecimento do aplicativo para estimar os efeitos de uma consulta específica ou um procedimento antes de implementar as alterações. Focalizar primeiro as alterações mais eficientes e, em seguida, continue com iterações através de outras consultas e procedimentos até alcançar um nível onde desempenho melhorou suficientemente.

Depois que você salva um rastreamento SQL Profiler em um arquivo ou uma tabela, reabra o rastreamento no SQL Profiler e examine o conteúdo. Para agrupar o rastreamento SQL Profiler, execute estas etapas:
  • Agrupe o rastreamento SQL Profiler por duração:
    1. No menu arquivo , clique em Propriedades .
    2. Clique na guia Colunas de dados e, em seguida, em grupos , clique em UP para mover a duração . Clique em para baixo para remover todas as outras colunas.
    3. Clique na guia eventos e, em seguida, remover todos os eventos exceto TSQL SQL:StmtCompleted e TSQL RPC: concluído . Isso permite que você enfocar somente as consultas que estão sendo executadas.
    4. Clique em OK .
    Agrupar por duração permite para ver facilmente o SQL instruções, lotes e procedimentos que estão executando o slowest. Examine o rastreamento quando o problema está ocorrendo e criar uma linha de base de bom desempenho. Você pode filtrar pela hora de início para interromper o rastreamento em seções quando o desempenho é boas e separadas seções quando o desempenho é ruim. Procure as consultas com a mais longa duração quando é bom desempenho. Esses são provavelmente a raiz do problema. Quando diminui o desempenho geral do sistema, até mesmo boas consultas podem mostrar longa duração porque eles estão aguardando para recursos do sistema.

    Revise os planos de execução para as consultas mais freqüentemente que longa duração. Se você vir que uma associação hash está sendo usada, considere usar a dica de consulta JOIN de LOOP para forçar uma associação de loop aninhadas para a consulta. Se o tempo de execução para a consulta usando uma associação de loop for menor que igual a ou até mesmo um pouco maior do que o tempo de execução com a associação de hash, uma associação de loop pode ser uma opção melhor se o computador está com memória alta e uso da CPU. Reduzindo a sobrecarga no gargalo de recurso (CPU e memória), você pode melhorar o desempenho geral do sistema. Para obter mais informações sobre o LOOP JOIN consulta dica, consulte o tópico "SELECT (T-SQL)" nos manuais online do SQL Server 7.0.
  • Agrupe o rastreamento SQL Profiler por classe de evento:
    1. No menu arquivo , clique em Propriedades .
    2. Clique na guia Colunas de dados e, em seguida, sob o título grupos , clique em UP para mover a Classe de evento e texto com Classe de evento na parte superior. Clique em para baixo para remover todas as outras colunas sob o título de grupos .
    3. Clique na guia eventos e, em seguida, verifique se todos os eventos estão incluídos.
    4. Clique em OK .

Tipos de eventos

Para ver quais tipos de eventos estão ocorrendo no computador executando SQL Server e a freqüência com a qual os eventos ocorrem, agrupar pela coluna Classe de evento . Pesquise esta coluna para os seguintes eventos:
  • MISC: preparar SQL e Exec preparado SQL; CURSORS: Cursorprepare Um evento de Preparar SQL indica que uma instrução SQL foi preparada para uso com um conjunto de resultados padrão (cursor do lado do cliente) usando SQLPrepare/SQLExecute (para ODBC) ou ICommandText::Prepare/ICommandText::Execute (para OLE DB) com as opções de cursor padrão: frente somente, somente leitura, tamanho do conjunto de linhas = 1. Um evento Cursorprepare indica que um cursor do lado do servidor foi preparado em um SQL instrução com SQLPrepare/SQLExecute (para ODBC) ou ICommandText::Prepare/ICommandText::Execute (para OLE DB) a uma das opções anteriores do cursor definido para um valor não-padrão. Um evento Exec preparado SQL indica que um dos tipos anteriores de instruções preparadas existentes foi executado. Se você vir freqüentes ocorrências desses eventos, seu aplicativo está usando o modelo de preparar/execução quando ele abre o resultado conjuntos. Em caso afirmativo, você deve determinar se você estiver usando o modelo de preparar/execução corretamente.

    O ideal é que um aplicativo prepara uma instrução SQL uma vez e executa muitas vezes, de modo que o otimizador não tenha que compilar um novo plano sempre que a instrução é executada. Sempre que você executar uma instrução preparada, você salvar o custo da compilação de consulta. Se você planeja somente executar uma consulta uma vez, a Microsoft recomenda que você não prepará-lo. Preparando-se e, em seguida, executando uma instrução SQL requer três de viagens de ida e volta pela rede: um para preparar a instrução, um para executar a instrução e outro para unprepare a instrução. Preparando a cursores server-side requer pelo menos cinco round trips: uma para preparar o cursor, um para executar ou abri-lo, um ou mais para buscar dele, um para fechá-lo e outra para unprepare-lo. Executar a consulta requer apenas uma trajetória de ida e volta.

    Para ver como efetivamente o seu aplicativo usa o modelo preparar/execução, compare o número de vezes esses dois eventos (preparar e executar) ocorrer. O número de eventos Exec preparado SQL deve ser muito maior do que o total de Preparar SQL e eventos CursorPrepare (pelo menos três a cinco vezes maior é uma boa estimativa). Isso indica que instruções preparadas são sendo reutilizadas com freqüência suficiente para superar o aumento sobrecarga para criá-los. Se o número de eventos SQL preparar e CursorPrepare é basicamente equivalente ao número de eventos Exec preparado SQL , isso pode indicar que o aplicativo é não com eficiência usando o modelo de preparar/execução. Tente preparar uma declaração de uma vez e reutilizá-los tanto quanto possível. Você também pode alterar seu aplicativo para preparar instruções uma vez e reutilizar essas instruções.

    O aplicativo deve ser escrito especificamente para usar o modelo preparar/executar com eficiência. O tempo de vida de um identificador para uma instrução preparada é controlado por quanto tempo você manter o HSTMT aberto em ODBC ou o objeto ICommandText no banco de dados OLE. Uma prática comum é obter um HSTMT, preparar uma instrução SQL, execute a instrução preparada e libere HSTMT, assim, perder a alça de plano preparado. Se você fizer isso, você não recebe qualquer benefício do modelo de preparar/execução. Na verdade, você poderá ver uma degradação de desempenho devido à sobrecarga extra dos percursos circulares de rede. O aplicativo deve ter um método para armazenar em cache HSTMT ou objeto com o identificador de instrução preparada e acessá-los para reutilização. O driver ou o provedor não faz isso automaticamente; o aplicativo é responsável por implementar, manter e usando essas informações. Se o aplicativo não é possível fazer isso, considere usar marcadores de parâmetro em vez do método preparar/execução.
  • usando marcadores de parâmetro Aplicativos podem usar marcadores de parâmetro para otimizar o uso da instrução Transact-SQL mesmo várias vezes com valores de saída e entrada diferente. Na primeira vez que uma consulta é executada, ela é preparada como uma consulta parametrizada e SQL Server gera e armazena em cache um plano para a consulta com parâmetros. Para chamadas subseqüentes à consulta mesma usando os parâmetros iguais ou diferentes, SQL Server não tem que gerar um novo plano de consulta; SQL Server pode reutilizar o plano de consulta existente substituindo os parâmetros atuais.

    Se o aplicativo usa marcadores de parâmetro com chamadas para SQLExecDirect (para ODBC) ou ICommandText::Execute (para OLE DB), o driver ou o provedor automaticamente pacotes a instrução SQL e executa-lo como uma chamada sp_executesql . A instrução não precisa ser preparada e executada separadamente. Quando o SQL Server recebe uma chamada para sp_executesql , ele automaticamente verifica o cache de procedimento para um plano correspondente e reutiliza esse plano ou gera um novo plano.

    Para determinar se seu aplicativo atualmente usa o parâmetro marcadores, é possível pesquisar a coluna de texto no rastreamento SQL Profiler para "sp_executesql." No entanto, porque sp_executesql pode ser chamado diretamente, não todas as instâncias indicar o uso de marcadores de parâmetro.

    Para obter mais informações sobre o modelo preparar/execução, consulte o tópico "Execução plano cache e Reuse" nos manuais online do SQL Server 7.0. Para obter mais informações sobre os marcadores de parâmetro, consulte o tópico "Parâmetro marcadores" nos manuais online do SQL Server 7.0.
  • SP: concluído Instruções SQL dinâmicas executadas com o comando EXECUTE aparecerão como um SP: concluído evento com o texto "SQL dinâmico". Expanda o SP: concluído evento e, em seguida, procure por quaisquer ocorrências que têm "SQL dinâmico" como o texto. Se existem vários desses eventos, você poderá melhorar o desempenho do aplicativo usando sp_executesql em vez da instrução EXECUTE. O procedimento sp_executesql armazenados permite que o SQL Server para reutilizar planos de execução se a mesma consulta for executada novamente usando diferentes parâmetros. Quando você usar a instrução EXECUTE, o plano não é parametrizado e ela não é reutilizada, a menos que a consulta é executada novamente usando os mesmos parâmetros.

    Para determinar as consultas ou procedimentos que usar eventos SQL dinâmicos com o EXECUTE instrução, observe a identificação de conexão e Start Time de para cada evento. Desagrupar o rastreamento (remover Classe de evento e o texto do título grupos ). Após você desagrupar o rastreamento, ele é classificado em ordem cronológica. Você pode filtrar o rastreamento pela identificação de conexão (na guia filtros ) e, em seguida, remover todas as classes evento, exceto o SP: Iniciando e SP: concluída eventos para aumentar a legibilidade. Em seguida, você pode procurar a hora de início do evento (no menu Editar , clique em Localizar ). Os resultados mostram quando o evento SQL dinâmico iniciado. Se o evento ocorreu em um procedimento armazenado, o evento aparece entre o SP: Iniciando e SP: concluído eventos para esse procedimento. Se não tivesse ocorrido o evento em um procedimento armazenado, ele foi executado como uma consulta ad hoc e você pode usar as outras colunas de dados ( Nome do aplicativo , Nome de usuário do NT e outros) para determinar onde o comando foi executado. Para determinar o texto do comando e o contexto de onde ela foi executada, você também pode adicionar classes de evento, como SQL:BatchCompleted e SQL:RPCCompleted .

    Depois de determinar onde a instrução EXECUTE está sendo usada, considere substitui-lo por uma chamada para sp_executesql . Por exemplo, considere o seguinte cenário em que EXECUTE o comando é usado com SQL dinâmico. Um procedimento usa um nome de tabela, ID e idValue como parâmetros de entrada e em seguida, executa uma instrução SELECT da tabela com base no valor ID. Usando uma instrução EXECUTE, o procedimento é semelhante ao seguinte código:
    drop proc dynamicUsingEXECUTE
    		  go create proc dynamicUsingEXECUTE @table sysname, @idName varchar(10),
    		  @idValue varchar(10) as declare @query nvarchar(4000) -- Build query string
    		  with parameter. -- Notice the use of escape quotes. select @query = 'select *
    		  from ' + @table + ' where ' + @idName + ' = ''' + @idValue + '''' exec (@query)
    		  go
    assumindo que a consulta está parametrizada não automaticamente, se você executar este procedimento em relação a tabela de títulos no banco de exemplo pubs dados duas vezes com valores diferentes para @ idValue parâmetro, SQL Server deve gerar um plano de consulta separado para cada execução. Por exemplo:
    exec dynamicUsingEXECUTE
    		  'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',
    		  'title_id', 'BU7832'
    Observação neste exemplo, a consulta é bastante simples que o SQL Server pode parametrizá-lo automaticamente e reutilizar, na verdade, o plano de execução. No entanto, se esta foi uma consulta complexa que o SQL Server não pode parametrizar automaticamente, SQL Server pode não reutilizar o plano para a segunda execução se @ idValue parâmetro foi alterado. A seguinte consulta simples limita a complexidade de exemplo.

    Você pode reescrever esse procedimento para usar sp_executesql em vez da instrução EXECUTE. Suporte para substituição de parâmetro torna sp_executesql mais eficiente porque ele gera planos de execução que têm mais probabilidade de ser reutilizadas pelo SQL Server. Por exemplo:
    drop proc dynamicUsingSP_EXECUTESQL go create proc
    		  dynamicUsingSP_EXECUTESQL @table sysname, @idName varchar(10), @idValue
    		  varchar(10) as declare @query nvarchar(4000) -- Build query string with
    		  parameter select @query = 'select * from ' + @table + ' where ' + @idName + ' =
    		  @idValue' -- Now execute with parameter exec sp_executesql @query, N'@idValue
    		  varchar(10)', @idValue go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'MC2222' go exec dynamicUsingSP_EXECUTESQL 'titles', 'title_id',
    		  'BU7832'
    neste exemplo, na primeira vez que a instrução sp_executesql é executada, SQL Server gera um plano com parâmetros para a instrução SELECT de títulos com id_título como o parâmetro. Para a segunda execução, SQL Server reutiliza o plano com o novo valor do parâmetro. Para obter mais informações sobre sp_executesql , consulte o "sp_executesql (T-SQL)" e "Usando sp_executesql" tópicos no SQL Server 7.0 Books Online.
  • SP:RECOMPILES Esse evento indica que um procedimento armazenado foi recompilado durante a execução. Vários eventos de recompilação indica que o SQL Server está usando recursos para compilação de consulta em vez de execução da consulta.
Se você não conseguir ver qualquer um desses eventos, o aplicativo está em execução ad-hoc apenas as consultas no SQL Server. A menos que o SQL Server determina que ele pode parametrizar automaticamente determinadas consultas ou se os mesmos parâmetros forem usados repetidamente, cada consulta é executada requer SQL Server gerar um novo plano de execução. Monitor de desempenho do SQL Server deve mostrar muitas compilações de SQL/s. Isso pode ser exige muito da CPU para muitos usuários simultâneos. Para contornar esse problema, localize mais executadas com freqüência consultas e considere criar procedimentos armazenados para essas consultas, usando o parâmetro marcadores, ou usando sp_executesql .

Referências

Para obter mais informações sobre como monitorar e solucionar problemas de desempenho no SQL Server, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
224587Como solucionar problemas de desempenho do aplicativo com o SQL Server
224453INF: Compreender e resolver o SQL Server 7.0 ou problemas de bloqueio de 2000
243586Solucionando problemas de recompilação de procedimento armazenado
243589Como solucionar problemas de consultas de execução lenta no SQL Server 7.0 ou posterior
251004INF: Como monitorar o bloqueio de SQL Server 7.0

Propriedades

ID do artigo: 243588 - Última revisão: quinta-feira, 8 de dezembro de 2005 - Revisão: 5.4
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Palavras-chave: 
kbmt kbhowtomaster kbhowto kbinfo KB243588 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: 243588

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