Archives of the TeradataForum

Message Posted: Wed, 10 Feb 2010 @ 10:28:47 GMT

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

I anticipated you might ask this question. It is indeed interesting to know why exactly it is necessary to enable the PJ for the receiving database.

In the ideal world, one would think that archive/restore utilities should be able to build exact images of the sources with one touch of a button. Reality is slightly more complex. We know that some objects have traditionally been difficult to handle. For example, we had to drop JI before archiving and rebuild them in the receiving database. SI could be handled automatically but it is often recommended to drop them anyway.

The case you are looking at is different: an extra object is needed in the receiving database. Why? Short answer would be: this is the way it is implemented, and it is up to Teradata Corp. to explain why they have gone for this option. Only they would know all the reasons. My guess is that this PJ on database level is needed to handle potential changes in the receiving database during the restore operation, both regular changes and unforeseen failure-type ones. What we perceive as an extra object may look as a necessity from the Teradata point of view. Potentially, they could have opted for creating an internal object which would not be visible to the customer but they have chosen the database-level PJ. Again, the question is to their software designers as to why exactly they have done this. I hope some of them could share their insights with us here.

Victor

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