Troubleshooting
Problem
Server levels 6.2.5, 6.3.3, 6.3.4 and 7.1.0 can experience this problem.
Symptom
The server halts because the active log becomes full when the server runs index reorganization on the BF_BITFILE_EXTENTS table.
Cause
When the server runs a fixing level which includes APAR IC82352, reorganization might be run on the BF_BITFILE_EXTENTS table to solve a performance degradation problem. However, the server can halt if the active log becomes full. The server halt is more likely to occur on systems where the BF_BITFILE_EXTENTS table is large, data deduplication is enabled, and the server is busy.
A large amount of deletion activity of storage pool data (DELETE FILESPACE on large nodes) on servers with enabled data deduplication can make the reorganization activity necessary.
Diagnosing The Problem
If formulas F7 and/or F8 are indicated on any index for table BF_BITFILE_EXTENTS, when a server running a fixing level for APAR IC82352 starts, it performs a cleanup index reorganization on BF_BITFILE_EXTENTS. Before you start the server that includes the fix for IC82352, issue the following commands from a DB2 command window to determine whether a reorganization of BF_BITFILE_EXTENTS will start:
db2start
db2 connect to tsmdb1
db2 "reorgchk current statistics on table tsmdb1.bf_bitfile_extents"
Examine each index for BF_BITFILE_EXTENTS. If Formula 7 (F7) or Formula 8 (F8) is indicated for any index on that table, index reorganization will start on that table when the server starts.
Resolving The Problem
This problem is fixed with IC91190. Before the fixing levels for that APAR are available, you can resolve the problem by either of the following methods:
Method 1
Issue the following commands from a DB2 command window, while the server is halted:
db2start
db2 connect to tsmdb1
db2 "reorg indexes all for table tsmdb1.bf_bitfile_extents allow no access cleanup only all"
db2 "runstats on table tsmdb1.bf_bitfile_extents and sampled detailed indexes all "
After the RUNSTATS process is complete, start the server.
These commands can fail when the bf_bitfile_extents table is large; if they do you will need to use method 2 instead.
Method 2
If you cannot use method 1, issue the following commands from a DB2 command window, while the server is halted:
db2start
db2 connect to tsmdb1
db2 "insert into tsmdb1.global_attributes
(owner,name,type,length,int32)
values('RDB','REORG_ONDEMAND_SETTLETIME_MIN',3,0,1000000) "
A side effect of this method is that if the server determines that a cleanup index reorganization needs to be done on BF_BITFILE_EXTENTS, all further reorganization activity on the server will stop until the server starts again.
The server will need to be restarted a minimum of once every 48 days due to IT03284.
To resume normal reorganization activity, after you have a fixing level for IC91190, issue these commands in a DB2 command window before you start the Tivoli Storage Manager server:
db2start
db2 connect to tsmdb1
db2 "delete from tsmdb1.global_attributes
where owner='RDB' and name='REORG_ONDEMAND_SETTLETIME_MIN' "
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21653582