OBCP第八章 OB运维、监控与异常处理-数据库监控

系统监控视图：系统视图

OceanBase 数据库为多租户架构，租户分为两种类型：普通租户以及 sys 租户。OceanBase 数据库系统表都存储在 sys 租户，且主键中存储租户号（tenant_id），区分每个租户的内容。每个租户内部创建一个该租户数据的只读视图

租户类型	包含系统表类别
SYS租户	核心表 分表位置信息表 模式及用户权限表 DDL 操作相关的表 系统配置相关的表 系统变量及系统状态相关的表 Zone 和服务器等部署相关的系统表 租户、Resource Pool、Unit 相关的系统表
普通租户	以 __tenant 作为表名前缀的只读视图，表示租户内信息其它系统表的视图

状态查询SQL

SQL	说明	注意事项
SELECT * FROM __all_zone	查看zone状态	is_merge_error对应的value是否是0 status是否全为ACTIVE
SELECT ZONE, SVR_IP, STATUS,STOP_TIME FROM __all_server;	查看OBServer状态	status,stop_time 两个字段来标识 OBserver 的状态： stop_time为0时，表示OBServer为started状态， 不为0时，表示OBServer处于stopped状态 status为active时表示OBServer处于正常状态， 为inactive时表示OBServer处于下线状态，为 deleting时表示OBServer正在被删除

磁盘空间查询SQL

SQL	说明	注意事项
SELECT * FROM __all_zone;	查看Zone状态	is_merge_error对应的value是否是0 status 是否全为ACTIVE
SELECT ZONE,SVR_IP,STATUS,STOP_TIME FROM __all_server;	查看OBServer状态	status,stop_time 两个字段来标识 OBserver 的状态： stop_time为0时，表示OBServer为started状态，不为0时，表示OBServer处于stopped状态status为active时表示OBServer处于正常状态，为inactive时表示OBServer处于下线状态，为deleting时表示OBServer正在被删除

磁盘空间查询SQL

SQL	说明	注意事项
select total_size,used_size,free_size svr_ip from __all_virtual_disk_stat;	查询 OceanBase 集群中各 OBServer 的磁盘容量和已使用量	free_size 一般大于800G（根据实际机器配置会有区别）。如果所有server都小于此值，说明集群存储空间不够，应考虑集群扩容
select tenant_id, svr_ip, unit_id, table_id, sum(data_size) /1024/1024/1024 size_G from __all_virtual_meta_table group by 1, 2, 3, 4;	记录了副本信息，可按租户，表统计磁盘空间使用	如果租户某unit磁盘空间占用过大(比如>4TB)应考虑增加租户unit。如果单表磁盘空间占用过大 (比如>200GB)，应考虑对表进行分区。只包含 SSTable磁盘空间，不含memTable内存中数据

历史事件查询SQL

__all_rootservice_event_history和__all_server_event_history分别记录集群级别和OBServer级别的历史事件。可以通过这两张表查询不同事件的信息，下表以查看转储事件为例

 

SQL	说明	注意事项
select* from __all_rootservice_event_history WHERE event LIKE ‘%minor%’ORDER BY gmt_create DESC LIMIT 10;	系统租户从 RootService 角度查看最近10次的转储记录	__all_rootservice_event_history记录集群级事件，如major freeze, 合并，server 上下线，修改primary_zone引发的切主 操作、负载均衡任务执行等，保留 7 天内的数据
SELECT * FROM __all_server_event_history WHERE svr_ip='192.168.100.1' AND module IN ('freeze', 'minor_merge') ORDER BY gmt_create DESC LIMIT 10;	系统租户查看具体某台OBServer 的转储情况	__all_server_event_history 记录server级事件，如转储，用户发起的系统命令，保留 2 天内的数据

机器剩余资源查询SQL

select b.zone, a.svr_ip, a.cpu_total, a.cpu_assigned cpu_ass, a.cpu_assigned_percent
cpu_ass_percent,round(a.mem_total/1024/1024/1024, 2) as mem_total, 
round(a.mem_assigned/1024/1024/1024, 2) mem_ass,round((a.mem_totala.mem_assigned)/1024/1024/1024, 2) as mem_free,a.mem_assigned_percent mem_ass_percent
from __all_virtual_server_stat a,__all_server b where a.svr_ip = b.svr_ip order by zone,cpu_assigned_percent desc;

