Archives of the TeradataForum
Message Posted: Thu, 19 Jun 2003 @ 16:29:50 GMT
If a job fails that is populating a table which has after journals enabled, the journal simply logs all table activity regardless. You're right in saying that Teradata will not rollback the journal entries if a transaction in progress fails. If you check the currentperm space of the journal table in this situation, you'll see that its still holding the aborted records, although none of these transactions will be applied to your target table during any subsequent ROLLFORWARD operation. Teradata substitutes an ABORT on the journal entries instead of the usual ET, so there's no chance of your target tables being corrupted with transactions that failed against the original journalled table. This means that you should be able to checkpoint and archive as usual, and the journal perm space will be cleared when you run your next DELETE job. The only side-effect that I can think of with this, is that you may see the currentperm in the journal once it is restored (i.e. after you've completed the archive as described above, and restored this file to your DR system - for example), not being completely cleared down, as Teradata will not be processing the transactions marked as ABORT. In which case, you'd need to run a one- off delete against the journal, but this is not really a great problem.
Ultimately, you're not able to remove the aborted transactions in isolation from the active (or saved, once checkpointed) subtable. However, as they are effectively meaningless and won't impact upon your target tables during rollforward, then this shouldn't pose too many problems. All of this does mean of course, that your journal table has to possess enough perm space to cater for these situations (which you've already realised). Ensure that your journal database(s) are added to whatever space monitoring routines are used at your site (canary queries, etc). I recall reading somewhere too that it is recommended that journal databases are sized at 3 times their expected size, to cater for the (very rare!) situation of your active, saved and restored subtables all holding maximum amount of expected data at the same time. This situation is technically possible, but not really very feasible.
Hope this helps.
|Copyright 2016 - All Rights Reserved|
|Last Modified: 27 Dec 2016|