Re: Streams: 9i source to 10g target
- From: "Arul Ramachandran" <contactarul@xxxxxxxxx>
- To: afatkulin@xxxxxxxxx
- Date: Tue, 27 Mar 2007 19:25:55 -0700
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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx>
> To: david@xxxxxxxxxxxxxxxxxx
> Cc: oracle-l@xxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
