September 10, 2010 at 1:06 pm
It's not only important to monitor how long it takes something to run, it's often important to monitor when (if ever) it was run and who ran it.
That way, when it's time to upgrade an application, you know which 30% of the canned reports that were provided with the app can be dropped without anyone caring or noticing.
Plus, if you need to make a change to a program, you know who is using it, so you know who to ask. In a big company, knowing who to talk to can be a lifesaver.
September 10, 2010 at 1:27 pm
Because we were limited on space and had very tight SLA's, we built a table to track each step of a Daily process job with start and stop time. We also included record counts so we could compare apples to oranges. This table, with its history, proved very valuable as we constantly looked at which steps were taking the longest time and could devote resources to "tweak" it to squeeze out better times. We found that using this process we could make great strides at improving our delivery times. At one point we cut our execution time in half!
September 10, 2010 at 1:44 pm
As others have mentioned, yes we employ similar methodology. We have used tables for performance tracking. Some of that is done via alerts and some via perfmon counters and some via execution times.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply