January 5, 2010 at 7:51 am
We have a server that is throwing the above message from SQL Server Agent. It is the only one of 10 separate servers that is.
I can see from the correspodence that this was supposed to be fixed by either SP1 or SP2 but was not necessarily so. Has it been fixed in SP3?
What bugs me is that the other nine servers have not had any SPs anyway and are not throwing this error. What causes this error?
The application on the server in question is running very badly although there seems to be no problem from an SQL/Infrastructure point of view.
My first thought is the application but I would wish to eliminate any issue regarding this message from the equation before we start looking elsewhere.
Madame Artois
January 5, 2010 at 10:33 am
I'd start by checking the permissions assigned to the SQL Agent Service Account.
Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
My Blog | Twitter | MVP Profile
Training | Consulting | Become a SQLskills Insider
Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]
January 6, 2010 at 5:44 am
I am not sure how to check this. The Infrastructure team built each server with the same 'Local System' account running all the services. I have been digging around on the internet, bol etc trying to understand the security permissions etc and the new SQLAgent roles. Why do they never cover this in training??? Perhaps there is a course I have missed?
I have been digging around on all 10 servers. More than the original server are throwing this error but only this one has the degridation of performance. So I think it is a bit of a red herring as regards the performance but, very obviously, I need to understand this aspect of security and am thankful for the guidance anyone can give
Madame Artois
January 6, 2010 at 6:39 am
What are the events following and prior to the 87 error in the Agent log? What are the events in your SQL Server log within the same time frame?
Are these servers clustered?
Shawn Melton
Twitter: @wsmelton
Blog: wsmelton.github.com
Github: wsmelton
January 6, 2010 at 7:01 am
The servers are not clustered.
It seems to start once the TSM backup starts. This software backs up all the servers and it does have SQL agent which enables it to back up running databases. However it does not clear down the transaction logs so I have a separate series of SQL backups to clear these down.
Once the errors have started they continue to fire every few minutes or so. The odd thing is that TSM backs up both the servers that are throwing these errors along with the ones that do not.
Madame Artois
January 6, 2010 at 7:04 am
Do you have those backup jobs trying to output to a log file?
Does that output file give you any more information if you do?
However it does not clear down the transaction logs so I have a separate series of SQL backups to clear these down.
What do you mean by "clear down"?
Shawn Melton
Twitter: @wsmelton
Blog: wsmelton.github.com
Github: wsmelton
January 6, 2010 at 7:08 am
I am pretty sure that Infrastructure do keep a log file and there is nothing in there of any note; we did check this. However I am working remotely from the office today but will mail a query to the team.
I do not know where you are in the world but England is pretty paralysed by a snowfall which is almost laughable in Europe or America.
Madame Artois
January 6, 2010 at 7:13 am
Well simple fix (at least to start with) is to patch the server to the current service pack provided by Microsoft.
If that does not stop the error from occuring would be best to put a call in with Micrsoft. But in order to put a call in with Microsoft to get a hot fix they will ask you to be at the current service pack.
Shawn Melton
Twitter: @wsmelton
Blog: wsmelton.github.com
Github: wsmelton
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply