Re: rollback and redo questions

I've a small comment about your comment "It'll actually roll forward from redo first ( recovering the rollback segements
>as well -- they are part of the redo information, they are logged) and then
>rollback any uncommitted transactions from the rollback segements (which
just
>got recovered themselves).

 This should be "It'll actually roll forward from redo entries recovering the rollback segements are part of the Recovery Process because the rollback segments are actually part of the redo/redo information nesessary for Recovery.

<364268db.4999649_at_192.86.155.100>...
>A copy of this was sent to Doug Cowles <dcowles_at_bigfoot.com>
>(if that email address didn't require changing)
>On Tue, 03 Nov 1998 23:29:20 -0500, you wrote:
>
>>I jus ran a canned script on my rollback segments and got the following
>>info
>>at the bottom of the report:
>>
>>"Rollback contention for system undo header = 0% (Total requests = 36)
>>
>>Rollback contention for system undo block = 0% (Total requests = 36)
>>Rollback contention for undo header = 100% (Total requests =
>>36)
>>Rollback contention for undo block = 0% (Total requests = 36)
>>If percentage is more than 1%, create more rollback segments "
>>
>>Question: What's with the undo header, and what is it? Can anyone
>>explain
>>why it's contention is sitting at 100%, whereas the others are at 0?
>>
>
>its rollback (undo) headers. In theory, the above output indicates
rollback
>segment contention however, without seeing the canned script we cannot
really
>tell. For all we know, the canned script is:
>
>select 'rollback contention for undo header = 100%' from dual;
>
>we need to see the question that is being asked of the database -- not just
the
>answer...
>
>>Also, supplementary question - as a transaction begins, it grabs a
>>rollback
>>segment, right?
>
>It doesn't 'grab' as 'grab' implies "it owns it". It is assigned, along
with
>other transactions, to a single rollback segment that it will use during
the
>course of the transaction.
>
>It will place UNDO information here.
>
>>At the same time, it places this uncommitted
>>information in
>>whatever is the current redo log file, right?
>
>Into the current online redo log file it will place REDO information, after
>images of information. It may place this data into many of the online
redo log
>files over time.
>
>> Now, if you should lose
>>the database,
>>it will make use of any redo information in the redo log file, rollback
>>any uncommitted
>>transactions, and roll forward any committed transactions, right?
>
>It'll actually roll forward from redo first ( recovering the rollback
segements
>as well -- they are part of the redo information, they are logged) and then
>rollback any uncommitted transactions from the rollback segements (which
just
>got recovered themselves).
>
>>So,
>>if the redo
>>log is smaller than the rollback segment which I'll assume is being
>>maxed out,
>>can't you potentially lose information IF, you have written a committed
>>transaction
>>to a redo log, there is a log switch for the write of the uncommitted
>>transaction (using the rollback segment), and the checkpoint is not
>>complete, and the database goes down, right?
>>
>
>If the checkpoint is not complete, we will *not* reuse a log file that
contains
>log entries for uncheckpointed data.
>
>Everytime a log switch occurrs -- a checkpoint is fired (among other
times --
>other events may fire a checkpoint but a log switch ALWAYS does). If the
data
>this checkpoint was flushing to disk *does not complete* by the time we
want to
>reuse the log file that fired that checkpoint, you will get the infamous
>"checkpoint not complete -- cannot allocate new log" message in your alert
file
>and the system will suspend temporarily -- waiting for that checkpoint to
>finish. The scenario you describe above is one the system will not allow
itself
>to get into.
>
>>I know that sounds somewhat convaluted, but hopefully someone will know
>>what
>>I mean. Just to confirm my understanding, when a transaction commits,
>>it will sit
>>in the redo logs until a checkpoint occurs, at which point it is made
>>permanent, right?
>>
>
>When you commit, its permanent. It might not be on disk in the DATAFILES
but
>its on disk (in the redo perhaps). It is however, permanent -- its
committed,
>its as good as done.
>
>>So, I guess what I'm asking here is , under what circumstance of the
>>above events
>>could you actually lose something, if you get my intention.
>>
>>- Dc.
>
>
>Thomas Kyte
>tkyte_at_us.oracle.com
>Oracle Government
>Herndon VA
>
>--
>http://govt.us.oracle.com/ -- downloadable utilities
>
>---------------------------------------------------------------------------
-
>Opinions are mine and do not necessarily reflect those of Oracle
Corporation
>
>Anti-Anti Spam Msg: if you want an answer emailed to you,
>you have to make it easy to get email to you. Any bounced
>email will be treated the same way i treat SPAM-- I delete it.

begin 666 Yassir Khogaly.vcf
M0D5'24XZ5D-!4D0-"E9%4E-)3TXZ,BXQ#0I..DMH;V=A;'D[66%S<VER#0I& M3CI987-S:7(@2VAO9V%L>0T*5$E43$4Z4V5N:6]R($]R86-L92!$0D$-"E1% M3#M(3TU%.U9/24-%.BLT-"@P*3$X,2 T-C T,#0R#0I414P[0T5,3#M63TE# M13HK-#0T,3$Y,#8W-S8-"D%$4CM(3TU%.CL[.SM+96YT.SM%;F=L86YD#0I, M04)%3#M(3TU%.T5.0T]$24Y'/5%53U1%1"U04DE.5$%"3$4Z2V5N=#TP1#TP M045N9VQA;F0-"E523#IH='1P.B\O=W=W+FMH;V=A;'DN9G)E97-E<G9E+F-O M+G5K#0I54DPZ:'1T<#HO+W=W=RYA965U+F]R9RYU:PT*14U!24P[4%)%1CM) M3E1%4DY%5#IY87-S:7) :VAO9V%L>2YF<F5E<V5R=F4N8V\N=6L-"E)%5CHQ <.3DX,3$P-%0Q-3(P-3!:#0I%3D0Z5D-!4D0-"@`` `
end Received on Wed Nov 04 1998 - 09:20:50 CST