ITPub博客

 —— 表级 TTL 自动过期 · TTL 归档到指定表 · 自动日期分区，真机实测与踩坑一、数据生命周期与降本：数据留得久，成本降得下继续上次COS特性后，官方升级到了V21.6.4,推出了一些新功能。为了体验这些功能，利用腾讯云的资源开通了TDSQL-B（即TDSQL Boundless）的验证环境。做数据库运维的可能都经历过订单、日志、审计、埋点这些表，而这些中除了订单数据，其他都

9 月 30 号这一天，接到反馈，业务反应查询有点慢。数据库显示acknowledge over PGA limit是最严重的等待事件。这套库是 Oracle 19c 的 CDB，挂着 12 个 PDB，宿主机 24 核、94.4G 内存，SGA 已经占掉 58G。一、上午：AWR中最扎眼的是等待事件AWR显示：指标值DB Time4,210.78 分钟（快照区间 60 分钟）会话数393 → 5

你以为和上次一样？不是，同是一台物理机上的几个虚拟机重启，但是每个环境不一样，这次主库归档没了上次写了 rhino 库的那篇，缺 1 个 sequence，主库归档还在，修通 TNS 链路后 FAL 自动补，半小时搞定。这次是另一套环境，缺了 200 多个 sequence，主库归档也清理了，FAL 补不了。但最后还是没重做备库，RMAN 增量前滚 15 秒解决。一、环境信息主库：prod-isl

背景物理机故障重启，上面的虚拟机跟着重启，虚拟机里的 Oracle ADG 备库也跟着重启了。这本来是个很常规的操作，相关人报给我说无法启动。当时看到出错信息是 ORA-10458 的时候，心里咯噔了一下——备库打不开了。第一反应是完了，是不是得重做备库。冷静下来一步步排查，发现根本不用重做，问题比想象的简单，但隐蔽得很。一、问题背景这是一套 Oracle 11.2.0.4 的 Active Da

之前我让AI整理了一下这个工程概念脉络2026年中就出了两个。我8月时候就觉得9月可能还有。不出意外，上周就是出了一个新的。我也不知道叫概念还是叫框架。不管叫什么吧。它火了。刚火起来的 Jev，这几天朋友圈、技术群都在刷。说它是"比 LLM 便宜几百倍、零幻觉、带置信度的决策模型"。最近我顺手体验了一把，有些验证截图，都是这次试出来的结果。今天不堆参数，就聊聊：它到底是什么、能

昨天快下班的时候，朋友圈开始刷同一张图。中国信息安全测评中心联合国家保密科技测评中心，发了《安全可靠测评结果公告（2026 年第 3 号）》。数据库这栏有：杭州易景数通的羲和通用数据库系统软件 V1.0和腾讯云计算（北京）的 TDSQL 集中式关系型数据库管理系统软件 V10.3等。名单不长，但其中两个名字，我看得有点久。两个名字一个是 TDSQL。老面孔了，从 V8.0 开始，不同版本在这个名单

现在我排查问题，越来越多交给 AI 跑，形成了极大依赖。最近测试环境有人报这台 175.186 的库 /arch 撑到 95%，我本来得自己 ssh 上去、一条条查视图、算缺口、写删除脚本。这次我把活全丢给 AI 了——它写诊断脚本、跑命令、读视图、算文件缺口，我基本只动嘴。省事是真的省事。但过程又一次证明：**AI 没经验、有误区，关键判断还得人拍板。**不过也同时说明以后我

现在我做有些工作，越来越多地让 AI 来替我干活。以前遇到 OGG 链路挂了，我得自己 ssh 上机器、一条条敲 GGSCI、写脚本逐台核对，费时费力还容易手抖。这次 OGG 集成抽取链路重建，我几乎把这些都交给了 AI——它写脚本、跑命令、批量比对，我基本只动嘴。省事是真的省事。但过程也说明了一件事：AI 没经验、有误区，关键判断还得靠人。 它连续跑偏三次，都是我把方向拉回来的。写下来

先说结论，省流版deleteMany / remove 不会释放磁盘空间。WiredTiger 只做标记删除，空间留给后续复用，不会返还给操作系统。真正能回收空间的是 compact（部分回收）和 drop()（完全释放）。一、问题背景前几天在帮一个朋友问我，MongoDB所在服务的磁盘满了。要删除数据行不行？我第一反应你要怎么删除？因为我多年经验告诉我这又是一个开发人员想出来

– 写在前面：前几天朋友抛来一句"表空间快满了，加文件还是扩磁盘？"我心想这不简单，先看看使用率再说。顺手丢出一条用了 N 年的查询语句，结果屏幕上跳出来一行：USED_MB 空、FREE_MB 空、USED_PERCENT 空——一排醒目的 NULL。我心里咯噔一下：不会是数据文件坏了吧？– 这是我工作多年第一次在生产库上看到这种现场。后来在 1

