Tuning Oracle With Consideration for Storage Snd Oracle Database Files

8/8/2019 Tuning Oracle With Consideration for Storage Snd Oracle Database Files

1/24

Tuning Oracle with Consideration for

Storage and Oracle Database Files

James F. Koopmann

Technical White Paper30128-00, Rev. AFebruary 2007


2/24

Copyright 2007 by International Business Machines Corporation. All rights reserved.


3/24

Tuning Oracle: Oracle Database Files iii

Contents

Chapter 1: INTRODUCTION

Chapter 2: DETERMINING RAID LEVELS

Data Files..................................................................................................................................2-2

Chapter 3: REDO LOGS

Reducing Redo Log Contention...............................................................................................3-1

Sizing Redo Logs .....................................................................................................................3-2

Sizing Redo Logs: SQL Method.........................................................................................3-2

Sizing Redo Logs Using the Redo Log Sizing Advisor......................................................3-3

Archived Redo Logs.................................................................................................................3-4

Chapter 4: CONTROL FILES

Initialization Files.....................................................................................................................4-1

Database Objects ......................................................................................................................4-1

Segment Level Statistics ..................................................................................................... 4-1

Investigating System Level Performance Problems ...........................................................4-2

Chapter 5: DISTRIBUTING TABLESPACE

SYSTEM Tablespace ...............................................................................................................5-2

TEMPORARY Tablespace ...................................................................................................... 5-2

Undo Tablespace ......................................................................................................................5-3

Conclusion................................................................................................................................5-5

Contact Information .................................................................................................................5-5


4/24

iv Tuning Oracle: Oracle Database Files


5/24

Tuning Oracle: Oracle Database Files 1-1

Chapter 1

Introduction

As a database administrator, you already know that tuning an Oracle database is a complex

task. With hundreds of features and numerous application interfaces, you must weigh

tuning decisions carefully, and not lose sight of the intricacy of the full system. In fact

tuning Oracle is not a one-person job. Oracle tuning requires not only the database

administration staff but others who understand the full intent of the database and the

applications:

Developers

System administrators

Storage administrators

Architects

Business personnel

You can address the complex task of tuning an Oracle database using a systematic

approach. This paper looks at tuning an Oracle database with consideration for Oracle

database files. Other papers address the aspects of memory and applications.

The physical operating system files map to Oracle logical structures at the segment level.You can improve the performance of the storage subsystem by monitoring the segments

associated with database objects, identify problems and ultimately tune those aspects of

Oracle that relate to the physical data files on the storage subsystem. Database files are the

physical link between logical structures in Oracle and your storage subsystem. They

contain a variety of information, are of different sizes, and often have unique and different

input/output (I/O) patterns.

Categorizing an Oracle database file for unique placement on physical storage is very

challenging. After you have the task completed, you must remember that databases

continue to grow exponentially and that continuous monitoring is nearly impossible.

Tuning the database aspect of Oracle is often neglected until the database performance

deteriorates.Specifically, this paper focuses on these factors:

Determining the appropriate RAID level

Understanding Redo Logs

Investigating system level performance problems


6/24

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-2 Tuning Oracle: Oracle Database Files

Distributing Tablespace

Applying Tuning Strategies for Oracle Database Files

By examining RAID level, Redo Logs and tablespace you gain a clearer and deeper

understanding of how database files impact system performance. You can then use thisinformation to tune Oracle and the underlying storage subsystem.

After you have analyzed your storage system, you can make the following decisions for

improved performance:

Reducing redo log contention

Sizing redo logs

Managing archived redo logs

Using segment level statistics to improve performance

By carefully tuning the Oracle database, you can better meet the information needs of yourenvironment. By understanding these tuning strategies, you will be better equipped to tune

the Oracle database to meet todays needs and to prepare for tomorrows needs.


7/24


Chapter 2

Determining RAID Levels

Before RAID, you had to manually balance the inputs/outputs load for an Oracle database

across many discrete disk drives. Today, with larger storage requirements and the use of

RAID, you can easily allow the storage subsystem to distribute the I/O load evenly across

