danielfountain (4/29/2013)
gfish (4/29/2013)
I am not just speaking hypothetically. We added an almost identical process to our system years ago and we are now spending a lot of time getting rid of it because it is a constant headache. The job queue table backs up regularly on a busy system, and even when it is not backed up it introduces load that competes with user interactive processes. The idea of "do it later" doesn't work when the system is so busy processing interactive requests from users that there is no "later" during working hours.What have you replaced it with?
I am looking to use it to run a load of stored procs first thing in the morning running parallel (the way i would code it also means that some rely on others). Currently they run concurrently but this isnt needed for much process.
Dan
We replaced it by simply looking at the real need for what was being done in the background jobs and deciding that it probably didn't need to be done at all. Without boring you with a lot of details, let's just say that we were spending a lot of time generating extremely accurate information when a simple approximation would have been sufficient. I know that this is not always possible and you may have looked at this already. I was just cautioning against over-use of this method as a way to avoid fixing bad processes.
For what you are doing it's probably fine, as long as "first thing in the morning" means before working hours. What we did (and what I was cautioning against) caused queued jobs to be added throughout the day, primarily by triggers. Users performing common tasks were unknowingly adding to the pile of queued jobs even though the system seemed to respond quickly to their request.
I would say that as long as the process is initiated by some sort of scheduled or manual administrative action and there is a reasonable certainty that all of the jobs will be completed before they start competing with users for server time then you are probably OK.