SAP 锁表参数

锁表参数 enque/table_size via ECC6 EHP7

本文链接：https://blog.csdn.net/ot512csdn/article/details/49616887



enque/table_size    决定SAP程序锁定数据的多少。

 

该参数遇到ECC6 EHP7版本，会躲在 DEV_ASCS01_erpdev 参数文件中。

如果修改DEFAULT.PFL 或 DEV_DVEBMGS00_erpdev 参数文件均不能生效，但EHP7版本在RZ10中有拿掉了ASCS的参数文件。

 

有一个办法，进入操作系统层，找到DEV_ASCS01_erpdev 参数文件，用VI打开，添加enque/table_size的值。

这样SAP系统启动才能使该参数生效！！！

 

更改enque/table_size的大小

原文链接：https://blog.csdn.net/jamesxsy/java/article/details/22943631

 

在月结的时候出现上述错误，锁定表溢出主要是由于参数：enque/table_size 太小导致的 . 这个参数太小之后，很多队列中的进程和JOB都会受到影响，报出一堆错误信息：

查询相关Notes: 1565578 - LockTable Overflow ，   13907- System error in the block handler, overflow lock table

这里面有讲到Lock Table的原理和更改参数的方法.

对应到具体的系统：SM12,附加—>统计。

 其中Peak Util 值的大小 >= 80% Granule Arguments 或者Granule Entries值，那就应该扩大参数enque/table_size的值.

enque/table_size的值如果是32000（32M），那这些表最大能包含近40000的条目.

 

现在我们系统中的enque/table_size值的大小如下，而根据上图，GranuleArguments 已经达到39481（39M），我们系统默认值4M已经远远不够了.

 因此我们将这个enque/table_size的值调整到最大，即可避免以后此类问题再次发生.

#-----------------------------------------------------------------------

# SAP Enqueue Server
#-----------------------------------------------------------------------
enque/table_size = 64000
enque/snapshot_pck_ids = 1600
enque/server/max_query_requests = 5000
enque/server/max_requests = 5000
enque/async_req_max = 5000
enque/server/threadcount = 4
rdisp/enqname = $(rdisp/myname)
SETENV_05 = SECUDIR=$(DIR_INSTANCE)/sec
 

 

SM12中查看系统当前的锁定内存值（附加--统计）：

 

R/3锁表溢出现象解决:

 

用TCODE:sm12看是否有锁占的空间过大,有就解除.

还有就是确定你是不是有人和你同时操作,产生事物锁.

 

最后实在不行就改下参数文件扩大表空间(enque/table_size)

TCODE:RZ10  INTANCE PROFILE.找到对应“enqueue table size”的参数做修改

 

 

DB2死锁解决办法(SQLCODE=-911, SQLSTATE=40001)

（DB2的数据库）在做update更新的时候，发生了死锁。后台报的错误为：SQLCODE=-911, SQLSTATE=40001

 

---------------------------------------

SQLCODE=-911, SQLSTATE=40001 错误的原因：是在执行update语句的时候发生了死锁

SQLCODE=-911, SQLSTATE=40001 解决方法：

---------------------------------------

然后我在CSDN上看到一个解决办法，成功搞定死锁

 

db2 命令行:

1、用管理员用户登录：db2 connect to 你的数据库名 user 用户名 using 密码

2、db2 "get snapshot for locks on 数据库名"

-------上面语句执行完成以后，你可以找到下面一段文字

应用程序句柄                               = 689
应用程序标识                        = *LOCAL.DB2.120711101108
序号                                = 00001
应用程序名                          = javaw.exe
CONNECT 授权标识                           = DB2ADMIN
应用程序状态                        = UOW 正在等待

3、db2 "force application(689)"   689就是上面查询出来的应用程序句柄
杀掉死锁进程

 

====================================================

关于enque/table_size

 

分类：

2010-10-31 13:40:38

*[1] Question: How large can and should the lock table be configured?
*As of Release 4.0 the default size for the lock table is 4 MB. For
medium-sized systems this value is absolutely sufficient. As of 4.6, it
appears that a size of 10-20 MB is required for some background jobs, and a size of 32-200 MB may be required for large systems, although this is the exception. As a lock table that is too small causes transaction terminations, but resources for the lock table are relatively low, a size of 20 MB should be specified initially. no further changes are generally required to the layout of the shared memories with this size (except for AIX 32 bit). You can enter this setting using the profile parameter:
enque/table_size = 20000
You can monitor the lock table in transaction SM12 via the menu option
"Extras -> Statistics".
The lock table is a shared memory, not a database table.

* [1]问题：锁表可以并且应该配置多大？
*从4.0版开始，锁定表的默认大小为4 MB。对于
中型系统，该值绝对足够。从4.6开始，
似乎有些后台作业需要10-20 MB的大小，而大型系统可能需要32-200 MB的大小，但这是例外。由于锁表太小会导致事务终止，但是锁表的资源相对较少，因此应最初指定20 MB的大小。通常不需要对此大小的共享内存的布局进行任何更改（AIX 32位除外）。您可以使用配置文件参数输入此设置：
enque / table_size = 20000
您可以通过菜单选项
“其他->统计” 来监视事务SM12中的锁定表。
锁表是共享内存，而不是数据库表。

*[2] Question: What does the expired queue time in the syslog mean for locks?*
Locks can usually only be set in the R/3 system if they are available. If an object is already locked, requests to lock it are refused and the error message " ... locked by user ..." is issued. This prevents the dead lock situations familiar from databases. However, a job should not terminate in background processing if a lock happens to be unavailable. In such cases, the locks are requested with the addition "and wait". The queue time incurred is then logged in the syslog. The maximum queue time is set using the profile parameter enque/delay_max.

* [2]问题：syslog中过期的队列时间对锁意味着什么？*
通常只有在R / 3系统可用时才可以设置锁。如果对象已被锁定，则锁定该对象的请求将被拒绝，并发出错误消息“ ...被用户...锁定”。这样可以防止数据库出现死锁情况。但是，如果锁恰巧不可用，则作业不应在后台处理中终止。在这种情况下，请求锁时要加上“和等待”。然后将产生的队列时间记录在系统日志中。使用配置文件参数enque / delay_max设置最大队列时间。

 

*[3] Question: How does communication take place in lock management?*
This question is especially important for troubleshooting since it indicates the characters at which errors can occur. In the Central Instance, all work processes can access the lock table directly. Therefore, the ENQ work process is not needed, and so no communication occurs.
An application server sets and deletes locks via the Message Server. There is therefore communication from work process-> dispatcher->server -> dispatcher -> ENQ work process. The lock table is read by RFC, that is, work process-> dialog process -> gateway-> gateway-> dialog process -> dialog process. Here again, the ENQ process is not required, although two dialog processes are needed for RFC communication. Central instances with few dialog processes can be overloaded quickly in this way. The same also applies to pure background or update server processing. The number of dialog
work processes must therefore be at least as high as the number of remaining processes.

* [3]问题：锁管理中通信是如何进行的？*
该问题对于故障排除尤其重要，因为它指出了可能发生错误的字符。在中央实例中，所有工作流程都可以直接访问锁定表。因此，不需要ENQ工作流程，因此不会发生通信。
应用服务器通过消息服务器设置和删除锁。因此，从工作流程->调度程序->服务器->调度程序-> ENQ工作流程开始进行通信。锁定表由RFC读取，即工作进程->对话进程->网关->网关->对话进程->对话进程。同样，这里不需要ENQ过程，尽管RFC通信需要两个对话过程。对话过程很少的中央实例可以通过这种方式快速重载。同样的情况也适用于纯后台或更新服务器处理。因此，对话
工作流程的数量必须至少与其余流程的数量一样高。

*[4] Question: What are "black" and "blue" locks?*
Black locks are normal transaction locks. Blue locks are inherited by the update system and deleted with the corresponding update request. Blue locks are also saved in the file system and restored when the system is restarted.

* [4]问题：什么是“黑色”和“蓝色”锁？*
黑色锁是正常的事务锁。蓝色锁由更新系统继承，并与相应的更新请求一起删除。蓝锁也保存在文件系统中，并在系统重新启动时恢复。