in FMS system I need to automatically send the spool of a given background job let say job 'B'.
Job B is generated by a different background job, let say job 'A'. SM36 has the possibility to send only A job spool. Any suggestions?
Already tried SM36 tcode
Related
I have a table in my database with defined jobs. One of jobs attribute is status, which can be [waiting, in_progress, done]. To process jobs i have defined master-worker relation between two servers, they work in the following way:
master looks for the first record in database with status 'waiting' and triggers a worker server to process the job.
Triggered worker sets status on the job to 'in_progress' in one transaction and starts executing the job (in the meantime server is looking for next job with status 'waiting' and triggers another worker)
when the job is done worker sets status on the job to 'done'
This is the perfect case scenario, however it might happen that during job execution one of the workers dies. In this case job needs to be restarted, however master has no way of verifying if job was done other than checking its status in database ('done'). Therefore if worker dies, in database the job has still status 'in_progress' and server has no idea that worker died and that job needs to be restarted. (we can't get any feedback from worker, we can not ping it and we can not get information what job is he currently working on)
My idea to solve this problem would be:
After worker changed job's status to 'in_progress' (transaction committed) he would open a new transaction with lock on the particular job.
Master, while looking for jobs to start would look for both 'waiting' and 'in_progress' which are not locked
If worker dies, transaction would break, releasing the lock from job record in database and master would reprocess it.
now i'm looking for a way to verify it this would indeed work. Possibly with SQL sctipt in SQL developer (two instances), i would like this to work in the following way:
Instance 1:
open transaction and create a row lock on row_1
sleep for 5 min
release lock
Instance 2:
Open transaction and look for row matching criteria (row_1 and row_2 match criteria)
return selected row
then i would kill instance 1 to simulate worker death and run instance 2 again.
Please advise if my approach is correct
P.S
Also could you point me to some good explanation how can i create script form instance 1?
I want to implement below design.
Data is coming to source table - source_tab and I have 3 procedures to invoke for processing this available data. I am invoking each procedure manually now.
Is there any way to create a job which will be invoked as soon as new data is available in source_tab and start processing data by invoking those 3 procedures sequentially. Also, next job cycle should not trigger until current execution gets finished. This should behave in same as Java listeners do.
I don't want to use TRIGGERS.
I agree with the comment suggesting MSMQ. A dirty method, if you don't want to use triggers is to set up a Job on a low interval schedule.
It could check the table, if new data exists then go to first step to execute and flow from there, if not then do nothing.
How you determine what "new" data is that would depend on the data. Easy enough if you have dateadded column or something similar. If not then you may have to have an additional job step to write the table as it is now into a staging table, then compare this version to the next one on the next run through.
Like I said, not nice but an option.
Let's say that I have Equipment table and MaintenanceSchedule table in SQL database.
So I need to update the value of the Notification (bit) field in the Equipment table to be true if the Date field in the MaintenanceSchedule table approached.
So, how to track some data stored in the database and do some actions if a specific condition achieved ?
You should probably use a sql job to accomplish this. The problem is you want this process to be resilient in case of failure.
If you just set the flag after the Date field has approached, there are a couple potential bugs. For example, lets say the job doesn't run for some reason. If you run the job on the following day, can you be sure that the flag hasn't been properly set, then unset by the process which does the notification (or whatever processing is done). If you set it again, could it be duplicating work?
It would be best to create a MaintenanceHistory table which logs each time the Notification bit is set. Then you could build a stored procedure to run a job which checks if the Notification bit has been set for a particular Date, and if not, set the bit and log to the history table.
Then you could schedule this as a job which just executes this procedure and set to run at the desired frequency (hourly, daily, monthly, whatever). With this type of implementation, you can run the job as often as you like as it won't re-run for the same Date.
I would create a sql server job to check if the maintenance window aproaches and set the flag accordingly.
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)
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.