[megoldva] Oracle 11 deadlock: ORA-02049: timeout: distributed transaction waiting for lock

Adatbázis: SQL, XML DB

Oracle 11 deadlock: ORA-02049: timeout: distributed transaction waiting for lock

Eleg surgos segitseg kellene. Sajnos elment szabadsagra a dba es nem adott at semmit nekunk. Annyit ertek sql-hez, hogy elfelejtett jelszo reset, uj db letrehozas, user letrehozas es kb ennyi, linuxos vagyok :( Ezt holnap meg kellene oldanom :(
oracle userkent be tudok jelentkezni linux rendszeren, tehat sql prompt van. Innentol kellene help :(

14:38:51,030 ERROR [xx.busyness.confirm]|10.14.4.24| (ajp-/0.0.0.0:8009-24) Error getting record for update with case reference 3361: java.sql.SQLSyntaxErrorException: ORA-02049: timeout: distributed transaction waiting for lock
14:38:51,050 ERROR [ie.originalsolutions.caseflow.acas.ssbl.ExtendedBaseBackgroundJob]|10.14.4.24| (ajp-/0.0.0.0:8009-24) here again: {className="ie.originalsolutions.caseflow.xx.busyness.CaseCalculationsDAO" methodName="getRecord(line:425)" componentSequenceNumber=0 severity=13 errorType=-1 errorMessage="Error getting record for update with case reference 3361" nestedException.message="ORA-02049: timeout: distributed transaction waiting for lock

Amit kaptam infot regrol:
dba korabban torolte a database lockot es az megoldotta a problemat.

Tovabba ez alapjan: http://orababy.blogspot.co.uk/2013/09/ora-02049-timeout-distributed.html
megneztem a lock timeoutot nalunk is 60.

Gui-ban, ha megnezem milyen lockok vannak, user alatt nincs, system alatt van csomo. A db cluster 3 szerverbol all.

1. Hogy kell megnezni ezt a lockos d olgot es, hogy kell ezt a torlest megcsinalni, mik a parancsok es lepesek ?
2. Ha ujra kellene inditani, hogy kell ezt ? Ha egyenkent rebootolom a node-okat gondolom semmit nem er, mert failoverelni fog a masik kettore, ha nem jol gondolom javitsatok. GUI-ban van egy shutdown gomb, esetleg az lenne ? Vagy, hogy van egy helyes ujrainditas, hogy adatok ne seruljenek ?

Pls help :(

  • 2870 megtekintés

( uid_228 | 2015. 08. 14., p – 13:56 )

Biztos elég kellemetlen a helyzet így is, ne vedd piszkálásnak tehát, de miért nem a supportnak írsz? Ha meg anélkül megy egy Oracle adatbázis, akkor ez máris nem a te problémád, hanem az adott cég (informatikai) vezetőjéé.

--
„Spiró ótvar, Konrád átok, Nádastól meg mindjárt hányok!”

( hrgy84 | 2015. 08. 14., p – 14:03 )

Lehetosegek:

- Felhivod a DBA-t, es megkerdezed
- Irsz az Oracle supportnak, es megkerdezed
- Keritesz embert a cegben, aki ert az Oracle-hoz es megkerdezed
- Ulsz, es nagyon szomoru leszel
--
Blog | @hron84
Üzemeltető macik

( lx | 2015. 08. 14., p – 14:16 )

"linuxos vagyok :( Ezt holnap meg kellene oldanom :("

Ez a két információ rebootra predesztinálja az ora szervert.

( tgerczei | 2015. 08. 14., p – 14:30 )

Egészen biztosan nem nyúlnék hozzá egyetlen ujjal sem. Ez nem a Te kompetenciád, és remélhetőleg nem tartozik a felelősségi körödbe sem. Bármi deviancia ezen baseline-tól a cégvezetés közvetlen problémája minden létező értelemben!
------------------------
Program terminated
{0} ok boto
boto ?

( Badb0y | 2015. 08. 14., p – 23:25 )

Utananeztem illetve egy teszt rendszeren le is teszteltem.
Csinaltam egy lockot ez a video alapjan: https://www.youtube.com/watch?v=JitJRb5x9vI

Majd ezeket a lepeseket kovetve kilottem:

Find the locked SID and Serial:
select sid, serial#, username, command, lockwait, osuser from v$session where lockwait is not null;
Find which sql has lock_wait:
select sql_text from v$sqltext where (address,hash_value) in (select sql_address,sql_hash_value from v$session where lockwait is not null) order by address, hash_value, piece;
kill a locked session, first need to find sid, serial.
alter system kill session 'sid, serial#';
Oracle 11 alatt elofordulhat hiba, akkor kell egy @ is a helyere:
... session '130,620,@1'; ...

A hibat nem ez oldotta meg, reggelre elengedte a process, igy szerencsere nem kellett hozzanyulni. De a fenti modszer a teszt rendszeren mukodott, nem tudom a prodon mukodott volna, de legkozelebb igy allok majd neki ha muszaj hozzanyulni.

Szantal koszi az infokat.

Figyelj, a sajat erdekedben mondtuk azt, hogy ha lehet, ne avatkozz bele. A jobbik eset az, hogy ha megoldod, onnantol te leszel a helyettes DBA anelkul, hogy kepzettseged lenne, a rosszabbik lehetoseg az, hogy valamiert elbokod, es te leszel az egyszemelyi felelos, mert ugy nyulsz hozza, hogy otleted sincs, _valojaban_ mit csinalsz. A YouTube video sem mond el mindent, es egy Oracle adatbazisszerver tipikusan olyan cucc, amit az ember nem csakannyal diagnosztizal.

Tudom, hogy ez most lepereg, mert lelkes vagy, es mert szeretned nem megbantani a fonokeidet, ugy erzed, hogy veszelyezteti az allasod, ha foglalkozol az uggyel. De tedd fel a kerdest: az a rosszabb, ha amiatt rugnak ki, mert nem akarsz olyasmit elrontani, amihez nem ertesz, vagy ha azert rugnak ki, mert tobbszazezres/millios kart okoztal a hozzaertesed hianya miatt. Nem biztos, hogy a kovetkezo eset is szerencsesen zarul majd.

Legalabb vedd fontolora.
--
Blog | @hron84
Üzemeltető macik

Tudjukmilyen, szerintem itt sokan voltak mar hasonlo helyzetben. Ezzel szemben 2015 van mar es kozolni kell az illetekessel, hogy ez igy nagyon nem jo es nem tudsz felelosseget vallalni az ilyen vakrepuleseert. Ha pedig nem ertik, hogy egy oracle db mennyire kulon szakma akkor szukseguk sincs ra.

+1. Meg kell mondani, hogy ez az állapot, illetve az ebből történő kihozása a DB-nek nem OS-üzemeltetői, hanem DBA tudást igényel. OS-üzemeltetőként annyit lehet tenni, hogy a problémát vélhetően okozó, egyébként valaminek következményeként beragadt lock-ot kipucolja az ember, de az adatbázis integritását, további helyes működését, konzisztenciáját a kellő DBA és alkalmazás-oldali ismeret hiányában nem lehet garantálni. Röviden: kilőhető egy "gyanús" lock, de lehet, hogy a DB ettől össze fog borulni.

Alapvetően nem csináltál hülyeséget, ez úgymond egy "tűzoltás" módszer. Amire figyelni érdemes:
- diagnosztizálni, hogy mi okozza a problémát, mert ha egyszer előjön, előjöhet máskor is (megtudni mi futtatja), és normális-e ez a működés
- kritikus-e a hiba ahhoz, hogy be kelljen avatkozni, kivárható-e hogy esetleg elmúlik magától
- a kill (disconnect elengánsabb, alter system disconnect session 'sid,serial,@isntance_number' immediate;) okés lehet, csak figyeljünk mit lövünk ki, ha egy SYS tulajdonában lévő kritikus háttérfolyamatot, akkor leállhat az adatbázis (a példád alapján több node-os, RAC rendszeretek van, szóval csak az egyik node állna le, az egész DB nem, de akkor is)
- még az előző ponthoz: érdemes tudni, hogy nem egy kritikus számlázó cuccot vagy valami hasonlót lősz-e ki, persze ha áll miatta az egész feldolgozás, akkor ugye nem sok lehetőség van, vagy kivárod..:D
- az elosztott tranzakció jelentheti azt is, hogy kommunikál a folyamat egy másik DB-vel, és ott van valami bibi, amiért lassú/elakadt, ennek is érdemes lehet utánajárni

Izé. Az ilyen esetek kiválóan alkalmasak rá, hogy a cégvezetést ráébresszék hogy egy DBA nem DBA és ha esetleg mégiscsak egy darab van, akkor (is) legyen már valamilyen doksi néhány dologról. Ahogy többen megjegyezték, tényleg nem túl nyerő olyan rendszerhez nyúlni, amihez egy Youtube video a "support", bátorítani pedig főleg nem jó.