Re: 9i streams vs triggers

servant wrote:

> "Mark Townsend" <markbtownsend_at_attbi.com> wrote in message
> news:BA442B14.5836%markbtownsend_at_attbi.com...
> > in article avmkgh$6kq$1_at_gabriel.uhc.com, servant at mjohns1_at_uhc.com wrote
> on
> > 1/10/03 6:14 AM:
> >
> > > The update
> > > will lock the row and block the select and vice versa, right?
> >
> > Nope - welcome to Oracle. Repeat after me - "readers don't block writers,
> > writers don't block readers". It's a little complicated, but basically
> > Oracle reads are not blocked by writes to the data (an older version of
> the
> > row(s) are used), and Oracle also doesn't take out read locks like other
> > databases do.
>
> So I've been told--a few times now :>) Thanks--this is news to me and Mr.
> Morgan has graciously given me a link to the manual which I am perusing now.
>
> >
> > > What I meant by replication is logical hot standby so I think we agree
> > > there. That solves the contention issue but does not address the
> complexity
> > > issue.
> >
> > The thinking here is not clear also - logical standby is still doing the
> > same amount of DML on the standby system, so if DML WAS going to block
> your
> > queries on the production, the 'replicated' DML would also block the
> queries
> > on the standby.
> >
>
> Yes, but it would only block the other reports--not the critical OLTP that
> is happening simultaneously. But that is moot now. My performance concerns
> now have turned to network bandwidth, CPU and memory utilization which are
> (I think) much less significant than data contention (blocking).

Correct. Though the chances of such contention in Oracle are minimal as not only do (and we repeat it again) readers not block writers and writers not block readers ... readers don't block readers either.

Daniel Morgan Received on Fri Jan 10 2003 - 16:00:08 CST