来看看ODQMON/ ODP extractors/ operational delta queue

我觉得得在标题里尽量多写关键词,要不然我以后找不到。
开会的时候讲到这个ODQMON了。嗯,我知识盲区。

我记得好像之前我也看过,但是为啥我一点印象都没有呢? 那只能说这个东西对于我来说太陌生了,我看一遍两遍,只能记住名字,不能记住脸。
那咋办,只能多看几遍。没办法啊。。
而且我当时记的模型肯定有问题,要不然我也不会啥啥啥都记不住,哎,典型的差生啊。基础知识不足,还不能举一反三。

写之前,先把Open ODS view概念写下:
ODS先不管,它是个view,它是一个BW metadata对象,提供了结构描述(对于attributes(fields)和数据类型).它是表示source system上面的视图,并且对该source添加了分析性的元数据。
就是一个更灵活的外部数据,不需要在BW里面建info objects了。这里面有个元数据的概念,和source system以及infosource的概念都不同。可以理解为data dictionary和啥啥的。Open ODS view全称: open operational data store view,开放性运营数据存储视图,这个翻译我自己写的,不知道咋翻译。你可以理解为,ERP或者其他运营系统的数据试图。理解为数据源。
以上,与本篇没啥关联,主要就是想别跟ODP搞混了。这个ODP呢,是operational data provisioning. 运营数据提供。这个是一种方法,就是替代PSA来的。
这一块其实我也不能讲清楚,我自己也有很多疑问,也许以后会慢慢看,暂时我也不能融汇起来讲,只能单点写了。
知道数据提供 ODP(operational data provisioning)了 紧接着来的,就是ODQ (operational delta queue) 增量队列。如果是小白,对增量队列就又不懂了。原先传统BW增量队列是在SAP ECC系统里的RSA7。

文章目录

  • 传统增量队列
    • full和delta
      • delta 的方式
        • delta的具体实现
  • ODP、ODQ
    • ODP的工作原理
    • ODQ
      • ODQ的 Push/Pull
      • ODQ 的保留时间
      • ODP 抽取验证
      • ODQ出错处理
      • ODQ error: internal kernel error/ DDIC_TYPE_INCONSISTENCY

传统增量队列

BW和ERP是紧密集成的,也就是说BW的数据每天都得从ERP抽取过来,保持同步,及时更新。BW的模型建好了之后,那数据是怎么抽过来的呢?

full和delta

抽取方式有两种:full和delta.
数据量较小的,或者主数据之类的,一般用full.
数据量较大的,我们就只抽取上次抽完后增删过的数据,已经抽取过的就不会再次抽取了,这就是delta,需要完整准确的捕获和加载增量数据。

delta 的方式

delta其实又分为初始化抽取增量抽取。初始化抽取,意思就是抽一次,因为一般ERP先上线,然后BW再上线,BW上线之前的ERP数据,我们从ERP的透明表中来一个初始化抽取:initialization. BW上线之后,ERP里面的增量数据,那我们就增量抽。这个第二次的增量呢,就是基于初始化和第一次的增量来抽取的,以此来保证两个系统数据的同步。

delta的具体实现

现在问题来了,到底内部咋工作的呢。我知道用增量方式,可是咋个机制呢?
要想完整准确的抽到ERP的数据,我需要咋弄呢?
这里有两种方式:pushpull.
push就是用一些专门给BW抽取设置的表,来存放增量数据。ERP系统产生增量数据后,一方面写入ECC自己使用的数据库表,另一方面将这些数据推到这写专门给BW抽取设置的表里。之后BW就从这个表里抽取数据。

pull呢,就是对于增量的数据,没有专门的表来存放,还是放在ERP自己的数据库表中,但是给所有的数据加上timestamp时间戳,并且记录每次抽取完成的时间。这样就利用时间来标识增量数据。BW抽取的时候,是直接从ERP里面拉出来数据。

这里有一点就是push和pull都是在有增量的时候才用的上,对于全量抽取和初始化抽取,都是从ERP自身的数据库表中提取的。

