系统迁移到SAP HANA 快速诊断指南

• 1. 简介
• 2. 如何从现有环境迁移系统
  • 2.1 ERP on HANA
  • 2.2 CRM on HANA
  • 2.3 BW on HANA
  • 2.4 最佳实践
    • 2.4.1  异构系统拷贝
      • i.   分拆表
      • ii.  手动导出/导入表
        
    • 2.4.2 同构系统拷贝
      • i.  使用备份和恢复拷贝系统
        • 方法1：使用SAPinst恢复
        • 方法2：手动恢复
          
      • ii.  用快照（snapshot）拷贝系统
        
      
      
  • 2.5 迁移工具版本推荐
  • 2.6 并行导入导出
    
• 3. 迁移中的问题
  • 3.1  提交代码数溢出：历史纪录表变得不可用
    • 3.1.1 故障现象
    • 3.1.2 其他术语
    • 3.1.3 原因和先决条件
    • 3.1.4 解决方案
      
  • 3.2 createoderby.jar来优化导出过程
    • 3.2.1 故障现象
    • 3.2.2 其他术语
    • 3.2.3 原因和先决条件
    • 3.2.4 解决方案
      
  • 3.3 报表程序 RUTPOADAPT 运行时间过长
    • 3.3.1 故障现象
    • 3.3.2 原因和先决条件
    • 3.3.3 解决方案
      
  • 3.4 不正确的时间以及时区设置
    • 3.4.1 故障现象
    • 3.4.2 附加关键词
    • 3.4.3 原因和先决条件
    • 3.4.4 解决方案
      
  • 3.5 BW on HANA 迁移问题
    • 3.5.1 故障现象
    • 3.5.2 其他术语
    • 3.5.3 原因和先决条件
    • 3.5.4 解决方案
      
    
    
• 相关链接
  

1. 简介

本文档将向您讲解如何将系统从现有环境迁移以及如何处理迁移中可能出现的问题。

2. 如何从现有环境迁移系统

本章节内容告诉您如何从现有环境迁移系统。

2.1 ERP on HANA

利用SAP ERP 6.0的SAP enhancement package 6, 适用于SAP HANA的版本，SAP可以在SAP ERP的现有功能上利用SAP HANA内存计算技术，使得业务应用程序运行更高效。因此，业务应用程序明显加快了处理大数据量的速度。SAP HANA包含所需的硬件设备以及相应的应用软件（例如，SAP HANA数据库和数据库复制工具）。

请注意，实际表现出的性能依赖于具体的配置，数据量和数据分布关系。

SAP ERP 6.0的SAP enhancement package 6, 适用于SAP HANA的版本技术上来说非常类似于一个增强包，然而它并不属于SAP ERP增强包的发布系列，而是一个为早期用户转向SAP HANA提供的中间可选项

考虑到SAP ERP 6.0的SAP enhancement package 6, 适用于SAP HANA的版本不能支持一些行业解决方案，附加组件或功能。这个发布版在SAP ERP的发布序列之外。

这个快速指南中描述的迁移步骤假定在SAP ECC安装过程中将被迁移的SAP系统是不会改变的。然而，使用不同的服务器或者SAP系统ID也是可能的。SAP系统中，包含原始的数据库称为“源系统”，被导入数据库拷贝的系统被称为“目标系统”。

快速指南请点击：HANA Cookbook-> ERP on HANA -> View Cookbook -> Migrate

2.2 CRM on HANA

请准备您的系统并进行SAP CRM（客户关系管理系统）的迁移。

利用 SAP enhancement package 2 for SAP CRM 7.0, version for SAP HANA 这个版本，SAP可以在SAP CRM的现有功能上利用SAP HANA内存计算技术，使得业务应用程序运行更高效。这使得业务应用程序明显加快了处理大数据量的速度。SAP HANA包含所需的硬件设备以及应用软件（例如，SAP HANA数据库和数据库复制工具）。SAP enhancement package 2 for SAP CRM 7.0, version for SAP HANA技术上来说类似于一个增强包，然而实际上，它不是SAP ERP增强包发布序列的一部分，它是为早期SAP用户转向SAP HANA的一个中间可选项。

