As soon as we upgrade our RAC 10.2.0.3 (Linux x86_64), 'gc blocks lost' dropped to negligible level. Although I didn't capture the pre-upgrade parameter values on that database, I did it on a Windows database non-RAC right before and after the upgrade. See below. Unfortunately nothing is obvious to explain the cure of my RAC problem. >: 10.2.0.4 new parameter < (indented): 10.2.0.3 parameter no longer in 10.2.0.4; actually none found !: same parameter with different value (old -> new) PARAMETER VALUE COMMENT ---------------------------------------------------- --------------------- ------------------------------------------ > _arch_corrupted_redo_log 0 > _asm_skip_resize_check FALSE > _buffered_publisher_flow_control_threshold 0 > _capture_buffer_size 65536 > _capture_publisher_flow_control_threshold 0 > _controlfile_enqueue_holding_time 120 > _cvw_enable_weak_checking TRUE ! _db_block_adjchk_level 77606400 -> 0 > _db_block_vlm_check FALSE > _db_block_vlm_leak_threshold 3 > _db_required_percent_fairshare_usage 10 ! _disable_duplex_link FALSE -> TRUE > _disable_flashback_wait_callback FALSE > _fg_sync_sleep_usecs 0 > _flashback_marker_cache_enabled TRUE > _flashback_marker_cache_size 328 > _high_priority_process_num_yields_before_sleep 1000 > _inquiry_retry_interval 3 > _insert_ctas_dependency FALSE > _kgx_spin_count 255 ! _kill_enqueue_blocker 1 -> 3 > _kill_diagnostics_timeout 60 > _kkdlgon_max_iter 20000 > _ksb_restart_clean_time 30000 > _ksb_restart_policy_times > _ksxp_testing 0 ! _large_pool_min_alloc 16000 -> 65536 larger value may reduce shared pool latch contention in shared server config > _lm_better_ddvictim TRUE > _lm_dd_max_search_time 180 > _lm_dd_search_cnt 3 > _lm_postevent_buffer_size 256 > _lm_rcvr_hang_allow_time 200 > _lm_rcvr_hang_check_frequency 60 > _lm_rcvr_hang_kill FALSE ! _log_archive_buffer_size 2048 -> 127 > _object_reuse_bast 2 > _optimizer_connect_by_combine_sw TRUE > _optimizer_enable_density_improvements FALSE > _optimizer_fkr_index_cost_bias 10 > _optimizer_or_expansion_subheap TRUE > _optimizer_sortmerge_join_inequality TRUE > _optimizer_star_trans_min_cost 0 > _optimizer_star_trans_min_ratio 0 ! _optimizer_undo_cost_change 10.2.0.3 -> 10.2.0.4 Will change unless you explicitly set optimizer_features_enable > _optimizer_use_histograms TRUE > _optimizer_use_subheap TRUE > _px_bind_peek_sharing TRUE > _px_ual_serial_input TRUE > _rcfg_disable_verify FALSE > _recovery_skip_cfseq_check FALSE > _rm_numa_sched_enable FALSE > _rm_numa_simulation_cpus 0 > _rm_numa_simulation_pgs 0 > _scatter_gcs_resources FALSE > _scatter_gcs_shadows FALSE > _side_channel_batch_timeout_ms 500 > _skgxp_udp_lmp_mtusize 0 > _skgxp_udp_lmp_on FALSE > _smon_undo_seg_rescan_limit 10 > _wcr_control 0 ! log_buffer 2859008 -> 2850816 I use ASMM; if that's why for the change, can ignore ! optimizer_features_enable 10.2.0.3 -> 10.2.0.4 > pre_11g_enable_capture FALSE "enable capture of DB Replay"; some 11g feature may be enabled here < 1436 rows selected. (for 10.2.0.3) > 1491 rows selected. (for 10.2.0.4) 2008-05 update: We upgraded a 10.2.0.3 database running on RH Linux x86_64. All changes are the same as above but the total number of parameters differ. < 1182 rows selected. (for 10.2.0.3) > 1236 rows selected. (for 10.2.0.4) 2009-05 update: commit_write quietly changes its behavior to nowait. See Bug 7142180.