一直有朋友问，是不是表建了索引，一定会使用索引，在RBO时代，访问效率会参考一些规则，优先级高的，认为效率就高，例如索引就比全表扫描效率高，但CBO时代，则会以成本为依据，谁的成本低，谁的效率就高，这样更科学。
用于决定在Oracle中解析目标SQL时所用优化器的类型，以及决定当使用CBO时计算成本值的侧重点。这里的“侧重点”是指当使用CBO来计算目标SQL各条执行路径的成本值时，计算成本值的方法会随着优化器模式的不同而不同。
在看《基于Oracle的SQL优化一书》知道了很多专业名称，做了记录，CBO、优化器、查询转换、执行计划、Hint、并行、游标、绑定变量、统计信息、直方图、索引等等。这篇博客可以说是读书笔记
2. 索引处于unusable期间，对表数据做DML操作，此时不维护索引。
OPTIMIZER_INDEX_COST_ADJ 这个初始化参数代表一个百分比,取值范围在1到10000之间. 该参数表示索引扫描和全表扫描成本的比较。缺省值100表示索引扫描成本等价转换与全表扫描成本。
Oracle数据库中优化器（Optimizer）是SQL分析和执行的优化工具，是Oracle数据库中内置的一个核心模块。优化器的目的就是为了得到目标SQL的执行计划。Oracle数据库里的优化器又分为RBO（rule-Based Optimizer，基于规则的优化器）和CBO（Cost-Based Optimizer，基于成本的优化器）这两种类型。从Oracle 10g开始，Oracle数据库默认都是基于CBO的优化方式。
优化器是数据库最核心的功能，也是最复杂的一部分。它负责将用户提交的SQL语句根据各种判断标准，制定出最优的执行计划，并交由执行器来最终执行。优化器算法的好坏、能力的强弱，直接决定了语句的执行效率。笔者也使用了其他诸如MySQL、PostgreSQL、SQLServer等关系型数据库。综合比较来说，Oracle的优化器是功能最强大的。学习SQL优化，从本质来讲就是学习从优化器的角度如何看待SQL，如何制定出更优的执行计划。当然，优化器本身是数据库系统中最复杂的一个部分，本书会就优化器的分类、工作原理等做简单介绍，不会深入细节。
大家好，我是陆金所数据库团队的负责人王英杰。这次的分享主要集中在陆金所去O在线换库的技术特点上，之后详细给大家剖析陆金所设计的在线换库方案以及方案如何在一个庞大的金融系统里通过多个团队的紧密配合稳妥落地。
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/bisal/article/details/89666608
原文链接 http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-bp-for-stats-gather-12c-1967354.pdf 译者 胡红伟 虽然优化器需要准确的统计信息来选择最优的执行计划，但是有些场景下，收集统计信息比较困难，或消耗资源较高，或收集统计信息不能及时完成，那么就需要另一种备选策略。 不稳定的表 不稳定的表即随着时间的变化，数据会发生巨大变化的表。例如，一个订单队列表，一天的开始它是空的，随着时间推移，订
编辑手记：Oracle Sharding是为OLTP应用程序定制设计的一种可扩展、支持高可用功能的架构，能够在不具有共享硬件或软件的Oracle数据库池中分发和复制数据。事实上基于高可用和易扩展性开发的系统或数据库架构并不仅仅是Oacle Sharding 一个，我们来通过不同产品的对比来认识，sharding到底强大在哪里。 1、Oracle Sharding与Microsoft Azure弹性数据库的比较 Microsoft提供了一个分片式数据库架构，具有与Oracle Sharding相同的许多目标，
本博客介绍一下属于oracle优化器范畴的一些基础知识，访问数据的方法，分为直接访问数据的方法和访问索引的方法两种，然后有了这些基础知识后，可以参考学习我的另外一篇博客：Oracle优化器简介，对Oracle 的一些原理的简单介绍，对于学习oracle方面的SQL优化是有帮助的，https://blog.csdn.net/u014427391/article/details/87656904
编辑手记：在Oracle数据库中，版本变化带来的一大挑战就是SQL执行计划的稳定性，为此Oracle经历了从Outline到Profile的特性演进，本文带大家一起来了解一下Profile的特性和使用。 SQL Profiles 是 Oracle 10g 引入的一项新特性，并且在11g中被广泛的使用，其核心功能可以说是 Outlines 的进化。Outlines 能够实现的功能 SQL Profiles 也完全能够实现，而 SQL Profiles 具有 Outlines 不具备的优化，个人认为最重要的有2
我认为Oracle最重要、最核心、智能化程度最高的技术之一，就是优化器。他决定了一条SQL，在现有条件下，用什么执行计划，是最优的。有高人说过“Oracle中80%的性能问题都是来自SQL语句”，因此，优化器的好坏，一定程度上就决定了SQL语句的执行效率，进而影响整个数据库的性能。
一.SQL语言的使用 1.IN 操作符 用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。 但是用IN的SQL性能总是比较低的，从Oracle执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别： ORACLE试图将其转换成多个表的连接，如果转换不成功则先执行IN里面的子查询，再查询外层的表记录，如果转换成功则直接采用多个表的连接方式查询。 由此可见用IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功，但对于含有分组统计等方面的SQL就不能转换了。
本文会分享陆金所在线换库的全过程，详细剖析陆金所设计的在线换数据库方案，整套方案又是如何在一个复杂庞大的金融系统里，通过多团队紧密配合稳妥落地。希望阅读本文之后，能够让大家深入了解金融核心系统去 Oracle 的难点和风险，并给想去 Oracle 但是不敢落地实施的同学提供真正的实战案例解决思路。
作者介绍 郭成日 云和恩墨北区技术工程师 专注于SQL审核和优化相关工作。曾经服务的客户涉及金融保险、电信运营商、政府、生产制造等行业。 在优化器进行查询转换的时候，如果将内嵌视图里推入连接谓词，视
文章来源：https://severalnines.com/database-blog/battle-nosql-databases-comparing-mongodb-and-oracle-nosql
作者简介： 刘晨，网名bisal，Oracle 10g/11g OCM，并国内首批Oracle YEP成员， 博客：blog.itpub.net/bisal 案例介绍 今天快下班的时候，几位兄弟来聊一
在Oracle数据库中，CBO会默认认为目标列的数据在其最小值（LOW_VALUE）和最大值（HIGH_VALUE）之间是均匀分布的，并且会按照这个均匀分布原则来计算对目标列施加WHERE查询条件后的可选择率以及结果集的Cardinality，进而据此来计算成本值并选择执行计划。但是，目标列的数据是均匀分布这个原则并不总是正确的，在实际的生产系统中，有很多表的列的数据分布是不均匀的，甚至是极度倾斜、分布极度不均衡的。对这样的列如果还按照均匀分布的原则去计算可选择率与Cardinality，并据此来计算成本、选择执行计划，那么CBO所选择的执行计划就很可能是不合理的，甚至是错误的，所以，此时应该收集列的直方图。
能否利用TStack的计算、网络和存储能力，将Oracle运行在X86服务器，IP网络，云存储的“云化”架构上，去掉IOE架构中的I和E呢？
编辑手记：一条SQL的执行计划异常变更，在深入分析的过程中，发现其涉及到的知识点非常之多，于是整个问题都变得错综复杂。前面介绍了绑定变量及其窥探方面的知识，今天来分析聚簇因子。 作者介绍： 刘晨，网名
关于周一 Eygle 在文章《千头万绪：从一道面试题看数据库性能和安全的方方面面》讲到的 SELECT* FROM girls WHERE age BETWEEN 18 and 24 and boyfriend='no' 这个 SQL，他 从数据库 SQL优化、数据安全、SQL审核、开发规范、IN-Memory 特性方面做了深入的分析。
Oracle数据库里的统计信息是一组存储在数据字典里，且从多个维度描述了数据库里对象的详细信息的一组数据。当Oracle数据库工作在CBO（Cost Based Optimization，基于代价的优化器）模式下时，优化器会根据数据字典中记录的对象的统计信息来评估SQL语句的不同执行计划的成本，从而找到最优或者是相对最优的执行计划。所以，可以说，SQL语句的执行计划由统计信息来决定，若没有统计信息则会采取动态采样的方式来生成执行计划。统计信息决定着SQL的执行计划的正确性，属于SQL执行的指导思想。若统计信息不准确，则会导致表的访问方式（例如应该使用索引，但是选择了全表扫描）、表与表的连接方式出现问题（例如应该使用HJ，但是使用了NL连接），从而导致CBO选择错误的执行计划。
USE_CONCAT提示强迫优化器扩展查询中的每一个OR谓词为独立的查询块. 最后合并所有查询块的结果，返回结果集给用户。
这是2023年纽约NYC MongoDB大会的第二期，这期的主题是在企业级别从RDBMS 迁移到 NoSQL.
“为什么索引没有被使用”是一个涉及面较广的问题。有多种原因会导致索引不能被使用。首要的原因就是统计信息不准，第二原因就是索引的选择度不高，使用索引比使用全表扫描效率更差。还有一个比较常见的原因，就是对索引列进行了函数、算术运算或其他表达式等操作，或出现隐式类型转换，导致无法使用索引。还有很多其它原因会导致不能使用索引，这个问题在MOS（MOS即My Oracle Support）“文档1549181.1为何在查询中索引未被使用”中有非常详细的解释，作者已经将相关内容发布到BLOG（http://blog.itpub.net/26736162/viewspace-2113670/）上了。下面是一些非常有用的检查项目。
多租户技术（Multi-TenancyTechnology） 又称多重租赁技术：是一种软件架构技术，是实现如何在多用户环境下（此处的多用户一般是面向企业用户）共用相同的系统或程序组件，并且可确保各用户间数据的隔离性。简单讲：在一台服务器上运行单个应用实例，它为多个租户（客户）提供服务。从定义中我们可以理解：多租户是一种架构，目的是为了让多用户环境下使用同一套程序，且保证用户间数据隔离。那么重点就很浅显易懂了，多租户的重点就是同一套程序下实现多用户数据的隔离
今天单位值班，有一些时间可以继续完成这篇连载文章。首先祝所有朋友新年快乐！感谢你们在这一年当中对我文章的关注和指点，来年我们共同继续努力！
经常会有一些朋友咨询我一些数据库的问题，我注意到一个很有意思的现象，凡是数据导入的问题，基本上都是Oracle类的，MySQL类的问题脑子里想了下竟然一次都没有。
之前我们了解了索引的属性，以及一些对于是否能用索引似是而非的场景，相应的说明和结论可以参考，
本文作者系Walt，关注SQL开发，Oracle、MySQL、PostgreSQL、TiDB等数据库，AWS、Azure、OCI等公有云计算架构和技术。
熟悉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版以来被采用，有着一套严格的使用规则，只要你按照
用IN写出来的SQL的优点是比较容易写及清晰易懂，这比较适合现代软件开发的风格。
云和恩墨旗下的DBASK小程序近期增加了数据库 MongoDB、Redis、 Elasticsearch、DB2、Weblogic 等新的的专题栏目和一些新的技术专家，另外，也新关联了技术闲谈、OB、架构文摘、51CTO技术栈等等数据领域的公众号，欢迎大家阅读分享。
数据迁移的目的是为了给数据找一个更合适的归宿，让其满足当前及未来某段时间内业务场景的使用需求，使数据更安全，更可靠，更有效的为客户服务。
Oracle数据库中最普通、最为常用的即为堆表，堆表的数据存储方式为无序存储，当对数据进行检索的时候，非常消耗资源，这个时候就可以为表创建索引了。在索引中，数据是按照一定的顺序排列起来的。当新建或重建索引时，索引列上的顺序是有序的，而表上的顺序是无序的，这样就存在了差异，即表现为聚簇因子（Clustering Factor，简称CF），也称为群集因子或集群因子等，本书统一称为聚簇因子。聚簇因子值的大小对CBO判断是否选择相关的索引起着至关重要的作用。
本文介绍了某超大型保险公司于 2023 年 11 月成功投产的全新核心保单系统，这是保险业首次采用全栈自主技术的核心业务系统。通过系统升级，该公司实现了从集中式到分布式架构的转变，借助国产 X86 服务器和 TiDB 分布式数据库显著提升了性能，为未来业务增长奠定了坚实基础。这一创新不仅在逻辑大集中的核心系统领域确立了新的标杆，同时也为金融行业关键系统的国产化建设提供了宝贵经验。
开始学习崔老师的《基于Oracle的SQL优化》，七百多页，虽然可能会比较痛苦，但想必是一个痛并快乐的过程，尽情享受了。。。
作者简介 苏星开 云和恩墨南区交付技术顾问，曾服务过通信、能源生产、金融等行业客户，擅长 SQL 审核和优化，DataGuard 容灾等。 1 概述 在 Oracle 12.2 版本和新发布的18.0
查询优化器（简称为优化器）是内置数据库软件，用于确定 SQL 语句访问请求数据的最有效方法。
5、支持多种OS，提供多种API接口，支持多种开发语言，对流行的PHP，Java很好的支持
在数据爆发式增长的时代，记录数据变化和演变，探究内在规律并运用到生产实践中，驱动业务的增长成为这个时代主旋律。本文就如何记录数据变化，处理数据变化谈谈自己的理解
今天读了一篇MOS文章，《ORA-01722, ORA-01839, ORA-01841, ORA-01847 or ORA-01858 from Queries with Dependent Predicates (文档 ID 232243.1)》，整篇文章的目的就是为了阐述对于包含相互依赖关系谓词的SQL语句产生错误的可能原因(To explain the possible causes of these errors in SQL statements that include predicates that are dependent on each other)。
小编寄语 我们都知道，对于通过dblink关联本地表和远程表，远程表的索引个数一般不超过20个，对其本身不会有什么影响。但是当索引个数超过20个的时候，又会发生什么变化呢？ 昨天同事参加了一个研讨会,有提到一个案例。一个通过dblink查询远端数据库，原来查询很快，但是远端数据库增加了一个索引之后，查询一下子变慢了。 经过分析，发现那个通过dblink的查询语句，查询远端数据库的时候，是走索引的，但是远端数据库添加索引之后，如果索引的个数超过20个，就会忽略第一个建立的索引，如果查询语句恰好用到了第一个建立
编辑手记：子查询是SQL中比较重要的一种语法，恰当地应用会很大程度上提高SQL的性能，若用的不得当，也可能会带来很多问题。因此子查询也是SQL比较难优化的部分。今天一起来学习最常见的几种优化子查询到方
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
