Head in a blender

Transaction logging? Here’s some stuff to keep in mind

Andy Pedisich  July 31 2009 12:57:06 PM
Got a couple of "log full" errors on my circular transaction logged server which caused it to dump.  It's running R 8.5.  So I decided to poke around and ask some questions. I ran into a communication someone with the same problem got from IBM support.  All the lines preceded by ">" are lifted from the communication.  Lines without them are mine.

> 1.  Please disable transactional logging on these databases:
> names.nsf
> log.nsf
> mail.box(es)
> busytime.nsf
> clusbusy.nsf
> event4.nsf
> admin4.nsf   --Disable TXNs on admin4 if this is not the administration server
> statrep.nsf
> statlog.nsf
> webadmin.nsf
> dbdirman.nsf
> reports.nsf
> mtstore.nsf
> activity.nsf
> ddm.nsf
> 3rd party DBs - anti-virus DBs, spam DBs, etc.
> * You can do this by going to database -> properties -> advance -> disable > transactional logging.

Just to note here that you can do this to all the databases mentioned at once using the Notes Administrator client.

Image:Transaction logging?  Here’s some stuff to keep in mind

> 2.  Then please make sure that these parameters are in the notes.ini:
> MailBoxDisableTXNLogging=1
(Not in 8.5 Admin Help)
> schedule_disabletxnlogging=1
(Not in 8.5 Admin Help)
> LOG_DisableTXNLogging=1
(Not in 8.5 admin help)

I have mixed reactions to all of this information.

First, I am glad to see this list of system databases that should be excluded from transaction logging.  The error message that I got when the server crashed led me to a reference that said there was a continuous transaction that filled the log.  I can easily see why that would be fixed by disabling transaction logging on those databases.  It doesn't matter that my server ran fine for a year with transaction logging running without disabling transaction logging on any database.

Second, I wish that this type of information was readily available in the Administrator's Help.  It sounds like a good all around thing to do.  There should be a section in admin help that says all of these things in one spot.  We shouldn't have to troll to find them here and there.   And considering there was some new information in this communication, it doesn't appear that it should be one of us civilians that should do it.

Here's an IBM doc about transaction logs that has a lot of the information about Transaction logs that should be in Admin Help.  It doesn't seem to give that laundry list of system databases though.

Third, I always end up digging around looking at the fields in STATREP.NSF documents for these stats that tell a lot.  Take this one, for example.  This stat went from zero to hitting in the thousands right before the crash.

Database.RM.SinceStartup.Critical.Log.Times = 0
(Shows how many times your system ran critically log full. If non-zero, consider increasing log size or Number of times that Domino filled the allocated log space. If greater than zero, consider increasing log size. Should be zero. If circular and >0, the system has a long-running transaction)

Quite frankly, I have a real problem with the fact that STATREP has important information that's pretty well hidden. This is information that could really help all administrators.  It's been under my skin for years and I think it's time I started talking about it.

Not today, though.  This is my third post today and I have work to do.  And perhaps a mini-vacation is in order.

- Andy


1Matt Buchanan  7/31/2009 2:39:38 PM  Transaction logging? Here’s some stuff to keep in mind

We've been given the same advice recently. It's also my understanding that you have to compact the databases after disabling transaction logging - just unchecking the box itself won't do (although I'm happy to be corrected there).

Interesting that this is an 8.5 server (our problem was on a 7.0.2 server) - that means there's conflicting advice on transaction logging mail.boxes in 8.5: { http://www-10.lotus.com/ldd/dominowiki.nsf/dx/mailboxdisabletxnlogging }

2Barb Skedel  7/31/2009 3:23:06 PM  Transaction logging? Here’s some stuff to keep in mind

Thanks for posting. Although I've been told to disable transaction logging for several of the databases noted, there were a few that I hadn't. We too had a few crashes in 8.5 thanks to corrupt transaction logs. Support told us to just turn off transaction logging, delete the transaction logs, and then recreate them.

3Chris Whisonant  7/31/2009 3:42:47 PM  Transaction logging? Here’s some stuff to keep in mind

@1 - yes, you would need to compact the db.

With 8.5, you should really enable translogs on mailboxes. I posted some info on this at my blog:

Also remember that you'll need to enable transaction logging on your mail.box files. This may mean that you will need to disable the notes.ini settings for MailBoxDisableTXNLogging=1 and/or RM_NO_LOG_LARGE_OBJECTS=1. You will also need to manually enable transaction logging on the database with the router off by using load compact -T on each of your mail.box files.

