Re: log switching question

Did you ever get any resolution from the analyst? This rang a bell with me because I was told exactly the same thing a few months ago and I could swear the analyst was right, even though it contradicts the documentation... I raised the log_checkpoint_interval and set the timeout to 0 and got less frequent checkpoints.. I might not have been that careful in analyzing the situation though since it was not that critical, so I might have been guilty of being gullible, but, come to think of it, log switches cause checkpoints, not the other way around. Also, is there any way to tell exactly how full a logfile is if your not archiving?

Thanks,
Dc.

On Tue, 31 Oct 2000 11:58:14 GMT, steve.adams_at_ixora.com.au (Steve Adams) wrote:

>Hi Scott,
>
>Yes, what the analyst told you is rubbish. The only reasons I know of for a log
>file switch are if you do it manually using either the SWITCH LOGFILE or the
>ARCHIVE LOG clauses of the ALTER SYSTEM command, or if it happens automatically
>because the current log file is full, or in parallel server to secure
>recoverability in a relatively idle instance.
>
>I'd firstly check that the logfiles are all the right size as follows:
> select lesiz, count(*) from x$kccle group by lesiz;
>Then if you are certain that nothing is doing ALTER SYSTEM commands, I would
>reopen the TAR and press for a real explanation.
>
>@ Regards,
>@ Steve Adams
>@ http://www.ixora.com.au/
>@ http://www.christianity.net.au/
>
>
>-----Original Message-----
>From: gambleNOSPAM_at_iwc.net (Scott Gamble)
>
>
>Hello everyone,
>
> Looking for some information on log_checkpoint_interval with respect to
>log switches.
>
>This may be purely a complete misunderstanding on my part, but I think I
>am missing something here or I cannot find the appropriate documentation.
>
>We have a database that is using 1 gig log files. and we are doing log
>switches/checkpoints _very_ frequently, in some cases in less than 10
>minutes and in _most_ cases those log files are less than the full 1 gig,
>in fact they are considerablly less, in the area of 100-200m. We think
>this started after the recent upgrade to 8.0.6 but are not 100% sure.
>
>To start with here are the parameters as we have them defined.
>
>log_checkpoint_interval integer 60000000
>log_checkpoint_timeout integer 0
>
>From what I have read log_checkpoint_timout, and log_checkpoint_interval
>control checkpoints. Neither of which should force a log switch based
>on the documention.
>
>Oracle seems to present conflicting information on this.
>
>The analyst that handled the TAR i opened said that a checkpoint will
>force a log switch and the solution to slow the check points down was to
>raise log_checkpoint_interval to a number that could not be reached prior
>to the log filling up.
>
>From what I understand log_checkpoint_interval is the
>number of OS blocks, 60M OS blocks is bigger than our log size. Obviously I
>am missing something here.
>
>Looking at a post in Metalink, that oracle people replied to, what the
>analyst told me above is incorrect.
>
>
>I guess my question comes down to this
>
>1) in the abscence of anyone doing an 'alter system switch logfile'
> why are the log files switching when they aren't full.
>
>Portion of v$archived_log
>
> BLOCKS BLOCK_SIZE TO_CHAR(COMPLE
>---------- ---------- --------------
> 460952 1024 10/30/00 10:27
> 1024000 1024 10/30/00 11:54
> 226364 1024 10/30/00 11:02
> 405973 1024 10/30/00 11:25
>
>
>
>Portion of the alert log....
>
>Mon Oct 30 10:55:58 2000
>Beginning log switch checkpoint up to RBA [0x6a1.2.10], SCN:
>0x0000.64cf083a
>Thread 1 advanced to log sequence 1697
> Current log# 4 seq# 1697 mem# 0: /u16/oradata/P013/redo4aP013.log
> Current log# 4 seq# 1697 mem# 1: /u17/oradata/P013/redo4bP013.log
>Mon Oct 30 11:02:11 2000
>Beginning log switch checkpoint up to RBA [0x6a2.2.10], SCN:
>0x0000.64cf15d5
>Thread 1 advanced to log sequence 1698
> Current log# 5 seq# 1698 mem# 0: /u17/oradata/P013/redo5aP013.log
> Current log# 5 seq# 1698 mem# 1: /u18/oradata/P013/redo5bP013.log
Received on Sun Nov 05 2000 - 21:50:10 CST