Re: Question on concurrency wait time

I am a little curious about the "unix_time_id". It looks like 4 bytes for the number of seconds since 1st Jan 1970 followed by 16 bytes (maybe a digest of the row) stored as a character string.

Two things (for strategic planning - this is nothing to do with the performance glitch).
a) Why not store it as a RAW and save 20 bytes per row and 20 bytes per index entry.
b) Is the unix time component the same as the part_date_time (with a deterministic adjustment, perhaps, for daylight savings time). If so could you do something to make the partition key a virtual column and eliminate on column from the index.

Regards
Jonathan Lewis

P.S.
While I agree with Stefan's analysis of the wait chains, there's one further layer to consider.
You said: "but we see the concurrency during the time when there is heavy activity happening on the database from another app." The overrun on the change tracking buffer MIGHT be the consequence of the CTWR process having to wait to get on the run queue because of CPU overload due to the other application. While increasing the buffer size may reduce the risk of over-run it might be more important to choke the other app so that it can't cause the problem,

--
http://www.freelists.org/webpage/oracle-l