华为云用户手册

约束与限制 使用对象存储时，挂载点不支持修改属组和权限。 对于并行文件系统，CCE支持通过OBS SDK方式和PVC挂载方式使用，其中PVC挂载方式是通过OBS服务提供的obsfs工具实现。在节点上每挂载一个并行文件系统对象存储卷，就会产生一个obsfs常驻进程。如下图所示： 图1 obsfs常驻进程 建议为每个obsfs进程预留1G的内存空间，例如4U8G的节点，则建议挂载obsfs并行文件系统的实例不超过8个。 obsfs常驻进程是直接运行在节点上，如果消耗的内存超过了节点上限，则会导致节点异常。例如在4U8G的节点上，运行的挂载并行文件系统卷的实例超过100+，有极大概率会导致节点异常不可用。因此强烈建议控制单个节点上的挂载并行文件系统实例的数量。 在使用obsfs工具时，还需遵循obsfs约束与限制。 安全容器不支持使用对象存储。 挂载普通桶时不支持硬链接（Hard Link）。 支持多个PV挂载同一个对象存储，但有如下限制： 多个不同的PVC/PV使用同一个底层对象存储卷时，如果挂载至同一Pod使用，会因为PV的volumeHandle参数值相同导致无法挂载，请避免该使用场景。 PV中persistentVolumeReclaimPolicy参数建议设置为Retain，否则可能存在一个PV删除时，级联删除底层卷，其他关联这个底层卷的PV会由于底层存储被删除导致使用出现异常。 重复用底层存储时，数据一致性由您自行维护。建议在应用层做好多读多写的隔离保护，合理规划文件使用时间，避免出现多个客户端写同一个文件的情况，防止产生数据覆盖和丢失。

验证数据持久化及共享性 查看部署的应用及文件。 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-demo 预期输出如下： web-demo-846b489584-mjhm9 1/1 Running 0 46s web-demo-846b489584-wvv5s 1/1 Running 0 46s 依次执行以下命令，查看Pod的/data路径下的文件。 kubectl exec web-demo-846b489584-mjhm9 -- ls /data kubectl exec web-demo-846b489584-wvv5s -- ls /data 两个Pod均无返回结果，说明/data路径下无文件。 执行以下命令，在/data路径下创建static文件。 kubectl exec web-demo-846b489584-mjhm9 -- touch /data/static 执行以下命令，查看/data路径下的文件。 kubectl exec web-demo-846b489584-mjhm9 -- ls /data 预期输出如下： static 验证数据持久化 执行以下命令，删除名称为web-demo-846b489584-mjhm9的Pod。 kubectl delete pod web-demo-846b489584-mjhm9 预期输出如下： pod "web-demo-846b489584-mjhm9" deleted 删除后，Deployment控制器会自动重新创建一个副本。 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-demo 预期输出如下，web-demo-846b489584-d4d4j为新建的Pod： web-demo-846b489584-d4d4j 1/1 Running 0 110s web-demo-846b489584-wvv5s 1/1 Running 0 7m50s 执行以下命令，验证新建的Pod中/data路径下的文件是否更改。 kubectl exec web-demo-846b489584-d4d4j -- ls /data 预期输出如下： static static文件仍然存在，则说明数据可持久化保存。 验证数据共享性 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-demo 预期输出如下： web-demo-846b489584-d4d4j 1/1 Running 0 7m web-demo-846b489584-wvv5s 1/1 Running 0 13m 执行以下命令，在任意一个Pod的/data路径下创建share文件。本例中选择名为web-demo-846b489584-d4d4j的Pod。 kubectl exec web-demo-846b489584-d4d4j -- touch /data/share 并查看该Pod中/data路径下的文件。 kubectl exec web-demo-846b489584-d4d4j -- ls /data 预期输出如下： share static 由于写入share文件的操作未在名为web-demo-846b489584-wvv5s的Pod中执行，在该Pod中查看/data路径下是否存在文件以验证数据共享性。 kubectl exec web-demo-846b489584-wvv5s -- ls /data 预期输出如下： share static 如果在任意一个Pod中的/data路径下创建文件，其他Pod下的/data路径下均存在此文件，则说明两个Pod共享一个存储卷。

验证数据持久化 查看部署的应用及本地文件。 执行以下命令，查看已创建的Pod。 kubectl get pod | grep web-local 预期输出如下： web-local-0 1/1 Running 0 38s 执行以下命令，查看本地持久卷是否挂载至/data路径。 kubectl exec web-local-0 -- df | grep data 预期输出如下： /dev/mapper/vg--everest--localvolume--persistent-pvc-local 10255636 36888 10202364 0% /data 执行以下命令，查看/data路径下的文件。 kubectl exec web-local-0 -- ls /data 预期输出如下： lost+found 执行以下命令，在/data路径下创建static文件。 kubectl exec web-local-0 -- touch /data/static 执行以下命令，查看/data路径下的文件。 kubectl exec web-local-0 -- ls /data 预期输出如下： lost+found static 执行以下命令，删除名称为web-local-0的Pod。 kubectl delete pod web-local-0 预期输出如下： pod "web-local-0" deleted 删除后，StatefulSet控制器会自动重新创建一个同名副本。执行以下命令，验证/data路径下的文件是否更改。 kubectl exec web-local-0 -- ls /data 预期输出如下： lost+found static static文件仍然存在，则说明本地持久存储中的数据可持久化保存。

使用kubectl自动创建本地持久卷 使用kubectl连接集群。 使用StorageClass动态创建PVC及PV。 创建pvc-local.yaml文件。 apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-local namespace: default spec: accessModes: - ReadWriteOnce # 本地持久卷必须为ReadWriteOnce resources: requests: storage: 10Gi # 本地持久卷大小 storageClassName: csi-local-topology # StorageClass类型为本地持久卷 表2 关键参数说明 参数 是否必选 描述 storage 是 PVC申请容量，单位为Gi。 storageClassName 是 存储类名称，本地持久卷对应的存储类名称为csi-local-topology。 执行以下命令，创建PVC。 kubectl apply -f pvc-local.yaml 创建应用。 创建web-local.yaml文件，本示例中将本地持久卷挂载至/data路径。 apiVersion: apps/v1 kind: StatefulSet metadata: name: web-local namespace: default spec: replicas: 1 selector: matchLabels: app: web-local serviceName: web-local # Headless Service名称 template: metadata: labels: app: web-local spec: containers: - name: container-1 image: nginx:latest volumeMounts: - name: pvc-disk #卷名称，需与volumes字段中的卷名称对应 mountPath: /data #存储卷挂载的位置 imagePullSecrets: - name: default-secret volumes: - name: pvc-disk #卷名称，可自定义 persistentVolumeClaim: claimName: pvc-local #已创建的PVC名称 --- apiVersion: v1 kind: Service metadata: name: web-local # Headless Service名称 namespace: default labels: app: web-local spec: selector: app: web-local clusterIP: None ports: - name: web-local targetPort: 80 nodePort: 0 port: 80 protocol: TCP type: ClusterIP 执行以下命令，创建一个挂载本地持久存储的应用。 kubectl apply -f web-local.yaml 工作负载创建成功后，容器挂载目录下的数据将会持久化保持，您可以参考验证数据持久化中的步骤进行验证。

相关操作 您还可以执行表3中的操作。 表3 其他操作 操作 说明 操作步骤 事件 查看PVC或PV的事件名称、事件类型、发生次数、Kubernetes事件、首次和最近发生的时间，便于定位问题。 在左侧导航栏选择“存储”，在右侧选择“存储卷声明”或“存储卷”页签。 单击目标实例操作列的“事件”，即可查看1小时内的事件（事件保存时间为1小时）。 查看YAML 可对PVC或PV的YAML文件进行查看、复制和下载。 在左侧导航栏选择“存储”，在右侧选择“存储卷声明”或“存储卷”页签。 单击目标实例操作列的“查看YAML”，即可查看或下载YAML。

问题现象 执行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)

扩展 除上述场景会出现存在多个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)

处理方法 建议开启列存表的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表需谨慎，根据实际业务需要来选择开启和关闭。

处理方法 使用GRANT语法对表/schema进行赋权，示例： 假设当前有两个用户tom和jerry，如果想要用户jerry能够对当前tom创建的所有表以及将来创建的表都有查询权限，如何处理： 将用户tom下的同名schema权限赋给jerry 1 GRANT USAGE ON SCHEMA tom TO jerry; 将用户tom已经创建的表的select权限赋给jerry 1 GRANT SELECT ON ALL TABLES IN SCHEMA tom TO jerry; 将用户tom未来在同名schema下创建的表的select权限赋给jerry 1 ALTER DEFAULT PRIVILEGES FOR USER tom IN SCHEMA tom GRANT SELECT ON TABLES TO jerry;

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

