Archives of the TeradataForum

Message Posted: Wed, 03 Dec 2003 @ 22:51:09 GMT

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

Salut Chamoun,

J'esp�re que tout va bien ;-)
Je viens de r�pondre � cette question pour un autre client, pri�re donc de trouver ci-joint ce que je lui ai r�pondu.....

********************************************************************

First of all, the ARC Catalog (by default called "$NETVAULT_CATALOG" in a OTB-NetVault environment) is used by ARCMAIN, NOT by NetVault. Whenever you start an ARCMAIN backup with the CATALOG option, ARCMAIN will write position information into a catalog table.

When you do an ARCMAIN restore, specifically when restoring a single object, this position information can greatly reduce the restore time, as it allows ARCMAIN to quickly position itself on the tape, avoiding the read of all tape blocks.

Maintenance of the catalog involves (mainly) the cleanup of rows that are associated with backups thave been retired. Currently, there is no automated nor integrated way of doing this.

As it is not NetVault that is using the catalog, one could say that catalog maintenance is also not NetVault's responsibility. That is true, although I admit it would be great if the retiring of NetVault savesets would cause also the cleanup of the corresponding catalog rows. I was under the impression that there is already an RFC TAR for this, I will try to look it up... Oh yes, here it is: ***There is a TAR out (TAR#207301), in which it is being asked that the catalog would indeed be better (and 'online') managed: retiring a Teradata saveset should cause the corresponding catalog rows in the corresponding DBS to be deleted, and so on. This is a Priority 3 TAR, and is NOT committed to any future release yet.***

These are the facts. Now let us look at some options for maintaining the catalog manually....

Whenever you do an ARCMAIN archive, you are assigned a UTILITY EVENT NUMBER (UEN), which shows itself in the ARC output:

11/20/2003 09:53:06 UTILITY EVENT NUMBER - 1113
11/20/2003 09:53:07 LOGGED ON 4 SESSIONS

This UEN is a key value for inserting position info into the catalog table:

EVENTNUM INTEGER
OBJLEVEL CHAR(1)
DATABASENAME VARCHAR(30)
TABLENAME VARCHAR(30)
REPOSITIONINFO VARBYTE(256))

At the same time, this UEN is a key value for inserting info into the dbc.rcevent table:

EventNum INTEGER
CreateDate DATE
CreateTime FLOAT
EventType CHAR(30)
UserName CHAR(30)
DatabaseName CHAR(30)
DataSetName VARCHAR(44)

So, purely theoretical, if one has the UEN associated with a given backup, and when one retires this backup, then one could go and do cleanup in the catalog table (and in dbc.rcevent, which is not the subject of this incident but is really showing the same 'lack-of- maintenance').

If one does not have the UEN, but one knows when the backup was made, then one could also make a "good estimate" of which information in the catalog (and in rcevent) to cleanup.

Suppose that you find entries in rcevent (join it to catalog on eventnum) that refer to 2002, and you no longer have any 2002 backups, then you can safely remove catalog entries that correspond to 2002.

*******************************************************************

Luc Van Gendt - Teradata Regional Technical Support Consultant

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