查看日志发现被远端关闭报错Stream closed by remote检查日志中的远端，日志显示SQL语句报错could not poll socket:Interrupted system call 导致执行失败2、LibcommPollWait中每隔9秒调用一次CheckClientConnectionStatus->PqCheckConnection检查与客户端连接是否正常PqCheckConnection中调用poll对客户端连接的socket进行有效性检查，如果poll过程中刚好被信号打断，就会报错could not poll socket: Interrupted system call3、客户返回结果集1200w，属于较大的结果集，在吐数据时会造成CN线程堵住，变得卡顿，导致poll过程时间拉长，容易被打断，触发概率上升，此次报错触发打断过程，属于新版本特性引入BUG，820,821均可能出现此问题4、client_connection_check_interval设置为0后，已经进行临时规避

问题现象：       重分布失败，重分布进程退出，重分布状态未变为no原因分析：1.查看重分布状态：cm_ctl query -Cv2.查看哪些表没有完成重分布1）、 找到老的nodegroup名称old_group_nameselect group_name from pgxc_group where in_redistribution='y';2）、 分别连接每个database统计各个database下未重分布的表数量select count(*) from pgxc_class where pgroup='old_group_name';3）、 如果想知道具体未重分布的表名称，可换成如下sql：select pcrelid::regclass from pgxc_class where pgroup='old_group_name';3.查看重分布日志   1）登录cn-1-1进入到沙箱内 ssh ·hostname -i·  2）查看最新的日志：cd $GAUSSLOG/bin/gs_redis/gs_redisxxx      grep 表名 gs_redisxxx 查看报错，有报锁超时解决方法：      界面重试重分布

【问题现象】       界面显示升级dbsmonitor，ecf-clustermanager容器工步工步失败，报资源不足【问题版本】        升级到HCS811【问题根因】       cdk集群node节点资源不足之ecf命名空间资源不足【原因分析】 1.界面显示升级dbsmonitor，ecf-clustermanager失败，资源不足2.查看标签为ecf的node资源上有mrs的pod3.了解到mrs有一个服务mrszookeeper，没有删除升级导致残留在ecf标签的node到，新版本HCS811node受标签影响导致ecf的服务获取pod资源不足，导致失败4.下线mrs的服务mrszookeeper，界面重试升级通过【处理方法】         与mrs沟通下线mrszookeeper服务，下线完成后，界面重试失败的服务通过

【问题现象】 点击升级，弹出 DWS.9015 升级任务下发失败【解决方案】查看空闲节点是否有失败记录，有责删除，重试升级

问题现象：重启集群，一个节点上的进程均启动失败问题分析：登录对应节点查看om_monitor进程没有正常拉起解决方案：1.crontab -l 查看定时拉起命令，手动拉起2.查看定时脚本问题，历史问题时 定时脚本人为导致语法错误

问题现象：集群1.7.2版本升级813.322失败过程中升级到8.1.1.500后卡住解决措施：1 8.0升级811.500后cn5002卡住，无法提交也无法回滚2 后台紧急应急：登录cn5002节点后台，kill cn后自动回滚，继续完成升级

问题现象：低版本8.1.1的agent升级到8.2.1.310导致agent引用内核的python版本，升级失败unable to import module解决方法：# 租户侧规避方案sourceVersion=v8.2.1.1_59b8d48a_4a6b6a0ctargetVersion=v8.2.1.310_06c3fedd_307d3b1acd / && find /rds -name *.pyxargs chattr -i && cd -cp -rf /rds/mgntAgent/version /rds/mgntAgent/version_bak_0830cp -rf /rds/datastore/dws/version /rds/datastore/dws/version_bak_0830cp -rf /var/spool/cron/root /home/Ruby/root_bak_0830cp -rf /etc/sudoers /etc/sudoers_bak_0830cp -rf /var/spool/cron/Ruby /home/Ruby/Ruby_bak_0830sed -i "s#$targetVersion#$sourceVersion#g" /rds/mgntAgent/version /rds/datastore/dws/version /var/spool/cron/root /etc/sudoers /var/spool/cron/Rubyrm /rds/mgntAgent/workplace -rfln -sfn /rds/mgntAgent/$sourceVersion /rds/mgntAgent/workplacerm /rds/datastore/dws/workplace -rfln -sfn /rds/datastore/dws/$sourceVersion /rds/datastore/dws/workplace# 租户侧还原方案sourceVersion=v8.2.1.310_06c3fedd_307d3b1atargetVersion=v8.2.1.1_59b8d48a_4a6b6a0ccd / && find /rds -name *.pyxargs chattr -i && cd -sed -i "s#$targetVersion#$sourceVersion#g" /rds/mgntAgent/version /rds/datastore/dws/version /var/spool/cron/root /etc/sudoers /var/spool/cron/Rubyrm /rds/mgntAgent/workplace -rfln -sfn /rds/mgntAgent/$sourceVersion /rds/mgntAgent/workplacerm /rds/datastore/dws/workplace -rfln -sfn /rds/datastore/dws/$sourceVersion /rds/datastore/dws/workplace

问题现象：扩容失败之文件目录权限不足，导致新节点rpc无法正常启动问题版本：2023年830的agent升级解决方法：     如下命令修改后重启haagent 重试：chattr -R -i /rds/chmod -R 755 /rds/mgntAgent/v8.2.1.310_bcf43ca7_f59ab299/chmod -R 755 /rds/datastorechmod -R 755 /rds/rpcsed -i 's#export PATH=\$PATH:\${JAVA_HOME}/bin#export PATH=\${JAVA_HOME}/bin:\$PATH#g' /home/Ruby/.bashrcservice haagent restart

问题背景：业务调度锁超时时长与guc参数设置的updata_lockwait_timeout和lockwait_timeout,不符问题分析：lockwait_timeout参数可分别对不同database设置，不同库有各自对应的pg_settings，gs_guc查看的为postgresql.conf中设置的参数值，具体业务库的作业以各自库中pg_settings表的setting字段的值为准准确查看业务库锁超时参数的方式参考（连对应业务库）：show lockwait_timeout;select * from pg_settings where name = 'lockwait_timeout';​​​​​​​修改各数据库对应的参数值语句参考：ALTER DATABASE databasename SET gucname = value

