Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / Ingres Topics / February 2007

Tip: Looking for answers? Try searching our database.

LOGFULL problems

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
ninamarkova@yahoo.ca - 19 Feb 2007 16:54 GMT
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/

 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.