华为云用户手册

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

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

在modifyJdbcCall和createParameterizedQuery阶段耗时 问题分析：如果主要耗时在modifyJdbcCall阶段（校验传入的SQL是否符合规范）和createParameterizedQuery阶段（将传入的SQL解析为preparedQuery，以获取由simplequery组成的subqueries），则需要确认是否传入的SQL过长导致。 处理方法：JDBC本身没办法优化这部分耗时，可在应用端查看是否可优化传入的SQL语句，详情可参见SQL语句改写规则。

处理方法 删除该表索引信息。 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 910111213 \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_defaultRange partition by(a)Number of partition: 2 (View pg_partition to check each partition range.)Has OIDs: noDistribute By: HASH(a)Location Nodes: ALL DATANODESOptions: 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 91011 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 | reldeltaidx | 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 910 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分区的索引信息。 12 START TRANSACTION read write;DELETE from pg_partition where relname = 'p1_index'; 查看表定义报错与现场报错相同，问题复现： 12 \d+ a_0317ERROR: The local index 700633 on the partition 700647 not exist.CONTEXT: referenced column: pg_get_indexdef

处理方法 要删除的用户为一个数据库的owner，需要将对象的所有权重新分配给其他用户。有以下两种处理方法： 方式一：将数据库owner转移给其他用户。例如，使用ALTER语句将数据库testdb的owner用户u1修改为u2。 12345678 testdb=# ALTER DATABASE testdb OWNER to u2;ALTER DATABASEtestdb=# \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+-------------+-------------+------------------------- testdb | u2 | UTF8 | en_US.UTF-8 | en_US.UTF-8 |(4 rows) 执行删除u1用户的命令，不再提示“owner of database testdb”的信息。 123 testdb=# DROP USER u1;ERROR: role "u1" cannot be dropped because some objects depend on it DETAIL: 3 objects in database gaussdb 方式二：如果已确认不需要数据库testdb，也可直接将其删除。将所有u1拥有的数据库对象的属主更改为u2。 12 testdb=# REASSIGN OWNED BY u1 TO u2;REASSIGN OWNED 清理owner是u1的对象。请谨慎使用，会将用户同名的schema也一同清理掉。 12 testdb=# DROP OWNED by u1;DROP OWNED 要删除的用户存在依赖关系，需要解除依赖关系。处理方法如下： 识别依赖关系。根据报错信息“3 objects in database gaussdb”可知gaussdb数据库里有3个对象依赖u1。由于数据库内系统表的依赖，在其他数据库中不会打印出详细的依赖对象信息，那么在gaussdb库中执行DROP USER的时候，会打印出具体的信息。 连接到gaussdb库执行如下命令： 1234 gaussdb=# DROP USER u1;ERROR: role "u1" cannot be dropped because some objects depend on itDETAIL: privileges for table pg_classprivileges for schema u2 获取到依赖项的详细信息如下： privileges for table pg_class：pg_class上u1用户的权限。 schema u2上u1用户的权限。 撤销依赖对象的权限。 1 2 3 4 5 6 7 8 9101112131415 gaussdb=# SELECT relname,relacl FROM pg_class WHERE relname = 'pg_class'; relname | relacl----------+---------------------------------- pg_class | {=r/Ruby,u1=r/Ruby}(1 row)gaussdb=#SELECT nspname,nspacl FROM pg_namespace WHERE nspname = 'u2'; nspname | nspacl---------+----------------------------- u2 | {u2=UC/u2,u2=LP/u2,u1=U/u2}gaussdb=# REVOKE SELECT ON TABLE pg_class FROM u1;REVOKEgaussdb=# REVOKE USAGE ON SCHEMA u2 FROM u1;REVOKE 再删除用户，可成功删除，不再提示有依赖。 12 gaussdb=# DROP USER u1;DROP USER

问题现象 数据库使用中遇到某些用户离职或者角色变更时，要对其账号进行销户、权限进行回收等操作，但是删除用户时出现类似：role “u1” cannot be dropped because some objects depend on it的报错信息，无法删除该用户。 例如，要删除用户u1时，出现如下提示： 1234 testdb=# DROP USER u1;ERROR: role "u1" cannot be dropped because some objects depend on it DETAIL: owner of database testdb 3 objects in database gaussdb

