通常的数据迁移是通过生成一个.sql文件做为数据载体。但由于数据库平台间的方言或其它差异,是很难实现的。特别是大字段(clob,blob)。各类数据库间的处理机制差异太大。
一、数据库建模
1、借助powerdesigner,先通过逆向工程,将Oracle数据库建模。这样的好处是数据库的表关系已经建起来。
二、生成数据库schema
2、将从oracle产生的模型,正向工程。即生成MySQL数据。
这里特别要注意,正向工程前,要修改当前pd所依赖的DBMS.把它修改成mysql.否则生成的sql只能适用于oracle.
修改dbms的步骤如下:
之只后就是生成mysql数据库的schema了。
三、通过ConvertOracletoMySql迁移数据
通过这些步骤,还缺初始化数据。期间一些很可能是blob的。
这里要借助工具。比如ConvertOracletoMysql
工具一是万能的。使用过程中发现一个缺点。
1、不能迁移关系,比如主外键等。所以采用了powerdesigner
2、不能根据依赖关系自动调整数据初始的先后顺序。估计是个跟关系绝缘的家伙。
所以注意一点。先用pd建立关系。再用convertoracletomysql来迁移数据。在迁移数据时要尽量选择merge模式。也就是不要覆盖原有的表关系。只追加数据。
四、局部调整
有时会报错,数据无法成功迁移。这时候要具体分析。有时是关系不对,要比对原有的oracle数据库,确认关系都对了。有时则很可能是数据的插入的顺序不对,要先插入所外键所依赖的表的数据。一个一个的来调整。
另外:手动进行脚本调试时要注意以下几点:
1.varchar2-->varchar
2.number-->numeric
3.clob-->text
4.双引号的问题
5.保留字的问题,加``
上面我们知道了将oracle数据迁移到mysql的操作过程,下面我们来看从Oracle迁移到Mysql之前必须知道的50件事!
1、对子查询的优化表现不佳。
2、对复杂查询的处理较弱
3、查询优化器不够成熟
4、性能优化工具与度量信息不足
5、审计功能相对较弱
6、安全功能不成熟,甚至可以说很粗糙。没有用户组与角色的概念,没有回收权限的功能(仅仅可以授予权限)。当一个用户从不同的主机/网络以同样地用户名/密码登录之后,可能被当作完全不同的用户来处理。没有类似于Oracle的内置的加密功能。
7、身份验证功能是完全内置的。不支持LDAP,ActiveDirectory以及其它类似的外部身份验证功能。
8、MysqlCluster可能与你的想象有较大差异。
9、存储过程与触发器的功能有限。
10、垂直扩展性较弱。
11、不支持MPP(大规模并行处理)。
12、支持SMP(对称多处理器),但是如果每个处理器超过4或8个核(core)时,Mysql的扩展性表现较差。
13、对于时间、日期、间隔等时间类型没有秒以下级别的存储类型。
14、可用来编写存储过程、触发器、计划事件以及存储函数的语言功能较弱。
15、没有基于回滚(roll-back)的恢复功能,只有前滚(roll-forward)的恢复功能。
16、不支持快照功能。
17、不支持数据库链(databaselink)。有一种叫做Federated的存储引擎可以作为一个中转将查询语句传递到远程服务器的一个表上,不过,它功能很粗糙并且漏洞很多。
18、数据完整性检查非常薄弱,即使是基本的完整性约束,也往往不能执行。
19、优化查询语句执行计划的优化器提示非常少。
20、只有一种表连接类型:嵌套循环连接(nested-loop),不支持排序-合并连接(sort-mergejoin)与散列连接(hashjoin)。
21、大部分查询只能使用表上的单一索引;在某些情况下,会存在使用多个索引的查询,但是查询优化器通常会低估其成本,它们常常比表扫描还要慢。
22、不支持位图索引(bitmapindex)。每种存储引擎都支持不同类型的索引。大部分存储引擎都支持B-Tree索引。
23、管理工具较少,功能也不够成熟。
24、没有成熟能够令人满意的IDE工具与调试程序。可能不得不在文本编辑器中编写存储过程,并且通过往表(调试日志表)中插入记录的方式来做调试。
25、每个表都可以使用一种不同的存储引擎。
26、每个存储引擎在行为表现、特性以及功能上都可能有很大差异。
27、大部分存储引擎都不支持外键。
28、默认的存储引擎(MyISAM)不支持事务,并且很容易损坏。
29、最先进最流行的存储引擎InnoDB由Oracle拥有。
30、有些执行计划只支持特定的存储引擎。特定类型的Count查询,在这种存储引擎中执行很快,在另外一种存储引擎中可能会很慢。
31、执行计划并不是全局共享的,,仅仅在连接内部是共享的。
32、全文搜索功能有限,只适用于非事务性存储引擎。Ditto用于地理信息系统/空间类型和查询。
33、没有资源控制。一个完全未经授权的用户可以毫不费力地耗尽服务器的所有内存并使其崩溃,或者可以耗尽所有CPU资源。
34、没有集成商业智能(businessintelligence),OLAP多维数据集等软件包。
35、没有与GridControl类似的工具(http://solutions.mysql.com/go.php?id=1296&t=s)
36、没有类似于RAC的功能。如果你问”如何使用Mysql来构造RAC”,只能说你问错了问题。
37、不支持用户自定义类型或域(domain)。
38、每个查询支持的连接的数量最大为61。
39、MySQL支持的SQL语法(ANSISQL标准)的很小一部分。不支持递归查询、通用表表达式(Oracle的with语句)或者窗口函数(分析函数)。支持部分类似于Merge或者类似特性的SQL语法扩展,不过相对于Oracle来讲功能非常简单。
40、不支持功能列(基于计算或者表达式的列,Oracle11g开始支持计算列,以及早期版本就支持虚列(rownum,rowid))。
41、不支持函数索引,只能在创建基于具体列的索引。
42、不支持物化视图。
43、不同的存储引擎之间,统计信息差别很大,并且所有的存储引擎支持的统计信息都只支持简单的基数(cardinality)与一定范围内的记录数(rows-in-a-range)。换句话说,数据分布统计信息是有限的。更新统计信息的机制也不多。
44、没有内置的负载均衡与故障切换机制。
45、复制(Replication)功能是异步的,并且有很大的局限性。例如,它是单线程的(single-threaded),因此一个处理能力更强的Slave的恢复速度也很难跟上处理能力相对较慢的Master。
46、Cluster并不如想象的那么完美。或许我已经提过这一点,但是这一点值得再说一遍。
47、数据字典(INFORMATION_SCHEMA)功能很有限,并且访问速度很慢(在繁忙的系统上还很容易发生崩溃)。
48、不支持在线的AlterTable操作。
49、不支持Sequence。
50、类似于ALTERTABLE或CREATETABLE一类的操作都是非事务性的。它们会提交未提交的事务,并且不能回滚也不能做灾难恢复。Schame被保存在文件系统上,这一点与它使用的存储引擎无关。
个人比较着重以下几点:
1、对子查询的优化表现不佳
2、对复杂查询的处理较弱
4、性能优化工具与度量信息不足
12、支持SMP(对称多处理器),但是如果每个处理器超过4或8个核(core)时,Mysql的扩展性表现较差。
15、没有基于回滚(roll-back)的恢复功能,只有前滚(roll-forward)的恢复功能。
18、数据完整性检查非常薄弱,即使是基本的完整性约束,也往往不能执行。
20、只有一种表连接类型:嵌套循环连接(nested-loop),不支持排序-合并连接(sort-mergejoin)与散列连接(hashjoin)。
21、大部分查询只能使用表上的单一索引;在某些情况下,会存在使用多个索引的查询,但是查询优化器通常会低估其成本,它们常常比表扫描还要慢。
26、每个存储引擎在行为表现、特性以及功能上都可能有很大差异。
28、默认的存储引擎(MyISAM)不支持事务,并且很容易损坏。
30、有些执行计划只支持特定的存储引擎。特定类型的Count查询,在这种存储引擎中执行很快,在另外一种存储引擎中可能会很慢。
31、执行计划并不是全局共享的,仅仅在连接内部是共享的。
33、没有资源控制。一个完全未经授权的用户可以毫不费力地耗尽服务器的所有内存并使其崩溃,或者可以耗尽所有CPU资源。
45、复制(Replication)功能是异步的,并且有很大的局限性。例如,它是单线程的(single-threaded),因此一个处理能力更强的Slave的恢复速度也很难跟上处理能力相对较慢的Master。
46、Cluster并不如想象的那么完美。或许我已经提过这一点,但是这一点值得再说一遍。
47、数据字典(INFORMATION_SCHEMA)功能很有限,并且访问速度很慢(在繁忙的系统上还很容易发生崩溃)。
48、不支持在线的AlterTable操作。
50、类似于ALTERTABLE或CREATETABLE一类的操作都是非事务性的。它们会提交未提交的事务,并且不能回滚也不能做灾难恢复。Schame被保存在文件系统上,这一点与它使用的存储引擎无关。
小编结语:
更多内容尽在课课家教育!
¥48.00¥180.00
¥199.00
¥798.00
¥29.90
¥48.00¥180.00
¥199.00