I like the job manager with the ability to view and drag jobs in the calander view.

What would even be nicer would be to see the average job duration and expand the the job on the calendar with the average duration so that I can scoot another job right under it to start after the fist one completes. This would be a great way to manage the job times.

Currently, I have to look at the last day and see how long the job takes and guess where to start my next job.

This feature would be slick if I can see on the calendar a graphical representation of job duration that fills the 15 min slot and allow me to scoot this other job right under it.

You already expand the completed jobs but the issue is, I can not move them but if you estimated the job duration before it runs to give us a graphical idea how long the job takes it would allow use to manage the jobs easier.

In the job manager, lets say today before any jobs run. If you have lets say, 15 database backups listed at 7:00PM

All of these jobs will be graphically displayed side by side- and not spaning the time frame 'Job Duration" the job ran like the prior day after the job ran.

Now lets say I want to rearrange these jobs to make them run sequntially instead of all kicking off at 7:00PM.

If I could see the job graphiclly like on the day after the job run, I could re arrange the jobs and moving them around one right after the other. So instead of the 7:00PM jobs all on the 7:00PM time line ,

The 1st job would span 7:00PM - Average duration - 7:10 and then I could move the 2 backup under the first then this job is 7:10 - 7:20 and so on.

The average run time would be a good guide graphically to span the job “graphically” to represent about how long the job will take.

This would just save a lot of time moving many jobs around on the calendar.

Plus this would be the same way the SQL Sentry manages jobs.

This does not have anything to do with job steps and I do not understand the idea of a job wrapper.

We sometime have 15-20 db on a server and we script out the backup jobs and we use the average job duration " if exists" to set the start time of the next job bases on the average job duration of the job before it.

I can try to do some screen shot, but what I asking is make the future jobs or the jobs that have not ran look graphically the same as the jobs that already ran looks like now now on the calendar. It would even be fine to use the last duration time to expand the un ran job graphically on the calendar.

“if you don’t want a job to start until the first job finishes, why don’t you
just create a wrapper job that calls one, then the other?”

This would seem like a lot of work when you are managing 100’s of backup jobs that get created.

I am assuming you are talking about creating a stored procedure wrapper or a SSIS wrapper to handle the jobs. Which it may be good but 50 server and 100 of back up jobs that chage offten may be easier moving them aouund on the calendar.

if the problem you are having is manually scheduling backups so performance
doesn’t suffer then a better solution would be to use a maintenance plan. You
can define those to backup all databases on the instance with only a few clicks.
You can also schedule log backups the same way and it will only pick up
databases in full recovery mode. Maintenance plans back up the databases
serially so they don’t impact performance. I do this on my systems and it works
flawlessly.

But to answer your question, what I was proposing was to create job steps in
your backup job that on completion automatically move to the next step. Each
step would be a backup of a specific database. Notice I said on completion
rather than on success of the step. But this requires a lot of work to set up if
you have 100’s of databases and only does what the maintenance plan would do
with about 5 minutes of setup.

Not that I disagree with having a GUI method of scheduling jobs, but absent
that, maintenance plans are your answer.

Maintanance plans work good in ideal environments but when you are doing multiple instance active \ active clusters and the backup locations are different based on the database, it becomes a night mare to manage.

We have some database backups that get replicated and some don’t, some get more snapshots, some less all bases on a tier model and using SAN storage on the backend.

Plus we run into many old vender db that are still in SQL 7 compatability mode that breaks the maintanance plan.

We have a stored procedure that creates the backup device in their teir location and created the jobs. The stored proc just takes a sec to run but it would be a drean to open the calander view and drag some of the jobs around to teak the times.

I liked your idea about exporting a job list to excel too. I usually end up running scripts to gather all my jobs into a reportable database. That way I can sort and filter by server, time, and so on. I moved that into a SSIS job to build a datawarehouse of server info, including many items like info from jobs, from average durations to failures and such. It’s helped alot in managing many jobs.

Wait! SQL Agent Job - This is the second in at least a two part series dealing
with SQL Agent Jobs. In this post, we are creating a new procedure to be used
instead of the system procedure sp_start_job when you need to wait for a SQL
Agent Job prior to moving on to the next step in a program. … (more)