Re: Do selects block truncates?
- From: "Andrew Kerber" <andrew.kerber@xxxxxxxxx>
- To: ukja.dion@xxxxxxxxx
- Date: Fri, 21 Dec 2007 10:53:34 -0600
When data is deleted during a select, oracle will read the rollback segment
to get the data as it was prior to the select, and if the segment is
overwritten we get the old rollback segment too small error message.
However, a truncate generates no rollback, so in order to get a consistent
oracle has to keep that table data available somehow, which in this case
would be not completing the truncate until the read completes.
On Dec 21, 2007 9:34 AM, Ukja.dion <ukja.dion@xxxxxxxxx> wrote:
> >this is never a bug but is the consequence of enforcing statement-level
> read consistency
> >which is always guranteed by oracle.
>
> Can you explain in more detail?
> Which relationship does read consistency mechanism have with the blocking
> of truncate by select operation?
> I don't know no concept of "select" blocking any kind of operation in
> Oracle.
> (except some internal lightweight locks like latch or buffer lock, library
> cache lock/pin, blah blah blah)
>
>
> -----Original Message-----
> From: Kurt Franke [mailto:Kurt-Franke@xxxxxx]
> Sent: Friday, December 21, 2007 10:35 PM
> To: 'oracle-l'; ukja.dion@xxxxxxxxx
> Subject: RE: Do selects block truncates?
>
>
> Hi,
>
> ...
> >
> > If select really blocks truncate, it's a amazing bug. :)
> >
>
> this is never a bug but is the consequence of enforcing statement-level
> read consistency
> which is always guranteed by oracle.
>
> the only exception from this mechanism is the complete refresh of a
> materialized view with
> "atomic_refresh => FALSE" which then does the truncate wether or not any
> select is runnig
> on the materialized view. active select on the materialized view will
> break
> then with
> ORA-08103
>
>
> regards
>
> kf
>
>
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
Other related posts:
