华为云用户手册

No suitable driver found for XXXX 问题分析：通过JDBC建连时URL格式错误。 处理方法：将URL格式修改为正确的格式。 gsjdbc4.jar对应URL格式为： jdbc:postgresql://host:port/database 在使用pom依赖时对应8.1.x版本 gsjdbc200.jar对应URL格式为：jdbc:gaussdb://host:port/database 在使用pom依赖时对应8.1.x-200版本

Connections could not be acquired from the underlying database! 问题分析：按照新建连接排查项进行排查： 驱动配置是否有误。 数据库连接地址是否有误。 密码或账号是否有误。 数据库未启动或无权访问。 项目未引入对应的驱动jar包。 处理方法： 排查驱动配置，将其修改为正确的驱动配置。 gsjdbc4.jar driver=org.postgresql.Driver gsjdbc200.jar driver=com.huawei.gauss200.jdbc.Driver 排查数据库连接地址，将其修改为正确的数据库连接地址。 gsjdbc4.jar对应jdbc:postgresql://host:port/database gsjdbc200.jar对应jdbc:gaussdb://host:port/database 排查用户名密码是否为数据库用户名或密码，将其修改为正确的数据库用户名或密码。 排查数据库是否启动或有权限访问。 检查使用的JDBC驱动是gsjdbc4.jar还是gsjdbc200.jar，请使用正确JDBC驱动jar包。 gsjdbc4.jar：与PostgreSQL保持兼容，其中类名、类结构与PostgreSQL驱动完全一致，曾经运行于PostgreSQL的应用程序可以直接移植到当前系统中使用。 gsjdbc200.jar：如果同一JVM进程内需要同时访问PostgreSQL及 GaussDB (DWS) 请使用该驱动包。该包主类名为“com.huawei.gauss200.jdbc.Driver”（即将“org.postgresql”替换为“com.huawei.gauss200.jdbc”），数据库连接的URL前缀为“jdbc:gaussdb”，其余与gsjdbc4.jar相同。

Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. 问题分析：客户端与服务端网络不通、端口错误或待连接CN异常。 处理方法： 客户端ping服务端IP，查看网络是否畅通，网络不通则需解决网络问题。 检查URL中连接CN的端口是否正确，若端口不正确则需修改为正确的端口（默认为8000）。

org.postgresql.util.PSQLException: FATAL: terminating connection due to administrator command Session unused timeout 问题分析：会话超时导致连接断开。 处理方法：排查CN和客户端JDBC上的超时配置，按业务实际情况调长超时时间或关闭超时设置。 查看报错的CN日志，如果有session unused timeout这样的日志，说明是会话超时导致的。 解决办法： 登录控制台单击指定集群名称。 在左侧导航栏选择“参数修改”，搜索参数“session_timeout”查看超时时间参数。 将session_timeout的CN、DN参数值设置为0，详情可参见修改数据库参数。

conflict 问题分析：JDBC jar包和应用程序冲突。例如JDBC和应用程序拥有相同路径相同名称的类导致： gsjdbc4.jar和开源postgresql.jar冲突，两者具有完全相同的类名。 gsjdbc4.jar由于 IAM 特性引入了一些其他工具，例如fastjson，和应用程序中的fastjson冲突。 处理方法： 针对和开源postgresql.jar的冲突，DWS提供了gsjdbc200.jar，使用和开源驱动不同的url格式和驱动路径，驱动名由org.postgresql.Driver修改为com.huawei.gauss200.jdbc.Driver，URL格式由org:postgresql://host:port/database改为jdbc:gaussdb://host:port/database，彻底解决了和开源jar包的冲突。 针对JDBC引入的jar和应用程序中引入jar的冲突，可以通过maven的shade修改了jar中类的路径，解决此类冲突。 排查使用的JDBC驱动是gsjdbc4.jar还是gsjdbc200.jar，如果是gsjdbc4.jar应该替换为gsjdbc200.jar，尝试建立连接。 对于pom依赖，将8.1.x版本替换为8.1.x-200版本。

JDBC DEV环境没问题，测试环境连接出错报空指针或URI报错uri is not hierarchical 问题分析：某些虚拟环境不支持获取扩展参数，需关闭。 处理方法：在连接时可设置连接参数“connectionExtraInfo=false”，详情可参见使用JDBC连接数据库。 1 jdbc:postgresql://host:port/database?connectionExtraInfo=false

