如何更简单地数据迁移

  • 3
  • July 2, 2014

对于很多租赁公司高管来说,特别是CIO,我们即将要讨论的,可能对于他们来说是最可怕的噩梦。不管怎样,就作者的经验来说,这些问题可以对抗,解决。借助前瞻性的思维和有系统的计划,是可以很顺利地数据迁移的.

现今的数据密集型世界,大多数的软件实施项目需要执行数据迁移。在我们部门,无论你是在布置一个新的合同系统,还是在线事务处理(OLTP)系统,一种数据仓库解决方案,在技术说在线分析处理(OLAP)系统,你将最有可能需要执行数据迁移.

对于外行人说,可以原谅他认为两个系统包含相同的数据,操作起来很相似,从一个系统移植到另一个系统很容易。非常遗憾,并非如此。从历史观点上说,遗留系统被证明是过于执行原子层级的数据的完整性过于轻松.

综上所述,绝对需要一个方法对策,解决数据迁移项目的问题。虽然没办法避免这些不愉快的惊喜,但是我们可以准备好解决他们.

数据迁移的阶段

数据迁移项目计划应该被分为几个阶段,涵盖整个项目。阶段可被界定为分析,数据映射,构建,传输和解,修订,迁移和解和维护.

1. 分析

分析阶段通常贯穿整个项目,由于数据观测传输项目通常会引入一个新的系统,因此项目经理会有在优先顺序上很矛盾,不仅仅是新系统要处理的。这里有可能会发生一些关键错误,大家的注意力都集中在新的项目上,却很很少注意到,甚至忽略数据迁移的需求。现实中的数据迁移在OLTP和OLAP空间中需要单独的详细的项目计划,那些只包含一行条目在甘特图上“数据迁移”是自欺欺人.

分析阶段的第二个元素是建立数据迁移团队,这个挑战通常显示同样的人预计他们将参与系统项目实施工作,同样也是数据迁移的一部分。这就导致了当务之急需要解决优先顺序问题。因为这对于项目经理需要作出优先呼叫依照业务需求,这个难题没有正确或是错误的答案.

另外一点值得注意的是,项目团队需要多在项目上投入精力。大多数成功地项目都是有着项目团队积极的执行和百分百的投入。不应该期望项目团队的成员全日制的工作和项目团队的人一样。项目重要性的清晰沟通,优先事项和项目组成员的责任一起,意味着在每天的日常业务需求创建的合理差距,由谁明白,为什么他们被要求加紧填补其他同事进行回填虚空.

回到数据迁移的话题,作为一个租赁资产融资业务的经理,你将会知道你的业务被多个系统支持。在很多数据迁移项目上,我们发现我们会面对很多不同的系统,或者我应该更精确的说数据来源,其中数据的组合,以转移所在.

分析阶段的下一部分包括开始熟悉你要迁移的实际数据。记住,项目上的这个点,你只有最低限度的信息,要在其上开发数据迁移计划。要想很好的完成工作,了解要被迁移数据的质量和数量是至关紧要的.

到目前为止,我们还没有考虑什么样的选择是真正适用于数据迁移。在OLAP数据迁移时,尤其是需要数据更新时,例如在数据仓库中更新,几乎没有选择,只能遵循一个自动迁移策略。无论如何,OLTP迁移,这是一个典型的一次性的,手动操作可能值得考虑,通常来说数据流量会是个引导器,

2. 数据映射

在你对旧数据源做出决定后,下一步是定义需要迁移什么数据;之后那些数据元素就会被映射到新系统。这包括将通过从每个数据元素和每个数据源的列表,并决定是否迁移,并在新的系统比较那些。在这个练习中的数据进一步提取的样本将是必要的,以帮助解释任何异常现象.

映射阶段不打算彻底查明由历史数据都将迁移到新的系统转换规则;相反它是从根本上让必须迁移的数据元素的清单的行为.

3. 建立

给你的迁移伙伴建立阶段需要经验,知识,和技能,NETSOL在这方面,脱颖而出。从众多纷杂的数据迁移的行业经验的合作伙伴,将提供放心工程与业务和技术专长的来完成此项目。为了提供一个快速启动这一进程,NETSOL在源数据和临时映射地已建成了数据迁移转换工具.

同时,转换工具不是唯一可用的方式,是截止到目前最有效率,最有效的。另一种趋向于电子表格,当你需要一个源数据元素映射到一个或多个目标元件,其总是失败。电子表格通常防止一个以上的人从在同一时间进行修改,造成不必要的管理费用.

在进行数据仓库类型的迁移,在改造和理顺数据集成到新表的需求将是提供实时快速获取在线分析的要求时,补给站数据存储库变得尤为关键.

4. 转移/调和

下两个阶段传输/和解和修改是迭代的。通常这将涉及多个子集数据和客户月末数据的完整数据,提取物通过与脚本临时数据库拉到变换,并根据需要映射到收件人数据库.

这个阶段会回答以下问题;

  • 我们预计这个脚本创建多少记录?
  • 是否创建了正确数量的记录?
  • 数据是否输入在正确的地方?
  • 数据格式化正确吗?
  • 一致吗?

这个阶段总是强调用户的历史数据元素必须迁移,在分析会议时对于他们来说不明显.

事实是,数据映射第一次是不容易成功地。大多数人没有意识到,一个数据元素的缺失,直到他们意识到,却为时已晚。为此,修改阶段必须遵守纠正这些异常和传输/和解阶段必须通过再次运行.

尽快投入迁移项目这一点是重要的是要,因为这将强调,任何可能需要接收方系统\’的数据模型进行调整,以适应任何特定的客户要求派生的任何问题是非常重要的.

这个阶段的和解方面是至关重要的一个成功的迁移。迁移与合作伙伴必须定义所需的标准和过程验证成功的和解。记住这是你的业务,你的数据,最终你的责任签署迁移和解结果。

5. 修订

修订后阶段的程度完全取决于前面描述的传输/和解阶段成果。从理论上讲,应该可以用一个完全统一,并成功转移脚本与和解阶段完全跳过这个阶段,但遗憾这是从来没有的情况下,异常也总是出现。有趣的是,经验表明,和解不平衡,或者有大量的数据不匹配的协议被发现事实的价值,是不是一个很好的指导,以迁移需要多少额外的努力,需要完成。

大型组合具有大和解不平衡很可能被纠正,或者大部分的差的发现,由一个或两个调整,并且通常这些都是容易跟踪,而较低的值和解不平衡,或协议的一个更小的数与数据失配是很难找到。

一旦传输/和解和修改阶段已圆满完成,是时候实现。

6. 迁移/和解

如在迁移/和解相位的第一步骤,建议完全迁移\“空转\”进行。空运行必须承担最终的代码集新系统的地方。这是因为任何进一步改变的基础数据结构和/或规则临界能够对数据传输的结果产生影响。迁移的数据应该是彻底的用户测试,和解。和解在这个阶段非常关键。迁移的伴侣会进行详细和解坚持你的标准和流程,但是最后签字的责任取决于你从审计和批准。

继成功地调和试运行的完整迁移才能进行。这通常会采取在月末的数据的地方,定时在一个周末发生。这项活动很明显将涉及业务系统的停机一段时间,所以要挑选最大限度地减少业务中断,而且还给出了时间解决可能出现的任何问题的时间是很重要的。

7. 维护

维护阶段才真正适用于执行数据仓库(OLAP)系统迁移的情况。在合同管理系统(OLTP)系统的迁移,在一次性迁移的环境中工作。对遗留数据成功迁移到新系统的目标是完成因此需要维持迁移脚本将被删除。

在数据仓库(OLAP)的迁移,你将最有可能在重装及时间隔新系统。随着新的信息被记录在你的合同管理系统,你会希望它传输到数据仓库(OLAP)。脚本性能在数据仓库迁移的一个关键问题,因为新数据添加到数据迁移脚本刷新将需要进行审查,以确保卓越的性能得以保持。

结论

最后,数据迁移,更多的,往往不是一个必要的步骤。成功的关键是要早做准备,持续监控并确保您的项目团队和合作伙伴的迁移你们之间有明确责任双方都能理解的方式,以及一个专门的团队来实现它。不幸的是除了准备之外没有神奇的魔术公式,规划,注重细节和勤奋劳动等,并确保你在关键业务中有一个经验丰富,技术精湛的合作伙伴

By Tony Langford and GrahamTarrant,
NETSOL Technologies

Top

请求演示

请提供以下详细资料,我们将回复您。

请求演示:- NFS AscentNFS移动解决方案

业务类型(其他):-

合同数量/年:-

租赁类型:-

组织形式:-

备注:-

上传RFP/RFS:-

To use CAPTCHA, you need Really Simple CAPTCHA plugin installed.