注意：考虑到利用SAP ERP 6.0的SAP enhancement package 6, 适用于SAP HANA的版本不能支持一些行业解决方案，附加组件和功能。这个发布版在SAP CRM的发布序列之外。

更多关于附加组件的支持信息，参见 Note 1768032 : SAP EHP 2 for SAP CRM 7.0, version for SAP HANA.

这个快速指南中描述的迁移步骤假定在SAP CRM安装过程中将被迁移的SAP系统是不会改变的。然而，使用不同的服务器或者SAP系统ID也是可能的。SAP系统中，包含原始的数据库称为“源系统”，被导入数据库拷贝的系统被称为“目标系统”。

参见：SAP Note 1680045 Release Note for Software Provisioning Manager 1.0.

快速指南请点击：HANA Cookbook-> CRM on HANA -> View Cookbook -> Migrate

2.3 BW on HANA

准备好您的HANA系统并迁移BW 数据到HANA数据库中。

从SAP NetWeaver 7.3 SPS05 和 SAP HANA SPS03 开始，您可以使用SAP HANA数据库来替代原有支持SAP Business Warehouse（BW）的关系型数据库。

这个过程需要将现存的BW（Business Warehouse）数据迁移到SAP HANA数据库（至少SPS03版本），无损现存的Business Warehouse数据或进程。在迁移之后，BW仅仅使用HANA做底层的数据库支持。

快速指南请点击：HANA Cookbook -> BW on HANA -> View Cookbook -> Deploying BW on HANA

2.4 最佳实践2.4.1  异构系统拷贝

如果目标系统中的操作系统或者数据库和源系统中的不同，我们称之为异构系统拷贝。该系统拷贝将由R3load实施，它将源系统中的所有SAP表导出，并将这些表导入目标系统。

i.   分拆表

注意：这部分的执行需要有丰富的系统迁移经验，也仅仅是在非常紧急时候运用，同时请联系SAP技术支持。

为了加速导出/导入大型表，SWPM提供Table Splitting Preparation 选项，用于分拆大型表到许多个数据包中，以便R3load可以对它们并行导入/导出。这里要求每个包的大小要相同或类似。

Table Splitting Preparation  in SAPinst            

在这一阶段，R3ta会生成WHR文件告诉R3load如何分拆表。

R3ta 根据下面两个文件来创建WHR文件。

R3ta_hints.txt: R3ta_hints.txt 被保存在以下路径：<ins_media>/COMMON/INSTALL，这个文件包括拆分后的表的主键项。

主键项应该是可选的。在DB05中，我们可以确定哪一个字段在主键项列表是最多被选的。

<splitting_table>.txt:  这个文件定义为了创建分拆后的表需要用户创建多少个数据包。

例如：

            

文件名将在如下阶段被指定：Table Splitting.

例如：

在执行完选项：Table Splitting后，WHR文件创建在目录 <Export directory>/ABAP/DATA.

但是R3load 不能根据WHR文件平均分拆表。

所以我们需要手动地调整WHR文件。使得每个包的大小基本保持一致。

ii.  手动导出/导入表

注意：这部分的执行需要有丰富的系统迁移经验，也仅仅是在非常紧急时候运用，同时请联系SAP技术支持。

因为工具本身的问题，我们不能在迁移的时候导出或导入表。所以我们需要手动来完成这一步。

导出步骤 1：

使用系统管理员的身份，为导出功能创建TSK文件和log文件

模板：

R3load -ctf E /<path>/<tablename>.STR /<path>/DDL<DB>_LRG.TPL <tablename><pkg_No>.TSK <export-db> -where /<path>/<tablename><pkg_No>.WHR -l <tablename>-<pkg_No>.log

*DDL<DB>_LRG.TPL  and <tablename>.STR  来自于安装路径 : sapinst_instdir/…/PRETABSPLIT/Split.

导出步骤 2：

手工创建文件：<tablename>.cmd

模板：

*tsk: “/<path>/<tablename>-<pkg_No>.TSK"*

icf: "/<path>/<tablename>.STR"

