We have got a SQL job that comprises of several steps. Currently, the On Failure property is set to Quit the job reporting failure which only notifies the relevant parties of the failed step. Is it possible to execute a SQL script if the step fails (for further processing etc.) as well as sending the notification? We are using SSMS 2014.
You can create another step that will be executed each time another step fails.
In this step, simply put a Script Transact-SQL (T-SQL) in it.
Then on this new step, weither it fails or not : Quit the job reporting failure
Make sure no step falls in this step from success.
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.
I have created multiple SQL DB Maintenance scripts which I am required to run in a defined order. I have 2 scripts. I want to run the 2nd script, only on successful execution of 1st script. The scripts contain queries that creates tables, stored procedures, SQL jobs etc.
Please suggest an optimal way of achieving this. I am using MS SQL Server 2012.
I am trying to implement it without using an SQL job.
I'm sure I'm stating the obvious, and it's probably because I'm not fully understand what you meant by "executed successfully", but if you meant no SQL error while running:
The optimal way to achieve it is to create a job for your scripts, then create two steps - one for the first script and for the second. Once both steps are there, you go to the advanced options of step 1 and set it up to your needs.
Screenshot
Can you create a SQL Server Agent Job? You could just set the steps to be Step 1: Run first script, Step 2: run second script. In the agent job setup you can decide what to when step 1 fails. Just have it not run step 2. You can also set it up to email you, skip to another step, run some other code etc... If anything the first code did failed with any error message, your second script would not run. -- If you really needed to avoid a job, you could add some if exists statements to your second script, but that will get very messy very fast
If the two scripts are in different files
Add a statement which would log into a table the completion and date .Change second script to read this first and exit,if not success
if both are in same file
ensure they are in a transaction and read ##trancount at the start of second script and exit ,if less than 1
SQL Server 2005’s job scheduling subsystem, SQL Server Agent, maintains a set of log files with warning and error messages about the jobs it has run, written to the %ProgramFiles%\Microsoft SQL Server\MSSQL.1\MSSQL\LOG directory. SQL Server will maintain up to nine SQL Server Agent error log files. The current log file is named SQLAGENT .OUT, whereas archived files are numbered sequentially. You can view SQL Server Agent logs by using SQL Server Management Studio.
Is it possible to log custom messages from your SQL Server Agent job in the job history messages?
If not what's the best way to go about doing such a thing?
For T-SQL job steps, you can use the print statement. For CmdExec steps, use Console.Writeline in your executable. If there is a lot of output, then by default SQL Agent will not keep all of, and will only keep a certain number of characters. To have it keep all output for a step, you go to the step properties, Advanced, and check the "Include step output in history" checkbox.
I haven't done it for a while, but I believe text generated by a PRINT statements in the code executed by the job will end up in the history table. If that doesn't work, RAISERROR with severity less than 11 should do it. (11 and up definitely will, but then jobs are marked as having failed.)
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.