Depuis peu, la grande majorité des mises à jours ou insertions de données
sur mon site web finissent 'presque' toutes en une exception 'Timeout expired'.
Cela fait plusieurs jours que je tente de trouver la source du problème, mais
en vain, j'en viens donc à demander de l'aide sur les groupes...
Il s'agit d'une appliction AspNet,
Les timeouts ont été placés à 15 secondes,
Dans tous les cas, il s'agit de mettre à jour 1 entrée ou d'ajouter 1 entrée
dans une des deux tables.
Chaque table contient respectivement 1500 et 4500 entrées.
1) INSERT INTO tbl_commentaires VALUES (blababla , ....
2) UPDATE tbl_news SET vues = (vues + 1) WHERE ID = x
Il n'y a pas d'indexes créé , excepté l'index de clé primaire.
Erreur détaillée:
"Timeout expired. The timeout period elapsed prior to completion of
the operation or the server is not responding."
Et une question pour finir : si je passe les timeout à 45 secondes, souvent
cela fini par passer. Mais........pour quelle raison cela pourrait-il être si
long ??!!?
Si quelqu'un a des idées à me proposer ou si un supplément d'informations
est nécessaire, je suis preneur !!!
les time out sont les conséquences en général de problèmes de contention, qui peuvent venir, par exemple d'un grand nombre de clients à servir ou de verrous bloquant...
Si vos requêtes 1 et 2 sont combinées et participent à un même traitement vous devriez mettre tout ceci dans une procédure stockée si possible transactionnées. Cela éviterait les aller et retours réseaux générateurs de gaspillage de temps, donc de contention.
Du genre :
CREATE PROCEDURE P_IU_COMMENT_NEWS @VAR1 ... AS
BEGIN TRANSACTION
INSERT INTO tbl_commentaires VALUES (blababla , ....
IF @@ERROR <> GOTO LBL_ROLL
UPDATE tbl_news SET vues = vues + 1 WHERE ID = x
IF @@ERROR <> GOTO LBL_ROLL
COMMIT TRANSACTION RETURN
LBL_ROLL: ROLLBACK TRANSACTION
De manière très générale il vaut mieux procéder avec des procédures qu'avec des requêtes pour tout ce qui est mis à jour de données au moins (INSERT, UPDATE, DELETE).
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 *************************
Cactus Corp. a écrit:
Bonjour!
Depuis peu, la grande majorité des mises à jours ou insertions de données sur mon site web finissent 'presque' toutes en une exception 'Timeout expired'. Cela fait plusieurs jours que je tente de trouver la source du problème, mais en vain, j'en viens donc à demander de l'aide sur les groupes...
Il s'agit d'une appliction AspNet,
Les timeouts ont été placés à 15 secondes,
Dans tous les cas, il s'agit de mettre à jour 1 entrée ou d'ajouter 1 entrée dans une des deux tables.
Chaque table contient respectivement 1500 et 4500 entrées.
1) INSERT INTO tbl_commentaires VALUES (blababla , .... 2) UPDATE tbl_news SET vues = (vues + 1) WHERE ID = x
Il n'y a pas d'indexes créé , excepté l'index de clé primaire.
Erreur détaillée: "Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding."
Et une question pour finir : si je passe les timeout à 45 secondes, souvent cela fini par passer. Mais........pour quelle raison cela pourrait-il être si long ??!!?
Si quelqu'un a des idées à me proposer ou si un supplément d'informations est nécessaire, je suis preneur !!!
Antonio
les time out sont les conséquences en général de problèmes de contention, qui
peuvent venir, par exemple d'un grand nombre de clients à servir ou de verrous
bloquant...
Si vos requêtes 1 et 2 sont combinées et participent à un même traitement vous
devriez mettre tout ceci dans une procédure stockée si possible transactionnées.
Cela éviterait les aller et retours réseaux générateurs de gaspillage de temps,
donc de contention.
Du genre :
CREATE PROCEDURE P_IU_COMMENT_NEWS @VAR1 ...
AS
BEGIN TRANSACTION
INSERT INTO tbl_commentaires
VALUES (blababla , ....
IF @@ERROR <>
GOTO LBL_ROLL
UPDATE tbl_news
SET vues = vues + 1
WHERE ID = x
IF @@ERROR <>
GOTO LBL_ROLL
COMMIT TRANSACTION
RETURN
LBL_ROLL:
ROLLBACK TRANSACTION
De manière très générale il vaut mieux procéder avec des procédures qu'avec des
requêtes pour tout ce qui est mis à jour de données au moins (INSERT, UPDATE,
DELETE).
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 *************************
Cactus Corp. a écrit:
Bonjour!
Depuis peu, la grande majorité des mises à jours ou insertions de données
sur mon site web finissent 'presque' toutes en une exception 'Timeout expired'.
Cela fait plusieurs jours que je tente de trouver la source du problème, mais
en vain, j'en viens donc à demander de l'aide sur les groupes...
Il s'agit d'une appliction AspNet,
Les timeouts ont été placés à 15 secondes,
Dans tous les cas, il s'agit de mettre à jour 1 entrée ou d'ajouter 1 entrée
dans une des deux tables.
Chaque table contient respectivement 1500 et 4500 entrées.
1) INSERT INTO tbl_commentaires VALUES (blababla , ....
2) UPDATE tbl_news SET vues = (vues + 1) WHERE ID = x
Il n'y a pas d'indexes créé , excepté l'index de clé primaire.
Erreur détaillée:
"Timeout expired. The timeout period elapsed prior to completion of
the operation or the server is not responding."
Et une question pour finir : si je passe les timeout à 45 secondes, souvent
cela fini par passer. Mais........pour quelle raison cela pourrait-il être si
long ??!!?
Si quelqu'un a des idées à me proposer ou si un supplément d'informations
est nécessaire, je suis preneur !!!
les time out sont les conséquences en général de problèmes de contention, qui peuvent venir, par exemple d'un grand nombre de clients à servir ou de verrous bloquant...
Si vos requêtes 1 et 2 sont combinées et participent à un même traitement vous devriez mettre tout ceci dans une procédure stockée si possible transactionnées. Cela éviterait les aller et retours réseaux générateurs de gaspillage de temps, donc de contention.
Du genre :
CREATE PROCEDURE P_IU_COMMENT_NEWS @VAR1 ... AS
BEGIN TRANSACTION
INSERT INTO tbl_commentaires VALUES (blababla , ....
IF @@ERROR <> GOTO LBL_ROLL
UPDATE tbl_news SET vues = vues + 1 WHERE ID = x
IF @@ERROR <> GOTO LBL_ROLL
COMMIT TRANSACTION RETURN
LBL_ROLL: ROLLBACK TRANSACTION
De manière très générale il vaut mieux procéder avec des procédures qu'avec des requêtes pour tout ce qui est mis à jour de données au moins (INSERT, UPDATE, DELETE).
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 *************************
Cactus Corp. a écrit:
Bonjour!
Depuis peu, la grande majorité des mises à jours ou insertions de données sur mon site web finissent 'presque' toutes en une exception 'Timeout expired'. Cela fait plusieurs jours que je tente de trouver la source du problème, mais en vain, j'en viens donc à demander de l'aide sur les groupes...
Il s'agit d'une appliction AspNet,
Les timeouts ont été placés à 15 secondes,
Dans tous les cas, il s'agit de mettre à jour 1 entrée ou d'ajouter 1 entrée dans une des deux tables.
Chaque table contient respectivement 1500 et 4500 entrées.
1) INSERT INTO tbl_commentaires VALUES (blababla , .... 2) UPDATE tbl_news SET vues = (vues + 1) WHERE ID = x
Il n'y a pas d'indexes créé , excepté l'index de clé primaire.
Erreur détaillée: "Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding."
Et une question pour finir : si je passe les timeout à 45 secondes, souvent cela fini par passer. Mais........pour quelle raison cela pourrait-il être si long ??!!?
Si quelqu'un a des idées à me proposer ou si un supplément d'informations est nécessaire, je suis preneur !!!
Antonio
Cactus Corp.
Bonjour Fred,
Votre proposition d'utiliser des procédures stockées me demanderait de changer toute la conception de l'application et de la coupler au sgbd, non ?
Ce qui m'ennuie un peu en faisant cela, c'est que jevais simplement contourner le problème sans l'avoir réellement identifié. Pourtant, je veux vraiment savoir ce qui ne joue pas.
Je crois qu'il me manque des connaissances théoriques sur ce point et je ne sais pas précisemment où les trouver. J'étais convaincu qu'un SELECT pouvait se faire totalement indépendamment des autres opérations en cours dans la base. Je pensais aussi qu'un UPDATE concernant une seule table, une seule ligne, ne pouvait pas (en tous cas je ne vois pas comment c'est possible) générer des verrous.
Même s'il y a 50 SELECT déclenchés en même temps.... en quoi pourrait- il y avoir un verrou ?
En tous cas je vous remercie pour votre réponse, elle me donne, à mon avis, la solution ultime à mon problème mais me posera aussi pas mal de problèmes plus tard =/
Antonio
Bonjour Fred,
Votre proposition d'utiliser des procédures stockées me demanderait
de changer toute la conception de l'application et de la coupler au sgbd,
non ?
Ce qui m'ennuie un peu en faisant cela, c'est que jevais simplement
contourner le problème sans l'avoir réellement identifié. Pourtant, je veux
vraiment savoir ce qui ne joue pas.
Je crois qu'il me manque des connaissances théoriques sur ce point et
je ne sais pas précisemment où les trouver. J'étais convaincu qu'un SELECT
pouvait se faire totalement indépendamment des autres opérations en
cours dans la base. Je pensais aussi qu'un UPDATE concernant une seule
table, une seule ligne, ne pouvait pas (en tous cas je ne vois pas comment
c'est possible) générer des verrous.
Même s'il y a 50 SELECT déclenchés en même temps.... en quoi pourrait-
il y avoir un verrou ?
En tous cas je vous remercie pour votre réponse, elle me donne, à mon
avis, la solution ultime à mon problème mais me posera aussi pas mal de
problèmes plus tard =/
Votre proposition d'utiliser des procédures stockées me demanderait de changer toute la conception de l'application et de la coupler au sgbd, non ?
Ce qui m'ennuie un peu en faisant cela, c'est que jevais simplement contourner le problème sans l'avoir réellement identifié. Pourtant, je veux vraiment savoir ce qui ne joue pas.
Je crois qu'il me manque des connaissances théoriques sur ce point et je ne sais pas précisemment où les trouver. J'étais convaincu qu'un SELECT pouvait se faire totalement indépendamment des autres opérations en cours dans la base. Je pensais aussi qu'un UPDATE concernant une seule table, une seule ligne, ne pouvait pas (en tous cas je ne vois pas comment c'est possible) générer des verrous.
Même s'il y a 50 SELECT déclenchés en même temps.... en quoi pourrait- il y avoir un verrou ?
En tous cas je vous remercie pour votre réponse, elle me donne, à mon avis, la solution ultime à mon problème mais me posera aussi pas mal de problèmes plus tard =/
Antonio
Cactus Corp.
Je suis aussi tombé sur le paramètre NOLOCK à placer dans la requête SELECT. Cela pourrait-il m'aider dans la mesure où il ne s'agit d'un système servant à afficher des articles et les commentaires associés ?
Je suis aussi tombé sur le paramètre NOLOCK à placer dans la
requête SELECT. Cela pourrait-il m'aider dans la mesure où il
ne s'agit d'un système servant à afficher des articles et les
commentaires associés ?
Je suis aussi tombé sur le paramètre NOLOCK à placer dans la requête SELECT. Cela pourrait-il m'aider dans la mesure où il ne s'agit d'un système servant à afficher des articles et les commentaires associés ?
Cactus Corp.
> Je suis aussi tombé sur le paramètre NOLOCK à placer dans la requête SELECT. Cela pourrait-il m'aider dans la mesure où il ne s'agit d'un système servant à afficher des articles et les commentaires associés ?
Je me réponds à moi-même hein , des fois que cela pourrait servir à d'autres!
J'ai modifié les deux requêtes prioritaires (les plus demandées) :
SELECT * FROM tbl_news ... SELECT * FROM tbl_commentaires...
en leur ajoutant le paramètre NOLOCK :
SELECT * FROM tbl_news WITH (NOLOCK) WHERE... SELECT * FROM tbl_commentaires WITH (NOLOCK) WHERE...
Ca tourne depuis une vingtaine de minutes à présent et je n'ai pas encore reçu de rapports d'erreurs! Je ne sais pas si c'est parce que tout le monde mange ou si cette modification porte ses fruits...
A suivre..
Antonio
> Je suis aussi tombé sur le paramètre NOLOCK à placer dans la
requête SELECT. Cela pourrait-il m'aider dans la mesure où il
ne s'agit d'un système servant à afficher des articles et les
commentaires associés ?
Je me réponds à moi-même hein , des fois que cela pourrait servir
à d'autres!
J'ai modifié les deux requêtes prioritaires (les plus demandées) :
SELECT * FROM tbl_news ...
SELECT * FROM tbl_commentaires...
en leur ajoutant le paramètre NOLOCK :
SELECT * FROM tbl_news WITH (NOLOCK) WHERE...
SELECT * FROM tbl_commentaires WITH (NOLOCK) WHERE...
Ca tourne depuis une vingtaine de minutes à présent et je n'ai pas encore
reçu de rapports d'erreurs! Je ne sais pas si c'est parce que tout le monde
mange ou si cette modification porte ses fruits...
> Je suis aussi tombé sur le paramètre NOLOCK à placer dans la requête SELECT. Cela pourrait-il m'aider dans la mesure où il ne s'agit d'un système servant à afficher des articles et les commentaires associés ?
Je me réponds à moi-même hein , des fois que cela pourrait servir à d'autres!
J'ai modifié les deux requêtes prioritaires (les plus demandées) :
SELECT * FROM tbl_news ... SELECT * FROM tbl_commentaires...
en leur ajoutant le paramètre NOLOCK :
SELECT * FROM tbl_news WITH (NOLOCK) WHERE... SELECT * FROM tbl_commentaires WITH (NOLOCK) WHERE...
Ca tourne depuis une vingtaine de minutes à présent et je n'ai pas encore reçu de rapports d'erreurs! Je ne sais pas si c'est parce que tout le monde mange ou si cette modification porte ses fruits...
A suivre..
Antonio
Fred BROUARD
Cactus Corp. a écrit:
Bonjour Fred,
Votre proposition d'utiliser des procédures stockées me demanderait de changer toute la conception de l'application et de la coupler au sgbd, non ?
Oui, mais c'est vital pour une application susceptible d'être attaquée par de nombreux utilisateurs (clients).
Ce qui m'ennuie un peu en faisant cela, c'est que jevais simplement contourner le problème sans l'avoir réellement identifié.
Non, le problème est claire vous avez de la contention, c'est juste de savoir à quel endroit elle se trouve qui vous gène.
> Pourtant, je veux
vraiment savoir ce qui ne joue pas.
Dans ce cas vous pouvez monitorer SQL Server à l'aide du profiler SQL afin de déterminer les durées excessives des traitements.
Je crois qu'il me manque des connaissances théoriques sur ce point et je ne sais pas précisemment où les trouver. J'étais convaincu qu'un SELECT pouvait se faire totalement indépendamment des autres opérations en cours dans la base.
Absoluement pas : une lecture nécessite la consistence des données. Si vous êtes en train d'augementer de 10% le prix de tous vos produits il serait catastrophique d'en extraire une partie avec la majoration et l'autre avec les anciens prix sans savoir lequels ont été touchés par l'UPDATE... C'est pourquoi il faut lire les données avant ou après mais pas pendant. D'ou des mécanismes de verouillage pour gérer la concurrence.
Je pensais aussi qu'un UPDATE concernant une seule table, une seule ligne, ne pouvait pas (en tous cas je ne vois pas comment c'est possible) générer des verrous.
Même s'il y a 50 SELECT déclenchés en même temps.... en quoi pourrait- il y avoir un verrou ?
En particulier lorsque vous lisez un verrou de type lecture partagée est posée. pendant ce verrous certaines opérations sont infaisables : - modifier les données, - ajouter, supprimer ... une colonne à la table - supprimer la table ...
En tous cas je vous remercie pour votre réponse, elle me donne, à mon avis, la solution ultime à mon problème mais me posera aussi pas mal de problèmes plus tard =/
Antonio
ATTENTION : les verrous sont posés automatiquement pas le serveur dans la cadre des transaction. par principe, un ordre SQL comme SELECT ou UPDATE est une transaction.
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 *************************
Cactus Corp. a écrit:
Bonjour Fred,
Votre proposition d'utiliser des procédures stockées me demanderait
de changer toute la conception de l'application et de la coupler au sgbd,
non ?
Oui, mais c'est vital pour une application susceptible d'être attaquée par de
nombreux utilisateurs (clients).
Ce qui m'ennuie un peu en faisant cela, c'est que jevais simplement
contourner le problème sans l'avoir réellement identifié.
Non, le problème est claire vous avez de la contention, c'est juste de savoir à
quel endroit elle se trouve qui vous gène.
> Pourtant, je veux
vraiment savoir ce qui ne joue pas.
Dans ce cas vous pouvez monitorer SQL Server à l'aide du profiler SQL afin de
déterminer les durées excessives des traitements.
Je crois qu'il me manque des connaissances théoriques sur ce point et
je ne sais pas précisemment où les trouver. J'étais convaincu qu'un SELECT
pouvait se faire totalement indépendamment des autres opérations en
cours dans la base.
Absoluement pas : une lecture nécessite la consistence des données. Si vous êtes
en train d'augementer de 10% le prix de tous vos produits il serait
catastrophique d'en extraire une partie avec la majoration et l'autre avec les
anciens prix sans savoir lequels ont été touchés par l'UPDATE...
C'est pourquoi il faut lire les données avant ou après mais pas pendant. D'ou
des mécanismes de verouillage pour gérer la concurrence.
Je pensais aussi qu'un UPDATE concernant une seule
table, une seule ligne, ne pouvait pas (en tous cas je ne vois pas comment
c'est possible) générer des verrous.
Même s'il y a 50 SELECT déclenchés en même temps.... en quoi pourrait-
il y avoir un verrou ?
En particulier lorsque vous lisez un verrou de type lecture partagée est posée.
pendant ce verrous certaines opérations sont infaisables :
- modifier les données,
- ajouter, supprimer ... une colonne à la table
- supprimer la table
...
En tous cas je vous remercie pour votre réponse, elle me donne, à mon
avis, la solution ultime à mon problème mais me posera aussi pas mal de
problèmes plus tard =/
Antonio
ATTENTION : les verrous sont posés automatiquement pas le serveur dans la cadre
des transaction. par principe, un ordre SQL comme SELECT ou UPDATE est une
transaction.
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 *************************
Votre proposition d'utiliser des procédures stockées me demanderait de changer toute la conception de l'application et de la coupler au sgbd, non ?
Oui, mais c'est vital pour une application susceptible d'être attaquée par de nombreux utilisateurs (clients).
Ce qui m'ennuie un peu en faisant cela, c'est que jevais simplement contourner le problème sans l'avoir réellement identifié.
Non, le problème est claire vous avez de la contention, c'est juste de savoir à quel endroit elle se trouve qui vous gène.
> Pourtant, je veux
vraiment savoir ce qui ne joue pas.
Dans ce cas vous pouvez monitorer SQL Server à l'aide du profiler SQL afin de déterminer les durées excessives des traitements.
Je crois qu'il me manque des connaissances théoriques sur ce point et je ne sais pas précisemment où les trouver. J'étais convaincu qu'un SELECT pouvait se faire totalement indépendamment des autres opérations en cours dans la base.
Absoluement pas : une lecture nécessite la consistence des données. Si vous êtes en train d'augementer de 10% le prix de tous vos produits il serait catastrophique d'en extraire une partie avec la majoration et l'autre avec les anciens prix sans savoir lequels ont été touchés par l'UPDATE... C'est pourquoi il faut lire les données avant ou après mais pas pendant. D'ou des mécanismes de verouillage pour gérer la concurrence.
Je pensais aussi qu'un UPDATE concernant une seule table, une seule ligne, ne pouvait pas (en tous cas je ne vois pas comment c'est possible) générer des verrous.
Même s'il y a 50 SELECT déclenchés en même temps.... en quoi pourrait- il y avoir un verrou ?
En particulier lorsque vous lisez un verrou de type lecture partagée est posée. pendant ce verrous certaines opérations sont infaisables : - modifier les données, - ajouter, supprimer ... une colonne à la table - supprimer la table ...
En tous cas je vous remercie pour votre réponse, elle me donne, à mon avis, la solution ultime à mon problème mais me posera aussi pas mal de problèmes plus tard =/
Antonio
ATTENTION : les verrous sont posés automatiquement pas le serveur dans la cadre des transaction. par principe, un ordre SQL comme SELECT ou UPDATE est une transaction.
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 *************************
Fred BROUARD
bonjour,
Si vous voulez pourrir vos données, c'est en effet un excellent moyen que d'utiliser la lecture sale (ou lecture impropre ou dirty read) en imposant que le serveur s'affranchisse de tout verrou.
Avant toute chose, prenez du recul, réfléchissez, documentez-vous, formez-vous afin de ne pas prendre un remède qui s'avérera pire que le mal.
Mon site SQLpro, comme mes bouquins, peuvent vous y aider. http://sqlpro.developpez.com
Si vous êtes dans le cadre d'une entreprise, une bonne formation sur ces concepts est sans doute nécessaire et peut être prise en charge par les fonds mutualisés (FAFIEC, Agefoss....). Je ne sais pas si c'est valable pour la suisse .... !
Cactus Corp. a écrit:
Je suis aussi tombé sur le paramètre NOLOCK à placer dans la requête SELECT. Cela pourrait-il m'aider dans la mesure où il ne s'agit d'un système servant à afficher des articles et les commentaires associés ?
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 *************************
bonjour,
Si vous voulez pourrir vos données, c'est en effet un excellent moyen que
d'utiliser la lecture sale (ou lecture impropre ou dirty read) en imposant que
le serveur s'affranchisse de tout verrou.
Avant toute chose, prenez du recul, réfléchissez, documentez-vous, formez-vous
afin de ne pas prendre un remède qui s'avérera pire que le mal.
Mon site SQLpro, comme mes bouquins, peuvent vous y aider.
http://sqlpro.developpez.com
Si vous êtes dans le cadre d'une entreprise, une bonne formation sur ces
concepts est sans doute nécessaire et peut être prise en charge par les fonds
mutualisés (FAFIEC, Agefoss....). Je ne sais pas si c'est valable pour la suisse
.... !
Cactus Corp. a écrit:
Je suis aussi tombé sur le paramètre NOLOCK à placer dans la
requête SELECT. Cela pourrait-il m'aider dans la mesure où il
ne s'agit d'un système servant à afficher des articles et les
commentaires associés ?
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 *************************
Si vous voulez pourrir vos données, c'est en effet un excellent moyen que d'utiliser la lecture sale (ou lecture impropre ou dirty read) en imposant que le serveur s'affranchisse de tout verrou.
Avant toute chose, prenez du recul, réfléchissez, documentez-vous, formez-vous afin de ne pas prendre un remède qui s'avérera pire que le mal.
Mon site SQLpro, comme mes bouquins, peuvent vous y aider. http://sqlpro.developpez.com
Si vous êtes dans le cadre d'une entreprise, une bonne formation sur ces concepts est sans doute nécessaire et peut être prise en charge par les fonds mutualisés (FAFIEC, Agefoss....). Je ne sais pas si c'est valable pour la suisse .... !
Cactus Corp. a écrit:
Je suis aussi tombé sur le paramètre NOLOCK à placer dans la requête SELECT. Cela pourrait-il m'aider dans la mesure où il ne s'agit d'un système servant à afficher des articles et les commentaires associés ?
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 *************************
Fred BROUARD
Cactus Corp. a écrit:
Je suis aussi tombé sur le paramètre NOLOCK à placer dans la requête SELECT. Cela pourrait-il m'aider dans la mesure où il ne s'agit d'un système servant à afficher des articles et les commentaires associés ?
Je me réponds à moi-même hein , des fois que cela pourrait servir à d'autres!
J'ai modifié les deux requêtes prioritaires (les plus demandées) :
SELECT * FROM tbl_news ... SELECT * FROM tbl_commentaires...
en leur ajoutant le paramètre NOLOCK :
SELECT * FROM tbl_news WITH (NOLOCK) WHERE... SELECT * FROM tbl_commentaires WITH (NOLOCK) WHERE...
Ca tourne depuis une vingtaine de minutes à présent et je n'ai pas encore reçu de rapports d'erreurs! Je ne sais pas si c'est parce que tout le monde mange ou si cette modification porte ses fruits...
Vous n'en recevrez, espérons-le, jamais, même si vos données sont corrompues. C'est le but du NOLOCK !
A +
A suivre..
Antonio
-- 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 *************************
Cactus Corp. a écrit:
Je suis aussi tombé sur le paramètre NOLOCK à placer dans la
requête SELECT. Cela pourrait-il m'aider dans la mesure où il
ne s'agit d'un système servant à afficher des articles et les
commentaires associés ?
Je me réponds à moi-même hein , des fois que cela pourrait servir
à d'autres!
J'ai modifié les deux requêtes prioritaires (les plus demandées) :
SELECT * FROM tbl_news ...
SELECT * FROM tbl_commentaires...
en leur ajoutant le paramètre NOLOCK :
SELECT * FROM tbl_news WITH (NOLOCK) WHERE...
SELECT * FROM tbl_commentaires WITH (NOLOCK) WHERE...
Ca tourne depuis une vingtaine de minutes à présent et je n'ai pas encore
reçu de rapports d'erreurs! Je ne sais pas si c'est parce que tout le monde
mange ou si cette modification porte ses fruits...
Vous n'en recevrez, espérons-le, jamais, même si vos données sont corrompues.
C'est le but du NOLOCK !
A +
A suivre..
Antonio
--
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 *************************
Je suis aussi tombé sur le paramètre NOLOCK à placer dans la requête SELECT. Cela pourrait-il m'aider dans la mesure où il ne s'agit d'un système servant à afficher des articles et les commentaires associés ?
Je me réponds à moi-même hein , des fois que cela pourrait servir à d'autres!
J'ai modifié les deux requêtes prioritaires (les plus demandées) :
SELECT * FROM tbl_news ... SELECT * FROM tbl_commentaires...
en leur ajoutant le paramètre NOLOCK :
SELECT * FROM tbl_news WITH (NOLOCK) WHERE... SELECT * FROM tbl_commentaires WITH (NOLOCK) WHERE...
Ca tourne depuis une vingtaine de minutes à présent et je n'ai pas encore reçu de rapports d'erreurs! Je ne sais pas si c'est parce que tout le monde mange ou si cette modification porte ses fruits...
Vous n'en recevrez, espérons-le, jamais, même si vos données sont corrompues. C'est le but du NOLOCK !
A +
A suivre..
Antonio
-- 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 *************************
> Si vous voulez pourrir vos données, c'est en effet un excellent moyen que d'utiliser la lecture sale (ou lecture impropre ou dirty read) en imposant que le serveur s'affranchisse de tout verrou.
Si vous vouliez me faire peur ou avoir mauvaise conscience c'est réussi ; )
Avant toute chose, prenez du recul, réfléchissez, documentez-vous, formez-vous afin de ne pas prendre un remède qui s'avérera pire que le mal.
Oui, j'ai vu que je devais aller plus loin. Jusqu'à présent je n'ai encore jamais rencontré ces problèmes et je me demande encore comment dans la mesure où je ne fais rien de 'nouveau'. Rien qu'entre hier et aujourd'hui j'en ai appris des trucs que j'étais censé savoir ; )
Mon site SQLpro, comme mes bouquins, peuvent vous y aider. http://sqlpro.developpez.com
Oui, j'ai presque lu tous vos articles, il ne faut pas se voiler la face, presque toutes les recherches pointent sur votre site depuis des années pour tout ce qui touche à SQL en français, il faut le vouloir pour rater vos pages!
Par contre, je n'ai pas encore craqué pour les livres. Peut être simplement parce que je n'ai jamais eu le besoin.
Je vais y refaire un tour, depuis le temps...
Si vous êtes dans le cadre d'une entreprise, une bonne formation sur ces concepts est sans doute nécessaire et peut être prise en charge par les fonds mutualisés (FAFIEC, Agefoss....). Je ne sais pas si c'est valable pour la suisse .... !
100% auto-formation , et oui, je suis en suisse et dans une PME du genre microPME ; )
Encore merci!
> Si vous voulez pourrir vos données, c'est en effet un excellent moyen que d'utiliser la lecture sale (ou lecture impropre ou dirty
read) en imposant que le serveur s'affranchisse de tout verrou.
Si vous vouliez me faire peur ou avoir mauvaise conscience c'est réussi ; )
Avant toute chose, prenez du recul, réfléchissez, documentez-vous, formez-vous afin de ne pas prendre un remède qui s'avérera pire
que le mal.
Oui, j'ai vu que je devais aller plus loin. Jusqu'à présent je n'ai encore jamais
rencontré ces problèmes et je me demande encore comment dans la mesure
où je ne fais rien de 'nouveau'. Rien qu'entre hier et aujourd'hui j'en ai appris
des trucs que j'étais censé savoir ; )
Mon site SQLpro, comme mes bouquins, peuvent vous y aider.
http://sqlpro.developpez.com
Oui, j'ai presque lu tous vos articles, il ne faut pas se voiler la face, presque
toutes les recherches pointent sur votre site depuis des années pour tout ce qui
touche à SQL en français, il faut le vouloir pour rater vos pages!
Par contre, je n'ai pas encore craqué pour les livres. Peut être simplement parce
que je n'ai jamais eu le besoin.
Je vais y refaire un tour, depuis le temps...
Si vous êtes dans le cadre d'une entreprise, une bonne formation sur ces concepts est sans doute nécessaire et peut être prise en
charge par les fonds mutualisés (FAFIEC, Agefoss....). Je ne sais pas si c'est valable pour la suisse .... !
100% auto-formation , et oui, je suis en suisse et dans une PME du genre microPME
; )
> Si vous voulez pourrir vos données, c'est en effet un excellent moyen que d'utiliser la lecture sale (ou lecture impropre ou dirty read) en imposant que le serveur s'affranchisse de tout verrou.
Si vous vouliez me faire peur ou avoir mauvaise conscience c'est réussi ; )
Avant toute chose, prenez du recul, réfléchissez, documentez-vous, formez-vous afin de ne pas prendre un remède qui s'avérera pire que le mal.
Oui, j'ai vu que je devais aller plus loin. Jusqu'à présent je n'ai encore jamais rencontré ces problèmes et je me demande encore comment dans la mesure où je ne fais rien de 'nouveau'. Rien qu'entre hier et aujourd'hui j'en ai appris des trucs que j'étais censé savoir ; )
Mon site SQLpro, comme mes bouquins, peuvent vous y aider. http://sqlpro.developpez.com
Oui, j'ai presque lu tous vos articles, il ne faut pas se voiler la face, presque toutes les recherches pointent sur votre site depuis des années pour tout ce qui touche à SQL en français, il faut le vouloir pour rater vos pages!
Par contre, je n'ai pas encore craqué pour les livres. Peut être simplement parce que je n'ai jamais eu le besoin.
Je vais y refaire un tour, depuis le temps...
Si vous êtes dans le cadre d'une entreprise, une bonne formation sur ces concepts est sans doute nécessaire et peut être prise en charge par les fonds mutualisés (FAFIEC, Agefoss....). Je ne sais pas si c'est valable pour la suisse .... !
100% auto-formation , et oui, je suis en suisse et dans une PME du genre microPME ; )
Encore merci!
Ambassadeur Kosh
une idée simple : augmenter le timeout.
si vous utilisez la clef primaire pour identifier vos lignes, normallement, ça doit aller super vite. vous etes certains que vous ne nous faites pas le coup du "je rempli le dataset avec les 1000000 de lignes, puis je trouve la ligne, je la modifie, et j'update sur le dataAdapter" ?
une idée simple : augmenter le timeout.
si vous utilisez la clef primaire pour identifier vos lignes, normallement,
ça doit aller super vite.
vous etes certains que vous ne nous faites pas le coup du "je rempli le
dataset avec les 1000000 de lignes, puis je trouve la ligne, je la modifie,
et j'update sur le dataAdapter" ?
si vous utilisez la clef primaire pour identifier vos lignes, normallement, ça doit aller super vite. vous etes certains que vous ne nous faites pas le coup du "je rempli le dataset avec les 1000000 de lignes, puis je trouve la ligne, je la modifie, et j'update sur le dataAdapter" ?
