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:
In addition, I also automate/script:
- Clean up of the diag log, notify log, and the diag path
- Retention of transaction logs
- Periodic snapshots writing data to disk or to tables
- 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)
- Tracking table sizes over time
- Looking for unexpected database changes
- Monitoring – instance up, database connect, HADR OK, log file saturation, etc – through the tool my company uses for enterprise monitoring
- Data pruning – deleting obsolete data on a daily basis
- 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?
Ember is always curious and thrives on change. She has built internationally recognized expertise in IBM Db2, and is now pivoting to focus on learning MySQL. Ember shares both posts about her core skill set and her journey learning MySQL. Ember lives in Denver and work from home