Edited 12/13/2017 to correct image and details about the database heap.
While I have tuned backup performance before, it has often been through physical database changes (spreading tables across more table spaces) that I achieve my greatest results. This post is not about backup performance tuning, but about solving a specific backup duration mystery.
Some of the more complicated work a DBA does is often analyzing a query. Whether it is proactive or in response to a performance problem, there are so many factors that go into query performance. Even when looking at a query that has a performance problem, there is only occasionally a single, obvious cause for all of the problems.
I think that one of my least favorite phrases is “Nothing else changed!” More common than a performance problem that simply slowly creeps up with performance getting worse and worse over time is the sudden performance problem. Many times, sudden database performance problems can be mapped back to a specific change at some level.
I have some very specific perspectives on monitoring DB2. In addition to regular consulting in my day job, we also provide full-service virtual DBA services, including monitoring. The monitoring we choose to do is very much under my control, and I’m constantly working on enhancements. I thought I’d blog on what I like to monitor and alert on without going too deeply into how these things can be monitored. There are excellent tools on the market, and excellent ways of scripting your own monitoring.
dsmtop is a long-awaited refresh of the wildly popular db2top. Like db2top, dsmtop is a free tool, included with DB2. It is in the base DB2 install starting with 11.1, and can be installed on DB2 10.1 or 10.5.
I am consistently shocked and appalled at how few clients actually do load testing. Many pay it lip service, but few actually engage in real, meaningful performance and load testing. I understand that load testing of an application can be difficult and expensive. It is not something that every developer has as a part of their toolkit. But the most successful go-lives and holiday seasons I’ve seen high-volume e-commerce sites endure are the ones that went through at least some load testing.
A number of new clients I’ve worked with lately have had minor or major runstats or reorg issues. I have tons of advice on runstats and reorgs across many blog entries, but I don’t have one place where all that advice is brought together. Here is that article. The truth is that reorgs and runstats are complicated, and most DBAs get them wrong or disagree on them in some way. There is no one right way, but there are a vast variety of ways to get it wrong.
The package cache is just one memory area that DB2 offers to tune memory usage for a DB2 database. This article is a deep dive into this memory area.
My background comes largely from the physical DBA world, though I’ve gained logical DBA skills over the years. Any reasonably mature IT organization will have a DBA at some level or another review SQL and DDL before it is implemented in production.
Isolation levels are such a critical concept to maximizing concurrency for transaction processing databases where ACID is so critical.