Oracle和MySQL的数据导入为何差别这么大

    经常会有一些朋友咨询我一些数据库的问题,我注意到一个很有意思的现象,凡是数据导入的问题,基本上都是Oracle类的,MySQL类的问题脑子里想了下竟然一次都没有。

    我禁不住开始思考这个未曾注意的问题:

    为什么Oracle导入数据会碰到很多的问题?

    我们来梳理一下这个问题,分别从导出导入的方式来聊聊。

    首先Oracle导出的文件格式就没打算让你拿来即用,导出文件叫做dump,换句话说可以理解这是一个二进制文件。当然实际上这个文件还是有很多的方式去抓取一些关键的信息,比如dump头部的信息可以通过strings来解析得到,我甚至在多年前碰到一个比较棘手的问题,DBA直接vim修改dump文件,这个操作风险和成本是比较高的。

    导出有哪些工具呢,主要有exp,expdp这两个工具,expdp的导出性能相对来说可以更加充分利用系统资源,导出的效率更高。exp相对来说对于一些小表还是比较省事的,expdp的导出是基于服务端模式的,也就是你需要做一些数据库层的配置才可以,这无疑增加了一些技术门槛。

    不知道大家注意到一个问题没有,那就是Oracle提供了SQL*Loader的工具导入,但是却没有一直提供一种简单有效的导出csv的工具,在导出的时候算是各路英雄汉使尽各种技艺,结合数据字典,结合文本过滤来完成。

    MySQL的导出方法相对比较简单,设计思路很有意思,导出的文件就是可以直接打开,可以直接修改的SQL文件。这个设计在很多应用场景中简直绝了,对于开发同学是非常友好的。

    导出工具原生的有mysqldump,新版本的是mysqlpump(总体感觉性价比不是很高),当然还有一些补充的第三方工具,比如mydumper之类的。

    所以导出这件事情,对于开发同学本身是有一个门槛的,而且在隔行如隔山的情况下,很多同学使用expdp导出的时候都一头雾水。从安全性来看,这个二进制文件是原汁原味的,从灵活性来看,MySQL基于SQL文本的方式是比较便捷。

    导出的部分其实不是最主要的,产生隔阂最大的是导入的部分,也是提出问题最多的。

    MySQL有什么数据导入工具,可以理解没有,就是SQL文本,你想怎么执行都可以。包括工具mysqldump,mysqlpump导出的文件都是如此,mydump有个配套的myloader算是一个小小的例外。

    Oracle有什么导入工具,有,而且是配套的,exp对应imp,expdp对应impdp

    常见的数据导入问题有:

    1)提示用户创建失败,导入失败

    2)提示表空间不存在,导入失败

    3)导入时如果创建的数据文件空间不足,导入失败

    4)导入时的用户权限不足,导入失败

    所以我要导入一个dump文件,如果是exp导出的,解析成本还算低一些。

    而如果是expdp导出的,通常很多开发同学都会一脸懵逼。

    1)导入要输入一个目录,什么是目录,不是系统目录吗?

    2)如果数据库用户已经存在,已经存在10张表,导入的时候默认会直接忽略这10章表,除非你手工删除或者选择额外的选项,比如replace或者truncate等。

    3)表空间源端和目标端环境不一致,要想知道到底有哪些表空间不一致,解析dump文件实话说不是很方便,有一个高级选项是remap_tablespaces

    4)数据导入之后,业务同学发现有些表还是访问不了,不好,需要重新分配下权限。

    通常来说,如果要导入一个dump,在Oracle侧其实是一件很严肃的事情,我们需要创建目录:

    create directory dump_data as ‘/data/dump_data’;

    grant read,write on directory dump_data to xxxx;

    配置表空间存储,有哪些表空间,哪些表空间需要映射,在数据导入之前,这些信息其实是不好提取的。我通常采用的方式是做下预导入,就是找个干净的环境,然后默认选项导入,看看哪些表空间报错,哪些用户报错,把这些信息提取出来,然后重新拼接一个导入命令。

    在这个基础上我去构建相关的表空间和数据文件的细节。

    对于数据文件,我不大喜欢自动扩展的方式,而是喜欢预创建出来,然后加上自动扩展。

    最后就是文件导入

    impdp system/xxxx directory=dump_data dumpfile=test.DMP logfile=impdp_test.log remap_tablespace=TEST_DATA1:DATA,TEST_DATA2:DATA,TEST_INDEX1:IDX,TEST_INDEX2:IDX

    对于Oracle DBA来说,这应该是再正常不过的事情了,而且有很多地方要做到细致周到的多,但是这样一个过程对于一个外行来说,成本就很高了。

    总是有一种感觉,Oracle就像汽车里面的宝马一样,操控性很好,提供了很多专业有效的管理方式。

    而Oracle的角色通常都是百GB起,TB上下,这样的数据量管理,就得适配出各种工具特点和特性。我觉得这些工具一直在追求的是更加高效和安全,可能从这个角度理解,Oracle的维护管理模式是需要专人来完成的。

    MySQL的管理方式很适合互联网这种变化快,而且数据量相对要小一些的环境。在易用性和学习门槛方便简直是做到了极致,比如你要到处一些有特色的insert语句(比如按照主键排序,显示完全列名等),都可以通过mysqldump很容易实现。

    以上就是Oracle和MySQL的数据导入为何差别这么大的详细内容,更多关于Oracle和MySQL的数据导入的资料请关注lingkb其它相关文章!