Discussion :

[Vulpus]

Bonjour,

Je ne suis pas un professionnel de l'informatique. Je suis médecin généraliste et j'utilse l'informatique dans mon travail.

Il semblerait que ce "lieu" soit le seul forum français sur SQL-serveur...c'est pourquoi je me permets d'y poster mon message.

Si ce forum n'est réservé qu'aux professionnels ou si je ne suis pas dans le bon sous-forum, merci de me l'indiquer.

J'expose tout de même mon problème en souhaitant vivement que vous puissiez m'aider.

Le progiciel de mon cabinet est EASYPRAT de la société MAIDIS, basé sur sa plate-forme logicielle Amies. Il tourne sous "MS SQLServer 2000".

http://www.maidis.fr/fr/nos-produits...ville/easyprat

Il y a 2-3 ans en raison du ralentissement du logiciel, le service de maintenance a procédé à une intervention sur SQL. Ma base dépassait les 2 Go et il semblait nécessaire de faire une modification.

Cependant la base fait maintenant plus de 6 Go et le chargement des dossiers les plus anciens met plus de 50 secondes à se faire.

Après vérification de l'intégrité de la base et compactage de celle-ci, la hot-line me certifiait que le problème était résolu. Or rien n'a changé.

Cependant, en cherchant moi-même et en utilisant les outils disponibles avec le logiciel, j'ai ré-indexé la base. Le résultat est incroyable, puisque l'ouverture des dossiers patients, y compris les plus anciens donc les plus "lourds", est quasi-instantanée.

Mais au démarrage suivant de l'ordinateur il faut recommencer. L'avantage de la ré-indexation est perdu. Cette manoeuvre dure plus de 10 minutes, et je dois recommencer tous les matins...

Avez-vous une idée ?
Avez-vous besoin de précisions ?
Dois-je m'adresser ailleurs ?

Quoi qu'il en soit je vous remercie par avance pour vos réponses.

[mikedavem]

Bonsoir,

Après vérification de l'intégrité de la base et compactage de celle-ci, la hot-line me certifiait que le problème était résolu. Or rien n'a changé.

Visiblement la hotline ne connaît pas le fonctionnement d'un serveur de bases de données. Le compactage et la vérification d'intégrité ne règle en rien les problèmes de performances. Le compactage a l'effet inverse.

Maintenant il se peut que votre serveur de bases de données ne comporte aucun plan de maintenance (plan de maintenance comporte en générale une réindexation de la base + mise à jour des statistiques des données de la base). Ces plans de maintenance sont nécessaires pour garder un fonctionnement optimum de votre base surtout si votre application met à jour intensivement vos données.

Maintenant d'autres facteurs pourront tôt ou tard être la source de vos problèmes comme la configuration de votre serveur ? Est il assez dimensionné pour un fonctionnement actuel de votre base ? Est ce que les fichiers de bases de données sont correctement dimensionnées ? Si non alors ceux-ci engendront une fragmentation importante de vos partitions de disques etc ... etc ...

A mon humble avis je pense qu'il pourrait être nécessaire de faire faire un audit de votre serveur par une personne compétente en la matière mais la mise en place d'un plan de maintenance adéquate peut dans un premier temps vous sortir d'affaire ...

++

[Vulpus]

Merci pour cette réponse rapide et les conseils donnés.

Dans la pratique, les recommandations que vous donnez devraient revenir à la hot-line... un contrat payant existe.

Dans les faits, je ne m'y connais pas assez pour confier à qqn d'extérieur à Maidis la mise en place d'un plan de maintenance ou un audit du serveur.

Je vais donc tenter d'argumenter avec vos conseils auprès de la hot-line.

Le fait que mon problème ait potentiellement une solution me rassure.

Merci.

[zinzineti]

Bonjour,
Cependant, en cherchant moi-même et en utilisant les outils disponibles avec le logiciel, j'ai ré-indexé la base. Le résultat est incroyable, puisque l'ouverture des dossiers patients, y compris les plus anciens donc les plus "lourds", est quasi-instantanée.
Mais au démarrage suivant de l'ordinateur il faut recommencer. L'avantage de la ré-indexation est perdu. Cette manoeuvre dure plus de 10 minutes, et je dois recommencer tous les matins...

La base de données SQL 2000 et l'application EASYPRAT sont hébergées sur la même machine ?
Quelles sont les caractéristiques de la machine qui héberge la base de données ?
C'est à dire :
- OS ?
- RAM ?
- CPU ?
- capacité disque ?


A+

[Vulpus]

Bonjour,

La base SQL-200 et l'application sont sur la même machine.

L'OS est Windows XP Pack 3 Professionnel

L'ordi :Intel Core 2 Duo CPU
P8400 @ 2.26GHz
2.99 Go de RAM

Disque dur partitionné :

Disque C : 147 Go dont 95.8 de libre où se trouvent la base et l'application
Disque D : 121 Go dont 19de libre où se trouvent des données diverses

[SQLpro]

Dans la pratique, les recommandations que vous donnez devraient revenir à la hot-line... un contrat payant existe.

Effectivement c'est à eux de vous donner des conseils et de mettre en œuvre les moyens, pas à vous.

Enfin, si le logiciel est hébergé sur la même machine que le SGBDR, alors il faut limiter le RAM utilisée par SQL Server, sinon il la bouffera toute entière au détriment de l'application (SQL Server étant préemptif et prioritaire). Dans ce cas, reconfigurez le avec

Code :

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

1
2
EXEC sp_configure 'max server memory', 1024
RECONFIGURE

Ce qui limitera SQL Server à 1 Go de RAM

Faites aussi le ménage sur votre disque D. Le taux de remplissage étant de plus de 80% c'est embêtant, sans être alarmant. Pensez à supprimer les fichiers inutiles. Éventuellement passez votre base en mode de journalisation "simple" afin d'éviter d'obtenir un fichier du journal de transaction démesuré !
Ceci se fait par :

Code :

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

1
2
ALTER DATABASE <mabase>
SET RECOVERY SIMPLE;

Mais évitez la défragmentation système. En cas de plantage, vous perdriez votre base.

Que dit la requête :

Code :

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

1
2
3
4
5
6
SELECT name, status & 1 AS autoclose,
             status & 4194304 AS autoshrink,
             DATABASEPROPERTYEX(name, 'IsAutoCreateStatistics') AS autoCstats,
             DATABASEPROPERTYEX(name, 'IsAutoUpdateStatistics') AS autoUstats,
             DATABASEPROPERTYEX(name, 'Recovery') AS JTmode
FROM sysdatabases

A +

[zinzineti]

Bonjour,
Mais au démarrage suivant de l'ordinateur il faut recommencer. L'avantage de la ré-indexation est perdu. Cette manoeuvre dure plus de 10 minutes, et je dois recommencer tous les matins...

Pour compléter tout ce qui a été dit, il faut savoir que lorsque vous arrêter/redémarrer votre machine hébergeant le serveur SQL, vous perdez tout ce qui est mis en mémoire cache. Qu'est ce qui est mis en mémoire cache ?
1.) Les plans d'exécutions c'est à dire le plan d'exécutions des requêtes et leur contexte d'exécutions

2.) Les statistiques : toutes les données collectées par SQL Server.


Résultat : Lenteur observée lors de l'utilisation de votre application après Arrêt/Redémarrage.

Leçon de cette situation : Vous venez de mettre en évidence un principe fondamental des SGBD, On n'arrête pas un serveur de SGBD comme on peut arrêter/redémarrer son PC de bureau !

Solution provisoire pour votre cas : Eviter d'arrêter votre machine après l'opération de maintenance sur SQL Server

A Moyen terme : Pensez à mettre votre SQL Serveur sur une machine différente de la machine qui héberge votre applicatif EASYPRAT . faîtes la suggestion à l'éditeur de l'applicatif EASYPRAT.

Merci de nous faire un retour

A+

[Vulpus]

Je vous remercie pour vos réponses.
Mon travail ne m'a pas laissé beaucoup de temps pour approfondir vos conseils jusqu'à ce jour.

Je ne m'y connais pas beaucoup sur SQL mais vos remarques me laissent penser que cette gestion de données semblent plus adaptée à une structure moyenne ou grosse (la plupart des médecins généralistes n'ont qu'un seul ordinateur qui ne tourne pas en permanence...).

Où dois-je taper les codes et les requêtes que vous me proposez (je suis vraiment un novice) ? Dans "analyseur de requêtes" ?

[zinzineti]

Oui dans "analyseur de requêtes".

[Vulpus]

