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.
- Basic database maintenance is scheduled. This includes:
- 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
- Standard starting settings are in place. This includes:
- DB2 Registry
- DBM Configuration
- DB Configuration
- 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
- 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
- Failover tests for all types of HA and DR solutions used
- 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
- Quick physical storage review – is any filesystem getting full as we load data in?
- 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.
- Licensing – did I remember to apply a license file to all servers?
- 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.
Remarkable things here. I am very happy to look your post.
Thanks a lot and I’m having a look ahead to contact you. Will you please drop me a e-mail?