I have two jobs at same time Let say a and b....
I need to run the jobs in a sequence
first =-----a
second=----b
both a and b scheduling times should be different so that I cant use them in single job
when I schedule them they are running parallel I required a sequence of execution.
One job every 30 minutes to do Task A starting 00:15
Other job every 30 minute do Tasks A and then B staring 00:00
If the actual requirement is that two separate activities should not take place at the same time, but that they have completely different scheduling requirements, you may be able to achieve this using an application lock.
This would require that all activity for each job happens within a single stored procedure (or, in some other way, is forced to use a single database session).
At the start of each activity, the code would call sp_getapplock, something like:
EXEC sp_getapplock N'D1852F12-F213-4BD3-A87C-10FB56506EF8',
N'Exclusive',
N'Session'
(Ideally, the lock is released afterwards using sp_releaseapplock)
Related
I have a SQL Agent job that runs on the 7th of each month on an hourly basis. I want to stop it from running further once it is successful.
For example, if the job is successful at 8:00 A.M, I dont want it to run any more untill the 7th of next month. Any scripts would be helpful for this.
I am working on trying to establish this rule through the use of MSDB sys.jobs and an idea that I have is to update the Enabled flag to a 0 once the run is complete. Once the 7th of next month hits, another job on the SQL Agent could go in an update the flag back to a 1 so it can be run. i
I suggest you create a new first job-step and, using the answer provided in the question sql-agent-job-last-run-status, you can check if the last execution succeeded.
You can then cancel the job from executing by using exec msdb.dbo.sp_stop_job
I use this method in an Availability group cluster (to check if SQL Agent is running on the primary for jobs the require it) and abort the job if not. It works well.
How about, create a table with a row for last successful run, populate it on a successful run.
Then first thing in the job, check that table, and if the last successful run is since the 7th, terminate.
Otherwise run the rest of the job.
The solution that I finally deployed was to add a step to the job that would disable it once all preceding steps succeeded. I added another job to the Agent that would go and enable this job on the 1st of each month so that they are ready to be executed. Just throwing this out so that someone else can benefit.
I've been experiencing a strange situation with a specific SELECT on SQL Server 2008 Standard.
I have a proc that executes a bunch of commands.
One of the last tasks is to insert the result of a select statement into a table. This proc is executed for each step of a job (with 20 steps) just changing one parameter, store code (the company has 20 stores).
This insert-select command normally executes in 2 minutes, but sometimes, it gets stuck with an SOS_SCHEDULER_YIELD lastwaittype and hangs forever... until I kill the process. After that, if I execute the same command, it executes in the normal 2 minutes.
I noticed that it doesn't matter if the CPU has 99% usage or 1%, or if there are other processes executing at the same time. I didn't find any pattern with these events. It just happens sometimes (almost every day with one or two steps).
Has anyone experienced this? I don't know what to do; I made a job to kill the process and execute it again if it hangs in SOS_SCHEDULER_YIELD for a long time, but I'd like to have a solution.
Thanks.
Breif:
I have five stored procedures and each of it have no dependencies. The identical stuff is that it pulling data from five different servers. We are just collating and feeding it to our server.
Question:
We have scheduled all these five in single job with 5 different steps. I want to execute it in parallel instead of sequential order.
Extra:
I can actually collate all five stored procs in to one if its possible to run it in parallel in sp level (if not possible in job level).
Thanks
The job steps are always executed in succession (hence 'steps').
To parallelize it, create five jobs with the same schedule.
There are several options. 2 of which are :
Create a SSIS job to run the 5 stored procedures in parallel.
Create 5 different SQL Server Agent jobs scheduled at the same time
It's also possible to create a main job and add steps to call child jobs (each calling it's own stored procedure) asynchronously as suggested at https://dba.stackexchange.com/questions/31104/calling-a-sql-server-job-within-another-job/31105#31105
However for more complicated flow it's better to use SSIS packages which are design to handle different workflows.
I'm going to make up some sql here. What I want is something like the following:
select ... for update priority 2; // Session 2
So when I run in another session
select ... for update priority 1; // Session 1
It immediately returns, and throws an error in session 2 (and hence does a rollback), and locks the row in session 1.
Then, whilst session 1 holds the lock, running the following in session 2.
select ... for update priority 2; // Session 2
Will wait until session 1 releases the lock.
How could I implement such a scheme, as the priority x is just something I've made up. I only need something that can do two priority levels.
Also, I'm happy to hide all my logic in PL/SQL procedures, I don't need this to work for generic SQL statements.
I'm using Oracle 10g if that makes any difference.
I'm not aware of a way to interrupt an atomic process in Oracle like you're suggesting. I think the only thing you could do would be to programmaticaly break down your larger processes into smaller ones and poll some type of sentinel table. So instead of doing a single update for 1 million rows perhaps you could write a proc that would update 1k, check a jobs table (or something similar) to see if there's a higher priority process running, and if a higher priority process is running, to pause its own execution through a wait loop. This is the only thing I can think that would keep your session alive during this process.
If you truly want to abort the progress of your currently running, lower priority thread and losing your session is acceptable, then I would suggest a jobs table again that registered the SQL that was being run and the session ID that it is run on. If you run a higher priority statement it should again check the jobs table and then issue a kill command to the low priority session (http://www.oracle-base.com/articles/misc/KillingOracleSessions.php) along with inserting a record into the jobs table to note the fact that it was killed. When a higher-priority process finishes it could check the jobs table to see if it was responsible for killing anything and if so, reissue it.
That's what resource manager was implemented for.
Let's say there's a SQL job that runs a stored procedure every one minute.
What happens, if it takes more than a minute? Does it start the procedure again (having 2 of them running in the same time) or it waits for the previous to finish?
A job can only have the status of running or not, a job that is already running won't start again.