SAP运行期数据归档 库容瘦身、留存与合规读取的实施方法

上线五年以上的SAP系统，库容膨胀几乎是绕不开的问题：业务凭证、物料移动和生产订单逐年累积，月末跑批越来越慢，备份窗口越拉越长，硬件扩容做了几轮仍然追不上数据增长。对这类存量系统，运行期数据归档是把库容降下来、同时守住历史数据留存与读取合规的主要手段。

SAP运行期数据归档是在系统持续生产运行期间，按归档对象把已完结业务的历史数据写入归档文件、从数据库中删除，并保留合规检索与读取能力的数据生命周期管理机制。它解决的不是单一的性能问题，而是库容、跑批效率、备份成本与合规留存四件事的平衡。

整套方法可以概括成一条主线：先算清楚库容膨胀的代价账，再定归档对象与保留期口径，随后按分析、预处理、写入、删除、读取验证的顺序执行，最后用归档索引守住合规读取的底线。上线多年、正在为扩容预算和月结窗口发愁的存量系统，适合按这条主线推进。

为什么库容会拖垮系统：上线五年后的四重代价

库容膨胀最先被感知的地方往往不是数据库本身，而是月末结账：凭证和单据数量翻了几倍之后，月结作业扫描的表越来越大，跑批窗口从几个小时拉长到通宵；与之相伴的是报表查询变慢、日常单据操作响应下降，业务部门开始抱怨系统不好用了。

更深层的代价在基础设施一侧。备份窗口随库容线性拉长，恢复演练的时间同样变长，灾备指标被动恶化；存储和内存的扩容预算一轮接一轮，尤其在内存数据库架构下，容量增长直接换算成硬件与许可开支。库容膨胀真正的成本不在存储介质本身，而在月末跑批窗口、备份恢复时间和每一轮扩容的预算审批里。多数企业第一次认真讨论归档，就是在第三轮扩容申请被管理层质疑之后。

先划清边界：运行期归档不是升级迁移前的数据分层

很多企业第一次听说归档，是在ECC升级S/4HANA的项目里：迁移前把历史数据分成迁走、归档、清理三类，目的是压缩切换窗口、控制迁移风险。那是迁移场景下的一次性数据分层。本文讲的运行期归档是另一个场景：系统没有升级计划也要做，对象判断跟着数据生命周期走，而不是跟着切换计划走，做完之后还要转为年度例行机制。

两者容易混，判断标准只有一条：动作如果是为某次系统切换服务、切换结束就收队，那是迁移数据分层；动作如果是为生产库建立长期的数据进出秩序、与升级与否无关，才是运行期归档。把两者混着做的常见后果，是升级项目结束后库容重新回涨，再也没有人接手治理。

归档对象怎么选：业务完结、低频访问与保留期依据

SAP的数据归档以归档对象为单位执行，每个归档对象由SAP预定义，界定一组业务数据及其从属关系，凭证归凭证、订单归订单，不能随手挑几张表删数据。一个对象能不能进本轮归档，判断条件有三条：业务已经完结、日常操作基本不再访问、保留期口径已经明确。三条缺一条，都先不动。

常见的标准归档对象与保留期参考如下表，对象名称以系统内事务码AOBJ的归档对象定义为准，不同版本与行业方案会补充更多对象；保留期一栏是国内制造业常见的确定思路，最终以企业自己的制度为准。

保留期不是IT部门能单独决定的数字。财务口径上，会计档案管理办法（财政部、国家档案局令第79号，2016年起施行）规定会计凭证和会计账簿保管期限为30年，年度财务报告永久保存，月度、季度、半年度财务报告10年，保管期从会计年度终了后的第一天起算。业务口径上，质量追溯、售后备件、合同争议可能要求更长留存，部分行业的质量体系对记录年限还有额外要求。归档时间必须不早于这些口径中的最长年限。

保留期由谁定：法规给下限，业务给上限

