October 31, 2016 at 11:51 am
Something on m 2005 SQL server is triggering this event, once it starts it repeatedly fills my application event log with "Error 50000 Severity: 10 State: 1 The backlog is: (null). The backlog table is: (null).
I have tried googling this message so that I can get it resolved but nothing is coming up for a match on this vague message. I can still connect and do things from t-sql and my applications that are connected aren't complaining, but my end-user apps halts all ability to log-in and don't log any errors when I find this message occurring. They make contact with the server but never complete what they need to do to complete database checks for completing the login sequences.
If I stop and restart the SQL server, the problem will go away until whatever triggers it again.
October 31, 2016 at 12:02 pm
Mindy Hreczuck (10/31/2016)
Something on m 2005 SQL server is triggering this event, once it starts it repeatedly fills my application event log with "Error 50000 Severity: 10 State: 1 The backlog is: (null). The backlog table is: (null).I have tried googling this message so that I can get it resolved but nothing is coming up for a match on this vague message. I can still connect and do things from t-sql and my applications that are connected aren't complaining, but my end-user apps halts all ability to log-in and don't log any errors when I find this message occurring. They make contact with the server but never complete what they need to do to complete database checks for completing the login sequences.
If I stop and restart the SQL server, the problem will go away until whatever triggers it again.
I believe error 50000 is a user-defined error, in which case this could be like looking for a proverbial needle in a haystack. I'd start by looking at whatever applications you have connecting and talk to the developers. If someone's throwing a custom error, I'd hope they would know about it and not just have a loop somewhere that keeps retrying the same thing hoping for a different result.
October 31, 2016 at 12:08 pm
This is on an older QA server of mine that's been starting to act a bit weird. It's running applications that are released and running in the field for months, so I'm leaning toward something server specific not app specific. It's also 3 different end-user apps (one of which hasn't changed in years, it's a product being phased out) that have completely different methods of communicating with the database. None of my other QA machines behave like this one.
October 31, 2016 at 12:32 pm
I would look at setting up a server side trace. You will probably want to look a procedure start/stop, statement start/stop and there may be a few others. I may not have the precise names here but it should help. The trace should run continuously until you see the errors, then you can relate the time of the errors back to the trace to see what was running at the time.
If you need help with setting up a trace, please ask. I am sure that there are others much more knowledgeable in this area that can help you.
I don't use traces (or extended events) often enough to really help at this time.
October 31, 2016 at 12:40 pm
I'm comfortable with traces, just which events to trace might be the question. I can't readily reproduce the behavior either. The server ran fine for days after the last time I restarted it.
October 31, 2016 at 1:32 pm
Mindy Hreczuck (10/31/2016)
I'm comfortable with traces, just which events to trace might be the question. I can't readily reproduce the behavior either. The server ran fine for days after the last time I restarted it.
Depending on how busy the server is, at a minimum, from the Errors and Warnings, you can capture the User Error Message and include the login and host columns. If you just grabbed this and filtered on error 50000 it seems it would be a very lightweight trace.
If you wanted to add more information, possibly add SQL events batch starting and batch completed
I'd probably want to make sure I pick up the host and login though to start narrowing things down.
Sue
November 2, 2016 at 11:50 am
Resolved. Profiler shed the light I needed. There was a old but still enabled\scheduled SQL job firing off and never stopping as it didn't accommodate for NULLS in its final step, which was monitoring a table for backlog counts and logging the backlog (NULL, in my case!).
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply