DBMS_STATS收集统计信息的问题及解决

收集数据库的统计信息是dba工作的一部分,如果在数据快速增长的库上,统计信息如果收集的频率太慢,会对执行计划有一定的影响。 而对于逐渐客户饱和的系统来说,统计信息就可以很长时间收集或者尽量不收集。 对于统计信息的收集,如果是很大的表,收集100%也是不现实的,如果收集的百分比太小,统计信息又失真,对系统系统无疑是雪上加霜。 以上是我采用的方式,不一定对,可以参考。如果表的大小超过30G,算是很大的表了,统计信息的收集比例在30%到40%之间,我给了40%。以下类似。 巨型表(>30G), percentage 40%. 大型表(>8G,<30G), percentage 50%. 中型表(>1G,<8G), percentage 60%. 小 表(<1G), percentage 70%. 对于较大的表,都加了degree.

exec DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=> 'xxxxx', TABNAME => 'xxxxxx'  ,CASCADE => TRUE, METHOD_OPT =>'FOR ALL INDEXED COLUMNS SIZE 1', ESTIMATE_PERCENT =>60   ,DEGREE=>2,GRANULARITY =>'ALL');

今天我照例准备了一下脚本,自己先试一下有没有问题。结果出乎意料报错了。

SQL> exec DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=> 'XXXX', TABNAME => 'XXXXX'                ,CASCADE => TRUE, METHOD_OPT =>'FOR ALL INDEXED COLUMNS SIZE 1', ESTIMATE_PERCENT =>70   ,DEGREE=>2,GRANULARITY =>'ALL');
BEGIN DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=> 'XXXX', TABNAME => 'XXXXX'                ,CASCADE => TRUE, METHOD_OPT =>'FOR ALL INDEXED COLUMNS SIZE 1', ESTIMATE_PERCENT =>70   ,DEGREE=>2,GRANULARITY =>'ALL'); END;


*
ERROR at line 1:
ORA-20000: Unable to analyze TABLE "XXXX"."XXXXX",
insufficient privileges or does not exist
ORA-06512: at "SYS.DBMS_STATS", line 23143
ORA-06512: at "SYS.DBMS_STATS", line 23205
ORA-06512: at line 1

我试着用dba用户来执行,结果还是同样的错误。我怀疑是不是bug了, 结果在metalink上转了一圈,有过类似的bug,但在11.2版本都修复了。 最后有一篇文章。Doc ID 1315184.1

CAUSE

Analyze operations against the XDB schema require the 'analyze any dictionary' privilege.

SOLUTION

Grant the required privilege:

SQL> grant analyze any dictionary to adamb;

果然好使。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-03-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

完美的执行计划导致的性能问题(r4笔记第17天)

今天现场的开发同事反馈有一个job处理数据的速度很慢,从半夜2点开始运行,结果到了早上8点还没有运行完,最后无奈kill掉了进程。等我刚到公司,他们想让我查查倒...

3137
来自专栏杨建荣的学习笔记

MySQL反连接的优化总结(r10笔记第51天)

今天同事有一个环境发现一条语句执行时间很长,感到非常奇怪。刚好有些时间,就抽空琢磨了下这个问题。 总体来看这个环境还是相对比较繁忙的,线程大概是200多个。 #...

3057
来自专栏数据和云

实战课堂:数据库高Library Cache Lock导致Hang的故障分析

编辑手记:在现实的生产环境中,DBA可能遭遇到各种各样的异常,或简单、或复杂,但是无一不考验DBA的经验和能力,在『实战课堂』栏目中,我们将整理和分享来自云和恩...

882
来自专栏杨建荣的学习笔记

一条全表扫描sql语句的分析 (r4笔记第32天)

今天在对生产系统做监控的时候,发现一个process的cpu消耗很高,抓取了对应的session和执行的sql语句。 发现是一个简单的update语句,这样一条...

3309
来自专栏后端技术探索

mysql 水平分表的几种方法

当一张的数据达到几百万时,你查询一次所花的时间会变多,如果有联合查询的话,我想有可能会死在那儿了。分表的目的就在于此,减小数据库的负担,缩短查询时间。

642
来自专栏后端技术探索

mysql 水平分表的几种方法

当一张的数据达到几百万时,你查询一次所花的时间会变多,如果有联合查询的话,我想有可能会死在那儿了。分表的目的就在于此,减小数据库的负担,缩短查询时间。

1402
来自专栏杨建荣的学习笔记

MySQL 5.5迁移到5.7的性能问题排查案例

最近和同事排查了一个MySQL的SQL性能问题。问题的背景是有一个业务的数据库从MySQL 5.5迁移到了MySQL 5.7,原来在5.5中有一个SQL...

742
来自专栏杨建荣的学习笔记

关于等待事件"read by other session"(r3笔记第89天)

在查看数据库负载的时候,发现早上10点开始到12点的这两个钟头,系统负载异常的高。于是抓取了一个awr报告。 Snap IdSnap TimeSessions...

2679
来自专栏数据和云

MySQL:由USE DB堵塞故障引发的思考

遇到故障,我们往往想的是如何解决这个故障,而不是从故障的根本去思考出现这个故障的原因?这样的结果,只能使我们得到了鱼,失去了渔。今天,我们就来分享一个由USE ...

2845
来自专栏数据和云

实战演练:洞若观火--治堵之道在清源

堵塞往往是一件可怕的事情,交通堵塞让人心烦意乱,水道堵塞城市就会臭气冲天,言路堵塞则是非难辨。数据库出现会话堵塞,则很可能造成系统业务中断,这对于 DBA 来说...

1005

扫码关注云+社区