华为云用户手册

处理方法 这两种行为由参数behavior_compat_options控制，当参数behavior_compat_options缺省的情况下，匹配到多行会报错，如果behavior_compat_options设置了merge_update_multi参数项，这种情况下不会报错，而是会随机匹配一行数据。 因此，当出现MERGE INTO的结果与预期不符时，需查看该参数是否被设置，同时排查是否匹配了多行数据，并修改业务逻辑。

原因分析 增加分区时需同时满足以下条件： 新增分区名不能与已有分区名相同。 新增分区的边界值必须大于最后一个分区的上边界。 新增分区的边界值要和分区表的分区键的类型一致。 已有分区p1的边界为(-∞，20221010)，而新增分区p0的上边界为20221009，落在分区p1内；已有分区p4的边界为[20221012,+∞)，而新增分区p5的上界为20221013，落在分区p4内。新增分区p0、p5不满足使用ADD PARTITION增加分区的条件，因此执行新增分区语句报错。

处理方法 使用ALTER TABLE SPLIT PARTITION分割已有分区，也能达到新增分区的目的。同样， SPLIT PARTITION的新分区名称也不能与已有分区相同。 使用split子句分割p4分区[20221012,+∞)为p4a分区范围为[20221012,20221013)和p4b分区范围为[20221013,+∞)。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 ——SPLIT PARTITION分割前的分区 SELECT relname, boundaries FROM pg_partition p where p.parentid='studentinfo'::regclass ORDER BY 1; relname | boundaries -------------+------------------------- p1 | {"2022-10-10 00:00:00"} p2 | {"2022-10-11 00:00:00"} p3 | {"2022-10-12 00:00:00"} p4 | {NULL} studentinfo | (5 rows) ALTER TABLE studentinfo SPLIT PARTITION p1 AT('2022-10-09 00:00:00+08') INTO (PARTITION P1a,PARTITION P1b); ALTER TABLE studentinfo SPLIT PARTITION p4 AT('2022-10-13 00:00:00+08') INTO (PARTITION P4a,PARTITION P4b); ——执行SPLIT PARTITION分割后的分区 SELECT relname, boundaries FROM pg_partition p where p.parentid='studentinfo'::regclass ORDER BY 1; relname | boundaries -------------+------------------------- p1a | {"2022-10-09 00:00:00"} p1b | {"2022-10-10 00:00:00"} p2 | {"2022-10-11 00:00:00"} p3 | {"2022-10-12 00:00:00"} p4a | {"2022-10-13 00:00:00"} p4b | {NULL} studentinfo | (7 rows) 如果对分区名称有要求，可以在分割后再使用rename partition统一分区名。 ALTER TABLE studentinfo RENAME PARTITION p1a to p0;

问题现象 创建范围分区表后增加新的分区，使用ALTER TABLE ADD PARTITION语句报错upper boundary of adding partition MUST overtop last existing partition。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 ——创建范围分区表studentinfo CREATE TABLE studentinfo (stuno smallint, sname varchar(20), score varchar(20), examate timestamp) PARTITION BY RANGE (examate) ( PARTITION p1 VALUES LESS THAN ('2022-10-10 00:00:00+08'), PARTITION p2 VALUES LESS THAN ('2022-10-11 00:00:00+08'), PARTITION p3 VALUES LESS THAN ('2022-10-12 00:00:00+08'), PARTITION p4 VALUES LESS THAN (maxvalue) ); ——添加边界值为2022-10-9 00:00:00+08的分区p0 ALTER TABLE studentinfo ADD PARTITION p0 values less than ('2022-10-9 00:00:00+08'); ERROR: the boundary of partition "p0" is less than previous partition's boundary ——添加边界值为2022-10-13 00:00:00+08的分区p5 ALTER TABLE studentinfo ADD PARTITION p5 values less than ('2022-10-13 00:00:00+08'); ERROR: the boundary of partition "p5" is equal to previous partition's boundary

问题现象 数据库中新建一张表，某个表字段使用character类型，在Java中读取character类型的字段时返回类型是byte。 例如，创建示例表table01： 1 2 3 4 CREATE TABLE IF NOT EXISTS table01( msg_id character(36), msg character varying(50) ); 在Java中，读取character类型的字段代码如下： 1 ColumnMetaInfo(msg_id,1,Byte,true,false,1,true);

