oh ! please dont come in situation to see any light at the end of the tunnel :-)
----- Original Message ----- From: "PAC Brion Arnaud" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 04, 2004 3:54 PM Subject: Re: TSM DB growing, but number of files remains the same ... 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: [EMAIL PROTECTED] *********************************************************************** -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Tuesday, 04 May, 2004 15:34 To: [EMAIL PROTECTED] 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
