Discussion :

[StringBuilder]

Bonjour,

J'ai un serveur qui ne répond plus aux requêtes.
Il accepte les connexions, mais quand on lance une requête, il ne répond plus.

Je soupçonne (peut-être à tord) un fichier de dponnées plein (log ou data de tempdb certainement).

Voici les symptômes :
- Aucune requête lancée depuis les applications n'aboutit sur aucune base
- Je ne peux pas me connecter avec Management Studio
- Avec SQLCMD je peux me connecter, faire "use mabase" sans souci, mais aucune requête n'aboutit sur aucune base
- Encéphalogramme plat (ou presque) niveau disques
- CPU à 100% sur un coeur

Le process de sauvegarde qui tourne toutes les 10 minutes pour sauvegarer les logs indique qu'il n'arrive pas à mettre à jour MSDB

Que faire ?

Je n'ose pas redémarrer le service ni le serveur de peur que ça ne redémarre plus du tout.

Log du soft de backup :

Code sql :

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

1
2
3
4
5
6
7
 
Error during LOG backup of CRM on gshupdatebdd1.updatecld.local !!!
Le délai a été dépassé pendant l'attente de l'optimisation de la requête. Réexécutez la requête.
Impossible d'ajouter à la base de données msdb un enregistrement d'historique ou de détail de sauvegarde ou de restauration. Il y a sans doute un problème avec la base msdb. La restauration ou la sauvegarde a cependant réussi.
76 pages traitées pour la base de données 'CRM', fichier 'CRM_log' dans le fichier 1.
BACKUP LOG a traité avec succès 76 pages en 0.079*secondes (7.472*Mo/s).
Error during backup of CRM on gshupdatebdd1.updatecld.local. Will not clean up older backups

Sortie de SQLCMD :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
C:\Users\sdevidal>sqlcmd -E
1> use master
2> go
Le contexte de la base de données a changé*; il est maintenant 'master'.
1> use msdb
2> go
Le contexte de la base de données a changé*; il est maintenant 'msdb'.
1> select * from sys.columns;
2> go
 
Sqlcmd*: avertissement*: la dernière opération a été interrompue parce que l'uti
lisateur a appuyé sur Ctrl+C.
1> exec sp_spaceused;
2> go
 
Sqlcmd*: avertissement*: la dernière opération a été interrompue parce que l'uti
lisateur a appuyé sur Ctrl+C.
1> use master;
2> go
Le contexte de la base de données a changé*; il est maintenant 'master'.
1> select * from sys.database_files
2> go
 
Sqlcmd*: avertissement*: la dernière opération a été interrompue parce que l'uti
lisateur a appuyé sur Ctrl+C.
1>
2>
3>
4>
5> use crm;
6> go
Le contexte de la base de données a changé*; il est maintenant 'CRM'.
1> select count(*) from te_isi_fi;
2> go

[StringBuilder]

La moindre tentative d'accès à une donnée échoue.

En revanche, le moteur tourne bien :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
Sqlcmd*: avertissement*: la dernière opération a été interrompue parce que l'uti
lisateur a appuyé sur Ctrl+C.
1> select 1 from te_isi_fi where id = 0
2>
3> go
 
Sqlcmd*: avertissement*: la dernière opération a été interrompue parce que l'uti
lisateur a appuyé sur Ctrl+C.
1> select 1
2> go
 
-----------
          1
 
(1 lignes affectées)
1>

[StringBuilder]

L'Agent SQL Server ne voulait pas redémarrer.

Au bout d'un moment le service a bien voulu redémarrer, et depuis tout est revenu dans l'ordre.

J'ai fait le tour des bases, et toutes ont tous leurs fichiers en autogrowth et aucun disque n'est plein...

Comprends pas...

[Invité]

tes traces parlent de problème sur msdb.
Est-ce que les fichiers de msdb sont en autogrowth ?
Est-ce qu'il n'y aurait pas une table énorme dedans ? J'avais déjà eu un problème avec une table système relative aux jobs qui grossissait en permanence mais c'était sur une version 2005 ou 2008.

[StringBuilder]

Merci pour ta réponse.

Oui, autogrowth est activé pour chaque fichier de chaque base de donnée (et ils sont tous à leur taille initiale, que j'avais largement sur-évalué histoire d'être tranquille).

Pour ce qui est de la table énorme dans MSDB j'ai effectivement le souci.
Je l'ai "résolu" en lançant, après chaque sauvegarde, une purge des traces de sauvegardes pour les fichiers qui n'existent plus (sinon SQL Server conserve la trace de TOUTES les sauvegardes de TOUTES les bases, y compris des logs)
=> Du coup un backup des LOG toutes les 10 minutes de chacune des bases, je te laisse imaginer le mammouth au bout d'un an... alors qu'on ne conserve ces backups que 3 semaines...

J'ai pas le code de mon programme sous la main, je le posterai demain.

[SQLpro]

L'agent SQL a une rétention paramétrable.

A +