归档的时间底线由最长的合规留存年限决定，而不是由存储紧张的月份决定。实操中建议财务、业务关键用户、审计和IT四方一起会签保留期矩阵：法规年限给下限，业务追溯需要给上限，两条线之间再按数据访问频率排优先级。未清项、未结订单、涉及未决争议的数据，无论多老都不能进归档范围，这条要写进口径文件作为硬约束。

归档怎么执行：分析、预处理、写入、删除与读取验证

执行层面，SAP提供事务码SARA作为中央归档管理入口，底层由ADK归档开发框架驱动，写入、删除、重载基于同一套归档文件机制运转。一轮完整的归档按五个步骤推进，前后顺序不能颠倒。

1. 分析：用归档对象自带的读取程序和变式圈定候选数据，比如按公司代码加过账日期划区间，先以只读方式核对数据量级，预估能释放多少库容，再结合数据库空间监控确认本轮的优先级。
2. 预处理：部分归档对象（财务凭证是典型）要求先跑预处理程序，系统逐条检查数据是否满足可归档条件，例如凭证是否已清账、是否仍被未完结流程引用，检查通过后打上可归档标识。
3. 写入：执行写入程序生成归档文件，文件先写到归档路径定义的文件系统，再按存储策略转存外部存储；此阶段只生成文件，生产库里的数据原样保留。
4. 删除：归档文件完成校验和备份之后才运行删除程序。删除程序按归档文件回读定位数据库记录逐条删除，不是按日期直接清表，删除量与写入量严格对应。
5. 读取验证：删除完成后按比例抽样，走归档读取路径调出原凭证和原单据，确认检索索引可用、单据显示完整，再关闭本轮归档会话并记录归档日志。

五个步骤里有两条纪律。第一，删除程序以归档文件为唯一依据回删数据，所以归档文件的备份与完整性校验必须先于删除完成，这个顺序不能反；文件没有备妥就删除，等于把合规链握在单点故障手里。第二，写入和删除作业放在业务低峰窗口后台执行，避开月结、备份作业的资源竞争，首轮执行前先在测试系统完整演练。

归档后怎么查：合规读取的机制与准备

归档不等于查不到，但查得顺不顺，取决于归档时的准备。SAP的读取路径有两层：对象级读取在SARA里直接进行，输入凭证号或单据号即可调出归档原单，适合偶尔的单笔查询；分析型检索依靠归档信息系统，事务码SARI，通过写入阶段生成的InfoStructure归档索引检索，索引里保存检索字段和指向归档文件的指针，配合Archive Explorer可以按期间、科目、往来单位等条件检索归档数据。

合规读取能力不是归档完成后再补的功能，而是由写入阶段的索引生成和归档文件存储方案一起决定的。审计和年度对账考验的正是第二层：没有建索引的归档库，遇到按条件批量检索的历史问题只能逐单调阅，效率差距很大。因此索引结构要在写入之前定好，归档文件与索引文件都要纳入备份策略。

长期存储方案同样要在架构层面明确。常见做法包括保留在文件系统、转存外部内容服务器，以及条件允许时采用近线存储；SAP近年提供的ILM信息生命周期管理方案还把留存规则与读取管理纳入同一框架，具体形态建议按系统版本和存储架构评估后确定。

实施要点与常见的坑：试点对象、存储纪律与长期机制

第一轮归档建议从风险低的对象试点，例如变更文档、接口类历史数据，跑通五步流程并验证读取路径后，再进入财务凭证这类合规敏感对象。凭证类对象直接关系审计，试点阶段宁可慢，也要把抽样验证和归档日志的规矩立起来，避免正式执行时才发现读取路径没打通。

常见的坑集中在四处：未清项混进归档范围，预处理程序只能挡住系统级的可归档性，挡不住口径错误，保留期矩阵必须先审；自建表的历史数据没有标准归档对象，需要基于ADK框架开发自定义归档对象，这部分工作量常被漏估；归档文件存储在单一路径没有冗余，文件损坏后合规链断裂；以及一次性项目做完就收队，没有转为年度例行机制，两三年后库容回涨到原点。

