Mémoire

Bonjour,

Comme tout bon SGBDR SQL Server est taillé pour utiliser au maximum toutes les
ressources dont il a besoin, c'est à dire la RAM et le disque principalement.

Les lectures de SQL Server se font TOUJOURS en RAM. Autrement dit la lecture
d'une table suppose qu'elle est montée en mémoire. Si ce n'est pas le cas, SQL
Server l'y place avant de lire.
Dans le but d'optimiser le fonctionnement et donner les meilleurs performances,
SQL Server utilise toute la mémoire qu'il trouve sur le serveur en fonction de
ses besoins. Il ne restituera de la mamoire que dans un seul cas : si l'OS est
"stressé" et lui demande expressément d'en restituer.
SQL server est donc "super prioritaire" au niveau de la mémoire, au détriment de
toutes les autres applications.

Deux solutions :
1) placer SQL Server sur une machine dédiée et interdire toute autre application
c'est la meilleure solution
2) indiquer à SQL server de limiter son buffer mémoire
les performances en seront dégradées, mais les autres applications tourneront,
sans pour autant être sûr de la synchro

Si cela n'est pas efficace : augmenter la mémoire (2 à 4 Go), optez pour des
disques plus rapide.

Question subsidiaires :
Le PC hébergeant SQL Server est-il un VRAI serveur ?
Les disques sont-ils des SCSI sous système RAID ?
Le fichier de journalisation est-il installé sur une grappe de disque différente
de celle de la base ?

Dans tout les cas ou ceci serait inéfficace, pensez à auditer le serveur pour
savoir ce qui se passe.

A lire :
http://sqlpro.developpez.com/cours/optimiser/

A +

--
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 *************************




Boris a écrit:

Bonjour,

j'ai un client qui réceptionne les données de 40 automates
et qui me les envoient sur un SQL2000. Le client
fonctionne 24/24 mais SQL prend tellement en mémoire (90%
de la mémoire de 1Go de RAM) que le système fini par
planter en timeout car le client ne peut plus joindre la
BD, un reboot de la base s'impose mais entre temps j'ai
perdu des données, et comme ça se passe la nuit tant que
je me rendre compte du pb, il est 8H et on a perdu 6 h de
données !!! Je souhaiterai que mon appli fonctionne 24/24
avec à la rigueur un reboot le week-end pur tout purger
mais sans plus.
Est ce que quelqu'un comprend mon pb et pourrait avoir un
élément de solution ?
Merci
Boris

Merci de votre réponse.
La base est bien sur un serveur dédiée, raid 5, scsi, 1Go
de RAM et le journal est sur un autre disque que les
données, donc à priori tous pour tout fonctionne bien.

Quel audit efficae dois je mettre en place car il en
existe un gd nombre... et malheureusement je ne peux me
contenter de faire reboot quotidien, j'ai trop de perte de
données.

J'ai un client qui ne fait que des insertions de données
et un autre en intranet qui les consulte toutes les mns.
donc toutes les mns je li des tables, si j'ai bien compris
cette lecture ferai également des montées mémoires ?
impossible de les lbérer ?

-----Message d'origine-----
Bonjour,

Comme tout bon SGBDR SQL Server est taillé pour utiliser

au maximum toutes les

ressources dont il a besoin, c'est à dire la RAM et le

disque principalement.

Les lectures de SQL Server se font TOUJOURS en RAM.

Autrement dit la lecture

d'une table suppose qu'elle est montée en mémoire. Si ce

n'est pas le cas, SQL

Server l'y place avant de lire.
Dans le but d'optimiser le fonctionnement et donner les

meilleurs performances,

SQL Server utilise toute la mémoire qu'il trouve sur le

serveur en fonction de

ses besoins. Il ne restituera de la mamoire que dans un

seul cas : si l'OS est

"stressé" et lui demande expressément d'en restituer.
SQL server est donc "super prioritaire" au niveau de la

mémoire, au détriment de

toutes les autres applications.

