It's Friday and it is a slow day. How about I tell you about a DB2 tool that until 2 weeks ago I had never heard of and never had used before? It is a tool that has been in DB2 for an eternity (I found an
entry in the Information Center for version 8). I am talking about
db2greg which is used to view and change the DB2 global registry.
hloeser@BR857D67:~/Downloads$ db2greg -dump
V,DB2GPRF,DB2SYSTEM,HENRIK,/opt/ibm/db2/V9.7,
V,DB2GPRF,DB2ADMINSERVER,dasusr1,/opt/ibm/db2/V9.7,
I,DB2,9.7.0.4,hloeser,/home/hloeser/sqllib,,1,0,/opt/ibm/db2/V9.7,,
V,DB2GPRF,DB2INSTDEF,hloeser,/opt/ibm/db2/V9.7,
V,DB2GPRF,DB2FCMCOMM,TCPIP4,/opt/ibm/db2/V9.7,
S,DB2,9.7.0.4,/opt/ibm/db2/V9.7,,,4,0,,1305817517,0
S,DAS,9.7.0.4,/opt/ibm/db2/V9.7/das,lib/libdb2dasgcf.so,,4,, ,,
I,DAS,9.7.0.4,dasusr1,/home/dasusr1/das,,1,0,/opt/ibm/db2/V9.7/das,,
Using the "-dump" option as shown above lists the current entries, here for a DB2 9.7. But why would I have to use db2greg and how did I find out about it? The reason is DB2 9.8 which basically is the pureScale feature that brings application cluster transparency. By lack of coffee and sleep and too much enthusiasm I had pulled too many power cables at the same time on a demo machine (nanoCluster). That resulted in some "extra time" in bringing back the machine to "fully operational". In that process I had to clean up some system entries, e.g., like shown in
this example in the Information Center.
You will notice in the example that some information DB2 needs to know about the GPFS and the RSCT clusters are stored in the global registry (PEER_DOMAIN, GPFS_CLUSTER, etc.). If parts of a system are manually (re-)build, the registry may become inconsistent and that's when db2greg options like "-delvarrec" and "-addvarrec" are needed to patch up the registry.
For me the mishap ended up with some extra work, but lots of new things learned. And remember, patch responsibly...