iSeries journaling performance

Question

I am responsible for a legacy application deployed on an iSeries V7R3. The application is fairly high volume, 2 million or so transactions per month.

The database for this app spans multiple libraries and I am currently journaling each library individually. I've been looking on the web for suggestions as to whether this is the best approach or if a single journal for the application might be better or at least be just as efficient.

So far I haven't found any clear advice on this topic, with some advising separate journals for each physical file. Of course searching for anything about the iSeries brings back ancient results often with no mention of the OS version or date of the information.

I'm not experiencing any problems other than managing multiple journals is sometimes a pain.

Answer 1

Any files that are changed together, ie. could be changed in a single transaction, should be journaled to the same journal. But the don't have to be, it's just simpler that way.

Without knowing more about your application, it's hard to provide recommendations. I'd question the need to split the files between libraries.

I will say, in no way shape or form should you have a journal per file (table).

We have a mutli-tenet application with about 300 tenets/10,000 users per server. Each tenet has their own data library and we have only 4 journals per server, so about 75 data libraries per journal.

IBM's documentation says

When deciding how many journals to use and how to assign objects to journals, consider the following:

• Using one journal (and journal receiver) is the simplest method for managing both daily operations and recovery. There is a limit of 10 000 000 objects that can be journaled to a single journal.
• If using a single journal receiver causes a performance bottleneck, you can alleviate this by placing the journal receiver in a separate disk pool from the objects that you are journaling.
• To simplify recovery, assign objects that are used together in the same application to the same journal.
• If you are journaling database files, all the physical files underlying a logical file must be assigned to the same journal.
• Files opened under the same commitment definition within a job can be journaled to different journals. In commitment control, each journal is considered a local location.
• If your major applications have completely separate objects and backup schedules, separate journals for the applications may simplify operating procedures and recovery.
• If you journal different objects for different reasons; such as recovery, auditing, or transferring transactions to another system; you may want to separate these functions into separate journals. However, you can assign an object to only one journal.
• If the security of certain objects requires that you exclude their backup and recovery procedures from the procedures for other objects, assign them to a separate journal, if possible.
• If you have basic disk pools with libraries, all objects assigned to a journal must be in the same disk pool as the journal. The journal receiver may be in a different disk pool. If you place a journal in a disk pool without libraries (non library disk pool), objects being journaled must be in the system disk pool. The journal receiver may be in either the system disk pool or the non library disk pool with the journal.
• If you have independent disk pools, they must be library capable in order to journal objects on them. You cannot journal objects on User-Defined File System (UDFS) independent disk pools.