手机版

当前位置:主页 > 云主机 >

域名注册_oracle数据库培训_精选特惠

时间:2021-09-28 15:06:43|来源:欧普曼云|编辑:欧普曼云|点击:

域名注册_oracle数据库培训_精选特惠

HALM-changes-transport的基础知识在HALM-blog中的native-transport-of-changes中有很好的描述。在HANA源系统中启用更改记录后,云服务器价格,用户可以使用本机HALM工具或通过CTS+传输HANA更改对象(从源系统到目标系统)。正如在另一篇博客中提到的,HALM总是试图在其传输逻辑中保持源系统和目标系统的一致性。当要运输的交付单元和发布的更改的数量足够少时,大数据的商业价值,它就可以正常工作。但是,随着分配给运输路线(或CTS+)的交付单元数量的增加和发布的更改数量的增加,可用于运输的更改的计算性能会显著降低。在这里,我想说明究竟是什么影响了HALM的性能,以便您可以优化您的传输。

如您所知,HANA对象位于包中,包通常分配给交付单元。修改HANA对象时(在启用CR的系统中),修改的对象将记录在更改中。一旦修改的对象准备好进行传输,更改贡献者就会批准他们的修改并发布更改。HALM将此类发布的变更视为运输的候选变更,在成功完成运输后,HALM存储与变更一起运输的DU包裹的信息。因此,如果DU\u A由3个包组成:"aaa"、"bbb"和"ccc",并且发布(和传输)的更改包含所有包的对象(例如,对象A、对象B和对象C),那么HALM以{source\u system,DU,package,运输更改}在这种情况下:

SRC DU_A aaa change1(发布时间:2016年1月1日00:00)

SRC DU_A bbb change1(发布时间:2016年1月1日00:00)

SRC DU_A ccc change1(发布时间:2016年1月1日00:00)

找出可用于运输的已发布更改(并对其进行分析),下一次,HALM将询问源系统中的存储库关于2016年1月1日00.00.00之后发布的更改。这是一个理想的情况。您可以想象change1只能包含包"aaa"和"bbb"的对象。在这种情况下,目标系统中将丢失有关传输的"ccc"包的信息,HALM将不得不询问从一开始(当CR打开时)起发布的DU更改。如果不久前启用了CR,这肯定不是问题。但如果同时发布数百(甚至数千)个DU变更,HALM将需要分析所有这些变更。这是一个耗时的操作。这就是为什么它可能是一个很好的理由,不时传输一个完整的DU(释放对象)。在这种情况下,HALM将为所有DU包存储上次成功传输的时间戳。

不幸的是,使用HALM传输的更改并不意味着它将永远不会再被传输。如您所知,DU在源系统中可以很容易地重新构造:包可以被分配和/或取消分配,这是一种不好的做法。但这些变化是基于分配给运输路线(或CTS+)的运输单位进行运输的。因此,在传输变更时,实际上仅传输属于传输路由/CTS+中定义的交付单元的对象。如果一段时间后新的包裹被分配到源系统中的一个交付单元,那么更改和许多(可能是很多)已经传输的更改必须重新传输。

所有描述的信息也与CTS+传输场景有关。不幸的是,在本机HANA场景中,您可以为一条传输路由分配一个或多个传递单元,而在这里没有这样的灵活性来对传递单元进行分组。在CTS+的情况下,您只需定义要通过CTS+传输的交付单元,它可能是一个非常长的列表。从性能的角度来看,您可以想象一件事是分析几个交付单元的更改,而另一件事是对20、50或更多的交付单元执行相同的操作。在这里,通过提供一种仅为分配给CTS+控制交付单元的所有选定子集发起传输的方法,数据分析方法,HALM仍然可以得到改进。请记住,服务器云,在这里可以使用相同的策略来不时传输"完整DU"以提高性能。

嗨,Yuri,

感谢您的详细解释。

在我们的例子中,我们有多个DU,属于共享同一HANA实例的多个团队。计数不到20个。

所有这些DU都分配给CTS+。

我的团队有两个最大的DU。

-DU1:约有50个包

-DU2:约有25个包

-每个包约有20个对象。

其余的DU归安全和接口等团队所有。到目前为止,这些DU的变化非常小。与这些DU相关的包装没有变化。

问题陈述:DU1和DU2每天都有大约10个变化,我们已经发布并准备好运输到质量。还有一些发布的变更ID"永远不会被传输"到quality。弹出窗口显示传输更改需要5到10分钟。

可能的解决方案?:按照您的建议,我是否应该从CTS+中"取消分配"除(DU1和DU2)之外的所有其他DU。迁移我的更改,然后在我传输完当天的更改后将DU分配回CTS+?

您好,

Sudarshan

您好Sudarshan,

您的案例中的主要问题是声明"…还有一些发布的变更ID永远不会被传输到"质量",这是一个HALM不是真正为之设计的场景(我知道,与ABAP world相反)。这个想法是,如果您的DEV系统中有这些对象,并且这些对象已经发布,那么它们可以(或者我可以说,甚至应该)传输到QA。大部分时间花在分析每个发布的变更的内容上。因此,如果至少有一个包被分配给一个DU(在源系统中),云服务器哪里好,而这个DU从来没有被传输到目标->所有发布的(因为CR是打开的)更改都将被读取和分析!而且由于发布的变更数量在增加,处理时间也在增加。通过传输一个完整的"DU"(比如说,每月一次左右),HALM只需读取和分析DU发布的最长1个月的变更。

对于其他未积极用于传输的DU,"从CTS+中取消分配"和"分配回"可能是有意义的,只有在需要运输时才进行。

Copyright © 2020-2021 深圳市飞博可科技有限公司 版权所有 备案号:粤ICP备17063389号