Nous avons deux serveurs SQL de production exécutant SQL Server 2005 SP4 avec une mise à jour cumulative 3. Les deux serveurs fonctionnent sur des machines physiques identiques. DELL PowerEdge R815 avec 4 processeurs 12 cœurs et 512 Go (oui Go) de RAM, avec 10 Go de disques connectés iSCSI SAN pour toutes les bases de données et journaux SQL. Le système d'exploitation est Microsoft Windows Server 2008 R2 Enterprise Edition avec toutes les mises à jour SP et Windows. Le lecteur du système d'exploitation est une matrice RAID 5 de 3 disques SAS de 2,5 pouces de 15 Go de 72 Go. Le SAN est un Dell EqualLogic 6510 avec 48 disques de 10 000 SAS de 3,5 pouces, configuré en RAID 50, découpé en plusieurs LUN pour les 2 serveurs SQL, et également partagé avec une machine Exchange et plusieurs serveurs VMWare.
Nous avons plus de 20 bases de données, dont 11 sont mises en miroir avec une haute disponibilité à l'aide d'un serveur témoin. Le serveur témoin est une machine moins puissante exécutant une instance SQL Server qui n'est utilisée que pour fournir des services témoins. La plus grande base de données en miroir fait 450 Go et génère environ 100 à 300 iops. Le moniteur de mise en miroir de bases de données signale un taux d'envoi actuel d'environ 100 Ko à 10 Mo par seconde, et une surcharge de validation de miroir de (généralement) 0 millisecondes. Le serveur miroir n'a aucun problème à suivre le principal.
Nous rencontrons régulièrement des basculements en miroir. Parfois, une seule base de données basculera, d'autres fois presque toutes les bases de données basculeront simultanément. Par exemple, hier soir, 10 des 11 bases de données ont été basculées, la base de données restante est restée accessible jusqu'à ce que je la bascule manuellement.
J'ai suivi plusieurs étapes de dépannage pour tenter d'identifier le problème, mais jusqu'à présent je n'ai pas pu résoudre le problème:
1) La machine est livrée avec une carte réseau Gigabit Broadcom BCM5709C NetXtreme II à 4 ports que nous avons initialement utilisée comme connexion réseau principale. Nous avons depuis installé un adaptateur de serveur Intel (R) PRO / 1000 PT double port sur les deux machines pour éliminer la carte réseau comme problème.
2) Toutes les bases de données ont une sauvegarde complète automatique tous les soirs avec une sauvegarde de journal pour les bases de données impliquées dans la mise en miroir. L'utilisation du fichier journal est surveillée et est rarement utilisée à plus de 15%. Le fichier journal de la base de données principale est de 125 Go, composé de 159 fichiers journaux virtuels dont la taille varie de 511 Mo à 1 Go. TempDB est sur son propre LUN et se compose de 24 fichiers de 2 Go.
3) Le journal SQL Server sur le témoin ne montre aucune erreur autre que: La connexion en miroir à «TCP: //SQL02.DOMAIN.INET: 5022» a expiré pour la base de données «Data» après 30 secondes sans réponse. Vérifiez le service et les connexions réseau.
Le journal SQL Server sur les serveurs principal et secondaire affiche des messages relatifs à la mise en miroir:
La connexion en miroir à «TCP: //SQL01.DOMAIN.INET: 5022» a expiré pour la base de données «Data» après 30 secondes sans réponse. Vérifiez le service et les connexions réseau.
La base de données en miroir "Data" fait passer les rôles de "PRINCIPAL" à "MIRROR" en raison de la synchronisation des rôles. (La synchronisation est mal orthographiée ici volontairement, car c'est précisément la façon dont le message réel est affiché.)
La base de données en miroir "Data" fait passer les rôles de "PRINCIPAL" à "MIRROR" en raison du basculement.
La base de données en miroir "Data" fait passer les rôles de "MIRROR" à "PRINCIPAL" en raison du basculement du partenaire.
Les services SQL Server continuent de fonctionner et les connexions réseau semblent rester en place. Nous avons constamment entre 500 et 2500 sessions connectées à chaque serveur (principalement des applications robotiques qui se connectent aux files d'attente de Service Broker sur une seule base de données).
4) TCP Chimney et RSS, etc. sont désactivés à l'aide de la syntaxe NET SH.
5) J'ai exécuté SQL Server 2005 Best Practices Analyzer sur les deux machines et je ne trouve rien d'autre que l'erreur très occasionnelle 833 du journal des événements d'application, dont aucune ne coïncide avec les événements de basculement:
SQL Server a rencontré 1 occurrence (s) de demandes d'E / S prenant plus de 15 secondes pour terminer sur le fichier [F: \ Data.MDF] dans la base de données [Data] (9). Le descripteur de fichier du système d'exploitation est 0x00000000000010A0. Le décalage de la dernière longue E / S est: 0x000007d4b10000).
6) Parfois, nous voyons "Le client n'a pas pu réutiliser une session avec SPID XXX, qui avait été réinitialisée pour le regroupement de connexions. Cette erreur peut avoir été provoquée par l'échec d'une opération antérieure. Consultez les journaux d'erreurs pour les opérations ayant échoué immédiatement avant ce message d'erreur. . " généré par les deux serveurs. Il ne semble pas y avoir de messages "antérieurs" qui indiquent un problème.
7) Parfois, le courrier de la base de données écrit une erreur dans le journal des événements d'application:
Type d'exception: Microsoft.SqlServer.Management.SqlIMail.Server.Common.BaseException Message: une erreur s'est produite sur la connexion. Raison: le délai a expiré. Le délai d'expiration s'est écoulé avant la fin de l'opération ou le serveur ne répond pas., Paramètres de connexion: Nom du serveur: MGSQL02, Nom de la base de données: msdb Données: System.Collections.ListDictionaryInternal TargetSite: Void OpenConnection (Microsoft.SqlServer.Management.Common. SqlConnectionInfo) HelpLink: NULL Source: DatabaseMailEngine
Informations StackTrace sur Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.ConnectionManager.OpenConnection (SqlConnectionInfo ci) sur Microsoft.SqlServer.Management.SqlIMail.Server.DataAccess.DataAccessAdapter.OpenConnection (String dbServerName, String dbName Password ) sur Microsoft.SqlServer.Management.SqlIMail.IMailProcess.QueueItemProcesser.ProcessQueueItems (String dbName, String dbServerName, Int32 lifetimeMinimumSec, LogLevel loggingLevel)
Je crois que les délais d'attente provoquent le basculement; qu'est-ce qui pourrait provoquer ces délais? Évidemment, s'il y avait un problème de réseau réel tel qu'un mauvais câble ou un mauvais commutateur, cela pourrait entraîner une perte de paquets et donc un délai d'attente, mais quelles autres choses pourraient entraîner des délais d'attente? Blocage? Si MSDB ou une autre base de données système avait un délai d'E / S, cela pourrait-il provoquer le basculement de la mise en miroir?
Merci pour tout conseil!
MSDN a ce qui suit à dire sur le mécanisme de temporisation lui-même :
Le mécanisme de temporisation de mise en miroir
Étant donné que les erreurs logicielles ne sont pas détectables directement par une instance de serveur, une erreur logicielle peut potentiellement faire attendre indéfiniment une instance de serveur. Pour éviter cela, la mise en miroir de bases de données implémente son propre mécanisme de délai d'expiration, basé sur chaque instance de serveur dans une session de mise en miroir envoyant un ping sur chaque connexion ouverte à un intervalle fixe.
Pour garder une connexion ouverte, une instance de serveur doit recevoir un ping sur cette connexion dans le délai d'expiration défini, plus le temps nécessaire pour envoyer un ping supplémentaire. La réception d'un ping pendant le délai d'attente indique que la connexion est toujours ouverte et que les instances de serveur communiquent via elle. Lors de la réception d'un ping, une instance de serveur réinitialise son compteur de délai d'attente sur cette connexion.
Si aucun ping n'est reçu sur une connexion pendant le délai d'expiration, une instance de serveur considère que la connexion a expiré. L'instance de serveur ferme la connexion expirée et gère l'événement d'expiration en fonction de l'état et du mode de fonctionnement de la session.
netsh interface tcp show global spectacles:
Receive-Side Scaling State : disabled
Chimney Offload State : disabled
NetDMA State : enabled
Direct Cache Acess (DCA) : disabled
Receive Window Auto-Tuning Level : disabled
Add-On Congestion Control Provider : ctcp
ECN Capability : disabled
RFC 1323 Timestamps : disablednetsh interface ipv4 show dynamicportrange tcp
Protocol tcp Dynamic Port Range
Start Port : 1025
Number of Ports : 64510SELECT name, value_in_use FROM sys.configurations
Requêtes distribuées ad hoc 0
masque d'E / S d'affinité 0
masque d'affinité 0
affinity64 I / O mask 0
affinity64 mask 0
Agent XPs 1
autoriser les mises à jour 0
crainte activée 0
seuil de processus bloqué 5
mode d'audit c2 0
clr activé 1
conformité aux critères communs activée 0
seuil de coût pour le parallélisme 4
cross db propriété chaînage 0
seuil du curseur -1
Base de données Mail XPs 1
langue de texte intégral par défaut 1033
langue par défaut 0
trace par défaut activée 1
interdire les résultats des déclencheurs 0
facteur de remplissage (%) 0
ft bande passante d'exploration (max) 100
ft bande passante d'exploration (min) 0
ft notifier la bande passante (max) 100
ft notifier la bande passante (min) 0
index créer de la mémoire (Ko) 0
résolution xact dans le doute 0
pooling léger 0
verrous 0
degré maximum de parallélisme 6
plage d'exploration maximale du texte intégral 4
mémoire maximale du serveur (Mo) 393216
taille max. de texte (B) 65536
nombre maximal de threads de travail 0
rétention des médias 0
mémoire minimale par requête (Ko) 2048
mémoire minimum du serveur (Mo) 52427
déclencheurs imbriqués 1
taille de paquet réseau (B) 1400
Procédures d'automatisation Ole 1
objets ouverts 0
Temporisation (s) PH 60
précalculer le rang 0
boost prioritaire 0
limite de coût du gouverneur de requête 0
attente (s) de requête -1
intervalle de récupération (min) 0
accès à distance 1
connexions d'administration à distance 0
délai (s) de connexion à distance 20
proc à distance trans 0
délai d'expiration de la requête à distance 600
XP de réplication 0
rechercher les processus de démarrage 0
serveur récursivité de déclenchement 1
définir la taille de l'ensemble de travail 0
afficher les options avancées 1
XP SMO et DMO 1
SQL Mail XPs 0
transformer les mots de bruit 0
coupure de l'année à deux chiffres 2049
connexions utilisateur 0
options utilisateur 4216
Procédures de l'assistant Web 0
xp_cmdshell 1
Il y a quelque temps, j'ai modifié manuellement la mirroring_connection_timeoutvaleur de toutes les bases de données en miroir à 30 secondes pour tenter de résoudre le problème; cela a simplement augmenté la durée entre les événements de basculement. Avec le mirroring_connection_timeoutparamètre défini par défaut sur 10 secondes, nous constatons beaucoup plus de basculements.
Un commentaire m'avait demandé de m'assurer qu'IPSec était désactivé, donc je poste le contenu de plusieurs netshcommandes qui affichent la configuration IPSec du système d'exploitation:
C: \> netsh ipsec dynamic afficher tout Aucune stratégie actuellement attribuée Politiques Mainmode non disponibles. Stratégies Quickmode non disponibles. Filtres génériques en mode principal non disponibles. Filtres spécifiques en mode principal non disponibles. Filtres génériques Quickmode non disponibles. Filtres Quickmode spécifiques non disponibles. Les associations de sécurité IPsec MainMode ne sont pas disponibles. Les associations de sécurité IPsec QuickMode ne sont pas disponibles. Paramètres de configuration IPsec ------------------------------ StrongCRLCheck: 1 IPsecexempt: 3 Statistiques IPsec ---------------- Association active: 0 Décharger les SA: 0 Clé en attente: 0 Ajouts de clés: 0 Suppressions de clés: 0 ReKeys: 0 Tunnels actifs: 0 Mauvais lots SPI: 0 Pkts non déchiffrés: 0 Pkts non authentifiés: 0 Pkts avec détection de relecture: 0 Octets confidentiels envoyés: 0 Octets confidentiels reçus: 0 Octets authentifiés envoyés: 0 Octets authentifiés reçus: 0 Octets de transport envoyés: 0 Octets de transport reçus: 0 Octets envoyés dans les tunnels: 0 Octets reçus dans les tunnels: 0 Octets déchargés envoyés: 0 Octets déchargés reçus: 0 C: \> netsh ipsec statique afficher tout ERR IPsec [05072]: aucune stratégie dans le magasin de stratégies
MISE À JOUR: 2012-12-20
Nous avons maintenant déplacé nos systèmes de production sur SQL Server 2012. Nous exécutons cela depuis le matin du 17 décembre - jusqu'à présent, aucun basculement. Cependant, quelques jours sont bien dans ce que nous avons vu avec les systèmes basés sur 2005.
Dans un effort pour documenter les performances de nos nouveaux systèmes, j'ai examiné sys.dm_os_wait_statsplus attentivement; et remarqué DBMIRROR_DBM_EVENT, qui est un type d'attente non documenté. Graham Kent chez Microsoft a un article intéressant concernant le dépannage des basculements inattendus et ce type d'attente. Je récapitulerai ses conclusions ici:
Le client connaissait une énorme chaîne de blocage construite sur une base de données OLTP à volume élevé où tous les bloqueurs principaux attendaient sur DBMIRROR_DBM_EVENT. Voici la séquence d'événements que j'ai vécue:
Examinez la chaîne de blocage elle-même - ho aide ici car tout ce que nous pouvons voir, c'est que nous attendons sur DBMIRROR_DBM_EVENT
Vérifiez la source du type d'attente non documenté. Évidemment, vous ne pouvez pas faire cela en dehors de MS, mais je peux dire qu'au moment de l'écriture, ce type d'attente représente l'attente utilisée lorsque le principal attend que le miroir durcisse un LSN, ce qui signifie que la transaction dont il fait partie ne peut pas être validée . Cela pointe immédiatement tout à fait spécifiquement au problème que le principal ne peut pas commettre de transactions pendant qu'il attend sur le miroir. Maintenant, nous devons rechercher pourquoi le miroir ne commet pas de transactions ou pourquoi le principal ne sait pas si c'est le cas.
Passez en revue les tables système msdb
(a) Examinez la table [backupset] pour voir si la taille des journaux produits au moment du problème est nettement supérieure à la normale. S'ils étaient exceptionnellement grands, il se peut que le miroir soit inondé de transactions et ne puisse tout simplement pas suivre le volume. C'est pourquoi les livres en ligne vous diront parfois de désactiver la mise en miroir si vous devez effectuer une opération journalisée exceptionnellement volumineuse telle qu'une reconstruction d'index. (référence pour savoir pourquoi c'est à http://technet.microsoft.com/en-us/library/cc917681.aspx ). Ici, j'ai utilisé le TSQL suivant
SELECT backup_set_id,backup_start_date,database_name,has_bulk_logged_data,backup_size / 1000
FROM [backupset]
where backup_start_date between '2011-01-05 14:00:00' and '2011-01-05 19:30:00'
go
select round((AVG(backup_size)/1000),0)
FROM [backupset]
where database_name = 'mydatabase'(b) d'autre part, j'ai regardé les données dans les tableaux [dbm_monitor_data]. La clé ici est de localiser le délai dans lequel nous avons eu un problème, puis de voir si nous avons subi des changements importants dans l'un des éléments suivants:
log_flush_rate
send_queue_size
send_rate
redo_queue_size
redo_rateCe sont tous des indicateurs similaires à la partie (a) en ce qu'ils peuvent montrer un composant ou un morceau d'architecture qui ne répondait pas. Par exemple, si send_queue commence soudainement à croître mais que la file d'attente re_do n'augmente pas, cela impliquerait que le principal ne peut pas envoyer les enregistrements de journal au miroir, vous voudrez peut-être regarder la connectivité ou les files d'attente du courtier de service traitant des transmissions réelles.
Dans ce scénario particulier, nous avons noté que tous les compteurs semblaient avoir des valeurs étranges, en ce sens qu'il y avait des sauvegardes de journaux en cours de tailles normales, mais il n'y avait aucun changement d'état, 0 file d'attente d'envoi, 0 file d'attente de rétablissement, un taux d'envoi plat et un plat refaire le taux. Ceci est très étrange car cela implique que le moniteur DBM n'a pu enregistrer aucune valeur de n'importe où au cours de la période de problème.
Consultez les journaux d'erreurs SQL Server. Dans ce cas, il n'y a eu aucune erreur ou message d'information, mais dans d'autres scénarios comme celui-ci, il est très courant que des erreurs dans la plage 1400 soient signalées, dont vous pouvez trouver des exemples à d'autres endroits dans mes autres blogs en miroir, tels que cet exemple d'erreur 1413
Passez en revue les fichiers de trace par défaut - dans ce scénario, je n'ai pas reçu les traces par défaut, mais ce sont des sources fantastiques d'informations sur les problèmes DBM, car elles enregistrent les événements de changement d'état sur tous les partenaires. Ceci est documenté ici:
Classe d'événement de changement d'état de mise en miroir de bases de données
Cela vous donne souvent une excellente image de scénarios tels que lorsque la connectivité réseau a échoué entre un ou tous les partenaires, puis l'état du partenariat par la suite.
CONCLUSIONS:
Dans ce scénario particulier, il me manque actuellement 2 points clés de données, mais cela mis à part, je peux toujours faire une hypothèse raisonnable sur les informations ci-dessus. Nous pouvons certainement dire que le blocage a été causé par le fait que DBM a été activé à cause des bloqueurs qui attendent tous sur le type d'attente DBMIRROR_DBM_EVENT. Étant donné que nous savons que nous n'avons pas inondé le miroir d'une opération journalisée volumineuse et que ce déploiement s'exécute normalement correctement dans ce mode, nous pouvons exclure les opérations volumineuses inhabituelles. Cela signifie que nous avons 2 candidats potentiels à ce stade:
Problèmes matériels sur la connectivité entre certains ou tous les partenaires.
Épuisement du processeur sur le serveur miroir - tout simplement incapable de suivre les redos - l'épuisement du processeur peut lui-même provenir d'un processus en dehors de SQL Server ou en dehors de ce partenariat miroir.
Un problème avec le code miroir lui-même (nous aurions vraiment besoin de quelques vidages de mémoire pour le confirmer).
Sur la base de l'expérience, je soupçonne 1 ou 2, mais je garde toujours un esprit ouvert à propos de 3 également, nous essayons de collecter plus de données maintenant pour examiner ce problème plus en détail.