数据库部署
关于DM数据库安装部署的详细内容，可以参考《DM_Install_zh.pdf》。
创建操作系统用户
达梦数据库的运行需要使用专用的dmdba用户，因此需要创建相关用户。
groupadd dinstall
useradd -g dinstall -m dmdba
DM数据库
运行/DMInstall.bin -i
检查操作系统限制
运行 ulimit -a 进行查询。修改open files为 65536 以上或 unlimited(无限制)。
如果用户需要为当前安装用户更改 ulimit 的资源限制，请修改文件 /etc/security/limits.conf
初始化数据库实例
运行以下命令初始化数据库实例（页大小32K，redo大小2048MB，开启归档）：
|
cd /db/dmdbms/bin ./dminit path=/db/dmdata/ PAGE_SIZE=32 LOG_SIZE=2048 ARCH_FLAG=1 |
修改数据库参数
执行命令vi /db/dmdata/DAMENG/dm.ini,并修改以下参数：
|
参数名称 |
取值 |
备注 |
|
BUFFER |
3000 |
用于缓存数据页，一般配置为操作系统物理内存的60%~80% |
|
MAX_BUFFER |
3000 |
用于控制系统缓冲区的上限，一般配置为和BUFFER参数相等 |
|
CALC_AS_DECIMAL |
1 |
1：表示整数类型的除法全部转换为DEC(0，0)处理,用于与ORACLE兼容 |
|
COMPATIBLE_MODE |
4 |
是否兼容其他数据库模式，2：兼容 ORACLE |
|
RECYCLE |
1000 |
用于缓存排序、分组、临时表等产生的临时数据 |
|
DICT_BUF_SIZE |
50 |
字典缓冲区大小，以兆为单位当数据库对象较多建议适当放大 |
|
TEMP_SIZE |
1000 |
默认创建的临时表空间大小，以兆为单位。有 效值范围（10~1048576 ），不断的扩充临时表空间也会影响性能，生产系统建议改为1000 |
|
CACHE_POOL_SIZE |
500 |
SQL 缓冲池大小，以兆为单位。有效值范围： 32 位平台下为（1~2048）；64 位平台下为 （1~67108864）。单位：MB |
|
MAX_SESSION |
1000 |
系统允许同时连接的最大数，同时还受到LICENSE的限制，取二者中较小的值，有效值范围（1~65000 ） |
|
MAX_SESSION_STATEMENT |
20000 |
单个会话上允许同时打开的语句句柄最大数，有的应用忘记关闭语句句柄，导致报错，这个参数可以适当放大 |
|
VIEW_PULLUP_FLAG |
1 |
是否对视图进行上拉优化，把视图转换为其原 始定义，消除视图。0：不启用；1：启用。一般建议启用。 |
|
CNNTB_OPT_FLAG |
2 |
是否使用优化的层次查询执行机制。0：不使用；1：强制使用；2：优化器自动决定是否使用 |
数据库用户创建(示例)
|
create user RPMDATA Identified By TAYH2021#; grant RESOURCE,VTI to RPMDATA; |
在Oracle迁移到达梦的过程中，因为达梦和Oracle均支持SQL92标准，因此可以直接使用DTS进行迁移替代。
数据移植
本次迁移过程中，一共有表1168个，存储过程62个，视图7个，序列27个，函数21个等，因此有一定的迁移代价，经过实际迁移过程之后发现主要的迁移难点是存储过程的迁移，但是均可以在数据库层面进行等价修改之后手动创建
Oracle数据库用户对象迁移统计汇总
|
类型 |
Oracle数据库 |
迁移代价 |
|
表 |
1168 |
0个修改 |
|
函数 |
21 |
0个修改 |
|
存储过程 |
62 |
30个等价修改（从数据库层面修改） |
|
视图 |
7 |
0个修改 |
|
序列 |
27 |
0个修改 |
|
包 |
2 |
0个修改 |
|
自定义类型 |
1 |
0个修改 |
使用DTS工具先完成数据表迁移，并手动处理报错对象。表迁移
对于表数据的迁移，使用DTS工具进行数据迁移，按当前的测试数据量，整个数据库迁移时间耗时4小时，主要个人电脑配置问题，迁移效率较低。
CPU、内存、磁盘IO，网络等硬件的配置，对数据迁移效率影响较大。如果提升硬件配置，迁移效率应该会有进一步提升。
目前存储过程和函数也是通过DTS进行了迁移，存储过程中有部分是在源端Oracle上就无法编译过去，因此到达梦中忽略进行编译，部分进行了等价修改，均是在数据库层面进行了修改，不涉及应用修改；函数部分，同样存在Oracle上无法编译过去的问题，进行了忽略，其他正常迁移；整个迁移过程
迁移任务清单
|
类型 |
数量 |
|
|
表 |
1168 |
|
|
视图 |
7 |
|
|
序列 |
27 |
|
|
存储过程 |
62 |
|
|
函数 |
21 |
|
|
包 |
2 |
|
|
公共同义词 |
33275 |
|
|
触发器 |
0 |
|
|
自定义类型 |
1 |
备注：
1、清单所列的项包含了很多不属于系统的数据库客体，故部分客体再迁移后报错不做二次处理。
2、表中数据量都不大，因此全部使用了DTS进行迁移。
中有两个包，均由DTS自动迁移完成。
迁移问题汇总
在本次迁移中，遇到的问题主要有以下几个方面，均为存储过程上的问题。
1、存储过程
在存储过程的迁移中，有部分存储过程无法自动迁移，查看原库中存储过程中
因此，将null去掉之后手工创建存储过程即可完成，大部分无法迁移的存储过程都有这个问题。
2、存储过程编译时报错“不是Group By表达式”
有一个存储过程在编译时报错“不是Group By表达式”，通过修改dm.ini的兼容性参数，兼容MySQL之后即可正常编译。
3、其他问题
存在部分在Oracle上就没有正常编译的存储过程和函数，因此在本次迁移中也忽略创建
根据《程序员手册》中JDBC部分修改相应连接串，如下所示：
// 定义 DM JDBC 驱动串
String jdbcString = "dm.jdbc.driver.DmDriver";
// 定义 DM URL 连接串
String urlString = "jdbc:dm://localhost:5236";
// 定义连接用户名
String userName = "USER_NAME";
// 定义连接用户口令
String password = "USER_PASSWD";
暂时未进行应用移植工作。
应用修改
因为达梦和Oracle的高度兼容性，JAVA程序迁移，基本只需要修改连接串就可以。
小结
1）数据库对象的兼容性良好；数据库对象基本可以通过DTS工具自动迁移，少部分需要手动修改；在迁移完成之后，后续需要继续与开发配合进行应用移植工作，包括应用连接数据库验证功能、使用压测工具例如LoadRunner进行压力测试等工作。
2）此次迁移工作，共用了1个工作日，其中数据库迁移和问题处理用了1个工作日，迁移过程较为顺利，大部分对象由DTS自动迁移完成。
