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.
You may have seen some people posting IBM badges (through Acclaim) that they’ve earned. These are now conferred along with some IBM Certifications, but there are more that you can earn.
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.
My favorite weeks of the year are IDUG conferences. I was lucky enough to go to my first European IDUG last year, and I am looking forward to IDUG in Lisbon this year!
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.
What is Temp Space in Db2?
Db2 needs some temporary space on disk to perform some actions. Commonly we think of these actions as primarily sort and join operations. These are operations where Db2 will first use the SORTHEAP memory area, but some data sets are just too big to fit in these locations. Even when an operation spills to temporary space, it may technically still occur in memory – just in the buffer pool for the temporary tablespace. Any type of data manipulation may require these sorts of operations. Db2 uses a system temporary table space for this kind of spill. There is also another type of temporary table space called a user temporary table space
Updated 11/22/2017: instructions on how to run the SQL statement
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.
Updated 6/26/2017 to include links on details for DSM 2.1.4 and a link to the DB2Night Show replay.