企业官网建设流程全解析

简介：面向SAP Basis管理员、IT运维及数据管理人员的SAP数据归档实操资料，专门解析SARA（SAP Archive Link Application）归档工具的完整用法。内容围绕采购订单等业务数据，讲解通过Write与Delete阶段进行归档删除，以缩减数据库体量、提升系统性能，同时满足历史数据合规留存要求。文档以图文形式记录了一次归档测试全过程：创建符合条件的PO、维护归档变式、在SM37中监控Write与Delete作业状态、检查EKKO表删除指示器，以及处理配置不当导致的归档失败问题；同时展开了deleting indicator从空到L的置位变化与删除触发条件。此外还说明了Read功能如何查询已归档数据，以及通过自定义变式只针对单个PO执行删除的灵活用法。资源共1个文件，为doc格式，整体约310KB，内容紧凑、步骤清晰，适合需要快速上手SAP数据归档的IT运维人员参考。已有1055人学习，属于较受欢迎的SAP实操笔记，对理解数据生命周期管理有不少帮助。

1. SAP数据归档SARA：不是删除按钮，是给几十亿行数据找后路

SAP系统跑上五六年，最头疼的不是功能不够，而是数据库越来越臃肿。某制造企业的物料凭证表从几十万行涨到上亿行，月底凭证过账慢得像卡了壳，备份时间从两小时拉到隔夜。这时候你打开事务码SARA——SAP标准的数据归档管理入口，它做的事情不是「删数据」，而是把已经关闭的业务数据从生产库搬到独立的归档文件里，保留可访问、可查询、可追溯的能力。SARA适合三类人：被数据库膨胀逼到墙角的基础运维、被业务问「三年前的凭证还能不能查」的应用负责人、以及准备做数据生命周期管理的架构师。本文只讲一件事：怎么用SARA把归档从「听说过」变成「能落地」。

2. 读懂归档对象与SARA的运转逻辑：先弄明白写、删、管、查四件事

2.1 归档对象：把散落的业务表绑成一捆

SAP数据归档的最小单位不是表，是归档对象（Archive Object）。为什么不是直接按表删？因为一张业务表永远不孤立。拿财务凭证举例，BKPF是凭证头，BSEG是行项目，还有文本表、状态表、增强表。如果只归档BSEG、留下BKPF，后续查凭证时行项目消失了，业务上直接翻车。

归档对象本质上是一个容器，定义了三样东西：一组关联的表、一个写程序、一个删除程序。SAP标准系统里，每个业务领域都预置了归档对象，比如物料凭证的MM_MATBEL、财务凭证的FI_DOCUMNT、销售订单的SD_VBRK。你用事务码AC01/AC02可以查看甚至自定义归档对象，但多数情况下用标准对象就够了。

自我开发的自定义表想归档，就得自己建归档对象，在AC01里指定头表、明细表、分配表，并写一个读数据函数。这一步门槛较高，常见做法是先复制一个相似的标准对象再改。我的建议是：能用标准对象就不自建，自建对象一旦关联关系没定义全，归档后就是一笔理不清的乱账。

2.2 SARA四个核心操作：写、删、管理、信息系统

打开事务码SARA，界面左边是归档对象列表，右边是操作面板。整个归档生命周期就四个动作。

第一是写（Write）：把数据库里符合条件的数据读出来，写入归档文件。这个动作不删除任何数据库记录，只是「复制」。第二是删（Delete）：根据写程序生成的归档文件，把已成功归档的数据从数据库里删除。这里的删除分测试模式和生产模式，测试模式只检查逻辑不真正删。第三是管理（Management）：查看已生成的归档文件、重读文件、管理文件生命周期。第四是归档信息系统（Archive Information System，简称AS）：为归档文件建索引，让用户可以通过事务码SARI做按条件的查询，而不是靠翻文件。

SAP交付的SARA只是操作台，真正的逻辑在ADK（Archive Development Kit）框架里。ADK规定了归档文件的格式、写入顺序和读取接口。归档文件一旦生成，结构就是固定的，SARA的写程序、删除程序、重读程序都通过ADK接口读写。理解这层关系，后面排查问题时就不会一头扎进应用代码里。

2.3 为什么归档后数据库空间没变：物理空间与逻辑删除

这是所有第一次用SARA的人都会踩的坑。在SARA里跑完写、跑完删，数据库表里的行数确实少了，可数据库文件大小几乎没变。于是业务问：归档到底有没有用？

答案在于删除程序的本质。SAP的删除程序执行的是标准DELETE语句，它把数据行从表中「逻辑删除」，但数据库段（Segment）中已分配的空间不会自动返还给数据文件。尤其在Oracle和HANA上，表的高水位线（High Water Mark）不会因为删除而降低，后续插入数据会复用这些空间，但文件大小和备份时间不会有明显变化。

所以归档的标准动作不是停在删除程序，而是删除之后做一次表重建（Table Rebuild）或空间收缩。在SAP里用事务码SE14可以重建单张表，用DBACOCKPIT可以做表空间级别的重组。这一步不做，SARA归档只完成了数据搬迁的一半。理解了「归档不等于空间立即释放」，你再看后面第4章的表重建，就知道那才是归档的临门一脚。

3. 用SARA跑通第一次数据归档：从查表大小到归档文件落地

3.1 第一步：归档前搞清楚哪些表最肥

归档不能拍脑袋，先做数据量分析。SAP内部没有直接显示所有表大小的标准报表，常见做法是查数据库层的字典视图。如果你的SAP跑在HANA上，可以执行下面这段SQL，按记录数和内存占用找出最占空间的表：

SELECT SCHEMA_NAME, TABLE_NAME, RECORD_COUNT, MEMORY_SIZE_IN_TOTAL / 1024 / 1024 AS size_mb FROM M_CS_TABLES WHERE SCHEMA_NAME = 'SAPABAP' AND RECORD_COUNT > 1000000 ORDER BY MEMORY_SIZE_IN_TOTAL DESC LIMIT 30;

这段SQL在HANA Studio或SAP HANA数据库控制台里跑。SCHEMA_NAME是SAP的数据库模式名，不同系统可能是SAPABAP、SAPERP等，先查自己系统的模式再替换。RECORD_COUNT是预估行数，M_CS_TABLES是HANA列存的表统计视图，返回的是内存中的估算值，不是精确值，用来做排序定位足够。跑出来的结果就是你归档候选表的优先级清单。

如果底层是Oracle，SQL改成查DBA_SEGMENTS：

SELECT SEGMENT_NAME, BYTES / 1024 / 1024 AS size_mb, SEGMENT_TYPE FROM DBA_SEGMENTS WHERE OWNER = 'SAPSR3' AND SEGMENT_TYPE = 'TABLE' ORDER BY BYTES DESC FETCH FIRST 30 ROWS ONLY;

Oracle视图里OWNER通常是SAPSR3或SAPR3。注意DBA_SEGMENTS需要足够权限，没有的话用USER_SEGMENTS代替，但只能看当前模式。实际项目中，我的习惯是先看哪些表超过500万行且月增长超过5%，这些表就是归档的优先候选。

3.2 第二步：选归档对象与创建变式

有了候选表之后，在SARA里输入对应的归档对象。以物料凭证为例，归档对象是MM_MATBEL，它覆盖了MKPF（物料凭证头）和MSEG（物料凭证行项目）以及关联的增强表。在SARA界面选择MM_MATBEL，点击「写」按钮，进入变式维护界面。

SAP的写程序需要一个变式（Variant）来定义归档条件。变式里的关键参数有三个。测试模式（Test Mode）：勾选后只生成测试归档文件，不进入生产归档队列。提交块大小（Commit Package Size）：每处理多少条数据提交一次，默认值通常能满足需求，数据量大的系统建议从5000开始调。归档截止日期（Archiving Cutoff Date）：只有业务关闭日期早于这个日期的数据才被归档，这是最核心的过滤条件。

创建变式时，务必把「测试模式」先勾上。测试运行时SAP会检查数据完整性、表关联，并生成一个不落地的测试归档文件。通过测试后，把变式里测试模式的勾取消，再跑一次生产写程序。这个两步走能拦截掉大部分归档对象配置错误。

下面是一个用SM36创建后台作业执行归档写程序的命令示例。实际生产环境中写程序建议放后台跑，因为海量数据的读取和文件生成可能耗时数小时。

# 通过SM36创建后台作业，作业步骤调用归档写程序 # 作业名：Z_ARCHIVE_MM_MATBEL_WRITE # 步骤类型：ABAP程序 # 程序名：程序名在SARA->写->选择变式后会自动显示 # 变式名：Z_MM_MATBEL_WRITE_V1 # 作业启动条件：立即执行或指定低峰时段

跑后台作业的好处是避免SAP GUI连接断开导致归档中断。作业日志可以在SM37里查看。写程序执行完毕后，SARA的「管理」界面会出现一个归档文件条目，里面包含文件路径、文件大小、数据条数。

3.3 第三步：执行删除程序，先测试再生产

写程序成功只是归档的复制阶段，接下来删除程序才真正释放数据库里的行。在SARA里对MM_MATBEL点击「删除」，同样要维护变式。删除变式里最重要的就是「测试模式」——SAP的删除程序测试模式会完整地检查归档文件与数据库记录的一致性，但不会执行删除，检查结果会留在日志里。

我一般会做三次验证再真正删除。第一次测试运行看日志有无未归档关联数据的报错；第二次测试运行在业务低峰期，确认没有锁冲突；第三次才切换生产模式。生产模式的删除程序每删除一批数据都会提交一次，中途出问题可以重新启动，已删除的数据不会回滚，但可以通过归档文件重读恢复。

删除程序的并行度是一个值得调的参数。大表归档时，删除程序慢了会拖垮整个归档窗口。常见做法是把包大小从默认值调大，比如从5000调到20000，减少事务提交次数，整体吞吐量会好不少。如果数据库是HANA，包大小对资源和速度的影响更加明显，太小会导致提交频繁、CPU消耗高，但太大也可能导致UNDO空间问题，需做一次压力测试确定合理值。

归档文件落地后，记得去文件系统看一眼实际产出。查看归档文件的命令通常是直接看SARA管理界面的路径配置。但运维团队更习惯用文件系统命令直接确认，比如：

# 查看归档目录下的文件，确认写程序已生成归档文件 ls -lh /saparchives/MM_MATBEL/2024/ | grep "MM_MATBEL" # 统计归档文件总大小，便于估算备份空间 du -sh /saparchives/MM_MATBEL/

归档文件默认存放在SARA里定义的逻辑路径下，通常是操作系统的一个目录。如果写程序执行成功但目录里没有文件，大概率是路径配置错了，或者文件被写到了别的应用服务器上。这一点在多应用服务器环境下尤其值得注意，归档文件只会生成在执行写程序的那台服务器上，别在其他服务器上找。

4. 归档完成之后：文件管理、归档重读与表重建

4.1 归档文件的全生命周期管理：备份与保留期

归档文件是数据的唯一副本，一旦数据库里的记录被删除，文件丢失等于数据灭失。SAP的归档文件默认是二进制格式，由ADK管理，文件本身没有自描述能力，必须配合SAP系统才能读取。这带来一个现实问题：文件不能随便挪、随便压、随便改名。

常见做法是归档文件落地后立即做一次磁带或对象存储备份，备份策略和数据库备份分开管理。归档文件的保留期原则上与业务法定保留期一致，比如财务凭证至少10年，而物料凭证可以按企业内控要求设定。在存储成本允许的前提下，我不建议设置「过期即删除」的策略，宁可多留一年也不要因为空间压力把历史数据提前销毁。归档文件的生命周期管理可以在SARA的管理界面里做状态标记，标记为「已备份」的文件才能安全地从生产存储迁移到低成本存储。

4.2 归档重读：业务要查三年前的凭证，怎么办

归档做完，业务部门最关心的是还能不能查历史数据。数据库里查不到了，但通过SAP的归档信息系统（AS）可以按条件查询。在事务码SARI里，归档信息系统按归档对象组织，你选择一个归档对象，输入查询条件，系统会去归档文件里搜索并展示数据。

要让AS可用，必须在SARA里为归档对象配置索引。配置信息包括索引字段组合，比如物料凭证归档对象可以按凭证日期、物料编号、工厂代码建立分析索引。配置好之后，每次写程序生成的归档文件会自动纳入索引范围。这里有一个容易被忽略的点：归档信息系统的索引本身也占用存储空间，索引字段越多，占的空间越大，查询越快。我的建议是只对业务上真实会查的字段建索引，不要贪多。

如果业务需要看到归档数据，但没有配置AS，那就只能靠ABAP里调用归档读取函数来读，成本高且不通用。对绝大多数企业来说，在第一次归档前就把AS配置好，是最省事的路径。配置AS的工作最好归档前做，因为一旦归档文件已经生成，再补索引需要逐个文件重新读取，数据量大的时候非常耗时。

4.3 表重建：把空间真正还给数据库

这是归档流程里最容易被跳过、也最让后续运维后悔的一步。删除程序跑完之后，表里的数据少了，但数据库段的空间并没有缩回来，尤其在没有开启表空间自动收缩的Oracle系统上。第2章说过，高水位线是罪魁祸首。解决方式是用事务码SE14对归档涉及的核心表做重建。

SE14的操作方式是这样的：进入事务码SE14，输入表名（比如MSEG），点击「重建」按钮，调整存储参数后执行。重建表的本质是把表移动到新的段里，只迁移现有数据，然后释放旧段空间。这个过程会锁表，必须在业务低峰期执行，且执行前要确认表上没有长事务。

更彻底的做法是在DBACOCKPIT里做表空间级别的重组（Reorg），把同一表空间里所有表一起压缩。步骤是：登录DBACOCKPIT，进入「空间管理」，选择目标表空间，执行重组。表空间重组期间，该表空间内的写入会受影响，所以必须安排在停机窗口。对HANA数据库，表重建的概念不如Oracle强烈，但删除大量数据后同样建议执行一次「表合并」或者更新统计信息，否则优化器可能基于过期统计信息生成低效的执行计划。

5. SAP归档避坑：五个让SARA项目翻车的常见问题

5.1 数据孤儿：归档了行项目，留下了凭证头

现象：归档删除程序跑完后，BKPF表里还有大量凭证头，但BSEG表里对应的行项目已经没了。业务查凭证时报「凭证不完整」，财务月结直接中断。

原因：归档对象的表关联定义不完整，写程序只选择了部分表，或者自定义归档对象时遗漏了关联表。尤其是添加了增强表、扩展字段后，归档对象没有同步更新，导致增强表数据留在库里、主表数据被带走。

解决：归档前用归档对象检查报表跑一遍依赖分析，确认写程序包含所有关联表。已经出现孤儿数据的，用SARI从归档文件里重读主表数据，与数据库表做全量对比，再把缺失数据补回去。这个修复过程没有一步到位的标准报表，通常得写ABAP联查。我的建议是归档对象变更后，必须重新执行完整测试归档，不要只测新增表。

5.2 删除程序越跑越慢，最后超时

现象：生产删除程序启动后，跑到两小时甚至更久，作业状态一直是运行中，数据库CPU升高，前台业务开始投诉响应慢。

原因：删除程序每删除一定行数就要提交一次事务，而大表的删除会触发索引维护和UNDO日志增长。包大小设置过小会让提交次数激增，导致整体速度被提交操作拖住；删除程序并行进程数配置过高，又会和业务事务争抢资源。

解决：删除程序的包大小从默认值往上调，在非生产环境用小数据量做一轮测试，找到提交频率和资源消耗的平衡点。同时限制删除作业的并行进程数，避免它和联机业务抢CPU。从经验来看，包大小设定在10000到30000之间是多数企业的合理区间，但最终还是以实际压测为准。

5.3 归档文件路径不存在或权限不对

现象：SARA写程序执行成功，日志显示「归档文件已生成」，但文件系统里找不到任何文件，或者文件生成在错误的目录下。

原因：SAP系统是多应用服务器架构，SARA里配置的逻辑路径必须映射到所有应用服务器上。如果只在一台服务器上创建了目录，写程序又被调度到了另一台服务器，归档文件就会写到不存在的地方，程序报错后事务回滚。另一种情况是操作系统权限不够，SAP启动用户没有目录的写权限，文件生成失败。

解决：在所有应用服务器上使用相同的绝对路径创建归档目录，并用SAP启动用户做一次写入测试。路径配置修改后，重启一下SAP的归档服务，确保所有服务器重新读取配置。归档开始前，批量创建好各归档对象的目录结构，不要等运行时才建。

5.4 归档后业务报表查不到历史数据

现象：归档完成后，业务部门经典的日报表、年度对比报表查不到几年前的数了，而报表本身没有报错，只是数据缺失。

原因：报表程序是直接查数据库表的，归档后数据已经物理删除，报表不会自动去读归档文件。SAP对这类问题提供了归档信息系统和报表的集成方案，但需要报表程序显式地调用归档读取接口。大部分自定义报表压根没写这个逻辑，所以数据「消失」了。

解决：归档前拉一张清单，列出所有涉及被归档表的报表程序，逐个确认是否需要历史数据访问能力。需要保留历史查询的，要么在报表里加上归档读取逻辑，要么给业务提供SARI的查询入口。这件事最好在归档立项阶段就评估，归档后才发现，报表改造的返工成本比归档本身还高。