原因分析 两个不同的事务对同一个表中的同一行数据进行并发更新/操作，导致后操作的事务发生了回滚。 举例说明： 打开一个连接Session A，使用普通用户u1连接GaussDB(DWS)数据库，在u1的同名SCHEMA u1下创建测试表u1.test，并插入数据。 12 CREATE TABLE test (id int, name varchar(50));INSERT INTO test VALUES (1, 'lily'); 打开一个新的连接会话Session B，使用系统管理员dbadmin连接GaussDB(DWS)数据库，开启事务1，执行UPDATE操作，UPDATE语句执行成功。 1234 START TRANSACTION;UPDATE u1.test SET id = 3 WHERE name = 'lily';UPDATE 1 在会话Session A中开启事务2，执行相同的UPDATE语句，执行报错。 1234 START TRANSACTION;UPDATE test SET id = 3 WHERE name = 'lily';ERROR: dn_6003_6004: abort transaction due to concurrent update test 289502. 针对上述案例，两个不同的事务并发更新了同一条记录，而并发更新同一条记录发生冲突不会等待锁，直接报错：abort transaction due to concurrent update。 在实际业务中，并不是只有并发UPDATE同一条记录会报错，select、delete等其他SQL并发操作，也有可能报错：abort transaction due to concurrent update。

排查方法 查看相关表CU中数据分布情况，以下操作在DN执行。 查看列存表对应的cudesc表 针对非分区表： 1 SELECT 'cstore.'||relname FROM pg_class where oid = (SELECT relcudescrelid FROM pg_class c inner join pg_namespace n on c.relnamespace = n.oid where relname = 'table name' and nspname = 'schema name'); 针对分区表： 1 SELECT 'cstore.'||relname FROM pg_class where oid in (SELECT p.relcudescrelid FROM pg_partition p,pg_class c,pg_namespace n where c.relnamespace = n.oid and p.parentid = c.oid and c.relname = 'table name' and n.nspname = 'schema name' and p.relcudescrelid != 0); 查看cudesc中各CU的rowcount情况 查询步骤一返回的cudesc表信息，查询结果类似如下，主要关注row_count过小（远小于6w）的CU数量，如果此数量较大，说明当前小CU多，CU膨胀问题严重，影响存储效率和查询访问效率。

场景5：无分区、有分区不剪枝 例如某业务表进场使用createtime时间列作为过滤条件获取特定时间数据，对该表设计为分区表后没有走分区剪枝（Selected Partitions数量多），Scan花了701785ms，I/O效率极低。 在增加分区键createtime作为过滤条件后，Partitioned scan走分区剪枝（Selected Partitions数量极少），性能从700s优化到10s，I/O效率极大提升。 常见场景：按照时间存储数据的大表，查询特征大多为访问当天或者某几天的数据，这种情况应该通过分区键进行分区剪枝（只扫描对应少量分区）来极大提升I/O效率，不走分区剪枝常见的情况有： 未设计成分区表。 设计了分区没使用分区键做过滤条件。 分区键做过滤条件时，对列值有函数转换。 触发因素：未合理使用分区表和分区剪枝功能，导致扫描效率低。 处理方式： 对按照时间特征存储和访问的大表设计成分区表。 分区键一般选离散度高、常用于查询过滤条件中的时间类型的字段。 分区间隔一般参考高频的查询所使用的间隔，需要注意的是针对列存表，分区间隔过小（例如按小时）可能会导致小文件过多的问题，一般建议最小间隔为按天。

场景6：行存表求count值 某行存大表频繁全表count（指不带过滤条件或者过滤条件过滤很少数据的count），其中Scan花费43s，持续占用大量I/O，此类作业并发起来后，整体系统I/O持续100%，触发I/O瓶颈，导致整体性能慢。 对比相同数据量的列存表（A-rows均为40960000），列存的Scan只花费14ms，I/O占用极低。 触发因素：行存表因其存储方式的原因，全表scan的效率较低，频繁的对大表全表扫描，导致I/O持续占用。 解决办法： 业务侧审视频繁全表count的必要性，降低全表count的频率和并发度。 如果业务类型符合列存表，则将行存表修改为列存表，提高I/O效率。

场景7：行存表求max值 计算某行存表某列的max值，花费了26772ms，此类作业并发起后，整体系统I/O持续100%，触发I/O瓶颈，导致整体性能慢。 针对max列增加索引后，语句耗时从26s优化到32ms，极大减少I/O消耗。 触发因素：行存表max值逐个scan符合条件的值来计算max，当scan的数据量很大时，会持续消耗I/O。 解决办法：给max列增加索引，凭借btree索引数据有序存储的特征，加速扫描过程，降低I/O消耗。

