Essbase Studio(11.1.2.3)钻取报错：Null DTExecuteReportOut对象返回

我之前处理过类似的Essbase Studio递归维度钻取问题，结合你描述的场景——低层级查询正常、Gen2高层级触发报错，且已经调整了Row Governor到60000行，给你几个针对性的排查和解决步骤：

1. 先排查递归维度的Gen2层级展开逻辑 #

Acct和Org是递归结构，高层级查询时递归展开的子节点数量可能远超预期，哪怕Row Governor设了60000，中间数据集的内存占用或行数可能触发了隐藏限制：

• 登录Essbase Studio控制台，找到Acct、Org这两个递归维度，检查Gen2层级的递归深度设置：如果是无限制递归，先临时把深度限制在3-5层，再测试高层级查询，看是否还报错。
• 用EAS（Essbase Administration Services）查一下Gen2层级的实际成员数，再交叉Time和Scenario的Level0成员数，算一下总行数是否接近或超过60000？如果实际行数远超，递归展开过程中很容易内存溢出导致对象返回null。

2. 调整Essbase Studio的JVM内存参数 #

Essbase Studio基于Java运行，内存不足时处理大数据集的递归查询很容易出现对象初始化失败：

• 找到安装目录下的startup.sh（Linux）或startup.bat（Windows），修改JVM启动参数：
  • 把-Xmx（最大堆内存）从默认的-Xmx1024m调高到-Xmx2048m甚至-Xmx4096m（根据服务器内存情况来，别超过物理内存的70%）
  • 如果是Java 7及以下版本，顺便调整-XX:MaxPermSize到-XX:MaxPermSize=512m
• 修改完重启Essbase Studio服务，再跑高层级查询试试。

3. 检查server.properties的其他关键参数 #

你已经改了Row Governor，还要确认这些参数是否配置合理：

• 打开<Essbase Studio安装目录>\server\properties下的server.properties：
  • 确认essbase.studio.report.maxRows确实设成了60000，修改后要重启服务才会生效
  • 把essbase.studio.report.timeout（报表超时时间）从默认值调高到300秒，高层级递归查询耗时会更长
  • 适当调高essbase.studio.memory.threshold（内存阈值），比如从默认的512改成1024（单位是MB）
• 保存文件后重启服务，再测试。

4. 验证钻取报表的高级设置是否有冲突 #

有时候报表的维度层级配置会有隐性问题：

• 打开钻取报表的高级设置，确认Acct和Org的Gen2层级确实关联到了递归维度的正确层级，没选错成其他层级
• 先做个简化测试：临时把Acct或Org改成Level0，单独跑高层级查询，看是哪个维度导致的问题，缩小排查范围
• 检查报表的过滤条件：有没有隐藏的过滤规则导致高层级查询返回异常数据集？

5. 检查Essbase数据源的连接和服务器日志 #

确保Essbase Studio和Essbase服务器之间的连接稳定，没有数据传输问题：

• 在Essbase Studio里测试数据源连接，确认连接正常
• 去Essbase服务器的<Essbase安装目录>\logs下看essbase.log，高层级查询时有没有内存不足、查询超时之类的报错，这些日志能帮你定位根本原因。

如果以上步骤都试过还是不行，建议导出当前报表的定义，重新建一个极简版报表（只保留Acct Gen2 + Time Level0），逐步添加其他维度，排查是不是报表定义本身有问题。

内容的提问来源于stack exchange，提问作者P.J