问题描述用户的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);

1. 升级前操作问题现象：租户面进入数据库内核升级，内核升级执行失败。进入沙箱，在$GAUSSLOG/om/gs_upradectl*日志中发现，执行升级失败，执行回滚失败。查看cn-1-1节点的$GAUSSLOG/om/gs_local*日志。升级SQL对系统表的更新导致锁等待超时失败处理方法：1）升级前检查并设置环境中死锁配置参数值。gsql postgresql://:8000/postgres?application_name='OM' -r -c 'show deadlock_timeout'参数小于10min，则执行下面命令设置gs_guc reload -Z datanode -Z coordinator -N all -I all -c 'deadlock_timeout=10min'2）重入。根据2章节进行处理3）如果guc参数有设置升级完成后，恢复guc参数gs_guc reload -Z datanode -Z coordinator -N all -I all -c 'deadlock_timeout=获取的值'2.升级中规避方法问题现象：升级SQL对系统表的更新导致锁等待观察方法：登录集群第一个cn节点，切换Ruby用户，进入沙箱。根据如下命令查看升级进度。tail -f $GAUSSLOG/om/gs_upgradectl*.log当日志刷新执行到 '-t update_catalog'。登录数据库观察锁情况。循环执行如下SQL:SELECT datname, query_start, query FROM pgxc_stat_activity WHERE application_name='OM'; SELECT 'EXECUTE DIRECT ON(' || nodename || ') ''SELECT pg_terminate_backend('||pid||')'';' kill_query, dbname, query FROM pgxc_lock_conflicts ;说明：升级过程中执行的命令和其他语句锁冲突，锁超时报错（升级的时候冲突，回滚的时也会冲突，所以不仅会导致升级卡住，还会导致回滚卡住）处理方法：登录集群第一个cn节点，切换Ruby用户，进入沙箱。 执行如下SQL获取冲突SQL。将卡住升级的SQL语句全杀掉。例如：SELECT 'EXECUTE DIRECT ON(' || nodename || ') ''SELECT pg_terminate_backend('||pid||')'';' kill_query, dbname, query FROM pgxc_lock_conflicts where query not ilike '%ADD COLUMN%';①带 ADD COLUMN 的是升级执行的语句，其余全杀②杀语句的多条命令一起执行，一起杀。否则可能死锁导致命令快速失败。kill的SQL直接通过查询语句获取。

Linux 中 Shell 编程的奇妙世界在 Linux 系统中，Shell 编程是一种强大而灵活的工具，它允许用户通过编写脚本来自定义和自动化各种任务。无论是系统管理员还是普通用户，都可以利用 Shell 编程来提高工作效率和系统管理的便捷性。本文将带你深入了解 Linux 中的 Shell 编程，包括基本概念、语法、常用命令以及实际应用，并包含丰富的代码示例。一、Shell 编程简介Shell 是一种命令行解释器，它接收用户输入的命令，并将其传递给操作系统执行。Shell 编程则是使用特定的 Shell 语言来编写脚本，这些脚本可以包含一系列命令、变量、控制结构和函数，以实现更复杂的任务。常见的 Shell 有 Bash、Zsh、Ksh 等，其中 Bash（Bourne Again Shell）是最广泛使用的一种。本文将以 Bash 为例进行介绍。二、Shell 编程基础变量定义变量：在 Shell 中，可以使用name=value的形式来定义变量。例如：my_var="Hello, World!"。引用变量：使用$variable_name来引用变量的值。例如：echo $my_var将输出"Hello, World!"。变量类型：Shell 中的变量没有严格的类型定义，可以存储字符串、数字等各种类型的值。命令替换可以将一个命令的输出作为另一个命令的参数或变量的值。例如：my_dir=$(pwd)将当前工作目录的路径存储在变量my_dir中。输入输出重定向>：将命令的输出重定向到一个文件，如果文件已存在，将覆盖原有内容。例如：ls > file_list.txt将当前目录下的文件列表输出到file_list.txt文件中。>>：将命令的输出追加到一个文件。例如：echo "New line" >> file_list.txt在file_list.txt文件末尾添加一行内容。<：将一个文件的内容作为命令的输入。例如：sort < file_list.txt对file_list.txt文件中的内容进行排序。三、控制结构条件判断if语句：用于根据条件执行不同的代码块。例如：if [ $my_var = "Hello" ]; then echo "Variable is Hello" else echo "Variable is not Hello" ficase语句：用于根据不同的情况执行不同的代码块。例如：case $my_var in "Hello") echo "Variable is Hello";; "World") echo "Variable is World";; *) echo "Variable is something else";; esac循环for循环：用于遍历一个列表或执行固定次数的循环。例如：for i in {1..5}; do echo $i donewhile循环：用于根据条件进行循环。例如：count=0 while [ $count -lt 5 ]; do echo $count count=$((count + 1)) done四、函数在 Shell 中，可以定义函数来封装可重复使用的代码块。例如：function my_function() { echo "This is my function" } my_function函数可以接受参数，参数可以在函数内部使用$1、$2等变量来引用。例如：function greet() { echo "Hello, $1!" } greet "John"五、实际应用示例自动化备份以下是一个简单的 Shell 脚本，用于备份指定目录到另一个位置：#!/bin/bash source_dir="/path/to/source" destination_dir="/path/to/destination" date=$(date +"%Y%m%d%H%M%S") backup_name="backup_$date.tar.gz" tar -czf $destination_dir/$backup_name $source_dir系统监控可以使用 Shell 脚本定期检查系统资源的使用情况，并在出现问题时发送通知。例如：#!/bin/bash while true; do cpu_usage=$(top -bn1 | grep "Cpu(s)" | awk '{print $2 + $4}') memory_usage=$(free | grep "Mem" | awk '{print $3/$2 * 100}') if [ $(echo "$cpu_usage > 80" | bc -l) -eq 1 ]; then echo "High CPU usage: $cpu_usage%" fi if [ $(echo "$memory_usage > 80" | bc -l) -eq 1 ]; then echo "High memory usage: $memory_usage%" fi sleep 60 done六、总结Shell 编程是 Linux 系统中非常强大的工具，它可以帮助用户自动化各种任务、提高工作效率和系统管理的便捷性。通过掌握 Shell 编程的基本概念、语法和常用命令，以及实际应用示例，你可以更好地利用 Linux 系统的强大功能。希望本文对你在 Linux 中的 Shell 编程之旅有所帮助。

前提:我们其中一个节点服务器做了raid5磁盘阵列重建, 之后用gs_replace -t config -h  xxx  和gs_replace -t start -h做了集群恢复.目前集群恢复至Normal状态.现象:       业务方反馈说, 做完操作后,使用kettle连接数据库经常断连, 有时成功有时失败,  且写失败次数大于读失败次数       已排除网络问题, 且业务方如果手动执行SQL正常,但大,长SQL无法正常执行这种情况怎么处理?