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工具可能也会遇到，可参考解决方案处理即可；

查看实例级别异常：1.查询实例重启时间ps -eo pid,lstart,etime,cmd|grep data4/master4，根据时间点查询cma日志及dn日志。sql级别异常：查看topsql，select * from  pgxc_wlm_session_info where status = 'aborted'; 查询问题sql及报错类型。

【问题描述】重分布完成业务执行报错，多了4个dropped列信息业务存在查询列属性的sqlselecta.attnum,n.nspname as table_schema,c.relname as table_name,a.attname as column_name,t.typname as type,a.attlen as length,a.atttypmod as lengthvar,a.attnotnull as notnull,b.description as comment,'%s' as stfrompg_namespace n left join pg_class con n.oid = c.relnamespaceleft join pg_attribute aon a.attrelid = c.oidleft join pg_description bon a.attrelid = b.objoid and a.attnum = b.objsubidleft join pg_type ton a.atttypid = t.oid【解决方案】在查询列属性使用时过滤掉drop列增加条件: attname not like '%....pg.dropped%'

【问题现象】缩容失败，查看日志，检查group异常【分析】查看groupselect * from pg_group；如果有两个node group 说明有异常，需要删除多余的自检nodegroup【解决方案】1.drop node group {nodegroupname};2.重试在线缩容

【问题现象】升级是失败，查看升级日志，依赖information_schema.time_stamp【解决方案】1.根据$GAUSSLOG/om/gs_upgradexxx 同目录下gs_localxxx日志获取到依赖的表2.修改列类型：alter table bi_reader.submit_log modify(submit_time timestamp with time zone);

【问题现象】          升级时updateDataStoreTask任务卡住，影响升级进度【问题版本】          8.1.1.x【适用场景】          8.1.1.x 升级 8.1.3.x【解决方法】        1.删除cn-1-1 /tmp目录下历史的gauss开头的文件及文件夹；                统计命令：cd /tmp/                         ls -Rf wc -l                 删除命令：沙箱内执行                         find /tmp/ -name "gauss_*_2021-*" xargs -n 1000 rm -rf                         find /tmp/ -name "gauss_*_2022-*" xargs -n 1000 rm -rf                         find /tmp/ -name "gauss_*_2023-0-*" xargs -n 1000 rm -rf                         find /tmp/ -name "gauss_*_2023-08-*" xargs -n 1000 rm -rf        2.然后重试升级；

1、查询使用not in，因其语义决定，会使用NestLoop算子2、关联条件中有or或无关联条件的笛卡儿积，无法使用Hashjoin只能选择NestLoop3、优化器代价估算不准，导致错误选择NestLoop

1、locate和positionlocate功能上比position强一些，locate可以指定查询的开始位置，position相当于locate函数中可选参数为1时的特殊情况在mysql兼容模式下case_insensitive参数可以控制大小写敏感如下图2、str_to_date和TO_TIMESTAMP这里str_to_date只是为了实现将字符串的格式输出一下，to_timestamp支持类似的功能，但参数格式不一致，并且to_timestamp有有同名的支持其他功能的能力to_timestamp在处理空串时在Teradata兼容模式下通过一个参数有不同的输出结果详情见产品文档to_timestamp在Oracle和Teradata和mysql兼容模式下对空串的处理有细微差别在8.1.1集群版本中to_timestamp处理空串时返回0001-01-01，而TD返回null

​分析遇到瓶颈了，求助图片贴不出来，我直接描述【客户环境类型】CPU是128核，环境用于跑批业务图片是nmon的分析结果，只取一天的数据，cpu遇到两个峰值，最高95%，第二个峰值92%，时间段持续都大于80%。持续时间20min如下图是单核CPU的具体情况，可以看出两个峰值，一个是sys%较高，还有另外一个时间段峰值是user%过高一、针对sys%过高分析如下以下是DWS提供的运维套件db_monitor的数据记录下图是活跃会话数，最高达到787，cpu较小的时刻平均2位数。这是单cn的活跃会话数，单cn会话平均150+，cn2达到200+这里辅助分析了高CPU的5条sql，同一时刻没有高CPU的sql。（大概80%左右，对比其他时刻80%真不算高，其他时刻有sql的cpu高达100%+，但cpu总体使用率不高）根据上述分析，CPU高与长SQL关系不大，是由于同一时刻发起了大量的短SQL进程，大量的SQL需要新启动进程导致 CPU SYS 飙高，监听创建新会话要分配进程的，这部分由 CPU SYS承担。所以我们给出的建议是全局并发控制设置max_active_statements,目前集群的数值设置为500，建议设置为150，实际生产设置为了120二、CPU的USER过高根据以上的分析方式，活跃会话并不高，且慢sql并不抢占过高的cpu，根据历史信息只能分析出thread_count和conn_info图像与CPU高基本拟合，同一个时间的thread_count与conn_info有同一个峰顶，怀疑与TPS有关（存疑？）。其次，观察进程，该时刻gauss发起的进程抢占的CPU全部处于用户态，无核心态​到这，无法往下分分析，求助分析思路或者建议​

问题现象：界面扩容节点， 遇到“确认：下一步”按钮灰色不能点规避措施：F12 鼠标选中按钮，删除disabled，然后界面可以点击

问题现象：使用table_distribution函数查询到不同DN上复制表占用空间大小不一致，怀疑复制表数据不一致排查思路：【1】实际调用table_distribution函数查询，各DN上数据总数一致，排查复制表倾斜，即实际原因在于对复制表的清理空间回收存在差异【2】使用函数pg_stat_get_last_vacuum_time查询相关复制表的vacuum时间，若与当前时间间隔较长，需排查老事务的影响造成空间回收差异；老事务排查方式：排查老事务的方法_数仓GaussDB(DWS)_大数据_华为云论坛 (huaweicloud.com)【3】若近期才vacuum执行成功，需观察对比一段时间，异常DN空间是否还会膨胀，并且可使用pagehack工具解析对应异常及正常DN的fsm文件对比差异，明确是否存在空间复用差异，若存在空间复用差异，则可判断为历史某个时间点的回收差异导致异常DN空间膨胀，进而使的空间复用存在差异；pagehack工具使用及空间重用：GaussDB(DWS)行存表的数据膨胀与空间重用-云社区-华为云 (huaweicloud.com)解决方式：该现象可通过调用vacuum full tablename来消除（注：需要业务低峰期）

问题现象：CN5001的DDL语句无法执行，且在等CN5002，但CN5002的DDL语句可正常执行，活跃视图中同一条语句有两个CN分别下发的情况，且应急重启CN也无法解决结合等待视图及锁视图，观察到持锁与等锁线程均为同一事务id问题原因：可查看并对比不同CN的PGXC_NODE视图，尤其关注node_name与node_host的对应关系是否准确，该现象的问题视图一般为修复CN节点时操作步骤有误导致的解决方式：修复异常CN的PGXC_NODE视图后，并重启异常CN，即可解决该问题