密码学中密码算法可以分为三类：哈希函数、对称密码算法和非对称密码算法。哈希函数哈希函数又称为摘要算法，对于数据data，Hash函数会生成固定长度的数据，即Hash(data)=result。这个过程是不可逆的，即Hash函数不存在反函数，无法由result得到data。在不应保存明文场景，比如口令(password)属于敏感信息，系统管理员用户也不应该知道用户的明文口令，就应该使用哈希算法，存储口令的单向哈希值。实际使用中会加入盐值和迭代次数，避免相同口令生成相同的哈希值，以防止彩虹表攻击。对称密码算法对称密码算法使用相同的密钥来加密和加密数据。对称密码算法分为分组密码算法和流密码算法。分组密码算法将明文分成固定长度的分组，用密钥对每个分组加密。由于分组长度固定，当明文长度不是分组长度的整数倍时，会对明文做填充处理。由于填充的存在，分组密码算法得到的密文长度会大于明文长度。流密码算法将明文逐比特与密钥流运算。流密码算法不需要填充，得到的密文长度等于明文长度。非对称密码算法非对称密码算法，又称为公钥密码算法。算法使用两个密钥：公钥和私钥。公钥向所有人公开，私钥保密。非对称密码算法应用于密钥协商、数字签名、数字证书等领域。数据加密是防止未授权访问和防护数据泄露的有效技术。介绍了密码算法的基本原理和GaussDB(DWS)数仓的加密函数，包括哈希函数gs_hash，对称密码算法gs_encrypt/gs_decrypt。

 问题描述某局点SQL执行慢，涉及大表的SQL执行不出来结果。分析过程数据倾斜在很多方面都会有体现：1）gs_ssh –c “df -h”查看各个数据磁盘的利用率，会有不均衡的现象。正常情况下，利用率最高和利用率最高的磁盘空间相差不大，如果磁盘利用率相差超过了5%就要引起重视。2）通过等待视图查看作业的运行情况，发现作业总是等待部分DN，或者个别DN。3）慢语句的explain performance显示，基表scan的时间和行数各个DN之间不均衡。数据最多的dn有22831616行，其他dn都是0行，数据有严重倾斜。4）通过倾斜检查接口可以发现数据倾斜。5）通过资源监控发现，个别节点的CPU/IO明显比其他节点高。问题根因GaussDB当前支持Hash表和复制表两种分布方式。默认创建的表是Hash分布的，如果不指定分布键，则选择表的第一列作为分布键。那么这种情况就可能存在倾斜的。倾斜造成的负面影响非常大。首先，SQL的性能会非常差，因为数据只分布在部分DN，那么SQL运行的时候就只有部分DN参与计算，没有发挥分布式的优势。其次，会导致资源倾斜，尤其是磁盘。可能部分磁盘的空间已经接近极限，但是其他磁盘利用率很低。可能出现部分节点CPU过高等等问题。解决详情如何找到倾斜的表：1）在库中表个数少于1W的场景，直接使用倾斜视图查询当前库内所有表的数据倾斜情况。2）在库中表个数非常多（至少大于1W）的场景，因PGXC_GET_TABLE_SKEWNESS涉及全库查并计算非常全面的倾斜字段，所以可能会花费比较长的时间（小时级），建议参考PGXC_GET_TABLE_SKEWNESS视图定义，直接使用table_distribution()函数自定义输出，减少输出列进行计算优化。

问题描述单表查询的场景下，客户预期1s以内返回结果，实际执行耗时超过10s。某客户反馈两个表的关联要去秒级返回，其中大表有2.7T，小表有100GB左右，查询结果一般都不大，过滤条件中有过滤性比价好的条件。分析过程1. 通过抓取问题SQL的执行信息，发现大部分的耗时都在“CStore Scan”。2. 分析出问题的场景：基表是一张十亿级别的表，每晚有批量增量数据入库，同时会有少量的数据清洗的工作。白天会有高并发的查询操作，查询不涉及表关联，并且返回结果都不大。3.可以看到两个表关联走了HashJoin，主要的耗时在基表扫描和HashJoin操作上。问题根因这种场景属于行列存表选择错误导致的问题。这种场景应该使用行存表+btree索引。解决详情调整表定义，表修改为行存表。同时建立btree索引，索引建立的原则：基于充分分析客户SQL的背景下去建立索引。索引要建立的刚刚好，不要有冗余。建立组合索引时候，要把过滤性比较好的列往前放。尽可能多的过滤条件都用到索引。主要的耗时点是在Hashjoin 和基表扫描上，这种情况下可以考用NestLoop+indexScan的计划。这种计划会把join条件下推到基表扫描上，然后利用基表的索引，提前把数据过滤掉。

