Correction: In the SHOW NODE against the subkeys, the KEY is the NODE_NAME. Field 1 is still the node number and field2 is PLATFORM_NAME.
Also, beware of using SHOW NODE on wrong or random pages. On 06.04.20 at 22:58 [EMAIL PROTECTED] wrote:
Date: Thu, 20 Apr 2006 22:58:34 -0500 From: Josh Davis <[EMAIL PROTECTED]> Reply-To: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> To: ADSM-L@VM.MARIST.EDU Subject: hidden flags to EXPIRE INV and CLEANUP EXPTABLE UNDOCUMENTED OPTIONS FOR EXPIRE INVENTORY: There are two undocumented/unsupported options for EXPIRE INV; BEGINNODEID and ENDNODEID. These accept the decimal node number of a node and can be used to expire a specific node's filespaces, or a specific range. WHY WOULD YOU EVER WANT TO USE THESE? EXPIRE INV won't check for filespace lock before parsing a filespace. As such, if you're running expiration, and a node is backing up a filespace when expire inventory gets to it, expire inventory will wait indefinitely. When this happens, CANCEL EXPIRATION or CANCEL PROC will register as "Cancel Pending" but will hang there until the lock is released. Officially there's supposed to be a resource timeout, but IBM wasn't able to give details on how long this is. HOW TO FIND THE NODE NUMBERS: Node numbers are sequential, starting at 1, and are in REG_TIME order. Deletions leave gaps. The short way would be a SELECT statement. Supposedly this can be done, but I couldn't figure out the column name. IBM doesn't like to give info regarding undocumented/unsupported options since that might make them liable to support or defend them in the future. The long way is to use SHOW commands. Use SHOW OBJDIR to find the btree node for the Nodes table. This SHOULD be 38. SHOW NODE 38 (hopefully) will show the top level of the tree. On average, there are about 11 second-level leaf nodes per first level leaf node. If you do SHOW NODE on each subtree, and save these to a file, you'll have the raw data for the nodes table. In the data section, field 1 is the node number in hex, and field 2 is the node name in all-caps ascii. OTHER USES FOR THE NODEID: This can be used with SHOW LOCKS and SHOW THREADS to find out which node is holding the lock preventing expire inv from continuing. From there, you can kill a session so that expire inv can continue or be cancelled. This can also be converted to decimal so you can run EXPIRE INV BEGINNODE=10 ENDNODE=20 or similar to operate only on a specific subset of nodes. This could be used to avoid nodes which have long-running transactions, to quick-expire a huge bunch of data that was just deleted, or to set up scheduled expirations for heavy-expire nodes. These same flags work on CLEANUP EXPTABLE. Since there is no way to cancel CLEANUP EXPTABLE, then running it on a small subset of nodes can help if you suspect you're not expiring all that you should be, but don't want to risk having to shutdown TSM to abort it when you're 50 million objects in and it's a week after you started it. WHY I'M SHARING THIS INFO: I've opened a DCR requesting EXPIRE INVENTORY be given an option to allow detection and skipping of locked filespaces, and that it should be implemented without killing expiration or the session/process holding the filespace lock. The FITS request number is MR0420061821 if you or anyone wants to be added to the notify/me-too list for this. If your sales rep doesn't know where/how to get to FITS, it's on D03DB004.boulder.ibm.com. I think it's under m_dir (marketing). This was way longer than I anticipated, but seemed useful enough to risk sharing. -- Josh