Deux solutions :
1) placer SQL Server sur une machine dédiée et interdire

toute autre application

c'est la meilleure solution
2) indiquer à SQL server de limiter son buffer mémoire
les performances en seront dégradées, mais les autres

applications tourneront,

sans pour autant être sûr de la synchro

Si cela n'est pas efficace : augmenter la mémoire (2 à 4

Go), optez pour des

disques plus rapide.

Question subsidiaires :
Le PC hébergeant SQL Server est-il un VRAI serveur ?
Les disques sont-ils des SCSI sous système RAID ?
Le fichier de journalisation est-il installé sur une

grappe de disque différente

de celle de la base ?

Dans tout les cas ou ceci serait inéfficace, pensez à

auditer le serveur pour

savoir ce qui se passe.

A lire :
http://sqlpro.developpez.com/cours/optimiser/

A +

--
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

*************************

Boris a écrit:

Bonjour,

j'ai un client qui réceptionne les données de 40

automates

et qui me les envoient sur un SQL2000. Le client
fonctionne 24/24 mais SQL prend tellement en mémoire

(90%

de la mémoire de 1Go de RAM) que le système fini par
planter en timeout car le client ne peut plus joindre

la

BD, un reboot de la base s'impose mais entre temps j'ai
perdu des données, et comme ça se passe la nuit tant

que

je me rendre compte du pb, il est 8H et on a perdu 6 h

de

données !!! Je souhaiterai que mon appli fonctionne

24/24

avec à la rigueur un reboot le week-end pur tout purger
mais sans plus.
Est ce que quelqu'un comprend mon pb et pourrait avoir

un

élément de solution ?
Merci
Boris

.

mns ??? m = minute, ms = milliseconde.

boris a écrit:

Merci de votre réponse.
La base est bien sur un serveur dédiée, raid 5, scsi, 1Go
de RAM et le journal est sur un autre disque que les
données, donc à priori tous pour tout fonctionne bien.

Quelle est la taille de la base ?

Quel audit efficae dois je mettre en place car il en
existe un gd nombre... et malheureusement je ne peux me
contenter de faire reboot quotidien, j'ai trop de perte de
données.

Difficile de vous orienter sans plus d'explication.

Les compteurs les plus importants sont les suivants. Mais avant cela ragardez si
une erreur récurente n'a pas lieu dans les journaux.


Processeur
% Temps Processeur
% Temps Privilégié
% Temps Utilisateur
% Temps d'interruption
Interruptions/s

système
Changements de contexte/s .
Longueur de la file du processeur

SQL server : buffer manager (mémoire tampon de SQL Server)
Buffer cache hit ratio
Procedure cache page
Free pages
Stolen Pages

SQL Server : Databases Objects (objets de la base de données)
Log Flush Wait/sec

SQL Server : General Statistic Objects (activité de la base et connexion)
User connections

SQL Server : Latches Objects ("loquets" sur objets)
Average Latch Wait Time (ms)
Latch wait /sec

