Archives of the TeradataForum
Message Posted: Thu, 28 Feb 2002 @ 19:31:37 GMT
If a backup is run, with checksum and you don't analyze, you can't be sure the backup is good. A backup may run to completion without reflecting an error but that doesn't mean it's good. There are times when an error is written to a log file while the backup shows successful completion. Rob has a "sniff" program that looks for various keywords (e.g. error, invalid, etc) but some errors happen that don't use these keywords (e.g corrupted fingerprint). These new words may be added to the sniff but, until you discover the error, you don't know if the backup is good or not. Usually, you find out when you try to recover something.
The problem that Rob is trying to address is: in an errored backup situation, for the types of errors that are corrupting our backups, GSC has recommended the checksum/analyze approach. This, in effect, doubles the length of time for the backup. If anyone else is running this type of scenario, we'd like to swap info with them to see what's what.
|Copyright 2016 - All Rights Reserved|
|Last Modified: 27 Dec 2016|