Como resolver problemas de desempenho de consultas ad-Hoc no SQL Server

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

Nesta página

Sumário

Este artigo descreve como resolver o desempenho lento de várias consultas ad-hoc em simultâneo no Microsoft SQL Server. Se não tiver determinado a origem exacta do problema, consulte o artigo seguinte na Microsoft Knowledge Base antes de continuar:
224587Como resolver o desempenho da aplicação com o SQL Server

Este artigo pressupõe que utilizou 224587 KB para limitar o âmbito do problema e que capturadas um registo do Monitor de desempenho do Windows NT e o SQL Profiler que detalhe de rastreio as colunas de dados, eventos e contadores específicas.

Características de problemas de desempenho

O problema de desempenho tem as seguintes características:
  • Consultas ad-hoc breve que normalmente têm uma duração muito curta lento desempenho global do sistema se ocorrer um número elevado de utilizadores simultâneos executar as consultas.
  • Muito alta ou 100 percentagem utilização da CPU.
  • Não bloquear associado durante períodos de um desempenho lento.

    Pode rapidamente procurar bloquear verificando a coluna BLK o resultado do procedimento armazenado do sistema sp_who . Se a coluna BLK não for zero para um número de ID (SPID) do processo de sistema, existe está a bloquear.
  • Em algumas situações, memória do servidor é stressed e poderá receber erros semelhantes aos seguintes erros:
    Erro: 701, gravidade: 17, estado: 1
    Existe memória de sistema insuficientes para executar esta consulta.
    - ou -
    Msg 8645, nível 17, 1, estado do procedimento, linha 1
    Ocorreu um tempo limite enquanto aguardava por recursos de memória executar a consulta. Volte a executar a consulta.

Melhoramentos nas compilações de consulta

Devido a melhorias na arquitectura do sistema iniciar no SQL Server 7.0, especificamente o Optimizador de consultas, poderá notar uma diferença na utilização de recursos do sistema por aplicações comparado com versões anteriores do SQL Server. Especificamente, o SQL Server 7.0 pode mostrar um aumento na utilização da CPU ou memória, mas versões anteriores do SQL Server são normalmente disco E/S dependente. Estas alterações podem ser rastreadas para dois factores:
  • Associações hash e de impressão em série
  • Tempos de compilação de consulta
Versões anteriores do SQL Server completamente confiavam no ciclo aninhado iterações para executar associações. Associações de ciclo aninhado inerentemente utilizar disco de E/S. Associações hash e de impressão em série a partir do SQL Server 7.0, foram introduzidas. Associações de hash e intercalar fazer muito mais de memória de processamento de associações de ciclo aninhado. O resultado lógico deste é que CPU e utilização da memória é superior quando estas técnicas de associação são utilizadas. Para obter mais informações sobre associações hash e de impressão em série, consulte os tópicos "Noções sobre associações de hash" e "Noções sobre impressão em série associações" no SQL Server 7.0 Books Online.

Tempos de compilação de consulta são afectados porque o Optimizador de consultas tem mais opções e informações disponíveis do que em versões anteriores do SQL Server, incluindo novas técnicas de associação de hash e intercalar, algoritmos de procura melhoradas e estatísticas de coluna. Estas informações adicionais permite o Optimizador de consultas para seleccionar o método mais eficiente para obter dados da consulta. No entanto, a análise e consideração destas novas técnicas e informações requer tempo de processamento. Este aumento da CPU pode resultar em tempos de compilação de consulta com mais do que em versões anteriores do SQL Server.

Para a maior parte das consultas, este aumento em tempo de compilação desfasamento por uma diminuição do 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 excepção, com muito pequenas e simples, consultas de tipo OLTP com tempos de execução muito baixos. Para estas consultas, o processo de geração de um plano de consulta poderá ter uma despesa igual ou maior do que a execução da consulta. Como resultado, pode executar a consulta ligeiramente mais lenta do que em versões anteriores do SQL Server. Uma vez que a diferença é normalmente em milissegundos, estes efeitos não são reparados para uma determinada consulta se for executada individualmente. No entanto, poderá notar que utilização da CPU de sistema global é superior em versões anteriores do SQL Server, se grandes quantidades de consultas ad-hoc são executadas em simultâneo por um número elevado de utilizadores.

