Re: Asynchronous Commit Feature of 10.2 - Basic Qs

 I will try to answer (answers inline)

  Qs 1 When using COMMIT_WRITE=BATCH,NOWAIT, After a database crash, if the
> respective Application has the capability to check within the database for
>
> volume of transactions lost after complete recovery & re-play the same,
> Can the COMMIT_WRITE=BATCH,NOWAIT feature be used in such a case?
>
> This basically refers to periodic Batch nature of Transactions which run
> with NO intermediate User intervention.
>

If the application can recover it self, yes why not.

> Qs 2 For a Process/SESSION consider that COMMIT_WRITE is set to
> BATCH,NOWAIT.
>
> If 2 Commits are issued sequentially (i.e. one after another), is there a
> possibility that the Commit which was issued later may be written 1st to the
>
>
> hard Disk ? Personally I think the answer is "NO"
>

I assume that you mean redo here. The redo is ordered in the in the log buffer, and the LGWR keeps track of where it is in the log buffer. So it writes the log buffer sequentially (in cycles).

>
> Qs 3 If multiple processes are running parallely & committing data with a
> related logical inter-dependency between them while doing updates, can the
>
> same be maintained when using the Asynchronous commit feature? To Explain
> this in simpler words:-
>
>
>
> Assume for 1 process COMMIT_WRITE is set to BATCH,NOWAIT.
>
> Assume at 10:00 this process issues a Commit after updating a field value
> to
>
> say "A".
>
> Assume that Oracle decides to write it to redo logs on Disk at 10:02.
>
>
>
> Question - If at 10:01 ANOTHER process reads(SELECTs) the same field
> value,
>
> will it get the UPDATED field Value of "A"
>
>
>

The redo is only used for recovery. You are confusing the SCN number. The current SCN and the snapshot scn (start of statement) dictate what you will see as commited or not.

  Qs 4 Is there any difference in the crash recovery mechanism in general
> with the use of this feature when compared to not using the same, both for
> Single instance & RAC setup?
>
>
>

There is a (small) window of exposure. This goes back to your first question. Oracle can only recover what it has in the redo log. If that redo is missing, you can't re execute the transaction. Doesn't matter RAC or not.

  Qs 5 Is there any difference in the rollback mechanism in general with the
> use of this feature when compared to not using the same both for single
> instance & RAC?
>

For normal rollback no, for rollback as part of instance recovery: you could be missing transactions.

>

  Qs 6 For COMMIT_WRITE=BATCH what are the general guidelines for data to be
> batched & written to disk? Is there an outer-time line involved? Do writes
> to disk necessarily happen at some periodicity?
>

Yes, there is a timeout feature for the LGWR. rougly once a second (haven't checked if that has changed lately)

>

  Qs 7 If archivelog mode is enabled, is there any change in the WRITEs
> mechanism to the archived redo log files?
>

No, why?

>
> Qs 8 Performance benefits seen when using this feature?
>

Yes! Tremendous escpecially for these great 'batch' programs that do 'TX' followed by a COMMIT. All the log file sync latency will dissapear for that program/process.

>
>

  Qs 9 Any Good Links / Docs on this?
>

I read the 10.2 doc and that was pretty clear. I think that you are making it more complicated than it is. The issue is that redo is not always on disk for that session. That could mean that the session is logically corrupting the data, however there is only small chance. Backup the data before you run the program :)

>
> Thanks indeed
>
>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely for the use of the addressee(s). If you are not the intended
> recipient, please notify the sender by e-mail and delete the original
> message. Further, you are not to copy, disclose, or distribute this e-mail
> or its contents to any other person and any such actions are unlawful. This
> e-mail may contain viruses. Infosys has taken every reasonable precaution to
> minimize this risk, but is not liable for any damage you may sustain as a
> result of any virus in this e-mail. You should carry out your own virus
> checks before opening the e-mail or attachment. Infosys reserves the right
> to monitor and review the content of all messages sent to or from this
> e-mail address. Messages sent to or from this e-mail address may be stored
> on the Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>

-- 
Anjo Kolk
Owner and Founder OraPerf Projects
tel:    +31-577-712000
mob: +31-6-55340888

--
http://www.freelists.org/webpage/oracle-l