新集群建立时，如果外表访问不通1先到数据库里面\des查看对应server，\des+ server_name,主要看地址里面的配置文件是否在节点的对应位置，如果没有，跟MRS侧确认，或者去其他集群scp一下2如果提示鉴权文件错误，如2.1步骤检查文件里面的server对应地址的文件，到对应MRS集群取到文件scp进来3如果还是不通，检查路由是否已经配置4如果还是不通，建议确认外表是否对应这个server5如果速度过慢，写入hosts到沙箱里的文件中/etc/hosts6如果速度仍旧无法提升，首先，先找到一套老的集群，先测试老集群的性能，在按老集群的/etc/hosts等比例复制到新集群的/etc/hosts，注意沙箱外与内都要添加。（一般沙箱内添加完毕速度就能上来）7如果速度依旧慢，考虑下这个链接https://bbs.huaweicloud.com/forum/thread-0265128586108666192-1-1.html修改/etc/resolv.conf文件，添加配置项options timeout:1 attempts:1 rotate；该配置项作用为域名解析超时为1秒，重试次数1次解释下5，6，7的现象及原因现象：DWS查询外表普遍慢，且打印执行计划均慢在外表扫描，打印堆栈分析，观察堆栈是否卡在res_nsearch && res_context_search，可参照如下方式，解决外表查询慢的问题原因：跨集群访问HDFS外表时，需要进行域名解析，目前现象为域名解析服务器没有找到对应的映射关系导致性能劣化8配置文件未更新外表查询慢，可能是配置文件未刷新，载入了旧的配置文件，只需要ALTER SERVER server_name REFRESH OPTIONS;就可解释一下：该配置刷新的是，是二进制文件，在实例目录下9常见错误分析9.1文件在对端hive无法找到对应文件，报错如下改报错可能是对端的问题，更大的问题是hosts文件未配置正确，再次检查老集群的配置，以老集群的配置在配置一次，本次问题解决需要添加后面两个域名映射，原因未知1.1.1.1 hadoop.hadoop.com hadoop.hadoop.com.2.2.2.2 hadoop.hadoop.com3.3.3.3 hadoop.hadoop.com.

前期需要做升级巡检，可参考该网址cid:link_00、沙箱内/opt/dws/opstools/Check执行以下命令，生成巡检报告./gs_check -e upgrade1、前期传安装包的步骤这里省略，可参考2、查询节点网卡是否含eth0,要确保没有ifconfig | grep eth03、检测网络连通性待填写4、进入容器中的rms库，查询此时集群的ak和sk，值为密文5、将ak、sk密文转换为明文，进入容器的opsTool目录java -jar SccTool.jar回车按 3 空格 密文记录下明文6、运行对这个命令有疑惑可参考7、补充，udstool.jar文件交行的文件地址在hcds的fusionclouddeploy用户家目录下

1、存储过程示例create or replace procedure test_process(a in integer)as begin raise notice '1'; while a<700 loop end loop; raise notice '2'; return;end;/在1和2中间是一个死循环，预期只打印1并且进入死循环2、函数示例create or replace function test_function(a int)returns varcharas$$begin DBMS_OUTPUT.PUT_LINE('1'); while a<700 loop end loop; DBMS_OUTPUT.PUT_LINE('2');return 'end';end;$$LANGUAGE plpgsql;预期只打印1并进入循环

一、问题现象业务使用JDBC做查询时报错Invalid character data was found. This is most likely caused by stored data containing characters that are invalid for the character set the database was created in. The most common example of this is storing 8bit data in a SQL_ASCII database.二、问题排查报错分析，出现了JDBC无法识别的字符，基础知识JDBC返回使用UTF-8解码客户实际JDBCselect table_name from information_schema.tables where table_schema='xxx' and table_type !='VIEW';三、问题原因系统表存储了特殊字符，因客户创建表使用了中文，且DWS表名不能超63字符，多汉字出现了截取导致的JDBC返回的字符无法识别；咨询客户后，发现客户之前程序处理时写错了表名字段导致；四、解决方案truncate table "xxxx";规范使用表名；

一、技能使用场景GaussDB(DWS)数仓集群从诞生就具备高可用能力，但现网环境不可避免的会遇到类似故障场景，如：服务器单台节点故障、RAID控制板卡损坏、RAID组磁盘异常、内存故障等场景，此时集群依旧持续为客户提供业务能力，故障也需要及时处理来防止二次故障以造成不可逆的影响，待硬件修复后，DWS集群也需要做实例(instacen)或者节点(node)级别数据副本的恢复。本文旨在阐述我们实际运维过程中遇到的运维修复操作的区别。高可用参考博文：https://bbs.huaweicloud.com/blogs/177361二、合理选择修复方式前提步骤：修复前先停实例或节点2.1 修复方式：cm_ctl build修复的最小和最大单位只能是DN(datanode)，且是单个实例。示例：nohup cm_ctl build -n 节点编号 -D 数据目录 -b full -t 108000000 >> /home/omm/6001.log 2>&1 &注意事项：a、-b参数支持的功能fullcleanup仅在高版本支持，具体可查看cm_ctl --help帮助关于Options for build的描述。b、现网环境都有shell窗口超时，执行切记挂起到后台，参考示例。适用场景：单个DN实例故障适用此场景。2.2、修复方式：gs_replace修复的最小和最大单位是节点(node)，该节点所有异常实例均会被修复，异常实例包含CN(datanode)、DN(datanode)、cm_server、cm_agent、GTM(global transaction manager)。示例：gs_replace -t config -h HostDB-1gs_replace标准方案：【运维变更】【标准变更方案】【纯软】gs_replace修复实例：cid:link_0【运维变更】【标准变更方案】【HC/HCS/HCSO】gs_replace修复实例：https://bbs.huaweicloud.com/forum/thread-150101-1-1.html注意事项：a、该节点的安装初始化需要正常，即二进制文件都是正确的，意味着只能是修复数据实例故障，如果节点安装初始化目录都不正常，这里需要参考云上温备替换或线下重装节点。b、该节点所有非normal状态的实例都会修复，一定切记有其他实例在正常恢复时，谨慎使用该命令，因错误执行IO能力不行会导致恢复时间拉长。c、CN会在config阶段修复正常，因CN只包含元数据。DN会在config阶段拷贝配置和目录，start阶段会完成数据恢复。d、云上需要打开集群内免密登录，不打开会导致修复卡在Ruby密码，实际Ruby密码得去rms库查解密，建议参考标准方案先打开。e、现网环境都有shell窗口超时，执行切记挂起到后台，可参考nohup方式。f、如遇到集群不可用的场景，如备先故障暂时无法修复，急需修复从备保证主从事务强同步，可在config成功完成后，手动拉起从备DN实例紧急恢复业务；适用场景：适用单个节点副本异常，或CN故障。2.3、修复方式：gs_ctl build注意事项：a、只能在本节点执行。适用场景：单个DN实例故障适用此场景。四、其他注意事项4.1 停止方式不同的误区cm_ctl stop -n 节点编号 -D 数据目录该方式停止的，选择2.1方式cm_ctl stop -n 节点编号该方式停止的，选择2.2方式，如选择2.1则会因为cm_ctl需要cm_agent通信发消息给cm_server，但停了节点后，节点上无cm_agent进程会导致无法从cm_server下发修复指令报错退出。注意事项：现网环境在gs_replace修复完成后，同一个节点会有部分实例恢复normal，同一个节点还有部分DN是Down Manually stopped状态，这时需要查看gs_replace的日志$GAUSSLOG/om/目录下，因预先按照4.1停了节点的，gs_replace完成后，“会删除在replace之处生成的标记文件，重启DN交给cm_agent管控”，这个动作在300s内需要完成，但DN实例replace完，从修复时间点到修复完成这期间产生的日志无法在300s内redo完成，会导致300s没有重启DN成功的场景，所以gs_replace完成很可能会遇到这类场景，此时拉起单个DN即可，参考如下示例：cm_ctl start -n 节点编号 -D 数据目录4.2 时间评估修复窗口尽量避开业务高峰期修复时间：扫描文件列表时间+同步文件列表时间+修复期间的数据差异即catchup时间扫描文件列表时间：一般地小文件越多耗时越久，这里不好评估，因CPU能力和不同OS内核遍历算法有差异。同步文件列表时间：可根据环境的磁盘类型评估，一般地业务空闲期，机械盘可达200-300MB/s，固态可达500-600MB/s。修复期间的数据差异即catchup时间：可计算从备目录空间。五、案例集锦1、正在整理补充；

🈚剧本，才真实！1024程序员快闪采访新鲜出炉！！你的互联网嘴替，带你勇闯GaussDB(DWS)程序员老巢~videovideovideovideo

客户端服务器远程-h -f报错ssl connection has been closed unexpectedlycn节点不报错ssl connection has been closed unexpectedly，但是直接connection to server was lost并退出sql文件的执行。gsql进入客户端，\i执行文件，也是一样的报错退出。sql文件每次都执行到2842行（一个分号结束为止）请问这是什么原因？

1024程序员节1、2、3项互动活动已经结束，感谢各位小伙伴的参与！获得本期活动奖励的名单如下，恭喜以下小伙伴~请各位中奖的小伙伴填写问卷反馈收货信息哦^_^  请小伙伴们在2023年11月3日24时前反馈收货信息，逾期礼品作废哦^_^ 礼品邮寄时间：15个工作日内完成邮寄。问卷反馈：链接【获奖名单】获奖类目昵称成绩礼品知识竞赛华峰15GaussDB(DWS)定制鼠标垫匿名用户15匿名用户15一三七14如是我闻，一时14章14LLL14代码画标识炒香菇的呆子/GaussDB(DWS)定制Polo衫yd_226072528/yd_280707402/yd_254620958/yd_232498978/皮牙子抓饭/Hello Digger/开发者故事皮牙子抓饭/GaussDB(DWS)定制咖啡杯------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------2的10次方是10241G = 1024 M1 M = 1024 kb1kb =1024 bit1024是二进制计数的基本计量单位，因此在程序员眼里，1024 是一个整数。程序员(英文Programmer)是从事程序开发、维护的专业人员。程序员就像是一个个1024，以最低调、踏实、核心的功能模块搭建起这个科技世界。在专属你们的节日里，我们为您准备了专属礼品，等您开启。1024程序员节游园会（以下游戏参与1种或以上，每项活动可重复中奖）1、知识竞赛此关卡共15道选择题，每题1分，总成绩前5名将获得GaussDB(DWS)定制鼠标垫。答题链接：Link   2、用代码画出GaussDB(DWS) 标识指尖敲击键盘碰撞出你对GaussDB(DWS)的喜爱，在本帖留言区，留言运行截图，将获得GaussDB(DWS)定制Polo衫。（获奖名额10名，先到先得）    3、分享您与GaussDB(DWS)的故事在本帖评论区分享您与GaussDB(DWS)的故事，我们将根据分享内容评选10名获奖用户。礼品：GaussDB(DWS)定制咖啡杯。（内容形式不限，文字、视频都可以）    4、指定论坛帖提问10月24日—25日在指定论坛帖提问，将有机会获得华为云开发者定制礼品。    5、有奖征文活动即日起—11月30日，参与绽放吧！GaussDB(DWS)云原生数仓有奖征文活动，将获得华为云开发者定制礼品。活动链接：Link礼品发放规则：1、2、3项活动结束后，我们将在5个工作日内公布获奖名单，15个工作日内发放相关礼品。4、5项活动奖品发放规则请参考对应活动链接规则哦~

在进行华为云《体验GaussDB(DWS)云原生数仓-湖仓一体》云实验时，当我想要购买DWS数仓服务，限制云实验内置的账号权限不足 实验网址:cid:link_0

问题思考：数据库中对表数据进行大量delete了，为啥\dt+ 显示表大小未改变？分析过程：首先我们先创建一张测试表，表里面插入了10条数据。 如果我们执行delete删除一条数据后再次查询，可以看到test表还有9条数据 重点操作来了，现在让我们设置下参数后再次查询，可以看到被删除的数据又可以查看到了。（xmin，xmax两列含义下文会讲） 从上面虽然可以看到已删除的数据，但是又出现两列数据xmin，xmax，在此解释下Xmin：数据插入时的事务ID，如批量插入数据，则批量插入的数据xmin值是一样的。Xmax：数据删除时的事务ID，如批量插入数据，则批量插入的数据的xmax值都一样且为0不难看出，被删除的数据对应xmax值为324527035（删除操作时的事务ID）,其他未被删除的数据行对应的xmax为0. 即数据被删除时，被删除数据对应行的xmax从0被改为删除时的事务ID，xmin不变。 执行删除多行时再看下对应xmax的值， 如下操作（首先还原参数设置rollback） delete删除三行数据 设置参数后查询，可以看到删除的三条数据xmax是一致的(删除的三条数据为a的值2,3,4)，即xmax为删除时的事务号。 执行下vacuum后再看下，可以看到执行vacuum后删除的数据就彻底查不到了。 有人可能会问大量的update操作呢？ 来手动update看下(txid_current()函数获取当前事务ID) 设置数据库参数后再次查询，可以看到更新前的数据且xmax值为更新操作时的事务ID，且更新后的数据对应xmax为0，xmin为当时更新操作时的事务ID，可以得出update操作实际为delete和insert的组合操作。 综上：可知表进行大量delete/update操作后，如果未开启autovacuum为避免存在大量脏页占用空间和影响后续查询效率（查询时数据库还是会扫描这些已删除的脏数据），有时还是需要手动进行vacuum full维护的. analyze进行空间释放的。

【问题背景】硬件故障，未按照标准流程下电，直接更换背板插线，导致文件系统损坏。【问题现象】更换背板插线后，再启动OS时报错 Failed to mount /var/chroot/DWS/data2 盘挂载失败，OS启动失败；解决启动后挂载盘报错 Structure needs cleaning【解决方式】1.OS启动时报错，解决方案：挂盘错误导致OS启动失败2.挂载盘报错 Structure needs cleaning ，解决方案：xfs_repair -L /dev/xxx 修复后 mount -a重新挂载  （ext4文件系统，使用命令  fsck.ext4 /dev/xxx 修复）【定位过程】1.OS启动时报错Failed to mount /var/chroot/DWS/data22. 参考解决方式1，进入维护模式修复后成功启动3. 启动后vi /etc/fstab 将步骤2屏蔽的盘重新加进来4. mount -a挂载盘报错，data2 data4未挂载上，Structure needs cleaning5. xfs文件系统，执行xfs_repair  /dev/xxx 修复后（如果失败 xfs_repair  -L /dev/xxx ， -L 可能会导致数据丢失）， mount -a重新挂载成功6. gs_replace修复节点时，报错 File exists: '/DWS/data1/coordinator'7. cd 到 报错节点路径下/DWS/data1 执行 ll ls 等元命令报错，去data3 下执行一样报错；去修复过的data2,4下执行正常；分析data1,3虽然挂载正常但是文件系统仍是损坏的；umount  /dev/xxx 解除挂载，xfs_repair  /dev/xxx 修复data1（如果失败 xfs_repair  -L /dev/xxx ， -L 可能会导致数据丢失），3后，mount -a重新挂载，执行元命令正常8. gs_replace修复节点后集群正常

GaussDB(DWS)812版本；数据库目前的字符集是SQL_ASCII，现在想要修改为UTF-8，具体需要怎么操作？修改后数据库中原有中文是否会乱码？

dws里的临时文件容量怎么限制大小或者清理空间？删了很多行，更新了很多行数据

【问题描述】gtm 实例异常，主备不连接失效【解决方法】1. iptables -L -n --line-number 查看发现防火墙未关闭2. 客户下午自己配置防火墙，未关闭，导致gtm主备不同步3. iptables -F 打开防火墙后，自行恢复

 ========================================在数据表右键，查看数据提示：获取数据时出错  单击“详细信息”了解详情。   SQL错误码: = 42P01 ERROR: relation "gs_wlm_session_info" does not exist   Hint: please use database "postgres" 提示 请刷新对象浏览器，然后重试。 关闭并重新打开窗口。  ==============================SELECT  * FROM dbms_om.gs_wlm_session_info;报错：[2023-10-18 10:20:45.293 CST] : [ERROR] 执行失败 错误代码：[0]SQL错误码: = 42P01 ERROR: relation "gs_wlm_session_info" does not exist   Hint: please use database "postgres" Line Number: 1==============================select * from  GS_WLM_SESSION_HISTORY数据库操作时出错。 确认要继续执行吗？ 单击“详细信息”了解详情。   ERROR: please use database "postgres" to dump wlm state info   Where: referenced column: pg_dump_wlm_session_info SQL statement "SELECT pg_catalog.pg_dump_wlm_session_info(true)" PL/pgSQL function pg_get_wlm_session_history() line 8 at EXECUTE statement 行号： 25