话题
Topic
从基础建设见功底，一套数据库上线前的调试过程，哪些参数设置是需要额外关注的？大家发挥想象，从隐患和性能角度，从Oracle11.2.0.4角度，平台以aix和linux为主。（本期话题贡献人：李广才）
发起人观点
杨建荣_北京：数据库升级中的参数考虑，可以分成几个方向：哪些是通用参数，是否有标准；哪些是性能参数，需要怎么考虑；哪些是过期参数，哪些是新特性参数，是否需要，比如segment deferred creation，case sensatitive的新特性，哪些隐含参数需要调整，比如skip scan是否需要，在我们的系统是禁掉的……
老A（周亮）：Oracle推出的每一个参数都有其特定适用场景，一切以适用角度和最佳实践为准。不过从稳定性角度（Oracle bug实在太多）出发，建议关闭一些新特性参数，如RAC中的DRM特性，11g中的小表直接路径读特性等。
王朝阳：很多参数已经较之前版本优化掉了，还是需要根据业务调整比如打开文件和游标数量，作业进程数量并行回滚级别之类的参数；另外还有操作系统相关的，比如shmmax以及/dev/shm大小等。
IvanYao：首先Oracle官方的文档，对于初始化安装一个Database有一个基本的OS kernel parameters 和Database的设置参考； 对于RAC环境MOS（support.oracle.comS（support.oracle.comS（support.oracle.com)提供了RAC and Oracle Clusterware Best Practices and Starter Kit(Linux/AIX/HP-UX/Soaris)一系列文章，而且是定期更新的，从2014年开始大量的中文文档出现在MOS中，所以对于上面提到的文档都有中文文档可以查询。 在我们这里遇到过系统升级Aix6.1到Aix7.1其中OS级别的参数被重置，导致RAC工作不正常的情况。
另外，从原理上，Oracle database是shared memory的重度用户，所以IPC机制中涉及的参数，特别是shared memory相关应该重点关注。
一般来说Oracle都是用在关键系统中，所有的audit和hardening参数设置的相关的设定和参数验证的工作应该在上线前完成。
彭小波：我说几个和数据库性能相关的几个参数。
1、从Oracle 9i 以上版本起，共享池分为多个副池（sub pool），最多由7个副池，_kghdsidx_count隐含参数，可以管理副池的个数，在CPU为4，共享池250M以上的情况，可以使用设置_kghdsidx_count值的个数副池管理共享池，副池可以作为独立的共享来管理，有独立的空闲列，LRU列，shared pool锁存器。因此可以减少shared pool锁存器的争用。
2、在数据库中发现mutex争用比较多时，可以根据具体情况设置_kgl_hot_object_copies参数，设置SQL争用比较的对象拷贝份数。来达到减少mutex争用的情况。
3、_CURSOR_OBSOLETE_THRESHOLD主要用来控制SQL多版本问题，对于版本过多的SQL，这不仅仅占用了内存，而且会使得SQL解析延迟，一次软解析甚至不如重新执行一次硬解析来的高效，所以Oracle引入了一系列的控制手段来处理这些特殊的游标。在11.2.0.3之后，这些解决方案是修改 _CURSOR_OBSOLETE_THRESHOLD，其作用是当SQL版本超过这个参数设定后，直接舍弃这个游标，重新解析，重头开始。在这一版本之前，通过补丁和参数（"_cursor_features_enabled" 和 event 106001）可以达成类似的效果。
关于SQL的多版本，MOS文章 296377.1 非常值得仔细看看。
李广才：从数据库初始上线调试来讲，基础设计的部分需要尽量贴合业务系统特性来设置。这类的设置会牵扯到较多的数据库配置，基础部分比如系统设置,内存分配、并行设置、缓存规划、文件磁盘规划、统计信息、索引以及表碎片维护计划等，而这些大部分最终是以性能最优化的角度，所以牵扯出来的范围会比较广。
话题上讲到参数设置，我这里抛砖引玉，从运维隐患的角度列出一些实例创建后需要的关注点。
deferred_segment_creation延迟段创建特性默认开启是否需要关闭？他主要影响你的一些导出操作。
_use_adaptive_log_file_sync特性，相信因为它没少遇见log_sync_waits。
_skip_unusable_indexes特性默认开启是否需要关闭？失效的索引不提示但又是不影响业务，这个是好事么？
_optimizer_use_feedback特性默认开启，这11g中这bug较多,是否需要关闭？
_datafile_write_errors_crash_instance特性默认也是开启的，在出现io超时时候会把整个数据库crash,相对比关闭后只offline datafile，哪个好？
optimizer_cature_sql_plan_baselines特性默认是否开启？11g中它会触发一些bug，比如撑爆你的sysaux。
query_rewrite_enabled查询重写默认开启是否需要关闭？
密码大小写敏感特性默认开启，是否需要关闭，特别是在新老数据库升级或者迁移情况下？
登陆失败密码延迟验证特性，该特性的特点主要在密码错误下触发,是否需要屏蔽？
基础审计默认开启的特性，审计表的位置以及审计记录管理是否需要斟酌一翻？
默认profile 密码180天过期是否需要匹配下密码管理策略或者直接更改？
DRM默认开启，是否有必要开启，11g带来的影响也不小呢？
直接路径读默认是开启的，是否应该关闭？
blank_trimming谓词条件去空值是否打开？
optimizer_dynamic_sampling与optimizer_index_caching的比例值是否需要根据应用类型评估设置等？
这只是在数据库实例层面的一部分考虑，还有不少需要关注的系统问题，比如系统的大页是否开启，开了就一定好么？swap 11g的比例算法已经不一样了，是否有关注过？
Rickyzhu：关于系统初始化参数，在不同版本参数不同，但是明显的趋势是数量越来越多。Oracle为了考虑向后的兼容，一些废弃obsolete的参数和一些deprecated参数仍然要保留，新增加的feature又引入了新的参数。
在系统升级特别是数据库升级时，为了保证业务的稳定和连续，建议老的参数继续保留，同时对新出现的参数按照Oracle推荐的最佳实践的方法和MOS的notes进行合理设置。
举两个例子，最近的一个EBS系统升级，数据库版本从10g让10gR2升级到了11g的最新release 11.2.0.4，有一些参数EBS专属的参数Oracle就提供了详细的notes来介绍，这样就必须按照参数进行设计，否则EBS的功能就会受到影响：
*._b_tree_bitmap_plans=FALSE
*._fast_full_scan_enabled=FALSE
*._fix_control='13704562:OFF'
*._gby_hash_aggregation_enabled=FALSE
*._like_with_bind_as_equality=TRUE
*._optimizer_autostats_job=FALSE
*._sort_elimination_cost_ratio=5
*._sqlexec_progression_cost=2147483647
*._system_trig_enabled=TRUE
另外一个例子，就是在测试环境和生产环境的可比性。因为配置不同，生产环境和测试环境在很多典型参数的配置是行也需要进行精细化调整。比如memory_target、sga_target等等。
这些前面已经探讨得已经很热烈了，不再赘述。有一个真实的例子。在一个生产环境，配置了streams进行两个数据库之间的数据复制，生产上线后发现stream的延迟总是超过之前定义的阈值，导致告警频发，跟踪发现是streams_pool_size没进行特别的调整。根据自动内存管理特性，只设置了sga 和pga。这样默认的streams池的大小不够，后来参考MOS notes对streams_pool_size进行特别设置，保证了最小值。提升了streams的复制效率。这个问题在测试环境因为数据量和压力的关系就很难提前预测和发现，也要经过实际的测试才能够发现。总而言之，数据库初始化的设置是个细致活，需要精细化的设置和调整。
杨志洪：这是2个层面的参数。首先，操作系统层面的，AIX的参数，点击【阅读原文】有非常详细的资料供检查。Linux的参数，重点关注HugePage的使用，还有联想服务器如果是上RAC的话，一定要记得把USB心跳关闭（近一年一个用户RAC系统2个节点频繁不定期重启，因为解决掉这个问题后成功成为我们的客户）。
数据库层面，重点是一些坑（关闭DRM、关闭AMM等一些新特性，ricky说的针对EBS的）。我这里贡献电信级大数据库系统的实践（注意Oracle每个版本都会做调整的，用之前还是要请专家甄别下，是否还适用）：
唐波：比如：log_archive_min_success；比如：log_archive_max_process；比如：log_archive_max_processes；比如：rman中的archivelog deletion policy。
群友论点
周俊@HOME.数据集成：用AIX的话存储和光卡的queue depth通常要调整一下，AIX可以用命令标识一下ASM盘防止踩盘事件发生。
小马：asm的内存参数，遇到过默认参数太小，大批量io操作直接当机。asm的memy_target和share池太小，刚好遇上rman和加磁盘，结果asm当了，基本就是默认参数太小，所以生产环境asm的内存参数还是调大点好。
FZJ111@CES.DBA：关于磁盘的参数比较容易被忽略，emc、hds、netapp的磁盘怎么调整属性才能发挥最好的io性能。还有网络网卡的，有的是实卡有的是虚卡，网络参数如何调整？对于用vios的架构，一般网卡都是虚的，要通过vios上去调网卡的一些参数，比如全双工、默认速率。对于用vmx的存储，还得让emc的来出参数。
其实db实例的参数都是根据应用测试来调的，每个系统业务不同。功能测试也就是uat的参数调的少，sit和压力测试参数要多一些。因为测试指标比较严格，每个模块和业务都是有指标的，sit和压力测试参数基本都要上生产。不仅是db，中间件、系统、存储、网络的参数优化都是比较有深度的。
lastwinner：场景很多，最佳实践必须细化到某个或某些场景才适用，因此对其他情况就可能没有参考价值了。可以理解为以默认配置为基础，根据具体情况进行适当修改，所有的数据库其实都是在Oracle默认值的基础上修改来的。
（以上观点仅供参考，本公众号、发起人及群友均不对上述参数或建议在生产上使用造成的后果负责。）
鸣 谢
在“DBA+社群”热议话题讨论活动中，得到了以下联合发起人以及群友们的积极参与和支持。在此，小编整理成文，并附上所有发表观点的人员头像汇总图，特此鸣谢！