 |
 |
Archives of the TeradataForum
Message Posted: Fri, 24 Jan 2003 @ 00:07:39 GMT
| Subj: | | Re: Connectivity Tests |
| |
| From: | | Matthew Winter |
Hi,
| | To get BTEQ to run it's fastest, you need to do an .EXPORT DATA. I'm not sure from your e-mail that you did this. | |
An .EXPORT DATA was used to perform the BTEQ Tests.
| | For exports (BTEQ, ODBC, etc), ensure the response buffer is maximum e.g. 64000. I don't know the exact max number. Each
interface has a different way of specifying that. For example, I believe BTEQ defaults to 8K which would require 8 times as many
request/response round trips as 64K. | |
The ODBC connections were configured with 65477 Response Buffer Size, the OLE DB connections had the extended properties setup with the
Maximum Response Buffer Size and the CLISPB.DAT file was modified to ensure the CLI connections used the Maximum Response Buffer Size.
| | Your FastExport result of '1 session is best' indicates fundamental incorrect operation of FastExport--it was created to speed
up the return phase via multiple sessions (via interleaved non blocking operations returning one spool). An incident should be opened.
Increasing sessions should increase the return phase throughput dramatically (with diminishing returns) assuming no other limiting factors
such as the LAN, client cpu, output media, etc. | |
When I did the original FastExport investigation, I performed the tests on a Dual CPU, Windows 2000 Server, connected via 100Mb LAN
connection into the same Switch as the Teradata Nodes. CPU usage never went above 15% during the tests. The tests were performed using the
6.1 Teradata Utilites. I have considered rerunning the tests again with the latest release, but have decided not to, until we move to V2R5
and 7.0 Teradata Utilities.
I could raise it as a problem, except the performance with 1 session is good and well above what we would expect.
Does any other company use the Windows version of FastExport and have you experienced this same issue?
Matthew Winter
| |