Desenvolver consultas parametrizadas

SQL Server 7.0 utiliza várias técnicas de novas, tais como cache de consultas ad-hoc e parameterization automática. No entanto, as consultas que SQL Server 7.0 automaticamente parameterizes são limitadas. Utilize os seguintes métodos para garantir que os planos de consulta são parametrizados e podem ser reutilizados com maior eficácia:
  • marcadores de parâmetro O OLE DB e ODBC APIs permitem parâmetros para ser especificado com um ponto de interrogação quando os utilizadores submeterem as consultas. Isto pode ser muito útil em qualquer aplicação, especialmente para aplicações de camada com módulos de geração de consulta em que utilizar procedimentos armazenados não está disponível. O plano de consulta que é gerado para consultas com marcadores de parâmetro poderá ser reutilizado por quaisquer clientes que executam a mesma consulta, mesmo se forem especificados valores de parâmetros diferentes. Para mais informações, consulte o tópico "Marcadores de parâmetro" no SQL Server 7.0 Books Online.
  • sp_executesql O procedimento armazenado sp_executesql denomina-se pelo fornecedor de OLE DB ou controlador ODBC quando são utilizados marcadores de parâmetro numa aplicação. No entanto, pode também ser chamado directamente pela aplicação ou num outro procedimento armazenado de explicitamente parametrizar consultas ad-hoc. Isto pode ser muito útil para aplicações ou ficheiros de comandos em que a instrução EXECUTE é utilizada para executar instruções de SQL dinâmicas. Ao contrário sp_executesql , a instrução EXECUTE não permite parameterization. Isto limita a possibilidade de reutilização de plano de consulta. Para mais informações, consulte o "sp_executesql (T-SQL)" e "Utilizar sp_executesql" tópicos no SQL Server 7.0 Books Online.
  • procedimentos armazenados Procedimentos armazenados tem muitas vantagens, incluindo a capacidade para parametrizar consultas e reutilizar planos de execução. Para mais informações, consulte os tópicos "Procedimentos armazenados" e "Programming procedimentos armazenados" no SQL Server 7.0 Books Online.

Visualizar dados do Monitor de desempenho

Utilize o registo do Monitor de desempenho para determinar que recursos do sistema estão a causar o congestionamento. O registo do Monitor de desempenho pode dar-lhe uma imagem global do sistema e ajudar a concentrar a atenção quando visualiza os dados de SQL Profiler. Reveja os dados do Monitor de desempenho do tempo de desempenho foi bom tempo que diminui o desempenho. Determine o contador foi afectado pela primeira vez e, em seguida, determinar qual dos seguintes problemas é mais relevante à sua situação:
  • Objecto: processo
    Contador: processador
    Instância: SQL Server
  • Objecto: processador
    Contador: % tempo do processador
    Instância: Verificação de cada instância do processador
  • Objecto: SQL Server: memória intermédia Manager
    Contador: Memórias intermédias livres
  • Objecto: SQL Server: memória intermédia Manager
    Contador: Contador de páginas roubados
  • Objecto: SQL Server: memória Manager
    Contador: Memória concede pendente
  • Objecto: Estatísticas SQL Server: SQL
    Contador: SQL compilações/seg
Se a utilização da CPU, compilações SQL/seg e memórias intermédias livre contadores são alto, memória permite pendente e roubado contador de páginas contadores são baixos, isto indica que a CPU é de congestionamento. Concentrar-se como parametrizar eficazmente e reutilizar planos de consulta para evitar o custo de geração de plano de consulta e consulte a secção "Grupo o rastreio SQL Profiler por classe de evento" deste artigo. Se as memórias intermédias livre e contadores de compilações SQL/seg são baixos e os contadores roubado contador de páginas e memória permite pendente alto, SQL Server é limitado de memória. Focar localizar consultas onde associações de hash são utilizadas e podem ser alteradas para efectuar um ciclo de associações e ver "Grupo SQL Profiler rastreio pela duração" secção deste artigo. Para obter mais informações sobre estes contadores, utilize o nome de contador para procurar o SQL Server 7.0 Books Online.