解决方案 建议根据业务实际情况调整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.

扩展 除上述场景会出现存在多个collation造成冲突，以下两种场景也会出现多个collation，报错不同但解决方法相同。 场景一 SELECT语句中比较表达式a=b存在多个collation造成冲突，执行报错could not determine which collation to use for string comparison。 1 2 3 SELECT a=b FROM t; ERROR: dn_6001_6002: could not determine which collation to use for string comparison HINT: Use the COLLATE clause to set the collation explicitly. 执行SELECT时，指定表达式a=b的排序规则为case_insensitive。 1 2 3 4 5 SELECT a=b COLLATE case_insensitive FROM t; ?column? ---------- f (1 row) 场景二 SELECT语句中表达式instr(a,b)存在多个collation造成冲突，执行报错could not determine which collation to use for string searching。 1 2 3 SELECT instr(a,b) FROM t; ERROR: dn_6005_6006: could not determine which collation to use for string searching HINT: Use the COLLATE clause to set the collation explicitly. 执行SELECT时，指定字段a的排序规则为case_insensitive或者指定字段b的排序规则为C来保证字段排序规则的统一。 1 2 3 4 5 6 7 8 9 10 11 SELECT instr(a collate case_insensitive,b) FROM t; instr ------- 0 (1 row) SELECT instr(a,b collate "C") FROM t; instr ------- 0 (1 row)

问题现象 执行SELECT查询时报错could not determine which collation to use for string hashing。 1 2 3 4 5 6 CREATE TABLE t(a text collate "C", b text collate case_insensitive); INSERT INTO t VALUES('Hello','world'); ——计算ifnull(a,b)的值的哈希值 SELECT hashtext(ifnull(a,b)) FROM t; ERROR: dn_6005_6006: could not determine which collation to use for string hashing. HINT: Use the COLLATE clause to set the collation explicitly. hashtext函数用于计算适当数据类型的值的哈希值。此处仅用作示例说明出现collate冲突时应该如何解决。

处理方法 当字符串表达式中collation有多个时，可手动指定COLLATE collation_name。 执行SELECT时，指定表达式ifnull(a,b)的排序规则为C或者case_insensitive。 1 2 3 4 5 6 7 8 9 10 11 SELECT hashtext(ifnull(a,b) collate "C") FROM t; hashtext ----------- 820977155 (1 row) SELECT hashtext(ifnull(a,b) collate case_insensitive) FROM t; hashtext ----------- 238052143 (1 row)

问题现象 创建范围分区表后增加新的分区，使用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

原因分析 增加分区时需同时满足以下条件： 新增分区名不能与已有分区名相同。 新增分区的边界值必须大于最后一个分区的上边界。 新增分区的边界值要和分区表的分区键的类型一致。 已有分区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;

处理方法 方式一：通过控制台修改statement_timeout参数。 登录GaussDB(DWS)管理控制台。 在左侧导航栏中，单击“集群管理”。 在集群列表中找到所需要的集群，单击集群名称，进入集群“基本信息”页面。 单击“参数修改”页签，根据需要修改参数“statement_timeout”默认值，然后单击“保存”。 GaussDB(DWS)默认不限制SQL超时，即statement_timeout默认值为0。如用户手动修改过该参数，建议恢复原默认值0，或者根据需要调整SQL超时时间，避免设置的SQL超时时间对其它任务产生影响。 在“修改预览”窗口，确认修改无误后，单击“保存”。 参数“statement_timeout”所在行“是否重启”列显示为“否”，表示该参数修改后无需进行重启操作，即修改后立即生效。 图1 修改参数statement_timeout 方式二：成功连接集群后，通过SQL命令修改statement_timeout参数。 使用SET语句修改（会话级别）： 1 SET statement_timeout TO 0; 使用ALTER ROLE语句修改（用户级别）： 1 ALTER USER username SET statement_timeout TO 600000; 其中，username为要设置SQL语句超时时间的数据库用户名。

