Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

73

积分

0

好友

0

主题
1#
发表于 2012-4-9 14:14:34 | 查看: 9026| 回复: 5
我们一个重要业务系统有一张分区大表,光基表就超过200G,同时还带着很多索引,因此,对这张表的统计分析非常耗时,每次需时超过3天,因此不能经常分析;但同时,这张表的变化量又很大,每天变化量超过8%,因此,无论我怎么设置stale_percent参数,都会让表很快过期,而一旦表过期,这个动作会引发我们业务系统严重的硬解析。因此,如今最好的办法是让表不过期,而我则择机进行周期性统计分析。这样,虽然执行计划依旧可能有问题,但也比现在因为担心硬解析而一直不分析强。

我的难题是:有没有什么好的办法,让表的统计信息永不失效呢?

注:表的统计信息可以不准,但是不能stale。

我的环境:Oracle 11.2.0.2

[ 本帖最后由 ccshu 于 2012-4-9 14:47 编辑 ]
2#
发表于 2012-4-9 14:52:29
锁住 表的统计信息。。。

sql 加hint

回复 只看该作者 道具 举报

3#
发表于 2012-4-9 14:54:14
原帖由 psufnxk2000 于 2012-4-9 14:52 发表
锁住 表的统计信息。。。

sql 加hint


锁住表的统计信息,表依旧会stale,这个我已经测试通过了。

由于SQL是应用自动生成的,无法通过hint解决,对此我很恼火, 也很无奈。

回复 只看该作者 道具 举报

4#
发表于 2012-4-9 15:00:59
可以通过  DBMS_STATS.LOCK_TABLE_STATS 来做。

回复 只看该作者 道具 举报

5#
发表于 2012-4-9 15:27:54
你的目的是锁定sql execution plan,而不应该是statistics, 可以考虑baseline,outline呢

[ 本帖最后由 anbob 于 2012-4-9 15:35 编辑 ]

回复 只看该作者 道具 举报

6#
发表于 2012-4-9 16:54:05
"一旦表过期,这个动作会引发我们业务系统严重的硬解析。"


Prior to Oracle 10g, automated collection of statistics for objects that had become stale was controlled by the setting of the MONITORING flag on table.

Depending on the MONITORING flag, the GATHER_STATS_JOB job collected "GATHER EMPTY" and "GATHER STALE"
on the flagged objects.


Whenever there is 10% change in data in a table, Oracle considers its statistics to be stale.

Up to date statistics are important to generate good execution plans. Automatic statistics collection job using DBMS_STATS
packages depend on the monitoring data to determine when to collect statistics on objects with stale statistics.

Prior to Oracle11g, the staleness threshold is hardcoded at 10%. This means that an object is considered stale if the number of rows inserted,updated or deleted since the last statistics gathering time is more than 10% of the number of rows. There is no way to modify this value prior to Oracle 11g.
Starting with Oracle11g, the staleness threshold can be set using the STALE_PERCENT statistics preference. This can be set globally using DBMS_STATS.SET_GLOBAL_PREFS or at the table level using DBMS_STATS.SET_TABLE_PREFS.


statistics 的stale 并不会导致 当前的statistics 立即失效, 也不会 直接(directly)导致 SQL需要重新硬解析。

stale 状态只是告诉 DBMS_STATS package 这些 陈旧统计信息的对象 存在 重新收集 collect statistics的需求。

在10g中 这个stale percent 是hard coding的 为10%, 在11g中可以通过 STALE_PERCENT来定义。


stale 的statistics 不代表这个statistics是失效的invalid的, 不代表相关的SQL 就一定需要再次hard parse 。

反而某些DDL操作会导致 statistics直接invalid 失效, 例如分区表 split partition时 相关分区的统计信息必须失效,即使你尝试lock 这些statistics也不能避免这种失效, 这也将导致 SQL cursor 的 hard reparse 。




可以通过 设置 [size=-1]STATISTICS_LEVEL 为BASIC来 disable 禁用SMON 更新 [size=-1]DBA_TAB_MODIFICATIONS视图相关的基表  详见 了解你所不知道的SMON功能(九):维护MON_MODS$字典基表 http://www.oracledatabase12g.com ... stics-mon-mods.html

但是使用BASIC的 [size=-1]STATISTICS_LEVEL 会导致 AWR、ASH、ADDM、ASMM等10g以后的特性不可用

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-24 11:03 , Processed in 0.050473 second(s), 21 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569