问题现象 DWS中有两种情况需要关注表是否做过UPDATE及DELETE操作： 对表频繁执行UPDATE或者DELETE操作会产生大量的磁盘页面碎片，从而逐渐降低查询的效率，需要将磁盘页面碎片恢复并交还操作系统，即VACUUM FULL操作，这种场景下需要查找出哪些表执行过UPDATE； 判断一张表是否是维度表，是否可以从Hash表变更为复制表，可以查看这张表是否执行过UPDATE或DELETE，如果执行过UPDATE或DELETE操作，则不能修改为复制表。

处理方法 通过以下命令查找哪些表执行过UPDATE及DELETE操作： 1 2 3 4 5 6 7 8 9 ANALYZE tablename; SELECT n.nspname , c.relname, pg_stat_get_tuples_deleted(x.pcrelid) as deleted, pg_stat_get_tuples_updated(x.pcrelid) as updated FROM pg_class c INNER JOIN pg_namespace n ON n.oid = c.relnamespace INNER JOIN pgxc_class x ON x.pcrelid = c.oid WHERE c.relkind = 'r' and c.relname='tablename' ;

处理方法 删除该表索引信息。 1 DROP INDEX a_0317_index; 对该表索引进行重建。 1 CREATE INDEX a_0317_index on a_0317(a) local (partition p1_index, partition p2_inde); 查看表定义无报错。 1 2 3 4 5 6 7 8 9 10 11 12 13 \d+ a_0317 Table "public.a_0317" Column | Type | Modifiers | Storage | Stats target | Description --------+---------+-----------+---------+--------------+------------- a | integer | | plain | | Indexes: "a_0317_index" btree (a) LOCAL(PARTITION p1_index, PARTITION p2_inde) TABLESPACE pg_default Range partition by(a) Number of partition: 2 (View pg_partition to check each partition range.) Has OIDs: no Distribute By: HASH(a) Location Nodes: ALL DATANODES Options: orientation=row, compression=no

问题复现 创建分区表a_0317，含p1，p2两个分区。 1 CREATE TABLE a_0317(a int) partition by range(a) (partition p1 values less than (4), partition p2 values less than (8)); 创建主表与分区索引。 1 CREATE INDEX a_0317_index on a_0317(a) local (partition p1_index, partition p2_inde); 查看分区表分区索引信息如下： 查看主表索引信息。 1 2 3 4 5 6 7 8 9 10 11 SELECT oid,* FROM pg_class where relname ='a_0317_index'; oid | relname | relnamespace | reltype | reloftype | relowner | relam | relfilenode | reltablespace | relpages | reltuples | relallvisible | reltoastrelid | reltoastidxid | reldeltarelid | reld eltaidx | relcudescrelid | relcudescidx | relhasindex | relisshared | relpersistence | relkind | relnatts | relchecks | relhasoids | relhaspkey | relhasrules | relhastriggers | relhassubclass | relcmprs | relhasclusterkey | relrowmovement | parttype | relfrozenxid | relacl | reloptions | relreplident | relfrozenxid64 --------+--------------+--------------+---------+-----------+----------+-------+-------------+---------------+----------+-----------+---------------+---------------+---------------+---------------+----- --------+----------------+--------------+-------------+-------------+----------------+---------+----------+-----------+------------+------------+-------------+----------------+----------------+--------- -+------------------+----------------+----------+--------------+--------+------------+--------------+---------------- 241487 | a_0317_index | 2200 | 0 | 0 | 16393 | 403 | 241487 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | f | f | p | i | 1 | 0 | f | f | f | f | f | 0 | f | f | p | 0 | | | n | 0 (1 row) 根据主表索引信息查看分区索引信息。 1 2 3 4 5 6 7 8 9 10 SELECT * FROM pg_partition where parentid= 241487; relname | parttype | parentid | rangenum | intervalnum | partstrategy | relfilenode | reltablespace | relpages | reltuples | relallvisible | reltoastrelid | reltoastidxid | indextblid | indisusable | reldeltarelid | reldeltaidx | relcudescrelid | relcudescidx | relfrozenxid | intspnum | partkey | intervaltablespace | interval | boundaries | transit | reloptions | relfrozenxid64 ----------+----------+----------+----------+-------------+--------------+-------------+---------------+----------+-----------+---------------+---------------+---------------+------------+-------------+- --------------+-------------+----------------+--------------+--------------+----------+---------+--------------------+----------+------------+---------+------------+---------------- p1_index | x | 241487 | 0 | 0 | n | 241488 | 0 | 0 | 0 | 0 | 0 | 0 | 241485 | t | 0 | 0 | 0 | 0 | 0 | | | | | | | | 0 p2_inde | x | 241487 | 0 | 0 | n | 241489 | 0 | 0 | 0 | 0 | 0 | 0 | 241486 | t | 0 | 0 | 0 | 0 | 0 | | | | | | | | 0 (2 rows) 连接CN开启读写事务，从pg_partition系统表删除p1分区的索引信息。 1 2 START TRANSACTION read write; DELETE from pg_partition where relname = 'p1_index'; 查看表定义报错与现场报错相同，问题复现： 1 2 \d+ a_0317 ERROR: The local index 700633 on the partition 700647 not exist.CONTEXT: referenced column: pg_get_indexdef

解决办法 为防止出现分区间隙，需要将ADD PARTITION的START值前移。 以分区表partitiontest为例： 1 2 3 4 5 6 7 8 9 10 CREATE TABLE partitiontest ( c_int integer, c_time TIMESTAMP WITHOUT TIME ZONE ) PARTITION BY range (c_int) ( partition p1 start(100)end(108), partition p2 start(108)end(120) ); 执行如下两种语句会发生报错： 1 2 ALTER TABLE partitiontest ADD PARTITION p3 start(120)end(130), DROP PARTITION p2; ERROR: start value of partition "p3" NOT EQUAL up-boundary of last partition. 1 2 ALTER TABLE partitiontest DROP PARTITION p2,ADD PARTITION p3 start(120)end(130); ERROR: start value of partition "p3" NOT EQUAL up-boundary of last partition. 可以修改语句为： 1 ALTER TABLE partitiontest ADD PARTITION p3 start(108)end(130), DROP PARTITION p2; 1 ALTER TABLE partitiontest DROP PARTITION p2,ADD PARTITION p3 start(108)end(130);

处理方法 方法一 该处理方法仅8.1.3及以上集群版本支持。 登录 GaussDB (DWS) 管理控制台。 在集群列表中单击指定集群名称。 进入“集群详情”页面，切换至“智能运维”页签。 在运维详情部分切换至运维计划模块。单击“添加运维任务”按钮。 弹出添加运维任务边栏。 运维任务选择“Vacuum”。 调度模式选择“指定目标”，智能运维将在指定时间窗内，自动下发表级Vacuum任务。 用户可配置需要Vacuum的列存表，其中一行对应一张表，每张表以数据库名、模式名、表名表示，以空格进行分割。 单击“下一步：定时配置”，配置Vacuum类型，推荐选择“周期型任务”，GaussDB(DWS)将自动在自定义时间窗内执行Vacuum。 确认无误后，单击“下一步：配置确认”，完成配置。 方法二 对列存表更新操作后，需要进行VACUUM FULL清理，更多用法请参见VACUUM的“VACUUM”章节的“VACUUM”章节。 1 VACUUM FULL table_name;

解决办法 通过下列的操作步骤，可以分析出查询效率异常降低的原因。 使用ANALYZE命令分析数据库。 ANALYZE命令更新所有表中数据大小以及属性等相关统计信息，该命令较为轻量级，可以经常执行。如果此命令执行后性能恢复或者有所提升，则表明AUTOVACUUM未能很好的完成它的工作，有待进一步分析。 检查查询语句是否返回了多余的数据信息。 例如，如果查询语句先查询一个表中所有的记录，而只用到结果中的前10条记录。对于包含50条记录的表，查询起来是很快的；但是，当表中包含的记录达到50000，查询效率将会有所下降。 若业务应用中存在只需要部分数据信息，但是查询语句却是返回所有信息的情况，建议修改查询语句，增加LIMIT子句来限制返回的记录数。这样至少使数据库优化器有了一定的优化空间，一定程度上会提升查询效率。 检查查询语句单独运行时是否仍然较慢。 尝试在数据库没有其他查询或查询较少的时候运行查询语句，并观察运行效率。如果效率较高，则说明可能是由于之前运行数据库系统的主机负载过大导致查询低效。此外，还可能是由于执行计划比较低效，但是由于主机硬件较快使得查询效率较高。 检查重复相同查询语句的执行效率。 查询效率低的一个重要原因是查询所需信息没有缓存在内存中，这可能是由于内存资源紧张，缓存信息被其他查询处理覆盖。 重复执行相同的查询语句，如果后续执行的查询语句效率提升，则可能是由于上述原因导致。

