Oracle Performance Tuning, 2nd Edition
by Mark Gurry and Peter Corrigan


Unconfirmed error reports are from readers. They have not yet been 
approved or disproved by the author or editor and represent solely the
opinion of the reader.

If you have any error reports or technical questions, you can send them to
booktech@oreilly.com. (Please specify the printing date of your copy.)


This page was last updated on June 30, 2004


Here's a key to the markup:

        [page-number]: serious technical mistake
        {page-number}: minor technical mistake
        <page-number>: important language/formatting problem
        (page-number): language change or minor formatting problem
        ?page-number?: reader question or request for clarification


UNCONFIRMED errors and comments from readers:


{181}  Second line in the example;
In the second example of %FOUND Attribute it is written:

    EXIT WHEN order_cur%NOTFOUND;

In my opinion, because the example was of %FOUND, I think it should be:

    EXIT WHEN NOT order_cur%FOUND;

But anyway, this does not make any diference in the execution.


[222]  Final paragraph;
This paragraph states "You will get better performance if you declare explicit 
cursors".  

Implicit cursors consistently execute faster than explicit cursors.  These resu
lts come from executing single row queries 10000 times against an Oracle 8.1.6 
database:

-- select * from sys.dual
Explicit Elapsed 1.83
Implicit Elapsed 1.49
-- select cus_ref_seq.nextval from sys.dual
Explicit Elapsed 2.52
Implicit Elapsed 2.12
-- select add_id from addresses where add_id = 1 (unique index)
Explicit Elapsed 1.51
Implicit Elapsed 1.15
-- select id from clarkea.tst22 where cola = 'A' (no index)
Explicit Elapsed 1.69
Implicit Elapsed 1.33
 
But I've also tried it on a 7.3.4 database and the performance gap is even wide
r.

I'm bringing this to your attention because I checked my copy of your book to c
linch an argument but was subsequently proved wrong by empirical evidence.  My 
copy is the 1996 printing, but I couldn't find this in the errata for any of th
e subsequent printings.


[400]  third paragraph;
PARALLEL_FROM_SERIAL
Many processes perform the table scan and hand the output to a single process.

should be:

PARALLEL_FROM_SERIAL
The table scan is performed by a single process and the data is passed to a number of
processes running in parallel.



(472) The code example in the fifth paragraph now reads:

	# decbcach.sql

Should read:

	incbcach.sql


<678> The first paragraph in the "Tuning EXPORT" section reads:

	"The EXPORT utility, the most common tool for an Oracle database
	backup, produces a flat ASCII file that can be transported from one
	hardware platform to another"

This is incorrect. Files produced by export can be transported from platform 
to platform BUT they are not flat ASCII files. They are stored in BINARY 
format.


(colophon)  At least one of what the colophon calls bees is actually a hornet.