Mit Wiederherstellungs-Logdateien der Oracle-Datenbank arbeiten
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Database Migration Service nutzt die Oracle LogMiner API, die Teil der Oracle-Datenbank ist, zum Abfragen archivierter Redo-Logdateien. Diese Dateien enthalten Informationen zum Verlauf der Aktivitäten in einer Datenbank. Jede Oracle-Datenbank enthält eine Reihe von Online-Redo-Logdateien.
Alle Transaktionsdatensätze in der Datenbank werden in den Dateien aufgezeichnet.
Wenn die aktuelle Redo-Logdatei rotiert (oder gewechselt) wird, kopiert der Archivierungsprozess
diese Datei in einen Archivspeicher. In der Zwischenzeit wird in der Datenbank eine andere Datei als aktuelle Datei festgelegt.
Wenn Database Migration Service die Oracle LogMiner API verwendet, greift er nicht auf die Online-Redo-Logdateien zu, sondern arbeitet nur mit den archivierten Logdateien.
Der Zugriff auf archivierte Redo-Logdateien führt zu einer höheren Latenz bei der Migration. Auf dieser Seite wird die empfohlene Konfiguration für Ihre Oracle-Quelldatenbanken beschrieben, um die Auswirkungen auf die Latenz zu minimieren.
Konfigurationsparameter für Oracle-Redo-Logdateien festlegen
Dieses Design hat erhebliche Auswirkungen auf die potenzielle Latenz von Database Migration Service. Wenn Oracle-Redo-Logdateien häufig gewechselt oder klein gehalten werden (z. B. < 256 MB), kann Database Migration Service Änderungen schneller replizieren.
Es gibt Konfigurationsparameter, mit denen Sie die Häufigkeit der Logdateirotation steuern können:
Größe:Online-Redo-Logdateien haben eine Mindestgröße von 4 MB. Die Standardgröße hängt von Ihrem Betriebssystem ab. Sie können die Größe der Logdateien ändern, indem Sie neue Onlinelogdateien erstellen und die älteren Logdateien löschen.
Führen Sie die folgende Abfrage aus, um die Größe der Online-Redo-Logdateien zu ermitteln:
SELECT GROUP#, STATUS, BYTES/1024/1024 MB FROM V$LOG
Zeit:Der Parameter ARCHIVE_LAG_TARGET gibt eine Obergrenze für die Dauer (in Sekunden) des aktuellen Logs der primären Datenbank an.
Dies ist nicht der genaue Zeitpunkt des Log-Wechsels, da berücksichtigt wird, wie lange es dauert, das Log zu archivieren. Der Standardwert ist 0 (keine Obergrenze). Es wird ein angemessener Wert von 1800 (oder 30 Minuten) oder weniger empfohlen.
Sie können die folgenden Befehle verwenden, um den Parameter ARCHIVE_LAG_TARGET festzulegen, entweder während der Initialisierung oder während die Datenbank in Betrieb ist:
SHOW PARAMETER ARCHIVE_LAG_TARGET;: Dieser Befehl zeigt an, wie viele Sekunden es dauert, bis sich das aktuelle Log erstreckt.
ALTER SYSTEM SET ARCHIVE_LAG_TARGET = number-of-seconds;
Verwenden Sie diesen Befehl, um die Obergrenze zu ändern.
Wenn Sie beispielsweise die Obergrenze auf 10 Minuten (bzw. 600 Sekunden) einstellen möchten, geben Sie ALTER SYSTEM SET ARCHIVE_LAG_TARGET = 600; ein.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-05 (UTC)."],[[["\u003cp\u003eDatabase Migration Service utilizes the Oracle LogMiner API to access archived redo log files, which contain a history of database activity, instead of the online redo log files, introducing some latency.\u003c/p\u003e\n"],["\u003cp\u003eThe frequency of Oracle redo log file switching and their size significantly impact the latency of Database Migration Service, with more frequent switching and smaller file sizes leading to faster replication.\u003c/p\u003e\n"],["\u003cp\u003eYou can modify the size of online redo log files, with a minimum of 4 MB, using guides provided for self-hosted Oracle and Amazon RDS Oracle environments.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eARCHIVE_LAG_TARGET\u003c/code\u003e parameter controls the maximum duration (in seconds) that a current log can span, with a suggested value of 1800 seconds (30 minutes) or less to enhance performance.\u003c/p\u003e\n"],["\u003cp\u003eAlthough it's possible to manually switch redo log files using the \u003ccode\u003eALTER SYSTEM SWITCH LOGFILE;\u003c/code\u003e command, it's not advised for production due to its privilege requirements and potential performance impact.\u003c/p\u003e\n"]]],[],null,["# Work with Oracle database redo log files\n\nDatabase Migration Service leverages the Oracle LogMiner API, which is part of Oracle Database, to\nquery archived redo log files. These files contain information about the history\nof activity on a database. Each Oracle database has a set of online redo log files.\nAll transaction records on the database are recorded in the files.\n\nWhen the current redo log file is rotated (or switched), the archive process\n[copies this file into an archive storage](https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/managing-archived-redo-log-files.html#GUID-9BD00F2E-DC98-4871-8D26-FDB40623909C). Meanwhile, the database promotes\nanother file to serve as the current file.\n\nWhen Database Migration Service uses the Oracle LogMiner API, it doesn't access\nthe online redo log files but only works with the archived log files.\nAccessing archived redo log files inherently adds some latency to the migration\nprocess. This page describes suggested configuration for your Oracle\nsource databases to control the latency impact.\n\nSet configuration parameters for Oracle redo log files\n------------------------------------------------------\n\nThis design has profound implications on Database Migration Service's potential latency. If\nOracle redo log files are switched frequently or kept to a smaller size (for\nexample, \\\u003c 256MB), Database Migration Service can replicate changes faster.\n\nThere are configuration parameters that you can set to control the log file\nrotation frequency:\n\n- **Size:** Online redo log files have a minimum size of 4 MB, and\n the default size is dependent on your operating system. You can modify the size\n of the log files by creating new online log files and dropping the older log files.\n\n To find the size of the online redo log files, run the following query: \n\n ```\n SELECT GROUP#, STATUS, BYTES/1024/1024 MB FROM V$LOG\n ```\n | For self-hosted Oracle, use [this guide](https://logic.edchen.org/how-to-resize-redo-logs-in-oracle/). For Amazon RDS Oracle, use [Performing common log-related tasks for Oracle DB instances](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.Oracle.CommonDBATasks.Log.html#Appendix.Oracle.CommonDBATasks.ResizingRedoLogs) in the Amazon RDS documentation.\n- **Time:** The `ARCHIVE_LAG_TARGET` parameter provides an upper limit of how long (in seconds) the current log of the primary database can span.\n\n This isn't the exact log switch time, because it takes into account how long\n it will take to archive the log. The default value is `0` (no upper bound),\n and a reasonable value of `1800` (or 30 minutes) or less is suggested.\n\n You can use the following commands to set the `ARCHIVE_LAG_TARGET`\n parameter, either during initialization or while the database is up:\n - `SHOW PARAMETER ARCHIVE_LAG_TARGET;` This command displays how many seconds it will take for the current log to span.\n - `ALTER SYSTEM SET ARCHIVE_LAG_TARGET = `\u003cvar translate=\"no\"\u003enumber-of-seconds\u003c/var\u003e`;` Use this command to change the upper limit.\n\n For example, to set the upper limit to 10 minutes (or 600 seconds),\n enter `ALTER SYSTEM SET ARCHIVE_LAG_TARGET = `\u003cvar translate=\"no\"\u003e600\u003c/var\u003e`;`\n\n| You can switch the redo log files manually by running the following command:\n|\n| `ALTER SYSTEM SWITCH LOGFILE;`\n|\n| Although using this command is effective for testing purposes, we don't\n| recommend it for production use-cases because of the privileges it requires\n| and the significant performance impact on the database."]]
