Re: Asynchronous Commit in Oracle Database 10g R2

You are absolutely correct but the thing is if I see some code like this running and the database goes down for some reason in the middle of executing the procedure, I (academically) will be fooled into assuming that I have an inconsistent database state but actually that wont be the case!

Best Regards
- orauser

Jonathan Lewis wrote:
> "orauser" <orauser_at_gmail.com> wrote in message
> news:1125757214.002563.129590_at_g14g2000cwa.googlegroups.com...
> > Exactly...and I think the extproc example given by Mr. Lewis has done
> > nothing but deviate us from the main problem here (i.e. undocumented
> > commit optimization).
> > I think any sensible person with a knowledge of how things work in
> > oracle would use DBMS_JOB (or whatever) instead of extproc.
> >
> > The point is oracle is doing an "Undocumented Optimization" which is
> > highly unacceptable. If you (Oracle) do these kind of optimizations why
> > not document it...!
> >
>
> I think you've missed the important point, though.
> The optimization is only a danger if there is a method
> for getting a message to the outside from inside the
> database call. Consequently the fact that such methods
> exist IS the main problem - the fact that I gave extproc
> as an example rather than utl_file or dbms_pipe is a
> minor detail.
>
>
> Technically, by the way, you could make the same
> problem appear using dbms_job so that doesn't
> protect you properly, even though the time window
> for the error would be much smaller if you happened
> to call dbms_job with a commit in the loop.
>
>
> Think carefully about the problem - if you cannot
> detect the optimization (apart from the change in
> speed) why do you need to know that it happens ?
>
>
> Two possible reasons why Oracle does not document
> every optimisation they introduce:
>
> a) it might help the opposition
>
> b) they might decide to withdraw it for some reason, but
> if someone had taken advantage of it because it was
> documented, then they would be obliged to continue
> supporting it.
>
>
> --
> Regards
>
> Jonathan Lewis
>
> Now waiting on the publishers: Cost Based Oracle - Volume 1
>
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
> The Co-operative Oracle Users' FAQ
>
> http://www.jlcomp.demon.co.uk/appearances.html
> Public Appearances - schedule updated 8th July 2005
Received on Sun Sep 04 2005 - 07:37:50 CDT