Utiliser les fichiers journaux de rétablissement de base de données Oracle
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Database Migration Service utilise l'API Oracle LogMiner, qui fait partie de la base de données Oracle, pour interroger les fichiers journaux de rétablissement archivés. Ces fichiers contiennent des informations sur l'historique d'activité d'une base de données. Chaque base de données Oracle dispose d'un ensemble de fichiers journaux de rétablissement en ligne.
Tous les enregistrements de transactions de la base de données sont enregistrés dans les fichiers.
Lorsque le fichier journal de relecture actuel est remplacé (ou remplacé), le processus d'archivage
copie ce fichier dans un espace de stockage d'archive. Pendant ce temps, la base de données promeut un autre fichier pour qu'il serve de fichier actuel.
Lorsque Database Migration Service utilise l'API Oracle LogMiner, il n'accède pas aux fichiers journaux de rétablissement en ligne, mais ne fonctionne qu'avec les fichiers journaux archivés.
L'accès aux fichiers journaux de rétablissement archivés ajoute intrinsèquement une latence au processus de migration. Cette page décrit une configuration suggérée pour vos bases de données sources Oracle afin de contrôler l'impact de la latence.
Définir les paramètres de configuration des fichiers journaux de rétablissement Oracle
Cette conception a des conséquences importantes sur la latence potentielle de Database Migration Service. Si les fichiers journaux de rétablissement d'Oracle sont fréquemment échangés ou conservés dans une taille inférieure (par exemple, < 256 Mo), Database Migration Service peut répliquer les modifications plus rapidement.
Il existe des paramètres de configuration que vous pouvez définir pour contrôler la fréquence de rotation des fichiers journaux:
Taille:les fichiers journaux de rétablissement en ligne ont une taille minimale de 4 Mo, et la taille par défaut dépend de votre système d'exploitation. Vous pouvez modifier la taille des fichiers journaux en créant de nouveaux fichiers journaux en ligne et en supprimant les anciens fichiers journaux.
Pour connaître la taille des fichiers journaux de rétablissement en ligne, exécutez la requête suivante :
SELECT GROUP#, STATUS, BYTES/1024/1024 MB FROM V$LOG
Durée:le paramètre ARCHIVE_LAG_TARGET indique la durée maximale (en secondes) pouvant être couverte par le journal actuel de la base de données principale.
Ce paramètre n'indique pas le moment exact du changement de journal, car il tient compte du temps nécessaire à l'archivage du journal. La valeur par défaut est 0 (pas de limite supérieure), et une valeur raisonnable de 1800 (ou 30 minutes) ou moins est suggérée.
Vous pouvez utiliser les commandes suivantes pour définir le paramètre ARCHIVE_LAG_TARGET, soit lors de l'initialisation, soit lorsque la base de données est opérationnelle:
SHOW PARAMETER ARCHIVE_LAG_TARGET; Cette commande affiche le nombre de secondes que couvrira le journal actuel.
ALTER SYSTEM SET ARCHIVE_LAG_TARGET = number-of-seconds;
Utilisez cette commande pour modifier la limite supérieure.
Par exemple, pour définir la limite supérieure sur 10 minutes (ou 600 secondes), saisissez ALTER SYSTEM SET ARCHIVE_LAG_TARGET = 600;.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/18 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/08/18 (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."]]