a group of disk drives. You must determine only what RAID level to use. When deciding

the RAID level for Oracle datafiles, there are a few critical factors:

Space requirements

Input/outputs per second (IOPS) and megabytes per second (MBps)

Disk utilization (the amount of usable disk drive space)

Table 2-1 RAID Levels and Descriptions

Raid Level Description

RAID 0 A non-redundant Redundant Array of Independent Disks (RAID) level in which data isstriped across a logical drive or array. RAID 0 provides high input/output (I/O) performance

and is better for non-critical data. All drives are available for storing user data; however, no

data redundancy exists. Data availability is more at risk than with other RAID levels, because

any single drive failure causes data loss and a logical drive status of Failed. Despite its name,

RAID 0 is not actually RAID unless it is combined with other features to provide data andfunctional redundancy, regeneration, and reconstruction.

RAID 1 A redundant Redundant Array of Independent Disks (RAID) level in which identical copiesof data are maintained on drive pairs, also known as mirrored pairs. RAID 1 uses disk drive

mirroring to make an exact copy from one drive to another drive. RAID 1 offers the best data

availability, but only half of the drives in the array are available for user data. If a single drive

fails in a RAID 1 array, all associated logical drives become degraded, but the mirrored drive

allows access to the data. RAID 1 can survive multiple drive failures as long as no more than

one failure exists per mirrored pair. If a drive pair fails in a RAID 1 array, all associated

logical drives fail, and all data is lost.

RAID 1+0 A striping and mirroring mode used for high performance.

Also known as Redundant Array of Independent Disks (RAID) 0+1.

RAID 5 A high input/output (I/O) Redundant Array of Independent Disks (RAID) level in which dataand redundancy are striped across a array or logical drive. The equivalent of one drivecapacity is used for redundancy data. RAID Level 5 is good for multiuser environments, such

as database or file system storage, where typical I/O size is small, and there is a high

proportion of read activity. If a single drive fails in a RAID 5 array, all associated logical

drives become degraded, but the redundancy data allows access to the data. If two or more

drives fail in a RAID 5 array, all associated logical drives fail, and all data is lost.


8/24

Determining RAID Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Data Files

Oracle databases place information on physical files on the storage subsystem.

The database requests data on disk drive.

The storage subsystems serves the data to the database processes.

Depending on the application and the configuration of the database, I/O requests might

arrive at varying intervals and for varying amounts of data. This is known as application

mix. For a complete discussion of application mixes in tuning Oracle, refer to: Tuning

Oracle with Consideration for Storage Subsystem and Your Application Mix.

As a database administrator, you are responsible for configuring the storage subsystem so

it serves the desired I/O rates. You must carefully monitor the datafile level to avert

potential hot spots within the storage subsystem. If a datafile, or a set of datafiles, begins

to reach the performance level of your configured storage subsystem, you must

reconfigure or move the datafiles.

To find those tablespaces and the physical datafile names that are performing large

amounts of reads and writes, use this SQL command:

select vtablespace.name tablespace_name,

vdatafile.name datafile_name,

vfilestat.phyrds physical_reads,

vfilestat.phywrts physical_writes,

vfilestat.avgiotim average_time_for_io

from v$datafile vdatafile,

v$filestat vfilestat,

v$tablespace vtablespace

where vdatafile.file# = vfilestat.file#

and vdatafile.ts# = vtablespace.ts#;

For a clear picture of the I/O activity on a set of datafiles, use the previous SQL command

periodically.

If there is no direct relationship between the Oracle objects stored in the underlying data

files, you can initially place these data files in the same RAID group and then monitor for

contention or for reaching physical storage subsystem limits such as IOPS and MBps.


9/24


Chapter 3

Redo Logs

Redo log files contain the changes that are made to a database and are used when needed

for recovery. Redo logs are constantly in use for writing and can at times become a

contentious point in the database and on the storage array.

Redo logs must be protected by RAID as these files are at the core of recovery procedures.

Consider a RAID 1 or RAID 1+0 for redo logs. These RAID provide the fast I/O that redo

