Archives of the TeradataForum

Message Posted: Tue, 09 Jul 2013 @ 10:08:05 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Hi Roopalini,

Yes, permanent journaling has 'issues', but there again so do most features, it's just a case of whether those really affect you or not. To address the points that you raised:

1) Correct. PJ's do not track changes to the table structure, only the data.

2) There's an overhead whether your table has 2 rows or 200m rows. The number of rows in the table does not affect the overhead of PJ, it's the number of changes made during your processing. Even if you are processing 200M rows, what percentage of the target table does this represent? If 200M rows is 50% of your table, then PJ is probably not a sensible option. If 200M rows is 1% of the target table then it looks a lot more attractive.

3) Sure, if the PJ gets turned off then changes won't get backed up. But by the same token if the backup fails then "they won't get backed up". If (and I'm not saying that PJ is the best answer for you) PJ is the chosen method of ensuring recovery then ** don't turn it off **. Or at least make the customer/user aware of the consequences of turning PJ off.

THERE IS NO DIFFERENTIAL BACKUP in Teradata.

Remember that a 'back up' is just a copy of the data, and one from which you can recover to a known point in time/processing. There are all sorts of ways that you can do this in a Teradata environment, and in my experience the 'best' outcome for the customer is a usually mixture of methods.

- backup using the arc utility

- PJ feature

- keep a copy of the input data files

- use 'create table as' to build a copy of the tables on the Teradata system

Cheers,

Dave

Ward Analytics Ltd - Information in motion (www.ward-analytics.com)

	<Prev	Next>		<<First	<Prev	Next>	Last>>