We all have seem hidden parameters being used as a workaround to solve a specific problem, and should be removed once a system has been upgraded to a version level that contains the fix for the specific problem. So what happen when you migrate database to Exadata Machine, specially using physical migration methods? Most likely they are not removed during the migration process, even though the version level might contains the correct fix. Verifying the hidden database initialization parameter usage helps avoid hidden parameters being used any longer than necessary. Otherwise, use of hidden initialization parameters not recommended by Oracle development can introduce instability, performance problems, corruptions, and crashes to your Exadata environments.
Please verify hidden initialization parameter usage in each ASM and database instance using following sql.
select name,value from v$parameter where substr(name,1,1)=’_’;
All being said, there are some acceptable hidden parameters for Exadata Machine. Please review the list of acceptable hidden parameters based on their usage.
Generally Acceptable Hidden Parameters Table
- _file_size_increase_increment with possible value of 2143289344
- _enable_NUMA_support depend on database versions
- _asm_resyncckpt with value of 0 to Turns off resync checkpointing
- _smm_auto_max_io_size 1024 to permits 1MB IOs for hash joins that spill to disk
- _parallel_adaptive_max_users with value of 2
- _assm_segment_repair_bg as false for bug 23734075 work around
- _backup_disk_bufcnt as 64 (Only when ZFS based backups are in use)
- _backup_disk_bufsz as 1048576 (Only when ZFS based backups are in use)
- _backup_file_bufcnt as 64 (Only when ZFS based backups are in use)
- _backup_file_bufsz as 1048576 (Only when ZFS based backups are in use)