Sql-server – Get Job step run for all jobs and job steps using TSQL

Each job step has a setting that allows it's output to be sent to a text file. This can be cumbersome because it's a text file located in the file system and not in a table and might be hard to get to. There is also an option to send the output of a job step to a table. You can query the table, but it's still clunky. (It is hard to write a query to pick the "X rows affected" string out of a blob of text, then pull the number out so that you can aggregate it, etc.)

I would recommend that you build a simple table in your user database (not in msdb or master) to keep that information. IMO, this is the best way to keep close track of the number of rows affected by each command, particularly if you want to be able to write simple queries to do historical reporting. This way, you can decide to log at the job step level, or if the step calls a stored procedure with multiple commands, you can log a audit record after each command. As always, @@ROWCOUNT is your friend.

IMO your vendor is actually on the right track.

An application layer job would require him to redo a lot of out-of-the-box SQL Agent features (eg. logic not to run a job that is already running, come up with a security and credentials store solution, integrate job results with error reporting and results tracking in SQL etc etc etc etc). And, most importantly, provide a backup/HA/DC solution for the scheduling. You do not want your disaster recovery story to be 'and after you finish recovering the standby server go create these 50 NT scheduler tasks'. So he is right in pushing back against using the system scheduler, it has nothing of the features and capabilities the Agent has.

He is even more so right in pushing back against triggers. Replacing a periodic job with a synchronous trigger increases request latency, increases cohesion and coupling (think schema changes...), increases downtime risk due to sync issues (trigger error->app error vs. job error->fix and retry later), dramatically increases deadlock problems (due to cross updates between tracked/trackee) and has many many more problems.

The easiest solution is indeed a Agent job, and msdb is by no means reserved for DBAs. A more fancy solution would be to use conversation timers and internal activation, which would have some advantages over Agent jobs, primarily due to containment (everything is inside the app DB, think mirroring failover scenarios), but I can totally understand if your vendor is reluctant to try out something that requires a very specific know-how. BTW I do hope you don't mean one job every 5 min per DB.

As for sysadmin permissions: the name of the game is code signing. You can give any permission to specific procedures, inspected and validated by you, by signing them with your private certificate.