Bonjour,
J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
On a un process qui recupere des donnees fichier et fait un BCP .
Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y a
115852 lignes a inserer.
Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de donnees
marche.
Pour plus de lignes par exemple 100000 lignes, les servers ne reponds plus
et se freeze. Oblige d eteindre la machine.
Est ce qu il y a un bug connu pour les gros transfert ? ou quelque chose de
genre ?
Merci
Olivier
Bonjour,
J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
On a un process qui recupere des donnees fichier et fait un BCP .
Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y a
115852 lignes a inserer.
Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de donnees
marche.
Pour plus de lignes par exemple 100000 lignes, les servers ne reponds plus
et se freeze. Oblige d eteindre la machine.
Est ce qu il y a un bug connu pour les gros transfert ? ou quelque chose de
genre ?
Merci
Olivier
Bonjour,
J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
On a un process qui recupere des donnees fichier et fait un BCP .
Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y a
115852 lignes a inserer.
Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de donnees
marche.
Pour plus de lignes par exemple 100000 lignes, les servers ne reponds plus
et se freeze. Oblige d eteindre la machine.
Est ce qu il y a un bug connu pour les gros transfert ? ou quelque chose de
genre ?
Merci
Olivier
Bonjour,
J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
On a un process qui recupere des donnees fichier et fait un BCP .
Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y a
115852 lignes a inserer.
Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de donnees
marche.
Pour plus de lignes par exemple 100000 lignes, les servers ne reponds plus
et se freeze. Oblige d eteindre la machine.
Est ce qu il y a un bug connu pour les gros transfert ? ou quelque chose de
genre ?
Merci
Olivier
Bonjour,
J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
On a un process qui recupere des donnees fichier et fait un BCP .
Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y a
115852 lignes a inserer.
Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de donnees
marche.
Pour plus de lignes par exemple 100000 lignes, les servers ne reponds plus
et se freeze. Oblige d eteindre la machine.
Est ce qu il y a un bug connu pour les gros transfert ? ou quelque chose de
genre ?
Merci
Olivier
Bonjour,
J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
On a un process qui recupere des donnees fichier et fait un BCP .
Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y a
115852 lignes a inserer.
Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de donnees
marche.
Pour plus de lignes par exemple 100000 lignes, les servers ne reponds plus
et se freeze. Oblige d eteindre la machine.
Est ce qu il y a un bug connu pour les gros transfert ? ou quelque chose de
genre ?
Merci
Olivier
Re,
J'ai repensé à ton pb.
Le fait que le serveur se fige peut être du à un manque de ressource ...
Par defaut le serveur SQL est configuré en allocation automatique entre 0
toute la Ram.
Il faut :
1- relever le minimum (puisqu'on a un ingénieur qui a pensé qu'un process
pouvait tourner avec 0 octets en ram !!!) pour atteindre 75 Mo minimum
2- abaisser le max (c'est le même ingénieur qui cette fois a pensé qu'un
process pouvait prendre toute la ram quitte à virer les autres process
ceux de windows !!!). Le choix de la valeur max depend si le serveur est
dédié ou pas.
De manière visuelle, dans l'entreprise ménagère/ propriété de l'instance /
mémoire il faut bouger les curseurs de manière à ce qu'ils soient dans le
vert (comme quoi l'ingénieur en question il savait qu'elles sont les
valeurs ;-)
tiens nous au courant.
"oLiVieR CheNeSoN" a écrit :
> Bonjour,
>
>
> J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
>
> On a un process qui recupere des donnees fichier et fait un BCP .
>
> Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y a
> 115852 lignes a inserer.
>
> Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de
> marche.
>
> Pour plus de lignes par exemple 100000 lignes, les servers ne reponds
> et se freeze. Oblige d eteindre la machine.
>
> Est ce qu il y a un bug connu pour les gros transfert ? ou quelque chose
> genre ?
>
>
> Merci
> Olivier
>
>
>
>
>
>
>
Re,
J'ai repensé à ton pb.
Le fait que le serveur se fige peut être du à un manque de ressource ...
Par defaut le serveur SQL est configuré en allocation automatique entre 0
toute la Ram.
Il faut :
1- relever le minimum (puisqu'on a un ingénieur qui a pensé qu'un process
pouvait tourner avec 0 octets en ram !!!) pour atteindre 75 Mo minimum
2- abaisser le max (c'est le même ingénieur qui cette fois a pensé qu'un
process pouvait prendre toute la ram quitte à virer les autres process
ceux de windows !!!). Le choix de la valeur max depend si le serveur est
dédié ou pas.
De manière visuelle, dans l'entreprise ménagère/ propriété de l'instance /
mémoire il faut bouger les curseurs de manière à ce qu'ils soient dans le
vert (comme quoi l'ingénieur en question il savait qu'elles sont les
valeurs ;-)
tiens nous au courant.
"oLiVieR CheNeSoN" a écrit :
> Bonjour,
>
>
> J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
>
> On a un process qui recupere des donnees fichier et fait un BCP .
>
> Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y a
> 115852 lignes a inserer.
>
> Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de
> marche.
>
> Pour plus de lignes par exemple 100000 lignes, les servers ne reponds
> et se freeze. Oblige d eteindre la machine.
>
> Est ce qu il y a un bug connu pour les gros transfert ? ou quelque chose
> genre ?
>
>
> Merci
> Olivier
>
>
>
>
>
>
>
Re,
J'ai repensé à ton pb.
Le fait que le serveur se fige peut être du à un manque de ressource ...
Par defaut le serveur SQL est configuré en allocation automatique entre 0
toute la Ram.
Il faut :
1- relever le minimum (puisqu'on a un ingénieur qui a pensé qu'un process
pouvait tourner avec 0 octets en ram !!!) pour atteindre 75 Mo minimum
2- abaisser le max (c'est le même ingénieur qui cette fois a pensé qu'un
process pouvait prendre toute la ram quitte à virer les autres process
ceux de windows !!!). Le choix de la valeur max depend si le serveur est
dédié ou pas.
De manière visuelle, dans l'entreprise ménagère/ propriété de l'instance /
mémoire il faut bouger les curseurs de manière à ce qu'ils soient dans le
vert (comme quoi l'ingénieur en question il savait qu'elles sont les
valeurs ;-)
tiens nous au courant.
"oLiVieR CheNeSoN" a écrit :
> Bonjour,
>
>
> J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
>
> On a un process qui recupere des donnees fichier et fait un BCP .
>
> Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y a
> 115852 lignes a inserer.
>
> Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de
> marche.
>
> Pour plus de lignes par exemple 100000 lignes, les servers ne reponds
> et se freeze. Oblige d eteindre la machine.
>
> Est ce qu il y a un bug connu pour les gros transfert ? ou quelque chose
> genre ?
>
>
> Merci
> Olivier
>
>
>
>
>
>
>
Qd tu dis : "c'est le même ingénieur qui cette fois a pensé qu'un
process pouvait prendre toute la ram quitte à virer les autres process comme
ceux de windows !!!). "
Es-tu sûr que sqlserver puisse géner l'execution du system ?
Pour moi utiliser un maxmemory sur sqlserver etait pour le cas où d'autres
applications etiaent lancées sur le meme serveur. Afin qu'elle ne soient pas
ralenti par SLQSERVER.
Mais pour ce qui est du system en lui-même, ca me parait bizare ... A moins
que ca soit mal géré, et qu'il faille l'utiliser car "c'est plus sûr" ?...
"Michel PRIORI" a écrit dans le
message de news:
> Re,
>
> J'ai repensé à ton pb.
> Le fait que le serveur se fige peut être du à un manque de ressource ...
Ram.
> Par defaut le serveur SQL est configuré en allocation automatique entre 0
et
> toute la Ram.
> Il faut :
> 1- relever le minimum (puisqu'on a un ingénieur qui a pensé qu'un process
> pouvait tourner avec 0 octets en ram !!!) pour atteindre 75 Mo minimum
> 2- abaisser le max (c'est le même ingénieur qui cette fois a pensé qu'un
> process pouvait prendre toute la ram quitte à virer les autres process
comme
> ceux de windows !!!). Le choix de la valeur max depend si le serveur est
> dédié ou pas.
>
> De manière visuelle, dans l'entreprise ménagère/ propriété de l'instance /
> mémoire il faut bouger les curseurs de manière à ce qu'ils soient dans le
> vert (comme quoi l'ingénieur en question il savait qu'elles sont les
bonnes
> valeurs ;-)
>
> tiens nous au courant.
> "oLiVieR CheNeSoN" a écrit :
>
> > Bonjour,
> >
> >
> > J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
> >
> > On a un process qui recupere des donnees fichier et fait un BCP .
> >
> > Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y a
> > 115852 lignes a inserer.
> >
> > Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de
donnees
> > marche.
> >
> > Pour plus de lignes par exemple 100000 lignes, les servers ne reponds
plus
> > et se freeze. Oblige d eteindre la machine.
> >
> > Est ce qu il y a un bug connu pour les gros transfert ? ou quelque chose
de
> > genre ?
> >
> >
> > Merci
> > Olivier
> >
> >
> >
> >
> >
> >
> >
Qd tu dis : "c'est le même ingénieur qui cette fois a pensé qu'un
process pouvait prendre toute la ram quitte à virer les autres process comme
ceux de windows !!!). "
Es-tu sûr que sqlserver puisse géner l'execution du system ?
Pour moi utiliser un maxmemory sur sqlserver etait pour le cas où d'autres
applications etiaent lancées sur le meme serveur. Afin qu'elle ne soient pas
ralenti par SLQSERVER.
Mais pour ce qui est du system en lui-même, ca me parait bizare ... A moins
que ca soit mal géré, et qu'il faille l'utiliser car "c'est plus sûr" ?...
"Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> a écrit dans le
message de news:BD0FCF9F-4882-4713-9E5E-2699E4F0238F@microsoft.com...
> Re,
>
> J'ai repensé à ton pb.
> Le fait que le serveur se fige peut être du à un manque de ressource ...
Ram.
> Par defaut le serveur SQL est configuré en allocation automatique entre 0
et
> toute la Ram.
> Il faut :
> 1- relever le minimum (puisqu'on a un ingénieur qui a pensé qu'un process
> pouvait tourner avec 0 octets en ram !!!) pour atteindre 75 Mo minimum
> 2- abaisser le max (c'est le même ingénieur qui cette fois a pensé qu'un
> process pouvait prendre toute la ram quitte à virer les autres process
comme
> ceux de windows !!!). Le choix de la valeur max depend si le serveur est
> dédié ou pas.
>
> De manière visuelle, dans l'entreprise ménagère/ propriété de l'instance /
> mémoire il faut bouger les curseurs de manière à ce qu'ils soient dans le
> vert (comme quoi l'ingénieur en question il savait qu'elles sont les
bonnes
> valeurs ;-)
>
> tiens nous au courant.
> "oLiVieR CheNeSoN" a écrit :
>
> > Bonjour,
> >
> >
> > J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
> >
> > On a un process qui recupere des donnees fichier et fait un BCP .
> >
> > Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y a
> > 115852 lignes a inserer.
> >
> > Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de
donnees
> > marche.
> >
> > Pour plus de lignes par exemple 100000 lignes, les servers ne reponds
plus
> > et se freeze. Oblige d eteindre la machine.
> >
> > Est ce qu il y a un bug connu pour les gros transfert ? ou quelque chose
de
> > genre ?
> >
> >
> > Merci
> > Olivier
> >
> >
> >
> >
> >
> >
> >
Qd tu dis : "c'est le même ingénieur qui cette fois a pensé qu'un
process pouvait prendre toute la ram quitte à virer les autres process comme
ceux de windows !!!). "
Es-tu sûr que sqlserver puisse géner l'execution du system ?
Pour moi utiliser un maxmemory sur sqlserver etait pour le cas où d'autres
applications etiaent lancées sur le meme serveur. Afin qu'elle ne soient pas
ralenti par SLQSERVER.
Mais pour ce qui est du system en lui-même, ca me parait bizare ... A moins
que ca soit mal géré, et qu'il faille l'utiliser car "c'est plus sûr" ?...
"Michel PRIORI" a écrit dans le
message de news:
> Re,
>
> J'ai repensé à ton pb.
> Le fait que le serveur se fige peut être du à un manque de ressource ...
Ram.
> Par defaut le serveur SQL est configuré en allocation automatique entre 0
et
> toute la Ram.
> Il faut :
> 1- relever le minimum (puisqu'on a un ingénieur qui a pensé qu'un process
> pouvait tourner avec 0 octets en ram !!!) pour atteindre 75 Mo minimum
> 2- abaisser le max (c'est le même ingénieur qui cette fois a pensé qu'un
> process pouvait prendre toute la ram quitte à virer les autres process
comme
> ceux de windows !!!). Le choix de la valeur max depend si le serveur est
> dédié ou pas.
>
> De manière visuelle, dans l'entreprise ménagère/ propriété de l'instance /
> mémoire il faut bouger les curseurs de manière à ce qu'ils soient dans le
> vert (comme quoi l'ingénieur en question il savait qu'elles sont les
bonnes
> valeurs ;-)
>
> tiens nous au courant.
> "oLiVieR CheNeSoN" a écrit :
>
> > Bonjour,
> >
> >
> > J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
> >
> > On a un process qui recupere des donnees fichier et fait un BCP .
> >
> > Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y a
> > 115852 lignes a inserer.
> >
> > Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de
donnees
> > marche.
> >
> > Pour plus de lignes par exemple 100000 lignes, les servers ne reponds
plus
> > et se freeze. Oblige d eteindre la machine.
> >
> > Est ce qu il y a un bug connu pour les gros transfert ? ou quelque chose
de
> > genre ?
> >
> >
> > Merci
> > Olivier
> >
> >
> >
> >
> >
> >
> >
Je suis toujours prenneur d'info.
Des fois je retiens ce qu'on me dis et ne prend pas le temps de controler
par moi même la véracité en faisant des tests. Surtout quand ça me semble
cohérent !
En ce qui concerne le parametrage de mémoire max dans le cadre de
l'allocation dynamique de la RAM :
1- il ne faut pas la confondre avec le parametrage de mémoire min qui lui
est fait pour "protéger" SQL de l'exclusion de la RAM même si son besoin
en
ram est tel qu'il est possible qu'un autre processus vienne la lui voler.
On indique donc quel est le seuil min de ram à garantir au process SQL.
2- la mémoire max indique donc le plafond d'allocation mémoire que SQL
peut
réclamer à l'OS. Sur l'interface graphique on note que la valeur max de ce
parametre est égal à la quantité de ram adressable. En clair si on a un
serveur à 256 Mo on peut aller jusqu'à 256 Mo ! je ne vois pas ce qu'il
reste
à windows dans un cas pareil. Le swap ?
3- Je pense que microsoft ne nous ments pas. Si un parametre permet
d'allouer 100% de la RAM, ce serait étonnant qu'il existe une limitation
non
exprimée et présente dans le code. A partir de là la situation de hold up
de
la Ram est plausible. Mais il est vrai que je ne l'ai pas éprouvé.
Je valide donc ta remarque que dans le doute : "il faille l'utiliser car
"c'est plus sûr""
Désolé de faire cette réponse tout en nuances. C'est pas trop mon style.
"deco" a écrit :Qd tu dis : "c'est le même ingénieur qui cette fois a pensé qu'un
process pouvait prendre toute la ram quitte à virer les autres process
comme
ceux de windows !!!). "
Es-tu sûr que sqlserver puisse géner l'execution du system ?
Pour moi utiliser un maxmemory sur sqlserver etait pour le cas où
d'autres
applications etiaent lancées sur le meme serveur. Afin qu'elle ne soient
pas
ralenti par SLQSERVER.
Mais pour ce qui est du system en lui-même, ca me parait bizare ... A
moins
que ca soit mal géré, et qu'il faille l'utiliser car "c'est plus sûr"
?...
"Michel PRIORI" a écrit dans le
message de news:
> Re,
>
> J'ai repensé à ton pb.
> Le fait que le serveur se fige peut être du à un manque de ressource
> ...
Ram.
> Par defaut le serveur SQL est configuré en allocation automatique entre
> 0
et
> toute la Ram.
> Il faut :
> 1- relever le minimum (puisqu'on a un ingénieur qui a pensé qu'un
> process
> pouvait tourner avec 0 octets en ram !!!) pour atteindre 75 Mo minimum
> 2- abaisser le max (c'est le même ingénieur qui cette fois a pensé
> qu'un
> process pouvait prendre toute la ram quitte à virer les autres process
comme
> ceux de windows !!!). Le choix de la valeur max depend si le serveur
> est
> dédié ou pas.
>
> De manière visuelle, dans l'entreprise ménagère/ propriété de
> l'instance /
> mémoire il faut bouger les curseurs de manière à ce qu'ils soient dans
> le
> vert (comme quoi l'ingénieur en question il savait qu'elles sont les
bonnes
> valeurs ;-)
>
> tiens nous au courant.
> "oLiVieR CheNeSoN" a écrit :
>
> > Bonjour,
> >
> >
> > J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
> >
> > On a un process qui recupere des donnees fichier et fait un BCP .
> >
> > Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y
> > a
> > 115852 lignes a inserer.
> >
> > Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de
donnees
> > marche.
> >
> > Pour plus de lignes par exemple 100000 lignes, les servers ne reponds
plus
> > et se freeze. Oblige d eteindre la machine.
> >
> > Est ce qu il y a un bug connu pour les gros transfert ? ou quelque
> > chose
de
> > genre ?
> >
> >
> > Merci
> > Olivier
> >
> >
> >
> >
> >
> >
> >
Je suis toujours prenneur d'info.
Des fois je retiens ce qu'on me dis et ne prend pas le temps de controler
par moi même la véracité en faisant des tests. Surtout quand ça me semble
cohérent !
En ce qui concerne le parametrage de mémoire max dans le cadre de
l'allocation dynamique de la RAM :
1- il ne faut pas la confondre avec le parametrage de mémoire min qui lui
est fait pour "protéger" SQL de l'exclusion de la RAM même si son besoin
en
ram est tel qu'il est possible qu'un autre processus vienne la lui voler.
On indique donc quel est le seuil min de ram à garantir au process SQL.
2- la mémoire max indique donc le plafond d'allocation mémoire que SQL
peut
réclamer à l'OS. Sur l'interface graphique on note que la valeur max de ce
parametre est égal à la quantité de ram adressable. En clair si on a un
serveur à 256 Mo on peut aller jusqu'à 256 Mo ! je ne vois pas ce qu'il
reste
à windows dans un cas pareil. Le swap ?
3- Je pense que microsoft ne nous ments pas. Si un parametre permet
d'allouer 100% de la RAM, ce serait étonnant qu'il existe une limitation
non
exprimée et présente dans le code. A partir de là la situation de hold up
de
la Ram est plausible. Mais il est vrai que je ne l'ai pas éprouvé.
Je valide donc ta remarque que dans le doute : "il faille l'utiliser car
"c'est plus sûr""
Désolé de faire cette réponse tout en nuances. C'est pas trop mon style.
"deco" a écrit :
Qd tu dis : "c'est le même ingénieur qui cette fois a pensé qu'un
process pouvait prendre toute la ram quitte à virer les autres process
comme
ceux de windows !!!). "
Es-tu sûr que sqlserver puisse géner l'execution du system ?
Pour moi utiliser un maxmemory sur sqlserver etait pour le cas où
d'autres
applications etiaent lancées sur le meme serveur. Afin qu'elle ne soient
pas
ralenti par SLQSERVER.
Mais pour ce qui est du system en lui-même, ca me parait bizare ... A
moins
que ca soit mal géré, et qu'il faille l'utiliser car "c'est plus sûr"
?...
"Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> a écrit dans le
message de news:BD0FCF9F-4882-4713-9E5E-2699E4F0238F@microsoft.com...
> Re,
>
> J'ai repensé à ton pb.
> Le fait que le serveur se fige peut être du à un manque de ressource
> ...
Ram.
> Par defaut le serveur SQL est configuré en allocation automatique entre
> 0
et
> toute la Ram.
> Il faut :
> 1- relever le minimum (puisqu'on a un ingénieur qui a pensé qu'un
> process
> pouvait tourner avec 0 octets en ram !!!) pour atteindre 75 Mo minimum
> 2- abaisser le max (c'est le même ingénieur qui cette fois a pensé
> qu'un
> process pouvait prendre toute la ram quitte à virer les autres process
comme
> ceux de windows !!!). Le choix de la valeur max depend si le serveur
> est
> dédié ou pas.
>
> De manière visuelle, dans l'entreprise ménagère/ propriété de
> l'instance /
> mémoire il faut bouger les curseurs de manière à ce qu'ils soient dans
> le
> vert (comme quoi l'ingénieur en question il savait qu'elles sont les
bonnes
> valeurs ;-)
>
> tiens nous au courant.
> "oLiVieR CheNeSoN" a écrit :
>
> > Bonjour,
> >
> >
> > J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
> >
> > On a un process qui recupere des donnees fichier et fait un BCP .
> >
> > Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y
> > a
> > 115852 lignes a inserer.
> >
> > Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de
donnees
> > marche.
> >
> > Pour plus de lignes par exemple 100000 lignes, les servers ne reponds
plus
> > et se freeze. Oblige d eteindre la machine.
> >
> > Est ce qu il y a un bug connu pour les gros transfert ? ou quelque
> > chose
de
> > genre ?
> >
> >
> > Merci
> > Olivier
> >
> >
> >
> >
> >
> >
> >
Je suis toujours prenneur d'info.
Des fois je retiens ce qu'on me dis et ne prend pas le temps de controler
par moi même la véracité en faisant des tests. Surtout quand ça me semble
cohérent !
En ce qui concerne le parametrage de mémoire max dans le cadre de
l'allocation dynamique de la RAM :
1- il ne faut pas la confondre avec le parametrage de mémoire min qui lui
est fait pour "protéger" SQL de l'exclusion de la RAM même si son besoin
en
ram est tel qu'il est possible qu'un autre processus vienne la lui voler.
On indique donc quel est le seuil min de ram à garantir au process SQL.
2- la mémoire max indique donc le plafond d'allocation mémoire que SQL
peut
réclamer à l'OS. Sur l'interface graphique on note que la valeur max de ce
parametre est égal à la quantité de ram adressable. En clair si on a un
serveur à 256 Mo on peut aller jusqu'à 256 Mo ! je ne vois pas ce qu'il
reste
à windows dans un cas pareil. Le swap ?
3- Je pense que microsoft ne nous ments pas. Si un parametre permet
d'allouer 100% de la RAM, ce serait étonnant qu'il existe une limitation
non
exprimée et présente dans le code. A partir de là la situation de hold up
de
la Ram est plausible. Mais il est vrai que je ne l'ai pas éprouvé.
Je valide donc ta remarque que dans le doute : "il faille l'utiliser car
"c'est plus sûr""
Désolé de faire cette réponse tout en nuances. C'est pas trop mon style.
"deco" a écrit :Qd tu dis : "c'est le même ingénieur qui cette fois a pensé qu'un
process pouvait prendre toute la ram quitte à virer les autres process
comme
ceux de windows !!!). "
Es-tu sûr que sqlserver puisse géner l'execution du system ?
Pour moi utiliser un maxmemory sur sqlserver etait pour le cas où
d'autres
applications etiaent lancées sur le meme serveur. Afin qu'elle ne soient
pas
ralenti par SLQSERVER.
Mais pour ce qui est du system en lui-même, ca me parait bizare ... A
moins
que ca soit mal géré, et qu'il faille l'utiliser car "c'est plus sûr"
?...
"Michel PRIORI" a écrit dans le
message de news:
> Re,
>
> J'ai repensé à ton pb.
> Le fait que le serveur se fige peut être du à un manque de ressource
> ...
Ram.
> Par defaut le serveur SQL est configuré en allocation automatique entre
> 0
et
> toute la Ram.
> Il faut :
> 1- relever le minimum (puisqu'on a un ingénieur qui a pensé qu'un
> process
> pouvait tourner avec 0 octets en ram !!!) pour atteindre 75 Mo minimum
> 2- abaisser le max (c'est le même ingénieur qui cette fois a pensé
> qu'un
> process pouvait prendre toute la ram quitte à virer les autres process
comme
> ceux de windows !!!). Le choix de la valeur max depend si le serveur
> est
> dédié ou pas.
>
> De manière visuelle, dans l'entreprise ménagère/ propriété de
> l'instance /
> mémoire il faut bouger les curseurs de manière à ce qu'ils soient dans
> le
> vert (comme quoi l'ingénieur en question il savait qu'elles sont les
bonnes
> valeurs ;-)
>
> tiens nous au courant.
> "oLiVieR CheNeSoN" a écrit :
>
> > Bonjour,
> >
> >
> > J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
> >
> > On a un process qui recupere des donnees fichier et fait un BCP .
> >
> > Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il y
> > a
> > 115852 lignes a inserer.
> >
> > Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer de
donnees
> > marche.
> >
> > Pour plus de lignes par exemple 100000 lignes, les servers ne reponds
plus
> > et se freeze. Oblige d eteindre la machine.
> >
> > Est ce qu il y a un bug connu pour les gros transfert ? ou quelque
> > chose
de
> > genre ?
> >
> >
> > Merci
> > Olivier
> >
> >
> >
> >
> >
> >
> >
le paramètrage mémoire de SQLServer n'empêche pas le swap qui est géré par
l'OS, il permet d'essayer de le prévenir.
br
"Michel PRIORI" wrote in message
news:
> Je suis toujours prenneur d'info.
> Des fois je retiens ce qu'on me dis et ne prend pas le temps de
> par moi même la véracité en faisant des tests. Surtout quand ça me
> cohérent !
>
> En ce qui concerne le parametrage de mémoire max dans le cadre de
> l'allocation dynamique de la RAM :
>
> 1- il ne faut pas la confondre avec le parametrage de mémoire min qui
> est fait pour "protéger" SQL de l'exclusion de la RAM même si son besoin
> en
> ram est tel qu'il est possible qu'un autre processus vienne la lui
> On indique donc quel est le seuil min de ram à garantir au process SQL.
>
> 2- la mémoire max indique donc le plafond d'allocation mémoire que SQL
> peut
> réclamer à l'OS. Sur l'interface graphique on note que la valeur max de
> parametre est égal à la quantité de ram adressable. En clair si on a un
> serveur à 256 Mo on peut aller jusqu'à 256 Mo ! je ne vois pas ce qu'il
> reste
> à windows dans un cas pareil. Le swap ?
>
> 3- Je pense que microsoft ne nous ments pas. Si un parametre permet
> d'allouer 100% de la RAM, ce serait étonnant qu'il existe une limitation
> non
> exprimée et présente dans le code. A partir de là la situation de hold
> de
> la Ram est plausible. Mais il est vrai que je ne l'ai pas éprouvé.
>
>
> Je valide donc ta remarque que dans le doute : "il faille l'utiliser car
> "c'est plus sûr""
> Désolé de faire cette réponse tout en nuances. C'est pas trop mon style.
>
>
>
> "deco" a écrit :
>
>> Qd tu dis : "c'est le même ingénieur qui cette fois a pensé qu'un
>> process pouvait prendre toute la ram quitte à virer les autres process
>> comme
>> ceux de windows !!!). "
>>
>> Es-tu sûr que sqlserver puisse géner l'execution du system ?
>> Pour moi utiliser un maxmemory sur sqlserver etait pour le cas où
>> d'autres
>> applications etiaent lancées sur le meme serveur. Afin qu'elle ne
>> pas
>> ralenti par SLQSERVER.
>> Mais pour ce qui est du system en lui-même, ca me parait bizare ... A
>> moins
>> que ca soit mal géré, et qu'il faille l'utiliser car "c'est plus sûr"
>> ?...
>>
>>
>>
>>
>>
>>
>> "Michel PRIORI" a écrit dans
>> message de news:
>> > Re,
>> >
>> > J'ai repensé à ton pb.
>> > Le fait que le serveur se fige peut être du à un manque de ressource
>> > ...
>> Ram.
>> > Par defaut le serveur SQL est configuré en allocation automatique
>> > 0
>> et
>> > toute la Ram.
>> > Il faut :
>> > 1- relever le minimum (puisqu'on a un ingénieur qui a pensé qu'un
>> > process
>> > pouvait tourner avec 0 octets en ram !!!) pour atteindre 75 Mo
>> > 2- abaisser le max (c'est le même ingénieur qui cette fois a pensé
>> > qu'un
>> > process pouvait prendre toute la ram quitte à virer les autres
>> comme
>> > ceux de windows !!!). Le choix de la valeur max depend si le serveur
>> > est
>> > dédié ou pas.
>> >
>> > De manière visuelle, dans l'entreprise ménagère/ propriété de
>> > l'instance /
>> > mémoire il faut bouger les curseurs de manière à ce qu'ils soient
>> > le
>> > vert (comme quoi l'ingénieur en question il savait qu'elles sont les
>> bonnes
>> > valeurs ;-)
>> >
>> > tiens nous au courant.
>> > "oLiVieR CheNeSoN" a écrit :
>> >
>> > > Bonjour,
>> > >
>> > >
>> > > J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
>> > >
>> > > On a un process qui recupere des donnees fichier et fait un BCP .
>> > >
>> > > Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il
>> > > a
>> > > 115852 lignes a inserer.
>> > >
>> > > Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer
>> donnees
>> > > marche.
>> > >
>> > > Pour plus de lignes par exemple 100000 lignes, les servers ne
>> plus
>> > > et se freeze. Oblige d eteindre la machine.
>> > >
>> > > Est ce qu il y a un bug connu pour les gros transfert ? ou quelque
>> > > chose
>> de
>> > > genre ?
>> > >
>> > >
>> > > Merci
>> > > Olivier
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>>
>>
>>
le paramètrage mémoire de SQLServer n'empêche pas le swap qui est géré par
l'OS, il permet d'essayer de le prévenir.
br
"Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> wrote in message
news:4F6C5EA7-7315-4D4E-9E04-9D0971FF4AD2@microsoft.com...
> Je suis toujours prenneur d'info.
> Des fois je retiens ce qu'on me dis et ne prend pas le temps de
> par moi même la véracité en faisant des tests. Surtout quand ça me
> cohérent !
>
> En ce qui concerne le parametrage de mémoire max dans le cadre de
> l'allocation dynamique de la RAM :
>
> 1- il ne faut pas la confondre avec le parametrage de mémoire min qui
> est fait pour "protéger" SQL de l'exclusion de la RAM même si son besoin
> en
> ram est tel qu'il est possible qu'un autre processus vienne la lui
> On indique donc quel est le seuil min de ram à garantir au process SQL.
>
> 2- la mémoire max indique donc le plafond d'allocation mémoire que SQL
> peut
> réclamer à l'OS. Sur l'interface graphique on note que la valeur max de
> parametre est égal à la quantité de ram adressable. En clair si on a un
> serveur à 256 Mo on peut aller jusqu'à 256 Mo ! je ne vois pas ce qu'il
> reste
> à windows dans un cas pareil. Le swap ?
>
> 3- Je pense que microsoft ne nous ments pas. Si un parametre permet
> d'allouer 100% de la RAM, ce serait étonnant qu'il existe une limitation
> non
> exprimée et présente dans le code. A partir de là la situation de hold
> de
> la Ram est plausible. Mais il est vrai que je ne l'ai pas éprouvé.
>
>
> Je valide donc ta remarque que dans le doute : "il faille l'utiliser car
> "c'est plus sûr""
> Désolé de faire cette réponse tout en nuances. C'est pas trop mon style.
>
>
>
> "deco" a écrit :
>
>> Qd tu dis : "c'est le même ingénieur qui cette fois a pensé qu'un
>> process pouvait prendre toute la ram quitte à virer les autres process
>> comme
>> ceux de windows !!!). "
>>
>> Es-tu sûr que sqlserver puisse géner l'execution du system ?
>> Pour moi utiliser un maxmemory sur sqlserver etait pour le cas où
>> d'autres
>> applications etiaent lancées sur le meme serveur. Afin qu'elle ne
>> pas
>> ralenti par SLQSERVER.
>> Mais pour ce qui est du system en lui-même, ca me parait bizare ... A
>> moins
>> que ca soit mal géré, et qu'il faille l'utiliser car "c'est plus sûr"
>> ?...
>>
>>
>>
>>
>>
>>
>> "Michel PRIORI" <MichelPRIORI@discussions.microsoft.com> a écrit dans
>> message de news:BD0FCF9F-4882-4713-9E5E-2699E4F0238F@microsoft.com...
>> > Re,
>> >
>> > J'ai repensé à ton pb.
>> > Le fait que le serveur se fige peut être du à un manque de ressource
>> > ...
>> Ram.
>> > Par defaut le serveur SQL est configuré en allocation automatique
>> > 0
>> et
>> > toute la Ram.
>> > Il faut :
>> > 1- relever le minimum (puisqu'on a un ingénieur qui a pensé qu'un
>> > process
>> > pouvait tourner avec 0 octets en ram !!!) pour atteindre 75 Mo
>> > 2- abaisser le max (c'est le même ingénieur qui cette fois a pensé
>> > qu'un
>> > process pouvait prendre toute la ram quitte à virer les autres
>> comme
>> > ceux de windows !!!). Le choix de la valeur max depend si le serveur
>> > est
>> > dédié ou pas.
>> >
>> > De manière visuelle, dans l'entreprise ménagère/ propriété de
>> > l'instance /
>> > mémoire il faut bouger les curseurs de manière à ce qu'ils soient
>> > le
>> > vert (comme quoi l'ingénieur en question il savait qu'elles sont les
>> bonnes
>> > valeurs ;-)
>> >
>> > tiens nous au courant.
>> > "oLiVieR CheNeSoN" a écrit :
>> >
>> > > Bonjour,
>> > >
>> > >
>> > > J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
>> > >
>> > > On a un process qui recupere des donnees fichier et fait un BCP .
>> > >
>> > > Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il
>> > > a
>> > > 115852 lignes a inserer.
>> > >
>> > > Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer
>> donnees
>> > > marche.
>> > >
>> > > Pour plus de lignes par exemple 100000 lignes, les servers ne
>> plus
>> > > et se freeze. Oblige d eteindre la machine.
>> > >
>> > > Est ce qu il y a un bug connu pour les gros transfert ? ou quelque
>> > > chose
>> de
>> > > genre ?
>> > >
>> > >
>> > > Merci
>> > > Olivier
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>>
>>
>>
le paramètrage mémoire de SQLServer n'empêche pas le swap qui est géré par
l'OS, il permet d'essayer de le prévenir.
br
"Michel PRIORI" wrote in message
news:
> Je suis toujours prenneur d'info.
> Des fois je retiens ce qu'on me dis et ne prend pas le temps de
> par moi même la véracité en faisant des tests. Surtout quand ça me
> cohérent !
>
> En ce qui concerne le parametrage de mémoire max dans le cadre de
> l'allocation dynamique de la RAM :
>
> 1- il ne faut pas la confondre avec le parametrage de mémoire min qui
> est fait pour "protéger" SQL de l'exclusion de la RAM même si son besoin
> en
> ram est tel qu'il est possible qu'un autre processus vienne la lui
> On indique donc quel est le seuil min de ram à garantir au process SQL.
>
> 2- la mémoire max indique donc le plafond d'allocation mémoire que SQL
> peut
> réclamer à l'OS. Sur l'interface graphique on note que la valeur max de
> parametre est égal à la quantité de ram adressable. En clair si on a un
> serveur à 256 Mo on peut aller jusqu'à 256 Mo ! je ne vois pas ce qu'il
> reste
> à windows dans un cas pareil. Le swap ?
>
> 3- Je pense que microsoft ne nous ments pas. Si un parametre permet
> d'allouer 100% de la RAM, ce serait étonnant qu'il existe une limitation
> non
> exprimée et présente dans le code. A partir de là la situation de hold
> de
> la Ram est plausible. Mais il est vrai que je ne l'ai pas éprouvé.
>
>
> Je valide donc ta remarque que dans le doute : "il faille l'utiliser car
> "c'est plus sûr""
> Désolé de faire cette réponse tout en nuances. C'est pas trop mon style.
>
>
>
> "deco" a écrit :
>
>> Qd tu dis : "c'est le même ingénieur qui cette fois a pensé qu'un
>> process pouvait prendre toute la ram quitte à virer les autres process
>> comme
>> ceux de windows !!!). "
>>
>> Es-tu sûr que sqlserver puisse géner l'execution du system ?
>> Pour moi utiliser un maxmemory sur sqlserver etait pour le cas où
>> d'autres
>> applications etiaent lancées sur le meme serveur. Afin qu'elle ne
>> pas
>> ralenti par SLQSERVER.
>> Mais pour ce qui est du system en lui-même, ca me parait bizare ... A
>> moins
>> que ca soit mal géré, et qu'il faille l'utiliser car "c'est plus sûr"
>> ?...
>>
>>
>>
>>
>>
>>
>> "Michel PRIORI" a écrit dans
>> message de news:
>> > Re,
>> >
>> > J'ai repensé à ton pb.
>> > Le fait que le serveur se fige peut être du à un manque de ressource
>> > ...
>> Ram.
>> > Par defaut le serveur SQL est configuré en allocation automatique
>> > 0
>> et
>> > toute la Ram.
>> > Il faut :
>> > 1- relever le minimum (puisqu'on a un ingénieur qui a pensé qu'un
>> > process
>> > pouvait tourner avec 0 octets en ram !!!) pour atteindre 75 Mo
>> > 2- abaisser le max (c'est le même ingénieur qui cette fois a pensé
>> > qu'un
>> > process pouvait prendre toute la ram quitte à virer les autres
>> comme
>> > ceux de windows !!!). Le choix de la valeur max depend si le serveur
>> > est
>> > dédié ou pas.
>> >
>> > De manière visuelle, dans l'entreprise ménagère/ propriété de
>> > l'instance /
>> > mémoire il faut bouger les curseurs de manière à ce qu'ils soient
>> > le
>> > vert (comme quoi l'ingénieur en question il savait qu'elles sont les
>> bonnes
>> > valeurs ;-)
>> >
>> > tiens nous au courant.
>> > "oLiVieR CheNeSoN" a écrit :
>> >
>> > > Bonjour,
>> > >
>> > >
>> > > J ai une gros souci avec mon SQL 2000 svr. SP3 sur Win2000
>> > >
>> > > On a un process qui recupere des donnees fichier et fait un BCP .
>> > >
>> > > Ensuite, les donnees inseres sont transferes par UPDATE,SELECT . Il
>> > > a
>> > > 115852 lignes a inserer.
>> > >
>> > > Apres des essaies, on a vu que jusqu a 90000 lignes. les transfer
>> donnees
>> > > marche.
>> > >
>> > > Pour plus de lignes par exemple 100000 lignes, les servers ne
>> plus
>> > > et se freeze. Oblige d eteindre la machine.
>> > >
>> > > Est ce qu il y a un bug connu pour les gros transfert ? ou quelque
>> > > chose
>> de
>> > > genre ?
>> > >
>> > >
>> > > Merci
>> > > Olivier
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>>
>>
>>