Re: Asynchronous Commit in Oracle Database 10g R2

<xhoster_at_gmail.com> wrote in message
news:20050902202109.103$g4_at_newsreader.com...
> "VC" <boston103_at_hotmail.com> wrote:
>
> <snip asynchronous commits>
>
>> Could you please comment on how this optimization does not create a
>> possibility for data loss ?
>
> Who says it doesn't? Of course there is the possibility of data loss.
> But
> then again, if your A/D converter suffers a buffer overrun because the app
> spent too much time waiting for a log sync, that is also a possibility for
> data loss. Life's a bitch, then you die.

Could you kindly rephrase the above ? I am not quite sure what you've meant by the A/D converter problem and how it's related to the database commit.

>
>
>> (An application thinks that a transaction has
>> committed while in fact it did not, and a crash occurs ...)
>
> Since the thing which is doing the commit in the tight loop is a PLSQL
> block running on the same database server, then the application's "thought
> process" doesn't survive the crash any better than its commits did.
> Therefore, the application can't "think" that it committed the
> transaction--either it can reconstruct exactly what it needs to by looking
> at what did get truly committed, or it simply has no idea what happened
> prior to the lights going out.

Are you saying that the application does not issue any commits at all but instead just calls a PL/SQL procedure which performs commits in some loop ? Is it the optimization we are talking about ?

 >If this is a problem, you shouldn't be
> commiting in the loop anyway, asynchronously or not.

If you mean committing inside a PL/SQL proc, then arguably one should not be doing so at all. I do not understand your using the word 'asynchronously' in the last sentence, though.

>
>
> Xho
>
> --
> -------------------- http://NewsReader.Com/ --------------------
> Usenet Newsgroup Service $9.95/Month 30GB
Received on Fri Sep 02 2005 - 19:37:04 CDT