Archives of the TeradataForum

Message Posted: Sun, 02 Sep 2001 @ 09:07:37 GMT

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

Hi,

In my experience, it's not completely true, but it's not all hype either.

You do 'sometimes' get database corruption, but I think it is very rare in a Teradata environment. In @8 years of Teradata experience working with 10-12 different customers I think I've only come across it 2 or 3 times that I can remember (which probably means it's about 3 or 4 times !). I will be perfectly open and say that the reason for my multi-customer experience is because during this time I worked for NCR (therefore if you wish to treat my reply as more sales hype then feel free).

What happens when you do get corruption depends (as always) on the extent and nature of the problem.

To clarify terms, corruption in this situation is when the dbms software, disk mangement s/w etc corrupts the data and not when the application does the wrong thing, or the wrong input file is loaded etc etc.

Back to options ...

1) a secondary index is corrupt and the data rows are correct: drop the secondary index and rebuild it. This requires two sql commands, it may take a while (typically up to 10's of minutes and not hours - depends on size of machine and size of table) but with the current release of Teradata users can continue to read the table during the bulk of this process. Conflicting database locks only come into effect at the end of the process.

2) the Teradata DBMS software has an option which allows you to hold a second copy of the table. This is called FALLBACK. If the primary copy of the data and the Fallback copy are out of sync then there is a utility (I think "table rebuild") which will allow you to rebuild either copy from the other.

3) if the data row is corrupt and you don't have Fallback (which probably most sites don't) then you can rollback or restore and rollforward - depends on what your recovery strategy for the specific table is. This is much the same as you could do on any dbms.

One thing to remember about all of the above is that a lot of the work is done by the Teradata system, so the processing runs in parallel across all the AMPs (units of parallelism), so your not waiting for a single resource to do the bulk of the work. The one exception mentioned above is the 'restore', this implies reading data from backup media which will typically be a tape on your client system. This may mean that you've reading from a single tape unit on your MVS mainframe, that part of the processing is essentially single-threaded. However, you have the option of backing up to directly attached tape silos which also means that you can run multiple concurrent backups (or restores). One site that I've worked with recently is recording some very good backup times using this architecture.

The above talks about resolving the problem when it happens. There is a utility called CHECKTABLE which can be used as a sanity check on your data. This can check the various items that I've mentioned above (secondary indexes out of sync, primary and fallback out of sync etc etc) and it's a good idea to run this on a regular basis.

Hopefully that gives you some ideas as to what can happen in a Teradata environment. At the end of the day, my own experience says that database corruption is not a frequent occurrence in a Teradata environment, but you're perfectly correct in that it can happen. There are utilities to detect when it has happened and there are relatively easy ways of correcting it once it has happened.

I'd be interested in what other list members have to say (whether they are ex-NCR employees or not !). If you want any more info please feel free to email me.

Regards,

Dave

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