What do you script?

Posted by

This is a quick follow up to my last post – Scripting/Automation for DBAs. In addition to what that post covered, it’s important to think about what you script/automate and what you don’t. My picks for what absolutely must be automated include:

  1. Backups
  2. Reorgs
  3. Runstats
In addition, I also automate/script:
  1. Clean up of the diag log, notify log, and the diag path
  2. Retention of transaction logs
  3. Periodic snapshots writing data to disk or to tables
  4. A script to check maintenance basics and catch failures of other scripts (I check reorgs within 30 days, runstats within 7 days, and backups within 7 days)
  5. Tracking table sizes over time
  6. Looking for unexpected database changes
  7. Monitoring – instance up, database connect, HADR OK, log file saturation, etc – through the tool my company uses for enterprise monitoring
  8. Data pruning – deleting obsolete data on a daily basis
  9. Configuration gathering – getting basic configuration information written out for disaster recovery
I have some data refreshes that are also scripted, though not scheduled – the developers can execute them when desired. I’ve never been a fan of scripting actual database restores that are used for data refreshes between environments.
What do you script and what do you not script and why?

Lead Database Administrator
Ember is always curious and thrives on change. Working in IT provides a lot of that change, but after 18 years developing a top-level expertise on Db2 for mid-range servers and more than 7 years blogging about it, Ember is hungry for new challenges and looks to expand her skill set to the Data Engineering role for Data Science. With in-depth SQL and RDBMS knowledge, Ember shares both posts about her core skill set and her journey into Data Science. Ember lives in Denver and work from home

One comment

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.