SQL Server : Locks Objects (verrous d'objets)
Average wait time (ms)
Lock Timeout/sec
Lock Wait/sec
Number of Deadlocks/sec

SQL Server : Memory Manager Object (gestion de la mémoire allouée aux objets)
Memory Grant Pending
Target Server Memory (KB)
Total Server Memory (KB)

SQL Server : Statistics Object (statistiques sur objet)
Batch Requests/sec
SQL Compilations/sec
SQL Re-Compilations/sec
Diminuez le nbr. Batch Requests/sec en passant vos lots SQL en un seul coup.
Cela minimise les temps de compilation et les espaces de stockage intermédiaires.
LogicalDisk / PhysicalDisk Object (disques physiques et logiques)
% Disk Read Time
% Disk Write Time
% Disk Time
% Idle Time
Avg. Disk Queue Length
Avg. Disk Read Queue Length
Avg. Disk Write Queue Length
Avg. Disk sec/Read
Avg. Disk sec/Write
Avg. Disk sec/Transfer
Disk Reads/sec
Disk Writes/sec
Disk Transfer/sec

Mémory (mémoire)
Page Faults/sec
Page Reads/sec
Page Writes/sec
Pages/sec

J'ai un client qui ne fait que des insertions de données
et un autre en intranet qui les consulte toutes les mns.
donc toutes les mns je li des tables, si j'ai bien compris
cette lecture ferai également des montées mémoires ?
impossible de les lbérer ?

ce n'est pas toi qui impose à SQL Server sa manière de travailler.

A +

-----Message d'origine-----
Bonjour,

Comme tout bon SGBDR SQL Server est taillé pour utiliser

au maximum toutes les

ressources dont il a besoin, c'est à dire la RAM et le

disque principalement.

Les lectures de SQL Server se font TOUJOURS en RAM.

Autrement dit la lecture

d'une table suppose qu'elle est montée en mémoire. Si ce

n'est pas le cas, SQL

Server l'y place avant de lire.
Dans le but d'optimiser le fonctionnement et donner les

meilleurs performances,

SQL Server utilise toute la mémoire qu'il trouve sur le

serveur en fonction de

ses besoins. Il ne restituera de la mamoire que dans un

seul cas : si l'OS est

"stressé" et lui demande expressément d'en restituer.
SQL server est donc "super prioritaire" au niveau de la

mémoire, au détriment de

toutes les autres applications.

Deux solutions :
1) placer SQL Server sur une machine dédiée et interdire

toute autre application

c'est la meilleure solution
2) indiquer à SQL server de limiter son buffer mémoire
les performances en seront dégradées, mais les autres

applications tourneront,

sans pour autant être sûr de la synchro

Si cela n'est pas efficace : augmenter la mémoire (2 à 4

Go), optez pour des

disques plus rapide.

Question subsidiaires :
Le PC hébergeant SQL Server est-il un VRAI serveur ?
Les disques sont-ils des SCSI sous système RAID ?
Le fichier de journalisation est-il installé sur une

grappe de disque différente

de celle de la base ?

Dans tout les cas ou ceci serait inéfficace, pensez à

auditer le serveur pour

savoir ce qui se passe.

A lire :
http://sqlpro.developpez.com/cours/optimiser/

A +

--
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

*************************

Boris a écrit:

Bonjour,

j'ai un client qui réceptionne les données de 40

automates

et qui me les envoient sur un SQL2000. Le client
fonctionne 24/24 mais SQL prend tellement en mémoire

(90%

de la mémoire de 1Go de RAM) que le système fini par
planter en timeout car le client ne peut plus joindre

la

BD, un reboot de la base s'impose mais entre temps j'ai
perdu des données, et comme ça se passe la nuit tant

que

je me rendre compte du pb, il est 8H et on a perdu 6 h

de

données !!! Je souhaiterai que mon appli fonctionne

24/24

avec à la rigueur un reboot le week-end pur tout purger
mais sans plus.
Est ce que quelqu'un comprend mon pb et pourrait avoir

un

élément de solution ?
Merci
Boris

.

--
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 *************************

Lorsque SQL Server a besoin accéder à des données, il effectue une lecture
sur une page. Si cette page est déjà en mémoire (dans le buffer pool), c'est
bon. Si cette page n'est pas en mémoire, il la lit sur disque est la place
dans un buffer, il utilise un buffer libre ou pas utilisé dernièrement. Ceci
est effectué par page est non par page.



SQL détermine la mémoire qu'il utilise soit de façon dynamique soit de façon
statique.



En dynamique, SQL va utiliser le plus de mémoire possible afin d'avoir un
buffer pool le plus grand possible. Si aucun autre processus de demande de
la mémoire, SQL va monter jusqu'à en laisser juste pour NT. Si un processus
se réveille et demande de la mémoire, SQL va en libérer, mais souvent pas
assez vite. Dans ce genre de configuration il est bon de donner une valeur
maximum à SQL Server.



