update et insert : timeout expired

Cactus Corp. a écrit:

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

Non, c'est un constat, c'est comme cela que ça marche et cela vous arrivera tôt
ou tard. Mais vous aurez beaucoup de mal à vous en aperçevoir lorsque cela se
produira. J'usqu'au jour ou un audit comptable montrera par exemple des
anomalies dans les écritures...

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

C'est là que la bât blesse : les SGBDR sont des outils très complexes et la
formation scolaire est de plus en plus lamentable. La plupart des cours en
France sont encore basé sur du Oracle avec une syntaxe datant d'avant 1992 !!!

C'est là aussi que je fais du bon beurre à replatrer des applications écrites
sans connaissance et auquel on demande ensuite de la perf, ce qui bien
évidemment est impossible à offrir sans une optimistaion préalable, passant
obligatoirement par une modèlisation parfaite.

Seriez vous Antonio Fontes ???

A +

Encore merci!

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

> Seriez vous Antonio Fontes ???
A +

Oui, celui que vous venez également de croiser sur un autre site il y a
quelques minutes ; )

Antonio

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

Bonjour,

Non non c'est certain. C'est une table avec 4800 entrées, 8 colonnes,
et je lance un INSERT dessus.

Dans l'autre cas, c'est une table avec 1500 entrées, 9 colonnes et je lance
un UPDATE dessus du format suivant:

UPDATE table SET vues = (vues + 1) WHERE ID = id

Je ne touche pas aux dataadapter dans mes développements généralement,
donc le problème ne devrait pas venir de là.

Bon et bien contrairement aux attentes, je continue à recevoir des
alertes, mais beaucoup moins cependant.

Suite aux récents échanges avec F.B., il serait sage de retirer mes
instructions 'WITH (NOLOCK)' dans les requêtes , surtout dans la
mesure où ce n'est pas ce qui a résolu le problème.


J'ai suivi une autre piste..

J'ai lancé la requête suivante:

SELECT spid, waittime, lastwaittype, waitresource
FROM master..sysprocesses
WHERE waittime > 2000
AND spid > 50

et j'obtiens au moment où le problème se présente, le résultat suivant:

51 123672 NETWORKIO
53 128891 NETWORKIO
54 135704 NETWORKIO
55 135750 NETWORKIO
57 137735 NETWORKIO
58 137547 NETWORKIO
59 115954 NETWORKIO
60 114125 NETWORKIO
61 99172 NETWORKIO
62 88797 NETWORKIO
64 76907 NETWORKIO
65 73735 NETWORKIO
66 36532 NETWORKIO

et le bonus, la dernière ligne:

67 13422 LCK_M_IX TAB: 7:722101613 []


Selon la documentationt rouvée à cet endroit :
http://sqldev.net/misc/waittypes.htm
NETWORKIO veut dire que le serveur attent une réponse ou un
complément d'informations du réseau.
Bizarre.


Mais j'ai donc immédiatement lancé un sp_who sur la base pour voir
les détails de ce spid 67:

66 0 runnable mylogin MISS 0 mydb SELECT
67 0 sleeping mylogin MISS 66 mydb UPDATE

Via une requête dans sysobjects, je vois effectivement que l'id 722101613
correspond à la table de commentaires.

Est-ce que je dois comprendre que le processus 'bloquant' est un select
dans la table de commentaires ou ma déduction est-elle trop 'naïve' ?

Antonio

> Je ne touche pas aux dataadapter dans mes développements généralement,
donc le problème ne devrait pas venir de là.

ok. c'est donc une SqlCommand tout ce qu'il y'a de plus simple qui fait le
boulot ?

Cactus Corp. a écrit:

Bon et bien contrairement aux attentes, je continue à recevoir des
alertes, mais beaucoup moins cependant.

Suite aux récents échanges avec F.B., il serait sage de retirer mes
instructions 'WITH (NOLOCK)' dans les requêtes , surtout dans la
mesure où ce n'est pas ce qui a résolu le problème.


J'ai suivi une autre piste..

J'ai lancé la requête suivante:

SELECT spid, waittime, lastwaittype, waitresource
FROM master..sysprocesses
WHERE waittime > 2000
AND spid > 50

et j'obtiens au moment où le problème se présente, le résultat suivant:

51 123672 NETWORKIO
53 128891 NETWORKIO
54 135704 NETWORKIO
55 135750 NETWORKIO
57 137735 NETWORKIO
58 137547 NETWORKIO
59 115954 NETWORKIO
60 114125 NETWORKIO
61 99172 NETWORKIO
62 88797 NETWORKIO
64 76907 NETWORKIO
65 73735 NETWORKIO
66 36532 NETWORKIO

et le bonus, la dernière ligne:

67 13422 LCK_M_IX TAB: 7:722101613 []


Selon la documentationt rouvée à cet endroit :
http://sqldev.net/misc/waittypes.htm
NETWORKIO veut dire que le serveur attent une réponse ou un
complément d'informations du réseau.
Bizarre.


Mais j'ai donc immédiatement lancé un sp_who sur la base pour voir
les détails de ce spid 67:

66 0 runnable mylogin MISS 0 mydb SELECT
67 0 sleeping mylogin MISS 66 mydb UPDATE

Via une requête dans sysobjects, je vois effectivement que l'id 722101613
correspond à la table de commentaires.

Est-ce que je dois comprendre que le processus 'bloquant' est un select
dans la table de commentaires ou ma déduction est-elle trop 'naïve' ?

elle est naïve. Seule SQL Profiler permetrait de tracer ce qui se passe.

je pense que votre traitement efectue d'abord un select et ouvre donc un curseur....

le nombre de processus que vous avez n'est pas important.

Quelle est votre config serveur ?
OS, SQL Server, RAM, disque dans le détail...

A +

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

> elle est naïve. Seule SQL Profiler permetrait de tracer ce qui se passe.

; )

je pense que votre traitement efectue d'abord un select et ouvre donc un curseur....
le nombre de processus que vous avez n'est pas important.

ok.

Quelle est votre config serveur ?
OS, SQL Server, RAM, disque dans le détail...

os: Windows 2000 serveur US
sql: MSDE
cpu: Athlon 2.4g
ram: 1go de ram, corsair ddr400 (2x512)
disques: 2x IBM - 80go - 8m cache - en configuration RAID 1 hardware (vt8237 via)

(pour info, le RAID n'est actif que depuis deux jours, les erreurs ne sont pas
devenues plus fréquentes)

antonio
(petite pause pour moi , il faut que j'aille tout de même me nourrir, il n'y aura
sûrement pas de réponse de ma part avant 19 heures environ)

p.s. : encore un grand merci à vous deux de prendre le temps de répondre à toutes
mes questions!

Cactus Corp. a écrit:

Quelle est votre config serveur ?
OS, SQL Server, RAM, disque dans le détail...

os: Windows 2000 serveur US
sql: MSDE
cpu: Athlon 2.4g
ram: 1go de ram, corsair ddr400 (2x512)

Tout dépend ensuite si :
1) d'autres applications sont installées : un serveur SGBDR doit être installé
sur une machine dédiée. En principe aucune autre appli ne doit y êre installée.
2) le volume de la fenêtre de données est en adéquation avec la RAM

disques: 2x IBM - 80go - 8m cache - en configuration RAID 1 hardware (vt8237 via)

Cache en écriture ???
Désactivez le de toute façon, ne serait-ce que pour voir.

(pour info, le RAID n'est actif que depuis deux jours, les erreurs ne sont pas
devenues plus fréquentes)

antonio
(petite pause pour moi , il faut que j'aille tout de même me nourrir, il n'y aura
sûrement pas de réponse de ma part avant 19 heures environ)

et moi je risque de ne plus pouvoir vous aider. Je doit partir à paris pour la
semaine ou je serais indisponible...

p.s. : encore un grand merci à vous deux de prendre le temps de répondre à toutes
mes questions!

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

Bon et bien j'ai trouvé la solution au problème. Réponse un peu philosophique
ci-dessous, à ne conseiller que si vous ête bien reposé ; )


J'ai un peu relu toutes nos discussions et il en est ressorti un fait marquant.
Soit toute ma conception au niveau des données était douteuse (leur organisation
et la manière de les modifier ou les consulter), soit nos discussions n'allaient
pas dans le bon sens.

Par orgueil , je suis parti du principe que nous n'étions pas sur la bonne voie
pour résoudre ce problème, mon modèle de données et ma manière de communiquer
avec sont parfaits. Affirmation fortement présomptueuse, certes, mais qui m'a été
très utile pour avancer.

Il y a quatre visions pour résoudre le genre de problème que je viens d'avoir:
- la vision admin système
- la vision admin réseau
- la vision dba
- la vision développeur d'applications

Chaque vision apporte un avantage et son inconvénient direct:
une expertise technique ou stratégique d'un côté, une perte de recul de l'autre.

Jusqu'ici, nos échanges ont plutôt tourné autour la vision dba. Or, si j'assume
le principe que mon modèle est parfaitement conçu, la vision dba ne m'est plus
la plus appropriée pour résoudre mon problème.

Il me restait trois visions: système, réseaux et développement.

Maintenant, je me suis imaginé en discussion avec une personne ayant mon
problème. Je pars du principe que je ne connais quoi que ce soit de près ou de
loin à l'optimation au niveau du modèle de données ou de son exploitation au
niveau sql.

Etant justement développeur, je me suis donc demandé :

- dis-voir, j'ai des timeouts serveur sur sql2000 depuis quelques temps, ca n'arrête
pas. j'ai tracé via le profiler rien trouvé, j'en suis toujours au même points: un processus
bloquant une table à cause d'un simple select!!!

et je me suis demandé ce que j'aurais répondu si l'on m'avait posé cette question:

- ben, t'as peut être pas refermé ton connecteur à la fin d'un traitement!
- bah si, je les referme tous. toujours.
- comment tu le sais ?
- j'ai un script qui me scanne mon code pour pas oublier ce genre d'erreur de débutant!
- il est peut être buggé ton script
- ....ah.....

Bon . Après cette courte réflexion, je décide donc de reparcourir tous les points
sur lesquels j'effectue un simple GetReader.J'ai donc lancé une recherche dans tous
les fichies sur 'IDatareader dr = DBUtils.GetReader()'

18 fichers trouvé(s)


Mmmh ok. Mainenant , recherche sur dr.Close(); :

17 fichiers trouvé(s)

-> ok, en voilà une mauvaise nouvelle. sur les 18 fichiers utilisant IDataReader,
1 de ces fichiers n'appelle pas la méthode Close();

Après en avoir ouvert quelques-uns de ces fichiers, j'ai fini par tomber dessus :

--------------------------------------
while(dr.Read())
{
...
coll.Add(...);
}
return coll;
--------------------------------------

Et oui, il manque le dr.Close() à la fin de cette requête!


Un grand moment de sollitude.....


Je pense que vous devinez sans doute comment le problème a t'il
été résolu: il s'agissait simplement d'un IDatareader (recordset nouvelle
génération) non fermé après la fin de son utilisation. Bien sûr, le script
que j'ai fait avait un bug et me l'annonçait comme fermé.

Bref, l'erreur est grave, impardonnable dans ce genre d'environnements
mais simple et basique aussi, et personne ne semble y avoir pensé.

Moralité : si votre application a toujours très bien marché pendant un
bon moment et qu'elle se met soudainement à vous faire des 'server
timeout' ou 'timeout expired' à tous bouts de champs, commencez par
vérifier que toutes les opérations effectuent bien une phase de relâchement
des ressources avant d'aller embêter les gourous sql ; )

Dans tous les cas, merci à FB et AK pour toutes leurs réponses. J'ai
au final appris énormement de choses durant ces dernières 24 heures,
qui seront, je n'en doute pas, utiles en temps voulu!

antonio

ok. moi ma certitude, c'etait qu'il y avait un pb du côté client. vu les
tables et le nb de données, ça peut difficilement etre sql qui est la cause.

je te propose donc quelques recommandations qui concernent ado.net :

qui dit manipulation autours d'une connection dit toujours ceci

try
{
connection.Open() ;
command.Execute() ;
...
}
catch ...
{
...
}
finally
{
connection.Close() ;
}

la connection n'est pas une connection en ado dotnet. donc toujours l'ouvrir
et la fermer tout de suite apres. surtout pas de connection static ouverte
en permanence...
ce qui doit être commun, c'est la ConnectionString, pas la connection. donc
tu peux faire autant d'instances de SqlConnection que tu veux, c'est fait
pour ça (il y'a un pool)

les reader, le close doit etre systématique, et donc utiliser le meme
Pattern...

le mot clef using va te rendre bien des services (pas using namespace,
using(type variable=initialisation()) {...} )

et sans aller plus loin, avec un DataAdapter et un Dataset, ce probleme
n'aurait jamais existé.

ce qui m'amene à t'inviter à passer sur microsoft.public.fr.dotnet (server
msnews) nous rendre visite.