Tag Info

Hot answers tagged

5

I would strongly suggest metadata in the connection in order to trace back to the application. In the connection string, there is an Application Name. There is also session data which can be used in the form of CONTEXT_INFO http://stackoverflow.com/questions/323494/sql-server-modifying-the-application-name-property-for-auditing-purposes Of course all ...


4

It's a bug. This Connect ticket has a workaround for it from Kendra Little: I was able to work around this issue by temporarily adding a scheduled to the Utility Information collection (@collection_set_id=4) with the SQL command below. After doing this I was able to complete the data collection configuration via the GUI successfully. Afterwards I ...


4

Typically, when a query is "interfering" with another query it is either blocking or deadlocking. Either of these would not be visible via a default SQL Profiler trace. If you are experiencing deadlocks, you will want trace flags 1204 and 1222 turned on in SQL Server so the deadlock output gets sent to the errorlogs. You could also re-run the trace and ...


3

I've just read your entire post and it matches exactly with the symptoms we are seeing in our smaller environment. The only difference is that we are running SQL 2008 R2 on Windows 2008 R2 Standard. We have no errors on any of the switches and no errors from the network stack suggesting that the reason for the timeout is valid. The only common theme here is ...


3

Use the most_recent_sql_handle in sys.dm_exec_connections to see the last statement that was executed. SELECT t.text, QUOTENAME(OBJECT_SCHEMA_NAME(t.objectid, t.dbid)) + '.' + QUOTENAME(OBJECT_NAME(t.objectid, t.dbid)) proc_name, c.connect_time, s.last_request_start_time, s.last_request_end_time, s.status ...


3

Have you tried using Adam Machanic's sp_whoisactive? There's an option to get the outer command to see if it really is within a proc. It could be the application is holding open a transaction instead of committing it. Try looking at DBCC OPENTRAN as well.


2

From comments, I'm guessing you had a client side Command timeout that has aborted the SQL query. This does not rollback the transaction because the connection stays open on SQL Server due to connection pooling. So, you need to use SET XACT_ABORT ON or add some client rollback code See SQL Server Transaction Timeout for all the gory details


2

Have you checked the error log? In Object Explorer, expand Management, expand SQL Server Logs, right-click Current... and choose Show SQL Server Log. Hopefully there will be more details there about what is causing the timeouts. If you can post anything suspect that you find there, we can help you troubleshoot further (though it may be something obvious, ...


1

So there's a couple of ways that this can happen. The queries in the blocking database reference objects within the blocked database. The queries are waiting for tempdb to allocate pages and one query is blocking another query. There is memory pressure and queries are waiting for memory to be allocated so they have to wait their turn in the memory ...


1

Turns out to have been a bug in the GEOS package-- there is an announcement on the postgis-users list. The link to the bug report is here.


1

I'm probably off-base here with my response, because I'm not really going to address finding the offending code, other than saying... Knowing the executed SQL from the trace, leads to knowing the associated ORM entity, which leads to Find All References in Visual Studio. Hopefully the code is DRY, but that's a separate topic. I'll focus on SQL performance ...


1

Can you check you sys.dm_os_schedulers ? Specifically, does work_queue_count deviates from 0 for any significant time? This would indicate worker starvation and would explain many of your symptoms.



Only top voted, non community-wiki answers of a minimum length are eligible