oracle18c的博客

字符串变长导致的游标不能共享而像Java等高级语言中，并没有严格限定字符串的长度，比较难从应用程序的角度控制类似问题的发生。为此在Bug 2450264 - Add event to improve cursor sharability on BIND_LENGTH_UPGRADEABLE中，Oracle引入了Event 10503，通过该事件可以将字符串设置为固定的长度，如2000，避免绑定变量带入的不同长度，导致多个子游标的出现。万能的"治标"方案。

事务回卷是 PostgreSQL 数据库中非常经典的问题，事务 ID 采用 32 位实现，理论上最大支持 4 Billion 个事务(32 位无符号数，xid 最大能够达到 42 亿)，但因为 XID 是循环复用的，新老事务相差的上限是 2 Billion，当达到 2 Billion 的上限时会进行事务”回卷“，可能导致新事务被误判早于旧事务，从而破坏 MVCC 机制，极端情况下会导致数据库强制关闭。每个事务关联到一个 Undo 段，段头包含事务槽(Transaction Slot)，记录事务的状态。

为了SQL语句能够始终以最优的执行计划执行，Oracle在不断的探索和革新。从9i的绑定变量Peeking，到11g的ACS和Statistics Feedback，在12c中则引入了Adaptive Query Optimization。Statistics Feedback在SQL第一次执行时，根据统计信息生成的执行计划执行SQL，执行过程中执行计划不能改变，如果统计信息不准确，在SQL第一次执行时可能就会引起灾难性的问题。

在具体介绍优化器之前，我们先普及一下执行计划的概念。所谓执行计划，是数据库在接收到SQL语句执行请求后，由优化器根据数据库表结构、索引信息以及其他必要信息生成的一个内部数据访问策略，这个策略详细描述了数据库引擎如何将SQL语句转化为一系列的操作步骤，从数据库中获取到最终的执行结果。通过执行计划，我们可以了解到数据库引擎如何访问表、如何使用索引，多表之间如何关联以及相关的其他操作，是数据库性能优化的重要分析工具。这篇文章和大家探讨了优化器和执行计划的关系，执行计划是如何工作的，又该如何阅读执行计划。

类似于 SPM，Oracle 有的很多功能都是这样的不断迭代进化的。比如 OMF (Oracle Managed Files) 最初只是在 10g 引入的一个新概念，刚推出来时也没觉得有什么很大的用途，但是在随后的版本中，Oracle 在 快速恢复区和 ASM 中广泛使用 OMF，使用这种方式能够从数据库层面实现数据文件、归档日志文件及闪回日志等的自动管理，不需要从操作系统上再去对数据库相关文件进行手工操作，一方面提高了管理效率，另一方面也避免从外部操作数据库文件，大大降低了运维风险。

Oracle 23ai 已经正式发布一段时间了，不过由于OP版只能在 Oracle Engineer System 上使用，所以在我们接触到的客户中真正使用 23ai 非常少。最近我们借助于 Oracle 提供的 Free 版本，针对新特性进行了系统的分析和学习，发现 23ai 真的是将 AI 功能贯彻的非常彻底的一个版本，以至于我都怀疑 DBA 是不是真的会失业！本篇是 23ai 新特性系列文章的第一篇，介绍 SQL 分析报告，对新技术特性感兴趣的朋友可以点个关注，大家一起来学习。

这篇文章介绍了数据在Oracle数据库中是如何组织和存储的，通过位图管理空间，规避了老版本中使用数据字典和自由链表方式引起的递归调用和并发争用问题，大幅提升了数据库的并发处理能力，是Oracle 9i之后推荐的管理方式。

