On m'a demandé de regarder un problème de performance sur un server SQL 2000
octoprocesseurs, 2 Go ram...
Base de prod 100 GO, a peu pres 200 spids.
Premier reflexe, une trace pour regarder les requêtes et voir côté
index...mais le problème c'est que la trace plombe l'application !
Ma question vient du type des requêtes utilisées, tout passe par des
curseurs de serveur, c'est à dire un appel au procédure stocké
sp_cursorprepexec, sp_cursorfetch, sp_cursorunprepare....je ne connais pas
ce mécanisme et j'aimerai un avis dessus...sur les performances que cela
peut entrainer.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
SQLpro
Bonjour,
le nombre de connexions simultanées indique la quantité de processeur nécessaire. Pour 200 spid ce qui est très faible un mono processeur suffit amplement (sauf DW). En revanche pour une base de 100 Go, dont la fenêtre des données doit à mon avis se situer entre 10 et 20 Go, il serait nécessaire de prévoir quelques 16 à + Go de RAM, c'est à dire une version avancée de Windows Server (Advanced ou Datacenter).
Pour vous en convaincre, auditez le compteur cache hit ratio dans perfmon et si vous trouvez que celui-ci est inférieur à 92 % alors l'ajout de RAM est nécessaire car votre serveur passe son temps à paginer !
A +
LaC a écrit :
Bonjour,
On m'a demandé de regarder un problème de performance sur un server S QL 2000 octoprocesseurs, 2 Go ram... Base de prod 100 GO, a peu pres 200 spids.
Premier reflexe, une trace pour regarder les requêtes et voir côté index...mais le problème c'est que la trace plombe l'application !
Ma question vient du type des requêtes utilisées, tout passe par des curseurs de serveur, c'est à dire un appel au procédure stocké sp_cursorprepexec, sp_cursorfetch, sp_cursorunprepare....je ne connais pas ce mécanisme et j'aimerai un avis dessus...sur les performances que cela peut entrainer.
merci.
Bonjour,
le nombre de connexions simultanées indique la quantité de processeur
nécessaire. Pour 200 spid ce qui est très faible un mono processeur
suffit amplement (sauf DW).
En revanche pour une base de 100 Go, dont la fenêtre des données doit
à mon avis se situer entre 10 et 20 Go, il serait nécessaire de
prévoir quelques 16 à + Go de RAM, c'est à dire une version avancée
de Windows Server (Advanced ou Datacenter).
Pour vous en convaincre, auditez le compteur cache hit ratio dans
perfmon et si vous trouvez que celui-ci est inférieur à 92 % alors
l'ajout de RAM est nécessaire car votre serveur passe son temps à
paginer !
A +
LaC a écrit :
Bonjour,
On m'a demandé de regarder un problème de performance sur un server S QL 2000
octoprocesseurs, 2 Go ram...
Base de prod 100 GO, a peu pres 200 spids.
Premier reflexe, une trace pour regarder les requêtes et voir côté
index...mais le problème c'est que la trace plombe l'application !
Ma question vient du type des requêtes utilisées, tout passe par des
curseurs de serveur, c'est à dire un appel au procédure stocké
sp_cursorprepexec, sp_cursorfetch, sp_cursorunprepare....je ne connais pas
ce mécanisme et j'aimerai un avis dessus...sur les performances que cela
peut entrainer.
le nombre de connexions simultanées indique la quantité de processeur nécessaire. Pour 200 spid ce qui est très faible un mono processeur suffit amplement (sauf DW). En revanche pour une base de 100 Go, dont la fenêtre des données doit à mon avis se situer entre 10 et 20 Go, il serait nécessaire de prévoir quelques 16 à + Go de RAM, c'est à dire une version avancée de Windows Server (Advanced ou Datacenter).
Pour vous en convaincre, auditez le compteur cache hit ratio dans perfmon et si vous trouvez que celui-ci est inférieur à 92 % alors l'ajout de RAM est nécessaire car votre serveur passe son temps à paginer !
A +
LaC a écrit :
Bonjour,
On m'a demandé de regarder un problème de performance sur un server S QL 2000 octoprocesseurs, 2 Go ram... Base de prod 100 GO, a peu pres 200 spids.
Premier reflexe, une trace pour regarder les requêtes et voir côté index...mais le problème c'est que la trace plombe l'application !
Ma question vient du type des requêtes utilisées, tout passe par des curseurs de serveur, c'est à dire un appel au procédure stocké sp_cursorprepexec, sp_cursorfetch, sp_cursorunprepare....je ne connais pas ce mécanisme et j'aimerai un avis dessus...sur les performances que cela peut entrainer.
merci.
LaC
Salut fréd,
j'ai loupé la ram est de 8 GO en faite. Quand au hit ratio je l'ai déja vérifié et il est bon.
...As tu déjà eu a faire à une application qui passe par un pool qui lance plein de connexion et tous les requêtes passent pas un ce mécanisme de curseurs serveurs via les procédures sp_cursorprepexec, sp_cursorfetch, sp_sorunprepare, sp_prepexec...
Laurent.
"SQLpro" a écrit dans le message de news:
Bonjour,
le nombre de connexions simultanées indique la quantité de processeur nécessaire. Pour 200 spid ce qui est très faible un mono processeur suffit amplement (sauf DW). En revanche pour une base de 100 Go, dont la fenêtre des données doit à mon avis se situer entre 10 et 20 Go, il serait nécessaire de prévoir quelques 16 à + Go de RAM, c'est à dire une version avancée de Windows Server (Advanced ou Datacenter).
Pour vous en convaincre, auditez le compteur cache hit ratio dans perfmon et si vous trouvez que celui-ci est inférieur à 92 % alors l'ajout de RAM est nécessaire car votre serveur passe son temps à paginer !
A +
LaC a écrit :
Bonjour,
On m'a demandé de regarder un problème de performance sur un server SQL 2000 octoprocesseurs, 2 Go ram... Base de prod 100 GO, a peu pres 200 spids.
Premier reflexe, une trace pour regarder les requêtes et voir côté index...mais le problème c'est que la trace plombe l'application !
Ma question vient du type des requêtes utilisées, tout passe par des curseurs de serveur, c'est à dire un appel au procédure stocké sp_cursorprepexec, sp_cursorfetch, sp_cursorunprepare....je ne connais pas ce mécanisme et j'aimerai un avis dessus...sur les performances que cela peut entrainer.
merci.
Salut fréd,
j'ai loupé la ram est de 8 GO en faite.
Quand au hit ratio je l'ai déja vérifié et il est bon.
...As tu déjà eu a faire à une application qui passe par un pool qui lance
plein de connexion et tous les requêtes passent pas un ce mécanisme de
curseurs serveurs via les procédures sp_cursorprepexec, sp_cursorfetch,
sp_sorunprepare, sp_prepexec...
Laurent.
"SQLpro" <brouardf@club-internet.fr> a écrit dans le message de news:
1159435539.981442.9070@i42g2000cwa.googlegroups.com...
Bonjour,
le nombre de connexions simultanées indique la quantité de processeur
nécessaire. Pour 200 spid ce qui est très faible un mono processeur
suffit amplement (sauf DW).
En revanche pour une base de 100 Go, dont la fenêtre des données doit
à mon avis se situer entre 10 et 20 Go, il serait nécessaire de
prévoir quelques 16 à + Go de RAM, c'est à dire une version avancée
de Windows Server (Advanced ou Datacenter).
Pour vous en convaincre, auditez le compteur cache hit ratio dans
perfmon et si vous trouvez que celui-ci est inférieur à 92 % alors
l'ajout de RAM est nécessaire car votre serveur passe son temps à
paginer !
A +
LaC a écrit :
Bonjour,
On m'a demandé de regarder un problème de performance sur un server SQL
2000
octoprocesseurs, 2 Go ram...
Base de prod 100 GO, a peu pres 200 spids.
Premier reflexe, une trace pour regarder les requêtes et voir côté
index...mais le problème c'est que la trace plombe l'application !
Ma question vient du type des requêtes utilisées, tout passe par des
curseurs de serveur, c'est à dire un appel au procédure stocké
sp_cursorprepexec, sp_cursorfetch, sp_cursorunprepare....je ne connais pas
ce mécanisme et j'aimerai un avis dessus...sur les performances que cela
peut entrainer.
j'ai loupé la ram est de 8 GO en faite. Quand au hit ratio je l'ai déja vérifié et il est bon.
...As tu déjà eu a faire à une application qui passe par un pool qui lance plein de connexion et tous les requêtes passent pas un ce mécanisme de curseurs serveurs via les procédures sp_cursorprepexec, sp_cursorfetch, sp_sorunprepare, sp_prepexec...
Laurent.
"SQLpro" a écrit dans le message de news:
Bonjour,
le nombre de connexions simultanées indique la quantité de processeur nécessaire. Pour 200 spid ce qui est très faible un mono processeur suffit amplement (sauf DW). En revanche pour une base de 100 Go, dont la fenêtre des données doit à mon avis se situer entre 10 et 20 Go, il serait nécessaire de prévoir quelques 16 à + Go de RAM, c'est à dire une version avancée de Windows Server (Advanced ou Datacenter).
Pour vous en convaincre, auditez le compteur cache hit ratio dans perfmon et si vous trouvez que celui-ci est inférieur à 92 % alors l'ajout de RAM est nécessaire car votre serveur passe son temps à paginer !
A +
LaC a écrit :
Bonjour,
On m'a demandé de regarder un problème de performance sur un server SQL 2000 octoprocesseurs, 2 Go ram... Base de prod 100 GO, a peu pres 200 spids.
Premier reflexe, une trace pour regarder les requêtes et voir côté index...mais le problème c'est que la trace plombe l'application !
Ma question vient du type des requêtes utilisées, tout passe par des curseurs de serveur, c'est à dire un appel au procédure stocké sp_cursorprepexec, sp_cursorfetch, sp_cursorunprepare....je ne connais pas ce mécanisme et j'aimerai un avis dessus...sur les performances que cela peut entrainer.
