Archives of the TeradataForum

Message Posted: Wed, 24 Jul 2002 @ 15:18:53 GMT

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

I think that you should consider a PAC Enhancement Request before trying anything like this. I certainly wouldn't recommend making your proposed change without the full buy-in of NCR.

The very first thing that occurred to me about changing the PI of DBC.ACCLOGTBL is that you'll have to drop the table and then re-create it.

The point being...

Each table is identified by a unique hexadecimal value called the TVMID (or sometimes TABLEID). The system tables in database DBC have special TVMIDs, also called Well-Known TVMIDs. Since each system table has a specific TVMID, the system software can safely refer to the table by its TVMID without having to perform a look-up in DBC.TVM. (FWIW: My experience is dated, so things might be somewhat different now).

In the process of dropping and then creating a new DBC.ACCLOGTBL, the new table will be assigned a new TVMID. If the DBC.ACCLOGTBL table is still referenced by its Well-Known TVMID, then the DBC.ACCLOGTBL will have disappeared as far as the system is concerned (and then the system will do some kind of nasty crash). At that point, probably the only way to recover is a SysInit.

If somebody has actually done this in the field, it would be neat to hear the details.

Probably the best way of handling the DBC.ACCLOGTBL is to have a history table (with a more desirable PI) where the contents of DBC.ACCLOGTBL are periodically transferred to the history table and then DBC.ACCLOGTBL can be purged. That way, the size of DBC.ACCLOGTBL will never get very large and the likelihood of Hot-AMPing will be minimized.

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