Re: Streams: 9i source to 10g target

Yes, the source could be 9i and target could be 10G; in fact, they could even be different Operating systems.

Even with 10G it takes a lot of sweat to make it work.... one needs to work with Oracle support most of the time on issues. Capture, apply, propagate processes get aborted randomly and there is a need to set up monitoring of these processes...

I do not know if it is me, but in my experience, I found Streams to be flaky when it comes to handling large transactions.. especially with batch jobs. If there are no frequent commits (example: commit every 1000 rows) then the apply either gets stuck or takes hours to catch up. This based on 10.2.0.2

Regards,
Arul

On 3/27/07, Alexander Fatkulin <afatkulin_at_gmail.com> wrote:
>
> David,
>
> here is my top headaches with 9i streams. All experience is based on
> 9.2.0.6 HP-UX (Itanium).
>
> No streams pool - they are simply using your shared pool for buffered
> queues. They dedicate a 10% of it by default. This can be fixed by
> setting the _first_spare_parameter but anyway - this puts additional
> pressure on your shared pool. We observed random ora-4031 under peak
> workloads (we were doing approximately 240 LCR/sec under peaks).
>
> They are slow when forced to mine from archived (not online) redo.
>
> We observer random logminer crashes approximately once a week. Newer
> versions / different platform may behave better (or worser).
>
> No automatic clearing of checkpoint-related information (or I
> completely missed it). My checkpoint table grew to 800MB in a first
> three days. I've ended up scheduling a job with manual cleaning up
> (system.logmnr_restart_ckpt$/system.logmnr_restart_ckpt_txinfo$) from
> those tables. Increasing the _checkpoint_frequency can help a bit.
>
> Capture restarts are just ridiculous. They can roll back to a rather
> old archive log file. Hence it's sometimes hard to figure out what you
> can delete safely and what you can not. 10G is _much more_ predictable
> in this case.
>
> No downstream capture. So you can not do a sort of "free lunch" from
> source server perspective.
>
> Lots of unsupported data types. Function-based indexes were my "number
> one".
>
> I've ended up manually instantiating all replication environment. That
> is - I have used dbms_capture_adm.create_capture to create capture,
> dbms_rule_adm to manually create rules, etc. That way the results are
> a little more predictable (dbms_streams_adm.add_*_rules can sometimes
> fail in the middle and not do any sort of cleanup). But that helped me
> to better understand the whole process. I still do it that way in 10G.
>
> That's all as long as I can remember.
>
> The 10G is much more better in all areas
>
> On 3/28/07, David Aldridge <david_at_david-aldridge.com> wrote:
> >
> > Yes, Kirtikumar Deshpande mentioned the flakiness of 9iR2 streams at
> RMOUG
> > -- do you know if that is related to a particular component of the
> > architecture though? Capture, propagation, staging etc? Or is it a
> general
> > instability?
> >
> >
> >
> > ----- Original Message ----
> > From: Alexander Fatkulin <afatkulin_at_gmail.com>
> > To: david_at_david-aldridge.com
> > Cc: oracle-l_at_freelists.org
> > Sent: Tuesday, March 27, 2007 8:52:18 AM
> > Subject: Re: Streams: 9i source to 10g target
> >
> >
> > David,
> >
> > Yes, you can do this (I did). You would run capture on 9i database and
> > propagate LCR's to target (10G).
> >
> > Unfortunately in 9iR2 Streams are a little premature...
> >
> > On 3/27/07, David Aldridge <david_at_david-aldridge.com> wrote:
> > >
> > >
> > >
> > > I may be missing something in the docs but it's not clear to me
> whether
> > > streams can be used with 9i as the source as 10g as the target -- in
> any
> > > case, I doubt that the docs would say whether it works in practice :)
> > >
> > > Has anyone tried this? Any comments on feasibility?
> > >
> > >
> > > regards,
> > >
> > > David Aldridge
> > >
> >
> >
> > --
> > Alexander Fatkulin
> >
> >
>
>
> --
> Alexander Fatkulin
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

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