Archives of the TeradataForum
Message Posted: Thu, 17 Apr 2003 @ 20:30:15 GMT
| Subj: | | Re: Capturing Data Leaving Teradata Machine |
| |
| From: | | Anomy Anom |
<-- Anonymously Posted: Thursday, April 17, 2003 15:56 -->
This is the answer from the developers: On the Solaris machine, the data was "sniffed" from interface /dev/hme0 which is a lan
connection. They collected all the network traffic from Teradata. The "sniffer" collected raw bytes which were analyzed to help
sectionalize the source of the (rare) data corruption.
John Hall also wrote in another reply:
| | It's certainly possible for the Teradata to be returning bad results. When you say corrupted, what is it about the data that isn't
right? Is there a specific query/macro which is returning the corrupted results? Can you post the SQL? What is your release of
software? | |
The data in the table is correct. This application says that sometimes the data comes back corrupt, but when they run the query again,
the data is correct. So because of the "sniffer", they think they have captured the data as soon as it comes off the network and hits their
server. I verified that data captured is not correct, but I'm not convinced that Teradata is the culprit. In our OLTP, we have over a
million transactions a day and this is the only query that returns supposedly returns "corrupt" data. But it has become my job to prove
that Teradata is innocent. Thus I looking for a way to capture the data as it leaves the Teradata machine.
We are running V2R3.0.3.110. We use CLI. I don't think posting the macro would help, because whenever I execute it, I get the correct
results.
| 