场景10：小文件多IOPS高 某业务执行过程中，整个集群IOPS飙高，另外当出现集群故障后，长期Building不成功，IOPS飙高，相关表信息如下： SELECT relname,reloptions,partcount FROM pg_class c INNER JOIN ( SELECT parentid,count(*) AS partcount FROM pg_partition GROUP BY parentid ) s ON c.oid = s.parentid ORDER BY partcount DESC; 触发因素：某业务库大量列存多分区（3000+）的表，导致小文件巨多（单DN文件2000w+），访问效率低，故障恢复Building极慢，同时Building也消耗大量IOPS，反向影响业务性能。 解决办法： 整改列存分区间隔，减少分区个数来降低文件个数。 列存表修改为行存表，行存的存储特征决定其文件个数不会像列存般膨胀严重。

场景8：大量数据带索引导入 某业务场景数据往DWS同步时，延迟严重，集群整体I/O压力大。 后台查看等待视图有大量wait wal sync和WALWriteLock状态，均为xlog同步状态。 触发因素：大量数据带索引（一般超过3个）导入（insert/copy/merge into）会产生大量xlog，导致主备同步慢，备机长期Catchup，整体I/O利用率飙高。。 解决方案： 严格控制每张表的索引个数，建议3个以内。 大量数据导入前先将索引删除，导入完成后再重新建索引。

场景9：行存大表首次查询 某业务场景出现备DN持续catchup，I/O压力大，观察某个SQL等待视图在wait wal sync。 排查业务发现某查询语句执行时间较长，执行kill命令后恢复。 触发因素：行存表大量数据入库后，首次查询触发page hint产生大量X LOG ，触发主备同步慢及大量I/O消耗。 解决措施： 对该类一次性访问大量新数据的场景，修改行存表为列存表。 可关闭wal_log_hints和enable_crc_check参数（不推荐该方式，因故障期间有数据丢失风险）。

场景4：无索引、有索引不走 某一次点查询，Seq Scan扫描需要3767ms，因涉及从4096000条数据中获取8240条数据，符合索引扫描的场景（海量数据中寻找少量数据），在对过滤条件列增加索引后，计划依然是Seq Scan而没有走Index Scan。 对目标表ANALYZE后，计划能够自动选择索引，性能从3s+优化到2ms+，极大降低I/O消耗。 常见场景：行存大表的查询场景，从大量数据中访问极少数据，没走索引扫描而是走顺序扫描，导致I/O效率低，不走索引常见有两种情况： 过滤条件列上没建索引。 有索引但是计划没选索引扫描。 触发因素： 常用过滤条件列没有建索引。 表中数据因执行DML操作后产生数据变化未及时ANALYZE，导致优化器无法选择索引扫描计划，ANALYZE介绍参见ANALYZE 。 处理方式： 对行存表常用过滤列增加索引，索引基本设计原则： 索引列选择distinct值多，且常用于过滤条件，过滤条件多时可以考虑建组合索引，组合索引中distinct值多的列排在前面，索引个数不宜超过3个。 大量数据带索引导入会产生大量I/O，如果该表涉及大量数据导入，需严格控制索引个数，建议导入前先将索引删除，导入完成后再重新建索引。 对频繁做DML操作的表，业务中加入及时ANALYZE，主要场景： 表数据从无到有。 表频繁进行INSERT/UPDATE/DELETE。 表数据即插即用，需要立即访问且只访问刚插入的数据。

场景1：列存小CU膨胀 某业务SQL查询出390871条数据需43248ms，分析计划主要耗时在Cstore Scan。 Cstore Scan的详细信息中，每个DN扫描出2w左右的数据，但是扫描了有数据的CU（CUSome）155079个，没有数据的CU（CUNone）156375个，说明当前小CU、未命中数据的CU极多，即CU膨胀严重。 触发因素：对列存表（尤其是分区表）进行高频小批量导入会造成CU膨胀。 处理方法 列存表的数据入库方式修改为攒批入库，单分区单批次入库数据量需大于DN个数*6W。 如果因业务原因无法攒批入库，则需定期VACUUM FULL此类高频小批量导入的列存表。 当小CU膨胀很快时，频繁VACUUM FULL也会消耗大量I/O，甚至加剧整个系统的I/O瓶颈，此场景建议修改列存表为行存表（CU长期膨胀严重的情况下，列存的存储空间优势和顺序扫描性能优势将不复存在）。

