IBM has published a document with some additional best practices for configuring TSAMP, so I thought I would add an article to my TSA series covering these settings.
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.
Why Should a Database be Highly Available?
It is significantly easier to implement high availability at other levels than it is at the database level. Often the database server is one of the more powerful servers in an environment, and without some fancy footwork there can be only one live copy of data. Ignoring high availability at the database level due to expense can be a bankruptcy-inducing choice for an organization. Just imagine what would happen if your databases suddenly did not exist. Not only would your company be unable to perform daily business, but the data lost could actually drive a company out of business.
HADR does an awesome job of replicating all logged operations to 1-3 standby databases. It is remarkably simple to use and pretty resilient. More than once I’ve started talking to a client about PureScale only to discover their actual high availability and/or disaster recovery needs can easily be met by a 4-server HADR implementation. Sometimes even by a two-server implementation.
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.
It’s that magical time of year again.
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).
Mike guest blogged for me about three and four server HADR clusters before, but I want to blog about it from the perspective of adding a third server into an existing two-server cluster. Please go visit Mike’s article for a more general view of multi-standby HADR.
Like any software, DB2 requires frequent patching. A database should be one of the most secure parts of any enterprise, and keeping it secure means keeping up with the fixes that are delivered in fix packs.
As always, when I feel pain, I share the knowledge that pain gained me with my blog readers. Man, that was a painful fixpack. I was upgrading an AIX HADR pair from 10.5 fixpack 3 to 10.5 fixpack 5. My experience has generally been that TSA is painful when patching DB2.
When the client considers high availability and disaster recovery, they often do not know what they are talking about. Many times the client may be dropping buzzwords like “five nines”. To them this is the definition of disaster recovery. In other cases, they are thinking of a worst-case scenario where a whole data center falls off the face of the earth and they need high availability.