Un traitement sur une base de 900MO est quasi instantanné ; le même sur une
base de 1.6 GO dure 1mn30.
Ceci sur une machine de test locale monoposte, sur SQL 2000, avec 512MO RAM.
Cela signifie-t-tl qu'une grande partie des data traitées est montée en RAM
et donc que l'ajout de RAM résoudrait mon problème ?
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
Fred BROUARD
Comme tout bon SGBDR SQL Server nécessite une machine dédiée.
Le principe de fonctionnement fait que SQL Server capte toute la RAM possible pour effectuer ses traitement. Il ne se sert pas du disque pour aller lire les données. Il les lit en mémoire afin de les traiter. Il doit donc demander à l'OS de lire le disque et placer les pages nécessaire en mémoire, et lorsque cela est fait il scrute les pages montée en mémoire pour traitement.
512 Mo de RAM pour une base de 1,6 Go qui doit être entiérement parcourue n'est pas très important, surtout s'il y a d'autres bases et d'autre applications...
mml a écrit:
Bonjour,
Un traitement sur une base de 900MO est quasi instantanné ; le même sur une base de 1.6 GO dure 1mn30. Ceci sur une machine de test locale monoposte, sur SQL 2000, avec 512MO RAM.
Cela signifie-t-tl qu'une grande partie des data traitées est montée en RAM et donc que l'ajout de RAM résoudrait mon problème ?
Oui, mais surtout dédier la machine (éviter de faire Outlook + Word + IE dessus !)
A +
Merci d'avance, MML
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Comme tout bon SGBDR SQL Server nécessite une machine dédiée.
Le principe de fonctionnement fait que SQL Server capte toute la RAM possible
pour effectuer ses traitement. Il ne se sert pas du disque pour aller lire les
données. Il les lit en mémoire afin de les traiter. Il doit donc demander à l'OS
de lire le disque et placer les pages nécessaire en mémoire, et lorsque cela est
fait il scrute les pages montée en mémoire pour traitement.
512 Mo de RAM pour une base de 1,6 Go qui doit être entiérement parcourue n'est
pas très important, surtout s'il y a d'autres bases et d'autre applications...
mml a écrit:
Bonjour,
Un traitement sur une base de 900MO est quasi instantanné ; le même sur une
base de 1.6 GO dure 1mn30.
Ceci sur une machine de test locale monoposte, sur SQL 2000, avec 512MO RAM.
Cela signifie-t-tl qu'une grande partie des data traitées est montée en RAM
et donc que l'ajout de RAM résoudrait mon problème ?
Oui, mais surtout dédier la machine (éviter de faire Outlook + Word + IE dessus !)
A +
Merci d'avance,
MML
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Comme tout bon SGBDR SQL Server nécessite une machine dédiée.
Le principe de fonctionnement fait que SQL Server capte toute la RAM possible pour effectuer ses traitement. Il ne se sert pas du disque pour aller lire les données. Il les lit en mémoire afin de les traiter. Il doit donc demander à l'OS de lire le disque et placer les pages nécessaire en mémoire, et lorsque cela est fait il scrute les pages montée en mémoire pour traitement.
512 Mo de RAM pour une base de 1,6 Go qui doit être entiérement parcourue n'est pas très important, surtout s'il y a d'autres bases et d'autre applications...
mml a écrit:
Bonjour,
Un traitement sur une base de 900MO est quasi instantanné ; le même sur une base de 1.6 GO dure 1mn30. Ceci sur une machine de test locale monoposte, sur SQL 2000, avec 512MO RAM.
Cela signifie-t-tl qu'une grande partie des data traitées est montée en RAM et donc que l'ajout de RAM résoudrait mon problème ?
Oui, mais surtout dédier la machine (éviter de faire Outlook + Word + IE dessus !)
A +
Merci d'avance, MML
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Philippe [MS]
Il n'y a pas que les problématiques liés à la mémoire qu'il faut traiter. Les I/O disque peuvent également avoir un impact non négligeable sur les performances. La séparation des Data et Logs sur deux axes disques différents, le sizing de la base TempDB, etc. sont également à prendre en considération.
Phil.
"Fred BROUARD" wrote in message news:
Comme tout bon SGBDR SQL Server nécessite une machine dédiée.
Le principe de fonctionnement fait que SQL Server capte toute la RAM
possible
pour effectuer ses traitement. Il ne se sert pas du disque pour aller lire
les
données. Il les lit en mémoire afin de les traiter. Il doit donc demander
à l'OS
de lire le disque et placer les pages nécessaire en mémoire, et lorsque
cela est
fait il scrute les pages montée en mémoire pour traitement.
512 Mo de RAM pour une base de 1,6 Go qui doit être entiérement parcourue
n'est
pas très important, surtout s'il y a d'autres bases et d'autre
applications...
mml a écrit: > Bonjour, > > Un traitement sur une base de 900MO est quasi instantanné ; le même sur
une
> base de 1.6 GO dure 1mn30. > Ceci sur une machine de test locale monoposte, sur SQL 2000, avec 512MO
RAM.
> > Cela signifie-t-tl qu'une grande partie des data traitées est montée en
RAM
> et donc que l'ajout de RAM résoudrait mon problème ?
Oui, mais surtout dédier la machine (éviter de faire Outlook + Word + IE
dessus !)
A +
> > Merci d'avance, > MML > >
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
Il n'y a pas que les problématiques liés à la mémoire qu'il faut traiter.
Les I/O disque peuvent également avoir un impact non négligeable sur les
performances. La séparation des Data et Logs sur deux axes disques
différents, le sizing de la base TempDB, etc. sont également à prendre en
considération.
Phil.
"Fred BROUARD" <brouardf@club-internet.fr> wrote in message
news:ObrjgbzxEHA.4040@TK2MSFTNGP11.phx.gbl...
Comme tout bon SGBDR SQL Server nécessite une machine dédiée.
Le principe de fonctionnement fait que SQL Server capte toute la RAM
possible
pour effectuer ses traitement. Il ne se sert pas du disque pour aller lire
les
données. Il les lit en mémoire afin de les traiter. Il doit donc demander
à l'OS
de lire le disque et placer les pages nécessaire en mémoire, et lorsque
cela est
fait il scrute les pages montée en mémoire pour traitement.
512 Mo de RAM pour une base de 1,6 Go qui doit être entiérement parcourue
n'est
pas très important, surtout s'il y a d'autres bases et d'autre
applications...
mml a écrit:
> Bonjour,
>
> Un traitement sur une base de 900MO est quasi instantanné ; le même sur
une
> base de 1.6 GO dure 1mn30.
> Ceci sur une machine de test locale monoposte, sur SQL 2000, avec 512MO
RAM.
>
> Cela signifie-t-tl qu'une grande partie des data traitées est montée en
RAM
> et donc que l'ajout de RAM résoudrait mon problème ?
Oui, mais surtout dédier la machine (éviter de faire Outlook + Word + IE
dessus !)
A +
>
> Merci d'avance,
> MML
>
>
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Il n'y a pas que les problématiques liés à la mémoire qu'il faut traiter. Les I/O disque peuvent également avoir un impact non négligeable sur les performances. La séparation des Data et Logs sur deux axes disques différents, le sizing de la base TempDB, etc. sont également à prendre en considération.
Phil.
"Fred BROUARD" wrote in message news:
Comme tout bon SGBDR SQL Server nécessite une machine dédiée.
Le principe de fonctionnement fait que SQL Server capte toute la RAM
possible
pour effectuer ses traitement. Il ne se sert pas du disque pour aller lire
les
données. Il les lit en mémoire afin de les traiter. Il doit donc demander
à l'OS
de lire le disque et placer les pages nécessaire en mémoire, et lorsque
cela est
fait il scrute les pages montée en mémoire pour traitement.
512 Mo de RAM pour une base de 1,6 Go qui doit être entiérement parcourue
n'est
pas très important, surtout s'il y a d'autres bases et d'autre
applications...
mml a écrit: > Bonjour, > > Un traitement sur une base de 900MO est quasi instantanné ; le même sur
une
> base de 1.6 GO dure 1mn30. > Ceci sur une machine de test locale monoposte, sur SQL 2000, avec 512MO
RAM.
> > Cela signifie-t-tl qu'une grande partie des data traitées est montée en
RAM
> et donc que l'ajout de RAM résoudrait mon problème ?
Oui, mais surtout dédier la machine (éviter de faire Outlook + Word + IE
dessus !)
A +
> > Merci d'avance, > MML > >
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
