• 售前

  • 售后

热门帖子
入门百科

oracle 数据库数据迁移解决方案

[复制链接]
丽人至上再 显示全部楼层 发表于 2021-10-26 12:35:18 |阅读模式 打印 上一主题 下一主题
  客岁年底做了不少体系的数据迁徙,大部门体系由于平台和版本的缘故起因,做的是逻辑迁徙,少部门做的是物理迁徙,有一些心得体会,与大家分享。
  起首说说迁徙流程,在迁徙之前,写好方案,特殊是实行的方案步调肯定要写清晰,然后举行完备的测试。我们在迁徙时,有的体系测试了四五次,通过测试来完满方案和流程。

  针对物理迁徙,也即通过RMAN备份来举行还原并应用归档的方式(这里不讨论通过dd方式举行的冷迁徙),虽然注意的是要将数据库设为force logging的方式,在用RMAN做全备之前,肯定要执行:

  否则大概会产生坏块。

  对于逻辑迁徙,在job_processes设置为>0的数值之前,注意job的下次执行时间和job所属用户。好比job的界说在之前已经导入,但是在迁徙之时,job已经运行过,那么迁徙完成之后,job的下次时间还是原来的时间,如许大概会重复运行。别的,job通过IMP导入后,job所属用户会酿成导入用户的名称,显然job原来的用户就不能对JOB举行管理了,可以通过下面的sql举行修改:

  在迁徙之前,应该克制对体系举行结构上的修改和发布,好比表结构,索引,存储过程包等。

  如果是用exp/imp导入的对象,包罗存储过程等,应该检查对象是否与原生产库一致,好比由于dblink的缘故起因,imp之后,存储过程不能创建,导致有部门存储过程丢失,只管这些存储过程大概没有被利用。

  下面是一些加速迁徙速度的技巧

  通过dblink,利用append insert的方式,同时利用并行,这种方式比exp/imp更快
  对于有LONG范例的列,insert..select的方式显然是不可的,可以通过exp/imp的方式,但是这种方式速度非常慢,其缘故起因在于imp时一行一行地插入表。有别的一种方式,即sqlplus的copy下令,下面是一个示例:


  不过,sqlpus的copy下令不支持有timestamp和lob列范例的表。如果有timestamp范例的表,可以通过在exp时,加上rowid的条件,将一个表分成多个部门同时利用,对于有lob范例的表,也可以同样处置惩罚(因为insert …select方式下,有lob范例列时,也同样是一行一行地插入)。注意在这种方式下,就不能利用direct的方式exp/imp。下面是exp导出时parfile示例:


  将表分成几部门同时利用,不但仅可以利用rowid,也可以利用表上的列,好比说,表上有一个created_date的列,并且保证是递增插入数据,那么这种环境下,也可以利用这个字段将表分成不同的范围同时举行导出和导入。不过利用ROWID通常具有更高的效率。
  当然对于有lob列的表,可以按上述方式,拆成多个insert方式同时插入,不必要exp/imp。

  ·对于特殊大的分区表,虽然利用并行可以进步速度,但是受限于单个历程(不能跨DB LINK举行并行变乱,只能并行查询,也即insert..select只能是SELECT部门才华举行并行)的处置惩罚能力,这种方式下速度仍旧有限。可以并行将数据插入多个中间表,然后通过exchange partition without validation 的方式,交换分区,这种方式将会大大进步了速度。
  ·有朋侪大概会问,为什么不并行直接插入分区表,当然如果黑白direct path(append)方式,则是没问题的,但是这种方式插入的性能较低。而direct path的方式,会在表上持有mode=6(互斥)的TM锁,不能多个会话同时插入。(update: 在insert 时利用如许的语句:insert into tablename partition (partname) select * from tablename where ….,更简朴更有效率。)
  ·迁徙时,将数据分成两部门,一部门是历史表,第二部门是动态厘革的表,在迁徙之前,先导入历史表,并在历史表上建好索引,这无疑会大大镌汰迁徙时业务体系中断时间。
  ·迁徙之前,思量清理掉垃圾数据。
  ·迁徙时,应保证表上没有任何索引,束缚(NOT NULL除外)和触发器,数据导入完成后,再建索引。建索引时同样,同时利用多个历程跑脚本。索引创建无成后,应去掉索引的PARALLEL属性
  ·在创建束缚时,应按先创建CHECK束缚,主键,唯一键,再创建外键束缚的次序。束缚状态为 ENABLE NOVALIDATE,这将大大镌汰束缚创建时间。而在迁徙完成后,再思量设回为ENABLE VALIDATE。
  ·通过利用dbms_stats.export_schame_stats和dbms_stats.import_schame_stats导入原库上的统计信息,而不用重新网络统计利用。
  朋侪们可以看到,以上均是针对9i的,实际上在10g以致11g环境下,也仍旧许多鉴戒意义。当然这些技巧不但仅用于完备的数据库迁徙,也可以应用到将个别表复制到其他数据库上。

  这里没有提到的是利用物化视图或高级复制、触发器之类的技能,因为这些技能,究竟要修改生产库,对生产库的运行有比力大的影响,因此,只有在停机时间要求特殊严格,而在这个时间内又不能完成迁徙时才应该思量。

  从迁徙的履向来说,只有完满的流程,完备的测试才可以保证乐成。这里只是摆列了一些小技巧,如果对整个迁徙过程有爱好,可以针对这个话题再举行讨论。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x

帖子地址: 

回复

使用道具 举报

分享
推广
火星云矿 | 预约S19Pro,享500抵1000!
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

草根技术分享(草根吧)是全球知名中文IT技术交流平台,创建于2021年,包含原创博客、精品问答、职业培训、技术社区、资源下载等产品服务,提供原创、优质、完整内容的专业IT技术开发社区。
  • 官方手机版

  • 微信公众号

  • 商务合作