简介《SAP SLT操作手册》是一份针对SAP Landscape Transformation Replication Server的实践指南面向需要将数据实时同步至SAP HANA等目标系统的IT专业人员和顾问。手册围绕SLT的实时数据复制能力先介绍适用场景、系统架构、用户与角色、容量规划再重点描述初始数据加载优化、复制流程、数据清洗转换、目标表结构修改监控与运维部分则涵盖配置状态查看、健康检查、Solution Manager集成并提供故障排除与日志解读思路。资源共1个PDF文件内容为全英文技术文档压缩包整体14.25MB章节结构清晰。这份手册已吸引2876人学习适合作为企业实施SAP实时数据迁移时的操作参考与排错指南帮助读者从初始化复制到持续同步全面建立实操能力也能为数据迁移、系统复制及实时分析等场景提供明确落地路径。1. SAP SLT操作手册为什么数据上HANA第一个要学它做 SAP 数据平台的人应该都有过这种体验业务方要求报表数据至少 T1结果你还在用全量抽取一张大表跑了三个多小时还没抽完业务又开始催。后来换到 SLT基于数据库触发器的实时复制几分钟内把 ECC 的表同步到 HANA库存、销售、物料凭证这些关键数据基本能做到准实时可见。这份《SAP SLT操作手册》就是围绕这个场景展开的SLT 是什么、环境怎么准备、LTRC 怎么配置、初始装载和增量同步怎么切换、跑挂了怎么看日志整条链路讲得比较完整。适合正在做 BW/4HANA、S/4 迁移、或者想把 SAP 数据实时同步到分析平台的人照着操作能少走不少弯路。2. SLT 同步原理与适用边界基于 trigger 的实时复制以及从初始装载到增量的切换SLT 全称 SAP Landscape Transformation Replication Server是 HANA 平台最常用的实时数据复制工具。它不读应用层的业务表而是直接在源系统数据库层做文章源表上创建触发器把 insert、update、delete 操作记录到日志表然后由 SLT 系统的调度器把这些增量记录拉取并写入 HANA 目标表。所谓“实时”本质是把传统 ETL 的抽取步骤压缩成 trigger 捕获加批量应用两步。2.1 SLT 的架构源系统、SLT 系统、HANA 目标三层的分工典型的 SLT 生产环境有三个角色源系统可以是 SAP ECC、S/4HANA也支持部分非 SAP 数据库。源系统上需要安装 SLT 的插件组件核心就是 trigger 和日志表。SLT 系统一台独立的 SAP 系统跑调度、监控、数据应用逻辑。它不直接连业务数据而是管理所有复制任务。HANA 目标最终数据落地的数据库可以是 HANA 一体机也可以是 HANA Cloud。图我就不画了说一个最容易搞混的点SLT 系统不等同于 HANA。很多初学者以为装了 HANA 就有 SLT不是的。SLT 是一个基于 ABAP 应用服务器的独立系统它和源系统之间走 RFC和目标 HANA 之间走 DB 连接或 RFC。生产环境里常见的拓扑是 SLT 系统和 HANA 装在同一台服务器上但逻辑上它们是分开的。复制链路里最关键的是 trigger 表的设计。SLT 会在源表上创建名为DDLSNG_*的触发器记录主键、操作类型、变更时间戳到日志表DDLSNG。SLT 调度器每隔几秒扫一次日志表把新的变更记录抓走。所以源库的 DML 性能会有一定损耗尤其是高频更新的大表这个后面避坑部分会展开。2.2 SLT 与全量抽取、ODP 的区别及适用边界做选型的时候很多人在 SLT、全量抽取、ODPOperational Data Provisioning之间纠结我一般用下面这个圈子来分方案实时性适用数据量主要场景SLT准实时秒到分钟级中小表优先大表需调优源系统到 HANA 的实时同步、S/4 迁移、BW 抽取层替代全量抽取DB Connect 类无实时性小表可以大表耗时不可控低频维度表、历史归档数据ODP增量抽取准实时中大型表BW/4HANA 从 S/4 抽取数据走 ODP 框架SLT 的优势是它不管你源系统是 ECC 还是 S/4不看业务数据结构直接复制表。坏处也是这个它复制的是物理表不是业务对象所以如果源端做了字段增强或者自定义表它会照搬过去但同时也把脏数据、历史包袱一起搬过去。边界就是如果你要做的是轻量级实时复制SLT 是首选如果你要做复杂的清洗、转换、关联还是得靠 BW 或 CDS。2.3 初始装载和增量同步的切换逻辑实际配置一个 SLT 复制任务顺序永远是先做初始装载Initial Load再做增量同步Delta Replication。初始装载是把源表当前全量数据一次性复制到 HANA增量同步则是等初始装载结束后靠 trigger 捕获后续变更。这个切换逻辑有个细节很多人忽略初始装载期间产生的增量数据怎么不丢SLT 的做法是先在源表上加 trigger再开始初始装载。也就是说trigger 先建立然后数据开始批量导出导出期间业务产生的变更已经写进日志表了。初始装载完成后SLT 再从日志表里读取这段时间的增量记录补齐到目标表。所以整个流程是安全的不会丢数据但需要在配置里把这两个阶段当成一个完整事务来对待。常见做法是先在开发环境跑一次小表验证流程再上生产配置大表。验证时重点看两个时间点初始装载开始的时间、增量同步 catch-up 完成的时间。如果增量 lag 太久跟不上说明批量应用参数需要调。3. 配置第一步SLT 用户角色、RFC 连接与源系统检查真正动手配置 SLT 之前有一堆前置检查要做。我见过太多人跳过这步直接进 LTRC结果 RFC 测试都过不去或者 trigger 建不出来然后开始各种怀疑人生。顺序应该是检查版本和补丁 → 处理源表主键和字段问题 → 创建 RFC 用户和权限 → 测试连接 → 再进配置界面。3.1 源系统和 SLT 系统的版本与补丁检查SLT 对源系统版本有明确要求不是所有 SAP 系统都能直接接。常见的支持矩阵大致是这样源系统类型支持版本需要安装的组件SAP ECC 6.0EHP5 以上SLT 插件包基于 SAP_BASIS 7.30S/4HANA1511 以上SLT 版本需同步更新SAP NetWeaver BW7.3x 以上需支持 ABAP 通道非 SAPOracle、SQL Server视数据库版本使用 DB Connect 方式实际操作时不去死记硬背版本号而是查 SAP Note 里对应 SLT 版本的支持矩阵。进入 LTRC 以后配置界面会识别源系统并做兼容性检查如果有问题会直接报错但等到那一步再处理就慢了。我一般习惯先用系统连接检查程序RSRFCCHK验证 RFC 可用性再进 LTRC。3.2 SLT 通讯用户创建与权限对象SLT 需要在源系统有一个专用 RFC 用户这个用户不能随便用业务账号顶替。它需要的权限和普通 ABAP 开发账号不一样最典型的是要能创建数据库 trigger、读取日志表、修改表结构。权限配置常见做法是复制 SAP 提供的模板角色然后按环境调整权限对象用途说明S_RFC远程调用必须授权且要能访问 RFCPING 和 RFC_METADATAS_TABU_DIS表维护权限允许读取和修改数据字典表S_ADMI_FCD管理权限需要 SUP用于创建数据库 triggerS_DEVELOPABAP 开发权限trigger 生成代码需要在 SU01 里创建用户后建议先用下面的 ABAP 代码测试一下 RFC 目标是否可用 测试 SLT 源系统 RFC 连接的可用性 DATA: lv_dest TYPE rfcdest VALUE SLT_SOURCE, lv_result TYPE sysysid. CALL FUNCTION RFC_PING DESTINATION lv_dest EXCEPTIONS communication_failure 1 system_failure 2 resource_failure 3 OTHERS 4. IF sy-subrc 0. WRITE: / RFC连接不可用返回码, sy-subrc. ELSE. WRITE: / RFC连接正常. ENDIF.这段逻辑很简单通过RFC_PING函数测试远程系统是否能响应。如果返回码是 0说明基础连接没问题如果报 communication_failure先查网络和 SAP 网关如果是授权错误大概率是 S_RFC 分配不到位。注意这里RFCDEST要用你实际创建的 SM58 里定义的 RFC 目标名称不要照抄。3.3 时区、字符集和主键检查时区不一致是 SLT 同步中非常隐蔽的问题。源系统在 UTC8SLT 系统在 UTC复制到 HANA 之后时间字段的展示值差了 8 个小时。这不是数据错了是时间戳的存储和解析没有对齐。建议在配置表时就统一约定源系统和 SLT 系统的时区设置保持一致最好都在参数文件里显式指定不要依赖操作系统默认值。字符集方面中文环境最容易出问题的是源系统字符集是非 Unicode比如原来 ECC 5.0 升级上来的SLT 目标 HANA 是 UTF-8。复制过去中文变问号大概率是源字段的 codepage 转换没配好。可以先在 LTRC 里查看该表的字段属性确认源字段类型是LANG、CHAR还是STRING再确认目标表的存储类型。主键检查是另一个必做项。SLT 复制要求源表必须有主键或唯一索引没有主键的表 trigger 能建但增量同步的日志记录会拿不到稳定的键值很容易产生重复数据或者 update 匹配不到行。检查方法可以用一段 SQL 查询但源系统如果是 ECC直接看数据字典更准确-- 在目标 HANA 上检查已同步表的主键定义 SELECT SCHEMA_NAME, TABLE_NAME, COLUMN_NAME, POSITION FROM SYS.CONSTRAINTS WHERE IS_PRIMARY_KEY TRUE AND SCHEMA_NAME SAP_SLT ORDER BY TABLE_NAME, POSITION;这个查询只对已经进到 HANA 的目标表有效。对于还在源系统上的表我一般用事务代码 SE16N 查表DD03L按表名过滤出 KEYFLAG 为 X 的字段就能判断主键情况。如果发现自己要同步的业务表没主键先用 SM30 维护数据字典补充键值或者用 SLT 配置里的 auxiliary table 功能辅助处理不要硬同步。4. LTRC 实操从创建配置到启动同步的完整流程前置检查做完就可以打开 LTRC 开始干活了。LTRC 是 SLT 的主配置事务代码界面不算复杂但第一次用的人容易在“表选择”这一步卡住。实际上 LTRC 的配置思路可以拆成四步创建配置 → 定义源和目标 → 选表 → 启动复制。4.1 创建新配置并设置源系统和目标进入 LTRC 后界面上会列出已有配置。新建时会让你填配置名称、描述然后选择源系统和目标 HANA 连接。这里注意配置名称不要随便起生产环境建议带上业务域或者项目代号比如 ZSLT_MM_STOCK因为后续监控、日志筛选都靠这个名字。源系统连接类型一般选 RFC目标系统选 HANA。如果目标 HANA 已经配置了 DB 连接也可以直接选 Database Connect但生产上走 RFC 更稳。保存之后LTRC 会立刻做一个连通性测试如果源系统的 RFC 用户权限不足这一步就报错了。所以第 3 章的用户权限检查一定要提前做好不要到这一步才去补权限。4.2 选择表和字段支持批量导入和过滤条件选表这一步是 LTRC 里最灵活的环节。你可以手工逐张加也可以用批量导入功能从 Excel 里粘贴表名列表或者按 schema 前缀批量选。建议按模块分批加比如先加物料主数据相关的MARA、MAKT、MARC跑通一遍流程再加单据表EKPO、VBAK不要一次性同步几百张表。每张表选中后LTRC 默认复制全表所有字段。如果源表字段特别多你只想同步其中一部分可以在字段标签页去掉不需要的字段。这个操作要谨慎后续如果有 schema 变更新增字段不会自动出现在目标表需要手动维护。过滤条件也是在这一步设置。例如只同步某个公司代码或 plants 的数据可以在 SLT 的配置里维护一个 WHERE 条件。常见写法是VKORG 1000这个条件会在生成 trigger 时拼进触发器逻辑里源端不符合条件的变更不会被记录到日志表。注意条件一旦设置初始装载和增量同步都会生效不是只过滤第一次装载。所以建条件前想清楚如果业务数据范围会变化不如同步全量后在 HANA 侧做视图过滤。4.3 启动复制、监控队列与常见状态含义配置保存后点激活复制SLT 会为每个表生成 trigger、执行初始装载任务、然后进入增量模式。之后在 LTRC 主界面可以看到每张表的同步状态状态显示含义需要采取的动作No Replication配置已保存但未激活点击激活启动Initial Load Running正在执行全量复制等待观察日志Replication Active增量同步正常无需操作定期检查延迟Suspicious表状态异常查看日志检查 trigger 是否失效Error同步中断按错误信息排查必要时重新激活判断整个配置是否工作正常不能只看状态列显示 Active还要看数据延迟。熟悉的做法是选中表行后看详情里的 Current Position 和 Last Committed Timestamp两个时间差就是当前延迟。如果一直往上走说明增量应用比变更产生慢需要做调优不是重启能解决的。4.4 用表查看同步进度和日志LTRC 界面能看状态但遇到大表或者批量配置多张表的场景直接查表效率更高。SLT 的配置数据存在几张核心表里我用得最多的是SLT_CONFIG主配置表记录所有复制任务和表清单LTCP_APPLY数据应用控制表记录每张表的 apply 进程状态LTDELTA增量日志表记录每次同步的 delta 记录SLT_STATUS_LOG状态变更历史排查问题时优先看它拿 SE16N 看 SLT_STATUS_LOG筛选配置名称和时间段基本能还原出问题的发生时间点。如果日志里出现“Trigger not found”之类的错误多半是目标表被手动删除过或者源系统的 trigger 被 DBA 手工清掉了。5. SLT 避坑指南初始装载慢、trigger 生成失败和同步中断的排查SLT 用熟了以后大家遇到的问题其实高度集中。这几条是我在项目里反复踩过的每一条都按现象、原因、解决来写希望能帮你省掉几天的排查时间。5.1 现象初始装载很慢但表本身数据量不大某张表只有 20 万条数据初始装载跑了两个小时还没结束看起来像卡死。检查 LTRC 日志发现它停在了 trigger 生成阶段而不是数据复制阶段。原因SLT 在初始装载前要先在源表上建 trigger这一步需要和源数据库进行 DDL 交互。如果源系统是 ECC 且数据库是 OracleDDL 操作需要额外的锁尤其是表上有大量索引或并发访问时锁等待时间会非常长。解决不要在业务高峰时段做初始装载尽量安排在非交易时段。如果确实必须在白天做先把源表上的冗余索引临时禁用掉等 trigger 建完再恢复。另外检查 RFC 连接的带宽设置SM58 里事务性 RFC 的 queue 大小默认值偏保守适当调大能缓解部分场景的慢问题。5.2 现象trigger 生成失败报对象不存在或权限不足激活复制时日志里直接报DDLSNG_*相关错误提示对象不存在或者 create trigger 时权限不足。原因最常见的两个原因。一是源系统数据库账号不是表属主没有 CREATE TRIGGER 权限二是 SAP 源系统缺少 SLT 相关插件组件。很多系统是 BASIS 团队直接拷贝生产配置来的忽略了 SLT 插件包的安装。解决先检查源系统的 SLT 组件是否激活用事务代码 SE38 运行程序RS_LT_TRIGGER_ENVIRONMENT这个程序会输出当前系统的 SLT 环境检查结果。权限问题就回到 SU01把 RFC 用户补上S_ADMI_FCD的 SUP 权限同时确认它拥有源 schema 的 ALTER 和 TRIGGER 权限。改完权限后在 LTRC 里把该表任务停止再重新激活会自动重建 trigger。5.3 现象增量同步中断恢复后数据抓不回来复制任务在凌晨中断第二天早上发现才处理。重启任务后日志表里的增量记录还在但 apply 进程一直报主键冲突或者直接跳过大量记录。原因SLT 的增量同步是基于日志表顺序读取的。如果中断期间有 DBA 手工删除或归档了日志表数据SLT 会读不到某一段的变更记录任务会尝试从头重建增量上下文导致和现有目标表数据不一致。主键冲突则说明目标表里的数据已经比源系统新可能是别人手动改过 HANA 侧数据。解决遇到这种中断不要直接重启先把LTDELTA里当前任务的最新日志时间戳记下来和目标表的最大更新时间对比。如果目标表已经超出源表需要从 HANA 侧把多余数据清掉再重启任务。如果日志表有空洞唯一的干净做法是把该表任务删掉重建重新做一次初始装载。数据量大的表很痛但脏数据带进去更痛。5.4 现象表没有主键增量同步的 update 匹配不到行复制日志没报错但目标表出现重复记录或者源端 update 字段后目标表同时新增了一条。原因源表没有唯一主键SLT 的 update 处理只能用 all columns 匹配如果一行数据多个字段完全相同就会出现匹配到多行或者匹配不到的情况。解决在配置阶段就发现这个问题优先处理源表补一个唯一性约束。如果源表不能动可以在 SLT 配置里勾选“Enable additional unique field”让 SLT 自动添加一个技术键字段用它来做变更匹配。这个字段初始装载时会赋值增量时也会保持一致效果等于给目标表加主键。唯一的缺点是需要多占一列存储一般可以接受。5.5 现象中文数据同步到 HANA 显示乱码或问号源表里看是正常中文同步到 HANA 后用 HANA Studio 查询全是问号。原因字符集转换问题。最常见的是源系统 codepage 非 Unicode比如 8400目标 HANA 是 UTF-8。SLT 在做数据应用时字符集以源系统的 codepage 为准如果源字段存储的是可转换字符但转换映射表缺失就会落成问号。解决第一步确认源系统是否 Unicode用事务代码 SE38 运行程序RSCPINST查看当前实例码页。如果是非 Unicode 系统需要在 SLT 配置的 RFC 目标里指定 codepage 转换参数。生产上比较顺的做法是先用一小张含中文的表做测试同步成功后查看字符集是否有问题没问题再放量大表。不要在几十张表都跑起来之后再去检查那会改到你怀疑人生。5.6 现象SLT 同步阻塞了源系统的业务更新生产反馈某个事务变慢数据库层面的会话监控显示大量 trigger 相关等待。原因SLT 的 trigger 是在源库层执行的如果日志表写入路径出现瓶颈业务表的 DML 会跟着被阻塞。通常是日志表膨胀、索引失效或者是 SLT 系统的拉取进程挂掉导致日志表数据堆积。解决先检查 SLT 的调度进程是否存活用事务代码 SM50 查看 SLT 系统是否有活动的更新进程。如果都挂着手动停止再启动对应配置的复制任务。日志表膨胀的预防办法是配置自动清理策略让 SLT 定期删除已应用的历史日志。生产环境我一般会建一个后台作业每小时检查一次日志表行数和最近一次拉取时间超过阈值就发邮件告警。6. LTRC 监控与调优技巧如何判断 SLT 是不是真的要跑不动了SLT 用久了你会发现它其实挺稳定的但稳定不等于不管。真正需要关注的是延迟趋势、错误队列和日志表增长速度这三个指标。延迟时间看 LTRC 列表页的 Last Committed Timestamp误差在几秒到一分钟内属于正常超过五分钟就要看是不是源系统在跑大批量作业。错误队列看LTCP_APPLY里的记录有没有堆积堆积说明 apply 进程处理不过来。调优的参数方面用得最多的是批量应用大小和并行任务数。在 LTRC 的配置详情里可以调整每个复制任务的最大批量条数默认通常几百到一千条以及同时运行的 worker 进程数。数据量大、单条记录字段多的表批量值调小一点反而更稳因为单次事务提交时间更短锁冲突概率更低。反过来字段少的维度表可以调大批量吞吐量会明显上升。日志分析的技巧是善用 SLT_STATUS_LOG 和LTDELTA。故意制造一次停表和恢复操作然后观察这两张表的变化能帮你理解 SLT 在异常场景下的行为。我一般会在测试环境专门拉一张大表手动在源端删几行数据再插回来看 SLT 怎么记录和恢复这样生产上出了问题心里有底。从那以后我每次新建配置都会强制走一遍这个流程先查主键和字段类型再做 10 万行的小批量测试最后全量上线并盯三天延迟趋势。这套习惯帮我挡掉了不少生产事故希望帮到你。本文还有配套的精品资源点击获取