Discussion :

[DavidSEA]

Bonjour,
Je ne sais pas trop où poser la question, je tente ici au cas ou quelqu'un aurait été confronté au problème.
J'ai rencontré le cas il y a quelques temps, avec SQL 2008 (pas R2), sur un PC qui reste allumé 24h/24 7j/7.
La quantité de mémoire utilisée par le processus Lsass.exe grossit petit à petit (4Ko toutes les 20-30 update environ), ce qui a pour effet, au bout d'un temps quand même relativement long, d'essouffler Windows (XP SP3).
C'est un logiciel développé en Delphi 7, qui utilise la série de composants ADO pour se connecter à SQL Server via OLE. Le provider le pire est 'Microsoft OLE DB Provider for SQL Server', mais ça se produit également à moindre échelle avec 'SQL Server Native Client' ou 'SQL Server Native Client 10.0'. Je reproduis le phénomène sur mes VM.
Je n'ai pas de virus, d'ailleurs, lorsque je ne fais pas d'update, ça se stabilise, et je n'ai aucun des symptômes qui sont recensés lorsque le virus Sasser a infecté le processus Lsass.exe (puisque apparemment ça peut être le cas).
J'ai fait énormément de recherche sur internet. Il y a d'ailleurs beaucoup de messages concernant les pertes de mémoire ou l'utilisation intensive de CPU (ce qui n'est pas mon cas) par lsass.exe. Comme ce processus est utilisé pour la gestion de sécurité et d'authentification, je me dis que ça tourne peut-être autour de la façon de s'identifier sur SQL Server, mais je sèche complètement.
Un petit test simple permet de reproduire (chez moi) le phénomène : avec un simple fichier .udl (fichier de liaison de données), lorque je fais 'Tester la connexion', ça bouffe 4Ko à chaque fois...
Je suis donc à la recherche de pistes...
Merci à vous
David

[SQLpro]

Lass étant un processus système, vous devriez poser votre question dans un forum Windows.
Les accès à vos insistances SQL sont fait par une authentification Windows ?
Essayez de ne plus faire d'authentification Windows et voyez ce qui se passe en authentification purement SQL. SI le phénomène ne se reproduit pas, c'est que c'est bien la couche Windows qui pose problème.

A +

[DavidSEA]

Merci pour votre réponse.
J'utilise une authentification SQL (utilisateur sa), mais SQL est installé avec le mode mixte.
Mon soucis apparaît uniquement lors d'une connexion à SQL Server, je pensais donc que c'était lié à une config SQL.
Par contre, le 'Test Connexion' d'un fichier .udl ne fait pas grimper en mémoire le processus Lsass.exe sous Windows 7. Ça viens donc d'XP.
Je vais orienter mes recherches vers là...
Merci encore.

[SQLpro]

Windows XP n'est pas un OS serveur. SQL Server a besoin d'un OS Serveur comme Windows Server 2008 / 2008 R2 / 2012 pour fonctionner correctement.
N'en tirez donc pas de conclusions hâtives !

A +

[DavidSEA]

Microsoft préconise ceci :

Système d'exploitation pris en charge

Windows 7; Windows Server 2003; Windows Server 2008; Windows Server 2008 R2; Windows Vista; Windows XP

J'ai pas précisé, mais il s'agit de SQL Express...

[DavidSEA]

Bonjour,
Je ne sais pas si je dois mettre 'Résolu' ou pas, mais j'ai trouvé un palliatif :
j'ai 'tripoté' au hasard les paramètres de la connexion (fichier .udl, StringConnection), et je suis tombé sur le paramètre 'MARS Connection' ou 'MultipleActiveResultSets'. En mettant ce paramètre à 'True', le processus Lsass.exe ne bouffe plus de mémoire (6k en 8h...), et n'occupe plus du tout la CPU (0% contre 3-4% avant)...
Ce paramètre n'est dispo qu'avec le provider 'SQL Native Client'.
Ça me laisse perplexe ! Y a-t-il quelque chose qui saute au yeux de quelqu'un ?