Es scheint mir, du machst hier einige Konzepte zusammen.
Lassen Sie uns zunächst über die Wiederherstellung von Instanzen sprechen. Nach einem Datenbankabsturz kommt es zu einer Instance-Wiederherstellung, egal ob es abgebrochen wird, der Server ausfällt usw. Beim Start der Instanz liest Oracle Daten aus den Redo-Logs und führt einen Rollback durch, wobei alle ausstehenden Änderungen in die Datendateien geschrieben werden. Als Nächstes liest es das Rückgängigmachen, ermittelt, welche Transaktionen nicht festgeschrieben wurden, und verwendet die Daten in Rückgängig, um alle Änderungen rückgängig zu machen, die bis zum Zeitpunkt des Absturzes nicht ausgeführt wurden. Auf diese Weise garantiert Oracle, bis zur letzten festgeschriebenen Transaktion wiederhergestellt zu sein.
Nun, was direkte Lasten und NOLOGGING betrifft. Es ist wichtig zu beachten, dass NOLOGGING nur gültig für direkte Lasten ist. Das bedeutet, dass Updates und Löschungen nie NOLOGGING sind, und dass INSERT nur nologging, wenn Sie den APPEND-Hinweis angeben.
Es ist wichtig zu verstehen, dass Sie beim direkten Laden Daten direkt in die Datendateien "laden". Sie müssen sich also nicht um Probleme im Zusammenhang mit der Instanzwiederherstellung kümmern. Wenn Sie eine NOLOGGING-Direktladung ausführen, werden die Daten weiterhin direkt in die Datendateien geschrieben.
Es geht so etwas. Sie tun eine direkte Last (für jetzt lassen Sie das Problem von NOLOGGING beiseite legen), und Daten werden direkt in die Datendateien geladen. In diesem Fall wird Oracle Speicher oberhalb der High Water Mark (HWM) zuweisen und diese brandneuen Blöcke direkt formatieren und laden. Wenn diese Blockzuweisung vorgenommen wird, werden diejenigen Datenwörterbuchaktualisierungen, die die Speicherplatzzuweisung beschreiben, in redo geschrieben und durch diese geschützt. Wenn Ihre Transaktion festgeschrieben wird, werden die Änderungen dauerhaft.
Jetzt, im Falle eines Absturzes einer Instanz, wurde entweder die Transaktion festgeschrieben (in diesem Fall befinden sich die Daten in den Datendateien und das Datenwörterbuch spiegelt diese neuen Extents wieder) oder wurde nicht festgeschrieben Die Tabelle sieht genauso aus wie vor der direkten Belastung. Somit werden Daten bis einschließlich der letzten festgeschriebenen Transaktion wiederhergestellt.
Jetzt, NOLOGGING. Ob eine direkte Belastung protokolliert wird oder nicht, ist für die Zwecke der Instanzwiederherstellung irrelevant. Es wird nur ins Spiel kommen im Falle eines Medienfehlers und Medienwiederherstellung.
Wenn Sie einen Datenträgerfehler haben, müssen Sie die Sicherung wiederherstellen.Sie werden also die beschädigte Datendatei wiederherstellen und anschließend Redo aus archivierten Redo-Logs anwenden, um die Transaktionen, die seit dem Zeitpunkt der Sicherung aufgetreten sind, auf den aktuellen Zeitpunkt "abzuspielen". Solange alle Änderungen protokolliert wurden, ist dies kein Problem, da alle Daten in den Redo-Logs enthalten sind. Was passiert jedoch bei einem Medienausfall nach einer NOLOGGING Direktladung?
Nun, wenn das Redo auf Ihre Segmente angewendet wird, die mit NOLOGGING geladen wurden, sind die erforderlichen Daten nicht im Redo. Also, die Data Dictionary-Transaktionen, die ich erwähnt habe, die die neuen Speicherbereiche erstellt, wo Daten geladen wurden, sind in den Redo, aber nichts, um diese Blöcke zu füllen. Die Extents werden also dem Segment zugewiesen, dann aber auch als ungültig markiert. Wenn Sie also versuchen, aus der Tabelle auszuwählen und diese ungültigen Blöcke zu treffen, erhalten Sie ORA-26040 "Daten wurden mit der Option NOLOGGING geladen". Das ist Oracle, das Ihnen mitteilt, dass Sie eine Datenbeschädigung haben, die durch die Wiederherstellung durch einen NOLOGGING-Vorgang verursacht wird.
Also, was zu tun ist? Nun, zuerst, jedes Mal, wenn Sie Daten mit NOLOGGING laden, stellen Sie sicher, dass Sie die Last bei Bedarf erneut ausführen können. Wenn also während des Ladevorgangs ein Instanzenfehler auftritt, können Sie den Ladevorgang neu starten. Wenn zwischen dem Zeitpunkt des NOLOGGING-Ladevorgangs und dem nächsten Backup ein Medienfehler auftritt, können Sie den Ladevorgang erneut ausführen.
Beachten Sie, dass Sie im Falle einer direkten NOLOGGING-Belastung bis zu Ihrer nächsten Sicherung der Datendateien/Tablespaces, die die Segmente enthalten, die direkt geladen wurden, nur Datenverlusten ausgesetzt sind. Sobald es durch Backup geschützt ist, sind Sie in Sicherheit.
Hoffe dies hilft, die Ideen rund um direkte Lasten, NOLOGGING, Instanzwiederherstellung und Medienwiederherstellung zu klären.