CMS连接丢失,但是一旦恢复,服务仍然失败

2020-08-26 05:07发布

点击此处---> 群内免费提供SAP练习系统(在群公告中)加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中) 症状: 从周日上午5...

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


症状:

  • 从周日上午5:30开始,直到我在上午11点重新启动群集中的所有节点为止,所有计划的报告均失败,并出现以下错误:无法执行操作。

观察

  1. CMC中的所有服务器都处于绿色运行状态。
  2. 用户仍然可以登录平台并刷新报告

发现:

在寻找根本原因时,这就是我所发现的。
  1. CMS数据库位于SQL Server 2016上。
  2. SQL Server参与了高可用性组
  3. 上午5:16,此可用性组发生故障。 主节点从正常运行到解决再到挂起,最后又恢复正常。 这一切都在几秒钟之内发生,但是SQL Server确实关闭了所有连接。
  4. SQL Server AlwaysOn租约超时已过期
  5. 按预期,我在CMS日志中看到此错误:SAP BusinessObjects BI平台CMS:丢失了与" BOE CMS Repo"的CMS系统数据库连接。
  6. SAP BusinessObjects BI平台CMS:无法连接到CMS系统数据库" BOE CMS Repo"。 原因:[Microsoft] [ODBC SQL Server驱动程序] [SQL Server]由于数据库副本不是PRIMARY或SECONDARY角色而无法访问可用性数据库'BOE_CMS_Repository'。 仅当数据库副本处于PRIMARY或SECONDARY角色时,才允许连接到可用性数据库。 稍后重试该操作。
  7. 这是一个分布式环境,其中:a)一个节点上的CMS/FRS,b)第二个节点上的处理/webi。
  8. 环境也是群集的。
  9. 其他节点记录到它们失去了与CMS的连接:Server Intelligence Agent已失去与CMS群集的连接,但将继续尝试重新连接。 请验证群集中的CMS是否正在运行。
  10. FRS还会在事件日志中引发错误:传输错误:未知错误。
  11. 但是,同样根据日志,CMS很快在5:18:55 AM之前重新恢复了与SQL Server的连接。
  12. 此外,其他节点重新建立了与CMS的连接:Server Intelligence Agent已在 msp-bicms02.teamasp.myteamasp.com :6400-上午5:18:55。
  13. 所有服务器上的日志级别在CMC中均设置为"无"。 德拉特! :(
  14. 即使处理节点在凌晨5:18恢复了连接,我也确实在Windows Event Log 3中看到了凌晨5:20和5:24之间的错误:EventID 34700,BusinessObjects_WIReportServer,传输错误:无效的对象引用。EventID34700,BusinessObjects_ConnectionServer ,传输错误:无效的对象引用。,EventID 34700,BusinessObjects_ConnectionServer32,传输错误:无效的对象引用。 事件日志中没有其他错误。 (我希望作业按计划运行时,由于我没有打开跟踪,所以会产生事件日志错误)...

根本原因:

  1. SQL Server租约超时到期,并导致可用性组出现错误。 我们需要解决这个问题。

问题:

  1. 即使BI平台表明已恢复所有连接并且所有服务器都在CMC中列为绿色健康状态,但为何平台仍无法在计划的报告上继续失败?
  2. 为什么要重新启动服务器节点才能使AJS再次正常工作?

理想情况下,我需要在单独的环境中复制此问题,并确定哪个服务未成功重新连接,并向平台开放支持案例,因为此缺陷需要在平台中解决。 但是我什至不知道从哪里开始。 恢复连接后,平台需要从连接断开的状态中更好地恢复。 也许它特定于一个不受信任的平台,并且如果所有服务都在一个盒子上运行,也许就不会有问题吗?

8条回答
ZJXianG
2020-08-26 05:51

感谢您抽出宝贵的时间查看我的问题!! 我真的很感激!!

我不确定是否很清楚,但是CMS和SQL数据库之间的连接仅断开了大约40秒钟,并且即使根据SIA日志也可以快速恢复。 在这40秒钟之外,CMC服务器页面看起来不错,每个服务都已启动并重新连接并呈绿色亮起。 除了在40秒钟之内(CMS已正确捕获)之外,没有延迟问题/网络问题。

但是,计划的报告作业仍然失败。

计划的报告的修复程序是重新启动服务。 理想情况下,不必这样做。 如果CMS重新正确连接,则该平台应能够自行处理终止过时的会话等。

但是,我要寻找的是为什么/如何在恢复连接后作业失败并且服务没有完全恢复。


听起来您提供的答案是,当CMS失去连接时,它可能已在服务器上运行过时的AJS会话,而当CMS发出shutdown services命令时,BI平台无法正确关闭?

一周热门 更多>