Oracle 23ai TPC-H 执行情况

J6vMZwlZZUQ7

TPC-H是一个广泛使用的基准测试，用于评估数据库系统在决策支持系统（DSS）场景下的性能。
在昨天的文章中，我们完成了《Oracle 23ai TPC-H 测试环境部署》，本文将继续记录在未做任何优化场景下，这22条SQL的真实执行情况。

• 1.修订执行有问题的SQL
  
• 2.完整运行22个SQL
  
• 3.测试结果统计（未做任何优化场景）
  

1. 修订执行有问题的SQL

因为根据《Oracle 23ai TPC-H 测试环境部署》准备好的TPC-H环境，实际测试发现有5个SQL需要微调下，否则执行会报错。
但不必担心，都是比较小的问题，不需要大改，主要是不符合Oracle 特殊的语法规则，稍加修改即可：

• Oracle 不允许在子查询别名前使用 AS 关键字
  
• Oracle 子查询的别名后面不需要也不能跟列名列表，只需要在子查询的末尾直接写上别名
  
• Oracle 不支持 substring(c_phone from 1 for 2) 函数的这种语法
  

实际测试涉及到的具体SQL和改写方案参考：
query7.sql、query8.sql、query9.sql

• 删除报错位置的 AS 关键字，具体位置如果找不到可以执行下，会报错具体位置，删除报错位置的 AS 关键字即可。
  

query13.sql

• 删除报错位置的 AS 关键字
  
• 把别名后面指定的(c_custkey,c_count)列名都去掉，列名别名c_count直接在子查询中直接指定即可。
  

query22.sql

• 删除报错位置的 AS 关键字
  
• 将substring(c_phone from 1 for 2) 改写为：substr(c_phone, 1, 2)，共有三处。
  

其他优化（可选）：
如果文件尾部有多余的where rownum语句，可以快速去掉，避免测试中不必要的错误回显：
查询最后一行情况：tail -n 1 query*.sql
我这里去掉文件最后一行：sed -i '$d' query*.sql
2. 完整运行22个SQL

我需要记录在做任何优化之前，确保完整运行过TPC-H的22个SQL查询，并记录每个查询的执行时间。
我这里使用如下脚本 query_all.sh 测试：
vi query_all.sh
for i in {1..22}; do    echo "PROMPT 当前执行第 $i 个查询;" >> commands.sql    echo "@query$i" >> commands.sqldonesqlplus -s tpch/tpch@alfred @commands.sql > output.log 2>&1因为执行时间比较长，我这里选择放到后台执行，同时可以利用周末的时间：
nohup sh query_all.sh &后台执行完成之后，发现这个output.log有811M大小..
嗯，有些查询返回行数实在是太多了，先不管，直接过滤下执行时间显示：
[oracle@dbtest dbgen]$ grep "Elapsed:" output.logElapsed: 00:06:36.20Elapsed: 00:01:09.51Elapsed: 00:07:43.89Elapsed: 00:07:24.58Elapsed: 00:08:11.85Elapsed: 00:06:01.30Elapsed: 00:07:39.31Elapsed: 00:07:46.35Elapsed: 00:10:10.19Elapsed: 00:08:45.04Elapsed: 00:00:56.25Elapsed: 00:07:04.59Elapsed: 00:02:46.57Elapsed: 00:06:22.81Elapsed: 00:00:00.06Elapsed: 00:06:09.22Elapsed: 00:00:00.38Elapsed: 00:01:11.31Elapsed: 00:06:20.15Elapsed: 00:17:00.94Elapsed: 00:07:05.97Elapsed: 00:07:15.76Elapsed: 00:14:26.95Elapsed: 00:01:22.08这有点乱。。而且咋是24个？比22个SQL要多了两个？
这里使用到一个小技巧，在匹配到关键字的行之后，额外多显示后面 1 行内容：
grep -A 1 "Elapsed:" output.log这样显示结果就是这样，第一个Elapsed时间就是对应第1个查询，后面也都好找到一一对应了，方便判断，原来执行第 15 个查询，是存在先创建视图，再查询，再删除这个视图的逻辑，所以Elapsed会多了两个，去掉这两个时间干扰即可。
3.测试结果统计（未做任何优化场景）

这里让鲸鱼小助手帮我根据实际测试结果直接整理出表格，方便大家直观看到测试结果。
查询执行时间统计表

查询编号执行时间 (HH:MM:SS)执行时间 (秒)执行快慢排名1100:00:56.2556.251200:01:09.5169.5121600:01:11.3171.3132200:01:22.0882.0841300:02:46.57166.5751500:06:09.22369.226600:06:01.30361.3071700:06:20.15380.1581400:06:22.81382.819100:06:36.20396.20101200:07:04.59424.59111900:07:05.97425.97122000:07:15.76435.7613400:07:24.58444.5814700:07:39.31459.3115300:07:43.89463.8916800:07:46.35466.3517500:08:11.85491.85181000:08:45.04525.0419900:10:10.19610.19202100:14:26.95866.95211800:17:00.941020.9422TOP 5 慢 SQL 执行情况

查询编号执行时间 (HH:MM:SS)执行时间 (秒)执行快慢排名1800:17:00.941020.94222100:14:26.95866.9521900:10:10.19610.19201000:08:45.04525.0419500:08:11.85491.8518关键信息

• 最慢查询：
  
  
  
  • 查询编号 18，执行时间 1020.94 秒（约 17 分钟），排名第 22。
    
  
  
• 第二慢查询：
  
  
  
  • 查询编号 21，执行时间 866.95 秒（约 14 分 27 秒），排名第 21。
    
  
  
• 第三慢查询：
  
  
  
  • 查询编号 9，执行时间 610.19 秒（约 10 分 10 秒），排名第 20。
    
  
  
• 第四慢查询：
  
  
  
  • 查询编号 10，执行时间 525.04 秒（约 8 分 45 秒），排名第 19。
    
  
  
• 第五慢查询：
  
  
  
  • 查询编号 5，执行时间 491.85 秒（约 8 分 12 秒），排名第 18。
    
  
  

说明

• 执行快慢排名 是根据执行时间（秒）从小到大排序，排名越小表示查询越快，排名越大表示查询越慢。
  
• 以上 TOP 5 慢 SQL 的执行时间均超过 8 分钟，其中查询编号 18 和 21 的执行时间尤为突出，分别超过 17 分钟 和 14 分钟。
  
• 这些慢 SQL 可能需要进一步优化，例如检查索引、优化查询逻辑或调整数据库配置，以提升整体性能。
  

在后续文章中我们将开始优化这些SQL，欢迎关注。