Descrição de conexões de cliente do servidor virtual SQL

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

Neste artigo

Sumário

Este artigo descreve algumas das noções básicas sobre conexões de cliente do SQL Microsoft Virtual Server.

Mais Informações

importante Esta seção, método ou tarefa contém etapas que informam sobre como modificar o registro. No entanto, sérios problemas poderão ocorrer se você modificar o registro incorretamente. Por isso, certifique-se que você execute essas etapas cuidadosamente. Para proteção adicional, fazer backup do registro antes de modificá-lo. Em seguida, você pode restaurar o registro se ocorrer um problema. Para obter mais informações sobre como fazer backup e restaurar o registro, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
322756Como fazer backup e restaurar o registro no Windows


Comportamento do cliente servidor virtual SQL

Microsoft Cluster Server (MSCS) fornece uma plataforma robusta e confiável na qual você pode criar aplicativos de missão crítica do SQL Server. Você não precisa modificar a maioria dos aplicativos de servidor para usá-los com MSCS. No entanto, aplicativos baseados em transações (por exemplo, banco de dados de servidores, como o Microsoft SQL Server) geralmente exigem modificações adicionais para que se o servidor falhar, suporte a failover adequadamente impede que a perda de integridade transacional. Desenvolvendo um aplicativo de cliente para operar com MSCS é relativamente simples. Você deve projetar aplicativos com verificação Lembre-se de erros e recuperação do banco de dados.

Mesmo sem o uso de clusters, um servidor SQL servidor recupera todos os bancos de dados automaticamente quando o servidor for reiniciado. Para garantir que um banco de dados é recuperada em um estado de aplicativo consistentes, as transações de banco de dados de uso para que ocorra failover no banco de dados corretamente e em um estado consistente. Quaisquer transações que estão incompletas quando ocorre failover devem ser revertidas, enquanto os efeitos de transações confirmadas todos devem ser preservados.

Durante o failover, os aplicativos cliente perder sua conexão com o SQL server e devem se reconectar ao continuar o processamento. Se a conexão cliente para o servidor estiver sem estado, (por exemplo, aplicativos que são desenvolvidos usando o Microsoft Internet Information Server [IIS] são sem monitoração de estado) o cliente reconecta-se ao servidor e continua o processamento. A menos que o cliente e o servidor tiverem um estado comum (por exemplo, cursores abertos, variáveis de sessão, variáveis globais do Transact-SQL ou dados em tempdb), o failover não é transparente para o cliente. Nesses casos, você deve projetar o aplicativo de cliente para informar ao usuário que a conexão foi perdida, ou redefinir ou ter o aplicativo automaticamente restabelecer a conexão com o servidor. Qualquer transação que não tenha sido confirmada quando ocorre um failover é revertida.

A discussão de como os clientes lidam com falhas de servidor é o padrão para qualquer aplicativo de cliente do SQL Server, mesmo sem o uso de clusters e servidores virtuais. O processo de verificação de erro é bastante semelhante para um aplicativo de banco de dados de cliente para um cluster. Quando o cluster começa failover, o programa cliente recebe uma mensagem de erro na conexão de banco de dados. As mensagens de erro encontradas dependem o que o programa cliente está tentando fazer no momento.

Se um servidor do SQL Server é falha sobre pelo cluster admin , pacotes de redefinição TCP não serão enviadas. Se o processo do SQL Server é finalizado pelo sistema operacional (por kill.exe), os pacotes de redefinição são enviados.

Isso pode afetar o aplicativo cliente se o aplicativo não especificar um parâmetro de tempo limite de consulta ou um tempo limite de consulta de zero (0).

Se o aplicativo não tiver um valor de tempo limite de consulta, em seguida, abra conexões serão deixados no estado de estabelecido após um failover. O fato de que as conexões abertas não estão fechadas e que não mais pacotes TCP são enviados dessas conexões indica que as conexões estão completamente ociosas. Porque o failover não enviou qualquer TCP redefinir pacotes para o aplicativo cliente, essas conexões abertas espere os resultados da consulta indefinidamente (supondo um tempo limite infinito consulta) e potencialmente causar a conexão para parar de responder (travar).

Para resolver esse problema da perspectiva do aplicativo cliente, altere o tempo limite da consulta para um número finito.

Comportamento de falha do banco de dados virtuais

Quando um servidor de banco de dados virtual falhar, uma mensagem de erro Falha de link de conexão é retornada ao cliente espera. O banco de dados no nó com falha do cluster é desligado e reiniciado no mesmo nó pelos parâmetros definidos:

Start\Programs\Administrative Tools (Common)\Cluster Administrator\Group\Failover\Properties
				
O limite de padrão de Failover do grupo é 10 reinicia em um período de 6 horas antes que ocorra um failover para o nó restante. No entanto, o SQL Server reiniciar limite, que pode ser verificada através das propriedades do SQL Server no recurso de cluster do SQL Server, tem um limite padrão de reinicializações de três em que o SQL Server em 900 segundos e por padrão afeta o grupo. Se um cliente tenta se conectar ao servidor, enquanto um banco de dados está sendo recuperado, o cliente recebe uma mensagem de erro de recuperação do banco de dados de aguardar e deve repetir após uma pequena pausa.