select zone,
concat(svr_ip, ':', svr_port) observer,
cpu_capacity,
cpu_total,
cpu_assigned,
cpu_assigned_percent,
mem_capacity/(1024*1024*1024) mem_capacity,
mem_total/(1024*1024*1024) mem_total,
mem_assigned/(1024*1024*1024) mem_assigned,
mem_assigned_percent,
unit_Num,
round('load', 2) 'load',
round('cpu_weight', 2) 'cpu_weight',
round('memory_weight', 2) 'mem_weight',
leader_count
from __all_virtual_server_stat
order by zone, svr_ip;

如果某个zone中所有server的某项指标(cpu_ass_percent, mem_ass_percent) 都比较高(>90)，后续加租户或扩租户资源可能会因资源不够失败，可考虑集群扩容

系统性能视图：gv$memory

gv$memory展示当前租户在所有OBServer上各个模块的内存使用情况，基于__all_virtual_memory_info创建

字段名称	类型	说明
CONTEXT	varchar(256)	内存所属Mod名称
COUNT	bigint(20)	当前该 Mod 使用中的内存单元个数
USED	bigint(20)	Mod当前使用的内存数值，单位：Byte
ALLOC_COUNT	bigint(20)	该Mod申请的内存总个数
FREE_COUNT	bigint(20)	该Mod释放的内存总个数

系统性能视图：gv$memstore

gv$memstore展示所有服务器上所有租户的MEMTable的内存使用状况，以__all_virtual_tenant_memstore_info创建

select * from gv$memstore;

字段名称	类型	说明
ACTIVE	bigint(20)	当前活跃的MEMTable的内存占用大小
TOTAL	bigint(20)	当前该 Mod 使用中的内存单元个数,包括 active + frozen memstore（Byte）
FREEZE_TRIGGER	bigint(20)	触发 MEMTable 冻结的内存大小（Byte）
MEM_LIMIT	bigint(20)	MEMTable 的内存大小限制（Byte）
FREEZE_CNT	bigint(20)	MEMTable 的冻结次数

系统性能视图：gv$sql_audit

gv$sql_audit视图用于展示所有 Server 上每一次 SQL 请求的来源、执行状态等统计信息。该视图是按照租户拆分的，除了系统租户，其他租户不能跨租户查询

检查特定租户下Top 10的sql执行时间：

select sql_id, query_sql,count(*), avg(elapsed_time), avg(execute_time), avg(queue_time), avg(user_io_wait_time) 
from gv$sql_audit where tenant_id=1002 group by sql_id
having count(*)>1 order by 5 desc limit 10\G

检查特定租户下消耗cpu最多的top sql:

select sql_id, avg(execute_time) avg_exec_time, count(*) cnt, 
avg(execute_time-TOTAL_WAIT_TIME_MICRO) cpu_time
from gv$sql_audit where tenant_id=1002 
group by 1 order by avg_exec_time * cnt desc limit 5;

系统性能视图：gv$sql

gv$sql用于记录所有热更新的 SQL 相关统计信息，记录每个 Plan 上的统计信息，汇总单个 Plan 多次执行的统计信息，每个 Plan 都会在表中有一行。下表对gv$sql部分字段进行简单归类：

字段类别	详细说明
用于定位SQL的字段	[CON_ID : 租户 ID] [SVR_IP : IP 地址] [SVR_PORT : 端口号] [PLAN_ID : 执行计划的 ID] [SQL_ID : SQL 的标识符] [TYPE : SQL 类型，local remote distribute] [SQL_TEXT : SQL 语句文本] [PLAN_HASH_VALUE :执行计划的 Hash 值]
SQL执行时间类统计字段	[FIRST_LOAD_TIME : 第一次执行时间] [LAST_ACTIVE_TIME : 上一次执行时间][AVG_EXE_USEC : 平均执行耗时] [SLOWEST_EXE_TIME : 最慢执行开始时间点][SLOWEST_EXE_USEC :最慢执行消耗时间] [SLOW_COUNT :慢查询次数统计]
SQL执行效率类统计字段	[HIT_COUNT : 命中 Plan Cache 的统计] [PLAN_SIZE : 物理计划占用的内存][EXECUTIONS : 执行次数] [DISK_READS : 读盘次数] [DIRECT_WRITES : 写盘次数] [BUFFER_GETS : 逻辑读次数] [ELAPSED_TIME : 完成总消耗时间] [CPU_TIME : 消耗的 CPU 时间]

系统性能视图：gv$plan_cache_plan_statgv$plan_cache_plan_stat 视图详细记录了当前租户在所有 Server 上的计划缓存中缓存的每一个缓存对象的状态。该表不仅缓存了 SQL 计划对象，也缓存了PL对象（如匿名块、PL Package 以及 PL Function），某些字段只在特定对象下有效

