SAP abap与数据库

以下为个人在平常中整理出来的，abap与数据之间的关系，有新认识之后，再继续补充。

2013/11/05:

1.sap 数据库表的主索引是：数据库表的主键，他的好处是可以提升读取数据库表的速度，但是会增加更新数据库表的时间。特别在创建次级索引的时候，一定要使用经常使用的字段进行设置。

 

2.sap中常用数据库类型：透明表（transparent table），共享表（pooled table），簇表（cluster table）。

透明表是和DB层的physical table相对应的表，而后两者是不对应到DB表的；然后多个簇表（cluster table）或者共享表（pooled table），组成一个table cluster或者table pool，tablecluster和table pool是物理层的DB.

注：簇表是逻辑上关联的几个表，在定义的时候分配给一个表簇、比如BSEG.

 

3.更新模式（DB和BDC）

   3-1.异步模式

          在这个模式下，DIALOG程序和UPDATE程序各自运行。DIALOG程序写请求到LOG TABLE，用一个COMMIT WORK来关闭LUW。UPDATE程序被COMMIT触发并开始运行来处理这些请求，DIALOG程序继续运行，不会等待UPDATE程序结束。UPDATE程序在特殊的UPDATE WORK PROCESS中运行。

          当数据库更新花费比较长的时间，用户DIALOG需要较少的响应时间，异步更新显得比较重要。在DIALOG处理中，异步更新是标准的技术，意思就是DIALOG程序一般会采取异步更新方式。

可以用VBLOG这个簇表来实现LOG TABLE，或者用透明表VBHDR,VBMOD,VBDATA,VBERROR来替代它。

 

   3-2.同步模式

          可以用COMMIT WORK AND WAIT语句来触发一个同步更新，DIALOG程序要等待UPDATE程序结束再进行下一步的处理。

          如果后续处理或者DIALOG程序的结束需要依靠更新的结果，这个时候要用同步模式。可以用SY-SUBRC来检查同步更新的执行情况，在程序等待UPDATE程序执行的过程中，DIALOG程序的DIALOG WORK PROCESS被释放，当更新结束之后，系统重新为DIALOG程序分配一个新的空闲的DIALOG WORK PROCESS做下一步的处理。

 

   3-3.本地模式

          使用SET UPDATE TASK LOCAL语句来使用UPDATE MODULE在本地执行，同样的用COMMIT WORK来关闭SAP LUW，更新会在同一个DIALOG WORK PROCESS中进行，DIALOG程序等待更新完成（同步）。当LOCAL UPDATE完成之后，会提交一个显示的DB COMMIT，DIALOG程序也得以继续执行。

 

          如果更新执行有错误，并且其中一个UPDATE MODULE发出一个终止程序的MESSAGE，系统会执行一个自动的DB ROLLBACK来丢弃这个SAP LUW所有的改变，并且DIALOG程序会终止，并弹出一个程序终止信息。

          LOCAL UPDATE模式中，更新请求不会写到VBLOG表中，而是在MAIN MEMORY中，因为没有IO的访问，其速度要比同步和异步模式的快一点。LOCAL UPDATE只适合批量模式。

          SET UPDATE TASK LOCAL工作到遇到COMMIT WORK语句，意思就是COMMIT WORK执行之后，SET UPDATE TASK LOCAL不再有效。

 

4.UPDATE MODULE的类型（V1&V2）

简单而言，V1的更新类型比V2的级别要高， 因此V1比V2要先执行，同时V1包含同步，异步，本地的更新方式，V2只能执行异步更新。

 

FUNCTION MODULE的processing type有三种，NORMAL FUCNTION MODULE,REMOTE-CAPABLE MODULE和UPDATE MODULE。每种下面又包含4种分类，立即启动，立即启动（不可重启），延迟启动，collective run.前2种属于V1类型，后两种属于V2类型。

 

UPDATE MODULE的类型决定了其处理的模式。所有的DIALOG程序里的V1请求都会在单独的DB LUW里执行。只有当V1执行成功之后才会处理V2请求，V2也会在单独的LUWS里执行。

 

V2类型的UPDATE MODULE处理的DB CHANGES一般都是紧接着V1的CHANGES（MAIN CHANGES）之后进行的。

 

V1类型的UPDATE MODULE分可重新启动或不可重新启动的两种。V2类型的当发生错误的时候总是可以重新启动，再次处理。

 

V2类型的COLLECTIVE RUN是SAP内部使用。相应的V2请求并不是在V1执行之后直接执行，而仅仅是在程序RSM13005被调用之后才执行。

 

V1请求都是由V1类型的UPDATE MODULE来创建的，对于同步异步模式来说，V1类型的UPDATE MODULE都会把请求创建到VBLOG这个TABLE，对于本地更新模式来说，V1请求是在MAIN MEMORY中创建的。V2类型的请求总是创建到VBLOG表中。

 

V1请求都会在一个V1类型的UPDATE WORK PROCESS（UPD）作为一个单独的DB LUW来处理。如果V1更新成功，系统会删除V1的请求和所有在V1更新任务上的锁，并设置一个DB COMMIT，然后触发V2更新。

 

V2请求也是在一个V2类型的UPDATE WORK PROCESS（UPD2）作为一个单独的DB LUW来处理。如果SAP系统没有设置V2类型的UPDATE WORK PROCESS，则V2请求会在一个V1类型的UPDATE WORK PROCESS里进行处理。如果V2请求处理成功，将会从VBLOG删除相关的请求，并设置一个DB COMMIT。V2请求一般都会运行在没有锁的情况下，因为这些锁在V1完成之后就被删除掉了。因此，V2更新总是运行在没有SAP LOCKS的情况下。

 

如果V1 UPDATE MODULE用一个终止消息终止了V1更新，那么V1更新任务上的锁讲被删除，数据库将ROLLBACK，一个E-MAIL会发送给创建这个LUW的用户，并且V1请求在VBLOG表中被标记为不正确。V2更新也就不会被触发。

 

当然如果V2 UPDATE MODULE终止了V2更新，同样的，数据库ROLLBACK，属于这个SAP LUW的V2更新都不会执行，V2请求在VBLOG表中被标记为不正确。

 

DIALOG程序用_SCOPE = 2创建的锁会被传递到V1更新任务中，在V1更新的结束，不管V1更新是否成功或者终止，都会把这些锁自动删除。因此，在DIALOG程序中不能显式的删除这些锁（太早），或者在UPDATE MODULE里删除（没必要）。