Zugriff auf gleiche tabelle

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

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.

Vielen Dank im Vorraus und Gruß

#2

Hallo.

ich habe das folgende Problem.

Ich habe auch eins …

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,

meint Eiilicht zu Vensre, wo grüßt

#3

Hi,
es handelt sich um ORACLE-Datenbanl und in Form Designer geschribene PL-SQL-Befehle. Sorry für Unvöllständigkeit der Frage…

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#4

Hallo,

vermutlich vergißt dein User das COMMIT.

was passiert kannst Du in der Enterprise Manager Konsole sehen. Da sollten die Sperren aufgelistet sein. (Das hängt etwas von der Version ab.)

Gruß

Peter

#5

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]

#6

Hallo,

Enterprise Manager Konsole öffnen, mit DB verbinden. Unterhalb von SESSIONS sollte ein Ordner SPERREN sein. (Nicht bei allen)

Alternativ:
Linke Seite in den Aufklappmenues. Ist etwas versteckt unter den Analysetools.

Alternativ:
Schau mal in V$LOCKS und V$LOCKED_OBJECT

Evtl ist auch der TEMPORARY TABLESPACE zu klein.

Gruß

Peter

#7

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]

#8

Hallo,

hab leider grad keine Oracle hier am Laufen, aber das wird DIr sicher weiterhelfen:

http://www.cs.utah.edu/classes/cs5530-gary/oracle/do…

Gruß

Peter

#9

Hallo Rezaei,

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…

Gruß
Martin

#10

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.

Vielen Dank im Vorraus und Gruß