Visualizar os dados de SQL Profiler

Quando estiver a resolver problemas de desempenho, é extremamente útil para visualizar dados de SQL Profiler. Não tem de rever os dados que é capturado; seja selectivo. SQL Profiler ajuda-o para ver eficazmente os dados capturados. No separador Propriedades (no menu ficheiro , clique em Propriedades ), SQL Profiler permite-lhe limitar os dados que são apresentados remover colunas de dados ou eventos, agrupar ou ordenar por colunas de dados e aplicar filtros. Pode procurar o rastreio completo ou apenas numa coluna específica para valores específicos (no menu Editar , clique em Localizar ). Também pode guardar os dados de SQL Profiler para uma tabela do SQL Server (no menu ficheiro , aponte para Guardar como e, em seguida, faça clique sobre Analisar tabela ), e, em seguida, executar consultas SQL relativamente à mesma.

Nota Certifique-se de que filtrar apenas um ficheiro de rastreio guardados. Se seguir estes passos num rastreio activo, risco de perder dados que foi capturados desde que o rastreio foi iniciado. Guardar um rastreio activo para um ficheiro ou tabela em primeiro lugar (no menu ficheiro , clique em Guardar como ) e, em seguida, abra-o (no menu ficheiro , clique em Abrir ) antes de continuar. Quando trabalha com um ficheiro de rastreio guardada, a filtragem não permanentemente remove os dados; os dados apenas estiver oculta, não é eliminado. Pode adicionar e remover eventos e colunas de dados para ajudar a definir as procuras.

Também deve focar as áreas onde tira o máximo partido. Os seguintes factores podem ajudar a aumentar o desempenho da aplicação, mas não necessariamente para o mesmo grau. Antes de implementar as alterações, determine como efectivas as alterações podem ser consoante os seguintes factores:
  • Frequência de consulta é executada
  • Quanto melhoria a consulta pode ser melhorada
Por exemplo, reduzir o tempo de execução de uma consulta única de 1,5 segundos a segundos 1.2 poderão não ser útil se a consulta não é executada frequentemente durante o dia. No entanto, se a consulta é executada muito frequentemente por um elevado número de utilizadores em simultâneo, o melhoramento de desempenho pode ser muito eficaz. Por outro lado, melhorar uma consulta única de 6 minutos para 3 segundos poderão não ter um aumento perceptível no desempenho global se raramente é utilizada. Utilize o agrupamento e filtragem técnicas SQL Profiler e conhecimento do utilizador da aplicação para estimar os efeitos de uma determinada consulta ou um procedimento antes de implementar as alterações. Focar primeiro as alterações mais eficazes e, em seguida, continue com iterações através de outras consultas e procedimentos até atingir um nível onde desempenho suficientemente melhorou.

