（1）对于每个SQL，生成计划前首先从资源管理模块获取系统当前的最大可用内存（Query Max Mem）和当前可用内存（System Available Mem）。最大可用内存通常为每个DN的最大可用内存去除系统预分配内存，例如：数据缓存等，表示语句可用的最大内存，如果语句使用内存超过该值，必须下盘。当前可用内存用于表示当前系统的繁忙程度，如果当前可用内存比较小，倾向于选择耗费内存少的计划。（2）依据当前可用内存生成计划，同时根据SQL引擎优化器计划生成过程中的cost估算值估算每个物化算子的内存使用量，以及流水线场景下整个查询使用的内存总量估算值。如果该值大于当前可用内存，则尝试将整个查询的内存使用量调到当前可用内存以下，此时会造成部分算子下盘。（3）将语句及估算的语句内存发送到CCN，如果当前可用内存小于语句估算内存，则估算语句的内存进一步减少是否对查询性能造成较大的影响，如果根据cost评估影响不大，则进一步减少算子的内存使用，使语句内存使用满足当前可用内存，将语句下发执行，否则则进入排队状态。（4）由于每个算子的内存使用量是基于cost评估获得，可能存在一定的误差。因此，在SQL语句执行时，支持内存的动态调整，包括：执行算子内存的自动扩展和提前下盘。当算子达到估算的内存值上限，但系统还有宽裕的内存时，会进行算子内存的扩展，继续保持不下盘的状态。当系统已用内存达到80%或更高时，如果算子已有最小内存保证，则会触发提前下盘逻辑，保证不会由于内存不足而报错。

GaussDB(DWS)的静态内存管理存在较大弊端，需要调优人员能够根据数据量、语句复杂程度和系统的内存大小设置合理的work_mem，既避免work_mem设置太大导致系统资源不够用，还要考虑到数据规模，保证大部分算子不下盘。通常情况下，这个是很难做到的，有以下几点原因：（1）通常情况下，复杂语句的执行计划中包含多个复杂算子，每个算子的内存使用上限是work_mem，我们没有办法计算一个语句要使用多少内存，因此也就不容易设置一个最优的work_mem参数，保证尽可能不下盘，同时内存又够用。并发场景更无法设置了。（2）work_mem只是每个算子内存使用的上限，并不是预分配；如果数据量没有那么大的话，实际内存使用是达不到work_mem的。因此也会影响work_mem的设置。（3）每个语句的场景不一样，有的语句包含多个物化算子，而另外的语句只有一个物化算子，而这个算子对内存的需求会比较大，因此无法全局统一地进行设置。GaussDB(DWS)的内存自适应技术介绍针对静态内存管理机制的弊端，我们设计了内存自适应控制技术，目的有两个：（1）去除静态内存管理对work_mem的依赖。可以由SQL引擎优化器模块自动估算每个算子所需的内存。（2）避免大并发场景下内存不足现象的发生。资源管理模块根据SQL引擎优化器对于每个查询内存的估算值，对每个查询进行调度，如果超过系统可用内存，则进行排队。

