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:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Tuesday, May 04, 2004 8:34 AM 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
