Control Coordinator Node，GaussDB A动态负载管理中心控制点。负责进行各Coordinator中复杂作业是否可以执行的中心判断、排队和调度，以实现动态负载管理。  GaussDB是一个内存自适应的数据库，会自动根据全局内存的负载情况，来对每个语句进行仲裁，当前资源合理的情况下，才会让语句下发并执行，如果在资源不足的情况下，就不让他继续执行，等到资源充足才进行执行，避免会出现比如内存占用过大，导致进程OOM之后异常退出之类的情况。有时候会出现一种情况，就是大量作业都提交了没有结果，表现出的现象就是业务完全不执行，所有作业都卡住  。问题： 集群并发高的时候，常常看到 waiting in ccn 之类的等待，这个是在等待 CCN 判断是 简单查询， 还是复杂查询 ， 然后再进入该进入的队列 等待或 执行 ？ CCN 在SQL没有解析或执行前是通过执行计划判断简单查询 还是 复杂查询 ？ CCN 的时候执行计划应该还没有吧  (否则CCN可能是个大瓶颈)  ？ 

【操作步骤&问题现象】关于SSD盘 GaussDB 集群推荐配置 目前有个疑问序号节点类型配置数量1管理控制节点2*Kunpeng 920,48 Core、2.6GHz,12*32G 内存,2*480G SATA SSD,4*960G SATA SSD,8*10GE,2*900W AC电源22数据节点2*Kunpeng 920,64 Core、2.6GHz,16*32GB内存,2*960GB SATA SSD,12*3.84T SATA SSD,1*Avago3508, 8*10GE,2*900W AC电源最少3节点研发推荐 每6块盘一组raid5在同等节点规模下，做4组raid 和做2做raid 即 每台服务器4个实例组，和每台服务器2个实力组相比是否存在性能差距？那为什么华为推荐此配置而非24块盘？

