Archives of the TeradataForum

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

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

Doug Drake wrote:

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.

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.

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>>