一：Workload analysis介绍：
首先,sap有个图非常有意思，字面意识是说系统瓶颈可能造成程序长期运行，而程序长期运行可能凸现系统瓶颈。
我觉得对这个的图解，侧面告戒我们不应该过于狭隘的进行性能或者负载分析，因为性能分析往往是多个因素相关联的，比方说内存问题也可引起cpu和io的高负载。同时也对性能分析提了个醒，我们需要对影响性能的因素有较全面的了解，在此基础上可按照多种方案进行全面而细致的具体分析，才不至于在实际的性能问题上南辕北辙。
系统瓶颈可以以硬件和配置两个角度划分：硬件瓶颈主要是cpu,内存，I/O和网络，就目前技术而言，I/O是瓶颈之首。配置而言，主要是内存参数配置，当然如果推广开来，还可以考虑数据库规划的配置，操作系统文件系统规划配置等等。
长期运行的程序，主要是未经优化的程序(程序算法，SQL性能问题)，当然程序也存在不必要功能可能性。
因此，我们也可以理解性能问题大致可以划分为一般性的系统问题和个别的程序问题，在这上面英文有多种说法bc315上的说法是，basis tunning & application tunning。
basis tunning的范畴，系统参数，数据库硬盘i/o规划，workload distribution的优化，硬件瓶颈
sap application tunning的范畴，Sap notes/patch,sap customizing, abap程序代码优化，index优化，sap表缓存。
注意sap表缓存和sap内存的区分。一般而言，sap内存包含了sap表缓存，还包含了sap的roll,heap,extened,paging内存。在特定环境下，sap内存，仅仅指roll,heap,extended,paging这些内存区域。另外就是sap缓存包含表缓存，还包含nametab,program缓存(参看st02)。就缓存而言，个人还是认为更应该划分在basis tunning范畴，就表缓存而言。当然划分为application tunning更好。
sap的dialog step中的各种类型的时间计算。个人认为这对于性能分析具有非常重要的现实意义。因为就大多数性能问题而言，往往可行的方案都是从个案分析开始的。而且我们遇到的绝大多数问题，都要针对个案的。
当一个用户请求被递交给服务器，实质上是递交一个用户目前登陆的dispather, dispather首先是将该请求放入其在内存中的队列表中，让dispather找到一个合适的空闲进程，才把该请求从等待队列中读取出来并分配给空闲进程。用户请求在dispather的队列的时间，叫做wait time。
在将用户请求分配给对话进程的时候，需要将共享roll区域的user context拷贝或者映射到对话进程。这个拷贝和映射的时间，就是roll-in time。
当需要从数据库获取数据，则请求被递交给数据库接口，数据库接口程序首先在sap缓存中寻找，如果sap缓存不能满足需求，则将向数据库请求，在数据库层面，当然也是先从数据库的缓存，必要才从数据文件获取(就查询而言)。最后数据被回到sap数据库接口然后是用户的进程。从提交请求给数据库接口到数据库接口返回结果给进程的这段时间，叫做Database time。APO系统使用的livecache技术，需要明确的一点是，访问livecache也是通过数据库接口的(仅供参考，不是特别确定-_-!)。
当用户事务在进程中运行完毕时，dispather将结果反馈给前端。从用户提交请求给dispather queue开始到用户得到dispather的响应(返回到屏幕)这段时间，叫做response time.
当用户的事务在进程中被运行完毕后，user context被拷贝回roll buffer的过程，叫做roll-out,roll-out过程耗用的时间，叫做roll-out time.
在该过程中被包含和需要细分的时间种类:
CPU time是该进程占用的cpu时间，(既该进程运行该事务分配到的所有cpu时间片的总和).
Load time就是从数据库装载abap程序，cua,屏幕所耗用的时间。
Processing time是response time扣除wait time,database time,load time,roll time和enqueue time的和的其他部分。
(所以processing time和cpu time对比是一个很重要的参数，根据sap的标准，如果processing time大于2倍cpu time，说明进程有过多的等待，往往可以说明存在cpu瓶颈)
在明白这些统计时间的基础上，就可以根据以上信息进行初步的性能问题分析了。
bc315上面良好的性能指标大概如下:
就整体而言：
Main menu(transaction profile)<100ms，就是说在sap标准菜单中的操作相应时间小于100ms
wait time<10%response time，比较小的wait time，说明dispather工作正常，能够及时响应，因此系统整体性能应该良好。
有一个经验性的参数，就是平均response time在1秒以下，代表着系统有良好的性能，但是需要个例对待。
此外还有以下参数:
平均roll-in time<20ms
平均roll-wait time<200ms
平均load(and generation) time<10% response time(50ms)
平均database request time<40% of(response time-wait time)
平均cpu time和processing time相当。
large roll-wait time代表着sap应用服务器同GUI或者外部系统的连接有性能问题。
large load time 一般是对应的program,cua或者screen缓存偏小
large database time则对应着数据库性能问题(database cpu/memory bottleneck, network work problem,index,buffer,statistics等)，也可能是expensive sql statement.
large cpu time 可能是abap程序性能问题
processing time远大于cpu time往往代表cpu瓶颈，网络问题
有了以上基础，就可以开始进行性能问题的初步分析了。
二：性能监控：
常用的性能监控和分析工具
workload analysis监控和分析：ST03N,ST03
work process监控和分析: SM50,SM66
操作系统性能监控：ST06,OS07
数据库性能监控：ST04 or ST04OLD
SAP内存监控：ST02
sap工作进程监控SM50/SM66
使用SM50我们可以监控到当前登陆的实例的工作进程，可以查询到状态，PID，正在运行的程序，正在访问的表及动作，如果正在执行某个sql语句，也可以在details里面看到sql语句，还可以查看到比如信号等等的信息。同时，我们可以在sm50里面跳转到对应进程的trace 日志文件进行更细节的查看，当然我们也可以手动更改相应进程的跟踪级别。这些功能，无论是对于系统整体性能还是特定程序的性能问题实时分析都很有帮助。而且SM50还可以中止进程或者终止程序。
典型的比如running状态下direct read，load program, rool in/out等动作，可以分别对应到数据库，sap buffer,sap memory问题，典型的stopped状态下的PRIV,CPICreason往往对应sap memory,communication问题。
需要注意的是，当用户登陆到sap之后，只会在一个instance上而不会被系统自动分配到别的instance上。因此，sm50仅仅能察看我们当前登陆系统的进程。所以我们有SM51和SM66来实现SM50不能实现的功能。
操作系统监控ST06/OS07
这个工具对于操作系统整体性能初步分析非常有用。我们可以用来监控CPU负载(syste,user,idle的比率，平均等待进程数/cpu)，还可以监控物理内存的可用情况以及page in or out情况，也能用来察看简单的硬盘，网络信息。
通过点击应用程序工具栏的detail analysis menu按钮，我们可以进行更细致的分析，比如察看cpu的历史记录，查看当前最耗cpu的进程(top cpu)，用系统工具去调用ping命令来测试前端与应用服务器，应用服务器和数据库的网络情况。也能和其他实例对比，还可以查看最近被变动的参数(当某些变动导致性能问题是比较有效)
SAP tunning summery 监控ST02
如果sap存在buffer问题或者内存参数配置问题，st02会是一个非常有用的监控和分析工具，而且能够帮助我们找到相应的实例参数。
一般而言，就sap buffer，不应当有太多的swap情况出现，但是program buffer,cua,single record buffer要例外一些。特别是program buffer.
就buffer而言，我们需要一段warm up的时间才能作为判断，其中的hit ratio是一个重要指标，buffer的命中率越高自然代表着越大比率的数据直接从buffer中获取，自然也就越能起到buffer改善i/o性能的作用。
就buffer而言，如果是多instance,采用load balancing会是更有效地解决方法。当然如果米够多，内存够大。。。
相关的参数，在st02的应用程序工具栏可以直接点击current paramter获取。
三：SAP内存管理：
SAP内存区域
Shared Memory: SAP Buffer (Program, Screen, Data Dictionary), Extended Memory, Roll Buffer, Paging Buffer
Local Memory: Local Roll, Local Page, Heap Memory
Roll Area(属于local memory), 主要存储user context,比如程序指针，set/get parameters,权限，内表，报表。
Paging Area(属于local memory)，主要存储程序相关数据。比方说extract,Import and Export，call transction之类。
Roll Buffer和Paging Buffer则是对应Roll area,paging area得shared memory 部分，roll-in过程表示从roll/paging buffer(shared memory)拷贝user context道roll/paging Area(local memory),roll-out恰好相反。
Roll file和Paging file则是对应Roll buffer和Paging buffer得文件部分(on disk)，当Roll buffer和paing buffer不足，则会存储与Roll file和Paging file.
Extended Memory(属于Shared Memory),存储同Roll area得数据，不过用户进程访问extended memory不同于roll area得拷贝，而是映射.
Extended Memory采用映射方式的好处在于：使用指针访问成本更低，速度更快，能够更有效的利用内存，降低cpu和硬盘的负载。当然，extended memory需要足够的物理内存来支持，因为它设计的初衷是理应只存在于物理内存。
内存分配顺序
sap得内存都是通过instance profile参数来设置的，所以下面简单介绍相关内存参数(st02 SAP memory部分的内存参数,这里都以unix平台为基准，windows平台则是采用零内存管理，在内存参数上有着差异)。
Profile parameter
ztta/roll_area
Comment
Roll area per workprocess (total)
ztta/roll_first
First amount of roll area used in a dialog WP
ztta/short_area
Short area per workprocess
rdisp/ROLL_SHM
Part of roll file in shared memory
rdisp/PG_SHM
Part of paging file in shared memory
rdisp/PG_LOCAL
Paging buffer per workprocess
em/initial_size_MB
Initial size of extended memory
em/blocksize_KB
Size of one extended memory block
em/address_space_MB
Address space reserved for ext. mem. (NT only)
ztta/roll_extension
Max. extended mem. per session (external mode)
abap/heap_area_dia
Max. heap memory for dialog workprocesses
abap/heap_area_nondia
Max. heap memory for non-dialog workprocesses
abap/heap_area_total
Max. usable heap memory
abap/heaplimit
Workprocess restart limit of heap memory
Roll buffer由rdisp/ROLL_SHM设置， Roll file由rdisp/ROLL_MAXFS减去rdisp/ROLL_SHM决定，单位8Byte。
Paging Buffer由rdisp/PG_SHM
设置，Paging file由rdisp/PG_MAXFS减去rdisp/PG_SHM决定，单位8Byte。
Roll Area分为Roll first和一般性的Roll Area.前者由ztta/roll_first 决定，一般值为1，具体值根据basis版本不同而略有差异；后者由ztta/roll_area决定。这两个区域都属于进程的local内存，都是在进程初始化时候就分配了相应的内存空间，但是ztta/roll_area部分并不是最初就被使用(对于win零内存管理机制，这个参数无效，而是使用em/address_space_MB)。
Extended memory属于shared memory部分由em/initial_size_MB来限定了其大小，这个应该是在sap instance初始化(不太确定，比方说windows的内存管理机制同unix是不同的,应该是由em/max_size_MB限制)是就分配的共享内存；ztta/roll_extension则是对每个进程所能访问em/initial_size_MB得最大配额。
sap一个实例所有进程得local heap得和的最大值由abap/heap_area_total来限制。abap/heap_area_dia和abap/heap_area_nondia则分别对dia和btc类型的进程所能分配的heap内存的最大值进行了限定。abap/heaplimit对于unix系统来说比较有意义，因为这代表着，如果一个进程使用的heap内存超过了这个值，那么该进程在运行完当前的程序之后，会被重新启动以释放之前申请的heap memory。
注意：extended memroy和heap memory都有一个总量的限制，即既有单个进程限制，也有总和限制。roll area是预先固定分配的。就unix平台，extended memory总量是固定和预分配的。就win平台而言，是自动管理并可按需自动增加到em/max_size_MB(不是很确定其细节）。
对dialog进程而言，不同类型操作系统平台下进程内存分配顺序是一致的。
即ztta/roll_first->ztta/roll_extension->ztta/roll_area->abap/heap_area_dia
对于dialog进程而言，有一个特殊的状态叫做PRIV mode，这一状态代表着dialog进程开始使用heap memory，priv mode这一个状态同时也标志着该进程被该session独占。
对于nog dialog进程，win和unix系统的内存分配方式略有差异。
非win平台 ztta/roll_area->abap/heap_area_nondia->ztta/roll_extension
win平台 ztta/roll_first->ztta/roll_extension->ztta/roll area->abap/heap_area_nondia
思考，根据进程类型，操作系统平台不同，那么内存耗尽的dump的类型是否会跟最后分配的内存类型相关？
小结：对于sap的内存参数管理，需要分unix和win nt与linux平台，然后才能选择合适的内存参数。关键是理解了不同类型的内存管理机制。
四硬件能力评价：暂略过
五耗资源SQL语句：
六 SAP表缓存：
七接口监控：
更多关于SAP的文章
首先,sap有个图非常有意思，字面意识是说系统瓶颈可能造成程序长期运行，而程序长期运行可能凸现系统瓶颈。
我觉得对这个的图解，侧面告戒我们不应该过于狭隘的进行性能或者负载分析，因为性能分析往往是多个因素相关联的，比方说内存问题也可引起cpu和io的高负载。同时也对性能分析提了个醒，我们需要对影响性能的因素有较全面的了解，在此基础上可按照多种方案进行全面而细致的具体分析，才不至于在实际的性能问题上南辕北辙。
系统瓶颈可以以硬件和配置两个角度划分：硬件瓶颈主要是cpu,内存，I/O和网络，就目前技术而言，I/O是瓶颈之首。配置而言，主要是内存参数配置，当然如果推广开来，还可以考虑数据库规划的配置，操作系统文件系统规划配置等等。
长期运行的程序，主要是未经优化的程序(程序算法，SQL性能问题)，当然程序也存在不必要功能可能性。
因此，我们也可以理解性能问题大致可以划分为一般性的系统问题和个别的程序问题，在这上面英文有多种说法bc315上的说法是，basis tunning & application tunning。
basis tunning的范畴，系统参数，数据库硬盘i/o规划，workload distribution的优化，硬件瓶颈
sap application tunning的范畴，Sap notes/patch,sap customizing, abap程序代码优化，index优化，sap表缓存。
注意sap表缓存和sap内存的区分。一般而言，sap内存包含了sap表缓存，还包含了sap的roll,heap,extened,paging内存。在特定环境下，sap内存，仅仅指roll,heap,extended,paging这些内存区域。另外就是sap缓存包含表缓存，还包含nametab,program缓存(参看st02)。就缓存而言，个人还是认为更应该划分在basis tunning范畴，就表缓存而言。当然划分为application tunning更好。
sap的dialog step中的各种类型的时间计算。个人认为这对于性能分析具有非常重要的现实意义。因为就大多数性能问题而言，往往可行的方案都是从个案分析开始的。而且我们遇到的绝大多数问题，都要针对个案的。
当一个用户请求被递交给服务器，实质上是递交一个用户目前登陆的dispather, dispather首先是将该请求放入其在内存中的队列表中，让dispather找到一个合适的空闲进程，才把该请求从等待队列中读取出来并分配给空闲进程。用户请求在dispather的队列的时间，叫做wait time。
在将用户请求分配给对话进程的时候，需要将共享roll区域的user context拷贝或者映射到对话进程。这个拷贝和映射的时间，就是roll-in time。
当需要从数据库获取数据，则请求被递交给数据库接口，数据库接口程序首先在sap缓存中寻找，如果sap缓存不能满足需求，则将向数据库请求，在数据库层面，当然也是先从数据库的缓存，必要才从数据文件获取(就查询而言)。最后数据被回到sap数据库接口然后是用户的进程。从提交请求给数据库接口到数据库接口返回结果给进程的这段时间，叫做Database time。APO系统使用的livecache技术，需要明确的一点是，访问livecache也是通过数据库接口的(仅供参考，不是特别确定-_-!)。
当用户事务在进程中运行完毕时，dispather将结果反馈给前端。从用户提交请求给dispather queue开始到用户得到dispather的响应(返回到屏幕)这段时间，叫做response time.
当用户的事务在进程中被运行完毕后，user context被拷贝回roll buffer的过程，叫做roll-out,roll-out过程耗用的时间，叫做roll-out time.
在该过程中被包含和需要细分的时间种类:
CPU time是该进程占用的cpu时间，(既该进程运行该事务分配到的所有cpu时间片的总和).
Load time就是从数据库装载abap程序，cua,屏幕所耗用的时间。
Processing time是response time扣除wait time,database time,load time,roll time和enqueue time的和的其他部分。
(所以processing time和cpu time对比是一个很重要的参数，根据sap的标准，如果processing time大于2倍cpu time，说明进程有过多的等待，往往可以说明存在cpu瓶颈)
在明白这些统计时间的基础上，就可以根据以上信息进行初步的性能问题分析了。
bc315上面良好的性能指标大概如下:
就整体而言：
Main menu(transaction profile)<100ms，就是说在sap标准菜单中的操作相应时间小于100ms
wait time<10%response time，比较小的wait time，说明dispather工作正常，能够及时响应，因此系统整体性能应该良好。
有一个经验性的参数，就是平均response time在1秒以下，代表着系统有良好的性能，但是需要个例对待。
此外还有以下参数:
平均roll-in time<20ms
平均roll-wait time<200ms
平均load(and generation) time<10% response time(50ms)
平均database request time<40% of(response time-wait time)
平均cpu time和processing time相当。
large roll-wait time代表着sap应用服务器同GUI或者外部系统的连接有性能问题。
large load time 一般是对应的program,cua或者screen缓存偏小
large database time则对应着数据库性能问题(database cpu/memory bottleneck, network work problem,index,buffer,statistics等)，也可能是expensive sql statement.
large cpu time 可能是abap程序性能问题
processing time远大于cpu time往往代表cpu瓶颈，网络问题
有了以上基础，就可以开始进行性能问题的初步分析了。
二：性能监控：
常用的性能监控和分析工具
workload analysis监控和分析：ST03N,ST03
work process监控和分析: SM50,SM66
操作系统性能监控：ST06,OS07
数据库性能监控：ST04 or ST04OLD
SAP内存监控：ST02
sap工作进程监控SM50/SM66
使用SM50我们可以监控到当前登陆的实例的工作进程，可以查询到状态，PID，正在运行的程序，正在访问的表及动作，如果正在执行某个sql语句，也可以在details里面看到sql语句，还可以查看到比如信号等等的信息。同时，我们可以在sm50里面跳转到对应进程的trace 日志文件进行更细节的查看，当然我们也可以手动更改相应进程的跟踪级别。这些功能，无论是对于系统整体性能还是特定程序的性能问题实时分析都很有帮助。而且SM50还可以中止进程或者终止程序。
典型的比如running状态下direct read，load program, rool in/out等动作，可以分别对应到数据库，sap buffer,sap memory问题，典型的stopped状态下的PRIV,CPICreason往往对应sap memory,communication问题。
需要注意的是，当用户登陆到sap之后，只会在一个instance上而不会被系统自动分配到别的instance上。因此，sm50仅仅能察看我们当前登陆系统的进程。所以我们有SM51和SM66来实现SM50不能实现的功能。
操作系统监控ST06/OS07
这个工具对于操作系统整体性能初步分析非常有用。我们可以用来监控CPU负载(syste,user,idle的比率，平均等待进程数/cpu)，还可以监控物理内存的可用情况以及page in or out情况，也能用来察看简单的硬盘，网络信息。
通过点击应用程序工具栏的detail analysis menu按钮，我们可以进行更细致的分析，比如察看cpu的历史记录，查看当前最耗cpu的进程(top cpu)，用系统工具去调用ping命令来测试前端与应用服务器，应用服务器和数据库的网络情况。也能和其他实例对比，还可以查看最近被变动的参数(当某些变动导致性能问题是比较有效)
SAP tunning summery 监控ST02
如果sap存在buffer问题或者内存参数配置问题，st02会是一个非常有用的监控和分析工具，而且能够帮助我们找到相应的实例参数。
一般而言，就sap buffer，不应当有太多的swap情况出现，但是program buffer,cua,single record buffer要例外一些。特别是program buffer.
就buffer而言，我们需要一段warm up的时间才能作为判断，其中的hit ratio是一个重要指标，buffer的命中率越高自然代表着越大比率的数据直接从buffer中获取，自然也就越能起到buffer改善i/o性能的作用。
就buffer而言，如果是多instance,采用load balancing会是更有效地解决方法。当然如果米够多，内存够大。。。
相关的参数，在st02的应用程序工具栏可以直接点击current paramter获取。
三：SAP内存管理：
SAP内存区域
Shared Memory: SAP Buffer (Program, Screen, Data Dictionary), Extended Memory, Roll Buffer, Paging Buffer
Local Memory: Local Roll, Local Page, Heap Memory
Roll Area(属于local memory), 主要存储user context,比如程序指针，set/get parameters,权限，内表，报表。
Paging Area(属于local memory)，主要存储程序相关数据。比方说extract,Import and Export，call transction之类。
Roll Buffer和Paging Buffer则是对应Roll area,paging area得shared memory 部分，roll-in过程表示从roll/paging buffer(shared memory)拷贝user context道roll/paging Area(local memory),roll-out恰好相反。
Roll file和Paging file则是对应Roll buffer和Paging buffer得文件部分(on disk)，当Roll buffer和paing buffer不足，则会存储与Roll file和Paging file.
Extended Memory(属于Shared Memory),存储同Roll area得数据，不过用户进程访问extended memory不同于roll area得拷贝，而是映射.
Extended Memory采用映射方式的好处在于：使用指针访问成本更低，速度更快，能够更有效的利用内存，降低cpu和硬盘的负载。当然，extended memory需要足够的物理内存来支持，因为它设计的初衷是理应只存在于物理内存。
内存分配顺序
sap得内存都是通过instance profile参数来设置的，所以下面简单介绍相关内存参数(st02 SAP memory部分的内存参数,这里都以unix平台为基准，windows平台则是采用零内存管理，在内存参数上有着差异)。
Profile parameter
ztta/roll_area
Comment
Roll area per workprocess (total)
ztta/roll_first
First amount of roll area used in a dialog WP
ztta/short_area
Short area per workprocess
rdisp/ROLL_SHM
Part of roll file in shared memory
rdisp/PG_SHM
Part of paging file in shared memory
rdisp/PG_LOCAL
Paging buffer per workprocess
em/initial_size_MB
Initial size of extended memory
em/blocksize_KB
Size of one extended memory block
em/address_space_MB
Address space reserved for ext. mem. (NT only)
ztta/roll_extension
Max. extended mem. per session (external mode)
abap/heap_area_dia
Max. heap memory for dialog workprocesses
abap/heap_area_nondia
Max. heap memory for non-dialog workprocesses
abap/heap_area_total
Max. usable heap memory
abap/heaplimit
Workprocess restart limit of heap memory
Roll buffer由rdisp/ROLL_SHM设置， Roll file由rdisp/ROLL_MAXFS减去rdisp/ROLL_SHM决定，单位8Byte。
Paging Buffer由rdisp/PG_SHM
设置，Paging file由rdisp/PG_MAXFS减去rdisp/PG_SHM决定，单位8Byte。
Roll Area分为Roll first和一般性的Roll Area.前者由ztta/roll_first 决定，一般值为1，具体值根据basis版本不同而略有差异；后者由ztta/roll_area决定。这两个区域都属于进程的local内存，都是在进程初始化时候就分配了相应的内存空间，但是ztta/roll_area部分并不是最初就被使用(对于win零内存管理机制，这个参数无效，而是使用em/address_space_MB)。
Extended memory属于shared memory部分由em/initial_size_MB来限定了其大小，这个应该是在sap instance初始化(不太确定，比方说windows的内存管理机制同unix是不同的,应该是由em/max_size_MB限制)是就分配的共享内存；ztta/roll_extension则是对每个进程所能访问em/initial_size_MB得最大配额。
sap一个实例所有进程得local heap得和的最大值由abap/heap_area_total来限制。abap/heap_area_dia和abap/heap_area_nondia则分别对dia和btc类型的进程所能分配的heap内存的最大值进行了限定。abap/heaplimit对于unix系统来说比较有意义，因为这代表着，如果一个进程使用的heap内存超过了这个值，那么该进程在运行完当前的程序之后，会被重新启动以释放之前申请的heap memory。
注意：extended memroy和heap memory都有一个总量的限制，即既有单个进程限制，也有总和限制。roll area是预先固定分配的。就unix平台，extended memory总量是固定和预分配的。就win平台而言，是自动管理并可按需自动增加到em/max_size_MB(不是很确定其细节）。
对dialog进程而言，不同类型操作系统平台下进程内存分配顺序是一致的。
即ztta/roll_first->ztta/roll_extension->ztta/roll_area->abap/heap_area_dia
对于dialog进程而言，有一个特殊的状态叫做PRIV mode，这一状态代表着dialog进程开始使用heap memory，priv mode这一个状态同时也标志着该进程被该session独占。
对于nog dialog进程，win和unix系统的内存分配方式略有差异。
非win平台 ztta/roll_area->abap/heap_area_nondia->ztta/roll_extension
win平台 ztta/roll_first->ztta/roll_extension->ztta/roll area->abap/heap_area_nondia
思考，根据进程类型，操作系统平台不同，那么内存耗尽的dump的类型是否会跟最后分配的内存类型相关？
小结：对于sap的内存参数管理，需要分unix和win nt与linux平台，然后才能选择合适的内存参数。关键是理解了不同类型的内存管理机制。
四硬件能力评价：暂略过
五耗资源SQL语句：
六 SAP表缓存：
七接口监控：
更多关于SAP的文章
编辑回复