场景3：表存储倾斜 例如表Scan的A-time中，max time DN执行耗时6554ms，min time DN耗时0s，DN之间扫描差异超过10倍以上，这种集合Scan的详细信息，基本可以确定为表存储倾斜导致。 通过table_distribution发现所有数据倾斜到了dn_6009单个DN，修改分布列使得表存储分布均匀后，max dn time和min dn time基本维持在相同水平400ms左右，Scan时间从6554ms优化到431ms。 触发因素：分布式场景，表分布列选择不合理会导致存储倾斜，同时导致DN间压力失衡，单DN I/O压力大，整体I/O效率下降。 解决办法：修改表的分布列使表的存储分布均匀，分布列选择原则参见选择分布列。

场景2：脏数据&数据清理 某业务SQL总执行时间2.519s，其中Scan占了2.516s，同时该表的扫描最终只扫描到0条符合条件数据，过滤了20480条数据，即总共扫描了20480+0条数据却消耗了2s+，扫描时间与扫描数据量严重不符，此现象可判断为由于脏数据多从而影响扫描和I/O效率。 查看表脏页率为99%，VACUUM FULL后性能优化到100ms左右。 触发因素：表频繁执行UPDATE/DELETE导致脏数据过多，且长时间未VACUUM FULL清理。 处理方法 对频繁UPDATE/DELETE产生脏数据的表，定期VACUUM FULL，因大表的VACUUM FULL也会消耗大量I/O，因此需要在业务低峰时执行，避免加剧业务高峰期I/O压力。 当脏数据产生很快，频繁VACUUM FULL也会消耗大量I/O，甚至加剧整个系统的I/O瓶颈，这时需要考虑脏数据的产生是否合理。针对频繁DELETE的场景，可以考虑如下方案： 全量DELETE修改为TRUNCATE或者使用临时表替代。 定期DELETE某时间段数据，使用分区表并使用TRUNCATE或DROP分区替代。

分析过程 GUC参数comm_max_stream表示任意两个DN之间stream的最大数量。 在CN上查询当前任意两个DN之间stream情况： 1 SELECT node_name,remote_name,count(*) FROM pgxc_comm_send_stream group by 1,2 order by 3 desc limit 100; 在DN上查询当前DN与其他DN之间stream情况： 1 SELECT node_name,remote_name,count(*) FROM pg_comm_send_stream group by 1,2 order by 3 desc limit 100; comm_max_stream参数值必须大于并发数*每并发平均stream算子数*（smp的平方）。 该参数默认值为：通过公式min(query_dop_limit * query_dop_limit * 2 * 20, max_process_memory(字节) * 0.025 /(最大CN数+当前DN数) / 260)计算，小于1024按照1024取值，其中query_dop_limit = 单个机器CPU核数 / 单个机器DN数。 不建议该参数值设置过大，因为comm_max_stream会占用内存（占用内存=256byte*comm_max_stream*comm_max_datanode），如果并发数据流数过大，查询较为复杂及smp过大都会导致内存不足。 如果comm_max_datanode参数值较小，进程内存充足，可以适当将comm_max_stream值调大。

处理方法 故障构造场景 使用客户端连接DWS数据库。 执行以下SQL语句。 1 2 3 4 5 6 7 8 9101112 CREATE TABLE t1(a int, b timestamp);CREATE TABLECREATE TABLE t2(a int, b text);CREATE TABLEINSERT INTO t1 select 1, current_date;INSERT 0 1INSERT INTO t2 select 1, current_date;INSERT 0 1SELECT * FROM t1 UNION SELECT * FROM t2;ERROR: UNION types timestamp without time zone and text cannot be matchedLINE 1: SELECT * FROM t1 UNION SELECT * FROM t2; ^ 解决办法 示例中，t1表和t2表在b列上类型不同，导致在UNION操作时出现类型不匹配的报错，应保证UNION各分支相同位置的输出列类型匹配。 t2表b列是text类型，插入的数据是current_date，在插入时发生了隐式类型转换，所以插入不报错；但是在查询时，不会自动进行隐式转换，因此会报错。 解决以上问题，需保证UNION各分支的输出列类型匹配，不满足要求时可以对输出列强制类型转化。 123456 SELECT a,b::text FROM t1 UNION SELECT a,b FROM t2; a | b ---+--------------------- 1 | 2023-02-16 1 | 2023-02-16 00:00:00(2 rows)

