Troubleshooting
Problem
After a move from file device dedup to container type storage pools, space might still be allocated for the tables used for file device dedup storage pool information. This document describes how to verify that the space is unused and how to free up storage.
Symptom
In this example we document how to check for information stored in the BF_QUEUED_CHUNKS table.
The following tables need to be checked in addition:
- BF_AGGREGATED_BITFILES
- BF_BITFILE_EXTENTS
- BF_DEREFERENCED_CHUNKS
Looking at the allocated/used space as documented with the swg21590928 technote (see related URL section) BF_QUEUED_CHUNKS might still report space being allocated:
NAME : BF_QUEUED_CHUNKS
ROWS_IN_TABLE : 344767
TABLE_USED_MB : 14
TABLE_ALLOC_MB: 2126
INDEX_USED_MB : 514957
INDEX_ALLOC_MB: 525261
Diagnosing The Problem
Before cleaning up the table and indices, verify that there is no outstanding dedup deletion:
SHOW DEDUPDELETE should report something similar to
**** Dedup Deletion General Status ****
Number of worker threads : 8
Number of active worker threads : 0
Number of suspended workers : 0
Number of workers to suspend : 0
Number of chunks waiting in queue : 0
Total number of chunks processed : 0
**** Dedup Deletion Worker Info ****
Worker thread 1 is not active
Worker thread 2 is not active
Worker thread 3 is not active
Worker thread 4 is not active
Worker thread 5 is not active
Worker thread 6 is not active
Worker thread 7 is not active
Worker thread 8 is not active
------------------------------------------
Total worker chunks queued : 0
Total worker chunks deleted: 0
**** Fragment Deletion Status ****
Number of busy threads: 0
Number of idle threads: 6
Number of entries queued: 0
Look at the SHOW THREADS output and verify that the bfDerefDeleteThreads are waiting for work as with the following example:
Thread 158, ID 28452 (0x6f24): bfDerefDeleteThread, procToken=0,
sessToken=0
Parent=157, result=0, joining=0, detached=1, zombie=0, session=0
Waiting for Cond 352415464 (&wrkInfoP->wakeUpWorkerThread) using mutex 0
(na). Waiting from
Stack trace:
000000007782C0EA ZwWaitForMultipleObjects()+a
000007FEFDA21430 GetCurrentProcess()+40
00000000776D06B0 WaitForMultipleObjects()+b0
000007FED310BCD4 pkWaitCondition()+94
000007FED331D25D bfDerefDeleteThread()+47d
000007FED3107911 startThread()+141
000007FEF0894F7F beginthreadex()+107
000007FEF0895126 endthreadex()+192
00000000776D59BD BaseThreadInitThunk()+d
000000007780A2E1 RtlUserThreadStart()+21
And confirm there are no chunks that are assigned to a workerid:
db2 connect to tsmdb1
db2 "select workerid, count(*) from tsmdb1.bf_queued_chunks group by workerid"
The output must look like
WORKERID 2
----------- -----------
0 record(s) selected.
Resolving The Problem
Once that is confirmed, you can go through an offline reorg of the BF_QUEUED_CHUNKS table. For instructions see the reorg technote (swg21683633, see URL link section below), followed by
db2 alter tablespace USERSPACE1 reduce max
db2 alter tablespace IDXSPACE1 reduce max
Pending on the conversion state of your tablespaces, you can use the following command to determine the correct tablespace to alter for BF_BITFILE_EXTENTS and BF_AGGREGATED_BITFILES
db2 "select substr(TABNAME,1,20) as table, substr(TBSPACE,1,20) as tablespace, substr(index_tbspace,1,20) as indexspace from syscat.tables where tabschema='TSMDB1' and TABNAME in ('BF_BITFILE_EXTENTS', 'BF_AGGREGATED_BITFILES') order by 3"
Once completed the space is freed to the OS again.
Related Information
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21992410