---

---

兼容 是对前人努力的尊重 是确保业务平稳过渡的基石 然而 这仅仅是故事的起点

一、开篇：迁移的痛点与期待

在数据库领域，Oracle无疑是当之无愧的巨头，承载着众多企业的核心业务数据。但随着技术的发展和成本的考量，越来越多的企业开始寻求Oracle的替代方案，金仓数据库（KingbaseES）就是其中的佼佼者。不过，迁移过程中的性能优化一直是企业最关心的问题之一。毕竟，谁也不想在迁移后，系统的响应速度变得龟速，业务受到影响。

二、下载部署：初遇金仓

访问电科金仓官网，在【数据库】栏目下载KingbaseES V9R2C13安装包。下载过程还算顺利，没有遇到什么大的问题。安装的时候，我发现金仓数据库的安装向导做得挺友好的，一步步引导，对于有数据库安装经验的人来说，上手并不难。不过，这里我想吐槽一下，安装过程中有些提示信息还是不够清晰，比如在选择安装路径的时候，没有明确提示哪些路径是不建议选择的，新手可能会踩坑。

安装完成后，我进行了简单的测试，创建了一个数据库实例，插入了一些测试数据。初步感觉，金仓数据库的启动速度还不错，比我之前安装的一些其他国产数据库要快。不过，这只是初步体验，真正的考验还在后面。

三、CPU资源优化：解决使用率过高的痛点

在数据库运行过程中，CPU使用率过高是一个常见的问题。如果不能及时解决，会严重影响数据库的性能。我通过学习金仓数据库的相关知识，掌握了一些识别和解决CPU使用率过高问题的方法。

（一）识别CPU使用率高的方法

1. kwr报告中DB CPU指标：DB CPU指标可作为一段时间内CPU使用率的依据。kwr报告提供CPU使用率过高时的有关sql耗时。通过分析kwr报告，我可以了解到哪些SQL语句消耗了较多的CPU资源。
2. kmonitor监控工具：kmonitor监控工具中资源使用率项可监控cpu使用率，并提供邮件、短信告警功能。通过kmonitor，我可以实时监控数据库的CPU使用情况，及时发现问题。
3. sys_stat_statements扩展：sys_stat_statements扩展可识别占用cpu时间的查询。通过执行以下SQL语句，我可以查询到消耗CPU时间较多的SQL语句：

查询sql的总cpu消耗时间
select c.rolname,b.datname,a.total_parse_time+a.total_plan_time+a.total_exec_time as total_time,a.* from sys_stat_statements a,sys_database b,sys_authid c where a.userid=c.oid and a.dbid=b.oid order by a.total_exec_time desc limit 5;

查询sql平均执行时间
SELECT userid::regrole, dbid, query, mean_exec_time 
FROM sys_stat_statements 
ORDER BY mean_exec_time 
DESC LIMIT 5;    

查询sql总执行时间
SELECT userid::regrole, dbid, query 
FROM sys_stat_statements 
ORDER BY total_exec_time 
DESC LIMIT 5;   

（二）CPU消耗较高的原因及解决方法

1. 长时间运行的事务：长事务可能导致CPU使用率过高。我可以通过以下SQL语句查询运行时间最长的连接：

SELECT pid, usename, datname, query, now() - xact_start as duration FROM sys_stat_activity WHERE pid <> sys_backend_pid() and state IN ('idle in transaction', 'active') ORDER BY duration DESC;

如果发现长时间运行的事务，我可以和应用人员协商终止这些事务，释放内存和CPU资源。终止事务的SQL语句如下：

SELECT sys_terminate_backend(pid);

需要注意的是，如果此终止方式失败，则需要在操作系统调用gdb命令终止会话连接。

2. 数据库总连接数：数据库的大量连接也可能会导致CPU和内存使用率增加。我可以通过以下SQL语句查询按状态排序的连接数信息：

SELECT state, count(*)  
FROM  sys_stat_activity   
WHERE pid <> sys_backend_pid()  
GROUP BY 1 ORDER BY 1;   

如果发现数据库总连接数过多，我可以考虑使用连接池程序控制总连接数和空闲连接时长，从而降低CPU和内存的使用率。