【摘要】 GaussDB(DWS)提供了丰富的视图用于SQL信息和状态监控，协助用户SQL运维及问题分析。其中负载管理也提供了专门的视图用于SQL运行状态监控，通过视图排查SQL排队原因，及时给出优化措施。本文重点介绍了负载管理常用视图，同时结合其他视图给出了视图应用案例。1.       背景介绍      GaussDB(DWS)提供了丰富的视图用于SQL信息和状态监控，协助用户SQL运维及问题分析。其中负载管理也提供了专门的视图用于SQL运行状态监控，通过视图排查SQL排队原因，及时给出优化措施。本文重点介绍了负载管理常用视图，同时结合其他视图给出了视图应用案例。2.       视图简介负载管理监控视图：PG_SESSION_WLMSTAT（负载管理常用视图）状态监控视图：PGXC_STAT_ACTIVITY（负载管理辅助视图），PG_SESSION_WLMSTAT中不包含query_id、query_start及coorname信息，可以通过关联该视图查看TopSQL实时监控视图：PGXC_WLM_SESSION_STATISTICS（负载管理辅助视图），包含query_band、资源监控等信息TopSQL历史监控视图：PGXC_WLM_SESSION_INFO（负载管理辅助视图）其中负载管理监控视图当前只有单CN视图，如需查看所有CN上查询负载管理信息可通过创建相应FUNCTION实现。参考FUNCTION如下：CREATE OR REPLACE FUNCTION pg_catalog.pgxc_session_wlmstat() RETURNS setof pg_session_wlmstat AS $$ DECLARE row_name record; row_data pg_session_wlmstat%rowtype; query_str text; query_str_nodes text; BEGIN query_str_nodes := 'SELECT node_name FROM pgxc_node WHERE node_type IN (''C'')'; FOR row_name IN EXECUTE(query_str_nodes) LOOP query_str := 'EXECUTE DIRECT ON (' || row_name.node_name || ') ''SELECT * from pg_session_wlmstat'''; FOR row_data IN EXECUTE(query_str) LOOP RETURN NEXT row_data; END LOOP; END LOOP; return; END; $$ LANGUAGE 'plpgsql' NOT FENCED;3.       视图应用创建资源池，设置快慢车道并发上限都是2，其余参数使用默认参数：CREATE RESOURCE POOL rp1 WITH (ACTIVE_STATEMENTS=2,MAX_DOP=2);创建用户，关联资源池rp1CREATE USER usr1 PASSWORD 'password' RESOURCE POOL 'rp1';使用usr1创建表并运行作业，快慢车道各运行10个作业(视图查询过程中可能有作业结束，因此排队作业数可能减少)，查询视图查询作业信息：PGXC_STAT_ACTIVITY视图postgres=# select coorname,usename,query_start,enqueue,state,query_id from pgxc_stat_activity where usename='usr1' order by query_start; coorname | usename | query_start | enqueue | state | query_id --------------+---------+-------------------------------+--------------------------+--------+------------------- coordinator1 | usr1 | 2021-06-11 09:59:02.822459+08 | | active | 75153818781745720 coordinator1 | usr1 | 2021-06-11 09:59:02.823087+08 | | active | 75153818781745723 coordinator1 | usr1 | 2021-06-11 09:59:02.8231+08 | waiting in respool queue | active | 75153818781745724 coordinator1 | usr1 | 2021-06-11 09:59:02.823715+08 | waiting in respool queue | active | 75153818781745726 coordinator1 | usr1 | 2021-06-11 09:59:02.823928+08 | waiting in respool queue | active | 75153818781745727 coordinator1 | usr1 | 2021-06-11 09:59:02.825433+08 | waiting in respool queue | active | 75153818781745728 coordinator1 | usr1 | 2021-06-11 09:59:02.825918+08 | waiting in respool queue | active | 75153818781745730 coordinator1 | usr1 | 2021-06-11 09:59:02.828873+08 | waiting in respool queue | active | 75153818781745732 coordinator1 | usr1 | 2021-06-11 09:59:02.870048+08 | waiting in respool queue | active | 75153818781745739 coordinator1 | usr1 | 2021-06-11 09:59:02.870726+08 | waiting in respool queue | active | 75153818781745740 coordinator1 | usr1 | 2021-06-11 09:59:04.532598+08 | | active | 75153818781745779 coordinator1 | usr1 | 2021-06-11 09:59:04.53264+08 | | active | 75153818781745778 coordinator1 | usr1 | 2021-06-11 09:59:04.533594+08 | waiting in ccn queue | active | 75153818781745782 coordinator1 | usr1 | 2021-06-11 09:59:04.533626+08 | waiting in ccn queue | active | 75153818781745783 coordinator1 | usr1 | 2021-06-11 09:59:04.53382+08 | waiting in ccn queue | active | 75153818781745784 coordinator1 | usr1 | 2021-06-11 09:59:04.533834+08 | waiting in ccn queue | active | 75153818781745787 coordinator1 | usr1 | 2021-06-11 09:59:04.534021+08 | waiting in ccn queue | active | 75153818781745786 coordinator1 | usr1 | 2021-06-11 09:59:04.534788+08 | waiting in ccn queue | active | 75153818781745788 coordinator1 | usr1 | 2021-06-11 09:59:04.53515+08 | waiting in ccn queue | active | 75153818781745789 coordinator1 | usr1 | 2021-06-11 09:59:04.536193+08 | waiting in ccn queue | active | 75153818781745790enqueue字段可能取值：waiting in queue：表示语句在排队中。（向前兼容取值）waiting in global queue：表示语句在CN并发队列排队中。waiting in respool queue：表示语句在资源池排队中。waiting in ccn queue：表示作业在CCN排队中。空：表示语句不在任何队列中，正在运行。state字段可能取值：(该字段代表session当前状态，不能说明语句在排队/运行中)active：后台正在执行查询。(该取值代表session有活跃作业，但是作业可能处于排队/实际运行中)idle：后台正在等待新的客户端命令。idle in transaction：后端在事务中，但事务中没有语句在执行。idle in transaction (aborted)：后端在事务中，但事务中有语句执行失败。fastpath function call：后端正在执行一个fast-path函数。disabled：如果后端禁用track_activities，则报告此状态。从视图中可看出usr1所有session状态均处于active状态，代表所有session都在运行查询；通过enqueue字段可以看出有8个作业在CCN队列排队(复杂作业/慢车道)，8个作业在资源池队列排队(简单作业/快车道)，其余四个作业enqueue字段为空代表正在运行，其中包含两个快车道作业，两个慢车道作业，这点在后面PG_SESSION_WLMSTAT视图查询结果中得到验证。PG_SESSION_WLMSTAT视图postgres=# select usename,processid,threadid,priority,attribute,lane,enqueue,status,block_time,elapsed_time,statement_mem from pg_session_wlmstat where usename='usr1'; usename | processid | threadid | priority | attribute | lane | enqueue | status | block_time | elapsed_time | statement_mem ---------+-----------+-----------------+----------+-------------+------+--------------+---------+------------+--------------+--------------- usr1 | 46919 | 140323231098624 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46920 | 140322958997248 | 2 | Simple | fast | None | running | 0 | 3 | 1 usr1 | 46922 | 140323509499648 | 2 | Simple | fast | None | running | 0 | 3 | 1 usr1 | 46921 | 140323556685568 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46923 | 140323492718336 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46924 | 140323416160000 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46925 | 140323396757248 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46926 | 140323347470080 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46927 | 140323330688768 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46928 | 140323313907456 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46952 | 140323293980416 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46953 | 140323277199104 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46954 | 140323254695680 | 2 | Complicated | slow | None | running | 0 | 2 | 256 usr1 | 46956 | 140323191777024 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46955 | 140323208558336 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46958 | 140323113662208 | 2 | Complicated | slow | None | running | 0 | 2 | 256 usr1 | 46959 | 140323083773696 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46960 | 140322866190080 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46957 | 140323172374272 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46961 | 140322830010112 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 (20 rows)attribute显示为Simple代表简单作业，显示Complicated代表复杂作业；lane显示fast代表语句运行在快车道，显示slow代表运行在慢车道；enqueue字段为None表示作业不在排队，显示Respool表示在资源池排队，显示CentralQueue表示在CCN排队，该字段与PGXC_STAT_ACTIVITY视图中enqueue字段相对应；status为pending表示查询排队/默认状态，显示running表示查询正在运行。备注：pending作业不一定在排队，有可能还没走到负载管理，做到走过负载管理后状态才更新为running，显示pending作业需要结合enqueue字段判断作业是否排队；pending作业enqueue为None表示作业未走到负载管理。4.  总结        本文简单介绍了负载管理常用视图，同时着重介绍了PGXC_STAT_ACTIVITY和PG_SESSION_WLMSTAT在实际应用中的差异，实际应用过程中可以根据实际需求将两个视图进行关联查询，为性能分析、负载管理提供帮助。转载来自：https://bbs.huaweicloud.com/blogs/278874        想了解GuassDB(DWS)更多信息，欢迎微信搜索“GaussDB DWS”关注微信公众号，和您分享最新最全的PB级数仓黑科技~

