一、体系结构 openGauss是一款单进程多线程数据库，客户端服务器架构。 1. 驱动  驱动支持：jdbc java，odbc c++，libpq c， 2. 核心线程 GaussDB线程：业务连接线程，SQL语句解析,解析后执行访问share buffer数据share buffer: 把table加载到share buffer数据，修改后会写wal buffer 通过bgwriter线程写到pg_xlog日志下MOT：内存存储引擎Cstore buffer：列存引擎temp buffer：存放临时表数据，全局临时表 表定义是全局的数据是会话是私有的 会话临时表work_mem：存放运行过程中临时的数据，比如排序，hash join 支持计算的 3. 辅助线程 Auditor：审计线程，收集各个线程的审计信息，写到审计文件里。WalSender：主库把日志发送到备库WalReceiver：备库接受主库Stat_collector：统计数据，，把后台线程对数据库的增删改查汇总，服务于数据库的优化器以便选择最优路径 4. 数据库postgresql.conf：数据库配置文件，GaussMaster线程会首先读取，对IP和端口号进行监听，等待连接pg_hba.conf：鉴权，黑白名单pg_ident.conf：用于安全，做标识gaussdb.state：记录当前进程的状态信息，当非正常关闭数据库后，重启数据库会重新生成。base/global/pg_talspc：存放数据文件，global存放全局，pg_tblspc存放单独表空间pg_xlog：redo log文件pg_clog：存放数据库日志提交信息，记录事物的状态，回滚，运行，提交。pg_csnlog：存放事物相关的快照及时间戳信息pg_twophase：存放两阶段事物提交文件的状态信息，如果要保持两个数据库之间的一致性需要两阶段提交， prepare ,commit。pg_serial：序列表pg_multixact：记录事物与锁的映射关系Archived_WAL：存放日志归档信息pg_audit：存放审计信息pg_replslot：用于主备机复制使用，主备机状态的交互pg_perf：性能视图

先输入sqlite3 文件名一、创建表创建表语法CREATE TABLE table_name(name1 type)字段修饰符primary key 定义主键列AUTOINCREMENT 自动增长UNIQUE 字段的值唯一NOT NULL 字段的值不为空二、删除表DROP TABLE 表名三、修改表3.1 添加字段add3.2 删除字段(mysql)3.3 修改字段modify和change(mysql)changemodify3.4 指定增加的字段在表中显示的位置(mysql)3.5 表重命名四、内置命令.table：查看表是否创建成功.schema：查看列表的完整信息五、DMLsqlite3中没有命令 truncate table清空表：用delete from 表名字

一、执行计划 1. SQL执行计划概述SQL执行计划是一个节点树，显示MogDB执行一条SQL语句时执行的详细步骤。每一个步骤为一个数据库运算符。 使用EXPLAIN命令可以查看优化器为每个查询生成的具体执行计划。EXPLAIN给每个执行节点都输出一行，显示基本的节点类型和优化器为执行这个节点预计的开销值。如图1所示。 SQL执行计划示例最底层节点是表扫描节点，它扫描表并返回原始数据行。不同的表访问模式有不同的扫描节点类型: 顺序扫描、索引扫描等。最底层节点的扫描对象也可能是非表行数据（不是直接从表中读取的数据），如VALUES子句和返回行集的函数，它们有自己的扫描节点类型。如果查询需要连接、聚集、排序、或者对原始行做其它操作，那么就会在扫描节点之上添加其它节点。 并且这些操作通常都有多种方法，因此在这些位置也有可能出现不同的执行节点类型。第一行（最上层节点）是执行计划总执行开销的预计。这个数值就是优化器试图最小化的数值。 2. 执行计划显示信息除了设置不同的执行计划显示格式外，还可以通过不同的EXPLAIN用法，显示不同详细程度的执行计划信息。常见有如下几种: EXPLAIN statement：只生成执行计划，不实际执行。其中statement代表SQL语句。EXPLAIN ANALYZE statement：生成执行计划，进行执行，并显示执行的概要信息。显示中加入了实际的运行时间统计，包括在每个规划节点内部花掉的总时间（以毫秒计）和它实际返回的行数。EXPLAIN PERFORMANCE statement：生成执行计划，进行执行，并显示执行期间的全部信息。为了测量运行时在执行计划中每个节点的开销，EXPLAIN ANALYZE或EXPLAIN PERFORMANCE会在当前查询执行上增加性能分析的开销。在一个查询上运行EXPLAIN ANALYZE或EXPLAIN PERFORMANCE有时会比普通查询明显的花费更多的时间。超支的数量依赖于查询的本质和使用的平台。 因此，当定位SQL运行慢问题时，如果SQL长时间运行未结束，建议通过EXPLAIN命令查看执行计划，进行初步定位。如果SQL可以运行出来，则推荐使用EXPLAIN ANALYZE或EXPLAIN PERFORMANCE查看执行计划及其实际的运行信息，以便更精准地定位问题原因。 EXPLAIN PERFORMANCE轻量化执行方式与EXPLAIN PERFORMANCE保持一致，在原来的基础上减少了性能分析的时间，执行时间与SQL执行时间的差异显著减少3. 详解如SQL执行计划概述节中所说，EXPLAIN会显示执行计划，但并不会实际执行SQL语句。EXPLAIN ANALYZE和EXPLAIN PERFORMANCE两者都会实际执行SQL语句并返回执行信息。在这一节将详细解释执行计划及执行信息。4. 执行计划以如下SQL语句为例:```sql SELECT * FROM t1, t2 WHERE t1.c1 = t2.c2; ```执行EXPLAIN的输出为:执行计划层级解读（纵向）: 第一层: Seq Scan on t2  表扫描算子，用Seq Scan的方式扫描表t2。这一层的作用是把表t2的数据从buffer或者磁盘上读上来输送给上层节点参与计算。 第二层: Hash  Hash算子，作用是把下层计算输送上来的算子计算hash值，为后续hash join操作做数据准备。 第三层: Seq Scan on t1  表扫描算子，用Seq Scan的方式扫描表t1。这一层的作用是把表t1的数据从buffer或者磁盘上读上来输送给上层节点参与hash join计算。 第四层: Hash Join  join算子，主要作用是将t1表和t2表的数据通过hash join的方式连接，并输出结果数据。 执行计划中的关键字说明: 表访问方式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，那么不是所有的行都会被检索到。 执行信息```sql select sum(t2.c1) from t1,t2 where t1.c1=t2.c2 group by t1.c2; ```执行EXPLAIN PERFORMANCE输出为:二、 SMP并行执行1. 特性简介 MogDB的SMP并行技术是一种利用计算机多核CPU架构来实现多线程并行计算，以充分利用CPU资源来提高查询性能的技术。 2. 特性描述 在复杂查询场景中，单个查询的执行较长，系统并发度低，通过SMP并行执行技术实现算子级的并行，能够有效减少查询执行时间，提升查询性能及资源利用率。SMP并行技术的整体实现思想是对于能够并行的查询算子，将数据分片，启动若干个工作线程分别计算，最后将结果汇总，返回前端。SMP并行执行增加数据交互算子Stream，实现多个工作线程之间的数据交互，确保查询的正确性，完成整体的查询。 SMP特性通过算子并行来提升性能，同时会占用更多的系统资源，包括CPU、内存、I/O等等。本质上SMP是一种以资源换取时间的方式，在合适的场景以及资源充足的情况下，能够起到较好的性能提升效果；但是如果在不合适的场景下，或者资源不足的情况下，反而可能引起性能的劣化。SMP特性适用于分析类查询场景，这类场景的特点是单个查询时间较长，业务并发度低。通过SMP并行技术能够降低查询时延，提高系统吞吐性能。然而在事务类大并发业务场景下，由于单个查询本身的时延很短，使用多线程并行技术反而会增加查询时延，降低系统吞吐性能。3. 适用场景支持并行的算子：计划中存在以下算子支持并行。   Scan：支持行存普通表和行存分区表顺序扫描 、列存普通表和列存分区表顺序扫描。  Join：HashJoin、NestLoop  Agg：HashAgg、SortAgg、PlainAgg、WindowAgg（只支持partition by，不支持order by）  Stream：Local Redistribute、Local Broadcast  其他：Result、Subqueryscan、Unique、Material、Setop、Append、VectoRow。 SMP特有算子：为了实现并行，新增了并行线程间的数据交换Stream算子供SMP特性使用。这些新增的算子可以看做Stream算子的子类。  Local Gather：实现实例内部并行线程的数据汇总。  Local Redistribute：在实例内部各线程之间，按照分布键进行数据重分布。  Local Broadcast：将数据广播到实例内部的每个线程。  Local RoundRobin：在实例内部各线程之间实现数据轮询分发。示例说明，以TPCH Q1的并行计划为例。在这个计划中，实现了Scan以及HashAgg算子的并行，并新增了Local Gather数据交换算子。其中3号算子为Local Gather算子，上面标有的“dop: 1/4”表明该算子的发送端线程的并行度为4，而接受端线程的并行度为1，即下层的4号HashAggregate算子按照4并行度执行，而上层的1~2号算子按照串行执行，3号算子实现了实例内并行线程的数据汇总。 通过计划Stream算子上表明的dop信息即可看出各个算子的并行情况。 4. 非适用场景 索引扫描不支持并行执行。MergeJoin不支持并行执行。WindowAgg order by不支持并行执行。cursor不支持并行执行。存储过程和函数内的查询不支持并行执行。不支持子查询subplan和initplan的并行，以及包含子查询的算子的并行。查询语句中带有median操作的查询不支持并行执行。带全局临时表的查询不支持并行执行。物化视图的更新不支持并行执行。5. 资源对SMP性能的影响SMP架构是一种利用富余资源来换取时间的方案，计划并行之后必定会引起资源消耗的增加，包括CPU、内存、I/O等资源的消耗都会出现明显的增长，而且随着并行度的增大，资源消耗也随之增大。当上述资源成为瓶颈的情况下，SMP无法提升性能，反而可能导致集群整体性能的劣化。下面对各种资源对SMP性能的影响情况分别进行说明。 CPU资源 在一般客户场景中，系统CPU利用率不高的情况下，利用SMP并行架构能够更充分地利用系统CPU资源，提升系统性能。但当数据库服务器的CPU核数较少，CPU利用率已经比较高的情况下，如果打开SMP并行，不仅性能提升不明显，反而可能因为多线程间的资源竞争而导致性能劣化。 内存资源 查询并行后会导致内存使用量的增长，但每个算子使用内存上限仍受到work_mem等参数的限制。假设work_mem为4GB，并行度为2，那么每个并行线程所分到的内存上限为2GB。在work_mem较小或者系统内存不充裕的情况下，使用SMP并行后，可能出现数据下盘，导致查询性能劣化的问题。 I/O资源 要实现并行扫描必定会增加I/O的资源消耗，因此只有在I/O资源充足的情况下，并行扫描才能够提高扫描性能。 6. 其他因素对SMP性能的影响除了资源因素外，还有一些因素也会对SMP并行性能造成影响。例如分区表中分区数据不均，以及系统并发度等因素。 数据倾斜对SMP性能的影响 当数据中存在严重数据倾斜时，并行效果较差。例如某表join列上某个值的数据量远大于其他值，开启并行后，根据join列的值对该表数据做hash重分布，使得某个并行线程的数据量远多于其他线程，造成长尾问题，导致并行后效果差。 系统并发度对SMP性能的影响 SMP特性会增加资源的使用，而在高并发场景下资源剩余较少。所以，如果在高并发场景下，开启SMP并行，会导致各查询之间严重的资源竞争问题。一旦出现了资源竞争的现象，无论是CPU、I/O、内存，都会导致整体性能的下降。因此在高并发场景下，开启SMP往往不能达到性能提升的效果，甚至可能引起性能劣化。 7. SMP 使用建议使用限制想要利用SMP提升查询性能需要满足以下条件： 系统的CPU、内存、I/O和网络带宽等资源充足。SMP架构是一种利用富余资源来换取时间的方案，计划并行之后必定会引起资源消耗的增加，当上述资源成为瓶颈的情况下，SMP无法提升性能，反而可能导致性能的劣化。在出现资源瓶颈的情况下，建议关闭SMP。 配置步骤  观察当前系统负载情况，如果系统资源充足（资源利用率小于50%），执行步骤2；否则退出。   设置query_dop=1（默认值），利用explain打出执行计划，观察计划是否符合SMP适用场景与限制小节中的适用场景。如果符合，进入步骤3。   设置query_dop=value，不考虑资源情况和计划特征，强制选取dop为1或value。   在符合条件的查询语句执行前设置合适的query_dop值，在语句执行结束后关闭query_dop。举例如下。```sql MogDB=SET query_dop = 4; MogDB=SELECT COUNT(*) FROM t1 GROUP BY a; ...... MogDB=SET query_dop = 1; Copy ``` 说明:资源许可的情况下，并行度越高，性能提升效果越好。SMP并行度支持会话级设置，推荐客户在执行符合要求的查询前，打开smp，执行结束后，关闭smp。以免在业务峰值时，对业务造成冲击。5. query_dop参数说明: 用户自定义的查询并行度。 该参数属于USERSET类型参数，请参考表GUC参数分类中对应设置方法进行设置。 取值范围: 整型，1~64。打开固定SMP功能，系统会使用固定并行度。  说明: 在开启并行查询后，请保证系统CPU、内存、网络等资源充足，以达到最佳效果。 默认值: 1 三、测试 1. 构建测试数据```sql [omm@node1 ~]$ gsql -d postgres -p26000 -r gsql ((openGauss 3.1.0 build 2c0ccaf9) compiled at 2022-09-25 19:32:58 commit 0 last mr ) Non-SSL connection (SSL connection is recommended when requiring high-security) Type "help" for help. openGauss=create table test (id int,en varchar(200)); CREATE TABLE Time: 9.511 ms openGauss=insert into test values(generate_series(1,10000000),md5(random()::text)); INSERT 0 10000000 Time: 25792.555 ms openGauss=\d+ List of relations Schema | Name | Type | Owner | Size | Storage | Description --------+------+-------+-------+--------+----------------------------------+------------- public | test | table | omm | 657 MB | {orientation=row,compression=no} | (1 row) ```2. CPU为16c时query_dop=1 ```sql openGauss=\timing Timing is on. openGauss=set query_dop=1; SET Time: 0.322 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 1603.324 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 673.562 ms ``` query_dop=4 ```sql openGauss=set query_dop=4; SET Time: 0.306 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 210.510 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 217.283 ms ``` query_dop=8 ```sql openGauss=set query_dop=8; SET Time: 0.258 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 165.018 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 157.060 ms ``` query_dop=16 ```sql openGauss=set query_dop=16; SET Time: 0.274 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 173.323 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 163.022 ms ``` 3. CPU为8c query_dop=1 ```sql openGauss=set query_dop=1; SET Time: 0.242 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 3426.668 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 990.474 ms ``` query_dop=4 ```sql openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 349.525 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 381.206 ms ``` query_dop=8 ```sql openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 283.316 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 277.508 ms ``` query_dop=16 ```sql openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 189.836 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 188.878 ms ```4. CPU为4cquery_dop=1 ```sql openGauss=\timing Timing is on. openGauss=set query_dop=1; SET Time: 0.314 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 3119.898 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 972.142 ms ``` query_dop=4 ```sql openGauss=set query_dop=4; SET Time: 0.267 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 380.970 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 337.972 ms ``` query_dop=8 ```sql openGauss=set query_dop=8; SET Time: 0.297 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 258.877 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 266.643 ms ``` query_dop=16 ```sql openGauss=set query_dop=16; SET Time: 0.306 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 224.949 ms openGauss=select * from test where id=999; id | en -----+---------------------------------- 999 | 4b9d69053e3de0ed30e1b9e3283f7270 (1 row) Time: 216.097 ms ```汇总并行度  16c SQL执行时间8c SQL 执行时间 4c SQL执行时间query_dop=1 660 ms 990 ms  972 ms  query_dop=4 215 ms 349 ms  380 ms query_dop=8165 ms 277 ms  258 ms query_dop=16166 ms 188 ms  224 ms query_dop=32 200 ms 243 ms  305 ms query_dop=64325 ms 387 ms  440 ms 

