问题现象1.用户查询自己的视图，显示对表无权限 2.管理员查询视图显示对表无权限问题原因视图定义所属schema所有者，没有权限查询视图定义涉及到的表。排查过程创建测试用户1 postgres=# create user user1 with password 'password@123'; CREATE USER 创建测试用户2 postgres=# create user user2 with password 'password@123'; CREATE USER 用户1创建表 create table user1.t1(id int,name text); 赋予用户2访问的权限 grant usage on schema user1 to user2; grant select on table user1.t1 to use2; 用户2创建视图 create view v1 as select * from user1.t1; 此时user2查询视图是正常的 select * from v1; 当user1重新创建t1表后或者撤销user2对表的权限， 使用管理员查user2的视图会报错 postgres=# select * from user2.v1; ERROR: SELECT permission denied to user "user2" for relation "user1.t1"解决方法重新把表的查询权限给用户user2 grant select on table user1.t1 to user2;

问题背景1.业务账号被锁无法登陆（直连CN） 2.业务账号被锁后出现未解锁也可以登录（通过负载均衡连接CN）问题原因1.业务密码错误导致账号被锁 2.DWS高并发模式下提供多个CN，每个节点都具备帐户锁定机制，但各个节点的帐户锁定信息并不共享，每个节点帐户锁定是独立裁定的，即业务通过负载均衡连接的时候转发到未锁定用户的CN可以登录，转发到锁定用户的CN就会报用户被锁。排查过程查看审计日志，看失败的是不是固定在部分CN，如果是就是部分CN被锁,其他CN可以正常登录 select begintime,endtime,result,node_name,username,client_conninfo,detail_info from pgxc_query_audit('2023-02-01','2023-02-03') where audit_type ='user_login' and username='被锁用户名' order by result;解决方法1.进行用户解锁，解锁是全局性的alter user username account unlock; 2.修改密码错误客户端密码，防止再次被锁。

此贴持续更新DWS 线下ESL版本升级路径：若当前版本为C80SPC3xx/5xx/7xx/8xx：C80-->8.0.0.2-->8.1.1.6-->8.1.3.6若当前版本为C80SPC300以前的版本，须升级至C80SPC300后再升级：C80-->C80SPC300-->8.0.0.2-->8.1.1.6-->8.1.3.6若当前版本为6.5.1.x：6.5.1-->8.0.0.2-->8.1.1.6-->8.1.3.6若当前版本为8.0.0.x：8.0.0-->8.1.1.6-->8.1.3.6若当前版本为8.1.0:8.1.0-->8.1.1.6-->8.1.3.68.0.0版本最新通用补丁为8.0.0.15补丁集群版本查询：/opt/huawei/Bigdata/om-server/om/sbin/pack/queryPack.sh (omm用户主管理节点执行)在线升级特性：源版本不低于811且目标版本不低于813版本，可在线升级集群升级与OS无关(能安装就能升级)：只要集群可以正常安装使用，那么不管此OS后续是否在高版本的兼容列表，此集群都可以正常进行版本升级在线扩容：仅指数据重分布阶段，添加节点实例仍需业务离线，811及以上版本可以在线扩容目前推荐升级至8.1.3版本：修复oid回卷问题（参考预警通知）新增在线升级、在线修复cn功能，进一步降低变更对业务影响优化autovacuum及autoanalyze，特性可用加固备份容灾，修复老版本切换不稳定易失败、备份容易导致磁盘满等问题增强熔断措施，避免语句下盘导致磁盘写满等对比8.0.0版本，优化列存小文件，列存升级至2.0版本升级方案获取：升级到8.0.0：https://support.huawei.com/enterprise/zh/cloud-computing/gaussdb-a-pid-250949677?category=installation-upgrade&subcategory=upgrade-guide8.0.0补丁：https://support.huawei.com/enterprise/zh/cloud-computing/gaussdb-a-pid-250949677?category=installation-upgrade&subcategory=patch-installation-guide升级到8.1.1.6或8.1.3.5：https://support.huawei.com/enterprise/zh/cloud-computing/hcs-dws-service-pid-251527524?category=installation-upgrade&subcategory=upgrade-guide

问题现象：裸机节点重启后服务自启设置不合理，network和NetworkManage服务冲突，到traffic ip没有绑定上问题根因：本集群为集中式组网BMS集群。vlan配置文件中默认配置了NM_CONTROLLER=no。默认不采用NetworkManager管理网络。当前节点network服务为disable状态，即开机不自启，导致实例重启后network服务为inactive状态，trafficIp未挂载。影响范围：8.1.3版本以前的HCS场景、ARM BMS集群。（euleros2.8版本）*8.1.3版本适配欧拉2.10版本重新制作镜像，已解决上述问题。*针对上述问题，对历史版本镜像排查，发现8.1.3版本以前的HCS场景、ARM BMS基础镜像中network服务为disable状态，对集中式组网场景有影响。问题规避：针对采用8.1.3版本前的BMS镜像,BMS集中式集群现网需要进行上下电操作，或因实例重启后出现实例ip地址丢失场景。1、执行上下电操作前需要执行systemctl status network 查看network服务是否启动，若为inactive服务，执行systemctl restart network 和systemctl enable netwrok。2、若重启实例后出现掉网卡场景，执行ifup bond0.xx查看是否可正常加载ip3、若步骤2操作无法正常拉起网卡，执行systemctl restart network，重启network服务。4.enable network服务，保证重启实例后network正常启动

问题现象gaussdb对接hdfs时参数校验阶段报错； controller日志报错Some config items value are invalid问题版本此问题为8.1.1.1版本出现，已在8.1.1.2修复问题分析1、查看controller日志报错Some config items value are invalid；2、查看manager版本和集群版本；3、查看oms节点/opt/huawei/Bigdata/components/current/MPPDB/configurations.xml文件dfs.namenode.kerberos.keytab参数配置，发现配置不对；解决方法1、主备oms节点修改/opt/huawei/Bigdata/components/current/MPPDB/configurations.xml文件dfs.namenode.kerberos.keytab参数配置，将1531行-2213行的scope的值setup修改为all2、修改完之后重启controller，主备oms节点都执行

【问题现象】       由于当前版本是8.1.3.300的问题，库与库之间是串行的，所以为了加快速度，可以手动多库并行分布【解决方法】0.创建不带索引的临时表 create table tmp_table like old_table(including all excluding indexes);1.导数据 已完成  外部sql并发导入分区数据2.建索引   按索引并发创建索引3.验业务 已完成4.换表改表名DROP VIEW IF EXISTS ftuser.v_ft_result3;alter table ftuser.ft_result3 rename to ftuser.ft_result3_bak_0814;alter table ftuser.ft_result3_tmp20220813 rename to ftuser.ft_result3;alter table ftuser.ft_result3_std rename to ftuser.ft_result3_std_bak_0814;alter table ftuser.ft_result3_std_tmp20220813_2 rename to ftuser.ft_result3_std;5.重建依赖视图gsql postgresql://:8000/txphw?application_name='OM' -ar -f ft_result3.sql6.客户验证业务7.完成重分步流程  1)表在重分步中无法删除，需要设置：alter tabel xxx set  (append_mode=off)  2)drop table xxx;  3)拉起重分步流程nohup gs_expand -t redistribute --redis-mode=insert --dws-mode --parallel-jobs=4 --fast-redis& 查看后台日志保证重分步完成  4）修改管控面状态delete from rds_action where objid={clusterid};nohup gs_expand -t redistribute --redis-mode=insert --dws-mode --parallel-jobs=4 --fast-redis&

问题现象：执行 grant select on all tables in schema ...to ...                 报错ERROR:NOT-SUPPORT:Not support Grant/Revoke privileges to objects in different nodegroup问题版本：8.1.3.100规避措施：改成单个表赋权规避grant select on rtd_po_header_t to jdbc_dws_sbi_ptp

问题现象：1.界面缩容失败2.确定后台是因为锁等待超时导致失败问题版本：《=8.1.3.100分析过程：1.查看缩容日志  cd $GAUSSLOG/om/gs_shrinkxx.log日志2.查看cn-1-1上的gs_redis日志,见在缩容开始1小时左右锁等待超时cd $GAUSSLOG/bin/gs_redis/gs_redisxxxxx.log规避措施：界面重试1.修改cn-1-1上的缩容步骤bat文件,需要修改post_redis为redisvi $PGHOST/shrinkimplphsicalcluster_step/shrinkimplphysicalcluster_step.dat2.客户从界面重入，重新点击缩容重入

问题现象： 缩容在界面提交后，右上角提示：“权限不足，请联系技术支持人员（主账号或者具有Security Administrator权限的账号）在当前页面完成对DWS的委托授权”问题版本：内核：8.1.3.100 管控面版本：规避措施：1.联系HC客户权限管理人员给对应用户的用户配配置Security Administrator的用户组2.检查用户权限:统一身份认证--》用户组--》对应赋予权限的用户组--》点击进入查看是否有“Security Administrator”3.确定已经有对应的权限后，再次在界面进行提交

【问题现象】用户正常使用的视图，在查询时报视图不存在。在审计日志中，只能查到视图创建行为，无法查到视图删除行为。【排查方法】1. 检查审计开关是否打开audit_enabled2. 检查DDL审计是否打开audit_operation_exec3. 检查视图的审计是否打开audit_system_object，其中二进制的第五位控制视图审计。现场以上功能都正常开启，新建视图再删除，都能被正常审计到。说明视图审计功能被正常打开。4. 检查视图定义，是否有级联删除行为。通过检查视图定义中依赖的对象（视图，表），在审计日志中发现依赖表存在频繁的级联删除行为。【问题根因】级联删除时，上层依赖对象会被删除，且无法记录到审计日志中。【场景分析】1. 用户创建视图依赖的基表1，属于部门A。2. 部门B使用基表1创建视图。3. 部门A经常删除重建基表1，使用级联删除导致部门B的视图也被一起删除。【解决办法】方法一：表重建，改成truncate。避免依赖对象被级联删除。方法二：使用“视图解耦”功能，参数：view_independent。基本原理：开启视图解耦，在删除依赖基表时，视图本身定义并不被删除，处于无法使用状态。待基表被重建，第一次使用视图时，视图会被自动重建。

 【报错现象】 8361897755 cn_5005 0A000 383087462031697455 [BACKEND] ERROR:  The relation "dw_mongo_km_specimen_log_orc_w" has no distribute type. 8361897755 cn_5005 0A000 383087462031697455 [BACKEND] STATEMENT:  grant select on all tables in schema mongodb to dataprodmanager  【最小用例】  create user u1 password 'Test_123'; CREATE SERVER hdfs_server FOREIGN DATA WRAPPER HDFS_FDW OPTIONS (type 'hdfs', address 'nohostname:noport',hdfscfgpath 'noconfigpath');         CREATE  FOREIGN TABLE dw_mongo_km_specimen_log_orc_w (           id character varying(200),                               class character varying(200),                            businessdomain character varying(200),                   businessmodulename character varying(300),               businessmodulecode character varying(200),               operationdepartmentcode character varying(200),          operationdepartmentname character varying(300),          operatorname character varying(300),                     operationtime timestamp without time zone,               operationobjecttype character varying(300),              operationobjectvalue text,                               operationcontent text,                                   operationremark character varying(5000)          )                                    SERVER hdfs_server                                        OPTIONS (                                                    encoding 'utf8',                                         foldername '/dws-data-table/dws_test_write_1y/',         format 'orc'                                         ) WRITE ONLY  DISTRIBUTE BY HASH(id); grant select on dw_mongo_km_specimen_log_orc_w to u1; 【问题根因】 write only类型外表创建时，不支持指定分布键。 但grant select 时获取分布键报错。 read only 必须指定分布键 ，所以可以grantwrite only 不要求指定分布键（将数据导出到一个文件） 【解决办法】通过拼写SQL过滤掉write only类型外表，单表进行grant授权。 

【报错现象】​报错语句：COPY dbadmin.xxx ( "mid","name","dws_updated_time" ) FROM STDIN WITH(FORMAT 'csv', DELIMITER ',', QUOTE '"', NULL 'null', ESCAPE '"', ENCODING 'UTF-8', COMPATIBLE_ILLEGAL_CHARS 'true')【问题背景】建表时没有合适的列作为分布列，为了防止数据倾斜，增加了一个sequence列作为分布列使用。【问题根因】1. 用户工具拼写COPY时对为指定的列，自动拼了NULL值进来。2. sequence列默认会有个NOT NULL约束。3. 只有当不指定值时才使用sequence的next_val获取序列值，如果指定了则直接用指定值。【解决办法】办法一：使用roundrobin分布方式，避免数据倾斜。办法二：多列组合作为分布列，避免数据倾斜。办法三：COPY时指定目标列，例如：copy t1(name) from stdin with delimiter ',';【相关问题】GaussDB(DWS)数据库设置主键后还需要设置分布键吗？仅设置主键即可，默认会选择主键的第一列作为分布键。如果两个同时设置，主键必须包含分布键。

【问题现象】COPY语句执行超时报错【内核版本】gaussdb (GaussDB 8.1.3 build 29305bc6) compiled at 2022-06-13 20:23:25 commit 3629 last mr 5138 release【问题日志】根据客户端的报错SQL在数据库后台日志中找到报错日志2023-01-18 14:13:40.576 database 139985690793728 0 cn_5003 217017229741661605 [BACKEND] LOG: copy from is in the INITIALIZING state. 2023-01-18 14:13:40.576 database 139985690793728 0 cn_5003 217017229741661605 [BACKEND] STATEMENT: COPY XXX 2023-01-18 14:13:40.579 database 139985690793728 0 cn_5003 217017229741661605 [BACKEND] LOG: [DYWLM]register dynamic info into dynamic_info_hashtbl, qid:[3, 3113970, 727366420575123], memory size:[118] 2023-01-18 14:13:40.579 database 139985690793728 0 cn_5003 217017229741661605 [BACKEND] STATEMENT: COPY XXX 2023-01-18 14:17:58.371 postgres 140089390778112 0 cn_5003 0 [BACKEND] LOG: PgstatCollectThreadStatus, node_name<cn_5003>, database_id<18609>, app_name<PostgreSQL JDBC Driver>, query_id<217017229741661605>, tid<139985690793728>, lw_tid<3113970>, parent_tid<0>, thread_level<0>, wait_status<wait ccn queue> 2023-01-18 14:21:00.566 database 139985690793728 0 cn_5003 217017229741661605 [BACKEND] LOG: copy from is transforming from INITIALIZING to TRANSFER_DATA state. 2023-01-18 14:21:00.566 database 139985690793728 0 cn_5003 217017229741661605 [BACKEND] STATEMENT: COPY XXX 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] LOG: could not receive data from client,remote nodename (null), detail:Connection reset by peer 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] CONTEXT: COPY cdm_zd_station_charge_power_info, line 901 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] STATEMENT: COPY XXX 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] LOG: incomplete message from client 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] CONTEXT: COPY cdm_zd_station_charge_power_info, line 901 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] STATEMENT: COPY XXX 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] LOG: An error in CopyFrom cannot be catched. 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] CONTEXT: COPY cdm_zd_station_charge_power_info, line 901 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] STATEMENT: COPY XXX 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] ERROR: unexpected EOF on client connection with an open transaction 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] CONTEXT: COPY cdm_zd_station_charge_power_info, line 901 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] LOCATION: CopyGetDataDefault, copy.cpp:338 2023-01-18 14:21:00.583 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] STATEMENT: COPY XXX 2023-01-18 14:21:00.584 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] LOG: could not send data to client [XXX]. detail:Broken pipe 2023-01-18 14:21:00.584 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] STATEMENT: COPY XXX 2023-01-18 14:21:00.584 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] LOG: [DYWLM]unregister dynamic info from dynamic_info_hashtbl, qid:[3, 3113970, 727366420575123], memory size:[118] 2023-01-18 14:21:00.584 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] STATEMENT: COPY XXX 2023-01-18 14:21:00.724 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] LOG: Failed to ABORT an implicitly PREPARED transaction status - RXACT_ABORT_FAILED:ABORT failed on all the nodes. 2023-01-18 14:21:00.724 database 139985690793728 5435493606 cn_5003 217017229741661605 [BACKEND] STATEMENT: COPY XXX 2023-01-18 14:21:00.726 database 139985690793728 0 cn_5003 0 [BACKEND] FATAL: connection to client lost主要逻辑14:13:40.576 copy from is in the INITIALIZING state 发起COPY语句14:17:58.371 后台PgstatCollect线程，显示139985690793728线程在'wait ccn queue'14:21:00.583 Connection reset by peer链接异常断开【业务侧逻辑】使用JDBC向数据库建链时，设置socket_timeout为5分钟。该COPY语句每小时会调起一次，正常时间段很快执行完。【问题分析】14:13:40到14:21:00语句端到端执行时间超过5分钟，连接因socket_timeout被JDBC断开。语句执行时间长是因为wait ccn queue在CCN等待排队因COPY语句最终没有执行完，没有被写入TOPSQLregister dynamic info into dynamic_info_hashtbl, qid:[3, 3113970, 727366420575123], memory size:[118]显示COPY语句本身只使用的118MB的内存CCN分快车道（估算内存>=32MB）和慢车道(估算内存<32MB)，COPY估算了118MB的内存，所以在慢车道里面排队，被其它人堵塞了。【慢车道分析】通过日志分析，COPY语句因在慢车道等待而超时，并未真正执行。 那当前为什么会在慢车道等待，我们看一下当前慢车道正在执行的SQL。postgres=# select start_time, finish_time, block_time, estimate_memory, max_peak_memory, substr(query,1,100) from pgxc_wlm_session_info where start_time >= '2023-01-18 22:00:00' and finish_time <= '2023-01-18 22:30:00' order by estimate_memory desc; start_time | finish_time | block_time | estimate_memory | max_peak_memory | substr -------------------------------+-------------------------------+------------+-----------------+-----------------+---------------------------------------------------------------- 2023-01-18 22:12:29.058331+08 | 2023-01-18 22:21:00.561384+08 | 6 | 19586 | 0 | --V0117\r + | | | | | with all_data as (\r + | | | | | select\r + | | | | | a.*,\r + | | | | | b.f_coupon_month,\r + | | | | | c.buy_time + 2023-01-18 22:04:51.585044+08 | 2023-01-18 22:09:24.23059+08 | 2 | 11165 | 0 | --V0117\r + | | | | | with all_data as (\r + | | | | | select\r + | | | | | a.*,\r + | | | | | b.f_coupon_month,\r + | | | | | c.buy_time 2023-01-18 22:21:00.569054+08 | 2023-01-18 22:23:13.520451+08 | 342461 | 128 | 28 | + | | | | | + | | | | | + | | | | | -- insert into zd_data.realtime_zd_station_spell_sell_info + | | | | | -- select + | | | | | -- if(DATE_FORMAT('2023-01 2023-01-18 22:05:19.461907+08 | 2023-01-18 22:09:38.63216+08 | 0 | 128 | 20 | + | | | | | + | | | | | insert into zd_data.realtime_zd_station_spell_sell_info_minute+ | | | | | select + | | | | | if(DATE_FORMAT('2023-01- 2023-01-18 22:24:46.341123+08 | 2023-01-18 22:27:48.66484+08 | 0 | 128 | 20 | + | | | | | + | | | | | insert into zd_data.realtime_zd_station_spell_sell_info_minute+ | | | | | select + | | | | | if(DATE_FORMAT('2023-01- 2023-01-18 22:10:06.422463+08 | 2023-01-18 22:13:57.675585+08 | 0 | 128 | 28 | + | | | | | + | | | | | + | | | | | -- insert into zd_data.realtime_zd_station_spell_sell_info + | | | | | -- select + | | | | | -- if(DATE_FORMAT('2023-01 2023-01-18 22:10:35.884899+08 | 2023-01-18 22:14:49.838399+08 | 0 | 128 | 16 | + | | | | | + | | | | | insert into zd_data.realtime_zd_station_spell_sell_info_minute+ | | | | | select + | | | | | if(DATE_FORMAT('2023-01- 2023-01-18 22:21:00.568848+08 | 2023-01-18 22:24:22.541598+08 | 342435 | 128 | 20 | + | | | | | + | | | | | insert into zd_data.realtime_zd_station_spell_sell_info_minute+ | | | | | select + | | | | | if(DATE_FORMAT('2023-01- 2023-01-18 22:21:00.567348+08 | 2023-01-18 22:21:01.778612+08 | 354437 | 128 | 28 | SELECT + | | | | | group_concat(f_czb_operator_id), + | | | | | COALESCE(array_length(regexp_split_to_array(group_concat(f_c 2023-01-18 22:05:12.738084+08 | 2023-01-18 22:09:28.064253+08 | 0 | 128 | 28 | + | | | | | + | | | | | + | | | | | -- insert into zd_data.realtime_zd_station_spell_sell_info + | | | | | -- select + | | | | | -- if(DATE_FORMAT('2023-01 (10 rows)当时有两个with all_data语句在执行，因内存估算超过32MB，都在慢车道里。执行时间覆盖了COPY语句的端到端时间。 所以，就是这两个语句执行时间长，导致COPY超时。【处理办法】1.需要客户优化近期新增复杂sql 2.资源池配置memory_limit参数，限制sql估算内存，避免单sql使用过多内存导致排队

DWS管控面之DMS-AGENT内存溢出 【问题现象】DMS-AGENT内存溢出 【常见版本】8.1.0以下版本,后续版本进行了优化改进 【定位思路】DMS-AGENT内存未做限制 1、console界面会出现集群“低性能” 2、查询集群状态，确定发生异常节点 3、登录节点，直接查询内存信息，找到dms-agent进程PID 4、规避措施与用户协商先停止此节点dms-agent

问题现象：日志未正常压缩回收日志盘打满问题原因：线下集群日志压缩和回收由FIM负责，若存在日志不压缩回收执行一下命令查看日志压缩回收进程是否存在1.执行命令，预期结果打印所有节点log.manager的进程号gs_ssh -c "ps -ef | grep log.manager | grep -v grep | awk '{print \$2}'"2.存在无log.manager进程的节点3.sh /opt/huawei/Bigdata/FusionInsight_MPPDB_XXXX/install/FusionInsight-MPPDB-XXXX/sbin/logManagerRun.sh start手动拉起后查看日志是否正常压缩回收