Database servers these days sometimes have a profusion of IP Addresses. IP V4, V6, management networks, and Virtual IP addresses all add to the ways applications connect in to a database server. I ran into an issue recently where I really needed to know what IP address was being used by an application, and thought I would share what I learned.
Some of my clients, instead of engaging me for day-to-day support, engage me for expert assistance only when it all really hits the fan. This issue occurred for one of those clients, who had other support performing the HADR failovers while the Linux kernel was upgraded. The version of RedHat did not change, but the kernel did.
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.
Sometimes configuration needs to be kept in sync between two or more Db2 systems. There are a variety of reasons – sometimes this is for keeping two HADR servers in sync, and other times it may be for keeping a dev, QA, or Staging system in sync with production. In any case, having an idea of what needs to be in sync and what doesn’t can be complicated. The focus here is at the system level. This post does not dig into comparison of logical objects in the database such as tables and indexes.
Corrected on 9/8/2017 to reflect correct syntax to eliminate just the one table.
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.
It’s that magical time of year again.
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.
This is something DB2 DBAs may need to do as a part of setting up TSAMP. Nearly every server I’ve done before has had a subnet mask of 255.255.255.0, but I ran into a server recently that wasn’t, and thought I would share how I figured out what it should be (alone, in the middle of the night, during an upgrade).