{ http://www.bleedyellow.com/blogs/lotusnut/entry/to_enable_daos_on_mail_box_databases_or_not }

And with later versions of DOAS, I know IBM is wanting to tie more into the router, so you'll want to benefit from this more by daosifying your mail.box files.

4Andrew Pollack  7/31/2009 4:46:00 PM  I have to wonder how much of this remains valid

See, it's clear that disabling translogs on these database is to increase performance and reduce the size of the log file needed.

We know that with each version, the performance hit from translogs has been reduced, and lately I'm hearing that even on the same drive there can be very little performance hit. If that's so, then is this list of db's really still at issue? If it is, then is performance really so much better?

Something doesn't jive.

5patrick picard  7/31/2009 6:54:48 PM  Transaction logging? Here’s some stuff to keep in mind

Thanks for the info. I am starting to prep for txn logging in production over the next 2 weeks.

Txn logging is an under documented feature and good guides are hard to come by.

6Mike Lazar  8/1/2009 1:01:25 PM  Transaction logging? Here’s some stuff to keep in mind

Not trolling, my friend, but why circular? Are your servers crashing that much? I personally never saw a reason for circular t-logging. Seemed like a waste. To me, all of the benefits are around better backup/restores. And if you disable t-logging names.nsf, why bother? The first thing that that'll happen after a crash is fixup on names.nsf. Kind of defeats the purpose of circular logging, no? Now, I'll be the 1st to admit I haven't looked at 8.5 T-Logging, so if circular now gives you those benefits, smack me around with a wet noodle.

7Patrick Picard  8/4/2009 1:59:25 PM  Transaction logging? Here’s some stuff to keep in mind

@6 Mike, T-logging is a requirement for DAOS now. Circular is an option for those who do not use backup tools that can leverage the domino API

Running fixup on names.nsf is short..but if you had 100's of mail files open during the crash, these 100 mail file will go thru fixup...which will take a while

8Nitin Agarwal  11/24/2009 12:42:16 PM  Transaction logging? Here’s some stuff to keep in mind

Thanks A Lot :)

9charles ross  12/2/2009 4:17:04 PM  Transaction logging? Here’s some stuff to keep in mind

Funny, we had an IBM ticket about some large file corruption problem and they gave us THIS list of system files to disable the T-Logging on, which I just finished following up on when I came across your tip. Only 3 files in common with yours....

catalog.nsf - not in yours


domlog.nsf - not in yours

ispy50.nsf - not in yours



So now I'm wondering if I do the union of these 2 lists (yours plus domlog, catalog and ispy).


10Dan B  3/4/2010 10:42:51 AM  Transaction logging? Here’s some stuff to keep in mind

I remember discussing this with IBM a few years ago and was able to come up with a similar list to the one in this article talking to their support. However, what they seem to be lacking is a consistent list of system databases they recommend disabling transaction logging on. Here is what I am using as standard practice at this time:

-antivirus databases

-directory assistance databases

-directory catalog databases

-email archiving databases

-journaling databases

-other domino directory databases


-webmail redirects



















11charles ross  9/19/2012 11:10:28 AM  Transaction logging? Here’s some stuff to keep in mind

These parms seem to cover mail.box, log.nsf and I guess busytime.nsf if that's what Schedule uses.





12Steve Watts  2/6/2014 3:13:55 PM  Transaction logging? Here’s some stuff to keep in mind

I say to always transaction log important databases. names.nsf is very important, your server doesn't do so well w/o it. mail.box should be logged as well (if you value mail), it is the first point of entry for email. admin4.nsf should be logged on your admin server. log.nsf needs special handling, if it is unlogged and over 1GB in size, the fixup that is run on it following restart will have a major impact on server startup. So you either need to rename it & let a new one be recreated or keep it small (we just run w/ txn logging enabled on it, especially w/ circular logging). Most of the other ones I don't have much say on.

I should mention, all concurrency improvements that are being made depend on the db being transactionally logged.


Domino database dev

13jeff  11/9/2016 9:16:24 AM  Transaction logging? Here’s some stuff to keep in mind

I currently setting up my rig ( { http://www.spectra.com/netapp/used-system/131/index.htm ) and this article helps a lot on my end giving me some good foundation when starting a configuration. } ) and this article helps a lot on my end giving me some good foundation when starting a configuration.