Hi Luke! Just because I'm currently trying to boost expiration processing: I see your database is rather large, how long did it take you to expire those 23194393 objects? I really tried almost everything, from moving to 15k speed disks, multiple database volumes, moving to RAW's, the best I have seen in my environment is 60 objects per second. I posted a question some time ago (2002) where I requested for other people's performances, Tom Kauffman was the winner at that time with a dazzling 3112 objects per second! Kindest regards, Eric van Loon KLM Royal Dutch Airlines
-----Original Message----- From: Luke Dahl [mailto:[EMAIL PROTECTED] Sent: Thursday, March 25, 2004 21:39 To: [EMAIL PROTECTED] Subject: Re: Expiration after TSM upgrade from 5.1.6.4 to 5.2.2.1 Hi Mark, Output from q db f=d: Available Space (MB): 118,780 Assigned Capacity (MB): 70,000 Maximum Extension (MB): 48,780 Maximum Reduction (MB): 15,924 Page Size (bytes): 4,096 Total Usable Pages: 17,920,000 Used Pages: 11,215,255 Pct Util: 62.6 Max. Pct Util: 77.3 Physical Volumes: 1 Buffer Pool Pages: 32,768 Total Buffer Requests: 2,151,221,843 Cache Hit Pct.: 99.04 Cache Wait Pct.: 0.00 Backup in Progress?: No Type of Backup In Progress: Incrementals Since Last Full: 0 Changed Since Last Backup (MB): 2,785.80 Percentage Changed: 6.36 Last Complete Backup Date/Time: 03/24/04 17:33:13 This is the standard amount of expiration we see: 03/14/04 17:27:07 ANR0812I Inventory file expiration process 1692 completed: examined 23194393 objects, deleting 1690917 backup objec cts, 0 archive objects, 0 DB backup volumes, and 0 recov very plan files. 0 errors were encountered. This is currently running: Process Process Description Status s Number -------- -------------------- ------------------------------------------------- 26 Expiration Examined 22853888 objects, deleting 20518954 bac ckup objects, 0 archive objects, 0 DB backup vo olumes, 0 recovery plan files; 1 errors encount tered. I don't think the policies were correctly expiring data prior to the upgrade. We've had numerous nodes that seemed to be storing much more than their policy dictated. We tried to force expiration on the files and it didn't seem to make much of a difference. Unfortunately we've been tweaking policies and trying to force a lot of data to drop off prior to the upgrade so I can't point to any particular reason why expiration is now expiring so much data. You can see the db size has dropped as well due to the expiration - and we performed an unload/reload less than a month ago prior to the upgrade. Being the db volume is one volume it could be disk contention, but it's a raw volume fiber attached (Sun T-3's). Luke "Stapleton, Mark" wrote: > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of > Luke Dahl > > We upgraded our TSM Server (Solaris 9) from 5.1.6.4 to 5.2.2.1 last > >week. Prior to the upgrade our expiration usually lasted about 24 > hours > >(53Gb database). It would generally post results like this: examined > >16446439 objects, deleting 59582 backup objects > >Our 3494 library showed est. capacity of 60Tb and approximately 88 pct. > >util. > > What is your db's cache hit ratio? 24 hours for a 53GB database is > manifestly too long. It should get through expiration in 2-3 hours. Give > us the output from Q DB F=D. > > >Any idea why expiration wasn't running properly prior to the upgrade? > >Data integrity looks good but we've just cleared out loads of space. I > >don't recall a known bug in expiration processing in 5.1.6.4 but may > >have missed something. Thanks for your thoughts and input. > > How, exactly, did you "clear out loads of space"? > > -- > Mark Stapleton ********************************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **********************************************************************
