GTM，全称Global Transaction Manager，即全局事务管理器，负责全局事务号的分发，事务提交时间戳的分发以及全局事务运行状态的登记，作为事务管理中的重要模块，为支持事务一致性提供必要的保证。事务开始和提交时与GTM进行交互获取必要的全局事务信息，包括事务ID，全局时间戳，全局快照等等。与其他模块一个很重要的不同点就是，为了保证一致性和事务标识全局唯一，集群中只要一个主GTM，即只有一个GTM真正参与事务（不过GTM和DN一样是高可用的，支持一主多备或主备从）。使用GTM来进行事务管理，一个很重要的问题就是会出现单点瓶颈，因为所有需要获取事务唯一标识的事务都需要连接GTM，获取全局快照的时候也都需要连接GTM，在大并发的情况下频繁的交互导致大量的网络通信和锁等待，从而限制了集群性能。在老的GTM模式下，虽然通过将活跃事务链表替换为CSN来减少了通信量，但是由于仍采用全局事务id的策略，所以每个活跃事务仍要在GTM注册槽位，GTM负责管理和分发全局事务id，这导致当并发量大的时候，GTM容易成为单点瓶颈，主要体现在以下两个方面：（1）在一个事务的执行流程中，CN会与GTM进行多次交互，如事务开始时在GTM注册槽位、获取快照时从GTM获取全局事务id、事务结束时向GTM提交并移除槽位等，这些频繁的交互会带来大量的网络通信和等待；（2）当并发量超过槽位数限制时，会由于槽位不够影响业务正常进行。由此可见，其影响性能的主要原因在于GTM的协调太强，通过对全局事务id的管控，虽然保证了事务的一致性，但是也限制了事务处理的效率。与GTM模式相反，GTM-FREE模式下CN/DN不与GTM交互，通过CN/DN分别维护本地事务id来保证事务系统的正常运行。这种模式下由于缺少全局事务id以及GTM的其他协调（CSN），事务的一致性会受到影响，从而限制了这种模式的适用范围。综上，现有的两种模式在效率和一致性要求上并没有达到一个很好的平衡，而影响这种平衡的主要因素在与“协调”，协调带来更多一致性的保障，但是却降低了性能。由此，一个好的模式应该是在尽可能少的协调的情况下，达到尽可能高的性能，这也是本章介绍的GTM-LITE模式GTM-LITE的主要目标就是在消除GTM瓶颈影响的同时，尽可能通过更少的信息交互，利用它来协调好事务的并发，从而保证事务一致性的同时提升性能。为此，GTM-LITE的主要设计思路包含以下4点：（1）本地事务id取代全局事务id。GTM不再分配全局唯一的事务id，每个CN/DN节点用本地产生的事务id，保证节点内事务id不会重复；对于跨节点的事务，由全局唯一的gid标识符前缀来保证写一致性，由全局唯一的csn号来保证事务读的一致性。（2）GTM不再维护槽位信息，仅在事务提交时下发全局唯一的csn序列号。GTM下发的全局csn是一个递增的uint64值。这一设计消除了BEGIN, GetNewTransactionId同GTM的交互。进一步，如果事务在GTM提交时失败，可以retry重新获取最新的csn，减少网络故障对系统造成的影响。（3）本地维护多版本过期脏元组的回收，并引入Snapshot Invalid机制，保证全局事务的一致性。由于舍弃全局事务id，无法直接根据RecentGlobalXmin确定需要清理的脏元组，所以需要利用全局csn来计算RecentGlobalXmin，从而实现GTM架构代码的有效复用。（4）引入prepared array链表对单节点事务可见性判断进行优化。对于单节点的读事务，不再向GTM申请快照，而是使用本地的快照+prepared array链表来进行可见性判断，这种方式在保证读外部一致性的前提下，尽可能的减少同GTM的交互。基本判断方法为：对于csn<本地快照csn的事务以及本地prepared（在prepared array中）且最终提交的事务，均可见。

 GaussDB技术解读——分布式优化器  分布式数据库场景下表分布在各个节点上，数据的本地性Data Locality是分布式优化器中生成执行计划时重点考虑的因素，基于Share Nothing的分布式数据库中有一个很关键概念就是“移动数据不如移动计算”，之所以有数据本地性就是因为数据在网络中传输会有不小的I/O消耗，网络的overhead通常情况下会大于本地的计算，因此分布式数据库优化的一个重要的原则就是尽量减少这个网络I/O消耗就能够提升效率。例如有以下例子一个聚集查询的例子：  表信息：- T1: distribute By HASH(c1)执行查询：- select sum(c1), c2 from t1 group by c2 1 由于表T1的分布列为c1但实际上要按照c2为键值进行聚集，对聚集列进行重分布是不可避免的一步操作，因此先做聚集还是先做数据迁移重分布就成为分布式优化器的一个选项，针对这一情况可以有以下两种分布式执行计划选择：  说明：  （1）执行计划A未考虑Data Locality的优化按照聚集的逻辑直接从扫描输出的100m元组进行重分布操作，造成大量的数据传输和网络资源消耗。  （2）执行计划B考虑Data Locality的优化，把AGG算子分解成2次AGG，其中第一次AGG在本地执行对原始数据进行缩减然后再通过网络重分布进入第二次AGG，虽说执行计划B相比A多了1个AGG算子，尽管计算的总量未发生变化但是节省了大量的网络IO操作，端到端提升了查询性能。  表关联也是类似的原理，如果当join列与分布列不一致时，需要网络stream节点算子对数据进行重分布或者复制确保查询执行的语义正确。 

应用场景 通过MERGE INTO语句，将目标表和源表中数据针对关联条件进行匹配，若关联条件匹配时对目标表进行UPDATE，无法匹配时对目标表执行INSERT。此语法可以很方便地用来合并执行UPDATE和INSERT，避免多次执行。语法如下： MERGE INTO table_name [ [ AS ] alias ]USING { { table_name | view_name } | subquery } [ [ AS ] alias ]ON ( condition )[ WHEN MATCHED THEN UPDATE SET { column_name = { expression | DEFAULT } | ( column_name [, ...] ) = ( { expression | DEFAULT } [, ...] ) } [, ...] [ WHERE condition ]][ WHEN NOT MATCHED THEN INSERT { DEFAULT VALUES | [ ( column_name [, ...] ) ] VALUES ( { expression | DEFAULT } [, ...] ) [, ...] [ WHERE condition ] }];其中，table_name 指的是更新的表，using()里边的指的是数据来源表/视图/子查询结果集，condition指的是连接条件。 如果满足连接条件，则更新字段；如果连接条件不满足，则停止更新进行插入。 举例 table_a : 计划金额表 table_b : 调整表 table_c : 调整金额表 MERGE INTO table_a t1 USING ( SELECT m.plan_id, m.adjust_money + d.adjust_money adjust_money, m.all_money + d.adjust_money all_money FROM table_a m LEFT JOIN table_b a ON m.card_id = a.card_id LEFT JOIN table_c d ON a.adjust_id = d.adjust_id WHERE a.adjust_id = 5 AND a.comp_code = '100101' AND m.year = d.year) t2 ON (t1.plan_id = t2.plan_id)WHEN matched THEN UPDATESET t1.adjust_money = t2.adjust_money, t1.all_money = t2.all_money要根据调整id，将调整金额累加到计划金额表中。一次更新当年12个月。 

1）详单查询GaussDB 200具备PB级数据负载能力，通过内存分析技术满足海量数据边入库边查询要求，适用于安全、电信、金融、物联网等行业的详单查询业务。 从这点可以看出，这一功能的实现是发挥了GaussDB 200在OLTP方面能力。2）数据仓库 GaussDB 200具备百TB级数据支撑能力，可以高效处理百亿行多表连接查询，适用于操作数据存储ODS（Operational Data Store）、企业数据仓库EDW（Enterprise Data Warehouse）、数据集市DM（Data Mart）。 以上这一功能体现了GaussDB 200在OLAP方面的能力。3）混合负载 GaussDB 200基于海量数据查询统计分析能力与事务处理能力，行列混存技术同时满足联机事务处理OLTP（On-Line Transaction Processing）与联机分析处理OLAP（Online Analytical Processing）混合负载场景。4）大数据分析 支持结构化数据PB级分析能力。分布式并行数据库集群满足PB级结构化大数据的分析能力。

1、全球首款AI-Native数据库。 AI原生数据库是GaussDB的主要特点之一。华为将AI引擎内置到GaussDB全系产品中，使其具备一定的自运维、自管理、自调优、故障自诊断和自愈的能力。华为也希望把在芯片、算法上面的优势，集中体现到数据库上来。 客观来讲，其实对于在数据库中植入AI技术，并不是一个新鲜做法。Oracle在几个版本之前就开始就植入了AI技术，开启了“Autonomous”之旅。2、异构计算支持X86、ARM、GPU、NPU。 这个也是Gauss数据库与其他数据库比较大的不同。目前主流的数据库产品，包括OracleDB、MySQL、SQL Server等，基本都是支持X86架构。我们认为，华为数据库对于异构计算的支持，可能是为该数据库未来向更多计算场景的应用做准备。我们知道，5G带来计算场景的变革或将更大。

华为GaussDB数据库包括：事务性（OLTP）数据库、分析型（OLAP）数据库和混合负载（HTAP）数据库。这里需要解释下OLTP、OLAP、HTAP之间的区别，这也是数据库最基本的内容。据库系统一般分为两种类型：一种是面向前台应用的，应用比较简单，但是重吞吐和高并发的OLTP类型；一种是重计算的，对大数据集进行统计分析的OLAP类型。OLTP：联机事务处理OLTP数据在系统中产生； 基于交易的处理系统（Transcation-Based）；每次交易牵涉的数据量很小； 对响应时间要求非常高； 用户数量非常庞大，主要是操作人员； 数据库的各种操作主要基于索引进行。OLAP：联机分析处理OLAP本身不产生数据，其基础数据来源于生产系统中的操作数据（OperationalData）；基于查询的分析系统； 复杂查询经常使用多表联结、全表扫描等，牵涉的数量往往十分庞大； 响应时间与具体查询有很大关系； 用户数量相对较小，其用户主要是业务人员与管理人员； 由于业务问题不固定，数据库的各种操作不能完全基于索引进行。

华为 GaussDB 是一个企业级 AI-Native 分布式数据库。GaussDB 采用 MPP(Massive Parallel Processing)架构，支持行存储与列存储，提供 PB(Petabyte，2 的 50 次方字节)级别数据量的处理能力。  华为Gauss数据库是全球首款AI-Native数据库，能够同时支持X86、ARM、GPU、NPU 等异构计算。数据库演进历史GaussDB：分布式&AI原生。华为GaussDB是一个企业级AI-Native分布式数据库。GaussDB采用MPP(Massive Parallel Processing)架构，支持行存储与列存储，提供PB(Petabyte，2的50次方字节)级别数据量的处理能力。可以为超大规模数据管理提供高性价比的通用计算平台，也可用于支撑各类数据仓库系统、BI(Business Intelligence)系统和决策支持系统，为上层应用的决策分析提供服务。华为GaussDB将AI能力植入到数据库内核的架构和算法中，为用户提供更高性能、更高可用、更多算力支持的分布式数据库。

采用spark将计算好的数据写入高斯数据库，提示invalid input syntax for type oid:"xxxxx"。导致部分数据无法写入这个异常具体怎么回事，有大神能够帮忙解释一下吗？

GaussDB 200 8.1.1.5版本集群，如何加速VACUUM FULL ANALYZE 系统表脏页释放？set那些参数有效果？80节点集群是否有办法控制在半小时内？

线下DWS 8.1.1.5版本，VACUUM FULL 系统表时如果存在业务语句执行，除了会出现锁等待是否还有其他影响？业务数据不一致？元数据不一致？

上图为华为数据库 GaussDB与openGauss对比。仅供参考。作者：墨天轮通信员

10月13日，第一次线下讲解openGauss数据库相关的知识，并对去年的真题做了解析，如果有讲的不好，请指出。通过网盘分享的文件：Adovate7 链接: https://pan.baidu.com/s/1ElKV0WUXcG7E5Qm9L0Hc9g?pwd=6aqe 提取码: 6aqe

环境说明当前GaussDB部署主要为轻量化部署（TPOPS）和GaussDBInstaller（这个很重要，小本本记下来）本文采用TPOPS部署模式进行说明本文部署模式为：分布式三节点本文数据库内核版本为：503.1.0启动ssl并配置ssl适用范围注：当前演示信息ssl证书采用数据库预置证书使用Ruby用户登录数据库任意主机开启SSL认证模式gs_guc set -Z coordinator -D /var/chroot/var/lib/engine/data1/cn -c "ssl=on"注意：这里的-D指定路径信息，在TPOPS部署模式下为：/var/chroot/var/lib/engine/data1/cn，在GaussDBInstaller部署模式下该路径在install_cluster.conf中定义的cn_dir变量配置客户端接入认证gs_guc reload -Z coordinator -D /var/chroot/var/lib/engine/data1/cn -h "hostssl all all 10.10.10.0/24 cert"注：可根据实际需要设置ssl连接的网段信息，所有连接均需要ssl的话请将IP地址替换为0.0.0.0/0配置ssl相关的证书参数gs_guc set -Z coordinator -D /var/chroot/var/lib/engine/data1/cn -c "ssl_cert_file='server.crt'" gs_guc set -Z coordinator -D /var/chroot/var/lib/engine/data1/cn -c "ssl_key_file='server.key'" gs_guc set -Z coordinator -D /var/chroot/var/lib/engine/data1/cn -c "'ssl_ca_file='cacert.pem'"重启数据库tpops部署请前往控制台点击重启，GaussDBInstaller部署则使用gs_om -t stop && gs_om -t start本文作者：lalallalal

执行安装集群报错：集群定义已保存，但创建集群未完成，请修改后重试。详细错误信息如下：Failed to verify nodes because Failed to verify oms nodes. because they are null or not avaliable.日志附件已经上传

环境说明当前GaussDB部署主要为轻量化部署（TPOPS）和GaussDBInstaller（这个很重要，小本本记下来）本文采用TPOPS部署模式进行说明本文部署模式为：分布式三节点本文数据库内核版本为：503.1.0启动ssl并配置ssl适用范围注：当前演示信息ssl证书采用数据库预置证书使用Ruby用户登录数据库任意主机开启SSL认证模式gs_guc set -Z coordinator -D /var/chroot/var/lib/engine/data1/cn -c "ssl=on"注意：这里的-D指定路径信息，在TPOPS部署模式下为：/var/chroot/var/lib/engine/data1/cn，在GaussDBInstaller部署模式下该路径在install_cluster.conf中定义的cn_dir变量配置客户端接入认证gs_guc reload -Z coordinator -D /var/chroot/var/lib/engine/data1/cn -h "hostssl all all 10.10.10.0/24 cert"注：可根据实际需要设置ssl连接的网段信息，所有连接均需要ssl的话请将IP地址替换为0.0.0.0/0配置ssl相关的证书参数gs_guc set -Z coordinator -D /var/chroot/var/lib/engine/data1/cn -c "ssl_cert_file='server.crt'" gs_guc set -Z coordinator -D /var/chroot/var/lib/engine/data1/cn -c "ssl_key_file='server.key'" gs_guc set -Z coordinator -D /var/chroot/var/lib/engine/data1/cn -c "'ssl_ca_file='cacert.pem'"重启数据库tpops部署请前往控制台点击重启，GaussDBInstaller部署则使用gs_om -t stop && gs_om -t start