【IT168 独家】
编者言:在4月份举办的2010中国数据库与商业智能技术大会上,国产数据库的代表厂商达梦高调亮相,给一向由国外厂商把持的企业商业数据库市场带来不小的波澜。人们开始纷纷将目光投向国产数据库软件市场,开始关注由中国人自己开发的数据库产品。
国产数据库产品究竟能不能用?在功能和特性上够不够用?为了解开这些疑问,我们特邀请在数据库业界众多知名的技术专家亲身试用相关产品,并真实地写出自己的试用感受。这些专家大都是Oracle数据库的ACE,或者是对其它主流的商业数据库十分精通和了解,让他们站在这样的角度来客观写出自己对国产数据库的技术评测,是非常有说服力的。
尽管各位专家的工作都十分繁忙,但他们还是都认为,将国产数据库软件在技术上的真实情况书写出來,给出自己中肯的评价,这是一件非常有意义的工作。 更令人欣慰的是,相比过去,今天像达梦这样的国产数据库产品已经显得非常自信,它们希望听到业界技术专家的建议甚至是批评,不断完善自己的产品和功能,这将是一个非常良性的循环,长此下去,我们相信,摆在国产数据库脚下的将是更为宽广的道路!
作者简介:杨廷琨(网名Yangtingkun),现任海虹医药电子商务有限公司首席DBA, ITPUB论坛Oracle数据库管理版版主,知名社区技术专家。2004年曾参与编写《Oracle数据库性能优化》一书,2007年被Oracle公司授予Oracle ACE称号,喜欢研究Oracle相关的技术问题,他的技术博客上积累了1500多篇Oracle相关的原创技术文章。
前几天ITPUB的熊主编和我联系,希望我能参加国产数据库达梦的试用活动,并写几篇使用感受。本来最近手头的事情比较多,本打算推辞的,不过熊主编再三邀请,而且强调并非是枪手文,只要写出真实使用感受即可。既然如此,我就本着支持国产数据库的原则,写几篇试用感受。
达梦6.0试用之数据字典(即将发布)
达梦6.0试用之分区(即将发布)
达梦6.0试用之并发和锁机制(即将发布)
达梦6.0试用之备份恢复(即将发布)
达梦6.0试用之导入导出(即将发布)
由于本人唯一熟悉的数据库就是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:\dmdbms\data>dir /oe
驱动器 E 中的卷没有标签。
卷的序列号是 9037-19E7
E:\dmdbms\data 的目录
2010-04-09 21:40 <DIR> ..
2010-04-09 21:40 <DIR> .
2010-03-30 20:48 4,096 dm.blt
2010-04-09 12:25 16,384 dm01.ctl
2010-04-09 12:25 32,768 BOOKSHOP01.ctl
2010-04-09 12:25 32,768 test02.ctl
2010-04-09 12:25 32,768 BOOKSHOP02.ctl
2010-04-09 12:25 32,768 test01.ctl
2010-04-09 12:25 32,768 SYSTEM01.ctl
2010-04-09 12:25 32,768 SYSTEM02.ctl
2010-04-09 12:25 16,384 dm02.ctl
2010-04-12 00:35 17,825,792 SYSTEM.DBF
2010-04-12 01:10 47,185,920 TMPDB001.dbf
2010-03-30 20:56 33,554,432 BOOKSHOP.DBF
2010-04-12 00:51 10,485,760 TMPDB000.dbf
2010-04-12 01:10 104,857,600 test.dbf
2010-04-12 01:10 67,108,864 SYSTEM01.log
2010-03-29 17:18 67,108,864 SYSTEM02.log
2010-04-12 01:06 293,601,280 test02.log
2010-04-12 01:10 67,108,864 BOOKSHOP01.log
2010-03-29 17:19 67,108,864 BOOKSHOP02.log
2010-04-12 07:56 486,539,264 test01.log
2010-04-09 12:25 613 dm_service.prikey
2010-03-30 01:03 134,217,728 BOOKSHOP.rol
2010-04-09 21:40 134,217,728 SYSTEM.rol
2010-04-12 07:56 187,695,104 test.rol
24 个文件 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都单独放置,很明显会占用更多的存储空间,同时也使得备份和恢复会更加的复杂。