1. 后台进程和Job
要知道SAP是个三层架构。
在中间层的application layer上,是个application server。
那么这个server上可以有很多个instance。
每个instance上可以设置很多个work process,工作进程。
这些工作进程是处理进入到application instance的task的。
啥task呢?
可能是一个交易的保存,一个前端对话任务,或者是一个后台处理任务。
1.1 instance
如果你要加一个instance:
进去可以看到现有的instance,和operation mode。点击新建可以新加新的instance。
然后在Host Name里添加server,还要加system number。
如果是直接进来的可以点击新建operation mode。这个就是basis做的了。
你要改operation mode就可以点击下面的other operation mode 改了operation mode和下面的工作进程分配。
根据时间来转换operation mode的不属于咱工作范围,就不说了。
1.2 work process
工作进程分为很多种,这些分类是根据需要处理的任务来预先设置的。
那么任务有哪些类型呢?
- Dialog 对话框任务,对应DIA工作进程
- Background后台批处理任务,对应BTC工作进程
- Update 非同步的数据库更新任务,对应UPD,对时间要求较高
- Updatev2 对时间要求不那么敏感,也是更新任务,主要更新统计数据,优先级没有UPD高
- 执行锁和释放锁(数据库表锁)任务,对应ENQ
- Spool 执行打印任务,对应SPO
这么多的工作进程是谁来负责分发呢?
在这个application server上有一个dispatcher,他根据任务类型和每个工作进程的工作量来分发工作进程。
那么这时候就要考虑到你的系统是否需要多个instance了。同时还得决定你的instance里面的任务类型和工作进程数量。
如果你很豪,就可以一个instance用来搞DIA任务,另一个用来搞BTC任务。
但是一般BW上面一个开发系统就只有一个instance,那么这个时候,也许就是白天DIA任务多,晚上BTC任务多。那么可以用operation mode来切换白天和晚上不同的任务模式。简单来说就是这个operation mode给你按时间来划分,然后在每个时间段里安排不同的工作进程类型和数量。
至于工作进程的总量一般是固定的。你只能通过重启application server来改变。
1.3 后台进程监控SM50、SM51、SM66
知道了后台进程一共多少个,就能来看了。
SM50:当前instance的后台进程情况
SM51:当前application server上所有instance的进程情况
SM66:全域工作流程概览
AL08: 当前系统用户
1.4 Job
后台操作,或者说后台进程,又或者说批处理操作是后台自动进行的,不要你再手动触发的。
在BW里面,DTP会激发后台job。处理链就是典型的后台job。
后台job是后台进程的工作单位。每个后台job会有好几个job steps。
step可以是ABAP程序,外部命令或者是程序。
而触发一个后台job的可以是event,也可以是定义的时间。
当我们去看一个job,会发现job有很多状态:
scheduled:就是已经设置好step,但是还没有开始条件。
released:已经发布的,那就必须得是有了开始条件的才能发布。
ready:就是说已经发布的job满足开始条件了。job Scheduler已经把这个job放到wait queue里面去了。等待一个free的工作进程。
active:job已经正在进行了,那么也不是说不能停。可以cancel掉。
finished:job的所有steps都已经完成了。
canceled:要么是被sm37进去的给cancel掉了,要么是steps里面有错被终止掉了。
job log里面可以看运行的job状态。如果有ABAP program的运行结果,可以在spool list里面看。
具体的job怎么设置在这里看:
link.
后台job在release之后就会在等待后台进程了。到了job的开始时间就会从进程开始执行了。
那么active的job呢,你就可以看看后台进程在执行的了。
写了这么多呢,我主要就是想说。DTP执行的时候,会有个后台job。那么这个后台job会去调用后台进程。
怎么看呢?
后台SM37去看所有active的job。
然后对应去看sm50的BTC的进程。
双击进进程,就能看见call它的background job了。
到此为止,所有的铺垫结束了,接下来回到正题了。
2. DTP处理模式
一个标准的DTP请求,一般能用并行处理方式就用并行处理方式。那么这个处理模式分别有啥,又分别是什么意思呢?
首先要知道DTP请求是按一个个请求来的,一个请求里有请求号,包号,记录号。
咱都知道请求号就是你啥时候开始的这个请求的一个标记号。
包号就是这个请求去请求数据的时候按照你设定的包的大小,把数据分成了多少个包来。
那么记录号呢,就是包里面的记录了。也就是你包的大小了。但是记录号不一定是你设定的包的大小。比如上面是包的大小为5万,但是不是说每个包就会固定死了是5万条数据。
那么处理模式实际上是你抽取,转换和传输到target的顺序。什么时候分离同步处理。
比如说有一种情况是delta抽取不需要测试数据,只需要给源标记成已经delta抽取过了。那么这个抽取模式就会让请求给源标志成已抽取,但是不会真正把数据抽取到target。(啥情况呢,就是你这个target已经被初始化过了,但是需要重构这个初始化请求,就用这个。)
一般情况下抽取都是同步抽取。如果你的记录必须是得按顺序来的,另一条基于前一条已抽取的情况的,那你用顺序抽取。
或者是要debug的时候,会选成顺序抽取。
以上讲了一大堆废话,再回到处理模式。
并行处理模式:也就是只要你记录不是说对顺序有要求的,那你就用并行抽取和处理不同包。
当你选了并行处理。
系统就会把多个包进行同步处理。
这种时候还可以怎么进行性能优化呢?
如果你此刻去执行这个DTP,那么后台会生成一个Job。
这个Job会占用一个后台进程。
然后这个进程就去跑你的数据请求。但是如果你的数据量特别大。那么这个进程可能会跑很久很久。
你此时去SM50看后台进程,也许有很多个空的进程。那它们空着也是空着,为什么不拿过来用呢?
两个进程一起用,你数据抽取的时间能减半。
这时候,在DTP的Runtime Properties里面把后台进程分配给这个DTP多一点。那你的抽数时间将会大大减少。
一般你调用的进程数不要超过空余进程数的一半,这种对于一次性大量数据抽取很有用。
你还可以设置这些后台进程在哪个server上面跑,job等级是啥。
根据我的实际经验,好像一开始是一个job,然后会分割成你设置的数量。这些后台进程数可以在这个表里看到: