SQL-Statements und Dateisystemänderungen tracen
„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.
Inhaltsverzeichnis
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.

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.
Schreibe einen Kommentar