KES的版本与license有效期
简单而又会产生灾难性的问题
使用version函数查看KES版本信息
test=# select version();
查看license有效期
test=# select get_license_validdays();
服务器的时区和时间
查看KES服务器的时区
test=# show timezone;
test=# show time_zone;
#两者皆可
查看KES服务器的时间
test=# select now(); //查询至时间戳
test=# select current_timestamp; //查询至时间戳
test=# select sysdate; //查询至时间
test=# select current_date; //查询至日期
启动时间与运行时长
查看数据库实例启动时间
test=# select sys_postmaster_start_time();
查看KES无故障运行时长
test=# select date_trunc('second', current_timestamp -sys_postmaster_start_time()) as uptime;
查看最近一次加载参数文件的时间
test=# select sys_conf_load_time();
空间占用情况
查看数据库列表
1、使用ksql的参数-l
[kingbase@node1 ~]$ ksql -dtest -Usystem -l
使用元命令\l
test=# \l
2、使用数据字典
test=# select datname from sys_database;
查看数据库占用的磁盘空间
1、统计当前数据库占用的磁盘空间
test=# select sys_database_size(current_database())/1024/1024 || 'MB'MB;
2、统计所有数据库占用的磁盘空间总量
test=# select (sum(sys_database_size(datname))/1024/1024) || 'MB' MB from sys_database;
-[ RECORD 1 ]-------------
mb | 64.3183355331420898MB
查看表和索引的大小
1、统计表的空间占用
sys_size_pretty这个函数可以将字节大小转换成人类可读的模式，sys_relation_size函数返回的是表的物理磁盘的大小，”||“用于拼接多个字符
这里将"select sys_relation_size(‘t01’)"返回的结果除以1024，然后在将其和kb拼接起来
test=# select sys_relation_size('t01')/1024 || 'kb' kb;
test=# select sys_size_pretty(sys_relation_size('public.t01'));
2、统计表和与表关联的索引占用空间总量
使用sys_total_relation_size函数
test=# select sys_total_relation_size('t01')/1024 || 'kb' kb;
test=# select sys_size_pretty(sys_total_relation_size('t01'));
3、统计表的记录数
test=# select count(*) || 'rows' "rows" from t01;
数据库的连接信息
在巡检过程中，如在docker下部署KES数据库
查看当前登录数据库的名称
test=# select current_catalog;current_catalog
-----------------test
(1 行记录)
test=# select current_database();current_database
------------------test
(1 行记录)
查看当前会话信息
1、查看当前会话的客户端IP和端口
test=# select inet_client_addr(),inet_client_port();inet_client_addr | inet_client_port
------------------+------------------192.168.40.111 | 14346
(1 行记录)
2、查看服务器的IP和端口
test=# select inet_server_addr(),inet_server_port(); inet_server_addr | inet_server_port
------------------+------------------192.168.40.111 | 54321
(1 行记录)
3、查看当前会话的后台进程ID
test=# select sys_backend_pid(); //查看sys_backend_pid
-----------------23134
(1 行记录)
test=# \! ps aux | grep 23134 | grep -v grep //验证
kingbase 23134 0.0 0.5 735144 20812 ? Ss 16:27 0:00 kingbase: system test 192.168.40.111(14350) idle
查看数据库中的连接信息
从sys_stat_activity表中查询datname,usename,client_addr,client_port这几个字段
test=# select datname,usename,client_addr,client_port from sys_stat_activity;datname | usename | client_addr | client_port
---------+---------+----------------+-------------| | | | system | | | system | | test | system | 192.168.40.111 | 14350| | | | | | | | |
(7 行记录)
查看会话执行的SQL信息
1、确认参数track_activities值为on
test=# show track_activities ;track_activities
------------------on
(1 行记录)
2、只看正在运行的SQL信息
查看状态(state)为非idle的状态
test=# select datname,usename,query,state from sys_stat_activity where state not like 'idle%';
-[ RECORD 1 ]------------------------------------------------------------------------------------
datname | test
usename | system
query | select datname,usename,query,state from sys_stat_activity where state not like 'idle%';
state | active
查看耗时较长的SQL
原理是查询当前的时间减去开始的时间(query_start)，通过在sys_stat_activity视图中查询current_timestamp字段得到当前的时间
where state != ‘idle’ 要求状态不是在线
order by 1 desc 为降序排列
test=# select current_timestamp - query_start as runtime,datname,usename,pid,query
test-# from sys_stat_activity
test-# where state != 'idle'
test-# order by 1 desc;
-[ RECORD 1 ]-----+------------------------------
current_timestamp | 2024-11-07 16:54:30.396887+08
实验1：事务阻塞会话的简单处理
会话1----实验准备
1、使用system用户登录数据库test
[kingbase@node1 ~]$ ksql test system
2、为保证实验不受影响，先删除t01数据库(使用不会报错的方式删除)
test=# drop table if exists t01;
注意: 表 "t01" 不存在
DROP TABLE
3、创建表t01，字段为id和name，字段类型分别为int和text
test=# create table t01(id int,name text);
CREATE TABLE
4、向表t01中插入数据(1,‘a’)、(2,‘b’)和(3,‘c’)
test=# insert into t01 values (1,'a');
INSERT 0 1
test=# insert into t01 values (2,'b');
INSERT 0 1
test=# insert into t01 values (3,'c');
INSERT 0 1
5、查看当前是否有事务在运行
test=# commit;
警告: 没有事物在运行中
COMMIT
会话1-----关闭自动提交、删除记录
1、查看当前会话后台进程ID
test=# select sys_backend_pid();sys_backend_pid
-----------------23274
(1 行记录)
2、将自动提交关闭
就是将AUTOCOMMIT给关闭掉，因为KES数据库默认是开启自动提交的
test=# \set AUTOCOMMIT off
3、删除表t01中id为1的那行数据
test=# delete from t01 where id=1;
DELETE 1
会话2-----做与会话1同样的操作，结果：发生锁等待事件
锁等待产生的原因：会话1和会话2都删除了表t01中的id=1的行
如果会话1长时间没有去提交这个事务，会话2就没有办法执行，那么会话2就会去找DBA(数据库管理员)，寻求怎么解决
DBA会处理这件事情，如何处理呢？通过sys_stat_activity来查看test的状态
通过观察wait_event_type等待的类型是不是产生一些事件，导致会话2没有办法进行
查看会话2的状态下wait_event_type是否为Lock
如果为Lock，会导致锁不上这条记录，只有锁上这条记录才能操作。所以此时是无法操作的
这时就要对会话1进行kill的处理
1、另外开启一个会话，使用system用户登录数据库test
[kingbase@node1 ~]$ ksql test system
2、查询当前会话的后台进程ID
test=# select sys_backend_pid();sys_backend_pid
-----------------23527
(1 行记录)
3、关闭自动提交
test=# \set AUTOCOMMIT off
4、删除表t01中id为1的那行数据
执行完下述命令时，就会发现会话2不动了，这就产生了锁等待事件
test=# delete from t01 where id=1;
会话3-----查询会话状态
1、打开横向输出
\x
2、查看当前会话登录后台进程ID
test=# select sys_backend_pid();
-[ RECORD 1 ]---+------
sys_backend_pid | 23636
3、查看sys_stat_activity视图中关于test的内容
通过观察会话1、2、3的状态，可以在各个会话中wait_event_type和wait_event中看出会话1和会话2都是异常的，会话三是正常的
wait_event_type为Client表示等待事件，通常由客户端触发；wait_event_type为Lock表示锁状态
wait_event为ClientRead表示系统正在从客户端读取数据，wait_event为transactionid表示系统正在等待特定事务ID完成相关操作或资源释放
test=# select * from sys_stat_activity where datname='test';
会话3-----清理导致阻塞的会话(杀掉会话1)，最重要
使用sys_terminate_backend(会话1ID)函数来kill掉会话1
test=# select sys_terminate_backend(23274);
-[ RECORD 1 ]---------+--
sys_terminate_backend | t
当我们执行完上述这一条kill会话1的命令，与此同时，会话2的锁等待事件也消失了，因为这个时候，delete表t01那行数据已经被释放掉了
会话2–会话1被断开(事务自动回滚)
1、确认：会话2由锁等待状态转为正常状态
通过pid的对比可以看到原先的会话2变成了现在的会话1
test=# select * from sys_stat_activity where datname='test';
2、在原先的会话1任意执行一个命令，由此可以看出该会话被断开
test=# \l
致命错误: 由于管理员命令中断联接
服务器意外地关闭了联接这种现象通常意味着服务器在处理请求之前
或者正在处理请求的时候意外中止
小结
KES中取消一条运行时间很长的SQL语句是"sys_cancel_backend"
注：
1、sys_cancel_backend：取消指定会话当前正在执行的SQL操作，会话还存在，回滚未提交事务
2、sys_terminate_backend：中断指定会话，回滚未提交事务
sys_stat_activity系统表
1、可以看到连接的状态信息
2、可以看到连接执行的SQL语句文本，以及过去所执行的SQL语句
3、可以看到事务开始的时间
这个实验主要是记住几个函数和系统视图及其功能
sys_stat_activity：系统视图，这里面有数据库中所有会话的状态信息
sys_backend_pid()：用于会话ID的函数
命错误: 由于管理员命令中断联接
服务器意外地关闭了联接
这种现象通常意味着服务器在处理请求之前
或者正在处理请求的时候意外中止