Discussion :

[rehsinup]

Bonjour à tous,

Technicien dans une clinique, je but sur un problème sur un serveur SQL qui gère notre logiciel métier.
Depuis le 05 avril les sauvegardes des bases SQL ne se finissent pas "normalement", ce qui a pour cause de bloquer l'accès aux logiciels métier. Un plan de maintenance est en place, avec différentes opérations dont la sauvegardes des bases qui se déroule à 02h00.
Jusqu’à aujourd'hui j'ai eu 3 coupures de services le 05, le 09 et le 13 avril (à chaque fois les heures remontées par les utilisateurs se situe après 02h00) et à chaque fois une erreur dans la sauvegarde des bases. (mais très peu d'info) tous les autres jobs se passent bien. (sauvegardes des journaux, etc ..)

En copie un extrait du journal du Plan de maintenance.
Sur la sauvegarde des bases, 4 opérations sont effectuées ( vérification de l'intégrité, sauvegarde des bases, réduction de la taille et reconstruction de l'index)
J'ai remarqué (je sais pas si c'est lié) que les coupures interviennent tous les 4 jours ...
Avez vous une idée de ce qui pourrait expliquer cette panne soudaine ?
Merci d'avance

[ATMorphine]

Bonjour
il est possible que ça vienne de :

• shrinkfile (réduction de taille), pose des verrou exclusifs sur le fichier
• reconstruction d'index si rebuild dans l'option online = on
• du checkdb si l'option TABLOCK est spécifiée

Le shrinkfile est une bad practice, surtout si c'est la dernière étape car ça va défaire ce qui a été reconstruit.
La reconstruction d'index doit se faire sur des plages horaires adapté avec l'option online = on pour éviter les verrouillage (nécessite version enterprise), autrement il faut faire du reorganize

[rehsinup]

Merci pour ta réponse,
pour info les étapes sont dans l'ordre où elles se déroulent.
Ce que j'ai le plus de mal à comprendre c'est que ce problème survient comme ça de nul part alors que ça tournait sans problème depuis des mois.
Je vais vérifier tous les points que tu m'as donné et je fais un retour.

[SQLpro]

Déjà réduire la taille de vos fichier EST UNE STUPIDITÉ EFFARANTE !!! Lisez le livre SQL 2014 pour en savoir plus : http://www.amazon.fr/dp/2212135920/

Ensuite le message est clair : la commande à été arrêtée.
Ce peut être quelqu'un qui l'a fait volontairement, ou bien cela a été consécutif à l'arrêt du serveur SQL.
Regardez dans vos journaux d'événement de SQL Server pour savoir s'il n'y a pas des arrêts du serveur...

A +

[rehsinup]

bonjour,

je vais voir avec l'éditeur pourquoi il a mit une réduction des fichiers.
Pour ce qui est des pannes, j'ai oublié de préciser que lundi j’étais en télémaintenance au moment de la panne, le serveur SQL répondait bien au ping, tous les services SQL étaient démarrés, il m'a fallut par contre redémarrer le service SQL pour faire repartir l'application.
J'ai un autre serveur SQL qui contacte ce serveur par moment et au moment des pannes j'ai des "Query timeout expired basehtml".
On dirait qu'il y a comme un job qui se termine mal par moment et qui rend le serveur "inactif" .

[elsuket]

Bonjour,

Dans SQL Server Management Studio (SSMS), à partir de l'explorateur d'objets (que l'on obtient en pressant F8 s'il n'est pas présent à l'ouverture de SSMS), vous allez trouver les nœuds > Gestion > Journaux de SQL Server. Par défaut il y en a 6. Prenez celui qui contient la date de la dernière panne, et dites-nous ce que vous trouvez dans ce journal à l'heure où le problème s'est manifesté, ou avant.

@++

[rehsinup]

bonjour,

Dans les journaux SQL, on voit rien d'anormal pour les dates du 5/9 et 13, tout à l'air de bien se déroulé, on a le résultat des sauvegardes des bases


les seules erreurs que l'on trouve sont dans l'historique du plan de maintenance.
on voit dans les journaux du plan de maintenance un jour où tout se passe bien (le 12/04) et les autres jours de panne où il n'y a que 3 étapes au lieu de 4.

[SQLpro]

Quelle est la taille des fichiers de vos bases ainsi que le pas et le mode de croissance ?

A +