【问题版本】 HCS830【问题描述】 安装部署扩容时DWS和ECF多个容器安装工步失败【问题影响】 无【问题根因】 CDK节点到镜像仓库网络不通【定位过程】 1、工步详情界面报异常为：code：500，Deploy service status abnormal 容器状态异常；2、安装部署安装多个容器工步报错，查看导出日志发现报错：容器镜像拉取失败，超时；{"podName":"dwsmaintaintool-XXXXXXXX-XXXX","uid":"XXXXXX-XXXX-XXXX-XXXX-XXXXXXXX","hostIP":"XX.XX.XX.XX","creationTime":"2023-12-28T14:59:56Z","status":"Pending","lifeName":"image","message":"Failed to pull image \\\\"cdk-api.cs.cloudoc.nxjiaotou.com:20202/op_svc_cdk/dwsmaintaintool-aarch64:8.3.0.2023XXXXXXXXXX\\\\": rpc error: code = Unknown desc = Error ****on: Get https://cdk-api.cs.cloudoc.nxjiaotou.com:20202/v2/: net/http: ****led while waiting for connection (Client.Timeout exceeded while awaiting headers)","reason":"FailedPullImage","eventTime":"2023-12-28T15:00:16Z","advice":null}3、到后台去查看容器状态，发现拉取镜像失败；kubectl describe pod <podname> -n <namespace>4、CDK节点curl镜像仓地址加端口不通，是CDK节点到镜像仓网络不通，建关联单，找CDK同事；（IP可在CDK镜像管理里面查）5、CDK同事让只需要集群节点到镜像仓库的地址:20202放通，服务网段和容器网段不用管，网络打通后，重试工步成功；【规避措施】        CDK节点IP到镜像仓库的地址:20202端口放通后重试工步

课程内容视频链接1、GaussDB(DWS)产品介绍cid:link_12、GaussDB(DWS)集群部署与管理cid:link_23、GaussDB(DWS) 数据迁移cid:link_34、GaussDB(DWS) 数据库对象设计cid:link_45、GaussDB(DWS) SQL进阶及应用开发指南cid:link_56、GaussDB(DWS)事务、锁机制管理cid:link_67、GaussDB(DWS)资源负载管理cid:link_78、GaussDB(DWS)性能调优cid:link_89、GaussDB(DWS)安全与权限设计cid:link_910、GaussDB(DWS) 补丁、升级及扩容流程cid:link_1011、GaussDB(DWS) 备份与恢复cid:link_1112、GaussDB(DWS) 日常巡检cid:link_12DWS最佳实践博客链接DWS最佳实践（一）DWS表设计cid:link_13DWS最佳实践（二）DWS数据的导入方式cid:link_14DWS最佳实践（三）DWS数据库日常运维操作cid:link_15DWS最佳实践（四）用户权限管理cid:link_16DWS最佳实践（五）DWS数据库的SQL调优基础cid:link_16DWS技术博客博客链接1、GaussDB for DWS高可用之主备从HA技术cid:link_172、GaussDB For DWS 字符集浅谈cid:link_183、GaussDB(DWS)存储系列之行存表cid:link_194、Gauss行列存储压缩总结cid:link_20​5、GaussDB(DWS)之数据库对象设计cid:link_216、GaussDB for DWS 高可用之数据复制cid:link_227、GaussDB(DWS)数据量太大？试试GDS并行导入cid:link_238、GaussDB(DWS) GDS导入容错详解cid:link_249、GaussDB(DWS)实践系列-性能优化最佳实践cid:link_2510、WDR-GaussDB(DWS)的性能监测报告cid:link_011、GaussDB(DWS)性能调优系列基础篇一：万物之始analyze统计信息cid:link_2612、GaussDB(DWS)性能调优系列基础篇二：大道至简explain分布式计划cid:link_2713、GaussDB(DWS)性能调优系列基础篇三：衍化至繁之分布式计划详解cid:link_2814、GaussDB(DWS)性能调优系列实战篇一：十八般武艺之总体调优策略cid:link_2915、GaussDB(DWS)性能调优系列实战篇二：十八般武艺之坏味道SQL识别cid:link_3016、GaussDB(DWS)性能调优系列实战篇三：十八般武艺之好味道表定义cid:link_3117、GaussDB(DWS)性能调优系列实战篇四：十八般武艺之SQL改写cid:link_3218、GaussDB(DWS)性能调优系列实战篇五：十八般武艺之路径干预cid:link_3319、GaussDB(DWS)性能调优系列实现篇六：十八般武艺Plan hint运用cid:link_34

