SSAS OLAP Cube每日自动处理偶发PostgreSQL流读取异常如何解决

该报错的核心触发原因是PostgreSQL数据源与SSAS服务之间的连接链路异常中断，你此前调整的均为SSAS侧的超时配置，故障根因大概率出在网络链路、PostgreSQL侧配置或访问压力层面，可按以下优先级排查解决：

• 调整TCP保活配置解决会话回收问题
  绝大多数偶发的读流中断故障，都是中间网络设备（交换机、防火墙、NAT网关）的空闲会话超时回收机制导致的，多数企业内网防火墙默认的空闲会话回收阈值为15~30分钟，与你报错的10分钟左右断开的特征吻合，而SSAS和PostgreSQL默认的TCP保活包发送间隔均大于该阈值，会被网络设备误判为空闲连接回收。
  首先修改SSAS服务器的TCP保活参数：打开注册表编辑器，定位到路径HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters，新增两个DWORD值：
  • KeepAliveTime 赋值为300000，单位为毫秒，即每5分钟发送一次TCP保活包
  • KeepAliveInterval 赋值为10000，单位为毫秒，即保活包无响应时每10秒重试一次
    配置完成后重启SSAS服务器生效。
    若使用云环境部署PostgreSQL，还需同步调整云安全组、NAT网关的会话超时时间，确保大于SSAS处理Cube的最长耗时。
• 排查PostgreSQL侧的主动断连配置
  检查PostgreSQL配置文件postgresql.conf的以下参数，避免PG主动断开长连接：
  • tcp_keepalives_idle 建议设为300，单位为秒，与SSAS侧的保活间隔对齐
  • tcp_keepalives_interval 建议设为10，单位为秒
  • statement_timeout 确认该值大于Cube处理任务的最长执行时长，测试阶段可临时设为0关闭语句超时验证
  • idle_in_transaction_session_timeout 确认该值大于Cube处理时的最长事务持有时间
• 优化Cube处理逻辑降低数据源压力
  偶发故障通常与高峰时段PostgreSQL的资源占用过高有关，可在Cube处理任务执行时同步监控PostgreSQL的pg_stat_activity系统视图，排查是否存在锁等待、连接数耗尽、IO/CPU负载打满的情况。同时可将Cube的全量处理逻辑调整为按分区增量处理，拆分单次查询的数据量和执行时长，降低PostgreSQL侧的访问压力。
• 升级PostgreSQL ODBC驱动
  旧版本的PostgreSQL ODBC驱动存在已知的长连接读流中断Bug，建议将SSAS服务器上安装的PostgreSQL ODBC驱动升级至官方最新稳定版，排除驱动层面的已知问题。
• 临时验证方案
  测试阶段可在Cube处理任务前新增一个前置脚本，先执行简单查询语句SELECT 1 触发生效数据源连接，再触发Cube处理任务，同时拆分Cube分区为小粒度单独处理，验证故障是否复现。

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