I would be a little surprised if the problem relates to
dynamic memory management, or the use of the
db_cache_size parameter.
However, it is possible that you managed to
change the number of db block buffers available
quite dramatically - which could have an effect
on the size at which a table is considered to be
a 'small' table, which could have an impact on
the actual resource usage for the execution of
a specific plan.
An alternative explanation - given the change
in performance when you changed from a
temporary table to a permanent table is the
issue of getting statistics generated for a
temporary table. If there are significant
differences in the execution plans involving
the critical table, you could investigate the
use of the dynamic_sampling hint (level 2
is probably appropriate for the temp table)
to improve Oracle's knowledge of the contents
of the temporary table.
NB - when you say 'hanging' does you mean:
The CPU is working hard but the process
is not completing
or
The process is stuck in the same wait
state and never changes the wait seq#
or
The process is recording huge numbers
of continually changing wait states
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
For one-day tutorials:
(see http://www.jlcomp.demon.co.uk/tutorial.html )
____UK_______April 8th
____UK_______April 22nd
____Denmark May 21-23rd
____USA_(FL)_May 2nd
Next dates for the 3-day seminar:
(see http://www.jlcomp.demon.co.uk/seminar.html )
____UK_(Manchester)_May
____Estonia___June (provisional)
____USA_(CA, TX)_August
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: 25 March 2003 19:19
> I reconfigured a database to use the dynamic memory management
features
> of Oracle 9i by setting the db_cache_size parameter. After doing
so, we
> ran into a problem with a data mart build script that builds a
temporary
> table (type temp) by populating it with key values and then cycling
> through the table, joining it to others on the key, and updating the
> rows with values pulled from these other tables. After setting the
> db_cache_size parameter, the build script hangs in the update loop
and
> the session is experiencing huge numbers of latch free waits on the
> cache buffer chains.
>
> We recreated the temporary table as a permanent table and the build
> script runs as expected.
>
> Anyone experienced anything like this with the db_cache_size
parameter
> and temporary tables?
>
> This is on a Compaq server running Tru64; the database is version
> 9.2.0.2 with all the latest patches installed.
>
> I haven't come across anything on metalink about it. We're not
wedded
> to the idea of using a temproary table in these builds, so I'm more
> curious than anything else.
>
> Glenn Stauffer
> Swarthmore College
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Jonathan Lewis
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