处理方法 建议开启列存表的delta表功能。 1 ALTER TABLE table_name SET (ENABLE_DELTA = ON); 开启列存表的delta表功能，在导入单条或者小规模数据进入表中时，能够防止小CU的产生，所以开启delta表能够带来显著的性能提升，例如在3CN、6DN的集群上操作，每次导入100条数据，导入时间能减少25%，存储空间减少97%，所以在需要多次插入小批量数据前应该先开启delta表，等到确定接下来没有小批量数据导入了再关闭。 delta表就是列存表附带的行存表，那么将数据插入delta表后将失去列存表的高压缩比等优势，正常情况下使用列存表的场景都是大批量数据导入，所以默认关闭delta表，如果开启delta表做大批量数据导入，反而会额外消耗更多时间和空间，同样在3CN、6DN的集群上操作，每次导入10000条数据时，开启delta表会比不开启时慢4倍，额外消耗10倍以上的空间。所以开启delta表需谨慎，根据实际业务需要来选择开启和关闭。

场景三：系统表过大导致VACUUM FULL执行慢 在排除IO/网络问题后，对空表执行VACUUM FULL，即使是空表执行VACUUM FULL也比较慢，则说明是系统表较大导致。因为VACUUM FULL任意一张表时，都会扫描pg_class、pg_partition、pg_proc三张系统表，当这三个系统表过大时，也会导致VACUUM FULL执行较慢。 处理方法：GaussDB(DWS)支持对系统表执行VACUUM FULL，但是会产生八级锁，涉及相关系统表的业务会被阻塞，注意要在业务空闲时间窗或停止业务期间且没有DDL操作时清理系统表。 有关清理系统表的操作，请参考哪些系统表不能做VACUUM FULL。

场景四：列存表使用了局部聚簇（PCK）时，VACUUM FULL执行慢 对列存表执行VACUUM FULL时，如果存在PCK，就会将PARTIAL_CLUSTER_ROWS中多条记录全都加载到内存中再进行排序，如果表较大或psort_work_mem设置较小，会导致PCK排序时产生下盘（数据库选择将临时结果暂存到磁盘），进行外部排序；一旦进行外部排序，时间消耗就会增加很多。 处理方法：根据表中数据的tuple length，合理调整PARTIAL_CLUSTER_ROWS和psort_work_mem的大小。 执行以下语句查看表定义。回显中存在“PARTIAL CLUSTER KEY”信息，表示存在PCK。 1 SELECT * FROM pg_get_tabledef('table name'); 登录DWS管理控制台，左侧选择“集群管理”。 单击对应的集群名称，进入集群详情页。 左侧选择“参数修改”，在搜索栏中输入psort_work_mem进行搜索，将CN参数值和DN参数值同时调大，单击“保存”。 再重新执行VACUUM FULL操作。

场景一：存在锁等待导致VACUUM FULL执行慢 8.1.x及以上集群版本的处理方法： 通过查询pgxc_lock_conflicts视图查看锁冲突情况。 1 SELECT * FROM pgxc_lock_conflicts; 在查询结果中查看granted字段为“f”，表示VACUUM FULL语句正在等待其他锁。granted字段为“t”，表示INSERT语句是持有锁。nodename，表示锁产生的位置，即CN或DN位置，例如cn_5001，继续执行2。 如果查询结果为0 rows，则表示不存在锁冲突。则需排查其它场景。 根据语句内容判断是终止持锁语句后继续执行VACUUM FULL还是在业务低峰期选择合适的时间执行VACUUM FULL。 如果要终止持锁语句，则执行以下语句。pid从上述步骤1获取，cn_5001为所查询到的nodename。 1 execute direct on (cn_5001) 'SELECT PG_TERMINATE_BACKEND(pid)'; 语句终止后，再重新执行VACUUM FULL。 1 VACUUM FULL table_name; 8.0.x及以前版本的处理方法： 在数据库中执行语句，获取VACUUM FULL操作对应的query_id。 1 SELECT * FROM pgxc_stat_activity WHERE query LIKE '%vacuum%'AND waiting = 't'; 根据1获取的query_id，执行以下语句查看是否存在锁等待。 1 SELECT * FROM pgxc_thread_wait_status WHERE query_id = {query_id}; 查询结果中“wait_status”存在“acquire lock”表示存在锁等待。同时查看“node_name”显示在对应的CN或DN上存在锁等待，记录相应的CN或DN名称，例如cn_5001或dn_600x_600y，继续执行3。 查询结果中“wait_status”不存在“acquire lock”，排除锁等待情况，继续排查其它场景。 执行以下语句，到等锁的对应CN或DN上从pg_locks中查看VACUUM FULL操作在等待哪个锁。以cn_5001为例，如果在DN上等锁，则改为相应的DN名称。pid为2获取的tid。 回显中记录relation的值。 1 execute direct on (cn_5001) 'SELECT * FROM pg_locks WHERE pid = {tid} AND granted = ''f'''; 根据获取的relation，从pg_locks中查看当前持有锁的pid。relation从3获取。 1 execute direct on (cn_5001) 'SELECT * FROM pg_locks WHERE relation = {relation} AND granted = ''t'''; 根据pid，执行以下语句查到对应的SQL语句。pid从4获取。 1 execute direct on (cn_5001) 'SELECT query FROM pg_stat_activity WHERE pid ={pid}'; 根据语句内容判断是终止持锁语句后继续执行VACUUM FULL还是在业务低峰期选择合适的时间执行VACUUM FULL。 如果要终止持锁语句，则执行以下语句。pid从上述4获取，cn_5001为所查询到的nodename。 1 execute direct on (cn_5001) 'SELECT PG_TERMINATE_BACKEND(pid)'; 语句终止后，再执行VACUUM FULL。 1 VACUUM FULL table_name;

