Oracle writes all copies the redo log file

You should use a systematic approach to both discovering the source of a perfor-mance problem and implementing the appropriate solution. This approach calls for establishing baselines for resource usage and response time before making any changes, and only making a small group of changes before reexamining the perfor-mance in the changed environment. It might be tempting to simply try to fix a problem without taking a measured approach, but this tactic will usually lead to additional problems down the road.

In Oracle Database 11g, such performance comparisons are made much easier. You can preserve AWR baselines that contain performance data from specific time peri-ods. Baselines can be established for fixed times or moving windows, or they can serve as a template.

Multiblock I/Os
For example, 32 database blocks, each consisting of 8 KB, for a total I/O size of 256 KB. Multiblock I/O is used for large-scale operations, such as full table scans. The number of blocks in one multiblock I/O is determined by the initial-ization parameter DB_FILE_MULTIBLOCK_READ_COUNT.

The Oracle database can read larger amounts of data with multiblock I/Os, so there are times when a full table scan might actually retrieve data faster than an index-based retrieval (e.g., if the selectivity of the index is low). Oracle can perform multiblock operations faster than the corresponding collection of single-block operations.

The main destinations of the I/O operations Oracle performs are the following:

• Redo logs

• Rollback information, which is spread across the datafiles of the tablespace containing the database’s rollback segments

• Archived redo logs, which go to the archived log destination (assuming the data- base is in ARCHIVELOG mode)

For example, consider a database with several large, busy tables. Placing multi-ple large tables in a single tablespace makes it difficult to determine which table is causing the I/O to the underlying datafiles. Segregating the objects allows you to directly monitor the I/O associated with each object. Your Oracle documenta-tion details the other factors to consider in mapping objects to tablespaces.

Place redo logs and redo log mirrors on the two least-busy devices
This placement maximizes throughput for transactional systems. Oracle writes to all copies of the redo log file, and this I/O is not completed until all copies have been successfully written to. If you have two copies of the redo log file, one on a slow device and the other on a fast device, your redo log I/O performance will be constrained by the slower device.