达梦数据库（DM6)和ORACLE 10g的异同点 |
| https://bbs.aliyun.com/detail/351337.html |
![[转帖]达梦数据库（DM6)和ORACLE 10g的异同点_第1张图片](http://img.e-com-net.com/image/info8/64a83c91b89f44adb3736f315969245a.jpg)
级别: 小白
|
只看楼主 更多操作楼主 发表于: 2017-03-24
比较惭愧，在当上本版版主后一直没有贡献一篇有营养的帖子，由于手上正好有达梦数据 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, 数据, 版本, 工作 |