logs require so as to not bottleneck the system as they record all changes.

Reducing Redo Log Contention

Because redo logs record all changes, it is important that they do not experience

contention. You can address redo log contention in several ways. Here are several

strategies to try:

Place all redo logs on one disk drive with no other files. Consider availability, andplace members of the same group on different physical disk drives and controllers for

recoverability.

Place each redo log group on a separate disk drive that does not store any other files.

Stripe the redo log files across several disk drives, using an operating system stripingtool. Manual striping is not possible in this situation.

Avoid using RAID 5 for redo logs.

Avoid concurrent activity on the same disk drive.

Dedicate a separate disk drive to redo log files so that log writer runs smoothly withoutfurther tuning.

If your system supports asynchronous I/O, and this feature is not currently configured,test the feature to see if it is beneficial for your system.

Consider the size of your redo logs. Improperly sized redo logs can impede theperformance of your database and hamper recovery time in the event of a database

failure.


10/24

Redo Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Sizing Redo Logs

As redo logs are filled to the size of the redo log file, Oracle creates an archived copy of

these files. If you make redo logs too small, the archive process can impair the

performance of redo and can cause excessive switching in the database and writing to thestorage array. As a general rule, you should size redo logs so that they can switch every 15

or 20 minutes during peak activity within the database. You can use either an SQL

command or the Redo Log Sizing Advisor to size redo logs. Both methods are described

here.

Sizing Redo Logs: SQL Method

The following SQL command gives a breakdown of the number of logs that have switched

for each of the hours of the day.

col day for a10

select to_char(first_time,'YYYY-MM-DD') day,to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'00',

1,0)),'99') 00,

to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'01',

1,0)),'99') 01,


1,0)),'99') 02,


1,0)),'99') 03,


1,0)),'99') 04,


1,0)),'99') 05,

to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'06',1,0)),'99') 06,


1,0)),'99') 07,


1,0)),'99') 08,


1,0)),'99') 09,


1,0)),'99') 10,


1,0)),'99') 11,


1,0)),'99') 12,


1,0)),'99') 13,


1,0)),'99') 14,


1,0)),'99') 15,


11/24

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sizing Redo Logs



1,0)),'99') 16,


1,0)),'99') 17,


1,0)),'99') 18,to_char(sum(decode(substr(to_char(first_time,'HH24'),1,2),'19',

1,0)),'99') 19,


1,0)),'99') 20,


1,0)),'99') 21,


1,0)),'99') 22,


1,0)),'99') 23

from v$log_history

group by to_char(first_time,'YYYY-MM-DD');

Check for hours that have a high number of switches, and then check the size of your redo

logs. Examine the disk drive area where the redo logs and archive logs are being written to

make sure that the disk drives can handle the amount of I/O hours when there are high

numbers of switches.

Sizing Redo Logs Using the Redo Log Sizing Advisor

You can use the Oracle Redo Log Sizing Advisor to obtain the Oracle recommended size

for your redo logs. The Redo Log Sizing Advisor considers the following factors and

recommends an appropriate size:

Optimizing log archiving issues

Optimizing Database Writer performance

Reducing excessive log switches

Reducing incomplete and excessive checkpoints

Reducing excessive disk drive I/O

Because redo logs are also used for recovery, the size of the redo logs must consider the

time- to-recovery requirements. You can specify the mean time to recovery with the

FAST_START_MTTR_TARGET initialization parameter. Oracle then tries to issue the

proper checkpoints during normal system operation to meet this target. After setting the

FAST_START_MTTR_TARGET initialization parameter, query the

V$INSTANCE_RECOVERYview for the OPTIMAL_LOGFILE_SIZEvalue, in MB:

SELECT OPTIMAL_LOGFILE_SIZE FROM V$INSTANCE_RECOVERY;

Use the recommended optimal logfile size value to rebuild the redo log groups.


12/24

Redo Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Archived Redo Logs

An Oracle database has multiple online redo log groups. These groups are written to one at

a time. As one group fills, Oracle archives that group, while moving to the next group of

