本文分享自华为云社区《[GaussDB(DWS) SQL进阶之PLSQL（二）-游标](https://bbs.huaweicloud.com/blogs/330535?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=ei&utm_content=content)》，作者： xxxsql123 。 # 前言 游标是一种数据处理方法，提供了在查询结果集中进行逐行遍历浏览数据的方法，也可以将游标当做上下文区域的句柄或者指针，借助游标对指定位置的数据进行查询与处理，本章我们主要聚焦于GaussDB(DWS)存储过程中的游标使用。 # 显式游标 显示游标主要用于处理存储过程中的查询结果集是游标常用的用法，具体分为如下几个步骤： # Step 1 定义游标： ## 静态游标定义： 即定义一个游标名以及与其相对应的SELECT语句 语法图：  示例如下： ``` --在存储过程的DECLARE中声明游标定义 CURSOR C1 IS SELECT section_name, place_id FROM hr.sections WHERE section_id = 50; CURSOR C2(sect_id INTEGER) IS SELECT section_name, place_id FROM hr.sections WHERE section_id = sect_id; ``` ## 动态游标定义： 即ref游标，可以通过静态的SQL语句在合适的时候动态的打开游标。先定义ref游标类型，后面通过open for动态绑定SELECT语句 语法图：  示例如下： ``` --在存储过程的DECLARE中声明游标定义 TYPE CURSOR_TYPE IS REF CURSOR; ``` 同时GaussDB(DWS)做了Oracle兼容，支持sys_refcursor动态游标类型，函数或存储过程可以通过sys_refcursor参数传入或传出游标结果集合，函数也可以通过返回sys_refcursor来返回游标结果集合。 语法图：  示例如下： ``` --在存储过程的DECLARE中声明游标定义 C1 SYS_REFCURSOR; ``` # Step 2 打开游标： ## 静态游标打开： 即执行游标对应的SELECT语句，将结果集放入工作区，将游标的指针指向工作区的起始位置。 语法图：  示例如下： ``` --在存储过程的BODY中打开游标 OPEN C1; OPEN C2(10); ``` ## 动态游标打开： 通过OPEN FOR语句打开动态游标，通过USING对SELECT语句进行动态绑定。 语法图：  示例如下： ``` --在存储过程的BODY中打开游标 SQL_STR := 'SELECT section_name, place_id FROM hr.sections WHERE section_id = :DEPT_NO;'; OPEN C3 FOR SQL_STR USING 50; ``` # Step 3 提取游标数据： 即提取游标指针指向的数据 语法图：  示例： ``` --在存储过程的BODY中执行 FETCH C3 INTO DEPT_NAME, DEPT_LOC; ``` # Step 4 循环处理游标数据： 提取数据后可以基于存储过程的语句灵活发挥 例如，给工资低于3000的员工增加500块钱工资 ``` --在存储过程的BODY中执行 LOOP FETCH C INTO V_EMPNO, V_SAL; EXIT WHEN C%NOTFOUND; IF V_SAL=3000 THEN UPDATE hr.staffs_t1 SET salary =salary + 500 WHERE staff_id = V_EMPNO; END IF; END LOOP; ``` # Step 5 关闭游标： 在处理完游标的数据后，应及时释放游标，以便释放游标所占用系统资源，游标关闭后工作区将变成无效，不能再使用FETCH语句获取其中数据。关闭后的游标可以使用OPEN语句重新打开。 语法图：  ``` --在存储过程的BODY中执行 CLOSE C1;--关闭游标 ``` # 游标属性 我们可以通过游标的属性来了解当前游标的状态。下面将介绍4中游标属性： ※ %FOUND布尔型属性：当最近一次读记录时成功返回，则值为TRUE。 ※ %NOTFOUND布尔型属性：与%FOUND相反。 ※ %ISOPEN布尔型属性：当游标已打开时返回TRUE。 ※ %ROWCOUNT数值型属性：返回已从游标中读取的记录数。 示例： ``` OPEN C1;--打开游标 LOOP --通过游标取值 FETCH C1 INTO DEPT_NAME, DEPT_LOC; EXIT WHEN C1%NOTFOUND; DBMS_OUTPUT.PUT_LINE(DEPT_NAME||'---'||DEPT_LOC); END LOOP; CLOSE C1;--关闭游标 ``` 接下来我们将结合前面所学习的知识，在存储过程运用显示游标。 数据准备： ``` CREATE SCHEMA hr; SET CURRENT_SCHEMA = 'hr'; DROP TABLE IF EXISTS sections; CREATE TABLE sections(section_id INT, section_name VARCHAR(100), place_id NUMBER(4)) DISTRIBUTE BY HASH(section_id); INSERT INTO sections VALUES (1, 'section_name1', 1),(2, 'section_name2', 2),(3, 'section_name3', 3); ``` 显示游标使用示例： ``` --游标参数的传递方法。 CREATE OR REPLACE PROCEDURE cursor_proc1() AS DECLARE DEPT_NAME VARCHAR(100); DEPT_LOC NUMBER(4); --定义游标 CURSOR C1 IS SELECT section_name, place_id FROM hr.sections WHERE section_id = 50; CURSOR C2(sect_id INTEGER) IS SELECT section_name, place_id FROM hr.sections WHERE section_id = sect_id; TYPE CURSOR_TYPE IS REF CURSOR; C3 CURSOR_TYPE; SQL_STR VARCHAR(100); BEGIN OPEN C1;--打开游标 LOOP --通过游标取值 FETCH C1 INTO DEPT_NAME, DEPT_LOC; EXIT WHEN C1%NOTFOUND; DBMS_OUTPUT.PUT_LINE(DEPT_NAME||'---'||DEPT_LOC); END LOOP; CLOSE C1;--关闭游标 OPEN C2(10); LOOP FETCH C2 INTO DEPT_NAME, DEPT_LOC; EXIT WHEN C2%NOTFOUND; DBMS_OUTPUT.PUT_LINE(DEPT_NAME||'---'||DEPT_LOC); END LOOP; CLOSE C2; SQL_STR := 'SELECT section_name, place_id FROM hr.sections WHERE section_id = :DEPT_NO;'; OPEN C3 FOR SQL_STR USING 50; LOOP FETCH C3 INTO DEPT_NAME, DEPT_LOC; EXIT WHEN C3%NOTFOUND; DBMS_OUTPUT.PUT_LINE(DEPT_NAME||'---'||DEPT_LOC); END LOOP; CLOSE C3; END; / CALL cursor_proc1(); DROP PROCEDURE cursor_proc1; ``` 执行结果： ``` postgres=# CALL cursor_proc1(); section_name3---3 section_name1---1 section_name2---2 section_name1---1 section_name2---2 section_name3---3 section_name1---1 section_name2---2 section_name3---3 cursor_proc1 -------------- (1 row) ``` SYS_REFCURSOR游标示例： ``` --SYS_REFCURSOR类型做为函数参数 CREATE OR REPLACE PROCEDURE proc_sys_ref(O OUT SYS_REFCURSOR) IS C1 SYS_REFCURSOR; BEGIN OPEN C1 FOR SELECT section_ID FROM HR.sections ORDER BY section_ID; O := C1; END; / DECLARE C1 SYS_REFCURSOR; TEMP NUMBER(4); BEGIN proc_sys_ref(C1); LOOP FETCH C1 INTO TEMP; DBMS_OUTPUT.PUT_LINE(C1%ROWCOUNT); EXIT WHEN C1%NOTFOUND; END LOOP; END; / --删除存储过程 DROP PROCEDURE proc_sys_ref; ``` 执行结果： ``` postgres=# DECLARE postgres-# C1 SYS_REFCURSOR; postgres-# TEMP NUMBER(4); postgres-# BEGIN postgres$# proc_sys_ref(C1); postgres$# LOOP postgres$# FETCH C1 INTO TEMP; postgres$# DBMS_OUTPUT.PUT_LINE(C1%ROWCOUNT); postgres$# EXIT WHEN C1%NOTFOUND; postgres$# END LOOP; postgres$# END; postgres$# / 1 2 3 3 ANONYMOUS BLOCK EXECUTE ``` # 隐式游标 对于非SELECT语句，例如UPDATE，DELETE操作，系统会自动的未这些操作设置游标，这些有系统隐含创建的游标即隐式游标。隐式游标的定义，打开，取值，关闭操作均有系统自动的完成，无需用户进行处理，用户只能通过隐式游标的相关属性完成相应的操作。 隐式游标属性： ※ SQL%FOUND布尔型属性：当最近一次读记录时成功返回，则值为TRUE。 ※ SQL%NOTFOUND布尔型属性：与%FOUND相反。 ※ SQL%ROWCOUNT数值型属性：返回已从游标中读取得记录数。 ※ SQL%ISOPEN布尔型属性：取值总是FALSE。SQL语句执行完毕立即关闭隐式游标。 隐式游标示例如下： ``` --删除EMP表中某部门的所有员工，如果该部门中已没有员工，则在DEPT表中删除该部门。 CREATE TABLE hr.staffs_t1 AS TABLE hr.staffs; CREATE TABLE hr.sections_t1 AS TABLE hr.sections; CREATE OR REPLACE PROCEDURE proc_cursor3() AS DECLARE V_DEPTNO NUMBER(4) := 100; BEGIN DELETE FROM hr.staffs WHERE section_ID = V_DEPTNO; --根据游标状态做进一步处理 IF SQL%NOTFOUND THEN DELETE FROM hr.sections_t1 WHERE section_ID = V_DEPTNO; END IF; END; / CALL proc_cursor3(); --删除存储过程和临时表 DROP PROCEDURE proc_cursor3; DROP TABLE hr.staffs_t1; DROP TABLE hr.sections_t1; ``` 以上就是在GuassDB(DWS)的存储过程中游标的基本使用。 # 总结 GuassDB(DWS)的游标使用在postgresql的基础上做了对Oracle的语法兼容，存储过程中的游标功能对于原来依赖Oracle的系统可以平滑的迁移。同时由于GuassDB(DWS)是分布式架构，和postgresql本身以及GuassDB(DWS)的单机模式上游标的行为细节上会略有不同，例如事务中的DECLARE CURSOR由于分布式和单机的实现差异导致在pg_cursors视图查询结果差异等。

【功能模块】  SQL功能【操作步骤&问题现象】1、编写SQL2、报错，见报错截图一补充说明，T1、T2、这2张表都有数据，且这2张表的数据都能关联上。再经过测试，发现T1表带上where条件就会报错（不带where条件能正常查询），见报错截图二【截图信息】报错截图一报错截图二【日志信息】（可选，上传日志内容或者附件）

【功能模块】安装FI平台时，备manager时报错【操作步骤&问题现象】主节点已安装上并能web访问管理节点了。执行备manager安装时：  ./install.sh -f /opt/FusionInsi......../software/备节点IP.ini 安装报错如下：=== STEP 2 Preparing for installation components.                  [done]=== STEP 3 Installing the manager.                                          [fail]ERROR:Installation failed. For details about the error, see the log file /var/log/Bigdata/controller/scriptlog/install.log.      Please run the following script to delete useless files:      /opt/huawei/Bigdata/om-server/om/inst/uninstall.sh具体明细：cat   /var/log/Bigdata/contro........./install log：Install OS optimization successfully.ERROR:Failed to initialize home directory.ERROR:Failed to initialize the node agent.[2022-05-18 14:06:51] ERROR Failed to install agent for OMS node. [install.sh(main):2291](195020)ERROR:Failed to install agent for OMS node.[2022-05-18 14:06:51] ERROR Installation failed. For details about the error, see the log file /var/log/Bigdata/controller/scriptlog/install.log. [install.sh(post_install):545](177408)截图如下示：下图两个终端都是备manager的交互界面。左边：安装过程；    右边：一直tail -f 跟踪安装的日志，报错具体信息如红圈所示。【截图信息】【日志信息】（可选，上传日志内容或者附件）

【DWS】【vacuum功能】行存分区表，对单分区做vacuum full操作是否锁整表？

近期，华为云GaussDB(for Redis)缓存数据库再次推出全新版本，携新特性重磅来袭！GaussDB(for Redis)是华为云推出的企业级分布式KV数据库，它完全兼容Redis协议，提供丰富的数据类型，基于云原生存储计算分离架构，在成本、可靠性等方面为企业带来全新价值。 本次GaussDB(for Redis)推出的全新特性，不仅对基础性能和连接管理等进行了大幅优化，同时突破开源Redis短板，实现增强版前缀搜索和集群版多租隔离功能，前缀搜索时延较开源Redis降低千倍，为助力企业业务发展带来了更多可能。关键特性1：增强版前缀扫描，千倍性能提升GaussDB(for Redis)推出的增强版前缀扫描功能，优化了String、Hash、Set、Zset四种数据类型scan的前缀搜索。GaussDB(for Redis)的SCAN、HSCAN、SSCAN、ZSCAN命令在使用方法上与开源Redis完全兼容，但前缀匹配模式的性能更为优秀，从开源的耗时O(N)优化到O(logN + M)（其中N是整体数据量，M是匹配的数据量）。下面根据某客户实际场景，对比GaussDB(for Redis)和开源Redis的性能：数据：500w个key，均为String，范围为“1”~“5000000”， value大小为100B。命令：Scan 0 Match 499999* Count 100。在500w个key中搜索11个key。结果：开源Redis为7.67s ，GaussDB(for Redis)仅为2.92ms，快了2600倍，且开源Redis在返回搜索结果前返回了4.98w+次的空结果，而GaussDB(for Redis)第一次就返回了搜索结果。开源Redis：GaussDB(for Redis)：在互联网业务中，诸如批量查找/删除一批相同前缀的key是很常见的业务场景，在上百万的数据量下，开源Redis的秒级时延显然是不可接受的。GaussDB(for Redis)针对这一场景进行了有效优化，将时延降低上千倍至毫秒级，带来了极致的性能体验。关键特性2：多租隔离，集群版业务数据隔离能力GaussDB(for Redis) 提供的多租隔离功能，允许用户为不同的业务创建不同的DB，实现不同业务数据隔离。使用方法上，GaussDB(for Redis)的多租隔离功能与开源Redis单机版本的多DB用法保持完全兼容（开源Redis集群版本不支持多DB）。用户可以通过SELECT DB来切换/新建不同的DB给不同的业务使用，通过FLUSHDB删除一个DB中的全部数据而不影响其他DB，从而高效地实现多租隔离效果。GaussDB(for Redis)多DB实现业务多租隔离GaussDB(for Redis)的多DB核心价值在于：集群版多DB：GaussDB(for Redis)集群版本可支持多DB；开源Redis的“多DB”只能用于单机，不支持集群。大规模多DB：GaussDB(for Redis)单实例支持65536个DB，搞定多业务多租隔离。高扩展性：开源Redis单机扩容到64G已经是极限，更不用说fork导致的容量利用率只有50%。GaussDB(for Redis)吞吐可水平扩展至百万QPS，容量支持12TB，解决了扩展性问题。低成本：GaussDB(for Redis)相比开源Redis，成本可降20%~70%。多租隔离是数据库的必备功能，在实际业务场景中，不同模块共享同一Redis实例是很常见的需求。GaussDB(for Redis)超越开源Redis，支持集群版本下的多DB，依托现有的秒级弹性扩缩容能力，在海量业务压力下仍能为客户提供灵活便捷的业务数据访问控制服务。目前，GaussDB(for Redis)已经凭借出色的产品实力在游戏系统、电商平台、推荐系统、社交媒体、物联网等众多企业级应用场景中发挥出巨大作用，而新推出的增强版前缀扫描与多租隔离两大功能特性，将以更优异的能力使企业在降本的同时实现增效，助力企业高效数字化！连接：https://bbs.huaweicloud.com/blogs/352808

近期，华为云GaussDB(for Redis)缓存数据库再次推出全新版本，携新特性重磅来袭！GaussDB(for Redis)是华为云推出的企业级分布式KV数据库，它完全兼容Redis协议，提供丰富的数据类型，基于云原生存储计算分离架构，在成本、可靠性等方面为企业带来全新价值。 本次GaussDB(for Redis)推出的全新特性，不仅对基础性能和连接管理等进行了大幅优化，同时突破开源Redis短板，实现增强版前缀搜索和集群版多租隔离功能，前缀搜索时延较开源Redis降低千倍，为助力企业业务发展带来了更多可能。关键特性1：增强版前缀扫描，千倍性能提升GaussDB(for Redis)推出的增强版前缀扫描功能，优化了String、Hash、Set、Zset四种数据类型scan的前缀搜索。GaussDB(for Redis)的SCAN、HSCAN、SSCAN、ZSCAN命令在使用方法上与开源Redis完全兼容，但前缀匹配模式的性能更为优秀，从开源的耗时O(N)优化到O(logN + M)（其中N是整体数据量，M是匹配的数据量）。下面根据某客户实际场景，对比GaussDB(for Redis)和开源Redis的性能：数据：500w个key，均为String，范围为“1”~“5000000”， value大小为100B。命令：Scan 0 Match 499999* Count 100。在500w个key中搜索11个key。结果：开源Redis为7.67s ，GaussDB(for Redis)仅为2.92ms，快了2600倍，且开源Redis在返回搜索结果前返回了4.98w+次的空结果，而GaussDB(for Redis)第一次就返回了搜索结果。开源Redis：GaussDB(for Redis)：在互联网业务中，诸如批量查找/删除一批相同前缀的key是很常见的业务场景，在上百万的数据量下，开源Redis的秒级时延显然是不可接受的。GaussDB(for Redis)针对这一场景进行了有效优化，将时延降低上千倍至毫秒级，带来了极致的性能体验。关键特性2：多租隔离，集群版业务数据隔离能力GaussDB(for Redis) 提供的多租隔离功能，允许用户为不同的业务创建不同的DB，实现不同业务数据隔离。使用方法上，GaussDB(for Redis)的多租隔离功能与开源Redis单机版本的多DB用法保持完全兼容（开源Redis集群版本不支持多DB）。用户可以通过SELECT DB来切换/新建不同的DB给不同的业务使用，通过FLUSHDB删除一个DB中的全部数据而不影响其他DB，从而高效地实现多租隔离效果。GaussDB(for Redis)多DB实现业务多租隔离GaussDB(for Redis)的多DB核心价值在于：集群版多DB：GaussDB(for Redis)集群版本可支持多DB；开源Redis的“多DB”只能用于单机，不支持集群。大规模多DB：GaussDB(for Redis)单实例支持65536个DB，搞定多业务多租隔离。高扩展性：开源Redis单机扩容到64G已经是极限，更不用说fork导致的容量利用率只有50%。GaussDB(for Redis)吞吐可水平扩展至百万QPS，容量支持12TB，解决了扩展性问题。低成本：GaussDB(for Redis)相比开源Redis，成本可降20%~70%。多租隔离是数据库的必备功能，在实际业务场景中，不同模块共享同一Redis实例是很常见的需求。GaussDB(for Redis)超越开源Redis，支持集群版本下的多DB，依托现有的秒级弹性扩缩容能力，在海量业务压力下仍能为客户提供灵活便捷的业务数据访问控制服务。目前，GaussDB(for Redis)已经凭借出色的产品实力在游戏系统、电商平台、推荐系统、社交媒体、物联网等众多企业级应用场景中发挥出巨大作用，而新推出的增强版前缀扫描与多租隔离两大功能特性，将以更优异的能力使企业在降本的同时实现增效，助力企业高效数字化！连接：https://bbs.huaweicloud.com/blogs/352808

GaussDB A 8.1 版本，在创建Function时入参使用的是TYPE类型的参数，生成的函数显示的入参是unknown，不支持Type类型入参么代码：-- Create tablecreate table DM_GTS_PROCESS_LOG_TEST(  object_type        CHAR(1),  object_name        VARCHAR(100),  step_type          VARCHAR(500),  execute_start_time DATE,  execute_end_time   DATE,  execute_duration   VARCHAR(20),  total_count        INTEGER,  status             VARCHAR(10),  log_info           VARCHAR(4000),  remarks            VARCHAR(4000)) WITH (ORIENTATION = ROW)DISTRIBUTE BY HASH (execute_start_time);--创建TYPEcreate TYPE  TYP_GTS_PROCESS_LOG_TEST AS (  object_type        CHAR(1),  object_name        VARCHAR(100),  step_type          VARCHAR(500),  execute_start_time DATE,  execute_end_time   DATE,  execute_duration   VARCHAR(20),  total_count        INTEGER,  status             VARCHAR(10),  log_info           VARCHAR(4000),  remarks            VARCHAR(4000)) ;--写日志的函数CREATE OR REPLACE FUNCTION gts_ioc.sp_dm_gts_process_log_test(v_log_params TYP_GTS_PROCESS_LOG_TEST) RETURNS integer LANGUAGE plpgsql NOT FENCED NOT SHIPPABLEAS $$DECLAREBEGIN     INSERT INTO DM_GTS_PROCESS_LOG_TEST    (OBJECT_TYPE,     OBJECT_NAME,     STEP_TYPE,     EXECUTE_START_TIME,     EXECUTE_END_TIME,     EXECUTE_DURATION,     TOTAL_COUNT,     STATUS,     LOG_INFO,     REMARKS)  VALUES    (V_LOG_PARAMS.OBJECT_TYPE,    V_LOG_PARAMS.OBJECT_NAME,    V_LOG_PARAMS.STEP_TYPE,    V_LOG_PARAMS.EXECUTE_START_TIME,    V_LOG_PARAMS.EXECUTE_END_TIME,    V_LOG_PARAMS.EXECUTE_DURATION,    V_LOG_PARAMS.TOTAL_COUNT,    V_LOG_PARAMS.STATUS,    V_LOG_PARAMS.LOG_INFO,    V_LOG_PARAMS.REMARKS    );        RETURN 1;END$$;

个人无法免费试用，使用？

创建1、首先 是找到使用页面 https://activity.huaweicloud.com/free_test/index.html2、全新注册用户，自行解决。（ps:需要邮箱认证，我的邮箱之前 注册过无法重复注册，原账号找回密码需要很多注册信息。。。，最后用guge的邮箱。。）3、点击0元试用 自动跳转到实例控制台，这里体验很流畅。4、点击实例列表名称进入 实例详情，一个月31天。这里开个玩笑，我买12个月 算31x12 不。。。好了进入主页面，咱们开始 详细的了解 华为云的redis实例详情如何了。二  详情页面详解1、基本信息采用arm架构，维护时间窗口默认帮用户设置了。这也是行业惯例。2、拓扑信息基本的主从架构，实例id 也是默认映射主节点的地址，一会可以连接实例看下支持的命令 和主从连接信息。3、连接信息连接信息访问方式免密访问连接地址redis-87f5d492-8b12-4d6f-9d6e-2984bec7e1af.cn-east-3.dcs.myhuaweicloud.com:6379只读地址redis-87f5d492-8b12-4d6f-9d6e-2984bec7e1af-readonly.cn-east-3.dcs.myhuaweicloud.com:6379IP地址172.31.201.38:6379公网访问查看文档我通过电脑自带的redis-cli 无法连接地址【 redis-87f5d492-8b12-4d6f-9d6e-2984bec7e1af.cn-east-3.dcs.myhuaweicloud.com 】，我以为是白名单的问题。然后在实例配置白名单配置里，设置自己的公网地址。(浏览器输入ip.cn，找到自己的公网地址)，然后添加我的公网ip地址后 依然不可以访问。仔细 一看如下文字所示，也就是 说这里的配置只是vpc内部的连接白名单。所以，url连接不是用来公网访问的，而是用来内部dns定向访问的。比如不同的子网划分，不同的地址映射吧，这样可以无需修改应用的ip地址配置。您还没有添加任何白名单，所有与VPC互通的IP地址均可访问实例。若需要指定的IP地址才能访问，请将这些IP地址加入白名单。那么如何公网访问呢？连接如下，需要自己开一个云主机用nginx的tcp代理来 映射，6379端口，操作指南详见连接    使用Nginx实现公网访问Redis 4.0/5.0的单机/主备/Proxy集群实例_分布式缓存服务 DCS_最佳实践_华为云 (huaweicloud.com)然后返回体验页面 https://activity.huaweicloud.com/free_test/index.html。 这里开始白嫖一个云主机，发现云主机被体验光了。好吧，下一篇博客在细说 通过云主机的redis-cli连接。这里先小结下体验感受：由于我使用过谷歌 和 redislab的kv服务，国内阿里云的kv服务，体验这里给在国内比较给中上评价吧，如果在国际上就比较差了，连接地址和 只读地址 都是无法通过公网连接的。原因如下：redislabs的使用企业版 url连接自动连上，他是自动化的dbaas服务部署是通过调用aws的接口 创建小实例，并且是可以直接公网访问的。阿里的实例是可以自动开公网访问，并且做到了一个url地址既可以公网也可以内网，并且就在实例的详情主页里实例【公网访问】开通一点击就OK，设置完白名单可以很方便通过url了解访问。4、web console体验直接在概览页面右上角点击 【连接Redis】，跳转到 web的console页面。页面很简洁。页面有db信息，并且自动auth成功，推出当前实例定跳转到 实例列表页面。进行简单操作 set hw hwc，info all。回显如下信息set hw hwcOKinfo all# Server redis_version:5.0.14 patch_version:5.0.14.1 redis_git_sha1:00000000 redis_git_dirty:0 redis_build_id:0 redis_mode:standalone os:Linux arch_bits:64 multiplexing_api:epoll atomicvar_api:atomic-builtin gcc_version:0.0.0 process_id:1 run_id:a7b30d214bf934f5a3254a6596f0bd83dd5c850d tcp_port:2407 uptime_in_seconds:2539 uptime_in_days:0 hz:10 configured_hz:10 lru_clock:8266221 executable:redis-server config_file:redis.conf instance_id:87f5d492-8b12-4d6f-9d6e-2984bec7e1af # Clients connected_clients:7 client_recent_max_input_buffer:2 client_recent_max_output_buffer:0 blocked_clients:0 rx_controlled_clients:0 total_real_rx_controlled:0 total_tx_controlled:0 total_rx_controlled:0 proxy_header_error:0 # Memory used_memory:2341624 used_memory_human:2.23M used_memory_rss:9961472 used_memory_rss_human:9.50M used_memory_peak:2464272 used_memory_peak_human:2.35M used_memory_peak_perc:95.02% used_memory_overhead:2300662 used_memory_startup:1082800 used_memory_dataset:40962 used_memory_dataset_perc:3.25% allocator_allocated:2725304 allocator_active:3088384 allocator_resident:19886080 total_system_memory:1081361883136 total_system_memory_human:1007.10G used_memory_lua:37888 used_memory_lua_human:37.00K used_memory_scripts:0 used_memory_scripts_human:0B number_of_cached_scripts:0 maxmemory:268435456 maxmemory_human:256.00M maxmemory_policy:volatile-lru allocator_frag_ratio:1.13 allocator_frag_bytes:363080 allocator_rss_ratio:6.44 allocator_rss_bytes:16797696 rss_overhead_ratio:0.50 rss_overhead_bytes:-9924608 mem_fragmentation_ratio:4.29 mem_fragmentation_bytes:7641792 mem_not_counted_for_evict:106 mem_replication_backlog:1048576 mem_clients_slaves:17042 mem_clients_normal:152066 mem_aof_buffer:106 mem_allocator:jemalloc-5.1.0 active_defrag_running:0 lazyfree_pending_objects:0 # Persistence loading:0 rdb_changes_since_last_save:1 rdb_bgsave_in_progress:0 rdb_last_save_time:1652430851 rdb_last_bgsave_status:ok rdb_last_bgsave_time_sec:0 rdb_current_bgsave_time_sec:-1 rdb_last_cow_size:299008 aof_enabled:1 aof_rewrite_in_progress:0 aof_rewrite_scheduled:0 aof_last_rewrite_time_sec:-1 aof_current_rewrite_time_sec:-1 aof_last_bgrewrite_status:ok aof_last_write_status:ok aof_last_cow_size:0 aof_current_size:53 max_aof_size:1342177280 aof_base_size:0 aof_pending_rewrite:0 aof_buffer_length:0 aof_rewrite_buffer_length:0 aof_pending_bio_fsync:0 total_aof_write_error:0 aof_delayed_fsync:0 # Stats total_connections_received:717 total_commands_processed:15038 instantaneous_ops_per_sec:5 total_net_input_bytes:889498 total_net_output_bytes:8147140 instantaneous_input_kbps:0.41 instantaneous_output_kbps:1.32 rejected_connections:0 sync_full:1 sync_partial_ok:0 sync_partial_err:0 expired_keys:0 expired_stale_perc:0.00 expired_time_cap_reached_count:0 evicted_keys:0 keyspace_hits:0 keyspace_misses:0 pubsub_channels:1 pubsub_patterns:0 latest_fork_usec:432 migrate_cached_sockets:0 slave_expires_tracked_keys:0 active_defrag_hits:0 active_defrag_misses:0 active_defrag_key_hits:0 active_defrag_key_misses:0 # Replication role:master connected_slaves:1 slave0:ip=192.168.30.31,port=3184,state=online,offset=663452,lag=0 master_replid:c07fd7bb03ad6d1628cde2f017a34d22ea8b36d0 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:663629 second_repl_offset:-1 repl_backlog_active:1 repl_backlog_size:1048576 repl_backlog_first_byte_offset:1 repl_backlog_histlen:663629 # CPU used_cpu_sys:1.036002 used_cpu_user:2.197352 used_cpu_sys_children:0.000000 used_cpu_user_children:0.002273 # Commandstats cmdstat_dcs.getBandwidth:calls=2,usec=16,usec_per_call=8.00 cmdstat_publish:calls=3722,usec=21106,usec_per_call=5.67 cmdstat_ping:calls=7298,usec=9439,usec_per_call=1.29 cmdstat_replconf:calls=2536,usec=4751,usec_per_call=1.87 cmdstat_set:calls=1,usec=10,usec_per_call=10.00 cmdstat_command:calls=4,usec=2607,usec_per_call=651.75 cmdstat_client:calls=6,usec=10,usec_per_call=1.67 cmdstat_subscribe:calls=3,usec=11,usec_per_call=3.67 cmdstat_info:calls=1399,usec=109527,usec_per_call=78.29 cmdstat_config:calls=23,usec=428,usec_per_call=18.61 cmdstat_slowlog:calls=43,usec=227,usec_per_call=5.28 cmdstat_psync:calls=1,usec=595,usec_per_call=595.00 # Cluster cluster_enabled:0 # Keyspace db0:keys=1,expires=0,avg_ttl=0在输入 config get * 看看配置信息config get *dbfilename redis.rdb requirepass masterauth cluster-announce-ip unixsocket /opt/redis/redis.sock logfile /var/log/redis.log pidfile /opt/redis/redis.pid slave-announce-ip replica-announce-ip maxmemory 268435456 max-aof-memory-multiplier 5 max-aof-size 1342177280 proto-max-bulk-len 536870912 client-query-buffer-limit 1073741824 maxmemory-samples 5 lfu-log-factor 10 lfu-decay-time 1 timeout 0 active-defrag-threshold-lower 10 active-defrag-threshold-upper 100 active-defrag-ignore-bytes 104857600 active-defrag-cycle-min 5 active-defrag-cycle-max 75 active-defrag-max-scan-fields 1000 auto-aof-rewrite-percentage 0 auto-aof-rewrite-min-size 67108864 hash-max-ziplist-entries 512 hash-max-ziplist-value 64 stream-node-max-bytes 4096 stream-node-max-entries 100 list-max-ziplist-size -2 list-compress-depth 0 set-max-intset-entries 512 zset-max-ziplist-entries 128 zset-max-ziplist-value 64 hll-sparse-max-bytes 3000 lua-time-limit 5000 slowlog-log-slower-than 10000 latency-monitor-threshold 0 slowlog-max-len 128 port 2407 cluster-announce-port 0 cluster-announce-bus-port 0 tcp-backlog 10000 databases 256 repl-ping-slave-period 10 repl-ping-replica-period 10 repl-timeout 60 repl-backlog-size 1048576 repl-backlog-ttl 3600 maxclients 10010 watchdog-period 0 slave-priority 100 replica-priority 100 slave-announce-port 0 replica-announce-port 0 min-slaves-to-write 0 min-replicas-to-write 0 min-slaves-max-lag 10 min-replicas-max-lag 10 hz 10 cluster-node-timeout 15000 cluster-migration-barrier 1 cluster-slave-validity-factor 10 cluster-replica-validity-factor 10 repl-diskless-sync-delay 5 tcp-keepalive 30 incremental-eviction-num 65535 active-expire-num 20 active-expire-cycle-slow-time-perc 25 cluster-require-full-coverage yes cluster-slave-no-failover no cluster-replica-no-failover no no-appendfsync-on-rewrite yes slave-serve-stale-data yes replica-serve-stale-data yes slave-read-only yes replica-read-only yes slave-ignore-maxmemory yes replica-ignore-maxmemory yes stop-writes-on-bgsave-error yes daemonize no rdbcompression no rdbchecksum yes activerehashing yes activedefrag no protected-mode no repl-disable-tcp-nodelay no repl-diskless-sync no aof-rewrite-incremental-fsync yes rdb-save-incremental-fsync yes aof-load-truncated yes aof-use-rdb-preamble yes lazyfree-lazy-eviction yes lazyfree-lazy-expire yes lazyfree-lazy-server-del yes slave-lazy-flush yes replica-lazy-flush yes dynamic-hz yes master-read-only no vpc-endpoint-proxy-header no tenant-sync no enable-write-protection no maxmemory-policy volatile-lru loglevel notice supervised no appendfsync no syslog-facility local0 appendonly yes dir /opt/redis save client-output-buffer-limit normal 0 0 0 slave 26843545 26843545 60 pubsub 33554432 8388608 60 unixsocketperm 600 slaveof notify-keyspace-events xE bind 192.168.36.137使用小结：由于带了控制台功能，那么开云主机的需要就不那么紧要了，客户几乎可以执行所有的可配置的 命令。命令支持的也很全面原文连接：https://bbs.huaweicloud.com/blogs/352815

本文分享自华为云社区《[华为云GaussDB(for Influx)揭秘第八期：GaussDB(for Influx)与开源企业版性能对比](https://bbs.huaweicloud.com/blogs/351732?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)》，作者：高斯Influx官方博客 。 “你们的数据库性能怎么样？” “能不能满足我们的业务？” “和其他数据库对比性能有优势么？” … 客户在使用数据库时常有这样的担心和疑问。 本文从测试方案、测试工具、测试场景、测试结果等方面详细介绍了GaussDB(for Influx)和开源InfluxDB集群在X86架构下的性能测试情况。测试结果显示，GaussDB(for Influx)较企业版InfluxDB集群能提供更高的写入性能、更低的访问延迟以及更高的数据压缩率。 # 1. 测试方案 ## 1.1 资源配置 服务端配置  ## 1.2 测试工具 测试工具为开源性能工具TS-benchMark。 # 2. 测试设计 ## 2.1 测试模型 本次测试采用风力发电数据模型，每个风场50个设备，每个设备50个传感器，1个风场1个线程，通过load数据的线程数来控制时间线的大小，通过收集时间的长短来控制数据量。 模型每条数据大小约为24字节，具体的类型如下： Timestamp | farm | device |sensor | value ## 2.2 测试数据量 测试数据分为两个场景，大数据量和小数据量，具体数据量如下：  >注：企业版InfluxDB在插入到47亿数据时OOM，以下性能对比都基于此数据量。 ## 2.3 测试场景 ### 2.3.1 数据写入场景 - batch_size(每个批次写入的数据量) 固定为50，线程数分别从1、2、4、8、16、32、64、128、256、512 递增； - 线程数（客户端并发请求的连接数）固定为8， batch_size分别从50、100、150、200、250、300 递增。 ### 2.3.2 数据查询场景 单线程进行不同语句的查询，并统计其时延信息。 **第一类查询： 所有TAG查询** ```mysql select * from sensor where f='f1' and d='d2' and s='s1' and time>=1514768400000000000 and time=1514772000000000000 ``` **第二类查询： TAG + VALUE查询** ```mysql select * from sensor where f='f1' and s='d2' and value>=3.0 and time>=1514768400000000000 and time1514854800000000000 ``` **第三类查询： 聚合查询** ```mysql select mean(value) from sensor where f='f1' and s='s1' and time>=1514768400000000000 and time=1514854800000000000 group by f,d,s,time(1h) ``` **第四类查询： 或条件查询** ```mysql select * from sensor where f='f1' and (s='s1' or s='s2' or s='s3' or s='s4' or s='s5') and time>=1514768400000000000 and time=1514769150000000000 ``` **第五类查询： 单个TAG查询** ```mysql select * from sensor where f='f1' and time>=1514768400000000000 and time=1514769150000000000 ``` # 3. 测试结果分析 ## 3.1 写入吞性能比对 在小数据量场景下，GaussDB(for Influx)的写入性能是企业版InfluxDB的13倍左右，在大数据量的场景下可以达到1.8倍左右。  ## 3.2 查询性能对比 1）第一类查询（所有TAG查询）：无论是大数据量还是小数据量场景下，GaussDB(for Influx)的吞吐量是开源InfluxDB企业版的2倍左右。  2）第二类查询（TAG + VALUE查询）：在小数据量场景下，开源InfluxDB企业版性能高于GaussDB(for Influx)，GaussDB(for Influx)在大数据量和小数据量场景下性能基本持平。  3）第三类查询（聚合查询）：GaussDB(for Influx)查询性能明显优于开源InfluxDB企业版，在小数据量场景下是开源版本的14倍，大数据量下也是开源版本的8倍左右。  4）第四类查询（或条件查询）：GaussDB(for Influx)查询性能在两种场景下比较稳定，开源企业版InfluxDB在两种场景下差异较大；GaussDB(for Influx)在小数据量场景下表现优于开源版，在大数据量场景下低于开源版。  5）第五类查询（单个TAG查询）：GaussDB(for Influx)查询性能在两种场景下比较稳定，在大数据量场景下低于开源版。  ## 3.3 数据压缩率对比 在250万时间线场景下，GaussDB(for Influx)导入了151亿条数据，导入前数据大小为337.5G，导入后为49.8G，压缩率为6.8；开源企业版导入了47亿条数据，导入前105G，导入后21.3G，压缩率为4.9。GaussDB(for Influx)压缩率是开源企业版的1.4倍左右。 Influx引擎采用LSM tree架构，随着后台compaction的进行，压缩率会进一步提升，当前数据对比是数据刚导入时的结果。 # 4. 总结 在GaussDB(for Influx)2节点对比开源版3节点场景下，GaussDB(for Influx)给客户带来了更高的写入能力、更稳定的查询能力、更高的压缩率。GaussDB(for Influx)写入能力在小数据量场景下是开源企业版的13倍，在大数据量场景下是开源企业版的1.8倍；查询能力在两种场景下表现稳定，在大部分查询场景下优于开源企业版；在压缩率方面，同样数据模型下，高出开源版本40%。 除了以上优势外，GaussDB(for Influx)还在集群化、冷热分级存储、高可用方面也做了深度优化，能更好地满足时序应用的各种场景。

本文分享自华为云社区《[互联网用户画像，精准营销，GaussDB(DWS)来支招](https://bbs.huaweicloud.com/blogs/349748?utm_source=csdn&utm_medium=bbs-ex&utm_campaign=ei&utm_content=content)》，作者： fudgefactor。 目前在互联网、教育、游戏等行业都有实时精准营销的需求。通过系统生成用户画像，在营销时通过条件组合筛选用户，快速提取目标群体。例如： - 在电商行业中，商家在进行营销活动前，需要根据活动的目的，圈选一批满足特定特征的目标用户群体进行广告推送。 - 在教育行业中，需要根据学生不同的特征，推送有针对性的练习题目，帮助学生查漏补缺。 - 在搜索、视频、门户网站中，根据用户关注的热点，推送不同的内容。 这些业务场景都有一些共同的特点： - 数据量庞大，运算量极大。 - 用户规模庞大，标签多，字段多，占用存储空间也多。 - 圈选的特征条件多样化，很难找到固定索引，如果每个字段一个索引，存储空间又会暴增。 - 性能要求高，因为实时营销要求秒级响应。 - 数据更新时效要求高，用户画像几乎要求实时更新。 针对上述业务场景特点，GaussDB(DWS)的roaringbitmap可以高效生成、压缩、解析位图数据，支持最常见的位图聚合操作（与、或、非、异或），满足用户在亿级以上用户、千万级标签的大数据量下实时精准营销、快速圈选用户的需求。 下面先通过两个示例来理解Roaringbitmap在用户画像场景中的使用方法。 # 示例一： 假设有一张用户浏览网页的流水信息表userinfo，表中的字段如下： ```mysql CREATE TABLE userinfo (userid int, age int, gender text, salary int, hobby text )with (orientation=column); ``` userinfo表中的数据会随着用户信息的变化不断增长，同时，如果用户有多个"爱好"(hobby)，那么就有多条记录对应同一个userid。 假设要筛选出所有“收入大于10000元的男性，年龄大于30岁，爱好钓鱼”的群体，向这些目标群体推送特定的消息。 传统的方法是直接在原表上执行查询，语句如下： ```mysql select distinct userid from userinfo where salary > 10000 and age > 30 and gender ='m' and hobby ='fishing'; ``` 当userinfo表的数据量不大的时候，可以通过在salary, age, gender，hobby列上建立索引来满足需求。但是如果userinfo表的数据量非常大，同时一张表的标签数非常多（比如有100个属性，需要对应有100个列）的时候，上述语句就不能满足诉求，因为如下原因： - 由于不确定会按照那些属性做过滤，需要创建的索引会非常多。 - 求distinct的性能比较差。 **这种场景下使用roaringbitmap就会有比较好的效果。** 新建一张Roaringbitmap表： ```mysql CREATE TABLE userinfoset ( age int, gender text, salary int, hobby text, userset roaringbitmap, PRIMARY KEY(age,gender,salary,hobby) )with (orientation=column); ``` 2. 所有userinfo表中的数据要通过标签列聚合到userinfoset表中。可以采用对全量数据进行聚合的方法（如下命令所示）。 ```mysql insert into userinfoset us select age, gender, salary, hobby, rb_build_agg(userid) from userinfo group by age, gender, salary, hobby; ``` 3. 直接查询userinfoset表获得用户筛选信息。 ```mysql select rb_iterate(rb_or_agg(userset)) from userinfoset where salary > 10000 and age > 30 and gender ='m' and hobby ='fishing'; ``` 数据进行聚合后的userinfoset的数据量相比源表小了很多，基表scan的性能会快很多，同时基于Roaringbitmap的优势，计算rb_or_agg和rb_iterate的性能也很好，相比传统的方法，性能明显提升。 # 示例二： 由于DWS规格的限制，每张表最大可以有1600列，如果描述用户的属性有10000个，我们无法通过创建一个有10000列的表来实现这个方案，那么示例一中的方案就不再有效了。 为此，我们可以这样设计我们的表结构： ```mysql create table userinfoset ( tag_value_id int, userset roaringbitmap )with(orientation=column); ``` 其中tag_value_id表示属性值对应的id，比如，性别这一属性，有”男“，”女“两个值，我们可以把它编码为1,2；学历这个属性的取值是”专科“，”本科“，”硕士“，“博士”，那么分别编码为3,4,5,6，等等。将不同的属性值编码为不同的id值。 userset列表示的是满足tag_value_id所对应属性值的用户id的集合。比如tag_value_id=1这条记录对应的userset就是所有性别为男的用户的集合。 **数据加工：** 这个表的数据一般是需要通过加工得到的，假设原始数据的表结构如下(一共有10张表)： ```mysql create table origin_1 ( userid int, tag_value_id1 int, tag_value_id2 int, tag_value_id3 int, ... tag_value_id998 int, tag_value_id999 int, tag_value_id1000 int )with(orientation=column); ... create table origin_10 ( userid int, tag_value_id9001 int, tag_value_id9002 int, tag_value_id9003 int, ... tag_value_id9998 int, tag_value_id9999 int, tag_value_id10000 int )with(orientation=column); ``` 我们可以通过类似以下的语句将数据加工到目标表中： ```mysql insert into userinfoset select tag_value_id1, rb_build_agg(userid) origin_1 from origin group by tag_value_id1; ... insert into userinfoset select tag_value_id10000, rb_build_agg(userid) origin_10 from origin group by tag_value_id10000; ``` **查询：** 假设需要圈选性别为男，学历为本科的用户的的个数有哪些，可以用以下语句实现： ```mysql select rb_or_cardinality_agg(userset) from userinfoset where tag_value_id in (1,4); ``` 如果用户要圈选的人群有更多的特征，将对应的tag_value_id加入到in子句中即可。 如果想要知道这些用户的具体的userid，可以通过如下函数实现： ```mysql select rb_iterate(rb_or_cardinality_agg(userset)) from userinfoset where tag_value_id in (1,4); ```

**关键词：os core，softlockup， soft lockup，软锁，spinlock，自旋锁，hardlockup，硬锁** **【问题现象】** 集群一个节点OS重启，该节点dn全部切换 **【问题影响】** 业务短暂受影响，节点OS重启 **【可能原因】** os core，spinlock自旋锁 **【排查过程】** **场景一：softlockup**** 1. 查看节点服务器/var/crash下是否有对应OS重启时间点的新文件生成 2. 若有，查看vmccore-dmesg.txt，查找关键词softlockup/soft lockup,类似信息如下 ``` Line 14426: [16947095.915801] Kernel panic - not syncing: softlockup: hung tasks ``` ``` Line 321: [16759206.809254] WARN: soft lockup - CPU#123 stuck for 11s! [gaussdb:115065] Line 9530: [16934330.848076] WARN: soft lockup - CPU#32 stuck for 11s! [java:63992] Line 9732: [16936866.829216] WARN: soft lockup - CPU#98 stuck for 11s! [gaussdb:42638] Line 9800: [16936966.785669] WARN: soft lockup - CPU#90 stuck for 11s! [swapper/90:0] Line 9801: [16936966.785691] WARN: soft lockup - CPU#92 stuck for 11s! [swapper/92:0] Line 9876: [16936966.822996] WARN: soft lockup - CPU#124 stuck for 11s! [gaussdb:42638] Line 9935: [16937034.842541] WARN: soft lockup - CPU#84 stuck for 11s! [kworker/84:3:94938] Line 10524: [16947046.830180] WARN: soft lockup - CPU#13 stuck for 11s! [swapper/13:0] Line 10561: [16947062.795203] WARN: soft lockup - CPU#13 stuck for 12s! [swapper/13:0] Line 10601: [16947082.813496] WARN: soft lockup - CPU#13 stuck for 11s! [swapper/13:0] Line 10637: [16947094.786193] watchdog: BUG: soft lockup - CPU#13 stuck for 22s! [swapper/13:0] ``` 3. 若vmcore-dmesg日志中有类似上述信息，即可判断该节点OS发生了softlockup（软锁） 4. 查看vmccore-dmesg.txt，查找关键词spin ``` Line 9831: [16936966.814045] queued_spin_lock_slowpath+0x64/0x2a8 Line 9861: [16936966.814104] queued_spin_lock_slowpath+0x15c/0x2a8 Line 11244: [16947094.843934] queued_spin_lock_slowpath+0x1e8/0x2a8 Line 12753: [16947094.852042] queued_spin_lock_slowpath+0x64/0x2a8 Line 14074: [16947094.858889] queued_spin_lock_slowpath+0x64/0x2a8 Line 14290: [16947094.859643] queued_spin_lock_slowpath+0x64/0x2a8 ``` 上述信息显示有：队列自旋锁（Queued Spin Lock）。一个CPU在等待一个自旋锁的过程中可能被软中断抢占，然后在软中断处理程序中等待另一个自旋锁（软中断可以抢占进程，但是不能抢占另一个正在执行的软中断）[参考资料3] **场景二：hardlockup**** 1. 查看节点服务器/var/crash下是否有对应OS重启时间点的新文件生成 2. 若有，查看vmccore-dmesg.txt，查找关键词hardlockup/hard lockup,类似信息如下 ``` [40637707.563167] Kernel panic - not syncing: Hard LOCKUP ``` ``` Line 20453: [40531353.970094] WARN: hard lockup - CPU#57 stuck for 184s! Line 20464: [40531353.970117] Sample hardirq: Line 20466: [40573193.747401] WARN: hard lockup - CPU#21 stuck for 184s! Line 20477: [40573193.747434] Sample hardirq: Line 20479: [40601533.954146] WARN: hard lockup - CPU#54 stuck for 184s! Line 20489: [40601533.954168] Sample hardirq: Line 20490: [40601533.954315] no hard irqs found. Line 20491: [40637701.829694] WARN: hard lockup - CPU#25 stuck for 184s! Line 20596: [40637707.551674] NMI watchdog: Watchdog detected hard LOCKUP on cpu 56 ``` 3. 若vmcore-dmesg日志中有类似上述信息，即可判断该节点OS发生了hardlockup（硬锁） 4. 查看vmccore-dmesg.txt，查找关键词spin，spin_lock_irqsave，softirq（释义参考5） ``` [28028783.396203] RIP [] native_queued_spin_lock_slowpath+0x122/0x1e0 [28028783.396212] Sample cputime: 4031743974 ns(HZ: 1000) [28028783.396214] Sample cpurate: 325000000 us, 545000000 sy, 0 ni, 2919986000 id, 110176000 wa, 0 hi, 30000000 si, 0 st [28028783.396215] Sample softirq: [28028783.396216] TIMER: 3956 [28028783.396217] NET_RX: 4643 [28028783.396218] BLOCK: 357 [28028783.396219] TASKLET: 4219 [28028783.396219] SCHED: 1192 [28028783.396220] RCU: 932 [28028783.396221] Sample hardirq: [28028783.396229] irq( 53): delta 360, total: 850999363, megasas [28028783.396251] irq( 209): delta 2284, total: 90955185, mlx5_comp60@pci:0000:86:00.0 [28028783.396273] irq( 339): delta 2339, total: 1829324747, mlx5_comp60@pci:0000:87:00.0 ``` ``` [27621497.158995] RIP [<ffffffffaa92f876>] _raw_spin_lock_irqsave+0x26/0x40 [27621497.159004] Sample cputime: 4000473239 ns(HZ: 1000) [27621497.159006] Sample cpurate: 2746000000 us, 363000000 sy, 0 ni, 711424000 id, 10740000 wa, 0 hi, 127000000 si, 0 st [27621497.159007] Sample softirq: [27621497.159009] TIMER: 4000 [27621497.159010] NET_RX: 16178 [27621497.159012] BLOCK: 231 [27621497.159013] TASKLET: 15523 [27621497.159014] SCHED: 514 [27621497.159016] RCU: 144 [27621497.159017] Sample hardirq: [27621497.159040] irq( 86): delta 294, total: 1001513759, megasas [27621497.159055] irq( 148): delta 6462, total: 142710187, mlx5_async@pci:0000:86:00.0 [27621497.159059] irq( 170): delta 8853, total: 2832381792, mlx5_comp21@pci:0000:86:00.0 [27621497.159085] irq( 300): delta 7258, total: 1351357192, mlx5_comp21@pci:0000:87:00.0 ``` ``` [27644465.096882] WARN: hard lockup - CPU#15 stuck for 164s! [27644465.096885] PID: 23336 Comm: python State: R Switches: 13572353787 [27644465.096887] RIP [<ffffffffaa57c8a4>] __list_del_entry+0x4/0xd0 [27644465.096897] Sample cputime: 4000018246 ns(HZ: 1000) [27644465.096898] Sample cpurate: 524000000 us, 271000000 sy, 0 ni, 3177571000 id, 2000 wa, 0 hi, 0 si, 0 st [27644465.096899] Sample softirq: [27644465.096900] TIMER: 3014 [27644465.096901] NET_RX: 6 [27644465.096902] SCHED: 620 [27644465.096903] RCU: 1102 [27644465.096904] Sample hardirq: [27644465.097047] no hard irqs found. ``` 上述信息显示有：队列自旋锁（Queued Spin Lock）。软中断处理程序在等待自旋锁的过程中可能被“硬”中断抢占，然后在“硬”中断处理程序中等待有另一个自旋锁（在“硬”中断处理程序中使用的自旋锁必须要先关闭该CPU上的“硬”中断，这是通过调用函数spin_lock_irqsave或spin_lock_irq实现的，否则会造成死锁）[参考资料3] **【解决方法】** 1. OS bug，通过升级OS来彻底解决 2. 优化业务，降低锁争抢的概率 **【参考信息】** 1. [soft lockup的分类和定位方法](https://blog.csdn.net/rikeyone/article/details/112304213?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522165232354716781435438339%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=165232354716781435438339&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_v31_ecpm-4-112304213-null-null.142^v9^control,157^v4^control&utm_term=softlockup%E8%A7%A3%E5%86%B3&spm=1018.2226.3001.4187) 2. [soft lockup和hard lockup的检测原理](https://blog.csdn.net/rikeyone/article/details/112004920) 3. [Linux内核同步原理之自旋锁（Spin Lock）](https://blog.csdn.net/roland_sun/article/details/107086021?ops_request_misc=&request_id=&biz_id=102&utm_term=queued_spin_lock_slowpath&utm_medium=distribute.pc_search_result.none-task-blog-2~all~sobaiduweb~default-3-107086021.nonecase&spm=1018.2226.3001.4187) 4. [Linux内核报错解决办法：kernel:NMI watchdog: BUG: soft lockup - CPU#0 stuck for 30s](https://blog.csdn.net/qq262593421/article/details/107142262) 5. softIRQ：软件中断（softIRQ）是内核提供的一种延迟执行机制，它完全由软件触发，虽然说是延迟机制，实际上，在大多数情况下，它与普通进程相比，能得到更快的响应时间。软中断也是其他一些内核机制的基础，比如tasklet，高分辨率timer等。

【问题现象】扩容完成后新的节点，监控上不显示【问题版本】HCS 802 DWS 8.1.0.3【可能原因】1、老版本未配置dms的初始化参数，导致节点未生成dms的启动文件2、扩容时停掉了进程和定时任务，扩容结束后未成功拉起【排查过程】1、通过connectTool.sh登录到新扩容的实例节点上，su - Ruby，查看是否存在InitDms.json文件，如果没有这个文件，则是未配置dms的初始化参数导致dms未启动2、若存在InitDms.json文件，ps aux | grep python，如果看到agentService.py --start则是dms_agent正常拉起了，如果进程未拉起，cd dms_workdir查看agent_service.log，登录dmscollection容器查看日志，无其他异常报错则尝试重新拉起dms-agent【解决方法】1、若是InitDms.json文件未生成，可以从老节点上把/home/Ruby/InitDms.json文件拷到新节点上，Web页面刷新即可登录cloudscope-->cdk-->变更管理-->服务升级-->dwscontroller-->搜索参数dms.collection.apigateway.addr正确配置后后台重启dwscontroller容器使参数生效注意：HCS802环境cdk修改参数时会同时修改掉IMAGE_NAME参数，注意这个参数不要被修改2、dms-agent未被拉起导致的节点未被监控，gs_ssh -c "ps -ef | grep agent_service | grep -v grep | awk '{print $2}' | xargs kill -9"重新拉起agent，待1~2分钟后去页面刷新

对于金融类客户业务来说，经常会出现类似基于某些条件排他的查找，例如：基于客户ID、客户ID和业务ID的组合，查找不在某个特征范围内的用户集合等等。此类查询特定记录的使用场景，可以使用NOT IN的语法来实现。NOT IN场景在分析型数据库中被广泛使用，例如：GaussDB(DWS)的大客户：工商银行、招商银行、光大银行在业务场景中都有数量众多的NOT IN语句。这类语句一般在进行集合排他比较时使用，例如如下语句：select * from t1 where a not in (select a from t2);该语句的语义为：查找a值不在t2表中的所有t1表中的记录。由于NOT IN对于NULL值的特殊处理，导致这类语句无法使用高效的HashJoin进行高效处理，性能比较差，调优门槛比较高，成为困扰大多数客户的一大难题。Teradata、Oracle等数据库友商也针对 NOT IN问题进行了大量探索，但始终未能完美解决该场景的性能问题。GaussDB(DWS)在8.1.2最新版本实现了独家的分布式Mixed-HashJoin的NOT IN优化技术，在招商银行联合创新项目中得到了应用，共有近900个作业（占作业总数的3%）中包含的NOT IN语句性能平均提升400倍，招行生产集群单日所有作业端到端性能提升15%，效果明显，解决了客户的痛点问题。这篇文章针对NOT IN的使用方法进行介绍，希望广大用户都可以尝试使用GaussDB(DWS)的NOT IN优化高级特性。 一. 数据库中的三值逻辑提到NOT IN，就不得不提到数据库中的三值逻辑。在数理逻辑中，我们用true和false的二值逻辑表示真假，而在现实世界中，会存在一些数据，目前是未知的，因此存储在数据库中是用NULL来表示的，遇到NULL值运算时，我们也无法判断其真假，故引入了第三值逻辑，即NULL。注意，NULL值不同于空串，因为空串是一个固定的值。当然，在Oracle兼容的模式下，空串是被视为空值的，但在TD和MYSQL兼容模式下就是不等价的。NULL值与任意值的比较均未知，属于游离于True和False之外的第三值，通俗来说，NULL值无法确定与任意值相等，但它可能是任意值，因此也无法确认NULL值与任意值不等。因此，如果需要查询NULL值，不能使用等值比较的方式，而应该使用IS NULL的形式，例如：select * from t where a = NULL; --错误select * from t where a is NULL; --正确而NOT IN中的IN操作符，由于其与=的等价关系，导致IN和NOT IN操作符均不会包含NULL值，例如：对于包含{1，-1，NULL}的数据表t，对应以下的查询结果：上述后两条语句返回1，只有1符合条件。上述两条语句返回1，只有-1符合条件；NULL和1的等值比较为NULL，取非后仍为NULL，不为真。上述语句返回2，1和-1符合条件。上述语句返回0，任意值与NULL比较结果均为NULL，非真。返回0，任意值比较结果NULL取非后仍为NULL，非真。 二. NOT IN的使用场景和示例NOT IN一般在特征提取时会有广泛使用。例如：我们需要查找不符合A，B两个属性中部分属性组成的相应条件的特定人群，可以将相应的条件插入一个表t2中，例如：满足A=1且B=3，则将(1,3)插入表中；满足B=4时，A值置为NULL。然后将目标表和表t2进行NOT IN操作，含义为：查找(A,B)组合不为(1,3)、同时B不为4的元组。在金融行业中，经常出现基于某些条件组合进行用户的筛选的业务，条件组合中由于部分未知情况可能包含某些列的缺失，则业务逻辑就可以这样实现。如上面例子所示，假如判断匹配的表t2(a, b)中包含如上两条记录，而参与查找的表t1(a,b)中包含5条记录：(1,3), (2,4), (2,6), (3,null), (null,5)。对于语句select * from t1 where (a,b) not in (select a,b from t2);在进行NOT IN运算时，NULL值可以看成和任意值匹配，只有两列中存在不匹配的列时，NOT IN返回true。t1各元组和t2目标表的匹配情况（如箭头所示）及输出结果result如下图所示。 三. NOT IN与NOT EXISTS的区别某些数据库的用户还知道NOT EXISTS的用法，和NOT IN很相似，但是有一定区别。例如：上例的NOT IN语句可以改写成下面的语句：select * from t1 where (a,b) not in (select a,b from t2); -> select * from t1 where not exists (select 1 from t2 where t1.a=t2.a and t1.b=t2.b);同样是获取不满足在某个范围内的元组，对于上例的输入，输出结果为4条元组，仅不包含(1,3)。为什么会这样呢？通过上面的分析，我们可以知道，NOT IN中IN使用等值（=）比较，而NOT IN则使用不等值（<>）比较。对比起来，EXISTS同样使用等值（=）比较，而NOT EXISTS则等价于等值（=）比较取反，即EXISTS和NOT EXISTS是互补的。因此，IN和EXISTS是等价的，而NOT IN和NOT EXISTS是不等价的，两者之间差了NULL的处理，如下图所示。从另一个角度来理解，NOT IN运算相当于NULL值的强过滤，均不输出。NOT EXISTS运算则相当于不进行NULL值过滤，均输出。对比两个语句的执行计划，可以看出Join条件上的差别。由于NOT IN在内核使用Anti Join（反连接运算）来实现，即元组不匹配才输出，因此条件上也增加了NULL值返回true的条件。 四. GaussDB(DWS) NOT IN优化技术NOT IN性能问题是业务公认的技术难题，友商Teradata和Oracle均针对NOT IN进行了部分场景的优化，即Null-aware技术，针对单列的NOT IN问题进行了NULL干预，但对于多列NOT IN问题仍然存在各种已知问题。下图为友商在NOT IN场景下，分布式以及单列/多列NOT IN的调研结论。GaussDB(DWS)也一直致力于该问题的求解，新版本针对NOT IN有两个优化技术。NOT NULL约束识别。通过上面的分析我们可以看出，NOT IN运算需要增加额外的NULL值判断，出现的OR条件导致必须通过低效的NestLoop计算。GaussDB(DWS)可以根据用户定义的NOT NULL约束来自动检测去掉NULL值判断，例如：上面的语句中，如果t1表的a列，及t2表的a列上均有NOT NULL约束，则条件t1.a=t2.a不再包含NULL值判断的OR条件，可以转化为高效的HashJoin来进行处理。同时，GaussDB(DWS)也支持部分表达式的NULL值推导，只要基表列上包含NOT NULL约束，参与NOT IN运算的表达式也可以由于推导出的NOT NULL约束进行计划层的优化。分布式Mixed-HashJoin技术。如果NOT IN运算的列值中包含NULL值，则必须采取对NULL值的单独处理来解决问题。GaussDB(DWS) 8.1.2版本实现了分布式Mixed-HashJoin技术，在执行时各DN可以动态分离出包含NULL值的元组，进行NestLoop特殊匹配处理；而对于非NULL值，则可以使用高效的HashJoin来进行执行。由于业务中的NULL值为不确认因素，所占的比例较少，因此，该技术可以保证该类场景的性能优势最大化，在NULL值很少的场景，性能和NOT EXISTS持平。新版本执行计划如下所示：该技术目前已经支持向量化引擎，后续将针对行引擎进行进一步的完善。同时，针对不同列的NULL值情况，也可以建多个NULL值的hash表加速匹配，避免NULL值过多时使用NestLoop仍然过慢。同时，由于外表的NULL值可能匹配到内表的任意值，因此通常需要将内表进行广播（Broadcast）操作。如果内表较大，则占用较多网络资源且影响性能。此时，如果外表在NOT In的某列上有NOT NULL约束，内表可以在该列上对非NULL值进行重分布，仅广播NULL值，减少网络数据发送量。例如，如果上例中，t1表的a列包含NOT NULL约束，则会生成如下的计划（t2表对应的a列进行了重分布，同时将NULL值广播）：五. NOT IN场景的调优手段如果使用GaussDB(DWS)早期版本的用户也不必着急，本章介绍一些NOT IN场景的调优手段，供大家在实践中使用。修改NOT IN为NOT EXISTS上文详细分析了NOT IN和NOT EXISTS的区别。因此，如果用户可以通过自身的业务逻辑，确认NOT EXISTS的语义也可以满足，通常可能是因为对于NULL值的处理不关心，或者数据中根本不存在NULL值，则可以通过等价改写将NOT IN改写为NOT EXISTS来进行优化。通用改写方法为：… WHERE … (col1, col2, …, coln) NOT IN (SELECT c1, c2, …, cn FROM …) … 改写为： … WHERE NOT EXISTS(SELECT 1 FROM … WHERE col1=c1 AND col2=c2 AND … AND coln=cn ...) …为基表列增加NOT NULL约束由于GaussDB(DWS)在早期版本中即支持NULL值的推导逻辑，因此可以通过对NOT IN运算的基表列增加NOT NULL约束，将OR条件转化为等值条件进行优化。注意，对于多列的NOT IN场景，仅需要将内外表对应的一列均增加NOT NULL约束即可进行调优。例如上例，可以单独为col1和c1增加NOT NULL约束，也可以为coln和cn增加NOT NULL约束，以此类推。也可以在SQL语句里显式增加IS NOT NULL的条件来过滤掉无用的NULL值，或者提示优化器该列上的非空约束，例如：select * from t1 where (a,b) not in (select a, b from t2 where a is not null) and a is not null;使用Mixed-HashJoin新技术8.1.2版本中，由于分布式Mixed-HashJoin技术仅支持向量化引擎，因此可以通过将语句中涉及的表均创建为列存表，并设置参数rewrite_rule包含’notinopt’值，即可使用新的技术。由于该参数为多值参数，因此，需要通过show rewrite_rule命令查看当前设置的值（如未设置则为默认值），通过在其后添加’notinopt’值进行设置。关于rewrite_rule的其它值，后续将在其它文章中介绍。如果用户使用的表为行存表，GaussDB(DWS)还提供参数enable_force_vector_engine强制使用向量化引擎处理，同样可以使用新技术。该参数为bool值，默认为off。以上两个参数均可以session级设置生效。进一步地，为了减少内表广播带来的资源消耗，如果在外表某些NOT IN列理论上不为空的情况下，可以为其中某些列增加NOT NULL约束，或在语句中指定IS NOT NULL条件，则可以通过数据重分布减少网络发送量，进一步提升性能。六. 结语通过本文的分析，相信用户朋友已经充分了解了分析型业务排他操作-NOT IN的使用场景、SQL语法，以及GaussDB(DWS)的NOT IN实现方式，可行的调优方法。希望广大用户能够通过深入的了解，对GaussDB(DWS)的性能调优产生浓厚的兴趣并深度参与进来。如NOT IN问题的攻克一样，GaussDB(DWS)目前正着力解决其它棘手的性能问题，期待在其它场景中，也可以给用户带来极致的性能体验，减少用户调优的成本。理论不如实践，那如何快速体验DWS呢？DWS现推出了一项Demo体验活动。进入DWS首页，点击“Demo体验”，快速便捷体验一把！体验过程中有任何建议和意见，可以去DWS社区论坛反馈哦；）

1、为了保证集群内所有服务器和行内ntp时钟一致所需要监控的内容2、以下几个场景会导致的情况和处理方法  （1）OMS节点和行内ntp服务器连通性中断  （2）主OMS节点ntp服务异常​​  （3）​主备OMS节点出现切换  （4）业务节点ntp服务异常