Frage zu Fehlermeldung DEADLOCK detected

Computer: Software & Programmierung Datenbanken allgemein
#1

nach dem mir eine OracleDB stehen geblieben ist, habe ich im alert.log die Fehlermeldung deadlock detected gefunden mit dem verwweis auf eine andere Datei (ORA00495.TRC).

in dieser Datei steht denn auch schon folgendes drin:

DEADLOCK DETECTED
Current SQL statement for this session:
delete from „ECCPLUS_DB“.„IMP_VERBRAUCH_WERTE“ where „IMP_ID“ = :1
The following deadlock is not an ORACLE error. It is a
deadlock due to user error in the design of an application
or from issuing incorrect ad-hoc SQL. The following
information may aid in determining the deadlock:
Deadlock graph:

und da drunter - nehme ich an - ein auszug der letzten sql-statements + ausführungsplänen.

nach was sucht man da ? ich muß zugeben, ich bin mal wieder total ratlos… heißt deadlock das zwei verschiedene statements die gleiche spalte gelockt haben oder was ?

#2

Hallo.

nach was sucht man da ? ich muß zugeben, ich bin mal wieder
total ratlos… heißt deadlock das zwei verschiedene
statements die gleiche spalte gelockt haben oder was ?

Grundiziell und prinzisätzlich tritt ein Deadlock dann auf, wenn zwei Prozesse gegenseitig auf ihre jeweils gesperrten Bereiche zugreifen wollen. Der klassische Fall : Benutzer A ändert Personalstamm X und will nach Y; Benutzer B ändert Y und will nach X. Beide Benutzer haben ihren Datensatz in Exklusivsperrung, und damit sind wir in der Eieruhr. Ein RDBMS, das diesen Namen verdient (und O’Rascal ist so was), löst diesen Widerspruch nach fest verdrahteten Algorithmen.

In Deinem Falle sieht es aber so aus, als hätte ein Prozess sich selbst enteiert (Pendant zur Endlosschleife, nur auf Datenbank’sch). Du müsstest also aus dem Logbuch entnehmen, welche Prozesse gerade im einzelnen auf welche Datensatzbereiche zugreifen, ob sich da irgendwas doppelt moppelt. Hast Du einen Log mit den Records und den dazugehörigen Sperrungen?

Gruß kw

#3

hi!

heißt deadlock das zwei verschiedene
statements die gleiche spalte gelockt haben oder was ?

nein, sondern auf dieselbe row oder - im schlechter implementierten fall - dieselbe tabelle oder, wenn es extrem implementiert ist, die gesamte db …

grüße,
tomh

ps: die fehlermeldung horcht sich jedoch irgendwie drastischer an - sieht so aus, als ob da eine „unbekannte“ applikation lockt …

#4

ps: die fehlermeldung horcht sich jedoch irgendwie drastischer
an - sieht so aus, als ob da eine „unbekannte“ applikation
lockt …

„unbekannte applikation“ dürfte stimmen, die leute hier greifen über ein programm auf einem terminalserver auf die datenbank zu

da dieser fehler jetzt 2 mal nacheinander aufgetreten ist und der lieferant der software ende letzter woche was neues in die DB eingespielt hat liegt die vermutung wohl nahe das die irgendeine procedure falsch programmiert haben… denke ich mal

danke schon mal

#5

In Deinem Falle sieht es aber so aus, als hätte ein Prozess
sich selbst enteiert (Pendant zur Endlosschleife, nur auf
Datenbank’sch). Du müsstest also aus dem Logbuch entnehmen,
welche Prozesse gerade im einzelnen auf welche
Datensatzbereiche zugreifen, ob sich da irgendwas doppelt
moppelt. Hast Du einen Log mit den Records und den
dazugehörigen Sperrungen?

was genau meinen Sie mit Logbuch ?

im Alert.log hatte ich den fehler ora-000060 mit verweiß auf die ORA00495.TRC . aus eben jener TRC- datei stammt der auszug der Fehlermeldung aus meiner ersten Frage.

