ANBOB™

在关系数据库性能优化技术中，有时存在数据库优化器评估问题，产生了错误的执行计划或执行计划改变，导致SQL执行效率变差，在无法或短时间内修改应用SQL代码时，需要从数据库端快速固定指定的执行计划，问题:
多个用户多个table(含索引)相同结构，对于相同的SQL文本，是否会互相影响？
多个用户相同的table， 对于相同的SQL文本，是否会互相影响？

前几天，一位朋友的Oracle RAC 2-nodes（Linux 6物理主机，HPE）系统计划进行HBA固件升级。幸运的是，他们采用了滚动节点的升级方式。在节点1升级FC HBA固件（Firmware version）并重启后，CRS启动失败，所有ASM DISK丢失，且在重启时遇到了操作系统无法启动的惊险情况。这里，我分享一下处理这种问题的经验。

最近，我注意到一位朋友在处理一个以G字开头的MySQL系国产数据库时遇到了一些问题。具体来说，该数据库占用了超过1TB的临时文件，导致文件系统告警，之前kill session并且未能释放。这是由于在杀掉dbproxy上的session后，db node上的session仍然存在。这样的情况可能是非原生分布式数据库的一个风险点，因为每个data node都是一个独立的MySQL实例。最终，我们通过登录到data node并手动kill session解决了问题。我在另一款国产MySQL系分布式数据库GoldenDB上进行了类似的模拟测试，仅记录处理方法。

数据是企业的重要生产要素，确保数据不丢失是大多数客户的核心目标。然而，要实现这一目标的高可用容灾方案不仅依赖于数据库产品的架构支持，还需要硬件成本的投入。同城双机房的配置在客户中较为普遍，如果追求RPO=0，无论是分布式数据库还是集中式数据库，个人了解到目前主流的数据库使用架构

在学习OceanBase时，测试环境是必不可少的。我在个人笔记本电脑（18核CPU，32GB内存）上的VBOX虚拟机中创建了一个配置为8核CPU、16GB内存和100GB磁盘空间的虚拟机，并在其上安装了OceanBase V4.2.1环境（Oracle租户），以便后续进行语法研究。以下是安装过程的简单记录。

在MySQL 5.6或从5.6 升级到8.0后有可能会遇到ERROR 1071 (42000):Specified key was too long; max key length is 767 bytes 报错，提示是遇到了索引KEY的最大上限767 字节。在本文中，我将解释此错误发生的原因以及如何解决它。

上周，Percona 发布了一篇警告博客，提醒用户<不要升级到 MySQL 8.0.37 之后的任何版本>。然而，现在访问 MySQL 官方下载页面，依然可以在主推的下拉列表中看到这些版本。
Percona 在文章中提到，Jean-François Gagné 在 bug.mysql.com 上报告了一个编号为 #115517 的 bug。不幸的是，这个 bug 目前处于私密状态。简而言之，如果您创建大量表（例如 10000 个），MySQL 守护进程在重新启动时会崩溃。当然，也有人认为这是危言耸听，因为单个数据库实例中有超过1万张表的用户可能不足0.0000001%。

今天一个客户的文件系统空间耗尽，数据库重启后，数据库无法启动，mount后提示ORA-00205: error in identifying control file, check alert log for more info, 查看DB ALERT LOG提示ORA-27048: skgfifi: file header information is invalid， 因为控制文件头损坏。简单记录.

Oracle Database 11g 引入了增量统计信息维护（Incremental Statistics Maintenance），以提高大型分区表统计信息收集的性能。当为分区表启用增量统计信息维护时，Oracle 会通过聚合分区级别统计信息来准确生成全局级别统计信息。除了增量统计信息外，配置较小的采样率也是加快大表统计信息收集的另一种方法。今天有位同事问，为什么在同时配置增量统计信息和小采样率时，小采样率没有起作用。

在oracle 数据库对象由 object_id 和 data_object_id 定义，后者的值也使用与 object_id 相同的内部唯一标识符。数据库中的对象标识符object id数量有硬性限制，一旦达到该限制，数据库将无法使用，必须重建。数据库中的唯一约束标识符数量也有硬性限制。触发些上限是会提示ORA-600 [kkdlron-max-objid] or ORA-600 [15260]。

Oracle 数据库在在线维护操作方面引入了大量特性，旨在实现日常维护和升级时无需停机。相比之下，MySQL 在这方面的表现稍逊一筹。作为 Oracle 的 DBA 是一件很幸福的事情，因为日常的分区维护、发现性能问题时的紧急创建索引等操作都可以在线完成。而 MySQL 虽然也宣称支持 DDL，但这是真的吗？

我们有一个 GoldenDB 的客户要求以后所有的 DDL 操作只能在停所有业务的情况下执行。对于拥有大量数据库实例且需要频繁进行 DDL 维护的情况，请问你能提供多少停机时间？

OceanBase v4作为一款分布式关系型数据库，提供了与Oracle数据库相似的LOB（Large Object）类型支持，包括BLOB（Binary Large Object）、CLOB（Character Large Object）以及NCLOB（National Character Large Object）。这些数据类型主要用于存储大量文本、图像、JSON、地理信息等非结构化或半结构化数据。在从 Oracle 迁移到 OceanBase 时，需要关注LOB对象的存储类型和属性，确保它们在OceanBase中得到适当的处理。我们所说的兼容性不仅包括类型兼容，还包括语法语义和行为兼容。如果 OceanBase 的限制比 Oracle 更宽松，则迁移过程可以正常进行。但如果 OceanBase 的限制更严格，则可能会导致数据无法迁入目标数据库。

数据库存放着组织拥有的最重要的资产之一——数据。保持数据安全和不受破坏是关键任务。对于大多数应用程序来说，停机比数据丢失或损坏更痛苦。DBA的核心职责包括数据库的备份恢复，到了关键时刻非常考验方案的有效性。在MySQL开源数据库也存在一些备份工具，但存在一些差异，备份应根据恢复需求进行规划, 这里简单整理。