dcf: "/<path>DDL<DB>_LRG.TPL"

dat: "/<path>/ABAP/DATA/" bs=1k fs=1000M

dir: "/<path>ABAP/DATA/<tablename>-<pkg_No>.TOC"

导出步骤 3：

使用系统管理员身份，从数据库中导出数据。

模板：

R3load -e <tablename><pkg_No>.cmd -datacodepage 4103 --l <tablename><pkg_No>.log -stop_on_error

---

导入步骤 1：

使用系统管理员的身份，为导入功能创建TSK文件和log文件

模板：

R3load -ctf I /<path>/<tablename>.STR /<path>/DDL<DB>.TPL <tablename>-<pkg_No>__<option>.TSK <import-db> -where

/<path>/ <tablename><pkg_No>.WHR -l <tablename><pkg_No>__<option>.log --o <option>

*DDL<DB>.TPL  and <tablename>.STR  来自于安装路径 : sapinst_instdir/…/PRETABSPLIT/Split.

需要将DDLHDB.TPL替代成note1753759中的附件。

导入步骤 2：

手工创建<tablename>.cmd

模板：

*tsk: “/<path>/<tablename>-<pkg_No>__<option>TSK"*

icf: "/<path>/<tablename>.STR"

dcf: "/<path>/DDL<DB>.TPL"

dat: "/<path>/ABAP/DATA/" bs=1k fs=1000M

dir: "/<patch>/ABAP/DATA/<tablename>-<pkg_No>.TOC"

导入步骤 3：

使用系统管理员身份来将数据导入数据库

模板：

R3load -i <tablename><pkg_No> __<option>.cmd -datacodepage 4103 --k <migration_key> --l <tablename><pkg_No> _<option>.log --c 100000 -rowstorelist /<path>/rowstorelist.txt

*Rowstorelist.txt 来自于 note-1659383.

2.4.2 同构系统拷贝

为实施同构系统拷贝，要求操作系统和数据库必须相同。（操作系统或数据库的版本可以不同。例如：Oracle8------>oracle11）

i.  使用备份和恢复拷贝系统方法1：使用SAPinst恢复

当完整的数据备份存在时，SAPinst 来处理ASCS 和Primary instance安装，并运行恢复。

• 在源系统中执行数据备份
• 可选步骤：如果从多节点系统拷贝HANA数据库到单机系统，需要在目标系统下执行以下SQL命令。
  

     举例：（源系统有三个节点）

     alter system alter configuration('daemon.ini','system') set('indexserver.c','instanceids')='40,42' with reconfigure;

• 将备份数据转移到目标系统（数据库）
• 在应用服务器（Application server）上运行SAPinst，如下述note所示，选择：Homogeneous System Copy（同构系统拷贝）
• 然后SAPinst接下来会安装新系统。SAPinst 执行数据恢复
  

      更多信息请参见：note- 1844468 and 1749467.

      1844468 Homogeneous system copy on SAP HANA

      1749467 Copying SAP HANA From a Multiple- to a Single-Host System

方法2：手动恢复

完整的数据备份存在时，用户手动执行ASCS和Primary instance安装，并执行恢复。

这种方法的适用情景：移动或分拆application instance到其他服务器上。

• 在源系统执行数据备份
• 可选步骤：如果从多节点系统拷贝HANA数据库到单机系统，需要在目标系统上执行以下SQL命令。
  

举例：（源系统有三个节点）

          alter system alter configuration('daemon.ini','system') set('indexserver.c','instanceids')='40,42' with reconfigure;

• 手动在目标系统上执行数据恢复
• 用SAPinst安装ASCS和Primary instance
  

          SAPinst(Welcome screen) => <Product Version> => <DB> =>System Copy => Distributed System =>Based on ABAP =>ASCS instance or Primary Application server Instance

ii.  用快照（snapshot）拷贝系统

用户无法停止应用系统来做完整数据备份。

这个方法的适用情景： 生产系统不能停止，但此时需要建立开发系统。

• 在源系统上用命令创建快照（snapshot）：backup data create snapshot
• 拷贝 data volume 文件到目标系统
• 在源系统上用命令删除快照：backup data drop snapshot
• 可选步骤：如果从多节点系统拷贝HANA数据库到单机系统，需要在目标系统上执行以下SQL命令。
  

举例：（源系统上有三个节点）

           alter system alter configuration('daemon.ini','system') set('indexserver.c','instanceids')='40,42' with reconfigure;

• 在目标系统中重命名（或者删除）data volume文件，log和data backup（数据备份）文件
• 在目标系统中，从系统中用系统管理员身份运行以下命令一激活快照。
• hdbnsutil -useSnapshot
• hdbnsutil -convertTopology
• 用SAPinst安装ASCS和Primary instance
  

          SAPinst(Welcome screen) => <Product Version> => <DB> =>System Copy => Distributed System =>Based on ABAP =>ASCS instance or Primary Application server Instance

  更多信息请参见：note- 1703435 and 1749467.

          1703435 Creating a copy of a running instance using snapshots

          1749467 Copying SAP HANA From a Multiple- to a Single-Host System

2.5 迁移工具版本推荐

关于迁移所使用的工具，我们建议您在开始迁移之前先查看note 1680045。

这个note包含SWPM的所有信息.

2.6 并行导入导出

请参照以下步骤进行选项 : export and import in parallel.(并行导入导出)

<SAP SW>=> <data base> => System copy => source system => Database Instance Export.

  

在通过几个步骤之后，您将发现选项 : Perform Parallel Export and Import.( 执行并行导入导出 )

3. 迁移中的问题

这部分提供特定迁移问题的解决方案。

3.1  提交代码数溢出：历史纪录表变得不可用3.1.1 故障现象

SAP-HANA-optimized DataStores 从变更日志中提取数据没有返回任何结果。 变更日志的回滚请求返回错误。 拥有历史纪录表的合并表操作返回错误。

3.1.2 其他术语

InMemory DSO, SAP-HANA-optimized DataStore, IMO, Changelog extraction, history table, HANA, BW on HANA, BWonHANA

3.1.3 原因和先决条件

遇到这个问题需要同时满足两个先决条件：

• 这个问题只存在于如果历史纪录表是在Revision 45之前被创建，例如：将一个标准DSO转化为SAP-HANA-optimized DataStores
• 超过2^31个提交在HANA数据库上被执行。
  

背景:

历史纪录表中包含内部列$validfrom$ and $validto$. 这些列用来存储那些插入或者更新记录进历史表的事务的提交ID。

在版本SP5（Revision 45）之前，这些列用 INTEGER（4 Byte）类型创建。在revision 45，这种数据类型变成了BIGINT（8 Byte），所以，所有在Revision 45或之后版本创建的历史表没有这个问题。

如果超过2^31个提交操作已经被执行，那么查询这些列的时候会发生数值溢出，返回一个空的结果集。

为了找出是否有DSOs仍旧使用4 byte的数据类型（先决条件1），请在HANA studio里用SYSTEM用户执行如下SQL语句，该语句会返回DSOs的激活的数据表。如果这个语句没有返回结果，就没有必要做进一步检测：

select distinct(table_name),schema_name from sys.m_cs_tables_ where table_oid in (select table_oid from sys.cs_COLUMNS_ where  column_name = '$validfrom$' and  trex_type_id = 73) and table_name like '%00' order by table_name

为找到包含历史纪录部分的所有表，请执行以下语句：

select distinct(table_name),schema_name from sys.m_cs_tables_ where table_oid in (select table_oid from sys.cs_COLUMNS_ where  column_name = '$validfrom$' and  trex_type_id = 73) order by table_name

为了找到现在您的HANA提交ID计数器（先决条件2），请在HANA studio里用SYSTEM用户执行如下SQL语句：

create table dummy_check_table___(x int primary key);

insert into dummy_check_table___ values (1);

--commit; only needed when autocommit=off

select top 1 last_commit_id from SYS.M_TRANSACTIONS_ where CONNECTION_ID = CURRENT_CONNECTION;

drop table dummy_check_table___;

last_commit_id 与 2^31 之间的差距能说明采取措施的紧急程度。

如果last_commit_id 大于 2147483648 (2^31)，你可以用系统管理员身份执行以下语句（其中的表名是一个例子）来得到所有需求有问题的DSO。

select distinct(SID) from "/BI0/A<DSO-NAME>80" WHERE "$validfrom$">2147483648

该问题的其他提示：

你在indexserver_alert 中发现记录如下 [46978]{-1}[240/718257265] 2013-06-27 10:00:45.369678 e attributes SingleUpdate.cpp(00685) : Additional info for previous 6930: index "SAPBWN:/BI0/A<DSO-NAME>80 (317462)", attribute "$validfrom$", docid 205, value "2482785352"

3.1.4 解决方案

这个问题的解决办法是把HANA升级到60以后的SP6版本。 这个版本包含了一个迁移程序，可以转换列$validfrom$ 和 $validto$的数据类型为BIGINT（8 Bytes）。包含该迁移程序的确切版本信息很快会在note中公布。

如果是在$validfrom$ 和 $validto$ 列中还有4字节数据类型的SAP-HANA-optimized DataStores，但是提交的ID数还没有到达2^31，那您现在可以做如下尝试：

请把您的HANA数据库升级到Revision 57 或 58

请将您的BW系统升级到7.30 SP8 or SP9, 7.31. SP7 or SP8，执行SAP Notes 1849498 和 1849497；或者，升级您的BW系统到包含有关ABAP coding的版本 7.30 SP10 or 7.31 SP9 。

根据这些notes和service packs的帮助，我们建议您为Standard DSOs使用新的激活程序，并将所有SAP-HANA-optimized DataStores转换为Standard DSOs

关于新版激活程序的更多信息，请参见下面的blog：

http://scn.sap.com/community/data-warehousing/netweaver-bw/blog/2013/05/10/bwonhana-standard-dso-also-optimized-for-hana

其他所有情况，请在BC-DB-HDB 或 BW-SYS-DB-HDB 组件中创建一个ticket。

详细信息请参见 Note 1879656

3.2 createoderby.jar来优化导出过程 3.2.1 故障现象

Migmon 只是按照名字首字母在字母表中的顺序来分类导出包（package）和表（table）。

这样可能会导致一个运行时间很长的包因为名字而被排在最后进行处理，从而造成总体导出时间过长。

3.2.2 其他术语

order_by.txt export systemcopy hana migration

3.2.3 原因和先决条件

想要通过创建order_by.txt文件来优化导出时间

3.2.4 解决方案

• 可以用createorderby.jar这个工具来优化导出时间，尤其是对SAP HANA系统采用并行导出/导入的时候：
  

迄今为止，导出过程一直采用英文字母表序列。而现在通过这个工具，我们可以根据包的导出运行时间来将他们分入作业组（job groups），从而实现对导出时间的优化。

• 为此，我们需要给导出操作创建一个名为order_by.txt的文件（和MigmonCtrl给导入操作创建order_by.txt文件相类似，尽管导出和导入有不同的次序标准）。
  

• 先决条件是需要执行过一次导出过程，因为分组时需要的export_time.txt 文件是在这个过程中创建的。因此，这个工具是用来优化并行导出/导入的迁移的（同样适用于优化重复多次的导出）。
  

• 这个工具提供了以下参数：
  

-h         列出了可供使用的参数和语法

-exportTimeFile [./export_time.txt] <export_time.txt 文件所在位置>

使你能够为export_time.txt 文件指定另外一个位置

-minRuntime [100] <能够成为作业组的包的最小运行时间>  

指定了将被该工具以秒为单位进行评估的包的最小运行时间------其他低于这个阈值的作业将在order_by.txt 外部运行

另外， order_by_visual.txt  文件会提供关于被创建的作业组和它们预期的导出时间的概述。例如：  
[ _BIC_AP_JTD03400-2 ]  
#9228 seconds  
jobNum=1  
_BIC_AP_JTD03400-2    9228  
[ _BIC_AP_JTD03400-4 ]
#9194 seconds  
jobNum=1  
_BIC_B0001693000      102  
_BIC_AP_JTD03400-4    9092   

