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，然后会分割成你设置的数量。这些后台进程数可以在这个表里看到：