Depois de guardar um rastreamento SQL Profiler para um ficheiro ou tabela, reabra o rastreio de SQL Profiler e reveja o conteúdo. Para agrupar o rastreio de SQL Profiler, siga estes passos:
  • Agrupar o rastreio de SQL Profiler por duração:
    1. No menu ficheiro , clique em Propriedades .
    2. Clique no separador Colunas de dados e, em seguida, em grupos , clique em cima para mover a duração . Clique em para baixo para remover todas as outras colunas.
    3. Clique no separador eventos e, em seguida, remova todos os eventos excepto TSQL SQL e TSQL RPC: concluída . Isto permite-lhe concentrar-se apenas as consultas que estão a ser executadas.
    4. Clique em OK .
    Agrupar por duração permite ver facilmente o SQL declarações, secções e procedimentos que executem o slowest. Reveja o rastreio quando ocorrer o problema e criar um plano base do bom desempenho. Pode filtrar por tempo de início para dividir o rastreio em secções quando desempenho secções boas e separadas quando está um fraco desempenho. Procure as consultas com a maior duração quando é bom desempenho. Estes são provavelmente a raiz do problema. Quando diminui o desempenho global do sistema, mesmo boas consultas podem mostrar durações longas porque eles estão a aguardar recursos do sistema.

    Rever os planos de execução para as consultas mais frequentemente que durações longas. Se vir que está a ser utilizada uma associação de hash, considere utilizar a dica de consulta LOOP JOIN para forçar uma associação de ciclo aninhado para a consulta. Se o tempo de execução para a consulta utilizando uma associação de ciclo for menor que igual ou mesmo ligeiramente superior a hora de execução com a associação de hash, uma associação de ciclo pode ser a melhor opção se o computador tem memória alta e utilização da CPU. Reduzindo a carga no congestionamento de recurso (CPU e memória), pode melhorar o desempenho global do sistema. Para mais informações sobre o JOIN de LOOP consultar sugestão, consulte o tópico "SELECT (T-SQL)" no SQL Server 7.0 Books Online.
  • Agrupar o rastreio de SQL Profiler por classe de evento:
    1. No menu ficheiro , clique em Propriedades .
    2. Clique no separador Colunas de dados e, em seguida, sob o título de grupos , clique em cima para mover a Classe de eventos e texto com a Classe de evento na parte superior. Clique em para baixo para remover todas as outras colunas sob o título de grupos .
    3. Faça clique sobre o separador eventos e, em seguida, certifique-se de que todos os eventos são incluídos.
    4. Clique em OK .

Tipos de eventos

