ANBOB™

前几天，一位朋友的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开源数据库也存在一些备份工具，但存在一些差异，备份应根据恢复需求进行规划, 这里简单整理。

The maximum size of large objects (LOBs) in Oracle, PostgreSQL, and MySQL varies depending on the type of LOB and the database system. Here are the details for each database:

OceanBase Database也同oracle一样支持partition table，但存在一些注意事项，甚至和oracle存在一些差异。分布式数据库的数据打散方式并不相同， 分布数据基于组规则到不同的物理区，在Oceanbase中以 Partition粒度分布到不同的OB SERVER节点，Oracle mode 的OceanBase Database可以创建65536个分区partition，也可以创建subpartition, Table的分区列又叫分区键( partitioning key), 分区键必须是PK和UK的子集或者是说主键唯一键必须包含分区键。

在数据库中分析系统中的锁等待非常重要， 在oracle中有大量的脚本，在Postgresql中也需要积累一些工具， 可以快速分析锁等待， 这里推荐几个好用的脚本。

Oracle dataguard redo传输网络带宽不足通常如standby同步时延增加，数据库层还会有哪些表现吗？当standby 同步延时较大故障时， 故障排除最重要的阶段是正确识别问题的性质，例如能够判断问题是否与网络本身、DataGuard、Oracle 数据库（主数据库或备用数据库）或其他数据库有关。尽管 Oracle 提供了非常强大的工具，但这并不是一件容易的事。

在oracle RAC 环境中节点的信息配置文件有些记录在gpnp profile，如asm_diskstring, 当修改其中的参数时需要在节点间同步，在root.sh时也需要校验，CSS守护进程在启动期间使用GPNP profile来发现 voting files(参数“DiscoveryString”)。发现字符串的不正确值将阻止CSS守护进程(最终阻止整个CRS堆栈)启动。相关的服务有gpnp.bin\mdns.bin。 如果因为一些原因无法push到远程节点时会提示如下错误，
ORA-29783:GPnP Attribute SET Failed With Error [CLSGPNP_NOT_FOUND]

在oracle中A库直接远程访问B库常见的有dblink, 在postgresql中有postgres_fdw和外部表，在opengauss系中同样有postgres_fdw、oracle_fdw(for Oracle)、mysql_fdw(for MySQL)， 在EDB中postgres_fdw、oci_dblink(for Oracle)。但是发现对于opengauss到远程 opengauss的使用dblink访问时(有oracle应用迁移而来)， 在oracle中常用的select * from t1@dblink1访问时，提示 remote table ‘t1’ does not exist, 即使创建user mapping时使用的t1表schema用户。如果应用中存在原oracle语法需要调整，影响postgresql和opengauss, 简单记录opengauss中的问题。

Oracle Active Data Guard 是 Data Guard 框架中的一个选项，允许在从主数据库对物理备用数据库应用更改时以只读方式打开该数据库。Oracle Data Guard在某些情况下可能无法使用Active Data Guard（ADG）特性。最近一个客户oracle 11g dataguard在open read only 然后再启用mrp应用日志变更时数据库自动变为mount状态，说明ADG功能无法使用，db alert中并无任何报错，这里也整理几个ADG无法使用的情况

最近在跟客户沟通时，发现有些数据库厂家对外宣称，具备从oracle数据库迁移到目标国产库时，从源库到目标异构数据库真实负载重演能力，于是花了点时间研究一下，该功能原本在Oracle叫做ORACLE REAL APPLICATION TESTING （RAT）或其中的子Database replay, 相比另一功能SPA,是能重演生产库的真实业务到测试环境，国产库厂家是怎么做的呢？是真的可以RAT? 有没有什么风险呢？ 这里简单描述。