Tuesday, December 30, 2008

Reader Poll: Where do you put your Domino transaction log files on i5/OS?

When running Domino on i5/OS and using transaction logging, do you put the transaction log files in a folder under the Domino data folder or in a separate folder on the IFS?

There is a bit of a debate going on between us and IBM on this. All of our i5/OS Domino servers have their transaction log files located in a separate subdirectory on the IFS. Such as /TRANSLOG/Server/ versus using /Domino/Server/Data/logdir. Domino doesn't care where they are as long as you point to them. It looks like BRMS does care where they are. If they aren't located under the Data folder then they don't get treated as Domino transaction log files.

We have been running with them outside the data directory ever since we have had the i5/OS systems with no issues. However we are now getting corrupt transaction log files when BRMS runs every since the power issue discussed in my previous post. I also can't find it documented anywhere that they must reside under the data directory on i5.

We use circular logging versus archive so BRMS doesn't need to touch the log files but it still does.

Thanks for the input.

9 comments:

Roland said...

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.

David Leedy said...

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...

Kevin Kanarski said...

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.

Roland said...

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? :-)

Rupert said...

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.

Roland said...

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.

Kevin Kanarski said...

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.

Chris Whisonant said...

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... ;)

Chris Whisonant said...

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...