ADSM-L

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

2004-05-04 09:59:48
Subject: Re: TSM DB growing, but number of files remains the same ...
From: PAC Brion Arnaud <Arnaud.Brion AT PANALPINA DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 4 May 2004 15:54:52 +0200
Richard,

Many thanks for that clarification, I really appreciate ! I believe what
I have to do now is to build some solid queries to explore our activity
log... Fortunately it has a retention of 30 days, what should allow me
to find out where it began to hurt. Wish me good luck, I'll keep you
informed if ever I find light at the end of the tunnel ! 
Cheers. 

Arnaud 

***********************************************************************
Panalpina Management Ltd., Basle, Switzerland, CIT Department
Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone:  +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.brion AT panalpina DOT com
***********************************************************************




-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Richard Sims
Sent: Tuesday, 04 May, 2004 15:34
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>