Is there a way to delete TSM node or nodes from db2?

moon-buddy

ADSM.ORG Moderator
Joined
Aug 24, 2005
Messages
7,006
Reaction score
403
Points
0
Location
Somewhere in the US
PREDATAR Control23

For one reason or another, I cannot remove a node from within the TSM server.

Is there a way (or, has someone done this) to remove (drop the node) the node from DB2? This means doing the node drop activity using DB2 tools.
 
PREDATAR Control23

The short answer is yes.

The long answer is that it may not delete other references to the node in other tables and may end up with inconsistencies in the database. I'd recommend pursuing the problem with remove node instead.
 
PREDATAR Control23

I agree that 'remove node' would be the best option but I cannot figure out why TSM cannot delete the filespace for the node. Running a 'delete filespace' finishes with no errors but running a 'remove node' after (even after a day), the TSM server says inventory exist. The node has been decommissioned a long time ago.

As you know, if inventory exist, removing the node is not possible.

Do you know the procedure to do this from the DB2 side, i.e., delete the filespace and delete the node?
 
PREDATAR Control23

'q occupancy <node_name> f=d' is not a valid command (f=d part).

Anyways, it shows the data - system state remaining:

Code:
Node Name      Type     Filespace      FSID     Storage         Number of        Physical         Logical
                        Name                    Pool Name            Files          Space           Space
                                                                                 Occupied        Occupied
                                                                                      (MB)            (MB)
----------     ----     ----------     ----     ----------     -----------     -----------     -----------
NODE1          Bkup     NODE1    -        1     WINTEL         102,077,914      299,290.78      297,285.78
                         \SystemS-
                         tate\NUL-
                         L\System
                         State\Sy-
                         stemState

For system state - this size is NOT normal. By the way, no dedup.
 
PREDATAR Control23

So, no dedup data. I wanted to rule that out because the first node to do a backup will own the extents created. If a 2nd node does a backup and some extents are common to the 1st node, they are referenced. So when you delete the filespace for the 1st node, Q OCC still shows it, but as DELETED. That's because the node can't be deleted if it owns extents referenced by other nodes. This is NOT your case, so let's move on.

I'd try to delete that filespace again. Don't need to target that one specifically, just: DEL FI NODE1 *
 
PREDATAR Control23

So, no dedup data. I wanted to rule that out because the first node to do a backup will own the extents created. If a 2nd node does a backup and some extents are common to the 1st node, they are referenced. So when you delete the filespace for the 1st node, Q OCC still shows it, but as DELETED. That's because the node can't be deleted if it owns extents referenced by other nodes. This is NOT your case, so let's move on.

I'd try to delete that filespace again. Don't need to target that one specifically, just: DEL FI NODE1 *

I ran multiple 'delete filespace <node> *' and the deletion process completes BUT the filespaces still remains. I even tried to be FSID specific for this remaining filespace but the same result.

I went even further as to unload and reload the TSM DB to no avail.

Really puzzled as this is happening to just this node.
 
PREDATAR Control23

Didn't think it applied, but as I said, it's a quick check so may as well rule it out.
 
PREDATAR Control23

Have you tried deleting the objects directly using the

delete object 0 <object_id>

process like many have done for orphaned Oracle data?

select 'del object 0', object_id from backups where node_name=<NODE_NAME>
 
PREDATAR Control23

Try to decommision the node in Spectrum Protect, before you decommision it, create a new domain that only has a default management class, and set the retention to 1 day. That way it should expire quick. Actually you could move to a new domain after decommissioning too.
 
PREDATAR Control23

Try to decommision the node in Spectrum Protect, before you decommision it, create a new domain that only has a default management class, and set the retention to 1 day. That way it should expire quick. Actually you could move to a new domain after decommissioning too.

I was thinking of doing this before I do Chad's suggestion - had done this before and worked well.

Stay tuned.
 
PREDATAR Control23

Update:

Changed retention for the node in question to 1 day, run expire inventory against the node and then delete filespace to be sure.

Did a q filespace and node shows the FSID with ZERO capacity; and still cannot delete the node since inventory still exists!

Dumbfounded by this!
 
PREDATAR Control23

Are you using Spectrum Protect dedup? I believe not, I think you use DataDomain, but I have to ask to be sure.
 
PREDATAR Control23

Did a q filespace and node shows the FSID with ZERO capacity;
With rounding, it's possible there's a tiny bit of data and will show up as 0 if it's less than 0.05% used. Check query occupancy to see if the number of bytes and files is 0.
 
PREDATAR Control23

Check activity log. It should mention, why cannot delete file space.
 
Top