这是2014年写的一篇文章(http://blog.csdn.net/bisal/article/details/18910785#reply)，看了一下，当时的实验和说明是，
收集统计信息可以用dbms_stats包，通常用这样的语法：exec dbms_stat.gather_table_stats(ownname=>'xxx', tabname=>'xxx', estimate_percent=>xxx, method_opt=>'xxx', cascade=>xxx);
本站文章除注明转载/出处外，均为本站原创，转载前请务必署名,转载请标明出处
收集数据库的统计信息是dba工作的一部分，如果在数据快速增长的库上，统计信息如果收集的频率太慢，会对执行计划有一定的影响。 而对于逐渐客户饱和的系统来说，统计信息就可以很长时间收集或者尽量不收集。 对于统计信息的收集，如果是很大的表，收集100%也是不现实的，如果收集的百分比太小，统计信息又失真，对系统系统无疑是雪上加霜。 以上是我采用的方式，不一定对，可以参考。如果表的大小超过30G，算是很大的表了，统计信息的收集比例在30%到40%之间，我给了40%。以下类似。 巨型表(>30G),
确定成功收集统计信息后，发现还是没有效果，在当时操作过程中认为收集统计信息后，oracle没有走上正确的索引就是成本优化器判断错误，于是决定手工绑定走错索引的sql，这也是一般的处理思路，如下示：
既然找到了一个方向，接下里我们验证下，我们将degree 设为1 ，这样就不使用并行了
默认情况下，数据库会为列收集基本统计信息，但不会收集直方图信息。Oracle通过指定DBMS_STATS的METHOD_OPT参数来创建直方图。METHOD_OPT参数可以接受如下的输入值：
原文链接 http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-bp-for-stats-gather-12c-1967354.pdf 译者 刘金龙 导 语 Oracle优化器会为SQL语句产生所有可能的访问路径（执行计划），然后从中选择一条COST值最低的执行路径，这个cost值是指oracle估算执行SQL所消耗的资源。为了让优化器能够精确计算的每一条执行计划的COST值，这就需要被执行SQL语句所需访问的所有对象（表和
最近有位朋友，要做一个T级别的数据迁移工作，打算使用数据泵，这个工具提供了非常多的参数，为的就是控制导入导出的过程。
环境：Oracle 11.2.0.4 采用并行的方式，快速收集全库统计信息，多用于跨版本升级之后，对全库的统计信息重新进行快速收集：
SQL> create table TBL_STAT as select * from dba_objects where 1<>1; Table created. SQL> create index idx_tbl_stat on tbl_stat (object_id); Index created. SQL> select count(*) from tbl_stat; COUNT(*) ---------- 0
有朋友问了我如下这样一个问题，最后的解决过程挺有意思的，让我发现了直方图统计信息里我之前没有注意到的两个知识点，这里跟大家分享一下。 问题 数据库的版本是11.2.0.3： 创建一个测试表T1： SQ
这是个终极问题，因为优化本身的复杂性实在是难以总结的，很多时候优化的方法并不是用到了什么高深莫测的技术，而只是一个思想意识层面的差异，而这些都很可能连带导致性能表现上的巨大差异。 所以有时候我们应该先搞清楚需求到底是什么，SQL本身是否合理，这些思考很可能会使优化工作事半功倍。而本文是假设SQL本身合理，从Oracle提供给我们的一些技术手段来简单介绍下Oracle数据库，该如何使用一些现有的技术来优化一个SQL执行的性能。 确定需要优化的SQL文本及当前SQL执行计划 确定SQL涉及的所有表及其索引的相
安装测试环境可以使用博主编写的 Oracle 一键安装脚本，同时支持单机和 RAC 集群模式！
编辑手记：在前一段，一篇智能数据库优化的论文引起广泛的关注，其实在 Oracle 数据库中，已经引入了大量自动化和智能化的方法去进行自动调节，包括在 SQL 层面的智能诊断分析和建议。 张大朋（L
Oracle中number数据类型存储的是整型，碰巧看到这篇文章讲解了通过分析索引了解0和1的存储机制，值得学习一下。
我认为Oracle最重要、最核心、智能化程度最高的技术之一，就是优化器。他决定了一条SQL，在现有条件下，用什么执行计划，是最优的。有高人说过“Oracle中80%的性能问题都是来自SQL语句”，因此，优化器的好坏，一定程度上就决定了SQL语句的执行效率，进而影响整个数据库的性能。
某数据库由于整体统计信息不准确，多次出现部分业务SQL选错执行计划，从而导致性能下降影响到最终用户体验，目前通过SQL_PROFILE绑定执行计划临时解决，但此方法不够灵活，后续维护工作量也会增加。 Oracle优化器（CBO）依赖数据库统计信息来计算目标SQL各种可能的执行路径的成本，并从中选择一条成本值最小的执行路径来作为目标SQL的执行计划。如果统计信息不准确甚至是错误，会导致优化器选择错误SQL执行计划的概率大大增加。 目前计划对该数据库统计信息进行重新收集，因为生产环境的复杂性，不排除重新收集正确的统计信息后，整体性能反而下降的情况。故而在收集之前需要对原有的统计信息做好备份，如发现收集后性能反而下降的极端情况，也可以快速回退到原有的统计信息。
在Oracle数据库中判断得到的执行计划是否准确，就是看目标SQL是否被真正执行过，真正执行过的SQL所对应的执行计划就是准确的，反之则有可能不准，因此，通过10046事件及如下的几种方式得到的执行计划是最准确的，而从其它方式获取到的执行计划都有可能不准确。
思路： 关联的表数据量都很大，获取一次数据时间较长，可以考虑将数据一次性捞出来放到临时表中，只执行一次耗时取数据的查询，放到临时表中，然后通过游标获取临时表中的数据，去对应的表中删除。 同时考虑到业务高峰期，job执行尽量避开业务高峰期。
第13章 数据库索引选项 练习 13.1 调查你当前使用的DBMS版本关于索引的限制和高级选项。 .索引行压缩与异常情况 MySQL支持 Oracle支持 MySQL使用NULL值实现索引行压缩。但不推荐在实际中使用NULL来代替一个特定的值，因为从长远来看，这可能会导致应用系统错误。
在一条SQL语句中，当使用索引时，cosistent gets 减少，而cost增加。理论上在稳定后的执行计划中，physical reads为零值的前提下， cost应当相应减少。下面来看看其原由。
为了便于建立性能良好的PL/SQL程序，Oracle提供了大量的系统包供使用。Oracle提供的这些包扩展并增强了数据库的一些功能，以及突
导读：笔者早年间从事了多年开发工作，后因个人兴趣转做数据库。在长期的工作实践中，看到了数据库工作（特别是SQL优化）面临的种种问题。本文通过几个案例探讨一下SQL优化的相关问题。
墨墨导读：众所周知，数据库升级、转换、迁移是数据库运维必备的日常技能，本文详细介绍一则将DB2数据库转换成Oracle数据库的案例，希望对大家有帮助。
Oracle优化器对于基数值的估算是否准确关系到能否生成最优的执行计划，而基数值估算的准确性又取决于SQL中各个对象的统计信息是否完整、是否能真实反映出对象的数据分布情况。因此使用何种方法收集统计信息是很有讲究的：对于数据倾斜度较大的表需要收集直方图，在此基础上如果有多个列存在相关性，那么多列统计信息（也叫扩展统计信息）收集又是一个更好的选择。
作者 | 罗贵林： 云和恩墨技术工程师，具有8年以上的 Oracle 数据库工作经验，曾任职于大型的国家电信、省级财政、省级公安的维护，性能调优等。精通 Oracle 数据库管理，调优，问题诊断。擅长 SQL 调优，Oracle Rac 等维护，管理。
最近BI同事反馈说一张表的数据查询非常慢，这个表数据总共不到1W行数据，这么一说我们首先想到的是高水位带来的性能问题，即高水位线下占用过多数据块，而这些数据块其实是部分数据占用，大多数是空闲的数据块。
在Oracle中，什么是基数（Cardinality）和可选择率（Selectivity）？
Oracle 10g之后的优化器支持两种模式，一个是normal模式，一个是tuning模式。在大多数情况下，优化器处于normal模式。基于CBO的normal模式只考虑很小部分的执行计划集合用于选择哪个执行计划，因为它需要在尽可能短的时间，通常是几秒或毫秒级来对当前的SQL语句进行解析并生成执行计划。因此并不能保证SQL语句每次都是使用最佳的执行计划。而tuning模式则将高负载的SQL语句直接扔给优化器，优化器来自动对其进行详细的分析，调试并给出建议，这就是Oracle 提供的Automatic Tuning Optimizer，即自动调整优化器。Oracle 自动调整优化器通过SQL调优建议器(SQL tuning advisor)来体现。
对于索引的调整，我们可以通过Oracle提供的索引监控特性来跟踪索引是否被使用。尽管该特性并未提供索引使用的频度，但仍不失为我们参考的方式之一。然而，最近在Oracle 10.2.0.3中发现收集统计信息时导致索引也被监控，而不是用于sql查询引发的索引监控。如此这般，索引监控岂不是鸡肋？
都还有很多啊, 但是data表空间使用率很高(超过了95%), 但是还剩几百GB呢. 登录服务器查看日志(tail -100f $ORACLE_BASE/diag/rdbms/ddcw/ddcw/trace/alert*.log)报错大概如下:
对“select owner, object_id, object_name from t where object_id=200000”这个sql定义调整任务：
前面给大家介绍了 过滤线粒体基因表达过高的细胞 基础版。今天给大家分享下进一步优化的代码(文中示例数据可在基础版推文找到)。
崔华，网名 dbsnake Oracle ACE Director，ACOUG 核心专家 编辑手记：感谢崔华授权我们独家转载其精品文章，也欢迎大家向“Oracle”社区投稿。 这里我们稍微讨论一下CBO对于Cost值相同的索引的选择，可能会有朋友认为在同样Cost的情况下，Oracle会按照索引名的字母顺序来选择索引，实际上并不完全是这样，CBO对于Cost值相同的索引的选择和Oracle的版本有关。 原理说明 MOS上文章“Handling of equally ranked (RBO) or cos
在使用CBO优化器模式的Oracle数据库中，统计信息是CBO生成最佳执行计划的重要依据。这些统计信息通常包括列级、表级、索引、系统级别的统计信息等。所有的这些统计信息都可以被备份，导入导出也可以被锁定与解锁。因此相应地，我们可以导出列级、表级、索引、系统级别的统计信息。通过导出导入统计信息，可以在测试环境来模拟产生环境进行数据库性能优化，SQL调优等。本文主要描述了基于schema级别导出导入统计信息到不同的数据库。
今天客户反馈某一个应用部署补丁的时候，执行了一个脚本一个多小时还没有执行完。 语句是下面这样的形式。 insert into em1_rater_00068_01 (select * from em1_rater_00050_01_backup a where a.record_id <= 65971543 and not exists (select b.record_id from em1_rater_00068_01 b
众所周知 ，列的直方图主要用于针对数据倾斜的情况，能帮助数据库更准确的了解数据的分布情况，从而选择更高效的执行计划。
因为损坏细胞和死细胞常表现出过大量的线粒体污染，因此需要过滤高线粒体基因表达的细胞。过滤原则为，移去线粒体基因表达比例过高的细胞，但是不能大量丢失样本细胞信息。
嘉宾介绍： 在SQL优化中，除了可以通过修改参数的方式干预优化器工作外，还可以使用提示的方式进行干预，而且这种方式更加精准、不影响其他SQL，故使用场景更加广泛。 1. ALL_ROWS 说明： AL
estimate_noise estimate_noise — Estimate the image noise from a single image.
目前所有使用Oracle作为数据库支撑平台的应用，大部分是数据量比较庞大的系统，即表的数据量级一般情况下都是在百万级以上。当然，在Oracle中创建分区是一种不错的选择，但是当发现应用有多张表关联的时候，并且这些表大部分都比较庞大，而关联的时候发现其中的某一张或者某几张表关联之后得到的结果集非常小，并且查询得到这个结果集的速度非常快，那么这个时候考虑在Oracle中创建“临时表”。
Bind Peeking是Oracle 9i中引入的新特性，一直持续到Oracle 10g R2。它的作用就是在SQL语句硬分析的时候，查看一下当前SQL谓词的值 ，以便生成最佳的执行计划。而在oracle 9i之前的版本中，Oracle 只根据统计信息来做出执行计划。
这个全球生态系统动态调查（GEDI）L4B产品提供了基于从2019-04-18开始的第19任务周到2021-08-04结束的第138任务周的观测结果的1公里×1公里平均地上生物量密度（AGBD）的估计值。GEDI L4A足迹生物量产品将每个高质量的波形转换为AGBD预测，而L4B产品使用每个1公里单元边界内存在的样本来统计推断平均AGBD。
建库(一般习惯配置gdbname与sid名一样，sys密码与system密码一样，以方便记忆)
（1）oracle11g建库(一般习惯配置gdbname与sid名一样，sys密码与system密码一样，以方便记忆)
全表扫描成本作为参照物，用于和表的其它访问方式的成本做对比。任何一种访问方式，只要成本超过了全表扫描成本，就不会被使用。
崔华，网名 dbsnake Oracle ACE Director，ACOUG 核心专家 如何查看一个sql的真实执行计划呢？用dbms_xplan.display_cursor(‘hash_value’,‘child_number’, 'advanced')是其中的一种很重要的方法。 我负责的一个库，在移植了大量数据后，跑最后一个运维作业的时候这个运维作业始终阻塞在这样的一个sql上： update saldat setsdaprs ='C',sdatno = :4 where
今天凌晨，又被电话叫醒了，说是有1个sql，现在跑的很慢。问题已经挺严重了，想让我看看，能不能做点什么。 首先就是和他们确认最近有什么改动，他们说这个是用了很久的sql语句了，没有任何的改动，再听他们说，之前也没有任何的问题。 然后就和他们确认之前这个jobl处理大概多长时间，那个哥们说他也是最近才进的这个项目，可能数据量不同，他也不清楚。但是他肯定的说这个job会跑的很快，几个小时肯定能处理完。 大概了解了下，他们也确定具体的sql语句是什么，没有得到太多的信息，首先通过top命令来抓一下目前消耗资源比
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
