See Bug 5898416 and Data Warehousing Guide. Parallel_max_servers is calculated based on some unpublished formula. In 10g, I often see it at 20 times cpu_count but it varies. I can't think of a good reason why parallel_max_servers needs to be set that high. Just explicitly set it to a lower value. (BTW, I'm writing a set of programs to determine what parameters affect what others. So far I've only finished session-modifiable boolean and numeric type parameters.) Yong Huang > That solution was suggested by another Oracle-L member, too (thanks Paul). > > In the meantime, I did manage to sort of determine the reason for the > problem. > > The cpu_count parameter is 64. It is one of the parameters used to > calculate the value of the parallel_max_servers parameter. The value > of the processes parameter is also used in that calculation, though it > is not mentioned in the Reference Guide. When I increased the value > of processes, the value of parallel_max_servers increased. I only > did a few tests and found that at processes=300, parallel_max_servers > was set to 285, but when processes was set to 1500, parallel_max_servers > was only 1280 and I only had 276 parallel query slaves start up. > > Unfortunately, we don't have enough memory available to run the database > with processes set to 1500.... So, one solution is to set the > parallel_max_servers parameter to something lower than the calculation, > or run ultprp.sql with a parameter instead of running ultrp.sql. > > - Maureen ... >> successfully and patching to 10.2.0.3.0 also completed successfully. -- //www.freelists.org/webpage/oracle-l