Re: Streams for one-time single source replication
- From: Stojan Veselinovski <stojan.veselinovski@xxxxxxxxx>
- To: rjoralist3@xxxxxxxxxxxxxxxxxxxxx
- Date: Fri, 7 Feb 2014 14:52:04 +1100
Streams has some gotcha's with large transactions that can take forever to
process. You need to make sure you understand how the application does it
transactions. Any batch jobs with large updates/deletes/inserts get
transformed into individual LCR's to process.
LOBS can be troublesome also. They can also be split up into multiple
LCR's.
Also had some memory leaks on the apply side.
Seeing you have an outage window and *some* wriggle room, I'd go for the
physical standby approach and drop/clean up data later on.
You could have the binaries patched and ready to go for a shortish cutover.
Stojan
www.stojanveselinovski.com/blog
On Fri, Feb 7, 2014 at 9:19 AM, Rich Jesse <rjoralist3@xxxxxxxxxxxxxxxxxxxxx
> wrote:
> Reed replies:
>
> > One of the gotchas we had was with sequences.
>
> Not in use for these schemas. Yay! We do have a few triggers though...
>
> > Another issue we dealt with was record updates. Connections on the source
> > were making changes to records while connections on the destination were
> > making updates to the same records. This would cause a conflict in the
> > apply process and cause the apply to stop working. It would add an entry
> in
> > the error log but would need to be restarted. The biggest problem with
> this
> > was due to the applications updating the entire record even though only
> one
> > or two fields were changed.
>
> Hmmmm...I could see that happening a lot here. :|
>
> > How are you
> > applications connecting to the database. Are they using remote resolution
> > with an alias? That would provide an easier cut over, just updating where
> > the alias points.
>
> The app server is being cutover at the same time as well, as we have
> all-new
> hardware for all tiers. So no worries from that standpoint.
>
> Thanks!
> Rich
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
Stojan
www.stojanveselinovski.com/blog
Other related posts:
