前端Query运行时间数据

因为这个任务被催了。大概有两个月了。
不过由于我最近一直在休假，所以还没时间搞。

今天正好大家都休假去了，我也来总结一点点。
关键词：BW statistics/query runtime/统计BW系统中query的重要程度，被使用频率。退役不被使用的query，Top N 被使用的query。

以上关键词便于以后查找。。。

那这篇的重点就在于：用户谁。。使用了哪些query

这个其实之前我师傅教过我，然而今非昔比。他教我那会，我真是刚入门，啥也不懂，他把他的大招聚集优化都告诉我了。
然而时过境迁，这时候聚集都被HANA直接抛弃了。
而且他叫我那会用的是SAP自己的Content。但是我不知道这玩意在我们系统有没有被安装。我今天用的也不是这个方法。

那就假设BI Content没被安装，你从哪里得知谁用了什么query?在特定时间段里，哪些query被用的最多（Top N)？

使用视图or表or BI content

BW系统有一些表和视图。里面是一些统计信息。BW的content也用的这些视图。
你可以用数据库表，也可以用预定义的视图。或者technical content。
BI Content数据源是 0TCT_DSA1 OLAP
cube: 0TCT_CA1（这个写了是个hana optimized infocube， 可能实时读取RSDDSTAT_OLAP的数据，具体我还没来研究）

视图： RSDDSTAT_OLAP
这个视图呢，就是我今天要用的了，源自于表：

RSDDSTATHEADER
RSDDSTATINFO
RSDDSTATEVDATA

看到这个情况你就知道了，那肯定用视图不用表啊。实际上这个view里也包含了所有我们需要用到的跟query运行时间有关的信息了。

打开统计开关

如果你这个实时数据没有，那你要检查一下这个数据是否被收集了。这个在RSDDSTAT里面：

第一步，选中或者筛选你要统计的query。
第二步，选择setting X
第三步，选择replace values，把开关打开。
然后保存。默认default我也不知道是啥，我不懂这个设置的意义。要么就关，要么就开。还有第三种选项我不明白用意。但是好像default也能收集到数据。

视图内容

统计数据有了，那我们来看看这个视图里都有什么信息。

除了最上面的五个看不懂的ID啊type啊。我们比较好用的是圈出来的，谁/什么时候/看的哪个info provider下的query。
然后还有两个标黄的时间，一个是runtime，一个是event runtime。究竟要用哪个时间来统计query运行时间。
这个就要往下来深究了。

首先runtime我们不知道是啥，但是还有个event ID在key里，绝对跟event time有关。
这个Event ID这么重要的么？
到底是什么值呢？

这个值可是相当多。
那我为啥圈出来3010和3100呢。这里我要劈叉了。为了看懂这个Event ID值，我们先来看下view里面的值到底长什么样子。前几个Key值，到底都是啥。
第一个SessionID是一个自动生成的。
第二个StepID也是自动生成的。
第三个HandleID，按序排列。
第四个HandleType,由图可见，跟handleID没什么一对一的关系。具体值有以下这么多。

也可以在表里看：

那我们观察下上上个例子的图，HANDLETYPE是OLAP的时候，对应后面的Info Provider和objectname给了我们query的信息。也只有是OLAP的操作类型才有我们需要的query的信息。
那这里我们可以推论，我们需要的是OLAP类型的HANDELTYPE。(其他类型有一些是打开前端操作工具，输入参数，以及连接数据提供者等等，这些我们不计入query运行时间）

第五个EventID，有很多ID（对应的值在之前的图上），但是咱不懂什么意思。

后面还有steptype:

这些又是什么意思呢？
我们的例子是AOE。这个就是你用啥工具看的报表。
AOE是用的Analysis for Office.
AOP Analysis Office Powerpoint

在这个表里也有：RSDDSTATSTEPTP

在例子中我圈出来几个时间，分别是UTIME和CALDAY，还有最后一列的STARTTIME。
这个时间就不用看了。就是分割了最后的开始时间。

那到这里，还有一个重要的时间。RUNTIME，都是一样的。
那他这个是啥？看右边的EVTIME，原来是EVTIME的总计时间。

如果我们只计算query的运行时间，那么这个runtime 399秒，就是完全无效的。我们需要先设定操作类型是OLAP类型下的。然后对应找EventID的对应Evtime才对。

那这个runtime就被我们舍弃了。

到此一片混乱后。
我们得出了结论：
我们需要的是Handle type是OLAP的event ID对应的event time。
那么OLAP下选哪些event ID呢？都要么？

我们知道event 3100(OLAP: Read Data)
event 3010(OLAP: Generate Query)
这两个显然跟处理query绝对有关，读取和生成query。

那也就是说，一般情况下，我来执行query,都会有两条event记录，分别是读取和生成。
不一般情况下，可能会有很多读取，一个生成。那么这个时候，只能把生成3010当作计算query执行与否的统计值。

好了，到这里我们再来细分例子。
如果我只要看用户看query的记录。
这里假设用户只能通过Analysis for Office的方式查看query.
由于Analysis里面基本都是workbook，一个workbook可以包含很多个query.
我们来看看steptype定义为AOE的时候，都有哪些event。

这里就能看到了，通过AOE的方式，这个用户在某时间查看了一张workbook，这张workbook里有两个query.所有的event。

思路到这里就理清了。
我需要所有OLAP(HANDELTYPE）的处理方式下，用AOE（STEPTYPE）工具查看报表的。
我需要知道是谁（UNAME），在什么时间（CALDAY）查看的，用时（EVTIME）多少。

*** 到这里又会进行到下一个疑问：
eventtime我们知道是用来计量query的时间的了。
可是这个event time还有其他相关的event count和eventIDcount 呢，那么这个event time是单个event id的时间么？
还是总体的时间啊？
首先要有eventcount和eventid count都是啥的概念。

说实话，看了解释也看不懂。
我只知道event id对应的eventID count是说这个event id被出发了多少次。
那我还是不知道eventtime是单个event ID的触发时间，还是总体的时间。

我们结合一个例子来看：
在10点02这个时间点，runtime总体是15709秒，用于12500这个event的时间是15704。这是他打开程序出错了。就是他这个AFO一直没打开。这个非报表运行时间我们给他排除。

那就还剩5秒的余量。
我不用计算了，正好是把所有evtime加起来的时间。

因为如果evtime是单个的，还要乘eventID count,那么远远不止5秒了。

为了严谨，我还是算了下。
确实这样的。
所有eventtime加起来由于四舍五入是15710.69

***得出结论，eventtime是汇总了以后的值。

这里把runtime讲一下，我这会才看到runtime的解释（validity period) 哎，有时候不懂英文很难搞啊

它是duration of a step in seconds.
summation of time taken by read event and query generate event gives the total execution time of Bex Query.

后面这句解释容易造成误解啊，我觉得这个就是一个step的需要时间。但是这个step它如果是用AFO打开，那还得包含打开工具的时间啊。

所以，一切都得具体情况具体分析。

STATLEVEL这个是detail level of OLAP statistics recording
0 代表aggregated data
1 代表OLAP data
2 代表OLAP and DM data

有一点要说的是，这个统计信息都是延时的。接近实时

设计query

在condition条件里设置，基于event: query generation 的次数来排序top 10的query.


再以query生成次数计算平均query用时。