Discussion :

[Kropernic]

Hello,

Pour la question, tout est dans le titre. J'ai déjà jeté un oeil dans les logs de l'instance SQL mais je ne trouve rien d'explicite. Au mieux, j'ai ceci :

09/22/2014 02:54:25,spid47s,Unknown,Database mirroring is inactive for database 'company'. This is an informational message only. No user action is required.
09/22/2014 02:54:13,spid4s,Unknown,SQL Server has encountered 761 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [D:\MSSQLSERVER\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\tempdb.mdf] in database [tempdb] (2). The OS file handle is 0x00000000000004BC. The offset of the latest long I/O is: 0x00000114e30000
09/22/2014 01:01:54,spid69,Unknown,DBCC CHECKDB (SALESREPORTS) WITH all_errormsgs<c/> data_purity executed by KAUFHOF\svc32_sql found 0 errors and repaired 0 errors. Elapsed time: 0 hours 0 minutes 0 seconds. Internal database snapshot has split point LSN = 00000e22:00000091:0001 and first LSN = 00000e20:00000079:0024.

Où on voit un DBCC CHECKCD qui se passe apparemment sans problème, puis un truc dont j'ignore de quoi il s'agit et en suite, un truc qui parle du mirroring (j'ai la même pour 4 DB différentes).

Et pendant que j'écris, je réalie que c'est en fait le DBCC CHECKDB qui n'a pas pu se faire du au fait que la DB en question avait basculée et vu qu'elle était en restoring, forcément pas moyen de faire l'opération demandée.

Je cherche donc à savoir quand et pourquoi ces DB's auraient basculées. Une idée de où/comment chercher ?

[SQLpro]

SQL Server has encountered 761 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file
ça c'est typique d'un problème de latence de disque.... Si tu es sur un SAN qui utilise le même réseau il est probable que l'encombrement du réseau ait jouée sur la rapidité de réponse dudit réseau et provoqué le basculement ceci dans une solution de mirroring synchrone !

A +

[Kropernic]

Euh bah non. Le serveur a ses propres disques bien à lui.

Mais bon, avec des IO qui mettent aussi longtemps, j'imagine que le problème vient quand même du disque.

Je vais demander à l'équipe hardware s'il y a moyen de faire un diagnostique des disques.

[dbaffaleuf]

Merci de poster l'ERRORLOG complet.

[Kropernic]

Merci de poster l'ERRORLOG complet.

Le voilà en pièce jointe.

Pour info, les bases ont forcément du basculer soit tard hier soir, soit tôt ce matin.

Sinon j'aurai eu plus de jobs en erreur.

[mikedavem]

09/22/2014 02:54:25,spid47s,Unknown,Database mirroring is inactive for database 'company'. This is an informational message only. No user action is required.
09/22/2014 02:54:13,spid4s,Unknown,SQL Server has encountered 761 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [D:\MSSQLSERVER\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\tempdb.mdf] in database [tempdb] (2). The OS file handle is 0x00000000000004BC. The offset of the latest long I/O is: 0x00000114e30000

Visiblement le problème viendrait à ce moment ... A peu près 10 secondes entre l'enregistrement des I/O qui prennent plus de 15 secondes et la détection du problème au niveau du miroir (temps du timeout). Est-ce lié ? Probablement mais rien de bien spécifique dans le journal. Tu n'aurais pas les logs de l'autre serveur également (celui devenu principal à ce moment là)? As-tu regardé également au niveau du journal d'événement Windows à la même heure pour un complément d'information ?

Le problème des longues I/O peut être en effet bien souvent lié au stockage mais pas forcément à tous les coups. Un autre problème classique est l'exécution d'un antivirus .. mais si cela t'arrive fréquemment il faudra investiguer plus loin.

++

[Kropernic]

Voici le log du serveur devenu principal à ce moment-là.

Aller voir dans les journaux d’événements windows est la première chose que j'ai faite mais je n'ai rien trouvé de particulier (mis à part les entrées qui sont déjà reprises dans le log de sql serveur).

Je ne pense pas qu'il y ait un antivirus sur ce serveur mais je vais demander.

C'est la première fois que ce problème survient. Je vais garder ça à l'oeil et croiser les doigts pour que ce soit anecdotique.

[mikedavem]

09/22/2014 02:54:22,spid53s,Unknown,The mirroring connection to "TCP://xxxxx:7022" has timed out for database "DocumentsEvolution" after 10 seconds without a response. Check the service and network connections.
09/22/2014 02:54:22,spid53s,Unknown,Error: 1479<c/> Severity: 16<c/> State: 1.
09/22/2014 02:54:22,spid59s,Unknown,The mirroring connection to "TCP://xxxxx:7022" has timed out for database "Tickets" after 10 seconds without a response. Check the service and network connections.
09/22/2014 02:54:22,spid59s,Unknown,Error: 1479<c/> Severity: 16<c/> State: 1.

Ok donc on retrouve bien notre fameux timeout de 10s l'autre côté et un basculement automatique ...

Sans plus d'information je serais tenté de dire que le problème d'IO semble être le déclencheur ici (longues I/O sur tempdb) ... on pourrait supposer que le serveur SQL à ce moment là ne répondait plus correctement aux pings du miroir ce qui a fait basculer tes sessions en miroir. Il ne reste plus qu'à trouver pourquoi les IO sont devenues subitement longues à cette heure-ci sur ce serveur.

++

[dbaffaleuf]

Et 10 secondes de timeout par défaut avec un witness c'est juste s'exposer à des bascules intempestives comme c'est la cas ici. Je pense qu'il vaut mieux mettre une valeur qui indique une déconnexion franche comme 40 secondes ou 1 minute. Ça ne changera pas grand chose sur ton délai de réaction...

[Kropernic]

A mon avis, ça doit être le timeout par défaut.

Je ne savais meme pas qu'on pouvait le changer. J'ai mis le mirroring en place il y a 2 ans puis je n'ai plus jamais eu à y toucher.

Je vais regarder comment faire ce changement. C'est vrai que c'est une bonne chose en soi.

Sinon, apparemment, le problème viendrait du fait que la batterie du controleur raid était déchargée et qu'il a du faire je sais pas quoi à cause de ça. Ce qui a fait que les disques ne répondaient plus.
C'est quand même bizarre cette affaire. Je ne vais pas lacher l'équipe système jusqu'à savoir le pourquoi du comment.

[dbaffaleuf]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ALTER DATABASE <mabase> SET PARTNER TIMEOUT 40;
GO

Et pour la batterie, elle alimente le cache. Si elle tombe en rade, le cache ne doit plus être accessible, et tout est descendu sur les disques, donc en direct sur un bon gros RAID à parité (je suppose)

[Kropernic]

Merci pour le timeout. Ca m'a évité la (possiblement longue) recherche.

C'est paramétré.

Sinon pour ce qui de la batterie et de la fonction, je n'en ai malheureusement aucune idée . Mais si tu le dis, je veux bien te croire.

Vais maintenant aller les voir pour comprendre pourquoi cette batterie tombe en rade comme ça.

[dbaffaleuf]

Ce n'est pas anormal qu'elle tombe en rade, mais sur la plupart des baies il y a des alertes lorsque le niveau de charge de la batterie ou son obsolescence devient critique. La question c'est plutôt :

1 - La baie a-t-elle remonté les alertes ?
2 - Si oui pourquoi n'ont-elles pas été vues ?

[Kropernic]

Apparemment (ie d'après ce qu'on m'a dit), la batterie remonte effectivement des alertes dans les journaux d’événements windows et ce ne serait pas la première fois que ça arrive mais c'est la première fois que cela provoque un basculement des db's.

Toujours apparemment, c'est un batterie qui se recharge de manière automatique. Il ne faudrait donc pas la remplacer (du moins pas encore).

Maintenant quant au pourquoi elles n'ont pas été vues, ce n'est pas moi qui gère le hardware mais je ne crois pas qu'il y a quelque chose qui va chercher automatiquement dans les journaux d'événements les alertes de ce genre.

[SQLpro]

Visiblement les gens systèmes sont assez nullissime chez vous car lorsque l'on utilise un cache en écriture avec un SGBDR on s'assure par tous les moyens que la batterie fonctionne.
Il faut donc impérativement générer une alerte par mail ou SMS en cas de problème à ce niveau et que le responsable de la maintenance intervienne au plus tôt.

Sinon, désactiver le cache en écriture.

En cas de défaut majeur, la base peut devenir irrécupérable !

A +