Re: streams capture performance

  • From: "Bradd Piontek" <piontekdd@xxxxxxxxx>
  • To: madhusreeram@xxxxxxxxx
  • Date: Wed, 15 Oct 2008 20:50:38 -0500

Can you post what the settings are in dba_capture_parameters?
As for init.ora:
min_parallel_servers
max_parallel_servers
(i would increase the streams_pool_size)

How big are your redo logs and how often, on average, to do switches occur?

Bradd Piontek
  "Next to doing a good job yourself,
        the greatest joy is in having someone
        else do a first-class job under your
        direction."
 -- William Feather


On Wed, Oct 15, 2008 at 5:38 PM, Madhu Sreeram <madhusreeram@xxxxxxxxx>wrote:

> 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
>
>

Other related posts: