全文检索是在互联网场景下应用非常广泛的特性，搜索引擎、站内搜索、电商搜索等场景下都会使用到，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

GaussDB支持自定义聚合函数能在分布式版本运行吗

一、背景在使用数据库中，创建外表从其他集群导数时，提示报错ERROR:cooperation analysis: column inf ormation does not match.这其实是个非常明显的错误，但每一次排查老是记不住原因，写个小笔记记录一下。二、报错语句报错语句为一条简单查询，因外表特性实际为数据插入select * from aa.bb；该外表创建语句见下面CREATE foreign TABLE aa.bblike aa.cc）server syndata_serveroptions(schema_name 'syndata',table_name 'cc',encoding 'utf8')distributeby roundrobin;三、分析排查原因：首先查看本端外表结构，后查看远端内表结构，发现结构基本一致，但外表比内表多了一行。原因是客户在建立完外表之后对外表进行了更新修改，但他自己不记得了。本来想放一张对比，但是是客户环境图片，这里就不放了。总而言之这个错误其实提示非常明显，客户有较强意愿认为自己无错时，还是要跟客户要一下报错sql，自己重现一遍，根据报错的语句排查两表结构。

为什么需要每次执行source ${BIGDATA_HOME}/mppdb/.mppdbgs_profile命令启动环境变量。直接写到.bashrc文件里面不行吗？有什么影响和弊端？

Gaussdb中100万条数据（50列）大概能占用多大空间？

HDC.2024大会可以了解各行各业的新技术和未来发展趋势，倾听业界各行各业大咖的精彩演讲，大家分享观会体会和心得？欢迎表达出来

1. 存在锁争抢在cn上执行select * from pg_stat_activity where query like '%vacuum%';找到vacuum full的pid查看该线程的等待状态，如果等待状态是acquire lock，说明存在锁等待select * from pg_thread_wait_status where tid = 139878309295872;在pg_locks中查询vacuum full在等哪个锁select * from pg_locks where pid = 139878309295872 and granted = 'f';查看持有该锁的线程select * from pg_locks where relation = 544793 and granted = 't';查看该线程对应的语句select query from pg_stat_activity where pid = 139877539612416;根据语句判断是否可以杀掉该语句继续做vacuum full，或者另外找时间窗做vacuum full。2. 存在IO/网络问题导致事务无法提交执行一个简单的create table语句，如果create table语句执行也很慢，说明存在IO/网络问题，进一步排查IO和网络。3. 系统表过大导致vacuum full慢vacuum full任意一张表时，都会扫描pg_class、pg_partition、pg_proc三张系统表，当这三个系统表过大时，也会导致vacuum full较慢。可以在排除IO/网络问题（即create table语句不慢）后，对空表做vacuum full，观察执行速度，如果空表做vacuum full也比较慢，则说明就是这三张系统表较大导致vacuum full任意表都慢。4. 排除以上场景之后，可以查看表定义中是否使用了PCK当存在PCK时，表做vacuum full时会进行全排序，此时如果表较大或psort_work_mem设置较小，就会导致PCK排序时产生下盘，进行外排，效率急剧下降。可以通过调大psort_work_mem进行规避。

1、vacuum只是将删除状态的空间释放掉，转换到能够重新使用的状态，但是对于系统来说该数据块的空闲空间并没有反应到系统的元数据中，并不进行空间合并。而vacuum full实质上是重建了整个表，以达到空间合并的效果。2、vacuum执行过程中对表加4级锁，不会影响表的增删改查，而vacuum full对表加8级锁，执行过程中表无法访问。3、vacuum对列存表无效。建临时表：数据库会新建一个临时表，临时表继承老表所有属性。这个阶段会对pg_class申请“RowExclusiveLock”锁，因为需要插入记录。拷贝数据：将原来的数据copy到temp表中。对临时表，老表以及索引都以“AccessExclusiveLock”模式打开。另外对于toast，只是lock，不打开。在这个过程中完成Dead Tuple的清理。重建索引：是在交换之后完成的，重建索引时，会更新一些统计信息。对表申请“ShareLock”锁。删除临时表：索引重建完成后，将带有老物理文件的新临时表进行删除。