1.GTM状态为Down[1.1]故障类型：GTM进程挂，cm_agent未拉起关键信息:检查gtm进程，发现进程不存在ps -ef | grep gtm | grep -v grep解决方案：手动查杀cm_agent进程，待进程重新拉起后，检查gtm进程状态，若依旧不存在，收集cm_agent日志，联系华为工程师。[1.2]故障类型：GTM与cm_agent之间连接断开关键日志:cm_server日志：${GAUSSLOG}/cm/cm_agent/cm_agent_创建时间.log在cm_agent日志中检查同时存在instanceId is 100*和dynamic_role * = Down,则可判定为cm_agent与GTM断连解决方案：1.可能是CPU或IO比较繁忙导致cm_agent与GTM之间无法建立连接，请排查当时业务CPU或IO等信息。2.可能被其他进程查杀，排查定时任务等信息。3.节点hang，一般会伴随着当前节点所有实例全部为Down，请联系华为工程师。2.GTM告警主备不同步/37003警告：GTM主备不同步的情况下如果出现主GTM挂掉的情况，不会引起主备切换，会造成集群不可用。​不会主备切换的原因如下：GTM实例作用说明：GTM的主要职责之一就是给客户端分发全局事务id (global xid, gxid)GTM首要保证在任何情况下，分发给客户端的gxid不能重复，只能单调递增（每个事务的gxid唯一）。在集群正常执行业务时，当多个客户端同时申请gxid，通过锁机制来防止GTM分发重复。仲裁的条件：(1)GTM1和GTM2均同步模式(2)GTM1连接状态异常在主GTM异常时，备GTM执行failover升主，由GTM的HA机制保证下发的gxid不会被复用。如若主GTM的xid没有同步给备机之前，备机升主，gxid 会重复。[2.1]故障类型：网络波动或断开关键日志:GTM ：${GAUSSLOG}/pg_log/gtm/postgresql-创建时间.log关键词:could not connect to the GTM * server， * connect_timeout=7：connection out of date解决方案：1.可能是网络丢包严重导致，请排查网络可通过$GAUSSHOME/bin/dfx_tool目录下的gsar.sh脚本抓取网络当时丢包情况sh gsar.sh {网卡名}2.规避方式：修改超时参数gs_guc reload -Z gtm -N all -I all -c "standby_connection_timeout=30"将参数修改以后可以达到规避的效果，不再上报告警。[2.2]故障类型：防火墙未关闭关键日志:GTM ：${GAUSSLOG}/pg_log/gtm/postgresql-创建时间.log关键词:could not connect to the GTM * server， * connect_timeout=x：wait xxx ，Operation now in progress解决方案：1. iptables -L -n --line-number 查看防火墙是否未关闭2. iptables -F 打开防火墙后，即可自行恢复​3.GTM执行报错[3.1]报错类型：Failed to receive GTM rollback transaction response for aborting transaction关键日志:GTM ：${GAUSSLOG}/pg_log/gtm/postgresql-创建时间.log关键词:GTM error, could not create sequence解决方案：gtm实例目录中cat gtm.sequence | wc -l检查sequence数量，sequence较大1.把sequence的cache调大，减少到gtm上写sequence的次数ALTER SEQUENCE {序列名} cache {数字};2.把gtm_rw_timeout调大，增加从gtm上接受结果的等待超时时间set gtm_rw_timeout='2min';3.如果依旧不能创建序列，kill掉GTM实例，待重启后即可[3.2]报错类型：FI界面出现MPPDBServer数据实例连接GTM异常关键日志:GTM ：${GAUSSLOG}/pg_log/gtm/postgresql-创建时间.log关键词:Too many threads active解决方案：1.并发偶尔冲高引起的，如果出现频繁并且影响业务可以尝试调整下gtm的连接数gs_guc reload -Z gtm -N all -I all -c "gtm_max_trans = 8192"gtm_max_trans参数说明：设置gtm最大可接收连接数， 不建议用户修改该参数。如果需要改动，此参数不能小于最大连接数加100。取值范围：整型，256~16384默认值：81922.gtm.conf文件中未设置gtm最大可接收连接数，使用默认值8192[3.3]报错类型：存储过程执行报错：GTMerror， could not obtain snapshot解决方案：通过JDBC在一个存储过程内执行delete, insert，vacuum等操作，vacuum报该错。将vacuum 与其他操作分开后可以正常执行。[3.4]报错类型：failed to get the sequence uuid xxx from etcd关键日志:GTM ：${GAUSSLOG}/pg_log/gtm/postgresql-创建时间.log关键词:failed to get the sequence uuid xxx from etcd此报错与vacuum 系列命令强关联，vacuum full 并发数高，占用GTM连接数解决方案：限制vacuum 系列命令并发数

