的配置与价值)
SAP数据归档的架构哲学：从SARA到SARI的协同设计解析
当系统管理员第一次点击SARA事务码执行数据归档时，往往只关注"如何清空数据库表"这个单一目标。直到某天业务部门突然需要查询三年前的物料凭证，却发现归档后的数据像被扔进了一个黑洞——这时才会意识到，SAP的归档机制远非简单的数据搬家，而是一套精密的数据生命周期管理系统。本文将带您穿透操作步骤的表象，从架构设计的视角重新理解SARA与SARI这对黄金组合的工作机制，特别是归档信息结构(Archive Information Structure)在其中扮演的关键角色。
1. 归档与查询的分离设计：SAP的架构智慧
在传统认知里，数据归档往往被简化为"将旧数据移动到廉价存储介质"的过程。但SAP的设计团队在1990年代就预见到了一个关键矛盾：存储效率与查询便利性本质上是相互冲突的。这种前瞻性思考催生了SARA(归档执行)与SARI(归档查询)的分离式架构。
1.1 为什么不能直接查询归档文件？
当我们用SARA对MM_MATBEL(物料凭证)执行归档时，系统实际上完成了三个层次的操作：
- 物理存储迁移：将MKPF/MSEG等表中的数据行转移到扩展名为
.ADA的归档文件中 - 数据库空间释放：原表中的数据行被删除，仅保留归档指针
- 索引重建：相关数据库索引被优化以提升现用数据查询效率
此时若直接查询归档文件会遇到两个致命问题：
- 性能灾难：每次查询都需要解压并扫描整个归档文件（想象一个包含百万级凭证的10GB文件）
- 语义断层：归档文件只保留原始表结构，无法支持按采购订单、成本中心等业务维度的聚合查询
* 典型归档文件结构示例（伪代码） DATA: lt_archive TYPE TABLE OF mm_matbel_arc WITH HEADER LINE. LOOP AT lt_archive WHERE belnr = '4900000123'. " 全表扫描性能极低 " 处理逻辑... ENDLOOP.1.2 归档信息结构的桥梁作用
SAP的解决方案是引入**归档信息结构(Archive Information Structure)**作为中间层。这个设计类似数据仓库中的星型模型：
[归档文件(.ADA)] → [归档信息结构] ← [查询界面]以MM模块最常用的SAP_DRB_MATBEL1结构为例，其核心字段包括：
| 字段名 | 源表 | 索引标志 | 业务含义 |
|---|---|---|---|
| BELNR | MKPF | ✓ | 物料凭证编号 |
| GJAHR | MKPF | ✓ | 会计年度 |
| MATNR | MSEG | ✓ | 物料编号 |
| WERKS | MSEG | ✓ | 工厂 |
| MENGE | MSEG | 移动数量 | |
| DMBTR | MSEG | 金额 |
这种设计实现了两个关键突破：
- 查询加速：对常用筛选条件建立索引，避免全表扫描
- 业务语义：跨表关联关键字段，支持按业务维度检索
2. MM_MATBEL归档的实战解剖
让我们以物料凭证归档为例，看看这套机制如何实际运作。假设某制造企业需要归档2020年度的200万条物料凭证。
2.1 归档执行阶段(SARA)
在SARA中配置MM_MATBEL归档对象时，高级选项里藏着关键设置：
* 归档对象MM_MATBEL的标准配置参数 ARCHIVE_PARAMETERS = VALUE #( DELAY_INDEX_UPDATE = 'X' " 延迟索引更新以提升性能 COMPRESSION_LEVEL = '6' " 中等压缩比平衡CPU与存储 MAX_ARCHIVE_SIZE = '10' " 单个归档文件最大10GB ).常见误区：许多管理员会忽略"Postprocessing"标签页中的设置。实际上，这里才是控制是否自动填充信息结构的关键：
注意：如果在此阶段未勾选"Update archive information structures"，归档后需要手动执行SARI的填充操作
2.2 信息结构填充机制
当发现已归档数据无法查询时，SARI中的"Fill Structures"操作实际上触发了以下后台逻辑：
- 元数据映射：根据SAP_DRB_MATBEL1的定义，定位归档文件中对应字段
- 批量加载：采用分段(Block)方式读取归档文件，避免内存溢出
- 增量更新：仅处理新增归档会话，跳过已处理的存档ID
* 简化版的填充逻辑（伪代码） DATA: lt_archive_ids TYPE TABLE OF ar_objectid. " 获取未处理的归档会话ID SELECT objectid INTO TABLE lt_archive_ids FROM ar_stat WHERE object = 'MM_MATBEL' AND struct_id = 'SAP_DRB_MATBEL1' AND filled = space. " 分段处理每个归档文件 LOOP AT lt_archive_ids INTO lv_archive_id. CALL FUNCTION 'ARCHIVE_GET_DATA' EXPORTING archive_id = lv_archive_id TABLES data = lt_mseg_data. " 转换并插入信息结构 MODIFY sap_drb_matbel1 FROM TABLE lt_transformed_data. ENDLOOP.2.3 性能优化实战技巧
对于超大型归档项目，以下策略能显著提升效率：
策略对比表：
| 方法 | 适用场景 | 风险提示 |
|---|---|---|
| 夜间分批填充 | 生产系统敏感时段 | 需监控锁等待 |
| 直接更新数据库 | 紧急修复场景 | 需DBA协助，跳过标准校验 |
| 使用并行处理 | 硬件资源充足 | 可能引发系统负载峰值 |
| 预过滤归档数据 | 只需部分数据进入信息结构 | 需自定义ABAP程序 |
3. 归档策略设计的系统工程
优秀的归档方案必须考虑整个数据生命周期的需求。以下是某汽车零部件企业的真实案例：
3.1 多阶段归档策略
该企业将物料凭证分为三个处理阶段：
- 热数据（当前年度）
- 保留在原表
- 全维度查询支持
- 温数据（前2-3年）
- 已归档但保持信息结构更新
- 开放有限字段查询
- 冷数据（3年以上）
- 仅保留原始归档文件
- 需特殊申请才能恢复查询
3.2 容量规划模型
通过以下公式可预估信息结构所需存储：
总记录数 = 年凭证量 × 保留年限 索引大小 ≈ 总记录数 × 120字节 数据大小 ≈ 总记录数 × 平均字段长度示例计算：
- 年凭证量：300万
- 保留5年温数据
- 平均字段长度：200字节
总容量 ≈ (300万×5)×(120+200) ≈ 4.8TB3.3 自动化监控方案
建议创建定期作业检查以下关键指标：
* 监控归档状态的ABAP程序片段 SELECT objectid, ar_date, fill_date FROM ar_stat WHERE object = 'MM_MATBEL' AND fill_date < sy-datum - 3. " 超过3天未填充的会话 IF sy-subrc = 0. " 触发告警通知 CALL FUNCTION 'ALERT_CREATE' ... ENDIF.4. 超越MM模块：归档架构的通用法则
虽然本文以MM_MATBEL为例，但SAP的归档设计哲学适用于几乎所有模块：
4.1 跨模块模式对比
| 模块 | 典型归档对象 | 特殊挑战 | 最佳实践 |
|---|---|---|---|
| FI | FI_DOCUMNT | 会计年度切换复杂性 | 按年度分片信息结构 |
| SD | SD_VBAK | 订单状态流转逻辑 | 预过滤取消订单 |
| HR | PA0001 | 数据隐私要求 | 加密归档文件 |
| CO | CO_ORDER | 成本分析维度多样 | 多信息结构并行 |
4.2 未来演进方向
随着S/4HANA的普及，归档机制正在发生重要演变：
- Native Storage Extension：直接利用HANA的内存计算能力
- Dynamic Tiering：自动冷热数据分层
- Cloud Archiving：与对象存储服务集成
例如，在S/4HANA 2022中可以使用以下新语法：
-- 使用SQL直接查询归档数据 SELECT * FROM "MATBEL_ARCHIVE" WHERE MATNR = '100-100' WITH ARCHIVAL; -- 自动包含归档数据这种演进不是对传统SARA/SARI的取代，而是架构思想的延续——在数据量爆炸的时代，智能分层与语义一致性的平衡比任何时候都更重要。
