对于Oracle不少特性，我们通常为了避免Bug，而是直接选择将一些功能屏蔽掉；虽然这样做不一定非常对，但是确实可以避免很多问题。这不一个网友咨询一个Ora-00600错误，从报错来看第一感觉可能是Bug，其中报错如下：

这里是一套Oracle 12.1版本的多租户环境。实际上我们知道，在Oracle 12.1版本中，多租户功能还不是足够的稳定，因此近些年不少客户已经选择将12.1 升级到12.2或者19c。单纯看上述报错是无法定位问题的，需要进一步分析trace的call stack信息：

通过上述堆栈信息，很容易就定位到具体的Bug。

Defect 21283337 – QKSAN.C TXN MSABESAN_DTXN ISSUE: CANNOT ROLLBACK WHILE WITHIN TRIGGER CONTEXT

针对该环境要么安装该one off Patch，或者将数据库升级到12.2的19年+版本。

实际上对于该问题，我们不难看出，是sql auto tunning任务导致。我们往常的做法通常是直接关闭该任务的。

至少从目前来看，我认为在11.2，以及12.1、12.2 甚至19c版本中，默认开启该任务没有太大的用处和价值。

这个case本身是非常简单的，主要目的不是记录bug流水账；而是想和大家来一起探讨一个问题：

对于数据库中的一些特性，我们的选择是什么样的？

我们都知道数据库在不断演进和发展，功能也越来越强大和丰富；同时数据库未来一定是向着自动化的方式演进。

因此我们知道，实际上Oracle从9i版本（至今近20年历史）开始就推出了SGA内存自动管理（在9i之前的版本中，设置Oracle内存参数是非常考验DBA技能的），以及后面的PGA自动管理，到后面甚至将SGA和PGA合二为一，彻底解放DBA，无需再进行繁琐的设置；设置统一的memory_target等参数即可。

然而理想很丰满，显示却很骨感；至少在目前我们的很多大型客户中，尤其是一些高并发环境下；仍然选择使用了内存手工调解；

对于很多小型系统来讲，比如医疗、高校、政府等数据库环境，你使用内存全自动管理，似乎问题也不大。

除了内存管理之外，对于应用SQL优化来讲，也是一件非常头疼的事情；因此Oracle推出了sql auto tunning的功能；在一些场景下，该定时任务确实能解决一些问题；然而并非没有坏处，比如本文中出现的Bug，可能导致数据库实例崩溃。

实际上对于SQL优化的工作，Oracle一直在不断迭代和演进，所以大家在Oracle 19c版本中看到了auto index 类似的功能；这是像AI4DB 方向的一个重大演进；从这一点来看，Oracle无疑是走在数据库世界前沿的。

所以我认为，本质上这是技术的演进迭代；从数据库厂商的角度来讲，我们是希望用户都能够使用最新的功能，去加快功能迭代；但是从最终用户来讲，往往更需要的是系统稳定性，因此从这一点出发，我认为关闭一些锦上添花的特性是无伤大雅的。

最后打个广告：云和恩墨 MogDB 关系型数据库2.1版本已发布，推出了多项实用功能，同时性能方面也有极大提升，欢迎使用！我们希望能为国产数据库尽一份绵薄之力！