SQL-Statements und Dateisystemänderungen tracen

(Last Updated On: 16. Juni 2016)

„Woher zieht der sich den Scheiß?“. Diese Frage schwirrt mir beim Upgrade und bei der Installation von komplexen Enterprise-Technologien immer über den Kopf, wenn Dumps geworfen werden, ohne dass in den Logs irgendwelche aussagekräftigen Informationen stehen würden.

Hierbei kann es oftmals helfen, wenn man mit tracen kann, welche SQL Statements gerade von der automatischen Prozedur auf der Datenbank ausgeführt werden, und welche Dateien auf dem DAteisystem verändert werden.

Dieser Beitrag wird regelmäßig geupdatet, um verschiedene Datenbanken und Dateisysteme abzudecken.

SQL-Statements auf eine Oracle Datenbank tracen

Als erstes müssen Sie wissen, wie der User heißt, dessen Session Sie tracen wollen. Eine Liste aller User kriegen Sie über

SELECT username from dba_users;

dann braucht irh den client identifier für eine session, die unter diesem usernamen braucht. Den Cleint identifier könnt ihr rausbekommen über

select client_identifier from v$session;

Danach aktivieren wir für diesen User die STatistiken

EXECUTE DBMS_MONITOR.CLIENT_ID_stat_ENABLE(client_id => '<cleint identifier>');

Jetzt lasst ihr die atuomatishce Prozedur, die ihr analysieren wollt, nochmal laufen, so dass die abzufangenden SQL Statements auf die Datenbank angesetzt werden. Sobald ihr sicher seid, dass die SQL Statements abgesetzt wurden, deaktiviert ihr den Trace wieder über

execute dbms_monitor.client_id_stat_disable(client_id => '<client identifier>');

Die gesammelten Statistiken für den Client identifier könnt ihr nun abrufen über beispielsweise

select * FROM V$CLIENT_STATS WHERE client_identifier LIKE '<client identifier>'

In den STatistiken stehen noch nicht die SQL Statements drin, sondern nur  statistische informationen, also beispielsweise welche Art von Statement ausgeführt wurde und wie lange diese gedauert hat.

Nun wollen wir detaillierter gehen und aktivierten statt den Statistiken einen detaillierten SQL Trace.

Bevor wir den SQL Trace checken müssen wir einige Paramter checken über den Befehl

show parameter <parametername>

Hierbi checkenw ir folgende parameter

  • diagnostic_dest. Zeigt den Ordner an, in dem später der trace geschrieben wird. In einem SAP system ist dieser Ordner meistens auf X:\ORACLE\TRP\SAPTRACE
  • MAX_DUMP_FILE_SIZE. Dieser Parameter steht standardmäßig auf UNLIMITED, was bedeutet, dass die Trace Files beliebig groß werden können. DAs kann natürlich dazu führen, dass die Festplattenpartition, in welche die Traces geschrieben werden, voll wird – was wir nicht wollen. Deswegen sollte hier ein Limit gesetzt werden.
  • STATISTICS_LEVEL. Steht diese rWert uaf all, werden zusätzlich zu den SQL Statements auch die Reaktionszeiten mitgeloggt, die wir bereits weiter oben einmal geloggt haben. ist der Wert auf BASIC, werdne diese hingegen nicht mit gesammelt.

Desweiterne wird es ohne einen TraceFile Identifier sehr schwer werden herauszufinden, welches Tracefile nachher für uns interessant ist. Daher setzen wir einen solchen Identifier über

ALTER SESSION SET TRACEFILE_IDENTIFIER = 'my_trace_id';

jetzt aktivierne wir das Tracing für die gesamte Datnebankinstanz über

dbms_monitor.database_trace_enable(instance_name => '<INstanzname>');

wenn der Trace aktiv ist, bekommt ihr nun einen Datensatz zurück bei der Abfrage

select * from dba_enabled_traces;

Jetzt führen wir wieder die Prozedur aus, die zu den aufzuzeichnednen sQL Statements führt, und beenden danach das Tracing wieder über

dbms_monitor.database_trace_disable;

Wenn ihr nach Deaktiiveren des Traces nun in euer DIAGNOSTIC_DEST-Verzeichnis schaut, werdet ihr dort jede Menge aktuelle Tracefiles finden. Öffnet ihr diese, werdet ihr dort nun SQL Statements vorfinden, die auf die Datenbank ausgeführt wurden.

2016-06-02_21h44_32

Diese Trace Files könnt ihr jetzt entweder innerhalb des Verzeichnisses nach beispielsweise einer bestimmten Tabelle oder Spalte greppen. Oder ihr könnt die Trace Files auch mit Hilfe der Binary trcsess in eine einzige Datei zusammenfügen.

Alle Dateien finden, die sich die letzten x Minuten geändert haben

Oftmals führen Sie eine Tätigkeit in einem Programm durch und Sie wollen wissen, welche Dateien auf dem Betriebssystem dadurch beeinflusst werden. Wenn Sie sich merken, wann Sie die Aktion durchgeführt haben, beispielsweise um 21:35, und um 21:40 wollen Sie wissen, welche Dateien sich die letzten 5 Minuten geändert haben, können Sie im betreffenden Verzeichnis einfach eingeben

find . -cmin -5

Oder alternativ können Sie alle DAteien in diesem Verzeichnis nach dem Änderungsdatum absteigend sortieren (die neusten Files stehen unten) und dann eine Uhrzeit greppen. Der folgende String greppt nach allen Dateien, die irgendwann zwischen 21:30 und und 21:39 verändert wurden

ls -lrt . | grep "Jun 16 21:3"

Dateisystemänderungen dauerhaft tracen

wenn Ihnen die Methode aus dem oberen Abschnitt nicht genügt und Sie stattdessen änderungen auf bestimmte Dateien dauerhaft tracen wollen, ist eventuell die binary audit etwas für Sie. Installation über

apt-get install audit

Starten über

/etc/init.d/auditd start

Jetzt bestimmen Sie, welche Daten der auditd überwachen soll. Wenn Sie beispielsweise eine Auditing-Regel auf die /etc/passwd legen wollen, die sowohl lesezugriffe als auch Veränderungen an den Ateiattributen trackt, dann geben Sie ein

auditctl -w /etc/passwd -k passwdtrace -p ra

Der Parameter -p bestimmt mit den Werten „ra“, dass Lesezugriff (read) und Attributsänderungen (attribute) auf die Datei getrackt werden. Über den Parameter -k geben sie einen eindeutigen Namen ein, der dann in den Audit Logs auftaucht, wenn so eine Aktion an /etc/passwd durchgeführt wird. Wenn Sie nun das log auswerten über

ausearch -k passwdtrace

dann suchen Sie im Log nach allen Einträgen, die auf Ihre Auditing-Regel passwdtrace zutreffen.

Sie können aber nicht nur nach Audit-REgelnamen filtern, sondern z. B. auch nach executables, die auf die Dateien zugegriffen haben

ausearch -x /bin/grep
ausearch -x /bin/rm

oder nach Usern

ausearch -ui 1000

Weitere Nützliche File Changing Tools

inofity-tools, incron

 

 

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

DaFRK

Andreas Loibl ist SAP-Berater, Ethical Hacker und Online Marketing Manager und schreibt auf seinem Blog DaFRK Blog über verschiedene Themen in den Sektoren Projektmanagement, Informationstechnik, Persönlichkeitsentwicklung, Finanzen und Zeitmanagement.

Das könnte Dich auch interessieren …

Kommentar verfassen

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.