Considerações sobre SQL Server 6.5 e SQL Server 7.0

SQL Server 6.5 e SQL Server 7.0 agem exatamente como descrito na seção anterior "Comportamento de falha de banco de dados virtual".

Quando o SQL Server 7.0 é executado como um servidor virtual SQL Server 7.0 oferece suporte a apenas um endereço IP mas poderá escutar nas portas adicionais conforme configurado pelo cliente. Isso é descrito no tópico "Vários escuta em TCP/IP Ports" no seguinte artigo da Base de dados de Conhecimento Microsoft:
254321INF: Requisitos de servidor em cluster do SQL, Don'ts e avisos básicos

Considerações sobre o Microsoft SQL Server 2000

SQL Server 2000 tem algumas diferenças no comportamento das versões de SQL Server 6.5 e SQL Server 7.0.

uso de porta do SQL Server 2000

Por padrão, uma instância nomeada escuta em uma porta dinâmica. Na primeira vez que o servidor inicia com uma porta definida como zero (0), o servidor solicita um número de porta livre do sistema operacional e, em seguida, o servidor escuta nessa porta. O servidor registros isso para o registro e, em seguida, usa a mesma porta toda vez.

Se um servidor é configurado para escutar uma porta dinâmica e o servidor não conseguir escutar na porta dinâmica na inicialização, o servidor escolhe outra porta.

Se você configurou uma porta estática durante a instalação ou após a instalação usando o utilitário de rede do servidor tenta escutar em TCP/IP se esta porta está em uso.

Clientes detectarão o número da porta para se conectar no caso de uma instância nomeada ou um com um número de porta não padrão.

As informações de conexão serão gravadas no cache "LastConnect" nessa chave do Registro:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\supersocketnetlib\lastConnect
Você encontrará as entradas para cada servidor e o método que foi usado para conectá-los no registro.

O cliente tentar reutilizar as informações de conexão em cada conexão, a menos que ele falha e, em seguida, re-negotiates as novas informações. Isso pode acontecer se o número da porta tiver sido alterado porque alguém foi alterado ou se fosse uma porta dinâmica foi re-assigned devido a uma porta em uso.

Conexões interrompidas

Existem três maneiras de que uma conexão pode ser interrompida:
  1. O servidor falhar; o processo termina por sendo killed (sistema eliminar de identificação de processo do servidor [ spid ]) ou uma violação de acesso (VA) ou algo faz com que o sistema operacional ou falha do serviço necessário.
  2. Falha de hardware do computador ou perda de energia.
  3. Desligamento do servidor.
Cada uma dessas conexões desfeitas exibem diferentes comportamentos vistos no computador cliente.
  1. No caso onde um servidor falhar, o cliente receberá uma mensagem de erro desfeitos conexão imediatamente. Você pode simular esse comportamento conectando-se com o OSQL, executar uma consulta longa e usar KILL para encerrar o processo do SQL Server. O cliente é encerrado com uma mensagem de erro ODBC.
  2. Uma falha de máquina é mais complicada. Pode alterar o comportamento um pouco com base em como a perda de conexão for detectada.

    Se o cliente estiver no meio de ler as informações, a perda de conexão pode ser detectada imediatamente porque os dados pára.

    Se o cliente está apenas esperando para resultados, o comportamento é ligeiramente diferente. O comportamento depende da configuração atividade do computador cliente.

    No Microsoft Windows 2000 Keep Alive é definida pelo código do cliente em uma base por conexão. Por padrão, atividade é definido como 30 segundos. Isso significa que se o soquete morre ele será detectada dentro de 30 segundos e o cliente recebe uma mensagem de erro. No Microsoft Windows NT 4.0, atividade não pode ser definida em uma base por conexão. Manter Alive deve ser definido para todo o computador, assim afetar todos os aplicativos no servidor.

    As chaves de registro são que está sendo referenciadas são:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters KeepAliveTime\REG_DWORD 30000

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters KeepAliveInterval\REG_DWORD 1000
  3. Quando você inicia um desligamento do servidor, o servidor aguarda um tempo para os clientes concluir. No entanto, se o cliente ainda está executando o servidor interrompe os threads dentro do servidor. Eliminar os threads pode também causar mensagens de erro diferentes no cliente. Mensagens de erro podem incluir uma conexão interrompida erro; no entanto, na maioria das vezes você ver essa mensagem de erro:
    "Ocorreu um erro desconhecido, conexão pode ter sido encerrada pelo servidor".
    O código de erro nativo a ODBC estiver definido como zero (0) nesse caso, mas é retornado como uma mensagem de erro ao cliente.

Referências

Para obter mais informações sobre o comportamento do cliente servidor virtual SQL no SQL Server 2005, visite o seguinte site da Web Microsoft Developer Network (MSDN):
http://msdn2.microsoft.com/en-us/library/ms189585.aspx

Propriedades

ID do artigo: 273673 - Última revisão: terça-feira, 4 de dezembro de 2007 - Revisão: 7.3
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 6.5 Enterprise Edition
  • Microsoft SQL Server 7.0 Enterprise Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Palavras-chave: 
kbmt kbhowto kbsql2005cluster kbclientserver kbinfo KB273673 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: 273673

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