首页 > 数据库 >南大通用GBase 8c系统视图分析SQL执行时间

南大通用GBase 8c系统视图分析SQL执行时间

时间:2024-09-18 13:54:07浏览次数:3  
标签:执行 calls SQL 8c time 视图 时间 sql unique

南大通用GBase 8c是一款多模多态数据库,支持主备式、分布式部署方式。对于故障和性能分析,内部提供丰富的工具和系统表或系统视图支撑实现。本文将介绍如何通过dbe_perf.statement系统视图分析SQL执行时间。

1、概述

dbe_perf.statement 实际上是一个视图,这个视图实际执行的是 get_instr_unique_sql() 内置函数,能够显示分布式CN节点或者主备式主DN节点上执行过的SQL语句的部分时间信息,比如SQL执行总耗时、执行器中的耗时、优化器中执行的耗时等。

它只能在CN或者主备式主节点上执行,不能在备DN上执行。

内置函数get_instr_unique_sql()的数据来自于 g_instance.stat_cxt.UniqueSQLHashtbl 哈希表。哈希表内存有限,所以不能保存所有的sql信息,通过配置 instr_unique_sql_count GUC参数(默认值是 100)可以调整 dbe_perf.statement 能够记录的sql的数据。节点重启后,g_instance.stat_cxt.UniqueSQLHashtbl 哈希表内容会被清空。

2、示例

下面的示例展示了benchmarksql测试中 UPDATE bmsql_warehouse SET w_ytd = w_ytd + $1 WHERE w_id = $2 语句的统计信息。

 

test=# select * from dbe_perf.statement where query ~ 'UPDATE bmsql_warehouse';

执行结果如下:

[ RECORD 1 ]
--------+----------------------------------------------------------------------
node_name            | cn1
node_id              | -1178713634
user_name            | test1
user_id              | 16974
unique_sql_id        | 739002000
query                | UPDATE bmsql_warehouse     SET w_ytd = w_ytd + $1     WHERE w_id = $2
n_calls              | 9339
min_elapse_time      | 150
max_elapse_time      | 26529
total_elapse_time    | 2512361
n_returned_rows      | 0
n_tuples_fetched     | 0
n_tuples_returned    | 0
n_tuples_inserted    | 0
n_tuples_updated     | 0
n_tuples_deleted     | 0
n_blocks_fetched     | 1
n_blocks_hit         | 1
n_soft_parse         | 0
n_hard_parse         | 0
db_time              | 2929210
CPU_time             | 906947
execution_time       | 0
parse_time           | 24
plan_time            | 0
rewrite_time         | 9
pl_execution_time    | 0
pl_compilation_time  | 0
data_io_time         | 0
net_send_info        | {"time":215081, "n_calls":28017, "size":1285855}
net_recv_info        | {"time":1385396, "n_calls":26612, "size":884261}
net_stream_send_info | {"time":0, "n_calls":0, "size":0}
net_stream_recv_info | {"time":0, "n_calls":0, "size":0}
last_updated         | 2022-12-12 13:51:59.767953+08
sort_count           | 0
sort_time            | 0
sort_mem_used        | 0
sort_spill_count     | 0
sort_spill_size      | 0
hash_count           | 0
hash_time            | 0
hash_mem_used        | 0
hash_spill_count     | 0
hash_spill_size      | 0

通过返回信息,可得知:

  • 在测试的这段时间这条sql执行了 9339次。
  • 每次执行的时间是 db_time / n_calls = 313us 实际消耗CPU的时间 CPU_time / n_calls = 97us。
  • 这条sql走lightproxy,所以 plan_time rewrite_time execution_time 都是0。

3、字段解析

  • n_calls

表示这个sql执行的次数,下面的时间都是总的时间,如果要计算平均时间需要除以 n_calls。

  • db_time

表示这个sql 执行的总时间, 用这个时间除以 n_calls 就是每条sql执行的平均时间。这个时间的计时从 ReadCommand 接收到 client的消息开始 (timeInfoRecordStart), 到给client 发给 ReadyForQuery消息结束 (timeInfoRecordEnd)。

  • CPU_time

这个时间和db_time 的计时类似,和db_time 不同的是,它调用的是 clock_gettime(CLOCK_THREAD_CPUTIME_ID, &tv) API,也就是只计算CPU时间,不计算在内核中sleep的时间。

  • parse_time

统计的是pg_parse_query 函数内生成查询数的时间。

  • plan_time

统计的是 planner 函数 优化器生成执行计划的时间。

  • rewrite_time

统计的是 pg_rewrite_query 函数内查询重写的时间。

  • execution_time

统计的是 PortalRun 函数内执行器消耗的时间。

  • data_io_time

统计的是读取表的block的时间,因为CN上只有元数据,所以这个值很小。

  • net_send_info

统计的是CN向DN发送执行计划或者下推的sql而调用 com_send的次数,消耗的时间,发送数据量的大小。

  • net_recv_info

同net_send_info 统计的是CN调用 com_recv的次数,消耗的时间,接收数据的大小。

4、清除统计信息

如果想清空统计信息,重新开始统计,可调用 reset_unique_sql 内置函数。