原因分析 网络不通 如果客户端主机通过GaussDB(DWS)集群的内网地址进行连接，需要排查客户端主机跟GaussDB(DWS)集群是否在相同的VPC和子网内，如果不在相同的VPC和子网内，则网络不通。 安全组规则禁止ping GaussDB(DWS)集群所属的安全组入规则需要放开ICMP协议端口才能允许ping，如果未开放ICMP协议端口，就无法ping通。创建GaussDB(DWS)集群时自动创建的安全组默认只放开了TCP协议和8000端口。 如果安全组入规则已开放ICMP协议端口，需要检查相应入规则的源地址是否涵盖了客户端主机的IP地址，如果没有，也无法ping通。

处理方法 网络不通 如果客户端主机通过GaussDB(DWS)集群的内网地址进行连接，应重新申请一台弹性云服务器作为客户端主机，且该弹性云服务器必须和GaussDB(DWS)集群处于相同的VPC和子网内。 安全组规则禁止ping 检查GaussDB(DWS)集群所属的安全组规则，查看是否对客户端主机的IP地址开放了ICMP协议端口。具体操作如下： 登录GaussDB(DWS)管理控制台。 在“集群管理”页面，找到所需要的集群，单击集群名称进入“基本信息”页面。 在“基本信息”页面，找到“安全组”参数，单击安全组名称，进入相应的安全组详情页面。 进入“入方向规则”页签，检查是否存在开放ICMP协议端口的入规则，如果不存在，请单击“添加规则”按钮，添加入方向规则开放ICMP协议端口。 协议端口：选择“ICMP”和“全部”。 源地址：选择“IP地址”，然后根据客户端主机的IP地址输入相应的IP地址与掩码。0.0.0.0/0表示任意地址。 图1 入方向规则 单击“确定”，完成入规则的添加。

原因分析 GDS进程崩溃。执行命令检查GDS进程是否崩溃： ps ux|grep gds 如果返回结果如下，则说明GDS进程启动成功： GDS启动参数-H配置不正确。 -H address_string：允许哪些主机连接和使用GDS服务。参数需为CIDR格式。此参数配置的目的是允许GaussDB(DWS)集群可以访问GDS服务进行数据导入，请保证所配置的网段包含GaussDB(DWS)集群各主机。

分析过程 和用户确认部分业务慢，执行慢的业务中都涉及到了同一张表tb_motor_vehicle。 收集几个典型的慢SQL语句，分别打印执行计划。从执行计划中可以看出来，两条SQL的耗时都集中在Partitioned CS tore Scan on public.tb_motor_vehicle列存表的分区扫描上。 已确认该表的分区键为createtime，而涉及的SQL中无任何createtime的筛选和过滤条件，基本可以确认是由于慢SQL的计划没有走分区剪枝，导致了全表扫描，对于185亿条数据量的表，全表扫描性能会很差。

原因分析 上述问题中撤销user3对表t1的访问权限未生效是因为：之前执行过GRANT SELECT ON table t1 TO public;这条SQL语句，该语句中关键字public表示该权限要赋予给所有角色，包括之后新创建的角色，所以新用户user3对该表也有访问权限。public可以看做是一个隐含定义好的组，它包含所有角色。 因此，执行完REVOKE SELECT ON table t1 FROM user3;之后，虽然user3用户没有了表t1的访问权限（通过系统表pg_class的relacl字段可查看t1表的权限），但是他仍然有public的权限，所以仍能访问该表。

调用存储过程报错 ERROR: cached plan must not change result type 问题分析：由于JDBC中使用了PreparedStatement，默认重复执行5次就会缓存plan，在此之后有如果重建表操作（例如修改表定义），再次执行就会报错ERROR: cached plan must not change result type. 处理方法：在JDBC连接字串中指定prepareThreshold=0，不再cache plan。例如： 1 String url = "jdbc:postgresql:// 192.168.0.10:2000/postgres?prepareThreshold=0";

使用JDBC执行create table as 语句报错 ERROR: relation "xx" already exists 问题分析：JDBC调用preparedStatement.getParameterMetaData()时会发送P报文，该报文会在数据库中创建表，导致execute执行时报表已存在。 处理方法：使用preparedStatement时，建议将CREATE TABLE AS拆开执行或者使用resultSet.getMetaData()。

