Re: frequent commits

"Pradeep" <agarwalp_at_eeism.com> wrote:
> Please fix what i am missing here.
>
> The argument against frequent commits is that oracle needs the
> transaction details,

The main argument against frequent commits is that you should commit when the transaction is done, and if that isn't frequent than the commits shouldn't be either. A secondary argument is that commits are slow.

> which is wiped out by COMMIT, to supports its
> multiversioning facility.

Committing doesn't wipe out the details. What it does do is free up those details to be wiped out by a later transaction. However on modern systems, undo_retention_time controls how long it tries to leave the details around before they get wiped out.

> But i have read that when oracle goes to rollback segments for getting
> the status of a trans id, and if the trans id not present it regards it
> as COMMITTED. This belief is what raised my question. ??

Yes, that is true. Only committed (or already rolled-back) undo/rollback can be overwritten, so if you go looking for it an it isn't there, then it must have been committed.

> If this not true, then what if a block update is committed->
> transaction id of the block does not indicate the commit status. and
> eventually after some time (read days) the rollback segments (which
> contains the status of that transaction id) gets wiped out, Now if i
> read that block will it give the 01555 error??

Perhaps. If the reading transaction can figure out that the committed data was committed before the reading transaction started, it won't throw a 01555. If it can't figure out when it was committed, or discovers it was committed after it started and thus needs to be rolled back, it will throw a 01555.

Xho

-- 
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service                        $9.95/Month 30GB