Description des connexions de client SQL Server virtuel

Traductions disponibles Traductions disponibles
Numéro d'article: 273673 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Sommaire

Résumé

Cet article présente certains des principes fondamentaux sur les connexions SQL de Microsoft Virtual Server Client.

Plus d'informations

Important Cette section, la méthode ou la tâche contient vous explique comment modifier le Registre. Toutefois, des problèmes graves peuvent se produire si vous modifiez le Registre de façon incorrecte. Par conséquent, assurez-vous que vous procédez comme suit. Pour une meilleure protection, sauvegardez le Registre avant de le modifier. Ensuite, vous pouvez restaurer le Registre en cas de problème. Pour plus d'informations sur la façon de sauvegarder et restaurer le Registre, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la base de connaissances Microsoft :
322756Comment faire pour sauvegarder et restaurer le Registre de Windows


Comportement de serveur virtuel SQL client

Microsoft Cluster Server (MSCS) offre une plate-forme fiable et robuste sur laquelle vous pouvez créer des applications de SQL Server critiques. Il est inutile de modifier la plupart des applications de serveur pour les utiliser avec MSCS. Toutefois, les applications basées sur les transactions (par exemple, serveurs de base de données, tels que Microsoft SQL Server) nécessitent généralement modification supplémentaire afin que si le serveur tombe en panne, prise en charge du basculement empêche correctement la perte d'intégrité transactionnelle. Développement d'une application client pour fonctionner avec MSCS est relativement simple. Vous devez concevoir des applications avec récupération de la base de données et n'oubliez pas de vérification des erreurs.

Même sans avoir recours à des clusters, un serveur SQL serveur reprend automatiquement toutes les bases de données lorsque le serveur est redémarré. Pour garantir qu'une base de données est restaurée dans un état d'une application cohérente, utilisation de la base de données transactions, de sorte que basculement se produit dans la base de données dans un état cohérent et correctement. Toutes les transactions sont incomplets lors du basculement doivent être restaurées, alors que les effets de toutes les transactions validées doivent être préservés.

Au cours du basculement, les applications client perdent leur connexion au serveur SQL Server et doivent se reconnecter à poursuivre le traitement. Si la connexion client au serveur est sans état, (par exemple, les applications développées à l'aide de Microsoft Internet Information Server [IIS] sont sans état) le client se reconnecte au serveur et continue le traitement. À moins que le client et le serveur n'ont un état commun (par exemple, les curseurs ouverts, variables de session, les variables globales de Transact-SQL ou les données de tempdb), le basculement n'est pas transparent pour le client. Dans ces cas, vous devez concevoir l'application client pour informer l'utilisateur que la connexion a été soit perdu, ou, réinitialiser ou a l'application automatiquement rétablir sa connexion au serveur. Toute transaction n'a pas été validée lors d'un basculement sur incident est annulée.

La discussion de comment clients traitent des défaillances du serveur est standard pour n'importe quelle application de client SQL Server, même sans avoir recours à des clusters et serveurs virtuels. L'erreur processus de vérification est très similaire pour une application de base de données client pour un cluster. Lorsque le cluster démarre le basculement, le programme client reçoit une message d'erreur sur la connexion de base de données. Les messages d'erreur rencontrés dépendent de ce que le programme client essaie de faire à ce moment.

Cas de défaillance d'un serveur SQL Server par cluster admin, les paquets de réinitialisation TCP ne sont pas envoyés. Si le processus SQL Server est arrêté par le système d'exploitation (par kill.exe), les paquets réinitialisation sont envoyés.

Cela peut affecter l'application cliente si l'application ne spécifie pas un paramètre de délai d'attente de requête ou un délai d'attente de requête de zéro (0).

Si l'application n'a pas une valeur du délai d'attente de la requête puis ouvrez connexions seront laissées dans l'état ESTABLISHED après un basculement. Le fait que les connexions ouvertes ne sont pas fermées et qu'aucun paquet TCP supplémentaire n'est envoyés à partir de ces connexions indique que ces connexions sont complètement inactives. Étant donné que le basculement n'a pas envoyé tout TCP réinitialiser des paquets à l'application cliente, ces connexions ouvertes attendre les résultats de la requête indéfiniment (en supposant un délai d'expiration des requêtes infini) et potentiellement entraîner le cesser de répondre (se bloquer) de la connexion.

Pour résoudre ce problème d'un point de vue application client, modifiez le délai d'expiration des requêtes à un nombre fini.

Un comportement d'échec de la base de données virtuel

En cas de panne d'un serveur de base de données virtuel, un message d'erreur lien échoué de connexion est renvoyée au client en attente. La base de données sur le n?ud défaillant du cluster est arrêté et redémarré sur le même n?ud par les paramètres définis :

Start\Programs\Administrative Tools (Common)\Cluster Administrator\Group\Failover\Properties
				
Le seuil de par défaut de basculement de groupe est 10 redémarrages dans un délai de six heures avant un basculement se produit sur le n?ud restant. Toutefois, le serveur SQL Server redémarrer seuil, qui peut être vérifiée par le biais des propriétés de SQL Server sur la ressource de cluster SQL Server, dispose d'un seuil par défaut de trois redémarrages sur que SQL Server de 900 secondes et par défaut affecte le groupe. Si un client tente de se connecter au serveur pendant une base de données est en cours de restauration, le client reçoit un en attente pour message d'erreur de récupération de base de données et doit recommencer après une courte pause.

Considérations relatives à SQL Server 6.5 et SQL Server 7.0

SQL Server 6.5 et SQL Server 7.0 se comportent exactement comme décrit dans la section précédente de "Problème de défaillance virtuel de base de données".

Lorsque SQL Server 7.0 s'exécute comme un serveur virtuel SQL Server 7.0 prend en charge uniquement une adresse IP mais peut écouter sur des ports supplémentaires tels que configurés par le client. Cela est décrit dans la rubrique «Multiple Listen-On Ports TCP/IP» dans l'article suivant de la base de connaissances Microsoft :
254321INF: En cluster SQL Server pense-bête, à ne pas faire et avertissements de base

Considérations relatives à Microsoft SQL Server 2000

SQL Server 2000 possède certaines différences de comportement à partir des versions de SQL Server 6.5 et SQL Server 7.0.

Utilisation du port SQL Server 2000

Par défaut, une instance nommée écoute sur un port dynamique. La première fois que le serveur démarre avec un port la valeur zéro (0), le serveur demande un numéro de port libre du système d'exploitation et ensuite le serveur écoute sur ce port. Le serveur enregistre ce dans le Registre, puis utilise le même port chaque fois.

Si un serveur est configuré pour écouter sur un port dynamique et le serveur ne parvient pas à écouter sur le port dynamique au démarrage, le serveur choisit un autre port.

Si vous avez configuré un port statique pendant l'installation ou après l'installation à l'aide de l'utilitaire réseau serveur il ne parvient pas à écouter sur TCP/IP si ce port est en cours d'utilisation.

Clients détectent le numéro de port pour se connecter au cas d'une instance nommée ou l'autre avec un numéro de port autre que celle par défaut.

Les informations de connexion sont écrit dans le cache «LastConnect» dans cette clé de Registre :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\supersocketnetlib\lastConnect
Vous trouverez des entrées pour chaque serveur et la méthode qui a été utilisée pour se connecter à leur dans le Registre.

Le client tente de réutiliser les informations de connexion sur chaque connexion, à moins qu'elle ne tombe en panne et puis re-negotiates les nouvelles informations. Cela peut se produire si le numéro de port a changé car quelqu'un l'a changé ou s'il s'agit d'un port dynamique a été réaffecté due à un port en cours d'utilisation.

Connexions interrompues

Il existe trois manières qu'une connexion peut être interrompue :
  1. Le serveur tombe en panne ; le processus se termine en étant mis à mort (système kill de processus serveur ID [spid]) ou une violation d'accès (AV) ou autre chose provoque le système d'exploitation ou l'échec du service requis.
  2. Défaillance matérielle de machine ou de perte de puissance.
  3. Arrêt du serveur.
Chacune de ces connexions cassées présentent des comportements différents visibles sur l'ordinateur client.
  1. Dans le cas où un serveur tombe en panne, le client reçoit une connexion interrompue message d'erreur immédiatement. Vous pouvez simuler ce comportement en vous connectant avec OSQL, l'exécution d'une requête longue, puis utiliser KILL pour arrêter votre processus de SQL Server. Le client quitte avec un message d'erreur ODBC.
  2. Une défaillance machine est plus complexe. Le comportement pouvez modifier légèrement en fonction de comment la perte de connexion est détectée.

    Si le client est au milieu de la lecture des informations, la perte de connexion peut être détectée immédiatement car les données s'arrête.

    Si le client attend simplement les résultats, le comportement est légèrement différent. Le comportement dépend de la configuration Keep Alive de l'ordinateur client.

    Sous Microsoft Windows 2000 Keep Alive est définie par le code de client de connexion par connexion. Par défaut, Keep Alive est fixée à 30 secondes. Cela signifie que si le socket meurt il est détecté dans les 30 secondes et le client reçoit une message d'erreur. Sur Microsoft Windows NT 4.0, Keep Alive ne peut pas être définie sur une base par connexion. Conserver actif doit être définie pour l'ensemble de l'ordinateur, ce qui influence toutes les applications sur le serveur.

    Les clés de Registre sont auquel il est fait référence sont les suivantes :
    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. Lorsque vous initiez un arrêt du serveur, le serveur attend un certain temps pour les clients à la fin. Toutefois, si le client est toujours en cours d'exécution le serveur supprime les threads à l'intérieur du serveur. Mise à mort les threads peut-être également provoquer des messages d'erreur sur le client. Messages d'erreur peuvent inclure une connexion interrompue Erreur ; toutefois, la plupart du temps vous voyez cette message d'erreur :
    "Une erreur inconnue s'est produite, la connexion s'est peut-être terminée par le serveur".
    Le code d'erreur native de ODBC est défini à zéro (0) dans ce cas, mais il est retourné comme une message d'erreur au client.

Références

Pour plus d'informations à propos du comportement de client de serveur virtuel SQL dans SQL Server 2005, reportez-vous au site Web de MSDN (Microsoft Developer Network) à l'adresse suivante :
http://msdn2.microsoft.com/en-us/library/ms189585.aspx

Propriétés

Numéro d'article: 273673 - Dernière mise à jour: mardi 4 décembre 2007 - Version: 7.3
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft SQL Server 6.5 Édition Entreprise
  • Microsoft SQL Server 7.0 Édition Entreprise
  • Microsoft SQL Server 2000 Édition Entreprise
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Mots-clés : 
kbmt kbhowto kbsql2005cluster kbclientserver kbinfo KB273673 KbMtfr
Traduction automatique
IMPORTANT : Cet article est issu du système de traduction automatique mis au point par Microsoft (http://support.microsoft.com/gp/mtdetails). Un certain nombre d?articles obtenus par traduction automatique sont en effet mis à votre disposition en complément des articles traduits en langue française par des traducteurs professionnels. Cela vous permet d?avoir accès, dans votre propre langue, à l?ensemble des articles de la base de connaissances rédigés originellement en langue anglaise. Les articles traduits automatiquement ne sont pas toujours parfaits et peuvent comporter des erreurs de vocabulaire, de syntaxe ou de grammaire (probablement semblables aux erreurs que ferait une personne étrangère s?exprimant dans votre langue !). Néanmoins, mis à part ces imperfections, ces articles devraient suffire à vous orienter et à vous aider à résoudre votre problème. Microsoft s?efforce aussi continuellement de faire évoluer son système de traduction automatique.
La version anglaise de cet article est la suivante: 273673
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

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