基于Oracle数据库的商业网站数据库移植

开篇：润墨网以专业的文秘视角，为您筛选了一篇基于Oracle数据库的商业网站数据库移植范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

摘要:在商业网站运行中,数据库移植的根本目的在于系统升级,解决当前系统功能上和性能上存在的问题。所以,在我们的移植工程中首先要保证逻辑的正确,做到移植前后的等价性,然后要对移植后的系统进行性能调优。该文为此具体探讨了商业网站的Oracle数据库移植为SQL Server数据库的理论与应用分析。

关键词:数据库移植;SQL Server;Oracle

中图分类号:TP311文献标识码:A 文章编号:1009-3044(2009)33-9126-01

数据库移植就是不改变原有系统的后台数据库管理系统,并仍然保持原有系统架构、系统数据,前后端应用程序不变的一种系统升级方法。这种系统的变更通常是出去商业或者系统整体性能的考虑。整个移植过程一般非常庞大,其中主要包括存储空间的移植、数据库对象的移植、数据库数据的移植、代码的移植、系统测试等很多方面的技术问题。本论文讨论的重点是以围绕网站数据库中数字类型数据移植而进行的。

1 数据库移植的理论分析

数据库移植工程在全球已经有很广泛的应用,同时也出现了不少现成的不同产品间的数据库产品移植工具。然而,由于各种数据库产品之间的实现还是有很多根本架构上的不同,采用的SQL标准也不尽相同,这个导致了在很多问题上,并不是简单的语法变化就可以实现保证正确性的数据库转换。完全依赖数据库产品可能存在一些正确性的隐患,因此,很多地方还似乎要根据具体分析来进行人工参与的。这样的话,我们决定在数据库移植开发的前期借助数据库产品中的自动移植工具省去我们很多的重复工作,但在某些关键性问题上仍然需要我们人为的工作,或者对工具进行相应具体的配置。Oracle是以高级结构化查询语言(SQL)为基础的企业级大型关系数据库,通俗地讲它是用方便逻辑管理的语言操纵大量有规律数据的集合,也是目前最流行的客户/服务器(CLIENT/Server)体系结构的数据库之一。而SQL Server 2005也同样是拥有很多优越特性的基于客户/服务器体系结构的数据库。相较而言,进行oracle移植工作有公司项目的商业目的。一般来说,我们把数据库中用来储存和表示数据的实体成为对象(Object),它通常包括数据的逻辑存储空间,表(Table),索引(Index),视图(View),约束(Constraint),触发器(Trigger)和存储过程(Store Procedure)等等相关组成部分。在本次移植工作中,我们要做的工作是把原先在Oracle上的所有相关数据、程序、服务等等全部移植到全新的SQL Server环境,因此基于两者数据库架构和原理的一些不同,这些数据库对象也有很大的不同。而一个完整的数据库系统一般分成数据库服务器端部分和应用程序部分,两者互相结合。而数据库又包括数据库对象和数据库数据。所以我们进行数据库移植的工作就大致大致可以分成一下几个部分:存储空间的移植、具体对象得数据库移植与数据移植。

2 存储空间的移植

进行数据库的移植先要进行数据库后台级别的移植,再进行Code级别的移植。我们商业网站的数据库建立在Oracle上的,一共有18个数据库分散在大小不等的100多个逻辑设备。为此我们就在新的SQL Server数据库中,创建相对应的18个方案,来完成存储空间移植的工作。特别是对于表的分区,一般情况下我们应该能够将数据大致平均地分部在各个分区上。由于网站系统中数据是以时间为单位分部的,因此将主要数据按月份分为12个区是顺理成章的。不过另一方面,网站的计算是每天晚上启动的,启动以后会计算当月或者前一个月的数据,因此,在某一个时间单元里面,数据库对数据的访问也是集中在某个月份的。也就是说这样的分区方法并没有达到我们提高数据表访问并行度从而提高性能的目的,也无法很好得解决磁盘竞争冲突等问题。由此我们引入了新的分区方法-Hash分区。对数据表的Hash分区可以很好的解决以上所说的并发度和竞争冲突的问题,不过也存在它的缺陷。所以,经过针对PnA系统的分析和讨论,我们决定选择区间和Hash组合的分区方式,这样既做到了各个分区数据量的大致均等,又使不同的fund分区存放,提高了系统访问的并发度。

