Oracle DBMS – theoretisches Grundwissen

(Last Updated On: 5. September 2015)

Theoretisches Wissen über die Oracle Datenbank

Instanz und Datenbank

eine Oracle-Datenbank besteht im wesentlich aus der Datenbank an sich und der Oracle-Serverinstanz.

Die Oracle-Serverinstanz ist das Hauptprogramm, welches sozusagen die Anwendungsschicht des Oracle-Datenbankmanagementsystems darstellt. Das bedeutet, dass andere Programme und nutzer, die Daten von der eigentlichen Datenbank abrufen oder bearbeiten wollen, sich erst an diese Oracle-Instanz wenden müssen. Diese ist also der Serverdienst, der im Hintergrund läuft. Die Oracle-Instanz liegt im laufenden Betrieb, wie viele andere Serverdienste auch, im Arbeitsspeicher des Systems und wartet dort auf eingehende Verbindungen, die von den Nutzern angefragt werden.

Die Einstellungen der Oracle-Serverinstanz wird wie bei vielen anderen Serverdiensten auch in einer oder mehreren Konfigurationsdateien gespeichert – im Fachjargon auch Parameterdatei genannt. Die aprameterdateien werden vor dem Start einer Oracle-Instanz gelesen und dann auf die jeweilige Instanz angewendet.

Die eigentliche Datenbank symbolisiert die Datenhaltungsschicht des Systems. Die Datenbank liegt zum größten Teil auf der festplatte oder SSD des Systems. Dort werden die ganzen Daten, die letztendlich durch die Oracle-Serverinstanz abgefragt und bearbeitet werden sollen, hinterlegt.

Es gibt immer mindestens eine Oracle-Instanz für eine Oracle-Datenbank. man kann nicht mehrere Oracle-Datenbanken mit einer einzigen Oracle-Instanz verwalten. Damit unterscheidet sich Oracle sehr stark von anderen Datenbankmanagementsystemen wie beispeislweise MySQL, wo man mit einer einzigen Serverinstanz mehrere datenbanken verwalten kann.

Umgekehrt ist es aber möglich, dass sich mehrere Oracle-Instanzen um eine einzige Oracle-Datenbank kümmern, das nennt man dann ein Redundancy Array oder allgemein bekannt als Cluster. Dadurch wird die Performance-Last auf mehrere Instanzen aufgeteilt. Desweiteren ist es möglich, dass man eine instanz verwaltet, backupt oder wartet, während die andere weiterhin auf Clientanfragen reagiert und die Datenbank für Clients zur Verfügung stellt.

eine Transaktion

eine Transaktion fasst Datenänderungen, die voneinander abhängig sind, zusammen. Damit Sie das verstehen können, müssen Sie mit dem Begriff der relationalen Datenbanken vertraut sein. Wenn ein Benutzer einen Datensatz ändert, dann müssen in einer relationalen Datenbank Datensätze in verschiedenen Tabellen geändert werden, also nicht nur in einer einzigen – weil dei Tabellen zueinander in einer Beziehung stehen. Wenn ein alter mitarbeiter aus einem Unternehmen ausscheidet und ein neuer seine Aufgaben übernimmt, müssen bie allen Aufgaben, die dieser alte Mitarbeiter bearbeiteet hat, unter Umständen die Daten des neuen mitarbeiters als Verantwortlicher eingetragen werden. Deswegen müssen in mehreren verschiedenen Tabellen Änderungen erfolgen, so dass dies umgesetzt werden kann.

Es wäre fatal, wenn in einigen Tabellen die Änderungen schon erfolgt wären, und mittendrin schmiert die Oracle-Instanz ab. Nun haben Sie in einigen Tabellen den neuen Mitarbeiter und in einigen den alten Mitarbeiter drin stehen. Die von der Datenbank abhngigen Programme können die Daten nicht mehr richtig zuordnen und spucken mitunter Fehlermeldungen aus. Damit dies vermieden wird, gibt es Transkationen. Eine Transaktion fasst alle Änderungen in verschiedenen Tabellen zusammen, die zu einer bestimmten Änderung von Daten gehören. Erst, wenn alle Änderungen vollständig und erfolgreich durhcgeführt wurden, werden die Änderungen permanent übernommen. Geht zwischendrin etwas schief, bleiben alle Daten auf dem Stand vor der Transaktion, bis irgendwann bei einem erneuten Versuch alle Änderungen erfolgreich durchgeführt werden können. Somit werden Inkonsistenzen vermieden.

Und nicht nur das System kann solche Transaktionen automatisch auf diese Art und Weise zurücksetzen. Auch manuell können solche Transaktionen innerhalb einer Sitzung zurückgerollt werden. Wenn ihr Chef Ihnen sagt, dass Sei in der Datenbank einen Termin für 09:00 uhr in seinem Terminaklender um eine Stunde verschieben sollen, Sie 10:00 Uhr eintragen und der Chef Ihnen hinterherruft „Ach lassen Sie’s, es klappt doch mit 09:00 Uhr“, dann können sie manuell veranlassen, dass die Änderung rückgängig gemacht wird. Der Nutzer wird hierzu natürlich nicht die notwendigen Datenbank-Befehle eingeben, das macht für Ihn meist das Anwendungsprogramm, welches im Hintergrund mit der Oracle-Instanz zusammenarbeitet.

Die System Global Area

Die System Global Area (SGA) ist eine Art Datenspeicher im Arbeitsspeicher des Systems, der wichtige Dateien in diesem zwischenspeichert. Die Daten, die über das SGA im Arbeitsspeicher abgelegt werden, sind beispeislweise Metadatan doer Systeminfomrationen zur Datenbank, die somit nicht jedesmal von der Festplatte über die Datendateien gelesen werden müssen, was Zeit spart. Aber auch Daten aus der Datenbank, die immer wieder abgefragt werden, werden hier abgelegt und „gecached“, damit nicht dauernd zeitintensive Lesezugriffe auf die Festplatte stattfinden müssen. Die oracle-Datenbank speicher häufig abgefragte Datensätze auch „Datenbankblöcke“ oder „Zeilen“ einer Datenbank deswegen im Database Buffer Cache auf dem Arbeitsspeicher. Dabei erkennt die Oracle-Datenbank, auf welche Datenbankblöcke besondesr häufig zugegriffen wird und hält diese wesentlich länger im Arbeitsspeicher vor als andere, die nur für eine gewisse Zeitspanne gebraucht werden.

Aber auch die Redo Logs, die wir später noch kenennlernen werden, haben in der SGA ihr zu Hause.

Einige der Daten, die über das SGA im Arbeitsspeicher zwischengespeichert werden, werden auf die Festplatte geschrieben, sobald die Oracle-datenbank mal weniger stark belastet wird und daher Ressourcen frei sind, um nebenbei die Daten auf die Festplatte zu sichern. Das geschieht beispielsweise bei den Redo Logs, die wir später noch kennen lernen werden. Ebenfalls später kennen lernen werden wir noch den Shared Pool und die Dirty List, die sich ebenfalls in der SGA befinden.

2015-06-22_12h20_42

2015-06-22_12h32_29

Die System Global Area befindet sich wie bereits erwähnt im Arbeitsspeicher und gehört deshalb architektonisch zur oracle-Instanz, da sich diese ja im Arbeitsspeicher befindet.

OLAP und OLTP Datenbanken

Je nach Anwendungsszenario einer Datenbank unterschiedet man zwischen einer OLAP und einer OLTP-Datenbank. Dabei geht es um den Einsatzzweck der Datenbank. Je nach Einsatzzweck wird eine datenbank unterschiedlich ausgerichtet. Einen praxisorientierten, eifnach verständlichen Vergleich zwischen OLAP und OLTP-anwendungen und deren Datenbanken habe ich in meinem Post zu SAP Business Warehouse gegeben.

OLTP-Datenbanken haben eine hohe Transaktionsrate aus, deren Änderungen innerhalb einer Transkation aber klein sind. Das heißt: pro Transaktion müssen nur wenige Daten abgerufen und bearbeitet werden, es gibt jedoch viele dieser kleinen Datenänderungen. Das ist beispielsweise bei einer ERP-Software, in der ständig neue Kundenaufträge und Bestellungen bei Lieferanten eingearbeitet werden, der Fall.

OLAP-Datenbanken werden regelmäßig mit Daten befüllt. Diese Datenbestände werden allesamt abgerufen und analysiert. Es werden also in einem Schritt große Mengen an Daten abgerufen. Hier ist die regelmäßigkeit und Anzahl der Transaktionen also gering, deren Datenumfang aber sehr groß. Business intelligence Systeme sind beispielsweise Softwarelösungen, die von OLAP-Datenbanken Gebrauch machen.

Was bedeutet jetzt diese Einteilung genau? Nun, nehmen wir mal aus der oberen Erklärung das Beispiel des Database Buffers.

2015-06-22_12h32_29

Im Database Buffer cache liegen also Tabellenblöcke, also Zeilen, die sehr häufig abgefragt werden. Diese werden im Arbeitsspeicher vorgehalten, da sie von dort aus wesentlich schneller abgefragt werden können als von der Festplatte.

Je größer diese Tabellenblöcke, desto mehr Zeilen einer tabelle können vorgehalten werden. Mit einem größeren TAbellenblockals dem oben dargestellten könnten wir also statt zwei Zeilen alle vier Zeilen der Beispieltabelle im Arbeitsspeicher vorhalten. Bleibt die Größe der Tabellenblöcke so wie sie ist, müssen wir die beiden Zeilen für die Mtiarbeiter Gruber und Seidel in einen extra Tabellenblock laden, was dann so aussähe.

2015-06-22_12h45_30

Jetzt nehmen wir mal an, diese mitarbeiterdaten werden in einem ERP-System ab und zu mal wieder abgerufen, weil beispielsweise jemand im Urlaubskalender nachsehen will, ob der Kollege Meier im nächsten Monat Urlaub hat, dann wird vielleicht das Urlaubskonto des Kollegen Gruber aktualisiert, der Kollege Seidel trägt Überstunden vom letzten Samstag ein usw. Hier macht es mehr Sinn, wenn wir die vier Zeilen in zwei Tabellenblöcke aufteilen. Denn wenn wir die vier Zeilen auf zwei Tabellenblöcke aufteilen, dann müssen bei jeder Abfrage nicht alle vier, sondern nur jeweils zwei Zeilen vom Arbeitsspeicher geladen werden, was unter Umständen stark vereinfach ausgedrückt jedes mal halb so lang dauert, als wenn wir alle vier Zeilen aus dem Arbeitsspeicher abrufen müssten. Logisch, oder?

Jetzt nehmen wir aber mal an, diese Mitarbeiterdatensätze sind mit einer anderen Tabelle in Verbindung, welche die Umsätze dieser mitarbeiter im letzten Quartal abgespeichert hat, verbunden. Diese leigt ebenfalls im Database Buffer cache. Ebenso liegt eien Tabelle im Cache, welche die mitarbeiter verschiedenen Filialen zuordnet.

2015-06-22_12h55_27

 

In unserem Business intelligence System sind jetzt diese Daten drin und wir wollen analysieren, welche Filiale im letzten Quartal den größten Umsatz gemacht hat. Die Analyse läuft folgendermaßen: Aus dem Database Buffer cache wird die Tabelle mti den mitarbeiterumsätzen genommen. Dei erste Zeile wird gelesen. Damit die vollständigen Daten zum mitarbeiter Gruber in der resten Zeile angezeigt werden kann, muss erst der obere Tabellenblock gelesen werden und danach der Tabellenblock rechts unten mit den Filialen. In der zweitene Tabelle muss der untere Tabellenblock geladen werden, in der dritten Zeiel wieder der obere Tabellenblock. Wenn nun hingegen die beiden Tabellenblöcke für die Mitarbeiter zusammengelegt werden,a lso alle vier Zeilen in einem Tabellenblock, müssten nur ein einziges mal die drei nun jeweils vierzeiligen Tabellenblöcke geladen werden und die analyse könnte komplett durchgeführt werden. Der Unterschied ist hier noch nicht wirklich groß – wenn Sie mitgezählt haben stellen Sie fest, dass Sie mit der ersten Varainten insgesamt acht Mitarbeiterzeilen vom Arbeitsspeicher laden und in der zweiten Variante einmalig die vier mitarbeiterzeilen laden müssen. Außerdem hätten Sie auch in der ersten Variante nur vier mitarbeiterzeilen laden müssen, wenn die Mitarbeiter in der umsatztabelle in der optimalen Reihenfolge gestanden hätten, also nach Gruber kommt Seidel und danach kommen Meier und Huber. Aber sie merken: je komplexer die Datenanalysen werden, desto eher lohnen sich größere Datenbankblöcke im SGA des Systems.

Und genau dies ist der Unterschied, der den Einsatzzweck von OLTP-Datenbanken und OLAP-Datenbanken ausmacht. Die Größe der tabellenblöcke macht im wesentlichen den Einsatzzweck der Datenbanken aus, für den sie am besten geeignet sind.

Die Dirty List

Wir haben weiter oben das Konzept des Database Buffer Caches kennengelernt, in welchem wie nun bereits bekannt verschiedene Datensätze der Datenbank im Arbeitsspeicher vorrätig gehalten werden. Je anchdem, ob wir ein OLTP oder OLAP-System haben, wählen wir die Größe dieser Tabellenblöcke unterschiedlich. So weit so gut.

Nicht nur die Lesevorgänge, sondern auch die Schreibvorgänge in Datensätze werden zunächst im Arbeitsspeicher hinterlegt. Dazu werden die im Arbeitsspeicher hinterlegten Tabellenblöcke abgeändert. Das heißt für einen bestimmten Zeitraum befinden sich im Database Buffer cache und somit im Arbeitsspeciher die aktualisierten Datensätze, während auf der festplatte noch die veralteten Datensätze drin stehen.

Irgendwann müssen diese geänderten Datensätze auf die Festplatte geschrieben werden, denn wenn irgendwann der Server heruntergefahren wird oder der Strom weg ist, gehen die Änderungen im Arbeitsspeicher verloren.

Die Dirty List enthält die Adressen der Tabellenblöcke im Database Buffer Cache, die geänderte datensätze enthalten. Wenn die Oracle-Instanz sich dazu entscheidet, geänderte Datensätze vom Arbeitsspeicher auf die Festplatte zu schreiben (etwa weil gerade wenig Last auf dem System ist), dann nimmt die Oracle-Instanz die Dirty List und guckt nach den Tabellenblöcken, die geändert wurden. Diese tbaellenblöcke werden dann auf die Festplatte geschrieben. Auch hier spielt die Größte der tabellenblöcke, die wir in der Differenzierung zwischen OLTP und OLAP besprochen haben, wieder eine Rolle – denn je größer die Tabellenblöcke, desto mehr muss geschrieben werden, obwohl sich mitunter weniger Zeilen geändert haben, als im Tabellenblock vorhanden sind.

 Redo Logs

Wir haben ja jetzt weiter oben gelernt, dass Änderungen in der datenbank erst im Arbeitsspeicher, genauer gesagt im Database Buffer Cache, durchgeführt werden, beovr sie auf die festplatte geschrieben werden. In er Zeit, in der diese Änderungen noch nicht auf der festplatte geschrieben sind, könnte ja theoretisch ein Stromausfall oder ähnliches passieren, oder enifach nur die Oracle-Instanz gestoppt werden, so dass die Änderungen im Arbeitsspeicher verloren gehen. Um dies weitestgehend zu verhindern, werden Änderungen zusätzlich in redo Logs protokolliert. Für jede datensatzänderung werden die blockadresse des geänderten Tabellenblocks, dessen neuer wert, der Zeitstempel des Änderungszeitpunkts und eine Systemänderungsnummer gespeichert.

Die Redo Logs selbst liegen jedoch wiederum im Arbeitsspeicher, nämlich im Redo Log Buffer. was ist also der Vorteil? Der sogenannte Redo-log-writer schreibt permanentden inhalt des Redo-Log-Buffers in sogenannte Redo-log-Dateien auf die festplatte. Sie fragen sich vielleicht, warum man denn dann nicht gleich die Änderungen vom Daatbase Buffer cache auf die Datendateien der festplatte schreibt? Dazu gibt es mehrere Gründe

  • es geht wesentlich schneller. Um eine Redo-Log-Datei zu schreiben, welche die aktuelle Änderung im Database buffer Cache an einem Tabellenblock enthält, muss nur die Redolog-Datei im Dateisystem gesucht, geöffnet und beschrieben werden. Um die Änderung in die datenbankdateien zu schreiben, muss diese gesucht, geöffnet, gelesen, in dieser nach der zugehörigen Tabelle gesucht werden, die Tabelle eingelesen werden, in der tabelle der zugehörige Datensatz gelesen werden und der Datensatz neu geschrieben werden. Das heißt: mit Redo-Logs hat man die änderungen an einem Datensatz wesentlich schneller auf der festplatte als über die Datendateien und verkleinert somit wesentlich das Zeitfenster, in dem etwas schief gehen kann, weil das System eventuell abstürzen könnte. Desweiteren ist die Redo-Log-Datei eine einzige zusammenhänge Datei, wohingegen die Datenbankdateien mitunter mehrere Dateien sind, die sich an unterschiedlciehn Stellena fu der festplatte befinden können, so dass der Schreib-/Lesekopf der festplatte hier öfter hin und her springen muss.
  • Es muss nur geschrieben und weniger gelesen werden. Wie oben bereits erklärt, muss beim Speichern von Änderungen in die Datenbankdateien diese erst gelesen und analysiert werden, um die Änderungen in dei richtige Tabelle zu schreiben. bei der Redo-Log Datei muss fast gar nichts gelesen, sondern nur geschrieben werden. Das erhöht die Performance dieser Schreibvorgänge, weil die Köpfe der Festplatten nicht erst den beschriebenen Bereich einer platte lesen und dann zu eienm unbeschriebenen Bereich springen und diesen beschreiben müssen
  • Da wie bereits erwähnt die Performance dieses Schreibvorgangs der Redo-logs besser ist als beim Schreiben in die Datenbankdateien, können die Redo-Logs ohne probleme auch geschrieben werden, wenn das System derzeit belastet wird
  • Wie bereits beschrieben, werden bei einer Änderung an einem Tabellenblcok im DAtabase Buffer Cache nicht nur die Änderungen, sondern der geasmte Tabellenblock aus dem arbeitsspeicher neu auf die Festplatte geschrieben.In den Redo-logs hingegen werden nur die Änderungen an den Tabellenblöcken geschrieben, nämlich der SQL-Code der zu dieser Änderung geführt hat. Das führt dazu, dass man merhere Änderungen an ein und demselben Tabellenblock über einen längeren Zeitraum sammeln kann und sie erst später über den Database Buffer Cache vom Arbeitsspeciher auf die Festpaltte speichern muss und die Änderungen an den Tabellenköpfen trotzdem über die Redo-Logs ständig auf der Festplatte mitschreiben kann. Das führt dazu, dass nicht so oft der überflüssige, gleichbleibende Anteil an Daten in den Tabellenblöcken immer wieder neu auf die festplatte geschrieben und von dort weider neu in de Arbeitsspeicher geladen werden muss.
  • Man kann die Schreib- und Leseperformance mehrerer Datenträger sinnvoll kombinieren. So kann ein Datenträger die RedoLogs schreiben, während der andere Datenträger die abgefragten Daten aus den Datenbankdateien liest.

Wie weiter oben im Theoriekapitel schon gelernt, speichern RedoLogs Änderungen an der datenbank, bevor diese in die Datendateien auf der festplatte geschribeen werden. Die Änderungen bleiben so lange in den Redo-Logs, bis ein sogeannnter Checkpoint dazu führt, dass die Änderungen in die Datendateien geschrieben und aus den RedoLogs gelöscht werden. Das sequentielle Ablegen der Änderungen in den RedoLogs passiert wesentlich schneller als das sofortige Ablegen in den Datendateien zustande klommen würden. Dies ist gut für die Performance und verkürzt auch den Zeitraum, in dem Änderungen an der Datenbank während des schreibvorgangs verloren gehen können, wenn das System mal abstürzt. Die Oracle-Datenbank wählt dann selbständig einen geeigneten Zeitpunkt für einen Checkpoint, in dem es dann die Änderungen in die Datendateien schreibt. Stürzt das System währenddessen ab, gibt es immer noch die RedoLogs, aus denen die Änderungen wiedergewonnen werden, sobald man das System neu startet. Danach kann ein erneuter Versuch unternommen werden, die Änderungen in den RedoLogs in die Datendateien zu schreiben.

Soweit so gut. Jedoch existiert die Gefahr, dass die Änderungen verloren gehen, wenn mit den RedoLogs etwas passiert. Stellen Sei sich vor, Ihr RedoLog enthält zurzeit über 500 geänderte Datensätze, die noch nicht in die Datendateien und somit noch nicht fest in die Datenbank geschrieben wurden. Wenn jetzt das RedoLog irgendwie aus versehen durch einen Datenfehler auf dem Datenträger korrupt oder gelöscht wird, haben Sie jede menge Transaktionen verloren.

Eine erste Maßnahme, um diesen Verlust zu verhindern ist, zwei Dateien von RedoLogs parallel schreiben zu lassen. Das bedeuetet, es wird zunächst ein REdoLog geschrieben, und nachdem der Schreibvorgang für dieses RedoLog abgearbeitet wurde, wird eine Spiegelung angelegt. Wenn nun eine der beiden RedoLog-Dateien beschädigt wird, ist immer noch die jeweils andere Version vorhanden. Erkennt die Oracle-Instanz, dass eine der beiden RedoLog-Dateien korrupt ist, wird sofort aus der noch funktionstüchtigen eine erneute Spiegelung erzeugt. Wird nun erneut eine Änderung an der Datenbank durchgefürht, beispeislweise ein weiterer Datensatz geänder,t dann wird zunächst das eine RedoLog aktualisiert und erst wenn der Schreibvorgang für dieses RedoLog abgeschlossen und die Datei weiterhin lesbar ist, wird die Änderung auf die zweite RedoLog-Datei übernommen. So geht im Fall der fälle, beispieslweise wenn das System während des Schrebivorgangs eines RedoLogs abstürzt, immer nur eine geringe Anzahl von Transaktionen verloren, da immer eine der beiden RedoLog-Versionen aktuell nicht beschrieben wird und unbeschädigt bleibt. Der Oralce Arhcvieurngsprozess kümmert sich darum, dass immer die gerade nicht beschriebene RedoLog-Datei in ein Archvierungsverzeichnis geschrieben wird, damti immer ein Backup der redoLogs vorhanden ist, auch wenn das System abstürzt.

