[SQL 2000] Time out expired

[Phenomenon]

Het volgende:

Ik heb een database waar verschillende stored procedures achter elkaar worden uitgevoerd. Op de client krijgt ik op een gegeven moment een melding 'Time out expired'. Dit krijg ik op alle clients als ik de batch doe.

Nu heb ik bijna een zelfde database en als ik het daarop doe, dan verloopt alles goed. Wanneer ik de stored procedure uitvoer in de Enterprise Manager dan verloopt de SP ook vlekkeloos.

Ik heb een tracert gestart om te kijken waar de fout optreedt en bij de fout (zonder foutmelding) geeft hij een CPU van 30453, Reads: 24411978, duration: 34066

Daar loopt het dus ergens fout op, maar ik kan nergens vinden waarom hij fout gaat. Zodra ik het handmatig doe, dan gaat alles weer goed. Met dezelfde parameters en alles. Voorheen ging ook altijd alles goed en er zijn geen veranderingen in de database gemaakt.

Ik vermoedde dat het probleem misschien in een corrupte tabel of iets dergelijks lag en heb een DBCC CHECK uitgevoerd, maar deze geef geen foutmeldingen terug.

Hoe kom ik er nu achter wat hier de fout veroorzaakt?

[Niemand_Anders]

Waarschijnlijk moet je de AdoDB.Connection.CommandTimeout (ASP) of System.Data.SqlClient.SqlCommand.CommandTimeout (.NET) property instellen. Standard hebben deze properties een timeout van 30 seconden.

[Phenomenon]

Jah dat klopt, maar de SP hoort gewoon niet zo lang te duren. Daar komt bij dat wanneer ik de SQL handmatig doe, hij dan ongeveer dezelfde tijd bezig zou moeten zijn met de query.

[Niemand_Anders]

Ik zou gewoon toch eerst eens de command timeout lekker flink verhogen (3600) en kijken of alles dan wel goed gaat.

Draait de website of het programma op dezelfde machine als waarop de enterprise manager draait? Kan het zijn dat de netwerk verbindingen niet helemaal stabiel zijn (peer reset) o.i.d.? Wordt er op het netwerk gebruik gemaakt van NAT waarbij sql servers zijn response niet kan terug geven?
Je zou ook in de sql server logs kunnen kijken of daar wat staat.

Zou je misschien ook kunnen aangeven in welke taal (met versie) je bezig bent?

[gorgi_19]

24 miljoen reads is best veel..... Heb je al eens gekeken naar het Execution Plan? Werk je verder nog ergens met locks oid?

[ Voor 20% gewijzigd door gorgi_19 op 17-07-2007 13:21 ]

[Phenomenon]

Het gaat om een applicatie gemaakt in Visual Basic 6.0.

De versie die bij de klant draait is gecompilleerd en kan ik dus zo niet 1 2 3 veranderen. Ik heb hier een VPN verbinding opgezet en krijg precies hetzelfde probleem als hun.

De applicatie draait gewoon op een werkstation en SQL 2000 draait op een aparte server. In de event logs van de server is niets bijzonders te vinden.

De netwerkverbindingen hebben geen problemen en er is ook geen packet loss of iets dergelijks. Het is echt 1 specifieke Stored Procedure die de hele tijd de mist in gaat.

De Stored Procedure wordt tig keer aangeroepen in een batch met verschillende parameters en de ene keer gaat het gewoon vlot, maar dan opeens krijg je een Time Out waar de profiler hoge CPU waarden etc op geeft.

Dezelfde Stored Procedure met dezelfde parameters in de Enterprise Manager (of dat nu lokaal is, of via een werkstation) gaat wel snel.

De manier waarop deze fout voorkomt klopt gewoon niet voor mij en zou niet mogen, maar jah wat allemaal niet mag.....

gorgi_19 schreef op dinsdag 17 juli 2007 @ 13:21:
24 miljoen reads is best veel..... Heb je al eens gekeken naar het Execution Plan? Werk je verder nog ergens met locks oid?

Nee in de applicatie wordt niet met locks gewerkt. Het rare is ook, dat is vorige week de live database geconverteerd heb naar een nieuwe versie (deze draait nog niet bij hun) en wanneer ik daar de batch op los laat alles goed gaat. Dit is een week ouderere data.

[ Voor 19% gewijzigd door Phenomenon op 17-07-2007 13:35 ]

[m.eddy]

Je geeft aan dat er nogal wat parameters worden gebruikt in de batch.
Als dit de flow van de batch beinvloed zou dat het probleem kunnen zijn. In dat geval wil je namelijk helemaal niet van het cache en statistics gedrag zien van SQL Server. Juist omdat de flow iedere keer anders is door de parameters.

Het klopt dat het vanuit de Enterprise manager dan wel goed gaat. In dat geval maak je geen gebruik van caching etc.

Geef aan het begin van de stored procedure een recompile om het cachen uit te schakelen. (WITH RECOMPILE)

[Phenomenon]

Nou dat lijkt inderdaad het probleem te zijn. Hij loopt nu gewoon door

Je bent geweldig!

[m.eddy]

Mooi.

Volgens mij wist ik dit door mijn abo op de nieuwsbrief van sqlservercentral.com. Komen elke dag paar items voorbij welke soms heel handig zijn.

Succes verder