这篇文章中给大家介绍了Oracle数据库中几种典型锁的概念及其实现。Oracle中的锁遵循最小粒度的原则，尽量将加锁粒度控制在最小范围，避免影响其他事务的操作。加锁粒度尽可能小；读永远不会阻塞写，写也永远不会阻塞写；锁永远不会主动升级。这些特性现在看来都很普通，市面上主流的关系型数据库基本都支持这些特性。但是倒退20年，这些都是Oracle碾压其他数据库的杀手锏，Oracle之所以能成为数据库领域的No. 1，除了合理的市场策略外，这些精细的设计也是帮助其统治市场非常重要的因素！

事务是数据库管理系统执行过程的一个逻辑单位，由一系列有限的数据库操作序列构成，事务必须满足‌ACID属性。ACID理论是数据库中最重要的概念之一，分别代表原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生；一致性是指事务将数据库从一个一致的状态转移到另一个一致的状态，这意味着事务执行的结果必须符合所有预定义的规则和约束；

本篇文章给大家介绍了Oracle数据一致性的保障体系，在这个体系中，检查点是非常重要的环节，它定期将“脏数据"从内存写出到数据文件。由于数据库是持续运行的，没有绝对的一致性状态，因此检查点队列被设计成一个先进先出的链表，依次从检查点对列写出到数据文件中，完成数据的持久化。对于已经进入检查点队列但没有写出到数据文件的脏块，实例恢复时会通过在线日志前滚将已修改的数据恢复出来应用到数据文件中，从而保证数据的一致性。

在这篇文章中，我们以一条更新SQL的视角，给大家介绍了Oracle数据库是如何处理DML语句的。通过这个过程我们可以看到，所有变更操作都是在内存中完成的，这里的内存操作包括Redo Log Buffer中记录的数据操作日志和Buffer Cache中对数据块的变更。当用户确认提交后，会将Redo Log Buffer记录同步写出到在线重做日志文件，而Buffer Cache中被修改的数据块，则会放入到“脏块”链表，基于一定的机制异步写出到数据文件中。

在这篇文章中，给大家介绍了从客户端发送一条SQL到数据库，经历了解析、绑定、执行和提取等几个阶段最终获取到相应的数据。其中，解析阶段因为涉及到执行计划的确定，成本非常高，为了实现一次解析多次执行的目的，Oracle又引入了绑定变量，将执行过程中的变量进行参数化处理，“欺骗”数据库认为都是相同的语句，从而避免了更多的硬解析。但是这种方式是“完美”的吗？又会给数据库的运行带来哪些问题？大家在使用数据库的过程中，又遇到哪些解析的问题？欢迎留言讨论！

Oracle直方图的概念相对复杂，涉及到的知识点比较多，通过一篇文章梳理不同直方图的生成原理和使用场景，帮助大家更好的理解和运用直方图解决实际生产问题。

Oracle 11g 开始，数据库密码默认区分大小写，但是提供了一个参数 – sec_case_sensitive_logon，使得11g的密码验证行为和之前相同（不区分大小写）。 但是在12c中，该参数已经被废弃，也就是说12c强制密码大小写验证。因此在上线前需要仔细检查应用系统密码，避免因为密码大小写问题导致登录失败。在设置 sec_case_sensitive_logon = fals...

按照正常的逻辑，节点2被踢出集群是预期行为，首先节点2已经出现操作系统夯住的异常，其次对于两个节点的集群，即使两个节点都没有明显的问题，Oracle也会优先保留id更小的那个，因此不论是什么情况节点2都会是被踢出集群的那个。和之前不同的是，这次的决策过程中提到了NodeWeights，系统使用节点2旧的权重进行集群决策，不凑巧的是节点2的权重比节点1的权重要高，因此把正常的节点1踢出了集群。事实上，几乎就在节点1将自己踢出集群之前的几秒钟，节点2的OS已经发生了重启，于是就发生了文前提到的那一幕。

客户的测试环境数据库频繁crash，而且据开发人员反馈是一条insert的SQL语句导致的。说实在话，随着Oracle数据库版本的演进，越来越少遇到宕机的案例，而这次竟然会因为一条insert导致实例崩溃，