• 这里，每个组将有一个作业，并且应当与最长运行时间的作业组（在本例中，是运行了9228秒的_BIC_AP_JTD03400-2）有一样（或者更少）的运行时间。
  

• 如果在created order_by.txt 中的作业数目超过了export_monitor_cmd.properties 的参数 jobNum= 中所设置的作业数, 这两者的数目和将被用作作业编号。
  

• 总体而言，我们推荐下面的步骤来对并行导出/导入进行优化：
  

在没有createorderby.jar工具的情况下执行初始化导出（因为此时还没有可用的export_time.txt文件）

根据需要使用拆分表和包的方式（如上文所述）优化导入时间

在这之后，用createorderby.jar来优化导出时间

通过这样结合的并行导出/导入步骤，我们就能从优化运行时间上获益

• 该工具被包含在MIGTIME.SAR最新的文件存档中，由software provisioning manager 1.0提供：Navigate to <Extracted Software Provisioning Manager Archive>\COMMON\INSTALL).  
  

请检查MIGTIME.SAR中是否包含createorderby.jar，如果可用的话，请将其解压。

如果不行，请在note中的附件中下载该工具。

已知错误  
18.06.2013  "RuntimeException: <TABLE> Parameter runtime must have the format HH:MM:SS !  
您使用了选项 -top 来创建 export_time.txt.。这不在createorderby.jar的涉及范围中。一个修正版的createorderby.jar已经被附在这个note中。 其中一个应急方案是不要对时间分析器（time analyzer）使用-top 选项。

• 具体细节请参见Note 1873729
  

3.3 报表程序 RUTPOADAPT 运行时间过长3.3.1 故障现象

在向SAP HANA数据库做系统迁移的时候，在目标系统中会执行报表程序RUTPOADAPT。该报表将池表（pool table）转换为透明表（transparent tables）

该报表会运行几个小时。在事务代码SM50中，您将注意到对表DD03L的选择访问花费了最多的时间。

3.3.2 原因和先决条件

SAP HANA优化程序策略对下列选择命令的处理欠佳：

SELECT tabname FROM DD03L

WHERE precfield = ? AND as4local = ?

3.3.3 解决方案

根据SAP HANA revisions 56的数据库端解决方案。

您可以使用如下解决方案来解决这个性能问题：

用索引 DD03L~6 来增强字段 AS4LOCAL

对以上一些表述的定义:

索引字段（Index fields）:

PRECFIELD

新定义:

索引字段:

PRECFIELD

AS4LOCAL

然而，在问题被SAP HANA数据库内部解决之前，这个改变只应是一个暂时性的解决方案。

具体细节请参见 Note 1855223

3.4 不正确的时间以及时区设置3.4.1 故障现象

错误信息 ZDATE_LARGE_TIME_DIFF

不正确的时间

在夏令时（daylight saving time）变化的过程中有问题

3.4.2 附加关键词

Timezone, UTC, GMT, time, date, tz, rsdbtime

3.4.3 原因和先决条件

• 该问题主要是由数据库或R/3系统的进程没有设置正确的时区造成的
  

• 由于操作系统的时间基准UTC时钟是由‘日期’间接设定的，所以本地时间（例如日期）的正确显示并不确保设置是正确的。如果时区设置错误，而正确的本地时间通过‘日期’被设定，那么UTC时钟的值也一定是不正确的。
  

• UTC时钟从格林威治标准时间01/01/1970, 00:00:00，开始以秒计数。在正确的设置下，无论位置在哪里，它的值在所有计算机中是相同的。
  

• 在向夏令时的转换过程中以及分布式系统中时区设置的错误会不可避免地造成该问题
  

• 时区和UTC时钟是操作系统层面上的属性，不属于应用软件（如操作系统或者R/3）的范畴。
  

3.4.4 解决方案

请按照如下步骤解决该问题：

1. 设置UTC时钟

• 关闭数据库和 R/3
• 以超级用户 (root)权限登录系统
• 设置 General Mean Time (GMT) 时区 (格林威治时间) ，例如在 C-shell中 使用 'setenv TZ GMT'.
• 用‘日期’来显示时间
  

