[mysql] update loopt vast

[_Thanatos_]

Hallo daar,
Ik heb een tabel die dient als weblog voor m'n IIS-webserver. De IIS'ers onder ons zullen dan wel weten hoe de tabel eruit ziet, voor de rest:

code:

ClientHost varchar(255)
Username varchar(255)
LogTime datetime
Service varchar(255)
Machine varchar(255)
ServerIP varchar(50)
ProcessingTime int
BytesRecvd int
BytesSent int
ServiceStatus int
Win32Status int
Operation varchar(255)
Target varchar(255)
Parameters varchar(255)

Weten we dat ook weer. Het probleem is dus dat een update in de tabel hartstikke vast loopt. En ik zou best willen weten waarom en wat eraan te doen valt

De query:

code:

UPDATE weblog SET LogTime=20020326000000 WHERE LogTime=20020326000000

Wat heb ik al geprobeerd:
De where-clause maakt niet uit. Als ik meer criteria toevoeg dan loopt het net zo hard vast.
Welk veld ik update maakt ook niets uit, het parsen van de datum zou dan ook geen probleem moeten opleveren volgens mij.
Ook heb ik op LogTime een index gelegd, maar ook dat maakt niets uit.
Welke client ik hiervoor gebruik maakt ook niets uit, ik doe het zelf in delphi waarbij ik de mysql API direct aanspreek. Daarover kan dus weinig verwarring ontstaan.

Ook, de velden die in de tabel staan mogen niet veranderen, anders werkt het loggen niet meer.

Het belangrijkste is dus dat ik erachter kom waarom het vastloopt. De oplossing is minder belangrijk (maar wel gewenst).

[drm]

Wat bedoel je met "loopt vast" Krijg je iets van foutmeldingen, oid?

[Pino]

Waarom zou je btw iets willen veranderen in hetzelfde?

[Verwijderd]

Quotes om de value van de LogTime zetten in je query.

[_Thanatos_]

"loopt vast" betekent precies wat er staat. De query loopt gewoon vast, het lijkt alsof ie er voor eeuwig over blijft doen, en hij returnt niet. Als ik het in mysql-front doe, dan loopt het hele prog vast, doe ik het in delphi, dan blijft ie gewoon steken op mysql_query() en komt ie nooit verder.

thef_pino: dat is het punt niet. Het maakt niet uit waarin ik het verander.

typhon: ik zei toch dat het veld niet belangrijk is. als ik een ander veld neem (een int bijvoorbeeld) dan maakt dat niets uit. En bovendien hoeven de quotes niet. Kijk maar.

[Pino]

Het lijkt er dus op dat de database zelf blijft hangen. Hoeveel records heb je eigenlijk?

[Verwijderd]

mysqlcheck?

en kan het niet en deadlock zijn?

[_Thanatos_]

Ik heb net dus een check gedaan, maar die zegt dat de tabel in orde is. Vervolgens loopt de update nog steeds vast. Daar ligt het dus niet aan.

thef_pino, de betreffende tabel heeft op het moment 3944 records. Niet echt dramatisch veel dus.

dj_delta, klinkt misschien dom, maar wat is een deadlock?

ohja, misschien overbodig, maar een willekeurige SELECT met dezelfde criteria als mijn update-statements gaat prima (en binnen een fractie van een seconde).

[Pino]

Een deadlock is dat twee processen elkaars data gebruiken en op elkaar staan te wachten omdat ze allebei iets gelockt hebben.

Dus:

proces 1 opent a
proces 2 opent b

proces 1 heeft b nodig maar krijgt die niet
proces 2 heeft a nodig maar krijgt die niet

en dan lekker wachten.

[_Thanatos_]

Nou een deadlock is het dus ook niet

edit: En een restart helpt ook niet. Kweet trouwens niet of het uitmaakt, maar het is versie 3.23.52-max (die zonder named pipes) en draait op win2k server met SP3.

[ Voor 0% gewijzigd door _Thanatos_ op 04-11-2002 20:25 . Reden: versie-info enzo ]

[marty]

Geef je mysql server eens een trap (ff restarten)
Dat wil het nog wel eens goed doen bij vage foutmeldingen :-)

[cameodski]

_Thanatos_ schreef op 04 november 2002 @ 18:58:
ohja, misschien overbodig, maar een willekeurige SELECT met dezelfde criteria als mijn update-statements gaat prima (en binnen een fractie van een seconde).

Het lijkt erop dat je problemen hebt met exclusive locks of gewoon simpelweg met het schrijven van data.
Kun je wel records inserten?
Ik weet niet of je in MySQL ook hints kunt meegeven. Zo ja, dan kun je eens proberen om mbv een select een exclusive lock te leggen.
In MSSQL kun je dat bijvoorbeel zo doen:

code:

select a
from b with (updlock)

Transactie kennen ze niet zo in MySQL, dus er is vast geen sprake van een transactie die nog actief is.

[_Thanatos_]

Records inserten gaat prima. Het gekke is, de geinserte record updaten met een statement zoals ik postte, gaat wel prima!

Nog wat, ik probeer het nu op een testdoos met mysql 4.0.4 pro en daarop loopt het ook vast. Precies hetzelfde probleem.

Wat trouwens ook opmerkelijk is, is dat het mysqld.exe proces op de server geen cpu-tijd aant opeten is. Helemaal nul komma niks.

[marty]

Wat gebeurt er als je met iets als mysql-front connect en via die GUI de records probeert te veranderen?

[Goodielover]

Blijkbaar staan de door de server geinserte records gelocked. Kan je als je de server down brengt wel bij de database? Dan zou je je query eens moeten uitvoeren met de IIS down.

[_Thanatos_]

marty: mysql-front loopt dan in z'n geheel vast.

Goodielover: dat maakt niet uit denk ik, als die vastlopende query 'uitgevoerd' wordt, en ik kijk vervolgens naar de processlist van mysql, zie ik dat die query het enige draaiende proces is. Bij de status van het proces staat dan echter wel "locked".

[ProgrammerX]

Heb je al eens geprobeerd de record te selecteren voor update :

SELECT * FROM WEBLOG FOR UPDATE

UPDATE WEBLOG SET LOGTIME=123 WHERE LOGTIME=123

Je kunt trouwens wel gebruik maken van transacties, maar alleen i.c.m. InnoDB tabellen en een bepaalde versie (ik dacht 53, maar dat staat in de online documentatie)

P.S. Als je delphi gebruikt i.c.m. MySQL kun je makkelijk gebruik maken van de zeos componenten

[_Thanatos_]

Hmm, hij die "select for update" lijkt ie niet meer vast te lopen... ik gok toch op een bug in mysql (immers, een query hoort niet vast te lopen).

P.S. ProggerX, ik gebruik met opzet de zeos library juist niet, omdat ik dan geen gebruik kan maken van virtualtrees en omdat ik zelf graag de controle over m'n statements hou. Zoals nu. Met zeos (mysql-front gebruikt ook zeos) loopt/liep het dus ook vast.

Mgoed, ik zit nu op m'n werk, ik ga het vanavond thuis nog wel ff uitgebreid uitproberen.

[ProgrammerX]

_Thanatos_ schreef op 05 november 2002 @ 14:14:
Hmm, hij die "select for update" lijkt ie niet meer vast te lopen... ik gok toch op een bug in mysql (immers, een query hoort niet vast te lopen).

P.S. ProggerX, ik gebruik met opzet de zeos library juist niet, omdat ik dan geen gebruik kan maken van virtualtrees en omdat ik zelf graag de controle over m'n statements hou. Zoals nu. Met zeos (mysql-front gebruikt ook zeos) loopt/liep het dus ook vast.

Mgoed, ik zit nu op m'n werk, ik ga het vanavond thuis nog wel ff uitgebreid uitproberen.

Met de online documentatie moet je er wel uitkomen met die "select for update"

Wat je trouwens bedoeld met controle over de statements snap ik niet helemaal.

Ik gebruik die componenten nu ook in delphi, maar maak wel zelf m'n sql statements . Gebruik alleen het database component voor de verbinding, en het query component als dataset voor m'n data (hun dataset is een afgeleide van TDataset, dus kun je hun queries ook koppelen aan datasources). De rest (selecteren, muteren enz.) doe ik inderdaad allemaal met sql statements

Edit : let je er trouwens wel op dat alle records die je gedurende deze "select for update" transactie selecteert ook gelockt zijn voor alle andere processen

[ Voor 0% gewijzigd door ProgrammerX op 05-11-2002 19:16 . Reden: Toevoeging ]

[_Thanatos_]

Volgens mij heb ik de oorzaak gevonden. Het lag idd in de richting van locks (geen deadlock). Ik had een "select * from tabel" statement lopen en deed gelijktijdig die update. om dat de eerste niet direct de resultset download, blijft het proces dus lopen, for some reason, en zijn alle records gelocked voor updaten (en deleten waarschijnlijk).

Maar waarom? sja...

[Goodielover]

The reason is waarschijnlijk read consistency.
Als jij de select open hebt staan en wil dan gaan updaten, kan het dus zijn dat door die update het record niet meer in de select zou voorkomen.
Blijkbaar maakt de DB niet eerst een snapshot van de tabel.

[_Thanatos_]

Dus in plaats van die "select * from tabel" kan ik beter steeds kleine 'hapjes' nemen met de limit-clause... dat zou dan denk ik beter moeten werken?

[Goodielover]

Lees het in een array en dan vandaaruit updaten.
Kan je de query condities van de select niet gewoon in de update opnemen, dan heb je ook geen aparte select nodig.