DM数据库体系结构
前言
- 数据库作为当前数字化经济的基石之一,是信息系统的中枢,从金融到银行、从私企到央企国企,几乎各个领域都有所触及。而数据库技术在几十年内被国外所垄断,我国的数据信息存在一定的安全威胁。
- 达梦数据库(以下用DM简称)作为全自主研发的国产数据库,专为企业级应用需求设计,为打破数据库技术垄断具有重要意义。
- 针对DM,我们可以从逻辑结构和物理结构两个方面来看数据库的体系结构。
逻辑结构
DM数据库以页为分配单位进行文件划分,是数据库中最小的分配单位;多个连续的页组成簇,一个簇总是处于一个数据文件中,而多个簇则可以;由簇组合成段,是簇的上级逻辑单位,一个段可以跨越多个数据文件;表空间是DM数据库中最大的分配单位,由一个个数据文件组成
-
表空间
-
表空间由一个或多个数据文件文件组成,所有数据库内部对象都存放在表空间中。
-
表空间分为普通表空间和混合表空间。普通表空间不能存储HUGE表(HUGE表,就是列存储表,以列为单位进行存储),混合表空间对普通表和HUGE表都可以存储。
-
在初始创建DM数据库时,会自动生成5个表空间(如上图所示):
-
SYSTEM表空间:存放有关DM数据库的字典信息,用户不能在此创建表和索引,也叫系统表空间
-
MAIN表空间:用户默认表空间,用于存放业务数据等,属于混合表空间(这个就是主要的数据存储地方)
-
ROLL表空间:用于存放事务运行过程中执行DML(数据库操作语言)操作之前的值,由系统自动维护,无需用户干预(和数据库的回滚操作相关)
-
TEMP表空间:临时表,如果SQL语句需要用到磁盘空间,则系统从TEMP表空间中分配临时段供该SQL语句使用。当然,用户创建的临时表也是使用该表空间(所以是temp,感觉像Windows中C盘的temp文件)
-
HMAIN表空间:用户存放HUGE数据的地方
注:表空间一般是不用过多关注,可能出问题就是涉及表空间不足
-
-
如果涉及表空间不足的问题,可以有以下三种方法解决:
- 扩展数据文件
alter tablespace "TEST" resize datafile 'TEST01.DBF' to 2000;
- 增加数据文件
alter tablespace "TEST" add datafile '/dm8/data/DAMENG/TEST02.DBF' size 100 autoextend on next 1 maxsize 2000;
- 开启自动增长
alter tablespace "TEST" datafile 'TEST01.DBF' autoextend on next 1 maxsize 2000;
-
-
段
段由簇组成,一个段可以包含来自不同数据文件的簇,也就是说,段可以跨数据文件存储。其中,段内的簇可以不用连续。
- 段可以划分为:
- 数据段
- 特定对象的数据结构,可以根据结构分为表数据段和索引数据段。用户在创建表或索引时,系统创建相应的数据段,根据存储参数决定对应数据段的簇如何分配
- 临时段
- 所有临时段都在TEMP表空间里面。DM数据库会创建临时段用于存储SQL语句执行和解析的中间结果,属于是临时存储空间(别人用完就没事儿了)。临时段是系统控制分配和释放,用户不能干预
- 回滚段
- 用于保存恢复数据库操作的信息。对于未提交事务,当执行回滚语句时,回滚记录被用来做回滚变更。在数据库恢复阶段,回滚记录被用来做任何未提交变更的回滚
- DM数据库提供了全自动回滚管理机制,消除了管理回滚段的复杂性,同时DM会收集回滚信息的使用情况,并根据统计结果进行周期性调整
- 数据段
- 段可以划分为:
-
簇
簇是进行存储空间分配的基本单位。一个簇由一系列逻辑上连续的页组成(默认是16个页)。一个簇的大小,由页的大小和组成簇的个数决定。一旦创建好数据库,那该数据库的簇的大小不可更改。
-
簇的分配、释放过程
- 分配过程:
- 首先去数据文件找是否有空闲簇,如果有空闲簇,那么直接给文件分配;如果没有空闲簇,就在数据文件中继续找,看是否有空闲空间,有的话给分配(这里空闲空间是以前的数据删除之后,不会变成和未使用过的簇一样,而是打上一个标签,如果没有空闲的未使用过的簇,那么就从这堆打了标签的簇中找是否符合条件的);如果都没有空闲空间,则要针对表空间进行扩充了
- 释放情况:
- 针对涉及SQL语句执行的临时段中的簇,则会在SQL语句执行完之后自动释放
- 针对ROLL表空间里的簇,系统会定时查看簇的情况,来确定是否需要释放簇
- 针对普通表中的簇,如果使用了删除操作如delete,则将对应的簇打上标签(此时数据还没有清理),在分配过程中需要使用标签簇才会将其释放,变成新的未使用的簇
- 分配过程:
-
-
页
页是DM数据库中最小的数据存储单位,默认为8KB,用户可以自己指定大小。数据库一旦创建好,整个生命周期中都不能更改页的大小。
-
DM数据库的页的组成成分如上图所示,包括四大部分:
- 页头控制信息包括页类型、页地址等信息
- 页中大片空白用于存储数据
- 空闲空间
- 行偏移数组则是用于存放偏移数组(标识页的空间情况,以便管理)
-
DM数据库提供了一个与性能有关的存储参数–FILLFACTOR,用于指定页在初始化插入数据时能够用的最大的空间比例。这种控制使用空间大小的情况可以方方便其他操作使用空间
注:FILLFACTOR过高,可能导致后续更新数据会频繁引起页分裂,降低性能;过低,会导致存储空间使用率不高,且页过多
-
物理存储结构
DM数据库使用大量物理存储结构来保护和管理数据,基于DM的逻辑结构,物理结构主要围绕表空间和日志进行设计,比较典型的有:用于进行功能设置的配置文件;用于记录文件分布的控制文件;用于保存用户实际数据的数据文件、重做日志文件、归档日志文件、备份文件;用来进行问题跟踪的跟踪日志文件,如上图所示。
-
配置文件
-
配置文件以ini为扩展名,用于设计一些配置选项,有固定的格式。两个方面的作用:
- 启用/禁止特定功能
- 针对当前运行的系统环境设置更好的参数,提升性能
-
1.1 服务配置
-
1.1.1 dm.ini
- 数据库启动必要的配置文件,通过配置该文件可以设置 DM 数据库服务器的各种功能和性能选项,主要的配置模块包括:控制文件相关、实例名、内存相关、线程相关等,类似于MySQL的my.ini文件
-
1.1.2 dmmal.ini
- MAL系统的配置文件
-
1.1.3 dmarch.ini
- 用于配置归档,一些相关的说明,请移步达梦数据库官方网站查看(www.dameng.com)
-
1.1.4 dm_svc.conf
-
属于客户端配置文件,包含相关的DM接口和客户端工具所需要配置的一些参数。当然,必须和接口/客户端在同一台机器上才行。在DM数据库安装时自动生成,以下为不同平台下的生成目录
- 32 位的 DM 安装在 Win32 操作平台下,此文件位于 %SystemRoot%\system32 目录; - 64 位的 DM 安装在 Win64 操作平台下,此文件位于 %SystemRoot%\system32 目录; - 32 位的 DM 安装在 Win64 操作平台下,此文件位于 %SystemRoot%\SysWOW64 目录; - 在 Linux 平台下,此文件位于/etc 目录。
-
相关配置顶:
- JDBC/.NET PROVIDER/NODE JS/Go 接口
- DPI 接口
- CYT 安全接口
- DIMP/DEXP 工具
- DPC 接口
- Disql 工具
- DCI 接口
-
dm_svc.conf 配置文件的内容分为全局配置区和服务配置区,服务配置区中的配置优先级高于全局配置区。全局配置区的配置项影响所有会话。下面以普通环境中的dm.svg.conf为例。
# 全局配置区 NORMAL=(192.168.0.1:5000,192.168.0.2:5236) Data_Watch=(192.168.0.3:5236,192.168.0.4:4350) TIME_ZONE=(480) #表示+8:00时区 DIRECT=(Y) # 服务配置区 # 常规环境,两个没有关系的IP [NORMAL] TIME_ZONE=(540) #表示+9:00时区 LOGIN_MODE=(4) SWITCH_TIMES=(3) SWITCH_INTERVAL=(100) # 服务配置区 # 数据守护环境,一主一备,只连备库 [Data_Watch] TIME_ZONE=(540) #表示+9:00时区 LOGIN_MODE=(2) SWITCH_TIMES=(3) SWITCH_INTERVAL=(100)
-
-
1.1.5 sqllog.ini
- 用于SQL日志配置,当且仅当 INI 参数 SVR_LOG=1 时使用。sqllog.ini 配置文件的内容分为全局配置区和模式配置区,全局配置区内允许配置所有的配置项,包括全局配置项和模式内配置项;模式配置区位于全局配置区后面,以“[模式名]”开头
-
1.1.6 dmthrd.ini
- 用于为线程类型绑定 CPU 核心,当且仅当 INI 参数 DMTHRD_INI=1 时使用。dmthrd.ini 中为线程类型绑定 CPU 核心的语法如下:
<线程类型名> = [<最小值>, <最大值>] 或 <线程类型名> = [<绑定值>]
-
< 线程类型名 >:指定线程类型
[< 最小值 >, < 最大值 >]:非负整数,指定 CPU 核心的绑定范围。例如设置 DM_AUDIT_THD=[0,2],表示创建审计日志刷盘线程时会循环绑定编号为 0、1、2 的三个 CPU 核心
[< 绑定值 >]:非负整数,表示仅绑定一个 CPU 核心,例如设置 DM_AUDIT_THD=[2],表示仅绑定编号值为 2 的 CPU 核心,等同于 DM_AUDIT_THD=[2,2]
-
-
1.2 复制配置
- 1.2.1 dmrep.ini
- dmrep.ini 用于配置复制实例
- 1.2.2 dmllog.ini
- dmllog.ini 用于配置逻辑日志
- 1.2.3 dmtimer.ini
- dmtimer.ini 用于配置定时器,用于数据守护中记录异步备库的定时器信息或数据复制中记录异步复制的定时器信息
- 1.2.1 dmrep.ini
-
-
控制文件
- 每个 DM 数据库都有一个名为 dm.ctl 的控制文件。控制文件是一个二进制文件,它记录了数据库必要的初始信息,其中主要包含以下内容:
- 数据库名称;
- 数据库服务器模式;
- OGUID 唯一标识;
- 数据库服务器版本;
- 数据文件版本;
- 数据库的启动次数;
- 数据库最近一次启动时间;
- 表空间信息,包括表空间名,表空间物理文件路径等,记录了所有数据库中使用的表空间,数组的方式保存起来;
- 控制文件校验码,校验码由数据库服务器在每次修改控制文件后计算生成,保证控制文件合法性,防止文件损坏及手工修改。
- 如果在修改过程中服务器故障,可能会导致控制文件损坏,为了避免出现这种情况,在修改控制文件时系统内部会执行备份操作:
- 策略一:在修改 dm.ctl 之前,先执行一次备份,确定 dm.ctl 修改成功后,再将备份删除,如果 dm.ctl 修改失败或中途出现故障,则保留备份文件。
- 策略二:在修改 dm.ctl 成功之后,根据 dm.ini 中指定的 CTL_BAK_PATH/CTL_BAK_NUM 对最新的 dm.ctl 执行备份,如果用户指定的 CTL_BAK_PATH 是非法路径,则不再生成备份文件,在路径有效的情况下,生成备份文件时根据指定的 CTL_BAK_NUM 判断是否删除老的备份文件。
- 每个 DM 数据库都有一个名为 dm.ctl 的控制文件。控制文件是一个二进制文件,它记录了数据库必要的初始信息,其中主要包含以下内容:
-
数据文件
- 数据文件以 dbf 为扩展名,一个 DM 数据文件对应磁盘上的一个物理文件或者达梦分布式数据库中的一个逻辑文件。在实际使用中,一般不建议使用单个巨大的数据文件,为一个表空间创建多个较小的数据文件是更好的选择。
- 数据文件按照组织形式分类:
- B树数据
- 行存储数据,按照B树索引组织。一个 B 树包含两个段,一个内节点段,存放内节点数据;一个叶子段,存放叶子节点数据。其 B 树的逻辑关系由段内页面上的记录,通过文件指针来完成。当表上没有指定聚集索引时,系统会自动产生一个唯一标识 rowid 作为 B 树的 key 来唯一标识一行
- 堆表数据
- 以挂链形式存储,支持最多 128 个链表,一个链表在物理上就是一个段,堆表采用的是物理 rowid,在插入过程中,rowid 在事先已确定,并保证其唯一性,所以可以并发插入,插入效率很高,且由于 rowid 是即时生成,无需保存在物理磁盘上,也节省了空间
- 列存储数据
- 按列方式组织存储,包含每个列对应的存放列数据的一系列数据文件,以及存放列数据控制信息的辅助表。读取列数据时,只需要顺序扫描列数据文件和辅助表数据
- 位图索引
- 位图索引与 B 树索引不同,每个索引条目不是指向一行数据,而是指向多行数据。每个索引项保存的是一定范围内所有行与当前索引键值映射关系的位图
- 两类特殊的数据文件:
- ROLL文件–ROLL 表空间的 dbf 文件,用于保存系统的回滚记录,提供事务回滚时的信息
- TEMP文件–TEMP.DBF 临时数据文件,当数据库查询的临时结果集过大,缓存已经不够用时,临时结果集就可以保存在 TEMP.DBF 文件中,供后续运算使用
- B树数据
-
重做日志文件
- 重做日志( REDO 日志)指在 DM 数据库中添加、删除、修改对象,或者改变数据,DM 都会按照特定的格式,将这些操作执行的结果写入到当前的重做日志文件
- 重做日志文件主要用于数据库的备份与恢复。当出现如电源故障、系统故障,或者数据库实例进程被强制终止,数据库缓冲区中的数据页会来不及写入数据文件。在重启 DM 实例时,通过重做日志文件中的信息,就可以将数据库的状态恢复到发生意外时的状态
- 重做日志文件对于数据库是至关重要的。它们用于存储数据库的事务日志,以便系统在出现系统故障和介质故障时能够进行故障恢复
-
归档日志文件
- 日志文件分为联机日志文件和归档日志文件。DM数据库可以在归档模式和非归档模式下运行。非归档模式下,数据库会只将重做日志写入联机日志文件中进行存储;归档模式下,数据库会同时将重做日志写入联机日志文件和归档日志文件中分别进行存储
- 联机日志文件指的是系统当前正在使用的日志文件,创建数据库时,联机日志文件通常被扩展至一定长度,其内容则被初始化为空,当系统运行时,该文件逐渐被产生的日志所填充。对日志文件的写入是顺序连续的
- 归档日志文件就是在归档模式下,重做日志被连续写入到归档日志后,所生成了归档日志文件。归档日志文件以归档时间命名
- 日志文件分为联机日志文件和归档日志文件。DM数据库可以在归档模式和非归档模式下运行。非归档模式下,数据库会只将重做日志写入联机日志文件中进行存储;归档模式下,数据库会同时将重做日志写入联机日志文件和归档日志文件中分别进行存储
-
逻辑日志文件
- 如果在数据库上配置了复制功能,复制源就会产生逻辑日志文件。逻辑日志文件是一个流式的文件,有自己的格式。逻辑日志文件按照复制记录的格式存储,用于发送给复制目的端
-
物理逻辑日志文件
- 按照特定的格式存储,用于 DBMS_LOGMNR 包挖掘获取数据库系统的历史执行语句
-
备份文件
- 备份文件以 bak 为扩展名,当数据库不幸出现故障时,备份文件就会发挥作用。当客户利用管理工具或直接发出备份的 SQL 命令时,DM Server 会自动进行备份,并产生一个或多个备份文件,备份文件自身包含了备份的名称、对应的数据库、备份类型和备份时间等信息
-
SQL日志文件
- SQL 日志文件是一个纯文本文件,命名格式为“dmsql_实例名[_模式名][_用户名][_日期_时间].log”。SQL 日志内容包含系统各会话执行的 SQL 语句、参数信息、错误信息等。跟踪日志主要用于分析错误和分析性能问题,进而对其进行优化。
- 系统中 SQL 日志的缓存是分块循环使用,管理员可根据系统执行的语句情况及压力情况设置恰当的日志缓存块大小及预留的缓冲块个数
注:打开 SQL 日志会影响系统的性能,因此一般在需要查错和调优的时候才会打开
-
事件日志文件
-
事件日志文件记录了 DM 数据库运行时的关键事件,例如:系统启动、关闭、内存申请失败、IO 错误等一些致命错误;数据库运行过程中的日志信息;备份还原过程中备份还原操作的阶段性信息等
-
事件日志文件主要用于系统出现严重错误时进行查看并定位问题。事件日志简称 ELOG。事件日志文件随着 DM 数据库服务的运行一直存在。
-
事件日志信息格式为:时间 + 日志类型(INFO/WARNING/ERROR/FATAL)+ 进程(database)+ 进程 ID(P 开头)+ 线程(dm_sql_thd/main_thread 等)+ 日志内容。初始化过程中产生的 ELOG 会保存在 ELOG_PATH 参数指定的目录下,名称为“dminit+ 日期 + 时间”。例如:dminit20220914090452.log。
-
内存结构
DM 数据库管理系统的内存结构主要包括内存池、缓冲区、排序区、哈希区等。根据系统中子模块的不同功能,对内存进行了上述划分,并采用了不同的管理模式
-
内存池
DM Server 的内存池包括共享内存池和其他一些运行时内存池
- 共享内存池
- DM Server 在启动时从操作系统申请的一大片内存。DM Server运行中申请和释放空间需要使用系统调用,引起线程切换从而降低性能。DM数据库采用共享内存池方式,一次性向系统申请大片空间,让系统运行中需要申请空间,就在共享池中切给它,用完释放后将空间还给内存池
- DM系统管理员可以修改配置文件设置共享内存池大小,参数为MEMORY_POOL,缺省大小 500M。ini文件中参数 MEMORY_EXTENT_SIZE 指定了共享内存池每次扩展的大小,参数 MEMORY_TARGET 则指定了共享内存池扩展到超过该值后,空闲时会收缩到的大小
- 运行时内存池
- 除了共享内存池,DM Server 的一些功能模块在运行时还会使用自己的运行时内存池,从操作系统申请一片内存作为本功能模块的内存池来使用,如会话内存池、虚拟机内存池等
- 共享内存池
-
缓冲区
-
数据缓冲区
-
顾名思义,就是数据页写入磁盘之前或者是读取数据页时,所存放的地方。将其设定得太小,会导致缓冲页命中率低,磁盘 IO 频繁;将其设定得太大,又会导致操作系统内存本身不够用。(适中调整)
-
数据缓冲区存在三条链来管理被缓冲的数据页:
-
“自由”链:用于存放目前尚未使用的内存数据页
-
“LRU”链:用于存放已被使用的内存数据页(包括未修改和已修改)
注:LRU 链对系统当前使用的页按其最近是否被使用的顺序进行了排序。这样当数据缓冲区中的自由链被用完时,从 LRU 链中淘汰部分最近未使用的数据页,能够较大程度地保证被淘汰的数据页在最近不会被用到,减少 IO
-
“脏”链,用于存放已被修改过的内存数据页
-
-
热数据保障:对于反复被访问的数据页,数据缓冲区会开辟一个特定的区域用于保存它们,以保证这些页不参加一般的淘汰机制,可以一直留在数据缓冲区
- 数据缓冲区分为四个类型:NORMAL、KEEP、FAST 和 RECYCLE
- NORMAL 缓冲区:主要是提供给系统处理的一些数据页,没有特定指定缓冲区的情况下,默认缓冲区为 NORMAL
- KEEP缓冲区:是对缓冲区中的数据页很少或几乎不怎么淘汰出去,主要针对用户的应用是否需要经常处在内存当中
- RECYCLE 缓冲区:供临时表空间使用
- FAST 缓冲区:根据用户指定的 FAST_POOL_PAGES 大小由系统自动进行管理
- 读多页:DM数据库支持多页读取,用户通过参数MULTI_PAGE_GET_NUM大小来控制每次读取的页数,减少I/O次数,提升数据查询、修改效率
注:如果 MULTI_PAGE_GET_NUM 太大,每次读取的页可能大多都不是以后所用到的数据页,这样不仅会增加 I/O 的读取,而且每次都会做一些无用的 I/O(需要系统管理员衡量好应用需求,适度调整)
- 数据缓冲区分为四个类型:NORMAL、KEEP、FAST 和 RECYCLE
-
-
日志缓冲区
- 日志缓冲区用于存放重做日志的内存缓冲区。系统运行产生的日志会先放在日志缓冲区中,不会立即写入磁盘,避免系统性能受直接I/O影响。单独开一块日志缓冲区的原因:
- 重做日志的格式同数据页完全不一样,无法进行统一管理
- 重做日志具备连续写的特点
- 在逻辑上,写重做日志比数据页 IO 优先级更高
注:DM Server 提供了参数 RLOG_BUF_SIZE 对日志缓冲区大小进行控制,日志缓冲区所占用的内存是从共享内存池中申请的,单位为页数量
- 日志缓冲区用于存放重做日志的内存缓冲区。系统运行产生的日志会先放在日志缓冲区中,不会立即写入磁盘,避免系统性能受直接I/O影响。单独开一块日志缓冲区的原因:
-
字典缓冲区
-
主要存储一些数据字典信息,如模式信息、表信息、列信息、触发器信息等。每次对数据库的操作都会涉及到数据字典信息,访问数据字典信息的效率直接影响到相应的操作效率,所以开出一块缓冲区存放字典信息,可以减少使用I/O的额外开销
-
DM8 采用的是将部分数据字典信息加载到缓冲区中,并采用 LRU 算法进行字典信息的控制,可以通过参数 DICT_BUF_SIZE调整缓冲区大小(默认配置5M)
注:缓冲区大小设置问题,如果太大,会浪费宝贵的内存空间,如果太小,可能会频繁的进行淘汰
-
-
SQL缓冲区
- 提供SQL语句执行过程中需要的内存,包括计划、SQL 语句和结果集缓存。DM Server提供了参数来支持是否需要计划重用(使用缓冲区保存那些反复执行的SQL语句以及执行计划),参数为 USE_PLN_POOL,当指定为非 0 时,则启动计划重用;为 0 时禁止计划重用。DM 同时还提供了参数 CACHE_POOL_SIZE,来改变 SQL 缓冲区大小(默认为20MB)
-
-
排序区
- 排序缓冲区提供数据排序所需要的内存空间。当用户执行 SQL 语句时的排序过程,就需要排序缓冲区提供内存。每次排序都首先申请内存,排序结束后再释放内存
- DM Server使用参数SORT_BUF_SIZE 来指定排序缓冲区的大小,默认值为2M
-
哈希区
- DM8 提供了为哈希连接而设定的缓冲区,不过该缓冲区是个虚拟缓冲区(系统没有真正创建特定属于哈希缓冲区的内存,而是在进行哈希连接时,对排序的数据量进行了计算)
- DM Server提供了参数 HJ_BUF_SIZE 来进行控制,由于该值的大小可能会限制哈希连接的效率,所以建议保持默认值,或设置为更大的值
线程
DM 服务器使用“对称服务器构架”的单进程、多线程结构,这种对称服务器构架在有效地利用了系统资源的同时又提供了较高的可伸缩性能。DM 进程中主要包括监听线程、IO 线程、工作线程、调度线程、日志线程等,以下分别对它们进行介绍
-
监听线程
- 主要的任务是在服务器端口上进行循环监听,一旦有来自客户的连接请求,监听线程被唤醒并生成一个会话申请任务,加入工作线程的任务队列,等待工作线程进行处理
- 系统启动完成后才启动,并且在系统关闭时首先被关闭
- 监听线程比普通线程优先级更高
- DM 服务器所有配置端口的范围为 1024-65534
- 主要的任务是在服务器端口上进行循环监听,一旦有来自客户的连接请求,监听线程被唤醒并生成一个会话申请任务,加入工作线程的任务队列,等待工作线程进行处理
-
工作线程(核心线程)
- 工作线程是 DM 服务器的核心线程,它从任务队列中取出任务,并根据任务的类型进行相应的处理,负责所有实际的数据相关操作
- DM8的初始线程个数和最大阀门值由配置文件决定,随会话连接的增加而增加(等于建立相关会话才会有对应线程产生),一个会话上的任务全部由同一个工作线程完成,减少线程切换的代价,提高系统效率。当线程达到预定的阀门值后,工作线程的值不再增加,由会话轮询线程接收用户请求,等待空闲的线程(有点儿像操作系统的进程,新的任务放在等待队列,等CPU空闲时再执行)
-
I/O线程
-
为避免因直接对数据页进行读写而造成的系统性能变差,DM数据库将I/O操作从工作线程中分离出来,专门使用I/O线程来处理这些I/O操作。需要进行I/O操作的时机(和MySQL类似):
- 需要处理的数据页不在缓冲区中,此时需要将相关数据页读入缓冲区
- 缓冲区满或系统关闭时,此时需要将部分脏数据页写入磁盘
- 检查点到来时,需要将所有脏数据页写入磁盘(检查点是数据库在特定时间点将脏数据页写入磁盘更新日志信息,确保发生故障时可以从最近时间点检查,而不用从头开始)
注:IO 线程在启动后,通常处于睡眠状态,当系统需要进行 I/O 时发出一个 I/O 请求,唤醒I/O线程处理请求。在完成该 I/O 操作后继续进入睡眠状态
-
I/O线程的个数可以由参数 IO_THR_GROUPS 设置,默认情况下是2个。I/O 线程使用异步的 I/O 将数据页写入磁盘,此时系统将所有的 I/O 请求直接递交给操作系统,操作系统在完成这些请求后才通知 I/O 线程
-
-
调度线程
- 调度线程用于接管系统中所有需要定时调度的任务。调度线程每秒钟轮询一次,负责的任务有以下一些:
- 检查系统级的时间触发器,如果满足触发条件则生成任务加到工作线程的任务队列由工作线程执行
- 清理 SQL 缓存、计划缓存中失效的项,或者超出缓存限制后淘汰不常用的缓存项
- 执行动态缓冲区检查。根据需要动态扩展或动态收缩系统缓冲池
- 自动执行检查点。为了保证日志的及时刷盘,减少系统故障时恢复时间,根据 INI 参数设置的自动检查点执行间隔定期执行检查点操作
- 会话超时检测。当客户连接设置了连接超时时,定期检测是否超时,如果超时则自动断开连接
- 必要时执行数据更新页刷盘
- 唤醒等待的工作线程
- 调度线程用于接管系统中所有需要定时调度的任务。调度线程每秒钟轮询一次,负责的任务有以下一些:
-
日志FLUSH线程
-
基于WAL原则,当事务提交或者执行检查点时,会通知 FLUSH 线程进行日志刷盘
注:WAL原则–在数据页写入磁盘之前,必须先将变更记录先写进磁盘,确保在系统崩溃时可以很快知晓当前的行为
- 由于日志具备顺序写入的特点,DM8 的日志 FLUSH 线程进行了优化,在刷盘之前,对不同缓冲区内的日志进行合并,减少 I/O 次数,进一步提高性能
- 如果系统配置了实时归档,在 FLUSH 线程日志刷盘前,会直接将日志通过网络发送到实时备库。如果配置了本地归档,则生成归档任务,通过日志归档线程完成
-
-
日志归档线程
- 日志归档线程包含异步归档线程,负责远程异步归档任务。
- 将日志 FLUSH 线程和日志归档线程分开的目的是为了减少不必要的效率损失,除了远程实时归档外,本地归档、远程异步归档都可以脱离 FLUSH 线程来做
- 日志归档线程包含异步归档线程,负责远程异步归档任务。
-
日志APPLY线程
- 用于配置数据守护的系统中。当服务器作为备库时,每次接收到主库的物理 REDO 日志生成一个 APPLY 任务加入到任务队列,APPLY 线程从任务队列中取出一个任务在备库上将日志重做,并生成自己的日志,保持和主库数据的同步或一致,作为主库的一个镜像
-
定时器线程
- 为用户在特定时间点开始某种操作或某个时间段反复进行某种操作而设计的。主要的定时操作:
- 逻辑日志异步归档
- 异步归档日志发送(只有在 PRIMARY 模式下,且是 OPEN 状态下)
- 作业调度
- 定时器线程默认情况下是不启动的,用户可以将参数TIMER_INI设置为1来开启该线程
- 为用户在特定时间点开始某种操作或某个时间段反复进行某种操作而设计的。主要的定时操作:
-
逻辑日志归档线程
- 用于 DM8 的数据复制中,目的是为了加快异地访问的响应速度,包含本地逻辑日志归档线程和远程逻辑日志归档线程
- 本地逻辑日志归档线程:从本地归档任务列表中取出一个归档任务,生成到逻辑日志,并将逻辑日志写入到逻辑日志文件中
- 远程逻辑日志归档线程:从远程归档任务列表中取出一个归档任务,并根据任务的类型进行相应的处理
- 用于 DM8 的数据复制中,目的是为了加快异地访问的响应速度,包含本地逻辑日志归档线程和远程逻辑日志归档线程
-
MAL系统相关线程
- DM内部的高速通信系统,基于TCP/IP协议实现。服务器中的如数据守护、数据复制、远程日志归档等都是通过MAL系统实现
-
其他线程
- 在一些特定的功能中会有不同的线程,例如回滚段清理 PURGE 线程、审计写文件线程等
-
线程信息查看
- DM 提供很多动态性能视图,通过它们用户可以直观地了解当前系统中有哪些线程在工作,以及线程的相关信息,相关动态视图如下:
名称 说明 V$LATCHES 记录当前正在等待的线程信息 V$THREADS 记录当前系统中活动线程的信息 V$PROCESS 记录服务器进程信息
总结
- 达梦数据库作为自主研发的国产数据库,其对应的体系结构是每个DBA必须了解和掌握的。上面的内容里面加了一些我自己的看法,如有错误,请批评指正
参考
- https://eco.dameng.com/ – 达梦产品官网