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.
Related
I'm trying to execute a SQL Server stored procedure through Python Pyodbc and to get the selection results printed out into .csv files. But this procedure is currently being used in other daily tasks so I'm worried that if my executing the procedure in python will interrupt the daily scheduled job process in SQL Server Agent. In the procedure, it creates several temporary tables #temp_a, #temp_b, and #temp_c. I'm wondering if these temp tables will break the scheduled jobs that include this procedure since there might be other procedures that will be creating temp table names using the same name such as #temp_a or #temp_b. The temp tables are created inside the procedure but with no delete query written. I could have tested this myself but the database I'm working on right now is just so fragile that I was told not to create tests. Thanks!
Yes
The temp-Tables will be created per Session.
I got the procedure execute by different Sessions on the same time there will be the same count of the temp-tables as sessions executed.
This temp-tables have each a different name:
#V_...._000000003EB1
#V_...._000000003EB8
The example above are the temp-Tables created by the same Procedure executed two times by different sessions at the same time.
So your scenario couldn't happen
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 have a SSIS package which contains 3 different Execute SQL tasks which are basically data stages, each stage is a stored procedure which is wrapped in a serialized transaction. I have wrapped all 3 into a sequence container, but im not sure whether the Transactions properties of the container would affect the fact that there are already transaction stored procedures in the Execute SQL Tasks. The default properties on the sequence container is:
TransactionOption: Supported
IsolationLevel: Serializable
Also would these settings cause a deadlock?
Thanks
In my stored procedure there are 8 queries for 8 tables.Each query has joins and sub queries. I am passing parameters & stored procedure name from
front end(designed in asp.net 3.5)
can we execute that 8 queries at the same time i.e. parallel execution so that I can minimize stored procedure execution time?
Regards,
N.SRIRAM
The stored procedure runs each each query within it sequentially. If you want to run more than one at once, you'll have to create threads in your asp.net application and run each query in it's own thread. However, due to locking and processor constraints, this may not necessarily run faster.
Can't find any answers on the net, has anyone tried this?
My stored proc processes deletion of tokens found across multiple tables and it is set to run for a specified number of "cpu service units" by using the ASUTIME LIMIT integer stored proc definition/characteristic. When this limit is met, will the stored proc commit or rollback the statements executed for the current token?
Thanks.
thanks.. anyway, a co worker of mine says that:
"With ASUTIME, we are controlling the number of CPU units that the stored procedure will use in its lifetime. If the stored procedure will use more service units than is allowed, the stored procedure will cancel. This means that as long as the app stays within its bounds, the SP will go on.
It can happen that another application, like a report run, will be kicked off while the stored procedure is running. There is no guarantee that the SP will stop at this point, or any point thereafter, because so long as both apps stay within their allowed range, the SP will not terminate. This may not be the intended behavior - most SPs of this nature are run on off days (i.e. Sunday) so that they will not interfere or competewith higher priority jobs during the regular day. In short, they are meant to end, and not to co-run with other jobs.
ASUTIME is designed for runaway stored procedures, not as a tight control on looping within a procedure. WLM priorities and service goals should used be for this, not ASUTIME.
There may not be significant savings with using ASUTIME, since the stored procedure would also have to check against system resources and the RLST tables."
Posting because it might be helpful to someone else.