Hallo,
ich habe das folgende Problem.
Ich habe in meiner Datenbank eine Tabelle ganz normal mit Create…angelegt und dann habe PUBLIC alle Rechte, also Select, Insert, Update und Delete vergeben.
Es ist nur so, daß manchmal die Datenbank hängt und habe das Gefühl, daß es passiert, wenn ein User versucht in der neuen Tabelle eine neue Zeile einfügen oder eine Zeile zu ändern und könne die andere User nicht arbeiten. Kann es daher kommen, daß gleichzeitig irgendwar in der Tabelle gemacht wird und dadurch das Problem ausgelöst wird, daß die andere nicht arbeiten können. Das sieht ja so aus, daß in der Anwendung die Sanduhr läuft und irgendwann (nach paar Minuten) kann wieder gearbeitet werden.
Bevor ich die neue Tabelle an die datenbank angebunden hatte, gab es das Problem nicht.
Ich habe in meiner Datenbank eine Tabelle ganz normal mit
Create…angelegt und dann habe PUBLIC alle Rechte, also
Select, Insert, Update und Delete vergeben.
Fein … um welch’ Datenbanksystem, o edler Fremder, handelt es sich? Diese Information wäre zwecks Erteilung einer qualifizorenen Anwort der Unwesentlichkeit nicht teilhaftig,
Hallo,
nach jeder Update bzw. insert oder delete wird ja ein COMMIT gesetzt. In Enterpreis-Manager? Wo kan ich nach Sperren sehnen?
Habe Oracle Enterpreis Manager Version 1.6.0
Gruß
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Peter,
vielen Dank für Ihre Tips,
Im Ent. Manager habe es leider nicht gefunden.
Mein Tablespace TEMP ist auch groß genug.
Habe versucht über die beider Log-Dateien, aslo V_$LOCK und V_$LOCK_OBJECT.
Ich kann die Tabelle nicht so verstehen. Bin ja kein Administrator, sonder nur Entwickler.
In V_$LOCKED_OBJECT steht aber der Name eines Useres, der wahrscheinlich die Aktion auslöst. Aber ich sehe kein Datum und so, um zu verstehen, ob das aktuell ist.
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
da wir ja nun schon wissen, dass es um Oracle geht: Folgende Dynamic Performance Views sind für dich interessant:
v$session
Dort siehst du alle aktuellen Sessions. Die brauchst du insbesondere, um für eine bestimmte Session SID und SERIAL# herauszufinden.
v$session_wait
Dort siehst du, was die aktiven Sessions gerade tun, bzw. worauf sie warten. Wer welche Session hat kannst du über die SID/SERIAL# in v$session herausfinden.
v$lock
Dort siehst du, welche Session (SID) ein Objekt sperrt (Block > 0), auf welches andere Sessions gerne zugreifen würden (Request > 0)
v$transaction
Dort siehst du, welche Session(s) eine offene Transaktion haben (also z.B. einen INSERT/DELETE/UPDATE ohne COMMIT). Die Verknüpfung mit der v$session läuft hier übrigens nicht über die SID sondern über v$transaction.SES_ADDR v$session.SADDR.
Mit den Resultaten deiner Nachforschungen kommst du dann am besten wieder hierher. Für mich klingt das Problem übrigens seeehr nach einem vergessenen COMMIT.
Ein netter Trick um vergessene COMMITs zu finden (so man sie nicht beim Testen über die v$transaction findet) ist, vor dem Beginn einer Transaktion einen "SET TRANSACTION NAME " zu machen. Wenn dieses Statement ausgeführt wird aber schon eine Transaktion offen ist, dann kommt der Fehler ORA-01453. in dem Fall ist dann entweder die Stelle, an der man den SET gemacht hat falsch, oder irgendwo davor wurde eine Transaktion nicht abgeschlossen…
Hallo,
ich habe das folgende Problem.
Ich habe in meiner Datenbank eine Tabelle ganz normal mit
Create…angelegt und dann habe PUBLIC alle Rechte, also
Select, Insert, Update und Delete vergeben.
Hallo:
Bei solchen FRagen bitte immer das ensprechende SQL Script mitliefern, so dass jemand dies auch testen kann.
Es ist nur so, daß manchmal die Datenbank hängt und habe das
Gefühl, daß es passiert, wenn ein User versucht in der neuen
Tabelle eine neue Zeile einfügen oder eine Zeile zu ändern und
könne die andere User nicht arbeiten.
Liegt auf dieser Tabelle ein Foreign key, welcher nicht indiziert ist ? FK’s auf Columns, welche mutiert werden können, sollen (müssen) immer indiziert sein
Kann es daher kommen,
daß gleichzeitig irgendwar in der Tabelle gemacht wird und
dadurch das Problem ausgelöst wird, daß die andere nicht
arbeiten können. Das sieht ja so aus, daß in der Anwendung die
Sanduhr läuft und irgendwann (nach paar Minuten) kann wieder
gearbeitet werden.
Bevor ich die neue Tabelle an die datenbank angebunden hatte,
gab es das Problem nicht.