redo logs. The process is cyclical and eventually the redo log groups will be re-written.You should configure Oracle and the storage array so that redo logs are archived quickly

and before they are needed again. When configuring for the redo log archive, keep in mind

that the redo logs have physical files associated with them. If the archive log process

cannot stay ahead of the redo log process contention for redo log files results. This

contention will ultimately halt the database. To prevent the database from halting, you

must place online and archive log files so they do not cause contention with each other.

To avoid contention for online and archive log files do the following tasks:

Create the archive area and the redo log area on separate disk drives.

Keep the archive area separate from other database files.

When placing two redo logs from the same redo log group, separate onto different diskdrives.

Keep redo logs separate from other database files.

Consider striping all redo logs across a set of disk drives, but monitor carefully forcontention.

Watch the I/O rates, or log switching activity to the archive area, and configure diskdrives to handle the I/O rates.


13/24


Chapter 4

Control Files

Oracle control files contain vital information on the configuration of an Oracle instance.

Control files are continually being updated to record specific recovery information.

Typically the disk drive placement of these control files is not an issue, but you should

monitor resource waits and make corrections as required.

Initialization Files

Oracle also maintains an initialization file that contains configurable parameters. This file

takes two forms, either an SPFILE or an INIT file. The use of this file does not cause any

disk drive contention within Oracle.

Database Objects

Oracle sessions have only two major functions when attached to an Oracle database:

To read (SELECT) information from objects

To write (INSERT, UPDATE, or DELETE) from objects

The two most common objects that Oracle sessions read and write from are tables and

associated indexes. The storage allocation associated with tables and indexes is

represented in Oracle through logical structures called segments.

If you monitor the activity of reads and writes through segments, you gain a better

understanding of how Oracle is performing on the storage array.

Segment Level Statistics

Oracle maintains segment level statistics on the individual table and index segments that

you can use to determine where performance problems exist when accessing the database

objects. Use segment-level statistics to determine how long it takes Oracle to read or writeinformation to database objects. By knowing how long Oracle takes to read or write

information, you can determine what database objects are experiencing problems. With

this knowledge, you can take actions such as reconfiguring your storage or moving

database objects to different disk drives.


14/24

Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


With segment-level statistics, you can determine where problem areas for particular

objects reside and take appropriate action. To collect segment level statistics, you must set

the STATISTICS_LEVEL parameter to TYPICAL or all. Oracle keeps segment-level

statistics associated with segments in three views.

To check the setting for STATISTICS_LEVEL, use this command:

SQL> SHOW PARAMETER statistics_level

NAME TYPE VALUE

------------------------------------ ----------- -----------

statistics_level string TYPICAL

To change the current setting of STATISTICS_LEVEL, use this ALTER statement:

SQL> ALTER SYSTEM SET statistics_level=TYPICAL SCOPE=SPFILE;

Investigating System Level Performance Problems

Use segment level statistics to investigate system-level performance problems. First

consider the performance problems you are having at the system level. For example, use

the following SQL to view the output from selecting information from the

V$SYSTEM_EVENT view.

select event,total_waits,total_timeouts,time_waited

from v$system_event

order by time_waited desc;

If you see a large amount of time awaited for reads, writes, or buffer activity, you might

want to further investigate the database objects related to this I/O by querying the

V$SEGMENT_STATISTICS view.

Table 4-1 Segment-Level Statistics

View Description

V$SEGSTAT_NAME Reference view describing each of the segment level statistics collected.

Two of the statistics in theV$SEGSTAT_NAME view are only sampled

while the others are accumulated. The STATISTICS#view is notthe

same as in theV$STATNAME view.

V$SEGSTAT Highly efficient view for real time monitoring of segment level statistics.

V$SEGMENT_STATISTICS User-friendly view for segment level statistics. It is the same as the

V$SEGSTAT view but with easily recognizable object properties such as

owner and segment_name.


15/24

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Database Objects


The following example SQL helps you determine which objects are producing read- or

write-performance problems. To find different wait events, replace the