reset_unique_sql 有三个入参:第一个入参可选 global 或 local,表示清除全局的或者本地的 sql。 第二个参数是 cleanType 用 all 即可, 第三个参数 cleanValue 用0 即可。

调用完后再查视图就会发现内容已清空。

test=# select reset_unique_sql('local', 'all', 0);
-[ RECORD 1 ]----+--
reset_unique_sql | t
test=# select * from dbe_perf.statement where query ~ 'UPDATE bmsql_warehouse';
(No rows)
test=#

以上就是通过系统视图查看SQL执行时间的方法。

标签:执行,calls,SQL,8c,time,视图,时间,sql,unique
From: https://blog.51cto.com/u_17023609/12045622

相关文章

  • Docker安装MySQL8.0.39报错:Fatal glibc error: CPU does not support x86-64-v2
    用Docker升级MySQL时报错Fatalglibcerror:CPUdoesnotsupportx86-64-v2,在网上找了很久资料,发现是MySQL的新镜像使用的是OracleLinux9,当前服务器的CPU无法安装这个所以报错,解决方法就是更换镜像版本这是我的解决方案,基于Dockerfile生成镜像:FROMm.daocloud.io/docker.......
  • C#如何使用SQLSugar进行数据库操作
    在现代应用程序中,数据库操作是不可或缺的组成部分。SQLSugar是一个轻量级的ORM(对象关系映射)框架,能够帮助开发者以简单的方式进行数据库交互。本文将介绍如何在C#中使用SQLSugar进行数据库操作。一、什么是SQLSugar?SQLSugar是一个高性能、易于使用的ORM框架,支持多种数据库,包括......
  • MYSQL CHAR会补齐空格吗
    在MySQL中,CHAR 类型会自动补齐空格。当你插入一个短于定义长度的字符串时,MySQL会用空格填充到指定的长度。例如,如果你定义一个 CHAR(10) 字段,并插入一个长度为5的字符串,MySQL会将其存储为 “XXXXX   ”(后面有5个空格)。这种行为与 VARCHAR 类型不同,后者不会补齐......
  • 20240918_114105 mysql 认识索引
    关于索引MySQL的索引是数据库管理系统中用于提高数据检索效率的一种数据结构。MySQL支持多种类型的索引,每种索引都有其特定的用途和优化方式。以下是MySQL中常见的几种索引类型:1.主键索引(PrimaryKeyIndex)定义:主键索引是一种特殊的唯一索引,它不允许有NULL值,且表中每一行数据......
  • SqlServer中的锁(仅供参考,可能有不准确的地方)
    SqlServer中的锁(仅供参考,可能有不准确的地方)-MyMemo-博客园(cnblogs.com) 锁模式|MicrosoftLearn共享锁(SharedLock):表示一个事务正在读取一行数据,其他事务也可以读取同一行数据,但不能进行写操作。也称为"S锁"或"读锁"。典型应用场景:当一个事务需要读取数......
  • MySQL与Glibc:了解它们的关系和版本
    最近发现mysql的linux版都有一个glibc后缀,特意查了一下这个glibc与mysql的关系一、解释MySQL是一款流行的开源关系型数据库管理系统,而Glibc则是GNUC库(GNUCLibrary)的简称。Glibc是大多数Linux系统上的标准C库,提供了许多基本的系统调用和函数。MySQL在运行时依赖于Glibc提供的......
  • 六种主流ETL工具的比较与Kettle的实践练习指南--MySQL、hive、hdfs等之间的数据迁移
            在数据集成和数据仓库建设中,ETL(Extract,Transform,Load)工具扮演着至关重要的角色。本文将对六种主流ETL工具进行比较,并深入探讨Kettle的实践应用。一、六种主流ETL工具比较1.DataPipeline设计及架构:专为超大数据量、高度复杂的数据链路设计的灵活、可扩......
  • 技术解读 MySQL InnoDB 大对象存储格式
    本文分享自华为云社区《【华为云MySQL技术专栏】InnoDB大对象存储格式解析》,作者:GaussDB数据库。1.背景在MySQL中,大字段是经常使用到的对象,例如:字符类型,包括日志、博客内容以及二进制类型的视频文件等。在InnoDB中,大字段也叫大对象(LargeObject,简称LOB),通常认为不会高频......
  • [昌哥IT课堂]|欢迎 MySQL 9.0,回顾 Oracle 在 8.0 版中的管理(译)
    对于新兴技术和社区的管理是相对容易的。经过29年发展,MySQL已成为全球数百万用户中使用最广泛且备受信任的开源数据库之一。在这一规模的社区领导中可能存在复杂性。我们努力寻求稳定和创新的平衡,为客户提供稳定可预测的平台,并为技术用户提供新功能。Oracle通过投资于技术的工......
  • 实操触发器的使用 mysql 20240918_102020
    需求新建日志表用于记录老师表的数据化情况起个名字teacher_log需要的列idoperationmsg建老师日志表CREATETABLEteacher_log( idINTPRIMARYKEYAUTO_INCREMENT, operationVARCHAR(11)NOTNULL, msgVARCHAR(200)NOTNULL);定义添加触发器如果往老师表tea......