GaussDB(DWS)的规划器在选择查询计划时，主要考虑了哪些因素？

了解背景什么是inode?在Linux系统里一切皆文件。文件存储在硬盘上，硬盘的最小存储单位“扇区”（Sector），每扇区存512字节（Bytes），即0.5KB。 在OS层，发生IO操作在硬盘上，不会一个个扇区读取，效率太低，而是一次性连续读取多个扇区，即一次性读一个“块”（Block）。 块是OS层最小的存取单位，一般地默认os块大小为4K，比如常见的centos、redhat、suse、oracle等OS，kylin server一般默认是64K。数据库系统一般默认数据块大小是8K，比如GaussDB(DWS)、Postgres、Oracle默认都是8K。 如果需要查看块大小可以使用getconf PAGE_SIZE或者getconf PAGESIZE。 数据都在文件里写，文件存储在“块”中，但是，文件的字节数、拥有者的User ID、Group ID、读写执行权限、文件时间戳ctime/mtime/atime、连接数、文件数据block的位置并不和该文件的数据存储在一起，这部分内容我们叫文件的元信息。也就是说除了文件名和文件内容以外的信息，都存储在元信息里，这个元信息俗称索引节点，即inode。 既然说了是元数据，数据指定要存储在硬盘上那么，inode也是要占用磁盘空间的。每个inode一般是128Byte或者256Byte，inode的总数是在磁盘分区格式化时指定。我们假设1G的磁盘，每1K设置1个inode 128Byte，那么inode占用的磁盘空间将高达128MB，占磁盘总量的1/8。inode还有好多有趣的应用这里不再赘述，小伙伴们可自行了解吆。问题描述某客户配置了生产环境应用系统的自动备份最近连续多天失败，需要分析原因。问题根因遇到No space left on device报错1. 检查磁盘使用率df -h2. 检查是否为inode满了df -i说明：以下主机名为随机名称。[root@abcde-db03 ~]# df -iFilesystem Inodes IUsed IFree IUse% Mounted ondevtmpfs 16478032 433 16477599 1% /devtmpfs 16480828 1 4183134 1% /dev/shmtmpfs 16480828 1 4183134 1% /var/chroot/dev/shmtmpfs 16480828 1458 4181677 1% /runtmpfs 16480828 17 4183118 1% /sys/fs/cgroup/dev/vda1 2621440 2621440 0 100% //dev/nvme0n1p1 156281344 8265 156273088 1% /var/chroot/DWS/data1/dev/nvme0n1p2 156281344 6025 156275319 1% /var/chroot/DWS/data2tmpfs 16480828 1 16480827 1% /run/user/1001tmpfs 16480828 1 16480827 1% /run/user/0说明：可以看到IFree实际已经为0，IUse%实际已经100%，代表inode已经写满了，正常状态下IUse也不会写满，在70%以下认为在合理范围。分析过程步骤1 根据备份日志排查发现，日志/opt/dws/tmp/无法写文件报错No space left on device[root@abcde-db03 ~]# vi /home/Ruby/log/cloud-dws-deploy.log步骤2 根据df -i检查发现/opt/dws/tmp挂载点在/根目录下，且根目录的inode使用率到100%[root@abcde-db03 ~]# df -h步骤3 根据检查根目录发现/tmp目录下gauss_error_file_*、gauss_hosts_file*、gauss_output_file*、gauss_result_file*类文件很多，多达100w+[root@abcde-db03 ~]# df -i[root@abcde-db03 ~]# cd /tmp[root@abcde-db03 tmp]# ls -l gauss_*_file_*|wc -l1381639这类文件主要gs_checkperf工具产生的临时文件，gs_checkperf主要是集群内监控执行采集节点各项指标如磁盘CPU内存等指标和巡检时会产生，执行动作完成后临时文件就不需要了，临时文件是历史动作有失败时会保留，评估可以直接删除，删除一定经客户许可。解决方案定时任务定时清理临时文件删除一定经客户许可，删除一定经客户许可，删除一定经客户许可。批量删除文件后inode使用率恢复正常，删除操作谨慎操作，需要按照客户流程执行，禁止私自操作[root@abcde-db03 tmp]# pwd/tmp[root@abcde-db03 tmp]# find /tmp -maxdepth 1 -name "gauss_*_file_*" -type f |xargs -n 1000 rm -f说明：xargs -n 1000 rm -f主要使用在文件数量多的时候，避免删除报错Argument list too long