把归档做成机制的做法是：每年固定窗口（比如年中月结后）执行一轮，Basis负责流程与后台作业，财务和业务关键用户负责口径确认，基础设施侧同步核对备份策略。上线五年以上的存量系统，这类库容治理通常并入SAP Basis运维服务的年度计划滚动执行。工博科技在存量系统运维项目中，一般先做一轮库容与表增长评估，再排定对象优先级和窗口安排，避免上来就直接碰凭证类对象。

FAQ

SAP数据归档会把业务数据删没了吗，审计还能查到吗？

归档分写入和删除两步：数据先完整写入归档文件并完成备份校验，之后才从数据库删除。删除后原单据仍可通过归档读取路径调出，财务凭证类对象配合归档索引还能按期间、科目等条件检索，审计和年度对账的读取需求在机制上有保障，前提是索引结构与归档文件的存储方案在设计阶段就落实。

SARA归档和ECC升级S/4HANA前的数据清理是一回事吗？

不是一回事。升级迁移前的数据分层是一次性动作，服务于压缩切换窗口、控制迁移风险，跟着项目计划走；运行期归档是系统持续运行期间的常态化库容治理，跟着数据生命周期走，与是否升级无关。两者判断历史数据下线的逻辑可以互相参考，但驱动场景、执行节奏和后续机制完全不同。

归档应该多久做一次？

建议转为年度例行机制，比如每年年中月结后执行一轮，平时用库容与表增长监控触发提醒。上线五年以上的系统首轮归档通常要分几个月处理多年存量，之后每年的增量归档工作量会明显小于首轮。具体频率取决于业务数据增长速度和库容目标，由Basis与业务部门共同确定。

上线只有两三年的SAP系统需要做归档吗？

通常不紧迫。两三年内系统数据量多处于可控区间，重点放在建立库容监控和保留期口径上即可。但单据量极大的场景例外，比如高频出入库、大批量物料移动的业务，数据增长快，可以提前评估。是否启动归档的判断依据是库容增长曲线和月结窗口的变化，而不是单纯的上线年限。

归档对象的保留期该怎么定，国内有什么依据？

财务口径的主要依据是会计档案管理办法（财政部、国家档案局令第79号）：会计凭证和会计账簿保管30年，年度财务报告永久保存，月度、季度、半年度财务报告10年，保管期自会计年度终了后第一天起算。业务口径还要叠加质量追溯、合同管理等行业要求，建议财务、业务、审计、IT四方会签保留期矩阵后再执行。

自建表里的历史数据怎么归档？

SAP标准归档对象只覆盖标准业务数据，自建表需要基于ADK框架开发自定义归档对象，把表的读取逻辑、删除程序和索引结构纳入同一套归档机制。这部分工作量在项目评估时容易漏估，建议与标准对象分批实施，先标准后自建，自建对象上线前在测试系统完整验证删除与读取链路。

归档做完以后系统会明显变快吗？

库容下降对月结跑批、备份和恢复时间的改善，在多数存量系统上可以直接观察到，日常单据操作的响应也会受益于表和索引变小。但归档不是性能问题的通用解法，如果瓶颈出在个别程序的执行计划或配置上，仍需按性能排查路径单独定位。归档改善的是数据整体规模，立项前先建立合理预期。

总结

运行期数据归档的本质，是给上线多年的SAP系统建立一条数据的出口规则：对象与保留期先定口径，SARA里分析、预处理、写入、删除、读取验证五步按纪律走，归档索引和文件存储在写入之前就设计好。做到这三点，库容瘦身与合规留存不是取舍关系，而是同一套机制的两面。

每家企业的库容结构、数据增长速度和保留期口径差别很大，第一轮归档从哪些对象下手、窗口怎么排，值得先做一轮评估再动手。工博科技的Basis运维团队在存量系统治理中，通常先输出库容与表增长评估，再与财务和业务部门确认口径，让归档从第一轮起就按机制运转。