问题描述用户的SQL性能差，执行计划中有SubPlan的关键字。UPDATE场景下出现了SubPlan导致语句执行性能差。 分析过程执行计划中有SubPlan，这类语句的性能往往比较差。上述执行计划中有SubPlan，这类语句的性能往往比较差。 问题根因执行计划中有SubPlan的语句往往性能比较差，执行计划中有SubPlan的语句往往性能比较差，这是因为，引用SubPlan结果的算子可能需要反复的调用获取这个SubPlan的值，即SubPlan以下的结果要重复执行很多次。 解决详情这类问题通常通过改写SQL来规避。往往这种场景的SQL语句的改写是比较困难，而且很容易出现改写后的结果不一致问题。由于我们在比较高的版本上已经支持了很多场景想的SubPlan的自动转化为join操作，因此一种比较方便的思路是打印他在高版本下的执行计划(explain verbose)，然后根据explain verbose 演绎出来改写后的SQL语句。为了确认改写后的语句与原来的语句是等价的，可以再次打印改写后的执行计划。

问题描述数据库性能时快时慢问题。GaussDB 数据库性能时快时慢问题，原先几秒钟的sql，目前20几秒出来，导致前台IOC页面数据加载超时，无法对用户提供图表显示。分析过程1. raid卡缓存策略未开启、CPU开启了节能模式，查询并未开启。2.和客户确认是部分业务慢，可以提供部分慢sql，打印执行计划，耗时主要在index scan上，怀疑是IO争抢导致，通过监控IO，发现并没有IO资源使用瓶颈。3.查询当前活跃sql，发现有大量的create index语句，需要和客户确认该业务是否合理。select * from pg_stat_activity where state !=’idle’ and usename !=’omm’;4.根据执行计划，发现在部分DN上耗时较高，查询表的倾斜情况，并未发现有倾斜的情况select table_skewness(‘ioc_dm.m_ss_index_event’);5.检查内存相关参数，设置不合理，需要优化。单节点总内存大小为256Gmax_process_memory为12G，设置过小shared_buffers为32M，设置过小work_mem：CN：64M 、DN：64Mmax_active_statements: -1（不限制并发数）6.进一步分析扫描慢的原因，发现表数据膨胀严重，对其中一张8G大小的表，总数据量5万条，做完vacuum full后大小减小为5.6M。问题根因1.大量表频繁增删改，未及时清理，导致脏数据过多，表数据膨胀，查询慢。2.交付时，内存参数设置不合理。7.4 解决详情1.对业务涉及到的常用的大表，执行vacuum full操作，清理脏数据；2.设置GUC内存参数。

问题描述查询语句执行慢，卡住无法返回结果。分析过程1.排查当前的IO，内存，CPU使用情况，没有发现资源占用高的情况。2.查看慢sql的线程等待状态。根据线程等待状态，并没有出现都在等待某个DN的情况，初步排除中间结果集偏斜到了同一个DN的情况。3.通过反复打印堆栈信息，发现堆栈在变化，并没有hang死，所以初步判断该问题未性能慢的问题，堆栈中有VecNestLoopRuntime，以及结合执行计划，初步判断是由于统计信息不准，优化器评估结果集较少，计划走了nestloop导致性能下降。4.对表执行analyze后性能并没有太大改善5.对sql增加hint关闭索引，让优化器强行走hashjoin，发现hint功能没有生效，原因是hint无法改变子查询中的计划6.通过set enable_indexscan = off;执行计划被改变，走了Hash Left Join，慢sql在3秒左右跑出结果，满足客户需求。问题根因优化器在选择执行计划时，对结果集评估较小，导致计划走了nestloop，性能下降。解决详情通过set set enable_indexscan = off;关闭索引功能，让优化器生成的执行计划不走nestloop，而走Hashjoin。

问题描述三条sql查询慢，查询的分区表总共185亿条数据，查询条件中没有涉及分区键。列存表，分区键为createtime,哈希分布键为motorvehicleid。分析过程1.和客户确认部分业务慢，慢的业务中都涉及到了同一张表tb_motor_vehicle。2.和客户收集几个典型的慢sql，分别打印执行计划。从执行计划中可以看出来，两条sql的耗时都集中在Partitioned CStore Scan on public.tb_motor_vehicle列存表的分区扫描上3.和客户确认，该表的分区键为createtime，而涉及到的sql中无任何createtime的筛选和过滤条件，基本可以确认是由于慢sql的计划没有走分区剪枝，导致了全表扫描，对于185亿条数据量的表，全表扫描性能会很差。性能从十几分钟，优化到了12秒左右，性能有明显提升。问题根因慢sql过滤条件中未涉及分区字段，导致执行计划未分区剪枝，走了全表扫描，性能严重裂化。解决详情在慢sql的过滤条件中增加分区筛选条件，避免走全表扫描。

分析过程1. 通过explain verbose打印语句执行计划2. 上述执行计划中有__REMOTE关键字，这就表明当前的语句是不下推执行的。3. 不下推语句在pg_log中会打印不下推的原因。上述语句在CN的日志中会找到类似以下的日志： 问题根因目前最新版本可以支持绝大多数常用函数的下推。不下推函数的场景主要出现在自定义函数属性定义错误的场景。不下推语句的执行方式没有利用分布式的优势，他的执行过程相当于把大量的数据和计算过程汇集到一个节点上去做，因此性能往往非常差。解决详情审视用户自定义函数的provolatile属性是否定义正确。如果定义不正确，要修改对应的属性，使它能够下推执行。具体判断方法可以参考如下说明：函数相关的所有属性都在pg_proc这张系统表中可以查到。其中与函数能否下推相关的两个属性是provolatile 和 proshippable。其中provolatile是继承自PG的字段，他的本质含义是描述函数是IMMUTABLE/STABLE/VOLATILE的。简单来讲，如果一个函数对于同样的输入，一定有相同的输出，那么这类函数就是IMMUTABLE的，例如绝大部分的字符串处理函数。如果一个函数的返回结果在一个SQL语句的调用过程中，结果是相同的，那么他就是STABLE的。例如时间相关的处理函数，他的最终显示结果可能与具体的GUC参数相关（例如控制时间显示格式的参数），这类函数都是STABLE的。如果一个函数的返回结果可能随着每一次的调用而返回不同的结果。例如nextval，random这种函数，每次调用结果都是不可预期的，那么他就是VOLATILE的。

分类专题名称场景分类专题案例地址sql类故障　语句不走索引扫描问题cid:link_19表未做analyzehttps://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=119620&page=1&authorid=&replytype=&extra=#pid989700表脏数据过多膨胀问题　raid卡缓存策略https://bbs.huaweicloud.com/forum/thread-101504-1-1.html网卡多队列问题cid:link_20arm网卡未加固https://bbs.huaweicloud.com/forum/thread-110780-1-1.html列存小CU过多https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=161327索引后置cid:link_12单条SQL性能慢(1)索引使用不当(2)滥用not in(3)未走分区剪枝(4)subplan(5)join结果集过大(6)未走单sharding场景(7)in list未转join(8)行列存表选择不当https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=90331&page=1&extra=#pid478647(9)gather慢场景https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=161503(10)生成路径数过多cid:link_13外表查询慢　资源类性能问题节点 cpu高https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=70939整体集群慢cid:link_21单节点io高https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=152917整体集群io高cid:link_14内存高导致性能慢https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=82838网络问题导致性能慢https://bbs.huaweicloud.com/forum/forum.php?mod=viewthread&tid=99679&extra=page%3D1sql报错类问题权限不足报错类问题cid:link_22JDBC使用问题　字符编码问题cid:link_15udf函数报错　结果集不稳定aggcid:link_18unionlimitorder bymerge intocid:link_16core问题如何配置corecid:link_17根据core找到对应的sql语句cid:link_4咨询类如何杀掉语句cid:link_23如何选择合适的分布键　等待状态含义cid:link_24应急预案CPU整体使用率高cid:link_25CPU倾斜cid:link_26动态内存高cid:link_27CCN排队https://bbs.huaweicloud.com/blogs/418824建联卡主/pooler create conncid:link_28连接数过载/too many clientscid:link_5IO高cid:link_6日常运维命令用户运维指南GaussDB(DWS)用户运维指南cid:link_1

尊敬的客户：很荣幸在此通知您，数据仓库专业级开发者认证（HCCDE - GaussDB(DWS)）预计将于2024年9月20日正式对外发布。为帮助您更好的了解HCCDE - GaussDB(DWS)认证相关内容，现进行预发布通知，请您关注。1 什么是HCCDE – GaussDB(DWS)认证？    数据仓库专业级开发者认证（HCCDE - GaussDB(DWS)）是华为云重磅推出的首个专业级开发者认证，也是华为云首个完整、明确定义数据仓库人才所需知识及技能的专业级认证。    HCCDE – GaussDB(DWS)认证作为华为云数据仓库领域最高等级的技能认证，由华为云学堂和华为云数据仓库GaussDB(DWS)产品部多位顶级专家精心设计、开发而成，保证了认证内容的权威性和可靠性。该认证主要面向数据仓库、数据库领域的应用架构师、系统架构师、资深工程师等对数据仓库有学习认证需求的相关岗位人员。获得HCCDE – GaussDB(DWS)认证证书能够展示自己在数据仓库领域的专业知识和技能，提升职场竞争力。HCCDE – GaussDB(DWS)认证对于数据仓库领域的专业人士来说，也是一个提升自己技能和展示专业能力的绝佳机会。通过该认证，您将获得华为云官方的能力认可，证明您在数据仓库及大数据方向具备了以下能力：全面掌握数据仓库领域相关的知识，深入理解GaussDB(DWS)的核心架构原理和关键技术原理。具备根据业务场景需要，利用GaussDB(DWS)进行架构设计和业务设计的能力。具备分析GaussDB(DWS)疑难性能问题、进行深度SQL优化、深度性能调优的能力。掌握导入导出方法，可以根据业务需要灵活选择不同数据源的最佳数据访问方案。具备根据业务安全要求进行安全设计的能力。具备根据业务实际需求设计合理的高可用方案，以及根据业务需要和业务高可用要求制定合理的备份和容灾策略的能力。2 为什么选择HCCDE – GaussDB(DWS)？华为云数据仓库GaussDB(DWS)，历经13年的技术磨砺，已成为国产数据仓库中的佼佼者，作为中国唯一获得数仓类CC安全认证的产品，在国有大行和股份制银行中的部署比例达到60.1%，是中国金融数仓市场本地部署第一名。GaussDB(DWS)在金融、泛政府、电信、能源、交通、医疗、物流、电商等领域，帮助1700+大客户实现规模商用。数字化时代，各行业对使用数据仓库的需求日益增长，华为云数据仓库GaussDB(DWS)前景广阔，对于相关人才的需求也极为旺盛。3 HCCDE – GaussDB(DWS)认证内容介绍HCCDE – GaussDB(DWS)认证课程将涵盖以下关键知识领域：GaussDB(DWS)核心架构理念：理解GaussDB(DWS)的整体架构和设计原则，包括分布式架构、数据模型、查询处理等方面的技术内容。GaussDB(DWS)对象设计理念：理解如何合理利用GaussDB(DWS)设计和使用对象，以及如何根据不同的业务场景进行有效的业务对象设计。GaussDB(DWS)性能管理：对GaussDB(DWS)进行性能监控和管理，包括如何定位和解决性能问题，以及如何进行性能优化。GaussDB(DWS)数据访问：基于GaussDB(DWS)进行数据的导入、加工、导出和查询，以及如何使用相关的工具和技术。GaussDB(DWS)安全管理及集群安全配置：理解 GaussDB(DWS)的安全机制和策略，包括如何进行安全管理和集群安全配置。GaussDB(DWS)资源管控：在GaussDB(DWS)中进行资源管理和控制，以及如何根据业务需求进行资源分配和调度。GaussDB(DWS)高可靠及高可用原理与方案设计：掌握GaussDB(DWS)的高可靠性和高可用性的设计原则和方法，包括如何设计和应用相关的解决方案。GaussDB(DWS)监控运维原理与方案设计：在GaussDB(DWS)中进行监控和运维，以及如何设计和实施相关的监控和运维方案。4 如何更好地准备认证？为了准备HCCDE – GaussDB(DWS)认证学习与考试，我们建议你具备以下几点条件：首先，你需要拥有多年的数据仓库/数据库领域的工作经验，或者对数据仓库/数据库有较为清晰的认识。这将帮助你更好的理解考试内容，并在实际应用中运用所学知识。其次，你需要拥有HCCDP – GaussDB(DWS)认证证书，或者具备与HCCDP – GaussDB(DWS)同等的能力。这意味着你需要熟悉数据仓库、数据库的基本原理和概念，熟练掌握基本的对象设计方法，熟练掌握SQL写法和规范，以及了解GaussDB(DWS)常用系统表、系统视图及常用的问题处理方法。在开始认证学习之前，我们建议你通过阅读产品文档和参与开发者社区来增进对GaussDB(DWS)的认知。这将帮助你更好地了解GaussDB(DWS)的功能和特性，为认证考试做好准备。产品文档链接：cid:link_1开发者学习平台链接：cid:link_05 考试和认证流程介绍6 结语随着大数据时代的来临，数据成为企业的核心资产。数据仓库技术因此变得至关重要，掌握相关技能对职业发展具有重要的意义。华为云开发者认证推出的HCCDE–GaussDB(DWS)专业级认证，提升个人能力并帮助企业优化数据利用，增强竞争力。加入HCCDE–GaussDB(DWS)专业级认证，共同迎接数据驱动的未来。

