Le Forum des Utilisateurs Sage

Bonjour à tous,

Je ne savais pas vraiement ou poster car mon problème concerne plustot un problème sql je pense.
Voila tout a commencer au mois de novembre où les utilisateurs de mon entreprise comment c'est a apercevoir des lenteurs de SAGE sous la ligne 100 v14.04 gestion commercial.
Chaque jours l'utilisation de SAGE est de pire en pire au point que je me fait tapé dessus (non je rigole)
Pour informations 15 personnes sont connecter sur la base en même temps, la base est hébergé sur un serveur SQL 2000 hébergé sur un serveur 2003.
Lorsque je regarde les logs du serveur rien à signaler sauf que le processus sql utilise le pc à 100% dans le gestionnaire des taches.
Après avoir fait faire toutes les manips possibles et inimaginable sur la base on me conseille de changer de serveur car celui n'est pas assez puissant.
La base fait 2,45 go pour 2go de ram, Or l'on me conseille le double de la base en mémoire.
Mais je ne voudrais pas racheter un serveur ce qui va faire exploser le budget sans être sur que cela fonctionne.
Qu'en pensez vous?

bonjour,
qu'est ce qui est long ?
ou ça rame ?
faudrait svp des exemples précis

Tout d'abord merci de m'avoir répondu car vous êtes ma derniere solution.

En fait lorsque les utilisateurs utilise le logiciel dès qu'il font une requete ou quoi que ce soit un petit sablier apparait et il doive attendre 5 10 minute pour avoir ce qu'ils avaient demandé. Ou lorsqu'ils cliquent ils se font éjecter du logiciel.

les utilisateurs mettent critères étendus ou rapide simplifié ?
la est la différence.
rapide simplifié = requete sql
critères étendus = entre guillements à du propriétaire.
essayes en rapide simplifié et dis moi le temps que ça prend.

ensuite faut vérifier le réseau
sage préconise en RAM au mimimun la taille de la base.

Excusez moi d'être inculte mais je ne connaissait pas du tout sage avant je débarque un peu pouvez vous me dire ou se situe cette option? merci

quand tu vas dans états / inventaire la premiere ligne tu peux changer.
c'est pareil dasn quasi tous les états

je viens de faire un test avec les 2 et pour les 2 j ai le même temp d'attente . Je n'ai plus que la solution migration de serveur?

bonjour

quand tu ouvres la base *. gcm dans le logiciel maintenance, reste-t-il de la place dispo ?
Je sais que la base est énorme mais peut etre qu'il faudrait encore l'agrandir car l'agrandissement dynamique de sage lorsqu'elle sature ralenti tous les traitements.
En RAM je crois que c'est au MINIMUM l'équivalent de la base.
Où ai-je entendu des bases max a 2 Go. au delà sage ne réponds plus de rien.... ??

cathy

cathy a écrit:bonjour

quand tu ouvres la base *. gcm dans le logiciel maintenance, reste-t-il de la place dispo ?
Je sais que la base est énorme mais peut etre qu'il faudrait encore l'agrandir car l'agrandissement dynamique de sage lorsqu'elle sature ralenti tous les traitements.
En RAM je crois que c'est au MINIMUM l'équivalent de la base.
Où ai-je entendu des bases max a 2 Go. au delà sage ne réponds plus de rien.... ??

cathy

elle est agrandi jusqu'à 5 go, par contre pensez vous que si c'est réellement la mémoire qui rentre en jeux car finalement toute les requêtes dont le SELECT sont mis dans le SWAP donc évidemment plus on rentre dans le temp et plus le SWAP est rempli non?
Pensez qu'il est nécessaire de changer tout le serveur ou simplement rajouter de la mémoire à celui ci?

J'ai aussi le même problème mais je pense pas que ça vient de mon serveur : IBM X226 4GO RAM disque en RAID 5 Bi-Xeon 3Ghz.
Base SQL : 2Go
OS : WIndows 2003 Server
SQL : SQL Server 2000.

Lenteur lors de certain etat avec critère etendue même si executé sur le serveur.
Jusqu'à maintenant aucune solution possible.

Juste pour la culture :

La différence entre Critères rapides simplifiés et Critères étendus :

En Rapide simplifié, la requête envoyée au serveur SQL pour réaliser l'état est en SQL natif.
En critères étendus, ce n'est plus le cas, c'est la plupart du temps une construction d'état en plusieurs étapes, parfois en N sous requêtes. De plus en critères étendu, on ajoute parfois des critères faisant référente à d'autres tables, ce qui engendre autant d'appels supplémentaires pour chaque ligne de résultat dans ces autres tables.

D'où une différence de performance parfois énormes entre ces deux types de critères pour un même rapport.

concernant le premier post:
une base de 2,45 Go pour 2Go de RAM !!!!

Sans parler de Sage, les simple préconisations de Microsoft SQL Server (que Sage reprend à minima) sont de 1,5 fois la taille de la BDD en RAM juste pour SQL Server, + 1 Go pour le systeme, et j'ajouterai 1 Go pour la marge, sans compter l'estimation d'augmentation de taille de la BDD en 2 ans d'utilisation (pour info, en moyenne compter de 1,5Ko par enregistrement pour une ligne de document ou une écriture comptable par exemple).

Donc là ça ne m'étonne pas du tout qu'il soit dans les choux, surtout avec 15 utilisateurs par dessus !!!

Le_Maraudeur a écrit:Juste pour la culture :

La différence entre Critères rapides simplifiés et Critères étendus :

En Rapide simplifié, la requête envoyée au serveur SQL pour réaliser l'état est en SQL natif.
En critères étendus, ce n'est plus le cas, c'est la plupart du temps une construction d'état en plusieurs étapes, parfois en N sous requêtes. De plus en critères étendu, on ajoute parfois des critères faisant référente à d'autres tables, ce qui engendre autant d'appels supplémentaires pour chaque ligne de résultat dans ces autres tables.

D'où une différence de performance parfois énormes entre ces deux types de critères pour un même rapport.

concernant le premier post:
une base de 2,45 Go pour 2Go de RAM !!!!

Sans parler de Sage, les simple préconisations de Microsoft SQL Server (que Sage reprend à minima) sont de 1,5 fois la taille de la BDD en RAM juste pour SQL Server, + 1 Go pour le systeme, et j'ajouterai 1 Go pour la marge, sans compter l'estimation d'augmentation de taille de la BDD en 2 ans d'utilisation (pour info, en moyenne compter de 1,5Ko par enregistrement pour une ligne de document ou une écriture comptable par exemple).

Donc là ça ne m'étonne pas du tout qu'il soit dans les choux, surtout avec 15 utilisateurs par dessus !!!

Bonjour,

Je remonte le sujet...
Je voudrais juste être sur. Sous SQL est-il encore nécessaire de faire un agrandissement de la taille de la base? Je pensais que ces problèmes de taille concernaient uniquement les versions propriétaires.

Merci,

Bonjour Yeliel,

Réponse un peu tardive, mais je vous suggère de regarder cet exemple assez criant de vérité.

CQFD

HTH,