磐维数据库（PanWeiDB）是由中国移动基于中国本土开源数据库openGauss打造的自研数据库产品，主要面向ICT基础设施。它具有高性能、高可靠性、高安全性和高兼容性的特点，能够支持集中式、分布式、云原生、一体机等多种应用场景。目前，磐维数据库已在中国移动的多个省（区、市）公司及专业公司部署应用。
案例背景
本文将分享**江西移动公司**在数据库国产化过程中的应用改造案例：BPMP系统应用程序在适配磐维数据库时，测试工单审批功能发现流程的审批信息出现问题。分享将向各位读者展示从发现问题到解决问题的全过程，
环境描述
- OS版本：BCLinux for Euler 21.10 (LTS-SP2)
- DB版本：panweidb 3.0.0
- 兼容模式：A模式
- 数据库架构：单机模式
问题描述
接到业务反馈，应用在适配磐维数据库时遇到的序列问题：有个logid字段是通过触发器触发序列的值自动插入表中，但序列值却不是按顺序插入。
表现为：审批流程是按id排序，但是最新的流程排到上面去了，正常来说应该是按时间顺序拍到最下面去。
问题分析
1、接到业务反馈的问题后，让他们提供了对应的SQL，并在磐维测试库执行。
SELECT * FROM xxxxx where processid=‘4347330’
可以看到在这个流程中，有个logid=23371742，这值比前后的值都要小，正常应该是23371785，按顺序插入的才对。
2、看到序列号为按顺序排列，首先想到到的是手动查看序列的当前值和下一个值是
否连贯
select nextval(‘sq_ser_checklogstem’)
select currval(‘sq_ser_checklogstem’)
可以到，手动设置下一个值是连贯的。此时又让业务测试新建一个流程看看是否还有问题。业务反馈流程还是有问题，在数据库查看logid也是不连续的。
SELECT * FROM xxxxx where processid=‘4347441’
注：该图是节选一个流程查看的，与上面查看的当前值无关
3、通过查看序列信息对比，发现序列的last_value和currval不一样
- 手动设置下一个值也是没有变化
分析结论
通过以上分析步骤可以出通元命令\d+序列名,看的序列的详细信息与currval和nextval的信息对不上，可以判断序列是有问题的，且问题就出在 cache_value 的值为20。这个参数会导致序列值出现不连续的现象。
注：CACHE 20表示系统每次从数据库获取序列值时，都会一次获取20个值并将其存储在内存中，供后续使用，如果系统在缓存中的序列值未完全使用完毕前发生故障或重启，那么未分配出去的序列值可能会丢失，导致序列值不连续。
解决方法
将序列号的cache_value 值改为1即可。
alter large sequence sq_ser_checklogs cache 1;
- 修改完之后，可以查看序列last_value的信息和currval是否一致
- 考虑到不止一个序列的cache值是20，所以可以用以下脚本拼接alter sequence 语句，然后批量修改。
SELECT
‘ALTER LARGE SEQUENCE ’ || sequence_schema || ‘.’ || sequence_name || ’ CACHE 1;’ AS alter_sequence_statement
FROM
information_schema.sequences;
注：ALTER LARGE SEQUENCE是针对大序列的修改
总结
如果想保证多个会话中，序列在任何情况下都连号，都需要将序列缓存（cache_value）设置为1。
