SAP LT 故障诊断指南

发表于 2017-5-17 17:15:55

马上注册，结交更多数据大咖，获取更多知识干货，轻松玩转大数据

您需要登录才可以下载或查看，没有帐号？立即注册

x

1.嵌入式的健康检查
2.模式创建期间
3.加载/复制期间
- 3.1 表添加在了 "Data Provisioning"中（加载或者复制）但是LTRC中未出现此表
- 3.2 表出现在LTRC中，原始加载真正启动
  - 3.2.1 对于即将被复制的表
    - 记录表检查
    - 触发检查
4.初始加载发生错误
5.加载完成并且复制状态还未被改变（在HANA studio中停滞在状态"load, executed"）
6.复制停止工作

1.嵌入式的健康检查

在LT配置监控控制台(事务代码LTR)中包含了两项嵌套的健康检查。

1、分析工作：

健康检查会检查和当前配置所有相关的工作是否都在运行。它可以用来帮助确定工作不运行的问题的根本原因。

2、表健康检查：

健康检查分析当前配置的所有表是否所有要求的步骤都被执行（例如触发的创建）。它可以用来帮助确定表停止工作在一个特定的状态的根本原因，从而表明哪一步骤没有成功被执行。

此两项健康检查也被包含在LTR驾驶舱(事务代码LTRC)的“专家功能”页面中的“Status and Notification”章节中。

此外，系统内还提供了一项确保1:N复制脚本内部一致性的健康检查。

1：N复制健康检查

这个故障解决项目适用于1：N复制脚本。系统检查相关的系统表的任何可能导致错误或者影响性能的不一致性。

在这个故障解决项目中，系统会检查以下这些项：

- 同一个日志记录表是否存在多配置注册
- SAP LT复制服务器系统表中是否存在废弃的记录
- 是否SAP LT复制服务器中与应用和日志表相关的配置没有被注册。
- 1：N复制进程中是否有表注册错误。
- 是否有配置在1：N复制过程中被错误设置。

此外，你可以看到系统中正在被复制的所有表，也可以看到与之有关联的某个配置和相应的MT ID

默认地，系统使用LTR驾驶舱中正在被加载的配置(MT ID)中指定的连接。如果需要的话，你可以在源RFC连接领域指定另外一个连接。

你可以看到健康检查部分中检查的结果。红色信号灯表示错误。你可以通过双击这个部分中的一个项目直接对细节信息进行操作。

2.模式创建期间

根本原因分析工具: SM21, ST22, dev trace

安装方面

确保在带有合适补丁等级的SAP LT复制服务器中正确的SAP内核版本被使用。确保SAP HANA DB共享库和SAP HANA DB客户机都得到了正确的安装，OS参数被校正过。严格参照SAP Note 1597627.

在SAP源系统和SAP LT复制服务器中，检查是否安装了DMIS附加组件的最低要求支持包级别，以确保能兼容您所安装的SAP HANA Studio的版本。

为了得到更多的信息，看 SAP Note 1759156.

确保适当的前端要求得到满足(SAP GUI 版本).

预配置：

在您启动LT配置监控控制台 (事务代码LTR)之前，确保SLT相关的Web服务都被激活了。

更多信息参见SAP Note 517484.

连接授权：

对于SAP源系统来说:

确保角色IUUC_REPL_REMOTE被正确地生成(通过事务代码PFCG)，以及被分配到RFC连接配置中的用户下。

不要用 DDIC 用户来进行 RFC 连接。

对于非SAP源系统：

确保数据库用户有足够的数据复制授权，更多信息参阅安全指南。

确保使用的内核的特定的数据库共享库部分在SAP LT复制服务器中被安装了。

对于SAP HANA 系统：

为了创建一个配置，用户系统被要求，或者是一个拥有类似的授权的用户,他至少有创建HANA DB模式的授权。

你可以在安全指南中得到更多的关于SAP LT复制服务器的角色和授权的概念。

配置输入:

当创建模式的时候确保你输入的配置信息是正确的。

*关于如何进入非SAP源系统中建立次级DB连接，参照：

Note 1768805 -SAP LT复制服务器：共同的 - 非SAP源

典型症状和根本原因：

a) LTR中错误文本：Not all configurations could be loaded due to data inconsistencies.

原因： LT 系统表中存在不一致性。

解决方案：

用户:把系统表中数据的不一致性反馈给SAP得到解决。

SAP内部: 检查所有的IUUC_REPL*，通常来说存在不一致的记录，通过修正不一致性，错误就会消失。

b) LTR中的错误文本：无效的表名： Could not find table/view RS_REPLICATION_COMPONENTS in schema SYS_REPL: line 1 col 28

原因1: DMIS 2011 SP3 / 2010 SP8中存在BUG

原因2: HANA系统中已经存在模式用户了

解决方案:

检查你想创建的具有相同名字的模式名，删除用户(cascade) 尝试重新创建模式。

c) LTR中的错误文本： Message E DMCLG 013 cannot be processed in plugin mode HTTP

*原因：*你最近安装了有DMIS AddOn (DMIS 2011 SP4 or DMIS 2010 SP9)的LT系统和相关的支持包在一个队列中。 .

解决方案:

参照SAP Note 1830248. 如果问题仍然存在，反馈给SAP。

d) LTR中错误文本: Error occurred when trying to execute the query

原因: 表 IUUC_REPL_HEAD示空的。

解决方案:

选择1: 从其他LT系统中转移 IUUC_REPL_HEAD的内容。

选择2：手动创建如下十个条目：

Error rendering macro 'code': Invalid value specified for parameter 'lang'TABLE_NAME ORIGIN BEHAVIOUR TABLE_TYPE TABLE_COMMENTDD02L 1 3 1 SAP TABLESDD02T 1 3 1 R/3 DD: SAP TABLE TEXTSDD08L 1 3 1 R/3 DD: RELATIONSHIP DEFINITIONSRS_LOG_FILES 2 1 2RS_MESSAGES 2 1 2RS_ORDER 2 1 2RS_ORDER_EXT 2 1 2RS_REPLICATION_COMPONENTS 2 1 2RS_SCHEMA_MAP 2 1 2RS_STATUS 2 1 2

3.加载/复制期间

根本原因分析工具: LTRC, SM37, IUUC_REMOTE, MWBMON, SE11, SM21, ST22, LTR, SM50, SM51, HANA studio

技巧:

1.要一直确保源系统与目标系统HANA之间的连接正常运转。

2. 对于非SAP源系统复制，比SAP源系统复制有更多的约束条件。请仔细查看 SAP Note 1768805 来得到支持方案。

3.1 表添加在了 "Data Provisioning"中（加载或者复制）但是LTRC中未出现此表

在HANA studio中检查<schema>.RS_ORDER表的内容：表的仍旧在那里？

在的话 ->通过事务号SM37来在LT系统上面检查，发现监控工作 (1LT/IUC_REP_MSTR on DMIS 2011 SP5 or IUUC_MONITOR_<mtid> on lower version)不在LT上面运行了。

该做什么:
- 在LT系统上面事务SM37上面核查，检查工作运行记录以便找出终止原因（Note：工作停止了，每天在午夜的时候重启，这是被应用程序设计的为了避免长时间运行的监控工作产生的问题）
- 工作名字: 低版本下的1LT/IUC_REP_MSTR on DMIS 2011 SP5 or IUUC_MONITOR_<mtid>
- 工作开始日期：选择前天
- 工作状态:取消的
解决方案:
- 通过事务 LTR重启监控工作. 如果工作不能被重启，在LT系统中检查ABAP得到更多的信息。

如果不是的话 ->LT系统上通过SM37检查，看看监控工作是否还在运行。

该做什么：
- 在LT系统上检查表 IUUC_RS_ORDER, IUUC_RS_STATUS 的表内容(事务 SE16), 填上 Mass Transfer ID 和表名之后执行。如果这不是你第一次操作表，会得到一些记录返回。如果表的最后一次操作不恰当，这些记录会不一致。
解决方案:
- 在IUUC_RS_ORDER and IUUC_RS_STATUS中删除与表相关的这些记录，之后尝试重新添加表来加载/复制。

3.2 表出现在LTRC中，原始加载真正启动

Notes:

1. 确保所有的LT角色被合适地创建和分配给RFC用户在源系统中（角色应该在表 "Authorizations"和 "User"中都有绿色信号灯).

