On Wed, 27 Jun 2012, "Loon, EJ van - SPLXO" @ KLM wrote:
>[...]
> My TSM databases are running for quite a while (since 4.1) and they are
> becoming rather fragmented, one of them more that 25%! It becomes
> noticeable too, expiration is running longer and longer.
> Our TSM servers are all running in AIX 5.3 on a P-series 570, SAN
> attached to a VMAX (OS, DB and LOG) and VNX (diskpool) storage subsystem
> and two EMC DL4106 DiskLibraries (VTS without physical tapes).
> Unloading the smallest (95 Gb) database takes about 7 hours, loading it
> takes about 3.5 hours. These tests are perform with a live database copy
> on our test environment. Overall it takes too long to do this on our
> live environment.
>[...]
My understanding of the "unload" process: TSM reads, in a single thread,
all of the database in logical order, i.e. it may do arbitrary amounts
of random 4kB read I/O depending on the amount of "randomness"
in physical placement of the database pages. I'm not aware of any method
to estimate that, short of scanning the whole database - ESTimate DBREorgstats
appeared to do just that - in essentially the same time that UNLOADDB would
take -
at my first & last glance.
Be aware that when looking for a free disk "page", TSM V5 always allocates
the first free one in disk (address) order, so databases that undergo
deletions of filespaces and nodes ought to be much more "random"
(due to tables being continued at lower addresses) than those
where only additions are performed to the inventory.
(Naturally, _we_ _often_ do deletions here ;-()
We've given up on the idea of re-organizing (in the course noticing that
a cheap "p520" (AFAIK, "p720" in today's terms) is _much_ more powerful
than an old "p 570", but even JS21 blades are doing quite well),
and with 15k FC disks we still don't have a serious problem with expiration.
I'm going to wait for some large enough[*] FC SSD system (to be used as
TSM DBCOPY, with the mirror broken just prior to UNLOAD) - guess it won't
take that long anymore - until considering migrating our "interesting" DBs to
V6.
[*] 512 GB required, since our oldest DB takes 442 GB disk space (stripped down
to a "max.reduction" of <4 GB), utilized only 60% since long ago - but at some
point
in time all filled up. Expiration took much longer then. ;-)
Sure one might get an even smaller DB by UNLOAD/LOAD - a test run (with disks
tuned for random read speed) would take about 2 days (net), and make for a new
DB
taking up about 220 GB (as opposed to the current "used space" of 260 GB) ...
anyway, I've never run ESTimate DBREorgstats to completion.
Best regards,
Wolfgang J. Moeller <moeller AT gwdg DOT de>
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
|