3. 低效的sql：低效的SQL语句是导致CPU使用率过高的常见原因之一。我可以通过kwr报告中Top SQL By Elapsed Time和Top SQL By CPU Time查询消耗高CPU的SQL语句，再通过explain analyze语法分析该SQL语句的执行计划，从而优化SQL语句。例如，我曾经遇到过一个查询语句，原本执行需要好几秒，通过添加合适的索引，执行时间缩短到了几百毫秒。

4. 硬件性能低：有的业务系统执行大批量SQL语句导致服务器CPU使用率高，这可能是因为服务器硬件资源有限。在这种情况下，我可以考虑升级服务器硬件，或者对业务系统进行优化，减少SQL语句的执行量。

四、IO资源优化：提升数据传输效率

IO资源是数据库性能的关键因素之一。如果IO性能不佳，会导致数据库的响应速度变慢，影响业务的正常运行。我通过学习金仓数据库的相关知识，掌握了一些IO资源优化的方法。

（一）优化数据库内存参数

1. shared_buffers：确保Kingbase有足够的共享内存存放数据页。调整此参数以匹配系统上可用的内存量，以获得数据库最佳性能。不同业务类型的数据库，shared_buffers参数的设置会有所不同。Kingbase数据库建议配置25%的物理内存给shared_buffers使用，这是一种当你不了解业务场景与数据分布时的普遍配置方案。举个例子，如果你的物理内存是256GB，而你的常用数据是100GB，那么设置一个大于100GB的shared_buffers可能是比较好的选择。设置shared_buffers的首要原则是，不让操作系统产生较多的换页。
2. wal_buffers：WAL日志是Kingbase中的一项安全相关功能，可确保事务的持久性和一致性。配置wal_buffers参数以匹配您的工作负载，并确保最佳WAL性能。调整wal_buffers的值时，重要的是要考虑生成WAL数据的速率，增加wal_buffers的值有助于降低磁盘写入频率并提高性能。不过在普通的负载下，调整wal_buffers并不能显著看到数据库性能的提升，只有当写入wal_buffers的速度大于Walwriter写盘的速度的时候，加大wal_buffers才会有特别明显的性能提升，这个场景会有很频繁的dml事务。作为一般规则，建议wal_buffers的值设置为磁盘数据库块大小的倍数。

（二）调整IO调度策略

采用合适的磁盘调度算法，可以提高IO性能。IO调度策略一般包括CFQ、Deadline、NOOP和Anticipatory。对于机械磁盘来说，Deadline是数据库的最佳选择，比如tpcc一般采用Deadline。固态硬盘一般可以不做调整。调整IO调度策略的命令如下：

echo deadline >/sys/block/sda/queue/scheduler

将sda的调度策略设置为deadline。我们也可以直接在/etc/grub.conf的kernel行最后添elevator=deadline来永久生效。

（三）利用多IO设备分担压力

把数据、日志、索引放到不同的I/O设备上，或者使用RAID设备，以此来利用多个设备的IO能力来分担IO压力。这样可以避免单个IO设备成为性能瓶颈，提高数据库的整体性能。

（四）优化文件系统挂载方式

优化挂载文件系统的参数，可以提高IO性能。推荐使用xfs和ext4文件系统。挂载XFS参数如下：

(rw, noatime,nodiratime,nobarrier)

挂载ext4参数如下：

ext4 (rw,noatime,nodiratime,nobarrier,data=ordered)

例如，noatime和nodiratime可以去掉更新访问的时间，nobarrier可以避免文件系统在数据提交时强制底层设备刷新cache，提高IO性能。

（五）配置预读IO请求队列

主要是指操作系统的预读和排队的大小的调整。预读是提高磁盘性能的有效手段，目前对顺序读比较有效，主要利用数据的局部性特点。调整预读扇区数的命令如下：

echo 256 /sys/block/sdb/queue/read_ahead_kb

I/O请求队列长度（调大能增加硬盘吞吐量，但要占用更多内存）的调整命令如下：

/sys/block/sdb/queue/nr_requests

例如，对于随机读取，我可以减少预读扇区数，增大队列长度；对于顺序读取，我可以增大预读扇区数，减少队列长度。

（六）延迟提交参数提升系统的吞吐量

