SAP HANA 工作室（SAP HANA Studio）
1). SLT心跳检测
或许你可能知道SAP HANA工作室在SLT复制时扮演的是被动的角色。所有你在数据配置（Data Provisioning）屏幕看到的信息都是来自于本地的SAP HANA表。
例如，已复制系统的列表存储在表RS_REPLICATION_COMPONENTS，位于SYS_REPL模式下而每张表的复制状态信息存放在相应模式的RS_STATUS表中。同样，所有用户进行的操作并不是直接执行而是放在表RS_ORDER (或者表 RS_ORDER_EXT)中。
SLT系统监控这些命令表的状态并且依次更新状态表中的当前活动。
这种被动的方式提供了很大发生错误的空间。万一SLT没有正常运行或是完全不工作—就没有办法在貌似一切都正常的数据配置屏幕中看到错误。
潜在的解决方案非常简单。SLT能以固定时间间隔更新特定SAP HANA表的时间戳 而数据配置驾驶舱（cockpit）能够翻译这些值，因此如果时间戳在一段时间后没有更新，那么，SLT出错的可能性就很大。
2). 对于复制错误的简单解决方案
当表的复制在错误的状态时，那么你在SAP HANA工作室中是没有任何办法来解决这个状态。唯一的办法就是运行SLT系统中的高级监测工作台，这需要非常专业的知识。
用户能够在数据配置屏幕中直接运行一种类似“自动修复”的功能，该功能会尝试进行一致性检查、清理，并且必要的话，在用户确认之后提供新的给定表的数据配置；也应该提供给用户关于错误的性质、给谁打电话以及在哪里继续调查的简单解释。
3.) 整体复制进度条，表加载进度
当你开始复制多张表时，你能做的只能是被动地等待。你可能会猜想表的更新状态整体进度，但是，进度信息是没有显示的。
一个解决方案就是调整数据配置屏幕来包含简单的进度条，以及把整体复制状态以文本显示（比如，与数据迁移时R3显示加载状态类似的方式“Replication status: running 3, waiting 8, completed 13, failed 1, total 25”）。
另一个不便之处就是缺少每张表的复制进度—特别是运行初次加载（initial load）。对于大表的情况，初次加载（或者一般的加载操作）可能需要几十分钟或几个小时。
你仍然有可能去手动检查源表的数据行数（查询数据库的统计数据或是在表DBSTATTORA查询ABAP统计数据），然后你可以查看已经加载至SAP HANA数据库的条数（利用Show definition功能）比较这两个值可以给你加载进度的提示。然而，这是一个繁琐的手动过程，可以很容易地实现自动化。
4). 初次加载估算/重新配置估算
当你被要求配置一张表时，往往跟着的问题就是“这将要多久？”。目前没有办法可以预测，尤其是当你在新的硬件上第一次复制，你可能只能根据表的大小有粗略 的估算，然而这是很不准确的。
解决方法也是很简单的。所需的只是SLT需要收集不同的统计数据，然后（如果客户同意）这些数据会发送给SAP来作分析。
应当收集以下信息：
SLT正在运行的硬件配置—这可以用来计算第一个代表机器“力量”的参数(HW_POWER)。
表名（以及相应的结构）—这可以用来估算表的复杂度或者直接把复杂度分配给众所周知的SAP 表中(TABLE_COMPLEXITY)。
表中的记录数以及表的大小—这可以代表复制的规模因子(TABLE_SIZE)。
复制持续时间—初次加载花费了多长时间（REPLICATION_TIME）。
这些值可以用来创建下面的公式和找到适当的通用变量：
REPLICATION_TIME = TABLE_SIZE * TABLE_COMPLEXITY / HW_POWER
当然，SLT收集的历史数据也可以使用，以防表需要再次配置。
SAP HANA工作室的数据配置屏幕应该包含有关表的详细信息或者选中将要配置的表的信息，包括时间估算。
SLT系统
1). 一致性检查和清理功能
我真的喜欢SLT作为我SAP HANA复制的第一选择。然而，我必须说事情并没有像所期望的那样工作。虽然复制的规则是很简单的，但是实施很抽象以至于有很大的发生错误的空间，并且错误发生的频率比认为正常的多。
我在防止错误的发生方面没有建设性的想法，但是我对解决问题还是颇有想法。
有用的功能毫无疑问是对给定的对象进行一致性检查。我遇到过很多次的是SAP HANA（表RS_STATUS的字段 ACTION和STATUS）与SLT（表IUUC_RS_STATUS字段ACTION和STATUS）的状态不一致。这个错误很显而易见，然而如果不在SLT、HANA或者两个系统中的数据库级运行更新语句，就没有别的解决办法了。
同样的错误可以在表RS_ORDER发现，有时这些表也会有一些为了同一张更新表的“最后”记录，也会发生在当表取消配置时，它已经从事务IUUC_SYNC_MON的列表移除，但是仍然存在于大量转移（Mass Transfer）定义中，没有办法去解决这个问题。
神奇的功能将是一致性检查，其中所有这些对象将互相验证并且所有的不一致将被删除。在不明确的状态用户的情况下可以为了决策查询语句。
“孤立”的条目应自动识别并在SLT开始时删除，以保持系统的干净和整洁。
2).清除功能
有以下的选项：
清除整个STL系统
清除指定的大量转移ID
清除指定的表
另一个不错的功能将是清除配置。要删除SLT中特定表的所有内容—就如SLT从未复制该表一样。这个功能将会移除给定大量转移中相关表的记录可能的不一致，而不影响SLT复制其他表，然后可以再次安全的配置表，不用担心和过时的记录冲突。
同样的功能应该在大量转移级别可供执行（清除给定大量转移定义的所有内容），以及整个SLT级别（使得其像刚刚安装后，包括移除了所有过时的大量转移ID）。
当然，在源系统也应执行相应的清除操作。
3). 复制统计数据
有关复制过程中详细的统计数据应该包括：
在上个时期复制了多少记录（例如每小时的基础上）。
复制操作花费了多少时间。
从源系统读取和写入到SAP HANA中花费了多少时间（以确定复制时间发生在何处）。
后台作业的利用率的最小值，平均值和最大值，建议是否应该分配更多的后台作业。
所有这些数据应该提供复制流程额外的深入理解、SLT系统如果以及如何调整的可能性。
4). 复制错误的可视化
每个SLT中的活动均由一系列的步骤组成。例如，复制的流程从初次加载开始，然后由正在进行的复制组成。初次加载更可以细分到如源系统的表删除操作、源系统的表创建、SLT系统的表创建、日志表的创建、生成运行时对象、计算访问计划（access plan）和触发源系统中的创建操作等等。
正在执行的活动以及万一发生错误，复制被打断的地方并不总是很清楚显示，这将有助于为每个表提供细节，如包括信号灯并且可能查看灰色的灯变成绿色指示灯，或在故障的情况下变成红灯，指出发生错误的位置的步骤树。
这样的东西可以使得每个人更好的理解正在执行的步骤，以及更有效的确定问题。
5).故障排除向导
一旦发现了复制过程的错误（或通过一致性检查或复制过程可视化），那么故障排除向导应当执行来引导用户决定问题并指导其至问题区域。
关于该向导的不错例子可以从解决BW中数据加载问题找到（事务RSA1中）。
6).复制调整对话框（目前只能通过ABAP调整）
SLT提供了调整复制流程的可能性。类似根据定义的标准过滤行、删除行、增加新的计算列或者改变列的数据类型的功能在SLT中都是可供使用的。
但是你需要开发新的ABAP语言中的对象，并把它们注册在SLT表。然后SLT会自动调用这些对象来运行上面提到的转换。
我相信SAP现在应当侧重于产品的稳定性而非增加新功能—不过，应该利用调整数据类型的可能性。非常简单的对话，为了特定表的数据类型改变而生成代码和注册设计，可以完成工作，需要的理由会在下一点解释。
7). BO数据服务的数据一致性
这是非常重要的一点。我必须承认，我没有测试最新版本，但是我会惊讶地看到变化。
数据类型在BO数据服务和SLT复制技术有很大的不一致。SLT复制的数据类型和ABAP中的一样，往往是序列化的字符串代表的价值。最好的例子是日期字段在ABAP中以YYYYMMDD形式存储，并且SLT以同样的方式复制。
一切都很好，只要你不需要使用多个复制技术。
当你开始使用BusinessObjects数据服务时，问题出现了。BO数据服务是为了各系统之间的数据转换而设计的。允许该BO数据服务总是把源数据翻译成内部格式然后转换成目标系统使用的类型。换句话说日期类型字段存储在ABAP序列化的字符串将被解释为日期值，然后将其存储为数据类型为“日期”。
再次，只要你只使用BO的数据复制技术服务，一切都很好。
这个问题的核心是你不能轻易地连接使用序列化字符串的表和使用日期值日期的表。你可能只有通过使用公式才能实现功能，但这种方法会导致严重的性能问题和查询执行时间长。
万一你需要结合这两个技术，你得在这些复制工具中做出调整—改变BO数据服务来使用SLT复制的数据类型或是调整SLT来转换BO数据服务中的数据类型。
理想的情况是，如果这种调整可以通过点击一个按钮 – 某种“兼容模式”，可以很容易地激活BO数据服务和/或SLT。
8). 文档
最后但一样重要的是—SLT 需要文档。SLT是目前设计为一个黑盒子，管理员并不需要知道它们的内部机制。
这很好只要SLT是按预期工作。然而，这可不是每天的现实 – SLT可能会遇到问题，接着管理员没有任何指导如何去解决问题。