扩容重分布时，如果带着严重倾斜的大表重分布，存在风险，可能造成磁盘满，导致集群降级甚至不可用。根因分析：倾斜表是由于分布键设置不合理，导致表的数据集中到少量dn上造成的。扩容重分布时，需要将所有表重新生成一遍，此时集群磁盘使用会上升，而且重分布期间集群不会只读，重分布倾斜的大表时，可能使磁盘空间达到95%，导致实例被杀，从而造成集群降级甚至不可用。注意：以下操作可能涉及高危命令，请在华为研发人员指导下运行1.将集群设置为只读（视情况决定是否关闭白名单）gs_guc reload -Z coordinator -Z datanode -N all -I all -c "default_transaction_read_only=on"2.停止只读检测，让集群恢复降级（停止磁盘95%杀实例的机制）gs_guc reload -Z cm -N all -I all -c "enable_transaction_read_only=off"3.排查磁盘满原因，根据磁盘满原因进行处理。（本文只讨论由于倾斜导致盘满的情况）4.找到倾斜的表，数据量小的情况可全库扫描倾斜表，数据量大的情况，可通过倒推法找到【总结】【数据倾斜】通过倒推法找出数据倾斜严重的表_数仓GaussDB(DWS)_大数据_华为云论坛 (huaweicloud.com)5.如果找到的表是形如data_redis.data_redis_tmp_XXX的临时表，XXX为原表oid，找到其原表并记录select * from pg_class where oid = XXX;6.确认排查工作完成后，解除只读gs_guc reload -Z coordinator -Z datanode -N all -I all -c "default_transaction_read_only=off"7.drop掉前面找到的临时表8.等待集群恢复正常后（如果有严重xlog堆积的情况，可以考虑全量build，注意是否有磁盘100%风险），均衡集群checkpoint;       (任意cn上执行3次)cm_ctl switchover -a9.将倾斜的原表设置为跳过重分布，XXX为表的oidupdate pgxc_class set redis_order=0 where pcrelid = XXX;10.获取建表语句后，创建一个和原表表定义相同，但分布方式合理的新表select * from pg_get_tabledef('schema名.表名');11.将原表数据导入新表insert into 新表 select * from 原表;12.确认数据无误后，将原表重命名为原表_bak，将新表重命名为原表，再度确认无误后，删除原表_bak。（无法回退，请操作前务必确认清楚！）此刻，该表重分布已完成13.开启只读检测，再度拉起重分布（如果有关闭白名单，记得开启）gs_guc reload -Z cm -N all -I all -c "default_transaction_read_only=on"后记：应急处理，耗时耗力，还有风险。提前处理，防范于未然，方乃上策。扩容前信息收集（./gs_check -e collect）的倾斜表NG项勿忽视，带病变更不可取。

XID是每一个写事务唯一的标识并不是每个事务一开始就分配XID，只有在发生写操作需要XID时才会分配为什么只给写事务分配xid

