Comments on Kevin Kanarski: Reader Poll: Where do you put your Domino transact...

Regarding the size of the log files, I would just ...

2009-01-05T20:30:00.000-06:00

Regarding the size of the log files, I would just be safe and go with the 4GB to be honest. This, of course, depends on the type of data that's being xlog'd. If we're talking about 1,000 active mail users, then go with 4GB. But if we're talking about 100 mail users then maybe you'll only need 1GB of xlogs. I'm not sure of any real specifics, but with disks being so large and cheap now, the space used isn't as much of an issue...

Good discussion here! I know that IBM recommends k...

2009-01-05T20:22:00.000-06:00

Good discussion here! I know that IBM recommends keeping xlogs all on the system ASP on i, but a long time ago when I was bored, I decided to put them on a secondary ASP. Here are the instructions.

Many people think that since the i isn't like other platforms that you don't have as many performance concerns. But if you're already seeing some disk performance issues, don't just throw on xlogs without some planning. Perhaps you could get some used drives (IBM supports them!) for cheap and a used RAID controller for housing the secondary ASP. Like every other computer system, this will likely yield better performance than just adding more load to what you already have. Funny that in my instructions I am putting the xlogs in a directory outside of data...

Anyway, like others have said, if you have no really legitimate reason then I would move these. It's great that IBM has gotten out a fix for BRMS for this, but as it's been pointed out there could be an issue with regressions if they don't get that included in the next release. But then you can at least point them to the PMR/SPR and maybe they can get that fixed much more quickly.

Also, Roland is correct that DAOS will require xlogs. Oh, and don't forget to disable xlogging for mailbox files, etc... ;)

It looks like the BRMS job database became corrupt...

2008-12-31T10:17:00.000-06:00

It looks like the BRMS job database became corrupt with our latest power outage. We have omits for the transaction log files but BRMS was ignoring them. Our iSeries engineer worked with IBM to get the job database corrected and now BRMS is skipping the trans log files like it should be.

Great Rubert...good to know. I don't know why this...

2008-12-30T19:04:00.000-06:00

Great Rubert...good to know. I don't know why this sort of info isn't easily available, at least where I've been looking.

Advice on circular transaction log size (not syste...

2008-12-30T18:18:00.000-06:00

Advice on circular transaction log size (not system i-specific):

The advantage of a smaller log size is the obvious one that it saves on disk space you may want to use for other purposes. Another way to look at that is that smaller logs mean less empty space you need to reserve for logs that may never be written.

The advantage of larger logs is that more data can be written to them before the server needs to get it into the actual nsfs. On a busy server with a small log and slow data drives you can fill up the transaction log during operations such as view rebuilds.

Given that 4GB is not much in today's money, I would allocate the full amount for most servers.

Its good IBM is supporting you, but I wouldn't be ...

2008-12-30T16:39:00.000-06:00

Its good IBM is supporting you, but I wouldn't be overly confident that at some point in a future BRMS release you'll won't run into a regression where the backup breaks again. Maybe you'd be safer to disable transaction logging, then reenable it in the data directory and be done with it, especially since there is no real advantage to "keep them together" otherwise.

Regarding Transaction Log size, I know about the 4 GB max size, but don't see any guidance about the pros/cons of picking any particular size like performance vs safety. I see there are defaults for that setting too. Maybe that's what I'll do, because they know what is best right? :-)

Roland - The largest you can make the transaction ...

2008-12-30T15:08:00.000-06:00

Roland - The largest you can make the transaction logs is 4096 MB. Essentially 63 TXN files is the max.

I think we put the log files in a separate folder just to keep them together. They are still on the main system ASP. We received an update from IBM for configuring BRMS so we will see if it works. Otherwise we will move them under the respective Data folders.

We have not turned on transaction logging on our i...

2008-12-30T12:52:00.000-06:00

We have not turned on transaction logging on our i5/OS either. I'm not the admin but similar to Rolands post all the documentation always says to use a separate drive and that's not really the case in this environment because the "400 just takes care of things like this".. or so I've heard.
I've never found a "Best Practice" on transaction logging on i5 so I couldn't champion this. I didn't know it was a pre-requesite to DAOS though!

There's so little i specific information out there...

We don't have transaction logging yet on our i5/OS...

2008-12-30T11:54:00.000-06:00

We don't have transaction logging yet on our i5/OS but as its a pre-requisite for DAOS in Domino 8.5 I have been researching it. There's isn't a lot of info pertaining to the unique i5/OS platform, but the best info I found in the IBM Redbook "Implementing IBM Lotus Domino 7 for i5/OS" where it says:

"On i5/OS, by default, the transaction logs are placed in the logdir subdirectory of the Domino
server data directory. The Domino Administrator client help text recommends placing the
transaction logs on their own separate drive. The equivalent on the System i platform is to
place them in a separate ASP. However, usually, the benefit is not significant enough to
justify the additional complexity. The basis for this is that the System i platform input/output
(I/O) architecture makes multiple drives look like a single unit, and so performance improves
when drives are added."

So, we were just going to implement the defaults since we are running 4 domino servers and having all their data under their own data directory makes sense to us.

The question you may want to ask yourself is what advantage is there in having the data outside the data directory since you're apparently going to just have backup/restore issues?

My question is how large to make the transaction log. There's not much info about the what size is best, or if it matters on the i.