Beim Anlegen einer RedoLog-Datei müssen Sie immer deren Größe angeben. Diese Entscheidung sollten Sie mit sorgfalt wählen, denn jedesmal, wenn eine RedoLog-Datei voll ist, wird ein Checkpoint initiiert und die Änderungen werden auf die Datendateien auf der Festplatte geschrieben, damit das RedoLog wieder geleert werden kann. Wenn sie die datei groß wählen, haben Sie seltener checkpoints, was dazu führt, dass ihr System bei einer hohen Transaktionslast stabiler läuft. Dafür dauert das Lesen der RedoLogs beim Systemstart länger als das Lesen der Datendateien, was heißt dass ihre Oracle-Instanz länger zum Starten braucht. Außerdem haben Sie ein höheres Risiko für Datenverlust, wenn einmal aus welchem Grund auch immer sämtliche Redo-Log-Gruppen verloren gehen würden. je größer die REdoLog-Gruppe, desto mehr Transaktion enthält sie und desto mehr Transaktionen gehen dann auch verloren.

Nun haben wir zwei REdo-log-Dateien, die in einer Gruppe wechselseitig geschrieben und archiviert werden. Die RedoLog-Datei, die gerade nicht beschrieben wird, wird archiviert, bevor Sie die Änderungen der neu beschriebenen Datei übernimmt. Diese beiden Dateien sollten auf jeweils unterschiedlichen Datenträgern liegen, so dass der Absturz eines Datenträgers nicht dazu führt, dass die Mirror-kopie des RedoLogs ebenfalls abhanden kommt. Desweiteren verbessert dies die Perforamnce, da ein Datenträger mit dem Archivieren des einen RedoLogs und ein anderer nur mit dem schreiben des RedoLogs beschäftigt ist.

Als zweite Maßnhame erstellen wir nun mehrere solcher Zweiergruppen aus Redo-Log-Dateien, die jeweils wiederum auf verschiedneen Datenträgern liegen. Eine optimale konfiguration sieht also so aus. Dadurch ermöglichen wir, dass gerade eine redolog gruppe im wechsel geschrieben werden kann (wie wir es oben bereits erälutert haben), während ältere redologs in einer anderen gruppe gerade in die datendateien weggesichert werden, weil die Dateien voll sind oder aus einem anderen Grund ein Checkpoint ausgelöst wurde.

2015-06-05_12h16_25

Sie können sich beispielsweise vorstellen, dass gerade die Gruppe aus G12m1.dbf und G12m2.dbf im Wechsel mit aktuellen Änderungen in den Tabellenblöcken beschrieben wird, während die RedoLogGruppe bestehend aus G11m1.dbf und G11m2.dbf gerade in die datenbankdateien geschrieben werden, weil sie voll gelaufen sind.

Hier, ohne sie abschrecken zu wollen, ein bisschen Praxis, falls Sie zu diesem Beitrag zurückkehren:

Sie können sich auf Ihrem System ansehen, wie der Status der Redologs ist

select group#, sequence#, bytes, status from v$log;

Die Speciherorte der Lgofiles kreigen Sien über die Tabelle V$logfile

Neue Redologgruppen fügen Sie foglendermaßen hinzu

alter database add logfile group 4 '/volume1/redo_4_1.log' SIZE 50M;

Und eine Datei zu einer Redo-Log-Gruppe können Sie so hinzufügen

alter database add logfile member '/volume2/redo_4_2.log' to group 4;

Den Speciherort eines Redologs ändern Sei foglendermaßen

alter database rename file '/oracle/oracle/product/<version>/oradata/orcl/redo01log' to '/volume1/redo_1_1.log';

Diese Datei darf aber gerade nicht in Benutzung sein, was Sie wie weiter oben bereits erwähnt über die tabelle V$log abfragen können. Desweiterne msüsen Sei die Datei auf Betirebssytemebene noch an den neuen Bestimmungsort kopieren und die zugriffsrechte richtig setzen.

Checkpoint

Wie bereits wieter oben schon erklärt führt ein Checkpoint dazu, dass die Änderungen an den Tabellenblöcken, die sich im Arbeitsspeicher befinden, in die Datenbankdateien geschrieben werden. Dabei bevorzugt der sogeannnte Database Writer prozess zunächst, die Änderungen aus dem Database Buffer Cache in die datenbankdateien zu schreiben, indem er die Dirty List zu Hilfe nimmt. Ist die Dirty List leer oder ist die Oracle-Instanz zuvor abgestürzt, bedient sich der Database Writer der Redo-Logs, die wenn schon nicht im Redo-Log-Puffer, dann aber als Redo-Log-Dateien auf der festplatte vorhanden sein sollten.

Ein Checkpoint kann zum einen manuell durch den User ausgeführt werden, das werden wir in der Praxis aber nru sehr sehr selten veranlassen.

Auf jeden Fall MUSS ein Checkpoint erfolgen, wenn alle Redo-Log-Dateien vollgeschrieben sind und wenn jetzt als nächstes damit begonnen werden würde, eine vollgeschriebene Redo-Log-Datei neu zu überschreiben. Deswegen initiiert die Oracle-Instanz zu einem solchen Zeitpunkt zwanghaft einen Checkpoint.

Immer, wenn ein Checkpoint dazu führt, dass Änderungen in die datnebankdateien geschrieben werden, wird die sogenannte System Change Number der letzten Änderung in die header der Datenbankdateien und in die Kontrolldatei schreibt. Somit weiß die Oralce-Instanz immer, auf welchem Stand sich die Datenbank gerade befindet und somit wird beispielsweise verhindert, dass veraltete Redo-Logs, die aus Versehen durch einen Admnistrator zurückkopiert werden, erneut in die datenbank geschrieben werden.

Commit

Ein Commit ist nicht zu verwechseln mit einem Checkpoint. Ein Commit wird jedesmal automatisch ausgeführt, sobald eine Transaktion abgeschlossen wurde. Nachdem eien Transaktion abgeschlossen wurde sorgt ein Commit dafür, dass die Änderungen an den Daten, die nach einer Transaktion in den Redo Log Buffer geschrieben werden, in die Redo Log Files auf die Festplatte geschrieben werden, so dass die Änderungen bei einem Systemabsturz nicht verloren gehen und aus den Redo Log Files wiederhergestellt werden können.

Der Unterschied ist also: Ein Checkpoint führt dazu, dass die Tabellenblöcke aus dem Databsae Buffer Cache in die Datenbankdateien auf der festplatte geschrieben werden, und ein Commit führt dazu, dass die Änderungen im Redo Log Buffer in die Redo Log Files geschrieben werden. Ein commit wird wesentlich häufiger ausgelöst als ein Checkpoint und soll dazu führen, dass Änderungen am Datenbestand der datenbank so früh wie möglich ihren platz auf die festplatte finden, ohne dabei dei Performance des Systems großartig einzuschränken.

Wie auch einen Checkpoint kann man einen Commit manuell über die KOmmandozeile auslösen, indem man einfach das SQL*Plus-Kommando commit eingibt.

Ein Schreiben von Änderungen in die Online-Redo-Log Dateien passiert standardmäßig immer:

  • wenn ein Commit automatisch ausgeführt wird (weil eine Transaktion abgeschlossen sit und in einer Redo Log Datei festgehalten werden)
  • ein Commit manuell ausgeführt wurde
  • der DBWR Blöcke vom Datenpuffer in die Datendateien schreibt
  • der Puffer zu 30% gefüllt ist
  • ein Zeitraum von drei Sekunden vergangen ist

Das Data Dictionary

Das Data Dictionary ist eine Sammlung von Tabellen und Ansichten (Views), die die Datenbank beschreiben. Das data Dictionary speichert die Metadaten der Datenbank, beschreibt also verschiedene Eigenschaften der Datenbank.  Das Data dictionary wird als Datendatei auf der festplatte gespeichert.

Tablespaces

Da die Daten der Datenbank letztendlich auf einem Datenträger wie einer Festplatte gespeichert werdne, kann es wie bei allen anderen Datena cuh zu Fragmentierung kommen, die zu Performanceienbußen führt. Es wäre ideal, wenn die daten eienr tabelle hintereinander auf einem speziellen Bereich eines datenträgers gepecihert wrüden. Damti das funktoniert, muss ein bestimmter Bereich afu einer platte dafür reserviert werden – und man muss dazu im voraus wissen, wie groß dieser Bereich auf der platte ungefähr sein wird. Es aht sich in der Praxis bewährt, für jede Tabelle einen solchen paltz zu reservieren, was heißt, dass man für jede Tabelle ungefähr deren Größe wissen muss. is tder Platz zu klein bewertet, kann man irgendwann keine neuen Daten mehr speichern. istn er groß zu bewertet, dauert es länger, bis Daten abgerufen und aktualsieirt werden können.

Ein Tablespace ist KEINE Datei, die für das Betriebssystem sichtbar ist. Ein Tablespace ist ein logischer container für Datenbankdateien. Ein Tablespace existiert nicht auf dem Dateisystem, sondern innerhalb des Data Dictionarys. Ein Tablespace sortiert also Datendateien nach bestimmten Kriterien, um wie oben angesprochen eine bessere Performance zu gewährleisten, aber auch eine einfachere Verwaltung verschiedener Datendateien. Damit ist es beispeilsweise möglich, den Tablespace, der anwendungskritische Daten trägt, auf einem anderen, schnelleren Datenträger zu speichern als die Datendateien, welche System-metainformationen enthalten, die weniger oft abgefragt werden. Dank dem Konzept der Tablespaces müssen die Datendateien einer Oracle-Datenbank also nicht zusammen innerhalb des selben Ordners oder datenträgers liegen, sondern können verstreut sein.

Ein Tablespace kann ein oder mehrere Datendateien umfassen, jedoch kann eine Datendatei immer nur zu maximal einem Tablespace gehören.

Deswegen hat Oracle die sogeannnten Tabelspaces eingeführt. Für wachsende Tabellen werden dynamisch neue Bereiche angefordert, wenn der reservierte Bereich auf einer Festplatte zu klein zu werden droht. Desweiteren können Datenbank dateien über mehrere datenträger hinweg gebündelt werden, so dass eine Datenbank über mehrere Datenträger hinweg wachsen kann. Wird der speicherplatz einmal knapp, kann einfach ein zustäzlicher Datenträger hinzugefügt werden. Desweiteren können einzelne Tabellen ohne großen  Aufwand gesichert werden, ohne dass gleich ein gesamtes Datenbankbackup durcgeführt werden muss, welches unter Umständen wesentlcih länger dauert. Alle vorhandenen Tabelspaces werden im oracle Data Dictionary gespeichert. sie können abgerufen werden über

SQL>select * from user_tablespaces;

Mit folgender Abrage kann man feststellen, welche Datenbankdateien zu welchem Tablespace gehören.

SQL>select file_name, tablespace_name, bytes, blcoks from dba_data_files;

Neben der manuellen Verwlatung der tablespaces durhc den Administrator kann man auch sogenannte Dictionary amanged Tabelspaces erstellen, die halbautomatisch durch das Oracle Data Dictionary verwaltet werden. Desweiteren kann die Oralce Instanz selsbt die Tablespaces verwalten, das nennt man dann Locally amanged Tablespaces. Diese letzte Option ist performante,r weil Änderungen an der Datenbank nicht gleichzeitig zu Änderungen am Data dictionary führen.

sie können einen Tabelspace, wenn sein platz droht voll zu werden, entweder manuell vergrößern

alter database datafile '<dateiname>.dbf' resize 1000M;

oder alternativ automatisch durch das DBMS selber vergörßern lassen.

alter database datafile '<dateiname>.dbf' autoextent on;
alter database datafile '<dateianem.dbf>' autoextent unlimited;
alter database datafile '<dateiname>.dbf' autoextend maxisze(20M);

Der nachteil bei autoextent ist, dann wenn Sie wie oben die unbegrenzte erweiterung des tablespaces zulassen, dass das DBMS den TAbelspaces so lange vergrößern kann, bis die Festplatte vollgeschrieben ist. Dadurch legen Sie dann ihr System lahm. Deswegen müssen Sie immer wieder den freien Speicherplatz auf der Festplatte im Blick haben, wenn Sie das autoextent-Feature anschalten.

Als letzte Alterantive können Sie einen Tablespace vergröern, indem sie ihm zusätzliche Datendateien zuordnen.

alter tablespace users
add datafile '<dateiname>.dbf' size 700M;

Einem Tablespace kann theoretisch keine einzige Tabelle, in der Praxis jedoch immer eine oder mehrere Tabellen zugeordnet sein. sie können acuh nachträglich neue Tabellen einem bestehenden Tabelspace zuweisen. Wie wir bereits geklrät haben, werden die Daten in einem tablespace hintereinader auf einem reservierten Speichersegment auf der festplatte geschrieben, damit kenie Formatierungauftritt. Ein reserviertes Segment nennt man auch Extent. Die extents werden zwar hintereinander auf die Festplatte geschrieben werden, können aber auf mehrere .dbf-Dateien im Dateisystem verstreut sein. Wenn sie einen TAbelspace das erste mal anlegen, weißen Sie diesem einen sogeannnten Basis-Extent zu. Dieser sollte idealerweise genau die Größe der tabellen haben, die auf diesem Tabelsapce leigen. Das bedeutet, es gibt nciht zu wenig, aber auch nicht zu viel Speicherplatz, der dem Extent zugeordnet wurde. Diesen basis-Extent können Sie bei einer stetig wachsenden TAbelle um weitere Next-Extents vergrößern, immer wieder, bis theoretisch die Festplatte voll ist, auf welcher der Tablespace liegt.

In den bisherigen Varainten wird die Größe der tabelspaces über das Data Dictionary verwaltet. Jedesmal, wenn Sie einen Tablsepace verändern, wird das Data Dictionary mit belastet. Wie wir aber gelernt haben, ist es auch möglich, einen Locally Managed Tablespace anzulegen. mit folgendem Statement erstellen Sie beispielsweise einen LMTS mit Ausgangsgröeß 100 MB, , der automatishc durhc das system vergörßert wird und maximal auf 500 MB anwachsen kann.

create tablespace user_m
datafile '<dateiname>.dbf' size 100M 
autoextend on maxsize 500M
extent management local autoallocate;

Nun wird die Größe des Tablespaces nciht mehr im Data Dictionary, sondern lokal innerhalb der Datendateien verwaltet.

System Tablespace

Enthält das Data Dictionary sowie Performance Management Info und Views. Dieser Tablespace muss dauerhaft online sein, damit das system läuft.

SYSAUX Tablespace

Zusätzlicher Tablespace zu SYSTEM, der zusätzliche informationen enthält. wrude vom System-Tablespace abgespalten, um die Last auf den System-Tablespace zu verringern.

USERS tablespace

Enthält Userobjekte und Userdaten

TEMP Tablespace

Speichert Ergebnisse von Abfragen zwischen, besonders bei Queries, die mittels ORDER BY-Clause sortiert werden sollen.

Undo-Tablespace

Sie haben weiter oben bereits gelernt, dass die Oracle-Datenbank Änderungen an den Daten zunächst im Arbeitsspeicher lagert und in From von REdo-Logs sichert, um Sie später auf die Datenbankdateien zu schreiben. Dabei verfolgt oracle einen optimistschen Ansatz. Das heißt Oracle beginnt bereits damit, die geänderten Daten schon als Redo-Log oder ganz in die datenbankdateien zu schreiben, bevor die eigentliche Transaktion mit einem COMMIT abgeschlossen ist. Das heißt, die Dateien werden bereits geändert, obwohl die Transaktion aus irgendeinem Grund eventuell noch abgebrochen werden kann, weil beispielsweise ein anderer Datenbankbenutzer gerade am selben Datensatz arbeitet. Für den Fall, das sowas passiert, schreibt Oracle sogenante Undo-Einträge in einen Undo-Tablespace. Dieser ermöglicht es, im Falle einer gescheiterten Transaktion die Datensätze wieder auf den ursprungszustand zurückzufürhen. Der optimistische Ansatz von Oracle lohnt sich, weil der Großteil der Transkation erfolgreich ausgeht und dadurch mit diesem Ansatz performance gewonnen werden kann. im Detail funktioniert das so

Ändert ein Anwendner einen Datensatz, wird von diesem im Vrofeld eine kopie des Tabellenblockes im Databse Buffer cache angelegt, bevor die Änderungen durch eien Transaktion initiiert wird. Nach der Änderung befinden sich für eien gewisse Zeit einmal der Tabellenblock, der gerade durch die Transaktion geändert wird, und einmal der ursprungszustand im Database Buffer cache.

Solange die Transaktion zum Ändern des Datensatzes noch nicht abgeschlossen ist, greifen die anderen Benutzer noch auf die Kopie des ursprungszustandes zu, dem sogenannten Before-Image. Sie sehen also noch den alten Wert des Datensatzes, bis die Transkation zum Ändern durch ein COMMIT abgeschlossen wird.

Das Before-Image wird aber nicht nur gebraucht, falls die Transaktion an sich fehlschlägt, sondern wird auch gebraucht, falls der user selbst seine Transaktion rückgängig machen will, weil er etwas falsches eingegeben oder geändert hat, auch Rollback genannt. Solange das Before-Image noch existiert, kann die Oracle-Instanz und somit auch der nutzer die transaktion wieder rückgängig machen.

Genau wie die Änerungen an den Tabellenköpfen werden auch die Before-Images regelmäßig ausd em Arbeitsspeicher auf einen festgelegten Tablespace auf die festplatte geschrieben, damit sie nicht gleich verloren gehen, wenn die Oracle-Instanz einmal abstürzt. Das Before-image wird dabei in den sogenannten undo-tablespace geschrieben.

SAP-spezifische Tablespaces

Da sich dieser Blog stark mit der Administration von SAP-systemen beschäftigt, werden wir noch ein wenig auf SAp-spezifische Tablespaces eingehen.

PSAPTEMP

Temporärer Tablespalce der beispielsweise Sortieroperationen enthält

PSAPROLL oder PSAPUNDO

Tablespace für rollback-operationen.

PSAP<SchemaID>

tablespace für alle SAP-objekte udn Tabellen (ABAP)

PSAP<SchemaID>DB

Tablespace für alle SAP-objekte und Tabellen (java)

PSAP<SchemaID>USR

Tablespace für alle kundeneigenen objekte und tabellen

PSAP<SchemaID><REL>

Tablespace für alle Objekte und Daten (ABAP), die von der verwendeten SAP-produktversion abhängig sind.

Datenverteilung

aus dem bereits vermittelten Wissen ist ersichtlich, dass die verwendung von RAID-levels, die bei schreibintensiven Umgebungen zu einem Performance-Bottleneck werden können, inakzeptabel ist. Deswegen ist es eine absolute Sünde, die zugriffshäufigen bestandteile von Oracle mit den RAID-Levels 3, 4 oder 5 zu betreiben,. ebenso wie die Verwendung von Software-RAID im allgemeinen.

Ebenso haben wir bereits weiter oben abgesteckt, dass zwe aufeinanderfolgende Redo-Log-Gruppen unbedingt auf verschiedenen Plattenbereichen liegen sollten. Ebenso sollten die beiden Mitglieder einer Redo-Log-Gruppe auf verschiedenen plattenbereichen liegen.

Desweiteren sollten die Datendateien und die Redo Logs ebenso auf verschiedenen Plattenbereichen liegen, so dass bei einem Checkpoint die Schreib- und Leseperformance der Redo-Logs unangetastet bleibt. Sie soltlen desweiterne nicht mit anderen sehr ändeurngsintensiven Teilen der Datenbank zusammen auf dem selben plattenbereich vermischt werdne, etwa mit Rollback-, Undo- oder temporären Tablespaces der Datenbank.

Für die Logs sollte immer ein RAID 1 verwendet werden.

Das führt uns ungefähr zu folgender Aufteilung.

2015-08-06_17h31_48

Redo Log Dateien bekommen eine eindeutige Log Sequence Number, welche auch gleichzeitig festlegt, in welcher Reihenfolge die Redo Log Dateien beschrieben werden, falls die Vorgänger-Redologdatei vollgeschrieben wurde.

Instanz-Recovery

Wollen wir mal zusammen in der Theorie durchgehen was passiert, wenn eine Oracle-Instanz abstürzt und danach wieder neu gestartet wird? Wenn eine oracle-Isntaz abstürzt müssen alle änderungen, die beim Absturz im Datbsae buffer cache standen, erst noch auf die Festplatte übertragen werden. DAs geschieht, wie wir ja bereits wisen, über die redo logs. Der hierzu nowtendige Recovery prozess wird bei jedem Oracle-instanz-Neustart automatisch ausgeführt.

Alle Änderungen in den Redo-Log-Dateien sind vollständig durchgelaufen und werden von den Redo-Log-Dateien in die datenbankdateien geschrieben. Eventuell prüft die Instanz vorher die System Change Number in den Headern der Kontrolldatei oder der Datenbankdateien um sicherzustellen, dass keine veralteten Änderungen in die Datenbankdateien von den REdo-logs übernommen werden. Alle nicht vollständig durchgelaufenen Transaktionen werden anhand ihrer Before-Images im Undo-Tablespace zurückgerollt.

Shared Pool

Der Sahred Pool verarbeitet die SQL-anweisungen und beschleunigt so deren Ausführung. Wenn eine SQL-Anweisung an die Oracle-Isntanz geshickt wird, muss diese erst verarbeitet werden. Daz gehören die Überprüfung der Syntax, die Existenz der in der anweisung angesprochenen Objkete und der Zugriffsrechte des Anwenders auf diese objekte.

Diese Daten findet der shared Pool im Data Dictionary, welches im SYSTEM-Tablespace liegt. Oracle muss die Daten im SYSTEM-Tablespace einlesen, um die SQL-Anweisungen verabreiten zu können. Dieses Data dictionary liegt fest abgespeichert auf der Festplate, wird jedoch im lauenden Betrieb im Arbeitsspeciher gehalten. Dort liegt es in einem speziellen Bereich des Sahred pools, dem sogenannten Dictionary cache.

Im Shared pool liegt ebenfalls der sogenannte Library Cache. Dieser enthält verschiedene Ausführungspläne, die wiederum vershciedene Routinen beinhalten, um die Oracle-Datenbank nach abfragten Objekten und Werten zu durchsuchen. Die Oralce-datenbank wählt nach Analyse der SQL-Anweisung den Asuführungsplan, der vermutlich am wenigsten Zeit udn ressourcen in Anspruch nehmen wird. Der passende, von der oracle-istnazausgewhlte Ausführungsplan, wird im Library cache abgelegt. Bei erneuter Asuführung der Anweisung kann der Ausführungsplan sofort aus dem cache geladen werden.

Large Pool, Java Pool & streams Pools

Im Large pool werden diverse weitere Komponenten vorgehalten, wie etwa der Recovery Manager oder der shared Server.

