https://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:656444800346932623
Eine Standby Datenback ist also das angestrebte Ziel.
Als eine Grundregel für Backups kann gelten, das die Daten auf mind. 3 physikalischen Oberflächen an getrennten Orten direkt auf der Datenbank auf das Medium erstellt werden.
Als ich mich mit der bisher verwendeten Backup Strategie vertraut mache musste ich erfahren, das Backups auf die lokalen Platten geschrieben und dann mit Unix tools an einen zweiten Standort kopiert werden. Ich sehe darin so viele Nachteile, gegenüber der Hersteller eigenen Methoden, das ich einen lange Analyse dazu erstellt habe. Meiner Meinung nach sind Datenbanken intelligente Systeme sich hervorragend effizient selbst replizieren können!
---
1. Betrieb einer Datenbank mit zwei Zuständigkeitsbereichen
1.1 Rolle des DBA:
Sorgt dafür das Betriebssystem und Datenbank Software
1. auf dem aktuellen Stand sind und
2. permanent 24 Stunden am Tag und immer gleichbleibend schnell funktionieren.
3. Sorgt für freien Speicher für die Datenbank ohne Limit genau zu Kosten des Speicherpreis.
4. Inhalte und Strukturen sind nicht Sache das DBA.
1.1.1 Aktueller Stand des Systems
Patches und Updates des Systems und der Datenbank installieren.
File System Snapshots als technische Mittel, um die System Software zu installieren sind sinnvoll, weil damit
die Patchvorgänge im Fehlerfall zurückgerollt werden können. (Es gibt keine weitere nützliche Anwendung diese Mechanismus.)
1.1.2 Permanente Funktion des Speichermediums durch Redundanz schaffen.
Backup der Datenbank auf externe Medien und Restore bis genau zur letzten Transaktion bei Wiederherstellung.
Des gibt eine Reihe weiterer nützlicher Anwendungen für das Backup Medium.
Deshalb sollte die Datenbank einen Zugriffspfad auf das Medium haben.
1.2 Rolle des Database Software Ingenieur
1.2.1 Prozess und Geschäftsabläufe verstehen und mit technischen Lösungen unterstüzen.
1.2.2 Inhalte, Strukturen und Regeln mit der Geschäftsleitung entwerfen.
1.2.3 Daten des Kunden sichern, erfassen und in der Datenbank ablegen.
1.2.4 Ein Informationssystem nach Kundenwünschen realisieren.
1.2.5 Ökonomische Lösungen schaffen / Arbeitszeit einsparen.
Daten Erfassung so organisieren, das möglichst wenig Schritte notwendig sind.
Beispielsweise bei der Rechnungserfassung Integration der Schritte Dokumentenerfassung,
Adressenerfassung und Buchhaltungsdaten und Journal auf eine Seite.
Zugriffspfade so einrichten, dass alle Anfragen und Reports schnell beantwortet werden, auch wenn das System wächst.
1.2.6 Optimieren
1. Engineering: Beständig das erreichte hinterfragen, und prüfen ob bessere Methoden als die bisher verwendeten, eingesetzt werden können.
2. Refactoring: Leistungssteigerungen durch das Vermesssen, Erkennen und Eleminieren von Redundanzen auf allen Ebenen.
3. Learning: Beständiges Lernen und den Zweifel ertragen, ob man richtig handelt, ob man verstanden hat, welche Methode wann optimal einzusetzen ist.
2. Das Backup Medium
2.1 Das Backup Medium muss sich in einen anderen Raum als dem Serverraum befinden
damit es unter allen Umständen gegen Zerstörung geschützt ist. Wäre es im gleichen Raum oder im gleichen
Servergehäuse könnten beide bei einem Brand oder Wasserschaden zerstört werden.
Neben der Pattenspiegelung im Servergehäuse haben wir durch die Kopien auf das Backup Medium,
3 physikalische Kopien der Datenbank-Inhalte. Je nach RAID Level können es auch mehr physikalische Kopien sein.
2.2 Backup Dateien
Der Backup Prozess erzeugt per Definition seit ca. 40 Jahren 2 Varianten
2.2.1 Full Backup:
Ist eine sequenzielle Datei, die alle Datenbank Tablespaces enthält.
Die Tablespaces enthalten auf dem Backup Medium vollständig alle Inhalte und Definitionen der Kundendaten,
jedoch nicht die leeren reservierten Bereiche.
Ebenso sind alle abgeschlossenen Transaktionen (Neueintragungen) enthalten, die während der Laufzeit des Backupvorgangs angefallen sind.
Definitiv ist ein Full Backup eine Kopie der Datenbank zum Zeitpunkt des Backup Ende.
2.2.2 Inkrementeller Backup: Ist eine sequenzielle Datei die alle Transaktioen (Neueintragungen) in der
chronologischen Reihenfolge, enthält in der sie ausgeführt wurden.
Definitiv ist ein inkrementeller Backup eine Menge der Änderungen zwischen einem zeitlichen Anfangs -und Endpunkt.
Effiziente Resourcen Nutzung
NUR wenn der Datenbank Server selbstständig direkt auf das Backup Medium schreibt,
kann er die aktuellen Daten entweder aus dem RAM Cache oder von der Platte lesen.
Ausserdem kann er so viele Dirty Cache Pages unerledigt lassen, wie es ihm beliebt,
weil der aktuelle Zustand dem File System nicht mitgeteilt werden muss.
Solange Daten aus dem Caches übertragen werden, bleibt der Kanal zu den lokalen Platten vollkommen offen für Kundenanfragen.
Wenn inkrementelle Backups in kurzen Zeitabständen erstellt werden, ist es sehr wahrscheinlich,
dass Daten nur aus den RAM Caches gelesen werden müssen.
Restore / Recovery
Rekonstruiert aus dem einem Full Backup und allen inkrementellen Backup Dateien einer aktuelle Datenbank
die dem Zustand des Originals zum Zeitpunkt des Ende des letzten Inkrementellen Backup entspricht.
(Ability to roll forward datafile image copies, thereby reducing recovery time and avoiding repeated full backups.)
Solange Tapes als Backup Medium in Verwendung waren, konnte die Datenbank erst nach dem Kopieren auf Platten
als logische Einheit rekonstruiert werden. Seitdem Festplatten als Backup Medium verwendet werden, kann die Datenbank auch INPLACE
rekonstruiert werden.
Rekonstruktion
Bei der Rekonstruktion werden die Inkrementellen Backups dem Full Backup hinzugefügt.
Nach dem Hinzufügen können die Dateien der Inkrementellen Backups gleich gelöscht werden.
Durch diese Vorarbeit wird das Wiederanfahren auf einem neuen Server immens beschleunigt.
Dieser muss dann nur eine Kopie des Backup Medium laden und kann sofort loslegen ohne sich selbst um die
inkrementellen Backups kümmern zu müssen.
(Another strategy is to use incrementally updated backups as explained in "Incrementally Updating Backups". In this strategy, you create an image copy of each datafile, then periodically roll forward this copy by making and then applying a level 1 incremental backup. In this way you avoid the overhead of making repeated full image copies of your datafiles, but enjoy all of the advantages.)
Die beschriebene Methode ist so bemerkenswert effizient, das sie schon vor 40 Jahren mit Tapes und einem
3000stel der Leistungsfähigkeit heutige Systeme funktionierte. Das ist so weil für die inkrementellen Backups nur Transactions Logs sequenziell verarbeitet werden und die Tablespaces, auf denen die Datenbank I/O macht nicht berührt werden müssen. Auch moderne CPUs verarbeiten sequenzielle Datenströme effizient ohne sich groß zu erhitzen.
In Oracle heißt das Format 'backup set'.
Aus: http://docs.oracle.com/cd/B28359_01/backup.111/b28270/rcmcncpt.htm#BRADV106
RMAN can also create backups in a proprietary format called a backup set.
A backup set contains the data from one or more data files, archived redo log files,
or control files or server parameter file.
The smallest unit of a backup set is a binary file called a backup piece.
Backup sets are the only form in which RMAN can write backups to sequential devices such as tape drives.
Backup sets enable tape devices to stream continuously. For example,
RMAN can mingle blocks from slow, medium, and fast disks into one backup
set so that the tape device has a constant input of blocks.
Image copies are useful for disk because you can update them incrementally,
and also recover them in place.
https://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmintro.htm#BRADV89341
https://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmcncpt.htm#BRADV106
Andere Zeitpunkte in der Vergangenheit rekonstruieren
Wenn ein Kunde aus Versehen gelöscht hat oder ein Programm wild geworden ist und Kundendaten überschrieben hat,
kann es nützlich sein, auf gesicherte Stände Zugriff zu haben.
Aus dem Backup
Traditionell werden im wöchendlichen Rhythmus neue Full Backup Backups erzeugt und ältere Full Backup Backups gelöscht,
so das man an einige wohl definierte Zeitpunkte in der Vergangenheit zugreifen kann.
(z.B. Montags 5:00 vor einer, zwei und vor drei Wochen).
Um diesen Service dem Kunden anbieten zu können, muss die Datenbank auf dem NAS im Produktions System
als Netzwerk Laufwerk eingebunden und als READ ONLY Datenbank gemountet werden.
Haben die Kunden keinen Zugriff auf das Backup, sind mehreren Generationen FULL BACKUP auf einer Platte nutzlos und können entfallen.
Es ist immer noch eine gute Idee die Daten eimal im Jahr auf ein Tape zu schreiben und dieses im Safe aufzubewahren.
Oracle Flashback Querys
Erlaubt es dem Anwendungsprogrammierer dem 'SELECT' die 'AS OF TIMESTAMP xxx' Klausel anzuhängen. Die maximale Zeitspanne lässt sich vorkonfigurieren. Es wird allerdings moderat mehr Plattenspeicher dafür verbraucht, wenn die Zeitspanne länger wird.
Flashback Query in der einfachen Form ist frei und absolut ausreichend, Flashback Transaction Query
ist lizenzpflichtig und nur notwendig wenn man die Transaction Logs durchsuchen muss.
Flashback Query ist cool, haben wir aber noch nie benötigt, weil die Anwendung selbstständig Historien der kritischen Datensätze erzeugt und anzeigt.
3 Immutable Database
Ein Datenmodel kann so gestaltet werden, dass es keine Operation gibt, bei der Daten verloren gehen. Geschäftsleute bevorzugen solche Datenmodelle. Deshalb waren von Anfang an wichtige Tabellen bei uns so angelegt.
Die Sorge dass interne Mitarbeiter Daten zum Schaden des Unternehmens vorsätzlich Löschen oder Verändern, kann gelindert werden.
Mit der vorhandenen Historie zu jedem Datensatz lassen sich Fehlerquellen und Irrtümer wesentlich schneller aufklären.
Wenn das Datenmodel so gestaltet ist, dass in der Datenbank nur Fakten mit Zeitpunkten gespeichert werden und Änderungen an bestehenden Objekten neue Datensätze erzeugen, so dass die alten Inhalt zugreifbar bleiben
und Löschungen durch den Anwender nur als neues Faktum also als Soft Delete Markierung gespeichert werden
dann hat man eine Immutable Database.
Time Machine Inklusive
Anders als in den unhandlichen Backups mit genau vordefinierten Zeitpunkten kann in einem Immutable Database Model auf beliebige Zeitpunkte bis zum Anfang des Unternehmens immer und ohne externe Hilfe und ohne Lizenzkosten und in Millisekunden und ohne Angabe einer anderen Quelle zugriffen werden.
Kosten Sparen
Wenn eine Immutable Database mit Time Machine in Funktion ist, dann werden die mehrere Full Backups im wöchentlichen Rhythmus nicht mehr benötigt.
Top Down - Replication
Weil die Daten permanent sind ist es wesendlich leichter Kopien der Daten oder Bezüge auf die Daten zu verwalten. Es gibt die Gewissheit, das Daten mit älteren Zeitpunkten seit dem letzten Synchronisieren unverändert sind
und die Zuversicht, das sich die neuen Daten sehr leicht extrahieren lassen und in einer Operation integrieren lassen.
4 System Snapshot mit Kundendaten / Tablespaces als Backup Methode
File System Snapshots als technische Mittel um die System Software zu installieren sind sinnvoll, weil damit
die Patchvorgänge im Fehlerfall zurückgerollt werden können. Wie in einer Datenbank Transaktion kann ein ROLLBACK gemacht werden. Die Datenbank dabei mit zu Sichern halte ich für eine schlechte Idee
Da könnte man auch auf die Idee kommen und sagen: hey cool damit kann ich auch meine Daten sichern, so das ich
einen gesicherten Stand der Kundendaten wiederherstellen kann.
Das haben schon andere versucht und sind kläglich gescheitet. Die Gründe sind folgende:
1. keine Kontrolle über den Zeitpunkt
Der Zeitpunkt ist davon abhängig wann der Snapshot erstellt wurde.
Wird eine gewisse Auswahl erfordert, müssen mehrere Snapshort vorgehalten werden,
was wieder den Speicherbedarf erhöht.
2. kompizierte Rekonstruktion
Die Datenbank Tablespaces aus einem Snapshot zu rekonstruieren ist schwierig weil
alle aktullen Transaction logs seit dem Snapshot Zeitpunkt hinzugefügt werden müssten um
den aktullen Zustand der Datenbank zu rekonstruieren. Ich weiss nicht ob es dafür automatische tools gibt.
3. Mindestens Verdoppelung des Speicherbedarfs
Der Speicherbedarfs für die Snapshorts von (100% + X * Snapshots) entspricht im Extremfall dem der Datenbank,
weshalb nur die Häfte der Kapazität zur verfügung steht. Wegen der Notwendigkeit die Änderungen an Dateien zu bemerken, müssen zusätzliche Berechungen von Hashwerten und deren Verwaltung und zusätzliche Schrieboperationen in kauft genommen werden. Wohl deshalb empfiehlt Oracle Snapshorts nur in Entwicklungsumgebungen und sicherlich nicht für sehr größe Datenbanken.
4. kein Zugriff auf den Snapshot
Vielleicht gibt es Unix tools um einzelne Dateien aus einen Snapshot zu rekonstruieren, nur sind diese Tools in der PL/SQL Entwicklungsumgebung nicht erreichbar und daher nutzlos, um Kundendaten zu rekonstruieren.
5. Datenlecks und Crypto
Wenn die Datenbank geheime Informationen enthält und diese sollen sicher gelöscht werden, gibt es keinen Weg für den Kunden diese Snapshots zu löschen, um sicher zu sein, dass keine Kopien mehr existieren.
Wenn Dokumente verschlüsselt werden und die Schlüssel wie empfohlen regelmäßig geändert und die Dokumente neuverschlüsselt werden, dann wird ein Snapshot jedes Mal den gesamten belegten Tablespace duplizieren müssen und die Nutzdatenspeichergröße schrumpft auf einen Bruchteil der verfügbaren Plattenkapazität.
6. Snapshots haben keine Kontext
Im Gegensatz dazu, können in einem aktuellen Oracle Datenbank Backup Set oder z.B.mit der Apple Time Machine
Endanwender frühere Versionsstände einzelner Dokumente in der richtigen Anwendung und im Kontext ohne Hilfe eines Operators und nur zu den Kosten eines externen Laufwerks, das ohnehin als physikalisches Backup Medium notwendig wird, rekonstruieren. Diese Dienstleistung wird inzwischen als stelbstverständlich hingenommen.
7. Falsches Medium
Normalerweise werden Snapshots auf das gleichen Medium geschrieben auf dem das Rollback unterstützt wird.
Das Backup muss aber auf ein externes Medium geschrieben werden, damit es nicht zusammen mit dem Original
verschwinden kann.
Schlussfolgerung: Das Tool Snapshot hat keine weitere nützliche Anwendung neben der Aufgabe die System Patches sicher zu installieren und soll deshalb unbedingt die Datenbank Tablespaces und Transaction Logs auslassen und sich nur um den System Rahmen kümmern.
Das hätte den Vorteil, dass ein Snapshot tatsächlich angewendet werden kann, um einen früheren Installationszustand der Software wiederherzustellen, auch wenn der Zeitpunkt Wochen zurückliegt, ohne die Kundendaten zu tangieren.
5 File System Backup mit Tablespaces
Wie vorher schon ausführlich beschrieben gibt es sehr effiziente Tools der Datenbankhersteller um inkrementelle Backups des aktuellen Datenbankzustands effizient in ein aktuelles Backup Set übertragen zu können.
1. Ein File System Backup mit Tablespaces zwingt die Datenbankmaschine alle ausstehenden Schreiboperationen für alle Dirty Cache Pages zu realisieren. Das können heutzutage mehrere Gigabytes sein, die dann fällig werden. Das stellt mindestens eine Performance Last dar, weil die Platten eine begrenzte Kanalbreite haben und sie dann lange Zeit voll ausgelastet ist.
(Unlike user-managed tools, RMAN does not require extra logging or backup mode because it knows the format of data blocks. RMAN is guaranteed not to back up fractured blocks. )
2. Ein File System Backup mit Tablespaces konserviert einen Datenbankzustand in der Vergangenheit entkoppelt vom aktuellen Datenstrom. Ein Restore des Backup Stand ist wertlos solange nicht alle seit dem Backup Zeitpunkt erzeugten Transaktions Logs aufbewaht und auf die Rekonstruktion angewendet wurden.
Wenn es sehr viele Transaktionen waren, kann es sehr lange dauern bis die Datenbank wieder benutzt werden kann.
3. kein Zugriff auf die Backups
Weil die Datenbank als Dateien auf dem Backup Medium ohne Verarbeitung durch den Recovery Prozess keine logische Einheit bilden, steht sie nicht als Resource zur Verfügung. Der Recovery Prozess läuft nur auf Veranlassung und nur durch einen Operator und dauern zu lange. Deshalb wäre nur im äußersten Notfall eine Rechtfertigung der Kosten möglich.
Schlussfolgerung: Die Methode hat gegenüber den zuvor beschriebenen Backup Sets den Nachteil, das mehr Plattenplatz verbraucht wird, weil Unix Tools die Logs nicht in das letzte Full Backup selbstständig integrieren können.
Und ausgerechnet dann, wenn man es braucht, darf man erst stundenlang warten bis alle Transaction Logs in die Rekonstruktion integriert wurden. Deshalb entfällt diese Option für viele Anwendungsfälle.
6 Oracle Data Pump
Der gute alte Tape Drive Algorithmus machte bisher noch das Rennen, doch es geht natürlich noch besser.
Anstelle des Backup Prozess auf der Datenbank Maschine, der auf dem NAS Disk Drive ein Backup Set aktuell hält,
läuft auf einer minimal lizenzierten zweiten Datenbank Maschine ein Prozess der über einen Datenbank Link
die erste Datenbank kopiert. Die Oracle Data Pump hat die Modi Full Export Mode, Schema Mode, Table Mode, Tablespace Mode und Transportable Tablespace Mode.
Ersetzen der inkrementellen Backups
Durch geeignete Programmierung im Table Mode können eigene Jobs geschrieben werden,
die neue Daten integrieren. Weil hier zwei gut informierte Programme kommunizieren, können tatsächlich NUR die Nutzdaten gefiltert auf das Notwendige (ohne Metadaten) übertragen werden. Es werden keine Index Strukturen kopiert, auch die Transaction Logs müssen nicht transportiert werden. Beide Systeme schreiben ihre eigenen Indices und Transactions Logs unabhängig voneinander.
Schlussfolgerung: Die Methode funktioniert nur mit darauf vorbereiteten Datenbank Schemata und ist keine generelle
Lösung wie der Tape Drive Algorithmus. Doch der Aufwand dafür kann sich offensichtlich so sehr lohnen,
dass Oracle das lizenzpflichtige Produkt Oracle Database Advanced Replication anbietet.
7 Lizenzpflichtiges Oracle Database Advanced Replication
Mit Hilfe von Materialized Views und Materialized View Logs werden hier Daten automatisch auf Tabellen Ebene über Database Links repliziert.
Die Materialized Views und Materialized View Logs entsprechen ungefähr den Tablespaces und Transaction Logs, die vom Tape Drive Algorithmus verarbeitet werden, jedoch für Tabellen.
8 Lizenzpflichtiges Oracle Database Partitionierung
Ist eine Methode um automatisch nach organisatorisch relevanten Kriterien die Tablespaces in mehrere Dateien zu unterteilen. Sehr große Datenbanken lassen sich damit leichter verwalten und kopieren. Die Lizenzkosten sind hoch.
Schlussfolgerung: Die Lösungen 7 und 8 haben den Nachteil sehr teuer zu sein. Auch hier muss das Datenbank Schema aufwändig vorbereits werden. Es ist also keine generelle Lösung wie der Tape Drive Algorithmus.
9 Anmerkungen zu Rich Hickley
Die u.a. von Rich Hickley propagierten Immutable Databases haben viele gute Eigenschaften. Eine Replikation der Daten auf andere Systeme ist sehr generell und robust auf logischer Ebene gelöst. Es ist sinnvoller in der Datenbank Fakten mit Zeitpunkten zu akumulieren und darauf Zugriff zu geben, als nur die Funktioen Insert Update Delete und Select auf den letzten Stand anzubieten und den Kunden mit überschriebenen Daten allein zu lassen.
Fast alle Bugs die ich in den letzten 5 Jahren hatte, können auf diese Problem zurückgeführt werden.
10 Anmerkungen zu Tom Kyte von Oracle
In Bezug zu Tom Kytes: "Strategy of backup large database (e.g. 2T)", version oracle 10.2.0 on 6-Feb-2008 16:14 UTC
Suppose you use partitioning...
• Unbezahlbar und auch nicht nötig, wenn Oracle Datapump geschickt benutzt wird.
And suppose you do it range, by date...
• Ein Filter für die Datapump erreicht das Gleiche in feinerer Auflösung.
And suppose the date is always increasing....
• Timestamps markieren per Trigger alle veränderten Objekte in der Reihenfolge der Änderungen.
And supposed old data is immutable...
• Die von Rich Hickley beschriebenen Strukturen sind wohl sehr effizient, doch auch in SQL Tabellen lässt sich eine imutable Database modellieren. Soft Delete ist für den Zweck der Informationsübertragung ausreichend, weil Zeilen nach einem Delete weiterbestehen. So kann das Faktum, das sie nicht mehr existieren, übermittelt werden.
Updates können per Merge über die unveränderlichen seriellen Primary Keys integriert werden.
Then - you could mark old tablespaces READ ONLY, back them up once more, and never touch them again....
• Ohne partitioning geht das nicht. Doch wenn die Tabellen per Timestamp über einen Index abfragbar sind,
können die neuen Daten blitzschnell gefunden werden und so die Performance Funktion Partitionierung ersetzen.
• Der große Effekt der Arbeitseinsparung für große Datenbanken stellt sich genau dann ein,
wenn der Full Backup mit den großen Tablespaces nur genau einmal gemacht wird und danach nie wieder.
In 10.2 - a relatively simple approach could be:
a) realize there are two types of disk, expensive and cheap.
b) buy a ton of cheap (get 2 or 3 TB, raid 10 it)
• Es gibt fertige NAS Produkte oder Tapes wenn es nicht zu langsam ist.
c) use that as a disk based backup area
d) enable block change tracking
• Erfordert lizenzpflichtige Enterprise Edition
e) make one full backup (and never do that again)
• Mach genau ein full backup und dann muss die Datenbank von keinen Unix tool mehr berührt werden.
f) use rman true incrementals to read only blocks that were modified and have rman "catch your backup up".
• ich denke darauf kann man auch verzichten, um die Kosten für eine EE Lizenz zu vermeiden.
g) Occasionally take your full backup on disk and offload it to tape so you have the last 7 or so backups to recover from
• Also offensichtlich empfiehlt Tom Kyte die Oracle Backup Set Methode, weil sie die einzige Methode ist mit der auch Tapes geschrieben werden können.
Vergleich der Kosten für Disk, I/O und Services
---------------------------------------------------------------------------------------------------
Methode Backup Disk Server Server Server
Space Factor, Disk I/O, Network I/O, CPU Load, Quality of Service
---------------------------------------------------------------------------------------------------
Tape Drive Algorithmus N Full Backups Transaction Transaction low step scale timestamp
(Oracle Backup Sets) Logs Logs access points
Oracle Backup Sets 1 Full Backup None Transaction low full scale timestamp
+ Immutable Database Logs access points
Oracle Data Pump +
Immutable Database 1 Full Backup None Raw Data low full scale timestamp access points
Oracle Database Logical Subset Mat. Views Replication Only. (No Recovery)
Advanced Replication of Tables Mat. Views Logs Mat. Views Logs low No timestamp access
points
File System Snapshot N Full Backups / Full Scan / All Files high Snapshort Only (No Recovery)
Intercept DB N timestamp access points
File System Backup N Full Backups + Transaction Transaction high N timestamp access p
mit Tablespaces Transaction Logs Logs Logs on urgent demand
Oracle Backup Sets N Full Backups Transaction Transaction low step scale timestamp
+ Oracle Database Logs Logs access points
Partitionierung
---------------------------------------------------------------------------------------------------
Sowohl Tom Kyte als auch Rich Hickley kenne ich aus vielen Vorträgen, die z. B. auf Youtube abrufbar sind. Den Ersten schätze ich weil er komplexe Probleme sehr gut und genau und relativistisch analysiert, gute Bücher schreibt und wohl mit einer Engelsgeduld Tausende von Fragen auf seiner Website beantwortet hat und noch immer ein guter Ratgeber ist.
Rich Hickleys Vorträge haben mir bewußt gemacht, wie wichtig es ist, die Zeit als Dimension in den Kundendaten mitzuspeichern und dass das Überschreiben von Datensätzen oder Objekten INPLACE keine gute Idee war.
Funktionale Programmierung verspricht high performance parallel computing ohne locks. Ganz anders als Java Programme mit ihren ewig neuen Objekten können Funktionen speichersparend und bedenkenlos auf parallelen Systemen laufen, wenn immutable Datenmodelle verwendet werden.
Das ist eine Perspektive, die mir gefällt und Respekt vor den Resourcen zeigt.
Mit dem SELECT Statement können in PL/SQL Funktionen beliebig geschachtelt auf die Datenbank angewendet werden.
Weil das Problem der Speicherverwaltung und Backups schon vor 40 Jahren gelöst wurde, können wir bewährte Methoden verwenden und nun viel interessantere Probleme lösen.
Danke an alle, die Ihr Wissen frei im Internet veröffentlichen
Dirk Strack