【版本信息】不涉及【问题现象及处理方法】之前介绍的性能问题处理套路中查杀烂SQL（执行时间长的SQL，也称长SQL）作为应急处理整体性能问题的常用手段之一，被广泛使用，但是经常有人会发出疑问，为何一个长SQL会有那么大的影响，怎么能防止一粒老鼠屎坏了一锅粥？这里就聊下这个话题1、消耗大量CPU/IO/内存等资源性能影响点：执行时间长的SQL往往会消耗比较多的CPU/IO/内存等资源，当这些资源出现资源瓶颈，必然会影响整体性能预防方案：配置资源管控，防止单SQL消耗大量资源，影响整体性能，参考https://bbs.huaweicloud.com/blogs/1746372、长期持锁阻塞DDL及后续业务性能影响点：所有SQL都会持锁，长SQL即会对相关表长期持锁，阻塞DDL（ALTER等），进而阻塞后续的业务预防方案：合理配置配置lockwait_timeout、ddl_lock_timeout等参数，避免SQL长期持锁&等锁3、影响空间回收，空间膨胀性能影响点：长SQL老事务会影响vacuum/autovacuum对空间的回收（https://bbs.huaweicloud.com/blogs/278695），导致空间膨胀，查询扫描性能下降1）预期外的长SQL：通过应用端&服务端合理配置SocketTimeout、statement_timeout预防2）预期内的长SQL：规划好调度，避开高频update/delete/insert作业时间4、实时场景，影响写入速度性能影响点：高频的update/delete/insert场景因长SQL导致空间无法及时回收，新数据无法复用老页面，需要频繁的开辟新页面，导致写入性能会受到严重影响预防方案：1）预期外的长SQL：通过应用端&服务端合理配置SocketTimeout、statement_timeout预防2）预期内的长SQL：规划好调度，避开高频update/delete/insert作业时间

    GaussDB(DWS)分布式数据库中数据倾斜有两种，分别为存储层数据倾斜和计算层数据倾斜。在创建表时，如果未选择合适的分布列，则会导致数据不能均匀存储在各个数据节点，在SQL运行时，数据量较大的节点往往会成为性能瓶颈。对于存储层数据倾斜，目前只能通过选择合适的分布列重建表的方式进行规避。相比而言，计算层数据倾斜识别及优化的难度就比较高。在我们遇到过的案例中，计算倾斜主要是由数据重分布导致的，由于在SQL语句使用了join关联、group by、over(partition by)窗口函数以及distinct等算子，数据需要按照指定的字段重新进行分布，这很可能会导致出现数据倾斜，因为在很多时候，参与重分布的字段往往不是一个理想的分布列。对于group by、over()、distinct算子引起的计算倾斜，优化方法主要是采用增加过滤条件，减少数据量来降低重分布带来的成本开销，或者是根据实际情况开启SMP并行，加快执行速度。如果计算倾斜来自于join关联，此时问题就变得相当棘手，在一些特殊情况下，常规的优化方法几乎无法做到提升性能。针对这种现状，在GauuDB 200 6.5.1版本中新增了RLBT(Runtime Load Balance Technology)方案，可以自动识别、解决运行时的计算倾斜问题。RLBT方案主要分为两个层面，第一步是计算倾斜识别，第二步是计算倾斜解决。计算倾斜的识别，即预先识别计算过程中的重分布列是否存在倾斜数据，RLBT方案中给出了三个解决手段，统计信息识别，hint方式指定以及规则识别。在解决倾斜时，目前针对最常见的join和agg算子进行了优化。有关RLBT方案详细内容可以参考GaussDB产品文档，在此我们只讨论该方案在一个特殊案例中的使用错误。下面是案例中经过处理的SQL语句：select t1.col_1,       t2.col_1,       t2.id,       t2.fo  from schema1.a03_edu_yyd_acct t1  left join schema2.sch_par_account t2    on t1.num_1 = t2.account_1   and t2.bb in ('01','11','12')   and t2.flg = '1' where t1.date_sat = cast('20210731' as date)   and t1.zum < 5000   and t1.num_1 = '203106';上面的语句查询结果中表t2的字段均为空，如果on条件改为trim(t1.num_1)=t2.account_1，则t2的字段均可以关联出正确不为空的结果。需要说明的是，该语句在数据库升级之前运行正常，只是在升级之后才出现问题，也就是说，升级之前，t1.num_1 = t2.account_1，升级之后必须是trim(t1.num_1)=t2.account_1。我们分别打印了上述两种情况的执行计划，从中可以看到，当on条件为t1.num_1 = t2.account_1时，执行计划使用了RLBT特性对数据倾斜进行了优化，当on条件为trim(t1.num_1) = t2.account_1时，执行计划未使用RLBT特性，t2表扫描的结果进行了broadcast。使用了RLBT特性的执行计划未使用RLBT特性的执行计划由于t1.num_1 为关联列，且t1.num_1 = '203106'，所有数据在一个DN上面，所以该值是一个倾斜值。根据RLBT方案，外表t1的数据需要做PART_REDISTRIBUTE_PART_ROUNDROBIN，其中对倾斜数据做roundrobin，非倾斜数据做redistribute，在performance执行计划中可以详细的看到t1.num_1 = '203106'的这部分数据在部分DN上进行了roundrobin分布。对于内表t2，需要做PART_REDISTRIBUTE_PART_BROADCAST，其中对倾斜数据做broadcast，非倾斜数据做redistribute。由于t1.num_1 = '203106'，t1.num_1 = t2.account_1，优化器推导出t2.account_1='203106'，因此对于t2的倾斜值'203106'，要在所有节点上进行broadcast。但是，在performance执行计划中我们看到，t2的这条数据未做broadcast，而是做了redistribute，数据仅分布在了其中一个DN上。显然，RLBT特性认为，t2.account_1不等于t1.num_1。从上面的分析可知，RLBT方案在进行倾斜优化时出了问题，把原本需要做broadcast的数据进行了redistribute，导致能够匹配的数据不在同一个DN上，这就是为什么t1.num_1 和 t2.account_1无法关联的原因。通过分析代码，我们发现数据库中有一个参数string_hash_compatible控制着char类型和varchar/text类型的hash值计算方式，当该参数值为on时，计算hash值时不会忽略char类型后面的空格；当参数值为off时，则会忽略char类型后面的空格。由于t1.num_1的数据类型为char(8)，t2.account_1的数据类型为varchar(6)，数据库中该参数值为on，优化器认为'226402'的 varchar(6)类型的值和char(8)类型的值是同一个类型，因此没有做类型转换，导致后面在做倾斜值比较的时候，对这两个值计算出的hash值不同，从而判断倾斜值出现问题，认为在表t2上'226402'这个值不是倾斜值，从而对t2.account_1做了REDISTRIBUTE，匹配失败。参数string_hash_compatible影响重大，在生产环境中不建议修改。如果SQL代码也无法进行调整，可以将RLBT控制参数skew_option设置为off，关闭该特性，避免倾斜优化错误。

    近期，项目上有一个统计表大小的需求，要求查出多个schema下所有表的当前使用容量，并且在查询过程中不能报错中断。根据需求编写SQL语句如下：select n.nspname, c.relname, pg_table_size(c.oid) as tab_size from pg_class c join pg_namespace n on c.relnamespace = n.oid and n.nspname in ('schem1', 'schem2', 'schem3' ……) where c.relkind = 'r' and c.oid > 16384 order by tab_size desc;      上述语句在小业务量的数据库中查询没有问题，但是当给定的schema多达上千个、表的数量约百万个、业务增删改查频繁、数据量极大的情况下，该查询往往会持续很长时间。由于在查询开始时，函数pg_table_size会根据语句条件生成一个待统计的表清单，此时如果在查询过程中某张表被删除，查询语句则会报错中断。除此之外，在查询过程中可能还会发生其他报错，例如节点异常、主备切换、事务同步延迟等，一旦语句中断，前面统计出来的结果都会回滚。众所周知，在PB级的GaussDB集群上统计所有表大小，其代价是巨大的，因此我们希望整个查询进程不会因为个别报错发生中断，而个别表因报错未能正常统计也是可以接受的。在这个需求中，可以使用GaussDB函数中的exception分支来捕获错误语句，当统计到某张表时数据库发生报错，语句回滚，但不中断，跳过错误后继续执行。自定义函数语句如下：create or replace function func_get_tablesize(tab_oid oid,out return_code text)returns textlanguage plpgsqlas $$declare v_sql text; ts text;begin v_sql := 'select pg_table_size('||tab_oid||')'; execute immediate v_sql into ts; if ts is null then return_code :=-1; else return ts; end if;exception when others then return_code :=-1;end$$;       上述自定义函数func_get_tablesize将系统函数pg_table_size进行了封装，当在统计某张表时集群发生报错或者该表大小为空，则返回-1。       使用函数func_get_tablesize替换掉统计表大小语句中的pg_table_size后，即可实现查询报错不中断的需求。

