关于 dbms_stats.gather_table_stats 的问题
我只是有一个关于 dbms_stats.gather_table_stats 的简单问题。在我们的应用程序中，该语句在为表创建索引后立即发生。它被称为
EXEC DBMS_STATS.GATHER_TABLE_STATS(< schemaname >, < tablename >)I just have a simple question regarding dbms_stats.gather_table_stats. In our application this statement occurs just after creating the index for the table. It is called as
EXEC DBMS_STATS.GATHER_TABLE_STATS(< schemaname >, < tablename >)
.
We are using Oracle 10.2g. Now question is when will exactly the information will be gathered? Will it be gathered on every update of table, or when some criteria is satisfied? Or is it that it will be gathered only when you call gather_table_stats again?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
除了 Gary 的好答案之外，在默认 10g 数据库上运行统计信息的 GATHER_STATS_JOB 计划任务默认配置为在两个“维护窗口组”期间运行，即 WEEKEND_WINDOW 和 WEEKNIGHT_WINDOW。前者于周六 00:00 开始，运行 48 小时，后者于每个工作日晚上 10 点开始，运行 8 小时。除非您更改计划或窗口，否则您的统计作业只能在这些时间内运行。这些窗口可能适合也可能不适合您的环境。
In addition to Gary's good answer, the GATHER_STATS_JOB scheduled task that runs the stats on the default 10g databases is configured by default to run during two "maintenance window groups", which are WEEKEND_WINDOW and WEEKNIGHT_WINDOW. The former starts at 00:00 Saturday and runs for 48 hours, the latter starts at 10pm each weeknight and runs for 8 hours. Your stats jobs can only run during those times unless you change the schedule or the windows. Those windows may or may not be good in your environment.
调用包时会收集统计信息（并且在收集完成之前包不会返回）。
通常，有一个自动作业将收集现有统计信息已消失的统计信息 '过时'。已选择进行监视的表将在插入/删除/更新时记录一些额外的数据（通过 dba_tab_modifications 可见）。
当 10% 的行已更改时，统计信息将“过时”，并将在下一次自动作业期间重新收集。检查 DBA_JOBS 以查看您的数据库是否/何时配置为收集过时表的统计信息（提示 - 避免在大量使用期间执行此操作）。
The stats are gathered when the package is called (and the package won't return until the gathering is complete).
Typically there is an automatic job that will gather stats where existing stats have gone 'stale'. Tables that have been selected for monitoring will have some extra data logged on inserts/deletes/updates (visible through dba_tab_modifications).
When 10% of rows have been changed, the stats are 'stale' and will be re-gathered during the next automatic job. Check DBA_JOBS to see if/when your database is configured to gather stats on stale tables (hint - avoid doing it during a heavy usage time).