GBase 8s性能调优流程

在实际的生产运行环境中，很多客户现场都看到开发人员和系统管理人员遇到很多有关于GBase 8s 数据库引起的性能问题，进而被多次问起如何进行GBase 8s 数据库性能调优，

性能优化原则

包括：

• 性能规划：深入了解应用与数据库的交互特征，确立良好的设计、开发、测试迭代过程，上线前消除模型上的性能瓶颈。
• 实例调优：建立性能基准，对比调节数据库、操作系统、存储、网络等的配置，主动监控、消除瓶颈。
• SQL 调优：书写高效 SQL，优化相关数据库对象，充分借助优化器，确定最佳执行计划。

性能优化流程

1. 首先执行下面的初始检查：
   – 获取直接用户的使用反馈，确定性能目标和范围。
   – 获取性能表现好与坏时的操作系统、数据库、应用统计信息。
   – 对数据库做一次全面健康检查。
2. 根据收集的信息，以及对应用特性的了解，构建性能概念模型，明确性能瓶颈所在，以及导致性能的根本原因。
   – 首先应该排除操作系统、硬件资源造成的瓶颈。
   – 然后针对数据库系统性能进行分析
   – 必要时，还需要检查应用日志，因为系统性能问题也可能由于应用非 SQL 部分造成瓶颈。
3. 提出一系列针对的优化措施，并根据它们对性能改善的重要程度排序，然后逐一加以实施。不要一次执行所有的优化措施，必须逐条尝试，逐步对比。
4. 通过获取直接用户的反馈验证调节是否已经产生预期的效果，否则，需要重新提炼性能概念模型，直到对应用特性了解进一步准确。
5. 重复上述，直到性能达到目标或由于客观约束无法进一步优化。

常见调优技巧

找到 CPU 占用最高的 SQL

1. 在 sysmaster 库中执行

select sqx_estcost, sqx_sqlstatement 
from syssqexplain 
order by sqx_estcost desc

注意：此时看到的仅仅是当前正在执行的 SQL
需要多看几次

2. onstat 命令
   onstat -g act 得到当前正在执行的 SQL
   
   根据 rstcb 列

onstat -u | grep 57c68220

从第三列 sessid 得到 SESSION
onstat -g ses SESSION 即可得到当时正在执行的 SQL
一般多找几个 threads 后，就基本可以确定问题 SQL

得到 SQL 后，利用 set explain on 分析其查询路径，看是否未利用索引，在对大表进行全表扫描，根据需要创建相应索引。

找到全表扫描较多的表及其 SQL

1. 得到全表扫描较多的表

-- 系统顺序扫描较多时，被多次顺序扫描的大表，如果有，应该考虑增加索引
select first 5 
  substr(t.tabname,0,20) tabname,
  substr(dbsname,0,10) dbname, 
  nrows*rowsize*p.seqscans costs, 
  substr(p.seqscans,0,8) seqscans,
  substr(nrows,0,8) nrows 
from sysmaster:sysptprof p , systables t,sysmaster:sysprofile s 
where p.tabname = t.tabname 
  and p.seqscans > s.value/50 
  and s.name = 'seqscans' 
  --and s.value > 2000000 and nrows > 2000 
order by 3 desc

2. 利用 onstat –g ses 0 –r 5/ onstat –g stm 的输出信息，根据表名，找到可能的 SQL 语句。由于以上获取 SQL 的办法是有局限的，如果无法获取，建议通过查看应用日志或联系开发人员查看源代码的方式来找到。

3. 利用 set explain on 分析其查询路径，确认是在对表进行全表扫描，根据需要创建相应索引。