简介SAP数据归档官方培训资料Archiving Workshop Exercises是一份实操型文档面向SAP Basis、系统运维及数据管理顾问用于解决生产库表庞大、归档对象配置复杂、历史数据删除不彻底等问题。压缩包共1个文件为doc格式整体2.62MB正文共27页按Preparation和Operation两大阶段组织。内容覆盖DB02识别最大表、SARA查找并核对归档对象、依赖关系检查、与数据所有者确认保留期限、归档路径与变式自定义、创建归档文件、审核后台作业结果、删除归档数据及UAT验证等关键环节并配有典型的事务代码操作界面插图。资料还强调归档前的业务影响评估、归档后的文档准备与员工培训可直接作为项目实施步骤参考或团队内训手册。目前已有770人学习/下载适合SAP系统管理员在测试环境逐项演练并落地归档策略。1. 数据膨胀是迟早的事归档不是想不想做的问题很多项目把《SAP数据归档官方资料.doc》当成技术手册收藏真到数据库告警那天才翻出来读读完更懵资料讲的是归档对象、ADK、删除程序但打开系统后第一步该敲哪个事务代码、先配哪个变式资料比我先懵。最后是被一次表空间满了、业务停摆的翻车事故逼着把这套机制啃了下来。归档不是备份也不等于清表。它是在生产系统里把不再频繁访问的历史数据落成独立文件再按规则从业务表里删除。做对了数据库瘦身历史账目还能查做错了历史凭证直接查不到审计对不上账。这套逻辑适合 SAP 顾问、BASIS 和数据运维尤其适合数据库已经涨到几个 TB 才开始着急的团队。下面把官方资料里的选型标准、SARA 配置、归档文件管理、踩坑记录和验证习惯串成一条线让归档从“看过资料”变成“能落地”。内容以常见做法为主不依赖某一版本的系统照着事务代码走就能对上号。2. SAP 数据归档的底层机制与归档对象选型先讲清机制再谈操作。官方资料一上来就讲归档对象Archiving Object不会先讲表这不是故意的是因为 SAP 的数据模型不允许直接 DELETE。业务数据分布在主表和几十张子表里靠外键关联直接删主表要么删不动要么留下一堆孤儿数据。归档对象是一组关联表的集合每个对象自带写程序Write Program和删程序Delete Program业务语义也封装在里面比如“只归档已清账的凭证”。2.1 两阶段归档写入与删除为何必须分开SAP 数据归档的核心是一个两阶段机制。写入阶段把业务数据从应用表抽取成 ADK 格式的归档文件写的同时给选中的记录打上归档标记删除阶段再读取这些标记按依赖关系逆向删子表、最后删主表。写入和删除在 SARA 里是两个独立动作可以分开调度也可以串成一道作业链。为什么必须分开因为只有先落文件、再删数据删错了才有后悔药。写入阶段失败生产数据原封不动库里没有脏数据删除阶段失败重新调度删除程序就行。反过来如果先删后写文件生成失败时数据已经没了恢复只剩归档前的备份等于把风险放大了很多倍。这是官方资料里最核心的设计思想也是它和普通数据清理工具的本质区别。两阶段还带来一个实际好处删除程序可以反复执行。删除按提交计数控制事务边界每处理一批数据提交一次遇到应用锁冲突就回滚到上一个提交点下次再续跑。所以看日志时会发现删除作业大多是“可重入”的而不是从头到尾一把梭。这也是我在项目里判断删除程序写得好不好的第一标准。这里顺带把归档和备份的关系说清楚很多人栽在这两个词的混用上维度数据备份数据归档目的灾难恢复、将系统恢复到某个时点管理历史数据生命周期、释放生产库空间对象完整数据库或增量变更按业务规则选出的历史业务数据访问方式恢复整个库后才能用通过归档信息系统直接读归档文件数据库影响不释放已用空间只产生副本物理删除业务表记录释放空间归档文件也是需要备份的但那是存储策略的事第 4 章再展开。这里只要记住归档完成之后归档文件就是唯一的数据副本备份它和备份生产库同等重要。2.2 归档对象与表的映射先从资料里找这张表官方资料里每个归档对象都带一张表清单这是我最先看的部分。每个对象会列出主表、子表、写程序名和删除程序名把这些抄成一张 Excel后续排查问题时全靠它定位。常见的标准归档对象如下归档对象覆盖数据典型主表FI_DOCUMNT会计凭证FI/COBKPF、BSEGMATBEL物料凭证MKPF、MSEGSD_VBBK销售单据VBAK、VBAPFI_ACCOUNTCONBLN总账科目余额GLFUNCA、GLT0CO_ITEM成本对象单据COEJ、COEP这里有个容易误解的点归档对象和数据库表不是一对一关系。FI_DOCUMNT 一个对象背后是几十张表删除程序会先删 BSEG 再删 BKPF而同一张表可能被多个归档对象覆盖一部分数据比如物料凭证表 MSEG 和货物移动历史耦合。所以实际沟通中不能问“删哪张表”要问“归档哪一类业务对象的凭证”口径从第一步就确定下来。官方资料查到一半会碰见一个大坑标准归档对象只覆盖 SAP 标准表。项目里的自建表、接口表、增强表不在任何标准对象里比如一张自开发的发票状态表涨到上亿行找不到可用的归档对象。常见做法有两种一是开发自定义归档对象通过 AOBJ 事务代码定义对象结构再在 ABAP 里调用 Archive Development KitADK的写和删除接口二是把日志型数据搬到独立历史表定时清理。第一种符合 SAP 规范但要投入开发第二种快但无法用归档信息系统检索保留期也不好管控。我一般建议先评估这张自建表的查询频率低频才值得开发归档对象。2.3 归档对象选型优先级不是所有大表都值得官方资料里专门有一个章节讲选型依据核心就三条数据不再频繁变动、有明确的法定保留期、查询频率降到阈值以下。三条同时满足才值得归档缺一条都不行。我习惯在此基础上加一个量化步骤。先列出数据库体积前 50 的表对每一张表问四个问题年增长行数、是否被标准归档对象覆盖、业务保留期多长、归档后通过什么方式查询。然后排优先级优先级判断标准例子高年增长超千万行、有标准对象覆盖、查询频率低会计凭证明细、物料凭证中增长较快、需自定义归档或需先做数据清理接口日志、状态历史表低数据还在被频繁读写、保留期未到未清项、在途单据这里要纠正一个直觉表行数大不等于该归档。某接口表 5 亿行但近三个月的记录每天被同步作业查一归档就把几百个作业卡死。正确做法是先和业务确认“多久以前的数据永远不再参与日常交易”把这条线划死再按线切数据集。我在一个项目里就把归档范围从“三年以上”改成“上一年度结平且已清账的凭证”数据量立刻少了一半用户没有任何感知因为没碰到他们还在用的区间。选型这件事没有标准答案但判断框架是通用的。只要先把数据生命周期和查询路径摸清再对照标准归档对象清单就能排出先后顺序。3. 把官方资料变成归档项目配置清单SARA 实操步骤资料读懂了不等于系统会动。SAP 归档管理的事务代码是 SARA所有标准归档对象的写入、删除、文件管理都在这里操作。新项目拿到官方资料后最常见的错误是通读原理不动手。正确路径是先把资料里的配置要素拆成清单然后在 SARA 里跑通一个归档对象的最小闭环再逐步扩展。3.1 四类配置要素归档对象、变式、Job 与文件路径官方资料里的配置章节拆到底就是四样东西归档对象、变式、后台作业、归档文件路径。这四样在 SARA 界面的不同位置配置少一样整个流程都跑不通。配置要素配置入口关键参数归档对象SARA 起始页输入对象名对象版本、是否激活、包含的表变式写入/删除程序的“变式”按钮保留期、测试运行、包大小、提交计数后台作业写入/删除时选“计划”或单独建 Job作业名、频率、服务器组文件路径文件系统或内容服务器连接目录、命名规则、最大文件大小归档对象在标准系统里大多是“已存在但未激活”的状态。资料会告诉你进入 SARA 输入对象名后就能用但实际项目里经常碰到对象版本和当前 Release 不匹配需要先把版本激活。激活是系统级动作日志里会列出缺失的组件或函数模块此时不要想着绕过直接找有权限的 BASIS 处理。变式是这里的灵魂。写入和删除程序各自独立保存变式不能混用。变式里定义了这次归档取数范围比如会计凭证按过账日期选择“小于等于某日期”物料凭证按凭证抬头日期选择。如果变式选成“全选”删除阶段会把所有符合条件的数据一并删掉。所以我的习惯是任何变式名称都带对象名和模式后缀比如 FI_DOCUMNT_2024_TEST降低点错变式的概率。3.2 SARA 跑通一个归档对象的最小闭环以会计凭证归档 FI_DOCUMNT 为例最小闭环在十分钟内能走完。步骤如下事务代码 SARA输入 FI_DOCUMNT回车。点“写入”按钮创建变式选择条件填过账日期小于某测试日期勾选“测试运行”不要勾“立即后台执行”。前台运行写入程序日志显示“可归档对象数量 N测试运行未写文件”验证选择条件是否正确。将变式改为生产模式取消测试运行重新执行写入。这次日志会出现归档会话号并生成 ADK 归档文件。回到 SARA 起始页点“删除”按钮选择相同变更范围先测试运行日志显示“可删除对象数量 M”。确认 M 和写入阶段一致后将删除变式切到生产模式运行删除程序。进入 SARI 归档信息系统为该对象建索引验证一条已归档凭证能查到。第 3 步是很多人跳过的步骤但这一跳最容易出事。测试运行不是慢一点而是只产生统计不产生文件。我见过有人把测试运行当作最终运行跑完以为归档好了一个月后发现数据库空间没怎么降打开日志仔细看才发现日志开头写着 Test。反过来也有人把生产运行当成测试一步到位把没到保留期的单据删了再想恢复只能走备份。第 5、6 步是删除阶段的两个关键决策点。删除程序在生产模式的日志里会显示真正删掉的记录数这个数必须和写入阶段的可归档数核对。如果写入阶段可归档 10 万条删除阶段提示可删除 9 万条差的一万条通常是未清项或锁记录属于正常现象。但如果差得太多说明两个变式的选择条件不一致要停下来排查而不是继续点执行。3.3 变式参数详解保留期、批量大小与运行模式变式选择屏幕上参数很多但真正影响归档结果的只有几个逐个说清楚参数作用初始值建议测试运行Test run不写文件、不删数据只统计首次必勾选择条件按字段限定数据范围常见是日期和状态先取小范围验证包大小Package size每次读取和写入的数据条数影响内存与文件数20000~50000提交计数Commit每处理多少条记录提交一次删除事务10000~20000详细日志Detail log控制对象级日志详细程度首次选详细日常选标准最大文件大小单个归档文件允许的最大字节数按文件系统上限的 70%包大小值得多讲两句。写入程序把生产表分段读出每个包写成一个数据块追加到归档文件。包太小程序反复打开表、读索引慢包太大内存和排序空间压力大出现 dump 的风险高。官方资料给的范围通常在 1 万到 5 万但我实际操作时会先跑一次 5 万如果运行时长超过 20 分钟就把包大小降半观察下次时长变化再校正。保留期不是独立参数而是体现在选择条件里。会计凭证按过账日期物料凭证按凭证抬头日期销售单据按开票日期。这里要特别和业务确认他们说的“保留期”是自然日还是会计年度。比如“保留七年”从 2018 年 1 月的凭证开始边界是 2018-01-01 之前还是当天稍微差一天审计就能挑出毛病。我的习惯是把边界条件直接写在变式描述里并请业务部门签字确认不靠口头沟通。注意变式参数是“写”和“删”各一套修改写入变式的包大小不会影响删除变式。删使用独立的提交计数控制两者不要混配。写到这SARA 的完整操作链已经有了雏形。下一章处理归档文件本身的问题因为很多项目死在这一步生产数据删完了归档文件却没人管。4. 归档文件存储、索引与重建历史数据不能直接删完不管删除阶段完成只是开始。归档文件的长期保管、索引建立、定期备份这三件事才决定归档方案是否可信。很多人只盯着数据从生产库消失的那一刻忽略了文件一旦丢失整体全完。4.1 归档文件的目录规划与命名规则ADK 格式的归档文件通常以“归档对象名.客户端.会话号.时间戳.ADK”的形式命名例如 FI_DOCUMNT.100.000045.20250115.adk每个归档会话产生一组文件。这个命名规则在官方资料里有明确说明实际排查时靠它就能定位到具体会话。目录规划我一般按四层建根路径 / SID / 客户端 / 归档对象 / 年月。例如/arch/S01/100/FI_DOCUMNT/202501/这样既按对象和年月控制权限又能用系统工具快速统计某个时段产出了多少文件。权限方面应用服务器运行用户要有读写权限日常运维账号只读即可避免误删。容量监控要按归档对象单独做因为 FI_DOCUMNT 一个月可能产出上百 GB 文件和 MATBEL 混在同一个目录下容量告警时很难分清是谁撑爆的。还有一个容易被忽略的点归档文件写入发生在应用服务器的文件系统上。如果用了共享文件系统所有应用服务器会同时打开同一批文件必须保证各节点挂载的是同一个存储路径。我在一个项目里遇到过两个应用节点挂载路径不一致SARA 日志显示文件已生成但另一个节点上的归档信息系统找不到文件排查到最后才发现是路径配置漂移。4.2 归档信息结构与数据重建删了还能查的关键写入和删除跑完后业务数据已经不在数据库里了。用户想查一张三年前的凭证靠什么靠归档信息系统事务代码 SARI。SARI 不是直接扫 ADK 文件内容而是先读归档文件的索引这个索引由信息结构Information Structure定义里面配置了检索字段比如公司代码、会计年度、凭证号。如果删除跑完却没有建立信息结构SARI 里要么看不到归档文件要么查一次就全量扫描慢到让人以为系统挂了。所以正确的顺序是删除之前先规划信息结构删除之后立刻建索引而不是等业务来投诉再补救。建立信息结构的步骤大致是进入 SARI创建信息结构选择归档对象 FI_DOCUMNT勾选要索引的字段激活后把现有归档文件导入索引。系统之后会自动为新归档文件更新索引。字段不是越多越好每多一个字段索引体积就大一分。归档文件本身是只读的索引可以反复重建所以我会先只选公司代码、会计年度、凭证编号三组字段等确实有余量需求再加字段。这里要紧扣一个常见误解重建索引不等于恢复数据。SAP 有专门的归档重建程序能把 ADK 文件内容恢复到数据库但那是灾难恢复场景日常绝不使用。日常的“查历史数据”走 SARI 就够了。真到需要把大量历史凭证重新激活回业务表时先和 BASIS 确认空间和停机窗口不要在业务高峰跑重建。注意归档信息结构不是备份重建索引也不是恢复数据。归档文件丢了索引再完整也查不到内容备份归档文件永远优先。4.3 归档文件的备份与冷热分层归档文件现在成了唯一的数据副本必须进入备份体系。不要把备份和归档混为一谈备份是复制归档文件本身归档是生成这些文件。官方资料通常会建议把归档文件纳入标准备份策略备份频率和数据保留年限对齐。检查归档文件有没有按预期产生、是否在备份范围内我习惯先用一个简单的 shell 命令摸清规模# 统计 FI_DOCUMNT 各时段归档文件总大小 du -sh /arch/S01/100/FI_DOCUMNT/*逻辑说明这个命令按子目录统计 FI_DOCUMNT 各年月归档文件的体积容量告警时能一眼看出哪个月份异常放大。参数说明-s 表示只输出每个参数的汇总大小-h 以人类可读单位显示* 会让命令遍历所有年月子目录并分别输出。生产环境建议把输出追加到文件留作历史对比不要只靠眼睛看。备份策略里还有一层冷热分层归档文件生成初期被访问频率高放在高速存储上超过法定保留期的转低频存储省钱。转存不能破坏目录命名规则否则未来重建索引时找不到文件。很多存储平台支持自动迁移策略但迁移动作会改变文件访问时间戳导致下一次统计时长文件误判为“未使用”。我的习惯是迁移后立刻做一轮索引校验确保 SARI 还能读到这些文件。文件管理和索引合在一起归档方案才算闭环。5. SAP 数据归档避坑清单五个最容易翻车的地方配置步骤可以照着资料走但真正让项目翻车的往往是细节顺序和假设错误。这五条都是我在实际系统里见过的现象每条按现象、原因、解决三步讲透。5.1 测试运行和生产运行挤在同一个变式里现象后台作业按计划执行完日志显示“测试运行”生产表的数据一个字节没少。业务等着空间释放项目组又重新排了一次生产归档前后浪费了一个月的排期。原因写入或删除变式里始终勾着“测试运行”。测试运行只统计不落文件、不删数据但很多人会在第一次执行后忘记取消勾选变式又被多个作业引用一错错一串。解决从第一天就把变式分成两套命名里带 TEST 和 PROD 后缀。测试变式只用来跑通逻辑生产变式永远不勾测试运行。调度后台作业时在作业步骤说明里写明变式名运行前再核对一遍。我的习惯是生产变式建好后把测试变式的执行权限收紧只允许归档负责人执行其他人碰不到。5.2 归档完没有建立信息结构历史数据查不到现象删除程序跑完用户立刻在标准报表里查去年凭证发现查不到第一反应是“数据被删了”投诉到 BASIS项目组开始准备回滚。原因归档后数据确实不在数据库里了但归档信息系统没有建索引SARI 读不到文件内容标准报表自然查不到。删除本身没有错是检索通道没跟上。解决在删除计划里把“SARI 建立信息结构”列为强制前置任务。删除完成后当天建索引并抽查一条已归档凭证。抽查不是只看有没有文件而是到 SARI 里实际点开凭证抬头和行项目确认业务字段能正常显示。这一步做完才能跟业务正式汇报“归档完成”。5.3 主子表顺序处理不对删除作业反复失败现象删除阶段运行报“在处理子表时找不到父记录”或外键相关错误作业中断后重试又在中途相同位置失败日志始终咬在同一张表上。原因归档对象的删除程序要按主子表依赖顺序逆向执行。标准对象一般没问题但自定义归档对象或对标准对象做了增强时开发人员很容易按表名字母顺序或添加顺序写删除逻辑导致子表没删完就删主表。解决先看归档对象定义里的删除程序文档确认表顺序和依赖关系。自定义对象在小数据量试删时把日志级别调到详细逐段检查每张表处理的行数。如果错误来自增强表检查增强表是否被错误地挂到了另一个归档对象的删除程序里。这类问题不是改参数能解决的要找 ABAP 开发调整程序结构不要反复重试同一套代码。5.4 归档文件大小参数没调作业写盘失败现象写入阶段作业跑到一半报“文件系统满”或“超出最大文件大小”SARA 会话显示红叉归档文件只写了一半重新执行又从零开始生产表被反复读取。原因包大小设得过大单个 ADK 文件迅速膨胀超过文件系统单文件上限或目录剩余空间。归档写入没有可靠的断点续传作业中断后的重跑会重新读表对生产系统也是一种额外负担。解决先确认文件系统单文件上限和目录容量把最大文件大小参数调到上限的 60%~70%同时把包大小降下来让一个会话产生多个文件。写完后检查文件清单确认最后一个文件完整落盘。归档目录建议加容量监控使用率超过 80% 就预警避免某月集中归档时一口气撑爆。5.5 未到保留期强行归档财务对不上账现象归档完成后财务月度报表里当月发生额和归档前对比明显少了审计要求调出旧单据旧单据已经不在生产库项目组拿不出业务语义上的合理解释。原因选择条件只按日期兜底没有考虑业务状态。比如会计凭证还在未清项状态就进了归档范围删除程序虽然有自己的规则但选择条件太宽时会把不该删的凭证纳入。保留期和清账状态是两个维度只用一个条件迟早出错。解决变式里同时限定日期和状态字段业务状态优先。FI_DOCUMNT 只归档“已清账且过账日期早于边界”的凭证物料凭证只归档“已过账且不存在未清库存”的移动。删除测试运行后把输出清单拿给财务抽查十条确认都是可归档数据再切生产删除。同时把保留期边界写进归档方案文档请业务部门签字避免事后各说各话。这五条只是高频翻车点的样本。归档项目里还有个通用排查习惯任何异常先看 SARA 会话日志再看归档文件目录最后查数据库锁和长事务。日志里写着哪个程序、哪张表、哪条记录出的问题多数情况在日志阶段就能定位不用到处猜。6. 归档后如何验证效果一套马上能用的检查习惯归档做完怎么知道真的有效我的检查顺序是先看日志数字再看文件增长最后到 SARI 抽查数据。日志数字指写入阶段的“可归档对象数”和删除阶段的“已删除对象数”两个数字应该基本一致偏差超过 1% 就要回头查变式。文件增长指归档文件目录的产出量用脚本按月统计形成趋势基线。SARI 抽查是最后一道关挑一个较早的归档会话实际打开一条凭证明细确认字段完整。给一个适合每月执行的检查脚本按目录汇总 ADK 文件大小# 按目录汇总 ADK 归档文件的大小 find /arch/S01/100 -name *.ADK -type f -printf %h %s\n \ | awk {sum[$1]$2} END {for (dir in sum) print dir, sum[dir]/1024/1024 MB}逻辑说明find 找出所有扩展名为 .ADK 的普通文件-printf 输出所在目录路径和文件字节大小awk 按目录累加最后以 MB 为单位输出。参数说明-name 匹配文件后缀-type f 排除目录本身%h 表示文件所在目录%s 表示字节数。输出结果建议保存成 CSV每月追加一次和 SARA 的归档会话数对照看哪个月份异常放大立刻能发现。除了脚本归档效果的验证还可以做成一张固定检查单检查项通过标准归档会话日志无红叉、无 ABAP dump可归档数与已删除数一致归档文件目录文件数等于会话数文件大小在预期范围内数据库空间目标表行数下降表空间释放量符合预期SARI 抽查按凭证号能查到抬头和行项目关键字段完整备份记录新增归档文件已进入当天备份任务我现在接手任何一个带着历史包袱的系统第一件事不是调参数而是把归档对象清单、归档文件目录、信息结构列表拉出来看一眼。有维护痕迹的系统后续才敢动没有维护痕迹的系统再新也不敢随便归档。归档这个方向看着是存储和清理的事实际做的全是数据生命周期管理先有检查习惯再谈扩大归档范围希望帮到你。本文还有配套的精品资源点击获取