显示时间必须和格林威治时间匹配。

格林威治时间比欧洲中部夏令时时间落后2个小时，比欧洲中部冬令时时间落后1个小时。

• 如果不是这样，您必须对UTC时钟用‘日期’来进行更正。注意：您必须在这里输入正确的格林威治时间。
  

现在UTC时钟已经被正确设置。

2. 设置时区

            使用您用来设置或查看时区设置的用户登录，例如ora<sid> or <sid>ad

            用‘日期’来显示时间。所显示的时间必须和本地时间在夏令时和标准时上都能匹配

            如果不是这样，您必须设置一个正确的时区，例如使用C-shell 'setenv TZ <zeitzone>'

如果您有对正确时区的疑问，请联系您的操作系统生产商。

• 确保在有疑问的用户的登录脚本中对正确的时区进行自动设定
  

• 在操作系统中设置一个默认的正确时区会更好。这样的话您就无需在登录脚本中设置时区了。
  

• 确保那些没有使用正常登录过程开启的进程 (例如通过 'rexec', 'cron') 也有一个正确的时区设置。如果一个 R/3子系统从CCMS系统检测器或一个R/3 启动配置文件或一台计算机（而不是‘本地’）开启的话，那么它将会随着rexec被启动。
  

• 现在时区已经为数据库和R/3进程进行了正确的设置。
  

3. 对R/3的设置进行检查

• 开启数据库（DB）和R/3
  

• 开启R/3报表RSDBTIME，所有时间现在应当被正确地显示
  

• 如果时间没能被正确显示，请检查在数据库影子进程（DB shadow processes）和R/3进程中的环境变量TZ设置，例如用'ps eww <prozessnumber' 或者一个合适的操作系统监视器。’ps’能够显示出环境变量的内容，然而这只能在BSD模式下使用，不是在所有UNIX派生版本中都有。如果您有疑问，请联系您的操作系统生产商。
  

具体细节请参见 Note 101726

3.5 BW on HANA 迁移问题

DSO 对象迁移问题

3.5.1 故障现象

DSO对象在从BW系统迁移到BW on HANA系统之后应当有列式存储表。SAP HANA-optimized DataStores （使用事务代码 RSMIGRHANADB）。在这个过程中，该表的布局将被变更日志中的数据以计算视图进行运算的方式所改变。这得益于出色的激活性能。

从HANA版本57开始，我们不再需要这种转换或对SAP HANA-optimized DataStores的清晰建模。所有标准的DataStore对象现在都会利用拥有可媲美性能的SAP HANA-optimized进程或者回滚进程。在这个过程中，变更日志中的数据将被保存在透明表中，因此不再需要对表的布局进行转换。通过支持非激活数据的概念（参见SAP Note 1767880）,内存消耗依然保持在SAP HANA-optimized DataStores的水平。

当这个SAP Note可供使用之后，将无法创建SAP HANA-optimized DataStores。已有的SAP HANA-optimized DataStores仍将被支持。然而，为了保持标准化，我们建议您将SAP HANA-optimized DataStores对象转换为典型的DataStore对象。

具体细节请参见Note 1849498

3.5.2 其他术语

HANA-optimized DSO, RSMIGRHANAD

3.5.3 原因和先决条件

您在使用一个版本高于或等于57的DBMS SAP HANA SP5.

3.5.4 解决方案

执行SAP note 1849497

1849497: SAP HANA: Optimizing standard DataStore objects

相关链接

• Data Migration
• ERP on hana Migration(Migrate an existing IDES ERP 6.0 EhP5 running on Oracle 11.2g to SAP HANA)
• "Migration Guide" Home(Migration from CRM Web Channel 7.0EhP1 to CRM Web Channel 7.0EhP1e)
• BW on HANA
• DOM:upgrade and migrate SAP systems to SAP HANA
• Note 1799545(upgrade-and-migration--bw-on-hana)
• Heterogeneous OS and DB Migration of R/3 Systems(Version 3.2)
  

来源：SAP HANA中文维基