在KingbaseES中，有一个参数叫做commit_delay，可以通过调整它来提升系统的吞吐量。commit_delay定义了一个组提交领导进程（group commit leader process）在调用XLogFlush中获得锁后，需要睡眠多少微秒来让组提交跟随者进程（group commit followers）进行排队，这样其他事务也写入到WAL buffer中，在下一次被唤醒时组提交领导者进程便可以一次刷新多个事务的WAL日志持久化到磁盘，这样一次IO可以flush多条wal日志到磁盘，从而可以提升系统的总吞吐量。此外，KingbaseES还有另外一个参数配合使用，称为commit_siblings。这个参数作用是达到多少并发活跃事务数，commit_delay需要休眠。如果当前活动的事务少于commit_siblings，则commit_delay即使是非零值也不会进入休眠而且直接进行SYNC操作；反之则进入休眠状态，等待其他事务的提交请求进来进行合并。

五、函数对比：金仓与Oracle的差异

（一）内置函数：兼容性与差异

从参考资料中，我了解到金仓数据库在Oracle模式下，与原生Oracle数据库的内置函数有很多兼容的地方，比如数字函数中的ABS、ACOS等，字符串函数中的CONCAT、LOWER等。不过，也存在一些差异，比如CHR函数，KingbaseES不允许输入0，而Oracle允许输入0。

在实际使用过程中，这些差异可能会给迁移带来一些麻烦。比如，在Oracle数据库中使用了CHR(0)的SQL语句，迁移到金仓数据库后，就需要进行修改。不过，金仓数据库提供了一些兼容模式，能够尽量减少迁移过程中的修改工作量。

（二）JSON函数：强大的处理能力

金仓数据库提供了丰富的JSON函数，比如JSON_ARRAY、JSON_OBJECT等。我测试了这些函数的性能，发现它们的处理速度还是不错的。比如，我使用JSON_ARRAY函数将一个数组转换为JSON数组，执行速度非常快。

不过，和Oracle的JSON函数相比，金仓数据库的JSON函数还是存在一些差异。比如，在处理某些复杂的JSON结构时，金仓数据库的函数可能需要更多的代码来实现相同的功能。但总体来说，金仓数据库的JSON函数已经能够满足大多数企业的需求。

（三）聚集函数和分析函数：功能对比

聚集函数和分析函数是数据库中常用的函数之一。金仓数据库在这方面与Oracle也有很多兼容的地方，比如AVG、COUNT等聚集函数，RANK、DENSE_RANK等分析函数。不过，也存在一些差异，比如在处理某些特殊的数据类型时，函数的返回结果可能会有所不同。

在实际使用过程中，我发现金仓数据库的分析函数在处理大数据量的时候，性能表现还是不错的。比如，我使用RANK函数对一个包含百万级数据的表进行排名，执行速度还是能够接受的。

六、逻辑读与物理读：金仓与Oracle的区别

在Oracle数据库中，物理读是从磁盘读取数据到buffer cache，消耗磁盘IO，一般是全表扫描导致；逻辑读是直接从数据库buffer cache中获取数据，分为当前读和一致性读，消耗CPU。而在金仓数据库中，逻辑读和物理读的定义略有不同。

金仓数据库中，sys_stat_statements视图可以查看数据库性能的关键指标，以下是有关计算物理读和逻辑读的关键字段及其含义：

1. shared_blks_hit：shared_buffer中的命中块数。
2. shared_blks_read：shared_buffer中未命中，从操作系统缓冲读进shared_buffer的块数，如果操作系统缓存中没有有关记录，则需要读取数据文件而发生物理磁盘IO，此过程理解为发生物理读。
3. shared_blks_dirtied：shared_buffer中弄脏的总块数。
4. shared_blks_written：从shared_buffer中写入的总块数，这里指从shared_buffer写入了操作系统缓存或写入数据文件而发生物理磁盘IO，此过程理解为发生物理写。

金仓数据库中，物理读和逻辑读的计算方式与Oracle略有不同，因为金仓数据库考虑了操作系统缓存的影响。在实际使用过程中，我需要注意这些差异，避免出现不必要的问题。

八、体验回顾

经过这次深度体验，我对金仓数据库助力Oracle迁移过程中的性能优化有了更深入的了解。金仓数据库在CPU资源优化、IO资源优化等方面，都有不错的表现。同时，金仓数据库在与Oracle的兼容性方面也做得比较好，能够减少迁移过程中的工作量。另外，随着人工智能技术的发展，可以将人工智能技术更深入地应用到数据库性能优化中，实现更智能的性能调优。

如果你想了解更多关于金仓数据库的信息，可以访问金仓博客站（https://kingbase.com.cn/explore），那里有更多的技术文章和案例分享。