处理方法 审视用户自定义函数的provolatile属性是否定义正确。如果定义不正确，要修改对应的属性，使它能够下推执行。 具体判断方法可以参考如下说明： 函数相关的所有属性都在pg_proc系统表中可以查到，与函数能否下推相关的两个属性是provolatile和 proshippable： 如果函数的provolatile属性为i，则无论proshippable的值是否为t，则函数始终可以下推。 如果函数的provolatile属性为s或v，则仅当proshippable的值为t时，函数可以下推。 provolatile的本质含义是描述函数的易变属性，取值为i/s/v，i代表IMMUTABLE，s代表STABLE，v代表VOLATILE。 举例如下： 如果一个函数对于同样的输入，一定有相同的输出，那么这类函数就是IMMUTABLE的，例如绝大部分的字符串处理函数，这类函数始终可以下推。 如果一个函数的返回结果在一个SQL语句的调用过程中，结果是相同的，那么它就是STABLE的。例如时间相关的处理函数，它的最终显示结果可能与具体的GUC参数相关（例如控制时间显示格式的参数），这类函数都是STABLE的，此类函数仅当其属性是SHIPPABLE的时候，才能下推。 如果一个函数的返回结果可能随着每一次的调用而返回不同的结果。例如nextval，random这种函数，每次调用结果都是不可预期的，这类函数就是VOLATILE的，此类函数仅当其属性是SHIPPABLE的时候，才能下推。 proshippable字段表示函数是否可以下推到DN上执行，默认值是false，取值范围为t/f/NULL。

处理方法 方法一：更改某个GaussDB(DWS) 集群的数据库默认时区。 登录GaussDB(DWS) 管理控制台。 在左侧导航栏中，单击“集群管理”。 在集群列表中找到所需要的集群，单击集群名称，进入集群“基本信息”页面。 单击“参数修改”页签，修改参数“timezone”，修改为您所在的时区，然后单击“保存”。 在“修改预览”窗口，确认修改无误后，单击“保存”。 用户可根据界面中参数“timezone”所在行的“是否重启”列，判断修改参数后无需进行重启操作。 修改“timezone”参数后无需重启集群操作 ，则修改后立即生效。 方法二：通过后台命令查询和更改数据库时区。 查询客户端时区和当前时间。其中客户端时区为UTC时区，now()函数返回当前时间。 1 2 3 4 5 6 7 8 9 10 11 show time zone; TimeZone ---------- UTC (1 row) select now(); now ------------------------------- 2022-05-16 06:05:58.711454+00 (1 row) 创建数据表，其中timestamp，timestamptz是常用的时间类型。timestamp不保存时区，timestamptz保存时区。 1 2 3 4 5 6 7 8 9 CREATE TABLE timezone_test (id int, t1 timestamp, t2 timestamptz) DISTRIBUTE BY HASH (id); \d timezone_test Table "public.timezone_test" Column | Type | Modifiers --------+-----------------------------+----------- id | integer | t1 | timestamp without time zone | t2 | timestamp with time zone | 向timezone_test表插入当前时间并查询当前表。 1 2 3 4 5 6 7 8 9 10 11 insert into timezone_test values (1, now(), now() ); show time zone; TimeZone ---------- UTC (1 row) select * from timezone_test; id | t1 | t2 ----+----------------------------+------------------------------- 1 | 2022-05-16 06:10:04.564599 | 2022-05-16 06:10:04.564599+00 (1 row) t1（timestamp类型）在保存数据时丢弃了时区信息，t2（timestamptz类型）保存了时区信息。 把客户端时区设置为东8区（UTC-8），再次查询timezone_test表。 1 2 3 4 5 6 7 8 9 10 11 set time zone 'UTC-8'; show time zone; TimeZone ---------- UTC-8 (1 row) select now(); now ------------------------------- 2022-05-16 14:13:43.175416+08 (1 row) 继续插入当前时间到timezone_test表，并查询。此时t1新插入的值是用的东8区时间，t2根据客户端时区对查询结果进行转换。 1 2 3 4 5 6 7 insert into timezone_test values (2, now(), now() ); select * from timezone_test; id | t1 | t2 ----+----------------------------+------------------------------- 1 | 2022-05-16 06:10:04.564599 | 2022-05-16 14:10:04.564599+08 2 | 2022-05-16 14:15:03.715265 | 2022-05-16 14:15:03.715265+08 (2 rows) timestamp类型只受数据在插入时的时区影响，查询结果不受客户端时区影响。 timestamptz类型在数据插入时记录了时区信息，查询时会根据客户端时区做转换，以客户端时区显示数据。

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

