THANKS: log_checkpoint_timeout new meaning in 8i

From: Koivu, Lisa <lkoivu_at_qode.com>
Date: Thu, 4 Jan 2001 15:40:46 -0500
Message-Id: <10731.125765@fatcity.com>

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0768E.9DBE2CF6
Content-Type: text/plain;

charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thank you Stephane for your explanation. That does make sense.=20 =20
After I thought about it, I figured if there was no real activity going = on
and the database is doing it's job (which it does very well) then I = really
don't have anything to worry about, flushing to disk will happen in due time. I should have thought of this, we even instance-crashed one = database
over and over one morning during testing (Die! Die! Die!) and it came = back
every time.=20
=20
Read: I may be paranoid.
=20
Thanks again.=20

Lisa Rutland Koivu=20
Oracle Database Administrator=20
Qode.com=20
4850 North State Road 7=20
Suite G104=20
Fort Lauderdale, FL 33319=20

V: 954.484.3191, x174=20
F: 954.484.2933=20
C: 954.658.5849=20

http://www.qode.com <http://www.qode.com/> =20

"The information contained herein does not express the opinion or = position
of Qode.com and cannot be attributed to or made binding upon Qode.com."

-----Original Message-----
From: Stephane Faroult [mailto:sfaroult_at_oriole.com] Sent: Thursday, January 04, 2001 2:55 PM To: Multiple recipients of list ORACLE-L Subject: Re: log_checkpoint_timeout new meaning in 8i

Lisa,=20

I think that many people read LOG_checkpoint_interval when I believe = that
one should read log_CHECKPOINT_interval. The problem stems from the = fact
that at any given point in time, the database files lag behind the SGA = - and
the committed delta is stored to redo logs. If your database suddenly crashes, on startup this delta must be applied to the files - and then restored rollback segments must be used to rollback possibly = uncommitted
transactions. This may take time, and by forcing CHECKPOINTs, i.e. = updating
data file blocks with the most recent memory contents, you can = guarantee
that you will never have to roll forward more than = log_checkpoint_interval
seconds worth of transaction data.=20
So what ? If no update occurs on your database, it means that SGA and datafile blocks stay in synch, and there is no reason to see any = checkpoint
occur either. And for redo log files, they only switch when full or explicitly told to do so - I have never found anything better to = guarantee a
maximum elapsed time between switches (for a standby database) than = running
a job issuing ALTER SYSTEM SWITCH LOGFILE when needed.=20

Regards,=20

St=E9phane Faroult=20
Oriole Corporation=20

hello all,

I've got LOG_CHECKPOINT_TIMEOUT set to 1800 (30 minutes) in one of my databases. I also have LOG_CHECKPOINTS_TO_ALERT set to true. However, every morning I look at the archive logs and I see that 1. the logs = haven't
switched since the nightly batch quit and 2. there are no checkpoints = in the
alert log since the log switch. This makes me a little nervous.=20

It seems that LOG_CHECKPOINT_TIMEOUT is not working. However, I find = this
on metalink that kind of explains it.=20

The parameter log_checkpoint_timeout has been re-interpreted. In prior releases, every log_checkpoint_timeout seconds, Oracle started an = interval
checkpoint. Starting with Oracle 8.1, log_checkpoint_timeout will be interpreted to mean that the incremental checkpoint should be at the = log
position where the tail of the log was log_checkpoint_timeout seconds = ago.
In other words, the incremental checkpoint should lag the tail of the = log by
no more than log_checkpoint_timeout seconds worth of redo.=20

I don't quite understand. Can someone paraphrase this? Does this mean = that
every LOG_CHECKPOINT_TIMEOUT seconds it makes sure that there is no = redo
that hasn't been written to disk that is more than = LOG_CHECKPOINT_TIMEOUT
seconds old? In other words, it checks to see if a checkpoint is = necessary
instead of just doing it?=20

Thanks=20

Lisa Rutland Koivu=20
Oracle Database Administrator=20
Qode.com=20
4850 North State Road 7=20
Suite G104=20
Fort Lauderdale, FL 33319=20

V: 954.484.3191, x174=20
F: 954.484.2933=20
C: 954.658.5849=20

http://www.qode.com <http://www.qode.com> =20

"The information contained herein does not express the opinion or = position
of Qode.com and cannot be attributed to or made binding upon Qode.com."

=20
=20

------_=_NextPart_001_01C0768E.9DBE2CF6
Content-Type: text/html;

charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV>Thank
you Stephane for your explanation.  That does make sense.
</DIV>
<DIV><SPAN
class=434353720-04012001> </DIV>
<DIV>After
I thought about it, I figured if there was no real activity going on and the database is doing it's job (which it does very well) then I really don't have anything to worry about, flushing to disk will happen in due time.  I should have thought of this, we even instance-crashed one database over and over one morning during testing (Die! Die! Die!) and it came back every time. </DIV>
<DIV><SPAN
class=434353720-04012001> </DIV>
<DIV><SPAN
class=434353720-04012001>Read:  I may be paranoid.</DIV>
<DIV><SPAN
class=434353720-04012001> </DIV>
<DIV>Thanks
again. </DIV>
Lisa Rutland Koivu Oracle Database Administrator Qode.com 4850 North State Road 7 Suite G104 Fort Lauderdale, FL  33319 
V: 954.484.3191, x174 F: 954.484.2933 C: 954.658.5849
 <A href="http://www.qode.com/"
target=_blank>http://www.qode.com</A> 
"The information contained herein
does not express the opinion or position of Qode.com and cannot be attributed to or made binding upon Qode.com."
<BLOCKQUOTE>

<DIV align=left class=OutlookMessageHeader dir=ltr>-----Original Message----- From: Stephane Faroult [mailto:sfaroult_at_oriole.com] Sent: Thursday, January 04, 2001 2:55 PM To: Multiple recipients of list ORACLE-L Subject: Re: log_checkpoint_timeout new meaning in 8i </DIV>Lisa,    I think that many people read LOG_checkpoint_interval when I believe that one should read log_CHECKPOINT_interval. The problem stems from the fact that at any given point in time, the database files lag behind the SGA - and the committed delta is stored to redo logs. If your database suddenly crashes, on startup this delta must be applied to the files - and then restored rollback segments must be used to rollback possibly uncommitted transactions. This may take time, and by forcing CHECKPOINTs, i.e. updating data file blocks with the most recent memory contents, you can guarantee that you will never have to roll forward more than log_checkpoint_interval seconds worth of transaction data.   So what ? If no update occurs on your database, it means that SGA and datafile blocks stay in synch, and there is no reason to see any checkpoint occur either. And for redo log files, they only switch when full or explicitly told to do so - I have never found anything better to guarantee a maximum elapsed time between switches (for a standby database) than running a job issuing ALTER SYSTEM SWITCH LOGFILE when needed.

  <P>Regards, 
  <P>Stéphane Faroult <BR>Oriole Corporation 
  <BLOCKQUOTE TYPE="CITE"><FONT face=Arial><FONT size=-1>hello

all,</BLOCKQUOTE>
 <BLOCKQUOTE TYPE="CITE">I've got LOG_CHECKPOINT_TIMEOUT set to 1800 (30 minutes) in one of my databases.  I also have LOG_CHECKPOINTS_TO_ALERT set to true.  However, every morning I look at the archive logs and I see that 1. the logs haven't switched since the nightly batch quit and 2. there are no checkpoints in the alert log since the log switch.  This makes me a little nervous.
  It seems that LOG_CHECKPOINT_TIMEOUT is not working.  However, I find this on metalink that kind of explains it.
 The parameter log_checkpoint_timeout has been re-interpreted. In prior releases, every log_checkpoint_timeout seconds, Oracle started an interval checkpoint. Starting with Oracle 8.1, log_checkpoint_timeout will be interpreted to mean that the incremental checkpoint should be at the log position where the tail of the log was log_checkpoint_timeout seconds ago. In other words, the incremental checkpoint should lag the tail of the log by no more than log_checkpoint_timeout seconds worth of redo. I don't quite understand.  Can someone paraphrase this?  Does this mean that every LOG_CHECKPOINT_TIMEOUT seconds it makes sure that there is no redo that hasn't been written to disk that is more than LOG_CHECKPOINT_TIMEOUT seconds old?  In other words, it checks to see if a checkpoint is necessary instead of just doing it?

    <P><FONT face=Arial><FONT size=-1>Thanks</FONT></FONT> 
    <P><B><FONT face=Arial><FONT size=-2>Lisa Rutland Koivu</FONT></FONT></B> 
    <BR><FONT face=Arial><FONT size=-2>Oracle Database

Administrator Qode.com 4850 North State Road 7 Suite G104 Fort Lauderdale, FL  33319
V: 954.484.3191, x174 F: 954.484.2933 C: 954.658.5849 <A href="http://www.qode.com" target=_blank>http://www.qode.com</A> "The information contained herein does not express the opinion or position of Qode.com and Received on Thu Jan 04 2001 - 14:40:46 CST