简介这份文档面向SAP Basis与IT运维人员聚焦SARA数据归档这一数据库优化关键环节帮助解决长期数据积累导致数据库膨胀、系统性能下降的问题。资源包共1个doc文件约310KB内容围绕归档全流程展开涵盖创建采购订单、Write与Deletion阶段操作、SM37作业状态监控、SE11删除标识检查、归档对象定制配置以及Read查询等要点并配有可归档PO条件判断与全面测试的实操记录。已有1055人学习下载适合需要掌握SAP归档配置与数据生命周期管理的中高级管理员参考。读者可借此理解归档变式维护、作业调度与删除标识置位之间的关联掌握从配置排查到归档删除的完整思路提升SAP环境下的数据管理效率与法规遵从能力。1. SAP 数据归档 SARA为什么你的生产库越跑越慢而答案可能不在代码里很多做 SAP 的同行都遇到过这个场景一个上线五六年的生产系统数据库体积从最初的几百 GB 涨到了好几个 TB用户抱怨报表越跑越慢DBA 说磁盘快满了BASIS 查了半天发现应用服务器负载并不高最后问题指向一个被长期忽略的动作——数据归档。而 SAP 里做数据归档最核心的事务码就是 SARA。SARA 不是一个“点一下就能瘦身”的按钮。它是一个归档管理框架的入口背后挂着一整套归档对象Archiving Object、前置处理程序Preprocessing、写入程序Write、删除程序Delete和存储管理。你真正要理解的是哪些数据能归档、归档到哪里、归档之后业务还能不能查、删除会不会破坏数据一致性。这篇文章面向的是正在被数据库膨胀困扰的 SAP BASIS、ABAP 开发和 DBA我会把 SARA 的选型逻辑、配置步骤、参数设置和踩坑经验拆开讲让你看完能判断自己的系统该不该做归档、从哪个对象下手、怎么验证结果。2. SARA 归档框架的底层逻辑与归档对象选型2.1 SARA 到底管了什么五个阶段拆开看SARA 的本质是一个调度框架它把数据归档拆成五个阶段每个阶段对应一个独立的执行步骤。你在 SARA 初始界面看到的那些按钮其实就是这五个阶段的入口。第一个阶段是变式维护Variant Maintenance。你需要为归档对象创建一个变式告诉系统“我要归档哪个时间段的数据”“每次打包多少条”“测试模式还是生产模式”。变式是后续所有步骤的基础没有变式什么都跑不了。第二个阶段是预处理Preprocessing。这个阶段会执行归档对象自带的前置程序通常做两件事检查数据是否满足归档条件比如是否已完全清账、是否没有未清项以及把待归档数据的索引写入归档文件。预处理不删数据它只是“标记”。第三个阶段是写入Write。这是真正把数据从数据库表里读出来、写到归档文件里的步骤。归档文件可以落在应用服务器的文件系统也可以直接交给外部存储管理系统比如常见的 Content Repository 或第三方归档方案。写入完成后数据还在数据库里但已经有一份完整的归档副本了。第四个阶段是删除Delete。删除程序根据写入阶段生成的归档文件把数据库中对应的数据行删掉。这一步才是真正释放数据库空间的动作。删除必须依赖成功的写入结果如果写入没完成或者归档文件不可读删除会失败。第五个阶段是存储管理Storage Management。归档文件不能一直放在应用服务器本地需要转移到长期存储介质上同时保证需要时能读回来。SARA 通过 Content Repository 来管理这个环节。理解这五个阶段的意义在于你可以在任意阶段停下来检查不会因为跑了一半就不可逆。尤其是删除阶段我强烈建议第一次跑的时候用测试模式确认无误再正式执行。2.2 归档对象怎么选从表体积和业务闭环两个维度判断SARA 支持大量标准归档对象比如 FI_DOCUMNT 对应财务凭证、MM_MATBEL 对应物料凭证、SD_VBRK 对应开票凭证、IDOC 对应 IDoc 数据。选哪个不是拍脑袋决定的我一般从两个维度来判断。第一个维度是表体积。用 DB02 或者 SE16N 看哪些表的行数和占用空间排在前列。常见的大表包括 BKPF/BSEG财务凭证、MSEG物料凭证行项目、VBRK/VBRP开票、EDIDC/EDID4IDoc。如果某张表的行数超过千万级而且大部分是历史数据那它就是归档的候选对象。第二个维度是业务闭环。归档不是单纯删数据它要求这批数据在业务上已经“完结”。比如财务凭证归档的前提是会计年度已关闭、没有未清项、没有被后续凭证引用。物料凭证归档的前提是相关采购订单、发票校验都已完成。如果业务上还有关联操作强行归档会导致后续流程报错。我通常的做法是先用 DB02 找出 Top 10 大表再对照 SAP 标准归档对象清单看哪些大表有对应的归档对象。然后和业务部门确认这些数据的业务状态确认可以归档之后再动手。这个顺序不能反先斩后奏的代价可能是生产事故。2.3 归档对象的依赖关系别忽略检查报告每个归档对象在 SARA 里都有一个“检查/管理”选项里面包含了依赖检查。比如 FI_DOCUMNT 归档之前系统会检查是否有未清项、是否有被其他模块引用的凭证。这些检查不是可选项是必须通过的。有一个容易被忽略的点某些归档对象之间存在依赖。比如你先归档了物料凭证但采购订单还没归档后续做采购订单归档时可能会因为找不到对应的物料凭证而出错。所以归档顺序也很重要一般建议从业务链的末端往前推先归档最独立的数据。3. 用 SARA 跑通一次完整归档从变式到删除的操作步骤3.1 创建归档变式参数怎么填才不出错进入 SARA输入归档对象比如 FI_DOCUMNT点击“变式维护”或者直接点“写入”时会提示你创建变式。变式维护界面里你需要关注几个关键参数。 以下为 SARA 变式维护中常见参数说明非实际代码用于解释参数含义 归档对象FI_DOCUMNT 变式名称Z_FI_ARCH_2024 公司代码1000 会计年度2020 凭证类型SA总账凭证 测试运行勾选首次必须勾选 详细日志勾选便于排查 最大处理条数10000根据系统资源调整公司代码和会计年度是最核心的筛选条件。我一般建议按会计年度归档不要跨年度混在一起否则后续查询和恢复都会很麻烦。测试运行选项在第一次执行时一定要勾上它会模拟整个流程但不实际删除数据让你看到哪些数据会被处理、有没有报错。最大处理条数这个参数很多人不注意。如果一次处理太多数据可能造成数据库锁等待、日志暴涨、甚至会话超时。我的经验是第一次跑设小一点比如 5000 到 10000观察系统资源消耗后再逐步放大。3.2 预处理和写入观察什么、等多久变式创建好之后按顺序执行预处理和写入。这两个步骤都可以在后台运行通过 SM37 查看作业日志。预处理阶段主要看检查报告。如果报告里出现大量“不满足归档条件”的记录说明你的筛选条件太宽了或者这批数据确实还有业务关联。这时候不要强行继续先搞清楚原因。写入阶段的时间取决于数据量和存储性能。我遇到过写入 100 万条财务凭证耗时 4 个小时的情况也见过 10 分钟就跑完的。关键看归档文件的写入速度如果发现作业跑了很久没进展用 SM50 看当前 SQL 语句用 ST04 看数据库负载。写入完成后系统会生成一个归档文件和一个统计日志。统计日志里会写明读取了多少条、成功写入多少条、跳过多少条、报错多少条。这个日志必须仔细看跳过和报错的原因要逐条确认。3.3 删除阶段不可逆操作前的三道保险删除是唯一不可逆的步骤。我一般会设三道保险。第一道删除前用归档对象自带的“读取”功能从归档文件里读几条数据出来确认内容完整、可读。如果归档文件本身有问题删除后就真的找不回来了。第二道删除作业先用测试模式跑一遍看系统报告会删除多少条、有没有依赖冲突。测试模式不会实际删数据但会告诉你正式执行会发生什么。第三道正式删除前做一次数据库备份。这不是开玩笑我见过删除程序因为归档文件损坏而中途失败导致部分数据已删、部分未删的尴尬局面。有备份才有后悔药。# 检查归档文件是否可读示意命令实际通过 SARA 或 ARCHIVE 相关事务码操作 # 在应用服务器上确认归档文件路径和权限 ls -lh /usr/sap/trans/archive/FI_DOCUMNT/ # 确认文件大小和修改时间是否符合预期删除完成后用 DB02 对比删除前后的表体积。如果体积没有明显下降可能是数据库的高水位线没有释放需要 DBA 做表重组或者 REORG。3.4 存储管理归档文件不能只放在本地归档文件默认落在应用服务器的文件系统上但生产环境不能长期这么放。原因很简单应用服务器磁盘空间有限而且没有冗余保护。SARA 通过 Content Repository 对接外部存储。配置路径在 FILE 或者 SAP 的归档管理里你需要指定存储类型比如 HTTP Content Server、SAP Content Server 或者第三方归档系统。配置完成后归档文件会从本地转移到存储系统本地只保留索引。这一步的坑在于如果存储系统配置错误归档文件可能既不在本地也不在存储上变成“黑匣子”。所以每次转移后都要用归档读取功能验证文件可访问。4. SARA 归档避坑指南五条血泪经验4.1 现象删除作业报“归档文件不可读”原因存储路径权限变更有一次生产系统做归档写入阶段一切正常删除阶段却报错说归档文件不可读。查了半天发现是应用服务器的文件系统权限被安全策略调整了SAP 服务账号失去了读取权限。解决方法是联系系统管理员恢复权限或者把归档文件转移到 Content Repository 后再执行删除。教训是归档前后都要确认文件系统权限没有被改动。4.2 现象归档后报表查不到历史数据原因未配置归档读取业务用户反馈说归档之后某些报表查不到以前的数据了。这不是归档的错而是报表没有配置归档读取。SAP 的标准报表通常支持“从归档中读取”选项但需要激活。解决方法是检查报表变式里是否有“读取归档”的勾选项或者用 SARA 的“读取”功能手动查询。归档不等于删除后不可查但查询方式会变。4.3 现象预处理通过但写入报错“数据锁定”原因并发业务操作预处理阶段检查通过写入阶段却报错说数据被锁定。原因是归档期间有用户在操作同一批数据比如正在过账新的财务凭证。解决方法是把归档作业安排在业务低峰期或者和业务部门协调暂停相关操作。归档不是完全在线的操作它需要一定的业务静默窗口。4.4 现象删除后数据库空间没释放原因高水位线未回收删除作业成功完成但 DB02 显示表体积没有明显变化。这是因为数据库的高水位线High Water Mark没有回收已删除的空间还在表段里。解决方法是让 DBA 执行表重组REORG或者在线表重建。不同数据库的处理方式不同需要和 DBA 确认。4.5 现象归档作业跑了一整夜没结束原因变式参数过大有一次设置了“最大处理条数 无限制”结果归档作业跑了 12 个小时还没结束最后因为会话超时被系统杀掉。解决方法是把大任务拆成多个小批次每批控制在合理范围内用后台作业串行执行。贪多嚼不烂在归档这件事上尤其明显。5. 归档之后验证数据完整性和建立长期归档节奏归档做完不是终点验证和节奏化才是。验证数据完整性我一般用三个方法。第一用 SARA 的读取功能随机抽查归档文件里的数据和归档前的数据库记录做比对。第二用标准报表比如财务的 FBL3N切换到“读取归档”模式确认能查到已归档的凭证。第三用 DB02 确认表体积确实下降了而且下降幅度和删除记录数大致匹配。建立长期归档节奏比一次性归档更重要。我的习惯是每个会计年度结束后在下一个年度的第一个季度内完成上一年度数据的归档。这样数据不会积压太久归档窗口也可控。同时维护一个归档日志表记录每次归档的对象、时间范围、记录数、操作人方便后续审计和追溯。还有一个进阶技巧对于特别大的归档对象可以用 SARA 的“并行处理”功能。在变式里设置并行作业数系统会把数据分成多个包同时处理。但并行数不是越多越好要结合数据库的 CPU 和 I/O 能力来调。我一般从 2 到 4 个并行作业开始试观察系统负载后再调整。最后说一个我自己的教训早期做归档时总想一次搞定所有大表结果作业冲突、锁等待、日志暴涨全来了。后来学乖了一次只做一个归档对象做完验证完再做下一个。慢就是快在 SAP 归档这件事上稳比快重要得多。希望帮到你。本文还有配套的精品资源点击获取