Para ver os tipos de eventos estão a ocorrer no computador com o SQL Server e com que frequência os eventos ocorrem, agrupar pela coluna Classe de evento . Procure nesta coluna para os seguintes eventos:
  • MISC: preparar SQL e serviço preparados SQL; CURSORES: Cursorprepare Um evento de SQL preparar indica que uma instrução de SQL foi preparada para utilização com um conjunto de resultado predefinido (cursor do lado do cliente) utilizando SQLPrepare/SQLExecute (para ODBC) ou ICommandText::Prepare/ICommandText::Execute (para OLE DB) com as opções de cursor predefinidas: para a frente, só de leitura, tamanho do conjunto de linhas = 1. Um evento Cursorprepare indica que foi preparado um cursor do lado do servidor num SQL instrução utilizando SQLPrepare/SQLExecute (para ODBC) ou ICommandText::Prepare/ICommandText::Execute (para OLE DB) com as opções de cursor anterior dos defina um valor não predefinido. Um evento de Execução E preparados SQL indica que um dos tipos de instruções preparadas existentes anteriores foi executado. Se vir frequentes ocorrências destes eventos, a sua aplicação é utilizar o modelo de preparação/executar quando é aberto resultado conjuntos. Se for esse o caso, terá de determinar se estiver a utilizar correctamente o modelo de preparação/executar.

    Idealmente, uma aplicação prepara uma vez uma instrução de SQL e executa muitas vezes, de modo que o optimizador não tenha que compilar um novo plano sempre que a instrução for executada. Sempre que executar uma instrução preparada, guardar o custo da compilação consulta. Se pretender apenas executar uma consulta de uma vez, a Microsoft recomenda que não prepará-lo. Preparar e, em seguida, executar uma instrução de SQL requerem três tráfego de rede: um para preparar a declaração, uma para executar a instrução e outra para unprepare a instrução. Preparar cursores do lado do servidor requer, pelo menos, cinco número de visitas: uma para preparar o cursor para executar ou abri-lo, um ou mais obtidos a partir do mesmo, uma para fechá-la e outra para unprepare-lo. Apenas executar a consulta requer uma ida e volta.

    Para ver como eficazmente a aplicação utiliza o modelo preparação/executar, comparar o número de vezes que estes dois eventos (preparar e execução) ocorrer. O número de eventos do Serviço preparados SQL deve ser muito maior do que o total de SQL preparar e eventos CursorPrepare (pelo menos três a cinco vezes maior é uma boa estimativa). Isto indica que instruções preparadas são a ser reutilizadas com uma frequência suficiente para ultrapassar a maior sobrecarga criá-los. Se o número de eventos Preparar SQL e CursorPrepare é aproximadamente equivalente ao número de eventos do Serviço preparados SQL , isto poderá indicar que a aplicação não está a efectivamente utilizar o modelo de preparação/executar. Tente preparar uma instrução uma vez e reutilizá-lo quanto possível. Também pode alterar a aplicação para preparar declarações uma vez e reutilizar esses instruções.

    A aplicação tem de ser especificamente escrita utilizar eficazmente o modelo de preparação/executar. A duração de um identificador para uma instrução preparada é controlada pela quanto mantiver o HSTMT aberto no ODBC ou o objecto ICommandText de OLE DB. É uma prática comum obter um HSTMT, preparar uma instrução de SQL, execute a instrução preparada e, em seguida, liberte HSTMT, assim perder a alça ao plano preparado. Se o fizer, não recebe qualquer vantagem do modelo de preparação/executar. De facto, poderá ver uma degradação do desempenho devido a sobrecarga adicional o tráfego de rede. A aplicação tem de ter um método para colocar em cache o HSTMT ou objecto com o identificador de instrução preparada e aceder-lhes para reutilização. O controlador ou o fornecedor não o faz automaticamente; a aplicação é responsável pela implementação, manutenção e utilizar estas informações. Se a aplicação não é possível fazer, considere utilizar marcadores de parâmetro em vez do método preparação/executar.
  • utilizar marcadores de parâmetro As aplicações podem utilizar marcadores de parâmetro para optimizar a utilização da mesma instrução Transact-SQL várias vezes com valores de saída e entrada diferente. A primeira vez que é executada uma consulta, está preparado como uma consulta parametrizada e SQL Server gera e coloca em cache um plano para a consulta parametrizado. Para chamadas subsequentes para a mesma consulta utilizando os parâmetros do mesmos ou diferentes ou, SQL Server não tem de gerar um novo plano de consulta; SQL Server pode reutilizar o plano de consulta existente substituindo os parâmetros actuais.

    Se a aplicação utiliza marcadores de parâmetro com chamadas para SQLExecDirect (para ODBC) ou ICommandText::Execute (para OLE DB), o controlador ou o fornecedor de pacotes a instrução SQL e automaticamente executado como uma chamada sp_executesql . A instrução não tem de ser preparado e executadas separadamente. Quando o SQL Server recebe uma chamada para sp_executesql , é automaticamente verifica a cache do procedimento para um plano correspondente e reutiliza esse plano ou gera um novo plano.

    Para determinar se a aplicação actualmente utiliza marcadores de parâmetro, pode procurar a coluna de texto no rastreio SQL Profiler para "sp_executesql." No entanto, uma vez que pode ser chamado directamente sp_executesql , nem todas as instâncias indicam a utilização dos marcadores de parâmetro.

    Para mais informações sobre o modelo preparação/executar, consulte o tópico "Execução de planeamento de colocação em cache e reutilizar" no SQL Server 7.0 Books Online. Para obter mais informações sobre marcadores de parâmetro, consulte o tópico "Marcadores de parâmetro" no SQL Server 7.0 Books Online.
  • SP: concluída Dinâmicas instruções de SQL executadas com o comando Executar aparecem como um SP: concluída evento com o texto "Dynamic SQL". Expanda o SP: concluída evento e, em seguida, procurar ocorrências que têm "Dynamic SQL" como o texto. Se existirem muitos destes eventos, poderá melhorar o desempenho da aplicação utilizando sp_executesql em vez da instrução EXECUTE. O procedimento armazenado sp_executesql permite SQL Server para reutilizar planos de execução se a mesma consulta é executada de novo utilizando parâmetros diferentes. Quando utiliza a instrução EXECUTE, o plano não é parametrizado e não reutilizar a menos que a consulta é executada novamente utilizando os mesmos parâmetros.

    Para determinar as consultas ou procedimentos que utilizar eventos SQL dinâmicos com o executar instrução nota o ID de ligação e hora de início de cada evento. Desagrupar o rastreio (remover Classe de eventos e o texto do título grupos ). Depois de desagrupar o rastreio, é ordenado por ordem cronológica. Pode filtrar o rastreio por ID de ligação (no separador filtros ) e, em seguida, remova todas as classes de evento, excepto o SP: Iniciar e SP: concluída eventos para melhor legibilidade melhorada. Em seguida, pode procurar a hora de início do evento (no menu Editar , clique em Localizar ). Mostram os resultados quando o evento SQL dinâmico iniciado. Se o evento ocorreu num procedimento armazenado, o evento aparece entre o SP: Iniciar e SP: concluída eventos para esse procedimento. Se o evento não tivesse ocorrido num procedimento armazenado, foi executada como uma consulta ad hoc e pode utilizar as outras colunas de dados ( Nome da aplicação , Nome de utilizador de NT e outros) para determinar onde o comando foi executado. Para determinar o texto do comando e o contexto em que foi executado, também pode adicionar classes de eventos, tais como SQL:BatchCompleted e SQL:RPCCompleted .

    Depois de determinar onde está a ser utilizada a instrução EXECUTE, considere substituir uma chamada para sp_executesql . Por exemplo, considere o seguinte cenário onde EXECUTE o comando é utilizado com o SQL dinâmica. Um procedimento tem um nome da tabela, ID e idValue como parâmetros de entrada e, em seguida, executa uma instrução SELECT da tabela com base no ID de valor. Utilizando 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
    partindo do princípio que a consulta é parametrizada não automaticamente, se executar este procedimento contra a tabela de títulos na base de exemplo pubs dados duas vezes com valores diferentes para @ idValue parâmetro, SQL Server deverá gerar um plano de consulta em separado para cada execução. Por exemplo:
    exec dynamicUsingEXECUTE
    		  'titles', 'title_id', 'MC2222' go exec dynamicUsingEXECUTE 'titles',
    		  'title_id', 'BU7832'
    NOTA: neste exemplo, a consulta é suficientemente simples que SQL Server pode automaticamente parametrizá-lo e, na realidade, reutilizar o plano de execução. No entanto, se este for uma consulta complexa não pode parametrizar automaticamente do SQL Server, SQL Server pode não reutilizar o plano de execução segundo se @ idValue parâmetro foi alterado. A seguinte consulta simples limita a complexidade do exemplo.

    Pode rescrever este procedimento para utilizar sp_executesql em vez da instrução EXECUTE. Suporte para substituição de parâmetro torna mais eficiente sp_executesql porque gera planos de execução é mais provável ser reutilizado 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, a 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 parâmetro. Para a execução de segunda, 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 "Utilizar sp_executesql" tópicos no SQL Server 7.0 Books Online.
  • SP:RECOMPILES Este evento indica que um procedimento armazenado foi novamente compilado durante a execução. Muitos eventos de recompilação indica que o SQL Server está a utilizar recursos de compilação de consulta em vez de execução da consulta.