什么是DataArts Insight(一)智能数据洞察（DataArts Insight）是华为云新一代BI服务，提供可视、实时、易用、安全的企业智能分析数据服务，以最自然高效的方式获取业务见解，支撑业务实时高效决策。适配云上云下多种数据源，提供丰富多样的可视化组件，采用拖拽式自由布局，轻松实现数据分析和报表搭建，快速定制专属数据大屏。产品架构(二)DataArts Insight的产品架构如图所示产品功能(三)01自助式分析DataArts Insight提供的智能图表可以帮助您直观、清晰地展示数据分析结果。DataArts Insight提供了多种图表样式，覆盖了表格、线图/面图、柱状图/条形图、指标图、圆盘图、散点图、气泡图等分析图表，满足您灵活多样的可视化分析需求。02数据大屏内置丰富的行业模板和素材内容，支持一键安装应用，快速搭建大屏。将可视化与叙事技术结合，支持多场景、多页面的故事性大屏。图表配置精细化程度再提升，支持动画效果，更有助于气氛渲染。数据指标、分析加工一键复用，加工效率高。03盘古 for BI将智能报表转化为智能工具，提供更加直观和高效的数据分析方式。通过机器学习和数据挖掘，自动发现数据中的关联与趋势，提供有效的洞察与建议。04数据接入支持多种数据源接入能力，包括DWS、ClickHouse、API、本地文件作为现代商业智能分析的数据源。支持公网连接、支持数据源的连通性测试。05数据加工支持在工作空间新建数据集，通过数据源导入、图形化和SQL形式创建数据集。数据集支持度量和维度的设置，支持新建分组维度，层次维度和计算字段，支持数据集字段隐藏。更多产品信息可进入产品主页查看：智能数据洞察 DataArts Insight

