如题，在今天在查看数据库schema大小的时候，两套集群一个可以正常查询出结果，另一个报错如下图：这个问题该怎么排查呢？以下是查询sql：SELECT schema_name,      pg_size_pretty(sum(table_size)::bigint) as "disk space",     round((sum(table_size) / pg_database_size(current_database())) * 100,2)         as "percent(%)" FROM (      SELECT pg_catalog.pg_namespace.nspname as schema_name,          pg_total_relation_size(pg_catalog.pg_class.oid) as table_size      FROM   pg_catalog.pg_class          JOIN pg_catalog.pg_namespace               ON relnamespace = pg_catalog.pg_namespace.oid ) t GROUP BY schema_name ORDER BY "percent(%)" desc;

根据DWS产品文档中描述，涉及autovacuum 功能的参数有以下这些，请问autovacuum 触发条件是怎么计算的，如果要调整，降低触发阈值，怎么调整autovacuum                      ; autovacuum_mode                 ; autovacuum_max_workers          ; autovacuum_naptime              ; autovacuum_vacuum_threshold     ; autovacuum_vacuum_scale_factor  ; 

GaussDB(dws)数据库中有多个用户，现在需要使用A用户来调用B用户的存储过程任务。其中B用户的存储过程中涉及对B用户下某张表分区的增删操作，请问A用户能够调用B用户这个存储过程所需要的最小权限是什么？谢谢！！！

【问题现象】dws管控面升级到820后，性能监控不显示【问题版本】dws820【排查步骤】1.登录dms数据库；查看指标上报最新时间发现部分指标上报时间不对select to_char(to_timestamp(max_ctime / 1000), 'YYYY-MM-DD HH24:MI:SS'), *from dms_mtc_max_ctimewhere cluster_id = 'c47a0fa2-96ca-4f0b-b479-5801a145698b' order by max_ctime asc;数据每天都会采集的如果时间不是最新的时间；那就有问题2.登录dms-collection查看dms-collection.log日志搜索报错发现插入数据的sql执行失败3.登录dms数据库执行报错的sql；报错：inserted partition key does not map to any partition此版本dms应用了分区表提高sql执行效率，由于dms依赖的数据库版本不支持自动分区函数；只能调用定时任务来创建分区;报错显示：插入的分区键没有映射到任何分区【恢复方法】：检查表的分区；\d+ 表名发现表分区没有继续创建；导致数据插入失败修复表分区：Select * from QRTZ_TRIGGERS WHERE JOB_GROUP = 'increasePartJob' ;UPDATE QRTZ_TRIGGERS SET TRIGGER_STATE = 'WAITING'WHERE TRIGGER_NAME = 'increasePartJob';完成重启dms-collection容器【根因】DMS 使用的存储数据库存在内核缺陷 930版本的分区表特性创建分区会触发内核事务ID上涨无法回收的问题 后续需要执行规避指南 将分区表回退为普通版【规避方法】1.登录dms数据库主节点判断方法：ip a 有浮动ip就是主节点2.将 的sql文件上传到opsadmin账户的tmp目录下chmod 777 文件名切换到dbadmin的目录下gsql -p 8635 -U dbadmin -WManager@123 -d dms -f 路径文件名获取回退sql文件请联系华为工程师

GaussDB(DWS)用户密码如何设置永久有效，需要执行的具体代码是什么？谢谢！！！

GaussDB(dws)数据库中有多个用户，现在需要使用A用户来调用B用户的存储过程任务。B用户的存储过程创建时会默认赋EXECUTE权限给A用户。但A用户执行B用户下的存储过程时，其中分区处理的部分会报错：删除分区会报错：must be owner of relation B用户。truncate分区数据时会报错：permission denied for relation B用户。请问：1、使用A用户来调用B用户的存储过程时，存储过程中的代码执行用户不应该是B用户么？2、通过A用户来调用B用户的存储过程来对表分区进行操作时，都需要满足哪些权限？谢谢！！！B用户的存储过程中有分区处理的逻辑如下：

问题背景1.业务咨询数据库如何进行中文字符匹配 2.正则匹配中文字符不正确问题原因业务数据库字符集编码使用的是sql_ascii导致排查过程postgres=# SELECT regexp_substr('冀A12345','(^[冀]{1}[A-Z]{1}[0-9]{5}$)'); regexp_substr --------------- (1 row) postgres=# show server_encoding; server_encoding ----------------- SQL_ASCII (1 row) postgres=# \c utf8_db utf8_db=# SELECT regexp_substr('冀A12345','(^[冀]{1}[A-Z]{1}[0-9]{5}$)'); regexp_substr --------------- 冀A12345 (1 row) utf8_db=# show server_encoding; server_encoding ----------------- UTF8 (1 row) 可以看到数据库字符集编码为 SQL_ASCII会导致中文匹配不到解决方案目前只支持创建数据库的时候指定字符集，如果数据库已经指定了字符集需要重新创建数据库 【数据库创建时字符集选择需慎重】

DWS版本： 8.1.1问题现状：客户环境重度使用存储过程，且存储过程逻辑复杂，动辄上千行代码，部分存储过程甚至需要跑10+小时。因为存储过程没法像单条语句那样可以通过explain查看执行计划进行分析调优；当集群卡顿出现卡顿时，无法明显判断是否由于存储过程内部刚好执行到了某条烂SQL导致，问题定位困难。请问下DWS是否有方法可定位当前存储过程执行到哪条语句，比如系统表、系统视图、后台日志等途径？或者针对以上痛点，是否有更好的解决方案(例如开发人员在存储过程编码时在每个关键业务处理环节加一句写日志表的操作，用于记录每个步骤的完成时间)？

基本信息 DWS版本： 8.1.1；静态负载管理请问下资源池的并发控制参数active_statements是针对单CN还是全局的？

【问题描述】：执行sql语句经常报报：terminating connection due to administrator command【排查过程】：通过查看报错的cn日志，日志显示报错时间点，pg_terminate_backend查杀的线程是一个启动包，此线程第一次执行的时候，出现了断连的情况Connection reset by peer，无法接收到远端的请求包，同时日志中显示session unused timeout，超时中断了这个线程，这个请求包没有接收完，就调用了pg_terminate_backend函数来kill掉这个线程，一直执行这个操作，日志里面也报了很多这个错，通过执行以下两个方法观察1. 网络流量的通信参数comm_usable_memory设置不合理（根据产品文档计算应是3.5G，目前设置值为2000M），需调整2. 调整session_timeout参数通过查看线程号，调整观察后，问题再次出现。再次查看查杀线程源头，发现是DRS服务查杀了DWS的线程拉drs的人确认，是他们一个已知问题，查杀错误导致的【问题根因】：DRS服务已知问题，DRS服务会回收链接，回收链接同时会调用pg_terminate_backend(pid)查杀函数，查杀函数线程是DWS服务这边的【解决办法】：已联系DWS服务的人，drs的修改相关参数规避

【问题描述】：业务连续几天报错（只读、DN内存不足），请帮忙看下日志，找到引起故障的SQL第一张截图 报只读错误，第二章截图 DN内存不足，请查看对应时间点日志，能否找出引发问题的SQL【排查过程】：1.排查20号和23号各触发一次只读，每次都是一个节点的同一个磁盘；2.该磁盘CN目录占用较大，GS_WLM_SESSION_INFO表和该表的附属toast表占用1.1T，导致比正常节点磁盘使用率高33%左右；3.分析当时触发只读的日志，当时下盘的语句有怀疑点，对比两次的语句不太一致，正在和业务进一步确认；【解决办法】：1.计划清理GS_WLM_SESSION_INFO表数据，关闭topsql；2.已truncate GS_WLM_SESSION_INFO表，关闭topsql，磁盘，空间已下降3.和业务沟通，后续推动收编至813；

GaussDB 8009集群如果各个节点NTP都配置为第三方服务器ntp会有什么影响？（正常是OMS配置第三方NTP,节点向OMS同步时钟）

