This website use cookies to help you have a superior and more admissible browsing experience on the website.
Loading...
By:
An Oracle redo log records every change made to your database. When a user runs an INSERT, UPDATE, or DELETE, Oracle doesn’t write that change directly to disk. It logs it first, then flushes it to the redo log files.
If the instance crashes, Oracle replays those logged changes on the next startup, recovering every committed transaction. This is the foundation of durability in ACID compliance.
Oracle maintains two types:
Before diving deeper, here are four terms you’ll see throughout this guide:
A redo log file is a preallocated, fixed-size file on disk. Unlike data files, redo logs are circular. When the last group is full, Oracle cycles back to the first group and overwrites it, but only after that group has been archived and its changes have been written to the data files (checkpointed).
Oracle organizes redo log files into a two-layer structure: groups and members. A group is a logical unit made up of one or more identical member files. The Log Writer process (LGWR) writes the same redo entries to every member in the current group simultaneously.
Multiplexing means storing multiple members of the same group on different physical disks. If one disk fails and corrupts a member file, Oracle keeps running as long as at least one member in the group remains readable. Without multiplexing, losing a single redo log file can bring the entire database down.
When you query V$LOG, each group will show one of four statuses:
| Status | What It Means |
|---|---|
| CURRENT | The group LGWR is actively writing to |
| ACTIVE | Log switch has occurred, but changes haven’t fully checkpointed to data files yet. Still needed for instance recovery |
| INACTIVE | Changes have been checkpointed. This group is safe to reuse |
| UNUSED | The group was just added and has never been written to |
To see your groups, members, sizes, and current status:
SELECT
a.GROUP#,
a.STATUS,
b.MEMBER,
a.BYTES/1024/1024 AS SIZE_MB
FROM V$LOG a
JOIN V$LOGFILE b ON a.GROUP# = b.GROUP#
ORDER BY a.GROUP#;
Add a new group (with two members on separate disks for multiplexing):
ALTER DATABASE ADD LOGFILE GROUP 4
('/u01/app/oracle/oradata/REDO/log4a.rdo',
'/u02/app/oracle/oradata/REDO/log4b.rdo') SIZE 512M;
Add a member to an existing group:
ALTER DATABASE ADD LOGFILE MEMBER
'/u02/app/oracle/oradata/REDO/log1b.rdo' TO GROUP 1;
Drop a group:
ALTER DATABASE DROP LOGFILE GROUP 4;CURRENT or ACTIVE. To drop the current group, run ALTER SYSTEM SWITCH LOGFILE first, wait for its status to change to INACTIVE, then drop it.Finding the right location for your redo log files comes down to two priorities: performance and redundancy.
If you use Oracle Managed Files (OMF), Oracle handles naming and placement automatically based on the DB_CREATE_ONLINE_LOG_DEST_n parameters. But regardless of how files are placed, one rule always applies: never store members of the same group on the same physical disk. If both members sit on the same failing volume, multiplexing offers no protection. Always separate members across different mount points, storage controllers, or ASM disk groups.
Query V$LOGFILE to see where each member is stored and whether it lives on a regular file system or in ASM:
SELECT
GROUP#,
TYPE,
MEMBER
FROM V$LOGFILE
ORDER BY GROUP#;
Use this procedure when migrating logs to faster storage or correcting a placement issue. The rename method below works across all Oracle versions.
1. Shut down the database cleanly so all redo data is flushed to disk:
SHUTDOWN IMMEDIATE;2. Copy the files to the new location at the OS level using cp (Linux) or copy (Windows). Oracle does not move files for you — this step must be done manually.
3. Mount the database:
STARTUP MOUNT;4. Update the control file with the new paths:
ALTER DATABASE RENAME FILE '/old_disk/log1a.rdo' TO '/new_disk/log1a.rdo';
ALTER DATABASE RENAME FILE '/old_disk/log1b.rdo' TO '/new_disk/log1b.rdo';5. Verify the paths are updated before opening:
SELECT GROUP#, TYPE, MEMBER FROM V$LOGFILE ORDER BY GROUP#;6. Open the database:
ALTER DATABASE OPEN;Log size and switch frequency are directly linked. The size of your redo logs determines how much change data Oracle can record before it must switch to the next group. Every switch triggers a checkpoint, forcing the Database Writer (DBWn) to flush modified data from memory to disk.
When logs are too small, switches happen too often. Constant checkpointing creates an I/O bottleneck and typically shows up as “log file switch (checkpoint incomplete)” in your wait events.
The target is one switch every 15 to 30 minutes during peak load. More frequent than that is a clear sign your logs are undersized.
Query V$LOG_HISTORY to see how many switches are happening per hour over the past seven days:
SELECT
TRUNC(FIRST_TIME, 'HH') AS HOUR,
COUNT(*) AS SWITCHES
FROM V$LOG_HISTORY
WHERE FIRST_TIME > SYSDATE - 7
GROUP BY TRUNC(FIRST_TIME, 'HH')
ORDER BY 1;
Look for hours with high switch counts. Those are your peak periods and your sizing reference point.
Use this formula as your starting point:
Peak Redo Rate (MB/min) × 30 min = Ideal Log Size
For standard OLTP workloads, 500 MB to 1 GB is a reasonable baseline. For databases with heavy batch jobs or end-of-day processing, size to peak load — not your daily average. Sizing for the average means your database will stall exactly when performance matters most.
One real example: a database running 200 MB logs hit 456 switches per hour during a nightly batch load. After increasing log size to 22 GB, the “log file switch (checkpoint incomplete)” wait event disappeared from AWR top waits entirely, and the batch window shrank by 40%.
You cannot resize an existing log file directly. The process is: add larger groups, cycle through them, then drop the old ones.
1. Add new groups at your target size:
ALTER DATABASE ADD LOGFILE GROUP 4 ('/u01/app/oracle/oradata/redo04.log') SIZE 2G;
ALTER DATABASE ADD LOGFILE GROUP 5 ('/u01/app/oracle/oradata/redo05.log') SIZE 2G;
ALTER DATABASE ADD LOGFILE GROUP 6 ('/u01/app/oracle/oradata/redo06.log') SIZE 2G;2. Force a log switch so Oracle moves to the new groups:
ALTER SYSTEM SWITCH LOGFILE;3. Once the old groups reach INACTIVE status, drop them:
ALTER DATABASE DROP LOGFILE GROUP 1;4. Repeat Step 3 for each remaining old group.
ALTER SYSTEM SWITCH LOGFILE more than once to cycle through all old groups. Always confirm a group is INACTIVE in V$LOG before dropping it.Every Oracle database runs in one of two modes: NOARCHIVELOG or ARCHIVELOG.
In NOARCHIVELOG mode, filled redo logs are simply overwritten. Recovery is only possible up to your last full backup — anything after that is gone.
In ARCHIVELOG mode, Oracle saves a permanent copy of every redo log before reusing it. This lets you restore an old backup and replay the archived logs to recover right up to the point of failure. For any production database, ARCHIVELOG mode is not optional.
When an instance crashes and restarts, Oracle runs a two-step recovery process automatically:
No manual intervention is needed. This process completes before the database opens.
Check your current archiving status:
ARCHIVE LOG LIST;
If the output shows “No Archive Mode”, follow these steps to enable it:
1. Shut down the database:
SHUTDOWN IMMEDIATE;2. Mount the database:
STARTUP MOUNT;3. Enable ARCHIVELOG mode:
ALTER DATABASE ARCHIVELOG;4. Open the database:
ALTER DATABASE OPEN;| Symptom | Likely Cause | Fix |
|---|---|---|
| Switches every 1–2 minutes | Log files too small | Increase log size using the add/drop method |
| log file sync wait event | I/O bottleneck on the log disk | Move logs to faster storage (SSD or NVMe) |
| log file switch (checkpoint incomplete) | Not enough log groups | Add more groups to give DBWn time to checkpoint |
| Archive destination full; database hangs | Archive space not monitored | Expand storage, relocate archives, or purge via RMAN |
Redo logs are Oracle’s first line of defense. They handle crash recovery automatically and ensure no committed transaction is lost when an instance goes down unexpectedly.
But redo logs have limits. They cannot recover from accidental data deletion, permanent disk failure, or corruption that has already been checkpointed to the data files. They also offer no way to manage backup policies across multiple databases from a single place.
For those scenarios, you need a dedicated backup solution. i2Backup is an enterprise backup platform built to cover what redo logs cannot.
A Complete Data Protection Stack
For Oracle environments that also require high availability or real-time replication, Info2soft offers two complementary products:
Together with i2Backup, these tools cover the full range of data protection needs — from instance-level crash recovery to cross-platform disaster recovery.
You can click the button to get a free trial of Info2soft’s disaster recovery solutions.
Oracle redo logs are the foundation of database durability. They record every committed change, enable automatic crash recovery, and — when sized and configured correctly — keep your database running without performance bottlenecks.
The key takeaways from this guide:
That said, redo logs are not a backup strategy. They protect against instance crashes, but not against accidental deletion, hardware failure, or the need to manage recovery across multiple databases. For that, a dedicated solution like Info2soft’s i2Backup fills the gap — with continuous Oracle backup, point-in-time recovery, and centralized management across your environment.