Der java pool bietet die Möglichkeit, gespeicherte Prozeduren anstelle der Orcale-eigenen sprache PL/SQl in Java zu programmieren. Java-Programme benötigen eine Java Virtual machine, um laufen zu können. Diese bietet Oracle in diesem Speichebreriehc des Java Pools.

Der Streams Pool wird zur Replikation von Daten zwiscehn Davenbanken verwendet. Dabei werden die daten als Nachricht vershcickt und in Queues abgelegt. Diese Queues werden im streams Pool zwischengespeichert.

Prog Global Area (PGA)

Standardmäßig ist die Oracle instanz so konfiguriert, dass für jeden Oracle-User, der für Anfragen genutzt wird, ein eigener sogenannter PGA geschaffen wird. Für jeden dieser PGA wird ein extra Serverprozess auf Betriebssystemebene gestartet,  der einen Freiraum im Arbeitsspeicher für diesen User reserviert. Hier werden user-spezifische Daten gecahed wie SQL-Code von Anfragen, die dieser User desöfteren ausführt usw.

2015-06-23_13h24_22

Automatic Memory Management

Jetzt, da Sie schon so viel über Oracle und seine Speicherverwaltung wissen, fragen Sie sich vielleicht, wie es ein Administrator schaffen soll, die richtigen Größen für diese ganzen Speicherbereiche zu finden?

Die Gute Nachricht ist: Für die meisten Szenarien reicht das Automatic Memory Management von Oracle, welches auf Basis von Erfahrungswerten im laufenden Betrieb die Größen dieser verschiedenen Speicherpools dynamisch anpasst.

sie können scih die aktuellen Größen aller buffer anzeigen lassen mit

SELECT * FROM v$sga;
SELECt * FROM v$sgainfo;

Die Gesamtgröße von SGA und PGA können Sie mit dem Parameter memory_target setzen.

ALTER SYSTEM SET memory_target = 838860800 SCOPE=BOTH

 Logische Speicherstrukturen

Wie wir weiter oben bereits kennengelernt haben, gibt es in Oracle physikalische speicherstrukturen, also Dateien wie beispielsweise das Control File, die Datendateien oder die Redo-Log-Dateien, die auf die festplatte geschrieben werden.

mit dem Tablespace, den wir weiter oben bereits besprochen haben, haben wir eine der sogenannten logischen Speicherstrukturen kennengelernt. Diese werden im Data Dictionary von Oracle festgelegt und helfen dabei, physikalsiche speicherstrukturen zu organisieren. Somit ist es beispielsweise möglich, dass man die Datendateien der Oracle-Datenbank über mehrere Datenträger verteilt. Dank des control Files und des Data Dictionarys, welche sich dei Pfade zu den Datendateien merken, erinnert sich die Oracle-Datenbank daran, welche Daten in einem Tablespace bei welchen Datendateien zu finden sind.

Neben dem Tablespace gibt es noch andere solcher logischer Speicherstrukturen.

Die kleinste logishce Speichereinheit ist der sogenannte Oracle Block. Es ist die logische Abbildung eines Datenclustesr auf einer physikalischen festplatte. Beispeil: Unter NTFS ist es so, dass der minimale Speicherplatz auf dem Dateisystem ein Cluster mit einer Größe von 4 KB ist. DAs heißt: selbst wenn Sie mit dem windowseditor eine Datei erstellen, die nur 1 KB groß ist, so wird diese in der theorie 1 KB-große Datei auf der festplatte 4 KB Speicherplatz wegnehmen, weil dies die kleinste verfügbare Speichermenge auf dem Dateisystem ist. Ein Oracle Block istdie entsprechung eines solchen Clusters im logischen sinne. es empfiehlt sich aus diesem Grund, die Größe der logischen Oralce Blocks an die minimale Größe solcher Datencluster auf dem physikalischen speichermedium anzupassen – oder ein Vielfaches davon zu nehmen. Einige Administratoren würden z. b. bei einer clustergröße von 4 KB hergehen und die Größe von Oracle Blocks auf 8 KB stellen, dem Zweifachen von 4KB.

Eine Gruppe von Oracle Blocks, die afu dem physikalischen Datenträger direkt nebeneinander liegen, nennt man ein Extent. Standardmäßig sind das 1 MB Große Gruppen an oracle Blocks. Wenn Sie die Größe von oracle Blocks auf 8KB gestellt haben heißt das, dass 1024 Oracle Blocks in diesem Extent drin sind. Ein Extent weißt Speicherplatz zu verschiedenen Datenbankobjekten zu. Wir ahben beispielsweise gelernt dass es möglich sit, in einem Tablespace nicht nur eine, sondern mehrere Tabellen zu verwalten. Jede Tabelle bekommt dabei einen gewissen Speicherpaltz zugewiesen. Diesen Speicherplatz weißt Oracle logisch geshen in From von einem oder mehreren Extents zu.

Jedes objekt in einem Tablespace, ob Tabelle, Index o. Sonstiges, wird in einem Segment gespeichert. Ein Segment ist eine Gruppierugn von Extents, die in ein und demselben Tablespace gespeichert sind und die einem Objekt zugewiesen wurden. Das heißt: Wenn ihr in einem Tablespace beispielsweise drei Tabellen erstellt, dann bekommt jede diese Tabellen jeweils ein Segment mit wiederum jeweils einem oder meheren zugewiesenen Extents.

Views

Ein View ist eine gespeicherte SQL-Anfrage, die ausgeführt werden kann, um bestimmte Daten aus der datenbank übersichtlich anzuzeigen. Das bedeuetet ein View ist nichts anderes als eine SQL-Anfrage, die sie auch ganz einfach selbsta usführen könnten, nur zur späteren Wiederverwendung gespeichert.

Das Data dictionary bietet viele verschiedene Views, mit der wir häufig benötigte informationen abfragen können.

Beispielsweise gibt es die Views

  • User: daten über die objekte, die einem User gehören
  • ALL: alle Daten und objekte, auf die derzeitig angemeldete user zurgeifen kann
  • DBA: Informationen über alle Objekten in der gesamten Datenbank.

mit foglendem SQL-Code können Sie jede einzelne View aus dem Dictionary holen:

spool on
spool c:\dictionary.txt
select * from dictionary;
spool off

in der Datei C:\dictionary.txt haben Sie nun die informationen aus allen Views des Data Dictionarys.

Wichtige Dateien

Die kontrolldatei

Die kontrolldatei enthlt die Speicherorte der Datenbankdateien, oft auch als Datendateien bezeichnet. Dies sind Dateien, die im Dateisystem der Festplatte des Systems hinterlegt sind, und in denen die Daten drin stehen, die letzendlich in der Datenbank hinterlegt sind. Manchmal sind diese Datendateien direkt im Dateisystem hinterlegt und haben somit einen Dateinamen. Dann enthlt die Kontrolldatei den Pfad zu diesen Dateien im Dateisystem. Manchmal jedoch werden die Datendateien direkt „roh“ auf eine Festplatte geschrieben, ohne dass es einen Dateinamen im Dateisystem gibt, der auf diese Daten zeigt. Dann enthält die Kontrolldatei den Pfad zu dem sogenannten Raw Device, also zum reservierten Speicherbereich, der für diese Datendateien vorgesehen ist.

Nach dem Start einer Oracle-Serverinstanz schaut diese in den Parameterdateien nach, wo sich die Kontrolldatei befindet. Die Serverinstanz öffnet die Kontrolldatei und sieht nach, wos ich die Datenbankdateien befinden. Daraufhin bindet die Oracle-instanz die Datenbankdateien an (man spricht auch vom mounten einer Datenbank) und ermöglicht somit den Zugriff auf die Datenbanken, die sich hinter diesen Datenbankdateien verbergen.

Neben den Pfaden zu den Datenbankdateien steht in der Kontrolldatei außerdem der Sicherungskatalog des recovery Managers. Das bedeutet die Kontrolldatei enthält ein Logbuch mit den wichtigsten Daten über alle erfolgten Sicherungen der Datenbank.

Ohne die Kontrolldatei weiß die Oracle-Serverinstanz nicht mehr, wo sich die Datenbankdateien befinden. Das heißt ohne Kontrolldatei funktioniert auch die Datenbank nicht. man aknn zwar versuchen, manuell eine Kontrolldatei zu erzeugen und die Datenbankdteien selber wiederzufinden, das ist jedoch mit enormem Aufwand verbunden. Deswegen wird die Kontrolldatei im laufenden Betrieb gespiegelt, so dass falls diese mal versehentlich gelöscht wird im laufendne Betirb wiederhergestellt werden kann und die Oracle-Datenbank weiterhin funktioniert. Und desweiteren wird die Kontrolldatei bei jedem Backup der Datenbank mitgesichert.

Weil die kontrolldatei so wichtig ist, wird diese genau wie die Redologs gespiegelt und zyklisch (also im Wechsel) auf die Festplatte geschrieben, während die andere Datei als Backup zur Verfügung steht. Grundsätzlich sit es deswegen, wie auch bei den RedoLogs, empfohlen, die beiden Kontrolldateien auf zwei verschiedenen Datenträgern vorzuhalten.

Paramaterdateien

Parameter der Oracle-Instanz können einmal im Oldschool PFILE und einmal im SPFILE gespeichert werden.

Soweit möglich, sollten Sie Änderungen immer über das SPFILE machen. Denn bei diesem handelt es sich um eine dynamische Datei, die im laufenden Betrieb geändert werden kann. Wenn sie Änderungen an Parametern übernehmen wollen, die im PFILE eingeben wurden, müssen Sie hingegen die Oracle-Instanz neu durchstarten. Desweitreen können Sei das SPFILE im Gegensatz zum dem PFILE zwischen mehreren in einem Cluster verbundenen oracle-Isntanzen teilen, so dass alle die selbe SPFILE-Datei verwenden.

Das SPFILE ist keine Textdatei, die Sie mit einem Texteditor bearbeiten können, sondern eine Binärdatei. Ändern können Sie die Parameterüber den SQLPlus-Command alter system set. DAs ältere PFILE hingegen können Sie durchaus mit einem Texteditor bearbeiten.

die Parameterdatei enthält außerdem den Pfad zum Control File, dessen Wichtigkeit wir ja weiter oben bereits erwähnt haben.

Wie speichert eine oracle Datenbank Änderungen

sie wissen vielleicht von anderen Datenbankmanagementsystemen, dass die Datenbanken immer an zwei Orten gehalten werden: Im Arbeitsspeicher des Systems und auf der Festplatte. Auf der festplatte werden die Daten gespeichert, so dass wenn der Server einmal neu gestaretet wird oder abstürzt, die Datenbank auf der Festplatte immer noch gespeichert ist und von dieser wieder gelesen werden kann. Im laufenden Betrieb der Datenbank dauert es jedoch sehr lange, wenn alle Daten jedes mal von der festplatte gelesen werden müssten. Die Anwender würden hierbei eine wahrnehmbare Verzögerung spüren, weil es jedesmal ein paar Sekunden dauern würde, bis die Daten aus der Datenbank angezeigt werden. Um dies zu verhindern, werden häufig angefragte Daten im Arbeitsspeicher vorgehalten. Wenn Sie an eienr Datenbank etwas ändern – etwa einen Datensatz hinzufügen oder einen bestehenden ändern, werden diese Änderungen ebenfalls zunächst in den Arbeitsspeicher geschrieben, weil dies wesentlich schneller geht. im Hintergrund werden die Änderungen dann auf die Festplatte geschrieben. Das birgt grundsätzlich das Problem, dass in der Zeit, in welcher die Daten vom Arbeitsspeciher auf die Festplatte kopiert werden, dass der Server in diesem Zeitraum abraucht und die Änderungen verloren gehen.

