Home Page for the TeradataForum
 

Archives of the TeradataForum

Message Posted: Sat, 02 Jun 2002 @ 00:18:20 GMT


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


Subj:   Re: TSET
 
From:   Dennis Calkins

Doug Drake wrote:

  We are considering the use of TSET to analyze an initial workload to enable us to understand the impact of various designs prior to having populated tables. There does not seem to be that much experience or information available on TSET. And after going through the only known piece of documentation on TSET (Teradata System Emulation Tool User Guide, June 2002, B035-2492-062A) I am left with the questions below.  


  A.) When a query in the target environment is "emulated" does this mean that one can generate explain plans in the test environment without having the real target data or the target hardware?  


Yes. The Real data and the real hardware is irrelevant.

TSET captures the DDL, the Stats, intersting optimizer variables and Constants, Number of AMPS, and PEs, and Nodes, some of the GDO tuning settings and anything else that may affect how the optimizer will plan the query and bundles them into a TAR file.

Then you take this TAR file over your test box and have TSET IMPORT it into the server.

Then you can run BTEQ EXPLAINS in this emulated TSET mode and the explains will be generated using all the optimizer information captured from the production box.


  B.) What other information can be gained from the emulation? For instance, can we gather the estimated CPU and I/O units for the emulated queries?  


You get the explain text just as if you had run the explain on your production box without adding workload to your production environment.

It should be the exact same explain text you would get on your production box if all thing were equal.

I say it that way because one of the purposes of TSET is to allow you change the emulation environment (like number of nodes, or amps, amount of data, cpu speeds, memory, SQL text) and see how that affects the explains.

Since Answer set size estimates and cpu time estimates are contained within the explain Yes you will get that information and everything else you would get from a normal explain.


  C.) If we need to emulate an environment using tables that are not currently populated can one easily "customize" the statistics and demographics in such a way that TSET sees these tables as fully populated with all the column and index statistics?  


Unfortunately I don't know about customizing the stats but since This is one of the variables you may want to change, there should be some way to do this.

Again the whole purpose of TSET is to allow the user to CUSTOMIZE the TSET environment to Play WHAT IF games. like....

What happens if I had 900 MHZ cpus instead of 500 MHZ?

what happens if I add another condition to my where clause?

What happens if I use NOT IN instead of NOT EXISTS in my query.

What happens after I upgrade to 4.1.3? (requires upgrading the TSET enabled box to 4.1.3. However, most of the time the TSET box is a 1 or 2 node TEST system so upgrading to the next version isn't as hard as upgrading the production box.


If fact we encourage people to use TSET to capture their query information on their production system running 4.1.0, or 4.1.1 or 4.1.2 and then takes the TSET information to a test system that has been upgraded to 4.1.3 or 5.0 (when it is released) and run the explains and see if they change.

IF you feel the change is detrimental to your job mix open an incident to the GSC and send them your TSET bundle and let them us run it against 4.1.0 and 4.1.1 and 4.1.2 and 4.1.3 and 5.0 and see if they agree the change was unwarrented.


Again no actual Data from the production box is required to run these TSET jobs, so you don't have to send billions of rows to the GSC, just the TSET bundle.

I would go so far as to suggest you capture the TSET information for any optimizer issues (3610, 'BAD' plans after upgrade) you are having and send that along to the GSC when you open your incident.

If the optimizer crashed (or chooses a different plan) running your query, it is a good bet it will behave the same way in a TSET environment emulating your query and that will help Teradata solve the issue since they can actually debug the behaviour on their own test system.



     
  <Prev Next>   <<First <Prev
Next>
Last>>
 
 
 
 
 
 
 
 
 
  
  Top Home Privacy Feedback  
 
 
Copyright for the TeradataForum (TDATA-L), Manta BlueSky    
Copyright 2016 - All Rights Reserved    
Last Modified: 27 Dec 2016