User & Table Monitoring

[eukalyptus]

Hi Leute,

ich wollte fragen, wie man in Oracle 9i User Aktivitäten überwachen kann. Ich würde zB gern herausfinden, welche User auf einen bestimmte Tabelle zugreifen und eventuell was sie gerade für eine Operation tun. Kann man das mittels SQL-Statements herausfinden oder brauche ich eine spezielle Monitoring-Software?

LG

[jwi]

Wir haben dies über einen Trigger gelöst.

[eukalyptus]

Wir haben dies über einen Trigger gelöst.

thx für deine Antwort erstmals. Ja ein Trigger könnte ich mir auch vorstellen, jedoch habe ich das Problem, dass ich bei dieser Tabelle den Datentyp einer Spalte ändern möchte und ich bekomme von Oracle immer eine Fehlermeldung (weil darauf zugeriffen wird). Ich würde jetzt gern diese User herausfinden und die Verbindung sozusagen "killen" oder zumindest diese benachrichtigen, dass sie sich ausloggen sollen oder so. Für einen Trigger ist es zu spät, außerdem würde mir ein Trigger keine Information darüber liefern, ob ein User gerade darauf zugreift oder? Ich könnte pro Operation (select, update, delete) die Aktionen mitloggen, mehr fällt mir auf Anhieb nicht ein. Wäre erfreut auf weitere Vorschläge...

LG

[dimitri]

Man ändert ja nicht ständig den Datentyp einer Spalte (und falls doch, sollte man sich Gedanken über sein Applikationsdesign machen).

Bei DDL Operationen sollte sowieso niemand schreibend auf der Datenbank rumeiern, sprich man beendet alle laufenden Sessions des Zugriffsusers und nimmt ihm die SESSION Rolle weg bzw. fährt den AppServer etc. runter bis der Updatevorgang erledigt ist.

Oracle bietet ab 11g Möglichkeiten solche Operationen auch wirklich live durchzuführen, allerdings ist dies eine kostenpflichtige Option der ohnehin nicht ganz günstigen Enterprise Edition (Real Application Testing).

Dim

[eukalyptus]

Man ändert ja nicht ständig den Datentyp einer Spalte (und falls doch, sollte man sich Gedanken über sein Applikationsdesign machen).

Eh nicht, aber man kann sich ja mal vertun, dass man einen falschen Datentyp genommen hat und später der Fehler erst zum Vorschein getreten ist.

Bei DDL Operationen sollte sowieso niemand schreibend auf der Datenbank rumeiern, sprich man beendet alle laufenden Sessions des Zugriffsusers und nimmt ihm die SESSION Rolle weg bzw. fährt den AppServer etc. runter bis der Updatevorgang erledigt ist.

Genau, deshalb habe ich ja gefragt...

User herausfinden und die Verbindung sozusagen "killen"...

Nach deiner Beschreibung sollte es reichen wenn ich mittels

SQL> ALTER SYSTEM KILL SESSION 'sid,serial#';

die derzeit offenen Sessions beende, jedoch hätte ich wieder das Problem, das bis dahin wieder irgendwelche geöffnet werden können oder? Ich möchte ehrlich gesagt nicht mit den Rollen herumspielen, weil das ganze System eh schon komplex genug ist und ich wirklich nicht was reinpfuschen möchte.. Wie mache ich das am besten bzw. wie würdest du es machen?

LG

[dimitri]

Eh nicht, aber man kann sich ja mal vertun, dass man einen falschen Datentyp genommen hat und später der Fehler erst zum Vorschein getreten ist.

Aber doch nicht in einer produktiven Umgebung. Testet Ihr denn nicht? Datentypen mal so eben wieder ändern ist meistens nicht mehr möglich.

Wie mache ich das am besten bzw. wie würdest du es machen?

Anwender informieren, Listener herunterfahren, Sessions killen, Strukturen updaten, Listener wieder hoch fahren, Anwender informieren.

Dim

[eukalyptus]

Aber doch nicht in einer produktiven Umgebung. Testet Ihr denn nicht? Datentypen mal so eben wieder ändern ist meistens nicht mehr möglich.

Wenns nicht möglich wäre, würde es zunächst einmal bei ALTER TABLE das Schlüsselwort MODIFY nicht geben . Desweiteren: Bei Datentyp-Problemen in Client/Server Archiketuren kann man das Problem anhand DB Basis ODER GUI Basis lösen. Da ich jedoch mit der GUI nichts zu tun habe und schnell eine Lösung finden muss, gibt es nur diese Möglichkeit. Aber gut, darüber zu diskutieren, welche Fehler man machen darf oder nicht bzw. wie hilfreich deine Kritik zu meinem Problem ist, wird schon etwas Off-Topic.

Anwender informieren, Listener herunterfahren, Sessions killen, Strukturen updaten, Listener wieder hoch fahren, Anwender informieren.

Ich habs schon gelöst, dass ich einfach zu einem Zeitpunkt wo wenig bis gar kein Traffic mehr ist (somit gar keine aktiven Sessions), meine DDL-Operation durchgeführt habe. Das Problem wäre nun aus der Welt geschaffen.

Btw, Oracle Sessions sind zunächst einmal ganz gut, was User Monitoring betrifft. Gibt es auch System-Tables, die Information über die Ressourcen (Tables, Views etc.) liefern, auf denen ein User gerade zugreift?

Thx
LG