当下的IT国产化进程，并非一刀切的全面替换，而是清晰分化成了"已替换的浅水区"和"难替换的深水区"两个截然不同的赛道。两个场景的行业现状、落地难度天差地别，也彻底重塑了数据库从业者的生存现状，行业红利褪去、岗位价值重构，已经成为无法回避的现实。一、国产化的两个层级：浅水区落地，深水区停滞1、可顺利替换的「浅水区」目前已经完成数据库国产化替换的企业，主要集中在

上周工作中遇到一件小事，戳中了当下大家过度依赖AI、机械照搬结论的通病，也印证了ToB传统企业数据库场景的特殊性。一、场景：AI和资深技术人的方案相悖了团队一位开发同学在做SQL索引优化，操作前咨询了我，我根据业务场景告知了他正确的索引建立方式。但提交代码审批时，他的索引方案和我给出的思路完全不一样。询问原因，得到了一个意外的回答：他后续又咨询了AI，AI给出的方案和我截然相反，他认定AI的方案是

一个来自https://cloud.tencent.com/developer/ask/2212634的问题一、先从一个问题切入问AI「1+2+3…+100等于多少」，这事跟企业信息化毫无关系——有人把知识喂给AI了，AI张嘴就来。但如果问「我们公司月度毛利是多少」，AI事先没有数据，答不出来。AI要拿到这个数据，只有两条路：有人提前准备好：定期上报、定期填报、定期维护——这不是AI自己动的，是人

近期做知识图谱与本体相关的分享，我发现一个非常普遍的行业乱象：当下多数企业做知识图谱、落地本体架构，都陷入了典型的"形式主义AI内卷"。人人都在跟风图数据库、追捧本体理论，但绝大多数人只看到了技术表层，完全没摸清落地的核心逻辑、适用边界和商业本质。看似全员入局，实则大多是无效投入、盲目跟风。最大误区：图数据库≠知识图谱，技术工具替代不了业务根基有些朋友、企业都存在一个致命认知偏

先说背景，实在没想通这个默认打开的参数为什么关闭了。从来没去考虑过会关闭。而且大部分都是打开的。实在不巧遇到这个数据库是关闭的一、问题背景前几天在客户现场排查一个性能问题，发现 Oracle 19c 数据库中 ACS（Adaptive Cursor Sharing，自适应游标共享）居然没有开启。按照 Oracle 的官方文档，ACS 从 11gR2 开始默认是开启的，但客户的 19c 环

现在行业里所有人都在说，AI最大的价值是提效。这句话，没人反对。但行业里还有一个公认的事实：个人提效 ≠ 组织提效。不少企业已经实现了组织层面的效率提升，这一点也没争议。但真正值得深究的问题是：企业靠AI提效之后，到底换来了什么？结合各行各业的落地现状，我发现一个很残酷的现实——真正能靠AI提效直接拉升营收的，几乎只有游戏行业。游戏行业里，AI提升内容生产、迭代、运营效率，能直接转化为更多新品、更

信通院 大数据技术标准推进委员会刚发了《数据库发展研究报告（2026年）》。这份报告去年我也读过，今年变化之大，值得认认真真写一篇。先说个背景。这已经是信通院连续第六年出数据库年度报告了，参与单位从信通院、移动、工行、中海油、南方电网，到 OceanBase、达梦、GoldenDB、金仓等一众国产数据库厂商，基本是国内数据库圈子的大半壁江山。89页的报告，我挑三个最值得说的角度来聊。先说钱这件事—

先说成本这件事关于数据库替换这件事，我个人始终觉得很多人对它的难度存在严重的低估。很多人一听说要换数据库，第一反应是"那不就是导个数据吗？"——这种朴素的理解不能说完全错，但确实只看到了冰山一角。你跟他说这个成本很大，他觉得你在吓唬人，是在帮原有数据库厂商说话，是在制造焦虑，是屁股决定脑袋。我有时候也很无奈。真正干过这件事的内行，心里都清楚这个活儿有多苦、多碎、多么不讨好。但在

最近群里一个故事最近身边发生了一件特别扎心，也特别值得所有职场人深思的小事，没有惊心动魄的剧情，只是一次普通的日常工作交付，却赤裸裸拉开了人与人之间的职场差距。有人说，部门领导临时下发了一项常规的数据整理任务，不算复杂，但涉及业务数据筛选、清洗、汇总，是团队日常工作中最常见、最基础的一类工作。就是这样一份人人都能做的工作，最终呈现出的结果，却让整个团队陷入了深刻的反思。接到任务的是同事A。和其他接

[告警类型：ZABBIX][规则名称：45.59的物化视图失效的监控][告警状态：已恢复][告警级别：P1][触发时间：2026-04-30 19:52:56][告警详情：45.59的物化视图失效的监控 (value is 1)]查询物化视图状态的确是已经有一个小时没有更新了。物化视图是一种简单且实施成本极低的数据同步方案简单无需第三方工具，且一致性有保证。当初正因为这样，导致越用越多，从2个表的