Archives of the TeradataForum

Message Posted: Mon, 06 Dec 2004 @ 23:52:33 GMT

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

No, this error did not occur after a restore. According to a description of the error, a query receives this error when a table structure changes (specifically, when the version number increases) between the time the SQL is parsed and the time that SQL is executed. Normally, this would be an extremely short period of time so this error's "window of opportunity" would be very small. However, the fact that we have received this error about 6 times in the past two weeks since adding a JI, and the fact that we NEVER received this error in the preceding two years (even though we drop/recreate secondary indexes and rename tables on a nightly basis) makes me think there is something fundamentally different about join indexes which increase the likelihood of this error. Is it simply the additional amount of time it takes to build the join index?

Even though this did not occur after a restore, your response is very timely.. I was searching for additional information about JI "gotchas" and I came a cross a TDATA posting from January, 2004, entitled "Misunderstanding of join index / problem with ARCMAIN", in which you describe this JI/ARC problem. Jon Christie responded to your posting and made a couple of statements that confused me somewhat. Jon stated "Until a fix is available I would strongly recommend that you put ALL join indexes in databases strictly reserved for join indexes and NEVER archive any of these databases. This will protect you from the worst problems..." At first I though this was a workaround - it seemed to imply that you could avoid the problem entirely by putting all JIs in a separate database that you never archive. However, Jon's subsequent remarks indicate that this is not the case, so I do not understand the value of doing this. Any ideas about this?

Also, Jon referred to DR82673, but I could not find any information about this DR. Any information anyone has one this DR would be greatly appreciated.

thanks,

Cliff Theiss

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