添加/编辑文档后$LDAPRDNHier视图未更新问题求助

这种突然掉链子的情况真的闹心——毕竟之前好好跑了多年的LDAP服务，突然就没办法同步新增/编辑的用户了，只能靠手动刷视图或者load updall -R -T $LDAPRDNHier path/to/extendednames.nsf救命。结合我多年折腾Domino的经验，给你几个排查和解决的方向：

1. 先排查视图索引的隐性损坏 #

有时候视图索引文件本身会出现肉眼看不到的损坏，表面上设置都正常，但自动刷新的机制就是触发不了。可以试试这两步：

• 先彻底清掉现有索引：执行load updall -X path/to/extendednames.nsf，然后重新生成全索引load updall -F path/to/extendednames.nsf，之后再把视图设置回自动刷新模式。
• 去Domino的控制台日志或者log.nsf里翻一翻，有没有和视图索引更新相关的报错——比如磁盘IO错误、权限问题，有时候存储层的临时抽风会把索引更新进程给卡挂了。

2. 验证LDAP和视图的关联配置有没有漂移 #

虽然你说没碰过视图配置，但Domino的LDAP配置偶尔会出现隐性漂移：

• 打开names.nsf里的LDAP Configuration文档，检查LDAP Search部分的User Search Base和对应的视图配置，确认确实指向的是$LDAPRDNHier视图，而且没有额外的过滤条件在搞事情。
• 重启LDAP服务试试：执行tell ldap restart，有时候服务进程的内存泄漏会导致它没法监听视图的更新事件。

3. 看看后台任务有没有资源抢占冲突 #

Domino的updall任务和其他后台任务（比如复制、归档）有时候会抢资源，导致视图自动刷新被延迟或者直接跳过：

• 打开服务器的Server Tasks文档，看看updall任务的调度频率，确保它在非高峰时段有足够的资源运行。
• 可以临时禁用一些非关键的后台任务，观察视图自动刷新能不能恢复，逐步排查是不是有任务在抢资源。

4. 检查extendednames.nsf的数据库一致性 #

数据库本身如果有文档结构损坏，也会阻塞视图索引的更新：

• 执行load fixup path/to/extendednames.nsf修复数据库的文档结构，有时候损坏的文档会卡着视图索引的遍历流程。
• 右键打开extendednames.nsf的属性→Design标签，确认Allow design refresh or replace to modify database是开启的——虽然你没改视图，但如果设计被锁定了，可能会导致索引更新的逻辑没法执行。

5. 应急：先整个自动化临时方案撑着 #

如果以上方法都暂时没解决问题，可以先整个定时任务自动重建索引，减少手动操作的麻烦：

• 在Domino服务器的Programs文档里加一个定时任务，比如每天凌晨2点执行：

  load updall -R -T $LDAPRDNHier path/to/extendednames.nsf
  

  至少能保证每天索引都是最新的，直到找到根本原因。

最后提一句，如果这些都不行，建议把Domino服务器的补丁更到最新版本——这类突然失效的问题，很多时候是IBM已经修复的已知Bug，升级补丁说不定就能解决。

内容的提问来源于stack exchange，提问作者Darajan