Personally, I do not enable this option unless there is clearly a parsing problem, identified by at least two of three situations: CPU consumption dominated by parse time and either shared pool latch contention or library cache latch or mutex contention. Conversely, if there are "out of shared pool memory" errors occurring, be sure to check that cursor_space_for_time is set to false.

Most DBAs know one way to ensure large packages are successfully loaded into the shared pool is use the dbms_shared_pool.keep procedure. When key packages are loaded into memory immediately after the instance starts, your chances of receiving an "out of shared pool memory" error are significantly reduced. In earlier versions of Oracle, especially Oracle8i, this could dramatically reduce the likelihood of running out of shared pool memory.

Figure 7-10 is an OSM report based on v$db_object_cache and shows some of the initial objects loaded after an Oracle instance restarts. Notice that when the report was generated, there were no objects being forcibly kept in the shared pool that met the report selection criteria.