在gsql命令方式中，使用\copy导入CSV文件的任意几列数据，如何实现？请教各位老师。

GaussDB是一款华为公司开发的关系型数据库管理系统（RDBMS），提供了多种数据类型用于存储和处理不同类型的数据。以下是GaussDB常见的数据类型：1、GaussDB常见的数据类型 1.1、数值型（Numeric Types）：整型（Integer）：INT小数型（Decimal）：DECIMAL 1 21.2、字符型（Character Types）：字符串（String）：CHAR、VARCHAR、TEXT、CLOB二进制数据（Binary Data）：BINARY、VARBINARY、BLOB 1 21.3、时间型（Date and Time Types）：日期（Date）：DATE时间（Time）：TIME时间戳（Timestamp）：TIMESTAMP 1 2 31.4、布尔型（Boolean Type）：布尔值（Boolean）：BOOLEAN 11.5、大整数（Big Integer）：大整数（Bigint）：BIGINT 11.6、浮点型（Floating-Point Types）：单精度浮点数（Float）：FLOAT双精度浮点数（Double）：DOUBLE 1 21.7、其他类型：XML：XMLJSON：JSON数组：ARRAY 1 2 3 2、GaussDB常用的DDL语句2.1、创建数据库 CREATE DATABASE database_name WITH OWNER = my_user TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8'; 1 2 3 4 5 6 WITH OWNER：指定数据库的所有者，即拥有该数据库的用户。 TEMPLATE：指定用作新数据库模板的现有数据库。在这个示例中，我们使用 template0 作为模板。 ENCODING：指定数据库的字符集。在这个示例中，我们使用 UTF8 字符集。 LC_COLLATE：指定数据库的排序规则，即字符串比较的规则。在这个示例中，我们使用 en_US.UTF-8 排序规则。 LC_CTYPE：指定数据库的字符分类规则，用于字符的分类和转换。 2.2、删除数据库 DROP DATABASE database_name; 1 2.3、创建表 CREATE TABLE table_name ( column1 datatype, column2 datatype, ... ); 1 2 3 4 5 2.4、修改表 2.4.1、添加列 ALTER TABLE table_name ADD column_name datatype; 1 2.4.2、修改列数据类型 ALTER TABLE table_name ALTER COLUMN column_name TYPE new_datatype; 1 2.4.3、修改列名 ALTER TABLE table_name RENAME COLUMN old_column_name TO new_column_name; 1 2.4.4、删除列 ALTER TABLE table_name DROP COLUMN column_name; 1 2.4.5、修改表名 ALTER TABLE table_name RENAME TO new_table_name; 1 2.5、删除表 DROP TABLE table_name; 1 2.6、创建索引 CREATE INDEX index_name ON table_name (column1, column2, ...); 1 2.7、删除索引 DROP INDEX index_name; 1 2.8、添加表注释 COMMENT ON TABLE table_name IS 'Your comment here'; 1 2.9、添加列注释 COMMENT ON COLUMN table_name.column_name IS 'Your comment here'; ———————————————— 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接：cid:link_0

GaussDB常见调优指南一. Analyze 统计信息解析 前言 适用版本：【8.1.1 及以上】本文简单介绍什么是统计信息、统计信息记录了什么、为什么要收集统计信息、怎么收集统计信息以及什么时候收集统计信息。 WHY：为什么需要统计信息Query 执行流程 词法&语法解析 语义解析 查询重写 查询优化 查询执行CBO 模型 通过代价模型(Cost Model)和统计信息估算每种执行方式的代价，然后选择一种执行代价最优的执行方式。WHAT：都有哪些统计信息 统计信息包括表记录条数、页面数、MCV(高频非 NULL 值)、HISTOGRAM（直方图）、CORRELATION 等。WHERE：统计信息在哪里 统计信息存储在系统表 pg_class 和 pg_statistic 中。HOW：如何生成统计信息 可以通过以下命令手动收集统计信息：ANALYZE [ VERBOSE ] [ table_name [ ( column_name [, ...] ) ] ]; 1 也可以通过配置参数 default_statistics_target 提升统计信息质量，或开启 autoanalyze 自动收集统计信息。WHEN：什么时候收集统计信息 大规模数据变化或查询新增数据时需要收集统计信息。WHO：谁来收集统计信息 建议在业务开发过程中，根据数据变化量和查询特征主动对相关表做 Analyze。总结 本文简单介绍了统计信息的含义及其在性能调优中的重要作用，详细说明了统计信息的内容、存储位置以及如何有效收集统计信息的方法。二. Explain 分布式计划解析 前言 适用版本：【8.1.1 及以上】本文介绍如何详细解读计划以及计划的执行过程，从中发现可能存在的性能瓶颈点及其产生的原因。执行算子介绍 常用的执行算子包括：扫描算子：SeqScan, Indexscan, IndexOnlyScan, BitmapScan, SubqueryScan, 等。 连接算子：NestLoop, MergeJoin, HashJoin。 物化算子：Material, Sort, Group, Agg, WindowAgg, Unique, Hash。 控制类算子：ModifyTable, Append, MergeAppend, RecursiveUnion, BitmapAnd, BitmapOr, 等。 Stream 算子：Gather Stream, Redistribute Stream, Broadcast Stream。 Explain 用法 使用 explain 命令可以查看优化器为每个查询生成的具体执行计划。 示例计划解读 通过具体示例说明不同类型的计划和算子的资源消耗、耗时等信息。总结 在调优过程中，熟练使用 Explain 并能分析各部分数据结果是非常重要的。三. 性能调优总体策略详解 前言 适用版本：【8.1.1 及以上】性能调优是应用迁移或开发过程中的关键步骤，需要贯穿于整个项目实施过程中。GaussDB(DWS)执行架构及说明 GaussDB(DWS)是典型的 share-nothing 架构，主要由 CN（Coordinator）和 DN（DataNode）组成。整体调优思路 调优过程包括数据模型建模、集群部署、表结构设计、SQL 语句优化等多个方面。性能瓶颈诊断 GaussDB(DWS)提供了丰富的计划信息显示工具 Explain 和动态执行信息分析工具 Top SQL，用于诊断性能瓶颈。性能原因分析 性能原因分析需要对数据库的执行实现原理有基本了解。GaussDB(DWS)基于代价生成计划，统计信息是计划准确的前提。调优项实施 调优项包括系统级调优和语句级调优。四. 性能调优之坏味道 SQL 识别 前言 适用版本：【8.1.1 及以上】本文介绍如何识别和优化坏味道 SQL。简单实例 通过具体实例说明坏味道 SQL 的识别方法。识别 SQL 坏味道之自诊断视图 通过自诊断视图识别 SQL 坏味道。发现正在运行的 SQL 的坏味道 利用 Top SQL 工具发现正在运行的 SQL 的坏味道。总结 本文介绍了如何识别和优化坏味道 SQL，以提高数据库性能。五. 性能调优之好味道表定义 前言 适用版本：【8.1.1 及以上】本文介绍如何定义表结构以优化性能。存储方式设计 选择合适的存储方式以提高性能。数据分布方式设计 设计合理的数据分布方式以优化性能。分布列设计 合理设计分布列以提高查询性能。表分区设计 通过表分区设计优化性能。字段设计 合理设计字段以提高性能。约束设计 通过设计约束提高数据完整性和查询性能。总结 本文介绍了如何通过合理设计表结构来优化性能。六. 性能调优之 SQL 改写 前言 适用版本：【8.1.1 及以上】本文介绍如何通过改写 SQL 提高性能。不支持下推导致的坏味道 识别并优化不支持下推的 SQL。不支持重分布导致的坏味道 识别并优化不支持重分布的 SQL。数据类型转换导致的坏味道 避免不必要的数据类型转换。全局性操作导致的坏味道 优化全局性操作以提高性能。NestLoop 类低效运算导致的坏味道 避免使用低效的 NestLoop 连接。冗余操作导致的坏味道 去除冗余操作以优化性能。总结 本文介绍了如何通过改写 SQL 提高性能。七. 性能调优之路径干预 前言 适用版本：【8.1.1 及以上】本文介绍如何通过路径干预提高性能。cost 模型选择 选择合适的 cost 模型以优化性能。Scan 方式的选择 选择合适的扫描方式以提高性能。关联方式的选择 选择合适的关联方式以优化性能。Stream 方式的选择 选择合适的 Stream 方式以优化性能。总结 本文介绍了如何通过路径干预提高性能。 ———————————————— 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接：cid:link_0

用户接口层在用户接口层，实现SQL-like语法，提供Create Model、Predict等关键字，支持AI算法训练和预测。当前支持的AI算法包括：GD（梯度下降法）、KMeans（聚类）、XGBoost、决策树等。查询优化层查询优化层提供AI训练执行计划和AI预测执行计划，该计划依据内部统计信息和AI算子调用关系，生成相应执行计划。可以把AI算子看做执行器中的计算单元，例如Join、AGG等，AI算子执行代价基于执行逻辑、获取的数据行数、算法复杂度共同决定。同时在执行计划生成后，可通过Explain语句查看详细的执行开销，分析路径选型的正确性。AI底座和执行层在AI底座中，提供超参优化能力，即用户不指定超参数或者指定超参数的范围，自动选择适合的参数，该功能极大提升用户使用的效率，同时达到最佳的训练性能。在执行器中，提供多种AI算子，例如GD算子可支持逻辑回归、分类；KMeans算子支持聚类。在每个算子实现过程中，遵循执行器算子实现逻辑，下层对接Scan算子，上次提供AI算子的训练或推理结果。在训练完成后，训练模型将实时保存到系统表中，用户可以查询gs_model_warehouse系统表来获取模型信息。存储层在存储层，DB4AI提供数据集管理功能，即用户可以抽取某个表或多个表中的列信息，组成一个数据集，用于后续模型训练。数据集管理功能类似git模式提供多版本管理，目的是保障训练数据的一致性。同时在这过程中，可通过特征处理和数据清洗保障数据的可用性。同时对已生成的模型进行管理，包括模型评估、定期模型验证、模型导入、模型导出等能力，在验证模型失效后，模型漂移功能可以进行模型刷新，保障模型可用。异构计算层DB4AI框架支持异构计算层，实现CPU和AI算力的统一调度，满足数据库语句执行和AI训练的完美结合。在实现方面，CPU算力，特指ARM及X86芯片，可用于基础机器学习算子调用及并行计算执行；AI算子，例如昇腾及GPU芯片，可用于重度分析算子（Join、AGG）及深度学习算子使用，加速大数据及多层网络场景下计算需求。 ———————————————— 版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 原文链接：cid:link_0

智能关键技术一：自治运维系统 GaussDB 自治运维系统“DBMind”的整体系统框图如下图所示，包含四个维度：数据采集层数据采集层主要功能实现指标数据采集，采集频率分为秒级采集和分钟级采集。其中秒级采集包括操作系统资源信息采集和数据库实例信息采集，例如操作系统层面CPU、内存、IO读写、网络资源信息采集，数据库实例状态、数据库内关键指标（内存、连接数、TPS、QPS、读写频率等）；分钟级采集包括审计日志采集、数据库日志采集和全量SQL流水采集。DBMind数据平台提供Agent进程用于采集上述指标；若客户系统配置普罗米修斯进行信息采集，DBMind提供openGauss-exporter，内置数据库多维度指标采集以及二次数据计算，实现与用户既有普罗米修斯平台对接。数据库采集端程序需要部署在同数据库物理机节点，数据库多节点集群环境中，每个物理节点部署一个Agent采集端（或者普罗米修斯采集端）。数据库采集端程序通常占用资源很少，通过配置文件可以制定不同指标采集频率，以免占用资源影响数据库业务正常运行。数据计算层数据计算层提供数据存储、数据分析及元数据管理能力。其中数据存储用于接收来自数据采集层发生来的数据，存储数据源可以是多种维度或者类型，包括普罗米修斯、时序数据库（OpenTSDB）、MongoDB、SQLite等，DBMind内置对接接口，AI模块与存储数据源的交互，获取数据并进行处理。DBMind默认提供SQLite数据库，方便普通开发者来使用AI自治功能；在企业业务中，存储层设计要复杂的多，可以使用多个开源组件组合使用，例如普罗米修斯+时序数据库，或者kafka+时序数据库等多种方案。使用nginx进行业务分流，mgrsrv服务对数据进行初步处理后，将数据写入关系型数据库。基于可靠性考虑，对于三个组件，分别加入备机进行可靠性保护。若企业业务处理上万业务节点的数据，图2方案无法满足客户业务诉求。故在方案设计时，需要引入分布式消息中间件、数据库中间件（DDM），同时因为nginx挂载节点有上限，需要对mgrsvr进行分区管理。consumer服务可以和mgrsvr部署在同一个节点上，mq集合代表分布式消息中间件，通常可以采用开源软件rocketmq或者rabbitmq，引入消息中间件目的是降低目标数据库的压力。DDM是华为云的数据库中间件，若采用开源软件，也可使用mycat或者dble等，可进行存储大规模被采集的数据。在整体业务角度，纵向通过分层设计，横向通过分区设计，保证全部业务可通过管控层完成数据处理。在数据计算层除了时序存储数据库外，还可以设计其他存储单元，例如算法模型库和故障规则库。其中算法模型库存储自治管理服务生成的AI模型，例如参数推荐训练模型；在算法模型库中，可以存储传统机器学习（例如监督学习）模型、强化学习模型。故障规则库是记录数据库常见故障案例，将这些案例通过拆解和分析，生成规则引擎。自治服务层包含三个主要部分：SQL诊断和调优、自治安全、数据库智能运维。其中SQL诊断和调优提供多种SQL治理和调优能力，包括慢SQL发现、SQL表现评估、智能索引推荐、智能查询重写等服务。自治安全通过AI技术实现敏感信息发觉、SQL注入检测和异常行为分析。数据库智能运维功能实现在数据库系统、OS系统和数据库集群层面的运维和调优，其中数据库系统服务包括数据库参数智能推荐、智能巡检、数据库分布键推荐和智能业务调度；在操作系统层面，实现慢盘检测和恢复、网络丢包检测；在数据库集群层面，基于故障或者负载需求，提供自动扩缩容、异常节点修复服务。DBMind提供监控展示层，通过WEB形式，方便用户直观感受运维管理带来的遍历。在展示界面方面，集成Grafana实现实施数据或指标的展示，同时AI趋势预测，给出后续时段的数据走向。告警界面展示系统中可能存在的问题或故障，分为致命、严重、一般，界面中只显示致命问题。为方便用户系统观察集群状态，提供健康指数报告和详细综合报告。健康指数报告给出当前系统的健康评分等级，默认80分以上属于运行健康状况，小于60分则存在严重隐患，急需修复。综合报告详细描述系统各维度信息，包括集群状态、负载运行情况、常见数据库指标项信息。

本文作者： 向日葵执行计划 以如下SQL语句为例： select cjxh, count(1) from dwcjk group by cjxh; 执行EXPLAIN的输出为： 执行计划字段解读（横向）： ● id：执行算子节点编号。 ● operation：具体的执行节点算子名称。 Vector前缀的算子是指向量化执行引擎算子，一般出现含有列存表的Query中。 Streaming是一个特殊的算子，它实现了分布式架构的核心数据shuffle功能， Streaming共有三种形态，分别对应了分布式结构下不同的数据shuffle功能： – Streaming (type: GATHER)：作用是coordinator从DN收集数据。 – Streaming(type: REDISTRIBUTE)：作用是DN根据选定的列把数据重分布到 所有的DN。 – Streaming(type: BROADCAST)：作用是把当前DN的数据广播给其他所有的 DN ● E-rows：每个算子估算的输出行数。 ● E-memory：DN上每个算子估算的内存使用量，只有DN上执行的算子会显示。某 些场景会在估算的内存使用量后使用括号显示该算子在内存资源充足下可以自动 扩展的内存上限。 ● E-width：每个算子输出元组的估算宽度。 ● E-costs：每个算子估算的执行代价。 – E-costs是优化器根据成本参数定义的单位来衡量的，习惯上以磁盘页面抓取 为1个单位， 其它开销参数将参照它来设置。 – 每个节点的开销（E-costs值）包括它的所有子节点的开销。 – 开销只反映了优化器关心的东西，并没有把结果行传递给客户端的时间考虑 进去。虽然这个时间可能在实际的总时间里占据相当重要的分量，但是被优 化器忽略了，因为它无法通过修改规划来改变。 执行计划层级解读（纵向）：第一层：CStore Scan on dwcjk 表扫描算子，用CStore Scan的方式扫描表dwcjk。这一层的作用是把表dwcjk的数 据从buffer或者磁盘上读上来输送给上层节点参与计算。 第二层：Vector Hash Aggregate 聚合算子，作用是把下层计算输送上来的算子做聚合操作(group by)。 第三层：Vector Streaming (type: GATHER) Shuffle算子，此处GATHER类型的Shuffle算子作用是把数据从DN汇聚到CN。 第四层：Row Adapter 存储格式转化算子，主要作用是把内存中列式格式数据转为行式数据，以便客户 端展示。 需要注意的是最顶层算子为Data Node Scan时，需要设置 enable_fast_query_shipping为off才能看到具体的执行计划，如下面这个计划： openGauss=# explain select cjxh, count(1) from dwcjk group by cjxh; QUERY PLAN Data Node Scan (cost=0.00…0.00 rows=0 width=0) Node/s: All datanodes (2 rows) 设置enable_fast_query_shipping参数之后，执行计划显示如下： 图片.png 执行计划中的关键字说明：表访问方式 – Seq Scan 全表顺序扫描。 – Index Scan 优化器决定使用两步的规划：最底层的规划节点访问一个索引，找出匹配索 引条件的行的位置，然后上层规划节点真实地从表中抓取出那些行。独立地 抓取数据行比顺序地读取它们的开销高很多，但是因为并非所有表的页面都 被访问了，这么做实际上仍然比一次顺序扫描开销要少。使用两层规划的原 因是，上层规划节点在读取索引标识出来的行位置之前，会先将它们按照物 理位置排序，这样可以最小化独立抓取的开销。 如果在WHERE里面使用的好几个字段上都有索引，那么优化器可能会使用索 引的AND或OR的组合。但是这么做要求访问两个索引，因此与只使用一个索 引，而把另外一个条件只当作过滤器相比，这个方法未必是更优。 索引扫描可以分为以下几类，他们之间的差异在于索引的排序机制。 ▪ Bitmap Index Scan 使用位图索引抓取数据页。 ▪ Index Scan using index_name 使用简单索引搜索，该方式表的数据行是以索引顺序抓取的，这样就令 读取它们的开销更大，但是这里的行少得可怜，因此对行位置的额外排 序并不值得。最常见的就是看到这种规划类型只抓取一行，以及那些要 求ORDER BY条件匹配索引顺序的查询。因为那时候没有多余的排序步 骤是必要的以满足ORDER BY。 表连接方式 – Nested Loop 嵌套循环，适用于被连接的数据子集较小的查询。在嵌套循环中，外表驱动 内表，外表返回的每一行都要在内表中检索找到它匹配的行，因此整个查询 返回的结果集不能太大（不能大于10000），要把返回子集较小的表作为外 表，而且在内表的连接字段上建议要有索引。 – (Sonic) Hash Join 哈希连接，适用于数据量大的表的连接方式。优化器使用两个表中较小的 表，利用连接键在内存中建立hash表，然后扫描较大的表并探测散列，找到 与散列匹配的行。Sonic和非Sonic的Hash Join的区别在于所使用hash表结构 不同，不影响执行的结果集。 – Merge Join 归并连接，通常情况下执行性能差于哈希连接。如果源数据已经被排序过， 在执行融合连接时，并不需要再排序，此时融合连接的性能优于哈希连接。 运算符 – sort 对结果集进行排序。 – filter EXPLAIN输出显示WHERE子句当作一个"filter"条件附属于顺序扫描计划节 点。这意味着规划节点为它扫描的每一行检查该条件，并且只输出符合条件 的行。预计的输出行数降低了，因为有WHERE子句。不过，扫描仍将必须访 问所有 10000 行，因此开销没有降低；实际上它还增加了一些（确切的说， 通过10000 * cpu_operator_cost）以反映检查WHERE条件的额外CPU时间。 – LIMIT LIMIT限定了执行结果的输出记录数。如果增加了LIMIT，那么不是所有的行 都会被检索到。

问题描述 服务器卡顿的厉害，xshell工具不能访问，联系服务器管理员后，其对服务器进行了重启，恢复访问后查看集群状态显示状态异常，出现了CN服务异常告警，查询集群状态， CN组件状态为Deleted。 详情如下：--查看集群状态 [omm@node01 ~]$ cm_ctl query -Cvipd [ CMServer State ]node node_ip instance state1 192.168.30.51 192.168.30.51 1 /gaussdb/cluster/data/cm/cm_server Primary 2 192.168.30.52 192.168.30.52 2 /gaussdb/cluster/data/cm/cm_server Standby 3 192.168.30.53 192.168.30.53 3 /gaussdb/cluster/data/cm/cm_server Standby[ ETCD State ]node node_ip instance state1 192.168.30.51 192.168.30.51 7001 /gaussdb/cluster/data/etcd StateFollower 2 192.168.30.52 192.168.30.52 7002 /gaussdb/cluster/data/etcd StateFollower 3 192.168.30.53 192.168.30.53 7003 /gaussdb/cluster/data/etcd StateLeader[ Cluster State ]cluster_state : Degraded 降级 redistributing : No balanced : No current_az : AZ_ALL[ Coordinator State ]node node_ip instance state1 192.168.30.51 192.168.30.51 5001 8000 /gaussdb/cluster/data/cn Deleted 2 192.168.30.52 192.168.30.52 5002 8000 /gaussdb/cluster/data/cn Normal 3 192.168.30.53 192.168.30.53 5003 8000 /gaussdb/cluster/data/cn Deleted[ Central Coordinator State ]node node_ip instance state2 192.168.30.52 192.168.30.52 5002 /gaussdb/cluster/data/cn Normal[ GTM State ]node node_ip instance state sync_state1 192.168.30.51 192.168.30.51 1001 /gaussdb/cluster/data/gtm P Primary Connection ok Sync 2 192.168.30.52 192.168.30.52 1002 /gaussdb/cluster/data/gtm S Standby Connection ok Sync 3 192.168.30.53 192.168.30.53 1003 /gaussdb/cluster/data/gtm S Standby Connection ok Sync[ Datanode State ]node node_ip instance state | node node_ip instance state | node node_ip instancestate1 192.168.30.51 192.168.30.51 6001 33100 /gaussdb/cluster/data/dn/dn_6001 P Primary Normal | 2 192.168.30.52 192.168.30.52 6002 33100 /gaussdb/cluster/data/dn/dn_6002 S Standby Normal | 3 192.168.30.53 192.168.30.53 6003 33100 /gaussdb/cluster/data/dn/dn_6003S Standby Normal 2 192.168.30.52 192.168.30.52 6004 33120 /gaussdb/cluster/data/dn/dn_6004 P Standby Normal | 1 192.168.30.51 192.168.30.51 6005 33120 /gaussdb/cluster/data/dn/dn_6005 S Primary Normal | 3 192.168.30.53 192.168.30.53 6006 33120 /gaussdb/cluster/data/dn/dn_6006S Standby Normal 3 192.168.30.53 192.168.30.53 6007 33140 /gaussdb/cluster/data/dn/dn_6007 P Primary Normal | 2 192.168.30.52 192.168.30.52 6008 33140 /gaussdb/cluster/data/dn/dn_6008 S Standby Normal | 1 192.168.30.51 192.168.30.51 6009 33140 /gaussdb/cluster/data/dn/dn_6009S Standby Normal 连接工具也只能访问30.52节点，访问30.51和30.53节点提示如下报错：问题原因 可能原因有以下： 1、 虚拟机重启，断网等故障导致CN被剔除。 2、 CN与主DN断连导致CN被剔除。 3、 CN组件Down导致CN被剔除。 4、 CN组件频繁重启导致CN被剔除。 5、 CN组件被主动剔除。分析过程 build相关日志路径：$GAUSSLOG/bin/gs_ctlcm_agent日志路径：$GAUSSLOG/cm实例日志路径：$GAUSSLOG/gs_log/dn_xxcn日志路径：$GAUSSLOG/gs_log/cn_5001系统日志（仅root用户）：/var/log/message查看磁盘空间 df -h 查看磁盘空间，3个节点磁盘空间剩余还有不少。查询集群状态 登录任一节点，切换到数据库用户，查询集群状态 ，集群状态变成了Cluster State：Degraded，30.51和30.53节点上的CN节点被剔除，状态变成了Deleted。su - omm cm_ctl query -Cvipd 输出如下：[ CMServer State ]node node_ip instance state1 192.168.30.51 192.168.30.51 1 /gaussdb/cluster/data/cm/cm_server Primary 2 192.168.30.52 192.168.30.52 2 /gaussdb/cluster/data/cm/cm_server Standby 3 192.168.30.53 192.168.30.53 3 /gaussdb/cluster/data/cm/cm_server Standby ...... [ Cluster State ]cluster_state : Degraded redistributing : No balanced : No current_az : AZ_ALL[ Coordinator State ]node node_ip instance state1 192.168.30.51 192.168.30.51 5001 8000 /gaussdb/cluster/data/cn Deleted 2 192.168.30.52 192.168.30.52 5002 8000 /gaussdb/cluster/data/cn Normal 3 192.168.30.53 192.168.30.53 5003 8000 /gaussdb/cluster/data/cn Deleted ...... 查看主节点的cm_server日志 登录到CMS主节点查集群状态获取主节点信息 任一个节点登录到CMS主节点(显示节点30.51的实例状态是Primary)，查看cm_server日志。 CMS主节点，可通过查询集群状态获取 。su - omm cm_ctl query -Cv 输出如下：[omm@node01 ~]$ cm_ctl query -Cv [ CMServer State ]node instance state1 192.168.30.51 1 Primary --显示节点30.51的实例状态是Primary 2 192.168.30.52 2 Standby 3 192.168.30.53 3 Standby ...... 查看主节点的cm_server日志 打开对应时间点的cm_server-.log日志，如对应时间点的日志已被压缩，则查看对应的cm_server-*.log.gz日志。su - omm cd $GAUSSLOG/cm/cm_server vi cm_server-2024-08-26_100433-current.log 输出如下：2024-08-26 11:32:58.134 tid=24745 Monitor ASYN LOG: instance(5001) heartbeat timeout, heartbeat:6191, threshold:6 2024-08-26 11:32:58.134 tid=24745 Monitor ASYN LOG: instance(5003) heartbeat timeout, heartbeat:6191, threshold:6 2024-08-26 11:32:58.143 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5) 2024-08-26 11:32:58.567 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5) 2024-08-26 11:32:58.577 tid=24770 STORAGE ASYN LOG: [ReadOnlyActRecordInitState] instance 5001 in the initial state, disk_usage:8, read_only:0, read_only_threshold:85 2024-08-26 11:32:59.144 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5) 2024-08-26 11:32:59.568 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5) 2024-08-26 11:33:00.144 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5) 2024-08-26 11:33:00.569 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5) 2024-08-26 11:33:01.146 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5) 2024-08-26 11:33:01.571 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5) 2024-08-26 11:33:02.146 tid=24759 AGENT_WORKER ASYN LOG: instance(node =1 instanceid =5001) is not in normal status(db_state=18 status=5) 2024-08-26 11:33:02.570 tid=24758 AGENT_WORKER ASYN LOG: instance(node =3 instanceid =5003) is not in normal status(db_state=18 status=5) 场景1：cm_server日志中搜索有关键词cn_down_to_delete=1 在cm_server日志中搜索有关键词cn_down_to_delete=1: ● 如对应时间点存在该信息，则原因为CN组件Down 导致，参考CN状态Down排查详细原因。 ● 确认故障节点是否发生断网。 ● 确认故障节点操作系统是否发生过重启。 ● 故障处理后执行节点修复加回被剔除的CN。 ● 如不涉及继续场景2。场景2：cm_server日志中搜索有关键词isCnDnDisconnected=1 在cm_server日志中搜索有关键词： isCnDnDisconnected=1： ● 如对应时间点存在该信息，则原因为CN组件与主DN断链导致，此时需要排查CN与主DN之间的网络，待网络恢复后，执行节点修复加回被剔除的CN。 ● 如不涉及继续场景3。场景3：cm_server日志中搜索有关键词cmd_disable_cn=1 在cm_server日志中搜索有关键词： cmd_disable_cn=1： ● 如对应时间点存在该信息，则原因为CN组件被主动剔除，确认剔除原因后，后执行节点修复加回被剔除的CN。 ● 如不涉及继续场景4。场景4：cm_server日志中搜索有关键词cnReadonly=1 在cm_server日志中搜索有关键词： cnReadonly=1： ● 如对应时间点存在该信息，则原因为CN组件readonly 导致，参考CN状态为readonly排查详细原因。 ● 如不涉及继续场景5。场景5：cm_server日志中搜索有关键词cn instance restarts within ten minutes is more than 在cm_server日志中搜索有关键词” cn instance restarts within ten minutes is more than”： ● 如对应时间点存在此信息，则原因为CN组件频繁重启导致，出现此种情况，参考 CN 启动失败进一步定位，故障处理后执行节点修复加回被剔除的CN。 ● 如不涉及继续场景6场景6：联系华为工程师提供技术支持若以上均不涉及，则联系华为工程师提供技术支持本文档属于场景6的情况。解决办法 修复CN 分别在已剔除的CN节点上操作，修复过程会有些漫长，大概5分钟左右--192.168.30.51上执行 gs_replace -t config -h 192.168.30.51 #修复CN组件 gs_replace -t start -h 192.168.30.51 #启动CN组件--192.168.30.53上执行 gs_replace -t config -h 192.168.30.53 #修复CN组件 gs_replace -t start -h 192.168.30.53 #启动CN组件 以192.168.30.51为例，输出如下：--修复CN [omm@node01 cn_5001]$ gs_replace -t config -h 192.168.30.51 Start checking bin files on node:['192.168.30.51'] checked bin files on node:[192.168.30.51], output:Success Check the etcd health. ETCD normal count:3 Check the number of abnormal ETCD is completed. Fixing ETCD instances. Fixing all the CMAgents instances. There are [0] CMAgents need to be repaired in cluster. There are [0] GNS need to be repaired in cluster. Update resource control config file: Not found resource config file on this node. Check stop resume file failed. Fresh cluster status successfully. Checking replace condition. Check the etcd health. ETCD normal count:3 Check the number of abnormal ETCD is completed. Successfully checked replace condition. Waiting for promote peer instances. . Successfully upgraded standby instances. Scp obs server key file to warmstandby node. Generate server key file succeed. Configuring replacement instances. Successfully configured replacement instances. Deleting abnormal CN from pgxc_node on the normal CN. No abnormal CN needs to be deleted. Unlocking cluster. Successfully unlocked cluster. Locking cluster. Successfully locked cluster. Incremental building CN from the Normal CN. Successfully incremental built CN from the Normal CN. Creating deleted CN on the normal CN. No CN needs to be created. Setting the SCTP. Successfully set the SCTP. Start to update_cn_status_to_normal_on_etcd. Successfully update_cn_status_to_normal_on_etcd. Unlocking cluster. Successfully unlocked cluster. Configuration succeeded. Successfully do action: config.--启动CN组件 [omm@node01 cn_5001]$ gs_replace -t start -h 192.168.30.51 Starting. ======================================================================Successfully started instance process. Waiting to become Normal.====================================================================== Start succeeded on all nodes. Start succeeded. Successfully do action: start. 查集群状态 查集群状态，集群状态已经由degraded变成了Noraml，CN组件状态也由Deleted变成了Noraml，任一个节点操作即可。cm_ctl query -Cvipd 输出如下：[omm@node01 ~]$ cm_ctl query -Cvipd [ CMServer State ]node node_ip instance state1 192.168.30.51 192.168.30.51 1 /gaussdb/cluster/data/cm/cm_server Primary 2 192.168.30.52 192.168.30.52 2 /gaussdb/cluster/data/cm/cm_server Standby 3 192.168.30.53 192.168.30.53 3 /gaussdb/cluster/data/cm/cm_server Standby[ ETCD State ]node node_ip instance state1 192.168.30.51 192.168.30.51 7001 /gaussdb/cluster/data/etcd StateFollower 2 192.168.30.52 192.168.30.52 7002 /gaussdb/cluster/data/etcd StateFollower 3 192.168.30.53 192.168.30.53 7003 /gaussdb/cluster/data/etcd StateLeader[ Cluster State ]cluster_state : Normal redistributing : No balanced : No current_az : AZ_ALL[ Coordinator State ]node node_ip instance state1 192.168.30.51 192.168.30.51 5001 8000 /gaussdb/cluster/data/cn Normal 2 192.168.30.52 192.168.30.52 5002 8000 /gaussdb/cluster/data/cn Normal 3 192.168.30.53 192.168.30.53 5003 8000 /gaussdb/cluster/data/cn Normal[ Central Coordinator State ]node node_ip instance state2 192.168.30.52 192.168.30.52 5002 /gaussdb/cluster/data/cn Normal[ GTM State ]node node_ip instance state sync_state1 192.168.30.51 192.168.30.51 1001 /gaussdb/cluster/data/gtm P Primary Connection ok Sync 2 192.168.30.52 192.168.30.52 1002 /gaussdb/cluster/data/gtm S Standby Connection ok Sync 3 192.168.30.53 192.168.30.53 1003 /gaussdb/cluster/data/gtm S Standby Connection ok Sync[ Datanode State ]node node_ip instance state | node node_ip instance state | node node_ip instancestate1 192.168.30.51 192.168.30.51 6001 33100 /gaussdb/cluster/data/dn/dn_6001 P Primary Normal | 2 192.168.30.52 192.168.30.52 6002 33100 /gaussdb/cluster/data/dn/dn_6002 S Standby Normal | 3 192.168.30.53 192.168.30.53 6003 33100 /gaussdb/cluster/data/dn/dn_6003S Standby Normal 2 192.168.30.52 192.168.30.52 6004 33120 /gaussdb/cluster/data/dn/dn_6004 P Standby Normal | 1 192.168.30.51 192.168.30.51 6005 33120 /gaussdb/cluster/data/dn/dn_6005 S Primary Normal | 3 192.168.30.53 192.168.30.53 6006 33120 /gaussdb/cluster/data/dn/dn_6006S Standby Normal 3 192.168.30.53 192.168.30.53 6007 33140 /gaussdb/cluster/data/dn/dn_6007 P Primary Normal | 2 192.168.30.52 192.168.30.52 6008 33140 /gaussdb/cluster/data/dn/dn_6008 S Standby Normal | 1 192.168.30.51 192.168.30.51 6009 33140 /gaussdb/cluster/data/dn/dn_6009S Standby Normal [omm@node01 ~]$

高弹性 在弹性扩展方面，GaussDB采用计算-内存-存储三层池化解耦设计，支持分层独立弹性伸缩，对应用透明。计算层将全局锁和页面属主目录（POD，Page Owner Directory）等状态下沉至共享内存层，本地仅保留数据页面，计算层增删节点无需状态信息迁移，实现秒级弹性伸缩；共享内存层采用POD方式管理缓冲池页面属主关系，POD基于一致性Hash均匀分布在共享内存层，增删节点仅迁移少量Bucket，内存层秒级弹性，应用无感知。GaussDB云原生数据库，打造计算/内存/存储三层池化架构，实现多节点透明多写、分层弹性伸缩、秒级快速恢复、秒级节点扩展能力，为用户带来最大价值。GaussDB持续创新，打造新型竞争力，为世界提供更优选择。

高可用 在高可用方面，GaussDB云原生数据库的节点故障能够做到6s内恢复，且对其他正常节点无影响，而其它厂商需要30s以上。可用性存在上述差异的根本原因在于，该云厂商部署在共享内存层支撑多写的核心组件存在单点问题，保存其上的全量脏页面、锁、事务状态等信息，在故障时需要全量恢复，特别是全局Buffer Pool，需要从共享存储的检查点依次恢复，较为耗时。与之相对比，GaussDB云原生围绕高可用做了大量创新： 首先，共享内存无脏页状态设计，仅内存节点故障时无需恢复WAL；其次，计算节点采用Past-Image设计，计算节点故障可从最近Image恢复，恢复时间大幅减少； 最后，GaussDB云原生业界首创双check-point设计，计算节点故障从内存检查点恢复，只有计算节点和共享内存节点同时故障时，才从共享存储的检查点恢复WAL。

高性能以D和O为代表的传统shared-disk多主架构，支持多节点透明多写，具备一定的吞吐扩展能力，在很长一段时间成功的支撑了企业关键业务负载。但其限制也很明显，首先D和O多写架构依赖专有硬件，弹性伸缩能力差，TCO较高，用户易被Lock in，在云计算和通用服务器大行其道的背景下，越来越多的用户希望多写架构能够运行于开放平台之上。另外，D和O的多节点并发事务状态多采用中心化模式设计，导致其扩展线性比较低，在重业务负载情况下，资源的扩展并不能带来对等的性能收益，导致其业务承载能力受到限制。 为继承D和O透明多写能力，同时充分利用云平台资源弹性和RDMA高速网络等先进硬件技术，当前业界头部数据库厂商均积极研究云原生多写架构。近期，某云厂商推出的云原生多主数据库，采用计算-内存-存储三层解耦的云原生架构设计，基于中心化组件实现多节点透明多写，是该方向架构演进的一个突破。但从其发表论文的测试数据来看，32节点TPCC吞吐为910万tpmC，而华为GaussDB云原生数据库在相同32节点可达3000+万tpmC的吞吐能力，支持128节点（16384鲲鹏核心）部署，能够支撑PB级OLTP业务规模，目前已在华为内部支撑实际业务生产。 存在上述性能差距的原因，笔者认为有如下几点： 第一，国内云厂商多写数据库的页面跨节点修改，采用进程级LLSN实现WAL记录的保序，而GaussDB云原生数据库采用细粒度页面级Lamport LSN保序，进程内无全局冲突点，在多核/众核环境下扩展性更强，能够更好的发挥硬件算力。第二，GaussDB云原生采用页面亲和性设计，脏页面无需回写共享内存，而该云厂商数据库采用中心式全量脏页面管理机制，事务产生的脏页面均须回写共享内存，造成大量页面在网络间频繁传递。GaussDB云原生数据库架构图 GaussDB云原生数据库在节点亲和性算法设计方面，除了分布式缓冲池的页面属主和读授权机制外，Undo段和FSM算法也充分考虑了节点亲和性设计，将节点间的网络交互降至最低，确保极致性能。 在Undo segment的节点亲和性设计上，从undo tablespace分配空间，多节点共享undo tablespace，而每个计算节点使用分布式锁机制亲和性分配Undo segment，每个Undo segment同一时刻只能被一个计算节点绑定。Undo segment亲和性分配机制图 在FSM空闲空间管理节点亲和性算法上，针对Heap FSM采用自动分区机制优化表数据插入分配页面算法，减少节点间冲突；针对索引空页面管理，采用自动分区机制优化索引查找空页面算法，减少节点间冲突。

  一、前言 在数据库中构建动态SQL语句是指根据不同的条件或参数创建不同的SQL语句。这通常是为了适应不同的业务需求，提高SQL的灵活性和效率。GaussDB数据库是一款具备高性能、高可用性和高扩展性的关系型数据库，它提供了丰富的功能和工具，支持动态SQL语句的构建。下面我们将介绍如何使用GaussDB数据库构建动态SQL语句。  二、构建动态SQL语句的基本步骤和注意事项 1、基本步骤  分析需求：首先需要明确业务需求，了解需要执行哪些SQL查询操作，并根据需求的不同来动态构建SQL语句。 准备参数：根据查询操作的不同，准备相应的参数，如筛选条件、排序规则等。 SQL拼接：根据需求和参数，使用字符串拼接方式构建SQL语句。 执行查询：使用GaussDB数据库的查询接口，执行构建好的SQL语句并获取查询结果。 处理结果：将查询结果进行处理和展示，可以是前端页面或后端接口等形式。 2、主要事项 避免SQL注入：在拼接SQL语句时，务必注意避免SQL注入的风险，不要直接拼接用户输入的内容。 性能优化：对于大规模数据的查询操作，需要进行性能优化，如使用索引、分页查询等方式来提高查询效率。 事务处理：如果涉及事务处理，需要使用GaussDB数据库的事务管理功能来确保数据的一致性和可靠性。 安全性保障：对于敏感数据的查询操作，需要进行安全性保障，如数据脱敏、权限控制等方式来保护数据的安全。 三、GaussDB中执行动态查询语句（示例） GaussDB提供两种方式：使用EXECUTE IMMEDIATE、OPEN FOR实现动态查询。前者通过动态执行SELECT语句，后者结合了游标的使用。当需要将查询的结果保存在一个数据集用于提取时，可使用OPEN FOR实现动态查询。  1、方式一：EXECUTE IMMEDIATE  ``` --传递并检索值（INTO子句用在USING子句前）： CREATE OR REPLACE FUNCTION dynamic_f() RETURNS text LANGUAGE plpgsql AS $$ DECLARE     d_id       INT := 2;    d_name     VARCHAR(20);    d_salary   INT; BEGIN    EXECUTE IMMEDIATE 'SELECT name,salary FROM company1 WHERE id = :1' INTO d_name,d_salary USING IN d_id;      RETURN '姓名:' || d_name || ' , 薪水:￥' ||d_salary; END $$;  --执行 CALL dynamic_f(); ```  主要属性说明：  INTO的变量 ：用于指定存放单行查询结果的变量。 USING IN的变量： 用于指定存放传递给动态SQL值的变量，在SQL拼接时可用占位符，占位符命名以“:”开始，后面可跟数字、字符或字符串，与USING子句的变量一一对应。 执行结果：   2、方式二：OPEN FOR  ``` --使用OPEN FOR打开动态游标来执行 CREATE OR REPLACE FUNCTION dynamic_cur() RETURNS text LANGUAGE plpgsql AS $$ DECLARE     v_name          VARCHAR2(20);     v_salary        INT;          TYPE ref_type IS REF CURSOR;  --定义游标类型     my_cur ref_type;              --定义游标变量      BEGIN     OPEN my_cur FOR 'SELECT name,salary FROM company1 WHERE id = :1' USING '3';   --打开游标, using是可选的     FETCH my_cur INTO v_name, v_salary; --获取数据     WHILE my_cur%FOUND          LOOP         RETURN v_name||'#'||v_salary;         FETCH my_cur INTO v_name, v_salary;     END LOOP;     CLOSE my_cur;   --关闭游标 END $$;  --执行 CALL dynamic_cur(); ```  主要属性说明  'WHILE my_cur%FOUND'： 是一个循环控制语句。'my_cur'是一个游标，而'%FOUND'是游标状态。当游标找到符合条件的记录时，这个状态就会为真（也就是说，如果'my_cur%'FOUND为真，那么就继续执行循环中的代码）。当游标没有更多的记录可返回时（或者达到了游标返回的最大记录数），这个状态就会为假，然后循环就会停止。所以，'WHILE my_cur%FOUND'的意思是：当游标'my_cur'还有记录可返回时，就继续执行循环中的代码。  执行结果   四、GaussDB中的动态非查询语句（示例） 其实这个可以简单的理解为非“SELECT语句”，基本写法跟前面的示例类似，下面继续以company1表为例：  ``` --使用EXECUTE IMMEDIATE执行动态非查询语句 CREATE OR REPLACE FUNCTION dynamic_cur() RETURNS void LANGUAGE plpgsql AS $$ DECLARE     v_id       INT := 4;     v_name     VARCHAR2(10) := 'ZhangSan';     v_age      INT := 30;      v_address  VARCHAR2(10) := 'BeiJing';     v_salary   INT := 30000;      v_newname   VARCHAR2(10) := 'company4'; BEGIN      EXECUTE IMMEDIATE 'INSERT INTO company1 VALUES(:1, :2, :3, :4, :5)' USING v_id, v_name, v_age,v_address,v_salary;      EXECUTE IMMEDIATE 'ALTER TABLE company1 RENAME to ' || v_newname;          END $$;  --执行 CALL dynamic_cur();  --查看结果 SELECT * FROM company4; 执行结果 ```   五、小结 通过使用GaussDB数据库构建动态SQL语句，数据应用部门可以更好地应对不断变化的数据查询需求，提高应用程序的性能和可维护性。本文主要介绍了如何使用GaussDB数据库构建动态SQL语句的基本步骤和注意事项，并通过实际案例进行了演示，欢迎大家测试、交流。  ——结束  ​ 

  一、前言 GaussDB是一款高性能、高可用的分布式数据库，广泛应用于各类行业和场景。在GaussDB中，锁是实现并发控制的关键机制之一，用于协调多个事务之间的数据访问，确保数据的一致性和完整性。本文将围绕GaussDB数据库的LOCK TABLE 做一简单介绍。  二、GaussDB数据库的锁 GaussDB提供了多种锁模式用于控制对表中数据的并发访问。这些模式可以用在MVCC（多版本并发控制）无法给出期望行为的场合。同样，大多数GaussDB命令自动施加恰当的锁，以保证被引用的表在命令的执行过程中不会以一种不兼容的方式被删除或者修改。比如，在存在其他并发操作的时候，ALTER TABLE是不能在同一个表上执行的。  1、GaussDB中的LOCK TABLE LOCK TABLE获取表级锁。  如果需要保持数据库数据的一致性，可以使用LOCK TABLE来阻止其他用户修改表。例如，一个应用需要保证表中的数据在事务的运行过程中不被修改。为实现这个目的，则可以对表进行锁定，这样将防止数据不被并发修改。LOCK TABLE只在一个事务块的内部有用，在事务结束时就会被释放。  1）语法格式  ``` LOCK [ TABLE ] name  IN {ACCESS SHARE | ROW SHARE | ROW EXCLUSIVE | SHARE UPDATE EXCLUSIVE | SHARE | SHARE ROW EXCLUSIVE | EXCLUSIVE | ACCESS EXCLUSIVE} MODE ```  2）参数说明  1）name：要锁定的表的名称。  2）锁的模式：  ACCESS SHARE：只读取表而不修改。所有对表进行读取而不修改的SQL语句都会自动请求这种锁。 ROW SHARE：允许对表进行并发读取，禁止对表进行其他操作。SELECT FOR UPDATE和SELECT FOR SHARE命令会自动在目标表上请求ROW SHARE锁（且所有被引用但不是FOR SHARE/FOR UPDATE的其他表上，还会自动加上ACCESS SHARE锁）。对于分区表，SELECT FOR SHARE操作还会在DN上获取partition对象的ROW EXCLUSIVE锁进行并发控制。 ROW EXCLUSIVE：与ROW SHARE锁相同，ROW EXCLUSIVE允许并发读取表，但是禁止修改表中数据。UPDATE，DELETE，INSERT命令会自动在目标表上请求这个锁（且所有被引用的其他表上还会自动加上的ACCESS SHARE锁）。通常情况下，所有会修改表数据的命令都会请求表的ROW EXCLUSIVE锁。 SHARE UPDATE EXCLUSIVE：保护一个表的模式不被并发修改，以及禁止在目标表上执行垃圾回收命令（VACUUM）。VACUUM（不带FULL选项）、ANALYZE、CREATE INDEX CONCURRENTLY命令会自动请求这样的锁。 SHARE：允许并发的查询，但是禁止对表进行修改。CREATE INDEX（不带CONCURRENTLY）语句会自动请求这种锁。 EXCLUSIVE:允许对目标表进行并发查询，但是禁止任何其他操作。这个模式只允许并发加ACCESS SHARE锁，也就是说，只有对表的读动作可以和持有这个锁模式的事务并发执行。任何SQL语句都不会在用户表上自动请求这个锁模式。然而在某些操作的时候，会在某些系统表上请求它。 SHARE ROW EXCLUSIVE:禁止对表进行任何的并发修改，而且是独占锁，因此一个会话中只能获取一次。任何SQL语句都不会自动请求这个锁模式。 ACCESS EXCLUSIVE:保证其所有者（事务）是可以访问该表的唯一事务。ALTER TABLE，DROP TABLE，TRUNCATE，REINDEX，CLUSTER，VACUUM FULL命令会自动请求这种锁。在LOCK TABLE命令没有明确声明需要的锁模式时，它是缺省锁模式。 2、示例一：ACCESS EXCLUSIVE 模式  ``` --创建测试表 DROP TABLE IF EXISTS omm2.company; CREATE TABLE omm2.company(    id int4 PRIMARY key NOT NULL   ,name varchar(10) NOT NULL   ,age int4 NOT NULL   ,address varchar(20) NOT NULL   ,salary float4 NOT NULL );  --初始化数据 INSERT INTO omm2.company VALUES (1, 'Paul', 32, 'California', 20000); INSERT INTO omm2.company VALUES (2, 'Allen', 25, 'Texas', 15000); INSERT INTO omm2.company VALUES (3, 'Teddy', 23, 'Norway', 20000); INSERT INTO omm2.company VALUES (4, 'ZhangSan', 30, 'BeiJing', 30000);  --启动一个事务 START TRANSACTION; LOCK TABLE omm2.company IN ACCESS EXCLUSIVE MODE; DELETE FROM omm2.company WHERE name ='Allen'; COMMIT; ```  解析：  “START TRANSACTION;”：启动一个新的事务。在数据库中，事务是一组一起执行的SQL语句，要么全部成功，要么全部失败。这确保了数据的一致性。 “LOCK TABLE omm2.company IN ACCESS EXCLUSIVE MODE;”：对omm2.company表进行了排他性锁定。在此模式下，其他会话不能对表进行读写操作，直到这个事务结束。这样可以防止在删除操作过程中其他事务对表产生干扰。 “DELETE FROM omm2.company WHERE name ='Allen'; ”：从omm2.company表中删除了所有名为'Allen'的记录。 “COMMIT;”：这行代码提交了前面的事务。在事务中执行的任何更改（在本例中是删除操作）在提交后才会永久保存在数据库中。 总的来说，这段代码删除了名为'Allen'的所有记录，并确保这个操作在提交之前不会被其他事务干扰。  3、示例二：SHARE ROW EXCLUSIVE 模式  ``` --复用示例一的测试表 CREATE TABLE omm2.company1 AS TABLE omm2.company;  --启动一个事务 START TRANSACTION; LOCK TABLE omm2.company1 IN SHARE ROW EXCLUSIVE MODE; DELETE FROM omm2.company1 WHERE name ='Allen'; COMMIT; ```  解析：  “CREATE TABLE omm2.company1 AS TABLE omm2.company;”：创建了一个新的表omm2.company1，其结构复制自已有的表omm2.company。这种操作通常用于创建表的副本，或者为某个操作创建一个临时的、与原表结构相同的新表。 “START TRANSACTION; ”：启动一个新的事务。在数据库中，事务是一组一起执行的SQL语句，要么全部成功，要么全部失败，这可以确保数据的一致性。 “LOCK TABLE omm2.company1 IN SHARE ROW EXCLUSIVE MODE; ”：对表omm2.company1进行了排他性锁定。在这种模式下，其他会话不能对表进行读写操作，直到这个事务结束，这样可以防止在删除操作过程中其他事务对表产生干扰。 “DELETE FROM omm2.company1 WHERE name ='Allen';”：从表omm1.company1中删除了所有名为'Allen'的记录。 “COMMIT;”:提交前面的事务。在事务中执行的任何更改（在本例中是删除操作）在提交后才会永久保存在数据库中。 三、小结 GaussDB数据库的锁机制是其重要的组成部分，用于支持并发控制和事务隔离。GaussDB实现了不同级别的事务隔离和并发控制，满足了不同场景下的需求。当然了，使用GaussDB数据库时也需要注意一些问题，如锁的管理和数据库的规划等。合理的锁管理和数据库规划能够提高系统的性能和可用性，反之则可能导致数据一致性问题或者系统故障。  ——结束  ​ 

如果通过 UGO 做完表结构校验 , 并已将表结构迁移到 GaussDB 中 , 如何通过 UGO 导出已经成功的表结构

​ 在数据库世界里，查询重写是提升性能的关键环节。WeTune作为一款革命性工具，能自动发现新重写规则，打破现有系统依赖人工发现重写规则的局限，大幅提升数据库查询性能。上海交通大学软件学院副院长王肇国和高斯实验室GaussDB数据库优化器专家Ethan联手开展了一场以《智能优化揭秘——GaussDB数据库查询重写的自动挖掘与生成》为主题的技术对谈，深入探讨了WeTune 2.0的重写规则与GaussDB的合作落地。直播过程包含对WeTune 2.0的项目背景、WeTune改写规则的自动发掘方式及实现、WeTune 2.0版本优势、在GaussDB中的应用与技术转化、未来前景等内容的解析与分享，一起倾听他们产教融合背后的故事吧。目录一、WeTune产品的项目背景二、WeTune改写规则的自动发掘方式三、WeTune改写规则的自动挖掘实现四、WeTune 2.0版本优势五、WeTune 2.0在华为云GaussDB的落地六、如何解决引入大量规则之后产生的性能问题？七、WeTune在数据库产业的价值及未来前景一、WeTune产品的项目背景 查询改写是数据库SQL优化过程中非常重要的部分，在语义不变的情况下，它可以把一条普通的或者性能不好的SQL语句优化成一条性能更好的SQL语句，实现查询效率的提升。改写规则作为查询改写中最关键的一个组件，想要在数据库里面添加改写规则，往往依赖于数据库专家经验的积累。如今，SQL语句的生成对象不再受限于程序员，外部框架和大模型也能够自动生成，随着生成源的增加，原来的SQL改写规则不再适用。由上海交通大学软件学院副院长王肇国团队开发出的WeTune刚好能解决这一问题，其核心思想就是自动发掘某些场景下的改写规则。于是，华为云数据库GaussDB团队与王肇国教授团队深度合作，成功完成WeTune 2.0在GaussDB产品上的落地。二、WeTune改写规则的自动发掘方式 自动挖掘的前提是暴力枚举，枚举之后检验语义是否正确，通过等价性验证去把最后一道关，所以，WeTune的等价性验证能力决定了它能够枚举哪些规则。下面是WeTune的改写规则的自动发掘方式：方式一，尝试暴力枚举所有在语法上合法的改写规则；方式二，用形式化验证的方式去验证枚举的规则是否正确（输入、输出的SQL是否在语义上等价）；方式三，借鉴数据库cost estimation技术检验改写规则是否有效，SQL优化性能是否更好。在实际运用中，以上改写规则的三种自动发掘方式也面临着一些现实层面的挑战。第一个暴力枚举虽然空间大，但开销也大，导致很多算力浪费。不过，上海交通大学软件学院副院长王肇国团队通过开发的一种只枚举小规则的技术，用小规则去推大规则，解决算力浪费的问题。第二个等价性验证。改写规则等价性验证，本质上就是SQL等价性验证，把不可判定问题的验证转换成可满足性等价、可判定问题的验证。另外，SQL等价性本身是一个关系型代数，把它转换成线性代数的求解。通过这两个维度解决了现有的SQL等价性验证问题，使得改写规则的枚举能力和范围大大提升。目前WeTune 2.0支持SQL:1999所有语法的验证。第三个除了借鉴数据库cost estimation技术来检验SQL优化性能是否更好以外，还会创建数据库实例，将改写规则在数据库实例上运行，以保证SQL优化效果最佳。有了这三方面的解决方案之后，2022年，上海交通大学软件学院副院长王肇国团队对WeTune 1.0版本进行了一个性能测试。他们从GitHub上通过对起始时间、受欢迎程度等维度进行筛选排序，找了涵盖电商、论坛等不同应用场景的20个开源应用，并在这些应用上运行程序，共收集了大概8500多条SQL语句。结果显示，WeTune 1.0优化的SQL语句大概674条，而其他商业数据库只能优化427条。相较而言，WeTune 1.0 优化效果大幅领先。三、WeTune改写规则的自动挖掘实现 WeTune 2.0在SQL等价性验证、枚举的能力和范围、规则的表达上都进行了精心设计，对GaussDB使用体验有极大提升。四、WeTune 2.0版本优势 相比WeTune 1.0版本，WeTune 2.0版本有几个比较大的优势：第一，增强的WeTune枚举能力，包括枚举的速度和枚举更多的复杂规则；第二，增强的WeTune验证能力，可以支持更多的SQL特性；第三，可以让用户可读、可加载、甚至可以直接使用手写。对比现有基于代码的查询引擎，WeTune 2.0不需要代码、不需要编译、不需要去发布版本，客户自己可以写改写规则，写完之后，通过GaussDB提早准备的接口，直接放到数据库里面就可以即时生效。GaussDB可以为用户提前预留好很多重写规则，后续如发现重写规则不够用，可自行增加，非常方便。第四，改写规则可在客户端实现部署。WeTune目前主要部署在云端，后面改写规则也可以部署在客户端，进行自动加载，实现不同用户间互不干扰。五、WeTune 2.0在华为云GaussDB的落地 WeTune和现有数据库应用落地过程中，不同的架构会面临不同挑战。WeTune 2.0在华为云GaussDB的落地，从技术角度来讲，GaussDB数据库是System-R架构，它的重写规则是耦合在代码里面，增加或卸载一个规则需要改写查询引擎。把WeTune应用在System-R架构上面涉及到理论、技术、工程层面的一些问题。不过，上海交通大学和华为的积极交流和深入探讨，也为彼此提供了不同的视角。在数据库开发过程中，改写规则非常依赖人工经验。随着客户场景越来越多，很多规则已经超出了现有的承载能力。从产品开发流程层面上讲，想要在GaussDB里面添加一个新的重写规则，论证重写规则是否等价是非常困难的。但是有了WeTune以后，开发者只要按照形式化语言去描述重写规则，然后WeTune拿去做验证，证明该规则在约束下是等价的，就可以放心地将该重写规则添加到GaussDB中，节约验证时间，对GaussDB的开发等流程非常有帮助。WeTune从框架上去解决了这两个重写规则是否等价的问题，这是WeTune非常突出的贡献点。对于客户来说，在使用GaussDB进行SQL优化时，只管放心用，优化交给GaussDB；对于开发者来说，只需要关心SQL语义，性能交给GaussDB。GaussDB引入WeTune2.0以后，自然会产生非常多的规则，帮助用户优化SQL的同时，也引入了另外一个成本，即会产生了SQL优化代价。六、如何解决引入大量规则之后产生的性能问题？ 从客户角度来讲，很多业务其实是相对比较固定的，而且上线之前也提前会做系统测试。若系统里面SQL优化度很高，那么就不必改写规则和暴力枚举，这样就可以降低优化成本。在实际环境中，大家希望数据库有成千上万条的改写规则可以给用户去用，可以生成改写的SQL语句。但是，改写规则非常多的时候，会导致改写和规则匹配的时间非常长，导致资源的极大浪费，也会影响用户体验。那如何在性能上做加速呢？目前来讲，主要通过两方面来去解决：一方面是从通用的匹配算法入手。当改写规则非常多的时候，匹配算法能够帮助性能有数量级的提升；另一方面，从应用的场景或从SQL产生的源头来进行分类。不同应用场景下、不同业务目的、不同的框架需要的改写规则不一样，WeTune 2.0可以对于不同场景和需求来去做定制化的规则探索。七、WeTune在数据库产业的价值及未来前景 WeTune是多个技术合起来形成了一个规则挖掘。从学术角度来讲，SQL等价性验证可以往数据库测试这个方向再迈一步。在数据库测试过程中，对于SQL的优化引擎，可以使用差分测试。差分测试是一种很经典的数据库测试方式，验证重写规则可以使用，验证SQL优化引擎过程中也适用。WeTune等价性验证器可以去枚举语义等价但形式完全不同的两条SQL，这样可以确保在测试对比过程中，程序运行是不一样的路径，可以更高效或覆盖面更广地完成数据库引擎的测试任务。WeTune不仅减轻了数据库开发者或者DBA的负担，目前在教育领域里有一定的应用，WeTune等价性验证帮助国内外很多高校助教批改学生的数据库作业，减轻数据库教育工作者的工作压力。华为与高校的深度合作将持续推进，融合双方的技术优势和科研力量，共同探索数据库领域的前沿技术，培养更多高水平的数据库人才。未来，华为和上海交通大学研究团队将携手，共同突破数据库查询重写技术的瓶颈，通过持续的创新和优化，进一步提升GaussDB的查询性能和效率。我们期待更多的技术合作和探索，推动数据库技术向智能化、自动化方向发展，为广大企业和用户带来更多价值。欢迎小伙伴们交流~​

问题描述CPU使用率高。问题现象出现CPU使用率超过阈值，CPU使用率快速上涨或短时间持续较高水平等现象。告警CPU使用率告警。业务影响CPU使用率高集群响应变慢。原因分析期间业务压力增大导致。出现CPU耗时较多的SQL。处理方法步骤 1查看监控是某个节点的CPU高还是集群整体CPU高，如果是整体CPU高生成集群级别wdr报告，如果是某个节点则生成节点级wdr报告。步骤 2首先查看当前已有的wdr报告快照。select * from snapshot.snapshot order by start_ts desc;步骤 3生成wdr报告需要两个snapshot_id，根据需要对比的两个时间段选取对应的snapshot_id，调整输出格式，gsql界面输入： \a \t \o + 生成文件名(html文件)步骤 4如果是要生成节点级的报告则执行：select generate_wdr_report(snapshot_id1, snapshot_id2, ‘all’, ‘node’, 节点名称)如果要生成集群级别报告则执行select generate_wdr_report(snapshot_id1, snapshot_id2, ‘all’, ‘cluster’)其中snapshot_id1和snapshot_id2按照时间从小到大的顺序写入上面分析出来的要生成报告的两个id，节点名称可以通过登录到问题节点执行show pgxc_node_name获取。 对应节点级别报告主要关注Top 10 Events by Total Wait Time和SQL ordered by CPU Time部分，集群级别主要关注SQL ordered by CPU Time部分，在wdr报告中搜索即可。步骤 6CPU使用率较低期间的wdr报告和较高期间的wdr报告个一份，这里已节点级别为例，集群级别只需要按照SQL ordered by CPU Time部分分析，分析方式一样。步骤 7Top 10 Events by Total Wait Time部分包含两个快照期间的主要等待事件，可以进行大致分析是否存在大量CPU耗时较高的等待事件例如文件数据读取，快照期间主要等待事件，如果通过对比发现CPU高期间的文件读事件明显变多，则说明此期间SQL执行读取数据上上涨导致的CPU耗时上涨。如果是各项等待事件都有一定幅度上涨则可能是集群压力上涨导致，具体是那一部分SQL则需要分析SQL ordered by CPU Time部分。步骤 8对比两份报告SQL ordered by CPU Time部分的CPU Time(us)差异,一般对比前10个即可，这里介绍一下此部分的主要构成。Unique SQL Id：对应unique_sql_id，可以通过此id去数据库查询使用此模板的SQL的其他数据，例如通过summary_statement查询总体语句的调用情况。Node Name：节点名称。User Name：用户名。CPU Time(us)：两个快照期间的CPU耗时Calls：两个快照期间的语句调用次数。Min Elapse Time(us)：SQL在内核内的最小运行时间，注意这是整体的最小解析时间不是此快照期间的最小。Max Elapse Time(us)：SQL在内核内的最大运行时间，注意这是整体的最大解析时间不是此快照期间的最小。Total Elapse Time(us)：两个快照期间此语句的SQL在内核内的总运行时间时间。Avg Elapse Time(us)：两个快照期间此语句的SQL在内核内的平均运行时间时间。Returned Rows：两个快照期间此语句的SELECT返回的结果集行数。Tuples Read：两个快照期间访问的元组数量。Tuples Affected：两个快照期间Insert/Update/Delete行数。Logical Read：两个快照期间的逻辑读数。Physical Read：两个快照期间的物理读数。Data IO Time(us)：两个快照期间IO上的时间花费。Sort Count：两个快照期间的排序执行的次数。Sort Time(us)：两个快照期间的排序执行的时间。Sort Mem Used(KB)：两个快照期间的排序过程中使用的work memory大小（单位：KB）。Sort Spill Count：两个快照期间的排序过程中，若发生落盘，写文件的次数。Sort Spill Size(KB)：两个快照期间的排序过程中，若发生落盘，使用的文件大小（单位：KB）。Hash Count：两个快照期间的hash执行的次数。Hash Time(us)：两个快照期间的hash执行的时间（单位：微秒）。Hash Mem Used(KB)：两个快照期间的hash过程中使用的work memory大小（单位：KB）。Hash Spill Count：两个快照期间的hash过程中，若发生落盘，写文件的次数。Hash Spill Size(KB)：两个快照期间的hash过程中，若发生落盘，使用的文件大小（单位：KB）。SQL Text：这里显示的SQL语句只有一部分，完整的SQL需要点击Unique SQL Id跳转到完整SQL处。步骤9如果发现CPU高期间报告的CPU Time(us)前面几个的SQL明显不同且CPU耗时较大，则原因可能为CPU高耗时SQL调用量上涨导致，如果需要分析为什么此SQL的CPU耗时高则可以参考步骤11。步骤 10如果两个报告前10个Unique SQL Id对比几乎相同，此时看SQL对应的CPU耗时和ncalls，如果calls上涨则说明是业务压力增大导致的CPU上涨，如果calls没有上涨，则需要分析为什么同一条SQL在此阶段的CPU耗时上涨，跳转步骤11。步骤 11在语句和调用次数没有变化的情况下，如果是查询语句看此SQL模板的Returned Rows和Physical Read，如果数量有明显增长则说明此SQL读写的数据量增大导致的CPU压力上涨，一般有两种情况，部分特殊值的情况下扫描数据量大或者计划发生改变导致扫描数据量变大。如果是写语句则可以看Tuples Affected是否有明显增加，一般读取数据比较耗CPU，如果是语句本身影响的主要围绕数据读取方面进行对比。步骤 12如果两个快照的数据几乎相同，可以通过火焰图或者长事务做进一步分析。