Discussion :

[franckgar]

Bonjour,

J'ai une application .net qui communique avec une base de données SQL server via des commandes ADO et l'appel de procédures stockées. La base client est relativement importante et ensuite 12 personnes travaillent en simultanée. Tout fonctionnaire parfaitement jusqu'à la semaine dernière où j'ai compressé les données de leur table qui nous sert de GED (par code, j'ai extrait chaque fichier, je l'ai zippé puis remis en base). Cette action a permis de réduire l'espace occupé par la table puisque nous sommes passés de 15Go à 1Go. Jusque là tout fonctionnait encore bien. Pour libérer réellement la taille des fichiers de la base, j'ai réduit la taille des fichiers via SQL Server manager (clic droit sur la base / tache/ réduire les fichiers).
La base est passée de 25Go à Go. Depuis cette action, mes clients n'arrêtent pas d'avoir des messages d'erreur "délai d'attente dépassé" ,après environ 2h d'utilisation du logiciel, sur l'appel de procédures qui ne posaient pas de problème avant. J'ai tout de suite réaugneté la taille du fichier de base et exécuter une ps pour reconstruire tous les index qui étaient très fragmentés. Malgré ses actions, les messages réapparaissent sans cesse. Dans le gestionnaire de tâches, je vois que SQL Server monte vite en mémoire pour occuper 1,7Go. Je n'ai plus idées et toute aide sera la bienvenue. Pour dernière info, dans le code ADO, je fais un begintransaction() même pour faire un simple select mais je ferme la connexion toute de suite derrière.
Merci à tous de votre éventuelle aide....

[zinzineti]

1. Donne-nous d'abord les résultats de cette requête

Code :

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

1
2
3
4
5
6
7
8
9
 
xp_msver ProductName
  ,ProductVersion
  ,Language
  ,Platform
  ,WindowsVersion
  ,ProcessorCount
  ,ProcessorType
  ,PhysicalMemory

2. la base de données est toujours accessible après les opérations ?

3. augmente le niveau de trace dans la procédure stockée, l'idée est de cibler à quel point la procstock bloque

[franckgar]

Voici les informations obtenues après exécution de la requête:1 ProductName NULL Microsoft SQL Server
ProductVersion 589824 9.00.1399.06
Language 1036 Français (France)
Platform NULL NT INTEL X86
WindowsVersion 143851525 5.0 (2195)
ProcessorCount 2 2
ProcessorType 586 PROCESSOR_INTEL_PENTIUM
PhysicalMemory 3920 3920 (4109914112)

[zinzineti]

As-tu réaliser des backups avant tes opérations ?

[franckgar]

Du temps de midi, je me suis connectée sur le serveur SQL de mon client. J'ai arrêté le service puis je l'ai redémarré. La taille mémoire occupée par SQL Server est maintenant aux alentours de 500Mo et on peut utiliser l'application sans problème (je viens de lancer l'affichage de listes qui étaient à l'origine de message tout à l'heure et là elles passent sans problème. Mais à mon avis, dans 1 ou 2h, les problèmes vont ressurgir.
Sinon lorsque les messages apparaissent, je vois un lock mais la base de données n'est pas bloquée. Je vais essayer d'augmenter le niveau de trace des procédures stockées qui posent le plus de problèmes.
Pour les backups, j'ai fait une sauvegarde de la base avant toutes ses modifs mais en une semaine le client a saisi pas mal de données.

[zinzineti]

Tu peux vérifier si /3GB est activé sur le serveur avec requette

Code :

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

1
2
3
SELECT physical_memory_in_bytes
,virtual_memory_in_bytes 
FROM sys.dm_os_sys_info

Si ce n'est le cas alors active /3GB (le redémarrage du serveur est indispensable pour prendre en compte cette option)

[zinzineti]

Affiche le résultat de cette requête. Remplace "TaBase" par le nom de ta base de données

Code :

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

1
2
3
 
SELECT DATABASEPROPERTY('TaBase', 'IsAutoShrink ')
,DATABASEPROPERTY('TaBase', 'IsAutoClose');

[franckgar]

Voici les résultats des requêtes:

Code :

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

1
2
3
4
5
6
7
8
9
SELECT physical_memory_in_bytes
,virtual_memory_in_bytes 
FROM sys.dm_os_sys_info
 
4109914112	2147352576
 
SELECT DATABASEPROPERTY('sociel', 'IsAutoShrink ')
,DATABASEPROPERTY('sociel', 'IsAutoClose');
NULL       0

Je ne comprends pas votre phrase "Si ce n'est le cas alors active /3GB ???"

[zinzineti]

Voici les résultats des requêtes:
SELECT physical_memory_in_bytes
,virtual_memory_in_bytes
FROM sys.dm_os_sys_info

4109914112 2147352576

La valeur de virtual_memory_in_bytes = 2147352576 montre que /3GB n'est pas activé. L'activation du /3GB permettra à SQL SERVER d'avoir une mémoire RAM plus grande, proche de 3GB.

SELECT DATABASEPROPERTY('sociel', 'IsAutoShrink ')
,DATABASEPROPERTY('sociel', 'IsAutoClose');
NULL 0

