Hogyan diagnosztizálják zár problémák

Mi van, ha valami munkafolyamatát, és a zár megakadályozza minden munkát? Hogyan hogy megtudja, melyik ülésen meg kell ölni, hogy a probléma elment? Ez a probléma elég gyakori a rendszergazdák, de ismeretlen okok miatt számomra az interneten nem találtam olyan modellt, hogy megoldja ezt a problémát. És ott van!







A másik nap a munkahelyen szembe azzal a problémával, zárak, nevezetesen kezdtek megjelenni az üzenet: „Konfliktus zár során végrehajtott tranzakció. Túllépte a maximális várakozási idő a zár.”

Hogyan diagnosztizálják zár problémák

Nyilvánvaló, hogy nincs probléma a patthelyzet, ott is csak valamiféle beszélgetés véget zár és „elfelejtette”, hogy távolítsa el. A probléma a súlyos következményeket helyeztek kilátásba - nem végeztek dokumentum a termékek értékesítése és szolgáltatások. Az adatbázis ugyanakkor mintegy 100 munkavállalót foglalkoztat, és lehetetlen, hogy a rutinszerű és része a művelet!

Két megoldás - újraindítani a szervert, vagy keressen a meghiúsult szekciót. Az első megoldás egyszerű és gyors, de mivel már van valaki írta - rebutat szerver lehet, amíg nem kap rúgva. Elhatároztam, hogy a második utat.

Találtam egy cikket, hogyan nézel, hogy blokkolja a SQL Trace. Igen, akkor is, ha úgy találja, hogy, akkor mi? Kell egy session!







Közelebb a 16:00, amikor rájöttem, hogy nem lehet húzni, csináltam egy újraindítást. Abban a reményben, hogy ez nem fog megtörténni újra (és ez volt az első alkalom, hat hónapos munka), én megkönnyebbültem működött. És jó okkal. A második nap - ugyanaz a helyzet. Én ásott és fél óra, megint érthetetlen kísérlete a Google és mások. Eredmény nélkül. Reboot. A nap végére megint. Nos, azt hiszem, csodálatos, nyugodtan jöjjön haza, és üljön and'll dig. Hazajövök, minden rendben van. Sajnos.

A harmadik napon nézett webinar, meséltek egy érdekes és hatékony módja annak, hogy megtalálják a problémát. Emlékszem, de a probléma már nem jelentkezik. Egy hét telt el, és itt van - a zár újra! Dörzsöli a kezét, és kezdenek viselkedni.

Másolás a fájl tehzhurnala a kijelölt helyre, repül a programban, hívás blokkolás, üzeneteket és távolítsa el vagy nevezze át a fájlt tehzhurnala. Nem kell egy csomó információt más zárak!

Menj a rphost_PID mappában található a szöveges fájlt, és nem a keresés a szó TTIMEOUT. Látjuk a következő sort:

By the way, rphost_PID mappák lehet több, minden attól függ, hogy mennyi a munkafolyamatok a szerveren futó.

És akkor ez egyszerű: nézd a sor végére - WaitConnections = 8239, a mi kapcsolat számát. Mi megy a szerver konzolon a csatlakozások, találjuk ezt a számot, és látni a munkamenet száma. Az én esetemben, az egyik felhasználó két ülés - sikertelen volt, és néhány más. Becsapta az ülésen, és ekkor tehzhurnal. És lám! Minden működött, az öröm nincs határa! De, mint kiderült, az ülés nem lebeg :), működött. Ezért a jövőben - kívánatos, hogy kommunikálni a felhasználóval és éber.

Véleményem viszont meglehetősen tipikus, szabványos megoldás a problémára. Nem ismert, hogy miért nem hallottam, esetleg annak a ténynek köszönhető, hogy meg kellett keresni a riasztást, és amikor a felhasználók nem fogy, nem működött, és elvégzett - a hibák nem.




Kapcsolódó cikkek