Posted by Many of the posts I write focus on either how to do or approach something or a story about something I did. Instead of the How, this post focuses on the What.
If you’re new to Db2, you may not even be aware of what you should do to support a Db2 environment in a proactive manner. And by “New to Db2”, I also include those with up to three years of Db2-only experience who are self-taught. It’s easy to teach yourself technology today and learn by doing, but this can leave gaps in the things you’ve never been asked to do or problems that you haven’t happened to run into yet. Heck, almost 18 years in, and there are still areas I know I’m weak in and couldn’t do without study and practice. (Replication, clustering, and partitioning, I’m looking at you!)
Working on the Database
The question I’m attempting to answer in this post is what you should be doing for each database you support and how often you should be doing that thing. Now note that these tasks do not include the things that people explicitly ask you to do – for example when developers ask for things. These are the minimums you should be doing outside of work that is actually requested of you.
| Task | Frequency (Minimum) | Details on How |
| Address HIPER or security APARs that may apply | Push – get notifications from IBM to address immediately | Sign up for notifications |
| Review diagnostic log for errors | Weekly (preferably more often via parsing and your monitoring) | DB2 Error Logging |
| Backup database and manage transaction log files | Per your recovery policy – no less than weekly in most cases | DB2 Basics: Backups of Data and Configuration Managing db2 transaction log files |
| Backup configuration and syntax to re-create the database | Per your recovery policy – often monthly or weekly | DB2 Basics: Backups of Data and Configuration |
| Perform runstats on all tables that change | Weekly or Daily | Runstats – What and Why Ember’s Best Practices for Runstats and Reorgs |
| Perform reorgchk, and reorg all tables that need it | Monthly or Weekly | DB2 Basics: What is a Reorg? Ember’s Best Practices for Runstats and Reorgs |
| Identify problem SQL and analyze/address it | Monthly or Weekly | Identifying Problem SQL DB2 Administrative SQL Cookbook: Finding Problem SQL in the Package Cache SQL Analysis Overview |
| Parse and understand locking event monitor output (when there are no overt locking problems) | Monthly | Analyzing Deadlocks – the new way |
| Archive and prune the Db2 diagnostic log | Monthly | Use db2diag -A |
| Review KPIs and look for tuning opportunities, even if there are no reported performance problems | Quarterly | DB2 Basics: MONREPORT |
| Read up on new mod packs, fix packs, and versions of Db2 and decide if you can or should update/upgrade | Quarterly | Db2 Basics: Patching Db2 |
| Test recovery strategy | Annually or Quarterly | How to Determine your Backup/Recovery Strategy |
| Test high availability and disaster recovery plans | Annually or Quarterly | Architecting High Availability and Disaster Recovery Solutions with Db2 |
| Perform health check of database and server, including all aspects of architecture, design, stability, security, and performance | Annually or Quarterly | |
| Review or create detailed environment documentation including architectural diagram | Annually or Quarterly | |
| Review or establish recovery objectives | Annually | How to determine your backup/recovery strategy |
| Review high availability and disaster recovery plans | Annually | High Availability Options for Db2 LUW |
| Establish or review database and server monitoring | Annually | Ember’s Take on Monitoring DB2 LUW |
The Rest
While the above establishes a minimum baseline, there are a thousand other partially related things you’ll be called upon to do and that you should be learning the details of. A health check can lead to a year’s worth of suggestions on how to make things better. In-house developers often need education and details on working with a Db2 database. Heck, even application vendors often need that. It is critical to always be learning and educating yourself on Db2.
The truth is that no one can tell you everything you need to do or know to perform a job as a Db2 DBA. This is because every DBA does a different job. We make the role our own through what we enjoy, what we see the need for, and what pain we experience.
If you’re new to Db2, strive to focus your learning time each month or week on an area and learn it in-depth, including experimenting with it in a sandbox environment. Find a community that works for you, whether that is reddit, stack overflow, twitter,YouTube or a local or national users group.
What a fantastic article! So concise, yet helpful to all levels of DBAs. Thank you very much.
nice blog mom
A great piece of information. You are really amazing. Thank you so much.