What you Need to Do to Support a Db2 Environment

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.