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