5.5 归档测试文件被误当成生产文件恢复

现象：测试环境归档了一部分数据，后来测试库刷新时，DBA把测试归档文件一并恢复到了生产环境的归档目录，生产系统里出现了一堆「幽灵归档会话」。

原因：归档文件在文件系统层面没有环境标识，同一逻辑路径下可以混放测试和生产文件。测试环境的归档会话ID和生产环境冲突时，SAP会把数据写串，业务查询归档数据时结果错乱。

解决：测试环境和生产环境的归档物理路径分离，运维规范里明确禁止跨环境拷贝归档文件。SARA管理界面里对测试归档文件及时标记状态为「测试运行」，不要让测试文件进入正式的归档生命周期。归档文件恢复操作必须有双人复核，DBA和SAP Basis各出一个确认清单。

6. 把SARA归档做顺手：监控、作业链与归档验证三个习惯

6.1 归档会话监控：别等业务发现才处理

归档做完了不等于可以撒手。SAP的归档会话可以通过SM37查看作业状态，但归档文件是否完整、删除是否彻底，SM37看不出来。我现在的习惯是每周一早晨扫一遍SARA管理界面，把上周所有归档会话过一遍。重点看三个指标：归档文件条数与写程序日志是否一致、删除程序日志有无警告、归档文件目录大小环比是否正常。这个习惯救过我很多次。有一次物料凭证归档文件的条数比日志少了两万条，排查发现是磁盘空间不足导致文件写入中断，但程序没有报错退出，如果等到业务查账才发现，补数会非常痛苦。

6.2 把归档做成作业链，减少人工干预

成熟的SAP运维环境里，归档不应该靠运维手工点按钮，而是做成跨事务码的作业链。常见的作业链是：归档写程序（后台作业）→ 归档删除程序（后台作业）→ 归档文件备份（系统命令）→ 表重建（SE14作业）。每一步由前一步的成功状态触发，失败就停止后续步骤并告警。

作业链的调度可以用SAP标准的后台作业调度，也可以用系统外部的运维调度平台。关键是每个作业步骤之间留足时间缓冲，删除程序必须在写程序完全结束后再启动，中间至少留15分钟间隔，防止文件系统缓存还没刷完。表重建作业务必放在业务低谷，且要设置作业超时和失败回滚通知，否则锁表锁到业务上线就真的翻车了。

6.3 归档验证：每次归档后花十分钟查一致性

归档验证不该等到审计才做，每次归档周期都应该有验证动作。验证分三层。第一层在SAP里：对比表中数据与归档文件条数，做几条抽查，确认关键业务数据都包含在归档文件中。第二层在文件系统：执行一行校验命令，确认归档文件的文件数和字节数与SARA记录匹配。第三层在业务侧：随机挑几个业务维度，在SARI里查历史数据，确认能查到、查得对。

这里放一个我常用的归档完整性校验命令模板，可以直接存成脚本定期执行：

#!/bin/bash # 校验归档文件完整性：对比SARA记录与文件系统实际数据 ARCHIVE_BASE="/saparchives" OBJECT="MM_MATBEL" YEAR="2024" # 统计该归档对象在指定年份的数据文件数 FILE_COUNT=$(find ${ARCHIVE_BASE}/${OBJECT}/${YEAR} -name "*.data" | wc -l) # 统计总字节数，用于与SARA管理界面比对 TOTAL_SIZE=$(du -sb ${ARCHIVE_BASE}/${OBJECT}/${YEAR} | awk '{print $1}') echo "归档对象: ${OBJECT}" echo "文件数量: ${FILE_COUNT}" echo "总字节数: ${TOTAL_SIZE}" # 将输出结果与SARA管理界面的统计值人工或自动比对

脚本输出的文件数和字节数，与SARA管理界面里的归档文件统计对比。只要每次归档后花十分钟跑一遍，归档数据的一致性就有基本保障。不要嫌麻烦，等发现归档文件损坏时，重建的代价远超这十分钟。

做SAP数据归档这几年，我最大的体会是：SARA本身操作不复杂，复杂的是归档前后的配套动作。数据量分析、变式配置、文件备份、表重建、验证机制，任何一个环节偷懒，都会在几个月后以更高的成本找回来。把归档当成一个完整的运维流程来做，而不是一个事务码，项目就稳了。希望这篇文章能帮你把SAP归档这条路上该避的坑提前绕开。

本文还有配套的精品资源，点击获取