Eine Oracle Datenbank arbeitet hier noch mit einigen Besonderheiten. Auch hier werden häufig abgefragte Daten sowie Änderungen zunächst im Arbeitssepicher vorgehalten. Die Oracle-Datenbank schreibt jedoch fortlaufend sogenannte Redo-Logs. Das heißt immer dann, wenn Sie eine Änderung in der Datenbank machen, wird im Arbeitssepciher eine Datei geschrieben, welche diese Änderungen enthält. Der Log-Writer-Prozess der Oracle-Instanz schreibt diese Änderung dann sofort in eine Datei auf der festplatte weg. Das geht wesentlich schneller, als würde der Serverprozess erst die gesamte Datenbank auf der Festplatte einlesen und dann die Änderung an der richtigen Stelle editieren bzw. einfügen.  Dadurch ist der Zeitraum, in welchem Daten verloren gehen können, wesentlich kürzer, weil die Redo-Log-Dateien wesentlich schneller geschrieben sind als bei herkömmlichen Datenbanken, welche die Änderungen einfach so auf die Datendateien der Datenbank schreiben.  Nach und nach versucht auch die Oracle-Instanz, Änderungen auf die Datendateien der Datenbank zu schreiben, um den Pufferspeicher im Arbeitsspeicher des Servers sauber und frei zu halten. Jedoch kann hier nichts mehr passieren, wenn in diesem Zeitraum der Server abraucht, weil ja noch die Redo-Logs vorhanden sind, falls etwas passieren sollte. oracle reserviert Tablespaces für wirklich ALLES. Sogar für die Zwischenergebnsise von Berechnungen, Hash-Operationen und Gruppierungen gibt es sogenannte temporäre Tablespaces.

Oracle und die Raw Devices

Von anderen Datenbankmanagementsystemen wie mySQL unter der Storage Engine InnoDB ist Ihnen vielleicht bekannt, dass Datenbanken die oben erwähnten Datendateien, also die auf der Festplatte gespeicherte Datenbank, als simple Dateien abspeichert. Wenn Sie diese Dateien auf einen externen Datenträger wegsichern, haben sie dann de fakto eine Sicherungskopie Ihrer Datenbank zum Zeitpunkt der Kopie, da diese Dateien dann sozusagen die inhalte der datenbank wiederspiegeln.

Dies hat jedoch Performancenachteile, weil das Betriebssystem erst die entsprechenden Dateien im Dateisystem erzeugen und verwalten muss. Desweiteren werden die Daten dann erst in den Schreibcache des Betriebssystems kopiert, bevor sie dann von diesme Schreibcache an die Festlatte „gesendet“ und dann von dieser geschrieben werden.

Wesentlich schneller und daher performanter wäre es, die Daten für die datenbank direkt als Bits und Bytes auf die Festplatte zu schreiben, ohne dass diese als Dateien im Dateisystem sichtbar bleiben. Der Vorteil ist die dadurch bessere Performance, da die Schreib- und Lesevorgänge direkt vom Betriebssystem zur Festplatte gehen und nicht erst den Umweg über das Dateisystem und den Betriebssystem-Schreibcache gehen müssen. Oracle hat nämlich selbst bereits einen Caching-Algorithmus integriert, wie wir später noch lernen werden. Diese beiden Caching-Algorithmen von Oracle und Betriebssystem sind sozusagen doppelt gemoppelt und können sich auch gegenseitig behindern. der Nachteil ist, dass Sie die Datenbankdateien nicht mehr als Datei im Dateisystem finden und daher nur noch über die datenbankinternen Methoden eine Sicherung der Datenbank anlegen können. Und selbstverständlich müssen Sei als Administrator sich darum kümmern, dass eben jener Bereich auf der Festplatte, auf den die rohen Datenbankdateien für die Datenbank geschrieben werden, nicht vom Dateisystem verwendet wird, um dort gewöhnliche Dateien drüberzuschreiben, da dies die Datenbankdateien ja zerstören würde.

Unter Linux/Unix-Systemen verwendete man dazu lange sogenannte Raw-Devices. Raw-Devices sind also „virtuelle Geräte“, die einen bestimmten Bereich auf einem Speichermedium wie einer Festplatte oder einer SSD markieren, auf dem das Dateisystem nicht  fungieren soll, sondern wo die Dateien direkt als Bits und Bytes auf die Festplatte geschrieben werden, ohne dass diesen Daten ein Dateiname oder Ähnliches zugeordnet wird.

Mittlerweile gibt es eine Alterantive zur nutzung von Raw Devices. Oracle erstellt auf den Geräten dann ein eigenes Dateisystem namens Automatic storage Management. Dei Geräte stehen dann dem Betriebssystem nicht mehr zur Verfügung – sondern nur noch der Oralce-Instanz, sodass die Verwendung des Betriebssystem-Caches übergangen wird.  Oracle kümmert sich dann selsbt um typische Funktionen, die man vielleicht vom Betriebssystem erwarten würde, etwa das Striping zum Verteilen der Daten auf mehrere Geräte (typische RAID-1-Funktionalität), oder das Verschieben der Daten von einer sterbenden platte auf eine zweite platte, die noch funktioniert, sowie um den Lastausgleich der Lese- und Schreibzugriffe zwischen mehreren Geräten.

Objektorientierung

Oracle wird als eine objektorientiertes relationales Datenbankmanagementsystem bezeichnet, weil es die prinzipiellen relationaler Datenbankmanagementsystem in eine objektorientiertes Datenmodell ummünzt. Das heißt im Klartext, dass Objekte, User, Tablespaces usw. als Objekte mit verschiedenen Eigenschaften beschrieben sind. Der Vorteil dieser objektorientierten Verhaltnsweise ist, dass man gleichartige Objekte, die nur wenige unterscheidende Merkmale haben, in Klassen zusammenfassen kann, was Arbeit beim definieren verschiedener gleichartiger Objekte spart, da sie viele gemeinsame Eigenschaften haben, die sie miteinander teilen.

Wenn Sie mehr über das objektorientierte datenmodell wissen wollen, sollte Sie sich mit einer Programmiersprache Ihrer Wahl mit objektorientierte Programmierung auseinandersetzen.

die Prozesse

Eine Oracle-Instnaz besteht dabei aus mehreren SErvernprozessen oracle<dbsid>. Diese gehören allesamt dem User <dbsid>adm. DAnn gibt es noch andere Prozesse

  • ora_pmon. process monitor. Zuständig für das Monitoring von Server- und Userprozessen und dem Erkennen von Problemen.
  • ora_dbwr / ora_dbw<n> – Database Writer. Schreibt regelmäßig im Hintergrund frisch geänderte, im Hautpspeicher befindliche Daten auf die Festplatte, damit Sie dauerhaft gespeichert sind.
  • ora_lgwr – log-Writer. Schreibt die sogeannnten RedoLogs aus dem Log Buffer in die redoLog-Files
  • ora_ckpt – Checkpointer. Erzwingt unter bestimmten Voraussetzungen einen Checkpoint und schreibt somit RedoLogs aus dem Hauptspceicher auf die Festplatte.
  • ora_smon  – System monitor. Zuständig für das Mounten Öffnen und Schließen der Datenbank und für die zuordnung von freiem Speciherplatz zu Datennbankdateien.
  • ora_reco – Recovery
  • ora-ARCH – Archiver. Archiviert die Redo-logs in ein Archiverzeichnis.
  • ora_lck – Lock Process
  • ora_snpn – Snapshot
  • ora_mmon – statistiken für das workload repository
  • ora_mman – Memory manager
  • ora_rkwr – Recovery Writer
  • ora_pspo – Starten von prozessen.

Im Gegensatz zu SAP-prozessen haben die Oracle-hintergrundprozesse keinen zugeordneten Vaterprozess. Da die sqlplus-Session, die benutzt wird, um die Oracle-Instanz über das kommando startup zu starten, nach dem Ausloggen wider terminiert wird, kann sich nciht ls Vaterprozess für die oben geannten prozesse dienenl. Daher werden die prozesse unter Unix an den zentralen unix-Prozesse init mit der PID 1 angehängt.

Zusammenfassung

Wollen wir mal zusammen den Start einer Oracle Datenbank durchgehen? Na dann alles klar:

Als erstes wird der Oracle Dienst gestartet. Dieser ist meistens auf Betriebssystemeebene auf Autostart gestellt, das heißt sowohl unter Windows als auch unter Linux/Unix läuft der Oracle Service/Daemon gleich nach Start des Betriebssystems. Mit diesem service/Daemon wird das sogenannte RDBMS, also das Datenbankmanagementsystem (oracle.exe), aber noch nicht die Instanz und auch noch nicht die Datenbank zur Verfügung gestellt.

2015-07-06_14h42_42

Nun wollen wir ja natürlich irgendwie erstmal die Oracle Instanz starten. Damit das geht, muss das RDBMS irgendwie Anfragen zum STarten der instanz per Netzwerk entgegennehmen können. Deswegen muss der Listener Service/Daemon gestartet werden, damit die Oracle Datenbank diese Anfrage empfangen kann und daraufhin die Oracle-Instanz startet. erst wenn der Lsitener läuft, kann das RDBMS eine Anfrage zum Starten der Instanz entgegennehmen, die wir beispielsweise in sql*plus über startup open anfragen könnten.

2015-07-06_14h46_49

Das Starten der Instanz passiert natürlich nicht einfach so. Denn wie wir ja gelernt haben, brauchen wir ja erstmal das Control File. Und der Standort zum Control File wiederum steht im SPFILE / PFILE, wo auch die anderen Parameter drin stehen, die zum STarten der instanz notwendig sind.

2015-07-06_15h00_18

Erst jetzt, wenn das RDBMS die zugehörige Parameter- und Kontrolldatei zur Instanz gefunden hat, wird die Oracle-Instanz an sich gestartet. Dazu wird der notwendige Speicherplatz für die SGA und PGA im Arbeitsspeicher reserviert, die anderen nowtendigen Prozesse wie DBWR, LOGWR usw. werden gestartet.  Jetzt überspringen wir der Einfachheit halber mal ein paar Schritte und gehen davon aus, dass die Oracle-Instanz läuft. Dann sieht das ganze so aus

2015-07-06_15h34_58

Während die Datenbank läuft, geschieht nun eine Änderung in der Datenbank. Wie wir gelernt haben, wird diese Änderung zunächst in die Tabellenblöcke des Databse Bufer Caches übertragen.

2015-07-06_15h39_13

Diese Änderung wird auch in den Redo Log Buffer übertragen.

2015-07-06_15h40_00

Noch hilft uns das ganze aber nichts, denn wenn jetzt das System abraucht, geht der inhalt im Arbeitsspeicher verloren – und damit letztendlich auch die Änderungen in der Datenbank, da die Änderungen sich noch nicht auf der festplatte befinden. Deswegen ist das erste, was die Oracle-instanz macht, diese Änderungen in die Redo Log Dateien zu schreiben, wie wir ja wissen. Und erst, wenn die Änderungen in diesen Redo-Log-Dateien gelandet sind, ist die Transaktion abgeschlossen und die Änderungen ist letztendlich von usern „abrufbar“, wenn diese eine Query an die Datenbank starten, da erst ab diesem Zeitpunkt gewährleistet ist, dass die Änderung auch bestehen bleibt, wenn das System abstürzt. Da also gewährleistet ist, dass die Daten nicht wieder verändert werden, bis sie auf der festplatte sind, spricht man von einer synchronen Übertraugng der Änderungen

