Archives of the TeradataForum
Message Posted: Wed, 10 Feb 2010 @ 10:28:47 GMT
| Re: Error 3566 - Database does not have permanent Journal
| Victor Sokovin
|Can you please explain why the database needs Journal enabled for restore and interesting part is the source does not have Journal enabled
for Db (After journal was enabled for tables only).
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
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
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.