GaussDB(DWS)默认就是分布式系统的，和GaussDB的【分布式版】有什么区别吗？

例如：使用delete命令误删除的数据库，可以恢复吗？就是像Oracle那样，使用闪回找到删除的数据。drop 和truncate支持闪回吗？

通过JDBC时，insert into的方式插入数据，在一个事务中提交多少条最优？INSERT INTO customer_t1 VALUES  (6885, 'maps', 'Joes'), (4321, 'tpcds', 'Lily'), (9527, 'world', 'James');

功能描述1. 对集群内所有磁盘的使用率进行筛选，识别超过阈值的磁盘2. 对单DN或单磁盘下所有DN进行磁盘使用率检查，覆盖以下场景：    1) 统计xlog归档目录大小    2) 统计临时下盘文件大小，并找出对应的语句    3) 统计pg_xlog目录下除归档日志之外的xlog大小，并检查是否存在roach进程、是否存在延迟回收标记文件、查询复制槽位置    4) 统计pg_cbm目录大小    5) 检查数据目录下的大文件，并判断该文件是否属于以下场景:        a. 普通表        b. create table as语句或vacuum full语句产生的中间文件        c. 系统表        d. 残留文件使用场景1. 磁盘告警或集群只读时，可使用此工具进行排查2. 当磁盘使用率出现倾斜时，可使用此工具进行排查参数说明-t  使用模式，可设置diskusedcheck，fastcheck，largetablecheck，detailcheck四种：    diskusedcheck模式：识别集群内磁盘使用率超过阈值的盘；    fastcheck模式：对单DN或单盘目录下所有DN进行快速的磁盘空间使用检查，包括pg_xlog目录，archive归档目录，pg_cbm目录，pgsql_tmp临时文件下盘目录；    largetablecheck模式：对单DN或单盘目录下所有DN进行大表检查，识别占用空间大于阈值的表（对于分区表，每个分区单独统计）；    detailcheck模式：顺序执行fastcheck与largetablecheck。-D  扫描路径，可以指定DN数据目录，也可以指定磁盘路径，当指定磁盘路径时，如果磁盘下有多个DN，会对多个DN都进行检测：    如果磁盘下有多个DN，会对多个DN都进行检测：    当模式为diskusedcheck时，不支持设置-D参数    当模式为fastcheck，largetablecheck，detailcheck时，-D参数不能为空，不可缺省    当模式为largetablecheck时，-D参数不支持设置为从备DN路径，如果-D参数设置为磁盘路径并且磁盘下存在从备DN，会跳过对从备DN的检查-s  大表阈值，仅当模式为largetablecheck或detailcheck时支持设置-s参数；默认值5，单位GB，即识别DN目录下单表或单分区大于5G的对象。可缺省。-u  磁盘使用率阈值，仅当模式为diskusedcheck时支持设置-u参数；默认值90，单位%，可缺省。说明：参数推荐值：当集群已经只读时，使用默认值90进行检查。当收到磁盘告警，但是未只读时，使用阈值70进行检查。未收到磁盘告警，发现明显倾斜时，根据正常磁盘使用率和倾斜磁盘的使用率灵活设置阈值，例如，在单节点发现正常磁盘使用率35%，倾斜磁盘使用率55%，此时可以选择阈值40进行检查。-h  获取简易使用说明。使用方法识别集群内磁盘使用率超过阈值的盘，-u设置70，即此命令可以将集群内磁盘使用率高于70%的盘识别出来：sh gs_diskusedcheck.sh -t diskusedcheck -u 70对单个DN或单个磁盘进行快速检查：sh gs_diskusedcheck.sh -t fastcheck -D /DWS/data1/h0dn1/primary0sh gs_diskusedcheck.sh -t fastcheck -D /DWS/data1当-D参数值为DN路径时，检查对应DN；当-D参数值为磁盘路径时，对该磁盘下所有DN实例进行顺序检查。对单个DN或单个磁盘进行大表检查：sh gs_diskusedcheck.sh -t largetablecheck -D /DWS/data1/h0dn1/primary0 -s 5sh gs_diskusedcheck.sh -t largetablecheck -D /DWS/data1 -s 5对于分区表，如果多个分区大小都超过阈值，会重复打印多次主表，relfilenode为实际分区的relfilenode，但是size为整个表的大小。结果分析当出现只读或磁盘告警时，快速识别磁盘使用率大于70%的磁盘：sh gs_diskusedcheck.sh -t diskusedcheck -u 70结果打印包含节点名称与磁盘名称，若打印结果为空，则说明当前磁盘使用率已恢复70%以下，为自恢复场景，考虑以下三种场景：1) 临时下盘文件过多。2) create table as select建表倾斜。3) 在事务中创建表并insert导入数据倾斜。明确使用率高的磁盘后，登录对应节点，对该盘下的所有DN进行快速检查：sh gs_diskusedcheck.sh -t fastcheck -D /DWS/data1从结果信息中关注下列信息：1) “check xlog size”结果为pg_xlog目录大小，此项检查结果大于10G说明磁盘使用率高的原因为xlog积压，可按照xlog积压场景进行排查。2) “check archive size”结果为archive归档目录大小，此项检查结果大于10G说明磁盘使用率高的原因为打开了xlog归档参数，可关闭archive_mode参数，并手动清理archive目录下的文件。3) “check cbm size”结果为pg_cbm目录大小，此项检查结果大于10G说明磁盘使用率高的原因为cbm文件过多，可考虑手动清理pg_cbm目录下的文件，并将下一次备份策略改为全量备份。4) “check tmp size”结果为pgsql_tmp目录大小，此项检查结果大于10G说明磁盘使用率高的原因为语句临时下盘文件过大，在此项结果下方会打印当前正在产生下盘文件的sql语句，可对这些语句进行查杀并反馈给业务优化。若各检查项无明显异常，则对磁盘下的所有DN进行大表检查，同时对一个正常DN进行大表检查，将结果进行对比，识别倾斜的大表并反馈业务整改；sh gs_diskusedcheck.sh -t largetablecheck -D /DWS/data1 -s 5sh gs_diskusedcheck.sh -t largetablecheck -D /DWS/data3/h1dn1/primary0 -s 5如下图，通过对比可发现dm_psi.rpt_psi_cbg_property_so_si_f_rpt_for_prdct_swith在倾斜的DN上大小为424GB，在正常DN上未检测出结果，说明大小小于检测阈值5G，所以该表存在严重的数据倾斜；同样的，通过对比可发现dm_psi.dm_psi_cbg_property_so_si_f_rpt_for_prdct_swith在倾斜的DN上大小为416GB，在正常DN上未检测出结果，说明大小小于检测阈值5G，所以该表也存在严重的数据倾斜。注：若所有磁盘使用率都高，不存在倾斜，则不需要对多个DN进行检查结果比对，只需对一个DN进行检查识别大表处理即可。​​对于有isCreating标记的对象，说明relfilenode在系统表中未找到记录，但是打开脏数据后找到了记录，可考虑以下场景：1) vacuum full或create table as语句正在执行未提交，可根据表名在活跃语句中检查是否存在相关语句。2) 备份期间延迟DDL文件导致已经drop的对象文件未回收，可通过文件产生时间结合当前备份任务进行判断。3) 文件残留，此场景需联系研发进行处理。对于有not found标记的对象，说明relfilenode在系统表中未找到记录，打开脏数据后也未找到记录，可考虑以下场景：1) 备份期间延迟DDL文件导致已经drop的对象文件未回收，可通过文件产生时间结合当前备份任务进行判断。2) 文件残留，此场景需联系研发进行处理。