2015-07-06_15h52_48

Was passiert, wenn jetzt der Server abschmiert, werden einige von euch fragen. Dazu müssen wir erst nochmal das Konzept der System Change Number in die Grafik einbauen.

Die System Change Number zeigt dem oracle-System an, auf welchem Stand es sich derzeit befindet. Die Datendateien unserer Datenbank enthalten derzeit die Daten ohne den Change und haben aber eine bestimmte SCN.

2015-07-06_15h57_19

Da wir jedoch einen change haben, muss eine aktualisierte SCN irgendwo abgespeichert werden. Da unsere Datendateien den Change derzeit noch nicht empfangen haben, ist der einzig logische speicherort für die neue SCN in den Redo Logs. Diese neue SCN muss auch in die Kontrolldateien wandern. Warum, sehen wir gleich.

2015-07-06_16h03_40

Jetzt lassen wir den Server an dieser Stelle einmal abstürzen. Wir starten das Serversystem und die Oracle instanz neu. Das RDBMS schaut wieder in das SPFILE, wo die Kontrolldateien liegen und merkt beim Starten der Instanz, dass die SCN-Nummer in den Kontrolldateien eins höher ist als die SCN in den Datendateien. Das heißt: das System weiß jetzt, dass es Änderungen im Vergleich zum derzeitigen Stand der Datendateien gibt. Und der einzige Ort, an dem diese Änderungen liegen können, sind die Redo Logs. Also schnappt sich das RDBMS die redo Logs und schaut nach, welche Änderungen ab dem Wert <SCN+1> vorgenommen wurden und schreibt diese Änderungen in die Datendateien. Danach werden die SCNs auf den gleichen Stand gebracht und die Datenbank ist auf dem aktuellen Stand.

2015-07-06_16h11_38

Gut, dann läuft unser Server erstmal wieder und alles ist auf dem aktuellen Stand:

2015-07-06_15h34_58

Was ist jetzt, wenn mal eines der Redo Logs vollgeschrieben ist? Redo Log-Dateien haben ja eine vordefinierte Größe, nach der diese voll werden. Nehmen wir mal an, seit der letzten Aktualisierung der Datendateien wurden 20 Changes durchgeführt, und beim 19. Change läuft eine Redo Log Datei voll. Dann wird einfach eine neue Redo Log Datei angefangen und die vollgelaufene Redo Log Datei wird nebenbei als Archive Log archiviert.

2015-07-06_16h22_17

Wenn die Archivierung fertig ist, wird das vollgelaufene Redo Log wieder geleert und steht wieder für einen neuen Schreibvorgang zur Verfügung.

2015-07-06_16h23_47

In einigen Fällen, wenn man die Größe der Redo Log Files falsch gewählt hat, kann es jedoch vor kommen, dass das erste vollgeschriebene Redo Logn noch archiviert ist, als das letzte Redo Log File vollgeschrieben wurde.

2015-07-06_16h29_38

Sie können es sich wahrscheinlich denken: In diesem Fall steht das System komplett still. Das bedeutet: Es ist solange keine Änderung möglich, bis wieder eine leere Redo Log Datei zur Verfügung steht. Diesen Fehelr quittiert Ihnen das oracle RDBMS oft mti der meldung ARCHIVER_STUCK. Diesen Fehelr können Sie vermeiden, indem Sie die Redo Logs so dimensionieren, dass Sie nicht voll werden, während noch eines archiviert wird, also beispieslweise eine weitere redo Log Datei hinzufügen. Oder sie können  den Archivierungsprozess beschelunigen, indem Sie beispielsweise die Redo Log Dateien wie bereits besprochen auf unterschiedliche Datenträger aufteilen oder beispeislweise schnellere Datenträgermedien verwenden.

Nun kann es aber trotzdem sein, dass bei Ihnen einmal ein Archiver Stuck auftritt, weil die Redo Logs aufgrund fehlenden Speicherplatzes nicht mehr archiviert werden können. Ich zeige Ihnen im Folgenden mal ein paar Methoden, mit denen Sie mit dem Problem umgehen können

  • Dummy-Datei. Diese maßnahme muss getroffen werden, bevor der Archier voll läuft. Dabei wird eine hinreichend große Dummy-DAtei in das Archiver-verzeichnis gelegt, die man beim Auftreten eines ARCHIVER_STUCK löschen kann. Somit hat man danach genügend zeit, um das Problem aufzulösen.
  • eine anchträglcihe Methdoe ist ein Verschieben der Offline-Redo-Logs im Archivierungsverzeichnis an eine andere Stelle, an der ausreichend paltz vorhandne ist. Damit ist wieder paltz für neue Archive-Logs vorahnden. Man muss dann jedoch nachräglcih sicherstellen, dass die verschobenen Offline Redo Logs noch manuell auf Band gesichert werden.
  • Als Alternative können Sei das Verzeichnis für die Archive Logs auf eina nderes vezreihcnis mit ausriehcend platz umstellen. in der Zwischenzeit können Sie dann die archive Logs im alten Ordner archivieren lassen und dann den ordner wieder zurückstellen. Dann müssen Sie die Archive Logs im anderen Ordner etnweder wieder in den Original-Ordner mit verschieben oder diese gleich manuell archivieren.

Wie läuft das jetzt, wenn wir ein Backup von unserer Datenbank machen wollen? Nun, bei einem sogenannten Offline-Backup, bei welchem die Oracle-istnanz vor dem Backup heruntergefahren wird, ist es reht einfach. Hierbei wird in der Regel einfach ein sogenannter Checkpoint initiiert und alle Änderungen im Database Buffer Cache werden auf die Datendateien übertragen.

2015-07-06_17h55_39

Hierbei würde die Oracle-Instanz beim hochfahren erkennen, dass die SCN der Kontrolldateien und die SCN der Datendateien gleich sind und daher die gespeicherten Changes in den Redo Logs und Archive Logs ignorieren, da diese maxiaml gleich alt sind mit den Änderungen in den Datendateien. Eventuell werden die Redo Logs und die Archive Logs nach einer gewissen Zeit geleert, so dass keine überflüssigen Änderungen mehr in den Logs gespeichert werden, die sich bereits in den Datendateien befinden. Sie sehen, das einzige, was Sie theoretisch backupen müssten, wären die Datendateien und die Kontrolldateien. Die REdo Logs und die Archive Logs brauchen Sie nicht, solange beim Checkpoint alle Änderungen sauber in die Datendateien geschrieben werden.

Komplizierter wird die ganze Angelegenheit bei einem sogenannten Online-Backup. Hier läuft die Oracle-Instanz weiter, während im laufenden Betrieb das Backup durchgeführt wird.

Was Sie bei einem Online-Backup überhaupt nicht wollen, ist folgendes Szenario:

Sie machen ein Backup und sichern gerade Ihre Datendateien weg, sagen wir mal, Sie brauchen pro Datendatei 10 Minuten und sind gerade dabei, die Datendatei zwei zu sichern.

2015-07-06_18h00_15

Während des Backups kommt ein Change herein, der alle Datendateien ändert. Es ist nicht schlimm, dass Ihnen die aktuelle Version von SCN+40 der Datei DF.DATA1 flöten gehen würde, da sie die Changes der SCN+40 aus den Redo Logs wiederherstellen können, wenn Sie nicht vergessen, die Redo Logs mit zu backupen. Die oracle instanz würde dann anhand der SCN+40 in der Kontrolldatei und der SCN+39 in der DF.DATA1 erkennen, dass der DF.DATA1 noch Änderungen fehlen, und diese nachziehen.

Schlimm ist allerdings zum einen, dass die Datei DF.DATA2 geändert wird, während wird Sie backupen. DAss dabei nichts anständiges raus kommen kann, sollte Ihnen einleuchten. die Datei könnte korrupt sein, da Sie teilweise Änderungen aus der version SCN+39 und tewileise Änderungen aus der Version SCN+40 enthält, aber nichts Ganzes aus einer der Versionen.

Desweiteren ist es fatal, dass wir die Version SCN+40 der Datei DF.DATA3 sichern würden und nicht die Version SCN+39 der Datei DF.DATA3. Denn unsere Oracle Instanz wird bei einem REcovery-Vesuch mit dem Wert SCN+40 in der Kontrolldatei feststellen, dass die Dateien DF.DATA1 und DF.DATA2 in der version SCn+39 vorliegen und versuchen, aus den Redo Logs die Version SCN+40 herzustellen, jedoch mitunter scheitern, da Teile der Änderungen auch in die Datei DF.DATA3 geschribeen werden müssten, die sich jedcoh bereits auf Version SCN+40 befindet. Oracle wird sich dabei mitunter  verwirrt in die Ecke zurückziehen und anfangen zu weinen.

Deswegen müssen Sie bei einem online backup sicherstellen, dass während des Onlien Backups nichts, aber auch gar nichts, in die Datendateien geschrieben wird, sondern alle Änderungen ausschließlich in REdo Logs und Archive Logsg eschrieben werden. Das machen Sie, indem Sie den Tablespace, den Sei backupen wollen, in den BACKUP-Modus versetzen

alter tablespace <tablespacename> begin backup;

# nach dem backup dann
alter tablespace <name> end backup;

In diesem Modus kann kein Checkpoint herbeigeführt werden und alle Änderungen werden nur noch in die Log-Dateien gespeichert. Und hier werden Sie feststellen, dass Änderungen im laufenden Betrieb kein Problem sind.

Jedoch gibt es auch hier mit den Redo-Log-Dateien ein Problem, um das sich der Backup-MOdus kümmern muss. Was passiert, wenn Sie die Datenbank in den Backup-Modus schalten, also verhindern, dass die datendateien beschrieben werden, aber zur selben Zeit noch der DBWR-Prozess versucht, Blöcke aus dem Datbase Buffer Cache in die datendateien zu schreiben? richtig, die Oracle-Datenbank lässt zu, dass dieser Vorgang noch abgeschlossen ist. Was ist jetzt, wenn der DBWR noch versucht, Datenzu schreiben, Sie aber schon bnegonnen hbaen, die Datendateien über ein Betriebssystem-Kommando wie beispielsweise copy (Widnows), cp (Linux) oder dd (Linux) zu kopieren? Dann haben Sie wieder das Problem, dass ein Teil der Datendateien mit einem alten Stand kopiert wird, während sie vom DBWR mit einem neuen Stand beschrieben werden. Dabei kann es vorkommen, dass bestimmte Datenblöcke dann inkonsistent werden, weil sie teilweise den Stand vor dem DBWR-Schreibprozess in sich haben udn teilweise den Stand danach. Dieses Problem nennt man Block-Split Issue. Dieses Problem kann nicht von der Datenbank verhindert werden, da das Datenbankprogramm ja keinen Einfluss auf die Betriebssystemkommandos nehmen kann, die das Betriebssystem ausführt. Die Oracle Datenbank kann also nicht sagen: „Moment mal, du kopierst jetzt noch nicht die datendatei, weil ich gerade noch einen Checkpoint zu Ende schreiben muss!“. Was Oracle aber automatisch macht, wenn Sie die Datenbannk in den Backup-Modus versetzen, ist ein initiales Before-Image aller Tabellenblöcke mit in die Redo-Log-Dateien zu schreiben. Wie Sie wissen, werden ja normalerweise nicht ganze Tabellenbölcke in die Redo-Log-Dateien geschrieben, sondern nur die Änderungen an den Tabellenblöcken, sogenannte Change Vectors. Im Backup Modus jedoch wird von allen Tabellenblöcken, die beim Anschalten des Backup-Modus noch nicht vollständig in die Datendateien geschribeen wurden, Images mit in die REdo-Log-Dateien geschrieben, so dass diese im Falle eines solchen Block Splits wiederhergestellt werden können. Hier ein kleiner Artikel auf Asktom zum Thema Block Split.

