|  | 设为首页 加入收藏 联系我们 |

|  | 首 页 行业资讯 网站运营 网络编程 数 据 库 网页设计 网络安全 网站推广 平面设计 服 务 器 JSPCMS |

| 站内搜索： 热门Tag： 淘特 CMS 门户 信息港 房产 汽车 旅游 分类信息 下载 JspCms 内容管理系统 更多>> |

现在位置：首页> 数 据 库

编辑推荐
·Oracle 11g数据库移植
·用SQL语句实现随机查询数据并不显示错误..
·一条语句简单解决“每个Y的最新X”的SQ..
·SQL Server存储过程命名标准
·SQL实现最优坐地铁方案
·SQL server服务器大内存配置
·SQL Server存储过程编写和优化措..
·Access中使用SQL语句应掌握的几点..
·SQL Server里附加数据库出错的解..
·SQL Server 2008之备份压缩

热门点击
·Oracle 11g数据库移植
·用SQL语句实现随机查询数据并不显示错误..
·一条语句简单解决“每个Y的最新X”的SQ..
·SQL Server存储过程命名标准
·SQL实现最优坐地铁方案
·SQL server服务器大内存配置
·SQL Server存储过程编写和优化措..
·Access中使用SQL语句应掌握的几点..
·SQL Server里附加数据库出错的解..
·SQL Server 2008之备份压缩

图片推荐
·Oracle.. | ·微软SQL ..

Oracle 11g数据库移植
作者： 日期：2010年3月31日 出处： 点击:

数据库版本频繁更新，不同版本数据库之间的移植是经常让数据库管理员头疼的问题。数据库移植不仅仅是导出导入的过程，由于新旧运行平台、操作系统、应用设备等的不同，其中涉及的问题方方面面，本文将为大家介绍Oracle Database 11g数据库移植的技巧、会遇到的问题和解决方案、以及实施移植的步骤等方面内容。 在数据库声明周期中最常发生的一件事就是不断地把数据库从老版本移植到新版本。不同版本之间的数据库移植有时候可能就像把数据从老版本里导出再导入到新版本中一样简单，不过其中涉及到的问题往往比你想象中复杂得多。而且移植过程还会涉及到其他一些显著的改变，例如操作系统改变、模式修改、以及相关应用软件的变化等等。每一项变化都存在着固有的风险性，不过人们常常认为还是应该把这些变化全部结合起来一起清除，来个一劳永逸，而且这样在移植过程中从头到尾都不去进行检测。这种情况出现了如此频繁，实在让人非常惊讶。 从一个软件工程师的观点来看，把这么多重要的改变通通放在一个步骤里实现是不是很好的解决办法并且足够安全呢?此外，不仅仅是实施移植而已，还要在实际移植之前检测这些变化是否适用于目标环境。 还有其他一些值得注意的地方：在依赖关系链打断移植过程之前，先把它给打断了，否则受打击的将是你。假设在从Oracle10g移植到11g的情况下，要把基层操作系统从Linux改为Solaris，在一个模式里修改主表，并且运行更新的或修改了版本的相关应用软件，那么应该在哪些步骤打断依赖关系链呢?换句话说，哪些步骤更加更安全、更熟悉、并且被其他很多人应用过了?而哪些步骤其他人都没有尝试过，而只适用于你的情况呢? 分清楚哪些是已经被实践过的而哪些又是未知的 如果你是Oracle新版本的边缘用户或者是最近才开始使用新版本的用户，那么在你(和你的公司)准备从老版本的关系数据库管理系统软件移植到新版本之前，已经有很多前辈为你做过“预演”了。同样的，那些前辈们已经跨越了采用Linux作为基本操作系统所带来的阴暗面。 考虑到关系数据库管理系统和操作系统的综合转换已经被大家所熟知，你的数据库产品所依赖的版本和操作系统是打破依赖关系链的理想之所在。如果把所有的操作都结合在一起一步到位的实施，那么移植过程是一个要么成功要么失败的过程，没有中间地带，而失败意味着时间可能都会浪费在这个过程的最简单部分，也就是说数据的移出和移入要花费大把的时间，如果失败，这些过程的执行等于做了无用功。如果你把整体移植过程至少分成两个不同的阶段，你将会把依赖关系链分割成若干小的关系链。这个必须熟习的指导性原则就是通过安全渐进的步骤完成移植过程。 对于数据库模式和应用软件的处理则要由你自己来决定。除非你已经对模式和应用软件的转换进行了彻底测试并使其正常运作了，否则整体移植过程的这一部分是否成功仍是个未知之数。如果让新应用软件和数据库上线，然后才发现新软件和数据库代码会导致连锁触发(cascading triggers)反应(将会导致实例瘫痪)，这样的情况会让你沮丧不已。实际产品环境中常包含成千上万条记录，而开发人员和测试人员在测试环境下的测试规模只有一百条记录，很难进行一次彻底的测试。 手动操作和设置导出和导入过程 关于导出和导入的实用工具，你不一定要接受其默认参数。事实上，你应该采用大部分的自定义设置，这样能够使移植过程更容易进行，而且在产品环境实际进行操作时能够节省大量时间。 我们首先来看看索引文件的参数设置，在导入过程中，最好使用indexfile=filename的设置，原因至少有四条。 第一，这样可以把表和索引等对象信息(全部或部分，取决于导出dump文件中包含了什么内容)存储在指定的输出文件中。想知道创建模式的源代码在哪里吗?如果你没有源代码，那这个参数(连同一个返回所有其他信息的简单查询)对于这些信息的提供会有很大帮助。查询部分会将全部的或user_source数据字典的内容输出到文件中。包、包体、存储过程、函数和触发器等代码信息都包括在输出的结果文件里。再稍微加工一下，例如执行CREATE OR REPLACE命令，清除SQL*Plus工具存储区域里无用的结果(如标题行、换页等)，剩下的就是一个模式最重要那部分的当前代码。 第二，如果你想对表和索引对象进行清洗或重排操作，那么在导入时通过这一设置，对索引文件进行编辑，并对表空间映射和存储参数进行更新时机恰到好处。 第三，如果你想让逻辑布局维持原样，可以分隔索引和表，也就是分离SQL CREATE命令(一部分脚本专门用于创建表，另一部分专门用于索引)。在进行实际的移植之前，要尽可能先设置好目标数据库。其中一部分工作就是创建新的同样的表空间，并运行创建表的脚本。提前运行创建表的标本有两个理由，一是使逻辑布局生效，二是提高移植导入的速度。 第四个原因回到了索引文件中所列的索引。当执行数据批量插入时，是有索引好呢还是没有所以更好呢，这对于插入效率有多大的影响?由于每插入一个新记录，就必须更新一个或多个索引(假设该记录至少有一个主键)，所以对于大型数据库而言，Oracle的建议是等所有的数据都已经插入完毕后再构建索引。这样的建议无疑又重申了indexfile的重要性，因为当导出时使用“indexes=n”(默认设置是y)的设置把索引忽略掉以后，想要在数据全部导入完毕后重新构建索引，indexfile就是衔接的桥梁。 数据库移植不是简单的导出导入 Oracle 11g最早的版本是运行在Linux系统下的，也提供安装了相关的关系数据库管理系统软件，你所运行的新实例包含了很多意想不到的新特性。不过，这一切都得在你成功的把源数据库(或模式)移植新的目标数据库之后再说。你可能正计划在周五的半夜占用八小时的停工和维护时间来执行移植操作。那么在移植之前，你可以做些什么来尽可能保证整个移植过程顺利“无痛”的进行呢?只要你对以下四个重要方面做好规划，就可以使你的移植过程与众不同：统筹管理、导出阶段、导入阶段和交接阶段。

首页 上一页 [1] [2] [3] 下一页 尾页

- 返回首页
- 打印本文
- 加入收藏
- 返回顶部
- 关闭窗口

相关文章 | 查看评论>> 发表评论
用 户： |
内 容： |
验证码： |

关于本站　|　免责声明　|　联系我们　|　版权隐私　|　友情链接　|网站地图 | SiteMap
联系电话：0531-88511191 | 客服QQ：6410861 | Email：totcms@163.com | ICP备：88888号 Copyright © TotCms.com All Rights Reserved. 济南淘网科技 版权所有