Se vir que destes eventos, a aplicação está a executar consultas de ad-hoc contra do SQL Server. Se o SQL Server determina que pode parametrizar automaticamente determinadas consultas ou se os mesmos parâmetros utilizados repetidamente, cada consulta é executada necessita do SQL Server gerar um novo plano de execução. Monitor de desempenho do SQL Server deve mostrar compilações SQL muitos/seg. Isto pode ser intensiva da CPU para muitos utilizadores em simultâneo. Para contornar este problema, localize mais frequentemente executar consultas e considere a criação de procedimentos armazenados para estas consultas, utilizar marcadores de parâmetro ou sp_executesql a utilizar.

Referências

Para obter mais informações sobre como monitorizar e problemas de desempenho no SQL Server, clique números de artigo que se seguem para visualizar os artigos na base de dados de conhecimento da Microsoft:
224587Como resolver o desempenho da aplicação com o SQL Server
224453INF: Compreender e resolver problemas de bloqueio de 2000 ou SQL Server 7.0
243586Resolução de problemas recompilation do procedimento armazenado
243589Como resolver consultas de execução lenta no SQL Server 7.0 ou posterior
251004INF: Como monitorar o bloqueio SQL Server 7.0

Propriedades

Artigo: 243588 - Última revisão: 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 2005 Server Enterprise
  • 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 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: 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