一、闪回恢复闪回恢复功能是数据库恢复技术的一环，可以有选择性的撤销一个已提交事务的影响，将数据从人为不正确的操作中进行恢复。在采用闪回技术之前，只能通过备份恢复、PITR等手段找回已提交的数据库修改，恢复时长需要数分钟甚至数小时。采用闪回技术后，恢复已提交的数据库修改前的数据，只需要秒级，而且恢复时间和数据库大小无关。   说明: ASTORE引擎暂不支持闪回DROP/TRUNCATE。 1. 闪回支持两种恢复模式： 基于MVCC多版本的数据恢复（仅支持Ustore）：适用于误删除、误更新、误插入数据的查询和恢复，用户通过配置旧版本保留时间，并执行相应的查询或恢复命令，查询或恢复到指定的时间点或CSN点。基于数据库回收站的恢复（仅支持Ustore）：适用于误DROP、误TRUNCATE的表的恢复。用户通过配置回收站开关，并执行相应的恢复命令，可以将误DROP、误TRUNCATE的表找回。 相关参数：   enable_default_ustore_table=on     开启默认支持Ustore存储引擎   undo_retention_time     设置undo旧版本保留时间。等同于允许闪回查询的时间跨度，超过该时间闪回查询可能会报restore point not found错误。   enable_recyclebin=on     打开回收站   recyclebin_retention_time=15min     设置回收站对象保留时间，超过该时间的回收站对象将被自动清理  二、闪回查询 1. 背景信息闪回查询可以查询过去某个时间点表的某个snapshot数据，这一特性可用于查看和逻辑重建意外删除或更改的受损数据。闪回查询基于MVCC多版本机制，通过检索查询旧版本，获取指定老版本数据。 2. 前提条件undo_retention_time参数用于设置undo旧版本的保留时间。   3. 语法 FlashBack ::= ( select_statement) TIMECAPSULE { TIMESTAMP | CSN } expression语法树中“TIMECAPSULE {TIMESTAMP | CSN} expression”为闪回功能新增表达方式，其中TIMECAPSULE表示使用闪回功能，TIMESTAMP以及CSN表示闪回功能使用具体时间点信息或使用CSN（commit sequence number）信息。 4. 参数说明TIMESTAMP  指要查询某个表在TIMESTAMP这个时间点上的数据，TIMESTAMP指一个具体的历史时间。CSN  指要查询整个数据库逻辑提交序下某个CSN点的数据，CSN指一个具体逻辑提交时间点，数据库中的CSN为写一致性点，每个CSN代表整个数据库的一个一致性点，查询某个CSN下的数据代表SQL查询数据库在该一致性点的相关数据。5. 使用示例 示例1：```sql SELECT * FROM t1 TIMECAPSULE TIMESTAMP to_timestamp ('2020-02-11 10:13:22.724718', 'YYYY-MM-DD HH24:MI:SS.FF'); ```示例2：```sql SELECT * FROM t1 TIMECAPSULE CSN 9617; ```示例3：```sql SELECT * FROM t1 AS t TIMECAPSULE TIMESTAMP to_timestamp ('2020-02-11 10:13:22.724718', 'YYYY-MM-DD HH24:MI:SS.FF'); ```示例4：```sql SELECT * FROM t1 AS t TIMECAPSULE CSN 9617; ```三、闪回表1. 背景信息闪回表可以将表恢复至特定时间点，当逻辑损坏仅限于一个或一组表，而不是整个数据库时，此特性可以快速恢复表的数据。闪回表基于MVCC多版本机制，通过删除指定时间点和该时间点之后的增量数据，并找回指定时间点和当前时间点删除的数据，实现表级数据还原。 2. 前提条件undo_retention_time参数用于设置undo旧版本的保留时间。3. 语法FlashBack ::= TIMECAPSULE TABLE table_name TO { TIMESTAMP | CSN } expression4. 使用示例```sql TIMECAPSULE TABLE t1 TO TIMESTAMP to_timestamp ('2020-02-11 10:13:22.724718', 'YYYY-MM-DD HH24:MI:SS.FF'); TIMECAPSULE TABLE t1 TO CSN 9617; ```四、闪回DROP/TRUNCATE1. 背景信息闪回DROP：可以恢复意外删除的表，从回收站（recycle bin）中恢复被删除的表及其附属结构如索引、表约束等。闪回drop是基于回收站机制，通过还原回收站中记录的表的物理文件，实现已drop表的恢复。 闪回TRUNCATE：可以恢复误操作或意外被进行truncate的表，从回收站中恢复被truncate的表及索引的物理数据。闪回truncate基于回收站机制，通过还原回收站中记录的表的物理文件，实现已truncate表的恢复。 2. 前提条件开启enable_recyclebin参数，启用回收站。recyclebin_retention_time参数用于设置回收站对象保留时间，超过该时间的回收站对象将被自动清理。3. 相关语法 删除表DropTable ::= DROP TABLE table_name [PURGE]清理回收站对象PurgeRecyclebin ::= PURGE { TABLE { table_name } | INDEX { index_name } | RECYCLEBIN }闪回被删除的表TimecapsuleTable ::= TIMECAPSULE TABLE { table_name } TO BEFORE DROP [RENAME TO new_tablename]截断表TruncateTable ::= TRUNCATE TABLE { table_name } [ PURGE ]闪回截断的表TimecapsuleTable ::= TIMECAPSULE TABLE { table_name } TO BEFORE TRUNCATE五、参数说明DROP/TRUNCATE TABLE table_name PURGE  默认将表数据放入回收站中，PURGE直接清理。PURGE RECYCLEBIN  表示清理回收站对象。TO BEFORE DROP使用这个子句检索回收站中已删除的表及其子对象。 可以指定原始用户指定的表的名称，或对象删除时数据库分配的系统生成名称。 回收站中系统生成的对象名称是唯一的。因此，如果指定系统生成名称，那么数据库检索指定的对象。使用“select * from pg_recyclebin;”语句查看回收站中的内容。如果指定了用户指定的名称，且如果回收站中包含多个该名称的对象，然后数据库检索回收站中最近移动的对象。如果想要检索更早版本的表，你可以这样做：  指定你想要检索的表的系统生成名称。  执行TIMECAPSULE TABLE … TO BEFORE DROP语句，直到你要检索的表。  恢复DROP表时，只恢复基表名，其他子对象名均保持回收站对象名。用户可根据需要，执行DDL命令手工调整子对象名。  回收站对象不支持DML、DCL、DDL等写操作，不支持DQL查询操作（后续支持）。  闪回点和当前点之间，执行过修改表结构或影响物理结构的语句，闪回失败。涉及namespace、表名改变等操作的DDL执行闪回报错： ERROR: recycle object %s desired does not exis；增加/删除/切割/合成等分区改变等操作的DDL执行闪回报错： ERROR: relation %s does not exis；其他情况报错：“ERROR：The table definition of %s has been changed. ”。RENAME TO为从回收站中检索的表指定一个新名称。 TO BEFORE TRUNCATE闪回到TRUNCATE之前。 六、语法示例```sql DROP TABLE t1 PURGE; PURGE TABLE t1; PURGE TABLE "BIN$04LhcpndanfgMAAAAAANPw==$0"; PURGE INDEX i1; PURGE INDEX "BIN$04LhcpndanfgMAAAAAANPw==$0"; PURGE RECYCLEBIN; TIMECAPSULE TABLE t1 TO BEFORE DROP; TIMECAPSULE TABLE t1 TO BEFORE DROP RENAME TO new_t1; TIMECAPSULE TABLE "BIN$04LhcpndanfgMAAAAAANPw==$0" TO BEFORE DROP; TIMECAPSULE TABLE "BIN$04LhcpndanfgMAAAAAANPw==$0" TO BEFORE DROP RENAME TO new_t1; ```

一、 账本数据库概述1. 背景信息 账本数据库融合了区块链思想，将用户操作记录至两种历史表中：用户历史表全局区块表  当用户创建防篡改用户表时，系统将自动为该表添加一个hash列来保存每行数据的hash摘要信息，同时在blockchain模式下会创建一张用户历史表来记录对应用户表中每条数据的变更行为；而用户对防篡改用户表的一次修改行为将记录至全局区块表中。由于历史表具有只可追加不可修改的特点，因此历史表记录串联起来便形成了用户对防篡改用户表的修改历史。 用户历史表命名和结构如下： 表 1 用户历史表blockchain.__hist所包含的字段字段名类型 描述   rec_num bigint 行级修改操作在历史表中的执行序号。hash_inshash16INSERT或UPDATE操作插入的数据行的hash值。 hash_delhash16DELETE或UPDATE操作删除的数据行的hash值。 pre_hash hash32 当前用户历史表的数据整体摘要。表 2 hash_ins与hash_del场景对应关系  -     hash_ins              hash_del     INSERT (√) 插入行的hash值 DELETE(√) 删除行的hash值。UPDATE (√) 新插入数据的hash值(√) 删除前该行的hash值。2. 操作步骤(1) 创建防篡改模式。 例如，创建防篡改模式ledgernsp。```sql MogDB=CREATE SCHEMA ledgernsp WITH BLOCKCHAIN; ```2. 在防篡改模式下创建防篡改用户表。 例如，创建防篡改用户表ledgernsp.usertable。```sql MogDB=CREATE TABLE ledgernsp.usertable(id int, name text); ```查看防篡改用户表结构及其对应的用户历史表结构。```sql MogDB=\d+ ledgernsp.usertable; MogDB=\d+ blockchain.ledgernsp_usertable_hist; ```执行结果如下：```sql MogDB=\d+ ledgernsp.usertable; Table "ledgernsp.usertable" Column | Type | Modifiers | Storage | Stats target | Description --------+---------+-----------+----------+--------------+------------- id | integer | | plain | | name | text | | extended | | hash | hash16 | | plain | | Has OIDs: no Distribute By: HASH(id) Location Nodes: ALL DATANODES Options: orientation=row, compression=no History table name: ledgernsp_usertable_hist MogDB=\d+ blockchain.ledgernsp_usertable_hist; Table "blockchain.ledgernsp_usertable_hist" Column | Type | Modifiers | Storage | Stats target | Description ----------+--------+-----------+---------+--------------+------------- rec_num | bigint | | plain | | hash_ins | hash16 | | plain | | hash_del | hash16 | | plain | | pre_hash | hash32 | | plain | | Indexes: "gs_hist_16388_index" PRIMARY KEY, btree (rec_num int4_ops) TABLESPACE pg_default Has OIDs: no Options: internal_mask=263 ```说明:防篡改表不支持非行存表、临时表、外表、unlog表、非行存表均无防篡改属性。防篡改表在创建时会自动增加一个名为hash的系统列，所以防篡改表单表最大列数为1599。 3. 修改防篡改用户表数据。 例如，对防篡改用户表执行INSERT/UPDATE/DELETE。```sql MogDB=INSERT INTO ledgernsp.usertable VALUES(1, 'alex'), (2, 'bob'), (3, 'peter'); INSERT 0 3 MogDB=SELECT *, hash FROM ledgernsp.usertable ORDER BY id; id | name | hash ----+-------+------------------ 1 | alex | 1f2e543c580cb8c5 2 | bob | 8fcd74a8a6a4b484 3 | peter | f51b4b1b12d0354b (3 rows) MogDB=UPDATE ledgernsp.usertable SET name = 'bob2' WHERE id = 2; UPDATE 1 MogDB=SELECT *, hash FROM ledgernsp.usertable ORDER BY id; id | name | hash ----+-------+------------------ 1 | alex | 1f2e543c580cb8c5 2 | bob2 | 437761affbb7c605 3 | peter | f51b4b1b12d0354b (3 rows) MogDB=DELETE FROM ledgernsp.usertable WHERE id = 3; DELETE 1 MogDB=SELECT *, hash FROM ledgernsp.usertable ORDER BY id; id | name | hash ----+------+------------------ 1 | alex | 1f2e543c580cb8c5 2 | bob2 | 437761affbb7c605 (2 rows) ```二、查看账本历史操作记录 1. 前提条件 系统中需要有审计管理员或者具有审计管理员权限的角色。数据库正常运行，并且对防篡改数据库执行了一系列增、删、改等操作，保证在查询时段内有账本操作记录结果产生。 2. 背景信息只有拥有AUDITADMIN属性的用户才可以查看账本历史操作记录。有关数据库用户及创建用户的办法请参见[管理用户及权限](https://docs.mogdb.io/zh/mogdb/v3.0/2-managing-users-and-their-permissions)。 查询全局区块表命令是直接查询gs_global_chain表，操作为：```sql SELECT * FROM gs_global_chain; ```该表有11个字段，每个字段的含义见章节[GS_GLOBAL_CHAIN](https://docs.mogdb.io/zh/mogdb/v3.0/GS_GLOBAL_CHAIN)。 查询用户历史表的命令是直接查询BLOCKCHAIN模式下的用户历史表，操作为： 例如用户表所在的模式为ledgernsp，表名为usertable，则对应的用户历史表名为blockchain.ledgernsp_usertable_hist；```sql SELECT * FROM blockchain.ledgernsp_usertable_hist; ```用户历史表有4个字段，每个字段的含义见[表1](https://docs.mogdb.io/zh/mogdb/v3.0/5-setting-a-ledger-databasetable1)。  说明: 用户历史表的表名一般为blockchain.hist形式。当防篡改用户表模式名或者表名过长导致前述方式生成的表名超出表名长度限制，则会采用blockchain.hist的方式命名。3. 操作步骤以操作系统用户omm登录数据库主节点。使用如下命令连接数据库。```sql gsql -d postgres -p 8000 ```postgres为需要连接的数据库名称，8000为端口号。  4. 查询全局区块表记录。```sql MogDB=SELECT * FROM gs_global_chain; blocknum | dbname | username | starttime | relid | relnsp | relname | relhash | globalhash | txcommand ----------+----------+----------+-------------------------------+-------+-----------+-----------+------------------+----------------------------------+------------------ ------------------------------------------------------------ 0 | postgres | omm | 2021-04-14 07:00:46.32757+08 | 16393 | ledgernsp | usertable | a41714001181a294 | 6b5624e039e8aee36bff3e8295c75b40 | insert into ledge rnsp.usertable values(1, 'alex'), (2, 'bob'), (3, 'peter'); 1 | postgres | omm | 2021-04-14 07:01:19.767799+08 | 16393 | ledgernsp | usertable | b3a9ed0755131181 | 328b48c4370faed930937869783c23e0 | update ledgernsp. usertable set name = 'bob2' where id = 2; 2 | postgres | omm | 2021-04-14 07:01:29.896148+08 | 16393 | ledgernsp | usertable | 0ae4b4e4ed2fcab5 | aa8f0a236357cac4e5bc1648a739f2ef | delete from ledge rnsp.usertable where id = 3; ```该结果表明，用户omm连续执行了三条DML命令，包括INSERT、UPDATE和DELETE操作。 5. 查询历史表记录。```sql MogDB=SELECT * FROM blockchain.ledgernsp_usertable_hist; rec_num | hash_ins | hash_del | pre_hash ---------+------------------+------------------+---------------------------------- 0 | 1f2e543c580cb8c5 | | e1b664970d925d09caa295abd38d9b35 1 | 8fcd74a8a6a4b484 | | dad3ed8939a141bf3682043891776b67 2 | f51b4b1b12d0354b | | 53eb887fc7c4302402343c8914e43c69 3 | 437761affbb7c605 | 8fcd74a8a6a4b484 | c2868c5b49550801d0dbbbaa77a83a10 4 | | f51b4b1b12d0354b | 9c512619f6ffef38c098477933499fe3 (5 rows) ```查询结果显示，用户omm对ledgernsp.usertable表插入了3条数据，更新了1条数据，随后删除了1行数据，最后剩余2行数据，hash值分别为1f2e543c580cb8c5和437761affbb7c605。 6. 查询用户表数据及hash校验列。```sql MogDB=SELECT *, hash FROM ledgernsp.usertable; id | name | hash ----+------+------------------ 1 | alex | 1f2e543c580cb8c5 2 | bob2 | 437761affbb7c605 (2 rows) ```查询结果显示，用户表中剩余2条数据，与步骤4中的记录一致。 三、校验账本数据一致性1. 前提条件 数据库正常运行，并且对防篡改数据库执行了一系列增、删、改等操作，保证在查询时段内有账本操作记录结果产生。 2. 背景信息账本数据库校验功能目前提供两种校验接口，分别为：]ledger_hist_check(text, text)](https://docs.mogdb.io/zh/mogdb/v3.0/20.1-ledger-database-functions)和[ledger_gchain_check(text, text)](https://docs.mogdb.io/zh/mogdb/v3.0/20.1-ledger-database-functions)。普通用户调用校验接口，仅能校验自己有权限访问的表。 校验防篡改用户表和用户历史表的接口为pg_catalog.ledger_hist_check，操作为：```sql SELECT pg_catalog.ledger_hist_check(schema_name text,table_name text); ```如果校验通过，函数返回t，反之则返回f。校验防篡改用户表、用户历史表和全局区块表三者是否一致的接口为pg_catalog.ledger_gchain_check，操作为：```sql SELECT pg_catalog.ledger_gchain_check(schema_name text, table_name text); ```如果校验通过，函数返回t，反之则返回f。 3. 操作步骤 校验防篡改用户表ledgernsp.usertable与其对应的历史表是否一致。```sql MogDB=SELECT pg_catalog.ledger_hist_check('ledgernsp', 'usertable'); ledger_hist_check ------------------- t (1 row) ```该结果表明防篡改用户表和用户历史表中记录的结果能够一一对应，保持一致。 查询防篡改用户表ledgernsp.usertable与其对应的历史表以及全局区块表中关于该表的记录是否一致。```sql MogDB= SELECT pg_catalog.ledger_gchain_check('ledgernsp', 'usertable'); ledger_gchain_check --------------------- t (1 row) ```查询结果显示，上述三表中关于ledgernsp.usertable的记录保持一致，未发生篡改行为。 四、归档账本数据库1. 前提条件系统中需要有审计管理员或者具有审计管理员权限的角色。数据库正常运行，并且对防篡改数据库执行了一系列增、删、改等操作，保证在查询时段内有账本操作记录结果产生。数据库已经正确配置审计文件的存储路径audit_directory。2. 背景信息账本数据库归档功能目前提供两种校验接口，分别为：[ledger_hist_archive(text, text)](https://docs.mogdb.io/zh/mogdb/v3.0/20.1-ledger-database-functions)和[ledger_gchain_archive(void)](https://docs.mogdb.io/zh/mogdb/v3.0/20.1-ledger-database-functions)。账本数据库接口仅审计管理员可以调用。 归档用户历史表的接口为pg_catalog.ledger_hist_archive，操作为：```sql SELECT pg_catalog.ledger_hist_archive(schema_name text,table_name text); ```如果归档成功，函数返回t，反之则返回f。 归档全局区块表的接口为pg_catalog.ledger_gchain_archive，操作为：```sql SELECT pg_catalog.ledger_gchain_archive(); ```如果归档成功，函数返回t，反之则返回f。 3. 操作步骤对指定用户历史表进行归档操作。```sql MogDB=SELECT pg_catalog.ledger_hist_archive('ledgernsp', 'usertable') ledger_hist_archive --------------------- t (1 row) ```用户历史表将归档为一条数据：```sql MogDB=SELECT * FROM blockchain.ledgernsp_usertable_hist; rec_num | hash_ins | hash_del | pre_hash ---------+------------------+------------------+---------------------------------- 3 | e78e75b00d396899 | 8fcd74a8a6a4b484 | fd61cb772033da297d10c4e658e898d7 (1 row) ```该结果表明当前节点用户历史表导出成功。 执行全局区块表导出操作。```sql MogDB=SELECT pg_catalog.ledger_gchain_archive(); ledger_gchain_archive ----------------------- t (1 row) ```全局历史表将以用户表为单位归档为N（用户表数量）条数据：```sql MogDB=SELECT * FROM gs_global_chain; blocknum | dbname | username | starttime | relid | relnsp | relname | relhash | globalhash | txcommand ----------+----------+----------+-------------------------------+-------+-----------+-----------+------------------+----------------------------------+----------- 1 | postgres | libc | 2021-05-10 19:59:38.619472+08 | 16388 | ledgernsp | usertable | 57c101076694b415 | be82f98ee68b2bc4e375f69209345406 | Archived. (1 row) ```该结果表明，当前节点全局区块表导出成功。 五、修复账本数据库1. 前提条件系统中需要有审计管理员或者具有审计管理员权限的角色。数据库正常运行，并且对防篡改数据库执行了一系列增、删、改等操作，保证在查询时段内有账本操作记录结果产生。2. 背景信息当在异常情况或表被损坏时需要使用[账本数据库](https://docs.mogdb.io/zh/mogdb/v3.0/5-setting-a-ledger-database)的函数章节中的ledger_gchain_repair(text, text)或ledger_hist_repair(text, text)接口对全局区块表或用户历史表进行修复，修复后调用全局区块表或用户历史表校验接口结果为true。 修复用户历史表的接口为pg_catalog.ledger_hist_repair，操作为：```sql SELECT pg_catalog.ledger_hist_repair(schema_name text,table_name text); ```如果修复成功，函数返回修复过程中用户历史表hash的增量。 归档全局区块表的接口为pg_catalog.ledger_gchain_repair，操作为：```sql SELECT pg_catalog.ledger_gchain_repair(schema_name text,table_name text); ```如果修复成功，函数返回修复过程中全局区块表hash的增量。 3. 操作步骤执行历史表修复操作。```sql MogDB=SELECT pg_catalog.ledger_hist_repair('ledgernsp', 'usertable'); ledger_hist_repair -------------------- 84e8bfc3b974e9cf (1 row) ```该结果表明当前节点用户历史表修复成功，修复造成的用户历史表hash增量为84e8bfc3b974e9cf。 执行全局区块表修复操作。```sql MogDB=SELECT pg_catalog.ledger_gchain_repair('ledgernsp', 'usertable'); ledger_gchain_repair ---------------------- a41714001181a294 (1 row) ```该结果表明，全局区块表修复成功，且插入一条修复数据，其hash值为a41714001181a294。

导航SQL语法创建数据库数据查询御酒数据操纵语言C API一、SQL语言数据定义(DDL) :用户定义、删除和修改数据模式数据查询(DQL) :用于查询数据数据操纵(DML) :用于增、删、改数据数据控制(DCL) :用于控制数据访问权限SQL的语法很像自然语言。每个语句都是一一个祈使句，以动词开头，表示所要做的动作。SQL由命令组成，每个命令以分号（;）结束，例如1.1 数字类型有三种：字符串常量、数据常量和二进制常量1.1.1 整型1.1.2 浮点型整型、浮点型、定点型浮点型：float(M, D); double(M, D)D表示浮点型数据小数点之后的精度，假如超过D位则四舍五入，即1.233四舍五入为1.23， 1.237四舍五入为1.24M表示浮点型数据总共的位数，D-2则表示总共支持五位，即小数点前只支持三位数create table test_float{ num float(5, 2) }; -- engine = innodb charset = utf8; insert into test_float values(1.233) insert into test_float values(1.237) insert into test_float values(10.233) insert into test_float values(100.233) insert into test_float values(1000.233)1.1.3 定点型定点型（金融行业）decimaldecmal在不指定M. D时默认为decmal(10，0)create table test_decimal{ float_num float(10, 2), double_num double(20, 2), decimal_num decimal(20, 2) }; insert into test_decimal values(123546565.23112, 16000000.33, 66666666.12) insert into test_decimal values(1235465655.23112, 1600000000.33, 6665566666.12)1.1.4 浮点型和定点型浮点型VSdecimalfloat、double类型存在精度丢失问题，即写入数据库的数据未必是插入数据库的数据decimal无论写入数据中的数据是多少，都不会存在精度丢失问题，decimal类型常见于银行系统、互联网金融系统等对小数点后的数字比较敏感的系统中1.2 日期类型create table test_time{ date_value date, time_value time, year_value datetime, datetime_value datetime, timestamp_value timestamp } insert into test_time values(now(), now(), now(), now(), now());1.3 字符串类型CHAR和VARCHARchar是固定长度字符串，其长度范围为0~255且与编码方式无关，无论字符实际长度是多少，都会按照指定长度存储，不够的用空格补足varchar为可变长度字符串（用的最多），在utf8编码的数据库中其长度范围为0~21844，如：1024char实际占用的字节数即存储的字符所古用的字节数，varchar实际占用的字 节数为存储的字符+1或+2或+3MySQL处理char类型数据时会将结尾的所有空格处理掉而varchar类型数据则不会SQL 7BINARY和VARBINARY（用不到）BLOB和TEXT二、SQLite 存储类SQLite 数据类型是一个用来指定任何对象的数据类型的属性。SQLite 中的每一列，每个变量和表达式都有相关的数据类型。可以在创建表的同时使用这些数据类型。SQLite 使用一个更普遍的动态类型系统。在 SQLite 中，值的数据类型与值本身是相关的，而不是与它的容器相关。2.1 Boolean 数据类型SQLite 没有单独的 Boolean 存储类。相反，布尔值被存储为整数 0（false）和 1（true）2.2 Date 与 Time 数据类型

一、数据库的概念嵌入式数据库开发（中间件）保存数据的方式：文件（缺点：无格式保存）–数据库（有格式的）**数据库是什么？**特殊文件（有格式、不能直接读取）通过DBMS软件，输入SQL语句进行数据库读取DBMS：数据库管理系统（软件）DBMS分类：分类NOSQL（Mongodb、Redis）、SQL（sql server（微软）、oracle(银行、电力很多)、mysql）分类大小：大型数据库（百万数据及）：oracle、sql server 中型数据库（万集：mysql） 小型数据库（sqlite3）分类架构：本地（sqlite3）、网络（主从、分布 ）mysql数据库文件格式类型：关系型（二维表）RDBMS、对象一行一元素、一列一属性，唯一标识为主键列DBMS访问方式：SQL语句、API（C/C++/python/java）

 一、 软件讲解  1. SCA 介绍SCA 全称 SQL Compatible Analysis，是一款异构数据库迁移前的 SQL 兼容和性能评估工具。  可用于异构数据迁移前的兼容性评估，评估源数据库中的实际业务 SQL 在目标库中是否存在语法问题，以及评估两款异构数据库中的 SQL 实际执行的性能差异。 本工具目前支持五种源端数据库，包括： Oracle, MySQL, DB2, PostgreSQL, Informix。 **适用于**： MogDB（以及其他基于 openGauss 的数据库） SCA 程序可运行如下 14 种类型的任务：  程序运行相关的任务   I [Initialize]: 初始化，用于初始化 SCA 资料库  L [Apply License]: 申请 License，用于 License 申请的任务 采集相关的任务  OC [Oracle Collection]: Oracle 采集，用于采集 Oracle 数据库中执行过的业务 SQL，需要长时间采集  MC [MySQL Collection]: MySQL 采集，用于采集 MySQL 数据库中执行过的业务 SQL，需提前配置慢日志，然后一次性采集  DC [DB2 Collection]: DB2 采集，用于采集 DB2 数据库中执行过的业务 SQL，需要长时间采集  PC [PostgreSQL Collection]: PostgreSQL 采集，用于采集 PostgreSQL 数据库中执行过的业务 SQL（依赖于 pg_stat_statments 插件），需要长时间采集  IC [Informix Collection]: Informix 采集，用于采集 Informix 数据库中执行过的业务 SQL（需要先手动开启 global sql trace 功能），需要长时间采集 分析相关的任务  OI [Oracle Inspection]: Oracle 兼容评估，用于评估源端 Oracle 中采集到的业务 SQL，在目标端 MogDB 中的实际兼容性  MI [MySQL Inspection]: MySQL 兼容评估，用于评估源端 MySQL 中采集到的业务 SQL，在目标端MogDB 中的实际兼容性  DI [DB2 Inspection]: DB2 兼容评估，用于评估源端 DB2 中采集到的业务 SQL，在目标端 MogDB 中的实际兼容性  PI [PostgreSQL Inspection]: PostgreSQL 兼容评估，用于评估源端 PostgreSQL 中采集到的业务 SQL，在目标端 MogDB 中的实际兼容性  II [Informix Inspection]: Informix 兼容评估，用于评估源端 Informix 中采集到的业务 SQL，在目标端 MogDB 中的实际兼容性  OS [Oracle Simulation]: Oracle 性能评估，用于评估源端 Oracle 中采集到的业务 SQL，在目标端 MogDB 中的执行性能  OIS [Oracle Inspection & Simulation]: Oracle 兼容和性能评估，等同于 OI + OS 两种任务同时进行  **注意：**  兼容评估，需要有完整的源库结构，推荐使用 MTK 工具进行源数据库结构迁移，测试用途下也可使用 SCA 自动创建测试目标库结构 SQL 模拟，需要有完整的源库数据和数据，推荐使用 MTK 工具进行源数据库结构以及数据迁移  2. 操作系统与平台支持 SCA 目前支持在如下操作系统和平台架构下运行：  Linux x86_64 Linux arm64 (ARM 平台由于没有 DB2/Informix 客户端，故不支持 DB2/Informix 数据采集) MacOS (MacOS 版本不支持 openGauss/MogDB 中的 SHA256 加密认证方式)  3. 数据库支持  SCA 目前支持的源端与目标端数据库类型如下：  源端：  Oracle: 不低于10.2  MySQL: 不低于5.5  DB2: 不低于11.5  PostgreSQL: 不低于 9  Informix: 不低于14.10 (更低版本未做验证)  File: MySQL slowlog 目标端：  MogDB/openGauss: 不低于 2.0  PostgreSQL: 不低于 13.0 **注意：** 平台支持，与数据库支持没有相关性，数据库可以运行在其他平台，如 Windows/AIX 等，只要从数据库到 SCA 运行主机网络与端口互通即可。二、SCA 安装使用  1. 部署步骤程序已打包为二进制可执行文件，无需额外的部署操作。 程序文件上传后，确认能正常通过网络连接数据库即可直接使用。  2. 常用命令注意：以下以 x8664 架构下的 Linux 系统为例进行说明，其他 ARM 平台或 MacOS 系统需要修改对应的命令名称。  申请 License (软件第一次运行的时候，需要先联机申请 License) ```s 运行过程中，需要输入用户邮箱 申请到的 License 数据会发送到输入的邮箱中。 将 License 数据拷贝出来，并写入 SCA 同目录中的 license.json 文件内即可 ./sca_linux_x86_64 T L ``` 初始化资料库 (对于同一个目标MogDB数据库，只在第一次运行时需要初始化资料库)```s ./sca_linux_x86_64 T i H <hostP <portN <repodatabaseU <repouserE <repopassworduser <super_userpassword <super_password> ``` Oracle 数据采集 (无需资料库)```s 作为测试用途，可添加如下参数加快 SQL 采集： q 0.001 Q 60 m off ./sca_linux_x86_64 T OC s SCOTT h <hostp <portn <target_dbu <Oracle_usere <Oracle_password> ``` 从指定 MySQL 慢日志采集```s ./sca_linux_x86_64 T MC d <data_directoryslowlog=<slow_logfile> ``` 从指定 MySQL 服务器进行自动采集```s ./sca_linux_x86_64 T MC d <data_directoryh <hostp <portn <target_dbu <MySQL_usere <MySQL_password> ``` 进行 Oracle 兼容评估 (资料库已初始化，且资料库登录信息均为默认值)```s ./sca_linux_x86_64 T OI d <unzipped data directoryn <target_db> ``` 只进行 SQL 模拟 (资料库已初始化，且资料库用户密码信息均为默认值)```s ./sca_linux_x86_64 T OS h <hostp <portn <target_dbd <unzipped data directory> ``` 同时进行SQL兼容度与性能评估 (资料库已初始化)```s ./sca_linux_x86_64 T OIS h <hostp <portn <target_dbu <repo_usere <repo_passwordd <unzipped data directory> ```三、SCA 命令行选项SCA 为纯命令行工具，所有功能均可通过单一的可执行程序完成。  1. 通用选项通用选项在各类任务中均有可能会使用。  help (帮助信息)在使用分析程序前，建议仔细阅读帮助信息（命令： ./sca_linux_x86_64 help）:```s Introduction: SCA is a tool used to do SQL lifecycle inspection and simulation when migration from heterogeneous database to MogDB. Source databases supported as below: 1. Oracle : SQL Inspection, Simulation 2. DB2 : SQL Inspection 3. MySQL : SQL Inspection 4. PostgreSQL : SQL Inspection 5. Informix : SQL Inspection Options: [ Overall ] help : Show help message v, version : Show SCA version T, type : Run type: : I = Init SCA repository : L = Apply for license : [Analysis: Target required] : OI = Oracle Inspection, this is default type : MI = MySQL Inspection : DI = DB2 Inspection : PI = PostgreSQL Inspection : II = Informix Inspection : OS = Oracle Simulation, just like Oracle SPA : OIS = Oracle Inspection & Simulation : [Collection: No need of target DB] : OC = Oracle Collection : MC = MySQL Collection : DC = DB2 Collection : PC = PostgreSQL Collection : IC = Informix Collection d, data : Unzipped data directory for analyzer, or directory for collection D, dataid : Use data with data id existed in the repository w, workers : Parallel workers for tasks, default: 10 x, debug : Enable debug mode l, logfile : Output to both logfile (without progressbar) and screen (with progressbar) L, logonly : Output to only logfile (without progressbar) F, force : Force mode in REPO Creation, drop old objects before create it r, report : Final report file location, default in data directory with name 'report' license : License file, default is [./license.json] sqlmodified : Modified SQL list used in simulation sqlconfig : SQL configuration file (for internal use) sqltransformer : Regular rules for SQL transformation (for internal use) : Format: [{"name": "xxx" : "source": "xxx", : "target": "xxx", : "comment": "xxx"}, ...] steps : Run given steps (with step id or name) in analysis tasks : Valid in type: : OI/MI/DI/PI/OS/OIS : Step valid in order: : 1.load : Load data from file to repository database : 2.make_object : Create source objects in target database : 3.inspect : Do SQL compatible analysis : 4.rollback_object : Rollback source objects created by make_object : 5.simulate : Do SQL performance analysis : 6.html_report : Genarate summary report in HTML format : 7.excel_report : Genarate detail report in Excel format : Option value for example: : steps 'load' : Just load data to repository database : steps 'inspect' : Run steps after 'inspect' (Step 37) : steps '5' : Run steps before 'simulate' (Step 15) : steps '25' : Run steps from 'make_object' to 'simulate' (Step 25) upgrade : Upgrade current binary SCA command [ Repository Connection ] H, repohost : Repository DB Server host address, default: 127.0.0.1 P, repoport : Repository DB server port, default: 5432 N, reponame : Repository database, default: sca_db U, repouser : Repository user, default: sca_repo E, repopassword : Repository password, default: SCA@password user : Administrator used to create repository DB and user, default: mogdb password : Password for Administrator, default: mogdb [ Source & Target Connection ] h, dbhost : Source & Target DB Server host address, default same as H p, dbport : Source & Target DB server port, default same as P n, dbname : Source & Target database, default same as N u, dbuser : Source & Target user, default same as U e, dbpassword : Source & Target password, default same as E targettype : Target database type in analysis tasks, default: MOGDB : Valid type: ORACLE, MOGDB, OPENGAUSS, POSTGRESQL, MYSQL, DB2 [ Collection Options ] q, sqldays : How many days for session sql data, default: 7 Q, sqlinterval : SQL collect interval in seconds, default: 600 s, schemainclude : Users/Schemas included in data collection, default: '' S, schemaexclude : Users/Schemas excluded in data collection : Default: <<depends on DB type>> m, enablemonitor : Starting background monitor process in SQL Collection : Valid values: 1/on/true/t = ENABLE, default: on : 0/off/false/f = DISABLE slowlog : MySQL slowlog for client data collection ignorebindplan: Ingore SQL binds and plans in Oracle data collection sqlcsv : SQL file in csv format for SQL Inspection (@todo) Usage: 0. Apply for license ./sca_linux_x86_64 T L 1. Init repository (used for first running) ./sca_linux_x86_64 T i H <hostP <portN <repodatabaseU <repouserE <repopassworduser <super_userpassword <super_password> 2. Oracle data collection Notice: "q 0.001 Q 60" means gather Session SQL only once # "m off" means do not monitor system status (CPU Idle and Disk Free) ./sca_linux_x86_64 T OC s SCOTT h <hostp <portn '<targetdb>' u <oracleusere <oraclepasswordq 0.001 Q 60 m off ./sca_linux_x86_64 T OC s SCOTT h <hostp <portn '<targetdb>' u <oracleusere <oraclepassword> 3. MySQL data collection using slowlog file ./sca_linux_x86_64 T MC d <reportdirectoryslowlog=<slowlogfile> 4. Oracle SQL compatible analysis (Required: Repository, Target DB) Note: use [H/P/N/U/E] options to assign the repository use [h/p/n/u/e] options to assign the target database ./sca_linux_x86_64 T OI d <unzipped data directoryn <target_db> 5. Oracle SQL performance simulation (Required: Repository, Target DB) Note: use [H/P/N/U/E] options to assign the repository use [h/p/n/u/e] options to assign the target database ./sca_linux_x86_64 T OS d <unzipped data directoryn <target_db> 6. MySQL SQL compatible analysis (Required: Repository, Target DB) Not e: use [H/P/N/U/E] options to assign the repository use [h/p/n/u/e] options to assign the target database ./sca_linux_x86_64 T MI d <unzipped data directoryh <hostp <portn <targetdb> ``` v, version (查看版本)查看当前 SCA 的版本信息：```s hongyedba@localhost ~ % ./sca_linux_x86_64 v SCA version: 5.1.0 ``` T, type (任务类型)  默认值： OI指定任务类型，目前 SCA 支持如下类型的任务： 程序运行相关的任务  I [Initialize]: 初始化，用于初始化 SCA 资料库  L [Apply License]: 申请 License，用于 License 申请的任务 采集相关的任务  OC [Oracle Collection]: Oracle 采集，用于采集 Oracle 数据库中执行过的业务 SQL，需要长时间采集  MC [MySQL Collection]: MySQL 采集，用于采集 MySQL 数据库中执行过的业务 SQL，需提前配置慢日志，然后一次性采集  DC [DB2 Collection]: DB2 采集，用于采集 DB2 数据库中执行过的业务 SQL，需要长时间采集  PC [PostgreSQL Collection]: PostgreSQL 采集，用于采集 PostgreSQL 数据库中执行过的业务 SQL（依赖于 pg_stat_statments 插件），需要长时间采集  IC [Informix Collection]: Informix 采集，用于采集 Informix 数据库中执行过的业务 SQL（需要先手动开启 global sql trace 功能），需要长时间采集 分析相关的任务  OI [Oracle Inspection]: Oracle 兼容评估，用于评估源端 Oracle 中采集到的业务 SQL，在目标端 MogDB 中的实际兼容性  MI [MySQL Inspection]: MySQL 兼容评估，用于评估源端 MySQL 中采集到的业务 SQL，在目标端 MogDB 中的实际兼容性  DI [DB2 Inspection]: DB2 兼容评估，用于评估源端 DB2 中采集到的业务 SQL，在目标端 MogDB 中的实际兼容性  PI [PostgreSQL Inspection]: PostgreSQL 兼容评估，用于评估源端 PostgreSQL 中采集到的业务 SQL，在目标端 MogDB 中的实际兼容性  II [Informix Inspection]: Informix 兼容评估，用于评估源端 Informix 中采集到的业务 SQL，在目标端 MogDB 中的实际兼容性  OS [Oracle Simulation]: Oracle 性能评估，用于评估源端 Oracle 中采集到的业务 SQL，在目标端 MogDB 中的执行性能  OIS [Oracle Inspection & Simulation]: Oracle 兼容和性能评估，等同于 OI + OS 两种任务同时进行 d, data (数据目录)  除了资料库初始化（T I）之外的所有任务类型，都可以指定 d 数据目录。   采集任务会将采集到的数据写入到 d 指定的数据目录。   分析任务会从数据目录中读取数据，将数据插入到资料库表中，最终生成的报告结果默认也会写入到数据目录下。  D, dataid (数据编号)  指定数据编号，然后直接从资料库读取指定编号的数据，而不是重新从数据目录中读取并加载数据。   指定 D选项后，会跳过加载数据的步骤，直接执行相关的分析任务。  w, workers (并发度)  默认值：10   指定用于运行任务的并发度大小，适量的并发度有助于提高各个任务的运行速度。   并发度用于： 文件数据加载到资料库，SQL兼容度评估，SQL复杂度评估，SQL性能模拟等操作中。 注意：   在SQL模拟任务中，并发度越大，可能导致单条SQL的执行效率下降，需要依据实际生产环境的负载压力选取合理的并发度，通常设置为生产库的平均活跃会话数。 x, debug (Debug模式)  开启Debug 模式，不会影响正常的分析逻辑，但是会输出大量的日志，通常用于辅助分析程序本身的运行异常。  l, logfile (日志文件)  指定程序日志文件，程序输出会同时输出到终端命令行与日志文件中。  L, logonly (仅日志文件)  指定程序日志文件，程序输出会仅输出到日志文件中。  F, force (强制模式)  是否启用强制模式，强制模式会在资料库初始化场景下生效。   在资料库初始化过程中，如果启用强制模式，会先删除资料库，然后重新创建。  r, report (报告目录)  默认值：<DATA_DIR>/report   指定报告目录，这里的报告包括 兼容评估 报告和 SQL模拟 报告，都是 html 格式报告，可离线查看。   同时，对于 兼容评估 任务，还会产生 sql_detail_list.csv 文件，记录所有 SQL 的评估结果，以及可能存在的改写方案。  license (License文件)  默认值：./license.json   License 文件的位置。  sqlmodified (自定义SQL改写)  SQL 性能模拟中，每次运行性能模拟均会产生不支持 SQL 列表文件（存储于自定义的报告目录中），名称为：Simulator_modified_list.csv。   该选项用于在 SQL 性能模拟任务中，手动修改部分不支持的 SQL ，以达到更多的 SQL 支持率，尽可能对比更多的 SQL 性能变化。   自定义SQL 修改的流程如下：     使用标准的流程完成 SQL 性能模拟任务（第一次性能模拟）    打开报告目录中的 Simulator_modified_list.csv 文件，手动修改该文件中的SQL语句语法，使其能在目标数据库中正确执行    在原有选项的前提下，增加 D <dataidsqlmodified <repordir>/Simulator_modified_list.csv 选项，即可重新对失败的 SQL 进行性能模拟继续检查步骤二和步骤三，直到最终性能模拟的 SQL 范围符合预期，取出最终的分析报告 sqlconfig (自定义SQL)  【高级用法】 指定各个步骤中使用的SQL命令，仅为内部紧急故障调试使用。  sqltransformer (SQL转换规则)  【高级用法】 指定从源库到目标库的 SQL 转换规则，使用正则匹配进行转换。  steps  在分析过程中，运行指定的步骤，可使用步骤名称或编号。   该选项在以下任务类型中生效： OI, MI, DI, PI, OS, OIS   有效的步骤编号与名称说明如下： load : 将数据载入到资料库 make_object : 在目标数据库中创建源库对象 inspect : 执行 SQL 兼容性分析 rollback_object : 回退 make_objects 步骤中创建的源库对象 simulate : 执行 SQL 性能模拟分析 html_report : 创建 HTML 格式的汇总报告 excel_report : 创建 Excel 格式的详细报告合法的使用示例如下：steps 'load' : 只执行数据入库步骤 steps 'inspect' : 执行 'inspect' 之后的各个步骤 (步骤 37) steps '5' : 执行 'simulate' 之前的各个步骤 (步骤 15) steps '25' : 执行从 'make_object' 到 'simulate' 中的步骤 (步骤 25) upgrade  在运行环境可联网的情况下，自动升级当前 SCA 可执行程序。  2. 资料库选项 H, repohost (资料库IP地址)  默认值：127.0.0.1   资料库数据库 IP 地址。  P, repoport (资料库端口)  默认值：5432   资料库数据库端口。  N, reponame (资料库名称)  默认值： sca_db   资料库数据库名称。  U, repouser (资料库用户)  默认值：sca_repo   资料库数据库登录用户。  E, repopassword (资料库密码)  默认值：SCA@password   资料库数据库登录密码。  user (管理员用户)  资料库管理员用户，用于初始化资料库过程中，创建资料库用户，和资料库数据库。  password (管路员密码)  资料库管理员用户登录密码，用于初始化资料库过程中，创建资料库用户，和资料库数据库。  3. 源或目标库连接 h, dbhost (源或目标库IP地址)  源或目标库数据库 IP 地址，默认继承 H 选项值。  p, dbport (源或目标库端口)  源或目标库数据库端口，默认继承 P 选项值。  n, dbname (源或目标库名称)  源或目标库数据库名称，默认继承 N 选项值。   在 SQL分析任务中，指定目标库名称，通常是使用 MTK 或其他数据迁移工具，进行数据库结构和数据迁移时，在 MogDB 端创建的目标数据库。   需要注意的是，资料库用户默认需要对目标库有完全的操作权限，默认资料库是管理员权限。     在兼容评估中，只需要目标库有对象结构即可    在SQL模拟中，需要目标库既有对象结构，也有真实对等的全量生产数据，否则性能模拟的结果不具有参考意义 u, dbuser (源或目标库用户)  源或目标库数据库登录用户，默认继承 U 选项值。  e, dbpassword (源或目标库密码)  源或目标库数据库登录密码，默认继承 E 选项值。  targettype (目标库类型)  指定分析任务总，目标数据库类型，默认为 MOGDB。   当前此参数并未完善，仅支持 MOGDB/POSTGRESQL。  4. 数据采集选项 q, sqldays (SQL采集天数)  指定SQL 相关数据的采集总天数，由于从会话缓存 GV$SQLAREA 中采集已执行过的 SQL 数据， 存在一定的概率漏采，可通过延长采集天数，减小漏采的概率。   默认会采集一周 7 天的 SQL 数据。  Q, sqlinterval (SQL采集间隔)  指定SQL 相关数据的采集间隔（单位：秒），默认每 10 分钟采集一次。   每次采集到的 SQL 数据会和已采集的数据进行对比去重，避免重复数据太多导致的数据文件过大。  s, schemainclude (Schema白名单)  指定数据采集的 Schema 白名单，即只采集白名单列表中列出的 Schema 相关数据。  S, schemaexclude (Schema黑名单)  指定数据采集的 Schema 黑名单，即不采集黑名单列表中列出的 Schema 相关数据。   默认会将Oracle 系统用户列入 Schema 黑名单中。  m, enablemonitor (资源监控)  是否在后台启用资源监控子进程，默认启用。   资源监控子进程会定期（间隔 3 秒）查询当前服务器的 CPU 使用率，以及数据目录所在文件系统的剩余空间。   当 CPU使用率高于 90%，或者文件系统剩余空间低于 100MB 时，监控子进程会触发信号，停止采集主进程，避免因为资源问题导致服务器故障。  slowlog (慢查询日志)  采集时，指定 MySQL 慢查询日志文件。   在采集程序无法访问目标 MySQL 数据库，以及不在 MySQL 服务器上运行采集程序时，可手动将目标库 MySQL 慢日志取出来，使用当前选项指定慢日志即可解析并生成对应的采集数据，可用于后续 MySQL SQL 兼容性评估任务。  ignorebindplan (忽略绑定变量与执行计划)  在Oracle 数据采集过程中，忽略 SQL 绑定变量和执行计划数据的采集，忽略采集能避免由于绑定变量或执行计划解析而导致的 Oracle 字典查询 Bug，并加快数据采集时间，但可能导致后期数据分析的精度下降。 四、SCA 结果说明SCA 结果分为两类：  采集结果 : 源库（Oracle）中的数据采集结果，该结果会自动打包为一个 zip 文件，并在采集最后给出明确文件位置提示。 分析结果 : 在目标MogDB/openGauss 中执行完分析后生成的分析报告，报告为单独一个文件夹，其中为离线 HTML 格式的报告文档，可任意进行拷贝传阅。 1. 采集结果数据采集结果会自动打包成 zip 数据包，默认存储在程序当前目录下。 采集完成之后的结果提示信息如下：```s 20220215 19:20:40.301126 INFO [runMe.py:356] +==================== [ Summary Information ] ====================+ 20220215 19:20:40.301184 INFO [runMe.py:357] | Task Name File Name File Size | 20220215 19:20:40.301222 INFO [runMe.py:358] | | 20220215 19:20:40.301260 INFO [runMe.py:360] | SCA_SESSION_SQL sca_sql_information.dat 3.65 KB | 20220215 19:20:40.301294 INFO [runMe.py:360] | SCA_SESSION_SQL_PERF sca_sql_performance.dat 3.29 KB | 20220215 19:20:40.301326 INFO [runMe.py:360] | SCA_MYSQL_USER_HOST sca_mysql_user_host.dat 1815 B | 20220215 19:20:40.301357 INFO [runMe.py:360] | SCA_DATABASE sca_database.dat 163 B | 20220215 19:20:40.301387 INFO [runMe.py:361] +=================================================================+ >>> Final Result is: >>> >>> /Users/hongyedba/Desktop/SCA_MySQL_test.zip ``` 2. 分析报告兼容性分析与 SQL 性能模拟均会生成对应的分析报告，分析报告默认位于指定的数据目录中，也可以使用 r 选项指定报告的输出目录。  3. 报告入口分析报告目录中，index.html 为报告的入口，点击该文件，使用默认浏览器（推荐使用Chrome）打开，即可查看分析报告。 3. SQL 兼容度汇总SQL 兼容度汇总页面展示本次兼容度分析的相关结果数据，页面表格中按照用户名，程序名，模块名汇总，展示系统中采集到的所有 SQL，以及这些 SQL 在MogDB 中的支持情况。 注意： 不同数据库中，该表格展示的内容也略有差异。 4. SQL 改写规则SQL 改写规则页面展示本次分析中涉及到的 SQL 改写相关的规则信息。 其中使用情况字段展示该条规则的触发情况：  Match 为规则在 SQL 中的命中数量 Count 为规则匹配的 SQL 数量 5. SQL 复杂度分布SQL 复杂度分布页面展示采集到的 SQL 的复杂度分布情况。 复杂度分布目前的评判标准如下：  SQL 涉及的表的数量，表数量越多，复杂度越高 SQL 中使用 connect by 语法的次数，使用 connect by 的次数越多，越有可能出现执行性能问题，对应 SQL 的复杂度越高 SQL 中使用自定义函数的数量，自定义函数中的逻辑复杂度不明，所以使用自定义函数越多，SQL 复杂度越高 SQL 在 Oracle 中的实际执行函数，执行耗时越高，则认为对应的 SQL 复杂度越高最终每条 SQL 的复杂度则按照以上 4 个评判标准进行汇总。SQL 复杂度越高，在迁移后越需要关注 SQL 的执行性能，避免性能问题导致的业务故障。 6. SQL 性能对比（性能对比汇总）SQL 性能对比汇总页面展示两个信息：  性能对比的基础信息，性能对比的一些基础配置，以及对比时使用到的相关阈值设置 SQL 性能汇总，按照总体，提升，下降，不支持，超时等维度对 SQL 进行汇总，分析各类 SQL 对整体负载的影响 7. SQL 性能对比（Top by Workload/SQL, Timeout） SQL 性能对比中 Top by Workload, Top by SQL, Timeout 等页面内容格式较为相似，以 Top by Workload 为例进行说明。 该列表展示影响最大的 100 条 SQL，其中 SQL FMS 字段为超链接，点击可进一步查看对应 SQL 的分析详情。 SQL 的性能影响有两个评估维度：  SQL 影响： 当前 SQL 在单条 SQL 执行情况下的性能变化影响的比例 负载影响： 当前 SQL 参考其总执行次数，综合评估其对整个 SQL 负载的性能变化，以及对整体 SQL 性能的影响 8. SQL 性能对比（SQL 详情）SQL详情页面展示如下几个方面的内容：  SQL 执行信息： SQL 在Oracle 以及 MogDB 中的执行信息，其中Oracle 中的执行信息来源于动态性能视图，MogDB 中的执行信息来源于实际 SQL 执行。 SQL 文本： SQL 在Oracle 中的执行文本，以及在 MogDB 中的实际执行文本。 SQL 绑定变量： SQL 在Oracle 中的绑定变量信息，该绑定变量信息会应用到 MogDB 中执行的 SQL 文本内，使其能在 MogDB 中真实的模拟业务执行。 Oracle 执行计划： SQL 在 Oracle 中的执行计划，该执行计划来源于动态性能视图。 MogDB 执行计划： SQL 在 MogDB 中的执行计划，该执行计划来源于实际执行，程序会自动对 MogDB 中的执行计划进行初步分析，标识出其中潜在的性能问题点。 MogDB 对象信息： SQL 中涉及到的对象在 MogDB 中的相关结构，以及统计信息。 9. 数据报告在报告的根目录中的SCA_Data_Report_<db_name>_<data_id>.xlsx 文件中记录了本次 SQL 兼容度评估涉及到的所有 SQL 的支持情况，SQL 支持情况的各维度汇总，以及部分 SQL 改写的汇总与列表。 Excel 数据报告中主要包含如下 sheet 页面：  封面页面： 作为 Excel 数据报告的第一页，记录报告的基础信息，名称，采集分析版本，数据编号等 汇总页面： 作为 Excel 数据报告的第二页，主要记录兼容信息汇总，不支持 SQL 的汇总，以及自动改写 SQL 的汇总 详细列表： 作为 Excel 数据报告的第三页，记录本次兼容性分析中涉及到的所有 SQL 的详细信息列表 改写列表： 从 Excel 数据报告的第四页开始，均为 SQL 改写列表，每一页对应一个改写规则，其中 SQL 中涉及到的改写部分均以红色加粗进行标识文件中的字段内容主要根据数据库的不同，略有差异。 (1) Oracle 用户名: 执行 SQL 的 Schema 信息，在 Oracle 中一般对应于用户 SQL类型: SQL 类型，区分采集到的 SQL 是系统 SQL 还是用户的业务SQL，取值为： USER, SYSTEM_CATALOG, SYSTEM_COMMAND 支持类别: SQL 在MogDB 中的支持类别：直接支持，改写支持，不支持 应用模块: 执行 SQL 语句的客户端 module 应用操作: 执行 SQL 语句的客户端 action MogDB异常代码: MogDB 中的 SQL 执行错误码 MogDB异常信息: MogDB 中的 SQL 执行报错信息 SQL_ID: Oracle 中的 SQL ID，用于从 Oracle 缓存视图中定位具体 SQL 信息 原始SQL: 原始 SQL文本 转换规则: SQL 满足的自动化改写规则 改写SQL: 经过自动化改写后的 SQL 文本(2) MySQL 库名(schema): 执行 SQL 的 Schema 信息，在MySQL 中一般对应于数据库 SQL类型: SQL 类型，区分采集到的 SQL 是系统 SQL 还是用户的业务SQL，取值为： USER, SYSTEM_CATALOG, SYSTEM_COMMAND 支持类别: SQL 在MogDB 中的支持类别：直接支持，改写支持，不支持 用户主机: 执行 SQL 的 MySQL 客户端用户和对应的执行客户端主机信息 MySQL错误代码: SQL 在MySQL 中的执行情况，如果是 0 则表明 SQL 执行成功，非 0 表示在 MySQL 中执行报错 MogDB异常代码: MogDB 中的 SQL 执行错误码 MogDB异常信息: MogDB 中的 SQL 执行报错信息 原始SQL: 原始 SQL文本 转换规则: SQL 满足的自动化改写规则 改写SQL: 经过自动化改写后的 SQL 文本(3) DB2 Schema: 执行 SQL 的Schema 信息 SQL类型: SQL 类型，区分采集到的 SQL 是系统 SQL 还是用户的业务SQL，取值为： USER, SYSTEM_CATALOG, SYSTEM_COMMAND 支持类别: SQL 在MogDB 中的支持类别：直接支持，改写支持，不支持 语句类型: DB2 中记录的 SQL 语句类型 MogDB异常代码: MogDB 中的 SQL 执行错误码 MogDB异常信息: MogDB 中的 SQL 执行报错信息 原始SQL: 原始 SQL文本 转换规则: SQL 满足的自动化改写规则 改写SQL: 经过自动化改写后的 SQL 文本(4) PostgreSQL Schema: 执行 SQL 的Schema 信息 SQL类型: SQL 类型，区分采集到的 SQL 是系统 SQL 还是用户的业务SQL，取值为： USER, SYSTEM_CATALOG, SYSTEM_COMMAND 支持类别: SQL 在MogDB 中的支持类别：直接支持，改写支持，不支持 MogDB异常代码: MogDB 中的 SQL 执行错误码 MogDB异常信息: MogDB 中的 SQL 执行报错信息 原始SQL: 原始 SQL文本 转换规则: SQL 满足的自动化改写规则 改写SQL: 经过自动化改写后的 SQL 文本(5) Informix 用户名: 执行 SQL 的用户信息 SQL类型: SQL 类型，区分采集到的 SQL 是系统 SQL 还是用户的业务SQL，取值为： USER, SYSTEM_CATALOG, SYSTEM_COMMAND 支持类别: SQL 在MogDB 中的支持类别：直接支持，改写支持，不支持 语句类型: Informix 中记录的 SQL 语句类型 MogDB异常代码: MogDB 中的 SQL 执行错误码 MogDB异常信息: MogDB 中的 SQL 执行报错信息 原始SQL: 原始 SQL文本 转换规则: SQL 满足的自动化改写规则 改写SQL: 经过自动化改写后的 SQL 文本

当服务器因海量用户出现高并发情况后，关系型数据库便出现了瓶颈。即磁盘IO性能低下和数据关系复杂，扩展性差，不便于大规模集群的问题。为此，我们引入NoSQL，即 Not-Only SQL（泛指非关系型的数据库），作为关系型数据库的补充。NoSQL的特点有：可扩容，可伸缩大数据量下高性能灵活的数据模型高可用等而Redis则是常见的NoSQL数据库之一。一、Redis简介（1）Redis特征：数据间没有必然的关联关系内部采用单线程机制进行工作高性能。官方提供测试数据，50个并发执行100000 个请求,读的速度是110000 次/s,写的速度是81000次/s。多数据类型支持字符串类型 string列表类型 list散列类型 hash集合类型 set有序集合类型sorted_set持久化支持。可以进行数据灾难恢复（2）Redis应用：为热点数据加速查询（主要场景），如热点商品、热点新闻、热点资讯、推广类等高访问量信息等任务队列，如秒杀、抢购、购票排队等即时信息查询，如各位排行榜、各类网站访问统计、公交到站信息、在线人数信息（聊天室、网站）、设备信号等时效性信息控制，如验证码控制、投票控制等分布式数据共享，如分布式集群架构中的 session 分离消息队列分布式锁二、Redis中的基本操作1.功能：设置 key，value 数据set key value2.功能：根据 key 查询对应的 value，如果不存在，返回空（nil）get key3.功能：清除屏幕中的信息clear4.功能：退出客户端quit exit <ESC>5.功能：获取命令帮助文档，获取组中所有命令信息名称help 命令名称 help @组名

一、工具讲解  1. MogDB Stack 简介  MogDB Stack是Kubernetes上的MogDB集群自动运维系统，提供包括部署、高可用、扩缩容、监控、备份恢复的MogDB全生命周期管理。借助MogDB Stack，MogDB可以无缝运行在公有云或私有部署的Kubernetes集群上。   2. MogDB Stack特性简单便捷的自动部署/回收   以Kubernetes作为原生的容器编排系统，以扩展资源的方式，轻松便捷地创建整套MogDB集群，并且根据用户的期望任意扩缩容。 稳定可靠的备份恢复能力   支持基于SQL的备份方式，并且存储在远端分布式存储中，多副本保证备份的可靠性，指定point-in-time的恢复方式，恢复到指定的时间点。 企业级的高可用性   自动故障探测、切换，并自动化的拉取数据快照恢复故障节点或重新调度新节点，实现系统的自愈能力，保证用户期望的副本数。 完善可靠的监控能力   基于Prometheus实现多维度的统一监控，囊括了系统层、容器层、数据库层的完整的监控指标。 精细化的资源管控   针对CPU、内存、存储等资源的限额，保证容器层的独立性，不会互相干扰，支持容器的亲和性、反亲和性调度。   3. 系统架构   4. 操作系统与平台支持MogDB Stack 目前支持在如下操作系统和平台架构下运行： Linux x86_64Linux arm64  二、 快速部署   1. 快速上手本文介绍了如何创建一个简单的 Kubernetes 集群，部署MogDB Operator，并使用 Mogdb Operator 部署 MogDB 集群。  本文中的部署说明仅用于测试目的，不要直接用于生产环境。如果要在生产环境部署，请参阅部署 部署 MogDB 集群章节。  2. 创建Kubernetes测试集群本节介绍如何使用 minikube 部署 Kubernetes 集群。 minikube 可以在虚拟机中创建一个 Kubernetes 集群，可在 macOS, Linux 和 Windows 上运行。 部署前，请确保满足以下要求： minikube：版本 1.18.1+ minikube 需要安装一个兼容的 hypervisor，详情见官方安装教程。 kubectl: 版本 >= 1.18.1 安装完 minikube 后，可以执行下面命令启动一个Kubernetes 集群：```s minikube start ```如果一切运行正常，会看到类似下面的输出，根据操作系统和使用的 hypervisor 会有些许差异。```s 😄 minikube v1.10.1 on Darwin 10.15.4 ✨ Automatically selected the hyperkit driver. Other choices: docker, vmwarefusion 💾 Downloading driver docker-machine-driver-hyperkit: docker-machine-driver-hyperkit.sha256: 65 B / 65 B [---] 100.00% ? p/s 0s docker-machine-driver-hyperkit: 10.90 MiB / 10.90 MiB 100.00% 1.76 MiB p 🔑 The 'hyperkit' driver requires elevated permissions. The following commands will be executed: $ sudo chown root:wheel /Users/user/.minikube/bin/docker-machine-driver-hyperkit $ sudo chmod u+s /Users/user/.minikube/bin/docker-machine-driver-hyperkit 💿 Downloading VM boot image ... minikube-v1.10.0.iso.sha256: 65 B / 65 B [-------------] 100.00% ? p/s 0s minikube-v1.10.0.iso: 174.99 MiB / 174.99 MiB [] 100.00% 6.63 MiB p/s 27s 👍 Starting control plane node minikube in cluster minikube 💾 Downloading Kubernetes v1.18.2 preload ... preloaded-images-k8s-v3-v1.18.2-docker-overlay2-amd64.tar.lz4: 525.43 MiB 🔥 Creating hyperkit VM (CPUs=2, Memory=4000MB, Disk=20000MB) ... 🐳 Preparing Kubernetes v1.18.2 on Docker 19.03.8 ... 🔎 Verifying Kubernetes components... 🌟 Enabled addons: default-storageclass, storage-provisioner 🏄 Done! kubectl is now configured to use "minikube" ```对于中国大陆用户，可以使用国内 gcr.io mirror 仓库，例如 registry.cn-hangzhou.aliyuncs.com/google_containers。```s minikube start --image-repository registry.cn-hangzhou.aliyuncs.com/google_containers ```或者给 Docker 配置 HTTP/HTTPS 代理。 将下面命令中的 127.0.0.1:1086 替换为您自己的HTTP/HTTPS 代理地址：```s minikube start --docker-env https_proxy=http://127.0.0.1:1086 \ --docker-env http_proxy=http://127.0.0.1:1086 ```  注意:  由于minikube（默认）通过虚拟机运行，127.0.0.1 指向虚拟机本身，所以在有些情况下可能需要将代理修改为您的主机的实际 IP。 参考 minikube setup 查看配置虚拟机和Kubernetes 集群的更多选项。 你可以使用 minikube 的子命令 kubectl 来进行集群操作。要使 kubectl 命令生效，你需要在 shell 配置文件中添加以下别名设置命令，或者在打开一个新的 shell 后执行以下别名设置命令。```s alias kubectl='minikube kubectl --' ```执行以下命令检查集群状态，并确保可以通过 kubectl 访问集群:```s kubectl cluster-info ```期望输出：```s Kubernetes master is running at https://192.168.64.2:8443 KubeDNS is running at https://192.168.64.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'. ```现在就可以开始部署 MogDB Operator 了！ 测试完成后，执行下面命令来销毁集群：```s minikube delete ```  2. 部署MogDB Operator开始之前，确保以下要求已满足： 可以使用 kubectl 访问的 Kubernetes 集群已安装 Kustomize v3+步骤1: 下载样例```s wget https://cdn-mogdb.enmotech.com/mogdb-stack/v1.0.0/mogdb-operator-examples.tar tar xf mogdb-operator-examples.tar cd mogdb-operator-examples ```步骤2: 安装MogDB Operator```s kustomize build ./kustomize/install/default | kubectl apply -f - ```期望输出:```s namespace/mogdb-operator-system created customresourcedefinition.apiextensions.k8s.io/mogdbbackups.mogdb.enmotech.io created customresourcedefinition.apiextensions.k8s.io/mogdbclusters.mogdb.enmotech.io created customresourcedefinition.apiextensions.k8s.io/mogdbrecoveries.mogdb.enmotech.io created serviceaccount/mogdb-operator-controller-manager created role.rbac.authorization.k8s.io/mogdb-operator-leader-election-role created clusterrole.rbac.authorization.k8s.io/mogdb-operator-manager-role created rolebinding.rbac.authorization.k8s.io/mogdb-operator-leader-election-rolebinding created clusterrolebinding.rbac.authorization.k8s.io/mogdb-operator-manager-rolebinding created configmap/mogdb-operator-manager-config created secret/mogdb-operator-huawei-registry created deployment.apps/mogdb-operator-controller-manager created ```  3. 部署MogDB集群```s kubectl apply -f https://cdn-mogdb.enmotech.com/mogdb-stack/v1.0.0/mogdb-cluster.yaml ```期望输出:```s mogdbcluster.mogdb.enmotech.io/cluster1 created ``` 查看pod状态```s kubectl get pods -n mogdb-operator-system ```期望输出:```s NAME READY STATUS RESTARTS AGE cluster1-jl2kn 3/3 Running 0 4m18s cluster1-zuveg 0/3 PodInitializing 0 108s ```等待所有pod都处于running状态，然后进行下一步，连接到MogDB集群。   4. 连接MogDB集群(1) 安装gsql命令行工具要连接到MogDB集群，您需要在使用kubectl的主机上安装MogDB客户端工具gsql安装与物理机匹配的命令行工具。  (2) 查看MogDB服务端口首先，将端口从本地主机转发到 Kubernetes 中的 MogDB Service。 我们先获取 mogdb-operator-system 命名空间中的服务列表：```s kubectl get svc -n mogdb-operator-system ```期望输出：```s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE cluster1-svc-master NodePort 10.1.115.245 <none> 5432:30013/TCP 38m cluster1-svc-replicas NodePort 10.1.41.187 <none> 5432:30012/TCP 38m ```输出结果显示了，k8s集群内部通过5432端口，集群外部通过30013端口访问实际的MogDB集群。  (3) 连接集群在连接之前，需要修改默认用户的密码。可以通过kubectl命令连接到容器，修改密码。```s kubectl exec -it cluster1-xxx -c ha-sidecar -/bin/bash gsql -dpostgres ALTER USER mogdb WITH PASSWORD 'new_password'; gsql -h 10.1.115.245 -p 5432 -U mogdb -W ```期望输出：```s gsql ((MogDB 3.0.0 build b5f25b20) compiled at 2022-06-30 14:41:25 commit 0 last mr ) Non-SSL connection (SSL connection is recommended when requiring high-security) Type "help" for help. MogDB= ```以下是一些可以用来验证集群功能的命令。 查看MogDB版本```s MogDB=select version(); version --------------------------------------------------------------------------------------------------------------------------------------------------- (MogDB 3.0.0 build b5f25b20) compiled at 2022-06-30 14:41:25 commit 0 last mr on aarch64-unknown-linux-gnu, compiled by g++ (GCC) 7.3.0, 64-bit (1 row) ```创建t1表```s MogDB=create table t1(id int); CREATE TABLE ```插入数据```s MogDB=insert into t1(id) values(1),(2),(3); INSERT 0 3 ```查看数据```s MogDB=select * from t1; id ---- 1 2 3 (3 rows) ```  5. 销毁MogDB集群完成测试后，您可能希望销毁MogDB集群。 删除MogDB集群```s kubectl delete mogdbcluster cluster1 ```期望输出:```s mogdbcluster.mogdb.enmotech.io "cluster1" deleted ``` 卸载MogDB Operator```s kustomize build ./kustomize/install/default | kubectl delete -f - ```期望输出:```s namespace/mogdb-operator-system created customresourcedefinition.apiextensions.k8s.io/mogdbbackups.mogdb.enmotech.io created customresourcedefinition.apiextensions.k8s.io/mogdbclusters.mogdb.enmotech.io created customresourcedefinition.apiextensions.k8s.io/mogdbrecoveries.mogdb.enmotech.io created serviceaccount/mogdb-apiserver created serviceaccount/mogdb-operator-controller-manager created role.rbac.authorization.k8s.io/mogdb-operator-leader-election-role created clusterrole.rbac.authorization.k8s.io/mgo-cluster-role created clusterrole.rbac.authorization.k8s.io/mogdb-operator-manager-role created rolebinding.rbac.authorization.k8s.io/mogdb-operator-leader-election-rolebinding created clusterrolebinding.rbac.authorization.k8s.io/mgo-cluster-role created clusterrolebinding.rbac.authorization.k8s.io/mogdb-operator-manager-rolebinding created configmap/mogdb-operator-manager-config created configmap/mogdb-operator-mgo-config created secret/mgorole-admin created secret/mgouser-admin created secret/mogdb-operator-huawei-registry created service/mogdb-apiserver created deployment.apps/mogdb-apiserver created deployment.apps/mogdb-operator-controller-manager created ```  三、架构  1. 高可用高可用是MogDB Stack体系中的，一个功能组件，以sidecar模式运行在MogDB所在的pod中，实时的监测MogDB的运行状态，当primary出现不可用状态时，触发切换逻辑。 发生切换的场景如下:   数据库磁盘故障或者某些硬件故障  主库的网络不可达  数据库发生故障宕机  机架掉电 特性  通过dcs保证ha自身的高可用  ha具备leader、follower角色，leader具有决策权  实时修复MogDB集群的复制状态  维护MogDB的角色 架构图 2. 监控(1) Kubernetes监控与告警  本文介绍如何对 Kubernetes 集群进行监控。在MogDB集群运行的过程中，需要对容器资源、宿主机、Kubernetes 组件等进行监控。对于这些组件或资源的监控，需要在整个Kubernetes 集群维度部署监控系统来实现。(2) 宿主机监控通过node exporter对物理机指标进行采集，统一抓取到prometheus中。Node Exporter 是 Prometheus 官方提供的一个节点资源采集组件，可以用于收集服务器节点的数据，如 CPU频率信息、磁盘IO统计、剩余可用内存 等等。Node Exporter 会将收集到的信息转换为 Prometheus 可识别的 Metrics 数据。Prometheus 可以从 Node Exporter 中对这些指标进行收集与存储，并且可以根据这些数据的实时变化进行服务器节点资源监控。 (3) 容器监控cAdvisor是Google开源的容器资源监控和性能分析工具，它是专门为容器而生，在Kubernetes中，我们不需要单独去安装，cAdvisor作为kubelet内置的一部分程序可以直接使用，也就是我们可以直接使用cadvisor采集数据，可以采集到和容器运行相关的所有指标。 cadvisor中获取到的典型监控指标如下： | 指标名称 | 类型 | 含义 | |--------------------------------------------|---------|-----------------------------| | container\_cpu\_load\_average\_10s | gauge | 过去10秒容器CPU的平均负载 | | container\_cpu\_usage\_seconds\_total | counter | 容器在每个CPU内核上的累积占用时间 \(单位：秒\) | | container\_cpu\_system\_seconds\_total | counter | System CPU累积占用时间（单位：秒） | | container\_cpu\_user\_seconds\_total | counter | User CPU累积占用时间（单位：秒） | | container\_fs\_usage\_bytes | gauge | 容器中文件系统的使用量\(单位：字节\) | | container\_fs\_limit\_bytes | gauge | 容器可以使用的文件系统总量\(单位：字节\) | | container\_fs\_reads\_bytes\_total | counter | 容器累积读取数据的总量\(单位：字节\) | | container\_fs\_writes\_bytes\_total | counter | 容器累积写入数据的总量\(单位：字节\) | | container\_memory\_max\_usage\_bytes | gauge | 容器的最大内存使用量（单位：字节） | | container\_memory\_usage\_bytes | gauge | 容器当前的内存使用量（单位：字节） | | container\_spec\_memory\_limit\_bytes | gauge | 容器的内存使用量限制 | | machine\_memory\_bytes | gauge | 当前主机的内存总量 | | container\_network\_receive\_bytes\_total | counter | 容器网络累积接收数据总量（单位：字节） | | container\_network\_transmit\_bytes\_total | counter | 容器网络累积传输数据总量（单位：字节） |(4) 资源对象监控kube-state-metrics提供资源对象本身的监控，如pod运行状态、有多少job在运行中等等，它基于client-go开发，轮询Kubernetes API，并将Kubernetes的结构化信息转换为metrics。 指标类别包括： CronJob Metrics DaemonSet Metrics Deployment Metrics Job Metrics LimitRange Metrics Node Metrics PersistentVolume Metrics PersistentVolumeClaim Metrics Pod Metrics Pod Disruption Budget Metrics ReplicaSet Metrics ReplicationController Metrics ResourceQuota Metrics Service Metrics StatefulSet Metrics Namespace Metrics Horizontal Pod Autoscaler Metrics Endpoint Metrics Secret Metrics ConfigMap Metrics(5) MogDB监控为了获取MogDB自身的监控指标，需要配套的MogDB exporter采集相应的数据。(6) 架构图  3. 备份(1) 备份管理MogDB Operator使用MogDB原生的dump命令执行备份，因此，备份内容为可移殖的sql形式，这样的好处是可以跨版本恢复。(2) 架构图  4. 恢复 (1) 恢复管理 MogDB Operator通过在s3存储上，查找合适的备份数据，恢复数据库到指定的时间点。 (2) 架构图  5. 客户端 （1） mgo客户端MogDB Operator Client，又叫做mgo，是与MogDB Operator 交互的最便捷方式。mgo通过一系列简单的命令，为创建、管理和删除 MogDB 集群提供了许多便捷的方法。 MogDB Operator 提供了于 mgo 客户端连接的接口，并通过 RBAC 和 TLS 进行验证管理。（2） 架构图