3 具体对象的数据库移植

在商业网站具体对象的数据库移植,这些具体对象包括:表、索引、视图以及数据类型。面来具体介绍了数字类型数据库如何实现它在新SQL Server环境中的移植工作。数字类型数据库中是最常见的一种对象类型,它本身并不复杂,转换起来也比较方便。可是往往有时由于具体的要求,表中存放数据对精度的要求比普通数据高很多,这样就出现一定问题了。特别是商业网站系统,平时每天都涉及大量的网络数据I/O和相关的计算,需要最大程度地保证数据精度,减少计算误差,保障客户利益。在网站系统中,原来的数据库上用Oracle中的float类型来表示浮点数,为了提升精度,在新的SQL Server系统中我们用NUMBER来表示各种数字,进行各种计算。Number类型的数字根据其参数的不同,可以表示成各种精度的整数或者小数,比如Number(1,2),等等。然而有一个问题需要注意,我们发现,简单地将Oracle中的float替换成SQL Server中的Number会产生一个问题。让我们看一个例子。在我们处理的计算中间过程中,需要从数库里取出一个浮点数并在之后的应用中和其他计算结果相比较,要求误差在于分之一以内。假设我们读取的是14.9875,那么我们在Oracle系统中,用这样的语句来读取并为以后的比较作准备:Select round (value, 3)from table1。相同的,Oracle中我们也用同样的语句来读取。可是我们却发现,在Oracle中select的结果是14.987,而在SQL Server中,这个结果变成了14.988。为了作测试,我们分别在我们的两个Server上运行如下的语句,来定位问题的所在。Oracle: Select round (14.9875, 3);SQL Server: Select round (14.9875, 3) from dual。

4 数据移植

当存储空间移植完成以后,我们就可以进行数据的移植。数据的移植在整个移植过程中显得非常重要,因为它是后面移植工作的基础,也是保证移植正确性的关键所在。选择一种高效的方式来实现数据移植是十分恰当而有必要的。首先在从Oracle到SQL Server的数据库移植过程中,SQL Server提供的数据库工具OMWB具备了数据移植的功能。不过为了将Oracle中不同的数据库和SQL Server中不同的Schema对应起来,我们只能选择一种合适的手工参与结合数据库工具的方法,来实施数据移植的工作。开发人员手工参与的方法有很多,当然,最简单直接的就是通过ODBC/JDBC来实现,然而这是一种比较低效的方法,在数据量小的时候还可以适用,在数据量暴增成千上万倍的今天,这样做带来的只能是速度上的极其低下。我们尝试过对一张千万行级别的表进行了移植,整个工作要花几天的时间,并且中间不能间断,万一有什么意外发生,前面的工作都将前功尽弃。因此,这并不是一个好方法。事实上,网站大部分数据其实都集中在某一部分大表中,在最终用户环境中,我们运用基于Oracle的相关脚本来配合我们实现数据库中的数据移植。因为脚本工具相对于ODBC等方法来说,对数据的操作更加直接,不需要繁琐的额外过程,效率特别高。对于我们的两个数据库系统来说,有很多脚本工具可以选择,我们只需选择各个数据库产品中相对高效、易于控制的脚本来帮助我们实现就可以了。最后,由于网络数据库系统的数据敏感性,我们最后要对移植的结果作出详细严格的测试,以有效的手段证明数据移植的准确性。我们的目标是移植前后数据相同或在一个很小的可以容忍的误差范围内。前文涉及到这类问题的有空串的移植、浮点精度等问题,这些都需要我们以适当质量保证手段来确保一致性。

总之,我们简单总结和介绍了在我们商业网站系统的数据库移植过程中所碰到的和可能碰到的各种问题,并提出了相应的解决方法。不过我们在数据库移植过程中需要根据具体情况对各个方面作出出合适的转换。在实际转换过程中,我们就根据不同的特点,提出了不同的数据策略。

参考文献:

[1] 张晓,张羽.远程数据库迁移技术研究[J].计算机应用研究,2005(4).

[2] 盖国强.循序渐进Oracle数据库管理、优化与备份恢复[M].北京:人民邮电出版社,2007.