gv$plan_cache_plan_stat记录的信息与gv$sql视图相似，但更加丰富，下表列出一些多出的字段

字段名称	类型	说明
LARGE_QUERYS	bigint(20)	被判断为大查询的次数
DELAYED_LARGE_QUERYS	bigint(20)	被判断为大查询且被丢入大查询队列的次数
DELAYED_PX_QUERYS	bigint(20)	并行查询被丢回队列重试的次数
OUTLINE_ID	bigint(20)	Outline 的 ID，为 -1 表示不是通过绑定 Outline 生成的计划
OUTLINE_DATA	bigint(20)	计划对应的 Outline 信息
TABLE_SCAN	bigint(20)	表示该查询是否为主键扫描
TIMEOUT_COUNT	bigint(20)	超时的次数

系统性能视图：gv$plan_cache_plan_explain

gv$plan_cache_plan_explain视图用于展示缓存在全部的 Server 中的计划缓存中的物理执行计划。

该视图仅支持 get 操作，查询时需要指定 IP、PORT、TENANT_ID、PLAN_ID 字段

select * from gv$plan_cache_plan_stat limit 5\G;

性能监控：常规监测

性能问题应优先通过OCP 管理员入口 ==> 集群入口 ==>性能 监控==> 数据趋势中查看QPS_RT, TPS_RT，大致定位出问题时间点

性能监控：捞取慢SQL

OceanBase中执行时间超过 trace_log_slow_query_watermark (系统参数)的sql，在 OBServer日志中都会打slow query消息

在 OBServer 日志中查找慢 SQL 消息：

fgrep '[slow query]' observer.log |sed -e 's/|/\n/g' | more <--查看日志中所有的 slow query

grep '' observer.log |sed -e 's/|/\n/g' | more <---根据trace_id 查询某个 slow query

参数	说明	默认值
trace_log_query_watermark	设置查询的执行时间阈值，如果查询的执行时间超过该阈值，则被认为是慢查询	100ms

性能监控：捞取慢SQL

[process begin] [query begin] 等方框号内的名称是指SQL执行经过的每一个内部模块

trace_id与gv$sql_audit里的trace_id字段对应\

stmt是指执行的SQL

u代表每一步消耗的时间，单位是微秒

total_timeu是指整个过程消耗的总时间

性能监控：捞取慢SQL

OceanBase提供两张虚拟表 v$sql_audit , gv$sql_audit记录最近一段时间sql执行历史

v$sql_audit 存储本机的sql执行历史， gv$sql_audit存储整个集群的sql执行历史

查询v$sql_audit表，如查询某租户执行时间大于1s的SQL：

select * from v$sql_audit where tenant_id = 
and elapsed_time > 1000000 limit 10;

 查询SQL执行时间按秒分布的直方图：

select round(elapsed_time/1000000), count(*) from v$sql_audit
where tenant_id =  group by 1;

性能监控：捞取慢SQL

OBProxy有自己的慢查询日志打印功能，通过设置OBProxy的配置项控制打印到日志中的SQL或事务的处理时间阈值；根据实际需求修改OBProxy配置项：

ALTER PROXYCONFIG SET slow_transaction_time_threshold='100ms';
ALTER PROXYCONFIG SET slow_proxy_process_time_threshold='5ms';

参数	说明	默认值
slow_transaction_time_threshold	指慢查询或事务的整个生命周期的s时间阈值，超过了该时间，就会打印相关日志	5s
slow_proxy_process_time_threshold	在发往 Server 前 Proxy 本身的处理时间，包括获取集群信息、路由信息、黑名单信息等	2ms
slow_query_time_threshold	指从OBProxy获取 SQL直到返回给客户端之前的这段时间的阈值，超过了该时间，也会打印相关日志	500ms

OBProxy慢查询举例

修复慢SQL

创建索引：当慢SQL因无合适索引可用时导致时，可创建索引

outline绑定：如慢SQL由OceanBase优化器选择了不够优的执行计划导致，可通过outline绑定执行计划。有两种方式创建outline：

通过 SQL_TEXT创建（用户执行的带参数的原始语句）

通过 SQL_ID 创建

CREATE [OR REPLACE] OUTLINE outline_name ON stmt [TO target_stmt]; //SQL_TEXT方式
CREATE OUTLINE outline_name ON sql_id USING HINT hint; //SQL_ID方式