Gehen wir von folgendem Szenario aus

2015-07-06_18h21_36

Gerade werden die Datendateien gesichert. Da der Tabelspace in den backup-modus geschaltgen ist, kann uns während des Backups nieamnd in die Datendateien reinschreiben, diese sind also sicher. Gleichzeitig wird gerade das allererste Redo Log File archiviert, das zweite Redo Log File wartet noch auf Archivierung, da es voll ist, und alle im Moment stattfindenden Changes, etwa der Change 40, wandert in die dritte Redo Log Datei. Solange wird nicht bei der dritten REdo Log Datei angekommen sidn, werden alle Changes einfach ganz problemlos in die dritte Redo Log Datei geschrieben. der kritische Punkt ist erst erreicht, wenn wir die dritte Redo Log Datei sichern wollen, und diese immer noch die aktive Redo-Log-Datei ist, welche die aktuellen Changes aufzeichnet. Dieser kritische punkt ist hier an dieser Stelle erreicht:

2015-07-06_18h30_30

Hier kommt Ihnen das Redo Log mirroring zu gute, also die Tatsache, dass pro REdo Log Gruppe zwei Redo Log Dateien vorhanden sind. Wie Sie wissen, wird immer nur maximale eine der beiden Redo Log Dateien in unserer 3. Redo Log Gruppe beschrieben, während von der anderen Redo Log Datei in der 3. Gruppe gelesen wird. Während also eine Datei mit der neuen Änderung 41 gerade beschrieben wird, kann die andere Datei mit der Änderung 40 zurückgesichert werden. Die Änderung 41 ist zwar dann nicht im Backup mit enthalten, aber so ist das nunmal bei einem Online-Backup.

 

Zu guter letzt müssen Sie sich noch ans Herz legen, dass Sie die Dateien in der richtigen Reihenfolge backupen müssen. Die richtige Reihenfolge zum Backup einer Oracle-Datenbank ist von oben nach unten:

  1. Datendateien
  2. Redo Logs
  3. Archive Logs
  4. Control Files

denn überlegen Sie mal: Wenn Sie die Kontrolldateien gleich als erstes wegsichern, kann es Ihnen passieren, dass Sie REdo Logs mit der Version SCN+40 zurücksichern, aber eine Control Datei mit der Version SCN+39 im Backup haben. Das heißt, Oracle wird die Änderungen in der Version SCN+40 in den Redo Logs womöglich ignorieren oder Ihnen eine Fehlermeldung ausspcuken, dass die Redo Logs eine neuere Version  anzeigen als das Control File. Umgekehrt bekommen Sie aber alle Änderungen aus der Version SCN+40 aus dem Backup heraus, auch wenn Sie zu guter letzt eine Kontrolldatei SCN+41 speichern, da die Datendateien ja eine Version haben, die älter ist als SCN+40 und sich daher die Änderungen aus den Redo Logs holen.

Zudem sollte logisch sein, dass Sie die Redo Logs vor den Archive Logs backupen. Denn wenn Sie erst die Archive Logs backupen und kurz nach dem Backup des Archive Logs wird ein noch nicht im Archive-Log-Backup enthaltenes Redo-Log archiviert und gleich danach geleert, dann wrid das nun leere Redo-Log nicht mehr gebackupt, aber auch die soeben frisch archivierte Version ist nicht in Ihrem Backup enthalten. Umgekehrt passiert es Ihnen allerhöchstens, dass Sie die Version eiens Redo Logs backupen, welches wenig später archiviert wird und dann lediglich doppelt noch einmal im Archive-log-Backup auftaucht.

Was bei Oracle cool ist ist die Tatsache, dass sie unabhängig von dem hier geschilderten Verfahren, welches ein „Full Backup“ umfasst, ein ständig im Hintergrund laufendes Backup haben können, welches zumindest einen Großteil Ihrer Daten sichert. Nehmen wir an, Sie haben eine Datensicherung der Datendateien,m die 30 Tage zurückliegt, auf einem Tertiärspeicher wie beispeilsweise einem Magnetband gesichert. Und Sie konfigurieren, dass jedes mal, wenn ein Redo Log File voll wird, das Archive Log ebenfalls auf einen Tertiärspeicher gesichert wird. Dann müssen Sie nur noch einstellen, dass bei jeder Archivierung eines Redo Logs gleichzeitig das Control File mitgesichert wird, und Sie haben ein autoamtisches, im Hintergrund alufendes Backup aller Daten außer denen, die im aktuellen Redo Log File drin sind. Und dieses Redo Log File wiederum haben Sie ja pro Gruppe gemirrort auf zwei Dateien, so dass Sie hier zumindest schonmal ein sehr einfaches Backup von diesem REdo Log haben. Sie sehen also: Bereits mit relativ wenig Aufwand können Sie Ihre Oracle Datenbank zumindest sehr einfach gehalten irgendwie backupen.

Sie sollten jedoch trotzdem hin und wieder ein Full Backup nach dem oben genannten Verfahren anstoßen, da Sie sich sicher vorstellen können, dass es nach 60, 90 oder 120 Tagen ziemlich lange dauern wird, alle Änderungen seit dem letzten Stand der Datendateien aus den Archive Logs wiederherzustellen.

Seit Oracle 10g steht außerdem die sogenannte Flash-Backup-Technologie zur Verfügung. Richtig kofniguriert schreibt der RKWR-prozess analog zum LGWR-prozess zu jeder nderung, die sich in denn REdo-Log-Dateien befinde,t auch die Undo-Informationen mit. Damit ist es möglich, dass zu einem beliebigen Stand der Datenbank ZURÜCKgerollt werden kann, auch wenn der gewünschte Stand schon mehrere Tage zurückliegt. Stellen Sie sich ein Computerspiel vor, bei welchem eine große Welle an Hackern die Daten von zahlreichen Spielern geknackt und deren Accountdaten verkauft haben. Mit den gesicherten Undo-Informationen könnte der Betreiber die Daten der spieler auf den Zeitpunkt vor den Angriff zurückrollen.

2015-09-05_16h21_44

Wollen wir jetzt noch ein Recovery-Szenario miteinander durchspielen? Nehmen wir mal an, eine der vielen DAtendateien geht kaputt und kann nicht wiederhergestellt werdne. Wir haben aber ein full backup aller Datendateien, jedoch mit einem älteren Stand, auf welchem ungefähr 1000 Änderungen weniger drauf sind als aktuell (SCN 2000 anstatt 3000).  Mit den Redologs kommen wir insgesamt auf eine SCN von 4123, also selbst die aktuellen Datendateien hängen ordentlich hinterher.

Dann wird einfach die eine verloren gegangene Datendatei aus dem Backup restored und mit Hilfe der Redo Logs werden dann ALLE datendateien auf den aktuellen Stand gezogen.

Bei diesem Szenario wurde von den Datendateien ein Offline-Backup durchgeführt. Das heißt es hat einfach gereicht, die Datendatei aus dem Backup wiederherzustellen.

Das Szenario oben, bei welchem wir nur die eine beschädigte Datei wiederhergestellt und alle anderen DAteien in Ruhe gelassen haben, wird Partial Restore  und Full Recovery genannt. Restore bezeichnet das Wiederherstellen der beschädigten Datei, und Recovery das bringen auf den aktuellen Stand.

Wie sieht es aus, wenn die Datendatieen mit der SCN 2000 damals bei einer Online-Sicherung gebackupt wurden? wie Sie weiter oben gelernt haben, sind Datendateien aus einem Online-Backup nicht konsistent, da es möglciherweise sein kann, dass der DBWR Änderungen zweier verschiedener SCN-Nummern in die Datendateien geschrieben hat. Deswegen ist eine Weiderherstellung der Datendateien aus einem Online-Backup alleine noch nicht konsistent. Sie brauchen zusätzlich zu den Datendateien die Redo-Logs, die während des Online-Backups geschrieben wurden, da diese, wie wir weiter oben gelernt haben, die Before-Images der Tabellenblöcke enthalten, bevor sie das erste mal geändert wurden. Nur damit ist ein Recovery möglich. Von diesem Zustand an sind dann die Datendateien wieder konsistent und wir müssen alle wieteren Redo-Logs einspielen, um die Datendateien auf den absolut aktuellsten STand zu bringen.

2015-09-05_16h34_28

Denn überlegen Sie mal: Wir haben diesmal nicht wie ein Beispiel weiter oben lediglich eine einzige Datendatei wiederhergestellt, sondern ALLE Datenobjekte zurückgespielt, also sämtliche Datendateien + die Control Dateien. was passiert, wenn Sie die Datendateien aus diesem Full-Backup auf die SCN 2040, also auf den stand aller Redo-Log Dateien während des Online-Backups – bringen – und danach die Datenbank mit alter database open öffnen und wieder produktiv einsetzen? Richtig, das System weiß  in diesem Moment aufgrund der veralteten Control-Files nicht, dass es bereits neuere Redo-Logs gibt und wird anfangen, neue Redo-Logs ab LSN 81 bzw. SCN 2041 zu schreiben, welche die eigentlichen Redo-Logs bis zum aktuellen STand überschreiben würden! Daher müssen Sie nach dem Zurückspielen eines Full-Backups, bei welcher die aktuellen Control-Files verloren gehen, ein Full Recovery auf die aktuellen Redo-Logs durchführen, sonst werden die Changes mit den SCNs 2041 – 4123 überschrieben! Das gilt sowohl für Full Recoveries von einem Offline- als auch von einem Online-Backup!

dieses oben genannte szenario, bei welchem wir ALLE Datenbankobjekte aus einer datensicherung zurückspielen (und nicht nur eine einzige beschädigte Datei wiedehrerstellen, wie ein Beispiel davor), wird Full REstore und full Recovery genannt.

wie sieht das ganze jetzt aus, wenn irgendein Benutzer einmal Mist gebaut hat, beispeislweise einen ganz ganz wichtigen Datensatz gelöscht hat? dann wollen wir ja eine Datenbank nicht ganz zurücksetzen, sondern wir wollen einen Stand haben, BEVOR der versehentlcihe löschvorgang durchgeführt wurde. Das nennt man dann ein point-In-Time-Recovery, also der Restore der Datenbank und die anschließende Recovery bis zu einem bestimmten Punkt. Da alle Redo-Log-Dateien ab diesem Vorteil nicht mehr zu gebrauchen sind, nutzt man nach dem Recovery die Gelegneheit und resettet alle Redo-Logs auf die LSN 1, so dass die Redo-Logs nach dem Recovery wieder bei LSN 1 anfangen.

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 …

2 Antworten

  1. 24. Juni 2015

    […] gehören beispielsweise die Konfiguration des Speicherplatzes. Auf diese Thematik bin ich im theoriepost zum Oracle DBMS schon etwas eingegangen. Zu planen gibt es hier sachen wie die Verteilung der Redo Logs Dateien, […]

  2. 6. Juli 2015

    […] Was RedoLog Files sind und wieso man sie archivieren sollte, lernen Sie in meinem Thread Oracle DBMS – theoretisches Grundwissen.# […]

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

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