statistic_name comparison in theWHERE clause.

select owner,object_type,object_name,value

from V$SEGMENT_STATISTICSwhere (statistic_name like '%read%'

or statistic_name like '%write%')

order by value desc

Here are common wait events that are I/O related:

db file scattered read

db file sequential read

log file sync

log file parallel write

db file parallel write

control file parallel write

control file sequential read

buffer busy waits

direct path read

log buffer space

The names and relative importance of wait events can change. To view the Oracle

documentation set for a current list of wait events, go to http://www.oracle.com/technology/software/tech/orion/index.html
http://www.oracle.com/technology/software/tech/orion/index.htmlhttp://www.oracle.com/technology/software/tech/orion/index.htmlhttp://www.oracle.com/technology/software/tech/orion/index.htmlhttp://www.oracle.com/technology/software/tech/orion/index.html


16/24

Control Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



17/24


Chapter 5

Distributing Tablespace

Tablespaces are the links between database objects and data files out on disk drive.

Tablespaces have the following attributes:

Hold and group various database objects for ease of management.

Contain one or many database objects, which have storage requirements throughsegments.

Store one or many physical database files on a disk drive.

Link between the logical database objects and to the physical blocks on a disk drive.

Consider these attributes when designing tablespaces, the objects they hold, and the

location where they will be placed on disk drive.

For example, placing the two most accessed tables, with their indexes, in one tablespace

will cause problems:

They would occupy the same relative areas on disk drive.

They would likely produce contention on the storage array.

Follow these basic guidelines for tablespace design:

Spread potential hot objects through different tablespaces.

Do not put similar objects in the same tablespace. To improve performance, place twoobjects that are used in the same SQL query in different tablespaces and at different

locations on disk drive.

Do not put an objects indexes in the same tablespace as the object.

Put similarly accessed objects together to allow for easy placement on a disk drive thatwill have the same configuration (RAID level, caching, segment size, and similar

attributes).

Put similarly maintained objects together to allow for maintenance at the tablespacelevel.

Watch for volatile objects and do not place them in the same tablespaces as stableobjects. For instance if an application creates and drops objects regularly, dedicate a

tablespace for its operations.


18/24

Distributing Tablespace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Separate read-only objects and place them in their own tablespaces.

Verify block size, percent-used, and percent-free for objects to reduce row-chainingthat would cause additional reads.

To identify tablespaces and the physical data file names that are performing large numbersof reads and writes, use the following SQL command:

select vtablespace.name tablespace_name,

vdatafile.name datafile_name,

vfilestat.phyrds physical_reads,

vfilestat.phywrts physical_writes,

vfilestat.avgiotim average_time_for_io

from v$datafile vdatafile,

v$filestat vfilestat,

v$tablespace vtablespace

where vdatafile.file# = vfilestat.file#

and vdatafile.ts# = vtablespace.ts#;

The previous SQL shows you the average time it takes for an I/O transaction. If the I/O

time is unacceptable, investigate for contention on the underlying disk drives and consider

reconfiguring disk drives.

SYSTEM Tablespace

The SYSTEM tablespace is a special tablespace that contains information about the current

instance and database. The SYSTEM tablespace contains the data dictionary, which

consists of tables that define every object created. Do not place user-defined objects in this

tablespace. User-defined objects in the SYSTEM tablespace is almost always the cause of

issues with the SYSTEM tablespace or its underlying physical data file.

TEMPORARY Tablespace

The TEMPORARY tablespace sorts and holds temporary segments when a user runs an

SQL statement requiring sorting or does database maintenance that creates temporary

segments. A users TEMPORARY tablespace for sorting is assigned in one of three ways.

Default tablespace is assigned to the user.

A default TEMPORARY tablespace is assigned for the entire database.

A TEMPORARY tablespace is group assigned.


19/24

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Undo Tablespace


If you have contention against TEMPORARY tablespaces, use TEMPORARY tablespace

groups. Here are some of the advantages of using TEMPORARY tablespace groups:

You can create multiple TEMPORARY tablespaces, assign them to a tablespace group,and use the tablespace group as the default TEMPORARY tablespace for the database or

user.

You can place multiple tablespaces on separate disk drives more easily, thus reducingthe I/O contention between them.

You can reduce contention between a single SQL statement, or a set of SQLstatements, thus reducing disk drive I/O contention.

You can allow large sort operations to span and consume multiple TEMPORARYtablespaces if needed.

You can manage the TEMPORARY tablespace more easily.

You can have a fewer islands ofTEMPORARY tablespaces scattered through database.

Undo Tablespace

The Oracle UNDO tablespace is used to store critical information for the possibility that a

ROLLBACK command will be issued, and changes made after the last COMMIT point will

be backed out. UNDO is also used to recover a database from failure by applying undo

records to roll back any uncommitted changes. The UNDO records also provide read-

consistency to satisfy a result set that is guaranteed at the time you issue data manipulation

language (DML) commands in relation to other users changing data mid-stream of your

result set. You might face a problem with the UNDO tablespace if the undo that you have

created can not provide sufficient consistency and recovery for the transaction mix on

your database system.

Use the Undo Advisor to answer questions on how the undo configuration is performing

for current work loads. Here is a sample of function calls to the Undo Advisor package,

DBMS_UNDO_ADV.


20/24



You might want to migrate databases to automatic undo management. See Oracle

documentation for procedure to migrate databases to automatic undo management: http://

www.oracle.com/technology/software/tech/orion/index.html.

If you migrate databases to automatic undo management, you should still occasionally

review the undo area and verify the I/O requirements of this tablespace.

Table 1 Function Calls to the Undo Advisor

Function Description

undo_info Basic UNDO information:

Tablespace Name

Current retention value

If undo is auto extensible

If undo is guaranteed undo retention

longest_query Longest running query. Use the LONGEST_QUERY function to

tune in relation to time.

required_retention Retention value is based on the longest running query. Use the

REQUIRED_RETENTION function to determine how to set the

UNDO_RETENTION function to help prevent snap-shot-too-old

errors.

best_possible_retention Undo_retention that best fits your parameters. Use theBEST_POSSIBLE_RETENTION function to determine the

best undo fit for your current undo tablespace size and usage.

required_undo_size Size of the undo tablespace needed for INIT.ORA parameter

UNDO_RETENTION.

undo_health Any problems encountered with your current undo tablespace

size or setting of the init.ora parameter undo_retention and

recommendations for fixing.

undo_advisor Descriptive output on any problems encountered and possible

resolutions.

undo_autotune Undo_auto tuning for undo retention can be either enabled or

disabled.

rbu_migration Size required for undo tablespace size. Use rbu_migration

information for switching to automatic undo management.
http://www.oracle.com/technology/software/tech/orion/index.htmlhttp://www.oracle.com/technology/software/tech/orion/index.htmlhttp://www.oracle.com/technology/software/tech/orion/index.htmlhttp://www.oracle.com/technology/software/tech/orion/index.html


21/24

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion


Conclusion

A clear understanding of how Oracle objects map to the physical files on a storage array is

essential for tuning an Oracle database and the underlying storage array. By pinpointing

activity on Oracle objects through monitoring of Oracle segments, you can detect andreduce contention, and improve database performance. Because the physical operating

system files map to Oracle logical structures at the segment level, you can monitor the

segments associated with database objects. To improve the performance of the storage

subsystem, use the mapping to identify problems and ultimately tune those aspects of

Oracle that relate to the physical data files on the storage subsystem.

Examining RAID levels, redo logs and tablespace provide you with a better understanding

of how database files impact system performance. You can then use this information to

tune Oracle and the underlying storage subsystem.

Whenever you increase database performance through structures that interface with the

storage, you experience performance gains on the storage array.

Contact Information

For more information and sales office locations, visit the IBM web sites at:

http://www.ibm.com
http://www.ibm.com/http://www.ibm.com/


22/24




23/24

No part of this document may be reproduced or transmitted in any form without written permission from

IBM Corporation.

Product data has been reviewed for accuracy as of the date of initial publication. Product data is subject to

change without notice. This document could include technical inaccuracies or typographical errors. IBM

may make improvements and/or changes in the product(s) and/or program(s) described herein at any time

without notice. Any statements regarding IBM's future direction and intent are subject to change orwithdrawal without notice, and represent goals and objectives only. References in this document to IBM

products, programs, or services does not imply that IBM intends to make such products, programs or

services available in all countries in which IBM operates or does business. Any reference to an IBM

Program Product in this document is not intended to state or imply that only that program product may be

used. Any functionally equivalent program, that does not infringe IBM's intellectually property rights, may

be used instead.

THE INFORMATION PROVIDED IN THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY

WARRANTY, EITHER EXPRESS OR IMPLIED. IBM EXPRESSLY DISCLAIMS ANY WARRANTIES

OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NONINFRINGEMENT. IBM

shall have no responsibility to update this information. IBM products are warranted, if at all, according to

the terms and conditions of the agreements (e.g., IBM Customer Agreement, Statement of Limited Warranty,

International Program License Agreement, etc.) under which they are provided. Information concerningnon-IBM products was obtained from the suppliers of those products, their published announcements or

other publicly available sources. IBM has not tested those products in connection with this publication and

cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products.

IBM makes no representations or warranties, expressed or implied, regarding non-IBM products and

services.

The provision of the information contained herein is not intended to, and does not, grant any right or license

under any IBM patents or copyrights. Inquiries regarding patent or copyright licenses should be made, in

writing, to:

IBM Director of Licensing

IBM Corporation

North Castle DriveArmonk, NY 10504-1785

U.S.A.


24/24

Legal Information and Trademarks

AIX*, IBM logo*, DB2 Universal Database*, IBM eServer*, Magstar*, OS/390*, OS/400*, e-business

logo*, ESCON*, FICON*, IBM*, S/390*, Tivoli*, TotalStorage*, WebSphere*, iSeries*, pSeries*,

xSeries*, xSeries*, System Storage*

* Registered trademarks of IBM Corporation

Intel is a trademark of the Intel Corporation in the United States and other countries.

Java and all Java-related trademarks and logos are trademarks or registered trademarks of Sun

Microsystems, Inc., in the United States and other countries.

Lotus, Notes, and Domino are trademarks or registered trademarks of Lotus Development Corporation.

Linux is a registered trademark of Linus Torvalds.

Microsoft, Windows and Windows NT are registered trademarks of Microsoft Corporation.

SET and Secure Electronic Transaction are trademarks owned by SET Secure Electronic Transaction LLC.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Notes:

Performance is in Internal Throughput Rate (ITR) ratio based on measurements and projections usingstandard IBM benchmarks in a controlled environment. The actual throughput that any user will experience

will vary depending upon considerations such as the amount of multiprogramming in the user's job stream,

the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can

be given that an individual user will achieve throughput improvements equivalent to the performance ratios

stated here.

IBM hardware products are manufactured from new parts, or new and serviceable used parts. Regardless,

our warranty terms apply.

All customer examples cited or described in this presentation are presented as illustrations of the manner in

which some customers have used IBM products and the results they may have achieved. Actual

environmental costs and performance characteristics will vary depending on individual customer

configurations and conditions.

This publication was produced in the United States. IBM may not offer the products, services or features

discussed in this document in other countries, and the information may be subject to change without notice.

Consult your local IBM business contact for information on the product or services available in your area.

All statements regarding IBM's future direction and intent are subject to change or withdrawal without

notice, and represent goals and objectives only.

Information about non-IBM products is obtained from the manufacturers of those products or their

published announcements. IBM has not tested those products and cannot confirm the performance,

compatibility, or any other claims related to non-IBM products. Questions on the capabilities of non-IBM

products should be addressed to the suppliers of those products.

Prices subject to change without notice. Contact your IBM representative or Business Partner for the most

current pricing in your geography.

TSW03008-USEN-00

Documents

Tuning Oracle With Consideration for Storage Snd Oracle Database Files