I will try to answer (answers inline)
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
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.
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.
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.
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)
mechanism to the archived redo log files?
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.
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 :)
**************** 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