|
It is a very good idea to have your journal receivers in separate ASP's.
Their is no performance implication to leaving the journal object itself in
the same library and ASP as the files being journaled though. In fact
leaving the journal with the files makes it easier to restore the data from
backup.
Create a separate ASP for each journal if possible. Mixing the receivers for
several different journals in one ASP will result in poorer performance.
The best journal performance can also be obtained by placing the receivers
for each journal in a "MIRRORED" ASP. Mirrored protected disks are
preferable to RAID protected disks because writing journal data to a RAID
disk results in the disk arm swinging between the outer and inner part of
the disk drive as RAID striping is updated. I can't remember exactly which
way it is, but I believe the RAID striping data is written to the outer part
of the disk while the receiver data is written to the inner part.
If your journal environment is very active, utilizing as many disks arms as
possible will always improve performance. On version 4.5 a new receiver size
option was introduced, *MAXOPT1. This journal option not only allows you to
have receivers up to 1 terabyte in size, it also allows for receiver data to
be written to 100 disks at a time. Prior to this feature, the maximum number
of arms used by journaling was limited to the 10 fastest arms in an ASP.
If you are by chance using remote journaling to synchronize transactions
between your mirrored systems, it is best to configure exactly the same
number of disk arms in each ASP on both systems. Remote journaling will only
use the number of arms it uses on the source system when the transactions
are replicated to the target system, even if you have more arms in the
target system's ASP. I've had discussions with IBM on this and have been
told that it is just a "quirk" of remote journaling.
In summary, the only negative implications to using separate ASP's for your
journal receivers is NOT to use them.
|
