Você não pode acessar um banco de dados do SQL Server usando o provedor OLE DB para SQL Server quando seu aplicativo está em um cenário de alto-estresse

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: 907264
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.
Bug #: 245183 (SQLBUDT)
Sintomas
Considere o seguinte cenário. Um aplicativo grande empresa usa o Microsoft SQL Server. O aplicativo está em um cenário de alto-estresse. Quando o aplicativo tenta acessar um banco de dados do SQL Server usando o Microsoft OLE DB Provider para SQL Server (SQLOLEDB), poderá receber uma ou mais das seguintes mensagens de erro:
Erro de rede geral
SQL Server não existe ou acesso negado
Tempo limite expirou
Causa
Esse problema ocorre quando um aplicativo grande empresa em um cenário de alto-estresse executa várias consultas em sessões de banco de dados OLE ou em conexões de ActiveX Data Objects (ADO) que usam SQLOLEDB.

Por exemplo, o seguinte comportamento pode ocorrer:
  • Uma nova consulta SQL usa um cursor firehose.

    Observação Um cursor firehose é um cursor do lado do servidor, forward-only e somente leitura.
  • A nova consulta SQL é executada em uma sessão de banco de dados OLE ou em uma conexão ADO que usa SQLOLEDB.
  • A sessão de banco de dados OLE ou a conexão ADO já está ocupada processando conjuntos de resultados de uma consulta anteriormente existente.
Quando esse comportamento ocorre, SQLOLEDB cria uma nova em pool não implícita conexão para executar a nova consulta SQL.

Quando um aplicativo grande empresa está em um cenário de alto-estresse, executar muitos dessas novas consultas SQL cria muitos correspondentes não pool implícitas conexões. Portanto, você pode receber mensagens de erro "Erro de rede geral".

Você pode receber essas mensagens de erro porque um ou mais das seguintes condições são verdadeiras:
  • A configuração de registro do SQL Server WinsockListenBacklog define o número máximo de solicitações simultâneas que novo logon. No entanto, o número de novo logon solicitações simultâneas da nova não pool implícita conexão ao computador que está executando o SQL Server excede esse valor.
  • Configuração do Registro MaxUserPort limita o número de portas efêmeras de TCP/IP no computador aplicativo. No entanto, o aplicativo requer mais efêmeras portas TCP/IP para ser atribuídos pelo Windows Sockets para as novas conexões implícitas não em pool.
  • A configuração de registro TCPTimedWaitDelay impede que o TCP/IP soquete portas efêmeras em computador de reciclagem rápido o suficiente para atender à demanda para novas conexões TCP/IP implícitas para as conexões implícitas não pool novas aplicativo.
Como Contornar
Para contornar esse problema, use um dos seguintes métodos:
  • Evite conexões implícitas em cenários de aplicativo de empresa de grande porte. Em vez disso, criar pares de origem/sessão de dados OLE adicionais explicitamente ou crie explicitamente ADO conexões.
  • Evite usar o cursor firehose em uma sessão SQLOLEDB ou define uma conexão ADO que irá processar vários resultado ao mesmo tempo.
  • Definir a propriedade conexões vários da conexão ADO para false, ou defina a propriedade DBPROP_MULTIPLECONNECTIONS OLE DB para VARIANT_FALSE.
  • Use o SQL Server 2005 nativo cliente API. Cliente nativo do SQL Server 2005 oferece suporte a vários Active resultado Sets (MARS). MARS mantém vários conjuntos de resultados sobre a mesma sessão de banco de dados OLE ou a conexão ADO.

    Para obter mais informações sobre cliente nativo do SQL Server 2005 e MARS, visite os seguintes sites da Microsoft Developer Network (MSDN):
    Microsoft SQL Server Native Client
    http://msdn2.microsoft.com/en-us/data/aa937733.aspx

    (MARS) usar Multiple Active Result Sets
    http://msdn2.microsoft.com/en-us/library/ms131686.aspx

    Usando o ADO com o SQL Native Client
    http://msdn2.microsoft.com/en-us/library/ms130978.aspx
Situação
Esse comportamento é por design.
Mais Informações
Para obter mais informações sobre conexões implícitas e SQLOLEDB, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
271128Implícitos conexões criadas pelo SQL Server OLE DB Provider (SQLOLEDB) não são colocados em pool
194979ADO gera conexões adicionais para o SQL Server
Para obter mais informações sobre o pool de conexões, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
328476Descrição de configurações de TCP/IP que talvez você precise ajustar ao pool de conexão do SQL Server está desativado

Aviso: este artigo foi traduzido automaticamente

Proprietăți

ID articol: 907264 - Ultima examinare: 03/14/2007 06:51:05 - Revizie: 1.2

Microsoft ActiveX Data Objects 2.7, Microsoft ActiveX Data Objects 2.7, Microsoft ActiveX Data Objects 2.6, Microsoft ActiveX Data Objects 2.5, Microsoft ActiveX Data Objects 2.1 Service Pack 2, Microsoft ActiveX Data Objects 2.0, Microsoft ActiveX Data Objects 1.5

  • kbmt kbdesign kbnofix kbtshoot kbprb KB907264 KbMtpt
Feedback