|
Archives of the TeradataForumMessage Posted: Tue, 24 Sep 2002 @ 16:46:03 GMT
Have someone design the ETL process. This design tends to be optimistic in its outlook. Have someone else design the audit process. They need to look at all the points of failure from a pessimistic perspective. What can go wrong and how would you know? You may not be able to prevent problems but you can be alerted and make a decision to stop/continue the process. How do you know BizTalk has written all the messages into the queue? Biztalk should keep a message count that can be compared later. What other counts and amounts can it summarize? How do you know the middle program has read and written the correct number of messages? Can you compare message in with message out and compare to original count. How about the other counts and amounts. Even if messages are discarded, they should be accounted for. How do you know the tpump job has read and written the correct number of messages? etc... What happens to message traffic if any of the platforms is restarted or crashes? What happens if the queue collapses, fills up or messages span read/write operations? What happens if you get duplicate messages? Jim
| ||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
Copyright 2016 - All Rights Reserved | ||||||||||||||||||||||||||||||||||||||||||||||||
Last Modified: 15 Jun 2023 | ||||||||||||||||||||||||||||||||||||||||||||||||