Hyundeok Kwon posted a message at http://technet.oracle.com:89/ubb/Forum70/HTML/001649.html. The problem he tries to solve, described by the first author Sergo Grigalashvili on that page, is exactly the same as ours: library cache latch contention in the portal database. The remedy is cut down usage of Javascript or move them onto Web server instead of storing in Oracle. In addition, I'm fighting this latch contention as a general database issue (general in the sense that I don't care whether it's Portal). quote: We migrated webdb 2.2 to portal 3.0.6(eventually 3.0.9) and experience a severe performance degradation which was addressed something in the forum. One simple thing you can try is reduce the number of javascript calls if you are using Portal forms. By default, javascripts are stored in the database and are called on loading. One javascript call takes 2-3 secs on 56k modem. Imagine how long it would take more if you have 20 javascripts in a page. What our developers did was take them out and put them in middle-tier. I don't know much about the details though. The other thing will be about CPU usage of database server. Portal hogs server resources quite a lot. Our server was SUN E450 which has 4 cpus of 450MHz. They were easily maxed out with only 10 or so active database sessions. So, you may have to try a bigger box, or tune your applications. Portal's connection pooling mechanism also cause problems in the number of "processes " and "distributed_processes" wise. In 3.0.7 and 3.0.8 I heard a few indexes for some portal tables are missing. You need to reconstruct them. end quote What indexes are missing? Jan Willem Vermeer (http://technet.oracle.com:89/ubb/Forum70/HTML/002517.html) finds that a lot of Java classes cannot be compiled (exactly what we found out here) and they exist in both SYS and PORTAL schema. He says "after deleting four classes that could not be compiled after the upgrade to 309, the portal-environment performance increased". Should we do this? DBAs: The change I plan to make to the port database is: session_cached_cursors = 10 --so that cursors don't need to be opened again, avoiding even soft parse _kgl_bucket_count = 5 --http://www.ixora.com.au/scripts/library.htm #_use_ism = false Uncommenting _use_ism restores usage of intimate shared memory to the default true. It should be set to false if we're severely short of memory (so SGA can be paged out to swap disk) or when you have problems with MTS. port used to run in MTS mode. Maybe that's the reason it was set. If library cache latch contention is still severe, we may consider disabling latch wait posting (_latch_wait_posting = 0) according to Steve Adams, Oracle8i Internal Services, p.27. Yong Huang select addr,child#,gets,misses,sleeps,immediate_gets,immediate_misses,waiters_woken,waits_holding_latch,spin_gets,sleep1,sleep2,sleep4 from v$latch_children where addr in ('D1B6C224', 'D1B6BE14', 'D1B6BE14', 'D1B6C01C', 'D1B6BE14', 'D1B6BE7C', 'D1B6BFB4', 'D1B6BFB4', 'D1B6BF4C', 'D1B6BE14', 'D1B6BE14', 'D1B6C224', 'D1B6C084', 'D1B6C154'); ADDR CHILD# GETS MISSES SLEEPS IMMEDIATE_GETS IMMEDIATE_MISSES WAITERS_WOKEN WAITS_HOLDING_LATCH SPIN_GETS SLEEP1 SLEEP2 SLEEP4 -------- ---------- ---------- ---------- ---------- -------------- ---------------- ------------- ------------------- ---------- ---------- ---------- ---------- D1B6BE14 11 97073403 7619824 3725141 14731 891 1974586 7619824 5467374 1059877 775193 0 D1B6BE7C 10 29148491 3006168 1559174 15675 155 811982 3006168 2172360 332290 345316 0 D1B6BF4C 8 17208569 405039 316441 14261 172 164303 405039 217279 91481 71984 0 D1B6BFB4 7 29429024 2153852 1846581 14912 153 993868 2153852 1065658 527262 416692 0 D1B6C01C 6 22978793 1267492 974087 15458 200 512612 1267492 645299 338637 228137 0 D1B6C084 5 50570171 3374084 1876195 14582 147 956749 3374084 2176391 642483 452512 0 D1B6C154 3 22806052 696976 477419 14595 100 242812 696976 380371 174732 125164 0 D1B6C224 1 28316551 1208418 864278 15552 126 443526 1208418 639575 315362 217366 0 8 rows selected. Our _spin_count is default 2000. May need to reduce by half (_spin_count * sleeps / misses, S. Adams' book p.24) _kgl_bucket_count and _kgl_latch_count are both 0 at this time. May need to pin heavily executed PL/SQL objects: PORTAL30.WWNLS_API 1875971 PORTAL30_SSO.WWNLS_API 1875971 PORTAL30.WWPRE_API_VALUE 2655837 PORTAL30.WWSEC_API 4761024 PORTAL30_SSO.WWSEC_API 4761024