When you’re planning the disk layout and subsequent placement of the various files that make up your database, you need to consider the different reasons Oracle per-forms I/O and the potential performance impacts.
Oracle and Disk I/O Resources | 161 The main destinations of the I/O operations Oracle performs are the following:
• Redo logs
• Data contained in tables
• Indexes on the tables
• The data dictionary, which goes in the SYSTEM tablespace
• Sort activity, which goes in the TEMP tablespace of the user performing the sort
• 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)
The following simple principles for managing these types of I/O can optimize Oracle’s use of the database server’s disk subsystem:
Use disk-striping technologies to spread I/O evenly across multiple spindles
These technologies are covered in detail in the next section, “Using RAID Disk Array Technology.” Oracle has simplified striping in Oracle Database 10gand newer releases by enabling striping through Enterprise Manager leveraging ASM.
Use tablespaces to clearly segregate and target different types of I/O
Separate table I/O from index I/O by placing these structures in different tablespaces. Youcan then place the datafiles for these tablespaces on various disks to provide better performance for concurrent access.
Using tablespaces to segregate objects also simplifies tuning later on. Oracle implements I/O activity at the level of the datafile, or the physical object the operating system sees as a file, and each file is a part of only one tablespace, as described in Chapter 4. Placing specific objects in specific tablespaces allows you to accurately measure and direct the I/O for those objects by tracking and mov-ing the underlymov-ing datafiles as needed.
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.
162 | Chapter 7: Oracle Performance
As described in Chapter 8, Oracle Database 10gRelease 2 gives youthe option of delaying write operations to the redo log for transactions. This capability can improve performance in very high transactional environments, but carries with it the possibility of losing committed data if your database crashes.
Distribute “system overhead” evenly over the available drives
System overhead consists of I/O to the SYSTEM tablespace for the data dictio-nary, the TEMP tablespace for sorting, and the tablespaces that contain rollback segments for undo information. You should consider the system profile in spreading the system overhead over multiple drives. For example, if the applica-tion generates a lot of data changes versus data reads, the I/O to the rollback segments may increase due to higher writes for changes and higher reads for consistent read functionality.
Sort activity can also affect disk I/O. Prior to Oracle Database 10g, youwould get the majority of sorts to occur in memory through tuning the SORT_AREA_
SIZE parameter in the initialization file. Oracle constantly queries and updates the data dictionary stored in the SYSTEM tablespace, and this information is cached in the shared pool section of the SGA, so sizing your shared pool properly is a key to overall performance. As of Oracle Database 10g, Oracle can automatically and dynamically size the different pools in the SGA.
Use a different device for archiving and redo log files
To avoid archiving performance issues due to I/O contention, make sure that the archive log destination uses different devices from those used for the redo logs and redo log mirrors.
Some other file placement issues to consider from the perspective of database avail-ability include the following:
If you are directing database backups to disk, store the backups on devices that don’t contain any database components
This protects the system from the potential loss of the database and the needed backups from the failure of an I/O device.
Make sure the device used for the archive log destination doesn’t contain any database components or database backups
If the failure of a single device results in the loss of both database components and archived redo logs, or backup components and archived redo logs, recovery will be endangered.
Fault-tolerant disk arrays don’t eliminate the need for a sound backup and recovery strategy. Fault-tolerant storage merely reduces the likelihood of undergoing database recovery due to the failure of a single drive. For full coverage of Oracle databases and high availability, see Chapter 11.
Oracle and Disk I/O Resources | 163