Celà veut dire l'option AutoClose est à OFF --> C'est bien.

par contre

Code :

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

SELECT DATABASEPROPERTY('sociel', 'IsAutoShrink ')

renvoie NULL ??? !!! Essaye encore ceci et donne le résultat

Code :

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

SELECT DATABASEPROPERTY('sociel', 'IsAutoShrink ')

[franckgar]

Je viens de refaire la requête SELECT DATABASEPROPERTY('sociel', 'IsAutoShrink ') et le résultat est 0.
Peux tu me dire comment on active \3Go ?

[zinzineti]

Complément d'infos. Il me semble que vous travaillez sous Windows server 2000;
donc vous ne pouvez pas utiliser le commutateur /3GB dans le fichier Boot.ini avec Windows 2000 Server, mais vous pouvez l'utiliser avec les versions Microsoft Windows 2000 Advanced Server ou Microsoft Windows 2000 Datacenter.

Quelle est l'edition de OS ?

ouvre la console DOS et exécute ceci :

Code :

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

systeminfo

et donne le résutat

[zinzineti]

Je viens de refaire la requête SELECT DATABASEPROPERTY('sociel', 'IsAutoShrink ') et le résultat est 0.

C'est bien.

Peux tu me dire comment on active \3Go ?

Attention avant donne d'abord la version de l' OS

tu peux le voir à l'aide de la commande DOS

Code :

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

systeminfo

[franckgar]

L'os est Microsoft Windows 2000 version 5.00.2195 avec service pack 4

[zinzineti]

L'os est Microsoft Windows 2000 version 5.00.2195 avec service pack 4

ça j'ai déjà vu avec la commande xp_msver.

Quand tu exécutes la commande systeminfo, qu'est ce qui est indiqué devant

Nom du système d'exploitation ? OU OS Name ?

[franckgar]

La commande systeminfo ne fonctionne pas sur Windows Server 2000 mais en lançant la commande msinfo32, je pense avoir obtenu la même chose. Je vois Nom du système d'exploitation et non OS Name.

[zinzineti]

La commande systeminfo ne fonctionne pas sur Windows Server 2000 mais en lançant la commande msinfo32, je pense avoir obtenu la même chose. Je vois Nom du système d'exploitation et non OS Name.

Qu'est ce qui est indiqué pour Nom du système d'exploitation ?

[franckgar]

Il est mentionné Microsoft Windows 2000 Server

[zinzineti]

Il est mentionné Microsoft Windows 2000 Server

Vous ne pouvez pas allouer plus de 4 Go de mémoire physique à une application dans Windows 2000 Server, car l'extension d'adresse physique (PAE) n'est pas disponible dans Microsoft Windows 2000 Server. De même, vous ne pouvez pas utiliser le commutateur /3GB dans le fichier Boot.ini avec Windows 2000 Server, mais vous pouvez l'utiliser avec les versions Microsoft Windows 2000 Advanced Server ou Microsoft Windows 2000 Datacenter. Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.

Source ici

[zinzineti]

Il est mentionné Microsoft Windows 2000 Server

On retenir que vous travaillez avec SQL Server 2005 RTM avec les options IsAutoShrink et IsAutoShrink bien configurées:
AutoClose --> OFF
IsAutoShrink --> OFF

Apparemment vous ne pouvez pas activer le commutateur /3GB vu que l'OS n'est pas Microsoft Windows 2000 Advanced Server ou Microsoft Windows 2000 Datacenter.

Des pistes :

1. Regarder s'il n'y pas des services inutiles qui tournent pour rien

2. Faites de la place sur vos disques durs

3. Examiner les nombres de lignes renvoyées par vos requêtes

4. Optimiser votre procédure stockées (si possible)

5. poser les bon index

6....

Peux-tu nous dire le nombre de lignes dans les principales tables ?

[franckgar]

Tout d'abord merci du temps que vous me consacrez et des nombreuses infos que vous m'avez apportées.
Mais il y a vraiment quelque chose de bizarre que je ne m'explique pas. Si j'arrête le service SQL puis que je le redémarre, l'application est plutôt rapide, les requêtes s'exécutent vite. Mais les performances se dégradent au fil de l'eau et au bout de 2h, on arrive à un blocage (délai temps exécution expiré). C'est vrai que j'utilise parfois des procédures stockées dynamiques et il me semble que SQL server ne peut pas utiliser d'index pour exécuter ces requêtes. Mais dans 80% des cas, les procédures sont simples et j'ai essayé de créer les index les plus adaptés. Au vu de tout ce que j'ai pû lire, mes tables ne contiennent pas énormément de données (max 120000 pour les plus grosses) par contre je fais beaucoup de jointure sur des champs date et des clés étrangères.
Autre chose, j'ai lu qu'il était préférable de dédier un serveur à la base de données et que 10% d'espace disponible était le minimum requis. Je viens de constater que mon client se sert du serveur pour stocker les fichiers de tous ses salariés et que par conséquent il ne restait que 9.8Go de libre sur les 92 de départ. Est ce que ce manque de place pourrait expliquer mon blocage et le fait que SQL Server ne fait que grossir en mémoire sans jamais la libérer même quand plus personne n'est connecté à l'application?