本片案例适用场景：other内存高，且other内存会随业务起伏other内存，通常表示除去GaussDB内核使用的内存以外的内存使用。分为堆内存和非堆内存，堆内存的排查通常需要替换lib包后，使用jeprof进行排查，详细排查此篇不进行展开，需要dws开发人员进行排查。而非堆内存，通常指栈内存，此类内存无法利用jeprof排查，本篇帖子主要讲解的就是该类内存的排查和处理方法。【判断other内存高】可通过如下语句，整体判断other内存是否偏高，本篇主要关注其中的other_used_memory和max_process_memory，当other_used_memory持续高于max_process_memory的70%的时候，cma会杀掉对应的实例。with a as (select * from pgxc_total_memory_detail where memorytype='dynamic_used_memory'),b as (select * from pgxc_total_memory_detail where memorytype='dynamic_peak_memory'), c as (select * from pgxc_total_memory_detail where memorytype='max_dynamic_memory'), d as (select * from pgxc_total_memory_detail where memorytype='process_used_memory'), e as (select * from pgxc_total_memory_detail where memorytype='other_used_memory'), f as (select * from pgxc_total_memory_detail where memorytype='max_process_memory') select a.nodename,a.memorymbytes as dynamic_used_memory,b.memorymbytes as dynamic_peak_memory, c.memorymbytes as max_dynamic_memory,d.memorymbytes as process_used_memory,e.memorymbytes as other_used_memory,f.memorymbytes as max_process_memory from a,b,c,d,e,f where a.nodename=b.nodename and b.nodename=c.nodename and c.nodename=d.nodename and d.nodename=e.nodename and e.nodename=f.nodename order by a.nodename;【线程过多导致非堆内存高】非堆内存高通常发生在dn上，dws的每个线程都会申请一定的栈空间，当前dws设定的每个内存可申请最大栈空间为16MB，语句越复杂，单个线程所消耗的栈内存就越多。当集群内部线程数量过多时，会造成比较大的内存消耗，other内存就会冲高。反过来讲，当线程被销毁后，栈内存也会释放，ohter内存也会下降。所以业务表象上，是other内存偏高，且other内存随业务高低峰起伏。【排查非堆内存高】当满足上述特征，就可以对之进行排查。排查需要直连dn进行排查，后续的命令都需要直连问题dn执行，如果你是客户端只能连接cn，无法直连dn，可通过execute命令执行，但需要注意引号规则变化，单引号应替换为两个单引号。例：execute direct on (dn_6001_6002) 'select * from pv_total_memory_detail where memorytype = ''other_used_memory''';1. 排查stream线程池中的线程是否偏多dws中dn与dn交互，依赖stream线程，语句使用完stream后，可以把stream线程放回stream线程池，待下一次复用，如果池中线程过多，可能造成非堆内存高。select count(*) from pg_thread_wait_status where thread_name like '%StreamPool%';show max_stream_pool;如果是该场景，建议调小max_stream_pool值，调整值请参考官方产品文档，max_stream_pool=MIN(max_connections, max_process_memory/16/5MB, 1024)2.排查活跃的线程是否偏多首先排查整体的活跃线程是否偏多select count(*) from pg_thread_wait_status where tlevel>0;如果的确偏多，可排查是否有占用stream特别多的语句select query_id , count(*) from pg_thread_wait_status group by 1 order by 2 desc limit 20;①如果没有stream数特别高的语句，那有可能是并发太高了，需要控制并发数。②如果找到了stream数特别高的语句，则需要连接cn，通过前面查到的query_id，找到对应语句，然后对语句进行整改。或者是设置参数max_streams_per_query，让stream数过多的语句报错退出。select * from pgxc_stat_activity where query_id in (xxx, xxx);