一. 互信异常排查方法判断omm用户目录文件权限是否正确，要求如下：/home 权限 755/home/omm 权限 750/home/omm/.ssh 权限 700/home/omm/.ssh/* 权限 600（所有文件）判断/home/omm/.profile文件内环境变量配置是否正确，正确配置如下：判断/home/omm/.bashrc文件内容中是否正确，正确配置如下​排查omm用户密码是否过期，参考产品文档‘ALM-12078 omm密码过期’章节异常节点使用root用户执行chage -l omm查找“Password expires”对应值，查看密码设置是否过期。检查/home/omm/.ssh/id_rsa文件是否包含加密字段，如下图，若不存在加密字段按照下面的修复方案进行修复二. 修复方案【​前提条件】目录权限及文件配置已修复，重启ssh-agent进程后互信仍未恢复【操作步骤】使用PuTTY，以omm用户登录到需要替换ssh密钥的节点。执行以下命令，防止超时退出。TMOUT=0说明：执行完本修复操作后，请及时恢复超时退出时间，执行命令TMOUT=超时退出时间。例如：TMOUT=600，表示用户无操作600秒后超时退出。执行以下命令，为节点生成新的密钥：如果当前节点是Manager管理节点，执行命令：sh ${CONTROLLER_HOME}/sbin/update-ssh-key.sh如果当前节点是非管理节点，执行命令：sh ${NODE_AGENT_HOME}/bin/update-ssh-key.sh执行上述命令时界面提示“Succeed to update ssh private key.”信息，表示ssh密钥生成成功。执行以下命令将该节点的公钥拷贝到主管理节点：scp ${HOME}/.ssh/id_rsa.pub oms_ip:${HOME}/.ssh/id_rsa.pub_bakoms_ip：表示主管理节点IP。根据提示输入omm用户密码完成文件拷贝。使用PuTTY，以omm用户登录到主管理节点。执行以下命令，防止超时退出：TMOUT=0执行以下命令，切换目录：cd ${HOME}/.ssh执行以下命令添加新的公钥信息：cat id_rsa.pub_bak >> authorized_keys执行以下命令移动临时公钥文件到其他目录，例如，移动到“/tmp”目录。mv -rf id_rsa.pub_bak /tmp拷贝主管理节点的authorized_keys文件到集群内其他节点：scp authorized_keys node_ip:/${HOME}/.ssh/authorized_keys​​​​​​​node_ip：集群内其他节点IP，不支持多个IP。​​​​​​​ps -ef|grep ssh-agent| grep -v grep | awk '{print $2}'| xargs kill -9在所有节点(包括管理节点)执行以下命令重启ssh-agent进程​​​​​​​​​​​​​​ps -ef|grep ssh-agent| grep -v grep | awk '{print $2}'| xargs kill -9执行以下命令无需输入密码确认私钥替换完成：ssh node_ipnode_ip：集群内其他节点IP，不支持多个IP。​​​​​​​【关键步骤】在异常节点生成新密钥（若有多个节点，可以同时多个节点执行）将异常节点生成的公钥/home/omm/.ssh/id_rsa.pub写入所有节点的/home/omm/.ssh/authorized_keys重启ssh-agent进程

【问题现象】     安装Console失败 下载日志报错Execute task by executor failed, error_msg: Execute task by executor failed: HCCI14001, 执行脚本异常，请联系技术支持工程师解决。 【常见版本】8.2.0以上版本    【定位思路】    1、登录HCC后台重试工步 bash /opt/rootscript/debug-/retry.sh run -i 工步ID 2、可见日志报错 'DMKClient start login' error %s Incorrect username or password. 3、检查DMK的sysadmin用户和密码 如果未部署完就修改过DMK密码可能要恢复成默认密码，注意恢复默认密码要修改5次以上。 

select c.relnamefrom pg_class cleft join pg_namespace n on n.oid=c.relnamespacewhere n.nspname in ('pg_catalog')and relkind in ('r','v')and c.oid<16385and concat(',',pg_catalog.array_to_string(c.relacl,E',')) like '%,=r/omm%';云上环境最后一行的omm要换成Ruby管理员

【版本信息】不涉及【问题现象】数据库端CN有频繁报warning，不能够从客户端收到数据，不完整的数据包。can not receive data from client, incomplete package【问题根因】ELB配置健康检查，要连接数据库IP和端口，监测端口服务在线，就马上断开连接，不发送后续的认证请求。【问题影响】ELB健康检查导致的数据库后端每10s一次的warning，属于正常现场，不会造成可感知的压力。

版本信息：不涉及问题描述：执行正则表达式报错：invalid regular expression: invalid repetition count(s)，示例：postgres=# select regexp_like('123','^(?=.*[0-9])(?=.*[a-zA-Z])([a-zA-Z0-9]{255})$'); regexp_like ------------- f(1 row)postgres=# postgres=# select regexp_like('123','^(?=.*[0-9])(?=.*[a-zA-Z])([a-zA-Z0-9]{256})$');ERROR: invalid regular expression: invalid repetition count(s)CONTEXT: SQL function "regexp_like" statement 1referenced column: regexp_like问题原因：因为在DWS中，正则表达式a{n}中，n的范围不能超过255，超过255后会报上述错误解决方法：该报错是由于产品规格导致，需要改写正则匹配逻辑解决，保证n的范围在255以内。

【问题版本】 管控面升级811->821 【问题描述】 DWS秘钥挂载至CDK失败/ECF秘钥挂载至CDK失败 【问题影响】 无 【问题根因】 cdk接口问题，查询分页，代码limit=10，修改为100 【定位过程】 问题根因：     国网region多，有30个iam账号，一般别的局点没有这么多region，iam账号不超10个，也就不会出现； 规避措施： 1、登到HCC Turkey工具后台节点； 2、vi /opt/cloud/hcci/src/HCCI/solution_driver/hcs/v8_2_0/utils/business/CDK/cdk_api_common.py 3、在cdk_api_common.py里搜索get_iam_config方法； 4、在url里把limit=10修改为limit=100，然后保存；如下：     url = '/api/v2/cdk/user-center/iam-aggregation?limit=10&offset=0&sortBy=CREATED_TIME&order=desc'     改成：url = '/api/v2/cdk/user-center/iam-aggregation?limit=100&offset=0&sortBy=CREATED_TIME&order=desc' 5、最后执行sh /opt/rootscripts/restart.sh命令重启框架后，界面重试工步通过；

【问题版本】 811升级820 【问题描述】 管控面升级ECF组件服务工步跑失败 【定位过程】 问题的每个排查方向的排查结果 1、DWS db升级工步失败，查看是超时900秒，重试工步后成功； 工步详情：     "1859350,升级DWS Controller MySQL失败，错误信息：HCCI125003，执行sshcmd失败；     IP：XX.XX.XX.XX，在设定超时时间900秒内未获取到期待的返回值；实际返回值为：" 2、ECF组件服务升级工步失败，登EICommon-Region-Master节点发现ECF组件服务容器状态异常；     登录ECF-Region-Node节点查看haveged服务没有起来，手动restart失败，熵值太低；     cat /proc/sys/kernel/random/entropy_avail 查看熵值太低，     systemctl status haveged.service 查看haveged     systemctl restart haveged.service 重启haveged     解决方案(1、2任选其一即可)：         1）删除/usr/local/lib/libhavege.so.1         2）删除/etc/ld.so.conf中的/usr/local/lib，然后执行ldconfig         3）重启haveged 3、登EICommon-Region-Master，ECF组件服务容器状态异常，还是拉不起来；     去CDK界面查看Region-Node有一个节点的标签被改了，改回ecf后去重启容器，容器重启成功，应该是资源抢占不到导致；     最后重试工步成功，升级成功；

1.逻辑备份失败，master节点agent日志显示No matching tables were found. Failed to dump ddl table info to master.2.找到对应的表为scheduler.pg_task, 手动执行gs_dump也报同样的错误3.确认为系统表，备份以及gs_dump命令不支持系统表

注：此方法仅适用于813及以上版本，以下版本需手动清理 步骤一：将集群内白名单改为trust gs_guc set -Z coordinator -Z datanode -N all -I all -h "local all all trust"步骤二：任意集群内节点，沙箱内执行 gs_ssh -c "python3 $GPHOME/script/local/LocalRoach.py -t cbm_recycle --backup-key 20230421_162811 --cbm-recycle-level 1 --metaPath /DWS/backup/metadata --env '/home/Ruby/.bashrc' -U Ruby -l /home/Ruby/recycle_backup01.log --task-type 0" >> /home/Ruby/recycle.log 2>&11、参数说明： --backup-key 备份集 --metaPath 备份的metadata --env 云上环境变量默认值：/home/Ruby/.bashrc 2、执行结果查看，执行节点查看以下日志 /home/Ruby/recycle.log统计执行正确节点：cat /home/Ruby/recycle.log |grep 'SUCCESS' |wc -l 统计执行异常节点：cat /home/Ruby/recycle.log |grep 'FAILURE' |wc -l 查看异常节点信息：cat /home/Ruby/recycle.log |grep -A 15 'FAILURE'步骤三：恢复集群内白名单为sha256 gs_guc set -Z coordinator -Z datanode -N all -I all -h "local all all sha256"

【问题版本】 dws8113 【问题描述】 告警语句堆积数量超阈值 【问题影响】 无 【问题根因】 阈值设置低 【规避措施】 阈值调高 【定位过程】     OC告警语句堆积数量实际超过默认阈值10，需要调大阈值，防止上报告警； 告警详情信息：     告警ID：DWS_2000000017_1_OM；     告警源：DWS_cn_xxx_1；     定位信息：cluster_id:xx-xx-xx-xx,cluster_name:XXXXX；     附加信息：CloudSerice=DWS,resourceId:xx-xx-xx-xxresourceIdName:XXXXX;         first_alarm_time:2023-09-13 16:14:22;10分钟内，堆积的查询语句数量平平均值为12.00，超过阈值10； 1、运维侧的告警语句堆积数量超阈值需要到serviceCM上改;     ServiceOM界面：服务列表-->数据仓库服务-->监控告警-->告警管理-->告警规则配置-->选 查询语句堆积数量超阈值-->修改；     console界面：数据仓库服务-->告警管理-->告警规则管理-->选 DWS_2000000017（查询语句堆积数量超阈值）规则-->修改； 2、后台规避措施：登后台DMS数据库改成50，观察一天看是否上报告警；     gsql -p 8635 -W XXXXXXXX -U dbadmin -d dms     select * from dms_meta_cluster_alarm_config_map where rule_id like 'DWS_2000000017%';     update dms_meta_cluster_alarm_config_map set threshold_value = 50 where rule_id like 'DWS_2000000017%';

【问题版本】 812->813.110 【问题描述】 集群升级失败报memory is temporarily unavailable 【问题影响】 影响升级 【问题根因】 数据库删除有残留，未删干净，元数据不一致 【定位过程】  1、nedw-test集群升级失败serviceOM数仓服务升级管理任务报EU030；     Error:{'errorCode':'EU030','errorWsg':Failed to doOnline upgrade and failed to do rollback of Online upgrade.'} 登CN节点查看gs_local日志报内存不足memory is temporarily unavailable、死锁问题；     ERROR: cn_5004:deadlock detected     ERROR: dn_6083_6084:memory is temporarily unavailable 2、登postgres库查询work_mem参数为2GB；show work_mem; gsql命令调整为4GB后重试升级；    gs_guc reload -Z coordinator -Z datanode -N all -I all -c "work_mem=4GB" 3、重试升级级失败，还是报的内存不足； 查询shared_buffers参数为2GB：show shared_buffers 查询CN_5001和报错日志的dn_6083_6084节点的内存pv_total_memory_detail值；     select * from pv_total_memory_detail; 4、重试失败，查gs_upgradectl和gs_local日志，发现有一个citic_nedw_lcyw数据库升级失败；     [FAILURE]host-11-0-0-XX     Rolling back catalog.     Failed to upgrade citic_nedw_lcyw catalog,ret_queue is -1. 5、一线说之前可能删过，找业务确认该数据库是否可以删除，确认是之前删除没有删干净；需删除后重试； 6、删不掉，调整upgrade_mode=0，后删除drop citic_nedw_lcyw ，一个小时后删除成功；     drop citic_nedw_lcyw;     ERROR:The database cannot be dropped during the database upgrade     gs_guc reload -Z coordinator -Z datanode -N all -I all -c "upgrade_mode=0";     drop citic_nedw_lcyw; 7、删除后把upgrade_mode改回原来的2，重试升级；     gs_guc reload -Z coordinator -Z datanode -N all -I all -c "upgrade_mode=2" 8、升级时间过长，判断是tmp文件下gauss开头的文件太多导致（排查每个CN节点），删除8月份前的文件后升级变快，最后升级成功； 统计命令：(/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-01-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-02-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-03-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-04-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-05-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-06-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-07-*" xargs -n 1000 rm -rf     find /tmp/ -name "gauss_*_2023-08-*" xargs -n 1000 rm -rf

1.排查cpu低，io低，topsql语句报错An I/O error occured while sending to the backend2.排查脏页率，发现部分系统表和业务表脏页率到99％，建议清理3.连接到客户端，数据堆积过多；排查CN日志，有大量的主键冲突；提醒客户端解决主键冲突后，问题解决

【规避方法】in 后面的条件默认就只能是5个,超过6个就过滤不下推在820版本之前,默认为5个,且不可修改.820版本之后,可以修改最大个数-- 谓词不下推的算子 3-4s6 --Partitioned CStore Scan on dmmds_mdr_dta.rit_cr030607_a001 aFilter: ((a.tim_cod = ANY ('{M,Y}'::bpchar[])) AND ((a.spp_cod)::text = 'BOD'::text) AND ((a.spp_val)::text = 'BOD'::text) AND (a.are_cod = 'A'::bpchar) AND ((a.drv_src)::text = 'SET:02'::text) AND ((a.chl_cod)::text = 'A'::text) AND (a.row_seq = ANY ('{1,10,19,28}'::integer[])) AND (a.tpp_val = ANY ('{2023-09-19,2023-08-19,2022-09-19,2022-08-31,2022-09-30,2022-03-19}'::date[])))Rows Removed by Filter: 484387263Pushdown Predicate Filter: (((a.tim_cod = 'M'::bpchar) OR (a.tim_cod = 'Y'::bpchar)) AND ((a.spp_cod)::text = 'BOD'::text) AND ((a.spp_val)::text = 'BOD'::text) AND (a.are_cod = 'A'::bpchar) AND ((a.drv_src)::text = 'SET:02'::text) AND ((a.chl_cod)::text = 'A'::text) AND ((a.row_seq = 1) OR (a.row_seq = 10) OR (a.row_seq = 19) OR (a.row_seq = 28)))- 谓词下推的算子 0.4s6 --Partitioned CStore Scan on dmmds_mdr_dta.rit_cr030607_a001 aFilter: ((a.tim_cod = ANY ('{M,Y}'::bpchar[])) AND ((a.spp_cod)::text = 'BOD'::text) AND ((a.spp_val)::text = 'BOD'::text) AND (a.are_cod = 'A'::bpchar) AND ((a.drv_src)::text = 'SET:02'::text) AND ((a.chl_cod)::text = 'A'::text) AND (a.row_seq = ANY ('{1,10,19,28}'::integer[])) AND (a.tpp_val = ANY ('{2023-09-19,2023-08-19,2022-09-19,2022-08-31,2022-09-30}'::date[])))Rows Removed by Filter: 479328840Pushdown Predicate Filter: (((a.tim_cod = 'M'::bpchar) OR (a.tim_cod = 'Y'::bpchar)) AND ((a.spp_cod)::text = 'BOD'::text) AND ((a.spp_val)::text = 'BOD'::text) AND (a.are_cod = 'A'::bpchar) AND ((a.drv_src)::text = 'SET:02'::text) AND ((a.chl_cod)::text = 'A'::text) AND ((a.row_seq = 1) OR (a.row_seq = 10) OR (a.row_seq = 19) OR (a.row_seq = 28)) AND ((a.tpp_val = '2023-09-19'::date) OR (a.tpp_val = '2023-08-19'::date) OR (a.tpp_val = '2022-09-19'::date) OR (a.tpp_val = '2022-08-31'::date) OR (a.tpp_val = '2022-09-30'::date)))

一、问题现象DWS访问集群内的普通表速率正常，访问hdfs集群的外表速率慢，慢的程度limit 1时间min起步，最后也能出结果，就是慢，无报错；二、问题排查1、检查hdfs集群访问；这里主要检查DWS集群节点访问HDFS集群是否互通；2、外部server配置正常；不光检查DWS集群，实际也要看HDFS文件等；3、外表创建正常；外表是否指定正确的server;4、以上检查都正常，检查配置正确的“错误域名”，1.1.1.1实际这个地址不通的，将域名和错误地址配置，意思让跳过域名访问，默认DWS访问HDFS使用IP连接，而不是域名，发现已配置：cat /etc/hosts1.1.1.1 hadoop.hadoop.com这里1.1.1.1固定，hadoop.hadoop.com把hadoop集群的域名都添加到这，按实际情况来；5、检查server缓存；每个DN路径下，如下文件，就是DN和hdfs的datanode交互时的缓存文件；md508a869c15082653caa1db1da2877dcc改文件属于二进制文件，可使用strings命令查看三、问题原因缓存未刷新。当遇到配置发生变化时，需要重新集群或者刷新配置，如果没有做，就会遇到访问慢的问题，而且这里慢，是部分外表访问慢。ALTER SERVER server_name REFRESH OPTIONS;四、解决方案ALTER SERVER server_name REFRESH OPTIONS;刷新HDFS配置文件。仅8.0.0.10及以上版本支持(8.1.0除外)。五、其他如果遇到刷新配置解决不了的慢，而且无报错，可以打印访问外表的等待视图，看在那个DN上发起访问外表，去对应DN上打印堆栈，实例：gstack $lwtid可以进一步定位，已知的访问慢，有可能是域名问题；

1、背景某局点用户查询表某字段发现都是科学计数法的形式，并且此字段经round函数处理之后全是0，怀疑是显示问题2、分析经过（1）通过查询表结构是double precision双精度类型不是科学计数法类型（2）该字段可以通过科学计数法的方式赋值（3）也可以正常赋值（4）由上图可以发现当赋值一个0.00000000154的值显示依旧是科学计数法，即当我们赋值一个10的负数次方的值时显示的就是科学计数法，正常现象。round函数返回的时离输入参数最近的整数，结果正确没有问题3、double precision类型对10的负数次方的值是以科学计数法显示的不影响计算