There are far too many variables and the question is too vague. As noted, there is always a performance impact every time any program runs. For journal processing, it can be complicated.

In a perhaps ideal setup, you would want your journal receiver in a user ASP consisting of mirrored drives. Also, the user ASP should have no other activity except the journal functions. This allows journal entries to be deposited as much as possible in consecutive disk sectors. There would be essentially no disk arm movement to write next entries. And because it’s mirrored, reads can come from whichever disk has a disk arm closest to the data being sought.

But you rarely see setups approaching “ideal”. Does it describe your system?

If not, then what is your system configuration? How many drives? (How many arms?) What journaling is done? What database activity happens in the same ASP? (How much is journaled?) Is commitment control always active? Sometimes? Never? What kinds of referential constraints exist? (How many of them are actively involved in common activity?) What will your journal entry requests look like? Single entries? Buffered blocks? (How many entries per block?) Will you have individual and separate jobs for each file that entries will be received for? Or will it be one job that will receive all entries and call different programs to process entries for different files? What is your normal CPU usage? Has any performance tuning been applied to the system? What is the usual disk usage? How much extra capacity is available?

Generally, you’re not going to see significant difference. The only good way to get a picture will be to try it. If it isn’t satisfactory, focus on fixing whatever element causes the biggest drag.

Tom