在SQL语句复杂、处理数据量大的AP场景下，单个查询对内存的需求越来越大，多个语句的并发很容易将系统的内存吃满，造成内存不足的问题。为了应对这种问题，GaussDB(DWS)引入了内存自适应控制的技术，在上述场景下能够对运行的作业进行内存级的管控，避免高并发场景下内存不足产生的各种问题。GaussDB(DWS)的静态内存管理机制及缺陷GaussDB(DWS)的执行引擎继承自PG，对于优化器生成的执行计划树，总体采取执行算子+流水线的处理方式，如下图所示。对于NestLoop算子节点，需要首先从左树的IndexScan算子节点获取元组，然后到右子树的IndexScan算子节点进行连接，匹配元组后进行输出。      流水线的执行方式使得对于NestLoop, IndexScan类的一般算子，同时只有一定数量的元组处于内存中，对于行引擎每个算子仅占用一条元组的空间，对于列引擎占用一个batch（最多1000条元组）的空间，占用的空间较小，基本可以忽略不计。      但是，GaussDB(DWS)中也有一些需要将所有数据收集后进行处理的算子，在执行时需要使用较多的内存，通常我们称这类算子为物化算子。GaussDB(DWS)中主要存在如下不同种类的物化算子：（1）HashJoin：Hash连接操作符，主要思想是计算左右两表连接列的hash值，通过hash值比较减少元组比较的次数，需要将一个表建立hash表，另一个表进行hash值比较操作，建立hash表需要在内存中进行。（2）HashAgg：Hash聚集操作符，主要思想同HashJoin类似，通过hash值比较减少元组去重比较的次数，需要将不同值的元组保存的内存中。（3）Sort：排序操作符，需要获取所有元组后进行排序操作，待排序元组均存在于内存中。（4）Materialize：物化操作符，通常在需要重复扫描时使用，通过将结果存储在内存中，保证重复扫描时的效率。      同时，GaussDB也提供下盘的机制，当上述操作符需要使用的内存太大时，可以将部分或全部的数据下盘处理，提高内存的使用效率，但相应的查询性能也会受到影响。PG使用 work_mem参数来控制算子可使用内存的阈值，当使用内存超过阈值时，就需要做下盘处理。GaussDB(DWS)的静态内存管理机制也延续了PG的处理机制，使用work_mem来控制单算子的内存使用上限。

最近遇到一个客户场景，涉及共享schema的权限问题。场景简单可以描述为：一些用户是数据的生产方，需要在schema中创建表并写入数据；另一些用户是数据的消费方，读取schema中的数据做分析。对于该schema权限管理的一种实现方法是数据生产方在每次创建新表后告知管理员用户使用grant select on all tables in schema语法来授予消费方权限。这种方法有一定的局限性。如果生产方在schema下面又创建了一些新表，为了授权消费方使用这些新表还需要告知管理员用户再次使用grant select on all tables in schema来授权。有没有简单的应对方案？答案是肯定的，可以使用Alter default privilege。Alter default privilege用于将来创建的对象的权限的授予或回收。 所有在共享schema中创建对象的用户都应该出现在alter default privileges for user之后的列表中。否则，如果有用户creator3没有在列表中，其在共享schema中创建的对象或者说那些Owner是creator3的对象将不能被user1查询。因为共享schema中creator3用户创建的表没有授予user1默认权限。管理员可以通过alter default privileges for user将creator3放入列表中为user1授予访问creator3用户创建表的默认权限，也可以由creator3用户自己通过alter default privileges授权给user1. 前面语法参数说明中有如果省略FOR ROLE/USER，则缺省值为当前用户。 alter default privileges只处理将来的对象，grant只处理已有的对象。进一步的，这两种语法授予权限时涉及的对象仅包括Owner是当前用户的对象。如果要为共享schema下面所有Owner的对象授予权限，需要使用管理员用户使用alter default privileges for user语法和grant语法。

  在GaussDB各类问题场景中，网络故障是最难定位及恢复的问题之一，其不仅可能影响着数据库的性能，甚至在一定程度上会阻塞业务的正常运行，造成严重后果。网络问题牵连着应用侧（即GaussDB）、操作系统、交换机以及硬件资源等，本文将介绍几种常用手段，用于梳理其间可能存在的问题，从而快速定位恢复。 对于性能慢、数据库连接异常等情况，建议使用gsar脚本检查网络状态，若重传率或丢包率超过0.01%，如图1最后一列红色框，则说明网络存在问题，需进一步分析定位。 排查一：TaiShan服务器网卡加固      对于TaiShan服务器(100/200)，均需要使用兼容的网卡及驱动，否则很有可能产生此类网络问题。附件：GaussDB A加固配置指南04.pdf（附件请点击文末“阅读原文”获取）       须严格按照加固配置指南进行定位，包括透明大页等均需核查。 排查二：MTU一致性      MTU即最大传输单元，整条数据链路要保证MTU的一致性，否则可能由于数据包大小不匹配导致丢包。使用ifconfig命令即可查看和修改各个网卡的MTU值。排查三：网络重传情况1. netstat查看重传次数      使用gsar脚本观察到明显的重传现象后，可根据netstat命令具体查看重传状态。      若重传次数达到12次（图3红色框中，第一列表示距离下一次重传的时间，第二列为已经发生重传的次数，理论上重传达到9分钟，keepalive就会检测到连接异常，将其断开），则说明此时网络不通，可进一步排查对端进程状态以及网络环境（ping）。

一、什么是keepAlived？Keepalived顾名思义，保持存活，在网络里面就是保持在线了，也就是所谓的高可用或热备，用来防止单点故障(单点故障是指一旦某一点出现故障就会导致整个系统架构的不可用)的发生。 二、keepAlived的原理Keepalived的实现基于VRRP（Virtual Router Redundancy Protocol，虚拟路由器冗余协议），而VRRP是为了解决静态路由的高可用。虚拟路由器由多个VRRP路由器组成，每个VRRP路由器都有各自的IP和共同的VRID(0-255)，其中一个VRRP路由器通过竞选成为MASTER，占有VIP，对外提供路由服务，其他成为BACKUP，MASTER以IP组播（组播地址：224.0.0.18）形式发送VRRP协议包，与BACKUP保持心跳连接，若MASTER不可用（或BACKUP接收不到VRRP协议包），则BACKUP通过竞选产生新的MASTER并继续对外提供路由服务，从而实现高可用。 三、KeepAlived与LVS的关系1、keepalived 是 lvs 的扩展项目，是对LVS项目的扩展增强，因此它们之间具备良好的兼容性。2、对LVS应用服务层的应用服务器集群进行状态监控：若应用服务器不可用，则keepalived将其从集群中摘除，若应用服务器恢复，则keepalived将其重新加入集群中。3、检查LVS主备节点的健康状态，通过IP漂移，实现主备冗余的服务高可用，服务器集群共享一个虚拟IP，同一时间只有一个服务器占有虚拟IP并对外提供服务，若该服务器不可用，则虚拟IP漂移至另一台服务器并对外提供服务，解决LVS本身单点故障问题。

GaussDB(DWS)为了保证业务的连续性和高可靠性，各个组件都进行了高可用设计。对于业务应用或者用户来说，他们发生请求给CN，CN解析并生成执行计划，交给DN去执行，执行后再由CN汇总将数据返回给业务用户或者业务应用。一、LVS是什么？ LVS是Linux Virtual Server的简称，也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目，它的官方站点是www.linuxvirtualserver.org。现在LVS已经是 Linux标准内核的一部分，在Linux2.4内核以前，使用LVS时必须要重新编译内核以支持LVS功能模块，但是从Linux2.4内核以后，已经完全内置了LVS的各个功能模块，无需给内核打任何补丁，可以直接使用LVS提供的各种功能。 二、LVS的目的是什么？LVS主要用于服务器集群的负载均衡，拥有VIP，客户端将所有请求发送至此VIP，LVS负责将请求分发到不同的RS，客户不感知RS。其目的是提高服务器的性能，将请求均衡的转移到不同的服务器上执行，从而将一组服务器构成高性能、高可靠的虚拟服务器。 三、LVS的体系结构使用LVS架设的服务器集群系统有三个部分组成：　　（1）最前端的负载均衡层，用Load Balancer表示；　　（2）中间的服务器集群层，用Server Array表示；　　（3）最底端的数据共享存储层，用Shared Storage表示；在用户看来，所有的内部应用都是透明的，用户只是在使用一个虚拟服务器提供的高性能服务。

全文检索是在互联网场景下应用非常广泛的特性，搜索引擎、站内搜索、电商搜索等场景下都会使用到，GaussDB(DWS)同样也支持全文检索功能，是基于GIN索引实现的。全文检索实现的功能，简单来说就是根据关键字从在全文字段中搜索到相关的信息，在不使用全文检索特性时，只能通过like ‘%keyword%’方式做模糊匹配，无法利用到索引，只能进行全表扫描，效率非常低，全文检索特性可以有效地提升检索性能。全文检索的基础就是GIN索引，Generalized Inverted Index，也就是通用倒排索引，是一个存储对(key, posting list)集合的索引结构，其中key是一个键值，而posting list 是一组出现过key的位置。如(‘hello', 2,3)中，表示hello在2和3这两个位置出现过。相信大家对GaussDB(DWS)的全文检索使用已经有了一些了解，其实全文检索还有ngram分词，和自定义词典等等其他用法。

收集各节点的锁信息为了检测分布式死锁，首先需要获得各节点的锁信息。GaussDB(DWS) 中可以通过 PG_LOCKS 视图查询当前节点的锁信息，因此可以通过 EXECUTE DIRECT 语句在所有节点查询 PG_LOCKS 视图，并收集到当前节点中。注意此处有一个细节，PG_LOCKS 视图中，很多信息是以 OID 类型给出的，例如一个锁加在一个表上，PG_LOCKS 视图会给出表的 OID。由于同一个表在各节点中的 OID 不一定相同，因此不能通过 OID 来标识一个表。在收集锁信息时，需要先将表的 OID 转换成 SCHEMA 名加表名。其它 OID 信息例如分区 OID 等也同理，需要转化为对应的名字。构建等待关系收集到各节点的锁信息之后，就可以开始构建等待关系了。事务 A 等待事务 B，需要满足 3 个条件：1. 两个事务加锁的资源相同（同一个表、同一个分区、同一个页面或同一个元组等）。特别注意，如果事务 A 对 DN1 的 t1 表的加锁，事务 B 对 DN2 的 t1 表的加锁，则我们认为它们加锁的资源不同，只有同一节点上的同一资源才被认为是相同的资源。2. 事务 B 已经持有锁，而事务 A 还未持有锁。3. 事务 A 和事务 B 申请的锁的级别互斥。通过对上一步收集到的锁信息进行处理，就可以构建出事务的等待关系。等待关系判环构建出事务的等待关系之后，就可以通过检查等待关系是否成环，来判断当前是否有分布式死锁。一般情况下，等待关系不会太多，通过观察就可以判断出当前有无分布式死锁。通过观察上一节中构建的等待信息，可以很容易地判断出事务 transaction1 和 transaction2 发生了循环等待，即产生了死锁。消除死锁上一步最终可能会找到等待关系中的一个或多个环，对于每个环，需要中止环中的一个事务，才能消除死锁。至于应该选择环中的哪个事务进行中止，需要我们从事务的重要性、已执行时间等多方面进行考虑，最终选择一个对业务影响最小的事务进行中止。

分布式数仓应用场景中，我们经常遇到数据库系统 hang 住的问题，所谓 hang 是指虽然数据库系统还在运行，但部分或全部业务无法正常执行。hang 问题的原因有很多，其中以分布式死锁最为常见，本次主要分享在碰到分布式死锁时，如何快速地解决死锁问题。GaussDB(DWS) 作为分布式数仓，通过锁机制来实行并发控制，因此也存在产生分布式死锁的可能。虽然分布式死锁无法避免，但幸运的是其提供了多种系统视图，能够保证在分布式死锁发生之后，快速地对死锁进行定位。假设上述两个事务的执行顺序如下：1. [transaction1] TRUNCATE t12. [transaction2] TRUNCATE t23. [transaction1] EXECUTE DIRECT ON(DN1) 'SELECT * FROM t2'4. [transaction2] EXECUTE DIRECT ON(DN2) 'SELECT * FROM t1'该执行顺序会导致死锁的产生。由于事务 transaction1 和 transaction2 都在 CN1 上执行，死锁中的所有锁等待信息都在 CN1 上，因此该死锁为单节点死锁。节点持有锁等待锁CN1[transaction1] TRUNCATE t1[transaction2] EXECUTE DIRECT ON(DN1) 'SELECT * FROM t2'CN1[transaction2] TRUNCATE t2[transaction1] EXECUTE DIRECT ON(DN2) 'SELECT * FROM t1'GaussDB(DWS) 支持自动处理单节点死锁。当某个节点上的多个事务陷入循环等待时，数据库系统会自动将其中一个事务中止，从而消除死锁。假设两个事务的执行顺序和上一节中的执行顺序一致，还是会产生死锁，死锁中的锁等待信息如下：节点持有锁等待锁CN1[transaction1] TRUNCATE t1[transaction2] EXECUTE DIRECT ON(DN1) 'SELECT * FROM t2'CN2[transaction1] TRUNCATE t2[transaction1] EXECUTE DIRECT ON(DN2) 'SELECT * FROM t1'这就是一个典型的分布式死锁，单独看 CN1 或 CN2 上的锁等待信息，都看不出来有死锁，但将多个节点的锁等待信息放到一起看，就能找到有循环等待的现象。发生分布式死锁时，陷入死锁的事务全部都无法继续执行下去，只有其中一个事务锁等待超时，剩余事务才能继续执行。默认情况下，锁等待超时时间是 20 分钟。

精彩导读：华为云数据仓库GaussDB(DWS)，历经13年的技术磨砺，已成为国产数据仓库中的佼佼者，是中国唯一获得数仓类CC安全认证的产品。华为云GaussDB(DWS)一站式全场景云数据仓库，提供PB级数据分析能力、多模分析和实时处理能力，以统一内核提供公有云、混合云等部署形态，用户体验一致。在金融、泛政府、电信、能源、交通、医疗、物流、电商等领域，帮助1700+大客户规模商用。未来，GaussDB(DWS)将继续深耕云原生Serverless化、实时分析、湖仓一体、数智融合、HTAP等国产数仓核心技术，引领数据产业，创新构建开放融合、云化、实时、全场景、智慧的数据底座！《GaussDB(DWS)资源管控》汇集资源管控架构、资源管控、资源监控三方面内容，详细介绍了资源管控技术原理、资源隔离管控能力、熔断垃圾SQL语句、schema空间管控、资源管控排队问题以及监控工具，帮助您一站式掌握资源管控的理论和应用方法。点击下载《GaussDB(DWS)资源管控》 了解详情联系我们欢迎GaussDB(DWS)用户、客户及爱好者参与到我们的社区建设中来，如果您有建议或疑问欢迎通过邮件联系我们！邮箱：dwspublic@huawei.com产品主页：cid:link_1社区论坛：cid:link_3开发者学习平台：cid:link_2

线下8.1.1.5版本，红帽7.4系统的节点安装系统镜像中带的strace是否有影响？

最近在开发工具脚本时，想要获取已建表的字段信息，比如类型，长度问题。现在通过 information_schema.columns 获取字段元数据。发现查询这个系统视图时发现时慢时快，快的时候25秒左右，慢的时候在3-4分钟。后来通过查看产品文档,通过关联几个系统表，整理一份sql，发现字段定义的长度和建表时的ddl存在差异。发现varchar类型的定义长度是atttypmod -4 其他是date ,timestamp,numeric  等类型更是看不懂了。sql：select t1.*from pg_attribute t1inner join pg_class t2on t1.attrelid = t2.oidinner join pg_namespace t3on t2.relnamespace = t3.oidinner join pg_type t4on t1.atttypid=t4.oidwhere t1.attnum>=0 and t2.relname = 'tablename' and t3.nspname='schemaname'order by t1.attnum;有没有熟悉的大神、老师，帮忙解释一下。或者告知其他的方法。

一、背景明明表存在，但是删除提示cn5003表不存在，在所有dn查询该表显示，其他cn、dn表信息都有，但cn5003不存在。原语句drop table xx.yy;报错ERROR:cn_5003:table "yy" does not exist查询系统表数据select * from pgxc_parallel_query('all','select get_nodename()::text,tablename::textfrom pg_tables where schemaname=''xx'' and tablename=''yy'') a(c1 text,c2 text);结果c1           | c2-----------------------------dn_6001_6002 | yydn_6003_6004 | yydn_6005_6006 | yydn_6007_6008 | yydn_6009_6010 | yydn_6011_6012 | yydn_6013_6014 | yydn_6015_6016 | yycn_5002      | yycn_5001      | yy(10rows)二、原因原因一般是并发ddl三、处理方法集群后台沙箱内gsql -m连接create table if not exists xx.yy;gsql 连接drop table xx.yy;

一、写在最前面，先说处理方法1、设置磁盘只读阈值（磁盘阈值为95的意思）gs_guc reload –Z cm –c “datastorage_threshold_value_check=95”; 2、解除只读gs_guc reload -Z coordinator -N all -I all -c "default_transaction_read_only=off";3、全量build先杀对应目录节点(平时杀尽量不要带mi)cm_ctl stop –n 2 –D /DWS/data2/h2dn2/standby1 –mi然后做一下全量buildnohup cm_ctl build –n 2 –D /DWS/data2/h2dn2/standby1 –b fullcleanup –t 108000000 > /home/Ruby/xx.log 2>&1 &这里可以根据主节点目录大小预估要做的时间，一般1h做1.5G，集群内带宽会用满，1G/s，也可以根据这算一下。最好和业务协调此刻尽量少进大批量作业或其他占用IO的作业。二、这里列举我遇到的三种只读情况集群只读基本由于节点磁盘到达阈值引起，首先可以登录oc界面查看具体告警详细信息确定具体节点，然后到后台检查检查磁盘使用量。到节点上具体的实例目录查询磁盘爆满到底是哪个目录引起的。1、日志目录节点磁盘使用量过大，数据库大小并未触发阈值，且数据目录不大，查询日志目录，发现由于一个定时任务导致日志积压造成。此时，解决方法是删除就行。补充，数据目录为/DWS/data1但日志目录为/DWS/manager/log/Ruby在沙箱内打df –h是看不出来日志目录的，可以在/DWS目录在打一次。日志我记得是挂在沙箱外根目录下，沙箱内在/DWS下。2、备份或快照备份或快照会在集群磁盘上生成大文件造成数据积压，使用ps –ef | grep roach可以查看是否有roach进程，是否是roach进程导致的磁盘打满。备份文件一般存放地址是/DWS/backup跟上述一致，这个目录在沙箱里打df –h是看不出来，进到/DWS看一下3、pg_xlog日志过大通常是单节点出现问题，且通常是备数据目录有问题。这个是由于集群近期插入删除更新等DML操作较多导致。大概率是由于带索引插入引起（主备同步数据，待索引插入的条数是直接插入的double）。当该操作过多备节点追赶不上，就会使得主和备节点之间数据持续积压，相差会越来越大最后导致节点磁盘打满。这个可以这么排查先看对应dn最新的日志，确定备日志同步槽在推进cd $GAUSSLOG/pg_log/dn_6012grep attempt postgresql-xxx.log 这个看最后查询出来的结果的16进制数字是否在增长除此之外也可以查看数据库内,检查restart_lsn是否在增长，增长代表数据同步正常，这个歌要在dn目录才有，后台连接记得该-p对应端口select * from pg_get_replication_slots();到数据实例目录查看，看16进制数是否增长确定同步正常推进实例目录一般是/DWS/data2/h2dn2/standby1这样的，每个实例不一样cm_ctl query –Cvdcd 实例目录pg_controldata ./可以通过这样查看最近数据库同步在做什么操作cd 实例目录cd pg_xlogpg_xlogdump –z 文件名补充一下可能会用到的命令--查看进程启动时间ps –eo lstart,etime,cmd | grep gaussdb--沙箱外看ioiostat –xdmt 2