Home > Workload Solutions > Oracle > White Papers > Dell PowerMax 2500 and 8500 Best Practices for Mission Critical Oracle Databases > Oracle redo log considerations
With all-flash NVMe SSD storage systems, the performance of database workloads increased significantly when compared to storage systems using spinning disks (hard disk drives, or HDDs). As a result, the sizing recommendations for redo log files has also changed to avoid unnecessary database delays. Such delays can occur if the redo log files are not sized correctly.
For example, if the redo log files are sized too small, Oracle will write updates to each file, fill it entirely, then move to the next file. When the last file has been filled, Oracle will return to the first. If the archive log process has not finished archiving the first file, Oracle will have to wait before writing to the log, creating a delay in the workload.
To avoid unnecessary database delays in high-performance databases, it is recommended to size each redo log file (member) at least 10 GB and have at least four files for each database instance (redo log thread). Since each database has a different workload profile, the DBA should monitor the rate of log switches. The database should not need to switch redo logs more than a few times in an hour. There should also be enough logs to allow the archive process to complete its work before the database need to reuse that log file.
Oracle 11gR2 introduced the ability to change the redo log block size from its default 512 bytes to 4 KB. One reason for this change was certain drives used 4 KB as their native block size (for example, SSD drives). Another reason was to reduce the metadata overhead that was associated with high density drives by increasing the block size from its legacy 512 bytes to 4 KB.
When using PowerMax storage, there are two key reasons why the redo log block size should not be changed from the default 512 bytes per sector: