|
Re: [ADSM-L] DB2 LOCKLIST parameter
2015-01-12 09:31:03
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.Denier AT JEFFERSON DOT EDU>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
01/09/2015 02:25 PM
Subject:
[ADSM-L] DB2
LOCKLIST parameter
Sent by:
"ADSM:
Dist Stor Manager" <ADSM-L AT VM.MARIST DOT 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.
|
|
|