问题现象 执行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.

原因分析 当一条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语句执行结果的随机性，而这个实际业务中是无法接受的。

问题现象 查看日志提示： [ERROR] Mpp task queryDataAnalyseById or updateDataAnalyseHistoryEndTimesAndResult fail, dataAnalyseId:17615 org.postgresql.util.PSQLException: ERROR: memory is temporarily unavailable sql：vacuum full dws_customer_360.t_user_resource;

处理方法 通过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)

问题现象 向表中插入数据报错：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.

处理方法 方法一：检查数据冲突，修改插入数据。例如，修改示例重复字段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

原因分析 数据文件是从Oracle导入的，文件编码为utf-8。该报错还会提示行数，由于文件特别大，vim命令打不开文件，于是用sed命令把报错行数提出来，再用vim命令打开，发现并没有什么异常。用split命令按行数切割后，部分文件也可以导入。 经分析GaussDB(DWS)的varchar型的字段或变量不允许含有'\0'（也即数值0x00、UTF编码'\u0000'）的字符串 ，需在导入前去掉字符串中的'\0'。

问题现象 某表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，打印执行计划，耗时主要在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'); 联系运维人员登录集群实例，检查内存相关参数，设置不合理，需要优化。 单节点总内存大小为256G max_process_memory为12G，设置过小 shared_buffers为32M，设置过小 work_mem：CN：64M 、DN：64M 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" 进一步分析扫描慢的原因，发现表数据膨胀严重，对其中一张8G大小的表，总数据量5万条，做完vacuum full后大小减小为5.6M。

处理方法 请使用具有schema权限的用户登录数据库，执行以下命令将schema中的表权限赋给指定的用户： 1 2 GRANT USAGE ON SCHEMA schema_name TO u1; GRANT SELECT ON ALL TABLES IN SCHEMA schema_name TO u1; 执行以下命令，将schema中未来新建的表的权限也赋予指定的用户： 1 ALTER DEFAULT PRIVILEGES IN SCHEMA schema_name GRANT SELECT ON TABLES TO u1; 上述SQL语句中的“GRANT SELECT”表示赋予的是表的查询权限，如果需要给其他用户赋予表的其他权限，请参考GRANT语法说明。 如果需要给某个用户赋权“可查询数据库所有schema里所有表”，可通过系统表PG_NAMESPACE查询出schema后授权。例如： 1 SELECT 'grant select on all tables in '|| nspname || 'to u1' FROM pg_namespace;

问题现象 连接GaussDB(DWS) 数据库时报错，提示客户端连接数太多。 使用gsql等SQL客户端工具连接数据库时，出现如下所示的报错信息： 1 FATAL: Already too many clients, active/non-active/reserved: 5/508/3. 使用客户端并发连接数据库时，出现如下所示的报错信息： 1 2 [2019/12/25 08:30:35] [ERROR] ERROR: pooler: failed to create connections in parallel mode for thread 140530192938752, Error Message: FATAL: dn_6001_6002: Too many clients already, active/non-active: 468/63. FATAL: dn_6001_6002: Too many clients already, active/non-active: 468/63.

处理方法 可优先通过如下方法进行应急处理： 临时将所有non-active的连接释放掉。 1 SELECT PG_TERMINATE_BACKEND(pid) from pg_stat_activity WHERE state='idle'; 在GaussDB(DWS) 控制台设置会话闲置超时时长session_timeout，在闲置会话超过所设定的时间后服务端将主动关闭连接。 session_timeout默认值为600秒，设置为0表示关闭超时限制，一般不建议设置为0。 session_timeout设置方法如下： 登录GaussDB(DWS) 管理控制台。 在左侧导航栏中，单击“集群管理”。 在集群列表中找到所需要的集群，单击集群名称，进入集群“基本信息”页面。 单击“参数修改”页签，修改参数“session_timeout”，然后单击“保存”。 在“修改预览”窗口，确认修改无误后，单击“保存”。 如果上述方式未能满足业务需求，可继续参考以下方式进行处理： 当前数据库连接已经超过了最大连接数场景处理方式： 查看CN上的连接来自哪里，总数量以及是否超过当前max_connections（默认值CN节点为800，DN节点为5000）。 1 SELECT coorname, client_addr, count(1) FROM pgxc_stat_activity group by coorname, client_addr order by coorname; 判断是否可以调大max_connections。调整策略如下： 调大CN的max_connections会造成并发连接到DN的查询变多，所以需要同步调大DN的max_connections和comm_max_stream。 CN/DN的max_connections一般按照原来的2倍调大，原值比较小的集群可以调节到4倍。 为避免在准备步骤失败，max_prepared_transactions的值不能小于max_connections，建议至少将其设置为等于max_connections，这样每个会话都可以有一个等待中的预备事务。 若上一步中判断可以调整max_connections，则可通过管理控制台调整最大连接数max_connections。 在管理控制台上，集群“基本信息”页面，单击“参数修改”页签，修改参数“max_connections”为合适的值，然后单击“保存”。 针对设置了用户最大连接数的场景处理方式： 在创建用户时由CREATE ROLE命令的CONNECTION LIMIT connlimit子句直接设定，也可以在设定以后用ALTER ROLE的CONNECTION LIMIT connlimit子句修改。 使用PG_ROLES视图查看指定用户的最大连接数。 1 2 3 4 5 SELECT ROLNAME,ROLCONNLIMIT FROM PG_ROLES WHERE ROLNAME='role1'; rolname | rolconnlimit ---------+-------------- role1 | 10 (1 row) 修改用户的最大连接数。 1 ALTER ROLE role1 connection limit 20;

磁盘空间告警订阅 为了减轻客户自行的运维压力，DWS提供了告警订阅的功能：即当集群的磁盘使用率大于设置的阈值时，系统会以短信、邮件形式通知到用户。 设置告警阈值： 登录DWS控制台，左侧选择“告警管理”，单击“告警规则管理”。 在告警规则列表中，单击“节点数据盘使用率超阈值”右侧的“修改”。 在集群列表中单击指定集群，进入集群详情页面。告警策略设置如下： 规则绑定集群：所有集群 告警策略：将数据盘的重要告警配置为70%，持续10分钟，紧急告警配置为75%，持续10分钟。如下设置： 在 消息通知 服务( SMN )创建主题。 切换到消息通知服务控制台，单击“创建主题”。如下设置“主题名称”和“企业项目”。 主题创建成功后，单击右侧的“添加订阅”。根据需要选择“短信”、“邮件”方式，订阅终端输入对应的手机号或邮箱地址。 输入的手机号或邮箱地址会受到确认短信或邮件，单击确认，即可完成订阅。 添加告警订阅。 回到DWS控制台，左侧选择“告警管理”，切换到“订阅”，单击“创建订阅”。 订阅名称输入“dms_alarm”，告警级别选择“紧急”、“重要”，消息通知主题名称选择上一步创建的主题“dms_alarm”。 单击“确认”。整个告警订阅成功，后续磁盘使用率大于70%和75%则发出通知。

单语句空间管控 GaussDB(DWS)支持语句磁盘空间管控相关的参数sql_use_spacelimit和temp_file_limit，用于业务运行时，避免由于不合理的数据量，引发磁盘空间暴增，触发告警/只读，主动识别不合理的大批量倒数业务或者高数据量入库业务。 登录DWS控制台，左侧单击“集群管理”，在集群列表中单击指定集群，进入集群详情页面。 单击“参数修改”，搜索栏中搜索sql_use_spacelimit和temp_file_limit（参见磁盘空间），根据业务进行调整。 建议设置sql_use_spacelimit为实例所在磁盘空间总容量的10%（例如购买时空间为100G/每节点，则配置该参数为10G）。 上述配置生效后，如果单语句运行过程中超过该配置参数，则SQL语句会被主动中止。如需临时放开，可以在session会话中执行以下语句进行临时关闭。 1 SET sql_use_spacelimit=0;

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