什么是FDE——Forward Deployed Engineer

by

最近几年，一个越来越常见的词出现在 AI、云计算、数据库等技术领域： FDE——Forward Deployed Engineer，前沿部署工程师。 这个名字听起来有点“高大上”，但如果用一句大白话解释： FDE，就是把真正懂技术、能写代码的工程师，放到客户和业务的一线，直接参与解决真实问题。 他不是坐在公司里等需求，也不只是给客户讲产品，而是直接进入客户现场，理解业务、分析问题、修改代码、调系统，甚至和客户一起把产品真正跑起来。 “Forward Deployed”真正强调的不是地点，而是位置。 这个“位置”是： 靠近问题发生的地方。 FDE 站在客户和研发之间，但又不是简单的“传话筒”。他需要自己下场解决问题。 数据库领域其实特别适合 FDE 如果把这个概念放到数据库领域，我觉得会非常有意思。 传统 DBA 更多关注： 而数据库 FDE 可以进一步向业务前面走： 例如客户说： “交易系统晚上很慢。” 一个数据库 FDE 不应该只回答： “数据库 CPU 90%。” 而应该继续追： 最后最好能够得到一个明确结果： 平均响应时间从 3.2 秒下降到 200ms。 这才是真正的 FDE 思维。 从 DBA 到 FDE，其实只差一步，区别只是： 传统 DBA 更多围绕“数据库”解决问题。 而 FDE 更强调： 围绕“客户最终目标”解决问题。 因此，从 DBA、开发、架构师、SRE、售前走向 FDE，本质上都是能力边界的扩展。 尤其是在 … Read more

Troubleshooting Oracle Exadata x8 crsctl start fail with error CRS-41053

by

最近有个客户的Oracle Exadata X8 其中一个节点crash后无法启动提示 CRS-41053 其他节点运行正常，手动重启CRS依旧失败并且alert日志中无明显报错。后在聚合所有日志，在问题时间段RStrce文件发现了OS system dependent operation:connect failed with status: 111， 排查出RS和MS进程异常，原因为/var空间耗尽，下面记录这个案例

瀚高数据库 ALTER COLUMN 报 cache lookup failed for foreign server 的问题定位

by

最近在highgo瀚高（IvorySQL） 数据库中，对普通表修改某一列的数据类型时，出现 cache lookup failed for foreign server 97007982。经过逐级排查，最终发现问题并不在目标表本身，而是该列被一个历史 View 依赖，而 View 曾经依赖 DBLink 相关对象；DBLink 删除后，View 中残留了异常依赖关系。

告别手工翻日志！Oracle RAC 日志聚合可视化工具 OracleLogVisualizer

by

一个节点异常，alert_xxx.log、ocssd.log、ohasd.log、crsd.log、各种 .trc 散落在几十个目录里；OracleLogVisualizer 就是为了解决这个问题而生的。

它把指定目录下所有 Oracle 日志 / trace 文件解析后聚合成一张表，按时间排序、关键字高亮、实时过滤——相当于给 RAC 日志装了个”时间轴浏览器”。

Oracle 19c RAC start failed caused by ASM Listener

by

最近一家玻璃基板的制造业客户的oracle 19c RAC 节因光纤交换机故障，后节点2重启失败。手动重启crs， 使用crsctl stat stat -t -init 查看资源，停留在ora.storage starting 状态。

查看crs alert log

2026-08-03 10:43:54.212 [ORAROOTAGENT(69300)]CRS-5019: All OCR locations are on ASM disk groups [CRS], and none of these disk groups are mounted. Details are at “(:CLSN00140:)” in “/u01/app/grid/diag/crs/anbob2/crs/trace/ohasd_orarootagent_root.trc”.

如何确认“_use_adaptive_log_file_sync”有没有生效？

by

Oracle 11gR2开始引入了 Adaptive Log File Sync，用于优化 log file sync 等待。很多DBA都知道这个隐藏参数：
“_use_adaptive_log_file_sync”
,客户担心的是这个参数改为false是不是仅是禁用自动调整，而不会恢复LGWR到Post，因为日志里已经提示从post到polling模式了，而没出现poll 到post。

Agent扑面而来，数据库从业者该如何自处？一个DBA的观察。

by

AI+各行业概念层出不穷，而数据库是IT架构中的基础软件，存放的数据是企业的核心资产，这里有两个概念数据库与数据，从市场变现角度显然后者才是主角。 我是一名DBA，庆幸是周围有些思想活跃、技术前沿的客户，去年有次和一个客户交流AI在数据库上如何大有作为，给我浇了盆冷水，让我开始重新审视数据库与AI的关系。

如何查询Oracle\达梦数据库的所有系统对象、性能视图

by

在数据库里的数据字典对象和动态性能视图有很多，但是最近学的数据库种类多了以后，有点走火入魔容易记混，在oracle中的中更多，我经常使用的是Tanelpoler的SQL工具包中的d.sql, 或常用的dict和v$fixed_table, 在达梦中dict对应的好像是sysobjects. 发现目前的大模型对国产回答还不完美，那我给AI的语料，简单记录.

High ‘latch: shared pool’ and ‘library cache: mutex X’ in Oracle 19c（19.13）

by

好久没有处理oracle的故障了，因为我的客户在oracle 升级19c后的数据库非常稳定，前几年随着X创推进，几乎oracle都被国产化替代了，刚好最近遇到了一个问题，有家医院客户，最近每隔几天早高峰会出现较高的’latch: shared pool’ 和’library cache: mutex X’，导致数据库节点hang, 重启解决，如果发现的早做flush sharedpool也可以缓解。数据库版本19.13.

Oracle迁移PostgreSQL系性能问题：not in

by

最近有客户在oracle迁移到Highgo数据库后，有些SQL运行时间timeout而中止，然后应用就开始调中间件的timeout时间如增加socketTimeout或removeAbandonedTimeout， 这是治标不治本的方法，主要是因为SQL时间变长了，查看了SQL 也是个简单的not in( …) 子查询。 这种SQL其实在oracle是有自动优化的，但PG没有

PostgreSQL性能问题： View无法谓词推进(predicates pushdown）

by

在 PostgreSQL 中，“视图（View）”、“连接（Join）”以及“谓词下推（Predicate Pushdown）”是直接影响 SQL 执行性能的重要优化环节。所谓谓词下推，是指优化器能够将外层查询中的 WHERE 条件或 Join 过滤条件，自动下推到视图或子查询内部执行，从而尽可能早地减少参与运算的数据量，降低扫描、排序和连接开销。

Alert: 不建议生产库使用YashanDB “nologging” table

by

前面一篇我分享了PostgreSQL系（像kingbase\gaussdb\highgo等）不要使用unlogged table, 那在oracle 迁移到yashanDB库同样存在该风险，yashanDB更是提供了nologging的语法，完全兼容Oracle，但原理机制也不相同。在分布式数据库因为多是基于redo的强一致，多数不支持nologging. 这里我继续简单测试yanshanDB.

Alert: Don’t Migrate “nologing” Table in Oracle Database to PostgreSQL “unlogged”

by

因 PostgreSQL 功能丰富，且在处理复杂 SQL 时的性能表现不俗，越来越多客户正从 Oracle 迁移到基于 PostgreSQL 的国产数据库，例如 GaussDB、Kingbase、HighgoDB 等。但要注意：换皮容易换骨难。有些语句看起来“形似”，底层机制却截然不同，仅做语法层面的转换，可能带来致命后果。本文总结 Oracle → PostgreSQL 迁移中NOLOGGING 与 UNLOGGED 这种看似相似、实则差异巨大的特性。