The role of the DBA in supporting WebSphere Commerce

I have generally been a bit disappointed on the information coming out of IBM on supporting Commerce databases. I also meet clients who don’t believe they need a dba or that they can hire someone out of college or with minimal database experience to fill such a role. In my opinion, any reasonably sized Commerce implementation needs a DBA, and unless that DBA has years of experience with DB2 (or Oracle as the case may be), and at least a year of experience supporting Commerce databases specifically, then it’s going to need to be a full-time dedicated DBA.

The basic message I get from IBM on database support – both in their intro readily available materials and in their selective customer experience and feedback sessions is that they see the DBA’s role as basically:

1. backup the database
2. do runstats and reorgs on the database
3. run dbclean on the database

Sure, that’s all I do, all day long. And my two other highly experienced colleagues together supporting over 100  databases.

As an example, here’s IBM’s tech-note (side-note, afterthought) on database support: http://www-01.ibm.com/support/docview.wss?uid=swg21224921

Heck, that one doesn’t even mention backups.

I could (and have) written over 50 pages of documentation on the items on that page alone. Not to mention thousands of lines of scripting. I’m hoping to do some nice details here on the blog on dbclean and data pruning, but that one section that they give so little mention to (basically they say “run dbclean”), I’ve put not less than 30 hours of effort into for every single client, not to mention the dozens if not hundreds of hours I and my colleagues have spent developing our overall strategy and scripts.

Supporting a WebSphere Commerce database is not rocket science. But it’s not 5th grade science either. Here’s a random list of things that I have some part in certainly monthly if not weekly:

1. Database-level backup and restore
   • Designing backup strategy based on resources and restore requirements
   • ad-hoc restores frequently needed during build, patching, etc
   • managing retention of backup images and transaction logs 
2. Data movement
   •  Between commerce databases on an ad-hoc basis
   • advising and assisting with data movement to/from other systems
   • Stagingcopies or restores in support of stagingprop
   • assisting in automation of regular data movement processes
3. Setting up and refining monitoring and alerting
4. Responding to alerts related to overall outages, database specific outages, filesystem utilization, and failures of database maintenance
5. Setting up and monitoring regular database maintenance including runstats, reorgs, and a few other niceties
6. DBCLEAN and data pruning
   • Designing initial implementation of data pruning including discussion of each of at least a dozen pruning areas with development and business people
   • Monitoring ongoing pruning, and correcting failures
   • Looking out for new pruning areas 
7. Stagingprop
   • Assisting with initial setup, possibly with use of stagingcopy
   • Heavy involvement in resolving errors which happen for every client at some time with some weeks spending 50% of my time on this 
   • Creating/dropping/altering stagingprop triggers as needed
8. Database object creation (working with developers on best practices and standards – sometimes writing the code myself)
   • Tables
   • Indexs
   • Stored procedures
   • Functions
   • Triggers
9. assisting in writing SQL (DML)
10. Executing SQL, particularly on Production environments where developers may not have access (per PCI standards!!)
11. Performance analysis, both proactive and reactive
    • Physical db2 parameters and resources – identifying problems and correcting them
    • Identifying and analyzing problem SQL and communicating about it and identifying and creating indexes to help resolve 
12. Implementing and supporting HADR and other High-Availability solutions
13. Managing security including:
    • Granting and revoking privileges and maintaining a consistent approach to doing so
    • Being aware of various items related to security and incorporating them into both new builds and existing databases
    • Assisting with DB related issues for PCI compliance 
14. Training new DBAs as well as non-DBAs on DB related topics
15. Resetting configadmin’s password
16. Assisting with Merchant Key Changes
17. Disaster recovery when needed from a wide variety of disaster situations
18. On an ad-hoc basis communicating with whoever asks on a  variety of these topics
19. Architecting strategy for all areas of database support

Whew. That’s  a mash-up of “System” or “Physical” DBA tasks and “Logical” or “Development” dba tasks – which some of the larger companies keep separate. I actually like to do them both so I really own MY DB2 databases and know them as well as possible.

The point is that there is a significant amount of database specific work in supporting a WebSphere Commerce implementation, and an experienced DBA is nice with a fast-learning DBA being a minimum.

I started my career with 7 years of “Physical” DB2 DBA work(the last year or two of that was mostly Commerce-specific), and am completing my 3rd playing a mixed role for Commerce databases specifically (with ESB, Portal and a few other misc databases thrown in for good measure). And now an interesting twist – I’m starting to learn Oracle too. So I’ll probably do some posts about that as well.

I truly love how there’s always something new to learn