Re: rollback and redo questions

Sorry I meant the redo/undo information necessary for completing the Recovery.

B.Sc Yassir Khogaly wrote in message
<71prer$4nr$1_at_newsreader4.core.theplanet.net>...
>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(S,#):#0I%3D0Z5D-!4D0-"@`` `
end Received on Wed Nov 04 1998 - 09:23:03 CST