教程指引：https://support.huaweicloud.com/bestpractice-dws/dws_05_0043.html实践介绍：      本实践将演示交通卡口车辆通行分析，将加载8.9亿条交通卡口车辆通行模拟数据到数据仓库单个数据库表中，并进行车辆精确查询和车辆模糊查询，展示GaussDB(DWS) 对于历史详单数据的高性能查询能力。说明：      GaussDB(DWS) 已预先将样例数据上传到OBS桶的“traffic-data”文件夹中，并给所有华为云用户赋予了该OBS桶的只读访问权限。估计时间：40分钟。实践步骤：准备工作•已注册华为云账号，账号不能处于欠费或冻结状态。•获取此账号的“AK/SK”，请参见创建访问密钥（AK和SK）进行获取。步骤一：创建集群步骤二：使用Data Studio连接集群步骤三：导入交通卡口样例数据步骤四：车辆分析课程反馈：场景分析：问题记录：小伙伴们在试用实践中，可以记录下场景和问题→前往此处留下问题或建议还有相机、键鼠套餐、风扇等多重好礼等你拿~

      用户在使用GaussDB(DWS)时，应该正确指定函数属性，错误指定函数属性不仅会导致查询语句执行效率低，而且可能会导致结果集不稳定的情况。本文简单介绍GaussDB(DWS)函数下推属性的相关知识，并提供几个函数属性相关的典型案例供大家参考。1. 函数下推属性介绍      GaussDB(DWS)创建函数时，可以指定许多函数属性，其中，与函数下推相关的属性为易失性级别 和下推属性，其中：    易失性：    IMMUTABLE：该属性的函数不会修改数据库，并且保证在任何情况下同样的输入参数永远返回同样的结果；    STABLE：该属性的函数不会修改数据库，并且保证在同一个查询中，对于同样的输入参数，函数返回的结果相同；    VOLATILE：该属性的函数对于同样的输入参数，函数的返回结果可能不通，典型的如timeofday，创建函数时如果未明确指定，则默认为VOLATILE；    下推属性：    SHIPPABLE：函数可以下推到DN执行    NOT SHIPPABLE：函数不能下推到DN执行，创建函数时如果未明确指定，则默认为NOT SHIPPABLE。    这两个函数属性可以通过pg_proc的provolatile（i表示immutable，s表示stable，v表示volatile）和proshippable（t表示shippable，null或f表示not shippable）查看。postgres=# select proname,provolatile,proshippable from pg_proc where proname = 'timeofday'; proname | provolatile | proshippable -----------+-------------+-------------- timeofday | v | (1 row)    在GaussDB(DWS)中，IMMUTABLE属性的函数时一定能够下推到DN执行的，不管下推属性是否为SHIPPABLE，对于STABLE和VOLATILE属性的函数，函数是否能下推要看指定的SHIPPABLE属性。因此，在创建函数时如果同时指定了IMMUTABLE 和 NOT SHIPPABLE的属性，函数创建成功时会有以下提示：NOTICE: Immutable function will be shippable anyway.2. 函数下推属性典型案例    案例一：未指定函数易失性级别导致函数不下推    函数定义如下：create function try_cast_int(p_in text, p_default int default 0) returns int as $$ begin begin return $1::int; exception when others then return p_default; end; end; $$ language plpgsql;    由于创建函数时未明确指定函数易失性级别和函数属性，函数默认为VOLATILE NOT SHIPPABLE，使用该函数时执行计划如下：postgres=# explain verbose select try_cast_int(b) from test order by a; QUERY PLAN -------------------------------------------------------------------------------------- Sort (cost=13.91..14.04 rows=50 width=36) Output: (try_cast_int(test.b, 0)), test.a Sort Key: test.a -> Data Node Scan on "__REMOTE_SORT_QUERY__" (cost=0.00..12.50 rows=50 width=36) Output: try_cast_int(test.b, 0), test.a Node/s: All datanodes Remote query: SELECT a, b FROM ONLY public.test WHERE true ORDER BY 1 (7 rows)    可以看出该sql执行计划不下推，执行效率较低，分析该函数发现该函数可以指定为IMMUTABLE属性，让该函数可以下推，因此，可以通过以下方式优化：ALTER FUNCTION try_cast_int(text,int) IMMUTABLE;    案例二：错误指定了函数下推属性导致结果集不稳定    下推函数能够下推到DN执行，与不下推函数相比有着更高的执行效率，有时开发者为了加快函数执行效率，所有自定义函数创建时都会指定为SHIPPABLE，某函数定义如下：create function get_count() returns int SHIPPABLE as $$ declare result int; begin result = (select count(*) from test); --test表是hash表 return result; end; $$ language plpgsql;    调用该函数发现以下现象：postgres=# select get_count(); get_count ----------- 2106 (1 row) postgres=# select get_count() from t_src; get_count ----------- 1032 (1 row)   发现加上from表之后函数的返回值结果发生了变化！为什么会出现这种情况呢？这是因为由于这个函数指定了SHIPPABLE的函数属性，因此生成计划时该函数会下推到DN上执行，该函数下推到DN后，由于函数定义中的test表是hash表，因此每个DN上只有该表的一部分数据，所以select count(*) from test返回的结果不是test表全量数据的结果，而是每个DN上部分数据的结果，因此导致加上from表后函数返回预期发生变化，优化方法：    （1）将函数改为不下推：alter function get_count() not shippable; 或者    （2）将函数中用到的表改为复制表，这样每个DN上都是一份该表的全量数据，即使下推到DN执行，也能保证结果集符合预期。3. 总结    创建自定义函数时，要正确指定函数的属性，确保函数属性符合预期，防止因函数属性设置不正确导致的性能下降或结果集不稳定。 原文链接：https://bbs.huaweicloud.com/blogs/250351

