A tale of two queries [solved]
-
Going to try asking this a different way and see if anyone can help. I have two queries:
SELECT * FROM tblData WHERE Machine = 1 and Operator = 1
and
SELECT SUM(WorkSecs) as WorkTime, SUM(RunSecs) as RunTime
FROM tblData WHERE Machine = 1 and Operator = 1Both of these queries are in a custom application I wrote that has been in operation for about four years. Both queries were taking only milliseconds to return a record. Some time last week the second query started taking about three seconds to return a record. The owner of the SQL server admits to mucking about with data table, so I have DROPPED the data table and CREATED it again. I have also backed up the database and truncated the transaction logs (though I don't think it would have any effect on this). The second query is still taking about three seconds to execute. The custom application is written in C++ using ADO and trusted connection. There are no ODBC/DSN connections defined on the client computer. Can anyone think of anything I can check on the SQL server or the client?
Thanx, >>>-----> MikeO
modified on Wednesday, May 26, 2010 10:16 AM
-
Going to try asking this a different way and see if anyone can help. I have two queries:
SELECT * FROM tblData WHERE Machine = 1 and Operator = 1
and
SELECT SUM(WorkSecs) as WorkTime, SUM(RunSecs) as RunTime
FROM tblData WHERE Machine = 1 and Operator = 1Both of these queries are in a custom application I wrote that has been in operation for about four years. Both queries were taking only milliseconds to return a record. Some time last week the second query started taking about three seconds to return a record. The owner of the SQL server admits to mucking about with data table, so I have DROPPED the data table and CREATED it again. I have also backed up the database and truncated the transaction logs (though I don't think it would have any effect on this). The second query is still taking about three seconds to execute. The custom application is written in C++ using ADO and trusted connection. There are no ODBC/DSN connections defined on the client computer. Can anyone think of anything I can check on the SQL server or the client?
Thanx, >>>-----> MikeO
modified on Wednesday, May 26, 2010 10:16 AM
I don't know enough DBA stuff to answer, but the fact that the second query uses aggregating functions would start me looking at things associated with temporary storage. Also maybe verify the response times by executing the SQL on the server. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
-
Going to try asking this a different way and see if anyone can help. I have two queries:
SELECT * FROM tblData WHERE Machine = 1 and Operator = 1
and
SELECT SUM(WorkSecs) as WorkTime, SUM(RunSecs) as RunTime
FROM tblData WHERE Machine = 1 and Operator = 1Both of these queries are in a custom application I wrote that has been in operation for about four years. Both queries were taking only milliseconds to return a record. Some time last week the second query started taking about three seconds to return a record. The owner of the SQL server admits to mucking about with data table, so I have DROPPED the data table and CREATED it again. I have also backed up the database and truncated the transaction logs (though I don't think it would have any effect on this). The second query is still taking about three seconds to execute. The custom application is written in C++ using ADO and trusted connection. There are no ODBC/DSN connections defined on the client computer. Can anyone think of anything I can check on the SQL server or the client?
Thanx, >>>-----> MikeO
modified on Wednesday, May 26, 2010 10:16 AM
In SQL Server Management studio, under the query menu, select the option to "Include Actual execution Plan" and run your query again. You want to see lots of seeks and no scans. Scans indicate it is reading the table or index from top to bottom. give it a shot
-
I don't know enough DBA stuff to answer, but the fact that the second query uses aggregating functions would start me looking at things associated with temporary storage. Also maybe verify the response times by executing the SQL on the server. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
Not sure where the temporary storage would take place. I have executed the query on the server. There is no noticeable delay. And that is puzzling because both the query sent by the code and the query typed into the Management Studio are executed on the server.
Thanx, >>>-----> MikeO
-
In SQL Server Management studio, under the query menu, select the option to "Include Actual execution Plan" and run your query again. You want to see lots of seeks and no scans. Scans indicate it is reading the table or index from top to bottom. give it a shot
David, I have done this per your suggestion to an earlier inquiry. There are no scans. It executes as quickly as I would expect in the Management Studio.
Thanx, >>>-----> MikeO
-
Going to try asking this a different way and see if anyone can help. I have two queries:
SELECT * FROM tblData WHERE Machine = 1 and Operator = 1
and
SELECT SUM(WorkSecs) as WorkTime, SUM(RunSecs) as RunTime
FROM tblData WHERE Machine = 1 and Operator = 1Both of these queries are in a custom application I wrote that has been in operation for about four years. Both queries were taking only milliseconds to return a record. Some time last week the second query started taking about three seconds to return a record. The owner of the SQL server admits to mucking about with data table, so I have DROPPED the data table and CREATED it again. I have also backed up the database and truncated the transaction logs (though I don't think it would have any effect on this). The second query is still taking about three seconds to execute. The custom application is written in C++ using ADO and trusted connection. There are no ODBC/DSN connections defined on the client computer. Can anyone think of anything I can check on the SQL server or the client?
Thanx, >>>-----> MikeO
modified on Wednesday, May 26, 2010 10:16 AM
Looking at the SQL Profiler on the SQL server I see that each time the second query is called it is followed by an 'Audit Login'. There is always a delay between the query and the 'Audit Login' and apparently my app does not receive a record set until after this is completed. Any ideas what could be causing this?
Thanx, >>>-----> MikeO
modified on Wednesday, May 26, 2010 8:03 AM
-
Looking at the SQL Profiler on the SQL server I see that each time the second query is called it is followed by an 'Audit Login'. There is always a delay between the query and the 'Audit Login' and apparently my app does not receive a record set until after this is completed. Any ideas what could be causing this?
Thanx, >>>-----> MikeO
modified on Wednesday, May 26, 2010 8:03 AM
Further review of the SQL profile shows this: Main program opens database connection (SPID 55) ...3 sec... Events processing thread opens database connection (SPID 56) ...3 sec... [PROCESS NEXT EVENT] Event processing thread does aggregate query (SPID 56) Audit login occurs (SPID XX) (XX usually between 57 and 60) ...3 sec... SET NO_BROWSABLE_TABLE_ON (SPID XX) sp_prepare 'select * from tblData' (SPID XX) SET NO_BROWSABLE_TABLE_OFF (SPID XX) sp_unprepare (SPID XX) Audit logoff occurs (SPID XX) Event processing thread does aggregate query on tblData (SPID 56) Audit login occurs (SPID XX) (XX usually between 57 and 60) ...3 sec... SET NO_BROWSABLE_TABLE_ON (SPID XX) sp_prepare 'select * from tblData' (SPID XX) SET NO_BROWSABLE_TABLE_OFF (SPID XX) sp_unprepare (SPID XX) Audit logoff occurs (SPID XX) Event processing thread does non-aggregate query on tblData (SPID 56) Event processing thread calls stored procedure (SPID 56) Event processing thread does non-aggregate query on tblData (SPID 56) [LOOP: PROCESS NEXT EVENT] I have never run SQL profiler before. From what I have seen I have to guess that either these 'Audit Logins' were not occurring two weeks ago or opening database connections was not taking as long two weeks ago. Can anybody run SQL profiler and give me an idea how long opening a connection normally takes?
Thanx, >>>-----> MikeO
-
Going to try asking this a different way and see if anyone can help. I have two queries:
SELECT * FROM tblData WHERE Machine = 1 and Operator = 1
and
SELECT SUM(WorkSecs) as WorkTime, SUM(RunSecs) as RunTime
FROM tblData WHERE Machine = 1 and Operator = 1Both of these queries are in a custom application I wrote that has been in operation for about four years. Both queries were taking only milliseconds to return a record. Some time last week the second query started taking about three seconds to return a record. The owner of the SQL server admits to mucking about with data table, so I have DROPPED the data table and CREATED it again. I have also backed up the database and truncated the transaction logs (though I don't think it would have any effect on this). The second query is still taking about three seconds to execute. The custom application is written in C++ using ADO and trusted connection. There are no ODBC/DSN connections defined on the client computer. Can anyone think of anything I can check on the SQL server or the client?
Thanx, >>>-----> MikeO
modified on Wednesday, May 26, 2010 10:16 AM
If anyone is interested, I found a solution to this problem on another forum. The connection string I am using has the server IP address to avoid any DNS issues. Apparently this is not good enough. I had to place an entry for the server in the hosts table of the client machine. Once this was done the time it takes to connect to the server drops back into the milliseconds range.
Thanx, >>>-----> MikeO
-
If anyone is interested, I found a solution to this problem on another forum. The connection string I am using has the server IP address to avoid any DNS issues. Apparently this is not good enough. I had to place an entry for the server in the hosts table of the client machine. Once this was done the time it takes to connect to the server drops back into the milliseconds range.
Thanx, >>>-----> MikeO
Just be careful with the HOSTS table entry; clearly and concisely document what was done and why. We had a problem last year with not being able to talk to a device because of undocumented HOST table entries. Tim