Oracle 7.2.2.3 memory leak

Hi, I wonder if anyone can help me track / solve my current problems:

We just upgraded to 7.2.2.3 (Solaris 2.3) on December 2nd, and since then have had a mass of problems ... I don't have the lists with me at the moment, but we have had at least 10 TARs opened. The current problem became visible on December 4th, and we have been fighting it ever since:

1. ORACLE jammed up (basically froze). We worked around this one by simply cancelling any ORACLE processes that seemed to use more than 40% of cpu. The problem seems to be a memory leak of some kind that has a cumulative effect. The first symptoms seem to crop up around 30,000 connects (SQL*NET V1 or V2), and become totally solid somewhere between 100,000 and 200,000 connects.
2. Increased the shared_pool from 16M to 24M
3. Received ORA-4031, and a number of ORA-0600 type errors. ORACLE supplied a patch on Dec.12 for the 4031, and another on Dec 14 for the 0600s. Immediately after the 4031 patch, system performance on our benchmark queries dropped to approximately 30% of the normal prior timings.
4. Set up a cron to run twice a day to: 'alter system flush shared_pool'
5. System ran with decent performance for 30 hours. We also had vastly upped our MTS_SERVERS and MTS_DISPATCHER parameters.
6. Altered cron to run the flush every 5 minutes after the system still cratered.
7. System has become moderately stable, but ORACLE tells me that this sort of problem and work-around has never been reported. I am further told that upgrade to 7.2.2.4 will get around the known problems with 7.2.2.3 (ORACLE didn't even seem to acknowledge their existence until the TAR was escalated to Level 1).

I have been quite surprised to find that no-one else seems to have had our problems. Is it true that we are the only users anywhere that are hit by these memory leaks (also by abyssmal performance after applying the patch for the 4031 error). If you've had similar experiences, please respond ... I find it hard to believe that I'm at the only site anywhere reporting these problems. Any support (and stories of your surprise) would be appreciated by me in wrapping up the upgrade report for my management (assuming that it will happen in the short-term future).

BTW, the front-line people handling the TARs HAVE provided good support in general (or rather in specifics ... it really seems that a lot of the time and difficulty was in getting any coordinated effort out of the group ... i.e. getting all the open TARs grouped together under general headings like memory problems, performance issues, SQL*NET problems, etc)

--
Name:	Bill Beaton			beatonb_at_cadvision.com
					Bill_Beaton_at_digitech.ab.ca
Phone:	(403) 295-3254 (Home)		(403) 266-8622 (work)