GaussDB(DWS) 813版本pgxc_wlm_session_statistics授权问题【版本信息】813；821【 问题现象】813版本非管理员用户无法查询其他用户的pgxc_wlm_session_statistics图一：pgxc_wlm_session_statistics报错【原因分析】821版本提供预置角色功能，使非管理员权限用户可访问特定的信息和功能，操作方法为切换至gs_role_read_all_stats角色。图二：gs_role_read_all_stats说明图三：gs_role_read_all_stats操作【处理方法】部署一下脚本：CREATE OR REPLACE FUNCTION func_wlm_session_statistics()RETURNS TABLE (datid oid, dbname name,schemaname text,nodename text,username name,application_name text,client_addr inet,client_hostname text,client_port integer,query_band text,pid bigint,block_time bigint,start_time timestamp with time zone,duration bigint,estimate_total_time bigint,estimate_left_time bigint,enqueue text,resource_pool name,control_group text,estimate_memory integer,min_peak_memory integer,max_peak_memory integer,average_peak_memory integer,memory_skew_percent integer,spill_info text,min_spill_size integer,max_spill_size integer,average_spill_size integer,spill_skew_percent integer,min_dn_time bigint,max_dn_time bigint,average_dn_time bigint,dntime_skew_percent integer,min_cpu_time bigint,max_cpu_time bigint,total_cpu_time bigint,cpu_skew_percent integer,min_peak_iops integer,max_peak_iops integer,average_peak_iops integer,iops_skew_percent integer,warning text,queryid bigint,query text,query_plan text,node_group text)LANGUAGE plpgsqlSECURITY DEFINERAS $$DECLAREBEGINRETURN QUERY EXECUTE 'select * from pgxc_wlm_session_statistics t';END $$;部署完成后，输入以下命令行运行脚本：grant execute on pro_monitor.func_wlm_session_statistics to fin_dmr_sre; 即可解决813版本无法授权查询pgxc_wlm_session_statistics问题。若授权依旧失败：则问题汇总为：授予普通用户预置角色gs_role_read_all_stats权限，不能通过pgxc_wlm_session_statistics查询所有用户的会话信息 ，只能看到当前用户自己信息：这是813受限制，821可实现。通过Function 的定义函数，使用管理员创建该函数，授予普通用户执行权限，这样普通用户可以看到其他用户会话，但是只能看到单个cn，如何才能看到所有cn：这个呢？这个已经不是权限问题了，绕过了813限制的问题 对于上述问题建议以下方案：赋权管理员权限操作升级8.2.1以上版本

