达梦6.0试用之架构篇

前几天ITPUB的熊建国主编和我联系，希望我能参加国产数据库达梦的适用活动，并写几篇使用感受。本来最近手工的事情比较多，本打算推辞的，不过熊主编再三邀请，而且强调并非是枪手文，只要写出真实使用感受即可。既然如此，我就本着支持国产数据库的原则，写几篇试用感受。

由于本人唯一熟悉的数据库就是Oracle，因此所有的对比都是与Oracle数据库进行对比，在这个过程中，将尽可能避免将对Oracle数据库的喜爱之情带进来，争取站在一个比较公正的位置上来进行评价。

这一篇简单介绍一下达梦数据库的系统架构。

 

 

Oracle的数据库分为两个部分，实例和数据库。实例由内存和进程组成，而数据库部分由文件组成。

而达梦数据库在安装过程中似乎并没有配置什么和内存相关的参数，莫非达梦数据库并没有独立的内存管理机制。

Oracle、SQLSERVER、DB2等大型数据库与ACCESS、EXCEL等小数据量数据库之前的一个重大区别就是前者拥有独立的内存管理功能，而后者只是一个操作系统上运行的应用程序，内存的分配和使用完全通过操作系统实现。

查询了一下达梦的管理员文档，发现达梦还是存在内存管理功能的，不过达梦的内存管理显得十分的简单。

达梦数据库总共包括3部分内存结构：数据缓冲区、日志缓冲区和共享内存池。

其中数据缓冲区用来缓存数据库中读取和修改的数据块，这部分由3个链表结构组成，分别是自由链表、干净链和脏链。这部分的内存结构和Oracle中的DB_CACHE部分类似；

日志缓冲区用于写入系统日志文件的缓冲，类型于Oracle中的LOG_BUFFER部分；

而共享缓冲区和Oracle中SHARED_POOL并不相同，主要用于达梦数据库小片内存的申请和释放。似乎达梦中并没有明确的共享池以及数据字典缓冲区的概念。如果是这样，那么显然不存在SQL语句重用的情况，也就是说对于所有的语句都是硬解析，这势必会对系统的并发性造成影响。

在达梦数据库中处理一些大数据量的表，然后在Windows的任务管理区中观察达梦数据库使用内存的情况。开始的时候达梦占用了50M的内存，当通过isql登陆数据库后，数据库使用内存增加，但是幅度很小。随着处理表数据量的增大（仅包含一个NUMBER类型的表），插入数据量达到100000的时候，达梦使用内存增加到了90M，随后数据量达到了1600000，而达梦使用的内存也达到了325M左右。当一段时间不再使用后，发现达梦数据库使用内存的空间又下降到100M左右。看来达梦的内存管理并不是预分配定额的内存，而是随着处理数据的增加而不断分配的，而且当一段时间不使用后，达梦数据库还会将部分内存释放给操作系统。从这一点看，达梦虽然拥有自己的内存管理系统，比ACCESS、EXCEL之类的数据库要专业一些，但是与当前的主流数据库还是有较大的差距，一方面内存管理体系过于简单，只能实现最简单的数据缓冲功能；另一方面，内存管理机制与操作系统绑定过于紧密，频繁的从操作系统分配内存，或释放空闲内存给操作系统，势必降低内存分配和管理的效率。

下面看看达梦数据库的文件部分。但是在开始之前，还是先要了解一下达梦数据库的逻辑结构。

达梦数据库的逻辑结构显然和Oracle有很大区别，而于SQLSERVER、SYBASE等数据库比较相似。在达梦数据库中存在多个DATABASE的概念，每个DATABASE由一个或多个数据文件组成。用户和DATABASE之间没有一一对应的关系。也就是说只要拥有权限，用户可以读写任何数据库中任何数据文件中的对象，因此DATABASE的概念和Oracle的TABLESPACE有十分类似。

达梦数据库也是由数据文件、日志文件、控制文件和参数文件组成的。

E:\>cd e:\dmdbms\data

E:\dmdbms\data>dir /oe
 驱动器 E 中的卷没有标签。
 卷的序列号是 9037-19E7

 E:\dmdbms\data 的目录

2010-04-09  21:40   

个文件  1,718,850,149 字节
               2 个目录  3,572,424,704 可用字节

这是一个达梦数据库的文件组成，可以看到，后缀为CTL的是控制文件，后缀为LOG的日志文件，而后缀为DBF是数据文件，而后缀为ROL是回滚数据文件。另外prikey结尾的显然是注册文件。

数据库的参数文件dm.ini没有存储在当前目录中，而是保存在达梦数据库的安装目录的可执行文件路径下C:\DMDBMS\BIN。

其中控制文件又有全局和局部之分。全局控制文件是dm01.ctl和dm02.ctl，两个文件内容相同互为备份，里面保存所有局部控制文件的信息。

对于数据库中每个DATABASE，都会存在一个或多个数据文件，一个或多个回滚数据文件，一对控制文件和一对日志文件。这显然和Oracle中的结果大相径庭，在Oracle中，控制文件和日志文件以及UNDO表空间都是对应整个数据库而言，而不是针对数据库中的某个子结构。

在一个数据库对应的控制文件中，记录数据库的数据文件的位置，回滚数据文件的位置，以及日志文件的位置。

达梦中临时文件是针对整个系统，而不是每个数据库都对应一个临时数据文件。在系统中存在一个临时数据库，这个数据库并没有对应的控制文件、日志文件和回滚数据文件，只是存在对应的临时数据文件。

在数据库中总是存在一个SYSTEM数据库，这和Oracle的SYSTEM表空间比较相似，都是用来保存数据字典等数据库正常运行所必须的结构和数据。

由于对于这种多数据库的环境还不是很熟悉，也确实这种环境下的日常使用和维护经验，因此现在不好评价这种对于每个DATABASE（相当于Oracle中的TABLESPACE）分别设置控制文件、日志文件和回滚数据文件的优缺点。不过根据当前这种结构可以推测一些优缺点。优点在于将业务数据和系统数据区分开，甚至不同的业务数据也可以分离开，这种分离比Oracle中的分离更加彻底，因为对应的日志、控制文件和回滚信息都是分离的。至于这种分离能否带来性能上的优势，或者备份、迁移上的便利，还需要测试才能确定；而缺点也显而易见，至少系统的复杂度被增加了。而且由于控制文件、日志文件和回滚数据文件对于每个DATABASE都单独放置，很明显会占用更多的存储空间，同时也使得备份和恢复会更加的复杂。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/4227/viewspace-668655/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/4227/viewspace-668655/