ADSM-L

Re: TSM DB growing, but number of files remains the same ...

2004-05-04 10:07:00
Subject: Re: TSM DB growing, but number of files remains the same ...
From: "Jolliff, Dale" <xjolliff AT TI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 4 May 2004 09:05:16 -0500
Speaking of the accounting log, what version and patch level actually
came out with corrections for problems that were introduced in the 4.x
versions?
I don't even remember now what version it was that broke.



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Tuesday, May 04, 2004 8:34 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: TSM DB growing, but number of files remains the same ...

>As a "relatively" experienced ADSM/TSM user, I entirely agree with what
>you said, but, as told in my mail, I doubt that any of my client has
>begun sending more files than usually, because following query "select
>sum(num_files) from occupancy" returns a relatively constant value.
From
>my perception, if I suddenly had more versions of the same files, this
>field should increase, or I am wrong and it does only count 1 unit for
>each filename, without considering the number of versions TSM keeps in
>its DB ? (5 versions of the same file will be counted as 1 ?)

Hi, Arnaud -

Realize that what shows up in Occupancy does not necessarily correlate
with what
goes into the database...  Occupancy may superficially seem like it
should
reflect everything, but it does not necessarily.  Occupancy reflects the
number
of filespace files and the space they consume when stored in storage
pools.
Depending upon client type and file system object types, the backed up
objects
may be stored directly in the database as they need no storage pool
space,
examples being Unix directories and empty files.  All this is to
emphasize that
the number of files you see in the Occupancy table DOES NOT tell you the
number
of files stored on the server for that filespace and storage pool.

The "Number of Files" value from Query OCCupancy reflect all instances
of file
objects: if you perform an Incremental backup, and then update the
timestamp on
one file and perform the backup again, the Number of Files count will go
up by
one, meaning that the count reflects versions.

What the Occupancy table cannot tell you is things like Aggregate size:
transaction size, as influenced from either the client or server, can
change the
size of an Aggregate, and smaller Aggregates mean higher database
utilization.
In topic "Database consumption factors" in ADSM QuickFacts, I summarize
what we
commonly know about what eats database space.

I stress accounting log reporting because it is the very best, detailed
handle
on what your clients are throwing at the server, and that is the
greatest impact
on TSM db space.  It's vital to see such information to spot the source
of
surges and other anomalies.  It greatly frustrates me to see sites
disregard
that administrative gold and try to figure out what has happened without
exploiting that resource.

It may very well be that your clients are not directly contributing to
the
database inflation...which may be the result of some kind of
constipation.
But problem resolution involves problem isolation, which requires being
able to
eliminate factors based upon solid information, and thus we need
thorough usage
tracking over time.

I think I'm over my typing quota now,   Richard Sims

<Prev in Thread] Current Thread [Next in Thread>