Bonjour,
nous avons une base SQL en version 2000 SP3 installé sur un serveur W2K Pack
3.
Le serveur dispose de 3 Go de RAM.
J'ai plusieurs problèmes avec notre base de donnée de production.
1) Est-il normal que la date des deux fichiers qui constituent ma base ( le
.MDF et le .LDF) ne change jamais. Cette date ne change que lorsque je stoppe
mon serveur alors que nous avons des insert et update qui sont fais toute la
journée.
2) Lorsque je stoppe le serveur SQL, la RAM descend à 200Mo utilisé.
Après quelques heures d'utilisation, la RAM monte à 2Go et à partir de ce
moment, la plupart des query executées via ADO renvoient un time out. Par
contre, si nous restoppons la base alors tout se repasse bien jusqu'à ce que
la RAM utilisée soit encore une fois de 2Go.
En fait, c'est comme si le serveur n'écrivait rien dans les deux fichiers
LDF et MDF, et qu'il gardait tout en mémoire ?
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
jgabillaud
Avez vous définie l'option recovery interval via sp_configure afin de forcer SQL Server à écrire régulièrement sur les disques?
"PICARD Cyril" a écrit :
Bonjour, nous avons une base SQL en version 2000 SP3 installé sur un serveur W2K Pack 3.
Le serveur dispose de 3 Go de RAM.
J'ai plusieurs problèmes avec notre base de donnée de production.
1) Est-il normal que la date des deux fichiers qui constituent ma base ( le .MDF et le .LDF) ne change jamais. Cette date ne change que lorsque je stoppe mon serveur alors que nous avons des insert et update qui sont fais toute la journée.
2) Lorsque je stoppe le serveur SQL, la RAM descend à 200Mo utilisé. Après quelques heures d'utilisation, la RAM monte à 2Go et à partir de ce moment, la plupart des query executées via ADO renvoient un time out. Par contre, si nous restoppons la base alors tout se repasse bien jusqu'à ce que la RAM utilisée soit encore une fois de 2Go.
En fait, c'est comme si le serveur n'écrivait rien dans les deux fichiers LDF et MDF, et qu'il gardait tout en mémoire ?
Quelqu'un peut 'il me renseigner ?
Merci.
Cyril.
Avez vous définie l'option recovery interval via sp_configure afin de forcer
SQL Server à écrire régulièrement sur les disques?
"PICARD Cyril" a écrit :
Bonjour,
nous avons une base SQL en version 2000 SP3 installé sur un serveur W2K Pack
3.
Le serveur dispose de 3 Go de RAM.
J'ai plusieurs problèmes avec notre base de donnée de production.
1) Est-il normal que la date des deux fichiers qui constituent ma base ( le
.MDF et le .LDF) ne change jamais. Cette date ne change que lorsque je stoppe
mon serveur alors que nous avons des insert et update qui sont fais toute la
journée.
2) Lorsque je stoppe le serveur SQL, la RAM descend à 200Mo utilisé.
Après quelques heures d'utilisation, la RAM monte à 2Go et à partir de ce
moment, la plupart des query executées via ADO renvoient un time out. Par
contre, si nous restoppons la base alors tout se repasse bien jusqu'à ce que
la RAM utilisée soit encore une fois de 2Go.
En fait, c'est comme si le serveur n'écrivait rien dans les deux fichiers
LDF et MDF, et qu'il gardait tout en mémoire ?
Avez vous définie l'option recovery interval via sp_configure afin de forcer SQL Server à écrire régulièrement sur les disques?
"PICARD Cyril" a écrit :
Bonjour, nous avons une base SQL en version 2000 SP3 installé sur un serveur W2K Pack 3.
Le serveur dispose de 3 Go de RAM.
J'ai plusieurs problèmes avec notre base de donnée de production.
1) Est-il normal que la date des deux fichiers qui constituent ma base ( le .MDF et le .LDF) ne change jamais. Cette date ne change que lorsque je stoppe mon serveur alors que nous avons des insert et update qui sont fais toute la journée.
2) Lorsque je stoppe le serveur SQL, la RAM descend à 200Mo utilisé. Après quelques heures d'utilisation, la RAM monte à 2Go et à partir de ce moment, la plupart des query executées via ADO renvoient un time out. Par contre, si nous restoppons la base alors tout se repasse bien jusqu'à ce que la RAM utilisée soit encore une fois de 2Go.
En fait, c'est comme si le serveur n'écrivait rien dans les deux fichiers LDF et MDF, et qu'il gardait tout en mémoire ?
Quelqu'un peut 'il me renseigner ?
Merci.
Cyril.
lionelp
Bonjour,
SQL server maintient les fichier ouverts tant qu'il tourne, il n'y a aucune raison de regarder leur date de modification. Les erreurs de timeout sont certainement dues à des verrouillages applicatifs, sur support.microsoft.com il y a des articles qui donent une méthodologie d'analyse de ces problèmes. Pour l'utilisation de la mémoire, pour simplifier il n'y a pas de corrélation entre sa taille et les timeouts.
Cordialement, LionelP
"PICARD Cyril" a écrit :
Bonjour, nous avons une base SQL en version 2000 SP3 installé sur un serveur W2K Pack 3.
Le serveur dispose de 3 Go de RAM.
J'ai plusieurs problèmes avec notre base de donnée de production.
1) Est-il normal que la date des deux fichiers qui constituent ma base ( le .MDF et le .LDF) ne change jamais. Cette date ne change que lorsque je stoppe mon serveur alors que nous avons des insert et update qui sont fais toute la journée.
2) Lorsque je stoppe le serveur SQL, la RAM descend à 200Mo utilisé. Après quelques heures d'utilisation, la RAM monte à 2Go et à partir de ce moment, la plupart des query executées via ADO renvoient un time out. Par contre, si nous restoppons la base alors tout se repasse bien jusqu'à ce que la RAM utilisée soit encore une fois de 2Go.
En fait, c'est comme si le serveur n'écrivait rien dans les deux fichiers LDF et MDF, et qu'il gardait tout en mémoire ?
Quelqu'un peut 'il me renseigner ?
Merci.
Cyril.
Bonjour,
SQL server maintient les fichier ouverts tant qu'il tourne, il n'y a aucune
raison de regarder leur date de modification.
Les erreurs de timeout sont certainement dues à des verrouillages
applicatifs, sur support.microsoft.com il y a des articles qui donent une
méthodologie d'analyse de ces problèmes.
Pour l'utilisation de la mémoire, pour simplifier il n'y a pas de
corrélation entre sa taille et les timeouts.
Cordialement,
LionelP
"PICARD Cyril" a écrit :
Bonjour,
nous avons une base SQL en version 2000 SP3 installé sur un serveur W2K Pack
3.
Le serveur dispose de 3 Go de RAM.
J'ai plusieurs problèmes avec notre base de donnée de production.
1) Est-il normal que la date des deux fichiers qui constituent ma base ( le
.MDF et le .LDF) ne change jamais. Cette date ne change que lorsque je stoppe
mon serveur alors que nous avons des insert et update qui sont fais toute la
journée.
2) Lorsque je stoppe le serveur SQL, la RAM descend à 200Mo utilisé.
Après quelques heures d'utilisation, la RAM monte à 2Go et à partir de ce
moment, la plupart des query executées via ADO renvoient un time out. Par
contre, si nous restoppons la base alors tout se repasse bien jusqu'à ce que
la RAM utilisée soit encore une fois de 2Go.
En fait, c'est comme si le serveur n'écrivait rien dans les deux fichiers
LDF et MDF, et qu'il gardait tout en mémoire ?
SQL server maintient les fichier ouverts tant qu'il tourne, il n'y a aucune raison de regarder leur date de modification. Les erreurs de timeout sont certainement dues à des verrouillages applicatifs, sur support.microsoft.com il y a des articles qui donent une méthodologie d'analyse de ces problèmes. Pour l'utilisation de la mémoire, pour simplifier il n'y a pas de corrélation entre sa taille et les timeouts.
Cordialement, LionelP
"PICARD Cyril" a écrit :
Bonjour, nous avons une base SQL en version 2000 SP3 installé sur un serveur W2K Pack 3.
Le serveur dispose de 3 Go de RAM.
J'ai plusieurs problèmes avec notre base de donnée de production.
1) Est-il normal que la date des deux fichiers qui constituent ma base ( le .MDF et le .LDF) ne change jamais. Cette date ne change que lorsque je stoppe mon serveur alors que nous avons des insert et update qui sont fais toute la journée.
2) Lorsque je stoppe le serveur SQL, la RAM descend à 200Mo utilisé. Après quelques heures d'utilisation, la RAM monte à 2Go et à partir de ce moment, la plupart des query executées via ADO renvoient un time out. Par contre, si nous restoppons la base alors tout se repasse bien jusqu'à ce que la RAM utilisée soit encore une fois de 2Go.
En fait, c'est comme si le serveur n'écrivait rien dans les deux fichiers LDF et MDF, et qu'il gardait tout en mémoire ?
Quelqu'un peut 'il me renseigner ?
Merci.
Cyril.
Fred BROUARD
En complément ...
a écrit:
Bonjour,
SQL server maintient les fichier ouverts tant qu'il tourne, il n'y a aucune raison de regarder leur date de modification. Les erreurs de timeout sont certainement dues à des verrouillages applicatifs, sur support.microsoft.com il y a des articles qui donent une méthodologie d'analyse de ces problèmes.
Quel est le style de codage de l'application ? Accès direct via table ? Utilisation de requêtes ?? De procédures stockées ??? L'aplication as t-elle été écrite pour SQL Server ou bien pour un autre SGBDR sans portage ??? (je pense à Access).
A +
Pour l'utilisation de la mémoire, pour simplifier il n'y a pas de corrélation entre sa taille et les timeouts.
Cordialement, LionelP
"PICARD Cyril" a écrit :
Bonjour, nous avons une base SQL en version 2000 SP3 installé sur un serveur W2K Pack 3.
Le serveur dispose de 3 Go de RAM.
J'ai plusieurs problèmes avec notre base de donnée de production.
1) Est-il normal que la date des deux fichiers qui constituent ma base ( le .MDF et le .LDF) ne change jamais. Cette date ne change que lorsque je stoppe mon serveur alors que nous avons des insert et update qui sont fais toute la journée.
2) Lorsque je stoppe le serveur SQL, la RAM descend à 200Mo utilisé. Après quelques heures d'utilisation, la RAM monte à 2Go et à partir de ce moment, la plupart des query executées via ADO renvoient un time out. Par contre, si nous restoppons la base alors tout se repasse bien jusqu'à ce que la RAM utilisée soit encore une fois de 2Go.
En fait, c'est comme si le serveur n'écrivait rien dans les deux fichiers LDF et MDF, et qu'il gardait tout en mémoire ?
Quelqu'un peut 'il me renseigner ?
Merci.
Cyril.
-- 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 *************************
En complément ...
lionelp@online.microsoft.com a écrit:
Bonjour,
SQL server maintient les fichier ouverts tant qu'il tourne, il n'y a aucune
raison de regarder leur date de modification.
Les erreurs de timeout sont certainement dues à des verrouillages
applicatifs, sur support.microsoft.com il y a des articles qui donent une
méthodologie d'analyse de ces problèmes.
Quel est le style de codage de l'application ? Accès direct via table ?
Utilisation de requêtes ?? De procédures stockées ???
L'aplication as t-elle été écrite pour SQL Server ou bien pour un autre SGBDR
sans portage ??? (je pense à Access).
A +
Pour l'utilisation de la mémoire, pour simplifier il n'y a pas de
corrélation entre sa taille et les timeouts.
Cordialement,
LionelP
"PICARD Cyril" a écrit :
Bonjour,
nous avons une base SQL en version 2000 SP3 installé sur un serveur W2K Pack
3.
Le serveur dispose de 3 Go de RAM.
J'ai plusieurs problèmes avec notre base de donnée de production.
1) Est-il normal que la date des deux fichiers qui constituent ma base ( le
.MDF et le .LDF) ne change jamais. Cette date ne change que lorsque je stoppe
mon serveur alors que nous avons des insert et update qui sont fais toute la
journée.
2) Lorsque je stoppe le serveur SQL, la RAM descend à 200Mo utilisé.
Après quelques heures d'utilisation, la RAM monte à 2Go et à partir de ce
moment, la plupart des query executées via ADO renvoient un time out. Par
contre, si nous restoppons la base alors tout se repasse bien jusqu'à ce que
la RAM utilisée soit encore une fois de 2Go.
En fait, c'est comme si le serveur n'écrivait rien dans les deux fichiers
LDF et MDF, et qu'il gardait tout en mémoire ?
Quelqu'un peut 'il me renseigner ?
Merci.
Cyril.
--
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 *************************
SQL server maintient les fichier ouverts tant qu'il tourne, il n'y a aucune raison de regarder leur date de modification. Les erreurs de timeout sont certainement dues à des verrouillages applicatifs, sur support.microsoft.com il y a des articles qui donent une méthodologie d'analyse de ces problèmes.
Quel est le style de codage de l'application ? Accès direct via table ? Utilisation de requêtes ?? De procédures stockées ??? L'aplication as t-elle été écrite pour SQL Server ou bien pour un autre SGBDR sans portage ??? (je pense à Access).
A +
Pour l'utilisation de la mémoire, pour simplifier il n'y a pas de corrélation entre sa taille et les timeouts.
Cordialement, LionelP
"PICARD Cyril" a écrit :
Bonjour, nous avons une base SQL en version 2000 SP3 installé sur un serveur W2K Pack 3.
Le serveur dispose de 3 Go de RAM.
J'ai plusieurs problèmes avec notre base de donnée de production.
1) Est-il normal que la date des deux fichiers qui constituent ma base ( le .MDF et le .LDF) ne change jamais. Cette date ne change que lorsque je stoppe mon serveur alors que nous avons des insert et update qui sont fais toute la journée.
2) Lorsque je stoppe le serveur SQL, la RAM descend à 200Mo utilisé. Après quelques heures d'utilisation, la RAM monte à 2Go et à partir de ce moment, la plupart des query executées via ADO renvoient un time out. Par contre, si nous restoppons la base alors tout se repasse bien jusqu'à ce que la RAM utilisée soit encore une fois de 2Go.
En fait, c'est comme si le serveur n'écrivait rien dans les deux fichiers LDF et MDF, et qu'il gardait tout en mémoire ?
Quelqu'un peut 'il me renseigner ?
Merci.
Cyril.
-- 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 *************************
