December 4, 2008 at 5:51 pm
I just read a good suggestion from Cath Trimble and it's got me thinking...
Send a report to developers/app owners that details various aspects of their database "health".
Some developers turn a blind eye to the back end - sometimes due to the fact that they don't have the rights or the knowledge to dig into this stuff. We can keep them more informed and also keep them assured that their data is being backed up and looked after.
I'm curious about what people do in this area and any ideas you might have. What are the most critical areas in your opinion to keep the database running?
Reporting services can do report bursting/breakouts (sending sections of a report to certain recipients), so I'm planning on hooking into our configuration management database to pull info about database owners. The report would run daily and perhaps a modified version would run weekly with other info. Various stats could translate into a rating/grade/color scheme for the database to give a heads up when things are heading south (maybe put that in the subject for failed jobs).
Security:
List of dbo/power users
List of new users
Modifications:
New objects (we have ddl triggers on all dbs pushing to an audit table)
Ops:
Failed jobs (we get pages on critical jobs)
Last backups (warm fuzzy feelings!)
Last time a restore was tested( planning on implementing periodic tests - i have an ssis package to automate this. )
Size/growth of db and log
Last time maintenance was performed (reorg, rebuild, stats update)
Performance:
Worst queries
User connection counts
The more I type, the more I think of - how about you? What's the most critical - a.k.a. phase I of my project? 🙂
December 4, 2008 at 6:00 pm
I tried sending server health reports to developers, once. The response was, "I already get enough email... would you stop sending these to me?" 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply