Re: Cluster growing

In article <879045uqcl.fsf_at_konst.develop.sirena2000.ru>, konst_at_sirena2000.ru says...
> raouldekezel_at_hotmail.com (Raoul De Kezel) writes:
>
> 1) Question. What was Oracle version when
> you created this cluster? 7.3.4 or you have made
> upgrade

Personal Oracle 7.3.4.0. Very precisely, an import from a pre 7.3.4 database into PO 7.3.4.0

> Oracle gave as TAR322 but didn't help at all
> (they tell we have to increase block size :-( from 2K )

I have similar experience. I am told to use clusters only for static tables, but I cant understand why (insert/delete performances aside). I am told that I have migrated rows, but I cant find any way to see them. Does anybody know of a way to detect migrated rows ? Analyze says 0 chained rows, a full table scan which extracts block id from rowid shows only blocks in strictly increasing order.

I also seem to observe some incomprehensible behavior, like Oracle insisting to allocate a new extent instead of reusing what I think are free blocks, yet when I delete 200 rows, I am able insert 20000 new ones, each with a distinct cluster key value, without any new extent allocated.

>
> We made an upgrade but it didn't help
>

May I know which upgrade didn't help ?

> We rebuild this cluster by creating another cluster
> and copying data table by table (we usually are 24x7
> we had to invent a special technique)

Wow. We are also 24x7 and I had hoped to use clusters to avoid reorganizations. Would you mind to disclose the special technique you invented ?

>
> We also had problem with another cluster
> his cluster index begin to corrupt slowly
> (we begin to get 'NOT FOUND' when looking up by this index)
> so we split this cluster. Some things become to work
> slower and we had to reprogram some queries
>

This echoes another problem I met. Queries started to answer no row when some existed. Seems that the cached plan was corrupted, because changing the capitalization of the query or rebooting the server cured the problem. Seems solved in 7.3.4, however.

> 2) Advice.
> 2.1 rebuild your cluster
> 2.2 don't use it at all

I am slowly beginning to see that this is very good advice. Thank you very much.

• Raoul