pat wrote:
> Thanks for mentioning Tom Kyte. I searched and found a lot of good
> information. For this database, we are one of the special cases he
> mentions in one of his articles. We are processing hundreds of GB of
> data per day. It is all in the form of messages that may have several
> hundred name/value pairs per message. We need to correlate on data
> that is stored in the parent table. There are no external
> relationships and the data has no other uses. It is all enterpise
> logging work. We are 24X7 and have processing requirements on the data
> that preclude us from truncating the table until it is seven days old.
> We rename tables to avoid the overhead of copying the data from one
> table to the next. We keep many tables to reduce the dataset size for
> the different processing requirements.
>
> We are maintaining schemas with both nested/non-nested tables during
> development. We have experienced over twice the insertion throughput
> with nested tables as opposed to non-nested. We eliminate iterating
> over the child elements with nested table inserts. Selects have been
> slightly slower, but that can be addressed with adding indexes per
> Tom's advise.
>
> We haven't made a final decision, but when we do it will be based on
> real tests that weigh all of the options.
Then another suggestion ... partitioning: Drop partition. If you have
that much data then partitioning is certainly appropriate.
--
Daniel A. Morgan
http://www.psoug.org
damorgan_at_x.washington.edu
(replace x with u to respond)
Received on Thu Jul 28 2005 - 20:42:46 CDT