使用gsql查询时，返回的小数比如0.5，0.25等结果的时候不显示0

数仓在使用过程中，难免会面临查询语句出现异常中断、阻塞时间长等突发问题，如果没能及时记录信息，事后就需要投入更多的人力及时间成本进行问题的定位和解决，有时还无法定位到错误出现的地方。为了解决这种场景，GaussDB(DWS)提供了强大的运维工具TopSQL，对运行中和运行完成的语句全方面记录，帮助用户定位性能问题。TopSQL被誉为性能定位、劣化分析等的重要基石，为用户提供覆盖内存、耗时、IO、网络、空间等多方面的信息记录。在线体验性能调优沙箱实验，点击预约直播听专家详解TopSQL工具。本期我们邀请了华为云数仓GaussDB(DWS)调优专家刘老师坐阵，和大家一起探讨关于运维利刃—TopSQL的话题。【本期云咖】【问题参考】（包括不限于）1. GaussDB(DWS)在开启全部的topsql情况下，会影响查询性能吗2. GaussDB(DWS)中topsql会占用多大空间，是否需要手动清理3. 如果根据topsql指导日常的业务优化4. topsql能否统计到存储倾斜的场景……对于GaussDB(DWS)运维工具TopSQL，你有哪些疑问呢？ 【活动时间】2024年2月19日-3月3日【参与方式】直接在此活动帖下方回帖提问即可。【获奖规则】参与云咖问答的提问我们会整理在问答专题中，你的提问将会帮助更多的开发者~欢迎大家踊跃提问，积极互动~【活动规则】1、开发者用户发布的提问，必须与本期产品相关，其他产品求助帖不参与此次活动，将视为无效内容，否则取消该用户获奖资格。（其他产品求助可发帖到相应的版块进行提问）；2、本次活动不限用户的总提问数及连续提问数，但需保证提问质量，如华为云社区小编认定参与用户有恶意灌水嫌疑，则取消该用户获奖资格；3、本次活动将根据实际参与情况发放奖励，包括但不限于用户百分之百中奖或奖项轮空的情况；以上奖品均为实物奖品，具体发放视出库情况而定； 4、每期活动预计于结束后10天内完成奖项公示，并于结束后20个工作日内完成邮寄。【温馨提示】1、请务必使用个人实名账号参与活动（IAM、企业账号等账号参与无效）。如一个实名认证对应多个账号，只有一个账号可领取奖励，若同一账号填写多个不同收件人或不同账号填写同一收件人，均不予发放奖励。2、所有获得奖品的获奖用户，请于获奖后3日内完成实名认证，否则视为放弃奖励。

【问题背景】：执行查询抛出报错：ERROR: The view "xxx" is invalid! Hint: Please turn on GUC parameter "view_independ问：抛出该报错的问题原因为？答：参数view_independent打开的时候执行ddl操作，让视图无效，后续关闭参数，这个时候再查询抛出该报错，问：view_independent这个参数默认为关闭，打开后再关闭，对数据库中的视图是否有什么潜在的影响答：打开后再关闭，中间若进行过删除视图操作，可能会存在很多无效视图。当参数view_independent开启时，存在视图依赖的表、函数、同义词及其他视图可以单独删除（临时表及临时视图除外），关联视图保留但不可用。当参数view_independent关闭时，存在视图依赖的表、函数、同义词及其他视图不可以单独删除，仅可使用cascade级联删除。

【问题现象】：对某个用户revoke某项权限后，用权限查询函数查询，发现该用户仍有该权限【根因】：用户权限来源不是直接赋予，而是通过role（角色）或者SYSADMIN（系统管理员）获得的。【排查方法】：1. 查询 pg_authid 表，通过 rolsystemadmin 字段判断是否是系统管理员，系统管可以管理所有普通用户和数据库。2. 可以通过下列语句查询role的赋予情况，role为角色，member为被赋权用户。然后再排查role所拥有的权限。select r1.rolname as role, r2.rolname as member, r3.rolname as grantor, admin_option from pg_auth_members a,pg_roles r1,pg_roles r2,pg_roles r3 where a.roleid = r1.oid and a.member = r2.oid and a.grantor = r3.oid;【解决方法】：回收用户的role（角色）或者SYSADMIN（系统管理员），但这会影响用户的其他权限，如有需要，请将权限更细粒度划分。revoke role_name from user_name;revoke all privileges from user_name; --回收系统管理员权限【复现示例】：将test_schema_user的权限赋予test_schema_user2，用revoke回收test_schema_user2的test_schema的create权限，利用has_schema_privilege查询test_schema_user2的权限情况，发现其仍有test_schema的create权限。参考：访问权限查询函数_数据仓库服务 GaussDB(DWS)_8.1.3推荐版_函数和操作符_系统信息函数 (huaweicloud.com)

GaussDB(DWS)8.1.3-ESL支持的麒麟操作系统如下：服务器类型操作系统软件支持的版本号对应操作系统内核版本通用X86服务器银河麒麟银河麒麟V10SP1（基于OpenEuler开发的银河麒麟V10SP1，目前仅支持20210518版本）Linux localhost.localdomain 4.19.90-23.8.v2101.ky10.x86_64 #1 SMP Mon May 17 17:08:34 CST 2021 x86_64 x86_64 x86_64 GNU/LinuxTaiShan服务器银河麒麟银河麒麟V10SP1（基于OpenEuler开发的银河麒麟V10SP1，目前仅支持20200711版本）Linux localhost.localdomain 4.19.90-17.ky10.aarch64 #1 SMP Sun Jun 28 14:27:40 CST 2020 aarch64 aarch64 aarch64 GNU/Linux

1、解除单cn实例方法，去对应cn实例目录下执行如下命令sed -i '/^#@#@#.*/s/#@#@#\(.*\)/\1/g' /srv/BigData/mppdb/data1/coordinator/pg_hba.conf2、批量注释关闭白名单方案参考：https://bbs.huaweicloud.com/forum/thread-145788-1-1.html

1、gs_replace标准方案请参考：https://bbs.huaweicloud.com/forum/thread-145788-1-1.html2、gs_replace -t config -h 节点名称之后，还需要gs_replace -t start -h 节点名称之后实例才会正常。注意coordinator_heartbeat_timeoutcn自动剔除的时间，如果未及时start，可能cn会delete状态需要重新执行config，在及时执行start，或者调大coordinator_heartbeat_timeout时间（gs_guc set -Z cm -N all -I all -c "coordinator_heartbeat_timeout=600"）单位是秒

1、只传入视图名，查询结果不易杜，但用于转储时尽可能使用此方法。会有一些多余的括号。select * from pg_get_viewdef('schema_name.view_name');2、传入视图名，指定pretty属性为true。显示的格式易读适合打印。select * from pg_get_viewdef('schema_name.view_name',true);3、传入视图名，指定fullflag属性为true。显示全部视图定义。select * from pg_get_viewdef('schema_name.view_name',false,true);

【问题描述】       扩容ECF工步失败：创建Region master CMDB三层服务数失败，报：can not find the cluster ei-dbs-region【问题版本】       HCS830【问题根因】        cdk提供的方法get_new_cluster_flag，用于查询当前集群的版本是1.9.7还是1.15.11版本，代码问题导致判断失误【定位过程】1、部署扩容ECF工步子工步EICommon Region：创建Region master CMDB三层服务数失败，报：can not find the cluster ei-dbs-region；2、导出工步日志，发现是"/opt/cloud/hcci/src/HCCI/utils/business/CDK/cdk_api_internal.py"脚本 line 135行，get_new_cluster_flag方法报的；3、调用CDK方法get_new_cluster_flag用于获取集群版本，从而根据版本获取节点密码，此报错影响高阶纳管节点；4、给CDK建关联单，确认是否有影响，修改cdk_api_internal.py脚本135行代码进行规避，规避后重试工步执行成功；【规避措施】1、登录HCC Turnkey后台，执行命令查询文件cdk_api_internal.py，找到对应turnkey版本的文件路径find /opt/cloud -name cdk_api_internal.py2. 打开文件，找到该方法get_new_cluster_flag，并修改135行代码修改前：    raise Exception(f'can not find the cluster {self.cluster_name}')修改后：    return True3.  修改完成后，确认前台无正在运行的工步再重启框架sh /opt/rootscripts/restart.sh

【版本信息】800【问题描述】全节点CPU高【处理方法】首先是按照cpu高的标准处理流程进行：https://bbs.huaweicloud.com/blogs/419012先查看集群基本情况：1.活跃语句100左右2.Stream数最大103.Cpuwatcher脚本占CPU的语句都在40以下4.抓进程也抓不到高CPU的进程ps H -eo pid,tid,pcpu|sort -n -k 3 |grep master5.语句最长执行时间1hr；有线程等待和cpu倾斜：6.并发数60无改动由此可以看出，长SQL，占CPU高的SQL语句都抓不到，但是全节点CPU均超过90%；定位不出具体SQL，则重新回到业务侧确认业务情况（若确认是资源不够导致cpu高的问题则此时可进行资源管控）。7.确认实时业务为短查询高并发语句，且在CPU高时期出现大量超时告警；查询dws的超时告警设置，发现数值为0，说明告警为客户外部程序设置，执行超过时间4s触发告警，与dws无关。因此告警后语句仍然正常执行。8.当前业务影响为实时业务查询感知慢，因此找到与实时业务一起执行的并发业务。活跃语句查询结果只找到一个非实时业务的语句，优化该语句后CPU无变化，且该语句执行时间在20分钟内。9.此时怀疑是短查询语句自身占用的CPU高，需要做优化处理。此时让客户明确提供了实时查询并发语句，优化该表后仍然无明显变化。查询表大小：select count(1) from 表名；查询表数量：select count(1) from pg_class；10. 查询实时查询的业务库的表数量，900+，全部做ANAYLZE后CPU降至20%以下：本问题中导致CPU高的根因为业务库中的900多个表中有个别或者部分表的统计信息不完整，导致执行计划选择了更消耗CPU的执行方式，导致了CPU高；但是由于都是快查询高并发语句（执行4s即为慢语句）；因此抓不到异常SQL。【根因分析】实时查询中有部分表统计信息不完整导致执行计划对资源占用更大，由于900+表排查困难，对业务库做统计信息收集后CPU立即恢复。本案例中对于CPU高的现象用常规的查杀语句，资源管控的方式无法解决，因为占用CPU的语句都是短查询语句，活跃数量基本在100以内，一个语句几秒钟就执行完成，这种情况下是无法抓到单独占CPU高的SQL语句的。这种情况下需要从另一个角度解决问题，就是SQL执行慢，SQL慢的常规解决方法就是查询执行计划，收集统计信息，优化语句。本案例中，SQL慢的表象结果仅为CPU高；内存，磁盘等其他指标均正常。

【问题描述】     管控面升级后serviceOM数仓服务监控告警模块不显示，报集群告警列表接口异常【问题版本】     HCS820、821、830【问题根因】     dms_endpoint为域名 service om无法解析【分析过程】1、管控面升级后检查发现serviceOM数仓服务监控告警模块不显示，且弹框提示集群告警列表接口异常、请求失败，请稍后重试或联系技术人员；2、界面F12发现/dws/rest/maintain/v1.0/dms/cluster接口报500 Internal Server Error;3、检查发现serviceOM配置管理{region_id}.dms.dms_endpoint的值配置的是域名加端口，导致无法解析，需要配置成IP；【解决方法】     把serviceOM配置管理{region_id}.dms.dms_endpoint域名加端口改成IP加端口即可；     注：（IP可以到节点ping一下域名ping出来，正常是和{region_id}.dws.controller_endpoint、{region_id}.dws.insight_endpoint配置的IP一致）

客户反馈问题，datax从dws往外导数据，速度恒定在10mb/s，从gp导可以达到40mb/s，这个是不是dws有什么限制？给出来详细的处理意见好伐，要不要让客户提交case 工单好了

【使用场景】当客户在使用数据库过程中，如果白天执行一些耗时比较长的任务（例如：统计数据汇总之类或从其他数据库同步数据的任务），会对正常的业务有性能影响，所以客户经常选择在晚上执行，无形中增加了客户的工作量。因此数据库兼容Orcale数据库中定时任务的功能，可以由客户创建定时任务，当任务时间点到达后可以自动触发任务的执行，从而可以减少客户运维的工作量。同时当我们执行一些SQL的实时性不是很高，集群资源又比较紧张的情况下，可以使用定时任务的方式下发SQL。【常用视图介绍】811之后的版本，PG_JOB视图用于代替之前版本的PG_JOB系统表，提供对之前版本的前向兼容。原PG_JOB系统表已经变更为PG_JOBS系统表。pg_job中的字段如下：job_id：作业ID。current_postgres_pid：如果当前任务正在执行，那么此处记录运行此任务的postgres线程ID。默认为-1，表示此任务未被执行或已经执行结束。log_user：创建者的UserName。priv_user：作业执行者的UserName。dbname：标识作业执行的数据库名。node_name：标识当前作业是在哪个CN上创建和执行。job_status：当前任务的执行状态，取值范围：('r', 's', 'f', 'd')，默认为's'，取值含义：r=runnings=successfully finishedf=job failedd=disableps：当job连续执行失败16次，会将job_status自动设置为失效状态'd'，后续不再执行该job。start_date：作业第一次开始执行时间，时间精确到毫秒。next_run_date：下次定时执行任务的时间，时间精确到毫秒。failure_count：失败计数，作业连续执行失败16次，不再继续执行。interval：作业执行的重复时间间隔。last_start_date：上次运行开始时间，时间精确到毫秒。last_end_date：上次运行的结束时间，时间精确到毫秒。last_suc_date：上次成功运行的开始时间，时间精确到毫秒。this_run_date：正在运行任务的开始时间，时间精确到毫秒。nspname：作业运行时所在的命名空间的名称。what：作业内容。【定时任务的创建及管理】可以参考官方文档进行操作：https://support.huaweicloud.com/devg-dws/dws_04_0041.html【任务状态判断】1.当时间到达job任务的next_run_date时间，job任务会进入任务队列，单个cn的job并发上限受到job_queue_processes的 限制，默认为10，超出该限制的任务会进行排队，此时job_status即任务的状态为f，start_date为创建job时传入的开始时间参数，start_date和next_run_date的值都为空，this_run_date的值也为空（当开始执行时该字段会进行刷新），2.当job排到队开始执行时，job_status即任务的状态会刷新为r，current_postgres_pid刷新为运行此任务的postgres线程ID，start_date和this_run_date会刷新为当前时间，若下次不执行next_run_date刷新为'4000-01-01 00:00:00'，若下次继续执行则next_run_date刷新为下一次执行的时间。3.当前作业执行成功后若下一次继续执行则，job_status即任务的状态会刷新为s，failure_count连续失败次数置0，this_run_date会刷新为当前时间，若下次不执行next_run_date刷新为'4000-01-01 00:00:00'，若下次继续执行则next_run_date刷新为下一次执行的时间。4.当前作业执行失败后后若下一次继续执行则，job_status即任务的状态会刷新为f，failure_count连续失败次数比之前加1，this_run_date会刷新为当前时间，若下次不执行next_run_date刷新为'4000-01-01 00:00:00'，若下次继续执行则next_run_date刷新为下一次执行的时间。5.若作业上一次执行完后不继续执行，job_status即任务的状态会刷新为d，next_run_date刷新为'4000-01-01 00:00:00'；总体流程如下：【执行定时任务的常见场景】1.若出现如下场景，job_status为f 且last_end_date和last_suc_date为空的情况，可能为该job线程丢失，我们可以登录后台，搜索对应cn日志，zgrep 'job_id: xxx'，在该日志文件中若找到如job worker with job id:xxx took too long time to start ,so canceled it，原因：进程启动慢被清理，规避措施：该场景中线程启动慢与集群各种资源都有关，重新调度该定时任务，在821新版本中添加1. 增加超时后重新调度逻辑 2. 增加参数 job_queue_naptime 设置触发任务的时间间隔及超时时间2.若根据job id查看对应cn日志出现如下报错：error msg: canceling statement due to workload manager exception.DETAIL: except rule [except_spill] is meet condition:rule [spillsize] is over limit, current value is:10517.原因：该场景为下盘超过异常规则导致规避措施：需要修改异规则：ALTER EXCEPT RULE 异常规则名 with (spollsize=xxx);3.在客户端设置完任务，使用当前时间后job任务没有立即执行：原因：当定时任务的执行时间设置为当前时间或者过去时间时，任务都会立即执行，这种场景可能是任务在排队等待，或者客户端和后台存在8小时时差，按照当前时间下发的任务需要等8小时后才会执行。判断方法：针对上述场景我们可以通过select * from pg_job进行判断看该任务下次执行时间，和select now();数据库当前时间做比较判断是否在排队还是因为时差导致还没有到执行时间。规避措施：1.若为排队，我们可以根据集群资源使用情况判断是否调大job_queue_processes（需要重启集群）2.若为客户端和后台存在时差，可以调整定时任务开始时间进行规避4.定时任务执行报错：all 32768 jobids have alloc, and there is no free jobid原因：定时任务当前规格为最大32768个，当前已达到上限从而触发报错规避措施：建议客户手动清理部分d状态的作业select * from pg_job where job_status = 'd' and last_start_date < 'xxxxx' and interval = 'null';  --xxx为 清理最后一次执行为某天前的定时任务call dbms_job.remove(xxx);   --xxx 为定时任务的jobid