SSAS 14.0.226.1表格模型重启后列丢失，处理报错求助

针对你遇到的SSAS版本14.0.226.1、Visual Studio 4.7.02558环境下，模型部署后处理正常，但服务重启后某维度处理提示Failed to save modifications to the server. Error returned: 'The 'Global_Code_SKU' column does not exist in the rowset.'的问题，结合你提到的6.32亿行事实表的场景，以下是几个经过验证的永久解决办法：

1. 核查维度列映射与数据源稳定性 #

• 首先确认Global_Code_SKU列的来源：如果该列来自维度表，要确保维度表的数据源连接在SSAS服务重启后能正常访问，特别注意列名的大小写和拼写一致性（SSAS部分场景下对列名大小写敏感）。
• 打开Visual Studio中的模型项目，检查维度的属性映射：确保Global_Code_SKU明确绑定到正确的数据源表列，避免使用动态生成的列或存在逻辑缺陷的计算列（如果是计算列，要验证其表达式在服务重启后能正常解析）。
• 部署前强制模型验证：右键项目选择Validate All，修复所有与列映射、数据源连接相关的警告或错误，避免无效元数据被部署到服务器。

2. 缓解事实表字典溢出风险 #

6.32亿行的事实表确实可能触发SSAS的字典溢出问题，尤其是高基数列：

• 先检查Global_Code_SKU的基数：如果是数百万级的高基数列，可以尝试将其设置为String类型的NoKey属性，或者调整维度存储模式：
  • 切换维度为ROLAP存储（原先是MOLAP的话），ROLAP会直接查询数据源，避免本地字典存储的溢出问题，但可能影响查询性能，需要根据业务场景权衡。
  • 若坚持使用MOLAP，调整SSAS内存配置：修改msmdsrv.ini配置文件中Memory\TotalMemoryLimit和Memory\LowMemoryLimit参数，给SSAS服务分配更多内存，确保字典数据能完整存储，避免溢出导致列信息丢失。
• 对事实表做分区优化：将6.32亿行拆分为多个分区（比如按日期分区），减少单个分区的行数，降低字典存储压力，同时也能提升处理和重启加载的效率。

3. 修复SSAS元数据损坏 #

服务重启后列丢失，大概率是元数据存储出现了损坏：

• 执行元数据备份与重建：先在SSMS中右键模型选择Backup备份元数据，然后删除服务器上的模型，重新部署完整模型（包括分区和角色），再恢复备份的元数据，确保元数据与物理存储完全一致。
• 使用SSAS修复工具：停止SSAS服务后，执行命令 msmdsrv.exe -repair -instance <你的实例名称> -database <模型名称>，修复数据库的元数据存储结构。

4. 升级SSAS到最新累积更新 #

你当前使用的SSAS 14.0.226.1是SQL Server 2017的RTM版本，存在不少已知的元数据和字典存储bug，升级到最新累积更新（比如CU31及以上）能直接解决很多这类底层问题，升级后重新部署模型即可。

5. 优化SSAS服务启动配置 #

避免服务重启时因依赖问题导致元数据加载失败：

• 将SSAS服务的启动类型改为Automatic (Delayed Start)，让系统先加载完数据库引擎、网络服务等依赖组件后再启动SSAS，确保数据源连接在SSAS启动时能正常访问。
• 在SSMS中配置模型的自动恢复：右键模型选择Properties，找到Auto Recover选项并启用，设置合理的恢复间隔，让服务重启后自动修复元数据异常。

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