New Builds – Do You Have a Checklist?

In case anyone is wondering why I’m currently just barely managing one post a week, the first and most obvious reason is preparation for Black Friday/Cyber Monday. Retail clients really stress their databases on these days, and a bit of proactive work can go a long way. The other reason is because somehow someone thought it would be a good idea to schedule a go-live for a rather large client for early/mid November. If I figure out who, I may have to complain. But it got me thinking about a checklist in my own head that I roll through before go-live, so I thought this week’s two-hour or less post would be on that.

Purpose of a go-live Checklist and Details

Many people who work on WebSphere Commerce just for their smallish employer may have only one go-live, or maybe 2-3 over 10 years to cover hardware and major software/site upgrades. The DBAs where I work handle about 6-12 per year, on top of the on-going support, builds, and training. After a while we’ve built up a list of things to double check. Most of these we do during a build process that is 2 months or longer and just check off when we’re getting close to go-live.

My list is very specifically DBA focused – there is plenty more for WebSphere Commerce or your specific application that it may not cover.

DBA e-commerce Checklist for go-live

The things I check are for WebSphere Commerce, but they should all apply to all e-commerce and even many DW/DSS databases.

1. Basic database maintenance is scheduled. This includes:
   • Backups
   • Reorgs, Runstats, Rbinds
   • Performance monitoring/Snapshots
   • Archiving of db2diag.log, instance.nfy, and cleaning up of DIAGPATH
   • Fail-safe maintenance check script to find silent maintenance failures
2. Standard starting settings are in place. This includes:
   • DB2 Registry
   • DBM Configuration
   • DB Configuration
3. Standard permissions scheme in place. This includes:
   • Revoking connect from PUBLIC
   • Giving the WebSphere Commerce database id DBADM and/or DATAACCESS
   • Creating groups for read-only and select/update/insert/delete access – per server if LDAP is used for database connections
4. Data pruning strategy in place. This is one step that can be done either pre-go-live or shortly after go-live. This includes:
   • Discussing detailed plan with dev team and client to identify any gaps or custom pruning areas needed
   • Sign off by dev team and Project Manager and Client on all retention guidelines
   • Coding of custom pruning areas if needed
   • Scheduling of pruning scripts in crontab
5. Failover tests for all types of HA and DR solutions used
6. Performance review. This includes:
   • Preferably load testing. Please, please, please let this client do full load testing.
   • Detailed review of physical database performance, and tweaking of parameters
   • SQL review – even if client doesn’t do load testing, look for problem SQL
7. Quick physical storage review – is any filesystem getting full as we load data in?
8. Code – may not have time to apply a DB2 FixPack, but I like to know if I’m going to need to in the near future. Sometimes a new one came out between the time I built the servers and the time we go live.
9. Licensing – did I remember to apply a license file to all servers?
10. db2look – I like to grab the structure of the objects via a db2look as it is during the pre-go-live code freeze

So what am I missing?

Most of this is in my head and the head of one of our other DBAs – between two of us, we handle most of the go-lives.