Running a Windows 2003 with SQL Server 2005 on, with around ~85-90 jobs which run once per hour (at different times), generating new sitemaps for each website hosted on the server, along with un-publishing pages.
The issue which I'm having with the server is that, the server seems to be running in three stages, the jobs run between 8am - 6pm each day, and the server is restarted around 2-3am every morning.
Once the jobs start in the morning, they will run successfully for around 90 minutes (9.30am), taking around 3-5 seconds to complete the job.
After 9.30, the jobs will start correctly, then, get stuck on executing (using 100% CPU).
If I manually stop the job, the server goes back to normal, but then the jobs will fail to execute at all, throwing the error below. (They were changed to run every 60 minutes, not every 15 a few months ago, but the names were never changed)
Step ID 1
Server [Server Name]
Job Name Execute Replicate File For [website] web
Step Name Vbscript for Replicate File every 15Minutes
Duration 00:00:00
Sql Severity 0
Sql Message ID 0
Operator Emailed
Operator Net sent
Operator Paged
Retries Attempted 0
Message
Executed as user: [Domain]\[User]. The step did not generate any output.
The step failed.
Information about the script that is running: It is a VBScript
Dim IEObj
Set IEObj=CreateObject("InternetExplorer.Application")
IEObj.Navigate "[weblink]/ReplicateFile.asp"
IEObj.visible=false
do Until IEObj.ReadyState=4
loop
IEObj.quit
Set IEObj=Nothing
#mellamokb - The script is down in the general settings as an ActiveX Script, not a T-SQL one, so I am unable to specify an output file for the errors.
Note: I didn't setup anything on this server or the CMS which it is replicating, and my knowledge of databases is fairly low.
My guess is that the page you are displaying in the browser, [weblink]/ReplicateFile.asp, is erroring out on at least one of sessions.
The code
do Until IEObj.ReadyState=4
loop
will cause significant CPU usage while it is running. And, more importantly, if the browser never gets to ReadyState 4, this code will continue to run forever. Have two of three of these stuck, and you will see 100% CPU usage on your server.
Related
we have jobs in sql agent runnig schedually. We know at least about one job (scheduled every day at three different times - morning, afternoon, night) which rarely (apx one per several months) fires/runs twice in same time (like a parallel). But it is scheduled only one time in same moment. Job runs CLR stored procedure which launch console application which process some getting data and recalculating
This behaviour causes problems for us.
Why?
How could it happend?
Where is problem?
But where is reason?
Thank you for all ideas.
(Of course, we should handle it and prevent this behaviour.)
I found error in job history according to time of job execution - error 6535.
This error appears twice for this job iteration. Firstly without addtional message, secondly with additional message "The step suceeded". When I looking for information about his error 6535 - i found that this error occurs on sql server 2005, but due to select ##version, the customer use sql server 2008 R2
I am executing a SQL Server Job that runs a set of SSIS packages. The run time for a full file set is about 16 hours.
I am running SQL Server 2016 in an Azure environment. The job the last two days has been finishing at 1 or 2 in the morning. When I come in the next morning my job execution window is saying the job failed but when I go in to view the job history it says everything thing in the job ran successfully. So I have no errors to go off of to try and figure this out except for these couples lines.
Is this truly an issue or is it more of just a bug? I'm lost on where to proceed.
EDIT: Here is the job history.
On a legacy SQL 2000 box that is awaiting upgrade
Does anyone have a script to kill / abort a job in SQL Agent 2000 if it over runs a set duration or overlaps with another agent job.
This is causing us a serious problem every few weeks a job overuns then locks the reindex job and that freezes our 24 / 7 server
One solution would be to add a step at the beginning of the job with which the long-running job overlaps which checks whether the long-running job is still running, and if it is issue an sp_stop_job command.
You can get the current execution status of a job using sp_help_job, but its output is not very easy to manipulate in a query.
Various methods of coercing the output of sp_help_job into a temp table in SQL 2000 are discussed here - alternatively you can query msdb.sysjobhistory to get the execution status information.
Is it possible to make Job Schedule, which will occur every less than 10 seconds?
Because Sql server doesn't allow that.
Schedule type is "Recurring" and Occurs "Daily".
Select occurs Daily and run every 10 seconds. Although keep in mind if your job takes longer than the time specified to run, the agent won't invoke it again until the running task completes.
See comments below. The UI tool doesn't allow input for less than 10 seconds. In your case you could schedule two job tasks offset by some number of seconds. The issue then is that the jobs could overlap as they are distinct tasks as far as SQL Agent knows.
I tried do something similar (SQL Server job with prcise timing), but the only reliabile way I found was custom windows service execution SQL statements.
If you schedule a SQL Server job to run every X number of minutes, and it does not finish the previous call before the # of minutes is up, will it skip the run since it is already running, or will it run two instances of the job doing the same steps?
The SQL Server agent checks whether the job is already running before starting a new iteration. If you have long running job and its schedule comes up, it would be skipped until the next interval.
You can try this for yourself. If you try to start a job that's already running, you will get an error to that effect.
I'm pretty sure it will skip it if it is running.
Which version of SQL Server are you using? This seems like a pretty easy thing to test. Set up a job with a WAITFOR in it that inserts a single row into a table and set up the job to run twice in quick succession (shorter than the WAITFOR DELAY).
When running such a test in SQL Server 2005 it skipped the run that was overlapped.