最近的瓜，有点多！

前言

这几天看到不少技术新闻，有几件事让我印象比较深。

1. 昆明公积金系统因故障暂停业务；
2. PingCAP 披露内部系统安全事件；
3. PHP 紧急修复两个高危漏洞。

巧的是，早上 Oracle Security 也连续发来两封安全邮件。

原本只是想整理一下 Oracle 新发布的补丁，后来想想，这几件事虽然性质不同，但都值得我们 DBA 关注。

平时我们忙着处理慢 SQL、备份、巡检和各种故障，真正涉及业务连续性和安全问题时，考虑的东西其实要多得多。

做了高可用，业务就一定不会中断吗？

10 月 19 日，昆明市住房公积金管理中心发布通告，因存储系统集群节点故障、数据库运行异常，导致线上线下公积金业务暂停办理。

10 月 21 日，澎湃新闻跟进报道，系统暂停业务已近 60 小时，当时仍在抢修。

看到这个消息，我首先想到的是存储和数据库高可用。

现在很多生产环境都有 RAC、存储多路径，有些还部署了 Data Guard。看起来高可用措施不少，但真正遇到故障，能不能快速恢复业务，仍然是另一回事。

比如 RAC 可以应对部分实例故障，但共享存储出现问题，整个集群仍可能受到影响。即使部署了 DG，备库能否接管、业务能否正常切换，也需要提前验证。

当然，这次昆明公积金具体的故障根因和恢复过程，目前缺少完整技术报告，不能随意判断。

不过有个问题值得思考：

如果同样的故障发生在自己负责的生产环境，我们需要多长时间恢复业务？

RMAN 备份成功、DG 同步正常，只能说明检查时的状态。真正的恢复能力，还得靠演练来验证。

数据库没有漏洞，数据就一定安全吗？

再看 PingCAP 最近披露的安全事件。

根据官方公告，攻击者在 9 月 9 日至 10 月 7 日期间，利用被盗的服务账号凭据访问了部分内部系统，复制了数据并获取了源代码。

调查确认部分客户相关信息受到影响。PingCAP 表示，目前没有证据表明 TiDB 中存储的数据受到影响，相关调查仍在继续。

这里需要区分，内部系统发生安全事件，不代表 TiDB 数据库产品本身存在漏洞。

不过，这件事让我想到平时的数据库运维。

现在很多环境都有监控平台、备份系统、自动化脚本，甚至还接入 GitLab、Jenkins 等工具。

这些系统里可能保存着数据库连接信息、运维账号、API Key，甚至是明文密码。

数据库本身权限控制得再严格，如果周边系统的凭据泄露了，风险同样不小。

最近 PHP 又爆出了两个高危漏洞，更能说明这个问题。

10 月 21 日，PHP 发布紧急安全更新，修复了 CVE-2026-109618 和 CVE-2026-109619，两个漏洞的 CVSS v4.0 评分均为 9.2。

研究人员已经演示了在特定条件下通过这些漏洞实现远程代码执行，以及读取 PHP 进程内存中的敏感信息。

官方修复版本包括 PHP 8.2.35、8.3.36、8.4.27 和 8.5.12。

这类漏洞虽然发生在应用层，但很多 Web 系统后面连接的就是数据库。一旦应用服务器被入侵，数据库连接凭据也可能受到威胁。

数据库安全，不能只盯着数据库本身。

Oracle 也连续发布安全公告，新 RU 已经来了

说回 Oracle。

10 月 20 日，Oracle 发布了 2026 年第四季度 CPU（Critical Patch Update），包含 1295 项新的安全补丁，涉及 Database、GoldenGate、MySQL 等多个产品。

其中 Oracle Database Server 有 14 项安全修复，4 项涉及无需身份认证即可通过网络远程利用的漏洞。

第二天，Oracle 又发布 CVE-2026-91403 安全警报，CVSS 评分达到 9.1。不过该漏洞涉及 Java SE、GraalVM 的 JSSE 组件，并不是 Oracle Database Server 内核漏洞。

相比安全公告，我更关心新一轮 RU 更新。

早上去 MOS 查了 KB106822（原 Doc ID 888.1），19c 已经更新到 19.33，26ai 则更新到了 23.26.4。

以上补丁于 10 月 20 日发布，Linux x86-64 平台已经可以下载。

对于短期内无法升级最新 RU 的环境，Oracle 还提供了对应旧 RU 的 MRP 和 CSPU，可以根据当前补丁基线评估。

但生产 RAC、Data Guard 环境不能看到补丁就直接安装，还是要先检查兼容性、补丁冲突、已知问题和回退方案。

安全要重视，生产稳定性也不能丢。

补丁下载地址

这次的 RU 补丁我也整理到了百度网盘。

Oracle 19c RU 19.33

Oracle 26ai RU 23.26.4

提取码：6666

网盘为个人分享，具体文件以实际内容为准。生产使用前请核对平台、Patch ID、文件完整性及官方 README。

最后聊几句

回头看这几件事，其实都和我们平时的工作有关。

1. 昆明公积金系统故障，让我想到备份和高可用能不能在关键时候真正发挥作用。
2. PingCAP 的安全事件和 PHP 高危漏洞，提醒我们关注数据库之外的账号、凭据和应用安全。
3. Oracle 的 CPU、RU 更新，则是 DBA 日常绕不开的补丁管理工作。

我觉得没必要看到故障就急着批评谁。生产系统足够复杂，任何厂商、任何团队都可能遇到问题。

真正值得关注的，是发生问题后能不能快速定位、恢复业务，以及后续有没有把问题解决。

做 DBA 这些年，越来越觉得这份工作不只是把数据库维护到正常运行那么简单。平时多看看行业里发生了什么，再回头检查一下自己的环境，想想有没有类似风险。

毕竟，真正发生故障的时候，能不能把业务恢复起来，才是最重要的。