处理方法 方法一：检查数据冲突，修改插入数据。例如，修改示例重复字段UA502为UA509。 1 2 INSERT INTO films VALUES ('UA509', 'Bananas', 105, '1971-07-13', 'Comedy', '82 minutes'); INSERT 0 1 方法二：删除表films主键约束。 1 2 3 4 ALTER TABLE films DROP CONSTRAINT films_pkey; ALTER TABLE INSERT INTO films VALUES ('UA502', 'Bananas', 105, '1971-07-13', 'Comedy', '82 minutes'); INSERT 0 1

问题现象 向表中插入数据报错：duplicate key value violates unique constraint "%s"。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 CREATE TABLE films ( code char(5) PRIMARY KEY, title varchar(40) NOT NULL, did integer NOT NULL, date_prod date, kind varchar(10), len interval hour to minute ); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "films_pkey" for table "films" CREATE TABLE INSERT INTO films VALUES ('UA502', 'Bananas', 105, DEFAULT, 'Comedy', '82 minutes'); INSERT INTO films VALUES ('UA502', 'Bananas', 105, '1971-07-13', 'Comedy', '82 minutes'); ERROR: dn_6003_6004: duplicate key value violates unique constraint "films_pkey" DETAIL: Key (code)=(UA502) already exists.

处理方法 通过toast的OID（示例中为2619，来源于报错信息的pg_toast_2619）查询出哪张表发生了损坏： 1 2 3 4 5 SELECT 2619::regclass; regclass -------------- pg_statistic (1 row) 对已定位的损坏表（步骤1中查询得到的表pg_statistic），执行REINDEX和VACUUM ANALYZE操作。显示REINDEX/VACUUM，表示修复完成。如果修复过程中出现报错，请继续执行步骤3。 1 2 3 REINDEX table pg_toast.pg_toast_2619; REINDEX table pg_statistic; VACUUM ANALYZE pg_statistic; 执行以下的命令定位该表中损坏的数据行。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 DO $$ declare v_rec record; BEGIN for v_rec in SELECT * FROM pg_statistic loop raise notice 'Parameter is: %', v_rec.ctid; raise notice 'Parameter is: %', v_rec; end loop; END; $$ LANGUAGE plpgsql; NOTICE: 00000: Parameter is: (46,9) ERROR: XX000: missing chunk number 0 for toast value 30982 in pg_toast_2619 CONTEXT: PL/pgSQL function inline_code_block line 7 at RAISE 将步骤3中定位的损坏数据行记录删除。 1 DELETE FROM pg_statistic WHERE ctid ='(46,9)'; 重复执行步骤3、步骤4，直到全部有问题的数据记录被删除。 损坏的数据行被删除后，执行步骤2中的REINDEX和VACUUM ANALYZE操作对该表重新进行修复。

