Tuning Oracle With Consideration For Storage SND Oracle Database Files

Tuning Oracle with Consideration for
Storage and Oracle Database Files
James F. Koopmann
Technical White Paper

30128-00, Rev. A
February 2007
Copyright © 2007 by International Business Machines Corporation. All rights reserved.
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
Tuning Oracle: Oracle Database Files iii

iv Tuning Oracle: Oracle Database Files
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
Tuning Oracle: Oracle Database Files 1-1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
• 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 this
information 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 your
environment. By understanding these tuning strategies, you will be better equipped to tune
the Oracle database to meet today’s needs and to prepare for tomorrow’s needs.
1-2 Tuning Oracle: Oracle Database Files

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 is
striped 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 and
functional redundancy, regeneration, and reconstruction.
RAID 1 A redundant Redundant Array of Independent Disks (RAID) level in which identical copies
of 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 data
and redundancy are striped across a array or logical drive. The equivalent of one drive
capacity 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.

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.

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, and
place 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 striping
tool. 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 without
further 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 the
performance of your database and hamper recovery time in the event of a database
failure.

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 the
storage 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”,
1,0)),'99') “01”,
1,0)),'99') “02”,
1,0)),'99') “03”,
1,0)),'99') “04”,
1,0)),'99') “05”,
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”,

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sizing Redo Logs
1,0)),'99') “16”,
1,0)),'99') “17”,
1,0)),'99') “18”,
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_RECOVERY view for the OPTIMAL_LOGFILE_SIZE value, in MB:
SELECT OPTIMAL_LOGFILE_SIZE FROM V$INSTANCE_RECOVERY;
Use the recommended optimal logfile size value to rebuild the redo log groups.

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 disk
drives.
• Keep redo logs separate from other database files.
• Consider striping all redo logs across a set of disk drives, but monitor carefully for
contention.
• Watch the I/O rates, or log switching activity to the archive area, and configure disk
drives to handle the I/O rates.

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 write
information 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.

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.
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 the V$SEGSTAT_NAME view are only sampled
while the others are accumulated. The STATISTICS# view is not the
same as in the V$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.
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.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 the WHERE clause.
select owner,object_type,object_name,value
from V$SEGMENT_STATISTICS
where (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

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

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 through
segments.
• 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 two
objects that are used in the same SQL query in different tablespaces and at different
locations on disk drive.
• Do not put an object’s indexes in the same tablespace as the object.
• Put similarly accessed objects together to allow for easy placement on a disk drive that
will have the same configuration (RAID level, caching, segment size, and similar
attributes).
• Put similarly maintained objects together to allow for maintenance at the tablespace
level.
• Watch for volatile objects and do not place them in the same tablespaces as stable
objects. For instance if an application creates and drops objects regularly, dedicate a
tablespace for its operations.

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-chaining
that would cause additional reads.
To identify tablespaces and the physical data file names that are performing large numbers
of 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 user’s 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.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 reducing
the I/O contention between them.
• You can reduce contention between a single SQL statement, or a set of SQL
statements, thus reducing disk drive I/O contention.
• You can allow large sort operations to span and consume multiple TEMPORARY
tablespaces if needed.
• You can manage the TEMPORARY tablespace more easily.
• You can have a fewer islands of TEMPORARY 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 user’s 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.

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 the
BEST_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.
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.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 and
reduce 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


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 or
withdrawal 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 concerning
non-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 Drive
Armonk, NY 10504-1785
U.S.A.
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 using
standard 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

Tuning Oracle With Consideration For Storage SND Oracle Database Files

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tuning Oracle With Consideration For Storage SND Oracle Database Files

Transféré par

Droits d'auteur :

Formats disponibles

Tuning Oracle with Consideration for

Storage and Oracle Database Files

Technical White Paper

Chapter 2: DETERMINING RAID LEVELS

Chapter 3: REDO LOGS

Chapter 4: CONTROL FILES

Chapter 5: DISTRIBUTING TABLESPACE

Tuning Oracle: Oracle Database Files iii

Tuning Oracle: Oracle Database Files 1-1

1-2 Tuning Oracle: Oracle Database Files

Table 2-1 RAID Levels and Descriptions

Raid Level Description

Tuning Oracle: Oracle Database Files 2-1

2-2 Tuning Oracle: Oracle Database Files

Reducing Redo Log Contention

Tuning Oracle: Oracle Database Files 3-1

Sizing Redo Logs

Sizing Redo Logs: SQL Method

3-2 Tuning Oracle: Oracle Database Files

Sizing Redo Logs Using the Redo Log Sizing Advisor

Tuning Oracle: Oracle Database Files 3-3

Archived Redo Logs

3-4 Tuning Oracle: Oracle Database Files

Segment Level Statistics

Tuning Oracle: Oracle Database Files 4-1

Table 4-1 Segment-Level Statistics

To check the setting for STATISTICS_LEVEL, use this command:

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

Investigating System Level Performance Problems

4-2 Tuning Oracle: Oracle Database Files

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

Tuning Oracle: Oracle Database Files 4-3

4-4 Tuning Oracle: Oracle Database Files

Tuning Oracle: Oracle Database Files 5-1

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

5-2 Tuning Oracle: Oracle Database Files

If you have contention against TEMPORARY tablespaces, use TEMPORARY tablespace

Tuning Oracle: Oracle Database Files 5-3

Table 1 Function Calls to the Undo Advisor

5-4 Tuning Oracle: Oracle Database Files

Tuning Oracle: Oracle Database Files 5-5

5-6 Tuning Oracle: Oracle Database Files

IBM Director of Licensing

* Registered trademarks of IBM Corporation

Vous aimerez peut-être aussi