来看看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。

传统增量队列

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

full和delta

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

delta 的方式

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

delta的具体实现

现在问题来了，到底内部咋工作的呢。我知道用增量方式，可是咋个机制呢？
要想完整准确的抽到ERP的数据，我需要咋弄呢?
这里有两种方式：push和pull.
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:是的，BW４HANA以后只有ODP数据源了，如果ERP是S/4hana 那也是自动支持的。如果你是先升级了BW4HANA，但是ECC还是6.0， 那就要装note给ECC让他支持ODP。

ODQ

下面我们来看看Operational data queue.
ODQ也就是存储原系统的增量数据的。因为有各种extractor，每个提取器有增量更新的，那大家来排排队。而且咱从上面图也能看到，ODP 支持的客户还挺多的，还有Data Services之类的。

这个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)。

总结一下呢，这个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拉（如果失败了）。

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

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。

这个增量类型在哪里看？
在这个表ROOSATTR里么？不是的哈。这个表只是说支不支持delta：

你要在这两个表里面看：
1. ROOSOURCE 看数据源delta process，比如说ABR和AIE。第一个是这个增量处理ABR，after-before-reverse，是啥意思呢？就是说，你这个如果第一条数据值10，然后有增量30，那么它会有一个反转值-10先进去，然后再有30进去。这是这种增量处理方式。你看LO的数据源，基本上是这个增量处理方式。
第二个AIE，after-image-via-extractor，这个是说你第一条是10，当它被改成30了，那就只有30的这条被发过去。这个一般是FI数据源。

2. RODELTAM
接着在这个表里，去检查，你输入了ABR和AIE后，它会告诉你你的增量类型是啥。D是Push从ODQ拿，E是Pull只能从数据源拿。

这里面对于数据源呢。我们自己建的数据源，本来我们是建个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：


第一个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。

你第一次跑DTP的时候，ODQ执行的是一个增量初始化请求，这个请求到数据源哪里，然后填充ODQDATA＿Ｃ这个表。第一个图就是这个表。这个第一个图是从application表来的。对于LO数据源，是要填充setup表的。从setup表来的。第二次跑DTP，ODQ就执行一个增量更新，把上一次的数据有增加或者修改（包括删除）的记录压缩放到ODQDATA这个表中。

ODP 抽取验证

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

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

当初始化请求被执行后，这个ODQ的滞留时间就被创建了。如果你想改，那就到ODQ＿CLEANUP这个程序下面或者选“Reorganize delta queues”，在ODQMON下面：

所有的delta queue里面的数据都被认为是business-critical ，所以只有被标志成已被提取，或者是不可用，才会被删除。
对于一个初始化请求，默认设置这个请求是：“Data with low relevance”，也就是被BW抽取１０天后从ERP删除，如果ODQ被设置成“Data with average relevance”.那就是１个月后被删除。

ODQ出错处理

有两种情况，一种是在ERP系统出错了：

那你删不掉这个出错的请求的，你得查看ｌｏｇ，看出错原因，然后修复。删了就影响增量，只能修复后重新跑抽取请求。重跑成功后，执行BW端的DTP，来抽取这个queue的数据。
如果在BW那里DTP出错了。那就删掉DTP的那条请求重抽一遍。
可惜了了，现在我的这个问题是，不能直接修复。fail是fail了，但是显示completed。

ODQ error: internal kernel error/ DDIC_TYPE_INCONSISTENCY

这个问题怎么解决呢？
因为直接再次抽取它抽不了啊。
看ST22给出的解决方案：
运行program RSNTABCONSISTENCY 或者 RSDDCHECK。

然后呢，

有个hidden warning，不知道咋回事。

到这里就看不懂了，执行跨客户端的多态结构检查？？？



我看别人的解决方法是到SE14里面去activate & adjust database，然后解决。但是我看这个已经是active的状态了啊。

今天来看又跑起来了。