在SAP HANA中旅行

2020-09-26 22:13发布

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


我们在SAP HANA中遇到了一些有关"时间旅行"的白皮书,但是我希望了解一些事情:

1。 在HANA vs Enterprise的运行时版本上使用TIme Travels时,HANA上的行为是否存在任何差异(例如,运行时-Banking Services或CRM等数据库中的HANA,如db)?/p>

2。 关于TT,当HANA数据库作为SAP解决方案的专用数据库运行时,是否应该关闭自动提交(要求TT正常工作)?

还是AUTOMCOMMIT OFF仅适用于开发自己的应用程序? (例如Enterprise HANA)

我现在必须为last_committed_Id锤击M_TRANSACTIONS或者必须发出显式的COMMIT命令,我对此感到不满意

...更不用说考虑我们随时间推移收集历史数据可能需要的额外空间了。

如果数据遭到黑客入侵/损坏,并且我们没有足够的还原完整数据库的能力(例如,必须将整个格局恢复到相同的水平),我们将尝试使用历史记录功能来恢复到某个时间点 坑,由于依赖性)

3。是否有任何想法可以找到每个SAP解决方案的TT信息?

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


我们在SAP HANA中遇到了一些有关"时间旅行"的白皮书,但是我希望了解一些事情:

1。 在HANA vs Enterprise的运行时版本上使用TIme Travels时,HANA上的行为是否存在任何差异(例如,运行时-Banking Services或CRM等数据库中的HANA,如db)?/p>

2。 关于TT,当HANA数据库作为SAP解决方案的专用数据库运行时,是否应该关闭自动提交(要求TT正常工作)?

还是AUTOMCOMMIT OFF仅适用于开发自己的应用程序? (例如Enterprise HANA)

我现在必须为last_committed_Id锤击M_TRANSACTIONS或者必须发出显式的COMMIT命令,我对此感到不满意

...更不用说考虑我们随时间推移收集历史数据可能需要的额外空间了。

如果数据遭到黑客入侵/损坏,并且我们没有足够的还原完整数据库的能力(例如,必须将整个格局恢复到相同的水平),我们将尝试使用历史记录功能来恢复到某个时间点 坑,由于依赖性)

3。是否有任何想法可以找到每个SAP解决方案的TT信息?

付费偷看设置
发送
2条回答
软件心理学工程师
1楼-- · 2020-09-26 22:28

对此有任何想法吗?

L

悠然的二货
2楼-- · 2020-09-26 22:30

嗨Liezl

不确定这些问题是否仍然与您相关。 我现在才看到它们,所以让我们做一个快速答案:

> 1.在运行时版本的HANA vs Enterprise上使用TIme Traveling时,HANA上的行为是否有差异?

不。 "运行时"和"企业"是HANA许可证的类型,与功能或技术无关。 "时间旅行"查询在所有HANA版本中的工作方式都相同。

> 2.关于TT,当HANA数据库作为SAP解决方案的专用数据库运行时,是否应该关闭自动提交(要求TT正常工作)? 还是仅在开发自己的应用程序时才适用AUTOMCOMMIT OFF? (例如Enterprise HANA)

AUTOCOMMIT OFF或ON是适用于每个会话的设置。 您不能为每个数据库设置它。 由于此设置定义了运行会话的应用程序是否希望能够使用COMMIT和ROLLBACK来控制事务,因此,真正取决于应用程序的选择是该设置还是由用户选择。

如果您不习惯使用COMMIT,则此功能不适合您。

> ...单独考虑我们随时间推移收集历史数据可能需要的额外空间。

当然,保留旧版本的数据会占用空间。 没有免费的午餐。

> 如果数据遭到黑客入侵/损坏,并且我们没有足够的还原完整数据库的能力(例如,必须还原整个数据库),我们将尝试使用历史记录功能来恢复到某个时间点 由于依赖关系而在同一凹坑内景观)

AAAND闹钟响了!

历史表绝不是时间点恢复机制! 数据库恢复是指一致地恢复数据库状态。

仅回滚一个或几个表有两件事:

1。 您仍然可以及时恢复所有问题和外部依赖性

2。 现在,您的数据库中不再有一致的状态,因为一个表反映了较旧的状态。

难道这个旧状态实际上仍然是一致的? 可以,但是如果没有手动编程和(可能)应用程序级别检查,您将无法证明或检验。 这意味着您必须重新创建每个可以回滚的表的事务一致性。 那是您真正要避免的事情。

另一个谬误是认为历史记录表比普通表更安全,因此能够"保护"数据错误处理。 事实并非如此。

历史记录表存储在同一数据库中,因此与其他任何表一样面临相同的风险。 保护数据库的关键点是进行备份并将这些备份存储在其他位置。 如果您希望能够恢复数据库,则无法解决。

> 3.每个SAP解决方案的哪里可以找到TT信息?

由于历史记录表的许多其他方面以及它们可以/不能使用的方式,我不知道有任何主要的SAP解决方案可以使用它。 一旦方法的效率变得很明显,SAP BW就开始将其用于DSO对象,并恢复为普通表。

很高兴进一步讨论,但是我认为历史记录表没有很多好的用例。

干杯

Lars

一周热门 更多>