LogMining - Versionsgeschichte

St161253 am 22. Februar 2020 um 18:44 Uhr

2020-02-22T18:44:46Z

← Nächstältere Version		Version vom 22. Februar 2020, 18:44 Uhr
Zeile 6:		Zeile 6:
	Sobald eine Oracle Datenbank Daten in ihrem Bestand modifizieren, anlegen oder löschen soll, führt Oracle diese Anweisung im schnellen Arbeitsspeicher (SGA) durch und übernimmt diese Änderungen zeitversetzt in den Datendateien (datafiles). Dieses Vorgehen an sich ließe sich nicht mit den [https://de.wikipedia.org/wiki/ACID ACID] Anforderung an relationale Datenbanken vereinbaren, da das RDBMS zu jederzeit sicherstellen muss, dass durchgeführte Transaktionen auch persistiert sind - selbst wenn das System im nächsten Moment durch einen Stromausfall ausfallen sollte. Oracle schreibt daher sämtliche Änderungen [[DDL & DML\|(DDL und ändernde DML)]] parallel in ein Transaktionsjournal, den so genannten Redo-Logs.		Sobald eine Oracle Datenbank Daten in ihrem Bestand modifizieren, anlegen oder löschen soll, führt Oracle diese Anweisung im schnellen Arbeitsspeicher (SGA) durch und übernimmt diese Änderungen zeitversetzt in den Datendateien (datafiles). Dieses Vorgehen an sich ließe sich nicht mit den [https://de.wikipedia.org/wiki/ACID ACID] Anforderung an relationale Datenbanken vereinbaren, da das RDBMS zu jederzeit sicherstellen muss, dass durchgeführte Transaktionen auch persistiert sind - selbst wenn das System im nächsten Moment durch einen Stromausfall ausfallen sollte. Oracle schreibt daher sämtliche Änderungen [[DDL & DML\|(DDL und ändernde DML)]] parallel in ein Transaktionsjournal, den so genannten Redo-Logs.

	Diese Redo-Logs protokollieren sinngemäß, durch welche Operationen der Datenbestand der Datenbankdatei zu modifizieren ist, um den aktuellen Zustand im Arbeitsspeicher zu entsprechen. Eine Transaktion wird also erst gegenüber dem Client als abgeschlossen bestätigt (commit), wenn dessen Operationen in den Redo-Logs niedergeschrieben sind. Sollte es im nächsten Moment zum Ausfall kommen, kann beim Hochfahren des Datenbanksystems der Datenbestand im Arbeitsspeicher wiederhergestellt werden, indem die Datenbankdateien eingelesen und die ausstehenden Redo-~~Log~~-Einträge erneut abgearbeitet (redo) werden.		Diese [[Redo Logs\|Redo-Logs]] protokollieren sinngemäß, durch welche Operationen der Datenbestand der Datenbankdatei zu modifizieren ist, um den aktuellen Zustand im Arbeitsspeicher zu entsprechen. Eine Transaktion wird also erst gegenüber dem Client als abgeschlossen bestätigt (commit), wenn dessen Operationen in den [[Redo Logs\|Redo-Logs]] niedergeschrieben sind. Sollte es im nächsten Moment zum Ausfall kommen, kann beim Hochfahren des Datenbanksystems der Datenbestand im Arbeitsspeicher wiederhergestellt werden, indem die Datenbankdateien eingelesen und die ausstehenden [[Redo Log\|Redo-Logs]]-Einträge erneut abgearbeitet (redo) werden.

	'''Was sind archivierte Transaktionsjournale (archivelogs)?'''		'''Was sind archivierte Transaktionsjournale (archivelogs)?'''
	Die Redo-Logs sind zur Sicherstellung der Konsistenz einer Oracle Datenbank von entscheidender Bedeutung. Daher werden diese Dateien zeitgleich i.d.R. min. zweimal geschrieben. Hierbei sollten zwei verschiedene Speicher eingesetzt werden.		Die [[Redo Logs\|Redo-Logs]] sind zur Sicherstellung der Konsistenz einer Oracle Datenbank von entscheidender Bedeutung. Daher werden diese Dateien zeitgleich i.d.R. min. zweimal geschrieben. Hierbei sollten zwei verschiedene Speicher eingesetzt werden.

	Sollte ein Journal beschädigt werden (z.B. weil das zugrunde liegende Dateisystem beschädigt wurde), kann Oracle mit der bzw. den verbleibenden Kopien die Fortsetzung des Betriebs sicherstellen. Die beiden Kopien werden im Oracle Terminologie Redo-Log-Gruppe bezeichnet. Für den Forensiker sind die Kopien also lediglich von Bedeutung, wenn der Verdacht im Raum steht, dass ein einzelne Redo-~~Log~~-Datei beschädigt wurde.		Sollte ein Journal beschädigt werden (z.B. weil das zugrunde liegende Dateisystem beschädigt wurde), kann Oracle mit der bzw. den verbleibenden Kopien die Fortsetzung des Betriebs sicherstellen. Die beiden Kopien werden im Oracle Terminologie Redo-Log-Gruppe bezeichnet. Für den Forensiker sind die Kopien also lediglich von Bedeutung, wenn der Verdacht im Raum steht, dass ein einzelne [[Redo Log\|Redo-Logs]]-Datei beschädigt wurde.

	Die Transaktions-Journale werden in einem Ring-Speicher abgebildet. Konkret handelt es sich um min. zwei, i.d.R. drei Redo-Log-Gruppen, die abwechselnd (Der Übergang heißt "log switch") beschrieben werden. Es gibt eine aktuelle Redo-Log-Gruppe und außerdem aktive und inaktive Redo-Log-Gruppen. Aktuelle und aktive Redo-Log-Gruppen benötigt Oracle im Falle eines Ausfalls für eine Wiederherstellung (Instance Recovery). Die inaktive Redo-Log-Gruppe wartet lediglich auf die Verwendung nach dem log switch.		Die Transaktions-Journale werden in einem Ring-Speicher abgebildet. Konkret handelt es sich um min. zwei, i.d.R. drei Redo-Log-Gruppen, die abwechselnd (Der Übergang heißt "log switch") beschrieben werden. Es gibt eine aktuelle Redo-Log-Gruppe und außerdem aktive und inaktive Redo-Log-Gruppen. Aktuelle und aktive Redo-Log-Gruppen benötigt Oracle im Falle eines Ausfalls für eine Wiederherstellung (Instance Recovery). Die inaktive Redo-Log-Gruppe wartet lediglich auf die Verwendung nach dem log switch.

	Sobald der Archive-Log-Modus aktiv ist, werden genutzte Redo-Logs nach einem log switch weggesichert. Sobald diese gesicherten Redo-Logs in ein spezielles "FRA" Verzeichnis (Fast Recovery Area) weggeschrieben wurden, spricht man anstelle von Redo-Logs von s.g. Archive-Logs.		Sobald der Archive-Log-Modus aktiv ist, werden genutzte Redo-Logs nach einem log switch weggesichert. Sobald diese gesicherten [[Redo Logs\|Redo-Logs]] in ein spezielles "FRA" Verzeichnis (Fast Recovery Area) weggeschrieben wurden, spricht man anstelle von [[Redo Logs\|Redo-Logs]] von s.g. Archive-Logs.

	Letztere erlauben es im laufenden Betrieb den kompletten Datenbestand der Oracle Datenbank atomar - als Transaktion für Transaktion - zu sichern. Das ist sogar möglich während das System online ist. Benötigt werden hierfür, neben den Control-Files - die hier aber nicht weiter erläutert werden - die Datenbankdateien (datafiles) und alle folgenden Redo-Logs, um Voll-, kommulative oder inkrementielle Backups zu erstellen. Derartige Backups sollen jedoch hier nicht weiter vertieft werden. Lediglich von dessen Existenz sollte ein Datenbank-Forensiker gehört haben.		Letztere erlauben es im laufenden Betrieb den kompletten Datenbestand der Oracle Datenbank atomar - als Transaktion für Transaktion - zu sichern. Das ist sogar möglich während das System online ist. Benötigt werden hierfür, neben den Control-Files - die hier aber nicht weiter erläutert werden - die Datenbankdateien (datafiles) und alle folgenden Redo-Logs, um Voll-, kommulative oder inkrementielle Backups zu erstellen. Derartige Backups sollen jedoch hier nicht weiter vertieft werden. Lediglich von dessen Existenz sollte ein Datenbank-Forensiker gehört haben.

St161253 am 22. Februar 2020 um 18:04 Uhr

2020-02-22T18:04:34Z

← Nächstältere Version		Version vom 22. Februar 2020, 18:04 Uhr
Zeile 4:		Zeile 4:

	'''Was sind Transaktionsjournale (redologs)?'''		'''Was sind Transaktionsjournale (redologs)?'''
	Sobald eine Oracle Datenbank Daten in ihrem Bestand modifizieren, anlegen oder löschen soll, führt Oracle diese Anweisung im schnellen Arbeitsspeicher (SGA) durch und übernimmt diese Änderungen zeitversetzt in den Datendateien (datafiles). Dieses Vorgehen an sich ließe sich nicht mit den [https://de.wikipedia.org/wiki/ACID ACID] Anforderung an relationale Datenbanken vereinbaren, da das RDBMS zu jederzeit sicherstellen muss, dass durchgeführte Transaktionen auch persistiert sind - selbst wenn das System im nächsten Moment durch einen Stromausfall ausfallen sollte. Oracle schreibt daher sämtliche Änderungen (DDL und ändernde DML) parallel in ein Transaktionsjournal, den so genannten Redo-Logs.		Sobald eine Oracle Datenbank Daten in ihrem Bestand modifizieren, anlegen oder löschen soll, führt Oracle diese Anweisung im schnellen Arbeitsspeicher (SGA) durch und übernimmt diese Änderungen zeitversetzt in den Datendateien (datafiles). Dieses Vorgehen an sich ließe sich nicht mit den [https://de.wikipedia.org/wiki/ACID ACID] Anforderung an relationale Datenbanken vereinbaren, da das RDBMS zu jederzeit sicherstellen muss, dass durchgeführte Transaktionen auch persistiert sind - selbst wenn das System im nächsten Moment durch einen Stromausfall ausfallen sollte. Oracle schreibt daher sämtliche Änderungen [[DDL & DML\|(DDL und ändernde DML)]] parallel in ein Transaktionsjournal, den so genannten Redo-Logs.

	Diese Redo-Logs protokollieren sinngemäß, durch welche Operationen der Datenbestand der Datenbankdatei zu modifizieren ist, um den aktuellen Zustand im Arbeitsspeicher zu entsprechen. Eine Transaktion wird also erst gegenüber dem Client als abgeschlossen bestätigt (commit), wenn dessen Operationen in den Redo-Logs niedergeschrieben sind. Sollte es im nächsten Moment zum Ausfall kommen, kann beim Hochfahren des Datenbanksystems der Datenbestand im Arbeitsspeicher wiederhergestellt werden, indem die Datenbankdateien eingelesen und die ausstehenden Redo-Log-Einträge erneut abgearbeitet (redo) werden.		Diese Redo-Logs protokollieren sinngemäß, durch welche Operationen der Datenbestand der Datenbankdatei zu modifizieren ist, um den aktuellen Zustand im Arbeitsspeicher zu entsprechen. Eine Transaktion wird also erst gegenüber dem Client als abgeschlossen bestätigt (commit), wenn dessen Operationen in den Redo-Logs niedergeschrieben sind. Sollte es im nächsten Moment zum Ausfall kommen, kann beim Hochfahren des Datenbanksystems der Datenbestand im Arbeitsspeicher wiederhergestellt werden, indem die Datenbankdateien eingelesen und die ausstehenden Redo-Log-Einträge erneut abgearbeitet (redo) werden.

Etduen am 22. Februar 2020 um 16:07 Uhr

2020-02-22T16:07:45Z

← Nächstältere Version		Version vom 22. Februar 2020, 16:07 Uhr
Zeile 1:		Zeile 1:
	~~Dieser Artikel beschäftigt sich mit dem~~ LogMining in Oracle Datenbanken.		'''LogMining in Oracle Datenbanken'''

	Im Kontext von Oracle Datenbanken, versteht man unter der Terminologie LogMining die nachträgliche Aufbereitung und Einsichtnahme von aktuellen oder archivierten Transaktionsjournalen.		Im Kontext von Oracle Datenbanken, versteht man unter der Terminologie LogMining die nachträgliche Aufbereitung und Einsichtnahme von aktuellen oder archivierten Transaktionsjournalen.

St161253 am 22. Februar 2020 um 15:40 Uhr

2020-02-22T15:40:40Z

St161253: Screenshot eingefügt der das Ergebnis eines LogMining-Prozesses darstellt.

2020-02-16T21:56:55Z

Screenshot eingefügt der das Ergebnis eines LogMining-Prozesses darstellt.

← Nächstältere Version		Version vom 16. Februar 2020, 21:56 Uhr
Zeile 40:		Zeile 40:
	Nun teilt man dem LogMiner mit, welche Archive- oder Redo-Logs er lesen soll. Ich wähle nur die aktuellen REDO-Logs, da auf meiner Demo-Umgebung keine Archive-Logs vorliegen und meine Redo-Log-Gruppen noch nicht durchgeswitcht sind.		Nun teilt man dem LogMiner mit, welche Archive- oder Redo-Logs er lesen soll. Ich wähle nur die aktuellen REDO-Logs, da auf meiner Demo-Umgebung keine Archive-Logs vorliegen und meine Redo-Log-Gruppen noch nicht durchgeswitcht sind.
	Die letzte Anweisung startet den LogMiner. Hierbei wird dem LogMiner über einem Parameter mitgeteilt, dass er als Dictionary den Online Katalog nutzen soll.		Die letzte Anweisung startet den LogMiner. Hierbei wird dem LogMiner über einem Parameter mitgeteilt, dass er als Dictionary den Online Katalog nutzen soll.
			<br clear="right"/>

	~~TOFILL~~		[[Datei:ORACLE SQLMINER DELETES FOUND.png\|mini\|Das Bild zeigt die Löschung meiner Datensätze. Zusammen mit einem Zeitstempel und dem Bentzer]]
			Nun kann über den nebenstehenden Befehl ermittelt werden, was der Anwender "DBUSER" in der letzten Zeit so angestellt hat. Hier wird nach der Aktivität innerhalb der letzten Stunde gefragt, aber natürlich sind auch andere Abfragen möglich.

St161253: Ergänzung erster Absätze als Beispiel

2020-02-16T20:34:07Z

Ergänzung erster Absätze als Beispiel

← Nächstältere Version		Version vom 16. Februar 2020, 20:34 Uhr
Zeile 30:		Zeile 30:

	Das Oracle Datenbanksystem erlaubt es sogar, einzelne Anweisungen aus der Vergangenheit unwirksam zu machen. Wie weit dies jedoch in den Datenbestand der Gegenwart durchgereicht wird, ist von verschiedenen Faktoren abhängig, die hier nicht weiter betrachtet werden.		Das Oracle Datenbanksystem erlaubt es sogar, einzelne Anweisungen aus der Vergangenheit unwirksam zu machen. Wie weit dies jedoch in den Datenbestand der Gegenwart durchgereicht wird, ist von verschiedenen Faktoren abhängig, die hier nicht weiter betrachtet werden.


			Beispiel:
			[[Datei:ORACLE SQL DELETE FROM PROFESSOREN.png\|mini\|Abb.1: Löschen unliebsamer Professoren]]
			Um ein ungewolltes Verhalten einzuschleusen löscht ein "frustrierter Student" als Benutzer „DBUSER“ einige unliebsame Professoren aus der Datenbank. Über die folgende Übung mit dem LogMiner wird diese Manipulation dann offengelegt.
			<br clear="right"/>

			[[Datei:ORACLE SQL START LOGMINER.png\|mini\|Abb. 2: Starten des Oracle LogMiners]]
			Nun teilt man dem LogMiner mit, welche Archive- oder Redo-Logs er lesen soll. Ich wähle nur die aktuellen REDO-Logs, da auf meiner Demo-Umgebung keine Archive-Logs vorliegen und meine Redo-Log-Gruppen noch nicht durchgeswitcht sind.
			Die letzte Anweisung startet den LogMiner. Hierbei wird dem LogMiner über einem Parameter mitgeteilt, dass er als Dictionary den Online Katalog nutzen soll.

	TOFILL		TOFILL

St161253: Die Seite wurde neu angelegt: „Dieser Artikel beschäftigt sich mit dem LogMining in Oracle Datenbanken. Im Kontext von Oracle Datenbanken, versteht man unter der Terminologie LogMining die…“

2020-02-16T19:48:15Z

Die Seite wurde neu angelegt: „Dieser Artikel beschäftigt sich mit dem LogMining in Oracle Datenbanken. Im Kontext von Oracle Datenbanken, versteht man unter der Terminologie LogMining die…“

Neue Seite

Dieser Artikel beschäftigt sich mit dem LogMining in Oracle Datenbanken.

Im Kontext von Oracle Datenbanken, versteht man unter der Terminologie LogMining die nachträgliche Aufbereitung und Einsichtnahme von aktuellen oder archivierten Transaktionsjournalen.

'''Was sind Transaktionsjournale (redologs)?'''
Sobald eine Oracle Datenbank Daten in ihrem Bestand modifizieren, anlegen oder löschen soll, führt Oracle diese Anweisung im schnellen Arbeitsspeicher (SGA) durch und übernimmt diese Änderungen zeitversetzt in den Datendateien (datafiles). Dieses Vorgehen an sich ließe sich nicht mit den ACID Anforderung an relationale Datenbanken vereinbaren, da das RDBMS zu jederzeit sicherstellen muss, dass durchgeführte Transaktionen auch persistiert sind - selbst wenn das System im nächsten Moment durch einen Stromausfall oder einer gecrashten Platte ausfallen sollte. Oracle schreibt daher sämtliche Änderungen (DDL und ändernde DML) parallel in ein Transaktionsjournal, den so genannten Redo-Logs.

Diese Redo-Logs protokollieren sinngemäß, durch welche Operationen der Datenbestand der Datenbankdatei zu modifizieren ist, um den aktuellen Zustand im Arbeitsspeicher zu entsprechen. Eine Transaktion wird also erst gegenüber dem Client als abgeschlossen bestätigt (commit), wenn dessen Operationen in den Redo-Logs niedergeschrieben sind. Sollte es im nächsten Moment zum Ausfall kommen, kann beim Hochfahren des Datenbanksystems der Datenbestand im Arbeitsspeicher wiederhergestellt werden, indem die Datenbankdateien eingelesen und die ausstehenden Redo-Log-Einträge erneut abgearbeitet (redo) werden.

'''Was sind archivierte Transaktionsjournale (archivelogs)?'''
Die Redo-Logs sind zur Sicherstellung der Konsistenz einer Oracle Datenbank von entscheidender Bedeutung. Daher werden diese Dateien zeitgleich i.d.R. min. zweimal geschrieben. Hierbei sollten zwei verschiedene Speicher eingesetzt werden.

Sollte ein Journal beschädigt werden (z.B. weil das zugrunde liegende Dateisystem beschädigt wurde), kann Oracle mit der bzw. den verbleibenden Kopien die Fortsetzung des Betriebs sicherstellen. Die beiden Kopien werden im Oracle Terminologie Redo-Log-Gruppe bezeichnet. Für den Forensiker sind die Kopien also lediglich von Bedeutung, wenn der Verdacht im Raum steht, dass ein einzelne Redo-Log-Datei beschädigt wurde.

Die Transaktions-Journale werden in einem s.g. Ring-Speicher abgebildet. Konkret handelt es sich um min. drei Redo-Log-Gruppen, die abwechselnd (log switch) beschrieben werden. Es gibt eine aktuelle Redo-Log-Gruppe und außerdem aktive und inaktive Redo-Log-Gruppen. Aktuelle und aktive Redo-Log-Gruppen benötigt Oracle im Falle eines Ausfalls für eine Wiederherstellung (Instance Recovery). Die inaktive Redo-Log-Gruppe wartet lediglich auf die Verwendung nach dem log switch.

Sobald der Archive-Log-Modus aktiv ist, werden genutzte Redo-Logs nach einem log switch weggesichert. Sobald diese gesicherten Redo-Logs weggeschrieben wurden, spricht man anstelle von Redo-Logs von s.g. Archive-Logs.

Letztere erlauben es im laufenden Betrieb den kompletten Datenbestand der Oracle Datenbank atomar - als Transaktion für Transaktion - zu sichern. Das ist sogar möglich während das System online ist. Benötigt werden hierfür, neben den Control-Files - die hier aber nicht weiter erläutert werden - die Datenbankdateien (datafiles) und alle folgenden Redo-Logs, um Voll-, kommulative oder inkrementielle Backups zu erstellen. Derartige Backups sollen jedoch hier nicht weiter vertieft werden. Lediglich von dessen Existenz sollte ein Datenbank-Forensiker gehört haben.

'''Wie kann ich Oracle LogMiner forensisch nutzen?'''
Wenn ein Forensiker Zugang zu den redo- oder archivelogs erhält, kann er sämtliche Anweisungen der Vergangenheit, quasi soweit die Backups es erlauben, nachvollziehen und strukturiert aufarbeiten. Hierzu bietet Oracle PLSQL-Pakete (PLSQL steht im übrigen für procedural language/structured query language ;-) ) an, die wiederum im Verwaltungswerkzeug „Enterprise Manager“ in einer Weboberfläche angeboten werden.

Es ist auch möglich die Redo-Logs in Gänze oder per SQL gefiltert in eine Textdatei auszuleiten, um sie mit anderen Tools auszuwerten.
Es ist also möglich sämtliche unbeabsichtigten oder schädliche Systemmanipulationen (z.B. SQL-Injektions) auch dann nachzuvollziehen, wenn zuvor das Audit-Logging nicht aktiviert wurde. Letzteres arbeitet innerhalb der Datenbankinstanz und generiert eigene Strukturen auf Basis ausgewählter Operationen und erlauben einem Administrator wesentlich feingranularer einzustellen, welche Operationen protokolliert werden. Ferner bietet es insbesondere auch die Möglichkeit Abfragen (z.B. falls der Verdacht im Raum steht, Daten würden ausgespäht werden) nachzuvollziehen. Daher ist das Auditing aufgrund des LogMinings nicht obsolete! Jedoch ist es für den Forensiker nur dann von Interesse, wenn dieses (auf Verdacht) vor oder während eines Angriffs eingeschaltet wird. Dies ist in der Praxis oft nicht der Fall, da das Schreiben der Audit-Logs eben eigenes Transaktionsvolumen benötigt und damit die Performance des Gesamtsystems beeinträchtigen kann.

Letztlich ist es sogar möglich, anhand der Redo-Logs eines Fremdsystems Transaktionen nachzuvollziehen. Hierfür wird jedoch auch das s.g. Data-Dictionary des Quell-Systems benötigt, um etwa Benutzerkennungen oder Tabellen-Namen - die Oracle intern als kryptische ID-Referenz verwaltet - auflösen zu können, so dass wieder die eigentlichen Objektnamen (z.B. Benutzernamen oder Tabellennamen) erscheinen.

Wenn ein Angriff stattgefunden hat und klar ist, dass die Datenbank-Instanz betroffen ist, findet man über Session-Traces, AWR Reports oder andere Tools explorativ die bösartigen Objekte im System. Von diesen ausgehend, kann dann in den Redo-Logs rekonstruiert werden, wie diese dahin kamen und insbesondere wer diese wann und wo angelegt hat.

Das Oracle Datenbanksystem erlaubt es sogar, einzelne Anweisungen aus der Vergangenheit unwirksam zu machen. Wie weit dies jedoch in den Datenbestand der Gegenwart durchgereicht wird, ist von verschiedenen Faktoren abhängig, die hier nicht weiter betrachtet werden.

TOFILL

← Nächstältere Version		Version vom 22. Februar 2020, 15:40 Uhr
Zeile 4:		Zeile 4:

	'''Was sind Transaktionsjournale (redologs)?'''		'''Was sind Transaktionsjournale (redologs)?'''
	Sobald eine Oracle Datenbank Daten in ihrem Bestand modifizieren, anlegen oder löschen soll, führt Oracle diese Anweisung im schnellen Arbeitsspeicher (SGA) durch und übernimmt diese Änderungen zeitversetzt in den Datendateien (datafiles). Dieses Vorgehen an sich ließe sich nicht mit den ACID Anforderung an relationale Datenbanken vereinbaren, da das RDBMS zu jederzeit sicherstellen muss, dass durchgeführte Transaktionen auch persistiert sind - selbst wenn das System im nächsten Moment durch einen Stromausfall ~~oder einer gecrashten Platte~~ ausfallen sollte. Oracle schreibt daher sämtliche Änderungen (DDL und ändernde DML) parallel in ein Transaktionsjournal, den so genannten Redo-Logs.		Sobald eine Oracle Datenbank Daten in ihrem Bestand modifizieren, anlegen oder löschen soll, führt Oracle diese Anweisung im schnellen Arbeitsspeicher (SGA) durch und übernimmt diese Änderungen zeitversetzt in den Datendateien (datafiles). Dieses Vorgehen an sich ließe sich nicht mit den [https://de.wikipedia.org/wiki/ACID ACID] Anforderung an relationale Datenbanken vereinbaren, da das RDBMS zu jederzeit sicherstellen muss, dass durchgeführte Transaktionen auch persistiert sind - selbst wenn das System im nächsten Moment durch einen Stromausfall ausfallen sollte. Oracle schreibt daher sämtliche Änderungen (DDL und ändernde DML) parallel in ein Transaktionsjournal, den so genannten Redo-Logs.

	Diese Redo-Logs protokollieren sinngemäß, durch welche Operationen der Datenbestand der Datenbankdatei zu modifizieren ist, um den aktuellen Zustand im Arbeitsspeicher zu entsprechen. Eine Transaktion wird also erst gegenüber dem Client als abgeschlossen bestätigt (commit), wenn dessen Operationen in den Redo-Logs niedergeschrieben sind. Sollte es im nächsten Moment zum Ausfall kommen, kann beim Hochfahren des Datenbanksystems der Datenbestand im Arbeitsspeicher wiederhergestellt werden, indem die Datenbankdateien eingelesen und die ausstehenden Redo-Log-Einträge erneut abgearbeitet (redo) werden.		Diese Redo-Logs protokollieren sinngemäß, durch welche Operationen der Datenbestand der Datenbankdatei zu modifizieren ist, um den aktuellen Zustand im Arbeitsspeicher zu entsprechen. Eine Transaktion wird also erst gegenüber dem Client als abgeschlossen bestätigt (commit), wenn dessen Operationen in den Redo-Logs niedergeschrieben sind. Sollte es im nächsten Moment zum Ausfall kommen, kann beim Hochfahren des Datenbanksystems der Datenbestand im Arbeitsspeicher wiederhergestellt werden, indem die Datenbankdateien eingelesen und die ausstehenden Redo-Log-Einträge erneut abgearbeitet (redo) werden.
Zeile 13:		Zeile 13:
	Sollte ein Journal beschädigt werden (z.B. weil das zugrunde liegende Dateisystem beschädigt wurde), kann Oracle mit der bzw. den verbleibenden Kopien die Fortsetzung des Betriebs sicherstellen. Die beiden Kopien werden im Oracle Terminologie Redo-Log-Gruppe bezeichnet. Für den Forensiker sind die Kopien also lediglich von Bedeutung, wenn der Verdacht im Raum steht, dass ein einzelne Redo-Log-Datei beschädigt wurde.		Sollte ein Journal beschädigt werden (z.B. weil das zugrunde liegende Dateisystem beschädigt wurde), kann Oracle mit der bzw. den verbleibenden Kopien die Fortsetzung des Betriebs sicherstellen. Die beiden Kopien werden im Oracle Terminologie Redo-Log-Gruppe bezeichnet. Für den Forensiker sind die Kopien also lediglich von Bedeutung, wenn der Verdacht im Raum steht, dass ein einzelne Redo-Log-Datei beschädigt wurde.

	Die Transaktions-Journale werden in einem ~~s.g.~~ Ring-Speicher abgebildet. Konkret handelt es sich um min. drei Redo-Log-Gruppen, die abwechselnd (log switch) beschrieben werden. Es gibt eine aktuelle Redo-Log-Gruppe und außerdem aktive und inaktive Redo-Log-Gruppen. Aktuelle und aktive Redo-Log-Gruppen benötigt Oracle im Falle eines Ausfalls für eine Wiederherstellung (Instance Recovery). Die inaktive Redo-Log-Gruppe wartet lediglich auf die Verwendung nach dem log switch.		Die Transaktions-Journale werden in einem Ring-Speicher abgebildet. Konkret handelt es sich um min. zwei, i.d.R. drei Redo-Log-Gruppen, die abwechselnd (Der Übergang heißt "log switch") beschrieben werden. Es gibt eine aktuelle Redo-Log-Gruppe und außerdem aktive und inaktive Redo-Log-Gruppen. Aktuelle und aktive Redo-Log-Gruppen benötigt Oracle im Falle eines Ausfalls für eine Wiederherstellung (Instance Recovery). Die inaktive Redo-Log-Gruppe wartet lediglich auf die Verwendung nach dem log switch.

	Sobald der Archive-Log-Modus aktiv ist, werden genutzte Redo-Logs nach einem log switch weggesichert. Sobald diese gesicherten Redo-Logs weggeschrieben wurden, spricht man anstelle von Redo-Logs von s.g. Archive-Logs.		Sobald der Archive-Log-Modus aktiv ist, werden genutzte Redo-Logs nach einem log switch weggesichert. Sobald diese gesicherten Redo-Logs in ein spezielles "FRA" Verzeichnis (Fast Recovery Area) weggeschrieben wurden, spricht man anstelle von Redo-Logs von s.g. Archive-Logs.

	Letztere erlauben es im laufenden Betrieb den kompletten Datenbestand der Oracle Datenbank atomar - als Transaktion für Transaktion - zu sichern. Das ist sogar möglich während das System online ist. Benötigt werden hierfür, neben den Control-Files - die hier aber nicht weiter erläutert werden - die Datenbankdateien (datafiles) und alle folgenden Redo-Logs, um Voll-, kommulative oder inkrementielle Backups zu erstellen. Derartige Backups sollen jedoch hier nicht weiter vertieft werden. Lediglich von dessen Existenz sollte ein Datenbank-Forensiker gehört haben.		Letztere erlauben es im laufenden Betrieb den kompletten Datenbestand der Oracle Datenbank atomar - als Transaktion für Transaktion - zu sichern. Das ist sogar möglich während das System online ist. Benötigt werden hierfür, neben den Control-Files - die hier aber nicht weiter erläutert werden - die Datenbankdateien (datafiles) und alle folgenden Redo-Logs, um Voll-, kommulative oder inkrementielle Backups zu erstellen. Derartige Backups sollen jedoch hier nicht weiter vertieft werden. Lediglich von dessen Existenz sollte ein Datenbank-Forensiker gehört haben.

	'''Wie kann ich Oracle LogMiner forensisch nutzen?'''		'''Wie kann ich Oracle LogMiner forensisch nutzen?'''
	Wenn ein Forensiker Zugang zu den redo- oder archivelogs erhält, kann er sämtliche Anweisungen der Vergangenheit, quasi soweit die Backups es erlauben, nachvollziehen und strukturiert aufarbeiten. Hierzu bietet Oracle PLSQL-Pakete (PLSQL steht im übrigen für procedural language/structured query language ~~;-)~~ ) an, die wiederum im Verwaltungswerkzeug „Enterprise Manager“ in einer Weboberfläche angeboten werden.		Wenn ein Forensiker Zugang zu den redo- oder archivelogs erhält, kann er sämtliche Anweisungen der Vergangenheit, - quasi soweit die Backups es erlauben - nachvollziehen und strukturiert aufarbeiten. Hierzu bietet Oracle PLSQL-Pakete (PLSQL steht im übrigen für ''procedural'' language/structured query language ) an, die wiederum im Verwaltungswerkzeug „Enterprise Manager“ in einer Weboberfläche angeboten werden.

	Es ist auch möglich die Redo-Logs in Gänze oder per SQL gefiltert in eine Textdatei auszuleiten, um sie mit anderen Tools auszuwerten.		Es ist auch möglich die Redo-Logs in Gänze oder per SQL gefiltert in eine Textdatei auszuleiten, um sie mit anderen Tools auszuwerten.
Zeile 34:		Zeile 34:
	Beispiel:		Beispiel:
	[[Datei:ORACLE SQL DELETE FROM PROFESSOREN.png\|mini\|Abb.1: Löschen unliebsamer Professoren]]		[[Datei:ORACLE SQL DELETE FROM PROFESSOREN.png\|mini\|Abb.1: Löschen unliebsamer Professoren]]
	Um ein ungewolltes Verhalten einzuschleusen löscht ein "frustrierter Student" als Benutzer „DBUSER“ einige unliebsame Professoren aus der Datenbank. Über die folgende Übung mit dem LogMiner wird diese Manipulation dann offengelegt.		Um ein ungewolltes Verhalten einzuschleusen löscht ein "frustrierter Student" ;-) als Benutzer „DBUSER“ einige unliebsame Professoren aus der Datenbank. Über die folgende Übung mit dem LogMiner wird diese Manipulation dann offengelegt.
	<br clear="right"/>		<br clear="right"/>