【功能模块】gds【操作步骤&问题现象】1、select * from 外表2、报错：error：dn_xx_xx：” 主机ip：端口号“ connect failed     ds上报错：错误代码：【0】【SQLErrorCode：998】【ERROR：dn_xx_xx:Session xxxxxx  doesn`t exist

客户反应语句被锁，查询步骤如下，1，查到表对应的oidselect '表名'::regclass::oid2，根据oid去pg_locks查询select * from pg_locks where relation=oid;结果显示shareUpdateExclusiveLock,3，根据上面查到的pid去pg_stat_activity中查execute direct on(cn_500x) 'select * from pg_stat_activity where pid=xxx';在所有cn上都查不到结果本来通过步骤3查到query_id后，在pgxc_thread_wait_status中查询等待任务的，但是步骤3查不到结果，不知道正确的方法如何往下查？

DWS巡检工具实战演练部署安装：安装Fusioncare检查待安装节点是否有安装旧版本FusionCare获取安装包链接 http：//suppot.huawei.com/enterprise搜索 Fusioninsight tool prober 8.0.2解压工具包获取 Fusioncare8.0.2安装包   SysChecker8.0.2巡检服务安装包⭐上传软件包到/home/omm目录下并解压安装包cd /home/ommunzip  Fusioncare8.0.1 zip⭐解压后生成目录FusionCare进入并执行安装cd Fusiomcaresh install.sh打开浏览器登录 https：//ip:8803   用户名：admin 密码：********首次登录配置环境信息 ：项目名称-环境名称-产品选择-环境信息（需填写主oms节点管理ip.节点root密码.F浮动ip.Fusioninsight用户名密码）-完成创建巡检：⭐创建任务（任务类型包括升级前 补丁前等）⭐选择集群⭐选择巡检项⭐开始巡检⭐导出巡检报告巡检整改：根据巡检报告提示及巡检指导文档进行修复⭐检查enable_bbox_dump和bbox_dump_path设置恢复指导：用户不允许设置OS core的前提下，且同意执行重启集群操作，只能通过设置enable_bbox_dump来达成抓取core的目的，根据检查结果，执行下面的修复方案：使用omm用户登录任意数据节点：source /opt/huawei/Bigdata/mppdb/.mppdbgs_profile如果命令enable_bbox_dump为off，则先执行gs_guc reload -Z coordinator –Zdatanode -N all -I all -c "enable_bbox_dump=on" 再执行第二步若bbox_dump_path的路径不符合要求，需要执行gs_guc reload -Z coordinator-Z datanode -N all -I all -c "bbox_dump_path=/dir"，其中“/dir”为用户给定的core路径目录                                                                                         ⭐检查ntpd服务恢复指导：Ntpd时间同步服务 根据巡检报告修复建议 执行service ntpd start 并查看状态⭐检查sshd服务恢复指导：查/etc/ssh/sshd_config文件，判断参数配置是否符合预期：PasswordAuthentication=yes;MaxStartups=1000;UseDNS=no;ClientAliveInterval大于10800或者等于0；StrictHostKeyChecking=no配置如上所示则检查项通过，若1或3配置不正确，检查报告警；若2、4、5配置不正确，检查项不通过⭐检查是否开启enable_stateless_pooler_reuse参数恢复指导：登录任意数据节点，使用omm用户执行:source /opt/huawei/Bigdata/mppdb/.mppdbgs_profilegs_guc set -Z datanode -N all -I all -c "enable_stateless_pooler_reuse=on"gs_guc set -Z coordinator -N all -I all -c "enable_stateless_pooler_reuse=on"cm_ctl stopcm_ctl start⭐检查public schema是否有安全风险恢复指导：将public下与pg_catalog同名函数drop或者将其迁移到其他schema。命令格式：ALTER TABLE table_name SET SCHEMA new_schema;ALTER FUNCTION funname ( [ { [ argmode ] [ argname ] argtype} [, ...] ] )    SET SCHEMA new_schema;收回public的创建权限SQL：REVOKE CREATE ON SCHEMA PUBLIC FROM public;修复后可选择重复巡检 再次进行核对检验

1.       背景介绍GaussDB(DWS)提供了丰富的视图用于SQL信息和状态监控，协助用户SQL运维及问题分析。其中负载管理也提供了专门的视图用于SQL运行状态监控，通过视图排查SQL排队原因，及时给出优化措施。本文重点介绍了负载管理常用视图，同时结合其他视图给出了视图应用案例。2.       视图简介负载管理监控视图：PG_SESSION_WLMSTAT（负载管理常用视图）状态监控视图：PGXC_STAT_ACTIVITY（负载管理辅助视图），PG_SESSION_WLMSTAT中不包含query_id、query_start及coorname信息，可以通过关联该视图查看TopSQL实时监控视图：PGXC_WLM_SESSION_STATISTICS（负载管理辅助视图），包含query_band、资源监控等信息TopSQL历史监控视图：PGXC_WLM_SESSION_INFO（负载管理辅助视图）其中负载管理监控视图当前只有单CN视图，如需查看所有CN上查询负载管理信息可通过创建相应FUNCTION实现。参考FUNCTION如下：CREATE OR REPLACE FUNCTION pg_catalog.pgxc_session_wlmstat() RETURNS setof pg_session_wlmstat AS $$ DECLARE row_name record; row_data pg_session_wlmstat%rowtype; query_str text; query_str_nodes text; BEGIN query_str_nodes := 'SELECT node_name FROM pgxc_node WHERE node_type IN (''C'')'; FOR row_name IN EXECUTE(query_str_nodes) LOOP query_str := 'EXECUTE DIRECT ON (' || row_name.node_name || ') ''SELECT * from pg_session_wlmstat'''; FOR row_data IN EXECUTE(query_str) LOOP RETURN NEXT row_data; END LOOP; END LOOP; return; END; $$ LANGUAGE 'plpgsql' NOT FENCED;3.       视图应用创建资源池，设置快慢车道并发上限都是2，其余参数使用默认参数：CREATE RESOURCE POOL rp1 WITH (ACTIVE_STATEMENTS=2,MAX_DOP=2);创建用户，关联资源池rp1CREATE USER usr1 PASSWORD 'password' RESOURCE POOL 'rp1';使用usr1创建表并运行作业，快慢车道各运行10个作业(视图查询过程中可能有作业结束，因此排队作业数可能减少)，查询视图查询作业信息：PGXC_STAT_ACTIVITY视图postgres=# select coorname,usename,query_start,enqueue,state,query_id from pgxc_stat_activity where usename='usr1' order by query_start; coorname | usename | query_start | enqueue | state | query_id --------------+---------+-------------------------------+--------------------------+--------+------------------- coordinator1 | usr1 | 2021-06-11 09:59:02.822459+08 | | active | 75153818781745720 coordinator1 | usr1 | 2021-06-11 09:59:02.823087+08 | | active | 75153818781745723 coordinator1 | usr1 | 2021-06-11 09:59:02.8231+08 | waiting in respool queue | active | 75153818781745724 coordinator1 | usr1 | 2021-06-11 09:59:02.823715+08 | waiting in respool queue | active | 75153818781745726 coordinator1 | usr1 | 2021-06-11 09:59:02.823928+08 | waiting in respool queue | active | 75153818781745727 coordinator1 | usr1 | 2021-06-11 09:59:02.825433+08 | waiting in respool queue | active | 75153818781745728 coordinator1 | usr1 | 2021-06-11 09:59:02.825918+08 | waiting in respool queue | active | 75153818781745730 coordinator1 | usr1 | 2021-06-11 09:59:02.828873+08 | waiting in respool queue | active | 75153818781745732 coordinator1 | usr1 | 2021-06-11 09:59:02.870048+08 | waiting in respool queue | active | 75153818781745739 coordinator1 | usr1 | 2021-06-11 09:59:02.870726+08 | waiting in respool queue | active | 75153818781745740 coordinator1 | usr1 | 2021-06-11 09:59:04.532598+08 | | active | 75153818781745779 coordinator1 | usr1 | 2021-06-11 09:59:04.53264+08 | | active | 75153818781745778 coordinator1 | usr1 | 2021-06-11 09:59:04.533594+08 | waiting in ccn queue | active | 75153818781745782 coordinator1 | usr1 | 2021-06-11 09:59:04.533626+08 | waiting in ccn queue | active | 75153818781745783 coordinator1 | usr1 | 2021-06-11 09:59:04.53382+08 | waiting in ccn queue | active | 75153818781745784 coordinator1 | usr1 | 2021-06-11 09:59:04.533834+08 | waiting in ccn queue | active | 75153818781745787 coordinator1 | usr1 | 2021-06-11 09:59:04.534021+08 | waiting in ccn queue | active | 75153818781745786 coordinator1 | usr1 | 2021-06-11 09:59:04.534788+08 | waiting in ccn queue | active | 75153818781745788 coordinator1 | usr1 | 2021-06-11 09:59:04.53515+08 | waiting in ccn queue | active | 75153818781745789 coordinator1 | usr1 | 2021-06-11 09:59:04.536193+08 | waiting in ccn queue | active | 75153818781745790enqueue字段可能取值：waiting in queue：表示语句在排队中。（向前兼容取值）waiting in global queue：表示语句在CN并发队列排队中。waiting in respool queue：表示语句在资源池排队中。waiting in ccn queue：表示作业在CCN排队中。空：表示语句不在任何队列中，正在运行。state字段可能取值：(该字段代表session当前状态，不能说明语句在排队/运行中)active：后台正在执行查询。(该取值代表session有活跃作业，但是作业可能处于排队/实际运行中)idle：后台正在等待新的客户端命令。idle in transaction：后端在事务中，但事务中没有语句在执行。idle in transaction (aborted)：后端在事务中，但事务中有语句执行失败。fastpath function call：后端正在执行一个fast-path函数。disabled：如果后端禁用track_activities，则报告此状态。从视图中可看出usr1所有session状态均处于active状态，代表所有session都在运行查询；通过enqueue字段可以看出有8个作业在CCN队列排队(复杂作业/慢车道)，8个作业在资源池队列排队(简单作业/快车道)，其余四个作业enqueue字段为空代表正在运行，其中包含两个快车道作业，两个慢车道作业，这点在后面PG_SESSION_WLMSTAT视图查询结果中得到验证。PG_SESSION_WLMSTAT视图postgres=# select usename,processid,threadid,priority,attribute,lane,enqueue,status,block_time,elapsed_time,statement_mem from pg_session_wlmstat where usename='usr1'; usename | processid | threadid | priority | attribute | lane | enqueue | status | block_time | elapsed_time | statement_mem ---------+-----------+-----------------+----------+-------------+------+--------------+---------+------------+--------------+--------------- usr1 | 46919 | 140323231098624 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46920 | 140322958997248 | 2 | Simple | fast | None | running | 0 | 3 | 1 usr1 | 46922 | 140323509499648 | 2 | Simple | fast | None | running | 0 | 3 | 1 usr1 | 46921 | 140323556685568 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46923 | 140323492718336 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46924 | 140323416160000 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46925 | 140323396757248 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46926 | 140323347470080 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46927 | 140323330688768 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46928 | 140323313907456 | 2 | Simple | fast | Respool | pending | 3 | 0 | 1 usr1 | 46952 | 140323293980416 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46953 | 140323277199104 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46954 | 140323254695680 | 2 | Complicated | slow | None | running | 0 | 2 | 256 usr1 | 46956 | 140323191777024 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46955 | 140323208558336 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46958 | 140323113662208 | 2 | Complicated | slow | None | running | 0 | 2 | 256 usr1 | 46959 | 140323083773696 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46960 | 140322866190080 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46957 | 140323172374272 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 usr1 | 46961 | 140322830010112 | 2 | Complicated | slow | CentralQueue | pending | 2 | 0 | 256 (20 rows)attribute显示为Simple代表简单作业，显示Complicated代表复杂作业；lane显示fast代表语句运行在快车道，显示slow代表运行在慢车道；enqueue字段为None表示作业不在排队，显示Respool表示在资源池排队，显示CentralQueue表示在CCN排队，该字段与PGXC_STAT_ACTIVITY视图中enqueue字段相对应；status为pending表示查询排队/默认状态，显示running表示查询正在运行。备注：pending作业不一定在排队，有可能还没走到负载管理，做到走过负载管理后状态才更新为running，显示pending作业需要结合enqueue字段判断作业是否排队；pending作业enqueue为None表示作业未走到负载管理。

问题描述： 创建或者扩容是，节点个数达到一定数据量，实例下发失败，RdsCreateInstance步骤失败BMS.0035 No IP addresses available on network xxxxx 分析过程：报错信息如下1.在 serviceOM 网络查询对应的xxx id，算出ip不足，只有61个ip，但是当节点超过时则没有ip资源2.cdk涉及的ctype，btype网段如下24位，0,2,4,8分别为26位掩码3.规划网段为：实际生成的网段为： 结论，网段生成有问题，需要手动修改cdk相关参数，重新发集群解决方案：ctype，btype按规划的为17位，对应补充，0,2,4,8 分别分四段19位网段  

       【2021年6月4日，中国，上海】6月3日至4日，以“数智金融，升级有道”为主题的华为智慧金融峰会2021在上海举行。在6月4日进行的“开启云原生新时代，数据智能赋能金融”主题论坛上，华为云EI服务产品部总经理贾永利表示：“面对金融业务多样化全面升级挑战, 通过AI与数据双轮驱动，华为云打造融合统一，敏捷灵活，持续演进的金融数据底座；利用AI的通用泛化，智能自动化，知识计算等全新能力加速激发金融全场景业务智能创新。”      随着数字化转型进程的逐渐深化，爆发增长的数据逐渐成为企业发展的重要生产要素，借助数据分析技术深挖数据资产价值，成为金融科技时代金融行业数字化转型的重要课题。华为云GaussDB(DWS)是推动金融数据仓库技术创新的积极贡献者，截止2021年5月底，为半数以上全国性股份制银行提供超大规模多层并行计算的数据仓库服务。工商银行与华为云深度合作，建设全球最大金融数仓      自2015年，工商银行启动新一代数据仓库的建设，解决日益增长的数据和业务需求，截止目前已建成8套集群、1000多个节点。基于华为云GaussDB(DWS)的分析师平台，单集群480节点四路全闪存服务器是全球最大金融数仓。承载13000位分析师在线数据探索，其作业平均等待时间从原来300分钟将至1.5分钟，灵活查询平均执行时间从30分钟将至50秒，大幅提升分析师体验，真正实现了人人都能成为分析师。 招商银行联合华为云，打造首个大规模金融云数仓      2020年经过严格的选型测试，招商银行与华为云共同发起设立新一代数据仓库联合实验室，同年6月“新一代数据仓库联合创新实验室”揭牌。双方秉承优势互补、资源共享的原则，开启新一代数据仓库联合创新，共同打造面向未来10年技术领先的企业数据仓库平台。截止目前，建成首个大规模金融云数仓，单集群240节点，装机容量达到10PB，为应用提供强大存储和算力支撑。      继今年1月首批应用投产，目前已承载20多个业务应用，预计到2022年上半年，该数据仓库将每天处理15万个ETL作业任务，完成50TB的数据交换，接入超过150个业务应用。以充足的算力匹配招行银行“人人用数，人人都是数据分析师”的数据发展战略，支撑数据分析师们更快更深更广地挖掘数据价值。中国人寿携手华为云，打造分钟级业务分析系统      华为云与中国人寿携手搭建的准实时+批量分析数据仓库，使用1套华为云GaussDB(DWS)替换30多套SQL Server，接入10多个源系统，每天2.7万张表的实时增量数据，使用小批量方案实现每3分钟或每5000条入库业务数据，提供T+0报表，以分钟级获取业务分析结果，极大提升保险客户业务满意度。      贾永利提到，在今年5月斩获贵州数博会 “领先科技成果奖”新技术的华为云GaussDB(DWS)实时数仓，是实时数据分析技术的进一步探索，也将在金融行业的实时业务中发挥价值。      基于标准数仓的架构内置时序引擎和CEP引擎，以处理时序数据和流数据，增加实时接入及混合负载能力。首创性的把多引擎融合在一起协同工作，支持持续计算、规则计算、预测分析，以及实时数据与历史数据关联分析。      华为云GaussDB(DWS)实时数仓已在华为云终端实时智能监控平台投产使用。该平台承载运维部门的业务监控，云平台10万多台服务器和数亿台智能终端持续上传时序数据和流数据，经过复杂分析处理后展示在前端监控台。时序数据单机入库每秒10万条、流数据每秒60万条持续入库，时序、流数据实时入仓持续计算，解决了时序数据和流数据在传统数仓的“装不进”问题。      从T+1到T+0，从小时级分钟级，到秒级毫秒级，华为云持续深入数据仓库技术的研究和实践，发挥自身优势，以丰富的跨域业务场景和实践经验，助力金融行业数字化转型，使能金融行业人人用数，人人都能成为分析师。本文转载自：GaussDB DWS微信公众号      想了解GuassDB(DWS)更多信息，欢迎微信搜索“GaussDB DWS”关注微信公众号，和您分享最新最全的PB级数仓黑科技~

怎样可以查询用户登录数据库历史记录呢

DWS锁等待问题场景构造及定位演练Gaussdb（dws）支持表锁等级分为1-8级常用等级：Select 一级锁 Insert update delete  三级锁Drop Alter 等ddl语句 八级锁操作示例及根据客户已知信息查询等待原因例：客户操作 truncate tb1 持续等待 查找原因构造环境1．开启事务   执行查询语句2． truncate 同一张表 （等待）定位演练1．根据执行语句 查询活跃sql语句pg_stat_activity视图获得所需信息query_id  2．根据所获query_id  查询语句等待情况pg_thread_wait_status视图获取所需信息acquire lock3．根据pid信息查询锁视图pg_locks 获取所需信息 被锁定对象关系oid4．查询oid 根据granted列 查看持有锁t的pid信息5.根据pid信息 查询sql活跃视图得出username query 等状态信息

【功能模块】sql脚本文件执行【操作步骤&问题现象】在使用命令 gsql -d  postgres -p port - f filed 执行某个sql文件时，里面的某个sql执行报错，此时会退出脚本文件的执行，但是怎样才能继续执行其余的sql语句，直至所有sql语句执行完毕oracle处理这种问题的办法是在执行sql语句前面加‘whenever sqlerror continue none ;’我想了一个办法，是利用匿名块来捕捉异常，还有其他办法么？类似于oracle这种处理方法

问题描述集群中所有节点的CPU都非常高，接近90%左右，系统响应慢，集群中有10个节点。问题分析当出现CPU高的时候，通过以下几个SQL，抓取一下当前系统的并发和正在执行的语句：select coorname,  usename, datname, enqueue , count(*) from pgxc_stat_activity  where  usename <> 'omm' and state = 'active' group by coorname, usename, datname, enqueue ;select coorname, usename, client_addr, sysdate - query_start as dur, enqueue, query_id, replace(query, chr(10), ' ') from pgxc_stat_activity where usename!= 'omm' and state = 'active' order by coorname, dur desc;select sysdate - query_start as dur, waiting, enqueue, state, a.query_id, replace(substr(query, 0, 10), chr(10), ' '), node_name,thread_name,tid,lwtid,ptid,tlevel,smpid,wait_status,wait_event  from pgxc_stat_activity a, pgxc_thread_wait_status b  where state = 'active' and  a.query_id = b.query_id and a.query_id <> 0  order by a.query_id, 1 desc;通过第三条语句中等待视图的信息可以看到，单个语句执行计划达到了839层，执行的语句非常复杂，对应到系统中会有800多个stream线程并发来执行这个一个SQL语句，同时分析到该类型的语句并发执行的有20左右，因此会导致集群CPU飙升。解决方案1. 根据业务场景进行优化SQL。降低SQL复杂度。2. 推荐多租户方案，对单个租户的CPU使用率进行管控。