比较惭愧，在当上本版版主后一直没有贡献一篇有养分的帖子，因为手上正好有达梦数据 DM6的版本，加上对ORACLE 10G比较熟悉，因此就这2种数据库的异同点作一个对比，也请你们不吝赐教。 对于达梦数据库，由于目前的工做是DBA，主要是对照了Oracle的一些概念来理解DM的，如下是我的的一些心得体会。 1.安装与内存结构 环境是Red Hat 5.5,这个也是服务器比较经常使用的Linux系统。 DM没有Oracle那么多的系统参数要设定，并且也不须要创建专门的安装用户，直接把文件解包后就能够安装了，整个过程10分钟左右就结束了，对于初学者来讲仍是比较简单的，而Oracle，当初刚学的时候，光是安装就花了1天，要配置的参数比较多，还要新建用户，对于不熟悉Oracle和Linux操做系统的人来讲比较痛苦。 跟Oracle同样，DM安装完以后会把DM_HOME的路径写到用户的.bash_profile文件里面去，这样在命令行打 cd $DM_HOME能够直接进入DM的家目录，不过DM并无把bin的命令路径加到.bash_profile文件里面，这样要在命令行执行isql，dmcc这些命令就须要进入$DM_HOME/bin目录下。为了方便起见，能够在root用户根目录下的.bash_profile文件里面的PATH后面再加上 :$DM_HOME/bin，以下： Export DM_HOME=/opt/dmdbms PATH=$PATH:$HOME/bin:/opt/dmdbms/bin 这里也能够写上绝对路径，另外推荐一个小工具rlwrap，这个包是用来在命令行上下翻页的，对于习惯了命令行操做的人来讲非常方便，在Linux下安装好以后一样在bash_profile配置文件里面加入一行以下： alias isql=`rlwrap isql` 这样，在命令行执行isql命令时，实际上就至关于执行了rlwrap isql。 在DM安装的时候选择高级配置，会要求你选择页以及簇的大小，对于这个页DM的文档里面说明是数据库存放数据最小的单位，对应的就是Oracle里的数据块了，而簇是一组页的集合，是存储空间分配的最小单位，一个数据文件至少包含一个簇，单位是页的个数，其对应的是Oracle里面的extent，也就是区。 DM的逻辑存储结构从上至下依次是：数据库--文件组--簇--页 oracle则是：表空间--段--区--块 在这里，表空间对应的是文件组了，而DM里面我以为应该也有一个段的概念，也就是用于存放一个数据库对象的空间，好比表和存储过程。一个段能够包含多个簇或者区，在Oracle里面，extent与extent之间的数据块并不必定是连续的，可是单个extent内部的数据块则必定是连续的，由于空间扩展的时候是按照连续的数据块来分配的，我想对于DM的簇和页的关系应该也是这样设计的，这样对应Oracle就很好理解了。 在内存方面，DM提供了MEMORY_POOL,BUFFER,LOG_BUFF和SORT_BUF_SIZE。 前面3个内存部分分别对应Oracle SGA里面的shard_pool,buffer_cache和log_buffer. 其中MEMORY_POOL里面存放的是SQL语句的执行计划以及系统表和动态视图。 BUFFER里面则是存放DM所要读取或者修改的数据，这里DM提供2个机制，直接从硬盘读取以及走文件缓冲，由参数direct_io来控制。经过BUFFER的好处就是DM不用频繁地从硬盘读取或者写入数据，而是由DM的检查点机制来控制写数据的时机，这点也跟Oracle很相似，只是检查点触发的机制上有差别。 DM的BUFFER里面也设计了3条链，自由链，干净链以及脏链 自由链上所记录的是内存里面还未使用过的内存块。 干净链上所记录的则是已经使用过但未作修改的内存块，也就是进行select操做所读入内存的数据块。 而脏链则记录读入内存后通过修改而且尚未刷入到磁盘的数据内存块。 Oracle的buffer_cache里面也有相似的链，LRU链和脏链，LRU链对应的是DM的自由链和干净链的集合，全部可用的内存块是在LRU链上进行查找的，脏链上所记录的内存空间是不能被使用的。 DM的干净链也是采用的LRU算法进行管理的，当某个数据库操做须要读取数据进内存的时候，会先检查自由链，看有没可用的内存块，若是有则直接使用，而且把这些内存块移到干净链上，若是通过了修改则移动到脏链上。 若是在自由链上找不到可用的内存块，则到干净链上根据LRU算法来决定哪些内存块可被使用，若是在干净链上也找不到可用的内存块，那么就会触发检查点来把内存里面的数据刷新到磁盘。 对于Oracle，是经过扫描LRU链的长度的百分比以及脏链上数据占总的数据缓冲区大小的百分比来触发刷新操做的，由于在实际的生产库中，BUFFER_CACHE通常都设定的很大，扫描整个LRU链时间会比较长，因此Oracle就加了这么一个机制。 DM有关这方面的参数控制我暂时还没找到，有待进一步研究吧：）。 对于日志缓冲区，log_buff，是用来记录对于数据库所进行的修改操做，也就是REDO，这点跟Oracle是一致的，其刷新的策略也跟Oracle一致，这个很好理解了。 对于Oracle的PGA部分，也就是用户全局区，DM没有专门的内存与之对应，应该是交由操做系统进行管理了，我只找到一个SORT_BUF_SIZE参数，是用来控制排序缓冲和索引重建的内存大小。 =============================================================================================================== 2.体系架构 跟Oracle同样，DM的数据文件也分控制文件，日志文件，数据文件三种，其中日志文件又分为*.rol和*.log，分别对应undo和redo。 跟oracle不同的是DM的控制文件分为全局控制文件和局部控制文件，全局控制文件里面存放的是当前DM的全部数据库的控制文件的存放位置，在linux下可用strings命令来查看其内容，例如： [root@tiger database]# strings dm01.ctl CM11 -KgU SYSTEM /soft/dmdatabase/database/SYSTEM01.ctl /soft/dmdatabase/database/SYSTEM02.ctl test /soft/dmdatabase/database/test01.ctl /soft/dmdatabase/database/test02.ctl htyro /soft/dmdatabase/database/htyro01.ctl /soft/dmdatabase/database/htyro02.ctl 以上输出表示当前的控制文件中一共记录了3个库，SYSTEM，test，htyro。其中SYSTEM是系统默认的库，是在安装软件的时候系统默认创建的，其记录一些全局的信息，对应Oracle的SYSTEM表空间。 这个库很是重要，不能被脱机，一旦损坏，dmserverd服务将没法启动。 下面来看看局部控制文件中所记录的信息吧，以上面的test01.ctl为例，输出以下： CD11 %s%t.log /soft/dmdatabase/database /soft/dmdatabase/database PRIMARY /soft/dmdatabase/database/test01.dbf ROLL /soft/dmdatabase/database/test.rol RLOG /soft/dmdatabase/database/test01.log /soft/dmdatabase/database/test02.log 能够看到，其记录的是当前数据库test里面的数据文件，日志文件的存放位置。 全局控制文件和局部控制文件通常都有2个以上，互为镜像，内容都是同样的，就是防止单个控制文件损坏了数据库没法启动的状况，建议存放在不一样的磁盘。 另外须要注意的是，全局控制文件dm.ctl里面所记录的控制文件一旦有任何一个损坏，那么dmserver则没法启动，而局部控制文件里面所记录的文件有损坏的话，只是其对应的数据库没法联机，但并不影响其余数据库的正常运转，因此无论是全局控制文件仍是局部控制文件都是至关重要的 在运行机制上，Oracle是一个实例对应一个库，也只能对应一个库，而DM则是一个实例对应多个库。DM的每一个数据库都有本身单独的控制文件，日志文件以及回滚段文件，这个也与Oracle的单实例的结构相同，所不一样的是临时文件TEMP是全局的，也就是多个库都是使用的同一个临时文件。 ============================================================================================================== 3.用户登陆 在DM的使用方面，刚开始确实很不习惯，一个首要的缘由就是DM把传统的用户拆分为登陆＋用户，致使我在登陆数据库的时候老是习惯性的写上用户名而不是登陆名。 同oracle同样，DM的权限赋予以及回收也是在用户层面上的，实际操做数据库的仍然是用户，可是把链接这个环节单独拿出来作成了一个登陆（login)的概念，一个用户必需要与一个登陆相关联才能够正常使用数据库，不然即便你是DBA没有与之关联的登陆也是操做不了数据库的，就比如你住在某个高档小区，下面的门须要一把钥匙，进你家的门也须要一把钥匙，登陆就至关于进入公共区的钥匙，只有住在这个单元的人或者管理人员才有，而用户则至关于私有区也就是你家大门的钥匙，只有你才有。 不知道这个比方是否够清楚：），反正我也是绕了很久。 DM使用这样的机制，是对应其三权分立的权限管理模式，除了sysdba ,还有syssso和sysaudit 2个用户，其中syssso就是管理登陆的，这样的管理机制对于单纯的DBA管理安全性要高。而sysaudit则是安全审计员，专门用于记录及监视对数据库所进行的操做，在Oracle里面audit（审计）也是DBA的工做，DM则单独把这个权限独立了出来，从必定程度上也减轻了DBA的负担。 与Oracle同样，DM除了能够把单独的权限赋给用户以外，还能够创建一个角色(role)，而后先把权限赋予角色，再把角色总体权限赋给用户，这种在生产库里面比较经常使用，特别是开发库中，要新增一个user的话，要赋不少权限，若是事先定义好其对应的角色，经过角色授予权限则会简单的多。 ============================================================================================================== 4.数据库启动以及系统日志 数据库的启动信息以及系统的日志记录信息是DBA重点关注的内容，这里也结合一下Oracle的机制来学习DM。 Oracle的启动是分3个阶段的： nomount: 此阶段加载配置文件以及启动本实例的后台进程 mount: 此阶段加载配置文件里面所记录的控制文件 open: 此阶段则是打开控制文件里面所记录的数据文件 Dm的启动则只有一个过程，这点经过监视DM的后台日志能够看到，如下是我在启动阶段监视$DM_HOME/log/dm_00.log系统日志的内容： tail -f $DM_HOME/log/dm_00.log 2010-09-29 09:31:21 database T-1208297792 DM Database Server startup... 2010-09-29 09:31:21 database T-1208297792 check point start (1, 0, 100) ... 2010-09-29 09:31:21 database T-1208297792 redo log flush ... 2010-09-29 09:31:21 database T-1208297792 system buffer flush ... 2010-09-29 09:31:21 database T-1208297792 check point end. 从上面内容能够看到，DM只有startup这个过程，接下来就会触发一个检查点来刷新内存。但实际上，DM也是有本身的参数文件的，在$DM_HOME/bin目录下，名称是dm.ini，其记录数据库的一些全局的参数，前面三行内容以下： #files location CTL_PATH1 = /soft/dm6/dmdatabase CTL_PATH2 = /soft/dm6/dmdatabase TEMP_PATH = /soft/dm6/dmdatabase 这个是指明全局控制文件以及临时文件TEMP的存放路径，而Oracle的pfile/spfile里面也存放了控制文件的路径，因此这个dm.ini参数能够参考Oracle的pfile来学习。 注意为何是pfile而不是spfile呢？由于spfile是Oracle为了能让某些修改在数据库运行的状况下就能够进行即动态修改，而专门从pfile转换而来的一个二进制文件，其内容跟pfile是同样的，可是若是使用pfile就只能静态修改，即修改以后须要重启数据库才能生效。DM目前还不支持动态的全局参数修改，须要先停库，而后再修改，因此说dm.ini和pfile是很相似的。 由于手上没有DM内部运行机制的资料，因此无从了解DM的完整的启动机制，可是从DM的参数结构配置来看，我的猜想DM启动也是先读取dm.ini参数文件为数据库实例搭建好启动环境，指明全局控制文件和临时文件的位置，而后再读取全局控制文件找到局部的控制文件，最后读取局部的控制文件找到数据文件，而后再OPEN。这样理解起来就很快了，也没什么障碍。 关于系统日志文件，我目前只在$DM_HOME/log下面找到了，相比Oracle种类繁多的日志，DM就简单许多了，总之把$DM_HOME/log/dm_00.log当作是Oracle的后台日志alert_sid.log就对了，数据库启动以及恢复以及检查点的信息都记录在这个日志文件里面，经过监控能够看到，备份的信息也会记录到DM的日志文件。 =============================================================================================================== 5.数据库的基本操做以及系统视图 DM的SQL是兼容SQL92标准的，因此绝大多数操做与Oracle没什么区别，我测试了几条select,update,delete语句，与Oracle的是彻底一致的，这点上没什么问题。 命令行的登陆方式也比较相似： Oracle: sqlplus user/password@host DM: isql user/password@host 若是是本机，则host能够省去，若是是远端服务器，则HOST须要指明远端的服务器名或者IP地址。 在这里须要说明的是Oracle若是是本机直接用Oracle登陆，那么不须要用户名和密码便可使用DBA模式，而登入远程服务器时才须要使用密码验证。而DM则无论是本机仍是远端的机器，都须要提供登陆名/密码，并且我查看了相关的文档，也没有看到有能够在命令行修改SYSDBA密码的命令，也就是说DM的登陆密码修改必须进入数据库系统以后才能操做，若是忘记了DBA的登陆密码会比较麻烦，暂时我还没想到好的解决办法，而Oracle则提供有orapwd命令用于从新设定DBA用户的密码。 对于执行过程的建立以及执行DM跟Oracle的语法基本一致，DM也兼容PL/SQL,因此在这个上面倒不须要另外花时间来掌握。为了兼容Oracle, DM也提供了exec 来调用procedure的方式，可是推荐用call的方式来调用。 另外Oracle的信息打印输出是用的其自带的系统执行过程 dbms_output.put_line()来实现的，而DM 则是经过 print的方式，了解清楚了这个，对于之后Oracle的移植颇有帮助。 Oracle在逻辑上提出了模式(schema)的概念，但实际上并无schema关键字的视图，可是有user_object的视图，实际就是用户下面的全部对象的集合，好比下面的操做： select * from scott.emp; 表示查询scott用户下的emp表，实际也能够理解为访问scott模式（集合）下的emp表。 Oracle默认是每一个用户在建立的时候会同时再创建一个schema（集合），也能够理解为一个容器，里面存放的是全部属于该用户的对象，好比表，索引，存储过程，函数，包等等。在Oracle里面不能单首创建schema,一个用户只有一个schema(模式）。 而DM则把schema的概念更加清晰化了，系统在建立用户的时候会默认建立一个与该用户同名的schema，而且还提供了create schema at database authorization user命令来单独的建立属于某个用户的schema，也就是说一个用户能够拥有多个schema，这样就便于用户把不一样的对象放到不一样的可是属于本身的schema里面，方便管理。 相对于Oracle,DM所提供的系统视图并很少，不过关键的视图都有了，好比systables,sysindexes这些。 Oracle的系统视图结构比较庞大，不只仅dba能够查看全局的视图，普通用户也能够查看本身所拥有的对象的视图好比user_tables,user_indexes等等。 而DM对于单个用户则没有提供这些视图，DM的视图和系统表是针对数据库实例（全局）和单个数据库（局部）的，而动态性能视图如v$buffer则是只有SYSTEM数据库才有的，用于查看整个数据库实例的动态信息，而其余一些系统表好比systables,sysindexes等等则是每一个数据库本身会生成一份，存放在各个数据库的sysdba模式下面，默认的拥有者是系统管理员DBA。 我的但愿DM在后面的版本里面可以增长更多的系统表和视图，以及对现有关键视图的信息更加完善，从DBA的角度来讲，这些系统视图也是维护数据库的一个很重要的信息来源。 =============================================================================================================== 6.数据库的备份与恢复 做为一个DBA，数据库的备份是其最重要也是最常要作的操做，这里我也结合一下Oracle的备份恢复机制来讲一下对DM的备份恢复机制的理解。 Oracle和DM的数据库运行模式都有归档模式和非归档模式，通常状况下数据库都运行在归档模式下，由于在归档模式下全部的联机日志都是有备份的，这样能够最大可能的保证数据库数据的完整性，而非归档模式则不会备份联机日志，通常只在不过重要的数据库上才使用非归档模式，如下的备份恢复均是在归档模式下进行的。 Oracle的备份可分为操做系统层面的备份（直接COPY）和用数据库工具的备份（rman),而操做系统层面的备份又分为冷备和热备，即在停库状况下的备份和数据库运行状况下的备份。 rman备份则手段更多，也更灵活，而且管理起来也更加方便。 DM的备份也分为联机备份和脱机备份，实际都是利用DM的数据库命令来完成的。DM目前不支持操做系统层面的备份，即冷备，我作了一下测试： a. 在T1时刻中止数据库服务，把数据库TEST所对应的TEST01.dbf文件复制一份到备份目录中，从新启动数据库。 b. 在T2时刻创建测试表T1于数据库TEST上（T2>T1),而后尝试插入若干条数据，再提交。 c. 在T3时刻中止数据库服务，把 a 步骤所备份的TEST0.dbf从新复制回来，覆盖T2时刻创建了表T1的数据文件。 d. 从新启动数据库服务，发现数据库TEST也能够正常启动，可是查询表T1发现不存在此表，可是T1时刻的数据都在，可是T1－T2这个时间段的数据就丢失了。 我查了一下DM的文档中有关备份恢复的部分，DM的恢复也是分restore和recover两步的，但只提供了restore命令，recover动做是跟restore绑定在一块儿的，经过在restore命令里面设定archivedir的路径来让数据库自动应用归档日志来对数据库进行恢复。因此对于冷备份的数据文件，DM没有提供单独recover的机制来应用日志到数据文件上，因此在目前的DM体系架构中，使用操做系统的COPY命令来备份数据库意义不大，推荐使用DM的backup命令来进行备份，这样备份才能跟归档日志结合在一块儿进行恢复。 另外须要注明的是，DM的SYSTEM数据库不能经过脱机恢复，因此此数据库损坏的话，只能中止数据库，而后经过DM所提供的restore命令来进行恢复，该命令位于$DM_HOME/bin目录下，此命令与联机方式下的普通数据库恢复的restore命令功能不同，其使用方法以下： RESTORE ini_path bak_path [-T | -t res_type] [-U | -u until_time] [R | -r arch_num arch_dirs] [-A | -a arch_flag arch_style arch_dir] [-B | -b bak_dir] [-D | -d db_name] 其中，dm.ini 文件和备份文件的地址是必需要指定的，然后面的参数是可选的。 而在Oracle中，restore和recover是两个操做步骤，是分开的，因此冷备份数据文件也是有意义的，把冷备的数据文件COPY回来以后，只要备份时间到当前的归档齐全，就能够执行recover动做来使得数据库一致。 跟oracle同样，经过数据库所提供的工具/命令来对数据库进行备份的时候，数据库能够在online状态下，而对数据库进行恢复的时候，则要使被恢复的数据库处于offline状态，恢复完毕以后再把数据库置于online状态。 在DM中，能够动态修改数据库的归档模式，命令以下： alter database test archivelog; --------------设置为归档模式 alter database test noarchivelog; --------------设置为非归档模式 这个参数在Oracle里须要在数据库mount的状态下进行修改，是记录在控制文件里面的，DM里面我暂时还没发现这个参数记录在哪里，可能也是记录在控制文件里面的。总之DM修改数据库的归档模式不须要重启，而Oracle修改归档模式则须要重启库。 下面我在命令行对测试库TEST来进行一次备份以及恢复的操做以便综合掌握DM的备份恢复机制。 1.命令行登陆DM，对TEST作一次全备，备份名为test_bak: [root@chris dmserver]# isql sysdba/728911@localhost isql V6.0.2.72-Build(2010.08.02) login success SQL>backup database test to test_bak bakfile '/soft/dm6/test001.bak'; backup database test to test_bak bakfile '/soft/dm6/test001.bak'; time used: 7352.304(ms). 2.删除数据库TEST的数据文件，联机日志文件以及UNDO文件，重启数据库服务，在后台日志里面发现以下信息： 2010-09-29 14:02:21 database T-1208138048 os_file_open error! path: /soft/dm6/dmdatabase/TEST.rol, code: 2 2010-09-29 14:02:21 database T-1208138048 os_file_open error! path: /soft/dm6/dmdatabase/TEST01.log, code: 2 2010-09-29 14:02:21 database T-1208138048 os_file_open error! path: /soft/dm6/dmdatabase/TEST02.log, code: 2 2010-09-29 14:02:21 database T-1208138048 os_file_open error! path: /soft/dm6/dmdatabase/TEST03.log, code: 2 2010-09-29 14:02:22 database T-1208138048 os_file_open error! path: /soft/dm6/dmdatabase/TEST.rol, code: 2 2010-09-29 14:02:22 database T-1208138048 fail to open db file /soft/dm6/dmdatabase/TEST.rol 数据库服务仍然能够启动，只不过TEST数据库是脱机的，没法访问。 3.对数据库TEST进行恢复，命令以下： SQL>restore database test from '/soft/dm6/test001.bak' set archivedir to '/soft/dm6'; restore database test from '/soft/dm6/test001.bak' set archivedir to '/soft/dm6'; time used: 7371.193(ms). 同时，在后台日志里面也能够发现以下信息。 2010-09-29 14:08:23 database S-1233137636 restore using /soft/dm6/test001.bak with 0 2010-09-29 14:08:31 database S-1233137636 restore end. 恢复成功后再使用命令alter database test set online来把数据库TEST启动起来便可。 整个备份以及恢复的过程跟Oracle很类似，Oracle经过RMAN备份格式以下： rman> backup database full format '$ORACLE_BASE/backup/bak_%U'; 而oracle恢复的过程也是先把须要恢复的表空间或者数据文件offline,而后进行restore和recover操做，最后再执行online动做。 DM与Oracle都提供了完整备份和增量备份的方式，不过说实话增量备份在生产库中用的很少，拿我以前的库来讲，由于用到了DATA GUARD，我是每周末在备库上进行一次完整的备份，同时删除2周以前的备份以及归档，保证整个数据库有2份可用的备份以及能够衔接的归档日志便可。 DM目前版本的备份只包含了数据文件，日志文件以及UNDO文件，对于在归档模式下所生成的归档日志以及控制文件和DM.INI参数文件还没法备份，因此归档日志的存放路径必定要规划好，在大的数据库里面必定要留足够的空间来存放归档，控制文件和参数文件则可经过脚本的方式按期备份。 总的来讲，DM的备份与恢复仍是要比Oracle要方便的，特别是利用管理工具，操做很直观，不过这里使用命令行来进行操做印象会更加深入。 以上是我在初步使用了达梦数据库的一点体会吧，整体上来讲DM的体系架构综合了Oracle和Mysql，运做方式上来看跟Oracle更加类似，从内存结构到数据文件的类型再到备份恢复的机制均可以在Oracle里面找到熟悉的部分，若是对Oracle的系统架构很熟悉的话，学习DM也是水到渠成的事了。 另外，对于DM的集群以及主备机的机制则跟Oracle有较大的不一样了，我目前也还在看相关的文档，虽然DM的主备与Oracle的DG模式都是利用的日志传递的方式来保持主备机器的数据一致性，可是由于DM多了一个登陆的概念，因此在具体的实现机制上仍是有所差别的，而DM的集群则跟Oracle结构彻底不同了，DM的集群是在主备机的基础上加以改进，让主机和备机都能跟外界通讯，主备之间采起的环形消息传递机制，而且每一台机器都是独立的数据库，而Oracle则采用把数据文件存放在共享存储上面，多台服务器对共享存储及同一份数据文件进行操做的方式来运做的，机制是彻底不同了。 数据库, Oracle, 数据, 版本, 工做
