I recently changed connect_limit (doubled it) and after that change
I got transaction log every morning full. It happened during the night
I suspected that it may be one of the cronjobs running, so I
disabled
for the weekend all nightly crons that update the databases.
I haven't change anything else. I saw some of the parameters were
automatically
Reconfigered after changing connect_limit - not all parameters were
doubled, increased but not doubled.
I didn't think this parameter should affect the transaction log file.
Am I right?
I could increase the size of the transaction log file but it is good
to know the reason
for filling it. It is recommended (in errlog.log) to reduce logfull
and force_abort
limits to give the Logging System more free logspace for recovery.
Currently logfull is 90%, force_abort - 72%. What are the best numbers
for those
2 parameters.
I think archiver works fine (I read this my be a problem simetimes).
The other think - I just came from maternity finding that Replicator
was installed
(Ingres 2.6/0305) between two db servers. Could this cause the
problem?
45 minutes before LOGFULL error I see error message related to the
replicator:
yoda ::[45051 IIGCC, 00000001]: Mon Feb 19 05:24:29 2007
E_GC2205_RMT_ABORT Session failure: ABORT received from remote
partner.
yoda ::[45051 IIGCC, 00000001]: Mon Feb 19 05:24:29 2007
E_CLFE07_BS_READ_ERR Read from peer process failed; it may have
exited.
YODA ::[45049 , 0000000103ea0200]: Mon Feb 19 05:35:17
2007 W_DM956A_REP_MANUAL_DIST Outstanding record(s) were found in
the replication input queue when opening database , this was probably
due to a system crash. These record(s) will be processed manually by
the current user thread.
yoda ::[45051 IIGCC, 00000002]: Mon Feb 19 05:46:04 2007
E_GC2205_RMT_ABORT Session failure: ABORT received from remote
partner.
yoda ::[45051 IIGCC, 00000002]: Mon Feb 19 05:46:04 2007
E_CLFE07_BS_READ_ERR Read from peer process failed; it may have
exited.
YODA ::[45049 , 0000000103ea0200]: Mon Feb 19 06:17:33
2007 E_DMA48E_LOGFULL_EXCEEDED
Unexpected condition during System Logfull Handling - the Logfile
has grown in size beyond the logfull point. The combined used and
reserved space in the transaction Log File has grown to exceed what
the Logging System has saved for its recovery handling. This may
indicate that the Logging System has not reserved enough logfile
space for rollback processing, or it may indicate that concurrent
activity in the system has unexpectedly used up logfile space more
quickly than expected. The Logging System will be shut down so that
recovery can be run in offline mode where logfile space usage is more
controlled. If this condition recurs then reduce the system logfull
and force-abort limits to give the Logging System more free logspace
for recovery. Log File BOF (1156250381, 41420, 292). Log File EOF
(1156250381, 72600, 1816). Reserved space: 180564044.
Any hints?
Thanks,
Nina Markova
Chip Nickolett - 19 Feb 2007 20:53 GMT
Nina,
How large is the transaction logfile? Doubling the size should not
have caused the problem. More likely, the process was force aborting
before and just went unnoticed because it cleared quickly.
There is really no magic number for force abort and log full limits.
What is more important is configuring the installation so that user
access is not impacted by these events. I've set force abort as low
as 50%, and typically set it between 65% - 70%. For log full, I will
typically set this between 90% - 93%. You need to determine what that
percentage means in real space (65% of a 400 MB log file is far
different than 65% of a 2 GB log file).
Replication could certainly be causing the problem if the transactions
are not completing quickly. You can use IPM to find the oldest
transaction, as well as transactions that have performed a lot of
logging activity. Once you identify the problem transaction /
application, you can look at your alternatives for correcting the
problem.
In addition to the errlog.log, you should review the iircp.log,
iiacp.log, and replicate.log files. They should provide more insight
into what is going on.
Best wishes,
Chip Nickolett (ChipN@Comp-Soln.com)
Comprehensive Solutions www.Comp-Soln.com
ninamarkova@yahoo.ca - 20 Feb 2007 17:44 GMT
Thanks.
transaction log is 300Mb. I dropped log_full from 90 to 80, and force-
abort from 72 to 60%.
Dropped them too much? - maybe there will be not enough space for
transactions.
Also cp_interval to 1% - I'll end up with large log files eventually.
Nina
> Nina,
>
[quoted text clipped - 25 lines]
> Chip Nickolett (C...@Comp-Soln.com)
> Comprehensive Solutions www.Comp-Soln.com
Chip Nickolett - 21 Feb 2007 04:29 GMT
Nina,
A 300 MB transaction log file is too small for most environments. I
personally don't like to use less than 1 GB. If you're able to
increase it, even if only by a few hundred MB, I would do it.
One percent is only 3 MB - really too small for a CP interval. I
would probably set the cp_interval to 5% (15 MB), and the
archiver_interval to 1. This will minimize CP flushes of modified
data to disk and should give you a little bit better performance.
Setting the archiver interval to one is good practice in general.
Best wishes.
Chip Nickolett
Comprehensive Solutions www.Comp-Soln.com
> Thanks.
>
[quoted text clipped - 35 lines]
> > Chip Nickolett (C...@Comp-Soln.com)
> > Comprehensive Solutions www.Comp-Soln.com
Jean-Pierre Zuate - 21 Feb 2007 10:53 GMT
Hello,
Just a small remark ...
Doubling the size should not have caused the problem.
Not sure, due to replicator. If you suppose more users can connect during
the day period, we can imagine more transactions to replicate ... then more
ways to have logfull situations with the same configuration (log file size).
HTH

Signature
Jean-Pierre Zuate
La Fage Conseil
+33(0)6 11 40 11 09
jpzuate@gmail.com
http://www.ingres-ua.fr/