2. 如果tx. LTRC 标签 "Table overview" 或 "Data Transfer Overview"中表的标识"In Process"被设置，这意味着LT正在处理此表。在这种情形下，请刷新界面并看看是否有变化。如果看到变化，那就是正常的

3. 如果有 “Error” 标志或者 “In process” 标志被频繁设置当时页面上面没有出现变化，说明出错了。

3.2.1 对于即将被复制的表

如果你正在解决一个选择了即将被复制的表，请从这里开始。

记录表检查

检查LTRC标签 "Table Overview":此表的目录表是否被创建（ "Logging table"领域）?

是的话，“Logging table”被填了。

继续下一选项“Trigger check”。

不是的话， "Logging table"是空的。 -> LT系统上面检查，是否存在有效的BGD?

不是的话，没有有效的BGD（通常情况下你可以在SM37上面看到一些时间延迟的工作）
- 解决方案:
- 选项 1:如果系统硬件容量允许的话，在系统上降低BGD的数量（必要的话重启LT）
- 选项 2: 如果可以的话临时停止其他运行的LT模式。
- 选项 3:降低配置给此模式或者其他正在运行的模式的数据加载工作数量。
- 选项 4:使用操作模式（事务号 RZ04 和RZ03)来临时将一些 DIA工作转换成BGD工作。
- 选项 5:可能是一个错误的/过时的LT系统标准，如果必要的话检查并且降低硬件容量。

存在BGD -> 在tx. SM37中检查主要控制工作的状态 (SP5上的/1LT/IUC_REP_CNTR_<mtid>和SP4上的IUUC_REPLIC_CNTR_<mtid> ) ->观察工作运转是否运行300秒以上？

是的话，意味着一个主控工作正在进行。

- 解决方案:
- 手动终止工作并刷新界面，应该可以看到工作被重新初始化，通常状况下很快就会结束-> 再一次检查记录表是否成功被创建

不是的话，你是否在用两个LT系统来从同一个源系统中进行复制呢？如果是的话-> 反馈给SAP得到进一步的处理

- 是的话.
  - 该如何做:
  - 如果客户在用两个LT系统来从同一个源系统中复制>让客户同时打开两个LT系统，并在两个系统(current NRLEVEL)上面检查数值范围IUUC_SHDW -> 如果在同样的数值范围（重叠）冲突 ->反馈给IMS进行解决*
- 不是的话
  - 该如何做:
  - LT系统中检查表的鉴别(table IUUC_LOGTAB_ID) ，在tx SE11源中检查表 /1CADMC/<ident> ，状态是否是激活的? 如果不是的话，试着激活表。
  - 如果激活失败，检查 ->DB是否一致？ Runtime是否一致？ (transaction SE11, Menu Utilities -> DB/runtime obj -> Check) -> 如果不一致的话反馈给IMS解决。

触发检查

LTRC标签 "Table Overview"中检查:触发状态是否是"Activated"?

是的话

继续下一选项“Table/Synonym check”.

不是的话.

- 检查src系统tx IUUC_REMOTE 中触发是否存在.
- 检查src系统tx IUUC_REMOTE 中触发是否存在-> 将触发淘汰

解决方案:

- 通过IUUC_REMOTE中的 "Expert Func" 来删除淘汰的触发.
- 双击检查淘汰的触发是否不见了。
- 如果标志被设定了在LTRC标签"Expert Functions"中重置 "Failed" 标签或者 “In process” 。
- 如果源系统中没有触发.
- 检查是否没有空闲的BGD工作进程或者主要控制工作停止（参考先前的章节"field ‘Logging table’ is empty.”)。
- 如果主控工作没有问题的话:
  - 解决方案:
  - 用LTRC标签 "Processing Steps" 手动再次创建触发。
  - 如果仍然未创建，在LT系统上检查LTRC标签 "Application Logs" 中的ABAP转储文件，系统日志，源系统中的设备驱动程序踪迹来得到更多信息。
  - 该做什么:
  - 反馈给SAP更多细节信息.

4.初始加载发生错误

如果所有的/许多表发生错误:

该做什么:

检查源系统和HANA目标系统之间的连通性。

解决方案:

修整好连通性问题，LT 将会继续加载。