对于logistics,就是LO抽取(包括SD,MM,PP模块)用的是push的方式。
对于financials,用的是pull的方式(FI,CO模块)。

pull的方式呢,就是在ERP里面激活数据源,然后复制到BW中,在BW就直接新建初始化和增量抽取的DTP。就可以完成数据抽取了。

咱这篇也就沿着pull来讲。
LO的push呢,相对复杂一点,要在ERP里面多做一些配置和操作。


讲到这里呢,就有个可能迷糊的点了,因为我们要搞数据源,所以激活数据源的RSA5,查看的RSA6和RSA7的增量队列,其实都是在ERP里面才能看到的。不要搞错了系统。

BW里面只能看到数据来了没有。
哎,以上没图。。。

0827 update:
LO数据源增强 .


ODP、ODQ

好了,现在回来,那这个Operational Delta Queue是代替BW delta queue的。那它到底咋工作的呢?ODP又是咋工作的呢?ODQ在哪儿呢?对于不同增量类型,ODQ又是咋弄的呢?
ODQ 有哪些重要的表? ODQ的滞留期间怎么维护的呢?

ODP的工作原理

Operational Data Provisioning (ODP)是740开始有的。因为730的时候我只记得info package和PSA。ODP提供了一种新的连接ERP到BW系统的方式。更灵活的统一了源系统和目标系统之间的数据传输,这句话啥意思呢。
在sap note 2232584里面有写,通过abap程序‘BS_ANLY_DS_RELEASE_ODP’使得ERP系统中的标准BW extractor 和ODP兼容了。这些extractor不仅在BW里可用,而且在其他的什么Odata,Data Services里面也可以用。
但是我听说如果在BW/4HANA上,只有ODP extractor可用。具体咱不知道。 0827update:是的,BW4HANA以后只有ODP数据源了,如果ERP是S/4hana 那也是自动支持的。如果你是先升级了BW4HANA,但是ECC还是6.0, 那就要装note给ECC让他支持ODP。
来看看ODQMON/ ODP extractors/ operational delta queue_第1张图片

ODQ

下面我们来看看Operational data queue.
ODQ也就是存储原系统的增量数据的。因为有各种extractor,每个提取器有增量更新的,那大家来排排队。而且咱从上面图也能看到,ODP 支持的客户还挺多的,还有Data Services之类的。
来看看ODQMON/ ODP extractors/ operational delta queue_第2张图片
这个ODQ在哪里看呢?就是在上图,在ERP系统的ODQMON这个tcode下面看。
单讲BW,对于BW的一个数据源对应的一个extractor的operational data queue中的一条,其实这个queue是只有一个的,也就对应了ODQ的可复用性,也就是说,你一个queue可以给好多人用。可以有好多个subscription,可以是给BW的,也可以是给BO的,给第三方的等等。(这个queue它里面是有好多表的)
单讲BW里面的subscription。当我们在BW那边复制了数据源,要做初始化抽取,也就是initial的时候,这个initial的DTP就会给我们去找ODQ要数据。为啥它去ODQ要数据呢?因为你没事总不能去ERP直接找底表要吧。人家才不理。
你去找ODQ要,ODQ说好嘞,我去拿哈。对于LO的数据源,extractor去setup表去拿了。(后期就是直接推数据到ODQ里面了)
对于FI的数据源,直接去function module去拿了。拿来了之后,放在了Q里。然后给BW的DTP抽过去。

对于需要增量抽取的,之后会有两个不同的DTP,因为有个initial data(delta initialization) 还有个data changes(delta)。
来看看ODQMON/ ODP extractors/ operational delta queue_第3张图片
在这里插入图片描述

总结一下呢,这个ODQ就是有queue啊,subscription啊,request啊,unit啊,还有具体的数据内容。
queue就是你去拿的数据是什么,是标准提取器,还是CDSview。
然后就是谁要的这个数据,谁是subscriber,是BW呢,还是说是OData啊,还是第三方的谁啊。这个subscription在BW里面就是DTP。它的subcriber类型是SAP Business Warehouse,subscriber是你的BW系统,然后subscription就是DTP。如果说是第三方,BOBJ可能是个job。
在subscription里面,就能看到请求request了。可能能看到不止一个请求。
请求下面就是unit,就是个package。在package里面你就能看到数据了。

然后呢,就是在ODQ里面,你是不能删除package里面的数据的,然后你可以看到后台job拉,重复这个last request拉(如果失败了)。
来看看ODQMON/ ODP extractors/ operational delta queue_第4张图片

下图最左边下角,我们从SAP ERP来的数据,它的ODQ就在ERP系统里。
对于SLT数据也是一样的,如果是ABAP CDS view或者是从HANA数据库来的数据,那就是在BW系统里面看ODQ了。
如果最顶层还有一个BW系统,调用其他BW系统的数据,那么它调用的ODP_BW 数据源的ODQ,是在它底下一层的BW系统里面的。这个下面这个图都很详尽。
但是咱基本也就是从SAP ERP系统来数据,到第一层BW系统结束了。如果上了S/4HANA可以在BW系统看。
来看看ODQMON/ ODP extractors/ operational delta queue_第5张图片

ODQ的 Push/Pull

ODQ是用于啥增量类型的呢?
下面这张图很好的解释了。如果这个ODP extractor的delta type 是’D‘, 每条数据会单条或者成组形式更新到增量队列中。BW需要delta update的时候,增量队列就会被读取,在增量队列中的数据都会被传输到BW系统中。这个是Push,就是说BW还没要你数据的时候,你就已经准备好了到ODQ的表里了。BW要得时候就直接去ODQ的表里取了。LO数据源是Push。
对于delta type ‘E’, extractor自己来提供增量数据(就是我们前面写的pull),然后把数据放到ODQ里面,然后再传输到BW里面。如果你这个extractor在BW那边已经做了初始化增量,那你这个extractor就得存储初始化数据的所有增量记录。并且把它们放到ODQ里面。如果你这个extractor有两个不同的BW目标,那你就得放到对应的ODQ里了,每个ODQ对应不同的目标系统。这个Pull,也就是说它不会自动把数据放到ODQ的表里的。只有说BW说要数据了,它去ODQ要,ODQ说我没有,然后只能去数据源的提取器让它把把数据给到ODQ里面去,然后BW的DTP才能从ODQ里面去取数据。FI/CO数据源是E。

来看看ODQMON/ ODP extractors/ operational delta queue_第6张图片这个增量类型在哪里看?
在这个表ROOSATTR里么?不是的哈。这个表只是说支不支持delta:
来看看ODQMON/ ODP extractors/ operational delta queue_第7张图片
你要在这两个表里面看:
1. ROOSOURCE 看数据源delta process,比如说ABR和AIE。第一个是这个增量处理ABR,after-before-reverse,是啥意思呢?就是说,你这个如果第一条数据值10,然后有增量30,那么它会有一个反转值-10先进去,然后再有30进去。这是这种增量处理方式。你看LO的数据源,基本上是这个增量处理方式。
第二个AIE,after-image-via-extractor,这个是说你第一条是10,当它被改成30了,那就只有30的这条被发过去。这个一般是FI数据源。
来看看ODQMON/ ODP extractors/ operational delta queue_第8张图片
2. RODELTAM

接着在这个表里,去检查,你输入了ABR和AIE后,它会告诉你你的增量类型是啥。D是Push从ODQ拿,E是Pull只能从数据源拿。
来看看ODQMON/ ODP extractors/ operational delta queue_第9张图片
这里面对于数据源呢。我们自己建的数据源,本来我们是建个view,在ERP里面再建一个RSO2的一般数据源。现在呢,行不通了。view就不用了,你要在ERP里面建一个CDSview,然后在BW里面建一个数据源。是基于这个CDS view的。

那么ODQ对应的表是啥呢?
4. ODQDATA_C 这个是所有的压缩的 初始化请求数据
5. ODQDATA_F 这个是所有压缩的 全量请求数据
6. ODQDATA 这个是所有的压缩的 增量请求数据
DTP是从ODQ拿数据的。你复制了数据源之后,第一次跑DTP,那么会执行一个Delta Initialization请求,这时候数据会更新到表ODQDATA_C.
那接下来,就会有增量数据了(咱讲的是个支持增量的数据源)。对于删的,增加的,修改的数据。从上次时间点开始,ODQ就会把这些数据拉过来。这是个增量更新,这些增量数据,会被压缩放在ODQDATA里面。
还有就是Full更新,那就是直接到ODQDATA_F这个表里了。对于Full更新的话,是没有subscription的,只有一个queue。Full就很简单,每次来都说,行了给我数据,反正他要得也少,也没什么更改的需求直接从仓库ODQDATA_F里搬得了。
Delta呢,因为麻烦,还得搞张纸条,写上谁上次要了啥,在啥时间点要的,记上subscription。
因为万一人家要的人回去发现数据不对了,还得回来找他看,啥时候拿的呀,为啥之前更新的没拿上啊?所以就得有这个subscription记录,哦,你是啥时候拿的,如果发现上次拿的不对了,那就再拿一次。ODQ是给delta的保留上次拿的数据的。保留一段时间的。

ODQ 的保留时间

在ODQ里面,数据会有保留时间的。而且如果一个ODQ有很多个subscription,在数据没有被所有的subscription都拿走之前,数据会一直在Q里面。那么在数据被所有的subscription都拿走了之后,还会有一定时间的保留。这个保留时间我们可以调整。在数据被所有subscription拿走后,会有一个标志flag显示是retrieve了或者cancelled。
默认情况下,保留时间是24小时。这是有个reorganization job来执行的,这个job在你建立subscription执行第一次的初始化请求的时候就默认生成了。用来重新规划delta queue。
job的执行和时间间隔呢,咱都可以来改。在这个程序:ODQ_CLEANUP里面改。或者在GOto里面,reorganize delta queue:
来看看ODQMON/ ODP extractors/ operational delta queue_第10张图片
来看看ODQMON/ ODP extractors/ operational delta queue_第11张图片
第一个recovery保留时间是24小时,是在你的后续数据完成抽取,或者取消抽取了之后,有retrieve或者cancelled的flag,过了24小时,它数据就清掉了。左上角有个job你可以看到什么时候这个job跑了。系统默认的时间就是01:23:45这个时间点。这个呢,就是说,万一你的增量请求在24小时内失败了,你可以来重复抽取一下。超过这个时间,被标志成retrieve和cancelled的数据就被删掉了。
第二个Data with low relevance是啥意思?这个是跟第三个相关的,当你有一个初始化请求,一般它是low relevance低相关,那在这个初始化请求一直没有抽取数据,没有被标志成retrieve或者invalid,那这个未抽取的数据只保留10天。
相应的,对于平均相关性,实际上是中等相关,**没有被抽取,没有被标志成retrieve或者invalid,**会保留31天。
这里有个很重要的点,因为你这个subscription是和你的initial DTP关联的,所以,不要随便在BW里面删除DTP啊,如果你删除了你第一个初始化DTP,那么你的subscription就没了啊,那跟随这个subscription建立的job就没了。直到下次有个delta初始化请求的时候,或者有个标准请求(full)的时候才会又默认建这个job。
然后,对于没有被抽取,但是是业务相关的数据不会被这个reorgnization的给删掉。delta queue里面的数据都被认为是业务相关,如果它的数据没有被后续提取,那么不会被删掉。直到说它已经被标志成retrieve或者cancelled才会被删。
对于初始化增量和标准请求,那不是业务相关,而是low relevance,只能有10天。过了10天这个数据没了,那你BW那边的初始化请求,由于没有执行抽取,那也就废掉了。得重新搞初始化抽取。

这篇由于是我反复来写,所以有好多重复和上下文不衔接的地方。0901更新。

DTP会直接从ODQ来拿数据。就没有PSA到info package这一步了。直接到info source。
来看看ODQMON/ ODP extractors/ operational delta queue_第12张图片
你第一次跑DTP的时候,ODQ执行的是一个增量初始化请求,这个请求到数据源哪里,然后填充ODQDATA_C这个表。第一个图就是这个表。这个第一个图是从application表来的。对于LO数据源,是要填充setup表的。从setup表来的。第二次跑DTP,ODQ就执行一个增量更新,把上一次的数据有增加或者修改(包括删除)的记录压缩放到ODQDATA这个表中。

