Hi!
Maybe it's a delayed commit cleanout issue, due massive deletes, so during
your first select most of your buffers involved in delete have to be cleaned
out (thus becoming dirty and generating extra redo).
Tanel.
- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL
Robin,
Thanks for the reply. I figured it would. Thats what
we are working at now. It's unfortunate it was set up
this way to begin with, but I am starting to see the
light at the end of the tunnel.
Larry
--- Robin Li <[EMAIL PROTECTED]> wrote:
> I had the performance issue with CLOB in one of m
Raj,
I agree. I could see where that could affect the
overall performance. The analyze wouldnt have an
effect on a SELECT COUNT(*) though would it??? That is
the piece that really has me stumped at the moment.
--- "Jamadagni, Rajendra"
<[EMAIL PROTECTED]> wrote:
> After deleting lot of old data, a
I had the performance issue with CLOB in one of my databases. After I did a
re-org, and separated the tables,indexes and CLOB into different
tablespaces, the performance got tremendous improvement.
Robin
- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Se
After deleting lot of old data, an analyze of the table is in order though ..
Raj
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, ha
Good Morning,
I have a database (8.1.7.3 on Sun Solaris 8) that has
a mixture of tables and indexes in the same
tablespace. Poor initial setup, but that is starting
to be addressed. One of the tables has a BLOB data
type and the LOBSEGMENT is stored in the same
tablespace as the tables and indexes