In den (online) redologs werden sämtliche Änderungen der Datenbank (inserts, deletes, updates) mitgeschrieben. In diese redologs wird zyklisch geschrieben. Es sind üblicherweise mindestens 3 redolog (bzw redolog-groups) Wenn redolog1 vollgeschrieben ist, wird in redolog2 weiter geschrieben. Wenn redolog2 voll ist, wird zu redolog3 gewechselt. Wenn das dann vollgeschrieben ist, wird (bei 3 redologs) wieder zu redolog1 gewechselt und das ganze geht von vorne los. Die alten Informationen in redolog1 werden also überschrieben. Bevor das geschieht, wird (insofern die DB im archivelog Modus ist) dieses redolog1 aber weggesichert. Das ist dann das erste archivelog. Und so sammeln sich im Laufe der Zeit eine ganze Menge archivelogs an. Und darin sind also alle *Änderungen* in der DB verzeichnet. Man braucht also unbedingt ein full backup. Wenn man ein full backup hat, kann man genau einen Zustand der Datenbank, also alle datafiles wiederherstellen. Und zwar genau den Zustand, den die DB zum Zeitpunkt des Backups hatte. Man nennt das Restore.
Hat man lückenlos alle archivelogs, die *nach* dem Erstellen dieses Backups erzeugt wurden, so kann man auch die Änderungen in der DB ‚nachfahren‘. Im Idealfall bis zum Zeitpunkt des Crashes. Oder eben auch jeden beliebigen Zeitpunkt davor (zwischen Generieren des full backups und Crash). Das nennt man Recovery.
Um genau zu erklären, wie das geht, könnte ich hier Romane tippen. Ist aber nicht nötig: Es gibt ausreichend Bücher darüber. Es ist nun mal nicht möglich, das ganze in zwei, drei Sätzen zu erklären.