随着应用数据的增多和表量的增加,为了增加统计信息收集的效率,Oracle推出了并行和并发收集统计信息的方法。
默认情况下,数据库会为列收集基本统计信息,但不会收集直方图信息。Oracle通过指定DBMS_STATS的METHOD_OPT参数来创建直方图。METHOD_OPT参数可以接受如下的输入值:
有朋友问了我如下这样一个问题,最后的解决过程挺有意思的,让我发现了直方图统计信息里我之前没有注意到的两个知识点,这里跟大家分享一下。 问题 数据库的版本是11.2.0.3: 创建一个测试表T1: SQ
原文链接 http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-bp-for-stats-gather-12c-1967354.pdf 译者 刘金龙 导 语 Oracle优化器会为SQL语句产生所有可能的访问路径(执行计划),然后从中选择一条COST值最低的执行路径,这个cost值是指oracle估算执行SQL所消耗的资源。为了让优化器能够精确计算的每一条执行计划的COST值,这就需要被执行SQL语句所需访问的所有对象(表和
A. They are gathered by the Manageability Monitor(MMON) background process.
原文链接 http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-bp-for-stats-gather-12c-1967354.pdf 译者 胡红伟 虽然优化器需要准确的统计信息来选择最优的执行计划,但是有些场景下,收集统计信息比较困难,或消耗资源较高,或收集统计信息不能及时完成,那么就需要另一种备选策略。 不稳定的表 不稳定的表即随着时间的变化,数据会发生巨大变化的表。例如,一个订单队列表,一天的开始它是空的,随着时间推移,订
在Oracle的11g版本中,统计信息为自动收集功能,在部署安装11g Oracle软件过程中,其中有一个步骤便是提示是否启动这个功能(默认是启用这个功能);且有时候在生产环境中,还会对一些对象做手动统计信息的搜集,如果新搜集的统计信息产生的执行计划在实际生产中不符和生产要求,则需继续使用原有的执行计划。
原文链接 http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-bp-for-stats-gather-12c-1967354.pdf 译者 杨禹航 何时收集统计信息 为了选择最佳执行计划,优化器必须可以获得有代表性的统计信息。有代表性的统计数据不必是最新的,而是一组能够帮助优化器确定执行计划中每个操作所能返回的行数。 自动统计信息收集任务 Oracle会在预定义维护窗口期间 (工作日10pm 到2am 和周末6am 到2am
从 Oracle 到 PostgreSQL :从 Uptime 到数据库实例运行时间
存在缺失和陈旧的统计信息的表、索引和分区会被收集。当自动收集任务运行时,优先收集缺失统计信息的对象,然后再收集陈旧统计信息的对象。可以从DBA_TAB_STATISTICS和DBA_IND_STATISTICS这两个视图中查询缺失或陈旧统计信息的对象。“LAST_ANALYZED IS NULL”表示统计信息缺失,“STALE_STATS='YES'”表示统计信息陈旧。当表或分区的数据变化量超过10%时,该对象的统计信息变为陈旧。
Oracle数据库的性能视图几乎可以说是最引以为骄傲的功能,在那样细粒度的采样统计强度下,依然保持卓越的性能,基于这些性能数据采样之后形成的AWR,更是Oracle DBA分析数据库性能问题的最重要手段之一。
对于大表的统计信息收集可以通过DEGREE参数使得扫描大表的时候进行并行扫描,从而加快扫描速度,缩短了收集统计信息的时间。但是,即使加了DEGREE参数,在收集统计信息的时候,还是进行一个表一个表的扫描,并没有并发的同时扫描多个表。在Oracle 11.2.0.2之后,有了一个参数,可以并发扫描表,这就是CONCURRENT参数。可以通过以下SQL语句查询数据库是否启用了CONCURRENT收集统计信息,默认为FALSE,表示没有开启并发收集统计信息:
在Oracle中,自动收集统计信息的机制有哪些?10g和11g在自动收集统计信息方面有哪些区别?
高效诊断性能问题,需要提供完整可用的统计信息,好比医生给病人看病的望闻问切,才能够正确的确诊,然后再开出相应的药方。Oracle数据库为系统、会话以及单独的sql语句生成多种类型的累积统计信息。本文主要描述Oracle性能统计涉及到的相关概念及统计对象,以更好的利用统计信息为性能调整奠定基础。
3.Oracle在执行IN子查询时,首先执行子查询,将查询结果放入临时表再执行主查询。而EXIST则是首先检查主查询,然后运行子查询直到找到第一个匹配项。NOT EXISTS比NOT IN效率稍高。但具体在选择IN或EXIST操作时,要根据主子表数据量大小来具体考虑。
在oracle9i中,默认的统计信息收集是不收集直方图信息的,也就是说默认的MOTHOD_OPT模式为FOR ALL COLUMNS SIZE 1
该系列专题为2018年4月OCP-052考题变革后的最新题库。题库为小麦苗解答,若解答有不对之处,可留言,也可联系小麦苗进行修改。
最近,Oracle数据库优化器的产品经理 Nigel Bayliss 发布了一篇文档,介绍:Setting up the Oracle Optimizer for PoCs - 在PoC测试中优化器参数的设置和调节。优化器是 Oracle 数据库的核心组件,我们一起来看一看 12c 有哪些优化器的变化。
① 当某个分区的数据变化达到10%,自动收集统计信息任务运行时,Oracle会更新该分区的统计信息。
最近有位朋友,要做一个T级别的数据迁移工作,打算使用数据泵,这个工具提供了非常多的参数,为的就是控制导入导出的过程。
A. AWR data is stored in the SYSTEM tablespace.
优化器(Optimizer )是Oracle数据库最重要的部件之一,随着Oracle数据库每个新版本的发布,优化器都会得到增强并追加一些新功能,本文将针对各个版本出现的新特性背景和发展进行简单介绍.
前几天,微信上收到《Oracle DBA工作笔记》、《MySQL DBA工作笔记》作者,DBAplus社群联合发起人杨建荣老师的邀请,说在他的 QQ 群里分享一下技术类、职场类、感悟类的文章,我顿时感到诚惶诚恐,荣幸之至,分享也是一个学习的过程呀,便欣然答应了杨老师的邀请。想着最近也在学习优化相关的东西,那就一边学习一边总结分享,文中如有其它不到之处,还请多多指教。
序言:优化器是Oracle数据库最引人入胜的部件之一,因为它对每一个SQL语句的处理都必不可少。优化器为每个SQL语句确定最有效的执行计划,这是基于给定的查询的结构,可用的关于底层对象的统计信息,以及所有与优化器和执行相关的特性。 本文来自Oracle 白皮书翻译(译者:苏旭辉 newkid),介绍了在Oracle数据库12c第二版中与优化器和统计信息相关的所有新特性并且提供了简单的,可再现的例子,使得你能够更容易地熟悉它们,尤其是当你从早先的版本进行迁移的时候。它还概括了已有的功能是如何被增强以改善性能
① 对于数据量不大的OLTP类型的系统,建议使用自动收集统计信息,并对一些特殊的大表写JOB定时收集统计信息。如果是数据量很大的OLAP或者DSS系统,那么建议DBA自己写JOB脚本来收集统计信息。
崔华,网名 dbsnake Oracle ACE Director,ACOUG 核心专家 编辑手记:感谢崔华授权我们独家转载其精品文章,也欢迎大家向“Oracle”社区投稿。 崔华手记:这篇文章的标题颇有些标题党的味道,但这不是我的初衷。其实我想表达的是,基于RDBMS的应用系统的性能问题绝大多数都是和SQL直接相关,而基于Oracle数据库的SQL优化能否奏效、效果的好与坏归根结底比拼的还是对CBO和执行计划的理解程度,这也正是我在《基于Oracle的SQL优化》一书中提出来的SQL优化方法论的第一点
Oracle数据库中优化器(Optimizer)是SQL分析和执行的优化工具,是Oracle数据库中内置的一个核心模块。优化器的目的就是为了得到目标SQL的执行计划。Oracle数据库里的优化器又分为RBO(rule-Based Optimizer,基于规则的优化器)和CBO(Cost-Based Optimizer,基于成本的优化器)这两种类型。从Oracle 10g开始,Oracle数据库默认都是基于CBO的优化方式。
AWR是Automatic Workload Repository的简称,中文叫着自动工作量资料档案库。既然是仓库,又是保存负载数据,所以保存的是数据库性能相关的数据。即特定数据库或者实例在过去运行期间整个性能表现。AWR能实现性能数据的收集,处理,维护,以及给出调整参考等。这些收集到的数据被定期保存到磁盘,可以从数据字典查询以及生成性能报告等。
1 Oracle AWR 介绍 Oracle Database 10g 提供了一个显著改进的工具:自己主动工作负载信息库 (AWR:Automatic Workload Repository)。 Oracle 建议用户用这个代替 Statspack。AWR 实质上是一个 Oracle 的内置工具。它採集与性能相关的统计数据。 并从那些统计数据中导出性能量度,以跟踪潜在的问题。与 Statspack 不同,快照由一个称为 MMON 的新的后台进程及其从 进程自己主动地每小时採集一次。为了节省空间,採集的数据在 7 天后自己主动清除。
一直有朋友问,是不是表建了索引,一定会使用索引,在RBO时代,访问效率会参考一些规则,优先级高的,认为效率就高,例如索引就比全表扫描效率高,但CBO时代,则会以成本为依据,谁的成本低,谁的效率就高,这样更科学。
2. 索引处于unusable期间,对表数据做DML操作,此时不维护索引。
我认为Oracle最重要、最核心、智能化程度最高的技术之一,就是优化器。他决定了一条SQL,在现有条件下,用什么执行计划,是最优的。有高人说过“Oracle中80%的性能问题都是来自SQL语句”,因此,优化器的好坏,一定程度上就决定了SQL语句的执行效率,进而影响整个数据库的性能。
在使用CBO优化器模式的Oracle数据库中,统计信息是CBO生成最佳执行计划的重要依据。这些统计信息通常包括列级、表级、索引、系统级别的统计信息等。所有的这些统计信息都可以被备份,导入导出也可以被锁定与解锁。因此相应地,我们可以导出列级、表级、索引、系统级别的统计信息。通过导出导入统计信息,可以在测试环境来模拟产生环境进行数据库性能优化,SQL调优等。本文主要描述了基于schema级别导出导入统计信息到不同的数据库。
主要采用DBMS_STATS.GATHER_TABLE_STATS包进行统计信息的收集,如下所示:
Oracle数据库里的统计信息是一组存储在数据字典里,且从多个维度描述了数据库里对象的详细信息的一组数据。当Oracle数据库工作在CBO(Cost Based Optimization,基于代价的优化器)模式下时,优化器会根据数据字典中记录的对象的统计信息来评估SQL语句的不同执行计划的成本,从而找到最优或者是相对最优的执行计划。所以,可以说,SQL语句的执行计划由统计信息来决定,若没有统计信息则会采取动态采样的方式来生成执行计划。统计信息决定着SQL的执行计划的正确性,属于SQL执行的指导思想。若统计信息不准确,则会导致表的访问方式(例如应该使用索引,但是选择了全表扫描)、表与表的连接方式出现问题(例如应该使用HJ,但是使用了NL连接),从而导致CBO选择错误的执行计划。
数据字典(Data Dictionary)也就是通常所说的系统目录,它是Oracle数据库中最重要的组成部分。数据字典记录了数据库的系统信息,它是只读表和视图的集合,数据字典的所有者为SYS用户,所有的数据字典表和视图都被储存在该数据库的SYSTEM表空间中。用户只能在数据字典上执行查询操作,而其维护和修改是由系统自动完成的。数据字典中存放了数据库自身的很多信息,包括了用于描述数据库和它的所有对象的信息,所以,数据字典是每个Oracle数据库的核心。例如一个表的创建者信息,创建时间信息,所属表空间信息,用户访问权限信息等。
熟悉ORACLE数据库的人,对RBO/CBO肯定很熟。 Rule Based Optimizer(RBO)基于规则 Cost Based Optimizer(CBO)基于成本,或者讲统计信息 ORACLE 提供了CBO、RBO两种SQL优化器。CBO在ORACLE7 引入,但在ORACLE8i 中才成熟。ORACLE 已经明确声明在ORACLE9i之后的版本中(ORACLE 10G ),RBO将不再支持。因此选择CBO 是必然的趋势。 RBO自ORACLE 6版以来被采用,有着一套严格的使用规则,只要你按照
一·、前言:这篇博文内容非原创,是我们公司的架构师给我们做技术培训的时候讲的内容,我稍微整理了下,借花献佛。这篇博文只是做一个大概的科普介绍,毕竟SQL优化的知识太大了,几乎可以用一本书来介绍。另外,博主对SQL优化也是刚刚接触,也有很多不了解的地方,说的不对的地方,还请大家指正,共勉! 二、oracle服务器,所谓oracle服务器指的是一个数据库管理系统,它包括一个oracle实例(动态)和一个oracle数据库(静态)。 oracle实例是一个运行的概念,提供了一种访问数据库的方式,由SGA和一些后
本文主要介绍自动统计信息收集(Automatic Optimizer Statistics Collection)任务。
随着2月的春风吹拂,Oracle 19c 的第一个 Exadata 版本发布将马上发布出来,等待可测试版本的朋友们马上即可如愿了。
在看《基于Oracle的SQL优化一书》知道了很多专业名称,做了记录,CBO、优化器、查询转换、执行计划、Hint、并行、游标、绑定变量、统计信息、直方图、索引等等。这篇博客可以说是读书笔记
对于索引的调整,我们可以通过Oracle提供的索引监控特性来跟踪索引是否被使用。尽管该特性并未提供索引使用的频度,但仍不失为我们参考的方式之一。然而,最近在Oracle 10.2.0.3中发现收集统计信息时导致索引也被监控,而不是用于sql查询引发的索引监控。如此这般,索引监控岂不是鸡肋?
使用Oracle数据库的应用系统,有时出现SQL性能突然变差,特别是对于OLTP类型系统执行频繁的核心SQL,如果出现性能问题,通常会影响整个数据库的性能,进而影响整个系统的正常运行。这是常常遇到的问题,也是一些DBA的挑战。 SQL性能变差原因分析 SQL的性能变差,通常是在SQL语句重新进行了解析,解析时使用了错误的执行计划出现的。 下列情况是SQL会重新解析的原因: SQL语句没有使用绑定变量,这样SQL每次执行都要解析。 SQL长时间没有执行,被刷出SHARED POOL,再次执行时需要重新解析。
题图:Hands@Photo by Toa Heftiba on Unsplash
Oracle会自动收集表的统计信息,大部分情况下,这种行为是有利的。当不需要对某个表做收集的时候,可以采用锁定统计信息的方法,把不需要收集的表排除在外,这样可以使得此表上的统计信息不变,如下所示:
在Oracle中,使用SPLIT来拆分某个分区的时候,其拆分出来的新分区的统计信息行数是多少?
t1.c1=t2.c1 and t1.c1=10,Oracle会自动将t2.c1=10的条件添加。
去“IOE”是一个甚嚣尘上的话题,在经年的渲染之后,很多企业都在以各自的方式在进行演绎。 云和恩墨最近帮助用户实施了一个重要的“去I”项目,引用恩墨一线负责人老熊的描述: 2014年5月8日,是一个重要的日子。一个省级电信运营商,将核心的CRM系统Oracle数据库进行了升级迁移,成功地从原来运行在IBM 595平台上的双节点10.2.0.5 RAC数据库,迁移并升级到基于x86+vmware平台的双节点11.2.0.3 RAC数据库上。新平台的服务器成本只有原小型机成本的十分之一。我个人认为是这是一个里
编辑手记:在SQL执行的过程中,选择不同的执行计划所产生的性能差异非常大,因此能够符合业务地选择正确的执行计划非常重要。但在真实环境中,总会受到一些因素的影响,今天我们来分析谓词越界和绑定变量窥探对SQL执行计划的影响。 案例场景 最近有一客户晚上新导入了一批数据到数据库中,第二天发现业务变慢,主要是其中有一条核心业务SQL执行计划走错导致。 结果排查发现客户在导入数据后并未重新收集统计信息,SQL使用绑定变量,窥探的变量刚好是越界,导致SQL第一次硬解析生成的执行计划走错。再加上10G的库导致接下
领取专属 10元无门槛券
手把手带您无忧上云