首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

每次创建索引以便Oracle优化器使用它时,是否需要运行gather_table_stats?

在Oracle数据库中,每次创建索引以便优化器使用它时,并不需要运行gather_table_stats。gather_table_stats是用于收集表统计信息的过程,包括表的行数、块数、列的数据分布等。它的目的是为了帮助优化器生成最优的执行计划。

创建索引时,Oracle会自动收集索引的统计信息,包括索引的高度、选择性等。这些统计信息会被优化器用来评估索引的成本和选择最佳的执行计划。

然而,如果在创建索引后对表的数据进行了大量的修改(如插入、更新、删除操作),那么索引的统计信息可能会变得过时。这时候,可以使用gather_table_stats来手动收集表的统计信息,以保证优化器的准确性和性能。

在腾讯云的产品中,可以使用TencentDB for Oracle来管理和优化Oracle数据库。TencentDB for Oracle提供了自动收集统计信息的功能,可以定期收集表和索引的统计信息,以保证查询的准确性和性能。您可以通过以下链接了解更多关于TencentDB for Oracle的信息:TencentDB for Oracle产品介绍

总结:每次创建索引以便Oracle优化器使用它时,并不需要运行gather_table_stats。但是如果对表的数据进行了大量的修改,可以使用gather_table_stats来手动收集表的统计信息,以保证优化器的准确性和性能。在腾讯云的产品中,可以使用TencentDB for Oracle来管理和优化Oracle数据库。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • Oracle 10g收集数据库统计信息

    某数据库由于整体统计信息不准确,多次出现部分业务SQL选错执行计划,从而导致性能下降影响到最终用户体验,目前通过SQL_PROFILE绑定执行计划临时解决,但此方法不够灵活,后续维护工作量也会增加。 Oracle优化器(CBO)依赖数据库统计信息来计算目标SQL各种可能的执行路径的成本,并从中选择一条成本值最小的执行路径来作为目标SQL的执行计划。如果统计信息不准确甚至是错误,会导致优化器选择错误SQL执行计划的概率大大增加。 目前计划对该数据库统计信息进行重新收集,因为生产环境的复杂性,不排除重新收集正确的统计信息后,整体性能反而下降的情况。故而在收集之前需要对原有的统计信息做好备份,如发现收集后性能反而下降的极端情况,也可以快速回退到原有的统计信息。

    01

    【DB笔试面试628】Oracle的统计信息包括哪几种类型?

    Oracle数据库里的统计信息是一组存储在数据字典里,且从多个维度描述了数据库里对象的详细信息的一组数据。当Oracle数据库工作在CBO(Cost Based Optimization,基于代价的优化器)模式下时,优化器会根据数据字典中记录的对象的统计信息来评估SQL语句的不同执行计划的成本,从而找到最优或者是相对最优的执行计划。所以,可以说,SQL语句的执行计划由统计信息来决定,若没有统计信息则会采取动态采样的方式来生成执行计划。统计信息决定着SQL的执行计划的正确性,属于SQL执行的指导思想。若统计信息不准确,则会导致表的访问方式(例如应该使用索引,但是选择了全表扫描)、表与表的连接方式出现问题(例如应该使用HJ,但是使用了NL连接),从而导致CBO选择错误的执行计划。

    02

    Oracle 历史SQL语句执行计划的对比与分析

    基于CBO优化器的环境中,SQL执行计划的生成依赖于统计信息的真实与完整。如列的离散度,列上的直方图,索引的可用性,索引上的聚簇因子。当这些信息是真实完整的情况下,CBO优化器通常都可以制定最优的执行计划。也正因此CBO优化器也灵活,难以控制,任一信息的不真实或缺失都可能导致执行计划发生变化而产生多个版本。经常碰到的情形是之前的某个SQL语句前阵子还不是TOP SQL,而最近变成了TOP SQL。或者说之前尽管是TOP SQL但,但最近尽然成了TOP 1。对于此情形,我们可以比对SQL语句的历史执行计划进行分析是何种原因导致SQL变慢或执行计划发生变化。下面通过例子来模拟SQL执行计划变异的情形。 1、创建演示环境

    01

    最近的几个技术问题总结和答疑(九)(r10笔记第16天)

    最近的琐事比较多,而提问题的朋友还是不少,很多消息都没有来得及回复,各种事情一堆起来,不少问题想起来已经过了好几天了,所以还是来整理一篇技术问答为好。 首先是很多朋友问我关于半自动化搭建Data Guard的脚本,我写了几篇文章来介绍思路,自己也提了不少的改进,团队内部也沟通过了,一直迟迟没有发布出来是因为我觉得目前的实现方式可能对于我的工作能够极大提高,但是很多朋友使用的环境可能没有中控的概念,所以不是很通用,所以我想做一些改变,还有一个是里面的有些逻辑我想改改,至少简化一下。但是一直是思想的前行

    04

    【DB笔试面试553】在Oracle中,什么是不可见索引?

    索引维护是DBA的一项重要工作。当一个系统运行很长一段时间,经过需求变更、结构设计变化后,系统中就可能会存在一些不再被使用的索引,或者使用效率很低的索引。这些索引的存在,不仅占用系统空间,而且会降低事务效率,增加系统的负载。因此,需要找出那些无用或低效的索引,并删除它们(找出无用索引可以通过索引监控的方法)。但是,直接删除索引还是存在一定风险的。例如,某些索引可能只是在一些周期的作业中被使用到,而如果监控周期没有覆盖到这些作业的触发点,那么就会认为索引是无用的,从而将其删除。当作业启动后,可能就会对系统性能造成冲击。这时,可能就会手忙脚乱地去找回索引定义语句、重建索引。在Oracle 11g里,Oracle提供了一个新的特性来降低直接删除索引或者禁用索引的风险,那就是不可见索引(Invisible Indexes)。

    02
    领券