Je vous recommande de regarder ces compteurs :

a.. Process Object
1.. Virtual Bytes - reserved virtual memory
2.. Private Bytes - committed virtual memory
b.. SQL Server:Buffer Partition
1.. Free list statistics
c.. SQL Server:Buffer Manager
1.. Stolen, Target, Total
d.. SQL Server:Memory Manager
1.. Memory manager statistics, etc.
Vous pouvez aussi regarder la répartition de mémoire interne à SQL avec DBCC
MEMORYSTATUS (Q271624 INF: Using DBCC MEMORYSTATUS to Monitor SQL Server
Memory Usage)


--
Cdlt,

FP


"boris" <anonymous@discussions.microsoft.com> wrote in message
news:096001c4b109$d0df8cb0$a601280a@phx.gbl...
Merci de votre réponse.
La base est bien sur un serveur dédiée, raid 5, scsi, 1Go
de RAM et le journal est sur un autre disque que les
données, donc à priori tous pour tout fonctionne bien.

Quel audit efficae dois je mettre en place car il en
existe un gd nombre... et malheureusement je ne peux me
contenter de faire reboot quotidien, j'ai trop de perte de
données.

J'ai un client qui ne fait que des insertions de données
et un autre en intranet qui les consulte toutes les mns.
donc toutes les mns je li des tables, si j'ai bien compris
cette lecture ferai également des montées mémoires ?
impossible de les lbérer ?

-----Message d'origine-----
Bonjour,

Comme tout bon SGBDR SQL Server est taillé pour utiliser

au maximum toutes les

ressources dont il a besoin, c'est à dire la RAM et le

disque principalement.

Les lectures de SQL Server se font TOUJOURS en RAM.

Autrement dit la lecture

d'une table suppose qu'elle est montée en mémoire. Si ce

n'est pas le cas, SQL

Server l'y place avant de lire.
Dans le but d'optimiser le fonctionnement et donner les

meilleurs performances,

SQL Server utilise toute la mémoire qu'il trouve sur le

serveur en fonction de

ses besoins. Il ne restituera de la mamoire que dans un

seul cas : si l'OS est

"stressé" et lui demande expressément d'en restituer.
SQL server est donc "super prioritaire" au niveau de la

mémoire, au détriment de

toutes les autres applications.

Deux solutions :
1) placer SQL Server sur une machine dédiée et interdire

toute autre application

c'est la meilleure solution
2) indiquer à SQL server de limiter son buffer mémoire
les performances en seront dégradées, mais les autres

applications tourneront,

sans pour autant être sûr de la synchro

Si cela n'est pas efficace : augmenter la mémoire (2 à 4

Go), optez pour des

disques plus rapide.

Question subsidiaires :
Le PC hébergeant SQL Server est-il un VRAI serveur ?
Les disques sont-ils des SCSI sous système RAID ?
Le fichier de journalisation est-il installé sur une

grappe de disque différente

de celle de la base ?

Dans tout les cas ou ceci serait inéfficace, pensez à

auditer le serveur pour

savoir ce qui se passe.

A lire :
http://sqlpro.developpez.com/cours/optimiser/

A +

--
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

*************************

Boris a écrit:

Bonjour,

j'ai un client qui réceptionne les données de 40

automates

et qui me les envoient sur un SQL2000. Le client
fonctionne 24/24 mais SQL prend tellement en mémoire

(90%

de la mémoire de 1Go de RAM) que le système fini par
planter en timeout car le client ne peut plus joindre

la

BD, un reboot de la base s'impose mais entre temps j'ai
perdu des données, et comme ça se passe la nuit tant

que

je me rendre compte du pb, il est 8H et on a perdu 6 h

de

données !!! Je souhaiterai que mon appli fonctionne

24/24

avec à la rigueur un reboot le week-end pur tout purger
mais sans plus.
Est ce que quelqu'un comprend mon pb et pourrait avoir

un

élément de solution ?
Merci
Boris

.