streams capture performance

Hi all,

I have a question about the performance expectation of streams capture process. I just implemented streams to capture DML changes in certain tables in our production and am not happy with the performance. If it doesn't improve we will be falling back to triggers. The capture latency is about 12hrs (capture process is reading 12hrs back archive file). Ours is a very high rate transaction database ( ~ 400gb/day archives). Based on the strmmon output during day (night time is more busy):

Streams Pool Size = 256M
 LOG 169K (redo/sec)
Capture rate: about 2400 lcrs captured per sec, about 4 lcrs enqueued/sec <idle wait events percentage> <flow control wait events percentage>: <90%I 0%F

Env: 10.2.0.4 on Redhat linux 4.1. six node RAC. Each node is two dual core AMD Opteron processors (64bit). Capture is local.

I am not concerned with "APPLY" rate , yet, as changes to apply is expected to be low. I am only concerned with the captured rate.

I have already looked at the best practices docs and made suitable changes. Oracle support analyst says that's the best I can get (he has not provided any reference documents yet) but I want to know from users who have implemented Streams. Are the numbers above fairly high? Is streams not designed for such a high log generation? What has been your experience?

Thanks in advance.

-Madhu Sreeram

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