提供综合数据库运维服务与优化方案(不限Oracle MySQL PG GaussDB GoldenDB OceanBase等), 微信/Tel:(+86)134-365-60330
Recently, a customer’s Oracle database encountered a performance problem, waiting for “row cache lock”. Analysis showed that the cache# p1 value pointed to the dc_realtime_tabst 。
Starting from 12.2.0.1 Grid infrastructure home does have tomcat installed on the GI_HOME. A security scan may find Tomcat security vulnerability CVE-2024-21733 in your Oracle RAC environment. How do I fix it ？
客户一套ORACLE 3 node RAC, 因为需要节点3 主机停机维护， 重启后CRS无法启动， 其它两个节点node 1 ,node2 运行正常。 node 3启动过程中 ora.asm 资源启动hang ，等待enq: dd – contention , 简单记录分析步骤。
最近有家半导体客户的oracle RAC间隔性出现了2次活动会话高负载的堵塞现象，找到我协助分析， 当时的主要活动会等待是buffer busy wait, enq: tx … 的hot object现象，同时有较高的log file sync 单次延时，当分析数据库性能问题时，从top event入手没错，但是也要防止被带偏，也可能是因为其它的影响，简单记录这个事件。
最近有个客户遇到了enq: TM – contention, 确认表上有大量的FK，并且存在FK 无索引的现象，同是一张表有近60个FK ，同时子表又有几十个子表的多层FK（外键关连） , 关于这个event十多年前有记录过一个笔记”Tuning enq: TM – contention with foreign key (外键引起的队列)”, 现在这个客户也是认可是有外键缺失索引的问题，但非要找到当时的堵塞者SQL, 当然如果SQL很快如果没进ASH, 可能就不好分析了，这里使用分享logminer如何查找线索。
最近遇到两起运行在 Linux 7 上的数据库主机问题。由于操作系统内核的内存使用率高，导致 Oracle RAC 的性能受损或无法使用。内存主要被 Slab 的 SUnreclaim 区域占用。这些案例有一个共同特点：都使用了分布式文件存储系统。这次的情况是生产环境中有 750G 的内存，而 SLAB 使用了接近 200G 的内存，且主要是由 SUnreclaim 区域占用的。特此记录这个案例。
在ORACLE中，SQL Profile 是对 SQL 语句文本的数据库级匹配。由于相同的 SQL 文本在不同用户下可能会受到影响，因此需要一些方法来避免这种情况。OceanBase 提供了 outline 功能，可以用于固定执行计划。那么在 OceanBase 中是否存在与 ORACLE 类似的、影响不同用户的问题呢？多个用户的相同 SQL 语句和相同的表是否共享同一个 outline 呢？outline 是全库共享的还是用户级私有的？
在关系数据库性能优化技术中，有时存在数据库优化器评估问题，产生了错误的执行计划或执行计划改变，导致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开源数据库也存在一些备份工具，但存在一些差异，备份应根据恢复需求进行规划, 这里简单整理。