【问题版本】 管控面821扩容【问题描述】 ECF安装运维容器工步失败【问题影响】 无【问题根因】 scc.domain.id的值存在问题，无法解析【定位过程】1、工步报错报Unexpected response from server: {'status': 500, 'message': 'invoke aos preview stack failed 调用aos预览堆栈失败；2、查看详细日志报错内容包含scc.domain.id，定位是821的scc.domain.id的值存在问题，导致无法解析，CDK脚本cdk_api_internal.py 1090报错。【规避措施】 1）登Turkey后台节点，修改/opt/cloud/hcci/src/HCCI/projects/project_id/plugins_cloudservice/ECF/params/dws-maintain.json文件；2）在该文件中scc.domain.id值的302前后增加英文双引号；（该后为  "scc.domain.id": "302",）3）重启docker容器，docker restart hcci_exec_project_id并重试工步。

为推动云原生数据仓库的技术创新和数智融合发展的新需求、新趋势、新路径，为相关行业内的企业、高校和个人，建立一个强大的知识、资源共享平台，共同推动数智化时代的创新和进步。2023年12月23日，由华为云开发者社区HCDG天津地区核心组与华为（天津）开发者创新中心在天津市滨海新区中新生态城，共同举办了“华为云数仓专家带你玩转GaussDB(DWS)云原生数据仓库”，开启了一场精彩的行业对话和专业探讨。活动开始，由华为（天津）开发者创新中心代表嘉宾韩清致开场词。韩清介绍了华为开发者创新中心的发展历程，即从2018年在天津市滨海新区成立华为云基地，到今年2023年7月正式成立北方首家华为开发者创新中心，全国的第三个开发者创新中心。作为国家首批智慧城市建设试点和世界智能大会永久展示基地，华为（天津）开发者创新中心将通过打造“开发者生态赋能平台”、“国家级转型试点平台”、“人才培养示范平台”、“生态运营服务平台”四大平台，为企业提供全方位、链条化的数字云服务，为数字产业高质量发展注入强劲动能。韩清表示，创新中心将从技术构建、业务合作活动等多种形式进行交流，同时欢迎大家加入天津HCDG，在华为云生态的建设中，共同探索和实践了多个创新项目，并对参加本次活动的企业代表、学生代表、开发者个人表示深深的感谢。在未来，华为（天津）开发者创新中心将会携手共同构建一个更开放、创新的生态系统。分享环节华为云数仓GaussDB(DWS)架构师专家周孟韬，分享了“GaussDB(DWS)云原生数仓技术”，从技术和业务两个角度，深入介绍GaussDB(DWS)云原生数据仓库的技术原理、特点、优势和应用案例。展示GaussDB(DWS)云原生数据仓库技术如何帮助企业实现数据资产最大化利用，提升数据分析的价值和效率，助力企业数字化转型，共同探讨数据仓库的发展趋势和挑战。周老师从“数据仓库的起源”、“数据仓库发展趋势”、“GaussDB(DWS)演进历程”等方面分享了自己对数据仓库算力基座的一些思考。同时，结合GaussDB(DWS)的研发工作及架构演进以及实际案例，如大家日常使用的电费账单分析，年度支付账单分析，公司的财务报表，训练AI大模型的数据处理等，解密大数据背后的支撑技术，以及多数开发者在研发过程遇到的难题和痛点，对实时、全场景分析、智慧数仓的开发思路。华为云数仓GaussDB(DWS)已经广泛应用于1700+大客户的核心业务中，基于华为云底座能力打通数据壁垒，通过湖仓一体与大数据互联互通，体验纵向的融合分析，借助数据生产线与AI生产线的高效配合，进行快速开发。特别是利用云原生的方式进行弹性放缩，按需、高性价比地适应灵活多变的业务需求。最后，周老师还表达了自己对华为天津开发者的创新方法和未来探索的祝福。同时分享了使用华为云实验沙箱进行体验的方法。感兴趣的伙伴也可以点击链接进行体验。#快速入门数据仓库服务GaussDB(DWS) cid:link_0#体验GaussDB(DWS)云原生数仓-湖仓一体 cid:link_1#体验GaussDB(DWS)云原生数仓-存算分离 cid:link_2​本场活动还特别邀请到华为云全球生态部，资深技术专家刘震。刘老师也是冒着北方的寒冬，不远万里从深圳飞到天津。刘老师从数据治理的目标与挑战、数据治理案例分享以及数据治理展望与畅享的角度。让大家对数据治理有了初步的了解和认识，并推荐了《华为数据之道》这本书，方便大家进一步深度学习。​交流环节提问交流环节中，学生和在职开发者针对自己的实际情况，向演讲的嘉宾提出了许多关于专业知识、行业发展询问。比如，“作为在校大学生或刚刚就业，如何学习大数据以及数据治理，有什么建议？”华为云数仓GaussDB(DWS)架构师周孟韬先生建议，根据个人专业、兴趣、城市发展等方面做个人职场能力的简历梳理，同时提前了解市场对人才需求情况，可以通过参与一些创新中心及天津HCDG的活动去提升认知，并思考个人能为企业解决什么实际问题。在积极热烈的交流环境下，活动接近尾声，大家合影留念后还持续不断从技术应用、个人发展等角度继续交流。以打造“开发者生态赋能平台”“国家级转型试点平台”“人才培养示范平台”“生态运营服务平台”四大平台为先的华为（天津）开发者创新中心，华为云天津HCDG开发者社区组织，以自身在华为云的实践出发，了解并满足开发者诉求，扎根技术本身，共建创新应用。未来，天津HCDG将一同携手广大开发者，共同延续华为云开发者社区精神，共创更多领域新生态。

【问题描述】 CES监控页面不显示【问题影响】 无【排查思路】两方面排查1、界面显示MO侧负责，可以先给MO侧间关联单排查（确认数据已经上报）；2、数据上报DWS侧负责，同步先排查DWS侧节点数据上报是否有异常；【定位过程】 数据上报问题1、登CCN节点排查日志，查询/home/Ruby/log/ces/ces.log是否打印正常；1）若日志中有报错：The post request return code is：401，content is2）查看配置文件 /home/Ruby/InitCes.json 是否异常，和正常显示指标的集群节点进行比对，获取正确，ak，sk，替换即可；（案例：cid:link_1）3）若无正确AKSK，需要手动在后台轮转；（案例：cid:link_0）4）若guestAgent版本太低会手动轮转失败，需要升guestAgent；2、查看/home/Ruby/log/cloud-dws-do_checkperf.log是正常采集的；3、查看每个节点Ruby用户下定时任务是否丢失、被修改，定时任务脚本是否执行（主要关注以下两个）；* * * * source /etc/profile;source ~/.bashrc; sh /rds/mgntAgent/v8.X.X_XXXX_XXXXX/dataReport.sh >/dev/null 2>&1*/4 * * * * source /etc/profile;source ~/.bashrc; nohup python3 /rds/datastore/dws/v8.X.X_XXXX_XXXXX/checkPerf.py >> /dev/null 2>&1 &4、定时任务若有问题，恢复需要crontab -e更改正确（参考好的节点），等一分钟，一分钟执行一次数据上报；

【问题版本】HCS821 管控面810->811升级后【业务影响】界面显示不准【问题描述】OC有license超容告警，页面显示容量比实际多或少【问题根因】811前老版本就没有license，需要手动插入数据；【规避措施】情景一：多统计了400状态节点核数 :规避措施1：在rms数据库rds_instance表删除状态为400的实例数据；（此情况是多统计了400状态的，需要手动删除） 1）.rms查询sql(包含400状态)：select ifnull(sum(x.value), 0) from rds_cluster r join rds_cluster_spec s on r.clusterSpecId = s.id join rds_cluster_instance_resspec t on r.clusterSpecId =t.cluster_spec_id join rds_instance y on r.id = y.clusterId join rds_resspecattr x on t.instance_spec_id = x.specId where r.status in ('199', '200') and x.attrCode = 'cpu';2）先备份原表：create table rds_instance_xxxxxxxx select * from rds_instance; 3）.删除状态为400 得：delete from rds_instance where clusterid='集群id' and status=400； 4）.5min后检查license页面是否正常; 情景二：只显示了部分集群的核数，且license_used数据为空或缺少:规避措施2：在rms数据库license_used表插入实际所有集群节点总核数数据；（此情况是811前没有这个表，需要手动插入） 1）.查询license_used表：select * from license_used； 2）.查询所有非400状态集群，并计算实际核数： select id,name,status from rds_cluster where status!='400'; select y.name,y.status from rds_cluster r join rds_instance y on r.id=y.clusterid where r.id in ('集群id') and y.status!='400'; 3）先备份原表：create table license_used_xxxxxxxx select * from license_used; 4）.插入数据：insert into license_used(cluster_id,cluster_status,cpu_count,node_cpu,data_used) values('集群id','200','集群节点总核数','单节点核数',''); 5）.5min后检查license页面是否正常； 长期措施：建议用户租户面升级到和管控面版本适配的版本就可以了，后面就不会出这问题了；

通过SQL on other GaussDB的方式进行高斯数据库跨库数据同步，发现目标端的一个高斯外表查询语句会在源端启动24个并发查询。如果同时查询的数据量过多，有把cn的连接数占满的风险，想请教下怎么降低SQL on other GaussDB在源端查询的并发度

背景：线下纯软集群部署时，因DWS没有机架感知策略、无法将安全环组内节点打散到不同机柜。客户现场是40台数据节点主机，每节点2个主dn，主机名为host111~host150，对应ip为x.x.x.111~x.x.x.150。111~120一个机柜(柜内从下往上顺序放置)，其他三组一样。问题：1. 纯软部署时，安全环的分配流程是什么，每组安全环是按照什么逻辑去分配的，ip或主机名的字典排序么？              尝试将配置规划工具LLD的“IP规划与进程部署”中的IP打散，不依照host111~host150的顺序填充，生成的集群部署installTemplet.xml文件显示实例是IP打散后的情况，但安装集群完毕后查看实例拓扑信息，最终仍然是按照111~150的顺序配置的安全环，即111~113一组环、114~116一组环、117~119一组环...          2. 部署时，如何根据现服务器柜内部署情况，自定义安全环的分配即考虑反亲和性提升组网架构的高可用性。

  【问题现象】  备份失败，报错write to compile failed! expected size xxxx, actual size 0!    【原因分析】出现该问题的可能原因如下：1. 备份介质空间占满，备份文件无法正常写入2. roach侧并发太大，导致备份介质负载大，备份报错【排查方法】步骤1：找任意节点查看备份内核日志，确认备份下发节点：沙箱内进行备份日志目录cd /DWS/manager/backup/log注：此目录为HC/HCS/HCSO集群自动备份日志目录，线下集群/后台调用备份命令日志路径：$GAUSSLOG/roach/agent。grep -i "Master IP:" *步骤2：登录备份下发节点确认首次备份/恢复报错节点：从本次备份开始搜索ERROR关键字，根据本次备份/恢复第一次报错，找到上报失败节点：步骤3：登录首次备份/恢复失败节点，查看备份/恢复失败原因从本次报错开始搜索ERROR关键字，确定备份/恢复失败原因：报错：write to compile failed! expected size xxxx, actual size 0!There is an error in storage media.怀疑是备份介质的问题，到对应的roach_client节点查看相应日志，通过grep "Success to connected Remote Media" roach_agent*.log，找到roach_client的ip地址，ssh到对应的roach_client节点，根据对应roach_client节点报错日志协调介质侧同时分析  【处理方法】1、检查备份介质剩余空间是否满足一次备份的空间需求，若空间不足先处理空间问题再重新拉起备份2、如果是并发问题，建议调大filesplit-size参数并减小parallel-process参数，重新拉起备份      

【问题现象】细粒度恢复表失败，报错table is not found,which has been dropped during backup【原因分析】出现该问题的可能原因如下：1. 目标表在备份过程中已经drop，并未备份到完整的表信息2. 后台调用恢复命令时待恢复的table_list文件书写异常导致表名未正确识别【排查方法】  步骤1：找任意节点查看备份内核日志，确认备份下发节点：沙箱内进行备份日志目录cd /DWS/manager/backup/log    注：此目录为HC/HCS/HCSO集群自动备份日志目录，线下集群/后台调用备份命令日志路径：$GAUSSLOG/roach/agent。grep -i "Master IP:" *步骤2：登录备份下发节点确认首次备份/恢复报错节点：从本次备份开始搜索ERROR关键字，根据本次备份/恢复第一次报错，找到上报失败节点：步骤3：登录首次备份/恢复失败节点，查看备份/恢复失败原因从本次报错开始搜索ERROR关键字，确定备份/恢复失败原因：找到对应报错：part ddl not restored success.restored table 95,expected 101.根据以上报错信息可知本次恢复期望恢复101张表，但是实际恢复只找到了95张表的ddl，通常是由于书写table_list文件时粘贴复制等其他操作导致文件中书写的列表多出一些空格或者制表符或者其他，恢复过程中部分表无法正常识别。【处理方法】1、检查table_list文件，删除多余空格、制表符等，保持文件的每一行为包含格式为<模式名称> .TableName的单个条目，确认table_list文件内容正确后重新拉起恢复      

【版本信息】所有版本【问题现象】业务报错：memory is temporarily unavailable【原因分析】出现该问题的原因主要是由于当前sql执行时，可用的动态内存不足，导致无法申请到足够的动态内存，触发报错。动态内存不足的常见场景如下：某个SQL占用内存高，导致其他sql内存不足，此时需要找到高内存sql进行业务优化内部空闲连接占用内存高，导致sql执行内存不足，此时需要清理空闲连接【处理方法】若问题持续存在，且当前仍在发生，可通过如下方式处理：步骤一：查看当前动态内存使用，找到动态内存占用高的实例Select a.nodename,a.memorymbytes as dynamic_used_memory,b.memorymbytes as max_dynamic_memory, dynamic_used_memory/max_dynamic_memory*100 as used_rate from pgxc_total_memory_detail a join pgxc_total_memory_detail b on a.nodename=b.nodename where a.memorytype = 'dynamic_used_memory' and b.memorytype = 'max_dynamic_memory' order by a.memorymbytes desc;步骤二：连接内存占用高的实例，查看语句内存占用情况，并拼接查杀命令，可根据查询结果应急查杀内存高的语句：select 'select pg_terminate_backend(' || pid || ');' , state, query_id, pg_size_pretty(totalsize) total, pg_size_pretty(freesize) free, pg_size_pretty(usedsize) used, sqlstr FROM (SELECT state, query_id, pid, sum(totalsize) totalsize, sum(freesize) freesize, sum(usedsize) usedsize, substr(query,1,100) sqlstr FROM pv_session_memory_detail, pg_stat_activity WHERE pid=split_part(sessid,'.',2) GROUP BY 1,2,3,7 ORDER BY 4 DESC);步骤三：连接内存占用高的实例，查看各线程memory context情况，并拼接查杀命令：select 'select pg_terminate_backend(' || split_part(sessid,'.',2) || ');', split_part(sessid,'.',2) pid,pg_size_pretty(sum(totalsize)) total_size,count(*) context_count from pv_session_memory_detail group by pid order by sum(totalsize) desc limit 100;步骤四：连接CN，清理空闲连接（不影响业务）select * from pgxc_clean_free_conn;若问题发生后当前不再出现，可以通过如下方法确认原因：步骤一： 登录报错节点，cd $GAUSSLOG/pg_log，找到报错实例，在日志中查看报错内容，出现memory temporarily unavailable的报错时，实例日志中会打印相关信息。根据报错的实例日志，在日志中搜索“abnormal”关键字找到当时内存使用最高的语句，找到对应的thread id，再根据thread id找到对应的query id（注意，非日志中的debug_query_id）。示例如下：示例中，实际占用内存高的语句为explain performance对应的语句，对应的queryid为76279718688746485，而非 76279718689098154----debug_query_id=76279718689098154, The abnormal query thread id 140664667547392.It current used memory is 13618 MB and estimated memory is 1102 MB.It also is the query which costs the maximum memory.----debug_query_id=76279718689098154, It is not the current session and beentry info : datid<16389>, app_name, query_id<76279718688746485>, tid<140664667547392>, lwtid<173496>, parent_tid<0>, thread_level<0>, query_string<explainperformance with ws as (select d_year AS ....>.步骤二：还可以根据历史topsql中max_peak_memory字段找到问题时间点内存占用高的语句：select * from pgxc_wlm_session_info where start_time > 'xxxx-xx-xx xx:xx:xx' and start_time < 'xxxx-xx-xx xx:xx:xx' order by max_peak_memory desc limit 100;【恢复确认】业务不再继续报错【参考信息】cid:link_0

开发者们集合啦！期待与资深大佬深入探讨数仓技术？跃跃欲试与更多伙伴切磋代码，交流心得？求召唤行业前辈传授经验，助力职场打怪升级？天津HCDG开发者社区为您通通安排上！