Hello Thomas, We've had issues with this parameter and I ended up setting it to a stupidly high number because I had the RAM to spare and was tired of seeing server hangs due to locklist exhaustion. I ended up using 4X the maximum recommended value of 1,220,000 and rounded it to an even 6,000,000. We use deduplication and will see 4-7 TB ingest, with another 3-5 TB migration and a further 3-6 TB of reclamation during a given day. If you're not using dedup on wide scale, I think you'd be safe using the recommended value for 5TB movement. __________________________ Matthew McGeary Technical Specialist - Operations PotashCorp T: (306) 933-8921 www.potashcorp.com
From: Thomas Denier <thomas.den...@jefferson.edu> To: ADSM-L@VM.MARIST.EDU Date: 01/09/2015 02:25 PM Subject: [ADSM-L] DB2 LOCKLIST parameter Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> Inventory expiration processes on one of our TSM servers have been failing occasionally with no obvious explanation. We were able to get trace data for the most recent failure. IBM reviewed the trace data and advised us to increase the DB2 LOCKLIST parameter. They referred us to a technote at http://www-01.ibm.com/support/docview.wss?uid=swg21430874 for information on calculating the new value for the parameter. The instructions in the document are puzzling, to put it politely. The document notes that deduplication greatly increases the need for row locks, but recommends the same LOCKLIST setting whether deduplication is being used or not. The recommended value is based on gigabytes of data moved rather than number of files moved. This sounds reasonable for environments with deduplication but is inexplicable in environments without deduplication. The document makes reference to "concurrent data movement". In one of the examples given, all incoming client data in a four hour period and all data moved by migration in the same period is counted as "concurrent data movement". The other example treats data movement spread over eight hours as "concurrent". As far as I can see, this makes sense only if every database transaction triggered by client sessions and background processes remains uncommitted until all data movement activity ends. One of our clients is a 32 bit Windows file server with 18 million files on rather slow disk drives. The backup for this client starts in the middle of our intended backup window and almost always runs through the day and an hour or two into the next backup window. The TSM server can run for months at a time with at least one client session in progress at all times. The examples in the technote seem to imply that all data movement occurring during those months should be counted as "concurrent". Is there any documentation available in which the criteria for selecting a LOCKLIST setting are explained more clearly? We are currently using TSM 6.2.5.0 server code running under zSeries Linux. We are preparing to upgrade to TSM 7.1.1.100. We are not currently using deduplication. We may use deduplication for backups of databases on client systems after the upgrade. We don't have the CPU and memory resources to use deduplication for all client files. Thomas Denier Thomas Jefferson University The information contained in this transmission contains privileged and confidential information. It is intended only for the use of the person named above. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. CAUTION: Intended recipients should NOT use email communication for emergent or urgent health care matters.
