关于10g每晚自动的gather_stats_job

bibosea

请教一下，关于10g每晚自动的gather_stats_job，在实际生产中的使用情况？会不会出现统计信息不全导致部分执行计划有问题？
一般小于100g的数据库，我都是每月做一次全靠分析：gather_database_stats。
我看你的一个分区的ppt上说不要随便停这个自动收集的job。

谢谢！

cshiqin

gather_stats_job调用过程dbms_stats.gather_database_stats_job_proc执行信息收集，它会检测哪些对象没有统计信息或者统计信息比较陈旧，将优先对这些对象进行分析。而我们平时手工用的dbms_stats.gather_database_stats，是没有分优先级的，也就是它将对数据里的所有对象进行分析，不管该对象有没有被分析过。GATHER_STATS_JOB任务一般是安排在晚上10pm-6am,周未全天启动。

Maclean Liu(刘相兵

好了，我们需要对GATHER_STATS_JOB和DBMS_STATS包下属的统计信息收集存储过程(gather_*_stats)有一个饱满的认识，他们远没有我们想象的那么2，实际上这个GATHER_STATS_JOB调用的PROGRAM存储过程是DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC，虽然这是一个内部存储过程(interal procedure)；但实际上它和我们经常手动调用的DBMS_STATS.GATHER_DATABASE_STATS收集整库统计信息的存储过程在以GATHER AUTO选项运行时的行为方式上几乎一致，主要的区别是GATHER_DATABASE_STATS_JOB_PROC总是优先收集那些急需收集统计信息的对象，这保证了在维护窗口关闭之前那些最需要收集的统计信息总是能得到满足。而在手动调用GATHER_DATABASE_STATS等存储过程时因为不需要考虑窗口时间线的限制，而不论优先级。


相见http://www.oracledatabase12g.com ... ats-every-time.html

Maclean Liu(刘相兵

"在实际生产中的使用情况？会不会出现统计信息不全导致部分执行计划有问题？"


默认DBMS_STATS只对 col_usage$ 中过记录的 列收集直方图(histogram) ， 可能因为缺乏直方图 而导致某些非绑定变量的SQL语句 计划偏差，  但是这是 DBMS_STATS 这个包的默认表现 即不仅是gather_stats_job这个作业 单独的问题。

关于 column_usage$ 和 histogram 详见http://www.oracledatabase12g.com ... tain-col-usage.html

bibosea

这样说的话， 如果数据量>1T，dbms_stats.gather_database_stats_job_proc还是很有效的？

对于数据量>1T数据库的统计信息收集，老大有什么其他建议？

谢谢

Maclean Liu(刘相兵

”对于数据量>1T数据库的统计信息收集“

如果 每天的数据变动更新量 不多 相对静态的话， GATHER_STATS_JOB的活跃度并不高（它只收集没有统计信息的对象 亦或者 统计信息陈旧的对象)， 建议保留默认设置。

如果 每天的数据变动量 都比较大的话， GATHER_STATS_JOB从 晚上22:00 -第二天6:00(6点以后即使收集不完，默认也会停止，等待第二天22:00继续)都会消耗就多的CPU和IO 去统计信息，如果 这个时间恰巧是业务高峰的话， 建议客制化 GATHER_STATS_JOB的启动时间和周期。