We have BizTalk 2016 running on SQL Server 2016 AlwaysOn.
The SQL Server Agent Job MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb is doing its thing but after some hours it fails. Sometimes 10 hours sometimes 90 hours or anything in between. I know, the job is designed to run forever and in a case of an error restarts itself within a minute. But I would like to know the actual error message for this failed job. The job history is not helpful because the job log entry is truncated.
A failover is not happening. The question is: WHY is this job failing and ultimately: how do I stop it from doing that?
I have set-up the extended monitoring of the failing step and it revealed, that the job failed because of a deadlock and it was chosen as the deadlock victim. So now is the question, why is there a deadlock? Is MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDbknown for deadlock issues?
Check the documentation at Description of the SQL Server Agent Jobs in BizTalk Server, it says:
Important At first, the MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb job status icon displays a status of Success. However, there will be no corresponding success entry in the job history. If one of the jobs in the MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb job fails, a failure entry appears in the job history and the status icon displays a status of Failure. The job will always display a status of Failure after the first failure. To verify that the other BizTalk Server SQL Server Agent jobs run correctly, check the status of the other BizTalk Server SQL Server Agent jobs.
Hope this answer your question.
Related
I've not seen this scenario in all my web searches.
We have several SQL Server Agent jobs that get kicked off by users through various applications.
Quite randomly, these executions will fail. When log in and manually kick the jobs off i'm immediately presented with 'SQL Agent not started' errors.
When I check the agent it says it's running. If I force a restart the problem is fixed.
The random nature of the issue causes testing issues.
The agent is already set up to 'restart if stopped unexpectedly' and 'restart with delay'.
A recent disaster recovery was performed and SQL Server Agent started successfully and declared itself 'running'. However once again it required a manual restart to actually work.
Is this a known issue or bug?
How can I mitigate against this when the agent says its running and all parameters are set correctly and meet the 'internet's' suggestions?
I have a database running on an azure vm with sql server. The db is in full recovery mode. The backup is configured through the web interface. Database and log backups have been working flawlessly for years. But recently the log backup was interrupted halfway through and the log backup process somehow got stuck. The following event has been logged every 5 minutes since then (reading log with managed_backup.sp_get_backup_diagnostics):
[SSMBackup2WAAdminXevent] Database Name = DB, Database ID = 777, Stage =
VerifyJobOutcome, Error Code = 0, Error Message = Warning, Additional Info = A
progress update hasn't been received from SQL Server in more than 30 minutes
for log backup. SSMBackup2WA will continue to wait.
SSMBackup2WA seem to be stuck waiting for a progress update never being received. This has resulted in no log backups being taken. The database backup have continued running without problem.
I have trouble finding the job/task used by SSMBackup2WA. I understand its not in the usual batch of SQL Server Agent jobs but somehow hidden.
My idea is to somehow cancel the existing job that is stuck in waiting loop but I have not figured out how.
I have tried to "reset" the backup process by turning off the backup and then turning it on again but that did not help.
I have no possibility to restart the sql server (and I don't know if that would help).
So since no one seemed to have an answer to this one I resorted to restarting the SQL-server. And after the restart the transaction log backup started working again!
What is interesting is the following log that appeared in the application event log during the restart. It does seem like there was a thread hanging indefinitely, waiting for an status update that never arrived. The restart seems to have taken care of it by killing this status thread and not restarting it again in the erroneous state it had ended up in.
Log Name: Application
Source: Microsoft SQL Server Automated Backup
Date: 1/15/2022 11:16:20 AM
Event ID: 57007
Task Category: None
Level: Warning
Keywords: Classic
User: N/A
Computer: wn-sqlserver1
Description:
[Warning] AutomatedBackupStatusMonitorError:
System.Exception:
Error in auto-backup status monitor thread --->
Microsoft.SqlServer.Management.IaaSAgentSqlQuery.Contract.IaaSAgentSqlQueryException:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The server was not
found or was not accessible. Verify that the instance name
is correct and that SQL Server is configured to allow remote
connections. (provider: Named Pipes Provider, error: 40 - Could
not open a connection to SQL Server) --->
I am using SQL Server 2016, and have some Jobs running in the SQL Server Agent. Today I found one of the job is taking too long (10hours!) to run and is still processing, so I try to stop that. I tried right-click and stop the job, it showed a success message. However, when I go to the Job Activity Monitor, it is showing that the job is still running! I also tried the following code:
USE [msdb]
GO
EXEC dbo.sp_stop_job N'Process Reserving MI (except problematic tables)'
GO
It also says the job stopped successfully. But again when I go to the Job Activity Monitor, it is showing that the job is still running!
Can any one please help?
At the end I have to ask the server team to reboot the server in order to solve this problem
I have a report running against a Data Driven subscription in SSRS. The subscription runs a report and produces PDFs - about 1000 of them. The process takes about 2 minutes to complete.
I have been kicking this off manually using the following SQL:
EXEC msdb.dbo.sp_start_job #job_name = '<job_name>'
This works, but what I would like to know is when the job has finished. According to what I have read so far, I should be able to run:
exec msdb.dbo.sp_help_job
This lists my job, but it always has a status of 4 (Idle), even while I can see that reports are being produced.
How can I tell when the job has completed and all my reports have been produced?
MSDB shouldn't contain informtaion on the reporting server. The reporting server is seperate from Sql Server Management Server and will only tell you if the job ran or not not what happened in the job. If you have access to the DB I don't know how you have it set up but I have a subscriptions table that I can check with email sent and when it was sent. IF you don't have that you can go onto the reportserver web site and check the subscription and check the status and it should have a date of when it was last sent.
The only way you can access the information in Sql Server Management Studio is by queryng the DB and its tables assuming it is setup correctly.
Since 3 days ago, an SQL Server 2005 Agent job that's used to retrieve data from an odbc data source (Microsoft XAL) fails with the following error:
"Executed as user: NT AUTHORITY\SYSTEM. The step was cancelled (stopped) as the result of a stop job request.".
As far as I can tell, we didn't change anything in the configuration of the job in the last few days. Any ideas what settings I should check to find the cause of the problem? Or had somebody had similar problems?
Thanks in advance!
I've found the solution. We had a stored procedure that was waiting via WAITFOR DELAY if another stored procedure was still running. And somehow, our database got inconsistent, so the stored procedure thought the other procedure was running all the time and waited and waited and waited...
At some point in the night, when the server got restarted because of a backup job, the agent worte this "The step was cancelled (stopped) as the result of a stop job request." into the job log.
Maybe this will help someone in the future who has the same problem.