Professional Documents
Culture Documents
Oracle Performance Tuning Part 7
Oracle Performance Tuning Part 7
profile
Composite Default screen
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:169
CHAPTER
7
Instance TuningThe
Redo Log Buffer and
Miscellaneous Tuning
Copyright 2001 by The McGraw-Hill Companies. All rights reserved. Printed in the United States of America. Except as permitted under the
Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a database or retrieval
system, without the prior written permission of the publisher, with the exception that the program listings may be entered, stored, and executed in a
computer system, but they may not be reproduced for publication.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Screen displays of copyrighted Oracle software programs have been reproduced herein with the permission of Oracle Corporation and/or its affiliates.
Information has been obtained by Publisher from sources believed to be reliable. However, because of the possibility of human or mechanical error
by our sources, Publisher, or others, Publisher does not guarantee to the accuracy, adequacy, or completeness of any information included in this
work and is not responsible for any errors or omissions or the results obtained from the use of such information.
Oracle Corporation does not make any representations or warranties as to the accuracy, adequacy, or completeness of any information contained in
this Work, and is not responsible for any errors or omissions.
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:19 AM
170
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:170
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:20 AM
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:171
Chapter 7:
is usually not reachable. This tuning effort is accomplished by tuning the Oracle
optimizer. The task of tuning the Oracle optimizer should be undertaken only after
all of the tuning methods outlined in the previous chapters have been exhausted.
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:20 AM
171
172
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:172
its memory structures), and that soon to be famous band, LGWR and the redo logs.
The order of events is very important here. Lets review this process, as it changed
significantly in Oracle 7.3:
1. A user process issues an insert, update, or delete statement. Let us assume
that it is the start of a transaction and Oracle assigns a transaction identifier
for this operation.
2. The server process associated with the user process reads the required data,
index, and rollback blocks into memory and locks the relevant row(s) that
require manipulation.
3. The server process then acquires what is called a redo copy latch first.
Acquiring this redo copy latch is a prerequisite condition before the process
can write to the redo log buffer. However, the write does not take place just
yet. It is useful to note that there are as many redo copy latches as are defined
by the Oracle initialization parameter LOG_SIMULTANEOUS_COPIES. This
parameter is obsolete in Oracle8i (automatically set to two times the number
of CPUs). But in prior releases, such as in Oracle 7.3.x, this parameter could
be set to the allowed maximum of two times the number of CPUs. In Oracle8,
this parameter could be set to up to eight times the number of CPUs. On
some operating system platforms, the support for eight times the number of
CPUs was back-ported to Oracle 7.3.4. There is no measurable overhead of
setting this to the platform-specific maximums.
4. The server process then acquires the redo allocation latch to reserve space in
the redo log buffer. The amount of space is dependent on the size of the redo
entry to be written. As soon as the space is reserved, the redo allocation latch
is released, as there is only one redo allocation latch per database and
hogging this latch can cause significant performance problems.
5. The server process then writes the redo entry into the redo log buffer using
the redo copy latch. (The redo entries when written to the redo log files are
used to recover one or more components of Oracle in the event of instance
or media failure.)
6. The server process then releases the redo copy latch.
7. Once the redo information is written into the redo log buffer, the server
process writes the rollback information into the blocks of the rollback
segment assigned to the transaction. This is used in the event the user process
issues a rollback instead of a commit. Please note that rollback entries also
generate a redo of their own and must also be logged in the redo log buffer.
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:20 AM
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:173
Chapter 7:
8. Now that all the bases are covered to protect the transaction (including the
data that is about to change) the server process can now update the row(s)
in the data and the index blocks.
NOTE
Given that the redo log buffer is a circular buffer,
simultaneous writes to this memory structure can
and will happen. This is of course subject to how
quickly the redo allocation latch is acquired and
released. Also note that the processing of the redo
information takes precedence over all other data
changes or activity. From a tuning perspective this
means that anything that holds up getting that
information into the redo log buffer will hold up
everything else. So keep this little guy in the SGA
happy! Remember the copy boy story!
LGWR writes the redo log buffer to disk on one of the following events:
Every three seconds (independent of DBWR). Yes, from Oracle8 and up, it
has its own timer.
On a commit. Remember that the write of the redo entry must physically be
completed before control is returned to the program issuing the commit.
Whenever redo information equal to one third of the size of the redo log
buffer has been written to the redo log buffer. For example, if the size of the
redo log buffer is 131072 bytes, when 43690 bytes of new information has
been written to the redo log buffer, LGWR will copy the new redo information
to disk. Starting from Oracle8, LGWR will write to the redo logs when MIN
(1MB,LOG_BUFFER/3) is true. This is to support better performance when
Oracle instances are configured with large redo log buffers. However, this
fact should not be misunderstood as a recommendation to set larger redo
log buffers. The point we are trying to make here is not that the redo log
buffer will never get more than one-third full. What we are trying to
communicate is that when it reaches the one-third full threshold, LGWR
will write the contents of the redo log buffer. However, given the circular
nature of the buffer, the remaining two-thirds of the buffer will be utilized
for writes by other server processes that need to write to the redo log buffer.
From Oracle8 and up, this one-third write will not exceed a size of 1MB (in
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:20 AM
173
174
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:174
the event the instance is configured with a redo log buffer larger than 3MB)
per the above formula. Said another way, if you size your redo log buffer at
15MB, LGWR will initiate a write when 1MB worth of redo entries have
been written to the redo log buffer. It should be noted here that in our tests
we could not find any evidence to corroborate the consistent working of
the one-third full event. The threshold at which LGWR was writing varied
significantly from one-sixth full to two-thirds full. Dont count on this one.
At checkpoints.
When posted by the DBWR process. But you must always remember that
modified data blocks in a database are always written after the corresponding
redo entries for those blocks are written to disk.
The size of this buffer can be seen immediately after starting an instance on the
line for Redo log buffers in the messages from the startup command:
SVRMGR> startup
ORACLE instance started.
Total System Global Area
Fixed Size
Variable Size
Database Buffers
Redo log buffers
Database mounted.
Database opened.
48572320
64912
45137920
2048000
524288
bytes
bytes
bytes
bytes
bytes
This is the value in bytes. The default for this parameter varies from version to
version. In Oracle 8.0, the smallest size allocated for the redo log buffer is 73728
bytes (72K). In Oracle 8.1.5, the default value is 524288 bytes (512K).
It is recommended to start with a smaller value and increase the size as needed
until this resource is no longer the point of contention. We have seen many database
administrators start with LOG_BUFFER = 131072 (128K) for their environments. And
thats a good size to start with. Increase the size only if there are wait events associated
with the redo log buffer (this is discussed later in the Wait Events that Affect the
Redo Log Buffer section). If your redo log buffer is, say, 32MB, chances are that
it is oversized and you may be wasting memory. Check the wait events in your
database for more information.
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:21 AM
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:175
Chapter 7:
LOG_SIMULTANEOUS_COPIES
P:\010Comp\Oracle8\145-4\ch07.vp
Wednesday, July 11, 2001 3:55:26 PM
175
176
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:176
latch free
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:21 AM
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:177
Chapter 7:
by one or more log file events (listed in the previous section), it indicates that the
problem is likely with the I/O system.
If you find latch free events along with the log buffer space events, you can
be sure there is a latch or redo log sizing issue. By querying V$LATCH for the
redo copy latch and redo allocation latch you can see the latch statistics. This
will confirm that there is a latch problem when the ratio of misses to gets or
immediate_misses to immediate_gets is greater than 1 percent. This can be
corrected by setting the value of LOG_SIMULTANEOUS_COPIES to the
platform allowed maximum (obsolete in Oracle8i). This increases the number
of copy latches. In fact, you can avoid dealing with this at all by setting that
maximum value at the outset. In Oracle8i, LOG_SIMULTANEOUS_COPIES is
auto-configured to two times the number of CPUs on the system.
So if the latches are in good order, the problem has to be that the server process
cant get space in the redo log buffer. It comes into play when we realize that the
redo log buffer is not being flushed fast or often enough. Making the redo log buffer
larger is not a big deal, but experience has shown that it is possible to reach a point
of diminishing returns very quickly. You should not increase the size of your redo
log buffer unless you have concrete evidence that warrants it in V$SESSION_WAIT.
VIP
From a pure I/O perspective, the most common
mistake is to put the redo logs with database files
or other types of files. This creates competition for
resources where it is least tolerated. Redo logs need
to go on independent storage devices, and they
need to be separated from all other files to perform
optimally. Dont forget that redo log switches on
archiving databases are also subject to the
limitations of how fast the redo logs can be safely
copied and made available to LGWR again. So
check your redo logs and make sure they are on
properly configured storage devices. Remember,
you dont want to overload the copy boy and have
him perform mailroom tasks and run errands for
you. If you do, you run the risk of preventing him
from doing his job right.
After correcting any storage device layout issues, it is safe to resize the redo log
buffer (if needed). Change the value for LOG_BUFFER in the initialization file and
restart the instance. You can start with a size of 128K or 256K and monitor the database
for redo log buffer-related wait events. If it is already getting largesay, more than
1MBsomething less dramatic might be in order. In fact, the database may be
experiencing a point of diminishing returns with regard to sizing the redo log buffer.
P:\010Comp\Oracle8\145-4\ch07.vp
Wednesday, July 11, 2001 3:55:50 PM
177
178
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:178
The sure-fire method to calculate the optimal size for the redo log buffer (or any other
memory structure, for that matter) should be based on wait events and wait events only.
Checkpoints
No, these are not guardposts on the border! They are moments in time when Oracle
makes sure that everything has been synchronized. They occur naturally every time
a log switch occurs or any time a DBA issues an alter system checkpoint command.
They create and record known synchronization points in the database so that recovery
can be easily facilitated in the event of an instance or a media failure. Occasionally, it
is useful to have them performed more often than nature dictates. To increase the
frequency of checkpoints, you can use either the LOG_CHECKPOINT_INTERVAL
or LOG_CHECKPOINT_TIMEOUT Oracle initialization parameter. The former
parameter is I/O-based and is set to the number of OS blocks worth of information
that must be written to the redo log files before a checkpoint is initiated. The latter
parameter is time-based and indirectly controls the maximum duration that dirty
blocks can remain in the database buffer cache. The definition of LOG_CHECKPOINT_
TIMEOUT has changed in Oracle8i.
Also it is useful to observe that checkpoints no longer occur on log switches.
They actually occur before a log switch. Obviously both aforementioned parameters
keep the previous checkpoint as a point of reference. Just remember that checkpoints
take resources and can impact system performance when done very frequently.
In our production experience, we have configured LOG_CHECKPOINT_
INTERVAL to a high number or 0 (the effect is the same), so that checkpoints occur
only during log switches. It is okay to leave LOG_CHECKPOINTS_TIMEOUT to its
default value of 0 (1800 in Oracle8i) so long as your system performs okay with
checkpoints on log switches only. But if these parameters are configured in the
aforementioned method, the redo log files need to be sized appropriately. Although
it is difficult to generalize the optimal frequency of log switching as it is dependent
on a variety of issues (such as whether you are running a standby database, what
your service level agreement for instance recovery is, and so on), it is safe to say that
the number of log switches in your system should not average more than one every
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:22 AM
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:179
Chapter 7:
P:\010Comp\Oracle8\145-4\ch07.vp
Wednesday, July 11, 2001 3:56:12 PM
179
180
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:180
Administrator Guide for more information on how to configure multiple redo logs and
redo log groups. Here we are concerned with their physical size and how this affects the
performance of your database.
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:22 AM
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:181
Chapter 7:
some experiments conducted by Craig Shallahamer of OraPub Inc.) suggests that the
law of diminishing returns kicks in around ten redo log groups. So for redo-heavy
systems, you may consider configuring more online redo log groups than the
minimum requirement of two groups.
Archiving
Once a database is put in archivelog mode, it is necessary to turn on the ARCH
process for automatic archiving of redo logs when log switches occur. The ARCH
process copies the redo logs to one or more destinations (depending on your Oracle
version). Configuring this in a proper fashion ensures that the archive logs are written
without any contention and, more importantly, are readily available when needed for
recovery. Configuring it haphazardly can create contention on storage devices. Apart
from using optimal storage devices and avoiding competition from other files, the
archive process can be tuned by setting LOG_ARCHIVE_BUFFERS and LOG_
ARCHIVE_BUFFER_SIZE. It must be noted that both of these parameters are
de-supported in Oracle8i. Oracle recommends leaving this at the default, but if the
archive system is having trouble keeping up, these parameters should be modified to
improve things. When required we have set this to the platform-specific maximums
and have had good archiving performance. But remember that creating multiple redo
log groups with multiple members has a higher probability of better performance.
Using multiple log members in a redo log file group will also speed up the
archiving process. All members in a group are used to perform the archiving process.
Oracle will optimize the archiving process by reading portions of data at a time from
all log members in a staggered round-robin fashion to distribute I/O. The benefit of
defining multiple log members rather than mirroring them at the OS level may
translate into some performance gains. Oracle does not see the multiple members
created via OS mirroring, but will effectively use all log members within a group to
optimize archiving process.
P:\010Comp\Oracle8\145-4\ch07.vp
Wednesday, July 11, 2001 3:56:27 PM
181
182
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:182
LOG_ARCHIVE_FORMAT
LOG_ARCHIVE_DEST
LOG_ARCHIVE_
MIN_SUCCEED_DEST
LOG_ARCHIVE_BUFFER_SIZE
LOG_ARCHIVE_BUFFERS
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:23 AM
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:183
Chapter 7:
LOG_CHECKPOINT_INTERVAL
LOG_CHECKPOINT_TIMEOUT
ARCH_IO_SLAVES
LGWR_IO_SLAVES
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:23 AM
183
184
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:184
And faster it was. With significant improvements in its kernel, added by support
for database partitioning, faster connectivity, and a variety of other features, it truly
was a major release. For some of us who had lived through the many bad hair days
trying to migrate from Oracle6 to Oracle7, we thought it was time to live a little (we
were definitely influenced by the marketing hype). We decided to dive into Oracle8
with our head hitting the water first. Thankfully the point of contact of the dive did
not feel like a ton of bricks. We were pleasantly surprised at the relative ease when
we compared it to the Oracle6 to Oracle7 migration. For starters, the migration utility
actually worked. Now that was like a breath of fresh air, as some of the databases that
we supported would have taken many hours to export and then many days to import.
It is hard to believe that Oracle8 is only four years oldit sure does seem longer
than that. Is that a sign of our old age? The long feeling could be attributed to the
fact that One year in the Oracle IT industry really is equivalent to seven normal
years. For those of you who have been around the block, you know exactly what we
mean. The calculation, and the fact that we have been working with Oracle8 for four
years, puts our combined experience at 56 years. Now, there is an explanation for that
long and maybe even old feeling!
One of the major features that made a great positive impact was the optimizers
capability to perform partition-aware processing of large tables and indexes. This
made a night and day difference in performance of the data warehouses of those
days. Plus, the support for some specialized parameters that controlled its behavior
further lent flexibility in configuring the Oracle optimizer.
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:23 AM
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:185
Chapter 7:
this book) have been exhausted. The working efficacy of these parameters should be
tested thoroughly before implementing them in a production environment.
WARNING
We have successfully implemented all of the
parameters discussed in this section at many large
production sites to produce predictable results.
However, it is your responsibility to test them in
your environment before implementing them.
These parameters are most significant for third-party packaged applications
where the code is usually inaccessible. They are also relevant for environments that
require hash joins for batch processing, but need the control mechanisms to hold
back the optimizer from being over-influenced by the hash join method for transactional
processing. And, by the way, hash joins are not as bad as people make them out to be.
Most of these parameters are relevant from Oracle 8.0.5, but some of them may
have been back-ported to prior releases. We thank Probal Shome of Oracle
Corporation for sharing his expertise and insight with us during the Oracle Open
World 1999 conference, with his paper Using Stored Outlines in Oracle 8i for Plan
Stability and the long and lively discussion that ensued. Bottom line, this section is
worth your time and effort if you are running any third-party packaged applications.
So without too much ado, go ahead and check it out.
OPTIMIZER_MAX_PERMUTATIONS
This parameter restricts the number of permutations of the tables the optimizer will
consider in queries with joins. Such a restriction ensures that the parse time for the
query stays within acceptable limits. However, a slight risk exists that the optimizer
will overlook a good plan it would otherwise have found. It also lets you limit the
amount of work the optimizer expends on optimizing queries with large joins. The
value of the integer is the number of permutations of the tables the optimizer will
consider with large joins.
OPTIMIZER_MAX_PERMUTATIONS defaults to a value of 80,000. When set
to a value below 80,000 (say, 79,000), it forces the optimizer to try up to eight
different tables as the driving table for queries that involve joins. This usually
results in the optimizer picking the least expensive of the 79,000 plans that it
generates. Said in another way, this parameter provides more options to decide
the order of joining tables for a given query. The default behavior (with the
default value) is to build a plan usually with the smallest table as the driving table.
This default behavior may not always generate the most suitable plan and the
performance you expected, especially for the third-party packaged applications.
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:23 AM
185
186
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:186
When this parameter is set, it does result in a nominal increase in the parse time of
the SQL statements. But in the bigger scheme of things, this nominal increase in parse
time is well worth the overhead when compared to the significant reduction in the
execution time of SQL statements.
OPTIMIZER_INDEX_COST_ADJ
This parameter directly adjusts the cost of using an index. The default value of 100
makes the optimizer evaluate the cost of the index as normal, and a value of 50 makes
the optimizer evaluate the cost to be half as expensive as normal. This parameter
encourages the use of all indexes, regardless of their selectivity. It applies to index use
in general. The range of values for this parameter is 110,000. When set to a low value
(say, 110), the optimizer is encouraged to perform index scans over full table scans.
OPTIMIZER_SEARCH_LIMIT
This parameter defaults to a value of 5. When set to a value of 1, the optimizer is
totally discouraged from considering cartesian product as the execution method.
With its default value of 5, the optimizer can and will perform cartesian product (if
applicable) for queries with five or fewer tables in the FROM clause. This behavior
of performing cartesian products may be acceptable for small tables, but for obvious
reasons is a no-no for large tables. Depending on the nature of the application, this
parameter needs to be adjusted. If you are seeing cartesian product execution plans,
you may want to set this parameter to 1.
NOTE
A cartesian product between two tables with 100
rows each will generate a result set of 10,000 rows.
Hence as the size of a table increases the cost of
performing a cartesian product increases
proportionately. Watch out for this one!
OPTIMIZER_INDEX_CACHING
This parameter defaults to a value of 0. The range of values for this parameter is
0100. When set to a high value (say, 99), the optimizer is encouraged to use the
nested loops join method over other methods. This parameter is especially useful
if the initialization parameter HASH_JOIN_ENABLED is set to TRUE and
HASH_MULTIBLOCK_IO_COUNT is set to a non-default value (say, equal to
DB_FILE_MULTIBLOCK_READ_COUNT). Setting this parameter to a high value
of 99 provides the capability to have the cake and eat it too. This is because the
default value for this parameter will put undue influence on the optimizer to consider
hash joins over all other joins (when HASH_JOIN_ENABLED is set to TRUE).
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:24 AM
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:187
Chapter 7:
Hash joins are suitable for applications, where a small table(s) joined to a very large
table(s), and the where clause predicates cause processing of a significant portion of
the large table(s). Hash joins are also suitable for applications that join two or more
large tables. Both scenarios mentioned here are relevant for batch processing where
the application usually processes a significant amount of data. Configuring this
parameter to a value of 99 does not necessarily turn off hash joins, but does hold
back the optimizer from going overboard with hash joins as the default join method.
NOTE
Please exercise due diligence in monitoring the
performance of your batch reports after setting this
parameter. In some very special scenarios, it is
possible for some of your batch reports to require a
USE_HASH hint.
In a Nutshell
Tuning the redo mechanism, including the redo log buffer, is one of the final things
to tune as part of instance tuning. You can go ahead and always set the value of the
Oracle initialization parameter LOG_SIMULTANEOUS_COPIES to the platform-specific
maximum if your Oracle database version is prior to Oracle8i. This proactively
avoids redo copy latch problems that occur due to lack of latches. Then set the size
of the redo log buffer to a reasonable starting value by setting LOG_BUFFER =
131072 (128K). Some folks start with 256K as well. Be cautious, though, as getting
too aggressive with this can create more problems than it fixes. Increase this value
if you observe the log buffer space wait event. However, if you also observe wait
events such as log file switch, log file sync, or log file parallel write, there may be
an underlying I/O issue. If this is the case, ensure that the redo logs and the archive
logs are on independent devices separated from the data files of the database.
The archiving system can be tuned by setting LOG_ARCHIVE_BUFFER_SIZE
and LOG_ARCHIVE_BUFFERS. Additionally, tune checkpoints by ensuring that
they occur only on log switches. Size the redo log files appropriately to control
checkpoint frequency, and allow sufficient time for the checkpoint process to
complete so you wont get those pesky checkpoint not complete messages.
Also ensure that they are on independent storage devices, as they need their
space (if you know what we mean). Though gains in this section of instance
tuning are not as significant as the other areas, you need to proactively configure
this. Every little bit (and byte) counts!
We are all aware that most third-party packaged application vendors, in their
efforts to encapsulate the complexity of their application, bury their SQL many
fathoms below sea level and make it unreachable to mortals such as us. We studied
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:24 AM
187
188
Series / Oracle Performance Tuning 101 / Vaidyanatha & Kostelac Jr. / 3145-4 / Chapter 7
Blind Folio 7:188
in good detail some instance-level tuning opportunities that are supported since
Oracle8, which modify the behavior of the Oracle optimizer and thus make these
packaged applications more amenable to our tuning efforts. And that ends the
broadcast on this chapter!
P:\010Comp\Oracle8\145-4\ch07.vp
Monday, May 14, 2001 11:48:24 AM
1002
O R I G I N A L AU T H E N T I C
O N LY F R O M O S B O R N E
resources, go to
OraclePressBooks.com.
Enter-to-win contests
technologies at OraclePressBooks.com
O R A C L E P R E S S E X C L U S I V E LY F R O M M c G R AW- H I L L / O S B O R N E
TM