RMAN, NetWorker, and huge delays in 'list' commands

We're slowly getting things in order here with Oracle 8.1.7, RMAN, and NetWorker. I'm only the RMAN guy in this chain of events so bear with me if I'm a bit less than accurate.

Up until a few months ago I was regularly running 'crosscheck backup' and
'delete expired backup' against each of our instances for the sake of
keeping RMAN snyched with what NetWorker had on file. Then it came to my attention that, due to the browse policy of the Legato system, I was losing backups once they left the browse listing, rather than when the tapepools they were on were expired and reused. Naturally, I've stopped these crosschecks and deletes.

It is my guess that we'll simply have to keep all of the RMAN backup information on hand for a full year (expiring only things older than that) to accomodate the tapepools we have for our bimonthly and monthly rotations of tapes.

(Sidebar: I'd be interested in knowing how others handle this situation of RMAN recovery catalog information vs NetWorker browse time and tape retention. Is there something I'm missing or is a full year's worth of database backups going to be required?)

Now, with only two full months under our belt of nightly backups using RMAN and NetWorker, I am finding that any 'list database' command in RMAN takes 10 or 20 minutes easily. Even refining that list to 'SYSDATE-1' doesn't seem to make things run much quicker.

Any ideas what might be causing such a huge delay? My guess was some sort of poor indexing or something...

Update: while composing this message, I wanted to provide more accurate (that is, less exaggerated) times for the problem. Now, all of a sudden, the list takes on the order of seconds; even the full result set of a
'list backup of database archivelog all' for more than two months takes
less than 10 seconds.

I asked the DBA if anything had changed and she replied no. Apparently, no update statistics or index rebuilds have been run against the RMAN database at all. No one can take credit for this "repair".

Although not a problem anymore, I still don't know what might have caused it or what its solution may have been so I'm still asking if anyone has any ideas they can offer.

Thanks muchly.

-- 
"Tie. 'Nuff said." - Anatomy of an Anti-Geek, User Friendly, 15 Nov 1998.
D. Joseph Creighton [ESTP] | Systems Analyst, Database Technologies, IST
Joe_Creighton_at_UManitoba.CA | University of Manitoba  Winnipeg, MB, Canada, eh?