达梦在大批量绑定变量时遇到的异常处理模拟和分享

问题背景

        在日常使用中，经常会遇到需要进行大批量插入、修改或查询的操作场景，大部分人都会按照之前在其他数据库时的使用习惯在达梦进行大批量绑定参数的数据插入、修改或查询，此时或许就会遇到报错变量空间溢出或Too big variables space等报错，经过排查处理后会引发一个新的疑问，达梦的绑定参数个数最大是65535，为什么没有达到这个数也会报错呢？

相关参数

        此时就要引入一个参数，VM_STACK_SIZE，虚拟机堆栈大小，在达梦数据库中，每个会话线程都会申请一定大小的堆栈空间用于参与会话sql执行的一系列操作，当一次性发起大批量的带绑定变量的操作时，如果虚拟机堆栈过小则会抛出异常，以下通过模式测试确认该参数的影响。

模拟测试

场景一

        通过jmeter测试大批量带绑定变量插入验证VM_STACK_SIZE参数对该系列场景的影响，首先使用默认大小进行测试，一次性插入1000条，每条插入绑定变量43个，变量总数为43000。

        VM_STACK_SIZE默认大小为256KB

        jmeter执行一次，一次性插入1000条，每条插入绑定变量43个，变量总数为43000，报错Too big variables space，如下图

        同时同步查看V$VMS视图观察堆栈使用情况，发现VUSED使用量极少，此处推测会话线程在解析sql后根据sql的情况申请堆栈大小，但是绑定参数数量过多堆栈空间配置过少导致申请失败从而返回异常。或者这一过程极快，查询动态视图时没办法捕捉到

        同时从sql log中查看该sql执行情况，会话线程解析完sql后，开始进行事务处理，随后就发生了回滚，中间的1秒时间可能为上诉进行申请虚拟机堆栈空间等一系列操作

场景二

        在测试了该参数在默认值情况下大批量场景插入失败后，尝试调大参数再试，将默认的256KB调整为2048KB

        jmeter执行一次，一次性插入1000条，每条插入绑定变量43个，变量总数为43000，执行成功，如下图

        同时同步查看V$VMS视图观察堆栈使用情况，这一过程在一瞬间，此时查询动态视图也没办法捕捉到使用信息，查看sql log，调大后批量插入执行成功，执行时间为49毫秒。

堆栈大小使用验证 

        jmeter尝试调大并发，捕捉到了部分线程的堆栈空间使用情况，根据视图信息猜测，一次性插入1000条，每条插入绑定变量43个，变量总数为43000时，单个会话线程大概需要用到430004/1024=419.92KB的堆栈空间，在默认256时报错。

        同时测试了调整VM_STACK_SIZE410时，执行失败。

        调整为430，执行成功，说明通过视图判断的大小基本准确

        

总结

        VM_STACK_SIZE对大量绑定参数变量场景确实有影响，但是在遇到这些场景时，一味的通过调大参数去进行处理不是一个很好的选择，虚拟机堆栈涉及到数据库内存底层，本次测试也仅是日常使用过程中遇到问题的同时也对该问题的相关解决方案引起的兴趣而起的测试，在遇到该场景时，并不是批量越大效率就越高，还是需要通过调整批次的数量来避免问题，毕竟每一个数据库抛出的错误都有它的一定道理。

更多技术干货请移步达梦技术社区：

https://eco.dameng.com
————————————————