Hi,

same experience; the first run of EXPIRE INVENTORY since upgrading to
3.1.2.1 (from 3.1.1.5) started on last Saturday and is still running
(DB is 20 GB). It used to take about 12 hours before upgrading. It used
to examine and delete about 1 million objects, up to now it has examined
4.5 million and deleted 2 million objects. Server is getting really slow,
sometimes during nightly backup, session are rejected due to maximum
number of sessions (60) exceeded; never had that before. My server
platform is AIX 3.1.

Perhaps this behaviour is due to APAR IX81990, which is fixed in 3.1.2.1. 
The README.SRV says:

| IX81990 FILES NOT EXPIRING DURING EXPIRATION 
| 
|  Inactive files are not expiraing according to the copy group  
|  definition for retain extra versions. This may cause excessive  
|  tape usage and the db to grow.  

Anyway, I think, I cancel that process in order to have a stable service
during the following unattended days.

Regards,

Reinhard

Russell Street writes:

 > Hi.... I recently upgraded to 3.1.2.1 (from 3.1.1.3) and found that
 > the EXPIRE INVENTORY process has changed.
 > 
 > It now examines many more objects (5 million now, 50,000 before)
 > 
 > It expires many more objects than before
 > 
 > It now takes 12 hours to run over the 12GB database -- it took 2-3
 > before.  The first time after the upgrade it ran for 36 continious
 > hours!
 > 
 > And it seems that something has changed so simple queries [query
 > volume] and operations [migration] that happily ran concurrently with
 > the expire inventory stall for excessive periods of time.
 > 
 > 
 > Anyone else had this experience?
 > 
 > Tx,
 > Russell
-- 
Reinhard Mersch                        Westfälische Wilhelms-UniversiReinhard 
Mersch                        Westfälische Wilhelms-Universität
Zentrum für Informationsverarbeitung - ehemals Universitätsrechenzentrum
Roentgenstrasse 9-13, D-48149 Muenster, Germany    Tel: +49(251)83-31583
E-Mail: mersch AT uni-muenster DOT de                     Fax: +49(251)83-31653