一、问题描述使用gdb工具，敲gdb回车后，发现报错如下：Could not load the Python gdb module from `/usr/local/share/gdb/python'.Limited Python support is available from the _gdb module.Suggest passing --data-directory=/path/to/gdb/data-directoryTraceback (most recent call last):File "<string>", line 1, inFile "/usr/lib64/python3.7/glob.py", line 4, inimport reFile "/usr/lib64/python3.7/re.py", line 143, inclass RegexFlag(enum.IntFlag):AttributeError: module 'enum' has no atribute 'IntFlag'/etc/gdbinit:9: Error in sourced command file:Error while executing Python code.二、问题原因gdb安装包了代码要使用python，而默认python版本没有enum.IntFlag属性导致报错；属于python不同版本的兼容性问题；三、涉及原理python默认使用环境变量PYTHONPATH使用下面的命令，能看到当前shell环境使用的python版本依赖的lib包echo $PYTHONPATH示例回显：/opt/huawei/Bigdata/mppdb/wisequery/lib那么如何确认当前使用python是什么版本，以及到底有没有enum.IntFlag属性呢可使用如下命令查看python版本:python -c "import sys;print(sys.version,sys.path);"示例回显：('2.7.5 (default, Sep 12 2018, 05:31:16) \n[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)]', ['', '/usr/lib64/python27.zip', '/usr/lib64/python2.7', '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload', '/usr/lib64/python2.7/site-packages', '/usr/lib64/python2.7/site-packages/gtk-2.0', '/usr/lib/python2.7/site-packages'])2.7.5的版本可使用如下命令测试属性：python -c "import enum;print(enum.IntFlag);"一般来说，这个环境变量都是集群带的，主要在低版本环境的集群可能会有这个报错；四、解决方案影响：重置python默认使用环境变量PYTHONPATH，属于会话级别关闭，对DWS集群无影响，下次登录时还是默认环境变量。具体操作命令如下：unset PYTHONPATHgdb可以看到这里就不报错了。五、其他场景如已知的HC环境的iotop工具可能也会遇到，可参考解决方案处理即可；