in der TRC- Datei sind wie gesagt noch eine ganze latte select- statements inc jede menge hieroglyphen wie c.b.

SELECT ROWID,IMP_ID,PRF_ID,GBER_ID,PLAN_ID,ZAHLENART_ID,MONAT_ID,JAHR,MONAT,KONTO,SOLL_HABEN_KZ,BETRAG,VKZ FROM IMP_DBR_ERLOESE_BLOCK WHERE (IMP_ID=:1)
hash=68aa89c8 timestamp=02-03-2004 07:39:07
namespace=CRSR flags=RON/KGHP/TIM/PN0/MED/[50010000]
kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch=3
lwt=3fb7184[3fb7184,3fb7184] ltm=3fb718c[3fb718c,3fb718c]
pwt=3fb719c[3fb719c,3fb719c] ptm=3fb71f4[3fb71f4,3fb71f4]
ref=3fb7174[3fb7174,3fb7174] lnd=3fb7200[3fb7200,3fb7200]
LIBRARY OBJECT: object=7d63c18
type=CRSR flags=EXS[0001] pflags= [00] status=VALD load=0
CHILDREN: size=16
child# table reference handle

0 7d63dd4 7d63da0 4a932d0
DATA BLOCKS:
data# heap pointer status pins change

0 7d64928 7d63c9c I/P/A 0 NONE

.
.
.
ich vermute einfach mal das es sich hierbei um den library cache handelt
meinen sie dieses ?

#6

es wurde zwar schon mal erwähnt aber ich erklärs nochmal:

ein deadlock tritt z.b. auf:

  • benutzer a macht update auf person „meier“
  • benutzer b macht update auf adresse zu person „meier“
  • benutzer a will nun ebenfalls adresse von „meier“ updaten. da aber benutzer b den datensatz gesperrt hat, muss a warten, bis b fertig ist (d.h. seine transaktion durch commit beendet hat).
  • benutzer b will nun update auf person „meier“ machen. er muss nun warten, bis benutzer a die transaktion beendet. der wartet aber schon auf b. in schlechten datenbanken würde nun alles hängen. oracle erkennt das problem und bricht beide transaktionen ab. zusätzlich wird noch eine meldung in den von dir beschriebenen logfiles geschrieben.

möglicherweise gibt es db-systeme, die so einen deadlock automatisch lösen können. bin persönlich aber kein fan von solcher „bevormundung“. ein deadlock ist meines erachtens nach immer ein programmfehler bzw. ein designfehler in der applikation. wenn die db diesen fehler still und heimlich selber ausbügelt, kommt niemand auf die idee, dass eigentlich die applikation müll ist. und irgendwann tritt dann ein fehler auf, dem die db nicht mehr gewachsen ist. schlimmstenfalls hast du dann inkonsitenzen in der db.

was in deinem fall möglicherweise der grund für das problem ist:

du hast eine master-detail-beziehung: tabelle b hat foreign-key auf tabelle a (mit „on delete cascade“). session 1 macht ein update auf einen datensatz in tabelle b. in der zwischenzeit will session 2 einen datensatz aus tabelle a löschen. die folge ist, dass die db alle detaildaten aus tabelle b mitlöschen will. einer dieser datensätze ist aber durch session 1 gelockt. session 2 muss also warten. nun will session 1 den zugehörigen master-datensatz ändern (z.b. weil irgendwelche aus den detaildatensätzen berechnete werte zurückgeschrieben werden sollen). ==> klassischer deadlock.

wie gesagt: ein grober designfehler in der applikation. session 1 müsste zuerst den master-datensatz mit einem select for update explizit sperren. dann würde es keine probleme geben.

da ich deine applikation nicht kenne, kann ich nicht genau sagen, woran es bei dir liegt. ich bin mir aber fast sicher, dass es ein ähnliches problem wie oben beschrieben ist.

erwin

#7

Das war eine super erklärung des Problems, vielen dank für die ausführlichkeit !

mittlerweile ist das Problem beim Softwarelieferanten, mal schaun was die rausfinden…