处理方法 8.0以下版本集群清理系统表需要先执行DELETE FROM，再执行VACUUM FULL。 此处仅以gs_wlm_session_info系统表为例： 12 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。

原因分析 请先判断同名的表是否确实是同一张表。在关系型数据库中，确定一张表通常需要3个因素：database，schema，table。从问题现象描述看，database，table已经确定，分别是human_resource、areas。接着，需要检查schema。使用dbadmin，user01分别登录发现，search_path依次是public和"$user"。dbadmin作为集群管理员，默认不会创建dbadmin同名的schema，即不指定schema的情况下所有表都会建在public下。而对于普通用户如user01，则会在创建用户时，默认创建同名的schema，即不指定schema时表都会创建在user01的schema下。最终确定该案例发生时，确实因为2个用户之间交错对表进行操作，导致了同名不同表的情况。

处理方法 可使用ALTER USER或者ALTER ROLE语法指定USEFT参数赋予角色或用户使用外表的权限。 参数USEFT | NOUSEFT决定一个新角色或用户是否能操作外表，包括：新建外表、删除外表、修改外表、读写外表。 指定USEFT表示角色或用户可操作外表。 缺省为NOUSEFT。表示新角色或用户没有操作外表的权限。 请使用数据库管理员用户给普通用户或角色赋予使用外表的权限，示例如下： 1 ALTER USER user_name USEFT; 修改用户或角色权限等信息的详细内容请参见ALTER USER或者ALTER ROLE。 对普通用户或角色赋予使用外表的权限后即可创建外表。

问题现象 创建GDS或OBS外表语句时，管理员用户可以执行成功，但普通用户执行时报错“ERROR: permission denied to create foreign table in security mode.”。 1 2 3 4 5 6 7 8 91011121314151617181920 CREATE USER u1 PASSWORD '{password}';SET current_schema = u;CREATE FOREIGN TABLE customer_ft( c_customer_sk integer , c_customer_id char(16) , c_current_cdemo_sk integer , c_current_hdemo_sk integer , c_current_addr_sk integer ) SERVER gsmpp_server OPTIONS( location 'gsfs://192.168.0.90:5000/customer1*.dat', FORMAT 'TEXT' , DELIMITER '|', encoding 'utf8', mode 'Normal')READ ONLY;ERROR: permission denied to create foreign table in security mode

原因分析 系统连接数量超过了最大连接数量，会显示如下错误信息。 12 gsql -d human_resource -h 10.168.0.74 -U user1 -p 8000 -W password -rgsql: FATAL: sorry, too many clients already 用户不具备访问该数据库的权限，会显示如下错误信息。 123 gsql -d human_resource -h 10.168.0.74 -U user1 -p 8000 -W password -rgsql: FATAL: permission denied for database "human_resource"DETAIL: User does not have CONNECT privilege. 网络连接故障。

处理方法 通过toast的OID（示例中为2619，来源于报错信息的pg_toast_2619）查询出哪张表发生了损坏： 12345 SELECT 2619::regclass; regclass-------------- pg_statistic(1 row) 对已定位的损坏表（步骤1中查询得到的表pg_statistic），执行REINDEX和VACUUM ANALYZE操作。显示REINDEX/VACUUM，表示修复完成。如果修复过程中出现报错，请继续执行步骤3。 123 REINDEX table pg_toast.pg_toast_2619;REINDEX table pg_statistic;VACUUM ANALYZE pg_statistic; 执行以下的命令定位该表中损坏的数据行。 1 2 3 4 5 6 7 8 91011121314 DO $$declare v_rec record;BEGINfor 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_2619CONTEXT: 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操作对该表重新进行修复。

问题现象 向表中插入数据报错：null value in column '%s' violates not-null constraint，此处s%指报错的列（字段）名。 1234 CREATE TABLE t1(a int, b int not null);INSERT INTO t1 VALUES (1);ERROR: dn_6001_6002: null value in column "b" violates not-null constraint

解决方案 针对上述案例，有两种解决方案： 方案一：使用ALTER TABLE删除字段b的非空（not null）约束 12345 ALTER TABLE t1 ALTER COLUMN b DROP NOT NULL;ALTER TABLEINSERT INTO t1 VALUES (1);INSERT 0 1 方案二：保持字段b的非空（not null）约束，字段b不再插入空值 在实际业务中，可根据实际情况选择解决方案。

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