问题现象1.业务执行语句报错ERROR:dn_6001_6002:Failed to connect dn_6003_6004,detail:1047 control channel disconnect 2.报错涉及的DN未重启，且执行带stream算子语句必现问题原因集群参数comm_max_stream不一致导致（CN之间参数要保持一致，DN之间参数要保持一致DN包括主备从）CN和DN之间可以不一致，建议参数请查看产品文档comm_max_stream参数设置。排查过程1.业务语句报错,后台查看DN未发生重启 2.业务创建表正常，业务执行语句带stream算子时就会出现报错。简单的select * from limit 1;也正常执行。 3.使用命令批量检查gs_guc check -Z coordinator -Z datanode -N all -I all -c "comm_max_stream" 4.如果第三步检查DN或CN参数完全一样则需后台进一步确认，查看正常DN和报错DN的comm_max_stream参数不一致。解决方法以下命令按实际进行修改参数设置 设置CN参数的命令 gs_guc set -Z coordinator -N all -I all -c "comm_max_stream=指定值" 设置DN参数的命令 gs_guc set -Z datanode -N all -I all -c "comm_max_stream=指定值" 参数comm_max_stream修改后需要重启集群

报错见上图。还有一种反向单引号，也不能识别，见下图：

参数校验失败，数据库节点无法登录问题现象：dws数据库ip无法登录问题版本：All排查方法：1.确认ip是什么ip：登录serviceOM-虚拟机-通过ip搜索查看此ip是什么ip;如果ip再此搜索不到；检查此ip是否是数据库vip；如果不是则检查是否ip获取错误2.dws和ecf的数据库ip主机名是DWS-DB01/02,DWS-Gauss-DB01/02,ECF-COMMON-DB01/02,ECF-CM-DB01/02；数据库vip一般和数据库ip是连着的：例如：数据库DWS-DB01/02ip分别是0.0.0.1；0.0.0.2则vip应该是0.0.0.33.确定ip后；手动登录如果是vip无法登录；则登录数据库节点；opsadmin用户登录 切root 切mysql用户执行 Get_db_status.py 根据执行结果判断vip是否还在；数据库状态是否正常解决方法：情况一vip不存在了1、以opsadmin登录到需要数据库主节点IP，并切换到root用户，再执行su - mysql切到mysql用户执行。2、使用查看数据库主备状态： Get_db_status.py，命令执行结果显示:Can not find VIP 10.170.181.70/23 both on the 10.170.181.68,10.170.181.69, 说明浮动IP丢失，继续按照下面方法修复。3、在数据库 主节点上执行命令查看当前数据库浮动IP信息：cat /usr/local/bin/ha_config4、挂载浮动IP并刷新arp缓存vip: 带掩码的浮动IP地址，对应上图vip_ip,gate_ip：网关地址 ，对应上图gateway_ip# root用户执行sudo ifconfig eth0:1 {vip} #挂载浮动ipsudo /usr/sbin/arping -I eth0 -c 5 -U -s {vip} -b {gate_ip} # 刷新arp缓存案例：# root用户执行sudo ifconfig eth0:1 10.170.181.70/23sudo /usr/sbin/arping -I eth0 -c 5 -U -s 10.170.181.70 -b 10.170.180.1再次切换到mysql用户下，查看数据库状态： Get_db_status.py。情况二备库挂了1、以opsadmin登录到需要重建备库的slave节点，并切换到root用户，再执行su - mysql切到mysql用户执行。2、关闭备库python /usr/local/bin/Stop_mysql_force.py关闭前，使用Get_db_status.py命令检查下数据库状态，如果数据库存在主，且主节点状态是只读状态。需要登录主数据库执行sql将状态改为读写状态：mysql -u ecf -pXj97cjOaQ2sv#@hIn7 -h db_vip -P 7306 -N -e "set global read_only=0;"3、重建备库python /usr/local/bin/MHA_RebuildSlave.py master_ipmaster_ip：MySQL主库的IP。4、重建完成后查看数据库进行是否启动。ps -ux查看数据库状态： Get_db_status.py数据库拉不起来，通过hcs同事找cloudb的同事处理