Broken pipe, connection reset by peer 问题分析：网络故障，数据库连接超时。 处理方法：检查网络状态，修复网络故障，影响数据库连接超时的因素。例如，数据库参数session_timeout。 登录控制台单击指定集群名称。 在左侧导航栏选择“参数修改”，搜索参数“session_timeout”查看超时时间参数。 将session_timeout的CN、DN参数值设置为0，详情可参见修改数据库参数。

处理方法 8.0以下版本集群清理系统表需要先执行DELETE FROM，再执行VACUUM FULL。 此处仅以gs_wlm_session_info系统表为例： 1 2 DELETE FROM pg_catalog.gs_wlm_session_info; VACUUM FULL pg_catalog.gs_wlm_session_info; 8.0及以上版本集群可执行以下命令清理系统表： 1 TRUNCATE TABLE dbms_om.gs_wlm_session_info; 此系统表的schema是dbms_om。

解决方案 建议根据业务实际情况调整update语句。比如分析public.t2的字段含义，确定更新的目标字段。针对上述案例，如果期望在a值相等的情况下，把public.t1中字段b更新为public.t2中的最大值，那么可以修改为如下逻辑： 1 2 3 4 5 6 7 UPDATE t1 SET t1.b = t2.b_max FROM (SELECT a, max(b) AS b_max FROM t2 GROUP BY a) t2 WHERE t1.a = t2.a; UPDATE 1 SELECT * FROM public.t1; a | b ---+--- 1 | 2 (1 row)

原因分析 当一条SQL语句中同一个元组被多次更新，执行便会报错ERROR：Non-deterministic UPDATE。 可以看到更新操作分成两步执行： 通过关联操作查找满足更新条件的元组。 执行更新操作。 针对上述案例，对于表public.t1中元组 (1, 1)来说，表public.t2中满足更新条件t1.a = t2.a的记录有两条，分别为(1, 1)， (1, 2)；按照执行器逻辑表t2的元组 (1, 1)需要被更新两次，那么就可能出现两种情况： 表public.t1和表public.t2关联时先命中(1, 1)，再命中(1, 2)，这时public.t1的元组(1, 1)，先被更新为(1,1)，再被更新为(1,2)，最终结果为(1, 2)。 表public.t1和表public.t2关联时先命中(1, 2)，再命中(1, 1)，这时public.t1的元组(1, 1)，先被更新为(1,2)，再被更新为(1,1)，最终结果为(1, 1)。 实际执行过程中public.t2表输出结果集的顺序会影响update语句的最终输出结果（实际业务中表public.t2的位置可能是一个非常复杂的子查询），导致了update语句执行结果的随机性，而这个实际业务中是无法接受的。

问题现象 执行update语句报错ERROR：Non-deterministic UPDATE。 1 2 3 4 5 6 7 8 9 10 11 12 CREATE TABLE public.t1(a int, b int) WITH(orientation = column); CREATE TABLE CREATE TABLE public.t2(a int, b int) WITH(orientation = column); CREATE TABLE INSERT INTO public.t1 VALUES (1, 1); INSERT INTO public.t2 VALUES (1, 1),(1, 2); UPDATE t1 SET t1.b = t2.b FROM t2 WHERE t1.a = t2.a; ERROR: Non-deterministic UPDATEDETAIL: multiple updates to a row by a single query for column store table.

处理方法 通过Function的exception方式屏蔽该报错，将大小统一到一个值，对于不存在的表，可以用大小为-1来表示，函数如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 CREATE OR REPLACE FUNCTION public.pg_t_size(tab_oid OID,OUT retrun_code text) RETURNS text LANGUAGE plpgsql AS $$ DECLARE v_sql text; ts text; BEGIN V_SQL:='select pg_size_pretty(pg_table_size('||tab_oid||'))'; EXECUTE IMMEDIATE V_SQL into ts; IF ts IS NULL THEN RETRUN_CODE:=-1; ELSE return ts; END IF; EXCEPTION WHEN OTHERS THEN RETRUN_CODE:=-1; END$$; 执行如下命令查询结果： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 call public.pg_t_size('1',''); retrun_code ------------- -1 (1 row) select oid from pg_class limit 2; oid ------ 2662 2659 (2 rows) call public.pg_t_size('2662',''); retrun_code ------------- 120 KB (1 row)

