March 29, 2002 at 7:54 am
I'm using netmon to view some network traces of requests from an IIS Server to a pair of SQL servers. In the decription field of the the TDS frames of the netmon trace I am seeing terms such as UNKNOWN EOM or just UNKNOWN e. g.
TDS UNKNOWN EOM Len = 0 Chnl = 12475 Pkt = 155 Win = 0
I'm am reviewing this network traffic because the customer has complained of the slowness of the web based application that he is using. I would like to know what the terms UNKNOWN and EOM stand for and could this be what is causing the slow data retrival
TIA
Mike Adkins
March 29, 2002 at 8:21 am
I don't think TDS is very well documented, but maybe someone will have an idea. Are you sure it's network traffic and not the query and/or the SQL Server itself? Or the IIS box overloaded?
Andy
March 29, 2002 at 8:45 am
Andy,
In one of the TDS packets that shares this description I can see the SQL Select query that is requested from the SQL server. It could possibly be the query that is causing the problem and the error is not being logged - I would like to use the network trace to determine this.
TIA
Mike
March 29, 2002 at 9:59 am
quote:
It could possibly be the query that is causing the problem
For this I qould suggest use Profiler against SQL server. Netmon will be of any help to handle queries in SQL.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
March 30, 2002 at 6:16 am
If anyone is familar with TDS packets that are processed through Netmon - if possible could you explain to me what the following packet description means
TDS UNKNOWN EOM Len = 0 Chnl = 12475 Pkt = 155 Win = 0
TIA
Mike Adkins
March 31, 2002 at 5:25 pm
EOM is possibly end of message. TDS isn't well documented. Some guys have reverse engineered TDS under Sybase, but Microsoft has continually expanded upon it, and SQL Server 2000 is now running version 8.0 of it. Microsoft hasn't released any documentation explaining the structure of TDS packets and it's doubtful they will any time in the near future.
What is the bandwidth utilization on the path between the SQL Server and the web server? Also, is the protocol access via TCP/IP rather than named pipes (TCP/IP is fastest across a network)?
And as Antares has indicated, Profiler will give you some times it takes for the queries to complete. That's not a bad place to look, either. A query could be running long due to a lack of indices or because statistics are out of date, and Profiler can reveal this information.
K. Brian Kelley
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply