DCA考试心得

1. 引言——从DCA考试说起

刚考完DCA，把这次备考和考试中一个让我印象最深的点写下来。文章错误地方还请指教。
DCA考试是纯上机实操，时长2个小时。考试内容基本上和培训讲义一致，涵盖了数据库安装、实例创建、表空间管理、用户权限、表管理、备份恢复等DBA日常工作需要用到的核心技能。如果你跟着老师讲的内容多做几遍练习，通过并不是什么难事。
顺便分享一个备考时很实用的环境搭建技巧：用VMware装好一台已配置好环境的虚拟机作为模板，关机后直接克隆出多份，每台虚拟机里独立练习dminit初始化实例、启停服务、表空间管理、用户权限、备份恢复等DCA考点。这样一套环境可以反复使用，每台虚拟机互不干扰，非常适合做多遍练习。下图就是我的练习环境。

不过，练习过程中有一个问题一直困扰着我——页大小和簇大小为什么建库后就再也改不了了？
DCA考试的第一道题就是安装并初始化实例。命令里要指定一堆参数：数据库名、实例名、端口号、SYSDBA密码、页大小（PAGE_SIZE）、簇大小（EXTENT_SIZE）、数据文件目录、日志文件大小等等。培训的时候老师也反复强调——这些参数建库前要想好，一旦定下来就不能改了。
但“不能改”这个结论，对于一个刚从DCA考场出来的新手来说，多少有点难以接受。毕竟在日常工作中，表空间大小可以扩，用户权限可以调，参数可以动态修改，怎么建库时选的页大小和簇大小就定死了？
带着这个疑问，我基于官方文档把达梦的存储结构从头理了一遍。搞清楚“页→簇→段→表空间→数据文件”这条线之后，才基本理解了为什么这两个参数如此特殊。
这篇文章就基于此说说我个人的理解。

2. 存储层次概览

达梦数据库的存储结构是分层的，从大到小依次是：数据库 → 表空间 → 数据文件 ↔ 段 → 簇 → 页。
挨个说一下每一层是什么。
数据库：最顶层，是所有表空间、数据文件、段、簇、页的最终集合。可以理解为一个“大房子”，里面所有的东西都属于这个数据库。
表空间：数据库下面一层，一个数据库由一个或多个表空间组成。表空间是逻辑上的概念，用于把数据库对象按业务或功能隔离开。比如系统表放SYSTEM表空间，用户数据放MAIN表空间或自己建的表空间。表空间本身不存数据，它只是一个“容器” ——所有数据库对象在逻辑上存放在表空间中，但物理上存储在数据文件中。
数据文件：这才是真正在磁盘上存数据的物理文件。每个表空间由一个或多个数据文件组成。
段：段是簇的上级逻辑单元。每个数据库对象（比如一张表或一个索引）对应一个段。，一张表的数据可以分散存放在多个物理文件里。
簇：簇由同一数据文件中连续的页组成。簇不能跨数据文件。簇的大小在建库时通过EXTENT_SIZE指定，可以是16页、32页或64页。簇是空间分配的最小单元，创建表或索引时，系统至少分配1个簇。
页：页是数据库中最小的存储单元，也是最小的I/O单元。页的大小在建库时通过PAGE_SIZE指定，可以是4KB、8KB、16KB或32KB。所有的数据最终都存在页里。
一个数据库有多个表空间，每个表空间有多个数据文件，每个数据文件里划分成多个簇，每个簇由连续的页组成，而每个数据库对象（如表）占用一个段，段由若干个簇组成。
这其中的关键是：页和簇是最底层的两个单位。页决定了“一格多大”，簇决定了“一次分配多少格”。它们共同构成了整个数据库存储的“度量标准”。建库时一旦指定，整个数据库生命周期内都无法更改。

3. 为什么页、簇大小不可修改？

页的内部结构
一个数据页从内部来看，可以细分为四个部分：页头控制信息、数据区、空闲空间、行偏移数组。
页头控制信息包含了页的类型、页地址等信息。数据区存放实际的行记录数据。空闲空间是页内还没被使用的剩余空间，可以由数据页自行管理，也可以通过FILLFACTOR参数来指定初始使用比例。行偏移数组位于页的尾部，用于标识页上的空间占用情况，以便管理数据页自身的空间。
为什么页大小不能改？
根本原因在于地址映射已经固化。
数据文件在磁盘上就是一串连续的字节。页号n对应的物理偏移量，等于n × 页大小。这个映射关系一旦确定，整个数据文件里所有的指针、地址都是基于这个公式计算的。
页头里存储的页地址等控制信息，在建库时就已经写入了。数据字典、段头信息、位图页里记录的全是页号和基于页大小的偏移量。如果页大小改了，同一个页号指向的物理位置就完全错位了。所有已写入的页头信息全部失效，数据字典里的指针就无法使用了。
理论上可以全量重写所有数据文件的内部指针，但这相当于重建整个数据库，不可能在线完成。
页大小除了自身不能改之外，还会对数据存储产生一个直接影响：记录不能跨页存储。
也就是说，一行数据必须完整地存放在同一个数据页里，不能拆成两半分别放在两个页上。加上数据页里还要存放页头控制信息等额外内容，所以达梦规定每条记录的总长度不能超过页面大小的一半。
不同页大小对应的最大行长度也各不相同，页大小越大能容纳的行记录就越长。如果插入的数据超过页大小一半的限制，就会报"记录超长"的错误。
USING LONG ROW
如果确实需要存储超长记录，达梦提供了一个叫USING LONG ROW的功能。开启之后，当记录长度超过页大小一半时，系统会尝试将过长的变长字符串转换为行外BLOB存储。这样单行记录就可以突破页大小一半的限制了。
不过这个功能对性能有一定影响，一般不建议所有表都开启。更根本的解决办法还是在建库时就选对页大小。
还有一个跟页相关的参数值得一提——FILLFACTOR（填充比例）。
它指定插入数据时数据页的充满程度，取值范围从0到100。默认值是0，等价于100，表示全满填充。设置一个较低的FILLFACTOR值，可以在页里预留一部分空闲空间，这样后续更新数据导致记录变长时，可以直接在原有页内扩展，避免频繁的页分裂。当然这是以牺牲空间利用率为代价的。
再看簇。
簇是数据页的上级逻辑单元，由同一个数据文件中连续的页组成。簇大小在建库时通过EXTENT_SIZE指定，可以是16页、32页或64页，默认16页。和页一样，簇大小建库后也无法修改。
簇是空间分配的最小单元。创建一张表或一个索引时，系统会为它分配至少一个簇。一个簇用完了，再自动分配新的簇。
簇大小不可修改的原因和页类似：数据文件的空闲空间位图是基于固定簇大小构建的。位图里每个比特位代表一个簇的占用状态——是空闲还是已分配。这个位图在数据文件里的位置和结构，跟簇大小是严格绑定的。簇大小改了，位图就没法正确解析了——原来一个簇对应的一段空间，在新规格下应该算几个簇？根本没有统一的对应规则。
至于簇的释放，当删除一张表时，它对应的段以及段里包含的所有簇都会被收回，释放为表空间的空闲簇。
页和簇，一个是"一格多大"，一个"一次分多少格"。建库时确定，之后整个数据库的生命周期里，所有数据文件、所有表空间都得按这套规格来运行。

4. 宏观：表空间、段与数据文件

段是簇的上级逻辑单元。简单说，每一个数据库对象（比如一张表或一个索引），都对应一个段。
段的一个关键特性是：段可以跨越同一个表空间中的多个数据文件。也就是说，一张表的数据可以分散存放在多个物理文件里。当表的一个簇用完了，系统会在这个表空间里找下一个可用的簇来分配，这个新簇可能落在同一个数据文件里，也可能落在另一个数据文件里。对用户来说完全透明，不需要关心数据具体存在哪个物理文件里。
但是段有一个边界：段不能跨表空间。一张表的所有数据，只能存放在它所属的那个表空间里，不能跑到别的表空间去。所以如果某个表空间满了，只能给它加数据文件，或者把表迁移到别的表空间。
表空间是段的逻辑容器。一个表空间里可以包含多个段，也就是包含多张表、多个索引。表空间本身不直接存数据，它负责把逻辑上的段和物理上的数据文件关联起来。
达梦数据库在初始化之后，默认会创建几个系统表空间：SYSTEM表空间存放数据字典和系统信息，ROLL表空间存放回滚记录，RLOG表空间存放重做日志，MAIN表空间是默认的用户数据存储位置，TEMP表空间存放临时数据。考试中经常会要求创建一个新的用户表空间，用于存放业务数据。
数据文件才是真正在磁盘上存数据的物理文件。每个表空间由一个或多个数据文件组成。比如手动创建了一个叫TEST的表空间，指定数据文件路径为/dm8/data/DAMENG/TEST.DBF，那么这张表空间里的所有数据，最终都会写入到这个物理文件中。
当表空间包含多个数据文件时，达梦采用“先填满第一个，再写第二个”的分配方式，而不是把数据均匀分散到各个文件里。
虽然页和簇的大小不能改，但表空间和数据文件层面的操作是非常灵活的。

5. 那建库后页大小选错了，数据能迁走吗？——从逻辑与物理备份看两个层次的差异

物理备份不行，逻辑备份可以。
物理备份还原：拷的是“页”，参数必须一致
物理备份的本质很简单——把数据文件里有效的数据页原样拷贝出来，存到备份集里。它不关心数据页里存的是什么内容，只关心“这些页在磁盘的什么位置、是不是有效数据页”还原的时候，再把备份集里的数据页原样写回目标数据文件。
正因为物理备份是原样拷贝数据页，它对目标库的底层存储规格有非常严格的要求：表备份集的页大小、簇大小、大小写是否敏感、UNICODE_FLAG等不可变的数据库初始化参数，必须与目标还原库一致。
道理很简单：物理备份拷的是按源库页大小组织好的数据页。源库页大小是8KB，备份集里每个数据页就是8KB。如果目标库页大小是16KB，还原的时候这些8KB的数据页往16KB的页里塞，数据页的格式、偏移量、页头信息全对不上——备份集根本没法正常导入。
所以物理备份还原不可行。
逻辑备份不一样。导出的是SQL，可以跨参数。

逻辑备份用的是dexp（逻辑导出）工具，它不碰数据文件里的数据页，而是把数据库对象的结构定义（建表语句）和数据内容提取出来，生成一个.dmp文件。逻辑备份关心的是“数据内容是什么”，而不是“数据存在磁盘的哪个位置”。
既然导出的只是SQL语句和纯数据，那.dmp文件就和源库的页大小、簇大小没有直接关系了。导入的时候，dimp工具会在目标库里重新执行这些SQL语句——建表、插数据。目标库页大小是多大，数据就按目标库的规格去存。
所以非全库级别的逻辑导出（用户级、模式级、表级），可以在不同页大小的库之间迁移数据。
逻辑备份和物理备份还有一个本质差异：逻辑备份针对的是数据内容，并不关心这些数据物理存储在什么位置。物理备份拷的是“页”，逻辑备份拷的是“内容”。一个受底层存储格式约束，一个不受。
不过要注意一点：全库级（FULL）的逻辑导出，情况会复杂一些。
全库导出不仅包含用户数据，还包含系统表和数据字典等元数据信息。这些信息里有一部分和数据库的初始化参数是绑定的。所以全库导入时，通常要求源库和目标库的页大小、字符集等参数一致，否则可能报错。
也就是说，逻辑备份能跨参数迁移，主要针对的是非全库级别的导出（用户级、模式级、表级）。全库导出的话，限制会多一些。
把物理备份和逻辑备份放在一起对比，差异就很清楚了：
物理备份拷的是数据页——按源库的页大小、簇大小组织好的物理数据块。还原的时候要求目标库的页大小、簇大小等参数完全一致。它速度快、适合大规模恢复，但灵活性差，跨参数迁移走不通。
逻辑备份拷的是SQL语句和数据内容——不涉及物理存储格式。非全库级别可以在不同参数的库之间迁移。它速度相对慢一些，但灵活性强，适合跨环境迁移。
物理备份还原针对的是“物理存储层面”——数据页的拷贝；逻辑备份还原针对的是“逻辑数据层面”——对象定义和数据的重建。速度上的差异同样值得注意。物理备份直接拷贝数据页，本质是磁盘I/O操作，速度非常快，TB级数据可以在小时级别完成。逻辑备份则需要把数据逐条转换成SQL语句再写入文件，涉及大量CPU计算，大表导出可能耗时数小时。恢复时差异更明显：物理还原是数据页的原样写回，逻辑还原需要逐条执行SQL重建数据和索引。速度和灵活性往往不可兼得。物理备份适合大规模快速恢复，逻辑备份适合跨环境迁移。
一个拷“页”，一个拷“内容”。一个受底层存储格式约束，一个不受。理解了这两个层次的差异，就能回答最初那个问题了：建库后页大小选错了，数据能不能迁走？——物理备份不行，但非全库的逻辑备份可以。
我们进行一个实践：
在虚拟机上新建两个实例，一个初始化DMHR示例（DEXP），一个则不包含该示例（DIMP）。

使用图形化页面导出：

将备份导入DIMP实例：


可以看到没有问题。再确认物理备份还原的情况：
先进行备份：

进行导入：

6. 建库前怎样选择页大小

已经简单了解了页大小为什么不能改。那接下来的问题就是：建库的时候到底选多大的页？
先搞清楚页大小会影响哪些事情。最直接的有三个：
第一，数据文件的最小大小。
达梦数据文件的最小值计算公式是：最小文件大小 = 4096 × 页大小。页大小4KB对应最小16MB，8KB对应32MB，16KB对应64MB，32KB对应128MB。这个限制对大多数业务来说影响不大，但如果你的数据库本来就很小（比如测试环境只有几百MB），选32KB页大小意味着每个数据文件至少128MB起步，空间利用率会偏低。
第二，单行记录的最大长度。
前面提到过，达梦规定每条记录的总长度不能超过页大小的一半。页大小4KB大概能存1900多字节，8KB约3900字节，16KB约8000字节，32KB约16000字节。如果你的业务表里单行数据超过了页大小一半的限制，插入就会报“记录超长”的错误。虽然可以用USING LONG ROW做行外存储，但那毕竟是有性能代价的，不建议作为常规手段。
第三，I/O效率与空间利用率的权衡。
页大小越小，每个I/O读进来的数据越少，适合小事务、点查询的场景。页大小越大，一次I/O能扫描的数据越多，适合大表扫描、批量分析的场景。但页越大也可能带来空间浪费——如果一个表每条记录只有几百字节，页大小32KB的话，一个页里能塞很多行，但万一页里最后剩下的那点空间塞不下新行，就浪费了。
根据具体条件来调节即可。没有绝对最优，只有相对合适。

7.结语

这篇文章从DCA考试里dminit的一个参数说起，一路捋了页、簇、段、表空间、数据文件这条线，最后对比了物理备份和逻辑备份在跨参数迁移上的差异。
页和簇为什么不能改——因为它们是物理度量单位，页号对应物理偏移量，簇号对应位图索引，建库时已经固化到数据文件里了，改不了。
物理备份和逻辑备份为什么一个不能跨参数、一个能——物理备份拷的是“页”，受底层存储格式约束；逻辑备份拷的是“内容”，不依赖物理存储格式。
回看 DCA 课程：我觉得最大的收获不是会敲多少条命令，而是搞清楚了“能做什么”和“为什么有些事不能做”之间的那条分界线。页和簇的机制算是达梦底层逻辑里很基础的一块，搞清楚它，后面再看表空间管理、备份恢复这些内容，感觉都顺了不少。
这篇文章里的理解肯定有不够严谨的地方。如果你发现了问题，或者有不同的见解，欢迎指出来，一起讨论。