原因分析 表关联的toast表的data发生损坏。 toast是The OverSized Attribute Storage Technique（超尺寸字段存储技术）的缩写，是超长字段在GaussDB(DWS)的一种存储方式。当某表中有超长字段的时候，那么该表会有与之相关联的toast表。根据toast表的命名规则，假设存在表名为test的OID为2619，那么如果存在与之相关联的toast表，则toast表名为pg_toast_2619。此报错中pg_toast_2619非固定表名，可根据实际报错对pg_toast_2619进行替换。

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

处理方法 应根据数据实际情况规划分区，以保证插入的数据都在规划好的分区中。 如果已规划的分区无法满足实际应用条件，可以增加分区后再插入数据。针对上述案例，可以增加分区c2，分区范围介于5000和MAXVALUE之间： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 ALTER TABLE startend_pt ADD PARTITION P6 VALUES LESS THAN (MAXVALUE); SELECT partition_name,high_value FROM dba_tab_partitions WHERE table_name='startend_pt'; partition_name | high_value ----------------+------------ p1_0 | 1 p1_1 | 201 p1_2 | 401 p1_3 | 601 p1_4 | 801 p1_5 | 1000 p2 | 2000 p3 | 2500 p4 | 3000 p5_1 | 4000 p5_2 | 5000 p6 | MAXVALUE (12 rows) INSERT INTO startend_pt VALUES (1,5001); SELECT * FROM startend_pt; c1 | c2 ----+------ 1 | 5001 (1 row)

问题现象 给范围分区表插入数据报错：inserted partition key does not map to any table partition。 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 27 CREATE TABLE startend_pt (c1 INT, c2 INT) DISTRIBUTE BY HASH (c1) PARTITION BY RANGE (c2) ( PARTITION p1 START(1) END(1000) EVERY(200) , PARTITION p2 END(2000), PARTITION p3 START(2000) END(2500) , PARTITION p4 START(2500), PARTITION p5 START(3000) END(5000) EVERY(1000) ); SELECT partition_name,high_value FROM dba_tab_partitions WHERE table_name='startend_pt'; partition_name | high_value ----------------+------------ p1_0 | 1 p1_1 | 201 p1_2 | 401 p1_3 | 601 p1_4 | 801 p1_5 | 1000 p2 | 2000 p3 | 2500 p4 | 3000 p5_1 | 4000 p5_2 | 5000 (11 rows) INSERT INTO startend_pt VALUES (1,5001); ERROR: dn_6003_6004: inserted partition key does not map to any table partition

处理方法 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。

处理方法 可在GaussDB(DWS)管理控制台设置告警的触发条件，指定达到磁盘使用率、告警持续时间及告警频次。 集群磁盘使用率达到90%就会触发集群只读，需要预留时间来处理问题，避免使用率达到只读阈值。 登录GaussDB(DWS) 管理控制台。 在左侧导航栏，单击“告警管理”，切换至“告警”页签。 单击左上角的“查看告警规则”按钮，进入告警规则页面。 在指定告警规则名称所在行操作列，单击“修改”按钮进入修改告警规则页面。将触发条件修改为平均值大于90%，抑制条件修改为“每1天告警一次”。（此处仅做举例，实际情况以业务诉求为准。） 触发条件：定义对监控指标做阈值判断的计算规则。目前主要使用一段时间内的平均值来降低告警震荡的几率。 抑制条件：在指定的时间段内，抑制同类型告警的反复触发和消除。 图1 设置告警规则

处理方法 根据评估，内存充足，将comm_max_stream参数值调大为2048。（参数值2048仅适用示例场景，请根据实际业务的内存查询结果进行参数值调整。） 登录GaussDB(DWS) 管理控制台。 在左侧导航栏中，单击“集群管理”。 在集群列表中找到所需要的集群，单击集群名称，进入集群“基本信息”页面。 单击“参数修改”页签，修改参数“comm_max_stream”，然后单击“保存”。 在“修改预览”窗口，确认修改无误后，单击“保存”。 参数“comm_max_stream”所在行“是否重启”列显示为“否”，表示该参数修改后无需进行重启操作，即修改后立即生效。