I would have to weigh in with Tanel and Fairlie on this, although our story is more sodden with bugs. http://www.freelists.org/archives/oracle-l/05-2006/msg00172.html
Like Tanel said for smaller databases (his point #1), ASMM should be fine - not really necessary per se, but it will do the job. I disagree about point #2, in light of my previous note, but I can accept that there might be situations were ASMM would be appropriate, as long as you are aware of the bugs and limitations of the feature.
Even under 10.2.0.2, we have sga_target = 0 - we were scarred (and scared) pretty good under 10.2.0.1.
How does ASMM handle a system with high volumes of non-shareable SQL? When manually sizing the shared pool, we have always been reminded that a large shared pool size could lead to serious performance problems strictly because of the size of the pool. Assuming you have this situation in an ASMM environment, how does Oracle handle it? Does the shared pool grow so large that the other auto-sized caches are affected? Do the advisors recommend increasing the sga_target to accommodate a huge shared pool and if so, what are the performance ramifications? Are they similar to those encountered with large shared pools in a manually sized environment?
I realize that one of the answers is to fix the app. However, I'm trying to understand how ASMM would handle this situation in case it isn't a good solution for some applications.
______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
-- Charles Schultz