Le code

Code :

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

1
2
EXEC sp_configure 'max server memory', 1024
RECONFIGURE

a fonctionné mais n'a pas apporté de changement dans le fonctionnement du logiciel.


La requête:

ALTER DATABASE <amies>
SET RECOVERY SIMPLE;

me renvoie le message suivant :

Serveur*: Msg 170, Niveau 15, État 1, Ligne 1
Ligne 1 : syntaxe incorrecte vers '<'.
Serveur*: Msg 195, Niveau 15, État 1, Ligne 2
'RECOVERY' n'est pas un Instruction SET reconnu.

La requête :

SELECT name, STATUS & 1 AS autoclose,
STATUS & 4194304 AS autoshrink,
DATABASEPROPERTYEX(name, 'IsAutoCreateStatistics') AS autoCstats,
DATABASEPROPERTYEX(name, 'IsAutoUpdateStatistics') AS autoUstats,
DATABASEPROPERTYEX(name, 'Recovery') AS JTmode
FROM sysdatabases

donne:

http://www.casimages.com/img.php?i=1...0852151877.jpg

[zinzineti]

Le code

[COLOR="blue"]

La requête:

ALTER DATABASE <amies>
SET RECOVERY SIMPLE;

me renvoie le message suivant :

Serveur*: Msg 170, Niveau 15, État 1, Ligne 1
Ligne 1 : syntaxe incorrecte vers '<'.
Serveur*: Msg 195, Niveau 15, État 1, Ligne 2
'RECOVERY' n'est pas un Instruction SET reconnu.

Il y a ce message d'erreur parce que vous avez laisser le nom de votre base de données entre les caractères '<' et '>'

la requête à exécuter devrait être :

Code :

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

ALTER DATABASE [amies] SET RECOVERY SIMPLE;

Vu le résultat affiché dans votre pièce jointe, la base [amies] est déjà en mode SIMPLE. Ce n'est donc pas la peine d'exécuter cette commande.

Voici ce que je vous propose :

Puisque vous avez un contrat de maintenance, rapportez les anomalies constatées à la société qui s'occupe de cette maintenance.
Parce que si vous faites des manipulations sans les consulter ça peut poser d'autres problèmes...

A+

[elsuket]

Bonjour,

Il est quand même fou d'implémenter une application reposant sur un SGBD sans savoir comment le moteur de base de données fonctionne.

Certes, cette application est destinée à de l'utilisation de type bureau, mais la base de données n'est pas statique, elle vit, donc il faut qu'elle soit maintenue.

Si l'on devait faire une base de données des entreprises qui vendent des logiciels reposant sur une base de données sans en connaître le fonctionnement, je doute de plus en plus que cette base de données ne doive pas être maintenue

Question subsidiaire : est-ce que le fait de mettre en veille le PC qui héberge une instance SQL Server provoque la perte du cache de SQL Server ?

@++

[mikedavem]

Question subsidiaire : est-ce que le fait de mettre en veille le PC qui héberge une instance SQL Server provoque la perte du cache de SQL Server ?

En principe non. La veille normale d'un poste de travail alimente toujours le processeur, la RAM etc ... et la veille prolongée recopie le contenu de la RAM sur disque avant de couper l'alimentation ..

++

[zinzineti]

Bonjour,
Il est quand même fou d'implémenter une application reposant sur un SGBD sans savoir comment le moteur de base de données fonctionne.

Là tu mets le doigt sur un problème majeur. Au fait les éditeurs de ces applications (et aussi les clients) sont plus préoccupés par l'aspect "sapin de noël" que le fonctionnement du moteur SGBD.

Certes, cette application est destinée à de l'utilisation de type bureau, mais la base de données n'est pas statique, elle vit, donc il faut qu'elle soit maintenue. Si l'on devait faire une base de données des entreprises qui vendent des logiciels reposant sur une base de données sans en connaître le fonctionnement, je doute de plus en plus que cette base de données ne doive pas être maintenue
@++