问题现象 某表table01中存在以大小写字母组合的名称为“ColumnA”的字段，使用SELECT语句查询该字段时，提示字段不存在，报错：column "columna" does not exist。 1 2 3 4 5 select ColumnA from table01 limit 100; ERROR: column "columna" does not exist LINE 1: select columna from TABLE_01; ^ CONTEXT: referenced column: columna

JDBC问题定位 JDBC（Java Database Connectivity，java数据库连接）是应用程序访问数据库的统一标准接口，应用程序可使用JDBC连接数据库并执行SQL。 GaussDB(DWS)提供了对JDBC 4.0特性的支持，本章节提供了JCDB常见问题定位及对应报错和问题的处理方法。 产生JDBC问题的原因主要分为以下三个方面： 应用程序和应用程序框架问题。 JDBC业务功能问题。 数据库配置问题。 JDBC问题在具体业务中的表现主要分为以下三个方面： 执行报错，JDBC抛出异常。 执行效率低，耗时异常。 特性不支持，JDBC未实现的JDK接口。 JDBC问题具体分类可参见表1。 表1 JDBC问题分类 问题分类 问题原因 建立数据库连接失败 JDBC客户端配置问题：包括URL格式不对，或用户名密码错误。 网络不通。 Jar包冲突。 数据库配置问题，数据库未配置远程访问权限。 执行业务抛出异常 传入SQL有误，GaussDB(DWS)不支持。 业务处理异常，返回异常报文。 网络故障。 数据库连接超时，socket已关闭。 性能问题 SQL执行慢。 结果集过大，导致应用程序段响应慢。 用户传入SQL过长，JDBC解析慢。 功能支持问题 JDK未提供标准接口。 JDBC未实现接口。 父主题： JDBC/ODBC类

处理方法 使用SQL客户端工具连接数据库。 执行如下命令查看当前会话。 1 SELECT * FROM pg_stat_activity; 查询结果中的关键字段，说明如下： datname：用户会话所连接的数据库名称。 usename：连接数据库的用户名。 client_addr：连接数据库的客户端主机的IP地址。 在查询结果中，找出待删除的数据库名称及对应的客户端主机IP地址。 请根据客户端主机的IP地址排查连接数据库的机器及应用，并停止相关的连接。 1 CLEAN CONNECTION TO ALL FOR DATABASE database_name; 重新执行删除数据库的命令。 1 DROP DATABASE [ IF EXISTS ] database_name;

分析过程 和用户确认是部分业务慢，获取部分慢SQL后，打印执行计划，分析出耗时主要在index scan上，可能是IO争抢导致，通过监控IO，发现并没有IO资源使用瓶颈。 查询当前活跃SQL，发现有大量的CREATE INDEX语句，需要和用户确认该业务是否合理。 1 SELECT * from pg_stat_activity where state !='idle' and usename !='Ruby'; 根据执行计划，发现在部分DN上耗时较高，查询表的倾斜情况，并未发现有倾斜的情况。 1 SELECT table_skewness('table name'); 联系运维人员登录集群实例，检查内存相关参数，设置不合理，需要优化。 单节点总内存大小为256GB。 max_process_memory为12GB，设置过小。 shared_buffers为32MB，设置过小。 work_mem：CN：64MB 、DN：64MB。 max_active_statements为-1（不限制并发数）。 按以下值设置： gs_guc set -Z coordinator -Z datanode -N all -I all -c "max_process_memory=25GB" gs_guc set -Z coordinator -Z datanode -N all -I all -c "shared_buffers=8GB" gs_guc set -Z coordinator -Z datanode -N all -I all -c "work_mem=128MB" 进一步分析扫描慢的原因，发现表数据膨胀严重，对其中一张8GB大小的表，总数据量5万条，做完VACUUM FULL后大小减小为5.6MB。

解决办法 通过流控机制防止网络压力过大，需要设置以下GUC参数的值控制网络流量峰值。 comm_quota_size = 400，comm_usable_memory = 100 。 通过如下步骤修改参数值： 登录GaussDB(DWS) 管理控制台。 在左侧导航树，单击“集群管理”。 在集群列表中找到所需要的集群，然后单击集群名称。 进入集群的“参数修改”页面，分别找到“comm_quota_size”和“comm_usable_memory”参数，修改其参数值，单击“保存”，确认无误后再单击“保存”。 数据库在识别此类错误后，会自动进行重试，重试次数使用GUC变量max_query_retry_times来控制。 目前仅支持单条SQL语句的重试，暂不支持事务块中出错SQL重试。