如果不是连通性问题，在LT系统中检查LTRC标签"Application Logs"中的ABAP转储文件盒系统日志来得到进一步的信息。

如果只是个别的表出错：

检查事务LTRC表"Application logs"，ABAP dumps 和系统日志来得到进一步的信息。

检查事务LTRC表 “Load Statistic”, 选择 “Load in process” 来得到表中失败部分的数目。在问题解决之后监控失败部分的数目是否下降。

典型错误1：

应用日志错误:

Run … aborted due to DUPLICATE KEY on …

解决方案:

将转移行为改成"Array Insert"

- LTRC 标签 "Data Transfer Overview"选择这个表和点击 modify (pencil)键，在弹出窗口中把"Transfer behavior" 改成"3 - Array Modify" 然后保存。
- 监控 LTRC 标签"Load Statistics" 之后你应该看到错误数量减少了。

典型错误2:

应用程序日志错误:

rscpLangCPListGetCPtry failed (16): lang: …

原因: 非统一码的源系统和包括双字节语言/客户代码页

解决方案:

同样的代码页必须在LT系统中被定义。为了安全起见，最好是定义与源系统一样数目的代码页。

字段类型映射是给表使用的:

该做什么:

检查源表确认源字段中是否包含一个空值

解决方案:

如果源字段包含一个空值，LT系统中空字段中的转换规则应该被实施。

5.加载完成并且复制状态还未被改变（在HANA studio中停滞在状态"load, executed"）

检查是否没有空闲的BGD工作进程或者主要控制工作停止（参考先前的章节"field ‘Logging table’ is empty.”)。

如果主控工作没有问题.

检查LTRC标签 "Mass Transfer Overview"中表的"In process"标志是否总被设定？

- 是的话，即"In Process"标志总是被设定的。
  该做什么:
  - 事务 LTRC标签 "Expert Functions",执行选项 "Reset Load and Replication Status" (重置 "In process"标签和 "Failed" 标签).
  - 然后监控一段时间看看表是否转换到了一个复制状态。
- 不是的话，即 "In Process" 标签没有被设置。
  在同一标签上面检查是否 Def, Gen, Cal标签中有的丢失了？
  - 是的话，即 Def, Gen, Cal标签中一个或者几个丢失了。
    该做什么:
    - 在LTRC标签"Processing steps"中试着手动触发第一个丢失的步骤，之后刷新看看是否丢失的X被设置了，下一个丢失的标志之后也被设置。如果没有检查应用程序记录，反馈给SAP更多的细节。

Def	Define Load/replication object
Gen	Generate runtime object
Cal	Start Range calculation

如果上面的都不是的话，在LT系统上检查LTRC标签 "Application Logs" 中的ABAP转储文件，系统日志得到更多的信息，反馈给SAP。

6.复制停止工作

Notes:

检查源系统与HANA目标系统的连接是否正常。

确保数据加载工作都运行正常(事务号 SM37)。

----

检查HANA studio 或者LTR中表的状态:

如果表的状态是 "replicate, in process":

是否原始加载过程中有许多表，并且在模式配置中数据加载工作的数量与初始加载工作的值相等？ -> 如果相等的话：所有的数据加载工作都被原始的加载所占据了，没有工作用来复制->把初始加载工作的值设置成一个较小的值。

是否原始加载过程中有许多表，并且在模式配置中标的数量比数据加载工作的数量多？

- 是的话。模式配置中数据加载工作的数量与初始加载工作的值相等？
  - 如果相等的话：所有的数据加载工作都被原始的加载所占据了，没有工作用来复制
  - 解决方案:
    - 选项 1: 模式配置中降低初始加载工作的值，保持数据加载工作的值。
    - 选项2:如果系统上面有BGD工作，降低数据加载工作的值，保持初始加载工作的值。
- 不是的话. 在源系统中检查记录表条目（相关的记录表名检查tx. LTRC 标签 "Table Overview"）
  - 如果记录表条目频繁地增大或者减少？
    - 是的话。 ->复制工作工作良好。
    - 如果条目只增加但是不减小
      该做什么:
      - 检查 tx. LTRC 标签 "Application Logs", ABAP转储文件和系统运行记录以便得到进一步的信息。
      - 也有可能是源表中的无效记录阻止了复制工作->需要SAP IMS来做进一步的检查