Et nombreux et très nombreux sont les entreprises qui sont dans cette situation. Mais personnellement je constate que pour des applications qui reposent sur le SGBD ORACLE, les éditeurs (et les clients) acceptent de jouer le jeu, c'est à dire essaye de se conformer aux bonnes pratiques :
- Serveur Dédié pour le SGBD
- Process d'administration régulière
- ...
Mais lorsqu'il s'agit du SGBD SQL Server, ohhh là là tout le monde se dit expert, à commencer par les développeurs qui font pleins de conneries à commencer par la conception du model de données, choix des types de données, longueur des types de données, tables sans jointures, base mal taillée, aucune connaissance sur la volumétrie, et la liste est non exhaustive
Et le pire c'est qu'il existe une idée très répandue du style "SQL Server c'est facile à utiliser et facile à administrer" ou "On n'a pas besoin de formation pour maîtriser SQLServer !"

Que faut-il faire pour une conscientisation efficace à tous les niveaux ?

[SQLpro]

Le code

EXEC sp_configure 'max server memory', 1024
RECONFIGURE

a fonctionné mais n'a pas apporté de changement dans le fonctionnement du logiciel.

Normal, vous n'en verrez les effets que par rapport au comportement conjoint de votre application et du SGBDR dans des cas limites.

La requête:

ALTER DATABASE <amies>
SET RECOVERY SIMPLE;

me renvoie le message suivant :

Serveur*: Msg 170, Niveau 15, État 1, Ligne 1
Ligne 1 : syntaxe incorrecte vers '<'.
Serveur*: Msg 195, Niveau 15, État 1, Ligne 2
'RECOVERY' n'est pas un Instruction SET reconnu.

La requête :

SELECT name, STATUS & 1 AS autoclose,
STATUS & 4194304 AS autoshrink,
DATABASEPROPERTYEX(name, 'IsAutoCreateStatistics') AS autoCstats,
DATABASEPROPERTYEX(name, 'IsAutoUpdateStatistics') AS autoUstats,
DATABASEPROPERTYEX(name, 'Recovery') AS JTmode
FROM sysdatabases

donne:

http://www.casimages.com/img.php?i=1...0852151877.jpg

Tout ceci est correctement paramétré.

Comme on vous l'as dit, évitez d'arrêter votre PC. Ceci efface le cache et oblige à des lecture disque. De plus la défragmentation ou la reconstruction des index doit avoir lieu régulièrement. En production c'est au moins 1 fois par semaine (dans votre cas, de mono utilisation, c'est suffisant) mais plus généralement 1 fois par jour.

A +

[Ptit_Dje]

Mais au démarrage suivant de l'ordinateur il faut recommencer. L'avantage de la ré-indexation est perdu. Cette manoeuvre dure plus de 10 minutes, et je dois recommencer tous les matins...

Bonjour,

Vous pouvez penser a creer un job qui s'execute automatiquement au demarrage de l'agent et qui effectue cette tache.
Ca vous evitera de devoir lancer l'operation manuellement.
Seul probleme, elle prendra toujours 10 minutes pour s'executer... Le temps d'un petit cafe

[Vulpus]

Vous pouvez penser a creer un job qui s'execute automatiquement au demarrage de l'agent et qui effectue cette tache.
Ca vous evitera de devoir lancer l'operation manuellement.
Seul probleme, elle prendra toujours 10 minutes pour s'executer... Le temps d'un petit cafe

Bonjour,

L'idée de la manoeuvre qui se lance automatiquement (et même celle du petit café du matin...) m’intéresse. Mais je ne suis pas du tout spécialiste et je n'ai vraiment aucune notion pour mettre cela au point.

Concernant tout ce qui a été dit depuis le début (et je vous en remercie tous), pouvez-vous m'aider à exprimer en termes professionnels (cela aura peut être plus de poids...) les doléances et les conseils que je pourrais formuler auprès de ma maintenance (notamment passage à la dernière version de MS-SQL Server) ?

Merci.

[Ptit_Dje]

Bonjour,

A cette adresse les grosses etapes pour creer un job:
http://www.quackit.com/sql_server/tu...agent_jobs.cfm

Il faut configurer celui-ci en fonction des etapes que le support vous a recommander d'effectuer pour defragmenter votre base.
Quelles sont-elles ?

[Vulpus]

Il faut configurer celui-ci en fonction des etapes que le support vous a recommander d'effectuer pour defragmenter votre base.
Quelles sont-elles ?

En fait, il existe avec l'application un utilitaire qui propose différents choix sur lesquels il suffit de cliquer : vérification de l'intégrité, compactage de la base, ré-indexation de la base, sauvegarde de la base et restauration de la base...