参加openGauss训练营，对opengauss有了初步的认识。下面是学习心得：
第一章 openGauss概述
openGauss是关系型数据库（relational database），采用客户端/服务器，单进程多线程架构；支持单机和一主多备部署方式，同时支持备机可读、双机高可用等特性。
openGauss有如下基本功能。
（1） 支持标准SQL。
openGauss数据库支持标准的SQL（structured query language，结构化查询语言）。SQL标准是一个国际性的标准，会定期更新和演进。SQL标准的定义分为核心特性以及可选特性，绝大部分的数据库都没有100%支撑SQL标准。openGauss数据库支持SQL92/SQL99/SQL2003等，同时支持SQL2011大部分核心特性以及部分可选特性。
（2） 支持标准开发接口。
openGauss数据库提供业界标准的ODBC（open database connectivity，开放式数据库连接）及JDBC（java database connectivity，java数据库连接）接口，保证用户能将业务快速迁移至openGauss。目前支持标准的ODBC3.5及JDBC4.0接口，其中ODBC能够支持CentOS、openEuler、SUSE、Win32、Win64等平台，JDBC无平台差异。
（3） 支持混合存储引擎。
openGauss数据库支持行存储引擎、列存储引擎和内存存储引擎等。行存储分为inplace update和append update两种模式，前者通过单独的回滚段（undo log）来保留元组的前像以解决读写冲突，可以更自然地支持数据更新；后者将更新记录混杂在数据记录中，通过新旧版本的形式来支持数据更新，对于旧版本需要定期做vacuum操作来支持磁盘空间的回收。列存储支持数据快速分析，更适合OLAP（online analytical processing，联机分析处理）业务。内存引擎支持实时数据处理，对有极致性能要求的业务提供支撑。
（4） 支持事务。
事务支持指的是系统提供事务的能力，openGauss支持事务的原子性、一致性、隔离性和持久性。事务支持及数据一致性保证是绝大多数数据库的基本功能，只有支持了事务，才能满足事务化的应用需求。
A（atomicity）： 原子性。整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。
C（consistency）： 一致性。事务需要保证从一个执行性状态转移到另一个一致性状态，不能违反数据库的一致性约束。
I（isolation）： 隔离性。隔离事务的执行状态，使它们好像是系统在给定时间内执行的唯一操作。例如有两个事务并发执行，事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。
D（durability）： 持久性。在事务提交以后，该事务对数据库所做的更改便持久地保存在数据库之中，不会因掉电、进程异常故障而丢失。
openGauss数据库支持事务的隔离级别有读已提交和可重复读，默认隔离级别是读已提交，保证不会读到脏数据。
事务分为隐式事务和显式事务。显式事务的相关基础接口如下。
Start transaction：事务开启。
Commit：事务提交。
Rollback：事务回滚。
另有用户还可以通过set transaction命令设置事务的隔离级别、读写模式或可推迟模式。
（5） 软硬结合。
openGauss数据库支持软硬件地结合，包括多核地并发访问控制、基于SSD（solid-state drive，固态硬盘）地I/O（input/output，输入/输出）优化、智能地buffer pool（缓冲池）数据管理。
（6） 智能优化器。
openGauss数据库提供了智能的代价模型、智能计划选择，可以显著提升数据库性能。openGauss的执行器包含了向量化执行和LLVM（low level virtual machine，底层虚拟机，一种构架编译器的框架系统）编译执行，可以显著提升数据库性能。
（7） 支持AI。
传统数据库生态依赖于DBA（database administrator，数据库管理员）进行数据地管理、维护、监控、优化。但是在大量的数据库实例中，DBA难以支持海量实例，而AI（artificial intelligence，人工智能）则可以自动优化数据库，openGauss数据库的AI功能包括AI自调优、AI索引推荐、AI慢SQL诊断等。
（8） 支持安全。
openGauss数据库具有非常好的安全特性，包括透明加密（在磁盘的存储文件是加密的）、全密态（数据传输、存储、计算都是加密的）、防篡改（用户不可篡改）、敏感数据智能发现等。
（9） 支持函数和存储过程。
函数和存储过程是数据库中的一种重要对象，主要功能是将用户特定功能的SQL语句集进行封装并方便调用。存储过程是SQL、PL（procedural language SQL，过程语言SQL）/SQL的组合。存储过程可以使执行商业规则的代码从应用程序中移动到数据库，从而实现代码存储一次但能够被多个程序使用。
允许客户模块化程序设计，对SQL语句集进行封装，调用方便。
存储过程会进行编译缓存，可以提升用户执行SQL语句集的速度。
系统管理员通过对执行某一存储过程的权限进行限制，能够实现对相应数据访问权限的限制，避免了非授权用户对数据的访问，保证了数据的安全。
为了处理SQL语句，存储过程分配一段内存区域来保存上下文。游标是指向上下文区域的句柄或指针。借助游标，存储过程可以控制上下文区域的变化。
支持6种异常信息级别方便客户对存储过程进行调试，支持设置断点和单步调试。存储过程调试是一种调试手段，可以在存储过程开发中，一步一步跟踪存储过程执行的流程，根据变量的值，找到错误的原因或者程序的bug，提高问题定位效率。
openGauss支持SQL标准中的函数及存储过程，增强了存储过程的易用性。
（10） 兼容PostgreSQL接口。
openGauss数据库兼容PSQL客户端，兼容PostgreSQL标准接口。
（11） 支持SQL hint。
openGauss数据库支持SQL hint（hint是SQL语句的注释，可以指导优化器选择人为指定的执行计划），影响执行计划生成，提升SQL查询性能。Plan Hint为用户提供了直接影响执行计划生成的手段，用户可以通过指定join顺序、join方法、Scan方法、结果行数等多个手段进行执行计划的调优，以提升查询性能。
（12）支持Copy接口容错机制。
openGauss数据库中，用户可以使用封装好的函数创建Copy错误表，并能在使用Copy From语句时指定容错选项。指定容错选项后，openGauss数据库在执行Copy From语句过程中不会因“部分解析”、“数据格式”、“字符集”等相关的报错中断事务，而是把这些报错信息记录至错误表中，从而使得Copy From的目标文件即使有少量数据错误也可以完成入库操作。用户随后可以在错误表中对相关的错误进行定位以及进一步排查。
第二章 主备HA部署
OM：运维管理模块（Operation Manager）。提供数据库日常运维、配置管理的管理接口、工具。
客户端驱动：负责接收来自应用的访问请求，并向应用返回执行结果。客户端驱动负责与openGauss实例通信，发送应用的SQL命令，接收openGauss实例的执行结果。
openGauss（主备）：负责存储业务数据、执行数据查询任务以及向客户端返回执行结果。openGauss实例包含主、备两种类型，支持一主多备。
Storage：服务器的本地存储资源，持久化存储数据。
第三章 WDR报告和性能调优
数据库系统，优化一直是绕不开的话题。完善了自己对openGauss优化的理解，主要从系统级，对象级，应用机参数着手优化。
一、系统级：集群级别或节点级别指标（OS，InstanceTime，Memory，Session，Thread，Events，Utility）
1、实时获取操作系统整体的负载情况（OS_RUNTIME,OS_THREADS）。CPU时间，负载LOAD，内存消耗情况，判断当前操作系统的整体负载状态，定位资源消耗比较大的进程。
2、系统级的时间消耗细分（INSTANCE_TIME）。判断整个系统是否在负载LOAD，网络，IO，CPU上存在瓶颈。
3、实例级内存分配，使用率（MEMORY_NODE_DETAIL,SHARED_MEMORY_DETAIL）。共享内存上下文分配/使用率，定位定界可细化至特性级别，结合session级别内存上下文分配视图接口，可帮助定位会话级内存使用问题。
4、系统级Session（SESSION_STAT,SESSION_TIME,SESSION_MEMORY,SESSION_MEMORY_DETAIL,SESSION_STAT_ACTIVITY）。会话级负载强度，逻辑/物理读写强度，排序活动等，用于甄别出负载强度高，使用资源多的会话。会话级时间细分，用于甄别出不同时间维度上session的消耗。会话级总内存和内存上下文分配/使用，可以定位单个session在特性级上的内存问题。获取实时系统活跃会话列表，包括会话基本信息，会话事务，语句，等待事件，会话状态（active,idle等）。用于分析当前系统活跃用户的活动信息，比如从语句的开始时间判断当前会话是否一致阻塞在某一个语句，从等待事件可以判断某一个或者多数会话阻塞在哪个事件或者节点（分布式场景）。
5、系统级Thread（THREAD_WAIT_STATUS）。获取实例工作线程/辅助线程列表列表，判断线程的运行状态，当前正阻塞在哪个事件上，正在等待哪个锁，或被哪个会话阻塞（提供可以判断系统中的会话等待链的接口）
6、系统级-Events（WAIT_EVENTS）各功能模块中IO,LOCK,LWLOCK,STATUS四类事件的等待次数，等待失败次数，等待时间等维度的统计信息，可以帮助定位特性级细粒度时延性能问题。
7、系统级-Utility（COMM_DELAY,COMM_RECV_STREAM,COMM_SEND_STREAM,COMM_STATUS，REPLICATION_STAT，GLOBAL_GET_BGWRITER_STATUS,GLOBAL_PAGEWRITER_STATUS，POOLER_STATUS）。获取通信组件时延信息，接收和发送流状态，用于诊断通信链路容量和时延故障。获取分布式部署形态下主备同步状态信息，用于诊断主备时延，复制性能故障。获取后台全量/增量检查点信息，buffer中待落盘脏页信息，后台刷脏工作线程的状态将影响bufferpool的效率，磁盘IO繁忙程度，这些信息可以帮助优化缓存和IO性能。分布式部署形态下，CN和DN之间的连接池将影响事务的执行效率和成功率，pooler状态可以帮助诊断连接池瓶颈。
二、对象级：数据库对象指标（Database、Table、Index、File、Lock）
1、对象级-Database（STAT_DATABASE,STAT_DATABASE_CONFLICTS）。提供数据库级别的活跃连接数，负载强度，块读写性能，行活动，死锁，临时下盘文件等信息。根据这些信息可以帮助建立数据库访存模型（读写比等负载特点），识别热点数据库，诊断数据库级别大颗粒性能瓶颈。
2、对象级-Table（STAT_USER_TABLES,STAT_SYS_TABLES,STAT_ALL_TABLESSTATIO_USER_TABLES,STATIO_SYS_TABLES,STATIO_ALL_TABLESGLOBAL_STAT_HOTKEYS_INFO）。表上行扫描活动，索引扫描活动，行变更活动，活跃行占比，表维护操作活动（vaccum，analyze），页面读取缓冲命中率等，这些信息可以帮助建立表级别的访存模型（读写比，缓存效率等），识别热点表，预警表维护操作，诊断表级别细粒度性能瓶颈。识别表级别热key，定界热点访问造成的网络，IO瓶颈。
3、对象级-Index（STAT_USER_INDEXES,STAT_SYS_INDEXES,STAT_ALL_INDEXESSTATIO_USER_INDEXES,STATIO_SYS_INDEXES,STATIO_ALL_INDEXES）。索引使用统计：indexscan次数，indexscan返回的索引项，通过indexscan返回的表行数等，索引页的缓存效率等，用以评估索引收益和效率。
4、对象级-File（FILE_IOSTAT,FILE_REDO_IOSTAT,STAT_BAD_BLOCK）。数据（数据，索引）文件的IO性能统计指标（读写数目，耗时，时延），可以帮助建立数据文件物理访存的模型，识别文件级别的物理IO强度和瓶颈。获取操作Redo文件的性能，帮助诊断redo日志操作的性能瓶颈。
5、对象级-Lock（LOCKS）对象锁涉及到的对象，事务，会话，锁信息，实时显示当前系统锁等待关系，识别热点锁。
6、对象级-Sequence（STATIO_USER_SEQUENCES,STATIO_SYS_SEQUENCES,STATIO_ALL_SEQUENCES）。sequence的缓存效率，如果我们处在一个高并发的情况下，系统频繁的多会话请求sequence取值。如果我们的sequence没有设置cache，那么每次都要更新数据字典，都要进行commit操作。多个会话还会出现该sequence记录的争用。
三、应用级：表征应用负载性能（Transaction、Statement、ActivesessionProfile、Slowquery、FullSQLtrace）
1、应用级-Transaction（TRANSACTIONS_RUNNING_XACTS,TRANSACTIONS_PREPARED_XACTS）。获取当前正在运行的单节点/两阶段事务列表，结合session和thread视图，诊断运行时间超过预期的事务。
2、应用级-Statement（STATEMENT_COUNT,STATEMENT）。DDL，DML(select,insert,update,delete)，DCL语句的分布比率，帮助建立负载特征模型，预警负载异常变动。语句级别（归一化SQL，模板SQL）的响应时间，执行次数，行活动，软硬解析比，时间模型，网络开销，排序性能（时间，内存，溢出），执行器HASH性能（时间，内存，溢出）。据此可以识别热点语句，定位语句性能瓶颈，建立语句性能基线，以低成本预警语句性能变化。
3、应用级-ActivesessionProfile（LOCAL_ACTIVE_SESSION,GS_ASP(publicschema)）。ASP(ActiveSessionProfile)活跃会话概要信息，通过采样实例活跃会话的状态信息，低成本复现过去一段时间的系统活动，主要包含会话基本信息，会话事务，语句，等待事件，会话状态(active,idle等)，当前正阻塞在哪个事件上，正在等待哪个锁，或被哪个会话阻塞。可以从中获取如下主要概要信息：最近用户session最耗资源的的事件。最近比较占资源的session/SQL把资源都消耗在哪些event上。最近执行时间/执行次数最多的是哪些SQL(进而可以找出表，数据库)。最近钟最耗资源的用户的信息。最近阻塞其他session最多的sessionLOCAL_ACTIVE_SESSION的默认采样频率是1s，内存视图，ASP的默认采样频率是10s，持久化在存储。
4、应用级-FullSQLtrace&SlowQuery（STATEMENT_HISTORY）。记录全量SQL信息，分为L0,L1,L2三个等级，可以获取实例信息，客户端信息，语句概要信息，执行信息，行活动信息，Cache/IO，时间模型，网络统计信息，锁概要信息，锁详细信息等。通过全量SQL，可以得到整个系统所有语句的执行流水以及他们的详细性能数据(持久化的)。除Statement视图提供的能力外，还额外提供了详细加放锁信息，可以诊断到单语句级别的性能波动。达到慢查询阈值设置的语句性能信息，性能要素和全量SQL一致。
四、WDR报表分析（集群级报表/节点级报表）
1、集群级Report主要关注以下指标（DatabaseStat、LoadProfile、InstanceEfficiencyPercentages、IOProfile、SQLStatistics、CacheIOStats、ObjectStats、SQLDetail）
2、节点级Report主要关注以下指标（InstanceEfficiencyPercentages、Top10EventsbyTotalWaitTime、WaitClassesbyTotalWaitTime、IOProfile、MemoryStatistics、TimeModel、SQLStatistics、WaitEvents、CacheIOStats、UtilityStatus、Objectstats、ConfigurationSettings）
通过对该主题的学习，WDR报表类似于Oracle—AWR报告，以后可以结合自己之前对Oracle数据库优化的经验，以及对AWR报告的分析，来更好的学习WDR报告，完善自己的优化技能。
第四章 openGauss的AI特性
1 openGauss开发了自己的数据库参数调优框架X-Tuner, 相比于传统方法，X-Tuner具有如下的功能特点：鲁棒性强，有一定的容错性;灵活部署，使用方便；理解解容易，便于二次开发：
2 SQLDiag: SQL语句智能识别
SQLDiag着眼于数据库的历史SQL语句，可以从历史数据中检测出相似SQL语句，并基于SQL向量化技术和时序预测算法预测SQL语句执行时长，进而识别出潜在慢SQL。该框架有的优点是：不需要SQL语句的执行计划，对数据库性能不会有任何的影响；使用场景广泛，经过改造甚至可以应用于NoSQL中；
3 智能优化器：数据库执行代价预测
openGauss为数据库用户推出基于在线深度学习的查询性能预测功能。openGauss针对SQL性能评估这一场景一站式整合了数据收集、数据清洗、数据预处理、数据编码、训练监控等流程。用户只需要根据推荐为模型配置少量参数，并在模型训练完成后调用模型预测接口直接得到性能预测结果。
第五章 安全
openGauss在部署完成后，实际上会有多个用户参与数据管理。除了管理员用户外，更多的是创建的普通用户直接进行数据管理。用户的多样性会导致数据库存在一些不可预期的风险。如何快速发现和追溯到这些异常的行为，则需要依赖审计机制和审计追踪机制。
审计记录的关键在于：
§ 定义何种数据库操作行为需要进行日志记录。
§ 记录的事件以何种形式展现和存储。
只有有效的记录了所关心的行为信息，才能依据这些行为进行问题审计和追溯，实现对系统的一个有效监督。
正如我们在“三权分立模型”章节描述的，进行权限分离后，就出现了审计管理员（当然也可以使用普通角色管理模型中的系统管理员来担当）。审计管理员最重要的作用在于对管理员以及普通用户所有关心的行为进行记录和审计追溯。审计首先要定义审计哪些数据库行为，其次需要定义审计内容记录在什么文件中以及何种目录下，最后需要定义清楚应提供何种接口供审计管理员进行审计查询。
openGauss针对用户所关心的行为提供了基础审计能力，包括事件的发起者、发生的时间和发生的内容。openGauss的审计功能受总体开关audit_enabled控制，默认开启。该开关不支持动态加载，需要重启数据库后才可以使功能的性质发生改变。在总体开关的基础上，openGauss增加了每一个对应审计项的开关。只有相应的开关开启，对应的审计功能项才能生效。
不同于总体开关，每一个对应的子审计项都支持动态加载，在数据库运行期间修改审计开关的值，不需要重启数据库即可支持。审计的子项目包括如下的部分：
§ audit_login_logout：用户登录、注销审计
§ audit_database_process：数据库启动、停止、恢复和切换审计
§ audit_user_locked：用户锁定和解锁审计
§ audit_user_violation：用户访问越权审计
§ audit_grant_revoke：授权和回收权限审计
§ audit_system_object：数据库对象的Create、Alter和Drop操作审计
§ audit_dml_state：具体表的INSERT、UDPDATE和DELETE操作审计
§ audit_dml_state_select：select查询操作审计
§ audit_copy_exec：copy行为审计
§ audit_function_exec：审计执行function的操作
§ audit_set_parameter：审计设置参数的行为
定义完审计记录行为后，当数据库执行相关的操作，内核独立的审计线程就会记录审计日志。
传统的审计日志保存方法有两种，记录到数据库的表中以及记录到OS文件中。前种方法由于表是数据库的对象，在符合权限的情况下就可以访问到该审计表，当发生非法操作时，审计记录的准确性难以得到保证。而后种方法虽然需要用户维护审计日志，但是比较安全，即使一个账户可以访问数据库，但不一定有访问OS这个文件的权限。
与审计日志存储相关的配置参数及其含义定义如下：
§ audit_directory：字符串类型，定义审计日志在系统中的存储目录，一个相对于“/data”数据目录的路径，默认值为：/var/log/openGauss/perfadm/pg_audit，也可以由用户指定。
§ audit_resource_policy：布尔类型，控制审计日志的保存策略，即以空间还是时间限制为优先策略决定审计文件更新，默认值为on。
§ audit_space_limit：整型类型，定义允许审计日志占用的磁盘空间总量，默认值为1GB，在实际配置中需要结合环境进行总体考虑。
§ audit_file_remain_time：整型类型，定义保留审计日志的最短时间要求，默认值为90，单位为天。特别的，如果取值为0，则表示无时间限制。
§ audit_file_remian_threshold：整型类型，定义审计目录audit_directory下可以存储的审计文件个数。默认值为1048576。
§ audit_rotation_size：整型类型，定义单个审计日志文件的最大大小，当审计日志文件大小超过此参数值时，新创建一个审计文件。
§ audit_rotation_interval：整型类型，定义新创建一个审计日志文件的时间间隔。默认值为1天，单位为分钟。
通过上述的这些配置参数，系统管理员用户可以在查询任务发生后找到对应的审计日志，并进行有效归档。审计日志文件也会按照参数指定的规则来进行更新、轮换等。
openGauss将审计所产生的文件独立存放在审计文件中，并按照产生的先后顺序进行标记管理，并以特定的格式进行存储（默认为二进制格式文件）。当审计管理员需要进行审计查询时，通过执行函数pg_query_audit即可，其具体的语法如下所示：
select * from pg_query_audit(timestamp valid_start_time, timestamp valid_end_time, audit_log);
其中，valid_start_time和valid_end_time定义了审计管理员将要审计的有效开始时间和有效结束时间；audit_log表示审计日志信息所在的归档路径，当不指定该参数时，默认查看链接当前实例的审计日志文件(不区分具体的审计文件)。
值得注意的是，valid_start_time和valid_end_time的有效值为从valid_start_time日期中的00:00:00开始到valid_end_time日期中23:59:59之间。由于审计日志中包含了众多的信息，如时间、地点、行为分类等等，审计管理在获得完整的信息后可以增加各种过滤条件来获得相对应的更明确的信息。
传统审计依据开关定义了不同的审计组合行为。事实上，这种无区分对待的审计行为虽然记录了所有想要审计的行为，但是对于通过审计日志发现问题则显得不那么容易，且管理员无法为特定的用户定义特定的行为，反而造成了系统处理的负担。因此需要为审计添加更精细化管理的能力。
统一审计的目的在于通过一系列有效的规则在数据库内部有选择性执行有效的审计，从而简化管理，提高数据库生成的审计数据的安全性。本节所述的技术目前处于研发阶段，对应产品尚未向客户发布。
openGauss提供了一套完整的统一审计策略机制，依据不同任务的诉求对用户的行为进行定制化审计管理。更进一步，openGauss的统一审计不仅可以依据用户、依据表进行审计行为定义，同时还可以扩展至通过IP地址、APP的名称来过滤和限制需要审计的内容。实际的语法如下所示：
CREATE AUDIT_POLICY policy_name[(privilege_audit_clause) | (access_audit_clause)[filter_clause FILTER_TYPE(filter_value)][ENABLED|DISABLED]];
其中，privilege_audit_clause定义语法如下：
PRIVILEGES (DDL|ALL) [ ON (LABEL(resource_label_name)) [, …]* ];
该语法定义了针对DDL类语句的审计策略，其中LABEL表示一组资产集合，即数据库对象的集合。access_audit_clause定义语法如下：
ACCESS (DML|ALL) [ ON (LABEL(resource_label_name)) [, ...]* ];
该语法定义了针对DML类语句的审计策略。filter_clause标记需要过滤的信息，常见的Filter types类型包括IP、APPS应用（访问的应用名）、ROLES（数据库系统用户）以及LABEL对象。
一个有效的统一审计策略可参见如下：
CREATE AUDIT_POLICY admin_policy PRIVILEGES CREATE, ALTER, DROP FILTER ON IP(local), ROLES(dev);
表示创建针对CREATE/ALTER/DROP操作的审计策略，审计策略只对dev用户在本地（local）执行CREATE/ALTER/DROP行为时生效。
第六章 openGauss与PostgreSQL的部分特性对比
OpenGauss和PostgreSQL的差别主要在几个方面：
运行时模型： OpenGauss是线程池模型、PostgreSQL是进程模型
事务处理机制： OpenGauss是64位事务ID，有增量checkpoint机制
数据存储与组织：OpenGauss是行存、列存以及内存引擎
查询优化器： 在优化器和SQL解析层做了优化