来看看ODQMON/ ODP extractors/ operational delta queue_第13张图片

ODP 抽取验证

之前我们在RSA7看增量队列,在RSA3看数据源的数据。
那现在呢,这个RSA7被ODQMON代替了,那RSA3呢,亲测还能用。
RSA3就是个测试,但是ODP数据源提取的测试可以从程序RODPS_REPL_TEST来。但他俩原理相差挺大的,这个程序就等于像是另一个目标系统。在ODQMON里面会创建一个新的目标源。你测试完了得手动重置,或者结束这些复制测试。否则表ODQDATA就会变很大,对ODQloading的性能有很大影响。一个ODP源使用一个delta queue,然后这个queue会被很多目标源共享。这个delta 数据如果已经被目标源提取了,那delta 数据表就会被清空。结束了测试后,创建的请求会被ODQ的清楚job定期清除。

ODQ滞留时间:
ODQ里面的数据是会保留来供协调和恢复的。但是不同于PSA,PSA是长久保存数据的。但是你也能控制queue里面的数据在传送到目标系统后还能保存多长时间。依据滞留期间设置决定你能否恢复ODQ的之前的数据。默认是24小时。queue里的数据被提取后,会被标志成被提取。

当初始化请求被执行后,这个ODQ的滞留时间就被创建了。如果你想改,那就到ODQ_CLEANUP这个程序下面或者选“Reorganize delta queues”,在ODQMON下面:
来看看ODQMON/ ODP extractors/ operational delta queue_第14张图片
所有的delta queue里面的数据都被认为是business-critical ,所以只有被标志成已被提取,或者是不可用,才会被删除。
对于一个初始化请求,默认设置这个请求是:“Data with low relevance”,也就是被BW抽取10天后从ERP删除,如果ODQ被设置成“Data with average relevance”.那就是1个月后被删除。

ODQ出错处理

有两种情况,一种是在ERP系统出错了:
来看看ODQMON/ ODP extractors/ operational delta queue_第15张图片
那你删不掉这个出错的请求的,你得查看log,看出错原因,然后修复。删了就影响增量,只能修复后重新跑抽取请求。重跑成功后,执行BW端的DTP,来抽取这个queue的数据。
如果在BW那里DTP出错了。那就删掉DTP的那条请求重抽一遍。
可惜了了,现在我的这个问题是,不能直接修复。fail是fail了,但是显示completed。
来看看ODQMON/ ODP extractors/ operational delta queue_第16张图片
来看看ODQMON/ ODP extractors/ operational delta queue_第17张图片
来看看ODQMON/ ODP extractors/ operational delta queue_第18张图片
来看看ODQMON/ ODP extractors/ operational delta queue_第19张图片

ODQ error: internal kernel error/ DDIC_TYPE_INCONSISTENCY

这个问题怎么解决呢?
因为直接再次抽取它抽不了啊。
看ST22给出的解决方案:
运行program RSNTABCONSISTENCY 或者 RSDDCHECK。
来看看ODQMON/ ODP extractors/ operational delta queue_第20张图片
然后呢,
来看看ODQMON/ ODP extractors/ operational delta queue_第21张图片
有个hidden warning,不知道咋回事。
来看看ODQMON/ ODP extractors/ operational delta queue_第22张图片
到这里就看不懂了,执行跨客户端的多态结构检查???
在这里插入图片描述
在这里插入图片描述
来看看ODQMON/ ODP extractors/ operational delta queue_第23张图片
我看别人的解决方法是到SE14里面去activate & adjust database,然后解决。但是我看这个已经是active的状态了啊。
来看看ODQMON/ ODP extractors/ operational delta queue_第24张图片
今天来看又跑起来了。
来看看ODQMON/ ODP extractors/ operational delta queue_第25张图片

你可能感兴趣的:(BW,BW4HANA,深度学习)